Путеводитель по ландшафту процессно-ориентированного программного обеспечения

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

• располагаемыми ресурсами – материальными, финансовыми, человеческими;
• бизнес-процессами, т.е. тем, как эти ресурсы используются.

Неупорядоченные и неэффективные процессы способны «помножить на ноль» любые выделяемые ресурсы.

Признаки хаотичных бизнес-процессов: 

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

С процессными проблемами сталкиваются как коммерческие, так и некоммерческие, государственные и муниципальные организации. Отличается только терминология. Так, государственные организации не любят термин «бизнес-процесс», предпочитая «административный регламент», – но суть одна и та же.

Современная дисциплина управления бизнес-процессами (BPM, Business Process Management) – результат эволюции методов и технологий, начавшейся в 80-е. За прошедшие десятилетия в этой области накоплен большой объем знаний, методов, технологий и практического опыта, а значит – можно говорить о самостоятельной прикладной науке. Так, свод знаний по управлению бизнес-процессами (BPM CBOK) насчитывает свыше 400 страниц. Притом это лишь краткое изложение основных положений, ключевых понятий и основных методов.

Управление бизнес-процессами включает три аспекта:

1. Процессная методология, начинающаяся с таких ключевых понятий, как «бизнес-способность», «кросс-функциональный» и «сквозной от начала до конца бизнес-процесс», «цепочка создания ценности».
2. Информационные технологии – программное обеспечение, облегчающее реализацию процессной методологии. Отдельного упоминания заслуживают интегрированные системы управления бизнес-процессами – BPMS (Business Process Management Suite).
3. Подход к реализации – управление процессными инициативами различного масштаба, от текущих усовершенствований до трансформаций бизнес-модели.

Процессная методология первична, а программные продукты – не более чем инструменты

Проекты «BPMS без BPM», т.е. инициативы по внедрению передового ПО, исходящие от ИТ-подразделения и не подкрепленные развитием процессных компетенций, обречены на неудачу. BPM – существенно больше, чем внедрение очередного программного продукта. Это глубокое изменение операций компании и ее организационной культуры.

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

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

Прогресс в области ИТ в последние годы столь стремителен, что роль ИТ уже не просто обеспечивающая – новые технологии зачастую становятся локомотивом процессных инициатив. Так, недавно ставшая популярной роботизация процессов (RPA, Robotic Process Automation) позволяет освободить человека от рутинных операций: обработки входящих документов, подготовки письменных ответов на стандартные запросы или ввода данных в корпоративную систему. Это дает толчок к очередному циклу совершенствования бизнес-процессов.

Оборотная сторона столь бурного прогресса:

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

Чем же руководствоваться при выборе процессного ПО и что взять за ориентиры?

Прежде всего разберемся со сложившимися классами программного обеспечения.

 Ниже мы рассмотрим назначение и характерные черты каждого класса.

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

Специализированное ПО

  1. Process Modeler – моделирование бизнес-процесса

Средства моделирования входят также в состав интегрированного ПО EA и BPMS, но у специализированных моделеров – простых в использовании, не требующих существенной поддержки со стороны ИТ-службы, недорогих или бесплатных – есть своя ниша. Если необходимо только моделирование отдельных процессов для целей оптимизации или регламентации – это оптимальный вариант.

Обязательная функциональность: 

• графическое моделирование бизнес-процессов для целей анализа (as-is) и/или проектирования (to-be).

Опциональная функциональность:

• автоматическая генерация текстовых регламентов из модели;
• имитационное моделирование (см. ниже).

На что обращать внимание при выборе:

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

Примеры: Bizagi Modeler, Microsoft Visio, Signavio.

2. Process Simulation – имитационное моделирование бизнес-процесса

Расчет показателей будущего бизнес-процесса по методу Монте-Карло   – грубо говоря, путем многократного подбрасывания монетки и усреднения полученных показателей.

Общее правило: больше данных на входе – больше показателей на выходе:

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

В этой категории есть мощные специализированные пакеты, но для первого знакомства можно воспользоваться имитационным моделированием, встроенным в бесплатный Bizagi Modeler.

3. Process Mining – выявление бизнес-процесса

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

Нюанс в том, что последовательность выполнения операций в информационной системе не регламентируется: моделировали одно, а фактически получается другое. Что именно – в какой последовательности фактически выполняются операции в рамках процесса – позволяют выяснить программные продукты класса Process Mining.

На вход программы подается файл аудиторского журнала (лог) информационной системы, содержащий как минимум следующие данные:

• номер экземпляра процесса;
• название операции;
• исполнитель;
• дата и время начала и завершения операции.

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

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

Интегрированные пакеты ПО

1. EA (Enterprise Architecture) – моделирование корпоративной архитектуры

Стандартная функциональность ПО класса Enterprise Architecture:

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

Как правило, это недешевое «тяжеловесное» ПО, требующее серверных ресурсов и поддержки со стороны ИТ-службы.

Примеры: ARIS, Business Studio.

ARIS, в дополнение к перечисленной выше обязательной функциональности, позволяет также выявлять бизнес-процессы   и сравнивать фактические показатели процессов с нормативными, отображая результаты наглядно за счет модуля ARIS PPM (Process Performance Management):

2. BPMS/iBPMS/Low-code – системы управления бизнес-процессами

Интегрированные системы управления бизнес-процессами существуют около 15 лет. В ходе эволюции расширялась их функциональность и несколько раз менялось название. Первоначально аббревиатура BPMS расшифровывалась как Business Process Management System – система управления бизнес-процессами. Затем с подачи аналитической компании Gartner BPMS стало расшифровываться как Business Process Management Suite – интегрированное ПО для управления бизнес-процессами.

 Примеры: Bizagi, Camunda, Comindware, ELMA, IBM BPM, Terrasoft.

Системы класса BPMS поддерживают все этапы усовершенствования PDCA – Plan-Do-Check-Act:

• Средства разработки (Plan) – моделирование схемы бизнес-процесса, данных, бизнес-правил, экранных форм и т.д.
• Исполнение процесса (Do) – процессный «движок» и веб-портал пользователя.
• Мониторинг и аналитика (Check, Act) – BAM, Business Activity Monitoring. Под мониторингом понимают оперативный контроль.

Современные корпоративные системы (ERP, CRM) тоже могут включать средства моделирования процессов и процессные движки, но их функциональность, как правило, уступает специализированному процессному ПО.

Принципы, на которых основаны системы класса BPMS:

• «Как нарисовали, так и работаем» (what you model is what you run). Имеется в виду, что схема процесса в BPMS является не инструкцией для исполнителей или программистов, а регламентом, непосредственно исполняемым системой. Например, на схеме процесса может быть изображен прямоугольник с надписью «Согласовать заказ с клиентом». Это означает, что в определенный момент сотрудник-исполнитель очередного шага процесса, зайдя в веб-портал, увидит назначенную ему задачу точно с такой формулировкой. Кликнув по ссылке, он увидит форму задачи, в которой должен будет заполнить поля и кликнуть «Готово». После этого процесс пойдет дальше по маршруту, и следующий исполнитель в цепочке увидит задачу в своем списке. У исполнителя нет возможности отступить от схемы.
• «Спроектировано с расчетом на изменения» (built for change). Бизнес-процессы в системах класса BPMS рассматриваются не как спроектированные раз и навсегда. Это взгляд, характерный для тяжеловесных корпоративных систем. Они представляют собой нечто, меняющиеся вслед за изменениями законодательства и регулирования, конкуренции и поведения покупателей, в ходе постоянной борьбы за сокращение издержек и т.п. 
• Короткие циклы разработки с опорой на обратную связь от пользователей (аджайл). Системы BPMS не подразумевают длительных циклов разработки – текущие небольшие правки в процесс вносятся в течение нескольких дней или даже часов. Это достигается за счет визуальной разработки, которая основывается на моделях. Схема процесса, схема данных, экранные формы, бизнес-правила и даже интеграционные интерфейсы – все это делается мышкой и по большей части не требует квалификации программиста.

В большинстве программных продуктов класса BPMS используется нотация BPMN 2.0 , в которой заложены перечисленные выше принципы. BPMN является открытым стандартом OMG и ISO, что также добавляет популярности этой нотации.

В начале 2010-х Gartner предложил новую аббревиатуру: iBPMS – «умная» (intelligent) BPMS. К функциональности, унаследованной от BPMS, добавились:

• Кейс-менеджмент (ACM). В отличие от классических процессов, в которых последовательность задач жестко задается шаблоном (схемой процесса), в рамках кейса исполнитель сам решает, кому и какие раздать подзадачи. В деятельности организаций рутинная и творческая работа переплетаются и дополняют друг друга. Поэтому естественно, что в определенный момент процессное ПО стало поддерживать как шаблонные процессы, так и кейсы.
• Доступ с планшетов и смартфонов. Это особенно востребовано топ-менеджментом и сотрудниками, проводящими рабочий день на бегу. Например, руководитель может оперативно одобрить заявку, а менеджер по продажам – сфотографировать только что подписанный клиентом заказ и инициировать его обработку сотрудниками в офисе.
• Размещение в «облаке». Возможность подписаться на сервис и немедленно приступить к работе, а в дальнейшем с легкостью масштабировать систему — привлекает все большее число заказчиков.
• Продвинутая аналитика. Применение искусственного интеллекта и машинного обучения позволяет облегчить сотрудникам выполнение задач в рамках бизнес-процессов, а иногда даже полностью их автоматизировать.

Сегодня интегрированное ПО для управления процессами все чаще предлагается как системы Low-code и платформы цифровой трансформации. К функциональности BPMS/iBPMS добавляются:

• Работа с данными вне процессного контекста. Стандартно BPMS позволяют что-то делать только в контексте определенного процесса и не дают возможности отредактировать какие-то данные, например, как это принято в корпоративных системах. В более современных вариантах это искусственное ограничение снято.
• Среда разработки в браузере. В традиционных BPMS разработка ведется в тяжеловесной программе. Современный тренд – для работы достаточно веб-браузера не только конечным пользователям, но и бизнес-аналитикам, и разработчикам.
• Внешние пользователи. Веб-портал BPMS в качестве пользователей рассматривает сотрудников организации. Но положение дел меняется: к внутренним пользователям добавляются внешние – клиенты, партнеры, поставщики…
• Современный пользовательский интерфейс. Прогресс в этой области идет быстро, и интерфейс современных соцсетей, к примеру, выглядит совсем не так, как веб-сайты десятилетней давности.
• Интеграция с интернетом вещей, машинным обучением, блокчейном и т.д. Если BPMS интегрировались в основном с унаследованными корпоративными системами (ERP, CRM, WMS и т.п.), то современные цифровые платформы поставляют широкий набор коннекторов к разнообразным интернет-сервисам.

Смежное и инфраструктурное ПО

1. BI (Business Intelligence) – бизнес-аналитика

Программное обеспечение BI решает широкий круг задач: от традиционной отчетности по данным корпоративных систем до выявления зависимостей (data mining) и предсказательной аналитики.

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

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

Технологии гиперкубов (OLAP) и витрин данных позволяют отделить аналитическую обработку данных от регистрации первичных данных (OLTP) и ускорить построение отчетов без ущерба для времени отклика системы на действия пользователя. Дополнительное ускорение дают технологии обработки данных в памяти.

Примеры: Oracle Business Intelligence, QlikView, SAP Business Objects.

2. BRMS (Business Rules Management System) – управление бизнес-правилами

Бизнес-правила можно встретить в разных областях бизнеса:

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

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

Компоненты BRMS:

• Моделирование бизнес-правил через серию условий «если–то» и/или матрицу принятия решений. Это делается без программирования через визуальный интерфейс, а потому по силам бизнес-аналитикам и продвинутым бизнес-пользователям.
• «Движок» бизнес-правил, применяющий заданные правила к полученным входным данным и дающий ответ в виде выходных данных.
• Программный интерфейс (API). Пользователи не взаимодействуют с системами класса BRMS напрямую – обращение к бизнес-правилам встраивается в исполняемый бизнес-процесс или в корпоративную систему.

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

Для моделирования бизнес-правил сегодня все чаще используется нотация DMN (Decision Modeling Notation), стандартизованная OMG.

3. ECM – управление контентом

Системы ECM (Enterprise Content Management) предназначены для хранения

• документов MS Word;
• электронных таблиц; 
• аудио- и видеозаписей;
• другой неструктурированной информации (контента).

Помимо основной функции хранения, они обеспечивают:

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

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

Примеры: Alfresco, Directum, Docsvision, Documentum, Microsoft SharePoint.

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

Системы BPMS используют DBMS для хранения в базе данных атрибутов процесса. Что касается контента, производители BPMS рекомендуют хранить его в ECM. Но это не является обязательным требованием – система BPMS даст возможность пользователю прикрепить документ к процессу и сама обеспечит его хранение.

ECM часто приобретается в связке с документооборотом. Если ECM – это универсальное ПО, то документооборот – это прикладное решение, разработанное поверх ECM

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

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

• Процессная методология и документооборот смотрят на документ с диаметрально противоположных точек зрения. Для документооборота документ – ценность, для бизнес-процесса – априори потери, следовательно, подлежит сокращению. В этом вопросе процессная методология соответствует текущему тренду цифровизации. Так, кто бы мог предположить еще несколько лет назад, что для посадки на самолет не понадобится посадочный талон, а хватит QR-кода на экране смартфона?
• Документооборот оперирует неструктурированным контентом, в то время как процессные технологии – структурированными данными. Например, согласование договора в первом случае означает вычитывание многостраничного текста, во втором – просмотр карточки договора с небольшим числом полей: реквизиты сторон, спецификация товара, условия оплаты. Текст договора готовится автоматически по шаблону. В первом случае интеграция с корпоративными системами затруднена необходимостью извлечь данные из документа (например, сумму контракта), что является трудоемкой операцией, чреватой ошибками. Во втором случае эта проблема отсутствует.
• В отличие от BPMS, системы документооборота не могут похвастаться развитыми средствами моделирования процесса, визуального проектирования схем данных, форм и т. п. Это приводит к необходимости написания большого объема программного кода. Это дискредитирует ключевые идеи управления бизнес-процессами – непосредственное вовлечение в проектирование процесса бизнес-пользователей и быстрое реагирование на изменения требований к бизнес-процессу.

4. EAI (Enterprise Application Integration) – интеграция корпоративных систем

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

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

• Области, в которых компания не ставит амбициозные цели, а ожидает от бизнес-процессов, чтобы они были «достаточно хорошими». Это может быть складской учет (если компания не специализируется на предоставлении складских услуг), управление персоналом, другие вспомогательные бизнес-процессы. Процессы из этой категории можно и нужно автоматизировать, используя тиражируемое («коробочное») ПО, не увлекаясь кастомизацией.
• Вторую группу составляют ключевые бизнес-процессы – те, которые обеспечивают компании конкурентное преимущество. Как правило, это процессы, непосредственно замыкающиеся на клиентах, партнерах, поставщиках. Данная группа меньше по численности. Она может составлять всего 5% от общего числа бизнес-процессов, но перевешивает по значимости. Здесь компания должна быть готова биться за то, чтобы ее бизнес-процессы были не просто удовлетворительными, а самыми лучшими. По крайней мере в своей рыночной нише. Для этого их надо постоянно «вылизывать», делая еще более удобными для клиентов:

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

При таком подходе к автоматизации подразумевается интеграция процессной системы с унаследованными учетными системами – складскими, производственными, кадровыми и т.д. На практике проекты BPMS не обходятся без объединения с унаследованными системами.

Более простой вариант – использование механизмов интеграции, предоставляемых самой BPMS: вызов веб-сервисов (WSDL/REST/OData), коннекторы к распространенным корпоративным системам, облачным сервисам, базам данных, ECM-системам и т.п.

Крупные организации с обширным «зоопарком» унаследованных систем идут по другому пути. Они используют специализированное интеграционное ПО. EAI – обозначение широкого класса систем, к которому относятся программные продукты ESB (Enterprise Service Bus), MOM (Message-Oriented Middleware), SOA и другие. Это тяжеловесное, дорогое и сложное ПО. Но оно обеспечивает более высокие уровни надежности, гибкости, производительности.

Примеры: Apache ServiceMix, IBM WebSpere, Microsoft BizTalk, Oracle SOA Suite.

5. RPA (Robotic Process Automation) – роботизация процессов

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

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

RPA представляет собой простую и дешевую альтернативу традиционной интеграции приложений (EAI)

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

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

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

Примеры: UiPath, WorkFusion.
Мы рассмотрели сложившиеся классы процессно-ориентированного ПО. В следующей статье "О выборе процессно-ориентированного программного обеспечения" мы перейдем к вопросам :

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