Основные методологии обследования организаций. Стандарт IDEF0

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

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

Сначала система моделируется как единое целое - один функциональный блок с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма называется контекстной и обозначается идентификатором "А-0". В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).

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

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

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

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

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

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

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

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

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

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

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

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

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

• создание модели группой специалистов, относящихся к различным сферам деятельности предприятия (в терминах IDEF0 - авторы, Authors). В рамках этого этапа авторы расспрашивают компетентных лиц о структуре различных процессов. На основе имеющихся положений, документов и результатов опроса создается черновик (Model Draft) модели;
• распространение черновика для рассмотрения, согласований и комментариев. На этой стадии черновик модели обсуждается с широким кругом компетентных лиц ("читателей") на предприятии. Каждая из диаграмм письменно критикуется и комментируется, а затем передается автору. Автор, в свою очередь, письменно соглашается с критикой или отвергает её, излагая логику принятия решения, и возвращает откорректированный черновик для дальнейшего рассмотрения. Этот процесс продолжается до тех пор, пока авторы и читатели не придут к единому мнению;
• официальное утверждение модели. Согласованную модель утверждает руководитель рабочей группы, если у авторов и читателей нет разногласий по поводу ее адекватности. Окончательная модель представляет собой согласованное представление о предприятии (системе) с заданной точки зрения и для заданной цели.

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

В последние годы интерес в России к методологиям семейства IDEF неуклонно растет. При этом интерес к таким стандартам, как IDEF3-5 можно назвать скорее теоретическим, а внимание к IDEF0 - вполне практически обоснованным.

Первые Case-средства, позволяющие строить модели DFD и IDEF0, появились на российском рынке еще в 1996 году, одновременно с выходом популярной книги о принципах моделирования в стандартах SADT. Тем не менее, большинство руководителей до сих пор расценивают моделирование в стандартах IDEF скорее как дань моде, чем как эффективный способ оптимизации существующей системы управления бизнесом.

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

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

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

• что поступает в подразделение "на входе"?
• какие функции и в какой последовательности выполняются в рамках подразделения?
• кто является ответственным за выполнение каждой из функций?
• чем руководствуется исполнитель при выполнении каждой из функций?
• что является результатом работы подразделения (на выходе)?

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

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

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

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