Организационные модели

Рис. 1. Типы представлений

Типы представления являются первой компонентой архитектуры. Они позволяют структурировать бизнес-процессы и выделять их составные части, что делает рассмотрение более простым. Применение этого принципа позволяет с различных точек зрения описывать содержание отдельных частей бизнес-процесса, используя специальные методы, наиболее полно соответствующие каждой точке зрения. Это избавляет пользователя от необходимости учитывать

множество связей и соединений. В рамках каждого типа представления создаются модели, отражающие ту или иную сторону исследуемой системы.

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

Рис. 2. Уровни описания

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

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

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

Уровень спецификации проекта достигается, как только концептуальные понятия проблем бизнеса, сформулированные на уровне определения требований, трансформируются в категории, связанные с информационными технологиями. На данном уровне описываются уже не функции, а пользовательские или модульные транзакции, которые выполняют функции. Это может рассматриваться как отображение сформулированных требований в категории и методы описания, связанные непосредственно с информационными системами и выраженные в терми

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

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

На уровне описания реализации спецификация проекта трансформируется в конкретные аппаратные и программные компоненты. Таким образом, осуществляется физическая связь с информационной системой.

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

Уровень описания реализации очень тесно связан с разработкой информационной системы: на этом уровне производится многократная корректировка функционирования системы по результатам коротких циклов (тестов) ее работы.

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

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

Каждый тип представления подвергается разложению на три уровня описания: определение требований, спецификацию проекта и описание реализации (рис.3).

Рис. 3. Представления и уровни описания

Таким образом, в архитектуре ARIS зафиксирован набор видов моделей, каждая из которых «расписывается» по уровням. Вместе с описанием проблем бизнеса, которое служит стартовой точкой для анализа, они составляют набор компонент архитектуры ARIS.

2. МОДЕЛИ УРОВНЯ ФОРМИРОВАНИЯ ТРЕБОВАНИЙ

Организационные модели

На сервере LOCAL создайте новую базу данных Auto Business, в которой разместите папки, как показано на рис.4.

Рис. 4. Создание новой базы данных

Для обеспечения доступности всех моделей, реализованных в среде ARIS, включите полный методологический фильтр, используя пункт меню Вид è Параметрыè Входè как показано на рис.5 и перезапустите ARIS.

Рис. 5. Включение полного методологического фильтра

Приступим к разработке моделей. Начнем со схемы, моделирующей организационную структуру нашей компании.

Модель 1:

В окне Содержимое элемента Требования (правое окно) для папки Организационные модели используя правую клавишу мыши создайте новую модель Организационная структура (типа Организационная схема) (рис. 6)

Рис.6. Создание новой модели.

Используя панель моделирования создайте модель организационной структуры компании (рис.7). Для определения типа и назначения объектов и связей, вносимых в модель, используйте глоссарий, приведенный в приложении.

Рис. 7. Организационная структура компании

Обратите внимание, что на приведенном на рис.7 фрагменте, отсутствуют некоторые должностные единицы и сотрудники. Доработайте данную модель самостоятельно.

Функциональные модели

Модель 2:

В папке Требования для Функциональных моделей создайте новую модель Целей (типа Диаграмма целей), в которой сформируйте дерево стратегических целей компании (рис.8).

Рис.8. Дерево целей

Модель 3:

В этой же папке создайте модель Дерево функций (типа Дерево функций), в которой детально декомпозируйте функцию Продажи, как показано на рис.9.

Рис. 9 Дерево функции Продажи

Модели процессов

Концептуальному уровню представленных выше моделей соответствует модели Дерево

продуктов/услуг и Диаграмма цепочки добавленного качества.

Модель 4:

Для моделирования первой структуры создайте в папке Требования (Модели процессов) модель Продукция/услуги (тип Дерево продуктов/услуг), как показано на рис.10.

Рис. 10. Дерево продуктов/услуг

Модель 5:

Для построения модели Процесс добавления качества (типа Диаграмма цепочки добавленного качества), в той же папке создайте новую модель указанного типа (рис.11).

Рис. 11. Процесс добавления качества

Поскольку объекты моделей Дерево функций и Процесс добавления качества являются функциями, эти модели можно связать. Выберите из контекстного меню функции Продажи (диаграмма Процесс добавления качества) пункт Назначения èСоздать.В появившемся диалоге выберите опцию Существующие модели, а затем – Дерево функций.

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

Следующими концептуальными моделями процессов являются Модели управления бизнесом (тип – Диаграмма управления бизнесом) и конкуренции (тип - Модель Конкуренция ).

Диаграмма управления бизнесом описывает все потенциальные риски бизнес-процесса и управление ими. Риск означает потенциальную опасность для процесса не достигнуть желаемой цели. Управление риском — это путь исключения риска или уменьшения его степени. Решение по риску означает реализацию управления отдельным риском.

Модель конкуренции предназначена для описания связей выпускаемой продукции, партнеров и конкурентов.

Создайте отмеченные модели, как показано на рис. 12, 13.

Модель 6:

Рис. 12. Модель Риски

Модель 7:

Рис. 13. Модель Конкуренция

Модель 8:

Важнейшей моделью процессов уровня определения требований является модель Событийная цепочка процесса (Extended event driven process chain – EPC). Модель Событийная цепочка процесса отражает последовательность функциональных шагов (действий) в рамках одного бизнес-процесса, которые выполняются организационными единицами, а также ограничения по времени, налагаемые на отдельные функции.

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

Рис. 14. Событийная цепочка Процесса продаж

Создайте новую модель Процесс продаж (типа EPC) (рис.14). При формировании модели придерживайтесь следующих рекомендаций:

• процесс всегда инициируется некоторым свершившимся событием;

• процесс всегда направлен сверху вниз;

• в центре модели располагаются функции;

• справа – элементы оргструктуры (исполнители);

• слева – элементы информационных моделей (данные, которые необходимы для реализации функции;

• при определении объектов модели используйте уже имеющиеся объекты (элементы организационных и функциональных моделей);

• процесс всегда заканчивается некоторым событием.

Модель 9:

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

Диаграмма распределения функции (тип – Диаграмма распределения функции) предназначена для того, чтобы описать все объекты, которые окружают функцию, исполнителей, входные и выходные потоки информации, документы, материалы, продукты/услуги, а так же используемое оборудование. Этот тип моделей целесообразно применять для детализации функций в моделях Дерево функций или Событийная цепочка процесса, в результате чего отражаются дополнительные связи и отношения, детализирующие эту функцию на уровне данных. Откройте созданную модель Дерево функции Продажи. Для функции Обработка заказа клиента из контекстного меню (Назначения èСоздать) создайте новую модель типа Диаграмма распределения функций (рис. 15).

Рис. 15. Распределение функции Обработка заказа клиента

На рис.15 отображены сущности, информация атрибутов которых используется при выполнении функции.

Модель 10:

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

Создайте из модели Дерево функции Продажи Диаграмму ролей для функции Заключение договора, как показано на рис.16.

Рис. 16. Диаграмма ролей

Модель 11:

Следующей важной моделью на уровне определения требований является Карта знаний. Карта знаний, как правило, ориентирована на организационную структуру, т.е. соответствующая категория знаний «связывается» с каждой организационной единицей.

Откройте модель Организационная структура. Для должности Служащий КГ создайте новую модель типа Карта знаний, как показано на рис.17.

Рис. 17. Карта знаний Служащего КГ

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

Модель 12:

Откройте модель Дерево функции Продажи. Для функции Производство создайте модель типа Промышленный процесс, как показано на рис.18.

Рис. 18. Модель Производство

Модель 13:

Для создания модели типа Офисный процесс используем уже существующую модель. Откройте модель Событийная цепочка Процесса продаж. Выполните команды Правка èВыделить всё è Копировать. Создайте новую модель Процесс продаж, но с типом Офисный процесс. Выполните команду Правка è Вставить. В результате модель типа Событийная цепочка процесса трансформируется в модель типа Офисный процесс, как показано на рис.19.

Рис. 19. Модель Процесс продаж (Офисный процесс)

Модели данных

При моделировании бизнеса часто приходится иметь дело с многочисленными терминами, определяющими информационные и иные объекты в организациях. Например, то, что понимается под термином «Данные о продажах» в отделе продаж, может значительно отличаться от того, что под этим подразумевают сотрудники производственного отдела. Введение соответствующей терминологии для организации и ее подразделений позволяет сделать информацию более понятной.

Так, например, можно определить, из чего складывается понятие «Данные о продаже».

Для этого служит модель Технических терминов (тип – Модель технических терминов).

Модель 14:

Эта модель является одной из основных концептуальных моделей данных уровня определения требований. На рис. 20 приведен пример этой модели. Создайте ее в папке Требования раздела Модели данных.

Рис. 20. Данные о продаже

Модель 15:

Если Модель технических терминов описывает некоторую иерархию или вложенность понятий (данных), то Модель семантики данных (Semantic data model – SeDaM) призвана отразить смысловую взаимосвязь информационных объектов (сущностей), в которых будет храниться информация (данные). По сути дела, эта модель, как правило, представляет собой модель «сущность-отношение» на уровне сущностей. Модель семантики данных также является концептуальной моделью уровня определения требований. Создайте эту модель в той же папке, как показано на рис.21.

Рис. 21. Модель Семантика данных

Данную модель можно дополнить атрибутами сущностей, поскольку соответствующий инструментарий присутствует на панели моделирования. Однако для более детального представления структуры данных используется модель Расширенная модель «сущность - отношение» (тип модели – Extended entity - relationship model - eERM). В этой модели принято раскрывать не только семантику, но и атрибутный состав сущностей.

Модель 16:

Создайте указанную модель используя механизм Назначения èСоздать для объекта База данных, который находится в модели Событийная цепочка Процесса продаж (eEPC) (папка Требования раздела Модели процессов) (рис.22).

Рис. 22. Модель База данных

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

К основным моделям данных рассматриваемого уровня относится также Диаграмма структуры знаний (Knowledge structure diagram). Эта диаграмма, как правило, является производной от Карты знаний, рассмотренной выше.

Откройте ранее созданную модель Служащий КГ (типа Карта знаний), находящуюся в папке Требования раздела Модели процессов. Для категории Знание авто создайте новую модель типа Диаграмма структуры знаний, как показано на рис.23.

Рис. 23. Модель Знание авто

3. МОДЕЛИ УРОВНЕЙ СПЕЦИФИКАЦИИ И РЕАЛИЗАЦИИ

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

Поиск по сайту: