Idef0 описание бизнес модели

Оглавление 2
Введение 3
1. История возникновения стандарта IDEF0 4
2. Основные элементы и понятия IDEF0 4
3. Процесс разработки IDEF0-модели 13
4. Особенности национальной практики применения функционального моделирования средствами IDEF0 14
Заключение 17
Список используемой литературы 18

Работа состоит из 1 файл

Введение

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

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

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

BPMN 2.0, EPC, IDEF — описание бизнес процессов от А до Я // Что выбрать и почему CORE лучше?

Основу многих современных стандартов описания бизнес-процессов составили методология SADT (Structured Analysis and Design Technique – метод структурного анализа и проектирования), семейство стандартов IDEF (Icam DEFinition, где Icam — это Integrated Computer-Aided Manufacturing) и алгоритмические языки.

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

1. История возникновения стандарта IDEF0

Исторически, IDEF0, как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing) и была предложена департаментом Военно-Воздушных Сил США. Собственно семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF=ICAM DEFinition). В процессе практической реализации, участники программы ICAM столкнулись с необходимостью разработки новых методов анализа процессов взаимодействия в промышленных системах. При этом кроме усовершенствованного набора функций для описания бизнес-процессов, одним из требований к новому стандарту было наличие эффективной методологии взаимодействия в рамках “аналитик-специалист”. Другими словами, новый метод должен был обеспечить групповую работу над созданием модели, с непосредственным участием всех аналитиков и специалистов, занятых в рамках проекта.

В результате поиска соответствующих решений родилась методология функционального моделирования IDEF0. C 1981 года стандарт IDEF0 претерпел несколько незначительных изменения, в основном ограничивающего характера, и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST).

Моделирование в нотации IDEF0: инженерная или эскизная модель

2. Основные элементы и понятия IDEF0

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

Первым из них является понятие функционального блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника (см. рис. 1) и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, “производить услуги”, а не “производство услуг”).

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

• Верхняя сторона имеет значение “Управление” (Control);
• Левая сторона имеет значение “Вход” (Input);
• Правая сторона имеет значение “Выход” (Output);
• Нижняя сторона имеет значение “Механизм” (Mechanism).

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.

Рис. 1. Функциональный блок.

Вторым “китом” методологии IDEF0 является понятие интерфейсной дуги (Arrow). Также интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком.

Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного.

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

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

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

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

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

Рис. 2.

Другое дело, когда технологические указания обрабатываются главным технологом и в них вносятся изменения (рис. 3). В этом случае они отображаются уже входящей интерфейсной дугой, а управляющим объектом являются, например, новые промышленные стандарты, исходя из которых производятся данные изменения.

Рис. 3.

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

Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

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

Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором “А-0”.

В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения(Viewpoint).

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

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

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

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

Важно отметить, что в каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок, или исходящие из него фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0 – модели. Наглядно принцип декомпозиции представлен на рисунке 4. Следует обратить внимание на взаимосвязь нумерации функциональных блоков и диаграмм — каждый блок имеет свой уникальный порядковый номер на диаграмме (цифра в правом нижнем углу прямоугольника), а обозначение под правым углом указывает на номер дочерней для этого блока диаграммы. Отсутствие этого обозначения говорит о том, что декомпозиции для данного блока не существует.

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

С другой стороны, случается необходимость избавиться от отдельных “концептуальных” интерфейсных дуг и не детализировать их глубже некоторого уровня. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования. Обозначение “туннеля” (Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из “туннеля”) только на этой диаграмме. В свою очередь, такое же обозначение вокруг конца (стрелки) интерфейсной дуги в непосредственной близи от блока – приёмника означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет. Чаще всего бывает, что отдельные объекты и соответствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных уровнях иерархии – в таком случае, они сначала “погружаются в туннель”, а затем, при необходимости “возвращаются из туннеля”.

Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого из элементов IDEF0: диаграмм, функциональных блоков, интерфейсных дуг существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Например, для управляющей интерфейсной дуги “распоряжение об оплате” глоссарий может содержать перечень полей соответствующего дуге документа, необходимый набор виз и т.д. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.

Рисунок 4. Декомпозиция функциональных блоков.

Принципы ограничения сложности IDEF0-диаграмм

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

Источник: www.freepapers.ru

Принципы построения модели IDEF0

Наиболее удобным языком моделирования бизнес-процессов является IDEF0, предложенный Дугласом Россом (SoftTech, Inc.) и называвшийся первоначально SADT — Structured Analysis and Design Technique.

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

Под моделью в IDEF0 понимают описание системы (текстовое и графи­ческое), которое должно дать ответ на некоторые заранее определенные вопросы.

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

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

Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами, другими словами, мы должны определить, что мы будем в дальнейшем рассмат­ривать как компоненты системы, а что как внешнее воздействие. На опреде­ление субъекта системы будет существенно влиять позиция, с которой рассматривается система, и цель моделирования — вопросы, на которые построенная модель должна дать ответ, другими словами, первоначально необходимо определить область (Scope) моделирования.

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

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

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

Цель моделирования (Purpose).Модель не может быть построена без четко сформулированной цели. Цель должна отвечать на следующие вопросы:

· Почему этот процесс должен быть смоделирован?

· Что должна показывать модель?

· Что может получить читатель?

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

Точка зрения (Viewpoint).Хотя при построении модели учитываются мнения различных людей, модель должна строиться с единой точки зрения. Точку зрения можно представить как взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соот­ветствовать цели моделирования.

Очевидно, что описание работы пред­приятия с точки зрения финансиста и технолога будет выглядеть совер­шенно по-разному, поэтому в течение моделирования важно оставаться на выбранной точке зрения. Как правило, выбирается точка зрения челове­ка, ответственного за моделируемую работу в целом. Часто при выборе точки зрения на модель важно задокументировать дополнительные альтер­нативные точки зрения. Для этой цели обычно используют диаграммы FEO (For Exposition Only), которые будут описаны в дальнейшем.

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

Модели AS-IS и ТО-ВЕ.Целью построения функциональных моделей обычно является выявление наиболее слабых и уязвимых мест деятель­ности организации, анализе преимуществ новых бизнес-процессов и сте­пени изменения существующей структуры организации бизнеса.

Анализ недостатков и «узких мест» начинают с построения модели AS-1S (Как есть), т.е. модели существующей организации работы. Модель AS-IS может строиться на основе изучения документации (должностных инструкций, положений о предприятии, приказов, отчетов и т.п.), анке­тирования и опроса служащих предприятия, создания фотографии рабочего дня и других источников. Полученная модель AS-IS служит для выявления неуправляемых работ, работ не обеспеченных ресурсами, ненужных и неэффективных работ, дублирующихся работ и других недостатков в организации деятельности предприятия. Исправ­ление недостатков, перенаправление информационных и материальных потоков приводит к созданию модели ТО-ВЕ (Как будет) — модели идеальной организации бизнес-процессов. Как правило, строится несколько моделей ТО-ВЕ, среди которых определяют наилучший вариант.

Следует указать на распространенную ошибку при создании модели AS-IS — это создание идеализированной модели. Примером может служить создание модели на основе знаний руководителя, а не конкретного испол­нителя работ. Руководитель знаком с тем, как предполагается выполнение работы по руководствам и должностным инструкциям, и часто не знает, как на самом деле подчиненные выполняют рутинные работы. В результате получается приукрашенная, искаженная модель, которая несет ложную информацию и которую невозможно в дальнейшем использовать для ана­лиза. Такая модель называется SHOULD BE (Как должно бы быть).

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

Иногда текущая AS-IS и будущая ТО-ВЕ модели различаются очень сильно, так что переход от начального к конечному состоянию становится неочевидным. В этом случае необходима третья модель, описывающая процесс перехода от начального к конечному состоянию системы, посколь­ку такой переход — это тоже бизнес-процесс.

Для задания цели моделирования, точки зрения и иных свойств модели предназначен диалог Model Properties (меню Model → Model Properties) (рис. 1).

Рис. 1. Диалог Model Properties

Закладка Generalслужит для внесения имени модели и проекта, имени и инициалов автора и временных рамок модели — AS-IS и ТО-ВЕ.

В закладке Purposeследует внести цель и точку зрения, а в закладке Definition– пояснительный текст (описание) к модели и описание области. В закладке Sourceописываются источники информации для построения модели (например, «Опрос экспертов предметной области и анализ документации»). В закладке Statusтого же диалога можно описать статус модели(рабочая версия, черновик, рекомендовано, публикация), время создания и последнего редактирования (отслеживается в дальнейшем автоматически по системной дате).

В закладке Numberingзадаются правила нумерации функциональных блоков.

В закладке Displayзадается список элементов отображаемых на диаграммах.

Закладка Layoutзадает параметры расположения объектов на диаграмме.

Закладка ABC Unitsзадает единицы функционально-стоимостного анализа.

PageSetup– закладка, на которой задаются параметры страницы.

Header /Footer– закладка, на которой задаются опции заголовка и нижнего колонтитула каркаса.

В закладке Shapesустанавливаются виды фигур для объектов диаграмм по умолчанию.

DrawStyle- закладка, на которой задаются опции графического стиля.

Диаграммы IDEF0.Основу методологии IDEF0 составляет графичес­кий язык описания бизнес-процессов. Модель в нотации IDEF0 представ­ляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе.

Модель может содержать четыре типа диаграмм:

· контекстную (в каждой модели может быть только одна контекстная
диаграмма);

· только для экспозиции (FEO).

Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимо­действия с внешней средой. После описания системы в целом проводится разбиение ее на крупные фрагменты.

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

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

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

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

Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:

Источник: studopedia.ru

IDEF0: функциональное моделирование деловых процессов

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

Разработчики информационных систем очень часто под повышением эффективности понимают рост количества рабочих станций в локальной вычислительной сети (ЛВС) предприятия, рост пропускной способности ЛВС, рост количества документов, обработка которых осуществляется на автоматизированных рабочих местах (АРМах) и т.п.

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

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

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

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

IDEF0 — методология функционального моделирования

В ходе реализации программы интегрированной компьютеризации производства (ICAM), предложенной в свое время ВВС для аэрокосмической промышленности США, была выявлена потребность в разработке методов анализа взаимодействия процессов в производственных системах. Для удовлетворения этой потребности была разработана методология IDEF0 (Integrated Definition Function Modeling), которая в настоящее время принята в качестве федерального стандарта США. Методология успешно применялась в самых различных отраслях, продемонстрировав себя как эффективное средство анализа, проектирования и представления деловых процессов. В настоящее время методология IDEF0 широко применяется не только в США, но и во всем мире. В России IDEF0 успешно применялся в государственных учреждениях (к примеру, в Государственной Налоговой Инспекции), в аэрокосмической промышленности (при проектировании космодрома в Плесецке), в Центральном Банке и коммерческих банках России, на предприятиях нефтегазовой промышленности и предприятиях других отраслей.

Основные понятия IDEF0

В основе IDEF0 методологии лежит понятие блока, который отображает некоторую бизнес-функцию. Четыре стороны блока имеют разную роль: левая сторона имеет значение «входа», правая — «выхода», верхняя — «управления», нижняя — «механизма» (см. рис. 1).

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

Принципы моделирования в IDEF0

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

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

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

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

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

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

Применение IDEF0

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

Построение модели КАК ЕСТЬ . Обследование предприятия является обязательной частью любого проекта создания или развития корпоративной информационной системы. Построение функциональной модели КАК ЕСТЬ позволяет четко зафиксировать, какие деловые процессы осуществляются на предприятии, какие информационные объекты используются при выполнении деловых процессов и отдельных операций. Функциональная модель КАК ЕСТЬ является отправной точкой для анализа потребностей предприятия, выявления проблем и «узких» мест и разработки проекта совершенствования деловых процессов.

Бизнес-правила . Модель деловых процессов позволяет выявить и точно определить бизнес-правила, используемые в деятельности предприятия.

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

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

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

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

Информационные объекты . Функциональная модель позволяет идентифицировать все информационные объекты, которыми оперирует предприятие в своей деятельности. В отличие от информационных моделей (Data Flow Diagrams, IDEF1X) функциональная модель IDEF0 отражает, как именно используются информационные объекты в рамках деловых процессов.

Построение модели КАК БУДЕТ . Создание и внедрение корпоративной информационной системы приводит к изменению условий выполнения отдельных операций, структуры деловых процессов и предприятия в целом. Это приводит к необходимости изменения системы бизнес-правил, используемых на предприятии, модификации должностных инструкций сотрудников. Функциональная модель КАК БУДЕТ позволяет уже на стадии проектирования будущей информационной системы определить эти изменения. Применение функциональной модели КАК БУДЕТ позволяет не только сократить сроки внедрения информационной системы, но также снизить риски, связанные с невосприимчивостью персонала к информационным технологиям.

Распределение ресурсов . Функциональная модель позволяет четко определить распределение ресурсов между операциями делового процесса, что дает возможность оценить эффективность использования ресурсов.

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

Программные системы IDEF0

В настоящее время существует множество CASE средств, поддерживающих функциональное моделирование в стандарте IDEF0.

ЗАКЛЮЧЕНИЕ

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

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

Ссылки по теме