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

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

Инструменты для описания бизнес-процессов относятся к классу BPA (Business Process Analysis). При помощи инструментальных средств, таких как Oracle BPA (ARIS), Casewise Corporate Modeler, IDEF, Performa, можно создавать понятные для менеджеров картинки и диаграммы, но для ИТ-специалиста они не всегда пригодны. ИТ-специалисты должны получать четкое и понятное описание бизнеса, а не создавать его заново, используя свои программные инструменты. Именно поэтому требуется связующее звено между инструментами описания бизнес-процессов и инструментами автоматизации бизнес-процессов класса BPM (Business Process Management), например, Oracle Business Studio (ранее BEA Business Studio), Tibco, Lombardi и т. д. Решению этой проблемы и посвящена данная статья.

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

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

«Система [system] – это комбинация взаимодействующих элементов, организованных для того, чтобы достичь одну или более из заявленных целей» [1].

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

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

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

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

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

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

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

На практике, для того чтобы достаточно четко разделить объекты моделирования по их основным атрибутам в базе объектов, используется широко распространенная матрица Захмана [3].

Матрица Захмана – схема структурирования бизнес-процессов

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

• цели – зачем?
• процессы – как?
• структура – кто?
• и т. д.

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

• контекстуальном – миссия/стратегия;
• концептуальном – бизнес/организация;
• логическом – подразделения/специализация
• и т. д.

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

Выбор, какие компоненты в данной системе считаются элементарными, относительно произволен и в большой степени оставляется на усмотрение исследователя.

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

Чтобы избежать подобного произвола, есть только два рецепта:

а) тщательно продумать, сформулировать и утвердить цель проекта описания процессов;

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

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

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

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

С другой стороны, стандартом де-факто нотации, используемой в BPM-инструментах, стал язык BPMN (Business Process Modeling Notation). Нотация BPMN может использоваться при описании бизнес-процессов на технологическом уровне описания бизнеса, однако это скорее исключение из правил, так как бизнес-аналитики предпочитают работать с более простыми нотациями. Возникает разрыв между языками, на которых говорят бизнес-аналитики и программисты.

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

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

Эта работа скучна, трудоемка и чревата появлением ошибок, связанных с человеческим фактором. Поэтому вполне закономерно возникает задача создания транслятора, который позволил бы переносить детальные диаграммы из среды бизнес-моделирования в среду автоматизации бизнес-процессов. Компания ФОРС разработала для этого специальный инструмент – BPM Accelerator.

Транслятор бизнес-процессов BPM Accelerator

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

Инструмент BPM Accelerator позволяет проводить трансляцию детальных диаграмм из средства бизнес-моделирования в средство автоматизации бизнес-процессов. Пример результата трансляции диаграммы бизнес-процесса «Отчет за командировку» в среду Oracle BPM Studio показан на рис. 3.

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

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

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

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