Методологии моделирования бизнес-процессов

ЛЕКЦИЯ «Методологии моделирования бизнес-процессов» Вопросы лекции 1. Обзор нотаций. 2. Нотация BPMN. Базовые элементы. 3. Нотация BPMN. Базовые правила моделирования. 4. Схема бизнес-процесса. 1. Обзор нотаций СЛАЙД 3 Моделирование бизнес-процессов стало классической работой множества бизнес-аналитиков в рамках оптимизации бизнес-процессов и стандартизации деятельности российских компаний. Существует множество нотаций, которые применяются в тех или иных случаях. Рассмотрим перечень основных нотаций, сформированный директором по оптимизации бизнес-процессов Московского финансово-промышленного университета «Синергия» Андреем Коптеловым. СЛАЙД 4 Моделирование бизнес-процессов — VAD (value added chain diagram) Нотация VAD, предложенная Майклом Портером (Michael Porter) в его работах по корпоративной стратегии, концентрируется на моделировании бизнес-процессов, «создающих ценность» в виде услуг или продукции для потребителя. Модель бизнес-процесса, построенная в нотации VAD, дает общий, не детализированный взгляд на бизнес-процессы. С помощью нотации VAD, можно описать перечень и взаимосвязь бизнес-процессов на верхнем уровне, так как данная нотация позволяет отобразить все бизнес-процессы компании на одной модели. В нотации VAD можно использовать связи, показывающие взаимосвязь бизнес-процессов относительно друг друга, при этом поток процесса в этой нотации в подавляющем большинстве случаев направлен слева направо (см. рис. 1). СЛАЙД 5 Рисунок 1 – Нотация VAD Вариантов нотации VAD реализовано в различных инструментах немало, и каждый со своим набором символов, но выглядят они все примерно одинаково – набор бизнес-процессов, часто связанных между собой связями «предшественник-последователь». Например, расширение данной нотации в инструментарии ARIS позволяет показать на модели бизнес-процесса исполнителей, риски, документы, данные и многое-многое другое. Помимо моделирования карты бизнес-процессов организации, нотация VAD позволяет моделировать сквозные (End-to-End) бизнес-процессы при их первичном определении. Но нужно понимать, что VAD не предназначена для моделирования логических условий в процессе, и поэтому она отлично воспринимается менеджментом. На практике, после моделирования бизнес-процессов на верхнем уровне в нотации VAD, следует более подробное моделирование бизнес-процессов в других нотациях, которые мы подробно рассмотрим далее. Модель нотации VAD можно нарисовать во множестве инструментов, например, в MS Visio,  ARIS,  Archi  и многих других инструментах моделирования бизнес-процессов. Моделирование бизнес-процессов – EPC (event-driven process chain) СЛАЙД 6 Нотация EPC разработана профессором Августом Вильгельмом Шеером в рамках методологии инструментария ARIS (методология и тиражируемый программный продукт для моделирования бизнес-процессов организаций). С помощью нотации EPC бизнес-процесс моделируется в виде перечня шагов процесса, запускаемых событиями (рис. 2). Нотация удобна для последующей регламентации бизнес-процесса, а также для анализа информационного потока бизнес-процесса (входящих/исходящих документов). Свобода нотации EPC позволяет описывать в рамках моделирования бизнес-процессов дополнительные объекты, такие как операционные риски, контрольные процедуры, экранные формы, информационные системы, показатели и многое другое. СЛАЙД 7 В рамках нотации EPC процесс моделируется «сверху-вниз», а порядок выполнения шагов/функций/действий/операций бизнес-процесса определяется через систему событий и логических условий. В качестве событий в нотации EPC рассматривается начало и завершение шагов процесса, а также внешние события требующие реакции от организации. Модель бизнес-процесса состоит из последовательностей «событие-функция-событие» и логических операторов «И», «ИЛИ», «исключающее ИЛИ» которые отображают решения, проверку условий, распараллеливание и схождение потоков моделируемого бизнес-процесса. Существует множество вариантов нотации EPC, в формате столбцов, строк, а также с разными перечнями используемых объектов, однако все эти варианты доступны только в инструментарии ARIS, тогда как в остальных инструментах, например, MS Visio или Business Studio доступно моделирование бизнес-процессов EPC лишь в классическом формате. Моделирование бизнес-процесса в нотации EPC позволяет впоследствии получить текстовый или табличный регламент бизнес-процессов, так как правильно нарисованная EPC модель может быть преобразована в последовательность предложений обычного языка, что становится основой для регламента. Именно поэтому данная нотация считается самой удобной для моделирования бизнес-процессов с целью их последующего анализа и регламентации. Рисунок 2 - Нотация EPC Моделирование бизнес-процессов – BPMN (Business Process Model and Notation 2.0) СЛАЙД 8 Нотация BPMN создана консорциумом Object Management Group (OMG) и предназначена для моделирования бизнес-процессов с целью их последующей автоматизации. Нотация BPMN используется для детального моделирования бизнес-процесса, а количество объектов в данной нотации превышает 100, что позволяет описать все нюансы поведения бизнес-процессов для того, чтобы информационная система могла преобразовать созданную модель в исполняемый код. Открытость нотации BPMN и поддержка большинством средств моделирования и автоматизации бизнес-процессов сделали данную нотацию лидером в моделировании бизнес-процессов (рис. 3). В нотации BPMN, помимо шагов бизнес-процесса, можно моделировать стартовые, промежуточные и завершающие события процесса, информационные потоки и потоки сообщений. Из особенностей нотации можно выделить применение по умолчанию стиля моделирования Swim Lane (плавательные дорожки), когда исполнитель показывается вертикальной или горизонтальной полосой, напоминающей дорожки в плавательном бассейне, и именно на этой дорожке располагаются действия/операции, выполняемые данным исполнителем. СЛАЙД 9 Рисунок 3 - Нотация BPMN Упорядочивание бизнес-процесса в формате Swim Lane делает наглядной передачу ответственности и потока работ между участниками процесса, но, в тоже время, затрудняет моделирование в случае нескольких соисполнителей у одной операции. Модели, нарисованные в нотации BPMN, часто сложно собрать в связанную иерархию, так как методология изначально создавалась для автоматизации «сквозных» бизнес-процессов. Для применения нотации BPMN необходим определенный опыт, что часто ограничивает число создателей данных моделей лишь системными и бизнес-аналитиками. Представители бизнес-подразделений моделируют бизнес-процессы в нотации BPMN достаточно редко. Несмотря на графические различия нотации BPMN и EPC очень похожи друг на друга, и в инструментарии ARIS они уже могут быть преобразованы друг в друга, правда с определенными методологическими ограничениями. Моделирование бизнес-процессов — Flow Charting СЛАЙД 10 Название нотации Flow Charting, проще всего перевести как блок-схемы. Данная нотация изначально появилась в стандарте ANSI в 1970 году, и содержит очень простой набор символов. За годы существования нотации Flow Charting было нарисовано множество вариантов блок-схем, содержащих символы для решения разных задач, например, для описания материальных потоков, ролей и работ, оборудования, для анализа входов и выходов функций. Фактически блок-схемы явились предшественниками современных нотаций моделирования бизнес-процессов, и вплоть до настоящего времени преподавались в большинстве учебных заведений в рамках дисциплин, посвящённых информационным технологиям. Нотация Flow Charting не имеет жесткого стандарта, что позволяет моделировать бизнес-процессы с различных точек зрения, добавляя те или иные объекты в модель по необходимости. Этим данная нотация очень похожа на EPC, но имеет еще больше свободы в части применения. Свобода вариантов применения Flow Charting и поддержка большинством недорогих и даже бесплатных средств моделирования бизнес-процессов сделало данную нотацию применимой во множестве компаний. Из недостатков Flow Charting можно выделить отсутствие типового перечня объектов и атрибутов, что является обратной стороной «свободы» данной нотации. Это позволяет моделировать один и тот же бизнес-процесс в данной нотации так, что модели будут серьёзно отличаться друг от друга. Несмотря на то, что модели бизнес-процессов в нотации Flow Charting можно встретить достаточно часто, скорее всего она будет уходить в прошлое, уступая место более «строгим нотациям» Моделирование бизнес-процессов  – IDEF (Integrated Definition Language) СЛАЙД 11 Нотация IDEF появилась в 70-ых годах, как стандарт правительства США, фокусирующий внимание на входах, выходах, механизмах и средствах управления бизнес-процессом и увязывающий процессы организации в иерархию. Ключевым элементом данной нотации является функция, тогда как все остальные объекты и взаимодействия моделируются с помощью связей. Нотация использует очень простой набор символов: прямоугольники процессов и стрелки, изображающие входы, выходы, управление и механизмы, эту нотацию отличает «встроенная» система нумерации шагов бизнес-процесса, что позволяет отслеживать связи между родительским и дочерними процессами. Более подробно мы ее рассматривали в предыдущих лекциях. Учитывая историю данного стандарта и достаточно широкое применение он реализован во многих средствах моделирования, но все же данную нотацию можно отнести к уходящему поколению, так как сторонников у нее все меньше, да и представители бизнеса часто относятся к данным «микросхемам» со скепсисом. Моделирование бизнес-процессов UML (Unified Modeling Languages) СЛАЙД 12 Унифицированный язык моделирования (UML) – это набор нотаций и методов моделирования, предназначенных для описания требований к информационным системам, однако среди нотаций UML есть и специализированная нотация, предназначенная именно для моделирования бизнес-процессов.  UML поддерживается Object Management Group (OMG), что сделало данную методологию достаточно распространенной среди ИТ-специалистов. Данная нотация очень похожа на EPC и BPMN, единственное отличие в отображении логических операторов и событий, и, хотя по нотации UML существует множество книг, и поддержана она множеством инструментов моделирования, используется UML Activiti Diagram в основном для системного анализа и проектирования, и лишь незначительное число компаний используют UML, чтобы моделировать бизнес-процессы. Моделирование бизнес-процессов – VSM (Value Stream Mapping) СЛАЙД 13 Название нотации VSM можно перевести на русский язык, как картирование потока создания потребительской ценности. Оригинальное название этой нотации в корпорации Тойота, где как считается, ее и придумали — Карта потоков материалов и информации. Нотация VSM была разработана как часть методологии бережливого производства, и использует набор специфических символов для отображения элементов затрат ресурсов и времени для анализа эффективности бизнес-процесса в проектах Lean 6Sigma. Lean Six Sigma — интегрированный метод продуктовой разработки и менеджмента, который комбинирует фокусировку на бережливость и скорость (Lean), а также на непрерывное повышение качества продукта и удовлетворенности клиента (Six Sigma). Карта потока создания ценности изображает физическое окружение и потоки материалов и продукции в производстве и используется для того, чтобы привязать к процессу затраты ресурсов и времени, и таким образом дать представление о производительности Задача данной нотации вовлечь в анализ бизнес-процесса его участников для того, чтобы стимулировать их к самостоятельному поиску возможностей оптимизации. Как правило модели VSM рисуются в проектах на Flip Chart и не требуют серьёзных средств моделирования бизнес-процессов, ведь на ее основании принимаются решения, а сама модель не становится основой ни для регламента, ни для ИТ-решения. Основное при создании модели в нотации VSM это заполнение временных атрибутов по процессу, для поиска «бутылочных горлышек» и мест излишнего хранения запасов. Данная нотация имеет ограниченный круг последователей, и среди широких масс бизнес-аналитиков она в ближайшее время распространена не будет из-за специфичности решаемых с ее помощью задач. Но в тоже время многие инструменты моделирования бизнес-процессов, например, ARIS, уже разработали расширения для поддержки моделирования бизнес-процессов в данной нотации. Моделирование бизнес-процессов – SIPOC СЛАЙД 14 Аббревиатура SIPOC означает: Supplier (поставщик), Input (вход), Process (процесс), Output (выход), Customer (потребитель). Это шаблон документирования процессов, принятый в методологии Шесть сигм, фактически это даже не нотация модели, а формат таблицы, который позволяет описать бизнес-процесс на верхнем уровне. Модель SIPOC наиболее эффективно применять при определении границ бизнес-процесса, взаимодействующих сторон и входов/выходов процесса. Для SIPOC не существует нотации, ведь это простая таблица с соответствующими заголовками, которая позволяет структурировать выбранной бизнес-процесс для последующего анализа и оптимизации. Полезность SIPOC, в отличии от других диаграмм заключается в возможности ее использования сотрудниками бизнес-подразделений, так как она не содержит сложной логики и множества объектов, как нотации EPC или BPMN. Итак, мы рассмотрели перечень нотаций моделирования бизнес-процессов, которые можно встретить на российском рынке, составленный директором по оптимизации бизнес-процессов Московского финансово-промышленного университета «Синергия» Андреем Коптеловым. СЛАЙД 15 Какую из нотаций выбрать для использования – это вопрос открытый, например, для моделирования бизнес-процессов организации на верхнем уровне используют нотацию VAD, для первичного моделирования бизнес-процесса, выбранного для оптимизации, проще использовать SIPOC или VAD. Для создания детальных моделей бизнес-процессов – упрощённый BPMN для моделирования кросс-функционального взаимодействия или EPC для детального моделирования с целью формализовать информационный поток и множество объектов, связанных с бизнес-процессом. Ну а если необходимо автоматизировать бизнес-процесс в BPMS системе (программное обеспечение для управления бизнес-процессами), то тут уже не обойтись без нотации BPMN. 2.Нотация BPMN. Базовые элементы СЛАЙД 16 Нотация BPMN — лучший язык моделирования бизнес-процессов (рис. 4). Эта нотация стала результатом анализа всего опыта моделирования и других нотаций за всю историю. Компания «Организация эффективного управления» [2] разместила на своем сайте информацию о ее применении, рассмотрим ее далее. Материал подготовлен Романом Зайцевым - партнером международной консалтинговой компании SCM Consult, экспертом в области управления бизнес-процессами, управления изменениями, повышения операционной эффективности и оптимизации бизнес-процессов. Рисунок 4 – BPMN 2.0 BPMN не только собрала в себе все лучшее от других нотаций, но и создала нечто совершенно новое. Моделирование бизнес-процессов начинается с нотации. А нотация начинается с изучения ее элементов. Элементы нотации выглядят одинаково во всех программах. Отличаться может только цвет заливки фигур. Но сами фигуры, толщина и форма линий – универсальна. Так что вы не перепутаете событие начала и окончания – вне зависимости от программы моделирования. Кстати, в самой нотации все графические элементы приведены в черно-белом формате. Базовые элементы. Нотация BPMN 2.0 СЛАЙД 17 Пул Пул символизирует собой сотрудника, выполняющего определенную роль в процессе. Если вы хотите показать, что цепочка операций выполняется конкретной ролью, поместите эти операции в пул. Такое представление позволяет очень наглядно отобразить взаимодействие между ролями, сотрудниками в процессе. СЛАЙД 18 Пул — это зона ответственности роли. Почему роли? Логика очень проста — каждый сотрудник выполняет несколько ролей. Совокупность ролей это должность. Каждая роль требует определенных знаний и навыков. Так что если вы определите роли в процессах и определите, из каких ролей складывается та или иная должность, то сможете с легкостью сформировать должностные инструкции. Операции в пуле СЛАЙД 19 А еще с помощью пула можно отображать программное обеспечение или какой-то инструмент. Например, станок. Такой взгляд на бизнес-процесс порой необходим. Например, вы можете отобразить взаимодействие пользователя и программы. Только нотация BPMN имеет пулы. По мнению Романа Зайцева, это очень серьезное преимущество перед другими нотациями. Операция Операция (задача, активность, действие) – это один из основополагающих элементов модели. Операция – это элементарное действие, которое необходимо выполнить. Элементарное — значит не требующее детализации, декомпозиции на данном уровне, в данной модели. СЛАЙД 20 Процесс / подпроцесс Если операция включает в себя ряд действий, которые вы хотите описать, то она становится процессом. СЛАЙД 21 Процесс или подпроцесс – это тоже действие, но его можно раскрыть и посмотреть, что там происходит внутри. Декомпозиция процесса СЛАЙД 22 Событие Событие — еще один основополагающий элемент модели бизнес-процесса. События определяют ход выполнения процесса. События – это то, что просто произошло. Это обстоятельство, условие, исходя из которого мы действуем дальше. События – это условие «если» в цепочке «если – то». Если на улице идет дождь, то нам надо взять зонт. Дождь — это событие, условие, которое определяет последующие действия в процессе. События могут быть разными: • Событие времени — истечение какого-то времени (через час) или дата/время (в 10:00) • События состояния — идет дождь, позвонил друг, упал курс доллара и т.д. • Событие сообщение — например, пришло письмо. • и т.д. Подробнее о типах событий будет написано дальше. СЛАЙД 23 Дата контакта с клиентом – пример промежуточного события События делятся на 3 типа: события начала определяют условия старта процесса, промежуточные события определяют развитие процесса и событие окончания, отражает условие, при котором мы считаем, что процесс окончен. Моделирование бизнес-процессов начинается с определения стартовых и финишных событий. Во многих нотациях существуют события. Но только нотация BPMN сделала их конкретными. СЛАЙД 24 Ветвление Ветвление, или шлюз – это логическая развилка в процессе. Если стоит развилка, значит, процесс может развиваться по-разному – в зависимости от условий. Самая простая развилка дает 2 варианта развития событий. Например, развилка «на улице идет дождь?» имеет два варианта ответа – да или нет. Соответственно от ответа, то есть от условия, зависят дальнейшие действия в процессе. В более сложных вариантах из развилки может исходить множество вариантов с событиями, которые и определяют направление процесса. А еще ветвления «собирают» в себя условия, когда они все должны быть выполнены – для перехода к следующей операции процесса. СЛАЙД 25 Поток операций Стрелка как раз соединяет операции и процессы и показывает порядок выполнения действий в процессе. Помимо порядка выполнения стрелка может также обозначать результат предыдущего процесса, который используется в следующем. Для этого необходимо сделать подпись к стрелке. Поток сообщений Поток сообщений отображает обмен информацией между участниками (пулами). Дело в том, что операции участников не могут быть соединены между собой потоком операций. Что в принципе логично. Вместо этого они обмениваются сообщениями. Так что если вы хотите показать, что процесс переходит от одного участника к другому, то соедините операции потоком сообщений. СЛАЙД 26 Чтобы конкретизировать сообщение, можно сделать подпись к стрелке. Подробнее рассмотрим дальше. Потоки сообщений Объект данных СЛАЙД 27 Объект данных – это информация, которую необходимо отобразить в процессе. Это может быть или документ, или письмо, или звонок. Кстати, с точки зрения управления бизнес-процессами любая информация в материальном виде является документом — запрос, электронное письмо, сообщение, бумажный документ и т.д. При соединении объекта данных с операцией необходимо учитывать направление стрелки. Если стрелка идет от данных к операции, значит, эти данные используются для выполнения операции. Если стрелка идет от операции к объекту данных, значит, данные появляются в результате выполнения операции. Моделирование бизнес-процессов без объектов данных не имеет особого смысла. СЛАЙД 28 Ассоциация Этот тип соединения используется для отображения взаимосвязи информационных объектов и баз данных с операциями. В таком случае стрелка ассоциации будет иметь направление. Если же порядок считывания/записи данных не имеет значения, можно установить ассоциацию без направления. Такое соединение используется для соединения текстовой нотации с другими элементами. Или, например, можно отобразить взаимосвязь события и документа. Завершающее событие процесса «Отчет сформирован», может быть соединено ассоциацией с документом «Отчет». СЛАЙД 29 План холодных звонков. Появляется в результате одного процесса и используется в другом. Вспомогательные базовые элементы. Нотация BPMN 2.0 СЛАЙД 30 Дорожка Дорожки существуют внутри пулов. С помощью дорожки удобно отображать несколько ролей, допустим, в рамках отдела. В таком случае пул будет являться отделом, а дорожка отображать сотрудников. Между операциями в дорожках может существовать поток операций, что тоже соответствует действительности. Например, дорожки могут отражать станки, на которых выполняются операции и переходы заготовок от одного станка к другому. СЛАЙД 31 База данных База данных, или хранилище данных – это место, где находятся данные. Это может быть электронная база данных, программа, папка на жестком диске, бумажная папка, шкаф, где хранятся документы… Так же, как и с объектом данных, направление стрелки, соединяющей базу данных с операцией, имеет значение. От БД к операции – операция использует базу для получения данных. От операции к БД – операция помещает данные в базу. Группа Это просто визуальная группировка элементов бизнес-процесса. Например, может использоваться для отображения этапов бизнес-процесса. Текстовая аннотация Текстовое сопровождение любого элемента модели бизнес-процесса. С помощью аннотации можно добавлять необходимую информацию непосредственно в модель процесса. Иногда позволяет полностью избавиться от текстового сопровождения модели в описании бизнес-процесса. С базовыми элементами закончили, однако, нужно понимать, что нотация BPMN намного глубже. 3. Нотация BPMN. Базовые правила моделирования. СЛАЙД 32 Правила моделирования процессов в нотации BPMN не так уж сложны и в основном базируются на логике и простоте восприятия. Правила существуют для того, чтобы избежать разночтений в моделях бизнес-процессов и упростить понимание и моделирование. Ниже приведены основные правила и рекомендации по моделированию процессов BPMN. Начнем с базовых правил нотации BPMN: • Потоки работ используются для отображения порядка выполнения процессов и операций. Они не могут пересекать границы подпроцессов и не могут выходить за границы пулов. • Потоки сообщений используются для отображения коммуникаций между участниками процесса. Они не могут соединять объекты внутри одного пула. • События на границах процессов или операций должны иметь как минимум один исходящий поток работ, а еще они не могут иметь входящих потоков. • Стартовое событие в подпроцессе не должно иметь конкретного типа. BPMN Уточнения СЛАЙД 33 Несколько пояснений к классическим заблуждениям относительно BPMN: • В нотации BPMN понятие Процесса, Модели, Диаграммы и Файла не является эквивалентным. Модель BPMN может содержать несколько процессов. Разные части Модели BPMN могут быть сохранены в разных файлах. Диаграмма BPMN может изображать целый набор Моделей бизнес-процессов. Модель BPMN может быть изображена с использованием нескольких диаграмм. • Диаграмма BPMN не является диаграммой потоков данных. И хотя объекты данных являются одним из основных элементов нотации BPMN, не рекомендуется пытаться моделировать информационные потоки сами по себе с помощью BPMN. • Шлюзы – это не принятие решения. Сами по себе шлюзы не принимают решения, они лишь отображают направление и условия развития процесса. • Принятие решения должно отображаться в виде операции, предшествующей шлюзу. • Используйте Ручную операцию для того, чтобы отобразить полностью ручное выполнение операции, без использования какого-либо программного обеспечения. • Используйте Пользовательскую операцию, чтобы отобразить полуавтоматические выполнения работы. В такой задаче пользователь выполняет операцию с помощью ПО. • Автоматическая задача выполняется без участия пользователя. Рекомендации по наименованию объектов в нотации BPMN   СЛАЙД 34 В нотации BPMN нет конкретных правил наименования объектов, но все же рекомендуется придерживаться принятых негласных правил. • Используйте ключевые слова, которые отражают суть и имеют отношение к вашему бизнесу. Не используйте непонятные, нераспространенные аббревиатуры.  Не используйте наименование самого элемента в нем.  Проверяйте грамматику. • Все операции, события и объекты данных должны иметь наименование. • Называйте процессы и операции так, будто это приказ. “Подготовить отчет” вместо “Подготовка отчета”. Используйте полное наименование, избегайте сокращений. • Не используйте одинаковые названия для операций (кроме Операций вызова). • Шлюзы не выполняют какую-либо работу и не принимают решения. Это просто визуализация объединения или ветвления потоков.  Нет необходимости называть объединяющие шлюзы.  Можно давать текстовые аннотации к объединяющим шлюзам, когда они логически не очевидны. • Шлюзы ветвления лучше называть вопросительными фразами. • Лучше всего называть исходящие из шлюзов потоки операций в согласованности с теми операциями или событиями, в которые они входят. Например, поток “Время подготовки отчета”, операция “Подготовить отчет” • Условные потоки операций нужно обязательно называть в соответствии и с условиями их возникновения. • Давать названия потоку работ по умолчанию не нужно. • События, имеющие пару, например события Сообщения, Связи, Сигнала, Эскалации и Ошибки необходимо называть одинаково. Т.е., если в одном процессе у вас есть событие “Сигнал пожарной охраны”, то в другом процессе, который запускается по данному событию, оно должно называться также. • Называйте события Состояния так, чтобы было понятно, какое состояние оно отображает. • Состояние одного и того же объекта данных необходимо указывать в квадратных скобках в самом названии объекта. Например, Договор [подписанный]. • Название пула должно соответствовать названию роли участника процесса, т.к. в BPMN пул и есть роль участника. Не называйте пулы названием процесса. • Для названия дорожек используйте наименование категории. Зачастую дорожки используют для наименования ролей одного участника. Правила моделирования процессов СЛАЙД 35 • Четко определяйте границы бизнес-процесса. Для этого необходимо дать ответы на вопросы: Кто, Как, Когда, Где и Зачем делает в процессе. Помните, процесс отвечает на вопрос “Как?”. • Разные способы начать процессы отражаются через стартовые события. Разные способы завершения процесса отображаются через события окончания. • Старайтесь составлять схемы таким образом, чтобы они помещались на одном печатном листе. • Аккуратно располагайте элементы диаграммы. Избегайте всего, что может помешать точному восприятию. Например, избегайте пересечения линий потоков. • Располагайте потоки работ горизонтально, а информационные и потоки сообщений вертикально. • В BPMN нет конкретного направления порядка выполнения процесса, но обычно процесс развивается слева направо. Не располагайте элементы так, чтобы поток шел зигзагообразно. • Основной вариант развития процесса (поток по умолчанию) должен быть центральной осью процесса. • Когда это возможно, преобразовывайте участки процесса в бизнес-правила. Использование операций типа Бизнес-правило позволяет сделать диаграмму лаконичной и гибкой. • Создавайте разные варианты диаграммы одного процесса, если нужно демонстрировать ее разному уровню заинтересованных лиц. Например: • Диаграмма верхнего уровня отражает только свернутые процессы и операции вызова и не содержит объектов данных – для Владельца процесса. • Подробная карта процессов с развернутыми подпроцессами и операциями вызова содержит все объекты данных и текстовые аннотации – для Исполнителей процесса. • Используйте подпроцессы для разделения процесса на этапы. • Используйте Операции вызова для повторного использования других процессов. • В каждом процессе должно быть как минимум одно событие начала и окончания. Отмечайте альтернативные пути начала и окончания процесса с помощью соответствующих событий. • Потоки процесса, приводящие к одному и тому же результату, должны быть объединены одним событием окончания. • Всегда используйте шлюзы для иллюстрации разделения или объединения потоков процесса. • Не используйте один шлюз для объединения и разделения потоков процесса одновременно. • Всегда располагайте операцию, которая будет определять условия ветвления потока, перед шлюзами типа Включающий, Исключающий и Комплексный. • Пытайтесь сворачивать разветвленные исходящие шлюзы в бизнес-правила. Это позволяет разгрузить внешний вид диаграмм. • Если процесс на диаграмме выполняется одной ролью, то не надо помещать операции процесса в пул. Не на данном уровне. 1. Схема бизнес-процесса СЛАЙД 36 Схема бизнес-процесса отражает его суть и механизм работы (рис. 5). Создать схему само по себе не очень сложно. Достаточно понимать, на какие вопросы должна отвечать схема, а далее придерживаться алгоритма создания. Рассмотрим пример формирования схемы бизнес-процесса Романа Зайцева. Рисунок 5 – Пример схемы бизнес-процесса Необходимо напомнить, что до начала описания бизнес процессов необходимо установить их границы. Список всех бизнес процессов компании – платформа, с которой необходимо начинать. Алгоритм, который здесь приводится, будет полезен тем, кто только собирается описывать бизнес-процессы. Схема бизнес-процесса СЛАЙД 37 1 – Задайте границы процесса Каждый бизнес-процесс начинается и заканчивается с события. Первое, что необходимо сделать – обозначить события начала и окончания (рис. 6). Рисунок 6 – Границы бизнес-процесса 2 – Нарисуйте основные блоки процесса СЛАЙД 38 Расположите основные блоки (подпроцессы, операции) бизнес-процесса в том порядке, в котором они выполняются (рис. 7). Рисунок 7 – Основные блоки Не усложняйте схему на данном этапе. Отобразите блоки так, будто процесс выполняется идеально. 3 – Добавьте развилки и другие события СЛАЙД 39 А вот теперь пора немного усложнить. Добавьте основные варианты развития процесса и основные промежуточные события (рис. 8). Дополните схему недостающими операциями. Рисунок 8 – Развилки и другие события 4 – Обозначьте роли участников процесса СЛАЙД 40 В бизнес-процессах нет должностей или конкретных сотрудников. Вместо этого используется понятие “роль”. Один сотрудник может выполнять множество ролей. Одну роль может выполнять множество сотрудников. Из набора ролей складывается должность (рис. 9). Рисунок 9 – Роли участников процесса По необходимости добавляйте недостающие операции. 5 – Разместите на схеме документы СЛАЙД 41 Документ – это не обязательно официальная бумага с семью подписями. С точки зрения управления бизнес-процессами документ – это информация на любом информационном носителе. Электронное письмо, доклад, презентация, сообщение – все это документы (рис. 10). Иногда необходимо отобразить промежуточные продукты. Это заготовки, полуфабрикаты или просто важные части работы, которые переходят из одного блока процесса в другой. Добавьте их на этом этапе. По необходимости. Рисунок 10 – Документы 6 – Добавьте используемые программы и базы данных СЛАЙД 42 Процесс должен отражать, какие программы и базы данных в нем используются (рис. 11). Рисунок 11 – Программы и базы 7 – Расположите инструменты и материалы СЛАЙД 43 Если в процессе используются инструменты и/или материалы, это также нужно отобразить. Основные моменты можно обозначить на схеме бизнес-процесса.  Детальное описание лучше дать в комментариях и специальных разделах описания. Отличный вариант – составить схему, ориентированную именно на использование инструментов и материалов. В подобной схеме упор делается не на поток работ, а на то, как, в каком количестве и какие материалы используются в бизнес-процессе. 8 – Определите показатели эффективности в бизнес-процессе Расположите на схеме бизнес-процесса показатели эффективности, которые тем или иным способом учитываются в системе (рис. 12). Рисунок 12 – Показатели эффективности 9 – Свяжите полученную схему с другими процессами СЛАЙД 44 Каждый бизнес-процесс – это лишь часть большой системы. Все процессы связаны между собой. По сути, связь является чем-то, чем процесс обменивается с другими процессами. Обратите внимание: необходимо указать процессы, с которыми связан текущий процесс, а также то, чем они обмениваются (рис. 13). Рисунок 13 - Связь бизнес-процесса с другими процессами 10 – Проверьте полученную модель бизнес-процесса СЛАЙД 45 В принципе, схема готова. Схема бизнес-процесса должна отвечать на следующие вопросы: • С чего начинается и чем заканчивается бизнес-процесс? • С какими процессами он связан? Чем обменивается? • Какие операции выполняются? В каком порядке? • Кто выполняет операции в процессе? • Какие документы используются и появляются в процессе? В каких операциях эти документы используются/появляются? • Какие инструменты, материалы, ПО и базы данных используются в процессе и в каких операциях? • Какие показатели эффективности и где именно фиксируются в бизнес-процессе? В качестве нотации моделирования эксперт рекомендует использовать BPMN. Практические рекомендации, по использованию нотации, с примерами и иллюстрациями, можно найти здесь. Качественно подготовленная схема должна быть проста для восприятия и достаточно информативна. Схема бизнес-процесса должна быть понятна «человеку с улицы». Схема бизнес-процесса на этапе описания должна отражать то, как процесс выполняется в реальной жизни. Данный алгоритм позволит вам довольно просто и быстро описать необходимые бизнес-процессы.