Русский
Русский
English
Статистика
Реклама

Process mining

Внедрение process mining аудит процессов в два клика

16.04.2021 12:14:51 | Автор: admin

Современные компании активно используют process mining для поиска узких мест в своих бизнес-процессах. У многих из них сформировано понимание ценности этой технологии ее используют для поиска инсайтов в больших массивах информации. Такая аналитика очень актуальна для предприятий, начинающих роботизировать свои процессы. Process mining помогает выявить узкие места автоматизации и связать существующие разрозненные IT-системы в единое целое.

Оптимизация автоматизации

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

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

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

Первые шаги: тестирование и выбор платформы

Для тестирования работы и возможностей process mining лучше выбирать небольшие проекты. При выборе платформы для process mining важно учесть ряд критических факторов: гибкость системы, функциональность, возможность простой интеграции с разными системами и стоимость лицензий. Одним из интересных решений является UiPath Process Mining, в котором есть встроенный модуль ETL, для компаний, только начинающих внедрение process mining, это большое преимущество. Его наличие внутри решения сильно облегчает развертывание в IT-системах.

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

Трудности перевода

При внедрении process mining в работу компании обычно бывает две основных сложности. Первая большие объемы данных, которые нужно анализировать. Вторая долгая автоматизация и наличие большого количества legacy-систем. Обе эти проблемы приводят к тому, что данных внутри компании много, но их невозможно анализировать, потому что они находятся в несвязанных друг с другом системах или представлены большим набором менеджерских дашбордов.

Кроме того сами процессы в компании могут быть устроены очень сложно, хотя

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

Как мы видим процессКак мы видим процессЧто происходит на самом делеЧто происходит на самом деле

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

Как это выглядит цепочка действий в интерфейсе Process MiningКак это выглядит цепочка действий в интерфейсе Process Mining

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

Действия, отфильтрованные по конкретному сотрудникуДействия, отфильтрованные по конкретному сотруднику

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

Подробнее..

Ящики, усы и скрипки

18.12.2020 12:07:33 | Автор: admin


Очень часто данные необходимо сравнивать. Например, у нас есть несколько рядов данных из какой-то области деятельности человека (промышленности, медицины, государственного управления, ), и мы хотим сравнить, насколько они похожи или, наоборот, чем одни показатели выделяются по сравнению с другими. Для простоты восприятия возьмем данные более простые, универсальные и нейтральные высоту в холке и вес нескольких пород собак по сведениям Американского клуба собаководства (American Kennel Club). Данные по размерам пород в среднем можно найти здесь. Прибавим к ним функцию random.uniform из Python-библиотеки numpy, переведем дюймы в сантиметры, а фунты в килограммы, и вот мы получаем реалистично выглядящий набор данных по размерам собак нескольких пород, с которым можно работать. В нашем примере это чихуахуа, бигли, ротвейлеры и английские сеттеры.



Одну из аналитик, которую можно применить для сравнения этих 4 числовых рядов посмотреть на их медиану. Она разбивает ряд данных на две части: половина значений меньше медианы и остальная половина больше. Медианные значения находим, группируя с помощью библиотеки pandas по столбцу Порода и применяя к сгруппированным данным функцию median. Аналогично можно было бы посмотреть и другие статистические показатели: среднее значение (mean) и моду (mode).

Видим, что половина встреченных нами чихуахуа имеет высоту в холке не больше 18 см, бигль значительно выше в районе 41 см, и следующие по размерам ротвейлер и английский сеттер, которые отличаются по росту незначительно: 58 и 63 см.



Рисунок 2. Медианные значения высоты в холке четырех пород собак.
Но только одной медианы недостаточно для сравнительного анализа данных. Можно получить больше информации, если рассмотреть такой инструмент как диаграмма размаха (также известная как ящик с усами, box-and-whiskers plot), построенную с помощью Python-библиотеки для построения графиков seaborn. Линия внутри ящика это уже знакомая нам медиана. Ее уровень на графике справа (см. Рисунок 3) совпадает с высотой соответствующего столбца слева. Но при этом диаграмма размаха содержит дополнительную информацию о том, как данные распределены внутри ряда: нижняя граница прямоугольника (ящика) это первый квартиль (величина, превосходящая 25% значений ряда), а верхняя граница третий квартиль (величина, превосходящая 75% значений). А те самые усы отрезки, отходящие вверх и вниз от середины прямоугольника строятся на основе интерквартильного размаха и обозначают верхнюю и нижнюю границу значимой части наших данных, исключая выбросы. Здесь выбросы отсутствуют (дистрофиков и собак-гигантов нам в рассмотрение не попадалось), при наличии они отобразились бы метками за пределами усов.



Рисунок 3. Сравнение столбчатой и диаграммы размаха, построенных для одного и того же набора данных.
Скрипичный график (violinplot) из той же библиотеки seaborn дает нам еще больше информации о структуре рассматриваемых данных. Ниже на Рисунке 4 представлены все три графика, где породы идут каждый раз в одинаковом порядке, а цвет для соответствующего ряда сохраняется.



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

Сходства и различия диаграммы размаха (ящика с усами) и скрипичного графика показаны на следующем Рисунке 5. Сначала сходства: (1) оба графика в том или ином виде отражают 0.25-квантиль, 0.5-квантиль (медиану) и 0.75-квантиль; (2) и там, и там отражаются крайние значения, которые близки к величине полутора межквартильных интервалов (IQR), отложенных от нижнего и верхнего края коробки те самые усы для диаграммы размаха, за пределами которых находятся выбросы.

Отличие же состоит в том, что скрипичный график содержит также информацию о том, как данные распределены внутри, т.к. границы построенной скрипки это повернутая на 90 градусов плотность распределения. И в этом случае при анализе графика у нас гораздо больше информации: в дополнение к квантилям и значениям, описывающим 4 интерквартильных расстояния (1.5 + 1 + 1.5) на скрипичном графике можно увидеть, распределены ли данные равномерно или есть несколько центров, где значения встречаются более часто.



Рисунок5. Пояснения по соответствию элементов двух графиков: размаха и скрипичного.
Более ярко эту мысль можно увидеть на следующем графике (Рисунок 6), где данные по двум группам ротвейлеров отличаются, но подобраны таким образом, что медианы совпадают (крайний слева график) и даже больше диаграммы размаха (в центре) тоже совпадают! И только скрипичный график (крайний справа) показывает нам, что на самом деле структура данных значительно отличается.



Рисунок 6. Пример, когда только скрипичные график позволяет нам увидеть отличия во внутренней структуре рассматриваемых данных.
Используя кластеризацию К-средних (cluster.KMeans) из модуля sklearn, мы можем визуально представить сгруппированные данные, построив диаграмму разброса с помощью функции scatterplot модуля seaborn. Здесь цвет отделяет один кластер, созданный ML-алгоритмом, от другого, а форма маркера показывает исходную принадлежность к той или иной группе. Понижать размерность с помощью PCA или какого-либо другого метода здесь было не нужно, т.к. данные изначально 2D.



Код для кластеризации и построения диаграммы разброса:




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

Рассказываем про библиотеку для Process Mining теперь SberPM в открытом доступе

27.04.2021 14:21:47 | Автор: admin
Process Mining это подход к извлечению, анализу и оптимизации процессов на основе данных из так называемых журналов событий (event logs), доступных в корпоративных ИТ-системах. Являясь своеобразным мостиком между Data Mining и Process Management, он выводит исследование бизнес-процессов на принципиально новый уровень. Подробнее о том, чем полезен такой подход и как мы его применяем вот здесь .

В конце 2020 года в открытый доступ вышла разработанная Сбером python-библиотека SberPM первая в России мультифункциональная библиотека для интеллектуального анализа процессов и клиентских путей. Ниже про то, как она устроена и как ей пользоваться.

image



DataHolder


Основу для применения Process Mining формируют данные лог-файла, в котором хранится информация о выполненных в рамках одного процесса действиях. Работа с библиотекой начинается с загрузки лога в DataHolder, под капотом которого производится автоматическая предобработка данных удаление нулевых значений, сортировка по времени и т.д. Как следует из названия, DataHolder хранит исследуемые данные с указанием ключевых атрибутов, необходимых для анализа ID (идентификатор события), активности, временные метки начала и/или конца событий. Также для более глубокой и интересной аналитики могут быть добавлены дополнительные атрибуты: ID и роли пользователей, территориальный и продуктовый разрезы, текстовые комментарии и другое.

image

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

image

image

Понятие DataHolder является базовым, поскольку большинство алгоритмов библиотеки работают с экземпляром именно этого класса.

Майнеры, визуализация и BPMN


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

  • SimpleMiner рисует все ребра, найденные в логе;
  • CausalMiner рисует только прямые связи;
  • HeuMiner удаляет наиболее редкие связи в зависимости от порога (threshold) чем он больше, тем меньше ребер на графе;
  • AlphaMiner рисует граф в виде сети Петри с учетом прямых, параллельных и независимых связей между активностями;
  • AlphaPlusMiner Alpha Miner, который может работать с одноцикловыми (one-loop) цепочками.

Визуализировать полученный в результате работы майнера граф процесса можно встроенными средствами Graphiz следующим образом:

image

Можно также сохранить (импорт) или загрузить (экспорт) граф в формате BPMN (Business Process Model Notation):

image

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

image

Итак, CausalMiner позволяет отобразить процесс наиболее линейно, HeuMiner показывает самые частотные цепочки, а AlphaMiner наглядно демонстрирует параллельные участки процесса.

Метрики


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

  1. ActivityMetric метрики по уникальным активностям;
  2. TransitionMetric метрики по уникальным переходам;
  3. IdMetric метрики по ID;
  4. TraceMetric метрики по уникальным цепочкам активностей;
  5. UserMetric метрики по уникальным пользователям;
  6. TokenReplay fitness, который показывает, насколько хорошо граф описывает бизнес-процесс.

В первых пяти случаях для объекта группировки рассчитываются число появлений, число уникальных ID / активностей / пользователей, процент зацикливаний, временные характеристики (средняя, медианная, максимальная и другие виды длительности) и т. д.

Пример работы класса UserMetric:

image

Несомненным преимуществом данного модуля является быстрота расчетов. Допустим, перед аналитиком стоит задача определить среднюю длительность самых частотных цепочек событий процесса. Решение методами pandas займет 5 минут и более 10 строк кода, в то время как решение методами SberPM 1 минуту и 3 строчки кода.

image

Помимо этого, в библиотеке реализована возможность добавить метрики на граф процесса. Сделать это можно следующим образом:

image

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

image

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

Модуль ML


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

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

image

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

image

Для кластеризации предназначен класс GraphClustering. Ниже приведен пример работы с ним:

image

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

image

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

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

image

image

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

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

image

Более подробное описание всех модулей и классов можно найти в файле tutorial.ipynb, расположенном в репозитории библиотеки SberPM на GitHub.

Мы планируем на постоянной основе улучшать библиотеку и дополнять ее функционал. Запланированы релизы для расширения и масштабирования Open Source решения SberPM. Пожалуйста, пользуйтесь, оставляйте обратную связь, добавляйте коммиты и развивайте библиотеку вместе с нами.
Подробнее..

Alpha-miner. Разбор построения модели для Process Mining

22.07.2020 12:20:51 | Автор: admin


Alpha-алгоритм первый в технологии анализа процессов, который позволял находить так называемые Workflow nets из логов процессов. Алгоритм был разработан в 2013 году самим основателем методологии Process Mining профессором Will M.P. van der Aalst.

Что такое Workflow nets (далее WF) это сеть, построенная на основе сетей Petri. Важно, WF на основе сетей Petri позволяет представлять и в дальнейшем анализировать рабочие процессы.

Отличительными чертами WF являются:
  1. Четкое начало. (Уникальное действие, которое только запускает все цепочки действий)
  2. Четкий конец (Уникальное действие, которое только заканчивает все цепочки действий)
  3. Каждое отдельное действие находится между п.1. и п.2.


Давайте посмотрим на пару примеров:





Данные схемы не являются WF. Почему? В первом случае у нас отсутствует начало и конец цепочки (они обозначаются кругом). Во втором случае действие d не имеет окончания.

Ниже я привел пример правильной WF сети есть начало и конец, а все действия расположены между ними и завершены.



Немного прояснив, что такое WF, переходим к работе alpha алгоритма:

Для того, чтобы получить WF с использованием alpha алгоритма, нам потребуется навести порядок в нашем логе. Для этого мы определим следующие отношениями между переходами в логе событий (в дальнейшем они понадобятся для построения модели):

1. Прямая последовательность.
Событие A > Событие B.
В реальном логе событий это выглядело бы так:



2. Причинно-следственная связь.
Событие A Событие B.
Означает, что в логе событий есть такие переходы



Но нет таких:



Следовательно на схеме мы ставим символ



  1. Параллельные события.
    В логе встречаются оба перехода Событие A Событие B и Событие B Событие A.
  2. Отсутствие последовательности.
    Событие A # Событие B и наоборот. Эти события не встречаются в логе.

Общий датасет из всех переходов называется множество L.

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



Напишем связи из нашего лога, которые используются в alpha алгоритме:

  1. Заявка по телефону > Обработка заявки,
    Заявка по телефону > Отправка результата,
    Обработка заявки > Отправка результата,
    Обработка заявки > Завершение заявки,
    Отправка результата > Обработка заявки,
    Отправка результата > Завершение заявки,
    Заявка по почте > Отправка ответа по почте
  2. Заявка по телефону Обработка заявки,
    Заявка по телефону Отправка результата,
    Обработка заявки Завершение заявки,
    Отправка результата Завершение заявки,
    Отправка результата Завершение заявки,
    Заявка по почте Отправка ответа по почте
  3. Обработка заявки || Отправка результата


На основании полученных отношений, рисуем WF.



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

Ограничения работы alpha алгоритма.

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



Ожидаемая модель будет выглядеть так:



Но alpha алгоритм выдаст нам совершенно другую картину:



В чем причина? Действие Обработка заявки не имеет начала и конца. В процессе генерации модели создается множество A (где есть все начала) и множество B (окончания процессов). Так как при многократных повторениях, у нас пропадают данные множества, алгоритм не может их найти. Соответственно данное действие выпадает из общей модели.

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

Как можно решить данную проблему? Нужно максимально учитывать особенности той системы, которую вы анализируете. Если ваша система пишет в лог не только основные моменты, но и действия, которые генерируются автоматически (например, в случаях рукописного ввода, система может каждые 5 секунд делать автосохранение и записывать это в лог), то есть смысл объединять эти действия в один элемент.
Подробнее..

Анализ сетей с использованием графов

25.08.2020 14:18:31 | Автор: admin

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

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


Рис. 1. Направленный граф, изображающий денежный оборот между банками, формирующими валютный рынок (1). Красным отмечены банки ЕС, синим Северной Америки, зелёным других стран.


Рис. 2. Граф, отображающий сотрудничество партнеров по аудиту в Дании в 2010-2014 гг (2)

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

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

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

Теперь попробуем применить анализ социальных сетей на практике. Для этого мы будем использовать язык программирования Python, а точнее библиотеку networkx, предназначенную для работы с графами, библиотеку matplotlib для визуализации и библиотеку community для выделения сообществ внутри сети. Давайте их импортируем:

1.import community2.import networkx as nx3.import matplotlib.cm as cm4.import matplotlib.pyplot as plt

1. Импорт данных и преобразование их в граф

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

1.G = nx.read_edgelist('email-Eu-core.txt', create_using=nx.DiGraph())2.print('Количество вершин: {}'.format(G.number_of_nodes()))3.print('Количество рёбер: {}'.format(G. number_of_edges()))4.print(' Среднее количество соседей у узлов в графе: {}'.format(round(G.number_of_edges() / float(G.number_of_nodes()), 4)))Количество вершин: 1005Количество рёбер: 25571Среднее количество соседей у узлов в графе: 25.4438


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

2. Основные характеристики графов

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

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

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

1.if nx.is_directed(G):2.        if nx.is_weakly_connected(G):3.                print('Граф является направленным и состоит из одной компоненты слабой связности.')4.        else:5.                print('Граф является направленным и состоит из нескольких компонент.')6.else:7.        if nx.is_connected(G):8.                print('Граф является ненаправленным и связным.')9.        else:10.                print('Граф является ненаправленным и состоит из нескольких компонент.')


Граф является направленным и состоит из нескольких компонент.

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

1.G_weak = G.subgraph(max(nx.weakly_connected_components(G), key=len))2.print('Количество вершин: {}'.format(G_weak.number_of_nodes()))3.print('Количество рёбер: {}'.format(G_weak.number_of_edges()))4.print('Среднее количество соседей у узла в графе: {}'.format(round(G_weak.number_of_edges() / float(G_weak.number_of_nodes()), 4)))5.6.G_strong = G.subgraph(max(nx.strongly_connected_components(G), key=len))7.print('Количество вершин: {}'.format(G_strong.number_of_nodes()))8.print('Количество рёбер: {}'.format(G_strong.number_of_edges()))9.print('Среднее количество соседей у узла в графе: {}'.format(round(G_strong.number_of_edges() / float(G_strong.number_of_nodes()), 4)))Количество вершин: 986Количество рёбер: 25552Среднее количество соседей у узла в графе: 25.9148Количество вершин: 803Количество рёбер: 24729Среднее количество соседей у узла в графе: 30.7958


Итак, мы получили основные характеристики для компоненты слабой связности и для входящей в неё компоненты сильной связности. Давайте посмотрим, какие выводы мы можем сделать на этом этапе. Мы видим, что из 1005 участников друг с другом общаются 986 человек, при этом 183 человека из них отправляли электронные письма другим людям в одностороннем порядке, и только 803 человека поддерживали двустороннее общение. В 823 случаях попытка наладить коммуникацию посредством электронной почты оказалась провальной. Также мы видим, что наиболее активные участники (входящие в компоненту сильной связности) поддерживают коммуникацию в среднем с 30 людьми.

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

Кроме того, узлы и связи могут создавать различные типы сетей: однодольные, двудольные или многоуровневые. Однодольные сети состоят из одного типа участников и связей между ними. Двудольные сети состоят из двух разных типов участников, где один из типов узлов связан только с другим типом. Многоуровневые сети также включают два типа участников, однако связи могут соединять как участников разных типов, так и однотипных участников (например, отношения между менеджерами и отношения между проектами). Взятый нами для исследования датасет представляет собой сеть однодольного типа, так как состоит только из одного типа участников и связей между ними.

3. Визуализация графа

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

1.plt.figure(figsize=(15, 15))2.plt.title('E-mails')3.nx.draw(G, node_size=5)4.plt.show()


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


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

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

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


Рис. 4. Компонента сильной связности с информацией обо всех входящих и исходящих электронных сообщениях между членами исследовательского учреждения
4. Степень узла и распределение степеней узлов

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

1.degree = dict(G.degree())2.degree_values = sorted(set(degree.values()))3.hist = [list(degree.values()).count(x) for x in degree_values]4.plt.figure(figsize=(10, 10))5.plt.plot(degree_values, hist, 'ro-')6.plt.legend(['Degree'])7.plt.xlabel('Degree')8.plt.ylabel('Number of nodes')9.plt.show()



Рис. 5. Распределение степеней в графе с информацией обо всех входящих и исходящих электронных сообщениях между членами исследовательского учреждения

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

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

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

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

1.print ('Диаметр: ', nx.diameter(G_strong))2.print ('Среднее расстояние в компоненте сильной связности: ', nx.average_shortest_path_length(G_strong))3.print ('Среднее расстояние в компоненте слабой связности: ', nx.average_shortest_path_length(G_weak))Диаметр: 6Среднее расстояние в компоненте сильной связности:  2.5474824768713336Среднее расстояние в компоненте слабой связности:  2.164486568301397


Давайте разберём полученные результаты. Диаметр в данном случае показывает нам максимальное расстояние между двумя незнакомыми людьми, и здесь, как и в известной теории о шести рукопожатиях, это расстояние равно 6. Среднее расстояние в компонентах также невелико, в среднем двум незнакомым людям достаточно 2 рукопожатий. Здесь можно также увидеть интересный феномен: среднее расстояние в компоненте сильной связности несколько ниже, чем в компоненте слабой связности. Объяснить это можно тем, что для компоненты слабой связности не учитывается направленность связей (только сам факт её наличия). Из-за этого связь в слабой компоненте появляется там, где она отсутствовала для сильной компоненты.

6. Кластеризация и выделение сообществ

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

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

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

Посмотрим на кластеризацию и кластерный коэффициент для компоненты слабой связности:

1.print ('Кластеризация: ', nx.transitivity(G_strong))2.print ('Кластерный коэффициент: ', nx.average_clustering(G_strong))Кластеризация:  0.2201493109315837Кластерный коэффициент:  0.37270757578876434


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

1.print ('Кластеризация: ', nx.transitivity(G_strong))2.print ('Кластерный коэффициент: ', nx.average_clustering(G_strong))3.print ('Количество центральных узлов: ', len(nx.center(G_strong)))4.print ('Количество узлов на периферии: ', len(nx.periphery(G_strong)))Кластеризация:  0.2328022090200813Кластерный коэффициент:  0.3905903756516427Количество центральных узлов: 46Количество узлов на периферии: 3


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

1.G_undirected = G_weak.to_undirected()2.partition = community.best_partition(G_undirected)3.communities = set(partition.values())4.communities_dict = {c: [k for k, v in partition.items() if v == c] for c in communities}5.highest_degree = {k: sorted(v, key=lambda x: G.degree(x))[-5:] for k, v in communities_dict.items()}6.print('Количество сообществ: ', len(highest_degree))7.print('Количество элементов в выделенных сообществах:', ', '.join([str(len(highest_degree[key])) for key in highest_degree]))Количество сообществ: 8Количество элементов в выделенных сообществах: 113, 114, 125, 131, 169, 188, 54, 92


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

1.pos = nx.spring_layout(G)2.plt.figure(figsize=(15, 15))3.cmap = cm.get_cmap('gist_rainbow', max(partition.values()) + 1)4.nx.draw_networkx_nodes(G, pos, partition.keys(), node_size=20, cmap=cmap, node_color=list(partition.values()))5.nx.draw_networkx_edges(G, pos, alpha=0.5)6.plt.show()



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

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

7. Взаимность связей

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

1.print ('Уровень взаимности графа: ', nx.overall_reciprocity(G))2.print ('Уровень взаимности компоненты слабой связности: ', nx.overall_reciprocity(G_weak))3.print ('Уровень взаимности компоненты сильной связности: ', nx.overall_reciprocity(G_strong))Уровень взаимности графа:  0.6933635759258535Уровень взаимности компоненты слабой связности:  0.6938791484032562Уровень взаимности компоненты сильной связности:  0.7169719762222492


В 71% случаев в компоненте сильной связности пользователи получали ответы на свои сообщения. Для компоненты слабой связности и всего графа в целом уровень предсказуемо ниже.

8. Универсальные свойства сетей

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

  1. Распределение степеней узлов. Во всех сетях есть много узлов с низкой степенью, в то же время есть небольшое количество огромных узлов, у которых соседей очень много. Это логично: если мы посмотрим на ссылки между различными web-сайтами, то обнаружим, что существует небольшое количество крупных сайтов, на которые в большом количестве ссылаются все остальные (Wikipedia, Microsoft). В то же время на среднестатистические сайты ссылки встречаются гораздо реже, хотя большинство сайтов относятся именно к такому типу.
  2. Диаметр и среднее расстояние в графе. Крупные сети имеют такое устройство, что средний диаметр у них очень небольшой, это явление в анализе социальных сетей называется явлением малого мира. Оно хорошо описывается через теорию шести рукопожатий: несмотря на огромное количество людей, среднее расстояние между двумя незнакомыми людьми будет равным шести.
  3. В больших сетях, как правило, присутствуют гигантские связные компоненты: более 80% узлов связаны между собой, остальные представлены более мелкими компонентами. При этом в каждой из крупных компонент можно встретить сообщества группы объектов, которые связаны между собой теснее, чем с остальным графом. Наличие кластеризации, то есть большого количества таких сообществ, чрезвычайно распространено в социальных графах.
  4. Во многих социальных графах действует принцип взаимности, когда при наличии исходящей связи очень высока вероятность встретить и входящую связь. Эта концепция специфична для направленных сетей, поскольку взаимность и обмен являются фундаментальными социальными процессами.


Все перечисленные выше тенденции мы разобрали и подтвердили для датасета с электронной перепиской: в графе обнаружилась большая связная компонента, содержащая более 80% всех узлов. Внутри этой компоненты большинство узлов характеризовалось небольшим количеством, однако существовал небольшой процент участников, у которых количество соседей было огромно. Также мы увидели, что диаметр и среднее расстояние между участниками графа небольшое: среднее расстояние в компоненте слабой связности, содержащей 986 участников, составило всего 2.1, что означает, что большинство участников связаны друг с другом всего через два рукопожатия. Кроме того, граф характеризуется высокой степенью взаимности: 69% всех участников поддерживали двусторонний контакт между собой.

Примечания:

С полным текстом исследования можно ознакомиться в книге Николая Викторовича Урсул Вся правда о Forex (2019).
Исследование описано в статье The Application of Social Network Analysis to Accounting and Auditing Slobodan Kacanski, Dean Lusher (2017, ссылка).
Подробнее..

Перевод Мониторинг и управление потоком задач в рамках взаимодействия микросервисов

14.01.2021 14:20:31 | Автор: admin


Ключевые тезисы:

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


В 2018-м я встретил архитектора из большой интернет-компании. Он рассказал мне, что они следуют всем правильным рекомендациям, и внутри различных областей делят функциональность на маленькие фрагменты, хотя и не называют этот архитектурный стиль микросервисами. Затем мы поговорили о том, как эти сервисы взаимодействуют друг с другом ради поддержания бизнес-логики, выходящей за границы сервисов, потому что именно здесь теория проверяется практикой. Он сказал, что их сервисы взаимодействуют с помощью событий, публикуемых в шине такой подход называют хореографией (ниже я расскажу о нём подробнее). В компании это считают оптимальным с точки зрения уменьшения связанности. Но они столкнулись с проблемой: трудно разобраться в том, что происходит в системе, а изменить её ещё труднее. Это не тот срежиссированный танец, который вы видите на презентациях, посвящённых микросервисам, это неуправляемые прыжки в стиле пого!

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


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


Хореографируемый поток событий.

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


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

Потеря прозрачности потока событий


Я хочу сосредоточиться на вопросе, возникающем чаще всего, когда я участвую в обсуждениях этой архитектуры: Как избежать потери прозрачности (и, вероятно, контроля) потока событий? В одном из исследований сотрудники Camunda (где я работаю) спрашивали об использовании микросервисов. 92 % респондентов как минимум рассматривали их, а 64 % уже использовали в том или ином виде. Это уже не хайп. Но в том исследовании мы также спрашивали и о трудностях, и получили чёткое подтверждение наших опасений: чаще всего нам говорили о потере сквозной прозрачности бизнес-процессов, задействующих многочисленные сервисы.


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

Обеспечение прозрачности


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

  1. Распределённая трассировка (например, Zipkin или Jaeger).
  2. Озёра данных или аналитические инструменты (например, Elastic).
  3. Контроль и анализ процессов (process mining) (например, ProM).
  4. Отслеживание с помощью автоматизации потоков задач (например, Camunda).

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

Распределённая трассировка


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


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

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

  • В трассировке трудно разобраться неспециалистам. Все мои попытки показать трассировки людям, далёким от техники, с треском провалились. Оказалось гораздо лучше потратить время на перерисовку той же информации в виде блоков и стрелок. И даже если вся эта информация о вызовах методов и сообщениях очень полезна для понимания схем взаимодействия, она оказывается слишком подробна для понимания ситуации с межсервисными бизнес-процессами.
  • Для управления избыточным объёмом подробных данных в распределённой трассировке применяется так называемое сэмплирование. Это означает, что собирается лишь небольшая доля запросов, и обычно больше 90 % всех запросов вообще не регистрируется. Об этом хорошо написано в статье Three Pillars with Zero Answers towards a New Scorecard for Observability. Так что у вас никогда не будет полной картины происходящего.

Озёра данных или аналитические инструменты


Итак, сама по себе трассировка вряд ли нам подходит. Логично будет обратиться к схожему подходу, но с учётом нашей конкретной задачи. Обычно это означает сбор не трассировок, а важных бизнес- или тематических событий, с которым вы, возможно, уже и так сталкивались. Часто решение сводится к созданию сервиса, который слушает все события и сохраняет их в базе, что может повышать нагрузку на систему. Сегодня многие используют для этого Elastic.


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


Пример интерфейса мониторинга событий.

К недостаткам можно отнести отсутствие графиков, облегчающих работу со списком событий. Но вы можете добавить их в инфраструктуру, скажем, проецируя события в средство визуализации вроде BPMN. Небольшие фреймворки наподобие bpmn.io позволяют добавлять информацию в диаграммы, выводимые в виде простых HTML-страниц (пример), которые можно запаковать в Kibana плагин.


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

Инструменты для контроля и анализа процессов (process mining)


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

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


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


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

Отслеживание с помощью автоматизации потоков задач


Другой интересный подход моделирование потоков задач с последующим развёртыванием и исполнением посредством модуля управления. Эта модель особенная в том смысле, что она только отслеживает события, а сама ничего активно не делает. То есть ничем не управляет только регистрирует. Я рассказывал об этом на Kafka Summit San Francisco 2018, используя для демонстрации Apache Kafka и open source-модуль управления рабочими процессами Zeebe.


Эта возможность особенно интересна. В сфере модулей управления немало инноваций, что приводит к появлению инструментов, которые компактны, удобны для разработки и высокомасштабируемы. Я писал об этом в статье Events, Flows and Long-Running Services: A Modern Approach to Workflow Automation. К очевидным недостаткам относится необходимость предварительного моделирования потока задач. Но зато эту модель можно исполнять с помощью модуля управления процессами, в отличие от мониторинга событий. По сути, вы запускаете экземпляры процессов для входящих событий или соотносите события с каким-либо экземпляром. Также это позволяет проверить, соответствует ли реальность вашей модели.

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


Пример мониторинга потока задач.

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

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

Перспективы для бизнеса


Доступность бизнес-процессов для мониторинга позволяет вам понимать контекст. Вы можете посмотреть для конкретного экземпляра, как, когда и в каком состоянии он завершился. А значит, вы можете понять, по какому пути этот процесс не пошел (а другие часто по нему проходят), и какие события или данные привели к определённым решениям. Также вы сможете понять, что способно произойти в ближайшем будущем. Другие виды мониторинга этого не позволяют. И хотя сегодня зачастую не принято обсуждать проблему согласованности между бизнесом и ИТ, совершенно необходимо, чтобы неспециалисты тоже могли разобраться в бизнес-процессах и в том, как события проходят через разные микросервисы.

От отслеживания к управлению


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

Например, вы можете начать с мониторинга таймаутов в сквозных процессах. Когда происходит таймаут, автоматически выполняется некое действие. В примере ниже, спустя 14 дней мы уведомим клиента о задержке, но всё ещё будем ждать. А через 21 день отменим заказ.


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

Оркестрация


Я часто слышу, что нужно избегать оркестрации, поскольку она приводит к связанности или нарушает автономность отдельных микросервисов, и конечно, её можно плохо реализовать. Но можно реализовать и так, чтобы оркестрация соответствовала принципам микросервисов и приносила бизнесу большую пользу. Я подробно говорил об этом на InfoQ New York 2018.

Для меня оркестрация означает, что один сервис может скомандовать другому что-то сделать. И всё. Это не тесная связанность, а связанность иного рода. Вспомним наш пример с заказом. Может оказаться целесообразным, чтобы кассовый сервис всего лишь генерировал заказ и клал его в шину событий, не зная, кто его обработает. Сервис заказов подхватывает событие о появившемся заказе. Получатель узнаёт о событии и решает что-нибудь сделать в связи с этим. То есть связанность присутствует на стороне получателя.

С оплатой ситуация иная, поскольку довольно странно, если платёжный сервис будет знать, за что получена оплата. Но ему понадобится это знание, чтобы среагировать на правильные события вроде размещения или создания заказа. Также это означает, сервис придётся менять каждый раз, когда вы хотите получать платежи за новые продукты или услуги. Во многих проектах эту неприятную связанность обходят за счёт генерирования необходимых событий о платежах, но это не события, поскольку отправитель хочет, чтобы кто-то что-нибудь сделал в связи с этим. Это команда! Сервис заказов командует платёжному сервису получить деньги. В этом случае отправитель знает, какую команду отправить, и делает это, то есть связанность присутствует на стороне отправителя.

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


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

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


Заключение


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

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

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

Как с помощью UiPath внедрить process mining в компании

31.12.2020 18:20:33 | Автор: admin

Вызовы цифровой трансформации


image

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

  1. Обнаружить проблему
  2. Внедрить изменения
  3. Отслеживать решение
  4. Реагировать на отклонения

На данный момент популярным решением для внедрения изменений является инструмент RPA, который позволяет автоматизировать рутинные действия пользователей. Что касается трех остальных пунктов для этого понадобится process mining или интеллектуальный анализ бизнес-процессов.

Интеллектуальный анализ бизнес-процессов (Process Mining) фокусируется на обнаружении, анализе и оптимизации бизнес-процессов на основе данных из журналов событий (англ. event logs), представляя недостающее звено между классическим анализом бизнес-процессов с использованием их моделей и интеллектуальным анализом данных.

Инструмент process mining позволяет захватить реальные данные из популярных ERP-, CRM-систем и баз данных сквозных бизнес-процессов в закупках, финансах, управлении претензиями, контакт-центрах и т.д. (SAP, Oracle, Salesforce, ServiceNow), визуализировать их для обнаружения узких мест, неэффективности использования ресурсов и исключений; и, наконец, мониторить изменения в процессе после его оптимизации, в том числе с помощью автоматизации.

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

image
Фото с ресурса: http://personeltest.ru/aways/habr.com/ru/post/257563/

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

Кейсы process mining и автоматизации


Аудит и улучшение существующих метрик


Крупная пенсионная, страховая и управляющая компания в Нидерландах нуждалась в более глубоком понимании автоматизации своих контакт-центров, чтобы понять ее влияние на свои бизнес-процессы. Компания развернула UiPath Process Mining, провела сквозную аналитику контакт-центра и выявила проблемы, которые приводили к дополнительной работе и длительному времени ожидания клиентов на линии.

На основе инсайтов UiPath Process Mining компания скорректировала автоматизацию контакт-центра. Это повысило качество и скорость связи с клиентами, а также позволило сильно сократить время ожидания клиентом оператора. В целом оказалось, что 80% всех работ можно было стандартизировать, и за счет этого снизить затраты контакт-центров на 568 тыс. евро.

Поддержка оперативных решений


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

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

Data mining и глубокое понимание процессов


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

Крупной телеком-компании из Нидерландов требовалось повысить прозрачность своих корпоративных закупок. Имея 6,3 миллиона абонентов фиксированной телефонной связи, более 33 миллионов абонентов мобильной связи и более 2 миллионов интернет-клиентов в пяти странах, они хотели найти решение для контроля рисков и определения путей снижения затрат.

Оператор развернул UiPath Process Mining для получения информации
и устранения интуитивной оценки процессов, а также ручной передачи данных. Он использовал UiPath Process Mining для оценки более чем 200 000 различных позиций, в том числе заказов на покупку и счета-фактуры.

В результате удалось сократить на 20% трудовые затраты, на 29% уменьшить время на обработку счетов-фактур, а также повысить предсказуемость затрат и улучшить отношения с поставщиками.

Опыт заказчиков


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

Екатерина Сабельникова, консультант по инновациям Philips рассказывает в своем блоге на LinkedIn о главных уроках, извлеченных при использовании process mining в компании.

Сфокусироваться на главном

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

Определить заинтересованных лиц

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

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

Обеспечить поддержку и одобрение высшего руководства

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

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

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

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

Как и у любой системы, у process mining существует ряд ограничений:

  • Адекватность отображения хода реального бизнес-процесса данными логов информационной системы;
  • Необходимость интерпретации результатов анализа.

С этими ограничениями мы столкнемся на практике, когда далее на примере UiPath Process Mining будем разбирать весь процесс внедрения аналитики бизнес процессов в организацию.

image
UiPath process mining помогает принимать основанные на фактах рекомендации для улучшения критических процессов

Гайд по развертыванию UiPath Process Mining


Формируем журнал событий

Для создания журнала событий необходимо определить источники данных для него, как правило их бывает не более 2-3. Даже если у компании есть SAP в UiPath и свой ETL, в реальном мире этим не даст воспользоваться принятая в компании стратегия интеграции и наличие КХД/КШД/DataLake или иных решений, которые управляют потоками данных.

Исходные данные получаем из хранилища данных или реплик БД и принятыми в компании средствами ETL, затем собираем/упрощаем их и помещаем в staging area для UiPath. UIPath может брать данные из любой реляционной БД, у которой есть ODBC драйвер. Затем уже из staging таблиц мы собираем журнал событий, с которым будут работать сами алгоритмы UiPath.

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

Проводим сборку журнала событий

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

Важно понимать, что некорректно выбранный состав шагов и уровень детализации процесса не даст решить задачи анализа или поддержки решений. И еще 100% цифровизации процесса нет нигде. Значит часть шагов, которые в процессе есть, вы не отразите в журнале. Если помнить, что вы решаете задачи увеличения показателей, а не получения красивой картинки это не страшно. А если не помнить, то можно решить, что process mining бесполезное внедрение.

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

Конфигурируем Process Mining UiPath

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

Важно отметить что у UiPath есть очень полезная функция анонимизации. Которая, например, контрагента Лучшая компания" во всех местах меняет на Контрагент 1. Это можно, конечно, сделать и руками создав временную таблицу справочник или написав очень хитрый запрос, но времени такая фича экономит много. Вообще деперсонализация результатов очень важная вещь, если вы анализируете процессы, отвечающие за финансовые потоки. Может оказаться, что бизнес-аналитику нельзя видеть коммерческую тайну, но для анализа она важна. Вот тут и помогает анонимизация.

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

Проводим аналитику отчетов

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


Создаем дашборды

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

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

Настраиваем оперативный контроль

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

Результат работы функции можно использовать в дашбордах чтобы метить подозрительные случаи или отсылать в UiPath Action Center, чтобы там записать процедуру по ее устранению. Кстати, так же работает и интеграция с ML можно вызывать программы на R или Python, передавая им на вход данные и записывая результаты работы.

Как видите, работа тут всегда итерационная. Это плохо при планировании и оценке объема работ, потому что нельзя точно оценить потребуется ли еще одна итерация или нет. Но это не свойство UiPath это свойство всех подобного рода продуктов. Это хорошо тем, что появляется возможность делать то, что реально надо и чем будут пользоваться, а не то что зафиксировали в требованиях до начала работ.

Здесь есть техническая проблема как организовать верстанный контроль. Тут у UiPath с самого начала все правильно: конфигурация настроек и дашбордов живет в git. Можно в локальном, можно в корпоративном, можно хоть на gituhub. В других решениях где-то версионности вообще нет (например, конфигурация модели данных), а где-то она достигается старым добрым способом допиши дату или номер версии в название файла. Технически очень много головной боли при наличии верстанного контроля уходит и длительность спринта сокращается.

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

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

Корпорация Everest Group ежегодно оценивает вендоров технологий process mining на основе их влияния на рынок, видения и возможностей их продуктов. В последнем исследовании 2020 года UiPath признали лидером в сфере process mining среди других крупнейших вендоров.

image

Выводы


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

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

Как в enterprise при помощи R применять технологии process mining?

03.11.2020 00:14:12 | Автор: admin

Как-то так получилось, что в 2020 году возник всплеск интереса к тематике Process Mining. Не исключено, что новая реальность удаленного режима потребовала более пристальной оценки эффективности технологических и бизнес-процессов. Это же как с кривыми и косыми деревянными рамами. Сквозит из всех щелей, а счетчик накручивает мегаватты на обогрев.


В целом, видны несколько популярных запросов по применению технологии process mining:


  • хочется что-то улучшить, но кроме модного слова больше ничего не слышали;
  • получить или сэкономить живые деньги путем оптимизации классического процесса order-to-cash и ему подобных;
  • системный аудит всего и вся собственной командой аудиторов;
  • построение операционной аналитики и мониторинга на основе показателей процессов, а не ИТ метрик.

В 99% случаев начинают читать Gartner/Forrester и попадают на 4-ку вендоров (Celonis/Minit/Software AG/UiPath), которые как-то присутствуют в России. И до того, как начать получать какую-либо выгоду, тут же получают немаленький ценник за лицензии и последующую ежегодную поддержку. При этом экономическое обоснование шито белыми нитками.


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


Является продолжением предыдущих публикаций.


Преамбула


Так ли уж технологии process mining недоступны простым смертным и все страшно и дорого?
Нет, нет и еще раз нет. 90% задач в продуктиве и 100% задач на исследовательском этапе могут быть закрыты open-source инструментами. Экосистема R позволяет их решать практически в полном объеме. Причем даже аудиторы и сотрудники HR службы могут освоить инструменты и эффективно их применять в своей повседневной деятельности. Что уж говорить о разработчиках и аналитиках.


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


Ниже несколько аргументов и иллюстраций в стиле беседа в лифте от 1-го до 30-го этажа, как именно используется R для применения технологий process mining во внутренних службах аудита бизнес-процессов.


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


Актуальность


В задачах аудита бизнес-процессов, как правило, требуется выполнение следующих требований:


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

Типичный сценарий проведения аудита процессов выглядит следующим образом:



Задача аудита по своей сути является разовой и уникальной. Новые источники данных, новая постановка задачи, новые инсайты. Практика показала, что использование коробочных process-mining решений для задач аудита не имеет особых преимуществ перед способами анализа процессов средствами data-science стека.


Основные причины кроются в том, что:


  • решениям требуется лог событий в жестко заданном формате, ETL нужно делать где-нибудь вовне;
  • парадигма проведения аналитики только мышкой заканчивается на 2-м или 3-м шаге, когда все равно требуется открывать капот и программировать сложные метрики и сложные формулы на встроенном вендоро-зависимом языке;
  • аналитика мышкой требует проведения стека ручных операций при повторных вычислениях;
  • лицензии стоят очень дорого.

Альтернативный вариант


Задача process-mining по своей сути ничем не отличается от классических задач анализа данных. Для ее решения можно успешно использовать стек data science инструментов, в частности, стек, построенный open-source на экосистеме R Tidyverse. Сам инструмент обладает широким спектром возможностей, доступ к которым появляется при подключении тех или иных open-source пакетов. Пакетов на настоящий момент существует более 10 тысяч, они активно развиваются. Но, поскольку задача process-mining достаточно ограничена, далее мы будем упоминать только пакеты, которые будут часто использоваться в задачах process mining office (PMO).


Обзор технических возможностей и способов решения типовых операций в контексте PMO будет подкрепляться компактными фрагментами кода. Важно учитывать, что в data science принято придерживаться концепции воспроизводимых вычислений, т.е. применение технологий и методологий по автоматическому (скрипт) получению идентичных результатов, выполняемых на разными людьми на разных машинах в разное время.


Важно то, что в задаче process-mining программирования не избежать в принципе, как бы этого ни хотелось. В случае с data science стеком это совершенно не критично, поскольку для аналитических кейсов PMO конструкции языка общего назначения R и пакетов tidyverse максимально приближены к человеческому языку и набор типовых операций ничуть не сложнее работы в Excel.


Краткое резюме по применению R для задач process mining:


  • дешево (open-source);
  • быстро (как время работы аналитика, так и время вычислений);
  • компактно (данные в 10-100 млн строк можно крутить на обычном ноутбуке);
  • воспроизводимо (все действия описываются в виде кода, поддерживается методология воспроизводимых вычислений);
  • функционально (в целом, экосистема R содержит > 10 тыс. пакетов, включая импорт/экспорт, процессинг, алгоритмы, визуализацию, разработку web АРМ, ...).

Импорт данных


Импорт из csv, команда и получаемая таблица:


df <- read_csv("./data/pmo/pmo_sales.csv")df


Импорт из xlsx, команда и получаемая таблица:


df <- read_excel("./data/pmo/pmo_sales.xlsx", sheet = "Данные здесь")df


Импорт данных из БД: MS SQL, PostgreS, Oracle, MySQL, Access, Redis, Clickhouse, Детально можно прочесть "Databases using R" (https://db.rstudio.com/)


Преобразование данных


Самые базовые действия (глаголы) на примере данных о продажах. Детально можно ознакомиться здесь:



Глагол mutate создание колонки.


df <- read_csv("./data/pmo/pmo_sales.csv") %>%  # считаем выручку по позициям  mutate(amount = unitprice * weight)df

Глагол group_by группировка по колонкам, глагол summarise расчет подытога.


# считаем выручку по товарамdf %>%   group_by(item) %>%  summarise(sum(weight), sum(amount))

Глагол select выбор и переименование колонок.


df %>%  select("Дата" = date, "Выручка, руб" = amount, item)

Глагол filter выбор строк по условию.


df %>%  filter(amount > 1000, item == "Арбуз")

Глагол arrange сортировка строк по колонкам.


df %>%  arrange(date, desc(amount))

Пример форматного вывода в отчет


df %>%   group_by(item) %>%  gt(rowname_col = "date")


Посмотрим графически на продажи


gp <- ggplot(df, aes(date, amount, color = item, fill = item)) +  geom_point(size = 4, shape = 19, alpha = 0.7) +  geom_line(lwd = 1.1) +  scale_x_date(date_breaks = "1 day", date_minor_breaks = "1 day", date_labels = "%d") +  scale_y_continuous(breaks = scales::pretty_breaks(10)) +  ggthemes::scale_color_tableau() +  ggthemes::scale_fill_tableau() +  theme_bw()gp


А можно разложить по фасетам


gp + facet_wrap(~item) + geom_area(alpha = 0.3)


Примеры преобразований на основе лога событий


Импорт лога


df <- read_csv("./data/pmo/pmo_school.csv")df


В ходе анализа решили сформировать новое поле активности на основе activity и resourse и посчитать число вхождений


df %>%   mutate(new_activity = glue("{activity} - {resource}")) %>%  count(new_activity, sort = TRUE)


Какая активность была последней и в какой час она происходила?


df %>%  mutate(hr = hour(timestamp), date = as_date(timestamp)) %>%  group_by(date) %>%  # оставляем самое последнее действие  filter(timestamp == max(timestamp)) %>%  ungroup() %>%  select(date, hr, everything(), -timestamp, -part)


Пример построения DWG графа с применением функций пакета bupaR (https://www.bupar.net)


Событийный лог взаимодействия с пациентами.


patients

Карта процесса


patients %>%    process_map()


Метрики производительности процесса


patients %>%    process_map(performance(median, "days"))


P.S.


  1. Приведенные методы являются, естественно, существеным упрощением полной теории. Но это упрощение вызвано простой самих процессов в enterprise. Классический бизнес даже близко не приближается к сложности коллайдера.
  2. Небольшой демонстрационный код по этой тематике был опубликован ранее, Бизнес-процессы в enterprise компаниях: домыслы и реальность. Проливаем свет с помощью R
  3. Для более детального погружения в тематику process mining даю отсылку к отправной точке, труду Wil M. P. van der Aalst Process Mining: Data Science in Action. Лекции, статьи, книги и т.д. можно далее искать самостоятельно, если тема заинтересует.

Предыдущая публикация Пакеты-пакеты-пакеты Насколько эффективно вы используете R?.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru