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

 

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

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

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

С помощью BPwin можно сделать свою работу более эффективной.

BPwin позволяет:

Гарантировать эффективность операций и рассматривать текущие операции используя мощные инструменты моделирования.

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

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

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

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

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

Аргументы и факты:

- поддерживает три стандартные нотации - IDEF0, DFD и IDEF3. Эти основные ракурса позволяют комплексно описывать предметную область;

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

- поддерживает основные методы расчета себестоимости по объему хозяйственной деятельности;

- легко осваивается;

- распространен и не дорог, много информации, а также компетентных специалистов;

- интегрирован с Paradigm Plus (для моделирования компонентов программного обеспечения), ERwin (для моделирования баз данных);

- содержит генератор отчетов;

- BPwin содержит большой набор средств для документирования проектов и моделей.

- позволяет эффективно манипулировать моделями;

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

Анализ бизнеса с различных сторон.

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

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

В основе методологии IDEF0 лежат четыре основных понятия:

- функциональный блок,

- дуга (стрелка),

- декомпозиция,

- глоссарий.

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

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

- верхняя сторона – «Управление» (Control);

- левая сторона – «Вход» (Input);

- правая сторона – «Выход» (Output);

- нижняя сторона – «Механизм» (Mechanism).

 

 

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

В методологии IDEF0 различают пять типов стрелок.

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

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

Выход (Output) – информация или материальный объект, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться.

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

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

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

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

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

1. Контекстная диаграмма

2. Диаграммы декомпозиции

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

4. Диаграммы только для экспозиции

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

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

- потоки данных;

- процессы (работы) преобразования входных потоков данных в выходные;

- накопители данных (хранилища);

- внешние сущности.

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

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

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

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

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

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

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

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

Задачи выполняемые средствами документирования и моделирования IDEF3:

1. Документировать данные о технологии процесса.

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

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

4. Содействовать принятию оптимальных решений при реорганизации технологических процессов.

5. Разрабатывать имитационные модели технологических процессов, по принципу «как будет, если…».

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

 

 

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

Таблица 1 - Типы связей IDEF3

Изображение	Название	Назначение
	Временное предшествование (Temporal precedence)	Исходное действие должно завершиться, прежде чем конечное действие сможет начаться
	Объектный поток (Object flow)	Выход исходного действия является входом конечного действия (исходное действие должно завершиться, прежде чем конечное действие сможет начаться)
	Нечеткое отношение (Relationship)	Вид взаимодействия между исходным и конечным действиями задается аналитиком отдельно для каждого случая использования такого отношения

 

 

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

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

На рисунке 1.10 представлено два варианта декомпозиции родительского модуля[5].

 

ERwin

 

Логические модели данных создаются на стадии проектирования с использованием методологии IDEF1X. В ERWin существует Case-средство, которое поддерживает методологию IDEF1X и стандарт IE (Information Engineering). Методология IDEF1X подразделяется на уровни, соответствующие разрабатываемой модели данных системы. Каждый такой уровень относится к определенной фазе проекта. Этот подход полезен при создании систем по принципу «сверху вниз».

На стадии проектирования создаются логические модели трех уровней: Диаграмма сущность-связь (Entity Relation Diagram), Модель данных, основанная на ключах (Key-Based model) и Полная атрибутивная модель.

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

Модель данных Key-Based model (модель основанная на ключах), описывает структуру данных системы. В эту систему включены все сущности и атрибуты, в том числе ключевые.

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

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

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

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

ERwin поддерживает основные типы связей: полная категория, неполная категория, многие-ко-многим, идентифицирующая/неидентифицирующая.

В ERwin связи представлены следующими основными элементами информации:

- имя связи;

- тип связи;

- мощность связи;

- требования по обеспечению ссылочной целостности.

- допустимость пустых (null) значений;

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

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

Идентифицирующая связь рисуется сплошной линией; неидентифицирующая – пунктирной. Со стороны дочерней сущности линии заканчиваются точкой.

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

Мощность связи (Cardinality) предназначена для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней.

Различают 4 типа мощности:

- общий случай не помечается каким-либо знаком (одному экземпляру родительской сущности соответствуют 0, 1 или много экземпляров дочерней сущности);

- знаком Р помечается случай, когда одному экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней сущности (исключено нулевое значение);

- знаком Z помечается случай, когда одному экземпляру родительской сущности соответствуют 0 или 1 экземпляр дочерней сущности (исключены множественные значения);

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

Фраза, характеризующая отношение между дочерней и родительской сущностями - Имя связи (Verb Phrase). Для связи идентифицирующей или неидентифицирующей «один ко многим» достаточно указать имя, показывающее отношение «Parent-to-Child» (от родительской к дочерней сущности). Для связи «многие ко многим» надлежит указывать имя как Child-to-Parent, так и Parent-to-Child.

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

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

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

Иерархия наследования связи и типы сущностей определяют, является ли сущность зависимой или независимой. Различают несколько типов зависимых сущностей: ассоциативная и характеристическая зависимая дочерняя. Ассоциативная сущность содержит информацию о связях сущностей, позволяет реализовать связь «многие-ко-многим» и связана с несколькими родительскими сущностями. Сущность, хранящая информацию о характеристиках родительской сущности и связанная только с одной родительской является характеристической зависимой дочерней сущностью. Например, связь Менеджер – Телефон.

Дочерняя сущность в иерархии наследования– это категориальная сущность.

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

Иерархия наследования (иерархия категорий) - особый тип объединения сущностей, разделяющие общие характеристики.

Как правило, иерархию наследования создают, когда несколько сущностей имеют общие по смыслу связи (например, если бы Совместитель и Постоянный сотрудник имели близкую по смыслу связь «работает в» с сущностью Предприятие), либо когда сущности имеют общие по смыслу атрибуты, либо когда это диктуется бизнес-правилами.

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

Иерархии категорий делятся на типы: полные и неполные.

В неполном типе категория еще не выстроена полностью, в родовом предке могут существовать экземпляры, которые не имеют соответствующих экземпляров в потомках.

Если одному экземпляру родового предка (сущность Сотрудник, смотри рисунок 1.11) обязательно соответствует экземпляр в каком-либо потомке (в примере служащий обязательно является либо Администратором, либо Агентом), то это полная категория.

Для создания связи следует:

- установить курсор в палитре инструментов на кнопке «Категория» и нажать левую кнопку мыши;

- щелкнуть вначале по родовому предку, а затем по потомку;

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

 

 

Для редактирования категорий необходимо щелкнуть по символу категории правой кнопкой мыши и выбрать в контекстном меню пункт Subtype Relationship Editor. В диалоге Subtype Relationship можно указать тип категории – полная/неполная (радио-кнопки Complete/Incomplete) и атрибут-дискриминатор категории (список Discriminator Attribute Choice).

 

Выводы по разделу 1

 

В первой главе рассмотрен жизненный цикл ITIL и в частности Служба Service Desk. Анализируя процесс Службы Service Desk, были определены направления для автоматизации процесса.

Рассмотрев теоретические основы проектирования информационных систем, сделаны следующие выводы:

MS Access как нельзя лучше подходит для реализации поставленных задач.