BPMN-модель как основа для реализации процессов в СИЭР. Часть 1

#Уголок_профессора

Часть 1. Создание событийной модели

Магия BPM-движка

Данная статья обращена к широкому кругу читателей: заказчикам, молодым IT-специалистам, студентам, коллегам и представителям других проектных команд, которым важно понимать принципы работы с такими компонентами, как BPM-движки, BPMS и, главным образом, СИЭР (системой исполнения электронных регламентов), имеющей BPM-движок. Мы поделимся своей рабочей практикой и компетенциями в этой области, расскажем об используемых нами платформах и инструментах.

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

Концепция процессного подхода к управлению (BPM — Business Process Management) сейчас весьма популярна. Она применяется в организациях всех типов, обсуждается в бизнес- и ИТ-сообществах, завоёвывает всё новых сторонников.

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

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

Помочь реализовать преимущества процессного подхода удобным и безболезненным образом призваны BPMS-системы и другие low-code решения, имеющие “под капотом” BPM-движок. Неудивительно, что они продолжают множиться и развиваться, предоставляя современному потребителю разнообразие продуктов и их версий.

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

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

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

Границы применимости

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

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

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

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

• Чем больше процессов автоматизируем, чем выше их уникальность, чем чаще возможны перестроения, тем больше пригодится BPMS / BPM-ный low-code.
• В то же время, в любой компании существуют и стандартизированные бизнес-процессы, не требующие индивидуальной разработки или глубокой кастомизации, в таких случаях не нужно конструировать личный процессный “велосипед”. Например, для взаимодействия с клиентами можно использовать готовые специализированные CRM-решения, а для задач налогового учета существует 1С; гипотетическая прибыль в случае создания более оптимального процесса своими руками незначительна по сравнению с необходимыми вложениями на изыскания, разработку и внедрение. При этом следующим этапом зрелости ИТ-инфраструктуры в таком случае все равно может оказаться BPM-движок, дополняющий “коробки”, оркестрируя, например, интеграционные фрагменты вокруг них.

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

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

В итоге требования экономности и гибкой настройки процессов обусловили встраивание BPM-компонента в архитектуру СИЭР^* — программной платформы, лежащей в основе, в частности, федеральной государственной информационной системы «Единая система предоставления государственных и муниципальных услуг (сервисов)» (ФГИС ПГС^**).

^*СИЭР — система исполнения электронных регламентов, она позволяет автоматизировать бизнес-процессы реализации государственных и муниципальных функций и услуг, а также может использоваться в корпоративных информационных системах. Правообладателем программной платформы «СИЭР» является компания «Эволента».

^**ФГИС ПГС — это система автоматизации административно-управленческих процессов предоставления государственных и муниципальных услуг и внутриведомственных административных процессов, которая, являясь «backend`ом» Госуслуг, реализует процессы рассмотрения заявлений.

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

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

Ключ к эффективности BPM-технологии и её реализация в СИЭР

Использовать BPM-технологию эффективно — реализовывать её преимущества и обходить недостатки — нам помогает знание её особенностей, а также архитектуры, в которую она встроена. Поэтому расскажем, что происходит «внутри» исполнения BPMN-модели.

Сначала аналитик выгружает на сервер подготовленную BPMN-схему (деплоит в одно нажатие новый алгоритм). Она описывает в понятном для системы стандарте логику нормативно-правовых актов — порядок переходов между исполнителями и доступные им действия, места запуска автоматизирующих сервисов и прочее. Данное описание имеет, согласно расширению .bpmn, сразу два представления — графическое, необходимое для визуального конструирования, и текстовое, содержащее то же описание процесса, но в виде XML, перечисляющего процессные элементы с их свойствами.

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

Как это работает?

До преобразований XML-текст лишь описывает, что должно происходить, но не содержит конкретного исполняемого кода, в то время как обычный программный алгоритм на языке Java содержал бы исходный код (саму Java-программу) и машинный код (результат компиляции в инструкции процессора) — инструкции для JVM и процессора, соответственно.

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

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

Таким образом, модель процесса ещё при загрузке парсится в Java-объекты, которыми затем управляет уже скомпилированный Java-код движка. Движок умеет работать по модели объектов, он, выполняя шаг процесса (например, фиксируя событие), вызывает соответствующий метод Java-объекта. Затем JVM интерпретирует и/или JIT-компилирует байт-код в машинный, а тот выполняется сервером.

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

Преимущества технологии

В связи с вышеизложенным отметим следующие преимущества:

• Полуавтоматизированный переход от описания и согласования бизнес-логики к реализации и исполнению, что позволяет экономить время и деньги. Исключаем этап «перевода» бизнес-требований, представленных описательными моделями, в постановку разработчикам, вместо этого насыщаем свойства элементов модели дополнительными техническими параметрами, а сам «перевод» выполняется автоматизированно.
• Гибкость и стабильность — при соответствующей инфраструктуре можно менять процесс без деплоя кода и остановок системы, не затрагивая остальной код.
• Универсальность и масштабируемость — один движок может работать со множеством разных процессов, просто читая разные файлы; несколько движков могут работать параллельно, деля между собой одновременную нагрузку.
• Снижение сложности миграции процессов — за счет стандартизированности нотации BPMN 2.0 при смене заточенных под неё инструментов снижаются трудозатраты на доработки.

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

Так как изменение одного процесса — это редактирование конкретного файла BPMN-схемы, изолированного от остальных процессов и функций системы, снижается риск поломок смежных сервисов, а также упрощается откат изменений процесса. Так, обновление стандарта оказания одной из государственных услуг обычно не влияет на работоспособность в тот же момент сотен и даже тысяч других услуг, оказываемых тысячами пользователей в едином контуре. Это огромное преимущество, которое трудно переоценить. Отдельно отметим архитектурное следствие вынесения оркестрации в отдельный компонент, благодаря чему достигается его изоляция и защита от внешних воздействий. Компонент с процессной логикой проще выделить как критический узел и окружить защитными слоями, что в СИЭР реализовано следующим образом: между движком и обвязкой, отвечающей за остальную бизнес-логику, обмен данными выполняется через доверенный контур (интеграционный сервис); движок не принимает внешние запросы напрямую, а делает это только через единый вход. Например, если пользователь принимает документы от заявителя и запускает дело в работу, он посылает запрос на бизнесовый модуль, который в свою очередь вызывает интеграционный сервис, тот обогащает запрос и исключительно сам передает его движку, управляя содержанием. Такой контроль доступа уменьшает возможную поверхность атаки. А очереди и другие интеграционные механизмы вокруг движка позволяют повысить устойчивость к сбоям и всплескам нагрузки, сохраняя её управляемость.

Недостатки технологии

Конечно, имеются и свои недостатки.

Во-первых, существует опасность фокуса на применении типичных функций, а не индивидуальных запросах заказчика. Имея выраженные ограничения инструментария (не нотации, но реализации бизнесовой обвязки под предметную область), аналитик начинает мыслить над процессом заказчика с точки зрения применимости к нему типичных конструкций и их связок — их действительно стоит использовать, чтобы не напороться на необходимость hard-code доработки. Однако, чтобы исходить из потребностей бизнеса, а не только своих привычек, стоит следить за обновлениями платформы и изучать их; не бояться узнавать для себя новые «связки», перенимая опыт коллег из других проектов.

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

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