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

1.

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

2.

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

3.

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

4.

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

5.

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

6.

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

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 включают:
- ограничение количества блоков на каждом уровне
декомпозиции (3-6 блоков);
- связность диаграмм (номера блоков);
- уникальность меток и наименований (отсутствие
повторяющихся имен);
- синтаксические правила для графики (блоков и дуг);
- разделение входов и управлений (правило определения
роли данных).
- отделение организации от функции, т.е. исключение
влияния организационной структуры на функциональную
модель.

10.

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

11.

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

12. Модель SADT Функциональный блок

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

13.

Модель SADT
Более общее представление
Более детальное представление
1
2
3
4
Одной из наиболее важных особенностей методологии SADT
является постепенное введение все больших уровней детализации по
мере создания диаграмм, отображающих модель

14.

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

15.

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

16.

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

17.

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

18.

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

19.

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

20.

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

21.

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

22.

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

23.

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

24.

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

25.

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

26.

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

27.

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

28.

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

29.

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

30.

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

31.

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

32.

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

33.

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

34.

35.

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

36.

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

37.

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

38.

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