Как за 7 шагов внедрить в компании эффективную систему управления бизнес-процессами?

Привет! Я Артемий Прокопенко — бизнес-архитектор, эксперт по цифровой трансформации, развитию и масштабированию бизнеса.

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

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

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

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

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

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

В рамках пилотной фазы надо перестроить процессы одного или нескольких подразделений компании, специалисты которых достаточно лояльны к изменениям (например, отдел ИТ). Процессы стоит распределить по очередям: в 1-ю очередь — 1-2 процесса, во 2-ю — 3-4 и так далее в зависимости от количества и сложности процессов.

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

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

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

Итак, какая структура должна быть у проекта внедрения технологии управленческого цикла? Ответ на этот вопрос — ниже.

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

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

Результат шага — утвержденный перечень целей проекта.

Состав команды определяется исходя из целей проекта.

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

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

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

Результат шага — утвержденный состав проектной команды с описанием обязанностей.

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

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

Результат шага — утвержденный план-график проекта и другая базовая документация.

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

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

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

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

Нотацию (IDEF, EPC, BPMN) и инструменты (Excel, Draw.io, MS Visio) для описания процессов следует выбрать на предыдущем шаге при планировании работы. Главное требование: описание должно отражать суть процессов и быть понятным для своей целевой аудитории.

Результат шага — утвержденное описание процессов в варианте «как есть».

Итак, завершив описание процессов в варианте «как есть», можно перейти к их анализу и оптимизации.

Анализ процесса предполагает поиск «узких мест» и путей их ликвидации.

При анализе важно задавать такие вопросы, связанные с расходованием 2 главных ресурсов бизнеса — денег и времени: за счет чего можно ускорить процесс? (время) за счет чего можно уменьшить себестоимость процесса? (деньги)

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

Финальный реестр предложений утверждается руководителем проекта и является источником для описания процессов в варианте «как должно быть».

Результат шага — утвержденное описание процессов в варианте «как должно быть».

Описание процессов в варианте «как должно быть» необходимо конвертировать в регламентные документы компании.

Иерархия таких документов следующая:

Уровень 1. Регламенты процессов и подпроцессов — документы процессной структуры бизнеса, ориентированные на владельцев процессов и подпроцессов, отвечают на вопрос: как управлять процессом/подпроцессом?

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

Уровень 3. Должностные инструкции — документы функциональной структуры бизнеса, ориентированные на сотрудников, отвечают на вопрос: какие обязанности должен выполнять сотрудник?

Уровень 4. Рабочие инструкции — документы процессной структуры бизнеса, ориентированные на сотрудников, отвечают на вопрос: как сотрудник должен выполнять свои обязанности?

Информация распространяется по уровням водопадным принципом: на уровне 1 формируются функцию, на уровне 2 они распределяются по подразделениям, на уровне 3 — по сотрудникам, на уровне 4 — декомпозируются до конкретных алгоритмов.

Результат шага — утвержденные регламентные документы.

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

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

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

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

Результат шага — отчеты, подтверждающие (цифрами), что процессы реализуются согласно новым регламентам (соблюдение регламентов – более 90%).