Модель AS-IS или модель «как есть» представляет собой модель бизнес-процессов на момент обследования предприятия и строится с целью понять, как функционирует данное предприятие с позиций системного анализа. Эта модель строится с целью выявления ошибок и узких мест, а также формулировки предложений по улучшению ситуации.
Во второй главе настоящего практикума при изучении методологий и технологий проектирования мы уже строили модель этого бизнес-процесса. Поэтому в этой части пособия мы только уточним эту модель, используя полученную в процессе сбора информацию.
Контекстная модель:
Название: Реализация готовой продукции со склада.
Цель: Увеличение продаж.
Точка зрения: Начальник отдела продаж.
Входные данные: копия накладной, копия договора, заказ.
Выходные данные: требование, счет, выписка из журнала, отчет, отказ от выполнения заказа.
Управление: номенклатура крепежных изделий, текущая цена крепежных изделий, устав предприятия, положение об отделе продаж.
Механизмы: сотрудник отдела продаж.
Контекстная модель представлена на рисунке 18.
Рис.18. Контекстная диаграмма
Перейдем к построению диаграммы декомпозиции. Обработав анкеты, мы можем идентифицировать основные функции: проверка готовности заказа, организация оплаты, организация выдачи, подготовка отчетов. Диаграмма декомпозиции представлена на рисунке 19.
Рис.19. Диаграмма декомпозиции
Проанализируем интервью и рассмотрим реальную технологию работ сотрудника отдела продаж. На основании этих данных можно декомпозировать основные функции. Основная функция «Проверка готовности заказа» может быть декомпозирована на следующие действия: выборка договоров на текущую дату, прием заказов на текущую дату, сверка с журналом готовой продукции. Декомпозиция представлена на рисунке 20.
Основную функцию «Организация оплаты» можно декомпозировать на следующие действия: подсчет суммы оплаты, выставление счета, оплата счета. Основную функцию «Организация выдачи» декомпозируем так: выписка требования, сообщение на склад о подготовке товара, подготовка выписки для отдела договоров, изменение в журнале продаж. Основную функцию «Подготовка отчетов» декомпозируем на такие действия: анализ данных, выборка данных, печать отчетов. Соответствующие диаграммы представлены на рисунке 21, 22, 23.
Рис.20. Диаграмма декомпозиции A1
Рис.21. Диаграмма декомпозиции A2
Рис.22. Диаграмма декомпозиции A3
Рис.23. Диаграмма декомпозиции A4
Поскольку перед проектировщиками поставлена цель автоматизации документооборота, то, прежде чем декомпозировать процессы, имеет смысл рассмотреть модель документооборота. При этом, можно пойти двумя путями: рассмотреть отдельную модель документооборота и декомпозировать отдельные бизнес-процессы с помощью построения DFD-диаграмм.
⇐ Предыдущая567891011121314Следующая ⇒
Похожая информация:
Поиск на сайте:
Нотация ARIS Value-added Chain Diagram (ARIS VAD)
На рис. 2.30 представлена одна из важнейших нотаций ARIS - нотация ARIS VAD. Диаграмма цепочки процесса, добавляющего ценность, используется при описании бизнес-процессов организации на верхнем уровне. Как правило, консультанты, использующие ARIS, рекомендуют выделять шесть-восемь бизнес-процессов верхнего уровня и описывать их в нотации ARIS VAD. Затем выполняется декомпозиция полученных процессов верхнего уровня в нотации ARIS VAD или ARIS еЕРС.
Модели AS-IS и ТО-ВЕ
Рассмотрим объекты нотации ARIS VAD, представленные на рис. 2.30.
Основным объектом нотации ARIS VAD является Value-added chain - процесс или некоторая группа функций организации, которая служит для получения добавленной ценности. Объекты соединяются между собой пунктирной стрелкой, которая имеет тип is predecessor of («является предшественником»). Этот тип связи показывает, что один процесс - предшественник другого. Очевидно, однако, что на практике все основные процессы цикличны. Кроме того, они имеют обратные связи. Поэтому термин is predecessor of, на наш взгляд, является неудачным.
Между процессами, приведенными на рис. 2.30, могут быть отображены потоки материальных ресурсов и информации, для описания которых можно воспользоваться объектами типа Cluster и Technical term, соответственно. Для описания инфраструктуры, необходимой для выполнения процесса, в данном примере выбраны типы объектов Product/Service и Information service. Выбор типов объектов для отображения реальных потоков является в достаточной степени условным. Очень важно в начале работ по моделированию процессов определиться, какие именно типы объектов будут использованы и какие объекты реального мира они будут отображать. Так, в случае примера, приведенного на рис. 2.30, можно было бы показать все потоки (информационные и материальные) при помощи объектов типа Technical term.
На рис. 2.30 показаны также объекты Organizational unit, отображающие подразделения, выполняющие соответствующие процессы.
Объекты соединяются между собой при помощи связей определенного типа (см. рис. 2.30). Например, информационный поток, отображаемый объектом Cluster, является входящим для первого процесса и связан с ним при помощи стрелки типа is input for («является входом для»). Другой пример - тип связи executes («исполняет») между объектами Value-added chain и Organizational unit. Тип связи is used by показывает, что Product/Service используется процессом и т.д. Таким образом, в методологии ARIS важнейшим требованием является корректный выбор и дальнейшее использование связей и объектов определенного типа.
На рис. 2.31 представлен пример модели верхнего уровня, выполненный в нотации ARIS VAD. Вы уже знакомы с этим процессов. Выше, на рис. 2.16, этот же процесс представлен в нотации IDEF0.
88____________________________ ВВ. Репин, В.Г. Елиферов
Глава 2 Выбор методологии описания бизнес-процессов________________________________ 89
Принципы построения диаграммы процесса верхнего уровня в нотации ARIS VAD существенно отличаются от нотации IDEF0. Так. в нотации ARIS VAD стрелки могут входить в любую сторону объекта Value-added chain. (Напомним, что в нотации IDEF0 каждая сторона объекта Activity (функция) имеет глубоки и смысл). На рис. 2.32 представлена ситуация, возможная в нотации ARIS VAD. когда на диаграмме процесса приводится множество обратных связей, которые понятны только аналитику, создавшему модель.
Указанный недостаток нотации ARIS VAD можно исключить, заранее оговорив возможность специального использования обратных связей, как, например, на рис. 2.33. Отметим, что у специалистов по ARIS такой подход может вызвать критику, так как противоречит нотации. Но мы придерживаемся той точки зрения, что это вполне допустимо, так как модели верхнего уровня в нотации ARIS VAD реально могут быть использованы лишь в качестве простейшего способа графического изображения цепочки процесса.
Заканчивая обзор нотации ARIS VAD, еще раз акцентируем внимание на том, что указанная нотация в большей степени носит иллюстративный характер и не предназначена для создания комплексных моделей процессов верхнего уровня организации.
90 В.В. Репин, В.Г. Елиферов. Процессный подход к управлению
2.7.2. Нотация ARIS еЕРС - расширение нотации IDEF3
Нотация ARIS еЕРС (extended Event Driven Process Chain) - расширенная цепочка процесса, управляемого событиями.
Нотация разработана специалистами компании IDS Scheer AG, Германия, в частности, профессором Шеером. В табл. 2.2 приводятся основные объекты, используемые в рамках нотации.
Таблица 2,2 Основные объекты, используемые при построении диаграмм еЕРС
Помимо основных объектов, указанных в табл. 2.2, при построении диаграммы еЕРС могут быть использованы многие другие объекты. На практике применение большого числа объектов различных типов нецелесообразно, так как это значительно увеличивает размер модели и затрудняет ее прочтение.
91
Для понимания смысла нотации ARJS сЕРС рассмотрим основные используемые типы объектов и связей (рис. 2.34-2.38). На рис. 2.34 представлена простейшая модель ARIS еЕРС, описывающая фрагмент бизнес-процесса предприятия.
Из рис. 2.34 видно, что связи между объектами имеют определенный смысл и отражают последовательность выполнения функций в рамках процесса. Стрелка, соединяющая Событие 1 и Функцию 1, «активирует» (activates) или инициирует выполнение Функции 1. Функция 1 «создает» (creates) Событие 2, за которым следует символ логического оператора «И», «запускающий» выполнение Функций 2 и 3.
Внимательный анализ нотации ARIS еЕРС показывает, что она практически не отличается от нотации IDEF3. Важнейшим отличием ARIS еЕРС является наличие объекта «событие» (event). Этот объект служит для отображения в модели возможных результатов выполнения функций, в зависимости от которых выполняется та или иная последующая ветвь процесса. Нотация ARIS еЕРС называется, очевидно, расширенной именно вследствие наличия в ней объекта «событие» (в IDEF3 такого объекта нет). На рис. 2.35 приводятся примеры применения символов логики и событий при построении моделей в нотации ARIS еЕРС.
При построении моделей в ARIS еЕРС необходимо соблюдать следующие правила:
1. Каждая функция должна быть инициирована событием и завершаться
событием;
2. В каждую функцию не может входить более одной стрелки, «запускаю
щей» ее выполнение, и выходить не более одной стрелки, описывающей
завершение выполнения функции.
Кроме этих правил, существуют и другие важные требования к формированию моделей в ARIS. Их можно изучить с помощью методического материала «Методы ARIS». который устанавливается на компьютер одновременно с демо-версией продукта, а также в .
На рис. 2.36 показано применение различных объектов нотации ARIS еЕРС при создании модели бизнес-процесса.
92____________________________ ВВ. Репин, В.Г. Елиферов. Процессный подход к управлению
Из рис. 2.35 и 2.36 видно, что бизнес-процесс в нотации ARIS еЕРС представляет собой последовательность процедур, расположенных в порядке их выполнения. Следует отметить, что реальная длительность выполнения процедур в ARIS еЕРС визуально отражена быть не может. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено вы-
Глава 2 Выбор методологии описания бизнес-процессов___________________________________ 93
полнение двух задач одновременно. Используемые при построении модели СИМ-ЮЛЫ логики позволяют отразить ветачение и слияние бизнес-процесса. Для получения информации о реальной длительности процессов и визуального отображения загруженности персонала в процессе можно использовать другие инструменты описания, например диаграммы Гантта в системе MS Project.
Рассмотрим примеры применения нотации ARIS еЕРС для описания бизнес-процессов. На рис. 2.37. представлен бизнес-процесс обработки заказа клиента. Этот же процесс изображен в нотации IDEF3 на рис. 2.23.
Процесс начинается с события «Поступил заказ клиента». Это событие инициирует функцию «Выполнить учет заказа в системе», которую выполняет менеджер Отдела сбыта. Для выполнения работы он использует «Систему учета заказов». Результат выполнения функции отображается событием «Учет заказа выполнен». После этого менеджер Отдела сбыта выполняет функцию «Выполнить анализ на соответствие номенклатуре». Результатом выполнения функции являются два альтернативных события «Заказ соответствует номенклатуре» и «Заказ не соответствует номенклатуре». Процесс ветвится. Для отображения ветвления процесса используется символ логического оператора - исключающее «ИЛИ».
Функция «Уведомить клиента о невозможности выполнения заказа» может выполняться в двух случаях: 1) заказ не соответствует номенклатуре и 2) производство невозможно. Для отображения на схеме процесса этих вариантов используется символ логического оператора «ИЛИ» и т.д.
Как видно из рис. 2.37, схема процесса в ARIS еЕРС отличается от схемы в IDEF3 наличием объектов: событий, документов, прикладных систем и должностей. Схема в ARIS eEPS визуально предстаатяется более информативной и воспринимается лучше, однако размер этой схемы существенно превышает размер схемы в IDEF3.
Рассмотренный выше процесс может быть представлен также в нотации ARIS PCD (Process Chain Diagram) - разновидности ARIS еЕРС. На рис. 2.38 показан бизнес-процесс обработки заявки клиента в нотации ARIS PCD. При описании этого процесса использованы все объекты, которые составляют процесс, показанный на рис. 2.37, но расположены они в виде столбцов таблицы. В первом столбце представлены события и некоторые символы логики, во втором - функции, в третьем - входящие и исходящие документы, в четвертом - виды прикладного программного обеспечения, в пятом - должности сотрудников, задействованных в процессе. Такое представление процесса является более «стандартным». Оно лучше подходит для целей документирования процессов. Однако представление в нотации ARIS PCD обладает существенным недостатком - его можно эффективно применять для простых (не более пяти-восьми функций), желательно линейных, процессов. Сложные процессы с разветвленной логикой отображать при помощи нотаций ARIS PCD неудобно, что наглядно видно на рис. 2.38.
94_________________________________ ВВ. Репин. В.Г. Елиферов. Процессный подход к управлению
Рис. 2.37. Пример модели процесса
Глава 2 Выбор методологии описания бизнес-процессов_______________________________ 95
в нотации AR1S eEPC.
96____________________________ В.В, Репин, В.Г. Елиферов. Проц ессный подход к управлению
Рис. 2.38. Пример обработки
Глава 2 Выбор методологии описания бизнес-процессов 9 7
заявки и нотации AR1S PCD.
98 В.В. Репин, В Г. Елиферов Процессный подход к управлению
Нотация AR1S Organizational Chart
Нотация ARIS Organizational Chan яа!яется одной ИЗ основных нотаций ARIS и предназначена для построения схем организационной структуры предприятия. Как правило, эта модель строится в начале проекта по моделированию бизнес-процессов. В модели отражаются существующие подразделения предприятия в виде иерархической структуры, как показано на рис.
Модель строится из объектов Organizational unit, Position, Internal person и др.
Заложенные в нотацию типы связей позволяют отразить различные виды отношений между объектами организационной структуры. В представленном на рис. 2.39 примере Предприятие управляется Директором, при этом используется тип связи is Organization Manager for. Иерархия подразделений строится при помощи связей типа is composed of. Кроме того, могут быть указаны должности - Position и фамилии реальных сотрудников, их занимающие - Internal person, тип связи occupies.
Кроме моделей иерархии подразделений, могут быть построены модели иерархии подчиненности в проектных командах, группах и т.д. Все отраженные в моделях объекты можно использовать в дальнейшем при формировании моделей бизнес-процессов. При построении сложных иерархических структур может быть применена декомпозиция, например, структуру подразделения возможно представить более детально.
Глава 2 Выбор методологии описания бизнес-процессов_________________________________ 99
Предыдущая78910111213141516171819202122Следующая
Модель AS-IS
– это модель «как есть», т.е. модель уже существующего процесса/функции. Обследование процессов является обязательной частью любого проекта создания или развития системы. Построение функциональной модели AS-IS позволяет четко зафиксировать, какие процессы осуществляются на предприятии, какие информационные объекты используются при выполнении функций различного уровня детализации.
На основе модели AS-IS
достигается консенсус между различными этапами процесса по тому, «кто что сделал» и что каждый этап добавляет в процесс. Функциональная модель AS-IS является отправной точкой для анализа потребностей предприятия
, выявления проблем и “узких” мест и разработки проекта совершенствования деловых процессов. Модель AS-IS позволяет выяснить, «что и как мы делаем сейчас» перед тем, как определить то, «что и как будет делаться завтра». Анализ функциональной модели AS-IS позволяет понять, где находится проблемная ситуация, в чем будут состоять преимущества новых процессов и каким изменениям подвергнется существующая структура организации процесса. Исследование необходимости реструктуризации
(выявление и ликвидация недостатков) в существующих процессах достигается за счет применения декомпозиции (анализа), производящаяся даже там, где функциональность на первый взгляд является очевидной.
Функциональная модель AS-IS
Так, например, признаками неэффективности существующих процессов могут быть:
- бесполезные, неуправляемые и дублирующиеся функции;
- неэффективный документооборот (нужный документ не оказывается в нужном месте в нужное время);
- отсутствие обратных связей по управлению (на проведение функции не оказывает влияния ее результат), входу (объекты или информация используются нерационально) и т. д.
При создании модели AS-IS неопытным аналитиком может возникать достаточно распространенная ошибка — это создание идеализированной модели, особенно в том случае, когда модель создается под влиянием знаний (точки зрения) руководителя. Обычно руководитель знаком с тем, как предполагается выполнение функции по руководствам и должностным инструкциям и часто не знает, как на самом деле подчиненные выполняют требуемые функции. Поэтому могут создаваться модели, называемые SHOULD BE (как должно бы быть), и несущие ложную информацию и которую невозможно в дальнейшем использовать для анализа.
BPMN (Business Process Management Notation) – это язык моделирования бизнес-процессов, который является промежуточным звеном между формализацией/визуализацией и воплощением бизнес-процесса.
Говоря проще, такая нотация представляет собой описание графических элементов, используемых для построения схемы протекания бизнес-процесса.
Как минимум, такая схема нужна, чтобы выстроить в соответствии с ней бизнес процесс и понятно регламентировать его для всех участников.
Как максимум, позволяет впоследствии провести автоматизацию бизнес-процессов в соответствии с имеющейся схемой.
История возникновения BPMN
Первая версия нотации BPMN вышла в мае 2004 года (BPMN 1.0). Следующая версия появилась в январе 2011 года (BPMN 2.0). Наконец, в январе 2013 года компания OMG выпустила ту версию, которая в основном используется и сегодня – BPMN 2.0.2.Основные графические элементы BPMN
BPMN-процесс – это любой бизнес-процесс, отражённый с помощью нотации. Процессы состоят из элементов, каждый из которых обозначается на схеме специальным значком.Элементы нотации BPMN – это элементы графической схемы, но также и элементы самого бизнес-процесса.
Нотация опирается на следующие базовые графические элементы:
- Пул и Дорожки
- Действия
- Шлюзы или Развилки
- События
- Потоки
- Артефакты
BPMN элементы “Пул” и “Дорожка”
Весь бизнес-процесс состоит из пулов: совокупности операций + лиц, которые эти операции выполняют.
Например, пулом окажется весь набор действий по погрузке товара и отправке его клиенту.
При этом выделяют так называемые “дорожки”, из которых состоит любой пул. Для нашего примера одной из дорожек станет оформление документов, касающихся погрузки и отправки товара, второй дорожкой – физическая погрузка нужной партии на автомобиль и поездка автомобиля к клиенту. Обе эти дорожки дополняют одна другую, проходят параллельно, но в целом служат выполнению одного и того же этапа бизнес-процесса.
BPMN элемент “Действие”
Под “действием” понимается единица работы, выполняемой в ходе исполнения бизнес-процесса. Действия могут быть как элементарными (задача/task), так и составными (подпроцесс/sub-process).
Есть несколько типов элементарных действий, которые отличаются условиями выполнения:
- Многократное выполнение действия в рамках одного процесса. Например, одно и то же действие может выполняться параллельно для каждого товара в заказе клиента.
- Циклическое действие выполняется многократно, пока заданное условие верно.
Абстрактная задача | Используется для обозначения простого действия или операции, не имеющей дальнейшей декомпозиции в рамках текущего бизнес-процесса. | |
Подпроцесс | Используется для отображения декомпозированного процесса, включенного в состав рассматриваемого процесса. Подпроцесс описан более подробно на своей диаграмме. | |
Процесс-ссылка | Используется для обозначения ссылки на один из наиболее часто повторяющихся процессов. |
Пользовательская задача | Используется для отображения задачи, которую выполняет человек. | |
Задача на выполнение сценария | Используется для отображения шага процесса, по достижении которого автоматически выполняется скрипт. | |
Задача на вызов сервиса | Используется для иллюстрации шага процесса, на котором вызывается веб-служба или скрипт С#. | |
Встроенный кейс | Используется для представления нестандартной задачи, курируемой ответственным лицом или группой лиц. Кейсы используются, когда нужно быстро организовать в рамках процесса неструктурированную или слабоструктурированную активность. |
BPMN элементы “Развилка” или “Шлюз”
Под шлюзами понимаются элементы, определяющие ветвление и слияние потоков работ.BPMN описывает 7 типов развилок. В качестве основных выделяют 2 типа:
Шлюз исключающего «или» | Используется для создания альтернативных потоков процесса или сходящихся потоков управления. | |
Параллельный шлюз | Используется для создания параллельных путей без оценки какого бы то ни было условия или для сходящихся потоков и синхронизации параллельных веток выполнения процесса. |
Пример использования шлюза исключающего «или» для создания альтернативных потоков процесса:
- Этап 7. Звонок клиенту с целью оценить качество обслуживания.
- 1. Если клиент доволен, фиксация положительной оценки, закрытие бизнес-процесса.
- 2. Если клиент недоволен, выяснение причины.
Фактически, шлюзы являются одними из самых ответственных и сложных этапов бизнес-процессов. От того, насколько грамотно будут прописаны все условия и следствия по принципу “Если… то”, во многом зависит эффективность работы всей системы.
BPMN элемент “Событие”
“Событие” является одним из главных элементов BPMN и служит для описания того, что должно случиться (в отличие от задачи, когда что-то должно быть сделано). Событием может быть, например, подписание договора, или разговор с клиентом.
Графические элементы событий в BPMN классифицируют двумя способами:
- В зависимости от положения события на схеме процесса:
Начальное событие (инициирующее бизнес-процесс) | |
Промежуточное событие | |
Конечное событие (заканчивающее бизнес-процесс). |
- По типу события классификация следующая:
Простое событие | Представляет не типизированное событие. | |
Событие-сообщение | Показывает отправку или получение сообщения. | |
Событие-таймер | Используется для моделирования регулярных событий. Также таймер может использоваться для моделирования моментов времени, временных промежутков и превышения лимита времени. |
BPMN элементы “Потоки”
Поток – это последовательность действий, которая обозначается стрелкой. Элемент “поток” показывает какое действие после какого необходимо совершить.Поток управления | На стандартный поток управления не воздействуют условия и он не проходит через шлюзы, т.е. является неконтролируемым. | |
Условный поток управления | Используется для того, чтобы показать, что дальнейшее выполнение процесса будет происходить по определённому потоку только в том случае, если выполнятся заданное условие. Ромбик у основания стрелки добавляется, если условный поток управления является исходящим от процесса. Ромбик не добавляется, если условный поток управления является исходящим от шлюза. | |
Поток управления по умолчанию | Используется тогда, когда необходимо показать, что дальнейшее выполнение процесса будет происходить по определённому потоку только если не выполняется ни одно из заданных условий. | |
Поток сообщений | Используется для отображения межпроцессного взаимодействия – отображает передачу сообщений или объектов из одного процесса в другой процесс или внешнюю ссылку. | |
Ассоциация | Применяется для визуализации связи между элементами потока и объектами, не являющимися элементами потока (артефактами). |
BPMN элементы “Артефакт”
Под артефактами в BPMN понимают объекты, которые не влияют на исполнение бизнес-процесса напрямую. Это могут быть документы, данные, информация.Основные виды артефактов:
Группа объектов | Используется для группировки графических элементов, принадлежащих одной и той же категории и позволяет повысить простоту восприятия диаграммы. | |
Текстовая аннотация | Применяется для уточнений к диаграмме – комментариев и пояснений, которые увеличат читабельность диаграммы. | |
Объект данных | Используется для отображения информации о данных, которые обрабатывается в ходе процесса. |
Преимущества BPMN
BPMN-описание бизнес процесса имеет несколько преимуществ.Первое – простота трансляции диаграмм в исполняемые модели с помощью языка формального описания бизнес-процессов.
Описание элементов BPMN является понятным для большинства участников бизнес-процессов и часто не требует никаких дополнительных разъяснений. С помощью простого графического выражения можно составить конкретные регламенты, которые будут исполняться сотрудниками.
Наряду с тем, что описание нотации BPMN 2.0 позволяет добиться понимания сотрудниками того, как происходят бизнес-процессы, данную нотацию поддерживают большинство современных инструментов бизнес-моделирования, что позволяет импорт готовых схем бизнес-процессов в BPM-системы.
Елена Гайдукова, маркетолог-аналитик, бренд-менеджер решений на базе , специалист по партнёрским отношениям.
«В какой нотации нам лучше строить свои бизнес-процессы? » — довольно частый и один из самых странных вопросов, которые мне приходилось слышать. Дело в том, что выбор нотации для бизнес-моделирования целиком и полностью зависит от целей и задач предприятия, которое решило перейти к процессному управлению.
Ещё раз об IDEF0
Именно нотация IDEF0 до сих пор остаётся горячо любимой среди консультантов и бизнес-аналитиков. Большинство семинаров и тренингов по процессному управлению сегодня проводятся на базе данной нотации, хотя лично я своё мнение по этому поводу уже высказал в статье « ».
IDEF0 хорошо подходит для построения процессов верхнего уровня, то есть для отображения логического взаимодействия между работами. При этом диаграмму можно декомпозировать, то есть каждый отдельный элемент можно представить в виде новой схемы взаимодействий, детализирующих выбранный блок. Благодаря отображению на диаграмме не только входов и выходов, но и «управления» и «механизма», существуют возможность проследить за движением и преобразованием ресурсов в ваших процессах.
К сожалению многие бизнес-консультанты не осознают, что при всех достоинствах IDEF0 её неразумно использовать для построения процессов нижнего уровня, детализирующих подробное выполнение работ персоналом (WorkFlow). Во-первых, нотация IDEF0 не способна отобразить временную последовательность выполнения работ, а во-вторых, не содержит блоков условного перехода, поэтому все процессы будут описывать работы лишь линейно, и недостаточно детализировано.
Вывод: нотация IDEF0 подходит для построения процессов верхнего уровня, с целью отображения взаимодействий между подразделениями и движения ресурсов.
BPMN – новый взгляд на процессы
BPMN – относительно новая нотация, первая версия которой появилась в 2005 году. Нотация ориентирована на детальное описание потоков работ, и наилучшим образом подходит для моделирования процессов на нижнем уровне. Нотация BPMN обладает одной ключевой особенностью — все диаграммы, построенные с соблюдением спецификации BPMN могут быть «выполнены» системой в режиме реального времени.
При выполнении процесса, создаётся его «экземпляр» и руководитель или владелец процесса может в реальном масштабе времени контролировать выполнение задач.
Возможность «выполнения» процессов сервером требует достаточно высокой квалификации специалиста по моделированию процессов и достаточной детализации процесса. Например, если бизнес-аналитик не предусмотрел соответствующего перехода или возможности возврата к предыдущей функции, то на определенном этапе процесс может «застопорится» и не выполнится, что приведёт к необходимости внесения изменений в процесс и повторного его запуска.
При всех её достоинствах нотация BPMN достаточно сложна для использования в целях регламентации, например, для описания всех функций персонала с целью анализа и генерации должностных инструкций, положений о подразделении и регламентов процессов.
Вывод: нотация BPMN наилучшим образом подходит для моделирования лишь ключевых процессов предприятия, для дальнейшего контроля их исполнения в реальном масштабе времени.
FlowChart – назад к основам
На самом деле нотации с таким названием не существует, имеется множество вариаций на тему обычной блок-схемы, например, Basic FlowChart, Сross Functional Flowchart и т.д.. Все эти нотации позволяют описывать потоки работ и распределять ответственность за выполняемые функции внутри процесса. Множество программных продуктов используют разновидности этих нотаций для описания процессов нижнего уровня в дополнение к описанию процессов верхнего уровня при помощи IDEF0.
Специалисты по бизнес-моделированию могут сами определять степень детализации подобных диаграмм, жестких требований к описанию схем процессов не существует, так как данные диаграммы не предназначены для исполнения системой в масштабе реального времени.
Очень часто данные нотации применяются в специализированных системах бизнес-моделирования для построения единой цельной процессной модели предприятия с привязкой к организационной структуре. Разработчики ПО также часто вводят дополнительные блоки для обозначения ресурсов, документов и т.д.
Вывод: простота моделирования процессов в нотациях FlowChart делает их идеальными кандидатами на использование в системах бизнес-моделирования с целью дальнейшей автоматической генерации регламентирующей документации: должностных инструкций, положений, регламентов.
eEPC – мы пойдём своим путём
Авторами нотации eEPC является известная немецкая фирма IDS Scheer AG. Как и нотации на базе FlowChart, eEPC предназначена для описания процессов нижнего уровня, вот только в основе неё лежат не функции персонала, а события, которые в свою очередь уже инициируют выполнение какого-либо действия со стороны персонала. Из-за данной особенности стандартные процессы получаются почти в два раза больше по сравнению с их аналогами, описанными в нотации FlowChart.
Функциональность нотации eEPC является избыточной для среднестатистического пользователя, использовать все доступные блоки не имеет смысла, поэтому, как правило, при разработке процессной модели в нотации eEPC пользователи предварительно составляют специальный документ (соглашение о моделировании), в котором заранее оговаривают, какие блоки будут использоваться в процессной модели предприятия.
Вывод: нотация eEPC может применяться для построения процессов нижнего уровня, если по каким-либо причинам более простая в использовании нотация FlowChart не удовлетворяет требований предприятия к глубине описания модели.
Разумеется, данная заметка не презентует на полноту изложения и не раскрывает особенности использования каждой нотации в отдельности, зато надеюсь, что после прочтения данной статьи, вопросов в стиле «Что нам выбрать BPMN или IDEF0? » станет меньше.
3.2. Нотации создания бизнес процессов
Модель - это отображение, какого либо процесса, создаваемое для решения задач. Для создания моделей используются специализированные языки, такие как графика, схемы, таблицы или текстовые описание и называются «нотацией» описания бизнес процесса.
Под методологией (нотацией) создания модели (описания) бизнес-процесса понимается совокупность способов, при помощи которых объекты реального мира и связи между ними представляются в виде модели. Для каждого объекта и связей характерны ряд параметров (атрибутов) отражающих определенные характеристики реального объекта (номер объекта, название, описание, длительность выполнения (для функций), стоимость и др.).
Модель бизнес-процесса - прикладное представление (в заданной нотации) исполняемых предприятием работ.
В практике деятельности предприятий применяются модели разной направленности:
модель бизнес-процессов верхнего уровня - агрегированная, наиболее общая модель бизнес-процесса предприятия;
модель бизнес-процесса алгоритмическая, отражающая состав и логику выполнения предприятием работ при его реализации;
модель бизнес-процесса потоковая, отражающая материальные, финансовые и информационные потоки объектов;
модель бизнес-процесса функциональная, отражающая функциональный состав бизнес-процесса, закрепление функций процесса за исполнителями.
В современных условиях модели стали рассматриваться как новый вид регламентационных документов. В тех случаях, когда модель разрабатывается с помощью специальной программы, ее применяют как электронный регламент. А в части применения подобных моделей стала развиваться специальная методология - бизнес-инжиниринг.
Формы описания бизнес-процесса:
текстовая;
табличная;
алгоритмическая.
Для детализации процесса текстовое описание дополняется описанием в виде таблицы или алгоритмической схемы.
Применение табличной формы (рис.3.2) делает описание процесса четким и упрощает его восприятие. Каждый параметр процесса отражается в отведенном столбце таблицы, а не «размывается» в тексте.
Описание бизнес-процесса |
Ответственный исполнитель |
Входная информация |
Срок исполнения |
Исходящая документация результат |
Потребитель результата бизнес-процесса |
Рис. 3.2. Пример табличного представления бизнес-процесса
Использование алгоритмических схем (рис. 3.3; 3.4) целесообразно в случаях, когда последовательность выполнения бизнес-процесса (подпроцессов, процедур) допускает вариантность исполнения (последовательное выполнение сочетается с параллельным, ветвление процесса и т. д.). Алгоритмические схемы призваны отобразить логическую связь процессов, к тому же они более наглядные и «читаемые».
Использовать исключительно одну форму - текстовую, табличную или алгоритмическую - нецелесообразно. Текстовая форма не столь наглядная и не структурированная, в табличной трудно отразить логическую и временную взаимосвязь процессов и поэтому трудно обойтись без алгоритмической схемы.
Если применять только алгоритмическую схему, на ней необходимо будет указать все существенные параметры процесса - исполнителей, входы, выходы, поставщиков, клиентов и т. д. В результате схема получится громоздкой и «трудночитаемой», что снизит ее практическую ценность.
Для составления алгоритмических схем используют специальные графические элементы (рис. 3.5), совокупность которых определяет нотацию моделирования. Наиболее популярными для описания бизнес-процессов являются: алгоритмическая блок-схема, Basic Flowchart, Cross-Functional Flowchart, Event-driven Process Chain,
IDEFO, 1DEF3, Data Flow Diagrams, Work Flow Diagram. Выбор нотации моделирования зависит от его целей и от программного продукта, применяемого для этого. Обычно используют 3^1 и более нотаций.
Наиболее распространенные нотации детализации (способы описания бизнес-процессов) - это представление процессов как алгоритмов в виде блок-схем и описание процесса в виде потока объектов. Под потоком объектов понимается информация, документы, другие ресурсы.
Понятие модели
Модель
представляет искусственный, созданный человеком объект любой природы (умозрительный или материально реализованный), который замещает или воспроизводит исследуемый объект.
Процесс построения, изучения и применения моделей называется моделированием.
Модель
— упрощенный, приближенный образ, который отражает наиболее существенные (с точки зрения цели моделирования) свойства оригинала.
Соответствие модели оригиналу называется адекватностью модели.
Адекватность включает требования полноты и точности (правильности). Требования должны выполняться в той мере, которая достаточна для достижения цели.
Для одного и того же объекта может быть построено множество различных моделей, отвечающих различным целям.
Модель внешнего вида часов
Структурная схема часов
Виды подобия: прямое (макет, фотография), косвенное (подобие по аналогии), условное (на основе соглашений).
Процесс моделирования имеет свойство динамичности: модели развиваются, уточняются, переходят одна в другую.
Классификация моделей
Познавательные (объяснительные) модели
отражают уже существующие объекты.
Нормативные (прагматические) модели
отражают объекты, которые должны быть осуществлены.
Градации нормативных моделей: от референтной (для целого класса объектов) до модели конкретного объекта.
Статические модели
не учитывают временной фактор.
Динамические модели
отражают изменения объекта, происходящие с течением времени. Динамическая модель сама может быть статична или находиться в динамике (имитационная модель).
Материальные модели
построены из реальных объектов.
Абстрактные модели
— это идеальные конструкции, выполненные средствами мышления, сознания.
Декларативные модели
отражают свойства, структуры, состояния объектов.
Процедурные модели
отражают процедурное, операционное знание.
Детерминированные модели
отражают процессы и явления, не подверженные случайностям.
Стохастические
– отражают случайные процессы, описываемые вероятностными характеристиками и статистическими закономерностями.
Формализованные модели
могут не иметь смысловой интерпретации.
В содержательных моделях
сохраняется семантика моделируемого объекта.
Языки описания моделей
Языки описания моделей: аналитические, численные, логические, теоретико-множественные, лингвистические, графические.
Графические модели (схемы, диаграммы, графики, чертежи)
– наглядны.
Нотация
- система условных обозначений (знаков) и правил их использования, принятая в конкретной методологии.
Требования к нотации:
- простота - простой знак предпочтительнее сложного;
- наглядность - хотя бы отдаленное сходство с оригиналом;
- индивидуальность - достаточное отличие от других обозначений;
- однозначность - нельзя обозначать одним символом различные объекты;
- определенность - четкие правила использования модели;
- учет устоявшихся традиций.
В модели бизнеса отражают:
- функции, которые бизнес-система должна выполнять — что она делает, для кого, с какой целью;
- процессы, последовательность отдельных шагов процессов (работ, операций);
- организационные структуры, обеспечивающие выполнение процессов;
- материальные и информационные потоки, возникающие в ходе выполнения процессов;
- данные, необходимые при выполнении процессов, и отношения между этими данными.
Методы моделирования бизнеса
Основаны на последовательной декомпозиции системы на все более мелкие подсистемы.
Принципы структурного подхода:
- «разделяй и властвуй» — разбиение сложных проблем на множество меньших задач, легких для понимания и решения;
- иерархическое упорядочивание – организация составных частей проблемы в иерархические древовидные структуры.
Две группы методов: моделирующие функциональную структуру и структуру данных
Наибольшее распространение получили методологии:
- IDEF0 – функциональные модели, основанные на методе SADT;
- IDEF1X – диаграммы данных «сущность-связь» (ERD);
- IDEF3 - диаграммы потоков работ (Work Flow Diagrams);
- DFD - диаграммы потоков данных (Data Flow Diagrams).
Предназначены для создания моделей систем с целью их последующей реализации в виде объектно-ориентированных программ
Наиболее известные методы:
- Booch’93 Г. Буча,
- OMT Дж. Румбаха
- OOSE А. Джекобсона
- UML (Unified Modeling Language) – на основе Booch’93, OMT, OOSE
Главным структурообразующим элементом является объект.
В программировании объект
— это структура, объединяющая данные и процедуры.
В модели бизнеса объекты
– это участники бизнес-процесса (активные объекты) и пассивные объекты (материалы, документы), над которыми выполняют действия активные объекты.
Позволяют имитировать на компьютере (с помощью специальных программ) процессы функционирования реальной системы (в режиме сжатого времени или пошаговом режиме).
Наиболее распространенные методы:
- сети Петри и раскрашенные сети Петри (CPN, Colored Petri Nets);
- GPSS (General Purpose Simulating System) – унифицированный язык имитационного моделирования;
- SIMAN (SIMulation ANalysis) – язык визуального моделирования.
Интегрированные методы моделирования объединяют различные виды моделей
– структурного анализа, объектно-ориентированные, имитационные и др.
- ARIS (Architecture of Integrated Information System) позволяет отражать в единой интегрированной модели: оргструктуры, функции, данные, процессы. Использует множество типов моделей.
- G2 — методология создания динамических интеллектуальных систем позволяет моделировать процессы с использованием знаний эксперта.
- BRM (Business Rules Management) – методология управления бизнес-правилами.
Структурные методологии
базируется на методе SADT (Structured Analysis and Design Technique) Росса, предназначенном для структурированного представления функций системы и анализа системных требований.
IDEF0-модель
состоит из диаграмм и фрагментов текста. На диаграммах все функции системы и их взаимодействия представлены как блоки (функции) и дуги (отношения).
Основные элементы модели:
- Функциональный блок (Activity) – преобразование (активность);
- Выходы (Output) – результат преобразования;
- Входы (Input) — объекты, которые преобразуются в Выходы;
- Управление (Control) — информация, как происходит преобразование;
- Механизм (Mechanism) – объекты, осуществляющие преобразование.
Функциональный блок
может быть декомпозирован — представлен в виде совокупности других взаимосвязанных блоков, которые детально описывают исходный блок.
Таким образом, IDEF0-модель состоит из
набора иерархически связанных диаграмм
На диаграмме блоки соединяются дугами: выходные дуги одних блоков могут являться входами (управлением, механизмом) других.
Дуги с одним свободным концом имеют источник или получатель вне диаграммы. Для обозначения внешних дуг используются буквы:
- I (Input),
- C (Control),
- O (Output) и
- M (Mechanism).
Типы связей между блоками:
Методология IDEF3
IDEF3-модели используются для документирования технологических (информационных) процессов, где важна последовательность выполнения процесса
Выделяют четыре элемента IDEF3-модели:
Единица работы
— отображают действия, процессы, события, этапы выполнения работ. Единица работы может иметь только один вход и один выход
Ссылки (Referents):
необходимые элементы для выполнения процесса (сырье, материалы);
результат процесса (изделие);
активаторы процесса (клиент, поставщик).
Связи (Links)
, которые бывают двух типов:
передают действия от одной единицы работ к другой
соединяют ссылку с единицей работ (активируют единицу работ)
Перекрестки (Junctions)
– элементы модели, за счет которых описывается логика и последовательность выполнения этапов процесса.
Бывают двух видов:
перекрестки слияния – Fan-in
Типы перекрестков
выходной процесс запустится, если завершились все входные процессы
после завершения входного процесса запустятся все выходные процессы
выходной процесс запустится, если завершились одновременно все входные процессы
после завершения входного процесса запустятся все выходные процессы, причем запустятся одновременно
выходной процесс запустится, если завершится один или несколько входных процессов
после завершения входного процесса запустятся один или несколько выходных процессов
выходной процесс запустится, если завершились один или несколько входных процессов, причем завершились одновременно
после завершения входного процесса запустится один или несколько выходных процессов, причем запустятся одновременно
выходной процесс запустится, если завершился только один входной процесс
после завершения входного процесса запустится только один выходной процесс
Правила создания перекрестков
- Каждому перекрестку слияния должен предшествовать перекресток ветвления.
- Перекресток слияния «И» не может следовать за перекрестком ветвления типа синхронного, асинхронного или исключающего «ИЛИ».
- Перекресток слияния типа исключающего «ИЛИ» не может следовать за перекрестком ветвления типа «И».
- Перекресток, имеющий одну стрелку на одной стороне, должен иметь более одной стрелки на другой.
- Перекресток не может быть одновременно перекрестком слияния и ветвления. В ситуации, когда необходимо одновременно осуществить слияние и разветвление потоков работ, вводится каскад перекрестков.
Правило относительно единиц работ
В блок может входить и из блока может выходить только одна связь последовательности. Для отображения множества входов и выходов используются перекрестки.
Разрешается множественная декомпозиция работ:
для одной и той же работы может быть создано несколько диаграмм декомпозиции (для описания разных вариантов реализации работы).
Номер работы А13.1.2 означает:
родительская работа имеет код А13,
номер декомпозиции – 1
номер работы на текущей диаграмме – 2.
Методология DFD
Диаграммы потоков данных DFD позволяют эффективно и наглядно описать процессы документооборота и обработки информации.
Используются две нотации: Йордана и Гейна-Сарсона
Типы структурных элементов (в нотации Гейна-Сарсона):
1. Процессы (функции, операции, действия)
, которые обрабатывают и изменяют информацию. Процессы показывают, каким образом входные потоки данных преобразуются в выходные
2. Потоки данных
, которые обозначают взаимодействие процессов с внешним миром и между собой. Поток данных соединяет выход процесса (объекта) с входом другого процесса (объекта).
3. Хранилища данных
— представляют собой собственно данные, к которым осуществляется доступ. Эти данные могут быть созданы или изменены процессами.
4. Внешние сущности
— определяют внешние элементы, которые участвуют в процессе обмена информацией с системой. Внешние сущности изображают входы в систему (источники информации) и/или выходы из системы (приемники информации). Примеры: заказчик, персонал, поставщик, клиент, склад, банк
Пример:
Объектно-ориентированный язык UML
Язык UML
был разработан для создания моделей информационных систем (ИС) с целью их последующей реализации в виде объектно-ориентированных программ.
Все представления о модели сложной системы фиксируются в виде диаграмм -специальных графических конструкций (схем, графов).
Имеется 8 основных типов диаграмм UML, отражающих различные аспекты: процессы, выполняемые системой (предоставляемые пользователю сервисы), последовательность выполняемых системой алгоритмических операций,
структуру программных объектов, их взаимодействие (обмен сообщениями) и т.д.
В настоящее время язык UML применяется не только для создания ИС, но и для анализа и перепроектирования бизнес-процессов:
вместо моделей процессов ИС строятся модели бизнес-процессов,
вместо программных объектов в моделях отражаются объекты бизнес-процессов (исполнители, продукция, услуги и т.д.),
вместо окружения ИС (пользователей ИС) моделируется окружение бизнеса (поставщики, партнеры, клиенты).
Отражает основные бизнес-процессы, их взаимодействие с окружением.
Начинается с построения внешней диаграммы (вариантов использования — Use Case Diagram), показывающей, как бизнес виден извне
— субъект окружения бизнеса. Примеры акторов: Клиент, Покупатель, Поставщик, Партнер, Акционер, Заказчик.
— относительно законченная последовательность действий в рамках некоторого бизнес-процесса, приносящая ощутимый результат конкретному актору.
Примеры прецедентов: Производство продукта Продажа продукта, Сервисное обслуживание, Разработка продукта, Маркетинг и сбыт.
Экземпляр (реализация) прецедента – конкретный вариант хода событий класс прецедентов — обобщенный прецедент.
Для акторов тоже различают понятия класса и экземпляра.
Акторы разных классов могут иметь общие характеристики или общие обязательства.
Можно ввести обобщенный класс акторов.
Между прецедентами и акторами устанавливаются отношения коммуникации
(отношения ассоциации со стереотипом communicate).
Они моделируют взаимосвязи прецедентов с окружением (информационные и материальные потоки)
Между прецедентами, как правило, устанавливаются только отношения зависимости а также отношения, структурирующие прецеденты – отношения обобщения, включения (зависимости со стереотипом include), расширения (зависимости со стереотипом extend).
Для каждого из элементов модели составляется спецификация.
В спецификации актора: наименование, стереотип (business actor), описание, список атрибутов, список обязательств и др.
В спецификации прецедента: наименование, стереотип (business use case), краткое описание, перечень связанных с прецедентом поддиаграмм и документов
Поток событий прецедента
Поток событий — описание прецедентов последовательностью шагов
Поток событий прецедента «Продажа продукта»:
- Продавец получает заявку клиента
- Если в заявке указан готовый продукт, то Продавец проверяет наличие продукта на складе. Если продукта нет в наличии, прецедент заканчивается. Если продукт есть на складе, то прецедент продолжается с шага 6.
- Если в заявке указывается заказной продукт, то Продавец формирует заказ и передает его
- Изготовителю продукта.
- Изготовитель изготавливает продукт в соответствии с требованиями клиента и сообщает о готовности Продавцу.
- Изготовитель отправляет продукт на Склад.
- Продавец сообщает Клиенту о готовности продукта и принимает от Клиента оплату.
- Продавец сообщает Отправителю количество продукта и адрес клиента и заказывает транспорт.
- Отправитель получает продукт со склада и доставляет его клиенту.
Дорожки:
Если в выполнении прецедента участвуют несколько объектов, то действия, выполняемые каждым объектом, размещаются на соответствующей дорожке
Структурирование прецедентов
Чтобы упростить описание прецедента, необходимо его структурировать. Рассмотрим два способа структурирования.
1. Выделение фрагментов
Если из описания прецедента с альтернативными потоками событий можно выделить фрагмент, представляющий собой относительно законченную последовательность событий, то данный фрагмент рассматривается как отдельный прецедент. Между выделенным прецедентом и базовым устанавливается отношения включения (include).
Иногда используют отношение расширения (extend). Оно устанавливается между базовым прецедентом и прецедентом, содержащим некоторое дополнительное поведение, выполняемое при определенных условиях.
2. Обобщение
Если несколько прецедентов имеют похожее поведение, то следует выделить общее поведение в отдельный прецедент (родительский). Между каждым из частных прецедентов и родительским устанавливается отношение обобщения (generali-zation).
Объектная модель бизнес-процесса
Раскрывает внутреннее устройство бизнеса: какие виды ресурсов используются для реализации прецедентов и каким образом они взаимодействуют.
Классы объектов модели бизнеса:
активные — исполнители процессов (стереотип business worker)
, например, Продавец, Изготовитель, Разработчик;
пассивные — сущности (стереотип business entity)
, например, Продукт, Заказ, Счет.
Иногда среди активных выделяют:
интерфейсные (стереотип Boundary) – активные объекты, взаимодействующие с окружением, т.е. с акторами. Примеры – Продавец, Регистратор, Секретарь..
управляющие (стереотип Control) – активные объекты, участвующие в выполнении процессов, но не имеющие контакта с окружением. Примеры – Разработчик продукции, Изготовитель, Менеджер проекта..
Классы и объекты
Класс
– некоторый тип объектов (множество похожих объектов),
Экземпляр
– конкретный объект (представитель класса).
Объекты имеют:
имя (через двоеточие может быть указано имя класса)
свойства — описываются с помощью атрибутов
поведение — представляется с помощью операций
У объектов одного класса состав атрибутов и операций одинаков.
Они отличаются значениями атрибутов, т.к. экземпляры классов описывают характеристики конкретного объекта.
Для отображения взаимосвязей объектов в процессе выполнения прецедента используются динамическая и статическая диаграммы взаимодействий.
Для отображения структурных и ассоциативных связей между классами используется диаграмма классов
Прецедент «Продажа заказного продукта»:
Продавец получает заявку клиента
Продавец формирует заказ и передает его Изготовителю продукта.
Изготовитель изготавливает продукт.
Изготовитель отправляет продукт на Склад и сообщает о готовности Продавцу.
Продавец сообщает Клиенту о готовности продукта и принимает от Клиента оплату.
Продавец сообщает Отправителю адрес клиента и заказывает транспорт.
Отправитель получает продукт со склада и доставляет его клиенту.
Элементы диаграммы последовательности
В верхней части диаграммы – активные объекты (и акторы) в виде прямоугольника («человечка»), от которого вниз проведена «линия жизни».
Сообщение (message) – отрезок горизонтальной линии со стрелкой, проведенный от линии жизни объекта (актора), посылающего сообщение, до линии жизни объекта (актора), получающего сообщение.
Отношение сообщения моделирует материальный или информационный поток.
Прием сообщений инициирует выполнение некоторого действия получателем
Сообщения упорядочены по времени: первое сообщение изображается вверху диаграммы, следующее – ниже, следующее – еще ниже и т.д.
Однако диаграмма не содержит метрики времени (расстояния между сообщениями – это не интервал времени)
Диаграмма кооперации (Collaboration Diagram)
Диаграмма классов
Диаграмма классов (Class diagram) используется для отображения устойчивых связей между классами объектов
Описание объектов
Методология ARIS (Architecture of Integrated Information System) разработана в 1990-х годах профессором А.-В. Шеером
Для каждого из этих представлений можно построить несколько типов моделей (в ARIS 5.0 общее количество типов диаграмм — 130)
Выделено четыре основных вида моделей (четыре представления):
- организационные модели — структура организации (иерархия подразделений и должностей);
- функциональные модели — иерархия функций (целей), выполняемых в организации;
- информационные модели — структура информации, необходимой для реализации функций системы;
- модели процессов/управления — комплексный взгляд на реализацию деловых процессов в рамках системы
Организационная схема
К организационным моделям относится Организационная схема (Organizational chat).
Основные типы объектов этой модели:
Модель строится иерархически
- от верхнего уровня структуры к нижнему.
Низшим уровнем является описание подразделений на уровне должностей - штатных единиц, занимаемых конкретными сотрудниками.
Дерево функций
Используется только один тип объекта - функция (работа, действие, этап в рамках процесса).
На верхнем уровне функции представляют собой бизнес-процессы. Детализация функций образует иерархическую структуру.
Самый нижний уровень представляют базовые функции (которые уже не могут быть разделены на составные элементы).
Событийная цепочка процесса
Основные типы объектов:
- Функция – некоторое (шаг процесса). С функцией могут быть связаны: исполнители, входные и выходные документы, программное обеспечение и т.д.
- Событие — какое-либо завершенное состояние объекта, которое влияет на дальнейший ход процесса. С одной стороны события являются стимулом к выполнению функций, с другой – их результатом.
- Логические операторы (И, ИЛИ, XOR) показывают разветвления в потоке процесса.
Примеры:
Интеграция моделей
Взаимосвязь моделей ARIS обеспечивается с помощью двух механизмов: интеграции и детализации
Благодаря хранению объектов в едином репозитории (специальной базе данных).
При создании нового объекта в репозитарии появляется отдельная запись, задающая описание объекта.
Объект можно скопировать из одной модели и вставить в другую с помощью команд Copy/Paste.
Детализация моделей
2. Механизм детализации:
для объектов текущей модели можно задавать ссылки на другие модели, являющиеся подробным описанием этого объекта.
Типы детализации, разрешенные к использованию, зависят от типа объекта
Механизм детализации позволяет избегать перегрузки моделей информацией, делая их более наглядными.
Инструментальные средства
Возможности инструментальных средств
- визуальное моделирование, позволяющее формировать графическую модель (в виде диаграмм, блок-схем, графов) в интерактивном режиме с использованием визуальных средств;
- проверка моделей – проверка соблюдения синтаксических и семантических правил построения моделей, определенных в используемой методологии моделирования;
- анализ построенных моделей – возможность просчитать стоимостные и временные характеристики процессов, проверить гипотезы «что, если …», выявить логические ошибки и т.д.;
- документирование – вывод представленной в моделях информации в виде текстовых описаний, содержащихся в файлах заданного формата;
- интеграция различных информационных систем – возможность обмениваться информацией о моделируемых процессах между различными приложениями;
- автоматическое создание компонент информационных систем – например, автоматическая кодогенерация (создание компьютерных программ), генерация баз данных на основе введенных моделей и диаграмм.
Использованная литература
1. Национальный исследовательский Томский политехнический университет. Томск. Силич В.А. 2016. 75 с. Презентация к лекции.