IDEF0 диаграмма: примеры и правила построения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 3.12

Построение моделей

Ни одна модель не должна строиться без ясного осознания объек­та и целей моделирования . При выборе цели моделирования необхо­димо ответить на следующие вопросы:

• Почему моделируется данный процесс?
• Что выявит данная модель?
• Как ознакомившиеся с этой моделью смогут ее применить?

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

• Каковы задачи менеджера?
• Каковы задачи клерка?
• Кто контролирует работу?
• Какая технология нужна для выполнения каждого шага и т.п.

Точка зрения

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

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

Границы моделирования

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

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

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

Когда границы моделирования понятны, также становится яс­ным, какие объекты системы по тем или иным причинам не вошли в модель.

Выбор наименования контекстного блока

Рекомендуется следующая последовательность действий при по­строении модели "с нуля": формулирование цели моделирования, выбор точки зрения, определение границ моделирования. Наименова­ние контекстного блока - функционального блока самого высокого уровня - обобщает определение границ моделирования.

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

Определение стрелок на контекстной диаграмме

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

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

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

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

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

Когда контекстная диаграмма представляется завершенной, по­пробуйте задать следующие вопросы:

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

Нумерация блоков и диаграмм

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

Префикс повторяется для каждого блока модели. Номера исполь­зуются для отражения уровня декомпозиции, на котором находится блок. Блок АО декомпозируется в блоки Al, A2, A3 и т.д.; блок А1 - в А11, А12, А13 и т.д.; блок - А11 в А111, А112, А113 и т.д. Для каждо­го уровня декомпозиции в конце номера добавляется одна цифра.

Два подхода к началу моделирования

Модели могут проектироваться как с использованием подхода "в ширину", когда каждая диаграмма максимально детализируется перед своей декомпозицией, так и с подходом "в глубину", когда сна­чала определяется иерархия блоков, а затем создаются соединяющие их стрелки. Естественно, возможно применение комбинации этих подходов , причем иерархия блоков может иногда немного меняться после того, как нарисованы стрелки. Это происходит в случае, когда создание стрелок может изменить понимание внутренней архитекту­ры моделируемого объекта.

Когда остановиться

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

При необходимости дальнейшей детализации отдельных процес­сов может быть использована методология IDEF3 .

Другие диаграммы IDEF0

В дополнение к контекстным диаграммам и диаграммам декомпо­зиции при разработке и представлении моделей могут применяться другие виды IDEF0-диаграмм .

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

Презентационные диаграммы. Презентационные диаграммы (For Exposition Only diagrams - FEO diagrams) часто включают в мо­дели, чтобы проиллюстрировать другие точки зрения или детали, выходящие за рамки традиционного синтаксиса IDEF0. Диаграммы FEO допускают нарушение любых правил построения диаграмм IDEF0 в целях выделения важных с точки зрения аналитика частей модели. Ес­тественно, если диаграмма FEO включена в модель исключительно для отображения другой точки зрения на систему, она, скорее всего, внешне будет выглядеть как обыкновенная IDEF0-диаграмма , удовле­творяя всем ограничениям IDEF0.

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

Кроме того, встречаются следующие виды презентационных диа­грамм:

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

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

Методология SADT (Structured Analysis and Design Technique – методология структурного анализа и проектирования) представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели системы.

Начало разработки данной методологии было положено Дугласом Россом (США) в середине 60-х гг. ХХ в. С тех пор системные аналитики компании SofTech, Inc. улучшили SADT и использовали ее в решении широкого круга проблем. Программное обеспечение телефонных сетей, диагностика, долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, конфигурация компьютерных систем, обучение персонала, управление финансами и материально-техническим снабжением – вот некоторые из областей эффективного применения SADT. Широкий спектр областей указывает на универсальность и мощь методологии SADT. В программе «Интеграции компьютерных и промышленных технологий» (Integrated Computer Aided Manufacturing, ICAM) Министерства обороны США была признана полезность SADT. Это привело к публикации ее части в 1981 г., называемой IDEF0 (Icam DEFinition), в качестве федерального стандарта на разработку программного обеспечения. Под этим названием SADT стала применяться тысячами специалистов в военных и промышленных организациях . Последняя редакция стандарта IDEF0 была выпущена в декабре 1993г. Национальным институтом по стандартам и технологиям США (National Institute Standards and Technology, NIST).

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

Описывать любые системы, а не только информационные (DFD предназначена для описания программного обеспечения);

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

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

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

Модель (AS-IS, TO-BE или SHOULD-BE) может содержать 4 типа диаграмм [ , ]:

Контекстную диаграмму;

Диаграммы декомпозиции;

Диаграммы дерева узлов;

Диаграммы только для экспозиции (for exposition only, FEO).

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

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

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

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

6.3. Элементы графической нотации IDEF0

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

На следующем рисунке показаны основные элементы графической нотации IDEF0 .

Рис. 6.1. Элементы графической нотации IDEF0

Прямоугольник представляет собой работу (процесс, деятельность, функцию или задачу) , которая имеет фиксированную цель и приводит к некоторому конечному результату. Имя работы должно выражать действие (например, «Изготовление детали», «Расчет допускаемых скоростей», «Формирование ведомости ЦДЛ № 3»).

Взаимодействие работ между собой и внешним миром описывается в виде стрелок. В IDEF0 различают 5 видов стрелок :

- вход (англ. input) – материал или информация, которые используются и преобразуются работой для получения результата (выхода). Вход отвечает на вопрос «Что подлежит обработке?». В качестве входа может быть как материальный объект (сырье, деталь, экзаменационный билет), так и не имеющий четких физических контуров (запрос к БД, вопрос преподавателя). Допускается, что работа может не иметь ни одной стрелки входа. Стрелки входа всегда рисуются входящими в левую грань работы;

- управление (англ. control) – управляющие, регламентирующие и нормативные данные, которыми руководствуется работа. Управление отвечает на вопрос «В соответствии с чем выполняется работа?». Управление влияет на работу, но не преобразуется ей, т.е. выступает в качестве ограничения. В качестве управления могут быть правила, стандарты, нормативы, расценки, устные указания. Стрелки управления рисуются входящими в верхнюю грань работы. Если при построении диаграммы возникает вопрос, как правильно нарисовать стрелку сверху или слева, то рекомендуется ее рисовать как вход (стрелка слева);

- выход (англ. output) – материал или информация, которые представляют результат выполнения работы. Выход отвечает на вопрос «Что является результатом работы?». В качестве выхода может быть как материальный объект (деталь, автомобиль, платежные документы, ведомость), так и нематериальный (выборка данных из БД, ответ на вопрос, устное указание). Стрелки выхода рисуются исходящими из правой грани работы;

- механизм (англ. mechanism) – ресурсы, которые выполняют работу. Механизм отвечает на вопрос «Кто выполняет работу или посредством чего?». В качестве механизма могут быть персонал предприятия, студент, станок, оборудование, программа. Стрелки механизма рисуются входящими в нижнюю грань работы;

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

6.4. Типы связей между работами

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

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

1. Иерархическая связь (связь «часть» – «целое») имеет место между функцией и подфункциями, из которых она состоит.

Рис. 6.2. Иерархическая связь

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

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

Рис. 6.5. Прямая связь по входу	Рис. 6.6. Обратная связь по входу

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

Рис. 6.7. Потребительская связь

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

Рис. 6.8. Логическая связь

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

Рис. 6.9. Методическая связь

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

Рис. 6.10. Ресурсная связь

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

Рис. 6.11. Информационная связь

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

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

Рис. 6.12. Временная связь

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

Рис. 6.13. Случайная связь

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

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

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

1. Перед построением модели необходимо определиться, какая модель (модели) системы будет построена. Это подразумевает определение ее типа AS-IS, TO-BE или SHOULD-BE, а также определения позиции, с точки зрения которой строится модель. «Точку зрения» лучше всего представлять себе как место (позицию) человека или объекта, в которое надо встать, чтобы увидеть систему в действии. Например, при построении модели работы продуктового магазина можно среди возможных претендентов, с точки зрения которых рассматривается система, выбрать продавца, кассира, бухгалтера или директора. Обычно выбирается одна точка зрения, наиболее полно охватывающая все нюансы работы системы, и при необходимости для некоторых диаграмм декомпозиции строятся диаграммы FEO, отображающие альтернативную точку зрения.

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

3. Количество блоков на диаграммах декомпозиции рекомендуется в пределах 3–6. Если на диаграмме декомпозиции два блока, то она, как правило, не имеет смысла. При наличии большого количества блоков диаграмма становится перенасыщенной и трудно читаемой.

4. Блоки на диаграмме декомпозиции следует располагать слева направо и сверху вниз. Такое расположение позволяет более четко отразить логику и последовательность выполнения работ. Кроме этого маршруты стрелок будут менее запутанными и иметь минимальное количество пересечений.

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

Рис. 6.14. Функция без управления и входа

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

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

6. У каждого блока должен быть как минимум один выход.

Рис. 6.15. Функция без выхода

Работы без результата не имеют смысла и не должны моделироваться. Исключение составляют работы, отображаемые в модели AS-IS. Их наличие свидетельствует о неэффективности и несовершенстве технологических процессов. В модели TO-BE эти работы должны отсутствовать.

7. При построении диаграмм следует минимизировать число пересечений, петель и поворотов стрелок.

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

9. Каждый блок и каждая стрелка на диаграммах должны обязательно иметь имя. Допускается использовать ветвление (декомпозицию) или слияние (композицию) стрелок. Это связано с тем, что одни и те же данные или объекты, порожденные одной работой, могут использоваться сразу в нескольких других работах. И наоборот, одинаковые или однородные данные и объекты, порожденные разными работами, могут использоваться в одном месте.

Рис. 6.16. Ветвление стрелок

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

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

На диаграмме не допускается рисовать стрелки, когда до и после ветвления они не именованы. На рис. 6.17 стрелка, входящая в блок «Формирование типовых ведомостей», не имеет имени до и после ветвления, что является ошибкой.

Рис. 6.17. Неправильное именование стрелок

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

Рис. 6.18. Туннелирование стрелок

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

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

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

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

Рис. 6.19. Объединение связей

13. Каждый блок на диаграммах должен иметь свой номер. Для того чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Блок на диаграмме верхнего уровня обозначается 0, блоки на диаграммах второго уровня – цифрами от 1 до 9 (1, 2, …, 9), блоки на третьем уровне – двумя цифрами, первая из которых указывает на номер детализируемого блока с родительской диаграммы, а вторая номер блока по порядку на текущей диаграмме (11, 12, 25, 63) и т. д. Контекстная диаграмма имеет обозначение «А – 0», диаграмма декомпозиции первого уровня – «А0», диаграммы декомпозиции следующих уровней – состоят из буквы «А», за которой следует номер декомпозируемого блока (например, «А11», «А12», «А25», «А63»). На рисунке показано типичное дерево диаграмм (диаграмма дерева узлов) с нумерацией.

Рис. 6.20. Иерархия диаграмм

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

6.6. Пример построения модели IDEF0 для системы определения допускаемых скоростей

Расчет допускаемых скоростей движения поездов является трудоемкой инженерной задачей. При проходе поездом какого-либо участка фактическая скорость движения поезда не должна превышать предельно допускаемую. Эта предельно допускаемая скорость устанавливается исходя из опыта эксплуатации и специально проводимых испытаний по динамике движения и воздействию на путь подвижного состава. Непревышение этой скорости гарантирует безопасность движения поездов, комфортабельные условия езды пассажиров и т. п. Они определяются в зависимости от типа подвижного состава (марки локомотива и типа вагонов), параметров верхнего строения пути (типа рельсов, балласта, эпюры шпал) и плана (радиуса кривых, переходных кривых, возвышения наружного рельса и т. д.). Как правило, для установления допускаемых скоростей необходимо определить не менее двух (на прямых) и пяти (в кривых) скоростей, из которых и выбирается окончательная допускаемая скорость, как наименьшая из всех рассчитанных. Расчет этих скоростей регламентируются Приказом МПС России № 41 от 12 ноября 2001 г. «Нормы допускаемых скоростей движения подвижного состава по железнодорожным путям колеи 1520 (1524) мм Федерального железнодорожного транспорта».

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

Контекстная диаграмма для задачи определения допускаемых скоростей показана на рис.6.21. Для построения модели использовался продукт BPwin 4.0 фирмы Computer Associates.

Рис. 6.21. Контекстная диаграмма системы определения допускаемых скоростей (методология IDEF0)

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

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

Подробный продольный профиль (содержит информацию, аналогичную рассмотренной выше);

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

Данные о результатах съемки плана пути вагоном-путеизмерителем;

Ведомость возвышений наружного рельса в кривых (содержит информацию о плане пути).

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

Управляющими данными являются:

Указание начальника службы пути дороги или Департамента пути и сооружений ОАО «РЖД» на расчет;

Приказ № 41, содержащий нормативно-справочную информацию, порядок и формулы определения допускаемых скоростей;

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

Сведения о планируемых ремонтах пути, реконструкции и переустройстве сооружений и устройств.

Результатом работы системы должны быть:

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

Ведомости Приказа начальника дороги об установлении допускаемых скоростей на перегонах и раздельных пунктах (Приказ «Н») согласно принятой на дороге форме. Утвержденный Приказ «Н» официально закрепляет допускаемые скорости движения поездов;

Типовые формы № 1, 1а и 2, содержащие планируемые допускаемые скорости для разработки графика движения поездов.

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

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

Диаграмма декомпозиции первого уровня для рассматриваемой задачи приведена на рис.6.22. Как правило, при построении диаграммы декомпозиции исходная функция (декомпозируемая) разбивается на 3–8 подфункций (блоков). При этом блоки на диаграмме декомпозиции рекомендуется располагать слева направо сверху вниз, чтобы лучше была видна последовательность и логика взаимодействия подфункций.

Рис. 6.22. Диаграмма декомпозиции первого уровня (методология IDEF0)

Очередность выполнения функций для решения рассматриваемой задачи следующая:

Ввод и корректировка нормативно-справочной информации и данных по участкам дороги (блоки 1 и 2);

Подготовка задания на расчет (блок 3). В нем указывается, для какого участка и пути, а также марки локомотива и типа вагонов следует выполнить расчет;

Расчет допускаемых скоростей в соответствии с порядком и формулами, указанными в Приказе № 41 (блок 4). В качестве исходной информации выступают данные по пути участка (план, верхнее строение пути и т. д.) и нормативы, выбираемые на основании задания на расчет;

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

Формирование и подготовка проекта Приказа «Н» и типовых ведомостей (блоки 6 и 7).

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

6.7. ICOM-коды

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

ICOM-коды (аббревиатура от Input, Control, Output и Mechanism) предназначены для идентификации граничных стрелок. ICOM-код содержит префикс, соответствующий типу стрелки (I, С, О или М), и порядковый номер (см. рис.).

Одна картинка стоит тысячи слов

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

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

Несколько слов о преимуществах графики

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

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

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

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

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

Почему это важно для моей работы

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

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

Типичные ошибки

Использование различных цветов

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

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

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

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

Нарушение структуры при внесении корректировок

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

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

Чаще всего ошибки допускают при названии блоков. Например, вместо «Создать статью» пишут «Создание статьи». Блоки в данном подходе – это действия, а потому они должны быть всегда глаголами.

Выгоды использования IDEF0

• Самая первая выгода очевидна – это наглядность. Вы сами начинаете понимать, как работает та или иная система, и можете также наглядно пояснить, где в этой системе «тонкие места» и как ваши решения помогут избавиться от них.
• Взаимопонимание и отсутствие разночтений. При обсуждении работы компании с использованием функциональной модели у вас имеются наглядные и понятные интуитивно блоки задач с управляющими элементами. Кроме того, функциональное моделирование предполагает создание в случае необходимости глоссария, в котором раскрываются условные обозначения и термины. В результате вы с клиентом, руководителем, другими сотрудниками при обсуждении проблемы говорите на одном языке.
• Простота и высокая скорость создания модели. Конечно, научиться моделированию не так просто, как кажется. Ведь схема - это, по сути, сверхплотная подача информации, что очень хорошо для понимания, но для реализации такой подачи требуется особый подход. Мозг аналитика выступает в данном случае как очень мощный пресс с одной стороны, и фильтр – с другой. Но с опытом этот процесс становится очень быстрым. В результате вы получаете инструмент, который поможет и самому разобраться, что же происходит в той или иной системе, и при помощи созданного в сжатые сроки наглядного пособия проиллюстрировать важные моменты коллегам или заказчикам.
• Дисциплина и отсутствие ошибок. Стандарт IDEF0 предполагает строгие рамки и правила. Такой подход дисциплинирует, а привычка действовать в рамках стандарта помогает избежать ошибок по невнимательности. Любые нарушения стандарта становятся сразу заметны.

В чем трудность применения IDEF0

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

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

Еще статьи по данной теме.