Моделирование схем в нотации BPMN в Business Studio 5
1 Процесс, его контекст и подход к описанию 2 Нотация BPMN 2.1 Основы графической схемы процесса 2.2 Базовые стартовые и конечные события 2.3 Операции и потоки управления 2.3.1 Декомпозиция процессов 2.4 Базовые шлюзы 2.4.1 Правила использования шлюзов. Логические ошибки 2.5 Базовые промежуточные события 2.6 Документы и потоки информации 2.6.1 Статусы документов 2.7 Программный продукт. Сервисная задача 2.8 Базы данных 2.9 Сущности CRM 2.10 Сноски 2.11 Межпроцессное взаимодействие 2.11.1 Старт и завершение процесса событиями-сообщениями 2.11.2 Промежуточные события отправки и получения сообщений 2.11.3 Потоки документов между процессами 2.11.4 Внешние ссылки 2.12 Дополнительные элементы 2.12.1 Типы задач и циклов 2.12.2 Старт процесса несколькими событиями 2.12.3 Сложные шлюзы 2.12.4 Граничные события 2.12.5 Описание сквозных процессов 3 Справочники 3.1 Деятельность, Оргединицы, Внешние ссылки 3.2 Функциональные объекты 4 Прочие правила 5 Организация работы по описанию процессов 6 Формальный анализ качества схемы (чек-лист) 7 Содержательный анализ схемы процесса 8 Заключение. Шпаргалка. Основные элементы нотации BPMN Содержание 2
3 Процесс – это устойчивая, целенаправленная совокупность взаимосвязанных видов деятельности, которая по определенной технологии преобразует входы и выходы, представляющие ценность для потребителя. ПРОЦЕСС ПРОЦЕСС ПРОЦЕСС ПРОЦЕСС ПРОЦЕСС ПРОЦЕСС ПРОЦЕСС Вход 1 Вход 2 Вход 3 Выход 1 Выход 2 Выход 3 Процесс может: получать входы только от других процессов ; передавать выходы только другим процессам. Цель: Консолидация шагов процессов и их взаимосвязей, определение и фиксация зон ответственности; Детализация действий исполнителей (в т.ч. систем); Формирование магистрального пути взаимосвязанных процессов. Точка зрения: Точка зрения аналитика БП Метод: Для вышеперечисленных целей необходимо описывать реальный поток работ ( Work Flow ) Процесс, его контекст и подход к описанию и – это информационные и материальные потоки. Входы выходы
Нотация BPMN 4 BPMN – система условных обозначений и их описания для моделирования бизнес-процессов. В 2013 году утверждена в качестве международного стандарта ISO / IEC 19510. Правило: в нашей Компании принято формировать схемы процессов всех уровней в нотации BPMN В нотации BPMN выделяют пять основных категорий элементов : элементы потока (события, процессы и шлюзы); данные (объекты данных и базы данных); соединяющие элементы (потоки управления, потоки сообщений и ассоциации); зоны ответственности (пулы и дорожки); артефакты (сноски ).
Основы графической схемы процесса 5 Пул (Pool ) – это просто рамка, внутри которой будет описан процесс Дорожки (Lane ) отображают исполнителей процесса Событие – элемент в виде кружочка Операция – четырехугольник со скругленными краями Поток управления – непрерывная стрелка Окружение процесса – все, что находится вне пула, изображаемое в виде белых прямоугольников – свернутых пулов Поток сообщений – пунктирная стрелка Правило: При создании схемы следует выбирать горизонтальную ориентацию. Шлюз – желтый ромб (оператор логики)
Базовые стартовые и конечные события 6 Правило: Если на схеме есть стартовое событие, то должно быть и конечное, и наоборот. Неопределенное событие используется при описании абстрактного процесса или декомпозиции конкретного события на нижний уровень. Стартовое c обытие -сообщение указывает на получение важной информации (в любом виде) для начала процесса. Событие-таймер указывает на наступление определенного времени для начала процесса. Событие-условие отражает исполнение некоторого условия для начала процесса. Правило: Событие необходимо именовать по формуле «глагол в прошедшем времени + существительное». Например, «Поступила задача на…», «Получен запрос…», «Счет сформирован…» Правило: Схемы процессов операционного уровня обязательно должны начинаться со стартового события. У процесса может быть несколько стартовых событий и несколько конечных событий. Но Правило: Все стартовые события должны быть связаны с одним потоком работ в рамках пула. Конечное c обытие -сообщение указывает на отправку важной информации (в любом виде) в другой процесс для его активации.
Операции и потоки управления 7 Правило : Наименование операции должно отвечать на вопрос «что сделать?» Правило : размер схемы – лист формата А4, кол-во операций 12-15. Общий критерий – схема должна нормально смотреться и легко читаться человеком с нормальным зрением при распечатке на листе формата А4. Правило : Недопустимо указывать в наименовании операции должности, подразделения и т.п. Правило (Правило двух стрелок) : У операции может быть только одна стрелка запуска и одна стрелка продолжения Правило: Входящий и исходящий поток управления допустимо изображать в любой комбинации, в зависимости от расположения на схеме Правило: все операции должны быть связаны потоком управления от стартового события до конечного
Декомпозиция процесса 8 Требуется подготовить проект документа Проект документа подготовлен Подпроцесс Правило: Стартовые и завершающие процесс события: 1) неопределенного типа; 2) контекстно поименованы. Декомпозиция – это разделение сложного объекта на части.
Базовые шлюзы 9 Эксклюзивный шлюз «Исключающее ИЛИ» (XOR ) показывает, что после выполнения операции процесс может пойти по одной из альтернативных веток (разветвление), либо приступить к выполнению операции после завершения одной из предшествующих операций (слияние). Параллельный шлюз «И» ( AND ) показывает, что две ветки процесса выполняются одновременно (разветвление) или следующая операция будет запущена после завершения обеих предыдущих операций (слияние).
Правила использования шлюзов 10 Правило: Шлюз не может объединять и разветвлять несколько потоков одновременно При необходимости описать ветвление процесса с возвратом на предыдущую операцию рекомендуется использовать «Правило двух стрелок» Логические ошибки ОК, если не нарушает логику процесса: поочередное выполнение Операции2 и Операции 3 дважды запустит Операцию 4
С обытие-обработчик Процесс ожидает наступления этого события, т.е. ожидает появления причины возникновения этого события. На диаграмме триггер внутри события, являющегося обработчиком, показывается незакрашенным. С обытие-инициатор Процесс ничего не ожидает и просто выполняется. На диаграмме триггер внутри события, являющегося инициатором, показывается закрашенным. При выполнении процесса возникает задержка до 14:00. Если операция «Подготовить отчет» не будет выполнена до 14:00 текущего дня, то таймер «14:00» отработает только на след.день. Задержка может быть обозначена как «25 числа месяца, 12:00». Наиболее часто используется динамическое назначение условий запуска события-таймера, которое определяется контекстом процесса (н-р, назначена дата встречи, и таймер установлен на эту дату). Базовые промежуточные события 11 Промежуточное событие-таймер указывает на возникновение различного рода задержек по ходу процесса. Промежуточное событие неопределенного типа можно использовать, если считаете, что они повышают информативность схемы для человека. Относительная задержка на 2 часа после выполнения операции. Событие-обработчик: процесс ожидает наступления этого события. Событие-инициатор: процесс выполняется дальше и ничего не ожидает.
Документы и потоки информации 12 Создает на выходе – если документ создается при выполнении операции Изменяет – если в рамках исполнения операции происходит изменение документа (внесение данных, корректировка, согласование, визирование, утверждение и проч. Во всех остальных случаях – «имеет на выходе» * Связь устанавливается от документа к потоку Вариант 2 * Поток документов и поток управления – НЕ одно и то же Правило: нельзя оставлять на схеме процесса «повисшие» документы, т.е. документы, которые «приходят из ниоткуда» и «уходят в никуда». Вариант 1 Вариант 3
Статусы документов 13 Использование статусов документов на схеме процесса существенно повышает ее наглядность и понятность для пользователей.
Программный продукт. Сервисная задача 14 Правило: Моделировать ПО в виде дорожек следует тогда, когда необходимо описать сложный процесс, выполняющийся преимущественно программой. Если процесс выполняется людьми, то операцию, выполняемую программой, следует выносить на дорожку исполнителя и маркировать как сервисную задачу. Правило: В сегда указывать ПО в операциях, где они используются. При добавлении Программного продукта всегда указывать тип связи. Не применять
Базы данных 15 !
Сущности CRM 16 Тип связи - используется Тип связи – создает на выходе * Нельзя оставлять на схеме процесса «повисшие» документы, но в случае с сущностями CRM можем договориться пренебречь данным правилом Тип связи единицы деятельности с информацией – создает на выходе; Тип связи информации с единицей деятельности – используется Тип связи - используется Тип связи – создает на выходе * *
Сноски Сноски – это объекты, которые можно использовать для представления рабочей информации на схеме процесса, например, для обсуждения. В готовой модели в Business Studio сносок быть не должно, так как их невозможно вывести в отчет (регламент). 17 Правило: Всю значимую информацию следует заносить в атрибуты объектов модели или элементов.
Межпроцессное взаимодействие Старт и завершение процесса событиями-сообщениями Промежуточные события отправки и получения сообщений Потоки документов между процессами Внешние ссылки 18
Старт и завершение процесса событиями-сообщениями 19 Правило: События отправки/получения сообщений всегда должны быть изображены с указанием связи с другими процессами Правило: Наименования событий в межпроцессном взаимодействии должны быть связаны по смыслу. При использовании событий отправки/получения сообщений обязательно откройте схему связанного процесса и убедитесь в том, что на ней корректно показаны соответствующие события отправки/получения сообщений.
Промежуточные события отправки сообщений 20 На этом фрагменте операция в процессе получает информацию из Процесса Б, но запускает его на выполнение. Важно понимать эту разницу. Правило: все операции должны быть связаны потоком управления от стартового события до конечного Правило: События отправки/получения сообщений всегда должны быть изображены с указанием связи с другими процессами При использовании событий отправки/получения сообщений обязательно откройте схему связанного процесса и убедитесь в том, что на ней корректно показаны соответствующие события отправки/получения сообщений.
Потоки документов между процессами 21
Внешние ссылки Правило: Внешняя ссылка используется для связи с потоками информации. Т.е. тогда, когда мы что-то получаем или передаем. Просто так связь какого-то действия с внешней ссылкой не надо показывать. 22 Правило: не описывать внешние процессы на дорожках.
Дополнительные элементы Типы задач и циклов Старт процесса несколькими событиями Сложные шлюзы Граничные события 23
Типы задач и типы циклов 24 Абстрактная задача Пользовательская задача Ручное выполнение Отправка сообщений Сервисная задача Задача-сценарий Бизнес-правило Получение сообщений Абстрактная задача Сервисная задача Бизнес-правило Задача-сценарий Пользовательская задача Получение сообщений Отправка сообщений Ручное выполнение Правило: На схемах следует применять два типа задач – абстрактную и сервисную. Стандартный цикл Многоэкземплярный последовательный цикл Многоэкземплярный параллельный цикл
Старт процесса несколькими событиями 25
Сложные шлюзы 26 Исключающее ИЛИ по событиям По смыслу тот же самый Эксклюзивный шлюз «Исключающее ИЛИ», но с привязкой к событиям Неэксклюзивный шлюз « Неисключающее ИЛИ» (OR ) показывает, что процесс может пойти либо по одной ветке, либо по нескольким, либо по всем веткам одновременно. Необходимо учитывать особенность использования парных шлюзов – «закрывающий шлюз» (правый) будет ожидать все активные потоки, запущенные «открывающим» (левым), для продолжения процесса. Комплексный шлюз показывает, что процесс может пойти либо по одной ветке, либо по нескольким, либо по всем веткам одновременно. Отличие от неэксклюзивного шлюза в возможности задавать любые необходимые варианты срабатывания шлюза на объединение. Шлюз «Исключающее ИЛИ по событиям» останавливает поток процесса до возникновения одного из событий, показанных после этого шлюза.
Граничные события 27 Прерывающее Непрерывающее Правило: использовать граничные события с пониманием Таймер
Описание сквозных процессов 28 Операция выполняется только в этом процессе Результат выполнения операции не потребляется в других процессах Операция по масштабу соответствует всем остальным операциям описываемого процесса Операция выполняется в других процессах Результат выполнения операции используется в других процессах Операция по масштабу существенно сложнее, чем операции описываемого процесса Вариант А Вариант Б Правило: избегайте процессных грыж – развернутого описания других процессов на схемах описываемых процессов.
Справочники – Деятельность, Оргединицы, Внешние ссылки 29
Справочники – Функциональные объекты 30
Прочие правила 31 Все уровни процессов чертить в BPMN (на схемах (на схемах верхнего уровня – процессные категории/процессные группы ) изображать подпроцессы без пулов, дорожек, потоков управления и прочих связей, по горизонтали ) Размер листа – А4 Кол-во операций на одном листе - не более 15 Промежуток между последовательными операциями на схемах – 1 клетка (необходимо для корректного формирования отчетов, т.к. автоматически присваивается нумерация операций ) Маршрут стрелок – самый короткий, с минимальным пересечением (должно быть продуманное расположение дорожек) Шрифт для всех элементов – по умолчанию – Arial 8пт Соблюдать единый внешний вид элементов Стараться избегать сносок, в идеале все должно быть отображено на схеме без всяких уточнений. Сноски в отчетах не отображаются. В свойствах операции указывать: Описание – краткое пояснение к операции (если оно требуется) Требования к срокам (если они есть) Программные продукты (для системных задач или задач, которые выполняются пользователем в каком-то ПО) В свойствах документа указывать: Статусы (термин ) Показ параметров элементов – настраивать одинаковый для однотипных элементов В свойствах процесса указывать: Оргединицы – В ладелец (является владельцем), И сполнитель (выполняет), С огласующий (согласовывает изменения процесса), Н аблюдатель (д/б проинформирован о внедрении/изменении процесса) – указывать подразделение-департамент Нормативно-справочные документы – Регламенты, Положения и т.п., ЗнР, Инструкции. Вести версионность схем
Организация работы по описанию процессов 32 1. Определите контекст процесса. Сформулируйте название процесса, лучше глаголом. Помните про цель описания процесса и точку зрения на процесс. Определите основные входы/выходы. Определите стартовые и завершающие события. Определите необходимых участников процесса (должности, роли). 2. Подготовьте диаграмму процесса. Создайте модель процесса в нотации BPMN. Создайте дорожки при помощи должностей (ролей). Создайте свернутые пулы для процессов, с которыми взаимодействует процесс. Если сотрудник создает по ходу процесса уникальный результат, нужный только для получения результата описываемого процесса в целом, этого сотрудника можно показать как участника процесса (должность или роль). Если результат сотрудника не уникальный, а типовой и используется в других процессах, то нужно выявить процесс, при выполнении которого создается результат, и показать этот процесс на схеме как типовой или свернутый пул. 3. Определите операции процесса. Составьте перечень операций процесса, выполняемых его участниками. Для определения операций процесса можно: а) ознакомиться с внутренними и внешними нормативно-методическими документами по процессу; б) вспомнить, что вам известно о выполнении процесса; в) провести встречи с участниками (исполнителями) и задать им вопросы, как выполняется процесс. Далее нужно показать эти операции на схеме процесса. Между ними необходимо оставить достаточно большое место для событий и операторов логики. Общее кол-во операций на схеме – не более 15. Старайтесь не детализировать операции без практической необходимости (вместо трех операций «Получить документ», «Проверить документ», «Отправить документ» делайте одну – «Проверить документ» - по входам и выходам все и так будет понятно. 4. Опишите взаимодействие между процессами. Если процесс может быть инициирован в начале или управляться по ходу выполнения другими процессами (события поступления сообщений) или запускает процессы (события отправки сообщений), то укажите эти события в соответствующей части схемы процесса. 5. Опишите логику процесса. Определите точки ветвления по ходу процесса. Добавьте на схему необходимые операторы логики (ИЛИ/И). Свяжите операции процесса, шлюзы и события между собой при помощи стрелок – потоков управления. 6. Опишите информационные потоки. Определите и покажите на схеме информационные потоки: а) внутри процесса; б) между процессами. 7. Заполните и настройте показ параметров операций процесса : требования к срокам, комментарии (описание), программные продукты 8. Визуально отредактируйте схему. Отредактируйте схему так, чтобы она была понятной с первого взгляда, наглядной и красивой. Схема должна легко читаться человеком с нормальным зрением при распечатке в формате А4. 9. Заполните параметры процесса. Определите и заполните владельца и участников процесса, а также нормативно-справочные документы в свойствах элемента. 10. Проверьте схему процесса по чек-листу. Выполните проверку схемы по чек-листу. Внесите изменения в схему и перейдите на шаг 7.
Формальный анализ качества схемы (чек-лист) Дополнительно проверить корректность построения схемы можно через Отчет в Business Studio «Проверка правильности построения диаграммы BPMN » 33 № Наименование требования Комментарий Кол-во 1 Корректность формулировок названий объектов на схеме 2 Корректность описания входов/выходов 3 Корректность описания событий 4 Логические ошибки 5 Физическая нереализуемость 6 Возвраты в прошлое 7 Не учтена необходимость обработки нескольких объектов 8 Наличие «процессной грыжи» 9 Однородность масштаба операций 10 Показ параметров 11 Наличие матрицы ролей и ВНД 12 Аккуратность исполнения схемы. Визуальная наглядность Всего несоответствий:
Содержательный анализ схемы процесса 34 № Наименование Комментарий 1 Операции, создающие ценность Проверяется наличие на схеме процесса операций, добавляющих ценность (для клиента и/или организации) 2 Операции, не создающие ценность Проверяется наличие на схеме процесса операций, не добавляющих ценность («муда») 3 Передача результата потребителю Проверяется, завершается ли процесс передачей результата следующему процессу (потребителю) 4 Возвраты Выявляются возвраты и определяются их причины. Если возврат технологический, то это допустимо. Остальные возвраты всегда являются признаками неэффективно выполняемого процесса 5 Дублирование операций Проверяется прямое, либо косвенное дублирование работы (может быть выявлено по дублированию результатов выполняемых операций) 6 Чрезмерный контроль Проверяется целесообразность операций контроля, в т.ч. Сверки, согласования, утверждения и т.п. 7 Узкие места Проверяется наличие узких мест (в первую очередь по ресурсам) 8 Автоматизация Проверяется наличие автоматизированных операций процесса, выявляются факты передачи данных из одной информационной системы в другую (и связанные с этим проблемы) 9 Роботизация Проверяется наличие роботизированных операций. Выявляется возможность роботизации операций
Заключение Главный критерий качественной схемы – чтобы тем сотрудникам, которые будут читать схемы, было все понятно без дополнительных вопросов! Сохраните для себя шпаргалку с основными правилами (будет позже) И как можно чаще сохраняйтесь при моделировании схем ;) 35
