Создание idef0 онлайн. Построение модели IDEF0. Два подхода к началу моделирования

Постановка задач Цель работы: сократить время и повысить удобство разработки диаграмм IDEF0 за счет удобного, интуитивно понятного интерфейса, большой области для работы. Задачи: Проанализировать предметную область и объект проектирования Выбрать методы решения; Закодировать и оттестировать; Внедрить.

Функциональные требования Создание следующих компонентов диаграммы IDEF0 на рабочей области: функционального ICOM-блока; интерфейсной дуги; комментариев. Перемещение компонентов диаграммы последовательности на рабочей области путем перетаскивания мышкой (с помощью технологии drag and drop). Удаление компонентов и связанных с ней элементов диаграммы с рабочей области: функционального ICOM-блока; интерфейсной дуги; комментариев. Установка фокуса на элемент диаграммы (для реализации функций удаления и технологии drag and drop). Редактирование название компонента диаграммы, изменение текста без удаления самой надписи. Ассоциирование комментариев с конкретными компонентами диаграммы. Сохранение и загрузка диаграммы в файл с расширением.xml Экспорт изображения

Нефункциональные требования Соответствие стандарту IDEF0. Соответствие варианту задания. стрелки должны быть проаннотированы, включая выносные аннотации; должны быть реализованы изогнутые стрелки; должна быть реализована стандартная IDEF рамка диаграммы. Реализация технологии Drag and Drop. Работать под управлением ОС Windows XP, 7. Продукт должен ставиться на «чистую» ОС, без требований установки дополнительных программ. Разрешающая способность экрана: 1024*768. Интерфейс на русском языке. Интерфейс однооконный. Наличие инсталлятора.

Распределение обязанностей Насонов: Программирование и отладка функций для работы с элементом «DiagramItem»: – создание – редактирование – перемещение в любую область рабочего поля – Удаление Программирование и отладка функций для работы элемента «TextItem»: – создание – редактирование – удаление Заводовский: Программирование и отладка функций для работы элемента «Arrow»: – Создание – Удаление

Распределение обязанностей Шалыгина: Программирование и отладка функций для работы с файлом: Составление структуры ide файла Осуществление записи ide файла Редактирование ide файла, Считывание ide файла Реализация функции «Создать», Реализация функции «Сохранить », «Сохранить как» Реализация функции «Открыть» Куц: Тестирование программы Проектирование интерфейса Составление плана работ Предложение концепции выбора технологии

Методика испытаний 1Создание стандартной рамки Вход: данные, необходимые для заполнения рамкиВыход: на рабочей области работает Статус: работает 2Добавление ICOM блока Вход: Выбор элемента «ICOM блок» и размещение его на рабочей области Выход: Появление элемента «ICOM блок» и размещение его на рабочей области Статус: работает 3Соединение блоков стрелками Вход: Выбор элемента «стрелка» и соединение ею двух ICOM блоков Выход: Появление элемента «стрелка» на рабочей области Статус: работает 4Удаление стрелки Вход: выделение стрелки и нажатие кнопки «удалить» Выход: стрелка удаляетсяСтатус: работает 5Удаление ICOM блока Вход: выделение ICOM блока и нажатие кнопки «удалить» Выход: ICOM блок удаляетсяСтатус: работает 6Аннотирование блока Вход: выделение ICOM блока, нажатие кнопки «добавить текст» Выход: добавлен текст к блокуСтатус: работает

Методика испытаний 7Аннотирование стрелок Вход: Выделение стрелки, нажатие кнопки «добавить текст» Выход: добавлен текст к стрелке Статус: работает 8Перетаскивание блока Вход: Нажатие левойкнопкой мыши на ICOM блок и перенос на другое место на сцене Выход: Блок изменил свои координаты на сцене Статус: работает

Полученные результаты По результатам проделанных работ стало возможно использовать следующие функции: Создание следующих компонентов диаграммы IDEF0 на рабочей области: функционального ICOM-блока; интерфейсной дуги; комментариев. Перемещение компонентов диаграммы последовательности на рабочей области путем перетаскивания мышкой (с помощью технологии drag and drop). Удаление компонентов и связанных с ней элементов диаграммы с рабочей области: функционального ICOM-блока; интерфейсной дуги; комментариев. Установка фокуса на элемент диаграммы (для реализации функций удаления и технологии drag and drop). Редактирование название компонента диаграммы, изменение текста без удаления самой надписи. Ассоциирование комментариев с конкретными компонентами диаграммы. Сохранение и загрузка диаграммы в файл с расширением.xml Экспорт изображения

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

Перспективы По результатам второго релиза наша команда готова предоставить заказчику редактор IDEF0 диаграмм с полным перечнем функций, заявленных в требованиях. Мы надеемся, что Вам понравились результаты работы на первом релизе. Нам приятно будет сотрудничать с Вами в дальнейшем. С уважением, Шалыгина М.М., Заводовский В.Б., Куц Д.В., Насонов А, А.

IDEF0 Diagrams Software - Create IDEF0 diagrams and business diagrams rapidly with rich examples and templates. Provide some IDEF0 knowledge.

IDEF Definition

IDEF is based on the Structured Analysis and Design Technique (SADT), a graphical approach to system description, introduced by Douglas T. Ross in the early 1970s. Since then, system analysts at Softech, Inc. have refined and used SADT in a wide variety of problems. In 1981, the U.S. Air Force Program for Integrated Computer-Aided Manufacturing (ICAM) standardized and made public a subset of SADT, called IDEF.

Was originally used to apply structured methods to better understand how to improve manufacturing productivity. IDEF0 was initially created at Northrop Corporation in 1966, and first available commercially by SofTek in 1972. An IDEF0 activity diagram contains one level of decomposition of a process. Boxes within a diagram show the subprocesses of the parent process named by the diagram. Arrows between the boxes show the flow of products between processes.

Innovative IDEF0 Software

Edraw Max is an easy to use IDEF0 diagrams software, which creates IDEF0 diagrams and business diagrams rapidly with rich examples and templates.

Build hierarchical diagrams using IEDF0 process charting models for model configuration management, need and benefit analyses, requirements definitions, and continuous improvement models.

System Requirements

Works on Windows 7, 8, 10, XP, Vista and Citrix

Works on 32 and 64 bit Windows

Works on Mac OS X 10.2 or later

Software Features

1. state of the art
2. vector-based
3. more than just IDEF0, IDEF1, IDEF2 Diagrams which can make over 200 kinds of diagrams
4. easy to use with drag and drop interface, premade symbols and automatic formatting tools
5. accompanied by a plethora of well-designed templates and examples
6. designed with broad file format compatibility

IDEF0 diagrams typically include the following components:

Context diagram - The topmost diagram in an IDEF0 model.

Parent/child diagram - An IDEF0 decomposition hierarchy using parent/child relationships.

Node trees - Tree-like structures of nodes rooted at a chosen node, and used to represent a full IDEF0 decomposition in a single diagram.

The Benefits of Using IDEF0 to Model Business Processes

1. Understanding - modeling helps discover the nature of the business being modeled; that is, what is being done in the business.
2. Communication - once understanding has been reached, the nature of the business processes can be documented and these documents easily communicated.
3. Enlightenment - modeling helps to uncover anomalies, redundancies deficiencies and inefficiencies in the existing (as-is) business process.
4. Improvement - a model allows you to select deficient areas of the business and its processes and improve them.
5. Redesign - a model provides a tangible basis for redesigning the process, performing simulations of the redesigned (to-be) business process as defined by the strategy. This means that strategies can be tested before implementation takes place.

The IDEF0 Modeling Techniques

An IDEF0 model represents the activities of the business from the point of view of the business, how those business activities interrelate, resources used to conduct each activity, and the result or output of each activity. The model consists of graphics and associated text supporting the graphics.

The IDEF0 modeling technique consists of a graphic language and a modeling process that can be used to develop a rich process description. It is an intuitive way to define, analyze and document the business as a whole and the processes of the business.

Основной из трех методологий, поддерживаемых BPwin, является IDEF0. IDEF0, относится к семейству IDEF, которое появилось в конце шестидесятых годов под названием SADT (Structured Analysis and Design Technique). IDEF0 может быть использована для моделирования широкого класса систем. Для новых систем применение IDEF0 имеет своей целью определение требований и указание функций для последующей разработки системы, отвечающей поставленным требованиям и реализующей выделенные функции. Применительно к уже существующим системам IDEF0 может быть использована для анализа функций, выполняемых системой и отображения механизмов, посредством которых эти функции выполняются. Результатом применения IDEF0 к некоторой системе является модель этой системы, состоящая из иерархически упорядоченного набора диаграмм, текста документации и словарей, связанных друг с другом с помощью перекрестных ссылок. Двумя наиболее важными компонентами, из которых строятся диаграммы IDEF0, являются бизнес-функции или работы (представленные на диаграммах в виде прямоугольников) и данные и объекты (изображаемые в виде стрелок), связывающие между собой работы. При этом стрелки, в зависимости от того в какую грань прямоугольника работы они входят или из какой грани выходят, делятся на пять видов:

Стрелки входа (входят в левую грань работы) - изображают данные или объекты, изменяемые в ходе выполнения работы.

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

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

Стрелки механизма (входят в нижнюю грань работы) - изображают ресурсы, необходимые для выполнения работы, но не изменяющиеся в процессе работы (например, оборудование, людские ресурсы…)

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

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

Рисунок 7.1. Функциональный блок и интерфейсные дуги

Работы на диаграммах изображаются в виде прямоугольников (функциональные блоки). Каждая работа изображает какую-либо функцию или задачу и именуется глаголом или глагольной фразой, обозначающей действие, например «Изготовление изделия», «Обслуживание клиента» и т.д. Стрелки помечаются существительным и обозначают объекты или информацию, связывающую работы между собой и с внешним миром.

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

После того как контекст описан, проводится построение следующих диаграмм в иерархии. Каждая последующая диаграмма является более подробным описанием (декомпозицией) одной из работ на вышестоящей диаграмме. Пример декомпозиции контекстной работы показан на Рис.7.2 и Рис.7.4. Описание каждой подсистемы проводится аналитиком совместно с экспертом предметной области. Обычно экспертом является человек, отвечающий за эту подсистему и, поэтому, досконально знающий все ее функции. Таким образом, вся система разбивается на подсистемы до нужного уровня детализации, и получается модель, аппроксимирующая систему с заданным уровнем точности. Получив модель, адекватно отображающую текущие бизнес-процессы (так называемую модель AS IS), аналитик с легкостью может увидеть все наиболее уязвимые места системы. После этого, с учетом выявленных недостатков, можно строить модель новой организации бизнес-процессов (модель TO BE).

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

На рисунке 7.2, где приведены три диаграммы и их взаимосвязи, показана структура IDEF0.-модели. Каждый компонент модели может быть декомпозирован на другой диаграмме. Каждая диаграмма иллюстрирует "внутреннее строение" блока на родительской диаграмме.

Рисунок 7.2 - Пример контекстной диаграммы

Как видно на Рис.7.2, BPwin позволяет выделять работы и стрелки разными цветами, а также привязывать имена стрелок к самим стрелкам (стрелка по имени “Отчетность”), что повышает наглядность и читаемость диаграммы.

Рисунок 7.3 - Пример диаграммы декомпозиции

Рисунок 7 . 4 - Пример контекстной диаграммы

Рисунок 7.5 - Пример диаграммы декомпозиции

Иерархия диаграмм

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

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

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

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

Рисунк 7.6 - Структура SADT-модели. Декомпозиция диаграмм

Рисунок 7.7 - Соответствие должно быть полным и непротиворечивым

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

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

Рис. 7.8. Пример механизма

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

Для того, чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Например, А21 является диаграммой, которая детализирует блок 1 на диаграмме А2. Аналогично, А2 детализирует блок 2 на диаграмме А0, которая является самой верхней диаграммой модели. На рисунке 7.9 показано типичное дерево диаграмм.

Рисунок 7.9 - Иерархия диаграмм

Лекция 8. Методологии DFD и IDEF 3

Известная сегодня уже не только в узких кругах аббревиатура IDEF0 является первой методологией, стандартизирующей работу над бизнес-процессами. Она была разработана в середине прошлого века в рамках аэрокосмического проекта в США и, показав свою эффективность, стала федеральным стандартом. В нашей стране в 2000 году подготовлен документ «Методология функционального моделирования IDEF0. Руководящий документМетодология функционального моделирования IDEF0 Руководящий документ. Издание официальное. Госстандарт России РД IDEF0 – 2000. Разработан Научно-исследовательским Центром CALS – технологий «Прикладная Логистика». Принят и введен в действие Постановлением Госстандарта России 2000 г. Москва », но как стандарт он так и не был утвержден. Хотя это не помешало данной методологии стать в нашей стране одним из наиболее популярных инструментов графического моделирования бизнес-процессов. В данной статье я предлагаю вам рассмотреть модель IDEF0 и оценить актуальность этого подхода в настоящее время.

Основные понятия и сокращения

Разберемся немного с названиями ключевых элементов методологии. Графический стандарт IDEF0 является частью методологии SADT (Structured Analysis and Design Technique – метод структурного анализа и проектирования). IDEF – это сокращение от ICAM Definition, а ICAM образовано от Integrated Computer Aided Manufacturing, что переводится как интегрированная компьютеризация производства. Методология SADT – это целое семейство из 15 разных моделей, которые в комплексе должны были позволить исследовать структуру, параметры и характеристики производственно-технических и организационно-экономических систем.

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

Нотация IDEF0 – это достаточно строгая методика, которая изначально была разработана, как и стандарты технического конструирования, для ручного моделирования. Поэтому там содержатся требования по размещению стрелок, формату всех элементов, содержанию информационной рамки к IDEF0 диаграмме и пр. Поскольку деятельность компании – это сложная многоуровневая система действий, то схем получается всегда много, и необходима однозначная систематизация и навигация по всем элементам модели. Сейчас это делают в основном компьютерные системы, поддерживающие моделирование в данной нотации. На территории России наиболее известными и доступными на сегодня являются системы AllFusion Process Modeler и Business Studio. Обзору этих систем я планирую посвятить отдельные статьи.

Функциональный блок

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

Обязательные элементы функционального блока в IDEF0

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

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

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

Для построения функциональной модели методология IDEF0 требует соблюдать следующие правила.

1. Входы – это ресурсы, которые переносят свою стоимость в выходы полностью, то есть расходуются на создание результата полностью, а механизмы – это ресурсы, которые переносят свою стоимость только частично (оборудование – через амортизацию, а люди – через заработную плату).
2. Управление – это необходимый элемент модели, так как он привязывает все действия к системе регламентов компании, четко обозначая, какие правила и требования должны быть соблюдены в процессе выполнения функции. Часто к этому потоку относятся формально, но при этом схема теряет строгость, а иногда даже смысл.
3. У каждого функционального блока должна быть как минимум одна стрелка с каждой стороны (так как не может быть работы без ресурсов или результатов, а также неполной будет инструкция без исполнителя или инструкции).

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

Контекстная диаграмма

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

1. Цель – конкретная формулировка назначения модели, по которой можно сверять в дальнейшем точность построения модели.
2. Точка зрения – от чьего лица строится модель, так как модель зависима всегда от ее автора и фокуса внимания. Если мы строим общую модель предприятия, то обычно она представляется с точки зрения его директора.
3. Тип модели – это указание на то, какая информация отображена на схемах. Здесь может быть 2 принципиальных варианта: AS IS («как есть») или TO BE («как будет»). Такое разделение необходимо, так как мы можем строить модели как для анализа деятельности, так и для ее трансформации. Мы должны четко отдавать себе отчет в том, что мы делаем, а также доносить эту информацию до окружающих.

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

Основные потоки

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

1. Материальный: материалы и комплектующие на входе и готовая продукция на выходе.
2. Клиентский: потенциальный клиент на входе и удовлетворенный на выходе.
3. Финансовый: на входе это обычно инвестиции, платежи клиентов (выручка), кредиты и прочие доходы; на выходе – это платежи поставщикам, налоги, платежи по кредитам и прибыль.
4. Информационный: на входе это все потоки информации о внешней среде (состояние рынка, поведение конкурентов, технологические инновации и пр.), а на выходе – это поток информации, которую компания сообщает о себе миру (вся рекламная информация, а так же все виды отчетности перед контролирующими органами).

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

(нажмите для увеличения)

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

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

• законы и нормы;
• приказы, распоряжения;
• инструкции и регламенты;
• планы;
• конструкторская документация и пр.

Второй – это недокументированная информация, к которой чаше всего относятся требования собственников.

И, наконец, механизмы – здесь только 2 вида потоков: оборудование (материальный) и исполнители (подразделения и люди). Здесь не может быть документов, как и не может быть людей на стрелках управления!

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

Декомпозиция

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

(нажмите для увеличения)

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

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

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

На рисунке ниже представлена диаграмма декомпозиции нашего примера.

(нажмите для увеличения)

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

Дальнейшая работа над моделью аналогична первому шагу – проводится декомпозиция каждого функционального блока первого уровня. Нумерация блоков будет содержать при этом номер первого уровня: А1.1 … А1.n, A2.1 … A2.n и т.д.

Выводы об актуальности нотации

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

1. Модель обладает хорошим визуализирующим потенциалом, но, на мой взгляд, большее ее значение – в дисциплинирующем эффекте. Заложенные в методологию правила и ограничения заставляют выработать системное и строгое отношение к моделям, что очень хорошо сказывается на качестве конечного результата.
2. Модель позволяет выстроить потоки связи между внешне не сильно связанными вещами: связать подсистемы фронт и бэк-офисов с управлением, что гораздо хуже удается другим нотациям.
3. Подход прост и понятен для большинства участников проекта. Построение и чтение диаграмм в данной нотации ограничивается только желанием вникать в хитросплетение потоков бизнеса.

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

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

Поэтому если пользоваться данной нотацией для тех задач, для которых она предназначена (структурирование деятельности верхнего уровня), то IDEF0 практически единственная на сегодня нотация, которая позволяет сделать это содержательно и аккуратно.

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

Владимир Репин К.т.н., исполнительный директор ООО «ФИНЭКСПЕРТ.РУ », зав. кафедрой Управления бизнес-процессами НОУ ВПО «ИЭФ «Синергия».

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

При попытке отобразить цепочку создания ценности, представленную на рисунке 5, в модели IDEF0 возникает вопрос: каким образом отобразить на одной диаграмме 16 бизнес-процессов одновременно? Делать это не стоит, т.к. диаграмма станет плохо читаемой (не говоря уже о нарушении требований стандарта). Нужно определиться с тем, каким образом сгруппировать процессы так, чтобы с одной стороны сохранилась цепочка, а с другой — чрезмерно не усложнять диаграмму . Кроме того, нужно решить, отображать ли в данной модели бизнес-процессы закупки, сбыта, управления финансами и т.д. Вариантов решения этой проблемы может быть несколько. Какого-то единственного правильного решения не существует. Конечно, все зависит от того, какие цели мы ставим перед моделью. На рисунке 6 показан пример модели в IDEF0, построенной для рассматриваемого случая.

Бизнес-процессы на диаграмме А0 (рисунок 6) сгруппированы по трем категориям на основе анализа движения материальных потоков — сырья, полуфабрикатов, готовой продукции. Далее в качестве примера показано детальное представление процесса «Производить, хранить и доставлять сырье» (см. рисунок 7).

Рисунок 6. Фрагмент модели в IDEF0, построенной на основе цепочек создания ценности. Диаграмма А0.

На рисунке 7 белым цветом показаны бизнес-процессы, выполняемые предприятием, а серым цветом — бизнес-процессы, выполняемые внешними контрагентами. Видно, что бизнес-процесс «Закупать сырье», по сути, управляет всеми остальными бизнес-процессами в рассматриваемой части цепочки создания ценности. Выполняется этот процесс Отделом закупок Службы снабжения. Так же в этом процессе участвует подразделение «Транспортный отдел» (оно не показано на схеме организационной структуры на рисунке 1). Хотя данное подразделение не входит в Службу снабжения, но выполняет часть рассматриваемого процесса. Таким образом, на диаграмме А2 представлен «сквозной» или межфункциональный (даже можно сказать межорганизационный) бизнес-процесс.

У читателя может возникнуть вопрос: почему на диаграмму А2 не попал бизнес-процесс хранения сырья на складе предприятия, выполняемый Складом сырья Службы снабжения? Этот процесс был условно отнесен в блоку процессов «Хранить и перерабатывать сырье и полуфабрикаты» (диаграмма А0, рисунок 6). Здесь мы коснулись вопроса определения границ «сквозных» или межфункциональных бизнес-процессов. Поскольку такие процессы не локализованы внутри отдельных подразделений (или даже организаций), определение их границ является достаточно субъективным и зависит от ряда критериев, которые, как правило, вырабатывается при проведении анализа бизнеса компании на основе установленных целей и задач.

Рисунок 7. Фрагмент модели в IDEF0, построенной на основе цепочек создания ценности. Диаграмма А2.

Выводы

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

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

Москва, февраль 2005 г.

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

Состав функций и распределение их по сотрудникам являются условными. Таблица дается в качестве примера.

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

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

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

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