Почему без поддержки автоматизация умирает за год

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

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

Ниже — разбор первого года жизни системы по событиям, из чего реально складывается счёт за сопровождение, что должно быть написано в договоре и в каких случаях поддержку честнее не покупать вовсе.

Первый год системы: события, которых нет в вашем плане

Соберите список того, от чего зависит ваша система: телефония, CRM, 1С, банковский клиент, API маркетплейса, провайдер языковой модели, шлюз SMS. Обычно получается от пяти до девяти пунктов. Теперь примите, что каждый из них меняется в среднем 2–4 раза в год — не по вашей воле и не по вашему графику. Это и есть график работ по поддержке.

К этому добавляется рост нагрузки. Система, спроектированная под 3 000 обращений в месяц, в сезон получает 9 000 — и упирается не в логику, а в лимиты: очередь на распознавание растёт, ответы приходят через сорок секунд вместо двух, часть запросов отваливается по таймауту. Формально ничего не сломано, просто вводные изменились втрое. Кто-то должен это увидеть до клиентов и расширить пропускную способность.

Из чего складывается цена поддержки

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

• Готовность. Инженер, который знает вашу систему, держит на неё время в календаре и обязан ответить за оговорённый срок. Это оплата доступности, а не отработанных часов, и она есть даже в спокойный месяц.
• Мониторинг. Автоматические проверки живости интеграций, длины очередей, доли ошибок, времени ответа и расхода токенов. Плюс живой человек, который смотрит на алерты и отличает всплеск от тренда.
• Регресс после чужих обновлений. Маркетплейс выкатил версию, телефония обновилась, 1С получила типовой релиз — надо прогнать сценарии и убедиться, что связка цела. Эта работа делается до аварии и потому со стороны невидима.
• Исправление дефектов. Ошибки, допущенные при внедрении, устраняются бесплатно в течение гарантийного срока. Строка в цене всё равно есть: подрядчик резервирует под них время.
• Качество модели. Разбор выборки диалогов, документов или ответов, правка промптов и базы знаний, обновление примеров. Без этого система деградирует ровно с той скоростью, с какой меняется ваш бизнес.
• Изменения по вашей инициативе. Новый прайс, новый сценарий, новое поле в CRM, новый отчёт. Обычно продаются пакетом включённых часов.
• Инфраструктура и безопасность. Обновления зависимостей, ротация ключей и сертификатов, резервные копии, проверка восстановления. Скучная строка, которая один раз в жизни окупает весь договор.

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

Почему 15–20% от стоимости проекта в год — формула из другой эпохи

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

Возьмём два проекта по 800 000 ₽. Первый — поиск по внутреннему архиву договоров: одна модель, одно хранилище, никаких внешних API, регламент меняется раз в год. Второй — голосовой робот, который живёт на телефонии, CRM, расписании, языковой модели и SMS-шлюзе: пять зависимостей, каждая меняется 2–4 раза в год. По формуле оба получают 800 000 × 20% ÷ 12 = 13 300 ₽/мес. Для первого это разумно и, возможно, много. Для второго это около трёх часов работы инженера в месяц — не хватит даже настроить и просмотреть мониторинг, не говоря о регрессе после пяти чужих обновлений. Одинаковая цена внедрения ничего не говорит о стоимости жизни системы.

Поддержка ИИ-системы — это не страховка от поломки. Это оплата того, чтобы система оставалась согласованной с миром, который меняется быстрее, чем ваш код.

Рабочая база для расчёта другая: число внешних зависимостей, объём потока, требуемое время реакции и цена часа простоя. Практический ориентир, которым пользуемся мы: базовая ставка за готовность и мониторинг плюс примерно 3–5 часов инженера в месяц на каждую внешнюю систему в связке плюс пакет часов на изменения, соразмерный тому, как часто у вас меняются правила. Дальше цифра проверяется на цене простоя: если час молчащей линии стоит вам 40 000 ₽ выручки, круглосуточное дежурство за 30 000 ₽/мес окупается одним инцидентом в год.

Что должно быть в договоре поддержки

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

1. 1Определение дефекта. Что именно считается ошибкой подрядчика и исправляется бесплатно, а что — новым требованием. Гарантия на собственный код бюро — 12 месяцев, и это должно быть написано словами, а не подразумеваться.
2. 2Включённые часы. Сколько их в месяц, переносятся ли неиспользованные на следующий период, по какой ставке идут часы сверх лимита. Без ставки сверх лимита любая срочная задача превращается в переговоры.
3. 3Регресс после обновлений внешних систем — за чей счёт. Обновление 1С или телефонии инициировали не вы и не подрядчик, но работа возникает у кого-то. Обычно она входит в абонентскую плату в оговорённом объёме часов, а крупная миграция оценивается отдельно.
4. 4Отчётность. Раз в месяц: список обращений с уровнями, факт по времени реакции, израсходованные часы, остаток пакета, расход на токены и минуты, список внесённых изменений. Без этого документа проверить, что вы покупаете, нельзя.
5. 5Порог изменения переменных расходов. При каком росте расхода на модель или телефонию подрядчик обязан прийти к вам с объяснением, а не молча перевыставить счёт вдвое больше.
6. 6Доступ к исходникам и документации. Код, схемы интеграций, промпты и инструкции лежат в вашем репозитории и остаются у вас при любом развитии событий.
7. 7Точка выхода. Расторжение с уведомлением за 30 дней и передача другому подрядчику: актуальная документация, разбор архитектуры, доступы. Договор без этого пункта — не поддержка, а привязка.
8. 8Ответственный с вашей стороны. Поддержка не работает в одну калитку: кто-то в компании обязан сообщать о смене прайса до того, как её увидят клиенты, и принимать изменения. Если такого человека нет, любой договор вырождается в реакцию на жалобы.

Признаки поддержки, за которую платят зря

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

Сколько это стоит и когда дешевле держать своими силами

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

Дальше арифметика. Инженер такого уровня обходится в 250 000–400 000 ₽/мес полного ФОТ. Одна система редко загружает его больше чем на треть, то есть стоит вам 85 000–130 000 ₽/мес — дороже подрядчика за 60 000 ₽. При четырёх системах загрузка становится полной, и свой инженер выигрывает с запасом. Отдельно держите в уме, что он уходит в отпуск, болеет и может уволиться в понедельник, унеся с собой всё знание о системе: у подрядчика с этим риском борется договор, у вас — только вторая голова в штате. Чаще всего дешевле гибрид: первая линия своя (мониторинг, перезапуск, правка прайса и базы знаний), вторая — подрядчик по SLA на инциденты и изменения кода. Такой формат обычно сокращает пакет включённых часов вдвое.

И честная оговорка: поддержка нужна не всякой системе. Если внутренний инструмент не ходит ни в один внешний API, регламент не менялся два года, а простой на сутки ничего не стоит — платить 40 000 ₽/мес не за что, достаточно гарантии на дефекты и почасовой ставки по запросу. Не покупайте режим 24/7 под процесс, который ночью никого не касается: это самая дорогая строка в договоре. А иногда правильный ответ — не поддерживать, а выключить: если бизнес-процесс изменился настолько, что система решает вчерашнюю задачу, дешевле признать это и переписать, чем ещё год платить за консервацию.

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