Технологии

Сколько стоит отложенная модернизация веб-системы и почему «подождём ещё год» обходится дороже

Разберём, из чего складывается цена годовой отсрочки модернизации веб-системы, как её оценить и в каких случаях перенос действительно оправдан.
Веб-система с множеством пристроек и временных решений
Модернизацию редко откладывают навсегда. Чаще решение выглядит рационально: текущий бюджет уже распределён, система пока выполняет свои задачи, поэтому крупные изменения переносят на один бюджетный цикл.
Но этот год не проходит бесплатно. Деньги всё равно уходят на точечные доработки, обновление отдельных компонентов и устранение накопленных проблем. В итоге компания уже тратится на модернизацию, но эти расходы не решают системные проблемы и не снижают стоимость дальнейшей поддержки.
Поддержка и развитие сайтов и веб-систем — это не только изменения интерфейса, но и доработки личных кабинетов, расчётных модулей, баз данных, внутренних сервисов и интеграций. От их работы напрямую зависят расчёты, обмен данными, работа сотрудников и другие бизнес-процессы, поэтому проблемы в таких системах со временем начинают влиять не только на IT, но и на работу компании в целом.

Почему ещё один год работы текущей системы может обойтись дороже

Цена отсрочки складывается не только из бюджета IT. Часть расходов видна в поддержке и разработке, часть переходит в рабочее время других подразделений, а часть проявляется в задачах, которые бизнес не может запустить вовремя.

Технический долг увеличивает стоимость поддержки

Расходы на поддержку начинают расти, когда в системе накапливаются временные решения, усложняются зависимости, а документация уже не полностью отражает реальное устройство проекта.
Один из факторов такого роста затрат — технический долг. Он возникает в том числе из вполне рациональных решений: например, когда ради сроков функцию запускают в упрощённом варианте и планируют вернуться к ней позже. Если таких решений становится много, они постепенно усложняют следующие изменения.
По оценкам отраслевых исследований, технический долг может составлять порядка 20–40% IT-расходов организации. Эта цифра показывает масштаб ресурсов, которые могут уходить на работу с уже накопленными ограничениями.
По исследованию Apple Hills Digital, Cloud.ru, Selectel и VK Tech, проведённому среди 419 компаний и дополненному 27 глубинными интервью с IT-руководителями, 78% компаний продолжают эксплуатировать legacy-системы. У 14% таких организаций они составляют более половины IT-портфеля.

Одна доработка запускает цепочку изменений

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

Ручная работа переносит расходы в другие подразделения

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

Как СберИнфра автоматизировала работу с финансовыми моделями

Вместо ручного заполнения и пересчёта моделей в Excel — специализированный веб-сервис для работы с расчётами

Читать кейс

Смена прежнего подрядчика требует дополнительных затрат

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

Как сменить подрядчика и не остановить веб-систему

Что проверить при передаче работающей системы новой команде и почему одного кода и документации для этого недостаточно.

Читать статью

Система начинает ограничивать рост бизнеса

Старая архитектура может влиять уже не на стоимость отдельной задачи, а на планы бизнеса. Новый сервис требует предварительной переработки нескольких компонентов, автоматизацию приходится откладывать, а нужную функцию — упрощать, чтобы она вписалась в существующие ограничения.
Ещё один сценарий — рост нагрузки. Система может нормально работать при текущем числе пользователей и объёме данных, но при росте бизнеса перестаёт масштабироваться предсказуемо. Тогда проблема уже не в возрасте технологий, а в том, что архитектура начинает ограничивать развитие.

Интеграции, миграция данных и импортозамещение

Доработанные системы сложнее интегрировать

Типовая интеграция с существующими системами обычно проще, если для них уже предусмотрен штатный механизм обмена. Например, для интернет-магазинов на «1С-Битрикс: Управление сайтом» и ряда торговых конфигураций «1С:Предприятия» есть готовые механизмы двустороннего обмена данными.
Но за годы эксплуатации коробочное решение часто заметно меняется. В нём появляются собственные поля, статусы и бизнес-правила, которых стандартный коннектор не учитывает. Тогда готовый обмен приходится адаптировать под реальные процессы компании.
С заказной системой ситуация зависит от API. Если он документирован и покрывает нужные данные и операции, подключение нового сервиса остаётся прогнозируемой задачей. Если нет, сначала приходится разбираться, как получить нужные данные, а затем может потребоваться отдельная доработка API. Поэтому интеграция с внешними системами со временем может дорожать даже без изменения самого внешнего сервиса.

Миграция данных требует отдельной подготовки

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

Импортозамещение затрагивает не только выбор нового ПО

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

Сколько стоит решение «вернёмся к модернизации через год»

Из чего складывается стоимость отсрочки

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

Как посчитать на практике

Предположим, дополнительные работы по поддержке обходятся в 120 тыс. рублей в месяц — это 1,44 млн рублей в год. Ручные операции стоят ещё 70 тыс. рублей в месяц, или 840 тыс. рублей в год. Ещё 600 тыс. рублей потребовали новые интеграции и 400 тыс. — незапланированные работы.
Цена отсрочки в таком условном примере — 3,28 млн рублей за год. В расчёт не входит стоимость самой будущей модернизации и проектов, которые бизнес не смог запустить.
Это не отраслевой норматив, а пример того, как можно оценить стоимость переноса в конкретной компании.

Когда модернизация не является срочной задачей

Когда модернизация системы не нужна

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

Когда модернизацию можно отложить

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

Как модернизировать систему без полной замены и остановки работы

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

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

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

Расставить приоритеты

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

Менять поэтапно и проверять результат

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

Оцените, во что обходится текущая система

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



Согласен