Как передавать задачу между отделами, чтобы она не возвращалась с вопросом «что дальше?»

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

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

Почему задача возвращается назад

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

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

Сначала назовите результат каждого этапа

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

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

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

Передавайте контекст вместе с карточкой

Карточка задачи — не конверт, в который бросили одно слово. Следующему исполнителю часто важно знать не только «что сделать», но и почему именно так. Какие ограничения уже согласованы? Что обещали клиенту? Где лежит исходный документ? Есть ли риск, который нельзя проигнорировать?

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

Один шаг — один владелец решения

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

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

Не прячьте исключения в комментариях

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

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

Сделайте возврат информативным

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

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

Срок должен принадлежать следующему действию

В карточках часто есть одна общая дата, и она почти ничего не объясняет. Продажи считают, что задача передана вовремя. Склад видит, что получить её нужно уже сегодня. Бухгалтерия узнаёт о срочности только из звонка. Общий срок не заменяет срок конкретного шага.

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

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

Автоматизация не должна создавать ложную готовность

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

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

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

Договоритесь о языке, а не только о полях

Одинаковая карточка не гарантирует одинакового понимания. Для продаж «срочный заказ» может означать обещание клиенту, для склада — наличие товара, для производства — изменение очереди. Когда ключевые слова читают по-разному, отделы спорят не о работе, а о словаре.

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

Проверьте путь на одном живом сценарии

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

На каждом переходе проверьте пять вещей:

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

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

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

Частые вопросы

Нужно ли делать обязательными все поля?

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

Что важнее: автоматический переход или ручное подтверждение?

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

Как понять, что маршрут стал лучше?

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

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