Механизм интеграции

Моделирование бизнеса — IDEF, UML, ARIS

Классификация моделей

Понятие модели

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

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

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

Модель внешнего вида часов
модель внешнего вида часов
Структурная схема часов
структурная схема часов

Виды подобия: прямое (макет, фотография), косвенное (подобие по аналогии), условное (на основе соглашений).

Процесс моделирования имеет свойство динамичности: модели развиваются, уточняются, переходят одна в другую.

Классификация моделей

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

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

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

Классификация моделей материальные абстрактные
Материальные модели построены из реальных объектов.
Абстрактные модели — это идеальные конструкции, выполненные средствами мышления, сознания.

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

Классификация моделей детерминированные стохастические
Детерминированные модели отражают процессы и явления, не подверженные случайностям.
Стохастические – отражают случайные процессы, описываемые вероятностными характеристиками и статистическими закономерностями.

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

Языки описания моделей

Языки описания моделей: аналитические, численные, логические, теоретико-множественные, лингвистические, графические.

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

Требования к нотации:

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

Содержание модели бизнеса

В модели бизнеса отражают:

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

Методы моделирования бизнеса

Структурные методы

Структурные методы
Основаны на последовательной декомпозиции системы на все более мелкие подсистемы.

Принципы структурного подхода:

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

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

Наибольшее распространение получили методологии:

  • IDEF0 – функциональные модели, основанные на методе SADT;
  • IDEF1X – диаграммы данных «сущность-связь» (ERD);
  • IDEF3 — диаграммы потоков работ (Work Flow Diagrams);
  • DFD — диаграммы потоков данных (Data Flow Diagrams).

Методы объектно-ориентированного моделирования

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

Наиболее известные методы:

  • Booch’93 Г. Буча,
  • OMT Дж. Румбаха
  • OOSE А. Джекобсона
  • UML (Unified Modeling Language) – на основе Booch’93, OMT, OOSE

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

Методы имитационного моделирования

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

Наиболее распространенные методы:

  • сети Петри и раскрашенные сети Петри (CPN, Colored Petri Nets);
  • GPSS (General Purpose Simulating System) – унифицированный язык имитационного моделирования;
  • SIMAN (SIMulation ANalysis) – язык визуального моделирования.

Интегрированные методы

Интегрированные методы
Интегрированные методы моделирования объединяют различные виды моделей – структурного анализа, объектно-ориентированные, имитационные и др.

  • ARIS (Architecture of Integrated Information System) позволяет отражать в единой интегрированной модели: оргструктуры, функции, данные, процессы. Использует множество типов моделей.
  • G2 — методология создания динамических интеллектуальных систем позволяет моделировать процессы с использованием знаний эксперта.
  • BRM (Business Rules Management) – методология управления бизнес-правилами.

Структурные методологии

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

Методология IDEF0
Методология IDEF0 базируется на методе SADT (Structured Analysis and Design Technique) Росса, предназначенном для структурированного представления функций системы и анализа системных требований.
IDEF0-модель состоит из диаграмм и фрагментов текста. На диаграммах все функции системы и их взаимодействия представлены как блоки (функции) и дуги (отношения).

Основные элементы модели:

  • Функциональный блок (Activity) – преобразование (активность);
  • Выходы (Output) – результат преобразования;
  • Входы (Input) — объекты, которые преобразуются в Выходы;
  • Управление (Control) — информация, как происходит преобразование;
  • Механизм (Mechanism) – объекты, осуществляющие преобразование.

Функциональный блок может быть декомпозирован — представлен в виде совокупности других взаимосвязанных блоков, которые детально описывают исходный блок.
IDEF0-модель состоит из набора иерархически связанных диаграмм
Таким образом, IDEF0-модель состоит из набора иерархически связанных диаграмм
На диаграмме блоки соединяются дугами: выходные дуги одних блоков могут являться входами (управлением, механизмом) других.
Дуги с одним свободным концом имеют источник или получатель вне диаграммы. Для обозначения внешних дуг используются буквы:

  • I (Input),
  • C (Control),
  • O (Output) и
  • M (Mechanism).

Типы связей между блоками:
Выход-вход
Выход-вход
Выход-управление
Выход-управление
Выход-механизм
Выход-механизм
Обратная связь по управлению
Обратная связь по управлению
Обратная связь по входу
Обратная связь по входу

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

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

Выделяют четыре элемента IDEF3-модели:
Единицы работ (Unit of work) IDEF3 Единица работы — отображают действия, процессы, события, этапы выполнения работ. Единица работы может иметь только один вход и один выход

Ссылки (Referents):
необходимые элементы для выполнения процесса (сырье, материалы);
результат процесса (изделие);
активаторы процесса (клиент, поставщик).
Ссылки (Referents) idef3

Связи (Links), которые бывают двух типов:
передают действия от одной единицы работ к другой
Связи (Links) idef3
соединяют ссылку с единицей работ (активируют единицу работ)
Связи (Links) idef3

Перекрестки (Junctions) – элементы модели, за счет которых описывается логика и последовательность выполнения этапов процесса.
Бывают двух видов:
перекрестки слияния – Fan-in
перекрестки слияния – Fan-in idef3
перекрестки ветвления – Fan-out
перекрестки ветвления – Fan-out

Типы перекрестков

Асинхронное И (Asynchronous AND)
выходной процесс запустится, если завершились все входные процессы
26_asynchronous_and_zavershilis_vse_vhodnie
после завершения входного процесса запустятся все выходные процессы
Асинхронное И (Asynchronous AND)

Синхронное И (Synchronous AND)
выходной процесс запустится, если завершились одновременно все входные процессы
Синхронное И (Synchronous AND)
после завершения входного процесса запустятся все выходные процессы, причем запустятся одновременно
Синхронное И (Synchronous AND)

Асинхронное ИЛИ (Asynchronous OR)
выходной процесс запустится, если завершится один или несколько входных процессов
Асинхронное ИЛИ (Asynchronous OR)
после завершения входного процесса запустятся один или несколько выходных процессов
Асинхронное ИЛИ (Asynchronous OR)

Синхронное ИЛИ (Synchronous OR)
выходной процесс запустится, если завершились один или несколько входных процессов, причем завершились одновременно
Синхронное ИЛИ (Synchronous OR)
после завершения входного процесса запустится один или несколько выходных процессов, причем запустятся одновременно
Синхронное ИЛИ (Synchronous OR)

Исключающее ИЛИ (XOR, Exclusive OR)
выходной процесс запустится, если завершился только один входной процесс
34_XOR_Exclusive_OR_input
после завершения входного процесса запустится только один выходной процесс
Исключающее ИЛИ (XOR, Exclusive OR)

Пример IDEF3

Пример IDEF3

Правила создания перекрестков

  1. Каждому перекрестку слияния должен предшествовать перекресток ветвления.
  2. Перекресток слияния «И» не может следовать за перекрестком ветвления типа синхронного, асинхронного или исключающего «ИЛИ».
  3. Перекресток слияния типа исключающего «ИЛИ» не может следовать за перекрестком ветвления типа «И».
  4. Перекресток, имеющий одну стрелку на одной стороне, должен иметь более одной стрелки на другой.
  5. Перекресток не может быть одновременно перекрестком слияния и ветвления. В ситуации, когда необходимо одновременно осуществить слияние и разветвление потоков работ, вводится каскад перекрестков.

Правило относительно единиц работ

В блок может входить и из блока может выходить только одна связь последовательности. Для отображения множества входов и выходов используются перекрестки.
Разрешается множественная декомпозиция работ:
для одной и той же работы может быть создано несколько диаграмм декомпозиции (для описания разных вариантов реализации работы).

Номер работы А13.1.2 означает:
родительская работа имеет код А13,
номер декомпозиции – 1
номер работы на текущей диаграмме – 2.

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

Диаграммы потоков данных DFD позволяют эффективно и наглядно описать процессы документооборота и обработки информации.
Используются две нотации: Йордана и Гейна-Сарсона

Типы структурных элементов (в нотации Гейна-Сарсона):
1. Процессы (функции, операции, действия), которые обрабатывают и изменяют информацию. Процессы показывают, каким образом входные потоки данных преобразуются в выходные
Методология DFD Процессы
2. Потоки данных, которые обозначают взаимодействие процессов с внешним миром и между собой. Поток данных соединяет выход процесса (объекта) с входом другого процесса (объекта).
Поток данных соединяет выход процесса (объекта) с входом другого процесса (объекта)
3. Хранилища данных — представляют собой собственно данные, к которым осуществляется доступ. Эти данные могут быть созданы или изменены процессами.
Хранилища данных - представляют собой собственно данные, к которым осуществляется доступ.
4. Внешние сущности — определяют внешние элементы, которые участвуют в процессе обмена информацией с системой. Внешние сущности изображают входы в систему (источники информации) и/или выходы из системы (приемники информации). Примеры: заказчик, персонал, поставщик, клиент, склад, банк
Внешние сущности - определяют внешние элементы, которые участвуют в процессе обмена информацией с системой

Пример:
Методология DFD пример

Объектно-ориентированный язык UML

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

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

Прецедентная модель бизнеса

Отражает основные бизнес-процессы, их взаимодействие с окружением.
Начинается с построения внешней диаграммы (вариантов использования — Use Case Diagram), показывающей, как бизнес виден извне
Прецедентная модель бизнеса

Актор (действующее лицо, business actor) — субъект окружения бизнеса. Примеры акторов: Клиент, Покупатель, Поставщик, Партнер, Акционер, Заказчик.
Актор (действующее лицо, business actor)

Прецедент (вариант использования, business use case) — относительно законченная последовательность действий в рамках некоторого бизнес-процесса, приносящая ощутимый результат конкретному актору .
Примеры прецедентов: Производство продукта Продажа продукта, Сервисное обслуживание, Разработка продукта, Маркетинг и сбыт.
Прецедент (вариант использования, business use case)

Экземпляр (реализация) прецедента – конкретный вариант хода событий класс прецедентов — обобщенный прецедент.

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

Между прецедентами и акторами устанавливаются отношения коммуникации (отношения ассоциации со стереотипом communicate).
Они моделируют взаимосвязи прецедентов с окружением (информационные и материальные потоки)
Между прецедентами, как правило, устанавливаются только отношения зависимости а также отношения, структурирующие прецеденты – отношения обобщения, включения (зависимости со стереотипом include), расширения (зависимости со стереотипом extend).
отношения обобщения, включения (зависимости со стереотипом include), расширения (зависимости со стереотипом extend)

Для каждого из элементов модели составляется спецификация.
В спецификации актора: наименование, стереотип (business actor), описание, список атрибутов, список обязательств и др.

В спецификации прецедента: наименование, стереотип (business use case), краткое описание, перечень связанных с прецедентом поддиаграмм и документов

Поток событий прецедента

Поток событий — описание прецедентов последовательностью шагов

Поток событий прецедента «Продажа продукта»:

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

Диаграмма деятельности (Activity Diagram)

Диаграмма деятельности (Activity diagram)

Элементы диаграммы деятельности

Элементы диаграммы деятельности

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

Структурирование прецедентов

Чтобы упростить описание прецедента, необходимо его структурировать. Рассмотрим два способа структурирования.
1. Выделение фрагментов
Если из описания прецедента с альтернативными потоками событий можно выделить фрагмент, представляющий собой относительно законченную последовательность событий, то данный фрагмент рассматривается как отдельный прецедент. Между выделенным прецедентом и базовым устанавливается отношения включения (include).
Иногда используют отношение расширения (extend). Оно устанавливается между базовым прецедентом и прецедентом, содержащим некоторое дополнительное поведение, выполняемое при определенных условиях.

2. Обобщение
Если несколько прецедентов имеют похожее поведение, то следует выделить общее поведение в отдельный прецедент (родительский). Между каждым из частных прецедентов и родительским устанавливается отношение обобщения (generali-zation).

Объектная модель бизнес-процесса

Раскрывает внутреннее устройство бизнеса: какие виды ресурсов используются для реализации прецедентов и каким образом они взаимодействуют.
Классы объектов модели бизнеса:
активные — исполнители процессов (стереотип business worker), например, Продавец, Изготовитель, Разработчик;
53_uml_aktivnie_klassi
пассивные — сущности (стереотип business entity), например, Продукт, Заказ, Счет.
пассивные - сущности (стереотип business entity)

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

Классы и объекты

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

Объекты имеют:
имя (через двоеточие может быть указано имя класса)
свойства — описываются с помощью атрибутов
поведение — представляется с помощью операций

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

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

Динамическая диаграмма взаимодействия

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

Элементы диаграммы последовательности

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

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

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

Статическая диаграмма взаимодействия

Диаграмма кооперации (Collaboration Diagram)
Статическая диаграмма взаимодействия

Диаграмма классов

Диаграмма классов (Class diagram) используется для отображения устойчивых связей между классами объектов
Диаграмма классов для прецедента «Продажа продукта»
Диаграмма классов для прецедента «Продажа продукта»
Для структурирования классов используются отношения обобщения и включения
Для структурирования классов используются отношения обобщения и включения

Описание объектов

Спецификация объекта состоит из описания свойств (атрибутов) и поведения (обязательств, операций).
Спецификация объекта состоит из описания свойств (атрибутов) и поведения (обязательств, операций).

Интегрированная методология ARIS


Методология ARIS (Architecture of Integrated Information System) разработана в 1990-х годах профессором А.-В. Шеером
Интегрированная методология ARIS
Для каждого из этих представлений можно построить несколько типов моделей (в ARIS 5.0 общее количество типов диаграмм — 130)

Выделено четыре основных вида моделей (четыре представления):

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

Организационная схема

К организационным моделям относится Организационная схема (Organizational chat).
Основные типы объектов этой модели:
Организационная схема (Organizational chat)

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

Дерево функций

К функциональным моделям относится Дерево функций (Function Tree).
К функциональным моделям относится Дерево функций (Function Tree)
Используется только один тип объекта — функция (работа, действие, этап в рамках процесса).
На верхнем уровне функции представляют собой бизнес-процессы. Детализация функций образует иерархическую структуру.
Самый нижний уровень представляют базовые функции (которые уже не могут быть разделены на составные элементы).

Событийная цепочка процесса

К моделям процессов/управления относится Диаграмма eEPC (extended Event driven Process Chain)
К моделям процессов/управления относится Диаграмма eEPC (extended Event driven Process Chain)
Основные типы объектов:
67_aris_diagram_eEPC_tipi_objectov

Элементы диаграммы eEPC

  • Функция – некоторое (шаг процесса). С функцией могут быть связаны: исполнители, входные и выходные документы, программное обеспечение и т.д.
  • Событие — какое-либо завершенное состояние объекта, которое влияет на дальнейший ход процесса. С одной стороны события являются стимулом к выполнению функций, с другой – их результатом.
  • Логические операторы (И, ИЛИ, XOR) показывают разветвления в потоке процесса.

Примеры:
Элементы диаграммы eEPC

Интеграция моделей

Взаимосвязь моделей ARIS обеспечивается с помощью двух механизмов: интеграции и детализации
1. Механизм интеграции
Благодаря хранению объектов в едином репозитории (специальной базе данных).
При создании нового объекта в репозитарии появляется отдельная запись, задающая описание объекта.
Объект можно скопировать из одной модели и вставить в другую с помощью команд Copy/Paste.
Механизм интеграции

Детализация моделей

2. Механизм детализации: для объектов текущей модели можно задавать ссылки на другие модели, являющиеся подробным описанием этого объекта.
Типы детализации, разрешенные к использованию, зависят от типа объекта
70_aris_detalizaciya_modeley

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

Инструментальные средства

Возможности инструментальных средств

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

Использованная литература

1. Национальный исследовательский Томский политехнический университет. Томск. Силич В.А. 2016. 75 с. Презентация к лекции.


бизнес-процесс

Бизнес-процесс. Управление и моделирование в BPM (Business Process Management)

Введение в управление бизнес-процессами (Business Process Management, BPM)

Распространенные роли в управлении бизнес-процессами:

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

Управление бизнес процессами (Business Process Management, BPM) – это концепция управления, увязывающая стратегию и цели организации с ожиданиями и потребностями клиентов путем соответствующей организации сквозных процессов. BPM сводит воедино стратегию, цели, культуру и организационную структуру, роли, политики, нормативы, методологии и программные средства для: а) анализа, проектирования, внедрения, управления и непрерывного улучшения сквозных процессов и б) регулирования отношений в области процессного управления.

Видео по бизнес-процессам:

Рисунок «Три взгляда на BPM»

Три взгляда на BPM

Усовершенствование бизнес процессов (BPI) – это разовая инициатива или проект, направленный на более полное соответствие стратегии организации и ожиданий клиентов. BPI включает в себя выбор, анализ, проектирование и внедрение усовершенствованного процесса.

Управление процессами предприятия (EPM) – это применение принципов, методов и процессов BPM в конкретной организации. EPM: а) обеспечивает соответствие портфеля и архитектуры сквозных процессов стратегии и ресурсам организации и б) предоставляет модель регулирования для оценки и управления BPM инициативами.

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

Управление бизнес процессами

Что такое управление бизнес процессами (BPM)?

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

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

  1. Бизнес процессы, поддерживающие управление бизнес процессами. Например, у организации должны быть процессы, которые обеспечивают:
    • описание и проектирование бизнес процессов;
    • разработку и внедрение бизнес процессов;
    • мониторинг и контроль исполнения бизнес процессов;
    • непрерывное и постоянное улучшение бизнес процессов, несмотря на и в ответ на внутренние и внешние изменения.
  2. Определенные роли (люди), вовлеченные в управление бизнес процессами . Таковые включают (не ограничиваясь ими) следующие:
    • архитектор процессов, который отвечает за описание и проектирование бизнес процессов;
    • процессный аналитик, который отвечает за построение, внедрение, мониторинг и оптимизацию бизнес процессов;
    • владелец процесса, который отвечает за исполнение бизнес процесса от начала до конца, в соответствии с определенными целевыми показателями эффективности и в конечном итоге за создание ценности для потребителя.
  3. Внедрение специализированных информационных технологий управления бизнес процессами , обеспечивающих следующую функциональность:
    • описание бизнес процессов в контексте корпоративной архитектуры;
    • проектирование бизнес процессов с целью внедрения;
    • исполнение бизнес процессов в контексте операционной деятельности;
    • мониторинг целевых показателей эффективности бизнес процессов;
    • анализ бизнес процессов с целью выявления и оценки возможностей для улучшения;
    • управление изменениями бизнес процесса.

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

Рисунок «Бизнес-процесс»

бизнес-процессКонцепция потребителя во взаимодействии функций внутри организации

Концепция потребителя в бизнес-процессе BPMЦенность в виде проектных спецификаций

ценность в виде проектных спецификацийПример: IТ подразделение фармацевтической компании оказывает услуги бизнес подразделениям. Каждая такая услуга предоставляется посредством бизнес процесса внутри IТ подразделения. Связь поставщик – потребитель сервиса показана ниже. Бизнес-процесс создает ценность для потребителя в форме продукции или услуг. Суть BPM заключается в оптимизации того, как эта ценность создается.

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

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

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

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

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

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

schema_rascheta_kpi_bizness_processa

Категории бизнес-процессов

Бизнес-процессы можно разделить на три категории:

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

Модель зрелости BPM

Модель зрелости бизнес-процессов BPM:

Модель зрелости бизнес-процессов BPM

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

Цели моделирования процессов

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

Процессные модели – это средства:

  • управления процессами организации;
  • анализа эффективности процесса;
  • описания изменений.

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

Побудительные причины моделирования процессов:

Причины моделирования бизнес-процессов

Процессные нотации

Распространенные процессные нотации:

Процессные нотации

BPMN:
BPMN диаграмма

Диаграмма с дорожками Брюса Силвера:
Диаграмма с дорожками

Блок-схема:
Блок схема

Процессная цепочка, управляемая событиями (EPC):
Процессная цепочка, управляемая событиями (EPC)

UML:
uml

IDEF:
IDEF

Карта потока создания ценности:
Карты потока создания ценностиСпециализированные подходы к моделированию процессов

Специализированные подходы к моделированию процессов:
Специализированные подходы к моделированию процессов

Процессная иерархия

Процессная иерархия:
Процессная иерархия

Основные принципы моделирования бизнес-процессов

Что означает моделирование бизнес-процессов на практике? Моделирование бизнес-процессов в компании может быть направлено на решение большого числа различных задач:

  • Точно определить результат бизнес-процесса и оценить его значение для бизнеса.
  • Определить набор действий, составляющих бизнес-процесс. Ясное определение набора задач и действий, которые необходимо выполнить, чрезвычайно важно для детального понимания процесса.
  • Определить порядок выполнения действий. Действия в рамках одного бизнес-процесса могут выполняться как последовательно, так и параллельно. Очевидно, что параллельное исполнение, если оно допустимо, позволяет сократить общее время выполнения процесса и, следовательно, повысить его эффективность.
  • Произвести разделение зон ответственности: определить, а затем отслеживать, какой сотрудник или подразделение компании несет ответственность за выполнение того или иного действия или процесса в целом.
  • Определить ресурсы, потребляемые бизнес-процессом. Точно зная, кто какие ресурсы использует и для каких операций, можно повысить эффективность использования ресурсов посредством планирования и оптимизации.
  • Понять суть взаимодействий между участвующими в процессе сотрудниками и подразделениями компании и оценить, а затем повысить эффективность коммуникации между ними.
  • Увидеть движение документов в ходе процесса. Бизнес-процессы производят и потребляют различные документы (в бумажной или электронной форме). Важно разобраться, откуда и куда идут документы или информационные потоки, и определить, оптимально ли их движение и действительно ли все они необходимы.
  • Определить потенциальные узкие места и возможности для улучшения процесса, которые будут использованы позже для его оптимизации.
  • Более эффективно внедрить стандарты качества, например ИСО 9000, и успешно пройти сертификацию.
  • Использовать модели бизнес-процессов в качестве руководства для новых сотрудников.
  • Эффективно произвести автоматизацию бизнес-процессов в целом или отдельных их шагов, включая автоматизацию взаимодействия с внешней средой — клиентами, поставщиками, партнерами.
  • Разобравшись в совокупности бизнес-процессов компании, понять и описать деятельность предприятия в целом.

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

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

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

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

Шаги построения модели бизнес-процесса

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

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

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

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

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

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

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

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