Почему нельзя останавливаться после запуска IT‑решения. Раскрываем ключевые риски.

Маркетологи и диджитал-директора привыкли считать, что техническая поддержка — это зона ответственности IT-отдела. Сервер упал — админы чинят. API отвалился — программисты правят. Но когда останавливается сбор данных для анализа рынка или перестаёт работать автоматическая обработка лидов, потери считает не IT-департамент. Их считает маркетинг. Падением конверсий, пропущенными тендерами и слепотой в конкурентной разведке. В этой статье я расскажу две реальные истории из практики — без имён, но с конкретными выводами.

Кейс №1. Парсер, который пропустил тендеры

Система для автоматического сбора данных по государственным закупкам. Задача типичная: роботы обходят отраслевые площадки, собирают информацию о тендерах, обрабатывают и складывают её в базу данных. Минимум ручного труда, максимум скорости реакции. Примерно год всё работало безупречно. Данные текли рекой,  тендерный отдел получал свежие аукционы каждый день.

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

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

Кейс №2. Нейросеть, которая встала

Второй проект — автоматизация обработки «грязных» данных. Нейросеть распознавала сущности в неструктурированном потоке информации в файлах doc и pdf и сама раскладывала всё по нужным полям и таблицам. Ручной труд сократился в разы, скорость обработки выросла на порядок. Больше про это рассказывал на выступлении в промышленной палате и в своем Телеграм канале.

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

Баланс таял. Мы это видели, предупреждали клиента, но быстрого решения на тот момент не существовало. В одно утро баланс обнулился — нейросеть отключилась. «Умная» обработка встала. Сотрудники снова сели вручную раскладывать данные.

Результат: скорость обработки упала примерно в 4–5 раз. А главное — был потерян накопленный слой кастомизации: промпты, шаблоны, правила обработки. Восстановление заняло время.

Почему это управленческая проблема, а не IT-шная

В обоих случаях код нашей командой Брейнфорс был написан хорошо. Архитектурных ошибок не было. Проблема пришла из внешней среды. Но удар пришёлся именно по маркетинговой и коммерческой функции:

1. Остановился сбор рыночных данных → потеря конкурентного преимущества.
2. Отключилась автоматизация → выросли затраты на ручной труд.
3. Пропали данные за период простоя → нарушилась аналитика, невозможно построить корректные отчёты.

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

Что на самом деле даёт поддержка: три уровня защиты

1. Мониторинг. Отслеживание балансов API, структуры сайтов-доноров, корректности поступающих данных. Алерты до того, как проблема стала заметна бизнесу.
2. Адаптация. Быстрое реагирование на изменения внешней среды: новые параметры площадок, обновление API, смена протоколов защиты.
3. План Б. Заранее проработанные альтернативные решения: резервные провайдеры ИИ, платёжные контуры, обходные маршруты сбора данных.

Чем заменить зарубежные решения: короткий обзор

В наших кейсах проблему решили так:

1. Парсер дописали под новые защитные параметры площадок. Данные восстановились.
2. Вместо зарубежной нейросети переехали на отечественные аналоги.

Что можно рассматривать как замену прямо сейчас, мы протестировали три варианта:

1. GigaChat (Сбер).  Подошел идеально для решения задачи: можно отправить файл и получить по нему ответ.
2. YandexGPT. В браузерной Алисе ПРО это сделать не удалось, поэтому вопросами API не занимались.
3. Open-source LLM (своё железо). Крайне невыгодно финансово.

Нам удалось повести миграцию с зарубежного ИИ на отечественный буквально за несколько часов. Мы адаптировали промпты и прописали новые параметры API и всё заработало. Но если бы задача была сложнее, то "легким испугом" мы бы не отделались.

Экономика поддержки: платить или терять

Главный страх заказчика: «Поддержка — это дополнительные расходы». Давайте посчитаем альтернативу.

Сценарий «Сделали и забыли»:

1. Стоимость поддержки: 0 руб./мес.
2. Один серьёзный инцидент в год: простой от 3 до 14 дней.
3. Потери: упущенные лиды, ручная обработка данных, срочный наём команды для ремонта.
4. Итоговая стоимость инцидента: от 200 000 до 1 500 000+ руб. (в зависимости от масштаба компании и системы).

Сценарий «Комплексная поддержка»:

1. Стоимость поддержки: 10 000–50 000 руб./мес. (зависит от сложности).
2. Количество инцидентов: 0 критических.
3. Потери: отсутствуют.
4. Бонус: система постоянно адаптируется, не устаревает.

Казалось бы, разница очевидна. Но вот пока не столкнешься с такими инцидентами, то платить не хочется. Не так ли?

Что в остатке?

Запуск IT-продукта — это не финал, а выход в открытое море. Внешняя среда изменится обязательно, вопрос только когда и как внезапно. Обязательно поменяются правила площадок, заблокируется платёжный шлюз, устареет API. Вопрос в том, сколько вы потеряете за время простоя и как быстро восстановитесь.

Профилактика всегда дешевле экстренного ремонта. А команда, которая знает ваш проект, всегда быстрее команды, которую вы наймёте в панике.

Инцидент прямо сейчас

Слышали ли вы, что теперь нельзя авторизоваться на русских сайтах с заграничных сервисов? За нарушение можно получить большой штраф. А вы готовы к таким изменениям?