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

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

Здесь может помочь следующее действие – разработка возможности ведения подобного журнала в legacy-системе. Как это сделать?

PMS, или система управления отелем (гостиницей)

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

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

Здесь process mining будет использован для исследования фактических процессов резервирования и выставления счетов. Но есть проблема: на данный момент система не создает журналов событий. Все, что есть – это код на C# и модель данных в БД SQL. 

Шаг 1: создание статической модели

Создание нужного “журнала”, который будет использован в процессной аналитике, начинается с БД SQL, где собраны все данные в так называемую модель данных (data model). Она включает таблицы, отношения, поля и типы полей. Все это может быть извлечено из базы данных в виде SQL-схемы, которая преобразуется в объекты с атрибутами и отношениями. Например, у клиента есть имя, фамилия и бронирование со дня въезда до дня отъезда.

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

Шаг 2: создание динамической модели

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

Для этого мы исследуем исходный код, чтобы включить ведение журнала выполнения программы при стандартном использовании приложения. В результате манипуляций создается журнал, из которого генерируются диаграммы последовательностей UML. Теперь эти диаграммы последовательностей описывают поток методов, вызываемых в каждом объекте. Эта «динамическая модель» – не бизнес-процесс, а последовательность методов, связанных с одним вариантом использования.

Шаг 3: расширение динамической модели

Для начала использования инструментов process mining необходимы:

• case id – идентификатор процесса;
• activity – событие или действие.

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

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

Шаг 4: преобразование, сборка, развертывание и запуск

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

Итого мы получаем приложение, к которому “добавлена” возможность ведения журнала события. Он запускается в момент развертывания “модифицированной” версии системы. Таким образом, можно исследовать любые сценарии использования PMS.

Шаг 5: анализ данных журнала

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

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

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

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

По материалам Fluxicon