Карьера 3.0: Как оставаться востребованным в эпоху ИИ

Такую фразу нужно проверить у руководителя или внутреннего заказчика. Спросите: «Какое решение вы принимаете на основании моей работы?» Если человек называет конкретное действие, связь с результатом есть. Если отвечает: «Нам просто нужен отчёт», уточните, кто его читает, что делает после прочтения и что произойдёт, если отчёта не будет. Иногда выяснится, что документ действительно нужен для контроля. Иногда — что его делают по привычке и никто не использует. Оба ответа полезны: первый показывает ценность, второй — возможность перепроектировать процесс.

Дефицитный контекст плюс ответственность

После инвентаря Елена вернулась к Антону. Она показала ему не новый красивый отчёт, а карту процесса.

— Первую часть я готова перевести в автоматический режим, — сказала она. — Но система пока не различает рост просрочки из-за нехватки транспорта и рост просрочки из-за задержек на складе. Если мы будем отправлять одинаковое решение по обоим случаям, расходы вырастут, а проблема останется.

Антон посмотрел на список.

— Тогда что нужно оставить за тобой?

— Формулировку управленческого вопроса, проверку причин, оценку вариантов и контроль исключений. А ещё нужно договориться, кто принимает решение, если риск выходит за установленный порог.

Это был первый разговор, в котором Елена не защищала каждую ручную операцию. Она сама предложила убрать часть своей прежней работы. Взамен обозначила более сложную зону — управление качеством решения.

Критерий востребованности можно сформулировать коротко: дефицитный контекст плюс готовность отвечать за решение.

Дефицитный контекст — это не секретная информация и не способность хранить в памяти больше фактов, чем коллеги. Это знание того, какие данные важны именно здесь, какие ограничения нельзя нарушить, чьи интересы сталкиваются, какую ошибку компания может принять, а какую — нет, и что произойдёт после выбранного действия.

Ответственность — не готовность единолично отвечать за всё и не привычка подписывать каждый документ. Это понятные полномочия, критерии проверки и связь с последствиями. Если сотруднику поручают результат, но не дают доступа к данным, права остановить риск или возможности влиять на решение, речь идёт не об ответственности, а о перекладывании вины. Карьерный рост начинается не с согласия «отвечать за всё», а с умения договориться о границах решения.

ИИ может увеличить скорость и качество работы Елены. Он может освободить её от сбора, сверки и первичного описания данных. Но он не отменяет вопроса «что делать дальше?». Более того, чем дешевле становится подготовка информации, тем заметнее человек, который умеет превратить её в выбор, объяснить компромисс и проверить последствия.

Название должности не исчезает. Меняется её содержание. Руководитель аналитики больше не обязан быть самым быстрым производителем отчётов. Его ценность — в том, чтобы построить контур, где данные превращаются в своевременные решения, а автоматизация освобождает время для сложных исключений, переговоров и ответственности.

Теперь у Елены есть не только тревога о будущем, но и рабочая карта: какие операции можно передать, где нужен соисполнитель, какие решения требуют контекста и какие результаты она должна уметь предъявить рынку. Следующий шаг — посмотреть на эту карту ещё строже и определить, какие фрагменты её работы уже легко заменить, какие пока трудно воспроизвести, а какие она сама должна сделать более ценными.

Карта своей заменяемости

Рынок оценивает не место в штатном расписании, а результат, за который кто-то готов платить. Но прежде чем передавать модели повторяемые операции, нужно увидеть, из чего они состоят. Самый точный способ — не спрашивать себя «заменит ли меня ИИ?», а устроить своей работе короткий краш-тест.

Возьмите последнюю задачу, которую вы выполняли регулярно. Например, «подготовить еженедельный отчёт», «проанализировать обращения клиентов» или «согласовать закупку». Теперь представьте, что завтра эту задачу должен повторить коллега или ИИ, имея только её название. Никаких пояснений, переписки, доступа к вашей памяти и знаний о внутренних правилах.

Эксперимент почти сразу вскрывает проблему: название задачи ничего не объясняет. В формулировке «подготовить отчёт» скрываются поиск данных, проверка периода, исправление форматов, удаление дублей, сравнение показателей, поиск отклонений, интерпретация причин, согласование спорных цифр и выбор того, что именно сообщить руководителю. Один глагол маскирует целую цепочку разных действий. Пока эта цепочка не видна, невозможно понять, что передать ИИ, что оставить человеку, а что вообще перестать делать.

Тест одного глагола

На десять минут запретите себе слова «подготовить», «сделать», «проанализировать», «проверить», «проконтролировать», «согласовать» и «организовать». Они слишком широки и скрывают детали. Записывайте только наблюдаемые действия: найти, выгрузить, очистить, сопоставить, посчитать, классифицировать, объяснить, запросить, выбрать, утвердить, отправить.

Например, вместо «проанализировать еженедельный отчёт» получится примерно такая запись:

Найти данные за нужный период в трёх внутренних источниках.

Проверить, что во всех выгрузках используются одинаковые даты и единицы измерения.

Удалить дублирующиеся записи и отдельно отметить пропуски.

Сопоставить фактический результат с планом и предыдущим периодом.

Посчитать отклонения по заранее заданным формулам.

Выделить показатели, которые вышли за допустимый диапазон.

Понять, связано ли отклонение с изменением спроса, ошибкой учёта, задержкой обработки или разовой ситуацией.

Запросить комментарий у владельца процесса.

Сформулировать вывод для руководителя, не перегружая его техническими деталями.

Предложить действие, срок и ответственного.

Проверить итоговый текст и отправить его в нужный канал.

Последние три пункта уже не просто продолжают первые. Они связаны с контекстом, полномочиями и последствиями. Модель может быстро найти отклонение и составить ясный текст, но это ещё не значит, что она знает, какое отклонение требует вмешательства, кому назначить действие и какой вывод допустимо передать наружу.

Пять удобных заблуждений

Первый миф: заменяемость относится к должности.

На деле заменяется не должность целиком, а отдельные операции внутри неё. Даже в одной должности могут одновременно существовать полностью стандартизируемые действия, редкие экспертные решения и коммуникации, где цена неверно понятого контекста выше выигрыша в скорости. Аналитик не бывает «заменяемым» или «незаменимым» целиком. Сбор данных в его работе можно передать системе, а интерпретацию результатов и ответственность за решение — нет.

Второй миф: если ИИ умеет подготовить результат, он умеет выполнить работу.

Модель может создать убедительный отчёт, письмо или сводную таблицу. Но работа состоит не только из конечного файла. В неё входят выбор источников, проверка исходных данных, понимание внутренних определений и оценка последствий. Хорошо оформленный документ с неверным периодом или незамеченной ошибкой учёта остаётся плохим результатом.

Третий миф: рутинное не имеет ценности, а сложное защищено.

Сбор показателей может быть рутинным, но без него руководитель примет решение вслепую. Согласование закупки может выглядеть как простое сравнение цен, хотя ошибка затронет бюджет и сроки. Сложный текст, напротив, иногда состоит из повторяемых шаблонов и легко передаётся модели. Сложность исполнения и ценность результата — разные характеристики.

Четвёртый миф: человек всегда исправит ошибку ИИ.

Человек исправляет ошибку только тогда, когда у него есть время, исходные данные и критерий проверки. Если модель подготовила сотню ответов, а проверяющий видит лишь гладкий текст, он может пропустить неверное обещание, перепутанную цифру или устаревшее условие. Человеческий контроль без процедуры проверки часто превращается в формальное согласование.

Пятый миф: для эксперимента нужен большой проект внедрения.

Первый пилот не требует перестройки всей работы. Достаточно выбрать один повторяемый участок, определить входные данные, ожидаемый результат и точку человеческой проверки. Сначала нужно изучить задачу, а не покупать или разворачивать сложную систему. Такой аудит обычно быстрее выявляет подходящий участок, чем обсуждение ИИ на уровне общих опасений.

Правильная единица анализа

Заменяемость — не ярлык специалиста, а доля действий, которые другой исполнитель или модель могут выполнить при заданных условиях без неприемлемой потери качества, контекста и контроля.

Такое определение сразу убирает две крайности. Не нужно защищать каждую операцию только потому, что она связана с вашей профессией. Не нужно и отдавать системе всё, что кажется повторяемым. Каждое действие следует рассматривать через четыре элемента: входные данные, операцию, критерий проверки и результат.

Например, «найти пропущенные значения» — действие с понятным входом, правилом и проверяемым результатом. «Объяснить, почему показатель снизился» — действие, для которого требуется более сложный контекст. «Выбрать, нужно ли менять процесс» — решение, связанное с ответственностью. Эти три шага могут находиться в одной строке должностной инструкции, но требуют разных связок человека и ИИ.

Удобная последовательность декомпозиции выглядит так.

Найти. Определить, откуда берутся сведения, кто владеет источником и за какой период они собраны.

Очистить. Привести данные к единому виду, убрать дубли, обнаружить пропуски и отметить сомнительные записи.

Сравнить. Сопоставить фактические значения с планом, нормативом, предыдущим периодом или другой контрольной группой.

Интерпретировать. Связать изменение показателя с причинами, отделив подтверждённые факты от предположений.

Согласовать. Получить комментарии от владельцев данных или процесса, разрешить расхождения и зафиксировать спорные места.

Решить. Определить действие, срок, ответственного и последствия бездействия.

Первые два шага часто хорошо подходят для передачи модели. Третий обычно можно частично автоматизировать по формальным правилам. Четвёртый требует контекста. Пятый зависит от распределения полномочий. Шестой остаётся зоной ответственности человека, даже если ИИ подготовил несколько вариантов.

В этой последовательности особенно важно различать выполнение операции и ответственность за результат. Модель может найти все отклонения, но не обязательно способна решить, какое из них требует вмешательства. Она может составить три варианта письма, но это не значит, что она может взять на себя обязательство перед клиентом.

Когда задача действительно уязвима для автоматизации

Высокая автоматизируемость обычно определяется не тем, что задача скучная, а вполне конкретными признаками.

Входные данные находятся в цифровом виде и доступны по понятному правилу. Для выполнения не нужно извлекать смысл из устных договорённостей, фрагментов переписки и личной памяти сотрудника.

Правило действия повторяется. При одинаковом типе входа разные исполнители получают примерно одинаковый промежуточный результат.

Результат можно быстро проверить. Есть формула, контрольная выборка, эталонный справочник, допустимый диапазон или другой внешний критерий.

Ошибка обратима. Неверную строку можно исправить до отправки, а результат — повторно получить из сохранённого источника.

Объём достаточно велик, чтобы экономия времени имела смысл. Передавать системе действие, которое выполняется раз в квартал и занимает семь минут, необязательно.

Контекст ограничен. Для выполнения не требуется знать незафиксированную историю отношений, неформальные правила или скрытые интересы участников.

Если большинство этих признаков присутствует, задача подходит для автоматизации или совместной работы с моделью. Но один параметр способен изменить решение: цена ошибки.

Простота действия не означает низкую цену ошибки

Удалить дубли легко, когда критерий дубля задан заранее. Но если похожие записи обозначают два разных события, автоматическая очистка уничтожит важную информацию. Сопоставить цены в предложениях поставщиков тоже несложно, если совпадают характеристики, сроки, комплектация и условия оплаты. Иначе самая низкая цифра может оказаться не самым выгодным предложением. Подготовить клиентский ответ легко, если требуется лишь сообщить статус заявки. Но если в ответе содержится обещание, компенсация, изменение условий или сведения о другом лице, риск резко возрастает.

Поэтому для каждого действия нужно задавать не один вопрос: «Можно ли это автоматизировать?» Важнее спросить: «Как будет обнаружена ошибка до того, как она повлияет на решение?»

О высокой цене ошибки говорят несколько сигналов.

Ошибка становится заметной только после отправки документа или выполнения действия.

Результат невозможно сравнить с надёжным эталоном.

Действие связано с деньгами, сроками, обязательствами перед клиентом или доступом к чувствительной информации.

Ошибка может выглядеть правдоподобно. Неверную формулу иногда легко заметить, а убедительное, но не подтверждённое объяснение — гораздо труднее.

Исполнитель не имеет права самостоятельно принимать решение, но автоматизированный процесс создаёт такое впечатление.

При наличии этих признаков ИИ всё равно может быть полезен, но только как усилитель: он ищет, группирует, предлагает и подсвечивает, а человек проверяет контекст и утверждает результат.

Три рабочих контекста

В клиентском ответе можно автоматизировать поиск истории обращения, выделение фактов, проверку статуса и подготовку черновика. Но выбор обещания, интерпретацию спорной ситуации и формулировки, способные создать финансовое или договорное обязательство, не стоит передавать модели без проверки. Здесь она экономит время на подготовке, а человек сохраняет контроль над содержанием и тоном решения.

В согласовании закупки системе можно поручить собрать предложения, привести единицы измерения к общему виду и предварительно сопоставить стоимость. Однако выбор поставщика может зависеть от соответствия техническому заданию, сроков поставки, бюджета, условий обслуживания и результатов прошлых поставок. Сводная таблица сама по себе не является решением. Она лишь сокращает путь до момента, когда решение можно принять осознанно.

В еженедельном отчёте модель способна собрать данные, обнаружить аномальные значения, проверить расчёты и подготовить черновой вывод. Но если показатель изменился из-за смены классификатора, временной остановки процесса или разовой крупной операции, автоматическое объяснение будет всего лишь гипотезой. Его необходимо отделить от подтверждённого факта.

Матрица ценности и уязвимости

Чтобы не спорить о заменяемости на уровне ощущений, разложите задачи по двум осям.

Первая ось — ценность результата для бизнеса. Насколько изменится работа организации, если эта задача будет выполнена плохо или не выполнена вовсе? Учитывайте деньги, сроки, качество обслуживания, управленческие решения и способность процесса продолжать работу.

Вторая ось — уязвимость задачи к стандартизации и передаче. Здесь уязвимость означает не слабость, а податливость формализации: можно ли отделить задачу от контекста, описать правила, проверить результат и исправить ошибку до того, как возникнут последствия?

Высокая уязвимость означает, что задачу легко разложить на формальные операции и передать другому исполнителю при сохранении контроля. Низкая — что в ней много скрытого контекста, уникального суждения, неформальных правил или ответственности. Цена ошибки вносит поправку: если действие выглядит простым, но его результат трудно проверить, передавать его без человеческого контроля нельзя.

Низкая ценность, высокая уязвимость. Передавать. Такую задачу можно автоматизировать, шаблонизировать или включить в пакетную обработку, оставив только выборочные проверки.

Высокая ценность, высокая уязвимость. Усиливать человеком. Модели можно поручить поиск, расчёт и подготовку черновика, а человеку оставить интерпретацию, проверку и утверждение.

Высокая ценность, низкая уязвимость. Защищать. Человеческое владение процессом следует сохранить, а автоматизировать только вспомогательные операции.

Низкая ценность, низкая уязвимость. Пересмотреть или убрать. Стоит уточнить, зачем задача существует, объединить её с другой или прекратить выполнение.

«Защищать» не означает прятать знания, создавать искусственную сложность или отказываться от любого инструмента. Это значит сохранить участок, где человеческий контекст пока создаёт основную ценность. Такой участок нужно сделать понятным, документировать и использовать для принятия решений.

«Передавать» не означает исчезать из процесса без контроля. Для низкоценной задачи достаточно установить владельца, вести журнал изменений и проводить периодическую выборочную проверку.

«Усиливать человеком» — самый интересный вариант. В этом квадранте ИИ действительно способен резко повысить производительность, но не должен становиться самостоятельным носителем ответственности. Человек сохраняет право остановить результат, запросить подтверждение и изменить вывод.

Разбор: еженедельный отчёт

Рассмотрим типовой еженедельный отчёт операционного подразделения. На выходе — две страницы для руководителя и приложение с показателями. Формулировка задачи звучит просто: «Подготовить отчёт к началу недели».

После декомпозиции проявляется совсем другая картина.

Сначала нужно получить выгрузки из системы учёта обращений, финансового плана и расписания сотрудников. Затем проверить, что везде используется один и тот же период. После этого требуется убрать повторы, найти пропуски, привести названия категорий к единому виду и выяснить, не изменились ли правила классификации.

Далее считаются фактические показатели, отклонения от плана и динамика за несколько предыдущих периодов. Система легко справится с формулами и выделит значения, вышедшие за заданный диапазон. Но сами отклонения ещё ничего не объясняют.

Снижение результата может быть связано с уменьшением входящего потока, задержкой внесения данных, изменением графика, новым способом классификации или реальным ухудшением процесса. Чтобы различить причины, нужен контекст владельца процесса. Иногда одна крупная операция меняет среднее значение сильнее, чем несколько десятков обычных случаев.

Затем появляется управленческий вывод. Нужно решить, какие цифры важны для руководителя, что следует вынести в начало, где требуется действие и какие вопросы пока нельзя считать закрытыми. Наконец, выводы согласуются с ответственными за данные, а отчёт отправляется тем, кто вправе использовать его для принятия решения.

Теперь распределение работы выглядит иначе.

Сбор стандартных выгрузок — действие с высокой уязвимостью и низкой или средней ценностью само по себе. Это кандидат на передачу.

Проверка форматов, удаление очевидных дублей и расчёт формул тоже обладают высокой уязвимостью. Их можно поручить модели или автоматическому сценарию, если предусмотрены контрольные проверки.

Поиск отклонений сочетает высокую уязвимость и высокую ценность. Здесь подходит усиление человеком: модель быстро находит подозрительные участки, а человек решает, какие из них действительно заслуживают внимания.

Интерпретация причин отличается низкой уязвимостью и высокой ценностью. Этот участок нужно защищать: сохранить человеческий анализ, доступ к контексту и ответственность владельца процесса.

Согласование спорных цифр и выбор управленческого действия также относятся к зоне высокой ценности и низкой уязвимости. Это не место для безусловной передачи.

Формирование черновика и приведение отчёта к нужному формату сочетают высокую уязвимость и высокую ценность результата. Здесь модель усиливает человека: создаёт первую версию, но не утверждает её.

Самая опасная ошибка — автоматизировать отчёт целиком только потому, что итоговый файл выглядит стандартно. Внешняя форма скрывает разные типы работы. В результате можно получить аккуратный документ, где все числа посчитаны, но выбран не тот период, пропущена смена классификатора или неверно объяснено отклонение.

Краш-тест перед первым пилотом

После декомпозиции не стоит сразу автоматизировать самый заметный участок. Выберите действие, которое одновременно соответствует пяти условиям: оно повторяется, имеет ясный вход, даёт проверяемый результат, не создаёт необратимого обязательства и может быть остановлено без ущерба для процесса.

Для еженедельного отчёта безопасным первым пилотом может стать сбор чернового блока показателей и списка подозрительных отклонений на обезличенных данных. Модель не отправляет отчёт, не формулирует окончательные выводы и не меняет исходные записи. Она только готовит промежуточный материал, который затем сравнивается с результатом ручной работы.

Если в данных есть персональные сведения, используйте только разрешённый организацией контур обработки и передавайте минимально необходимый набор полей. По возможности записи нужно обезличить. Ответственность за законность и безопасность обработки данных остаётся у владельца процесса, а не у модели.

Пилот лучше проводить в режиме параллельного выполнения. Старый способ пока продолжает работать, а новый результат готовится рядом. Сравнивать нужно не впечатления, а конкретные показатели: сколько времени заняла подготовка, сколько расхождений найдено, сколько исправлений внесено, какие типы ошибок возникли и на каком шаге их обнаружили.

Алгоритм состоит из семи шагов.

Шаг 1. Назовите не всю задачу, а один участок.

Не «автоматизировать отчёт», а «собрать показатели за неделю и проверить пропуски». Чем уже граница, тем быстрее появится наблюдаемый результат.

Шаг 2. Зафиксируйте, что не входит в пилот.

В нашем примере за пределами пилота остаются интерпретация причин, выбор действий, отправка документа и изменение первичных данных. Эти ограничения нужны не для бюрократии, а для защиты процесса от незаметного расширения полномочий.

Шаг 3. Опишите входные данные.

Нужно указать источники, период, обязательные поля, допустимые форматы и правила удаления или сохранения спорных записей. Если вход невозможно описать, задача пока не готова к передаче.

Шаг 4. Опишите приемлемый результат.

Например: таблица с показателями, перечень пропусков, список дублей и отметка по каждому отклонению с указанием его источника. Не «хороший отчёт», а результат, который можно проверить по отдельным пунктам.

Шаг 5. Назначьте человеческую точку контроля.

Конкретный владелец должен проверить исходные данные, выборочные расчёты и список отклонений. Проверяющий не обязан переписывать всё вручную, но обязан иметь право остановить результат.

Шаг 6. Определите условие остановки.

Пилот прекращается, если модель систематически теряет записи, путает периоды, не показывает источник вывода или создаёт больше исправлений, чем экономит времени. Такие условия лучше установить до запуска. Иначе успехом могут объявить любой результат, который просто выглядит быстрее.

Шаг 7. Примите одно из четырёх решений.

Передавать — если действие малоценно, повторяемо, проверяемо и обратимо. Его можно включить в автоматический сценарий, шаблон или регулярную пакетную обработку. Человек сохраняет выборочный контроль, но перестаёт вручную выполнять каждую операцию.

Усиливать — если результат ценен, а отдельные операции хорошо стандартизируются. Модель ищет, считает, группирует и готовит черновик. Человек интерпретирует, согласует и утверждает. Так обычно и выглядит безопасный рабочий союз.

Защищать — если действие связано с уникальным контекстом, трудной проверкой или высокой ценой ошибки. Не нужно искусственно отдавать его системе ради самого факта автоматизации. Можно улучшить доступ к данным, сократить рутинную подготовку и сделать экспертное решение прозрачнее.

Пересмотреть или убрать — если задача не даёт заметной ценности и при этом не поддаётся безопасной стандартизации. Часто такой участок существует лишь по привычке: его продолжают выполнять, потому что когда-то он был нужен. Удаление лишнего процесса повышает производительность лучше, чем попытка его автоматизировать.

После аудита иногда появляется промежуточное решение: «пока не менять». Оно означает, что ценность задачи высока, а условия для безопасной передачи ещё не созданы. Тогда нужно не защищать ручной процесс навсегда, а зафиксировать, чего именно не хватает: единого справочника, контрольного эталона, доступа к источникам, понятного владельца или правила проверки.