Бизнес-процессы. Основные понятия. Теория. Методы - Шеер А.-В.

Автор: Шеер А.-В.

Теги: бизнес

ISBN: 5-88-661-022-7

Год: 1999

Похожие

Бизнес-процессы. Регламентация и управление.

Бизнес-процессы компании: построение, анализ, регламентация

Бизнес процессы в компаниях связи

Основные структуры и методы теории представлений

Текст

!|!Й
йВКЖжВ
яяяш#
llllii
' АгааеЖк Аж
иле^жая
•S5iS5Wa«s
,sr41®SX5
ввАА
1ВЯ1
vf

айЖИ®»ввЖЯВ«
ж
Я1Й

aSAtil
аМЙЙАТ
ИЖ®
1вМвИ1
Oil!
3|й®ЫЖ !, :ЖЖЙ Ж
iiillllll
®Wi;;7a:t«as7y;;;'

да;
Ж
SlilSilillfiillili
11в1Я;111ЯЖЯЙ1
;ЛЧ7{1'«53Э’ВИ;в®а'К'
lllllllllill
ЭДЖг!51а:‘«’,ач®£;Ж7-
К ВАШ® ЖАа
-Ай -Ж
“я.уда-ждаА^ ®MW® A ;
ж
Август-Вильгельм Шеер
Бизнес
процесс
Основные понятия
Теория
Методы
Перевод с английского
1 *" XJyidiJ
«(jSi
Важ
l|
<1ЙИЖ
♦ _
1
Вес
МетаТехнолоп
Москва, 19
ждада
Август-Вильгельм Шеер
: ' j '
Бизнес-процессы
^Основные понятия
Теория
Методы
Перевод с английского
Издание 2-е, переработанное и дополненное.
В книге представлены систематизированные знания по
,, теоретическим основам бизнес-процессов и бизнес-информатике.
Приведены различные подходы и методы описания и анализа
бизнес-процессов. Изложена концепция архитектуры бизнес-
инжиниринга (АБИ), которая представляет собой четко
сформулированную методологию проведения всего цикла работ по
совершенствованию бизнеса: от формирования стратегических
целей компании до подробнейшей спецификации проекта
информационной системы. Методология дана в аспекте новейших
достижений информационных технологий и тенденций их развития.
Описаны процедуры, значимые для каждого предприятия,—
реорганизация бизнес-процессов, сертификация по стандарту
качества ISO 9000-, управление корпоративными знаниями.
Книга будет интересна всем, кто так или иначе связан-с
управлением бизнесом и информационными технологиями.
August-Wilhelm Scheer
ARIS
Business Process
Frameworks
Second, Completely Revised
and Englarged Edition
With 94 Figures
Springer
Август-Вильгельм Шеер
Бизнес-процессы
Основные понятия
Теория
Методы
Издание 2-е, переработанное и
дополненное
Перевод с английского
Научная редакция
канд. техн, наук
Каменнова М. С.,
канд. хим. наук
Громов А. И.
Весть ~ МетаТехнология
Москва 1999
scan: The Stainless Steel Cat
Август-Вильгельм Шеер. «Бизнес-процессы. Основные понятия. Теория. Методы».
Издание 2-е, переработанное и дополненное. Пер. с англ.
Научная редакция и предисловие: канд. техн, наук Каменнова М. С., канд. хим. наук Громов А. И.
Переводчик: Михайлова Н. А.
Оригинал-макет: Каменное Н. Г.
ISBN 5-88-661-022-7
В книге представлены систематизированные знания по теоретическим основам бизнес-
процессов и бизнес-информатике. Приведены различные подходы и методы описания и
анализа бизнес-процессов. Изложена концепция архитектуры бизнес-инжиниринга
(АБИ), которая представляет собой четко сформулированную методологию проведения
всего цикла работ по совершенствованию бизнеса: от формирования стратегических целей
компании до подробнейшей спецификации проекта информационной системы. Методоло-
гия дана в аспекте новейших достижений информационных технологий и тенденций их раз-
вития. Описаны процедуры, значимые для каждого предприятия — реорганизация бизнес-
процессов, сертификация по стандарту качества ISO 9000, управление корпоративными
знаниями.
Книга будет интересна всем, кто так или иначе связан с управлением бизнесом и инфор-
мационными технологиями.
© Springer-Verlag Berlin Heidelberg, 1998 All rights reserved
- Изд. 2-е, переработанное и дополненное. - Berlin; Heidelberg; New York; Barcelona;
Budapest; Hong Kong; London; Milan; Paris; Singapore; Tokyo: Springer, 1998
© ОАО «Весть», ООО «МетаТехнология», 1999
перевод, предисловие, оформление
115446 Москва, Коломенский пр. 1а., тел.: (095) 115-6001, факс: (095) 112-2333
E-Mail: consulting@vest.msk.ru
Подготовлено к печати совместно с издательством АОЗТ «Просветитель»
ISBN 5-88-661-022-7
Издательство АОЗТ «Просветитель», 1999
Предисловие V
Предисловие к русскому
изданию
«.. не товары, а процессы их создания приносят
компаниям долгосрочный успех»
М.Хаммер, Д. Чампи «Реинжиниринг корпорации»
Предлагаемая вашему вниманию книга
представляет собой фундаментальный труд
по теории бизнес-процессов и бизнес-инфор-
матике. Таких книг очень мало, на русском
языке их просто нет. Как правило, публикуе-
мые по тематике бизес-процессов книги опи-
сывают успешный опыт отдельных западных
компаний в проведении проектов по совер-
шенствованию бизнес-процессов с неболь-
шими методологическими вставками, кото-
рые, безусловно, представляют немалый ин-
терес, но не дают читающему целостной
картины. Исключение составляет, может
быть, книга М.Хаммера, Д.Чампи «Реинжи-
ниринг корпорации». Книга Проф. Шеера
рассматривает проблематику бизнес-про-
цессов под другим углом - в ней представле-
на теоретико-методологическая основа этой
проблемы, причем в разрезе самых после-
дних достижений информационных техноло-
гий и тенденций их развития. Книга позволя-
ет составить целостную картину того, что же
такое бизнес-процесс, каково его наполне-
ние, как он связан с организационной струк-
турой предприятия, ролями отдельных со-
трудников, информационным обеспечением,
управлением знаниями.
Однако, прежде чем поделиться своим
впечатлением о книге, хотелось бы коснуться
всей «процессной» проблематики и пояснить,
почему эта тема так актуальна, особенно в
свете изменений, происходящих в экономике
России.
Экономическая ситуация в России и скла-
дывающиеся рыночные отношения требуют
очень серьезного пересмотра принципов и
механизмов управления на уровне каждого
предприятия. Сегодня система управления
практически всех предприятий имеет ярко
выраженную функциональную направлен-
ность (рис.А). Есть Руководитель, ему подчи-
няются ЗАМы по направлениям, под каждым
из них находятся подразделения, выполняю-
щие определенные функции.
В основе подобной организации управле-
ния лежит принцип разделения и специали-
зации труда Адама Смита, описанный в его
работе «Достояние народа», опубликован-
ной еще в конце XVIII века. Однако в нынеш-
них условиях этот подход управления ока-
зывается неэффетивным по следующим при-
чинам:
— функционально-ориентированная ор-
ганизация не стимулирует заинтересо-
ванность работающих в конечном ре-
зультате, поскольку системы оценки их
деятельности оторваны от результа-
тивности работы предприятия в целом.
Их видение происходящего чаще всего
не выходит за рамки подразделений, в
которых они работают, они не ориенти-
рованы на целевые задачи предприя-
тия. Монопольное положение каждой
службы внутри предприятия, приводя-
щее к тому, что работники этих служб
считают себя незаменимыми в органи-
зации, приводит к неоправданной и ча-
сто разрушительной конкуренции
между функциональными отделами и
подразделениями организации.
— при функциональном подходе главным
потребителем результатов труда ра-
ботника является его вышестоящий на-
чальник. Это означает, что каждый со-
знательно или подсознательно старает-
ся удовлетворить (или угодить)
начальнику, а не коллеге из соседнего
подразделения, а тем более клиенту.
При современных тенденциях клиент-
ной ориентации, когда клиент ~ «царь и
бог», такой подход сразу отбрасывает
предприятие на последние роли в кон-
курентной борьбе за доли рынка. Умес-
тно отметить, что начинать разговор о
клиентной ориентации предприятия, не
пройдя путь процессной ориентации, в
принципе можно, но стоимость подсоб-
ного подхода оказывается слишком вы-
сокой.
— большая часть реальных рабочих про-
цессов предприятия состоит из мно-
жества функций, т.е. выходит за рамки
отдельных подразделений. Однако в
функционально ориентированных
структурах чрезмерно усложнен об-
VI Предисловие
Рис.а. Обобщенная функционально-структурная схема традиционной
организации-предприятия
мен информацией между различными
подразделениями, что приводит к
большим накладным расходам, нео-
правданно длительным срокам выра-
ботки управленческих решений, и как
следствие потере клиентов. По подсче-
там аналитиков время взаимодей-
ствия между подразделениями разде-
ляется следующим образом: 20% - вре-
мя работы, 80% - передача
результатов следующему исполните-
лю. Попытки внедрения автоматиза-
ции в функционально ориентирован-
ных организациях (программа внедре-
ния АСУ 70-х годов) привели к
увеличению накладных расходов на
обеспечение деятельности без повы-
шения эффективности, а в ряде случа-
ев при снижении эффективности в не-
сколько раз.
иерархическая функциональная
структура неизбежно обладает еще
одним серьезным пороком - это фунда-
ментальный закон искажения инфор-
мации при ее передаче или закон ин-
формационной энтропии. Управляю-
щая информация передается в
основном с помощью естественного
языка, а любой естественный язык об-
ладает информационной избыточнос-
тью. Русский язык обладает 32% ин-
формационной избыточностью, что
больше многих других европейских
языков. В свою очередь информацион-
ная избыточность является источни-
ком искажения сути сообщения, т.е.
при передаче через четыре уровня уп-
равления информации мы имеем высо-
кую вероятность получения около
100% искажений от исходного сообще-
ния. По этой причине погибли и распа-
лись все великие иерархические им-
перии от древнейших времен до сегод-
няшних дней.
Сама по себе функциональная ориента-
ция управления не содержит в себе ни види-
мого конфликта, ни противоречий и вполне
Предисловие VII
укладывается в большинство форм органи-
зационного анализа, восходящих к Ньюто-
новским воззрениям на способы достижения
результатов в работе, т.е. выполнению ли-
нейной последовательности заданий. На-
пример, для военных организаций такая
четко определенная иерархическая функ-
циональная структура управления оправ-
дана обязательными (уставными) отноше-
ниями подчиненности и теми конкретными
целями, которые перед ними ставятся.
Вместе с тем, еще раз хочется подчерк-
нуть, что реальная деятельность (т.е. дея-
тельность, приносящая дополнительное ка-
чество) не осуществляется вдоль линейно-
функциональной иерархии, т.к. здесь имеют
место только разрешения и приказы. Она
пронизывает предприятие в виде набора биз-
нес-процессов, которые в большинстве своем
никем не управляются и никто за них не от-
вечает, потому что бизнес-процессы не опи-
саны и не документированы.
Введем несколько определений из «про-
цессной» терминологии.
Коммерческие и некоммерческие органи-
зации производят продукты или предостав-
ляют услуги, поэтому они могут рассматри-
ваться как производственные системы. В
свою очередь, производственные системы со-
стоят из групп взаимонезависимых компо-
нент, работающих вместе для достижения
конечной цели. Эти компоненты определяют-
ся как процессы. Таким образом, производ-
ственная система состоит из группы
взатмосвязанных процессов, которые обес-
печивают достижение целей организации.
Процессы - это связанный набор повторя-
емых действий (функций), котоые
преобразуют исходный материал и/или ин-
формацию в конечный продукт (услугу) в со-
ответствии с предварительно установленны-
ми правилами.
Различают основные и вспомогательные
процессы. Основные процессы - это те, кото-
рые добавляют качество, вспомогательные
процессы формируют инфраструктуру орга-
низации. Примерами процессов могут быть
процессы сбыта и снабжения, процесс разра-
ботки нового изделия и вывода его на рынок,
процесс обслуживания клиентов. Лозунг не-
фтяных компаний «от скважины до бензо-
заправки» означает ничто иное как бинес-
процесс макро-уровня, охватывающий весь
технологический цикл.
Как правило, не существует стандартного
списка бизнес-процессов, каждое предпри-
ятие должно разрабатывать свой собствен-
ный перечень основных бизнес-процессов.
Идея представления организации в виде
набора бизнес-процессов, а управления ее
деятельностью - как управление бизнес-
процессами стала распространяться в кон-
це 80-х годов. Лучшие компании мира нача-
ли решать для себя эти задачи и на практи-
ке доказали важность, эффективность,
экономичность и прогрессивность перехода
на клиентно-ориентированное производ-
ство и процессно-ориентированную струк-
туру управления производством. Эта тен-
денция привела к включению управления
процессами в критерий для получения са-
мых престижных наград в области управле-
ния бизнесом.
В настоящее время компании мирового
уровня используют методы управления про-
цессами в рамках реализации стратегии сис-
темного управления качеством. При исполь-
зовании процессно-ориентированного подхо-
да в управлении сам процесс становится
распределенным регулятором качества со-
ставляющих его процедур, будучи ориенти-
рованным на реального рыночного клиента.
Выделение бизнес-процессов, их анализ и
последующее совершенствование - колос-
сальный резерв для повышения конкурент-
носпособности компании и эффективности ее
работы. Среди основных преимуществ такого
подхода можно выделить простоту проведе-
ния оптимизации как самих процессов, с точ-
ки зрения их организации, синхронизации,
взаимосогласованности, так и ресурсов, по-
требляемых процессами, особенно это каса-
ется человеческих ресурсов. Кроме того, ста-
новится очевидность управления, нацелен-
ного на конечный результат, который
оценивается потребителем - клиентом про-
цесса.
В качестве примеров направлений работ
по совершенствоанию процессов можно на-
звать:
— Совершенствование процесса управ-
ленческого учета и финансового плани-
рования с целью быстрого доступа к
критически важной информации.
— Сокращение сроков освоения новых ви-
дов продукции и вывода ее на рынок.
— Сокращение цикла обслуживания кли-
ентов.
Различают постепенное (пошаговое) и
VIII Предисловие
кардинальное совершенствования. Посте-
пенное совершенствование — это те измене-
ния в процессе, которые требуют небольших
капиталовложений или вообще их не требу-
ют. Кардинальное совершенствование — су-
щественные изменения процесса; часто они
сопровождаются переходом на новую тех-
нологию, фундаментальными переменами в
организационной структуре и новым взгля-
дом на весь процесс. Этот тип изменений по-
лучил название «реорганизация».
Необходимость совершенствования биз-
нес-процессов привела к созданию методоло-
гии управления процессами (МУП), которая
включает шесть основных шагов:
Шаг 1. Определение владельца(ев) про-
цесса
Шаг 2. Описание границ и интерфейсов
процесса
Шаг 3. Описание самого процесса с помо
щью программного инструмента
рия
Шаг 4. Установка точек контроля за
процессом
Шаг 5. Измерение показателей процес-
са в точках контроля
Шаг 6. Анализ полученной информации
и предложения по совершенство
ванию
С точки зрения анализа и оптимизации
бизнес-процессов, МУП и соответствующие
инструментальные средства позволяют вы-
являть:
— дублирование функций,
— узкие места,
— затратные центры,
— качество выполнения отдельных one
раций,
— избыточные операции,
— отсутствие или неполноту информа-
ции,
— возможности автоматизации
— возможности внедрения систем управ-
ления качеством
— возможности сертификации по ISO
9000 (ISO 9002 или ISO 9004-1)
Одна из основных причин, диктующая не-
обходимость перехода на процессную ориен-
тацию управления производством, заключа-
ется в изменившихся возможностях способов
и методов поддержки принятия решения в
современном мире, т.е. в доступности всевоз-
можных средств информационного обеспе-
чения деятельности.
Пятьдесят лет назад и ранее, когда вы-
числительные средства поддержки инфор-
мационной деятельности не были доступны,
существование функционально-ориенти-
рованного подхода к управлению было не
только оправдано, но и единственно возмож-
ным решением в управлении сложными
объектами. Подобный подход позволяет де-
композировать деятельность по функцио-
нальному принципу и обеспечив согласова-
ние между функциями соответствующими
стандартами осуществлять осознанное уп-
равление. Проблемой, не всегда видимой,
здесь является наличие в исполнительных
механизмах человека, скрытого иерархией
структуры и спинами начальников. Далее
начинают всегда и без исключения работать
законы Паркинсона.
Эффективное существование функцио-
нально-ориентированного управления тре-
бует непрерывного, жесткого и циничного
управления персоналом. В современном об-
ществе подобный подход неприемлем (и хо-
телось бы в это верить). С другой стороны,
при использовании средств поддержки ин-
формационной деятельности возникает воз-
можность охватить всю систему целиком,
рассмотрев составляющие ее процессы как
единое целое, и введя контур исполнительно-
го управления на передний план. В этом слу-
чае, человек как исполнительный ресурс сис-
темы оказывается непосредственно вовлечен
в процесс, подчиняясь его законам и логике, и
отчитываясь не конкретному человеку со
своими слабостями и проблемами, а процес-
су, наполненному равнозначными и равноот-
ветственными элементами-людьми исполнения.
В результате система выравнивает требо-
вания ко всем участникам процесса, требуя
от них равного качества на всех участках, во
всех процедурах, становясь саморегулирую-
щей с точки зрения качества структурой. В
данном случае, ключевым фактором успеш-
ного существования подобной системы явля-
ется использование совершенной системы
управления предприятием (СУП), обеспечи-
вающей оперативной информацией участни-
ков процесса, сам процесс с технологической
точки зрения и руководителей предприятия.
Количество уровней управления сокращает-
ся до двух, численность управленческого со-
става уменьшается по мере стабилизации
процесса, резко возрастает эффективность
Предисловие IX
процесса и его управляемость, образуется
гибкость и настраиваемость управления.
Однако, еще раз следует подчеркнуть, что
внедрение самой совершенной системы уп-
равления предприятием (СУП) в функцио-
нально-ориентированную структуру не
только не принесет ожидаемого эффекта, а
наоборот увеличит накладные расходы и, как
правило, снизит общую эффективность де-
ятельности.
Из всего сказанного следует вывод о том,
что переход на процессную ориентацию - та
неизбежность, с которой придется столк-
нуться практически каждому среднему и
крупному российскому предприятию, если
оно хочет не только выжить, но и успешно
развиваться.
Чем же полезна в этом отношении книга
профессора Шеера?
В книге представлены систематизирован-
ные знания по теоретическим основам биз-
нес-процессов и бизнес-информатики. Дает-
ся базовая модель бизнес-процесса, описы-
ваются субъекты прцесса и все виды потоков,
проистекающих в рамках бизнес-процесса.
Эта базовая модель имеет определяющее
значение при дальнейшем изложении двух
концепций - Архитектуры Интегрированных
Информационных Систем (АРИС) и Архи-
тектуры Бизнес-Инжиниринга (АБИ). Кон-
цепция АРИС - это методология информаци-
онных систем, концепция АБИ - представля-
ет собой четко сформулированную
методологию проведения всего цикла работ
по реформированию (совершенствованию)
бизнеса: от формирования стратегических
целей компании до подробнейшей специфи-
кации проекта информационной системы.
Причем, работать по этой методологии мож-
но независимо от того, на каком этапе начи-
нается или заканчивается проект - необходи-
мо ли только выделить и описать бизнес-про-
цесс, или провести его анализ и привязку к
организационной структуре, или спланиро-
вать развертывание информационной систе-
мы на каждом рабочем месте с учетом имею-
щегося аппаратного обеспечения (компьюте-
ра) и лицензий на программное обеспечение.
Особым достоинством книги является то,
что все теоретические и методологические
положения бизнес-информатики излагаются
в разрезе новейших информационных техно-
логий - управление потоками работ
(workflow), Интернет, управления знаниями,
объектно-ориентированного моделирования
на базе языка UML и т.д., а также уже имею-
щихся архитектурных решений от различ-
ных производителей, университетов и науч-
ных центров.
Последняя глава книги описывает раз-
личные процедуры, выполнение которых в
компании, претендующий на серьезные по-
зиции на рынке, является критически значи-
мым. Это процедуры реинжиниринга биз-
нес-процессов, сертификации компании в
соответствии со международным стандар-
том качества ISO 9000, управления корпо-
ративными знаниями. Деятельность в этих
направлениях нетрадиционна для российс-
ких предприятий, поэтому незнание этих
процедур вполне оправдано. В книге они
представлены
настолько ясно и четко, что их описание мо-
жет служить практическим руководством
при реализации в рамках реального пред-
приятия.
Несомненно, книга Проф. Шеера будет ин-
тересна всем, кто так или иначе связан с уп-
равлением бизнесом и информационными
технологиями.
В заключении хотелось бы поблагодарить
тех, кто принимал участие в подготовке рус-
ского издания книги: прежде всего, перевод-
чицу Наталью Александровну Михайлову,
талант и переводческий опыт которой позво-
лил перевести книгу за очень короткий срок
и с высоким качеством, редактора русского
языка Евгению Викторовну Крестьянинову,
Николая Каменнова, ответственного за ори-
гинал-макет книги, а так же дизайн-студию
«АСК» за помощь и ценные советы при офор-
млении книги.
Москва, май 1999 г.
Мария Каменнова, канд. тех. наук
Александр Громов, канд. хим. наук
X
Предисловие
Предисловие ко второму
изданию
С момента первой публикации в 1992 году
книга «Архитектура интегрированных ин-
формационных систем» (Architecture of
Integrated Information Systems) пользуется
огромной популярностью. Использование
бизнес-моделей для документирования стан-
дартного программного обеспечения дало
блестящие результаты. Программный про-
дукт ARIS Toolset, разработанный фирмой
IDS Prof. Scheer GmbH на базе концепции
ARIS, сегодня занимает лидирующее поло-
жение на мировом рынке инструментальных
средств для инжиниринга бизнес-процессов.
ARIS Toolset нашел применение в универси-
тетах США, Европы, Южной Африки, Бра-
зилии и стран Азиатско-Тихоокеанского ре-
гиона, предоставив в распоряжение научных,
исследовательских и проектно-конструктор-
ских учреждений, занимающихся вопросами
корпоративной организации и информацион-
ных технологий для бизнеса, современный
инструмент для инжиниринга бизнес-про-
цессов.
Бурное развитие в области информацион-
ных технологий (ИТ), происшедшее с момен-
та выхода в свет первого издания этой книги,
привело к появлению такой массы новых ас-
пектов и такого количества дополнительной
информации, что мы сочли необходимым
полностью переработать содержание книги,
разбив ее на две:
«Бизнес-процессы. Основные понятия.
Теория. Методы» (ARIS ~ Business Process
Frameworks) и « Моделирование бизнес-
процессов» (ARIS — Business Process Modeling).
Каждая книга рассчитана на свой контин-
гент читателей. Если первая предназначена
для тех, кого интересуют вопросы проекти-
рования бизнес-процессов, стандартных
приложений и их аспекты, связанные с биз-
несом, то вторая подробно знакомит с мето-
дами моделирования и информационными
технологиями.
Об этой книге
В книге «Бизнес-процессы. Основные по-
нятия. Теория. Методы» мы используем
концепцию ARIS для описания бизнес-про-
цессов. ARIS - Архитектура бизнес-инжи-
ниринга (АБИ) представляет собой модель
для управления бизнес-процессами.
Еще один новый элемент, представлен-
ный в настоящем издании, — описание пото-
ков выходов. Концепция АБИ включает но-
вые концепции программного обеспечения,
такие как системы workflow, компонентное
программное обеспечение и рабочие про-
странства. Вместо метода сущность-отно-
шение мы используем теперь для описания
метамоделей унифицированный язык моде-
лирования (UML).
Поначалу казавшаяся многообещающей
концепция AD/CYCLE не оправдала ожида-
ний. В связи с тем, что компания IBM отказа-
лась от дальнейшего распространения этого
метода, в настоящем издании мы его больше
не рассматриваем.
Книга может заинтересовать менеджеров
по информационным технологиям, консуль-
тантов, преподавателей и студентов, занима-
ющихся информатикой, бизнес-информати-
кой и родственными дисциплинами. Автору
было бы особенно приятно, если бы эта книга
стала дополнительным подспорьем для сту-
дентов, изучающих науку управления бизне-
сом, как учебное пособие по теории бизнеса,
ориентированной на ИТ.
Содержащиеся в книге иллюстрации
представлены в виде слайдов на Web-узле
по адресу:
http://www.iwi.uni-sb.de/lehre/aris-i/
(английские версии). Их разрешается ис-
пользовать при условии соблюдения авторс-
ких прав и со ссылкой на источник.
Я хотел бы выразить благодарность Крис-
тиану К. Тьюсу из «The Localizer» за скрупу-
лезный перевод текста на английский язык.
Я также благодарен Урсуле Маркус за коор-
динацию и правку перевода с немецкого на
английский, Франку Хаберманну — за тща-
тельное редактирование немецкой рукописи,
Натали Антерист и Йохену Кунце — за под-
готовку иллюстраций на английском языке и
проф. Томасу Галледжу из Университета
Джорджа Мейсона (шт. Вирджиния) — за
тщательную правку английской рукописи.
Неоценимую техническую помощь оказали
Маркус Болд, д-р Вольфганг Кремер, Мар-
кус Люциус, д-р Маркус Нюттгенс и Арнольд
Траут.
Саарбрюккен, Германия, июль 1998 г.
Август-Вильгельм Шеер
Предисловие XI
Классификация содержания
Написанные автором книги по инжини-
рингу бизнес-процессов образуют стройную
систему, которая представлена на рис. б.
Бизнес-информатика перекидывает мос-
тик между теорией бизнеса и информацион-
ными и коммуникационными технологиями,
устанавливая между ними двунаправлен-
ную связь. Информационные и коммуника-
ционные технологии следует анализировать
с точки зрения того, каким образом новые
технические процедуры позволяют реализо-
вать новые концепции приложений для биз-
неса. «Направление влияния» показано
стрелкой в левой части рис. б. В бизнес-ин-
форматике необязательно разбираться во
всем спектре информационных технологий—
достаточно знать, как применять сегмент, от-
вечающий за изменения в концепциях биз-
нес-приложений. В этой области бизнес-ин-
форматика играет особенно важную роль.
Стрелка в правой части рис. б иллюстри-
рует влияние потребностей бизнеса на разви-
тие информационных и коммуникационных
технологий.
Рис. б. Технический профиль книг автора
XII Предисловие
Оба направления отношения рассматри-
ваются в книге «Principles of Efficient
Information Management» («Принципы эф-
фективного управления информацией»), вто-
рое издание которой было опубликовано в
1991 году.
Важнейшие аспекты влияния информа-
ционных технологий на бизнес-процессы
рассматриваются в книге «С1М (Computer
Integrated Manufacturing) - Towards the
Factory of the Future» («С1М (компьютеризо-
ванное управление производством) - к заво-
ду будущего»), которая в 1994 году вышла в
третьем издании.
Обе книги посвящены инфраструктурам,
ориентированным на ИТ, и могут служить
надежным фундаментом для создания спе-
циализированных корпоративных систем.
В информационных системах эти инфра-
структуры воплощаются в инструменты ИТ.
Таким образом, информационные системы
становятся реальным мостиком между биз-
нес-приложениями и информационными
технологиями.
Концепция, изложенная в книге
«Architecture of Integrated Information
Systems - ARIS» («Архитектура интегриро-
ванных информационных систем - ARIS»),
была разработана для комплексного описа-
ния информационных систем. Первое изда-
ние этой книги выпущено в 1992 году. Второе
издание выходит в двух книгах:
ARIS - Business Process Frameworks (Биз-
нес-процессы. Основные понятия. Теория.
Методы) и ARIS - Business Process Modeling
(Моделирование бизнес-процессов).
В книге «Business Process Engineering -
Reference Models for Industrial Enterprises»
(«Инжиниринг бизнес-процессов - модели-
прототипы для промышленных предприя-
тий»), второе издание которой опубликовано
в 1994 году, предлагается интегрированная
информационная система для промышлен-
ных предприятий на базе концепции ARIS,
где используются модели функций, данных,
организации и процессов.
Коммерческая ценность описания инфор-
мационных систем снижается по мере разви-
тия и совершенствования технических
средств реализации. Одновременно ослабе-
вает и стабильность концепций, поскольку
стремительное развитие ИТ, как правило, не
может не сказываться на технической реали-
зации информационных систем. При подго-
товке книг к печати автор учитывал это об-
стоятельство в соответствии с «весовым ко-
эффициентом» каждого аспекта. На рис. б
этот «весовой коэффициент» представлен
треугольником.
Все книги автора изданы и на немецком
языке. Книга «Инжиниринг бизнес-процес-
сов» вышла в свет на китайском, а «С1М» пе-
реведена на португальский. В настоящее
время готовятся переводы на другие языки.
XIV Предисловие
Г.1.6. Имитация 65
Г.1.7. Обеспечение качества 66
Г.1.8. Хранилище процессов 68
Г.2. Планирование и управление бизнес-процессами 68
Г.2.1. Мониторинг процессов 70
Г.2.2. Составление графиков и регулирование мощностей 70
Г.2.3. Управленческие информационные системы (EIS) 71
Г.2.4. Непрерывное совершенствование процессов —
адаптивный инжиниринг бизнес-процессов 74
Г.З. Управление потоками работ (workflow) 77
Г.4. Прикладные системы 83
Г.4.1. Традиционные стандартные программные решения 83
Г.4.2. Компонентное программное обеспечение 88
Г.4.2.1. Объекты 88
Г.4.2.2. Бизнес-объекты 91
Г.4.2.3. Java-аплеты 91
Г.4.2.4. Проблемы стандартизации 92
Г.5. Рабочее пространство (инфраструктура) 99
Г.5.1. Концепция рабочего пространства 99
Г.5.2. Концепции реализации 101
Г.5.2.1. Рабочее пространство (инфраструктура) ARIS 101
Г.5.2.2. Рабочее пространство SAP 101
Г.5.2.3. SNI-ComUnity 103
Г.5.2.4. Проект San Francisco компании IBM 104
Г.5.3. Перспективы развития индустрии программного обеспечения 105
д. Моделирование стандартов в ARIS 108
Д.1. Общепринятые принципы моделирования 108
Д.2. Уровни моделирования 109
Д.З. Степени структурирования и детализации 115
Д-4. Варианты моделей 115
Предисловие XV
Е. Сравнение ARIS с другими концепциями 120
Е.1. Объектно-ориентированное моделирование 120
Е.2. Архитектура CIMOSA 126
Е.З. IFIP — Методология информационных систем 128
Е.4. Инфраструктура Захмана 129
Е.5. Результаты исследований Санкт-Галленского университета, Швейцария 131
Е.6. Другие архитектурные решения 133
Ж. Внедрение ARIS — практические процедуры 135
Ж.1. Реинжиниринг бизнес-процессов на базе модели ARIS 135
Ж.1.1. Корпоративный инжиниринг, ориентированный на процессы 135
Ж.1.2. Процедурная модель для оптимизации бизнес-процессов 136
Ж.1.3. Фазы оптимизации бизнес-процессов 137
Ж.1.3.1. Подготовительные меры 137
Ж.1.3.2. Стратегическое планирование 137
Ж.1.3.3. Анализ «как есть» 138
Ж. 1.3.4. Целевая концепция 138
Ж.1.3.5. Спецификация проекта 139
Ж.1.3.6. Реализация 139
Ж.1.3.7. Регулярный мониторинг и непрерывное совершенствование
процессов 140
Ж. 1.4. Резюме 140
Ж.2. Сертификация соответствия стандарту ISO 9000
на базе модели ARIS 140
Ж.2.1. Управление качеством (УК) на базе ARIS
с ориентацией на процессы 140
Ж.2.2. Процедурная модель для сертификации ISO 142
Ж.2.2.1. Процедурная модель: общее описание 142
Ж.2.2.2. Процедурная модель: преимущества 142
Ж.2.3. Фазы процедурной модели 143
Ж.2.3.1. Стратегическое планирование 143
Ж.2.3.2. Фаза подготовки к управлению качеством 143
Ж.2.3.3. Анализ системы управления качеством «как есть» 144
Ж.2.3.4 «ISO 9000 на базе ARIS»: целевая концепция 144
Ж.2.3.5. Структурирование системы УК 145
Ж.2.3.6. Применение и пересмотр систем УК 145
XVI Предисловие
Ж.2.3.7. Сертификация 146
Ж.2.3.8. Перспективы и инфраструктура:
системное управление качеством 146
Ж.З. Использование моделей ARIS для управления знаниями 146
Ж.3.1. Использование знаний для получения
конкурентных преимуществ 147
Ж.3.2. Процедуры реинжиниринга процессов знаний 147
Ж.3.3. Фазы реинжиниринга процессов знаний 149
Ж.3.3.1. Стратегическое планирование знаний 149
Ж.3.3.2. Анализ процесса обработки знаний «как есть» 149
Ж.3.3.3. Анализ состояния «как есть» 150
Ж.3.3.4. Целевая концепция обработки знаний 151
Ж.3.3.5. Организационно-кадровая концепция реализации 151
Ж.3.3.6. Концепция реализации средствами ИТ 151
Ж.3.3.7. Реализация концепций 152
Предисловие XVII
Список рисунков
Рис. 1а. Сравнение усилий по приобретению и внедрению
программного обеспечения в рамках жизненного цикла 6
Рис. 16. Способы сокращения организационных усилий 7
Рис. 2а. Диаграмма взаимодействия в бизнес-процессе «обработка заказа» 10
Рис. 25. Общая диаграмма взаимодействия на предприятиях 10
Рис. 3. Поток функций в бизнес-процессе «обработка заказа» 12
Рис. 4. Поток выходов в бизнес-процессе «обработка заказа» 13
Рис. 5. Поток информации в бизнес-процессе «обработка заказа» 15
Рис. 6. Объединенная модель бизнес-процесса «обработка заказа» 16
Рис. 7. Детальный фрагмент бизнес-процесса применительно
к событию «изготовление изделия» 18
Рис. 8. Факторы промышленного производства 20
Рис. 9. Классификация типов выхода и входа 21
Рис. 10. ARIS-модель бизнес-процесса 22
Рис. 11. Модель экземпляра бизнес-процесса обработки заказа (1-й уровень) 25
Рис. 12. Уровни абстракции в моделировании 27
Рис. 13. Общая ARIS-модель бизнес-процесса 28
Рис. 14а. Функциональная модель 31
Рис. 146. (Иерархическая) организационная модель 32
Рис. 14в. Модель данных 33
Рис. 14г. Модель выходов 34
Рис. 15. Модели ARIS 35
Рис. 16. Фазовая модель ARIS 37
Рис. 17. Здание ARIS и фазовая модель
39
XVIII Предисловие
Рис. 18. Здание ARIS, дополненное связями с корпоративной стратегией и управлением информацией 40
Рис. 19. Предварительная информационная модель ARIS 41
Рис. 20. ARIS-компоненты метауровня ARIS 42
Рис. 21. Один из вариантов диаграммы ЕРС для процедурной модели ARIS 46
Рис. 22. ARIS-модели «создания определения требований на уровне функциональной модели» 47
Рис. 23. Отношение между концепцией ARIS и информационной моделью ARIS 49
Рис. 24. Управление процессами на базе концепции здания ARIS 51
Рис. 25а. Модель продуктов и процессов 53
Рис. 256. Эквивалентные описания продуктов и процессов для различных услуг 53
Рис. 25в. Взаимосвязь между изменениями процесса и продукта 54
Рис. 26а. Фрагмент диаграммы ЕРС из модели-прототипа страхования, разработанной фирмой KPMG на базе ARIS 55
Рис. 266. Фрагмент диаграммы ЕРС из модели-прототипа R/3 56
Рис. 27. Топография знаний 57
Рис. 28а. Управление знаниями, представленное в виде диаграммы ЕРС 57
Рис. 285. Профили знаний в компании 58
Рис. 29. Вычисление стоимости производственного процесса 59
Рис. 30. Информационная база пооперационного исчисления стоимости в управленческих процессах 60
Рис. 31. Вычисление стоимости бизнес-процессов 61
Рис. 32. Некоторые количественные и качественные критерии эталонного сравнения 64
Рис. 33. Метод имитационного моделирования 64
Рис. 34. Уровни документирования в рамках TQM 65
Рис. 35а. Централизованное и децентрализованное моделирование в среде клиент-—сервер 66
Предисловие XIX
Рис. 356. Иллюстрация процесса, дополненная мультимедийными элементами 67
Рис. 36. Мониторинг процессов 69
Рис. 37. Составление графика бизнес-процесса
(модель процедуры для реализации программного обеспечения) 71
Рис. 38. Планирование мощностей в бизнес-процессе 72
Рис. 39. Отчетность по отклонениям в управлении бизнес-процессами 74
Рис. 40. Реинжиниринг и непрерывное совершенствование 75
Рис. 41. Различные типы моделей 76
Рис. 42. Метамодель контроля версий модели 77
Рис. 43. От модели бизнес-процесса — к реальной процедуре 78
Рис. 44. Экран системы workflow (пример использования буферов обмена) 79
Рис. 45. Структура процесса до и после внедрения коллективной организации работ 80
Рис. 46. Различные степени структурирования процессов workflow 81
Рис. 47. Модель-прототип, разработанная WfMC 81
Рис. 48. Типы и экземпляры бизнес-процесса 82
Рис. 49. Связь между объектом-типом и объектом-экземпляром на мета-уровне 83
Рис. 50. Индивидуализация моделей-прототипов 84
Рис. 51. Интерактивное построение бизнес-процесса и настройка стандартной программы 86
Рис. 52. Объектно-ориентированное представление процесса «обработка заказа» 89
Рис. 53. Бизнес-объекты в примере «обработка заказа» 90
Рис. 54. Связывание аплетов со зданием ARIS 93
Рис. 55. Архитектура управления объектами 94
Рис. 56. Бизнес-объект SAP 95
Рис. 57. Бизнес-компоненты 96
Рис. 58. Встраивание общих бизнес-объектов 97
XX Предисловие
Рис. 59. Рабочее пространство с взаимозаменяемыми компонентами 98
Рис. 60. Промышленная производственная система 99
Рис. 61. Информационная система, управляемая workflow 100
Рис. 62. Архитектура рабочего пространства ARIS 102
Рис. 63. Компоненты SAP Business Engineer 103
Рис. 64. Архитектура SNI ComUnity 104
Рис. 65. Проект San Francisco компании IBM 105
Рис. 66. Уровни моделирования ARIS ПО
Рис. 67. Стандарт администрирования модели в ARIS Toolset 111
Рис. 68. Таблица типов объектов 112
Рис. 69. Таблица прикладных объектов 112
Рис. 70. Таблица типов объектов, дополненная типами экземпляров 113
Рис. 71. Таблица прикладных объектов, дополненная типами экземпляров 113
Рис. 72. Структурированность модели 114
Рис. 73. Иерархическое представление с помощью ARIS различных уровней модели-прототипа 116
Рис. 74. Иерархия модели SAP 117
Рис. 75. Символическое представление подмодели и полной модели 117
Рис. 76. Примеры инжиниринговых решений и их последствия 118
Рис. 77. Последствия инжиниринговых решений 118
Рис. 78. Инструменты моделирования 121
Рис. 79. Диаграмма действий и потоков объектов 122
Рис. 80. Представление процесса «обработка заказа» (см. рис. 3) в виде диаграммы действий и потоков объектов 124
Рис. 81. Архитектура моделирования CIMOSA (куб CIMOSA) 125
Рис. 82. Типы моделей в архитектуре IFIP 127
Рис. 83. Архитектура Захмана 130
Рис. 84. Процедурная модель для объектного моделирования методом SOM 131
Рис. 85. Концепция АИС, представленная в виде «волчка» 132
Предисловие XXI
Рис. 86. Переориентация с функций на процессы 134
Рис. 87. Процедурная модель для оптимизации бизнес-процессов 136
Рис. 88. х Диаграмма ЕРС для бизнес-процесса «обработка заказа клиента» 137
Рис. 89. Элементы ISO 9001 139
Рис. 90. Предварительная процедурная модель
ARIS для сертификации ISO 141
Рис. 91. Фазы процедурной модели, представленные в виде
диаграммы цепочки добавленной стоимости 142
Рис. 92. Модели ARIS для управления качеством 143
Рис. 93. Предварительная процедурная модель ARIS
для реинжиниринга процессов знаний 148
Рис. 94. Моделирование обработки знаний 150

Преимущества ARIS для пользователя
1
А. Преимущества ARIS для
пользователя
Аббревиатура ARIS расшифровывается
как «Архитектура интегрированных инфор-
мационных систем» («Architecture of
Integrated Information Systems»). Понятие
«архитектура» обычно используется в строи-
тельстве. В области информационных техно-
логий (ИТ) оно служит для описания:
— их типа,
— функциональных свойств,
— взаимоотношений между отдельными
«кирпичиками» информационной сис-
темы.
Термин «архитектура» широко употреб-
ляется в концепциях ИТ. Некоторые специа-
листы, в частности Крцмар (Кгстаг
Informationssystem-Architekturen. 1990, с. 396)
и Штрунц (Strunz. Informations- and
Kommunikationssysteme. 1990, с. 441), пыта-
лись этимологически объяснить перенос это-
го понятия из области строительства в сферу
ИТ. Однако, по мнению автора этой книги,
дело здесь не столько в этимологии, сколько в
разговорном жаргоне. В области информаци-
онных технологий термин «архитектура», ча-
сто встречающийся в американских публи-
кациях, прочно ассоциируется с такими по-
нятиями, как планирование, регламентация,
структуризация и координация деятельнос-
ти деловых партнеров. Все эти понятия ти-
пичны для информационных систем. В таком
значении термин «архитектура» употребля-
ется также для описания аппаратных систем
и баз данных (Lockemann, Dittrich.
Architektur von Datenbanksystemen. 1987, c. 87).
В первом издании этой книги речь шла о
применении архитектуры ARIS к разработке
инфраструктуры для комплексного описания
(моделирования) автоматизированных ин-
формационных систем — от определения
требований до описания реализации. Мы кон-
центрировали внимание прежде всего на ин-
формационных системах и на их роли в под-
держке бизнес-процессов.
Сегодня, когда связь информационных
технологий с бизнес-процессами стала еще
теснее, роль моделирования бизнес-процес-
сов существенно возросла. Модели бизнес-
процессов, построенные на базе концепции
ARIS, находят применение даже в таких
классических областях ведения бизнеса, как
пооперационное исчисление стоимости, орга-
низация и реорганизация процессов, управ-
ление качеством. Это ведет к тому, что моде-
лирование бизнес-процессов все чаще рас-
сматривается как еще один аспект
управления бизнесом.
К сожалению, управленческая терминоло-
гия грешит рядом недостатков: зачастую она
неоднозначна, расплывчата, а подчас и от-
кровенно противоречива. По этой причине,
словесные формулировки как правило, ока-
зываются неадекватными при описании ха-
рактеристик информационных систем. С
другой стороны, математические языки,
предназначенные для описания вопросов,
связанных с принятием решений и планиро-
ванием в сфере управления бизнесом, хотя и
отличаются большей точностью и легче под-
даются проверке, подходят далеко не в каж-
дом случае.
Именно поэтому при моделировании в сре-
де ARIS для описания проблем в области
организации процессов используются полу-
концептуальные методы. Они позволяют
взглянуть на ситуацию с позиции управле-
ния бизнесом, а их достаточная точность и де-
тализация обеспечивают превосходный
старт для дальнейшей обработки информа-
ционными системами (ИС).
Благодаря новым методам и инструментам
модели бизнес-процессов все больше стано-
вятся точкой фокусировки и «калькой» при
разработке и настройке информационных
систем. По этой причине, в концепции ARIS
уровень и полнота описания бизнеса имеют
приоритет перед вопросами реализации.
Полуконцептуальные графические мето-
ды, такие как организационные диаграммы
или сетевые графики, широко применяются в
сфере управления бизнесом. Однако концеп-
ция ARIS идет дальше, предоставляя в рас-
2
Бизнес-процессы
поряжение менеджера справочное руковод-
ство по систематическому и полному модели-
рованию бизнес-процессов.
Сегодня описание бизнес-процессов все
сильнее интегрируется с корпоративным до-
кументированием знаний и опыта компании.
«Управление знаниями» и «корпоративная
память» — это всего лишь два понятия тер-
минологии, применяемой в этом контексте.
Значение ARIS как инфраструктуры управ-
ления знаниями продолжает возрастать.
Концепция ARIS прежде всего позволяет
зафиксировать широкий спектр описатель-
ных аспектов бизнес-процессов, подобрать
способы для их рассмотрения, определить
возможные наложения методов и выявить
пробелы в описании. Преимущества ARIS
очевидны как при решении административ-
ных и организационных вопросов бизнеса,
так и при проектировании компьютеризован-
ных информационных систем.
А.1. Преимущества для
управления бизнесом и
организационных процессов
Формулировка глобальной цели, или целе-
вая корпоративная установка, определяет
содержание и форму производственного про-
цесса, а также использование его материаль-
ного выхода (результата) и услуг путем соче-
тания производственных факторов
(Gutenberg. Die Produktion. 1983, сс. 1-10). Вы-
полнение этих задач зависит от множества
субъектов и технических средств, которые
должны тесно взаимодействовать. Правила,
необходимые для достижения корпоратив-
ной цели, и формируют организацию (Frese.
Grundlagen der Organisation. 1995, с. 1)
Структурная (функциональная) или
иерархическая организация характеризует-
ся постоянными (статическими) правилами,
такими как иерархия или топология пред-
приятия. Это касается отношений между
подразделениями, примерами которых могут
служить управление, выход, информацион-
ные или коммуникационные технологии. Эти
отношения описываются с помощью простых
инструментов, включая организационные
диаграммы.
Организация процессов, напротив, связа-
на с нестационарным и логическим (динами-
ческим) поведением процессов, необходимых
для выполнения программной корпоратив-
ной установки.
Между иерархической структурой орга-
низации и структурой процессов существует
тесная взаимосвязь.
В течение многих лет одной из ключевых
тем в теории бизнеса были иерархические
организации. Однако благодаря прочно во-
шедшим в моду «ученым» выражениям типа
«инжиниринг бизнес-процессов» (Gaitanides.
Prozefiorga.niza.tion. 1983; Euersheim.
Prozefiorientierte Unternehmensorganisation.
1994; Nippa, Picot. Prozefimanagement und
Reengineering. 1996) на авансцену в последние
годы вышла организация процессов.
Вообще говоря, бизнес-процесс для пред-
приятия представляет собой непрерывную
серию задач, решение которых осуществля-
ется с целью создания выхода (результата).
Исходной точкой и конечным продуктом биз-
нес-процесса является выход, спрос на кото-
рые предъявляют корпоративные или вне-
шние «потребители».
Бизнес-процессы позволяют добиваться
высокой эффективности деятельности пред-
приятия, фокусируя внимание на запросах
потребителей. Поэтому важно максимально
повысить значимость бизнес-процесса и увя-
зать с ним многочисленные функции
(Hammer, Champy. Business Reengineering.
1995).
В центре внимания бизнес-процессов все-
гда стоят вопросы управления бизнесом. Их
цели поддаются строгому определению (на-
пример, сократить цикл бизнес-процесса
«разработка продукта» на 30%), и они явля-
ются объектами учета стоимости (поопера-
ционного определения стоимости).
Многие элементы инжиниринга и реинжи-
ниринга бизнес-процессов (BPR) вошли в
предыдущие концепции построения органи-
зации. Например, модель Y-CIM (Scheer. CIM.
1994; CIM компьютеризованное управление
производством) описывает контекст между
разработкой продукта и процессом матери-
ально-технического обеспечения (логисти-
Преимущества ARIS для пользователя
3
кой) на промышленном предприятии, акцен-
тируя внимание на организации бизнес-про-
цессов. Еще в 1984 году автор описал бизнес-
процессы и их реализацию с помощью диаг-
рамм цепочки процессов (Scheer. Efficient
Information Management. 1991).
Для создания моделей бизнес-процессов
существует множество причин, например:
— оптимизация организационных измене-
ний (побочный продукт BPR),
— хранение корпоративных знаний, в том
числе в виде моделей-прототипов,
— создание и постоянный контроль техно-
логической документации для получе-
ния сертификата ISO-9000 и других,
— исчисление стоимости бизнес-процес-
сов,
— эффективное использование информа-
ции о процессах для реализации стан-
дартных программных решений или си-
стем workflow и адаптации их к конк-
ретным нуждам.
В рамках этих категорий методы модели-
рования можно применять и с более широки-
ми целями. Реинжиниринг бизнес-процессов
(BPR) позволяет «высветить» их компонен-
ты, требующие внимания.
Среди многочисленных проблем, которые
можно решить в результате оптимизации
бизнес-процессов, назовем лишь следующие:
— изменение структуры процесса путем
введения одновременно выполняемых
задач, что позволяет устранить лишние
циклы и сделать структуру более раци-
ональной,
— изменение структуры организационной
отчетности и повышение квалифика-
ции сотрудников путем комплексного
совершенствования процесса,
— сокращение объема документации, ра-
ционализация и ускорение документо-
оборота и потока данных,
— рассмотрение возможных мер по при-
влечению внешних ресурсов (т.е. по пе-
редаче функции создания выхода
внешнему исполнителю),
— внедрение новых производственных и
ИТ-ресурсов для улучшения функций
обработки.
Эти примеры относятся к множеству ас-
пектов и категорий моделирования, таких
как организация процессов, иерархические
структуры, квалификация сотрудников, до-
кументы (данные), внешний или внутренний
выход, а также ресурсы производства и ин-
формационных технологий. Очевидно, что
модель бизнес-процесса, предназначенная
для оптимизации, должна быть довольно
сложной. Более того, она должна учитывать
массу аспектов, для которых требуются мно-
гочисленные методы описания. Эти разнооб-
разные задачи определяют как вид объектов
моделирования, так и необходимую степень
структурирования, или уровень детализа-
ции.
Помимо фактической цели моделирова-
ния, фокус модели также определяется при-
меняемыми методами, особенно в тех случа-
ях, когда уже задан тип метода. Модели вос-
производят фрагменты реальности. Они
создаются путем абстрагирования от свойств
реальных объектов, при этом основная
структура и поведение этих объектов оста-
ются нетронутыми (гомоморфизм). Степень
возможного абстрагирования от несуще-
ственных характеристик зависит не только
от назначения модели в плане содержания,
но и от возможностей методов описания.
Если, скажем, выбран объектно-ориентиро-
ванный (например, метод сетей Петри) или
системно-теоретический подход, то модель
будет содержать только такие объекты, кото-
рые вписываются в синтаксис или семантику
этих методов.
Во избежание «зацикливания» на опреде-
ленных методах концепция ARIS не привя-
зывается к какому-то конкретному методу,
она обеспечивает общее описание бизнес-
процесса. В частности, ARIS не имеет конку-
рентов в области создания моделей управле-
ния производством на уровне предприятия.
4
Бизнес-процессы
А.2. Преимущества для
пользователя при
разработке
информационных систем
Информационные системы можно разра-
батывать самостоятельно, создавая специа-
лизированные приложения, либо приобре-
тать в виде уже готовых, стандартных реше-
ний. Если на первых порах популярностью
пользовались специализированные прило-
жения, то теперь нормой стали интегриро-
ванные стандартные решения. С появлением
новых типов программного обеспечения (на-
пример, компонентного, где приложения со-
бираются из отдельных программных компо-
нентов, предназначенных для конкретных
случаев) в последнее время получает распро-
странение смешанный вариант, сочетающий
оба этих способа. ARIS поддерживает все три
варианта: специализированные приложения,
стандартные программные решения и компо-
нентную сборку.
Разработка специализированных прило-
жений обычно обходится дорого и часто ос-
ложняется из-за таких факторов неопреде-
ленности, как продолжительность цикла раз-
работки или затруднения при оценке
стоимости. Поэтому наблюдающая тенден-
ция к переходу от индивидуальной разработ-
ки программного обеспечения к промышлен-
ному производству на «фабриках программ-
ного обеспечения» не вызывает удивления
(Balzert. Entwicklung von Software-Systemen.
1992, с. 5).
В связи с этим появилось множество мето-
дов для поддержки процесса разработки про-
граммного обеспечения. Они различаются
как по целевому объекту, ставя в центр вни-
мания различные аспекты процесса разра-
ботки программного обеспечения, так и по
подходу к рассматриваемым проблемам с
ориентацией на данные, события или функ-
ции. Общий обзор существующих методов
можно найти в различных работах, посвя-
щенных проектированию программного обес-
печения. К их числу относятся монографии
Бальцерта (Balzer. Lehrbuch der Software-
Technik. 1996) и Соммервилла (Sommerville.
Software Engineering. 1987), а также отчеты
конференций Рабочей группы 8.1, опублико-
ванные IFIP (например, Olle, Sol, Tully.
Information Systems Design Methodologies.
1983; Olle, Ver rijn-Stuart, Bhabuta.
Information Systems Life Cycle. 1988;
Preftmar, Eggers, Reinken. Interaktive
Entwurfsmethode. 1989; Barker. CASE*
Method. 1990; Hildebrand. Software Tools.
1990). Это лишь малая доля литературы по
данному вопросу.
В настоящее время рынок перенасыщен
обилием методов, почти неотличимых друг от
друга. Необъятное множество продуктов и
способов фактически затормозило развитие
автоматизированных инструментов на базе
этих методов. В связи с этим мы предлагаем
методологию, интегрирующую различные
методы разработки.
Ниже приведены типичные вопросы, отве-
ты на которые позволяют более эффективно
использовать возможности этой методологии
(Sol. Information Systems Design
Methodologies. 1983, c. 4; Olle et al/.
Information Systems Methodologies. 1991, c. 2;
Brodie, Ridjanovic, - Silva. Framework for
Information Systems. 1983, c. 232):
1. Действительно ли существует так мно-
го абсолютно разных способов проекти-
рования автоматизированных инфор-
мационных систем?
2. Если нет, то насколько схожи эти мето-
ды? Если да, то почему так много раз-
ных способов?
3. Существует ли оптимальный способ
разработки информационной системы?
4. Где начинается и где заканчивается
процесс разработки?
5. Как выглядит конечный продукт про-
цесса проектирования?
6. Сколько этапов необходимо для полу-
чения результата разработки?
7. Следует ли использовать только один
определенный вид информационной си-
стемы или же требуется несколько ме-
тодов — свой для каждой системы? По
каким критериям следует выбирать эти
методы?
Преимущества ARIS для пользователя
5
Постановка этих вопросов позволяет
классифицировать и оценить различные ме-
тоды. Однако только одного их решения мало.
Есть и вторая группа факторов, которые
дают основания обратиться к методологиям
проектирования информационных систем.
Она вытекает из того обстоятельства, что в
сложных проектах разработки обычно уча-
ствует несколько деловых партнеров. Подчас
они пользуются разными методами, либо ре-
зультаты их работы частично накладывают-
ся друг на друга. Только инфраструктура,
интегрирующая отдельные методы, подтвер-
ждающая согласованность или указывающая
на возможное наложение, способна привести
к взаимопониманию. Очевидно, что такая ин-
фраструктура может и должна координиро-
вать различные методы. К сожалению, мно-
гие из популярных сегодня методов разра-
ботки информационных систем напоминают
скорее плоды досужих умствований, нежели
эмпирические концепции, опирающиеся на
убедительные теории.
Концепция ARIS создает направляющие
ориентиры для разработки, оптимизации и
реализации интегрированных прикладных
систем. В то же время она наглядно показы-
вает специалистам по управлению бизнесом,
как именно следует рассматривать, анализи-
ровать, документировать и внедрять инфор-
мационные системы.
Программное обеспечение для управления
бизнесом включает модули для бухгалтерс-
кого учета, закупок, продаж, производствен-
ного планирования и т. д. Финансовые инфор-
мационные системы заметно отличаются по-
вышенной сложностью. Внедрение
информационных систем затрагивает многих
сотрудников организации и внешних дело-
вых партнеров. Это становится очевидным в
условиях органично интегрированной обра-
ботки данных, где данные совместно исполь-
зуются множеством приложений. В числе
примеров можно назвать реализацию на
предприятиях комплексных ИС-ориентиро-
ванных концепций, компьютеризованное уп-
равление производством (CIM) на промыш-
ленных предприятиях, системы управления
товарами с ИС-поддержкой на предприятиях
розничной торговли, электронные банковс-
кие операции в финансовых учреждениях.
До середины 90-х годов соотношение меж-
ду усилиями по внедрению финансовых при-
кладных пакетов в организации и ценой их
приобретения зачастую превышало 5:1. Ус-
тановить готовые системы относительно не-
сложно, но такая резкая диспропорция
объясняется тем, что пользователям необхо-
димо к тому же определить, какие цели
(стратегического характера) они хотят дос-
тичь с помощью данной системы, как этого
добиться, используя функциональные воз-
можности системы, и каким образом следует
настроить, сконфигурировать и технически
внедрить данный пакет.
В ранней модели жизненного цикла, при-
веденной на рис. 1а, системы программного
обеспечения были представлены только на
нижних уровнях диаграммы. Деловые функ-
ции системы описывались «пользовательски-
ми интерфейсами, таблицами данных, уста-
новками параметров, именами транзакций»,
либо их нужно было соответствующим обра-
зом выводить. По этой причине пользовате-
лям прежде приходилось вырабатывать свои
собственные деловые требования и увязы-
вать спецификацию проекта со стандартным
программным решением. Безусловно, для
этого требовалось обладать серьезными по-
знаниями и навыками в области информаци-
онных систем и знать, как добиться выполне-
ния предъявляемых требований. Все это не-
редко вынуждало пользователей обращаться
к консультантам.
В результате быстрого снижения стоимос-
ти аппаратных и программных средств отме-
ченная диспропорция еще более усугубилась.
Мелкие и средние предприятия оказались не
в состоянии платить консультантам милли-
оны долларов за внедрение. Это вызвало рост
популярности инфраструктур, методов и ин-
струментов, позволяющих уменьшать сто-
имость внедрения программного обеспече-
ния, повышая для пользователя приемле-
мость стандартных программных решений.
6
Бизнес-п роцессы
5
Целевая концепция
с позиции пользователя
Характеристика
традиционного
стандартного
программного
решения
Согласование целевой
концепции и системного
решения
Описание
реализации
Вопросы
управления
технологии
Спецификация
проекта
Определение
требовании
семантические
одели
Рис. 1а. Сравнение усилий по приобретению и внедрению программного обеспечения в рамках
жизненного цикла
Сравнение времени
и усилий
Информационные
Преимущества ARIS для пользователя
7
Спецификация
проекта
Вопросы
управления
Определение
требований
(семантические
модели)
Рис. 1 б. Способы сокращения организационных усилий
Целевая концепция
с позиции пользователя
Сокращение времени
и усилий по созданию
целевых концепций с
помощью моделей-
прототипов
Моделирование
документирования
стандартных программных
решений для согласования
с целевой концепцией
Согласование целевой
концепции с системным
решением при помощи
инструментальных
средств
Автоматическая настройка
стандартного программного
обеспечения применительно к
конкретным нуждам при помощи
определения требований
8
Бизнес-процессы
Для этого существует ряд способов (см. —
рис. 16):
— сокращение усилий, необходимых для
создания целевой концепции, за счет
эффективного использования знаний
«лучших образцов практики», предос-
тавленных в виде моделей-прототипов;
— создание определения требований за
счет эффективного использования ме-
тодов моделирования для детализации
описания;
— документирование определения требо-
ваний к стандартному программному
обеспечению с помощью семантических
методов моделирования, что делает
бизнес-логику более понятной;
— применение семантических моделей
для максимального автоматического со-
гласования определения требований
целевой концепции со стандартным
программным обеспечением, что сокра-
щает необходимость специальных зна-
ний в области информационных систем;
— эффективное использование семанти-
ческих моделей в качестве отправной
точки для максимальной автоматиза-
ции системы и настройки конфигура-
ции применительно к конкретным нуж-
дам.
При создании концепции ARIS ставилась
цель повысить эффективность этих способов,
ускорить внедрение стандартного программ-
ного обеспечения и сократить усилия по его
внедрению за счет включения интегрирован-
ных методов и инструментов (ARIS Toolset).
Функциональные возможности ARIS обес-
печивают:
— инфраструктуру (архитектуру) для
полного описания стандартных про-
граммных решений;
— интеграцию в эту архитектуру наибо-
лее подходящих методов моделирова-
ния информационных систем и разра-
ботку методов описания бизнес-процес-
сов;
предоставление моделей-прототипов в
качестве инструментов управления
прикладным ноу-хау, моделирования и
анализа системных требований, а так-
же инструментов, помогающих полу-
чить удобную для пользователя навига-
цию в рамках моделей.
эффективно используя стандартные
программные решения, ARIS-здание
бизнес-инжиниринга (НОВЕ) предлага-
ет архитектуру для управления биз-
нес-процессами. Благодаря использо-
ванию систем workflow, она слабо свя-
зана со программными «кирпичиками»
(бизнес-объектами). ARIS обеспечивает
инфраструктуру для описания сборки
программных компонентов, позволяя
создавать деловые информационные
системы, которые идеально подходят
для конфигурирования систем
workflow, создания фильтров и опреде-
ления параметров приложений.
Базовая модель бизнес-процесса в ARIS
9
Б. Базовая модель бизнес-
процесса в ARIS
Для работы в среде ARIS необходимо сна-
чала тщательно изучить соответствующий
объект, что, в свою очередь, приводит к со-
зданию простейшей модели бизнес-процесса,
опирающейся в основном, на знание деятель-
ности предприятия. Затем эта модель расши-
ряется за счет дополнительных деталей. В
итоге получается базовая модель бизнес-
процесса в ARIS.
Б.1. Исходная модель бизнес-
процесса
Поясним ключевые моменты описания
бизнес-процессов на простом примере обра-
ботки заказов. Для начала изложим общий
сценарий.
Допустим, потребитель хочет заказать из-
готовителю несколько изделий. На основе ин-
формации о клиенте и изделиях изучается
вопрос о технической возможности и эконо-
мической целесообразности изготовления
данных изделий. После поступления заказа у
поставщика приобретаются необходимые
материалы. После получения материалов и
последующего планирования заказа пред-
приятие изготавливает изделия в соответ-
ствии с графиком работ и отправляет их кли-
енту вместе с надлежащей документацией.
Теперь рассмотрим этот сценарий с раз-
личных точек зрения.
В теории систем мы можем разграничить
структуру системы и ее поведение. Начнем с
описания субъектов (сущностей) ответствен-
ности и отношений, участвующих в бизнес-
процессе, а затем опишем динамическое по-
ведение при помощи последовательности
функций. Выходные потоки описывают ре-
зультаты выполнения процесса, а информа-
ционные потоки — обмен документами, уча-
ствующими в процессе.
Функции, производители выхода (органи-
зационные единицы), выходные и информа-
ционные объекты представлены различными
символами. Потоки обозначены стрелками.
Б. 1.1. Субъекты ответственности
и их отношения
На рис. 2а представлены субъекты ответ-
ственности (организационные единицы), уча-
ствующие в бизнес-процессе, причем для
каждого из них показан выход, а также взаи-
мосвязи (отношения) в виде контекстных ди-
аграмм или диаграмм взаимодействия. Пос-
ледовательность выполнения процессов
здесь не отражена, тем не менее можно полу-
чить исходное представление о структуре
бизнес-процесса. В сложных процессах не-
сметное множество обменов между различ-
ными деловыми партнерами подчас может
привести в замешательство. Помимо различ-
ных взаимодействий, сюда можно ввести
функции субъектов ответственности. На ди-
аграмме это сделано лишь в нескольких местах.
Диаграммы взаимодействия широко при-
меняются в теории бизнеса. Рис. 26 отражает
довольно типичную картину взаимоотноше-
ний между клиентом, производителем и по-
ставщиком и результаты (выходы) их взаи-
модействия.
Б. 1.2. Поток функций
На рис. 3 тот же бизнес-процесс описыва-
ется при помощи подлежащих выполнению
функций с указанием их последовательнос-
ти. Главная роль здесь отводится не субъек-
там ответственности, как это было на статич-
ной диаграмме взаимодействия, а динамич-
ной последовательности функций. Для
наглядности на рис. 3 представлены и опера-
ционные единицы. Из-за обилия элементов
их взаимосвязь с диаграммой, приведенной
на рис. 26, здесь не столь очевидна.
Функциональные потоки представляют
собой последовательности выполнения фун-
кций для создания выхода и, таким образом,
они могут характеризовать бизнес-процесс.
Сами выходные потоки будут показаны от-
дельно.
10 Бизнес-процессы
Рис. 2а. Диаграмма взаимодействия в бизнес-процессе «обработка заказа»
Рис. 26. Общая диаграмма взаимодействия на предприятиях
Базовая модель бизнес-процесса в ARIS 11
Б. 1.3. Поток выходов
Цель бизнес-процесса состоит в создании
выхода для получения вознаграждения в
виде другого выхода. В нашем примере выхо-
дом производителя является выполнение за-
каза клиента, а вознаграждением — получе-
ние денежных средств, хотя в процессе про-
изводства создается также промежуточный
выход, возникающий в результате выполне-
ния функций.
Понятие «выход» весьма неоднозначно. В
наиболее общем смысле выход в бизнесе есть
результат производственного процесса. Вы-
ход может быть физическим (материальный
выход) и нефизическим (услуги). В то время
как материальный выход легко поддается оп-
ределению (например, доставка материала,
изготовленные детали или даже готовый про-
дукт), с понятием «услуги» дело обстоит
сложнее, поскольку оно охватывает услуги
самого разнообразного характера. Вот лишь
некоторые примеры:
— театральные представления (драмати-
ческие спектакли, концерты), где
выходом является исполнение на сце-
не; потребление этого выхода происхо-
дит одновременно с его созданием;
— банковские услуги в виде займов или
кредитов; в этом случае услуга со-
стоит в предоставлении необходимых
денежных средств и сама по себе явля-
ется результатом других банковских
услуг (проверка кредитоспособности,
услуги по депозиту и т. д.);
— услуги по страхованию;
— услуги государственного сектора (вы-
дача водительских удостоверений, удо-
стоверений личности и т. д.).
Немаловажная характеристика выхода —
его востребованность стороной, не являю-
щейся его производителем. Иными словами,
на данный выход должен быть спрос. Необхо-
димыми предпосылками служат поступле-
ние заявки от клиента и наличие договорен-
ности о цене. На каком уровне существует
здесь отношение клиент-поставщик — меж-
ду внешними деловыми партнерами или
между внутренними организационными еди-
ницами, — значения не имеет. Цена может
быть рыночной, либо речь может идти лишь о
внутрифирменных расчетах. Кроме того, не-
существенно, имеем ли мы дело с запрашива-
емой ценой или фактически уплачиваемой.
Если сторона, приобретающая услугу, осоз-
нает ее денежную стоимость — этого доста-
точно. Внутрифирменные услуги, так же, как
и некоторые внешние услуги государствен-
ного сектора, иногда предоставляются бес-
платно.
Для повышения прозрачности выхода су-
ществует тенденция к описанию внутрифир-
менного выхода и начислению соответствую-
щей стоимости. Так же обстоит дело и в госу-
дарственном секторе. На рис. 4 под символом
каждого выхода указана создающая его фун-
кция. В данном случае выходом являются ин-
формационные услуги, например, «прове-
ренный заказ», «производственный план»,
«заказ», «документация на заказ», «заказ на
отправку». Изделия же, представляющие со-
бой непосредственный результат процесса
производства, рассматриваются как матери-
альный выход. Доставленные изделия — ре-
зультат услуги «транспортировка».
На рис. 4 показан результат процесса «из-
готовление изделия», т.е. материальный вы-
ход в виде изготовленного изделия. Анало-
гичным образом в процессе изготовления вы-
полняется и документируется проверка
качества. Все данные, относящиеся к заказ-
чику, фиксируются в «документации на за-
каз», которая сама по себе является услугой
по предоставлению информации. После каж-
дой внутрифирменной функции описывается
поставляемый ею выход, который в свою оче-
редь поступает в следующий процесс уже в
качестве входа. Чтобы не перегружать диаг-
рамму, организационные единицы на рисун-
ке опущены. Приведенная иллюстрация вы-
ходного потока не позволяет однозначно опи-
сать последовательность выполнения функций.
Б. 1.4. Информационный поток
Помимо информационных услуг, компо-
нентами процесса являются и другие данные,
используемые для описания инфраструкту-
ры бизнес-процессов.
N>
Бизнес-процессы
Условные обозначения: Организационный поток - » функциональный поток Функция /Горганиза-Х (/\Л Логический (| ционная ) \/ у оператор "Им Ч^единицах х—<
Рис. 3
Поток функций в бизнес-процессе «обработка заказа
Заказ
поставщику
Ввод заказа
Платеж
Оплата
Заказ
потребителя
клиента
Проверенный
заказ
Производ-
ственный план
Ввод заказа
Проверка заказа
Планирование
производства
Условные обозначения:
Поток выходов
Выход
Функция
Рис. 4.
Поток выходов в бизнес-процессе «обработка заказа
Изготовление Отправка
изделия изделия
Базовая модель бизнес-процесса в ARIS
14 Бизнес-процессы
На рис. 5 представлены информационные
объекты бизнес-процесса и данные, которы-
ми они обмениваются. Объекты, отнесенные к
разряду информационных услуг, обведены
двойной рамкой. Показаны также информа-
ционные объекты, описывающие контекст-
ную среду бизнес-процесса, например, дан-
ные, касающиеся поставщиков, изделий или
графиков работы. Эти данные необходимы
для создания информационных услуг. На-
пример, при проверке заказов проверяется
кредитоспособность заказчика и наличие ма-
териально-производственных запасов.
Каждый информационный объект имеет
свое имя. Ему можно присвоить и другие ат-
рибуты, но для экономии места они здесь опу-
щены. Функции процесса, работающие с ин-
формационными объектами, являются час-
тью объектов, предоставляющих
информационные услуги. Можно соотнести
функции и с другими информационными
объектами, однако это будут уже подфунк-
ции по отношению к функциям процесса, рас-
сматривавшимся до сих пор, поэтому на рис. 5
они не показаны. Например, детальную фун-
кцию «проверка кредитоспособности» можно
соотнести с информационным объектом
КЛИЕНТ в рамках функции процесса «про-
верка заказа».
Поскольку поток данных активизируется
функциями, связанными с информационны-
ми объектами, функциональный поток на рис.
5 более или менее просматривается. Однако
если один информационный объект обраба-
тывается несколькими функциями или если
одна функция требует нескольких потоков
данных, то однозначно проследить функцио-
нальный процесс невозможно.
Б. 1.5. Объединенная модель
бизнес-процесса
Ни один из представленных здесь потоков
(организационный, функциональный, выход-
ной и информационный) не позволяет смоде-
лировать бизнес-процесс полностью. Следо-
вательно, необходимо собрать все описания
воедино. Для этого нужно взять за основу
одно из описаний, а затем интегрировать его с
остальными.
Поскольку к определению бизнес-процес-
са ближе всего подходит поток функций, его
мы и возьмем за отправную точку (рис. 6).
Позже, при рассмотрении объектно-ориен-
тированных методов, будет показано, как
можно использовать в этой роли информаци-
онные потоки.
Чтобы иметь возможность различать свя-
зи между объектами, представим потоки в
диаграмме разными линиями.
Наличие стрелок, соответствующих пото-
кам функций и выходов, может показаться
избыточным, но они не всегда идут парал-
лельно. После функции «обработка заказа»
выполнение функции «изготовление изде-
лия» активизируется поставщиком. Одно-
временно услуги поставщика оплачиваются
отделом закупок, хотя первая функция фак-
тически не имеет физического выхода.
Информационные объекты, обозначенные
как услуги, не привязываются к функциям в
качестве информационных объектов. Если
потоки (например, выходов и функций) идут
параллельно, описание процесса можно ра-
ционализировать, опустив один из них.
Б.2. ARIS-модель
бизнес-процесса
Простейшая модель, изображенная на рис.
6, уже согласуется с определением бизнес-
процесса, хотя для придания большей реали-
стичности мы дополним ее некоторыми дета-
лями. Впоследствии мы обобщим рассмот-
ренный бизнес-процесс на примере
обработки заказов.
Б.2.1. Пример расширенной
версии процесса
На рис. 7 представлена более подробная
версия процесса «изготовление изделия»,
изображенного на рис. 6. Она иллюстрирует
ключевые расширения семантической осно-
вы описания бизнес-процесса, используемые
в этой книге. Они почерпнуты из литературы
по управлению бизнесом, бизнес-информа-
тики и практического опыта.
Рис. 5. Поток информации в бизнес-процессе «обработка заказа»
Базовая модель бизнес-процесса в ARIS
о
Бизнес-процессы
Условные обозначения:
~ Организационный поток
-> Поток фуНКЦИЙ
Информационный поток
> Поток информационных услуг
-> Поток материального выхода
Функция
Контекст-
ные
данные
Организа^
ционная
„единиш.
Выход
/д\ Логический
\/у оператор "И"
Рис. 6
Объединенная модель бизнес-процесса «обработка заказа
Базовая модель бизнес-процесса в ARIS 17
Функциональные потоки дополняются уп-
равляющими элементами в виде событий и
сообщений. Это позволяет более адекватно
описать последовательность выполнения
процесса. События описывают изменения ус-
ловий и то, что произошло в результате неко-
торого события, что, в свою очередь, активи-
зирует следующую функцию. Помимо про-
стых событий, имеются также и сложные.
Например, для функции «изготовление изде-
лия» нужно завершить планирование и
иметь в наличии необходимые детали. Эта за-
висимость выражается с помощью логичес-
кого оператора «И» между указанными собы-
тиями.
Управляющие потоки регулируют акти-
визацию событий в соответствии с разумной
логикой процесса. Наряду с логическими свя-
зями можно использовать последовательные,
параллельные, альтернативные и комбини-
рованные методы. Управляющие потоки реа-
лизуются в виде событий и сообщений, кото-
рые они активизируют, после чего информа-
ция о начале события передается
следующему элементу процесса. На рисун-
ках сообщения обозначены символом «кон-
верт». Они определяют реакцию функций на
события. Кроме информации о начале собы-
тия, сообщения могут содержать дополни-
тельные атрибуты (Scheer. ARIS ~ Business
Process Modeling. 1998).
После того как события «производствен-
ный план составлен» и «заказ (поставщику)
обработан» посредством соответствующих
сообщений активизировали функцию «изго-
товление изделия», происходит событие «из-
делие выполнено». Таким образом данный
процесс завершается, и это событие посред-
ством сообщений активизирует наступление
последующих событий.
Здесь иллюстрируются только события,
имеющие отношение к непрерывному биз-
нес-процессу. Такие события называются
релевантными.
Потоки функций, управляемые события-
ми, известны также под названием Event-
driven Process Chain (ЕРС) — событийные
диаграммы процесса. Метод ЕРС разработан
в 1992 году Институтом информационных си-
стем (Iwi) при Университете Заарланда (Гер-
мания) совместно с сотрудниками SAP в рам-
ках проекта научно-исследовательских и
опытно-конструкторских разработок, фи-
нансировавшегося фирмой SAP AG (Keller,
Nuttgens, Scheer. Semantische Prozeftmo-
dellierung. 1992). Сейчас этот метод является
одним из ключевых компонентов модуля,
предназначенного для описания моделей в
системе SAP R/3. Метод ЕРС не проводит
жесткого разграничения между описанными
здесь потоками. В частности, выходной и уп-
равляющий потоки часто могут объединять-
ся, а сообщения не используются. Возможно,
именно это упрощение способствовало ус-
пешному применению метода ЕРС в реаль-
ной практике. Несколько позже мы остано-
вимся на нем подробнее.
На рис. 7 более детально представлено
формирование конечного результата (выхо-
да) из отдельных выходов путем их объеди-
нения и последующей трансформацией. Да-
лее термин «выход» будет употребляться
также как синоним понятия «продукт».
В сфере производства производственные
факторы действуют в различных комбинаци-
ях. Согласно теории производства, предло-
женной Гутенбергом, основными факторами
являются производственные ресурсы, чело-
веческие ресурсы, материальные ресурсы
(сырье, материалы, заготовки) и управление.
Разработанная Гутенбергом теория произ-
водства относится к созданию материального
выхода. Однако, принимая во внимание воз-
растающую роль функций обслуживания в
промышленном производстве, в данной рабо-
те нам нужен общий подход, в равной мере
применимый и к сфере услуг. Кроме того, со-
гласно концепции управления информацион-
ными ресурсами, информация сама по себе
считается производственным фактором
(Zimmermann et al. Produktionsfaktor
Information. 1972; Horton. Information
Management Workbook. 1981; Krcmar.
Informationsmanagement. 1997).
Эти потребности учитываются в современ-
ной теории коммерческого производства,
расширяющей понятие производственных
факторов (см. рис. 8). Вообще, любой объект,
необходимый для выполнения процесса
00
Бизнес-процессы
Условные обозначения:
---------------- Организационный поток / Поток ресурсов
---------------->• Управляющий поток
---------------- >•------Информационный поток
----------------ПОТОк информационных услуг
----------------_>>-поток материального выхода
ППУ = Производственное планирование и Управление
Функция
Человечес-
кий ресурс
Сообщение
Выход
1 Г
I Прикладное |
I ПО |
Контекст-
ные данные
Юрганизащр
онная ,
L единица^
Компы
ное обе
о ван!
Логический
опе|мтор
Рис. 7. Детальный фрагмент бизнес-процесса применительно к событию «изготовление изделия
Базовая модель бизнес-процесса в ARIS 19
«производство», — будь то материал, услуга
или информация — рассматривается как
производственный фактор. Понятие «произ-
водство» употребляется и в более широком
контексте, включая создание нефизического
выхода, т.е. услуг (Kern. Industrielle
Produktionswirtschaft. 1992, с. 12).
На рис. 7 фактор «производственные ре-
сурсы» представлен соответствующей маши-
ной, компьютерной системой (рабочей стан-
цией) для управления производственным
процессом и компьютером, управляющим
данной машиной.
Человеческий ресурс (на выходе или вхо-
де), относящийся к объекту (выход, связан-
ный с объектом), представлен с добавлением
категории «оператор машины».
Управление (планирование и контроллинг
объединенного процесса) определяется
стремлением к цели «высокое качество» —
одному из ключевых компонентов выполне-
ния процесса. Аспекты, относящиеся к орга-
низационной структуре, показаны в привяз-
ке к функциям организационных единиц (в
данном случае — производственного цеха).
Использование материалов как факторов
объектов иллюстрирует соответствующий
материал. Факторами объектов могут быть
также поточные объекты, бесплатные и пре-
доставляемые заказчиком, например, ткань,
предоставляемая красильной фабрикой. В
качестве других примеров поточных объек-
тов можно привести пациентов больницы или
клиентов парикмахерской (Corsten.
Dienstleistungsproduktion. 1994).
«Производственные планы» рассматрива-
ются как нефизические материалы (услуги),
представляющие собой выход предшествую-
щих функций планирования производства.
На этом этапе выясняются имеющиеся мощ-
ности и выполняются другие виды проверки.
Иллюстрацией этих услуг служит документ с
названием «производственный план». В тео-
рии бизнеса не прекращается дискуссия о
принципах отнесения услуг к произведенно-
му продукту (Farny. Produktions- und
Kostentheorie. 1965; Muller. Informati-
onsprodukte. 1995). В этой монографии мы
рассматриваем их как отдельные факторы,
— именно поэтому на рис. 8 они представле-
ны как составная часть обрабатываемого
объекта.
Существуют также дополнительные фак-
торы, которые, будучи вспомогательными ус-
лугами, имеют лишь косвенное отношение к
производству. Сюда же относятся обще-
ственные услуги и воздействие на окружаю-
щую среду.
Услуги, предоставляемые внешними
партнерами, относятся к производству (на-
пример, ремонтные услуги), но они не имеют
отношения к нефизическому входу, напря-
мую связанному с обрабатываемым объек-
том, как это обозначено на нашей схеме.
Во всем остальном для целей этой работы
можно ограничиться упрощенной классифи-
кацией, приведенной на рис. 9.
Для создания выхода требуется дополни-
тельная информация о процессе. Эта инфор-
мация представлена на рис. 7 объектом дан-
ных «график работ». Графики работ влияют
на процесс. Поскольку они не являются ре-
зультатом соответствующего бизнес-процес-
са, а хранятся скорее в качестве эталонных
данных, их нельзя рассматривать как инфор-
мационные услуги в рамках данного процес-
са.
ARIS-модель бизнес-процесса позволяет
разграничить события, активизирующие уп-
равляющий поток посредством сообщений, и
поток выходов. Следует отметить, что при
практическом моделировании потоки управ-
ления и выходов в целях упрощения можно
объединять. Это имеет смысл, когда в каче-
стве выходов рассматриваются информаци-
онные объекты, например, документация на
заказ или счета-фактуры. Такой принцип по-
зволяет приравнять активизирующее собы-
тие к информационным объектам. Однако
для приложений, где требуется более точное
описание сообщений (например, в системах
workflow) или точное прослеживание потока
материальных выходов (например, в произ-
водственных процессах), разграничение по-
токов является обязательным условием.
Бизнес-процессы
. 8. Факторы промышленного производства (Kern. Industrielle Produktionswirtschaft. 1992, с. 17)
Базовая модель бизнес-процесса в ARIS 21
Рис. 9. Классификация типов выхода и входа
В ARIS-модели бизнес-процесса вычленя-
ются следующие виды потоков:
— Организационные потоки. Характери-
зуют управление организационными
единицами и их обязанности.
— Целевые потоки. Характеризуют кон-
цептуальные и бизнес-цели, которых
требуется достичь в результате выпол-
нения того или иного процесса или дей-
ствия. Цели ставит руководство.
— Управляющие потоки. Управляют логи-
ческой последовательностью выполне-
ния функций посредством событий и
сообщений. Функции процесса реали-
зуют потоки, например, путем добавле-
ния к входному потоку какого-либо
компонента, необходимого для создания
выхода. В управляющих потоках каж-
дый процесс активизируется одним или
несколькими сообщениями. Однако
каждый процесс в свою очередь тоже по-
рождает одно или более сообщений.
Потоки выходов. Мы можем разграни-
чить потоки материальных выходов и
потоки услуг. Потоки услуг могут функ-
ционировать сами по себе, тогда как по-
токи материальных выходов обычно
управляются и сопровождаются пото-
ками услуг. Услуги подразделяются на
информационные (создание и предос-
тавление информации) и прочие. Пото-
ки финансовых ресурсов являются ком-
понентами потоков выходов. Различные
услуги до определенной степени допус-
кают замещение. Это позволяет заме-
нять физические услуги (например, вы-
дачу денежной наличности) информа-
ционными (например, переводом
электронных «денег»).
Потоки ресурсов. Отображают «достав-
ку» используемого выхода — потенци-
ального фактора «ресурсы». Понятие
«ресурсы» охватывает как производ-
ственное оборудование, так и компью-
терные средства.
22 Бизнес-процессы
Базовая модель бизнес-процесса в ARIS 23
Организационный поток / Поток ресурсов
Управляющий поток
Функция
Событие
Сообщение
Контекстные
данные
л......... ।
J Прикладное ПО J
I (программное •
I обеспечение) I
Рис. 10. ARIS-модель бизнес-процесса
.....* Информационный поток
----->• Поток информационных услуг
-—-------------> Поток материальных выходов
ППУ ВоДственное планирование и управление
ПК = • ^ьный компьютер
Человеческий
ресурс
Машина О
Компьютерное V\/
оборудование
Логический
оператор "И"
24 Бизнес-процессы
— Потоки человеческих ресурсов. Пока-
зывают «доставку» прямого человечес-
кого ресурса.
— Информационные потоки. Эти потоки
управляют доступом к информации,
представляющей собой совокупность
целенаправленных знаний и навыков,
необходимых для выполнения функ-
ций.
На рис. 10 приведена детальная схема пол-
ного бизнес-процесса обработки заказа. От-
правка как функция транспортировки пред-
ставлена в виде материального выхода, по-
скольку она изменяет местоположение
обрабатываемого объекта. Однако ее можно
было бы интерпретировать и как услугу.
ARIS-модель бизнес-процесса является
иерархической, т.е. функции можно предста-
вить в виде более детальных бизнес-процес-
сов. Функция рассматривается как процесс
на следующем лежащем ниже уровне, если
когда этот процесс можно описать теми же
элементами ARIS.
Элементы ARIS-модели, отображающие
отдельные части бизнес-процесса, позволя-
ют создать его представление, независимое
от используемого метода. Правда, в некото-
рых концепциях анализа бизнес-систем эле-
менты объектно-ориентированных методик
представлены специальным описательным
языком. Однако в объектно-ориентирован-
ном анализе главное внимание уделяется
описанию классов, подклассов и соответству-
ющих методов. Обычно эти классы соответ-
ствуют классам данных. Управляющие пото-
ки отображаются в виде потока сообщений
между классами. В бизнес-процессах проис-
ходит обмен множеством сообщений, где фи-
гурируют заказы, клиенты и изделия. При
объектно-ориентированном подходе пред-
ставление управляющего потока может ока-
заться чрезмерно перегруженным деталями.
Так, например, одни и те же потоки сообще-
ний приходится дифференцировать с помо-
щью последовательной нумерации. Между
тем, ARIS-модель сосредоточена на концеп-
циях бизнеса, поэтому в центре внимания
находятся функции и управляющие ими потоки.
Впоследствии мы покажем, что объектно-
ориентированный метод является хорошим
дополнением к моделированию, ориентиро-
ванному на процесс, поскольку он позволяет
взглянуть на модели бизнес-процессов в дру-
гом ракурсе. Поэтому объектно-ориентиро-
ванное моделирование можно интегрировать
в ARIS-концепцию.
Б.2.2. Обобщенная модель
бизнес-процесса
Модели бизнес-процессов можно проекти-
ровать на разных уровнях абстрагирования.
Рассмотренная выше модель бизнес-процес-
са относилась к обработке заказов. В этом
примере описывалась не столько реальная
процедура обработки заказов клиентов,
сколько некоторый обобщенный процесс об-
работки заказов, представляющий собой аб-
стракцию реально осуществляемого процес-
са. Такой вид описания называется типом
бизнес-процесса.
На рис. 11 приведен фрагмент производ-
ственного процесса обработки отдельного за-
каза. Здесь каждый объект, фигурирующий в
бизнес-процессе, конкретизируется присво-
ением ему определенного имени или набора
имен. Для управления конкретными процес-
сами используются конкретные модели биз-
нес-процессов. В производственном секторе
это обычно составление графиков работ, ко-
торые служат описанием производственного
процесса для изготовления отдельных дета-
лей или выполнения производственных зака-
зов.
В административном секторе конкретные
модели бизнес-процессов реализуются с по-
мощью систем управления workflow. Систе-
мы workflow автоматизируют управление
потоками документов и работ. Следователь-
но, они должны иметь доступ к информации,
касающейся управляющей структуры и от-
ветственных субъектов, а также технических
средств применительно к каждому бизнес-
событию. Конкретные бизнес-процессы на-
зываются экземплярами. Между типом биз-
нес-процесса (рис. 7) и экземпляром этого
процесса (рис. 11) существует отношение
класс — экземпляр.
Условные обозначения:
Организационный поток / Поток ресурсов
Управляющий поток
Информационный поток
5* Поток информационных услуг
Поток материального выхода
ППУ = Производственное планирование и управление
Функция
Человечес-
кий ресурс
Машина
Контекст-
ные
данные
Выход
• •
Компьютер-
ное обору-
дование ,
Рис. 11. Модель экземпляра бизнес-процесса обработки заказа (1-й уровень)
. Прикладное.
I ПО I
Логический
оператор "И"
Базовая модель бизнес-процесса в ARIS
т
26 Бизнес-процессы
Совокупность конкретных процессов об-
работки заказа составляет класс, или тип, на-
зываемый «бизнес-процесс обработки зака-
за». Конкретные процессы являются экземп-
лярами (элементами) этого класса. Классы
«перенимают» характеристики своих эле-
ментов, хотя каждый из классов - это абст-
ракция отдельных его экземпляров.
Уровни типа занимают важнейшее место в
моделировании бизнес-процессов. Для под-
держки организационных и реорганизацион-
ных мер необходимо не только «ноу-хау» по
каждому бизнес-процессу, но и ноу-хау отно-
сительно всей структуры процессов в органи-
зации. В конце концов, целью организацион-
ных изменений является усовершенствова-
ние всего процесса. Таким образом,
экземпляры «выстраиваются» в соответ-
ствии с новой, усовершенствованной схемой.
Благодаря обработке исключений, возникаю-
щих в ходе выполнения процесса и «выпада-
ющих» из его структуры, можно учитывать
конкретные отклонения отдельных экземп-
ляров.
Представление экземпляров называется
1-м уровнем описания; уровни типа называ-
ются 2-м уровнем описания.
Таким образом, 1-й и 2-й уровни находят-
ся в таком же отношении, как классы и экзем-
пляры. Каждый класс характеризуется име-
нем и перечнем атрибутов, описывающих со-
ответствующий экземпляр. Например, класс
КЛИЕНТ характеризуется атрибутами «но-
мер клиента», «имя клиента» и «платежный
период». Экземпляры, имеющие эти характе-
ристики, являются предметом описания на
1-м уровне. На рис. 12 приведено несколько
примеров описаний 1-го и 2-го уровней.
Для дальнейшей характеристики классов
можно перечислить прилагаемые к ним фун-
кции. Мы сделаем это позже.
Группировка классов всегда вызывает не-
которые затруднения. Поэтому при описании
понятия «заказ» мы будем абстрагироваться
только от специфических свойств 4711 и 4723.
В результате получаем классы «оформлен-
ный заказ» и «готовый заказ». На 2-м уровне
мы абстрагируемся от свойств «оформлен-
ный» и «готовый» и создадим из этого под-
множества родительский класс «заказ». Та-
кая операция называется обобщением и обо-
значается символом «треугольник».
При обобщении величины группируются в
родительские классы. При этом экземпляры
заказа 1-го уровня становятся и экземпляра-
ми класса «заказ». Классу «заказ» приписы-
вается как свойство «состояние заказа», что
позволяет соотнести с каждым экземпляром
класса состояние процесса, описав заказ как
«оформленный» или «готовый». Материалы и
изделия также обобщаются, становясь «дета-
лями» и «ресурсами».
Таким образом, 2-й уровень содержит свя-
занные с предметной областью классы описа-
ний бизнес-процесса. Что касается новых
классов, формируемых из аналогичных (по-
хожих) классов 2-го уровня путем абстраги-
рования от их отношений с конкретной облас-
тью, то они присваиваются 3-му уровню, ко-
торый является метауровнем (см. рис. 12).
При этом классы 2-го уровня становятся эк-
земплярами этих метаклассов. Например,
класс «материальный выход» включает эк-
земпляры «материал» и «изделие», а также
обобщенное понятие «деталь». Класс «инфор-
мационные услуги» охватывает понятие «за-
каз» вместе с двумя его дочерними классами,
а также понятие «сертификат». Формирова-
ние этого класса зависит и от его назначения.
В роли элементов метаклассов могут высту-
пать либо обобщенные классы 2-го уровня,
либо их подклассы.
При формировании классов вовсе не обя-
зательно любой ценой избегать их взаимного
наложения. Например, с точки зрения потока
выходов, можно сгруппировать классы «за-
каз» и «сертификат» в класс «информацион-
ные услуги». Между тем, с информационной
точки зрения, они являются также и объек-
тами данных, одновременно становясь, таким
образом, экземплярами класса «объекты
данных».
Если применить эту процедуру к модели
бизнес-процесса на рис. 10, где приведено
описание 2-го уровня, то получится общая
ARIS-модель бизнес-процесса 3-го уровня,
показанная на рис. 13. На этом рисунке иллю-
стрируются общие классы описания бизнес-
Базовая модель бизнес-процесса в ARIS 27
Рис. 12. Уровни абстракции в моделировании
28 Бизнес-процессы
Условные обозначения: ————► поток 1
IIOIW pcvypiAjD
-------------- Управляющий поток
..............Информационный поток
..............► Поток информационных услуг
..............►- Поток материального выхода
------........поток финансовых ресурсов
Рис. 13. Общая ARIS-модель бизнес-процесса
Базовая модель бизнес-процесса в ARIS 29
процессов и отношения между ними. Отноше-
ния, обозначенные стрелками, тоже можно
было бы представить как классы (классы от-
ношений). Однако для простоты мы не стали
этого делать, В дальнейшем под метакласса-
ми мы будем подразумевать любой объект
представления (классы и отношения).
Помимо описанных здесь отношений,
между классами возможны и другие реле-
вантные отношения. Кроме того, классы
мета-уровня можно разбивать на подклассы.
Модель на рис. 13, хотя ее нельзя считать ис-
черпывающей, отражает важнейшие объек-
ты, необходимые для представления бизнес-
процессов.
Таким образом, классы на 3-м уровне мо-
делирования определяют каждый объект,
необходимый для описания фактов на 2-м
уровне. Эти объекты служат стандартными
блоками, или «кирпичиками» для описания
приложений на 2-м уровне. С другой стороны,
поскольку классы 2-го уровня используют
терминологию 1-го уровня, то объекты 3-го
уровня образуют также инфраструктуру для
описания конкретных бизнес-процессов.
Этот процесс абстрагирования можно про-
должить, группируя теперь уже классы 3-го
уровня и относя полученные группировки к
мета2-уровню. Затем выполняется абстраги-
рование от содержания модели. На рис. 12 по-
казано формирование общего класса «тип
объекта», экземплярами которого являются
все метаклассы.
Уровни моделирования и описание мета2-
уровня более подробно мы рассмотрим в раз-
деле Д.2.
30 Бизнес-процессы
В. Разработка архитектуры
интегрированных
информационных систем
(здание ARIS)
Метамодель бизнес-процесса 3-го уровня
описывает характеристические классы и их
взаимоотношения, с помощью которых мож-
но моделировать фактические прикладные
процессы 2-го и 1-го уровней. Поскольку
объекты 2-го уровня являются экземплярами
метауровня, можно использовать только те
объекты, классы которых определены на ме-
тауровне. В свою очередь типы бизнес-про-
цессов, смоделированные на 2-м уровне, оп-
ределяют структуру реальных конкретных
процедур на 1-м уровне. Таким образом, ме-
тамодели по существу определяют возмож-
ности проектирования бизнес-процесса.
Вследствие большого разнообразия клас-
сов и их семантических взаимоотношений
модели бизнес-процессов могут быть струк-
турированы с высокой степенью детализа-
ции. Полученная при этом структура называ-
ется «Архитектурой интегрированных ин-
формационных систем» (ARIS).
Метамодель бизнес-процесса, приведен-
ная на рис. 13, объединяет следующие классы:
— контекстные данные, описывающие ин-
фраструктуру процесса;
— исходные и результирующие события;
— сообщения;
— функции;
— человеческий ресурс;
— технические ресурсы и компьютерные
средства;
— прикладное программное обеспечение;
— материальный выход, выход в виде ус-
луг и информационные слуги;
— финансовые ресурсы;
— организационные единицы;
— корпоративные цели.
Поскольку каждый класс может быть свя-
зан с другим классом, структура системы до-
статочно сложна. Семантические отношения
между классами и соответствующими функ-
циями, представленные на рис. 13, отражают
лишь фрагмент множества возможных взаи-
моотношений.
Многообразные отношения могут суще-
ствовать и между самими классами. Напри-
мер, отношение между функциями и челове-
ческим ресурсом зависит также от того, ка-
кой ресурс обеспечивает выполнение
процесса. Кроме того, отношения внутри
классов могут описывать зависимость между
объектами данных или связь между события-
ми.
Для упрощения в разделе В.1 классы со
сходными семантическими взаимоотношени-
ями сгруппированы в описания (модели)
ARIS различных типов. Это дает возмож-
ность рассматривать связи в рамках той или
иной модели, избавляя от необходимости сра-
зу же учитывать весь комплекс взаимоотно-
шений с другими моделями.
До сих пор мы обсуждали бизнес-процес-
сы больше с точки зрения управления бизне-
сом, не останавливаясь подробно на исполь-
зовании информационных технологий (ИТ).
Однако поскольку одной из ключевых тем
этой книги является внедрение бизнес-моде-
лей в информационные системы (ИС), в раз-
деле В.2 мы введем понятие жизненного цик-
ла, шаг за шагом трансформируя классы биз-
нес-процессов в объекты ИС.
Для более детального описания этих взаи-
моотношений требуется более формализо-
ванный язык, чем в предыдущем материале
книги. Этот язык разрабатывается в разделе
В.З для создания эскиза информационной мо-
дели. Концепция ARIS иллюстрирует также
принцип описания бизнес-процессов. Для
этой цели мы построим эскиз процедурной
модели в разделе В.4.
Разработка архитектуры 31
Цель
Информа-
ционные
услуги
к
Преобразует
Активизирует
Финансовые
ресурсы
Материаль-
ный выход
Начальное
событие
Прочие
услуги
Информа-
ционные
услуги
Контекст-
ные дан-
ные
Прочие
услуги
Вход
(обрабатывается)
Материаль-
У ный выход
о
Человечес-
кий ресурс
Машинный
ресурс
Финансовые
ресурсы
Результат/
Событие
I Програм- ।
I мноеобес-|
1 лечение 1
Компьютер-
ное обору-
дование ,
ционная
единица
Рис. 14а. Функциональная модель
Выход
(создается)
Организа-
Сообщение
Функция

В.1. Типы моделей в ARIS
Группировка классов и отношений между
ними в модели служит для структурирова-
ния и совершенствования бизнес-процессов.
Разбивка на модели имеет дополнительное
преимущество: она позволяет устранить из-
быточность, часто возникающую при нео-
днократном использовании объектов в моде-
ли процесса. Например, одни и те же контек-
стные данные, события или организационные
единицы могут относиться к ряду функций.
Можно также применять методы моделиро-
вания, ориентированные на различные типы
моделей, которые на практике доказали свою
состоятельность. В частности, процедуры,
относящиеся к различным типам моделей, с
этой точки зрения отличаются от более тео-
ретических концепций моделирования, где
системы для упрощения разбиваются на под-
системы, однако, каждая подсистема изобра-
жается тем же способом, что и исходная сис-
тема. Именно поэтому для одной и той же сис-
темы при таком подходе невозможно
применять разные методы моделирования.
32 Бизнес-процессы
Рис. 146. (Иерархическая) организационная модель
Модели ARIS различных типов строятся в
соответствии с критерием «семантического
корреляционного сходства». На рис. 14а-г
представлены модели ARIS, рассматривае-
мые в контексте метамодели бизнес-процес-
са, приведенной на рис. 13. Благодаря прямой
связи уровней описания эти модели сохраня-
ют силу для уровней 2 и 1.
Хотя в метамоделях бизнес-процессов ис-
пользуются только предварительные обозна-
чения классов, относящиеся преимуществен-
но к оизнес-операциям, эти модели пригодят-
ся впоследствии для детализации и реализа-
ции классов в категориях PIT и концепции
жизненного цикла.
При создании моделей используются раз-
личные потоки, о которых шла речь в разделе
Б.2.1. В результате получаются следующие
виды моделей ARIS.
Разработка архитектуры 33
Рис. 14в. Модель данных
Функциональные модели. Процессы, —
преобразующие вход в выход, группи-
руются в функциональную модель (см.
рис. 14а). Обозначения «функция»,
«процесс» и «операция» употребляются
как синонимы. В связи с тем, что функ-
ции тесно связаны с целями, поскольку
они направлены на их достижение и
подчиняются их управлению, цели так-
же относят к функциональным моде-
лям. В прикладных системах (ПС) опи-
сываются правила компьютерной обра-
ботки функции. Таким образом, ПС ____
адекватно подходит под определение
«функций» и также относится к функ-
циональной модели.
Организационные модели. Класс орга-
низационных моделей служит для опи-
сания иерархической структуры орга-
низации. В организационных моделях
группируются субъекты ответственно-
сти и средства, выполняющие работу
над одним и тем же объектом. Именно
поэтому сущность «человеческий ре-
сурс», а также средства «финансовые
ресурсы» и «компьютерная техника»
относятся к организационной модели
(см. рис. 146).
Модель данных. Модели данных опи-
сывают информационный контекст
(среду обработки данных), а также со-
общения, активизирующие функции
34 Бизнес-процессы
Рис. 14г. Модель выходов
или активизируемые ими. С именами —
данных можно также связать предва-
рительные детали, касающиеся функ-
ции информационных систем как носи-
телей данных. В моделях данных неяв- _
ным образом фиксируются также
объекты в виде информационных услуг.
Однако в основном такие объекты опи-
сываются в моделях выходов. Объекты
модели данных представлены на
рис. 14в.
Модели выходов. Модели выходов со-
держат все физические и нефизичес-
кие входы и выходы, включая потоки
денежных средств (см. рис. 14г).
Модели управления / модели процесса.
В этих моделях соответствующие клас-
сы моделируются с учетом их внутрен-
них взаимоотношений. Представление
отношений между отдельными моделя-
ми, так же как и в рамках всего бизнес-
процесса, в виде управляющих моделей
(или моделей процесса) позволяет по-
Разработка архитектуры 35
стоянно отслеживать все двусторонние
отношения между моделями различ-
ных типов, а также полностью описать
процесс.
В теории систем мы можем провести раз-
граничение между структурой системы и ее
поведением. Понятие структуры охватывает
статичное представление системы, а поведе-
ние описывает ее динамику. В моделях биз-
нес-процессов динамика выражается управ-
лением событиями и потоком сообщений. Мо-
дели функций, организации, данных и
выходов описывают структуру системы. Мо-
дели управления показывают все структур-
ные связи в рамках упомянутых моделей и
описывают динамическое поведение потока,
отображающего бизнес-процесс.
На рис. 15 приведены модели и некоторые
их классы, образующие «здание» ARIS. Мо-
дель процесса представлена в виде модели
управления. Показано также происхождение
объектов модели управления и индивидуаль-
ных моделей различных типов.
36 Бизнес-процессы
В.2. Фазовая модель ARIS
До сих пор мы обсуждали бизнес-процес-
сы с точки зрения управления, т. е. не делая
акцента на информационной технологии.
Рассмотренные выше прикладные системы
(компоненты функциональной модели), ком-
пьютерная техника (компонент организаци-
онной модели) и носители данных (компонен-
ты модели данных) содержат только имена
систем, но не описания в категориях ИТ. Пос-
ледние включаются в концепцию ARIS в за-
висимости от степени использования элемен-
тов ИТ в рамках каждой модели.
— Функциональные модели поддержива-
ются прикладными системами, которые
более детально описываются на уровне
отдельных модулей, транзакций или
языков программирования.
— Организационные модели, наряду с их
производственными и компьютерными
ресурсами, можно детализировать пу-
тем перечисления сетевых понятий, ап-
паратных компонентов и других техни-
ческих спецификаций.
— Модели данных можно детализировать
посредством указания моделей данных,
путей доступа и использования памяти.
— Модели выходов могут иметь различ-
ные типы выходов, например, матери-
альный выход и информационные услу-
ги. Здесь существует тесная связь с ка-
тегориями ИТ. В материальном выходе
(например, в развлекательной технике,
автомобилях и станках) наряду с необ-
ходимыми аппаратными средствами
используется все больше компонентов
ИТ (например, технология микросхем).
Другие сферы услуг, скажем, резерви-
рование авиабилетов, также тесно свя-
заны с ИТ.
— Поскольку соответствующие модели
можно объединить в рамках модели уп-
равления, то, согласно приведенной
выше аргументации, в ней определенно
существует связь с элементами ИТ.
Таким образом, описания бизнеса с помо-
щью фазовой модели поэтапно трансформи-
руются в объекты информационных и комму-
никационных технологий.
Фазовые модели характеризуют этапы
описания реализации вопросов бизнеса по-
средством компьютерных систем. Этот про-
цесс реализации часто описывают с помощью
различных концепций (Olle et al. Information
Systems Methodologies. 1991, c.46; Gesamt-
struktur des V-Modells. in Brohl, Droschel. V-
Modell. 1995, c. 21-30). ARIS-модель включает
пять фаз (см. рис. 16).
На фазе 1 описывается текущее состояние
деятельности (или одного из ее направлений)
в контексте стратегических установок и с
ориентацией на использование ИС. «Ориен-
тация на использование ИС» подразумевает,
что основные виды связей объектов и катего-
рий ИТ с новыми корпоративными концепци-
ями уже приняты во внимание. Примерами
здесь могут служить создание виртуальных
компаний через коммуникационные сети,
электронные банковские операции, компью-
терная обработка заказов, разработка про-
дуктов в промышленности (CIM), интегриро-
ванные системы управления товарами
(MMS) в розничной торговле.
Стратегическое планирование отражает
долгосрочные корпоративные цели организа-
ции, общие корпоративные функции и ресур-
сы. Таким образом, стратегические установ-
ки определяют в долгосрочной перспективе
бизнес-процессы организации, включая кор-
поративные цели, критические факторы ус-
пеха и распределение ресурсов. Обсуждае-
мые методы «адаптированы» к представле-
нию концепций управления
бизнес-процессами с точки зрения стратеги-
ческого планирования. Если фактические
бизнес-процессы уже описаны, это происхо-
дит обычным способом. На данном этапе не-
желательно разбивать процессы и функции
на модели ARIS и описывать их в деталях.
Фаза 2 посвящена определению требова-
ний. На этом этапе создаются подробные мо-
дели (каждого типа) прикладной системы. И
здесь тоже ключевое место занимает органи-
зационное содержание бизнеса. На этом
Разработка архитектуры 37
/
о
энаон ен УЛ

Рис. 16. Фазовая модель ARIS
38 Бизнес-процессы
уровне следует включить примеры оизнес-
процессов, особенно ARIS-модель бизнес-
процесса, представленную на рис. 10.
Однако на этой фазе, в отличие от страте-
гического подхода, необходимы более форма-
лизованные языки описания, поскольку опи-
сания, предназначенные для определения
требований, являются отправной точкой для
реализации ИТ. Языки описания должны
быть понятны с точки зрения бизнеса, чтобы
служить отправной точкой для последова-
тельного внедрения ИТ. Кроме того, на дан-
ном уровне имеет смысл включить в описание
общие объекты ИТ типа баз данных или про-
грамм.
Фаза 3 связана с разработкой специфика-
ции проекта, где бизнес-модели адаптируют-
ся к требованиям интерфейсов инструмен-
тальных средств реализации ПС (баз данных,
сетевых архитектур, языков программирова-
ния и т.д.). На этом этапе реальные программ-
ные продукты по-прежнему не имеют значе-
ния.
Фаза 4 предполагает создание описания
реализации, где разработанные требования
реализуются в виде физических структур
данных, аппаратных компонентов и реаль-
ных продуктов.
Эти четыре фазы описывают создание ин-
формационной системы и поэтому называют-
ся «конструктивным временем». Позже за-
конченная система принимает работоспособ-
ный вид и вступает в эксплуатационную
фазу, которая получила название «реального
времени». В нашей монографии эксплуата-
ция информационных систем, т. е. их реаль-
ное время, подробно не рассматривается.
Фаза определения требований тесно свя-
зана с уровнем стратегического планирова-
ния, о чем свидетельствует самая широкая
стрелка на рис. 16. Однако более узкая стрел-
ка, указывающая на спецификацию проекта,
означает, что эта фаза не зависит от конкрет-
ной реализации проекта.
С другой стороны, описание реализации и
эксплуатация тесно связаны с «уровнем ап-
паратно-программной поддержки». Измене-
ния в информационных технологиях системы
немедленно сказываются на типе реализации
и эксплуатации.
Фазовая концепция не предполагает такой
жесткой последовательности в процессе раз-
работки, как это требуют «модели водопада».
Скорее, эта концепция включает в себя про-
цедуру эволюционного создания прототипов
(Boehm. Spiral Model. 1988 и Floyd. Systematic
Look at Prototyping. 1984). Однако даже при
эволюционной разработке программного
обеспечения обычно используются представ-
ленные уровни описания. Фазовые модели
применяются прежде всего потому, что они
предлагают широкий спектр объектов и ме-
тодов описания.
Здание ARIS на рис. 17 дополнено четырь-
мя фазами ARIS-модели конструктивного
времени. После создания общего концепту-
ального проекта бизнес-процессы разбива-
ются на модели различных типов и докумен-
тируются, проходя путь от этапа определе-
ния требований к этапу описания
реализации. Эти три уровня описания созда-
ются также и для целей управления. Благо-
даря этому становится возможным создание
связей с другими компонентами на каждом
уровне описания.
Здание ARIS на рис. 17 иллюстрирует ар-
хитектуру информационной системы. Эта ар-
хитектура, включающая набор моделей раз-
личных типов, подразделяется на определе-
ние требований, спецификацию проекта и
описание реализации и тесно связана с кате-
гориями ИТ.
Концепция ARIS нацелена на создание и
управление бизнес-процессами организации.
Помимо связи со стратегическими установ-
ками, она перекликается со стратегическим
управлением информацией (Кгстаг.
Informationsmanagement. 1997; Schmidt.
Informationsmanagement. 1996).
Управление информацией предполагает
планирование, регулирование и внедрение
«информационного» ресурса. Поэто-
му Воллник в модели-прототипе (Wollnick.
Referenzmodell des Informationsmanage-
ments. 1988) выделяет три аспекта: управле-
ние инфраструктурой (управление инфор-
мационными технологиями), управление
прикладной системой и управление внедре-
нием информационных систем. Эти опреде-
Разработка архитектуры 39
Здание ARIS
Описание реализации
Определение
требований
Определение
требований
Определение
требований
Стратегический анализ
бизнес-процесса и целевое
концептуальное проектирование
Определение
требований
Спецификация
проекта
Спецификация Спецификация Спецификация
проекта В проекта И проекта
Данные
Описание
реализации
Описание
реализации
Определение требований
Спецификация проекта
Описание реализации
Описание
реализации
^Управление Функция
Выход
Рис. 17. Здание ARIS и фазовая модель
40 Бизнес-процессы
Корпоративная
стратегия
Управление
информацией
Рис. 18. Здание ARIS, дополненное связями с корпоративной
стратегией и управлением информацией
ления вписываются в концепцию ARIS. Пер-
вая задача, связанная с инфраструктурой,
охватывает уровни информационных техно-
логий и спецификации проекта, представ-
ленные на рис. 18. Вторая задача относится к
управлению информационными системами и
включает реализацию организационных тре-
бований в автоматизированных информаци-
онных системах с помощью концепции жиз-
ненного цикла ARIS, фокусируя внимание на
фазах конструктивного времени. Третья за-
дача — управление внедрением информаци-
онных систем — относится к фазе реального
времени в модели жизненного цикла ARIS.
В результате влияния информационных
технологий на организационные проблемы и
происходящие изменения (оно обозначено на
рис. 18 стрелкой слева), возникает связь меж-
ду управлением информацией и корпоратив-
ной стратегией (правая часть рисунка). Та-
ким образом, концепция ARIS делает более
прозрачной реализацию стратегических ус-
тановок и создает инфраструктуру для более
эффективного управления информацией.
В.З. Предварительная
информационная модель
ARIS
Здание ARIS создает «каркас» для класси-
фикации описательных компонентов бизнес-
процесса. Теперь обсудим подробнее отдель-
ные «кирпичики» бизнес-процесса и отноше-
ния между ними. Мы будем рассматривать
метауровень, где фиксируются элементы об-
щего бизнес-процесса, т.е. без контекстной
привязки к конкретным бизнес-процессам.
Основой для этого послужит ARIS-модель
бизнес-процесса, представленная на рис. 13.
Рис. 19. Предварительная информационная модель ARIS
Класс
Связь с
классом
Связь с
классом
Связь
"часть целого"
Связь как класс
Разработка архитектуры
42 Бизнес-процессы
Выход
Мета-бизнес-процесс ARIS
Архитектура (Здание ARIS)
Рис. 20. ARIS-компоненты метауровня ARIS
Исследуем ее теперь более подробно, анали-
зируя отношения между элементами. Вос-
пользуемся при этом унифицированным
языком описания и унифицированными сим-
волами для обозначения различных элемен-
тов (функций, организационных единиц, ре-
сурсов, сообщений и т. д.), а также их взаимо-
отношений.
Модель сущность—отношение (ERM),
предложенная Ченом (Chen. Entity-
Relationship Model. 1976), прекрасно подхо-
дит для описания объектов. Хотя изначально
эта модель предназначалась для представле-
ния структур данных в прикладных систе-
мах, она может служить и языком общего
описания, а, следовательно, ее можно приме-
нить и к описанию метауровней.
При объектно-ориентированных подходах
(Rumbaugh et al. Object-Oriented Modeling and
Design. 1991) в объектную модель тоже вво-
дятся классы и их отношения. Однако с ними
связываются и определенные методы. Что
касается объектов моделирования, то на ме-
тауровне они идентичны (например, когда
речь идет о создании, удалении, редактиро-
вании или графическом выводе объекта).
Кроме того, в объектно-ориентированных
моделях на стадии анализа допустимо ис-
пользовать только классы и их имена, т. е. ат-
рибуты и методы опускаются (подробное об-
суждение методов моделирования и метамо-
делей вы найдете в работе: Scheer. ARIS -
Business Process Modeling. 1998).
В первом издании этой книги в качестве
языка описания мы применяли расширенную
модель ERM. Однако сейчас в объектно-ори-
ентированном моделировании все шире при-
меняется язык UML - унифицированный
язык моделирования (см. UML Notation
Guide. 1997; UML Semantics. 1997; о внедре-
нии UML можно прочесть, в частности, в
работе: Oestereich. Objektorientierte Software-
entwicklung. 1997), поэтому для иллюстрации
классов мы воспользуемся именно этим язы-
ком. Что касается содержания, то оба языка
взаимозаменяемы.
Язык описания UML позволяет отдельно
представлять классы объектов и классы свя-
зей в моделях различных типов. Такое пред-
ставление известно как метамодель ARIS
или информационная модель ARIS.
Разработка архитектуры 43
Выход
Модели данных
Функциональные
> модели
Организационные
модели
Модели выходов
Модели
управления
Информационная модель ARIS
Репозиторий ARIS
В то же время эта информационная мо-
дель описывает конструкцию базы данных,
где можно хранить модели реального мира,
разработанные с помощью методологии
ARIS. Организационные и функциональные
модели, равно как и модели данных, выхода и
управления, относящиеся к тому или иному
приложению, рассматриваются как экземп-
ляры базы данных, построенной в соответ-
ствии с информационной моделью. Такие
базы данных называются репозиториями.
Понятие «репозиторий» приобрело популяр-
ность в 1989 году, когда корпорация IBM про-
возгласила новую концепцию разработки
программного обеспечения — AD/CYCLE
(Winter, Маад. AD/CYCLE. 1990; Fosdick. Ten
Steps to AD/CYCLE. 1990; Hofinger. IBM
Repository Manager. 1991).
Для каждой модели ARIS (функциональ-
ной, организационной, данных, выхода и уп-
равления) репозиторий ARIS содержит мо-
дели 2-го уровня, а также их отношения и мо-
дели для каждой фазы жизненного цикла
ARIS. При моделировании на 1-м уровне, т. е.
на уровне 1 экземпляров ARIS, репозиторий
необходимо обновлять, вводя в него соответ-
ствующие экземпляры процесса.
Таким образом, репозитории становятся
ядром информационной системы. Важность и
значение информационной модели, содержа-
щейся в репозитории, определяется ее спо-
собностью оказывать решающее влияние на
эффективность элементов описания.
Язык UML оперирует диаграммами клас-
сов, которые изображаются прямоугольни-
ками, и ассоциативными связями (или просто
связями), которые в свою очередь изобража-
ются рамками. Связи различаются по мощно-
сти отношений 1:* (один ко многим), 1:1 (один
к одному), *.* (многие ко многим) или *:1 (мно-
гие к одному). Звездочка может означать
«много» или «п».
С помощью этих простых элементов на
рис. 19 представлен эскиз информационной
модели ARIS. В каждой модели описываются
лишь несколько рассмотренных до сих пор
классов вместе с их связями. Из различных
элементов жизненного цикла сюда включена-
только фаза определения требований, т. е.
характеристики, связанные со спецификаци-
ей проекта и описанием реализации, не ис-
пользуются. Информационная модель, изоб-
раженная на рис. 19, дает общее представле-
44 Бизнес-процессы
ние об этом типе модели. Более подробно ме-
тодология моделирования описана в работе:
Scheer. ARIS ~ Business Process Modeling.
Отправными точками функциональной
модели на рис. 19 являются корпоративные
цели, которые управляют функциями; други-
ми словами, для достижения той или иной
цели должны быть выполнены определенные
функции. Корпоративные цели обычно клас-
сифицируются по иерархическому принци-
пу. Общие цели, такие как «максимизация
прибыли», «достижение определенной ры-
ночной доли» или «достижение определенно-
го темпа роста», разделяются на подцели, на-
пример, «достижение определенной суммы
дохода», «снижение расходов на определен-
ную сумму» или «достижение определенного
уровня качества». Благодаря интегрирован-
ной структуре целей класс КОРПОРАТИВ-
НЫЕ ЦЕЛИ характеризуется связью *:*. По-
скольку подцели входят в главные цели, они
характеризуются связью «часть целого». Та-
кая связь называется целевой структурой.
Она выделяется в самостоятельный класс.
Примерами функций являются обработка
заказов, продажа или регулирование, кото-
рые могут быть детализированы на составля-
ющие их подфункции. Взаимосвязь между
функциями, равно как и связь функций с це-
лями, на достижение которых они направле-
ны, предполагает между ФУНКЦИЕЙ и
КОРПОРАТИВНЫМИ ЦЕЛЯМИ отношение
типа *:*. ФУНКЦИОНАЛЬНАЯ СТРУКТУ-
РА представляет собой связь «часть целого»,
определяя функции, содержащиеся в других
функциях.
Центральным элементом в организацион-
ной модели является ОРГАНИЗАЦИОННАЯ
ЕДИНИЦА. Этот класс включает такие эк-
земпляры, как ПОЗИЦИЯ, ПОДРАЗДЕЛЕ-
НИЕ или ПРЕДПРИЯТИЕ. Независимо от
того, являются эти области подчиненными
или главными, они всегда характеризуются
связью Г* - это «часть целого» в рамках клас-
са ОРГАНИЗАЦИОННАЯ ЕДИНИЦА. Та-
ким образом, эта связь позволяет одной обла-
сти выступать в качестве подчиненной по от-
ношению к нескольким другим. Это относит-
ся, например, к отделу продаж, который свя-
зан с рядом основных областей,
производящих продукт. Ответственные
субъекты или средства («машины», «компью-
тер», «человеческий ресурс») связываются с
организационными единицами.
Модель данных (левая часть здания ARIS)
отображает структуру данных. Класс ИН-
ФОРМАЦИОННЫЙ ОБЪЕКТ характеризу-
ет объекты, описываемые атрибутами баз
данных. Между их экземплярами, такими
как данные об изделии и данные о клиенте,
существуют связи (например, какой клиент
какие изделия покупает). Эти связи выража-
ются отношением *:* внутри класса ИНФОР-
МАЦИОННЫЙ ОБЪЕКТ.
Информационные объекты, относящиеся
к области с взаимосвязанным содержанием,
можно сгруппировать в диаграмму класса
или модель данных. Поскольку из-за иден-
тичных информационных объектов МОДЕЛЬ
ДАННЫХ и ИНФОРМАЦИОННЫЙ
ОБЪЕКТ могут частично накладываться
друг на друга, они связаны отношением *:* -
«часть целого».
В модели выходов класс ВЫХОД пред-
ставляет все виды выходов (материальный
выход, услуги и информационный выход).
Экземплярами выступают классы выходов,
связанные с прикладным уровнем, например,
изделие, материалы, запчасти, время сборки,
гарантийные услуги или сертификаты. Здесь
также различные виды выходов могут быть
взаимосвязаны (отношением «часть целого»).
Связи между всеми четырьмя компонен-
тами (организация, функция, информация и
выходы) представлены в модели управления.
Связь между ОРГАНИЗАЦИОННОЙ
ЕДИНИЦЕЙ и ФУНКЦИЕЙ выражается от-
ношением ОТВЕТСТВЕННОСТЬ.
Организационным единицам могут быть
присвоены определенные привилегии, отно-
сящиеся к ИНФОРМАЦИОННЫМ ОБЪЕК-
ТАМ, которые выражаются отношением
ПРИВИЛЕГИИ ДОСТУПА.
Полная функциональная модель ARIS,
представленная в работе Scheer. ARIS -
Business Modeling. 1998, подробно описывает
классы и отношения между ними в модели
мета-бизнес-процесса. Она описывает также
Разработка архитектуры 45
все модели ARIS, охватывающие фазы жиз-
ненного цикла. Эта модель включает около
300 классов и связей.
Информационная модель ARIS представ-
ляет собой схему репозитория для хранения
соответствующих прикладных моделей. Дан-
ные, хранящиеся в репозитории, включают
классы реальных приложений (например,
для сферы продаж или бухгалтерского уче-
та), хотя обычно - на уровне типов. В то время
как объекты типа КЛИЕНТ и ИЗДЕЛИЕ хра-
нятся в репозитории в качестве экземпляров
класса ИНФОРМАЦИОННЫЙ ОБЪЕКТ,
сами экземпляры, т. е. индивидуальные сущ-
ности «клиент» и «изделие» 1-го уровня, как
правило, хранятся в базе данных о продажах.
При моделировании процессов на уровне эк-
земпляров (например, для приложений
workflow) соблюдать это правило не обяза-
тельно.
На рис. 20 сгруппированы четыре компо-
нента метауровня с указанием их взаимосвязей:
- — мета-бизнес-процесс ARIS,
— архитектура (Здание ARIS),
— информационная модель ARIS,
— репозиторий ARIS.
В.4. Предварительная
процедурная модель ARIS
Концепция ARIS предоставляет методо-
логию описания бизнес-процессов от этапа
определения требований до этапа описания
реализации. Примером может служить обра-
ботка заказов, жалоб или страховых исков.
Проведение реорганизации тоже можно
интерпретировать как бизнес-процесс. В
силу того, что реорганизация предполагает
участие многочисленного штата сотрудников
(как своих, так и посторонних), выполнение
множества функций, составление и исполь-
зование несметного количества документов,
не помешает заранее спланировать этот про-
цесс, руководствуясь концепцией ARIS.
Процедурная модель ARIS описывает, как
реализовать концепцию ARIS, т.е. как необ-
ходимо организовать управление проектом,
определить функции и получить пакет вы-
ходных документов на базе ARIS. Процедур-
ная модель ARIS описывает концепцию
ARIS, пользуясь средствами ARIS.
Процедурные модели можно строить и на
уровне типов (2-й уровень моделирования). В
этом случаи они могут служить моделями ре-
ального проекта. Процедурные модели для
реорганизации бизнес-процессов (английс-
кая аббревиатура - BPR), разработки про-
граммного обеспечения, реализации систем
workflow или стандартных программных ре-
шений можно найти в приложениях и науч-
ных публикациях. Эти модели используются
для создания процедур применительно к кон-
кретным проектам.
Если подробное описание процедурной мо-
дели отсутствует, это не столь уж важно. На-
пример, процедурная модель BPR, предло-
женная Хэммером и Чампи (Hammer,
Champy. Business Reengineering. 1995, с. 153),
содержит всего пять функций: мобилизацию,
диагностику, перепроектирование, переход и
управление изменениями. Последняя функ-
ция осуществляется одновременно с первы-
ми четырьмя фазами. С другой стороны, для
разработки программного обеспечения суще-
ствует широкий диапазон процедурных мо-
делей, в том числе V-модель Координацион-
ного и консультативного управления Герман-
ского правительства по информационной
технологии в федеральной администрации
(KBSt. V~Modell. 1992). Разработаны и раз-
личные модели для реализации workflow
(Gaiter. Vom Geschdftsprozefimodell zum
Workflow-Modell. 1997). Для облегчения реа-
лизации стандартных программных реше-
ний, в частности SAP/R3 и SAP, ряд консал-
тинговых фирм предлагает детальные проце-
дурные модели (Keller, Teufel. SAP R/3
prozefiorientiert anwenden. 1997, c. 177;
Meinhardt. Geschaftsprozeborientierte Ein-
fuhrung von Standard-Software. 1995; Kirchmer.
Implementation of Standard Software. 1998;
Plattner. Products & Organization. 1997).
46 Бизнес-процессы
Начало
проекта
Определение
требований на
уровне модели
управления (ЕРС)
' Определение
требований на
уровне модели
управления
t завершено
Создание
определения
требований на
уровне модели
выходов
Создание
определения
требований на
уровне организа-
ционной модели
Создание
определения
требований на
уровне модели
данных
Создание
определения
требований на
уровне функцио-
нальной модели
Определение
треоований
завершено
Создание
спецификации
проекта на
уровне функци-
ональном модели
Создание
спецификации
проекта на уровне
организаци-
онной модели
Создание
спецификации
проекта на уровне
модели данных
Создание
спецификации
проекта на уровне
модели выхода
Создание
спецификации
проекта на уровне
модели
управления
Спецификация
проекта
завершена
Описание
реализации на
уровне функци-
ональной модели
Описание
реализации
на уровне
организа-
ционной модели
Описание
реализации
на уровне модели
данных
Описание
реализации
на уровне модели
выхода
Проект
завершен
Рис. 21. Один из вариантов диаграммы ЕРС для процедурной
Описание
реализации
на уровне модели
управления
модели ARIS
Разработка архитектуры 47
Рис. 22. ARIS-модели «создания определения требований на уровне функциональной модели»
Помимо процедурных моделей различного
назначения, имеются коммерческие модели
для локальных целей, например, для модели-
рования данных (Szidzek. Datenmo-
dellierung-Vorgehensmodell. 1993). Процедур-
ная модель семантических объектов (SOM),
разработанная Зинцем и Ферстлем, предназ-
начена для внедрения объектно-ориентиро-
ванных методов в моделирование бизнес-
процессов (Ferstl, Sinz. SOM. 1993, с. 27).
На первый взгляд, процедурная модель
ARIS включает те же модели и фазы жизнен-
ного цикла, которые описаны в ARIS. Однако,
используя эти объекты и соответствующие
методы, процедурную модель ARIS можно
реализовать на гораздо более детальном
уровне. На рис. 21 процедурная модель, пред-
ставленная в виде последовательности про-
цессов, управляемых событиями (ЕРС), со-
стоит из функций и событий. Отношения пос-
ледовательности позволяют одновременно
реализовать модели функций, организации,
данных, выходов и управления для одной и
той же фазы. Определение требований начи-
нается с модели управления, т.е. с описания
процесса. При разбиении процессов на от-
дельные конкретные этапы может происхо-
дить наложение детализированных областей.
В рамках процессов можно задавать различ-
ные уровни детализации; однако придержи-
ваться жесткого принципа разбиения на
фазы, как в модели «водопада», отнюдь не
обязательно. Скорее, различные формы раз-
работки, например создание прототипов,
можно представить в виде некоторых упоря-
доченных отношений.
Помимо функций и событий, сюда можно
включить и другие элементы описания про-
цесса, например, организационные единицы,
данные и выход. На рис. 22 изображена схема
«создания определения требований на уров-
не функциональной модели».
— Модели данных содержат ключевые
вехи процедурной модели (т.е. события
и сообщения, инициирующие или за-
вершающие процесс) и контекстных
описаний (такие как модели, хранимые
в репозитории моделей).
— Функциональные модели предостав-
ляют стандартные блоки архитектуры
ИТ. С ними ассоциируется соответ-
48 Бизнес-процессы
ствующее программное обеспечение,
будь то текстовый процессор или инст-
рументы моделирования.
— Организационные модели описывают
подразделения, кадры и машинные ре-
сурсы, необходимые для отдельных
процессов.
— Модели выходов определяют входы и
выходы функций, т.е. управляющую и
функциональную модели.
До сих пор мы рассматривали процедур-
ные модели только на уровне определения
требований. Поскольку они содержат ИТ-
объекты, такие как репозитории моделей,
персональные компьютеры и прикладное
программное обеспечение (текстовые про-
цессоры, программы моделирования и т. д.),
процедурные модели можно перенести так-
же на фазы спецификации проекта и описа-
ния реализации.
На этапе спецификации проекта опреде-
ляются проектные характеристики для баз
данных репозитория, персональных компью-
теров и программных средств моделирова-
ния. Затем, на этапе описания реализации
описывается их реализация с точки зрения
информационных технологий. Если исполь-
зуется ARIS Toolset, то фаза спецификации
проекта является тем этапом, где принимает-
ся решение о внедрении одной или несколь-
ких пользовательских версий. На уровне опи-
сания реализации определяются реальные
параметры и фактические базы данных.
На базе общей процедурной модели можно
построить специализированные модели под
конкретные проекты. Например, при реин-
жиниринге информационной системы отдела
продаж общие функции типа «создание опре-
деления требований на уровне модели дан-
ных» дополняются функцией «создание мо-
дели данных и определение требований ин-
формационной системы отдела продаж».
Это сопоставимо с переходом от моделирова-
ния типов к описанию экземпляров. С другой
стороны, абстрагирование от конкретных от-
ношений в процедурной модели ARIS дает
общую метамодель ARIS на 3-м уровне моде-
лирования.
Подведем итоги:
1. Процедурная модель ARIS определяет-
ся соответствующей архитектурой
ARIS, описывающей бизнес-процессы.
2. Поскольку процедурные модели можно
рассматривать как модели бизнес-про-
цессов, они могут описываться теми же
концептуальными моделями ARIS, что
и любой другой бизнес-процесс.
3. Результаты каждой функции в проце-
дурной модели хранятся в репозитории
ARIS.
4. Репозиторий, т.е. информационная мо-
дель ARIS, является стандартной схе-
мой для хранения результатов, напри-
мер проекта базы данных. Эти резуль-
таты представляются в виде
функциональной модели, модели дан-
ных, организационной модели, мо-
дели выходов и управления.
5. Модель-прототип процедурной модели
также хранится в репозитории ARIS.
На рис. 23 показано, как процедурная мо-
дель ARIS соотносится с концепцией ARIS -
на этот раз на примере организации, занима-
ющейся продажей. Процедурная модель хра-
нится в репозитории ARIS и описывается на
2-м уровне. Ее логика определяется архитек-
турой ARIS и информационной моделью
ARIS. Представляя единичный процесс реа-
лизации проекта, процедурная модель, ори-
ентированная на конкретную предметную
область, является экземпляром общей проце-
дурной модели для разработки бизнес-про-
цессов с размещением их на 1-м уровне моде-
лирования. Процедурная модель в репозито-
рии соответственно модифицируется.
Пунктирные стрелки показывают, каким об-
разом метауровень определяет подчиненные
уровни, а сплошные иллюстрируют последо-
вательность операций в процедурной модели.
В итоге получаются модели продаж. Эти мо-
дели размещаются на 2-м уровне моделиро-
вания, описывая общие процессы продажи.
Рис. 23.
Уровень 3
Уровень 2
Уровень 1
Отношение между концепцией ARIS и информационной моделью ARIS
Разработка архитектуры

(О
50 Бизнес-процессы
Г. Управление бизнес-
процессами на базе ARIS.
ARIS — архитектура
бизнес-инжиниринга
Итак, концепция ARIS прокладывает путь
к инжинирингу, планированию и управлению
бизнес-процессами. Теперь проанализируем
ее преимущества, упомянутые в разделе А, а
также деловые, организационные и инфор-
мационно-технологические (ИТ) аспекты ее
реализации.
ARIS-архитектура бизнес-инжиниринга
(АБИ) расширяет архитектуру ARIS, позво-
ляя рассматривать управление бизнес-про-
цессами не только с организационной точки
зрения, но и с точки зрения информационных
технологий. Мы покажем, каким образом
ARIS способствует управлению бизнесом на
этапах проектирования и разработки с помо-
щью программных инструментов, совмести-
мых с ARIS.
ARIS АБИ дает владельцам бизнес-про-
цессов возможность сконцентрировать вни-
мание на различных аспектах построения и
описания своих бизнес-процессов, предос-
тавляя в их распоряжение полную инфра-
структуру для управления — от организаци-
онного инжиниринга до практической реали-
зации информационных технологий,
включая непрерывное адаптивное совершен-
ствование. Кроме того, АБИ позволяет осу-
ществлять планирование и управление теку-
щими бизнес-процедурами на постоянной ос-
нове, уделяя внимание их непрерывному
совершенствованию (Scheer. Workflow-
Systeme. 1997; Scheer. ARIS - House of
Business Engineering. 1996; Thome, Hufgard.
Continuous System Engineering. 1996). Инф-
раструктура АБИ опирается на всестороннее
знание специфики бизнеса, — важнейшую
предпосылку планирования и управления
производственными процессами. Такие
объекты, как «график работ» и «прейскурант
материалов», служат основой для детального
описания производственных процессов, а си-
стемы производственного планирования и
управления в среде АБИ позволяют решать
вопросы планирования и контроллинга этих
процессов. Многие из этих концепций и про-
цедур можно обобщить. Такая обобщенная
система управления процессами представле-
на на рис. 24.
— На уровне I (инжиниринг процессов)
бизнес-процессы моделируются в соот-
ветствии с производственным графи-
ком работ. Концепция ARIS предостав-
ляет инфраструктуру, которая охваты-
вает все аспекты бизнес-процесса.
Здесь же используются различные ме-
тоды оптимизации и оценки, а также
методы, гарантирующие качество про-
цессов.
— На уровне II(планирование и управле-
ние процессами) осуществляется пла-
нирование и управление текущими биз-
нес-процессами. Сюда же относятся ме-
тоды планирования, регулирования
мощностей и пооперационного стоимос-
тного анализа. Мониторинг позволяет
менеджерам контролировать состояние
различных процессов.
— На уровне III (управление потоками
работ) объекты, подлежащие обработ-
ке, например, заказы клиентов с сопут-
ствующей документацией или страхо-
вые иски, доставляются с одного рабо-
чего места на другое. Электронные
документы доставляются системами
класса workflow.
— На уровне IV (прикладная система) до-
кументы, доставленные на рабочее мес-
то, подвергаются определенной обра-
ботке, т. е. функции бизнес-процесса
выполняются с помощью прикладных
программных систем (от простых тек-
стовых процессоров до сложных про-
граммных решений), бизнес-объектов и
Java-аплетов.
Модели по°<^птипы Оценка
ПППНРГСПР ПрОТОТИПЫ иЦспКа
иппппХпо Управление Сравнение Имитация
рду в знаниями с эталоном
. РАБОЧЕЕ ПРОСТРАНСТВО
>
Составление
графиков и
управление
мощностями
Стандартные Компоненты
программные Бизнес-объекты Java-
модули Библиотеки аплеты
объектов
Рис, 24. Управление процессами на базе концепции здания ARIS
Управление бизнес-процессами на базе ARIS
52 Бизнес-процессы
Четыре уровня АБИ связаны между собой
контурами обратной связи. Уровень управле-
ния процессами предоставляет информацию
об эффективности текущих процессов. Имен-
но на этом этапе начинается непрерывная
адаптация и совершенствование бизнес-про-
цессов.
Уровень управления потоками работ пере-
дает фактические данные о процессах, под-
лежащих выполнению (суммы, сроки, выде-
ляемые ресурсы), на уровень управления
процессами. Затем система workflow активи-
зирует прикладные модули.
Пятый компонент концепции АБИ объеди-
няет уровни I-IV в единую инфраструктуру.
Инфраструктуры содержат информацию о
соответствующей архитектуре и приложе-
ниях, конфигурируя реальные приложения с
помощью инструментария уровней II и III, а
информацию по предметной области для них
— из моделей-прототипов (уровень I). Инф-
раструктуры включают также информацию
о составе компонентов и их отношениях (Ргее.
Komponentenbasierte Softwareentwicklung.
1997, с. 7).
Программное обеспечение на уровнях ин-
жиниринга и планирования процессов позво-
ляет владельцу бизнес-процесса взглянуть
на бизнес с организационной точки зрения.
Уровни же управления потоками работ и
прикладной системы относятся к конкретной
программной реализации. Модель жизненно-
го цикла ARIS применима к каждому из че-
тырех уровней. Поэтому на каждом уровне
любая программная система может быть опи-
сана с точки зрения определения требований,
спецификации проекта и описания реализа-
ции. Отношения между уровнями АБИ рас-
сматриваются преимущественно на уровне
определения требований, например: как ло-
гически перейти от модели процесса на уров-
не II к модели потоков работ на уровне III.
Здесь же анализируется совместимость про-
ектной спецификации для системы модели-
рования на уровне I с системой workflow на
уровне III, включая даже аспекты реализа-
ции. Уровни концепции АБИ перпендику-
лярны фазам жизненного цикла ARIS.
АБИ — это прежде всего концепция, одна-
ко ее можно использовать и как инфраструк-
туру для разработки реальных программных
продуктов. Концепция АБИ впервые предло-
жена автором на Саарбрюккенском семинаре
(Saarbrucken Arbeitstagung) в 1994 году. Она
применяется в качестве стандартной корпо-
ративной архитектуры в фирме IDS Prof.
Scheer GmbH и основана на практических
знаниях и опыте в области реальных при-
кладных систем. Концепция АБИ была пред-
ложена многим другим производителям про-
граммного обеспечения. Автор неоднократно
излагал ее в докладах и на презентациях. В
1996 году ей был посвящен обстоятельный
информационный документ (Scheer. ARIS -
House of Business Engineering. 1996).
Хотя концепция АБИ не привязана к кон-
кретным коммерческим разработкам, из
практических соображений мы излагаем ее
здесь применительно к различным продук-
там ARIS, системе SAP R/3 и Siemens-
Nixdorf ComUnity, по ходу дела ссылаясь и
на другие концепции создания программного
обеспечения.
В следующих разделах мы рассмотрим
уровни концепции АБИ более подробно.
Г. 1. Инжиниринг бизнес-процессов
Цель инжиниринга бизнес-процессов зак-
лючается в достижении максимально эффек-
тивных бизнес-решений. Ответственность за
инжиниринг может лежать на организацион-
ных подразделениях, группах внедрения
проектов по реструктуризации процессов
или даже на самих владельцах бизнес-про-
цессов. Если разработка производственных
графиков может годами находиться в веде-
нии одного отдела, то другие виды бизнес-
процессов не поддаются столь жесткой рег-
ламентации. Мы бы рекомендовали поручать
инжиниринг тем организационным структу-
рам, которые отвечают непосредственно за
бизнес-процессы.
Вообще, корпоративные бизнес-процессы,
такие как, например, стандартный процесс
закупки, проектируются на уровне типов.
Для некоторых подформ могут создаваться под-
типы (например, заказы на запасные детали,
Управление бизнес-процессами на базе ARIS 53
Условные обозначения:
Готовый Сборка Компонент,
продукт материалы
График работ
Рис. 25а. Модель продуктов и процессов
Прейскурант материалов
Финанси- Консуль- Гаран- Страхо- Регули- Автома-
рование тация тия вание ровка шина
График работ
модель А 160
ОП. Операция Продолжитель- Машина/
№ (ОП.) ность (мин.) Оператор
1 Колесо 5 Е 42
2 Окно 10 М3
3 Дверца со 8 Е 15
стороны
водителя
Рис. 256. Эквивалентные описания продуктов и процессов для различных услуг
54 Бизнес-процессы
Процесс питания в ресторанах
Процесс питания в закусочных
Рис. 25в. Взаимосвязь между изменениями процесса и продукта
обычные детали или детали, требующиеся
эпизодически). Однако отдельно для конк-
ретных деталей процессы заказа, как прави-
ло, не моделируются.
С другой стороны, производственные гра-
фики для изготовления конкретных деталей
действительно документируются. Это обус-
ловлено тем, что описания процессов служат
не только для того, чтобы обеспечить соблю-
дение основных корпоративных правил, но и
для непосредственного выполнения процес-
сов. Чем больше технологической документа-
ции используется для выполнения бизнес-
процессов (например, для управления пото-
ками работ в системах workflow), тем больше
требуется описаний конкретных экземпля-
ров процесса.
Для построения оптимальных бизнес-про-
цессов, наряду с лучшими образцами практи-
ки, можно применять модели-прототипы.
Возможны и такие методы, как сопоставле-
ние альтернативных процедур (эталонное
сравнение), имитационное моделирование и
оценка качества. Далее мы рассмотрим вспо-
могательные средства инжиниринга.
Г. 1.1. Моделирование продуктов и
бизнес-процессов
Инжиниринг бизнес-процессов начинает-
ся со стратегического корпоративного плани-
рования. На этом этапе определяются группы
производимых продуктов и базовые корпора-
тивные процессы. Продукты, разумеется, со-
здаются в результате выполнения процессов,
а необходимые бизнес-процессы разрабаты-
ваются с учетом особенностей данного вида
производства.
Термины «прейскурант материалов» и
«график работ» хорошо описывают взаимо-
отношения между моделями продуктов и
процессов в промышленном производстве.
Это видно из примера, приведенного на
рис. 25а. Прейскурант материалов описывает
состав готовых продуктов (в данном примере
Ш и П2), включающий операции сборки (С) и
компоненты (KI, К2). В графике работ указы-
ваются производственные процессы, необхо-
димые для изготовления каждой детали.
Иными словами, этот график включает опе-
рации (функции), подлежащие выполнению.
Графики работ обычно представлены в фор-
ме таблиц. Для одного компонента можно
описать несколько альтернативных графи-
ков работ. Например, для детали К2 можно
задать графики 1 и 2.
Независимые описания продуктов и про-
цессов позволяют связывать один (стандарт-
ный) график работ одновременно с несколь-
кими деталями (в приведенном примере гра-
фик работ 1 отнесен к готовым продуктам Ш
и П2). Готовые продукты могут различаться
по составляющим компонентам, однако это
может не влиять на производственный про-
цесс. Например, в химической промышленно-
сти некоторые продукты состоят из идентич-
ных компонентов, которые различаются по
цвету. В результате при одинаковой произ-
водственной технологии получаются разные
продукты. Независимые описания продуктов
и моделей процессов, а также возможность
их произвольного сочетания - важнейшие ус-
ловия для устранения избыточности при уп-
равлении данными.
В производственном секторе детальные
описания продуктов и процессов используют-
ся только в отношении физических продуктов.
Управление бизнес-процессами на базе ARIS 55
Рис. 26а. Фрагмент диаграммы ЕРС из модели-прототипа страхования, разработанной фирмой
KPMG на базе ARIS
56 Бизнес-процессы
Процесс
Рис. 266. Фрагмент диаграммы ЕРС из модели-прототипа R/3
Однако в настоящее время усиливается тен-
денция к поставке физических продуктов в
комплексе с услугами. Например, примени-
тельно к автомобилю это могут быть услуги
по страхованию и финансированию. Подоб-
ная ситуация иллюстрируется на рис. 256, где
наряду с графиком работ по созданию физи-
ческого продукта приведены диаграммы
ЕРС, описывающие процессы создания услуг.
Эти диаграммы представляют последова-
тельность функций, необходимых для закры-
тия страхового полиса или предоставления
кредита.
Полное моделирование продуктов и про-
цессов применительно к каждому физичес-
кому и нефизическому продукту открывает
возможность для унифицированного управ-
ления бизнес-процессами. Обязательной
предпосылкой для определения стоимости
продуктов и согласованного планирования и
управления бизнес-процессами является на-
личие всеобъемлющей процедуры расчета.
Позже мы остановимся на этом подробнее.
Ключевую роль в производстве продуктов
играют не только сами процессы, но и их фор-
мы, которые определяют типы создаваемых
продуктов. Верхняя диаграмма на рис. 25в
представляет различные процессы в созда-
нии продукта «питание в ресторанах». Они
включают такие функции, как заказ, обслу-
живание, еда и оплата. Питание же в заку-
сочных состоит из следующих функций: за-
каз, оплата, (самообслуживание и еда
(Pentland. Process Grammars. 1994).
Здесь тип процесса, особенно последова-
тельность функций, существенно влияет на
тип продукта. Таким образом, введение нов-
шеств в процесс приводит к созданию нового
продукта.
Г.1.2. Модели-прототипы
Модели-прототипы, разработанные при-
менительно к реальным условиям (лучшие
образцы практики) или построенные теоре-
тически, документируют ноу-хау процесса,
Управление бизнес-процессами на базе ARIS 57
Рис. 27. Топография знаний ( Scheer, Bold, Hagemeyer, Kraemer. Informationssysteme im Wandel.
1997, c. 27)
I
I
I
I
Рис. 28a. Управление знаниями, представленное в виде диаграммы ЕРС
58 Бизнес-процессы
Определены сферы
компетенции
Низкий коэффициент
актуализации
Эффективные взаимодействия
между сотрудниками
Время быстрого доступа
"Интеллектуальная" интрасеть
Оценка
знаний
Использо-
вание
знаний
Налажен "контроль за обучением"
Нет четкого разграничения
ответственности
Знания редко распространяются
на новые продукты
Бессчетное множество
непродуктивных внутренних отчетов
Аккумуляция
знаний
Сохранение
знаний
Нет практики "усвоения уроков"
Большая текучесть
Отсутствие нормативной
документации
Расширение
знаний
Распростра-
нение
знаний
Сотрудничество с университетами
Однобокость в комплектовании кадров
Практическое отсутствие лицензирования
Высокий уровень творческой
инициативы
Наличие первоклассных
экспертов
Пристальное внимание
к новейшим научным данным
Практическое отсутствие перемен
на организационном уровне
Интенсивный обмен информацией
в отдельных подразделениях
Обособленные "островки" знаний
Неэффективные совещания
Заштрихованная
область
= Нынешний уровень
Рис. 286. Профили знаний в компании (Probst, Raub, Rombardt. Wissen managen. 1997, c. 346)
которое используется для моделирования.
Можно разграничить процедурные модели
(или реализацию стандартного программного
обеспечения) и модели бизнеса, например,
для обработки заказов или внедрения про-
дуктов.
Можно создавать специализированные
модели для вертикальных рынков (получая
модели-прототипы вертикальных рынков).
Модели-прототипы ARIS, созданные консал-
тинговыми фирмами с богатым опытом рабо-
ты в области реальных проектов, имеются
фактически для каждого вертикального рын-
ка. Таким образом, основу коммерческих про-
дуктов составляют документально оформ-
ленные знания и практический опыт.
Модели-прототипы могут характеризо-
ваться исчерпывающей полнотой, охватывая
сотни и тысячи объектов. Этим и объясняется
применение различных уровней агрегирова-
ния (глубины детализации).
Модель-прототип может служить для
компании исходной позицией при создании
процессов, позволяя определить степень де-
тализации модели и содержательную часть с
точки зрения бизнеса. Адаптируя ее с учетом
специфики предприятия, можно получить
специализированную модель, ориентирован-
ную на конкретные нужды. Анализ проектов,
взятых из реальной практики, показал, что
применение моделей прототипов в корпора-
тивных проектах позволяет сократить время
и стоимость их реализации более чем на 30%.
Модели-прототипы, предлагаемые по-
ставщиками в виде программных пакетов
(наибольшей полнотой отличается SAP R/3),
обеспечивают клиенту существенные пре-
имущества, используя ноу-хау бизнес-про-
цессов и предоставляя возможность сравне-
ния различных программных решений и вы-
явления положительных и отрицательных
сторон их внедрения.
Управление бизнес-процессами на базе ARIS 59
Производственные стоимостные центры
Условные обозначения: BE = единица времени
ДЕ = денежная единица
Рис. 29. Вычисление стоимости производственного процесса
На рис. 26а-б показаны фрагменты моде-
ли-прототипа для вертикального рынка
страховых компаний, разработанной консал-
тинговой фирмой KPMG, и модели-прототи-
па SAP R/3. Они созданы в значительной
мере на базе концепции ARIS. Модель-прото-
тип страхования охватывает 543 функции, а
SAP R/3 — в несколько раз больше. Обе мо-
дели, помимо моделей процессов, включают
функциональные и организационные модели
и модели данных.
Фирма IDS Prof. Scheer GmbH предлагает
дополнительные модели-прототипы, постро-
енные на базе ARIS, для обрабатывающей,
энергетической, бумажной, финансовой и хи-
мической отраслей промышленности, а так-
же для сферы услуг.
Г.1.3. Управление знаниями
Ноу-хау бизнес-процессов все чаще рас-
сматривается как один из важнейших компо-
нентов управления корпоративными знания-
ми. Корпоративные знания включают ноу-
хау относительно продуктов, технологий,
рабочих процедур и правил, а также индиви-
дуальные знания и уменея каждого конкрет-
ного работника.
Одна из первоочередных задач управле-
ния знаниями заключается в документирова-
нии, хранении, использовании и расширении
этого базового ноу-хау.
Важный шаг к организации управления
знаниями — создание хранилища для корпо-
ративного ноу-хау. В организационной моде-
ли ARIS предусматрены функциональные
средства для представления хранилищ
структурированной корпоративной инфор-
мации о технологических процедурах и ре-
сурсах и даже о ноу-хау, которым обладают
конкретные работники.
На уровне модели данных знания фикси-
руются в виде документов, хранящихся на
традиционных носителях, а также в виде тек-
стовых, голосовых, графических и видео- до-
кументов.
Модель управления отражает связи меж-
ду различными типами знаний. Например,
профиль ноу-хау работника или, иначе гово-
ря, умения, приобретаемые работником при
выполнении определенной функции, можно
связать с другими функциями. Различные
иерархии создателей знаний по отношению к
компании (индивидуумы, группы, сама ком-
пания, группа компаний, альянсы компаний)
60 Бизнес-процессы
Стоимостные центры накладных расходов
Условные обозначения: ДЕ ~ денежная единица
Рис. 30. Информационная база пооперационного исчисления стоимости в управленческих
процессах
можно определить на уровне организацион-
ной модели ARIS, а затем связать их с типами
знаний в других моделях (см. рис. 27). Таким
образом, ARIS становится инфраструктурой
для «корпоративной памяти» или «хранили-
ща знаний».
Методы моделирования следует допол-
нить соответствующими типами знаний или
объектов, связанных с создателями знаний,
используемых или получаемых при выпол-
нении той или иной функции (см. рис. 28а).
Связка этих объектов в среде ARIS превра-
щает пути доступа в «карты знаний». Храни-
лища знаний выявляют и устраняют дефи-
цит знаний, неиспользуемые знания, недо-
статочную прозрачность знаний,
неэффективное распространение знаний или
их несогласованную аккумуляцию (Probst,
Raub, Rombardt. Wissen managen. 1997; Myers.
Knowledge Management and Organizational
Design. 1996). На рис. 286 приведен наглядный
пример жизненного цикла знаний, где от-
дельные фазы можно оценивать по положи-
тельным и отрицательным факторам.
Г. 1.4. Оценка процессов
Для того чтобы построить бизнес-процесс,
отвечающий конкретным целям, его необхо-
димо оценить с точки зрения этих целей. Если
речь идет, допустим, о ключевых задачах в
сфере электронной или автомобильной про-
мышленности (например, «снизить время вы-
полнения (цикла) на 50%»), то требуется оце-
нить продолжительность выполнения функ-
ций, участвующих в процессе. Для этой цели
подойдут оценки, полученные с помощью ме-
тодов сетевых диаграмм.
Если цели носят финансовый характер,
например, «сократить стоимость процессов
на 30%», то необходимо установить связь
между стоимостью и процессами. Проблема,
однако, в том, что современные системы уче-
та стоимости, опирающиеся на стоимостные
центры, больше ориентированы на функцио-
нальный подход. Например, целевой учет
стоимости направлен на оптимальное управ-
ление функциональными стоимостными цен-
трами. Поскольку стоимость бизнес-процес-
сов заранее неизвестна, то здесь новые перс-
пективы открывает такой метод, как
пооперационное исчисление стоимости. Роль
Управление бизнес-процессами на базе ARIS 61
Рис. 31. Вычисление стоимости бизнес-процессов
этого метода в бизнесе уже не первый год яв-
ляется темой профессиональных дискуссий
(см., в частности, Glaser. Prozefikosten-
rechnung. 1992; Horvath, Mayer. Prozefi-
kostenrechnung. 1989; Kloock. Prozefikosten-
rechnung. 1992), однако в этой книге мы не бу-
дем в него углубляться.
В основе пооперационного исчисления сто-
имости лежит принцип разбиения бизнес-
процессов на элементарные подпроцессы
(операции). Сначала определяется средняя
стоимость единовременного выполнения
каждого подпроцесса. Затем с помощью соот-
ветствующих коэффициентов вычисляется
стоимость всего бизнес-процесса.
Сам по себе принцип начисления стоимос-
ти по процессам отнюдь не нов. Напротив, в
сфере производства этот способ повсеместно
применяется для определения стоимости
продуктов и заказов. Расчеты основаны на
описаниях процессов (прейскурантах мате-
риалов и графиках работ). Полученную та-
ким образом информацию можно адаптиро-
вать для оценки стоимости общих бизнес-
процессов.
На рис. 29 представлена модель производ-
ственного процесса на уровне прейскурантов
материалов и графиков работ. Это первая
ступенька к вычислению стоимости процесса
производства. Продукт П состоит из двух
компонентов — К1 и К2. Эти детали описаны
в прейскуранте материалов для П. Для каж-
дого компонента существует график работ,
описывающий две операции (наладка и сбор-
ка/монтаж). Планируемая продолжитель-
62 Бизнес-процессы
ность наладки, изготовления и сборки привя-
зывается к соответствующим операциям.
При учете по стоимостным центрам опреде-
ляются ставки стоимости для каждого сто-
имостного центра (в данном примере — пред-
варительная подготовка и сборка) и для конк-
ретных операций (наладка и сборка монтаж).
Вычисленная стоимость изготовления умно-
жается на продолжительность использова-
ния ее компонентов. Коэффициент использо-
вания на одну операцию определяется по
данным, содержащимся в графике работ. На-
пример, для изготовления компонента К1
требуется 3 ДЕ на наладку и 10 BE на сборку.
Умножение на ставки 10 ДЕ/ВЕ и 20 ДЕ/ВЕ
дает стоимость выполнения этих функций -
30 и 200 ДЕ, соответственно. Просуммировав
стоимость всех функций, получаем сто-
имость изготовления одной единицы Ш, рав-
ную 1070 ДЕ. Поскольку в данном случае сто-
имостным фактором является Ш, то сто-
имость производственного процесса равна
стоимости производства стоимостного фак-
тора П1.
Производственный сектор располагает та-
кими инструментами, как графики работ и
прейскуранты материалов с детальным опи-
санием процессов. В сфере управления по-
добные описания обычно отсутствуют (во
всяком случае пока), поэтому здесь напря-
мую рассчитать ставки стоимости процессов
очень сложно.
В системах традиционного учета стоимос-
ти и для процессов, связанных с косвенным
выходом, также можно устанавливать диф-
ференцированные базовые показатели, кото-
рые будут служить характеристиками вы-
полняемых в их рамках функций. Например,
в области закупок базовым показателем яв-
ляется «число заказов», в управленческом
секторе — «число рассмотренных счетов-
фактур», а в области продаж — «число зака-
зов на отправку». Эти базовые показатели
можно использовать для планирования по
стоимостным центрам, однако в таких расче-
тах взаимосвязь с конкретным стоимостным
фактором неизвестна, и, следовательно, для
этих функций можно устанавливать только
единые ставки. Именно этим объясняется об-
щепринятая практика вычисления совокуп-
ной ставки накладных расходов (допустим,
на основе производственных издержек), хотя
она и подвергается критике за слишком обоб-
щенный подход. Пооперационное исчисление
стоимости открывает новые возможности для
решения этих проблем.
При пооперационном исчислении стоимос-
ти сначала необходимо ввести описания про-
цессов. Однако из-за чрезвычайной сложнос-
ти, широкого разнообразия, а иногда и низкой
повторяемости управленческих процедур
процессы моделируются на уровне типов, а не
на уровне конкретных экземпляров.
Для каждого стоимостного центра опреде-
ляются характерные типы подпроцессов, ко-
торые объединяются по стоимостным цент-
рам в типы основных процессов (см. рис. 30).
Подпроцессом называется компонент бизнес-
процесса. Если подпроцесс не разбивается на
дальнейшие составляющие, то он равнозна-
чен понятию «функция». В примере, приве-
денном на рис. 30, основной процесс «закуп-
ка» состоит из четырех подпроцессов: заказ,
напоминание об уплате, проверка счетов-
фактур и инициация платежей.
Как и в сфере производства, подпроцесс
связан с понятием «операция». Для каждого
подпроцесса можно определить ставки сто-
имости (например, стоимость типичного за-
каза на поставку, стоимость типичного напо-
минания об уплате и т. д.). Основному процес-
су присваивается коэффициент
использования каждого подпроцесса. Эти по-
казатели приведены на рис. 30 в ячейках с
описанием функций. Умножая ставку сто-
имости процесса на коэффициент использо-
вания, получаем стоимость процесса в пере-
счете на 1 подпроцесс. Сложив результаты,
получаем стоимость основного процесса, в
данном случае - типичного заказа на постав-
ку. Если полученную стоимость процесса
предполагается использовать в расчетах, то
необходимо учесть стоимостные факторы.
Для этого требуется установить базовый по-
казатель, позволяющий определить, сколько
основных процессов типа «закупка» связано с
одной единицей данного стоимостного факто-
ра. В нашем примере коэффициент использо-
Управление бизнес-процессами на базе ARIS 63
вания равен 2, что дает 192 ДЕ на единицу
стоимостного фактора.
Опираясь на моделирование процессов,
базовый принцип расчета по стоимостным
ставкам можно расширить, распространив
его на функции, принимающие косвенное
участие в создании выхода.
Точность распределения стоимости про-
цесса в соответствии с коэффициентом ис-
пользования зависит от точности базового
показателя основного процесса, связанного со
стоимостным фактором, и от точности уста-
новленного коэффициента использования. В
данном случае, в отличие от процедуры опре-
деления стоимости производства, связать
единицу основного процесса невозможно на-
прямую с единицей стоимостного фактора.
Таким образом, распределение накладных
расходов по процессам позволяет избежать
маловразумительных единых ставок.
Пооперационное исчисление стоимости не
подменяет существующие системы учета по
функциональным подразделениям и стоимо-
стным центрам, а интегрирует их в процеду-
ру расчета в качестве источников и получа-
телей информации. На рис. 31 приведена схе-
ма расчета стоимости бизнес-процесса на
базе интегрированной модели с привязкой к
традиционному учету по стоимостным центрам.
Эта схема основана на традиционной сис-
теме учета стоимости с детализацией по сто-
имостным центрам. Сначала анализируются
функции в стоимостных центрах и определя-
ются их базовые показатели. Затем вычисля-
ется ставка стоимости процесса в пересчете
на функцию.
Функциональная структура, приведенная
на рис. 31 в виде диаграммы ЕРС, представ-
ляет собой адаптированную модель бизнес-
процесса. Коэффициенты использования,
приходящиеся на каждую функцию процес-
са, умножаются на соответствующие ставки
стоимости. Стоимость (основного) процесса
можно вывести из суммарной стоимости
функций. Процесс и цифровые показатели,
представленные на рис. 31, соответствуют
примеру на рис. 30.
Г. 1.5. Эталонное сравнение
процессов
Эталоны могут служить базовыми крите-
риями для инжиниринга высокоэффектив-
ных бизнес-процессов. Сопоставление соб-
ственного бизнес-процесса с аналогичным
процессом, взятым за образец, позволяет по-
лучить целевые или ориентировочные пока-
затели. Такая процедура называется эталон-
ным сравнением. Можно сопоставлять биз-
нес-процессы в рамках одной компании, на-
пример, по разным подразделениям или
торговым филиалам. Можно привлекать для
сравнения бизнес-процессы конкурирующих
фирм, занятых в той же отрасли. Для этой
цели подходят, например, эталоны бизнес-
процессов, предлагаемые консалтинговыми
компаниями. Можно также использовать и
аналогичные процессы, применяемые в дру-
гих отраслях. Например, процедура обслу-
живания на заправочно-ремонтном пункте в
автогонках «Индианаполис 500», взятая как
эталон, способна внести ценный вклад в орга-
низацию обслуживания самолетов местной
авиалинии.
Короче говоря, существует множество ис-
точников ноу-хау — от научных публикаций
и докладов на конференциях до коммерчес-
ких эталонов, исследований, проводимых
различными ассоциациями, и услуг консал-
тинговых фирм.
Расхождение между характеристиками
эталонного процесса и собственными показа-
телями может подсказать, как лучше органи-
зовать у себя бизнес-процессы. Целевыми
критериями при эталонном сравнении могут
выступать финансовые, временные или сово-
купные показатели, например, стоимость
процесса, пропускная способность или вели-
чина входа/выхода, хотя немаловажное зна-
чение имеют и более субъективные характе-
ристики, связанные со степенью удовлетво-
ренности клиентов.
Хотя концепция эталонного сравнения не
нова, она всегда позволяет по-новому подой-
ти к совершенствованию бизнес-процесса и
необходимого для него сокращению времени.
Знакомство с различными публикациями
(Kuting. Benchmarking von Geschaftspro-
64 Бизнес-процессы
КОЛИЧЕСТВЕННЫЕ И КАЧЕСТВЕННЫЕ
КРИТЕРИИ ЭТАЛОННОГО СРАВНЕНИЯ
Продуктивность
Выход продукции/численность персонала. Выход продукции на единицу используемого ресурса.
Стоимость на 1 "доброкачественную" единицу изделия. Число выполненных заказов на 1 час
трудозатрат. Добавленное качество на 1 работника. Стоимость функций, добавляющих качество,
в процентах...
Качество
Процент отходов. Процент доработки и переделки (число единиц продукции, человеко-часов).
Процент дефектных партий товара (число продуктов). Процент возвратов. Стоимость гарантийного обслуживания.
Наличие и достоверность информации...
Показатели времени
Процент доставок в установленные сроки. Время цикла изготовления продукта. Время цикла доставки.
Число доставок с задержкой. Время, требуемое для переналадки. Время, требуемое для проверки.
Процент непродуктивного времени...
Удовлетворенность клиентов
Число клиентов, возобновляющих заказ на покупку. Индексы удовлетворенности клиентов. Реально
ожидаемый выход. Рекомендации по приобретению. Представление о функциональных возможностях.
Удобство для пользователя...
Канцелярская работа
Время, требуемое для обработки заказа. Число препятствий для клиента. Среднее число контактов на
оформление 1 заказа. Число дефектов и требований доработки и переделки. Число допустимых
исключений. Задержки отчетности в днях (количество продуктов, объем продаж)...
Рис. 32. Некоторые количественные и качественные критерии эталонного сравнения ("из работы
Kilting, Benchmarking von Geschaftsprozessen 1996, с. 135)
Событийная диаграмма
процесса(ЕРС
Результаты имитационного
Рис. 33. Метод имитационного моделирования
Общая стоимость
[Руб-1
Стоимость материалов
{Руб.]
О Стоимость рабочей силы
[Руб.]
□ Вспомогательные и
эксплуатационные расходы
[Руб.]
Стоимость энергоносителей
[Руб.]
□ Различные накладные расходы
[Руб.]
Ставки списания
[Руб.]
□ Вмененный процент
[Руб.]
Прочие издержки
□ Людские ресурсы
Ресурсы ИТ
□ Прочие ресурсы
Управление бизнес-процессами на базе ARIS 65
Рис. 34, Уровни документирования в рамках TQM
zessen. 1996; Aichele. Kennzahlenbasierte
Geschaftsprozefianalyse) дает представление о
том, в какой мере изучены критерии оценки
применительно к инжинирингу бизнес-про-
цессов. На рис. 32 приведена краткая сводка
критериев эталонного сравнения.
Г. 1.6. Имитация
Хотя оценка бизнес-процесса на основе ре-
зультатов пооперационного исчисления сто-
имости и эталонного сравнения имеет важней-
шее значение, для построения оптимального
бизнес-процесса разрабатывается несколько
альтернатив, которые анализируются с помо-
щью метода имитационного моделирования.
Для описания и анализа различных проект-
ных альтернатив в гипотетических ситуациях
(«что если») никаких методических расшире-
ний модели бизнес-процесса не требуется.
После проведения анализа основой для имита-
ции служит существующая модель процесса.
Динамика альтернативных процессов ис-
следуется с помощью динамической (имита-
ционной) модели. Отдельные процессы гене-
рируются и отслеживаются на модели про-
цесса. Таким образом, процессы описываются
на уровне экземпляров и проводится анализ
их взаимоотношений. Это позволяет выявить
потенциальные задержки до начала выпол-
нения реального процесса.
Для анализа можно выбирать альтерна-
тивные варианты, различающиеся по таким
аспектам, как структура процесса, время вы-
полнения функций, характер поведения со-
ответствующих организационных единиц.
Альтернативы вырабатываются индивиду-
ально на основе эмпирических исследований
либо автоматическим способом — по случай-
ному принципу.
Структуру имитационной модели можно
получить непосредственно из общей струк-
туры процесса, представленной на уровне I
модели АБИ, а затем оценить с помощью
66 Бизнес-процессы
Централизованное моделирование
Децентрализованное моделирование
в корпоративных подразделениях
Рис. 35а. Централизованное и децентрализованное моделирование в среде клиент—сервер
(IDS. ARIS-Easy Design. 1997)
Семантическая полнота
Более сложные оценки
Имитация
Пооперационное исчисление стоимости
ISO 9000
Фокус внимания:
Содержание бизнеса
Простые оценки
модуля имитационного моделирования. На
рис. 33 приведен пример оценки бизнес-про-
цесса при помощи системы SIMPLE++ в со-
четании с ARIS Toolset. Имитационные экс-
перименты для получения оптимальных биз-
нес-процессов издавна применяются в
изучении организации производства, напри-
мер, для определения эффективных правил
расстановки приоритетов при эвристическом
управлении процессами (см. Glaser/Geiger/
Rohde, PPS 1992, с 225) или при составлении
планов размещения оборудования на про-
мышленных предприятиях. Для процессов,
происходящих в офисах, комплексные иссле-
дования методом динамического моделиро-
вания применяются реже, хотя в связи с оп-
тимизацией процессов управления и обслу-
живания они начинают приобретать все
большую популярность. Например, приклад-
ное программное обеспечение для имитаци-
онного моделирования уже используется в
банках и страховых компаниях.
Г. 1.7. Обеспечение качества
В стандарте ISO 9000 сформулированы
критерии для определения качества бизнес-
процессов. Компания может удостовериться
в степени своего соответствия этим критери-
ям, получив надлежащий сертификат. Ос-
новная идея такой сертификации заключает-
ся в том, что оно свидетельствует именно о
качестве самих процессов.
Такие стандарты, как ISO 9000 и 9ххх, а
также более жесткий стандарт QS-9000, при-
нятый в автомобильной промышленности, за-
няли прочное положение во всем мире. Они не
только подтверждают соответствие базовым
стандартам типа ISO 9001, но и делают ак-
цент на аспектах управления, прокладывая
путь к общему (или системному) управлению
качеством (TQM). Для ключевых моделей
TQM типа Malcolm Baldrige Award или «Ев-
ропейской награды за качество» (EQA) цент-
ром приложения критериев оценки являются
именно бизнес-процессы, что способствует
успешной деятельности предприятий благо-
даря усилению ориентации на потребителя
Управление бизнес-процессами на базе ARIS 67
Рис. 356. Иллюстрация процесса, дополненная мультимедийными элементами
(IDS. ARIS-Easy Design. 1997)
(Seghezzi, Hansen. Qualitatsstrategien. 1993;
Seghezzi, Dahlem. Schritt fur Schritt zu TQM.
1997).
Однако с получением сертификата ISO
9000 усилия по повышению качества не пре-
кращаются. Для оптимизации корпоратив-
ных процессов применительно к конкретным
целям концепция системного управления ка-
чеством требует ориентировать свое мышле-
ние и действия на процессы и постоянно пе-
ресматривать и совершенствовать существу-
ющие процедуры.
Применение концепции ARIS к описанию
бизнес-процессов автоматически обеспечи-
вает согласованность моделей. Концепция
ARIS позволяет документировать каждый
базовый элемент системы управления каче-
ством (TQM), фигурирующий в стандарте
ISO 9000. Сюда входят описание обязаннос-
тей в рамках организации (должностные ин-
струкции), идентификация продукции, ее
приобретение, изготовление и сопровожде-
ние, управление документооборотом, а также
перемещение, хранение, упаковка и отправ-
ка продукции. Руководство по документиро-
ванию в рамках TQM, первоначально разра-
ботанное для внешнего пользования, содер-
жит более детальное описание процедур и
инструкций по эксплуатации. Они представ-
ляются с помощью событийных диаграмм
процессов (ЕРС) в виде иерархии процессов,
состоящей из нескольких уровней (рис. 34).
Согласованность перекрестных ссылок внут-
ри моделей сохраняется даже без ручного со-
провождения. Эта система обеспечивает
связь моделей с 20 элементами ISO 9001, по-
зволяя автоматически создавать руковод-
ство по TQM, процедурные и эксплуатацион-
ные инструкции и исходные описания зада-
ний (Копгд, Packowski, Wyler. BPR als Chance.
1995). В результате необходимость в бумаж-
ных версиях документации по TQM отпадает.
Использование определенного инструмен-
та моделирования и хранение процессов в ре-
позитории обеспечивают соблюдение стан-
дартного требования, согласно которому опи-
сания процессов должны в любое время
находиться в распоряжении всех сотрудни-
ков предприятия. Предоставление пользова-
тельских привилегий и прав доступа гаран-
тирует правомочным пользователям доступ к
соответствующему процессу в режиме
«только для чтения». Затем им можно предо-
ставить доступ к текущим данным через кор-
поративные интрасети.
68 Бизнес-процессы
Г. 1.8. Хранилище п роцессов
Систематический сбор, хранение и веде-
ние (сопровождение) ноу-хау бизнес-процес-
сов в репозитории воплощаются в так назы-
ваемом хранилище процессов.
Источниками информации для таких хра-
нилищ служат различные проекты, связан-
ные с анализом бизнес-процессов. Это могут
быть проекты по реинжинирингу, сертифи-
кации ISO 9000, внедрению стандартного
программного обеспечения, реализации по-
операционного исчисления стоимости и т. д.
Если в этих проектах применяется разнооб-
разный набор методов и инструментов, необ-
ходимо свести воедино содержание моделей,
имеющихся в хранилище, а затем объеди-
нить их с другими моделями. Последователь-
но и четко изложенные корпоративные инст-
рукции позволят в дальнейшем использовать
это ноу-хау в других проектах, а Интернет и
интрасетевые технологии предоставят воз-
можность распространить его в масштабах
всего предприятия на глобальном уровне.
Поскольку ноу-хау процессов является
компетенцией работников, непосредственно
участвующих в операциях, следует органи-
зовать сбор и ведение этих данных в децент-
рализованном репозитории. Для такой рабо-
ты не требуется владеть специальной мето-
дикой, поскольку главное здесь — сбор
фактической информации, составляющей со-
держание.
Собранные данные объединяются на цент-
рализованном уровне и подвергаются тща-
тельному анализу. Возможны и более слож-
ные оценки, включающие имитационные экс-
перименты, пооперационное исчисление
стоимости и т. д. На рис. 35а концепция хра-
нилища процессов представлена в архитек-
туре клиент—сервер. Однако чисто графи-
ческая иллюстрация процесса в виде диаг-
раммы ЕРС содержит только часть знаний,
относящихся к определенному бизнес-про-
цессу. Сюда не входят данные об организаци-
онной структуре, стоимости и времени, кото-
рые представляются другими способами, на-
пример, в форме таблиц. На рис. 356
графическая иллюстрация бизнес-процесса
в виде диаграммы ЕРС дополнена такими
мультимедийными элементами, как видео,
графика, изображения и таблицы.
Г.2. Планирование и управление
бизнес-процессами
Инжиниринг бизнес-процесса завершает-
ся созданием своего рода шаблона для конк-
ретных бизнес-процессов (экземпляров про-
цесса). Для того чтобы можно было осуществ-
лять планирование и управление текущими
бизнес-процессами, необходимо предоста-
вить надлежащую информацию в распоря-
жение тех, кто за них отвечает. В производ-
ственных системах планирование и управле-
ние процессами — обычная практика. Для
планирования и управления производством
продукции уже десятки лет используются
информационные системы. Они действуют по
принципу прогрессивного планирования.
Сначала определяются долгосрочные по-
требности в материалах и мощностях, необ-
ходимых для выполнения прогнозируемых
клиентских заказов. Затем составляется гра-
фик выполнения краткосрочных заводских
нарядов-заказов, после чего оптимизируется
последовательность конкретных операций
(Scheer. Business Process Engineering. 1994).
В офисах системы планирования и управ-
ления еще не стали привычным явлением.
Однако для применения этих базовых кон-
цепций создание в офисе жестко регламенти-
рованной среды отнюдь не обязательно. Для
планирования офисных процедур, включая
долгосрочное распределение персонала, по-
мещений и ресурсов, можно использовать ре-
зультаты прогнозов относительно выходов.
Идентификация необходимых типов процес-
сов позволяет определить количество бизнес-
процессов, подлежащих выполнению.
Управление процессами в офисе означает,
что ответственный распорядитель может ин-
формировать клиентов о состоянии их дел.
Это предполагает оптимальное использова-
ние ресурсов и постоянный мониторинг вре-
мени выполнения и качества процессов. Вно-
ся изменения в приоритеты, распределение
Управление бизнес-процессами на базе ARIS 69
Рис. 36. Мониторинг процессов
f> £,<* ¥*•* Amt* h*4
uy^b <BOl ' #* • ' £? zf Яй 9
70 Бизнес-процессы
ресурсов и последовательность обработки,
владелец бизнес-процесса может корректи-
ровать процесс в соответствии с поставлен-
ными задачами. Необходимыми инструмен-
тами для этого служат мониторинг процес-
сов, составление графиков, регулирование
мощностей и управленческие информацион-
ные системы (EIS).
Г.2.1. Мониторинг процессов
Мониторинг процессов служит для их уча-
стников и руководителей источником опера-
тивной информации о состоянии текущих
бизнес-процессов. В левом окне на рис. 36
представлено описание бизнес-процесса на
уровне типа, а в правом — на уровне экземп-
ляра. Хотя их структура идентична, между
ними все же есть различия. Символ папки в
функции «поддержка данных о закупке ос-
новных материалов» указывает, что эта фун-
кция в данный момент находится в работе.
Предыдущие функции уже выполнены. Та-
ким образом, известна не только роль каждой
организационной единицы, но и роль каждого
отдельного сотрудника. Функции, для кото-
рых определена только роль сотрудников, но
к которым еще не приступили, обозначаются
соответствующим цветом.
Помимо состояния обработки, можно ука-
зывать текущее время и стоимость процесса
применительно к конкретному случаю. Та-
ким образом, ответственный распорядитель
бизнес-процесса располагает наглядной ин-
формацией, позволяющей ему отвечать на
вопросы клиентов и при необходимости кор-
ректировать дальнейший процесс.
Г.2.2. Составление графиков и
регулирование мощностей
Бизнес-процессы обусловливают опреде-
ленные последовательности транзакций,
описываемые с помощью сетевых графиков.
Установив предполагаемые или плановые
сроки выполнения функций, можно вычис-
лить сеть событий с помощью известных по-
казателей сетевого графика (например, са-
мый поздний или самый ранний момент нача-
ла или завершения событий) и таким образом
построить график для всего процесса.
На рис. 37 результат такого вычисления
представлен в виде диаграммы Гантта. Этот
пример относится к процедурной модели ре-
ализации программного обеспечения. В диаг-
рамме Гантта для каждой функции модели
процесса создается отдельная строка. Длина
каждой горизонтальной линии указывает на
продолжительность функции. Продолжи-
тельность функций вычисляется на основе
потока управления и интервалов, отведен-
ных на каждую из них (например, в соответ-
ствии с целевой концепцией функция В начи-
нается через неделю после функции А). При-
вязав к функциям организационные единицы
и машинные ресурсы, можно представить и
мощности. Каждая строка диаграммы Гантта
соответствует определенному ресурсу и по-
казывает его загрузку на данный период. По-
добный пример приведен на рис. 38, где заг-
рузка представлена столбчиковыми диаг-
раммами.
Завоевывающие все большую популяр-
ность системы производственного планиро-
вания и управления предоставляют широкий
спектр алгоритмов планирования. Когда
складывается напряженная обстановка, ал-
горитмы позволяют планировать сверхуроч-
ную работу и дополнительные рабочие сме-
ны, переводить операции на резервные мощ-
ности или планировать выполнение
различных заказов (процессов) по эвристи-
ческому принципу в соответствии с присво-
енными приоритетами.
Управление мощностями и планировани-
ем находит все более широкое применение и
вне производственного сектора. Преимуще-
ства, которые оно дает руководителям биз-
нес-процессов, выходят далеко за рамки тра-
диционной сферы его приложения. Учиты-
вая высокую стоимость ресурсов в
операционных при проведении операции, его
можно эффективно применять даже в меди-
цинских учереждениях. В розничной торгов-
ле, особенно для компаний мирового масшта-
ба, ведущих бизнес в странах, где происходит
либерализация законов, связанных, напри-
мер, со временем открытия магазинов, уп-
равление процессами приобретает важней-
шее значение. То же относится и к сектору
общественных услуг, где отмечаются сезон-
Управление бизнес-процессами на базе ARIS 71
Анализ
"как есть" С
Целевая
концепция А
Целевая
вдицепция
инициирована
Целевая
концепция В

У** ..
' jJob lw№xtion_____!
f Avn A*»VM * !
;гАм*й1ивв ,
! ^'A*-n Antovs С }
;'.Prestr» Anatys» Resits]
J'jTirget Concept A j
, «Terget Солеей 8 j
Target Concept C •
Weak Port Arafyss ]
] "^taptemertaton Strategy
‘ Ooortertaxn J
’ Impiemertabofl ;
>-«r •

Целевая
концепция С
Рис. 37. Составление графика бизнес-процесса (модель процедуры для реализации
программного обеспечения)
ные колебания нагрузки (например, в связи с
ежегодными перерасчетами налога на зара-
ботную плату). Применение таких инстру-
ментов, как составление графиков и регули-
рование мощностей, позволяет распределить
нагрузку таким образом, чтобы исключить
работу в вечернее время и при этом избежать
проволочек в обслуживании клиентов.
Г.2.3. Управленческие
информационные системы
(EIS)
Увеличение объема доступной информа-
ции само по себе еще не означает улучшения
качества принимаемых решений. Напротив,
информационная перегрузка зачастую при-
водит к противоположному результату. Мас-
са данных, лежащих мертвым грузом, меша-
ет «за деревьями увидеть лес». Поэтому необ-
ходимо отфильтровать информацию,
имеющую критическое значение для приня-
тиярешений, исходя из личных соображений
и потребностей задачи. Управленческие ин-
формационные системы (EIS) предоставляют
в распоряжение руководства объединенную
совокупность данных по корпоративным и
внешним вопросам, позволяя контролиро-
вать, анализировать и планировать бизнес-
процессы. Простота использования делает их
удобным инструментом для руководителя,
т.е. для владельца бизнес-процесса.
Ключевые характеристики этих систем
перечислены ниже (Back-Hock. Executive-
Information-Sy stem-Generatoren und —
Anwendungen. 1991, cc. 40-41).
Системы класса EIS
— позволяют автоматически объединять
данные из различных источников;
72 Бизнес-процессы
Рис. 38. Планирование мощностей в бизнес-процессе
— отличаются простотой в использова-
нии;
— запрашивают информацию, представ-
ленную в различных плоскостях описа-
ния и на разных уровнях агрегирования
(т.е. используют полный спектр функ-
циональных возможностей);
— включают средства агрегирования;
— предусматривают средства ведения от-
четности, ориентированные на пользо-
вателя, включая графическое пред-
ставление результатов;
— имеют дополнительные функции (пе-
чать, управление данными, электрон-
ная почта с отчетами и комментариями).
В основе управленческих информацион-
ных систем лежит концепция хранилища
данных (Inmon. Data Warehouse. 1993). В хра-
нилище данных операционные системы и
данные строго обособлены от данных и сис-
тем для поддержки принятия решений. Если
текущая информация хранится только в опе-
рационных базах данных, то информация за
прошлые периоды размещается в хранили-
щах данных. При комплексных запросах не-
посредственный доступ к базам данных хра-
нилища резко повышает оперативность отве-
та. Другое преимущество состоит в том, что
на быстродействии операционных систем это
никак не отражается. К недостаткам храни-
лищ можно отнести дополнительную нагруз-
ку, связанную с хранением избыточных дан-
ных, и необходимость вновь интегрировать
данные после обновления содержащейся в
хранилище информации. Еще одно неудоб-
ство состоит в том, что при обновлении хра-
нилища не всегда обеспечивается целост-
ность данных (Scheer. Data Warehouse 1996. с. 75).
Управление бизнес-процессами на базе ARIS 73
Особые требования, предъявляемые уп-
равленческими информационными система-
ми к системам баз данных, связаны с храни-
лищами данных. Их табличная структура по-
зволяет выполнять двумерное
моделирование (допустим, «время» и «про-
дукты»), Более глубокое исследование дан-
ных, например:
—- статистический анализ, охватывающий
различные базы данных,
— сложные статистические вычисления,
— создание отчетов на основе информа-
ции из нескольких областей базы дан-
ных, выходит за рамки основных функ-
циональных возможностей систем ре-
ляционных баз данных (Engels. OLAP
1995. с. 99).
Кодд, автор реляционной модели баз дан-
ных, является и основоположником идеи баз
данных, в основе которых лежит принцип
OLAP (оперативная аналитическая обработ-
ка). Такие базы позволяют выполнять слож-
ный анализ данных благодаря хранению мно-
гомерной информации. OLAP дает возмож-
ность проводить автономный оперативный
анализ (Codd. OLAP. 1993; Jahnke,
Groffтапп, Kruppa. OLAP. 1996). Таким об-
разом, OLAP следует рассматривать как
один из аспектов общей концепции хранили-
ща данных.
Одна из особенностей OLAP состоит в том,
что она позволяет анализировать информа-
цию под разными углами зрения. Можно, на-
пример, анализировать стоимость по опреде-
ленным регионам, временным периодам и
бизнес-процессам. OLAP сортирует значе-
ния различных объектов-прототипов (регио-
нов, периодов, процессов и т. д.), раскладывая
их параллельно осям многомерных кубов.
Приведем пример конкретного запроса
OLAP: «Какова стоимость каждого процесса
в таком-то регионе за период с 1-го по 3-й ме-
сяц? » Если оценивать эти же данные в других
ракурсах, то запрос может выглядеть следу-
ющим образом: «Какова стоимость такого-то
процесса в каждом регионе за прошлый квар-
тал?» Владельцы предприятий могут исполь-
зовать управленческую информационную
систему (EIS) для объединения полученной
информации о текущих бизнес-процессах.
Оценки EIS можно предварительно сконфи-
гурировать в соответствии с логикой модели
процесса, особенно - модели данных. В каче-
стве оценок и параметров отчетности часто
используются комбинации следующих сег-
ментационных структур (Muksch, Holthuis,
Reiser. Data Warehouse-Konzept. 1996, c. 424;
Zell. Fuhrungsinforma-tionssysteme. 1997, c.
293):
— организационные структуры: жесткая
группировка организационных планов
по юридическим лицам, коммерческим,
технологическим и функциональным
секторам, подразделениям, стоимост-
ным центрам и т.д.;
— структуры продукции: сортировка по
изделиям, товарным группам, типам
продукции и т.д.;
— региональные структуры: сортировка
по странам, штатам, территориям, ре-
гионам и т.д.;
— типы потребителей и продаж: сорти-
ровка по потребительским группам, ти-
пам потребителей, типам продаж, кана-
лам сбыта;
— временные структуры: сортировка по
периодичности отчетов (ежемесячно,
ежеквартально, ежегодно) и отчетному
периоду (месяц, квартал, год);
— характеристики и показатели бизнеса:
сортировка по доходу, вкладу, прибы-
ли, стоимости процессов и т.д.
(Reichmann. Controlling mit Кепп-
zahlen. 1997);
•— категории данных: сортировка по про-
гнозам, целевым показателям, факти-
ческим показателям, отклонениям.
Данные уровня I, особенно результаты
эталонного сравнения и имитационных экс-
периментов, тоже можно использовать как
источники для систем класса EIS. Важней-
шими источниками являются также резуль-
таты мониторинга процессов, составления
графиков и регулирования мощностей на
уровне II, основанные на информации о вы-
полнении процессов на уровне III.
74 Бизнес-процессы
Основные
бизнес-процессы
Подпроцессы
Условные обозначения:
Срочно требуется дальнейший анализ
Требуется дальнейший анализ
Дальнейший анализ не требуется
Рис. 39. Отчетность по отклонениям в управлении бизнес-процессами
Стратегия интеллектуальных запросов
(«добыча данных») позволяет владельцам
процессов безошибочно выходить на процес-
сы, имеющие прямое отношение к запраши-
ваемой информации. Идея «добычи данных»
состоит в умении сформулировать образец
запроса во всей совокупности структуриро-
ванных и неструктурированных данных, по-
лучить в ответ информацию, которая иначе
вряд ли попала бы в поле зрения, и выдавать
эту информацию конечному пользователю
(Hagedorn, Bissantz, Mertens. Data Mining.
1997; Petersohn. Klassifikation bei Ent-
scheidungsproblemen. 1997).
Мы не будем здесь останавливаться на
оценках, которые сводятся к простому доку-
ментированию плановой процедуры бизнес-
процессов.
На рис. 39 показана схема отчетности по
отклонениям (исключениям) в управлении
бизнес-процессами (Kraemer. Kostenmana-
gement. 1993). Эта схема позволяет одним
взглядом охватить все проблемные участки
на предприятии. Заштрихованные области
показывают, какие процессы требуют немед-
ленных корректировок (темно-серые), а ка-
кие — дальнейшего анализа (светло-серые).
Незаштрихованные области представляют
процессы, где дальнейший анализ не требу-
ется. Подробный анализ выделенных процес-
сов может вскрыть дополнительные возмож-
ности оптимизации.
Г.2.4. Непрерывное
совершенствование
процессов — адаптивный
инжиниринг бизнес-
процессов
Инжиниринг бизнес-процессов — это не
одноразовое мероприятие, а постоянная за-
дача для того, кто за них отвечает. В японской
парадигме управления «кайзен» (kaizen - в
переводе «медленная, непрекращающаяся
оптимизация», см. Sebestyen. Management-
«Geheimnis» Kaizen. 1994, с. 17) акцент дела-
ется именно на необходимости постоянной
адаптации и оптимизации бизнес-процессов.
Помимо идеи непрерывного эволюционно-
го совершенствования бизнес-процессов, су-
ществует более революционная реинжини-
ринговая концепция Хэммера и Чампи
(Hammer, Champy. Business Reengineering.
1995). При реинжиниринге бизнес-процессов
Управление бизнес-процессами на базе ARIS 75
Рис. 40. Реинжиниринг и непрерывное совершенствование
перед предприятием ставится задача начать
все как бы с нуля.
Оба подхода имеют свои достоинства. В оп-
ределенной ситуации, когда у предприятия
появляется шанс радикально переосмыслить
структуру своей деятельности, внеся в нее
фундаментальные изменения, можно прове-
сти реинжиниринг. Но и после его заверше-
ния процессы остаются в постоянном движе-
нии. Возникают новые организационные фор-
мы, появляются новые образцы ведения
бизнеса, которые можно взять за прототип,
изобретаются новые технологии, наконец,
приобретаются знания и опыт, связанные с
недавно внедренными процессами. Все это
влечет за собой необходимость адаптации но-
вых процессов. Для описания потребностей
предприятия в совершенствовании как
нельзя лучше подходит такое широко извес-
тное понятие, как «турбулентная среда».
В процессе планирования и управления
бизнес-процессами достаточно выражение
выявляются различные причины для прове-
дения реинжиниринга, которые связываяют
между собой уровни инжиниринга и управ-
ления, как показано на схеме обратной связи
АБИ (см. рис. 24). Рис. 40 (Imai. Kaizen. 1992, с.
51) иллюстрирует колебания между фазами
реинжиниринга и непрерывного совершен-
ствования.
При реализации фундаментальных реин-
жини-ринговых проектов компании нередко
осуществляют внедрение крупномасштаб-
ных ИС или миграцию на более совершенные
системы (предпочитая, например, интегри-
рованное стандартное программное реше-
ние). Это позволяет избежать применения к
старым процессам новой технологии. Органи-
зации, ограниченные в средствах, также
76 Бизнес-процессы
Рис. 41. Различные типы моделей (AHweyer. Adaptive Geschaftsprozesse. 1997, с. 186)
выигрывают от более рационального внедре-
ния программного обеспечения. Кроме того,
эту фазу можно использовать для усиления у
сотрудников мотивации к совершенствова-
нию процесса реинжиниринга. Например,
для усовершенствования процесса могут по-
требоваться следующие изменения:
• модификация функциональной проце-
дуры,
• объединение нескольких функций,
• модификация потока управления,
• модификация организационных обя-
занностей,
• модификация используемых данных,
• модификация систем ИТ.
Бизнес-процессы считаются устойчивы-
ми, когда изменения в корпоративной среде
не требуют или почти не требуют модифика-
ции бизнес-процесса. Если возникает необхо-
димость в модификациях, их стоимость зави-
сит от степени сложности адаптации процес-
са. Очевидно, что бизнес-процессы должны
быть устойчивыми и адаптируемыми, хотя
эти показатели с трудом поддаются количе-
ственным оценкам.
На всех этапах реинжиниринга и непре-
рывной оптимизации бизнес-процессы сле-
дует четко документировать. Это является
обязательной предпосылкой для их оценки
на стадии анализа. На рис. 40 функция доку-
ментирования представлена «хранилищем
процессов». Именно здесь хранятся корпора-
тивные знания организации о процессах и ин-
формация о процессах-прототипах. Здесь же
можно собирать модели текущих, унаследо-
ванных и даже будущих процессов, которые
послужат фундаментом для организацион-
ной перестройки в будущем.
Подобный путь разработки моделей иллю-
стрируется на рис. 41. Если хранятся и про-
шлые модели, то успех или неудачу меропри-
ятий в процессе реинжиниринга можно оце-
нивать путем сравнения моделей.
Управление бизнес-процессами на базе ARIS 77
Рис. 42. Метамодель контроля версий модели
Для хранения версий основных моделей
необходим контроль версий. Метамодель та-
кого контроля представлена на рис. 42. Моде-
ли и их'составляющие элементы связывают-
ся с классом ВРЕМЯ и, таким образом, несут
на себе «печать» времени. Соответствующие
данные хранятся в объектах данных ВЕР-
СИЯ МОДЕЛИ или ВЕРСИЯ ЭЛЕМЕНТА
МОДЕЛИ. Версии моделей состоят из связан-
ных с ними версий элементов модели. Термин
«элемент модели» охватывает широкий круг
понятий, таких как функции, данные, орга-
низационные единицы, выход и его взаимо-
связи. Из этих элементов можно построить
модели реальных процессов.
При помощи отношения *:* с одной верси-
ей модели можно связывать несколько вер-
сий одного и того же элемента модели. Это по-
зволяет избежать автоматической генерации
новых версий модели при незначительных
изменениях в ее элементах. Модели в масш-
табе корпорации состоят из нескольких сотен
или даже тысяч элементов, что существенно
осложняет контроль версий. С другой сторо-
ны, контроль версий обеспечивает прозрач-
ность управления бизнес-процессами. Кроме
того, контроль версий является неотъемле-
мой частью корпоративной памяти организа-
ции.
Г.З. Управление потоками работ
(workflow)
Рассмотренные аспекты инжиниринга и
планирования бизнес-процессов ориентиро-
ваны на менеджеров, занимающихся вопро-
сами управления бизнесом. Использование
технологии workflow позволяет трансформи-
ровать бизнес-процессы в инструменты ИТ.
78 Бизнес-процессы
п Маршрут 25 „
Прием заказа Отправка
Рис. 43. От модели бизнес-процесса — к реальной процедуре
Как правило, управлять всем бизнес-про-
цессом при помощи одной прикладной систе-
мы невозможно. Очень часто для этого требу-
ется ряд прикладных систем для организа-
ции продаж, закупок, производства и учета.
Даже комплексные стандартные прикладные
системы имеют пробелы, которые необходи-
мо восполнить с помощью специализи-рован-
ных систем или стандартных приложений от
других поставщиков. Ни одна из этих систем
сама по себе не способна определять состоя-
ние всего процесса (например, состояние об-
работки конкретного заказа на каждом эта-
пе). Поэтому имеет смысл вынести общее уп-
равление процессом на отдельный уровень
вместо того, чтобы распределять ответствен-
ность между несколькими системами. Этот
уровень называется «workflow» или уровень
«потока работ».
Системы класса workflow передают обра-
батываемые объекты (документы) с одного
рабочего места на другое. В идеале эта пере-
дача осуществляется электронными сред-
ствами — от компьютера, установленного на
одном рабочем месте, к компьютеру, где вы-
полняется следующая операция. Для этого
требуется детальное описание процедуры
применительно к конкретному типу процесса
и указание на соответствующего исполнителя.
Поток документов, изображенный на рис. 24,
включает «папку», содержащую электрон-
ные ссылки на функциональные компоненты,
которые нужно активизировать, и необходи-
мые для обработки данные, которые переда-
ются с одного рабочего места на другое.
На рис. 43 показано, как процесс, описан-
ный на уровне инжиниринга, приобретает
черты реального процесса на уровне выпол-
Управление бизнес-процессами на базе ARIS 79
Wray
Тгау ,- Folder^* View "> Option»

№мй
ОисфСол'-
G3 Uatena! ЧОО ’О СВох&<94
33 Maanai 14СС- 4Q С3с< БМ Л 33
Сз Uaienai >300-30 СВох'лм.’л
cwt» рислаьг^ -зла |
rwton р«жпам-<з Заа
narun *Ne»!oty aau
Рис. 44. Экран системы workflow (пример использования буферов обмена)
г*1
Буфер обмена
Список
документов
Корзина для
входящих
документов
Корзина для
исходящих
документов

нения. Вместо перечня общих наименований
организационных единиц мы видим теперь
имена конкретных сотрудников, вместо об-
щих обозначений заказов — ссылки на конк-
ретных клиентов. По завершении той или
иной операции система класса workflow за-
бирает исходящий документ из электронного
ящика одного менеджера и пересылает его в
электронный ящик для входящих сообщений
на компьютере следующего менеджера. При
наличии нескольких менеджеров документ
может рассылаться по нескольким ящикам.
Как только один из менеджеров приступает к
обработке документа, из остальных ящиков
его копии удаляются (Hagemeyer, Rolles,
Schmidt, Scheer. Arbeitsverteilungsverfahren.
1998). На рис. 44 изображен экран системы
workflow со значками корзин для входящих и
исходящих бумаг и буферов обмена.
Системы workflow содержат информацию
о состоянии процесса обработки, времени вы-
полнения и пользователях каждого бизнес-
процесса и при необходимости выдают дан-
ные для оценки стоимости и времени, а также
предоставлют информацию для мониторинга
процессов. Именно поэтому системы
workflow являются фундаментом для управ-
ления процессами на уровне II.
Процессы на уровне workflow могут быть
представлены графически на эране монитора
каждого пользователя. Это делает более по-
нятной организационную подоплеку бизнес-
процессов. Если говорить о мониторинге про-
цессов (см. правое окно на рис. 36), то ключе-
вую роль в этом контексте играют диаграммы
ЕРС. Сюда входят такие детали, как указание
конкретных сотрудников и выбор пути вы-
полнения процесса из различных альтерна-
тивных вариантов, представленных в общем
описании бизнес-процесса. Это позволяет
пользователям видеть, какая роль им отво-
дится в процессе, кто их «предшественники»
и «преемники». Они также видят, что, ска-
жем, в данном примере к ним имеет отноше-
ние только левая ветвь бизнес-процесса, по-
скольку поток управления в правой ветви
удален. А в связи с тем, что конкретный
пользователь следующей функции еще не
назван, то указано только имя подразделе-
ния. Пользователь на следующем операцион-
ном этапе будет назван лишь после выполне-
ния данной функции в соответствии с теку-
щей нагрузкой.
80 Бизнес-процессы
Хорошо структурированный процесс
Слабо структурированный процесс
Рис. 45. Структура процесса до и после внедрения коллективной организации работ
При внедрении систем workflow мы раз-
граничиваем процессы с четко определенной
структурой и процессы, для которых после-
довательность выполнения определена лишь
в общих чертах. Для многих операционных и
повторяющихся процедур, скажем, для обра-
ботки заказов или ссуд, функции, их после-
довательность, ветви процесса и организаци-
онные единицы заведомо известны. Такие
процессы хорошо структурированы и могут
быть описаны, например, методом ЕРС.
Другие процессы можно описать лишь ча-
стично, поскольку функции становятся изве-
стны только с началом фактической обработ-
ки, последовательность этапов обработки ус-
танавливается применительно к конкретной
ситуации, а организационные единицы опре-
деляются в зависимости от конкретных тре-
бований. Такие процессы считаются слабо
структурированными и поддаются лишь час-
тичному моделированию. Например, их фун-
кции можно только перечислить в списках «к
исполнению». Точная последовательность
функций определяется коллективно в ходе
выполнения, а ответственность за ее соблю-
дение возлагается на непосредственных ис
полнителей. В системах workflow, разраба-
тываемых специально для конкретных слу-
чаев, сотрудники сами определяют своих
«преемников».
На первый взгляд может показаться, что
системы workflow предназначены только для
управления четко определенными процесса-
ми. Слабо структурированные процессы под-
держиваются программным обеспечением
класса groupware, функциональные возмож-
ности которого ограничиваются электронной
почтой, видеоконференциями, коллективны-
ми конференциями и другими аналогичными
средствами (Schwabe, Krcmar. CSCW-
Werkzeuge. 1996) и которое не требует каких-
либо навыков логического построения про-
цессов.
В реальной жизни всегда приходится
иметь дело со структурами и того и другого
типа. Системы workflow имеют в своем соста-
ве функции «обработки исключений», что по-
зволяет изменять управление бизнес-про-
цессом по ситуации прямо в ходе его выпол-
нения. Эти функции можно связать с
программными решениями для коллектив-
ной работы, так что системы workflow и
grupware будут дополнять друг друга. В бу-
дущем их, по всей вероятности, даже можно
будет интегрировать. На рис. 45 показано, как
хорошо структурированный процесс вслед-
ствие его переориентации на принципы кол-
лективной работы может быть превращен в
слабо структурированный, где обязательным
предписанием является только список «к ис-
полнению». На рис. 46 представлены различ-
ные этапы структурирования процессов
workflow.
Благодаря стандартам интерфейсов, раз-
работанным Коалицией по управлению
workflow (WfMC), различные системы
workflow теперь могут быть связаны с помо-
щью интерфейсов прикладного программи-
Управление бизнес-процессами на базе ARIS 81
Совместный Полуструктурированный Структурированный
Система workflow типа Ad Hoc - самое простое Система workflow для коллективной работы Интегрированная коллективная функция Интегрированная "цепочка действий" Исключения типа Ad Нос Стандартная система workflow
-4И
Интерактивный обмен информацией между отдельными сотрудниками Коллективная работа в рамках группы, обмен идет через одного сотрудника Коллективная работа в системе workflow в рамках структурированной процедуры Функции без заранее определенной последо- вательности в рамках структурированного workflow Обработка исключений для отдельных функций Полностью структури- рованная система workflow с повторяющей- ся последовательностью операций
Гибкий Структурированный
Рис. 46. Различные степени структурирования процессов workflow
Условное обозначение: WAPI = Интерфейс прикладного программирования workflow
Рис. 47. Модель-прототип, разработанная WfMC (Hollingsworth. Workflow Reference Model. 1995)
82 Бизнес-процессы
Рис. 48. Типы и экземпляры бизнес-процесса
рования (API). В настоящее время изучаются
стандарты интерфейсов для моделирования
процессов на уровне инжиниринга (уровень
I), управления (уровень II) и прикладных сис-
тем (уровень IV). Они классифицируются на
основе модели-прототипа, представленной
на рис. 47.
Такие стандарты обычно представляют
собой решение по минимуму, поскольку они
приводят требования сторон к наименьшему
общему знаменателю. Однако все же они яв-
ляются ценными вспомогательными сред-
ствами для дальнейшей разработки откры-
той архитектуры программного обеспечения,
ориентированной на процессы. Но для реаль-
ных приложений наиболее успешным мето-
дом остается разработка индивидуальных
интерфейсов между соответствующими сис-
темами.
Для того чтобы непосредственно переда-
вать системам workflow данные, поступаю-
щие с уровня I моделирования процессов,
каждый экземпляр должен создаваться в со-
ответствии с шаблонами моделей. Обязатель-
ным условием является также возможность
управлять данными экземпляров. Кроме
того, модели экземпляров должны быть мо-
дифицируемыми в случае обработки исклю-
чений.
Экземпляры обычно поддерживаются
прикладными системами. Системы workflow,
в основе которых лежат концепции управле-
ния процессами, не зависят ни от каких конк-
ретных приложений. Благодаря тому, что
данные об экземплярах (например, время на-
чала и окончания события) фиксируются ав-
томатически без каких-либо дополнитель-
ных прикладных модулей («начать обработку
заказа» или «начать процесс изготовления»),
они поддерживаются моделями, располагаю-
щимися на уровне I репозитория ARIS.
На рис. 48 приведен фрагмент бизнес-про-
цесса «обработка заявки на ссуду» на уровне
типов и на уровне экземпляров. На метауров-
не объект-экземпляр связывается с каждым
объектом-типом отношением 1:* (см. рис. 49).
Управление бизнес-процессами на базе ARIS 83
Рис. 49. Связь между объектом-типом и объектом-экземпляром на мета-уровне
В разделе Д.2 «Уровни моделирования» мы
подробно рассмотрим, как модели экземпля-
ров встраиваются в концепцию ARIS (в част-
ности, в мета- и мета2-структуру репозитория).
Г. 4. Прикладные системы
Системы workflow инициируют работу
приложения на уровне АБИ посредством ко-
манды CALL, избавляя пользователей от не-
обходимости разбираться в тонкостях при-
кладной системы. Как только команда CALL
активизирует обработку варианта (экземп-
ляра) процесса, система workflow вызывает
экран соответствующее приложение вместе с
информацией, необходимой для данного про-
цесса. Наряду с комментариями относитель-
но используемых программ обработки эта ин-
формация содержит комментарии базы дан-
ных, хранящиеся в электронной папке
событий.
Для управления программами при помощи
системы workflow требуется достаточно вы-
сокая степень структурирования программ-
ных модулей. Кроме того, эти модули должны
быть доступны извне для системы workflow.
Далее мы кратко обсудим различные воз-
можности управления традиционными стан-
дартными программами посредством процес-
сов. Затем рассмотрим объектно-ориентиро-
ванные методы, которые становятся все
более актуальными и подводят к идее компо-
нентного программного обеспечения. Прин-
ципы построения инфраструктуры, зало-
женные в концепции АБИ, позволяют полу-
чить информацию об архитектуре, а также
многократно использовать программные
компоненты.
Г.4.1. Традиционные стандартные
программные решения
Традиционные стандартные программные
решения для различных аспектов бизнеса
представляют собой интегрированные при-
кладные системы, управляемые транзакция-
ми. Нередко эти решения состоят из интегри-
рованных программ и предполагают про-
граммное управление процессами, что не
вполне вписывается в концепцию АБИ, где
управление реализуется системами
workflow.
Однако при условии разбивки прикладных
систем на компоненты и при наличии у них
интерфейса для вызова удаленных процедур
(RPC) системы workflow могут инициировать
выполнение этих программных модулей или
транзакций. Например, SAP R/3 располагает
интерфейсом для вызова удаленных функ-
ций (RFC). При применении независимых си-
стем workflow для управления стандартны-
ми программами последние разделяются на
функции обработки и поток управления, по-
ступающий от workflow. Это означает, что
производитель больше не отвечает за целост-
ность решения. Для переноса этого гибкого
метода на архитектуру стандартных про-
граммных решений в этих решениях исполь-
зуются специализированные системы
workflow для управления процессами. К со-
жалению, такие системы workflow зачастую
тесно связаны с конкретной системой и не
подходят для решений, в основе которых ле-
жат гетерогенные системы.
Эти модели позволяют конфигурировать
стандартные программы при условии, что та-
кие программы описаны семантическими мо-
делями, связанными с репозиторием системы.
84 Бизнес-процессы
Определить
вертикальный рынок
Определить
бизнес-процессы
Выбрать
модели-прототипы
процессов
Адаптировать
модели-прототипы
процессов
Промышленность
Рис. 50. Индивидуализация моделей-прототипов
С помощью перекрещивающихся линий
можно убрать с экрана ненужные функции
бизнес-процесса, предлагаемого прикладной
системой. На рис. 50 схематически изображе-
на процедура работы с моделями в системе
SAP R/3. Сначала определяется модель-про-
тотип соответствующей области бизнеса,
(розничная торговля, банковское дело, про-
мышленность и т.д.). В нашем примере мы
взяли в качестве вертикального рынка «про-
мышленность». В рамках решения для верти-
кального рынка выбираются конкретные биз-
нес-процессы. В нашем примере это произ-
водство, закупка и продажа. Для получения
бизнес-процессов, специфических для дан-
ного клиента из данной области деятельнос-
ти, из процессов, представленных в виде ди-
аграмм ЕРС, удаляются ненужные функции
и зависящие от них события. В процедуру
правки заложены определенные правила, по-
зволяющие проследить возможные комбина-
ции и взаимозависимости в рамках осуще-
ствляемых бизнес-процессов. Например, от-
мена функции «хранение на складе» требует
и удаления функции «выдача со склада».
Информация о вносимых изменениях пе-
редается непосредственно модулю управле-
ния конфигурацией системы.
Каждая бизнес-функция позволяет ввес-
ти дополнительные параметры. Например,
функция «формирование заказа на постав-
ку» может относиться к отделу отправки,
стороннему поставщику, складу или отделу
Управление бизнес-процессами на базе ARIS 85
продаж. Очевидно, что такой заказ требует
более подробной спецификации. Руководство
по управлению реализацией (IMG) системы
SAP R/3 содержит дополнительные компью-
теризованные средства поддержки. Как и в
моделях процессов, для конфигурирования
стандартного программного обеспечения
можно использовать другие типы моделей,
такие как модели данных, функциональные и
организационные модели. Можно, например,
удалять информационные объекты из моде-
ли данных стандартной программы или, на-
против, добавлять новые. Можно удалять ат-
рибуты или изменять их длину. Эта инфор-
мация также передается системе, которая
автоматически изменяет настройку экранов.
Другие примеры вы найдете в работе: Scheer.
ARIS ~ Business Process Modeling. 1998.
Непосредственное взаимодействие между
средствами моделирования, семантическими
моделями и прикладной системой видоизме-
няет стратегию реализации стандартного ПО.
Прежде было принято придерживаться жес-
ткого разделения на фазы с применением
анализа «как есть» для выявления слабых
мест. Позже были разработаны целевые кон-
цепции, независимые от конкретного стан-
дартного обеспечения, которые реализовы-
вались с помощью методов индивидуальной
настройки. В настоящее время разные фазы
все чаще реализуются одновременно и во
взаимодействии друг с другом, что открывает
путь к тесному сотрудничеству между теми,
кто непосредственно занимается бизнесом, и
персоналом по внедрению системы, позволяя
параллельно решать вопросы бизнеса и воп-
росы внедрения. Это иллюстрирует пример
на рис. 51. Для наглядности все четыре окна
показаны отдельно. В реальном приложении
эти окна отображаются на одном экране, пре-
доставляя пользователю всю информацию
сразу.
В верхнем правом окне представлен фраг-
мент модели бизнес-процесса, выполненной с
помощью ARIS Toolset, демонстрирующий
часть процесса, которая должна быть удале-
на. Здесь же добавляется дополнительная
ветвь процесса, отсутствующая в стандарт-
ной программе.
Функция «формирование запроса» запра-
шивает пользователя, какой экран использу-
ется в SAP R/3. В соответствии с моделью
процесса щелкнув на этой функции (или выб-
рав команду), пользователь может, не углуб-
ляясь в тонкости, вызвать SAP R/3. Этот эк-
ран изображен внизу слева.
Для индивидуальной настройки этой фун-
кции вызывается инструмент настройки, со-
держащийся в Руководстве по управлению
реализацией (IMG). В верхнем левом окне по-
казаны доступные параметры функции.
С помощью инструмента моделирования
результаты обсуждений, выбранные пара-
метры, нерешенные вопросы и т. п. сохраня-
ются в функции, как показано в нижнем пра-
вом окне. Это позволяет подробно документи-
ровать инжиниринг бизнес-процессов как с
точки зрения самого бизнеса, так и с точки
зрения ИТ. Такая документация впослед-
ствии поможет разрешить проблемы, возни-
кающие при использовании этого ноу-хау
для мониторинга текущего проекта и для ре-
ализации последующих.
Поскольку сопровождение высокоинтег-
рированных систем и оперативное обновле-
ние руководств по обучению и документиро-
ванию для всей системы требуют больших
усилий, а производители обычно «неповорот-
ливы» с разъяснением их политики по основ-
ным версиям, эти системы следует разбивать
на более простые блоки (модули, компонен-
ты, агенты, бизнес-объекты). Для компонен-
тов такие алгоритмы вполне удовлетвори-
тельны. Кроме того, отсутствие жесткой свя-
зи между компонентами облегчает их
сопровождение, а обновление их документа-
ции менее трудоемко.
Разбиение прикладных систем на модули
— идея не новая. Модули предоставляют в
распоряжение пользователей четко описан-
ные интерфейсы, которые являются для них
единственным средством обмена информаци-
ей. Пользователи не обременены деталями,
связанными с реализацией модуля (эта ин-
формация от них «спрятана»).
86 Бизнес-процессы
Модель процесса
Процесс: Обработка запроса клиента
Функция "Как есть" /Цель Нерешенные вопросы Интерфейс Отв. исполни- тель Дата Категория сложности
1. Определить заказчика Отныне запросы заказчикам будут упорядочиваться в соответствии с кодами стран ISP (провайдеров услуг Интернета) Параллельная разработка изделий. Необходим клиент. Данные о клиенте (внутренние) С. Иванов 29 мая Стандартная
2. Определить контакт для запроса Определить стороннего поставщика как новый Тип Партнера в специализированной версии Нет Данные о клиенте (внутренние) П. Мельников 29 мая Стандартная
3. Ввести предмет запроса Использовать в качестве стандарта AFN Item Туре Нет Данные о клиенте (внутренние) П. Мельников С. Иванов 30 мая Стандартная
Документирование результатов
Рис. 51. Интерактивное построение бизнес-процесса и настройка стандартной программы
Управление бизнес-процессами на базе ARIS 87
Щ Change View -Maintain Sales Document Types**: Overview
Table view Edit Goto Choose Utilities System Help
Настройка: "Сопровождение типов документов по продажам"
а Create Inquiry: Initial Screen
Sales document Edt Overview Item Etwetxwwr* SjjPem Неф
яг -«л, 1 4^C' M Ml Fi r
Singl.Hne entry DoubMine entry ' Business data
Inquiry type j Organizational data~~ ~ Sales organization Distribution channel ; Division Sales office Sales group >4**- : IN }±| 0801 Sales Org. 001 01 04 — - —- - "J _ _ ; „ __ . —J 5 IPS ПП100) | Ы®230Ь jOVR 18:36
Функция "Формирование запроса"
88 Бизнес-процессы
И все же модульный принцип имеет один
недостаток - во многих случаях он не допус-
кает никаких вариаций. Внесение модифика-
ций в какой-нибудь модуль для некоторых
приложений немедленно требует изменений
в программном коде. Иногда даже возникает
необходимость в разных версиях. Это приво-
дит к нагромождению модульных концепций
и ограничивает возможность их многократ-
ного применения.
С другой стороны, объектно-ориентиро-
ванные концепции описываются на уровне
типов, что позволяет при внесении измене-
ний создавать подтипы определенного типа
объекта, устраняя необходимость изменять
исходный тип объекта. Подтипы описывают
лишь отклонение от исходного типа объекта.
Это придает системе гибкость и повышает
многократность использования спроектиро-
ванных объектов.
Дробление монолитных прикладных сис-
тем на все более мелкие составные части пре-
красно согласуется с расширяющимися воз-
можностями объектно-ориентированных
концепций. Это подводит нас к понятию «ком-
понентного программного обеспечения», на
котором, собственно и базируется внедрение
реальных приложений.
Г.4.2. Компонентное
программное обеспечение
Основная идея компонентного ПО заклю-
чается в сборке прикладных систем из от-
дельных стандартных компонентов, разрабо-
танных разными поставщиками. Обмен сооб-
щениями обеспечивает между компонентами
нежесткую связь. Таким образом, при разра-
ботке программ акцент с программирования
смещается в сторону проектирования реше-
ний и сборки компонентов. Концепция ис-
пользования компонентов тесно связана с ос-
новными принципами объектно-ориентиро-
ванного подхода.
Объектно-ориентированные концепции не
новы, однако в последние годы их роль в сфе-
ре создания реальных приложений заметно
возрастает. Сегодня новые приложения, как
правило, разрабатываются на базе объект-
но-ориентированных технологий: традици-
онное стандартное ПО разбивается на струк-
туры объектов по принципу «сверху вниз» и
затем проводится по принципу «снизу вверх»
весь цикл разработки новых систем.
Г.4.2.1. Объекты
Объектная ориентация основана на кон-
цепции инкапсуляции объектов вместе с со-
ответствующими описаниями данных и при-
меняемыми при этом методами (функциями).
Пользователи активизируют методы с помо-
щью сообщений, открывающих доступ к дан-
ным. Конкретные детали реализации метода
от пользователя скрыты.
Системы разрабатываются на уровне ти-
пов, т.е. похожие объекты группируются в
классы. В этой книге мы не разграничиваем
понятия «объект» (уровень экземпляров) и
«классы» (уровень типов), а говорим просто
об объектах. О каком именно понятии идет
речь, становится ясно из контекста. Еще од-
ной характеристикой объектов является их
наследственная функциональность. Она по-
зволяет подчиненным классам наследовать
методы и атрибуты, присущие вышестоящим
классам, посредством обобщения или специа-
лизации. Наследование лежит в основе прин-
ципа многократного использования.
Очевидно, что характеристики объектно-
ориентированных методов можно было бы
описать гораздо подробнее, однако для целей
данной работы достаточно и беглого обзора.
Рис. 52 иллюстрирует объектно-ориентиро-
ванное описание процесса «обработка зака-
за», рассмотренного в разделе Б.1. Здесь
представлены объекты, их имена, атрибуты и
методы. Показан также обмен сообщения ми,
включая метод соответствующего целевого
объекта, передаваемые данные и данные, со-
держащиеся в ответе. В отличие от рис. 5, где
приведен информационный поток, здесь мы
дифференцируем функции, активизирую-
щие обмен данными. Поток сообщений, кото-
рый является результатом потока управле-
ния бизнес-процессом, использовать необя-
зательно, так как последовательность
выполнения функций внутри объектов не
указана. Напомним, что бизнес-процессы ха-
рактеризуются рядом потоков, включая фун-
кциональный, выходной, информационный и
Управление бизнес-процессами на базе ARIS 89
Бизнес-объект "Прием заказа"
Заказ клиента
на поставку
Дата
Изделие
Количество
Заказ клиента
Бизнес-объект "Заказ на поставку"
Заказ поставщику
на поставку
Номер поставщика
Номер материала
Инициация ввода
данных
Подтверждение
поступления
Ввести заказ
Данные о закупке
Дата
Номер клиента
Номер изделия
Количество
Определить кредитоспособность
номер клиента
Ввод заказа
Проверка
кредитоспособности
Проверка наличия
Определение
потребности в
материалах
Подача заявки
Инициация
планирования
Определить запасы
Номер изделия
Клиент
Изделие
Имя
Номер клиента
Обозначение
Номер изделия
Определение
кредитоспособности
Кредите- —►
способность
Определение
запасов
Составить заказ
на поставку
Требования
к материалам
Составление заказа
на поставку
Прослеживание
заказа
на поставку
Проследить заказ
Планиро-
вать заказ
Данные
о заказе
Условные обозначения:
Начать функцию
Данные
Имя
Атрибут
Функция
Объект -
прочие услуги
Данные о заказе
Бизнес-объект "Изготовление"
Производственный план ^"(Ввести данные Документация на заказ
Номер плана Обозначение
Планирование заказа Прослеживание заказа Ввод данных Отправка документации
Производ- ственные данные
отменить операции
Номер изделия
График работ
Номер изделия
Номер графика
работ
Создание графика
работ
Отмена операций
Рис. 52. Объектно-ориентированное представление процесса «обработка заказа;
92 Бизнес-процессы
Язык Java можно использовать на трех
уровнях. Команды могут вводиться прямо в
текст HTML-страницы как исходный код
JavaScript. Этот код команд лишь отчасти
идентичен Java, хотя оба языка основаны на
C++. Однако JavaScript позволяет реализо-
вать лишь небольшие приложения, напри-
мер, для проверки значений или отображе-
ния «шапки» в строке состояния браузера.
Кроме того, JavaScript не способен обеспе-
чить осуществлять прямую связь между
клиентом и сервером.
Далее байт-код аплета передается клиен-
ту в дополнение к загружаемой HTML-стра-
нице. Переданный байт-код проверяется и
интерпретируется на клиенте, после чего ап-
лет выполняется. Аплеты запускаются толь-
ко в среде браузера, без него их исполнение
невозможно. Однако в рамках аплетов может
происходить дальнейшее общение между
сервером и клиентом. Аплеты способны заг-
ружать документы с сервера и обрабатывать
их до того, как они будут отправлены обратно
на сервер для завершения процесса. Прило-
жения могут выполняться независимо от сре-
ды браузера. Все, что им нужно — это вирту-
альная машина Java для передачи байт-кода.
Приложения позволяют разрабатывать не-
зависимые приложения, конструктивные
блоки которых по мере необходимости загру-
жаются на клиентский компьютер через сеть.
Как аплеты, так и приложения поддержива-
ют компонентное ПО. Установка и сопровож-
дение ненужных модулей не требуются. Сис-
темы собираются индивидуально в соответ-
ствии со спецификациями заказчика.
Эту концепцию можно включить в инфра-
структуру АБИ (см. рис. 54). Процессы, уп-
равляемые на уровне III системой workflow,
описываются на уровне моделирования. При-
ложения на уровне IV могут быть доступны в
виде байт-кода на серверах глобально рас-
пределенных приложений. При открытии
папки для обработки какого-либо события
система workflow создает Web-страницу, со-
ответствующую данному этапу обработки.
Эта Web-страница запускает аплет и вызы-
вает сервер приложений. Подключившись к
аплету, пользователи выполняют необходи-
мые функции, после чего данные возвраща-
ются и передаются системе workflow.
Данные включают также информацию о
времени и продолжительности процесса, ко-
торая агрегируется с помощью системы
workflow и возвращается для управления
процессами. Этот процесс поддерживает лю-
бую операционную систему и аппаратную
платформу. Нужные для обработки аплеты,
включая обрабатываемый объект, загружа-
ются через пользовательский интерфейс
браузера. Пользователи могут выполнять
функции децентрализованно. Клиенты име-
ют непосредственный доступ к любому методу.
После обработки преобразованные объекты
возвращаются на сервер, который передает
их на дальнейшую обработку.
В процессе обработки событий серверы
workflow постоянно контролируют запуск
любых других серверов и обработку данных.
Супервизоры могут запрашивать информа-
цию о времени и продолжительности процес-
са, а также о состоянии процесса в любой мо-
мент, хотя доступ к объектам во время их об-
работки невозможен (Binas-Holz. Java
Programmierbuch. 1996, особенно с. 98;
Goldammer. HTML-Script ruft Java Applet.
1996; van Hoff, Shaio, Starbuck. Java-Applets.
1996).
Г.4.2.4. Проблемы стандартизации
Для сборки прикладных систем из гетеро-
генных модулей необходимы стандартизо-
ванные интерфейсы, особенно для связи со
средами клиент-сервер. В настоящее время
попытки такой стандартизации предприни-
мают различные организации, в том числе
Группа по технологии управления объектами
(Object Management Group - OMG) и Группа
по разработке открытых приложений (Open
Application Group - OAG). Ту же цель пресле-
дуют промышленные стандарты, разрабаты-
ваемые крупнейшими поставщиками
(Microsoft, SAP и другие).
Консорциум OMG объединяет поставщи-
ков разной продукции. В начале 1998 года эта
организация насчитывала более 800 членов.
Предложенная ею архитектура управления
объектами (ОМА) представляет собой инф-
раструктуру для распределения и обеспече-
ния взаимодействия объектно-ориентиро-
ванных программных модулей в сетевых ге-
терогенных системах (см. рис. 55).
III. Управление workflow
IV. Прикладная система
I. Создание
процессов
V. РАБОЧЕЕ ПРОСТРАНСТВО
Этапы цикла
II. Планирование и
управление
процессами
Определяет инструменты
Сервер workflow
HTML-страница
Состоит
* йз
Определяет
..процессы
Описание процесса
“Сервер
приложений
Java-аплет
Онлайновая обработка
аплетами____________
Web-браузер |
Клиент
(Workflow и Web)
Исходный код Java
Система разработки
Управление бизнес-процессами на базе ARIS
Рис. 54. Связывание аплетов со зданием ARIS
<£>
W
94 Бизнес-процессы
Рис. 55. Архитектура управления объектами (OMG. Common Business Objects. 1996, с. 3)
Центральным элементом этой архитекту-
ры является брокер запросов к объектам
(ORB), предназначенный для обмена сообще-
ниями между объектами на гетерогенных
платформах в соответствии со стандартом
CORBA (Common Object Request Broker
Architecture - Общая архитектура брокера
запросов к объектам).
CORBA — это стандарт, устанавливаю-
щий взаимодействие клиентских и сервер-
ных объектов. Клиентский объект может ак-
тивизировать тот или иной метод с помощью
ORB. При этом ему совершенно не обязатель-
но «знать» местонахождение серверного
объекта.
Одна из задач OMG заключается в описа-
нии стандарта CORBA. Конкретную реализа-
цию оставляют на усмотрение различных по-
ставщиков. Среди существующих коммер-
ческих реализаций можно выделить ORBIX
фирмы IONA Technologies, Ltd.
Дальше этого попытки стандартизации
объектов приложений пока не идут. Ведется,
однако, работа по определению так называе-
мых «общих бизнес-объектов» (СВО), о кото-
рых речь пойдет далее. Службы CORBA
(CORBAservices) предоставляют базовые ус-
луги, например, проверку целостности. Сред-
ства CORBA (CORBAfacilities) можно срав-
нить с универсальной библиотекой классов:
они включают стандартные функции, наибо-
лее часто встречающиеся во многих прило-
жениях, что существенно экономит время и
силы пользователей при работе с приложе-
ниями. Домены CORBA (COR-BAdomains)
предлагают специализированные функции,
например, для систем автоматизированного
проектирования.
Корпорация Microsoft разработала стан-
дарты для связывания объектно-ориентиро-
ванных компонентов. Стандарты СОМ (ком-
понентная объектная модель) для однополь-
зовательских систем и DCOM
(распределенная компонентная объектная
модель) для распределенных систем обеспе-
чивают взаимодействие между объектами. В
настоящее время разрабатываются интер-
фейсы со стандартом CORBA.
Управление бизнес-процессами на базе ARJS 95
Интерфейс
Ядро
бизнес-объекта
Ограничения
Связанные
с объектом
Управление
входными
событиями
По подписке
Атрибуты
Подтипы
Методы
Бизнес
-правила
Связанные
со средой
Атрибуты
Выходное
событие
Доступ
через
COM/DCOM
Java
CORBA
Публикация
Бизнес-объект SAP (SAP. White Paper Business Objects. 1997, c. 7)
Рис. 56.
Компания SAP также разработала кон-
цепцию взаимодействия с бизнес-объектами,
которая называется BAPI (интерфейс про-
граммирования бизнес-приложений). Интер-
фейсы BAPI реализуются в качестве методов
работы с бизнес-объектами SAP, предостав-
ляя открытый доступ к бизнес-функциям.
Структура бизнес-объектов SAP представ-
лена на рис. 56.
Ядро бизнес-объекта SAP заключает в
себе базовую бизнес-логику. Второй слой со-
держит бизнес-правила, отвечающие за це-
лостность. Третий слой охватывает объект-
ные методы, атрибуты, а также средства уп-
равления входными событиями, выходные
события и описания BAPI. В качестве интер-
фейсов поддерживаются стандарты СОМ/
DCOM, CORBA и Java.
В расширенной версии этой концепции
бизнес-объекты группируются в пакеты —
так называемые бизнес-компоненты. На пер-
вом этапе вся система R/3 включала лишь
три компонента (HR - человеческие ресурсы,
LO - логистику и FI/СО - финансы/контрол-
линг). Впоследствии было добавлено еще с де-
сяток вновь разработанных компонентов (на-
пример, Business Engineer и Business
Information Warehouse). Взаимодействие
между этими компонентами, осуществляе-
мое при помощи технологии ALE (возмож-
96 Бизнес-процессы
Рис. 57. Бизнес-компоненты (SAP. White Paper Business Frameworks. 1996, c. 6)
Управление бизнес-процессами на базе ARIS 97
Специализированный бизнес-объект
Финансо- вые бизнес- объекты Производствен- ные бизнес- объекты Прочие бизнес- объекты
Общие бизнес-объекты
Библиотека бизнес-объектов
CORBA, Службы CORBA, Средства CORBA
Рис. 58. Встраивание общих бизнес-объектов ( OMG. Common Business Objects. 1996, с. 21)
ность связи приложений), можно сравнить со
способом взаимодействия между независи-
мыми системами R/3 и между системами R/3
и R/2 (см. рис. 57). Концепция ALE поддержи-
вается Группой OAG, что является залогом
продолжения разработки общего стандарта.
Она также обеспечивает взаимодействие с
Интернет-приложениями.
Интерфейсы BAPI и сообщения ALE слу-
жат методами доступа к бизнес-объектам
или компонентам. Главное различие между
ними заключается в степени структуриро-
ванности. В то время как сообщение ALE спо-
собно активизировать через Интернет слож-
ное приложение, например, всю процедуру
обработки заказа, интерфейсы BAPI предпо-
лагают более детальные методы, скажем,
проверку доступности (Zencke. BAPI. 1997).
Сообщения ALE могут обрабатываться асин-
хронно в отличие от синхронной работы ин-
терфейсов BAPI.
Опираясь на результаты CORBA, Группа
OMG также выступила поборником стандар-
тизации бизнес-объектов. В 1996 году она
опубликовала документ RFP-4, приглашая
специалистов высказать свои идеи относи-
98 Бизнес-процессы
Рис. 59. Рабочее пространство с взаимозаменяемыми компонентами
(Pree. Komponentenbasierte Softwareentwicklung. 1997, с. 7)
тельно стандартизации общих бизнес-объек-
тов (СВО ~ Common Business Objects). Задача
заключалась в том, чтобы создать описание
базовых приложений, из которых можно
было бы конструировать конкретные объек-
ты. Принцип встраивания СВО показан на
рис. 58. Например, СВО может представлять
собой объект, используемый для обработки
информации о продажах или данных финан-
сового учета. Некоторые предложения были
связаны с проблемами расчета обменных
курсов валюты (этот вопрос был поднят кор-
порацией IBM), другие относились к прило-
жениям workflow. Описание объектов долж-
но создаваться в соответствии с рекоменда-
циями (OMG. Common Business Objects.
1996, с. 17), разработанными по следующим ас-
пектам:
— обозначение СВО,
— атрибуты объектов
— отношения между СВО,
— условия, необходимые для СВО и их
взаимоотношений,
— правила бизнес-процесса, применя-
емые к СВО и их взаимоотношениям,
— спецификация интерфейсов и методов
СВО на языке описания IDL, принятом
Группой OMG.
Благодаря этой деятельности открывается
наиболее реальная возможность поставить
разработку программного обеспечения «на
конвейер-». Одним из ключевых факторов,
способствующих успеху такого подхода, яв-
ляется концепция инфраструктуры.
Управление бизнес-процессами на базе ARIS 99
Рис. 60. Промышленная производственная система
Г.5. Рабочее пространство
(инфраструктура)
Г.5.1. Концепция рабочего
пространства
Объектно-ориентированный подход бла-
годаря принципу наследования расширил
модульную концепцию и упростил процесс
внесения изменений, исключив необходи-
мость в создании новых разновидностей мо-
дулей. Концепция инфраструктуры идет еще
дальше, позволяя объединять различные
компоненты в конкретное приложение (см.
рис. 59). На первый взгляд это напоминает
бизнес-объект. Однако данная концепция
включает также инфраструктурные компо-
ненты (системы workflow, средства модели-
рования и межплатформное программное
обеспечение), связывающие бизнес-объекты
в приложение в рамках инфраструктуры. Бо-
лее того, принцип наследования, присущий
объектно-ориентированному методу, заме-
няется принципом компонования.
Взаимозаменяемые компоненты в инфра-
структуре являются «горячими точками»;
пользователи могут заменять их собственны-
ми компонентами в соответствии со своими
потребностями. На рис.59 эти компоненты
заштрихованы. Компоненты, которые нельзя
заменить, являются «застывшими точками».
Адаптация рабочего пространства путем за-
мены компонентов называется компоновани-
ем и представляет собой альтернативу
объектно-ориентированной адаптации, где
подклассы обладают свойством наследова-
ния. Таким образом, рабочие пространства —
это незаконченные прикладные системы, ко-
торые пользователь может настроитьприме-
нительно к конкретным нуждам путем «пере-
ключения» компонентов. Следовательно, этот
подход позволяет многократно использовать
не только сами компоненты, но и архитектур-
ное ноу-хау для их связывания.
Программные продукты в этом случае
концентрируют внимание на самих рабочих
пространствах и на включении межплатфор-
много программного обеспечения, перекиды-
вая мостик между приложениями, операци-
онной системой и аппаратными средствами.
100 Бизнес-процессы
Рис. 61. Информационная система, управляемая workflow
Мы попытались провести аналогию между
промышленными производственными систе-
мами и информационными системами. Эта
аналогия особенно очевидна, когда информа-
ционные системы основаны на технологии
workflow и рабочего пространства.
На рис. 60 представлена промышленная
производственная система, а на рис. 61 — ин-
формационная система, управляемая
workflow, в эквивалентной структуре. Про-
ектирование и описание продуктов осуще-
ствляются на стадии инжиниринга. На ста-
дии планирования определяются графики
выполнения производственных процессов. В
информационной системе это соответствует
уровню I концепции АБИ. Производственная
система управляется системой производ-
ственных графиков, которая соответствует
уровню II концепции АБИ.
Система транспортировки материалов
связывает склад, где хранятся подлежащие
обработке объекты, и машинную систему,
выполняющую функции обработки. Процесс
реализуется в соответствии с графиком ра-
бот. Система перемещения материалов соот-
ветствует системе workflow уровня III кон-
цепции АБИ. Хранение и выполнение функ-
ций уровня IV соответствуют базе данных и
бизнес-объектам.
Надеемся, что аналогия между приведен-
ными системами прослеживается достаточно
отчетливо. Применительно к информацион-
ным системам концепция АБИ подразделяет
всю систему на склад (хранилище данных),
систему транспортировки материалов
(workflow) и выполнение функций (бизнес-
объекты). Уровни I и II представлены соот-
Преимущества ARIS для пользователя 101
ветственно моделированием продуктов и
процессов — с одной стороны, и планирова-
нием и управлением процессами — с другой.
Структурирование информационных систем
на подсистемы упрощает их разработку и уп-.
равление, а также обеспечивает более гиб-
кую индивидуальную настройку.
Г.5.2. Концепции реализации
Сегодня концепции реализации, опериру-
ющие понятием «рабочее пространство», на-
ходятся на различных этапах разработки.
Тем не менее, они наглядно свидетельствуют
о важной роли этой концепция в будущем.
Г.5.2.1. Рабочее пространство
(инфраструктура) ARIS
Концепция рабочего пространства (РП)
ARIS, разработанная фирмой IDS в качестве
прототипа, совместима с концепцией АБИ,
поскольку ARIS Toolset предоставляет инст-
рументальные средства моделирования и
анализа на уровне инжиниринга процессов.
На уровне планирования и управления
бизнес-процессами имеются специальные
интегрированные продукты для поопераци-
онного исчисления стоимости, мониторинга,
составления графиков и регулирования мощ-
ностей, а также интерфейсы с продуктами
сторонних поставщиков, например, MS
Project.
На уровне workflow ARIS предоставляет
функции создания прототипов и интерфейсы
примерно с десятью разными системами
workflow.
На уровне прикладных систем, помимо ин-
терфейсов для работы со стандартными про-
граммными решениями типа SAP R/3 через
процедуры вызова удаленных функций
(RFC) и интерфейсов BAPI, если таковые
имеются, представлены обобщенные (родо-
вые) бизнес-объекты для решений, связан-
ных с логистикой.
Прикладное ноу-хау хранится на уровне I
в моделях-прототипах и служит для напол-
нения содержанием других уровней. Индиви-
дуальная настройка моделей-прототипов по-
зволяет адаптировать обобщенные бизнес-
объекты, разработанные на уровне IV, к кон-
кретным приложениям. На рис. 62 представ-
лена архитектура рабочего пространства
ARIS, где управление бизнес-объектами на
сервере приложений осуществляется менед-
жером объектов. Связь данных с сервером
приложений устанавливается при помощи
независимого интерфейса с реляционными
базами данных. Шлюз CORBA обеспечивает
интерфейс с внешними системами, которые
активизируются событиями. Система
workflow в рабочем пространстве ARIS уп-
равляет процессами, происходящими в рам-
ках бизнес-объектов и между ними, а также
связями с внешними системами.
Связь клиентов Window с сервером прило-
жений реализуется через интерфейсы
CORBA.
Бизнес-объекты можно конфигурировать
на уровне моделирования, используя типы
моделей уровня I.
Модели данных позволяют вводить допол-
нительные атрибуты или отбрасывать не-
нужные. Визуальные представления (экра-
ны) бизнес-объектов создаются с помощью
моделей шаблонов. Функции бизнес-объек-
тов можно выбирать, используя модели фун-
кций. Модели процессов задают связь между
функциями и моделями. Они также управля-
ют процессами в рамках бизнес-объектов.
Привилегии функций и данных описываются
организационными диаграммами и диаграм-
мами привилегий. Методы моделирования и
варианты конфигураций подробно рассмат-
риваются в работе: Scheer. ARIS - Business
Process Modeling. 1998.
Г.5.2.2. Рабочее пространство SAP
Бизнес-объекты и компоненты SAP, пред-
ставленные на рис. 56 и 57, иллюстрируют
ключевые элементы рабочего пространства
SAP. Эти элементы включают модель-прото-
тип SAP, где бизнес-процессы описываются
диаграммами ЕРС, технологию интеграции
АБЕ, бизнес-workflow SAP, технологию ин-
терфейсов BAPI для бизнес-объектов и сами
бизнес-объекты (SAP. White Paper Business
Framework. 1996, c. 15).
1. Инжиниринг проце 1- —i Модели данных ссов Модели шаблонов Модели функций схв’ ° шо Модели процессов Органиграмма 1 о о Диаграмма привилеги
II. Планирование и управление ARIS
процессами Пооперационное исчисление стоимости
Мониторинг
Интерфейсы управления процессами
III. Workflow ARIS
ARIS
Интерфейсы workflow, например,
Staffware, IBM-Flowmark,
SNI-Workparty и т.д
Бизнес-процессы
Операция Поставщик
Интерфейсы ARIS
со стандартными программами
через RFC, BAPI и т.д.
Техническая среда Операционные системы Системы баз данных Интерфейсы клиент-сервер
| Windows NT | | Poet | | CORBA |
| Windows 95 | | Oracle | 1 TCP/IP i
| Unix J 1 SQL | г.т' • :i
Рис. 62. Архитектура рабочего пространства ARIS
Преимущества ARIS для пользователя 103
Прикладные компоненты Организация корпорации
Сценарии бизнес-процессов
Рис. 63. Компоненты SAP Business Engineer (SAP White Paper Business Framework. 1996)
В концепцию рабочего пространства сле-
дует включить и SAP Business Engineer (BE)
вместе с его возможностями конфигурирова-
ния, хотя этот элемент не упомянут. В общем
виде Business Engineer представлен на рис. 63
(SAP. White Paper Business Framework. 1996,
c. 9; Schroder. Business Engineer. 1997). Не-
смотря на индивидуальную разработку раз-
личных компонентов (BE, workflow, модели-
рование данных и т.д.), в настоящее время все
более широкую популярность приобретает
интеграция решений. Рабочее пространство
SAP интегрирует не только программные ре-
шения SAP, но и решения сторонних произ-
водителей ПО. Это открывает путь к созда-
нию комплексных решений для вертикаль-
ных рынков. В то же время рабочее
пространство и технология SAP могут слу-
жить инструментарием при разработке
пользователями собственных усовершен-
ствований к SAP R/3.
Г.5.2.3. SNI-ComUnity
Инфраструктура, предложенная фирмой
Siemens-Nixdorf, сочетает в себе систему
workflow под названием Workparty, инстру-
ментарий для конфигурирования ComUnity
и различные бизнес-объекты для промыш-
ленных приложений. Связывая средства мо-
делирования ARIS на уровне I и (несколько
позже) на уровне II, SNI создает концепту-
альную схему, в той или иной степени соот-
ветствующую концепции АБИ. Архитектура
технической платформы Workparty пред-
ставлена на рис. 64. Как видим, для нее харак-
терно частое использование стандартов
Microsoft.
104 Бизнес-процессы
Уровень
пользовательского
интерфейса
(Visual Basic)
Формы
Visual Basic
Внешние приложения
Приложения, поддерживающие
интерфейс СОМ, например,
MS-Office и т.д.
Службы интерфейса пользователя
C0M/DC0M
Контроллер приложений
управления бизнесом (УБ)
р
а
з
(Visual Basic)
C0M/DC0M
(Visual Basic/
Visual C++))
tt
Контроллер внешних приложений
Уровень управления
бизнесом
Службы УБ

Уровень
бизнес-данных
Репозиторий
ODBC
Администратор
репозитория
объектов
ы
К
о
а
CASE/UML
данных
Рис. 64. Архитектура SNI ComUnity (Siemens Nixdorf. ComUnity. 1997)
Г.5.2.4. Проект San Francisco
компании IBM
Проект San Francisco компании IBM со-
здан с целью ускорить и удешевить разра-
ботку приложений для малых и средних
предприятий (SME). Как показано на рис. 65,
проект San Francisco включает различные
уровни. Разработчик приложений занимает
верхнюю ступеньку, откуда осуществляет
доступ к остальным уровням. Виртуальная
машина Java обеспечивает независимость
прикладных решений от аппаратно-про-
граммной платформы.
Базовый уровень подразделяется на три
компонента: базовые службы, базовые клас-
сы объектных моделей и утилиты.
— Базовые службы основаны на стандар-
те OMG для служб объектов. Они пред-
ставлены на языке Java и частично
адаптированы к функциональным воз-
можностям Java и специфическим тре-
бованиям IBM.
— Базовые классы объектных моделей со-
держат механизмы для хранения или
идентификации объектов.
— Утилиты содержат базовые компонен-
ты графического пользовательского ин-
терфейса (GUI) и функции управления
Преимущества ARIS для пользователя 105
Код, созданный
разработчиком
Совместно
используемые
рабочие пространства
Коммерческие приложения
Базовые инфраструктуры бизнес-процессов
Общие бизнес-объекты
Интерфейс виртуальной машины Java
Базовый уровень
OS/400 OS/2 NT AIX MVS/ESA HP UX
Серверы
Клиенты
Windows 95
Рис. 65. Проект San Francisco компании IBM (IBM. Shareable Frameworks. 1996)
сеансами, включая средства управле-
ния конфликтами. Хотя эти функции
частично заложены в операционной си-
стеме, наличие таких средств в утили-
тах обеспечивает интеграцию и единые
принципы построения пользовательс-
кого интерфейса.
Общие бизнес-объекты (СВО) применимы
ко многим вертикальным рынкам. Разработ-
чикам программного обеспечения остается
дополнить отдельные функции или добавить
конкретные характеристики, отражающие
специфику компании. Сюда могут входить
такие функции, как управление адресами,
условия платежа, календарное планирова-
ние или обмен данными (например, EDI). Эти
СВО сопоставимы с общими бизнес-объекта-
ми OMG, что объясняет заинтересованность
IBM в сертификации СВО Группой OMG. Ба-
зовые инфраструктуры бизнес-процессов
предоставляют объекты для управления за-
казами, управления хранилищами (склада-
ми), а также для корпоративного учета. По
оценкам IBM, на общие бизнес-объекты и ба-
зовые инфраструктуры бизнес-процессов
приходится примерно 40% любого приложе-
ния. Остальное составляют экранные формы,
характеристики, учитывающие конкретные
особенности страны и отрасли, бизнес-прави-
ла и дополнительные функции, составляю-
щие специфику приложения.
Г.5.3. Перспективы развития
индустрии программного
обеспечения
Появление компонентного ПО и создание
рабочих пространств открывают новые воз-
можности для разработки программного
обеспечения. Здесь можно провести анало-
гию с производством компьютерного обору-
дования, где на смену вертикальному подхо-
ду, когда поставщики изготавливали аппа-
106 Бизнес-процессы
ратные системы целиком «от и до», пришел
горизонтальный принцип, при котором
процессоры, периферийные устройства,
операционные системы и т.д. изготавлива-
ются отдельно, а затем компонуются. Те же
перспективы и в области разработки при-
кладного ПО. Применительно к аппарат-
ным средствам предпосылкой такого раз-
вития стало создание стандартов на про-
цессоры, операционные системы, базы
данных и коммуникационные сети.
Помимо прочего, для разработки при-
кладных систем потребуются стандарты на
компоненты и инфраструктуры. Такие
стандарты позволят адаптировать компо-
ненты, выпускаемые разными производи-
телями, к различным рабочим простран-
ствам.
Есть основания полагать, что глубина
производства в индустрии ПО станет
уменьшаться. Рынок будут формировать
производители, специализирующиеся на
комплексных решениях и выполняющие
сборку компонентов в рамках (своих) инф-
раструктур, а также поставщики компо-
нентов. Между этими двумя полюсами зай-
мут место изготовители подсистем, постав-
ляющие промежуточные продукты.
Отбор и замена компонентов будут про-
изводиться по принципу «лучших предста-
вителей своего класса», а при сборке в цен-
тре внимания будет ноу-хау самого бизнеса
и возможности его моделирование в соот-
ветствии с методом сборки. Таким образом,
точками фокусировки при разработке про-
граммного обеспечения станут уровень ин-
жиниринга как часть концепции АБИ с его
методами моделирования, а также связи
для интеграции с workflow и адаптации
бизнес-объектов.
Точно так же, как в автомобильной про-
мышленности производители должны об-
ладать знаниями и опытом в области разра-
ботки (инжиниринга), логистики и сборки,
поставщикам комплексных решений, поми-
мо овладения инфраструктурами, потребу-
ются навыки в работе с методами наполне-
ния их содержанием и моделирования,
представленные на уровне I. Кроме того, им
необходимо будет оценивать кандидатуры
поставщиков компонентов, а также уста-
навливать связи между производителями и
поставщиками. Производителям комплекс-
ных решений потребуются также знания и
опыт в области консалтинга и технического
обслуживания на глобальном уровне, т.е.
возможности, которыми располагают толь-
ко крупные корпорации. Такой «багаж» не-
обходим, чтобы гарантировать целостность
предлагаемых полных решений. Постав-
щики помельче сосредоточатся на разра-
ботке отдельных компонентов и подсистем.
С другой стороны, не следует переоце-
нивать возможности рынка компонентного
ПО - здесь крупным поставщикам решений
придется делать выбор. Проблема в том,
что принцип конструктора «Лего», допус-
кающего произвольную компоновку эле-
ментов, в этой области неприменим. Эле-
менты «Лего» совершенно идентичны и со-
бираются по типовой схеме. Для этого
необязательно понимать их внутреннюю
структуру, достаточно знать, что они име-
ют стандартные размеры и «связи».
В отличие от «Лего» программные ком-
поненты содержат прикладную информа-
цию — каждый свою. Для их сборки необхо-
димо хорошо разбираться в технических
интерфейсах и логике приложения. Этим
определяется возможность или невозмож-
ность использования в сборке того или ино-
го компонента. Главное условие для пра-
вильной сборки —наличие исчерпывающе-
го документального описания компонентов.
Создание сложных модулей требует объе-
динения усилий поставщиков комплексных
решений и поставщиков отдельных компо-
нентов. Здесь можно провести аналогию с
аэрокосмической и автомобильной отрас-
лями. В этих отраслях обмен информацией
о продуктах и тесное сотрудничество в про-
цессе разработки называются параллель-
ным инжинирингом (Scheer. Business
Process Engineering. 1994). Опыт в области
параллельного инжиниринга и многие его
методы в значительной мере применимы и
к разработке программного обеспечения. К
Преимущества ARIS для пользователя 107
сожалению, в отличие от сферы матери-
ального производства, поставщику про-
граммных компонентов труднее защитить
свое ноу-хау. Если знания и опыт, которы-
ми обладают изготовители автотранспорт-
ных средств в области научно-исследова-
тельских и опытно-конструкторских раз-
работок, а также в области производства,
охватывают процедуры и технические ре-
сурсы, и при этом они постоянно произво-
дят свою продукцию, то все, чем располага-
ют поставщики ПО, — это методы и техно-
логии разработки.
После совместной работы над каким-ни-
будь проектом поставщику решений не со-
ставит ни малейшего труда «позаимство-
вать» у партнера его ноу-хау.
Важнейшими условиями интенсивного
развития компонентного ПО являются со-
здание эффективных механизмов защиты
и определенная культура отношений, ос-
нованная на принципах доверия и сотруд-
ничества между поставщиками компонен-
тов и поставщиками готовых решений.
108 Бизнес-процессы
Д. Моделирование
стандартов в ARIS
Моделирование в ARIS представляет со-
бой манипулирование элементами при помо-
щи моделей, фаз, понятий и методов ARIS с
целью описания бизнес-процессов. Модели-
рование - процесс творческий, и поэтому он
не поддается жесткой регламентации. Одна-
ко соблюдение некоторых стандартов дает
возможность классифицировать и с понима-
нием использовать разработанные ранее мо-
дели. Нелишне также установить определен-
ные стандарты качества и неизменно следо-
вать им.
В этом разделе мы кратко обсудим общие
принципы моделирования, а затем более под-
робно уровни моделирования (уровень эк-
земпляров, уровень типов, метауровень и
мета2-уровень), степени структурирования и
детализации, а также различные варианты
моделей.
Д.1. Общепринятые принципы
моделирования
Термин «общепринятые принципы моде-
лирования» (Becker, Rosemann, Schutte.
Grundsatze ordnungsgemafier Modellierung.
1995; Galler. Vom Geschaftsprozefimodell zum
Workflow-Modell. 1997; Reiter, Wilhelm, Geib.
Multiperspektivische Informationsmodelli-
erung. 1997) возник по аналогии с термином
«общепринятые принципы учета» (ОППУ).
Принципы моделирования обеспечивают
максимальное число степеней свободы при
«прозрачном» контроле качества (Maier.
Qualitat von Datenmodellen. 1996).
В концепции и вспомогательных инстру-
ментах ARIS заложены следующие правила,
постоянно совершенствуемые в рамках Ис-
следовательского Проекта Правительства
Германии (Projekt «GoM». Fordergebiet
Softwaretechnologie. Az.: 523-4001-01 IS 604 A).
Принцип корректности. Корректность
моделей зависит от правильности се-
мантики и синтаксиса, т.е. от полноты и
согласованности синтаксиса конкрет-
ной метамодели. «Семантическая кор-
ректность модели определяется тем,
насколько адекватно она отвечает
структуре и поведению моделируемой
объектной системы» (Rosemann.
Komplexitatsmanagement in Prozefimo-
dellen. 1996, c. 94). В реальных приложе-
ниях соответствие этим требованиям
можно подтвердить лишь после прове-
дения имитационных экспериментов
или выполнения иных аналогичных ша-
гов. Для этой цели прекрасно подходит
ARIS Toolset. Этот инструмент распо-
лагает широким набором правил для
проверки синтаксиса модели, позволяя
убедиться, что каждая функция не
только активизируется определенным
событием, но и в свою очередь активи-
зирует следующее событие и т.д.
Принцип релевантности. Следует мо-
делировать лишь те фрагменты реаль-
ной объектной системы, которые соот-
ветствуют назначению модели. Модель
не должна содержать информации
больше, чем необходимо. Это позволяет
сохранить соотношение затраты/выго-
ды на приемлемом уровне.
Принцип соизмеримости затрат и вы-
год. К числу факторов, определяющих
эффективность соотношения затраты/
выгоды, относятся объем усилий, необ-
ходимых для создания модели, полез-
ность моделирования конкретного сце-
нария и продолжительность использо-
вания модели.
Принцип прозрачности. «Прозрач-
ность» гарантирует понятность и удоб-
ство модели для пользователей. Она
также определяет степень рациональ-
ности отношений между моделью и
пользователем. (Rosemann. Komp-
lexitatsmanagement in Prozefimodellen.
Моделирование стандартов в ARIS 109
1996, с. 99). Поскольку модели содержат
большой объем информации, относя-
щейся к техническим и организацион-
ным вопросам, быстро в них разобрать-
ся обычно под силу только специалис-
там. При разбиении моделей на
различные типы представлений (под-
модели) легче понять конкретные ас-
пекты.
Принцип сравнимости. Модели, со-
зданные на базе согласованной концеп-
туальной инфраструктуры и единого
языка моделирования, сравнимы меж-
ду собой, если имена объектов отвечают
установленным соглашениям и если ис-
пользовались идентичные объекты мо-
делирования, а также эквивалентные
степени детализации. (Rosemann.
Komplexitatsmanagement in Prozefimo-
dellen. 1996, с. 102).B отношении моде-
лей, описанных разными языками, важ-
но убедиться в сопоставимости их мета-
моделей.
Принцип систематизированной струк-
туры. Этот принцип в качестве обяза-
тельного условия предполагает воз-
можность интеграции моделей разных
типов. Для этого требуется единая ме-
тамодель, объединяющая различные
типы представлений, что может обеспе-
чить информационная модель ARIS.
Д.2. Уровни моделирования
Концепция ARIS разработана на мета-
уровне, независимом от конкретной приклад-
ной области (см. рис. 12). Поскольку условия,
допускаемые на этом уровне, справедливы
также для уровней типов и экземпляров, кон-
цепция ARIS автоматически распространя-
ется на уровни моделирования, лежащие
ниже.
На рис. 66 представлен пример моделей
ARIS на уровне определения требований.
Для каждой модели описывается типичное
понятие, связанное с понятием лежащего
ниже уровня абстракции отношением класс-
элемент.
На мета2-уровне описывается только об-
щее понятие «тип объекта». По отношению к
этому классу понятия, используемые на ме-
тауровне, выступают в качестве элементов.
Информационная модель ARIS разрабатыва-
ется на метауровне. Иными словами, именно
здесь определяются общие понятийные клас-
сы, описывающие бизнес-процесс, и отноше-
ния между ними. Реальные приложения мо-
делируются на прикладном уровне, причем
информационные системы для бизнеса обыч-
но разрабатываются на уровне описания, что
придает этим методам моделирования осо-
бую ценность. Конкретные экземпляры моде-
лируются на уровне экземпляров. Все эти
процессы выполняются в реальном времени.
Каждый уровень абстракции обозначен
соответствующим символом (см. правую
часть диаграммы на рис. 66).
Модели обычно создаются на уровне типов
в соответствии с фазами проектирования
бизнес-процесса. Это делает модели «неуяз-
вимыми» к любым модификациям экземпля-
ров, например, в тех случаях, когда в модель
данных включаются новые изделия или из
организационной модели удаляются отдель-
ные сотрудники. Однако если в определенном
типе бизнес-процесса всегда присутствуют
одни и те же экземпляры, то их можно ис-
пользовать и для моделирования. Такие си-
туации возникают, когда некие функции вы-
полняются только определенным специалис-
том, или если многократно используется один
и тот же экземпляр данных, или если данная
модель всегда связана с конкретной органи-
зационной единицей, а не с ее типом. Именно
по этой причине в некоторых моделях уровни
экземпляров и уровни типов объединяются.
Для того чтобы лучше понять уровни опи-
сания, рассмотрим процесс создания на базе
ARIS Toolset эскизного варианта некоторой
стандартной модели.
Хранение и управление всеми моделями
ARIS Toolset осуществляется на мета-’-уров-
не. Это делает их независимыми от конкрет-
ных методов, поскольку все описания, специ-
фичные для того или иного метода и модели,
являются экземплярами этого общего типа-
110 Бизнес-процессы
Мета2-уровень
Тип объекта
Обозначение
уровней абстракции
Мета2
Мета
Типы приложения
Экземпляры
Изделие
Изделие 1235
Рис. 66. Уровни моделирования ARIS
Моделирование стандартов в ARIS 111
Рис. 67. Стандарт администрирования модели в ARIS Toolset
112 Бизнес-процессы
Тип объекта № типа объекта Описание Обозначение
1 Тип функции Скругленный прямоугольник
2 Тип сущности Прямоугольник
3 Тип организационной единицы Овал
4 Тип выхода Прямоугольник в двойной рамке
Рис. 68. Таблица типов объектов
Прикладной объект № прикладного объекта № типа объекта Описание
1 1 Ввод заказа
2 1 Прослеживание заказа
3 1 Отправка
4 2 Клиент
5 2 Изделие
6 3 Установка (Цех)
7 4 Конечный продукт
Рис. 69. Таблица прикладных объектов
Моделирование стандартов в ARIS 113
Тип объекта № типа объекта Описание Обозначение
4 Выход Прямоугольник в двойной рамке
10 Экземпляр функции Скругленный прямоугольник
11 Экземпляр сущности Прямоугольник
12 Экземпляр Овал
организационной единицы
13 Экземпляр выхода Прямоугольник в двойной рамке
Рис. 70. Таблица типов объектов, дополненная типами экземпляров
Прикладной объект № прикладного объекта № типа объекта Описание объекта
7 4 Конечный продукт
10 4 Конечный продукт 1234
11 4 Конечный продукт 1235
12 2 КлиентМ
13 2 КлиентN
Рис. 71. Таблица прикладных объектов, дополненная типами экземпляров
114 Бизнес-процессы
Рис. 72. Структурированность модели
объекта. Таким образом, в ARIS Toolset мож-
но включать новые методы моделирования,
причем (как правило) без каких-либо измене-
ний в программе.
Класс ТИП ОБЪЕКТА на мета2-уровне ис-
пользует в качестве экземпляров объекты
метауровня, например, типы функций, типы
организационных единиц, типы выходов и т.д.
(см. рис. 67). К каждому объекту моделирова-
ния можно применять те же операции (созда-
ние, удаление, отображение, перемещение и
представление в виде иерархии), которые оп-
ределяются в классе ТИП ОБЪЕКТА. На рис.
68 класс ТИП ОБЪЕКТА представлен в виде
таблицы. Если посредством новых методов
вводятся новые объекты моделирования, то
они рассматриваются как новые экземпляры
данного класса, т.е. представляются соответ-
ствующими строками в таблице типов объек-
тов.
Модели прикладного уровня являются эк-
земплярами объектов моделирования на ме-
тауровне. На рис. 67 это показано пунктирны-
ми линиями. Для целей хранения на мета2-
уровне вводится класс ПРИКЛАДНОЙ
ОБЪЕКТ. Этот класс содержит все экземпля-
ры объектов метауровня и, следовательно, он
связан с классом ТИП ОБЪЕКТА отношени-
ем *:1. Отношения хранения представлены
сплошными линиями. Линии между объекта-
ми моделирования определяются в модели
связью СОЕДИНЕНИЕ между ПРИКЛАД-
НЫМИ ОБЪЕКТАМИ. Эта ситуация описана
в таблице на рис. 69. В то время как «имена
классов» на метауровне являются элемента-
ми класса ТИП ОБЪЕКТА, прикладные
объекты представляют собой элементы ме-
таклассов.
Моделирование стандартов в ARIS 115
В том случае, когда модели экземпляров
создаются в ARIS (например, для приложе-
ний workflow), интерпретация мета- и мета2-
моделей ARIS расширяется. Структура
мета2-модели на рис. 67, в отличие от до пус-
тимых экземпляров, не меняется. Мета2-мо-
дель класса ТИП ОБЪЕКТА (см. рис. 70)
включает различные описания экземпляров
прикладных объектов, а также реальные эк-
земпляры этих прикладных объектов (см.
рис. 71). Таким образом, в таблицы вводятся
не только типы приложений, но и их экземп-
ляры. То же справедливо для связи СОЕДИ-
НЕНИЕ и для других связей.
Каждая модель в ARIS Toolset логически
хранится в нескольких больших таблицах.
Эти таблицы реализуются в объектно-ориен-
тированной базе данных (РОЕТ), обеспечи-
вая более детальные и, следовательно, более
эффективные с точки зрения производитель-
ности структуры доступа (например, к комп-
лексным моделям).
Д.З. Степени структурирования и
детализации
Можно создавать модели с разной степе-
нью структурирования. В примере на рис. 72
классы данных и связи в прикладной области
представлены на уровне определения требо-
ваний. Сначала диаграммы классов группи-
руются в кластерные понятия, которые затем
объединяются в модель продаж. Все три по-
нятийных уровня связаны отношениями 1:* -
«часть целого».
Структурированность модели представ-
лена блоками трехъярусной пирамиды (см.
рис. 72).
При описании больших прикладных обла-
стей, бесспорно, необходим иерархический
подход. На рис. 73 показано, как с помощью
ARIS Toolset создается иерархическое пред-
ставление в модели-прототипе логистики
продаж, разработанной консультантами ком-
пании IDS Prof. Scheer GmbH.
На рис. 74 представлены основные этапы
структурирования модуля Business Engineer
(BE) системы SAP R/3. Крупные функцио-
нальные области (продажа, производство и
т.д.) конкретного вертикального рынка объе-
диняются на уровне бизнес-сценария; уро-
вень бизнес-процессов охватывает альтерна-
тивные процессы для той или иной функцио-
нальной области. В рамках альтернативного
процесса представлены альтернативные
функции (бизнес-функции, участвующие в
бизнес-процессе).
Более того, с помощью моделей можно
описывать и различные подобласти сложного
целого. Любую модель — будь то полная кор-
поративная модель или одна из ее подмоде-
лей — можно построить в соответствии с кри-
териями бизнеса. Это можно наглядно пред-
ставить в виде мозаики, где отдельные
элементы складываются в цельную картину
(см. рис. 75).
Д.4. Варианты моделей
При обсуждении вопросов, связанных с
непрерывным совершенствованием процес-
сов и версиями моделей, мы коснулись аспек-
та управления вариантами моделей, которые
создаются по ходу дела и различаются по
времени создания. Иногда возможно парал-
лельное использование нескольких вариан-
тов модели, предназначенных для разных ус-
ловий в одной и той же ситуации. Для созда-
ния вариантов существует два основных
метода:
— выбор варианта на основе имеющейся
базовой модели. Здесь, помимо самих
объектов, из базовой модели переносят-
ся знания в области отношений между
объектами;
— конструирование варианта из общих
стандартных блоков.
В системе CIM Analyzer, разработанной в
1991 году Институтом информационных сис-
тем (IWi), функции, необходимые для дея-
тельности предприятия, выбирались на осно-
ве разветвленного дерева функций и сово-
купности бизнес-атрибутов в соответствии с
известными правилами (Jost. EDV-gestutzte
CIM-Rahmenplanung. 1993, с. 33).
AHIS - Mealing OftHnualson
l-|g|x|
£*» £* y*w Atywton Ev>«»» A‘i«nee Inte? J^Wtow
'••O eg H • л»еь 'ЭВ v- •'” Я •. - й* » 9t Q =
116 Бизнес-процессы

Рис. 73. Иерархическое представление с помощью ARIS различных уровней модели-прототипа
Моделирование стандартов в ARIS 117
Рис. 74. Иерархия модели SAP (Schroder. Business Engineer 1997)
Рис. 75. Символическое представление подмодели и полной модели
118 Бизнес-процессы
Инжиниринговое решение Организационные последствия
Переход с производства специализированных продуктов на выпуск стандартных продуктов с вариантами Например, упрощение процедур проектирования и обработки заказов клиентов; стандартизация графиков работ; внедрение системы управления вариантами.
Возврат конечных продуктов, отслуживших свой срок Например, внедрение конструктивных решений, облегчающих разборку; создание мощностей для утилизации отходов.
Рис. 76. Примеры инжиниринговых решений и их последствия (Remme. Konstruktion von.
Geschaftsprozessen. 1997, с. 90)
Организация процесса
без системы запасов ("субстанция")
Инжиниринговое
решение: внедрение
системы запасов
Организация процесса
с системой запасов
Рис. 77. Последствия инжиниринговых решений (Remme, Organisationsplanung. 1997, с. 13)
Моделирование стандартов в ARIS 119
В системе SAP R/3 применяется расши-
ренный подход. На уровне бизнес-сценария
(см. рис. 74) функциональные области опре-
деляются на основе онлайновых вопросов и
ответов. Затем таким же образом задается
альтернативный процесс с «вычеркиванием»
ненужных объектов в базовой модели. Далее
по той же схеме определяются значения па-
раметров для альтернативных функций в
рамках процесса. Основные принципы этой
процедуры были включены в систему
COMET фирмы Nixdorf (Scheer. Efficient
Information Management. 1991).
В концепции CIM Analyzer и системе SAP
BE учитывается знание правил. CIM
Analyzer фиксирует контекст отношений
между конкретной деятельностью (напри-
мер, серийным производством) и необходи-
мыми функциями (например, поддержанием
материально-производственных запасов). В
системе Business Engineer условия целостно-
сти определяются на базе знания правил, а
связи между функциями (например, если ус-
таревает функция А, то устаревает и функ-
ция С) могут использоваться для упрощения
оперативного выбора.
Рэмм предлагает конструктивно-ориенти-
рованный метод создания вариантов (Remme.
Konstruktion von Geschaftspro-zessen. 1997;
Remme. Organisationsplanung. 1997; Lang.
Gestaltung von Geschaftspro-zessen. 1997), ко-
торый интегрирован в ARIS Toolset в каче-
стве прототипа. Согласно теории Рэмма,
предприятие есть результат инжиниринго-
вых решений (см. рис. 76).
Базовые функции предприятия в чистом
виде, т.е. не затронутые какими-либо инжи-
ниринговыми решениями, называются суб-
станцией. Инжиниринговые решения оказы-
вают воздействие на субстанцию. Организа-
ционные последствия определяются как
элементы общего процесса, описывающие с
точки зрения осуществляемого процесса по-
следствия инжинирингового решения для
предприятия. Вплетение этих элементов в
изначальную цепочку приводит к формиро-
ванию модели процесса, связанного с конк-
ретной прикладной областью. На рис. 77
представлено инжиниринговое решение
«внедрение системы запасов» применитель-
но к субстанции «закупки». Сначала, по ана-
логии с изготовлением изделия из предвари-
тельно собранных узлов, определяется мес-
то, которое элемент должен занять в
субстанции, а затем реализуется его связь с
субстанцией.
Таким образом, модели ARIS могут харак-
теризоваться разными типами описаний
ARIS (5 типов описаний, каждый из которых
представлен на трех уровнях), разными
уровнями моделирования (мета2-, мета-,
типы приложения, экземпляры), разной сте-
пенью структурирования и уровнем детали-
зации, а также описаниями вариантов.
Предисловие XIII
Содержание
А. \ Преимущества ARIS для пользователя 1
А.1. Преимущества для управления бизнесом и организационных процессов 2
А.2. Преимущества для пользователя при разработке информационных систем 4
Б. Базовая модель бизнес-процесса в ARIS 9
Б.1. Исходная модель бизнес-процесса 9
Б.1.1. Субъекты ответственности и их отношения 9
Б.1.2. Поток функций 9
Б.1.3. Поток выходов И
Б.1.4. Информационный поток 11
Б.1.5. Объединенная модель бизнес-процесса 14
Б.2. ARIS-модель бизнес-процесса 14
Б.2.1. Пример расширенной версии процесса 14
Б.2.2. Обобщенная модель бизнес-процесса 24
В. Разработка архитектуры интегрированных информационных систем (здание ARIS) 30
В.1. Типы моделей в ARIS 31
В.2. Фазовая модель ARIS 36
В.З. Предварительная информационная модель ARIS 40
В.4. Предварительная процедурная модель ARIS 45
Г. Управление бизнес-процессами на базе ARIS. ARIS- архитектура бизнес-инжиниринга 50
Г.1. Инжиниринг бизнес-процессов 52
Г.1.1. Моделирование продуктов и бизнес-процессов 54
Г.1.2. Модели-прототипы 56
Г.1.3. Управление знаниями 59
Г.1.4. Оценка процессов 60
Г.1.5. Эталонное сравнение процессов 63
120 Бизнес-процессы
Е. Сравнение ARIS с другими
концепциями
К моменту выхода в свет первого издания
этой книги возможности сравнения ARIS с
другими подходами были ограничены, по-
скольку существовало лишь несколько под-
робных архитектурных концепций для опи-
сания информационных систем. С тех пор ар-
хитектура информационных систем
приобрела более широкую популярность, что
нашло отражение как в теоретических дис-
куссиях, так и в практической реализации.
Эмпирические исследования в области уп-
равления информацией свидетельствуют о
признании архитектуры ИС как важного
фактора в решении реальных задач (Кгстаг.
Informationsmanagement. 1997, с. 9; Niittgens.
Коо rdin iert- dezen tra les Informa tionsma -
nagement. 1995, c. 69). Среди многообразия
методов сравнения архитектур, пожалуй,
наиболее популярен сейчас анализ метакон-
цепций.
Хотя главным достоинством ARIS являет-
ся её концепция интеграции
— архитектуры,
— различных методов и
— инструментальной поддержки,
мы коснемся и тех методов, которые фокуси-
руются лишь на одном из этих компонентов.
Однако хотелось бы еще раз подчеркнуть,
что интегрированный подход ARIS дает осо-
бые преимущества для практической реали-
зации. Это обусловлено тем, что отдельного
рассмотрения архитектур и методов без со-
ответствующей инструментальной поддерж-
ки, равно как и графической поддержки без
определенной методической концепции (в от-
ношении графических инструментов), для
внедрения в реальных условиях недостаточно.
Концепция ARIS предоставляет базовую
инфраструктуру для методов моделирова-
ния и при этом не ставновится привязанной к
какому-либо конкретному методу. Поэтому
совокупность методов в ARIS не является
чем-то раз и навсегда заданным, а продолжа-
ет расширяться и пополняться. Богатство
функциональных возможностей ARIS опре-
деляется не только тем, что она поддержива-
ет тот или иной конкретный метод. Если в
рамках её инфраструктуры можно логичес-
ки классифицировать новый метод, она по-
зволяет включить его в набор используемых
средств. Методы, вписывающиеся в ARIS
подробно рассматриваются в работе: Scheer.
ARIS ~ Business Process Modeling. 1998. Мета-
модель, представленная в данной книге, слу-
жит хорошей отправной точкой для сравне-
ния с другими методами.
Инструменты мы сравнивать здесь не бу-
дем, а просто сошлемся на имеющиеся пуб-
ликации. Кроме того, опубликован целый ряд
сравнительных исследований, проведенных
различными аналитиками рынка (Long.
Taxonomy of BPR Tools. 1992; Finkeifien,
Forschner, Hage. Werkzeuge zur Prozefianalyse.
1996). Наиболее известно, пожалуй, исследо-
вание, проведенное Gartner Group (см. рис.
78), где ARIS Toolset фигурирует под именем
производителя - IDS Prof. Scheer.
Далее сравним ARIS с другими концепциями.
Е.1. Объектно-ориентированное
моделирование
В объектно-ориентированных концепциях
термин «архитектура» используется редко,
но в связи с их растущей популярностью мы
начнем сравнение именно с них. Рассмотрим
более подробно такие характеристики объек-
тно-ориентированных подходов, как форми-
рование классов, методы инкапсуляции и ат-
рибуты, а также функции обмена сообщениями.
Объектно-ориентированные модели опи-
раются на теорию систем, которая ставит це-
лью выделение, объяснение и описание
сложных систем при помощи единообразных
стандартов. Системы состоят из множества
компонентов (подсистем и элементов), свя-
занных между собой некими отношениями.
При моделировании системы задача заклю-
чается в том, чтобы упростить рассматривав-
Сравнение ARIS с другими концепциями 121
Выборка поставщиков инструментов BPR
Претенденты Лидеры
Способность
к
реализации
Oracl^ ICL< Popkin# IBM • Sterling SoftiHre Rationi Logic Work# IDS Prof. Scheer Meta Softwar?
Software Visii banner groui Micrograf# ABC Technologic Aoni^ IntelliCd#p Holosof^ NEC • Action Technologies л Ptech# MosaixW Mega Int#. Scito^ Powersirri • Wizdom Systems • KBS I 9 Promodel CASI Softwar# • Systems Modeling • . Interfacing Technolo< CASEwise ф Ф Gensym S Hitachi Imagine The# Ф High Perfomance Sys. Proforma#
Поставщики, сменившие Данные на 8/97
направление или избравшие Поставщики концептуальных решений
отдельную нишу
------------------- Полнота видения ----------------------------------------->
Источник: Gartner Group
Рис. 78. Инструменты моделирования. (Gartner Group, 1997)
122 Бизнес-процессы
Рис. 79, Диаграмма действий и потоков объектов (UML Notation Guide. 1997, рис. 56)
Моделирование стандартов в ARIS 123
мый объект путем абстрагирования. В теории
систем мы можем разграничить структуру
системы и её поведение. Следовательно, в
объектно-ориентированном моделировании
необходимо различать методы, предназна-
ченные только для моделирования структу-
ры, и методы, предназначенные для модели-
рования как структуры, так и поведения.
При моделировании структуры первая и
главная цель состоит в формировании клас-
сов. К сторонникам этой концепции относятся
Коуд, Йордон, Рамбо, Шлаэр, Меллор (Coad/
Yourdo. Object-Oriented Analysis. 1991; Coad/
Yourdon. Object-Oriented Design. 1991;
Rumbaugh et al. Object Oriented Modeling and
Design. 1991; Shlaer/Mellor. Object Oriented
Systems Analysis. 1988).
Таким образом, центральной задачей
здесь является отыскание подходящих клас-
сов. Однако эти методы, к сожалению, не рас-
полагают специальными средствами для
формирования классов. Поэтому такие кон-
цепции нередко опираются на знания, полу-
ченные при моделировании данных, особенно
методом ERM (модель сущность-отношение).
После этапа проектирования операции (ме-
тоды) связываются с классами, а динамичес-
кое поведение описывается через обмен сооб-
щениями.
При согласовании моделей процессов с по-
ведением реальной системы ключевым мо-
ментом являются операции. Сторонники этой
концепции - Мейер, Вирфс-Брок и Джекоб-
сен (Meyer. Object-Oriented Software
Construction. 1988; Wirfs-Brock, Wilkerson,
Wiener. Objektorientiertes Software-Design.
1993; Jacobsen. Object-Oriented Software
Engineering. 1996). Хотелось бы особо отме-
тить метод Use Case, разработанный Джекоб-
сеном и группой других специалистов. Этот
метод примечателен использованием кон-
цепции UML.
Несмотря на абстрагирование от неакту-
альных свойств рассматриваемого объекта, в
объектно-ориентированном моделировании
сохраняется значительный объем семантики,
в частности при определении связей класса с
атрибутами, методами и ассоциативными от-
ношениями. Семантическое описание при-
звано сделать модель интуитивно-понятной.
С другой стороны, избыток семантики ведет к
чрезмерному усложнению больших моделей,
затрудняя их понимание даже для квалифи-
цированных пользователей. Упрощение мо-
дели предполагает отбрасывание несуще-
ственных элементов и отношений системы
путем абстрагирования.
Одним из главных недостатков объектно-
ориентированного подхода является невоз-
можность достаточно детального описания
процессов. Даже используя такие методы,
как Use Case или диаграммы взаимодей-
ствий, трудно наглядно представить ветвле-
ние процессов, организационные аспекты и
потоки выходов (Frank. Multiperspektivische
Unternehmensmodellierung. 1994, с. 136).
Диаграммы перехода состояний, так же
как диаграммы действий и потоков объектов,
во многом аналогичны диаграммам ЕРС. Это
наглядно иллюстрирует рис.79, взятый из до-
кументации по UML, на котором представле-
ны поток управления между функциями,
связь функций с организационными едини-
цами и поток обрабатываемых объектов при-
менительно к заказу в нашем
Заказ — это информационный объект. С
другой стороны, это также показатель выхо-
да, поэтому в данном случае представлен и
поток информационных услуг. Хотя в целом
подобная диаграмма охватывает все типы мо-
делей (представлений) ARIS, здесь отсут-
ствуют средства для классификации описа-
тельных элементов и расширения возможно-
стей описания в рамках отдельных моделей.
Для дополнительного сравнения на рис. 80
показана диаграмма действий и потоков
объектов применительно к исходному приме-
ру обработки заказа, приведенному на рис. 3.
Неоспоримым достоинством объектно-
ориентированного моделирования является
тесная связь моделей с реализацией. Это пре-
дельно облегчает, например, создание прото-
типов.
Концепция ARIS позволяет упростить мо-
дель не только за счет абстрагирования, но и
за счет различных типов представлений (мо-
делей), каждое из которых рассматривает
процесс в каком-то одном, определенном ра-
Бизнес-процессы
Рис. 80. Представление процесса «обработка заказа» (см. рис. 3) в виде диаграммы действий и потоков объектов
Сравнение ARIS с другими концепциями 125
Архитектура экземпляров
Архитектура прототипов
Рис. 81. Архитектура моделирования CIMOSA (куб CIMOSA) (Vernadat. Enterprise Modeling and
Integration. 1996, c. 45)
126 Бизнес-процессы
курсе. Это также позволяет внедрять очень
простые методы моделирования (например,
органиграммы), хотя обеспечить согласован-
ность разных типов представлений в рамках
одной модели затруднительно. Таким обра-
зом, чрезвычайно важную роль играют моде-
ли управления, или модели процессов, где
эти представления снова сводятся воедино.
Они позволяют классифицировать и объект-
но-ориентированную модель. Следовательно,
модели, представляющие процесс в разных
ракурсах, можно рассматривать как расши-
ренный вариант комплексного объектно-ори-
ентированного подхода.
Поскольку объектно-ориентированное мо-
делирование строго придерживается концеп-
ции системной разработки, основное внима-
ние при таком подходе сосредоточено не на
вопросах бизнеса. Архитектура ARIS, напро-
тив, изначально сфокусирована именно на
бизнес-процессы и поэтому включает такие
понятия бизнеса, как теория производства,
пооперационное исчисление стоимости и
организационные аспекты предприятия.
Модели функций, организации, данных,
выходов и управления составляют архитек-
турную концепцию, которая располагает бо-
лее богатыми семантическими возможностя-
ми, чем абстрактное описание системы, пред-
лагаемое объектно-ориентированными
моделями. Это обусловлено отсутствием в
последних инфраструктуры рабочего про-
странства, что затрудняет выявление нало-
жений или противоречий в рамках типов ди-
аграмм. Интересно отметить, что вопреки ут-
верждению, будто
объектно-ориентированная концепция пред-
ставляет собой унифицированный подход, в
ней используется порядка восьми разных ме-
тодов.
Мы ни в какой мере не хотим противопос-
тавлять ARIS объектно-ориентированному
моделированию. Напротив, при разработке
специальных систем методом объектно-ори-
ентированного моделирования целесообраз-
но использовать и различные типы представ-
лений ARIS — хотя бы в силу того, что архи-
тектура ARIS больше сфокусирована на
аспектах бизнеса, а ее представления (моде-
ли) более понятны.
Е.2. Архитектура CIMOSA
В рамках программы ESPRIT, финансиру-
емой Европейским Союзом (ЕС), осуществле-
но несколько исследовательских проектов по
разработке архитектуры открытых систем
(CIMOSA) для компьютеризованных систем
управления производством (CIM). Получен-
ные результаты опубликованы в ряде работ,
например AMICE. CIMOSA 1993; Vernadat.
Enterprise Modeling and Integration. 1996 и
другие. Первоначально в проекте CIMOSA
участвовало 30 организаций, среди которых
были производственники в качестве пользо-
вателей, разработчики ИТ и исследовательс-
кие институты. Хотя в прикладном отноше-
нии проект был ориентирован на системы
CIM, его стратегическая задача заключалась
в получении результатов для общего модели-
рования предприятий. Одной из целей
CIMOSA была разработка архитектуры и ме-
тодологии для создания систем, ориентиро-
ванных на конкретного потребителя, путем
«стыковки» стандартизованных модулей
CIM независимо от их производителей (прин-
цип «Plug and Play»); (см. Vernadat. Enterprise
Modeling and Integration 1996. c. 41).
Инфраструктура моделирования CIMO-
SA представляется в форме куба (см. рис. 81).
Архитектура CIMOSA — трехмерная.
Каждое из трех измерений представлено од-
ной из осей куба. На вертикальной оси («сту-
пенчатая деривация») представлены три
уровня описания фазовой концепции: опре-
деление требований, спецификация проекта
и описание реализации. Эти уровни в значи-
тельной мере идентичны фазам жизненного
цикла ARIS.
Горизонтальная ось («поэтапная конкре-
тизация») описывает последовательную ин-
дивидуализацию понятий. На первом этапе
определяются базовые требования (общие
требования, стандартные блоки), которые на
следующем, втором этапе конкретизируются
с учетом специфики отрасли (частные требо-
вания), а на третьем этапе дифференцируют-
ся применительно к специфике предприятия
(конкретные требования).
Сравнение ARIS с другими концепциями 127
Рис. 82. Типы моделей в архитектуре IFIP
(Olle et al. Information Systems Methodologies. 1991, c. 13)
Эта «проекция» наглядно показывает, что,
согласно концепции CIMOSA, общие стан-
дартные блоки следует использовать для оп-
ределения стандартов, после чего блоки
группируются в модели-прототипы для кон-
кретных отраслей. На последнем этапе они
используются для выработки решений, пред-
назначенных для конкретных организаций. В
инфраструктуре ARIS степень детализации
информационной модели определяется при
решении вопросов структурирования.
Непосредственно введение моделей-про-
тотипов, связанных с содержанием, наглядно
свидетельствует о том, что архитектура
CIMOSA сочетает общие положения методо-
логии информационных систем с прикладны-
ми областями CIM.
Третья ось («поэтапная генерация») опи-
сывает различные типы моделей информа-
ционной системы. Цели этой «проекции» ана-
логичны целям ARIS: речь здесь тоже идет о
создании типов описаний, хотя результаты
не во всем тождественны. В архитектуре
CIMOSA типы описания подразделяются на
«модель функций», «информационную мо-
дель», «модель ресурсов» и «организацион-
ную модель». «Модель функций» представ-
ляет собой описание событий, хотя она также
охватывает другие элементы, такие как со-
бытия и процессы, включая выполнение и об-
работку исключений (Vernadat. Enterprise
Modeling and Integration. 1996, c. 46). «Инфор-
мационная модель» относится к представле-
нию данных или описанию объектов. «Модель
ресурсов» описывает ИТ и производственные
ресурсы, а «организационная модель» —
организационную иерархию.
В архитектуре CIMOSA все содержание
также разбивается на различные типы пред-
ставлений, но здесь, в отличие от ARIS, где
имеются модели управления и модели про-
цессов, отсутствует их уровень.В результате
128 Бизнес-процессы
в CIMOSA описания разных типов комбини-
руются друг с другом. Например, при описа-
нии ресурсов одновременно выполняется их
привязка к функциям. В концепции модели-
рования CIMOSA не предусмотрена модель
выходов.
Концепция CIMOSA предоставляет адек-
ватную архитектуру для описания информа-
ционных систем, которую можно наполнять
содержанием в виде стандартизованных мо-
делей-прототипов на протяжении всего про-
цесса создания реального программного обес-
печения. Несмотря на упомянутые выше не-
достатки, у нее есть и важные достоинства.
Концепция CIMOSA позволяет классифици-
ровать методы моделирования и описывать
их метамоделями, не отступая при этом от со-
бытийной модели, ориентированной на биз-
нес-процессы. Более того, она рассматривает
предприятия как серию взаимодействующих
друг с другом агентов.
Несмотря на внушительные затраты фи-
нансовых и интеллектуальных ресурсов,
практическая отдача CIMOSA пока мини-
мальна. Судя по сообщениям пользователей
из реального бизнеса, участвующих в проек-
те, число специальных приложений, разра-
ботанных при помощи этой архитектуры,
еще крайне незначительно. Исключение со-
ставляют автомобильная компания Renault,
внедрившая прикладную систему для ремон-
тного обслуживания производственных уста-
новок, и компания TRAUB AG, внедрившая
прикладную систему для оптимизации инди-
видуальной разработки инструментов. На се-
годняшний день инструментальные средства
моделирования на базе CIMOSA не нашли
широкого практического применения.
Главная причина отсутствия успеха в сфе-
ре практической реализации, вероятно, кро-
ется в излишне теоретизированной платфор-
ме, которая не охватывает уже имеющиеся
коммерческие ИТ-решения (например, стан-
дартное программное обеспечение). Довольно
слабый интерес к концепциям CIM, похоже,
можно объяснить тем, что предельно узкая
направленность этого подхода идет ему во
вред.
Е.З. IFIP — Методология
информационных систем
Всеобъемлющая методология разработки
более традиционных информационных сис-
тем изложена в книге Olle et al. Information
Systems Methodologies. 1991. Понятие «мето-
дология» в данном случае используется в том
же значении, что и «архитектура». Семь ав-
торов этой монографии являются членами
одной из рабочих групп Международной фе-
дерации по обработке информации (IFIP) -
рабочей группы WG 8.1 по проектированию и
оценке информационных систем техническо-
го комитета ТС 8 по информационным систе-
мам. Результаты исследования подытожены
в документе «Методология информационных
систем» (ISM).
Эта методология не сужает объект иссле-
дования какими-то конкретными методами
разработки ИС. Напротив, она базируется на
широком спектре знаний, стремясь охватить
как можно больше концепций, среди которых
интерактивный метод проектирования (IDA),
методология информационного инжиниринга
(IEM), один из вариантов высокоуровневых
сетей Петри (IML), метод систем разработки
Джексона (JSD), метод информационного
анализа Нийссена (NIAM), язык постановки
задач/анализатор постановки задач (PSL/
PSA), метод структурированного анализа и
проектирования (SADT), а также метод Йор-
дона.
Эта методология использует метамодели
сущность-отношение. Ее отличительными
особенностями являются концепция и стадии
жизненного цикла информационной систе-
мы, а также разграничение моделей, ориен-
тированных на представление данных, про-
цессов и поведения (см. рис. 82). Построение
этих моделей не столько обусловлено анали-
тическими умозаключениями, сколько на-
правлено на разрешение ключевых проблем,
типичных для традиционных методов разра-
ботки ИС (Olle et al. Information Systems
Methodologies 1991. c. 12).
Типы сущностей и их атрибуты рассмат-
риваются в рамках модели данных. Модель
процессов описывает события (бизнес-функ-
ции), включая их взаимоотношения с пред-
Моделирование стандартов в ARIS 129
шественниками и преемниками. Анализ со-
бытий и их взаимоотношений с предшествен-
никами и преемниками проводится в рамках
модели поведения.
Из полной 12-этапной модели жизненного
цикла (Olle et al. Information Systems
Methodologies. 1991, c. 46) мы вычленим три
этапа: планирование информационных сис-
тем, планирование бизнеса и проектирование
систем, а затем рассмотрим два последних
более подробно ввиду их ключевой роли в ме-
тодологии.
Планирование информационных систем
относится к стратегическому планированию
информационные системы. На стадии биз-
нес-анализа исследуются существующие ин-
формационных систем всего предприятия
или какого-либо его сектора. Проектирование
соответствующей информационной системы
осуществляется на этапе проектирования си-
стем. Это понятие охватывает также всеобъ-
емлющую процедурную модель с распреде-
лением ролей в организации проекта.
Эта методология в чем-то перекликается с
ARIS, а в чем-то с ней расходится. Общим для
обеих концепций является двумерное пред-
ставление, охватывающее типы моделей и
этапы разработки. Однако их конкретные
формы различаются. Например, Олле и его
соавторы не вычленяют явным образом орга-
низационную модель, а рассматривают ее
(хотя и рудиментарно) наряду с другими
функциями. Описание процессов более или
менее согласуется с описанием функций в
ARIS. Данные, функции и события также
строго разделяются. Связка этих трех моде-
лей лишь отдаленно напоминает модель уп-
равления ARIS. Этап проектирования систе-
мы объединяет разграничиваемые в ARIS
фазы определения требований и специфика-
ции проекта с акцентом на последней.
Главное отличие модели IFIP от модели
ARIS заключается в том, что в ней отсутствуют:
— модели выходов,
— организационная модель,
— фаза реализации,
— систематизированная модель управления.
Е.4. Инфраструктура Захмана
Весьма популярный в США метод описа-
ния предприятий был разработан Дж. А. Зах-
маном (Zachman. Framework for Information
Systems Architecture. 1987; Sowa, Zachman.
Extending and Formalizing the Framework for
Information Systems Architecture. 1992;
Burgess, Hokel. Brief Introduction to the
Zachman Framework. 1994). Захман взял за
основу архитектуру информационных сис-
тем (ISA) фирмы IBM, расширив ее и допол-
нив. Эта концепция неоднократно излагалась
им в лекциях и на семинарах.
Инфраструктура Захмана (см. рис. 83)
включает 6 перспектив и 6 блоков описания. В
терминологии ARIS блоки описания Захмана
соответствуют типам представлений (моде-
лей), а перспективы — уровням модели жиз-
ненного цикла.
Перспективы перечислены в скобках вме-
сте с описаниями роли участников: масштаб
(планировщик), корпоративная модель (вла-
делец), системная модель (проектировщик),
технологическая модель (построитель), ком-
поненты (субподрядчик) и функционирую-
щая система (пользователь).
Исследуемые области обозначены вопро-
сительными словами, а соответствующие
действия указаны в скобках: что (данные),
как (функция), где (сеть), кто (люди), когда
(время) и почему (логическое обоснование).
Исследуемые перспективы и файлы распо-
лагаются под прямым углом друг к другу.
Каждое поле в матрице описывается по опре-
деленной методике.
Инфраструктуру Захмана, в противопо-
ложность ARIS, невозможно напрямую вне-
дрить в информационную систему, а ввод от-
ношений между полями описания не систе-
матизирован. К тому же, связь
инфраструктуры Захмана с конкретным со-
зданием выхода в рамках бизнес-процесса не
очевидна.
Благодаря сотрудничеству с фирмой
Framework Software, Inc. (шт. Калифорния) в
настоящее время отмечаются первые попыт-
ки создания вспомогательных инструментов.
ФОКУС
п
Е
Р
С
П
Е
К
Т
И
В
А
Общая инфраструктура Элемент Связь Элемент ЧТО (Данные) Сущность Отношение Сущность КАК (Функция) Процесс Вход-Выход Процесс ГДЕ (Сеть) Узел Линия Узел КТО (Люди) Агент Работа Агент КОГДА (Время) Событие Цикл Событие ПОЧЕМУ (Логическое обоснование) Конец Означает Конец
МАСШТАБ (Планировщик) Список сущностей Список процессов Список узлов Список организаций Список основных событий Список целей
КОРПОРАТИВНАЯ МОДЕЛЬ (Владелец) Корпоративный субъект Корпоративное правило Корпоративный субъект Корпоративный процесс Ресурс Корпоративный процесс Корпоративный микрорайон Корпоративный канал Корпоративный микрорайон Организация Работа Организация Корпоративное событие Корпоративный цикл Корпоративное событие Цель Стратегия Цель
СИСТЕМНАЯ МОДЕЛЬ (Проектировщик) Тип сущности Тип отношения Тип сущности Системный процесс Пользовательское описание Системный процесс Узел Канал связи Узел Роль Представление Роль Системное событие Системный цикл Системное событие Критерий Выбор Критерий
ТЕХНОЛОГИЧЕСКАЯ МОДЕЛЬ (Исполнитель) ?? Структура данных Целостность на уровне ссылок Структура данных Приложение Аппаратный формат Приложение Точка соединения Коммуникационная линия Точка соединения Пользователь Технический интерфейс Пользователь Техническое событие Технический цикл Техническое событие Состояние Действие Состояние
КОМПОНЕНТЫ (Субподрядчик) Контейнер данных Сбор Контейнер данных Модуль/Объект Связь/Сообщение Модуль/Объект Адрес Протокол Адрес Индивидуум Транзакция Индивидуум Компонентное событие Компонентный цикл Компонентное событие Подсостояние Шаг/Задача Подсостояние
ФУНКЦИОНИРУЮЩАЯ СИСТЕМА (Пользователь) Информация Целостность Информация Процедура Запрос Процедура Клиент-сервер Доступ Клиент-сервер Работник Сеанс работы Работник Операционное событие Операционный цикл Операционное событие Цель Вариант Цель
Бизнес-процессы
Рис. 83. Архитектура Захмана (Burgess/Hokel. Brief Introduction to the Zachman Framework 1994. c. 26)
Сравнение ARIS с другими концепциями 131
Рис. 84. Процедурная модель для объектного моделирования методом SOM (Ferstl, Sinz.
Wirtschaftsinformatik. 1993, с. 137)
Е.5. Результаты исследований
Санкт-Г алленского
университета, Швейцария
Ряд концепций описания информацион-
ных систем разработан в исследовательских
проектах Санкт-Галленского университета
(Швейцария). Спектр исследований широк —
от процедурных моделей и метамоделей до
описания методов, от метода проектирования
бизнес-процессов (PROMET) до сравнения
различных методов и инструментов модели-
рования. Хотя конкретных рекомендаций по
созданию архитектуры здесь не приводится,
можно построить инфраструктуру, опираясь
на определение требований для оценки раз-
личных методов реинжиниринга бизнес-про-
цессов. Поскольку классификация методов
основана именно на определении требований,
она описывается, если можно так выразить-
ся, на «более высоком логическом уровне»,
соответствующем уровню ARIS (Bach, Brecht,
Hess, Osterle. Enabling Systematic Business
Change. 1996, c. 38; Osterle, Bremer, Hilbers.
Unternehmensfuhrung und Informations-
system. 1992; Gutzwiller, Osterle. Referenz-Meta-
Modell Analyse. 1990; Osterle. Business
Engineering 1.1995, c. 31).
Различаются «методические компоненты»
и «проектные компоненты». Методические
компоненты относятся к процедурной модели
для реинжиниринговых проектов и подраз-
деляются на следующие категории: функ-
ции, организационная ролевая концепция,
описываемые результаты и методики. Про-
ектные компоненты соответствуют «типам
представления» и подразделяются на следу-
ющие категории: потоки работ, результаты
(выходы) процессов, управление процессами,
информационная система, организационная
структура и организационная (корпоратив-
ная) культура.
Этот подход в равной мере акцентирует
внимание на процедурной модели и на иско-
мых результатах. В противоположность
ARIS, где модель бизнес-процессов изна-
чально вводится как ключевой элемент для
создания различных типов представлений
132 Бизнес-процессы
Рис. 85. Концепция АИС, представленная в виде «волчка» (Krcmar. Informationssystem -
Architekturen.1990, с. 399)
(моделей), описание конкретных проектных
компонент не опирается на какую-либо базо-
вую модель. В инфраструктуре ARIS выход
процесса описывается в модели выходов.
Процедурная модель ARIS в основном адре-
сована «методическим компонентам». В кон-
цепции ARIS АБИ существует тесная интег-
рация между самой концепцией и описания-
ми " потоков работ, с одной стороны, и
внедрением бизнес-процессов в информаци-
онные системы, с другой. В инфраструктуре
ARIS вопросы организационной культуры
рассматриваются на уровне стратегического
планирования.
Отсутствие в исследованиях Санкт-Гал-
ленского университета четко выраженной
архитектурной концепции становится оче-
видным, если соединить линиями объекты
ERM «проектной области», составляющие
единую группу, с метамоделями. В информа-
ционной модели ARIS, напротив, типы пред-
ставлений для классификации моделируе-
мых объектов определяются с самого начала.
Сравнение ARIS с другими концепциями 133
Е.6. Другие архитектурные
решения
Приведенный здесь перечень охватывает
лишь часть широкого спектра архитектур.
Концепция AD/CYCLE, представленная
компанией IBM и описанная в первом изда-
нии этой книги, не оправдала ожиданий, хотя
почерпнутые из нее знания были использова-
ны при создании следующего продукта —
AIX/CASE. Не оправдали ожиданий и многие
концепции, предложенные консалтинговыми
фирмами, поризводителями программного
обеспечения и аппаратных средств, в том
числе, концепция информационного инжини-
ринга (IEM), выдвинутая Джеймсом Марти-
ном (Martin. Information Engineering И. 1990).
Сейчас Microsoft и ряд других поставщи-
ков программного обеспечения предлагают
репозиторий Microsoft (MR), принцип кото-
рого аналогичен AD/CYCLE. Репозиторий
MR представляет собой базу данных для хра-
нения компонентов, моделей и объектов на-
ряду с их описаниями и отношениями, обес-
печивающую многократное использование и
инструментальную поддержку. Очевидно,
MR основан на открытой метамодели (в соот-
ветствии с методом UML) и взаимодействует
с другими репозиториями (Linthicum.
Microsoft Repository. 1997). Несмотря на то,
что к этому продукту можно предъявить не-
которые претензии, MR имеет больше шан-
сов на успех, чем AD/CYCLE.
Ферстль и Зинц, разработавшие концеп-
цию семантической объектной модели (SOM;
см. Ferstl, Sinz. Vorgehensmodell zur
Objektmodellierung. 1993), предложили про-
цедурную модель с систематизированной
структурой типов описания в виде списка ре-
зультатов процедурной модели. Структура и
поведение системы описываются в рамках
модели SOM (см. рис. 84). Кроме того, треху-
ровневая концепция создает основу для дета-
лизации. Осуществляется также постоянная
координация уровней между моделью струк-
туры и моделью поведения.
Эта модель расширяется более детализи-
рованными методами и описаниями экземп-
ляров (Ferstl, Sinz. Wirtschaftsinformatik.
1994). Имеется прототип инструментальной
системы моделирования. В отличие от ARIS
эта концепция привязана к определенному
методу проектирования, а именно — к объек-
тно-ориентированному. Она не предусматри-
вает отдельного описания организационной
модели и модели выходов.
«Архитектура информационных систем»
Крцмара (АИС) (ISA; см. Кгстаг.
Informationssystem-Architekturen. 1990) изоб-
ражается в виде «волчка» (см. рис. 85). Это оз-
начает, что при отсутствии хотя бы части
описания структура полностью утрачивает
работоспособность. Концепция АИС акцен-
тирует внимание на связи между архи текту-
рой и корпоративной стратегией, что на ри-
сунке показано вертикальной стрелкой. На
сегодняшний день это предложение пока не
нашло практического воплощения.
О других архитектурных концепциях
можно прочесть в работах: Williams. Purdue
Enterprise Reference Architecture. 1991;
Vernadat., Enterprise Modeling and Integration.
1996; Sinz. Modellierung betrieblicher Infor-
mationssysteme. 1996; Niittgens. Koordiniert-
dezentrales Informationsmanagement. 1995;
Oberweis. Modellierung von Workflows. 1996;
Donovan. Business Reengineering. 1994; Chen,
Doumeingts. GRAI-CIM. 1996; Bach, Brecht,
Hess, Osterle. Enabling Systematic Business
Change. 1996; Krcmar. Informations-
management. 1997.
134 Бизнес-процессы
Предприятие
( I 1 i
Персонал
НИОКР Продажа и Произ-
и маркетинг водство
Рис. 86. Переориентация с функций на процессы
Внедрение ARIS — практические процедуры 135
Ж. Внедрение ARIS —
практические процедуры
В этом разеделе мы покажем как можно
практически использовать модели ARIS с
максимальной отдачей. Будет рассмотрено
также применение модели ARIS, соответ-
ствующей уровню I «здания» бизнес-инжи-
ниринга, на конкретных примерах, включающих:
— реинжиниринг бизнес-процессов,
— сертификацию качества по стандарту
ISO 9000,
- — управление знаниями.
Авторы располагают практическим опы-
том в этих областях.
Дополнительные сведения об эффектив-
ном внедрении ARIS в таких областях, как
— реализация стандартных приложений
(SAP/R/3),
— реализация систем workflow,
- — создание приложений с помощью АБИ,
— моделирование с помощью UML,
содержатся в работе: Scheer. ARIS -
Business Process Modeling. 1998.
Ж.1. Реинжиниринг бизнес-
процессов на базе модели
ARIS
Ральф Хайб, Dipl.-Kfm., фирма IDS Prof.
Scheer GmbH, Саарбрюккен, Германия.
Ж. 1.1. Корпоративный
инжиниринг,
ориентированный на
процессы
Прежние методы реорганизации бизнес-
процессов тяготели к радикально новому ин-
жинирингу процессов безотносительно к су-
ществующим структурам (Hammer, Champy.
Business Reengineering. 1995). При других
подходах акцент делался на необходимости в
поэтапном и непрерывном совершенствова-
нии процессов (Harrington. Business Process
Improvement. 1991). Общее между этими ме-
тодами заключается в высоком приоритете
ИТ как инструментария для изменения про-
цессов. Среди множества возможных спосо-
бов оптимизации, имеюющих разную степень
сложности, всё более важное значение при-
обретают добротные процедуры и внедрение
соответствующих методов и инструментов.
В этой книге мы рассматриваем инфра-
структуру для оптимизации бизнес-процес-
сов при помощи процедурной модели ARIS,
позволяющей их перестраивать и постоянно
совершенствовать. В основе процедурных
моделей лежит циклический принцип. Новые
бизнес-процессы определяются в результате
анализа существующих структур (см.
рис. 86), реализуются современными сред-
ствами ИТ, а затем регулярно пересматрива-
ются и модифицируются.
Метод ARIS позволяет разработать все-
объемлющие систематизированные описа-
ния бизнес-процессов, реализовать их в виде
решений ИТ и исследовать различные аспекты
бизнес-процессов, такие как организацион-
ная структура, структура функций и данных,
обеспечивая последующую интеграцию этих
аспектов при помощи моделей процессов.
Стандартизованные методы моделирования
повышают прозрачность, позволяют сравни-
вать результаты проектов и создают единую
платформу для обсуждения корпоративных
процессов на разных уровнях иерархии (ру-
ководство, менеджеры различных направле-
ний деятельности, специалисты в области
организационного развития и ИТ).
Одним из ключевых достоинств концепции
ARIS является ее тесная интеграция с ARIS
Toolset, повышающая эффективность реин-
жиниринговых проектов и обеспечивающая
многократное использование полученных ре-
зультатов.
136 Бизнес-процессы
Подготовительные
меры
Стратегическое
планирование
Анализ
как есть'
Целевая
концепция
Спецификация
проекта
Реализация
(описание)
Регулярный
мониторинг
производительности
Рис. 87. Процедурная модель для оптимизации бизнес-процессов
Ж. 1.2. Процедурная модель для
оптимизации бизнес-
процессов
Представленная здесь процедурная мо-
дель базируется на опыте фирмы IDS Prof.
Scheer GmbH, приобретенном в результате
реализации целого ряда проектов по оптими-
зации бизнес-процессов (ОБП). Эту модель
можно использовать в качестве контрольной
схемы и нормативного руководства при вы-
полнении проектов ОБП. Модель-прототип
документально представлена в ARIS Toolset
в соответствии с методами ARIS, что позво-
ляет адаптировать ее к конкретной ситуа-
ции. Отдельные решения в рамках проекта
можно использовать как «базу умений и на-
выков» при реализации последующих проектов.
Основные фазы проекта описываются ди-
аграммой цепочки добавленной стоимости
(см. рис. 87). Функции и процессы, предусмот-
ренные проектом, дополнительно описыва-
ются диаграммами ЕРС (событийные диаг-
раммы процессов), которые расширяются
Внедрение ARIS — практические процедуры 137
Рис. 88. Диаграмма ЕРС для бизнес-процесса «обработка заказа клиента»
при помощи органиграмм (представляющих
примерную организацию проекта) и моделей
данных (иллюстрирующих результаты проекта).
Ж. 1.3. Фазы оптимизации бизнес-
процессов
Ж.1.3.1. Подготовительные меры
. На подготовительном этапе намечаются
общие контуры проекта: формулируются
цели, определяются необходимые процеду-
ры и вносятся соответствующие изменения в
организацию проекта. Одним из важнейших
факторов успеха при реализации проекта
ОБП является умелая организация. Следует
создать специальный комитет, который бу-
дет направлять работу над проектом. Обычно
результаты проекта систематически оцени-
ваются, а затем подытоживаются проектной
группой, сотрудничающей с отделом ИС или
соответствующим организационным подраз-
делением. Иногда на этом этапе привлекают
консультантов со стороны. Конкретные ис-
полнители отдельных процессов и члены
проектной группы объединяют усилия, на-
правленные на достижение определенных
результатов в сфере бизнеса.
Исходя из целей проекта, методы его опи-
сания документально оформляются в виде
руководства, которое служит основой для
обучения персонала, занимающегося внедре-
нием проекта. Затем проводится презента-
ция для ознакомления с проектом других со-
трудников.
Ж. 1.3.2. Стратегическое
планирование
Оптимизация бизнес-процессов начинает-
ся с определения стратегических установок
предприятия. Бизнес-процессы следует
строить таким образом, чтобы они способ-
ствовали достижению стратегических корпо-
ративных целей.
Для определения стратегических устано-
вок могут использоваться модели продуктов
и выходов, а также целевые диаграммы, ох-
ватывающие ключевые секторы деятельное-
138 Бизнес-процессы
ти предприятия в совокупности с производи-
мыми продуктами, предоставляемыми услу-
гами и категориями клиентов. Моделируются
критические факторы успеха и иерархия
корпоративных целей. Проводится анализ
стратегических установок с конкретизацией
целей ОБП. Цели могут носить как количе-
ственный (повышение производительности,
сокращение издержек и времени цикла вы-
полнения), так и качественный характер (по-
вышение качества продукции, гибкости или
качества обслуживания). Цели проекта пред-
ставляются в виде целевой диаграммы.
Ж.1.3.3. Анализ «как есть»
Анализ «как есть» начинается с «инвента-
ризации» бизнес-процессов. Создается опи-
сание инфраструктуры, где основные бизнес-
процессы представляются в виде цепочек до-
бавленной стоимости. Это представление
служит основой для более подробного описа-
ния процессов с помощью событийных диаг-
рамм процессов ЕРС (см. рис. 88). В дополне-
ние к этому существующая иерархическая
организация представляется в виде органиг-
рамм, важнейшие информационные объекты
— в виде диаграмм бизнес-терминов, а суще-
ствующие прикладные системы — в виде ди-
аграмм прикладных систем.
Моделирование бизнес-процессов обеспе-
чивает прозрачность, выявляя таким обра-
зом их слабые места и потенциальные воз-
можности оптимизации. Текущие бизнес-
процессы оцениваются с точки зрения их
соответствия целям ОБП. Критериями оцен-
ки бизнес-процессов, позволяющие опреде-
лить возможные области оптимизации, слу-
жат время цикла выполнения процесса (вре-
мя обработки, периоды отладки, задержки,
время транспортировки), стоимость процес-
са, организационное наполнение (количество
субъектов ответственности, участвующих в
процессе), системное наполнение (количество
информационных систем, участвующих в
процессе), динамика среды (количество пере-
ходов с компьютеризованной обработки на
ручную и наоборот), избыточность данных и
наличие узких мест при выполнении отдель-
ных операций.
Оценка бизнес-процессов и моделиро!
ние потенциальных возможностей их от
мизации являются ключевыми момента
целевой концепции реинжиниринга.
Ж. 1.3.4. Целевая концепция
В целевой концепции описываются ал
тернативные варианты целевых процессе
Описание начинается с анализа слабых ме>
в существующих бизнес-процессах. При из
жиниринге бизнес-процессов можно таки
обращаться к моделям-прототипам, соде{
жащим процессы и организационные струг
туры, типичные для различных вертикалг
ных рынков. Модели-прототипы основаны н
опыте и знаниях, приобретенных в результа
те реализации аналогичных проектов. Ис
пользование моделей-прототипов позволяв
ускорить проектирование целевых процессе:
за счет заимствования больших фрагменте!
структур-прототипов. При этом высвобожда-
ются ресурсы, которые можно сосредоточит!
на других участках корпоративных процес-
сов.
Разработанные целевые процессы оцени-
ваются с точки зрения их соответствия по-
ставленным целям. Инструменты имитаци-
онного моделирования и пооперационного ис-
числения стоимости, предлагаемые ARIS
Toolset, облегчают такую оценку, показывая
как изменения в бизнес-процессе влияют нг
стоимость процесса, его производительность
степень использования машинных pecypcoi
и т.д. Таким образом, можно моделироватг
различные гипотетические сценарии («чт<
если»).
Затем на основании новых целевых про-
цессов строится органиграмма соответствую-
щей организационной иерархии. Следуег
также определить организационные меры п<
обеспечению новых целевых процессов. Е
комплексе таких мер может входить плани-
рование будущих потребностей в людски?
ресурсах или установление необходимы;
квалификационных требований.
Внедрение ARIS — практические процедуры 139
I. Управление
II. Рабочий процесс
системой QM
III. Вспомогательные
функции
Рис. 89. Элементы ISO 9001 (из работы IM Magazin Qualitat 1996, с. 66)
Ж. 1.3.5. Спецификация проекта
Фаза спецификации проекта связана с
планированием внедрения целевых бизнес-
процессов средствами новейших достижений
ИТ. Вначале определяются приложения, ко-
торые планируется внедрить на каждом уча-
стке отдельного процесса. Это могут быть
специализированные решения, стандартные
приложения, системы класса workflow, сис-
темы управления коллективной работой и
электронными документами, приложения
для работы в Интернете. Выбор приложений
зависит от требований бизнеса, сформулиро-
ванных в целевой концепции и подкреплен-
ных оценками прибыльности, а также от того,
насколько эффективно данное приложение
можно интегрировать в корпоративную инф-
раструктуру ИТ. Спецификация проекта
увязывает бизнес-процессы, прикладные си-
стемы и инфраструктуру ИТ в единое целое.
После составления спецификаций разра-
батывается план реализации и поэтапного
перехода. Этот план служит основой для вне-
дрения бизнес-процессов. Он определяет
стратегию реализации для различных участ-
ков, устанавливает сроки выполнения конк-
ретных подпроектов и объем неоходимых для
них ресурсов.
Ж. 1.3.6. Реализация
Этап реализации предполагает внедрение
решений ИТ на различных участках. На этом
этапе параллельно осуществляется ряд под-
проектов, в ходе которых ранее определен-
ные целевые процессы подвергаются даль-
нейшей детализации, а затем внедряются в
информационные системы. Создание прото-
типов программного обеспечения позволяет
заблаговременно выяснить, насколько удач-
но процессы вписываются в соответствую-
щие программные решения. Это помогает за-
ручиться одобрением пользователей этих си-
стем на протяжении всего проекта и
повысить их психологическую готовность к
принятию нововведений.
140 Бизнес-процессы
Ж.1.3.7. Регулярный мониторинг и
непрерывное
совершенствование
процессов
Вслед за реализацией бизнес-процессов и
внедрение информационных систем наступа-
ет фаза контроля и оптимизации. Теперь це-
левые процессы и ИС вновь рассматриваются
и анализируются с точки зрения соответ-
ствия целям ОБП. Источником базовых дан-
ных для их оценки могут служить непосред-
ственно информационные системы (напри-
мер, системы workflow, предоставляющие
результаты анализа производительности,
данные о стоимости поддерживаемых про-
цессов и о степени использования машинных
ресурсов).
Регулярный мониторинг производитель-
ности позволяет намечать меры по адаптации
бизнес-процессов и соответствующих про-
граммных решений к конкретным ситуациям.
При этом постоянно предпологается непре-
рывное совершенствование процессов.
Ж. 1.4. Резюме
Несмотря на большое разнообразие воз-
можных способов оптимизации бизнес-про-
цессов, ключевую роль в проектах ОБП игра-
ют хорошо отработанные процедуры и при-
менение соответствующих методов и
инструментальных средств. Процедурная
модель ARIS для оптимизации бизнес-про-
цессов, основанная на фундаментальной ме-
тодической концепции, широко апробирова-
на на практике. Согласованность процедур,
методов и инструментальной поддержки по-
зволяет с успехом использовать ее для реин-
жиниринга и адаптации бизнес-процессов.
Процедурная модель ARIS является также
ключом к ускорению реализации проекта,
повышению качества его результатов. Ее
функциональные возможности в области
поддержки методов и инструментов обеспе-
чивают дополнительные преимущества в
виде снижения стоимости проекта. Корпора-
тивная база знаний, созданная с помощью мо-
дели ARIS, позволет предприятиям решать
новые сложные задачи.
Ж.2. Сертификация соответствия
стандарту ISO 9000 на базе
модели ARIS
Д-р Клаус Хеллинг, фирма IDS Prof
Scheer GmbH, Саарбрюккен, Германия.
Ж.2.1. Управление качеством (УК)
на базе ARIS с
ориентацией на процессы
Сегодня каждая компания, занимающаяся
проблемами управления качеством, должна
быть знакома со стандартами DIN EN ISO
900х (далее — ISO 900х). Системы управле-
ния качеством (УК) включают организацион-
ную структуру, субъекты ответственности,
процедуры, процессы и средства, необходи-
мые для управления качеством. Структура
реальных систем УК, как правило, содержит
20 элементов, составляющих стандарт ISO
9001. Эти элементы представлены на рис. 89.
К сожалению, большинству пользователей
трудно разобраться в столь сложных систе-
мах, поскольку для каждой функции необхо-
димо учитывать множество требований к
различным элементам. В связи с этим идея
внедрения системы УК вряд ли у кого-то мо-
жет вызвать энтузиазм.
Современные стратегии требуют, чтобы
концепция управления качеством была на-
правлена на бизнес-процессы. Ориентация
на процессы облегчает участие сотрудников в
создании системы УК, поскольку в этом слу-
чае они имеют имеют дело с описанием обыч-
ных, повседневных задач и нет необходимос-
ти в абстрактном языке стандарта. Привле-
чение персонала к созданию и обновлению
процедур и правил эксплуатации имеет пер-
востепенное значение. Это повышает психо-
логическую готовность сотрудников к приня-
тию новой системы УК и позволяет эффек-
тивнее использовать их творческий
потенциал в непрерывном совершенствова-
нии и расширении системы УК.
ARIS Toolset отвечает современным тре-
бованиям, позволяя анализировать, модели-
ровать и оптимизировать процессы, обеспе-
чивающие высокое качество. Это идеальный
инструмент для эффективной разработки си-
стем УК, ориентированных на процессы, и
для сертификации по стандарту ISO 900х.
Внедрение ARIS — практические процедуры 141
-------t-------
Фаза подготовки
к QM
----*-------
Анализ QM
"как есть"
Требуется
новая целевая
концепция
ISO 9000
на базе ARIS
Целевая
концепция
Требуется
концепция
реализации
-----X------
Создание
документации
QM
----1------
Применение
и пересмотр
системы QM
Рис. 90. Предварительная процедурная модель ARIS для сертификации ISO
142 Бизнес-процессы
Стратегическое
планирование
Фаза подготовки
к QM
Анализ QM
"как есть"
ISO 9000
на базе ARIS:
целевая концепция
□ Определить стратегические
цели
□ Проанализировать
корпоративную среду
□ Изучить стратегические
направления бизнеса
□ Выработать стратегию
сертификации и ТОМ
□ Проинформировать персонал
о ISO 900х и ТОМ
□ Назначить руководителя
проекта QM
□ Определить политику
по качеству
□ Обучить персонал
и создать мотивации
□ Рассмотреть имеющиеся
документы QM
0 Рассортировать документы
QM согласно стандарту
а Оценить систему QM
□ Определить необходимость
□ Провести обучение
"ISO 9000 на базе ARIS"
□ Описать соглашения
по системе QM
а Описать отчеты ISO 9000
□ Связать процессы QM
с элементами QM
Конструирование
системы QM
Применение
и пересмотр
системы QM
Сертификация
системы QM
TQM '
(Полное управление
качеством) .
□ Смоделировать
организационную структуру
□ Оценить процессы ОМ
□ Выработать операции
и порядок процедур
□ Создать руководство по QM
□ Обучить весь персонал
системе QM
□ Выполнить процессы
в соответствии с системой
° Провести внутренние
ревизии
о Активизировать процесс
усовершенствования
а Провести внешнюю ревизию
□ Активизировать процесс
ревизию
□ Внедрить маркетинговую
концепцию для сертификата
а Определить концепцию ТОМ
Определить цели и меры
□ Выбрать и применить
процедуру ТОМ
□ Активизировать процесс
усовершенствования
Рис. 91. Фазы процедурной модели, представленные в виде диаграммы цепочки добавленной
стоимости
Кроме того, ARIS Toolset поддерживает
структуру интегрированных систем управ-
ления, соответствующим нескольким стан-
дартам, например, ISO 9000, QS 9000, VDA
Bd. 6, ISO 14000, EMAS и т.д. (Helling,
Herrmann. Anderungen flexibel meistern. 1997).
Фокусировка на главных бизнес-процессах
позволяет наглядно представлять, докумен-
тировать и совершенствовать их содержание
в различных аспектах систем качества, инф-
раструктуры и управления безопасностью.
Ж.2.2. Процедурная модель для
сертификации ISO
Ж.2.2.1. Процедурная модель: общее
описание
При проектировании систем управления
качеством крайне важно привлечь к участию
каждое подразделение и каждого сотрудни-
ка. В зависимости от масштабов компании и
практикуемых в ней методов управления ка-
чеством на проектирование этих систем тре-
буется от 6 до 18 месяцев. Основные этапы
проекта сертификации представлены в про-
цедурной модели для сертификации ISO (см.
рис. 90). Рассмотрим подробнее этапы вне-
дрения стстемы качества с помощью ARIS
Toolset.
Ж.2.2.2. Процедурная модель:
преимущества
Процедурные модели охватывают всю со-
вокупность процессов-прототипов, описывая
в базе данных ARIS каждый этап — от стра-
тегического планирования до получения сер-
тификата ISO. Процедурные модели объеди-
няют умения и навыки, требующиеся для со-
здания документации УК, ориентированной
на процессы, с практическими инструкциями
по внедрению ARIS Toolset. Добавляя или ис-
ключая отдельные этапы и выделяя конкрет-
ным этапам необходимые ресурсы, по своему
усмотрению ARIS Toolset можно адаптиро-
вать к корпоративным требованиям. Связав
ARIS Toolset с какой-либо системой управле-
ния проектами, планы, относящиеся к проек-
ту можно разрабатывать непосредственно на
Внедрение ARIS - практические процедуры 143
Рис. 92. Модели ARIS для управления качеством
базе процедурной модели. Процедурные мо-
дели отражают знания и опыт, приобретен-
ные в ходе множества консалтинговых про-
ектов, и служат надежным руководством для
сертификации систем УК и системного уп-
равления качеством (TQM).
Ж.2.3. Фазы процедурной
модели
Процедурная модель состоит из восьми ос-
новных фаз, представленных на рис. 90 в виде
диаграммы ЕРС, а на рис. 91 — в виде диаг-
раммы цепочки добавленной стоимости.
Каждая фаза процедурной модели описыва-
ется подробной диаграммой ЕРС. У функций,
для которых имеется более детальное описа-
ние в виде другой диаграммы ЕРС, верхняя
граница отмечена точкой. Кроме того, каждая
функция процесса имеет более подробное
словесное описание, включая данные о входе
и выходе, а также о внутренних и внешних
людских ресурсах. На уровне 3 каждая функ-
ция, требующая использования ARIS Toolset,
дополняется еще одной диаграммой ЕРС,
описывающей, какие методы и функции
ARIS Toolset необходимы для выполнения
данной задачи.
Ж.2.3.1. Стратегическое
планирование
На этапе стратегического планирования
задача состоит в том, чтобы определить сово-
купность актуальных стратегических (долго-
срочных) корпоративных целей. Эти цели оп-
ределяются после анализа стратегических
участков деятельности предприятия и кор-
поративной среды. Исходя из стратегических
целей намечаются меры по их достижению.
Крайне важно, чтобы руководство рассмат-
ривало создание системы управления каче-
ством как стратегическую задачу. Таким об-
разом, ARIS Toolset внедряется как страте-
гический инструмент для документирования
и непрерывного совершенствования каждого
корпоративного процесса.
144 Бизнес-процессы
Ж.2.3.2. Фаза подготовки к
управлению качеством
На подготовительной фазе обычно предпо-
лагается проведение одного или нескольких
семинаров, где различные аспекты сертифи-
кации ISO 900х оцениваются с учетом специ-
фики компании, выработка предварительной
концепции сертификации, назначение руко-
водителя проекта по УК и определение кор-
поративной политики по вопросам качества.
Руководитель проекта УК является предста-
вителем администрации, отвечающим за вне-
дрение системы УК. Он должен иметь доступ
к высшему руководству и быть независимым
в своих действиях от линейных руководите-
лей. К определению общих принципов поли-
тики по качеству при необходимости можно
привлекать консультантов со стороны. Одна-
ко конкретные формулировки и обязатель-
ства, тоджественные задачам в области каче-
ства, должны исходить от самой компании.
Соответствующие стратегии следует довести
до сведения всех сотрудников. Необходимо
позаботиться и о том, чтобы задачи, относя-
щиеся к управлению качеством получили
единодушную и безоговорочную поддержку
персонала.
На подготовительной фазе намечаются
предварительные процедуры и основы уп-
равления проектом. Таким образом, проце-
дурную модель ARIS можно модифициро-
вать в соответствии с требованиями серти-
фикации ISO 9000.
Ж.2.3.3. Анализ системы управления
качеством «как есть»
Каждое предприятие имеет структуры,
правила и документы, которые составляют
основу для исправного функционирования
корпоративных процедур и должны быть ин-
тегрированы с новой системой УК. Анализ
«как есть» предполагает исследование вне-
дряемого стандарта (ISO 9001, 9002 или 9003)
с учетом специфики компании. Цель такого
анализа — выяснение требований стандарта
и в какой мере они затрагивают конкретные
аспекты деятельности компании. На этом же
этапе в рамках компании проводится инвен-
таризация документов и информационных
систем (ИС), имеющих отношение к качеству.
Для того чтобы наметить дальнейшие дей-
ствия, необходимо ответить на следующие
вопросы:
— какие существующие процессы можнс
использовать для создания документа-
ции, отвечающей стандарту ISO 900х?
— какие процессы необходимо реоргани-
зовать?
— какие дополнительные процессы следу-
ет описать?
Ж.2.3.4 «ISO 9000 на базе ARIS»:
целевая концепция
Методы, используемые ARIS Toolset, до-
кументально оформляются в виде руковод-
ства по стандартам, которое содержит общее
описание основных типов моделей, типов
объектов, символов и границ. При создании
системы УК важнейшее значение имеют сле-
дующие типы моделей ARIS на уровне опре-
деления требований:
— органиграммы,
— диаграммы цепочки добавленной сто-
имости,
— диаграммы ЕРС.
Можно также использовать модели биз-
нес-терминов, диаграммы информационной
среды, деревья узлов, диаграммы информа-
ционных потоков, матрицы выбора процес-
сов, событийные диаграммы и диаграммы
описания функций. Сотрудники, которым
предстоит оперировать инструментами и ме-
тодами ARIS, должны, безусловно, пройти
соответствующее обучение.
Предварительная архитектура процессов
тоже описывается на стадии выработки целе-
вой концепции. Связав идентифицированные
процессы с элементами УК, можно получить
общее представление о соответствии этих
процессов требованиям стандарта.
Внедрение ARIS — практические процедуры 145
Ж.2.3.5. Структурирование системы УК
Документирование процессов структури-
руется с учётом с архитектуры процессов
данного предприятия, при этом процессы мо-
делируются по принципу «сверху-вниз» с по-
мощью диаграмм цепочек добавленной сто-
имости. Цепочки добавленной стоимости раз-
биваются на отдельные процессы,
распределяющиеся по нескольким уровням
(см. рис. 92). Затем эти процессы представля-
ются в виде диаграмм ЕРС. Инструментарий
ARIS Toolset позволяет добавлять к каждой
функции ЕРС текстовое описание. Если в
дальнейшем потребуется количественный
анализ процессов, то можно ввести такие по-
казатели, как время и стоимость обработки.
Для каждой функции, т.е. на каждом этапе
процесса, вводятся организационные субъек-
ты ответственности, вспомогательные доку-
менты, необходимые подтверждающие доку-
менты и прикладные системы.
Для описания организационной модели
иерархическая организация моделируется с
помощью организационных диаграмм. Поми-
мо иерархической организации, для структу-
рирования систем УК часто используются
ролевые модели, отражающие в рамках
предприятия роль различных субъектов, как,
например, менеджер по качеству, внутрен-
ний аудитор, руководитель проекта, клерк
или цеховой мастер. Организационные моде-
ли напрямую связываются с процессами. Это
позволяет сразу же увидеть, кто за что отве-
чает. Следует четко разграничивать, отвеча-
ет ли данная организационная единица за оп-
ределенную функцию, выполняет ли ее, уча-
ствует ли в ней или же ее только нужно
держать в курсе дела.
Должностные инструкции (описания опе-
раций) вытекают непосредственно из связи
должности сотрудников с конкретными фун-
кциями в цепочке процесса.
Каждое лицо, отвечающее за процессы,
сохраняет их модели в общекорпоративной
базе данных с помощью ARIS Toolset и может
осуществлять доступ к текущим процессам,
действующим организационным структурам
и документам. После согласования докумен-
тов их содержание еще раз рассматривается,
анализируется и утверждается. Затем доку-
ментация по УК оформляется в виде отчета,
т.е. общие описания процессов для руковод-
ства по УК создаются непосредственно из ди-
аграмм цепочек добавленной стоимости, раз-
работанных в ARIS Toolset, а на основании
диаграмм ЕРС генерируются процедурные
инструкции. Здесь наглядно выявляются
преимущества ARIS по сравнению с тради-
ционными системами документирования, где
документы и перекрестные ссылки прихо-
дится вести вручную.
ARIS Toolset позволяет представлять про-
цессы в виде многоуровневых иерархий, при
этом перекрестные ссылки, хранящиеся в си-
стеме, обеспечивают целостность и непроти-
воречивость архитектуры процессов.
Модели процессов можно также предоста-
вить непосредственно в распоряжение всех
сотрудников предприятия, участвующих в
проекте, что позволит эффективнее исполь-
зовать многопользовательские и сетевые
функции ARIS Toolset. При этом исключает-
ся необходимость в создании специальных и
процедурных инструкций для персонала.
Модель корпоративных процессов, построен-
ная с помощью ARIS Toolset, одновременно
служит реальной документацией системы по
УК. Предоставление соответствующих
пользовательских привилегий и прав досту-
па гарантирует пользователям доступ к нуж-
ным областям базы данных ARIS на уровне
чтения.
Ж.2.3.6. Применение и пересмотр
систем УК
После того как документация по УК введе-
на в действие, процессы выполняются в соот-
ветствии с новыми описанными стандартами.
Теперь можно начать внутренний аудит сис-
темы УК.
Дата проведения внутреннего аудита дол-
жна быть согласована с руководителем про-
веряемого сектора. Такая предварительная
договоренность исключает возможные подо-
зрения, что внутренний аудит проводится с
целью застичь кого-нибудь врасплох или
придраться к недочетам. Напротив, его зада-
ча состоит в том, чтобы помочь подразделе-
ниям освоить процессы УК в соответствии с
146 Бизнес-процессы
новыми инструкциями' Кроме того, аудит по-
зволяет выявить возможные ошибки в доку-
ментации.
Целью внутреннего аудита является со-
вершенствование процессов. Системы УК не
статичны, а напротив, подвержены постоян-
ным изменениям. В разное время и по разным
причинам может возникать необходимость в
совершенствовании документации, когда,
скажем, обнаружены ошибки в её содержа-
нии и оформлении или когда текущая доку-
ментация устарела вследствие изменений,
внесённых в процессы УК. Очевидно, что в
таких случаях необходимы изменения и в до-
кументации. Поскольку ARIS Toolset опира-
ется на компьютеризованную базу данных,
обновление документации предельно упро-
щается и существенно сокращаются после-
дующие усилия по распространению ее мо-
дифицированных версий.
После того как система УК успешно реа-
лизована и прошла внутренний аудит, эта
фаза завершается. Теперь предприятие гото-
во к сертификации.
Ж.2.3.7. Сертификация
Процедура сертификации зависит от ус-
ловий договора с организацией, выдающей
сертификат. В числе основных элементов
процедуры — заполнение краткой анкеты,
возможно, предварительный аудит и, разу-
меется, фактический аудит предприятия. На
этом этапе проверяется, отвечают ли уста-
новленные предписания требованиям стан-
дарта, знают ли об этом соответствующие
лица и действительно ли эти предписания со-
блюдаются.
За сертификатом УК можно обращаться
после успешного проведения внутреннего
аудита. Сертификат действителен в течение
трех лет, при этом выдающая его организа-
ция ежегодно проводит повторный аудит вы-
борочной проверкой системы УК. Одна из
важнейших целей повторного аудита — про-
верить, устранены ли недостатки, выявлен-
ные в ходе предыдущего аудита. Полная по-
вторная сертификация через каждые три
года обусловлена необходимостью постоян-
ного поддерживать документации УК на
уровне современных требований.
Ж.2.3.8. Перспективы и
инфраструктура: системное
управление качеством
Получение сертификата ISO 900х не озна-
чает, что можно отказаться от дальнейших
усилий в области повышения качества. На-
против, качество следует постоянно контро-
лировать с учетом требований внутренних и
внешних потребителей. Для системного уп-
равления качеством (СУК) необходимо мыс-
лить и действовать с точки зрения эффектив-
ности процессов. Поскольку создание систе-
мы УК, ориентированной на процессы,
непосредственно связано с сертификацией
ISO 900х, «процессная концепция» получила
на предприятиях широкое распространение.
Принцип СУК требует непрерывного совер-
шенствования корпоративных процессов и
постоянной оценки положения дел под кри-
тическим углом зрения.
Продолжительность и стоимость каждого
бизнес-процесса, моделируемого средствами
ARIS Toolset, можно оценивать при помощи
результата анализа различных показателей
и имитационных экспериментов. Включен-
ный в ARIS Toolset компонент АВС (поопера-
ционное исчисление стоимости) позволяет
контролировать процессы с точки зрения их
экономичности. Система workflow (если она
реализована) предоставляет данные, кото-
рые могут служить основой для определения
эффективности процессов. Фактическая сто-
имость и продолжительность выполнения
процессов подсказывают возможности опти-
мизации.
Ж.З. Использование моделей
ARIS для управлениязна
НИЯМИ
Д-р Томас Аллвейер, IDS Prof. Scheer
GmbH, Саарбрюккен, Германия.
Сравнение ARIS с другими концепциями 147
Ж.3.1. Использование знаний для
получения конкурентных
преимуществ
Несмотря на возрастающее значение на-
копленных корпоративных знаний, факти-
чески они используются лишь в объеме 30%,
а остальные знания, как правило, лежат мер-
твым грузом (Zucker, Schmitz. Knowledge
Flow Management. 1994). Исследования пока-
зывают, что большинство компаний исполь-
зуют свои корпоративные знания неадекват-
но или не в полной мере. Например, из-за от-
сутствия определенной информации часто
допускаются дорогостоящие ошибки. Или
критически важные знания оказываются ут-
раченными в связи с уходом из компании со-
трудников (Spek, Ноод. Knowledge
Management. 1994). В последние годы разук-
рупнение среднего управленческого звена
нередко приводило к серьезным потерям зна-
ний. Децентрализация компании влечет за
собой и децентрализацию знаний, поэтому
одна из важнейших проблем — обеспечить
доступность ключевой информации в масш-
табах всего предприятия. В противном слу-
чае в одних и тех же ситуациях приходится
каждый раз заново изобретать велосипед.
Сегодня все больше организаций предпри-
нимают соответствующие меры с целью обес-
печить управление одним из насущнейших
ресурсов — информацией. В некоторых ком-
паниях даже учреждена новая должность —
директор по знаниям (Davenport. Knowledge
Management. 1996), в функции которого вхо-
дят разработка, мониторинг и совершенство-
вание стратегий, процессов, организацион-
ных структур, технологий для обработки
корпоративной информации (Probst, Raub,
Rombardt. Wissen managen. 1997). Сбор, ото-
бражение, предоставление и использование
знаний зависят также от других корпоратив-
ных функций и осуществляются даже непос-
редственно в рамках бизнес-процессов. Та-
ким образом, понимание бизнес-процессов —
важнейшая предпосылка для
целенаправленного управления знаниями.
Выполнение таких функций, как, скажем,
разработка продуктов или консалтинг всегда
предполагало высокий уровень компетентно-
сти. Теперь все больше знаний требуют те-
перь и предельно стандартизованные про-
цессы (например, обработка заказов), кото-
рые приобретают все большую гибкость, что
продиктовано стремлением полнее удовлет-
ворять индивидуальные запросы клиентов.
Для выполнения этих процессов нужен хоро-
шо обученный и опытный персонал, а также
соответствующая документация и справоч-
ные руководства.
Таким образом, для совершенствования
бизнес-процессов необходим не только ана-
лиз потока функций, данных, организацион-
ного потока и потока управления, но и эф-
фективное использование накопленных зна-
ний — как оформленных в виде
документации, так и составляющих личный
«багаж» сотрудников.
Ж.3.2. Процедуры реинжиниринга
процессов знаний
На рис. 93 представлена процедурная мо-
дель для совершенствования использования
корпоративных знаний. По аналогии с терми-
ном «реинжиниринг бизнес-процессов» мы
хотели бы предложить термин «реинжини-
ринг процессов знаний».
Одна из важнейших задач на этапе стра-
тегического планирования знаний — выяс-
нить, какие знания имеют ключевое значение
для предприятия, чтобы сфокусировать про-
ект на соответствующих участках.
Далее анализируются существующие спо-
собы обработки знаний, определяется, где
размещаются конкретные корпоративные
знания, как и где они создаются и каким обра-
зом используются.
Результаты анализа «как есть» служат
фундаментом для дальнейшего исследования
системы обработки знаний с целью выявить
недостатки (например, монополизацию или
слабое использование существующих зна-
ний) и потенциальные возможности усовер-
шенствования.
На этапе создания целевых концепций оп-
ределяются конкретные изменения в процес-
сах, вносятся поправки в документацию, рас-
148 Бизнес-процессы
Стратегическое
планирование
знаний
Анализ
обработки
знаний
"как есть"
Анализ
"как есть"
выполнен
Анализ
состояния
обработки
знании "как есть'
целевая
концепция
обработки
знаний
Концепция
реализации
средствами
ИТ создана
Осуществление
концепций
реализации
Рис. 93. Предварительная процедурная модель ARIS для реинжиниринга процессов знаний
Внедрение ARIS — практические процедуры 149
пространяются знания в рамках существу-
ющих бизнес-процессов или разрабатывают-
ся специальные процессы знаний для сбора,
подготовки и распространения знаний.
Для того, чтобы создать условия, в кото-
рых внесение этих изменений было бы ус-
пешным, необходимы соответствующие
организационные и кадровые мероприятия
(например, обучение персонала), а также
подготовка базы в виде вспомогательных ин-
формационных и коммуникационных техно-
логий (прикладные системы для коллектив-
ной работы или интрасети). Наконец, для реа-
лизации этих концепций следует обучить
персонал, протестировать новые процедуры
и проводить их совершенствование.
Далее мы рассмотрим, как эти этапы про-
цедурной модели создаются с помощью ARIS.
Ж.3.3. Фазы реинжиниринга
процессов знаний
Ж.3.3.1. Стратегическое
планирование знаний
Стратегическое планирование знаний
опирается на стратегические корпоративные
цели. Основное назначение данной фазы зак-
лючается в том, чтобы определить, каким об-
разом управление знаниями может способ-
ствовать достижению этих целей и какие
конкретные задачи вытекают из самого про-
екта. Например, компания может ставить пе-
ред собой стратегическую цель занять или
сохранить лидирующее положение в каче-
стве поставщика технологий. Проект управ-
ления знаниями должен обеспечивать сбор и
учет внешней информации об этих техноло-
гиях. Необходима также координация и, воз-
можно, активизация внутренних научно-ис-
следовательских и опытно-конструкторских
разработок в этой области. В любом случае,
особенно важно совершенствовать обмен
корпоративными знаниями, их документиро-
вание, облегчая таким образом к ним доступ.
Именно поэтому стратегическую целевую
систему и базовые корпоративные бизнес-
процессы, так же как и актуальные катего-
рии знаний, целесообразно представлять
средствами ARIS Toolset, чтобы установить
между ними связь. Эти модели являются от-
правной точкой для детального моделирова-
ния на следующем этапе.
Ж.3.3.2. Анализ процесса обработки
знаний «как есть»
На этой фазе проекта фиксируется и мо-
делируется состояние предприятия «как
есть». Выше уже было сказано, что вслед-
ствие тесной связи между бизнес-процесса-
ми и управлением знаниями сначала необхо-
димо представить бизнес-процессы в виде
диаграмм ЕРС. Часто такие модели уже су-
ществуют — они создаются в ходе реинжи-
ниринга бизнес-процессов или при внедре-
нии стандартного программного решения.
Для того чтобы описать процесс обработки
знаний, важно также построить модель, от-
ражающую, какие категории знаний обраба-
тываются, кто какими знаниями обладает,
какие знания требуются для конкретных
функций, где эти знания создаются или отку-
да их можно получить. Помимо объектов, не-
обходимых для оптимизации бизнес-процес-
сов, для этого дополнительно нужны типы
объектов и моделей. Эти типы представлены
на диаграмме ЕРС в ARIS Easy Design (см.
рис. 94).
— Структурные диаграммы знаний. Эти
диаграммы наглядно показывают, ка-
кие знания актуальны для предприя-
тия. Например, объем знаний, необхо-
димых для проекта, может включать
знание прикладной области, процедур,
методов и инструментов управления
проектом, навыки проведения демонст-
рации и презентаций и т.д. Мы можем
разграничить общие, подразумеваемые
знания, которыми обладают сотрудни-
ки, и знания, представленные в явно
выраженной документальной форме. К
последним относятся конкретные доку-
менты, файлы, прикладные системы,
где зафиксирована соответствующая
информация.
— Карты знаний. В этом случае диаграм-
мы представляют, какие сотрудники
или организационные единицы облада-
ют конкретными знаниями (Scheer,
Bold, Hagemeyer, Kraemer. Informa-
150 Бизнес-процессы
Рис. 94. Моделирование обработки знаний
tionssysteme im Wandel. 1997). Они мо-
гут отражать также степень полноты
знаний. Карты знаний позволяют выя-
вить области неполных знаний и моно-
польных носителей знаний.
— Создание и использование знаний.
Здесь моделируется дополнительная
информация в рамках моделей суще-
ствующих бизнес-процессов, показы-
вающая, например, в какой мере те или
иные знания необходимы для реализа-
ции определенной функции или какие
знания документально фиксируются
при выполнении какой-либо функции.
Информационные и коммуникационные
системы, фигурирующие в структурных ди-
аграммах знаний и моделях бизнес-процес-
сов, можно использовать для документирова-
ния, обработки и распространения знаний.
Помимо аспектов, которые могут быть
изображены только графически, описание
должно включать модели, отражающие спо-
соб представления и подготовки знаний и на-
личие или отсутствие мотивации для обмена
знаниями.
Ж.3.3.3. Анализ состояния «как есть»
Особые преимущества моделирования
«как есть» заключаются в том, что оно позво-
ляет документально зафиксировать, какими
знаниями располагает предприятие и где они
находятся. Такая документация помогает бы-
стро отыскать нужного человека для реше-
ния конкретных вопросов.
Однако одним из ключевых достоинств мо-
делей является их способность выявлять сла-
бые места и области с потенциальными воз-
можностями для совершенствования обра-
ботки знаний. К таким областям могут,
например, относиться:
-— стратегически важные знания, не охва-
ченные предприятием;
—- монопольное владение знаниями, при-
водящее к утрате критических знаний,
особенно в связи с уходом из компании
сотрудников;
— неудовлетворенные потребности в зна-
ниях;
Внедрение ARIS — практические процедуры 151
— неиспользуемые знания из арсенала
предприятия;
— приобретение и создание одних и тех
же знаний каждый раз заново (фактор
избыточности);
— бесполезные или устаревшие знания
сотрудников;
— жесткая организационная обособлен-
ность приобретения и использования
знаний, затрудняющая их распростра-
нение;
- — отсутствие согласованности в реальной
инфраструктуре информационных и
коммуникационных технологий, пред-
назначенной для обработки знаний.
Ж.3.3.4. Целевая концепция
обработки знаний
В соответствии с результатами анализа в
бизнес-процессы на этом этапе вносятся из-
менения, направленные на улучшение обра-
ботки знаний. Это означает в том числе и воз-
можность включения дополнительных функ-
ций для документирования приобретенного
опыта и информации и предоставление их в
распоряжение других сотрудников.
Кроме того, можно описать конкретные
процедуры обработки, предназначенные для
обновления, структурирования и распрост-
ранения знаний, а также для удаления уста-
ревших знаний. Можно, например, для отде-
ла продаж описать общекорпоративный про-
цесс сбора и компиляции данных о
требованиях и пожеланиях клиентов. Эта ин-
формация может использоваться для даль-
нейшей разработки продуктов с последую-
щим её распространением.
В дополнение к этому следует описать не-
обходимые изменения в организационных
структурах и определить целевые профили
знаний для сотрудников. И последнее, но не
менее важное: на этом этапе нужно описать и
смоделировать требования к средствам под-
держки в виде систем на базе информацион-
ных и коммуникационных технологий. Важно
позаботиться о том, чтобы определяющую
роль в проектах управления знаниями игра-
ли не технологии, а требования бизнеса. Воп-
реки грандиозным ожиданиям из всего комп-
лекса группового программного обеспечения,
внедренного в компании, часто используется
только электронная почта или, скажем, един-
ственным приложением, работающим в кор-
поративной интрасети, оказывается ежене-
дельное меню столовой предприятия. Подоб-
ные проблемы возникают в тех случаях,
когда конкретные потребности пользовате-
лей не сфокусированы на эффективной обра-
ботке знаний.
Целевая концепция обработки знаний опи-
сывается типами моделей, рассмотренными
выше.
Ж.3.3.5. Организационно-кадровая
концепция реализации
На этой фазе разрабатываются и реализу-
ются концепции обучения, направленные на
ознакомление персонала с изменениями в
процессах и с новыми информационными си-
стемами. Для того чтобы определить, кого из
сотрудников затрагивают основные измене-
ния, и разработать конкретные меры и курсы
обучения, используются модели «как есть» и
целевые модели, созданные на предыдущих
этапах. Эти модели применяются также для
наглядной демонстрации и в качестве
средств обучения.
Профильные знания используются при
планировании, в курсах повышения квали-
фикации персонала, а также при приеме на
работу новых сотрудников.
Ж.3.3.6. Концепция реализации
средствами ИТ
Целевые модели определяют целевые тре-
бования к средствам поддержки в виде ин-
формационных и коммуникационных систем
(сюда относятся, например, интрасетевые ре-
шения, групповое программное обеспечение
и системы управления документа ми). Для
интегрирования разных систем и обеспече-
ния доступа к содержанию знаний с точки
зрения их согласованного распространения и
доставки, как правило, необходима единая
структура, например, технологии Интернет/
интранет (Christmann-Jacoby, Maas.
Wissensmanagement. 1997).
152 Бизнес-процессы
Концепции реализации управления зна-
ниями с помощью ИТ включают и такие ас-
пекты, как структурирование содержания,
описание пользовательских интерфейсов,
внедрение специальных служб типа дискус-
сионных групп или подписки на информаци-
онные услуги. Модели ARIS с инструмен-
тальной поддержкой, применяемые в бизнес-
процессах и обработке знаний, позволяют
перемещаться по содержанию знаний, как
навигационные структуры, ориентирован-
ные на процессы. При этом модели служат
отправной точкой, а доступ к информации,
необходимой для того или иного процесса,
осуществляется при помощи гиперссылок.
Ж.3.3.7. Реализация концепций
Реализация концепций предполагает про-
ведение курсов обучения, обеспечение соот-
ветствия персонала квалификационным тре-
бованиям, подготовку и контроль модифика-
ции бизнес-процессов и организационных
структур, а также внедрение информацион-
ных и коммуникационных технологий. Фун-
даментом для этого служат разработанные
модели ARIS.
Новые процессы и системы следует проте-
стировать и при необходимости их откоррек-
тировать. Расширение обработки знаний воз-
можно при внедрении процесса непрерывно-
го совершенствования. Одной из важнейших
предпосылок здесь является постоянное об-
новление моделей бизнес-процессов и моде-
лей обработки знаний. Это обеспечивает про-
зрачность их текущего состояния (Allweyer.
Adaptive Geschaftsprozesse. 1997).
Издательство АОЗТ «Просветитель»
Москва, В. Якиманка, 38а
Лицензия ЛР №071532 от 31.10.97
Подписано в печать 08.06.99 г.
Формат 62x94/8. Гарнитура «Journal». Печать офсетная.
11 пен. л. Тираж 950 экз.
Бумага мел. Заказ № 66.
Отпечатано в типографии АОЗТ «Просветитель» с готовых диапозитивов.
Москва, В. Якиманка, 38а