IDEF0 на сегодняшний день является основным стандартом моделирования бизнес-процессов. Описание системы с помощью IDEF0 называется функциональной моделью . Модель описывает, что происходит в системе, как ею управляют, какие сущности она преобразует, какие средства использует для выполнения своих функций и что производит.
При построении модели должна быть поставлена цель моделирования, отвечающая на следующие вопросы:
· почему этот процесс должен быть смоделирован?
· что должна показывать модель?
· что может получить читатель?
Примеры определения цели: "идентифицировать и определить текущие проблемы, сделать возможным анализ потенциальных улучшений", "идентифицировать роли и ответственность служащих для написания должностных инструкций", «определить возможность автоматизации…», «регламентировать процесс…» и т.д.
Точка зрения также является одним из ключевых элементов при построении модели. Точку зрения можно представить как взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования.
Основной концептуальный принцип методологии IDEF – представление любой изучаемой системы в виде набора взаимодействующих и взаимосвязанных блоков, отображающих процессы, операции, действия, происходящие в изучаемой системе. В IDEF0 все, что происходит в системе и ее элементах, принято называть функциями. Каждой функции ставится в соответствие блок.
Функциональные блоки на диаграммах изображаются прямоугольниками, означающими поименованные процессы, функции, работы или операции, которые происходят в течение определенного времени и имеют распознаваемые результаты. Внутри каждого блока помещается его имя и номер. Имя блока должно быть активным глаголом, глагольным оборотом или отглагольным существительным, обозначающим действие.
Блоки в IDEF0 размещаются по степени важности, как ее понимает автор диаграммы. Этот относительный порядок называется доминированием. Доминирование понимается как влияние, которое один блок оказывает на другие блоки диаграммы. Наиболее доминирующий блок обычно размещается в верхнем левом углу диаграммы, а наименее доминирующий – в правом углу.
Интерфейсы, посредством которых блок взаимодействует с другими блоками или с внешней по отношению к моделируемой системе среде, представляются стрелками, входящими в блок или выходящими из него. Каждая сторона функционального блока имеет стандартное значение с точки зрения связи блок/стрелка. Стандартное расположение стрелок показано на рис.1.
Рис. 1. Контекст IDEF0.
Стрелки описывают взаимодействие блоков с внешним миром и между собой. Стрелки представляют собой некую информацию и именуются существительными или оборотами существительного.
В IDEF0 различают пять типов стрелок:
1. Вход - материал или информация, которые используются или преобразуется функциональным блоком для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа.
2. Управление - правила, стратегии, процедуры или стандарты, которыми руководствуется блок. Управление влияет на блок, но не преобразуется им.
3. Выход - материал или информация, которые производятся блоком. Блок без результата не имеет смысла и не должен моделироваться.
4. Механизм - ресурсы, которые выполняют блок, например, персонал предприятия, станки, устройства и т.д. По усмотрению аналитика стрелки механизма могут не изображаться в модели.
5. Вызов (Call) - специальная стрелка, указывающая на другую модель работы. Стрелка вызова используется для указания того, что некоторая работа выполняется за пределами моделируемой системы.
Стрелки на контекстной диаграмме служат для описания взаимодействия системы с окружающим миром. Граничные стрелки - стрелки, которые начинаются у границы диаграммы, а заканчиваются у работы или наоборот. Внутренние стрелки связывают блоки между собой. Различают пять видов связей работ.
1. Связь по входу - стрелка выхода вышестоящего блока направляется на вход нижестоящего (рис. 2).
Рис. 2. Отношение «выход-вход».
2. Связь по управлению - выход вышестоящего блока направляется на управление нижестоящего (рис. 3).
Рис. 3. Отношение «выход-управление».
3. Обратная связь по управлению - выход нижестоящего блока направляется на управление вышестоящего (рис. 4).
Рис. 4. Обратная связь по управлению
4. Обратная связь по входу - выход нижестоящего блока направляется на вход вышестоящего (рис. 5).
Рис. 5. Отношение обратной связи по входу
5. Связь выход-механизм - выход одного блока направляется на механизм другого (рис. 6).
Рис. 6 Связь «выход-механизм».
В нотации IDEF0 описание системы (модель) организовано в виде иерархически упорядоченных и взаимосвязанных диаграмм. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма). Контекстная диаграмма включает только один блок, характеризующий всю совокупность моделируемых процессов, без подробностей.
Рис. 7 Пример контекстной диаграммы IDEF0.
После чего проводится функциональная декомпозиция (рис.8) – этот блок деятельности (большой процесс) подразделяется на крупные подпроцессы – и каждый подпроцесс описывается отдельно (диаграммы декомпозиции). Затем каждый подпроцесс декомпозируется на более мелкие - и так далее до достижения необходимой детализации описания.
Рис.8 Пример диаграммы декомпозиции IDEF0.
Методология функционального моделирования IDEF0 - это технология описания системы в целом как множества взаимозависимых действий, или функций. Важно отметить функциональную направленность IDEF0 - функции системы исследуются независимо от объектов, которые обеспечивают их выполнение. "Функциональная" точка зрения позволяет четко отделить аспекты назначения системы от аспектов ее физической реализации. На рисунке 3 приведен пример типовой диаграммы IDEF0.
Наиболее часто IDEF0 применяется как технология исследования и проектирования систем на логическом уровне. По этой причине он, как правило, используется на ранних этапах разработки проекта, до IDEF3 моделирования для сбора данных и моделирования процесса "как есть". Результаты IDEF0 анализа могут применяться при проведении проектирования с использованием моделей IDEF3 и диаграмм потоков данных.
Синтаксис и семантика моделей IDEF0
Модели IDEF0
IDEF0 сочетает в себе небольшую по объему графическую нотацию (она содержит только два обозначения: блоки и стрелки) со строгими и четко определенными рекомендациями, в совокупности предназначенными для построения качественной и понятной модели системы.
Методология IDEF0 в некоторой степени напоминает рекомендации, существующие в книгоиздательском деле, часто набор напечатанных моделей IDEF0 организуется в брошюру (называемую в терминах IDEF0 комплект), имеющую содержание, глоссарий и другие элементы, характерные для законченной книги.
Первый шаг при построении модели IDEF0 заключается в определении назначения модели - набора вопросов, на которые должна отвечать модель. Набор вопросов можно сравнить с предисловием, в котором раскрывается назначение книги.
Границы моделирования предназначены для обозначения ширины охвата предметной области и глубины детализации и являются логическим продолжением уже определенного назначения модели. Как читающий модель, так и непосредственно ее автор должны понимать степень детальности ответов на поставленные в назначении модели вопросы.
Следующим шагом указывается предполагаемая целевая аудитория, для нужд которой создается модель. Зачастую от выбора целевой аудитории зависит уровень детализации, с которым должна создаваться модель. Перед построением модели необходимо иметь представление о том, какие сведения о предмете моделирования уже известны, какие дополнительные материалы и (или) техническая документация для понимания модели могут быть необходимы целевой аудитории, какие язык и стиль изложения являются наиболее подходящими.
Под точкой зрения понимается перспектива, с которой наблюдалась система при построении модели. Точка зрения выбирается таким образом, чтобы учесть уже обозначенные границы моделирования и назначение модели. Однажды выбранная точка зрения остается неизменной для всех элементов модели. При необходимости могут быть созданы другие модели, отображающие систему с других точек зрения. Вот несколько примеров точек зрения при построении моделей: клиент, поставщик, владелец, редактор.
Действия
Действие, обычно в IDEF0 называемое функцией, обрабатывает или переводит входные параметры (сырье, информацию и т.п.) в выходные. Поскольку модели IDEF0 представляют систему как множество иерархических (вложенных) функций, в первую очередь должна, быть определена функция, описывающая систему в целом - контекстная функция. Функции изображаются на диаграммах как поименованные прямоугольники, или функциональные блоки. Имена функций в IDEF0 подбираются по сходным правилам с именами действий в IDEF3 - с использованием глаголов или отглагольных существительных. Важно подбирать имена таким образом, чтобы они отражали систему так, как если бы она обозревалась с точки зрения, выбранной для моделирования.
Пример функционального блока приведен на рисунке 2.1.
Рисунок 2.1 – Функциональный блок IDEF0
Выше мы определяли IDEF0 модели как иерархическое множество вложенных блоков. Любой блок может быть декомпозирован на составляющие его блоки. Декомпозицию часто ассоциируют с моделированием "сверху вниз", однако это не совсем верно. Функциональную декомпозицию корректнее определять как моделирование "снаружи вовнутрь", в котором мы рассматриваем систему наподобие луковицы, с которой последовательно снимаются слои.
Границы и связи
Чтобы быть полезным, описание любого блока должно, как минимум, включать в себя описание объектов, которые блок создает в результате своей работы ("выхода"), и объектов, которые блок потребляет или преобразует ("вход").
В IDEF0 также моделируются управление и механизмы исполнения. Под управлением понимаются объекты, воздействующие на способ, которым блок преобразует вход в выход. Механизм исполнения - объекты, которые непосредственно выполняют преобразование входа в выход, но не потребляются при этом сами по себе.
I (Input) - вход - нечто, что потребляется в ходе выполнения процесса;
С (Control) - управление - ограничения и инструкции, влияющие на ход выполнения процесса;
О (Output) - выход - нечто, являющееся результатом выполнения процесса;
М (Mechanism) - исполняющий механизм - нечто, что используется для выполнения процесса, но не потребляется само по себе. Рисунок 2.2 показывает 4 возможных типа стрелок в IDEF0, каждый из типов соединяется со своей стороной функционального блока.
Рисунок 2.2 - Каждый тип стрелки соединяется со своей
стороной функционального блока
Для названия стрелок, как правило, употребляются имена существительные. Стрелки могут представлять собой людей, места, вещи, идеи или события. Как и в случае с функциональными блоками, присвоение имен всем стрелкам на диаграмме является только необходимым условием для понимания читателем сути изображенного. Отдельное описание каждой стрелки в текстовом виде может оказаться критическим фактором для построения точной и полезной модели.
Стрелки входа . Вход представляет собой сырье, или информацию, потребляемую или преобразуемую функциональным блоком для производства выхода. Стрелки входа всегда направлены в левую сторону прямоугольника, обозначающего в IDEF0 функциональный, блок. Наличие входных стрелок на диаграмме не является обязательным, так как возможно, что некоторые блоки ничего не преобразуют и не изменяют. Примером блока, не имеющего входа, может служить "принятие решения руководством", где для принятия решения анализируется несколько факторов, но ни один из них непосредственно не преобразуется и не потребляется в результате принятия какого-либо решения.
Стрелки управления . Стрелки управления отвечают за регулирование того, как и когда выполняется функциональный блок, и, если он выполняется, какой выход получается в результате его выполнения. Так как управление контролирует поведение функционального блока для обеспечения создания желаемого выхода, каждый функциональный блок должен иметь, как минимум, одну стрелку управления. Стрелки управления всегда входят в функциональный блок сверху.
Управление часто существует в виде правил, инструкций, законов, политики, набора необходимых процедур или стандартов. Влияя на работу блока, оно непосредственно не потребляется и не трансформируется в результате. Может оказаться, что целью функционального блока является как раз изменение того или иного правила, инструкции, стандарта и т.п. В этом случае стрелка, содержащая соответствующую информацию, должна рассматриваться не как управление, а как вход функционального блока.
Управление можно рассматривать как специфический вид входа. В случаях, когда неясно, относить ли стрелку к входу или к управлению, предпочтительно относить ее к управлению до момента, пока неясность не будет разрешена.
Стрелки выхода . Выход - это продукция или информация, получаемая в результате работы функционального блока. Каждый блок должен иметь, как минимум, один выход. Действие, которое не производит никакого четко определяемого выхода, не должно моделироваться вообще (по меньшей мере, должно рассматриваться в качестве одного из первых кандидатов на исключение из модели).
При моделировании непроизводственных предметных областей выходами, как правило, являются данные, в каком-либо виде обрабатываемые функциональным блоком. В этом случае важно, чтобы названия стрелок входа и выхода были достаточно различимы по своему смыслу. Например, блок "Прием пациентов" может иметь стрелку "Данные о пациенте" как на входе, так и на выходе. В такой ситуации входящую стрелку можно назвать "Предварительные данные о пациенте", а исходящую - "Подтвержденные данные о пациенте".
Стрелки механизма исполнения . Механизмы являются ресурсом, который непосредственно исполняет моделируемое действие. С помощью механизмов исполнения могут моделироваться: ключевой персонал, техника и (или) оборудование. Стрелки механизма исполнения могут отсутствовать в случае, если оказывается, что они не являются необходимыми для достижения поставленной цели моделирования.
Комбинированные стрелки . В IDEF0 существует пять основных видов комбинированных стрелок: выход - вход, выход - управление, выход - механизм исполнения, выход - обратная связь на управление и выход - обратная связь на вход.
Стрелка выход - вход применяется, когда один из блоков должен полностью завершить работу перед началом работы другого блока. Так, на рисунок 2.3 формирование счета должно предшествовать приему заказа.
Рисунок 2.3 - Комбинация стрелок выход - вход
Стрелка выход - управление отражает ситуацию преобладания одного блока над другим, когда один блок управляет работой другого. На рисунке 2.4 принципы формирования инвестиционного портфеля управляют поведением брокеров на бирже.
Рисунок 2.4 - Комбинированная стрелка выход - управление
Стрелки выход - механизм исполнения встречаются реже и отражают ситуацию, когда выход одного функционального блока применяется в качестве оборудования для работы другого блока. На рисунке 2.5 зажим, устройство, используемое для закрепления детали во время ее сборки, должно быть собрано для того, чтобы выполнить сборку детали.
Рисунок 2.5 - Комбинированная стрелка выход - механизм исполнения
Обратные связи на вход и на управление применяются в случаях, когда зависимые блоки формируют обратные связи для управляющих ими блоков. На рисунке 2.6 получаемая от брокеров информация о текущих биржевых курсах применяется для корректировки стратегии игры на бирже.
Рисунок 2.6 - Комбинированная стрелка выход - обратная связь на управление
Стрелка выход - обратная связь на вход обычно применяется для описания циклов повторной обработки чего-либо. Рисунок 2.7 может служить примером применения стрелки такого типа. Кроме того, связи выход - обратная связь на вход могут применяться в случае, если бракованная продукция может заново использоваться в качестве сырья, как это происходит, например, при производстве оконного стекла, когда разбитое в процессе производства стекло перемалывается и переплавляется заново вместе с обыкновенным сырьем.
Рисунок 2.7 - Комбинированная стрелка выход - обратная связь на вход
Разбиение и соединение стрелок . Выход функционального блока может использоваться в нескольких других блоках. Фактически чуть ли не главная ценность IDEF0 заключается в том, что эта методология помогает выявить взаимозависимости между блоками системы. Соответственно IDEF0 предусматривает как разбиение, так и соединение стрелок на диаграмме. Разбитые на несколько частей стрелки могут, иметь наименования, отличающиеся от наименования исходной стрелки. Исходная и разбитые (или объединенные) стрелки в совокупности называются связанными. Такая техника обычно применяется для того, чтобы отразить использование в процессе только части сырья или информации, обозначаемых исходной стрелкой (рисунок 2.8). Аналогичный подход применяется и к объединяемым стрелкам.
Рисунок 2.8 - Разбитая на две части и переименованная стрелка
Туннели
Понятие связанные стрелки используется для управления уровнем детализации диаграмм. Если одна из стрелок диаграммы отсутствует на родительской диаграмме (например, ввиду своей несущественности для родительского уровня) и не связана с другими стрелками той же диаграммы, точка входа этой стрелки на диаграмму или выхода с нее обозначается туннелем. На рисунке 2.9, например, стрелка "корпоративная информационная система" - важный механизм исполнения для данной диаграммы, но, возможно, она более нигде не используется в модели. Туннель в данном случае используется как альтернатива загромождению родительских диаграмм помещением на них несущественных для их уровня стрелок.
Рисунок 2.9 - Пример применения туннеля
Построение моделей IDEF0
В этом подразделе мы рассмотрим методику построения моделей IDEF0 более подробно.
Диаграммы
На рисунке 2.10 типовая диаграмма IDEF0 показана вместе с находящейся на ее полях служебной информацией. Служебная информация состоит из хорошо выделенных верхнего и нижнего колонтитулов (заголовка и "подвала") - Элементы заголовка используются для отслеживания процесса создания модели. Элементы "подвала" отображают наименование модели, к которой относится диаграмма, и показывают ее расположение относительно других диаграмм модели.
Рисунок 2.10 - IDEF0-диаграмма со служебной информацией на полях
Все элементы заголовка диаграммы перечислены в таблице 2.1.
Таблица 2.1 - Элементы заголовка диаграммы IDEF0
| Поле | Назначение |
| USED AT | Используется для отражения внешних ссылок на данную диаграмму (заполняется на печатном документе вручную) |
| Author, date, project | Содержит ФИО автора диаграммы, дату создания, дату последнего внесения изменений, наименование проекта, в рамках которого она создавалась |
| Notes 1…10 | При ручном редактировании программ пользователи могут зачеркивать цифру каждый раз, когда они вносят очередное изменение |
| Status | Статус отражает состояние разработки или утверждения данной диаграммы. Это поле используется для реализации формального процесса публикации я шагами пересмотра и утверждения |
| Working | Новая диаграмма, глобальные изменения или новый автор для существующей диаграммы |
| Draft | Диаграмма достигла некоторого приемлемого для читателей уровня и готова для предоставления на утверждение |
| Recommended | Диаграмма одобрена и утверждена. Какие-либо изменения не предвидятся |
| Publication | Диаграмма готова для окончательной печати и публикации |
| Reader | ФИО читателя |
| Date | Дата знакомства читателя с диаграммой |
| Context | Набросок расположения функциональных блоков на родительской диаграмме, на котором подсвечен декомпозируемый данный диаграммой блок. Для диаграммы самого верхнего уровня (контекстной диаграммы) в поле помещается контекст ТОР |
Все элементы "подвала" диаграммы перечислены в таблице 2.2.
Таблица 2.2 - Элементы "подвала" диаграммы IDEF0
| Поле | Назначение |
| Node | Номер диаграммы, совпадающий с номером родительского функционального блока |
| Title | Имя родительского функционального блока |
| Number (еще называют C-Number) | Уникальный идентификатор данной версии данной диаграммы. Таким образом, каждая новая версия диаграммы будет иметь новое значение в этом поле. Как правило, C-Number состоит из инициалов автора (которые предполагаются уникальными среди всех аналитиков проекта) и последовательного уникального идентификатора, например, SDO005. При публикации эти номера могут быть заменены стандартными номерами страниц. Если диаграмма замещает другую диаграмму, номер заменяемой диаграммы может быть заключен в скобки – SDJ005 (SDO004). Это обеспечивает хранение истории изменений всех диаграмм модели. |
Построение моделей
Ни одна модель не должна строиться без ясного осознания объекта и целей моделирования. Выбранное определение цели моделирования должно отвечать на следующие вопросы:
· Почему моделируется данный процесс?
· Что выявит данная модель?
· Как ознакомившиеся с этой моделью смогут ее применить?
Следующее предложение может служить примером формулирования цели моделирования. Выявить задачи каждого работника компании и понять в целом взаимосвязь между отдельно взятыми задачами для разработки руководства по обучению новых сотрудников.
Модели строятся для того, чтобы ответить на набор поставленных вопросов. Такие вопросы формулируются на ранних стадиях моделирования и впоследствии служат основой для четкого и краткого определения цели моделирования. Примерами таких вопросов могут быть:
· Каковы задачи менеджера?
· Каковы задачи клерка?
· Кто контролирует работу?
· Какая технология нужна для выполнения каждого шага? и т.п.
Точка зрения
С методической точки зрения при моделировании полезно использовать мнение экспертов, имеющих разные взгляды на предметную область, однако каждая отдельно взятая модель должна разрабатываться исходя из единственной заранее определенной точки зрения. Часто другие точки зрения вкратце документируются в прикрепленных диаграммах FEO (см. ниже) исключительно для наглядности изложения.
Точку зрения нужно подбирать достаточно аккуратно, основой для выбора должна служить поставленная цель моделирования. Наименованием точки зрения может быть наименование должности, подразделения или роли (например, руководитель отдела или менеджер по продажам). Как и в случае с определением цели моделирования, четкое определение точки зрения необходимо для обеспечения внутренней целостности модели и предотвращения постоянного изменения ее структуры. Может оказаться необходимым построение моделей с разных точек зрения для детального отражения всех особенностей выделенных в системе функциональных блоков.
Границы моделирования
Одним из положительных результатов построения функциональных моделей оказывается прояснение границ моделирования системы в целом и ее основных компонентов. Хотя и предполагается, что в процессе работы над моделью будет происходить некоторое изменение границ моделирования, их вербальное (словесное) описание должно поддерживаться с самого начала для обеспечения координации работы участвующих в проекте аналитиков. Как и при определении цели моделирования, отсутствие границ затрудняет оценку степени завершенности модели, поскольку границы моделирования имеют тенденцию к расширению с ростом размеров модели.
Границы моделирования имеют два компонента: ширину охвата и глубину детализации. Ширина охвата обозначает внешние границы моделируемой системы. Глубина детализации определяет степень подробности, с которой нужно проводить декомпозицию функциональных блоков.
Чтобы облегчить правильное определение границ моделирования при разработке моделей IDEF0, существенные усилия затрачиваются на разработку и рецензирование контекстной диаграммы IDEF0 (диаграммы "самого верхнего" уровня). Иногда даже прибегают к построению дополнительной диаграммы для отображения уровня, более высокого, чем контекстный, для данной модели, что позволяет обозначить систему, внутри которой располагается объект для моделирования. Существенные затраты на разработку контекстной диаграммы вполне оправданы, поскольку она является своего рода "точкой отсчета" для остальных диаграмм модели и вносимые в нее изменения каскадом отражаются на все лежащие ниже уровни.
Когда границы моделирования понятны, становятся ясными и причины, по которым некоторые объекты системы не вошли в модель.
Настоящие рекомендации по стандартизации предназначены для использования при анализе и синтезе производственно-технических и организационно-экономических систем методами функционального моделирования в различных отраслях экономики.
Рекомендации содержат описание комплекса средств для наглядного представления широкого спектра деловых, производственных и других процессов и операций предприятия на любом уровне детализации,
а также организационные и методические приемы применения этих средств.
Постоянное усложнение производственно-технических и организационно-экономических систем – фирм, предприятий, производств и других субъектов производственно-хозяйственной деятельности – и необходимость их анализа с целью совершенствования функционирования и повышения эффективности обусловливают необходимость применения специальных средств описания и анализа таких систем. Эта проблема приобретает особую актуальность в связи с появлением интегрированных компьютеризированных производств и автоматизированных предприятий.
В США в конце 70-х годов была предложена и реализована Программа интегрированной компьютеризации производства ICAM – Integrated Computer Aided Manufacturing, направленная на увеличение эффективности предприятий посредством широкого внедрения компьютерных (информационных) технологий.
Реализация программы ICAM потребовала создания адекватных методов анализа и проектирования производственных систем и способов обмена информацией между специалистами, занимающимися такими проблемами. Для удовлетворения этой потребности в рамках программы ICAM была разработана методология моделирования IDEF (ICAM Definition), позволяющая исследовать структуру, параметры и характеристики производственно-технических и организационно-экономических систем.
Методология IDEF
Общая методология IDEF состоит из трех частных методологий моделирования, основанных на графическом представлении систем:
IDEF0 используется для создания функциональной модели, отображающей
структуру и функции системы, а также потоки информации и материальных
объектов, преобразуемые этими функциями;
IDEF1 применяется для построения информационной модели, отображающей
структуру и содержание информационных потоков, необходимых для поддержки
функций системы;
IDEF2 позволяет построить динамическую модель меняющихся во времени
поведения функций, информации и ресурсов системы.
К настоящему времени наибольшее распространение и применение имеют методологии IDEF0 и IDEF1 (IDEF1X).
Методология IDEF0, особенности и приемы применения которой описываются в настоящих рекомендациях, основана на подходе, получившем название
SADT – Structured Analysis & Design Technique – метод структурного анализа и проектирования. Основу этого подхода и методологии IDEF0 составляет графический язык описания (моделирования) систем.
Общие понятия
Модель IDEF0: Графическое описание системы, разработанное с определенной целью и с выбранной точки зрения. Комплект документов IDEF0, которые изображают функции системы с помощью графики (диаграмм), текста и глоссария.
Цель: краткая формулировка причины создания модели.
Точка зрения: указание на должностное лицо или подразделение организации, с позиции которого разрабатывается модель. Для каждой модели точка зрения единственная.
Глоссарий: Список определений для ключевых слов, фраз и аббревиатур, связанных с узлами, блоками, стрелками или с моделью IDEF0 в целом.
Текст: Любой текстовый (не графический) комментарий к графической диаграмме IDEF0.
Примечание к модели: текстовый комментарий, являющийся частью диаграммы IDEF0 и используемый для записи факта, не нашедшего графического изображения.
Функция: деятельность, процесс или преобразование (моделируемые блоком IDEF0), идентифицируемое глаголом или глагольной формой, которая описывает, что должно быть выполнено.
Декомпозиция: разделение моделируемой функции на функции-компоненты.
Пример контекстной диаграммы
Диаграмма
Диаграмма: часть модели, описывающая декомпозицию блока.
Контекст: Окружающая среда, в которой действует функция (или комплект функций на диаграмме).
Контекстная диаграмма: диаграмма, имеющая узловой номер А–n (А минус n), которая представляет контекст модели. Диаграмма А–0, состоящая из одного блока, является необходимой (обязательной) контекстной диаграммой; диаграммы с узловыми номерами А–1, А–2, ..., – дополнительные контекстные диаграммы (n > 0).
Диаграмма А–0 (А минус ноль): Специальный вид (контекстной) диаграммы IDEF0, состоящей из одного блока, описывающего функцию верхнего уровня, ее входы, выходы, управление, и механизмы, вместе с формулировками цели модели и точки зрения, с которой строится модель.
Дочерняя диаграмма: диаграмма, детализирующая родительский (порождающий) блок.
Родительская диаграмма: диаграмма, которая содержит родительский блок.
Узловая ссылка: код, присвоенный диаграмме для ее идентификации и определения положения в иерархии модели; формируется из сокращенного имени модели и узлового номера диаграммы с дополнительными расширениями.
Узловой номер диаграммы: часть узловой ссылки диаграммы, которая соответствует номеру родительского блока.
Декомпозиция
На контекстной диаграмме А–0 объект моделирования представлен единственным блоком с граничными стрелками, отображающими связь объекта моделирования
с окружающей средой.
Единственная функция, представленная на контекстной диаграмме верхнего уровня, может быть разложена на основные подфункции путем создания дочерних диаграмм, содержащих детализацию родительских блоков.
Блок
Блок: прямоугольник, содержащий имя и номер и используемый для описания функции.
Номер блока: число (0–6), помещаемое в правом нижнем углу блока и однозначно идентифицирующее блок на диаграмме.
Имя блока: глагол или глагольный оборот, помещенный внутри блока и описывающий моделируемую функцию.
Дочерний блок: блок на дочерней (порожденной) диаграмме.
Родительский блок: блок, который подробно описывается дочерней диаграммой.
Для блоков установлены следующие синтаксические правила:
Размеры блоков должны быть достаточными для того, чтобы включить имя и номер блока.
Блоки должны быть прямоугольными, с прямыми углами;
Блоки должны быть нарисованы сплошными линиями.
Узел
Узел: блок, порождающий дочерние блоки; родительский блок.
Узловой номер: код, присвоенный блоку и определяющий его положение в иерархии модели; может быть использован в качестве подробного ссылочного выражения.
Дерево узлов: Представление отношений между родительскими и дочерними узлами модели IDEF0 в форме древовидного графа. Имеет то же значение и содержание, что и перечень узлов.
Перечень узлов: список, часто ступенчатый, показывающий узлы модели IDEF0 в упорядоченном виде. Имеет то же значение и содержание, что и дерево узлов.
Стрелка
Стрелка: Направленная линия, состоящая из одного или нескольких сегментов, которая моделирует открытый канал или канал, передающий данные или материальные объекты от источника (начальная точка стрелки), к потребителю (конечная точка с «наконечником»). Входная стрелка: класс стрелок, отображающих вход IDEF0-блока, то есть данные или материальные объекты, которые преобразуются функцией в выход. Входные стрелки связываются с левой стороной блока IDEF0. Выходная стрелка: класс стрелок, отображающих выход IDEF0 -блока, то есть данные или материальные объекты, произведенные функцией. Выходные стрелки связываются с правой стороной блока IDEF0. Стрелка механизма: Класс стрелок, которые отображают механизмы IDEF0, то есть средства, используемые для выполнения функции; включает специальный случай стрелки вызова. Стрелки механизмов связываются с нижней стороной блока IDEF0. Управляющая стрелка: Класс стрелок, которые в IDEF0 отображают управления, то есть условия, при выполнении которых выход блока будет правильным. Данные или объекты, моделируемые как управления, могут преобразовываться функцией, создающей соответствующий выход. Управляющие стрелки связываются с верхней стороной блока IDEF0.
Метка стрелки: существительное или оборот существительного, связанные со стрелкой или сегментом стрелки и определяющие их значение.
Внутренняя стрелка: входная, управляющая или выходная стрелка, концы которой связывают источник и потребителя, являющиеся блоками одной диаграммы. Отличается от граничной стрелки. Граничная стрелка: стрелка, один из концов которой связан с источником или потребителем, а другой не присоединен ни к какому блоку на диаграмме. Отображает связь диаграммы с другими блоками системы и отличается от внутренней стрелки. Сегмент стрелки: сегмент линии, который начинается или заканчивается на стороне блока, в точке ветвления или слияния, или на границе (несвязанный конец стрелки). Ветвление: разделение стрелки на два или большее число сегментов. Слияние: объединение двух или большего числа сегментов стрелок в один сегмент. Связывание/развязывание: Объединение значений стрелок в составное значение (связывание в «пучок»), или разделение значений стрелок (развязывание «пучка»), выраженные синтаксисом слияния или ветвления стрелок. Тильда: небольшая ломаная (волнистая) линия, используемая для соединения метки с конкретным сегментом стрелки или примечания модели с компонентом диаграммы. Код ICOM: код, обеспечивающий соответствие граничных стрелок дочерней диаграммы со стрелками родительского блока; используется для ссылок (аббревиатура ICOM расшифровывается как Input – вход, Control – управление, Output – выход, Mechanism – механизм).
Семантика блоков и стрелок
Каждая сторона функционального блока имеет стандартное назначение с точки зрения связи блок/стрелки. В свою очередь, сторона блока, к которой присоединена стрелка, однозначно определяет ее роль.
Для стрелок установлены следующие синтаксические правила:
- Ломаные стрелки изменяют направление только под утлом 90°;
- Стрелки должны быть нарисованы сплошными линиями.
Можно использовать линии различной толщины;
- Стрелки могут состоять только из вертикальных или горизонтальных отрезков.
Отрезки, направленные по диагонали, не допускаются;
- Концы стрелок должны касаться внешней границы функционального блока,
но не должны пересекать ее;
Стрелки должны присоединяться к блоку на его сторонах.
Присоединение в углах не допускается.
Далее рассмотрим стандартные методы системного структурного анализа, описанные серией федеральных стандартов США «Icam Definition », в соответствии с . Подробную информацию по всем стандартам этой серии можно найти на сайте http://www.idef.com.
Стандарт IDEF0 (FIPS183) предназначен для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, связывающие эти функции. Данный документ представляет собой оформление (по инициативе Министерства обороны США) в виде стандарта технологии анализа сложных систем SADT (Structured Analysis and Design Technique), разработанной группой американских аналитиков во главе с Дугласом Россом в 1973 году.
Метод, предлагаемый стандартом IDEF0, предназначен для функционального моделирования, то есть моделирования выполнения функций объекта, путем создания описательной графической модели, показывающей что, как и кем делается в рамках функционирования предприятия. Функциональная модель представляет собой структурированное изображение функций производственной системы или среды, информации и объектов, связывающих эти функции. Модель строится методом декомпозиции: от крупных составных структур к более мелким, простым. Элементы каждого уровня декомпозиции представляют собой действия по переработке информационных или материальных ресурсов при определенных условиях с использованием заданных механизмов. Каждое действие раскладывается на более мелкие операции по переработке определенной части информационных или материальных ресурсов при определенных условиях с использованием части заданных механизмов. Аналогично раскладываются операции. Последний шаг декомпозиции должен приводить к получению модели, степень детализации которой удовлетворяет требованиям, заданным в самом начале процесса создания модели.
Методология IDEF0 основана на следующих положениях:
1. Система и модель . Модель – искусственный объект, представляющий собой отображение (образ) системы и ее компонентов. М моделирует А , если М отвечает на вопросы относительно А . Здесь М – модель, А – моделируемый объект (оригинал). Модель разрабатывают для понимания, анализа и принятия решений о реконструкции (реинжиниринге) или замене существующей, либо проектировании новой системы. Система представляет собой совокупность взаимосвязанных и взаимодействующих частей, выполняющих некоторую полезную работу. Частями (элементами) системы могут быть любые комбинации разнообразных сущностей, включающие людей, информацию, программное обеспечение, оборудование, изделия, сырье или энергию. Модель описывает, что происходит в системе, как ею управляют, какие сущности она преобразует, какие средства использует для выполнения своих функций и что производит.
2. Блочное моделирование и его графическое представление . Основной концептуальный принцип методологии IDEF – представление любой изучаемой системы в виде набора взаимодействующих и взаимосвязанных блоков, отображающих процессы, операции, действия, происходящие в изучаемой системе. В IDEF0 все, что происходит в системе и ее элементах, принято называть функциями. Каждой функции ставится в соответствие блок. На IDEF0-диаграмме (чаще говорят SADT-диаграмме), основном документе при анализе и проектировании систем, блок представляет собой прямоугольник. Интерфейсы, посредством которых блок взаимодействует с другими блоками или с внешней по отношению к моделируемой системе средой, представляются стрелками, входящими в блок или выходящими из него. Входящие стрелки показывают, какие условия должны быть одновременно выполнены, чтобы функция, описываемая блоком, осуществилась.
3. Строгость и формализм . Разработка моделей IDEF0 требует соблюдения ряда строгих формальных правил, обеспечивающих преимущества методологии в отношении однозначности, точности и целостности сложных многоуровневых моделей. Эти правила описываются ниже с точки зрения технологии SADT. Здесь отмечается только основное из них: все стадии и этапы разработки и корректировки модели должны строго, формально документироваться с тем, чтобы при ее эксплуатации не возникало вопросов, связанных с неполнотой или некорректностью документации.
4. Итеративное моделирование . Разработка модели в IDEF0 представляет собой пошаговую, итеративную процедуру. На каждом шаге итерации разработчик предлагает вариант модели, который подвергают обсуждению, рецензированию и последующему редактированию, после чего цикл повторяется. Такая организация работы способствует оптимальному использованию знаний системного аналитика, владеющего методологией и техникой IDEF0, и знаний специалистов – экспертов в предметной области, к которой относится объект моделирования.
5. Отделение «организации» от «функций» . При разработке моделей следует избегать изначальной «привязки» функций исследуемой системы к существующей организационной структуре моделируемого объекта (предприятия, фирмы). Это помогает избежать субъективной точки зрения, навязанной организацией и ее руководством. Организационная структура должна явиться результатом использования (применения) модели. Сравнение результата с существующей структурой позволяет, во-первых, оценить адекватность модели, а во-вторых – предложить решения, направленные на совершенствование этой структуры.
Примеры задач, решаемых на основе методологии моделирования IDEF0:
Анализ и реинжиниринг бизнес-процессов.
Разработка информационной системы управления данными о качестве.
Разработка регламентов и процедур обеспечения качества продукции и создания систем обработки данных о качестве. Функциональная модель позволяет заменить традиционные руководства по качеству в виде описательных текстовых бумажных документов – стандартизованными электронными моделями, целостность и непротиворечивость которых поддерживается автоматически. При необходимости из них всегда можно получить бумажный отчет в привычном виде.
Проектирование информационной инфраструктуры, процедур и регламентов информационного взаимодействия.
Задачи анализа рисков в плане информационной безопасности.
Рассмотрим в соответствии с работой принципы построения диаграмм по технологии SADT (IDEF0).
Графический язык SADT прост и гармоничен. В основе методологии лежат четыре основных понятия.
Первым из них является понятие «функциональный блок ». Функциональный блок графически изображается в виде прямоугольника (см. рис. 3.23) и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, «производить услуги », а не «производство услуг »). Каждая из четырех сторон функционального блока имеет своё определенное значение (роль), при этом: верхняя сторона имеет значение «управление » (contr ol); левая сторона имеет значение «вход » (input ); правая сторона имеет значение «выход » (output ); нижняя сторона имеет значение «механизм » (mechanism ). Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.
Известная сегодня уже не только в узких кругах аббревиатура 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 практически единственная на сегодня нотация, которая позволяет сделать это содержательно и аккуратно.
В проектном управлении этот стандарт моделирования наиболее применим там, где нужно связать наглядными потоками разные проекты или процессы. Графическая модель при этом позволит более рационально распределить ответственность и ресурсы по задачам. Логика выполнения задач проекта, отраженная на схемах, поможет подготовить более качественный календарный план в виде диаграммы Ганта.