Наверх

Глава 2. Нотация IDEF0, или Матрешка для бизнес-аналитика

Время чтения: 6 минут
16
Глава 2. Нотация IDEF0, или Матрешка для бизнес-аналитика

Шел 1981 год, департамент ВВС США разрабатывал программу автоматизации промышленных предприятий, которая сокращённо называлась ICAM (Integrated Computer Aided Manufacturing)…

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.

Изображение от vectorjuice на Freepik.

Чтобы прочитать эту статью до конца,
или зарегистрируйтесь

Комментарии 16

Елена Истомина 14 сентября 2010

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

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

Ольга Ситникова 14 сентября 2010
IDEF0 лучше всего подходит для описания процессов "верхнего уровня"
Да, ведь именно для этого этот стандарт и создавался: описать общую картину так, чтобы её видели все разом, а те, кому нужно, детализировали до нужной степени.
Для описания нотаций на более нижних уровнях лучше использовать другие нотации (например, BPMN).
А вот с этим утверждением не соглашусь. С помощью нотации IDEF0 можно описать процесс и на очень низком уровне, вплоть до имени конкретного исполнителя очень небольшого действия, стоимость которого составляет копейки. А если подключить ещё и родственную ей DFD-нотацию, то уточнить даже и то, какой исполнитель какую информацию и у кого должен запросить.
Елена Истомина 16 сентября 2010
С помощью нотации IDEF0 можно описать процесс и на очень низком уровне

Ну можно конечно. Просто мой личный опыт привел меня вот к таким выводам, т.к. BPMN с его дорожками нагляднее показывает функции каждого участника процесса. А именно это важно на нижних уровнях.

Ольга, а м.б. все-таки взять дальше для рассмотрения какой-то бизнес-процесс, а не бытовой?

А мне как раз бытовой пример понравился. Те, кто моделированием процессов занимается, реальных "деловых" процессов нарисуется еще... Зато все понятно :)
 

Андрей Романов 17 сентября 2010

Представленная технология позволит описать состав ресурсов процесса. Для описания реальных процессов

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

Александр Головко 17 сентября 2010

Я попал в кулинарный техникум?

А где хлеб?

Ольга Ситникова 17 сентября 2010

необходимо воспользоваться UML

Друзья, я хотела описать достоинства и недостатки именно IDEF0, описать те процессы, для которых, по моему мнению, удобно использовать именно IDEF0. Мне думалось, что комментарии будут касаться именно этой нотации навроде "а мы её используем для ...", а не "лучше использовать BPMN / UML" (причём без каких-либо пруфов). Автору известны достоинства и недостатки и других нотаций, но здесь речь идёт об одной, той, что упомянута в названии.
Ольга Ситникова 17 сентября 2010

Я попал в кулинарный техникум?

Опишите свой бизнес-процесс) Возможно, у вас получится так же забавно, как у меня.
Александр Головко 17 сентября 2010

Методу, который Вы описали, более 50 лет.

Если Вы используете его у себя на кухне, кто же против.

Если Вы используете его в работе, то покажите как.

Опишите свой бизнес-процесс) Возможно, у вас получится так же забавно, как у меня.
Специально для Вас
Ольга Ситникова 17 сентября 2010

Если Вы используете его у себя на кухне, кто же против.

Некачественный переход на личности =) Но я всё же думаю, что своя кухня - это своя кухня, а лезть в чужие нужно только по личным приглашениям.
Специально для Вас
Годный непонятный процесс =) Фишка в том, что когда преследуется цель описать НОТАЦИЮ, то какбе удобнее собственно НОТАЦИЮ и описать. У вас в статье, насколько я могла понять, пробежавшись мельком, цель была описать ПРОЦЕСС. Вы её достигли. А у меня была цель другая) И достигать я хотела как раз её. Посему в данном случае привязываться к тому, какой процесс описан в этой конкретной диаграмме (борщ или согласование договора в супермегакорпорации), это просто кощунство.  Как-то так)
Плюс людям нравится ;)
А мне как раз бытовой пример понравился. Те, кто моделированием процессов занимается, реальных "деловых" процессов нарисуется еще... Зато все понятно :)  
Анатолий Юмашев 21 сентября 2010
В следующих сериях вас ждут захватывающие истории о нотациях BPMN, EPC и UML.

ждем-с
Анатолий Юмашев 21 сентября 2010

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

Вот мы имеем процесс приготовления супа.

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

Вот этот момент как-то в нотациях обозначен? По каким правилам можно или нужно декомпозировать процессы?

Если рассматривать пример, то выделить "Чистку лука" и по какой то причине поставить перед "Подготовкой овощей" мы можем?

Или по какому то правилу нужно "Чистку лука" засунуть внутрь процесса "Подготовки овощей"?

Если такое правило есть, то как оно называется?

Я нашел 2 косвенных правила, это рациональное мышление и ВИСИ. Но рационализм есть не у всех, а ВИСИ по сути чуток из другой области.

У вас есть какое то правило или методика по которой вы определяется верность и корректность разбивания процессов на подпроцессы?

Анатолий Юмашев 21 сентября 2010
Именно поэтому нотация IDEF0 кажется более приемлемой для описания процессов технологических
А какие процессы еще бывают?
Технология - наука о технике (техника - способы или средства созданных людьми для оптимизации своих действий)
процесс - набор действия
Можно заключить что технология это набор процессов, или описание процесса это по сути и есть технология.
А вот с Еленой согласен.
IDEF0 лучше всего подходит для описания процессов "верхнего уровня",
Идефом удобно группировать действия. Мол вот эти действия относятся к производству, а вот эти к продажам, а вот эти к бэкофису или штабу :)
Там нет начала или реакции на события, на верхнем уровне нужно просто упорядочить процессы и раскидать стрелками кто и кому чего должен.
А вот когда дело доходит до процедур, которые запускаются по тому или иному событию, там уже рулит BPMN. Тут тоже согласен с Еленой. Хотя сравнить его могу лишь с EPC. И в первую очередь он удобен исполнителю и новому сотруднику. Посмотрел свою линию действий и уже примерно понял что нужно делать, от кого что ждать и кому чего передавать. А как нужно делать посмотрел в тексте. Все красиво :)
Ольга Ситникова 21 сентября 2010

Вот этот момент как-то в нотациях обозначен? По каким правилам можно или нужно декомпозировать процессы?

Нотация - это прежде всего система значков =) Поэтому в описаниях нотаций, как правило, не даётся правил проведения декомпозиции, а только способы её правильного оформления. Как правильно декомпозировать процессы, наверное, не может подсказать или научить никто, поскольку каждый человек уникален и у каждого свой образ мышления.
У вас есть какое то правило или методика по которой вы определяется верность и корректность разбивания процессов на подпроцессы?
Да, у меня есть своя методика =) Она называется методом, ну скажем так, визуализации. Нужно представить себе выполнение процесса: какие действия за какими выполняются, что для этого нужно, просто прокрутить в своей голове, как бы вы выполняли этот процесс. Если самому плохо получается, например, из-за недостатка знаний в предметной области, то можно спросить эксперта (будь то реальный человек или, скажем, интернет-страничка).
В нашем конкретном примере "Чистка лука" выглядит действием не настолько самостоятельным, чтобы выделять его в отдельную функцию на диаграмме декомпозиции первого уровня, но при этом и более узким, чем "Подготовка овощей" (хотя бы, например, потому что лук - это овощ =) ), что намекает на то, чтобы включить её в набор функций, декомпозирующих функцию "Подготовка овощей".
В общем, я считаю, что какой метод декомпозиции не предложи, он так или иначе, в той или иной степени, будет эмпирическим, а потому структуризации поддающимся слабо.
А какие процессы еще бывают?
Возможно, я ввела вас в заблуждение своей терминологией) Под "технологическим процессом" здесь я понимала процессы, наверное, производственные, которые происходят по чётко отлаженной технологии, просто потому хотя бы, что если нарушить технологию (изменить время проведения или условия), то можно получить продукт другого качества, а иногда и вообще другой. Примеры: химическое производство, изготовление кирпичей =), выплавка стали, варение шаманских зелий и проч. Антагонистами технологических процессов лично для меня являются бизнес-процессы: гибкие, зависящие от внешних воздействий, use cases для бизнес-процессов всегда подразумевают откат, компенсацию, обработку исключительных ситуаций и проч.
Все красиво :)
Да, у всего есть свои плюсы) И если красиво всё скомбинировать, будет просто шик! =)
Анатолий Юмашев 22 сентября 2010

Под "технологическим процессом" здесь я понимала процессы, наверное, производственные

Вооот. Давайте называть их "производственные" и "административные", а то понятия "технологические процессы" и "бизнес-процессы" если вдуматься в них по сути равны одному понятию "процессы".
Как то так :)
А в остальном супер статья! стиль изложения мой любимый, ждем-с BPMN + UML. И даже EPC - вдруг получится обнаружить ее полезность :)
михаил Иванов 31 октября 2010

Подскажите пожалуйста, в данной статье описан процесс готовки борща при помощи IDEF0-модели «как есть» (очень доступно и понятно), а можно на том же примере описать в моделе «как надо»?

За статью огромное спасибо! перечитал различные изложения. результат -- понял как оформлять, но не суть. Приготовил "БОРЩ" понял, кажется, суть ;)

Чтобы прокомментировать, или зарегистрируйтесь