Х@йня этот ваш BPM или как не похоронить компанию под кипой бесполезных регламентов

Кажется, мир сошел с ума, захлебывается в тренде на бизнес-аналитиков. По данным HH.ru на сегодня, открыто более 6 500 вакансий со средней зарплатой 170 000 руб/мес.

Т.е. емкость рынка >13 миллиардов руб/год

На этом хайпе, каждый айтишник, который однажды рисовал блок-схемы, считает себя супер-пупер бизнес-аналитиком)

Что самое интересное, функционал бизнес-аналитика часто смешивают с функционалом системного аналитика, что максимально странно)

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

Спросите любого, кто хоть раз рисовал блок-схемы, какой методологией он пользуется и на 99,9% услышите BPMN — это ошибка.

Т.е. BPMN — это просто общепринятый подход (свод правил) к отрисовке процессов в виде блоков и стрелочек

Схемы процессов отрисовываются в специализированных программах, их много и они разные. Есть дорогие и супер-профессиональные, которые позволяют формировать документацию (описание процессов) на основании отрисованных схем, например Business Studio, Rational Rose, Elma, до самых простых и доступных, например, Draw.io

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

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

Таким образом, мы все дальше от Бога, от фундаментального понимания и преимуществ, которое дает использование Процессного управления (Управления Процессами)

Итак,

Правильно, когда Процессное управление в компании осознанно опирается на какую-либо методологию, либо их комбинацию.

Методологию нужно подбирать исходя из:
— Целей компании
— Целей Процессного управления
— Выбранной Парадигмы Управления
— Функциональности (основного вида деятельности компании или ее отдельных подразделений)

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

Так, для ИТ-компаний подходят:

1. Agile — Методология гибкого управления проектами, сосредоточенная на быстрой адаптации к изменениям и активном вовлечении заинтересованных сторон.
2. Scrum — Agile-методология, применяемая для управления проектами, которая делит процесс на итерации (спринты) и включает регулярные встречи.
3. ITIL (Information Technology Infrastructure Library) — Рамочная программа для управления ИТ-услугами, предлагающая лучшие практики для управления ИТ-процессами.
4. COBIT (Control Objectives for Information and Related Technologies) — Модель управления для разработки и управления бизнес-ИТ, сосредотачивающаяся на контроле и управлении информационными технологиями.

Для производственных компаний подходят:

1. Six Sigma — Методология, основанная на данных, указывающая на повышение качества процессов путем снижения вариативности и дефектов.
2. Lean Management — Философия управления, сосредотачивающаяся на устранении потерь и оптимизации процессов для повышения эффективности.
3. Тотальное управление качеством (TQM) — Комплексный подход к долгосрочному успеху через удовлетворение клиентов и вовлечение всех сотрудников в процесс улучшения качества.

Наиболее распространена на рынке и массово используется методология BPM

Фокус на клиенте и ценности, которую процесс создает.

Цикл управления процессами по методологии BPM

1. Идентификация процесса:
• Определение границ процесса и его участников.
• Сбор информации о текущих процессах.
2. Моделирование процесса:
• Создание диаграммы процесса с использованием в нотации BPMN
• Моделирование различных сценариев и вариантов выполнения процесса.
3. Анализ процесса:
• Оценка эффективности процесса (потери, узкие места).
• Использование техник, таких как SWOT-анализ или 5 почему, для выявления проблем.
4. Оптимизация процесса:
• Разработка предложений по улучшению (автоматизация, изменение потоков).
• Проектирование новых рабочих процессов или модификация существующих.
5. Реализация изменений:
• Внедрение оптимизированных процессов.
• Обучение сотрудников и внедрение новых практик.
6. Мониторинг и контроль:
• Отслеживание выполнения процесса с помощью ключевых показателей эффективности (KPI).
• Использование контрольных точек для оценки прогресса и выявления отклонений.
7. Обратная связь и улучшение:
• Сбор отзывов от участников процесса.
• Регулярные аудиты по исполнению процессов
• Постоянное улучшение на основе полученной информации (цикл PDCA – Plan-Do-Check-Act).

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

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

И все это потому, что подход к оптимизации выбран неверно.

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

BPM — это прекрасно. И обязательно должно использоваться в компаниях для поддержания порядка и развития, но исключительно в качестве поддержки после проекта оптимизации и, крайне желательно, собственным проектным офисом.

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

Разумеется, чтобы качественно выполнить эту работу, необходимо владение не столько техническими средствами описания бизнес-процессов, сколько понимание сквозных процессов в компании, бизнес-образование, большая насмотренность и знание Best Practics — лучших отраслевых практик. Представить, что такой опытный бизнес-технолог будет заниматься отрисовкой схем, а тем более проектированием API — странное желание.

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

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