Недавно на Хабре были опубликованы несколько статей ( раз, два ) на тему бизнес-процессов. Там утверждается, что в этой области всё настолько усложнено и запутанно, что разобраться в этом нельзя. Также было высказано подозрение, что теория процессного управления — по сути чистый пиар и маркетинг, не имеющий практической пользы.
Я много лет занимаюсь процессным управлением и, раз уж эта тема была поднята, опишу что это такое и зачем оно нужно.
Термин «процессное управление» применяется к двум разным сферам деятельности:
- В случае, когда не производится автоматизация исполнения бизнес-процессов. Задача — составить описание бизнеса в виде графических диаграмм, которые легко воспринимаются людьми. Такие диаграммы фактически представляют собой специальный язык общения менеджеров, бизнес-аналитиков и руководителей предприятий и используются для выработки и объяснения базовых решений по организации бизнеса предприятия.
- В случае, когда бизнес-процессы непосредственно исполняются в компьютерной среде предприятия. Будем называть процессы этого вида — исполнимые бизнес-процессы. Для исполнения таких бизнес-процессов на предприятии устанавливается специальная компьютерная система — BPMS (Business Process Managrment System) в английском варианте наименования, или СУБП (Система Управления Бизнес-Процессами) в русском варианте. Этим бизнес-процессам и посвящена данная статья.
Эволюция развития BPMS и «естественный отбор» за примерно 15 — 20 лет привели к тому, что в существующих на рынке BPMS используется одна и та же базовая концепция. В ней к бизнес-процессам относятся два понятия: определение бизнес-процесса и экземпляр бизнес-процесса. Иногда определение бизнес-процесса также называют шаблоном бизнес-процесса. Определение бизнес-процесса содержит схему бизнес-процесса, роли бизнес-процесса, правила назначения исполнителей на роли. Также определение бизнес-процесса содержит описание структур хранения данных.
Для каждого определения бизнес-процесса можно создавать и запускать на выполнение экземпляры этого бизнес-процесса. Понятия определения и экземпляра бизнес-процесса аналогичны понятиям класса и объекта в программировании. То есть, если определение бизнес-процесса содержит схему бизнес-процесса, типы данных, названия ролей, то в выполняющемся экземпляре бизнес-процесса на схеме находятся перемещающиеся точки управления, на роли назначаются конкретные исполнители, экземпляр бизнес-процесса содержит конкретные данные, типы которых соответствуют типам данных в определении бизнес-процесса.
Проще всего представлять себе перемещающиеся по схеме исполнимого бизнес-процесса точки управления по аналогии с перемещением фишек в настольной игре с кубиком.
Схема исполнимого бизнес-процесса состоит из узлов и переходов (их иногда также называют ребрами). Появление точки управления в узле определенного вида соответствует выполнению некоторого действия в производственной деятельности предприятия. В этот момент времени BPMS генерирует задание конкретному исполнителю. Переходы на схеме бизнес-процесса, а также узлы, предназначенные для разветвлений и слияний точек управления, располагаются таким образом, чтобы содержащиеся в бизнес-процессе действия выполнялись скоординировано и в правильном порядке.
Фактически основная функция BPMS — раздавать задания исполнителем в соответствии с перемещением точек управления по схеме бизнес-процесса и контролировать выполнение этих заданий.
В современных BPMS определение бизнес-процесса также содержит описание средств взаимодействия бизнес-процесса с исполнителем задания. Обычно это графическая форма для взаимодействия экземпляра бизнес-процесса с пользователем, или программный интерфейс для взаимодействия с внешней информационной системой. Еще одним элементом определения бизнес-процесса являются бизнес-правила, которые используются для выбора конкретного пути дальнейшего движения точки управления в точках разветвления маршрутов.
Есть определенное сходство между исполнимым бизнес-процессом и компьютерной программой. В основе и исполнимого бизнес-процесса и компьютерной программы лежат алгоритмы. Для компьютерных программ, так же как для бизнес-процессов для аналитического моделирования, существуют графические нотации (Например, диаграмма классов UML), которые программисты и программные архитекторы используют для объяснения различных программных и архитектурных решений. Однако, сами компьютерные программы пока все-таки массово не разрабатываются в форме графических объектов, они в основном пишутся в виде текстов на языках программирования. В чем ситуация для исполнимых бизнес-процессов отличается от компьютерных программ? В отличие от программы, команды которой выполняет компьютер, часть действий бизнес-процесса выполняют люди. Они делают это существенно дольше компьютера, поэтому экземпляры бизнес-процессов выполняются относительно долго, их состояние меняется медленно. Более того, в отличие от компьютерной программы, во время выполнения бизнес-процессов менеджмент предприятия может заметно влиять на их выполнение, например, увеличивать или уменьшать количество работников, выполняющих те, или иные действия.
Поэтому руководителям и менеджерам предприятия важно быстро понимать, в каком состоянии находятся исполняющиеся экземпляры бизнес-процессов предприятия. Такое понимание дает графическая схема бизнес-процесса с нанесенными на нее текущими положениями точек управления, а также пройденными этими точками маршрутами с момента запуска экземпляра бизнес-процесса. Для компьютерных программ такие диаграммы в большинстве случаев смысла не имеют, т.к. скорость перемещения точек управления будет существенно превышать пределы человеческих возможностей по их отслеживанию.
Процессный подход в случае исполнимых бизнес-процессов
Процессный подход предполагает, что деятельность предприятия можно представить в виде множества выполняющихся экземпляров бизнес-процессов. Он эффективен для предприятий, в производственной деятельности которых происходит многократное повторение одних и тех же цепочек действий, совершаемых различными исполнителями. Такими предприятиями является большинство офисных компаний, занимающихся различными видами работ с документами, таких как — банки, страховые, инвестиционные компании, консалтинговые компании, издательства. Также использование процессного подхода эффективно на предприятиях, деятельность которых описывается четкими регламентами, например, — в органах государственного управления.
Процессным управлением в случае исполнимых бизнес-процессов можно назвать следующую деятельность:
- На предприятии бизнес-процессы выделены, построены в исполнимом виде и внедрены в эксплуатацию путем загрузки в BPMS. Процессное управление в этом случае является результатом:
- Действий бизнес-аналитиков, разработавших исполнимые бизнес-процессы, в частности — схемы бизнес-процессов
- Принятия управленческих решений менеджерами в узлах схем экземпляров бизнес-процессов, имеющих различные возможные варианты дальнейшего движения точек управления
- Принятия управленческих решений исполнителями заданий при вводе в экземпляры бизнес-процессов данных (от которых существенно зависит их дальнейшее поведение).
- Действий бизнес-аналитиков, разработавших исполнимые бизнес-процессы, в частности — схемы бизнес-процессов
- К процессному управлению относится оперативное изменение схем и других элементов определений бизнес-процессов в ответ на изменение условий бизнеса предприятия.
- Также к процессному управлению относится косвенное административное влияние на выполнение конкретных экземпляров бизнес-процессов. Например, влияние по «человеческим ресурсам» — менеджмент предприятия может увеличивать или уменьшать количество работников, выполняющих определенные операции, или изменять требования к квалификации работников, выполняющих некоторые действия, а также принимать конкретные кадровые решения, назначая сотрудников на те, или иные роли. Также менеджеры могут анализировать состояния исполняющиеся экземпляров бизнес-процессов, проводить разбор возникающих коллизий и принимать различные административные решения, влияющие на эффективность исполнения экземпляров бизнес-процессов, не изменяя при этом схемы бизнес-процессов.
Основные преимущества процессного подхода в случае исполнимых бизнес-процессов
В случае использования исполнимых бизнес-процессов на предприятии появляется аналог производственного конвейера, от которого можно получить увеличение производительности труда, сравнимое с тем, которое было получено от внедрения конвейера на производстве. Повышение производительности труда достигается вследствие того, что данный механизм позволяет исключить из действий сотрудников рутинные операции, неэффективные процедуры, связанные с поиском и передачей информации, существенно повысить скорость взаимодействия сотрудников. Работники выполняют поступившие задачи, не отвлекаясь на:
- Получение от других работников необходимых для выполнения задания данных
- Передачу результатов своего труда другим работникам
- Изучение должностных инструкций
Все необходимое для выполнения задания возникает перед работником на экране компьютера.
Однако, наиболее эффектное использование исполнимых бизнес-процессов связано с понятием «Процессная трансформация»: После того, как BPMS внедрена в эксплуатацию и все работники предприятия привыкли к тому, что их деятельность является выполнением заданий BPMS, оказывается что, изменяя определения бизнес-процессов, можно очень быстро перестраивать бизнес предприятия. Так как в случае BPMS работникам не надо заботиться о том, от кого получить исходную информацию и кому отправить результат работы, можно легко и очень быстро изменять последовательности действий, исполнителей и типы используемых данных. При этом не требуется изменять должностные инструкции, проводить тренинги по обучению и аттестации. Во многих случаях исполнителей заданий можно даже не информировать об изменении бизнес-процессов, так как это не отразится на характере их работы.
Это приводит к качественным изменениям в управлении. Получаемая скорость изменения бизнеса в десятки и даже сотни раз может превосходить скорость изменения традиционными методами. При этом стоимость преобразования бизнеса небольшая. Это может стать существенным конкурентным преимуществом.
Более подробное описание исполнимых бизнес-процессов
Схема бизнес-процесса
Схема обычно определяется как математическое понятие — направленный граф: множество узлов, соединенных между собой переходами (также иногда называемыми стрелочками или ребрами). Узлы бизнес-процесса могут быть двух типов — узлы, соответствующие шагам процесса, и маршрутные узлы. Во время выполнения по переходам перемещаются точки управления (указатели на активные узлы экземпляра бизнес-процесса).
В выполняющемся экземпляре бизнес-процесса одновременно может быть несколько точек управления. В соответствии с бизнес-логикой точка управления в маршрутном узле может разделиться на несколько точек управления, также точки управления могут ждать друг друга в определенном маршрутном узле и далее слиться в одну точку управления.
В узле, соответствующем шагу процесса, находится узел-действие. Если точка управления пришла в узел-действие, то BPMS дает задание исполнителю (сотруднику или информационной системе) и ждет ответа (сообщения, что работа выполнена). После ответа исполнителя точка управления движется по переходу к следующему узлу бизнес-процесса.
Маршрутный узел соответствует появлению, удалению, разветвлению-слиянию точек управления или выбору перехода, по которому точка управления будет перемещена дальше. В таких узлах BPMS выбирает на основании содержащихся в маршрутных узлах бизнес-правил следующий узел (узлы), в который будет направлена точка управления. Часто с этими узлами связано более одного входящего или исходящего перехода.
Поясним поведение наиболее часто используемых в бизнес-процессах узлов, а также приведем их графические изображения в соответствии с нотацией BPMN.
Узел «начало» соответствует точке начала исполнения бизнес-процесса. У него нет входящих ребер (переходов) и есть только одно исходящее ребро. В момент запуска экземпляра бизнес-процесса в узел помещается точка управления, которая тут же выходит из него по исходящему ребру. В бизнес-процессе должен существовать единственный узел «начало». Обозначается «тонкой» окружностью (Рис. 1 а)
Рисунок 1. Обозначения узлов: а – начало; б – завершение потока; в – окончание; г – действие
Узел «завершение потока» должен иметь одно или более входящих ребер и ни одного исходящего. При попадании какой-либо точки управления в этот узел она удаляется. Экземпляр бизнес-процесса, в котором не осталось ни одной точки управления, считается завершившимся. В бизнес-процессе может существовать несколько узлов «завершение потока». Этот узел не обязателен, если в бизнес-процессе существует хотя бы один узел «окончание». Обозначается «жирной» окружностью (Рис. 1 б).
Узел «окончание» соответствует точке окончания исполнения бизнес-процесса. Узел «окончание» должен иметь один или более входящих ребер (переходов) и ни одного исходящего ребра. При попадании управления в узел «окончание» удаляются все точки управления в этом экземпляре процесса, а также во всех его подпроцессах. В бизнес-процессе может существовать несколько узлов «окончание». Этот узел не обязателен, если в бизнес-процессе существует хотя бы один узлел «завершение потока». Обозначается черной окружностью внутри окружности (Рис. 1, в).
Узел «действие» генерирует задание исполнителю, обозначается прямоугольником со скругленными углами, в центре которого пишется имя узла (Рис. 1 г)
Узел «исключающий шлюз» может иметь несколько входящих и несколько исходящих ребер. Для каждой пришедшей в него точки управления выбирается, по какому из исходящих ребер она будет перемещена далее. Обозначается ромбом, в котором изображен «крестик» (Рис. 2 а).
Рисунок 2. Обозначения узлов: а – исключающий шлюз; б – параллельный шлюз
Узел «параллельный шлюз» обозначается ромбом, в котором изображен «плюс» (Рис.2 б). Может иметь несколько входящих и несколько исходящих ребер. Для каждого входящего ребра пришедшая по нему в параллельный шлюз точка управления ставится в очередь. Если для всех входящих ребер их очереди заполнены хотя бы одной точкой управления, то все точки управления, находящиеся на первой позиции очереди каждого входящего ребра, удаляются, а на каждом исходящем ребре генерируется точка управления.
Рисунок 3. Пример (упрощенный) схемы бизнес-процесса “Оплата счета поставщика”
Переменные бизнес-процесса
При помощи переменных происходит обмен информацией между шагами процесса Переменные бизнес-процесса также используются при выборе конкретного внутреннего перемещения точки управления между узлами по какому-либо из возможных переходов. Переменные бизнес-процесса могут являться входящими и исходящими параметрами при взаимодействии BPMS с информационными системами предприятия.
Роли бизнес-процесса
В экземпляре бизнес-процесса производится связывание узлов-действий с исполнителями заданий при помощи ролей. При разработке бизнес-процесса создается роль и ставится в соответствие определенным узлам-действиям. Во время выполнения бизнес-процесса ролям назначаются конкретные исполнители. Здесь можно провести аналогию с театральным спектаклем: в процессе написании сценария определяются используемые в спектакле роли. Потом, при постановке в конкретном театре, на роли назначаются актеры – исполнители ролей.
В бизнес-процессе также могут быть различные правила выполнения заданий. Например, бизнес-процесс может послать задание на выполнение всем членам некоторой группы пользователей, а выполнять это задание будет первый пользователь, взявший задание на выполнение, — у остальных членов группы это задание будет отозвано.
Системы управления бизнес-процессами и их основные компоненты
Современная BPMS должна обеспечивать разработку бизнес-процессов в графической среде, исполнение экземпляров бизнес-процессов, мониторинг состояний экземпляров, ведение истории событий экземпляров бизнес-процессов, интеграцию приложений при помощи используемых бизнес-процессами коннекторов, администрирование пользователей, а также возможность замещения исполнителей заданий.
Для выполнения этих функций в BPMS служат следующие графические интерфейсы:
- интерфейсы для работы с заданиями исполнителей
- интерфейсы для работы с загруженными в BPMS определениями бизнес-процессов
- интерфейсы для работы с выполняющимися в BPMS экземплярами процессов
- интерфейсы для администрирования пользователей и групп пользователей
- интерфейсы для настройки замещений исполнителей заданий
Для создания и изменения бизнес-процессов обычно применяются графические дизайнеры, являющиеся частью среды разработки, которые могут быть как отдельными самостоятельными программами, так и интернет-приложениями.
Типичная BPMS состоит из следующих основных компонентов:
- Среда исполнения бизнес-процессов
- Среда разработки бизнес-процессов и связанных с ними объектов
- Клиент-оповещатель о поступивших заданиях
- Компонент-коннектор к другим информационным системам
Также BPMS может содержать симулятор бизнес-процессов, используемый для отладки бизнес-процессов перед их загрузкой в промышленную систему.
Среда исполнения бизнес-процессов – это основной компонент BPMS. Она реализует исполнение экземпляра бизнес-процесса в соответствии с его определением. Этот компонент содержит определения загруженных в него бизнес-процессов и выполняющиеся экземпляры бизнес-процессов. Генерирует списки заданий и визуальные формы, соответствующие заданиям. Как правило, среда исполнения бизнес-процессов позволяет создавать и изменять свойства пользователей, а также дает возможность устанавливать различные права на объекты системы.
Среда разработки бизнес-процессов и связанных с ними объектов служит для создания и модификации исполнимых бизнес-процессов. В этой среде определяются последовательность выполнения шагов бизнес-процесса и данные, назначаются роли участникам процесса, вводятся правила маршрутизации, определяются графические формы заданий, используемые участниками бизнес-процесса для выполнения задач. Среда разработки позволяет сконструировать графическую схему бизнес-процесса с описанием ее деталей в виде свойств отдельных элементов (действий, подпроцессов, маршрутных узлов и т.д.) или бизнес-процесса в целом. Среда разработки — инструмент разработчика бизнес-процессов (бизнес-аналитика), он, в частности, обеспечивает внесение изменений в бизнес-процесс путем простой модификации графической схемы и свойств элементов.
Клиент-оповещатель о поступивших заданиях представляет собой компонент, обеспечивающий доступ пользователей к функциональности среды исполнения бизнес-процессов. В частности, он: Отображает списки заданий и визуальные формы заданий. Позволяет пользователям выполнять задания. Позволяет администратору системы устанавливать права на объекты системы. Дает возможность осуществлять мониторинг исполнения экземпляров бизнес процессов. А также реализует оповещение пользователя о поступивших задачах.
Компонент-коннектор к другим информационным системам в различных BPMS реализован по-разному. В данной статье будем рассматривать компонент-коннектор, представляющий собой набор специальных приложений — бот-станций. Каждая бот-станция должна располагаться на отдельном сервере, одна из бот-станций (локальная бот-станция) может располагаться на том же сервере, что и среда исполнения. Бот-станции содержат специальные сущности — ботов, которые периодически опрашивают среду исполнения. Боты представляют собой автоматических исполнителей, чем-то напоминающих человека (такая организация коннектора более удобна управленцам, — им легче думать в этих таких терминах). Если выполняющиеся в среде исполнения экземпляры бизнес-процессов содержат задачи для ботов, загруженных в бот-станцию, то боты выполняют эти задачи и возвращают результаты работы в среду исполнения. В частности, при этом боты могут обращаться к другим информационным системам.
При помощи интерфейсов для работы с заданиями исполнителей пользователь может:
- Получать, фильтровать, выполнять задачи, генерируемые экземплярами бизнес-процессов
- Запускать новые экземпляры бизнес-процессов
- Просматривать состояния выполняющихся экземпляров бизнес-процессов
- Загружать в среду исполнения новые определения бизнес-процессов, или новые версии уже содержащихся в среде исполнения определений бизнес-процессов
Рисунок 4. Пример интерфейса, отображающего список задач пользователя.
Рисунок 5. Пример интерфейса, в котором можно запускать новые экземпляры бизнес-процессов и загружать новые определения бизнес-процессов.
При помощи интерфейсов для администрирования системы администратор может:
- Создавать-удалять пользователей и группы пользователей
- Включать (исключать) пользователей в группы
- Раздавать права на объекты системы пользователям и группам пользователей
- Принудительно останавливать экземпляры бизнес-процессов
- Добавлять, изменять правила замещения пользователей
Рисунок 6. Пример интерфейса, в котором можно просматривать состояния выполняющихся экземпляров бизнес-процессов
Используя среду разработки, бизнес-аналитик может разрабатывать бизнес-процессы, включая бизнес-правила, различные элементы коннекторов к внешним системам и другие элементы, а также загружать их в среду исполнения.
Рисунок 7. Пример интерфейса, в котором можно разрабатывать бизнес-процессы
При помощи симулятора бизнес-процессов можно тестировать разработанные бизнес-процессы на условной конфигурации на клиентском компьютере аналитика, не загружая их в промышленную систему.
Описание работы пользователей и компонентов BPMS
На одном сервере запускается среда исполнения бизнес-процессов. На нескольких серверах могут быть запущены бот-станции.
На клиентских компьютерах пользователей запускается клиент-оповещатель о поступивших заданиях или браузер, в котором открывается web-интерфейс BPMS.
На клиентских компьютерах аналитиков запускается среда разработки бизнес-процессов и связанных с ними объектов. Также на клиентских компьютерах аналитиков запускается симулятор бизнес-процессов.
В среде исполнения выполняются экземпляры бизнес-процессов.
Размещенные в бот-станциях боты (автоматические исполнители заданий) периодически опрашивают среду исполнения бизнес-процессов. Если выполняющиеся в среде исполнения экземпляры бизнес-процессов содержат задачи для ботов, то боты выполняют эти задачи и возвращают результаты работы в среду исполнения.
Web-интерфейсы и клиенты-оповещатели периодически обращаются к среде исполнения и отображают задачи пользователей.
Пользуясь web-интерфейсом BPMS пользователи:
- Получают, фильтруют, выполняют задачи, генерируемые экземплярами бизнес-процессов
- Запускают новые экземпляры бизнес-процессов
- Просматривают состояния выполняющихся экземпляров бизнес-процессов
Пользуясь web-нтерфейсом BPMS администраторы:
- Загружают или изменяют определения бизнес-процессов
- Создают или изменяют параметры пользователей и групп пользователей
- Раздают права на объекты системы
- Изменяют параметры ботов и бот-станций
При помощи среды разработки аналитики:
- разрабатывают и модифицируют бизнес-процессы
Для разработки бизнес-процесса аналитику надо:
- при помощи «мыши» нарисовать схему бизнес-процесса
- определить участвующие в процессе роли, назначить для ролей исполнителей
- задать данные бизнес-процесса (переменные процесса)
- определить графические элементы форм заданий бизнес-процесса
- связать узлы схемы бизнес-процесса с соответствующими ролями пользователей или ботов (автоматических исполнителей)
После того, как бизнес-процесс разработан, он загружается в BPMS. После этого можно запускать экземпляры данного бизнес-процесса и выполнять генерируемые ими задания.
При помощи симулятора бизнес-процессов аналитики тестируют разработанные бизнес-процессы на условной конфигурации перед загрузкой их в промышленную BPMS.
Клиенты-оповещатели сигнализируют пользователям о появлении новых заданий.
Реинжиниринг и эволюционное управление бизнес-процессами
Исторически процессный подход сначала включал в себя только бизнес-процессы для аналитического моделирования. В рамках этого подхода проводилось выделение бизнес-процессов предприятия, анализ выделенных бизнес-процессов и генерировались предложения по повышению эффективности бизнеса путем изменения бизнес-процессов. Далее производилось внедрение измененных бизнес-процессов на предприятии.
Так как изменение бизнес-процессов для аналитического моделирования не связано с автоматизацией, внедрение измененных бизнес-процессов являлось дорогой процедурой, предусматривало переобучение персонала, изменение должностных инструкций, часто — изменение организационной структуры предприятия. Такие изменения очень затратно делать последовательными небольшими шагами. Поэтому такие изменения производились редко, но сами изменения являлись значительными. В литературе такое преобразование бизнес-процессов получило название — реинжиниринг бизнес-процессов. Реинжиниринг бизнес-процессов подразумевает радикальное перепроектирование бизнес-процессов предприятия для достижения существенного эффекта производственно-хозяйственной и финансово-экономической деятельности.
При использования исполнимых бизнес-процессов стоимость внедрения изменений относительно небольшая, поэтому в этом случае часто применяется эволюционное изменение бизнес-процессов. На предприятии устанавливается BPMS, разрабатываются, загружаются в систему и внедряются в эксплуатацию бизнес-процессы «как есть», после чего они постепенно, в течение длительного времени преобразуются в бизнес-процессы «как надо» и постепенно эволюционируют вслед за изменением условий деятельности предприятия.
К бизнес-процессам часто привязывают расчет различных показателей эффективности деятельности предприятия (КПЭ), как финансовых, так и нефинансовых. Существуют методы процессного управления, основанные на КПЭ, предусматривающие предвидение результатов деятельности и планирование путей их достижения.
Для образного понимания того, как бизнес-процессы используются в качестве инструмента управления бизнесом в случае эволюционного управления с использованием КПЭ А. Белайчук (председатель Ассоциации профессионалов по управлению бизнес-процессами) предложил следующую аналогию: Управление предприятием можно образно сравнить с управлением автомобилем. В этом случае КПЭ являются аналогом того, что видит водитель — вид через лобовое стекло автомобиля и значения показателей датчиков (скорость, давление масла, количество оборотов двигателя, количество бензина и т.п.), а бизнес-процессы выполняют роль руля, педалей (газ, тормоз, сцепление) и рычага переключения передач автомобиля. То есть, служат для непосредственного управления траекторией в пространстве и времени.
Современный взгляд на процессное управление предполагает разнесение управления по нескольким уровням.
На первом уровне рассматривается общее стратегическое управление предприятием. На этом уровне используются бизнес-процессы для аналитического моделирования. Задача бизнес-процессов данного уровня – формирование общих представлений об основных бизнес-процессах предприятия и обмен этими представлениями между управленцами. Этот уровень не предполагает реальное исполнение разработанных бизнес-процессов.
Описать последовательности действий в бизнес-процессах первого уровня можно и просто в виде текста, такие описания называются — текстовые регламенты. Однако визуальную информацию люди воспринимает существенно быстрее и легче, чем текстовые описания. Поэтому наибольшее распространение получили именно графические представления бизнес-процессов для аналитического моделирования.
На верхнем уровне процессного управления также используются средства имитационного моделирования. Этот класс программ не предусматривает реального исполнения бизнес-процессов предприятия в компьютерной среде. Системы имитационного моделирования содержат настраиваемую статистическую модель бизнес-процессов организации. Задавая различные параметры этой модели и многократно «проигрывая» бизнес-процессы на условных автоматических пользователях, можно получить значения различных показателей деятельности и таким образом прогнозировать изменение реальных показателей предприятия в будущем в зависимости от тех или иных изменений в бизнес-процессах. Если статистическая модель построена правильно, то имитационное моделирование может быть средством определения оптимальных параметров бизнес-процессов.
На следующем уровне стратегические бизнес-процессы предприятия переводятся в исполнимые бизнес-процессы. На этом уровне схемы бизнес-процессов принято изображать в нотациях BPMN, UML (Диаграмма деятельности) и родственных им. На этом уровне текущая деятельность предприятия представляется в виде множества выполняющихся экземпляров бизнес-процессов.
Следующий (третий) уровень процессного управления соответствует бизнес-объектам предприятия. Состояние всего предприятия на текущий момент времени определяется состоянием всех бизнес-объектов предприятия на этот момент временя. Процессный подход предполагает, что состояния бизнес-объектов изменяются экземплярами бизнес-процессов второго уровня при выполнении соответствующих заданий. Для этого слоя в качестве хранилищ традиционно используются системы управления контентом (ECM-системы), или системы управления базами данных. Также возможно на этом уровне использовать ERP-системы. Для объяснения концепции бизнес-объектов можно воспользоваться аналогией с бухгалтерским учетом: бухгалтерское состояние предприятия на фиксированный момент времени определяется денежными остатками на счетах бухгалтерского учета, а изменение состояния предприятия определяется бухгалтерскими проводками. В рамках данной аналогии проводки будут соответствовать бизнес-процессам, а остатки на счетах — бизнес-объектам.
Математические основы исполнимых бизнес-процессов
Успех языка запросов к реляционным базам данных SQL обычно связывают с тем, что в основе его лежит солидная математическая теория — реляционная алгебра. Разработчики языков описания исполнимых бизнес-процессов также стараются положить в основу языка серьезную математическую теорию.
Большинство существующих языков описания исполнимых бизнес-процессов в той или иной степени относят к одной из двух математических теорий:
- теория сетей Петри
- концепция Пи-исчисления
Теория сетей Петри основана на классической теории графов, является расширением теории конечных автоматов. Она возникла в 60-х годах ХХ века и с тех пор постоянно развивается. Теория сетей Петри — сложная, очень хорошо разработанная теория, в ней строго определены такие понятия, как состояния, условия, переходы и т. п. Также теория включает графическую нотацию (систему графических обозначений, на основе которых можно рисовать соответствующие графы). Сети Петри хорошо исследованы математиками — установлены многие их свойства, доказано большое количество теорем.
Практическое использование теории сетей Петри в основном было связано с описанием поведения очень сложных систем, например элементов интегральных схем. Построив для системы соответствующую сеть Петри, далее можно было использовать результаты соответствующих теорем и таким образом исследовать свойства системы.
Для описания BPMS использовать концепцию сетей Петри в явном виде неудобно, так как графическая нотация сетей Петри не является интуитивно понятной. Бизнес-аналитикам, а тем более менеджерам с ней сложно работать. Кроме того, появились некоторые классы бизнес-процессов, которые нельзя описать с ее помощью.
Наследниками теории сетей Петри стали первые языки определения бизнес-процессов (например, WPDL и XPDL коалиции WfMC). Они основаны на теории графов и концептуально включают в себя многие понятия и концепции сетей Петри: узлы, переходы, условия и т.д. Однако, в отличие от сетей Петри, эти языки не являются строгими — в ряде случаев можно составить такие предложения языка, которые будут синтаксически допустимыми, однако поведение порожденного бизнес-процесса не будет определено однозначно.
Концепция Пи-исчисления (Pi calculus) была разработана в конце 80-х годов ХХ века Робином Милнером и основана на алгебре параллельных процессов. В отличие от сетей Петри, математическими объектами Пи-исчисления являются не графы, а выражения над элементами специальных множеств и преобразования над этими выражениями. В настоящее время Пи-исчисление является перспективной, но еще молодой и развивающейся теорией, в ней много открытых вопросов и нерешенных проблем. Математически было доказано, что функциональные возможности Пи-исчисления выше, чем сетей Петри.
Разработчики языков BPEL и BPML утверждают, что эти языки обладают более высокой выразительной мощностью, чем языки, основанные на сетях Петри, так как в основе этих языков лежит Пи-исчисление. Однако существуют и скептики, считающие, что связь этих языков с концепцией Пи-исчисления не очевидна, и предполагающих, что эти утверждения ближе к маркетинговому ходу, чем к реальному использованию этой теории при построении данных языков.
Поделиться с друзьями
sshikov
Я вполне с этим согласен.
Ну т.е. не то чтобы это был чистый пиар, но большая часть маркетинговых материалов очень сильно преувеличивает достоинства, и замалчивает недостатки. Это факт.
amikheev
Большинство автоматизируемых бизнес-процессов, действительно, простые. Однако, это не мешает получению финансового эффекта. На конвейере часто тоже простые операции выполняются, а финансовый эффект от конвейера — значительный.
Вообще бывают, хотя их и не много,
sshikov
Ну, по сути то что автоматизируется — это и есть конвейер. Как правило.
Shortki
На схеме очень хорошо видно, что циклы плохо ложатся на BPMN. А представленная схема не сколько сложна, сколько плохо описана и перегружена, отчего неочевидна и кажется сложной.
amikheev
Данную схему имеет смысл разбить на несколько подпроцессов (т.е. на несколько вложенных друг в друга схем). Тогда восприниматься она будет легче. Я не стал этого делать, т.к. при наличии подпроцессов трудно все объяснить или показать на одном скриншоте.
Но, в любом случае, схемы алгоритмов принятия решений в этом бизнес-процессе достаточно сложные по сравнению со схемами обычных бизнес-процессов. Эта сложность объективна, она останется даже, если разбить все на подпроцессы.
Shortki
Ценность хорошей диаграммы в том что её легко понять, а не в том что можно «все объяснить или показать на одном скриншоте». Процесс можно представить с разным уровнем детализации, если на диаграмме более 20 объектов, значит уровень детализации следуют понизить, умело орудуя drilldown можно любую схему сделать понятной.
Представленная схема не кажется мне сложной, любая реальная схема «обрастает» подробностями, делая её ценнее, но не всегда имеет смысл эти подробности сразу выкладывать на верхнем уровне. Хотя должен признать «сложные схемы» выглядят солиднее, иногда это имеет свой положительный эффект.
amikheev
Да. Надо стараться, чтобы схема любого подпроцесса свободно умещалась на экране компьютера. То есть, если элементов много и что-то не умещается, надо какие-то части схемы переносить в подпроцессы.
amikheev
В данном случае возможно взаимодействие аналитика с программистом. Это проверено на практике:
Аналитик «заказывает» у программиста нужные ему компоненты- графические элементы форм заданий, коннекторы к внешним хранилищам и т.п. — Программист реализует их и устанавливает в палитру среды разработки. После этого аналитик использует их в своих бизнес-процессах.
sshikov
Моя практика показывает, что все равно получается плоховато. По ряду причин: основная из которых в том, что процессы это плохой вид повторно используемого компонента. Коннекторы — это да, это достаточно классический вид, широко используемый в других проектах. А вот сами процессы — это с трудом.
amikheev
С повторным использованием бывают сложности. Оно возможно, в частности, подпроцессы стараются разрабатывать так, чтобы они могли быть использованы в большом количестве процессов. В какой-то степени это напоминает процедурное программирование с повторно используемыми процедурами. А аналог объектной модели в бизнес-процессы пока еще не получилось интегрировать. Это приводит к необходимости дублировать часть функциональности в разных бизнес-процессах.
Но, несмотря на определенные сложности, процессный подход может принести качественные преимущества бизнесу. Например, специалисту, хорошо разбирающемуся в том, как при помощи изменения тарифных планов и предоставления скидок разным категориям клиентов повышать продажи, это дает возможность очень быстро управлять продажами, немедленно реагируя на изменения на рынке при помощи оперативной модификации находящиеся в эксплуатации бизнес-процессов. — Не надо каждый раз «дергать» программиста, можно самостоятельно видоизменить схему и параметры. К программисту в этом случае надо обращаться редко, для создания новых элементов бизнес-процессов.
Можете привести примеры кейсов из вашей практики, процессная реализация которых была неудачной?
sshikov
Так ведь понятно, почему не получается переиспользовать. Во всяком случае пока для бизнес процессов нет нормальной модели, и устоявшейся практики, хотя бы такой, как для ООП.
Что до моей практики, то я бы так сказал — самая большая проблема при использовании конкретно BPMN состоит как раз в том, что из этого пытаются сделать язык программирования, и получается отвратительно. Т… е даже если все работает — это получается настолько невнятно, что сопровождать потом практически невозможно. Т.е. примерно так:
amikheev
Языки описания бизнес-процессов пока все-таки не позиционируются как полноценные языки программирования. К ним нельзя предъявлять такие высокие требования. Но существует ли какая-то другая технология, не имеющая описанных выше сложностей, позволяющая специалисту предметной области, не знакомому с программированием, быстро и гибко модифицировать бизнес-логику и структуру приложения?
А такая возможность может существенно улучшать финансовые результаты автоматизируемого предприятия.
Многие широко используемые в настоящее время технологии сначала были несовершенны. Главное, чтобы здравая идея в технологии была. В новой технологии сложности обязательно будут. Но, если идея хорошая, с течением времени сложности будут преодолены.
Danov
Shortki
Когда я разрабатывал приложение для описания БП, то изначально намеревался воспользоваться BPMN, но чем больше я прикладывал эту нотацию к интерфейсу, тем больше осознавал насколько она ограничена и искусственна. В итоге оставил попытки и разработал собственную нотацию, что было спорным, но как сейчас уже понятно верным решением.
Попутно избавился от порока (с моей точки зрения) большинства систем управления процессами и проектами — процессный подход. Во всех диаграммах всегда фигурируют процессы, которые много и подробно расписаны, но нигде не отведено места целям исполнения процессов и необходимым для этого ресурсам. При изучении таких диаграмм складывается представление, что процессы существуют ради процессов, а цели достигаются сами по себе. Мне кажется это пошло от консультантов, которые были пионерами в описании процессов, они берут с клиентов за часы исполнения работ, поэтому крайне заинтересованы представлять суть работы именно в процессах, и крайне не заинтересованы акцентировать внимание на конечных результатах своей деятельности. Отчего во всей «процессной науке» случился перекос.
Да, и забавный нюанс, ещё не разу не встретился бизнес-аналитик который описывая какую-нибудь ситуацию не приводил бы аналогию с мерседесом :)
amikheev
Процессный подход — это не только графическая нотация. Для исполнимых бизнес-процессов нужно еще определить механизм назначения исполнителей на роли, задать структуры данных и т.д.
Я при объяснении процессного подхода часто привожу аналогию с велосипедом :)BPMN — не единственная возможная нотация, применяющаяся в процессном подходе. Например, я иногда использую UML (Activity Diagramm), есть и другие «процессные» нотации. Но BPMN «продвигает» очень активная команда. Вполне возможно, что чисто «маркетинговыми» приемами остальные нотации будут вытеснены ей на периферию предметной области.
Danov
Поделитесь разработанной нотацией. Хабр — идеальное место для обсуждения.
Shortki
Можете посмотреть здесь, там на странице общее описание приложения inShort, но есть ссылка на pdf с документацией где сам формализм описан вполне подробно.
Tiamon
Слишком много народу паразитирует на этих системах.
А сами системы паразитируют на бизнесе. )
BPMN действительно мало применимы, пока. Все красивые интерфейсы как правило на работают в стоке и требуют длительного и мучительного допиливания. То что красиво на картинке и в презентации превращается в ад, для разработчиков.
Да и мегаграфики, часто рисуют те, кто ни разу не был на конкретном производстве и не понимает живой процесс.
Короче во всем здравый смысл и золотая середина, не ведемся на презентации, графики апробируем на живом процессе. Упрощаем систему, максимально, не строем сложных процессов, разбиваем их на несколько и т.д. Выбирая софт сразу узнаем сколько будет стоить допилить его под себя )
amikheev
Да. Это, к сожалению, имеет место.
Технология эта пока не совершенна. Работать в рамках этой технологии непривычно и тяжело как специалистам предметной области, так и программистам. Но эффект от ее применения есть. В ее основе лежит здравый подход. Не страшно, что пока «шелухи» разной вокруг нее очень много. С течением времени все это должно «рассосаться», текущие проблемы будут решены, технология должна стать широко используемой в бизнесе.
Danov
За BPM системами я лет 15 слежу. Даже, все двадцать. Проблема BPMS в том, что разработчики процессного подхода пытаются повторить путь разработчиков информационных систем. Т.е. основателям BPMS нужно было бы изначально изучить Computer Science и уже затем бизнес.
А получилось, что ребята выучились на манагеров и пошли писать свой язык и его интерпретатор. Оделись в солидные костюмы, просят солидные финансы, а по факту их уровень алгоритмического мышления на уровне старшеклассника, и могут автоматизировать лишь не более 5% процессов предприятия, типа учета командировочных расходов, т.е. постфактум мелкий кусочек даже учетных систем. А когда речь заходит о планировании, о развитии предприятия, тут у них полный провал. Далее чеклистов согласования заявок мысль не работает. Поддержка версионности процессов вообще к хаосу ведет. А надо бы не шишки набивать, а детально изучить плюсы и минусы систем управления версиями и систем поддержки коллективной разработки ИС.
По мне так Adaptive Case Management и его совмещение с системами управления контентом, более полезное направления развития BPM в автоматизации постоянно эволюционирующих социальных процессов.
А за поднятую тему и детальный разбор плюс вам в карму и за статью!
amikheev
Это — не простой вопрос. Можно придумать разные интересные и полезные технологии, которые никто не будет использовать в силу сложности их освоения. Данная технология предназначена для управленцев и разрабатывали ее тоже управленцы (менеджеры), поэтому она соответствует их мышлению и менеджеры, хотя и с трудом, готовы ей пользоваться. Похоже, что таким не «прямым» путем, постепенно улучшая и, с течением времени, заимствуя решения из Computer Science, можно широко внедрить этот подход в практику и сделать реально эффективным.
А если изначально сделать все «как надо», то менеджеры не поймут, изучать-использовать откажутся и все это будет не востребовано.
Danov
Думаю, зря вы подстраиваетесь под менеджеров. Например, современная системная инженерия (та что про разработку железа и бетона) — берет из Software Engineering практики пачками и адаптирует их себе во благо. Например, agile методологию.
Эта точка зрения понятна и допустима, если бы не 15...20 лет эволюции BPMS. Очень похоже, что не туда эволюционирует.amikheev
Я смотрю на это гораздо более оптимистично. За 15 лет ситуация в данной области все-таки заметно улучшилась. Начиналось все с проприетарных систем, а сейчас уже есть OpenSource системы, которые можно реально использовать на предприятиях.
Oleg_Sh
Компания, где я работаю, также занимается автоматизацией бизнес-процессов. Но это одно из направлений нашей деятельности, мы автоматизируем не все подряд процессы, а только некоторый подкласс, но все описанные вами нюансы у нас встречаются.
У нас тоже был модуль, работавший как ваш BPMS-движок. Там можно было рисовать в графике процессы, состоявшие из заданий, соединять их стрелочками, и т.д. — все как у вас. Мы даже это внедряли, но потом отказались от этого подхода. Почему:
1) Реальный процесс получался из десятков задач. Диаграмма занимала несколько экранов, ходила петлями и змейками — жуть.
2) Все проблемы с переиспользованием и версионированием, о которых в коментах уже говорили.
3) Если на каком-то шаге возникала программная ошибка, то процесс падал и без участия программиста не оживал. Ну как пример: пользователь вбил адрес в каком-то новом формате, о котором аналитики не подумали. Код свалился с ошибкой, процесс остановился — ждем программиста. В результате пара человек просто сидела на поддержке 100% времени, разбирая целыми днями эти ошибки.
Но самый большой гвоздь в крышку гроба был забит, когда пришел очередной заказчик, и выдвинул такие требования:
— Хочу, чтобы некоторые задачи в некотором конкретном процессе можно было отменять.
— А еще некоторые задачи мне хочется менять местами — опять же, в конкретном инстансе конкретного процесса. Ну вот попался такой особый случай — менеджер должен иметь возможность кое-что перепланировать.
— А еще бывает, что менеджеру хочется в некотором конкретном случае добавить несколько дополнительных задач.
Самое ужасное, что эти требования — нормальные, если речь идет о длительном процессе с уникальными особенностями. Представьте, что вы автоматизируете бизнес строительной компании, которая строит коттеджи по уникальным проектам. Для каждого участка строительства надо предусмотреть разное количество задач. Если эти задачи еще и делаются в параллели, то средствами BPMS это не решается никак.
В итоге сейчас в нашей компании есть средство, которому эта задача «по зубам». Я не знаю, до какой степени об этом можно рассказывать. В википедии навскидку похожего не нашел. Скажу только, что конкретный вид процесса каждый раз генерируется автоматически. Если кому-то интересно — попробую сделать статью об этом и опубликовать через корпоративный блог.
amikheev
Обычно путем декомпозиции, вынося участки схемы в подпроцессы, можно существенно улучшить понимаемость схем процессов. Если, например, бизнес-процесс состоит из 7 шагов, каждый из которых является подпроцессом, то на диаграмме процесса будет всего 7 элементов. Однако, при клике на любой из этих элементов, BPMS откроет схему этого подпроцесса. В случае четырех уровней вложенности для подпроцессов из 7 элементов, 4-ый уровень будет содержать 2401 задачу, при этом каждая схема будет состоять только из 7 элементов.
Для реальных бизнес-процессов, конечно, все не так просто. При декомпозиции надо учитывать не только количество элементов, но и бизнес-логику процесса. Но, в целом, путем декомпозиции понимаемость схем можно существенно улучшить.
Эти проблемы пока не решены. Приходится иногда использовать дублирование, которого, конечно, хотелось бы избежать.
Если такая ошибка связана с неправильно введенными данными, то многие BPMS позволяют исправить ее без программиста. — Администратор системы может изменить значение переменной конкретного экземпляра бизнес-процесса, при этом в историю действий с экземпляром процесса будет добавлена соответствующая запись.
Для таких действий предусмотрен элемент «Бизнес-Исключение»
Это классическому процессному подходу не очень хорошо соответствует. Все же процессный подход появился как аналог конвейера. Во многих BPMS сделать такие изменения бизнес-процессов можно, но делать их будет неудобно и выглядеть они будут неестественно.
Для таких операций был придуман Adaptive Case Management, но он отличается от традиционного процессного подхода.
В случае длительных процессов есть методы перевода экземпляров бизнес-процесса на новую версию определения бизнес-процесса. При этом в новый экземпляр бизнес-процесса переносятся данные и точки управления из старого экземпляра. Если версии не очень сильно отличаются, такое преобразование тоже можно сделать без участия программиста.
Процессный подход не предназначен для решения таких задач. Для таких задач надо применять управление проектами. Для этого разработан другой класс программного обеспечения. Бизнес-процессы предполагают многократное выполнение одних и тех же цепочек действий. Проект предполагает однократное выполнение, контроль ресурсов, возможность существенного отличия фактических действий от плановых и т.п.
В проектном подходе можно использовать процессное управление как вспомогательное направление для автоматизации использующихся во многих проектах одних и тех же рутинных процедур. Но основным в этом случае все равно должно быть проектное управление.
Интересно. Поместите ссылку на блог.
Oleg_Sh
У нас также использовались подпроцессы, все это было возможно. Однако я много раз смотрел товарищам через плечо и видел, как они скролят направо-налево и вверх-вниз какие-то змеиные кольца. С одной стороны, мир не идеален, и, если приложить усилия, наверняка можно было сделать процесс более читаемым. С другой стороны, эти люди не враги себе, наверняка есть большие сложности с тем, чтобы все упростить.
Но было бы интересно увидеть конкретные примеры с вашей стороны. В реальном решении, на сколько сложны бизнес-процессы?
Из написанного можно сделать вывод, что процессы — это максимально упрощенная версия проектов.
«Проект предполагает однократное выполнение» — естественно, однократное выполнение не автоматизируется, но мой пример — строительство коттеджей по уникальным проектам — можно представить как процессы с вариабельными частями, либо типовые проекты. И это уже можно автоматизировать.
«контроль ресурсов» — тут не понял. При выполнении процесса легче легкого контролировать ресурсы. Как и другие показатели.
«возможность существенного отличия фактических действий от плановых» — что значит «существенного»? Если в процессе стоит ветвление по условию, это уже проект, или еще нет?
Ну и т.д.
Danov
Danov
Ваш пример со строительством коттеджей ровно о том же.
Именно по этой границе происходит борьба автоматизаторов PM и BPM, особенно, если это две независимых команды. По мне так должна быть одна система, в которой гармонично переплетаются PM/BPM/ACM. И далее выясняется, что ИС должна быть тесно интегрирована с ERP & CRM.
Oleg_Sh
Как в известном анекдоте: «мышки, станьте ежиками».
amikheev
Я стараюсь использовать простые процессы. Часто вместо большого и сложного бизнес-процесса можно сделать набор относительно простых процессов, взаимодействующих друг с другом через данные или сообщения. Наиболее сложные процессы, которые я разрабатывал, содержали порядка ста элементов, разнесенных по четырем уровням вложенности подпроцессов. На одной схеме «промежуточного» процесса было два-три вызова подпроцессов.
Danov
Конечно интересно! Пишите!
Можно выстроить данные ИС-системы по оси PM-BPM. Первые могут быть и с генератором процесса (или браться из шаблонов), который затем вручную корректируются. Идеальная система должна быть где-то посередине, поддерживая обе парадигмы, как встраиваемые в друг-друга фрагменты. Похоже, у вас нечто похожее реализовано. Есть еще крайность Adaptive Case Management, который больше на чат с набором правил похож и накапливанием заполненных переменных.
Oleg_Sh
Ошибка может проявиться через много шагов после того, как были вбиты данные. Естественно, этого пытаются избежать, но мир не идеален и всякое бывает. Проблема еще и в том, что в том подходе, который описан в статье, задача отката не решается, если только специально не создавать точки отката. Впрочем, и с точками отката тоже не все ясно — ошибочный процесс мог поменять что-то вне своих локальных переменных — как это откатить?
Danov
Понятно, что откаты нужно отдельно прграммировать. Минимально, что можно сделать автоматически, это запустить процесс с прежней точки и попросить пользователей подтвердить свое прежнее решение. И для разбора полетов хранить всю историю изменения переменных.
Опять же, универсальное решение вряд ли есть. Можно ограничить возможность редактирования переменных, а также хранить историю изменений. Можно реализовать механизм отката транзакций.Oleg_Sh
Можно все, хотелось бы пример реального решения.
amikheev
Не совсем понятно, что делать, если кто-то не подтвердит свое прежнее решение.
Danov
В одной_большой_конторе просто ввели штрафы за просрочку заявок в списке входящих.
amikheev
Для таких случаев было введено понятие «Компенсация». Если на этапе разработки бизнес-процесса для узла-действия известно, что после выполнения этого действия может быть откат, то с ним связывается цепочка действий, которая должна быть выполнена в случае отката (В нотации BPMN соединяется специальной пунктирной линией).
Например, если бизнес-процесс связан с оформлением турпоездки, то при изменении клиентом уже частично оформленного варианта может потребоваться отменить бронирование гостиницы, сдать билеты и т.п.
Oleg_Sh
Вы немного не о том написали. Вы написали о бизнес сценарии «отмена турпоездки» или «изменение в планах поездки». Наша система тоже это умеет — надо заложить дополнительные правила по отмене ненужных действий. Система построит новый процесс, в котором будут шаги по отмене ненужных действий и совершению новых нужных (например, отменить бронирование гостиницы, забронировать яхту на эти же даты).
Но это просто дополнительные требования, которые могут быть, а могут и нет. Изначально я писал о том, что если произошла техническая ошибка (код выбросил исключение), то нет общего способа решить проблему без программиста. Предложили вариант откатиться на последнее ручное действие — это не подходит, т.к. отмена в общем случае не реализуема.
Пример. Процесс планирования турпоездки. Одно из действий — бронирование гостиницы — автоматизировано. Наша система посылает в систему бронирования запрос, система бронирования что-то отвечает. Внезапно интерфейс системы бронирования чуть-чуть поменяли, или решили забронировать какую-то нестандартную гостиницу. Ответ от системы бронирования пришел и был провалидирован, но на одном из дальнейших шагов (скажем, распечатка памятки для клиента) произошла системная ошибка — гостиница называлась корейскими иероглифами, для которых не нашлось шрифтов.
Автоматически подобные ошибки не решить: мы не знаем, какие шаги отменять. И как их правильно отменять. Если мы попробуем включить процесс «компенсации», то он тоже может упасть на каком-нибудь шаге вроде «распечатки квитанции об отмене».
amikheev
Если в эксплуатации проявилась ошибка в коде коннектора, обработчика или в логике бизнес-процесса, — это может вызвать проблемы.
Если ошибка в логике, — бизнес-аналитик ее исправляет и передает администратору BPMS новую версию бизнес-процесса для загрузки в систему. После установки новой версии, новые экземпляры данного бизнес-процесса уже будут нормально исполняться, но надо еще исправить старые экземпляры. Для этого применяются различные варианты действий:
Если ошибка в коде, то программист исправляет ее, собирает новый компонент и пишет заявку администратору BPMS на обновление компонента в системе. Иногда загрузки нового компонента достаточно, чтобы «зависшие» экземпляры пошли дальше. Если нет, то можно дополнительно применить описанные выше варианты действий.
При эксплуатации BPMS важно, чтобы программист и бизнес-аналитик работали с промышленной системой не напрямую, а через администратора, а также чтобы все корректирующие действия фиксировались и оформлялись соответствующими документами.
Иначе можно потерять контроль над системой — никто не будет понимать, почему система себя так ведет, надежны ли содержащиеся в ней данные и как можно исправить ошибки…
pan_KOST
А какому виду относится комплекс ИС в составе PLM+PDP + ERP?
На мой взгляд, в реальном производстве, они работают именно как BPMS в изначальном своём понимании. Или я где то не прав?
Danov
Кстати да. Есть сходство с BPMS.
Сходу могу предположить, что BPMS более социальные, а PLM/PDM более железные.
pan_KOST
Скорее не железные, а относящиеся к реальном сектору и к реальному производству, а не к финансам, ИТ и другому менеджменту.
Хотя никто не мешает использовать оба варианта в крупной компании одновременно ( хотя в такой компании, скорее всего уже есть SAP, на базе которого можно творить очень многое =) )