Презентация на тему: МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ

МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ
Вопросы:
Эволюция подходов к моделированию и управлению бизнес-процессами
Эволюция подходов к моделированию и управлению бизнес-процессами
МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ
Методологии построения исполняемых моделей разрабатываются и выпускаются организациями по стандартизации и международными консорциумами:
Пояснение:
Современный этап
Понятие моделирования бизнес-процессов
Понятие моделирования бизнес-процессов
Понятие моделирования бизнес-процессов
Понятие моделирования бизнес-процессов
Понятие моделирования бизнес-процессов
Понятие моделирования бизнес-процессов
Понятие моделирования бизнес-процессов
Понятие моделирования бизнес-процессов
Методология функционального моделирования IDEF0
Методология функционального моделирования IDEF0
Методология функционального моделирования IDEF0
Методология функционального моделирования IDEF0
Методология функционального моделирования IDEF0
Методология функционального моделирования IDEF0
Методология функционального моделирования IDEF0
Методология функционального моделирования IDEF0
Принцип декомпозиции
Ограничение сложности
Принцип контекста
Методология функционального моделирования IDEF0
Методология функционального моделирования IDEF0
Методология функционального моделирования IDEF0
МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ
Методология функционального моделирования IDEF0
Методология функционального моделирования IDEF0
Методология функционального моделирования IDEF0
Методология функционального моделирования IDEF0
Методология функционального моделирования IDEF0
Диаграмма потоков данных DFD
Диаграмма потоков данных DFD
Диаграмма потоков данных DFD
Диаграмма потоков данных DFD
МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ
МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ
МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ
Диаграмма потоков данных DFD
Диаграмма потоков данных DFD
Диаграмма потоков данных DFD
Диаграмма потоков данных DFD
Диаграмма потоков данных DFD
Диаграмма потоков данных DFD
Диаграмма потоков данных DFD
Диаграмма потоков данных DFD
Диаграмма потоков данных DFD
Диаграмма потоков данных DFD
Диаграмма потоков данных DFD
Диаграмма потоков данных DFD
Диаграмма потоков данных DFD
Диаграмма потоков данных DFD
Диаграмма потоков данных DFD
Нотации Процесс и Процедура
Нотация Процесс
Нотация Процесс
Нотация Процесс
Нотация Процесс
Нотация Процедура
Нотация Процедура
Нотация Процедура
Нотация Процедура
Нотация CFC
Нотация EPC
Нотация EPC
Нотация EPC
Нотация EPC
Нотация EPC
Нотация EPC
Нотация EPC
Нотация EPC
Нотация EPC
Нотация EPC
Нотация EPC
Нотация EPC
Нотация EPC
Нотация EPC
Нотация EPC
Нотация EPC
Нотация EPC
Нотация EPC
Нотация EPC
Степень детализации процесса в нотациях
1/88
Средняя оценка: 4.0/5 (всего оценок: 37)
Код скопирован в буфер обмена
Скачать (7101 Кб)
1

Первый слайд презентации: МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ

Изображение слайда
2

Слайд 2: Вопросы:

Эволюция подходов к моделированию и управлению бизнес-процессами. Понятие моделирования бизнес-процессов. Методология функционального моделирования IDEF0. Диаграмма потока данных DFD. Нотации Процесс и Процедура. Нотация EPC.

Изображение слайда
3

Слайд 3: Эволюция подходов к моделированию и управлению бизнес-процессами

Первая волна: Фредерика Тейлора « Принципы научного управления». Используются блок-схемы, ориентированные графы, сети Петри, методологии SADT, IDEF, DFD. Попытки автоматизации бизнес-процессов. Вторая волна: M. Хаммера и Д.  Чампи «Реинжиниринг корпорации: манифест революции в бизнесе». Появление систем управления потоками работ WfMS ( Workflow Management Systems ) 2-го поколения. Третья волна: Г. Смит и П. Фингар «Управление бизнес-процессами: третья волна». Появление систем управления бизнес-процессами BPMS. Стремление к стандартизации.

Изображение слайда
4

Слайд 4: Эволюция подходов к моделированию и управлению бизнес-процессами

Моделирование бизнес-процессов Совершенствование деятельности Использование ИТ Первая волна 1920–80-е гг. Анализ способов выполнения работ. Рационализация трудовых операций. Модели на бумаге. Низкая автоматизация 1980-е гг. Всеобщее управление качеством. Непрерывность изменений. Научный подход. Последовательное совершенствование 1970–90-е гг. Система управления базами данных. Совместное использование данных. Приложения, обращающиеся к базам данных Вторая волна 1990-е гг. ПО для построения диаграмм и анализа процессов в статике. Ручной реинжиниринг. Единовременное создание модели. Автоматизация: КИС с поддержкой потоков работ (WfMS, ERP) 1990-е гг. Реинжиниринг бизнес-процессов. Дискретность изменений. Ненаучный подход. Радикальное преобразование 1990-е гг. Распределенные вычисления. Совместное использование функций. Распределенные приложения Третья волна 2000-е гг. Ориентированное на бизнес-процессы ПО. Исполняемые модели. Итеративная оптимизация. Средства моделирования интегрированы в BPMS. Имитационное моделирование и анализ моделей в динамике. Конвертирование моделей. Стандартизация методологий 2000-е гг. Управление бизнес-процессами (BPM). Непрерывность изменений. Гибкость, адаптивность. Научный подход. Итеративное совершенствование 2000-е гг. Системы управления бизнес-процессами. Совместное исполнение бизнес-процессов. Распределенные бизнес-процессы

Изображение слайда
5

Слайд 5

Изображение слайда
6

Слайд 6: Методологии построения исполняемых моделей разрабатываются и выпускаются организациями по стандартизации и международными консорциумами:

OASIS ( Organization for the Advancement of Structured Information Standards ): в спецификации ebXML и BPEL, стандарты для электронного бизнеса на базе XML и веб-сервисов ; OMG ( Object Management Group ): стандарты BPMN и UML, MDA и CORBA; W3C ( World Wide Web Consortium ): стандарты WS-CDL, WSCI, спецификации XML, технологии веб-сервисов; WfMC ( Workflow Management Coalition ): стандарты Wf -XML и XPDL. Изначально методологии BPML и BPMN были созданы консорциумом BPMI.org ( Business Process Management Initiative ), дальнейшее развитие BPML было прекращено в пользу BPEL, в 2005 г. произошло слияние BPMI.org с OMG, и в настоящее время работы над BPMN ведутся в рамках OMG.

Изображение слайда
7

Слайд 7: Пояснение:

Язык BPML дополняет язык реализации бизнес-процессов ( Business Process Execution Language, сокр. BPEL). BPML может использоваться для определения детальных бизнес-процессов, исполняемых при вызове каждого web -сервиса. BPML преобразует (« мэппирует ») бизнес-операции в обменные сообщения. Этот язык может использоваться для определения корпоративных бизнес-процессов, комплексных web -сервисов и многостороннего сотрудничества. В разработке BPML-спецификаций участвует целый ряд организаций: CSC, Intalio, SAP, Sun, SeeBeyond, Versata и др. UML  ( Unified Modeling Language  — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения, моделирования бизнес-процессов, системного проектирования и отображения организационных структур. Концепция MDA ( Model Driven Architecture ) призвана обеспечить общую основу для описания и использования большинства существующих стандартов, не ограничивая разработчиков в выборе конкретных технологий. CORBA ( Common Object Request Broker Architecture  — общая архитектура брокера объектных запросов; типовая архитектура опосредованных запросов к объектам) — технологический стандарт написания распределённых приложений, продвигаемый консорциумом (рабочей группой) OMG и соответствующая ему информационная технология. Web Services Choreography Description Language (WS-CDL). Спецификация предназначена для создания сценариев взаимодействия Web -сервисов в рамках общего бизнес-протокола.

Изображение слайда
8

Слайд 8: Современный этап

Технологии автоматизации межкорпоративного взаимодействия : бизнес-бизнес ( Business-to-Business, B2B ); ebXML ( Electronic Business using extensible Markup Language, ISO 15000 ). Наращивание функционала систем Workflow. Переход от задач описания процессов к задачам совершенствования по параметрам стоимости, качества и времени выполнения. Использование системы сбалансированных показателей (BSC — Balanced ScoreCard ) для обеспечения контроля результативности через наборы ключевых показателей результативности (KPI — Key Performance Indicators ).

Изображение слайда
9

Слайд 9: Понятие моделирования бизнес-процессов

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

Изображение слайда
10

Слайд 10: Понятие моделирования бизнес-процессов

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

Изображение слайда
11

Слайд 11: Понятие моделирования бизнес-процессов

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

Изображение слайда
12

Слайд 12: Понятие моделирования бизнес-процессов

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

Изображение слайда
13

Слайд 13: Понятие моделирования бизнес-процессов

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

Изображение слайда
14

Слайд 14: Понятие моделирования бизнес-процессов

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

Изображение слайда
15

Слайд 15: Понятие моделирования бизнес-процессов

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

Изображение слайда
16

Слайд 16: Понятие моделирования бизнес-процессов

Изображение слайда
17

Слайд 17: Методология функционального моделирования IDEF0

Функциональный подход основан на трех принципах: Разбиение исследуемого процесса на функциональные блоки – подпроцессы, исходя из набора принципов, среди которых принцип «определенности» (выход каждого блока должен быть ясно понимаем независимо от сложности процесса), «единственности» и т. д. 2) Возможность детализации любых процессов путем иерархической декомпозиции. 3) Использование для описания процесса графических нотаций с возможностью текстового разъясняющего дополнения.

Изображение слайда
18

Слайд 18: Методология функционального моделирования IDEF0

1960-х гг. Дуглас Росс (Массачусетский технологический институт, компания SoftTech ): методология структурного анализа и проектирования SADT ( Structured Analysis and Design Technique ). конец 1970-х гг. Министерство обороны США, программа интегрированной компьютерной поддержки производства ICAM ( Integrated Computer-Aided Manufacturing ): принята значительная часть SADT. в 1970-х гг. появился целый набор таких методов под общим названием IDEF (первоначально ICAМ DEFinition, затем Integrated DEFinition ). 1981 г. Технология SADT, переименованная в IDEF0, получила статус федерального стандарта США (последняя редакция выпущена Национальным Институтом По Стандартам и Технологиям США NIST – National Institute of Standards and Technology в 1993 г.,).

Изображение слайда
19

Слайд 19: Методология функционального моделирования IDEF0

IDEF0 – методология функционального моделирования, снабженная наглядным графическим языком и позволяющая представить моделируемую систему в виде набора взаимосвязанных функций. Как правило, является первым этапом изучения системы ; IDEF1 – методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи ; IDEF1X (IDEF1 e Xtended ) – методология построения реляционных структур. О тносится к типу методологий «сущность-взаимосвязь» ( Entity-Relationship – ER) и, как правило, применяется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе ;

Изображение слайда
20

Слайд 20: Методология функционального моделирования IDEF0

IDEF3 – методология описания процессов, происходящих в системе. Описывает сценарий и последовательность операций для каждого процесса. Близка к алгоритмическим методам построения схем процессов и стандартным средствам построения блок-схем (построение блок-схемы в программе MS Word ); IDEF4 – методология объектно-ориентированного проектирования. Р еализует объектно-ориентированный анализ больших систем, предоставляя пользователю графический язык для изображения классов, диаграмм наследования, таксономии методов ; IDEF5 – методология онтологического исследования сложных систем. Систему можно описать с помощью определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени. На базе этих утверждений формируются выводы о дальнейшем развитии системы и производится ее оптимизация.

Изображение слайда
21

Слайд 21: Методология функционального моделирования IDEF0

Элемент – функциональный блок.

Изображение слайда
22

Слайд 22: Методология функционального моделирования IDEF0

Элемент – стрелка (интерфейсная дуга). Стрелки могут быть: Входящие Input – вводные, которые ставят определенную задачу (вход). Исходящие Output – выводящие результат деятельности (выход) Управляющие (сверху вниз) Control – механизмы управления (положения, инструкции и д р.). Механизмы (снизу вверх) Mechanism – используется для того, чтобы произвести необходимую работу (обеспечение, ресурсы). Каждая сторона четырехугольника определяет тип стрелки. Каждая стрелка на дочерней диаграмме должна соответствовать стрелкам на родительской диаграмме.

Изображение слайда
23

Слайд 23: Методология функционального моделирования IDEF0

Граничные стрелки помечаются с помощью ICOM -меток: Input, Control, Output, Mechanism.

Изображение слайда
24

Слайд 24: Методология функционального моделирования IDEF0

Принципы моделирования: − функциональной декомпозиции; − ограничения сложности; − контекста.

Изображение слайда
25

Слайд 25: Принцип декомпозиции

Родительская диаграмма Дочерняя диаграмма

Изображение слайда
26

Слайд 26: Ограничение сложности

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

Изображение слайда
27

Слайд 27: Принцип контекста

Моделирование бизнес-процесса начинается с построения контекстной диаграммы. На диаграмме отображается только один блок – главная бизнес-функция моделируемой системы. Планировать учебную нагрузку преподавателя А0 Нормативные документы Сотрудники кафедры Спланированная учебная нагрузка преподавателя Данные о преподавателе и учебных дисциплинах

Изображение слайда
28

Слайд 28: Методология функционального моделирования IDEF0

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

Изображение слайда
29

Слайд 29: Методология функционального моделирования IDEF0

Ветвление и слияние стрелок

Изображение слайда
30

Слайд 30: Методология функционального моделирования IDEF0

Туннелирование

Изображение слайда
31

Слайд 31

Рамка (каркас) диаграммы

Изображение слайда
32

Слайд 32: Методология функционального моделирования IDEF0

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

Изображение слайда
33

Слайд 33: Методология функционального моделирования IDEF0

Построение модели: Шаг 1. Построение модели «как есть». Шаг 2. Определение бизнес-правил. Шаг 3. Построение модели «как должно быть». Шаг 4. Распределение ресурсов.

Изображение слайда
34

Слайд 34: Методология функционального моделирования IDEF0

Определение бизнес-правил

Изображение слайда
35

Слайд 35: Методология функционального моделирования IDEF0

Н аправлена на анализ функциональных аспектов и позволяет ответить на вопрос: «Что делает система ?». П одходит для описания бизнес-процессов верхнего уровня и позволяет отразить управление процессами, обратные связи и информационные потоки. Существует целый ряд программных инструментов, поддерживающих функциональное моделирование в стандарте IDEF0: BPwin и ERwin, ERwin Process Modeler ( Computer Associates ), IDEF0.EM Tool (ИП Ориентсофт ), Design /IDEF ( MetaSoftware ).

Изображение слайда
36

Слайд 36: Методология функционального моделирования IDEF0

Изображение слайда
37

Слайд 37: Диаграмма потоков данных DFD

DFD ( Data Flow Diagram, 1979 г.) представляет иерархию функциональных процессов, связанных потоками данных. Цель — продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами. Как и в IDEF0, основу методологии DFD составляет графический язык описания процессов. Используется при построении функциональной модели TO-BE. Распространенные графические нотации DFD: Йордана – Де Марко (Эд Йордан ( Yourdon ) и Том де Марко ( DeMarko )); Гейна Сарсона ( Gane Sarson ).

Изображение слайда
38

Слайд 38: Диаграмма потоков данных DFD

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

Изображение слайда
39

Слайд 39: Диаграмма потоков данных DFD

DFD должна наглядно ответить на вопросы: из чего состоит информационная система? что нужно, чтобы обработать информацию?

Изображение слайда
40

Слайд 40: Диаграмма потоков данных DFD

Элементы: Процесс (англ. Process ), т.е. функция или последовательность действий, которые нужно предпринять, чтобы данные были обработаны. Внешние сущности (англ. External Entity ). Л юбые объекты, которые не входят в систему, но являются для нее источником информации либо получателями какой-либо информации из системы после обработки данных. Хранилище данных (англ. Data store ). Внутреннее хранилище данных для процессов в системе. Поток данных (англ. Data flow ). В нотации отображается в виде стрелок, которые показывают, какая информация входит, а какая исходит из того или иного блока на диаграмме.

Изображение слайда
41

Слайд 41

Графические эле м енты DFD

Изображение слайда
42

Слайд 42

Нотация Гейна Сарсона

Изображение слайда
43

Слайд 43

Изображение слайда
44

Слайд 44: Диаграмма потоков данных DFD

Требования к оформлению процесса: Каждая функция (процесс) должна иметь идентификатор; Название процесса нужно формулировать согласно формуле: Название процесса = Действие + Объект, над которым действие осуществляется Например, если эта работа связана с действием по продаже продукции, то ее нужно назвать <Продать продукцию>. Название работы должно быть по возможности кратким и состоять из 2-3 слов.

Изображение слайда
45

Слайд 45: Диаграмма потоков данных DFD

Требования к оформлению потока: Название потока нужно формулировать согласно формуле: Название потока = Объект, представляющий поток + Статус объекта Если речь идет о продукции, которую отгрузили клиенту, то поток можно назвать <Продукция, отгруженная> или <Продукция, отгруженная клиенту>. В данном случае <Продукция> это объект, представляющий поток, а <отгруженная клиенту> — статус объекта. Название должно быть по возможности кратким и состоять из 2-3 слов.

Изображение слайда
46

Слайд 46: Диаграмма потоков данных DFD

Требования нумерации: Внешние сущности ( External Entity ). Хранилище данных ( Data store ).

Изображение слайда
47

Слайд 47: Диаграмма потоков данных DFD

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

Изображение слайда
48

Слайд 48: Диаграмма потоков данных DFD

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

Изображение слайда
49

Слайд 49: Диаграмма потоков данных DFD

Изображение слайда
50

Слайд 50: Диаграмма потоков данных DFD

Шаг 1. Построение контекстной диаграммы. Уровень системы

Изображение слайда
51

Слайд 51: Диаграмма потоков данных DFD

Шаг 1. Построение контекстной диаграммы. В некоторых случаях стоит построить несколько контекстных диаграмм с иерархией: наличие большого количества внешних сущностей (десять и более); распределенная природа системы; многофункциональность системы с уже сложившейся или выявленной группировкой функций в отдельные подсистемы.

Изображение слайда
52

Слайд 52: Диаграмма потоков данных DFD

Шаг 2. Детализация подсистем на контекстной диаграмме. Правила : балансировки  — при детализации процесса дочерняя диаграмма в качестве внешних источников/приемников данных может иметь только те компоненты (подсистемы, процессы, внешние сущности, накопители данных), с которыми имеет информационную связь соответствующий процесс на родительской диаграмме; нумерации  — при детализации процессов должна поддерживаться их иерархическая нумерация. семи  — для того, чтобы диаграмма легко читалась, количество функций на диаграмме не должно быть больше семи. Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д.

Изображение слайда
53

Слайд 53: Диаграмма потоков данных DFD

Шаг 2. Детализация подсистем на контекстной диаграмме. Уровень подсистемы

Изображение слайда
54

Слайд 54: Диаграмма потоков данных DFD

Шаг 2. Детализация подсистем на контекстной диаграмме. Уровень процесса

Изображение слайда
55

Слайд 55: Диаграмма потоков данных DFD

Шаг 3. Миниспецификация. Документ, детально описывающий логику процесса. С одержит номер процесса, списки входных и выходных данных, тело процесса — подробный алгоритм функции, преобразующий входные потоки данных в выходные.

Изображение слайда
56

Слайд 56: Диаграмма потоков данных DFD

Шаг 3. Миниспецификация. Требования:

Изображение слайда
57

Слайд 57: Диаграмма потоков данных DFD

Шаг 4. Создание Словаря данных. Определенным образом организованный список всех элементов данных системы с их точными определениями, что дает возможность различным категориям пользователей (от системного аналитика до программиста) иметь общее понимание всех входных и выходных потоков и компонент хранилищ. Определения элементов данных в словаре осуществляются: описанием значений потоков и хранилищ, изображенных на DFD; описанием композиции агрегатов данных, движущихся вдоль потоков, т.е. комплексных данных, которые могут расчленяться на элементарные символы (например,  АДРЕС ПОКУПАТЕЛЯ  содержит  ПОЧТОВЫЙ ИНДЕКС, ГОРОД, УЛИЦУ  и т.д.); описанием композиции групповых данных в хранилище; специфицированием значений и областей действия элементарных фрагментов информации в потоках данных и хранилищах; описанием деталей отношений между хранилищами.

Изображение слайда
58

Слайд 58: Диаграмма потоков данных DFD

Шаг 4. Создание Словаря данных. Определяются структура и содержание всех потоков данных и хранилищ данных, которые присутствуют на диаграммах. Для каждого потока в словаре хранятся: имя потока, тип, атрибуты. Например, при моделировании документооборота вводятся сведения о структуре и реквизитном составе документов.

Изображение слайда
59

Слайд 59: Нотации Процесс и Процедура

Нотация Basic FlowChart ( BFC, Процесс, простая блок-схема) применяется для моделирования отдельных процессов компании, а также на нижнем уровне модели бизнес-процессов, например, совместно с IDEF0. Представляет алгоритм выполнения процесса и является нотацией класса workflow. Позволяют задать причинно-следственные связи и временную последовательность выполнения действий процесса. 1921 г. – американский инженер Франк Банкер Гилбрет представил первый структурированный метод для документирования потоков процесса ( flow process chart ) для членов Американского общества инженеров-механиков ( American Society ofMechanical   Engineers, ASME).

Изображение слайда
60

Слайд 60: Нотация Процесс

Графические элементы нотации BFC : Начало процесса / Конец процесса Ручной процесс Автоматизированный процесс. Бумажный документ. В каждом блоке этого типа, помимо названия, должен быть обязательно указан код печатного документа. В отдельной таблице, прилагаемой к диаграмме, по коду должны восстанавливаться шаблон и процедуры заполнения печатной формы. Ручной (с клавиатуры, сканера) ввод данных в автоматизированную систему. Блок этого типа должен обязательно иметь связь с блоком типа 7 с указанием соответствующей подсистемы и т.д. Автоматизированная система, электронное хранилище данных. В тексте блока такого типа обязательно должно быть указано название Модуля, Подсистемы, Системы и т.д. Решение (выбор). Текст в этом блоке должен предполагать ответы «Да» или «Нет». Отступление допускается, если при этом вопрос и варианты ответов становятся более понятными (например, возможен вопрос: «Как клиент оплачивает заказ?»-и варианты ответа: «Наличными», «Через банк»). Архив. Значок размещается в том подразделении, где ведется архив. Соединитель страниц. Если символ находится в конце страницы, он должен содержать номер следующей страницы. Если значок расположен в начале – указывается номер предыдущей страницы. Соединитель с другим процессом. Должен содержать код процесса (указывается в заголовке диаграммы перед именем процесса ).

Изображение слайда
61

Слайд 61: Нотация Процесс

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

Изображение слайда
62

Слайд 62: Нотация Процесс

Если две или более линий объединятся в одну, то место объединения должно быть смещено. Вместо одного символа с соответствующим текстом могут быть использованы несколько символов с перекрытием изображения. Выходящие из блоков документы не должны теряться. Рекомендуемое количество блоков на диаграмме ≤ 30. Требования к построению BFC :

Изображение слайда
63

Слайд 63: Нотация Процесс

Преимущества BFC Недостатки BFC Простота и наглядность описания Ограниченное число графических элементов Быстрое описание процесса Не требует специальных знаний

Изображение слайда
64

Слайд 64: Нотация Процедура

Нотация Cross Functional Flowchart ( CFC, Процедура, функциональная блок-схема, кросс-функциональная схема, перекрестно-функциональная диаграмма) отображает процесс на нижнем уровне бизнес-модели. Разработана в 1990-ых гг. на основе диаграмм, которые использовались для представления алгоритмов и описания логики компьютерных программ. Процедура отображает детальный алгоритм выполнения бизнес-процесса, участников бизнес-процесса и их взаимодействие в рамках Процедуры.

Изображение слайда
65

Слайд 65: Нотация Процедура

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

Изображение слайда
66

Слайд 66: Нотация Процедура

Графические элементы CFC :

Изображение слайда
67

Слайд 67: Нотация Процедура

Преимущества CFC Недостатки CFC Простота и наглядность описания Ограниченное число графических элементов Быстрое описание процесса Отсутствие визуальных значков для моделирования движения документов и статусов Не требует специальных знаний Невозможность экспорта моделей в BPMS для автоматизации Интеграция с IDEF0 по потокам объектов

Изображение слайда
68

Слайд 68: Нотация CFC

Изображение слайда
69

Слайд 69: Нотация EPC

Нотация Event-Driven Process Chain ( EPC, событийная цепочка процессов) используется для описания процессов на разных уровнях. Представляет упорядоченную комбинацию событий и функций. Для каждой функции могут быть определены начальные и конечные события, участники, исполнители, материальные и документальные потоки, сопровождающие её. Может быть проведена декомпозиция (например, в нотациях EPC или BPMN). Нач. 1990-ых гг. – EPC-метод разработан Августом-Вильгельмом Шеером ( August-Wilhelm Scheer ) в рамках работ над созданием методологии ARIS ( Architecture of Integrated Information Systems, Архитектура интегрированных информационных систем). Методология EPC существует в разных интерпретациях (ARIS, Microsoft Visio, Business Studio, Bflow ).

Изображение слайда
70

Слайд 70: Нотация EPC

Основные графические элементы EPC :

Изображение слайда
71

Слайд 71: Нотация EPC

Основные графические элементы EPC :

Изображение слайда
72

Слайд 72: Нотация EPC

Основные графические элементы EPC :

Изображение слайда
73

Слайд 73: Нотация EPC

Основные графические элементы EPC :

Изображение слайда
74

Слайд 74: Нотация EPC

Основные графические элементы EPC :

Изображение слайда
75

Слайд 75: Нотация EPC

Основные графические элементы EPC :

Изображение слайда
76

Слайд 76: Нотация EPC

Основные графические элементы EPC : https:// sites.google.com/site/anisimovkhv/learning/pris/lecture/tema8/tema8_3 http:// www.businessstudio.ru/wiki/docs/v4/doku.php/ru/csdesign/bpmodeling/epc_notation

Изображение слайда
77

Слайд 77: Нотация EPC

Типы связей между объектами на диаграмме процесса в нотации EPC (http://www.businessstudio.ru/wiki/docs/v4/doku.php/ru/csdesign/bpmodeling/epc_notation): процесса ; субъекта ; программного продукта; документа ; базы данных; информации ; товарно-материальных ценностей (ТМЦ); терминов ; операторов.

Изображение слайда
78

Слайд 78: Нотация EPC

Правила моделирования: 1. Диаграмма функции должна начинаться как минимум одним стартовым событием) и завершаться как минимум одним конечным событием. 2. События и функции по ходу выполнения процесса должны чередоваться. Решения о дальнейшем ходе выполнения процесса принимаются функциями. 3. Рекомендуемое количество функций на диаграмме – не более 20. Если количество функций диаграммы значительно превышает 20, то существует вероятность, что неправильно выделены процессы на верхнем уровне и необходимо произвести корректировку модели. 4. События и функции должны содержать строго по одной входящей и одной исходящей связи, отражающей ход выполнения процесса.

Изображение слайда
79

Слайд 79: Нотация EPC

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

Изображение слайда
80

Слайд 80: Нотация EPC

Правила моделирования: 6. На диаграмме не должны присутствовать объекты без единой связи. 7. Каждый оператор слияния должен обладать хотя бы двумя входящими связями и только одной исходящей, оператор ветвления - только одной входящей связью и хотя бы двумя исходящими. Операторы не могут обладать одновременно несколькими входящими и исходящими связями. 8. Если оператор обладает входящей связью от элемента "событие", то он должен обладать исходящей связью к элементу "функция" и наоборот. 9. За одиночным событием не должны следовать операторы OR или XOR. 10. Операторы могут объединять или разветвлять только функции или только события. Одновременное объединение/ветвление функции и события невозможно. 11. Оператор, разветвляющий ветки, и оператор, объединяющий эти ветки, должны совпадать. Допускается также ситуация, когда оператор ветвления AND, оператор объединения OR.

Изображение слайда
81

Слайд 81: Нотация EPC

Допустимые ситуации

Изображение слайда
82

Слайд 82: Нотация EPC

Недопустимая ситуация

Изображение слайда
83

Слайд 83: Нотация EPC

Алгоритм построения диаграммы: Шаг 1. Определить начальное и конечное события. Шаг 2. Добавить действия и соответствующие им промежуточные события. Шаг 3. Присоединить документы и (или) информацию, которая необходима для выполнения каждого этапа (входы) и документы, которые являются результатами работы на каждом этапе (выходы). Добавить связи с исполнителями и с обозначением ролей. Р аспространенная роль – «выполняет ». Другие : «утверждают результат», «отвечает за техническую часть», «должен быть уведомлен о нестандартном завершении» и т.п. Шаг 4. Оценить полноту и качество схемы. Проанализировать, все ли варианты исполнения процесса учтены в схеме.

Изображение слайда
84

Слайд 84: Нотация EPC

Алгоритм построения диаграммы: Пример первого шага

Изображение слайда
85

Слайд 85: Нотация EPC

Алгоритм построения диаграммы: Пример второго шага

Изображение слайда
86

Слайд 86: Нотация EPC

Алгоритм построения диаграммы: Пример третьего шага

Изображение слайда
87

Слайд 87: Нотация EPC

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

Изображение слайда
88

Последний слайд презентации: МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ: Степень детализации процесса в нотациях

Изображение слайда