Майнинг процессов перед автоматизацией хаотичных передач

Что идёт не так, когда передачи накапливаются

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

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

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

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

Эта скрытая работа и делает картирование бизнес‑процессов сложнее, чем кажется. Официальный процесс может говорить «отправить, проверить, утвердить». Реальный процесс чаще ближе к «отправить, исправить недостающие поля, переслать по email, ждать финансы, напомнить финансам в чате, обновить таблицу, затем утвердить». Если смотреть только на формальную схему, вы пропустите ту часть, которая съедает время.

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

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

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

Что показывает майнинг процессов

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

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

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

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

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

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

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

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

Какие данные собирать в первую очередь

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

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

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

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

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

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

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

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

Сначала держите чистые данные системы отдельно от человеческих догадок. Если кто‑то говорит: «Мы обычно отправляем в юридический отдел после этого», относите это как заметку, а не как событие. Постройте первую карту только на зафиксированных фактах. Потом сравните карту с тем, что люди думают, что происходит. Разрыв между этими двумя просмотрами часто и есть причина задержки.

Как шаг за шагом картировать работу

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

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

Вытяните выборку событий из каждой системы, которая касается этого потока. Не нужен идеальный data warehouse для старта. Несколько сотен кейсов из вашего тикет‑инструмента, ERP, CRM, системы email‑утверждений или экспортированных таблиц часто достаточно.

Для каждого события собирайте одинаковые поля: ID кейса или запроса, название события, дату и время, человека или команду, которая это сделала, и статус или результат.

Приведите имена в порядок до анализа. Если в одной системе «approved», в другой «ok», в третьей «manager signoff», объедините их в одну метку, если они означают одно и то же. Этот небольшой шаг очистки предотвратит много путаницы.

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

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

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

Затем сравните карту с тем, как менеджеры думают, что работает процесс. Менеджеры обычно описывают предполагаемый «хэппи‑пасс». Логи событий показывают распространённый путь.

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

Простой пример: от запроса до утверждения

Команда может считать, что медленное выставление счетов — проблема. Логи событий часто показывают другое.

Клиент просит коммерацию в понедельник в 9:12. Продажи создают её в 9:25, операции проверяют наличие в 10:03, финансы утверждают цену в 10:18. На бумаге это выглядит быстро. Но предложение затем лежит без движения 19 часов, прежде чем продажи отправят его клиенту на следующее утро. Клиент принимает в течение двух часов, так что внешняя задержка не проблема.

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

Простая карта процесса может показать только четыре шага:

• Создано предложение
• Утверждение предложения
• Выписан счёт
• Получен платёж

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

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

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

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

Ошибки, которые ведут команды не в ту сторону

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

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

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

Пара предупреждающих знаков обычно означает, что картина слишком аккуратна:

• Петли переработки почти не видны
• Ручные исправления происходят вне отслеживаемой системы
• Одно среднее время скрывает огромные вариации
• Отчёты теряют отменённые или повторно открытые кейсы
• Срочные случаи пропускают шаги и исчезают с основного пути

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

Легко обвинить софт во всех задержках. Некоторые задержки вызваны политикой, staffing, расписанием или мотивацией. Менеджер может утверждать только дважды в неделю. Клиент может прислать недостающие документы поздно. Две команды могут иметь разные определения «готово». Никакой сценарий это не исправит.

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

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

Быстрые проверки перед автоматизацией

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

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

• Где начинается кейс и где он явно заканчивается?
• Можно ли проследить один кейс через инструменты по общему ID, номеру заказа или номеру тикета?
• Где работа сидит дольше всего?
• Какие две самые распространённые петли?
• Первый плохой шаг — стоит ли его удалить, упростить или автоматизировать?

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

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

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

Что делать дальше с тем, что вы нашли

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

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

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

Ваш черновик должен содержать четыре вещи:

• Что запускает работу
• Кто обрабатывает её дальше
• Где работа может приостановиться или вернуться
• Что считается завершением

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

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

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

Если выводы указывают на крупный редизайн, внешний специалист может сэкономить недели проб и ошибок. Oleg Sotnikov at oleg.is работает как Fractional CTO и советник стартапов, и такого рода обзор процессов естественно вписывается в более широкую работу по автоматизации и внедрению AI.

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