Визуальное моделирование бизнес-процессов

Новая концепция бизнеса - ориентация на бизнес-процессы

В 70-80-х годах прошлого века началось массовое снижение конкурентоспособности американских бизнес-компаний. В частности, японские компании стали успешно конкурировать с американскими прямо на внутреннем рынке США. В поисках путей повышения эффективности американского бизнеса в начале 1990-х годов в США появилась новая парадигма организации бизнеса, ориентированная на процессы. В результате, в лексикон бизнеса и IT-технологий вошли такие термины, как бизнес-процесс (business process), реинжиниринг бизнеса (business reengineering), реинжиниринг бизнес-процессов (business process reengineering), моделирование бизнес-процессов (business process modeling).

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

Эту идею в конце XVIII века впервые сформулировал Адам Смит. На ее основе были созданы мануфактуры, которые в XIX веке вытеснили ремесленные цеха и кустарное производство товаров. В начале XX века Генри Форд усовершенствовал эту идею и создал сборочный конвейер на своих автомобильных заводах, что позволило значительно увеличить производительность труда. Сейчас такие конвейеры существуют во многих отраслях промышленности. После этого Альфред Стоун, руководитель компании "Дженерал Моторс", применил идею разделения труда к управлению крупным производством.

В начале 1990-х годов Майкл Хаммер и Джеймс Чампли предложили иную форму организации бизнеса, ориентированную на процессы (бизнес-процессы).

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

ERP-системы

На сегодняшний день существуют стандартные системы комплексной автоматизации бизнеса компании, ориентированные на поддержку бизнес-процессов в компании и называющиеся ERP-системами (Enterprise Resource Planning). Лидерами в этой области являются системы SAP R/3, Oracle Applications, BAAN, Microsoft Axapta.

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

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

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

Недостатком ERP-систем является высокая стоимость (по сравнению с ценой готовых систем, решающих какие-либо частные задачи бизнеса), а также высокая цена на их внедрение, которая, как правило, в несколько раз превышает цену самой системы. Дальнейшую информацию о ERP системах можно почерпнуть в [9.4].

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

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

Почему хорошая формализация бизнес-процесса важна?

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

Пример бизнес-процесса

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

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

Выделим следующие действия бизнес-процесса.

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

Декомпозиция бизнес-процессов

Понятно, что целиком, со всеми деталями бизнес-процесс, представленный выше, существенно больше. Но если все эти детали поместить на одну диаграмму, то она будет чрезвычайно трудна для восприятия и годна только для автоматической обработки. С помощью такой диаграммы нельзя будет объяснить сотрудникам и клиентам порядок работ, она не сможет служить удобным практическим руководством. Однако если ограничиться только деталями верхнего уровня, то получится спецификация "в принципе" - ее можно будет вставлять в отчеты для начальства и использовать только для самого первого, "шапочного" знакомства с тем, как в магазине продается мебель. Но хочется, чтобы спецификация бизнес-процесса была понятна и доступна людям, а также была бы полной. Тогда разные специалисты могли бы упростить знакомство с принципами работы магазина, используя наши спецификации - и те, кто желает получить лишь общее представление, и те, кто должен детально разобраться в каком-то одном фрагменте, и те, к то должен/хочет понять все. Полная спецификация нужна, например, ответственному за делопроизводство магазина. Кроме того, многим специалистам, ответственным за отдельные участки процесса, необходимо детально знать процесс работы смежников, то есть им бы очень пригодился соответствующий фрагмент полной спецификации бизнес-процесса. Наконец, полная спецификация нужна для автоматизированной поддержки бизнес-процесса.

Детальность и доступность одновременно достигаются декомпозицией бизнес-процесса. Так, действие "Оформление заказа" с рис. 9.1 раскрывается в отдельную диаграмму, представленную на рис. 9.2.

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

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

Исполняемая семантика бизнес-процессов

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

Такой вычислитель в англоязычной литературе обычно называют Workflow Engine (WE). Он полезен по следующим причинам.

В итоге, как показано на рис. 9.3, WE оказывается ядром мощной системы автоматизации бизнеса компании. И программа, которую он выполняет, - это спецификация бизнес-процесса.

Рассмотрим, как WE может выполнять фрагмент бизнес-процесса покупки мебели, изображенный на рис. 9.2. Сразу после старта наш процесс начинает деятельность под названием "Создание дизайн-проекта". Например, открывается рабочее окно графического редактора, где создается дизайн-проект (это пример полезного ПО, которое может быть интегрировано с WE ). Выход из этого редактора может осуществляться с сохранением промежуточных результатов - проект еще не готов, процесс продолжает пребывать в состоянии "Создание дизайн-проекта", а продавец-дизайнер вместе с клиентом, например, пошли пить кофе. Второй вариант выхода из редактора - дизайн-проект готов. WE предлагает продавцу-дизайнеру выбрать один из трех вариантов (в виде окошка со списком выбора):

Продавец-дизайнер выбирает тот ответ, который соответствует ситуации, и WE продолжает исполнять процесс.

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

Бизнес-процессы и web-сервисы

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

С бизнес-процессами тесно связны web-сервисы. Так, язык BPMN имеет исполняемые проекции в язык BEPL, а последний описывает бизнес-процессы как набор взаимодействующих web-сервисов.

Web-сервисом, согласно, называется программная система, идентифицируемая строкой URI, чьи открытые интерфейсы и привязки определены и описаны посредством языка XML. Ее описание может быть найдено другими программными системами, которые могут взаимодействовать с ней посредством сообщений, описанных на XML и передаваемых через Интернет-протоколы. URI-строка (Uniform Resource Identifier) состоит из унифицированного указателя информационного ресурса - URL (Uniform Resource Locator) - и унифицированного имени ресурса - URN (Uniform Resource Name). URN - это имя, которое не ссылается на физический ресурс.

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

Обзор BPMN

Далее будет рассмотрен известный язык визуального моделирования бизнес-процессов - ), первая версия стандарта вышла в 2004 году. Позднее этот стандарт перешел под эгиду комитета OMG и в 2006 году была выпущена первая OMG-версия этого стандарта [9.3].

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

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

Рассмотрим эти конструкции подробнее.

Действия (activities)

Процесс состоит из цепочки действий. Действия бывают следующих видов:

Задача (task) - это атомарное действие процесса, неделимое на более элементарные части. На диаграмме задача изображается, как показано на рис. 9.4, a. На рис. 9.4, б приводится три вида задач, которые могут быть заданы в BPMN - циклическая задача, множественная задача и откат.

Циклическая задача (loop) - это задача, которая выполняется в цикле. В параметрах этой задачи можно указать, какой цикл имеется в виду - с пред- или постусловием, определить это условие и указать некоторые дополнительные свойства цикла.

Множественная задача (multiple instance) - это циклическая задача, которая выполняет в цикле целый набор однотипных задач. Текстовыми параметрами можно задать условие цикла, количество однотипных задач, а также порядок их выполнения (последовательный или параллельный).

Откат (compensation) - задача, которая вызывается в случае отмены другой задачи, например, клиент отказался от забронированного отеля - тогда система должна освободить соответствующую бронь; пример приводится на рис. 9.5.

Кроме того, у задачи есть атрибут, который может иметь одно из следующих значений:

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

Еще одним типом действия является подпроцесс (subprocess). Он позволяет разбить сложные процессы на более мелкие. Подпроцессы бывают свернутые (collapsed subprocesses) - см. рис. 9.4, в и г - и развернутые (expanded subprocesses) - см. рис. 9.4, д. Так же как и задачи, подпроцессы могут быть циклическими, множественными и с откатом, но кроме того, могут иметь еще маркер произвольный (ad hoc) - см. рис. 9.4, г. Он означает, что задачи и другие подпроцессы, входящие в состав данного, исполняются в произвольном порядке.

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

Развернутый подпроцесс позволяет задать на диаграмме второй этаж (а, возможно, третий и т. д. - все зависит от того, насколько модель "глубока"). Это означает, что прямо на родительской диаграмме один или несколько процессов детализированы, как показано на рис. 9.6.

Связи (connecting objects)

На рис. 9.7 показаны связи разного вида, существующие в BPMN:

Участники (swimlanes) бизнес-процесса

Таких участников в BPMN бывает два вида. Первый вид - участник бизнес-процесса (pool). Это бизнес-сущность (например, компания), участвующая в бизнес-процессе, или некоторая бизнес-роль - покупатель, продавец, дилер и т. д. В одном бизнес-процессе может быть много компаний, но часть из них может быть представлена бизнес-ролями. Это означает, что в этом общем бизнес-процессе не существенны детали их индивидуальных, внутренних бизнес-процессов, а важна только стандартная реакция, определяемая теми ролями, которые они играют. Одну и ту же роль могут играть разные компании, выполняющие лишь определенные правила взаимодействия. Как бизнес-роль (покупатель, продавец некоторой биржи), так и уникальная компания (например Центробанк РФ) являются в BPMN участниками бизнес-процесса. Пример показан на рис. 9.8, а.

На этом рисунке представлены два участника бизнес-процесса - Client и Service Provider. В каждом из них определен свой бизнес-процесс. Эти участники взаимодействуют друг с другом, обмениваясь сообщениями. Отмечу, что эти сообщения можно было "протащить" до отдельных задач, но можно оставить и так: здесь мы не будем вдаваться в детали семантики сообщений.

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

На рис. 9.8, б показан пример внутренних участников. Так, в компании под названием Service Provider из примера на рис. 9.8, а имеется два отдела - отдел продаж (Sale Department) и производственный отдел (Manufacturing Department). Бизнес-процесс этой компании на рис. 9.8, б распределен по этим двум участникам.

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

Порты (gateways)

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

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

На рис. 9.9, б показан оператор распараллеливания и соединения потоков управления. Как следует из этого рисунка, он может быть изображен с ромбиком и без.

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

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

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

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

На диаграммах BPMN событие изображается, как показано на рис. 9.10, а. Внизу, сразу под символом события, указывается его имя или источник. События бывают трех типов:

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

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

Контрольные вопросы