Системы bpms – Naumen BPM — автоматизация и управление бизнес-процессами предприятий (Business Process Management, BPM)

Содержание

Краткое описание BPMN с примером / Trinion corporate blog / Habr

О том, что такое BPMN, написано очень много. Но проблема в том, что почти вся информация, которую можно найти в Интернет, ориентирована на людей, которые уже ранее сталкивались с BPMN или с другим стандартом моделирования бизнес-процессов. Я же предлагаю разобраться «с нуля» — что такое BPMN? В чем особенности и преимущества этой технологии и почему она появилась и оказалась столь востребованной, по крайней мере, за рубежом. Да и у нас в стране ей все больше и больше интересуются.

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

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

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

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

Лично я познакомился впервые с BPMN около восьми лет назад, когда начал изучать систему Bizagi Modeler. Заинтересовался я этой системой по причине того, что давно уже понимал всю важность моделирования. До этого я лично пользовался IDEF0 и IDEF3, но там я сталкивался с определенными ограничениями. Дело в том, что IDEF0 несколько ограничен по числу возможностей. А IDEF3 мне лично показался излишне строгим и «сухим», в нем было сложно моделировать многие виды бизнес-процессов с участием программных продуктов.

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

В поисках оптимального решения для себя я изучал ARIS, инструменты 1С для бизнес-моделирования, различные системы моделирования бизнес-процессов, которые были придуманы различными бизнес-консультантами, как российскими, так и зарубежными. И, конечно же, познакомился с нотацией BPMN.

При первом знакомстве BPMN мне во многом понравился, идея была очень хорошей, а вот исполнение на тот момент с моей точки зрения еще было «сырым». И полноценно пользоваться BPMN я начал около 3 лет назад, после того, как задачи, которые я стал решать, усложнились настолько, что IDEF0 применять полноценно никак не получалось. И оказалось, что нотация развивалась, и теперь я активно пользуюсь BPMN в своей работе.

BPM: ОСНОВНЫЕ ПОНЯТИЯ


Для того чтобы разобраться, что такое BPMN, нужно понимать, что часть этой аббревиатуры «BPM» имеет две расшифровки — Business Process Modeling и Business Process Management. В первом случае – это непосредственно моделирование бизнес процесса, а во втором – управление бизнес-процессами, т.е. общая система, частью которой и является Business Process Modeling.

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

Есть и еще одно понятие, о котором стоит сразу упомянуть – это «BPMS», т.е. Business Process Modeling System. Этот термин описывает те самые системы управления, в которых производится моделирование, а также исполнение бизнес-процессов.

Можно сказать, что BPMN является частью двух важнейших составляющих:

  • BPM (Business Process Modeling) – это та среда, где вы занимаетесь непосредственно моделированием. Самостоятельно или в команде.
  • BPMS (Business Process Modeling System) – это инструменты для исполнения созданных вами моделей. Это может быть Bizagi, Comundo,ELMA и пр.
  • Итак, основные понятия у нас есть. Подробнее о BPM я планирую поговорить в следующих статьях.

ЯЗЫК ОПИСАНИЯ БИЗНЕС-ПРОЦЕССОВ


Когда впервые сталкиваешься с моделированием бизнес-процессов, очень тяжело понять, с чего же тут начать, где искать основу для понимания того, как строятся бизнес-модели. И я также с этим в свое время столкнулся.

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

Кроме того, в силу ограниченности задач, которые стоят перед этим языком, он гораздо более определен в терминологии. Но все же и здесь имеется очень много нюансов, каких-то сочетаний «слов», которые несут собственную смысловую нагрузку. И очень важно строго следовать правилам сочетания разных элементов языка и знать ограничения (что с чем сочетать недопустимо, как начинать описание, чем заканчивать и пр.).

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

Например, для моделирования бизнес-процессов вам понадобится знание таких понятий, как «условия», «цикл», «декомпозиция» и т.д.

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

НЕМНОГО ИСТОРИИ BPMN


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

Первая версия BPMN 1.0 была выпущена в мае 2004 года компанией Business Process Management Initiative. Эта версия обладала ограниченными возможностями и была, так сказать, «пробным вариантом», который нуждался в многочисленных доработках.

Следующая версия BPMN 1.1 выходит в январе 2008, и здесь разработкой и поддержкой занималась уже Object Management Group, организация, появившаяся в результате слияния BPMI с другой компанией-разработчиком программного обеспечения.

Еще один релиз появляется всего через год, версия BPMN 1.2 выходит в свет в январе 2009. Разработчик OMG остается прежним. Команда, которая занимается продуктом, после слияния практически не меняется.

В январе 2011 года компания OMG выпускает версию BPMN 2.0, а в декабре 2013 выходит последний на данный момент релиз – BPMN 2.0.2. Именно эта версия предлагается всем пользователям и сегодня, так как система получилась стабильной, возможности моделирования в ней очень широкие, а язык моделирования (набор обозначений) по большей части понятен всем бизнес-пользователям – как бизнесменам, бизнес-консультантам, так и техническим специалистам.

Из истории можно сделать вывод что период изменений в этом языке миновал, и можно спокойно изучать и использовать его на практике.

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

Я особенно хочу подчеркнуть этот момент, так как и сам столкнулся поначалу с непониманием, зачем те или иные вещи усложнять? Ведь для описания бизнес-процессов, например, при GAP-анализе (анализ разрывов) или для представления заказчику бизнес-модели в какой-то упрощенной форме, всего многообразия элементов BPMN вам не нужно. Но когда начинается автоматизация, когда бизнес-модель становится не просто удобной схемой, а может экспортироваться в другие программные продукты в качестве исполняемых данных, все становится на свои места. Последняя версия BPMN действительно стабильна и все требования к языку обоснованы.

ИЗ ЧЕГО СОСТОИТ НОТАЦИЯ BPMN?


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

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

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

Язык описания бизнес-процессов опирается на следующие базовые объекты:

  • Event – Событие;
  • Activity – Действия;
  • Gateway – Шлюзы или Развилки;
  • Flow – Поток.
  • Date – Данные;
  • Artefact – Артефакты;
  • Swimline – «плавательные дорожки»;
  • Pool (Пул) — набор.

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

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

EVENT (СОБЫТИЕ)


Event – это то событие, которое произошло в описании процесса или хореографии (о ней я расскажу отдельно). Эти события могут быть начальными, конечными или промежуточными.

Например, опишем процесс получения заказа от клиента по телефону:

  • Событие Старт – это входящий звонок от клиента.
  • Событие Финиш – это отправка готового расходного документа на печать.

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

ACTIVITY (ДЕЙСТВИЯ)


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

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

Обычно действия делят следующим образом:

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

GATEWAY (ШЛЮЗ, РАЗВИЛКА)


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

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

FLOW (ПОТОК) И MESSAGE FLOWS (ПОТОК СООБЩЕНИЙ)


Поток Flow – это последовательность действий, обозначается как стрелка, и показывает, какое действие после какого необходимо совершить.

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

Message Flows Association – еще один вид линий, в отличие от сообщений, которые являются пунктирными линиями, этот вариант отображается в виде последовательности не отрезков, а точек. Необходима для того, чтобы показывать артефакты (о них – ниже).

POOL (ПУЛ)


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

Пул может также содержать, так называемые, «дорожки». Они нужны для того, чтобы указать участников процессов, которые скрыты в пуле. Например, в процессе работы с клиентами участвует менеджер по продажам, руководитель отдела продаж, возможно, бухгалтер или кассир.

DATE OBJECT (ДАННЫЕ, ОБЪЕКТЫ ДАННЫХ)


Объекты данных – это элемент, который показывает, какие данные и документы нужны для того, чтобы какое-то действие запустилось, либо которые являются результатом выполненного действия. Объектом данных может быть сформированный заказ. Для менеджера это будет результат действий, а для склада, который получает заказ – началом действия (сбор товаров и отгрузка).

MESSAGE (СООБЩЕНИЕ)


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

ARTEFACT (АРТЕФАКТЫ)


Под артефактами в BPMN понимают объекты, не являющиеся действиями и не связанные с действиями напрямую. Это могут быть любые документы, данные, информация, которая не влияет напрямую на исполнение процесса.

Выделяют два вида артефактов:

  • Object Group (Группа объектов)
  • Text Annotation (Текстовая аннотация)

Object Group (Группа объектов) – это еще одна возможность объединить под общим символом несколько элементов, чтобы сэкономить место на диаграмме и повысить простоту ее восприятия. Здесь собираются различные активности под одним общим названием. Группу объектов также всегда можно рассмотреть детально. Группа выглядит как прямоугольник с закругленными углами, выполненный штриховой линией с точками.

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

ИСПОЛНЯЕМЫЕ И НЕИСПОЛНЯЕМЫЕ БИЗНЕС-ПРОЦЕССЫ


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

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

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

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

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

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

ПОДХОДИТ ЛИ BPMN ДЛЯ МАЛОГО И СРЕДНЕГО БИЗНЕСА?


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

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

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

МИНУСЫ И ВАЖНЫЕ ОСОБЕННОСТИ BPMN


О том, насколько удобна BPMN, я сказал уже много. Но для выбора любого инструмента важно также понимать и возможные минусы. О них я сейчас и расскажу:
  • Система имеет значительное количество понятий и терминов, их нужно знать и применять грамотно.
  • Высокий уровень вхождения. Как и любой инструмент с широкими возможностями требует большего времени на изучение, по сравнению с другими нотациями (IDEF0, IDEF3).
  • Необходимо знание бизнес-анализа. В BPMN модели — это не просто картинки или схемы, которые вы можете нарисовать в любом графическом редакторе. Здесь очень важна грамотная структура и четкая последовательность.

ПРИМЕР ПРАКТИЧЕСКОГО ПРИМЕНЕНИЯ BPMN


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

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

Данный бизнес-процесс выполняется следующим образом:

  1. Менеджер по продажам получает информацию о потребностях клиента (заказ).
  2. В системе CRM создается документ Заказ покупателя.
  3. Если нужные товары есть в наличие, то менеджер создает расходный документ в программе учета. Если товара нет в наличии, менеджер делает запрос в отдел закупки.
  4. Отдел закупки оформляет запрос поставщикам на получение товара.

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

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

Точкой входа служит получение заказа от покупателя. Точкой выхода – «резервирование товара».

Обратите внимание, что после получения заказа стрелка ведет к этапу-ромбу, т.е. условию:

  • Если весь товар имеется в наличие, то менеджер выполняет подпроцесс «резервирование товаров». Я специально оформил эти действия именно подпроцессом, чтобы иметь возможность при необходимости детализировать действия менеджера. А потом – к точке выхода «Резервирование товаров проведено».
  • Если товаров в наличие нет, то менеджер выполняет запрос в отдел закупки. Информация о заказе переходит в отдел закупки к другому исполнителю – менеджеру по закупкам, что наглядно видно на схеме, и уже этот исполнитель создает заказ поставщику. На схеме также видно, что заказ поставщику создан на основе запроса на поставку и заказа поставщикам.

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

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

КАК РАЗРАБАТЫВАТЬ ДИАГРАММЫ BPMN НА ПРАКТИКЕ?


Здесь я хочу поделиться некоторыми советами о том, с чего начать и как производить разработку моделей бизнес-процессов. Мои советы основаны на знаниях особенностей бизнес-моделирования и личном практическом опыте.
  1. Необходимо запланировать начало и конец процесса. С этого начинается моделирование любого процесса. Так мы обозначаем рамки, в которых будем работать.
  2. Для начала лучше всего описать линейную последовательность действий: шаг за шагом движение от начала к финальному результату. Далее при необходимости добавляются ветвления. В таком порядке работать намного проще, чем ставить две или более ветвей одновременно и путаться в стрелках, что откуда и куда идет.
  3. Пришло время определить ответственных лиц. До этого мы работали с событиями «в чистом виде». Теперь у них появились исполнители и ответственные.
  4. Добавляем данные, сноски, комментарии.

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

Что еще хотелось бы посоветовать:

  1. Создавайте диаграммы как можно менее разветвленные. Чем больше элементов окажется на вашей диаграмме, тем сложнее ее будет читать и вам, и вашим заказчикам.
  2. Используйте наиболее простую и понятную терминологию. Очень важно, чтобы ваши заказчики, а также технические специалисты, которые будут работать с диаграммами, без лишних пояснений понимали все (или почти все) термины.
  3. Все названия процессов должны быть максимально информативны и понятны. Иначе читабельность диаграммы также будет крайне низкой. Для названий процессов лучше всего подойдут либо термины, принятые в конкретной организации для описания работы, либо – просто понятные интуитивно фразы.
  4. Зоны ответственности также важно называть понятно для сотрудников компании, бизнес-модель работы которой вы описываете. Самое простое решение – выбирать названия среди существующих подразделений. А если необходимой должности или отдела в компании пока еще не существует, не бойтесь придумывать его сами. Но постарайтесь, чтобы название также было «говорящим», понятным для широкого круга бизнес-аудитории.
  5. Подпроцессов должно быть столько, чтобы избежать ненужной детализации, но не более того. Помните о чувстве меры. Если подпроцессов будет слишком мало, то действия, которые стоило бы спрятать в них, будут находиться в общем процессе, создавая дополнительные объекты, стрелки, ветвления и, как следствие, путаницу. Если вы перестараетесь с желанием убрать все в подпроцессы, то диаграмма потеряет свою информативность, а какие-то изменения в подпроцессе начнут ненаглядно влиять на результаты всего процесса.
  6. Не бойтесь ошибаться! Если вы ошибетесь в исполняемой методологии, это очень быстро выяснится в процессе исполнения (отладки) процесса. Если вы создаете просто наглядную схему, то мелкие ошибки не столь важны, главное, чтобы эта схема помогла вам и людям, для которых вы ее делаете (заказчики, технические специалисты), понять все нюансы вашей идеи. И в любом случае, на ошибках учатся, а исправления внести в бизнес-модель можно быстро и просто.

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

Еще статьи по данной теме:

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

Cистема управления бизнес-процессами | BPMS

Внедрение BPM-системы

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

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

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

Независимо от выбранного подхода к внедрению, дальнейшая работа с системой управления бизнес-процессами на базе Comindware Business Application Platform основана на простой схеме действий:

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

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

Comindware Business Application Platform изначально создана как Low-code платформа для успешной и гибкой реализации процессного подхода к управлению компанией. Адаптивные BPM-системы на базе платформы от Comindware способны оперативно меняться вместе с эволюцией бизнес-процессов компании.

все о BPM, ACM, RPA и Digital


Оригинал: Getting Started With BPM: Introduction
Авторы: Sandy Kemsley, Steve Russel

Суть управления бизнес-процессами (BPM) – оптимизация производительности сквозных процессов. BPM включает методологию процессного усовершенствования и поддерживающие ее инструменты. К методологии относятся, например, способы сбора информации о процессов («выявление»  процессов) и методы процессной оптимизации, а инструменты включают в себя BPA (Business Process Analysis) для моделирования и анализа процессов и BPMS (Business Process Management Suite) для их автоматизации.

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

В настоящей статье мы рассмотрим спектр вопросов от бизнеса и методологии до технологий:

  1. Правильный выбор первого процесса
  2. Вовлечение бизнеса
  3. Востребованность со стороны пользователей
  4. Структурированная и неструктурированная работа
  5. Оценка успеха
  6. Широкое внедрение в организации

ЧИТАТЬ ДАЛЕЕ



Оригинал: Intelligent Automation: A Buyer’s Guide
Автор: Нил Вард-Даттон (Neil Ward-Dutton)

Вероятно, вы уже наслышаны о технологии роботизации процессов (RPA, Robotic Process Automation) и изучаете возможные выгоды от ее внедрения. Но если вы всерьез задумываетесь о широком применении автоматизации для вашего бизнеса, вам стоит взглянуть на этот вопрос несколько шире, не останавливаясь только на RPA и искусственном интеллекте (ИИ). Вам стоит обратить внимание на другие технологии, чтобы получить максимум выгоды от инвестиций в RPA и расширить охват автоматизации в вашей компании. В этом отчете объясняется, в чем преимущества «интеллектуальной автоматизации», как комплексного подхода, и что конкретно вам нужно делать.

Сегодняшние требования автоматизации

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

ЧИТАТЬ ДАЛЕЕ



Оригинал: Architect Your Automation Strike Teams
Автор: Крэйг Ле Клер (Craig Le Clair), вице-президент, главный аналитик

Такие новые технологии,  как роботизация процессов (RPA), виртуальные агенты и машинное обучение — и есть те невидимые роботы, о которых говорится в недавно опубликованной Forrester книге «Невидимые роботы в ночной тиши: как искусственный интеллект и автоматизация реструктурируют рабочую силу». Невидимые роботы стремительно выдвинули автоматизацию на первое место среди корпоративных инициатив, но компании затягивают решение организационных и управленческих вопросов.

Как ответ на эти вызовы, стали появляться “ударные команды” автоматизации. Что они собой представляют? Ударные команды приходят на смену концепции Центра автоматизации или Центра передового опыта.

ЧИТАТЬ ДАЛЕЕ



Оригинал: Digital Transformation Should Start With Customers
Авторы: Томас Дэвенпорт (Thomas H. Davenport) и Эндрю Спаньи (Andrew Spanyi)

Очевидно, что для многих компаний цифровая трансформация в масштабах предприятия является серьезным вызовом. Статистика говорит о большой доле неудач в проектах цифровой трансформации — сравнимой со статистикой неудач крупномасштабных преобразований в целом. Слишком много устаревших систем, слишком много технического долга и слишком много накопленных данных в изолированных хранилищах функциональных и бизнес-подразделений, с которыми приходится разбираться.

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

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

Так с чего же начать?

ЧИТАТЬ ДАЛЕЕ



Оригинал: Lessons From The Failed Chatbot Revolution — And 5 Industries Where The Tech Is Making A Comeback
Сокращенный перевод: FutureBanking.ru

Хайп чатботов пришелся на 2016 год, когда они были буквально везде, но с тех пор стало понятно, что многие ожидания от них не оправдались, считают аналитики CB Insights. Однако они выделяют пять отраслей, в которых чатботы оказались действительно полезны, и финтех – первая из них. (Четыре остальных — здравоохранение, продажи и CRM, розница, юриспруденция — BPMS.ru.)

ЧИТАТЬ ДАЛЕЕ



Оригинал: Manufacturers’ digital transformation initiatives lag behind other industries

Согласно отчету Levadata, значительное число производственных компаний полагается на устаревшие аналоговые процессы и отстают в цифровизации от других отраслей. Так, в учете складских запасов около 50% компаний до сих пор полагаются на Excel, возможности аналитики которого ограничены.

Levadata недавно опросил свыше 200 руководителей, отвечающих за закупки и цепочки поставок, и большинство опрошенных (58%) сообщили, что управление поставками по-прежнему осуществляется через выделенных менеджеров, а не через централизованную систему хранения и анализа данных.

Несмотря на идущие разговоры о том, что к 2024 году обрабатывающие отрасли будут покрыты цифровыми технологиями, только у половины респондентов в каком-то виде имеется централизованная система анализа поставщиков и затрат на закупки, а 44% при разработке новых продуктов не используют инструменты управления затратами. Основная причина отставания — стоимость: экономию респонденты предпочитают инновациям.

ЧИТАТЬ ДАЛЕЕ



Оригинал статьи на finexpert.ru
Автор: Владимир Репин — к.т.н., доцент, консультант по управлению, генеральный директор ООО «Владимир Репин Менеджмент», советник зам. председателя правления АО «СО-ЕЭС»

Какие нотации используют компании для описания процессов сегодня?

Многие успешные компании, внедряющие технологии автоматизации бизнес-процессов, используют нотацию BPMN. Многие, но не все… Более того, в РФ существует огромное количество средних и крупных предприятий, на которых вообще отсутствует принятый корпоративный стандарт проектирования бизнес-процессов. Какими средствами они «рисуют» процессы? Чаще всего в MS Visio используют набор объектов для «Простой блок-схемы». Бывают ситуации хуже, когда в компании одновременно применяют 3-4 разных подхода к описанию процессов, причем все они нестандартные и реализованы в различных «нотациях» и программных продуктах, включая MS Excel и Power Point. Интересно, почему, когда речь заходит о необходимости описать процессы, все (кроме узкого круга профи) хватаются за эту «Простую блок-схему» с ромбиками?

ЧИТАТЬ ДАЛЕЕ



Оригинал: Just 8 reasons to use RPA
Автор: Скотт Фрэнсис (Scott Francis)

Во-первых, позвольте заметить, что вместо «RPA» мы чаще употребляем термины «роботизация» или «автоматизация». RPA – это особый тип автоматизации, заключающийся в воспроизведении действий пользователя.

Нас постоянно спрашивают: в каких случаях надо использовать RPA? Разумеется, есть множество ответов на этот вопрос, но лучше приведем несколько удачных примеров:

ЧИТАТЬ ДАЛЕЕ



Оригинал: Giants Will Fall
Автор: Джим Сайнур (Jim Sinur)

Есть устойчивое мнение, что пропасть между крупными и малыми компаниями растет, и маленькие компании обречены всегда быть отстающими. Цифры и история на стороне гигантов. Они большие и финансово устойчивые, поэтому они могут тратить больше денег на исследования и разработку (R&D). Но в реальности они этого не делают, потому что слишком заняты повышением курса акций и набиванием карманов топов. Даже если обязать их потратить значительную сумму на R&D, выберут ли они для инвестиций в правильное направление? Как библейский Давид, встретившийся с Голиафом, малый и средний бизнес может послать в гигантов пять гладких цифровых камней.

ЧИТАТЬ ДАЛЕЕ



Оригинал: IT-as-a-business is dead. Long live BusOps
Автор: Боб Льюис (Bob Lewis)

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

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

Отчасти это связано с ненормальной практикой «ИТ как бизнес», когда между ИТ и внутренними заказчиками устанавливаются соглашения об уровне сервиса (SLA).

ЧИТАТЬ ДАЛЕЕ



Оригинал: Large Enterprises Succeeding With Low-Code
Forrester Consulting по заказу Appian, май 2019 г.

Как выбрать платформу low-code, подходящую для ключевых бизнес-приложений

Резюме для руководителей

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

Эти проблемы особенно актуальны для крупных предприятий, предъявляющих наиболее строгие требования к масштабируемости, сложности, безопасности и целостности прикладных решений. Традиционно в разработке ключевых приложений такие компании полагались на профессиональных программистов. Однако в последние годы появилась более быстрая альтернатива кодированию в виде платформ разработки, требующих минимального кодирования — low-code. Но способны ли они удовлетворить корпоративным требованиям? Могут ли корпоративные заказчики воспользоваться преимуществами быстрой разработки, масштабно создавая и эксплуатируя приложения на платформе low-code?

ЧИТАТЬ ДАЛЕЕ



Оригинал: An Approach to Digital Transformation
Автор: Сэмир Парадкар (Sameer Paradkar)

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

ЧИТАТЬ ДАЛЕЕ



Оригинал: Get ready for robots

Софтверные роботы, или RPA (Robotic Process Automation), обещают радикально изменить представление о стоимости, эффективности и качестве выполнения многих процессов, которые до сих пор бизнес доверял людям, как в бэк-, так и во фронт-офисе.

Это была хорошая новость. Но внедрение RPA не обходится без сложностей. EY внедрял RPA в 20 странах, и часто к нам обращаются после того, как первая попытка провалилась. Потенциально RPA способен революционизировать экономику и качество сервиса текущих ручных операций, но при этом от 30 до 50% проектов RPA проваливается, по нашим наблюдениям. Это происходит не из-за технологии – есть много успешных внедрений. Но есть ряд типичных ошибок, не позволяющих организациям реализовать потенциал RPA.

В настоящей статье мы рассматриваем наиболее распространенные проблемы, с которыми сталкиваются клиенты по мере реализации проектов роботизации.

ЧИТАТЬ ДАЛЕЕ



Оригинал:  Practical Process: Measuring Business Process Performance
Автор: Роджер Тригер (Roger Tregear)

Меня недавно спросили: «Если задать KPI отдельно для каждого процесса в процессной архитектуре компании, то как узнать, что они соответствуют стратегическим целям организации?» Хороший вопрос!

ЧИТАТЬ ДАЛЕЕ



Оригинал: What Skills are Needed for BPM Success?

Авторы:

  • Грег Рок, Редактор и основатель, DBizInstitute.org, BPMInstitute.org & BAInstitute.org. С 25 годами опыта по созданию профессиональных сообществ, Грег Рок признан в качестве лидера в проведении профессиональных тренингов и обучения, жизненно необходимых для инициатив процессной трансформации бизнеса. Его работа была признана журналами Wall Street Journal, Fortune Magazine, Financial Times, CIO Magazin.
  • Андрей Спаний, Faculty Member, DBizInstitute.org and Managing Director, Spanyi International. Деятельность Андрея Спания в области управления бизнес-процессами и операционному лидерству признана на международном уровне. Он является автором трех книг, более 50 статей и признанным ведущим спикером. Он делал доклады и проводил сессии во многих странах по всему миру и опубликовал статьи более, чем в 10 журналах. Автор книги «BPM Is A Team Sport».

Один из наиболее часто задаваемых вопросов в области BPM — какие навыки нужны для успеха BPM-проекта? Всем понятно, что важно уметь моделировать, но помимо навыков и умений, требуется определенный образ мышления.

ЧИТАТЬ ДАЛЕЕ



Оригинал: Analysis of Process Automation Investments and Total Cost of Ownership (TCO) Appian, IBM, and Pega

Краткая характеристика методов исследования и анализа

В четвертом квартале 2018 года BPM.com провел маркетинговое исследование инвестиционных стратегий и опыта использования программного обеспечения BPM, предлагаемого Appian, IBM, Pegasystems и другими вендорами из отчета Gartner, посвященного Intelligent Business Process Management Suites (iBPMS). (Альтернативные названия — средства автоматизации рабочих процессов, средства интеллектуальной автоматизацией, платформы цифровой трансформации.)

ЧИТАТЬ ДАЛЕЕ



Лучший способ узнать в каком направлении движется отрасль BPM – посетить конференцию bpmNEXT (www.bpmnext.com). Не может себе позволить слетать в Санта-Барбару? Все выступления выложены на youtube. Нет времени, слабоват английский? Тогда здесь и сейчас – краткая выжимка из наиболее интересных докладов.

ЧИТАТЬ ДАЛЕЕ



Оригинал: Harmon on BPM: Keeping Track of New Developments
Автор: Пол Хармон (Paul Harmon)

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

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

ЧИТАТЬ ДАЛЕЕ



Оригинал: The Forrester Wave™: Robotic Process Automation, Q2 2018
Автор: Крейг Леклэ (Craig Le Clair)
Отчет публикуется в сокращенном переводе

Ключевые выводы

Во главе гонки — UiPath, Automation Anywhere и Blue Prism

Исследователи Форрестер выяснили, что лидерами рынка являются UiPath, Automation Anywhere и Blue Prism. WorkFusion, Pegasystems, NICE, Kryon, Kofax, EdgeVerve и Thoughtonomy — сильные игроки. Претенденты — Redwood Software, Contextor, Softomotive, AntWorks и Another Monday.

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

Возможности управления приложениями — это входной билет. Безопасность, аналитика, мультиарендность (multitenancy), легкость разработки и эффективность развертывания — вот что выделяет программные продукты из общего ряда.

ЧИТАТЬ ДАЛЕЕ



Оригинал статьи на сайте BPM in UA

Напомним, Customer Experience (CX) – это совокупность впечатлений клиента при взаимодействии с компанией, которая оказывает ему услугу или поставляет товар.

Недавнее исследование Gartner показало, что 81% лидеров в области СХ убеждены, что их компании полностью или в большей степени конкурируют на основе управления клиентским опытом. При этом только половина из них может обосновать влияние СХ на бизнес-результаты. 48% опрошенных говорят, что их усилия в CX превышают ожидания менеджмента, но только 22% компаний подтверждают, что их работа превосходит ожидания клиентов.

ЧИТАТЬ ДАЛЕЕ


Топ 10: BPM системы

1

ELMA BPM

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

2

Studio Creatio

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

3

ТЕЗИС

Система управления документами и задачами. Позволяет организовать работу с задачами (контроль исполнительской дисциплины), документами (оптимизация работы с документами) и канцелярией (автоматизация канцелярии). Включает в себя корпоративный портал. Есть мобильная версия.

4

Docsvision

Cистема управления документами, задачами и бизнес-процессами организации. Автоматизация делопроизводства. Управление бизнес-процессами и заданиями. Поиск и анализ информации. Информационная безопасность. Средства организации ЮЗЭДО. Средства настройки и разработки решений. Мобильная работа. Интеграция и масштабирование

5

Comindware Business Application Platform

Комплексная Low-code система управления бизнес-процессами включает полный комплект средств для моделирования бизнес-процессов в нотации BPMN 2.0, автоматизации бизнес-процессов, а также управления кейсами.

6

EOS for SharePoint

Полнофункциональная система для организации электронного документооборота и автоматизации бизнес-процессов на платформе Microsoft SharePoint.

7

Pyrus

Простой в использовании, но мощный по инструментарию веб-сервис для эффективного управления всей организацией, цифровизации и автоматизации бизнес-процессов. Позволяет быстро ставить задачи коллегам, вести мониторинг их выполнения, запускать проекты и электронный документооборот. Мобильные приложения (iOS, Android) с оффлайн-доступом. Синхронизация с 1С, G Suite, Active Directory, amoCRM, JIRA. Интеграция с любыми корпоративными системами.

Что такое BPMS | Бизнес-Консоль — управление бизнес-процессами (BPM)

Что такое BPMS | Бизнес-Консоль — управление бизнес-процессами (BPM)

+7 495 803 32 23

BPMS — Business Process Management Suite — это класс программного обеспечения, которое заточено на управление бизнес-процессами в условиях частых изменений. Основная идея BPMS: процесс моделируется в графической среде и представляет собой набор графических элементов в определенной нотации, задается набор атрибутов процесса, после чего процесс запускается на исполнение (пользователи начинают получать задания). Любое изменения процесса после этого изменяет его поведение в исполняемой среде. Такая работа обычно выполняется бизнес-технологами. Получается, что бизнес-пользователь действительно может создать приложение без участия ИТ-специалиста. Но так могут думать только те, кто совершенно не представляет себе из чего складывается информационное пространство современной организации, даже самой небольшой.

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

В чем преимущество использования BPMS:

  1. BPM не столько выдвигает новые идеи, сколько развивает и комбинирует уже известные. В науке достижения часто появляются на стыке дисциплин или направлений. В случае BPM таких направлений три: процессное управление и реинжиниринг бизнес-процессов, документооборот и управление потоками работ (Workflow), интеграция корпоративных приложений (EAI).
    Не конкретизируя как BPM развил эти направления (интересующихся адресуем к статье «Истоки BPMS» на сайте bpms.ru), отметим, что BPM удачно их комбинирует. Например, сочетание процессного управления и интеграции приложений дало интеграцию на основе бизнес-процессов, а сочетание технологий Workflow и методологии реинжиниринга дало полный цикл управления бизнес-процессом (моделирование-исполнение-анализ) на основе единой модели.
  2. BPMS — это класс системного программного обеспечения, появление которого следует той же логике, что и появление СУБД за двадцать лет до того. Вспомним: в свое время мысль о том, что данные целесообразно отделить от алгоритмов и использовать для управления ими специализированное системное программное обеспечение в виде СУБД, вовсе не была очевидной. Скептики говорили, что их программы и так справляются с хранением данных, и никакая СУБД не сможет делать это быстрее и лучше, и вообще СУБД — это лишняя трата денег.
    Сегодня то же самое происходит с процессами: появилось понимание того, что у этих информационных объектов есть специфика, отличающая их и от алгоритмов, и от данных. Как следствие, появилась идея специализированного системного программного обеспечения, которое (как и СУБД в случае данных) полностью возьмет на себя управление процессами: моделирование, хранение, исполнение, анализ и т.д. — т.е. BPMS.
  3. Системы BPMS органично сочетаются с уже сложившейся ИТ-инфраструктурой: для хранения данных о процессах используются распространенные реляционные СУБД, для исполнения процессов — сервера приложений на платформе JEE или .NET, для интеграции — существующие адаптеры (ODBC, JDBC, JCA) и веб-сервисы, для авторизации и аутентификации — службы каталогов (LDAP, Active Directory).
    BPM и SOA, в отличие от предыдущего поколения средств Workflow и EAI, следуют открытым стандартам в моделировании процессов (BPMN, BPEL, XPDL) и в интеграции с корпоративными приложениями (SOA и вебсервисы).
  4. BPM подразумевает непрерывное усовершенствование и короткий цикл разработки. Инструментарий BPMS позволяет визуальными средствами быстро разработать начальную схему бизнес-процесса и запустить ее в опытную эксплуатацию. В дальнейшем BPM (в сочетании с SOA) позволяет с минимальными затратами дорабатывать бизнес-процесс и увязывать его с разнородными корпоративными системами.
    Это полностью соответствует современным тенденциям в разработке информационных систем. Короткие циклы разработки предпочтительны перед традиционным длительным циклом. Успех сопутствует тем проектам, где пользователь максимально быстро получает первую версию программы и имеет возможность, с одной стороны, начинать извлекать из нее пользу (что способствует быстрому возврату инвестиций), а с другой — оперативно вносить корректировки в дальнейшую разработку, страхуя тем самым программистов от дорогостоящих ошибок. И именно по этой схеме реализуются проекты BPM.

Навигация по записям

24.12.2019

Офлайн-режим в мобильном клиенте Bizagi

Мобильный клиент Bizagi теперь поддерживает офлайновый режим работы. Даже если у вас отсутствует подключение к сети, вы можете:
  • выполнять назначенные вам задачи
  • запускать новые процессы

28.11.2019

Интеграция в Bizagi Digital Platform — все возможности

Один из стандартных вопросов, на которые нам приходится отвечать в ходе презентаций Bizagi — какими возможностями интеграции обладает данное ПО. Их много, мы насчитали аж 14:

16.02.2019

Gartner отнес Bizagi к группе преследователей рейтинга iBPMS в третий раз подряд

В рейтинге систем iBPMS Gartner третий год подряд отнес Bizagi к категории Challengers, засвидетельствовав тем самым отличные эксплуатационные характеристики Bizagi Digital Platform и хорошую репутацию компании на рынке. Bizagi занял позицию непосредственно за тройкой лидеров Pegasoft, Appian, IBM, значительно превзойдя таких известных на российском рынке конкурентов, как K2, Red Hat, Aura Portal, Bonitasoft и bpm’online.

Наши партнёры

Компания «Бизнес-консоль» является авторизованным партнёром
ведущих мировых производителей программного обеспечения BPMS

Copyright © 2000 — 2016 ООО «Бизнес-консоль»

ТОП-4 возможности BPM-систем — обзорная статья про BPM.

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

Внедрение BPM-системы необходимо предприятию, если:

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

Популярные BPM-системы

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

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

    Интерфейс BPM-системы bpmИнтерфейс BPM-системы bpm’online

  2. Bizagi BPM Suite – это система, направленная на моделирование, выполнение, автоматизацию и анализ бизнес-процессов предприятия. Для оптимальной настройки системы нужно использовать три разных блока для моделирования, разработки и исполнения процессов.

    Интерфейс BPM-системы bpmИнтерфейс BPM-системы Bizagi

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

Возможности BPM-систем ElmaИнтерфейс BPM-системы Elma

Возможности BPM-систем

Автоматизация бизнес-процессов

Автоматизация Б-П позволяет частично или полностью перевести стереотипные операции и бизнес-задачи под контроль BPM-системы. Результатом использования которой будет высвобождение человеческих и денежных ресурсов для увеличения производительности труда и результативности стратегического управления.

Ускорение рутинных задач

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

Ускорение выполнения задач

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

Единая платформа управления бизнесом

Современная система BPM — это готовое решение для управления продажами, маркетингом и сервисом. Благодаря чему возможно в едином интерфейсе управлять переходом клиента от этапа знакомства с компанией до момента завершения сделки.

Похожие статьи

Зачет по BPM | Открытые системы. СУБД

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

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

Свою лепту в сумятицу, связанную с BPM, вносят маркетинговые приемы производителей, расширительно толкующих используемые ими термины. Можно вспомнить, как в свое время все СУБД в одночасье стали «реляционными». Нечто похожее наблюдается и сейчас: о наличии систем категории BPM в их продуктовых линейках заявляют многие поставщики, хотя это не всегда обоснованно. К примеру, в качестве BPM позиционируются столь разные программные продукты, как дизайнер бизнес-процессов (IDS Scheer ARIS), программное обеспечение промежуточного слоя для координации Web-сервисов (Oracle BPEL) и ориентированное на работу с персоналом BPM-приложение (Fujitsu Interstage).

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

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

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

Попытаемся сформулировать ключевые тезисы, позволяющие сориентироваться в тематике BPM.

BPM — это не программа

Как следует из определения, которое дает Wikipedia, BPM — это управленческая методология. Следует различать BPM как методологию реорганизации и оптимизации бизнес-процессов и как программный инструментарий, часто используемый с этой целью. Подобное программное обеспечение вообще-то следует называть Business Process Management System (BPMS) или BPM-системой, однако зачастую его именуют просто BPM.

Разница тут примерно такая же, как между бухгалтерским учетом, воспринимаемым в качестве управленческой методологии, и бухгалтерской программой. В быту то и другое можно называть просто «бухгалтерией», но контекст всегда позволяет понять, о чем идет речь. Продолжим аналогию. Теоретически можно вести бухгалтерский учет и без компьютера, но на практике вряд ли кто-то будет так поступать. Шансов встретить BPM без BPMS больше, но в перспективе — при наличии доступного специализированного программного обеспечения — подобное окажется столь же нецелесообразным. И еще. Сегодня есть специалисты по бухгалтерскому учету и специалисты по бухгалтерским программам, но точно так же могут существовать специалисты как по управленческим, так и по программным аспектам BPM. Естественно, для успешной реализации BPM-проекта нужны и те, и другие.

Новизна BPM

Иногда можно услышать, что BPM существовал всегда. Подобные утверждения исходят из чересчур расширительной трактовки термина, которая мешает уловить суть того, что возникло в управлении бизнес-процессами относительно недавно и сейчас обозначается этой аббревиатурой. Новый подход начал развиваться приблизительно с 2000 года, а всплеск числа публикаций о BPM пришелся на 2003 год. BPM сменил популярный в 90-е годы реинжиниринг бизнес-процессов [1], однако нужно учесть следующее:

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

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

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

BPM и workflow

С употреблением этих терминов возникла немалая путаница [2]. Сам по себе термин workflow означает «последовательность работ, составляющих процесс», но его принято использовать и для обозначения функции управления потоком работ в традиционных системах документооборота. А Business Process Management есть расширение workflow, но в BPM больше внимания уделяется автоматически выполняемым шагам бизнес-процесса (т.е. межсистемному взаимодействию) и мониторингу бизнес-процессов (т.е. сбору статистики выполнения бизнес-процессов).

Теоретически, BPM-системы должны равно хорошо координировать задачи, выполняемые как людьми (human-to-human flow), так и автоматизированными системами (system-to-system flow). Однако на практике сегодняшние BPM-системы лучше справляются либо с тем, либо с другим [3]. В частности, стандарт BPEL в своем нынешнем виде описывает координацию вызовов Web-сервисов и не рассматривает взаимодействие с людьми [4].

Системы, ориентированные на координацию выполняемых людьми работ, иногда называют workflow-системами (еще одно значение этого термина), а аналитики Gartner обозначают их термином Pure-Play BPM. Термин «BPM-система» иногда используется в узком смысле — «система, ориентированная на интеграцию»; в Gartner такую систему называют Integration BPM. Встречается также собирательный термин «системы BPM и workflow».

Компоненты BPM

Распространенная ошибка — воспринимать BPM-систему как еще одну «рисовалку бизнес-процессов». Действительно, визуальный редактор (или дизайнер) бизнес-процессов, являющийся компонентом BPM-системы, мало чем отличается от традиционного инструментария реинжиниринга бизнес-процессов (средств рисования IDEF- или DFD-диаграмм). Но в BPM-системе рисование схемы бизнес-процесса является не завершающим этапом работы, а ее началом.

Готовая схема бизнес-процесса в виде XML-файла загружается в «движок» (BPM engine), а затем начинают стартовать экземпляры бизнес-процесса. Скажем, в бизнес-процессе сервисного обслуживания автомобиля экземпляр бизнес-процесса — это клиентский заказ. Каждый заказ проходит через последовательность шагов: менеджер оговаривает с клиентом объем работы, проводит первичный осмотр автомобиля, потом автомобиль отправляется мастеру в цех, тот выполняет свою задачу, наконец, клиент расплачивается и забирает автомобиль. Кроме того, в ходе реализации заказа возможны дополнительные согласования с клиентом.

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

У экземпляра бизнес-процесса есть контекст — набор реквизитов, определенных в схеме бизнес-процесса. В нашем примере это марка и номер автомобиля, фамилия и телефон клиента, наименования необходимых для ремонта запчастей и т.п. Такие данные могут храниться либо непосредственно во внутренней базе данных «движка» BPM, либо в специализированной внешней системе или базе данных (тогда пишется программа, связывающая «движок» с этой системой). Часть шагов бизнес-процесса (например, выписка счета) допустимо выполнять автоматически. Можно предусмотреть и дополнительные средства контроля. Скажем, если процесс задержался на каком-то шаге дольше, чем того требует регламент, по SMS автоматически отправляется уведомление менеджеру.

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

Дизайнер, «движок» и монитор являются стандартными компонентами BPM и соответствуют управленческой практике: разработка схемы бизнес-процесса, исполнение и анализ. Развитые BPM-системы помимо этих компонентов могут включать в себя модули Business Rule Engine (BRE), Business Activity Monitoring (BAM) и др. [5]. Существуют и программные продукты, реализующие отдельные компоненты BPM, — скажем, только проектирование бизнес-процессов.

BPM и корпоративные приложения

Как и в СУБД, где сначала определяется схема данных, а затем в нее заносятся сами данные, в BPMS сначала определяется схема, а уж потом в соответствии с нею создаются экземпляры бизнес-процессов. Схема данных в первом случае и схема бизнес-процесса во втором могут быть произвольными — в зависимости от предметной области.

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

Достоинства BPM раскрываются в полной мере, когда на предприятии используется не одно, а несколько корпоративных приложений. С такой ситуацией сталкиваются и корпорации, приобретающие компании с уже сложившейся информационной инфраструктурой, и предприятия, растущие потребности которых не может удовлетворить единственная ERP-система, — необходимы системы управления отношениями с клиентами, системы бюджетирования и оперативного управления производством. Даже если предприятие обходится без них, сделав ставку на ERP-систему одного поставщика, то есть еще «клиент-банк», САПР и АСУТП и другие программные системы, которые не входят в состав ERP. Плюс к тому у большинства организаций имеются приложения собственной разработки, автоматизирующие некие специфические функции.

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

В области интеграции технология BPM пересекается с SOA (service-oriented architecture — «сервис-ориентированная архитектура»). Отсутствие стандарта на взаимодействие систем разных производителей до сих пор делало интеграцию занятием, перспективным преимущественно для самих интеграторов и пугавшим заказчиков неприемлемо высокими расходами и рисками. Как известно, неудовлетворенный заказчик с легкостью делает неудовлетворенным разработчика. В результате отрасль пришла к пониманию необходимости решения этой проблемы. SOA обеспечивает стандарт на интерфейсы и среду, в которой такие интерфейсы могут публиковаться и вызываться, а BPM — смысловую нагрузку и правила, согласно которым системы должны передавать друг другу информацию и управление.

Речь, конечно, не идет о возврате к «лоскутной» автоматизации — набору слабосвязанных программ и дублирующих друг друга баз данных. Но понятно, что путь создания единой всеохватывающей системы является тупиковым, приводит к появлению неповоротливых нежизнеспособных монстров. Современная архитектура — двухуровневая. Внизу находятся тесно интегрированные системы, внутри которых располагается единая база данных с присущими ей классическими «короткими» транзакциями. На верхнем уровне системы связываются друг с другом при помощи BPMS в рамках «длинных» транзакций.

Преимущества такой архитектуры становятся очевидными при рассмотрении задачи, состоящей в интеграции цепочки «поставщики — клиенты» и создании «виртуальной корпорации». Рамки бизнес-процесса раздвигаются, и вслед за границами функциональных подразделений рушатся границы предприятий. Считается, что на Западе предприятия уже научились отстраивать бизнес-процессы, и сегодня актуальной для бизнеса стала интеграция между компаниями [6]. С технической точки зрения интеграция гетерогенных корпоративных приложений на основе бизнес-процессов выполняется с помощью так называемых «композитных» (composite) приложений [7], которые представляют собой пользовательские интерфейсы одновременно к бизнес-функциям корпоративных приложений и к «движкам» BPM.

Литература

  1. Howard Smith, Peter Fingar, Business Process Management: The Third Wave. Meghan-Kiffer Press, 2002.
  2. Jim Sinur, Toby Bell, A BPM Taxonomy: Creating Clarity in a Confusing Market. Gartner Research, 2003.
  3. Jim Sinur, The Gap Between IBSs and Pure-Play BPM Is Narrowing. Gartner Research, 2003.
  4. WS-BPEL Extension for People — BPEL4People. A Joint White Paper by IBM and SAP, 2005.
  5. Jim Sinur, David McCoy, Toby Bell, Creating a BPM and Workflow Automation Vendor Checklist. Gartner Research, 2003.
  6. Майкл Хаммер, Бизнес в ХХI веке: повестка дня. Что необходимо сделать каждой компании, чтобы стать лидером рынка в текущем десятилетии. М.: Добрая книга, 2005.
  7. Massimo Pezzini, Composite Applications Head Toward the Mainstream. Gartner Research, 2003.

Анатолий Белайчук ([email protected]) — технический директор компании «Бизнес-Консоль» (Москва).


Ресурсы по BPM

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

Проблематика BPM периодически обсуждается на форуме sql.ru.

Этого, конечно, слишком мало. К сожалению, у нас пока не сформировалось сообщество профессионалов в данной области, которому было бы чем заняться. Так, в свое время Workflow Management Coalition была организована на общественных началах (хотя и не без спонсорской помощи) с конкретной целью — выработать общепринятый глоссарий, и эта задача была решена. Затем, также в рамках WfMC, были разработаны референтная модель системы workflow и стандарт XPDL. (Кстати, первый вопрос к будущему BPM-сообществу: кто должен создавать русскоязычный глоссарий?)

Поделитесь материалом с коллегами и друзьями

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *