В какой программе сделать диаграмму idef0

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

· контекстная – одна для каждой модели, она представляет самое общее описание системы и ее взаимодействие с окружающей средой;

· декомпозиции – отражает более детальное описание отдельной части бизнес-процесса;

· дерева узлов – описывает иерархическую зависимость работ;

· иллюстративная – для иллюстрации отдельных видов моделей.

Основными элементами модели IDEF0 являются: функциональный блок и стрелка.

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

Как создать диаграмму или визуализацию любого процесса в diagrams.net

Для каждого функционального блока в рамках модели определяется:

· уникальный номер, который присваивается автоматически

· название, которое должно отражать действие, оно задается только в виде глагола или отглагольного существительного, например, ИЗГОТОВИТЬ ДЕТАЛЬ, СОБРАТЬ ДАННЫЕ, ИЗГОТОВление детели, сбор данных;

· описание, которое дает развернутую смысловую характеристику действия. Например, сбор данных по телефону, сбор данных по электронной почте, проведение опроса и др.

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

Рис.1. Пример контекстной диаграммы

Для того чтобы задать другие свойства блока необходимо нажать правой клавишей мыши на изображении блока и выбрать нужное свойство Activity properties (рис. 2). Для каждого действия необходимо задать его имя (Name) и описание (Definition). Разработка модели начинается с определения контекстной диаграммы, в которой определяется взаимодействие модели с внешними компонентами (рис. 1).

Рис. 2. Редактор задания свойств действия.

Второй основной элемент IDEFO-методологии — это стрелка. Стрелка бывает четырех типов: стрелка-вход, выход, механизм и управление.

1. Вход (Input) рисуется, как входящая в левую грань функционального блока. Вход показывает, что требуется для выполнения функции, например: КЛИЕНТ.

2. Выход (Output) – исходящая из правой грани блока. Выход — результат функции, например: Реализованная услуга

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

4. Управление (Control) рисуется входящей в верхнюю грань блока. Управление ограничивает (регламентирует) выполнение функции, например, ПРАВИЛА, ЛИЦЕНЗИЯ.

Ramus — функциональная схема информационной системы и бизнес процессов (DFD и IDEF0).

Каждая стрелка (рис.3) определяется уникальным именем (Name), которое задается существительным в единственном числе им. падеже, и описанием (Definition, Note) (рис. 4). Имена вновь внесенных стрелок автоматически заносятся в словарь (Arrow Dictionary).

Рис. 3. Задание имени стрелки.

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

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

Рис. 4. Задание свойств Definition и Note

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

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

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

Рис. 5. Туннельная стрелка

Для их «перетаскивания» наверх нужно щелкнуть правой кнопкой мыши по квадратным скобкам граничной стрелки и выбрать из выпадающего меню Arrow Tunnel. Появится диалоговое окно Border Arrow Editor (рис. 6).

Рис. 6. Диалог Border Arrow Editor

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

Таким образом, строится иерархическая система диаграмм, на каждом уровне которой бизнес-процесс описывается подробнее. Пример диаграммы приведен на рис. 7.

Рис. 7. Декомпозиция диаграммы процесса

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

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

Назначение процесса аналогично процессу в модели IDEF0. В этой модели применяются специальные элементы: хранилище данных и внешняя сущность.

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

Внешняя сущность представляет собой внешний источник или получатель данных. Ее имя должно содержать существительное, например, «клиент». Предполагается, что объекты, представленные как внешние сущности, не должны участвовать ни в какой обработке. На панели инструментов внешняя сущность задана пиктограммой . Пример DFD диаграммы приведен на рис.8.

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

Рис. 8. Диаграмма потока данных

Источник: mydocx.ru

Палитра инструментов для построения диаграмм idef0.

Состав палитры инструментов изменяется автоматически, когда происходит переключение с одной нотации на другую, поэтому рассмотрим палитру инструментов диаграммы IDEF0 (рис. 42), которая возникает по умолчанию.

Рис. 42.

На панели инструментов AllFusion PM расположены следующие инструменты:

1. Кнопка «Pointer Tool» используется для выбора и определения позиции объектов, добавленных в диаграмму.
2. Кнопка «Activity Box Tool» используется для установки блоков в диаграмме.
3. Кнопка «Precedence Arrow Tool» используется, чтобы устанавливать дуги в диаграмме.
4. Кнопка «Squiggle Tool» используется для создания тильды, которая соединяет дугу с ее названием.
5. Кнопка «Text Тооl» используется для создания текстовых блоков.
6. Кнопка «Diagram Dictionary Editor» открывает диалоговое окно «Diagram Manager» для перехода на какую-либо диаграмму или удаления диаграммы.
7. Кнопка «Go to Sibling Diagram» используется для перехода и отображения связанных диаграмм: FEO-диаграмм и диаграмм дерева узлов, построенных на основе текущей диаграммы.
8. Кнопка «Go to Parent Diagram» является переходом на родительскую диаграмму.
9. Кнопка «Go to Child Diagram» используется для перехода на дочернюю диаграмму, если она существует, или для создания новой дочерней диаграммы, декомпозирующей выделенную работу.

Контрольные вопросы:

1. В чем суть методологии IDEF0?
2. Назовите состав модели IDEF0.
3. Назовите состав диаграммы IDEF0.
4. Дайте характеристику объекта «работа» («функция») в диаграммах IDEF0: смысл, графическое представление, правила именования.
5. Дайте характеристику объекта «стрелка» в диаграммах IDEF0: смысл, графическое представление, правила именования, классификации стрелок.
6. Проиллюстрируйте допустимые связи в диаграммах IDEF0.
7. Как нумеруются диаграммы и работы в IDEF0?
8. Как строится диаграмма IDEF0?
9. Дайте характеристику палитры инструментов IDEF0?

4.6. Построение диаграмм потоков данных (dfd).

Диаграммы потоков данных (Data flow diagramming, DFD) обеспечивают графическое представление взаимодействия данных и процессов (работ). Используются для описания документооборота и обработки информации. Диаграммы DFD можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации. В AllFusion PM для построения диаграмм потоков данных используется нотация Гейна-Сарсона (Gane/Sarson).

Состав dfd-модели.

Модель, выполненная в методологии DFD, может содержать четыре типа диаграмм:

• контекстную диаграмму;
• диаграммы декомпозиции;
• диаграммы дерева узлов (будут рассмотрены позднее);
• FEO-диаграммы (будут рассмотрены позднее).

Состав dfd-диаграммы.

В состав диаграммы DFD могут входить четыре графических объекта: функциональные блоки, отображающие работы, стрелки, внешние ссылки и хранилища данных. Кроме этого на диаграмме, выполненной в методологии IDEF0, могут размещаться текстовые блоки. Рассмотрим более подробно объекты диаграммы DFD.

Работы.

В DFD работы представляют собой функции системы, преобразующие входы в выходы, например, обрабатывают и изменяют входную информацию в выходную. Работы представлены на диаграммах в виде прямоугольников со скругленными углами, например, работа “Ведение системы обработки информации” на рис. 44. Смысл работ в DFD совпадает со смыслом работ IDEF0 и IDEF3. Так же как работы IDEF0, они имеют входы и выходы, но не поддерживают управления и механизмы.

Источник: studfile.net

Как анализировать бизнес-процессы с помощью IDEF0

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

Что такое IDEF0

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

Сначала мы поговорим о том, как рисовать IDEF0 диаграммы, а потом, как с помощью них анализировать процессы.

Полезные правила

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

Рецепт бургера

Булочки для бургера — 3 шт.
Фарш мясной — 400 г
Сыр твердый — 30-50 г
Помидор — 1-2 шт.
Огурец соленый — 1 шт.
Лук синий (фиолетовый) — 1 шт.
Салатные (капустные) листья — 5-6 шт.
Майонез — 2 ч. л.
Кетчуп (любой) — 2 ч. л.
Перец черный — по вкусу
Соль — по вкусу
Масло подсолнечное — для жарки

1. Подготавливаем необходимые ингредиенты для бургера.
2. В мясной фарш добавляем соль и перец по вкусу, хорошо вымешиваем. Формируем шарик, расплющиваем его в руках, чтобы получилась плоская котлета. Надавливаем большим пальцем в центр котлеты, чтобы она не вздулась во время обжаривания.
3. Обжариваем котлету 4-5 минут с каждой стороны. На готовую котлету кладем тонкий кусочек сыра.
4. Помидоры нарезаем кружочками, твердый сыр — тонкими пластинами, соленый огурец — тонкими кружочками. В отдельной емкости смешиваем майонез и кетчуп.
5. Булочку разрезаем пополам и смазываем соусом из майонеза и кетчупа.
6. Выкладываем на соус порванный руками листья салата (капусты).
7. На салат кладем нарезанный тонкими колечками лук.
8. На лук выкладываем кружочек помидора.
9. На кружочек помидора выкладываем котлету.
10. На котлету выкладываем пару ломтиков соленого огурца и ломтик сыра.
11. Накрываем бургер второй частью булочки. По такому же принципу формируем остальные бургеры.

Контекстная диаграмма

В IDEF0 всё начинается с контекстной диаграммы.

Контекстная диаграмма A-0

Контекстная диаграмма обозначается как A-0. Эта диаграмма позволяет определить границы моделирования. На ней есть всего один блок, он же действие, он же активность. В стандарте IDEF0 блоки принято называть глаголами. Это требование поможет вам не допускать ошибок, а так же добавляет читаемости к диаграмме.

Блок и стрелки на контекстной диаграмме определяет связи процесса с внешним миром.

Стрелки, которые приходят к блоку слева — всегда входы в процесс. Это необходимые для передела ресурсы (объекты переменных затрат). То есть, если для приготовления бургера мы «потратим» булочку, то булочка — это вход.

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

Стрелки, приходящие сверху — стрелки управления. Они определяют способы, условия и ограничения выполнения процесса.

Единственная выходящая стрелка из блока — стрелка справа. И это выход. То есть то, что получается в результате работы процесса. Как видно из нашей контекстной диаграммы — это далеко не всегда только основной результат процесса. В нашем случае мы испачкали нож и сковороду и вероятно где-то за границами этого процесса мы их помоем, тем не менее это тоже результат приготовления бургера.

Стрелки принято называть существительными.

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

Декомпозиция первого уровня

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

Блоки на диаграммах располагаются не в порядке последовательности процесса, а в порядке доминирования действий. То есть, чем более важна эта часть процесса, тем выше она располагается. Тем не менее очень часто доминирование совпадает с последовательностью.

Диаграмма А0

Я разделил процесс «Приготовить бургер» на три действия — подготовить ингредиенты, приготовить котлету, собрать бургер. То есть мы видим более подробное описание действия контекстной диаграммы.

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

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

Представляю исправленные версии диаграмм.

Контекстная диаграмма А-0
Диаграмма А0

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

Декомпозиция второго уровня

По аналогии сделаем декомпозицию действий подготовить ингредиенты и приготовить котлету.

Диаграмма А1 Подготовить ингредиенты

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

Диаграмма А2 Приготовить котлету

Декомпозиция приготовить котлету прошла гладко.

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

Что можно увидеть на этих диаграммах?

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

Второй очевидный момент — мы видим все необходимые ресурсы для работы процесса. Соответственно, если в других процессах мы не позаботились о том, чтобы передавать ресурсы своевременно, то наш процесс будет давать сбой.

В третьих, мы видим, что процесс даёт на выходе на самом деле.

И одно из самых важных — мы видим как контролируется процесс. В нашем случае со стороны управления приходит только рецепт. Там могут быть прочие нормативы и приказы, распорядки, традиции и так далее. Но всё это оставляет приготовление бургера на совести повара. Если мы вспомним ресторанную практику, то отпускаемую продукцию контролирует шеф-повар.

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

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

Как посчитать стоимость процесса?

На диаграммах вы могли увидеть, что в нижнем левом углу каждого действия стоят цифры 0,00. Обычно там пишется стоимость данного действия.

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

Если мы замешиваем соус только каждый второй бургер, то вероятность прохождения этого блока 0,5. Самый популярный центр затрат — персонал. Обычно единица измерения персонала — трудовой час. То есть берётся зарплата сотрудника за час и умножается на количество часов (дней, минут, секунд), потраченное на это действие.

Таким образом, стоимость действия контекстной диаграммы, а значит и всего процесса — сумма стоимости всех действий на диаграмме декомпозиции. Стоимость действия на диаграмме декомпозиции — сумма стоимости всех «поддействий».

Тогда варьируя цену центров затрат, можно посмотреть, как будет увеличиваться или уменьшаться стоимость всего процесса. Возможно, увеличение стоимости процесса на организацию контроля уменьшит стоимость всего процесса в целом, так как уменьшится вероятность прохождения других действий. Тут нужно эксперементировать.

Итог

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

P. S. Стоимость и скорость бизнес-процесса подробно рассмотрены в следующей статье .

Источник: dzen.ru