Вступление
Очень не хочется превращать данную статью в сухой академический текст с очередным объяснением, как рисовать в определенной нотации бизнес-процессы. А ведь разнообразие графических нотаций и методологий моделирования при первом приближении может испугать. С какой начать? Как ее использовать? Что вообще с этим делать? Если вбить в поисковик название самой первой и достаточно популярной нотации IDEF0, то будет много ссылок описательного содержания. Поэтому не будем уходить в теорию сильно, а попробуем разобрать на практике применение данной нотации в действии.
Краткая история
IDEF0 – это методология функционального моделирования и графическая нотация, используемая для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, связывающих эти функции.
Раз это нотация, то она имеет систему требований и правил для построения модели деятельности в том или ином виде. Ее мы и рассмотрим на практике.
IDEF0 был разработан в далеком 1981 году в рамках программы автоматизации промышленных предприятий ICAM (Integrated Computer Aided Manufacturing) департаментом Военно-воздушных сил США. Все последующие стандарты, разработанные на этой основе, унаследовали название IDEF (ICAM Definition).
Как Федеральный стандарт обработки информации IDEF0 (Integration Definition for Function Modeling) был утвержден в США в 1993 году.
В России находится в статусе руководящего документа с 2000 года (РД IDEF0 - 2000. Методология функционального моделирования IDEF0) и в настоящее время в качестве стандарта не утверждена. Тем не менее IDEF0 является одним из популярных подходов для описания бизнес-процессов. При использовании определений и названий элементов я буду приводить их на русском языке, а также указывать английскую интерпретацию для понимания и исключения разночтений.
Графический стандарт IDEF0 является частью методологии SADT (Structured Analysis and Design Technique). Методология SADT – методология структурного анализа и проектирования, предложенная Дугласом Россом и применяющаяся в период с 1969-1973 годах. Это целое семейство из 15 разных моделей, каждая из которых имеет свои определенные цели.
Описание элементов нотации
Первично, если посмотреть на графическое изображение нотации IDEF0 – она очень проста, понятна и лаконична. Для моделирования используется в большей части всего два элемента:
• Функциональный блок – отображает функцию (действие или работу).
• Стрелки – отображают взаимодействие с внешним миром и между собой.
Таким образом, визуальное отображение процесса представляет собой классическое определение бизнес-процесса, которое звучит как «это совокупность взаимосвязанных или взаимодействующих видов деятельности, преобразующих входы в выходы с помощью управления и используя ресурсы» – рисунок 1.
Рисунок 1. Визуальное представление процесса
Четыре базиса нотации IDEF0:
- Использование контекстной диаграммы;
- Использование 5 типов стрелок;
- Поддержка декомпозиции;
- Доминирование.
Контекстная диаграмма
Основа функционального моделирования – это определение основной задачи, которая решается путем выполнения основного бизнес-процесса.
Самая верхняя диаграмма, на которой объект моделирования представлен единственным блоком с граничными стрелками – это диаграмма, которая называется A-0 (А минус ноль). Этот функциональный блок – так называемый «черный ящик», так как он дает самое первичное представление об описываемой предметной области или системе в целом. Он описывает функцию верхнего уровня, ее входы, выходы, управление и механизмы, вместе с формулировками цели модели и точки зрения, с которой строится модель. Сама контекстная диаграмма – это диаграмма, имеющая узловой номер A-n (n ≥ 0), которая представляет контекст модели.
ВАЖНО! При задании имени функции нужно придерживаться следующего правила: имя должно быть активным глаголом или глагольным оборотом, описывающим данную функцию.
Дополнительно на контекстной диаграмме А-0 отображаются ключевые характеристики всей модели:
- Цель – четкая конкретная формулировка назначения или причины создания модели.
- Точка зрения – тот, от имени кого строится модель, так как модель зависима всегда от ее автора и фокуса его внимания.
- Тип модели – это указание на то, какая информация отображена на схемах: AS IS («Как есть») или TO BE («Как будет»).
Итак, рассмотрим наш практический пример. Возьмем процесс приготовления котлет по-одесски. Тогда основной процесс можно сформулировать следующим образом: «Приготовить котлеты по-одесски». Контекстную диаграмму верхнего уровня можно представить следующим образом – рисунок 2.
Название функционального блока А-0 задано: «Приготовить котлеты по-одесски», а также определены цель, точка зрения и тип модели.
Рисунок 2. Контекстная диаграмма
Основная цель контекстной диаграммы – выявление первостепенной, главной задачи, которую решает исполнение главного бизнес-процесса. Как уже говорилось, методология IDEF0 – это методология построения процессов верхнего уровня, самый укрупненный взгляд на все бизнес-процессы. Контекстная диаграмма, особенно диаграмма самого верхнего уровня А-0 не дает полного представления о процессе (функции). Построение контекстной диаграммы А-0 показывает: какую бизнес-цель мы преследуем, какие ресурсы используются при этом, что будет получено на выходе исполнения процесса, кто будет задействован при исполнении процесса, чем будет регламентироваться процесс. Диаграмма A-0 устанавливает область моделирования и ее границу. Стрелки на этой диаграмме отображают связи объекта моделирования с окружающей средой.
Стрелки
После определения основной задачи (функции), характеризующей бизнес-процесс, следует определять: какие данные у нас есть для выполнения процесса, что необходимо получить на выходе процесса. Это поможет определить четкие требования к процессу.
Определяются следующие типы стрелок (Arrows):
- Ввод (Input) процесса, операции, действия или функции.
Отображает значение сырья, комплектующих, расходных материалов, материальных, финансовых, энергетических, информационных ресурсов, документов на бумажном (электронном носителе) и так далее, т.е. то, что будет преобразовано в ходе выполнения процесса.
Всегда присоединяется к функциональному блоку слева.
- Вывод (Output) процесса, операции, действия или функции.
Отображает преобразованную информацию (документ) или товарно-материальные ценности (в т.ч. отходы производства), а также отчетность, продукцию или услугу, любые преобразованные данные.
Всегда выходит из функционального блока справа.
- Механизм (Mechanism) процесса, операции, действия или функции.
Отображает то, что преобразовывает вход в выход: сотрудники, техника, оборудование, программное обеспечение, средства связи, то есть все то, что участвует в процессе. Считается, что за один цикл процесса не происходит изменения механизма.
Всегда присоединяется к функциональному блоку снизу, но в отличии, от стрелки «Вызов», она всегда направлена в функциональный блок из вне.
- Контроль (Control) процесса, операции, действия или функции.
Отображает контролирующее (управляющее) воздействие внешней среды на процесс в виде международных и/или отечественных стандартов, внутренних стандартов фирм, должностных (рабочих) инструкции, технической документации, законодательных актов различных уровней, регламентов, планов работ и других документов. Определяет, как должен выполняться бизнес-процесс, как должно происходить преобразование входа в выход.
Всегда присоединяется к функциональному блоку сверху.
- Вызов (Call) процесса, операции, действия или функции.
Обозначает обращение из одного функционального блока к другому функциональному блоку и обеспечивает связь между моделями или между разными частями одной модели.
Всегда присоединяется к функциональному блоку снизу, но в отличии, от стрелки «Механизм», она направлена из функционального блока и помечается ссылкой на вызываемый функциональный блок.
ВАЖНО! Ввод – это ресурсы, которые переносят свою стоимость в выводы полностью, то есть расходуются на создание результата полностью, а механизмы – это ресурсы, которые переносят свою стоимость только частично (например, оборудование – через амортизацию, а люди – через заработную плату).
ВАЖНО! У каждого функционального блока должна быть как минимум одна стрелка с каждой стороны (так как не может быть работы без ресурсов или результатов, а также неполной будет инструкция без исполнителя или инструкции).
Также очень часто можно встретить следующие определения: не «Ввод», а «Вход», не «Вывод», а «Выход», не «Контроль», а «Управление». И порой пятая стрелка «Вызов» может быть вообще упущена из виду. Это может быть связано, как с особенностью перевода первичного стандарта, так и с некоторым недопониманием работы с нотацией.
ВАЖНО! Данная особенность может сильно повлиять на построение диаграммы, поэтому нужно следить за терминологией и определением данных при построении модели.
Таким образом, можно сказать, что функциональный блок IDEF0 показывает преобразование входа в выход с помощью механизмов с учетом управляющих воздействий.
Но вернемся к приготовлению котлет по-одесски.
Итог выполнения процесса (Вывод) – это вкусные котлеты по-одесски.
На вход (Ввод) поступают необходимые для приготовления ингредиенты: мясо трех сортов (говядина, телятина, свинина), белая булка, молоко, лук, сахар, соль, перец, панировочные сухари. Предполагается, что данные продукты уже куплены в нужном количестве и качестве.
Исполнение процесса (Контроль) регламентируется с помощью Книги о вкусной и здоровой пище (нельзя готовить блюдо не зная рецепт), а также ценными и мудрыми советами Сары Львовны, того, кто знает всю технологию приготовления вкусных котлет («Савва, ну кто так лук чистит?!»).
А исполнитель процесса (Механизм), как и положено в большой семье, во-первых, Савва Игнатьевич, глава семейства, тот кто вызвался приготовить котлеты (но не факт, что так будет), и, во-вторых, многочисленные родственники на вспомогательных действиях (а порой и просто советами).
Если обратиться к построению бизнес-процессов в данной нотации IDEF0 в реальной жизни, т.е. на проектах при описании процессов реальных фирм, то данные будет собирать и обрабатывать бизнес-аналитик. Ему отводиться роль по выявлению входных и выходных данных, установление механизмов и способов управления. Полученные данные будут сведены им в первую контекстную диаграмму А-0.
Так как первая контекстная диаграмма не дает полного видения всех подпроцессов первичного процесса, поэтому проводится ее декомпозиция, т.е. получение более детального описания процесса.
Так же и в нашем примере, схема на рисунке 2 не дает нам пока полного представления о процессе приготовления котлет по-одесски. Поэтому мы будем делать декомпозицию исходного процесса.
Декомпозиция
Нотация IDEF0 поддерживает последовательную декомпозицию процесса до требуемого уровня детализации. Дочерняя диаграмма, создаваемая при декомпозиции, охватывает ту же область, что и родительский процесс, но описывает ее более подробно. Согласно методологии IDEF0 при декомпозиции стрелки родительского процесса переносятся на дочернюю диаграмму в виде граничных стрелок.
ВАЖНО! На обычной (не контекстной) диаграмме граничные стрелки представляют входы, управления, выходы или механизмы родительского блока диаграммы. Источник или потребителя граничных стрелок можно обнаружить, только изучая родительскую диаграмму. Все граничные стрелки на дочерней диаграмме должны соответствовать стрелкам родительского блока.
При декомпозиции большая задача разбивается на более детальные подзадачи. Которые могут проходить как параллельно, так и последовательно. Количество декомпозиций зависит от необходимого уровня детализаций.
ВАЖНО! В русскоязычной литературе для IDEF0 можно встретить разные рекомендации по оптимальному количеству блоков на диаграмме. Однако, в стандарте четко указано, что что диаграмма может содержать от 3 до 6 блоков.
Вернемся к нашему примеру. В случае приготовления котлет по-одесски декомпозицию можно провести, как показано на рисунке 3.
Рисунок 3. Диаграмма декомпозиции первого уровня
На схеме видно, что для того, чтобы получить требуемое блюдо, нужно выполнить определенную последовательность операций:
1) Подготовить ингредиенты;
2) Сформировать котлеты;
3) Обжарить котлеты;
4) Подать блюдо на стол.
Однако функциональный блок А1 пока представляется в виде «четного ящика», так как не понятно, что значит «Подготовить ингредиенты». А это означает, что можно провести его декомпозицию. Пример представлена на рисунке 4.
Рисунок 4. Диаграмма декомпозиции второго уровня
Первых два процесса («Обжарить лук с сахаром» и «Замочить белую булку в молоке») можно выполнять одновременно, а вот начать третий процесс («Перемолоть все в мясорубке») без получения выходных результатов от первого и второго процессов уже нельзя.
Доминирование
И заключительная важная составляющая нотации, влияющая на восприятие и легкость в чтении всей диаграммы, называется доминирование. Блоки модели IDEF0 на диаграммах декомпозиции должны располагаться по диагонали – от левого верхнего угла диаграммы до правого нижнего в порядке присвоенных номеров. Блоки на диаграмме, расположенные вверху слева, «доминируют» над блоками, расположенными внизу справа. Т.е. это можно сравнить с привычным нам чтением – мы читаем слева на право и сверху вниз, аналогично происходит и чтение диаграмм в нотации IDEF0. Под «доминированием» также понимается влияние, которое блок оказывает на другие блоки диаграммы. Расположение блоков на листе диаграммы отражает авторское восприятие ситуации.
ВАЖНО! Нумерация блоков происходит согласно принципу «доминирования» – по степени важности или в хронологическом порядке, согласно их расположению.
Итого
В чем трудность применения нотации IDEF0? Или все хорошо?
Начнем с хороших качеств применения данной методологии:
1. С нее хорошо начать изучать нотации и методологии построения бизнес-процессов – она проста и легка в восприятии и не требует каких-либо специфических навыков.
2. Больше подходит для описания технологических процессов, где нет факторов внешней среды, способных влиять на процесс.
Ну и немного недостатков:
1. Она не отражает реакцию участников процесса на события внешней среды.
2. Невозможно оценить риски, связанные с изменениями во внешней среде, и невозможно смоделировать запасные варианты.
3. В IDEF0 рассматриваются только логические отношения между работами, временная последовательность не учитывается.
И еще интересное наблюдение, вероятность того, что два бизнес-аналитика создадут две одинаковых модели описания бизнес-процессов очень мала. Даже если этот процесс будет примитивно прост. Поэтому считать, что кто-то неправильно отобразил данные – не следует. Однако, это не исключает факта того, что необходимо придерживаться правил описания моделей. Любая бизнес-модель – это также и отражение опыта и знаний бизнес-аналитика, его видение ситуации и понимания предметной области.
Ну и на закуску
Предлагаю вам посмотреть на варианты декомпозиций рассматриваемого выше процесса «Приготовить котлеты по-одесски» и найти в них типичные ошибки построения модели.
Рисунок 5
Рисунок 6
