Начало работы над моделью деятельности организации
Объектом справочника «Деятельность» является единица деятельности, как единица измеряемой деятельности предприятия. В зависимости от используемой нотации моделирования единицы деятельности могут быть разных типов. Слева от типа единицы деятельности показано его графическое обозначение в Навигаторе:
Нотацию моделирования можно изменять во время работы над моделью. При декомпозиции единицы деятельности в Навигаторе программа позволяет определить тип каждого создаваемого дочернего элемента. В дальнейшем, при необходимости, тип дочернего элемента можно изменить, если он еще не был декомпозирован. В Таблице 1 приведены типы единиц деятельности, которые можно создать с помощью пункта меню Добавить контекстного меню деятельности в Навигаторе.
| Тип текущей единицы деятельности | Типы создаваемой единицы деятельности |
|---|---|
| Папка | Папка, IDEF0, Basic Flowchart, Cross-Functional Flowchart, EPC, BPMN |
| IDEF0 | IDEF0, Basic Flowchart, Cross-Functional Flowchart, EPC, BPMN, Ссылка |
| Basic Flowchart | Basic Flowchart, Cross-Functional Flowchart, Решение, EPC, BPMN, Ссылка |
| Cross-Functional Flowchart | Basic Flowchart, Cross-Functional Flowchart, Действие, Решение, EPC, BPMN, Ссылка |
| EPC | EPC, BPMN, Ссылка |
| BPMN | EPC, BPMN, Ссылка |
| Действие | Ничего |
| Решение | Ничего |
| Ссылка | Ничего |
Состав пунктов меню Добавить в контекстном меню единицы деятельности зависит от нотации диаграммы и возможности создания типов единиц деятельности от текущей единицы деятельности. Так, например, для процесса в нотации IDEF0 на первом уровне модели доступен только пункт меню Добавить, а в меню единицы деятельности следующего уровня появляются пункты меню Добавить на этот уровень и Преобразовать в.
При использовании клавиш Ins (аналог пункта меню Добавить на этот уровень) и Shift+Ins (аналог пункта меню Добавить) открывается окно для выбора типа единицы деятельности. Если на данном уровне возможно создание только одного типа единицы деятельности, то он добавляется автоматически.
Создание первой единицы деятельности модели
В начале работы с базой данных справочник «Деятельность» пуст, и в дереве Навигатора на вкладке Деятельность объекты отсутствуют.
Так как в одной базе данных могут создаваться модели для разных предприятий, целесообразно создавать для каждой модели свою папку. Новая папка создается при помощи пункта меню Добавить → Папка в контекстном меню пустой области вкладки Деятельность (Рис. 1).
Первый объект IDEF0, добавленный от любой папки или на первом уровне на вкладке Деятельность, представляет собой процесс в нотации IDEF0 (A-0, «А минус ноль»).
Диаграмма уровня А-0 в нотации IDEF0 может содержать только одну единицу деятельности, который будет декомпозироваться. На диаграмме A-0 могут быть добавлены стрелки, согласно правилам нотации IDEF0 (подробнее см. Нотация IDEF0).
Название и код единицы деятельности
Новая единица деятельности добавляется с именем, состоящим из кода и названия. Название вводится пользователем.
Тип кода, отображаемого перед названием единицы деятельности, может быть задан для объектов справочника «Деятельность» и отдельно для заголовков диаграмм (Главное меню → Главная → Настройки для всех пользователей → вкладка Модели → группа параметров Единицы деятельности ). Для выбора типа кода, отображаемого перед названием единицы деятельности, служит параметр «Тип кода для названия объекта». Для выбора типа кода, отображаемого перед названием единицы деятельности в заголовке диаграммы, служит параметр «Тип кода для заголовка диаграммы». Для выбора в качестве типа кода доступно 3 варианта:
Свойства модели
Моделью в Business Studio называется объект справочника «Деятельность» типа «Папка» со всеми потомками папки или же единица деятельности типа IDEF0 верхнего уровня со всеми потомками. Эти папка и единица деятельности IDEF0 верхнего уровня называются корневыми объектами своих моделей соответственно.
Свойства модели задаются на вкладке Свойства модели в Окне свойств корневого объекта модели. Свойства модели влияют на всю модель. Свойства модели для любой единицы деятельности модели могут быть вызваны по гиперссылке Свойства модели в Окне свойств этой единицы деятельности (Рис. 3).
Код единицы деятельности модели формируется в соответствии с настройками, заданными в свойствах модели.
Для обеспечения большей гибкости в отношении нумерации единиц деятельности существует возможность задать настройки для двух типов кодов: простого и полного.
При выборе параметров, значение которых будет использоваться в качестве значения кода единицы деятельности, рекомендуется выбирать из параметров «Номер», «Иерархический код» и «Ручной код»:
Преобразование типа единицы деятельности
Пункт контекстного меню Преобразовать в позволяет изменить тип единицы деятельности при условии, что единица деятельности еще не декомпозирована (не имеет потомков). Для единиц деятельности с типом Basic Flowchart, Cross-Functional Flowchart, EPC, BPMN, Ссылка преобразование зависит от типа их родителя. В Таблице 2 приведены исходные типы Единиц деятельности и соответствующие им типы преобразования.
Построение системы процессов в среде Business Studio
Владимир Репин
Генеральный директор ООО «Владимир Репин Менеджмент»
Руководитель отдела Анализа и методологического обеспечения ПО № 8 ГБУ «Аналитический центр» Департамента экономической политики и развития города Москвы
Консультант по управлению
Кандидат технических наук
В статье обсуждаются вопросы построения системы организации и ее использования в среде моделирования процессов. Представлен пример системы процессов торговой компании, созданной в среде моделирования Business Studio.
Методика построения системы процессов компании
В данном разделе представлен авторский взгляд на построение в компании системы (архитектуры) процессов.
Подход к построению системы процессов организации можно сравнить с собиранием пазла. Для того, что собрать картинку из большого количества разрозненных элементов нужно:
Очевидно, что в случае потери общей картинки задача сборки элементов пазла существенно усложняется.
Переводя эту аналогию на язык можно сказать, что:
Один из возможных алгоритмов построения системы процессов организации представлен на рис 1.
Рис. 1. Алгоритм построения системы процессов организации
На первом шаге осуществляется разработка модели процессов организации на верхнем уровне. Цель создания модели — понимание того, как устроен бизнес организации. Рекомендуется создавать эту модель, используя принципы определения и построения схем цепочек создания ценности (ЦСЦ). Формируемая модель является структурной. Ее назначение — системно показать процессы компании на верхнем уровне и основные, наиболее важные связи между ними. Для создания структурной модели можно использовать любую, понятную и удобную нотацию ( IDEF0 ). Главное, чтобы эта нотация соответствовала поставленной задаче. Для создания структурной модели можно использовать MS Visio, как наиболее доступный инструмент. На крайний случай, можно нарисовать модель на бумаге.
На шаге 2 осуществляется анализ деятельности структурных подразделений, выявление и структурирование процессов, которые в них выполняются. В случае, если позволяют человеческие ресурсы, шаги 1 и 2 можно выполнять одновременно. Заметим, что информация о процессах подразделений представляется в табличной форме (в MS Excel).
После получения видения процессов организации в целом (структурная модель процессов на верхнем уровне) и информации по процессам структурных подразделений на шаге 3 формируется первая версия системы процессов организации. Она представляет собой таблицу в MS Excel, включающую несколько столбцов:
Заметим, что схемы ЦСЦ являются промежуточным, рабочим материалом, необходимым для понимания бизнеса в целом и создания основы, «скелета» системы процессов. Но результат работы (система процессов) представляется в табличной форме.
На шаге 4 выполняется согласование границ процессов по входам/выходам и инициирующим/завершающим событиям. Это довольно длительный и затратный с точки зрения вовлечения человеческих ресурсов этап, но он позволяет сделать систему более адекватной. Как правило, при согласовании входов/выходов структура процессов несколько изменяется. Обратим внимание, что для процессов 1 и 2 уровня нужно согласовывать только границы ответственности руководителей на уровне решаемых задач, достигаемых целей «Стыковка» на уровне реальных рабочих документов выполняется на 3 и 4 уровнях.
По итогам выполнения этого шага формируется вторая версия системы процессов организации. Уточняются должности руководителей, ответственных за выполнение процессов, и состав участников на уровне подразделений и должностей сотрудников.
На шаге 5 осуществляется согласование системы процессов. Результатом является третья, согласованная версия системы процессов. Она является рабочей и используется на следующих этапах проекта внедрения процессного подхода.
Обычно для разработки адекватной бизнесу системы процессов требуется не менее 3–4 итераций. Для компании среднего размера (численность 1000–1500 человек, 100–150 сотрудников руководящего состава) такая работа занимает около 2 месяцев.
Важно, чтобы работу по формированию системы процессов организации выполняли квалифицированные или внешние консультанты. Возможен вариант организации совместной команды. Нежелательно поручать такую важную задачу, как построение системы процессов организации, малоопытным и недостаточно компетентным сотрудникам.
Использование отраслевых решений и материалов других компаний
На практике при построении системы процессов могут использоваться:
Если в команде проекта есть эксперты, владеющие указанной выше информацией, то построение системы процессов организации можно выполнять, не разрабатывая схемы цепочек создания ценности ( не формируя структурную графическую модель верхнего уровня). Дело в том, что у таких экспертов уже есть видение того, как работает бизнес, и понимание, как можно структурировать процессы для компаний данной отрасли.
В этом случае берется материал, наработанный в другой компании. Далее он корректируется и уточняется с использованием информации о процессах структурных подразделений рассматриваемой организации.
Необходимость графической модели процессов на верхнем уровне
Отдельно стоит обсудить, насколько полезны графические модели процессов для построения системы процессов. Например, с точки зрения автора, ошибкой является попытка построения многоуровневой системы процессов организации в одной модели IDEF0 (или другой нотации). Если соблюдать формальные правила, то в такой модели может получиться 7–8 уровней декомпозиции. Но реальную ценность для последующего описания и регламентации имеет всего 1–2 нижних уровня, где выполнятся конкретные операции процессов и осуществляется реальный документооборот! Именно на этих уровнях процессы могут быть описаны в формате Work Flow (поток работ), и при помощи этих описаний сформированы регламенты работы сотрудников («регламент процесса», «инструкция по выполнению процесса» ).
Можно сказать, что структурная модель верхнего уровня нужна:
Заметим, что руководители компаний, которые умеют и хотят работать со структурной графической моделью процессов верхнего уровня, на практике встречаются исключительно редко.
Пример построения системы процессов торговой компании
Рис. 2. ЦСЦ торговой компании
Данная схема не полностью соответствовала реальности рассматриваемой компании. Ее использовали только в качестве основы для дальнейшего обсуждения структуры процессов на верхнем уровне. Кроме схемы, была использована система процессов другой торговой компании. Также был учтен опыт работы в других компаниях аналогичного профиля.
В результате обсуждения появилась первая версия системы процессов компании. Ее фрагмент представлен на Рис. 3.
Рис. 3. Первая версия системы процессов торговой компании
На рисунке видно, что уровень «подпроцессов» и «операций» не заполнен. Определены только «группы процессов» и «процессы».
После получения первой версии системы, провели серию совещаний с руководителями подразделений, в ходе которых уточнялась структура процессов и определялись подпроцессы. В некоторых случаях, удалось сразу дойти до уровня операций.
В результате анализа процессов структурных подразделений компании, была разработана вторая версия системы процессов. Затем были уточнены ответственные и участники процессов.
Рис. 4. Четвертая версия системы процессов торговой компании
Было принято решения описывать на отдельных листах MS Excel процессы:
Создание системы процессов в Business Studio
После того, как система процессов была создана и согласована в виде файла MS Excel, было принято решение перенести ее в среду моделирования Business Studio. Данные были предварительно обработаны и загружены в Business Studio. Это легко можно сделать путем пакетного импорта из файла MS Excel. Результат (дерево процессов) представлен на Рис. 5.
Рис. 5. Система процессов торговой компании в Business Studio
Были созданы три папки: «Процессы ЦО», «Процессы РЦ» и «Процессы УН». Внутри этих папок процессы имеют структуру. Четвертый уровень — это уровень операций, выполняемых конкретными сотрудниками подразделений.
На Рис. 6. показан пример описания одного из операционных процессов в нотации «Процедура» Business Studio.
Заметим, что в данном проекте стыковка процессов по входам/выходам в файле MS Excel не осуществлялась. Это решено было делать при последовательном описании и согласовании схем процессов 3 или 4 уровня в Business Studio.
Рис. 6. Описание процессов в нотации «Процедура»
Для того, чтобы можно было моделировать процессы, используя существующие названия подразделений и должностей, в среде Business Studio была описана схема организационной структуры компании. Поскольку она была довольно сложной, пришлось создавать модель на нескольких уровнях (см. Рис. 7 и 8).
Рис. 7. Описание организационной структуры компании в Business Studio
Рис. 8. Описание организационной структуры подразделения компании в Business Studio
После описания ряда пилотных процессов, был разработан отчет, выводящий информацию о процессах в нужном компании виде — «Инструкции по выполнению процесса». Данный документ предназначался для регламентации деятельности конкретных сотрудников компании на операционном уровне.
Заключение
Еще раз обратим внимание на систему процессов в среде моделирования Business Studio, представленную на Рис. 5. Важно, что описание процессов в такой системе можно начинать с третьего или, лучше, с четвертого уровня — там, где есть реальный документооборот. Это означает, что процессы первого и второго уровня вообще можно не описывать! В этом случае исключаются значительные затраты времени на моделирование и согласование «неисполняемых» (в BPMS) и «нерегламентируемых» (слишком общие для этой цели) «процессов» 1 и 2 уровня.
Возможно, такой подход вызовет критику со стороны некоторых системных аналитиков. Но, с точки зрения автора статьи, создание «системных» графических моделей верхнего уровня, непонятных и ненужных руководителям и сотрудникам организации, не является лучшей альтернативой с практической точки зрения.
Начало работы над моделью деятельности организации
Объектом справочника «Процессы» является процесс, как единица измеряемой деятельности предприятия. В зависимости от используемой нотации моделирования процессы могут быть разных типов. Слева от типа процесса показано его графическое обозначение в Навигаторе:
Нотацию моделирования можно изменять во время работы над моделью. При декомпозиции процесса в Навигаторе программа позволяет определить тип каждого создаваемого подпроцесса. В дальнейшем, при необходимости, тип подпроцесса можно изменить, если он еще не был декомпозирован. В Таблице 1 приведены типы процессов, которые можно создать с помощью пункта меню Добавить контекстного меню процесса в Навигаторе.
| Тип текущего процесса | Типы создаваемого процесса |
|---|---|
| Папка | Папка, IDEF0, Процесс, Процедура, EPC, BPMN |
| IDEF0 | IDEF0, Процесс, Процедура, EPC, BPMN, Ссылка |
| Процесс | Процесс, Процедура, Решение, EPC, BPMN, Ссылка |
| Процедура | Процесс, Процедура, Действие, Решение, EPC, BPMN, Ссылка |
| EPC | EPC, BPMN, Ссылка |
| BPMN | EPC, BPMN, Ссылка |
| Действие | Ничего |
| Решение | Ничего |
| Ссылка | Ничего |
Состав пунктов меню Добавить в контекстном меню процесса зависит от нотации диаграммы и возможности создания типов процессов от текущего процесса. Так, например, для процесса в нотации IDEF0 на первом уровне модели доступен только пункт меню Добавить, а в меню процесса следующего уровня появляются пункты меню Добавить на этот уровень и Преобразовать в.
При использовании клавиш Ins (аналог пункта меню Добавить на этот уровень) и Shift+Ins (аналог пункта меню Добавить) открывается окно для выбора типа процесса. Если на данном уровне возможно создание только одного типа процесса, то он добавляется автоматически.
Создание первого процесса модели
В начале работы с базой данных справочник «Процессы» пуст, и в дереве Навигатора на вкладке Процессы объекты отсутствуют.
Так как в одной базе данных могут создаваться модели для разных предприятий, целесообразно создавать для каждой модели свою папку. Новая папка создается при помощи пункта меню Добавить → Папка в контекстном меню пустой области вкладки Процессы (Рис. 1).
Первый объект IDEF0, добавленный от любой папки или на первом уровне на вкладке Процессы, представляет собой процесс в нотации IDEF0 (A-0, «А минус ноль»).
Диаграмма уровня А-0 в нотации IDEF0 может содержать только один процесс, который будет декомпозироваться. На диаграмме A-0 могут быть добавлены стрелки, согласно правилам нотации IDEF0 (подробнее см. Нотация IDEF0).
Название и код процесса
Новый процесс добавляется с именем, состоящим из кода и названия. Название вводится пользователем.
Тип кода, отображаемого перед названием процесса, может быть задан для объектов справочника «Процессы» и отдельно для заголовков диаграмм (Главное меню → Главная → Настройки для всех пользователей → вкладка Модели → группа параметров Процессы). Для выбора типа кода, отображаемого перед названием процесса, служит параметр «Тип кода для названия объекта». Для выбора типа кода, отображаемого перед названием процесса в заголовке диаграммы, служит параметр «Тип кода для заголовка диаграммы». Для выбора в качестве типа кода доступно 3 варианта:
Свойства модели
Моделью в Business Studio называется объект справочника «Процессы» типа «Папка» со всеми потомками папки или же процесс типа IDEF0 верхнего уровня со всеми потомками. Эти папка и процесс IDEF0 верхнего уровня называются корневыми объектами своих моделей соответственно.
Свойства модели задаются на вкладке Свойства модели в Окне свойств корневого объекта модели. Свойства модели влияют на всю модель. Свойства модели для любого процесса модели могут быть вызваны по гиперссылке Свойства модели в Окне свойств этого процесса (Рис. 3).
Код процесса модели формируется в соответствии с настройками, заданными в свойствах модели.
Для обеспечения большей гибкости в отношении нумерации процессов существует возможность задать настройки для двух типов кодов: простого и полного.
При выборе параметров, значение которых будет использоваться в качестве значения кода процесса, рекомендуется выбирать из параметров «Номер», «Иерархический код» и «Ручной код»:
Преобразование типа процесса
Пункт контекстного меню Преобразовать в позволяет изменить тип процесса при условии, что процесс еще не декомпозирован (не имеет потомков). Для процессов с типом Процесс, Процедура, EPC, BPMN, Ссылка преобразование зависит от типа их родителя. В Таблице 2 приведены исходные типы Процессов и соответствующие им типы преобразования.
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, простая ). Но сотрудникам компаний, неискушенным в моделировании, необходимо отдавать отчет в каждом своем действии в системе: что и для чего делается. Моделировать просто так, наобум — напрасно тратить время и деньги компании. Качество полученных моделей предопределяет возможность использования их для анализа и принятия решений по реорганизации, выгрузки из системы регламентирующих документов по и проч.
