Адаптивные бизнес процессы это

Адаптивное управление проектом – Adaptive Project Framework (APF, в русс.: АПФ) – дополняет «линейку» проектных моделей и методологий, которые работают в условиях частого изменения стартовых задач под запросы потребителя уже в ходе проекта. Вместе с Agile, Kanban, Scrum и другими управленческими моделями и подходами, Adaptive Project Framework входит в семейство так называемого «гибкого» менеджмента. В этом смысле APF вместе с остальными разновидностями «гибкого» менеджмента противостоит традиционному последовательному менеджменту и может внедряться как структурный каркас вместе с инструментарием изменяемого и процессного менеджментов.

• Область применения
• Принципы APF Управление
• Управление фактическими изменениями

Область применения APF

Разнообразие современных проектных практик даёт возможность выбирать их согласно принципу целесообразности в зависимости от:

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

APF в качестве части «гибкого» менеджмента начал формироваться в начале 21 века в США как ответ на управленческие сложности, которые возникали в IT-индустрии при ведении проектов. Большинство таких проектов не имело чётко сформулированных знакомых требований на начальном этапе. Их нужно было формулировать в ходе процесса, ориентируясь на обратную связь от потребителей (заказчиков), которые корректировали своими предпочтениями ход создания продукта. На начальном этапе APF формировались только стратегические требования с общим описанием возможностей и функционала. А корректировка промежуточных результатов с добавлением новой ценности продукта происходила после каждой итерации (этапа).

Моделирование бизнес-процессов | Naked BPM

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

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

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

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

Принципы APF

Как часть семейства «гибкого» управления, модель APF ориентирована на те же принципы, которые были сформулированы в манифесте Agile в 2001 году. В этих ценностных ориентирах:

1. на первое место ставились люди и их взаимодействие и только на второе – процессы и инструменты,
2. работающий продукт опережал по важности скрупулёзное документирование процессов,
3. живое сотрудничество было важнее чёткой регламентации взаимодействий по условиям контракта,
4. готовность к изменению оказывалась важнее первоначального плана.

Такие принципы описывали единый образ функционирования в реальных условиях отрасли разработки ПО, но их легко применять и в отраслях, сходных по типологическим характеристикам с IT-индустрией. К таким условиям относятся:

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

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

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

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

• Предприниматель обеспечивает постоянную обратную связь с потребителями, стоя за прилавком или рядом с продавцом.
• Предприниматель не закупает сразу десятки сортов кофе, предполагая множество вариантов его приготовления, а ограничивается 2-3 популярными сортами и 2-3 видами приготовления. Это сокращает стартовые расходы на закупку и позволяет оценить предпочтения потребителей. Деньги, полученные от первых продаж, возвращаются в бизнес для поддержания перспективной тенденции.
• Предприниматель не тратится сразу на концепт предприятия с фирменным стилем, а смотрит за реакцией посетителей. Если переодевание продавца в варианты фирменной одежды увеличивает «кассу», то эта тенденция прорабатывается в следующей итерации. Если данный фактор роли не играет, что демонстрирует статистика по итогам отведённого периода, то предприниматель отказывается от этой формы инновации в следующем периоде.
• Параллельно тестируется несколько независимых нововведения, результаты которых не влияют друг на друга. Как правило, таких нововведений не больше 2-3 в одной итерации.
• Если меняются условия, то меняется и варианты подхода. Например, при смене сезонов летом увеличивается спрос на кофе с мороженым или при возвращении студентов с летних каникул в соседнее общежитие меняются вкусовые пристрастия среднего потребителя и т. д.

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

Управление фактическими изменениями

В стандартной модели APF управление фактическими изменениями проявляется в следующих общих для любой отрасли формах:

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

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

Адаптивный менеджмент основан на «гибком» компенсаторном регулировании и управлении внутренними противоречиями.

Его эффективность косвенно подтверждается ещё и тем, что PMI (Институт управления проектами) включил итеративные и адаптивные практики в последнее издание PMBoK – Свода знаний проектного менеджмента, что предполагает возможность применения адаптивных методов и для крупных проектов.

Отзывы, комментарии и обсуждения

Источник: finswin.com

Adaptive Case Management (ACM)
Адаптивное ведение дел

ACM — Adaptive Case Management, адаптивное ведение дел — одно из направлений развития управления бизнес-процессами. В 2011 году, опубликованном в отраслевом издании CMSWire, отмечается, что подобные решения будут выделены в отдельное направление на рынке (из ранее выделенного сегмента BPM-систем), будут строиться как продолжение почтовых систем и ориентироваться на повышение удобства работы с задачами при наличии как структурированного, так и неструктурированного контента (гибкий пользовательско-ориентированный интерфейс, акцент на совместную работу и так далее) и в этом отношении будут интересны ECM-вендорам.

Adaptive Case Management (ACM) — это концепция, альтернативная концепции BPM. Альтернативная — это значит, что решается та же самая задача эффективной организации бизнес-процессов, но другими средствами. Если совсем кратко, то идейное различие в подходах можно охарактеризовать следующим образом:

BPM идет от структуры процесса, состава шагов, которые необходимо совершить, чтобы достигнуть цели. Данные могут возникать в ходе процесса, являясь полностью ависимыми от него. ACM идет от информации и бизнес-данных, возникающих в ходе работы и необходимых для того, чтобы считать результат достигнутым . Процессы возникают в контексте данных, а не наоборот.

1. Место ACM среди других технологий

Начнем с того, что BPM, Project Management (PM), ACM и ряд других управленческих технологий, применяются для управления деятельностью организаций.

Чтобы показать, каким образом ACM встраивается в практическую деятельность и каковы отличительные черты этой технологии именно в практическом применении, я воспользуюсь очень простой моделью деятельности, в которой выделены:

• цель;
• действие, направленное на достижение этой цели;
• исполнитель, производящий это действие.

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

Далее, рассмотрим следующие свойства каждого элемента этой модели: повторяемость (как возможность многократного повторного использования одних и тех же описаний и моделей) и предсказуемость (как возможность предварительного планирования).

Здесь знаками `+` и `-` отмечены свойства, которые были бы предпочтительны или, соответственно, нежелательны для данной технологии. Знаком `?` отмечены свойства, наличие или отсутствие которых мало влияет на технологию.

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

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

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

Но и тут проблемы: в регламенте не удастся зафиксировать ни процесс, ни его результат, ни даже его цели. А регулярно писать регламент под каждую вновь появляющуюся цель — это уровень технологий, о котором в ACM даже не заикаются. Далее, положим, что можно и от регламента отказаться, уповая лишь на инициативу работников умственного труда (knowledge workers). Но кто сможет показать хоть одну компанию численностью более десятка человек, где сотрудникам предоставлена полная свобода в целеполагании, выборе средств и методов работы? Конец доказательства.

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

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

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

2. Предельно конкретный пример

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

Казалось бы, при взгляде сверху, все просто. Но при погружении в детали начинаются `неприятности»:

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

В итоге, оптимальный алгоритм (и, соответственно, оптимальная схема данного этапа процесса) содержит массу ветвлений и с десяток различных состояний. И все это только для одного этапа процесса обработки заявки, рассчитанного на выполнение в течение нескольких минут реального времени!

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

Посмотрим, что изменится, если не пытаться описывать процесс, а попытаться описать результат, который требуется получить?

Если выписать все возможные комбинации результатов проверки злополучных четырех условий, пометить каждый вариант признаком `Принять` или `Отклонить`, свести варианты в таблицу и отсортировать их по наиболее часто проверяемым условиям, то получится… готовый к употреблению `чек-лист` (условия обезличены, так как это выдержка из документа ДСП):

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

Уже на этом микро-примере, хорошо видно, насколько меняется результат (в данном случае — организация работы оператора), если переместить фокус внимания со структуры процесса на структуру обрабатываемой информации. Также на этом примере видно, что применение `новейшей` концепции, на практике может приводить к уже известным решениям. Как говорится, `все новое — хорошо забытое старое`.

Также здесь можно упомянуть еще один пример построенной по принципам ACM инструкции, опубликованный Анатолием Юмашевым, а также замечательный пост Максима Смирнова об одной реализации бизнес-процессов чек-листами . Хотя, на мой взгляд, контрольный список действий — это не единственная из возможных реализаций чек-листов, но описана она очень хорошо.

3. Взгляд со стороны нормативной документации

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

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

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

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

4. Взгляд со стороны текущей деятельности сотрудников

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

Некоторое время назад в своем посте `Ахиллесова пята` процесса я поднимал вопрос о поисках альтернатив процессному управлению, когда речь идет о неустойчивых процессах. И, как по заказу, вскоре появился ACM, позиционируемый именно как такая альтернатива. Основной идеей тогда было — выявить устойчивые компоненты в неустойчивых процессах и найти способ автоматизировать устойчивую часть процессов. Теперь эту идею можно сформулировать более конкретно:

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

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

• Инициатор и его место в оргструктуре предприятия. Дает ответ на вопрос: кому нужен шаблон?
• Объект системы и его свойства, от которого инициируется задача. Отвечает на вопрос: в каком месте системы нужна инициация задачи по шаблону?
• Структура задачи. Отвечает на вопрос: какие ситуации может охватить данный шаблон?

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

• Структура задачи/Вложение — где была бы полезна кнопка на быстрый старт задачи?
• Структура задачи/Вложение/Исполнители — можно ли сразу заполнить маршрут задачи?
• Структура задачи/Вложение/Инициатор — кому показывать эту кнопку?
• Инициатор/Структура задачи — кому мы можем помочь с устранением рутины?
• Структура задачи/Инициатор — кому будет интересен данный шаблон?

Выводы, которые можно получать с помощью такого анализа:

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

Заключение

В статье я попытался представить тему ACM с четырех различных углов зрения. Закономерно, что результаты, получаемые в каждом случае, внешне значительно отличаются друг от друга. Это говорит о том, что концепция ACM достаточно нетривиальна.

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

• Источник — Гибкие процессы

Источник: www.tadviser.ru

Автоматизация бизнес-процессов. Часть 2. Adaptive BPM

Итак, в первой части было рассмотрено, какие бывают бизнес-процессы по степени их устойчивости к изменениям, технические концепции для реализации конкретного типа БП, а также пример логики добавления/удаления таска из адаптивной модели БП.
В этой части статьи собираюсь подробней описать, чем же adaptive BPM (aBPM) отличаются от normative BPM (nBPM) и от Adaptive Case Management (ACM), затем представить архитектуру получившейся aBPM системы.

На рисунке 1 хорошо виден переход от явно структурированных БП (nBPM) к неявно структурированным БП, проще говоря к ACM.

Нельзя сказать, что nBPM — это прошлый век, а за ACM — будущее автоматизации процесс менеджмента.

Для одних БП в одном контексте более применим один подход, а для других БП в другом контексте применим другой подход моделирования.

Примером может служить самый изъезженный БП «заявка на отпуск». Есть возможность реализовать этот процесс с помощью ACM, или же с помощью обычного TreeSet.

Это можно сравнить с забиванием гвоздя в доску. Годится взять молоток и забить гвоздь, а возможно взять и установку для забивания строительных свай, потом произвести расчёты по силе, амплитуде, углу удара и этой установкой забить гвоздь. Результат тот же — гвоздь забит, но насколько было сложное решение (включая проектировку и изготовление такой установки для свай) для решения простой задачи. А для забивания свай молоток совсем не подходит.

Важно понимать, какой инструмент и в каком контексте применять к задачам.

nBPM — хорошо подходит к чётко структурированным и коротким по длительности исполнения БП в пределах одного предприятия, например тот же БП «заявка на отпуск».

ACM — хорошо решают задачи с неявно структурированными БП, например в медицине и в страховании, когда каждая инстанция процесса может быть индивидуально смоделирована согласно возникшей ситуации. Несколько примеров применения АСМ описал maxstroy.

aBPM — на мой взгляд, нечто среднее, компромисс между чёткой структурой nBPM и сложным ACM. Хорошо применим в случаях непредвиденных изменений модели БП длинных по времени исполнения экземпляров процессов.

Типичный пример из финансовой отрасли «погашение кредита» (длительность исполнения БП до 30 лет) — в момент старта модель БП находится в актуальном состоянии и все запускаемые экземпляры процесса одинаковые. Однако в течении 30 лет возникают новые требования к модели процесса (например, изменения в законодательстве), и необходимые изменения применяются уже к запущенным экземплярам процесса «на лету», то есть без прерывания выполнения данного экземпляра. Все новые экземпляры процесса уже содержат в себе эти изменения, происходит так называемая эволюция БП.

По воле случая я наиболее часто имел дело с aBPM, о которой и пойдёт дальнейшее повествование.

Архитектура aBPM представляет собой «надстройку» над любым обычным BPM Engine.

Архитектура не зависит от производителя, что дает ещё одну возможность управления миграциями БП с одного BPM Engine на другой (например, как произошло с JBoss BPM, когда Red Hat отказался от поддержки и дальнейшей разработки этого BPM «движка»).

BPM-Adapter — инкапсулирует функционал общения с каждым типом BPM Engine; в данном примере будет взят только один тип BPM Engine — это open souce Camunda BPM (fork от Activiti BPM), но в принципе возможны любые комбинации.

PCS — является ядром системы, которое и управляет всеми процессами в BPM Engine. Например, при вызове функции запуска экземпляра процесса, PCS берёт на себя управление версиями моделей БП и решает, какую версию на каком BPM Engine запускать.

В следующей части расскажу о моделировании aBPM прoцессов.

Забегая наперёд, хочется отметить основную идею моделирования aBPM:

Модель aBPM состоит из двух подтипов процессов:

— предметные бизнес-процессы
— технические бизнес-процессы

Предметные бизнес-процессы собираются из технических БП, из которых в свою очередь строится модель бизнес логики данного БП. В предметных БП разрешено только частичное использование элементов стандарта BPMN 2.0.

Технические бизнес-процессы вмещают полный функционал стандарта BPMN 2.0.

Спасибо за внимание, добавляйте в закладки и до следующей части статьи!

• BPMN 2.0
• bpm
• workflow
• ad hoc
• bpm instances migration
• dynamic changes
• adaptive BPM
• normative BPM
• Adaptive Case Management

• Программирование
• Анализ и проектирование систем

Источник: habr.com