Как владельцу бизнеса навести порядок в просроченных задачах
Просроченные задачи редко возникают из-за лени сотрудников. Владелец обычно видит лишь верхний слой проблемы: сроки сорваны, поручения висят, руководители отделов обещают закрыть хвосты к концу недели. Причина глубже. В компании нет единого определения задачи, нет понятного срока, нет владельца результата, нет ритма проверки. Пока я не навожу порядок в этих четырёх точках, список просрочки растёт даже при сильной команде.
Я начинаю не с поиска виноватых, а с правил. Задача в системе должна содержать действие, срок, ответственного и критерий завершения. Формулировка «разобраться с поставщиком» не годится. Формулировка «согласовать новый график поставок и получить подтверждение письмом до 16:00 среды» годится. Когда запись точная, спор о статусе исчезает. Когда запись размытая, сотрудник считает, что работа идёт, а руководитель видит просрочку.
Отдельная ошибка — хранить задачи в нескольких местах. Часть поручений живёт в мессенджере, часть в почте, часть в блокнотах, часть в памяти руководителя. При такой схеме контроль не работает. Я выбираю одну систему учёта и запрещаю ставить управленческие задачи вне неё. Обсуждение может идти где угодно, фиксация срока и ответственного — только в одном контуре.
Основа системы
Дальше я ввожу единый статусный ряд. Открыта, в работе, заблокирована, выполнена, просрочена. Больше статусов не нужно. Избыточная детализация создаёт иллюзию порядка, но размывает картину. Особенно полезен статус «заблокирована». Он отделяет реальную помеху от простого затягивания. Если сотрудник переводит задачу в этот статус, он указывает причину, дату блокировки и чьё решение нужно для продолжения. Тогда руководитель видит не жалобу, а предмет для действия.
После статусов я задаю правило срока. У каждой задачи есть конечная дата и, если работа длинная, контрольная точка внутри периода. Без промежуточной проверки длинные задачи почти всегда приезжают в просрочку в день финального срока. Контрольная точка нужна не для лишнего отчёта, а для раннего сигнала. Если на середине пути нет результата, к концу пути его тоже не будет.
Ещё один базовый элемент — один ответственный. Не отдел, не группа, не «совместно». Когда за задачу отвечают трое, по факту не отвечает никто. Соисполнители допустимы, но владелец срока и результата всегда один. Я фиксирую это жёстко, иначе система разваливается на первом же споре.
Правила эскалации
Контроль просрочки без последствий быстро превращается в декоративную отчётность. Поэтому я заранее описываю эскалацию — порядок передачи проблемы на следующий уровень управления. В первый день просрочки сотрудник пишет причину, новый срок и действие для закрытия. Если срок сорван повторно, подключается прямой руководитель. Если просрочка бьёт по клиенту, деньгам или производственному циклу, вопрос уходит выше в тот же день. Эскалация нужна не для наказания, а для ускорения решения там, где линейный уровень уже не справляется.
При этом я разделяю просрочку на три вида. Первый — дисциплинарная: задачу забыли, не спланировали, не уточнили. Второй — управленческая: у задачи не было приоритета, ресурсов, согласования. Третий — системная: сбой процесса, перегрузка участка, конфликт функций между отделами. Если смешивать эти причины, владелец бизнеса будет лечить людей там, где сломан процесс, или чинить процесс там, где вопрос в исполнительской дисциплине.
Я не принимаю формулировки вроде «не успели», «много задач», «ждали ответ». Причина просрочки должна быть разложена на факт. Нет решения директора. Нет данных от бухгалтерии. Подрядчик не прислал макет. Склад не отгрузил образец. Такая запись показывает, куда вмешиваться. Общие слова маскируют отсутствие управления.
Ритм контроля
Дальше я настраиваю ритм. Просроченные задачи нельзя разбирать раз в месяц. Нужен короткий цикл. Для операционных команд подходит ежедневный просмотр коротким составом: руководитель, ответственные по критичным задачам, иногда смежник, если есть зависимость. Для проектной работы достаточно двух-трёх раз в неделю. Смысл не в длительном совещании, а в принятии решений по списку просрочки.
На разборе я смотрю только на три вопроса. Почему срок сорван. Что мешает закрытию. Какая новая дата подтверждена. Если причина требует вмешательства, я назначаю конкретное решение: утвердить бюджет, снять конфликт приоритетов, дать ресурс, заменить исполнителя, остановить второстепенную работу. Разговоры про загруженность без решения я пресекаю. Иначе встреча превращается в обмен объяснениями.
Отчёт по просрочке я держу коротким. Название задачи, ответственный, дата срока, количество дней просрочки, причина, новая дата, статус решения. Этого достаточно, чтобы видеть реальную картину. Если полей десять и больше, команда начинает обслуживать таблицу вместо закрытия задач. Если полей слишком мало, владелец не понимает, где узкое место.
Хорошо работает возрастной анализ просрочки. Я делю задачи на группы: 1–3 дня, 4–7 дней, 8–14 дней, дальше — свыше двух недель. Такая группировка сразу показывает, где временный сбой, а где накоплен старый долг. Старую просрочку я разбираю отдельно. Она опаснее новой, потому что к ней привыкают и перестают воспринимать как риск.
Есть ещё одна ловушка — искусственное закрытие задач. Сотрудник ставит статус «выполнено», хотя результат не принят. Чтобы убрать этот приём, я отделяю завершение работы от приёмки результата. Если задача связана с клиентом, оплатой, документом или внедрением, закрытие происходит после подтверждения факта: письмо получено, акт подписан, изменение работает, файл сдан в нужном виде. Иначе просрочка исчезает только на экране.
Для собственника самый полезный показатель — не общее число задач, а доля просрочки среди активных и скорость её снятия. Если новых задач много, но просрочка держится под контролем и старые долги не копятся, система жива. Если доля просрочки растёт две-три недели подряд, причина почти всегда в приоритетах, перегрузе руководителей или слабой постановке задач.
Я не советую начинать с дорогой автоматизации. Сначала нужны правила, роли и дисциплина статусов. Потом уже выбор инструмента. Иначе компания переносит хаос в новую программу и получает тот же беспорядок в более красивом интерфейсе.
Когда система начинает работать, я вижу три изменения. Руководители перестают прятать отложенные вопросы в переписке. Сотрудники раньше поднимают блокировки. Собственник получает короткий, жёсткий список проблем, по которому можно принимать решения без догадок. Просроченные задачи не исчезают совсем. Но они перестают быть серой зоной, где теряются деньги, сроки и ответственность.
