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

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

Основной из трех методологий, поддерживаемых 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 и idef3 - использовать свободно распространяемый кроссплатформенный редактор диаграмм, блок-схем, сетевых диаграмм, UML-диаграмм и прочей нечисти под названием "Dia". Программа переведена на многие языки, включая русский.

Скачать программу можно на ее официальном сайте: http://projects.gnome.org/dia/ . На момент написания статьи последняя версия программы Dia была под номером 0.97.1 - причем она является таковой уже чуть ли не два года. Не смотря на это функционал у приложения отличный.

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

для создания схем в графической нотации idef0 достаточно выбрать стандартную библиотеку элементов Dia под названием "SADT / IDEF0":

Если вы впервые столкнулись с idef0, то очень рекомендую сначала прочитать вот эти статьи про эту методологию:

1. Современные методологии описания бизнес-процессов. Методология IDEF0 - Ковалев Валерий Михайлович (Журнал "Консультант директора", № 12, Июнь, 2004 г.)
2. IDEF0 как инструмент моделирования процессов - Андрей Дворников (Журнал "Авант Партнер", № 22(79), Август 2005 г.)
3. Опыт использования стандарта IDEF0 - Сергей Рубцов

Построение IDEF3-диаграмм

С idef3 капельку посложнее. Стандартного набора элементов для построения диаграмма в графической нотации idef3 в Dia не предусмотрено, однако все нужные блоки в программе есть. Их нужно просто сгруппировать вручную. Для этого нажимаем в меню: "Файл -> категории и объекты". В открывшемся окне нажимаем кнопку "Создать". Откроется ещё одно окошко, в котором выбираем пункт "Название категории" и вписываем туда "idef3". Процесс создания категории выглядит примерно так:

Так как вы только что создали эту категорию - естественно она пуста. Нам нужно переместить в нее нужные элементы схем. Поэтому:

Жмем кнопку "Применить", "Закрыть" окошко и готово! Заходим в "другие библиотеки элементов" и выбираем там созданную нами графическую нотацию "idef3" (она располагается в положенной ей месте по алфавиту). Кстати, чтобы писать в блоках, удобно использовать клавишу F2. Конечно, это не идеальный инструмент, но этот способ позволяет создавать диаграммы IDEF3 максимально приближенно к их точной графической нотации.

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

ЛАБОРАТОРНАЯ РАБОТА № 1

Основы работы в BPwin

С помощью этой лабораторной работы Вы сможете:

познакомиться с основными элементами рабочего интерфейса BPwin;

освоить технологию создания новой модели;

научиться редактировать построенную диаграмму.

Теоретические сведения

 Для упрощения процесса построения модели бизнес-процессов в IDEF0, можно использовать CASE-средство BPwin, которое позволяет наглядно представить функциональную декомпозицию системы.

AllFusion Process Modeler (BPwin) является инструментальным средством, полностью поддерживающим стандарт IDEF0, который был принят в начале 90-х годов в США на основе SADT.

Основная идея методологии SADT - построение древовидной функциональной модели предприятия.

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

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

Рис. 1.1. Пример диаграммы IDEF0

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

строиться модель). Обычно в качестве точки зрения выбирается точка зрения лица или объекта, ответственных за работу моделируемой системы в целом.

Общая функция разбивается на крупные подфункции. Этот процесс называется

функциональной декомпозицией.

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

Этапы построения модели

1. Определение основного бизнес-процесса.

2. Построение контекстной диаграммы.

3. Построение диаграммы процесса верхнего уровня.

4. Функциональная декомпозиция каждого процесса, с помощью детализирующих диаграмм.

Практическое задание

Создание диаграммы А-0

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

Целевые функции мебельной фабрики:

переработка сырья;

изготовление деталей для мебели;

сборка изделия;

контроль качества.

Нормативные документы мебельной фабрики:

чертежи (деталей, сборочный);

нормы по переработке сырья;

стандарты качества;

производственные инструкции;

инструкции по технике безопасности.

Подразделения предприятия:

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

цех по изготовлению деталей;

сборочный цех;

отдел проверки качества изделия.

Основным сырьем для изготовления мебели является дерево .

Определим основной бизнес-процесс, используя выявленные целевые функции. Так как основное предназначение мебельной фабрики состоит в том, чтобы изготавливать мебель, значит, основным бизнес-процессом является ИЗГОТОВЛЕНИЕ МЕБЕЛИ.

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

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

Для контекстного процесса ИЗГОТОВЛЕНИЕ МЕБЕЛИ определим необходимую информацию:

ВХОД - сырьё;

УПРАВЛЕНИЕ – чертежи, производственные инструкции, инструкции по технике безопасности (нормативные документы);

МЕХАНИЗМЫ – персонал, производственное оборудование;

ВЫХОД – готовая мебель.

Задание 1. Запуск программы и открытие проекта.

Создание новой модели.

1. Запустите BPwin .

2. Выберите режим работы: создать новую модель (Create model ).

3. В поле Name введите имя модели:Изготовление мебели .

4. Из группы Type выберите тип диаграммыBusiness Process (IDEF0 ) (рис.

Рис. 1.2. Диалоговое окно создания модели

5. Нажмите OK.

После щелчка на кнопке ОК появляется диалог Properties for New Models (рис. 1.3.).

6. Укажите свою фамилию и инициалы.

Рис. 1.3. Диалоговое окно Properties for New Models

После этого вы увидите стандартное окно BPwin (рис. 1.4.):

Рис. 1.4. Стандартное окно BPwin

Основные инструменты BPwin

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

На основной панели инструментов расположены элементы управления, в основном знакомые по другим Windows-интерфейсам (рис. 1.5.):

Рис. 1.5. Элементы управления BPwin

Функциональность панели инструментов доступна из основного меню BPwin (табл. 1).

Таблица 1. 1. Элементы управления основной панели инструментов BPwin

На основной панели инструментов (либо в любом желаемом месте экрана) расположены инструменты редактора BPwin для IDEF0-диаграмм (рис. 1.6.).

Рис. 1.6. Панель инструментов редактора BPwin

Таблица 1.2. Инструменты редактора BPwin

Задание 2. Работа с блоком.

Построение контекстной диаграммы процесса ИЗГОТОВЛЕНИЕ МЕБЕЛИ.

Для ввода имени блока необходимо:

1. Щелкнуть правой клавишей мыши по блоку.

2. Выбрать команду Name .

3. В диалоговом окне ввести название «Изготовление мебели» (рис.1.7.).

Рис. 1.7. Диалоговое окно BPwin

4. Для того чтобы текст стал понятен, в контекстном меню выберите пункт

Font (рис. 1.8.):

Рис. 1.8. Контекстно-зависимое меню

5. В диалоговом окне Activity Properties в нижней части вкладкиFоnt установите флажки в опцияхАрр1у setting to , позволяющих изменить шрифт для всех работ на текущей диаграмме, в модели, и в группеGlobal , позволяющей изменить шрифт одновременно для всех объектов модели, в опцииScript выберите«кириллический».

3. Подвести курсор мыши к верхней стороне блока до образования темного треугольника и щелкнуть левой кнопкой мыши (рис. 1.11.).

Рис. 1.11. Построение дуги управления

Построение дуг входа имеханизмов производится аналогичным образом.

4. Постройте дуги входа имеханизмов .

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

5. Постройте дугу выхода.

Задание 4. Идентификация дуги управления.

1. Выберите на панели редактирования кнопку .

2. Щелкните правой кнопкой мыши по дуге.

3. Выберите команду Name (рис. 1.12.).

Рис. 1.12. Контекстно-зависимое меню

4. В диалоговом окне введите название дуги: «Нормативная документация»

Построение модели IDEF0

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

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

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

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

Цель моделирования

Цель моделирования определяется из ответов на следующие вопросы:

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

Точка зрения (Viewpoint).

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

IDEF0-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения. Для внесения области, цели и точки зрения в модели IDEF0 в BPwin следует выбрать пункт меню Model/Model Properties, вызывающий диалог Model Properties (рис. П2.3). В закладке Purpose следует внести цель и точку зрения, а в закладку Definition - определение модели и описание области.

Рис. П2.3. Диалог задания свойств модели

В закладке Status того же диалога можно описать статус модели (черновой вариант, рабочий, окончательный и т. д.), время создания и последнего редактирования (отслеживается в дальнейшем автоматически по системной дате). В закладке Source описываются источники информации для построения модели (например, "Опрос экспертов предметной области и анализ документации"). Закладка General служит для внесения имени проекта и модели, имени и инициалов автора и временных рамок модели - AS-IS и ТО-ВЕ.

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

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

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

Результат описания модели можно получить в отчете Model Report. Диалог настройки отчета по модели вызывается из пункта меню Tools/Reports/Model Report.

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

Рис. П2.4. Диалоговое окно для формирования отчета по модели

На рис. П2.5 представлен отчет, сформированный по вышеуказанным полям.

Рис. П2.5. Предварительный просмотр отчета

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

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

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

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

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

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

Работы (Activity) обозначают поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Работы изображаются в виде прямоугольников. Все работы должны быть названы и определены. Имя работы должно быть выражено отглагольным существительным, обозначающим действие (например, "Деятельность компании", "Прием заказа" и т.д.). Работа "Деятельность компании" может иметь, например, следующее определение: "Это учебная модель, описывающая деятельность компании". При создании новой модели (меню File/New) автоматически создается контекстная диаграмма с единственной работой, изображающей систему в целом (рис. П2.6).

Рис. П2.6. Пример контекстной диаграммы

Для внесения имени работы следует щелкнуть по работе правой кнопкой мыши, выбрать в меню Name Editor и в появившемся диалоге внести имя работы. Для описания других свойств работы служит диалог Activity Properties (рис. П2.7).

Рис. П2.П2. Редактор задания свойств работы

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

Возникает диалог Activity Box Count (рис. П2.8), в котором следует указать нотацию новой диаграммы и количество работ на ней. Остановимся пока на нотации IDEF0 и щелкнем на ОК. Появляется диаграмма декомпозиции (рис. П2.9). Допустимый интервал числа работ - 2-8. Декомпозировать работу на одну работу не имеет смысла: диаграммы с количеством работ более восьми получаются перенасыщенными и плохо читаются. Для обеспечения наглядности и лучшего понимания моделируемых процессов рекомендуется использовать от трех до шести блоков на одной диаграмме.

Рис. П2.8. Диалог Activity Box Count

Рис. П2.9. Пример диаграммы декомпозиции

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

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

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

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

Стрелки(Arrow) описывают взаимодействие работ и представляют собой некую информацию, выраженную существительными.(Например, "Звонки клиентов", "Правила и процедуры", "Бухгалтерская система".)

В IDEF0 различают пять типов стрелок:

Вход (Input ) - материал или информация, которые используются или преобразуются работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Каждый тип стрелок подходит к определенной стороне прямоугольника, изображающего работу, или выходит из нее. Стрелка входа рисуется как входящая в левую грань работы. При описании технологических процессов (для этого и был придуман IDEF0) не возникает проблем определения входов. Действительно, "Звонки клиентов" на рис. П2.6 - это нечто, что перерабатывается в процессе "Деятельность компании" для получения результата. При моделировании ИС, когда стрелками являются не физические объекты, а данные, не все так очевидно. Например, при "Приеме пациента" карта пациента может быть и на входе и на выходе, между тем качество этих данных меняется. Другими словами, в нашем примере для того, чтобы оправдать свое назначение, стрелки входа и выхода должны быть точно определены с тем, чтобы указать на то, что данные действительно были переработаны (например, на выходе - "Заполненная карта пациента"). Очень часто сложно определить, являются ли данные входом или управлением. В этом случае подсказкой может служить информация о том, перерабатываются/изменяются ли данные в работе или нет. Если изменяются, то, скорее всего, это вход, если нет - управление.

Управление (Control ) - правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы. На рис. П2.6 стрелка "Правила и процедуры" - управление для работы "Деятельность компании". Управление влияет на работу, но не преобразуется работой. Если цель работы - изменить процедуру или стратегию, то такая процедура или стратегия будет для работы входом. В случае возникновения неопределенности в статусе стрелки (управление или вход) рекомендуется рисовать стрелку управления.

Выход (Output ) - материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка выхода рисуется как исходящая из правой грани работы. На рис. П2.6 стрелки "Маркетинговые материалы" и "Проданные продукты" являются выходом для работы "Деятельность компании".

Механизм (Mechanism ) - ресурсы, которые выполняют работу, например персонал предприятия, станки, устройства и т. д. Стрелка механизма рисуется как входящая в нижнюю грань работы. На рис. П2.6 стрелка "Бухгалтерская система" является механизмом для работы "Деятельность компании". По усмотрению аналитика стрелки механизма могут не изображаться в модели.

Вызов (Call ) - специальная стрелка, указывающая на другую модель работы. Стрелка вызова рисуется как исходящая из нижней грани работы. На рис. П2.10 стрелка "Другая модель работы" является вызовом для работы "Изготовление изделия". Стрелка вызова используется для указания того, что некоторая работа выполняется за пределами моделируемой системы. В BPwin стрелки вызова используются в механизме слияния и разделения моделей.

Рис. П2.10. Стрелка вызова, появляющаяся при расщеплении модели

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

Для внесения граничной стрелки входа следует:

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

Рис. П2.11. Диалог IDEF0 Arrow Properties

ICOM-коды . Диаграмма декомпозиции предназначена для детализации работы. В отличие от моделей, отображающих структуру организации, работа на диаграмме верхнего уровня в IDEF0 - это не элемент управления нижестоящими работами. Работы нижнего уровня - это то же самое, что работы верхнего уровня, но в более детальном изложении. Как следствие этого границы работы верхнего уровня - это то же самое, что границы диаграммы декомпозиции. ICOM (аббревиатура от Input, Control, Output и Mechanism) - коды, предназначенные для идентификации граничных стрелок. Код ICOM содержит префикс, соответствующий типу стрелки (I, С, О или М), и порядковый номер.

BPwin вносит ICOM-коды автоматически. Для отображения ICOM-кодов следует включить опцию ICOM codes на закладке Display диалога Model Properties (меню Model/Model Properties) (рис.П2.12).

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

Рис. П2.12. Включение опции ICOM codes на закладке Display

Рис. П2.13. Редактирование словаря стрелок

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

Несвязанные граничные стрелки (unconnected border arrow) . При декомпозиции работы входящие в нее и исходящие из нее стрелки (кроме стрелки вызова) автоматически появляются на диаграмме декомпозиции (миграция стрелок), но при этом не касаются работ. Такие стрелки называются несвязанными и воспринимаются в BPwin как синтаксическая ошибка.

На рис. П2.14 приведен фрагмент диаграммы декомпозиции с несвязанными стрелками, генерирующийся BPwin при декомпозиции работы "Сборка настольных компьютеров" (см. рис. П2.9). Для связывания стрелок входа, управления или механизма необходимо перейти в режим редактирования стрелок, щелкнуть по наконечнику стрелки и потом по соответствующему сегменту работы. Для связывания стрелки выхода необходимо перейти в режим редактирования стрелок, щелкнуть по сегменту выхода работы и затем по стрелке.

Рис. П2.14. Пример несвязанных стрелок

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

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

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

Рис. П2.15. Связь по входу

Связь по управлению (output-control ), когда выход вышестоящей работы направляется на управление нижестоящей. Связь по управлению показывает доминирование вышестоящей работы. Данные или объекты выхода вышестоящей работы не меняются в нижестоящей. На рис. П2.16 стрелка "Заказы клиентов" связывает работы "Продажи и маркетинг" и "Сборка и тестирование компьютеров" .

Рис. П2.16. Связь по управлению

Обратная связь по входу (output-input feedback ), когда выход нижестоящей работы направляется на вход вышестоящей. Такая связь, как правило, используется для описания циклов. На рис. П2.17 стрелка "Результаты тестирования" связывает работы "Тестирование компьютеров" и "Отслеживание расписания и управление сборкой и тестированием" .

Рис. П2.1П2. Обратная связь по входу

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

Рис. П2.18. Обратная связь по управлению

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

Рис. П2.19. Связь выход-механизм

Явные стрелки. Явная стрелка имеет источником одну-единственную работу и назначением тоже одну-единственную работу.

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

Смысл разветвляющихся и сливающихся стрелок передается именованием каждой ветви стрелок. Существуют определенные правила именования таких стрелок. Рассмотрим их на примере разветвляющихся стрелок. Если стрелка именована до разветвления, а после разветвления ни одна из ветвей не именована, то подразумевается, что каждая ветвь моделирует те же данные или объекты, что и ветвь до разветвления (рис. П2.20).

Рис. П2.20.

Если стрелка именована до разветвления, а после разветвления какая-либо из ветвей тоже именована, то подразумевается, что эти ветви соответствуют именованию. Если при этом какая-либо ветвь после разветвления осталась неименованной, то подразумевается, что она моделирует те же данные или объекты, что и ветвь до разветвления (рис. П2.21).

Рис. П2.21. Пример именования разветвляющейся стрелки

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

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

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

Рис. П2.22. Неразрешенная (unresolved) стрелка

Для их "перетаскивания" наверх нужно щелкнуть правой кнопкой мыши по квадратным скобкам граничной стрелки и в контекстном меню выбрать команду Arrow Tunnel (рис. П2.23).

Рис. П2.23. Выбор команды из контекстного меню

Появляется диалог Border Arrow Editor (рис. П2.24).

Если щелкнуть по кнопке Resolve Border Arrow, стрелка мигрирует на диаграмму верхнего уровня, если по кнопке Change To Tunnel - стрелка будет туннелирована и не попадет на другую диаграмму. Туннельная стрелка изображается с круглыми скобками на конце (рис. П2.25).

Рис. П2.24. Диалог Border Arrow Editor

Рис. П2.25. Типы туннелирования стрелок

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

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

Нумерация работ и диаграмм . Все работы модели нумеруются. Номер состоит из префикса и числа. Может быть использован префикс любой длины, но обычно используют префикс А. Контекстная (корневая) работа дерева имеет номер А0. Работы i декомпозиции А0 имеют номера А1, А2, A3 и т. д. Работы декомпозиции нижнего уровня имеют номер родительской работы и очередной порядковый номер, например работы декомпозиции A3 будут иметь номера А31, А32, АЗЗ, А34 и т. д. Работы образуют иерархию, где каждая работа может иметь одну родительскую и несколько дочерних работ, образуя дерево. Такое дерево называют деревом узлов, а вышеописанную нумерацию - нумерацией по узлам. Диаграммы IDEF0 имеют двойную нумерацию. Во-первых, диаграммы имеют номера по узлу. Контекстная диаграмма всегда имеет номер А-0, декомпозиция контекстной диаграммы - номер А0, остальные диаграммы декомпозиции - номера по соответствующему узлу (например, A1, A2, А21, А213 и т. д.). BPwin автоматически поддерживает нумерацию по узлам, т. е. при проведении декомпозиции создается новая диаграмма и ей автоматически присваивается соответствующий номер. В результате проведения экспертизы диаграммы могут уточняться и изменяться, следовательно, могут быть созданы различные версии одной и той же (с точки зрения ее расположения в дереве узлов) диаграммы декомпозиции. BPwin позволяет иметь в модели только одну диаграмму декомпозиции в данном узле. Прежние версии диаграммы можно хранить в виде бумажной копии либо как FEO-диаграмму. (К сожалению, при создании FEO-диаграмм отсутствует возможность отката, т. е. из диаграммы можно получить декомпозиции FEO, но не наоборот.) В любом случае следует отличать различные версии одной и той же диаграммы. Для этого существует специальный номер - C-number, который должен присваиваться автором модели вручную. C-number - это произвольная строка, но рекомендуется придерживаться стандарта, когда номер состоит из буквенного префикса и порядкового номера, причем в качестве префикса используются инициалы автора диаграммы, а порядковый номер отслеживается автором вручную, например МСВ00021.