1. Постановка задачи
На этапе постановки задачи необходимо четко обозначить объект и цель последующего исследования:
- Определить границы процесса, как операционные (какое действие или событие является началом процесса, а какое – окончанием), так и временные (период для выгрузки)
- Сформулировать ожидания от анализа, по возможности гипотезы, которые необходимо проверить
- Сформировать команду исследования
- Идентифицировать все необходимые источники данных
Чтобы определить, подходит ли процесс для анализа методами Process Mining, а также выбрать из нескольких процессов и верно расставить приоритеты в анализе, стоит руководствоваться тремя правилами.
1. Процесс проходит в информационной системе, и действия пользователей оставляют цифровые следы (логи). Чем более подробно и близко к практике логируется бизнес-процесс, тем лучше он подходит для анализа (пример: картинка сверху).
Если действия пользователей не оставляют следов либо детализация фиксируемых событий недостаточна, можно доработать информационную систему для записи более подробных логов или же использовать стороннее ПО, позволяющее зафиксировать все действия сотрудника с экрана ПК (например, агент логирования от Сбера).
2. Процесс достаточно массовый, исполняется регулярно, ежедневно. Чем больше данных будет собрано по нему, чем больше экземпляров осуществляется за рассматриваемый период времени — тем более точными и объективными будут результаты анализа.
3. Есть понимание цели исследования и полномочия по внесению изменений в процесс.
Понимание цели и четко сформулированные задачи позволят корректно собрать данные для анализа и получить прикладные выводы, полезные для бизнеса.
Привлечение в команду исследования владельцев процессов, имеющих полномочия для изменений, даст возможность обратить выводы в реальные действия и потенциально — финансовые выгоды.
1. Процесс проходит в информационной системе, и действия пользователей оставляют цифровые следы (логи). Чем более подробно и близко к практике логируется бизнес-процесс, тем лучше он подходит для анализа (пример: картинка сверху).
Если действия пользователей не оставляют следов либо детализация фиксируемых событий недостаточна, можно доработать информационную систему для записи более подробных логов или же использовать стороннее ПО, позволяющее зафиксировать все действия сотрудника с экрана ПК (например, агент логирования от Сбера).
2. Процесс достаточно массовый, исполняется регулярно, ежедневно. Чем больше данных будет собрано по нему, чем больше экземпляров осуществляется за рассматриваемый период времени — тем более точными и объективными будут результаты анализа.
3. Есть понимание цели исследования и полномочия по внесению изменений в процесс.
Понимание цели и четко сформулированные задачи позволят корректно собрать данные для анализа и получить прикладные выводы, полезные для бизнеса.
Привлечение в команду исследования владельцев процессов, имеющих полномочия для изменений, даст возможность обратить выводы в реальные действия и потенциально — финансовые выгоды.
На этапе подготовки к исследованию необходимо как можно подробнее описать объект анализа (процесс и определение экземпляра процесса), сформулировать первоначальные гипотезы и цели анализа. Это позволит провести анализ быстрее и получить релевантные результаты.
Гипотезы, сформулированные на первом этапе, могут трансформироваться и пополняться в ходе анализа, по мере накопления знаний о реальном протекании процесса. Но четко сформулированная и согласованная всеми участниками цель исследования поможет не отвлекаться на проработку нецелевых предположений и гипотез.
Гипотезы, сформулированные на первом этапе, могут трансформироваться и пополняться в ходе анализа, по мере накопления знаний о реальном протекании процесса. Но четко сформулированная и согласованная всеми участниками цель исследования поможет не отвлекаться на проработку нецелевых предположений и гипотез.
Команда проекта формируется исходя из индивидуальных потребностей каждого исследования. Стандартная команда включает 5 ролей.
В зависимости от целей конкретного исследования, некоторые роли могу совмещаться или исключаться. Например, владелец процесса может сам взять на себя роль эксперта; аналитик PM может сам иметь доступ к логам наиболее стандартных информационных систем и выполнять роль эксперта по ИТ-системам; а специалист Data Science может не понадобиться, т.к. команда не нуждается в разработке специализированных инструментов и может проводить анализ на базе стандартного функционала имеющихся инструментов.
В зависимости от целей конкретного исследования, некоторые роли могу совмещаться или исключаться. Например, владелец процесса может сам взять на себя роль эксперта; аналитик PM может сам иметь доступ к логам наиболее стандартных информационных систем и выполнять роль эксперта по ИТ-системам; а специалист Data Science может не понадобиться, т.к. команда не нуждается в разработке специализированных инструментов и может проводить анализ на базе стандартного функционала имеющихся инструментов.
Пример
В качестве примера, на котором мы будем рассматривать все дальнейшие этапы проекта, возьмем процесс продажи нефинансового продукта в подразделениях банка.
A. Все действия сотрудников проходят в единой системе, что обеспечивает наличие логов, единообразие протекания процесса независимо от подразделения и сотрудника, а также возможность проследить каждый экземпляр процесса (в нашем случае контакт с клиентом) от начала и до конца благодаря сквозному идентификатору.
B. Процесс массовый — по данным информационных систем ежедневно десятки (в некоторые периоды сотни) клиентов обращались в отделения банка для приобретения продукта.
C. Владелец процесса в самом начале проекта обозначил цель — повысить конверсию. На момент старта проекта конверсия, согласно статистическим данным, составляла 27%.
Изначально поставленная владельцем процесса цель — повышение конверсии, требует уточнения и детализации. Конверсия в 27% была рассчитана на основании данных из информационных систем за январь — июнь 2020 года о количестве контактов с клиентом (2240) и количестве реальных продаж продукта (616).
A. Все действия сотрудников проходят в единой системе, что обеспечивает наличие логов, единообразие протекания процесса независимо от подразделения и сотрудника, а также возможность проследить каждый экземпляр процесса (в нашем случае контакт с клиентом) от начала и до конца благодаря сквозному идентификатору.
B. Процесс массовый — по данным информационных систем ежедневно десятки (в некоторые периоды сотни) клиентов обращались в отделения банка для приобретения продукта.
C. Владелец процесса в самом начале проекта обозначил цель — повысить конверсию. На момент старта проекта конверсия, согласно статистическим данным, составляла 27%.
Изначально поставленная владельцем процесса цель — повышение конверсии, требует уточнения и детализации. Конверсия в 27% была рассчитана на основании данных из информационных систем за январь — июнь 2020 года о количестве контактов с клиентом (2240) и количестве реальных продаж продукта (616).
- В рамках первой встречи рабочей группы были сформулированы названные ниже предложения и гипотезы для дальнейшей проверки.
- Конверсия рассчитана некорректно, т. к. данные, полученные из системы, могли быть модифицированы или просто некорректно обработаны.
- Не все сотрудники в отделениях следуют процедурам и скриптам продаж. Действует человеческий фактор, некоторые сотрудники могут быть недостаточно обучены из-за текучки персонала.
- Есть подразделения и отдельные сотрудники, которые справляются со своими задачами лучше других. Необходимо найти такие примеры, выявить лучшие практики и модифицировать процесс с учетом этой информации.