Для чего используется методология idef0. IDEF0. Знакомство с нотацией и пример использования. Точка зрения определяет основное направление развития модели и уровень необходимой детализации

Практикум по применению IDEF0 для функционального описания программного обеспечения САПР

Практикум по применению IDEF0 для функционального описания программного обеспечения
Часть 1.

Если анализировать объявления о найме сотрудников фирм, занимающихся разработкой программного обеспечения, то в последнее время ощущается острая нехватка руководителей проектов, способных грамотно осуществлять постановку задач. Проблема заключается не в том, что они не могут сформулировать задачу, а в том, что они не могут корректно оформить документацию с учетом современных стандартов проектирования. Заказчику уже мало дать несколько листиков, набранных в Word. Он хочет документацию, оформленную в BPWin, ErWin, S-Designer, Power Designer, Rational Rose и т.д. За каждым из этих CASE-средством стоит стандарт. Данная статья посвящена одному из них - IDEF0.

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

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

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

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

Стандарт IDEF0 (Integrated Definition Function Modeling) предназначен для функционального моделирования и принят в качестве федерального стандарта США. Стандарт IDEF0 является одним из группы стандартов, широко применяемых для описания любых бизнес-процессов. Его применение для описания программных проектов является весьма молодым направлением, но применение IDEF0 гарантирует серьезное отношение к вам ваших партнеров...

Применение стандартов группы IDEF (IDEF0, IDEF1 и т.д.) является фактическим условием для получения статуса организацией, удовлетворяющей ISO9000, ISO9001. Эти стандарты для организации - возможность увеличить сбыт продукции, возможность доказать, что она "на гребне волны".

Многие программисты широко используют CASE ErWin, при этом не зная, что он основан на стандарте IDEF1. Это не просто то, что вам нравится или нравится вашим клиентам. Это стандарт - и этим все сказано.

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

В основе стандарта IDEF0 лежит три базовых принципа:

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

2. принцип ограничения сложности - количество блоков на диаграмме должно быть 2...6 (условие удобочитаемости);

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

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

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

Входные данные - исходные ресурсы для описываемой блоком функции (исходная информация, материалы).

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

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

Механизм - это то, посредством чего осуществляется данное действие (станки, приборы, людские ресурсы, программное обеспечение).

Взаимодействие между блоками отображается в виде дуг (стрелок). Иногда стороны блока называют направлениями, а стрелки - потоками. Стрелки можно подписывать. Подписи связываются с соответствующей стрелкой при помощи зигзага (молнии).

Общий вид реализации блока IDEF0-диаграммы изображен на рис.1.

Рис.1. Реализация блока, применяемого в IDEF0-диаграммах.

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

В своей сущности диаграммы образуют дерево. Любая диаграмма выступает как ДК по отношению к низлежащим.

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

Рис.2. Пример основной диаграммы.

Рис.3. Пример декомпозиции основной функции.

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

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

Обычно разводка связей начинается с данных. Входные данные - это данные, необходимые для выполнения функции. С этим направлением вопросы возникают редко. Выходные данные - это данные, являющиеся результатом выполнения функции. Простейшая ситуация, когда выходные данные являются входными данными для другого блока. Всегда ли это так? Если функция, обрабатывая входную информацию, формирует управляющую команду, это управление. Примерно такая же ситуация при формировании функцией формата данных. Формат данных - это механизм передачи информации.

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

Рис.4. Типы связей между блоками на диаграмме. Соответственно а)связь по данным, б)связь по управлению, в)связь по механизму, г)обратная связь.

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

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

Нумерация блоков (индекс блока на диаграмме) на диаграмме определяется на основе приоритета. Нумерация начинается с единицы. Код диаграммы состоит из буквы "А" и номера. ДК имеет код A-0. Буква "А" подразумевает активное действие (от англ. active). Диаграмма, являющаяся декомпозированным вариантом ДК, будет иметь код А0. Каждый элемент на диаграмме А0 будет иметь код от А1 до А6 в соответствии с приоритетом. В свою очередь, при декомпозиции одного из блоков А1...А6, коды блоков вновь декомпозированной диаграммы будут состоять из кода декомпозированной диаграммы плюс индекс выбранного блока. Коды блоков диаграммы не повторяются в пределах всей диаграммы.

По количеству цифр в коде диаграммы можно определить уровень диаграммы - уровень декомпозиции ДК. Принято считать ДК главным уровнем, а все остальные с первого уровня декомпозиции и выше.

Типы последовательности выполнения действий. Данные могут обрабатываться последовательно или параллельно.

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

Пример параллельной обработки - вы можете одновременно смотреть телевизор и есть яблоко. При этом одновременно совершаются два действия. Эти действия между собой не связаны. Такие блоки на диаграмме располагаются вертикально друг над другом.

Часто на диаграмме существует группа действий (блоков), из которой выполняется только одно, в зависимости от какого-либо условия. Такие действия называются альтернативными. К таким блокам условие должно подводиться как управляющее воздействие (выбор действия). Рекомендуется введение специального блока на диаграмму, осуществляющего обработку условия выбора альтернативного действия (блока). Этот блок формирует отдельные команды по выбору для каждого блока.

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

Существуют случаи, когда человек (в том числе один и тот же) для одного блока будет выступать механизмом и управлением. ТАКОЕ СЛУЧАЕТСЯ. Пример, человек пишет письмо. Оно пишется посредством этого человека, и этот же человек управляет содержимым этого письма.

Управляющие данные. Управление - это команда. Если команда содержит информативную часть (названия, условия, сроки выполнения и т.д.), то информативная часть команды является входными данными.

Наиболее простое решение заключается в разделении исходной стрелки на две: управляющую и данных. Эти стрелки подводятся к соответствующим сторонам блока. Обе разделенных стрелки должны иметь соответствующие надписи.

Сергей Соколов (Минск, БГУИР)
E-Mail:

Геннадий Верников

В настоящее время в России резко возрос интерес к общепринятым на Западе стандартам менеджмента, однако, в реальной практике управления существует один очень показательный момент. Многих руководителей до сих пор можно поставить в тупик прямым вопросом об организационной структуре компании или о схеме существующих бизнес-процессов. Наиболее продвинутые и регулярно читающие экономическую периодику менеджеры, как правило, начинают чертить понятные только им одним иерархические диаграммы, но и в этом процессе обычно быстро заходят в тупик. То же самое касается сотрудников и руководителей различных служб и функциональных подразделений. В большинстве случаев, единственным набором изложенных правил, в соответствии с которыми должно функционировать предприятие, является набор отдельных положений и должностных инструкций. Чаще всего эти документы составлялись не один год назад, слабо структурированы и невзаимосвязаны между собой и, вследствие этого, просто пылятся на полках. До поры до времени подобный подход был оправдан, так как во время становления российской рыночной экономики понятие конкуренции практически отсутствовало, да и затраты считать не было особой необходимости - прибыль была гигантской. В результате этого, мы видим в течение последних двух лет вполне объяснимую картину: крупные компании, выросшие в начале 90-х годов, постепенно сдают свои позиции, вплоть до полного ухода с рынка. Отчасти это обусловлено тем, что на предприятии не были внедрены стандарты управления, полностью отсутствовало понятие функциональной модели деятельности и миссии. С помощью моделирования различных областей деятельности можно достаточно эффективно анализировать "узкие места" в управлении и оптимизировать общую схему бизнеса. Но, как известно, на любом предприятии высший приоритет имеют только те проекты, которые непосредственно приносят прибыль, поэтому речь об обследовании деятельности и ее реорганизации обычно идет только во время ощутимого кризиса в управлении компанией.

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

Само же понятие "моделирование бизнес-процессов" пришло в быт большинства аналитиков одновременно с появлением на рынке сложных программных продуктов, предназначенных для комплексной автоматизации управления предприятием. Подобные системы всегда подразумевают проведение глубокого предпроектного обследования деятельности компании. Результатом этого обследование является экспертное заключение, в котором отдельными пунктами выносятся рекомендации по устранению "узких мест" в управлении деятельностью. На основании этого заключения, непосредственно перед проектом внедрения системы автоматизации, проводится так называемая реорганизация бизнес-процессов, иногда достаточно серьезная и болезненная для компании. Это и естественно, сложившийся годами коллектив всегда сложно заставить "думать по-новому". Подобные комплексные обследования предприятий всегда являются сложными и существенно отличающимися от случая к случаю задачами. Для решения подобных задач моделирования сложных систем существуют хорошо обкатанные методологии и стандарты. К таким стандартам относятся методологии семейства IDEF. С их помощью можно эффективно отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. При этом широта и глубина обследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными. В настоящий момент к семейству IDEF можно отнести следующие стандарты:

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

IDEF1 - методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи;

IDEF1X (IDEF1 Extended) - методология построения реляционных структур. IDEF1X относится к типу методологий "Сущность-взаимосвязь" (ER - Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;

IDEF2 - методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. Однако в настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе "раскрашенных сетей Петри" (CPN - Color Petri Nets);

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

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

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

История возникновения стандарта IDEF0

Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique). Несколько лет назад в России небольшим тиражом вышла одноименная книга, посвящанная описанию основных принципов построения SADT-диаграмм. Исторически, IDEF0, как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing) и была предложена департаментом Военно-Воздушных Сил США. Собственно семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF=ICAM DEFinition). В процессе практической реализации, участники программы ICAM столкнулись с необходимостью разработки новых методов анализа процессов взаимодействия в промышленных системах. При этом кроме усовершенствованного набора функций для описания бизнес-процессов, одним из требований к новому стандарту было наличие эффективной методологии взаимодействия в рамках "аналитик-специалист". Другими словами, новый метод должен был обеспечить групповую работу над созданием модели, с непосредственным участием всех аналитиков и специалистов, занятых в рамках проекта.

В результате поиска соответствующих решений родилась методология функционального моделирования IDEF0. C 1981 года стандарт IDEF0 претерпел несколько незначительных изменения, в основном ограничивающего характера, и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом По Стандарам и Технологиям США (NIST).

Основные элементы и понятия IDEF0

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

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

Каждая из четырех сторон функционального блока имеет своё определенное значение (роль), при этом:

Верхняя сторона имеет значение "Управление" (Control);

Левая сторона имеет значение "Вход" (Input);

Правая сторона имеет значение "Выход" (Output);

Нижняя сторона имеет значение "Механизм" (Mechanism).

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.

Рисунок 1. Функциональный блок.

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

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

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

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

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

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

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

Рисунок 2.

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

Рисунок 3.

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

Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

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

Модель IDEF0 всегда начинается с представления системы как единого целого - одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором "А-0".

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

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

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

В процессе декомпозиции, функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы и называется дочерней (Child diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком - Child Box). В свою очередь, функциональный блок - предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит - родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. Важно отметить, что в каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок, или исходящие из него фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0 - модели. Наглядно принцип декомпозиции представлен на рисунке 4. Следует обратить внимание на взаимосвязь нумерации функциональных блоков и диаграмм - каждый блок имеет свой уникальный порядковый номер на диаграмме (цифра в правом нижнем углу прямоугольника), а обозначение под правым углом указывает на номер дочерней для этого блока диаграммы. Отсутствие этого обозначения говорит о том, что декомпозиции для данного блока не существует.

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

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

Рисунок 4. Декомпозиция функциональных блоков.

Принципы ограничения сложности IDEF0-диаграмм

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

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

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

Дисциплина групповой работы над разработкой IDEF0-модели

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

Создание модели группой специалистов, относящихся к различным сферам деятельности предприятия. Эта группа в терминах IDEF0 называется авторами (Authors). Построение первоначальной модели является динамическим процессом, в течение которого авторы опрашивают компетентных лиц о структуре различных процессов. На основе имеющихся положений, документов и результатов опросов создается черновик (Model Draft) модели.

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

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

Особенности национальной практики применения функционального моделирования средствами IDEF0

В последние годы интерес в России к методологиям семейства IDEF неуклонно растет. Это я постоянно наблюдаю, просматривая статистику обращений к своей персональной web-странице (http://www.vernikov.ru), на которой кратко описаны основные принципы этих стандартов. При этом интерес к таким стандартам, как IDEF3-5 я бы назвал теоретическим, а к IDEF0 вполне практически обоснованным. Собственно говоря, первые Case-средства, позволяющие строить DFD и IDEF0 диаграммы появились на российком рынке еще в 1996 году, одновременно с выходом популярной книги по принципам моделирования в стандартах SADT.

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

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

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

Что поступает в подразделение "на входе"?

Какие функции, и в какой последовательности выполняются в рамках подразделения?

Кто является ответственным за выполнение каждой из функций?

Чем руководствуется исполнитель при выполнении каждой из функций?

Что является результатом работы подразделения (на выходе)?

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

Разумеется, подобный подход требует ряда организационных мер, в первую очередь со стороны руководства обследуемого предприятия. Это обусловлено тем, что эта техника подразумевает возложение на некоторых сотрудников дополнительных обязанностей по освоению и практическому применению новых методологий. Однако в конечном итоге это оправдывает себя, так как дополнительные один-два часа работы отдельных сотрудников в течение нескольких дней позволяют существенно экономить средства на оплату консультационных услуг сторонней компании (которые в любом случае будут отрывать от работы тех же работников анкетами и вопросами). Что касается самих работников предприятия, так или иначе выраженного противодействия с их стороны я в своей практике не встречал.

Вывод из всего этого можно сделать следующий: совершенно не обязательно каждый раз самим придумывать решения для стандартных задач. Всегда, когда Вы сталкиваетесь с необходимостью анализа той или иной функциональной системы (от системы проектирования космического корабля, до процесса приготовления комплексного ужина) - используйте годами проверенные и обкатанные методы. Одним из таких методов и является 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 уместно называть нотацией, входящей в состав методологии SADT.

Нотация IDEF0 – это достаточно строгая методика, которая изначально была разработана, как и стандарты технического конструирования, для ручного моделирования. Поэтому там содержатся требования по размещению стрелок, формату всех элементов, содержанию информационной рамки к IDEF0 диаграмме и пр. Поскольку деятельность компании – это сложная многоуровневая система действий, то схем получается всегда много, и необходима однозначная систематизация и навигация по всем элементам модели. Сейчас это делают в основном компьютерные системы, поддерживающие моделирование в данной нотации. На территории России наиболее известными и доступными на сегодня являются системы AllFusion Process Modeler и Business Studio. Обзору этих систем я планирую посвятить отдельные статьи.

Функциональный блок

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

Обязательные элементы функционального блока в IDEF0

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

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

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

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

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

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

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

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

Цель – конкретная формулировка назначения модели, по которой можно сверять в дальнейшем точность построения модели.
Точка зрения – от чьего лица строится модель, так как модель зависима всегда от ее автора и фокуса внимания. Если мы строим общую модель предприятия, то обычно она представляется с точки зрения его директора.
Тип модели – это указание на то, какая информация отображена на схемах. Здесь может быть 2 принципиальных варианта: AS IS («как есть») или TO BE («как будет»). Такое разделение необходимо, так как мы можем строить модели как для анализа деятельности, так и для ее трансформации. Мы должны четко отдавать себе отчет в том, что мы делаем, а также доносить эту информацию до окружающих.

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

Основные потоки

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

Материальный: материалы и комплектующие на входе и готовая продукция на выходе.
Клиентский: потенциальный клиент на входе и удовлетворенный на выходе.
Финансовый: на входе это обычно инвестиции, платежи клиентов (выручка), кредиты и прочие доходы; на выходе – это платежи поставщикам, налоги, платежи по кредитам и прибыль.
Информационный: на входе это все потоки информации о внешней среде (состояние рынка, поведение конкурентов, технологические инновации и пр.), а на выходе – это поток информации, которую компания сообщает о себе миру (вся рекламная информация, а так же все виды отчетности перед контролирующими органами).

Обратите внимание, что компания – это открытая система, и в ней ничего не возникает и не исчезает. Компания способна только преобразовывать входящие потоки в выходящие, и если она это делает хорошо, то появляется дополнительный денежный поток (прибыль), отражающий в каком-то смысле качество работы всей системы.

(нажмите для увеличения)

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

Стрелки управления могут быть представлены только 1 видом потока – информационным, который можно разбить на 2 подвида. Первый – это документы, такие как:

законы и нормы;
приказы, распоряжения;
инструкции и регламенты;
планы;
конструкторская документация и пр.

Второй – это недокументированная информация, к которой чаше всего относятся требования собственников.

И, наконец, механизмы – здесь только 2 вида потоков: оборудование (материальный) и исполнители (подразделения и люди). Здесь не может быть документов, как и не может быть людей на стрелках управления!

Для навигации в модели предусмотрена сквозная нумерация. Контекстная диаграмма нумеруется «А-0». В дальнейшем каждый функциональный блок получает свой номер, какой бы глубокой ни была декомпозиция.

Декомпозиция

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

(нажмите для увеличения)

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

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

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

На рисунке ниже представлена диаграмма декомпозиции нашего примера.

(нажмите для увеличения)

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

Дальнейшая работа над моделью аналогична первому шагу – проводится декомпозиция каждого функционального блока первого уровня. Нумерация блоков будет содержать при этом номер первого уровня: А1.1 … А1.n, A2.1 … A2.n и т.д.

Выводы об актуальности нотации

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

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

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

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

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

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

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

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

Преимущество графики

Что представляет собой модели IDEF0? Графические схемы со своими особенностями и правила их построения. Почему именно графика? Потому что она эффективна. В этом можно убедиться на нескольких примерах.

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

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

Преимущества IDEF0 для IT -специалистов

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

Так как же доступно донести суть, не прибегая к объемным текстам? Графика! Именно она позволяет сократить написанное, наглядно демонстрируя нужную информацию. Ведь одно изображение способно заменить сотни слов. И применительно к использованию графики при описании бизнес-процессов – это на 100% верно.

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

Нотация описания бизнес-процессов: что это такое

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

IDEF0 – это…

IDEF0 – метод функционального моделирования, а также графическая нотация, которая используется для описания и формализации бизнес-процессов. Особенность IDEF0 заключается в том, что эта методология ориентирована на соподчиненность объектов. IDEF0 была разработана для автоматизации предприятий еще в 1981 году в США.

Функциональная модель компании

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

Типы стрелок

Входящими ставятся задачи.

Исходящими выводят результат деятельности.

Управляющие (стрелки сверху вниз) – это механизмы управления.

Механизмы (стрелки снизу вверх) используются для проведения необходимых работ.

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

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

У IDEF0 есть еще оно неоспоримое преимущество. Эта методика была разработана сравнительно давно, и за три десятилетия она прошла тщательную шлифовку и корректировку. Поэтому создать функциональную модель компании можно быстро и минимальной вероятностью ошибки.

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

Как создается функциональная модель

Разберем создание функциональной модели на примере написания статьи.

Основной блок будет так и называться «Написание статьи».

То, что необходимо для написания статьи, отражается на входящих стрелках – «Опыт», «Дополнительная литература».

Управляющие стрелки для написания статьи – «План статьи», «Требования к оформлению», «Правила русского языка».

Механизмы – это непосредственно сам автор, копирайтер, редактор, программное обеспечение. Как организуется работа этих механизмов? Автор создает текст, записывая его аудиоверсию. Копирайтер переносит текст в текстовый формат, ориентируясь на план публикации, соблюдая требования издателя и правила русского языка. Затем к работе подключается редактор, который проверяет статью, исправляя речевые, орфографические и пунктуационные ошибки. Программное обеспечение – это те программы и инструменты, которыми пользовались участники процесса при создании статьи.

Все вышеописанное – только общая схема работы, поэтому ее нужно детализировать.

Вернемся к нашей модели и декомпозируем общий блок на несколько связанных между собой элементов.

Так, весь процесс написания статьи можно разделить на 4 этапа:

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

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

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

Функциональное моделирование эффективно используется при принятии различных управленческих решений. В приведенном нами примере процесса написания статьи два специалиста – копирайтер и редактор. И при необходимой оптимизации финансирования проекта по схеме несложно определить, как это сделать. У копирайтера и корректора схожие методы работы, поэтому всю работу можно предложить выполнить копирайтеру, так как он работает непосредственно с аудиотекстом, чего редактор делать не умеет. При этом копирайтеру можно предложить выполнить эту работу за половину той суммы, которая предназначалась редактору. Да, от этого, возможно, потеряется качество текста, но задача оптимизации была выполнена успешно. А сделать это без наглядной схемы было бы сложнее.

Процесс создания нотации IDEF0

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

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

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

Вторую нотацию можно назвать «Как должно быть». Она создается на основе первой с изменениями, внесенными в соответствии с поставленной задачей.

Стандарт IDEF0 и его требования

О базовых требованиях IDEF0 мы говорили чуть выше.

Главный элемент – в верхнем левом углу.
Каждый элемент должен иметь входящие и исходящие стрелки. Причем входящие стрелки находятся слева, справа – исходящие.
Сверху располагаются управляющие элементы, снизу – механизмы.
При расположении нескольких блоков на одном листе или экране последующие размещаются справа внизу от предыдущего.
Схемы следует создавать так, чтобы стрелки пересекались минимальное количество раз.

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

Ошибки при работе с IDEF0

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

Использование нескольких цветов

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

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

Большое количество блоков

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

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

Изменение структуры при исправлении ошибок

При создании схемы важно, чтобы не один процесс не остался без входящих, исходящих или иных важных элементов. К примеру, если нужно удалить из схемы автора, то нужно удалять все элементы и стрелки, непосредственно к нему относящиеся. Если же они останутся в схеме, то возникнет недоразумение и путаница, так как при детализации будут вести неизвестно куда.

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

Название блоков и управляющих элементов

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

Преимущества использования IDEF0

Наглядность. Изобразив работу компании в виде схемы, становится понятным, как работает компания, где могут возникнуть проблемы и как предупредить их появление.

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

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

Минимальная вероятность ошибки. Работа по стандарту IDEF0 требует строгого следования его правилам. Это дисциплинирует исполнителя и исключает возможность возникновения ошибки. К тому же любое несоответствие стандарту сразу же становится заметным.

И напоследок

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

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

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

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

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

Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, "производить услуги"). На диаграмме функциональный блок изображается прямоугольником (Рис. 3.).

Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом:

Верхняя сторона имеет значение "Управление" (Control);

Левая сторона имеет значение "Вход" (Input);

Правая сторона имеет значение "Выход" (Output);

Нижняя сторона имеет значение "Механизм" (Mechanism).

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

Рис. 3. - Функциональный блок

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

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

Декомпозиция (Decomposition) является основным понятием стандарта IDEF0. Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции . При этом уровень детализации процесса определяется непосредственно разработчиком модели.

Декомпозиция позволяет постепенно и структурировано представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой (Рис.4.).

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

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

Рис. 4. - Схема декомпозиции функциональных блоков модели

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

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

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

В свою очередь, функциональный блок — предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит - родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. В каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок или исходящие из него, фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0-модели.

Иногда отдельные интерфейсные дуги высшего уровня не имеет смысла продолжать рассматривать на диаграммах нижнего уровня, или наоборот — отдельные дуги нижнего отражать на диаграммах более высоких уровней - это будет только перегружать диаграммы и делать их сложными для восприятия. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования. Обозначение "туннеля" (Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из "туннеля") только на этой диаграмме.

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

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

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

Обычно процесс разработки является итеративным и состоит из следующих условных этапов : Создание модели группой специалистов, относящихся к различным сферам деятельности предприятия. Эта группа в терминах IDEF0 называется авторами (Authors). Построение первоначальной модели является динамическим процессом, в течение которого авторы опрашивают компетентных лиц о структуре различных процессов, создавая модели деятельности подразделений.

При этом их интересуют ответы на следующие вопросы:

Что поступает в подразделение "на входе"?

Какие функции и в какой последовательности выполняются в рамках подразделения?

Кто является ответственным за выполнение каждой из функций ?

Чем руководствуется исполнитель при выполнении каждой из функций ?

Что является результатом работы подразделения (на выходе)?

На основе имеющихся положений, документов и результатов опросов создается черновик (Model Draft) модели.

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

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

Модель IDEF0 рекомендована к применению в предприятии при описании бизнес-процессов на верхнем уровне. При составлении функциональной модели бизнес-процесса (IDEF0) описываются выполняемые функции и входные, выходные потоки материальных, финансовых ресурсов и информации (документов, файлов).

Условные обозначения формата IDEF0 представлены в таблицах 2,3.

Таблица 2. - Графические символы нотации IDEF0

Символ	Изображение	Описание
Блок		Блок описывает процесс. Типичный блок показан на рис. 1. Внутри каждого блока помещается его имя и номер. Имя должно быть активным глаголом, глагольным оборотом или отглагольным существительным. Номер блока размещается в правом нижнем углу. Номера блоков используются для идентификации на диаграмме и в соответствующем тексте.
Стрелка		Стрелки обозначают входящие и исходящие из процесса объекты (данные). Каждая сторона функционального блока имеет стандартное значение с точки зрения связи блок-стрелка, В свою очередь, сторона блока, к которой присоединена стрелка, однозначно определяет ее роль. Стрелки, входящие в левую сторону блока - входы. Стрелки, входящие в блок сверху - управления. Стрелки, покидающие процесс справа - выходы, т.е. данные или материальные объекты, произведенные процессом. Стрелки, подключенные к нижней стороне блока, представляют механизмы.
Туннелированная стрелка		Туннелированные стрелки означают, что данные, обозначаемые этими стрелками, не рассматриваются на родительской диаграмме и/или на дочерней диаграмме. Стрелка, помещенная в туннель там, где она присоединяется к блоку, означает, что данные, выраженные этой стрелкой, не обязательны на следующем уровне декомпозиции. Стрелка, помещаемая в туннель на свободном конце означает, что выраженные ею данные отсутствуют на родительской диаграмме.
Внешняя ссылка		Внешняя ссылка - место, сущность или субъект, которые находятся за границами моделируемой системы. Используются для обозначения источника или приемника стрелки вне модели. На диаграммах Внешняя ссылка изображается в виде квадрата, рядом с которым показано наименование Внешней ссылки.
Междиаграммная ссылка		Элемент, обозначающий другую диаграмму. Служит для обозначения перехода стрелок на диаграмму другого бизнес-процесса без показа стрелки на вышележащей диаграмме (при использовании иерархических моделей).

Таблица 3. - Графические символы нотации IDEF0