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

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

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

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

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

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

Моделирование работы службы поддержки клиентов

Описание метода и его стадии

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

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

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

Завершающие стадии моделирования

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

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

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

В зависимости от целей, моделирование может отличаться по видам. Построить основной подход к рабочим операциям компании можно исходя именно из вида моделирования, каждый из которых концентрируется на определенных характеристиках. Давайте подробнее рассмотрим наиболее популярные виды моделирования:

• Объективное. Как понятно из названия этого вида, модель в этом случае представляет собой ряд взаимодействующих объектов, которые преобразуются в ходе выполнения всех действий.
• Функциональное. Описание такого подхода строится на взаимосвязанных строго структурированных функциях.
• Имитационное. Этот вид моделирования нацелен на тестирование бизнес-процессов во внешней и внутренней среде с дальнейшей оценкой характеристик и оптимизацией ресурсов.

Формирование модели на примере:

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

Создание моделей бизнес-процессов — принципы

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

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

Подведем итоги

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

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

Источник: www.elma-bpm.ru

BPMN vs EPC и ТОП-5 советов по детальному моделированию бизнес-процессов

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

EPC и BPMN: вместо или вместе

При том, что все процессно-событийные нотации бизнес-моделирования, к которым относятся UML-диаграмма деятельности (UML activity), BPMN (Business Process Model and Notation) и EPC (Event-Process Chain), помогают наглядно описать логику выполнения процесса в виде направленного графа из действий и условных операторов, каждая из них решает эту задачу по-своему.

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

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

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

Методы описания бизнес-процессов (IDEF, DFD, BPMN, EPC, UML)

Код курса

MODP

Ближайшая дата курса

14 июня, 2023

Длительность обучения

8 ак.часов

Стоимость обучения

15 000 руб.

Как нарисовать понятную BPMN-диаграмму: ТОП-5 правил для начинающих бизнес-аналитиков

Если читателями ваших BPMN-диаграмм являются люди, а не BPMS-системы, главной миссией является не строгое соблюдение правил нотации, а понятность созданной схемы. Сделать это помогут следующие правила.

Используйте только XOR и AND

Большинство людей интуитивно понимают разницу между XOR и AND, а вот разобраться, чем отличается исключающее ИЛИ от неисключающего без дополнительных объяснений сможет уже не каждый. Тем более, эксперты предметной области или другие стейкхолдеры со стороны бизнеса не обязаны знать о тонкостях отличия XOR-шлюза, управляемого событиями, от такого же, но управляемого данными. Также не стоит использовать на BPMN-диаграммах сложный шлюз, который объединяет несколько логических операторов. Практически любой бизнес-процесс, в т.ч. со сложной логикой, множеством проверок и ветвлений можно описать с помощью операторов исключающего ИЛИ (XOR) и распараллеливания потоков управления И (AND). Все остальные шлюзы в BPMN-диаграмме, создаваемой для людей, а не BPMS-систем, – «горе от ума».

Ограничьте набор событий

Аналогичное утверждение о сокращении избыточности справедливо и для широкого набора событий, которые есть в этой нотации. Из 13 видов событий, имеющихся в BPMN 2.0, на практике чаще всего используются всего 5: простое, сообщение, таймер, ошибка, отмена, а также завершающий останов, который показывает немедленное прекращение выполнения процесса. Все остальные типы событий ориентированы на машинную обработку в BPMS-среде, а не на быстрое понимание людьми.

Меньше – значит лучше: сократите число блоков на диаграмме

В отличие от EPC, в BPMN нет строгого правила об обязательном чередовании действий и событий. Поэтому не стоит размещать блок «событие» после каждой задачи, если это не требуется для дальнейшего выполнения и понимания бизнес-процесса. Например, в BPMN-схеме на выходе задачи «Заполнить отчет» далеко не всегда требуется событие «Отчет заполнен». Если это событие запускает задачу проверки этого заполненного отчета – тогда да, его нужно показать на диаграмме. А если процесс просто идет без привязки к этому свершившемуся факту, не следует загромождать диаграмму.

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

Не скрывайте путь за дорожками: как показать исполнителей действий в BPMN

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

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

Источник: babok-school.ru

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

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

Базовые правила моделирования процессов в нотации BPMN

Начнем с базовых правил нотации BPMN:

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

Управление бизнес-процессами
Моделирование бизнес процессов. Нотация BPMN — базовые элементы

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

BPMN Уточнения

Несколько пояснений к классическим заблуждениям относительно BPMN:

• В нотации BPMN понятие Процесса, Модели, Диаграммы и Файла не является эквивалентным. Модель BPMN может содержать несколько процессов. Разные части Модели BPMN могут быть сохранены в разных файлах. Диаграмма BPMN может изображать целый набор Моделей бизнес процессов. Модель BPMN может быть изображена с использованием нескольких диаграмм
• Диаграмма BPMN не является диаграммой потоков данных. И хотя объекты данных являются одним из основных элементов нотации BPMN, не рекомендуется пытаться моделировать информационные потоки сами по себе с помощью BPMN.
• Шлюзы — это не принятие решения. Сами по себе шлюзы не принимают решения, они лишь отображают направление и условия развития процесса.
• Принятие решения должно отображаться виде операции, предшествующей шлюзу.
• Используйте Ручную операцию для того, чтобы отобразить полностью ручное выполнение операции, без использования какого-либо программного обеспечения.
• Используйте Пользовательскую операцию, чтобы отобразить полуавтоматические выполнения работы. В такой задаче пользователь выполняет операцию с помощью ПО.
• Автоматическая задача выполняется без участия пользователя.

Рекомендации по наименованию объектов в нотации BPMN

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

• Используйте ключевые слова, которые отражают суть и имеют отношение к вашему бизнесу. Не используйте непонятные, нераспространенные аббревиатуры. Не используйте наименование самого элемента в нем. Проверяйте грамматику.
• Все операции, события и объекты данных должны иметь наименование.
• Называйте процессы и операции так, будто это приказ. «Подготовить отчет» вместо «Подготовка отчета». Используйте полное наименование, избегайте сокращений.
• Не используйте одинаковые названия для операций (кроме Операций вызова).
• Шлюзы не выполняют какую-либо работу и не принимают решения. Это просто визуализация объединения или ветвления потоков. Нет необходимости называть объединяющие шлюзы. Можно давать текстовые аннотации к объединяющим шлюзам, когда они логически не очевидны.
• Шлюзы ветвления лучше называть вопросительными фразами
• Лучше всего называть исходящие из шлюзов потоки операций в согласованности с теми операциями или событиями, в которые они входят. Например, поток «Время подготовки отчета», операция «Подготовить отчет»
• Условные потоки операций нужно обязательно называть в соответствии и с условиями их возникновения.
• Давать названия потоку работ по умолчанию не нужно.
• События, имеющие пару, например, события Сообщения, Связи, Сигнала, Эскалации и Ошибки необходимо называть одинаково. Т.е. если в одном процессе у вас есть событие «Сигнал пожарной охраны», то в другом процессе, который запускается по данному событию, оно должно называться также.
• Называйте события Состояния так, чтобы было понятно, какое состояние оно отображает.
• Состояние одного и того же объекта данных необходимо указывать в квадратных скобках в самом названии объекта. Например, Договор [подписанный]
• Название пула должно соответствовать названию роли участника процесса, т.к. в BPMN пул и есть роль участника. Не называйте пулы названием процесса.
• Для названия дорожек используйте наименование категории. Зачастую дорожки используют для наименования ролей одного участника.

Правила моделирования процессов — лучшие практики

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

Управление бизнес-процессами
Нотация BPMN. Практическое моделирование

Нотация BPMN давно является стандартом моделирования бизнес-спроцессов. Мы подготовили для вас более 100 иллюстраций, с описанием наиболее распространенных вопросов, связанных с практическим использованием нотации BPMN и моделированием бизнес-процессов

Источник: deep-vision.one