Матрица приоритетов автоматизации: как считать эффект и сложность

Почему список «что автоматизировать» не работает

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

Вторая причина — громкость. Задача с последней планёрки обгоняет ту, что тихо съедает по 40 часов в месяц у трёх сотрудников. Опрос Deloitte (2018, 530 руководителей) показывает, чем это заканчивается: главный барьер масштабирования — фрагментация процессов (32%), нехватку ясного видения и готовности ИТ назвали по 17%. Компании не столько не могут автоматизировать, сколько не могут выбрать и удержать приоритет.

Эффект: сначала часы, потом деньги

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

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

Пример: 150 обращений в неделю по 5 минут — 12,5 часа в неделю, около 54 часов в месяц. При ставке 700 рублей в час это порядка 38 тысяч рублей. Если на контроль и разбор ошибок уходит 6 часов, реальный эффект — 48 часов. Такие числа сравнимы между отделами и не зависят от того, кто громче просил.

Полезно добавить пятый множитель — стоимость задержки: сколько теряется за каждую неделю, пока задача не сделана. У сверки счетов задержка стоит денег через пени, у внутреннего отчёта — только нервов. В Scaled Agile такой приоритет называют WSJF: стоимость задержки, делённая на длительность работы. Логика простая: две задачи с одинаковой экономией не равны, если одна блокирует оплату.

Похожую логику использует RICE из Intercom: балл = (охват × влияние × уверенность) / усилие, где влияние — по шкале 3 / 2 / 1 / 0,5 / 0,25, а уверенность — 100 / 80 / 50%. Для автоматизации охват и влияние удобнее заменить на часы экономии, а множитель уверенности оставить: оценка без данных заслуживает понижения.

Сложность: не «дорого», а четыре фактора

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

• Число систем: каждая новая система — отдельная интеграция, свои права доступа и свой формат данных. Три системы в процессе — это не «чуть сложнее», а три точки отказа.
• Качество данных: заполнены ли поля, есть ли единый ключ клиента, в каком виде приходят вложения. Процесс с грязными данными сначала чинят, потом автоматизируют.
• Доля исключений: 70–80% типовых случаев — рабочий ориентир для старта. Если нетиповых больше трети, задача превращается в долгую доработку правил.
• Сопровождение и обратимость: кто правит правила, когда меняется форма или тариф, и можно ли вернуть ручной режим за день. Автоматизация, которую нельзя выключить, — это риск, а не экономия.

Сроки систематически занижают, и это не свойство конкретной команды. Flyvbjerg и Budzier разобрали 1 471 IT-проект: средний перерасход бюджета — 27%, а каждый шестой вышел за бюджет на 200% и почти на 70% по срокам. Вывод для матрицы: в квадрант «просто» не ставят задачу, чья оценка не проверена разбором данных. Наш приём — умножать непроверенную оценку на 1,5 и смотреть, меняется ли приоритет.

Матрица: четыре квадранта и что в них делать

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

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

Пять ошибок, из-за которых матрицу считают заново

1. Эффект в процентах без базы. «Ускорим обработку на 30%» нельзя сравнить с «сэкономим 40 часов». Проценты появляются после того, как есть часы, а не вместо них.
2. Сложность по демо поставщика. На демо показывают только удачный сценарий; число систем и качество данных проверяют на ваших доступах.
3. Задачи разного масштаба в одном списке. Автоматизация одного письма и замена учётной системы не конкурируют: их разносят по разным очередям.
4. Эффект без сопровождения. Правила и интеграции требуют правок; если 10 часов в месяц уходит на поддержку, а экономия 15, честный эффект — 5.
5. Матрица без владельца и даты пересмотра. Приоритеты устаревают за квартал: меняются тарифы, формы, объёмы. Без даты пересмотра матрица живёт до первого конфликта.

Пример: шесть задач одного отдела

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

Самая крупная по эффекту задача — не первая: у ответов на вопросы клиентов 50 часов экономии, но 25 дней работы и нет регламента, сначала нужны правила. Отчёт руководителю даёт всего 12 часов, зато собирается за 6 дней и снимает рутину с дорогого человека. Как считать метрики после запуска — в статье про замер эффекта.

Очередь на квартал и правило пересмотра

Матрица даёт порядок, но работать начинает только очередь: три-четыре задачи, срок, владелец и условие, при котором задачу снимают. Фиксировать её стоит письменно — таблицей на общей странице.

• Срок: у каждой задачи есть дата, когда её либо запускают, либо снимают. Без даты очередь превращается в список пожеланий.
• Владелец: человек из бизнеса, а не из ИТ. Он отвечает за правила и за то, чтобы данные были приведены в порядок.
• Условие остановки: заранее описанный признак, при котором работу прекращают. Например, доля нетиповых случаев выше 40% или стоимость интеграции выросла вдвое.
• Дата пересмотра: раз в квартал, по факту замеров. Между пересмотрами очередь не двигают — иначе приоритет снова определяет тот, кто громче.

Пересмотр по факту важен не меньше самой матрицы. McKinsey в разборе о провале трансформаций (2019) приводит оценку: около 70% таких программ не достигают целей. Причины — завышенные ожидания, отсутствие общей картины и незакрытая «основная работа» у ключевых людей. Матрица делает ожидания проверяемыми, но не заменяет владельца и регулярный разбор.

Что показывает рынок и чего матрица не обещает

Опрос Deloitte стоит держать перед глазами: локальный успех достижим почти всегда, портфельный эффект — редкость.

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