Как передать знания о бизнес-системе новому сотруднику?

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

Это важно не только при увольнении или найме. Любая система становится уязвимой, когда её знает один человек. Он может заболеть, уйти в отпуск или просто не помнить, почему три года назад сделали странное исключение. Компания не должна останавливаться вместе с его календарём.

Почему инструкции сами по себе не спасают

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

Новый сотрудник может узнать, куда нажать, но не понять, зачем это действие нужно и что будет, если его пропустить. Например, он видит, как выгрузить заказы, но не знает, какие из них нельзя передавать в учётную систему до подтверждения оплаты. Формально инструкция есть. Управляемой передачи дела — нет.

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

Соберите одну карту системы

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

• какие задачи бизнеса решает система;
• какие люди и отделы в ней работают;
• какие внешние сервисы с ней связаны;
• где находятся ключевые данные;
• кто владелец процесса, кто администратор и кто может подстраховать;
• какие действия происходят каждый день, неделю и месяц.

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

Если такой карты нет совсем, полезно сначала разобраться, зачем она нужна руководителю: «Зачем бизнесу карта IT-систем?». Карта нужна не для красоты на встрече с подрядчиком. Она помогает быстро принять решение, когда что-то меняется.

Разделите знание на четыре слоя

Одна длинная инструкция плохо читается и быстро устаревает. Проще собрать знания по слоям.

1. Рабочий слой. Как менеджер, бухгалтер, кладовщик или оператор делает свои обычные действия.
2. Управленческий слой. Какие показатели смотрят, кто подтверждает исключения и по каким правилам принимают решения.
3. Технический слой. Где размещена система, какие есть интеграции, резервные копии, обновления и контакты поддержки.
4. Аварийный слой. Что делать, если система недоступна, данные не пришли или сотрудник с важным доступом внезапно отсутствует.

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

Не передавайте пароли вместе со знаниями

Частая ошибка — прислать новому сотруднику чужой логин «на первое время». Это создаёт две проблемы. Непонятно, кто сделал действие, и невозможно безопасно закрыть доступ бывшему сотруднику.

У каждого человека должна быть отдельная учётная запись с правами по его задачам. Передача знания — это объяснение роли, а не передача чужой личности в системе. Как настроить такие роли, разобрано отдельно в статье «Как организовать права доступа в бизнес-системе?».

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

Передавайте не только порядок кликов, но и исключения

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

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

Проведите передачу по реальному рабочему дню

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

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

Затем полезно дать человеку сделать такой же сценарий самому, но с возможностью задать вопрос. И только после этого считать передачу завершённой. Показать — не значит научить.

Оставьте след после передачи

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

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

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

Запишите контакты и границы ответственности

У системы редко бывает один владелец во всех смыслах. Руководитель процесса отвечает за то, что работа идёт правильно. Администратор — за настройки и доступы. Подрядчик — за согласованный объём технической поддержки. Пользователь — за корректность своих данных.

Если эти роли не разделены, любой сбой превращается в поиск виноватого. Если разделены — вопрос быстрее попадает к тому, кто действительно может его решить. Для каждого контакта укажите не только имя и канал связи, но и повод обращения: «менеджер CRM — правило воронки», «подрядчик — ошибка интеграции», «руководитель отдела — спорное решение по заказу».

Не забывайте о резервном сценарии

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

Резервная копия здесь тоже часть процесса, а не техническая деталь. Она полезна только тогда, когда известно, кто может её восстановить и как проверить результат. О регулярности и проверке копий можно прочитать в материале «Как часто нужно делать резервные копии сайта и бизнес-системы?».

Короткий чек-лист передачи

• Есть одна понятная карта системы и её владельцы.
• У нового человека отдельная учётная запись с нужными правами.
• Описан один реальный рабочий сценарий, а не только меню системы.
• Зафиксированы исключения и порядок эскалации.
• Известны контакты бизнеса, администратора и поддержки.
• Проверено, кто отвечает за резервный сценарий и восстановление.
• Новый сотрудник самостоятельно выполнил ключевую операцию.

Начните с одной самой важной системы, а не со всего IT-ландшафта. Часто это CRM, учётная система, сервис заявок или склад. За один-два рабочих часа можно собрать достаточно материала, чтобы компания перестала зависеть от памяти одного человека.

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