В компании может быть хороший регламент, понятная схема процесса и даже формально назначенные ответственные. Но это совсем не гарантирует, что сотрудники начнут работать по новым правилам. Очень часто через пару недель всё возвращается к старой привычной схеме: задачи снова ставят в личных сообщениях, согласования проходят устно, а сотрудники спрашивают друг друга "а как у нас это обычно делается?". Проблема здесь не всегда в дисциплине. Чаще причина в том, что сам документ внедрили, а новый способ работы - нет. Разберём шесть типичных ошибок и что делать, чтобы регламент действительно стал рабочим инструментом.
Я часто вижу одну и ту же ситуацию. Компания тратит время на описание процесса, документ несколько раз согласовывают, правят формулировки, утверждают финальную версию, рассылают сотрудникам и считают задачу закрытой. На деле в этот момент работа только начинается. Регламент - это описание желаемого порядка, но не гарантия того, что люди будут действовать именно так.
Для меня главный критерий внедрения очень простой: что именно стало происходить по-другому после появления документа? Если до регламента задачи ставили в чатах и после регламента продолжают ставить там же, значит, процесс не изменился. Если раньше согласования проходили устно и спустя месяц всё осталось так же, значит, появился файл, но не новая система работы.
Любое изменение привычного процесса сначала воспринимается как усложнение. Представим, что раньше расход согласовывали одним сообщением руководителю: "Можно оплатить подрядчика на 30 000?". Теперь нужно заполнить форму, указать сумму, статью бюджета и приложить счёт. С точки зрения сотрудника новый порядок выглядит тяжелее старого.
Поэтому недостаточно сказать: "С понедельника работаем так". Нужно объяснить, какую проблему новый порядок решает. Например: "Согласования теряются в переписке, бухгалтерия не всегда видит подтверждение, а руководителям приходится искать старые сообщения. Теперь все расходы фиксируем в одном месте". После такого объяснения у процесса появляется логика.
Я бы всегда отвечала команде на три вопроса: что было неудобно раньше, что конкретно меняется сейчас и какой результат мы хотим получить. Когда люди понимают смысл, сопротивление обычно снижается само.
Это одна из самых частых причин, почему регламент не приживается. Можно написать, что все задачи должны находиться в корпоративной системе, но если руководитель продолжает присылать поручения в личный чат, сотрудники будут ориентироваться на чат. Можно зафиксировать, что расходы согласовываются через форму, но если собственник отвечает "ок" в Telegram, именно это становится настоящим процессом.
Люди очень быстро понимают, где формальное правило, а где реальная власть. Поэтому я бы начинала внедрение не с рядовых сотрудников, а с руководителей. Если компания договорилась, что заявки на подбор принимаются только через форму, руководитель тоже должен пользоваться формой. Если задача не занесена в систему, она не должна считаться поставленной.
Иначе сотрудники получают противоречивый сигнал: "Правила есть, но соблюдать их необязательно". После этого вернуть процесс в систему становится гораздо сложнее.
Ещё одна типичная история - документ создают "для порядка". В итоге появляется большой регламент взаимодействия, где много правильных слов про сроки, ответственность и передачу информации, но сотруднику по-прежнему непонятно, что делать в конкретной ситуации.
Хороший регламент почти всегда рождается из конкретной боли. Например, заявки клиентов теряются между отделами, новые сотрудники выходят без доступов, договоры слишком долго согласовываются, руководители по-разному открывают вакансии, никто не понимает, кто принимает финальное решение.
Возьмём подбор. Если один руководитель пишет HR в мессенджере, второй говорит о вакансии на планёрке, а третий присылает голосовое, неудивительно, что часть запросов теряется. Здесь не нужен документ на десять страниц. Гораздо полезнее зафиксировать простой порядок: вакансия считается открытой только после заявки, в заявке есть обязательные поля, HR подтверждает запуск в течение одного рабочего дня, без согласованного бюджета поиск не начинается.
Такой регламент работает, потому что решает реальную проблему, а не просто создаёт ощущение порядка.
Иногда внутренний документ выглядит настолько официально, что сотруднику проще спросить коллегу, чем разобраться самому. Формулировки вроде "ответственное лицо осуществляет проверку корректности предоставленных сведений" выглядят серьёзно, но не помогают действовать.
Если человек после прочтения документа всё равно задаёт вопросы "Кому отправить?", "Кто принимает решение?", "Сколько ждать ответа?", "Что делать, если данных нет?", значит, регламент описан недостаточно практично.
Я бы проверяла любой документ очень просто: дать его сотруднику, который раньше не участвовал в процессе, и попросить пройти путь от начала до конца. Если он понимает порядок без дополнительных объяснений, регламент работает. Если нет - документ нужно упрощать.
Хороший регламент не обязательно должен быть коротким, но в нём должны легко находиться основные вещи: старт процесса, ответственный, ключевые шаги, срок, ожидаемый результат и действия в нестандартной ситуации.
Это особенно заметно в процессах, где задействовано несколько подразделений. Например, выход нового сотрудника. HR готовит документы, IT создаёт доступы, офис-менеджер готовит рабочее место, руководитель планирует первую неделю. Все делают свою часть, но утром выясняется, что ноутбук не готов.
Дальше начинается знакомое: "Я думала, IT уже сделал", "А я ждал заявку", "Мне никто не сказал, что человек выходит сегодня". Проблема не в том, что кто-то специально сорвал процесс. Проблема в том, что никто не отвечал за результат целиком.
Для меня здесь работает простое правило: участников может быть много, владелец результата должен быть один. Если владельцем выхода нового сотрудника назначен HR, это не значит, что HR сам настраивает ноутбук. Это значит, что он проверяет, что к дате выхода готовы документы, техника, доступы и план первой недели.
Тогда вместо "я свою часть сделал" появляется другой вопрос: "Получили ли мы конечный результат?".
Первый вариант процесса редко бывает идеальным. На бумаге многое выглядит логично, но реальная работа быстро показывает слабые места. Может оказаться, что один шаг дублирует другой, согласование занимает слишком много времени, в форме не хватает нужного поля или сотрудники дважды вводят одну и ту же информацию.
Поэтому я бы всегда назначала проверку через две-три недели после запуска. Причём обсуждать нужно не то, "кто нарушил регламент", а то, где процесс сам создаёт сложности. Полезно спросить сотрудников, на каком этапе они застревают, какой шаг приходится обходить, где новый порядок оказался сложнее старого и какие вопросы повторяются чаще всего.
Если один человек однажды нарушил правило - возможно, это действительно вопрос дисциплины. Если десять человек постоянно обходят один и тот же этап - стоит проверить сам этап. Иногда компания пытается усилить контроль там, где правильнее упростить процесс.
Например, если покупка на 2 000 рублей требует согласования у трёх руководителей, сотрудники рано или поздно начнут искать обходные пути. Здесь проблема не обязательно в людях. Возможно, стоимость самого согласования уже выше стоимости риска.
Я бы не запускала новый документ сразу на всю компанию. Сначала лучше проверить его на небольшой группе сотрудников, которые реально работают в этом процессе. Не просто дать прочитать, а попросить пройти по шагам и отметить, где возникают вопросы.
После запуска стоит оставить короткий тестовый период и заранее назначить дату разбора. На этой встрече полезно собрать реальные сбои: где задача потерялась, где сотрудник не понял следующий шаг, где руководитель снова вмешался вручную, какой этап оказался лишним.
После этого регламент можно скорректировать и уже закрепить как рабочую версию. Это нормальный процесс. Хороший документ не обязан быть идеальным с первой попытки.
Ещё один важный момент - новый порядок должен быть встроен в рабочие инструменты. Если есть заявка, должна быть удобная форма. Если нужен шаблон, он должен лежать там, где сотрудник его реально найдёт. Если задачи ставятся в системе, руководители должны использовать ту же систему. Чем меньше человеку приходится помнить правила "силой воли", тем устойчивее работает процесс.
Для меня показатель внедрения - не подпись под документом и не формальное "ознакомлен". Гораздо важнее реальные изменения: сотрудники реже задают повторяющиеся вопросы, задачи перестают теряться, руководителю не приходится вручную контролировать каждый этап, новые люди быстрее включаются в работу, а одинаковых ошибок становится меньше.
И главное - когда у сотрудника возникает вопрос, он действительно идёт в регламент и находит там ответ. Не потому, что обязан, а потому, что это самый быстрый способ разобраться.
Вот тогда документ становится рабочим инструментом.
Если сотрудники продолжают работать "как привыкли", я бы не начинала с вывода, что они сопротивляются изменениям. Сначала стоит проверить сам процесс внедрения. Поняли ли люди, зачем нужен новый порядок? Работают ли руководители по тем же правилам? Решает ли регламент конкретную проблему? Можно ли им пользоваться без лишних объяснений? Есть ли один владелец результата? Проверяли ли процесс после запуска?
Очень часто причина находится именно здесь. Написать регламент сравнительно просто. Гораздо сложнее сделать так, чтобы новый способ работы оказался понятнее и устойчивее старого. И когда сотрудники перестают спрашивать "А как мы обычно это делаем?", можно считать, что регламент действительно внедрён.
Отправляя данные вы подтверждаете пользовательское соглашение