Нотации моделирования бизнес процессов. Выбор нотации для описания бизнес-процессов. Функциональная модель AS-IS

Нотация моделирования бизнес-процессов BPMN (Business Process Modeling Notation) была впервые представлена публике еще в 2004 г. и описана консорциумом Object Management Group. В основе управления процессами в BPMN лежит идея, что сама стратегия управления опирается на три основные методологии: моделирования бизнес-процессов, анализа и оптимизации. В свою очередь, их поддерживает ряд инструментальных средств, служащих:

  • для разработки стратегии, описания, анализа, документирования;
  • информационной поддержки бизнес-процессов;
  • поддержки потока работ (Workflow management).

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

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

  • диаграммы активности UML;
  • диаграмма потоков активностей и принятия решений ADF (activity decision flow);
  • диаграмма событийных цепочек процесса ЕРС (event-driven process chain);
  • нотация функционального моделирования IDEF (Icam DEFinition for functional modeling);
  • другие модели (UMLEDOC Business Processes, RosettaNet, LOVeM).

В 2010 г. была опубликована версия BPMN 2.0, созданная при сотрудничестве многих исследовательских групп, в том числе консорциума OMG, Института Хассо Платтнера (Hasso Plattner Institut, Потсдам, Германия), университета Гумбольдта (Берлин, Германия), университетской инициативы Signavio.

В 2013 г. версия BPMN 2.0.1 была принята как международный стандарт IS0/1 ЕС 19510:2013 Информационные технологии. Модель и нотация процесса менеджмента объекта в групповом бизнесе.

Основные понятия и группы объектов в BPMN приведены в табл. 4.6.

Таблица 4.6

Основные понятия и группы объектов в BPMN

объектов

Описание

Действия

При помощи объектов Действия описываются задачи (бизнес-правила, сценарии, задачи-сервисы, задачи отправки сообщений и др.). Задачи затем детализируются, в том числе за счет маркеров действий (сценариев действий) и определения потоков (порядка и условий выполнения действий)

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

Логические операторы

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

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

Хореография

Понятие, впервые появившееся именно во второй версии нотации BPMN. Его основная идея в отражении задач взаимодействия (обмена сообщения) между участниками (двумя и более)

Диалоги и взаимодействия

Определение характера информационных взаимодействий: один-к- одному либо один-ко-многим. Отличие от хореографии - в выделении нескольких пулов действий (swimlanes ) и детальном описании каждого из них (пример таких пулов приведен на рис. 4.17)

Благодаря группе объектов Роли определяются:

  • распределение обязанностей участников процесса;
  • информационные потоки между ними;
  • порядок обмена сообщениями

Нотация еЕРС (Extended Event-driven Process Chain, расширенная событийная цепочка процессов) предполагает описание алгоритма действий, выполняемых отдельными организационными единицами, что позволяет сформировать общий сценарий процесса как последовательность отдельных шагов.

Рис. 4.17.

Основными объектами диаграммы еЕРС являются элементы, приведенные в табл. 4.7.

Таблица 4.7

Объекты и нотация диаграмм еЕРС

Тип объекта

Описание

Графическое

обозначение

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

Логическое

Правила выполнения функции (если наступает только одно из событий или обязательно оба события) и правила наступления событий при выполнении функций (по сути, правила слияния и разделения ветвей процесса)

Описание элемента работы, который представляет собой один этап процесса

Интерфейс

процесса

Внешний (по отношению к текущей диаграмме) процесс или функция. Используется для указания взаимосвязи процессов (как для логической последовательности «следу- ющий/предыдущий процесс», так и для обозначения направления передачи объекта)

Объекты организационной схемы

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

еЕРС нс случайна названа «расширенной» диаграммой - на практике в модели такого вида могут также включаться другие объекты, например:

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

Между всеми объектами в обязательном порядке определяются связи, например, «создает» (документ), «распределяет» (задание между сотрудниками), «использует» (информационную систему 1C), «выполняет» (функцию выполняет менеджер), «принимает решение», «обеспечивает», «является владельцем» и многие другие.

Пример

Текстовое описание

Па вход процесса поступает запрос от клиента, который должен быть обработай. Ответственность за выполнение данной функции возлагается на отдел продаж. По результатам обработки запроса будет сформирован заказ в системе 1C.

Графическое описание


Рис. 4.18.

Как видно из рисунка 4.18, графическое описание алгоритма позволяет составить интегрированную картину процесса. Она, в свою очередь, может в дальнейшем использоваться либо как основа для «As-^-анализа, либо для последующей доработки и автоматизации как самого процесса, так и управления им с точки зрения достижения целевых показателей эффективности.

Архитектура интегрированных программных систем ARIS - инструментальная система моделирования бизнеса, разработанная компанией IDS Scheer AG и ныне принадлежащая Software AG.

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

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


Рис. 4.19.

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

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

Для каждого из представлений программный продукт ARIS предусматривает различные виды диаграмм:

  • организационная диаграмма;
  • диаграмма данных ERM;
  • диаграммы BPMN 2.0;
  • процессный ландшафт (цепочка добавленной стоимости VACD);
  • системный ландшафт (диаграмма компонентов);
  • иерархическая диаграмма активностей (whiteboard );
  • диаграмма бизнес-процессов ЕРС;
  • диаграмма ИТ-инфраструктуры (сети);
  • диаграмма общего вида.

Методология ARIS исходит из предположения, что деятельность предприятия может быть полностью описана при помощи иерархии моделей. Также используются различные инструменты, которые позволяют получить новые возможности (табл. 4.8).

Расширения ARIS

Таблица 4.8

Дополнительные

инструменты

Предоставляемые возможности

Процессная

аналитика

Визуализация проблем производительности

Получение отчетов/оповещений о достижении критических отметок показателей процессов

Мониторинг данных, процессов и их ключевых индикаторов (например, функционально-стоимостной анализ затрат)

Управление

Управление бизнес-операциями, рисками и требованиями, контроль исключений

Управление политиками и соответствием требованиям регуляторов

Формирование карт политик в бизнес-контексте с разграничением зон ответственности

Сочетание политик управления требованиями, рисками и процессами

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

Управление взаимодействием: создание рабо- чей платформы коллаборации

Организация общих обсуждений процессов/приложений/данных

Представление моделей процессов в формате web-страниц

Публикация моделей процессов в интранет-сети компании

Возможность для специалистов компании предложить свои улучшения в процессах

Симуляция

Возможность «прогона» (симуляции) моделей BPMN 2.0 и ЕРС для выявления различий моделей As-Is и То-Ве

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

Возможность проведения сценарного анализа «Что, если» для определения степени зависимости результата и показателей процессов от определенных факторов и групп факторов

Моделирование

бизнес-правил

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

Управление

оптимизацией

Интеграция информации о структуре и значениях ключевых показателей эффективности процессов, моделях бизнес-процессов, информации о центрах затрат для поддержки принятия стратегических решений

Одной из главных стадий при проектировании ИС является описание бизнес-процессов, для чего необходимо выбрать нотацию, в которой оно будет выполнено. На данный момент существует ряд наиболее распространенных языков графического описания бизнес-процессов: IDEF, UML и ARIS. Для выбора наиболее подходящей для данной работы нотации описания бизнес-процессов, необходимо выполнить анализ каждой из них и оценить достоинства и недостатки.

IDEF - это семейство методов моделирования, состоящее из 15 подходов описания бизнес процессов (от IDEF0 до IDEF14). Данная нотация применяется для построения функциональной модели системы . Несмотря на большое количество нотаций, входящих в эту методологию, наиболее часто применяемыми на практике являются IDEF0 и IDEF3, которые будут рассмотрены в рамках текущего анализа. Пример диаграммы IDEF0 отображающей функции и процедуры, а также потоки информации и материальных средств отображен на рис. 1.2.

Рисунок 1.2. Нотация IDEF0

Пример использования нотации IDEF3, описывающей логическую последовательность выполнения работ, представлена на рис. 1.3.

Рисунок 1.3. Нотация IDEF3

При отслеживании потоков документации при использовании методологии IDEF возникает необходимость совместного использования нотации DFD.

Вторая наиболее широко применяемая методология - это методология UML, являющееся объектно-ориентированный языком моделирования для описания сложных систем. Язык UML позволяет перейти от описаний системы непосредственно к написанию компьютерных программ и сформировать основу будущего средства автоматизации. Поэтому он содержит более 10 различных типов диаграмм, представленных на рис. 1.4.


Рисунок 1.4. Диаграмма языка UML

Для описания бизнес-процессов используется диаграмма деятельности.

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


Рисунок 1.5. Диаграмма ARIS

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

  • · организационные модели, представляющие иерархию организационных подразделений, должностей и конкретных лиц, связи между ними, а также территориальную привязку структурных подразделений;
  • · функциональные модели, содержащие иерархию целей, стоящих перед аппаратом управления, с совокупностью деревьев функций, необходимых для достижения поставленных целей;
  • · информационные модели, отражающие структуру информации, необходимой для реализации всей совокупности функций системы;
  • · модели управления, представляющие комплексный взгляд на реализацию бизнес-процессов в рамках системы .

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

Таблица 1. 1. Сравнительная таблица нотаций описание бизнес-процессов

Показатель

Принцип построения диаграммы

Принцип иерархии

Временная последовательность выполнения процедур

Временная последовательность выполнения процедур

Входящая информация

Стрелки сверху / слева

Используется отдельный объект

Исходящая информация

Стрелка справа

В диаграмме активности нет - отображается в отдельной диаграмме

Используется отдельный объект

Наглядность модели

Возможность взаимосвязи функциональной и информационной модели

Основная область применения методологий

Для построения модели бизнес-процессов

Для разработки основы ИС и моделирования БП

Для выбора конкретной нотации для описания бизнес-процессов, необходимо определить критерии, удовлетворяющие требованиям данной работы:

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

Вышеуказанные возможности полностью реализованы в нотации ARIS, которая и будет использована для описания бизнес-процессов в данном исследовании.

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

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

Разрабатываемая ИС удовлетворяет следующие требования:

  • · справочный характер ИС - разрабатываемая система в диалоговом режиме предоставляет пользователям необходимую в процессе реализации проектов информацию (советы, извлеченные уроки, шаблоны документов и др.);
  • · экспертный характер ИС - при заполнении системы начальными данными, в том числе определение показателей оценок методик и рангов проектов, применены опыт, мнения и советы ведущих экспертов Компании;
  • · аналитический характер ИС - для реализации системы были проанализированы методики управления проектами и выбраны наиболее критичные (в рамках данного исследования) данные для включения в систему;
  • · база знаний в ИС - при создании в системе нового проекта определение методики его ведения происходит посредствам семантических правил в режиме «вопрос-ответ», расчет и определение которых выполняется в соответствие с рангами методик по показателям (Приложение Б.);
  • · база документов в ИС - в системе хранится ряд документов в библиотеках узла: проектные процедуры, шаблоны календарных планов, уставов и т.п.;
  • · база данных в ИС - подход реализации узлов на порталах SharePoint можно представить как реляционную базу данных, в которой её таблицами являются списки SharePoint.

Системой управления реализуемых бизнес-процессов является платформа разработки ИС - MS SharePoint 2013.

Разработка информационной системы, описание бизнес-процессов и настройка системы на платформе SharePoint 2013 приведена в Главе 2.

Процессным подходом к организации бизнеса мир занимается уже давно и достаточно эффективно, и стандарт Business Process Model and Notation (BPMN, нотация) является процедурой продуманной с правильным описанием бизнес-процессов. Компании постоянно совершенствуют разные специализации данного стандарта и тем самым добиваются весьма существенного повышения всех качественных показателей своей работы. Нотация BPMN понятна не только для экспертов той предметной области, в которой она создавалась, её логическими выкладками может оперировать любой работник.

Моделирование и стандартизация

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

Для построения определённой модели может использоваться не одна версия (нотация BPMN 2.0 (PDF) и другие), иногда модель составляется из фрагментов разных нотаций, но способ их систематизации и прочтения один и тот же. Всё большее количество предпринимателей внедряют в своих компаниях опирающееся на данный стандарт выполнение бизнес-процессов. Растёт с каждым днём востребованность специалистов, которые владеют этим языком моделирования. Всё большее количество людей занято изучением графических элементов нотации BPMN и правил построения моделей. Для этого существуют специальные курсы, где желающие познакомятся с назначением этого языка, с видами диаграмм, увидят возможности автоматического выполнения построенных моделей. Самое интересное - практический опыт в нотации BPMN 2.0 (на русском языке тоже есть), моделирование и проведение анализа, разработка бизнес-процесса.

Специалисты

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

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

Символы (элементы) BPMN

Поддерживает и развивает BPMN организация OMG. Это не мем интернетных завсегдатаев, обозначающий "о майн гот", а весьма знаменитая фирма Object Management Group, в которой участвуют более восьмисот компаний, разрабатывающих стандарты, подобные BPMN-нотации. Всеми полезными изменениями в новых версиях мы обязаны разработчикам OMG. Именно эта организация выбрала ключевым направлением продвижение нотации UML BPMN, с помощью которой моделируются объектно-ориентированные системы. А потому при разработке диаграмм помимо концепций и понятий (поток управления, действие, объект данных и тому подобное) в BPMN много понятий, характерных для подхода объектно-ориентированного: сообщение, обмен и поток сообщений.

Символы графической нотации разобраны по назначению и объединяются в категории. Objects - объекты потока, Data - данные, Swimlanes - зоны ответственности, Connecting Objects - соединяющие объекты, Artifacts - артефакты. Поток управления, объект данных и символы объектов потока дополнительно разделяются на подгруппы по семантическому признаку, чтобы отобразить специфику происходящих событий, особенности ветвления потоков, выполнение действий и так далее. Указывают специфику за счёт дополнительных графических изображений - маркеры, иконки, помещённые внутри главного символа. Также символы событий бывают с разным видом контура и фоновым цветом.

События по времени

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

Конечное событие - результат выполнения бизнес-процесса. Сюда поток управления только входит, а поток сообщений всё так же движется и на вход, и на выход. Входящий поток изображается стрелкой. Диаграмма отображает только одно конечное событие или несколько - они обведены контуром в виде жирной одинарной линии. Промежуточное событие - это любое из остальных, которые возникают во время выполнения бизнес-процесса. Сюда входит один поток и выходит тоже один. Только Boundary (граничное событие) возникает и обрабатывается сразу - либо в самом начале, либо в конце действия. Отображается оно на контуре (границе) действия, и содержит только один поток - либо входящий, либо выходящий. А обозначается такое событие тонкой двойной линией.

События: прерывание подпроцесса и тип результата

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

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

Действия

Изображаемый в виде диаграммы процесс выглядит упорядоченным набором действий, которые выполняются для получения определённого результата. На вертикальной диаграмме нотации BPMN сверху вниз задаётся последовательность, показывающая выполнение процесса по времени. Также можно проследить её по направлению стрелок соединяющих элементов слева направо. У отображаемых действий есть три главных вида и много разновидностей, каждое из которых имеет собственную иконку или значок.

Task - задача. Элементарное действие, то есть неделимое. Разновидность или специфика задачи отображается маркером или иконкой в верхнем углу слева на символе действия. Задача может быть Service (сервисная), для оказания услуги, являющейся автоматизированным приложением или веб-сервисом. Send - отправка сообщения. Если хотя бы единожды сообщение отправлено, задача может считаться выполненной. Receive - получение сообщения (тот же принцип: если единожды получено сообщение, задача выполнена). Задача User - пользователя, считается характерной, выполняется исполнителем при помощи программного обеспечения и содействии других сотрудников. Задача, требующая ручного исполнения, - Manual, которая исполняется без помощи автоматизации. Business-Rule - бизнес-правило, по технологии выполнение этой задачи зависит от обстоятельств, выбрать способ помогает заданность бизнес-правила. Script - сценарий, где выполнение операций строго по порядку, описанному на распознаваемом исполнителем языке. Обычно этот вид задач выполняется автоматическими средствами.

Подпроцессы

Sub-Process - подпроцесс. Он включает в себя шлюзы в нотации BPMN, потоки операций, события и много других действий. Таким образом, подпроцесс является составным действием, части которого непосредственно отображаются внутри символа на диаграмме или же выносятся на отдельную декомпозиционную диаграмму. В последнем случае на главной диаграмме в центре подпроцесса (нижний край действия) должен отображаться знак +. Есть стандартные подпроцессы, но их недостаточно, поэтому и появились две его специфические разновидности. Это Event Sub-Process - событийный подпроцесс, который запускается всегда при появлении стартового события. Диаграмма показывает его никак не связанным с остальными действиями и потоками операций. Контур такого подпроцесса изображён точками.

Вторая разновидность - Transaction (транзакция), это состоящее из разных операций действие с удачным завершением, то есть получением положительного результата. Получить конкретный результат можно только при условии удачного завершения абсолютно всех составляющих. Если же возникают проблемы по ходу выполнения подпроцесса, результаты всех предыдущих операций будут отменены (отмена события). Такими помехами могут стать невозможность выполнения той или иной операции или некорректное выполнение её. Чтобы не отменять предыдущие события, можно попробовать неудавшуюся операцию компенсировать (компенсация события). Контур такого подпроцесса отображён двойной сплошной линией. Для включения в диаграмму всех задач или подпроцессов, используемых повторно, существует Call - вызов, который на диаграмме обозначен жирным контуром.

Шлюзы

Шлюзы в нотации BPMN предназначены для того, чтобы указывать специфику потока операций и их пропуска по параллельным или альтернативным ветвям. Шлюз может обходиться без исходящих или входящих потоков, но всегда имеет как минимум два собственных либо входящих потока, либо исходящих. Маркер внутри его символа задаёт тип шлюза. Это может быть Exclusive, XOR - эксклюзивный с исключающим "или", предназначенный для разделения потока на альтернативные маршруты. По ходу выполнения процесса активирован может быть только один из предлагаемых маршрутов. Условия пропуска содержатся рядом с обозначающей линией. Inclusive, OR - неэксклюзивный с логическим "или" шлюз, предназначенный для разделения потока на маршруты, где активируется каждый, если соблюдено условие истинности логического выражения, связанного с ним. В этом процессе можно выполнять несколько маршрутов, но если хоть в одном отсутствует истинность, то выбор невозможен.

Аналог неэксклюзивного шлюза - Complex (комплексный). Отличие в том, что определяющее активизацию того или иного потока операций выражение только одно. Parallel, AND - параллельный с логическим "и" шлюз нужен для ветвления или слияния параллельно выполняемых операций. Exclusive Event-Based - шлюз эксклюзивный, но основанный на событиях, разделяющих поток операций на альтернативные маршруты. Exclusive Event-Based Gateway to start a Process - тоже эксклюзивный шлюз, события, на которых он основан, запускают весь процесс. Это начальный символ процесса или подпроцесса, входящих потоков не имеет. Таким же образом работает и Parallel Event-Based Gateway to start a Process - шлюз параллельный, также основанный на запускающих процесс событиях. Однако при его помощи можно активировать несколько процессов одновременно, если события, связанные с ними, сработают. Входящих потоков, естественно, не имеет. На картинках ясно видна нотация BPMN в примерах построения диаграмм с двумя видами шлюзов.

Данные и потоки

Объект данных содержится и используется в диаграммах специфически, что демонстрирует применение дополнительных маркеров. Data Inputs - входные данные, то есть исходная информация для того, чтобы начать выполнение действий. Изображается на верхнем крае символа. Data Collection - набор данных, то есть целый массив или коллекция данных одного типа. Отображено снизу символа. Объект данных и действия объединены связью с помощью ассоциации.

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

Примеры и выводы

Стартовое событие, как можно заключить из названия, указывает на точку начала того или иного процесса. Это отправная начальная точка, что значит отсутствие любого вида входящего потока. Стартовое событие в примерах нотации BPMN обозначается кругом, в котором центр свободен. Таким событием может стать письмо или звонок от клиента, например, направленный в интернет-магазин или на сайт компании, которая моделирует данный бизнес-процесс. Далее поток операций идёт по линиям и обозначает выполнение процесса вплоть до красного кружка, который обозначает завершение, конечное событие. Их, кстати, может быть и несколько, и легко проследить, где именно поток операций пришёл к концу, завершив процесс. Никакой исходящий поток из красного кружка невозможен.

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

Модель 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 (как должно бы быть), и несущие ложную информацию и которую невозможно в дальнейшем использовать для анализа.

Понятие модели

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

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

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

Модель внешнего вида часов

Структурная схема часов

Виды подобия: прямое (макет, фотография), косвенное (подобие по аналогии), условное (на основе соглашений).

Процесс моделирования имеет свойство динамичности: модели развиваются, уточняются, переходят одна в другую.

Классификация моделей


Познавательные (объяснительные) модели отражают уже существующие объекты.

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


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


Материальные модели построены из реальных объектов.
Абстрактные модели — это идеальные конструкции, выполненные средствами мышления, сознания.


Декларативные модели отражают свойства, структуры, состояния объектов.
Процедурные модели отражают процедурное, операционное знание.


Детерминированные модели отражают процессы и явления, не подверженные случайностям.
Стохастические – отражают случайные процессы, описываемые вероятностными характеристиками и статистическими закономерностями.


Формализованные модели могут не иметь смысловой интерпретации.
В содержательных моделях сохраняется семантика моделируемого объекта.

Языки описания моделей

Языки описания моделей: аналитические, численные, логические, теоретико-множественные, лингвистические, графические.

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

Требования к нотации:

  • простота - простой знак предпочтительнее сложного;
  • наглядность - хотя бы отдаленное сходство с оригиналом;
  • индивидуальность - достаточное отличие от других обозначений;
  • однозначность - нельзя обозначать одним символом различные объекты;
  • определенность - четкие правила использования модели;
  • учет устоявшихся традиций.

В модели бизнеса отражают:

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

Методы моделирования бизнеса


Основаны на последовательной декомпозиции системы на все более мелкие подсистемы.

Принципы структурного подхода:

  • «разделяй и властвуй» — разбиение сложных проблем на множество меньших задач, легких для понимания и решения;
  • иерархическое упорядочивание – организация составных частей проблемы в иерархические древовидные структуры.

Две группы методов: моделирующие функциональную структуру и структуру данных

Наибольшее распространение получили методологии:

  • 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

Типы перекрестков


выходной процесс запустится, если завершились все входные процессы

после завершения входного процесса запустятся все выходные процессы


выходной процесс запустится, если завершились одновременно все входные процессы

после завершения входного процесса запустятся все выходные процессы, причем запустятся одновременно


выходной процесс запустится, если завершится один или несколько входных процессов

после завершения входного процесса запустятся один или несколько выходных процессов


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

после завершения входного процесса запустится один или несколько выходных процессов, причем запустятся одновременно


выходной процесс запустится, если завершился только один входной процесс

после завершения входного процесса запустится только один выходной процесс

Правила создания перекрестков

  1. Каждому перекрестку слияния должен предшествовать перекресток ветвления.
  2. Перекресток слияния «И» не может следовать за перекрестком ветвления типа синхронного, асинхронного или исключающего «ИЛИ».
  3. Перекресток слияния типа исключающего «ИЛИ» не может следовать за перекрестком ветвления типа «И».
  4. Перекресток, имеющий одну стрелку на одной стороне, должен иметь более одной стрелки на другой.
  5. Перекресток не может быть одновременно перекрестком слияния и ветвления. В ситуации, когда необходимо одновременно осуществить слияние и разветвление потоков работ, вводится каскад перекрестков.

Правило относительно единиц работ

В блок может входить и из блока может выходить только одна связь последовательности. Для отображения множества входов и выходов используются перекрестки.
Разрешается множественная декомпозиция работ:
для одной и той же работы может быть создано несколько диаграмм декомпозиции (для описания разных вариантов реализации работы).

Номер работы А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 с. Презентация к лекции.