ICAM, IDEF, IDEF0

Шел 1981 год, департамент ВВС США разрабатывал программу автоматизации промышленных предприятий под названием ICAM (Integrated Computer Aided Manufacturing). Для успешного хода проекта требовалось моделировать автоматизированное предприятие всем участникам параллельно. Специально для этих целей был разработан набор стандартов IDEF (ICAM DEFinition). Одним из стандартов набора являлась нотация функционального моделирования под кодовым названием IDEF0, которая слегка видоизменялась с ходом времени, и спецификация для последней версии была выпущена в декабре 1993 года. Расскажу немного об особенностях процесса функционального моделирования бизнес-процесса с помощью нотации IDEF0 и одновременно помогу упомянутому мною в предыдущей статье Аристарху Григорьевичу: опишу бизнес-процесс приготовления борща.

Функциональное моделирование начинается с определения основной задачи, которая решается путем выполнения этого бизнес-процесса. В нашем случае — «приготовить борщ». Для начала стоит определить, какими данными и материалами мы обладаем до выполнения бизнес-процесса (входные данные/input), а также четко обозначить, что мы хотим получить в результате выполнения бизнес-процесса (выходные данные/output). Это позволит выявить четкие требования к бизнес-процессу и отбросить несбыточные надежды: обладая лишь горсткой сомнительного происхождения камней невозможно получить золотые слитки. В случае приготовления борща на входе имеются, например, овощи и мясо (их может, конечно, и не быть, но допустим, что все продукты были предусмотрительно закуплены). На выходе мы должны вполне логично получить борщ.

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

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

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

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

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

Рис. 2. Диаграмма декомпозиции первого уровня

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

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

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

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

Методология IDEF0 и сложности

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

В следующих сериях вас ждут захватывающие истории о нотациях BPMN, EPC и UML.