В idef0 все что происходит в системе и ее элементах принято называть
Методология функционального моделирования IDEF0
IDEF0 на сегодняшний день является основным стандартом моделирования бизнес-процессов. Описание системы с помощью IDEF0 называется функциональной моделью. Модель описывает, что происходит в системе, как ею управляют, какие сущности она преобразует, какие средства использует для выполнения своих функций и что производит.
При построении модели должна быть поставлена цель моделирования,отвечающая на следующие вопросы:
· почему этот процесс должен быть смоделирован?
· что должна показывать модель?
· что может получить читатель?
Примеры определения цели: «идентифицировать и определить текущие проблемы, сделать возможным анализ потенциальных улучшений», «идентифицировать роли и ответственность служащих для написания должностных инструкций», «определить возможность автоматизации…», «регламентировать процесс…» и т.д.
Точка зрения также является одним из ключевых элементов при построении модели. Точку зрения можно представить как взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования.
Основной концептуальный принцип методологии IDEF – представление любой изучаемой системы в виде набора взаимодействующих и взаимосвязанных блоков, отображающих процессы, операции, действия, происходящие в изучаемой системе. В IDEF0 все, что происходит в системе и ее элементах, принято называть функциями. Каждой функции ставится в соответствие блок.
Функциональные блоки на диаграммах изображаются прямоугольниками, означающими поименованные процессы, функции, работы или операции, которые происходят в течение определенного времени и имеют распознаваемые результаты. Внутри каждого блока помещается его имя и номер. Имя блока должно быть активным глаголом, глагольным оборотом или отглагольным существительным, обозначающим действие.
Блоки в IDEF0 размещаются по степени важности, как ее понимает автор диаграммы. Этот относительный порядок называется доминированием. Доминирование понимается как влияние, которое один блок оказывает на другие блоки диаграммы. Наиболее доминирующий блок обычно размещается в верхнем левом углу диаграммы, а наименее доминирующий – в правом углу.
Интерфейсы, посредством которых блок взаимодействует с другими блоками или с внешней по отношению к моделируемой системе среде, представляются стрелками, входящими в блок или выходящими из него. Каждая сторона функционального блока имеет стандартное значение с точки зрения связи блок/стрелка. Стандартное расположение стрелок показано на рис.1.
Рис. 1. Контекст IDEF0.
Стрелки описывают взаимодействие блоков с внешним миром и между собой. Стрелки представляют собой некую информацию и именуются существительными или оборотами существительного.
В IDEF0 различают пять типов стрелок:
Рис. 2. Отношение «выход-вход».
Рис. 3. Отношение «выход-управление».
Рис. 4. Обратная связь по управлению
Рис. 5. Отношение обратной связи по входу
Рис. 6 Связь «выход-механизм».
В нотации IDEF0 описание системы (модель) организовано в виде иерархически упорядоченных и взаимосвязанных диаграмм. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма). Контекстная диаграмма включает только один блок, характеризующий всю совокупность моделируемых процессов, без подробностей.
Рис. 7 Пример контекстной диаграммы IDEF0.
Концепции IDEF0
Графическое и текстовое представление моделируемой деятельности. Графическая и текстовая нотация блочного моделирования, управляющие конфигурацией модели, в IDEF0-диаграммах показывает производственные операции — как блок, а взаимосвязи с операциями — как стрелки, входящие/покидающие блок. Наличие четко описанных нотаций обеспечивает корректность встроенных в иерархическую структуру модели диаграмм.
В IDEF0 все, что происходит в системе и ее элементах, принято называть функциями. Каждой функции ставится в соответствие блок. Для того чтобы представить реальные производственные операции, блоки могут быть интерпретированы как деятельность, связанная с другими блоками, с интерфейсными стрелками, определяющими, когда и как переключаются или управляются операции. Взаимодействие блоков друг с другом описываются посредством интерфейсных стрелок, выражающих «ограничения», которые в свою очередь определяют, когда и каким образом функции выполняются и управляются.
Компактность. Линейное дескриптивное описание характеристик в виде связного текста не всегда удобно для восприятия. Документация с описанием производственной архитектуры должна быть компактной для простого ориентирования в предмете. Двухмерная форма, описанная на языке диаграмм, достигает компактности без потери возможности выражения отношений, таких как интерфейсы и обратная связь. IDEF0-диаграммы позволяют предста-вить любую изучаемую и/или описываемую систему в виде обеспечивающей компактность информации иерархии взаимодействующих и взаимосвязанных блоков, отображающих процессы, операции, действия.
Обмен информацией. Существуют совокупность методов, правил и процедур, предназна-ченных для построения функциональной модели объекта какой-либо предметной области. Средства IDEF0 облегчают передачу информации от одного участника разработки модели (отдельного разработчика или рабочей группы) к другому. К числу таких средств относятся:
диаграммы базируются на простой графике, состоящей из блоков и стрелок, легко читаемы и понимаемы.
-метки на естественном языке для описания блоков и стрелок, а также глоссарий и со-проводительный текст для точного определения понятий элементов диаграммы;
— последовательная декомпозиция диаграмм модели, использование иерархии с главной функцией на верху модели, и дальнейшее разбитие на подфункции при углублении вниз;
— древовидные схемы иерархии диаграмм и блоков, обеспечивающие обозримость модели в целом и входящих в нее деталей;
— индексирование диаграмм и блоков, позволяющее однозначно обращаться к ним в ие-рархической структуре модели;
— ограничения (не более 6 блоков на диаграмму) введены для простого восприятия диаграмм;
-диаграммы сопровождаются текстом и глоссарием, для улучшения восприятия графического представления.
Создания прескриптивных моделей. Методология нацеливает аналитиков и заказчиков на создание описания правил функционирования предприятия, а также на определение особых требований в терминах исполняемых функций, требуемой информации и применяемых ресурсов.
Итеративный процесс создания модели на основе разделения (декомпозиции) функций, выполняемых системными аналитиками, обеспечивающий точное описание системы.
Функциональная декомпозиция — способ моделирования типовой ситуации, когда любое действие, операция, функция могут быть разбиты (декомпозированы) на более простые действия, операции, функции. Другими словами, сложный процесс может быть представлен в виде совокупности элементарных функций. Представляя функции графически, в виде блоков, можно как бы заглянуть внутрь блока и детально рассмотреть ее структуру и состав. Одной из наиболее важных особенностей методологии IDEF0 является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель.
Коммуникативность и ограничения сложности. При работе с IDEF0 диаграммами суще—ственным является максимальная доступность для понимания специалистами, а также их разборчивость и удобочитаемость. Суть принципа ограничения сложности состоит в том, что количество блоков на диаграмме должно быть не менее двух и не более шести. Практика показывает, что соблюдение этого принципа приводит к тому, что функциональные процессы, представленные в виде IDEF0 модели, хорошо структурированы, понятны и легко поддаются анализу.
Строгость, точность, формализм и однозначность. Разработка моделей IDEF0 требует соблюдения ряда строгих формальных правил, обеспечивающих преимущества методологии в отношении однозначности, точности и целостности сложных многоуровневых моделей. Выполнение правил стандарта IDEF0 требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика. Качество модели обеспечивается соблюдением следующих требований:
-все стадии и этапы разработки и корректировки модели должны строго, формально документироваться с тем, чтобы при ее эксплуатации не возникало вопросов, связанных с неполнотой или некорректностью документации;
— подробное описание на каждом уровне (3-6 блоков).
— ограниченный контекст (только то, что относится к делу и ничего лишнего; ничего не упущено).
— синтаксические правила построения диаграмм (блоки и стрелки) ;
— неповторяющиеся названия блоков и стрелок;
— переходы между диаграммами (дерево диаграмм) ;
— переход между объектами/данными (коды ICOM и туннельные переходы) ;
— разделение входа и управления (правила для определения роли данных или объекта) ;
— обязательное наличие управления (все блоки требуют как минимум одного управляющего входа) ;
— сегменты стрелок (разделение или соединение), метки для стрелок;
— требования к наименованию стрелок;
— назначение и точка зрения (все модели должны иметь назначение и точку зрения).
Методология. Пошаговые процедуры, обеспечивающие эффективные процессы разработки модели, ее просмотра, объединения и сбора данных. Разработка модели в IDEF0 представляет собой пошаговую процедуру, на каждом шаге которой разработчик предлагает вариант модели, который подвергают обсуждению, рецензированию и последующему ре-дактированию, после чего цикл повторяется. Такая организация работы способствует оп-тимальному использованию знаний системного аналитика, владеющего методологией и техникой IDEF0, и знаний специалистов — экспертов в предметной области, к которой отно-сится объект моделирования.
Контекстность. Моделирование делового процесса начинается с построения контекстной диаграммы. На этой диаграмме отображается только один блок — главная функция модели-руемой системы — это «миссия» системы, ее значение в окружающем мире. Расположение диаграммы на вершине модели, указывает на то, что она является обобщающей для рассматриваемой системы. Кроме того, контекстная диаграмма «фиксирует» границы моделируемой системы, определяя то, как моделируемая система взаимодействует со своим окружением. Диаграммы первого уровня представляют важнейшие подсистемы с их взаимосвязями, а диаграммы самого нижнего уровня представляют детализированные функции, с помощью которых работает система.
Разделения функций, выполняемых участниками проекта при разработке моделей: источники информации (эксперты), разработчики диаграмм и модели (аналитики), обмен письменной информацией (библиотекарь), рецензирование и утверждение модели (читатели), принятие и утверждение модели (комитет технического контроля).
Язык ссылок, адресованных к отдельным частям диаграммы, и правила их сокращений облегчающие оформление замечаний при рецензировании модели.
Язык функций моделей с графическим языком описания системы, позволяющие декларативно определять правила работы системы, что часто является особенно важным завершающим шагом в описании системы.
Отделение «организации» от «функций». Разделение организации от функции включена в назначение модели и определяется выбором функций и меток стрелок в процессе создания модели. При разработке моделей следует избегать изначальной «привязки» функций исследуемой системы к существующей организационной структуре моделируемого объекта (предприятия, фирмы). Это помогает избежать субъективной точки зрения, навязанной организацией и ее руководством. Организационная структура должна явиться результатом применения модели.
Рекомендации по реализации аналитических проектов. Сравнение результата моделирования с существующей структурой позволяет оценить адекватность модели и предложить решения, направленные на совершенствование этой структуры.
Практика показала, что IDEF0-методология является подходящим и эффективным средством:
моделирования технических требований к системе;
моделирования процессов в проектах реинжиниринга;
комплексного проектирования систем;
разработки систем управления издержками операций (процессов).
Методология IDEF0 объединяет диаграммы в модель через объекты системы. Такая схема требует согласования наименования и учета объектов системы с тем, чтобы две диаграммы могли рассматриваться, как взаимосвязанные между собой. В IDEF0 используется собственный графический язык, который представляет собой полное и выразительное средство, способное наглядно представлять широкий спектр деловых, производственных и других про-цессов и операций предприятия на любом уровне детализации. Язык:
обеспечивает точное и лаконичное описание моделируемых объектов, удобство исполь-зования и интерпретации этого описания;
облегчает взаимодействие и взаимопонимание системных аналитиков, разработчиков и персонала изучаемого объекта (фирмы, предприятия), т.е. служит средством «информа-ционного общения» большого числа специалистов и рабочих групп, занятых в одном проекте, в процессе обсуждения, рецензирования, критики и утверждения результатов;
позволяет визуализировать работу сложных систем, в том числе критически важных и тре-бующих особой осторожности и соблюдения специальных мер безопасности;
позволяет лаконично, однозначно и точно показать все элементы (блоки) системы и все отношения и связи между ними, выявить ошибочные, лишние или дублирующие связи и т.д.;
позволяет составлять документацию, описывающую систему, и обмениваться информацией о таких системах. Язык не использует многословные характеристики, изложенные в форме традиционных текстов;
прошел многолетнюю проверку и продемонстрировал работоспособность как в проектах ВВС США, так и в других проектах, выполнявшихся государственными и частными промышленными компаниями;
легок и прост в изучении и освоении;
может генерироваться рядом инструментальных средств машинной графики.
Перечисленные свойства языка предопределили выбор методологии IDEF0 в качестве базового средства анализа и синтеза производственно-технических и организационно-экономических систем, что нашло свое отражение в упомянутых федеральных стандартах США.
‹ IDEF0 — методология функционального моделирования
Вверх
IDEF0-стандарт ›
Основные положения IDEF0
Методология IDEF0 основана на следующих концептуальных положениях:
1. Модель – искусственный объект, представляющий собой отображение (образ) системы и ее компонентов.
Это положение можно объяснить такой схемой:
М моделирует А, если М отвечает на вопросы относительно А.
2. Блочное моделирование и его графическое представление.
Основной концептуальный принцип методологии IDEF – представление любой изучаемой системы в виде набора взаимодействующих и взаимосвязанных
блоков, отображающих процессы, операции, действия, происходящие в изучаемой системе. В IDEF0 все, что происходит в системе и ее элементах, принято называть функциями. Каждой функции ставится в соответствие блок. На IDEF0 –диаграмме, основном документе при анализе и проектировании систем, блок представляет собой прямоугольник. Интерфейсы, посредством которых блок взаимодействует с другими блоками или с внешней по отношению к моделируемой системе средой, представляются стрелками, входящими в блок или выходящими из
него. Входящие стрелки показывают, какие условия должны быть одновременно выполнены, чтобы функция, описываемая блоком, осуществилась.
3. Лаконичность и точность.
Документация, описывающая систему, должна быть точной и лаконичной. Многословные характеристики, изложенные в форме традиционных текстов, неудовлетворительны. Графический язык позволяет лаконично, однозначно и точно показать все элементы (блоки) системы и все отношения и связи между ними, выявить ошибочные, лишние или дублирующие связи и т.д.
4. Передача информации.
Средства IDEF0 облегчают передачу информации от одного участника разработки модели (отдельного разработчика или рабочей группы) к другому. К числу таких средств относятся:
· диаграммы, основанные на простой графике блоков и стрелок, легко
читаемые и понимаемые;
· метки на естественном языке для описания блоков и стрелок, а также
глоссарий и сопроводительный текст для уточнения смысла элементов диаграммы;
· последовательная декомпозиция диаграмм, строящаяся по иерархическому принципу, при котором на верхнем уровне отображаются основные функции, а затем происходит их детализация и уточнение;
5. Строгость и формализм.
Разработка моделей IDEF0 требует соблюдения ряда строгих формальных правил, обеспечивающих преимущества методологии в отношении однозначности, точности и целостности сложных многоуровневых моделей. Все стадии и этапы разработки и корректировки модели должны строго, формально документироваться с тем, чтобы при ее эксплуатации не возникало вопросов, связанных с неполнотой или некорректностью документации.
6. Итеративное моделирование.
Разработка модели в IDEF0 представляет собой пошаговую, итеративную процедуру. На каждом шаге итерации разработчик предлагает вариант модели, который подвергают обсуждению, рецензированию и последующему редактированию, после чего цикл повторяется. Такая организация работы способствует оптимальному использованию знаний системного аналитика, владеющего методологией и
техникой IDEF0, и знаний специалистов – экспертов в предметной области, к которой относится объект моделирования.
7. Отделение «организации» от «функций».
При разработке моделей следует избегать изначальной «привязки» функций исследуемой системы к существующей организационной структуре моделируемого объекта (предприятия, фирмы). Это помогает избежать субъективной точки зрения, навязанной организацией и ее руководством. Организационная структура должна явиться результатом использования (применения).
Набор структурных компонентов языка, их характеристики и правила, определяющие связи между компонентами, представляют собой синтаксис языка. Компоненты синтаксиса IDEF0 – блоки, стрелки, диаграммы и правила. Блоки представляют функции, определяемые как деятельность, процесс, операция, действие или преобразование. Стрелки представляют данные или материальные обекты, связанны с функциями. Правила определяют, как следует применять компоненты; диаграммы обеспечивают формат графического и словесного описания моделей. Формат образует основу для управления конфигурацией модели.
Рассмотрим подробнее компоненты синтаксиса.
Блок описывает функцию. Внутри каждого блока помещается его имя и номер. Имя должо быть активным глаголом или глагольным оборотом, описывающим функцию. Номер блока размещается в правом нижнем углу. Номера блоков используются для их идентификации на диаграмме и в соответствующем тексте. (пример блока показан ниже). Размеры блоков должны быть достаточными для того, чтобы включить имя блока. Блоки должны быть прямоугольниками, с прямыми углами, а также нарисованы сплошными линиями.
 |
Стрелка формируется из одного или более отрезков прямых или наконечника на одном конце. Сегменты стрелок могут быть прямыми или ломанными, горизонтальные и вертикальные отрезки стрелки соединяются дугами под углом 90°. Стрелки направленные по диагонали недопускаются. Стрелки не представляют поток или последовательность событий, как в традиционных блок-схемах потоков или процессов. Они лишь показывают, какие данные или материальные объекты должны поступить на вход функции для того, чтобы эта функция могла выполняться. Стрелки также могут ветвиться или сливаться. Концы стрелок должны касаться внешней границы функционального блока, но не должны пересекать её. Стрелки должны присоединяться к блоку на его сторонах. Присоединение в углах не допускается.
Каждая сторона функционального блока имеет стандартное значение с точки зрения связи блока и стрелки. В свою очередь, сторона блока, к которой присоединена стрелка, однозначно определяет её роль. Стрелки, входящие в левую сторону блока – входы. Входы преобразуются или расходуются функцией, чтобы создать то, что появится на её выходе. Стрелки, входящие в блок сверху – управление. Управление определяет условия, необходимые функции, чтобы произвести правильный выход. Стрелки покидающие блок справа – выходы, т.е. данные или материальные объекты, произведенные функцией.
IDEF0. Знакомство с нотацией и пример использования
Зачастую в моей работе возникает необходимость не просто изучить и решить определенную проблему, но выявить ее местонахождение в общей модели работы компании. Мало понимать, что определенное подразделение работает неправильно, важно понимать, каким образом оно взаимодействует с другими. Иначе невозможно выявить все существующие проблемы и выбрать оптимальный метод решения поставленной задачи. А для этого требуется изучить работу компании и составить ее функциональную модель.Конечно, в теории функциональная модель работы компании должна быть у руководителя, причем, не важно, идет речь об организации работы склада или об IT системе (от лида до заявки). Но в реальности практически никогда ее не оказывается, а потому в процессе изучения и поиска решения поставленной клиентом задачи я также создаю функциональную модель работы компании или определенного процесса (функции) самостоятельно.
Одна картинка стоит тысячи слов. Народная мудрость
Зачастую в моей работе возникает необходимость не просто изучить и решить определенную проблему, но выявить ее местонахождение в общей модели работы компании. Мало понимать, что определенное подразделение работает неправильно, важно понимать, каким образом оно взаимодействует с другими. Иначе невозможно выявить все существующие проблемы и выбрать оптимальный метод решения поставленной задачи. А для этого требуется изучить работу компании и составить ее функциональную модель.Конечно, в теории функциональная модель работы компании должна быть у руководителя, причем, не важно, идет речь об организации работы склада или об 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 основных этапа:
На схеме наглядно видно, на каком этапе какие управляющие элементы и какие механизмы задействованы. Так, автор при создании аудио использует свои знания и опыт, при этом руководствуется планом публикации и требованиями издателя. Копирайтер получает на входе аудиозапись, из которой, руководствуясь правилами русского языка, создает текст. Корректор получает текст и проверяет его, также руководствуясь правилами русского языка. Для размещения статьи в издании необходимо специальное программное обеспечение.
При создании функциональной модели ключевыми параметрами являются цель и точка зрения. Исходя из них, моделирование одних и тех же процессов может выглядеть несколько по-разному. Например, в моем случае целью является «рассказать о процессе написания статьи». А точка зрения копирайтера – это «написание и публикация статьи с точки зрения руководителя процесса».
Так, если бы тот же процесс был описан с точки зрения копирайтера, то входящими были бы опыт и аудиофайл от автора. При этом в таком случае под Опытом подразумевался бы опыт копирайтера, но не руководителя или автора. А потому первое, что нужно определить при создании модели бизнес-процесса – это выбрать точку зрения и четко сформулировать цель. Такое моделирование не только наглядно, но и очень удобно для принятия эффективных управленческих решений. Например, в описанном выше бизнес-процессе есть два отдельных специалиста — копирайтер и корректор.
Если я поставлю задачу оптимизировать финансирование проекта, то я благодаря схеме сразу увижу, где это и как можно сделать. Так, к копирайтер и корректор пользуются примерно одинаковыми правилами, но копирайтер получает аудио, а выдает результат в виде текста, корректор же и принимает, и отдает текст.
А потому при необходимости я могу, скажем, за половину стоимости обязанности корректора предложить копирайтеру. Так я сэкономлю средства и время на взаимодействие разных специалистов. Конечно, я понимаю все заслуги корректоров и почему лучше работать с отдельным специалистам. Но напоминаю — у меня стоит задача: оптимизация затрат. Без такого наглядного инструмента было бы сложнее определить, какие из блоков можно удалить и, таким образом, оптимизировать работу.
Как создавать нотации IDEF0
Существует множество различных программных продуктов, которые можно применять при создании нотаций. Какие-то созданы специально для функционального моделирования, другие предназначены для любой работы с графическими элементами. Где и как вы будете строить эти модели – решать вам.
Я лично считаю, что на первом этапе нет ничего лучше, чем обычная бумага, простой карандаш и ластик, чтобы вносить корректировки в случае ошибок. Для того чтобы создать нотацию существующих бизнес-процессов, т.е. описать, как сейчас работает компания, необходимо принципы работы изучить. Сторонний специалист (консультант, разработчик) для этого проводит интервью. На первом этапе на вопросы отвечает руководитель компании, далее в процессе детализации нотации проводятся интервью сотрудников, отвечающих за различные этапы работы.
При этом важно понимать, что в результате потребуется 2 нотации. Первая будет отображать бизнес-процессы в виде «как есть». Ее вы создаете на основе интервью и согласовываете каждую детализацию с сотрудниками компании и руководителем. Очень важно, чтобы ваше видение существующих процессов совпало с реальностью, именно для этого и требуется подтверждение на всех уровнях. Вторая нотация – «как должно быть».
Она создается на основе первой и тех изменений, которые вы предлагаете внести в структуру работы для оптимизации и автоматизации работы компании в рамках выполнения поставленной задачи. Требования стандарта IDEF0 Базовые требования стандарта IDEF0, в принципе, я описал выше и показал на примере.
Стандарт IDEF0 включает в себя также общепринятые обозначения, правила, требования к блокам диаграмм, имеет собственную семантику. Подробно ознакомиться с ними можно в документе «Методология функционального моделирования IDEF0».
Типичные ошибки
Функциональное моделирование выполняют при помощи самых разных инструментов, в том числе, не предназначенных для моделирования. В последнем случае нет проверки на ошибки и ограничения стандарта. Желание повысить наглядность и отсутствие опыта при этом часто оканчиваются ошибками.
Использование различных цветов
Все элементы на диаграмме одинаково важны. При функциональном моделировании нет более или менее важных элементов. Исчезновение любого приведет к нарушению процесса и производственному браку.
Часто при моделировании на бумаге или в различных программах пользователи пытаются повысить наглядность за счет использования разных цветов. Это одна из самых распространенных ошибок. На самом деле, применение разноцветных стрелок и блоков только вносит дополнительную путаницу, а также искажает восприятие схемы.
Ваша модель должна читаться в черно-белом виде, без каких-то дополнительных цветовых решений. Такой подход одновременно помогает избежать недоразумений и дисциплинирует создателя модели, в результате читабельность и грамотность модели повышаются.
Слишком большое количество блоков
При составлении модели часто стараются отобразить на одном листе все нюансы работы компании со всеми подробностями. В результате получается очень большое количество блоков с большим количеством управляющих стрелок.
Читабельность при этом теряется. Оптимальный вариант – это детализация, достаточная для понимания вопроса, и не более того. Подробная детализация работы каждого подразделения или даже сотрудника может раскрываться при выборе подробного просмотра того или иного процесса. И создается такая структура только если это действительно нужно для работы или принятия решения.
Нарушение структуры при внесении корректировок
Внимательно следите за тем, чтобы не возникло путаницы или процессов без входящих, исходящих и других важных элементов. Например, если в приведенном выше примере, я посчитаю нужным сместить точку зрения на копирайтера, я удалю из схемы автора. И тогда управляющие элементы «опыт автора и сторонние источники», а также план публикации становятся ненужными. Ведь ими пользуется автор. Копирайтер работает с аудиофайлом.
И если они останутся в общей схеме, то при детализации будут вести непонятно куда и вносить путаницу. Аналогично, если я решу добавить какой-то блок, важно убедиться, чтобы он также имел все необходимые атрибуты. Здесь очень важна внимательность, так как при моделировании сложных бизнес-процессов изменения в одной части модели могут повлечь за собой изменения в другой. Их обязательно нужно внести.
Правила названия управляющих элементов и блоков
Важно запомнить простое правило: управляющие стрелки называют именами существительными, блоки – глаголами. Так принято в стандарте IDEF0, и такой подход помогает избежать путаницы и ошибок. Чаще всего ошибки допускают при названии блоков. Например, вместо «Создать статью» пишут «Создание статьи». Блоки в данном подходе – это действия, а потому они должны быть всегда глаголами.
Выгоды использования IDEF0
В чем трудность применения IDEF0
Важно понимать, что только в самых простых случаях два бизнес-аналитика создадут для описания работы компании абсолютно одинаковые функциональные модели. Любая модель – это отражение опыта аналитика, глубины понимания работы бизнеса, который он стремится описать, а также, в некотором роде, его личная точка зрения на этот бизнес. Т.е. человек разрабатывает бизнес-модель с точки зрения руководителя, как будто этим руководителем является именно он.
При этом я считаю, что бизнес-аналитик — это не совсем профессия, бизнес-аналитикой занимается каждый руководитель бизнеса или разработчик каких-то систем, который анализирует бизнес и стремится выстроить наиболее эффективную систему. Именно для этих людей и для этих целей предназначен инструмент IDEF0. А потому очень важно при составлении функциональной бизнес модели «как есть» постоянно советоваться с руководителем компании, чтобы не совершить ошибки, которая повлечет за собой автоматически ошибки на этапах декомпозиции. Также на последующих этапах могут потребоваться дополнительные согласования с руководителями структурных подразделений и сотрудниками.
Только если ваша функциональная модель «как есть» будет действительно отражать реальное положение вещей, можно вносить какие-то изменения и предложения. А для достижения качественных результатов в такой работе требуется, прежде всего, практический опыт и знание особенностей того или иного вида бизнеса.