Я захожу в организацию и почти всегда вижу одно и то же. Папка с регламентами есть. Люди по ним не работают. Руководитель уверен, что документы верные.
Проблема не в документе. Проблема в том, что регламент и реальный процесс существуют в параллельных мирах.
Регламент — это документ, описывающий бизнес-процесс. Не наоборот. Это простое правило нарушается в большинстве организаций — и именно здесь начинается хаос.
strong>Почему регламенты не работают.
За годы практики я видел пять причин. Они разные по природе, но одинаковые по результату.
Первая и самая частая: регламент создан человеком, который не понимает реальных ролей и обязанностей. Он описал как должно быть, не зная как есть на самом деле. Ответственные назначены формально. Люди узнали об этом из готового документа.
Вторая: регламент непонятный. Написан формально правильно, но без обучения, разъяснений и примеров. Люди не знают как по нему работать и работают как привыкли.
Третья: отписка. Создан для аудита или проверки. Никто не планировал по нему работать с самого начала.
Четвёртая: оторван от реальности. По факту процессы работают иначе. Разрыв между документом и практикой никто не закрыл.
Пятая и самая опасная: основан на ошибочных процессах. Ошибка зафиксирована в документе и воспроизводится снова и снова.
strong>Что происходит когда руководитель настаивает на нерабочем регламенте.
Команда игнорирует документ — это нормальная защитная реакция. Люди чувствуют, что он не отражает реальность, и продолжают работать так, как работали.
Опасность начинается когда руководитель убеждён, что регламент верный, и заставляет по нему работать. Тогда разрушаются живые процессы, которые держали систему. А нерабочий регламент их не заменяет.
Организация теряет то немногое, что работало.
strong>Как я работаю с нерабочими регламентами.
Первый шаг всегда один — диагностика реального процесса.
Кто держатель процесса. Как он выстроен по факту, а не по документу. Кто ответственный на каждом этапе. Как процесс распределён по должностям и отделам.
Только после того как реальная картина собрана, можно приступать к корректировке регламента, разъяснениям и обучению.
Рабочий регламент рождается из реального процесса. Сначала понять как работает система. Потом зафиксировать это в документе. Только тогда он будет работать, а не висеть в воздухе.
strong>Из практики.
Обращения в службу поддержки шли в одну точку — к инженеру. Лёгкие вопросы, сложные задачи, претензии, жалобы, предложения — всё к нему. Система не справлялась.
После диагностики процесса и создания рабочего регламента с чётким скриптом поток разделился. Лёгкие обращения пошли к новичкам — они получали практику, инженер разгружался. Сложные задачи шли к профильному специалисту. Претензии и жалобы сразу поступали к руководителю с уже собранными данными для принятия решения.
Инженер перестал быть узким местом. Скорость обработки выросла. Качество информации на входе у руководителя улучшилось.
Регламент не создал новый процесс. Он описал правильный и закрепил его.
Разница между рабочим и нерабочим регламентом не в качестве документа. В том, отражает ли он реальность — или существует параллельно с ней.
Исходная публикация
Открыть в Telegram ↗Материал опубликован в авторском канале и перенесён на сайт с сохранением текста.
