Регламенты не внедряются сами
Разбирали с командой клиента ситуацию. Руководители написали регламент постановки задач с примерами и шаблонами. Менеджеры пробежались глазами по документу, кивнули и продолжили ставить задачи по-старому.
Почему?
Потому что старый способ по-прежнему проще и привычнее. «По-старому» почти всегда побеждает «по-новому», если за новым подходом не стоит ничего, кроме ещё одного документа в корпоративной Wiki.
Проблема большинства регламентов не в том, что они плохо написаны. Проблема в том, что компании внедряют документы, но не внедряют новое поведение.
Недостаточно написать хороший регламент и сказать: «Теперь работаем так». Нужно сделать новый способ работы понятным, обязательным и контролируемым.
Что для этого можно сделать?
Сначала соберите обратную связь у тех, кто будет работать по регламенту, до того как документ станет финальным. Не просто спросите: «Что думаете?», а попросите конкретные замечания: что здесь может не сработать, где возникнут сложности и как можно улучшить.
Это полезно сразу по нескольким причинам. Сотрудники начинают воспринимать регламент не только как очередное правило, спущенное сверху, а как процесс, в создании которого они участвовали. Именно исполнители часто замечают ограничения, которые не видны руководителю. А иногда обсуждение показывает, что проблема вообще в разном понимании самого процесса.
Обязательно установите дедлайн на ознакомление. Например: «до пятницы, 18:00».
Если до этого момента комментариев нет, считаем, что замечаний к документу у сотрудника тоже нет. После этого аргумент «я не согласен» уже не работает.
Но одного ознакомления всё равно недостаточно. Нужно заранее определить дату, с которой новый порядок становится обязательным, и убрать возможность продолжать работать по-старому.
Если задача должна ставиться по новому шаблону, то в другом формате она просто не принимается в работу. Иначе, если новый процесс можно без последствий игнорировать, его будут игнорировать.
Назначьте ответственного, который будет следить за применением регламента в работе. При этом не обязательно резко вводить изменения во всей компании. Возьмите один проект или небольшую команду и попробуйте новый подход там. Пусть они поработают по регламенту несколько недель. Соберите статистику и посмотрите, что изменилось: стало ли меньше ошибок и потерянного времени.
Тогда у вас появится реальный пример. Остальным гораздо проще «продать» то, что уже работает у коллег, чем то, что просто написано в Wiki. Особенно если новый регламент показал измеримый результат.
Регламент это всего лишь артефакт. А изменение поведения сотрудников — проект со сроками, ответственными, контрольными точками и метриками. Если относиться к внедрению регламента как к публикации документа, он будет пылиться в Wiki. Если относиться к нему как к проекту по изменению поведения, то люди начнут работать по-новому.
Разбирали с командой клиента ситуацию. Руководители написали регламент постановки задач с примерами и шаблонами. Менеджеры пробежались глазами по документу, кивнули и продолжили ставить задачи по-старому.
Почему?
Потому что старый способ по-прежнему проще и привычнее. «По-старому» почти всегда побеждает «по-новому», если за новым подходом не стоит ничего, кроме ещё одного документа в корпоративной Wiki.
Проблема большинства регламентов не в том, что они плохо написаны. Проблема в том, что компании внедряют документы, но не внедряют новое поведение.
Недостаточно написать хороший регламент и сказать: «Теперь работаем так». Нужно сделать новый способ работы понятным, обязательным и контролируемым.
Что для этого можно сделать?
Сначала соберите обратную связь у тех, кто будет работать по регламенту, до того как документ станет финальным. Не просто спросите: «Что думаете?», а попросите конкретные замечания: что здесь может не сработать, где возникнут сложности и как можно улучшить.
Это полезно сразу по нескольким причинам. Сотрудники начинают воспринимать регламент не только как очередное правило, спущенное сверху, а как процесс, в создании которого они участвовали. Именно исполнители часто замечают ограничения, которые не видны руководителю. А иногда обсуждение показывает, что проблема вообще в разном понимании самого процесса.
Обязательно установите дедлайн на ознакомление. Например: «до пятницы, 18:00».
Если до этого момента комментариев нет, считаем, что замечаний к документу у сотрудника тоже нет. После этого аргумент «я не согласен» уже не работает.
Но одного ознакомления всё равно недостаточно. Нужно заранее определить дату, с которой новый порядок становится обязательным, и убрать возможность продолжать работать по-старому.
Если задача должна ставиться по новому шаблону, то в другом формате она просто не принимается в работу. Иначе, если новый процесс можно без последствий игнорировать, его будут игнорировать.
Назначьте ответственного, который будет следить за применением регламента в работе. При этом не обязательно резко вводить изменения во всей компании. Возьмите один проект или небольшую команду и попробуйте новый подход там. Пусть они поработают по регламенту несколько недель. Соберите статистику и посмотрите, что изменилось: стало ли меньше ошибок и потерянного времени.
Тогда у вас появится реальный пример. Остальным гораздо проще «продать» то, что уже работает у коллег, чем то, что просто написано в Wiki. Особенно если новый регламент показал измеримый результат.
Регламент это всего лишь артефакт. А изменение поведения сотрудников — проект со сроками, ответственными, контрольными точками и метриками. Если относиться к внедрению регламента как к публикации документа, он будет пылиться в Wiki. Если относиться к нему как к проекту по изменению поведения, то люди начнут работать по-новому.