Передача дел при увольнении сотрудника: типичные ошибки автоматизации

Передача дел при увольнении сотрудника - это момент, в котором сразу видно, работает ли автоматизация бизнес-процессов на самом деле или существует только на бумаге. У селлера маркетплейса цена ошибки выше, чем в обычном офисе: карточки товаров, рекламные кампании, переписка с покупателями и доступы к личным кабинетам WB, Ozon и Я.Маркета не терпят паузы даже в пару дней. Типичные ошибки автоматизации при передаче дел - это не поломки кода, а неправильные допущения: что задача сама найдёт нового исполнителя, что доступ отключится вовремя без участия человека, что новый сотрудник поймёт контекст по одному названию задачи в таск-трекере.

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

Что реально уходит вместе с сотрудником

Когда увольняется человек, который вёл карточки, рекламу или переписку с покупателями на маркетплейсе, уходит не только он сам, а три разных слоя: открытые задачи (недоделанные и будущие шаги), доступы (кабинеты, рекламные аккаунты, склад, 1С) и контекст - договорённости с поставщиками, причины конкретных настроек рекламы, история спорных возвратов.

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

Ошибка 1: увольнение зафиксировано, а процессы - нет

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

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

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

Хотите навести порядок в задачах и процессах команды? Посмотреть →

Ошибка 2: доступы отключают не в такт с передачей дел

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

Здесь особенно хорошо видно, почему написанная инструкция не спасает. Регламент "отключить доступы в течение суток после увольнения" можно не прочитать, забыть выполнить вовремя или выполнить формально - подписать бумагу, но не отозвать пароль от рекламного кабинета. Разница не в документе, а в том, физически ли шаг встроен в процесс: если отключение доступа - это отдельный шаг бизнес-процесса в системе, который не закрывается, пока ответственный за IT или админ не подтвердит выполнение, пропустить его нельзя в принципе.

Ошибка 3: один чек-лист на все роли

Третья ошибка - универсальный чек-лист офбординга ("сдать пропуск, вернуть технику, подписать обходной"), который не учитывает специфику ролей в команде маркетплейса. У разных сотрудников теряется принципиально разное:

• у менеджера маркетплейса - незакрытые обращения покупателей, неотвеченные отзывы с истекающим сроком, статусы претензий по возвратам;
• у байера (закупщика) - договорённости о ценах и отсрочках с поставщиками, которые нигде не зафиксированы, кроме личных переписок;
• у контент-менеджера - незавершённые карточки товаров, черновики инфографики, невыгруженные изменения на маркетплейсе;
• у менеджера по рекламе - логика распределения бюджета между кампаниями и причины, по которым ДРР по одним товарам держат выше среднего;
• у бухгалтера - статусы сверок с маркетплейсом и невыясненные расхождения по выплатам;
• у кладовщика - расхождения по остаткам, которые ещё не оформлены как акт, и незавершённая приёмка товара.

Один типовой чек-лист "сдай дела" эти детали не ловит, потому что написан для абстрактного офисного сотрудника, а не под конкретную роль в цепочке селлера.

Ошибка 4: никто не подтверждает, что дела приняты

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

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

Ошибка 5: контекст остаётся в голове, а не в системе

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

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

Как выстроить передачу дел, которая не держится на памяти

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

Работает обратный принцип: увольнение сотрудника запускает конкретный бизнес-процесс в системе, а не напоминание кому-то что-то сделать. У этого процесса заранее прописаны шаги под роль - какие задачи проверяются, какие доступы отключаются и в каком порядке, кто подтверждает приём дел - и каждый шаг физически нельзя закрыть, пока он не выполнен. Отключение доступа не отмечается "сделано", пока не подтверждено фактически. Задача не считается переданной, пока преемник не открыл её и не принял. Такой процесс не полагается на то, что кто-то вспомнит и не поленится - он не даёт пройти дальше, если шаг пропущен, и именно поэтому закрывает типичные ошибки автоматизации, а не переносит их в новый документ.