Я проверяю процесс на отсутствие незаменимого сотрудника, а не на скорость идеального исполнителя

Я проверяю устойчивость процесса не по тому, как быстро работает самый опытный сотрудник. Для меня важнее другой вопрос: сможет ли коллега продолжить дело, если этого человека завтра нет на связи?

Это не проверка людей на заменяемость. Хороший специалист знает контекст, которого нет в инструкции. Проблема начинается тогда, когда весь путь клиента держится только в его голове: кому написать, где посмотреть исключение, что можно решить без согласования, а что нельзя. Пока он на месте, такой процесс кажется быстрым. Когда он уходит в отпуск или заболевает, компания внезапно узнаёт цену своей «эффективности».

Зависимость обычно прячется в обычных фразах

Её редко видно в схеме процесса. Зато она слышна на планёрке: «спросите у Марины», «Иван знает, где это лежит», «она всегда понимает, что имел в виду клиент». В этих словах нет ничего плохого. Плохо, когда система не оставляет следующему человеку ни истории решения, ни понятного следующего шага.

Представьте склад, ключ от которого лежит у самого аккуратного кладовщика. Пока он приходит вовремя, склад работает. Но ключ не становится системой учёта только потому, что хозяин ключа надёжен. С цифровыми процессами то же самое: личная память может быть хорошей страховкой, но не должна быть единственным механизмом.

Я начинаю не с регламента на двадцать страниц

Самый полезный материал часто умещается в нескольких ответах: с чего начинается работа, какой результат считается готовым, какие данные нужны на входе, кто принимает решение при исключении и где остаётся след. Это не бюрократия. Это способ снять с сильного сотрудника роль круглосуточного переводчика между людьми и системами.

Например, в обращениях клиентов полезно договориться не только о сроке ответа. Нужно видеть, что происходит, если вопрос пришёл без номера договора, если клиент прислал противоречивые данные или если исполнитель не может воспроизвести проблему. Когда эти развилки названы, новый сотрудник не начинает с личного чата с предшественником.

В IT-продуктах я отдельно смотрю на права, очереди и историю действий. Если задача закрыта, должно быть понятно кем, почему и что стало с обещанием клиенту. Если данные исправлены, важно видеть старое значение и основание изменения. Здесь полезна живая документация, которая растёт из ближайшего изменения, а не папка, которую открывают раз в год.

Проверка проще, чем кажется

Я выбираю один реальный рабочий сценарий и прошу пройти его человека, который не участвовал в его настройке. Не для экзамена. Для поиска мест, где система молчит. Может оказаться, что карточка клиента не показывает важный статус, доступ выдаётся по просьбе в мессенджере, а исключение существует только в памяти руководителя.

Такой тест полезнее красивого дашборда. Он показывает не скорость идеального исполнителя, а способность процесса пережить обычный рабочий день: отпуск, смену сотрудника, рост нагрузки или спорный запрос. Для SaaS это ещё и проверка того, не оказался ли клиент один на один с непонятным шагом. Об этом я писал, разбирая момент, когда пользователь остаётся без следующего шага.

Что меняется после такой проверки

Не нужно пытаться сразу описать всю компанию. Достаточно взять один рискованный участок и сделать его понятным: добавить поле причины, назначить владельца очереди, зафиксировать правило передачи или вывести историю рядом с решением. Затем снова пройти тот же сценарий. Если другой человек может завершить работу без догадок и лишнего ожидания, изменение сработало.

Автоматизация здесь помогает, но не заменяет договорённость. Она может собрать обращения в очередь, напомнить о сроке и сохранить историю. Но она не угадает правило, которое команда никогда не сформулировала. Поэтому перед настройкой я ищу не «самого незаменимого» сотрудника, а самый важный ручной перевод: тот момент, где работа останавливается, пока кто-то не вспомнит, как принято.

Это спокойный способ сделать процесс человечнее. Сильный сотрудник перестаёт быть аварийной службой для всего бизнеса, а коллеги получают возможность действовать уверенно. И именно тогда система начинает поддерживать работу, а не просто хранить карточки.

Что стоит оставить в системе

Я не предлагаю записывать каждое движение мыши. Важнее оставить след там, где меняется обязательство: клиенту обещали срок, документ ушёл на согласование, задача вернулась с замечанием, доступ дали или отозвали. У такого следа должен быть понятный владелец и язык, который одинаково понимают продажа, операция и поддержка.

Полезно отделить знания о правиле от знания о конкретном случае. Правило «без подтверждённого контакта заявка не передаётся в работу» может жить в настройке формы. А пояснение, почему для конкретного клиента сделали исключение, должно быть видно в карточке. Тогда через месяц команда не восстанавливает историю по обрывкам переписки.

Отдельно я смотрю на момент передачи. Задача не должна исчезать у одного человека раньше, чем появилась у другого. Простая очередь с ответственным и временем следующей проверки часто полезнее сложного маршрута. Если очередь растёт, это тоже не повод тихо нанять ещё одного исполнителя: сначала стоит понять, какое решение в ней ждёт владельца.

Наконец, процесс нужно пересматривать после настоящего сбоя, а не только после внедрения. Не для поиска виноватого, а чтобы добавить недостающую подсказку, поле или развилку. Такой подход превращает работу с зависимостью от людей в регулярное улучшение, а не в тревожный проект «на всякий случай».