Office Air Magazine: журнал о науке, бизнесе и не только...

Главная » Статьи » Теория и практика управления

ПРАКТИКА МОДЕЛИРОВАНИЯ И ОРГАНИЗАЦИИ БИЗНЕС-ПРОЦЕССОВ
Для того чтобы автоматизировать бизнес-процесс, нужно иметь его описание, а также представлять себе объект, который необходимо автоматизировать. Описание бизнеса и бизнес-процессов - это важная и самостоятельная задача, которую должны решать не ИТ-специалисты, а бизнес-аналитики, консультанты и управленцы. Они создают модель бизнеса, на детальном уровне которой описываются схемы автоматизируемых бизнес-процессов. Автоматизировать можно только те процессы, отраженные на схеме, которые прошли логический контроль со стороны менеджеров и бизнес-аналитиков. Но часто возникает проблема, связанная с тем, что менеджеры и бизнес-аналитики плохо понимают языки автоматизации исполняемых бизнес-процессов класса 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.

ris-1

Рис. 1. Модель бизнес-процесса “Отчет за командировку” на детальном уровне описания в средстве бизнес-моделирования Сasewise Corporate Modeler

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

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

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

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

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

ris2

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

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

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

ris-3

Рис. 3. Модель бизнес-процесса «Отчет за командировку» после ее трансляции в 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.

Взято: http://www.goodlancer.com/archives/5213

Категория: Теория и практика управления | Добавил: economist (25.05.2009)
Просмотров: 10977
Форма входа
Категории раздела
Теория и практика управления [4]Наука: открытия и исследования [3]
Друзья сайта
  • ИПММС НАНУ
  • Академия технологических наук Украины
  • Форум AUP.RU
  • Блог ученой кошки
  • Дневник ученой кошки
  • Статистика