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