Нотация 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 кажется более приемлемой для описания процессов технологических.

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