Журнал о системах электронного документооборота (СЭД)
Моделирование и регламентация бизнес-процессов

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

  17 комментариев Добавить в закладки

«Divide et impera»
Максима римского сената

 Шёл 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.

Ещё материалы автора
Похожие записи
Комментарии (17)
Елена Истомина 14 сентября 2010 г. 17:09  

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

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

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

 

С помощью нотации IDEF0 можно описать процесс и на очень низком уровне

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

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

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

Андрей Романов 17 сентября 2010 г. 09:11  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сергей Александрович 31 мая 2012 г. 00:41  

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

Сейчас обсуждают
Больше комментариев