Почему регламенты, тикет-системы и даже ИИ не разгружают бэк-офис

В 2026 году операционная нагрузка не снижается, а растет. Геополитика и валютные качели заставляют компании пересматривать бюджеты чуть ли не в реальном времени, циклы планирования сжимаются, а бизнес при этом одновременно вкладывается в ИИ и цифровую трансформацию. Звучит противоречиво, но так и есть: старые процессы еще работают, новые только выстраиваются, а стыковка между ними требует постоянного ручного вмешательства – то есть административной нагрузки становится больше, а не меньше. На этом фоне советы директоров требуют оптимизировать бюджеты и повышать эффективность, но привычные способы сокращения затрат уже не работают.

Всю эту перегрузку принимают на себя поддерживающие функции – HR, финансы, закупки, юристы, АХО. Именно они разбирают растущий поток согласований, отвечают на запросы от бизнеса и держат на себе работу систем и процессов. Строго говоря, чем быстрее растет бизнес, тем сильнее страдает бэк-офис. А привычный рецепт «не хватает рук – наймем еще» перестал работать, потому что фонд оплаты труда растет быстрее, чем хотелось бы. При этом при правильной оптимизации бэк-офиса компания из 3 тыс. сотрудников может сэкономить до 78 млн. рублей в год.

В этой статье я разберу, сколько именно стоит такая перегрузка в деньгах и почему привычные способы ее снять не решают проблему до конца? Более детально эту тему мы разобрали в экспертном материале об операционной модели бэк-офиса. Полную его версию с кейсами компаний ГК Альфа-Лизинг, Systeme Electric, Монетка можно скачать на сайте SimpleOne.

Какие решения не повышают операционную эффективность бэк-офиса

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

1. Внедрение тикет-системы

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

Но довольно скоро система упирается в потолок собственных возможностей:

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

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

2. Прописывание регламентов

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

А через полгода-год ситуация обычно откатывается назад. Регламенты перестают соблюдать, потому что они требуют слишком много шагов, которые легко пропустить, когда все горит. Новые сотрудники просто не знают об инструкциях или не могут их найти. Любое изменение процесса – и документация устаревает, потому что актуализировать ее вручную никто не успевает.

Без технологической поддержки регламент – это просто файл. Человек физически не способен держать в голове 20 инструкций и следить за 50 дедлайнами одновременно. Первый форс-мажор или увольнение ключевого сотрудника, и все снова скатывается в хаос.

3. Масштабирование ERP-системы

ERP – мощный инструмент для учета и управления ресурсами, и у крупных вендоров – от SAP и Oracle до 1С – давно есть отдельные модули под HR-сервис, ITSM и обработку внутренних обращений. Формально ERP умеет обрабатывать запросы сотрудников, и на бумаге все логично: система уже куплена, внедрена, люди в ней и так работают – остается только включить сервисный модуль.

На практике обычно не внедряют ERP под сервис-деск, а в уже существующую 1С докидывают сверху модуль обработки заявок. И вот тут вылезают ограничения, которых на старте не видно. Каталог услуг и SLA-движок в сервисных модулях ERP на деле слабее, чем в описании: их приходится собирать вручную, а под сложные маршруты согласования нужна доработка каждого процесса. Интерфейс самообслуживания, особенно в 1С, заточен под ежедневного оператора учета, а не под сотрудника, который заходит раз в месяц подать заявку на справку – порог входа высокий, и люди снова уходят в почту и звонки. А сервисные процессы меняются постоянно: новая услуга, другой состав согласующих, лишний шаг проверки – и каждое такое изменение в модуле поверх ERP превращается в задачу для разработчика, потому что задевает учетный контур.

И это не бесплатно: базовое внедрение 1С для среднего бизнеса, по оценкам интеграторов, укладывается в 3-6 месяцев и 5-15 млн. рублей, но достройка полноценного сервисного контура с каталогом, SLA, интеграциями и удобным порталом превращается в отдельный подпроект, сопоставимый по масштабу с основным внедрением. В итоге заказчик получает не работающий сервис-деск, а еще одну зону доработок, которую нужно тащить наравне с учетным контуром.

4. Внедрение ИИ-агентов

ИИ-агенты – самая модная ставка последних лет: посадить агента на входящий поток, пусть сам разбирает обращения, отвечает на типовые вопросы, оформляет и закрывает заявки без участия человека. На бумаге это выглядит как финальная форма автоматизации – то, к чему остальные инструменты вроде как подводят.

Но ИИ не работает в вакууме. Агент хорош настолько, насколько хороши данные и процессы под ним. Если обращения приходят в свободной форме, каталога услуг нет, а данные разбросаны по нескольким системам и Excel – агенту банально не на чем учиться и не с чем работать. Он начинает путать маршруты, выдавать ответы, которые приходится перепроверять руками, и достраивать недостающий контекст догадками. Нагрузка не падает, появляется новый слой контроля, и теперь нужно следить еще и за самим ИИ.

Без стандартизированных и оцифрованных процессов ИИ, как и все остальное в этом списке, не убирает хаос, а просто оцифровывает его – быстрее и на новом уровне. Поэтому сначала нужно навести порядок в бэк-офисе: каталог услуг, структурированные формы, единые данные, SLA – и только потом посадить агента, который на этой основе закрывает запросы без человека.

5. Точечная автоматизация

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

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

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

Как посчитать операционные потери обслуживающей функции

Резюмируя сказанное выше, многие способы оптимизации нагрузки на самом деле не избавляют бизнес от лишних трат. Так сколько стоят операционные потери на самом деле? Возьмем компанию на 3 тыс. сотрудников и посчитаем ручной труд, который можно автоматизировать.

По рынку на одного сотрудника приходится в среднем 5-7 внутренних обращений в месяц – суммарно в ИТ, HR, бухгалтерию, АХО, к юристам, в закупки и клиентский сервис. Для компании в 3 тыс. человек это почти 200 тыс. обращений в год. Вот как выглядит типичное распределение нагрузки:

Среднее время ручной обработки (AHT, Average Handling Time) сильно отличается по подразделениям:

AHT – это не время жизни заявки целиком, а именно активный ручной труд сотрудника: разобраться в запросе, найти данные в нескольких системах, оформить документ, передать дальше. Это то время, которое оплачивается из ФОТ.

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

Средневзвешенное время ручной обработки одного обращения по компании – 39 минут. Именно эта цифра корректна для расчета ФОТ и оценки потенциала автоматизации, а не грубое усреднение по количеству подразделений.

Переводим в часы и деньги:

• 7 775 000 минут ÷ 60 ≈ 130 000 часов ручной работы в год.
• 130 000 часов × 600 ₽/час* ≈ 78 млн ₽/год.

*600 ₽/час – усредненная нагруженная ставка специалиста бэк-офиса (оклад + страховые взносы + накладные)

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

Почему придется менять операционную модель бэк-офиса

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

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

Поэтому линейное масштабирование бэк-офиса – наймом, новым софтом или подключением ИИ – не снижает цифру потерь на ручном труде, а в лучшем случае немного притормаживает их рост. При этом рынок не стоит на месте одинаково для всех. По данным нашего исследования, только 30,8% компаний способны увеличивать объем обрабатываемых обращений без пропорционального роста штата бэк-офиса. Логика, которая позволяет им расти без найма, устроена иначе – об этом поговорим в следующей статье.

Партнерский материал

Реклама. Рекламодатель ООО «Симпл 1» ИНН 9725013892 Erid 2SDnjczwxVR

Читайте также: