Построение бизнес-модели в BPwin

 

       Содержание

 

Введение            4

     Case-средство BPwin        5

     Методология BPwin        12

         IDEF0          12

         IDEF3          16 DFD           21

    Построение  информационной модели – «Деятельность  оптовой компании»        26

Заключение           29

Список использованных источников      30

 
 
 
 
 
 
 
 
 

     Введение 

     Для проведения анализа и реорганизации  бизнес-процессов PLATINUM technology предлагает CASE-средство верхнего уровня BPwin, поддерживающее методологии IDEFO (функциональная модель), IDEF3 (WorkFlow Diagram) и DFD (DataFlow Diagram). Методология IDEFO предписывает построение иерархической системы диаграмм - единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром, после чего проводится функциональная декомпозиция - система разбивается на подсистемы и каждая подсистема описывается отдельно. Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности. После каждого сеанса декомпозиции проводится сеанс экспертизы: каждая диаграмма проверяется экспертами предметной области, представителями заказчика, людьми, непосредственно участвующими в бизнес-процессе. Такая технология создания модели позволяет построить модель, адекватную предметной области на всех уровнях абстрагирования. Если в процессе моделирования нужно осветить специфические стороны технологии предприятия, BPwin позволяет переключиться на любой ветви модели на нотацию IDEF3 или DFD и создать смешанную модель. Нотация DFD включает такие понятия, как внешняя ссылка и хранилище данных, что делает ее более удобной для моделирования документооборота. Методология IDEF3 включает элемент "перекресток", что позволяет описать логику взаимодействия компонентов системы.

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

     Case-средство BPwin

      AllFusion Process Modeler 7 или как он ранее  назывался BPwin – мощный программный  продукт с помощью которого, можно   проводить моделирование, анализ, описание и последующую оптимизацию бизнес-процессов.  С помощью BPwin можно создавать графические модели бизнес-процессов.   Графическое  изображение схемы выполнения работ, организации документооборота, обмена различными видами информации позволяет визуализировать существующую модель организации бизнеса.  Это  дает возможность использовать передовые инженерные технологии для решения задач  управления организацией.

      С помощью BPwin (AllFusion Process Modeler 7) можно организовать подробное документирование всех важных аспекты  бизнес-процессов т.е. необходимых действий, способов  их осуществления и контроля за ними, необходимыми для этого ресурсами и  впоследствии визуализировать полученную информацию. BPwin позволяет повысить эффективность ИТ-решений в бизнесе, проектировщики и аналитики бизнес-моделей получают возможность найти оптимальное соотношение между бизнес-требованиями, корпоративными инициативами, процессами информационной архитектуры и  проектированием приложений. С помощью BPwin можно увидеть полную картину организации деятельности предприятия: от количества работы в небольших подразделениях  предприятия до сложных функций организации предприятия.

      Использование BPwin (AllFusion Process Modeler 7) эффективно  использовать в проектах, в которых нужно сделать описание существующих баз предприятия, внедрить на предприятии  корпоративные информационные систем и для проведения реорганизации существующих бизнес-проектов.  С помощью BPwin можно провести оптимизацию деятельности предприятия и осуществить проверку на соответствие ее стандартам ISO 9000, создать проект организационной структуры, исключить ненужные операции, уменьшить размер издержек и увеличить эффективность. В основе программного продукта  BPwin (AllFusion Process Modeler 7) заложены общепринятые технологии моделирования, такие как idef0. Моделирование с помощью методологии idef0 рекомендовано к использованию Госстандартом Российской Федерации и  является общепринятым стандартом в США.  Наглядность и простота моделей  Process Modeler делает значительно более простым взаимодействие между различными участниками бизнес-процессов. Популярность BPwin (AllFusion Process Modeler 7) дает возможность  согласовывать функциональные модели в электронном виде. BPwin (AllFusion Process Modeler 7) - это продукт компании Computer Associates,  он вместе с ERwin Data Modeler (ERwin), Model Manager (ModelMart) и Data Model Validator (ERwin Examiner), входит в пакет программ AllFusion Modeling Suite. Использование этого программного комплекса позволяет эффективно обеспечить все аспекты моделирования информационных систем.

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

      С точки зрения функциональности системы. В рамках методологии IDEF0 (Integration Definition for Function Modeling) бизнес-процесс представляется в виде набора элементов-работ, которые взаимодействуют между собой, а также показывается информационные, людские и производственные ресурсы, потребляемые каждой работой.

      С точки зрения потоков информации (документооборота) в системе. Диаграммы DFD (Data Flow Diagramming) могут дополнить то, что уже отражено в модели IDEF3, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией между бизнес-функциями внутри системы. В тоже время диаграммы DFD оставляют без внимания взаимодействие между бизнес-функциями.

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

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

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

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

      

      Рисунок 1 - Основная панель инструментов BPwin

      1. Создать новую модель

      2. Открыть модель

      3. Сохранить модель

      4. Печать модели

      5. Мастер создания отчетов

      6. Выбор масштаба

      7. Масштабирование

      8. Увеличение участка

      9. Проверка ошибок

      10. Включение и выключение навигатора  модели

      На  основной панели инструментов (либо в  любом желаемом месте экрана) расположены инструменты редактора BPwin, представленные на рисунке 2:

      

      Рисунок 2 - Инструменты редактора BPwin

      1. Pointer Tool – используется для выбора  и определения позиции объектов добавленных в диаграмму.

      2. Activity Box Tool – используется для  установки блоков в диаграмме.

      3. Arrow Tool – используется, чтобы устанавливать дуги в диаграмме.

      4. Squiggle Tool – используется для создания  тильды (squiggle, ), которая

      соединяет дугу с ее названием.

      5. Text Block Tool – используется для создания  текстовых блоков.

      6. Diagram Dictionary Editor – открывает диалоговое окно Diagram Dictionary Editor, где можно перейти на какую-либо диаграмму или создать новую

диаграмму.

      7. Go to Sibling Diagram – используется для  отображения следующей диаграммы того же уровня.

      8. Go to Parent Diagram – переход на родительскую диаграмму.

      9. Go to Child Diagram – используется, чтобы  отобразить диаграмму потомка или разложить выделенный блок на диаграмму потомка.

      Любая диаграмма состоит из совокупности следующих объектов:

      • Блоков;

      • Дуг;

      • Текстовых блоков.

      Для работы с любым из этих объектов можно использовать либо основное меню, которое представлено в рисунке 3:

      

      Рисунок 3 - Основное меню BPwin

      Описание  полей бланка диаграммы.

      Каждая  диаграмма располагается внутри бланка имеющего несколько информационных полей:

      Поля  верхней части рамки

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

      Author (Автор) – имя создателя диаграммы.

      Date (Дата) – дата создания и имя проекта.

      Project (Проект) – имя проекта.

      Rev (Пересмотрено__________) – дата последнего редактирования диаграммы.

      Notes 12345678910 (Замечания) – используется при проведении сеанса экспертизы.

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

      Status (Статус) – статус отображает стадию создания диаграммы, отображая все этапы публикации:

      Working (Рабочая версия) – новая диаграмма, кардинально обновленная диаграмма или новый автор диаграммы;

      Draft (Эскиз) – диаграмма прошла первичную экспертизу и готова к дальнейшему обсуждению;

      Recommended (Рекомендовано) – диаграмма и все ее сопровождающие документы прошли экспертизу. Новых изменений не ожидается;

      Publication (Публикация) – диаграмма готова к окончательной печати и публикации.

      Reader (Читатель) – имя читателя (эксперта).

      Date (Дата) – дата прочтения (экспертизы).

      Context (Контекст) – схема расположения работ в диаграмме верхнего уровня. Работа, являющаяся родительской, показана темным прямоугольником, остальные – светлым. На контекстной диаграмме (А-0) показывается надпись ТОР. В левом нижнем углу показывается номер по узлу родительской диаграммы:

      Поля  нижней части рамки

      Node (Узел) – номер узла диаграммы (номер родительского блока).

      Title (Название) – имя диаграммы. По умолчанию – имя родительского блока.

      Number (Номер) – C-номер, уникальный номер версии диаграммы.

      Page (Страница) – номер страницы, может использоваться как номер страницы при формировании папки. 

    Методология BPwin

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

 

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

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

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

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

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

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

    В IDEF0 реализованы три базовых принципа моделирования процессов: 

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

         - принцип ограничения сложности; 

         - принцип контекста. 

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

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

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

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

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

 

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

     IDEF3 — методология моделирования  и стандарт документирования  процессов, происходящих в системе. Метод документирования технологических процессов предоставляет механизм документирования и сбора информации о процессах.

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

      Основные  элементы методологии IDEF 3 отображены в таблице 1.

      Таблица 1 - Основные элементы методологии IDEF 3

Диаграммы Основная единица  описания в IDEF3
Единица

работы

(UOW)

Центральный компонент  модели. Изображаются

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

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

 
 
 
 

     В IDEF3 различают три типа стрелок, изображающих связи, которые представлены в таблице 2.

     Таблица 2 - Типы стрелок, изображающие связи в IDEF3

Старшая

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

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

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

 

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

     IDEF3 состоит из двух методов:

       - Process Flow Description (PFD) - описание технологических  процессов, с указанием того, что  происходит на каждом этапе  технологического процесса.

       - Object State Transition Description (OSTD) - Описание  переходов состояний объектов, с указанием того, какие существуют промежуточные состояния у объектов в моделируемой системе.

      Диаграмма IDEF3 Process Flow Description может состоять из 5 основных описательных блоков:

       - работы (boxes, activities)

       - стрелки или связи (arrows, links)

       - перекрёстки (junctions)

       - объекты ссылок

      Существуют  два типа диаграмм в стандарте IDEF3, представляющие описание одного и того же сценария технологического процесса в разных ракурсах:

      -  диаграммы описания последовательности  этапов процесса (Process Flow Description Diagrams, PFDD);

      - диаграммы состояния объекта  в и его трансформаций процессе (Object State Transition Network, OSTN).

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

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

       

     Рисунок 4 - Типы перекрестков в IDEF3

     Описание  типов перекрестков отражено в таблице 3.

     Таблица 3 - Описание типов перекрестков в IDEF3

Наименование Смысл в случае слияния стрелок Смысл в случае разветвления стрелок
Asynchronous AND Все предшествующие

процессы  должны быть

завершены

Все следующие

процессы  должны быть

запущены

Synchronous AND Все предшествующие

процессы  завершены

одновременно

Все следующие

процессы  запускаются

одновременно

Asynchronous OR Один или несколько

предшествующих

процессов должны быть

завершены

Один или несколько

следующих процессов

должны  быть запущены

Synchronous OR Один или несколько

предшествующих

процессов завершены

одновременно

Один или несколько

следующих процессов

запускаются

одновременно

XOR (Exclusive OR) Только один

предшествующий

процесс завершен

Только один следующий

процесс запускается


 

Все перекрестки  в PFDD диаграмме нумеруются, каждый номер имеет префикс "J".

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

      - документировать имеющиеся данные  о технологии процесса, выявленные, скажем, в процессе опроса компетентных сотрудников, ответственных за организацию рассматриваемого процесса;

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

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

      - содействовать принятию или эксплутационных  свойств конечного продукта.

 

     DFD и DFD диаграммы

 

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

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

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

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

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

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

      

      Рисунок 5 - Панель инструментов методологии DFD

 

      DFD рассматривает систему как совокупность предметов. Контекстная диаграмма часто включает работы и внешние ссылки, представленные в таблице 4. Работы обычно именуются по названию системы, например «АРМ клиента».

     Таблица 4. Элементы контекстной диаграммы

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

данных

Изображают объекты  в покое, в отличие от стрелок, описывающих объекты в движении.
Построение бизнес-модели в BPwin