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

Автор: В.Г. Елиферов, А.Н. Прошин

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

Инструменты для описания бизнес-процессов - инструменты класса BPA (Business Process Analysis). Например, Oracle BPA (ARIS), Casewise Corporate Modeler, IDEF**, Proforma и др. создают понятные для менеджеров картинки и диаграммы, но для ИТ-специалиста они не всегда пригодны. ИТ-специалисты должны получать, четкое, понятное описание бизнеса, а не создавать его заново, используя свои инструменты, инструменты автоматизации.

Таким образом, необходима связка между инструментами описания бизнес-процессов и инструментами автоматизации бизнес-процессов класса BPM (Business Process Management) такими как Oracle Business Studio (ранее BEA Business Studio), Tibco, Lombardi и др. Этой проблеме и посвящена данная статья

Организация - как система

Любую организацию можно рассматривать как достаточно сложную систему состоящую из множества подсистем и элементов. Достаточно точное определение системы дается в стандарте ИСО/МЭК 15288:2002 - "Проектирование систем - Процессы жизненного цикла системы".

Система [system] - комбинация взаимодействующих элементов, организованных для того, чтобы достичь одну или более заявленную цель. [1] То есть, для описания системы необходимо определить элементы (объекты) из которых состоит система и связи между этими элементами (объектами). Для практических нужд моделирования бизнес-процессов связи между элементами системы могут иметь различный характер, свойства и атрибуты, то есть тоже могут рассматриваться как объекты системы.

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

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

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

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

Если говорить об отдельных бизнес-процессах, то здесь очень важно вовремя остановиться при проведении декомпозиции бизнес-процессов сверху-вниз. На практике, для того чтобы достаточно четко разделить объекты моделирования по их основным атрибутам в базе объектов в компании ООО "ФОРС-Центр разработки" используется широко распространенная Матрица Захмана [3].

Матрица Захмана - схема для структурирования бизнес-процессов/p>

Рис. 1. Матрица Захмана - основа для анализа и структурирования бизнес-процессов.

Матрица Захмана (framework) определяет какие аспекты деятельности организации:

• Цели - Зачем?
• Процессы- Как?
• Структуры - Кто?
• и т.д.

… и на каких уровнях:

• Контекстуальном - Миссия / Стратегия
• Концептуальном - Бизнес / Организация
• Логическом - Подразделения / Специализация
• и т.д

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

И этот принцип в полной мере относится к системам бизнес-процессов организаций, поскольку проблема "что считать элементами системы", решенная "по усмотрению исследователя" (бизнес-аналитика) загубила не один проект "описания бизнес-процессов". Как правило, бизнес-аналитики пытаются создать очень подробную модель и максимально использовать возможности инструмента. Так на одном крупном пищевом комбинате модель процессов созданная в нотации IDEF0 содержала Процесс А422311 "Разбивание крупных комков сахара, соли" - (6-й уровень декомпозиции!!!). Являлось ли целью проекта моделирования бизнес-процессов, создать описание глубиной до отдельных технологических операций или даже переходов? - На этот вопрос получить ответ не удалось.

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

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

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

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

Рис. 2 Так выглядит модель бизнес-процесса "Отчета за командировку" на детальном уровне описания в средстве бизнес-моделирования (Сasewise Corporate Modeler).

С другой стороны, стандартом де-факто нотации, используемой в BPM-инструментах стал язык BPMN (Business Process Modelling Notation).

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

Объекты определили, нотацию выбрали, модель нарисовали. Что дальше?

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

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

Такой транслятор "BPM Accelerator" был разработан в компании ФОРС

BPM Accelerator реализован как встроенный модуль Casewise Corporate Modeler.

Рис. 3 Схема преобразования диаграммы бизнес-процесса (нотация Casewise) с помощью транслятора в исполняемый процесс BPM.

После его запуска для выбранной диаграмма, сначала проверяется соответствие нотации, используемой при построении данной диаграммы, нотации BPMN и в случае необходимости предлагается дополнить таблицу соответствия между используемыми нотационными объектами и объектами из нотации BPMN. То есть бизнес-процесс проходит дополнительную проверку на непротиворечивость созданных объектов и связей между ними. После установления соответствия осуществляется трансляция диаграммы в код на промежуточном языке XPDL (Extended Process Definition Language), который уже загружается в BPM-инструмент.

Наш инструмент BPM Accelerator позволяет осуществить трансляцию детальных диаграмм из средства бизнес-моделирования в средство автоматизации бизнес-процессов.

Пример результата трансляции диаграммы бизнес-процесса "Отчет за командировку" в среду Oracle BPM Studio показан на следующем Рис.4.

Рис. 4 Так выглядит модель бизнес-процесса "Отчет за командировку" после трансляции ее в BPM.

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

Таким образом, для автоматизации конкретного бизнес-процесса не нужно повторять его описание в средстве BPM, в которое транслируется готовая модель.

Список литературы

1. ИСО/МЭК 15288:2002 - Проектирование систем - Процессы жизненного цикла системы.
2. Гради Буч Объектно-ориентированный анализ и проектирование с примерами приложений / (3 изд.) М. "Вильямс" 2008 г
3. David C. Hay. Requirements Analysis: From Business Views to Architecture. Published 2002 by Prentice Hall.