На всякий случай, если кто-то впервые сталкивается с этим термином, "Process Mining" — это метод анализа хода процесса, который наравне с более привычным интервьюированием и работой с документами позволяет улучшить бизнес-процессы и повысить производительность труда. Технология забирает данные о действиях пользователей из информационных систем, таких как ERP, MES, CRM, чтобы на их основе понять, как особенности отдельных действий влияют на показатели работы компании.

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

• Каждое из подразделений может воспринимать границы одного и того же процесса по-разному. Например, для департамента закупок процесс годового планирования/бюджетирования состоит из многих шагов, а для инициатора закупки (например, механический цех) — это всего 2-3 шага, которые сильно разнесены по времени (специалист сделал запрос, а согласовали через пару месяцев).
• Все бизнес-процессы обычно иерархичны и формально, как сквозные (например, производство "под заказ" может начинаться с визита клиента в офис и включать производство, логистику и финансовые расчеты), так и локальные процессы (например, выдача справки по НДФЛ по запросу сотрудника) могут быть выбрать для анализа.

В практике RAMAX Group мы обычно используем два подхода:

• Работа со сквозными процессами (снабжение - от запроса до поставки, ТОИР- от планирования до выполнения планово-предупредительных работ и т.д.).
• Работа с локальными процессами в рамках подразделения или на третьем уровне процессной модели (работа от проекта договора до его согласования/подписания, проведение платежа - от заявки до сверки с банковской выпиской, приемка товара - от разгрузки до размещения в месте хранения и оформления в ERP).

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

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

Реальность сквозных процессов

Данный вид процессов хорош тем, что его легче соотнести с финансовыми показателями работы компании, что позволит проще рассчитать экономический эффект от его оптимизации. Более того, сквозной процесс чаще всего влияет на фундаментальные вещи, например, кассовый разрыв, размер неликвидных складских остатков, оборачиваемость запасов готовой продукции, конверсия при массовых продажах, NPS (качество клиентского обслуживания) и подобное. То есть эффект от оптимизации такого процесса даже для среднего бизнеса будет в денежном эквиваленте достаточно большим.

Но масштаб сквозного процесса означает долгий срок выполнения проекта по его анализу, потому что:

• в большинстве ERP (включая западные) данные будут храниться разрозненно (в 90% это данные будут находиться не только в ERP, но и в других ИС), и их придется собирать в единый журнал событий;
• иногда нельзя проследить «путь» одной заявки/договора/обращения сквозь весь процесс, так как некоторые связи просто могут оказаться не оцифрованными;
• после сбора журнала событий можно столкнуться с ситуаций, когда большое количество уникальных шагов (100-200) сделает практически невозможным анализ, и придется упрощать модель процесса, группируя шаги в более крупные, тем самым повышая риск потерь потенциальных областей улучшения;
• из-за того, что в сквозном процессе участвуют много подразделений с собственными задачами и взглядом на ход процесса (а иногда и с несовместимыми формулами расчета эффективности их работы), такой анализ несет много организационных сложностей как на этапе подготовки данных, так и во время защиты результатов;
• изменения, направленные на оптимизацию процессов, будут чаще всего сравнимы по масштабам с объектом анализа – то есть будут затрагивать несколько подразделений, и реализация таких изменений сама по себе станет непростым процессом;
• трудоемкость такой работы тоже достаточно велика, например, типовой проект анализа процесса снабжения, от заявки до поставки МТЦ инициатору, займет около 9 месяцев и задействует команду в 3-4 человека.

В чем суть локальных процессов

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

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

• Работа с локальными процессами так же не лишена и своих трудностей. Локальный процесс очень сложно монетизировать, если только через сокращение трудозатрат, что сразу создает деликатную ситуацию, т.к. высвобождающиеся ресурсы надо или привлечь к другой деятельности, или сократить.
• Зачастую эффект будет качественным, а не монетизируемым, и даже если и таким, то заметными суммы экономии станут только после того, как мы проанализируем с десяток таких процессов.
• Иногда найденные проблемы будут «одноразовыми» - будучи выявленными один раз они могут быть скорректированы и уже не требовать постоянного мониторинга (потребность в дальнейшем применении инструмента исчезнет).
• Источники неэффективности часто находятся на «границе ответственности» двух подразделений. Если процесс изначально заявлен как локальный, исправить это без привлечения «смежников» не получится.
• Часто анализ процесса может показать, что «все и так хорошо» - к этому надо быть готовым.
• Очень часто локальные процессы включают множество ручных шагов, которые не подлежат цифровизации (общение по телефону, физическое перемещение объектов, работа с бумажными документами), и могут быть непригодны для анализа.
• Трудоемкость анализа меньше, чем при работе со сквозным процессом (1-2 человека способны сделать анализ за месяц). Но так как таких процессов много, то экономически эффективно будет сформировать свой центр компетенции, а не привлекать консультантов, что само по себе является непростой задачей.

Какой же из подходов является правильным? Как практически и везде – гибридный, все зависит от обстоятельств. Для большего понимания вот несколько апробированных на практике сценариев развития:

• Если начинаем «с нуля» и на уровне высшего руководство декларирована готовность меняться, то лучше всего взять сквозной процесс, важность которого не вызывает ни у кого сомнений (в 90% случаев это или «снабжение» или «ТОиР, включая МТО»), привлечь консультанта и за счет работы в смешанной команде начать формировать свой центр компетенции. Такой подход позволяет окупить первоначальные инвестиции (в лицензии на ПО, консультантов) за счет эффектов от предложенных изменений. Анализ сквозного процесса проходит на достаточно высоком уровне, формируя потребность детального анализа локальных «подпроцессов» в ходе проекта. Возможно, собственная команда даже успеет проанализировать проблемный локальный процесс до конца большого проекта.
• Если начинаем «с нуля» и при этом достаточно опыта других компаний, чтобы обосновать закупку лицензий и старт таких проектов, то можно начинать с анализа локальных процессов, про которые уже известно, что они нуждаются в оптимизации. Это быстрее даст результат и появится больше шансов, что внедрение предложенных изменений произойдёт в том же году, что и анализ, и на выходе мы получим понятный результат от инвестиций. Привлечение консультанта точно необходимо для формирования центра компетенции, но изначально можно рассчитывать, что порядка 50% работ совершит собственная команда, и дальнейшее масштабирование на все предприятие будет уже осуществляться собственными силами. В этом случае высокоуровневый анализ сквозных процессов станет во вторую очередь после того, как потенциал локальных улучшений процесса будет исчерпан или в рамках локального анализа станет ясно, что все проблемы на границах между локальными процессами.
• Если в компании уже есть сильная команда, занимающаяся совершенствованием процессной модели, есть инициатива к переходу к модели «data driven company» или команда, которая отвечает за «бережливое производств», то можно рассматривать Process Mining, именно, как инструмент. Мы не ищем процессы для анализа, а изначально планируем анализ всех оцифрованных процессов в рамках общей инициативы по повышению операционной эффективность. В этом случае стоит задача максимального сокращения цикла анализа конкретного процесса при сохранении достоверности результатов. Здесь «узким местом» становятся данные –неэффективно под каждый процесс собирать свои журналы событий, так как данные разных процессов пересекаются в значительной мере. Таким образом, важным становится консалтинг в области каталогизации данных автоматизированного контроля их качества.

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