Поговорим о том, какие инструменты хотелось бы иметь при описании бизнес-процессов. Инструментов BPMS (BPM systems) много, но выбрать то особо нечего …
Ниже перечислим некоторые важные инструментальные возможности некоторых сред моделирования процессов (в основном АРИС-ARIS и MS visio).
Уточнения. BPM (business process management, управление бизнес-процессами) - это тот, который из области системной инженерии (SE), который почему-то теперь называют BPA (анализ). Он же CASE, где S= "system" (не "software").
"Бизнес-процесс" - это синоним "процесс" и даже таким терминам как: операция, действие, активность, функция, процедура. Приставку "бизнес" указывают, чтобы отличать процессы класса "административные" - "деловые" (см. BPM CBOK) от химических и физических (других "природных") процессов. Любой процесс, который реализуется человеком или компьютером (программой, роботом), - это "бизнес-процесс", несмотря на то, что непосредственно к "бизнесу" отношения может и не иметь. Настолько вот запутан этот BPM, хотя в реальности он прост.
Задача
Она очень простая. Нужно простым образом формализовывать процессы, нас окружающие. Так формализовать, чтобы модели процессов были адекватны реальным процессам, но чтобы их визуализацию хоть как-то понимало большинство людей, первый раз слышащих слово "BPM". Формально "интуитивно понятных" BPM-нотаций - много (также как много рекламно-маркетингового шума о BPM), но взять особо нечего. Однако здесь важна не только сама нотация (IDEF\VAD\EPC\BPMN\UML и т.п.), а механизмы ее представления на экране: слои, вариативность "точек зрения" (view-шек, представлений) и т.п. На мой взгляд, лучшим вариантом пока остается EPC (Event-driven Process Chain), но не суть, - представленные ниже подходы могут применяться к другим нотациям.
Можно зарисовывать простые процессы в произвольной нотации карандашом и на салфетке - и это тоже будет работать, но нам хотелось бы "цифровизованно" (через автоматизацию процесса моделирования процессов), включая проверку соблюдения нотации (соглашения о моделировании), кликабельность модели (объектов схемы), ведение репозитария объектов, web-паблишер и много всего остального, что облегчает работу с большими и сложными моделями.
1. Подходы к визуализации диаграммы
1.1 Слои модели
Они позволяют управлять сложностью внутри одной модели (схемы). Например, введем три категории: Документы (входящие и исходящие), функция, ресурсы (роли и инструменты). Для каждой категории - свой слой.
Нарисовал нам наш архитектор (специалист по моделированию процессов) схему:
Рис. 1 Процесс оформления заявления
Visio Stencil Library for EPC - не нашел, поэтому "как то так" (штатная EPC - вообще "никакая").
Смотрят пользователи (Работник, Начальник, бизнес и системные аналитики) на схему и понять не могут, что нарисовано то и как этот процесс работает. Соглашение о моделировании прочитали, обучающие ролики посмотрели, но все равно не понятно.
Путь к пониманию - это упрощение схемы, например, будем отключать слои. В правильном инструменте (BPM-Tool) должны быть кнопки управления слоями - категориями. По кнопке "отключить ресурсы" - будет скрыт слой "ресурсы", в котором показаны объекты схемы (модели) типа "Роль" {Работник; Начальник} и Инструмент {MS Word}. Уже схема стала менее нагруженной (правой части не стало).
Далее отключаем слой "Документооборот" (docflow) и остается только последовательность действий (workflow, Process Flow), который говорит, что нужно провести всего две операции.
По мере появления ясности подключаем слои (кто исполнитель и какие документы на входе и выходе каждой функции \ операции). Когда схема большая (перегруженная) отключение слоев может творить "чудеса" в плане облегчения восприятия процесса. Иногда достаточно увидеть несколько представлений "одного и того же" (т.е. "те же самые, только в профиль") чтобы понять и нотацию и саму логику схемы, а если для этого достаточно нажать несколько кнопок (фильтров категорий), то путь к пониманию резко сокращается.
Пользоваться послойным построением схемы также удобно: вначале нарисовали основной слой workflow, потом наращиваем информативность процесса другими слоями.
Пример такой реализации возможен в MS Visio:
Рис. 2 Управление слоями в MS Visio
Инструмент управления слоями, как управление сложностью - давно норма в векторных графических редакторах, ГИС и других CAD-системах, например, AutoCAD.
1.2 Плавательные дорожки
Swimlane позволяют группировать процесс по разрезам "Исполнители" и "Инструменты" (в общем случае - в разрезе любой иной категории объектов).
Применительно к Рис. 1 "Процесс оформления заявления": отключили слой "документы", а оставшуюся часть (функции и ресурсы) представили в виде одной или двух Swimlane (опять же "по кнопке").
Рис. 3 Swimlane по ролям в горизонтальной плоскости
Применительно к рассматриваемому случаю возможны следующие комбинации Swimlane:
- две одинарные (горизонт, вертикаль) по ролям;
- две одинарные (горизонт, вертикаль) по инструментам (часто в разрезе баз данных показывают);
- две двойные, "шахматка", таблица (горизонт - роли, вертикаль - инструменты и наоборот).
"Дорожки" помимо того, что позволяют создать другое (альтернативное) представление процесса (смена представления иногда играет решающую роль в понимании процесса), обеспечивают сортировку по указанным категориям, что позволяет быстро и просто найти: где применяется такой-то инструмент и где "нужно поработать" такому то исполнителю (роли).
Основная проблема "дорожек" в том, что когда "дорожки" не нагруженные, то "съедается" основная часть листа и плотность "упаковки" объектов в модели процесса становится мизерная (КПД бассейна, где загружены только две дорожки, а остальные пустые - низкое).
1.3 Объекты модели и их атрибуты, свойства
Модель процесса в виде диаграммы отличается от "просто нарисованной схемы процесса" тем, что в ней "выделены" объекты и присутствуют атрибуты этих объектов. Для каждой категории объектов можно задавать свой набор атрибутов. Манипуляция с атрибутами объектов позволяет сортировку, "атрибутивную" аналитику и т.п. В целом, добавление атрибутов, как задающих графический элемент и его размещение, так и связность с окружением и "бизнес-свойства" объекта - это и есть ключевой механизм моделирования и не только процессов.
Как минимум необходимы атрибуты: название объекта, тип (функция, документ, роль и т.п.), связь с другими объектами. В принципе любой векторный графический редактор оперирует с объектами, но редкий имеет удобные инструменты работы с их атрибутами.
В Visio это могут быть данные фигуры и таблица свойств фигуры (ShapeSheet). Еще интереснее свойства хранить в отдельном файле Excel , например, связанном с visio (штатная функция visio). Такой подход позволяет иметь репозитарий свойств объектов в файле Excel и соответственно обширные инструменты поиска, сортировки и т.п. Любой BPM инструмент, включая АРИС, не имеет таких развитых возможностей для анализа как Excel , поэтому выгрузка в Excel интересуемой пользователя атрибутики была бы важным элементом любого BPM-инструмента.
При просмотре схемы процесса должна быть возможность выделения объекта и просмотр атрибутов схемы и ее объектов (с наложением фильтров, т.к. иначе будет избыток).
1.4 Задание своей нотации (на примере новой ЕРС ver. 2)
Посмотрим на примере нотации ЕРС. Что же в ней улучшить? Все улучшения запишем в гипотетическую ЕРС2 нотацию.
Есть предубеждение, что Событийная цепочка процессов обязательно должна иметь строгое чередование "функция" - "событие". Это не так: события указываются только тогда, когда это действительно нужно.
Вообще, от workflow (схема алгоритма) ЕРС отличается в основном двумя параметрами: наличие указания ресурсов и документов (материалов) и иное задание условия разветвления алгоритма (ветвление по условию). Использование элемента "событие" - как указание результата, вместо "да" и "нет" - более функциональное и позволяет кроме того сократить номенклатуру графических примитивов. Событие - как "что-то произошло" и событие - как результат проверки условия.
Как показано в п. 1.1 "Слои модели": выделяем зону docflow, EPC-workflow и ресурсную зону. Docflow, а также любые другие входы и выходы функции (включая материалы, заготовки, полуфабрикаты и конечные продукты) - отображаем слева от функции (отдельная стрелка для всех входов, отдельная для всех выходов) с соответствующим направлением движения, а все ресурсы - справа от функции (без направленных коннекторов). Это позволит иметь стандартный "взгляд" на процесс и сразу фокусироваться на конкретной зоне.
В ЕРС2 будет классификация моделей: приведенная и мультиресурсная. В приведенной схеме будет к каждой функции привязано не более одной роли (инструмента), чтобы была однозначность по исполнителю (инструментарию), что важно не только для анализа, но и при построении Swimlane (каждому "пловцу - исполнителю" по выделенной дорожке).
Возможность задания своей нотации в инструменте моделирования означает подсказку (блокировку) при некорректном построении модели, как в момент отрисовки, так и через проверочный отчет построенной диаграммы. Например, в ЕРС2 предусматриваются следующие типы коннекторов: для входящих сущностей (входящие документы, материалы-заготовки), для выходящих (исходящие документы, продукты операции), соединитель потока (функции, события), соединитель ресурса. В объекте "функция" предусматриваются три "Connection Point" (visio):
- вверху и внизу объекта "функция" (и "события") - для указания структуры потока (очередность действий, событий);
- слева в овале "функция" два коннектора: один вход, второй выход (общие для docflow и потока материалов и т.п.);
- справа два коннектора: для исполнителя функции и инструмента, который используется для реализации функции.
Такой подход позволит легче читать схему ЕРС, сегодня же "глаза разбегаются", когда видишь паутину и вперемешку разбросанные а) "роли" - и слева и справа функции и б) "документы" - и слева и справа функции.
Соответственно тест на валидность построенной модели проверяет соблюдение указанных правил соединения объектов, а также другие правила построения (про коннекторы - лишь как небольшой пример проверки правил нотации).
Вопрос: кроме как в visio, где можно задавать новые нотации и делать проверки на соответствие (валидность), аналогичные показанным выше?
1.5 Из таблицы - схему, а из схемы - таблицу
Если посмотреть на ЕРС схему (рис. 1), то видно, что она однозначно задается таблицей. Поля таблицы: вход, выход, функция, исполнитель, инструмент. Заполнили табличку, нажали кнопку "построить" - и схема сгенерировалась. Справедливо и обратное: по нарисованной схеме можно построить адекватную табличку без потери информации (lossless).
Механизм "Из таблицы - схему" в ARIS \ ARIS Express называется Smart Designer. Только он не умеет строить ветвление процесса. На всякий случай: поиск по "ARIS Smart Designer EPC", закладка "картинки".
Преимущества: человек, вообще не знающий нотации (ни одной), по простым правилам заполнил табличку и сгенерировал "по кнопке" схему процесса. Более того, возможно итерационно: вначале заполнил поле "функция" (оно же и "событие", - только с указанием соответствующего признака) - увидел "ствол" функций и событий (магистраль потока, workflow), а потом начал наращивать их левые (вход\выход) и правые (ресурсные) связи.
Можно предусмотреть в таблице отдельное поле "полное описание функции" с подробным (большим, т.е. не влезающим в надпись) описанием операции, отображаемое на диаграмме в виде, например, всплывающей подсказки (или в отдельном окне) при активации конкретной функции (при наведении мышью).
Концептуально изложенный подход близок к выделенной в АРИС нотации "табличная ЕРС" (см. "Нотация ЕРС в виде таблицы"), но здесь реализация в виде обычной текстовой таблицы, т.е. ближе к ARIS Smart Designer. Причем логику процесса также можно указать в составе таблицы, например, как ссылка на предшествующий объект (этого нет Smart Designer, но не сложно добавить "что-то" для ЕРС2). Таблицу можно вставлять в текстовые регламенты word и макросом (VBA) генерить схему процесса ("не отходя от кассы") с дублированием конечно в общем каталоге моделей.
В теме автоматического создания диаграмм из таблицы (особенно Excel) нельзя обойти MS Visio Data Visualizer. Как обычно, - идея "на отлично" (идея далеко не новая), но реализация … Видимо в погоне за максимальным универсализмом "выплеснулся ребенок BPM". Я ожидал увидеть что-то такое же простое, функциональное (мощное) и BPM-ориентированное как ARIS Smart Designer. Может это впечатление сложилось из-за отсутствия мастера автопостроения EPC. Кроме того, исключительная модель по подписке не позволяет популяризацию инструмента.
Собирать схему из таблицы намного сложнее, чем наоборот, т.к. требуется сложный механизм пространственного разнесения объектов схемы (минимизация пересечений, задание направления потока и т.п.).
1.6 Из скрипта - схему, а из схемы - скрипт
Подход аналогичный генерации схемы по таблице (см. п. 1.5.), только используется язык, наподобие plant uml \ dot (graphviz). Структурные схемы (другие с простой нотацией) и UML строить уже можно, но вот EPC (лучше EPC2, т.е. задание языком специфических правил нотации) и другие со сложной нотацией - нет (красиво не получилось).
Применительно к graphviz: в случае, когда репозитарий объектов хранится в Excel, можно автоматически генерировать схемы, используя инструменты типа: Excel to Graphviz (sourceforge.net).
Пример простого VAD из dot:
digraph g {
rankdir=LR;
node [shape = cds];
Step1 -> Step2 -> Step3 -> Step4;
}
Посмотреть схему можно, вставив код в окно "Online Graphviz Generator":
http://fiane.mooo.com:8080/graphviz/
Кстати, редкий Online Graphviz понимает несокращенный набор параметров спецификации.
Кратко: LR - говорит, что схема строится "слева - направо" (для EPC ставим "сверху - вниз"), cds - это код объекта в виде "кораблика" (VAD). Далее через "->" указывает последовательность процессов. Можно задавать последовательно-параллельные структуры, подписи и тип стрелок, добавлять объекты "исполнители", "продукты" и другие "VAD-примочки", но при этом код становится сложным, а отсутствие нормального управления надписью (перенос, вписывание в фиксированный размер объекта и т.п.) ограничивают применимость инструмента.
Применять подход "скрипт -> схема" можно в сочетании с табличным представлением: например, скриптом VBA читаем поля заполненной пользователем таблички бизнес-процесса (см. 1.5 Из таблицы - схему …) и генерируем dot-последовательность, которую "скармливаем" локальному генератору dot (Graphviz устанавливается на компьютер) или Online Generator. Прямо в word- документе под табличкой "Процесс такой-то" размещаем "кнопочку" и пользователю даем возможность просмотра в графике того, что он ввел в табличку (как он описал в табличной форме свой процесс).
Из "BPM-связанного" особенно удобен dot для построения графов переходов. Если в модели есть docflow с документами со многими состояниями, то без схемы переходов состояний понимание многочисленных переходов осложнено, особенно когда смена состояний документа размазана по многим листам схемы. В итоге заполнив табличку и "скормив" её генератору dot мы увидим всевозможные переходы из состояний. Например, для документа "Отчет" возможны следующие состояния: Шаблон отчета - Шаблон отчета заполнен - Отчет согласован в отделе №1 - Отчет согласован в отделе №2 - Отчет подписан первой подписью - Отчет подписан второй подписью - Отчет оправлен регулятору - Отчет принят регулятором (возможны различные переходы из состояний).
В теме автоматического создания диаграмм из "текстового описания языком" нельзя не упомянуть про Object Process Diagram (OPD) \ Object Process Language (OPL). Тезисы у Object Process Methodology (OPM) вроде как BPM-ориентированные, но поверхностное знакомство с ним породило уверенность, что эта методология намного дальше от "workflow \ business process" (народа), чем те же plant uml \ dot (graphviz). OPCloud доступен тут: https://sandbox.opm.technion.ac.il/
Если немного помечтать, то настоящий BPM - инструмент должен из любого текстового "процессного" регламента (порядка действий) строить схему процесса. Когда это появится, то загрузив в такую систему многостраничные регламенты (листов под 200-300) мы обязательно увидим противоречивость и неоднозначность этих "пухлых" регламентов (несмотря на это, по ним как-то все работают же).
2. Другое
2.1 Навигация по связанным моделям (каталог моделей)
При построении вложенных диаграмм (причем, возможно выполненных в разных нотациях, например, верхнеуровневые в VAD, IDEF0) необходимо иметь возможность перехода от одной к другой.
Обычно связанный набор моделей (и их объектов) называют репозитарий (репозитОрий). Часто в интерфейсе программы предусмотрено два окна: иерархическое дерево моделей (слева вверху) и окно диаграммы (основное). В идеале навигация по моделям должна быть трех видов:
- по дереву моделей (treeview );
- по кликабельным объектам схемы (детализация - проваливаемся в низ, кнопка "выше" - переход к верхнеуровневой модели);
- комбинированная, когда при переходе через кликабельные объекты схемы меняется фокус на общем дереве процессов.
В итоге получаем визуальный навигатор по одной "большой процессной модели", где верхнеуровневые схемы описывают "лес процессов", а детальные модели (процессы) - "деревья". При этом можно легко менять декомпозицию и перемещаться по уровням представления "процессного слоя" компании.
2.2 Разные фишки и отчеты по атрибутике
Поиск по названиям моделей, атрибутам. Задание правил отбора, например, по диапазону значений последнего редактирования модели. Выгрузка данных фильтрации \ сортировки во внешний файл (отчет), причем разного формата (например, excel для анализа, pdf для презентабельности) и т.п.
Правила работы с одноименными объектами (разрешение конфликтов), например, при наименовании нового объекта система смотрит - использовался ли одноименный объект и при выявлении такового предложит варианты, например, подтвердить или переименовать. У объекта в терминах АРИС только один Definition (Определение объекта, образ), но сколько угодно Occurrence (Отображение объекта, экземпляры на схемах).
2.3 Специфические отчеты
Отчеты могут быть разнообразны (зависит от воображения), но в первую очередь, нас будут интересовать выгрузки в распространенные формы. Универсальный генератор отчетов "на все случаи жизни" видимо проблема, но инструменты создания отчетов должны быть изначально в среде моделирования.
Для примера рассмотрим матрицу ответственности\ участия RACI. Требуется автоматическая генерация усеченной RACI-матрицы (здесь показано только для участников процесса, но часто плюс владельцы процесса) по имеющейся, например, VAD-диаграмме (value added chain diagram). Набор ключевых "мега процессов" компании показан в виде VAD и нужно по ним построить (синхронизировать) матрицу участников (RACI по одной только роли "участник процесса").
Рис. 4 Построение RACI матрицы
Алгоритм построения таблицы на VBA Visio\Excel может быть следующий:
1) Создаем в таблице Excel новую строку и в поле "Ключевые процессы" подставляем значение с активного листа visio из объекта типа "название мега процесса".
2) Далее циклом пробегаем по всем VAD-элементам схемы (листа) и через связь (объект "соединитель" для связки с объектами "исполнитель") находим связанные объекты типа "исполнитель" (участник подпроцесса).
3) Находим соответствующее название подразделения в шапке таблицы и на пересечении с процессом ставим символ участия (признак).
4) Переход к следующему листу visio.
Когда в организации десятки подразделений и около сотни "мега процессов" (их выделение достаточно субъективно), то задача синхронизации схем мега-процессов и матрицы участия подразделений в таких ключевых процессах становится достаточно трудоемкой.
2.4 Упаковка необъятной схемы процесса в печатный лист
Когда рисуют гигантскую "портянку" из "тучи элементов" на одной схеме, а потом нужно ее распечатать (А4, А3) или представить в ином интерфейсе (без скролинга такой "портянки"), то возникает ступор. Должна быть поддержка многостраничной схемы и элементов перехода между страницами (в том числе, кликабельными).
2.5 Разное
Публикация процессов, совместная работа, интеграция с корпоративной базой нормативных документов и т.п.
Авто-размещение объектов на схеме: набросал невпопад объекты на лист (главное правильно связи указать и никого не забыть) и нажал кнопку: "расположить как надо" и система сама оптимально и красиво разместила объекты на схеме (в visio функции выравнивания и распределения фигур).
Открытые стандарты хранения и экспорта \ импорта (внешний графический импорт \ экспорт как минимум в visio), как самих графических объектов модели, так и их атрибутов. К сожалению, тот же MS visio так и не научился нормально экспортировать схемы в pdf и svg (например, всплывающие подсказки).
Изменение дизайна графического примитива для любого объекта нотации, расширение нотации, передача новых шаблонов в другую аналогичную систему, добавление новых атрибутов объектов (новых полей) и многое другое.
Заключение
Устаревшие подходы, реализованные в "современных" платных инструментах моделирования не адекватны времени. За механизацией пришли модные: "информатизация", потом "автоматизация", а теперь и "цифровизация" (аж Digital Transformation / digital disruption и совсем "свежий" Digital process Automation), но возможности инструментов моделирования процессов за три десятка лет почти не изменились. Функциональность древних ARIS, BPwin и т.п. практически не осовременилась в современных BPMS, несмотря на то, что интерес к классическому моделированию процессов постоянно растет, т.к. проблема замены текстовых регламентов на что-то прогрессивное - в целом так и не решена (диаграммы рабочих процессов не заменили текст). Имитационное моделирование и исполняемые модели (также направления, process mining, enterprise architecture - ЕА и др.) - не в счет, рассматриваем "классическое моделирование процессов" - оно же просто "формализация процессов".
Дождаться Open Source системы, в которой было бы реализовано указанное выше, - в обозримом будущем - маловероятно, поэтому, направление улучшайзинга для себя вижу как связку: visio VBA (core, графика) + Excel (как репозитарий для хранения атрибутов моделей, а в будущем и атрибутов графических объектов, инструменты аналитики) + web (publisher & collaboration).
Динозавр - монстр АРИС до сих пор остаётся продуктом №1 в данном сегменте, несмотря на то, что он "заморозился" во времени (в части toolset) и ничего нового в этом направлении не предлагает. АРИС (1994г) и многочисленные visio-надстроенные инструменты (Business Studio, BPM-Х, Orbus iServer и десяток аналогичных) хорошо показали саму концепцию моделирования процессов, которая неизменна десятилетиями. Концептуально подходы понятны, но вот для построения моделей процессов из free взять нечего: через BPMN описать сложные процессы компании - это утопия, если нужно чтобы пользователь понимал нарисованное. Вроде бы удобный трамплин для амбициозного стартапа …
Если в CASE, где S="software", еще наблюдается вялотекущая "движуха", например, UML-UML2- SysML или "всяко исполняемое" (no code\ low code), то направление CASE, где S="system" в части BPM (не EA), - фактически "замерло на месте", а робкие попытки, что методологического плана, что инструментального - прежде всего Open Source инструменты "классического" моделирования процессов - скорее отождествляются термином "застой". Правда может я чего-то не заметил.
Немного поутихнет мода на BPMN2 (фетиш в плане замещения нотации ЕРС) и мы вернёмся к "вечному", к классическим подходам BPM, т.к. другого ничего пока так и нет (задачу описания небольших процессов - не рассматриваем). Вернувшись к исходной точке описания процессов, следует смотреть в сторону чего-то интуитивно понятного "простому смертному": бухгалтеру, кассиру, секретарю и т.п., т.е. не программисту. Скорее всего, вернемся к "старине" ЕРС (т.е. фактически к "разбитому корыту") и начнем двигаться к нотации "ЕРС+" (показано на примере ЕРС2) и более гибким (см. предложенные выше фишки) и открытым (free, Open Source) инструментам моделирования. Ориентация на человека, а не машину - ключевой вектор развития. Нотации и инструменты должны быть более "человечными", схемы процессов должны создавать не "специально обученные люди", а сами участники процесса, возможно, даже не подозревая об этом и непосредственно не рисуя процессы.
В 2000-ном году мной использовались ровно такие же подходы и ровно те же инструменты моделирования (основные: ARIS toolset, MS visio), что и сейчас, но тогда была настолько интенсивная "движуха в мире ВРМ", что казалось "вот-вот и прогресс всё поменяет", но это оказалось иллюзией. "Старику ARIS" (в части классического моделирования процессов) на пенсию бы (не смотря на добавленные круглую цифру 10 и магическое слово "cloud"), но похоже перемены придут еще совсем не скоро и светлое будущее «обычного» BPM откладывается …
Редакционное уточнение. В предыдущих статьях не скупился на внешние ссылки. После этого статья обычно блокировалась хабро-модераторами и потом я упорно им доказывал, что приведенные ссылки не рекламного характера (в основном ссылки то – антирекламные были), но при этом всё равно часть ссылок приходилось удалять (видимо принцип: "не вашим - не нашим"). Поэтому, "спокойнее" - с минимум ссылок, а "ищущий" сам загуглит по ключевым словам.
