После запуска система перестаёт быть проектом и становится хозяйством. Меняется характер работы: вместо этапов и приёмки появляются регулярные обязанности — кто-то смотрит на оповещения, кто-то отвечает пользователям, кто-то вносит в базу знаний новый прайс, кто-то раз в квартал решает, что дорабатывать. Если эти обязанности не распределены поимённо, они не исчезают: они просто копятся, пока кто-нибудь не обнаружит, что система полгода отвечает по правилам, отменённым в марте.
Первый год при этом не однородный. В нём четыре разные задачи с разными исполнителями и разной ценой: на первом месяце вы добиваете дефекты и приучаете людей, к третьему — отвечаете на первую волну «а можно ещё», к шестому — ловите тихое расхождение системы с изменившимся бизнесом, к двенадцатому — считаете пользу и решаете, развивать, переписывать или выключать. Ни одна из этих четырёх задач не решается фразой «мы купили поддержку».
Ниже — разбор года по этим четырём точкам: что происходит в каждой, кто именно действует, сколько часов и денег это стоит и по каким числам понять, что система здорова. Все расчёты — модельные, на одном сквозном примере, который вы сможете пересчитать на своих цифрах.
Модельная система, на которой всё считается
Чтобы разговор не расползся, зафиксируем пример и будем держаться его до конца статьи. Оптовая компания, 60 человек. Внедрение обошлось в 1 200 000 ₽ и включает четыре связанных куска: ассистент в клиентском мессенджере, который отвечает на типовые вопросы по наличию, срокам и документам; классификатор входящих обращений; автозаполнение карточек в CRM; обмен с 1С:УТ по остаткам и статусам заказов. Поток — 3 000 обращений в месяц.
Важнее суммы другое число: у этой системы четыре внешние зависимости — Bot API мессенджера, CRM, 1С:УТ и провайдер языковой модели. Каждая из них меняется по своему календарю, а не по вашему. Именно количество зависимостей, а не цена внедрения, определяет, сколько работы будет в год. Мы разбирали эту логику подробно в материале о цене сопровождения; здесь она нужна как вводная.
Период жизни системы от подписания акта до вывода из работы. В отличие от внедрения, у эксплуатации нет даты окончания и нет технического задания — есть регламент, роли и бюджет на год. Всё, что происходит в этот период, делится на четыре контура: мониторинг, поддержка пользователей, обновление знаний и правил, развитие.
Горизонтальная лента времени на 12 месяцев с четырьмя выделенными узлами. Узел «месяц 1 — стабилизация»: подпись «34 обращения, 9 дефектов». Узел «месяц 3 — первая волна доработок»: подпись «22 заявки на изменения, принято 9». Узел «месяц 6 — дрейф знаний»: подпись «эскалации 12 % → 21 %». Узел «месяц 12 — ревизия»: подпись «решение: развивать, переписывать или выключить». Под лентой — тонкая полоса «переменные расходы 7 600 ₽/мес», идущая ровно через весь год. Чертёжный стиль, подписи по-русски.
Месяц первый: стабилизация, а не поддержка
Первый месяц устроен не так, как все последующие, и путать его с поддержкой — типичная ошибка бюджета. В это время система догоняет реальность: всплывают случаи, которых не было ни в тестах, ни в приёмке, потому что живой поток всегда богаче выборки. В модельном примере за первый месяц пришло 34 обращения от сотрудников, из них 9 оказались дефектами внедрения, 14 — вопросами «как это делается», 11 — просьбами поменять формулировку или порядок полей.
Дефекты внедрения на этом этапе исправляются бесплатно: это гарантия на работу подрядчика, а не платные часы. Проверять это надо не по обещаниям, а по формулировке в договоре — что считается дефектом и на какой срок распространяется гарантия. Разбор границы между дефектом и новым требованием у нас вынесен в отдельный материал о приёмке работ, и его стоит прочитать до подписания акта, а не после.
| Что происходит в первый месяц | Норма | Тревожный признак |
|---|---|---|
| Поток обращений от сотрудников | 25–40 за месяц при 60 пользователях, спад вдвое к четвёртой неделе | Ноль обращений: люди не пользуются системой, а обходят её |
| Доля дефектов внедрения в потоке | 20–35 % обращений первой недели, к четвёртой — почти ноль | Доля не падает: значит, чинят симптомы, а не причины |
| Доля обращений «как это делается» | до 40 %, снимается инструкцией и одним получасовым разбором | Растёт ко второму месяцу: инструкции нет или ею никто не пользуется |
| Просьбы изменить поведение системы | 10–15 за месяц, собираются в список и не делаются сразу | Делаются немедленно и по одной: система расползается без плана |
Просьбы «поменяйте формулировку», «добавьте поле», «пусть спрашивает иначе» приходят валом и выглядят мелочью. Если делать их с колёс, через месяц никто не сможет объяснить, почему система ведёт себя именно так, а регламент разойдётся с реальным поведением. Рабочий порядок другой: дефекты — сразу и бесплатно, изменения — в список, разбор списка раз в две недели с владельцем процесса. Из 11 просьб первого месяца в модельном примере в работу ушли 4, остальные отпали сами, когда люди привыкли.
Месяц третий: первая волна доработок
К концу второго месяца люди перестают бояться системы и начинают её использовать всерьёз. Отсюда вторая волна: не «почините», а «а можно ещё». В модельном примере к третьему месяцу накопилось 22 заявки на изменения: новый статус сделки, отдельный сценарий для дилеров, выгрузка в другой формат, ещё один шаблон ответа. Это здоровый признак, но именно на нём проекты начинают течь по деньгам.
Правило простое: изменения делаются не по мере поступления, а раз в две недели пакетом, после того как их отсортировал владелец процесса. Сортировка — по одному вопросу: сколько раз в месяц случается ситуация, ради которой просят изменение. Всё, что случается реже двух раз в месяц, откладывается на квартальный пересмотр. В модельном примере из 22 заявок в работу пошли 9, из них 6 уложились во включённые часы, 3 потребовали отдельной оценки на 24 часа работ.
Эти 111 800 ₽ — не перерасход и не ошибка подрядчика. Это нормальная стоимость того, что систему начали использовать. Ошибка возникает раньше: когда бюджет проекта заканчивается на дате запуска и первая же волна изменений выглядит как внезапный счёт. Правильно закладывать её на этапе сметы — как отдельную строку «изменения первого квартала», а не выпрашивать потом.
Столбчатая диаграмма за 12 месяцев, ось X — месяцы, ось Y — число обращений в поддержку. Значения по месяцам: 34, 14, 19, 6, 7, 5, 15, 8, 6, 7, 11, 6. Столбец седьмого месяца выделен и подписан «типовой релиз 1С», столбец одиннадцатого подписан «сезон, поток вырос втрое». Пунктиром — линия среднего уровня 6–8 обращений. Оси подписаны по-русски.
Месяц шестой: система расходится с реальностью
Самая дорогая часть года не сопровождается ни авариями, ни жалобами. К шестому месяцу в компании успевает поменяться то, о чём системе никто не сказал: прайс, срок поставки, регламент возврата, состав ассортимента, ответственный за направление. Система продолжает уверенно отвечать по старым данным. В модельном примере это видно по одному числу: доля обращений, которые ассистент передаёт человеку, выросла с 12 % в третьем месяце до 21 % в шестом. Никто не жаловался — просто люди стали чаще дописывать «переключите на менеджера».
Дрейф лечится не техникой, а регламентом: любое изменение в бизнесе, которое видит клиент, обязано иметь маршрут до базы знаний системы. Прайс поменяли — кто и в какой срок правит источник, из которого ассистент берёт цены. Склад переехал — кто меняет сроки доставки. У этой темы своя механика и свои цифры, мы разобрали её отдельно в материале о деградации системы за полгода; здесь достаточно понимать, что шестой месяц — это точка, где расхождение уже накопилось, но ещё дёшево стоит.
Возьмите три факта, которые изменились у вас за последние полгода: цену любой позиции, срок доставки в один регион и условие возврата. Задайте эти три вопроса своей системе так, как их задал бы клиент. Если хотя бы один ответ старый — вы уже в дрейфе, и вопрос только в том, сколько месяцев он длится и сколько клиентов услышали неправду.
Месяц двенадцатый: ревизия и решение на следующий год
К концу года у вас впервые есть данные, чтобы говорить не о планах, а о факте. Ревизия занимает одну встречу на полтора часа и требует трёх документов: журнала обращений за год, отчёта по метрикам здоровья и списка изменений с их стоимостью. На выходе — одно из четырёх решений: оставить как есть, развивать, переписывать модуль, выключить.
- 1Считаем фактическую пользу. Не по ощущениям и не по презентации подрядчика, а по цифрам из самой системы: сколько обращений закрыто без человека, сколько времени высвободилось, сколько ошибок ввода исчезло. Методика ретроспективного замера отличается от предварительного расчёта окупаемости, потому что данные «после» уже лежат внутри системы.
- 2Считаем фактическую стоимость года. Абонплата, часы сверх лимита, переменные расходы на модель и хостинг, время своих людей. Последняя строка обычно оказывается открытием: её никто не учитывал.
- 3Смотрим, что из запланированного не сделано и почему. Если в списке отложенных изменений три раза подряд лежит одно и то же — это не низкий приоритет, это признак, что модуль сопротивляется правкам.
- 4Сверяем систему с текущим процессом. Процесс за год изменился; вопрос, насколько сильно и решает ли система сегодняшнюю задачу или вчерашнюю.
- 5Принимаем решение и закладываем бюджет на следующий год — уже не по норме, а по факту прошедших двенадцати месяцев.
Самый неудобный из возможных исходов — четвёртый. Если за год системой пользуются трое из двенадцати, а обходят её девять, честнее выключить и разобраться в причинах, чем ещё год оплачивать сопровождение того, что не работает. Разбор таких случаев у нас вынесен в материал про зомби-систему, и он же содержит критерии, по которым систему признают мёртвой.
Схема из четырёх концентрических или параллельных контуров вокруг блока «система». Контур «мониторинг» — подпись «непрерывно, получатель — дежурный инженер». Контур «поддержка пользователей» — «по обращению, до 4 рабочих часов, администратор системы». Контур «знания и правила» — «по событию в бизнесе плюс ежемесячная сверка, владелец процесса». Контур «развитие» — «раз в квартал пакетом, подрядчик по оценке». Между контурами — стрелки, показывающие, что сигнал из мониторинга может уйти в любой из трёх остальных. Чертёжный стиль, все подписи по-русски.
Четыре контура эксплуатации и кто в них работает
Разговор «кто отвечает за систему» бесполезен, пока он ведётся про систему целиком. Ответственность распадается на четыре контура, и в каждом свой хозяин. Ниже — распределение, которое работает в компании 20–300 человек: три роли, из них две обязательно внутренние. Подрядчик не может закрыть контуры знаний и приоритетов, потому что не знает, что у вас изменилось.
| Контур | Что в нём делают | Кто ведёт | Частота |
|---|---|---|---|
| Мониторинг | Проверки живости, ошибки обмена, длина очереди, расход на модель, оповещения и разбор ложных срабатываний | Подрядчик, получатель оповещений — администратор системы | Непрерывно, разбор алертов 2 часа в месяц |
| Поддержка пользователей | Вопросы сотрудников, мелкие правки формулировок и справочников, разбор спорных случаев | Администратор системы внутри компании, вторая линия — подрядчик | По обращению, реакция до 4 рабочих часов |
| Знания и правила | Прайс, сроки, регламенты, новые позиции, стоп-темы, сценарии ответа | Владелец процесса, руками — администратор системы | По событию в бизнесе плюс сверка раз в месяц |
| Развитие | Новые сценарии, интеграции, отчёты, изменения логики | Владелец процесса ставит приоритет, делает подрядчик | Раз в квартал пакетом, с оценкой |
Ключевая фигура здесь — администратор системы на стороне компании. Это не программист: это человек, который умеет открыть панель, поправить справочник, добавить статью в базу знаний, посмотреть журнал и внятно описать проблему. Обычно им становится сильный сотрудник того отдела, где система работает, с выделенными на это 8–10 часами в месяц. Без такого человека любая поддержка вырождается в реакцию на жалобы: подрядчик физически не знает, что у вас поменялся прайс.
У системы не бывает одного ответственного. У неё бывает четыре контура — и в трёх из них хозяин обязан сидеть внутри компании.
Восемь метрик здоровья и их нормальные значения
Отчёт «всё работает» ничего не значит. Здоровье системы описывается восемью числами, и половина из них — не технические. Технику видит подрядчик, бизнес-часть видите только вы. Нормы ниже — ориентиры для контура вроде модельного: ассистент плюс классификация плюс обмен с учётной системой. Свои пороги имеет смысл зафиксировать в первый месяц, когда система уже стабильна, и дальше сравнивать с ними.
| Метрика | Норма | Повод разбираться |
|---|---|---|
| Доступность за месяц | не ниже 99,5 %, это до 3,6 часа простоя | ниже 99 %, то есть свыше 7,2 часа |
| Доля ошибок обмена за сутки | менее 1 % операций | свыше 2 % два дня подряд |
| Возраст старейшей неразобранной задачи | менее 4 рабочих часов | свыше 8 рабочих часов |
| Доля обращений, переданных человеку | 10–20 % при стабильной базе знаний | рост на треть за месяц |
| Доля ответов «не знаю» | 3–8 % | свыше 12 % |
| Время ответа, 95-й перцентиль | менее 8 секунд | свыше 15 секунд |
| Себестоимость одного обращения | 2,5 ₽ ± 20 % в модельном примере | свыше 150 % от среднего за 14 дней |
| Повторные обращения по тому же вопросу за 7 дней | менее 15 % | свыше 25 % |
Четвёртая, пятая и восьмая строки — это и есть ранняя диагностика дрейфа. Они начинают ползти за 4–8 недель до того, как кто-нибудь пожалуется, и именно поэтому их надо смотреть ежемесячно, а не по случаю. Какие из этих чисел выводить в оповещения, с какими порогами и кому они должны приходить — отдельная инженерная задача, разобранная в материале о мониторинге автоматизации.
Нарисованный абстрактный лист ежемесячного отчёта, разбитый на четыре подписанные зоны. Зона 1 «метрики здоровья»: восемь строк с нормой и фактом, две строки выделены как вышедшие за порог. Зона 2 «обращения»: число обращений за месяц и разбивка по уровням, подпись «34 → 6». Зона 3 «часы»: израсходовано из включённых, сверх лимита, остаток пакета. Зона 4 «расходы»: запросы к модели 3 600 ₽, хостинг 4 000 ₽, сравнение с прошлым месяцем. Чертёжный стиль без реального интерфейса, подписи по-русски.
Сколько это стоит: разбор годового бюджета
Норма, которую вы услышите чаще всего, — 10–20 % стоимости внедрения в год. Для модельной системы за 1 200 000 ₽ это 120 000–240 000 ₽ в год, то есть 10 000–20 000 ₽ в месяц. Полезно понимать, из чего эта доля должна складываться и в каком случае она вообще сходится.
Разрыв между нормой и фактом объясняется одной строкой — базовой ставкой за готовность. Нижний рыночный тариф сопровождения одной системы начинается примерно с 25 000 ₽ в месяц, то есть с 300 000 ₽ в год, и он почти не зависит от того, сколько стоило внедрение: инженер всё равно держит время в календаре и настраивает мониторинг. Разделите: чтобы 300 000 ₽ уложились в верхнюю границу нормы в 20 %, внедрение должно стоить от 1 500 000 ₽; чтобы уложились в нижнюю границу в 10 % — от 3 000 000 ₽. На проекте за 600 000 ₽ норма даёт 5 000–10 000 ₽ в месяц, за которые на рынке не продаётся ничего, кроме почтового адреса подрядчика.
Отсюда практический вывод для планирования. Для контура ценой до 1 500 000 ₽ закладывайте 25–55 % от стоимости внедрения в год, для проектов от 3 000 000 ₽ — 12–20 %: чем крупнее внедрение, тем лучше амортизируется постоянная часть. И отдельно держите в бюджете две строки, которых обычно нет вовсе: время своих людей и переменные расходы на модель, минуты и хранение. В модельном примере это 159 600 ₽ и 91 200 ₽ соответственно — вместе почти 39 % годового бюджета эксплуатации.
Горизонтальная столбчатая диаграмма с пятью статьями годового бюджета в рублях: «сопровождение у подрядчика 300 000», «развитие сверх лимита 96 000», «переменные расходы 91 200», «свой администратор 91 200», «обновление знаний 68 400». Итог 646 800 ₽ подписан отдельно. Две последние статьи и «переменные расходы» выделены штриховкой с пометкой «обычно нет в смете проекта». Рядом тонкая шкала с отметкой «норма 10–20 % = 120 000–240 000 ₽» для сравнения. Подписи по-русски.
Если сопровождения нет вообще: минимум за один день
Ситуация «подрядчик сделал и ушёл, договора поддержки нет» встречается чаще, чем кажется. Она не смертельна, но требует одного рабочего дня и примерно 30 000 ₽, чтобы система не превратилась в чёрный ящик, который никто не может ни починить, ни передать. Порядок действий такой.
- 1Проверить восстановление, а не наличие копий
Сам факт, что «бэкапы настроены», ничего не значит. Разверните копию на отдельном сервере и убедитесь, что система на ней поднимается и видит данные. Полдня работы. Копия, которую ни разу не восстанавливали, статистически с высокой вероятностью нерабочая, и узнаёте вы об этом в худший день.
- 2Забрать доступы на себя
Домен, хостинг, репозиторий, ключи к API смежных систем, аккаунт провайдера модели, платёжный метод. Всё это должно быть оформлено на компанию, а не на почту разработчика. Отдельно выпишите даты истечения ключей и сертификатов в общий календарь — просроченный токен выглядит как внезапная авария без причины.
- 3Собрать документацию на две страницы
Не проектную документацию, а рабочую: схема связей систем, где что лежит, как перезапустить, где смотреть журнал, к кому идти по каждой внешней зависимости. Если такой бумаги нет, её пишет тот, кто ещё помнит систему, — сейчас, а не через год.
- 4Назначить живого получателя оповещений
Даже самый простой мониторинг бесполезен, если письма падают в общий ящик. Нужен один человек с именем и телефоном, которому приходит сигнал, и одна короткая инструкция на пять строк: что сделать первым делом, кому звонить, если не помогло.
- 5Завести журнал изменений
Одна таблица: дата, что поменяли, кто, зачем. Без неё через полгода никто не сможет ответить, почему система ведёт себя так, и любая диагностика начинается с археологии. Ведение занимает минуту на изменение.
Эти пять пунктов не заменяют сопровождение — они делают его возможным. Пока их нет, ни один подрядчик не сможет взять систему на поддержку по вменяемой цене: сначала придётся оплатить аудит и восстановление картины. Мы такие аудиты делаем, но честно предупреждаем: разобраться в чужой системе без документации стоит от 60 000 ₽ и занимает 3–5 рабочих дней.
Чек-лист передачи системы в эксплуатацию: 12 пунктов
Приёмка отвечает на вопрос «сделано ли то, что заказывали». Передача в эксплуатацию отвечает на другой: «сможем ли мы этим жить». Это разные списки, и второй обычно забывают. Ниже — 12 пунктов, которые имеет смысл закрыть до того, как проектная команда разойдётся.
- 1Назначен администратор системы внутри компании, у него выделено 8–10 часов в месяц и есть все нужные права.
- 2Назначен владелец процесса, который принимает решения об изменениях и отвечает за актуальность правил.
- 3Все доступы оформлены на компанию: домен, хостинг, репозиторий, ключи к API, аккаунт провайдера модели.
- 4Составлен список внешних зависимостей с датами истечения ключей и сертификатов, даты занесены в общий календарь.
- 5Резервное копирование настроено, и восстановление хотя бы один раз проверено на практике с фиксацией времени.
- 6Мониторинг включён, пороги заданы, у каждого оповещения есть живой получатель по имени.
- 7Есть рабочая инструкция на 2–3 страницы: схема связей, перезапуск, где журналы, к кому идти по каждой зависимости.
- 8Есть регламент обновления знаний: какое событие в бизнесе кто и в какой срок доносит до системы.
- 9Заведён журнал изменений, и в нём есть первая запись — состав системы на дату запуска.
- 10Зафиксированы базовые значения восьми метрик здоровья на стабильном месяце — с ними сравнивают дальше.
- 11В договоре сопровождения описаны уровни инцидентов, время реакции, объём включённых часов и форма ежемесячного отчёта.
- 12Описана точка выхода: срок уведомления о расторжении и состав пакета, который передаётся другому подрядчику.
Двенадцатый пункт кажется недоверием к подрядчику, но именно он определяет, будет ли у вас через два года выбор. Систему, для которой описана точка выхода, можно передать за неделю; систему без неё передают месяцами и с потерями. Наши обязательства по передаче исходников, документации и доступов вынесены на страницу гарантий отдельным разделом — это проверяемая часть договора, а не декларация.
Схема «пакет передачи в эксплуатацию»: раскрытая коробка-контейнер, внутри двенадцать подписанных ярлыков — «администратор системы», «владелец процесса», «доступы на компанию», «список зависимостей с датами ключей», «проверенное восстановление», «мониторинг с получателем», «инструкция на 2–3 страницы», «регламент обновления знаний», «журнал изменений», «базовые значения метрик», «SLA и отчётность», «точка выхода». Сбоку — штамп «до роспуска проектной команды». Чертёжный стиль, подписи по-русски.
Когда сопровождение покупать не надо
Договор поддержки нужен не всякой системе, и продавать его в этих случаях — недобросовестно. Есть три ситуации, в которых честный ответ — «не покупайте».
- Система изолирована и стабильна. Ни одной внешней зависимости, правила не менялись два года, сутки простоя ничего не стоят. Здесь достаточно гарантии на дефекты и почасовой ставки по запросу: 25 000 ₽ в месяц вы будете платить за спокойствие, а не за работу.
- Внутри есть загруженный инженер. Если в штате человек, который читает журналы и код, а систем у вас четыре, свой специалист обходится дешевле и быстрее реагирует. При одной системе он загружен на треть и стоит дороже подрядчика — арифметику этой развилки мы приводили в материале о цене поддержки.
- Система решает вчерашнюю задачу. Если процесс изменился настолько, что система больше не в него, сопровождение консервирует проблему за ваши деньги. Дешевле признать это на годовой ревизии и переписать нужный модуль, чем ещё двенадцать месяцев оплачивать поддержку того, что не нужно.
И отдельно про режим 24/7: это самая дорогая строка в любом договоре, и она нужна только под процессы, простой которых действительно стоит денег ночью. Оптовик, который отгружает с девяти до восемнадцати, платит за круглосуточное дежурство впустую. Проверка простая: посчитайте, во что вам обходится час молчащей системы в три часа ночи. Если получается ноль, покупайте рабочие часы.
Таблица-сравнение на две колонки: «с сопровождением» и «без сопровождения». Шесть строк: «обновление внешнего API — заметили за сутки / заметили через 3 недели по жалобе клиента», «изменился прайс — правка за 20 минут / система отвечает старую цену месяцами», «доля переданных человеку обращений — 10–20 % / рост до 30 % и выше», «истёк ключ — предупреждение за 14 дней / внезапная остановка», «стоимость года — 646 800 ₽ / 0 ₽ плюс цена инцидентов», «передача системы другому подрядчику — неделя / месяцы и потери». Чертёжный стиль, подписи по-русски.
Система после запуска не стоит на месте: она либо обслуживается, либо расходится с бизнесом. Расхождение не выглядит поломкой и потому не вызывает тревоги — ровно до момента, когда клиент получает неверный срок, а менеджер узнаёт об этом от клиента. Стоимость такой тишины считается не в часах простоя, а в месяцах, в течение которых никто не смотрел на четыре числа из восьми.
Практический минимум на год выглядит так: назначенный администратор с 8–10 часами в месяц, владелец процесса с правом решать, четыре контура с прописанной ответственностью, восемь метрик в ежемесячном отчёте, квартальный пересмотр изменений и годовая ревизия с честным решением. Бюджет — 25–55 % от стоимости внедрения для небольших контуров и 12–20 % для крупных, с обязательными строками на своё время и переменные расходы.
Система не ломается в тот день, когда о ней забыли. Она ломается в тот день, когда о ней вспомнили — и обнаружили, что она полгода отвечала за март.
