Области эффективного применения нотации IDEF0 для задач описания бизнес-процессов Текст научной статьи по специальности «Компьютерные и информационные науки»

Вестник СПбГУ. Сер. 8. 2008. Вып. 2

И. В. Ананьев, Е. Г. Серова

ОБЛАСТИ ЭФФЕКТИВНОГО ПРИМЕНЕНИЯ НОТАЦИИ IDEF0 ДЛЯ ЗАДАЧ ОПИСАНИЯ БИЗНЕС-ПРОЦЕССОВ

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

ВВЕДЕНИЕ

Рыночная ситуация, в которой находятся современные компании, довольно нестабильна и требует быстрой и точной реакции на происходящие изменения. Рано или поздно реорганизация бизнеса становится неизбежной, и менеджерам приходится задумываться о том, как изменить текущие бизнес-процессы (БП), чтобы улучшить деятельность предприятия. Например, производитель может захотеть пересмотреть то, как происходят закупка исходных материалов, порядок оформления заказов, или изменить перечень работ по доставке готовой продукции заказчикам. Очевидно, что реинжиниринг бизнес-процессов (Business Process Reengineering) тесно связан с изменениями архитектуры корпоративных информационных систем (КИС). Ключевым моментом успеха проекта по реорганизации является тесное взаимодействие между всеми группами лиц, заинтересованных в выполнении задачи, прежде всего между специалистами в сфере информационных технологий и экспертами в предметной области бизнеса. Это возможно посредством составления различных моделей, отражающих БП и понятных всем участникам проекта. Одновременно модель должна служить

© И. В. Ананьев, Е. Г. Серова, 2008

для формализации и документирования существующего состояния дел и изучения возможностей улучшения работы.

Наиболее известной и распространенной методологией описания биз-нес-процессов1 является предложенная в 70-х гг. XX в. Д. Россом (D. Ross) методология структурного анализа SADT (Structured Analysis and Design Technique). На основе SADT был принят стандарт моделирования бизнес-процессов IDEF0 [Маклаков, 2003]. Но является ли тезис об универсальности этой методологии (провозглашаемый во многих публикациях по этой теме) оправданным? Чтобы ответить на этот вопрос, необходимо рассмотреть степень применимости IDEF0 для описания БП при решении различных задач. Таким образом, цель данной статьи — выделить ту область (те области), где IDEF0 выступает действительно лучшим инструментом.

ОБЛАСТИ ПРИМЕНЕНИЯ НОТАЦИИ IDEF0

При помощи нотации IDEF0 можно описать почти любые бизнес-процессы2. Но из этого не следует, что все БП нужно описывать именно этим способом. Необходимо подчеркнуть, что некоторые нотации являются инструментами для решения определенных задач, в противоположность иллюстрациям, которые инструментами не являются. Например, инструментальными нотациями являются графики PERT (в терминах этой нотации выполняются поиск и оптимизация критического пути), машиностроительные чертежи (разработка технологии и материальных нормативов), электрические схемы (расчет токов, напряжений и т. д.), фондовые чарты (технический анализ). Очевидно, что нотации-инструменты должны быть стандартизированы по наиболее принципиальным характеристикам (речь идет не о том, как изображать события в PERT-диаграммах — кружочком или прямоугольником, это как раз не имеет значения). Что касается остальных (неинструментальных) нотаций, то они могут служить лишь для передачи впечатления, т. е. являются интуитивно понятными иллюстрациями к содержательным материалам (текстам, таблицам и т. п.), и в стандартизации не нуждаются.

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

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

2 Термин «бизнес-процесс» можно понимать более широко, как любое выстраивание или преобразование бизнеса. Но в данном случае нас интересует более узкая трактовка, связанная с применением нотации IDEF0.

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

Далее мы предлагаем выделить четыре области, имеющие непосредственное отношение к менеджменту организации, в которых используется описание БП, и оценить ГОЕБО с точки зрения пригодности в качестве инструмента для решения конкретных задач управления. Первые две области относятся к бизнес-консалтингу, а остальные две — к 1Т-консалтингу (рис. 1):

1) построение и оптимизация производственных процессов3;

2) организация (оптимизация) управленческой деятельности;

3) описание работы пользователей как необходимый этап проектирования корпоративных систем;

4) описание функциональности КИС.

Описания бизнес-процессов

Бизнес-консалтинг

Организация (оптимизация) производственных процессов

Организация (оптимизация) управленческих процедур

ГГ-консалтинг

Описание работы пользователей

Описание функциональности КИС

Рис. 1. Четыре области использования IDEF0 для описания БП

ПОСТРОЕНИЕ И ОПТИМИЗАЦИЯ ПРОИЗВОДСТВЕННЫХ ПРОЦЕССОВ

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

3 Производственные процессы в данном случае понимаются в широком смысле, включая в них не только материальное производство, но и предприятия, занимающиеся оказанием услуг, R&D, финансовой деятельностью, а также практически любые другие предприятия, процессы в которых устоялись. Консалтинг рассматривается не как консультирование, а как любая экспертная или проектная деятельность в соответствующих областях. При такой расширенной трактовке названные области покрывают практически все применения IDEF0 диаграмм в управлении предприятием.

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

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

Материалы, комплектующие, услуги (материальные объекты или изменения в материальных объектах)

Инструкции, технологии, приказы

_1_

Производственная операция

П1

т

Изделия,

комплектующие,

услуги

(материальные объекты или изменения в материальных объектах)

Оборудование, сотрудники

Рис. 2. Использование ШЕБ0 для описания производственных процессов

Оптимизация производственных процессов может проводиться с целью либо повышения качества продукции, либо снижения материальных, трудовых, временных затрат [Ойхман, Попов, 1997; Рубцов, 2001].

Пример подобного применения описаний БП представлен в работе [Роттер, Шук, 2005]. В ней решается задача настройки производственного бизнес-процесса в самой простой постановке — однопродуктовой однопо-точной линии. Но как быть, если мы имеем дело с реальным машиностроительным производством, в котором номенклатура исчисляется тысячами наименований? Неужели нужно разрабатывать БП для каждого изделия?

Использование ГОЕБ0 для анализа и оптимизации производственных процессов в ряде случаев не проводит к желаемому результату. Для этого есть множество известных научных направлений: линейное программирование, теория расписаний, теория массового обслуживания, дискретное моделирование, оптимизация РЕИТ-сетей. У каждого из них своя система понятий и своя нотация.

ГОЕБ0-диаграммы не всегда способны передать сущность производственных процессов. Легко можно привести примеры того, как технологические усовершенствования, радикально изменяющие экономические показатели производственных процессов, никак не отражаются на диаграммах. И наоборот, по диаграмме, невозможно понять, существуют ли резервы

для улучшения БП. Основная причина заключается в том, что семантика изображения диаграмм не формализована4, а технологические ограничения не отражаются в диаграммах стандарта ГОЕБО5.

ОРГАНИЗАЦИЯ (ОПТИМИЗАЦИЯ) УПРАВЛЕНЧЕСКОЙ ДЕЯТЕЛЬНОСТИ

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

При рассмотрении задач этого класса входами и выходами активностей являются информационные объекты, управлением — распоряжения, резолюции, справочники, ценники и т. п. информационные сущности, механизмами выступают сотрудники и КИС (или ее отдельные подсистемы). Активности представляют собой процедуры по преобразованию информационных объектов, причем все эти процедуры являются невидимыми для клиента и не затрагивают интересов клиента напрямую (рис. 3).

Инструкции, справочники, приказы, резолюции (информационные объекты)

Бумажные или электронные документы (информационные объекты)

1

Управленческая процедура П2

т

Сотрудники и КИС

Бумажные

или электронные

документы

(информационные

объекты)

Рис. 3. Использование ШЕБО для описания процессов управления

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

4 Рассмотрим простейшую ШЕБО-диаграмму:

^ Активность 1 ^ Активность 2 ^ На входе в Активность 1 — партия деталей. На выходе — партия деталей. Можно ли утверждать, что эти активности работают строго поочередно? Или иногда они работают одновременно? Ни того, ни другого утверждать нельзя. ШЕБО допускает обе интерпретации. Но как тогда сравнивать варианты организации БП? По какому критерию их оптимизировать?

5 Ограничение на пропускную способность трубопровода просто негде отразить.

Здесь применение IDEF0 намного уместнее, чем в предыдущем случае. Объект и результат (входы и выходы) являются однородными (это информация). Технологические ограничения выражены более слабо. Иерархия описаний БП образуется легко и естественно (процедура принятия решения распадается на отдельные действия, пакет документации — на документы и отдельные реквизиты).

Автоматически оптимизация таких БП не всегда возможна по тем же причинам, что и IDEF0-описание производственных процессов: семантика процессов не формализована и на IDEF0-диаграммах не отражаются количественные характеристики рассматриваемых процессов, но, по крайней мере, на них можно увидеть результаты этой оптимизации. Справедливости ради стоит отметить существование точки зрения, согласно которой такие описания БП могут быть очень полезны [Калянов, 1999]. Например, один из признанных специалистов в области бизнес-моделирования Г. М. Калянов считает, что достижима цель автоматической генерации спецификаций БП, их анализ и верификация. В своей статье он приводит ряд принципов, на которых базируется спецификация бизнес-процесса [Калянов, 2001]. Предполагается также, что в состав описания процесса входят дополнительные данные: рабочие характеристики процессов (время выполнения, ресурсозатраты, количество продукции в единицу времени и т. п.), распределение частоты и интенсивности каждого из потоков, характеристики состояний, которые достижимы каждым из процессов, информация по допустимости переходов между состояниями и т. д.

ПРИМЕНЕНИЕ IDEF0 В IT-КОНСАЛТИНГЕ

Теперь, когда рассмотрены первые две области, относящиеся к направлению бизнес-консалтинга, необходимо остановиться на следующих двух областях применения нотации IDEF0. Прежде чем сделать это, дадим общие характеристики всего направления в целом. В IT-консалтинге можно выделить две области применения описания БП: во-первых, управленческих БП предприятия, которые взаимодействуют с КИС (существующей или проектируемой); во-вторых, процессов, протекающих в КИС, а также их взаимодействия с внешним (человеческим, внемашинным) миром (рис. 4). Между этими областями существует принципиальное различие, и игнорировать его нельзя, потому что фактически речь идет о разных объектах моделирования.

Необходимо понимать, что процессы, протекающие в КИС и в управленческой среде, относятся к двум разным мирам, которые разделены интерфейсами пользователя [Hammer, Champy, 1993]. В IDEF0-описаниях бизнес-процессов человеческого мира корпоративная информационная система выступает в форме механизмов поддержки активностей. В бизнес-процессах КИС человеческий мир выступает как поставщик входов, выходов и сигналов управления.

Субъектами деятельности являются пользователи, которые обмениваются документами, сообщениями, управленческими воздействиями

КИС — это механизм, реализующий выполнение процедур пользователей

Заказ от клиента

КИС: планирование запуска заказа

н

й

¿и

Субъектами деятельности являются подсистемы, задачи, программы корпоративной информационной системы

Пользователи — это внешний мир, с которым КИС обменивается документами

Рис. 4. Две области использования ГОКИ) в 1Т-консалтинге

Теперь, когда общая картина ясна, можно рассмотреть перспективы применения ГОЕБО-диаграмм для описания процессов, происходящих в среде пользователей КИС и в самой КИС.

ОПИСАНИЕ РАБОТЫ ПОЛЬЗОВАТЕЛЕЙ ПРОЕКТИРУЕМОЙ КОРПОРАТИВНОЙ СИСТЕМЫ

Это частный случай области, рассмотренной выше (описание управленческих процедур). Его специфичность состоит в том, что в данном случае в ГОЕБО-диаграммах не упоминаются функции, не имеющие отношения к корпоративной информационной системе. Например, в функциональности проектируемой КИС не отразится тот факт, что особо крупные платежи дополнительно акцептуются лично финансовым директором (если это делается без участия КИС) (рис. 5).

Инструкции, справочники, приказы, резолюции (информационные объекты)

Бумажные _^_1 Бумажные

или электронные документы (информационные объекты)

Действие пользователя

ИЗ

}

или электронные документы (информационные объекты)

КИС

Рис. 5. Использование ШЕБО для описания поведения пользователя

Наиболее оптимистические ожидания от применения ГОЕБО в 1Т-кон-салтинге предполагают автоматическую генерацию программного кода по ГОЕБ-описаниям. Но необходимо иметь в виду, что пользователь КИС и сама КИС — это разные объекты. Описания поведения пользователей несут слишком мало информации об объекте проектирования (корпоративной системе). Наивно ожидать от механического генератора кода успешного создания КИС на основе анализа описания поведения пользователя. Впрочем, если «генератором кода» выступает обычный программист, то ему этой информации тоже будет недостаточно. Вопрос о генерации кода имеет смысл рассматривать только в контексте использования ГОЕБО для описания поведения КИС.

Существует еще одно соображение в пользу описания БП поведения пользователей. Всем известно, что перед внедрением КИС следует навести порядок в БП. В результате внедрения КИС бизнес-процессы неизбежно изменятся, и этими изменениями нужно управлять. Однако идея о том, что сначала должно быть составлено описание процессов «аз 18», затем «аз Ш Ье», на практике довольно часто выглядит не так.

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

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

Трансформация бизнес-процессов при внедрении КИС

Рис. 6. Описания бизнес-процессов, рассматриваемые при внедрении КИС

Фактически мы имеем дело не с двумя системами бизнес-процессов, а с четырьмя. Нужно ли каждый из них описывать детально? Как использовать эти описания? Что конкретно должны включать эти описания, чтобы способствовать решению задачи? С какой степенью детализации их нужно описывать, чтобы разработка моделей не стала чрезмерно трудоемкой? С этими вопросами сталкиваются компании при внедрении КИС.

ОПИСАНИЕ ФУНКЦИОНАЛЬНОСТИ КИС

В этой четвертой области применения ГОЕБ0-диаграмм описывают ро-цессы, протекающие внутри компьютерной системы. Такие описания нужны не только при проектировании систем (что происходит очень редко и только в соответствующих 1Т-компаниях), но и при выборе и внедрении КИС на любом предприятии (что имеет место значительно чаще).

6 Растиражированная идея о необходимости предварительно описать БП «как есть», а затем «как должно быть» частично пригодна, когда речь идет о разработке заказной системы.

Что будет типичной активностью здесь: построение отчета о прибыли, определение остатка материала на складе, проверка правильности параметров запроса пользователя и т. д.? Что будет входами и выходами: записи, файлы, отношения (relations) баз данных (БД), отчеты, сообщения и прочие вну-тримашинные информационные объекты?7 Таким образом, описания внутренних процессов в нотации IDEF0 вполне возможны, а техника декомпозиции диаграмм хорошо соответствует нисходящему подходу, который повсеместно применяется при проектировании программных комплексов (рис. 7).

Инструкции, справочники, приказы, резолюции (информационные объекты)

Записи, файлы, отношения БД, сообщения (внутренние информационные объекты)

1

Процедура КИС

П4

т

Записи, файлы, отношения БД, сообщения, отчеты

ПО более низкого уровня (СУБД, ОС и т. д.)

Рис. 7. Использование IDEF0 для описания поведения КИС

Представляется, что применение IDEF0 в качестве одного из основных технологических элементов при проектировании корпоративных систем неуместно.

Для обоснования этого тезиса сошлемся на одного из классиков программирования Никлауса Вирта и на его формулу:

Программы = Алгоритмы + Структуры данных.

Попробуем понять, какие компоненты описаний IDEF0 отвечают за ее «слагаемые».

А. М. Вендров, А. Н. Кальянов, А. В. Козлинский, В. Н. Лебедев справедливо отмечают, что практически во всех известных методиках проектирования программных систем используются три группы средств:

1) DFD (Data Flow Diagrams) или SADT-диаграммы, иллюстрирующие функции, которые система должна выполнять8;

7 Заметим, что в этом случае внемашинные процессы, а также производственные БП должны быть полностью удалены из ШЕБО-диаграмм.

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

2) ERD (Entity-Relationship Diagrams), моделирующие отношения между данными;

3) STD (State Transition Diagrams), моделирующие зависящее от времени поведение системы (аспекты реального времени) [Вендров; Калянов, Козлинский, Лебедев, 1997].

Проанализировав содержание всех трех описаний, мы вновь приходим к выводу, что материала для генерации кода недостаточно. ERD отвечают только за внешние структуры (БД, но никак не за структуру записей, классов и т. д.). А за алгоритмы вообще не отвечает никто. Ни IDEF0, ни DFD, ни STD не описывают алгоритмы в привычном нам понимании.

Теперь, не поднимая больше вопроса об автоматической генерации программного кода, мы вправе задать вопрос о том месте, которое занимает IDEF0 (а заодно и DFD) в процессе проектирования программных систем.

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

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

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

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

9 Профессиональные программисты давно не используют графические описания алгоритмов, считая их слишком громоздкими.

выводы

Таким образом, из четырех областей, наиболее часто упоминаемых в примерах по IDEF0 и в другой литературе, реальный практический интерес представляют две. Это — описание управленческих процедур и описание процедур пользователей КИС.

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

Литература

Вендров А. М. CASE-технологии. Современные методы и средства проектирования информационных систем [Электронный ресурс]. — Режим доступа: http:// www.citforum.ru/database/case/index.shtml Калянов Г. М. Как внедрить CASE в вашей организации? 1999 [Электронный ресурс]. — Режим доступа: http://www.pcweek.ru/themes/detail.php?ID=49984 Калянов Г. М. CASE: все только начинается // Директор информационной службы

(моделирование бизнес-процессов). 2001. № 3. Март. С. 16-18. Калянов А. Н., Козлинский А. В., Лебедев В. Н. Сравнительный анализ структурных

методологий // СУБД. 1997. № 5-6. С. 75-78. Маклаков С. В. Моделирование бизнес-процессов с AllFusion Process Modeler. М.: Диалог-Мифи, 2003.

Ойхман Е. Г., Попов Э. В. Реинжиниринг бизнеса: Реинжиниринг организаций и информационные технологии. М.: Финансы и статистика, 1997. Роттер М., Шук Дж. Учитесь видеть бизнес-процессы. М.: Альпина Бизнес Букс, 2005. Рубцов С. В. Уточнение понятия бизнес-процесс. В монографии «Целевое управление корпорациями», 2001 [Электронный ресурс]. — Режим доступа: http:// orrsv.narod.ru/Book/Book_3.htm#Refining_of_BP Hammer M., Champy J. Reengeneering the Corporation: A Manifesto for Business Revolution. London: Nicholas Brealey Publishing, 1993.

Статья поступила в редакцию 19 марта 2008 г.