Инструкция работает, а процесс уже нет: как понять, что регламент устарел
Краткая аннотация
Рабочая инструкция может оставаться формально правильной и при этом мешать процессу. Я разбираю, как отличить полезный контроль от шага, который давно потерял смысл, почему сотрудники продолжают выполнять лишние действия и как пересматривать регламент без риска сломать то, что всё ещё работает.
Я раньше думала, что устаревшая инструкция выглядит очевидно: старые скриншоты, несуществующие кнопки, фамилии сотрудников, которых давно нет в компании. На практике самые опасные инструкции выглядят аккуратно. Все пункты выполнимы, сотрудники их знают, руководитель уверен, что процесс под контролем.
Проблема появляется в другом месте. Причина, ради которой когда-то добавили определённый шаг, исчезла, а сам шаг остался. Система уже автоматически хранит версии документов, но люди продолжают сохранять копии вручную. CRM уже проверяет обязательные поля, но менеджер всё равно переносит данные в Excel для второй проверки. Так процесс постепенно обрастает действиями, которые никто не решается убрать.
Я стала смотреть на инструкции не как на список действий, а как на набор защитных механизмов. И для каждого пункта задавать один неудобный вопрос: какую конкретно ошибку этот шаг предотвращает сегодня?
У каждого пункта должна быть причина существования
Плохой признак — когда на вопрос зачем мы это делаем отвечают потому что так написано в инструкции.
Сам по себе такой ответ ничего не доказывает. Возможно, пункт действительно критичный, просто сотрудники не знают его происхождения. Но если никто не может объяснить, какой риск он закрывает, я начинаю разбирать его отдельно.
Возьму простой пример.
В процессе подготовки договора была инструкция: перед отправкой клиенту менеджер должен сохранить финальный файл в отдельную сетевую папку. Когда правило появилось, документы пересылали по почте, версии легко путались, а сотрудник мог случайно отправить черновик.
Позже компания перешла на систему, где каждая версия договора автоматически сохранялась с историей изменений. Финальный документ формировался из утверждённой версии и уже физически не мог потеряться.
Но пункт про сетевую папку остался.
В итоге сотрудник:
- открывал финальный договор;
- скачивал его;
- переименовывал по шаблону;
- сохранял в сетевую папку;
- после этого отправлял клиенту.
Технически всё выполнялось правильно.
Только защита от потери версии уже находилась в другой системе.
То есть контроль не усиливал процесс. Он дублировал другой контроль.
Именно это я считаю первым признаком устаревшей инструкции: действие осталось, а риск, ради которого оно появилось, уже закрывается другим механизмом.
Я проверяю не шаг, а связку риск → контроль
Удалять действия просто потому, что они кажутся лишними, опасно.
Некоторые странные пункты появились после очень конкретного сбоя, о котором через два года уже никто не помнит.
Поэтому я сначала восстанавливаю причинную цепочку.
Например, в регламенте написано: перед запуском рекламной кампании вручную сверить дневной бюджет в кабинете и в CRM.
На первый взгляд — очевидное дублирование.
Но дальше выясняется, что CRM получает бюджет из внешней системы с задержкой. Если менеджер изменил значение непосредственно перед запуском, старая сумма ещё некоторое время остаётся в CRM.
Теперь ручная сверка выглядит уже совсем иначе.
Она не просто повторяет данные.
Она закрывает конкретное окно рассинхронизации.
Перед тем как убрать пункт, я проверяю пять вещей:
- какая ошибка возможна без этого действия;
- где впервые появился этот риск;
- есть ли сейчас другой механизм, который его закрывает;
- одинаково ли этот механизм работает во всех сценариях;
- что произойдёт, если убрать ручной контроль сегодня.
Последний вопрос особенно полезный.
Не что, по нашему мнению, должно произойти, а что реально произойдёт в системе.
Иногда обнаруживается, что автоматизация работает только в основном сценарии, а ручной пункт спасает исключения.
Второй пример: Excel, который никто не решался удалить
У меня был похожий случай с клиентскими данными.
Менеджер создавал клиента в CRM, а затем переносил часть полей в общую таблицу. В таблице были название компании, ИНН, менеджер, тариф и статус подключения.
На вопрос зачем нужна таблица ответ был привычный: для контроля.
Я открыла процесс и увидела, что CRM уже содержит все эти поля.
Более того, часть данных в таблице регулярно расходилась с CRM просто потому, что после изменения тарифа кто-то забывал обновить Excel.
Получилась странная ситуация: резервный контроль был менее надёжным, чем система, которую он должен был контролировать.
Но просто удалить таблицу было нельзя.
Оказалось, что бухгалтерия использовала её для одной операции: один раз в неделю забирала оттуда список новых клиентов.
То есть 90% таблицы действительно превратились в цифровой ритуал, но у оставшихся 10% была реальная функция.
Мы не стали спорить, нужна таблица или нет.
Мы разложили её назначение на части.
CRM уже была источником данных о клиенте. Значит, дублировать карточки не требовалось.
А бухгалтерии на самом деле нужен был не Excel, а конкретный список новых подключений за период.
После этого задача стала технически понятной: сформировать такой список из CRM автоматически.
Таблицу удалось убрать не потому, что она старая, а потому, что мы нашли последнего потребителя функции, ради которой она ещё существовала.
Это важная разница.
Устаревшие инструкции часто держатся на скрытых зависимостях
Есть ещё одна причина, почему регламенты трудно чистить.
В инструкции описано действие одного сотрудника, но результатом этого действия может пользоваться другой отдел.
Причём это нигде не документировано.
Например, менеджер перед закрытием сделки вручную добавляет специальный комментарий.
Для него комментарий выглядит бессмысленно.
Но потом выясняется, что бухгалтер использует поиск по этой фразе, чтобы находить определённый тип операций.
Если менеджер просто перестанет писать комментарий, его собственный процесс станет быстрее, а соседний — сломается.
Поэтому при пересмотре инструкции я стараюсь смотреть не только вперёд по процессу, но и в стороны.
Кто использует результат этого действия?
Кто читает создаваемый файл?
Кто смотрит на статус?
Кто зависит от названия?
Кто использует поле, которое сотрудники заполняют вроде бы для галочки?
Иногда ответ находится совершенно не там, где я ожидала.
Именно поэтому я не люблю подход уберём все лишние шаги. Лишний для одного участника шаг может быть входом для другого процесса.
Есть признаки, по которым инструкция начинает выдавать свой возраст
Некоторые симптомы повторяются довольно часто.
Например, сотрудник выполняет действие только потому, что без него формально нельзя закрыть этап, хотя фактически результат нигде не используется.
Или один и тот же факт вводится дважды в разные системы.
Или инструкция заставляет человека вручную проверять то, что система уже умеет валидировать автоматически.
Но есть и менее очевидные признаки:
- пункт регулярно обходят, но проблем из-за этого не возникает;
- сотрудники создали неофициальный короткий путь, которым пользуются все опытные;
- действие необходимо только для одной старой категории клиентов;
- контроль появился из-за ограничения системы, которого уже нет;
- этап заканчивается созданием информации, которую никто дальше не читает.
Для меня особенно интересен неофициальный короткий путь.
Если новички работают по инструкции, а опытные сотрудники постоянно её сокращают, это не обязательно значит, что опытные нарушают процесс.
Иногда они просто давно обнаружили, что часть процесса существует только на бумаге.
Но и копировать их поведение автоматически нельзя.
Сначала нужно понять, почему короткий путь работает.
Самый полезный вопрос — что именно является результатом шага
В инструкциях часто описывают действия, но редко описывают результат.
Например:
загрузить файл;
поставить галочку;
написать комментарий;
проверить реквизиты;
перенести данные;
сохранить копию.
Я стараюсь переписать такой пункт мысленно в другой форме:
что должно быть истинно после выполнения этого шага?
Если написано проверить реквизиты, результат может звучать так: ИНН и расчётный счёт прошли проверку по источнику X.
Если написано сохранить файл, реальный результат может быть таким: финальная версия документа доступна для восстановления.
Если написано согласовать скидку, результат: подтверждено, что скидка не выводит сделку за допустимый уровень маржи.
Это уже намного полезнее.
Потому что после этого появляется возможность заменить действие, не потеряв цель.
Сегодня финальную версию документа человек сохраняет вручную.
Завтра система делает это автоматически.
Результат остаётся тем же.
И инструкция может измениться без изменения самого контроля.
Я бы не удаляла устаревший шаг сразу
Если пункт влияет на деньги, документы, права доступа или обязательства перед клиентом, я бы не убирала его в пятницу вечером со словами вроде теперь всё автоматизировано.
Есть более спокойный способ.
Некоторое время старый контроль можно оставить, но перестать использовать его как единственный источник истины.
Например, система автоматически проверяет реквизиты, а сотрудник ещё неделю выполняет ручную сверку.
Мы сравниваем результаты.
Если автоматика и человек постоянно получают одно и то же, это аргумент в пользу удаления ручного шага.
Если находятся расхождения, задача уже не в инструкции.
Нужно понять, в каком сценарии автоматическая проверка неполна.
Такой параллельный режим полезен ещё и потому, что документация редко описывает все исключения.
Старый процесс может помнить о них лучше документации.
Инструкцию стоит хранить вместе с причиной изменения
Есть ещё одна вещь, которой мне часто не хватает в регламентах: истории решений.
Написано:
перед отправкой проверить поле вручную.
Но неизвестно, почему.
Через год этот пункт выглядит абсурдно, и начинается спор.
Один говорит, что его нужно удалить.
Другой боится, что он появился не просто так.
Оба правы.
Поэтому для важных правил я бы сохраняла не только новую формулировку, но и короткую причину изменения.
Например:
Ручная проверка добавлена после случаев, когда интеграция не передавала код региона.
Теперь через год можно проверить конкретную вещь: передаёт ли текущая интеграция код региона во всех сценариях.
Если передаёт — у нас появляется основание удалить контроль.
Без этого знания приходится угадывать.
В технической документации такой подход давно привычен: есть история изменений, причины архитектурных решений, версии API.
В бизнес-инструкциях почему-то часто остаётся только текущий текст.
И вместе с историей документа исчезает история причин.
Когда я считаю инструкцию действительно устаревшей
Для меня возраст документа почти ничего не значит.
Инструкция пятилетней давности может прекрасно работать.
А регламент, написанный три месяца назад, может уже не соответствовать процессу после смены CRM или интеграции.
Я считаю пункт кандидатом на пересмотр, если происходит хотя бы одно из трёх.
Первое: риск, ради которого появился контроль, больше не существует.
Второе: тот же риск уже надёжно закрывается другим механизмом.
Третье: действие создаёт данные или результат, которыми никто больше не пользуется.
Но даже тогда я не начинаю с удаления.
Сначала проверяю зависимости и исключения.
Потому что цель не в том, чтобы сделать инструкцию короче.
Цель — оставить в ней только те действия, которые действительно поддерживают процесс.
Вывод
Устаревшая инструкция редко выглядит старой.
Гораздо чаще это вполне аккуратный документ, который сотрудники дисциплинированно выполняют каждый день.
Просто часть его шагов появилась в другой технической реальности.
Когда-то файл нужно было сохранять вручную, потому что версии терялись.
Когда-то данные дублировали в таблице, потому что другой отдел не имел доступа к CRM.
Когда-то поле проверяли глазами, потому что интеграция периодически его теряла.
Потом системы меняются, а инструкции — нет.
Поэтому я больше не начинаю пересмотр регламента с вопроса какой пункт можно убрать.
Я начинаю с другого:
какой риск закрывает этот пункт и существует ли этот риск сейчас?
Если ответ есть, инструкция ещё выполняет работу.
Если ответа нет, начинается нормальное техническое расследование: кто использует результат, какие зависимости спрятаны дальше по цепочке и можно ли заменить ручное действие более надёжным механизмом.
Только после этого я что-то удаляю.
Потому что хороший регламент — это не документ, в котором подробно описано всё, что сотрудники привыкли делать.
Это документ, в котором каждое действие всё ещё имеет причину.