Моделирование бизнес процессов средствами bpwin

Моделирование деловых процессов, как правило, выполняется с помощью case-средств. К таким средствам относятся BPwin (PLATINUM technology), Silverrun (Silverrun technology), Oracle Designer (Oracle), Rational Rose (Rational Software) и др. Функциональные возможности инструментальных средств структурного моделирования деловых процессов будут рассмотрены на примере case-средства BPwin.

BPwin поддерживает три методологии моделирования: функциональное моделирование (IDEF0); описание бизнес-процессов (IDEF3); диаграммы потоков данных (DFD).

Инструментальная среда BPwin

BPwin имеет достаточно простой и интуитивно понятный интерфейс пользователя. При запуске BPwin по умолчанию появляется основная панель инструментов, палитра инструментов (вид которой зависит от выбранной нотации) и, в левой части, навигатор модели — Model Explorer (рис. 7.1).

При создании новой модели возникает диалог, в котором следует указать, будет ли создана модель заново или она будет открыта из файла либо из репозитория ModelMart, затем внести имя модели и выбрать методологию, в которой будет построена модель (рис. 7.2).

Как было указано выше, BPwin поддерживает три методологии — IDEF0, IDEF3 и DFD, каждая из которых решает свои специфические задачи. В BPwin возможно построение смешанных моделей, т. е. модель может содержать одновременно диаграммы как IDEF0, так и IDEF3 и DFD. Состав палитры инструментов изменяется автоматически, когда происходит переключение с одной нотации на другую.

Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Работа изображается в виде прямоугольников, данные — в виде стрелок. Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется контекстное меню, каждый пункт которого соответствует редактору какого-либо свойства объекта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Моделирование
деловых процессов, как правило,
выполняется с помощью case-средств. К
таким средствам
относятся BPwin (PLATINUM
technology), Silverrun (Silverrun technology), Oracle Designer
(Oracle), Rational Rose (Rational Software) и
др. Функциональные
возможности инструментальных средств
структурного моделирования деловых
процессов будут рассмотрены на
примере case-средства BPwin.

BPwin
поддерживает три методологии
моделирования: функциональное
моделирование (IDEF0); описание
бизнес-процессов (IDEF3); диаграммы
потоков данных (DFD).

Инструментальная
среда BPwin

BPwin
имеет достаточно простой и интуитивно
понятный интерфейс пользователя.
При запуске BPwin по умолчанию появляется
основная панель инструментов, палитра
инструментов (вид которой зависит
от выбранной нотации) и, в левой
части, навигатор модели — Model Explorer
(рис.
7.1).

При
создании новой модели возникает
диалог, в котором следует указать,
будет ли создана модель заново или
она будет открыта из файла либо из
репозитория ModelMart, затем внести имя
модели и выбрать методологию, в
которой будет построена модель (рис.
7.2).

Как
было указано выше, BPwin поддерживает
три методологии — IDEF0, IDEF3 и DFD, каждая
из которых решает свои специфические
задачи. В BPwin возможно построение
смешанных моделей, т. е. модель может
содержать одновременно диаграммы
как IDEF0, так и IDEF3 и DFD. Состав палитры
инструментов изменяется автоматически,
когда происходит переключение с
одной нотации на другую.

Рис.
7.1. 
Интегрированная среда разработки
модели BPwin

Рис.
7.2. 
Диалог создания модели

Модель
в BPwin рассматривается как совокупность
работ, каждая из которых оперирует
с некоторым набором данных. Работа
изображается в виде прямоугольников,
данные — в виде стрелок. Если щелкнуть
по любому объекту модели левой
кнопкой мыши, появляется контекстное
меню, каждый пункт которого
соответствует редактору какого-либо
свойства объекта.

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

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

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

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

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

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

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

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

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

• Что
  может получить клиент?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• диаграммы
  декомпозиции;

• диаграммы
  дерева узлов
  ;

• диаграммы
  только для экспозиции (FEO).

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

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

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

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

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

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

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

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

на
панели инструментов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• щелкнуть
  по кнопке с символом стрелки

;

• в
  палитре инструментов перенести
  курсор к левой стороне экрана, пока
  не появится начальная штриховая
  полоска;

• щелкнуть
  один раз по полоске (откуда выходит
  стрелка
  ) и еще раз в левой части работы
  со стороны входа (где заканчивается
  стрелка
  );

• вернуться
  в палитру инструментов и выбрать
  опцию редактирования стрелки

;

• щелкнуть
  правой кнопкой мыши на линии стрелки,
  во всплывающем меню выбрать Name и
  добавить имя стрелки
  в закладке Name диалога IDEF0 Arrow
  Properties.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Другим
примером туннелирования может быть
ситуация, когда стрелка механизма
мигрирует с верхнего уровня на
нижний, причем на нижнем уровне этот
механизм используется одинаково во
всех работах без исключения.
(Предполагается, что не нужно
детализировать стрелку механизма,
т. е. стрелка механизма на дочерней
работе именована до разветвления,
а после разветвления ветви не имеют
собственного имени). В этом случае
стрелка механизма на нижнем уровне
может быть удалена, после чего на
родительской диаграмме она может
быть туннелирована, а в комментарии
к стрелке или в словаре можно указать,
что механизм будет использоваться
во всех работах дочерней диаграммы
декомпозиции. Такое туннелирование
называется «не-в-дочерней-работе»
(рис.
7.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.

Диаграммы
дерева узлов и FEO

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

Рис.
7.26. 
Диаграмма дерева узлов

Для
создания диаграммы дерева узлов
следует выбрать в меню пункт
Diagram/Add Node Tree (рис.
7.27). Возникает диалог формирования
диаграммы дерева узлов Node Tree Definition
(рис.
7.28, 7.
29).

Рис.
7.27. 
Выбор команды для формирования
диаграммы дерева узлов

Рис.
7.28. 
Диалог настройки диаграммы дерева
узлов (шаг 1)

Рис.
7.29. 
Диалог настройки диаграммы дерева
узлов (шаг 2)

В
диалоге Node Tree Definition следует указать
глубину дерева — Number of Levels (по
умолчанию — 3) и корень дерева (по
умолчанию — родительская работа
текущей диаграммы). По умолчанию
нижний уровень декомпозиции
показывается в виде списка, остальные
работы — в виде прямоугольников.
Для отображения всего дерева в виде
прямоугольников следует выключить
опцию Bullet Last Level. При создании дерева
узлов следует указать имя диаграммы,
поскольку, если в нескольких диаграммах
в качестве корня на дереве узлов
использовать одну и ту же работу,
все эти диаграммы получат одинаковый
номер (номер узла + постфикс N, например
AON) и в списке открытых диаграмм
(пункт меню Window) их можно будет
различить только по имени.

Диаграммы
«только для экспозиции» (FEO)
часто используются в модели для
иллюстрации других точек зрения,
для отображения отдельных деталей,
которые не поддерживаются явно
синтаксисом IDEF0. Диаграммы FEO позволяют
нарушить любое синтаксическое
правило, поскольку по сути являются
просто картинками — копиями
стандартных диаграмм и не включаются
в анализ синтаксиса. Для создания
диаграммы FEO следует выбрать пункт
меню Diagram/Add FEO Diagram. В возникающем
диалоге Add New FEO Diagram следует указать
имя диаграммы FEO и тип родительской
диаграммы (рис.
7.30).

Рис.
7.30. 
Диалог создания FEO-диаграммы

Новая
диаграмма получает номер, который
генерируется автоматически (номер
родительской диаграммы по узлу +
постфикс F,
например A1F
).

Каркас
диаграммы

На
рис.
7.31 показан типичный пример диаграммы
декомпозиции с граничными рамками,
которые называются каркасом диаграммы.

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

Каркас
содержит заголовок (верхняя часть
рамки) и подвал (нижняя часть).
Заголовок каркаса используется для
отслеживания диаграммы в процессе
моделирования. Нижняя часть
используется для идентификации и
позиционирования в иерархии диаграммы.

Смысл
элементов каркаса приведен в табл.
7.1 и 7.2.

Значения
полей каркаса задаются в диалоге
Diagram Properties (меню Diagram /Diagram Properties) —
рис.
7.32.

Рис.
7.32. 
Диалог Diagram Properties

Таблица 7.1. Поля заголовка каркаса (слева направо)
Поле	Смысл
Used At	Используется для указания на родительскую работу в случае, если на текущую диаграмму ссылались посредством стрелки вызова
Autor, Date, Rev, Project	Имя создателя диаграммы, дата создания и имя проекта, в рамках которого была создана диаграмма. REV-дата последнего редактирования диаграммы
Notes 123456789 10	Используется при проведении сеанса экспертизы. Эксперт должен (на бумажной копии диаграммы) указать число замечаний, вычеркивая цифру из списка каждый раз при внесении нового замечания
Status	Статус отображает стадию создания диаграммы, отображая все этапы публикации
Working	Новая диаграмма, кардинально обновленная диаграмма или новый автор диаграммы
Draft	Диаграмма прошла первичную экспертизу и готова к дальнейшему обсуждению
Recommended	Диаграмма и все ее сопровождающие документы прошли экспертизу. Новых изменений не ожидается
Publication	Диаграмма готова к окончательной печати и публикации
Reader	Имя читателя (эксперта)
Date	Дата прочтения (экспертизы)
Context	Схема расположения работ в диаграмме верхнего уровня. Работа, являющаяся родительской, показана темным прямоугольником, остальные – светлым. На контекстной диаграмме (А-0) показана надпись ТОР. В левом нижнем углу показывается номер по узлу родительской диаграммы:

Слияние
и расщепление моделей

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

Таблица 7.2. Поля подвала каркаса (слева направо)
Поле	Смысл
Node	Номер узла диаграммы (номер родительской работы )
Title	Имя диаграммы. По умолчанию — имя родительской работы
Number	C-Number, уникальный номер версии диаграммы
Page	Номер страницы, может использоваться как номер страницы при формировании папки

BPwin
использует для слияния и разветвления
моделей стрелки вызова. Для слияния
необходимо выполнить следующие
условия:

• Обе
  сливаемые модели должны быть открыты
  в BPwin.

• Имя
  модели-источника, которое присоединяют
  к модели-цели, должно совпадать с
  именем стрелки
  вызова работы
  в модели-цели.

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

Рис.
7.33. 
Стрелка вызова работы «Сборка и
тестирование компьютеров»
модели-цели

• Имена
  контекстной работы
  подсоединяемой модели-источника и
  работы
  на модели-цели, к которой мы
  подсоединяем модель-источник, должны
  совпадать.

• Модель-источник
  должна иметь, по крайней мере, одну
  диаграмму декомпозиции.

Для
слияния моделей нужно щелкнуть
правой кнопкой мыши по работе со
стрелкой вызова в модели-цели и во
всплывающем меню выбрать пункт Merge
Model.

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

Рис.
7.34. 
Диалог Continue with merge

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

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

Разделение
моделей производится аналогично.
Для отщепления ветви от модели
следует щелкнуть правой кнопкой
мыши по декомпозированной работе (
работа не должна иметь диагональной
черты в левом верхнем углу) и выбрать
во всплывающем меню пункт Split Model. В
появившемся диалоге Split Options следует
указать имя создаваемой модели.
После подтверждения расщепления в
старой модели работа станет
недекомпозированной (признак —
диагональная черта в левом верхнем
углу), будет создана стрелка вызова,
ее имя будет совпадать с именем новой
модели, и, наконец, будет создана
новая модель, причем имя контекстной
работы будет совпадать с именем
работы, от которой была «оторвана»
декомпозиция.

Создание
отчетов в BPwin

BPwin
имеет мощный инструмент генерации
отчетов. Отчеты по модели вызываются
из пункта меню Report. Всего имеется
семь типов отчетов:

1. Model
   Report. Включает информацию о контексте
   модели — имя модели, точку зрения,
   область, цель, имя автора, дату
   создания и др.

2. Diagram
   Report. Отчет по конкретной диаграмме.
   Включает список объектов ( работ,
   стрелок, хранилищ данных, внешних
   ссылок и т. д.).

3. Diagram
   Object Report. Наиболее полный отчет по
   модели. Может включать полный список
   объектов модели ( работ,
   стрелок с указанием их типа и др.) и
   свойства, определяемые пользователем.

4. Activity
   Cost Report. Отчет о результатах стоимостного
   анализа. Будет рассмотрен ниже.

5. Arrow
   Report. Отчет по стрелкам.
   Может содержать информацию из
   словаря стрелок, информацию о
   работе-источнике, работе-назначении
   стрелки
   и информацию о разветвлении и слиянии
   стрелок.

6. Data
   Usage Report. Отчет о результатах связывания
   модели процессов и модели данных.
   (Будет рассмотрен ниже.)

7. Model
   Consistency Report. Отчет, содержащий список
   синтаксических ошибок модели.

1


Моделирование бизнес-процессов средствами BPwin Составитель: Шаповалова С.В.

2


Оглавление 1. Моделирование бизнес-процессов средствами BPwin Моделирование бизнес-процессов средствами BPwin 2. Инструментальная среда BPwin Инструментальная среда BPwin 3. Построение модели IDEF0Построение модели IDEF0 4. Модели AS-IS и ТО-ВЕМодели AS-IS и ТО-ВЕ 5. Диаграмма деревьев узлов Диаграмма деревьев узлов 6. Диаграммы «только для экспозиции» (FEO)Диаграммы «только для экспозиции» (FEO) 7. Слияние и расщепление моделей Слияние и расщепление моделей

3


11. Создание отчетов в BPwin Создание отчетов в BPwin 12. Стоимостный анализ Стоимостный анализ 13.Свойства, определяемые пользователем (UDP)Свойства, определяемые пользователем (UDP) 14. Диаграммы потоков данных Диаграммы потоков данных 15. Метод описания процессов IDEF3Метод описания процессов IDEF3 16. Организационные диаграммы и диаграммы Swim Lane Организационные диаграммы и диаграммы Swim Lane 17. Использование нетрадиционного синтаксиса на диаграммах функциональной модели Использование нетрадиционного синтаксиса на диаграммах функциональной модели 18. Декомпозиция работы IDEF0 в диаграмму DFDДекомпозиция работы IDEF0 в диаграмму DFD 19. Межстраничные ссылки (Off-Page Reference) и внешние сущности (External Reference) на диаграммах DFD и IDEFOМежстраничные ссылки (Off-Page Reference) и внешние сущности (External Reference) на диаграммах DFD и IDEFO 20. Декомпозиция работы IDEF0 или DFD в диаграмму IDEF3Декомпозиция работы IDEF0 или DFD в диаграмму IDEF3

4


Моделирование бизнес-процессов средствами BPwin BPwin поддерживает три методологии моделирования: функциональное моделирование (IDEF0); описание бизнес-процессов (IDEF3); диаграммы потоков данных (DFD).

5


Инструментальная среда BPwin При запуске BPwin по умолчанию появляется основная панель инструментов, палитра инструментов (вид которой зависит от выбранной нотации) и, в левой части, навигатор модели Model Explorer

6


При создании новой модели возникает диалог, в котором следует указать, будет ли создана модель заново или она будет открыта из файла либо из репозитория ModelMart, затем внести имя модели и выбрать методологию, в которой будет построена модель

7


В BPwin возможно построение смешанных моделей, т. е. модель может содержать одновременно диаграммы как IDEF0, так и IDEF3 и DFD. Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Работа изображается в виде прямоугольников, данные в виде стрелок. Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется контекстное меню, каждый пункт которого соответствует редактору какого-либо свойства объекта.

8


Построение модели IDEF0 Моделирование системы в IDEF0 начинается с создания контекстной диаграммы – наиболее абстрактного уровня описания системы в целом, содержащей определение субъекта моделирования, цели и точки зрения на модель. Под субъектом понимается сама система. Цель моделирования определяется из ответов на следующие вопросы: Почему этот процесс должен быть смоделирован? Что должна показывать модель? Что может получить клиент? Точка зрения должна соответствовать цели и границам моделирования. Как правило, выбирается точка зрения человека, ответственного за моделируемую работу в целом.

9


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

10


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

11


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

12


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

13


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

14


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

15


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

16


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

17


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

18


Для внесения имени работы следует щелкнуть по работе правой кнопкой мыши, выбрать в меню Name Editor и в появившемся диалоге внести имя работы.

19


Для описания других свойств работы служит диалог Activity Properties

20


Диаграммы декомпозиции содержат родственные работы, т. е. дочерние работы, имеющие общую родительскую работу. Для создания диаграммы декомпозиции следует щелкнуть по кнопке на панели инструментов. Возникает диалог Activity Box Count, в котором следует указать нотацию новой диаграммы (например, IDEF0) и количество работ на ней (допустимый интервал числа работ – 2-8).

21


Пример диаграммы декомпозиции

22


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

23


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

24


Стрелки(Arrow) описывают взаимодействие работ и представляют собой некую информацию, выраженную существительными.(Например, «Звонки клиентов», «Правила и процедуры», «Бухгалтерская система».) В IDEF0 различают пять типов стрелок: Вход(Input) материал или информация, которые используются или преобразуются работой для получения результата (выхода). Работа может не иметь ни одной стрелки входа. Стрелка входа рисуется как входящая в левую грань работы. Стрелки входа и выхода должны быть точно определены с тем, чтобы указать на то, что данные действительно были переработаны (например, на входе «карта пациента», а на выходе «Заполненная карта пациента»). Часто сложно определить, являются ли данные входом или управлением. Если они изменяются, то, скорее всего, это вход, если нет управление.

25


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

26


Выход(Output) материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка выхода рисуется как исходящая из правой грани работы. Control Input Output MechanismCall Другая модель работы

27


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

28


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

29


Граничные стрелки Стрелки на контекстной диаграмме (граничные) служат для описания взаимодействия системы с окружающим миром. Для внесения граничной стрелки входа следует: -щелкнуть по кнопке с символом стрелки в палитре инструментов; -перенести курсор к левой стороне экрана, до начальной штриховой полоски; -щелкнуть по полоске (откуда выходит стрелка) и еще раз в левой части работы со стороны входа (где заканчивается стрелка); В палитре инструментов выбрать опцию редактирования стрелки, щелкнуть правой кнопкой мыши на линии стрелки, во всплывающем меню выбрать Name и добавить имя стрелки в закладке Name диалога IDEF0 Arrow Properties.

30


Имена вновь внесенных стрелок автоматически заносятся в словарь Arrow Dictionary.

31


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

32


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

33


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

34


Диаграмма декомпозиции с несвязанными граничными стрелками

35


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

36


Связь по входу(output-input)

37


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

38


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

39


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

40


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

41


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

42


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

43


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

44


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

45


Для их «перетаскивания» наверх нужно щелкнуть правой кнопкой мыши по квадратным скобкам граничной стрелки и в контекстном меню выбрать команду Arrow Tunnel. Появляется диалог Border Arrow Editor. Если щелкнуть по кнопке Resolve Border Arrow, стрелка мигрирует на диаграмму верхнего уровня, если по кнопке Change To Tunnel – стрелка будет туннелирована и не попадет на другую диаграмму. Туннельная стрелка изображается с круглыми скобками на конце.

46


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

47


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

48


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

49


Нумерация работ и диаграмм Все работы модели нумеруются. Номер состоит из префикса и числа. Может быть использован любой префикс, но обычно используют префиксА. Контекстная (корневая) работа дерева имеет номер А0. Работы i декомпозиции А0 имеют номера А1, А2, A3 и т. д. Работы декомпозиции нижнего уровня имеют номер родительской работы и очередной порядковый номер, например работы декомпозиции A3 будут иметь номера А31, А32, АЗЗ, А34 и т. д.

50


Работы образуют иерархию, где каждая работа может иметь одну родительскую и несколько дочерних работ, образуя дерево. Такое дерево называют деревом узлов, а вышеописанную нумерацию нумерацией по узлам. Диаграммы IDEF0 имеют двойную нумерацию. Во-первых, диаграммы имеют номера по узлу. Контекстная диаграмма всегда имеет номер А- 0, декомпозиция контекстной диаграммы номер А0, остальные диаграммы декомпозиции номера по соответствующему узлу (например, A1, A2, А21, А213 и т. д.).

51


BPwin позволяет иметь в модели только одну диаграмму декомпозиции в данном узле. Прежние версии диаграммы можно хранить в виде бумажной копии либо как FEO-диаграмму. Следует отличать различные версии одной и той же диаграммы. Для этого существует специальный номер C- number, который должен присваиваться автором модели вручную. C-number это произвольная строка, номер состоит из буквенного префикса и порядкового номера (префикс –инициалы автора диаграммы, а порядковый номер отслеживается автором вручную, например МСВ00021 ).

52


Диаграмма деревьев узлов Показывает иерархию работ в модели и позволяет рассмотреть всю модель целиком, но не показывает взаимосвязи между работами. Процесс создания модели работ является итерационным, работы могут менять свое расположение в дереве узлов многократно. Чтобы не запутаться, следует после каждого изменения создавать диаграмму дерева узлов. BPwin имеет мощный инструмент навигации по модели Model Explorer, который позволяет представить иерархию работ и диаграмм в удобном и компактном виде.

53


Диаграмма дерева узлов

54


Для создания диаграммы дерева узлов следует выбрать в меню пункт Diagram/Add Node Tree. Возникает диалог формирования диаграммы дерева узлов Node Tree Definition Выбор команды для формирования диаграммы дерева узлов Диалог настройки диаграммы дерева узлов (шаг 1) Диалог настройки диаграммы дерева узлов (шаг 2)

55


Указать глубину дерева – Number of Levels (по умолчанию – 3) и корень дерева (по умолчанию – родительская работа текущей диаграммы). По умолчанию нижний уровень декомпозиции показывается в виде списка, остальные работы – в виде прямоугольников. Для отображения всего дерева в виде прямоугольников – выключить опцию Bullet Last Level. Указать имя диаграммы, т.к., если в нескольких диаграммах в качестве корня использовать одну и ту же работу, все эти диаграммы получат одинаковый номер (номер узла + постфикс N, например AON) и в списке открытых диаграмм (пункт меню Window) их можно будет различить только по имени.

56


Диаграммы «только для экспозиции» (FEO) Используются в модели для иллюстрации других точек зрения, для отображения отдельных деталей, которые не поддерживаются явно синтаксисом IDEF0. Диаграммы FEO позволяют нарушить любое синтаксическое правило, т.к. являются просто картинками – копиями стандартных диаграмм и не включаются в анализ синтаксиса. Для создания диаграммы FEO – выбрать пункт меню Diagram/Add FEO Diagram. В диалоге Add New FEO Diagram – указать имя диаграммы FEO и тип родительской диаграммы.

57


Новая диаграмма получает номер, который генерируется автоматически (номер родительской диаграммы по узлу + постфикс F, например A1F) Диалог создания FEO-диаграммы

58


Каркас диаграммы Граничные рамки называются каркасом диаграммы. Каркас содержит заголовок (верхняя часть рамки) и подвал (нижняя часть). Заголовок каркаса используется для отслеживания диаграммы в процессе моделирования. Нижняя часть используется для идентификации и позиционирования в иерархии диаграммы.

59


Значения полей каркаса задаются в диалоге Diagram Properties (меню Diagram /Diagram Properties)

60

61


Подвал каркаса

62


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

63


Для слияния и разветвления моделей используются стрелки вызова. Для слияния необходимо выполнить следующие условия: –Обе сливаемые модели должны быть открыты в BPwin. –Имя модели-источника, которое присоединяют к модели-цели, должно совпадать с именем стрелки вызова работы в модели-цели. –Стрелка вызова должна исходить из недекомпозируемой работы (работа должна иметь диагональную черту в левом верхнем углу) –Имена контекстной работы подсоединяемой модели- источника и работы на модели-цели, к которой мы подсоединяем модель-источник, должны совпадать. –Модель-источник должна иметь, по крайней мере, одну диаграмму декомпозиции.

64


Стрелка вызова работы «Сборка и тестирование компьютеров» модели-цели

65


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

66


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

67


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

68


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

69


Создание отчетов в BPwin BPwin имеет мощный инструмент генерации отчетов. Отчеты вызываются из пункта меню Report. Всего имеется 7 типов отчетов: 1. Model Report. Информация о контексте модели имя модели, точка зрения, область, цель, имя автора, дата создания и др. 2. Diagram Report. Отчет по конкретной диаграмме. Список объектов (работ, стрелок, хранилищ данных, внешних ссылок и т. д.). 3. Diagram Object Report. Наиболее полный отчет по модели. Полный список объектов модели (работ, стрелок с указанием их типа и др.) и свойства, определяемые пользователем.

70


4. Activity Cost Report. Отчет о результатах стоимостного анализа. Arrow Report. 5. Отчет по стрелкам. Может содержать информацию из словаря стрелок, информацию о работе-источнике, работе-назначении стрелки и информацию о разветвлении и слиянии стрелок. 6. Data Usage Report. Отчет о результатах связывания модели процессов и модели данных. (Будет рассмотрен ниже.) 7. Model Consistency Report. Отчет, содержащий список синтаксических ошибок модели.

71


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

72


BPwin предоставляет два инструмента для оценки модели стоимостный анализ, основанный на работах (Activity Based Costing, ABC), и свойства, определяемые пользователем (User Defined Properties, UDP). Функциональное оценивание (ABC) – это технология выявления и исследования стоимости выполнения той или иной функции (действия). Исходными данными для функционального оценивания являются затраты на ресурсы (материалы, персонал и т.д.). Стоимостный анализ – соглашение об учете, для сбора затрат, связанных с работами, с целью определить общую стоимость процесса. Стоимостный анализ основан на модели работ. ABC применяется для того, чтобы понять происхождение выходных затрат и облегчить выбор нужной модели работ при реорганизации деятельности предприятия (Business Process Reengineering, BPR).

73


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

74


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

75


ABC включает следующие основные понятия: Объект затрат – причина, по которой работа выполняется, обычно основной выход работы. Стоимость работ есть суммарная стоимость объектов затрат; Двигатель затрат характеристики входов и управлений работы, которые влияют на то, как выполняется и как долго длится работа; Центры затрат, которые можно трактовать как статьи расхода.

76


Сначала задаются единицы измерения времени и денег. Для этого следует вызвать диалог Model Properties (меню Model), закладка ABC Units. Если в списке отсутствует необходимая валюта (например, рубль), ее можно добавить. Диапазон измерения времени в списке Unit of measurment достаточен для большинства случаев – от секунд до лет.

77


Затем описываются центры затрат (cost centers). Для внесения центров затрат необходимо вызвать диалог Cost Center Editor из меню Model

78


Каждому центру затрат следует дать подробное описание в окне Definition. Порядок в списке можно менять при помощи стрелок, расположенных справа от списка. Задание последовательности центров затрат в списке –во-первых, облегчает последующую работу при присвоении стоимости работам, –во-вторых, имеет значение при использовании единых стандартных отчетов в разных моделях. Информация о центрах затрат и UDP сохраняется в BPwin в виде указателей, т. е. хранятся не названия центров затрат, а их номера. Поэтому, если нужно использовать один и тот же стандартный отчет в разных моделях, списки центров затрат должны быть в них одинаковы

79


Для задания стоимости работы следует щелкнуть правой кнопкой мыши по работе и на всплывающем меню выбрать Cost. В диалоге Activity Cost указывается частота проведения данной работы в рамках общего процесса (окно Frequency) и продолжительность (Duration). Затем следует выбрать в списке один из центров затрат и в окне Cost задать его стоимость. Аналогично назначаются суммы по каждому центру затрат, т. е. задается стоимость каждой работы по каждой статье расхода. Если возникает необходимость внесения дополнительных центров затрат, диалог Cost Center Editor вызывается прямо из диалога Activity Properties/Cost соответствующей кнопкой.

80


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

81


Если во всех работах модели включен режим Compute from Decompositions, то вычисления автоматически проводятся по всей иерархии работ снизу вверх

82


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

83


Для более тонкого анализа можно использовать EasyABC (ABC Technology, Inc.). BPwin имеет двунаправленный интерфейс с EasyABC. Для экспорта данных в EasyABC следует – выбрать пункт меню File/Export/Node Tree, задать в диалоге Export Node Tree необходимые настройки и экспортировать дерево узлов в текстовый файл (.txt). Файл экспорта можно импортировать в EasyABC. Результирующие данные можно импортировать из EasyABC в BPwin. Для импорта – выбрать меню File/Import/Costs и в диалоге Import Activity Costs выбрать необходимые установки.

84


Отчет позволяет документировать имя, номер, определение и стоимость работ, как суммарную, так и раздельно по центрам затрат. Результаты стоимостного анализа представляются в отчете BPwin, настройка которого производится в диалоговом окне Activity Cost Report (меню Tools/Reports/Activity Cost Report).

85


Свойства, определяемые пользователем (UDP) UDP позволяют провести дополнительный анализ, хотя и без суммирующих подсчетов. Для описания UDP служит диалог User-Defined Property Editor (меню Model/UDP Definition Editor). В верхнем окне диалога вносится имя UDP, в списке выбора Datatype описывается тип свойства. Можно задать 18 различных типов UDP, в том числе управляющих команд и массивов, объединенных по категориям.

86


Для внесения категории – задать имя категории в окне New Keyword и щелкнуть по кнопке Add Category. Для присвоения свойства категории – выбрать UDP из списка, затем категорию из списка категорий и щелкнуть по кнопке Update. Одна категория может объединять несколько свойств, а одно свойство может входить в несколько категорий. Свойство List может содержать массив предварительно определенных значений. Для определения области значений UDP типа List – задать значение свойства в окне New Keyword и щелкнуть по кнопке Add Member.

87


Каждой работе можно поставить в соответствие набор UDP. Для этого – щелкнуть правой кнопкой мыши по работе и выбрать пункт меню UDP. В закладке UDP Values диалога IDEF0 Activity Properties можно задать значения UDP. Результат можно проанализировать в отчете Diagram Object Report (меню Tools/Report/Diagram Object Report).

88


Диалог настройки отчета Diagram Object Report

89


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

90


Основные компоненты DFD – процессы или работы, внешние сущности, потоки данных, накопители данных (хранилища). В BPwin для построения диаграмм потоков данных используется нотация Гейна-Сарсона. Для того чтобы дополнить модель IDEF0 диаграммой DFD, нужно в процессе декомпозиции в диалоге Activity Box Count «кликнуть» по радио-кнопке DFD.

91


В палитре инструментов на новой диаграмме DFD появляются новые кнопки: (External Reference) – добавить в диаграмму внешнюю ссылку; (Data store) – добавить в диаграмму хранилище данных; Diagram Dictionary Editor – ссылка на другую страницу. В отличие от IDEF0 этот инструмент позволяет направить стрелку на любую диаграмму (а не только на верхний уровень).

92


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

93


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

94


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

95


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

96


В DFD номер каждой работы может включать префикс, номер родительской работы (А) и номер объекта. Номер объекта это уникальный номер работы на диаграмме. Например, работа может иметь номер А Уникальный номер имеют хранилища данных и внешние сущности независимо от их расположения на диаграмме. Каждое хранилище данных имеет префикс D и уникальный номер, например D5. Каждая внешняя сущность имеет префикс Е и уникальный номер, например Е5.

97


Метод описания процессов IDEF3 Для описания логики взаимодействия информационных потоков подходит IDEF3 (workflow diagram). Диаграммы Workflow используются для анализа завершенности процедур обработки информации. С их помощью можно описывать сценарии действий сотрудников организации. Каждый сценарий сопровождается описанием процесса и может быть использован для документирования каждой функции. IDEF3 дает возможность аналитикам описать ситуацию, когда процессы выполняются в определенной последовательности, а также описать объекты, участвующие совместно в одном процессе.

98


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

99


Единицы работы – Unit of Work (UOW) – называемые работами (activity) – центральный компонент модели. Идентификатор работы присваивается при создании и не меняется никогда. Даже если работа будет удалена, ее идентификатор не будет вновь использоваться для других работ. Обычно номер работы состоит из номера родительской работы и порядкового номера на текущей диаграмме. Связи – взаимоотношения работ. Все связи в IDEF3 однонаправлены и могут быть направлены куда угодно, но рекомендуется, чтобы связи были направлены слева направо.

100


В IDEF3 различают три типа стрелок, изображающих связи, стиль которых устанавливается через меню Edit/Arrow Style: Старшая (Precedence) – сплошная линия, связывающая единицы работ (UOW). Рисуется слева направо или сверху вниз, показывает, что работа-источник должна закончиться прежде, чем работа-цель начнется. Отношения (Relational Link) – пунктирная линия, изображает связи между единицами работ (UOW) а также между единицами работ и объектами ссылок. Потоки объектов (Object Flow) – стрелка с двумя наконечниками, применяется для описания того факта, что объект используется в двух или более единицах работы, например, когда объект порождается в одной работе и используется в другой.

101


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

102


Для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы, используются перекрестки (Junction). Различают перекрестки для слияния (Fan-in Junction) и разветвления стрелок (Fan-out Junction). Перекресток не может использоваться одновременно для слияния и для разветвления. Для внесения перекрестка служит кнопка (добавить в диаграмму перекресток Junction) в палитре инструментов. В диалоге Select Junction Type необходимо указать тип перекрестка.

103


Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. В отличие от IDEF0 и DFD в IDEF3 стрелки могут сливаться и разветвляться только через перекрестки Обозначение Наименов ание Смысл в случае слияния стрелок (Fan-in Junction) Смысл в случае разветвления стрелок — (Fanout Junction) Asynchro nous AND Все предшествующиепроцессы должны быть завершены Все следующиепроцессы должны быть запущены Synchron ous AND Все предшествующиепроцессы завершены одновременно Все следующиепроцессы запускаются одновременно Asynchro nous OR Один или несколько предшествующихпроцессов должны быть завершены Один или несколько следующихпроцессов должны быть запущены Synchron ous OR Один или несколько предшествующихпроцессов завершены одновременно Один или несколько следующихпроцессов запускаются одновременно XOR (Exclusive OR) Только один предшествующий процесс завершен Только один следующийпроцесс запускается Типы перекрестков

104


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

105


Спецификация IDEF3 различает три стиля объектов ссылок безусловные (unconditional), синхронные (synchronous) и асинхронные (asynchronous). BPwin поддерживает только безусловные объекты ссылок. Синхронные и асинхронные объекты ссылок, используемые в диаграммах переходов состояний объектов, не поддерживаются. При внесении объектов ссылок помимо имени следует указывать тип объекта ссылки.

106

107


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

108


Организационные диаграммы и диаграммы Swim Lane BPwin 4.1 содержит средства для моделирования организационной структуры предприятия. BPwin 4.1 содержит четыре новых словаря — словарь изображений (bitmap), словарь ресурсов, словарь ролей и словарь групп ролей. Словарь изображений служит для импорта файлов в формате bmp в модель. Импортированные изображения можно использовать в диаграммах для улучшения их внешнего вида.

109


Для импорта изображения следует перейти в меню Dictionary/Bitmaps. Появляется диалог Bitmap Dictionary, в котором следует щелкнуть по кнопке Import и найти файл формата bmp.

110


Словарь Role Group Dictionary (меню Dictionary/Role Group) позволяет создать и определить свойства групп ролей. Группы ролей могут использоваться как на организационных диаграммах, так и на диаграммах Swim Lane. В качестве значения группы ролей может быть название предприятия, отдела, цеха или название региона, города и т. д.

111


Для каждой группы ролей может быть внесено описание, указано изображение, предварительно импортированное в словаре изображений, и указана важность группы ролей. Словарь ролей вызывается из меню Dictionary/Role

112


Ролью может быть должность или позиция конкретного исполнителя. Каждой роли может соответствовать одна или несколько групп ролей. В словаре ролей для каждой роли можно внести определение (Definition), связать роль с изображением (Bitmap) и геометрической фигурой (Shape), указать важность роли (Importance). Словарь ресурсов (меню Dictionary/Resource позволяет создать ресурс и связать его с комбинацией «группа ролей/роль». Ресурсом для роли может быть конкретный исполнитель. В качестве значения ресурса, например, можно использовать фамилию и имя сотрудника.

113


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

114


Для создания организационной диаграммы следует выбрать меню Diagram/Add Organization Chart. Появляется гид Diagram/Add Organization Chart. В первом диалоге гида следует внести название и имя автора диаграммы, группу ролей и роль для верхнего уровня иерархического дерева.

115


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

116


Третий диалог, Organization Chart предназначен для изменения свойств организационной диаграммы. В группе Drawing можно указать, какая именно информация будет отображаться на блоках диаграммы (наименование блока, имя группы ролей роль и ресурс). Для отображения иконок на диаграмме в группе Draw Style следует выбрать опцию Bitmap.

117


После щелчка по кнопке «Готово» создается организационная диаграмма. Для дополнения диаграммы следует щелкнуть правой кнопкой мыши по блоку и выбрать в контекстном меню один из пунктов: Edit subordinate list – редактирование блока; Add subordinates – добавляет нижний уровень; Add sibling on left – добавляет блок на текущий уровень слева от редактируемого блока; Add sibling on right – добавляет блок на текущий уровень справа от редактируемого блока.

118

119


Созданные в словаре Role Dictionary роли могут быть использованы в диаграмме Swim Lane. Диаграмма Swim Lane является разновидностью диаграммы IDEF3, позволяющей явно описать роли и ответственности исполнителей в конкретной технологической операции. Эта диаграмма разделена на горизонтальные полосы, с каждой полосой может быть связана роль или UDP типа Text List. Полоса может содержать объекты диаграммы IDEF3 (UOW, перекрестки и объекты ссылок), относящиеся к соответствующей роли.

120


Для создания диаграммы Swim Lane следует выбрать меню Diagram/Add Swim Lane diagram. Появляется гид Swim Lane diagram Wizard. В первом диалоге гида следует внести название и имя автора диаграммы, выбрать имя и номер диаграммы IDEF3, на основе которой будет построена диаграмма, и группу ролей, из которой можно будет выбрать роли, связанные с диаграммой.

121


Во втором диалоге гида следует выбрать роли, на основе которых будет создана диаграмма. Диаграмма будет разделена на количество полос, указанных в колонке Display Swim Line. После щелчка по кнопке «Готово» создается новая диаграмма, все объекты которой расположены произвольно. Расположить объекты на полосах, соответствующих ролям, следует вручную.

122


Диаграмма Swim Lane

123


Использование нетрадиционного синтаксиса на диаграммах функциональной модели BPwin 4.1 позволяет нарушить традиционный синтаксис нотаций IDEFO, IDEF3 и DFD и использовать для работы не прямоугольники, а практически любые геометрические фигуры. Кроме того, можно разместить на работе изображение, импортированное в словарь Bitmap Dictionary. Для использования нетрадиционного синтаксиса необходимо щелкнуть по работе и выбрать в контекстном меню пункт Box Style.

124


Во вкладке Box Style следует выбрать опцию Custom и указать геометрическую фигуру (Shape) и изображение (Bitmap).

125


После щелчка по кнопке ОК на диаграмме работа отображается в нетрадиционном синтаксисе. Использование нетрадиционного синтаксиса может быть полезно при решении ряда задач, например, при преобразовании диаграммы IDEF3 в имитационную модель Arena Изображение элемента диаграммы в виде звездочки

126


Диаграмма IDEF3, выполненная в синтаксисе имитационной модели Arena

127


В результате дополнения диаграмм IDEF0 диаграммами DFD и IDEF3 может быть создана смешанная модель, которая наилучшим образом описывает все стороны деятельности предприятия. Иерархию работ в смешанной модели можно увидеть в окне Model Explorer. Модели в нотации IDEF0 изображаются зеленым цветом, в IDEF3 – желтым, в DFD –голубым.

128


BPwin допускает следующие переходы с одной нотации на другую: IDEF0 -> DFD; IDEF0 -> IDEF3; DFD -> IDEF3. Декомпозировать работу DFD на диаграмму IDEF0 нельзя, так же как декомпозировать работу IDEF3 на диаграмму любой другой нотации.

129


Декомпозиция работы IDEF0 в диаграмму DFD Для создания дочерней диаграммы DFD следует при декомпозиции в диалоге Activity Box Count выбрать радиокнопку DFD. Создается новая диаграмма DFD, и стрелки, которые касаются родительской работы, мигрируют на диаграмму нижнего уровня так, как если бы это была диаграмма IDEF0.

130


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

131


Нотация DFD не включает понятия «управление» и «механизм» и можно создавать внутренние стрелки исходящими из любой грани работы и входящими в любую грань, BPwin не позволяет связать граничные стрелки на диаграмме DFD произвольным образом. Стрелки можно связать только так, как если бы это была диаграмма IDEF0, т. е. входящую с верхней грани диаграммы стрелку — только к верхней грани работы и т. д. Согласно нотации DFD диаграмма не должна иметь граничных стрелок – все стрелки должны начинаться и заканчиваться на работах, хранилищах данных или внешних сущностях.

132


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

133


Замена граничных стрелок внутренними на диаграмме DFD

134


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

135


Межстраничные ссылки (Off-Page Reference) и внешние сущности (External Reference) на диаграммах DFD и IDEFO Нотация DFD включает межстраничные ссылки – инструмент, позволяющий описать переход стрелки (т. е. передачу данных или объектов) с одной диаграммы на другую. Для ее создания на диаграмме DFD следует создать новую граничную стрелку. У границы диаграммы эта стрелка будет помечена квадратными скобками, так же как неразрешенная стрелка на диаграмме IDEF0.

136


Затем следует щелкнуть правой кнопкой мыши по квадратным скобкам и выбрать в контекстном меню пункт Off-Page Reference. Появляется диалог Off-Page Arrow Reference. В нем необходимо указать диаграмму, на которую будет направлена стрелка, и, если это диаграмма в нотации IDEF0, границу, от которой будет исходить стрелка (Destination border).

137


В результате будет создана межстраничная ссылка как на диаграмме-источнике, так и на диаграмме-назначении. Межстраничная ссылка может быть помечена как C-number диаграммы, как номер диаграммы по узлу или как имя диаграммы. Для изменения метки следует перейти в меню Model/Model Properties и во вкладке Display диалога Model Properties и в группе (Off-Page Reference label выбрать нужную опцию. BPwin позволяет создать на границе диаграммы не только межстраничную ссылку, но и внешнюю сущность и тоннель.

138


Для создания внешней сущности на диаграмме DFD следует создать новую граничную стрелку (у границы диаграммы эта стрелка будет помечена квадратными скобками). Затем следует щелкнуть правой кнопкой мыши по квадратным скобкам и выбрать в контекстном меню пункт External Reference. Далее в диалоге External Reference надо выбрать имя внешней сущности или внести это имя. На диаграмме DFD можно также создать тоннельную стрелку, хотя нотация DFD не предусматривает создания такого элемента.

139


В результате BPwin позволяет создавать на диаграмме DFD четыре типа граничных стрелок (рис , сверху вниз): –обычная граничная стрелка (не допускается нотацией DFD); –межстраничная ссылка; –тоннельная стрелка (не предусмотрена нотацией DFD); –внешняя ссылка.

140


Граничные стрелки на диаграмме DFD Граничные стрелки на диаграмме IDEF0 Пример диаграмм с граничными стрелками

141


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

142


Декомпозиция работы IDEF0 или DFD в диаграмму IDEF3 Стрелки на диаграммах IDEF0 и DFD означают потоки информации или объектов, передаваемых от одной работы к другой. На диаграммах IDEF3 стрелки показывают только последовательность выполнения работ, т. е. имеют иной смысл, нежели стрелки IDEF0 и DFD. Поэтому при декомпозиции работы IDEF0 или DFD в IDEF3 стрелки не мигрируют на нижний уровень. Если необходимо показать на IDEF3 те же объекты, что и на родительских диаграммах IDEF3 или DFD, используются объекты ссылки (referent).

143


Фрагмент дочерней диаграммы IDEF3 Фрагмент родительской диаграммы IDEF0

144


Литература 1. Вендров А.М. Проектирование программного обеспечения экономических информационных систем М: «Финансы и статистика», Проектирование информационных систем М: «Компьютер Пресс», 9, Колтунова Е. Требования к информационной системе и модели жизненного цикла Требования к информационной системе и модели жизненного цикла 4. Автоматизированные Системы Стадии создания. ГОСТ Комплекс стандартов на автоматизированные системы ИПК издательство стандартов ISO/IEC 12207: Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя: Пер. с англ. М.: ДМК, Thiele D. Life cycle management using life cycle process standards. Abstract. Life cycle management using life cycle process standards. Abstract. 8. Козленко Л. Проектирование информационных систем. Проектирование информационных систем.

145


9.Clegg, Dai and Richard Barker Case Method Fast-track: A RAD Approach Adison-Wesley, Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем М.: Финансы и статистика, Построение и совершенствование систем управления.Построение и совершенствование систем управления. 12. Елиферов В.Г., Репин В.В. Бизнес-процессы: регламентация и управление М.: ИНФРА-М, Основы организационного бизнеса ( , Эмитент. Существенные факторы, события, действия) 14. Кондратьев В.В., Краснова В.Б. Модульная программа для менеджеров. Реструктуризация управления компанией М.: Инфра-М, Калянов Г.Н. Теория и практика реорганизации бизнес-процессов М.: СИНТЕГ, Калянов Г.Н. Структурный системный анализ М.: Лори, 1996

146


17. Калянов Г.Н. Структурный системный анализ М.: Лори, Марка Д.А., Мак Гоуэн К. SADT методология структурного анализа и проектирования М.: Метатехнология, Маклаков С.В. Создание информационных систем с AllFusion Modelling Suite М.: Диалог-МИФИ, Черемных С.В., Ручкин В.С., Семенов И.О. Структурный анализ систем. IDEF-технологии М.: Финансы и статистика, Смирнова Г.Н.,Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем. Учебник М.: «Финансы и статистика», ГОСТ Единая система классификации и кодирования технико- экономической информации М.: Изд. стандартов, Маклаков С.В. Создание информационных систем с AllFusion Modelling Suite М.: Диалог-МИФИ, Буч Г. Объектно-ориентированное проектирование с примерами применения М.: Конкорд, Нейбург Э. Д., Максимчук Р.А. Проектирование баз данных с помощью UML М.: Издательский дом «Вильямс», 2002