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

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

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

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

Почему передача дел на маркетплейсе рвётся чаще, чем в обычном бизнесе

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

Вторая причина - пароли и доступы живут в личных менеджерах паролей и телефонах, а не в общем хранилище компании. Личный кабинет WB, рекламный кабинет, сервис аналитики, доступ к таблицам поставщиков - всё это может уйти вместе с сотрудником физически, если никто заранее не свёл это в одно место.

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

Что нужно передать, а не просто рассказать за час до ухода

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

• доступы к личным кабинетам WB, Ozon, Я.Маркет и к рекламным кабинетам внутри них
• пароли от сервисов аналитики, репрайсеров и сервисов управления ставками
• шаблоны карточек товаров, инфографики и тон общения с покупателями
• контакты поставщиков и байеров, текущие договорённости по закупкам и ценам
• список открытых задач с их реальным статусом, а не тем, что «почти готово»
• история переписки с клиентами, поставщиками и маркетплейсом по спорным ситуациям

Если хотя бы один из этих пунктов передаётся «на словах», он теряется - новый человек либо тратит время на восстановление контекста, либо действует вслепую.

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

Почему регламент передачи дел не спасает

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

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

Как выглядит процесс передачи дел в системе без программиста

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

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

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

Что делать, если увольнение внезапное или конфликтное

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

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

Что реально стоит сорванная передача дел

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

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

Чек-лист: кто и что передаёт при увольнении на маркетплейсе

Передача дел удобнее всего собирается по ролям - у каждой свой обязательный набор:

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

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