«Моделирование бизнес-процессов с BPwin 4.0»

Моделирование бизнес-процессов с BPwin 4.0

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

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

Сергей Владимирович Маклаков

Москва

"ДИАЛОГМИФИ"

2002

Предисловие

В 1998 году вышла книга автора, посвященная инструментальным средствам системного анализа и проектирования информационных систем -BPwin и ERwin. (Маклаков С. BPwin и ERwin. CASE-средства разработки информационных систем. М: Диалог-МИФИ). Книга выдержала два издания и пользовалась популярностью среди специалистов в области информационных технологий. BPwin является средством, которое позволяет облегчить проведение обследования предприятия, построить функциональные модели и в дальнейшем с их помощью проанализировать и улучшить бизнес-процессы. Этот инструмент используют в основном системные аналитики и специалисты по внедрению информационных систем. ERwin предназначен для другого круга задач и для специалистов другого профиля - это система проектирования баз данных.

Многочисленные пожелания читателей и выход новой версии продукта фирмы Computer Associater - BPwin 4.0 побудили автора написать книгу, целиком посвященную BPwin и предназначенную для специалистов, задачей которых является создание функциональных моделей и реинжиниринг бизнес-процессов.

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

Книга состоит из четырех глав.

Гл. 1 посвящена изложению основ методологии функционального моделирования и построению моделей IDEFO, IDEF3 и DFD с помощью BPwin 4.O. В ней также рассматривается стоимостный анализ и основы имитационного моделирования.

В гл. 2 излагаются принципы построения отчетов на основе информации функциональной модели. Рассматриваются как встроенные средства BPwin 4.0, предназначенные для создания отчетов, так и использование генератора отчетов Crystal Reports.

В гл. 3 вводится понятие модели данных. Рассматривается связывание модели данных и функциональной модели с помощью BPwin 4.0 и ERwin 4.0.

Гл. 4 состоит из 16 упражнений и представляет собой практикум по созданию функциональной модели.

Автор приносит благодарность фирме "Интерфейс Ltd." () за возможность использования лицензионных программных средств.

Особую признательность автор выражает своей жене Елене за помощь в оформлении рукописи.

Введение

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

Что происходит на предприятии? Прежде чем пытаться улучшить деятельность предприятия, выбрать, а затем внедрить информационную систему, необходимо проанализировать, как работает предприятие в настоящее время. Для анализа необходимо знать не только как работает предприятие в целом, как оно взаимодействует с внешними организациями, заказчиками и поставщиками, но и как организована деятельность на каждом рабочем месте. Один человек, как правило, не обладает такой информацией. Действительно, руководитель предприятия хорошо разбирается, как работает организация в целом, но не в состоянии знать особенности деятельности всех рядовых сотрудников. Рядовой сотрудник хорошо разбирается в своих обязанностях, но плохо знает, как работают его коллеги. Следовательно, для анализа деятельности предприятия следует собрать знания множества в едином месте - создать модель деятельности предприятия. Многие корпоративные информационные системы зарубежных производителей (SAP R/3, BAAN, ROSS iRenaissance и др.) имеют в своем составе специальные средства (поддерживающие оригинальные методики), с помощью которых можно обследовать предприятия и построить модель их деятельности, однако существуют стандартизированные, опробованные в течение многих лет методологии и инструментальные средства. Наиболее известной и распространенной является предложенная в 70-х годах Дугласом Россом (Douglas Ross) методология структурного анализа SADT (Structured Analysis and Design Technique).

В начале 90-х годов в США на основе SADT был принят стандарт моделирования бизнес-процессов IDEF0 (). IDEFO является независимым от частных организаций стандартом и получил чрезвычайно широкое распространение, он принят в качестве стандарта в нескольких международных организациях, в том числе в НАТО и МВФ. BPwin 4.0 является инструментальным средством, полностью поддерживающим стандарт IDEF0.

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

Затем общая функция разбивается на крупные подфункции. Этот процесс называется функциональной декомпозицией. Затем каждая подфункция декомпозируется на более мелкие - и так далее до достижения необходимой детализации описания. На рис. 1 показано дерево функций, называемое деревом узлов функциональной модели.

Рис. 1. Пример декомпозиции - диаграмма дерева узлов функциональной модели

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

Работы на диаграммах изображаются в виде прямоугольников (функциональные блоки). Каждая работа изображает какую-либо функцию или работу и именуется глаголом или глагольной фразой, обозначающей действие, например "Изготовление изделия", "Обслуживание клиента" и т. д. Стрелки помечаются существительным и обозначают объекты или информацию, связывающую работы между собой и с внешним миром. В отличие от моделей, отображающих структуру организации, работа на диаграмме верхнего уровня в функциональной модели - это не элемент управления нижестоящими работами. Работы нижнего уровня - это то же самое, что работа верхнего уровня, но в более детальном изложении. После каждого сеанса декомпозиции автором диаграммы формируется папка -набор документов, в который входит сама диаграмма, дополнительные отчеты и т. д. Папка направляется эксперту предметной области (т. е. человеку, хорошо разбирающемуся в моделируемом фрагменте деятельности предприятия) для проведения экспертизы. На уровне контекстной диаграммы это может быть управляющий предприятия, на уровне первой декомпозиции - начальник отдела и т. д., вплоть до рядового исполнителя. Прежде чем декомпозировать далее, на текущем уровне необходимо внести в диаграмму все замечания экспертов. Таким образом, каждый из экспертов дополняет модель в той ее части, в которой он наиболее компетентен. В результате получается полностью адекватная системе модель, которая позволяет наглядно представить существующие недостатки, перенаправить и усовершенствовать бизнес-процессы, провести анализ стоимости производства, а также послужить основой для создания информационной системы. BPwin позволяет создавать модели процессов и поддерживает в одной модели в дополнение к IDEF0 еще два стандарта (нотации) моделирования - DFD и IDEF3. Каждая из этих трех нотаций позволяет рассмотреть различные стороны деятельности предприятия. Диаграммы IDEF0 предназначены для описания бизнес-процессов на предприятии, они позволяют понять, какие объекты или информация служат сырьем для процессов, какие результаты производят работы, что является управляющими факторами и какие ресурсы для этого необходимы. Нотация IDEF0 позволяет выявить формальные недостатки бизнес-процессов, что существенно облегчает анализ деятельности предприятия. Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. Для описания логики взаимодействия информационных потоков более подходит IDEF3, называемая также workflow diagramming - нотацией моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов.

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

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

Рис. 2. Построение моделей ТО-ВЕ как результат анализа модели AS-IS

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

BPwin предоставляет аналитику два инструмента для оценки модели -стоимостный анализ, основанный на работах (Activity Based Costing, ABC), и свойства, определяемые пользователем (User Defined Properties, UDP). ABC является широко распространенной методикой, используемой международными корпорациями и государственными организациями для идентификации движителей затрат в организации. Стоимостный анализ представляет собой соглашение об учете, используемое для сбора затрат, связанных с работами, с целью определить общую стоимость процесса. Стоимостный анализ основан на модели работ, поскольку количественная оценка невозможна без детального понимания функциональности предприятия. Обычно ABC применяется для того, чтобы понять происхождение затрат и облегчить выбор нужной модели работ при реорганизации деятельности предприятия (Business Process Re-engineering, BPR). С помощью стоимостного анализа можно решить такие задачи, как определение действительной стоимости производства продукта, определение действительной стоимости поддержки клиента, идентификация работ, которые стоят больше всего (те, которые должны быть улучшены в первую очередь), и др. в каждой из моделей AS-IS и ТО-ВЕ. Следовательно, стоимостный анализ позволяет оценить, каковы будут последствия внедрения информационной системы, действительно ли это приведет к повышению производительности и экономическому эффекту и к какому именно.

BPwin позволяет делать достаточно эффективные оценки стоимости, но при этом не претендует на высокую точность таких оценок. Для точных вычислений затрат можно воспользоваться специализированным средством тоимостного анализа EasyABC. BPwin поддерживает двунаправленный экспорт - импорт в EasyABC (рис. 3). Результаты стоимостного анализа наглядно представляются на специальном отчете BPwin - ABC. ABC позволяет оценить стоимостные и временные характеристики системы. Если стоимостных показателей недостаточно, имеется возможность внесения собственных метрик - свойств, определенных пользователем UDP.

Рис. 3. Общая схема взаимодействия BPwin с программными продуктами Computer Associates и других фирм

В какую сумму обойдется внедрение информационной системы?

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

Поддерживает ли структура данных информационной системы деятельность предприятия? Ответ на этот вопрос возможен, если предприятие самостоятельно разрабатывает информационную систему или структура данных приобретаемой информационной системы открыта и документирована. База данных должна полностью обеспечивать каждую функцию предприятия. Для того чтобы убедиться в этом, структура данных должна быть связана с функциональной моделью. Модель данных может быть создана вновь или воссоздана из существующей информационной системы с помощью ERwin 4.0 (фирма Computer Associates) - системы проектирования данных.

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

Стрелки в функциональной модели BPwin обозначают некоторую информацию, использующуюся в моделируемой системе. В ERwin на логическом уровне модели данных информация отображается в виде сущностей (соответствуют таблицам на физическом уровне), состоящих из атрибутов сущностей (соответствуют колонкам таблицы). Сущности состоят из совокупности отдельных записей — экземпляров сущностей (соответствуют записям в таблице). К модели данных предъявляются определенные требования (нормализация данных), которые призваны обеспечить компактность и непротиворечивость хранения данных. Основная идея нормализации данных - каждый факт должен храниться в одном месте. Это приводит к тому, что информация, которая моделируется в виде одной стрелки в функциональной модели, может содержаться в нескольких сущностях и атрибутах в модели данных. Кроме того, на диаграмме функциональной модели могут присутствовать различные стрелки, изображающие одни и те же данные, но на разных этапах обработки (например, необработанные детали - обработанные детали - собранное изделие). Информация о таких стрелках находится в одних и тех же сущностях. Следовательно, одной и той же стрелке в функциональной модели могут соответствовать несколько сущностей в модели данных и, наоборот, одной сущности может соответствовать несколько стрелок.

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

Поддерживает ли функциональность информационной системы деятельность предприятия? Разработчики информационных систем в процессе создания программного обеспечения сталкиваются с целым рядом трудновыполнимых задач. Работая с объектно-ориентированными технологиями создания приложений, они создают клиент-серверные приложения, которые должны удовлетворять требованиям надежности, управляемости и высокой производительности. Решение этих задач возможно только в условиях высокоэффективного анализа и проектирования. С одной стороны, BPwin позволяет построить адекватную модель (модель работ) существующих на предприятии процессов (AS-IS), проанализировать эту модель и построить модель будущих процессов (ТО-ВЕ). С другой стороны, разработчики, использующие такие средства объектно-ориентированного анализа и проектирования, как Rational Rose фирмы Rational Software или Paradigm Plus фирмы Computer Associates, могут описать функциональность информационной системы при помощи диаграмм Use Cases (диаграммы Use Cases являются составной частью объектно-ориентированного языка моделирования информационных систем UML, Unified Modeling Language). Бизнес-процессы современных предприятий и организаций весьма сложны. В результате анализа могут быть описаны работы (activity) и функции (use case), информация о которых получена из самых разных источников, поэтому необходима синхронизация работ и функций. Такая синхронизация позволяет выявить соответствие информационной системы реальным бизнес-процессам предприятия, выяснить, действительно ли внедряемая корпоративная информационная система обеспечит поддержку деятельности предприятия.

BPwin 4.0 позволяет связать модели процессов с объектной моделью Paradigm Plus 4.0 (см. рис. 3). Целью интеграции моделей Paradigm Plus и BPwin является установление логической связи между работами (activity) и функциями (use case), что позволяет создать единую технологическую цепочку от анализа бизнес-процессов до генерации кода приложений, включая описание требований к приложению.

Организация коллективной работы.

Создание и внедрение современных информационных систем, основанных на широком использовании распределенных вычислений, объединении традиционных и новейших информационных технологий, требует тесного взаимодействия всех участников проекта: менеджеров, бизнес-аналитиков и системных аналитиков, администраторов баз данных, разработчиков. Для этого использующиеся на разных этапах и разными специалистами средства моделирования и разработки должны быть объединены общей системой организации совместной работы. Для организации коллективной работы BPwin способен взаимодействовать с Mode] Mart (фирма Computer Associates) - хранилищем моделей, к которому открыт доступ для участников проекта (см. рис. 3). Model Mart удовлетворяет всем требованиям, предъявляемым к средствам организации коллективной работы, а именно:

1. Совместному моделированию. Каждый участник проекта имеет инструмент поиска и доступа к интересующей его модели в любое время. При совместной работе используются три режима: незащищенный, защищенный и режим просмотра. В режиме просмотра запрещается любое изменение моделей. В защищенном режиме модель, с которой работает один пользователь, не может быть изменена другими пользователями. В незащищенном режиме пользователи могут работать с общими моделями в реальном масштабе времени. Возникающие при этом конфликты разрешаются при помощи специального модуля - Intelligent Conflict Resolution (ICR). В дополнение к стандартным средствам организации совместной работы Model Mart позволяет сохранять множество версий, снабженных аннотациями, с последующим сравнением предыдущих и новых версий. При необходимости возможен возврат к предыдущим версиям.

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

Архитектуре Model Mart, которая реализована на архитектуре клиент- сервер. В качестве платформы реализации хранилища выбраны РСУБД Sybase, Microsoft SQL Server, Informix и Oracle. Клиентскими приложениями являются ERwin 4.0 и BPwin 4.0. В Model Mart реализован доступ к хранилищу моделей через API, что позволяет постоянно наращивать возможности интегрированной среды путем включения новых инструментов моделирования и анализа.

Оптимизация бизнес-процессов с помощью имитационного моделирования.

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

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

Создание имитационной модели является очень сложной задачей. BPwin позволяет детально исследовать технологический процесс, построить диаграмму такого процесса (IDEF3) и экспортировать модель (см. рис. 3) в один из самых эффективных инструментов имитационного моделирования- Arena (фирма System Modeling Corporation, ). Arena позволяет строить имитационные модели, "проигрывать" и оптимизировать технологические процессы в самых разных сферах деятельности.

Отчеты и экспорт модели. BPwin 4.0 на основе информации о модели бизнес-процесссов позволяет генерировать разнообразные отчеты, которые могут быть использованы для анализа и документирования модели. Отчеты могут быть экспортированы в распространенные форматы - текстовый, MS Office, HTML и др. (см. рис. 3). Результаты экспорта могут быть использованы для создания отчетов с помощью средств других производителей, например Crystal Reports. BPwin 4.0 поддерживает также экспорт и импорт модели в текстовый файл формата IDL (см. рис. 3). Формат IDL является стандартом для экспорта и импорта моделей IDEF0, позволяет разрабатывать функциональные модели одновременно инструментальными средствами различных производителей.

Глава 1. Инструментальные средства BPwin4.0

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

1.1.1. Общее описание интерфейса BPwin 4.0

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

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

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

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

Таблица 1.1.1. Описание элементов управления основной панели инструментов BPwin 4.0

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

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

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

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

После щелчка по кнопке ОК появляется диалог Properties for New Models (рис. 1.1.3), в котором следует внести свойства модели. (Более подробно свойства модели будут рассмотрены в 1.2.1.)

Рис. 1.1.3. Диалог Properties for New Models

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

1.1.3. Установка цвета и шрифта объектов

Пункты контекстного меню Font и Color вызывают диалог Arrow Properties или Activity Properties для установки шрифта (в том числе его размера и стиля) и цвета объекта. В нижней части вкладки Font диалогов Arrow Properties и Activity Properties (рис. 1.1.4) находятся группа опций Apply setting to, позволяющих изменить шрифт для всех работ или стрелок на текущей диаграмме, в модели, и группа Global, позволяющая изменить шрифт одновременно для всех объектов модели.

Рис. 1.1.4. Вкладка Font диалога Activity Properties

Кроме того, BPwin позволяет установить шрифт по умолчанию для объектов определенного типа на диаграммах и в отчетах. Для этого следует выбрать меню Model/Default Fonts, после чего появляется каскадное меню, каждый пункт которого служит для установки шрифтов для определенного типа объектов:

Context Activity - работа на контекстной диаграмме;

Context Arrow - стрелки на контекстной диаграмме;

Decomposition Activity - работы на диаграмме декомпозиции;

Decomposition Arrow - стрелки на диаграмме декомпозиции;

Node Tree Text - текст на диаграмме дерева узлов;

Frame User Text - текст, вносимый пользователем в каркасе диаграмм;

Frame System Text — системный текст в каркасе диаграмм;

Text Blocks - текстовые блоки;

Parent Diagram Text - текст родительской диаграммы;

Parent Diagram Title Text - текст заголовка родительской диаграммы;

Report Text - текст отчетов.

Если на компьютере установлена операционная система Windows NT, возможно некорректное отображение на диаграммах кириллических шрифтов. Для корректной работы BPwin необходимо отредактировать регистры NT.

В разделе

HKEY_LOCAL_MACHINE SOFTWARE/Microsoft/WindowsNT/CurrentWersion/FontMapper

следует установить 204-ю таблицу - DEFAULT OXOOOOOOcc (204).

В разделе

HKEY_LOCAL_MACHINE SOFTWARE/Microsoft/WindowsNT/CurrentWersion/FontSubstitutes

следует для всех стандартных шрифтов установить ссылку на 204-ю таблицу, например:

Arial.O "Arial,204"

1.1.4. Model Explorer - навигатор модели

Инструмент навигации Model Explorer имеет три вкладки - Activities, Diagrams и Objects. Вкладка Activities (рис. 1.1.5) показывает в виде раскрывающегося иерархического списка все работы модели. Одновременно могут быть показаны все модели, открытые в BPwin. Работы с диаграмм IDEF0 показываются зеленым цветом, IDEF3 - желтым и DFD - голубым.

Рис. 1.1.5. Вкладка Activities навигатора Model Explorer

Щелчок по работе во вкладке Activity переключает левое окно BPwin на диаграмму, на которой эта работа размещена. Для редактирования свойств работы следует щелкнуть по ней правой кнопкой мыши. Появляется контекстное меню. В табл. 1.1.2 приведено значение пунктов меню.

Таблица 1.1.2. Контекстное меню редактирования свойств работы

Если с помощью вкладки Activities можно перейти на стандартные диаграммы (контекстную и декомпозиции, см. 1.2), то вторая вкладка -Diagrams (рис. 1.1.6)- служит для перехода на любую диаграмму модели.

Рис. 1.1.6. Вкладка Diagrams навигатора Model Explorer

После перехода на вкладку Objects на ней показываются все объекты, соответствующие выбранной на вкладке Diagrams диаграмме, в том числе работы, хранилища данных, внешние ссылки, объекты ссылок и перекрестки (рис. 1.1.7).

Рис. 1.1.7. Вкладка Objects навигатора Model Explorer

1.2. Создание модели в стандарте IDEF0

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

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

Наиболее удобным языком моделирования бизнес-процессов является IDEF0, предложенный более 20 лет назад Дугласом Россом (SoftTech, Inc.) и называвшийся первоначально SADT - Structured Analysis and Design Technique. (Подробно методология SADT излагается в книге Дэвида А. Марка и Клемента Мак-Гоуэна "Методология структурного анализа и проектирования SADT" (М.:Метатехнология, 1993.) В начале 70-х годов вооруженные силы США применили подмножество SADT, касающееся моделирования процессов, для реализации проектов в рамках программы ICAM (Integrated Computer-Aided Manufacturing). В дальнейшем это подмножество SADT было принято в качестве федерального стандарта США под наименованием IDEF0. Подробные спецификации на стандарты IDEF можно найти на сайте .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Иногда текущая AS-IS и будущая ТО-ВЕ модели различаются очень сильно, так что переход от начального к конечному состоянию становится неочевидным. В этом случае необходима третья модель, описывающая процесс перехода от начального к конечному состоянию системы, поскольку такой переход - это тоже бизнес-процесс. Результат описания модели можно получить в отчете Model Report. Диалог настройки отчета по модели вызывается из пункта меню Tools/Reports/Model Report. В диалоге настройки следует выбрать необходимые поля, при этом автоматически отображается очередность вывода информации в отчет (рис. 1.2.2).

Рис. 1.2.2. Отчет по модели

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

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

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

декомпозиции;

дерева узлов;

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

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

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

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

1.2.2. Работы (Activity)

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

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

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

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

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

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

Рис. 1.2.5. Диалог Activity Box Count Если оказывается, что количество работ недостаточно, тоработу можно добавить в диаграмму, щелкнув сначала по кнопке SsM на палитре инструментов, а затем по свободному месту на диаграмме.

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

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

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

Каждая из работ на диаграмме декомпозиции может быть, в свою очередь декомпозирована. На диаграмме декомпозиции работы нумеруются автоматически слева направо. Номер работы показывается в правом нижнем углу. В левом верхнем углу изображается небольшая диагональная черта, которая показывает, что данная работа не была декомпозирована. Так, на рис. 1.2.7 работа "Сборка изделия" имеет номер 3 и не была еще декомпозирована. Работа "Контроль качества" (номер 4) имеет нижний уровень декомпозиции.

Рис. 1.2.7. Пример декомпозируемых работ

1.2.3. Стрелки (Arrow)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 1.2.8. Диалог Arrow Properties

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

Рис. 1.2.9. Фрагмент диаграммы декомпозиции cICOM-кодам (11, С1 и С2)

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

Словарь стрелок редактируется при помощи специального редактора Arrow Dictionary, в котором определяется стрелка и вносится относящийся к ней комментарий (рис. 1.2.10).

Рис. 1.2.10. Словарь стрелок

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

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

Таблица 1.2.1. Кнопки панели управления словаря (слева направо)

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

Несвязанные граничные стрелки (unconnected border arrow).

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

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

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

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

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

В IDEF0 различают пять типов связей работ.

Связь по входу (output-input), когда стрелка выхода вышестоящей работы (далее — просто выход) направляется на вход нижестоящей (например, на рис. 1.2.12 стрелка "Детали" связывает работы "Изготовление деталей"'и "Сборка изделия").

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

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

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

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

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

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

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

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

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

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

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

Смысл разветвляющихся и сливающихся стрелок передается именованием каждой ветви стрелок. Существуют определенные правила именования таких стрелок. Рассмотрим их на примере разветвляющихся стрелок.

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

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

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

Рис. 1.2.18. Другой пример именования разветвляющейся стрелки

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

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

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

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

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

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

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

Если выбрать опцию Resolve it to border arrow, стрелка мигрирует на диаграмму верхнего уровня, а если Change it to resolved rounded стрелка будет затоннелирована и не попадет на другую диаграмму, тоннельная стрелка изображается с круглыми скобками на конце (рис. 1 -2.)

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

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

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

1.2.4. Нумерация работ и диаграмм

Все работы модели нумеруются. Номер состоит из префикса и числа. Может быть использован префикс любой длины, но обычно используют префикс А. Контекстная (корневая) работа дерева имеет номер АО. Работы декомпозиции АО имеют номера Al, A2, A3 и т. д. Работы декомпозиции нижнего уровня имеют номер родительской работы и очередной порядковый номер, например работы декомпозиции A3 будут иметь номера Д31, А32, АЗЗ, А34 и т. д. Работы образуют иерархию, где каждая работа может иметь одну родительскую и несколько дочерних работ, образуя дерево. Такое дерево называют деревом узлов, а вышеописанную нумерацию - нумерацией по узлам. Имеются незначительные варианты нумерации, которые можно настроить во вкладке Presentation диалога Model Properties (меню Edit/Model Properties).

Диаграммы IDEF0 имеют двойную нумерацию. Во-первых, диаграммы имеют номера по узлу. Контекстная диаграмма всегда имеет номер А-0, декомпозиция контекстной диаграммы - номер АО, остальные диаграммы декомпозиции - номера по соответствующему узлу (например, Al, A2, А21, А213 и т.д.). BPwin автоматически поддерживает нумерацию по узлам, т. е. при проведении декомпозиции создается новая диаграмма и ей автоматически присваивается соответствующий номер. В результате проведения экспертизы диаграммы могут уточняться и изменяться, следовательно, могут быть созданы различные версии одной и той же (с точки зрения ее расположения в дереве узлов) диаграммы декомпозиции. BPwin позволяет иметь в модели только одну диаграмму декомпозиции в данном узле. Прежние версии диаграммы можно хранить в виде бумажной копии либо как FEO-диаграмму. (К сожалению, при создании FEO-диаграмм отсутствует возможность отката, т. е. можно получить из диаграммы декомпозиции FEO, но не наоборот.) В любом случае следует отличать различные версии одной и той же диаграммы. Для этого существует специальный номер - С-number, который должен присваиваться автором модели вручную. C-num-ber — это произвольная строка, но рекомендуется придерживаться стандарта, когда номер состоит из буквенного префикса и порядкового номера, причем в качестве префикса используются инициалы автора диаграммы, а порядковый номер отслеживается автором вручную, например МСВ00021.

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

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

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

Для создания диаграммы дерева узлов следует выбрать в меню пункт Diagram/Add Node Tree. Возникает эксперт создания диаграммы дерева узлов Node Tree Wizard. В первом диалоге эксперта необходимо внести имя диаграммы дерева узлов, узел верхнего уровня и глубину дерева -Number of Levels (по умолчанию 3). Поскольку дерево узлов не обязательно в качестве верхнего уровня должна иметь контекстную работу и иметь произвольную глубину. В одной модели можно создавать множество диаграмм деревьев узлов. Имя дерева узлов по умолчанию совпадает с именем работы верхнего уровня, а номер диаграммы автоматически генерируется как номер узла верхнего уровя плюс литера "N", например A0N. Если в модели создается два дерева узлов, имеющих в качестве верхнего уровня одну и ту же работу, то по умолчанию диаграммы получат идентичные номер и имя. Поэтому рекомендуется при создании диаграммы дерева узлов внести имя диаграммы, отличное от значения по умолчанию. Второй диалог эксперта Node Tree Wizard (рис. 1.2.24) позволяет задать свойства диаграммы дерева узлов.

Рис. 1.2.24. Диалог настройки диаграммы дерева узлов

По умолчанию нижний уровень декомпозиции показывается в виде списка, остальные работы - в виде прямоугольников. Для отображения всего дерева в виде прямоугольников следует выбрать опцию Bullet Last Level. Труппа Connection Style позволяет выбрать стиль соединительных линий - диагональные (по умолчанию) или ортогональные.

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

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

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

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

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

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

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

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

Таблица 1.2.2. Поля заголовка каркаса (слева направо)

Таблица 1.2.3. Поля подвала каркаса (слева направо)

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

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

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

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

BPwin использует для слияния и разветвления моделей стрелки вызова.

Для слияния необходимо выполнить следующие условия:

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

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

(рис. 1.2.28);

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

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

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

Рис. 1,2.28. Условия слияния моделей

Рис. 1.2.29. Стрелка вызова работы "Сборка изделия модели-цели

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

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

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

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

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

Рис. 1.2.31. Вид моделей в Model Explorer после слияния. Выделены модель-источник и присоединенная ветвь модели-цели

1.2.8. Рекомендации по рисованию диаграмм

В реальных диаграммах к каждой работе может подходить и от каждой может отходить около десятка стрелок. Если диаграмма содержит 6-8 работ, то она может содержать 30-40 стрелок, причем они могут сливаться, разветвляться и пересекаться. Такие диаграммы могут стать очень плохо читаемыми.

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

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

Следует максимально увеличивать расстояние между входящими или выходящими стрелками на одной грани работы. Если включить опцию Automatically space arrows на вкладке Layout диалога Model Properties (меню Model/Model Properties), BPwin будет располагать стрелки нужным образом автоматически.

Следует максимально увеличить расстояние между работами, поворотами и пересечениями стрелок.

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

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

" Циклические обратные связи следует рисовать только в случае крайней необходимости, когда подчеркивают значение повторно используемого объекта. Принято изображать такие связи на диаграмме декомпозиции. BPwin не позволяет создать циклическую обратную связь за один прием. Если все же необходимо изобразить такую связь, следует сначала создать обычную связь по входу, затем разветвить стрелку, направить новую ветвь обратно ко входу работы-источника и, наконец, удалить старую ветвь стрелки выхода (рис. 1.2.32).

Рис. 1.2.32. Пример обратной циклической связи

■ Следует минимизировать число пересечений, петель и поворотов стрелок. Это ручная и, в случае насыщенных диаграмм, творческая работа (рис. 1.2.33).

Рис. 1.2.33. Минимизация пересечений и поворотов стрелок

Если нужно изобразить связь по входу, необходимо избегать "нависа-ния" работ друг над другом. В этом случае BPwin изображает связи по входу в виде петли, что затрудняет чтение диаграмм (рис. 1.2.34).

Рис. 1.2.34. Пример правильного (справа) и неправильного (слева) расположения работ при изображении связи по входу

1.2.9. Проведение экспертизы

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

Рис. 1.2.35. Цикл автор-читатель

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

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

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

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

Рис. 1.2.36. Внесение замечаний в диаграмму

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

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

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

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

1.3. Стоимостный анализ (ABC) и свойства, определяемые пользователем (UDP)

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

BPwin предоставляет аналитику два инструмента для оценки модели - стоимостный анализ, основанный на работах (Activity Based Costing, ABC), и свойства, определяемые пользователем (User Defined Properties, UDP). ABC является широко распространенной методикой, используемой международными корпорациями и государственными организациями (в том числе Департаментом обороны США) для идентификации истинных движителей затрат в организации.

Стоимостный анализ представляет собой соглашение об учете, используемое для сбора затрат, связанных с работами, с целью определить общую стоимость процесса. Стоимостный анализ основан на модели работ, потому что количественная оценка невозможна без детального понимания функциональности предприятия. Обычно ABC применяется для того, чтобы понять происхождение выходных затрат и облегчить выбор нужной модели работ при реорганизации деятельности предприятия (Business Process Re-engineering, BPR). С помощью стоимостного анализа можно решить такие задачи, как определение действительной стоимости производства продукта, определение действительной стоимости поддержки клиента, идентификация работ, которые стоят больше всего (те, которые должны быть улучшены в первую очередь), обеспечение менеджеров финансовой мерой предлагаемых изменений, и др.

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

ABC включает следующие основные понятия:

- объект затрат - причина, по которой работа выполняется, обычно, основной выход работы, стоимость работ есть суммарная стоимость объектов затрат ("Готовое изделие", рис. 1.3.1).

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

центры затрат, которые можно трактовать как статьи расхода.

Рис. 1.3.1. Иллюстрация терминов ABC

При проведении стоимостного анализа в BPwin сначала задаются единицы измерения времени и денег. Для задания единиц измерения следует вызвать диалог Model Properties (меню Edit/Model Properties), вкладка ABC Units (рис. 1.3.2).

Если в списке выбора отсутствует необходимая валюта (например, рубль), ее можно добавить. Символ валюты по умолчанию берется из настроек Windows. Диапазон измерения времени в списке Unit of measurment достаточен для большинства случаев - от секунд до лет.

Рис. 1.3.2. Настройка единиц измерения валюты и времени

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

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

Рис. 1.3.3. Диалог Cost Center Dictionary

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

Рис. 1.3.4. Задание стоимости работ в диалоге Activity Cost

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

Рис. 1.3.5. Вычисление затрат родительской работы

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

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

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

внешний осмотр-стоимость 50 руб.;

пробное включение - стоимость 150 руб.;

испытание на стенде - стоимость 300 руб.

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

300 руб. (Испытание на стенде) (8+150 руб. (Пробное включение) (4 +

+ 50 руб. (Внешний осмотр) (2 = 3100 руб.

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

50 руб. (Внешний осмотр) (8+150 руб. (Пробное включение) (4 +

+ 300 руб. (Испытание на стенде) (2 = 1600 руб.

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

Рис. 1.3.6. Фрагмент диаграммы декомпозиции работы "Контроль качества "

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

Рис. 1.3.7. Диалог настройки отчета по стоимости работ

Результаты отображаются и непосредственно на диаграммах. В левом нижнем углу прямоугольника работы может показываться либо стоимость (по умолчанию), либо продолжительность, либо частота проведения работы. Настройка отображения осуществляется в диалоге Model Properties (меню Model/Model Properties), вкладка Display, опции ABC Data и ABC Units.

ABC позволяет оценить стоимостные и временные характеристики системы. Если стоимостных показателей недостаточно, имеется возможность внесения собственных метрик - свойств, определенных пользователем (User Defined Properties, UDP). UDP позволяют провести дополнительный анализ, хотя и без суммирующих подсчетов.

Для описания UDP служит диалог UDP Dictionary (меню Dictionary /UDP) (рис. 1.3.8). UDP можно поставить в соответствие одно или несколько ключевых слов. Ключевые слова могут быть использованы для отбора UDP при печати отчетов или при присвоении свойств работам и стрелкам. Ключевые слова должны быть описаны в словаре UDP Keyword List (рис. 1.3.9). Для внесения нового ключевого слова следует щелкнуть по кнопке Ш. и в таблице диалога UDP Keyword List задать значение ключевого слова.

Для создания нового свойства (UDP) следует в словаре UDP Dictionary перейти к нижней строке списка и дважды щелкнуть по полю Name. В режиме редактирования имени следует внести имя UDP. В поле UDP Type (рис. 1.3.10) описывается тип свойства. Имеется возможность задания 18 различных типов UDP (табл. 1.3.1), в том числе управляющих команд и массивов.

Таблица 1.3.1. Типы UDP и их использование

ТипИспользование

Character ListМассив символов. Значения свойства этого типа

(Single selection) должны быть определены в диалоге UDP Dictionary (поле Value). Объекту модели можно присваивать только одно значение из предварительно заданного списка

Text List (Multiple Массив строк (множественный выбор). Значения selections)свойства этого типа должны быть определены в диалоге UDP Dictionary (поле Value). Объекту модели можно присваивать одновременно несколько значений из предварительно заданного

Списка Integer ListМассив целых чисел (множественный выбор).

(MultipleЗначения свойства этого типа должны быть selections)определены в диалоге UDP Dictionary (поле Value).

Объекту модели можно присваивать одновременно несколько значений из предварительно заданного списка Date List (Multiple Массив дат (множественный выбор). Значения selections)свойства этого типа должны быть определены в диалоге UDP Dictionary (поле Value). Объекту модели можно присваивать одновременно несколько значений из предварительно заданного списка Real Number List Массив действительных чисел (множественный (Multipleвыбор). Значения свойства этого типа должны быть selections)определены в диалоге UDP Dictionary (поле Value).

Объекту модели можно присваивать одновременно несколько значений из предварительно заданного списка Character ListМассив символов (множественный выбор). (MultipleЗначения свойства этого типа должны быть selections)определены в диалоге UDP Dictionary (поле Value). Объекту модели можно присваивать одновременно несколько значений из предварительно заданного списка

Рис. 1.3.8. Диалог описания UDP

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

Рис. 1.3.9. Диалог описания ключевых слов UDP

Рис. 1.3.10. Выбор типа UDP

Каждой работе можно поставить в соответствие набор UDP. Для этого следует щелкнуть правой кнопкой мыши по работе и выбрать пункт меню UDP. Во вкладке UDP Values диалога Activity Properties можно задать значения UDP. Свойства типа List отображаются списком выбора, который заполнен предварительно определенными значениями. Свойства типа Command могут иметь в качестве значения командную строку, которая выполняется при нажатии на кнопку > . Например, свойство "Спецификации" категории "Дополнительная документация" может иметь значение C:\MSOffice97\Office\WINWORD.EXE specl.doc.

Рис. 1.3.11. Задание значений UDP

Кнопка Filter служит для задания фильтра по ключевым словам UDP. По умолчанию в списке показываются свойства всех категорий.

Кнопка Dictionary вызывает диалог User Defined Property Dictionary Соис. 1-3-12), который позволяет создавать и редактировать как UDP, так ключевые слова UDP. В верхнем окне диалога вносится имя UDP, в списке выбора Datatype описывается тип свойства. Для внесения ключевого слова следует задать имя в окне New Keywords и щелкнуть по кнопке Add Keywords. Для присвоения ключевого слова необходимо выбрать UDP из списка User-Defined Properties, затем ключевое слово из списка Keywords и щелкнуть по кнопке Update. Одно ключевое слово может объединять несколько свойств, в то же время одному свойству может соответствовать несколько ключевых слов. Свойство типа List может содержать массив предварительно определенных значений. Для определения области значений UDP типа List следует задать значение свойства в окне New Member и щелкнуть по кнопке Add Member. Значения из списка можно редактировать и удалять (кнопки Update Member и Delete Member).

Рис. 1.3.12. Диалог User Defined Property Dictionary

Результат задания значений UDP можно проанализировать в отчете Diagram Object Report (меню Tools/Report/Diagram Object Report, рис. 1.3.13).

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

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

1.4. Дополнение созданной модели процессов организационными диаграммами, диаграммами DFD и Workflow (IDEF3)

1.4.1. Диаграммы потоков данных (Data Flow Diagramming)

Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет модельную систему как сеть связанных между собой работ. Их можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации. DFD описывает:

функции обработки информации (работы);

документы (стрелки, arrow), объекты, сотрудников или отделы, которые участвуют в обработке информации;

внешние ссылки (external references), которые обеспечивают интерфейс с внешними объектами, находящимися за границами модели руемой системы;

таблицы для хранения документов (хранилище данных, data store).

В BPwin для построения диаграмм потоков данных используется нотация Гейна - Сарсона.

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

- добавить в диаграмму внешнюю ссылку (External Reference). Внешняя ссылка является источником или приемником данных извне модели;

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

В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой. Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы - движение объектов (data flow), хранение объектов (data stores), поставка и распространение объектов (external entities) (рис. 1.4.1).

Рис. 1.4.1. Пример диаграммы DFD

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

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

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

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

Рис. 1.4.2. Внешняя сущность

Хранилище данных. В отличие от стрелок, описывающих объекты в движении, хранилища данных изображают объекты в покое (рис. 1.4.3).

Рис. 1.4.3. Хранилище данных

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

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

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

Альтернативным подходом является подход, популярный при создании программного обеспечения, называемый событийным разделением (event Partitioning), в котором различные диаграммы DFD выстраивают модель системы. Во-первых, логическая модель строится как совокупность работ и документирования того, что они (эти работы) должны делать.

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

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

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

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

1.4.2. Метод описания процессов IDEF3

Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс документооборота. Однако для описания логики взаимодействия информационных потоков более подходит IDEF3, называемая также workflow diagramming - методологией моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. Диаграммы Workflow могут быть использованы в моделировании бизнес-процессов для анализа завершенности процедур обработки информации. С их помощью можно описывать сценарии действий сотрудников организации, например последовательность обработки заказа события, которые необходимо обработать за конечное время. Каждый тенарий сопровождается описанием процесса и может быть использован я документирования каждой функции.

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

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

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

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

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

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

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

Работа в IDEF3 требует более подробного описания, чем работа в IDEF0 Каждая UOW должна иметь ассоциированный документ, который включает текстовое описание компонентов работы: объектов (Objects) и фактов (Facts), связанных с работой, ограничений (Constraints), накладываемых на работу, и дополнительное описание работы (Description). Эта информация заносится во вкладку UOW диалога Activity Properties (рис. 1.4.4).

Рис. 1.4.4. Вкладка UOW диалога Activity Properties Пример значений свойств UOW приведен в табл. 1.4.1.

Таблица 1.4.1. Пример текстового описания компонентов UOW

ТunИспользование

NAMEПодготовка компонентов

"DefinitionПодготавливаются все компоненты компьютера согласно

спецификации заказа

"ObjectsКомпоненты: винчестеры, корпуса, материнские платы,

видиокарты, звуковые карты, дисководы CD-ROM

и флоппи, модемы, программное обеспечение

"Constrains Установка модема требует установки дополнительного пограммного обеспечения

Связи. Связи показывают взаимоотношения работ. Все связи в IDEF3 однонаправленны и могут быть направлены куда угодно, но обычно диаграммы IDEF3 стараются построить так, чтобы связи были направлены слева направо. В IDEF3 различают три типа стрелок, изображающих связи, стиль которых устанавливается во вкладке Style (рис. 1.4.5) диалога Arrow Properties (пункт контекстного меню Style).

Рис. 1.4.5. Вкладка Style диалога Arrow Properties

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

Стрелка отношения (Relational Link) - пунктирная линия, использующаяся для изображения связей между единицами работ (UOW), а также между единицами работ и объектами ссылок.

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

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

Отношение показывает, что стрелка является альтернативой старшей стрелке или потоку объектов в смысле задания последовательности выполнения работ - работа-источник не обязательно должна закончиться прежде, чем работа-цель начнется. Более того, работа-цель может закончиться прежде, чем закончится работа-источник (рис. 1.4.6).

Старт работы Окончание работы Старт работы- Окончание-источника -источника цели работы -цели Старшая или поток объектов

Старт работы Старт работы- Окончание работы Окончание -источника цели -источника работы-цели '''' Отношение

Старт работы Старт работы- Отношение Окончание работы -источника цели работы-цели -источника Отношение

Рис. 1.4.6. Временная диаграмма выполнения работ

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

Таблица 1.4.2. Типы перекрестков

Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. Можно редактировать свойства перекрестка при помощи диалога Junction Properties (вызывается из контекстного меню). В отличие от IDEF0 и DFD в IDEF3 стрелки могут сливаться и разветвляться только через перекрестки. Рис. 1.4.7-1.4.11 иллюстрируют смысл перекрестков каждого типа.

Рис. 1.4.7. Перекрестки для слияния и разветвления типа синхронного "И". Здесь после завершения работы 1 одновременно запускаются работы 2 и 4. Для запуска работы 5 требуется одновременное завершение работ 3 и 4

Рис. 1.4.8. Перекрестки для слияния и разветвления типа асинхронного "И". Здесь после завершения работы 1 запускаются работы 2 и 4 (не обязательно одновременно). Для запуска работы 5 требуется завершение работ 3 и 4 (не обязательно одновременное)

Рис. 1.4.9. Перекрестки для слияния и разветвления типа асинхронного "ИЛИ". Здесь после завершения работы 1 запускается либо работа 2, либо работа 3, либо работа 4, либо их сочетание (не обязательно одновременно). Для запуска работы 5 требуется завершение любой из работ 2, 3 и 4 или их сочетания (не обязательно одновременное)

Рис. 1.4.10. Перекрестки для слияния и разветвления типа синхронного "ИЛИ". Здесь после завершения работы 1 запускается либо работа 2, либо работа 3, либо работа 4, либо их сочетание. Если запускается более одной работы, требуется их одновременный запуск. Для запуска работы 5 требуется завершение любой из работ 2, 3 и 4 или их сочетания. Если завершается более чем одна работа, требуется их одновременное завершение

Рис. 1.4.11. Перекрестки для слияния и разветвления типа исключающего "ИЛИ". Здесь после завершения работы 1 запускается только одна работа - либо работа 3, либо работа 4. Для запуска работы 5 требуется завершение только одной из работ, 3 или 4

Правила создания перекрестков. На одной диаграмме IDEF3 может быть создано несколько перекрестков различных типов. Определенные сочетания перекрестков для слияния и для разветвления могут приводить к логическим несоответствиям. Чтобы избежать конфликтов необходимо соблюдать следующие правила:

Каждому перекрестку для слияния должен предшествовать перекресток для разветвления.

Перекресток для слияния "И" не может следовать за перекрестком для разветвления типа синхронного или асинхронного "ИЛИ" (рис. 1.4.12).

Действительно, после работы 1 может запускаться только одна работа - 2 или 3, а для запуска работы 4 требуется окончание обеих работ - 2 и 3. Такой сценарий не может реализоваться.

Рис. 1.4.12. Неверное размещение перекрестков. Перекресток для слияния "И" не может следовать за перекрестком для разветвления "ИЛИ"

Перекресток для слияния "И" не может следовать за перекрестком для разветвления типа исключающего "ИЛИ" (рис. 1.4.13).

Рис. 1.4.13. Неверное размещение перекрестков. Перекресток для слияния "И" не может следовать за перекрестком для разветвления типа исключающего "ИЛИ"

4. Перекресток для слияния типа исключающего "ИЛИ" не может следовать за перекрестком для разветвления типа "И" (рис. 1.4.14). Здесь после завершения работы 1 запускаются обе работы - 2 и 3, а для запуска работы 4 требуется, чтобы завершилась одна и только одна работа -или 2, или 3.

Рис. 1.4.14. Неверное размещение перекрестков. Перекресток для слияния типа исключающего "ИЛИ" не может следовать за перекрестком для разветвления типа "И"

Перекресток, имеющий одну стрелку на одной стороне, должен иметь более одной стрелки на другой.

Объект ссылки. Объект ссылки в IDEF3 выражает некую идею, концепцию или данные, которые нельзя связать со стрелкой, перекрестком или работой (рис. 1.4.15). Для внесения объекта ссылки служит кнопка ШЗ (добавить в диаграмму объект ссылки - Referent) в палитре инструментов. Объект ссылки изображается в виде прямоугольника, похожего на прямоугольник работы. Имя объекта ссылки задается в диалоге Referent Properties (пункт контекстного меню Name), в качестве имени можно использовать имя какой-либо стрелки с других диаграмм или имя сущности из модели данных. Объекты ссылки должны быть связаны с единицами работ или перекрестками пунктирными линиями. Официальная спецификация IDEF3 различает три стиля объектов ссылок - безусловные (unconditional), синхронные (synchronous) и асинхронные (asynchronous). BPwin поддерживает только безусловные объекты ссылок. Синхронные и асинхронные объекты ссылок, используемые в диаграммах переходов состояний объектов, не поддерживаются.

Рис. 1.4.15. Объект ссылки

При внесении объектов ссылок помимо имени следует указывать л объекта ссылки. Типы объектов ссылок приведены в табл. 1.4.3.

Таблица 1.4.3. Типы объектов ссылок

Декомпозиция работ. В IDEF3 декомпозиция используется для детализации работ. Методология IDEF3 позволяет декомпозировать работу многократно, т. е. работа может иметь множество дочерних работ. Это позволяет в одной модели описать альтернативные потоки. Декомпозиция может быть сценарием или описанием. Описание включает все возможные пути развития процесса. Сценарий является частным случаем описания и иллюстрирует только один путь реализации процесса. По умолчанию при декомпозиции на диаграмму IDEF3 создается описание. Чтобы создать сценарий, необходимо перейти в меню Diagram/Add IDEF3 Scenario.

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

Рис. 1.4.16. Номер единицы работы (UOW)

Для описания номер декомпозиции равен 1. Для сценария номер декомпозиции всегда больше 1.

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

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

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

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

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

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

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

Таблица 1.4.4. Диапазоны номеров работ

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

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

1.4.3. Организационные диаграммы и диаграммы Swim Lane

BPwin 4.0 содержит набор инструментов для моделирования организационной структуры предприятия. В отличие от предыдущей версии 2.5 он содержит четыре новых словаря - словарь изображений (bitmap), словарь ресурсов, словарь ролей и словарь групп ролей. Словарь изображений служит для импорта файлов в формате bmp в модель. Импортированные изображения можно использовать в диаграммах для улучшения их внеш него вида. Для импорта изображения следует перейти в меню Dictionary/ Bitmaps. Появляется диалог Bitmap Dictionary (рис. 1.4.17), в котором следует щелкнуть по кнопке Inport и найти файл формата bmp.

Рис. 1.4.17. Диалог Bitmap Dictionary

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

Рис. 1.4.18. Словарь групп ролей

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

Словарь ролей вызывается из меню Dictionary/Role (рис. 1.4.19).

Рис. 1.4.19. Словарь ролей

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

Рис. 1.4.20. Словарь ролей

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

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

Рис. 1.4.21. Первый диалог гида Organization Chart Wizard

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

Рис. 1.4.22. Создание второго уровня организационной диаграммы в Organization Chart Wizard

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

После щелчка по кнопке Finish создается организационная диаграмма (рис. 1.4.23).

Рис. 1.4.23. Первый и второй уровни организационной диаграммы

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

Edit subordinate list — редактирование блока;

Add subordinates - добавляет нижний уровень;

Add sibling on left - добавляет блок на текущий уровень слева от редактируемого блока;

Add sibling on rigth - добавляет блок на текущий уровень справа от редактируемого блока.

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

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

Рис. 1.4.24. Первый диалог гида Swim Lane Diagram Wizard

Во втором диалоге гида следует выбрать роли, на основе которых будет создана диаграмма. Диаграмма будет разделена на количество полос, указанных в колонке Display Swim Line.

Рис. 1.4.25. Выбор ролей во втором диалоге гида Swim Lane Diagram Wizard

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

Рис. 1.4.26. Диаграмма Swim Lane

1.4.4. Использование нетрадиционного синтаксиса на диаграммах функциональной модели

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

Рис. 1.4.27. Вкладка Box Style диалога Activity Properties

После щелчка по кнопке ОК на диаграмме работа отображается в нетрадиционном синтаксисе (рис. 1.4.28).

Рис. 1.4.28. Отображение работы в виде овала на диаграмме IDEF0

Использование нетрадиционного синтаксиса может быть полезно при решении ряда задач, например при преобразовании диаграммы IDEF3 в имитационную модель Arena (рис. 1.4.29, см. также 1.4.6).

Рис. 1.4.29. Диаграмма 1DEF3, выполненная в синтаксисе имитационной модели Arena

1.4.5. Создание смешанной модели

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

Авторы нотаций IDEFO, IDEF3 и DFD не предполагали совместного использования диаграмм различной нотации в одной модели, поэтому создание смешанной модели имеет ряд особенностей. Во-первых, существуют определенные правила декомпозиции работы одной нотации в диаграмму другой. Во-вторых, BPwin позволяет разместить объекты одной нотации на диаграмме другой. Рассмотрим эти особенности.

Рис. 1.4.30. Представление смешанной модели в окне Model Explorer

BPwin допускает следующие переходы с одной нотации на другую:

IDEF0 -> DFD;

IDEF0 -> IDEF3;

DFD -> IDEF3.

Декомпозировать работу DFD на диаграмму IDEF0 нельзя, так же как декомпозировать работу IDEF3 на диаграмму любой другой нотации.

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

Рис. 1.4.31. Декомпозируемая работа на диаграмме IDEF0

Стрелки входа родительской работы на дочерней диаграмме DFD показываются входящими стрелками с левой стороны диаграммы DFD, стрелки управления - входящими стрелками с верхней стороны диаграммы и т. д. Хотя нотация DFD не включает понятия "управление" и "механизм" и можно создавать внутренние стрелки исходящими из любой грани работы и входящими в любую грань, BPwin не позволяет связать граничные стрелки на диаграмме DFD произвольным образом. Стрелки можно связать только так, как если бы это была диаграмма IDEF0, т. е. входящую с верхней грани диаграммы стрелку - только к верхней грани работы и т. д.

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

удалить все граничные стрелки на диаграмме DFD;

создать соответствующие внешние сущности и хранилища данных;

Рис. 1.4.33. Тоннелирование стрелок на диаграмме IDEF0

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

Результат этих действий представлен на рис. 1.4.33 и 1.4.34.

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

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

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

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

Рис. 1.4.35. Создание межстраничной ссылки на диаграмме DFD

В результате будет создана межстраничная ссылка (см., например, ссылку на диаграмму А23 на рис. 1.4.34) как на диаграмме-источнике, так и на диаграмме-назначении. Межстраничная ссылка может быть помечена как C-number диаграммы, как номер диаграммы по узлу (как на рис. 1.4.34) или как имя диаграммы. Для изменения метки следует перейти

в меню Model/Model Properties и во вкладке Display диалога Model Properties и в группе Off-Page Reference label выбрать нужную опцию.

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

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

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

В результате BPwin позволяет создавать на диаграмме DFD четыре типа граничных стрелок (рис. 1.4.36, сверху вниз):

обычная граничная стрелка (не допускается нотацией DFD);

межстраничная ссылка;

тоннельная стрелка (не предусмотрена нотацией DFD);

внешняя ссылка.

Рис. 1.4.36. Граничные стрелки на диаграмме DFD

Интересной особенностью BPwin является то, что те же самые типы стрелок можно создать на диаграмме IDEF0 (рис. 1.4.37):

обычная граничная стрелка;

межстраничная ссылка (не предусмотрена нотацией 1DEF0);

тоннельная стрелка;

внешняя ссылка (не предусмотрена нотацией IDEF0).

Рис. 1.4.37. Граничные стрелки на диаграмме IDEF0

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

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

Рис. 1.4.38. Фрагмент дочерней диаграммы 1DEF3

Рис. 1.4.39. Фрагмент родительской диаграммы IDEFO

1.4.6. Имитационное моделирование

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

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

Одним из наиболее эффективных инструментов имитационного моделирования является система Arena фирмы System Modeling Corporation (). Arena позволяет строить имитационные модели, проигрывать их и анализировать результаты такого проигрывания. Имитационное моделирование - это универсальное средство для оптимизации процессов, поэтому модели с помощью Arena могут быть построены для самых разных сфер деятельности - производственных технологических операций, складского учета, банковской деятельности, обслуживания клиентов в ресторане и т. д. и т. п. В настоящей книге описана версия Arena BE 3.6.1.

Имитационная модель Arena включает следующие основные элементы: источники и стоки (Create и Dispose), процессы (Process) и очереди (Queue). Источники - это элементы, от которых в модель поступает информация или объекты. Скорость поступления данных или объектов от источника обычно задается статистической функцией. Сток - это устройство для приема информации или объектов. Понятие очереди близко к понятию хранилища данных - это место, где объекты ожидают обработки. Времена обработки объектов (производительность) в разных процессах могут быть разными. В результате перед некоторыми процессами могут накапливаться объекты, ожидающие своей очереди. Часто целью имитационного моделирования является минимизация количества объектов в очередях. Тип очереди в имитационной модели может быть конкретизирован. Очередь может быть похожа на стек — пришедшие последними в очередь объекты первыми отправляются на дальнейшую обработку (LIFO: last-in-first-out). Альтернативой стеку может быть последовательная обработка, когда первыми на дальнейшую обработку отправляются объекты, пришедшие первыми (FIFO: first-in-first-out). Могут быть заданы и более сложные алгоритмы обработки очереди. Процессы - это аналог работ в функциональной модели. В имитационной модели может быть задана производительность процессов.

Простейшая имитационная модель, созданная в Arena, показана на рис. 1.4.40.

Рис. 1.4.40. Простейшая имитационная модель

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

Рис. 1.4.41. Палитра инструментов Arena

Модули типа Flowchart (в том числе Create, Dispose и Process) служат для отображения потоков объектов и могут быть перенесены на рабочее пространство модели drag&drop. Модули типа Data (например, Queue) не могут быть размещены в рабочем пространстве модели и служат для настройки параметров модели. Окно редактирования параметров появляется в нижней части модели, когда фокус установлен на модуле типа Data.

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

Для задания свойств модулю типа Flowchart необходимо дважды щелкнуть по нему и в появившемся диалоге задать значения параметров. Для задания свойств модулю Resourse (типа Data) необходимо щелкнуть по нему один раз на панели инструментов и в нижнем окне внести значения параметров (например, Busy/Hour = 15, Idle/Hour = 15 и Per Use = 2.5). Для контроля проигрывания модели необходимо внести в модель модуль Simulate и задать параметры этого модуля (например, Run Length = 40, Hours/Day = 8).

Для проигрывания модели необходимо перейти в меню Run/Go. После проигрывания модели автоматически генерируются отчеты в формате Crystal Reports (рис. 1.4.42).

Рис. 1.4.42. Отчет по результатам проигрывания модели

Модель в Arena может быть гораздо более сложной, чем представленная на рис. 1.4.40. Она может включать сотни модулей различных типов. Модули, обрабатывающие сущности (подобные модулю Server из примера), могут иметь различные состояния, например "ожидание" или "работа". Каждому состоянию можно поставить в соответствие определенное изображение и тем самым анимировать имитационную модель. В поставку Arena входит набор примеров. Один из примеров (файл Mortgage Extention l.doe) приведен на рис. 1.4.43.

Рис. 1.4.43. Модель обработки документа

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

Создавать имитационные модели без предварительного анализа бизнес-процессов не всегда представляется возможным. Действительно, не поняв сути бизнес-процессов предприятия, бессмысленно пытаться оптимизировать конкретные технологические процессы. Поэтому функциональные модели и имитационные модели не заменяют, а дополняют друг друга, при этом они могут быть тесно взаимосвязаны. Имитационная модель дает больше информации для анализа системы, в свою очередь, результаты такого анализа могут стать причиной модификации модели процессов. Наиболее целесообразно сначала создать функциональную модель, а затем на ее основе строить модель имитационную. Для поддержки такой технологии инструментальное средство функционального моделирования BPwin 4.0 имеет возможность IDEF3 в имитационную модель Arena (версии 3.6 и выше). Для преобразования диаграммы IDEF3 в модель Arena необходимо, чтобы BPwin 4.0 и Arena одновременно были запущены. В BPwin 4.0 следует открыть диаграмму IDEF3 и затем выбрать меню File/Export/Arena. Далее экспорт производится автоматически.

Поскольку имитационная модель имеет гораздо больше параметров, чем диаграмма IDEF3, в BPwin 4.0 имеется возможность задать эти параметры с помощью свойств, определяемых пользователем (UDP). В поставку BPwin 4.0 входят примеры моделей с предварительно внесенными UDP для экспорта в Arena (каталог Program Files/Computer Associates /BPwin 4.0/Samples/Arena/) и модель ArenaBEUDPs.bpl, в которой определены все необходимые для экспорта UDP и которую можно использовать в качестве шаблона для создания новых моделей. В том же каталоге находится файл BPwin IDEF3 to Arena BE mappings.doc, содержащий описание UDP, необходимых для построения имитационной модели.

Рис. 1.4.44. Диаграмма IDEF3 - пример для иллюстрации экспорта в Arena

На рис 1.4.44 показан пример функциональной модели, а на рис. 1.4.45 -результат экспорта этой модели в Arena.

Рис. 1.4.45. Имитационная модель Arena -результат импорта из BPwin

К сожалению, поставляемые с BPwin примеры после экспорта в Arena не могут быть сразу же "проиграны". В свойствах модели содержатся ошибки. Arena не допускает использования символа & в названии работы и в качестве разделителя дробной части для действительных чисел используется не запятая, а точка. Ресурсы объектов модели могут быть исправлены с помощью диалога Resource (рис. 1.4.46), после чего успешно "проиграны".

Рис. 1.4.46. Диалог Resource для редактирования ресурсов объектов имитационной модели Arena

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

1.5. Использование обучающего модуля BPwin

Основным расширением функциональности Service Pack 2 для BPwin явилось включение обучающего модуля (On-line tutorial). Для вызова обучающей программы в BPwin следует перейти в меню Help/BPwin online Tutorial. Появляется диалог BPwin Tutorial (рис. 1.5.1), в котором можно выбрать один из 10 уроков.

Рис. 1.5.1. Диалог BPwin Tutorial

Уроки представляют собой последовательное изложение материала как по методологии построения моделей (рис. 1.5.2) и нотациям IDEFO, IDEF3 и DFD, так и по технике работы с BPwin (рис. 1.5.3).

Рис. 1.5.2. Обучение построению смешанных моделей в BPwin Tutorial

Рис. 1.5.3. Обучение технике создания внутренних стрелок

Глава 2. Создание отчетов

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

2.1.1. Встроенные шаблоны отчетов

Существует три способа создания отчетов в BPwin 4.0:

с помощью встроенных шаблонов;

с помощью Report Template Builder;

с помощью RPTwin.

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

Отчеты на основе встроенных шаблонов можно создать, выбрав из меню Tools/Reports необходимый тип шаблона. Всего имеется семь типов шаблонов отчетов:

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

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

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

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

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

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

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

Синтаксические ошибки IDEF0 с точки зрения BPwin разделяются на три типа:

первых, это ошибки, которые BPwin выявить не в состоянии.

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

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

Рис. 2.1.1. Отчет Model Consistency Report

Третий тип ошибок BPwin позволяет допустить, но детектирует их. Полный их список можно получить в отчете Model Consistency Report. Список ошибок может содержать, например, неименованные работы и стрелки (unnamed arrow, unnamed activity), несвязанные стрелки (unconnected border arrow), неразрешенные стрелки (unresolved (square tunneled) arrow connections) и т. д. Пример отчета Model Consistency Report приведен на рис. 2.1.1.

При выборе пункта меню, который соответствует какому-либо отчету, появляется диалог настройки отчета. Для каждого из семи типов отчетов он выглядит по-своему. Рассмотрим типичный диалог Arrow Report (рис. 2.1.2).

Рис. 2.1.2. Диалог Arrow Report

Раскрывающийся список Standart Reports позволяет выбрать один из стандартных отчетов. Стандартный отчет - это запоминаемая комбинация переключателей, флажков и других элементов управления диалога. Для создания собственного стандартного отчета необходимо задать опции отчета, ввести имя отчета в поле списка выбора и щелкнуть по кнопке New. BPwin сохраняет информацию о стандартном отчете в файле BPWINRPT.INI. Все определения этого файла доступны из любой модели. Единственное ограничение - свойства, определяемые пользователем (User-Defined Properties). Они сохраняются в виде указателя и поэтому доступны только из "родной" модели. Стандартный отчет можно изменить (кнопка Update) или удалить (кнопка Delete).

В правом верхнем углу диалога находится группа управляющих элементов для выбора формата отчета. Доступны следующие форматы:

Labeled - отчеты включают метку поля, затем, в следующей строке, печатается содержимое поля;

Fixed Column - каждое поле печатается в собственной колонке;

Tab-Comma Delimited - каждое поле печатается в собственной колонке. Колонки разделяются знаком табуляции или запятыми;

DDE Table - данные передаются по протоколу DDE в приложение, например в MS Word или Excel;

RPTwin - отчет создается в формате RPTwin - специализированного генератора отчетов, который входит в поставку BPwin.

Опция Ordering (на отчете по стрелкам отсутствует) сортирует данные по какому-либо значению.

Опция Multi-Valued Format регулирует вывод полей в отчете при группировке данных:

Repeating Group - детальные данные объединяются в одно поле, между значениями вставляется +.

Filled — дублирование данных для каждого заголовка группы;

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

2.1.2. Создание отчетов с помощью Report Template Builder

Собственный шаблон отчета можно создать с помощью диалога Report Template Builder. Пункт меню Tools/Reports Builder вызывает диалог Report Templates (рис. 2.1.3). Кнопка New служит для создания нового шаблона, кнопка Edit - для редактирования существующего. Список выбора Output Туре позволяет задать формат результата выполнения отчета. Отчет может быть экспортирован в текстовый формат, RTF и HTML. Кнопка Run позволяет выполнить отчет.

Рис. 2.1.3. Диалог Report Templates

Щелчок по кнопке New или Edit вызывает диалог диалога Report Template Builder (рис. 2.1.4).

Рис. 2.1.4. Диалог Report Template Builder

Смысл кнопок панели управления диалога Report Template Builder приведен в табл. 2.1.1.

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

Таблица 2.1.1. Кнопки панели управления диалога Report Template Builder (слева направо)

Кнопка Предназначение Создать новый шаблон Открыть существующий шаблон Сохранить шаблон. Если шаблон сохраняется впервые, предлагается внести имя шаблона Выполнить отчет Вызов диалога Properties Удаление пункта отчета

Для создания новой секции отчета необходимо выбрать тип объекта модели и щелкнуть по кнопкеПо умолчанию в отчет включается только имя объекта. Для включения других свойств необходимо с помощью меню Edit/Properties или соответствующей кнопки на панели инструментов вызвать диалог Properties (рис. 2.1.5). Вкладка Property Tree позволяет включить в отчет свойство объекта, а вкладка Table -стиль, размер и цвет шрифта. В зависимости от типа редактируемого объекта диалог Properties может иметь дополнительные вкладки.

Рис. 2.1.5. Диалог Properties

В результате выполнения отчет экспортируется либо в текстовый файл формата RTF или в файл формата HTML (рис. 2.1.6).

Рис. 2.1.6. Результат выполнения отчета

2.2. Создание отчетов в RPTwin

2.2.1. Создание нового отчета

RPTwin является специализированным генераторам отчетов, который позволяет создавать качественные отчеты по моделям процессов и данных. К сожалению, в RPTwin не входит в поставку BPwin 4.0, однако создавать отчеты с его помощью можно предварительно установив его на том же компьютере, что и BPwin 4.O. Функциональность RPTwin позволяет создавать не просто отчеты презентационного качества, что само по себе очень важно. Включение в RPTwin более 40 функций позволяет производить сложную обработку данных, получая при этом результат, который невозможно получить средствами ERwin или BPwin. Например, при оценке функциональной модели BPwin можно использовать средства стоимостного анализа (ABC) и свойства, определяемые пользователем (UDP) (см. гл. 1). По умолчанию общая стоимость процесса вычисляется как сумма стоимостей работ декомпозиции. В отличие от стоимостного анализа BPwin не может производить подсчет суммарного значения свойства UDP. Экспорт отчета по UDP в RPTwin позволяет создать отчет, включающий в себя сложную обработку данных, в том числе подсчет суммирующего значения UDP, среднего значения, максимального значения и т. д. и т. п.

После создания отчета в ERwin или BPwin и выбора RPTwin в качестве формата (Report Format) возникает диалог сохранения данных отчета, где необходимо указать имя файла. Все отчеты RPTwin создаются на основе файла данных отчета, который имеет расширение LWD. Запускается RPTwin, и возникает диалог New Report (рис. 2.2.1). Новый отчет можно создать и непосредственно из среды RPTwin (меню File/New), при создании следует указать имя файла данных отчета (LWD).

Рис. 2.2.1. Диалог New Report

В диалоге New Report можно выбрать тип создаваемого отчета.

Quick Reports - создание простейших отчетов:

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

Vertical. Простой вертикальный отчет, в котором данные располагаются вертикально, в одну колонку, одно поле под другим. RPTwin автоматически создает вертикальный отчет, включая в него все объекты файла данных.

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

Guided Reports - при выборе отчета Guided Reports возникает диалог Guided Report (рис. 2.2.2), в котором, начиная с простого отчета, можно шаг за шагом создать отчет с сортировкой, группировкой и сложным форматированием данных:

Group/Totals. Табличный отчет с автоматической группировкой и сортировкой данных. В отчет также включаются суммирующие значения.

Рис. 2.2.2. Диалог Guided Report

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

2.2.2. Инструментальная среда RPTwin

После выбора типа отчета в диалоге New Report и задания необходимых опций отчет создается автоматически. В окне RPTwin показывается окно DataSet Columns и шаблон отчета (рис. 2.2.3).

Рис. 2.2.3. Шаблон отчета

Шаблон отчета включает несколько секций:

Report Header - печатается единожды в начале отчета. В примере на рис. 2.2.3 в этой секции расположены текстовое поле "Отчет по стрелкам" и дата отчета;

Page Header - печатается в верхней части каждой страницы. В примере на рис. 2.2.3 в этой секции расположены текстовые поля - заголовки колонок;

Group Header - печатается в начале каждой группы. В примере отчет сгруппирован по имени стрелки. Секция Group Header содержит текстовое поле Arrow Name и поле данных - имя стрелки (Arrow Name);

Detail - печатается для каждой строчки набора данных (файл .LWD). В примере содержит поля набора данных отчета по стрелкам;

Group Footer - печатается в конце каждой группы. Обычно в этой секции располагаются суммирующие по группе значения;

Page Footer - печатается в нижней части каждой страницы. Может, например, содержать номер страницы;

Report Footer - печатается единожды в начале отчета. Обычно в этой секции располагаются суммирующие по отчету значения.

В секциях отчета могут располагаться следующие элементы:

Data Fields - поля, отображающие данные из .LWD-файла;

Text Fields - используются для внесения в отчет поясняющего текста;

Formula Fields - вычисляемые поля;

Special Fields - специальные поля, например время, номер страницы, номер записи и т. д.;

OLE объекты (Object Link and Embedding) - специальные объекты (обычно графические, связываемые с OLE-серверами (PC Paintbrush, MS Excel, MS Word и т. д.).

В верхней части окна RPTwin располагается панель инструментов. Функциональность панели инструментов доступна из основного меню RPTwin и показана в табл. 2.2.1.

Таблица 2.2.1. Описание элементов управления основной панели инструментов RPTwin

Элементы управления Описание Соответствующие пункты меню Создать новый отчет File/New

Открыть отчет File/Open

Сохранить отчет File/Save

Напечатать отчет File/Print

Просмотр отчета File/Print Preview

Привязка объектов Layout/Snap отчета к сетке

Выбор стиля шрифта

Выбор типа и размера шрифта

Форматирование поля

RPTwin имеет также палитру инструментов (ТооШох). Назначение кнопок палитры инструментов приведено в табл. 2.2.2.

Таблица 2.2.2. Описание элементов управления палитры инструментов

DataSet Columns (см. рис. 2.2.3) показывает список полей набора данных из LWD-файла. Эти поля могут быть включены в отчет при помощи техники drag&drop. Список DataSet Columns можно перемещать по рабочему пространству отчета, можно скрыть его или вновь сделать видимым (пункт меню View/DataSet Columns List).

2.2.3. Вставка и форматирование объектов отчета

Созданный в диалоге New Report отчет может быть изменен - в него могут быть добавлены новые объекты, свойства существующих объектов могут быть изменены.

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

■ простое поле данных (Simple Data Field) представляет собой колонку набора данных (файл .LWD). В режиме дизайна отображается именем колонки набора данных, например ENTITY NAME или ATTRIBUTE NAME;

специальное поле (Special Function) показывает дату (Date) и время (Time) выполнения отчета, номер страницы (Page Number), номер строки (Record Number) и общее количество строк (Record Count);

формула (Formula) позволяет производить сложные вычисления и обработку данных. (Создание и использование формул будет рассмотрено в 2.4.)

Поля могут быть включены в любую секцию отчета. Простые поля можно включить в отчет, просто "перетаскивая" их (drag&drop) из окна DataSet Columns List в соответствующую секцию.

Для включения специального поля можно воспользоваться палитрой инструментов (см. табл. 2.2.2) или меню Insert/Special Field. Специальное поле должно быть включено в строго определенную секцию отчета. Так, например, номер страницы может быть включен в Page Header или в Page Footer, общее количество строк (Record Count) - в Group Footer, Page Footer или Report Footer.

Для редактирования свойств полей данных следует щелкнуть правой кнопкой мыши по полю и выбрать во всплывающем меню пункт Data Field Properties.

Возникает диалог Data Field Properties (рис. 2.2.4), в котором можно изменить следующие свойства поля:

имя поля (поле ввода Name);

координаты поля в отчете и его размеры (Position, Height и Width). Изменить координаты поля можно также просто, "перетащив" поле по рабочему пространству отчета, "зацепив" его мышью. Изменить размеры поля можно также непосредственно в рабочем пространстве отчета. Для этого следует щелкнуть по полю. Появятся габаритные указатели поля Arrow Dest Type. "Зацепив" мышью такой указатель, можно увеличить или уменьшить размер поля. Опция Can be squeezed up if no data особенно важна для вертикальных отчетов. Если она включена, то строка, не содержащая данных, не будет печататься. Ширина поля может быть установлена фиксированной (значение Fixed Width в комбинированном списке справа от поля Width), может автоматически устанавливаться по ширине поля данных (Adjust Width to Data) или максимально возможной - до следующего поля справа или правой границы отчета (Expand Right to Margin or Next Item);

Рис. 2.2.4. Диалог Data Field Properties

расположение длинного поля в несколько строчек (Word Wrap);

рамки поля (Borders);

фон поля (Patterns);

кроме того, можно скрыть поле, если повторяются его значения (опция Suppress группы Repeating Values). Если при включенной опции Suppress включена также опция Redisplay after Group, значение поля печатается один раз в начале каждой группы, даже если оно является повторяющимся. Если включена опция Redisplay after Page, значение поля печатается один раз в начале каждой страницы.

Текстовые поля (Text Field) могут использоваться в отчете для заголовков, подписей и другой поясняющей информации. Они могут содержать буквы, цифры и специальные символы. Для вставки текстового поля можно воспользоваться кнопкой в палитре инструментов или меню Insert/Text Field.

При внесении поля или при его редактировании (для редактирования свойств текстового поля следует щелкнуть правой кнопкой мыши по полю и выбрать во всплывающем меню пункт Text Field Properties) возникает диалог Text Field Properties (рис. 2.2.5), в котором можно внести текст поля (Text), имя (Name), изменить рамки (Borders), его размеры и расположение на отчете.

Для удаления поля следует щелкнуть по нему левой кнопкой мыши и нажать на клавишу Delete на клавиатуре.

Рис. 2.2.5. Диалог Text Field Properties

Помимо текстовых или специальных полей в отчет могут быть включены OLE-объекты. Для вставки текстового поля можно воспользоваться кнопкой в палитре инструментов или меню Insert/OLE Object. При внесении OLE-объекта возникает диалог Вставка объекта (Insert Object), рис. 2.2.6, в котором следует указать либо тип вновь создаваемого объекта, либо имя файла, содержащего объект. Если вставляется существующий объект, он будет добавлен в секцию отчета, если новый - вызовется соответствующее приложение для создания объекта.

Рис. 2.2.6. Диалог "Вставка объекта"

Для редактирования OLE-объекта следует дважды щелкнуть по нему кнопкой мыши. Вызывается приложение для редактирования объекта, причем в большинстве случаев меню приложения встраивается в меню RPTwin.

Некоторые OLE-объекты могут быть преобразованы в другой тип. Для преобразования типа объекта следует щелкнуть по нему правой кнопкой мыши и выбрать во всплывающем меню пункт "Объект/Преобразовать" (Object/Convert). В появившемся диалоге "Преобразование" (Convert) следует указать новый тип объекта и щелкнуть по кнопке ОК.

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

2.2.4. Группировка и сортировка данных отчета

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

Для установления сортировки и группировки следует выбрать пункт меню Layout/Sorting and Grouping. Появляется диалог Sorting/Grouping (рис. 2.2.7).

Рис. 2.2.7. Диалог Sorting/Grouping

В левом списке диалога (DataSet Columns) содержатся имена всех полей набора данных, в правом (Sort/Group On) - список полей, по которым производится сортировка или группировка.

Для установки сортировки по полю необходимо выбрать его в левом списке и щелкнуть по кнопке Add>. Затем следует выбрать опцию Sort Only и установить порядок сортировки - по возрастанию (Ascending) или по убыванию (Descending). Опция Case Sensitive устанавливает режим сортировки - учитывать ли при сортировке регистр данных.

Для установки группировки по полю необходимо выбрать его в левом списке и щелкнуть по кнопке Add>. Затем следует выбрать опцию, Group and Sort и установить порядок сортировки. Группы сортируются автоматически - нельзя установить группировку по полю без сортировки. Опции with Header и with Footer (установлены по умолчанию) включают в отчет секции Group Header и Group Footer.

RPTwin позволяет установить сортировку и группировку по вычисляемому значению. Для создания вычисляемого значения следует щелкнуть по кнопке Sort/Group on Calculated Value и в появившемся диалоге Formula Editor набрать текст формулы (например, "LTrim ({Arrow Name})"). Синтаксис формул будет рассмотрен в 2.2.7-2.2.9. Созданная формула автоматически добавляется в правый список диалога Sorting/Grouping.

2.2.5. Изменение файла данных отчета

Любой отчет RPTwin использует в качестве источника единственный файл данных (.LWD), имя которого указывается при создании отчета. Иногда необходимо использовать созданный шаблон отчета (файл .LWR.) для работы с различными наборами данных. RPTwin позволяет изменить файл набора данных.

Для этого необходимо выбрать пункт меню Options/Current DataSet. Появляется диалог Current DataSet (рис. 2.2.8), который содержит два поля ввода - DataSet Currently In Use By This Report и DataSet Linked To This Report. Поле DataSet Currently In Use By This Report показывает файл данных, который используется в отчете. В поле DataSet Linked To This Report показывается файл, который сохраняется вместе с отчетом. Обычно в обоих полях показывается один и тот же файл.

Рис. 2.2.8. Диалог Current DataSet

Если необходимо временно использовать другой файл данных, следует указать его имя в верхнем поле. Новый файл данных должен иметь те же самые имена колонок, что и старый; типы колонок также должны совпадать. Если имена или типы колонок не совпадают, поля отчета получают имя Bad Formula.

Если необходимо изменить файл данных для его постоянного использования в дальнейшем, следует указать его имя в нижнем поле и щелкнуть по кнопке Link. Указанный файл данных (*.LWD) будет связан с текущим файлом шаблона отчета (*.LWR). По умолчанию указывается полное имя файла (путь + имя), которое запоминается в шаблоне отчета. Если не указывать путь (кнопка No Path), то шаблон отчета не привязывается к конкретному месту на диске. В этом случае RPTwin сначала ищет файл данных в каталоге по умолчанию (DATASETS), затем в каталоге, в котором содержится файл шаблона отчета, затем в текущем каталоге.

2.2.6. Изменение свойств отчета

RPTwin позволяет изменять свойства как уже созданного отчета, так и новых отчетов. Свойства существующего отчета редактируются в диалогах Current Layout и Page Layout. Так, рассматриваемые ниже свойства Show Text Borders, Add Names to New Data Fields, Snap Objects To Grid, Show Grid, Measurement Units, Number Formats и Enable Case Sensitive Sort для уже созданного отчета можно изменить в диалоге Current Layout (меню Options/Current Layout).

Те же самые свойства для вновь создаваемых отчетов редактируются в диалоге Preferences (рис. 2.2.9).

Опция Default Data Format позволяет задать форматирование полей отчета по умолчанию. Отдельно задается формат для полей разных типов: Datetime, Date, Time, Number, Money. Форматирование каждого поля в уже созданном отчете можно изменить в диалоге Data Field Properties (см. рис. 2.2.4).

По умолчанию RPTwin создает многоколонный отчет, разбивая его по ширине, в случае необходимости - на несколько страниц. Если включить опцию Fit All Columns on One Page, то колонки будут сжаты так, чтобы уместить отчет по ширине на одной странице.

Рис. 2.2.9. Диалог Current DataSet

В группе Margins устанавливается ширина поля отчета в сантиметрах или дюймах (Units).

Если опция Show Text Borders включена, все текстовые поля отчета заключаются в рамки.

При включенной опции Add Names to New Data Fields новые поля вносятся в отчет вместе с текстовым полем - именем колонки в файле данных.

Snap Objects To Grid позволяет жестко связать поля с координатной сеткой.

Show Grid - показывает координатную сетку.

В группе Number Formats задается формат числовых полей - разделители, символ валюты и др.

Опция Enable Case Sensitive Sort позволяет учитывать при сортировке различия в регистре.

2.2.7. Создание формул RPTwin

RPTwin позволяет преобразовать в формулу любое поле данных. Для этого в диалоге Data Field Properties (см. рис. 2.2.4) следует щелкнуть по кнопке Formula Editor. Возникает диалог Formula Editor (рис. 2.2.10).

Рис. 2.2.10. Диалог Formula Editor

По умолчанию в верхнем поле диалога (Formula) отображается имя теКуЩего поля данных отчета. В это поле следует внести текст создаваемой (Ьормулы. В левом списке диалога DataSet Columns содержится список колонок файла данных отчета, в правом (Functions) - список функций gpTwin. В нижнем списке (Operators) содержится список операторов. Для внесения колонки, функции или оператора в текст формулы следует дважды щелкнуть по соответствующей строчке списка. Группа кнопок Edit облегчает редактирование текста формулы. Текст формулы должен удовлетворять требованиям синтаксиса формул RPTwin. Если формула содержит ошибку, то при закрытии диалога Formula Editor (кнопка OK) возникнет диалог RPTwin с сообщением об ошибке.

Рассмотрим синтаксические правила формул RPTwin.

Имена колонок. Имена колонок не должны начинаться с цифры и не должны содержать специальных символов (пробел, символ оператора и т. д.). Имя колонки в примере на рис. 2.2.10 содержит пробел, что является ошибкой. Для использования имен колонок, содержащих специальные символы, их следует заключить в фигурные скобки. Имена полей, не содержащие специальных символов, можно использовать без скобок. Имя "Arrow Dest. Type" - неверное, имена "{Arrow Dest. Type}" и "Name" -не содержат ошибки. Если имя колонки содержит пробелы в начале или конце строки, эти пробелы должны быть заключены в фигурные скобки -"{Name}" (два пробела в начале имени) или "{Name }" (два пробела в конце имени).

Операторы. RPTwin поддерживает три типа операторов:

арифметические: сложение (+), вычитание (-), умножение (*), деление (/);

текстовый оператор конкатенации (&);

" операторы сравнения, использующиеся в предикате конструкции If (<=, <, =, >=, >);

■логические операторы (is in, contains, and, or, not, is null, is not null).

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

Оператор конкатенации позволяет сложить значения текстовых полей. При создании формул, оперирующих с текстом, следует учитывать, что строковые константы заключаются в двойные кавычки. Так, если значение поля Arrow Dest. - "Брак", а поля Arrow Name - "Output", то результатом выполнения формулы "{Arrow Dest.}&" "&{ Arrow Name}" будет "Брак Output".

Типы данных. При выполнении действий над данными необходимо соблюдать правила соответствия типов. Если создать формулу ""Arrow" + 1.0", то RPTwin выдаст сообщение об ошибке несоответствия типов - текст не может быть сложен с числом. RPTwin различает пять типов данных:

Number;

Text; • Date;

Time;

Datetime.

Если возвращаемое значение формулы строка, то в некоторых случаях при несоответствии типов RPTwin не выдает ошибки, а конвертирует операнды в соответствующий тип. Например, выражение "3&5" будет выполнено без ошибки. Число 3 конвертируется в строку "3", 5 - в "5", результатом выполнения формулы будет строка "35".

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

Арифметические операторы могут использоваться только с числами. Если возвращаемое значение число, автоматически конвертация типов не производится. Для конвертации типов в этом случае следует явно использовать функции конвертации (см. табл. 2.2.3).

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

2.2.8. Функции RPTwin

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

Агрегативные функции позволяют производить вычисления по нескольким строкам отчета. Некоторые функции (Sum, Avg, Min, Max, Count) выполняются контекстно, т. е. возвращают результат в зависимости от той секции отчета, в которой находятся. Например, если функция Sum(number) находится в секции Group Footer, она возвращает сумму, вычисленную по группе, если в Page Footer - то по странице. Другие агрегативные функции (GroupAvg GroupSum, GroupMin, GroupMax, GroupCount, ReportAvg, ReportCount, ReportMax, ReportMin, ReportSum) возвращают значение независимо от их расположения в отчете. Даже если функция ReportSum (number) находится в секции Group Footer, она возвращает сумму, вычисленную по всему отчету. Агрегативные функции группы, такие, как GroupAvg, вычисляют значения независимо от того, в какой секции текущей группы они расположены. Если такая функция располагается, например, в секции Report Footer, она вычисляет агрегативное значение по всему отчету.

RPTwin является двухпроходным (Two-Pass, другой термин - Look-Ahead) генератором отчетов. Это означает, что отчет выполняется в два этапа. На первом этапе просматриваются все данные и вычисляются значения функций. На втором этапе происходит непосредственно процесс печати или вывода на экран в режиме предварительного просмотра. Поэтому значения агрегативных функций Sum, Avg, Min, Max, Count будут вычисляться одинаково, независимо от того, расположены ли они в секции Footer или Header.

Полный список функций RPTwin приведен в табл. 2.2.3.

Таблица 2.2.3. Функции RPTwin

2.2.9. Использование формул RPTwin

Рассмотрим построение отчета RPTwin по модели процессов, изображенной на рис. 2.2.11. Модель описывает процесс изготовления изделия и имеет три уровня декомпозиции. В ней описаны следующие свойства, определяемые пользователем (UDP):

уровень декомпозиции (Integer List, допустимые значения в модели - 0,1,2);

потребление электроэнергии, кВт-ч (Real Number);

потребление воды, т (Real Number).

Контекстной работе ("Изготовление изделия") присвоено значение UDP "Уровень декомпозиции", равное 0, работам на диаграмме декомпозиции контекста -1 и работам на диаграммах декомпозиции нижнего уровня -2. Значения свойств "Потребление электроэнергии, кВт-ч" и "Потребление воды, т" присвоены только работам на диаграммах декомпозиции нижнего уровня.

Создание UDP в BPwin и присвоение значений работам подробно описано в 1.3.

Рис. 2.2.11. Дерево узлов модели процессов

Непосредственно в среде BPwin невозможно оценить количество ресурсов (электроэнергия и вода), необходимых для производства изделия, поскольку невозможно производить арифметические операции с UDP. В отчете Diagram Object Report, фрагмент которого приведен на рис. 2.2.12, можно получить только список работ с указанием их UDP, но невозможно отфильтровать работы и произвести расчеты суммарных значений, необходимых для производства изделия ресурсов.

Рис. 2.2.12. Отчет по UDP (Diagram Object Report), полученный средствами BPwin

Создать отчет со сложной обработкой данных возможно только средствами RPTwin. Для создания такого отчета необходимо в диалоге настройки отчета Diagram Object Report в качестве формата отчета указать RPTwin, после чего щелкнуть по кнопке Report. В появившемся диалоге сохранения файла следует указать имя файла данных отчета (.LWD). После этого автоматически запускается RPTwin и появляется диалог New Report. В диалоге New Report в качестве типа создаваемого отчета следует указать Columnar. Создается шаблон отчета, включающий в себя все колонки файла набора данных отчета (рис. 2.2.13).

Рис. 2.2.13. Шаблон отчета "Ресурсы, необходимые для изготовления изделия "

Фрагмент отчета (режим предварительного просмотра) представлен на рис. 2.2.14.

Ресурсы, необходимые для изготовления изделия

11/20/2001

Activity NameУровеньПотребление Потребление

декомпозиции элекгроэнерг воды.т ии, кВт ч

Изготовление изделияО

Переработка сырья1

Сортировка брака250

Изготовление полуфабриката2402

Изготовление деталей1

Выбор способа изготовления210

детали

Рис. 2.2.14. Отчет "Ресурсы, необходимые для изготовления изделия"

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

Поскольку UDP, определяющие потребление ресурсов, заданы только для работ нижнего уровня декомпозиции, можно оставить в отчете только эти работы. Для установки фильтра в среде RPTwin нужно выбрать пункт меню Options/Filter. В диалоге Filter (рис. 2.2.15) следует выбрать опцию Include и щелкнуть по кнопке Formula Editor.

Рис. 2.2.15. Диалог Filter

В диалоге Formula Editor нужно создать формулу {Уровень декомпозиции}=2

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

Теперь можно удалить из отчета поле и заголовок "Уровень декомпозиции".

Сгруппируем работы по уровню энергопотребления. Для этого следует выбрать пункт меню Layout/Sorting and Grouping. Будем считать, что работы, имеющие значение UDP "Потребление электроэнергии, кВт-ч" больше 10, относятся к высокому уровню энергопотребления, от 5 до 10 -к среднему и менее 5 - к низкому. В файле данных отчета нет колонки, непосредственно указывающей на уровень энергопотребления, поэтому следует провести группировку по вычисляемому значению. Для создания вычисляемого значения в диалоге Sorting/Grouping следует щелкнуть по кнопке Sort/Group on Calculated Value и в появившемся диалоге Formula Editor набрать текст формулы:

If {Потребление электроэнергии, кВт-ч} >10 Then "Высокие энергозатраты"

Else If {Потребление электроэнергии, кВт-ч} < 5

Then "Низкие энергозатраты" Else "Средние энергозатраты"

В шаблоне отчета создаются две новые секции - Group Header и Group Footer.

В секцию Group Header поместим формулу

If {Потребление электроэнергии, кВт-ч} >10 Then "Высокие энергозатраты"

Else If {Потребление электроэнергии, кВт-ч} <5

Then "Низкие энергозатраты" Else "Средние энергозатраты"

В секцию Group Footer поместим формулы с агрегативными функциями: "Итоговое потребление воды работ с " & (If {Потребление электроэнергии, кВт-ч} >10 Then "высоким" Else If {Потребление электроэнергии, кВт-ч} <5 Then "низким" Else "средним") &" энергопотреблением- " &GroupSum ({Потребление воды, т})&", т"

И

"Итоговое потребление электроэнергии работ с " & (If {Потребление электроэнергии, кВт-ч} >10 Then "высоким" Else If {Потребление электроэнергии, кВт-ч} <5 Then "низким" Else "средним") &" энергопотреблением - " &GroupSum ({Потребление электроэнергии, кВт-ч})&", кВт-ч"

В секции Report Footer расположим формулы

"Итоговое потребление электроэнергии " &ReportSum ({Потребление электроэнергии, кВт-ч})&", кВт-ч"

и

"Итоговое потребление воды " &ReportSum ({Потребление воды, т})&",т" На рис. 2.2.16 представлен результат - итоговый отчет по потреблению ресурсов, который содержит суммирующую информацию по UDP и сложную группировку по вычисляемому полю. Суммирующие показатели потребления ресурсов вычисляются как по всему отчету, так и по категориям работ.

Ресурсы, необходимые для изготовления изделия

Имя работыПотребление воды, т Потребление электроэнергии, кВт-ч

Высокие энергозатраты

Испытание на стенде2 40

Изготовление полуфабриката2 40

Переработка полуфабриката в деталь6 60

Итоговое потребление электроэнергииработ с высоким энергопотреблениеи -140, кВт-ч Итоговое потребление воды работ с высоким энергопотреблением-10, т

Низкие энергозатраты

Проверка блоков0 3

Внешний осмотр0 1

Выбор способа изготовления детали0 1

Проверка качества полуфабриката0 4

Итоговое потребление электроэнергииработ с низким энергопотреблением - 9, кВт-ч Итоговое потребление воды работ с низким энергопотреблением-0,т

Средние энергозатраты

Сборка блоков1 10

Пробное включение1 10

Окончательная сборка1 5

Сортировка брака0 5

Итоговое потребление электроэнергииработ со средним энергопотреблением- 30, кВт-ч

Итоговое потребление воды работ сосредним энергопотреблением - 3, т

Итоговое потребление электроэнергии 179, кВт-ч Итоговое потребление воды 13, т

Рис. 2.2.16. Итоговый отчет по потреблению ресурсов

2.3. Использование Crystal Reports для создания отчетов

2.3.1. Подготовка данных для отчета

Crystal Reports (фирма Crystal Decisions, ) является признанным лидером среди недорогих генераторов отчетов, работающих на платформе Windows. Простота использования и широкие функциональные возможности делают этот инструмент очень удобным для создания наглядных высококачественных отчетов, иллюстрирующих все детали функциональной модели, созданной в BPwin. Crystal Reports позволяет создавать отчеты, используя в качестве источников данных текстовые файлы, настольные базы данных (dBase, Paradox, Access и др.), реляционные СУБД (Oracle, MS SQLServer, Sybase, Informix и др.) и специальные источники данных, например файловую систему или OLE DB. Однако для создания отчетов на основе данных BPwin удобно использовать следующую схему:

Создать в BPwin стандартный отчет и экспортировать его по протоколу DDE в MS Excel.

Сохранить файл в формате MS Excel.

Настроить ODBC-источник для доступа к файлу MS Excel.

Использовать полученный ODBC-источник как источник данных в отчете Crystal Reports.

Для создания отчета в среде BPwin необходимо перейти в меню Tools/Reports и выбрать необходимый тип шаблона, например Arrow Report. Появляется диалог Arrow Report (рис. 2.1.2). Отчет может содержать информацию о стрелках, в том числе информацию о ветвях стрелок. Для этого необходимо включить опцию Branch Into. Для экспорта необходимо предварительно запустить MS Excel, затем в диалоге настройки отчета включить опцию DDE Table и щелкнуть по кнопке Report (рис. 2.3.1).

Рис. 2.3.1. Настройки отчета для экспорта в MS Excel

Появляется диалог (рис. 2.3.2), в котором необходимо выбрать Назначение экспорта - документ Word или книгу Excel.

Рис. 2.3.2. Настройки экспорта по протоколу DDE

После щелчка по кнопке ОК данные передаются в указанную книгу. В среде MS Excel необходимо выделить все ячейки с данными, перейти в меню "Вставка/Имя/Присвоить". В диалоге "Присвоение имени" необходимо внести имя, которое будет в дальнейшем использоваться в Crystal Reports как имя таблицы. Полученный файл MS Excel необходимо сохранить.

Рис. 2.3.3. Диалог "Присвоениеимени"

Затем следует щелкнуть по кнопке Start (Пуск) и выбрать меню Settings/Control Panel. В группе Control Panel следует щелкнуть по иконке ODBC Data Sources. В диалоге ODBC Data Sources Administrator (рис. 2.3.4) необходимо создать новый источник данных для доступа к предварительно сохраненному файлу MS Excel.

Рис. 2.3.4. Диалог ODBC Data Sources Administrator

Для создания нового ODBC-источника следует щелкнуть по кнопке Add, выбрать в качестве драйвера Microsoft Excel Driver и в диалоге ODBC Microsoft Excel Setup указать имя источника и путь к файлу данных (рис. 2.3.5)

Рис. 2.3.5. Диалог ODBC Microsoft Excel Setup

2.3.2. Инструментальная среда Crystal Reports Designer

Crystal Reports состоит из нескольких модулей, главный из которых -модуль разработки отчетов Crystal Reports Designer. Он имеет мощную и интуитивно понятную среду разработки. Ниже описана версия Crystal Reports Designer 8.5. На рис. 2.3.6 показано главное окно Crystal Reports Designer.

Рис. 2.3.6. Главное окно Crystal Reports Designer

Системное меню (Control Menu Box) находится в левом верхнем углу, кнопки Maximize и Minimize - в правом верхнем. В верхней части окна, сразу под заголовком, находится главное меню Crystal Reports (Menu bar). В нижней части окна находится строка состояния (Status Bar).

Кнопки, обозначающие наиболее часто встречающиеся действия, вынесены в панели инструментов. Всего Crystal Reports имеет четыре панели инструментов: главную (рис. 2.3.7), форматирования, вспомогательную и панель инструментов для анализа. Каждую панель можно показать или скрыть с помощью редактора Toolbars (меню View/Toolbars).

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

Рис. 2.3.7. Главная панель инструментов Crystal Reports

Главная панель инструментов имеет следующие кнопки (слева направо):

Создание отчета.

Открытие отчета.

Сохранение отчета.

Печать отчета.

Переход в режим просмотра отчета.

Экспорт отчета.

Обновление отчета.

Вырезка фрагмента текста или объекта отчета.

Копирование фрагмента текста или объекта отчета.

Вставка фрагмента текста или объекта отчета. Отмена действия.

Отказ от отмены действия.

Создание гиперссылки.

Создание поля базы данных.

Создание текстового объекта.

Создание суммирующего поля.

Вызов эксперта создания отчета.

Вызов эксперта форматирования секций отчета.

Выборка данных.

Сортировка данных.

Создание диаграммы.

Вставка в отчет географической карты.

Поиск в отчете.

Масштабирование отчета.

Вызов контекстной справки.

Панель форматирования содержит кнопки форматирования полей отчета и становится доступной, только если фокус установлен на соответствующем объекте отчета.

Help - мощное средство поддержки Crystal Reports. Для вызова помощи необходимо перейти в меню Hep I/Contents или нажать клавишу Fl на клавиатуре. Для получения более подробной информации можно выбрать пункты, выделенные зеленым цветом. Можно также использовать поиск для получения информации по заданной теме. Контекстную подсказку можно вызвать при нажатии клавиш Shift + Fl.

2.3.3. Создание простых отчетов в среде Crystal Reports Designer

Первый шаг создания отчета - щелчок по кнопке(Новый отчет)

на панели инструментов. Открывается диалог Report Gallery (рис. 2.3.8).

Рис. 2.3.8. Диалог Report Gallery

Он предлагает несколько опций для построения нового отчета. Существует несколько типов сложных отчетов: Form Letter, Form, Cross-Tab, Subreport, Mail Label, Drill Down и OLAP.

Рассмотрим стандартный отчет - Standard Report. После щелчка по кнопке ОК в диалоге Report Gallery открывается диалог Standard Report Expert (рис. 2.3.9).

Рис. 2.3.9. Диалог Standard Report Expert

Вкладка Data служит для выбора источника данных для отчета. Щелчок на кнопке Database вызывает диалог Data Explorer (рис. 2.3.10), в котором можно выбрать соответствующую базу данных в качестве источника данных для отчета. Доступ к базе данных может быть осуществлен с помощью ODBC или драйвера прямого доступа. Необходимо в разделе ODBC найти предварительно созданный источник Для доступа к файлу данных Excel.

Вкладка Fields позволяет с помощью кнопок Add и Remove включить в отчет необходимые поля предварительно отобранных для отчета таблиц. Щелчок на кнопке Next переключает диалог к следующей вкладке, Group диалога Standard Report Expert (рис. 2.3.12).

Рис. 2.3.12. Вкладка Group диалога Standard Report Expert

Вкладка Chart позволяет включить в отчет диаграммы. Диаграмма в Crystal Reports 8.0 может быть создана на основе агрегативной или детальной информации, на основе информации из матричных отчетов или OLAP-источников.

Вкладка Select диалога Standard Report Expert (рис. 2.3.13) позволяет отобрать данные для отчета. На вкладке можно установить для каждого поля логическое условие - предикат.

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

Вкладки Total и Тор N позволяют более эффективно обрабатывать сгруппированные данные. На вкладке Total можно выбрать поля, по которым в отчете будет проведено агрегатирование данных. Crystal Reports

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

Рис. 2.3.13. Вкладка Select диалога Standard Report Expert

Если строка удовлетворяет заданным условиям, она включается в отчет. Предикаты, установленные для различных полей, объединяются логическим "И". Кнопка Browse Data служит для просмотра значений выбранного поля, причем показываются первые 100 неповторяющихся значений. Поля и списки выбора из группы в нижней правой части вкладки контекстные - их тип и количество зависят от типа выбранного поля и условия выборки. Верхний список выбора предназначен для задания логического оператора. Содержимое списка зависит от типа поля (числовое, строковое или дата). Служебное слово not используется для отрицания условия, например условие is not equial включит в отчет строки, значения поля в которых не равно заданному.

Допускается использование следующих операторов:

equal to - равенство; применимо для поля любого типа;

one of - равенство любому значению из списка заданных; применимо для поля любого типа;

greater (less) then or equal to - больше (меньше) или равно; применимо для поля любого типа;

between - задает верхнюю и нижнюю границу значений поля; применимо для поля любого типа;

starts with - выбирает текстовые поля, начинающиеся с заданного символа;

like - выбор текстового поля по маске; допускаются маски '*' - последовательность символов и '?'- один символ;

Formula - установка выборки по формуле;

in the period - применимо для поля типа даты и даты-времени. Вкладка Style диалога Standard Report Expert (рис. 2.3.14) служит

для форматирования будущего отчета. Crystal Reports предлагает 10 стилей.

Рис. 2.3.14. Вкладка Style диалога Standard Report Expert

В дальнейшем форматирование отчета можно изменить. Кнопка в нижней части вкладки позволяет включить в отчет рисунок в формате bmp, например логотип компании.

В том случае, если отчет строится более чем по одной таблице, в диалоге Standard Report Expert становится доступной вкладка Links, которая позволяет связать данные из разных таблиц.

После щелчка на кнопке Finish открывается главное окно Report Designer (рис. 2.3.15), которое содержит две главные вкладки - Design и Preview. Вкладка Preview позволяет не только просмотреть отчет, но и редактировать его с "живыми" данными прямо в режиме просмотра. В окне просмотра можно выполнять многие операции - построение отчета, группировку, суммирование и форматирование. Вкладка Design предназначена для редактирования шаблона отчета.

Рис. 2.3.15. Главное окно Report Designer

Рассмотрим, как выглядит отчет на вкладке Design. Большая белая область в середине вкладки - Edit box - разделена на секции горизонтальными линиями. При добавлении секции в отчет (например, при группировке данных) Crystal Reports автоматически добавляет линию. Серая область слева от Edit box содержит дополнительную информацию, помогающую работать с данными и объектами. Горизонтальные линии продолжаются в серую область, определяя секции, и Crystal Reports идентифицирует каждую секцию по аббревиатуре или выбранному имени.

Секция заголовка отчета Report Header (RH) изображается единожды в самом начале отчета. Секции Page Header (РН) и Page Footer (PF) доказываются на каждой странице и обычно используются для заголовков, нумерации страниц и т. д. Секция Detail(D) - это основное содержание отчета. Секция Report Footer (RF) показывается единожды в самом конце отчета.

2.3.4. Внесение в отчет Crystal Reports новых полей

Для внесения нового поля в отчет нужно выбрать меню Insert/Database Field или щелкнуть по соответствующей кнопке на панели инструментов. Появляется диалог Field Explorer (рис. 2.3.16), который служит для внесения в отчет полей базы данных, специальных полей, формул и параметров.

Рис. 2.3.16. Диалог Field Explorer

Панель инструментов диалога Field Explorer имеет следующие кнопки (слева направо):

Режим внесения выбранного объекта в отчет.

Просмотр содержимого колонки базы данных (первые 100 неповторяющихся значений).

"Создание объекта.

"Редактирование объекта.

Переименование объекта.

Удаление объекта.

Перемещение объекта по списку вверх.

Перемещение объекта по списку вниз.

При внесении поля базы данных доступны только первые две кнопки. Для внесения поля в отчет нужно выбрать поле в списке, перейти в режим внесения объекта (левая кнопка на панели инструментов диалога Field Explorer) и щелкнуть на свободной части какой-либо секции отчета. Можно также перенести поле из списка в секцию отчета методом drag&drop.

Поля будут размещены в порядке их расположения в диалоге, но не в порядке выбора. Размер поля в отчете зависит от размера поля в базе данных. В секцию Page Header одновременно вносится текстовый объект -заголовок поля, который представляет собой название колонки в базе данных.

Для просмотра полученного отчета на вкладке Preview следует

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

Crystal Reports позволяет изменить порядок расположения полей отчета. Для этого можно просто перенести поле внутри секции или между секциями методом drag&drop. Можно также сразу перенести группу полей. Для этого нужно предварительно выбрать их, щелкнув в каждом, одновременно нажимая клавишу Shift или Ctrl.

Если создать отчет и затем сохранить или закрыть его, Crystal Reports по умолчанию вместе с ним сохраняет данные. Если после этого открыть отчет, он будет содержать сохраненные данные. Время и дата последнего обновления данных будут показаны в правой верхней части вкладки Preview. Для принудительного обновления данных следует выбрать пункт меню Report/Refresh Report Data либо нажать клавишу F5.

Для форматирования поля служит диалог Format Editor (рис. 2.3.17), который можно вызвать, щелкнув правой кнопкой мыши по полю и выбрав в контекстном меню пункт Format Field. Вкладки диалога Format Editor позволяют задавать свойства полей безусловно (поля выбора) или по условию (кнопки вызова редактора формул справа от каждого условия).

Рис. 2.3.17. Диалог Format Editor

Вкладка Common диалога Format Editor содержит следующие опции форматирования:

Keep Object Together - запрет на разрыв объекта при переходе на новую страницу; если эта опция включена, то объект, не умещающийся на текущей странице, будет перенесен на следующую целиком;

" Close Border on Page Break - если объект не умещается на текущей странице и переносится на следующую частично (разрывается на две части), каждая часть обрамляется полностью;

Can Grow - возможность печати объекта в несколько строчек;

Tool Tip Text - создание ярлыка объекта (ярлык появляется в режиме просмотра);

Text Rotation - вращение объекта (допускается горизонтальное или вертикальное размещение объекта;

" Suppress if Duplicated — если значение поля повторяется несколько раз, показывается только первое значение, остальные скрываются.

Вкладка Border позволяет создать рамку для объекта. На вкладке Fom можно установить размер, стиль и цвет шрифта. Вкладка Paragraph Formating служит для форматирования текста, если он расположен в несколько строк.*

С помощью вкладки Hyperlink можно установить гиперссылку на другой объект текущего отчета, web-сайт, адрес электронной почты или другой отчет.

Вставка в отчет текстовых объектов. Для вставки текстового объекта нужно щелкнуть на кнопке на панели инструментов или выбрать из меню Insert/Text Object. После этого следует щелкнуть на свободном месте в секции отчета, например Page Header. Разместить текстовый объект можно как в режиме Preview Window, так и в Design режиме Window (рис. 2.3.18).

Рис. 2.3.18. Текстовый объект

После размещения текстового объекта Crystal Reports переходит в режим редактирования. При помощи клавиатуры можно набрать текст, а в верхней части экрана появляется окно форматирования текстового объекта. Можно импортировать текст из текстового файла. Для этого в режиме редактирования следует щелкнуть правой кнопкой мыши на текстовом объекте и выбрать из контекстного меню Import From File. Поддерживается импорт из файлов формата ASCII, HTML и MS Word.

Текстовый объект в Crystal Reports может содержать не только текст, но и поля базы данных, формулы, специальные поля и параметры. Чтобы внести в состав текстового объекта новое поле, нужно сначала создать его в какой-либо секции отчета, а затем, находясь в режиме редактирования, переместить его (drag&drop) внутрь текстового объекта.

Вставка в отчет специальных полей. Помимо текстовых полей в отчет могут быть включены специальные поля, которые содержат дополнительную информацию, такую, как номер страницы (Page Number), номер записи (Record Number), дата отчета и т. д. Для вставки специального поля необходимо выбрать меню Insert/Special Field.

2.3.5. Группировка записей отчета Crystal Reports

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

Вкладка Border позволяет создать рамку для объекта. На вкладке Fom можно установить размер, стиль и цвет шрифта. Вкладка Paragraph Formating служит для форматирования текста, если он расположен в несколько строк.*

С помощью вкладки Hyperlink можно установить гиперссылку на другой объект текущего отчета, web-сайт, адрес электронной почты или другой отчет.

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

из меню Insert/Text Object. После этого следует щелкнуть на свободном месте в секции отчета, например Page Header. Разместить текстовый объект можно как в режиме Preview Window, так и в Design режиме Window (рис. 2.3.18).

Рис. 2.3.18. Текстовый объект

После размещения текстового объекта Crystal Reports переходит в режим редактирования. При помощи клавиатуры можно набрать текст, а в верхней части экрана появляется окно форматирования текстового объекта. Можно импортировать текст из текстового файла. Для этого в режиме редактирования следует щелкнуть правой кнопкой мыши на текстовом объекте и выбрать из контекстного меню Import From File. Поддерживается импорт из файлов формата ASCII, HTML и MS Word.

Текстовый объект в Crystal Reports может содержать не только текст, но и поля базы данных, формулы, специальные поля и параметры. Чтобы внести в состав текстового объекта новое поле, нужно сначала создать его в какой-либо секции отчета, а затем, находясь в режиме редактирования, переместить его (drag&drop) внутрь текстового объекта.

Вставка в отчет специальных полей. Помимо текстовых полей в отчет могут быть включены специальные поля, которые содержат дополнительную информацию, такую, как номер страницы (Page Number), номер записи (Record Number), дата отчета и т. д. Для вставки специального поля необходимо выбрать меню Insert/Special Field.

2.3.5. Группировка записей отчета Crystal Reports

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

записи, можно суммировать данные в каждой группе, например подсчитать

общую сумму продаж или количество покупателей в каждом городе.

Группу можно добавить с помощью вкладки Group диалога Standart Report Expert (CM. выше). При создании каждой группы в отчет добавляются новые секции - Group header и Group Footer. Можно сгруппировать информацию по полям отчета или даже по полям, которые не входят в отчет.

Для вставки группы в уже существующий отчет следует выбрать пункт меню Insert/Group или щелкнуть на соответствующей кнопке в дополнительной панели инструментов. Открывается диалог Insert Group (рис. 2.3.19).

Рис. 2.3.19. Диалог Insert Group

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

Рис. 2.3.20. Фрагмент отчета, в котором данные сгруппированы по именам работ — источников стрелок

Установка опции Keep group together предотвращает разрыв группы на разные страницы.

Использование опции Repeat group header on each new page позволяет повторить заголовок группы на каждой странице, если группа располагается на разных страницах.

Группы могут располагаться в порядке возрастания - in ascending order (от А до Z и от 1 до 9) и в порядке убывания - in descending order (от Z до А и от 9 до 1). При выборе in original order сортировка групп не производится.

Сортировка in specified order позволяет установить группировку по признаку, который не хранится в источнике данных.

Новая группа автоматически становится внутренней. Если в отчете уже существовала группа, необходимо следить за тем, чтобы логика группировки была правильной. Изменить порядок групп несложно. Для этого, находясь на вкладке Design, нужно переместить методом drag&drop заголовки секций групп.

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

Рассмотрим модель IDEF0, показанную на рис. 2.3.21. Стрелка "Звонки клиентов" разветвляется на стрелки "Запрос информации о ценах" и "Заявки на заказ". В свою очередь, стрелка "Заявки на заказ" разветвляется на стрелки "Заявки на настольные компьютеры" и "Заявки на ноутбуки".

Рис. 2.3.21. Пример диаграммы IDEF0 с разветвляющимися стрелками

Crystal Reports позволяет создавать древовидный отчет по стрелкам или работам. Рассмотрим создание древовидного отчета по стрелкам. Создадим отчет по стрелкам, как описано в 2.3.1, и включим в него поля Arrow Name и Branch From. Отчет экспортируем в MS Excel и на основе файла данных создадим стандартный отчет, как описано в 2.3.2. Затем необходимо создать группировку по первичному ключу (идентификатору) таблицы (Arrow Name), затем перейти в меню Report/Hierarchical Grouping Options. В открывшемся диалоге Hierarchical Options (рис. 2.3.22) следует включить опцию Sort Data Hierarchically и указать родительское поле группировки -Parent ID Field (в примере - Branch From).

Рис. 2.3.22. Диалог Hierarchical Options

В поле Group Ident указывается смещение вправо группы нижнего уровня отчета в сантиметрах. Уровень вложений не ограничен. Результат -отчет по стрелкам с иерархической группировкой показан на рис. 2.3.23.

Звонки клиентов

Запрос информации о иенах Заявки на заказ

Заявки на настольные компьютеры

Заявки на ноутбуки

Рис. 2.3.23. Пример отчета с иерархической группировкой

Глава 3. Связывание модели процессов и модели данных

3.1. Модель данных и ее соответствие модели процессов

Функциональная модель BPwin является основой для построения модели данных. Действительно, не имея информации о том, как работает предприятие, бессмысленно строить модель данных. Для построения модели данных удобно использовать специализированное средство фирмы Computer Associates -ERwin 4.0. К сожалению, процесс преобразования модели BPwin в модель данных плохо формализуется и поэтому не автоматизирован. Модель данных, как правило, создается вручную в среде ERwin, при этом функциональная модель используется как проектная документация.

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

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

На диаграммах ERwin сущности показываются в виде прямоугольников. Имеется несколько уровней представления модели. На уровне сущностей имя сущности показывается внутри прямоугольника (рис. 3.1.1).

Рис. 3.1.1. Фрагмент модели данных в нотации IDEF1X (уровень сущностей)

На уровне атрибутов имя сущности показано над прямоугольником, атрибуты сущности показываются в виде списка внутри прямоугольника (рис. 3.1.2).

Рис. 3.1.2. Фрагмент модели данных в нотации IDEF1X (уровень атрибутов)

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

Стрелке в модели процессов может соответствовать отдельная сущность в модели данных. Так, стрелке "Части" на рис. 3.1.3 соответствует сущность "Часть", стрелке "Конечные продукты" - сущность "Продукт".

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

Рис. 3.1.4. Преобразование стрелки в атрибут

Работы в модели процессов могут создавать или изменять данные, которые соответствуют входящим или выходящим стрелкам. Они могут воздействовать как целиком на сущности (создавая или модифицируя экземпляры сущности, рис. 3.1.5), так и на отдельные атрибуты сущности (рис. 3.1.6).

Рис. 3.1.5. Воздействие работы на сущность

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

Рис. 3.1.6. Воздействие работы на атрибуты

3.2. Экспорт данных из ERwin в BPwin и связывание объектов модели данных со стрелками и работами

Первым шагом связывания модели данных и модели процессов является экспорт данных из ERwin в BPwin. Для успешного связывания моделей необходимо, чтобы версии ERwin в BPwin соответствовали друг другу. Ниже рассмотрен экспорт и импорт моделей в ERwin 4.0 и BPwin 4.O.

Существует два способа связывания объектов модели данных и модели процессов:

Экспорт и импорт через файлы формата .ЕАХ - .ВРХ.

Синхронизация моделей, хранящихся в репозитории ModelMart.

Рассмотрим первый способ связывания моделей.

Для экспорта модели данных из ERwin в BPwin необходимо в ERwin открыть модель (рис. 3.2.1) и выбрать пункт меню File/Export/BPwin. В появившемся диалоге необходимо выбрать имя файла *.еах и нажать ОК.

Рис. 3.2.1. Модель данных, открытая в ERwin 4.0

Затем в BPwin нужно открыть модель процесса, выбрать в меню пункт File/Import/ERwin (ЕАХ), выбрать имя файла и нажать ОК. Появится диалог Import Differences Preview, в котором показывается протокол импорта (рис. 3.2.2). Для внесения данных в модель процесса следует щелкнуть по кнопке Accept. Кнопка Cancel отменяет импорт.

Рис. 3.2.2. Диалог Import Differences Preview

После внесения данных в модель процессов можно связать сущности и атрибуты со стрелками. Правой кнопкой мыши нужно щелкнуть по стрелке и выбрать в контекстном меню Arrow Data.

Появляется вкладка Arrow Data диалога Arrow Properties (рис. 3.2.3).

Рис. 3.2.3. Вкладка Arrow Data диалога Arrow Property

Для связывания атрибута со стрелкой достаточно щелкнуть по иконке выбора Ц в иерархическом списке атрибутов. При этом сущность автоматически связывается со стрелкой. Каждая стрелка в модели процессов может быть связана с несколькими атрибутами различных сущностей.

Кнопка Copy In позволяет копировать связанные данные из другой стрелки.

Кнопка Clear - все связи стрелки с данными.

Кнопка Migrate вызывает диалог Changes to Arrow Data Associations, в котором отображаются данные, мигрирующие от дочерних к родительским стрелкам (для разветвляющихся и сливающихся стрелок). При миграции возможны изменения связывания данных:

Deletions - если данные связаны с родительской стрелкой, но не связаны с дочерней, связи с родительской стрелкой удаляются;

Additions - если данные связаны с дочерней стрелкой и не связаны с родительской, добавляется связь с родительской стрелкой.

Для подтверждения изменений в диалоге Changes to Arrow Data Дввоыайопз следует щелкнуть по кнопке ОК. Миграция возможна только в моделях IDEF0 и DFD.

Как было указано выше, работы могут воздействовать на данные. Для документирования такого воздействия необходимо щелкнуть правой кнопкой мыши по работе и выбрать пункт меню Data Usage Editor (рис. 3.2.4).

Рис. 3.2.4. Диалог BPwin Data Usage Editor

В появившемся диалоге Data Usage Editor в виде иерархического списка показываются все работы модели, стрелки, которые касаются работ, сущности и атрибуты, которые были связаны со стрелками. В верхнем списке нужно щелкнуть по имени стрелки, с которой были связаны сущности и атрибуты. Для задания ассоциации достаточно щелкнуть по окну "О в иерархическом списке.

Для сущностей задается ассоциация CRUD (Create, Read, Update, Delete), Для атрибутов - IRUN (Insert, Read, Update, Nullify). Ассоциации CRUD и IRUN - это правила использования сущностей и атрибутов работами, т. е. то, что могут делать работы с входящими или исходящими данными. Данные не могут использоваться работами произвольно. Стрелки входа представляют данные, которые работа преобразует в выход или потребляет.

Такие данные могут быть обновлены (Update) или прочитаны (Read) но не могут быть созданы (Create, Insert) или удалены (Delete, Nullify)' Данные, связанные со стрелками управления, могут быть только прочитаны (Read), но не могут быть изменены - процедуры и стратегии не могут изменяться в работе. Данные, связанные со стрелками выхода, могут быть обновлены (если им соответствуют данные стрелок входа), удалены (Delete, Nullify) или созданы (Create, Insert). Для стрелок механизма ассоциации не устанавливаются.

Результат связывания объектов модели процессов можно отобразить в отчете Data Usage Report (меню Report/Data Usage Report). Ниже приведен пример такого отчета.

Arrow Name Entity Name C _R _U _DAttribute NameI _R_ U_ N

ДеталиЧастьU DВес частиU N

U DКоличествоU N

U DНазвание частиU

U DНомер частиU

3.3. Создание сущностей и атрибутов BPwin и их экспорт в ERwin

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

Для редактирования сущностей следует выбрать пункт меню Dictionary/Entity. Появляется диалог Entity Dictionary (рис. 3.3.1) - словарь сущностей. Интерфейс словаря сущностей полностью аналогичен интерфейсу словаря стрелок, описанному в 1.2. Для экспорта в ERwin в словаре Entity Dictionary следует создать новую сущность, которая может быть использована для ассоциации со стрелками сразу же после создания (до экспорта в ERwin).

Рис. 3.3.1. Диалог Entity Dictionary

Для редактирования атрибутов предварительно созданных сущностей служит словарь атрибутов (пункт меню Dictionary /Entity /Attribute).

Колонка Entity диалога Attribute Dictionary служит для связывания созданного атрибута с сущностью (рис. 3.3.2). В раскрывающемся списке, который появляется, когда фокус установлен на поле Entity таблицы, показываются только те сущности, которые созданы в диалоге Entity Dictionary или импортированы из ERwin.

Рис. 3.3.2. Диалог Attribute Dictionary

После описания сущностей или атрибутов следует сохранить данные и выйти из словаря.

Для экспорта данных в BPwin следует выбрать меню File/Export/ ERwin 4.0 (ВРХ) и указать файл, в который будет выгружена информация о модели.

В ERwin следует выбрать меню File/Import/BPwin и указать файл ВРХ, в который была выгружена информация о модели.

Возникает диалог ERwin/BPwin Import (рис. 3.3.3), в котором отображаются:

сущности и атрибуты, имеющиеся в ВРХ-файле, но отсутствующие в модели ERwin (верхнее окно - Entities/Attributes available to be imperted);

имена работ, ассоциированных с сущностями и атрибутами, на основе которых будут созданы предметные области (Subject Area) модели данных.

В примере на рис. 3.3.3 сущность "Клиент", атрибуты "Фамилия", "Имя" и "Адрес" будут импортированы из ВРХ- файла в модель ERwin.

После щелчка по кнопке Import запускается процесс импорта ВРХ-файла. Импортированная сущность (на рис. 3.3.4 - сущность "Клиент") размещается в левом верхнем углу диаграммы ERwin. Она не имеет первичного ключа и не связана с другими сущностями. Назначение атрибутов первичным ключом и связывание сущностей можно провести только средствами ERwin; другими словами, сущности и атрибуты, созданные в BPwin и затем импортированные в ERwin, можно рассмат ривать как заготовку для создания полноценной .модели данных, а не как готовую модель.

Рис. 3.3.4. Модель данных после импорта сущности "Клиент"

Глава 4. Практикум. Создание функциональной модели с помощью BPwin 4.0

4.1. Упражнение 1. Создание контекстной диаграммы

Гл. 4 содержит 16 упражнений, предназначенных для самостоятельной работы. Цель упражнений - дать читателю навык создания и редактирования функциональных моделей в BPwin 4.O. Для выполнения последующего упражнения необходимо иметь результат выполнения предыдущего, поэтому рекомендуется сохранять модель, полученную в конце каждого упражнения.

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

Основные процедуры в компании таковы:

продавцы принимают заказы клиентов;

операторы группируют заказы по типам компьютеров;

операторы собирают и тестируют компьютеры;

операторы упаковывают компьютеры согласно заказам;

кладовщик отгружает клиентам заказы.

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

Перед выполнением упражнения 1 внимательно прочитайте подразделы 1.1,1.2.1,1.2.3 и 2.1.

Запустите BPwin. (Кнопка Start/BPwin).

Если появляется диалог ModelMart Connection Manager, нажмите на кнопку Cancel.

Щелкните по кнопке. Появляется диалог I would like to. Внесите имя модели "Деятельность компании" и выберите Туре - IDEF0. Нажмите ОК.

Автоматически создается контекстная диаграмма.

Обратите внимание на кнопку: на панели инструментов. Эта кнопка включает и выключает инструмент просмотра и навигации - Model Explorer (появляется слева). Model Explorer имеет три вкладки - Activities, Diagrams и Objects. Во вкладке Activities щелчок правой кнопкой по объекту позволяет редактировать его свойства.

|6. Если вам непонятно, как выполнить то или иное действие, вы можете вызвать помощь - клавиша F1 или меню Help.

Перейдите в меню Model/Model Properties. Во вкладке General диалога Model Properties следует внести имя модели "Деятельность компании", имя проекта "Модель деятельности компании", имя автора и тип модели - Time Frame: AS-IS.

Во вкладке Purpose внесите цель - "Purpose: Моделировать текущие (AS-IS) бизнес-процессы компании" и точку зрения - "Viewpoint: Директор".

Во вкладке Definition внесите определение "Это учебная модель, описывающая деятельность компании" и цель "Scope: Общее управление бизнесом компании: исследование рынка, закупка компонентов, сборка, тестирование и продажа продуктов".

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

Во вкладке Definition внесите определение "Текущие бизнес-процессы компании".

Создайте стрелки на контекстной диаграмме (табл. 4.1.1).

Таблица 4.1.1. Стрелки контекстной диаграммы

13. С помощью кнопкивнесите текст в поле диаграммы - точку зрения и цель (рис. 4.1.1).

Рис. 4.1.1. Внесение текста в поле диаграммы с помощью редактора Text Block Editor

Результат выполнения упражнения 1 показан на рис. 4.1.2.

Рис. 4.1.2. Контекстная диаграмма 14. Создайте отчет по модели. Меню Tools/Reports/Model Report (рис. 4.1.3).

Рис. 4.1.3. Отчет Model Report

4.2. Упражнение 2. Создание диаграммы декомпозиции

Перед выполнением упражнения 2 внимательно прочитайте подраз-: делы 1.2.2 и 1.2.3.

1. Выберите кнопку перехода на нижний уровень в палитре инструментов и в диалоге Activity Box Count установите число работ на диаграмме нижнего уровня - 3 - и нажмите ОК.

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

Автоматически будет создана диаграмма декомпозиции. Правой кнопкой мыши щелкните по работе, выберите Name и внесите имя работы. Повторите операцию для всех трех работ. Затем внесите определение, статус и источник для каждой работы согласно табл. 4.2.1.

Таблица 4.2,1. Работы диаграммы декомпозиции АО

2. Для изменения свойств работ после их внесения в диаграмму можно воспользоваться словарем работ. Вызов словаря - меню Dictionary /Activity (рис. 4.2.2).

Рис. 4.2.2. Словарь Activity Dictionary

Если описать имя и свойства работы в словаре, ее можно будет внести

в диаграмму позже с помощью кнопки в палитре инструментов.

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

по кнопке I(Purge). 3. Перейдите в режим рисования стрелок. Свяжите граничные стрелки

(кнопка L=,rt на палитре инструментов так, как показано на рис. 4.2.3.

Рис. 4.2.3. Связанные граничные стрелки на диаграмме АО

4. Правой кнопкой мыши щелкните по ветви стрелки управления работы "Сборка и тестирование компьютеров" и переименуйте ее в "Правила сборки и тестирования" (рис. 4.2.4).

Рис. 4.2.4. Стрелка "Правила сборки и тестирования"

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

Альтернативный метод внесения имен и свойств стрелок -использование словаря стрелок (вызов словаря - меню Dictionary/Arrow). Если внести имя и свойства стрелки в словарь, ее можно будет внести в диаграмму позже. Стрелку нельзя удалить из словаря, если она используется на какой-либо диаграмме. Если удалить стрелку из диаграммы, из словаря она не удаляется. Имя и описание такой стрелки может быть использовано в дальнейшем. Для добавления стрелки необходимо перейти в конец списка и щелкнуть правой кнопкой по последней строке. Возникает новая строка, в которой нужно внести имя и свойства стрелки.

Создайте новые внутренние стрелки так, как показано на рис. 4.2.5.

Рис. 4.2.5.Внутренние стрелки диаграммы АО

7. Создайте стрелку обратной связи (по управлению) "Результаты сборки и тестирования", идущую от работы "Сборка и тестирование компьютеров" к работе "Продажи и маркетинг". Измените стиль стрелки (толщина линий) и установите опцию Extra Arrowhead (из контекстного меню). Методом drag&drop перенесите имена стрелок так, чтобы их было удобнее читать. Если необходимо, установите Squiggle (из контекстного меню). Результат изменений показан на рис. 4.2.6.

Рис. 4.2.6. Результат редактирования стрелок на диаграмме АО 8. Создайте новую граничную стрелку выхода "Маркетинговые материалы , выходящую из работы "Продажи и маркетинг". Эта стрелка автоматически не попадает на диаграмму верхнего уровня и имеет квадратные скобки на наконечнике:--> . Щелкните правой кнопкой мыши по квадратным скобкам и выберите пункт меню Arrow Tunnel В диалоге Border Arrow Editor выберите опцию Resolve it to Border Arrow. Для стрелки "Маркетинговые материалы" выберите опцию Тпш из контекстного меню. Результат выполнения упражнения 2 показан на рис. 4.2.7.

Рис. 4.2.7. Результат выполнения упражнения 2 - диаграмма АО

4.3. Упражнение 3. Создание диаграммы декомпозиции А2

Декомпозируем работу "Сборка и тестирование компьютеров".

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

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

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

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

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

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

Таблица 4.3.1. Работы диаграммы декомпозиции А2

Таблица 4.3.2. Стрелки диаграммы декомпозиции А2

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

Рис. 4.3.1. Результат выполнения упражнения 3

4.4. Упражнение 4. Создание диаграммы узлов

Перед выполнением упражнения 4 внимательно прочитайте подраздел 1.2.5.

Выберите меню Diagram/Add Node Tree. В первом диалоге гида Node Tree Wizard внесите имя диаграммы, укажите диаграмму корня дерева и количество уровней (рис. 4.4.1).

Рис. 4.4.1. Первый диалог гида Node Tree Wizard

2. Во втором диалоге установите опции, как на рис. 4.4.2.

Рис. 4.4.2. Второй диалог гида Node Tree Wizard

Щелкните по Finish. Создается диаграмма дерева узлов. Результат можно посмотреть на рис. 4.4.3.

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

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

Для модификации диаграммы правой кнопкой мыши щелкните по свободному месту, не занятому объектами, выберите меню Node tree Diagram Properties и во вкладке Style диалога Node Tree Properties отключите опцию Bullet Last Level. Щелкните по ОК. Результат показан на рис. 4.4.4.

Рис. 4.4.4. Результат выполнения упражнения 4

4.5. Упражнение 5. Создание FEO диаграммы

Предположим, что при обсуждении бизнес-процессов возникла необходимость детально рассмотреть взаимодействие работы "Сборка и тестирование компьютеров" с другими работами. Чтобы не портить диаграмму декомпозиции, создайте FEO-диаграмму, на которой будут только стрелки работы "Сборка и тестирование компьютеров ".

Выберите пункт меню Diagram/Add FEO Diagram.

В диалоге Add New FEO Diagram выберите тип и внесите имя диаграммы FEO. Щелкните по ОК.

Для определения диаграммы перейдите в Diagram/Diagram Properties и во вкладке Diagram Text внесите определение.

Удалите лишние стрелки на диаграмме FEO. Результат показан на рис. 4.5.1.

Рис. 4.5.1. Диаграмма FEO

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

4.6. Упражнение 6. Расщепление и слияние моделей

4.6.1. Расщепление модели

Перед выполнением упражнения 6 внимательно прочитайте подраздел 1.2.7.

Перейдите на диаграмму АО. Правой кнопкой мыши щелкните по работе "Сборка и тестирование компьютеров" и выберите Split model.

Рис. 4.6.1. Диалог Split Option

В диалоге Split Option внесите имя новой модели "Сборка и тестирование компьютеров", установите опции, как на рисунке, и щелкните по ОК (рис. 4.6.1).

Посмотрите на результат: в Model Explorer появилась новая модель, а на диаграмме АО модели "Деятельность компании" появилась стрелка вызова "Сборка и тестирование компьютеров".

Создайте в модели "Сборка и тестирование компьютеров" новую стрелку "Неисправные компоненты". На диаграмме АО это будет граничная стрелка выхода, на диаграмме АО - граничная стрелка выхода от работ "Сборка настольных компьютеров", "Тестирование компьютеров"и "Сборка ноутбуков".

4.6.2. Слияние модели

Перейдите на диаграмму АО модели "Деятельность компании".

Правой кнопкой мыши щелкните по работе "Сборка и тестирование компьютеров" и выберите Merge model.

[3. В диалоге Merge Model включите опцию Cut/Paste entire dictionaries и щелкните по ОК.

Посмотрите на результат. В Model Explorer видно, что две модели j слились. Модель "Сборка и тестирование компьютеров" осталась и может ;быть сохранена в отдельном файле. На диаграмме АО модели "Деятельность компании" исчезла стрелка вызова "Сборка и тестирование I компьютеров". Появилась неразрешенная граничная стрелка "Неисправные компоненты". Направьте эту стрелку к входу работы "Отгрузка ; и получение".

4.7. Упражнение 7. Создание диаграммы IDEF3

Перед выполнением упражнения 7 внимательно прочитайте подраздел 1.4.

1. Перейдите на диаграмму А2 и декомпозируйте работу "Сборка настольных компьютеров". В диалоге Activity Box Count (рис. 4.7.1) установите число работ 4 и нотацию IDEF3.

Рис. 4.7.1. Выбор нотации IDEF3 в диалоге Activity Box Count

Возникает диаграмма IDEF3, содержащая работы (UOW). Правой кнопкой мыши щелкните по работе, выберите в контекстном меню Name и внесите имя работы "Подготовка компонентов". Затем во вкладке Definition внесите определение "Подготавливаются все компоненты компьютера согласно спецификации заказа". 2. Во вкладке UOW внесите свойства работы (табл. 4.7.1).

Таблица 4.7.1. Свойства UOW

3.Внесите в диаграмму еще 3 работы (кнопка II).

Внесите имена работ:

Установка материнской платы и винчестера;

Установка модема;

Установка дисковода CD-ROM;

Установка флоппи- дисковода;

Инсталляция операционной системы;

Инсталляция дополнительного программного обеспечения.

4.С помощью кнопки— _ палитры инструментов создайте объект ссылки. Внесите имя объекта внешней ссылки "Компоненты".

Свяжите стрелкой объект ссылки и работу "Подготовка компонент".

5.Свяжите стрелкой работы "Подготовка компонентов" (выход) и "Установка материнской платы и винчестера". Измените стиль стрелки на Object Flow.

В IDEF3 имя стрелки может отсутствовать, хотя BPwin показывает отсутствие имени как ошибку. Результат показан на рис. 4.7.2.

Рис. 4.7.2. Результат создания VOW и объекта ссылки

6. С помощью кнопки «» на палитре инструментов внесите два перекрестка типа "асинхронное или" и свяжите работы с перекрестками, как показано на рис. 4.7.3.

Рис. 4.7.3. Диаграмма IDEF3 после создания перекрестков

7. Правой кнопкой щелкните по перекрестку для разветвления (fan-out), выберите Name и внесите имя "Компоненты, требуемые в спецификации заказа".

Создайте два перекрестка типа исключающего "ИЛИ" и свяжите работы, как показано на рис. 4.7.4.

Рис. 4.7.4. Результат выполнения упражнения 7

4.8. Упражнение 8. Создание сценария

1.Выберите пункт меню Diagram/Add IDEF3 Scenario.

Создайте диаграмму сценария на основе диаграммы IDEF3 "Сборка настольных компьютеров" (А22.1).

2.Удалите элементы, не входящие в сценарий (рис. 4.8.1).

Рис. 4.8.1. Результат выполнения упражнения 8

4.9. Упражнение 9. Стоимостный анализ (Activity Based Costing)

Перед выполнением упражнения 9 внимательно прочитайте подразделы 1.3 и 2.1.

П. В диалоге Model Properties (вызывается из меню Mode/Model Properties) во вкладке ABC Units (рис. 4.9.1) установите единицы измерения денег и времени — рубли и часы.

Рис. 4.9.1. Вкладка ABC Units диалога Model Properties

Перейдите в Dictionary/Cost Center и в диалоге Cost Center Dictionary внесите название и определение центров затрат (табл. 4.9.1).

Таблица 4.9.1. Центры затрат ABC

Для отображения стоимости каждой работы в нижнем левом углу прямоугольника перейдите в меню Model/Model Properties и во вкладке Display диалога Model Properties включите опцию ABC Data (рис. 4.9.2).

Рис. 4.9.2. Вкладка Display диалога Model Properties

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

Для назначения стоимости работе следует щелкнуть по ней правой кнопкой мыши и выбрать в контекстном меню Cost (рис. 4.9.3).

Рис. 4.9.3. Вкладка Cost диалога Activity Properties 3.

Для работ на диаграмме А2 внесите параметры ABC (табл. 4.9.2).

Таблица 4.9.2. Стоимости работ на диаграмме А2

Посмотрите результат - стоимость работы верхнего уровня (рис. 4.9.4).

Рис. 4.9.4. Отображение стоимости в нижнем левом углу прямоугольника работы

4. Сгенерируйте отчет Activity Cost Report (рис. 4.9.5).

Activity Name ftctiuity Cost Cost CenterCost Center Cost

<рУ.бль)(Рубль)

Сборка и тестирование 585 620,00 Компоненты579 200,80

компьютеров

Рабочая сила5 920,08

Управление500,00

Отслеживание расписания 500,00 Управление500,08

и управление сборкой и

тестированием

Сборка настольных1 700,00 Компоненты1 600,88

компьютеров

Рабочая сила100,08

Рис. 4.9.5. Отчет Activity Cost Report

4.10. Упражнение 10. Использование категорий UDP

Перед выполнением упражнения 10 внимательно прочитайте подразделы 1.3, 2.1 и 2.2. И. Перейдите в меню Dictionary/UDP Keywords и в диалоге UDP Keyword

List внесите ключевые слова UDP (рис. 4.10.1):

Расход ресурсов;

Документация;

Информационная система.

Рис. 4.10.1. Словарь ключевых слов UDP

Создайте UDP. Для этого перейдите в Dictionary/UDP и в словаре внесите имя UDP, например "Приложение".

Для UDP типа List необходимо в поле Value задать список значений. Для UDP - "Приложение". Внесите значение "Модуль оформления зака зов" (рис. 4.10.2).

Рис. 4.10.2. Словарь UDP

Затем внесите другие значения в соответствии с табл. 4.10.1. Для подключения к UDP ключевого слова перейдите к полю Keyword и щелкните по полю выбора.

Таблица 4.10.1. Наименование и свойства UDP

Для назначения UDP работе следует щелкнуть по ней правой кнопкой мыши и выбрать в контекстном меню UDP. Появляется вкладка UDP Values диалога Activity Properties (рис. 4.10.3).

Рис. 4.10.3. Вкладка UDP Values диалога Activity Properties

Внесите значения UDP для работ (таблица 4.10.2).

Таблица 4.10.2. Значения UDP

После внесения UDP типа Command или Command List щелчок по кнопкеприведет к запуску приложения.

В диалоге Activity Properties щелкните по кнопке Filter. В появившемся диалоге Diagram object UDP filter (рис. 4.10.4) отключите ключевые слова "Информационная система". Щелкните по ОК. В результате в диалоге Activity Properties не будут отображаться UDP с ключевыми словами "Информационная система".

Рис. 4.10.4. Диалог Diagram object UDP filter

Отметим, что свойства UDP можно присвоить не только работам, но и стрелкам.

7.Посмотрите отчет по UDP. Меню Tools/Report/Diagram Object Report.

Выберите опции отчета:

Start from Activity: A2. Сборка и тестирование компьютеров

Number of Levels: 2

User Defined Properties: Расход электроэнергии

Report Format: RPTwin.

8.Щелкните по кнопке Report. В появившемся диалоге "Сохранение файла" щелкните по кнопке "Сохранить".

Запускается генератор отчетов RPTwin и появляется диалог New Report. Выберите тип отчета Columnar (рис. 4.10.5).

Рис. 4.10.5. Диалог New Report Автоматически создается шаблон отчета (рис. 4.10.6).

Рис. 4.10.6. Шаблон отчета в RPTwin

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

9. Выберите в меню Insert/Formula Field, затем переместите маркер в секцию отчета Page Footer, затем щелкните один раз. Появляется диалог Formula Editor (рис. 4.10.7).

Рис. 4.10.7. Диалог Formula Editor

В поле Formula внесите текст формулы: Sum ({"Расход электроэнергии"})

Затем щелкните по ОК. Отчет показывается в окне просмотра (рис. 4.10.8). В нижней части страницы расположено суммирующее поле - результат вычисления формулы (на рис. 4.10.8 не видно).

Рис. 4.10.8. Окно просмотра отчета в RPTwin

4.11. Упражнение 11. Расщепление модели

Перед выполнением упражнения 11 внимательно прочитайте подраздел 1.2.7.

1.Перейдите на диаграмму АО и щелкните правой кнопкой мыщи по работе "Отгрузка и получение". В контекстном меню выберите Split Model.

В появившемся диалоге Split Option установите опцию Enable Merge /Overwrite Option, внесите имя новой модели - "Отгрузка и получение" и щелкните по ОК.

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

2.Внесите свойства новой модели:

Time Frame: AS-IS;

Purpose: Документировать работу "Отгрузка и получение";

Viewpoint: Начальник отдела;

Definition: Модель создается для иллюстрации возможностей BPwin по расщеплению и слиянию моделей

Scope: Работы по получению комплектующих и отправке готовой продукции.

3.Декомпозируйте контекстную работу на 3 работы (табл. 4.11.1).

Таблица 4.11.1. Декомпозиция работы "Отгрузка и получение"

Свяжите граничные стрелки, как показано на рис. 4.11.1.

Рис. 4.11.1. Внутренние стрелки на декомпозиции работы "Отгрузка и получение"

5. Внесите следующие внутренние и граничные стрелки (табл. 4.11.2).

Таблица 4.11.2. Внутренние и граничные стрелки на декомпозиции работы "Отгрузка и получение"

6. Туннелируйте граничные стрелки (Resolve Border Arrow). Результат выполнения упражнения показан на рис. 4.11.2.

Рис. 4.11.2. Результат выполнения упражнения 11

4.12. Упражнение 12. Слияние расщепленной модели с исходной моделью

1.Перейдите в модель "Деятельность компании". На диаграмме АО щелкните правой кнопкой мыши по работе "Отгрузка и получение".

В контекстном меню выберите Merge Model. В появившемся диалоге Merge Model установите опцию Cut/Paste entire dictionaries и щелкните по ОК.

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

Появились новые стрелки с квадратными скобками. Туннелируйте эти стрелки (Resolve Border Arrow).

2.На диаграмме АО туннелируйте и свяжите стрелки согласно рис. 4.12.1.

Рис. 4.12.1. Результат выполнения упражнения 12

4.13. Упражнение 13. Копирование работ

4.13.1. Копирование работ в другую модель

Создайте новую модель "ТЕСТ". Декомпозируйте контекстную работу в новой модели, но не вносите имена работ.

Переключите Model Explorer во вкладку Activity. В технике drag&drop перенесите какую-нибудь работу из модели "Деятельность компании" на диаграмму декомпозиции модели "ТЕСТ". В появившемся диалоге Continue with Merge? установите опцию Paste/Merge entire dictionaries и щелкните по ОК. В результате работа из модели "Деятельность компании" копируется на новую диаграмму модели "ТЕСТ".

4.13.2. Перемещение работ в той же самой модели

Щелкните по работе в модели "ТЕСТ" и переместите работу на место неназванной работы на другой диаграмме. В появившемся диалоге Continue with Merge? щелкните по ОК. В результате работа переносится из одной диаграммы на другую.

4.14. Упражнение 14. Создание модели ТО-ВЕ (реинжиниринг бизнес-процессов)

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

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

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

Работа "Сборка и тестирование компьютеров" должна быть реорганизована и названа "Производство продукта". Будут созданы работы "Разработать конфигурацию", "Планировать производство" и "Собрать продукт".

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

Функции диспетчера в работе "Сборка и тестирование компьютеров" должны быть заменены на функции планировщика.

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

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

4.14.1. Расщепление и модификация модели

1.Измените свойства модели "Деятельность компании":

Model Name: Предлагаемая модель компании;

" Time Frame: TO-BE;

Purpose: Документировать предлагаемые изменения бизнес-процессов компании.

Переименуйте работу "Сборка и тестирование компьютеров"в "Производство продукта". Расщепите эту работу в модель с тем же названием.

Модифицируйте отщепленную модель. Переместите работу "Тестирование компьютеров" с диаграммы АО "Производство продукта" на диаграмму А2.1 "Сборка настольных компьютеров".

Переименуйте работу "Сборка настольных компьютеров" на диаграмме АО в "Сборку продукта".

Удалите работу "Сборка ноутбуков".

Переименуйте стрелку "Заказы на настольные компьютеры" в "Заказы на изготовление".

Переименуйте "Отслеживание расписания и управление сборкой и тестированием" в "Планирование производства".

Создайте работу "Разработать конфигурацию".

Создайте ветвь стрелки "Персонал производственного отдела", назовите ее "Дизайнер" и направьте как механизм к работе "Разработать конфигурацию".

Создайте стрелку "Стандарты на продукцию" и направьте ее от выхода "Разработать конфигурацию" к границе диаграммы. Туннелируйте эту стрелку (Resolve Border Arrow). Создайте ветвь этой стрелки, идущую к управлению работы "Планирование производства" и назовите ее "Списком необходимых компонентов ".

Удалите стрелку "Правила сборки и тестирования". Создайте ветвь стрелки "Стандарты на продукцию", идущую к управлению работы "Сборка продукта" и назовите ее "Правилами сборки и тестирования".

Переименуйте стрелку "Диспетчер" в "Планировщика производства".

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

Добавьте стрелку "Информация от поставщика" как граничную управляющую к работе "Планирование производства".

Добавьте стрелку "Заказ поставщику" как граничную стрелку выхода от работы "Планирование производства".

Туннелируйте эти стрелки (Resolve Border Arrow).

На диаграмме А-0 туннелируйте стрелку (Resolve Border Arrow) "Собранные компьютеры" и свяжите ее на диаграмме АО с выходом работы "Сборка продукта".

Результат выполнения первой части упражнения 14 приведен на рис. 4.14.1 и 4.14.2.

Рис. 4.14.1. Результат выполнения первой части упражнения 14 -диаграмма АО

Рис. 4.14.2. Результат выполнения первой части упражнения 14 —

диаграмма А-0

4.14.2. Слияние модели

1.Перейдите к работе "Производство продукта" в модели "Деятельность компании". Щелкните правой кнопкой мыши по работе. В контекстном меню выберите Merge Model. В появившемся диалоге Merge Model установите опцию Cut/Paste entire dictionaries, опцию Overwrite existing fields и щелкните по ОК.

Модели должны слиться.

На диаграмме АО туннелируйте стрелки (Resolve Border Arrow,) "Информация от поставщика" и "Заказ поставщику".

Направьте стрелку "Прогноз продаж" с выхода "Продажи и маркетинг" на управление "Производство продукта".

Направьте стрелку "Стандарты на продукцию" с выхода "Производство продукта" на управление "Продажи и маркетинг".

Удалите ветвь стрелки управления "Правила и процедуры" работы "Производство продукта".

Закройте модель "Производство продукта".

Результат выполнения второй части упражнения 14 приведен на рис. 4.14.3 и 4.14.4.

Рис. 4.14.3. Результат выполнения второй части упражнения 14-

диаграмма А-0

Рис. 4.14.4. Результат выполнения второй части упражнения 14-

диаграмма АО

4.14.3. Использование Model Explorer для реорганизации дерева декомпозиции

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

Было бы логично перенести эту работу на уровень выше.

Используя возможности Model Explorer, перенесите работу "Разработать конфигурацию" с диаграммы А2 "Производство продукта" на диаграмму АО.

Разрешите и перенаправьте стрелки согласно рис. 4.14.5 и 4.14.6.

Рис. 4.14.5. Результат выполнения третьей части упражнения 14 —

диаграмма АО

Рис. 4.14.6. Результат выполнения третьей части упражнения 14 —диаграмма A3

4.14.4. Модификация диаграммы IDEF3 "Сборка продукта" с целью отображения новой информации

Так же как в модели AS-IS, сборка продукта состоит из сборки компонентов и установки программного обеспечения. Однако теперь в работу "Сборка продукта" включена работа "Тестирование компьютера".

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

Модифицируйте диаграмму IDEF3 "Сборка продукта" в соответствии с приведенной информацией. Результат приведен на рис. 4.14.7.

Рис. 4.14.7. Результат выполнения четвертой части упражнения 14-

диаграмма A3 2.1

4.14.5. Декомпозиция работы "Продажи и маркетинг"

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

На основе этой информации декомпозируйте работу "Продажи и маркетинг" (IDEF0).

Создайте следующие работы:

Предоставление информации о ценах;

Оформление заказов;

Исследование рынка.

Результат декомпозиции представлен на рис. 4.14.8.

Рис. 4.14.8. Результат выполнения пятой части упражнения 14-

диаграмма А2

4.15. Упражнение 15. Создание диаграммы DFD

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

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

Декомпозируйте работу "Оформление заказов" на диаграмме А2.

В диалоге Activity Box Count выберите количество работ 2 и нотацию DFD (рис. 4.15.1).

Рис. 4.15.1. Выбор нотации DFD в диалоге Activity Box Count

3.Щелкните по OK и внесите в новую диаграмму DFD A22 имена работ:

Проверка и внесение клиента;

Внесение заказа.

4.Используя кнопкуI на палитре инструментов, внесите хранилища

данных:

Список клиентов;

Список продуктов;

Список заказов.

Удалите граничные стрелки с диаграммы DFD A22.

Используя кнопку на палитре инструментов, внесите внешнюю ссылку:

Звонки клиентов.

Создайте внутренние ссылки согласно рис. 4.15.2. При именовании стрелок используйте словарь.

Рис. 4.15.2. Диаграмма А22

8.Обратите внимание, что стрелки "Информация о клиентах" и "Заказы клиентов" двунаправленные. Для того чтобы сделать стрелку двунаправленной, щелкните правой кнопкой по стрелке, выберите в контекстном меню пункт Style и во вкладке Style выберите опцию Bidirectional.

9.На родительской диаграмме А2 туннелируйте (Change to Tunnel) стрелки, подходящие и исходящие из работы "Оформление заказов" (рис. 4.15.3).

Рис. 4.15.3. Работа "Оформление заказов" на диаграмме А2

4.16. Упражнение 16. Использование Off-Page Reference на диаграмме DFD

Некоторые стрелки с диаграмм IDEF0 и DFD (не только с родительских) могут показываться на диаграмме DFD. Для отображения таких стрелок используется инструмент Off-Page Reference.

1.Декомпозируйте работу "Исследование рынка" на диаграмме А2 на диаграмму DFD. Удалите граничные стрелки. Создайте следующие работы:

Разработка прогнозов продаж;

Разработка маркетинговых материалов;

Привлечение новых клиентов.

2.Используя кнопку- , на палитре инструментов, внесите хранилища данных:

Список клиентов;

Список продуктов;

Список заказов.

3.Добавьте две внешние ссылки:

Маркетинговые материалы;

Прогноз продаж.

4.Свяжите объекты диаграммы DFD стрелками, как показано на рис. 4.16.1.

Рис. 4.16.1. Диаграмма А23

На родительской диаграмме А2 туннелируйте (Change to Tunnel) стрелки, подходящие и исходящие из работы "Исследованиерынка".

В случае внесения новых клиентов в работе "Проверка и внесение клиента" на диаграмме А22 "Оформление заказов" информация должна направляться к работе "Привлечение новых клиентов" диаграммы А23 "Исследование рынка". Для этого необходимо использовать инструмент Off-Page Reference. На диаграмме А22 "Оформление заказов" создайте новую граничную стрелку, исходящую от работы "Проверка и внесение клиента", и назовите ее "Информацией о новом клиенте" (рис. 4.16.2).

Рис. 4.16.2. Граничная стрелка "Информация о новом клиенте" на диаграмме А22

7. Правой кнопкой щелкните по наконечнику стрелки и выберите в меню Off-Page Reference. В появившемся диалоге Off-Page Arrow Reference (рис. 4.16.3) выберите в качестве диаграммы A23D "Исследованиерынка".

Рис. 4.16.3. Диалог Off-Page Arrow Reference

Перейдите в меню Model/Model Properties, далее - во вкладку Display. Установите опцию Off-Page Reference label - Node number.

Перейдите на диаграмму A23D "Исследование рынка" и направьте стрелку "Информация о новом клиенте" на вход работы "Привлечение новых клиентов". Результат представлен на рис. 4.16.4.

Рис. 4.16.4. Межстраничная ссылка на диаграмме А23

Оглавление

Предисловие

Введение

Глава 1. Инструментальные средства BPwin4.0

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

    1.1.1. Общее описание интерфейса BPwin 4.0

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

    1.1.3. Установка цвета и шрифта объектов

    1.1.4. Model Explorer - навигатор модели

  1.2. Создание модели в стандарте IDEF0

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

    1.2.2. Работы (Activity)

    1.2.3. Стрелки (Arrow)

    1.2.4. Нумерация работ и диаграмм

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

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

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

    1.2.8. Рекомендации по рисованию диаграмм

    1.2.9. Проведение экспертизы

  1.3. Стоимостный анализ (ABC) и свойства, определяемые пользователем (UDP)

  1.4. Дополнение созданной модели процессов организационными диаграммами, диаграммами DFD и Workflow (IDEF3)

    1.4.1. Диаграммы потоков данных (Data Flow Diagramming)

    1.4.2. Метод описания процессов IDEF3

    1.4.3. Организационные диаграммы и диаграммы Swim Lane

    1.4.4. Использование нетрадиционного синтаксиса на диаграммах функциональной модели

    1.4.5. Создание смешанной модели

    1.4.6. Имитационное моделирование

  1.5. Использование обучающего модуля BPwin

Глава 2. Создание отчетов

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

    2.1.1. Встроенные шаблоны отчетов

    2.1.2. Создание отчетов с помощью Report Template Builder

  2.2. Создание отчетов в RPTwin

    2.2.1. Создание нового отчета

    2.2.2. Инструментальная среда RPTwin

    2.2.3. Вставка и форматирование объектов отчета

    2.2.4. Группировка и сортировка данных отчета

    2.2.5. Изменение файла данных отчета

    2.2.6. Изменение свойств отчета

    2.2.7. Создание формул RPTwin

    2.2.8. Функции RPTwin

    2.2.9. Использование формул RPTwin

  2.3. Использование Crystal Reports для создания отчетов

    2.3.1. Подготовка данных для отчета

    2.3.2. Инструментальная среда Crystal Reports Designer

    2.3.3. Создание простых отчетов в среде Crystal Reports Designer

    2.3.4. Внесение в отчет Crystal Reports новых полей

    2.3.5. Группировка записей отчета Crystal Reports

    2.3.5. Группировка записей отчета Crystal Reports

Глава 3. Связывание модели процессов и модели данных

  3.1. Модель данных и ее соответствие модели процессов

  3.2. Экспорт данных из ERwin в BPwin и связывание объектов модели данных со стрелками и работами

  3.3. Создание сущностей и атрибутов BPwin и их экспорт в ERwin

Глава 4. Практикум. Создание функциональной модели с помощью BPwin 4.0

  4.1. Упражнение 1. Создание контекстной диаграммы

  4.2. Упражнение 2. Создание диаграммы декомпозиции

  4.3. Упражнение 3. Создание диаграммы декомпозиции А2

  4.4. Упражнение 4. Создание диаграммы узлов

  4.5. Упражнение 5. Создание FEO диаграммы

  4.6. Упражнение 6. Расщепление и слияние моделей

    4.6.1. Расщепление модели

    4.6.2. Слияние модели

  4.7. Упражнение 7. Создание диаграммы IDEF3

  4.8. Упражнение 8. Создание сценария

  4.9. Упражнение 9. Стоимостный анализ (Activity Based Costing)

  4.10. Упражнение 10. Использование категорий UDP

  4.11. Упражнение 11. Расщепление модели

  4.12. Упражнение 12. Слияние расщепленной модели с исходной моделью

  4.13. Упражнение 13. Копирование работ

    4.13.1. Копирование работ в другую модель

    4.13.2. Перемещение работ в той же самой модели

  4.14. Упражнение 14. Создание модели ТО-ВЕ (реинжиниринг бизнес-процессов)

    4.14.1. Расщепление и модификация модели

    4.14.2. Слияние модели

    4.14.3. Использование Model Explorer для реорганизации дерева декомпозиции

    4.14.4. Модификация диаграммы IDEF3 "Сборка продукта" с целью отображения новой информации

  4.15. Упражнение 15. Создание диаграммы DFD

  4.16. Упражнение 16. Использование Off-Page Reference на диаграмме DFD

Реклама на сайте