Наличие в диаграммах DFD элементов для обозначения источников , приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс документооборота. Однако для описания логики взаимодействия информационных потоков более подходит IDEF3, называемая также workflow diagramming, — методология моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов . Диаграммы Workflow могут быть использованы в моделировании бизнес-процессов для анализа завершенности процедур обработки информации. С их помощью можно описывать сценарии действий сотрудников организации, например последовательность обработки заказа или события, которые необходимо обработать за конечное время. Каждый сценарий сопровождается описанием процесса и может быть использован для документирования каждой функции.
IDEF3 — это метод, имеющий основной целью дать возможность аналитикам описать ситуацию, когда процессы выполняются в определенной последовательности, а также описать объекты, участвующие совместно в одном процессе .
Построение диаграммы IDEF0 в process modeler (bpwin)
Техника описания набора данных IDEF3 является частью структурного анализа . В отличие от некоторых методик описаний процессов IDEF3 не ограничивает аналитика чрезмерно жесткими рамками синтаксиса, что может привести к созданию неполных или противоречивых моделей.
IDEF3 может быть также использован как метод создания процессов . IDEF3 дополняет IDEF0 и содержит все необходимое для построения моделей, которые в дальнейшем могут быть использованы для имитационного анализа.
Каждая работа в IDEF3 описывает какой-либо сценарий бизнес-процесса и может являться составляющей другой работы. Поскольку сценарий описывает цель и рамки модели, важно, чтобы работы именовались отглагольным существительным, обозначающим процесс действия, или фразой, содержащей такое существительное.
Точка зрения на модель должна быть документирована. Обычно это точка зрения человека, ответственного за работу в целом. Также необходимо документировать цель модели — те вопросы, на которые призвана ответить модель.
Диаграмма является основной единицей описания в IDEF3. Важно правильно построить диаграммы, поскольку они предназначены для чтения другими людьми (а не только автором).
Единицы работы — Unit of Work (UOW) — также называемые работами ( activity ), являются центральными компонентами модели. В IDEF3 работы изображаются прямоугольниками с прямыми углами и имеют имя, выраженное отглагольным существительным, обозначающим процесс действия, одиночным или в составе фразы, и номер ( идентификатор ); другое имя существительное в составе той же фразы обычно отображает основной выход (результат) работы (например, «Изготовление изделия»). Часто имя существительное в имени работы меняется в процессе моделирования, поскольку модель может уточняться и редактироваться. Идентификатор работы присваивается при создании и не меняется никогда. Даже если работа будет удалена, ее идентификатор не будет вновь использоваться для других работ . Обычно номер работы состоит из номера родительской работы и порядкового номера на текущей диаграмме.
Связи показывают взаимоотношения работ. Все связи в IDEF3 однонаправлены и могут быть направлены куда угодно, но обычно диаграммы IDEF3 стараются построить так, чтобы связи были направлены слева направо. В IDEF3 различают три типа стрелок, изображающих связи , стиль которых устанавливается через меню Edit/Arrow Style :
Старшая (Precedence)
сплошная линия, связывающая единицы работ (UOW). Рисуется слева направо или сверху вниз. Показывает, что работа-источник должна закончиться прежде, чем работа-цель начнется.
Отношения (Relational Link)
пунктирная линия, использующаяся для изображения связей между единицами работ (UOW) а также между единицами работ и объектами ссылок.
Потоки объектов (Object Flow)
стрелка с двумя наконечниками, применяется для описания того факта, что объект используется в двух или более единицах работы, например, когда объект порождается в одной работе и используется в другой.
Старшая связь показывает, что работа-источник заканчивается ранее, чем начинается работа-цель. Часто результатом работы-источника становится объект , необходимый для запуска работы-цели. В этом случае стрелку, обозначающую объект , изображают с двойным наконечником. Имя стрелки должно ясно идентифицировать отображаемый объект . Поток объектов имеет ту же семантику, что и старшая стрелка.
Отношение показывает, что стрелка является альтернативой старшей стрелке или потоку объектов в смысле задания последовательности выполнения работ — работа-источник не обязательно должна закончиться, прежде чем работа-цель начнется. Более того, работа-цель может закончиться прежде, чем закончится работа-источник.
Окончание одной работы может служить сигналом к началу нескольких работ , или же одна работа для своего запуска может ожидать окончания нескольких работ . Для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы, используются перекрестки (Junction). Различают перекрестки для слияния ( Fan -in Junction ) и разветвления стрелок ( Fan -out Junction ). Перекресток не может использоваться одновременно для слияния и для разветвления. Для внесения перекрестка служит кнопка
— (добавить в диаграмму перекресток — Junction ) в палитре инструментов. В диалоге Select Junction Type необходимо указать тип перекрестка .
Смысл каждого типа приведен в таблице 8.1.
Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. Можно редактировать свойства перекрестка при помощи диалога Junction Properties, который вызывается в контекстном меню перекрестка командой Definition/Note. В отличие от IDEF0 и DFD в IDEF3 стрелки могут сливаться и разветвляться только через перекрестки .
Объект ссылки в IDEF3 выражает некую идею, концепцию или данные, которые нельзя связать со стрелкой, перекрестком или работой. Для внесения объекта ссылки служит кнопка
— (добавить в диаграмму объект ссылки — Referent ) в палитре инструментов. Объект ссылки изображается в виде прямоугольника, похожего на прямоугольник работы
. Имя объекта ссылки задается в диалоге Referent ( пункт Name контекстного меню ), в качестве имени можно использовать имя какой-либо стрелки с других диаграмм или имя сущности из модели данных. Объекты ссылки должны быть связаны с единицами работ или перекрестками пунктирными линиями. Официальная спецификация IDEF3 различает три стиля объектов ссылок — безусловные ( unconditional ), синхронные (synchronous) и асинхронные ( asynchronous ). BPwin поддерживает только безусловные объекты ссылок. Синхронные и асинхронные объекты ссылок, используемые в диаграммах переходов состояний объектов, не поддерживаются.
Источник: intuit.ru
Методология моделирования IDEF3 для описания потоков работ (Work Flow Modeling).
В отличие от нотации IDEF0 в нотации IDEF3 стороны четырехугольника, изображающего функцию (работу, процесс), не используют для привязки входов различного типа. Более того, в четырехугольник может входить и выходить только одна стрелка. В противном случае правила построения диаграмм в IDEF3 будут нарушены.
При декомпозиции процессов в IDEF3 не происходит мигрирования и туннелирования стрелок. Аналитик должен сам заботиться о связности моделирования процесса и корректности декомпозиции.
Нотацию IDEF3 целесообразно применять в случае относительно простых процессов на нижнем уровне декомпозиции, т.е. процессов уровня рабочих мест. В этом случае схема процесса может служить основой для создания документов, регламентирующих работу исполнителей. Очевидно, что процесс в нотации IDEF3 является «плоским». При помощи этой нотации достаточно сложно создавать комбинированные модели, в которых бы сочетались описания потоков работ и процессы управления этими работами. Этот факт становится очевидным в особенности при сравнении описаний процессов в нотации IDEF3 и IDEF0.
- Синтаксис и семантика моделей IDEF3
- Диаграммы
- Единица работы. Действие
- Связи
- Соединения
- Указатели
- Декомпозиция действий
- Требования IDEF3 к описанию бизнес-процессов
IDEF3 — способ описания процессов с использованием структурированного метода, позволяющего эксперту в предметной области представить положение вещей как упорядоченную последовательность событий с одновременным описанием объектов, имеющих непосредственное отношение к процессу.
IDEF3 является технологией, хорошо приспособленной для сбора данных, требующихся для проведения структурного анализа системы.
В отличие от большинства технологий моделирования бизнес-процессов, IDEF3 не имеет жестких синтаксических или семантических ограничений, делающих неудобным описание неполных или нецелостных систем. Кроме того, автор модели (системный аналитик) избавлен от необходимости смешивать свои собственные предположения о функционировании системы с экспертными утверждениями в целях заполнения пробелов в описании предметной области. На рис. 3.1 изображен пример описания процесса с использованием методологии IDEF3.
IDEF3 также может быть использован как метод проектирования бизнес-процессов. IDEF3-моделирование органично дополняет традиционное моделирование с использованием стандартаметодологии IDEF0. В настоящее время оно получает все большее распространение как вполне жизнеспособный путь построения моделей проектируемых систем для дальнейшего анализа имитационными методами. Имитационное тестирование часто используют для оценки эксплуатационных качеств разрабатываемой системы. Более подробно методы имитационного анализа будут рассмотрены ниже.
Рис.3.1 Описание процесса в методологии IDEF3
Синтаксис и семантика моделей IDEF3
Основой модели IDEF3 служит так называемый сценарий бизнес-процесса, который выделяет последовательность действий или подпроцессов анализируемой системы. Поскольку сценарий определяет назначение и границы модели, довольно важным является подбор подходящего наименования для обозначения действий. Для подбора необходимого имени применяются стандартные рекомендации по предпочтительному использованию глаголов и отглагольных существительных, например «обработать заказ клиента» или «применить новый дизайн».
Сценарий для большинства моделей должен быть документирован. Обычно это название набора должностных обязанностей человека, являющегося источником информации о моделируемом процессе.
Также важным для системного аналитика является понимание цели моделирования — набора вопросов, ответами на которые будет служить модель, границ моделирования — какие части системы войдут, а какие не будут отображены в модели, и целевой аудитории — для кого разрабатывается модель.
Диаграммы
Как и в любой рассматриваемой в этой книге технологии моделирования действий, главной организационной единицей модели IDEF3 является диаграмма. Взаимная организация диаграмм внутри модели IDEF3 особенно важна в случае, когда модель заведомо создается для последующего опубликования или рецензирования, что является вполне обычной практикой при проектировании новых систем. В этом случае системный аналитик должен позаботиться о таком информационном наполнении диаграмм, чтобы каждая из них была самодостаточной и в то же время понятной пользователю.
Единица работы. Действие
Аналогично другим технологиям моделирования действие, или в терминах IDEF3 «единица работы» (Unit of Work — UOW), — другой важный компонент модели. Диаграммы IDEF3 отображают действие в виде прямоугольника. Как уже отмечалось, действия именуются с использованием глаголов или отглагольных существительных, каждому из действий присваивается уникальный идентификационный номер. Этот номер не используется вновь даже в том случае, если в процессе построения модели действие удаляется. В диаграммах IDEF3 номер действия обычно предваряется номером его родителя (рис. 3.2)
Рис . Об этом говорит сайт https://intellect.icu . 3.2. Изображение и нумерация действия в диаграмме IDEF3
Связи
Связи выделяют существенные взаимоотношения между действиями. Все связи в IDEF3 являются однонаправленными, и хотя стрелка может начинаться или заканчиваться на любой стороне блока, обозначающего действие, диаграммы IDEF3обычно организуются слева направо таким образом, что стрелки начинаются на правой и заканчиваются на левой стороне блоков. В табл. 3.1 приведены три возможных типа связей.
Связь типа «временное предшествование». Как видно из названия, связи этого типа показывают, что исходное действие должно полностью завершиться, прежде чем начнется выполнение конечного действия. Связь должна быть поименована таким образом, чтобы человеку, просматривающему модель, была понятна причина ее появления.
Во многих случаях завершение одного действия инициирует начало выполнения другого, как показано на рис. 3.3. В этом примере автор должен принять рекомендации рецензентов, прежде чем начать вносить соответствующие изменения в работу.
Временнбе предшествование (Temporal precedence)
Исходное действие должно завершиться, прежде чем конечное действие сможет начаться
Объектный поток (Object flow)
Выход исходного действия является входом конечного действия. Из этого, в частности, следует, что исходное действие должно завершиться, прежде чем конечное действие сможет начаться
Нечеткое отношение (Relationship)
Вид взаимодействия между исходным и конечным действиями задается аналитиком отдельно для каждого случая использования такого отношения
Рис. 3.3. Связь типа “временное предшествование” между действиями 1 и 2.
Связь типа «объектный поток». Одна из наиболее часто встречающихся причин использования связи типа «объектный поток» заключается в том, что некоторый объект, являющийся результатом выполнения исходного действия, необходим для выполнения конечного действия. Обозначение такой связи отличается от связи временного предшествования двойной стрелкой. Наименования потоковых связей должны четко идентифицировать объект, который передается с их помощью. Временная семантика объектных связей аналогична связям предшествования, это означает, что порождающее объектную связь исходное действие должно завершиться, прежде чем конечное действие может начать выполняться.
Связь типа «нечеткое отношение». Связи этого типа используются для выделения отношений между действиями, которые невозможно описать с использованием предшественных или объектных связей. Значение каждой такой связи должно быть определено, поскольку связи типа «нечеткое отношение» сами по себе не предполагают никаких ограничений. Одно из применений нечетких отношений — отображение взаимоотношений между параллельно выполняющимися действиями. Наиболее часто нечеткие отношения используются для описания специальных случаев связей предшествования, например для описания альтернативных вариантов временного предшествования.
Соединения
Завершение одного действия может инициировать начало выполнения сразу нескольких других действий или, наоборот, определенное действие может требовать завершения нескольких других действий до начала своего выполнения. Соединения разбивают или соединяют внутренние потоки и используются для описания ветвления процесса:
- разворачивающие соединения используются для разбиения потока. Завершение одного действия вызывает начало выполнения нескольких других;
- сворачивающие соединения объединяют потоки. Завершение одного или нескольких действий вызывает начало выполнения другого действия.
В табл. 2.2 объединены три типа соединений.
Источник: intellect.icu
Методология IDEF0
IDEF0 — это методология графического описания систем и процессов деятельности организации как множества взаимосвязанных функций. Она позволяет исследовать функции организации, не связывая их с объектами, обеспечивающими их реализацию.
В стандарте IDEF0 посредством входа показывают объекты — информационные и материальные потоки, которые преобразуются в бизнес- процессе. С помощью управления показываются объекты — материальные и информационные потоки, которые не преобразуются в процессе, по нужны для его выполнения. Используя механизмы IDEF0 можно отображать инструменты и ресурсы, с помощью которых бизнес-процесс реализуется (например, технические средства, люди, информационные системы и т.д.). Выход бизнес-процесса, описанного в стандарте IDEF0, полностью соответствует по смыслу выходу процесса, описанному с помощью DFD-схeмы.
Основные элементы диаграммы IDEF0.
Методология IDEF0 незначительно отличается от классической схемы описания бизнес-процессов DFD. Основным отличием является наличие в языке дополнительной аналитики. Данный стандарт описания бизнес-процессов предлагает показывать не просто входы и выходы, как это делается в DFD-формате, он предлагает ввести три типа входов. Первый тип входов назвали также входом, а два других входа назвали управлением и механизмами.
Основными элементами диаграммы в нотации IDEF0 являются:
- • блоки, в виде которых представлены процессы, функции, операции, действия (в зависимости от степени детализации);
- • стрелки, в виде которых на диаграмме отражают информационные и материальные ресурсы, связанные с функциями.
В стандарте IDEFO под блоком подразумеваются функции. Сейчас, поскольку большее распространение в управлении организацией получила концепция процессного подхода, как правило, в виде блоков отражают процессы, подпроцессы и операции. Далее при рассмотрении методологии IDEF будет использоваться термин функция, под которым могут подразумеваться также процессы, подпроцессы, операции и действия.
Стандартный блок приведен на рис. 5.2. Он представляет собой прямоугольник, внутри которого по центру расположено название блока (функции) и его номер справа внизу. Название должно быть представлено в виде активного глагола. Например, «Обработать обращение», «Оформить договор», «Согласовать».
В практике российских аналитиков также используются отглагольные формы, например, «Обработка обращения», «Оформление договора». Однако такой способ названия блоков несколько нарушает требования стандарта IDEF0. Номера блоков используют при декомпозиции функции и текстовом описании модели. Стоит обратить внимание на то, что при декомпозиции у блока сохраняется как название, так и номер.
Рис. 5.2. Стандарт представления диаграммы IDEF0
Стрелки в стандарте IDEF0 не показывают движение данных или последовательность событий, как на DFD- или WFD- диаграммах. Здесь они предназначены для указания данных и объектов, необходимых для осуществления данной функции, и что в результате ее реализации получается. Стрелки могут быть прямыми или ломаными. В последнем случае угол сгиба должен равняться 90°.
На схеме они должны располагаться вертикально или горизонтально, но диагонали — не допускается. Концы стрелок должны касаться внешней границы блока, но не заходить за нее. Также недопустимо присоединять стрелку к углу блока, поскольку в зависимости от того, с какой стороны к блоку подходит стрелка, можно определить назначение объекта, который она представляет. В рамках данного стандарта выделяют четыре типа стрелок: входящие (вход, Input), выходящие (выход, Output), стрелки управления (управление, Control), стрелки механизма (механизм, Mechanism).
В соответствии с используемой в стандарте кодификацией (ICOM) на диаграмме стрелки обозначаются первыми буквами латинского названия, т.е.: вход — I, управление — С, выход — О, механизм — М.
Входящая стрелка показывает движение объекта в сторону блока слева. Этот объект преобразуется в ходе выполнения функции (указанной в виде блока) в выходной объект. Таким образом, объект, который получается в результате реализации функции, — это выход, выходящая стрелка, которая отражается справа от блока. Выход бизнес-процесса, описанного в стандарте IDEF0, полностью соответствует по смыслу выходу процесса, описанному при помощи DFD-схемы.
Здесь нужно учитывать, что если на вход поступает информация, то и на выходе из функции тоже будет информация. Если на входе — материалы, то и на выходе — какой-либо материальный объект. Если на входе — человек, то и на выходе — человек.
Часто при описании бизнес-процессов с помощью методологии IDEF0 начинающие аналитики допускают ошибку, заключающуюся в несоблюдении правила: «Сущности входящего и выходящего объекта одинаковы».
Рассмотрим для примера функцию «Припять сотрудника на работу». Правило моделирования с помощью IDEF0 говорит о том, что функциональный блок предназначен для описания функции, преобразующей входящий объект в исходящий.
Таким образом, можно говорить о том, что при оформлении нового работника потенциальный работник преобразуется в сотрудника, имеющего конкретную должность в данной организации. Если процесс рассматривать с позиции работника отдела кадров, который должен выполнить необходимые операции с документами, то оформление нового работника может начаться с момента, когда он принесет резюме и сообщит о своем желании работать в этой организации, и закончится, когда приказ о приеме на работу подпишут обе стороны. В данном случае речь идет о документационном оформлении работника. Поэтому совершенно некорректно на входе указывать человека, а на выходе документ, и наоборот (рис. 5.3).
Рис. 5.3. IDEF0-диаграмма процесса «Прием сотрудника на работу»
Стрелка управления, которая входит в блок сверху, показывает условия и элементы управления, необходимые для выполнения функции, напри
мер: инструкция по сборке мебели, руководство пользователя информационной системы, регламент работы с обращениями граждан.
Стрелка механизма, отображенная снизу от блока, представляет то, с помощью чего реализуется данная функция. Существует два вида стрелок механизма:
- 1) стрелка механизма, направленная вверх, которая показывает механизмы, инструменты, ресурсы, поддерживающие выполнение функции, например: должностное лицо, информационная система, станок, оборудование;
- 2) стрелка механизма, направленная вниз, предназначенная для отображения на диаграмме обращения к блоку, входящему в состав другой модели (редко используется).
Стрелки называются существительными или словосочетаниями, состоящими из существительного и прилагательного, например см. рис. 5.3, для функции «Принять сотрудника на работу» входящая стрелка называется «Потенциальный сотрудник», выходящая — «Сотрудник».
Методология IDEF0 предполагает разработку нескольких диаграмм, с помощью которых описываются функция или процесс: контекстная диаграмма; диаграмма верхнего уровня; набор дочерних диаграмм, на которых отражено более детальное представление об объекте моделирования.
Контекстная диаграмма представляет собой один блок со стрелками, которые отражают связи описываемого процесса с внешней средой. Таким образом, можно говорить о том, что контекстная диаграмма показывает область моделирования и ее границы. Название блока соответствует названию описываемой функции (процесса). Номер контекстной диаграммы всегда нулевой.
Его принято обозначать «АО». Когда речь идет об описании деятельности организации или подразделения, то при создании контекстной диаграммы в качестве названия указывается название проекта или краткая формулировка описываемой деятельности. Например, «Оформить дебетовую банковскую карту» или «Управлять персоналом».
Такой же подход применяется и при названии стрелок, входящих и исходящих от единственного блока контекстной диаграммы. На рис. 5.4 приведен пример контекстной диаграммы процесса «Управление претензиями клиентов». Кроме того, контекстная диаграмма должна содержать описание цели построения модели и сведения о точке зрения, в соответствии с которой строится модель IDEF0.
Диаграмма верхнего уровня является первой дочерней диаграммой по отношению к контекстной. На рис. 5.5 приведена диаграмма верхнего уровня процесса «Управление претензиями клиентов». Она является дочерней диаграммой по отношению к контекстной, приведенной на рис. 5.4.
Функция, показанная на контекстной диаграмме (АО), раскладывается на подфункции посредством создания данной дочерней диаграммы верхнего уровня. Затем каждая из представленных подфункций раскрывается в виде дочерних диаграмм более низкого уровня. Степень декомпозиции в данном случае определяется целью моделирования, т.е. разбиение функции на подфункции, операции и т.д. происходит до тех пор, пока не будут достигнуты цели и задачи моделирования.
Рис. 5.4. Контекстная диаграмма процесса «Управление претензиями клиентов»
В рамках данной методологии моделирования различают родительскую и дочернюю диаграммы. Их иерархические отношения иллюстрирует рис. 5.1.
Под родительской диаграммой подразумевается диаграмма, содержащая один или несколько родительских блоков. Это диаграмма верхнего уровня относительно той, которая является декомпозицией одного из ее блоков (родительских блоков). Например, контекстная диаграмма процесса «Управление претензиями клиентов» является родительской для диаграммы верхнего уровня процесса «Управление претензиями клиентов», которая представлена на рис. 5.5. Последняя — является родительской диаграммой для диаграммы подпроцесса регистрации претензии.
Методология IDEF0 требует, чтобы в диаграмме было не менее трех и не более пяти блоков, иначе она становится сложной для чтения и восприятия.
Функциональные блоки на диаграмме 1DEF0 должны размещаться последовательно и в порядке степени их важности. Их принято располагать по диагонали (см. рис. 5.5).
Каждая дочерняя диаграмма состоит из дочерних блоков и стрелок, которые обеспечивают необходимую на данном уровне детализацию родительского блока. Таким образом, дочерняя диаграмма описывает ту же предметную область, что и ее родительский блок. Примером может служить диаграмма декомпозиции подпроцесса «Зарегистрировать претензию», которая представлена на рис. 5.6.
Она является дочерней диаграммой для диаграммы верхнего уровня процесса «Управление претензиями клиентов» (см. рис. 5.5), поскольку она представляет собой более детальное описание одного функционального блока (первого) родительской диаграммы. Аналогичным образом могут быть подробно описаны и другие функциональные блоки данной родительской диаграммы.
Рис. 5.5. Диаграмма верхнего уровня процесса «Управление претензиями клиентов»
Рис. 5.6. Диаграмма подпроцесса «Зарегистрировать претензию»
Источник: studme.org
