Process mining = автоматический анализ процессов

05.03.2017

Автор: Валентин Рагозин

1. Как восстановить ход процесса?

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

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

К счастью, для решения задач измерения и воссоздания реального хода бизнес-процессов и поиска проблем в системах автоматизированного workflow есть специализированные инструменты. Они появились на рынке относительно недавно на волне зарождения нового направление в анализе — Process Mining. Суть данного аналитического метода состоит в построении точной модели реальных бизнес-процессов компании на основании транзакционных данных из автоматизированных информационных систем. В качестве исходных данных можно также использовать логи или журналы движения таких объектов, как заказы, наряды, заявки, кейсы, трабл-тикеты, инциденты, документы, договоры, поручения и пр.

Одним из аналитических процессных инструментов является продукт финской компании QPR Software — QPR Process Analyzer (далее — просто Analyzer). О том, что он из себя представляет и каких результатов позволяет достичь, я опишу в данной статье.

Для целей понимания данной статьи следует уяснить пару важных моментов из области процессного дизайна:

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

2. Варианты поставки и особенности использования Analyzer

Прежде всего стоит отметить, что Analyzer имеет 2 версии:

1. Standalone версия в виде надстройки в Excel. Позволяет производить работу с данными в привычном для многих пользователей Excel. При этом аналитик может работать как с данными непосредственно в файле , так и подключаться к СУБД , где лежат данные по процессу. Коллективная работа с данными не поддерживается. Размер СУБД ограничен 10Gb, СУБД входит в комплект поставки.
2. Серверная версия. Серверная версия Analyzer поддерживает работу нескольких пользователей и работает только с данными в СУБД (MS SQL или Oracle приобретается отдельно). С серверной версией может работать 2 типа клиентских приложений:

2.1 Excel со встроенной в него специальной надстройкой.

2.2 Веб клиент (браузер).

Обе версии клиентского приложения можно использовать одновременно.

Дополнительно QPR предлагает аренду Analyzer в облаке, что может быть очень удобно в случае ограниченного бюджета, сжатых сроков проекта или для выполнения временных/пилотных аналитических работ или изысканий. По сути, облачная версия — это та же серверная версия, но установленная на ресурсах вендора (QPR) и переданная Заказчику во временное пользование.

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

• опытные аналитики проводят сложный анализ первичных данных и с помощью функционала многочисленных фильтров и сортировок находят основные проблемы в процессе и участки их локализации;
• потребители аналитических данных по процессу (например, владельцы процесса или участники процесса) получают доступ к этим данным через Web-клиент и на их основании могут построить дополнительные срезы или выделить интересующие их детали.

Отчасти такое разделение труда вызвано соображениями производительности, которые нельзя не принять во внимание, когда объемы процессных данных составляют несколько гигабайт и даже десятки гигабайт. Проводить первичную диагностику процесса на таком объеме может быть очень затратно по времени. Аналитики, работающие с Excel-клиентом, могут, а порой даже вынуждены (!) ограничивать размеры процессной выборки при первичном анализе для того, чтобы выявить проблемные области/участки в процессе. И когда проблемы локализованы и параметризированы, то найденный аналитический шаблон (срез, точка зрения, набор фильтров) можно уже применять для полного массива процессных данных.

При таком подходе к анализу ключевой проблемой самого анализа является sampling или формирование представительного и минимального набора процессных данных по первичному гигантскому массиву логов или транзакций. QPR Process Analyzer содержит такой алгоритм! Согласно этому алгоритму отбираются данные из большого массива данных таким образом, чтобы на базе небольшой выборки показать/выявить общий проблемный тренд анализируемого процесса, имеющий место быть во всём первичном массиве данных. То есть, например, у вас в базе данных содержится 1 миллион объектов (заказов, кейсов, инцидентов, заявок, договоров, проводок), а вы задали ограничение в 10 тысяч. Analyzer подберет данные из всей базы данных таким образом, чтобы показать общий тренд для всей базы, а не только для первых 10 тысяч. Таким образом, можно утверждать, то, что верно для 10 тысяч объектов, на 95 % справедливо и для миллиона объектов.

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

Какой объем данных брать решает аналитик. На мой взгляд брать большее 20 % от исходного массива для первичного анализа не имеет смысла. Однако все зависит от объема данных и конкретного видения аналитика.

3. Формат исходных данных

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

Минимальная информация, которую нужно подать на вход QPR Analyzer, представляет из себя следующее:

ID объекта	Произошедшее событие	Временная метка события

Так, например, данные могут выглядеть следующим образом:

Этой минимальной информации достаточно, чтобы воссоздать бизнес-процесс и построить диаграмму шагов бизнес-процесса. Описание диаграммы бизнес-процесса приведено в разделе 4.

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

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

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

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

Process Analyzer позволяет загрузить от 50 до 300 статических атрибутов, в зависимости от типа лицензии.

4. Flowchart view

Диаграмма бизнес процесса — это базовое и самое первое представление, которое формируется в Process Analyzer. Данное представление отображает бизнес-процесс по загруженным данным как есть, со всеми его ветвлениями и петлями. Пример диаграммы бизнес-процесса можно увидеть на рисунке 1.

Рис. 1 Пример диаграммы бизнес-процесса

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

1. Максимальную цепочку шагов до завершения процесса
2. Циклы и повторы шагов бизнес-процесса
3. Возможные варианты перехода от шага к шагу
4. Среднее время между шагами бизнес-процесса
5. Частоту прохождения через шаги бизнес-процесса

Также диаграмма бизнес-процесса показывает среднее время прохождения объекта (заказа, заявки, договора, инцидента и т.п.) по всему маршруту, что дает дополнительную информацию для анализа. Однако, для анализа временных затрат существует более специфический инструмент — Duration view, речь о котором пойдет чуть ниже.

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

Рис.2. Сравнительный анализ вариантов/сценариев бизнес-процесса по атрибутам объектов

Например, сравнение может быть выполнено в контексте оказываемых услуг (рис. 3)

Рис.3. Сравнение вариантов процесса: продажа оборудования физическим или юридическим лицам.

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

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

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

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

Рис.4 Управление объемом выборки

Объем выборки указывается в процентах, чем выше число, тем меньше уникальных ситуаций (сценариев процесса) попадает в выборку. На примере на рис.4. в выборку попадут только те сценарии (маршруты workflow), которые статистически набирают хотя бы 5% от общего объема случившихся в процессе сценариев/маршрутов, то есть на диаграмме бизнес-процесса не будут отображаться те сценарии/участки бизнес-процесса, по которым шла обработка 5% и менее от всего объема объектов.

5. Path view

Я уже использовал словосочетание бизнес-сценарий (или просто сценарий) и даже дал его определение в начале, но думаю, что всё же нужны дополнительные пояснения. Бизнес-процесс представляет из себя большое разнообразие условий и вытекающих из них веток, потому объекты бизнес-процесса могут пройти различными путями (маршрутами), чтобы в конечном итоге достигнуть результата. Каждый отдельный маршрут будет выглядеть линейно и его можно рассматривать как бизнес-сценарий. Т.е. путь=маршрут=сценарий — это конкретный набор шагов бизнес-процесса, случившихся в определенной последовательности.

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

Для анализа бизнес-сценариев в Analyzer существует представление Path View или как еще его можно назвать: диаграмма сценариев бизнес-процесса (см. рис.5).

Рис.5 Пример анализа сценариев

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

6. Influence view

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

Рис.6 Пример анализа влияния

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

В качестве входных данных для примера анализа влияния я выбрал один из нестандартных бизнес сценариев из Path Analysis. Целью моего исследования является выяснение причины возникновения такого сценария. Рисунок 6 показывает какие атрибуты процесса оказали влияние на попадание объектов в выбранный бизнес-сценарий и какой вес этого влияния.

Из приведенного примера видно, что из 58 тысяч объектов 44801 удовлетворяют условию, т.е. так или иначе проходили выбранный бизнес сценарий. Наибольшее влияние оказали объекты, у которых канал поступления запроса был «Сайт», таких объектов 5106, что составляет 11 % от всех объектов, удовлетворяющих условиям выборки.

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

7. Filters

Как правило, для работы Analyzer выгружается большой объем данных и работать с ним трудно. Для того, чтобы помочь аналитику сфокусироваться на интересующих его данных, существует функционал фильтров рис. 7

Рис.7 Функционал фильтров

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

При этом настройки фильтров можно сохранять и применять их для разных представлений и данных. Например, я создал фильтр, показывающий только те объекты, время обработки в которых было свыше 4 дней. Этот же фильтр я могу использовать как для Path analysis, так и вместе с функционалом Benchmark.

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

8. Duration view

Анализ длительности — наиболее типовое и понятное всем представление — см. рис. 8

Рис. 8 Анализ длительности работы над объектами

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

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

Выбрав интересующую(ие) строку(и) можно построить любое другое представление, будь то анализ бизнес-процесса, анализ сценариев или анализ влияния.

9. Прочие представления

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

1. Profiling view — представляет из себя круговую диаграмму, которая строится на основании параметров объектов. Выбирая те или иные параметры объектов, вы будете видеть «пирог», отражающий распределение по количеству объектов с данным атрибутом.
2. Variations — представляет из себя гистограмму, отображающую шаги бизнес-сценария в текстовом виде. Шаги разделяются знаками #. и имеют вид #.Создано обращение..Обращение закрыто.#. При этом Analyzer выводит данные о количестве раз исполнения этих бизнес-сценариев. Представление таких данных в виде таблицы бывает полезно для количественного анализа.
3. Events — представляет из себя список событий для выбранных элементов (например, для конкретного бизнес сценария или для объектов с определенным значением атрибута). Если вы используете клиентское приложение в виде Excel и задали стоимость каждого действия над объектом, то с помощью сводной таблицы весьма удобно построить отчет, отражающий распределение затрат по шагам процесса.
4. Event types — представляет из себя отчет по всем типам событий для выбранных элементов представления (будь то шаги бизнес процесса, атрибуты объектов или временные метки) с указанием количества раз, когда это событие было зафиксировано. При этом в отчете фигурируют 2 характеристики: общее количество и уникальное количество раз. Важно понимать, что один и тот же объект мог проходить через один и тот же шаг процесса более одного раза.
5. Flows — анализ процессов, представляет те же данные что и диаграмма процессов, только в табличном виде. Это дает возможность детального количественного сравнения между процессами и предоставляет данные для дальнейшей цифровой обработки.
6. Cases — это представление выводит информацию по всем объектам, попавшим в выборку. Это бывает полезно для формирования задачи на выгрузку нужных атрибутов или формирования отчета для принятия корректирующих действий. Например, с помощью Analyzer вы смогли найти некоторые проблемы в бизнес-процессе, но выбранные атрибуты не дают точного представления о проблеме. Для того, чтобы разобраться, что же произошло и какие атрибуты объектов требуется взять, нужно обратится к системе-источнику. Для этого вам потребуются идентификаторы объектов из системы-источника. Если же проблему удалось идентифицировать, то для принятия корректирующих действий это представление можно использовать как отчетную форму.

10. Заключение

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

Хочется отметить, что несмотря на простоту использования инструмента, его применение потребует серьезной аналитической работы. Наибольшую трудоемкость имеет подготовка исходных транзакционных данных или логов по процессу к загрузке в Analyzer. Для выполнения этой работы потребуется глубокое изучение модели данных исследуемой системы и бизнес-логики, заложенной в нее на системном уровне. Так, например, первый вопрос, который встает перед аналитиком, что считать бизнес-действием или шагом процесса? Полное определение действия зачастую размыто между тем, что произошло (объект направлен в очередь) и тем, кто назначен на обработку объекта в очереди (департамент продаж). Таким образом, в приведенном примере для получения понятной картины бизнес-процесса нужно склеить 2 этих факта, чтобы получить требуемый результат, который будет выглядеть вот так: «Объект направлен в очередь Департамента Продаж».

Следующим возникает вопрос об атрибутивном описании происходящего: что за объект? какой у него номер? кто его создал? кто в департаменте продаж с ним работал? и так далее. Потому для подготовки данных к загрузке потребуются силы бизнес и системных аналитиков. Т.к. первые знают процесс, понимают бизнес-логику и цели, которые требуется достичь, но не понимают реализацию всего этого в системе. Системные аналитики напротив понимают реализацию, но не осознают бизнес- логику.

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

Узнать больше об Analyzer можно на сайте производителя.

Список статей