Построение модели idef0 программа linux. Основные элементы и понятия IDEF0. Использование различных цветов

Самый простой и быстрый способ создания диаграмм по графическим нотациям idef0 и idef3 - использовать свободно распространяемый кроссплатформенный редактор диаграмм, блок-схем, сетевых диаграмм, UML-диаграмм и прочей нечисти под названием "Dia". Программа переведена на многие языки, включая русский.

Скачать программу можно на ее официальном сайте: http://projects.gnome.org/dia/ . На момент написания статьи последняя версия программы Dia была под номером 0.97.1 - причем она является таковой уже чуть ли не два года. Не смотря на это функционал у приложения отличный.

Построение IDEF0-диаграмм

для создания схем в графической нотации idef0 достаточно выбрать стандартную библиотеку элементов Dia под названием "SADT / IDEF0":

Если вы впервые столкнулись с idef0, то очень рекомендую сначала прочитать вот эти статьи про эту методологию:

Современные методологии описания бизнес-процессов. Методология IDEF0 - Ковалев Валерий Михайлович (Журнал "Консультант директора", № 12, Июнь, 2004 г.)
IDEF0 как инструмент моделирования процессов - Андрей Дворников (Журнал "Авант Партнер", № 22(79), Август 2005 г.)
Опыт использования стандарта IDEF0 - Сергей Рубцов

Построение IDEF3-диаграмм

С idef3 капельку посложнее. Стандартного набора элементов для построения диаграмма в графической нотации idef3 в Dia не предусмотрено, однако все нужные блоки в программе есть. Их нужно просто сгруппировать вручную. Для этого нажимаем в меню: "Файл -> категории и объекты". В открывшемся окне нажимаем кнопку "Создать". Откроется ещё одно окошко, в котором выбираем пункт "Название категории" и вписываем туда "idef3". Процесс создания категории выглядит примерно так:

Так как вы только что создали эту категорию - естественно она пуста. Нам нужно переместить в нее нужные элементы схем. Поэтому:

Жмем кнопку "Применить", "Закрыть" окошко и готово! Заходим в "другие библиотеки элементов" и выбираем там созданную нами графическую нотацию "idef3" (она располагается в положенной ей месте по алфавиту). Кстати, чтобы писать в блоках, удобно использовать клавишу F2. Конечно, это не идеальный инструмент, но этот способ позволяет создавать диаграммы IDEF3 максимально приближенно к их точной графической нотации.

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

IDEF0 Diagrams Software - Create IDEF0 diagrams and business diagrams rapidly with rich examples and templates. Provide some IDEF0 knowledge.

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.

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 SofTek in 1972. An IDEF0 activity diagram contains one level of decomposition of a process. Boxes within a diagram show the subprocesses of the parent process named by the diagram. Arrows between the boxes show the flow of products between processes.

Innovative IDEF0 Software

Edraw Max is an easy to use IDEF0 diagrams software, which creates IDEF0 diagrams and business diagrams rapidly with rich examples and templates.

Build hierarchical diagrams using IEDF0 process charting models for model configuration management, need and benefit analyses, requirements definitions, and continuous improvement models.

System Requirements

Works on Windows 7, 8, 10, XP, Vista and Citrix

Works on 32 and 64 bit Windows

Works on Mac OS X 10.2 or later

Software Features

Edraw is:

state of the art
vector-based
more than just IDEF0, IDEF1, IDEF2 Diagrams which can make over 200 kinds of diagrams
easy to use with drag and drop interface, premade symbols and automatic formatting tools
accompanied by a plethora of well-designed templates and examples
designed with broad file format compatibility

IDEF0 diagrams typically include the following components:

Context diagram - The topmost diagram in an IDEF0 model.

Parent/child diagram - An IDEF0 decomposition hierarchy using parent/child relationships.

Node trees - Tree-like structures of nodes rooted at a chosen node, and used to represent a full IDEF0 decomposition in a single diagram.

The Benefits of Using IDEF0 to Model Business Processes

Understanding - modeling helps discover the nature of the business being modeled; that is, what is being done in the business.
Communication - once understanding has been reached, the nature of the business processes can be documented and these documents easily communicated.
Enlightenment - modeling helps to uncover anomalies, redundancies deficiencies and inefficiencies in the existing (as-is) business process.
Improvement - a model allows you to select deficient areas of the business and its processes and improve them.
Redesign - a model provides a tangible basis for redesigning the process, performing simulations of the redesigned (to-be) business process as defined by the strategy. This means that strategies can be tested before implementation takes place.

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.

Подходом, основанным на методологии общего описания и функционального моделирования бизнес- процессов, является методология IDEF0. В основе ее лежит методология интегрированного компьютеризированного производства (Integrated Computer-Aided Manufacturing - ICAM), использовавшаяся в военно-воздушных аэрокосмических лабораториях США в процессе разработки и создания новых видов самолетов и космических аппаратов. Позднее на этой основе был разработан и введен в действие в 1993 г. федеральный стандарт США по информационным технологиям - Публикация? 183 (Federal Information Processing Standard, Publication 183).

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

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

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

Рисунок 1. Иерархия детализируемых диаграмм в IDEF0.

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

Стрелки могут быть четырех видов:

Рисунок 2. Позиционирование стрелок в модели IDEF0.

Входы ( Input ) и Выходы ( Output ) (подходят слева к блокам и выходят справа от них) — представляют собой данные, объекты, материалы и т.п., относящиеся к выполняемым блоками функциям (это, как правило, перерабатываемые ресурсы и результаты выполнения отдельных функций блоков);
Механизмы выполнения функций ( Mechanism ) (подходят снизу к блокам) — представляют собой долговременные ресурсы, необходимые для выполнения соответствующих работ (это могут быть конкретные работники, подразделения организации, машины, оборудование, компьютерная техника и т.п.);
Управление или регламентирующие документы ( Control ) (подходят сверху к блокам) − представляют собой условия, директивы, руководящие документы и т. п., управляющие выполнением данной функции.

Компоненты синтаксиса IDEF0 - блоки, стрелки, диаграммы и правила.

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

Блок описывает функцию. Внутри каждого блока помещаются его имя и номер. Имя должно быть глагольной фразой или отглагольным существительным. Номер блока размещается в правом нижнем углу. Номера блоков используются для их идентификации на диаграмме и в соответствующем тексте.

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

Рисунок 3. Стрелки на IDEF0-диаграмме.

Для блоков установлены следующие синтаксические правила :

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

Для стрелок установлены следующие синтаксические правила :

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

IDEF0-модели состоят из документов трех типов:

графических диаграмм,
текста
глоссария.

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

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

Диаграмма верхнего уровня обеспечивает наиболее общее описание объекта моделирования. За этой диаграммой следует серия дочерних диаграмм, дающих более детальное представление об объекте.

Каждая модель должна иметь контекстную диаграмму верхнего уровня, на которой объект моделирования представлен единственным блоком с граничными стрелками. Эта диаграмма называется А-0 (А минус ноль). Стрелки на этой диаграмме отображают связи объекта моделирования с окружающей средой. Поскольку единственный блок представляет весь объект, его имя - общее для всего проекта. Это же справедливо и для всех стрелок диаграммы, поскольку они представляют полный комплект внешних интерфейсов объекта. Диаграмма А-0 устанавливает область моделирования и ее границу.

Рисунок 4. Пример контекстной диаграммы верхнего уровня.

Контекстная диаграмма А-0 также должна содержать краткие утверждения, определяющие точку зрения должностного лица или подразделения, с позиций которого создается модель, и цель, для достижения которой ее разрабатывают. Формулировка цели выражает причину создания модели, то есть содержит перечень вопросов, на которые должна отвечать модель, что в значительной мере определяет ее структуру. Наиболее важные свойства объекта обычно выявляются на верхних уровнях иерархии; по мере декомпозиции функции верхнего уровня и разбиения ее на подфункции, эти свойства уточняются. Каждая подфункция, в свою очередь, декомпозируется на элементы следующего уровня, и так происходит до тех пор, пока не будет получена структура, позволяющая ответить на вопросы, сформулированные в цели моделирования. Каждая подфункция моделируется отдельным блоком. Каждый родительский блок подробно описывается дочерней диаграммой на более низком уровне. Все дочерние диаграммы должны быть в пределах области контекстной диаграммы верхнего уровня.

Часто бывают случаи, когда отдельные стрелки не имеет смысла продолжать рассматривать в дочерних диаграммах ниже какого-то определенного уровня в иерархии, или наоборот — отдельные блоки не имеют практического смысла выше какого-то уровня. С другой стороны, иногда возникает необходимость избавиться от отдельных “концептуальных” стрелок и не детализировать их глубже некоторого уровня. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования . Обозначение “туннеля” в виде двух круглых скобок вокруг начала стрелки обозначает, что эта стрелка не была унаследована от функционального родительского блока и появилась (из “туннеля”) только на этой диаграмме. В свою очередь, такое же обозначение вокруг конца стрелки в непосредственной близи от блока - приёмника означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта стрелка отображаться и рассматриваться не будет. Чаще всего бывает, что отдельные объекты и соответствующие им интерфейсные стрелки не рассматриваются на некоторых промежуточных уровнях иерархии - в таком случае, они сначала “погружаются в туннель”, а затем, при необходимости “возвращаются из туннеля”.

Наглядность графического языка IDEF0 делает модель вполне читаемой и для лиц, которые не принимали участия в проекте ее создания, а также эффективной для проведения показов и презентаций. В дальнейшем, на базе построенной модели могут быть организованы новые проекты, нацеленные на производство изменений на предприятии (в системе).

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

IDEF0–модели состоят из трех типов документов: графических диаграмм, текста и глоссария. Эти документы имеют перекрестные ссылки друг на друга.

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

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

Графическая диаграмма – главный компонент IDEF0–модели, содержащий блоки, стрелки, соединения блоков и стрелок и ассоциированные с ними отношения. Блоки представляют основные функции моделируемого объекта. Эти функции могут быть разбиты (декомпозированы) на составные части и представлены в виде более подробных диаграмм; процесс декомпозиции продолжается до тех пор, пока объект не будет описан на уровне детализации, необходимом для достижения целей конкретного проекта. Диаграмма верхнего уровня обеспечивает наиболее общее или абстрактное описание объекта моделирования. За этой диаграммой следует серия дочерних диаграмм, дающих более детальное представление об объекте.

Каждая модель должна иметь контекстную диаграмму верхнего уровня, на которой объект моделирования представлен единственным блоком с граничными стрелками. Эта диаграмма называется A–0 (А минус нуль). Стрелки на этой диаграмме отображают связи объекта моделирования с окружающей средой. Поскольку единственный блок представляет весь объект, его имя общее для всего проекта. Это же справедливо и для всех стрелок диаграммы, поскольку они представляют полный комплект внешних интерфейсов объекта. Диаграмма A–0 устанавливает область моделирования и ее границу. Пример диаграммы A–0 показан на рис. 3.10., рис. 3.11., рис. 3.12.

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

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

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

Контекстная диаграмма A–0 также должна содержать краткие утверждения, определяющие точку зрения должностного лица или подразделения, с позиций которого создается модель, и цель, для достижения которой ее разрабатывают. Эти утверждения помогают руководить разработкой модели и ввести этот процесс в определенные рамки.

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

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

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

Владимир Репин К.т.н., исполнительный директор ООО «ФИНЭКСПЕРТ.РУ », зав. кафедрой Управления бизнес-процессами НОУ ВПО «ИЭФ «Синергия».

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

При попытке отобразить цепочку создания ценности, представленную на рисунке 5, в модели IDEF0 возникает вопрос: каким образом отобразить на одной диаграмме 16 бизнес-процессов одновременно? Делать это не стоит, т.к. диаграмма станет плохо читаемой (не говоря уже о нарушении требований стандарта). Нужно определиться с тем, каким образом сгруппировать процессы так, чтобы с одной стороны сохранилась цепочка, а с другой — чрезмерно не усложнять диаграмму . Кроме того, нужно решить, отображать ли в данной модели бизнес-процессы закупки, сбыта, управления финансами и т.д. Вариантов решения этой проблемы может быть несколько. Какого-то единственного правильного решения не существует. Конечно, все зависит от того, какие цели мы ставим перед моделью. На рисунке 6 показан пример модели в IDEF0, построенной для рассматриваемого случая.

Бизнес-процессы на диаграмме А0 (рисунок 6) сгруппированы по трем категориям на основе анализа движения материальных потоков — сырья, полуфабрикатов, готовой продукции. Далее в качестве примера показано детальное представление процесса «Производить, хранить и доставлять сырье» (см. рисунок 7).

Рисунок 6. Фрагмент модели в IDEF0, построенной на основе цепочек создания ценности. Диаграмма А0.

На рисунке 7 белым цветом показаны бизнес-процессы, выполняемые предприятием, а серым цветом — бизнес-процессы, выполняемые внешними контрагентами. Видно, что бизнес-процесс «Закупать сырье», по сути, управляет всеми остальными бизнес-процессами в рассматриваемой части цепочки создания ценности. Выполняется этот процесс Отделом закупок Службы снабжения. Так же в этом процессе участвует подразделение «Транспортный отдел» (оно не показано на схеме организационной структуры на рисунке 1). Хотя данное подразделение не входит в Службу снабжения, но выполняет часть рассматриваемого процесса. Таким образом, на диаграмме А2 представлен «сквозной» или межфункциональный (даже можно сказать межорганизационный) бизнес-процесс.

У читателя может возникнуть вопрос: почему на диаграмму А2 не попал бизнес-процесс хранения сырья на складе предприятия, выполняемый Складом сырья Службы снабжения? Этот процесс был условно отнесен в блоку процессов «Хранить и перерабатывать сырье и полуфабрикаты» (диаграмма А0, рисунок 6). Здесь мы коснулись вопроса определения границ «сквозных» или межфункциональных бизнес-процессов. Поскольку такие процессы не локализованы внутри отдельных подразделений (или даже организаций), определение их границ является достаточно субъективным и зависит от ряда критериев, которые, как правило, вырабатывается при проведении анализа бизнеса компании на основе установленных целей и задач.

Рисунок 7. Фрагмент модели в IDEF0, построенной на основе цепочек создания ценности. Диаграмма А2.

Выводы

Мы проводили анализ цепочек создания ценности нескольких российских компаний при помощи стандарта IDEF0 и считаем, что он вполне подходит для этих целей при правильном и последовательном методическом подходе. На наш взгляд, реальной проблемой является то, что специалисты предприятий смешивают два представленных выше подхода при построении моделей в IDEF0. В результате полученная модель содержит как описание деятельности подразделений («локальные» процессы), так и элементы «сквозных» процессов. Такое смешение делает модель «рыхлой» и существенно затрудняет ее анализ и последующее использование для целей реорганизации, документирования и подготовки к автоматизации.

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

Москва, февраль 2005 г.

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

Состав функций и распределение их по сотрудникам являются условными. Таблица дается в качестве примера.

Конечно, такое разделение процессов является субъективным.

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

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

Это проблема не только IDEF0, но и любого другого способа графического представления бизнес-процессов.