Подписаться
Рубрикатор
Полный список
Развитие организации
Управление процессами
Моделирование процессов
Регламентация процессов
Автоматизация процессов
Бережливое производство
Менеджмент качества
Управление проектами
Дайджесты по Business Studio

Облако терминов
12-процессная модель 4PL ACM Activity diagram AQPC ARIS ARIS 9 ARIS eEPC Balanced Scorecard Big Data & Analytic BMPN BPA BPEL BPM BPM accelerator BPM CBOK BPM-система BPM-системы BPMN BPMS BPR BPWin BS Portal BSC Business Intelligence Business Performance Management Business Performance Management (BPM) Business Process Management Business Process Management Systems Business Process Manager Business Rules Business Studio Business Studio 3.6 Business Studio 4 Business Studio 4.0 Business Studio Portal CA ERwin Data Modeler Case Management Casewise Casewise Corporate Modeler CFFC Corporate Modeler CPM CRM Decision Management DFD Directum ECM

Моделирование бизнес-процессов в нотации BPMN
Опрос

Вы используете

Библиотека

30.03.2013 19:37
  от автора
  Репин

Похоронит ли BPMN простую блок-схему?

Оценки за материал: 5.00 (4)

В последнее время публикуется множество материалов по применению нотации BPMN. Ее рассматривают как наиболее перспективную в области Business Process Management. Но так или это на самом деле? Заменит ли нотации BPMN простую, но удобную для решения ряда практических задач «Простую блок-схему в Visio»? Какими преимуществами обладает «Простая блок-схема?». Для чего и как ее можно использовать в компании? Ответы на эти вопросы приводятся в статье В.В. Репина.
Введение

В ряде статей можно найти сравнительный анализ различных нотаций: BPMN, ARIS eEPC и других. Их сравнивают по выразительной способности, наличию тех или иных элементов, возможности «корректного» отображения процессных паттернов и прочее. С моей точки зрения, сравнивать нотации между собой – неблагодарное занятие, и вот почему. В реальной ситуации, при внедрении в компании процессного подхода необходимо учитывать следующие аспекты:

1. возможности собственно нотации моделирования бизнес-процессов;
2. возможности инструментального средства моделирования, которое поддерживает (реализует внутри себе) данную нотацию;
3. методику использования нотации и инструмента моделирования в конкретном проекте (а он всегда имеет четкие цели и задачи) конкретной компании (а это значит, что нужно учитывать многие факторы: от бюджета до корпоративной культуры);
4. наличие компетентных специалистов, способных эффективно применять нотацию, создавая модели процессов в среде моделирования для решения конкретных задач по проекту (например, для регламентации деятельности).
5. наличие достаточно компетентных внутренних заказчиков, способных читать нотацию в регламентах бизнес-процессов компании (особенности корпоративной культуры и зрелости управленческих технологий).

С учетом этих аспектов и нужно сравнивать нотации и оценивать их практическую полезность и применимость.

Простая блок-схема

На рис. 1. представлен фрагмент схемы процесса, сформированной в весьма распространенной нотации под названием «Простая блок-схема». Чаще всего такие схемы рисуют, используя инструмент MS Visio.

С точки зрения классической нотации Work Flow (например, IDEF3), простая блок-схема содержит только один элемент маршрутизации (gateway/шлюз, оператор логики и т.п) - ромбик. Он годится на все случаи жизни. Очевидно, что большинство схем, которые делаются в компаниях в нотации «простая блок-схема», не выдерживают критики с теоретической точки зрения. Они «не исполнимы» с точки зрения автоматизации, содержат множество нарушений формальных требований и т.п.


Рис. 1. Фрагмент «простой блок-схемы».

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

1. Схемы процессов субъективны

Любая схема процесса в достаточной степени субъективна. Даже при использовании такой сложной нотации, как BPMN, у разных специалистов получаются схемы различного вида. Что уже говорить о более простой нотации. Но с практической точки зрения стремиться к «идеальности» схемы бессмысленно. Результат не окупит потраченные на его получение ресурсы. Важно, чтобы схема отображала процесс «как есть» с той степенью точности, которая позволяет принимать решения, приводящие к улучшению процесса.

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

2. Комплексное восприятие графических схем человеком

Реальный человек – не «токен» (в понимании стандарта BPMN 2.0). Он видит графическую схему процесса целиком, интегрально (если конечно она умещается на листе формата А4). Это означает, что некоторые нарушения строгой нотации моделирования с определенной (на мой взгляд, очень высокой) вероятностью не приведут к некорректной интерпретации схемы человеком. Другими словами, если мы разрабатываем графическую схему для человека, то можем использовать более простую нотацию, сознательно допуская нарушение некоторых «классических» требований подхода Work Flow.

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

Оборонное научное агентство DARPA готовит к запуску почти 4-летний проект по разработке искусственного интеллекта, который сможет самообучаться и совершенствовать себя.

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

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

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

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

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


3. Запас информационной прочности

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

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

4. Простота обучения

В реальных проектах важно быстро обучить сотрудников описывать процессы и воспринимать разрабатываемые схемы. Чрезмерно сложная нотация моделирования потребует намного больших затрат ресурсов для обучения всех сотрудников. Особенно это касается руководящего состава. Фактор обучения, легкости преодоления барьера освоения «процессного языка» может стать одним из критически важных и значимых для успеха проекта.

Использования особенностей инструмента для усиления возможностей «простой блок-схемы»

Очевидно, что музыкальное произведение подбирают под тот инструмент, который есть в наличии. Точно так же очевидно, что конкретная среда моделирования со своим функционалом дает дополнительные преимущества при использовании нотации. Даже MS Visio предлагает некоторые функциональные возможности, помогающие при практическом использовании «простой блок-схемы». Что уж говорить о более тяжелых, специализированных системах. Таких, например, как Business Studio.

В Business Studio простая блок-схема реализована в виде нотации «Процедура» (почему так назвали – это уже история разработчиков). Условные обозначения этой нотации представлены на рис. 2.


Рис.2 . Нотация «Процедура» Business Studio.

В нотации «Процедура» используются простые условные обозначения. Так для стрелки типа «связь предшествования» («Sequence Flow» в BPMN) используется стрелка с одним наконечником. Для связи типа «поток объектов» («Message Flow» в BPMN) – стрелки с двумя наконечниками. Начало и конец стрелки могут быть либо темными, либо светлыми, пустыми. Таким образом, можно показывать туннелирование стрелок, что практически удобно.

Но самое интересное, что к стрелкам в Business Studio можно привязывать объекты справочника «Объекты деятельности». А эти объекты используются для описания документов. К ним могут прикрепляться реальные файлы MS Word. Таким образом, стрелка – это не только объект на схеме, но и носитель информации о взаимодействии операций при выполнении процесса. Поскольку операции выполняют люди, то это означает, что мы можем получить описание взаимодействие сотрудников и т.п. Возможности «простой блок-схемы» существенно расширяются. Это особенно удобно при автоматическом формировании регламентирующих документов путем выгрузки информации из Business Studio на основе определенного шаблона.


Рис. 3. Пример прикрепления документов к стрелкам в Business Studio.

В качестве примера, на рис. 3. показано, как в Business Studio можно прикрепить документы к стрелке, связывающей операции процесса между собой. Если бы мы использовали ARIS eEPC, то нам пришлось бы рисовать столько стрелок, сколько движется документов. А это практически неудобно.

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

Пятнадцать лет назад некоторые специалисты предрекали смерть нотации IDEF0, но она жива, и продолжает активно применяться. Так что BPMN 2.0, равно как и S-BPM, вряд ли «похоронят» простую блок-схему.

В.В. Репин, к.т.н., Исполнительный директор и партнер ООО «BPM Консалтинг Групп», доцент кафедры Бизнес-информатики и систем управления производством МИСиС.

Март 2013 г.

Литература


1. Федоров И. «Сравнительный анализ нотаций моделирования бизнес-процессов», http://www.osp.ru/os/2011/08/13011140/, 2011 г.
2. Вил ванн дер Аалст. «Управление потоками работ. Модели, методы и системы». М.: «Физматлит», 2007 г.
3. В.В. Репин. «Бизнес-процессы. Моделирование, внедрение, управление». М.: «Манн, Иванов и Фербер», 2013 г.

Комментарии

Оценки: /
01.04.2013 14:17
  от автора
  Дмитрий Пинаев
А если применять только базовые элементы нотации BPMN, то диаграммы будут получаться вполне читаемыми. Поэтому, почему бы ее и не применять?

Частные комментарии:

1.>>Сложная нотация может увести нас от реального понимания проблем процесса к обсуждению более правильной формы представления нашего весьма субъективного представления о реальной деятельности.

Это вряд ли, т.к. вряд ли соберутся в компании столько экспертов, чтобы обсуждать правильную форму. А вот к затруднению понимания и к внесению в понимание субъективизма – приведет.

2.>>Возможно, нам нужны нотации, которые могут описывать процесс визуально именно с учетом вероятности исполнения отдельных операций (а не в жесткой машинной логике BPMN).
Честно говоря, не понял: откуда такой вывод?

3.>>В качестве примера, на рис. 3. показано, как в Business Studio можно прикрепить документы к стрелке, связывающей операции процесса между собой. Если бы мы использовали ARIS eEPC, то нам пришлось бы рисовать столько стрелок, сколько движется документов.

И не только стрелок, но и документов. Кстати не только в eEPC, но и в BPMN пришлось бы делать тоже самое.

4.>>Так что BPMN 2.0, равно как и S-BPM, вряд ли «похоронят» простую блок-схему.
Вопрос к автору:
Почему в качестве примеры приведена нотация(?) S-BPM?
Насколько правомерно считать эту нотацию нотацией моделирования БП, учитывая что в ней отсутствует представление цельного наглядного алгоритма выполнения процесса?
Оценки: /
01.04.2013 14:21
  от автора
  Репин
Привет, Дмитрий!

1. Согласен насчет количества экспертов в компании
2. Скорее, на основе интуиции, чем строгой логики.
3. Да, что в eEPС, что в BPMN нужно рисовать много стрелок и документов. Есть ощущение, что эти нотации (особенно BPMN) не были рассчитаны на то, что у кого-то в процессах на нижнем уровне будет много документов
4. Про S-BPM написал, поскольку ее позиционируют как "убийцу" eEPC...
Оценки: /
01.04.2013 14:35
  от автора
  Дмитрий Пинаев
2. Тогда нужны не вероятности, а критерии по которым искусственный интеллект будет понимать: приближает ли выполнение операции к цели процесса или нет
Оценки: /
01.04.2013 22:20
  от автора
  Klimchuk Aleksandr
Коллеги, добрый вечер

Спасибо Владимиру за (как всегда) системный и обстоятельный анализ вопроса.
Я и для себя я считаю наиболее удачной связкой IDEF0 + блок-схема с дорожками и отсечением по времени.
Однако в статье не прозвучало два главных аргумента в пользу BPMN: сводимось к блок-схеме при использовании наиболее простого набора символов и автоматическая транслируемость в средства автоматизации.
Эти два аргумента, на мой взгляд, весьма серьезно "бьют" простую блок-схему на комплексном проекте управления бизнес-процессами.
Оценки: /
02.04.2013 08:20
  от автора
  Репин
Привет, Александр!

Сводимость только внешняя. Об этом как раз в статье есть информация. Поясню мысль:
1. в BPMN стрелки, как правило, не имеют названий (за исключением ситуации с развилкой). Мы в "Процедуре" - именуем каждую стрелку контекстно;
2. в BPMN/EPC нужно показывать столько стрелок и значков, сколько движется документов.

Поэтому BPMN не сводим к простой блок-схеме в случае ее реализации в Business Studio.
Оценки: /
03.04.2013 09:38
  от автора
  Klimchuk Aleksandr
"2. в BPMN/EPC нужно показывать столько стрелок и значков, сколько движется документов." - не соглашусь.
Приведу пример из Бизаги, буквально вчера рисовал. Есть процедура согласования оплаты. Она основана на документе "Заявка на оплату", который сначала создается, потом согласовывается и исполняется. В диаграмме процесса BPMN я показываю действия "создать", "проверить" .... и просто их соединяю стрелками временной последовательности. Естественно, каждое действие меняет атрибуты документа. Но зачем сам документ показывать? Смысла в такой информации "0", лишь засоряем схему.
Вообще, вопрос наложения процессной схемы на документарную весьма неоднозначен, хоть диссертации пиши Гипотеза, что последовательность действий похожа и может свестись к траекториям документов не доказана.
Оценки: /
04.04.2013 18:53
  от автора
  Репин
"...Естественно, каждое действие меняет атрибуты документа..."
- если это настроено в информационной системе, так? Тогда, возможно, "да".

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

Кроме того, не надо путать схему потоков данных (DFD) и схему бизнес-процесса.

Например, в ARIS eEPC можно показывать движения документов (требуется много стрелок и объектов). Но есть отдельная нотация для описания потока данных...

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

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

Комментировать материалы могут только зарегистрированные пользователи. Вы можете зарегистрироваться здесь.
©  2010-2014 В.В. Репин. Сайт основан 3 февраля 2001 г.

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

Регистрация
О Портале
Правила
Контакты
Новости
Библиотека
Энциклопедия
Литература и сайты
Группы
Мои страницы
Тесты
Форум
Доска объявлений