Библиотека

Введение

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

Мы затронем только три аспекта моделирования: определение границ процессов, использование событий и привязка документов к стрелкам. Первые два аспекта важны независимо от применяемой системы моделирования. Третий обусловлен особенностями архитектуры именно Business Studio.

Границы процессов

На рис. 1 показано, что для определения границ любого процесса необходимо определить:
1. входы/выходы;
2. инициирующие и завершающие события.

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


Рис. 1. Определение границ процесса: входы/выходы и события.

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

Давайте попытаемся понять, что же такое «событие». В «Википедии» приводится следующее определение:

«Собы́тие — то, что имеет место, происходит, наступает в произвольной точке пространства-времени; значительное происшествие…»

Определение, конечно, не очень четкое. Оно скорее философское. Посмотрим, что говорят профессиональные стандарты.
В стандарте ISO 19510 «Information technology — Object Management Group Business Process Model and Notation» вразделе 8.4.5 Events приводится следующее определениесобытия:

«An Event is something that happens during the course of a Process (событие – эточто-то, чтослучаетсявовремявыполненияпроцесса)».

К сожалению, это тоже не самое понятное и четкое определение.

Обратимся к стандартам ARIS. Определение, приводимое в «Методах ARIS» сформулировано следующим образом:

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

События переключают функции и могут быть результатом выполнения функции. Упорядочивание комбинации событий и функций в последовательность позволяет
создать событийные диаграммы процессов EPC (Event - Driven Process Chain - цепочка процесса, управляемая событиями). С помощью этих диаграмм процедуры
бизнес-процесса представляются как логические последовательности событий».

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

Так же приведем определение события, сформулированное разработчиком среды моделирования Business Studio:

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

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

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

Подчеркнем, понятие «событие» используется во всех современных нотациях, используемых для моделирования бизнес-процессов на операционном уровне (WorkFlow): eEPC, BPMN 2.0, CFFC. Далее в статьях серии мы рассмотрим, каким образом применяются события, и определяются границы процессов в указанных нотациях.

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

Входы/выходы процесса

Посмотрим, каким образом визуально можно показать границы процесса в нотации «Процедура» (CFFC – Cross Functional Flow Chart)среды моделирования Business Studio.


Рис. 2А. Схема процесса в нотации «Процедура» (CFFC, простая блок-схема).

На рис. 2А показано событие «Поступил запрос от клиента». Оно является инициирующим для рассматриваемого процесса. Справа от операции процесса «Выполнить анализ запроса» показаны стрелки с двумя наконечниками – информационные входы. Заметим, что эти входы не «висят в воздухе». Один из них привязан к внешней ссылке «Клиент». Другой вход поступает из процесса «Управление ценообразованием». Так же «Счет на оплату товара» и «Информация об отказе» являются выходами процесса. Они поступают к клиенту. «Счет на оплату» поступает так же в процесс «Контроль оплаты счетов».

Обратим внимание читателя, что на схеме процесса использовано два типа стрелок:
• стрелки с одним наконечником имеют тип «Связь предшествования»;
• стрелки с двумя наконечниками имеют тип «Поток объектов».

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

Заметим, что стрелки типа «Связь предшествования» можно не именовать. Но автор статьи придерживается стиля, при котором такие стрелки именуются в терминах событий, например: «Запрос не соответствует номенклатуре», «Счет на оплату подготовлен». Это делается исключительно с целью повышения визуальной наглядности схемы для пользователей.

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

Отметим, что если бы стрелка «Счет на оплату товара» с двумя тёмными наконечниками не была присоединена к кружку «Контроль оплаты счетов» (это условное обозначение т.н. междиаграммной ссылки в Business Studio),то это означало бы ее миграцию на верхний уровень.

Наоборот, если наконечники стрелки светлые (см. на рис. 2А стрелку «Пример»), то в соответствии с принятыми в Business Studio условными обозначениями это означает, что стрелка туннельная, и не будет показана на диаграмме верхнего уровня.

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

Использование событий

На рис. 2А представлено два события:
• инициирующее событие – «Поступил запрос от клиента»;
• завершающее событие – «Обработка запроса клиента выполнена».

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

В нотации «Процедура» Business Studio можно восполнить недостаток, связанный с невозможностью использования промежуточных событий процесса, именуя стрелки типа «Связь предшествования» в терминах событий, как было сказано выше.

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


Рис. 2Б. Промежуточные события в нотации «Процедура» (CFFC, простая блок-схема).

Миграция и туннельные стрелки

Некоторые стрелки с двумя наконечниками (тип «Поток объектов») на схеме рис. 2А имеют светлый наконечник, а некоторые темный. В чем разница? Как уже говорилось выше, стрелки со светлым концом (или началом - «шарик») являются туннельными, и не показываются на диаграмме верхнего уровня. Стрелки с темным концом будут показаны на диаграмме верхнего уровня. Это удобно, когда осуществляется моделирование процесса и его подпроцессов (например, описание группы подпроцессов в рамках одного сквозного процесса). В этом случае использовать междиаграммные ссылки не нужно. Информационные потоки между подпроцессами можно показать за счет миграции стрелок с уровня на уровень (как в нотации IDEF0).

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

На рис. 3. показаны описанные выше ситуации.


Рис. 3. Использование миграции и междиаграмммных стрелок.

На рис. 3 показано, что документ «А» является выходом подпроцесса 1.2.3.1. и входом подпроцесса 2.3.2.2. Использована методика миграции стрелок. В свою очередь документ «Б» является выходом подпроцесса 1.2.3.2. и входом подпроцесса 2.3.3.3. При этом использован механизм создания междиаграммных ссылок.

В Business Studio миграцию и междиаграммные ссылки можно использовать в нотациях «Процедура» и IDEF0. Заметим, что в нотациях eEPC и BPMN в Business Studio нет ни миграции, ни междиаграммныхсссылок. Взаимодействие между процессами в этих нотация можно показать по-другому (процесс-интерфейс в eEPC и свернутый пул в BPMN).

Привязка документов к стрелкам

В нотации «Процедура» есть еще одна любопытная особенность, связанная с архитектурой самой среды BusinessStudio. Заключается она в том, что к стрелкам на диаграмме в нотации «Процедура» (и еще в нотации IDEF0) можно привязывать объекты из справочника «Объекты деятельности» как показано на рис. 4.


Рис. 4. Привязка документов к стрелкам.

Для чего это делается? Проще всего понять это, взглянув на рис. 5. Объект из справочника объектов деятельности (бумажный или электронный документ) привязывается к стрелке, показанной на диаграмме процесса. К этому объекту может быть привязан реальный файл MSWord. Практический смысл такой привязки:
a)показать документ как вход или выход в регламенте процесса;
b)вывести форму документа в приложение к регламенту процесса в MS Word.

Заметим, что форма документа в виде файла может быть либо закачана в базу Business Studio, либо на нее может быть сделана ссылка на внешний источник (файл, находящийся на каком-то жестком диске).

Стрелка на схеме (см. рис. 5) связывает два процесса между собой. К стрелке привязан объект из справочника. Таким образом, при выводе информации в регламент, для Процесса 2 в столбце таблицы «Входящие документы» будет показано название соответствующего документа из справочника. Это удобно, поскольку на схеме можно показать всего одну стрелку, к которой привязано несколько документов. Названия всех этих документов будут выведены в таблицу регламента процесса.


Рис.5. Смысл привязки документов к стрелкам в Business Studio.

Стоит подчеркнуть, что стрелка с двумя наконечниками, собственно, моделирует вход/выход на первом уровне абстракции (Словарь стрелок хранится в специальном справочнике Business Studio). На втором, более детальном, уровне используются ресурсы из справочника «Объекты деятельности», привязанные к стрелкам.И этот факт является еще одним «подводным камнем» при использовании нотации «Процедура». Некоторые неопытные пользователи Business Studio ленятся привязывать объекты к стрелкам. В результате, в регламенте процесса появляются пустые места. Некоторые, наоборот сознательно используются стрелки именно как входы/выходы и выводят в регламент названия стрелок, а не документов. Последний подход, на мой взгляд, является методически некорректным.

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

Обратим внимание, что за счет унификации внутри системы в Business Studio есть возможность привязывать документы (объекты из справочника «Объекты деятельности») к стрелкам типа «Связь предшествования». Очевидно, что с содержательной точки зрения это делать некорректно. Привязывая документы к стрелкам предшествования можно, конечно, сократить количество графических элементов на схеме процесса (что и было изначально задумано разработчиками системы). Но методически это будет некорректно и, в конечном счете, запутает читателей схемы (сотрудников компании, работающих с системой и использующие регламенты процессов). Кстати, в Business Studio в нотации eEPC привязывать документы к стрелкам, показывающим последовательность операций процесса невозможно, что полностью соответствует требованиям этой нотации.

Плохой стиль моделирования процессов в Business Studio

В заключение на рис. 6 представлен «плохой», т.е. методически некорректный стиль использования нотации «Процедура» в Business Studio.


Рис. 6. «Плохой» стиль моделирования в нотации «Процедура»Business Studio.

Предлагаем читателю самому найти ошибки (методически некорректные моменты) в данной схеме. В следующей статье серии мы приведем соответствующие ответы.

Резюме

Среда моделирования Business Studio предоставляет пользователям гибкие возможности для описания и регламентации бизнес-процессов в нотации «Процедура» (CFFC, простая блок-схема). Но сотрудникам компаний, неискушенным в моделировании, необходимо отдавать отчет в каждом своем действии в системе: что и для чего делается. Моделировать просто так, наобум – напрасно тратить время и деньги компании. Качество полученных моделей предопределяет возможность использования их для анализа и принятия решений по реорганизации, выгрузки из системы регламентирующих документов по бизнес-процессам и проч.

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

Сентябрь 2014 г.