Нотации «Basic Flowchart» и «Cross-functional Flowchart»
Нотации Flowchart используются для представления алгоритма (сценария) выполнения процесса и позволяют задать причинно-следственные связи и временную последовательность выполнения действий процесса. Нотации поддерживают декомпозицию на подпроцессы.
Нотации Flowchart можно применять для моделирования отдельных процессов компании, а также на нижнем уровне модели бизнес-процессов, созданной в нотации IDEF0.
Описание назначения графических символов, используемых в нотациях Flowchart, приведено в Таблице 1.
Если символ «Решение» используется для проверки условия, то «Решение» помещается на диаграмму после символа «Действие», в названии символа «Решение» указывается проверяемое условие, а все возможные варианты значения условия показываются выходящими стрелками (например, «Да» или «Нет» (Рис. 3)).
Символ «Решение» аналогичен символу «Исключающее ИЛИ» (XOR) в других нотациях моделирования.
Если стрелка служит только для обозначения передачи управления, то имя стрелки оставляется пустым. Если кроме передачи управления из предыдущего действия в следующее действие поступает объект(ы) деятельности, то стрелка именуется, и в список объектов стрелки заносится соответствующий объект(ы) деятельности (Рис. 5).
Если источником объекта(ов) является одно из действий процесса, то такой объект показывается с помощью стрелки, исходящей из действия-источника и входящей в действие-потребитель, для выполнения которого необходим объект (Рис. 7).
При этом действие «Регистрация в журнале «Исходящая корреспонденция» не запускает выполнение действия «Заполнение графы «Номер накладной» в журнале «Исходящая корреспонденция».
Информация о способах добавления фигур на диаграмму содержится в главе Руководство пользователя → Создание модели деятельности организации.
Пример диаграммы процесса в нотации «Basic Flowchart приведен на Рис. 8.
Нотации моделирования бизнес-процессов
Нотация IDEF0
Наиболее популярная нотация моделирования бизнес-процессов, основанная на методологии структурного анализа SADT. Методология IDEF0 — это методология моделирования, позволяющая создать функциональную модель, отображающую структуру и функции системы, а также потоки информации и материальных объектов, связывающие эти функции (на рисунке представлена графическая диаграмма в нотации IDEF0 — пример реализован в системе Business Studio, которая включает в себя функции программы для построения IDEF0). Бизнес-процессы в нотации IDEF0 представляются в форме прямоугольника, а стрелки отражают связь с другими процессами и внешней средой. Особенностью нотации является:
Нотация IDEF0 используется для создания верхнего уровня модели бизнес-процессов. Построение IDEF0-диаграммы верхнего уровня обеспечивает наиболее общее или абстрактное описание объекта моделирования. На нижнем уровне для описания алгоритма (сценария) выполнения процесса допустимо сменить стандарт IDEF0 на нотацию Процесс, Процедура, EPC или BPMN 2.0.
Подробнее о нотации IDEF0
С методологией SADT можно подробно ознакомиться в монографии Дэвида А. Марка и Клемента МакГоуэна «Методология структурного анализа и проектирования SADT».
Нотация Процесс (Basic Flowchart в Visio)
Данная нотация используется для представления алгоритма выполнения процесса (нотация класса workflow). Используются графические элементы: событие, процесс, решение, два типа стрелок — стрелки предшествования и стрелки «Поток объектов».
Нотация Процесс поддерживает декомпозицию на подпроцессы.
Нотацию Процесс можно применять для моделирования отдельных процессов компании, а также на нижнем уровне модели бизнес-процессов, созданной в нотации IDEF0.
Нотация Процедура (Cross-Functional Flowchart в Visio)
Данная нотация используется для представления алгоритма выполнения процесса (нотация класса workflow). Дополнительно к графическим элементам, применяемым в нотации Процесс, используются дорожки (Swim Lanes), обозначающие организационные единицы — исполнителей действий процесса.
Нотация Процедура поддерживает декомпозицию на подпроцессы.
Нотацию Процедура можно применять для моделирования отдельных процессов компании, а также на нижнем уровне модели бизнес-процессов, созданной в нотации IDEF0.
Нотация BPMN 2.0
Данная нотация используется для представления алгоритма выполнения процесса (нотация класса workflow). Особенностью нотации BPMN 2.0, появившейся в качестве стандарта моделирования в 2011 году, является то, что она предназначена как для моделирования бизнес-процессов, так и для их исполнения. Она доступна для понимания и удобна как бизнес-аналитикам, так и разработчикам, которые занимаются автоматизацией исполнения процессов. Для экспорта схемы процесса в BPMS-систему в Business Studio используется стандарт XPDL.
В Business Studio представлено 2 типа диаграмм BPMN 2.0 — диаграммы процессов и диаграммы взаимодействия процессов. Используются следующие графические элементы: процессы, события, шлюзы; 3 типа стрелок: поток управления, поток сообщений, ассоциации; объекты: документы, информация, сообщения, базы данных. Важно, что в Business Studio все элементы диаграмм BPMN являются объектами репозитория.
В Business Studio в нотации BPMN можно строить иерархическое дерево процессов, т.е. поддерживается декомпозиция.
Для процесса BPMN можно автоматически сформировать регламент и другие отчеты, эта нотация применяется преимущественно для описания процессов нижнего уровня, особенно со сложной логикой исполнения.
Нотация EPC (Event-Driven Process Chain)
Данная нотация используется для представления алгоритма выполнения процесса (нотация класса workflow). Диаграмма, описанная в нотации EPC (событийная цепочка процессов), представляет собой упорядоченную комбинацию событий и функций. Для каждой функции могут быть определены начальные и конечные события, участники, исполнители, материальные и документальные потоки, сопровождающие её. В нотации EPC ветвление стрелок осуществляется с использованием операторов.
Нотация EPC поддерживает декомпозицию на более низкие уровни. Диаграмма декомпозируемой функции EPC может быть описана только в нотациях EPC или BPMN 2.0.
Нотацию EPC можно применять для моделирования отдельных процессов компании, а также на нижнем уровне модели бизнес-процессов, созданной в нотации IDEF0.
Нотации «Процесс» и «Процедура»
Нотации «Процесс» (Basic Flowchart в Microsoft Visio) и «Процедура» (Cross-Functional Flowchart в Microsoft Visio) используются для представления алгоритма (сценария) выполнения процесса и позволяют задать причинно-следственные связи и временную последовательность выполнения действий процесса. Нотации поддерживают декомпозицию на подпроцессы, также как и нотация IDEF0.
Нотации «Процесс» и «Процедура» можно применять для моделирования отдельных процессов компании, а также на нижнем уровне модели бизнес-процессов, созданной в нотации IDEF0.
Описание назначения графических символов, используемых в нотациях «Процесс» и «Процедура», приведено в Таблице 1.
| Название | Графический символ | Описание |
|---|---|---|
| Действие |  | Действие обозначается с помощью прямоугольного блока. Внутри блока помещается название действия. Временная последовательность выполнения действий задается расположением действий на диаграмме процесса в нотации «Процесс»/»Процедура» сверху вниз (слева направо на горизонтальной диаграмме процесса в нотации «Процедура»). |
| Решение |  | Элемент «Решение» обозначает ветвление, после которого процесс может пойти по одному и только одному альтернативному направлению в зависимости от некоторого условия. Элемент «Решение» может иметь один или несколько входов и ряд альтернативных выходов. Элемент «Решение» используется в двух вариантах: для обозначения действия, результат которого определяет дальнейшее выполнение процесса, или для обозначения проверки условия. Если «Решение» используется для обозначения действия, то все возможные варианты результатов этого действия показываются выходящими стрелками (Рис. 1). |
Если элемент «Решение» используется для проверки условия, то «Решение» помещается на диаграмму после элемента «Действие», в названии элемента «Решение» указывается проверяемое условие, а все возможные варианты значения условия показываются выходящими стрелками (например, «Да» или «Нет» (Рис. 2)).
Элемент «Решение» аналогичен элементу «Исключающее ИЛИ» (XOR) в других нотациях моделирования.
Стрелка, запускающая выполнение действия, изображается входящей в действие сверху. Стрелка, обозначающая передачу управления другому (другим) действию, изображается выходящей из действия снизу (Рис. 3).
Если стрелка служит только для обозначения передачи управления, то имя стрелки оставляется пустым. Если кроме передачи управления из предыдущего действия в следующее действие поступает объект(ы) деятельности, то стрелка именуется, и в список объектов стрелки заносится соответствующий объект(ы) деятельности (Рис. 4).
Стрелки «Поток объектов» обозначаются стрелкой с двумя треугольниками на конце. Если обозначение источника объекта(ов) неважно, то такой объект показывается стрелкой с туннелированным началом (Рис. 5).
Если источником объекта(ов) является одно из действий процесса, то такой объект показывается с помощью стрелки, исходящей из действия-источника и входящей в действие-потребитель, для выполнения которого необходим объект (Рис. 6).
При этом действие «Регистрация в журнале «Исходящая корреспонденция» не запускает выполнение действия «Заполнение графы «Номер накладной» в журнале «Исходящая корреспонденция».
Информация о способах добавления элементов на диаграмму содержится в главе Руководство пользователя → Создание модели деятельности организации.
Пример диаграммы процесса в нотации «Процесс» приведен на Рис. 7.
Пример диаграммы процесса в нотации «Процедура» приведен на Рис. 8.
Нотации для моделирования бизнес-процессов и их поддержка
В сети Интернет можно встретить множество обзоров и обсуждений нотаций для моделирования бизнес-процессов. Консультанты и бизнес-аналитики ведут длительные дискуссии о том, какую же нотацию лучше применять при моделировании бизнес-процессов предприятия. С нашей точки зрения обсуждение нотаций без привязки к программному продукту не имеет смысла. Ведь графическая схема – это только вершина айсберга, вся бизнес-логика и связи хранятся «внутри» блоков нотации и не видны на схеме.
Например, популярная сейчас нотация BPMN по-настоящему раскроет свои преимущества только в связке с BPM-системой, которая может «понимать» и «исполнять» нарисованную схему бизнес-процесса в реальном времени. То есть при помощи этой нотации можно автоматизировать и контролировать выполнение процесса. Если же вы просто нарисуете процесс в нотации BPMN в Visio и сохраните его как картинку, то при этом вы потеряете практически все преимущества данной нотации перед любой другой.
Сейчас на рынке появилось множество программных продуктов, которые якобы поддерживают сразу несколько нотаций, но дело в том, что на самом деле логика работы у этих программ одинаковая для любой из этих нотаций. Как правило, ответственность и документы закрепляются внутри блока, а затем, для визуального соответствия требованиям одной из нотаций, на схему можно добавить графические блоки, наличие которых никак на функционал не влияет. То есть по сути вы строите две модели: одну по логике работы программы, а вторую – для соответствия требованиям нотации и при этом эти модели могут не совпадать (то, что мы видим не соответствует тому что сохранилось в базу данных).
Ниже приведён пример системы бизнес-моделирования, которая на бумаге поддерживает нотацию ARIS eEPC, но, на самом деле, ответственность закрепляется в карточке на функцию, а графические блоки используются «для красоты».
Но давайте не будем критиковать чужие разработки, а последовательно рассмотрим самые популярные на рынке нотации для моделирования бизнес-процессов, а также их реализацию в программе Fox Manager.
Процессы верхнего уровня
Самые распространённые нотации для построения процессов верхнего уровня на сегодняшний день это IDEF0 (методология функционального моделирования) и ARIS VAD (цепочка создания ценности).
В Fox Manager мы не придерживались строгих требований какой-либо нотации, а просто создали диаграмму взаимодействий процессов, которая состоит из блоков и стрелочек и показывает связи, а также входы и выходы процессов на наглядной графической схеме. Преимущество нашего подхода к моделированию процессов верхнего уровня заключается в том, что такие диаграммы программа Fox Manager может формировать автоматически, посмотрите небольшой видеоролик, чтобы понять, как это работает.
В чём же отличие нашей схемы от IDEF0? В первую очередь в том, что в IDEF0 есть требования к тому к какой стороне блока какая стрелка должна подходить:
Является ли это важным отличием, которое даёт преимущества данной нотации перед нашим подходом? С нашей точки зрения – нет, но при желании, вы можете привести схему взаимодействий в Fox Manager в чёткое соответствие с требованиями этой нотации (сверху – оригинальная схема в IDEF0, снизу – её аналог в Fox Manager).
Как видите, при желании, вы можете моделировать схемы IDEF0 и в Fox Manager.
Есть у нотации IDEF0 и другие требования, (которые, впрочем, обычно не соблюдаются бизнес-аналитиками) – это ограничение на количество блоков на схеме (6-8) и принцип доминирования (наиболее важная функция должна находится в верхнем левом углу). Опять же, не существует никаких преград к тому, чтобы расположить блоки по этому принципу и в нашей программе.
Что касается нотации ARIS VAD – то тут всё ещё проще: достаточно выстроить процессы по цепочке создания ценности и при желании показать ответственных и взаимодействия.
На картинке приведён пример такой схемы в нашей программе (сверху – оригинальная диаграмма ARIS VAD, снизу – её аналог в Fox Manager). Конечно, можно придраться в форме блоков, стрелок или подсветке, но в целом, не возникает сомнений, что в нашей программе, при желании, можно строить диаграммы в соответствии с требованиями нотации ARIS VAD.
Процессы нижнего уровня
В программе Fox Manage мы используем простую, наглядную и очень гибкую нотацию для моделирования процессов нижнего уровня. Ознакомиться с её возможностями можно из видеоролика.
Существует множество нотаций для моделирования бизнес-процессов нижнего уровня: Basic Flowchart, Cross Functional Flowchart, EPC и другие. Большинство из них имеют незначительные отличия друг от друга.
Например, если в программе Fox Manager на диаграмме свернуть блоки ответственных, документов и ресурсов, то мы получим аналог нотации Basic Flowchart (справа – оригинальный процесс, слева – аналог в Fox Manager).
Если же все блоки на диаграмме развернуть – то мы получим аналог процесса в нотации EPC. Самое замечательное то, что при использовании нотации Fox Manager блоки можно сворачивать и разворачивать динамически, и при этом не нужно создавать новую версию процесса в другой нотации. На картинке справа изображен оригинальный процесс, а слева – аналог в Fox Manager.
Да, конечно, имеются и различия, например, в качестве отображения события мы использовали контрольную функцию, также у нас нет отдельных блоков «Логические И» и «Логическое ИЛИ», но их можно легко заменить другим блоком (ромбиком) с буквой «Х» или «V» внутри.
Поддержка нотации Cross Functional Flowchart была добавлена в программу в одном из наших бесплатных обновлений. Данная нотация отличается от уже рассмотренных выше нотаций тем, что на ней можно показывать ответственных дорожками, а не рядом с блоком. К сожалению, у этого способа есть свои недостатки, когда ответственных очень много – то процесс становится ненаглядным и трудночитаемым. Также возникают проблемы, когда необходимо распределить ответственность за функцию сразу двум и более должностям. Ниже приведён пример такого процесса в Fox Manager.
Что касается нотации BPMN, то мы считаем, что её возможности слишком избыточны для целей описания, анализа и регламентации бизнес-процессов. В этой нотации представлено около 100 различных блоков и их подвидов, которые используются при автоматизации процессов, но они бесполезны для систем бизнес-моделирования, которые не умеют «исполнять» процессы в реальном времени, а берут из них информацию для формирования регламентирующих документов.
Конечно, можно сократить набор элементов этой нотации до необходимого минимума и попытаться приспособить её для целей регламентации, но при этом мы потеряем её главное преимущество – возможность исполнения процессов BPM-движком. При этом, если оставить только 5-10 необходимых блоков, то, скорее всего, внешний вид таких процессов будет очень походить на уже рассмотренные нами нотации.
При этом, мы рассматриваем возможность добавления поддержки данной нотации в одном из следующих бесплатный обновлений программы.
Вывод
Мы считаем, что в программе Fox Manager подобраны оптимальные нотации для моделирования бизнес-процессов, которые одновременно легки для восприятия и обладают и высоким функционалом.
Поддержка нотации реализована на базе ядра программы, мы не используем Visio и другие сторонние компоненты, поэтому скорость обработки данных из таких блок схем очень высокая.
На схеме можно отображать множество дополнительной информации, например, рядом с названием функции можно вывести её тип, частоту, время и даже стоимость, которая рассчитывается динамически в реальном времени по мере заполнения процесса. При этом внешний вид схемы можно настроить для каждого пользователя индивидуально.
А ещё в нашем редакторе процессов можно отслеживать изменения, которые вносились пользователями и выводить их в таблицу или отображать графически на диаграмме.
Если Вам не хватает стандартного функционала, то Вы можете расширять базовый набор блоков для моделирования бизнес-процессов. Например, Вы можете создать блоки рисков или показателей и выводить их на графической схеме процесса.
Но мы отдаём себе отчёт в том, что некоторые бизнес-аналитики не доверяют новым разработкам и предпочитают пользоваться старыми, знакомыми им нотациями. Цель данной статьи – показать гибкость программы Fox Manager и возможность настройки внешнего вида схем под требования большинства имеющихся на рынке нотаций. Стройте модели бизнес-процессов так, как удобно именно вам!
Краткий путеводитель по методологиям и нотациям описания и моделирования бизнес-процессов. Часть 1
Аналитики скорее всего не раз задавались вопросами – почему нотаций и методологий так много, какую из них выбрать, какая из них будет правильной…?
Самая главная причина такого разнообразия (на мой взгляд), что одна нотация (или методология) не может сразу решить все задачи, которые поставлены для описания бизнес-процессов. И исходя из этого минимум три нотации должны быть в арсенале аналитика. Ну а остальные опционально.
ОСНОВНЫЕ ОПРЕДЕЛЕНИЯ И ТЕРМИНЫ
Начнем с простого – есть описание бизнес-процесса, а есть моделирование. Есть ли между ними разница? Разница есть, но, возможно в какие-то моменты ей можно пренебрегать и использовать эти слова как синонимы. Если все же разграничивать эти понятия, то определения будут следующими.
Описание бизнес-процессов – это документирование процесса в свободной форме, например, простое текстовое описание пользовательских сценариев (Use Case).
Таким образом, описав не формально бизнес-процесс, мы все равно получим его документированное выражение.
Преимуществом этого способа является то, что любой новичок может описать простой процесс, а бывают случаи, когда процесс настолько прост, что нет необходимости использования тяжеловесной нотации.
Недостаток такого подхода тоже есть: если углубляться и оставаться на этом уровне, то может быть «изобретение собственного велосипеда» – т.е. в какой-то момент потребуется стандартизация и унификация действий в описании бизнес-процессов. В этом случае нужно уже задумываться об моделировании бизнес-процессов, т.е. выборе формальных методов их отображения. Таким образом, мы переходим уже к определению, что же такое моделирование бизнес-процессов.
Моделирование бизнес-процессов – это формализованная процедура, подразумевающая создание некоторой формальной модели процесса, описанной на математическом или любом другом формализованном языке.
Основное отличие моделирования от описания в этом случае, что моделирование – это формальное представление бизнес-процесса с помощью общеизвестных методологий, методов и нотаций.
Методология моделирования определяет системные основы исследования или проектирования, а также совокупность методов и принципов построения моделей бизнес-процессов.
Моделирование осуществляется с помощью графических элементов (совокупности нотаций) и правил их использования.
Метод – это систематическая процедура, применяемая для генерации описания системы с использованием соответствующих нотаций.
Или если более кратко – это способ достижения какой-либо цели, а способом будет нотация моделирования процессов.
Нотация – это система условных знаков и правил их использования для описания различных категорий моделируемой системы, таких как объектов, процессов, взаимосвязей и т.п.
Нотации – это формализованные графические модели, которые используются, чтобы фиксировать бизнес-процессы, анализировать их и оптимизировать.
В методологии моделирования выделяют различные подходы к построению и отображению моделей бизнес-процессов или виды моделирования, основными среди которых считаются структурное, объектно-ориентированное и интегрированное.
Как я уже писала выше, единого верного способа моделирования нет, поэтому нужно правильно ставить цель моделирования и исходя из нее выбирать нужный способ реализации. Т.е. выбор того или иного подхода к моделированию бизнес-процессов зависит от многих факторов, например, уровень моделирования, детальность моделирования, цель моделирования и т.п. А также следует учитывать, что на практике методы и нотации могут комбинироваться для достижения оптимального результата.
1. СТРУКТУРНОЕ МОДЕЛИРОВАНИЕ
Структурное моделирование – это область системного анализа и вид моделирования, который используется как средство исследования систем и может служить для их разработки. Оно изучает структуру системы с точки зрения состава элементов и подсистем и отношений между ними (структура), а также с точки зрения свойств системы, которые позволяют достигать заданной цели (функции). У него есть свои подвиды.
1.1. ФУНКЦИОНАЛЬНОЕ МОДЕЛИРОВАНИЕ
Функциональное моделирование – это вид моделирования, который подразумевает описание процессов в виде взаимосвязанных, четко структурированных функций. Т.е. главный элемент – это функция (операция), а бизнес-процесс представляется в виде последовательности функций, преобразующих входы процесса в выходы с использованием определенных ресурсов.
1.2. ИМИТАЦИОННОЕ МОДЕЛИРОВАНИЕ
Имитационное моделирование (или моделирование проведения) – представление поведения системы во времени, описание поведения бизнес-процессов при различных внешних и внутренних условиях с анализом как динамических характеристик процессов, так и с распределением ресурсов.
CPN (Цветные сети Петри)
1.3. ИНФОРМАЦИОННОЕ МОДЕЛИРОВАНИЕ
Информационное моделирование дает представление объектов предметной области, их свойств и отношений между ними.
Нотация Баркера (Barker Notation)
Нотации IDEF1 и IDEF1X (Integration Definition for Information Modeling)
2. ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ МОДЕЛИРОВАНИЕ
Объектно-ориентированное моделирование подразумевает описание процессов, как набора взаимодействующих объектов без детализации выполняемых операций, но с описанием условий и событий. Объект – это какой-либо предмет, который преобразуется при выполнении процессов. В основе – объектная модель, которая базируется на таких принципах, как инкапсуляция, абстрагирование, полиморфизм, наследование, параллелизм, устойчивость и т.д. При этом статическую структуру модели описывают объекты, а поведение модели – сообщения, которыми эти объекты обмениваются.
Язык графического описания
Метод Джеймса Румбаха ( OMT)
Метод Айвара Джекобсона (OOSE)
3. ИНТЕГРИРОВАННОЕ МОДЕЛИРОВАНИЕ
Интегрированное моделирование объединяют различные виды моделей – структурного анализа, объектно-ориентированные, имитационные и др., т.е. это совокупность нескольких различных моделей каждая из которых описывает отдельные перспективы его структуры, а все вместе они образуют полное и комплексное представление о моделируемом объекте.
КРАТКОЕ ОПИСАНИЕ МЕТОДОЛОГИЙ И МЕТОДОВ
Методология структурного анализа и проектирования SADT (Structured analysis and design technique) – представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта (производимые им действия и связи между этими действиями) какой-либо предметной области. Разработана Дугласом Россом в 1969-1973 годах. Эта методология возникла под сильным влиянием PLEX, концепции клеточной модели человек-ориентированных функций Хори, общей теории систем технологии программирования и кибернетики. Она изначально создавалась для проектирования систем более общего назначения по сравнению с другими структурными методами, выросшими из проектирования программного обеспечения.
Основным рабочим элементом методологии является диаграмма. Модель SADT объединяет и организует диаграммы в иерархические древовидные структуры, при этом чем выше уровень диаграммы, тем она менее детализирована. В состав диаграммы входят блоки, изображающие активности моделируемой системы, и дуги, связывающие блоки вместе и изображающие взаимодействия, и взаимосвязи между блоками.
Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. Для уже существующих систем SADT может быть использована для анализа функций, выполняемых системой, а также для указания механизмов, посредством которых они осуществляются.
Элементы методологии SADT (синтаксис):
Самая распространенная нотация методологии SADT: IDEF0 (для функционального моделирования бизнес-процессов).
Диаграмма потоков данных DFD (Data Flow Diagrams) – это методология (стандарт) описания бизнес-процессов верхнего уровня или макропроцессов. На диаграммах потоков данных показываются работы, которые входят в состав описываемого бизнес-процесса, а также показываются входы и выходы каждой из работ. Данные входы и выходы представляют из себя информационные, либо материальные потоки. При этом выходы одной работы могут являться входами для других.
При построении DFD-схемы бизнес-процесса нужно помнить, что данная схема показывает материальные и информационные потоки, и не показывает временную последовательность этих потоков, так как они могут выполняться одновременно или может существовать несколько вариантов различных последовательностей их выполнения, которые в свою очередь могут зависеть от разных точек зрения на этот процесс.
При построении DFD-схемы бизнес-процесса нужно показывать подразделения и должности участников. Рекомендуется использовать правила при формулировке названий:
Основными элементами диаграмм потоков данных являются:
Нотации данной методологии DFD:
Диаграмма потоков работ WFD (Work Flow Diagram) – представляет собой диаграмму потоков работ, которая используется для описания бизнес-процессов нижнего уровня, где возникает необходимость показывать временную последовательность выполнения работ в зависимости от получающихся результатов и событий, возникающих в ходе выполнения процесса. Здесь главным объектом описания становятся действия (работы), а не потоки данных (как в методологии DFD).
Для этого используются следующие графические объекты, с помощью которых описывается процесс: логические операторы, события начала и окончания процесса, а также элементы, показывающие временные задержки.
С помощью логических операторов (блоки принятия решений) показывают альтернативы, которые происходят в процессе: в каких случаях процесс протекает по одной технологии, а в каких случаях по другой.
С помощью событий начала и окончания процесса показывается, когда процесса начинается и когда заканчивается.
Нотация, разработанная в данной методологии: IDEF3 (PFDD – Process Flow Description Diagrams), т.е. диаграмма описания последовательности этапов процесса, с помощью которой моделируется последовательность действий, реализуемых в рамках бизнес-процесса.
Архитектура интегрированных информационных систем ARIS (Architecture of Integrated Information Systems) — это архитектура, концепция, методология, инструментальная среда (тиражируемый программный продукт), нотация, а также это система взглядов на деятельность организации, которая позволяет проектировать, проводить анализ, оптимизацию и внедрение бизнес-процессов.
Методология ARIS был разработана Августом-Вильгельмом Шеером в 1990х, сегодня права принадлежат немецкой компании Software AG.
В основе методологии лежит представление деятельности организации в виде различных моделей и сведение этих моделей в единую систему. Модели составляют здание ARIS – пять типов представлений, связанных между собой и отражающих основные аспекты деятельности организации:
При этом каждая из этих точек зрения разделяется ещё на три подуровня:
Для описания бизнес-процессов предлагается использовать около 80 типов моделей, каждая из которых принадлежит тому или иному аспекту. ARIS предоставляет визуальный инструментарий для обеспечения наглядности моделей.
Продукты линейки ARIS Design Platform включают в себя программы различной направленности, например, для моделирования архитектуры предприятия ARIS Business Architect и ARIS IT Architect или для имитационного моделирования и анализа бизнес-процессов – ARIS Business Simulator. Кроме того, доступна бесплатная программа ARIS Express с несколько урезанной функциональностью.
Серьезное преимущество ARIS перед другими инструментами моделирования заключается в том, что в нем хорошо развиты графические средства представления сформированных моделей.
К числу наиболее значимых и практически используемых нотаций ARIS можно отнести:
Диаграмма перехода состояний для проектирования систем реального времени STD (State Transition Diagram) – демонстрируют поведение разрабатываемой программной системы при получении управляющих воздействий (извне). Такие диаграммы позволяют осуществить декомпозицию управляющих процессов, происходящих в системе, и описать отношение между управляющими потоками.
С помощью STD можно моделировать последующее функционирование системы исходя из предыдущих и текущих состояний. Моделируемая система в текущий момент времени находится только в одном состоянии из всего множества состояний. В течение времени она может изменить свое состояние и тем самым перейти в следующее состояние из заданного множества состояний. Для перехода в состояние нужно какое-либо особое условие – условие перехода. Оно может быть информационным (условие появления информации) или временным.
STD состоит из следующих объектов:
К самым распространенным нотациям и языкам моделирования STD можно отнести:
Модель «сущность-связь» (ERM, Entity-Relationship Model или ER-модель) – модель данных, позволяющая описывать концептуальные схемы предметной области.
ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных. С ее помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями.
В основе ER-модели лежат понятия:
ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств ее визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена диаграмма «сущность-связь» (ERD, Entity-Relationship Diagram, ER-диаграмма).
Понятия ER-модель и ER-диаграмма часто ошибочно не различают, хотя для визуализации ER-моделей могут быть использованы и другие графические нотации, либо визуализация может вообще не применяться (например, использоваться текстовое описание).
Используемые нотации (графические модели):
Рассмотрены самые известные и максимально используемые методы и методологии описания бизнес-процессов. В части 2 данной статьи рассмотрим уже нотации. И попробуем построить в каждой из нотаций интересный пример.
