Моделирование бизнес-процессов – как правильно это делать?

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

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

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

Цель проекта картирования процессов

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

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

Как правильно определить цели картирования процессов?

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

Объем проекта

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

Проектирование процессов в организации и их отображение — что нужно учитывать?

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

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

Что, кроме количества процессов, определяет полноту их моделирования?

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

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

Картирование процессов — всегда ли оно должно быть очень подробным?

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

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

Структура карты процесса

При создании карт бизнес-процессов также нельзя игнорировать вопрос их структуры. Если ожидаемый уровень детализации карты значителен, то попытка создать только одну диаграмму на процесс может привести к созданию гигантских диаграмм, которые, если вы хотите анализировать их на бумаге, должны быть распечатаны не в формате А4 и даже не А3, но в формате плаката… Как нетрудно догадаться, читабельность такого произведения была бы ничтожно мала. Кроме того, такой подход также привел бы к повторному отображению одних и тех же групп действий, выполняемых в рамках разных процессов, и, скорее всего, каждый раз немного по-разному.

Соответствующий дизайн карт бизнес-процессов в организации

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

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

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

Что важно в разрезе вариантов отображаемых бизнес-процессов?

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

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

Инструменты нотации и отображения процессов

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

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

Словарь терминов

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

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

Правильная идентификация бизнес-процессов и их отображение — самые важные выводы

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