Устаревшая система тормозит бизнес: 8 признаков, что пора модернизировать
Новые функции выходят месяцами, поддержка дорожает, а систему знают один-два человека? Разбираем 8 признаков устаревшей системы, цену бездействия и первый шаг к модернизации. В конце — чек-лист.
Руководитель отдела продаж просит добавить в личный кабинет клиента новый способ оплаты. Разработчики оценивают задачу и называют срок — три месяца. Изменение затронет расчеты с клиентами, обмен данными с бухгалтерией и отчеты. Модули тесно связаны между собой, а значит, придется все проверять вручную. Кроме того, счет за поддержку системы, который компания оплачивает каждый месяц, снова вырос.
Обычно в такой ситуации руководители винят ИТ: задача на первый взгляд простая, а сроки большие, да и обходится работа дорого. Но часто проблема в самой системе. Ее создавали под задачи, которые были у компании несколько лет назад, и теперь она не успевает за ростом бизнеса.
Вывод: модернизация информационных систем нужна не ИТ-отделу, а самому бизнесу: она помогает быстро запускать новые функции и держать расходы под контролем.
В статье разберем 8 признаков, по которым видно, что системе пора на модернизацию. В конце — чек-лист для самостоятельной оценки.
Содержание
- Почему система устаревает, даже если работает
- 8 признаков, что системе нужна модернизация
- Сколько стоит ничего не делать
- С чего начать: обследование информационной системы
- Чек-лист: готова ли ваша система к модернизации
- Модернизация информационной системы: в двух словах
- Часто задаваемые вопросы
Почему система устаревает, даже если работает
Главное возражение против модернизации звучит так: «Работает — не трогай». Система действительно может годами выполнять свои функции. Но устаревшая система — не то же самое, что сломанная.
Устаревание бывает двух видов:
- Техническое. Платформа, язык или СУБД больше не поддерживаются производителем, специалистов по стеку все меньше, обновления безопасности не выходят.
- Функциональное. Технически система исправна, но не умеет того, что нужно сейчас: интегрироваться с новыми сервисами, выдерживать возросшую нагрузку, быстро получать новые функции.
Механизм у обоих видов один — технический долг. Так называют накопленные компромиссы: решения «сделаем быстро, потом переделаем», обходные пути, устаревшие библиотеки, недописанную документацию. Каждое из них по отдельности безобидно. Вместе они работают как проценты по кредиту: чем дольше не гасить долг, тем больше времени и денег уходит на любое изменение.
Legacy-системы (унаследованное ПО, которое сложно менять) редко становятся проблемой в один день. Обычно это медленный процесс, который замечают по косвенным симптомам. Их и разберем дальше.
8 признаков, что системе нужна модернизация
Ниже — признаки устаревшей системы, которые чаще всего встречаются в компаниях. Ответьте на вопросы и отметьте, какие из них есть у вас.
1. Новые функции выходят месяцами
Бизнес придумывает улучшение, а до пользователей оно доходит через квартал. Бэклог растет быстрее, чем команда его разбирает. Конкуренты тем временем запускают похожие функции за пару недель.
Причина обычно в архитектуре. В монолите — системе, где все модули тесно связаны, — изменение в одном месте задевает все остальное (как в примере из начала статьи). Каждую доработку приходится долго согласовывать, разрабатывать с оглядкой и полностью перепроверять.
Чем грозит: потеря скорости вывода продукта на рынок (time-to-market), упущенная выручка, демотивация команды.
Как проверить: посчитайте средний срок от идеи до релиза за последние полгода. Сколько задач сдвигалось с формулировкой «в текущей архитектуре это сложно»?
Бизнес- и системный анализ, цифровизация бизнес-процессов
Ошибка в требованиях может стоить копейки на этапе анализа и обойтись в миллионы после запуска новых процессов.
КПР находит такие ошибки до того, как они попадают в код. Сводим противоречивые пожелания подразделений в единые требования, исследуем процессы и проектируем систему, понятную и бизнесу, и разработчикам.
2. Поддержка съедает бюджет развития
Деньги на систему выделяются, но почти все уходит на то, чтобы она просто продолжала работать: исправление ошибок, обновления, обходные решения. На новые функции почти ничего не остается.
С годами доля поддержки растет. Код становится запутаннее, специалистов по старому стеку нанимать дороже, а каждое исправление занимает больше времени.
Чем грозит: бюджет на ИТ растет, а бизнес не получает ничего нового. Развитие продукта фактически останавливается.
Как проверить: разделите затраты на систему за 2–3 последних года на «поддержку» и «развитие». Если доля поддержки растет из года в год, это тревожный сигнал.
3. Каждое изменение что-то ломает
После релиза внезапно перестает работать то, что никто не трогал. Команда боится выкатывать обновления, релизы проходят по ночам, а откаты стали обычным делом.
За этим обычно стоят скрытые зависимости между модулями и отсутствие автотестов. Система стала настолько сложной, что предсказать последствия изменения невозможно.
Чем грозит: простои, ошибки у клиентов, рост нагрузки на поддержку, еще большее замедление релизов.
Как проверить: сколько инцидентов случилось после релизов за последний квартал? Есть ли автоматические тесты, и какую часть системы они покрывают?
4. Систему знают один-два человека
Есть разработчик или подрядчик, без которого ничего нельзя изменить. Документации нет или она описывает систему пятилетней давности. Отпуск ключевого специалиста — повод отложить все доработки.
Чем грозит: если этот человек уйдет, компания рискует остаться с системой, которую никто не понимает. Это прямой операционный риск, который сложно застраховать.
Как проверить: сколько людей могут самостоятельно выпустить релиз? Когда последний раз обновлялась документация по архитектуре и интеграциям?
ИТ-аутсорсинг и выделенные команды специалистов
Проект готов к старту, а команда — еще нет? Для крупной финансовой группы мы собрали несколько кросс-функциональных команд: аналитиков, backend- и frontend-разработчиков, Android- и iOS-разработчиков, тестировщиков и дизайнеров.
Для иностранного банка подключили архитектора, который спроектировал новый кредитный продукт и процессы SWIFT-переводов.
Вы ставите задачи, мы приводим людей, которые знают ваши процессы.
5. Интеграции через выгрузки и «костыли»
Данные между системой и бухгалтерией, CRM, банком или маркетплейсом передаются файлами. Кто-то каждый день выгружает таблицу и загружает ее в другую программу. Подключение нового партнера превращается в отдельный проект.
Современные системы обмениваются данными через API — программные интерфейсы, которые позволяют передавать информацию автоматически и в реальном времени. Устаревшие часто их не поддерживают.
Чем грозит: ручной труд, ошибки в данных, медленная реакция на запросы клиентов и партнеров.
Как проверить: перечислите все обмены данными с другими системами. Сколько из них идет вручную или через файлы?
6. Система не выдерживает рост
В пиковые дни — распродажи, закрытие месяца, сезон — система тормозит или «падает». Добавление новых пользователей, филиалов или направлений требует покупки все более мощного оборудования, а эффект с каждым разом меньше.
Чем грозит: система становится потолком для роста бизнеса. Компания не может взять больше клиентов или сделок, потому что ИТ не справится.
Как проверить: как меняется время отклика системы в пиковые часы? Каков запас по нагрузке, если поток клиентов вырастет вдвое?
7. Стек без поддержки и с уязвимостями
Платформа, операционная система или СУБД больше не получают обновлений от производителя. Часть компонентов принадлежит зарубежным вендорам, которые ушли с российского рынка. Обновить их нельзя, а найти замену непросто.
Для российских компаний это не только вопрос безопасности. Организации, чьи системы относятся к значимым объектам критической информационной инфраструктуры (КИИ), обязаны переходить на российское ПО. Многим другим компаниям импортозамещение нужно, чтобы снизить санкционные риски и не зависеть от лицензий, которые нельзя продлить.
Чем грозит: утечки данных, атаки, штрафы регуляторов, внезапная остановка системы из-за отзыва лицензии.
Как проверить: когда заканчивается поддержка платформы и СУБД? Есть ли в используемых версиях известные уязвимости из базы CVE? Есть ли в системе компоненты ушедших вендоров? Подпадает ли компания под требования по КИИ?
Импортозамещение программного обеспечения и миграция данных
Аккредитивы с зарубежными расчетами, SWIFT-платежи, депозиты юрлиц, договоры РКО. Все это нужно перенести в новую АБС и не остановить работу банка ни на день.
Мы это уже делали: перевели российский филиал международного банка с Диасофт на ЦФТ, пока обе системы работали параллельно. Каждая запись выверена, требования Банка России соблюдены. За нашими плечами более 100 проектов.
8. Данные есть, а пользоваться ими нельзя
Система годами копит ценную информацию о клиентах, заказах и процессах. Но чтобы собрать управленческий отчет, аналитик тратит несколько дней: выгружает данные из разных мест и сводит их вручную. Цифры в отчетах не сходятся.
Чем грозит: решения принимаются на ощущениях, а не на данных. Компания не может внедрить аналитику, персонализацию и другие инструменты, которые уже используют конкуренты.
Как проверить: сколько времени уходит на подготовку ежемесячного отчета для руководства? Есть ли единый источник данных — например, хранилище с витринами данных, — которому доверяют все отделы?
Один-два признака — повод наблюдать и планировать.
Узнали три признака и больше? Специалисты КПР проверят систему и скажут, что модернизировать в первую очередь.
Сколько стоит ничего не делать
Отказ от модернизации кажется экономией: не нужно выделять бюджет и рисковать. Но у бездействия тоже есть цена, просто она распределяется по разным статьям расходов:
- Растущая стоимость поддержки. Каждый год сопровождение обходится дороже, а специалистов по редкому стеку все сложнее найти и удержать.
- Упущенная выручка. Функция, которая выходит на три месяца позже, чем у конкурентов, приносит меньше денег или не приносит их вовсе.
- Ручной труд. Сотрудники тратят часы на выгрузки, сверки и обходные решения вместо основной работы.
- Простои и инциденты. Каждый час недоступности системы — это остановленные продажи, недовольные клиенты и работа поддержки в авральном режиме.
- Риски безопасности. Устранение последствий утечки или атаки почти всегда дороже, чем своевременное обновление.
Чтобы оценить свою ситуацию, сложите эти составляющие хотя бы приблизительно. Для наглядности мы взяли вымышленные цифры — подставьте вместо них свои:
| Статья | За год, условно |
|---|---|
| Рост стоимости поддержки к прошлому году | 2 млн ₽ |
| Ручные операции: 3 сотрудника × 30 % времени | 1,8 млн ₽ |
| Простои в пиковые периоды | 1,5 млн ₽ |
| Задержка запуска новой функции на квартал | 3 млн ₽ |
| Итого стоимость бездействия | 8,3 млн ₽ |
Теперь сравните эту сумму с тем, во сколько обойдется модернизация. Такая оценка — хороший аргумент для разговора с собственником или финансовым директором.
С чего начать: обследование информационной системы
Первый шаг — это обследование. Оно помогает ответить на три вопроса: что именно мешает системе, сколько это стоит бизнесу и какой путь модернизации обойдется дешевле и безопаснее.
Как проходит обследование информационной системы в КПР:
- Интервью с пользователями. Разбираемся, какие задачи решает система, что мешает руководителям и пользователям, какие планы развития у компании.
- Анализ архитектуры и кода. Оцениваем структуру системы, качество кода, технический долг, покрытие тестами, актуальность документации.
- Оценка интеграций, данных и безопасности. Проверяем, как система обменивается данными, где хранятся и насколько доступны данные, есть ли уязвимости и зарубежные компоненты.
- Оценка стоимости владения. Считаем, сколько компания тратит на поддержку и сколько теряет из-за ограничений системы.
- Отчет и дорожная карта. Передаем карту рисков, рекомендованный подход к модернизации, план работ по этапам с оценкой сроков и бюджета.
На выходе вы получаете документ, с которым можно идти к руководству: что не так, сколько это стоит и что делать дальше.
Если обследование покажет, что старую систему выгоднее заменить, КПР спроектирует и разработает новую. Функции переносятся поэтапно, поэтому бизнес не останавливается ни на день.
Если модернизацию будет делать внешняя команда, пригодятся еще две статьи: как выбрать ИТ-подрядчика и запустить проект и что описать в техническом задании до старта разработки.
Разработка и сопровождение информационных систем и мобильных приложений
В одном из крупнейших банков страны предприниматели заказывают электронную подпись прямо в интернет-банке. Эту функцию разработала команда КПР.
Мы делаем системы под реальную нагрузку: сервис проверки контрагентов для того же банка, хранилище, которое ежедневно обрабатывает до миллиардов записей, мобильные продукты крупной финансовой группы.
От архитектуры до поддержки в промышленной эксплуатации.
Чек-лист: готова ли ваша система к модернизации
Чтобы оценить ситуацию самостоятельно, мы подготовили чек-лист из 12 вопросов. Его можно пройти за 10 минут, а затем обсудить результаты с командой или руководством.
12 вопросов в четырех блоках: скорость и развитие продукта, затраты и зависимость от людей, надежность и технологии, интеграции и данные. За каждый ответ — 0, 1 или 2 балла, в конце — расшифровка результата и три ответа, при которых обследование лучше не откладывать.
Модернизация информационной системы: в двух словах
- Старая система может мешать бизнесу, даже если она работает. Это заметно по тому, что новые функции выходят месяцами, поддержка с каждым годом дорожает, а в системе разбирается только один-два человека.
- Отказ от изменений часто обходится дороже модернизации. Компания каждый год переплачивает за поддержку, теряет выручку из-за медленных запусков и тратит время сотрудников на ручную работу.
- Начинать нужно с обследования системы. Чаще всего систему выгоднее обновлять по частям, не останавливая работу компании.
Часто задаваемые вопросы
Сколько стоит модернизация информационной системы?
Стоимость зависит от размера системы, состояния кода, числа интеграций и выбранного подхода. Поэтапная модернизация обычно обходится дешевле переписывания и позволяет распределить бюджет по этапам. Точную оценку можно дать только после обследования.
Сколько длится модернизация и остановится ли работа бизнеса?
От нескольких месяцев до года и больше — в зависимости от масштаба. При поэтапном подходе система продолжает работать: изменения выкатываются небольшими частями, а старая и новая версии модулей какое-то время работают параллельно.
Что лучше: модернизировать систему или переписать с нуля?
В большинстве случаев выгоднее модернизировать поэтапно, например выносить части монолита в отдельные микросервисы: это дешевле, быстрее дает результат и снижает риски. Переписывание оправдано, когда система не поддается изменениям, а бизнес-логика сильно изменилась. Какой вариант подходит именно вам, показывает обследование.