52
Как следующий шаг в автоматизации бизнес-процессов в 1990-х гг.
появляются системы управления потоками работ WfMS (Workflow Management
System) второго поколения, предназначенные для маршрутизации потоков
работ любого типа в рамках бизнес-процессов компании. Эти системы
снабжены средой разработчика, которая теоретически может использоваться
для моделирования различных нестандартных бизнес-процессов, однако на
практике в большинстве случаев внедрение нового или изменение имеющегося
процесса требовало привлечения труда программистов. Еще более ограни-
ченные возможности по настройке и изменению процессов предоставляли
поддерживающие управление потоками работ системы планирования ресурсов
предприятия ERP (Enterprise Resource Planning). Внесение любых
существенных изменений в бизнес- процесс превращалось в весьма
дорогостоящий и долгосрочный проект по проектированию и разработке
программного обеспечения, а модели бизнес-процессов, построенные
аналитиками, использовались для более четкой формулировки требований,
которые затем передавались программистам. В качестве примера методологии
и средства автоматизации бизнес-процессов второго поколения можно назвать
соответственно ARIS и распространенную ERP-систему SAP R/3.
Негибкость моделей и средств автоматизации, их неспособность
обеспечить оперативное реагирование на постоянные изменения в бизнес-среде
стали основными недостатками систем «второй волны», стимулировавшими
разработку в начале 2000-х гг. методологий следующего — третьего —
поколения. Манифестом «третьей волны» в моделировании бизнес-процессов
можно по праву назвать книгу Г. Смита и П. Фингара «Управление бизнес-
процессами: третья волна». На смену радикальному реинжинирингу приходит
системное и «плавное» управление. Изменчивость бизнес-процессов,
возможность их корректировки в ответ на изменения в бизнесе становятся
главным критерием использования информационных технологий как средства,
позволяющего получить преимущества на рынке.
53
Идея методологий и инструментов моделирования третьего поколения
состоит в том, чтобы позволить руководству и сотрудникам компании
создавать и самим внедрять новые процессы «на лету». Автоматизация
процессов производится посредством так называемых систем управления
бизнес-процессами BPMS (Business Process Management System), которые дают
возможность непосредственно реализовывать бизнес-процессы в соответствии
с построенной формальной моделью и не требуют разработки дополнительного
программного обеспечения.
Для разработки понятных машине «исполняемых» моделей требуются
более точные методы моделирования. К таким методам относятся языки
моделирования на базе XML: BPML, BPEL, XPDL. Однако построение моделей
непосредственно на этих языках неудобно для бизнес-пользователей. В этой
связи большое внимание разработчики программного обеспечения уделяют
средствам конвертирования графических моделей бизнес-процессов в
исполняемые. Это позволяет бизнес-аналитику или менеджеру строить модели
бизнес-процессов с использованием графической нотации, а затем
преобразовывать построенную модель (пока нередко с помощью технического
специалиста) в исполняемый вид.
Следует понимать, что графические модели, предназначенные для
преобразования в исполняемые, должны быть гораздо более строгими и
формальными по сравнению с моделями, создаваемыми в аналитических целях.
Например, графическую модель, построенную в виде блок-схемы с обширными
текстовыми комментариями, автоматически конвертировать в исполняемый
формат не удастся. В качестве языка, позволяющего построить наглядную,
понятную неподготовленному пользователю модель, которую затем можно
однозначно преобразовать в исполняемый язык (изначально это был 3PML),
выступила нотация BPMN. Она поддерживает описание таких
программистских функций, как обработка событий и ошибок, откат транзакций
и т. п.
54
«Третья волна» принесла в моделирование бизнес-процессов стремление
к стандартизации. Методологии построения исполняемых моделей
разрабатываются и выпускаются организациями по стандартизации и
международными консорциумами:
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).
Потребности в автоматизации бизнес-процессов взаимодействия между
предприятиями возникли еще в 60-х гг. прошлого века. Первое поколение
электронных систем В2В- взаимодействия описывает стандарт UN/EDIFACT,
или ЭДИФАКТ ООН (Правила ООН Электронного Обмена Данными в
Управлении, Торговле и на Транспорте, ISO 9735), который, несмотря на
высокую конкуренцию со стороны XML-систем в последние годы, до сих пор
довольно широко применяется в Европе во многих секторах экономики.
55
Развитие сети Интернет послужило толчком к созданию новых методов и
технологий в области электронного обмена данными. Одним из наиболее
удачных методов электронного обмена является появившаяся в 1998 г.
методология консорциума RosettaNet. Данная технология описывает открытую
платформу электронного взаимодействия, основанного на стандарте XML, и
позволяет сторонам, участвующим во взаимодействии, обмениваться бизнес-
информацией через Интернет. Первоначально стандарт был разработан для
индустрии высоких технологий (информационные технологии и электроника),
однако предложенный подход послужил основой механизмов взаимодействия
предприятий и других отраслей. В рамках методологии RosettaNet разработаны
стандарты более сотни процессов бизнес-взаимодействия между различными
компаниями или подразделениями внутри одного предприятия. Эти
стандартизованные процессы получили название процессов интерфейса
взаимодействия с партнером (Partner Interface Process, PIP) и специфицируют
транзакции между двумя бизнес-системами в форме диалога на основе
стандарта XML.
Еще одной современной технологией автоматизации межкорпоративного
взаимодействия является ebXML (Electronic Business using extensible Markup
Language, ИСО 15000). Работа над технологией ebXML началась в 1999 г. по
инициативе СЕФАКТ ООН (Центр ООН по поддержке процедур и практики
управления, коммерции и транспорта) и консорциума OASIS, накопившего
большой опыт в сфере организации ведения бизнеса в Интернете на базе XML.
Целью данного проекта является разработка инфраструктуры электронного
бизнеса — полного набора спецификаций, позволяющего осуществлять бизнес-
взаимодействия через единообразную XML-среду. С появлением ebXML
компании получили стандартизованный де-факто метод обмена данными и
бизнес- сообщениями, а также единые условия информационной поддержки
торговых отношений. Архитектура ebXML объединяет спецификации формата
сообщений, модели бизнес-про- цессов, пакет синтаксически нейтральных
базовых компонентов и распределенные хранилища данных (репозитории).
56
Стандарт ebXML получает все более широкое распространение с внедрением
технологии веб-сервисов (Web Services). [30]
2.4. Виды, стадии и принципы моделирования бизнес-процессов
Виды моделирования бизнес процессов
Моделирование бизнес процессов может иметь различную
направленность. Это зависит от того, какие проблемы предполагается решить с
его помощью. Учет абсолютно всех воздействий на процесс может значительно
усложнить модель и привести к избыточности описания процесса. Чтобы этого
избежать, моделирование бизнес процессов разделяют по видам. Вид
моделирования выбирается в зависимости от исследуемых характеристик
процесса.
Наиболее часто, для целей совершенствования процесса применяют
следующие виды моделирования:
Функциональное моделирование. Этот вид моделирования
подразумевает описание процессов в виде взаимосвязанных, четко
структурированных функций. При этом строгая временная последовательность
функций, в том виде, как она существует в реальных процессах, не обязательна.
Объектное моделирование – подразумевает описание процессов, как
набора взаимодействующих объектов – т.е. производственных единиц.
Объектом является какой-либо предмет, преобразуемый в ходе выполнения
процессов.
Имитационное моделирование – при таком виде моделирования
бизнес-процессов подразумевается моделирование поведения процессов в
различных внешних и внутренних условиях с анализом динамических
характеристик процессов и с анализом распределения ресурсов.
Разделение моделирования по видам выполняется для упрощения работы
и концентрации внимания на тех или иных характеристиках процесса. При этом
для одного и того же процесса могут быть применены различные виды
моделирования. Это позволяет работать с одним видом моделей независимо от
других.[31]
57
Стадии моделирования бизнес процессов
Моделирование бизнес процессов, как правило, включает в себя
выполнение нескольких последовательных стадий. Т.к. конечной целью
моделирования является улучшение процессов, то оно охватывает и
«проектную» часть работы, и работы по внедрению моделей процессов.
Состав стадий, которые включает в себя моделирование бизнес
процессов следующий:
выявление процессов и построение исходной модели «как есть». Для
того чтобы улучшить процесс, необходимо понимать, как он работает в данный
момент. На этой стадии определяются границы процесса, выявляются его
ключевые элементы, собираются данные о работе процесса. В результате
создается исходная модель процесса «как есть». Эта модель не всегда адекватно
отражает работу процесса, поэтому модель этой стадии можно назвать «первым
драфтом» или исходной моделью «как есть».
пересмотр, анализ и уточнение исходной модели. На этой стадии
выявляются противоречия и дублирование действий в процессе, определяются
ограничения процесса, взаимосвязи процесса, устанавливается необходимость
изменения процесса. В результате формируется окончательный вариант модели
«как есть».
разработка модели «как должно быть». После анализа
существующей ситуации, необходимо определить желаемое состояние
процесса. Это желаемое состояние представляется в модели «как должно
быть». Такая модель показывает, как процесс должен выглядеть в будущем,
включая все необходимые улучшения. В ходе этой стадии моделирования
бизнес процессов и разрабатываются такие модели.
тестирование и применение модели «как должно быть». Эта стадия
моделирования связана с внедрением разработанной модели в практику
деятельности организации. Модель бизнес процесса проходит апробацию, и в
нее вносятся необходимые изменения.
58
улучшение модели «как должно быть». Моделирование бизнес-
процессов не ограничивается только созданием модели «как должно быть».
Каждый из процессов по ходу работы продолжает изменяться и
совершенствоваться, поэтому модели процессов должны регулярно
пересматриваться и улучшаться. Эта стадия моделирования связана с
постоянным улучшением процессов и улучшением модели бизнес-
процессов.[31]
Принципы моделирования бизнес процессов
Моделирование бизнес процессов основывается на ряде принципов,
которые дают возможность создать адекватные модели процессов. Их
соблюдение позволяет описать множество параметров состояния процессов
таким образом, чтобы внутри одной модели компоненты были тесно
взаимосвязаны, в то время как отдельные модели оставались в достаточной
степени независимыми друг от друга.
Главными принципами моделирования бизнес процессов являются
следующие:
Принцип декомпозиции – каждый процесс может быть представлен
набором иерархически выстроенных элементов. В соответствии с этим
принципом процесс необходимо детализировать на составляющие элементы.
Принцип сфокусированности – для разработки модели необходимо
абстрагироваться от множества параметров процесса и сфокусироваться на
ключевых аспектах. Для каждой модели эти аспекты могут быть свои.
Принцип документирования – элементы, входящие в процесс, должны
быть формализованы и зафиксированы в модели. Для различных элементов
процесса необходимо использовать различающиеся обозначения. Фиксация
элементов в модели зависит от вида моделирования и выбранных методов.
Принцип непротиворечивости – все элементы, входящие в модель
процесса должны иметь однозначное толкование и не противоречить друг
другу.
59
Принцип полноты и достаточности – прежде чем включать в модель
тот или иной элемент, необходимо оценить его влияние на процесс. Если
элемент не существенный для выполнения процесса, то его включение в модель
не целесообразно, т.к. он может только усложнить модель бизнес-процесса.[31]
2.5. Методы моделирования бизнес-процессов
Под методологией (нотацией) создания модели (описания) бизнес-
процесса понимается совокупность способов, при помощи которых объекты
реального мира и связи между ними представляются в виде модели. Для
каждого объекта и связей характерны ряд параметров, или атрибутов,
отражающих опредёленные характеристики реального объекта (номер объекта,
название, описание, длительность выполнения (для функций), стоимость и др.).
Основу многих современных методологий моделирования бизнес-
процессов составили методология SADT (Structured Analysis and Design
Technique – метод структурного анализа и проектирования), семейство
стандартов IDEF (Icam DEFinition, где Icam – это Integrated Computer-Aided
Manufacturing) и алгоритмические языки.[32]
Основные типы методологий моделирования и анализа бизнес-процессов:
Моделирование бизнес-процессов (Business Process Modeling).
Наиболее широко используемая методология описания бизнес-процессов –
стандарт IDEF0. Модели в нотации IDEF0 предназначены для
высокоуровневого описания бизнеса компании в функциональном аспекте.
Описание потоков работ (Work Flow Modeling). Стандарт IDEF3
предназначен для описания рабочих процессов и близок к алгоритмическим
методам построения блок-схем.
Описание потоков данных (Data Flow Modeling). Нотация DFD (Data
Flow Diagramming), позволяет отразить последовательность работ,
выполняемых по ходу процесса, и потоки информации, циркулирующие между
этими работами.
Прочие методологии.[33]
idef0
60
Модель состоит из диаграмм, фрагментов текстов и глоссария, имеющих
ссылки друг на друга. Диаграммы — главные компоненты модели, все функции
и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с
блоком определяет тип интерфейса:
Тип интерфейса:
Управляющая информация входит в блок сверху.
Входная информация входит в блок слева.
Результаты выходят из блока справа.
Механизм (человек или автоматизированная система), который
осуществляет операцию, входит в блок снизу.
Каждый компонент модели может быть декомпозирован (расшифрован
более подробно) на другой диаграмме. Рекомендуется прекращать
моделирование, когда уровень детализации модели удовлетворяет ее цель.
Общее число уровней в модели не должно превышать 5-6.
Построение диаграмм начинается с представления всей системы в виде
одного блока и дуг, изображающих интерфейсы с функциями вне системы.
Затем блок, который представляет систему в качестве единого модуля,
детализируется на другой диаграмме с помощью нескольких блоков,
соединенных интерфейсными дугами. Каждая детальная диаграмма является
декомпозицией блока из диаграммы предыдущего уровня. На каждом шаге
декомпозиции диаграмма предыдущего уровня называется родительской для
более детальной диаграммы.
На таких диаграммах не указаны явно ни последовательность, ни время.
Метод обладает рядом недостатков: сложность восприятия (большое
количество дуг на диаграммах и большое количество уровней декомпозиции),
трудность увязки нескольких процессов.[33]
idef3
Этот метод предназначен для моделирования последовательности
выполнения действий и взаимозависимости между ними в рамках процессов.
61
Модели IDEF3 могут использоваться для детализации функциональных блоков
IDEF0, не имеющих диаграмм декомпозиции.
Диаграммы IDEF3 отображают действие в виде прямоугольника.
Действия именуются с использованием глаголов или отглагольных
существительных, каждому из действий присваивается уникальный
идентификационный номер (номер действия обычно предваряется номером его
родителя, например, 1.1.). Все связи в IDEF3 являются однонаправленными и
организуются слева направо.
Типы связей IDEF3:
Временное предшествование (Temporal precedence), простая стрелка.
Исходное действие должно завершиться, прежде чем конечное действие
сможет начаться.
Объектный поток (Object flow), стрелка с двойным наконечником.
Выход исходного действия является входом конечного действия. Исходное
действие должно завершиться, прежде чем конечное действие сможет начаться.
Наименования потоковых связей должны чётко идентифицировать объект,
который передается с их помощью.
Нечеткое отношение (Relationship), пунктирная стрелка.
Завершение одного действия может инициировать начало выполнения
сразу нескольких других действий, или наоборот, определенное действие
может требовать завершения нескольких других действий до начала своего
выполнения (ветвление процесса).
Ветвление процесса отражается с помощью специальных блоков:
"И", блок со знаком &.
"Исключающее ИЛИ" ("одно из"), блок со знаком Х.
"ИЛИ", блок со знаком О.
Если действия "И", "ИЛИ" должны выполняться синхронно, это
обозначается двумя двойными вертикальными линиями внутри блока,
асинхронно – одной.