Нотация cffc что это
Процедура отображает детальный алгоритм выполнения бизнес-процесса, а так же всех участников бизнес-процесса и как они взаимодействуют между собой в рамках Процедуры. Дорожка на диаграмме означает должность, подразделение и роль. На дорожках Процедуры размещаются действия, за которые и отвечает должность, подразделение, роль. Каждое действие может быть декомпозировано (разбито на более детальные бизнес-процессы) в нотациях Процедура, EPC или Процесс.
Действия на дорожках Процедуры связаны между собой информационными или материальными потоками.
Дорожки на кросс-функциональной схеме могут быть как горизонтальные, так и вертикальные. Выбор направления зависит от стандарта предприятия или вкуса разработчика Процедуры.
На Процедуре так же могут использоваться решения (условия) для ветвления бизнес-процесса.
Недостатки Процедуры. В некоторых случаях может быть удобней использовать дополнительные графические элементы, которые имеются в других нотациях.
Преимущества Процедуры значительные, т.к. нотация является очень простой для создания и пониманиями сотрудниками с разным уровнем подготовки.
Основные потребители Процедуры – сотрудники разных уровней организации.
Другие нотации бизнес-моделирования, поддерживаемые в Business Studio:
Пример диаграммы процесса в нотации Процедура (Cross Functional Flowchart)
Нотации моделирования бизнес-процессов
Нотация IDEF0
Наиболее популярная нотация моделирования бизнес-процессов, основанная на методологии структурного анализа SADT. Методология IDEF0 — это методология моделирования, позволяющая создать функциональную модель, отображающую структуру и функции системы, а также потоки информации и материальных объектов, связывающие эти функции (на рисунке представлена графическая диаграмма в нотации IDEF0 — пример реализован в системе Business Studio, которая включает в себя функции программы для построения IDEF0). Бизнес-процессы в нотации IDEF0 представляются в форме прямоугольника, а стрелки отражают связь с другими процессами и внешней средой. Особенностью нотации является:
Нотация IDEF0 используется для создания верхнего уровня модели бизнес-процессов. Построение IDEF0-диаграммы верхнего уровня обеспечивает наиболее общее или абстрактное описание объекта моделирования. На нижнем уровне для описания алгоритма (сценария) выполнения процесса допустимо сменить стандарт IDEF0 на нотацию Процесс, Процедура, EPC или BPMN 2.0.
Подробнее о нотации IDEF0
С методологией SADT можно подробно ознакомиться в монографии Дэвида А. Марка и Клемента МакГоуэна «Методология структурного анализа и проектирования SADT».
Нотация Процесс (Basic Flowchart в Visio)
Данная нотация используется для представления алгоритма выполнения процесса (нотация класса workflow). Используются графические элементы: событие, процесс, решение, два типа стрелок — стрелки предшествования и стрелки «Поток объектов».
Нотация Процесс поддерживает декомпозицию на подпроцессы.
Нотацию Процесс можно применять для моделирования отдельных процессов компании, а также на нижнем уровне модели бизнес-процессов, созданной в нотации IDEF0.
Нотация Процедура (Cross-Functional Flowchart в Visio)
Данная нотация используется для представления алгоритма выполнения процесса (нотация класса workflow). Дополнительно к графическим элементам, применяемым в нотации Процесс, используются дорожки (Swim Lanes), обозначающие организационные единицы — исполнителей действий процесса.
Нотация Процедура поддерживает декомпозицию на подпроцессы.
Нотацию Процедура можно применять для моделирования отдельных процессов компании, а также на нижнем уровне модели бизнес-процессов, созданной в нотации IDEF0.
Нотация BPMN 2.0
Данная нотация используется для представления алгоритма выполнения процесса (нотация класса workflow). Особенностью нотации BPMN 2.0, появившейся в качестве стандарта моделирования в 2011 году, является то, что она предназначена как для моделирования бизнес-процессов, так и для их исполнения. Она доступна для понимания и удобна как бизнес-аналитикам, так и разработчикам, которые занимаются автоматизацией исполнения процессов. Для экспорта схемы процесса в BPMS-систему в Business Studio используется стандарт XPDL.
В Business Studio представлено 2 типа диаграмм BPMN 2.0 — диаграммы процессов и диаграммы взаимодействия процессов. Используются следующие графические элементы: процессы, события, шлюзы; 3 типа стрелок: поток управления, поток сообщений, ассоциации; объекты: документы, информация, сообщения, базы данных. Важно, что в Business Studio все элементы диаграмм BPMN являются объектами репозитория.
В Business Studio в нотации BPMN можно строить иерархическое дерево процессов, т.е. поддерживается декомпозиция.
Для процесса BPMN можно автоматически сформировать регламент и другие отчеты, эта нотация применяется преимущественно для описания процессов нижнего уровня, особенно со сложной логикой исполнения.
Нотация EPC (Event-Driven Process Chain)
Данная нотация используется для представления алгоритма выполнения процесса (нотация класса workflow). Диаграмма, описанная в нотации EPC (событийная цепочка процессов), представляет собой упорядоченную комбинацию событий и функций. Для каждой функции могут быть определены начальные и конечные события, участники, исполнители, материальные и документальные потоки, сопровождающие её. В нотации EPC ветвление стрелок осуществляется с использованием операторов.
Нотация EPC поддерживает декомпозицию на более низкие уровни. Диаграмма декомпозируемой функции EPC может быть описана только в нотациях EPC или BPMN 2.0.
Нотацию EPC можно применять для моделирования отдельных процессов компании, а также на нижнем уровне модели бизнес-процессов, созданной в нотации IDEF0.
Система моделирования бизнес-процессов: возможности, влияющие на эффективность практического применения
Функциональные возможности систем моделирования бизнес-процессов, которые могут существенно повлиять на эффективность их практического применения в ближайшем будущем.
В статье В.В. Репина рассматриваются функциональные возможности систем моделирования бизнес-процессов, которые могут существенно повлиять на эффективность их практического применения в ближайшем будущем. Автор приглашает к диалогу как пользователей систем (бизнес-аналитики, менеджеры по развитию), так и потенциальных клиентов.
Для чего нужна система моделирования?
В статье речь пойдет о программных продуктах определенного класса – системах моделирования бизнес-процессов (ARIS, Casewise, iGrafx, Business Studio и др.). С точки зрения автора статьи, такие системы могут быть весьма полезны при создании базы знаний компании, основанной на процессном взгляде на деятельность. Эти системы позволяют:
● создавать комплексные, многоуровневые модели бизнес-процессов, организационной структуры, документов, целей и показателей, которые могут, в первую очередь, быть использованы для оптимизации (реинжиниринга) бизнес-процессов и орг. структуры организации;
● накапливать информацию в контексте процессов (результаты внутренних аудитов, выполнения корректирующих и предупреждающих действий, проектов оптимизации; информации по бенчмаркингу и проч.);
● генерировать для персонала компании информацию регламентирующего характера (регламенты, инструкции, положения и т.п.) в форме документов MS Word или в виде страниц на web-портале;
● выполнять имитационное моделирование бизнес-процессов с целью поиска направлений их оптимизации;
● частично поддерживать деятельность по оперативному управлению (ввод/вывод плановых и фактических значений показателей, в т.ч. с использование web-портала);
● разрабатывать технические задания для автоматизации бизнес-процессов (например, путем создания моделей в нотации BPMN).
В настоящее время наблюдается активное развитие систем моделирования. На мой взгляд, существует ряд аспектов, которые могут существенно повлиять на эффективность практического применения систем моделирования в ближайшем будущем. Рассмотрим их последовательно.
Регламент без регламента
Практически все руководители компаний в той или иной степени убеждены в необходимости регламентации деятельности своих сотрудников. При достижении определенного уровня зрелости компания не может без них обойтись. Однако как только в организации появляется значительное число регламентирующих документов, возникает ситуация, когда эти документы:
● своевременно не обновляются;
● противоречат друг друг;
● частично дублируют друг друга;
С точки зрения сотрудников, использующих регламенты, проблема выглядит так:
● нет времени читать «толстые» регламенты;
● сложно находить нужную информацию в большом количестве документов;
● долго и сложно вносить изменения в связанные между собой нормативные документы;
Таким образом, налицо конфликт между необходимостью регламентировать деятельность и сложностью практического использования нормативных документов. В рамках стандартного, общепринятого взгляда этот конфликт является неразрешимым. Поэтому многие консультанты ищут ответ в использовании других методов, в первую очередь в автоматизации бизнес-процессов. Однако автоматизация, к сожалению, по разным причинам не устраняет данный конфликт в полной мере (не все процессы можно автоматизировать и т.д.). Нужно искать решение в другой плоскости.
Именно в этой связи стоит сказать про первый функциональный аспект среды моделирования бизнес-процессов, который данный конфликт практически устраняет. Он может быть сформулирован следующим образом:
Полный отказ от регламентирующих документов в традиционном смысле (бумага, файлы MS Word или pdf). Информация, опубликованная со статусом «Утверждено» на внутреннем web-портале компании, заменяет собой регламенты, т.е. является обязательной к исполнению.
Что это означает? Среда моделирования используется в качестве базы знаний по бизнес-процессам. После внесения изменений в модель процесса (орг. структуры, документов и т.п.), информация становится доступной на портале со статусом «На согласовании». Web-портал (тесно интегрированный или непосредственно являющийся модулем среды моделирования) позволяет осуществлять согласование и утверждение изменений в электронном виде (в т.ч. с использование ЭЦП). Кроме того, система дает возможность:
● визуализировать последние изменения (например, выделять цветом на схемах те операции процесса, требования к которым были изменены);
● уведомлять пользователей по e-mail;
● визуализировать изменения различного в виде иконок (как, например, сделано на facebook);
● автоматически генерировать список всех изменений с гиперссылками на нужные разделы регламентов, которые касаются именно данного сотрудника;
Таким образом, скорость внесения изменений в массив регламентирующей информации радикально изменяется. С учетом наличия таких устройств, как планшеты, у всех сотрудников появляется быстрый и легкий способ доступа к нужной именно ему информации.
Простота моделирования
Второй аспект работы со средой моделирования – это простота. Для работы нужна простая, но выразительная нотация описания процессов. Но что мы имеем на сегодняшний день? CFFC (Cross Functional Flow Chart) – диаграмма с «ромбиками», eEPC и BPMN. Последняя нотация – самая сложная. Некоторые считают, что ее может использовать любой сотрудник компании, если ограничить количество применяемых элементов (т.е. фактически создать т.н. «методический фильтр», как это в свое время делали консультанты при внедрении ARIS). Но на практике довольно сложно обучить большое количество людей в компании корректно использовать BPMN. Итак, нужна нотация, которая была бы простой и понятной «с первого взгляда» обычного человека, но в то же время достаточно выразительной для целей описания реального бизнес-процесса.
Есть еще одна проблема, но в другой плоскости. Удобно ли отображать информационные потоки на диаграмме BPMN? Скорее «нет», чем «да». А если нужно будет изобразить другую информацию, например материальные потоки? В свое время ARIS предлагал решать такого рода проблему путем создания множества моделей разного типа, описывающих один и тот же процесс. Сложно назвать такой подход удобным для пользователя.
Думаю, что в перспективной системе бизнес-моделирования должны быть реализованы «многослойные» модели. Т.е. модель будет одна, но можно будет переключаться между слоями, меняя визуальное представление. Хотим видеть на схеме потоки управления – включаем слой «Work Flow/Control Flow». Хотим видеть потоки данных и хранилища – включаем слой «Data Flow» и т.п. Почему при бизнес-моделировании до сих пор нет возможности делать слои, как в P-CAD или Photo Shop?!
Далее. Очень бы хотелось уйти от необходимости разрабатывать отчеты для вывода информации из системы путем сложных настроек, требующих хороших знаний структуры данных модели, программирования на каких-то языках и т.п. Нужна возможность простого визуального проектирования отчета по принципу «взял нужный атрибут со схемы (из описания объекта) и перетащил в шаблон отчета». Система должна сама определять нужную структуру запроса к базе данных. Слишком уж сложно сейчас проектировать отчеты для пользователей, если их потребности выходят за рамки простейших и банальных требований. В этой связи хочется добавить еще возможность простого визуального расширения структуры данных модели без необходимости глубокого владения системными командами и т.п.
Все в web
Современная система моделирования процессов, на мой взгляд, должна работать через web-броузер, т.е. не иметь каких-либо десктопных приложений (за исключением сервера базы данных и служебных приложений для администраторов). Таким образом, работа будет осуществляться прямо в броузере – графические схемы, справочники процессов, орг. структура, документы и проч. При этом должна существовать возможность фильтровать информацию по статусам моделей (например «Для публикации»). Кроме того, обязательно должна быть реализована возможность использовать ЭЦП для согласования и утверждения моделей процессов.
Следует особенно подчеркнуть важность такого параметра системы, как скорость работы. При использовании web-портала информация должна обновляться практически мгновенно. Страницы со схемами процессов и документами должны открываться очень быстро. Иначе пользователи просто не захотят пользоваться справочной и регламентирующей информацией из системы. Не должно быть таких ситуаций, когда процесс обновления информации из базы на web-портале загружает сервер на много часов, если не суток.
Работа на web-портале среды моделирования даст возможность измерять активность пользователей, анализировать, какая информация пользуется спросом, а какая нет. Таким образом, легко будет рассчитать ряд показателей, по которым можно управлять системой описания и регламентации бизнес-процессов компании, планомерно повышая ее эффективность.
Еще одной особенностью должна стать возможность гибкой настройки интерфейса системы под свои задачи. Пользователь должен иметь комфортное информационное пространство для работы, а не жесткое меню, построенное в логике разработчика системы и понятное только ему.
Процесс без графической схемы
Поддержка оперативного управления
Оперативное управление процессами предполагает планирование и контроль деятельности по определенным показателям. Система моделирования будет гораздо более востребованной практически, если обеспечит возможность интеграции с учетными системами и возможность ввода/вывода плановых и фактических значений показателей. Обязательно должна быть возможность быстрой и легкой настройки панелей управления с интерактивными графиками и диаграммами, которые необходимы руководителю для управления процессом. Конечно, в данном случае налицо пересечение функциональных возможностей системы с BI/BPM (Business Performance Management). Поэтому, видимо, необходима интеграция с такими системами, но обязательно в удобной пользователю форме и через web-интерфейс.
Прочие
Среди прочих, не таких значительных аспектов перспективной системы бизнес-моделирования, можно упомянуть следующие:
● легкость перехода с версии на версию;
● отсутствие глюков (багов);
● цена решения (не более 3 тыс. рублей за одно рабочее место).
Процессное управление «пойдет в массы» только при наличии простого, удобного, эффективного и дешевого программного инструмента.
Резюме
Приглашаю к дискуссии. Уверен, что практикующие бизнес-аналитики предложат еще десяток-два аспектов, которые являются для них критичными. Собственно, статья и была написана для того, чтобы обсудить различные взгляды на требования к перспективной системе моделирования бизнес-процессов.
Нотация «Процедура»
Диаграмма процесса в нотации «Процедура» (Cross-Functional Flowchart) отличается от диаграмм процессов в других нотациях. В ней используются субъекты и процессы типов «Решение», «Действие», а также «События». Подробнее о решении и событиях см. Нотация «Процесс».
На Рис. 1 показан фрагмент диаграммы процесса в нотации «Процедура».
Диаграмма процесса в нотации «Процедура» делится субъектами на колонки, в которых размещаются процессы типа «Действие». Над колонками субъектов показывается поле с названием процесса в нотации «Процедура», слева от первой колонки находится служебное поле диаграммы.
Колонки субъектов на диаграмме можно расположить горизонтально или вертикально (рекомендуется использовать вертикальное расположение). Способ расположения выбирается в окне Функциональная блок-схема, которое открывается один раз при добавлении на диаграмму первого субъекта (Рис. 2).
Палитра элементов окна диаграммы процесса в нотации «Процедура»
Описание назначения кнопок палитры элементов Окна диаграммы процесса в нотации «Процедура» приведено в Таблице 1.
Работа с диаграммой процесса в нотации «Процедура»
Субъекты на диаграмме процесса в нотации «Процедура»
Субъекты на диаграмму процесса в нотации «Процедура» добавляются перетаскиванием из иерархического справочника субъектов, который показывается в Навигаторе. Подробнее о перетаскивании элементов на диаграмму см. Добавление элементов на диаграмму перетаскиванием.
Для вставки дорожки субъекта между двумя дорожками, присутствующими на диаграмме, следует переместить курсор мыши чуть выше линии, разделяющей дорожки субъектов, и нажать на появившийся синий треугольник или, в случае отсутствия треугольника, на оранжевую галочку. В открывшемся окне необходимо выбрать субъекта, которого требуется добавить на диаграмму (Рис. 3).
Можно изменить добавленный ранее субъект на другой с помощью пункта меню Сменить объект в контекстном меню заголовка дорожки. При этом автоматически изменится связь с субъектом с типом «выполняет» для всех действий, находящихся в колодце данного субъекта.
При переименовании дорожки субъекта на диаграмме новое название может совпасть с названием субъекта, уже существующего в справочнике «Субъекты». В этом случае будет предложено выбрать одно из действий: заменить субъект диаграммы на субъект из справочника или переименовать субъект диаграммы, присвоив ему такое же название, как у субъекта из справочника (Рис. 4).
В случае выбора радиокнопки Переименовать объект… субъект будет переименован на всех диаграммах, на которых присутствует.
Внимание!
Действие считается помещенным в дорожку субъекта по центральной точке фигуры (Рис. 5).
При увеличении ширины элемента диаграммы, расположенного внутри дорожки субъекта, ширина этой дорожки будет также пропорционально увеличиваться.
При добавлении очередного субъекта может оказаться, что страница диаграммы не вмещает новую дорожку (Рис. 6). Дорожка субъекта, тем не менее, будет добавлена на диаграмму. Чтобы изменить ширину дорожки, выделите её и подвиньте значок на боковой грани заголовка (подробнее о графической трансформации объектов на диаграмме см. Графическая трансформация объектов на диаграмме). Высоту поля заголовка также можно изменить, передвигая значок на верхней или нижней грани заголовка. При изменении высоты заголовка одной дорожки меняется высота заголовка всех других.
Для изменения ширины сразу всех дорожек диаграммы выделите группу дорожек и подвиньте значок на боковой грани контура группы.
Кроме того, можно изменить масштаб диаграммы, чтобы на листе отображалось все содержимое. Подробнее об изменении параметров страницы диаграммы см. Изменение параметров страницы диаграммы.
Business Studio, нотация «Процедура»: границы процессов, события, стрелки
Владимир Репин
Генеральный директор ООО «Владимир Репин Менеджмент»
Руководитель отдела Анализа и методологического обеспечения ПО № 8 ГБУ «Аналитический центр» Департамента экономической политики и развития города Москвы
Консультант по управлению
Кандидат технических наук
Введение
Мы затронем только три аспекта моделирования: определение границ процессов, использование событий и привязка документов к стрелкам. Первые два аспекта важны независимо от применяемой системы моделирования. Третий обусловлен особенностями архитектуры именно Business Studio.
Границы процессов
На рис. 1 показано, что для определения границ любого процесса необходимо определить:
Входы/выходы процесса — это информационные или материальные ресурсы. При определении границ процесса важно четко определить требования к этим ресурсам. Это можно сделать при помощи разного рода спецификаций. Кроме того, желательно продумать, как именно (по какой методике) нужно будет проверять соответствие входящего/исходящего ресурса установленной спецификации (требованиям).
Рис. 1. Определение границ процесса: входы/выходы и события
Понятие входов/выходов достаточно очевидно и понятно. Сложнее обстоит дело с понятием «событие». Неискушенные в сотрудники не сразу понимают смысл и ценность использования понятия «события» для описания процессов, делая акцент при моделировании только на информационные (материальные) потоки (входы/выходы). В результате границы процессов в моделях оказываются определены нечетко. Что снижает практическую ценность моделей для последующего анализа и принятия решений (по зонам ответственности менеджеров, реорганизации процесса, регламентации и проч.).
Давайте попытаемся понять, что же такое «событие». В «Википедии» приводится следующее определение:
«Событие — то, что имеет место, происходит, наступает в произвольной точке ; значительное происшествие…»
Определение, конечно, не очень четкое. Оно скорее философское. Посмотрим, что говорят профессиональные стандарты.
В стандарте ISO 19510 «Information technology — Object Management Group Business Process Model and Notation» в разделе 8.4.5 Events приводится следующее определение события:
К сожалению, это тоже не самое понятное и четкое определение.
Обратимся к стандартам ARIS. Определение, приводимое в «Методах ARIS» сформулировано следующим образом:
Указанное определение является более четким и практически ориентированным.
Так же приведем определение события, сформулированное разработчиком среды моделирования Business Studio:
Состояние, зафиксированное в момент времени с нулевой длительностью, важное с точки зрения анализа поведения моделируемой системы.
С точки зрения практических задач моделирования можно определить, как минимум, три разных типа событий, на примере которых понятие события становится более очевидным (см. примеры на рис. 1):
Итак, ключевое назначение событий в модели:
Подчеркнем, понятие «событие» используется во всех современных нотациях, используемых для моделирования на операционном уровне (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. Использование миграции и междиаграмммных стрелок
В Business Studio миграцию и междиаграммные ссылки можно использовать в нотациях «Процедура» и IDEF0. Заметим, что в нотациях eEPC и BPMN в Business Studio нет ни миграции, ни междиаграммныхсссылок. Взаимодействие между процессами в этих нотация можно показать ( в eEPC и свернутый пул в BPMN).
Привязка документов к стрелкам
В нотации «Процедура» есть еще одна любопытная особенность, связанная с архитектурой самой среды BusinessStudio. Заключается она в том, что к стрелкам на диаграмме в нотации «Процедура» (и еще в нотации IDEF0) можно привязывать объекты из справочника «Объекты деятельности» как показано на рис. 4.
Рис. 4. Привязка документов к стрелкам
Для чего это делается? Проще всего понять это, взглянув на рис. 5. Объект из справочника объектов деятельности (бумажный или электронный документ) привязывается к стрелке, показанной на диаграмме процесса. К этому объекту может быть привязан реальный файл MSWord. Практический смысл такой привязки:
Заметим, что форма документа в виде файла может быть либо закачана в базу 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, простая ). Но сотрудникам компаний, неискушенным в моделировании, необходимо отдавать отчет в каждом своем действии в системе: что и для чего делается. Моделировать просто так, наобум — напрасно тратить время и деньги компании. Качество полученных моделей предопределяет возможность использования их для анализа и принятия решений по реорганизации, выгрузки из системы регламентирующих документов по и проч.