Операционные процессы

Содержание

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

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

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

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

Модель внешнего вида часов

Структурная схема часов

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

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

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


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

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


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


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


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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример IDEF3

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

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

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

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

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

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

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

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

Пример:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Диаграмма кооперации (Collaboration Diagram)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примеры:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Каждый бизнес-процесс имеет:

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

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

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

Наличие проработанной системы бизнес-процессов значительно упрощает приведение деятельности компании на соответствие требованиям стандартам качества ISO 9001:2015. В условиях свершившегося вступления России в ВТО, соответствие предприятия стандартам ISO 9001:2015 становится важным конкурентным преимуществом.

Внедрение СМК на предприятии в обязательном порядке требует создания и описания бизнес-процессов.

Разработка бизнес-процессов

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

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

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

В описании бизнес-процесса можно выделить следующие разделы:

  • Стандартные формы бизнес-процесса
  • Карта бизнес-процесса
  • Маршруты бизнес-процесса
  • Матрицы бизнес-процесса
  • Блок-схемы бизнес-процесса
  • Описание стыков бизнес-процесса
  • Вспомогательные описания бизнес-процесса
  • Развернутое описание бизнес-процесса
  • Документирование бизнес-процесса
  • Определение показателей и индикаторов бизнес-процесса
  • Регламент выполнения бизнес-процесса

Рассмотрим подробнее каждый этап.

1.Стандартные формы описания бизнес-процесса

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

2.Карта бизнес-процесса

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

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

  • Каким документом завершается рабочий цикл, чтобы его можно было начать сначала?
  • Кому передается этот документ?
  • Что этому предшествует?
  • Кто вовлечен в этот процесс внутри и вне организации?
  • Кто выдает задание для запуска процесса?

Рекомендация

При составлении карты бизнес-процесса следует воспользоваться популярной вопросной формулой 5W1H. Коротко, это 5 вопросов W:

и один вопрос H

  • How? (Как совершается эта операция? Можно ли сделать это иначе или внести улучшения?).

Если карта получается слишком сложной — это сигнал о том, что в управлении организацией нет должного порядка.

Маршруты бизнес-процесса

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

Матрицы бизнес-процесса

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

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

Составление блок-схемы бизнес-процесса

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

  • Сопоставима ли ценность от данного бизнес-процесса с затратами на его проведение?
  • Насколько он интегрирован с другими бизнес-процессами?
  • Могут ли быть сразу обнаружены ошибки этого бизнес-процесса?
  • Что сделано для улучшения и обеспечения качества этого бизнес-процесса?

Описание стыков бизнес-процессов

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

Рекомендация

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

Затем составьте аналогичное описание входов.

Вспомогательные описания бизнес-процессов

В качестве вспомогательно описания используются компоновочные схемы, мнемосхемы, диаграммы Ганта и сетевые графики. Две последние удобно использовать для процессов управления проектами.

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

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

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

Документирование бизнес-процесса

Бизнес-процессы, входящие в систему СМК, подлежат документированию. Наиболее удобной формой описания является процедура. Бизнес-процесс может быть описан одной или несколькими процедурами, в зависимости от сложности. Удобно сделать единый вид для описания всех бизнес-процессов.

Определение показателей и индикаторов бизнес-процесса

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

  • качество;
  • время выполнения;
  • количество;
  • издержки.

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

Группа индикаторов бизнес-процесса показывает степень достижения цели.

Группа требований включает в себя:

  • человеческие ресурсы;
  • инфраструктура;
  • условия производственной среды.

Группа обеспечения желаемого протекания процесса:

  • информация;
  • инструкции по выполнению работ;
  • время.

Группа рекомендаций:

  • финансы;
  • логистика;
  • поставщики;
  • партнеры и т.д.

11. Регламент выполнения бизнес-процесса

Крупные бизнес-процессы целесообразно оформлять в виде отдельного документа «Регламента выполнения бизнес-процесса». Остальные бизнес-процессы могут быть оформлены в виде положений о подразделении и должностных инструкций.

В регламент следует заложить требования, обеспечивающие соответствие циклу Шухарта-Деминга:

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

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

Методические пособия

Чтобы лучше понять, как используются реальные процессы на реальном предприятии, вы можете приобрести разработанные нами методические пособия:

«Управление рисками в управлении проектами. Выполнение требований ISO 9001:2015»

«Управление рисками в управлении запасами. Выполнение требований ISO 9001:2015» + образец описания бизнес-процесса

Операционные процессы

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *