Шеер. Бизнес-процессы. Основные понятия. Теория. Методы
Подождите немного. Документ загружается.
классов мы воспользуемся именно этим языком. Что касается содержания, то оба языка
взаимозаменяемы.
Язык описания UML позволяет отдельно представлять классы объектов и классы связей в
моделях различных типов. Такое представление известно как метамодель ARIS или
информационная модель ARIS.
В то же время эта информационная модель описывает конструкцию базы данных, где
можно хранить модели реального мира, разработанные с помощью методологии ARIS.
Организационные и функциональные модели, равно как и модели данных, выхода и
управления, относящиеся к тому или иному приложению, рассматриваются как экземпляры
базы данных, построенной в соответствии с информационной моделью. Такие базы данных
называются репозиториями. Понятие «репозиторий» приобрело популярность в 1989 году,
когда корпорация IBM провозгласила новую концепцию разработки программного обеспечения
- AD/CYCLE.
Для каждой модели ARIS (функциональной, организационной, данных, выхода и
управления) репозиторий ARIS содержит модели 2-го уровня, а также их отношения и модели
для каждой фазы жизненного цикла ARIS. При моделировании на 1-м уровне, т. е. на уровне 1
экземпляров ARIS, репозиторий необходимо обновлять, вводя в него соответствующие
экземпляры процесса.
Таким образом, репозиторий становятся ядром информационной системы. Важность и
значение информационной модели, содержащейся в репозитории, определяется ее
способностью оказывать решающее влияние на эффективность элементов описания.
Язык UML оперирует диаграммами классов, которые изображаются прямоугольниками, и
ассоциативными связями (или просто связями), которые в свою очередь изображаются
рамками. Связи различаются по мощности отношений 1:* (один ко многим), 1:1 (один к
одному), *:* (многие ко многим) или *:1 (многие к одному). Звездочка может означать «много»
или «n».
С помощью этих простых элементов на рис. 19 представлен эскиз информационной
модели ARIS. В каждой модели описываются лишь несколько рассмотренных до сих пор
классов вместе с их связями. Из различных элементов жизненного цикла сюда включена —
только фаза определения требований, т. е. характеристики, связанные со спецификацией
проекта и описанием реализации, не используются. Информационная модель, изображенная на
рис. 19, дает общее представление об этом типе модели.
Отправными точками функциональной модели на рис. 19 являются корпоративные цели,
которые управляют функциями; другими словами, для достижения той или иной цели должны
быть выполнены определенные функции. Корпоративные цели обычно классифицируются по
иерархическому принципу. Общие цели, такие как «максимизация прибыли», «достижение
определенной рыночной доли» или «достижение определенного темпа роста», разделяются на
подцели, например, «достижение определенной суммы дохода», «снижение расходов на
определенную сумму» или «достижение определенного уровня качества». Благодаря
интегрированной структуре целей класс КОРПОРАТИВНЫЕ ЦЕЛИ характеризуется связью
*:*. Поскольку подцели входят в главные цели, они характеризуются связью «часть целого».
Такая связь называется целевой структурой. Она выделяется в самостоятельный класс.
Примерами функций являются обработка заказов, продажа или регулирование, которые
могут быть детализированы на составляющие их подфункции. Взаимосвязь между функциями,
равно как и связь функций с целями, на достижение которых они направлены, предполагает
между ФУНКЦИЕЙ и КОРПОРАТИВНЫМИ ЦЕЛЯМИ отношение типа *:*.
ФУНКЦИОНАЛЬНАЯ СТРУКТУРА представляет собой связь «часть целого», определяя
функции, содержащиеся в других функциях.
Центральным элементом в организационной модели является ОРГАНИЗАЦИОННАЯ
ЕДИНИЦА. Этот класс включает такие экземпляры, как ПОЗИЦИЯ, ПОДРАЗДЕЛЕНИЕ или
ПРЕДПРИЯТИЕ. Независимо от того, являются эти области подчиненными или главными, они
всегда характеризуются связью *:* — это «часть целого» в рамках класса
ОРГАНИЗАЦИОННАЯ ЕДИНИЦА. Таким образом, эта связь позволяет одной области
выступать в качестве подчиненной по отношению к нескольким другим. Это относится,
51
например, к отделу продаж, который связан с рядом основных областей, производящих
продукт. Ответственные субъекты или средства («машины», «компьютер», «человеческий
ресурс») связываются с организационными единицами.
Модель данных (левая часть здания ARIS) отображает структуру данных. Класс
ИНФОРМАЦИОННЫЙ ОБЪЕКТ характеризует объекты, описываемые атрибутами баз
данных. Между их экземплярами, такими как данные об изделии и данные о клиенте,
существуют связи (например, какой клиент какие изделия покупает). Эти связи выражаются
отношением *:* внутри класса ИНФОРМАЦИОННЫЙ ОБЪЕКТ.
Информационные объекты, относящиеся к области с взаимосвязанным содержанием,
можно сгруппировать в диаграмму класса или модель данных. Поскольку из-за идентичных
информационных объектов МОДЕЛЬ ДАННЫХ и ИНФОРМАЦИОННЫЙ ОБЪЕКТ могут
частично накладываться друг на друга, они связаны отношением *:* — «часть целого».
В модели выходов класс ВЫХОД представляет все виды выходов (материальный выход,
услуги и информационный выход). Экземплярами выступают классы выходов, связанные с
прикладным уровнем, например, изделие, материалы, запчасти, время сборки, гарантийные
услуги или сертификаты. Здесь также различные виды выходов могут быть взаимосвязаны
(отношением «часть целого»).
Связи между всеми четырьмя компонентами (организация, функция, информация и
выходы) представлены в модели управления.
Связь между ОРГАНИЗАЦИОННОЙ ЕДИНИЦЕЙ и ФУНКЦИЕЙ выражается
отношением ОТВЕТСТВЕННОСТЬ.
Организационным единицам могут быть присвоены определенные привилегии,
относящиеся к ИНФОРМАЦИОННЫМ ОБЪЕКТАМ, которые выражаются отношением
ПРИВИЛЕГИИ ДОСТУПА.
Полная функциональная модель ARIS подробно описывает классы и отношения между
ними в модели мета-бизнес-процесса. Она описывает также все модели ARIS, охватывающие
фазы жизненного цикла. Эта модель включает около 300 классов и связей.
Информационная модель ARIS представляет собой схему репозитория для хранения
соответствующих прикладных моделей. Данные, хранящиеся в репозитории, включают классы
реальных приложений (например, для сферы продаж или бухгалтерского учета), хотя обычно -
на уровне типов. В то время как объекты типа КЛИЕНТ и ИЗДЕЛИЕ хранятся в репозитории в
качестве экземпляров класса ИНФОРМАЦИОННЫЙ ОБЪЕКТ, сами экземпляры, т. е.
индивидуальные сущности «клиент» и «изделие» 1-го уровня, как правило, хранятся в базе
данных о продажах. При моделировании процессов на уровне экземпляров (например, для
приложений workflow) соблюдать это правило не обязательно.
На рис. 20 сгруппированы четыре компонента метауровня с указанием их взаимосвязей:
мета-бизнес-процесс ARIS,
архитектура (Здание ARIS),
информационная модель ARIS,
репозиторий ARIS.
В.4. Предварительная процедурная модель ARIS
Концепция ARIS предоставляет методологию описания бизнес-процессов от этапа
определения требований до этапа описания реализации. Примером может служить обработка
заказов, жалоб или страховых исков.
Проведение реорганизации тоже можно интерпретировать как бизнес-процесс. В силу
того, что реорганизация предполагает участие многочисленного штата сотрудников (как своих,
так и посторонних), выполнение множества функций, составление и использование несметного
количества документов, не помешает заранее спланировать этот процесс, руководствуясь
концепцией ARIS.
Процедурная модель ARIS описывает, как реализовать концепцию ARIS, т. е. как
необходимо организовать управление проектом, определить функции и получить пакет
52
выходных документов на базе ARIS. Процедурная модель ARIS описывает концепцию ARIS,
пользуясь средствами ARIS.
Процедурные модели можно строить и на уровне типов (2-й уровень моделирования). В
этом случаи они могут служить моделями реального проекта. Процедурные модели для
реорганизации бизнес-процессов (английская аббревиатура - BPR), разработки программного
обеспечения, реализации систем workflow или стандартных программных решений можно
найти в приложениях и научных публикациях. Эти модели используются для создания
процедур применительно к конкретным проектам.
Если подробное описание процедурной модели отсутствует, это не столь уж важно.
Например, процедурная модель BPR, предложенная Хэммером и Чампи, содержит всего пять
функций: мобилизацию, диагностику, перепроектирование, переход и управление
изменениями. Последняя функция осуществляется одновременно с первыми четырьмя фазами.
С другой стороны, для разработки программного обеспечения существует широкий диапазон
процедурных моделей, в том числе V-модель Координационного и консультативного
управления Германского правительства по информационной технологии в федеральной
администрации. Разработаны и различные модели для реализации workflow. Для облегчения
реализации стандартных программных решений, в частности SAP/R3 и SAP, ряд
консалтинговых фирм предлагает детальные процедурные модели.
53
Рис. 21. Один из вариантов диаграммы EPC для процедурной модели ARIS
54
Рис. 22. ARIS-модели «создания определения требований на уровне функциональной модели»
Помимо процедурных моделей различного назначения, имеются коммерческие модели для
локальных целей, например, для моделирования данных. Процедурная модель семантических
объектов (SOM), разработанная Зинцем и Ферстлем, предназначена для внедрения объектно-
ориентированных методов в моделирование бизнес-процессов.
На первый взгляд, процедурная модель ARIS включает те же модели и фазы жизненного
цикла, которые описаны в ARIS. Однако, используя эти объекты и соответствующие методы,
процедурную модель ARIS можно реализовать на гораздо более детальном уровне. На рис. 21
процедурная модель, представленная в виде последовательности процессов, управляемых
событиями (EPC), состоит из функций и событий. Отношения последовательности позволяют
одновременно реализовать модели функций, организации, данных, выходов и управления для
одной и той же фазы. Определение требований начинается с модели управления, т. е. с
описания процесса. При разбиении процессов на отдельные конкретные этапы может
происходить наложение детализированных областей. В рамках процессов можно задавать
различные уровни детализации; однако придерживаться жесткого принципа разбиения на фазы,
как в модели «водопада», отнюдь не обязательно. Скорее, различные формы разработки,
например создание прототипов, можно представить в виде некоторых упорядоченных
отношений.
Помимо функций и событий, сюда можно включить и другие элементы описания
процесса, например, организационные единицы, данные и выход. На рис. 22 изображена схема
«создания определения требований на уровне функциональной модели».
Модели данных содержат ключевые вехи процедурной модели (т. е. события и
сообщения, инициирующие или завершающие процесс) и контекстных описаний (такие как
модели, хранимые в репозитории моделей).
Функциональные модели предоставляют стандартные блоки архитектуры ИТ. С ними
ассоциируется соответствующее программное обеспечение, будь то текстовый процессор или
инструменты моделирования.
Организационные модели описывают подразделения, кадры и машинные ресурсы,
необходимые для отдельных процессов.
Модели выходов определяют входы и выходы функций, т. е. управляющую и
функциональную модели.
55
До сих пор мы рассматривали процедурные модели только на уровне определения
требований. Поскольку они содержат ИТ-объекты, такие как репозитории моделей,
персональные компьютеры и прикладное программное обеспечение (текстовые процессоры,
программы моделирования и т. д.), процедурные модели можно перенести также на фазы
спецификации проекта и описания реализации.
На этапе спецификации проекта определяются проектные характеристики для баз данных
репозитория, персональных компьютеров и программных средств моделирования. Затем, на
этапе описания реализации описывается их реализация с точки зрения информационных
технологий. Если используется ARIS Toolset, то фаза спецификации проекта является тем
этапом, где принимается решение о внедрении одной или нескольких пользовательских версий.
На уровне описания реализации определяются реальные параметры и фактические базы
данных.
На базе общей процедурной модели можно построить специализированные модели под
конкретные проекты. Например, при реинжиниринге информационной системы отдела продаж
общие функции типа «создание определения требований на уровне модели данных»
дополняются функцией «создание модели данных и определение требований информационной
системы отдела продаж». Это сопоставимо с переходом от моделирования типов к описанию
экземпляров. С другой стороны, абстрагирование от конкретных отношений в процедурной
модели ARIS дает общую метамодель ARIS на 3-м уровне моделирования.
Подведем итоги:
Процедурная модель ARIS определяется соответствующей архитектурой ARIS,
описывающей бизнес-процессы.
Поскольку процедурные модели можно рассматривать как модели бизнес-процессов, они
могут описываться теми же концептуальными моделями ARIS, что и любой другой бизнес-
процесс.
Результаты каждой функции в процедурной модели хранятся в репозитории ARIS.
Репозиторий, т. е. информационная модель ARIS, является стандартной схемой для
хранения результатов, например проекта базы данных. Эти результаты представляются в виде
функциональной модели, модели данных, организационной модели, модели выходов и
управления.
Модель-прототип процедурной модели также хранится в репозитории ARIS.
На рис. 23 показано, как процедурная модель ARIS соотносится с концепцией ARIS - на
этот раз на примере организации, занимающейся продажей. Процедурная модель хранится в
репозитории ARIS и описывается на 2-м уровне. Ее логика определяется архитектурой ARIS и
информационной моделью ARIS. Представляя единичный процесс реализации проекта,
процедурная модель, ориентированная на конкретную предметную область, является
экземпляром общей процедурной модели для разработки бизнес-процессов с размещением их
на 1-м уровне моделирования. Процедурная модель в репозитории соответственно
модифицируется. Пунктирные стрелки показывают, каким образом метауровень определяет
подчиненные уровни, а сплошные иллюстрируют последовательность операций в процедурной
модели. В итоге получаются модели продаж. Эти модели размещаются на 2-м уровне
моделирования, описывая общие процессы продажи.
56
Рис. 23. Отношение между концепцией ARIS и информационной моделью ARIS
57
Г. Управление бизнес-процессами на базе ARIS. ARIS —
архитектура бизнес-инжиниринга
Итак, концепция ARIS прокладывает путь к инжинирингу, планированию и управлению
бизнес-процессами. Теперь проанализируем ее преимущества, упомянутые в разделе А, а также
деловые, организационные и информационно-технологические (ИТ) аспекты ее реализации.
ARIS-архитектура бизнес-инжиниринга (АБИ) расширяет архитектуру ARIS, позволяя
рассматривать управление бизнес-процессами не только с организационной точки зрения, но и
с точки зрения информационных технологий. Мы покажем, каким образом ARIS способствует
управлению бизнесом на этапах проектирования и разработки с помощью программных
инструментов, совместимых с ARIS.
ARIS АБИ дает владельцам бизнес-процессов возможность сконцентрировать внимание на
различных аспектах построения и описания своих бизнес-процессов, предоставляя в их
распоряжение полную инфраструктуру для управления — от организационного инжиниринга
до практической реализации информационных технологий, включая непрерывное адаптивное
совершенствование. Кроме того, АБИ позволяет осуществлять планирование и управление
текущими бизнес-процедурами на постоянной основе, уделяя внимание их непрерывному
совершенствованию. Инфраструктура АБИ опирается на всестороннее знание специфики
бизнеса, — важнейшую предпосылку планирования и управления производственными
процессами. Такие объекты, как «график работ» и «прейскурант материалов», служат основой
для детального описания производственных процессов, а системы производственного
планирования и управления в среде АБИ позволяют решать вопросы планирования и
контроллинга этих процессов. Многие из этих концепций и процедур можно обобщить. Такая
обобщенная система управления процессами представлена на рис. 24.
На уровне I (инжиниринг процессов) бизнес-процессы моделируются в соответствии с
производственным графиком работ. Концепция ARIS предоставляет инфраструктуру, которая
охватывает все аспекты бизнес-процесса. Здесь же используются различные методы
оптимизации и оценки, а также методы, гарантирующие качество процессов.
На уровне II (планирование и управление процессами) осуществляется планирование и
управление текущими бизнес-процессами. Сюда же относятся методы планирования,
регулирования мощностей и пооперационного стоимостного анализа. Мониторинг позволяет
менеджерам контролировать состояние различных процессов.
На уровне III (управление потоками работ) объекты, подлежащие обработке, например,
заказы клиентов с сопутствующей документацией или страховые иски, доставляются с одного
рабочего места на другое. Электронные документы доставляются системами класса workflow.
На уровне IV (прикладная система) документы, доставленные на рабочее место,
подвергаются определенной обработке, т.]е.]функции бизнес-процесса выполняются с помощью
прикладных программных систем (от простых текстовых процессоров до сложных
программных решений), бизнес-объектов и Java-аплетов.
58
Рис. 24. Управление процессами на базе концепции здания ARIS
Четыре уровня АБИ связаны между собой контурами обратной связи. Уровень управления
процессами предоставляет информацию об эффективности текущих процессов. Именно на этом
этапе начинается непрерывная адаптация и совершенствование бизнес-процессов.
Уровень управления потоками работ передает фактические данные о процессах,
подлежащих выполнению (суммы, сроки, выделяемые ресурсы), на уровень управления
процессами. Затем система workflow активизирует прикладные модули.
Пятый компонент концепции АБИ объединяет уровни I-IV в единую инфраструктуру.
Инфраструктуры содержат информацию о соответствующей архитектуре и приложениях,
конфигурируя реальные приложения с помощью инструментария уровней II и III, а
59
информацию по предметной области для них — из моделей-прототипов (уровень I).
Инфраструктуры включают также информацию о составе компонентов и их отношениях.
Программное обеспечение на уровнях инжиниринга и планирования процессов позволяет
владельцу бизнес-процесса взглянуть на бизнес с организационной точки зрения. Уровни же
управления потоками работ и прикладной системы относятся к конкретной программной
реализации. Модель жизненного цикла ARIS применима к каждому из четырех уровней.
Поэтому на каждом уровне любая программная система может быть описана с точки зрения
определения требований, спецификации проекта и описания реализации. Отношения между
уровнями АБИ рассматриваются преимущественно на уровне определения требований,
например: как логически перейти от модели процесса на уровне II к модели потоков работ на
уровне III. Здесь же анализируется совместимость проектной спецификации для системы
моделирования на уровне I с системой workflow на уровне III, включая даже аспекты
реализации. Уровни концепции АБИ перпендикулярны фазам жизненного цикла ARIS.
АБИ — это прежде всего концепция, однако ее можно использовать и как инфраструктуру
для разработки реальных программных продуктов. Концепция АБИ впервые предложена
автором на Саарбрюккенском семинаре в 1994 году. Она применяется в качестве стандартной
корпоративной архитектуры в фирме IDS Sheer AG и основана на практических знаниях и
опыте в области реальных прикладных систем. Концепция АБИ была предложена многим
другим производителям программного обеспечения. Автор неоднократно излагал ее в докладах
и на презентациях. В 1996 году ей был посвящен обстоятельный информационный документ.
Хотя концепция АБИ не привязана к конкретным коммерческим разработкам, из
практических соображений мы излагаем ее здесь применительно к различным продуктам ARIS,
системе SAP R/3 и Siemens-Nixdorf ComUnity, по ходу дела ссылаясь и на другие концепции
создания программного обеспечения.
В следующих разделах мы рассмотрим уровни концепции АБИ более подробно.
Г.1. Инжиниринг бизнес-процессов
Цель инжиниринга бизнес-процессов заключается в достижении максимально
эффективных бизнес-решений. Ответственность за инжиниринг может лежать на
организационных подразделениях, группах внедрения проектов по реструктуризации процессов
или даже на самих владельцах бизнес-процессов. Если разработка производственных графиков
может годами находиться в ведении одного отдела, то другие виды бизнес-процессов не
поддаются столь жесткой регламентации. Мы бы рекомендовали поручать инжиниринг тем
организационным структурам, которые отвечают непосредственно за бизнес-процессы.
Вообще, корпоративные бизнес-процессы, такие как, например, стандартный процесс
закупки, проектируются на уровне типов. Для некоторых подформ могут создаваться подтипы
(например, заказы на запасные детали, обычные детали или детали, требующиеся
эпизодически). Однако отдельно для конкретных деталей процессы заказа, как правило, не
моделируются.
60