в чем нарисовать idef0
IDEF0 Diagram Software
IDEF Definition
IDEF is based on the Structured Analysis and Design Technique (SADT), a graphical approach to system description, introduced by Douglas T. Ross in the early 1970s. Since then, system analysts at Softech, Inc. have refined and used SADT in a wide variety of problems. In 1981, the U.S. Air Force Program for Integrated Computer-Aided Manufacturing (ICAM) standardized and made public a subset of SADT, called IDEF.
IDEF0 diagram was originally used to apply structured methods to better understand how to improve manufacturing productivity. IDEF0 was initially created at Northrop Corporation in 1966, and first available commercially by SofTech in 1972. An IDEF0 activity diagram contains one level of decomposition of a process. Boxes within a diagram show the sub-processes of the parent process named by the diagram. Arrows between the boxes show the flow of products between processes.
Innovative IDEF0 Software
EdrawMax is an easy to use IDEF0 diagrams software, which creates IDEF0 diagrams and business diagrams rapidly with rich examples and templates.
EdrawMax
All-in-One Diagram Software
Build hierarchical diagrams using IEDF0 process charting models for model configuration management, need and benefit analyses, requirements definitions, and continuous improvement models.
System Requirements
Software Features
IDEF0 Diagram Shapes
IDEF0 diagrams typically include the following components:
The Benefits of Using IDEF0 to Model Business Processes
The IDEF0 Modeling Techniques
An IDEF0 model represents the activities of the business from the point of view of the business, how those business activities interrelate, resources used to conduct each activity, and the result or output of each activity. The model consists of graphics and associated text supporting the graphics.
The IDEF0 modeling technique consists of a graphic language and a modeling process that can be used to develop a rich process description. It is an intuitive way to define, analyze and document the business as a whole and the processes of the business.
The IDEF0 notation was standardized in 1993 by the National Institute of Standards and Technology of the United States Department of Commerce and is a public domain methodology. IDEF0 is a subset of the complete IDEF0 system modeling methodology which includes process and information modeling.
There are a number of business process and information modeling notations around. Most of these are part of proprietary methodologies developed by consulting firms.
IDEF0, being in the public domain, is dismantling the Tower of Babel to the point where a model’s main purpose and communication can now be achieved.
The modeling of the entire business and its processes is especially difficult because, even in small- and medium-sized businesses, business processes are complex and referred to as being of medium complexity. The IDEF0 method facilitates the modeling of the business as a complex system so it can be understood and improved.
Business Process Modeling Using IDEF Diagrams
IDEF (Integrated Definition) diagrams were introduced in 1981 as part of the Integrated Computer-Aided Manufacturing (ICAM) project. There are numerous IDEF methods, but two of them serve as the basis for business process models: the IDEF0 method that focuses on activity modeling and the IDEF3 method that accomplishes process description and can be used to rapidly generate discrete-event simulation model specifications (Mayer et al., 1998). The IDEF0 method is designed to model the decisions, actions, and activities of an organization or other system and is targeted to communicating and analyzing the functional perspective of a system (Mayer et al 1998).
Perhaps the main strength of IDEF0 is its simplicity, as it uses only one notational construct, called the ICOM (Input-Control-Output-echanism). IDEF3 describes processes as ordered sequences of events or activities. As such, IDEF3 is a scenario-driven process flow modeling technique, based on the direct capture of precedence and causality relations between situations and events (Mayer et al 1998). The goal of an IDEF3 model is to provide a structured method for expressing the domain experts’ knowledge about how a particular system or organization works (as opposed to
IDEF0, which is mainly concerned with what activities the organization performs). Similar to IDEF0, the main strength of IDEF3 is the simplicity of its notation, which relies on only one basic construct, called the UOB (Unit of Behavior).
IDEF0 Diagrams Examples
It’s easy to start IDEF flowchart from existing examples or templates. Right in the software, you can find well-built IDEF flowcharts that you can use.
Актуально ли на сегодня моделирование в IDEF0?
Известная сегодня уже не только в узких кругах аббревиатура IDEF0 является первой методологией, стандартизирующей работу над бизнес-процессами. Она была разработана в середине прошлого века в рамках аэрокосмического проекта в США и, показав свою эффективность, стала федеральным стандартом. В нашей стране в 2000 году подготовлен документ « Методология функционального моделирования IDEF0. Руководящий документ Методология функционального моделирования IDEF0 Руководящий документ. Издание официальное. Госстандарт России РД IDEF0 – 2000. Разработан Научно-исследовательским Центром CALS – технологий «Прикладная Логистика». Принят и введен в действие Постановлением Госстандарта России 2000 г. Москва », но как стандарт он так и не был утвержден. Хотя это не помешало данной методологии стать в нашей стране одним из наиболее популярных инструментов графического моделирования бизнес-процессов. В данной статье я предлагаю вам рассмотреть модель IDEF0 и оценить актуальность этого подхода в настоящее время.
Основные понятия и сокращения
Разберемся немного с названиями ключевых элементов методологии. Графический стандарт IDEF0 является частью методологии SADT (Structured Analysis and Design Technique – метод структурного анализа и проектирования). IDEF – это сокращение от ICAM Definition, а ICAM образовано от Integrated Computer Aided Manufacturing, что переводится как интегрированная компьютеризация производства. Методология SADT – это целое семейство из 15 разных моделей, которые в комплексе должны были позволить исследовать структуру, параметры и характеристики производственно-технических и организационно-экономических систем.
Нотация IDEF0 – это достаточно строгая методика, которая изначально была разработана, как и стандарты технического конструирования, для ручного моделирования. Поэтому там содержатся требования по размещению стрелок, формату всех элементов, содержанию информационной рамки к IDEF0 диаграмме и пр. Поскольку деятельность компании – это сложная многоуровневая система действий, то схем получается всегда много, и необходима однозначная систематизация и навигация по всем элементам модели. Сейчас это делают в основном компьютерные системы, поддерживающие моделирование в данной нотации. На территории России наиболее известными и доступными на сегодня являются системы AllFusion Process Modeler и Business Studio. Обзору этих систем я планирую посвятить отдельные статьи.
Функциональный блок
Независимо от масштаба действий все функции отображаются единообразно и обязательно содержат 4 ключевых потока, которые жестко закреплены за сторонами функционального блока:
Такой подход позволяет немного сэкономить на пояснениях в схемах и добиться однозначности в отображении потоков, что придает стройности всей модели.
Для построения функциональной модели методология IDEF0 требует соблюдать следующие правила.
Рассмотренная схема является «кирпичиком» подхода IDEF0. Функциональное моделирование предполагает постепенный переход от общего к частному за счет декомпозиции. Декомпозиция – это «углубление» в рассматриваемую функцию, разделение ее на более мелкие функции. При этом, когда функция верхнего уровня представлена обобщенно и после декомпозирована, ее уместно уже назвать процессом.
Контекстная диаграмма
На самом верхнем уровне компания представляется как «черный ящик», в котором происходит некая деятельность, переводящая входы в выходы. Этот уровень принято называть « контекстная диаграмма », то есть схема, описывающая контекст деятельности компании. Дополнительно на контекстной диаграмме отображаются ключевые характеристики всей модели.
Таким образом, контекстная диаграмма содержит в самом обобщенном виде описание деятельности компании, которую пронизывают потоки, связывающие компанию с внешним миром. Думаю, на них тоже следует остановиться немного поподробнее.
Основные потоки
Опыт показал, что, несмотря на кажущуюся простоту и формальность этого уровня, на нем часто приходится подолгу задерживаться, так как здесь должны быть отражены все значимые для собственника и рынка результаты. Ошибка может привести к созданию моделей, не выполняющих поставленные перед бизнесом задачи. Чтобы проверить, что значимые потоки отражены, убедитесь, что на вашей схеме присутствуют все 4 основные вида потоков.
Обратите внимание, что компания – это открытая система, и в ней ничего не возникает и не исчезает. Компания способна только преобразовывать входящие потоки в выходящие, и если она это делает хорошо, то появляется дополнительный денежный поток (прибыль), отражающий в каком-то смысле качество работы всей системы.
Хорошо, если вы выделите каждый из этих типов потоков своим цветом, чтобы можно было легко различить движение ресурсов и не пропустить важные моменты. Например, часто можно наблюдать отсутствие клиента в потоках компании, поэтому и работа с ним строится по остаточному принципу – клиент часто чувствует себя помехой для сотрудников компании, задачи которого сфокусированы на обработке потока документов.
Стрелки управления могут быть представлены только 1 видом потока – информационным, который можно разбить на 2 подвида. Первый – это документы, такие как:
Второй – это недокументированная информация, к которой чаше всего относятся требования собственников.
И, наконец, механизмы – здесь только 2 вида потоков: оборудование (материальный) и исполнители (подразделения и люди). Здесь не может быть документов, как и не может быть людей на стрелках управления!
Для навигации в модели предусмотрена сквозная нумерация. Контекстная диаграмма нумеруется «А-0». В дальнейшем каждый функциональный блок получает свой номер, какой бы глубокой ни была декомпозиция.
Декомпозиция
После проработки потоков контекстной диаграммы можем перейти к декомпозиции. Переходя на уровень ниже, как бы открывая «черный ящик», мы сначала видим чистый лист со стрелками, которые были присоединены к функциональному блоку.
И вот здесь уже начинается собственно функциональное моделирование – мы должны понять, какой набор действий может связать эти потоки и обеспечить выполнение всех требований. Сложность состоит в том, что действий в компании очень много, а на схеме мы имеем право отобразить не более 9 функций, иначе схема станет нечитабельной и соответственно бесполезной.
Не всегда просто скомпоновать сложную деятельность так, чтобы она осталась наглядной, читабельной и при этом полной. Чаще всего прибегают при этом к разделению всего многообразия процессов на основные крупные блоки, наиболее значимыми из которых являются следующие.
На рисунке ниже представлена диаграмма декомпозиции нашего примера.
Дальнейшая работа над моделью аналогична первому шагу – проводится декомпозиция каждого функционального блока первого уровня. Нумерация блоков будет содержать при этом номер первого уровня: А1.1 … А1.n, A2.1 … A2.n и т.д.
Выводы об актуальности нотации
В рамках данной статьи удалось отобразить только основные понятия IDEF0-нотации на коротком примере IDEF0, по которым, конечно, сложно судить о методологии в целом. Но достаточно большой опыт использования данной нотации на практике позволяет мне сделать следующие выводы.
Некоторые из названных аргументов заставляют думать, что данный подход является лучшим и единственным для полного моделирования деятельности. Но не нужно забывать, что функциональная модель рассчитана только для верхнего уровня моделирования. Использование нотации IDEF0 для проектирования работы на уровне исполнителей ведет к тому, что схемы получаются чисто иллюстративными и на их основе невозможно построить толковый регламент, так как они не содержат:
Поэтому если пользоваться данной нотацией для тех задач, для которых она предназначена (структурирование деятельности верхнего уровня), то IDEF0 практически единственная на сегодня нотация, которая позволяет сделать это содержательно и аккуратно.
В проектном управлении этот стандарт моделирования наиболее применим там, где нужно связать наглядными потоками разные проекты или процессы. Графическая модель при этом позволит более рационально распределить ответственность и ресурсы по задачам. Логика выполнения задач проекта, отраженная на схемах, поможет подготовить более качественный календарный план в виде диаграммы Ганта.
Хорошие BPM — инструменты, которых нет и нет. Моделирование процессов
Поговорим о том, какие инструменты хотелось бы иметь при описании бизнес-процессов. Инструментов BPMS (BPM systems) много, но выбрать то особо нечего …
Ниже перечислим некоторые важные инструментальные возможности некоторых сред моделирования процессов (в основном АРИС-ARIS и MS visio).
Задача
1. Подходы к визуализации диаграммы
1.1 Слои модели
Нарисовал нам наш архитектор (специалист по моделированию процессов) схему:
Рис. 1 Процесс оформления заявления
Смотрят пользователи (Работник, Начальник, бизнес и системные аналитики) на схему и понять не могут, что нарисовано то и как этот процесс работает. Соглашение о моделировании прочитали, обучающие ролики посмотрели, но все равно не понятно.
Далее отключаем слой «Документооборот» (docflow) и остается только последовательность действий (workflow, Process Flow), который говорит, что нужно провести всего две операции.
По мере появления ясности подключаем слои (кто исполнитель и какие документы на входе и выходе каждой функции \ операции). Когда схема большая (перегруженная) отключение слоев может творить «чудеса» в плане облегчения восприятия процесса. Иногда достаточно увидеть несколько представлений «одного и того же» (т.е. «те же самые, только в профиль») чтобы понять и нотацию и саму логику схемы, а если для этого достаточно нажать несколько кнопок (фильтров категорий), то путь к пониманию резко сокращается.
Пользоваться послойным построением схемы также удобно: вначале нарисовали основной слой workflow, потом наращиваем информативность процесса другими слоями.
Пример такой реализации возможен в MS Visio:
Рис. 2 Управление слоями в MS Visio
1.2 Плавательные дорожки
Применительно к Рис. 1 «Процесс оформления заявления»: отключили слой «документы», а оставшуюся часть (функции и ресурсы) представили в виде одной или двух Swimlane (опять же «по кнопке»).
Рис. 3 Swimlane по ролям в горизонтальной плоскости
Применительно к рассматриваемому случаю возможны следующие комбинации Swimlane:
две одинарные (горизонт, вертикаль) по ролям;
две одинарные (горизонт, вертикаль) по инструментам (часто в разрезе баз данных показывают);
«Дорожки» помимо того, что позволяют создать другое (альтернативное) представление процесса (смена представления иногда играет решающую роль в понимании процесса), обеспечивают сортировку по указанным категориям, что позволяет быстро и просто найти: где применяется такой-то инструмент и где «нужно поработать» такому то исполнителю (роли).
1.3 Объекты модели и их атрибуты, свойства
Как минимум необходимы атрибуты: название объекта, тип (функция, документ, роль и т.п.), связь с другими объектами. В принципе любой векторный графический редактор оперирует с объектами, но редкий имеет удобные инструменты работы с их атрибутами.
При просмотре схемы процесса должна быть возможность выделения объекта и просмотр атрибутов схемы и ее объектов (с наложением фильтров, т.к. иначе будет избыток).
1.4 Задание своей нотации (на примере новой ЕРС ver. 2)
Посмотрим на примере нотации ЕРС. Что же в ней улучшить? Все улучшения запишем в гипотетическую ЕРС2 нотацию.
Возможность задания своей нотации в инструменте моделирования означает подсказку (блокировку) при некорректном построении модели, как в момент отрисовки, так и через проверочный отчет построенной диаграммы. Например, в ЕРС2 предусматриваются следующие типы коннекторов: для входящих сущностей (входящие документы, материалы-заготовки), для выходящих (исходящие документы, продукты операции), соединитель потока (функции, события), соединитель ресурса. В объекте «функция» предусматриваются три «Connection Point» (visio):
слева в овале «функция» два коннектора: один вход, второй выход (общие для docflow и потока материалов и т.п.);
справа два коннектора: для исполнителя функции и инструмента, который используется для реализации функции.
Вопрос: кроме как в visio, где можно задавать новые нотации и делать проверки на соответствие (валидность), аналогичные показанным выше?
Можно предусмотреть в таблице отдельное поле «полное описание функции» с подробным (большим, т.е. не влезающим в надпись) описанием операции, отображаемое на диаграмме в виде, например, всплывающей подсказки (или в отдельном окне) при активации конкретной функции (при наведении мышью).
Концептуально изложенный подход близок к выделенной в АРИС нотации «табличная ЕРС» (см. «Нотация ЕРС в виде таблицы»), но здесь реализация в виде обычной текстовой таблицы, т.е. ближе к ARIS Smart Designer. Причем логику процесса также можно указать в составе таблицы, например, как ссылка на предшествующий объект (этого нет Smart Designer, но не сложно добавить «что-то» для ЕРС2). Таблицу можно вставлять в текстовые регламенты word и макросом (VBA) генерить схему процесса («не отходя от кассы») с дублированием конечно в общем каталоге моделей.
Собирать схему из таблицы намного сложнее, чем наоборот, т.к. требуется сложный механизм пространственного разнесения объектов схемы (минимизация пересечений, задание направления потока и т.п.).
Применительно к graphviz: в случае, когда репозитарий объектов хранится в Excel, можно автоматически генерировать схемы, используя инструменты типа: Excel to Graphviz (sourceforge.net).
Пример простого VAD из dot:
Посмотреть схему можно, вставив код в окно «Online Graphviz Generator»:
Кстати, редкий Online Graphviz понимает несокращенный набор параметров спецификации.
В теме автоматического создания диаграмм из «текстового описания языком» нельзя не упомянуть про Object Process Diagram (OPD) \ Object Process Language (OPL). Тезисы у Object Process Methodology (OPM) вроде как BPM-ориентированные, но поверхностное знакомство с ним породило уверенность, что эта методология намного дальше от «workflow \ business process» (народа), чем те же plant uml \ dot (graphviz). OPCloud доступен тут: https://sandbox.opm.technion.ac.il/
2. Другое
2.1 Навигация по связанным моделям (каталог моделей)
При построении вложенных диаграмм (причем, возможно выполненных в разных нотациях, например, верхнеуровневые в VAD, IDEF0) необходимо иметь возможность перехода от одной к другой.
Обычно связанный набор моделей (и их объектов) называют репозитарий (репозитОрий). Часто в интерфейсе программы предусмотрено два окна: иерархическое дерево моделей (слева вверху) и окно диаграммы (основное). В идеале навигация по моделям должна быть трех видов:
по дереву моделей (treeview );
комбинированная, когда при переходе через кликабельные объекты схемы меняется фокус на общем дереве процессов.
2.2 Разные фишки и отчеты по атрибутике
Поиск по названиям моделей, атрибутам. Задание правил отбора, например, по диапазону значений последнего редактирования модели. Выгрузка данных фильтрации \ сортировки во внешний файл (отчет), причем разного формата (например, excel для анализа, pdf для презентабельности) и т.п.
2.3 Специфические отчеты
Отчеты могут быть разнообразны (зависит от воображения), но в первую очередь, нас будут интересовать выгрузки в распространенные формы. Универсальный генератор отчетов «на все случаи жизни» видимо проблема, но инструменты создания отчетов должны быть изначально в среде моделирования.
Для примера рассмотрим матрицу ответственности\ участия RACI. Требуется автоматическая генерация усеченной RACI-матрицы (здесь показано только для участников процесса, но часто плюс владельцы процесса) по имеющейся, например, VAD-диаграмме (value added chain diagram). Набор ключевых «мега процессов» компании показан в виде VAD и нужно по ним построить (синхронизировать) матрицу участников (RACI по одной только роли «участник процесса»).
Рис. 4 Построение RACI матрицы
Алгоритм построения таблицы на VBA Visio\Excel может быть следующий:
Создаем в таблице Excel новую строку и в поле «Ключевые процессы» подставляем значение с активного листа visio из объекта типа «название мега процесса».
Далее циклом пробегаем по всем VAD-элементам схемы (листа) и через связь (объект «соединитель» для связки с объектами «исполнитель») находим связанные объекты типа «исполнитель» (участник подпроцесса).
Находим соответствующее название подразделения в шапке таблицы и на пересечении с процессом ставим символ участия (признак).
Переход к следующему листу visio.
Когда в организации десятки подразделений и около сотни «мега процессов» (их выделение достаточно субъективно), то задача синхронизации схем мега-процессов и матрицы участия подразделений в таких ключевых процессах становится достаточно трудоемкой.
2.4 Упаковка необъятной схемы процесса в печатный лист
Когда рисуют гигантскую «портянку» из «тучи элементов» на одной схеме, а потом нужно ее распечатать (А4, А3) или представить в ином интерфейсе (без скролинга такой «портянки»), то возникает ступор. Должна быть поддержка многостраничной схемы и элементов перехода между страницами (в том числе, кликабельными).
2.5 Разное
Публикация процессов, совместная работа, интеграция с корпоративной базой нормативных документов и т.п.
Авто-размещение объектов на схеме: набросал невпопад объекты на лист (главное правильно связи указать и никого не забыть) и нажал кнопку: «расположить как надо» и система сама оптимально и красиво разместила объекты на схеме (в visio функции выравнивания и распределения фигур).
Открытые стандарты хранения и экспорта \ импорта (внешний графический импорт \ экспорт как минимум в visio), как самих графических объектов модели, так и их атрибутов. К сожалению, тот же MS visio так и не научился нормально экспортировать схемы в pdf и svg (например, всплывающие подсказки).
Изменение дизайна графического примитива для любого объекта нотации, расширение нотации, передача новых шаблонов в другую аналогичную систему, добавление новых атрибутов объектов (новых полей) и многое другое.
Заключение
В 2000-ном году мной использовались ровно такие же подходы и ровно те же инструменты моделирования (основные: ARIS toolset, MS visio), что и сейчас, но тогда была настолько интенсивная «движуха в мире ВРМ», что казалось «вот-вот и прогресс всё поменяет», но это оказалось иллюзией. «Старику ARIS» (в части классического моделирования процессов) на пенсию бы (не смотря на добавленные круглую цифру 10 и магическое слово «cloud»), но похоже перемены придут еще совсем не скоро и светлое будущее «обычного» BPM откладывается …