Лекция_4 Моделирование бизнес процессов

1.

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

2.

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

3.

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

4.

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

5.

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

6.

Методы моделирования бизнес-процессов:
- SADT/IDEF0 - метод функционального
моделирования;
- IDEF3 - метод моделирования процессов;
- DFD - моделирование потоков данных;
- BPMN - нотация моделирования потоков
работ;
- метод ARIS;
- метод моделирования, используемый в
технологии Rational Rosse.

7.

Виды моделей (диаграмм):
- SADT (Structured Analysis and Design Technique)
модели и соответствующие функциональные диаграммы
- DFD (Data Flow Diagrams) диаграммы потоков
данных
- ERD (Entity-Relationship Diagrams) диаграммы
«сущность-связь»
На стадии проектирования системы модели
расширяются, уточняются и дополняются диаграммами,
отражающими ее структуру.
Перечисленные модели в совокупности дают полное
описание системы независимо от того, является ли она
существующей или вновь разрабатываемой. Состав
диаграмм в каждом конкретном случае зависит от
необходимой полноты описания системы.

8.

Методология SADT (Structured Analysis and
Design Technique) – методология (технология)
структурного анализа и проектирования, лежит в
основе стандарта IDEF.
Технологии моделирования:
- IDEF0
–
метод
функционального
моделирования;
- IDEF3 – метод описания бизнес-процессов;
- DFD - метод построения диаграмм потоков
данных.
Все описанные подходы входят в семейство
стандартов IDEF (Integrated DEFinition; дословно:
Integrated – составлять целое, интегрировать,
Definition – определение, ясность, точность;
«целостная ясность»).

9.

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

10.

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

11.

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

12.

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

13.

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

14.

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

15.

В методологии SADT (IDEFO) требуется только пять
типов взаимодействий между блоками для описания их
отношений: вход, управление, обратная связь по входу,
обратная связь по управлению, выход-механизм.
Связь по входу
Обратная связь по
входу
Связь по управлению
Обратная связь по
управлению
Связь выходмеханизм

16.

Диаграмма А0 создания базы данных

17.

18.

IDEF3 – метод описания бизнеc-процессов
IDEF3 – метод описания бизнеc-процессов с
использованием
структурированного
метода,
позволяющего
эксперту
в
предметной
области
представить положение вещей как упорядоченную
последовательность
событий
с
одновременным
описанием объектов, имеющих непосредственное
отношение к процессу.
Основой модели IDEF3 служит так называемый
сценарий
бизнес-процесса,
который
выделяет
последовательность действий. Наименованием действия
служат глаголы или отглагольные существительные:
«обработать
заказ
клиента»,
«технологическая
подготовка».

19.

Средства документирования и моделирования IDEF3
позволяют выполнять следующие задачи:
- Документировать имеющиеся данные о технологии
процесса, выявленные в процессе опроса компетентных
сотрудников,
ответственных
за
организацию
рассматриваемого процесса.
- Определять и анализировать точки влияния потоков
сопутствующего
документооборота
на
сценарий
технологических процессов.
- Определять ситуации, в которых требуется принятие
решения, влияющего на жизненный цикл процесса,
например изменение конструктивных, технологических или
эксплуатационных свойств конечного продукта.
- Содействовать принятию оптимальных решений
при реорганизации технологических процессов.
Разрабатывать
имитационные
модели
технологических процессов, по принципу "КАК БУДЕТ,
ЕСЛИ..."

20.

Модель, выполненная в IDEF3, содержит следующие
элементы:
Единицы работы - Unit of Work (UOW) - основной
компонент диаграммы IDEF3 близкий по смыслу к функции
IDEF0.UOW, также называемые работами (activity),
являются центральными компонентами модели. В IDEF3
работы изображаются прямоугольниками с прямыми углами
и имеют имя, выраженное отглагольным существительным,
обозначающими процесс действия, одиночным или в
составе фразы, и номер (идентификатор); другое имя
существительное в составе той же фразы обычно
отображает основной выход (результат) работы (например,
«Изготовление изделия»).
Связи (Links) - Связи, изображаемые стрелками,
показывают взаимоотношения работ. Все связи в IDEF3
однонаправлены и могут быть направлены куда угодно, но
обычно диаграммы IDEF3 стараются построить так, чтобы
связи были направлены слева направо. В IDEF3 различают
три типа связей.

21.

Модель, выполненная в IDEF3, содержит
следующие элементы:
Перекрестки
(Junctions)
перекрестки
используются в диаграммах IDEF3, чтобы показать
ветвления
логической
схемы
моделируемого
процесса и альтернативные пути развития процесса
могущие возникнуть во время его выполнения.
Различают два типа перекрестков:
Перекресток слияния (Fan-in Junction) – узел,
собирающий множество стрелок в одну, указывая на
необходимость
условия
завершенности
работисточников стрелок для продолжения процесса.
Перекресток ветвления (Fan-out Junction) – узел,
в котором единственная входящая в него стрелка
ветвится, показывая, что работы, следующие за
перекрестком,
выполняются
параллельно
или
альтернативно.

22.

Классификация типов перекрестков

23.

Пример IDEF3 диаграммы

24.

Перекрестки синхронное «И»
Перекрестки асинхронное «И»

25.

Перекрестки асинхронное «ИЛИ»

26.

Перекрестки синхронное «ИЛИ»

27.

Перекрестки исключающее «ИЛИ»

28.

DFD – (Data Flow Diagrams ) метод построения
потоков данных
DFD могут содержать:
- объекты, собирающие и хранящие информацию,
- хранилища данных
- внешние сущности – объекты моделирующие
взаимодействие с теми частями системы, которые выходят
за границы моделирования.
Построение
DFD
–
диаграмм
в
основном
ассоциируется с разработкой программного обеспечения.
Основные компоненты диаграмм:
- внешние сущности
- системы/подсистемы
- процессы
- накопители данных
- потоки данных

29.

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

30.

Модель DFD
Накопитель данных
Представляет собой абстрактное устройство для
хранения информации, которую можно в любой момент
поместить в накопитель и через некоторое время извлечь
D1
Получаемые счета
Накопитель данных идентифицируется буквой "D" и
произвольным числом

31.

Виды модели:
1. AS–IS – это модель «как есть» для выявления
узких мест, анализа недостатков;
2. TO–BE – это модель «как будет» для
исправления,
а
также
перенаправления
информационных и материальных ресурсов.
Цель моделирования определяется из ответов на
следующие вопросы:
Почему
этот
процесс
должен
быть
смоделирован?
- Что должна показывать модель?
- Что может получить клиент?

32.

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

33.

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

34.

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

35.

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