Сила регламентов (часть 1)
На днях решил задать ИИ вопрос про самые большие боли бизнес-процессов и с удивлением обнаружил, что одной из самых частых является тема регламентов. Вроде бы тема старая и избитая. Но в комментариях под многими статьями похожие боли:
«Написали подробный регламент, а сотрудники всё равно делают по-своему». «Уровень исполнения — процентов тридцать. Остальное саботаж». «Регламент есть, но никто в него не заглядывает, пока проверка не придёт».
Если вам такое знакомо или вы в принципе хотели бы разобраться в этой теме, то давайте разбираться вместе. Чтобы понять, почему регламенты не работают и как сделать так, чтобы они работали на 100%.
Итак, начнём. Классический ответ на вопрос «почему регламенты не работают?» звучит так: потому что нет контроля, потому что люди недисциплинированные, потому что руководитель не требует. Но это всё следствия. А причина глубже.
Давайте посмотрим, что обычно пишут в регламентах. В подавляющем большинстве — одно и то же: кто ответственный, за что он ответственный, кто кому подчиняется, зоны и матрицы ответственности и обязанности.
И вот здесь зарыта главная проблема. Такой регламент отвечает на вопрос «кто виноват», но не отвечает на вопрос «как нужно правильно выполнять работу». Работник открывает документ и видит: «Мастер цеха несёт ответственность за качественное выполнение слесарных работ». Отлично. А как именно? А если сроки горят? А что делать, если деталь не подошла не по вине мастера? Можно ли доработать и передать дальше? Ничего этого в регламенте нет. Есть ответственность. И муки каждый раз делать выбор и отстаивать его. Ну как? Хотели бы выполнять такой регламент? Думаю, что нет. Поэтому регламент и не работает.
Чтобы исправить ситуацию, давайте сначала разберёмся, что такое регламент на самом деле.
В моей интерпретации регламент — это документ, который фиксирует информационные потоки, способы их обмена и алгоритмы принятия решений. Зоны ответственности и должности в таком регламенте тоже есть, но они вторичны. А на первом месте именно то, что происходит между людьми, когда работа движется от одного этапа к другому.
В таких регламентах есть три вещи, которые они должны описывать.
1. Передача информации. Для получения определённого, одинакового результата всегда нужен один и тот же набор данных. Конструктор разрабатывает чертёж и формирует перечень номенклатуры для снабжения. Передаёт сборочный чертёж технологу, тот прорабатывает вопрос, как это изготовить. После чего технолог передаёт дальше в производство. Производство изготавливает, соблюдая требования. Этот набор информации неизменен для каждого конкретного предприятия. Меняются только лица, которые с ним работают. И что бы вы ни производили — мебель, автомобиль, лавку, металлоконструкцию — неважно. Набор данных, которые нужно передать, чтобы получить изделие, на каждом из предприятий будет один и тот же. А это значит, что для получения одинакового результата с одинаковым качеством регламент должен фиксировать: какая информация, на основании чего формируется, в каком виде передаётся и кому.
2. Алгоритм принятия решений. Помимо информации регламент должен описывать ещё и то, как действовать в той или иной ситуации. Простой пример — отдел качества. Смотрим, соответствует ли продукция конструкторской документации. Если да — идём дальше. Если нет — пишем акт. Если частично нет — тоже пишем акт, но с указанием конкретных отклонений. Дальше: изолятор брака или доработка, вызов конструктора, принятие коллегиального решения. Всё это можно и нужно прописать как последовательность: что делаем в каком случае, что пишем в какой графе, и так далее. И тогда алгоритм остаётся неизменным, независимо от того, кто его исполняет. Сегодня ОТК, завтра технолог или ответственный мастер. Именно поэтому в моём подходе роль исполнителя (ответственного) вторична.