BPMN vs IDEF3: 11:5 в пользу BPMN (пока что, по крайней мере)..
Я иногда просто поражаюсь творческой плодовитости Анатолия Левенчука, который за день успевает опубликовать по несколько постов, посвященных самым разным вопросам системной инженирии. И хотя по большей части материал идет мимо моего сознания (либо я не понимаю, о чем идет речь, либо не совсем интересно), однако в некоторых случаях я получаю от чтения определенную пользу. И уже одно это заставляет меня просматривать его записи каждый раз с любопытством...
Вот, например, буквально на днях он опубликовал статью под заголовком:
Что нужно для счастья: онтология, лексика, нотация
На первый вгляд, ничего такого особенного - статья себе как статья. Однако, прочитав ее - я задумался о том, что за той или иной нотацией (то есть стандартом описания) бизнес-процессов непременно стоит какая-то определенная философия (читай: онтология).
Вот, к примеру, нотации IDEF3 и BPMN! Скажем, в IDEF3 присутствуют следующие концепты (говоря словами Левенчука):
1. Работы (Acivities)
2. Связи (Links) и потоки объектов (Object Flows)
3. Перекрестки (Junctions)
Кроме того, существует еще один концепт, весьма примечательный:
4) объект ссылки (Referent), который "выражает некую идею, концепцию или данные, которые нельзя связать со стрелкой, перекрестком или работой" (источник цитаты здесь).
В другом месте читаю про Referent такие слова:
Последним отличием стандарта IDEF3 в отличие от классической методологии WFD является использование на схеме бизнес-процесса такого элемента как "объект ссылки", который связывается с работами и перекрестками. С помощью объектов ссылки показывается прочая важная информация, которую целесообразно зафиксировать при описании бизнес-процесса.
- Хм! - думаю я. - Очень таинственно... Что же это за прочая такая информация? И для чего она понадобилась-то вдруг? Ответ нахожу в следующей таблице, где описываются типы объектов ссылок:
Тип объекта ссылкиЦель описанияOBJECTОписывает участие важного объекта в работеGOTOИнструмент циклического перехода (в повторяющейся последовательности работ), возможно на текущей диаграмме, но не обязательно. Если все работы цикла присутствуют на текущей диаграмме, цикл может также изображаться стрелкой, возвращающейся на стартовую работу. GOTO может ссылаться на перекрестокUOB (Unit of behaviour)Применяется, когда необходимо подчеркнуть множественное использование какой-либо работы, но без цикла. Например, работа "Контроль качества" может быть использована в процессе "Изготовление изделия" несколько раз, после каждой единичной операции. Обычно этот тип ссылки не используется для моделирования автоматически запускающихся работNOTEИспользуется для документирования важной информации, относящейся к каким-либо графическим объектам на диаграмме. NOTE является альтернативой внесению текстового объекта в диаграммуELAB (Elaboration)Используется для усовершенствования графиков или их более детального описания. Обычно употребляется для детального описания разветвления и слияния стрелок на перекрестках
- Интересно, - продолжаю размышлять я. - Если разработчики стандарта IDEF3 начинают расширять его границы, значит к этому толкает их практика. Странно только, что в рамках одного и того же графического элемента объединены такие разные вещи, как объект (OBJECT), переход (GOTO) и текстовая аннотация (NOTE). Что-то здесь не так...
Для иллюстрации можно привести следующий пример с использованием объектов ссылок (мелковато, но что поделаешь):
Для полноты картины добавим еще кое-что. Как выясняется, в стандарте IDEF3 есть по меньшей мере две (!) разновидности диаграмм:
1) диаграмма Описания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD) - пример такой диаграммы представлен на рисунке (см. чуть выше) и
2) диаграмма Сети Трансформаций Состояния Объекта (Object State Transition Network, OSTN) - ее образец дан на следующем рисунке:
При построении PFDD применяется метод Process Flow Description (PFD), который описывает технологические процессы, с указанием того, что происходит на каждом этапе технологического процесса.
А при построении OSTN применяется метод Object State Transition Description (OSTD), который описывает переходы состояний (!) объектов, с указанием того, какие существуют промежуточные состояния у объектов в моделируемой системе.
Таким образом, появляется еще один концепт (на втором рисунке он изображен кружочком):
5) моменты перехода состояний системы.
Итак, всего пять концептов...
Теперь обратим внимание на BPMN. В статье из Википедии читаю следующее:
Моделирование в BPMN осуществляется посредством диаграмм с небольшим числом графических элементов. Это помогает пользователям быстро понимать логику процесса. Выделяют четыре основные категории элементов:
* Объекты потока управления: события, действия и логические операторы
* Соединяющие объекты: поток управления, поток сообщений и ассоциации
* Роли: пулы и дорожки
* Артефакты: данные, группы и текстовые аннотации.
Попробуем посчитать концепты: 1) событие (аналог концепта 5 из IDEF3), 2) действие (аналог концепта 1), 3) логический оператор (аналог концепта 3), 4) поток управления (аналог концепта 2), 5) поток сообщений, 6) ассоциация, 7) пулы, 8) дорожки, 9) данные, 10) группы, 11) текстовые аннотации
Получается 11:5 в пользу BPMN. То есть, говоря иными словами, в основе BPMN лежит более богатая онтология, которая открывает больше возможностей при описании бизнес-процессов, чем IDEF3. По крайней мере, такой первичный вывод напрашивается даже при поверхностном сравнении стандартов.
Вы можете в этом месте меня обоснованно спросить, и с чего это я вдруг так увлекся сравнительным анализом двух стандартов? Ответить просто: чисто из практических побуждений. В данный момент я всячески стараюсь применить стандарт IDEF к описанию процесса бюджетирования. И если на верхнем уровне описания с помощью IDEF0 все прошло хорошо, то на нижних этажах, где используется станарт IDEF3, возникли кое-какие сложности. И как-то... чисто интуитивно мне показалось, что IDEF3 несколько... скуповат что ли для выражения особенностей реальных бизнес-процессов... Вот и пытаюсь сравнить! Не исключено, что описав некоторые процессы на IDEF, попробую сделать их аналогичное описание на BPMN. Интересно, что у меня тогда получится :)
Вот, например, буквально на днях он опубликовал статью под заголовком:
Что нужно для счастья: онтология, лексика, нотация
На первый вгляд, ничего такого особенного - статья себе как статья. Однако, прочитав ее - я задумался о том, что за той или иной нотацией (то есть стандартом описания) бизнес-процессов непременно стоит какая-то определенная философия (читай: онтология).
Вот, к примеру, нотации IDEF3 и BPMN! Скажем, в IDEF3 присутствуют следующие концепты (говоря словами Левенчука):
1. Работы (Acivities)
2. Связи (Links) и потоки объектов (Object Flows)
3. Перекрестки (Junctions)
Кроме того, существует еще один концепт, весьма примечательный:
4) объект ссылки (Referent), который "выражает некую идею, концепцию или данные, которые нельзя связать со стрелкой, перекрестком или работой" (источник цитаты здесь).
В другом месте читаю про Referent такие слова:
Последним отличием стандарта IDEF3 в отличие от классической методологии WFD является использование на схеме бизнес-процесса такого элемента как "объект ссылки", который связывается с работами и перекрестками. С помощью объектов ссылки показывается прочая важная информация, которую целесообразно зафиксировать при описании бизнес-процесса.
- Хм! - думаю я. - Очень таинственно... Что же это за прочая такая информация? И для чего она понадобилась-то вдруг? Ответ нахожу в следующей таблице, где описываются типы объектов ссылок:
Тип объекта ссылкиЦель описанияOBJECTОписывает участие важного объекта в работеGOTOИнструмент циклического перехода (в повторяющейся последовательности работ), возможно на текущей диаграмме, но не обязательно. Если все работы цикла присутствуют на текущей диаграмме, цикл может также изображаться стрелкой, возвращающейся на стартовую работу. GOTO может ссылаться на перекрестокUOB (Unit of behaviour)Применяется, когда необходимо подчеркнуть множественное использование какой-либо работы, но без цикла. Например, работа "Контроль качества" может быть использована в процессе "Изготовление изделия" несколько раз, после каждой единичной операции. Обычно этот тип ссылки не используется для моделирования автоматически запускающихся работNOTEИспользуется для документирования важной информации, относящейся к каким-либо графическим объектам на диаграмме. NOTE является альтернативой внесению текстового объекта в диаграммуELAB (Elaboration)Используется для усовершенствования графиков или их более детального описания. Обычно употребляется для детального описания разветвления и слияния стрелок на перекрестках
- Интересно, - продолжаю размышлять я. - Если разработчики стандарта IDEF3 начинают расширять его границы, значит к этому толкает их практика. Странно только, что в рамках одного и того же графического элемента объединены такие разные вещи, как объект (OBJECT), переход (GOTO) и текстовая аннотация (NOTE). Что-то здесь не так...
Для иллюстрации можно привести следующий пример с использованием объектов ссылок (мелковато, но что поделаешь):
Для полноты картины добавим еще кое-что. Как выясняется, в стандарте IDEF3 есть по меньшей мере две (!) разновидности диаграмм:
1) диаграмма Описания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD) - пример такой диаграммы представлен на рисунке (см. чуть выше) и
2) диаграмма Сети Трансформаций Состояния Объекта (Object State Transition Network, OSTN) - ее образец дан на следующем рисунке:
При построении PFDD применяется метод Process Flow Description (PFD), который описывает технологические процессы, с указанием того, что происходит на каждом этапе технологического процесса.
А при построении OSTN применяется метод Object State Transition Description (OSTD), который описывает переходы состояний (!) объектов, с указанием того, какие существуют промежуточные состояния у объектов в моделируемой системе.
Таким образом, появляется еще один концепт (на втором рисунке он изображен кружочком):
5) моменты перехода состояний системы.
Итак, всего пять концептов...
Теперь обратим внимание на BPMN. В статье из Википедии читаю следующее:
Моделирование в BPMN осуществляется посредством диаграмм с небольшим числом графических элементов. Это помогает пользователям быстро понимать логику процесса. Выделяют четыре основные категории элементов:
* Объекты потока управления: события, действия и логические операторы
* Соединяющие объекты: поток управления, поток сообщений и ассоциации
* Роли: пулы и дорожки
* Артефакты: данные, группы и текстовые аннотации.
Попробуем посчитать концепты: 1) событие (аналог концепта 5 из IDEF3), 2) действие (аналог концепта 1), 3) логический оператор (аналог концепта 3), 4) поток управления (аналог концепта 2), 5) поток сообщений, 6) ассоциация, 7) пулы, 8) дорожки, 9) данные, 10) группы, 11) текстовые аннотации
Получается 11:5 в пользу BPMN. То есть, говоря иными словами, в основе BPMN лежит более богатая онтология, которая открывает больше возможностей при описании бизнес-процессов, чем IDEF3. По крайней мере, такой первичный вывод напрашивается даже при поверхностном сравнении стандартов.
Вы можете в этом месте меня обоснованно спросить, и с чего это я вдруг так увлекся сравнительным анализом двух стандартов? Ответить просто: чисто из практических побуждений. В данный момент я всячески стараюсь применить стандарт IDEF к описанию процесса бюджетирования. И если на верхнем уровне описания с помощью IDEF0 все прошло хорошо, то на нижних этажах, где используется станарт IDEF3, возникли кое-какие сложности. И как-то... чисто интуитивно мне показалось, что IDEF3 несколько... скуповат что ли для выражения особенностей реальных бизнес-процессов... Вот и пытаюсь сравнить! Не исключено, что описав некоторые процессы на IDEF, попробую сделать их аналогичное описание на BPMN. Интересно, что у меня тогда получится :)