Д. З. Степени структурирования и детализации

 

Можно создавать модели с разной степенью структурирования. В примере на рис. 72 классы данных и связи в прикладной области представлены на уровне определения требований. Сначала диаграммы классов группируются в кластерные понятия, которые затем объединяются в модель продаж. Все три понятийных уровня связаны отношениями 1:* -«часть целого».

Структурированность модели представлена блоками трехъярусной пирамиды (см. рис. 72).

При описании больших прикладных областей, бесспорно, необходим иерархический подход. На рис. 73 показано, как с помощью ARIS Toolset создается иерархическое представление в модели-прототипе логистики продаж, разработанной консультантами компании IDS Sheer AG.

На рис. 74 представлены основные этапы структурирования модуля Business Engineer (BE) системы SAP R/3. Крупные функциональные области (продажа, производство и т. д.) конкретного вертикального рынка объединяются на уровне бизнес-сценария; уровень бизнес-процессов охватывает альтернативные процессы для той или иной функциональной области. В рамках альтернативного процесса представлены альтернативные функции (бизнес-функции, участвующие в бизнес-процессе).

Более того, с помощью моделей можно описывать и различные подобласти сложного целого. Любую модель — будь то полная корпоративная модель или одна из ее подмоделей — можно построить в соответствии с критериями бизнеса. Это можно наглядно представить в виде мозаики, где отдельные элементы складываются в цельную картину (см. рис. 75).

 

Д.4. Варианты моделей

 

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

выбор варианта на основе имеющейся базовой модели. Здесь, помимо самих объектов, из базовой модели переносятся знания в области отношений между объектами;

конструирование варианта из общих стандартных блоков.

В системе CIM Analyzer, разработанной в 1991 году Институтом информационных систем (IWi), функции, необходимые для деятельности предприятия, выбирались на основе разветвленного дерева функций и совокупности бизнес-атрибутов в соответствии с известными правилами.

Рис. 73. Иерархическое представление с помощью ARIS различных уровней модели-прототипа

Рис. 74. Иерархия модели SAP

Рис. 75. Символическое представление подмодели и полной модели

Рис. 76. Примеры инжиниринговых решений и их последствия

Рис.77. Последствия инжиниринговых решений

В системе SAP R/3 применяется расширенный подход. На уровне бизнес-сценария (см. рис. 74) функциональные области определяются на основе онлайновых вопросов и ответов. Затем таким же образом задается альтернативный процесс с «вычеркиванием» ненужных объектов в базовой модели. Далее по той же схеме определяются значения параметров для альтернативных функций в рамках процесса. Основные принципы этой процедуры были включены в систему COMET фирмы Nixdorf.

В концепции CIM Analyzer и системе SAP BE учитывается знание правил. CIM Analyzer фиксирует контекст отношений между конкретной деятельностью (например, серийным производством) и необходимыми функциями (например, поддержанием материально-производственных запасов). В системе Business Engineer условия целостности определяются на базе знания правил, а связи между функциями (например, если устаревает функция А, то устаревает и функция С) могут использоваться для упрощения оперативного выбора.

Рэмм предлагает конструктивно-ориентированный метод создания вариантов, который интегрирован в ARIS Toolset в качестве прототипа. Согласно теории Рэмма, предприятие есть результат инжиниринговых решений (см. рис. 76).

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

Таким образом, модели ARIS могут характеризоваться разными типами описаний ARIS (5 типов описаний, каждый из которых представлен на трех уровнях), разными уровнями моделирования (мета²-, мета-, типы приложения, экземпляры), разной степенью структурирования и уровнем детализации, а также описаниями вариантов.