Бизнес-процессы можно описывать разными способами: UML, классическим BPMN, S-BPM и другими нотациями.
BPMN самый распространенный вариант. Но мне больше нравится субъектно-ориентированный подход — S-BPM.
В нем процесс строится вокруг субъектов. Субъектом может быть человек, система или ИИ-агент.
У каждого субъекта есть свое поведение, а между собой они обмениваются артефактами.
Такой подход с одной стороны, простой, а с другой — хорошо переносится на архитектуру мультиагентной системы.
Но в целом я бы не зацикливался на конкретной нотации.
Главное, чтобы вы могли прочитать схему, бизнес понимал, что на ней происходит, а инженер мог на ее основе построить работающую систему.
Гораздо важнее понять, соответствует ли эта схема реальности.
Интервью здесь полезны, но, как мы знаем, люди часто лгут. Причем иногда даже не специально.
Поэтому я рекомендую дополнять интервью Process Mining.
В Сбере мы использовали для этого самописный инструмент, но я бы рекомендовал открытую библиотеку PM4Py. С помощью ИИ сегодня можно легко разобраться и с самой библиотекой, и с тем, как запускать анализ.
Идея Process Mining в том, что информационные системы оставляют цифровой след, и по нему можно восстановить то, как процесс действительно проходил.
Для этого нужен журнал событий минимум с тремя полями:
• Case ID — конкретный экземпляр процесса: заявка, заказ, сделка.
• Activity — какое действие произошло.
• Timestamp — когда оно произошло.
• Дополнительно полезен Resource — кто выполнил действие: человек, система или агент.
Но на практике самая трудозатратная часть Process Mining в подготовке данных.
Информационные системы почти никогда не хранят события сразу в нужном формате.
Например, Jira может хранить историю изменения задачи примерно так:
`issue = DATA-4712`
`field = status`
`from = In Progress`
`to = Review`
`author = Andre`
`created = 14:42`
А Process Mining хотелось бы получить:
`case_id = DATA-4712`
`activity = Sent to Review`
`timestamp = 14:42`
`resource = Andre`
То есть сначала нужно понять схему данных системы, а потом смапить их в стандартный лог событий.
И здесь сделать полностью универсальный инструмент довольно сложно.
У Jira один формат. У CRM другой. У ERP третий. У внутренней самописной системы четвертый.
Поэтому универсальным может быть сам движок Process Mining, но не слой извлечения данных из любой системы.
Зато здесь очень хорошо помогает ИИ.
Можно взять небольшой сэмпл реальных данных, показать его ИИ и попросить написать скрипт на питоне, который преобразует исходные поля в нужный формат.
После этого проверить несколько кейсов вручную, убедиться, что события интерпретированы правильно, и только потом прогонять весь массив через PM4Py.
После подготовки лога событий можно восстановить честную карту процесса.
В интервью вам расскажут одно, а на деле часть кейсов могут возвращаться назад, часть проходит через другие подразделения, а некоторые несколько дней ждут согласований.
И здесь мы уже смотрим не на представление человека о процессе, а на цифровой след того, что действительно происходило в системе.
Можно находить возвраты, петли, задержки, обходные маршруты, расхождения с регламентом и аномальное поведение.
Поэтому Process Mining используют не только для оптимизации процессов, но и коллеги из кибербезопасности.
Но полностью заменять интервью данными тоже нельзя.
Process Mining хорошо показывает, что произошло, но далеко не всегда объясняет, почему.
По журналу видно, что заявка трижды вернулась назад. А сотрудник может объяснить, что данные приходят из другой системы в неправильном формате и их приходится исправлять вручную.
Поэтому я бы всегда сочетал несколько источников.
Люди дают контекст. Данные дают факты.
Интервью показывает, как человек понимает процесс. Process Mining показывает цифровой след того, что реально происходило.
И только их комбинация позволяет собрать действительно честную AS-IS модель.
В следующей статье разберем как найти точки автоматизации с максимальной отдачей.
👉 Полная статья
