Шеер. Бизнес-процессы. Основные понятия. Теория. Методы
Подождите немного. Документ загружается.
Рис.64. Архитектура SNI ComUnity
Г.5.2.4. Проект San Francisco компании IBM
Проект San Francisco компании IBM создан с целью ускорить и удешевить разработку
приложений для малых и средних предприятий (SME). Как показано на рис. 65, проект San
Francisco включает различные уровни. Разработчик приложений занимает верхнюю ступеньку,
откуда осуществляет доступ к остальным уровням. Виртуальная машина Java обеспечивает
независимость прикладных решений от аппаратно-программной платформы.
Базовый уровень подразделяется на три компонента: базовые службы, базовые классы
объектных моделей и утилиты.
Базовые службы основаны на стандарте OMG для служб объектов. Они представлены на
языке Java и частично адаптированы к функциональным возможностям Java и специфическим
требованиям IBM.
Базовые классы объектных моделей содержат механизмы для хранения или
идентификации объектов.
Утилиты содержат базовые компоненты графического пользовательского интерфейса
(GUI) и функции управления сеансами, включая средства управления конфликтами. Хотя эти
функции частично заложены в операционной системе, наличие таких средств в утилитах
обеспечивает интеграцию и единые принципы построения пользовательского интерфейса.
111
Рис. 65. Проект San Francisco компании IBM
Общие бизнес-объекты (СВО) применимы ко многим вертикальным рынкам.
Разработчикам программного обеспечения остается дополнить отдельные функции или
добавить конкретные характеристики, отражающие специфику компании. Сюда могут входить
такие функции, как управление адресами, условия платежа, календарное планирование или
обмен данными (например, EDI). Эти СВО сопоставимы с общими бизнес-объектами OMG, что
объясняет заинтересованность IBM в сертификации СВО Группой OMG. Базовые
инфраструктуры бизнес-процессов предоставляют объекты для управления заказами,
управления хранилищами (складами), а также для корпоративного учета. По оценкам IBM, на
общие бизнес-объекты и базовые инфраструктуры бизнес-процессов приходится примерно 40%
любого приложения. Остальное составляют экранные формы, характеристики, учитывающие
конкретные особенности страны и отрасли, бизнес-правила и дополнительные функции,
составляющие специфику приложения
Г.5.3. Перспективы развития индустрии программного обеспечения
Появление компонентного ПО и создание рабочих пространств открывают новые
возможности для разработки программного обеспечения Здесь можно провести аналогию с
производством компьютерного оборудования, где на смену вертикальному подходу, когда
поставщики изготавливали аппаратные системы целиком «от и до», пришел горизонтальный
принцип, при котором процессоры, периферийные устройства, операционные системы и]т.]д.
изготавливаются отдельно, а затем компонуются. Те же перспективы и в области разработки
прикладного ПО. Применительно к аппаратным средствам предпосылкой такого развития стало
создание стандартов на процессоры, операционные системы, базы данных и
коммуникационные сети.
Помимо прочего, для разработки прикладных систем потребуются стандарты на
компоненты и инфраструктуры. Такие стандарты позволят адаптировать компоненты,
выпускаемые разными производителями, к различным рабочим пространствам.
112
Есть основания полагать, что глубина производства в индустрии ПО станет уменьшаться.
Рынок будут формировать производители, специализирующиеся на комплексных решениях и
выполняющие сборку компонентов в рамках (своих) инфраструктур, а также поставщики
компонентов. Между этими двумя полюсами займут место изготовители подсистем,
поставляющие промежуточные продукты.
Отбор и замена компонентов будут производиться по принципу «лучших представителей
своего класса», а при сборке в центре внимания будет ноу-хау самого бизнеса и возможности
его моделирование в соответствии с методом сборки. Таким образом, точками фокусировки при
разработке программного обеспечения станут уровень инжиниринга как часть концепции АБИ
с его методами моделирования, а также связи для интеграции с workflow и адаптации бизнес-
объектов.
Точно так же, как в автомобильной промышленности производители должны обладать
знаниями и опытом в области разработки (инжиниринга), логистики и сборки, поставщикам
комплексных решений, помимо овладения инфраструктурами, потребуются навыки в работе с
методами наполнения их содержанием и моделирования, представленные на уровне I. Кроме
того, им необходимо будет оценивать кандидатуры поставщиков компонентов, а также
устанавливать связи между производителями и поставщиками. Производителям комплексных
решений потребуются также знания и опыт в области консалтинга и технического
обслуживания на глобальном уровне, т.]е.]возможности, которыми располагают только крупные
корпорации. Такой «багаж» необходим, чтобы гарантировать целостность предлагаемых
полных решений. Поставщики помельче сосредоточатся на разработке отдельных компонентов
и подсистем.
С другой стороны, не следует переоценивать возможности рынка компонентного ПО —
здесь крупным поставщикам решений придется делать выбор. Проблема в том, что принцип
конструктора «Лего», допускающего произвольную компоновку элементов, в этой области
неприменим. Элементы «Лего» совершенно идентичны и собираются по типовой схеме. Для
этого необязательно понимать их внутреннюю структуру, достаточно знать, что они имеют
стандартные размеры и «связи».
В отличие от «Лего» программные компоненты содержат прикладную информацию —
каждый свою. Для их сборки необходимо хорошо разбираться в технических интерфейсах и
логике приложения. Этим определяется возможность или невозможность использования в
сборке того или иного компонента. Главное условие для правильной сборки — наличие
исчерпывающего документального описания компонентов. Создание сложных модулей требует
объединения усилий поставщиков комплексных решений и поставщиков отдельных
компонентов. Здесь можно провести аналогию с аэрокосмической и автомобильной отраслями.
В этих отраслях обмен информацией о продуктах и тесное сотрудничество в процессе
разработки называются параллельным инжинирингом. Опыт в области параллельного
инжиниринга и многие его методы в значительной мере применимы и к разработке
программного обеспечения. К сожалению, в отличие от сферы материального производства,
поставщику программных компонентов труднее защитить свое ноу-хау. Если знания и опыт,
которыми обладают изготовители автотранспортных средств в области научно-
исследовательских и опытно-конструкторских разработок, а также в области производства,
охватывают процедуры и технические ресурсы, и при этом они постоянно производят свою
продукцию, то все, чем располагают поставщики ПО, — это методы и технологии разработки.
После совместной работы над каким-нибудь проектом поставщику решений не составит
ни малейшего труда «позаимствовать» у партнера его ноу-хау.
Важнейшими условиями интенсивного развития компонентного ПО являются создание
эффективных механизмов защиты и определенная культура отношений, основанная на
принципах доверия и сотрудничества между поставщиками компонентов и поставщиками
готовых решений.
113
Д. Моделирование стандартов в ARIS
Моделирование в ARIS представляет собой манипулирование элементами при помощи
моделей, фаз, понятий и методов ARIS с целью описания бизнес-процессов. Моделирование —
процесс творческий, и поэтому он не поддается жесткой регламентации. Однако соблюдение
некоторых стандартов дает возможность классифицировать и с пониманием использовать
разработанные ранее модели. Нелишне также установить определенные стандарты качества и
неизменно следовать им.
В этом разделе мы кратко обсудим общие принципы моделирования, а затем более
подробно уровни моделирования (уровень экземпляров, уровень типов, метауровень и мета
2
-
уровень), степени структурирования и детализации, а также различные варианты моделей.
Д.1. Общепринятые принципы моделирования
Термин «общепринятые принципы моделирования» возник по аналогии с термином
«общепринятые принципы учета» (ОППУ). Принципы моделирования обеспечивают
максимальное число степеней свободы при «прозрачном» контроле качества.
В концепции и вспомогательных инструментах ARIS заложены следующие правила,
постоянно совершенствуемые в рамках Исследовательского Проекта Правительства Германии.
Принцип корректности. Корректность моделей зависит от правильности семантики и
синтаксиса, т.]е.]от полноты и согласованности синтаксиса конкретной метамодели.
«Семантическая корректность модели определяется тем, насколько адекватно она отвечает
структуре и поведению моделируемой объектной системы». В реальных приложениях
соответствие этим требованиям можно подтвердить лишь после проведения имитационных
экспериментов или выполнения иных аналогичных шагов. Для этой цели прекрасно подходит
ARIS Toolset. Этот инструмент располагает широким набором правил для проверки синтаксиса
модели, позволяя убедиться, что каждая функция не только активизируется определенным
событием, но и в свою очередь активизирует следующее событие и]т.]д.
Принцип релевантности. Следует моделировать лишь те фрагменты реальной объектной
системы, которые соответствуют назначению модели. Модель не должна содержать
информации больше, чем необходимо. Это позволяет сохранить соотношение затраты/выгоды
на приемлемом уровне.
Принцип соизмеримости затрат и выгод. К числу факторов, определяющих
эффективность соотношения затраты/ выгоды, относятся объем усилий, необходимых для
создания модели, полезность моделирования конкретного сценария и продолжительность
использования модели.
Принцип прозрачности. «Прозрачность» гарантирует понятность и удобство модели для
пользователей. Она также определяет степень рациональности отношений между моделью и
пользователем. Поскольку модели содержат большой объем информации, относящейся к
техническим и организационным вопросам, быстро в них разобраться обычно под силу только
специалистам. При разбиении моделей на различные типы представлений (подмодели) легче
понять конкретные аспекты.
Принцип сравнимости. Модели, созданные на базе согласованной концептуальной
инфраструктуры и единого языка моделирования, сравнимы между собой, если имена объектов
отвечают установленным соглашениям и если использовались идентичные объекты
моделирования, а также эквивалентные степени детализации. В отношении моделей, описанных
разными языками, важно убедиться в сопоставимости их мета-моделей.
Принцип систематизированной структуры. Этот принцип в качестве обязательного
условия предполагает возможность интеграции моделей разных типов. Для этого требуется
единая метамодель, объединяющая различные типы представлений, что может обеспечить
информационная модель ARIS.
114
Д.2. Уровни моделирования
Концепция ARIS разработана на мета-уровне, независимом от конкретной прикладной
области (см. рис. 12). Поскольку условия, допускаемые на этом уровне, справедливы также для
уровней типов и экземпляров, концепция ARIS автоматически распространяется на уровни
моделирования, лежащие ниже.
На рис. 66 представлен пример моделей ARIS на уровне определения требований. Для
каждой модели описывается типичное понятие, связанное с понятием лежащего ниже уровня
абстракции отношением класс-элемент.
На мета
2
-уровне описывается только общее понятие «тип объекта». По отношению к
этому классу понятия, используемые на метауровне, выступают в качестве элементов.
Информационная модель ARIS разрабатывается на метауровне. Иными словами, именно здесь
определяются общие понятийные классы, описывающие бизнес-процесс, и отношения между
ними. Реальные приложения моделируются на прикладном уровне, причем информационные
системы для бизнеса обычно разрабатываются на уровне описания, что придает этим методам
моделирования особую ценность. Конкретные экземпляры моделируются на уровне
экземпляров. Все эти процессы выполняются в реальном времени.
Каждый уровень абстракции обозначен соответствующим символом (см. правую часть
диаграммы на рис. 66).
Модели обычно создаются на уровне типов в соответствии с фазами проектирования
бизнес-процесса. Это делает модели «неуязвимыми» к любым модификациям экземпляров,
например, в тех случаях, когда в модель данных включаются новые изделия или из
организационной модели удаляются отдельные сотрудники. Однако если в определенном типе
бизнес-процесса всегда присутствуют одни и те же экземпляры, то их можно использовать и
для моделирования. Такие ситуации возникают, когда некие функции выполняются только
определенным специалистом, или если многократно используется один и тот же экземпляр
данных, или если данная модель всегда связана с конкретной организационной единицей, а не с
ее типом. Именно по этой причине в некоторых моделях уровни экземпляров и уровни типов
объединяются.
Для того чтобы лучше понять уровни описания, рассмотрим процесс создания на базе
ARIS Toolset эскизного варианта некоторой стандартной модели.
Хранение и управление всеми моделями ARIS Toolset осуществляется на мета
2
-уровне.
Это делает их независимыми от конкретных методов, поскольку все описания, специфичные
для того или иного метода и модели, являются экземплярами этого общего типа объекта. Таким
образом, в ARIS Toolset можно включать новые методы моделирования, причем (как правило)
без каких-либо изменений в программе.
115
Рис. 66. Уровни моделирования ARIS
116
Рис. 67. Стандарт администрирования модели в ARIS Toolset
117
Рис. 68. Таблица типов объектов
Рис. 69. Таблица прикладных объектов
Рис. 70. Таблица типов объектов, дополненная типами экземпляров
Рис. 71. Таблица прикладных объектов, дополненная типами экземпляров
118
Рис. 72. Структурированность модели
Класс ТИП ОБЪЕКТА на мета
2
-уровне использует в качестве экземпляров объекты
метауровня, например, типы функций, типы организационных единиц, типы выходов и]т.]д. (см.
рис. 67). К каждому объекту моделирования можно применять те же операции (создание,
удаление, отображение, перемещение и представление в виде иерархии), которые определяются
в классе ТИП ОБЪЕКТА. На рис. 68 класс ТИП ОБЪЕКТА представлен в виде таблицы. Если
посредством новых методов вводятся новые объекты моделирования, то они рассматриваются
как новые экземпляры данного класса, т.]е.]представляются соответствующими строками в
таблице типов объектов.
Модели прикладного уровня являются экземплярами объектов моделирования на
метауровне. На рис. 67 это показано пунктирными линиями. Для целей хранения на мета
2
-
уровне вводится класс ПРИКЛАДНОЙ ОБЪЕКТ. Этот класс содержит все экземпляры
объектов метауровня и, следовательно, он связан с классом ТИП ОБЪЕКТА отношением *:1.
Отношения хранения представлены сплошными линиями. Линии между объектами
моделирования определяются в модели связью СОЕДИНЕНИЕ между ПРИКЛАДНЫМИ
ОБЪЕКТАМИ. Эта ситуация описана в таблице на рис. 69. В то время как «имена классов» на
метауровне являются элементами класса ТИП ОБЪЕКТА, прикладные объекты представляют
собой элементы метаклассов.
В том случае, когда модели экземпляров создаются в ARIS (например, для приложений
workflow), интерпретация мета- и мета
2
-моделей ARIS расширяется. Структура мета
2
-модели на
рис. 67, в отличие от допустимых экземпляров, не меняется. Мета
2
-модель класса ТИП
ОБЪЕКТА (см. рис. 70) включает различные описания экземпляров прикладных объектов, а
также реальные экземпляры этих прикладных объектов (см. рис. 71). Таким образом, в таблицы
вводятся не только типы приложений, но и их экземпляры. То же справедливо для связи
СОЕДИНЕНИЕ и для других связей.
Каждая модель в ARIS Toolset логически хранится в нескольких больших таблицах. Эти
таблицы реализуются в объектно-ориентированной базе данных (РОЕТ), обеспечивая более
детальные и, следовательно, более эффективные с точки зрения производительности структуры
доступа (например, к комплексным моделям).
119
Д. З. Степени структурирования и детализации
Можно создавать модели с разной степенью структурирования. В примере на рис. 72
классы данных и связи в прикладной области представлены на уровне определения требований.
Сначала диаграммы классов группируются в кластерные понятия, которые затем объединяются
в модель продаж. Все три понятийных уровня связаны отношениями 1:* -«часть целого».
Структурированность модели представлена блоками трехъярусной пирамиды (см. рис. 72).
При описании больших прикладных областей, бесспорно, необходим иерархический
подход. На рис. 73 показано, как с помощью ARIS Toolset создается иерархическое
представление в модели-прототипе логистики продаж, разработанной консультантами
компании IDS Sheer AG.
На рис. 74 представлены основные этапы структурирования модуля Business Engineer (BE)
системы SAP R/3. Крупные функциональные области (продажа, производство и]т.]д.)
конкретного вертикального рынка объединяются на уровне бизнес-сценария; уровень бизнес-
процессов охватывает альтернативные процессы для той или иной функциональной области. В
рамках альтернативного процесса представлены альтернативные функции (бизнес-функции,
участвующие в бизнес-процессе).
Более того, с помощью моделей можно описывать и различные подобласти сложного
целого. Любую модель — будь то полная корпоративная модель или одна из ее подмоделей —
можно построить в соответствии с критериями бизнеса. Это можно наглядно представить в
виде мозаики, где отдельные элементы складываются в цельную картину (см. рис. 75).
Д.4. Варианты моделей
При обсуждении вопросов, связанных с непрерывным совершенствованием процессов и
версиями моделей, мы коснулись аспекта управления вариантами моделей, которые создаются
по ходу дела и различаются по времени создания. Иногда возможно параллельное
использование нескольких вариантов модели, предназначенных для разных условий в одной и
той же ситуации. Для создания вариантов существует два основных метода:
выбор варианта на основе имеющейся базовой модели. Здесь, помимо самих объектов, из
базовой модели переносятся знания в области отношений между объектами;
конструирование варианта из общих стандартных блоков.
В системе CIM Analyzer, разработанной в 1991 году Институтом информационных систем
(IWi), функции, необходимые для деятельности предприятия, выбирались на основе
разветвленного дерева функций и совокупности бизнес-атрибутов в соответствии с известными
правилами.
120