Ни одна модель не может быть создана без конкретного объекта или цели. Формулировка цели должна ответить на следующие вопросы:
-почему был смоделирован представленный процесс;
-что эта модель собирается показать;
-что с ней могут сделать читающие ее.
Формулировка цели позволяет команде экспертов придерживаться ее на протяжении всего процесса моделирования. Без формулировки цели моделирование может зайти в тупик.
Модели создаются для получения ответа на ряд вопросов. Данные вопросы должны подготавливаться заранее и будут служить основой для создания цели модели. Примерные вопросы могут звучать следующим образом:
-каковы основные задачи сотрудника;
-кто отвечает за произведенную продукцию;
-кто управляет начальной стадией производства;
-какой требуется инструмент для каждого этапа.
Точка зрения (Viewpoint).
Особенно важно включать в процесс разработки модели представителей различных мнений, однако сама модель должна базироваться на единой точке зрения. Чаще всего разнообразные точки зрения кратко фиксируют на диаграмме ФЕО (англ. FEO, For Exposition Only. Русс. --- только для комментариев).
Эти диаграммы используются только в качестве материалов для презентаций. Точка зрения должна формулироваться с особенной внимательностью, отталкиваясь от цели.
При построении модели важно придерживаться одной точки зрения. Точка зрения должна содержать наименование должности, структурного подразделения или описание должностных обязанностей работника.
Модели могут содержать разнообразные точки зрения с целью детальной фиксации всех действий (функций).
Границы (Boundary).
Одной из главных польз, получаемых от конструирования моделей действия, является прояснение границ всей системы и ее специфических компонентов действия.
Хотя предполагается, что границы будут слегка модифицированы на протяжении процесса моделирования, они должны поддерживаться для указания направления в процессе разработки модели. К примеру, трудно понять закончена ли модель, формулируя цели без существования определенной границы. Граница модели будет иметь склонность расширяться в процессе совершенствования модели.
Граница имеет два компонента --- широту и глубину. Широту модели определяют боковые границы процесса. Глубину определяет уровень декомпозиции действий.
Для простоты определения границы многие процессы разработки модели IDEF 0 затрачивают большое время на доработку контекстной диаграммы модели. Диаграмма может быть даже разработана, что само по себе будет представлять один уровень подконтекстной диаграммы для указания на большую систему, внутри которой данная система находится. Эти усилия стоят того, так как контекстная диаграмма становится точкой отсчета для всего процесса моделирования. Все изменения в контекстной диаграмме будут становиться своеобразным каскадом в форме декомпозиции диаграммы.
Когда границы определены, то действия, не вошедшие в модель также проясняются.
Присвоение названия системе (действию).
Рекомендуемая последовательность действий при моделировании
--- определить цель модели, затем уточнить точки зрения касаемые модели и, в завершение, определить границы модели. Название действия, которое указано в контекстной диаграмме суммирует описание границ.
Контекстное действие должно содержать глагольную фразу, которая совпадает с формулировкой границ модели. Ожидается, что граница модели будет колебаться на протяжении первых нескольких дней моделирования. Цели и точки зрения модели останутся без изменения с самого начала.
Важно всегда начинать с определения целей, точек зрения и границы модели. Четкое определение этих позиций важно для всего процесса моделирования.
Определение основных параметров ИКОМ.
Согласно правилам построения интерфейсных стрелок в диаграммах стандарта IDEF0 нужно начинать от выхода, а не от входа, и затем представить «ресурс» и «управление». Каждое действие существует для выполнения специфических функций, и каждая функция имеет уже определенные выходы. Если будет трудно установить выход в действии, то это означает, что существует возможность изменения бизнес-процесса.
1. Определение выхода.
Если выход определили, необходимо уточнить соответствие модели сценарию. Данная процедура, если она возможна в данной ситуации, должна быть смоделирована, чтобы показать такую возможность. Многие исследователи забывают моделировать негативный результат, производимый действием. Негативный результат часто используется как обратная интерфейсная стрелка в начало действия и должна учитываться для каждого действия. Также важно включать «сомнительные» интерфейсные стрелки в диаграмму и позволить экспертам процесса решать, нужно ли их включать в модель.
2. Определение входа.
После того, как выходы были определены, должен продумываться вход. Вход специфически трансформирован или обработан действием для производства выходов. В производственной сфере легче представить, как «сырье-вход» трансформировано и/или обработано в противоположный «выход-продукт». Таким образом, в сфере информационного обмена ввод данных может вначале быть вообще не трансформирован или обработан. Очень редко интерфейсная стрелка входа именуется также как и интерфейсная стрелка выхода. В общем, это показывает, что либо данное действие добавляет некоторую ценность бизнесу, либо выход был неправильно назван. Решением этого может быть использование прилагательных для модифицирования существительных в наименовании стрелок для указания на трансформацию, которая имеет место в действии. Для примера, вход мог быть назван «исходная информация» и корреспондируемый выход мог быть назван как «верифицированная информация». Прилагательные «исходная» и «верифицированная» модифицируют данные для понимания результатов трансформации.
3. Определение ресурса.
После создания выхода и входа нужно продумывать ресурсы, относящиеся к действию. Ресурсы включают людей, оборудование, компьютерные базы данных и т.д.
4. Определение управления.
В завершении следует добавить интерфейсную стрелку «управление», управляющую действием. Управление существует в форме правил, регламента, политики, процедур или стандартов. Всем действиям в IDEF0 требуется хотя бы одна контрольная интерфейсная стрелка. Контроль является формой входа в действие.
Когда контекстная диаграмма становится завершенной и стабильной, задайте к ней следующие вопросы:
--- диаграмма суммирует действия, которые будут смоделированы;
--- контекстная диаграмма сочетается ли последовательно с границей, точкой зрения и целями;
--- находятся ли интерфейсной интерфейсные стрелки на подходящем уровне детализации для действия. (Для этого Вам нужно ограничить количество стрелок до шести каждого типа);
--- есть ли согласие рабочей группы по поводу модели.
5. Нумерация действий и диаграмм.
Все действия в стандарте IDEF0 пронумерованы. Может быть использован префикс любой длины, но почти во всех моделях использован символ А. После префикса следует число. Базовое действие всегда нумеруется символом А0. Префикс повторяется для каждого действия. Числа используются для представления того, как детализированы действия. Действие А0 декомпозировано в А1, А2, А3 и т.д. А1 также декомпозировано в А11, А12, А13 и т.д. А 11 также декомпозировано в А111, А112, А113 и т.д. К каждому уровню декомпозиции добавляются последовательные дополнительные цифры. Единственное исключение к этому формату --- это первый уровень, где А0 декомпозирован не в А01, А02 и т.д., а в А1, А2 и т.д.
6. Взаимоотношения диаграммы с родительским действием (границы и иерархия).
Действие декомпозируется, если для его понимания необходима большая детализация. Когда действие декомпозируется, не забывайте о его жизненном цикле. Это предопределяет список кандидатов в дочерние действия. К примеру, узел «делать пирожные» может иметь жизненный цикл «собирать ингредиенты», «приготовить масло», «печь тесто» и т.д.
В стандарте функционального моделирования IDEF0 важно осознавать, что границы дочерней диаграммы --- это границы родительского действия. Это имеет важное последствие. Вся работа осуществляется на листе (нижний уровень) действия.
В отличие от иерархии, как это определено в структурированном программировании, действия на высшем уровне не являются управляющими по отношению к дочерним действиям. «Дочки» и есть родительские действия, только представленные более детализировано.
Коды ИКОМ расположены в конце границы интерфейсной интерфейсные стрелки в дочерней диаграмме для указания, где корреспондируемся интерфейсная стрелка находится на родительской диаграмме. Они используются в качестве проверки последовательности и полезны, когда порядок стрелок в дочерних действиях отличается от родительских. Код ИКОМ состоит из букв И, К, О, М и числа, указывающего «верх - низ» или «лево - право», расположение этой интерфейсной интерфейсные стрелки на родительском действии, например И1, К1, О1, М1.
7. Моделирование «вширь» и «вглубь».
Модели могут быть разработаны как «вширь» (в которой каждая диаграмма детализирована наиболее подробно перед началом ее декомпозиции), так и «вглубь» (в которой иерархия действий сначала определена, а уже затем изображаются интерфейсной интерфейсные стрелки, соединяющие все воедино). Конечно, обе технологии могут быть задействованы на протяжении создания одной модели. Иерархия действий иногда будет незаметно изменяться при изображении стрелок, потому что изображение стрелок идентифицирует некие новые взгляды на структуру модели.
2.6. Пример: моделирование бизнес-процесса на основе стандарта IDEF0.
Для перехода к непосредственному практикуму по стандарту IDEF0 нами была предложена модель процесса консалтингового проекта. Для более простого анализа предложенной модели нами были выделены и сформулированы основные функции консалтингового проекта. Предлагаемые ниже функции взяты из книги «Управленческое консультирование» под редакцией Милана Кубра.
Итак, перечень функций консалтингового проекта состоит из пяти компонентов:
1.Подготовка к консультационному заданию.
2.Диагностика.
3.Планирование действий.
4.Внедрение.
5.Завершение.
Прежде, чем перейти к изучению модели бизнес-процесса следует проанализировать перечисленные выше функции.
Подготовка к консультационному заданию.
Любая работа состоит из начала и окончания. В консалтинговом проекте немаловажное место занимает подготовка к вступлению консультанта к проектному заданию. В частности к этой функции относятся следующие подфункции:
-контакты с клиентом;
-предварительная диагностика проблемы;
-формирование технического задания;
-формулирование предложений клиенту;
-заключение контракта на проведение консалтинговых работ.
Схематически рассматриваемую функцию можно представить следующим образом:
Рис.2 Действие отображаемое в стандарте IDEF0
Диагностика.
Основная задача диагностики выявить силы и факторы, которые вызывают проблему.
В нашей модели основными компонентами функции «Диагностика» являются:
-выявление необходимых факторов;
-анализ и синтез материала;
-детальное изучение проблемы.
Диагностика схематически представлена ниже.
Рис.3 Диагностика
Планирование действий.
Цель данной функции – определить верное решение проблемы клиента. Данная функция осложнена тем, что в случае ошибки на стадии диагностики необходимым станет возврат к предыдущему этапу и повторное проведение диагностики проблемы.
В данной функции модели выделены следующие компоненты:
-выработка решений;
-оценка альтернативных вариантов;
Рис.4 Планирование действий
-предложения клиенту;
-планирование практической реализации решения.
Как и в предыдущих двух функциях ниже представлен блок «Планирование действий».
Внедрение.
Эта функция осуществляет реализацию разработанных ранее консультантами решений проблем клиента. Компонентами описываемой функции принято считать:
-помощь в осуществлении предложенного;
-корректировка предложений;
-обучение персонала клиентской компании;
-планирование и контроль за внедрением.
Ниже представлена модель функции «Внедрение» на основе стандарта IDEF0.
Рис.5 Внедрение
Завершение.
Итак, завершающая функция в нашей модели – «Завершение». На этой стадии консалтинговых работ сдается последний отчет, производятся взаимные расчеты между сторонами и в случае успешного сотрудничества происходят переговоры о дальнейшем сотрудничестве. Ниже мы представили перечень выделенных компонент функции «Завершение»:
-оценка сделанного;
-конечный отчет;
-расчет по обязательствам;
-оценка планов на будущее;
-уход консультанта.
-
Рис.7 Контекстная диаграмма бизнес-процесса
Рис.6 Завершение
Теперь для полноты картины о вышеописанных функциях консалтингового бизнеса ниже будет представлен полностью описанный бизнес-процесс на основе стандарта IDEF0.
Рис. 8 Бизнес-процесс консалтингового проекта
2 .7. Описание метода DFD (DataFlaw Diagramming) (Метод Гэйна – Сарсона)
Также как и стандарт IDEF0 диаграммы потоков данных (DFD) моделируют систему, как сеть действий, связанных друг с другом. Диаграммы потоков данных также моделируют «холдинг-резервуар» (holding tank) сохранения данных, а также внешние элементы, которые указывают на связи с объектами за пределами созданной системы.
В отличие от стрелок в стандарте IDEF0, которые характеризуют вынужденные взаимоотношения, интерфейсные стрелки в DFD показывают как объекты (включая данные) в действительности протекают или движутся от одного действия к другому. Данное представление потока вместе с хранением данных и внешними элементами, дает DFD моделям больше сходства с физическими характеристиками системы, которыми являются движение объектов (поток данных), хранение объектов (хранение данных), обеспечение и объекто-распространение (внешние элементы).
Диаграммы потоков данных часто ассоциируются с разработкой программных продуктов, т.к. они разрабатывались изначально для этих целей. Данное изображение объекта в диаграмме было разработано Крисом Гэйном и Тришем Сарсоном – авторами метода разработки диаграмм потоков данных (метод Гэйна – Сарсона). Действия представлены в форме прямоугольника с закругленными углами. Подобно этому можно рассматривать метод DFD Юрдона – Де Марко, в которых кружками (шариками) изображаются действия.
Синтаксис и семантика модели DFD.
В отличие от стандарта IDEF0, который представляет систему, как набор взаимосвязанных действий, DFD представляет систему как «форму существительного». Контекстная диаграмма DFD часто состоит из прямоугольника действия и внешнего элемента. Прямоугольник действия обычно именуют именем системы.
Добавление внешних элементов не перечит фундаментальному требованию гласящему: «Модель нужно построить исходя из одной точки зрения. Она должна иметь четко определенную цель и границы.»
Действие.
Действие в диаграммах DFD представляет функцию, которая обрабатывает или трансформирует входы в выходы. Хотя обычно они изображаются в виде прямоугольника с закругленными углами, однако, действия в диаграммах DFD – те же действия, что и в стандартах IDEF0 и IDEF3. Как и в IDEF3 действиях, действия в DFD имеют вход и выход, но не обладают интерфейсными стрелками «управление» и «ресурс», как в стандарте IDEF0. В некоторых моделях Гэйна – Сарсона «ресурс» стандарта IDEF0 изображается как ресурсы и добавляется вниз прямоугольника.
Внешние элементы (External Entities).
Внешние элементы предоставляют вход для системы и/или получают из нее выход. Внешний элемент может сразу предоставить вход (действовать, как поставщик) и получать выход (как потребитель). Внешние элементы изображаются затененными прямоугольниками и обычно находятся по сторонам диаграммы. Единственный внешний элемент может появляться множество раз на одной диаграмме. Такое расположение обычно используют, чтобы избежать длинных соединяющих линий через всю диаграмму.
Интерфейсные стрелки (поток данных) (Arrows).
Интерфейсные стрелки описывают движение (поток) объектов из одной части системы в другую. По причине того, что стороны прямоугольника действия в диаграммах DFD не наделены определенными функциями, то интерфейсные стрелки могут исходить из любой стороны действия. В методе DFD также используют двунаправленную интерфейсную стрелку, чтобы указать координацию связи «команда – исполнение» между двумя действиями, между действием и внешним элементом и между внешними элементами.
Хранение данных (Data Storage).
Тогда как поток указывает на объекты в движении, хранение данных указывает на объекты, находящиеся в покое. В системе обработки данных, хранилища данных представляют механизмы, способом которых данные задерживаются для последующей обработки.
Разветвление и соединение.
В методе DFD интерфейсные стрелки могут разветвляться и их сегмент может быть переименован, чтобы показать декомпозицию данных, переходивших по процессу.
Интерфейсные стрелки могут также сходиться (соединяться) для формирования агрегированных объектов.
Построение модели DFD
DFD модель может быть построена, используя традиционный структурный анализ и подход к моделированию, схожий с описанным в стандарте IDEF0. Текущая физическая модель создается первой для описания существующей системы, которая в настоящее время используется. Затем текущая логическая модель создана для моделирования необходимых требований текущей системы. После этого, новая модель создана для моделирования необходимых требований предлагаемой системы. В конце концов, новая физическая модель создана для моделирования исполнения.
Альтернативный подход, который получил наибольшую популярность в разработке программного обеспечения и называется «расчленение события», в котором несколько моделей DFD построены для моделирования системы. Логическая модель построена для моделирования системы в виде набора действий и документирования того, что система должна делать.
Затем, модель окружения описывает систему, как объект, который отвечает за события, исходящие от внешних элементов. Данная модель окружения обычно состоит из формулировки цели системы, одной контекстной диаграммы и списка событий. Контекстная диаграмма состоит из одного прямоугольника, который представляет целую систему и внешних элементов, с которыми данная система будет взаимодействовать, т.е. с ее окружением.
В итоге поведенческая модель создана для моделирования того, как система будет поддерживать все события. Данная модель начинается в виде одной диаграммы с одним прямоугольником. Хранилище данных добавлено для моделирования данных, которые должны быть сохранены между событиями. Потоки добавлены для связи с другими элементами и диаграмма проверена на наличие стыковок с моделью окружения.
Процесс подчистки обычно требуется для переформатирования модели с целью дальнейшего ее использования на презентациях. Агрегация действия использована для создания упрощенной родительской диаграммы. Декомпозиция применяется для улучшения понимания.
Нумерация объекта.
В методе DFD каждое число действия может включать префикс, значение родительской диаграммы и номер объекта. Номер объекта идентифицирует уникальность действия в диаграмме. Номер родительской диаграммы и номер объекта вместе идентифицируют каждое действие в модели.
Уникальные числа относятся к каждому хранилищу данных либо внешним ссылочным именам вне зависимости от нахождения объекта на диаграмме.
Каждый номер хранилища данных содержит префикс «D» и уникальный номер хранилища.
Каждая внешняя ссылка включает в себя префикс «E» и уникальный номер внешнего элемента.
2.8. Пример: моделирование процесса обмена данными на основе метода DFD.
В случае с методом DFD рассмотрим построение модели на примере документооборота, существующего внутри консалтингового проекта на стадии анализа и сбора данных для оптимизации организационной структуры управления (ОСУ).
На стадии диагностики ОСУ выделяют следующие основные области для анализа:
– принятие управленческих решений;
- скалярная цепь;
– функций управления;
– «зоны прав и ответственности» в организации.
Ниже представлена диаграмма DFD описания обмена данными на стадии диагностики ОСУ.
Рис.9 Модель описания процесса обмена данными при диагностике ОСУ
2 .9. Выводы по второй части
Представленный выше стандарт уже достаточно давно используется во всем мире практиками – консультантами в своих проектах по реинжинирингу бизнес-процессов. Стандарт IDEF уже давно прошел проверку временем на профессиональную пригодность.
Завершая вторую часть статьи о стандарте IDEF, хотелось бы еще раз отметить его основные свойства.
Широкий спектр применения.Стандарт IDEF можно использовать как при описании процессов в малых, так и в крупных (холдинговых, сетевых) организациях. Стандарт IDEF может быть использован как инструмент реинжиниринга не только для описания процессов, протекающих в коммерческих организациях, но и в некоммерческом секторе, а также специфических процессов, существующих в управлении государственными учреждениями и организациями.
Простота синтаксиса и семантики.Стандарт IDEF достаточно прост с точки зрения его освоения. Как уже было показано выше в настоящей статье синтаксис и семантика стандартов IDEF 0 и IDEF 3 содержит набор символьных элементов, каждый из которых носит свое информационное содержание. Нет в стандарте IDEF одинаковых символов с разными свойствами, как и наоборот – нет разных символов с одинаковой трактовкой. Стандарт IDEF обладает строгим понятийным аппаратом, без которого невозможно существование на практике кодированной информации.
Информационная полнота.Стандарт IDEF способен описывать большие массивы информации о процессе. Это отражается не только в части графического представления информации о бизнес-процессе. Стандарту IDEF присущи и аналитические способности, без которых графическое представление информации было бы неполноценным. В частности к таким дополнительным инструментам к стандарту IDEF можно отнести функционально – стоимостной анализ, строение границ диаграммы стандарта и т.д.
