С чего начинается описание бизнес процесса в методике idef0

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

Методология IDEF0 берет своё начало в 60-х годах. Разработана известным американским ученым Дуглас России в США. В настоящее время методология IDEF0 является фундаментальной, занимает ведущую позицию. Рассмотрим более подробно ее назначение и особенности.

Несколько слов о преимуществах графики

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

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

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

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

Что такое нотация описания бизнес-процессов

Нотация описание бизнес-процессов — графическое исполнение бизнес-процесса, его описание с помощью графических элементов для наиболее простого восприятия.

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

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

По аналогии с языками программирования, нотации называют языками моделирования бизнес-процессов, являются общепризнанными и понятными для всех.
Сегодня в мире наиболее популярны 3 нотации:

• IDEF0;
• EPC;
• BPMN.

Наиболее популярная нотация моделирования бизнес-процессов, основанная на методологии структурного анализа SADT.

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

Несмотря на то, что нотация разработана более 50 лет назад, она не сколько не устарела и в настоящее время широко используется. Следует отметить, что методология получила свою популярность практически сразу после ее создания. Аналитики стали использовать ее во всех сферах экономики, и уже очень скоро нотация заработала мировое признание.

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

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

Назначение и состав методологии

Методология IDEF0 получила свою популярность и широкое применение благодаря простому графическому исполнению и простоте восприятия.

Методология IDEF0 описания бизнес-процессов заключается в описании действий с помощью диаграмм.

Описание бизнеса-процессов происходит быстро и очень понятно. Главные составляющие — диаграммы.

Выделяют четыре типа диаграмм:

• контекстная;
• диаграмма декомпозиции;
• диаграмма дерева узлов;
• диаграмма только для экспозиции.

Контекстная диаграмма — ее принято считать главной диаграммой, поскольку нацелена на изображение основной функции и ее взаимодействие с внешней средой.

Диаграммами декомпозиции — считаются второстепенными или дочерними. Описывают составные части основной функции.

Диаграмма дерева узлов — выражает зависимость функций между собой.

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

Элементы графической нотации

Как уже говорилось, свою популярность и универсальность в использовании, методология IDEF0 получила благодаря простому описанию бизнес-процессов, с помощью графических объектов.

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

Прямоугольник обозначает функцию, действие людей, которое имеет свою цель и конечный результат. Имя функции как правило это глагол, обозначающий то или иное действие. Виды функций:

• Деятельность;
• Процесс;
• Операция;
• Действие.

Стрелочка в диаграмме обозначает взаимосвязь функций между собой и внешним миром. Подразделяются на:

• Вход;
• Управление;
• Механизм;
• Выход;
• Вызов.

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

Типы связей между функциями

В бизнес-процессе каждая функция должна отвечать за один определенный процесс. Поэтому важно перед описанием бизнес-процесса верно разбить «цепь» на отдельные действия. Далее, когда определено количество действий, определяется взаимосвязь между функциями. В этом случае в строении бизнес-процесса важную роль играет верная последовательность функций.

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

Выделяют несколько типов связей:

• Иерархическая
• Регламентирующая связь
• Функциональная
• Потребительская
• Логическая
• Коллегиальная
• Ресурсная
• Информационная
• Временная
• Случайная.

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

Плюсы и минусы

Преимущества IDEF0:

• Главным преимуществом методологии IDEF0 является полнота описания бизнес-процесса. Описание с помощью диаграмм (главных и второстепенных) позволяется точно описать все процессы, и указать множество взаимосвязей между ними и с внешней средой;
• Жесткие требования к изложению информации. Это приводит к стандартизации бизнес-процессов.

Недостатки IDEF0:

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

Правила и рекомендации построения диаграмм

Создавая рабочий бизнес-процесс, который действительно будет всем понятен и будет эффективным, необходимо помнить, что он должен соответствовать следующим критериям:

• Законченность — бизнес-процесс должен иметь четкую цель, окончательный продукт, на создание которого направлены действия.
• Лаконичность — принимая во внимание, что бизнес-процесс имеет большую аудиторию (от руководства компанией до рядовых сотрудников), важно, чтобы процесс был описан наиболее лаконично.
• Подбор участников бизнес-процесса — важно четко определить всех лиц, привлеченных к реализации проекта, и закрепить за каждым отдельные задачи. При этом не стоит перечислять участников в сносках, необходимо лаконично вписать их в общую схему для простоты восприятия.
• Понятное потребителю описание — любой человек, прочитав описание бизнес-процесса, должен понять его без дополнительных пояснений.

Облегчить чтение модели возможно, если придерживаться определенны правил создания диаграмм IDEF0. Вот некоторые из них:

• Первостепенно определить для себя цель бизнес-процесса. Необходимо определить тип формируемой модели, а также позицию, с точки зрения которой будет строиться модель.
• При разработке моделей следует избегать изначальной «привязки» функций исследуемой системы к существующей организационной структуре моделируемого объекта (предприятия, фирмы).
• На контекстной диаграмме отображается один блок, показывающий назначение системы. Для него рекомендуется отображать по 2–4 стрелки, входящие и выходящие с каждой стороны.
• Количество блоков на диаграммах декомпозиции рекомендуется в пределах 3–6.
• Блоки на диаграмме декомпозиции следует располагать слева направо и сверху вниз.
• Отсутствие у функции одновременно стрелок управления и входа не допускается.
• Обеспечить каждому блоку свой вход.
• Постараться как можно меньше допустить поворотов в диаграмме и петель.
• Используйте обратные дуги для изображения обратных связей.
• Поименуйте каждый элемент диаграммы.
• Использовать туннелирование стрелок.
• Объединить стрелки, проходящие параллельно и дать им единое имя.
• Нумерация блоков.

Типичные ошибки

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

Рассмотрим типичные ошибки:

1. Использование различных цветов — не стоит пытать выделить отдельные элементы цветами, чтобы повысить наглядность. Все элементы одинаково важны.
2. Слишком большое количество блоков — нельзя изобразить все нюансы процесса на одном листе. Для конкретизации деятельности необходимо применить детализацию каждого блока.
3. Нарушение структуры при внесении корректировок — при внесении каких-либо изменений, например смены точки зрения, следите за тем, чтобы не возникло путаницы или процессов без входящих, исходящих и других важных элементов.
4. Правила названия управляющих элементов и блоков — называйте стрелки именами, а блоки глаголами.

Программное обеспечение для построения диаграмм IDEF0

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

К сегодняшнему дню создано не мало программ для создания диаграмм IDEF0. Вот некоторые из них:

• ERWin 3.5.2;
• Design/ IDEF;
• Dia;
• IDEF0/EMTool;
• BPwin.

Пример создания функциональной модели IDEF0

Рассмотрим процесс написания статьи для наглядного описания создания функциональной модели IDEF0

Основной блок называется «Написать статью».

Взаимодействие с внешней средой обозначены на схеме входящими стрелками – «Знания в области написания статьи», «Опыт», «Информация из сторонних источников». Основы, которые необходимы для описания.

Управляющие в данном случае – это «План публикации», «Требования издателя», «Правила русского языка».

А в роли «Механизмов» выступают автор, копирайтер, корректор и программное обеспечение.

Таким образом, созданы основные параметры процесса, его вход, выход, а также все необходимое для успешного проведения процесса. Но это – только основные рамки процесса. Так описывается общая схема работы компании в целом.

На самом деле, процесс создания статьи, как и любой бизнес-процесс можно и нужно детализировать.

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

Метод моделирования бизнес-процесса IDEF0 имеет свои плюсы и минусы. Вместе с тем, надо отметить, что несмотря на длительность использования данного метода, своей актуальности он теряет. До настоящего времени является мощнейшим, универсальным методом создания функциональных моделей.



IDEF0 (Integrated Definition) — язык проектирования функциональных моделей, включает как сам язык моделирования, так и методологию для построения и интерпретации моделей. IDEF0 является одной из первых нотаций для моделирования бизнес-процессов, которая возникла в американской аэрокосмической промышленности в 1970-ых годах.

IDEF0 — основные характеристики

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

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

Основной принцип моделирования в нотации IDEF0 указывает, что между функциями, которые входят в различные подсистемы, должно быть как можно меньшей связей. На одном уровне должно быть не меньше 5 и не больше 3 функций.

Диаграммы IDEF0 читают сверху вниз и слева направо. Все базовые элементы основаны на простых символах:

• прямоугольники изображают функции или процессы;
• стрелки обозначают как функции взаимосвязаны через физические и информационные потоки.

Семантика языка описывает именно функции системы — что должно быть сделано для преобразования входящего потока, поэтому названия в прямоугольниках должны быть заданы глаголом или отглагольным существительным. Каждая сторона прямоугольника имеет свое значение и однозначно связана с одним из 4 видов стрелок:

Существует также стрелка вызова, которая указывает на функцию, выполняемую за пределами указанного блока.

Другие правила синтаксиса

• блок должен полностью вмещать название;

• можно использовать только блоки прямоугольной формы;

• блоки должны быть нарисованы сплошными линиями;

• изгиб стрелок должен составлять 90°;

• сегменты стрелок должны быть отрисованы сплошными линиями;

• нельзя рисовать стрелки по диагонали;

• стрелки не должны пересекать границы блока;

• стрелки нельзя присоединять к углам блока;

• стрелки должны быть подписаны, для подписи используются только имена существительные.

Диаграммы должны давать исчерпывающие представление об объекте, его функциях и связях.

Виды диаграмм

• контекстная диаграмма описывает основное назначение системы, а также ее взаимодействие с внешней средой. Может быть только одна контекстная диаграмма, которая обозначается символами A0;
• диаграмма декомпозиции детализирует отдельные элементы системы и связи между ними. Процедуру декомпозиции можно повторять до тех пор, пока не будет достигнут желаемый уровень детализации модели;
• диаграмма дерева узлов показывает иерархические зависимости между отдельными функциями;
• диаграмма только для композиции показывают систему с определенного ракурса, например, со стороны руководителей организации.

Иерархия типов функций

• деятельность — совокупность всех процессов организации;
• бизнес-процесс — совокупность логически связанных операций;
• операция — совокупность последовательных или параллельных действий внутри определенного потока;
• действие— преобразование свойств какого-либо объекта.

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

Основные характеристики IDF0

• высокий уровень детализации любых типов процессов;

• последовательность и относительная простота языковых средств, которые обеспечивают полноту использования и точность интерпретаций;

• упор на иерархическое отображение элементов;

• может быть воссоздана на программном уровне.

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

Для чего используется

Нотация универсальна и позволяет детально описывать достаточно сложные системы и процессы на любом уровне.

• широко применяется в США при автоматизации машинного производства и до сих пор является частью стандарта FIPS (Federal Information Processing Standard);

• применяется для имплементации методологий непрерывного улучшения, таких как Strategic Justification of Integrated Enterprise Technologies (SJET) и Perform Continuous Enterprise Improvement (PCEI);

• в литературе можно найти пример описания процесса разработки стратегии на языке IDEF0.

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

Преимущества

• высокая степень детализации на всех уровнях иерархии;

• возможность отобразить взаимосвязи между различными уровнями системы;

• популярность среди аналитиков;

• большое количество документации на английском языке;

• подходит для презентаций руководству;

• аккуратно спроектированные схемы легко читаются.

Недостатки

• крупные производители софта постепенно отказываются от поддержки данной нотации;

• диаграммы могут выглядеть перегруженными и визуально непривлекательными;

• низкий потенциал для автоматизации функциональных моделей;

• требует определенных навыков для адекватного проектирования диаграмм;

В целом можно сказать, что в области проектирования бизнес-процессов в информационных системах на смену IDEF0 пришли другие нотации, прежде всего BPMN.

BPMN vs IDEF0

Хотя IDEF0 иногда используют для моделирования бизнес-процессов, эта нотация задумывалась как средство моделирования взаимодействия бизнес-функций, не обязательно в процессном контексте. Стрелка в BPMN показывает точную последовательность выполнения шагов процесса, а в IDEF0 стрелки входов-выходов не обязаны отображать эту последовательность. Кроме того, BPMN содержит XML-описание элементов, что значительно упрощает имплементацию на программном уровне. В отличие от IDEF0, BPMN разрабатывалась с прицелом на автоматизацию бизнес-процессов, поэтому многие элементы нотации показывают именно машинные способы передачи и обработки данных. Нотация нашла широкое применение в BPMS, ERP, CRM, SRM и других информационных системах.

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

Comindware Business Application Platform исправляет этот недостаток BPMN за счет конструктора для проектирования исполняемой архитектуры предприятия. Конструктор визуализирует связи между бизнес-процессами, ресурсами и способностями предприятия, не уступая по точности IDEF0. Инструмент можно использовать для создания иерархических моделей с несколькими уровнями вложений.

IDEF0. Знакомство с нотацией и пример использования +12

Одна картинка стоит тысячи слов

Народная мудрость

Зачастую в моей работе возникает необходимость не просто изучить и решить определенную проблему, но выявить ее местонахождение в общей модели работы компании. Мало понимать, что определенное подразделение работает неправильно, важно понимать, каким образом оно взаимодействует с другими. Иначе невозможно выявить все существующие проблемы и выбрать оптимальный метод решения поставленной задачи. А для этого требуется изучить работу компании и составить ее функциональную модель.

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

Несколько слов о преимуществах графики

Как известно, функциональные модели IDEF0 — это всегда графические схемы. У них есть свои особенности и правила составления. Об этом мы поговорим чуть-чуть позже. А сейчас я хотел бы привести пару примеров эффективности графики. Почему я делаю на этом акцент? Скорей всего, после моего утверждения о необходимости функциональной модели работы компании, очень многие подумали, что это все необязательно, можно и на словах пояснить как работает та или иная функция в компании. Вот об этом я и хочу поговорить.

И для начала сделаем небольшой экскурс в историю. Вернемся в далекий 1877 год, в период Русско-Турецкой войны. Именно тогда полиграфист Сытин впервые применил графику при описании военных действий. Сейчас для нас все это привычно, при описании любого сражения у каждого перед глазами возникают карты со стрелками, которые наглядно показывают ход сражения. А в те времена военные действия описывались словами. Для каждого боя — много-много слов. И понять в итоге, что же происходит, было очень сложно.

А потому идея Сытина была поистине революционной — он начал печатать литографические копии карт с обозначением укреплений и расположений воинских частей. Назывались эти карты “Для читателей газет. Пособие”. Идея оказалась настолько актуальной, что первый же тираж “Пособий” разошелся мгновенно. И потом такие приложения были очень востребованы. Причина очевидна. Графика помогала понять то, что при помощи одних слов разобрать было практически невозможно.

Аналогичный пример беспомощности словесных описаний я могу привести также из своей практики. Один из моих заказчиков очень просил взяться за внедрение ERM-системы для его компании. На вопрос, есть ли у них какое-то техническое задание, я получил ответ: “Да, есть. Но в нем 400 страниц”. При этом клиент очень жаловался, что мои коллеги, к которым он обращался ранее, либо отказывались от проекта вообще, либо называли явно завышенные цены. После того, как я увидел, что в техническом задании действительно 400 страниц, и состоит оно исключительно из текстового описания, я понял причины поведения разработчиков. Прочитать такой объем текста, вникнуть в него, разобраться во всех нюансах только для того, чтобы понять задачу и назвать цену — это и правда очень сложно.

Этому клиенту я предложил альтернативный вариант — описать все, что можно, графически в виде нотаций. Показал ему примеры моделирования. В итоге они сейчас переосмысливают свои пожелания и оформление технического задания.

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

Почему это важно для моей работы

Моя работа всегда связана с внесением изменений в существующую систему. А для того, чтобы внести изменения и получить нужный результат, нужно изучить то, что существует уже сейчас. И не важно, что именно мы делаем – настраиваем или устанавливаем с нуля CRM-систему, создаем эффективную ERP-систему, занимаемся интеграцией различных систем для повышения автоматизации работы в целом. В любом случае, для начала, необходимо получить представление о существующей схеме работы, и только после этого можно предлагать какие-то изменения и продумывать варианты решения поставленной задачи.

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

Такие отчеты об обследовании работы получаются объемные, занимают не одну страницу, что с одной стороны, необходимо, а с другой – усложняет восприятие. Вначале я, как и многие, думал, что объемные отчеты — это хорошо, ведь человек платит за работу и нужно ему предоставить максимум подробной информации.

> Пример одного из моих отчетов в текстовом виде

На самом деле, важно не предоставить объем, а максимально быстро и полно донести суть. Большие объемы текста требуют времени, которого у бизнесменов чаще всего очень мало. А графика позволяет сократить объем моего предложения и наглядно, в понятной форме показать решение. В результате мои предложения значительно сократились, в них появилась графика, а решения о начале сотрудничества стали приниматься быстрее.

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

Но для начала, давайте разберемся с основными понятиями, что такое нотации, зачем они нужны, что такое IDEF0, в чем особенности и преимущества этого метода.

Что такое нотация описания бизнес-процессов

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

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

В общем, нотации можно назвать языком программирования при бизнес-анализе.

Что такое IDEF0?

IDEF0 — методология функционального моделирования (англ. function modeling) и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является ее акцент на соподчиненность объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временна?я последовательность (поток работ).

Википедия

Стандарт IDEF0 был разработан в 1981 году в США департаментом Военно-воздушных сил для автоматизации промышленных предприятий. В процессе разработки программного обеспечения разработчики столкнулись с необходимостью разработки новых методов анализа бизнес-процессов. В результате появилась методология функционального моделирования IDEF0, в которой для анализа применяются специальные нотации IDEF0.

Функциональная модель компании

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

Стрелки могут быть:

• Входящие – вводные, которые ставят определенную задачу.
• Исходящие – выводящие результат деятельности.
• Управляющие (сверху вниз) – механизмы управления (положения, инструкции и пр).
• Механизмы (снизу вверх) – что используется для того, чтобы произвести необходимую работу.

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

Стрелки подписываются при помощи имен существительных (опыт, план, правила), а блоки – при помощи глаголов, т.е. в них описываются действия, которые производятся (создать товар, заключить договор, произвести отгрузку).

IDEF0 – это очень простой и одновременно наглядный язык описания бизнес-процессов. С помощью этого стандарта возможна передача информации между разработчиками, консультантами и пользователями. Стандарт очень тщательно разрабатывался, он удобен для проектирования, универсален. Для работы с ним существует множество инструментов, например, VISIO, BPWIN, ERWIN, Bussines studio и т.д.

Кроме того, использование для создания бизнес-моделей IDEF0 — это не только удобно, это еще и правильно. Этот инструмент был разработан для бизнес-аналитики, он прошел длительную и тщательную отладку и шлифовку. А потому при помощи IDEF0 создать функциональную модель без ошибок намного проще, чем без применения этого стандарта.

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

Пример создания функциональной модели IDEF0

Для того чтобы понять, как работать с функциональным моделированием, я приведу пример процесса написания статьи.

Основной блок – «Написать статью».

Пример описания функциональной модели верхнего уровня

Входящие стрелки – «Опыт», «Информация из сторонних источников». Это те вводные, которые необходимы для начала работы.

Управляющие для написания статьи – это «План публикации», «Требования издателя», «Правила русского языка».

А в роли «Механизмов» выступают автор, копирайтер, корректор и программное обеспечение. В данном случае автор создает аудиоматериал, в котором собирает все мысли и идеи, которые должны быть отражены в статье. Копирайтер – это человек, который создает на основе этого материала, руководствуясь требованиями издателя, планом публикации и правилами русского языка, готовый текст статьи. Корректор проверяет материал на ошибки. А программное обеспечение – это те инструменты, которые используют в работе все участники процесса.

Таким образом, я задал основные параметры процесса, его вход, выход, а также все необходимое для успешного проведения процесса. Но это – только основные рамки процесса. Так описывается общая схема работы компании в целом.

На самом деле, процесс создания статьи, как и любой бизнес-процесс можно и нужно детализировать. Для этого я декомпозирую общий блок «написать статью» на связанные между собой элементы.

В нашем случае работа делится на 4 основных этапа:

1. Подготовить аудио.
2. Подготовить текст
3. Подготовить текст к публикации.
4. Разместить статью в издании.

Пример описания функциональной модели бизнес процесса второго уровня

На схеме наглядно видно, на каком этапе какие управляющие элементы и какие механизмы задействованы.

Так, автор при создании аудио использует свои знания и опыт, при этом руководствуется планом публикации и требованиями издателя. Копирайтер получает на входе аудиозапись, из которой, руководствуясь правилами русского языка, создает текст. Корректор получает текст и проверяет его, также руководствуясь правилами русского языка. Для размещения статьи в издании необходимо специальное программное обеспечение.

При создании функциональной модели ключевыми параметрами являются цель и точка зрения. Исходя из них, моделирование одних и тех же процессов может выглядеть несколько по-разному. Например, в моем случае целью является «рассказать о процессе написания статьи». А точка зрения копирайтера – это «написание и публикация статьи с точки зрения руководителя процесса».

Так, если бы тот же процесс был описан с точки зрения копирайтера, то входящими были бы опыт и аудиофайл от автора. При этом в таком случае под Опытом подразумевался бы опыт копирайтера, но не руководителя или автора. А потому первое, что нужно определить при создании модели бизнес-процесса – это выбрать точку зрения и четко сформулировать цель.

Такое моделирование не только наглядно, но и очень удобно для принятия эффективных управленческих решений. Например, в описанном выше бизнес-процессе есть два отдельных специалиста — копирайтер и корректор. Если я поставлю задачу оптимизировать финансирование проекта, то я благодаря схеме сразу увижу, где это и как можно сделать. Так, к копирайтер и корректор пользуются примерно одинаковыми правилами, но копирайтер получает аудио, а выдает результат в виде текста, корректор же и принимает, и отдает текст. А потому при необходимости я могу, скажем, за половину стоимости обязанности корректора предложить копирайтеру. Так я сэкономлю средства и время на взаимодействие разных специалистов. Конечно, я понимаю все заслуги корректоров и почему лучше работать с отдельным специалистам. Но напоминаю — у меня стоит задача: оптимизация затрат.

Без такого наглядного инструмента было бы сложнее определить, какие из блоков можно удалить и, таким образом, оптимизировать работу.

Как создавать нотации IDEF0

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

Я лично считаю, что на первом этапе нет ничего лучше, чем обычная бумага, простой карандаш и ластик, чтобы вносить корректировки в случае ошибок.

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

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

Вторая нотация – «как должно быть». Она создается на основе первой и тех изменений, которые вы предлагаете внести в структуру работы для оптимизации и автоматизации работы компании в рамках выполнения поставленной задачи.

Требования стандарта IDEF0

Базовые требования стандарта IDEF0, в принципе, я описал выше и показал на примере.

1. В левом верхнем углу всегда – главный элемент.
2. Все элементы должны иметь входящие и исходящие стрелки, так как для выполнения необходимо что-то получить на входе (заказ, поставленную задачу), а после обработки на выходе необходимо передать готовый продукт. Входящие стрелки всегда слева, исходящие – справа.
3. Сверху – управляющие элементы, снизу – механизмы, необходимые для выполнения процесса.
4. Если на одном листе (экране) располагается несколько блоков, каждый последующий располагается справа и ниже предыдущего.
5. Необходимо стремиться создавать схемы таким образом, чтобы пересечение стрелок было сведено к необходимому минимуму.

Стандарт IDEF0 включает в себя также общепринятые обозначения, правила, требования к блокам диаграмм, имеет собственную семантику. Подробно ознакомиться с ними можно в документе «Методология функционального моделирования IDEF0».

Типичные ошибки

Функциональное моделирование выполняют при помощи самых разных инструментов, в том числе, не предназначенных для моделирования. В последнем случае нет проверки на ошибки и ограничения стандарта. Желание повысить наглядность и отсутствие опыта при этом часто оканчиваются ошибками.

Использование различных цветов

Все элементы на диаграмме одинаково важны. При функциональном моделировании нет более или менее важных элементов. Исчезновение любого приведет к нарушению процесса и производственному браку.

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

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

Слишком большое количество блоков

При составлении модели часто стараются отобразить на одном листе все нюансы работы компании со всеми подробностями. В результате получается очень большое количество блоков с большим количеством управляющих стрелок. Читабельность при этом теряется.

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

Нарушение структуры при внесении корректировок

Внимательно следите за тем, чтобы не возникло путаницы или процессов без входящих, исходящих и других важных элементов. Например, если в приведенном выше примере, я посчитаю нужным сместить точку зрения на копирайтера, я удалю из схемы автора. И тогда управляющие элементы «опыт автора и сторонние источники», а также план публикации становятся ненужными. Ведь ими пользуется автор. Копирайтер работает с аудиофайлом. И если они останутся в общей схеме, то при детализации будут вести непонятно куда и вносить путаницу.

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

Правила названия управляющих элементов и блоков

Важно запомнить простое правило: управляющие стрелки называют именами существительными, блоки – глаголами. Так принято в стандарте IDEF0, и такой подход помогает избежать путаницы и ошибок.

Чаще всего ошибки допускают при названии блоков. Например, вместо «Создать статью» пишут «Создание статьи». Блоки в данном подходе – это действия, а потому они должны быть всегда глаголами.

Выгоды использования IDEF0

• Самая первая выгода очевидна – это наглядность. Вы сами начинаете понимать, как работает та или иная система, и можете также наглядно пояснить, где в этой системе «тонкие места» и как ваши решения помогут избавиться от них.
• Взаимопонимание и отсутствие разночтений. При обсуждении работы компании с использованием функциональной модели у вас имеются наглядные и понятные интуитивно блоки задач с управляющими элементами. Кроме того, функциональное моделирование предполагает создание в случае необходимости глоссария, в котором раскрываются условные обозначения и термины. В результате вы с клиентом, руководителем, другими сотрудниками при обсуждении проблемы говорите на одном языке.
• Простота и высокая скорость создания модели. Конечно, научиться моделированию не так просто, как кажется. Ведь схема — это, по сути, сверхплотная подача информации, что очень хорошо для понимания, но для реализации такой подачи требуется особый подход. Мозг аналитика выступает в данном случае как очень мощный пресс с одной стороны, и фильтр – с другой. Но с опытом этот процесс становится очень быстрым. В результате вы получаете инструмент, который поможет и самому разобраться, что же происходит в той или иной системе, и при помощи созданного в сжатые сроки наглядного пособия проиллюстрировать важные моменты коллегам или заказчикам.
• Дисциплина и отсутствие ошибок. Стандарт IDEF0 предполагает строгие рамки и правила. Такой подход дисциплинирует, а привычка действовать в рамках стандарта помогает избежать ошибок по невнимательности. Любые нарушения стандарта становятся сразу заметны.

В чем трудность применения IDEF0

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

При этом я считаю, что бизнес-аналитик — это не совсем профессия, бизнес-аналитикой занимается каждый руководитель бизнеса или разработчик каких-то систем, который анализирует бизнес и стремится выстроить наиболее эффективную систему. Именно для этих людей и для этих целей предназначен инструмент IDEF0.

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

IDEF0. Недостатки и преимущества

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

1. Стрелка входа всегда приходит в левую кромку активности.
2. Стрелка управления — в верхнюю кромку.
3. Стрелка механизма — нижняя кромка.
4. Стрелка механизма — правая кромка.

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

Правила построение диаграмм бизнес-процессов с применением методики IDEF0

При создании бизнес-процесса необходимо учитывать, что он должен соответствовать определенным критериями, чтобы он был более понятен и эффективен. К такими критериям относятся:

1. Лаконичность. Бизнес-процесс должен быть описан максимально лаконично, так как имеет большую аудиторию.
2. Законченность. У бизнес-процесса должна иметься четкая цель, конечный продукт, на создание которого направлены действия.
3. Подбор участников бизнес-процесса. При использовании IDEF0 должны четко определяться лица, которые привлекаются к реализации.
4. Понятное потребителю описание. Любой потребитель после ознакомления моделью должен ее понять без дополнительных объяснений.

Чтобы облегчить чтение модели бизнес-процесса, необходимо придерживаться определенных правил создания диаграмм IDEF0:

1. Нумерация блоков.
2. Определенность типа формируемой модели.
3. Объединение стрелок, которые проходят параллельно.
4. Избегание «привязки» системы к существующей организационной структуре моделируемого объекта.
5. Использование туннелирования стрелок.
6. Количество блоков от 3 до 6.
7. Именовать каждый элемент диаграммы.
8. Блоки должны располагаться слева направо и сверху вниз.
9. Использование обратных дуг для изображения обратных связей.
10. Отсутствие у стрелок входа и управления недопустимо.
11. Минимизировать количество поворотов стрелок.
12. Обеспечение входа для каждого блока.

Этапы построение диаграммы бизнес-процесса с использованием IDEF0

Процесс построения диаграммы бизнес-процесса выглядит следующим образом:

1. Построение функциональной модели. На данном этапе осуществляется сбор информации о процессах на объекте, построение и утверждение функциональной схемы.
2. Собирание стоимостей. На данном этапе осуществляется построение структурной схемы объекта, определение статей затрат и распределение данных статей по структурной схеме.
3. Перенос стоимостей на функциональную модель. На данном этапе осуществляется согласование структурной схемы и функциональной модели процессов, определяется стоимость функций.
4. Анализ результатов и выработка рекомендаций. На данном этапе проводится анализ ранее полученных результатов и формирование рекомендаций по совершенствованию процессов.
5. Локализация процессов. Для осуществления дальнейшего анализа необходимо локализовать процессы функциональной модели. Составляется перечень функций, которые связаны причинно-следственными отношениями. Такие функции располагаются на низшем уровне иерархии.
6. Составление глоссария механизмов и управлений. В данном документе должен содержаться полный перечень управлений и механизмов низшего уровня. В каждом глоссарии выделяются элементы, которые являются продукцией вспомогательных процессов.
7. Определение последовательности рассмотрения процессов. Данное определение осуществляется только в том случае, если одного или нескольких процессов применяется в качестве управления или механизма в других процессах.