Моделирование бизнес-процессов в нотации BPMN. Пособие для начинающих. Часть I Текст

Читать фрагмент
Как читать книгу после покупки
Шрифт:Меньше АаБольше Аа

© Владимир Репин, 2019

ISBN 978-5-4496-6989-6 (т. 1)

ISBN 978-5-4496-6990-2

Создано в интеллектуальной издательской системе Ridero

1. Введение. Что такое нотация BPMN?

1.1. Нотация BPMN

Вы держите перед собой книгу – краткое методическое пособие по освоению нотации BPMN для целей практического описания и анализа бизнес-процессов компании.

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

Книга не предназначена для повышения квалификации профессионалов в области моделирования и автоматизации бизнес-процессов. Для практиков, имеющих большой опыт автоматизации процессов, или теоретиков BPMN предлагаемые подходы к изложению темы могут показаться чрезмерно упрощенными. Но хочу еще раз подчеркнуть, что целевая аудитория книги – сотрудники, которые только что приступили к изучению методов моделирования процессов.

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

BPMN (Business Process Model and Notation – нотация и модель бизнес-процессов) разработана компанией Business Process Management Initiative и поддерживается Object Management Group после слияния организаций в 2005 г. Последняя версия 2.0 вышла в 2012 г. В 20013 году BPMN утверждена в качестве международного стандарта ISO/IEC 19510.

В настоящее время большинство компаний, поставляющих системы автоматизации бизнес-процессов – BPMS, используют нотацию BPMN для проектирования исполняемых процессов.

Фактически, BPMN сегодня – это лучшая, признанная на международном уровне и активно используемая многими компаниями нотация. Но она, как любая другая нотация, имеет ограничения применимости. Например, для формирования архитектуры процессов компании (т.н. модели верхнего уровня) лучше использовать нотацию IDEF0.

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

Рекомендую последовательно выполнять все задания без исключения, даже если что-то уже покажется вам знакомым и слишком простым. Для выполнения заданий можно использовать MS Visio, Business Studio, Bizagi BPM Modeler или любую другую программу, которая поддерживает создание графических схем в нотации BPMN.

В конце книги вы сможете найти ссылки на дополнительные материалы для более глубокого освоения темы моделирования и процессного управления в целом.

Схемы процессов для книги подготовлены в среде моделирования Business Studio 4. Вид некоторых графических объектов может слегка отличаться от используемых в других программах, поддерживающих моделирование в нотации BPMN.

1.2. Процесс и его контекст

Обратите внимание на определение процесса (бизнес-процесса):

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

Входы и выходы – это информационные и материальные потоки.

Прежде чем описывать процесс в виде графической схемы, очень важно определить его контекст – см. рис. 1.

Рис. 1. Правильный контекст процесса.


Рис.2. Неправильный контекст процесса.


Запомните принцип: процесс может:

• получать входы от других процессов;

• передавать выходы другим процессам.


Процесс НЕ может:

• получать входы от отделов, сотрудников, физических лиц и прочих сущностей, кроме процессов;

• передавать выходы другим отделам, сотрудникам, физическим лицам и прочим сущностям, кроме процессов.


Почему это так? Процесс – это не сферический конь в вакууме. Он существует среди других процессов в общей архитектуре процессов организации. Если вы будете рисовать на схеме взаимодействие процесса с «Ивановым» или «Отделом закупки», то вместо системы взаимодействующих процессов получите управленческий винегрет.

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

Будет здорово, если вы также выявите управляющие воздействия (планы, приказы, распоряжения) и нормативные требования к процессу (ГОСТы, регламенты, положения и т.п.). Это важно для анализа контекста. Но управляющие воздействия не всегда целесообразно показывать на схеме процесса.

Затем нужно указать состав участников процесса, но об этом несколько позже.

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

События отличаются от входов/выходов. Они определяют условия запуска (продолжения, завершения) процесса.

Если начать описание процесса без определения его контекста, границ и событий, то с вероятностью 99% вы нарисуете не то, что нужно. Работу придется переделывать несколько раз.

1.3. Цель, точка зрения и метод

Перед тем как описывать процесс, важно определиться с тремя вопросами:

• цель;

• точка зрения;

• метод.


Определите цель. Для чего вам нужно описание процесса? Если читателями процесса будут только люди, то схема может быть простой, построенной с использованием минимального количество графических элементов.

Если вы планируете описать только функции, которые выполняются в какой-то информационной системе (например, документооборот), – это одно. Если цель – получить, проанализировать и использовать для регламентации схему реального бизнес-процесса со всеми его особенностями – это другое. Можно описать процесс широкими мазками для общего представления, а можно детально, с учетом всех нюансов.


Пример укрупненного представления процесса открытия депозита в банке:

1. прийти в банк;

2. открыть депозит;

3. уйти из банка.


Достаточно ли такого описания для решения практических задач? Смотря каких…

Определите точку зрения (как правило, – это точка зрения бизнес-заказчика модели). Ее выбор существенно повлияет на результат. Приведу пример. Как будет выглядеть процесс открытия банковского депозита в банке?


С точки зрения клиента последовательность такая:

• прийти в банк;

• получить талончик в электронной очереди;

• дождаться своей очереди (увы, операция ожидания – это тоже часть процесса);

• объяснить пожелания сотруднику банка, передать паспорт;

• подписать договор;

• перейти в кассу и внести деньги;

• получить квитанцию о внесении средств;

• покинуть банк.


Тот же процесс с точки зрения сотрудника банка (операциониста):

• выяснить потребность клиента;

• проверить паспорт;

• оформить договор и сберкнижку;

• оформить депозит в системе;

• выдать бирку на внесение денег в кассе, передать документы кассиру.


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

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

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

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

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

Нужна помощь
Купите 3 книги одновременно и выберите четвёртую в подарок!

Чтобы воспользоваться акцией, добавьте нужные книги в корзину. Сделать это можно на странице каждой книги, либо в общем списке:

  1. Нажмите на многоточие
    рядом с книгой
  2. Выберите пункт
    «Добавить в корзину»