«Третья волна» принесла в моделирование бизнес-процессов стремление к стандартизации. Методологии построения исполняемых моделей разрабатываются и выпускаются организациями по стандартизации и международными консорциумами:

– OASIS (Organization for the Advancement of Structured Information Standards, осн. в 1993 г.) выпускает спецификации ebXML и BPEL, а также различные стандарты для электронного бизнеса на базе XML и веб-сервисов;

– OMG (Object Management Group, осн. в 1989 г.) выпускает стандарты BPMN и UML, а также MDA и CORBA;

– W3C (World Wide Web Consortium, осн. в 1994 г.) выпускает стандарты WS-CDL, WSCI, а также спецификации XML, технологии веб-сервисов и многие другие;

– WfMC (Workflow Management Coalition, осн. в 1993 г.) выпускает стандарты Wf-XML и XPDL.

На современном этапе в круг задач моделирования и автоматизации бизнес-процессов все чаще включают автоматизацию взаимодействия предприятия с внешней средой. В модели бизнес-процесса отражают взаимодействие компании с различными внешними сущностями: клиентами, коммерческими партнерами, поставщиками, административными органами. При автоматизации процесса данные взаимодействия также стараются по возможности автоматизировать. Особенно активно развиваются технологии автоматизации межкорпоративного взаимодействия – бизнес-бизнес (англ. Business-to-Business, B2B).

1.3. Моделирование бизнес-процессов

1.3.1 Основные принципы моделирования бизнес-процессов

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

– Точно определить результат бизнес-процесса и оценить его значение для бизнеса.

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

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

– Произвести разделение зон ответственности: определить и отслеживать, какой сотрудник или подразделение компании несет ответственность за выполнение того или иного действия или процесса в целом.

– Определить ресурсы, потребляемые бизнес-процессом. Точно зная, кто какие ресурсы использует и для каких операций, можно повысить эффективность использования ресурсов посредством планирования и оптимизации.

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

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

– Определить потенциально узкие места и возможности для улучшения процесса, которые будут использованы позже для его оптимизации.

– Более эффективно внедрить стандарты качества, например, ИСО 9000, и успешно пройти сертификацию.

– Использовать модели бизнес-процессов в качестве руководства для новых сотрудников.

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

– Разобравшись в совокупности бизнес-процессов, понять и описать деятельность предприятия в целом.

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

Первый вопрос при построении модели «как есть» касается результата рассматриваемого бизнес-процесса. Случается, что получить четкую формулировку результата бизнес-процесса нелегко, несмотря на всю важность этого понятия для эффективности работы компании.

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

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

На рисунке 1.4 показаны основные шаги при построении модели бизнес-процесса.

Рисунок 1.4 – Шаги построения модели бизнес-процесса

Важной частью построения модели бизнес-процесса является исследование аспектов его эффективности. Сюда входят использование ресурсов, время выполнения работ сотрудниками, возможные задержки и простои. Необходимо разработать систему показателей или метрик для оценки эффективности процесса. Частично в качестве метрик могут быть взяты используемые в компании показатели KPI (Key Performance Indicator), однако могут потребоваться и дополнительные, характеризующие рассматриваемый процесс, показатели.

При моделировании определяются бизнес-цели, в достижение которых вносит свой вклад моделируемый процесс. Следует различать понятия бизнес-цели и результата процесса. Каждый бизнес-процесс должен иметь, как минимум, один результат и быть направлен на достижение хотя бы одной бизнес-цели. Например, результат процесса «Исполнение заказа на подключение абонента» можно определить, как «Получение подтверждения подключения от клиента», тогда как бизнес-цели, которые преследуются при выполнении данного процесса, могут включать «Обеспечение минимального времени исполнения заказа» и «Обеспечение минимального процента рекламаций». Для определения целей следует обратиться к бизнес-стратегии.

Необходимо выявить события, которые могут прервать ход процесса. В случае прерывания может потребоваться корректно «откатить» (компенсировать) те шаги процесса, которые уже были выполнены. Для этого следует определить логику компенсирующих действий для каждого прерывающего события.

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

Собрав все указанные сведения, можно получить хорошее представление о ходе бизнес-процесса. На этапе моделирования должны быть получены следующие результаты:

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

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

3. Модель «как есть» каждого рассмотренного бизнес-процесса, детально описывающая процесс и отражающая ход процесса, действия, роли, движение документов, а также точки возможной оптимизации. Такая модель включает в себя:

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

– высокоуровневую диаграмму процесса, показывающую его крупные шаги (обычно не более десяти) и, связанные с ними роли;

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

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

На практике хорошо зарекомендовал себя следующий состав группы, осуществляющей моделирование бизнес-процесса:

1. владелец бизнес-процесса и один/два сотрудника того же подразделения компании, помогающих ему;

2. специалист по управлению качеством;

3. бизнес-аналитик(и);

4. представитель ИТ-подразделения;

5. внешний консультант (не обязательно).

1.3.2 Нотация и модель бизнес-процессов (BPMN)

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

BPMN (англ. Business Process Model and Notation, нотация и модель бизнес-процессов) – система условных обозначений (нотация) для моделирования бизнес-процессов. Разработана Business Process Management Initiative (BPMI.org) и поддерживается Object Management Group, после слияния обеих организаций в 2005 году. Последняя версия BPMN – 2.0.

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

По заявлению разработчиков стандарта BPMN, он вобрал в себя лучшие идеи, что имеются в следующих нотациях и методологиях моделирования:

1. UML (Unified Modeling Language, Унифицированный язык моделирования): Activity Diagram (диаграмма деятельности), EDOC (Enterprise Distributed Object Computing, корпоративная распределенная обработка объектов) – Business Processes (бизнес-процессы);

2. IDEF (SADT);

3. ebXML (Electronic Business eXtensible Markup Language, расширяемый язык разметки для электронного бизнеса) BPSS (Business Process Specification Schema, схемы спецификации бизнес-процессов);

4. ADF (Activity-Decision Flow, поток «деятельность-результат») Diagram;

5. RosettaNet;

6. LOVEM (Line of Visibility Engineering Methodology, визуальная методология проектирования);

7. EPC.

Поддержка и дальнейшее развитие BPMN организацией OMG наложило свой «отпечаток» на данную методологию. Одним из ключевых направлений OMG является продвижение UML, предназначенного для моделирования объектно-ориентированных систем. В связи с этим, в BPMN при моделировании (разработке диаграмм), помимо понятий и концепций структурного подхода (действие, поток управления, объект данных и т. д.), используются такие характерные для объектно-ориентированного подхода понятия, как сообщение, обмен сообщениями и поток сообщений.

Элементы (символы) графической нотации BPMN по назначению объединены в категории:

1. объекты потока (Flow Objects);

2. данные (Data);

3. зоны ответственности (Swimlanes);

4. соединяющие элементы (Connecting Objects);

5. артефакты (Artifacts).

В табл. 1.2 приведены символы нотации BPMN и их базовое изображение [39].

Таблица 1.2. Символы нотации BPMN

Символы объектов потока, объект данных и поток управления имеют дополнительное семантическое деление с целью отображения специфики происходящих событий, выполнения действий, особенностей слияния/ветвления потоков и т. д. Указание специфики выполняется за счет дополнительного графического изображения (иконки, маркера), помещенного внутрь основного символа. В дополнение к этому символы событий могут иметь различный вид контура и фоновый цвет.

Ниже приводится описание специфики отображения символов и их семантическая интерпретация.

События

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

Все события классифицируются по следующим признакам:

1. По времени наступления:

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

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

1.3. Промежуточное событие – все остальные события, возникающие в ходе выполнения процесса. В промежуточное событие обязательно должен входить и выходить один поток. Исключение составляют граничные (Boundary) события, возникающие и обрабатываемые непосредственно либо в самом начале действия, либо в его конце. Такие события отображаются на границе (контуре) действия и у них может быть только либо входящий, либо исходящий поток. Контур события отображается двойной тонкой линией.

2. По возможности прерывания выполнения действия (подпроцесса):

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

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

3. По типу результата действия:

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

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

4. По причине возникновения (триггеру).

Действия

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

Различают три основных вида действий и их разновидности:

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

– сервисная (Service). Задача предназначена для оказания услуги, которая может являться как веб-сервисом, так и автоматизированным приложением;

– отправка сообщения (Send). Задача считается выполненной, если сообщение послано хотя бы один раз;

– получение сообщения (Receive). Задача считается выполненной, если сообщение получено хотя бы один раз;

– пользовательская (User). Характерная задача, выполняемая исполнителем при содействии других людей или программного обеспечения;

– ручное исполнение (Manual). Характерная задача, выполняемая исполнителем без каких-либо средств автоматизации;

– бизнес-правило (Business-Rule). Задача, технология выполнения которой зависит от текущих обстоятельств и выбирается на основе заданного бизнес-правила;

– сценарий (Script). Задача, порядок выполнения операций которой описан на языке, распознаваемом исполнителем. Обычно используется для задач, выполняемых автоматическими средствами;

подпроцесс (Sub-Process) – составное действие, включающее в себя другие действия, шлюзы, события и потоки операций. Части подпроцесса могут непосредственно отображены на диаграмме внутри символа действия или вынесены на отдельную диаграмму декомпозиции. Во втором случае на родительской диаграмме в центре нижнего края действия (подпроцесса) отображается символ +. Кроме стандартных подпроцессов, имеется еще две специфические его разновидности:

– событийный подпроцесс (Event Sub-Process). Запускается каждый раз, когда происходит одно из стартовых событий. На диаграмме событийный подпроцесс не связан с другими действиями потоками операций. Контур подпроцесса отображается точками;

– транзакция (Transaction). Действие, состоящее из составных операций, удачное завершение (получение конкретного положительного результата) которого возможно при удачном завершении всех его составляющих. В случае возникновения проблем при выполнении подпроцесса (невозможности выполнения одной из операций или высокой вероятности ее некорректного выполнения) результаты предыдущих операций отменяются (событие отмена) или компенсируются (событие компенсация). Контур подпроцесса отображается двойной сплошной линией;

– вызов (Call). Позволяет включать в состав диаграммы повторно используемые задачи и подпроцессы. На диаграмме выделяется жирным контуром.

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

– цикл (Loop). Действие выполняется в цикле с пред- (while) или пост- (repeat-until) условием;

||| или ≡ – многоэкземплярность (Multi-Instance). Параллельное или последовательное выполнение нескольких экземпляров однотипных действий. При последовательном выполнении действие можно рассматривать как цикл с параметром (for);

– компенсация (Compensation). Действие выполняется взамен стандартного при невозможности его удачного завершения;

~ – настраиваемый подпроцесс (Ad-Hoc). Указывается только для подпроцессов. Конкретный состав и последовательность входящих в него действий определяется исполнителем в процессе его выполнения.

В общем случае для действия может быть указано несколько маркеров.

Шлюзы

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

– эксклюзивный (Exclusive, XOR – исключающее ИЛИ). Предназначен для разделения потока операций на несколько альтернативных маршрутов, т. е. в ходе выполнения процесса может быть активирован только один из предложенных маршрутов. Условия пропуска по исходящему маршруту задается рядом с соответствующей линией в виде логического выражения;

– неэксклюзивный (Inclusive, OR – логическое ИЛИ). Предназначен для разделения потока операций на несколько маршрутов, каждый из которых активируется при условии истинности связанного с ним логического выражения. Таким образом, при выполнении процесса может быть выбрано сразу несколько маршрутов, в т. ч. и ни одного в случае ложности всех выражений;

– комплексный (Complex). Аналогичен неэксклюзивному шлюзу. Отличие заключается в том, что с ним связано одно выражение, которое определяет, какие из потоков операций будут активированы;

– параллельный (Parallel, AND – логическое И). Предназначен для слияния/ветвления одновременно (параллельно) выполняемых потоков операций;

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

<1 2 3 4 5 6 >

На страницу:

Перейти

3 из 6