Почему компании автоматизируют не те процессы — и как найти подходящий workflow для AI

Компании начинают автоматизацию не с того вопроса

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

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

Прежде чем выбирать AI-агента, нужно ответить на более базовые вопросы:

• Как процесс выполняется сейчас, а не как он описан в регламенте?
• Какие люди, системы и документы в нём участвуют?
• Где возникают задержки и ручные переходы?
• Какая информация нужна для принятия каждого решения?
• Какие исключения не отражены в инструкциях?
• Где проходит граница ответственности между участниками?
• Как выглядит конкретный и проверяемый результат процесса?

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

Описанный процесс почти всегда отличается от реального

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

Задачи и статусы находятся в Jira. Требования и архитектурные решения хранятся в Confluence. Реализованные изменения видны в GitHub. Часть договорённостей принимается на встречах. Дополнительные материалы остаются в документах, а некоторые исключения существуют только в памяти опытных сотрудников.

Формальный процесс показывает, как работа должна выполняться. Цифровые следы показывают отдельные факты: кто изменил задачу, когда появился pull request или какая страница была обновлена. Но ни один из этих источников сам по себе не объясняет весь workflow.

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

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

Что происходит, если автоматизировать плохо понятый процесс

Когда компания переходит к реализации слишком рано, проблемы проявляются уже во время пилота:

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

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

Как должен работать Process Discovery

Process Discovery — это восстановление фактического workflow по данным рабочих систем и объяснениям его участников. Его задача — не просто нарисовать схему, а подтвердить, где проходит работа, какие решения принимаются и что мешает процессу двигаться дальше.

В Laplace отправной точкой для такого анализа может выступать Context Audit. Он уже помогает находить проблемы рабочего контекста по доступным данным Jira, Confluence, GitHub и активного календаря: неполные задачи, пробелы в документации, слабую связь между объектами и незавершённые решения.

Однако Context Audit не является готовой картой бизнес-процесса и не заменяет интервью с участниками. Следующий этап должен соединить найденные цифровые следы с человеческим пониманием работы.

• 1. Изучить результаты Context Audit и понять, какие источники доступны и где обнаружены контекстные разрывы.
• 2. Собрать связанные задачи, документы, изменения в коде и события календаря.
• 3. Отделить подтверждённые факты от гипотез и неизвестных участков.
• 4. Провести адаптивное интервью с участником процесса.
• 5. Сопоставить ответы человека с цифровыми следами.
• 6. Найти задержки, ручные переходы и точки потери контекста.
• 7. Сформировать карту реального workflow с участниками, источниками, решениями и исключениями.
• 8. Спроектировать digital team для подтверждённых задач процесса.
• 9. Подготовить ограниченный пилот с baseline, критериями качества и точками человеческого контроля.

Почему интервью должно быть адаптивным

Участнику процесса не нужен универсальный длинный опросник. Вопросы должны зависеть от уже найденных данных, пробелов и противоречий.

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

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

Что разрабатывает Laplace

Laplace работает над Process Discovery Agent — новым этапом между Context Audit и созданием digital team.

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

Process Discovery Agent планируется использовать для подготовки следующих результатов:

• Подтверждённая данными модель процесса.
• Визуальная карта workflow.
• Список задержек и ручных переходов.
• Перечень неизвестных или недоступных участков.
• AI-возможности внутри процесса.
• Проект цифровой команды.
• План пилота с baseline и критериями успеха.
• Оценка достоверности выводов.

Пример: разработка новой функции

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

Но анализ фактического workflow показывает другую картину:

• Задачи приходят в разработку без критериев приёмки.
• Решения, принятые на встречах, не всегда попадают в Confluence.
• Разработчики повторно уточняют требования у менеджера продукта.
• Pull request не во всех случаях связан с исходной задачей.
• Документация обновляется после релиза или остаётся без изменений.

В предполагаемом сценарии Process Discovery Agent будет сопоставлять задачи Jira, страницы Confluence, изменения GitHub и календарные события. Затем он будет уточнять причины возврата задач, место фиксации решений, правила связи кода с задачами и ответственность за документацию.

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

Как может выглядеть проект digital team

Для такого процесса проект цифровой команды может включать:

• Агента, проверяющего качество постановки задач.
• Агента, собирающего единый контекст по новой функции.
• Цифрового технического редактора.
• Помощника по подготовке релиза.

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

Пилот запускается на одной команде и одном типе workflow. До его начала фиксируются время прохождения задачи, число повторных уточнений, возвратов и отсутствующих связей между задачами, документацией и изменениями. Так компания проверяет не общую способность AI генерировать текст, а влияние digital team на конкретный процесс.

Почему Process Discovery должен показывать unknowns и confidence

Языковая модель способна построить правдоподобное объяснение даже на основании неполных данных. Для исследования бизнес-процесса это опасное свойство.

Если часть workflow не видна в подключённых системах, агент не должен автоматически дорисовывать недостающие этапы. Для каждого значимого вывода важно показывать:

• На каких данных основан вывод.
• Что сообщил участник процесса.
• Какие источники были недоступны.
• Где данные противоречат объяснению.
• Насколько достоверен вывод.
• Какую информацию необходимо проверить вручную.

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

Оценка confidence не должна превращаться в непрозрачное универсальное число. Команде важнее понимать состав доказательств: какие факты подтверждены, какие выводы сделаны на основании интервью и где остаются неизвестные участки.

Как выбрать первый workflow для AI

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

• Процесс регулярно повторяется.
• У него есть конкретное начало и завершение.
• Он проходит через несколько систем или участников.
• В нём есть заметные ручные переходы.
• Результат можно проверить.
• Значимые действия допускают человеческое подтверждение.
• Исходное состояние можно зафиксировать.
• У процесса есть владелец, заинтересованный в улучшении.

Необязательно выбирать процесс с наибольшими затратами. Для первого пилота полезнее workflow, в котором можно быстро проверить гипотезу, обнаружить исключения и сравнить результат с baseline.

Сначала понять работу — затем строить digital team

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

Регламент даёт только предполагаемую схему. Данные рабочих систем показывают отдельные факты. Интервью объясняет причины и исключения. Только их совместный анализ позволяет восстановить процесс и выбрать подходящий сценарий автоматизации.

Частые вопросы

Что такое Process Discovery?

Process Discovery — это восстановление реального бизнес-процесса по данным рабочих систем и объяснениям его участников. Результатом должна стать подтверждённая карта этапов, решений, участников, задержек и неизвестных участков.

Чем Process Discovery отличается от Context Audit?

Context Audit помогает находить проблемы рабочего контекста в доступных источниках. Process Discovery должен идти дальше: сопоставлять цифровые следы с адаптивным интервью и формировать модель конкретного workflow. Process Discovery Agent в Laplace пока находится в разработке.

Почему недостаточно провести интервью с сотрудниками?

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

Как понять, что процесс подходит для AI-автоматизации?

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

Нужно ли сначала описывать процессы всей компании?

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