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

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

Для селлера на Wildberries, Ozon или Я.Маркете это не абстрактная тема. В сезон одновременно идут закупка, приёмка, обновление карточек, ответы на отзывы, работа с рекламой и разбор возвратов - десятки задач в день на нескольких людей. Если постановка и контроль держатся на памяти руководителя и переписке в чатах, любой рост ассортимента или штата обнажает узкое место: задачи теряются, сроки съезжают, и никто не может сказать, на каком шаге застряла конкретная задача.

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

Почему ручная постановка задач перестаёт работать при росте

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

Как только сотрудников и процессов становится больше пяти-семи, поле зрения перестаёт вмещать всё. Задача, поставленная голосом на планёрке или сообщением в личку, живёт ровно столько, сколько её помнят участники переписки. Она не привязана к процессу (например, к обработке возврата или обновлению карточки товара), поэтому при смене сотрудника или отпуске контекст теряется полностью.

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

Ошибка 1. Задачу ставят там, где переписка, а не там, где контроль

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

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

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

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

Ошибка 2. Автоматизируют задачу, а не процесс, в который она входит

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

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

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

Ошибка 3. Контроль подменяют регламентом или памяткой

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

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

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

Ошибка 4. Автоматизация считает статусы, но не считает стоимость шага

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

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

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

Ошибка 5. У задачи есть дедлайн, но нет однозначного ответственного

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

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

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

Как настроить постановку и контроль задач без этих ошибок

Собрать всё вместе можно в четырёх принципах.

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

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