Что нужно знать для запуска проекта по бизнес-моделированию процессов
Моделирование бизнес-процессов организации имеет разные цели в организации.
Estimated reading time: 13 минут
Первая цель – это анализ и оптимизация процессов, когда мы исследуемую деятельность разбиваем буквально на атомы, чтобы разобраться, как эта деятельность устроена. Диаграммы или схемы процессов, создаваемые в рамках аналитического моделирования, называют аналитическими диаграммами. Их особенность состоит в том, что вся ключевая информация максимально выносится прямо на схему — поэтому аналитикам не требуется обращаться к дополнительным документам во время проектирования. Целевой аудиторией таких диаграмм являются бизнес-аналитики.
В результате таких проектов нередко появляются диаграммы впечатляющих масштабов — схемы «во всю стену», включающие более сотни элементов, каждый из которых отражает отдельную операцию, действие или решение. Когда деятельность разложена на элементарные составляющие — условно говоря, «атомы» процессов, — и между ними выстроены связи, у аналитиков появляется возможность выявить узкие места и предложить пути улучшения.
Итогом такого анализа становятся предложения по оптимизации деятельности: автоматизация отдельных шагов, изменение порядка выполнения работ или перераспределение функций между участниками процесса.
Почему аналитики создают столь детальные и громоздкие схемы? Всё просто: их основная аудитория — они сами. Для внешнего обсуждения, например с бизнес-экспертами или пользователями, аналитики используют только отдельные фрагменты схем, которые называют «островками». Каждый такой островок охватывает небольшой участок процесса — 4–5 шагов, связанные документы и программное обеспечение, поддерживающее выполнение этих операций.
Именно эти островки становятся предметом рабочих обсуждений. Совместно с экспертами аналитики уточняют детали, задают уточняющие вопросы, фиксируют ответы — а затем интегрируют новую информацию обратно в большую диаграмму, где продолжается поиск и обоснование решений по оптимизации.
HighAdvance Consulting Group оказывает услуги по грейдированию должностей (офлайн и онлайн), обучению оценке должностей, а также разработке систем оплаты труда. За дополнительной информацией обращайтесь к ведущему эксперту Максиму Логинову +7 921 334 67 62 | mrloginov2209@gmail.com×
Вторая цель моделирования — это регламентация деятельности, когда мы создаем процессы (схемы), через которые объясняем сотрудникам корпоративные правила работы. В результате в компании формируется база знаний корпоративных правил. Эти схемы должны быть максимально простыми и понятными.
Схемы, которые получаются в рамках таких проектов, называются регламентными. Здесь обычно ограничивается количество шагов, которые выносятся на диаграмму. Возникает требование, чтобы диаграмма помещалась на листочке формата А4, и при необходимости каждый кубик (кубики – это шаги процесса) описывается на отдельной диаграмме. Сотрудники хорошо ориентируются в таких диаграммах. Минимальное количество символов используется на этих диаграммах как раз для того, чтобы сотрудники не тратили много времени на постоянное обучение, как правильно читать ту или иную схему.
Если брать тот же самый BPMN, то в ее спецификации более 100 символов можно использовать на диаграмме. Их довольно сложно запомнить обычному пользователю. Такое обилие значков не требуется. Поэтому на регламентных схемах желательно количество значков сократить. Обычно используется от 9 до 12 символов.
Третья цель моделирования — это автоматизация. Процессы описываются для того, чтобы затем «зашить» их в виде дорожных карт, например в Bitrix. Bitrix затем будет по этим дорожным картам сам «нарезать» нашим сотрудникам задачи, будет проверять, насколько своевременно эти задачи выполняются, длительность каждой операции и т.д.
Это три цели моделирования. В реальной жизни, с консультантами или без, предприятия все эти три цели стараются реализовать.
Моделирование бизнес-процессов организации. Как правильно выбрать нотации для моделирования бизнес-процессов
Исходя из целей моделирования, консультанты ранее рекомендовали определенные нотации под определенные цели моделирования.
Анализ и автоматизация
Если это анализ и оптимизация, чаще всего использовался EPC, событийная цепочка процесса. Это нотация Headliner, программного немецкого продукта ARIS. Она активно использовалась для того, чтобы как раз на диаграмме можно было отобразить материальные, информационные потоки, все операции и всех участников. Диаграммы мощные, цветные. Для анализа – это отличный вариант.
Доктор August‑Wilhelm Scheer, разработчик этой нотации, предложил каждую функцию на диаграмме описывать по методу интеллектуальных карт. Вы можете, какая бы огромная диаграмма ни была, любую функцию взять, на нее посмотреть, и Вы по этой функции будете знать все. Потому что информация об этой функции или действиях сотрудника там описана в формате интеллектуальной карты: вход-выход, поддерживающий ресурс, регламентирующий ресурс, исполнитель, сама функция, требования к срокам, если это релевантно для конкретной задачи. Очень удобный инструмент.
Моделирование и автоматизация
Если говорить про цель моделирования и автоматизации, то свод знаний по управлению бизнес-процессами BPM CBOK (Business Process Management Common Body of Knowledge) 4.0, русифицированный, актуальный на сегодняшний момент времени уверяет нас, и не безосновательно, что уже де-факто стандартом описания процессов для автоматизации выступает нотация BPMN. Потому что огромное количество систем, которые исполняют бизнес-процессы, внутри себя уже имеют графический движок, хорошо понимающий диаграммы BPMN. Поэтому если вдруг вы принимаете решение описывать процессы для автоматизации, описывайте процессы в BPMN.
Регламентация процессов
Для регламентации консультанты рекомендовали использовать Cross-functional flowchart (кросс‑функциональная блок‑схема, «диаграмма дорожек»). Это простые блок-схемы: ромбик, да-нет, направо-налево, плавательные дорожки, 3-4 символа всего на диаграмме, стрелка, прямоугольничек и ромбик. Вот и все символы. Они действительно очень простые, понятные.
В этой стройной картине все прекрасно, за исключением одного, что тем людям, которые разрабатывают схемы, если мы пойдем по этому маршруту, нужно знать и EPC, и BPMN, и Cross-functional flowchart и как-то внутри их подружить между собой. Не самое рациональное расходование рабочего и бизнес-аналитического времени.
В последние годы консультанты активно продвигают идею использования единой нотации BPMN (Business Process Model and Notation) для решения сразу трёх ключевых задач — анализа, регламентации и автоматизации бизнес‑процессов.
Благодаря BPMN становится возможным создавать исполняемые диаграммы, которые можно напрямую передавать в программные системы для выполнения процессов. Именно здесь востребовано богатство визуальных элементов BPMN — десятки символов, каждый из которых несёт чёткое функциональное значение. Такое разнообразие не случайно: фактически BPMN представляет собой графический язык программирования, позволяющий описать логику работы системы в визуальной форме, понятной и машинам, и людям.
Когда же задача заключается не в настройке программного обеспечения, а в инструктаже сотрудников — объяснении, как должны выполняться операции на рабочих местах — здесь вполне достаточно ограниченного подмножества нотации. Практика показывает, что 7–9 базовых символов BPMN 2.0 позволяют создать наглядные и легко читаемые схемы, которые эффективно заменяют длинные текстовые регламенты.
Далее, когда процесс передаётся IT‑специалистам для автоматизации, они используют эти упрощённые схемы как основу. К ним добавляются дополнительные элементы BPMN, несущие техническую информацию, необходимую для настройки систем. Таким образом, используя одну нотацию, организация получает единый язык описания бизнес‑процессов, подходящий и для регламентации, и для автоматизации.
Более того, BPMN хорошо подходит и для аналитического моделирования, поскольку поддерживает детализированное описание действий, ролей и взаимодействий. Однако у этой нотации есть ограничение — она изначально была разработана IT‑специалистами и не предназначалась для отображения материальных потоков.
Мы решаем этот вопрос с помощью цветовой кодировки. На диаграммах применяем стандартные символы BPMN 2.0, но используем разные цвета для обозначения типов объектов: например, коричневые элементы отражают товарно‑материальные ценности, а незакрашенные — информационные. Такой приём сохраняет единую визуальную логику нотации и одновременно делает схему более информативной для бизнес‑анализа.
Моделирование бизнес-процессов организации. Документирование правил моделирования бизнес-процессов
После выбора нотации следующим шагом становится документация правил моделирования. Обычно они оформляются в документе под названием «Соглашение о моделировании». В нём фиксируются принципы построения диаграмм: какие символы используются и для каких целей, как оформляются схемы, какие требования предъявляются к их содержанию и структуре. Нередко в этом же документе задаются общие правила для всей регламентирующей документации компании.
В «Соглашении о моделировании» также описывается иерархия процессной модели. На верхнем уровне располагаются процессные категории — крупные блоки деятельности компании, например, поддерживающие процессы. Каждая процессная категория делится на процессные группы — например, в составе категории «Поддерживающие процессы» может быть выделена группа Управление персоналом.
Далее процессные группы разбиваются на бизнес‑процессы. В нашем примере в группу «Управление персоналом» входят процессы подбора, развития и перемещения сотрудников. Каждый из этих бизнес‑процессов, в свою очередь, детализируется до операционных процессов, где описывается последовательность действий сотрудников на рабочих местах — например, как оформить заявку на подбор персонала, как закрыть вакансию и т. д.
После декомпозиции процессной модели по уровням для каждого уровня назначается свой тип нормативного документа. Так, для процессных групп обычно разрабатывается стандарт предприятия или положение о соответствующей области деятельности. Например, для группы «Управление персоналом» это может быть «Положение об управлении персоналом» или стандарт предприятия с аналогичным названием.
Для бизнес‑процессов создаются регламенты бизнес‑процессов, а для операционных процессов — документированные процедуры. Таким образом, формируется структура нормативных документов, отражающая логику всей процессной модели организации.
Каждый тип документа имеет свою целевую аудиторию.
Стандарты предприятия и Положения о деятельности адресованы топ‑менеджменту. В них деятельность описана укрупнённо, но чётко определены ключевые метрики, зоны ответственности и состав входящих бизнес‑процессов.
Регламенты бизнес‑процессов предназначены для руководителей среднего звена, отвечающих за организацию и контроль выполнения процессов.
Документированные процедуры используются операционным персоналом и описывают пошаговый порядок выполнения конкретных операций.
Соответственно, степень детализации информации в этих документах различается: чем ниже уровень процесса, тем конкретнее и детальнее описываются действия исполнителей. При этом вся система документации остаётся логически связанной — от стратегического уровня управления до рабочего места специалиста.
HighAdvance Consulting Group оказывает услуги по проведению (офлайн и онлайн) фасилитации и стратегических сессий , форсайтов, сценарного планирования. За дополнительной информацией обращайтесь к ведущему эксперту Максиму Александровичу Логинову +7 921 334 67 62 | mrloginov2209@gmail.com×
Моделирование бизнес-процессов организации. Три шага при запуске проекта
При запуске проекта по описанию бизнес-процессов, по внедрению или актуализации процессного подхода в компании есть три шага.
Первый шаг
Первый шаг — это создание BPM-компетенции в компании. В рамках этого шага мы:
- разрабатываем соглашение о моделировании, положение о процессном управлении в компании
- договариваемся о нотациях, которые будут использоваться
- подбираем инструменты для моделирования.
На этом же этапе проводится обучение бизнес-аналитиков, которые будут, опираясь на соглашение о моделировании:
- описывать бизнес-процессы
- формировать схемы
- заполнять правильно необходимые атрибуты наших процессов для того, чтобы потом получались качественные, полноценные, наполненные актуальной информацией, регламентирующие документы.
Здесь же передаются различные технологии, ну, такие как проведение интервью, модерация моделирующих сессий. Эти знания и навыки необходимы экспертам, когда они ведут групповую работу над процессом. По потребностям заказчика на этом же этапе бизнес-аналитиков подготавливаем к анализу бизнес-процессов.
Всегда передаются знания по визуальному анализу — изучаются правила работы с графической моделью процесса. Есть определенный чек-лист на что нужно обращать внимание, когда эксперты работают со схемой процесса:
- бесполезные действия
- дублирующие функции
- серые пятна и т.д.
Обучение проводиться на материалах компании, чтобы участники видели свою деятельность и обучение проходило эффективнее.
В рамках обучения изучаются аналитические инструменты:
- Контрольная карта Шухарта — это инструмент статистического управления качеством, который используют для оценки стабильности и предсказуемости бизнес‑процессов. Она строится на основании фактических данных по ключевым показателям, отражающим количественные или качественные характеристики процесса, и позволяет отслеживать отклонения во времени, выявлять выход процесса из стабильного состояния и анализировать причины вариаций. На основе этих данных принимаются управленческие решения, направленные на повышение устойчивости и эффективности системы управления.
- Диаграмма Парето — инструмент приоритизации в задачах оптимизации процессов. В течение заданного периода фиксируется количество отклонений по отдельным процессам или видам проблем, после чего данные визуализируются в виде диаграммы Парето, показывающей, какие процессы или причины дают наибольший вклад в общий объём отклонений. Это позволяет сфокусировать усилия на наиболее «проблемных» процессах, сократить число отклонений за единицу времени и получить максимальный эффект от улучшений.
- Диаграмма Исикавы (или «рыбья кость») — графический инструмент поиска причин отклонений и дефектов. В рамках обучения и рабочих сессий с её помощью совместно с участниками по шагам исследуются возможные причины, приведшие к возникновению проблемы в конкретном процессе, группируются факторы и выстраиваются причинно‑следственные связи. Такой формат работы помогает структурировать экспертные знания, выйти за рамки очевидных объяснений и сформировать обоснованные гипотезы для дальнейшего анализа и корректирующих действий.
На этом этапе в компании формируются базовые BPM‑компетенции — сотрудники осваивают нотации, принципы моделирования и подходы к работе с процессами, достаточные для дальнейшего развития системы своими силами. После прохождения этого этапа предприятие может переходить в режим «самостоятельного плавания», привлекая внешних консультантов точечно, по мере необходимости.
Как правило, экспертиза консультантов требуется в ситуациях, когда:
- необходимо провести сложную моделирующую или стратегическую сессию с участием большого числа стейкхолдеров;
- нужен независимый аудит описанного бизнес‑процесса или схемы процесса, чтобы проверить корректность моделей и минимизировать риски ошибок при последующей автоматизации и внедрении изменений.
Такой формат — внутреннее развитие BPM‑компетенций при точечной поддержке извне — позволяет компании снизить зависимость от консультантов, контролировать риски и одновременно сохранять доступ к внешней экспертизе в наиболее чувствительных и сложных точках проекта.
Пост создан на основе материалов с сайта (полная версия)