Подпишитесь на наш блог
Подпишитесь на нашу электронную ежемесячную рассылку для получения полезных советов и ценных ресурсов
Апрель, 2025
Почему компании
не могут отказаться от устаревших
ИТ-решений
Почему 60% российских компаний держатся за старые программы и legacy-код 90-х и 2000-х? Разбираем причины, стоимость замены и способы обновить ИТ без остановки бизнеса.
В 2025 году до 60% российских компаний продолжают использовать программное обеспечение, разработанное в 90-х и начале 2000-х годов. Это касается как финансового сектора, так и логистики, телекомов и госсектора. Банки, страховые компании, логистические и государственные структуры — повсюду встречаются знакомые интерфейсы и архитектуры прошлых десятилетий. Почему так происходит, и какие реальные потери стоят за этой привычкой откладывать обновление?
Почему "legacy" остается в строю?
Во-первых, потому что это работает. «Если не сломалось — не трогай» — универсальный принцип, особенно для компаний, где простой системы может обойтись в миллиарды. Многие крупные компании в России десятилетиями опирались на собственные решения, написанные на Java, COBOL и Oracle Forms. Эти системы проверены и масштабированы. А значит — трогать их опасно.
COBOL до сих пор применяется в банковских системах по всему миру (и в России тоже) для обработки транзакций. По данным Reuters (2021), около 43% банковских систем глобально зависят от COBOL, и в России эта доля может быть даже выше.
Oracle Forms, популярная в 90-х и 2000-х, использовалась для создания интерфейсов в финансовом и транспортном секторах.
Oracle Forms, популярная в 90-х и 2000-х, использовалась для создания интерфейсов в финансовом и транспортном секторах.
Oracle forms interface
Во-вторых, цена вопроса. Замена ядра банковской платформы крупной финансосвой организации стоила бы более 100 млрд рублей. Даже частичная миграция на микросервисную архитектуру требует лет работы и инвестиций в десятки миллиардов. Бизнес считает: лучше платить за поддержание, чем за рискованный переход.
Замена ядра в западных банках, таких как ING или Deutsche Bank, оценивается в $1–2 млрд (80–160 млрд рублей по курсу 2024 года), с учетом меньшей сложности интеграции.
Замена ядра в западных банках, таких как ING или Deutsche Bank, оценивается в $1–2 млрд (80–160 млрд рублей по курсу 2024 года), с учетом меньшей сложности интеграции.
Третья причина — интеграция. Внутри одной компании может работать 300–500 систем, связанных между собой через старые API, очереди сообщений, FTP и даже email. Поменять одну — значит перелопатить десятки.
В некоторых компаниях до сих пор применяются системы, завязанные на обмен данных через FTP, что было нормой в 2000-х. Замена одной системы требует переработки десятков связанных компонентов, что подтверждается опытом других компаний. И это особенно актуально после 2022 года, когда уход западных вендоров (SAP, Oracle) усложнил обновление интеграционных слоев.
В некоторых компаниях до сих пор применяются системы, завязанные на обмен данных через FTP, что было нормой в 2000-х. Замена одной системы требует переработки десятков связанных компонентов, что подтверждается опытом других компаний. И это особенно актуально после 2022 года, когда уход западных вендоров (SAP, Oracle) усложнил обновление интеграционных слоев.
Наконец, люди. Во многих крупных компаниях работают разработчики, которые начали карьеру в 80-х. Уйдут они — и часть логики систем станет недоступной. Найти специалиста по Natural или PL/1 сегодня почти невозможно, а переобучить новых — нерентабельно.
Если эти разработчики уходят, документация часто устаревшая или отсутствует, что делает системы "черным ящиком". Переобучение новых специалистов на такие языки действительно нерентабельно — проще поддерживать старое, чем переписывать с нуля.
Если эти разработчики уходят, документация часто устаревшая или отсутствует, что делает системы "черным ящиком". Переобучение новых специалистов на такие языки действительно нерентабельно — проще поддерживать старое, чем переписывать с нуля.
Но в чём тогда проблема?
Проблема в том, что время не стоит на месте. Старые системы не поддерживают современные требования по безопасности. Многие из них не имеют шифрования «по умолчанию», не интегрируются с biometrics или real-time аналитикой, не масштабируются в облаках. Атака на Colonial Pipeline в США или утечка данных из Equifax — прямые последствия технического долга.
Он также мешает развитию. В отдельных случаях технические ограничения не позволяют внедрить полноценные системы персонализированного маркетинга. Попытки реализовать функциональность через обходные решения могут обходиться в сотни миллионов рублей. Основная проблема — невозможность централизовать данные о клиентах и построить сквозную аналитику.
Есть и операционные издержки. В крупных дистрибьюторских компаниях на поддержку собственных ERP-систем, созданных ещё в начале 2000-х годов, уходит до 70 млн рублей ежегодно. Переход на современные решения позволяет сократить эти расходы вдвое и ускорить управленческие процессы.
Он также мешает развитию. В отдельных случаях технические ограничения не позволяют внедрить полноценные системы персонализированного маркетинга. Попытки реализовать функциональность через обходные решения могут обходиться в сотни миллионов рублей. Основная проблема — невозможность централизовать данные о клиентах и построить сквозную аналитику.
Есть и операционные издержки. В крупных дистрибьюторских компаниях на поддержку собственных ERP-систем, созданных ещё в начале 2000-х годов, уходит до 70 млн рублей ежегодно. Переход на современные решения позволяет сократить эти расходы вдвое и ускорить управленческие процессы.
Сколько стоит избавиться от leagcy-кода?
- Модернизация банковского ядра — от 30 до 150 млрд рублей
- Переход на микросервисную архитектуру — от 5 до 25 млрд рублей
- Внедрение новой ERP в холдинге — 500 млн – 3 млрд рубле
Эти суммы кажутся огромными, пока не начинаешь считать потери: простои, утечки данных, отказ клиентов из-за низкой скорости обработки запросов. Например, по данным Accenture, каждый рубль, вложенный в модернизацию, экономит до 3–5 рублей в будущем.
Как уменьшить стоимость?
Полная замена инфраструктуры требует значительных ресурсов, но большинство компаний выбирают постепенную модернизацию. Один из подходов — приоритизировать критические узлы: системы, связанные с клиентскими данными, платёжными транзакциями и аналитикой. Для них создаются изолированные микросервисы или API-обёртки, которые работают параллельно с устаревшими модулями. Это позволяет снижать технический долг поэтапно, не останавливая бизнес-процессы. Такой подход также упрощает бюджетирование: расходы распределяются на 2–4 года и согласуются с инвестиционным циклом компании.
Как действуют ведущие компании
Некоторые идут по пути постепенной замены. Вместо одного большого проекта — десятки малых, сфокусированных на отдельных бизнес-юнитах. Они называют это "платформенный подход". Другие — строят собственную облачную инфраструктуру, переписывая модули на Go и Kotlin. Третьи — выбирают путь API-обёрток, сохраняя старую систему, но делая её доступной для новых решений.
Некоторые идут по пути постепенной замены. Вместо одного большого проекта — десятки малых, сфокусированных на отдельных бизнес-юнитах. Они называют это "платформенный подход". Другие — строят собственную облачную инфраструктуру, переписывая модули на Go и Kotlin. Третьи — выбирают путь API-обёрток, сохраняя старую систему, но делая её доступной для новых решений.
Legacy — это как старые инженерные сети под городом. Пока всё работает — никто не думает о рисках. Но когда что-то ломается, цена вопроса становится неприемлемой. Бизнес может экономить на модернизации сегодня, но завтра это обойдётся дороже. Не все системы нужно сразу выбрасывать. Но стратегический план обновления критичен. Иначе завтра работать станет не на чём.