Оптимизируем ИТ-бюджет без ущерба для стратегии роста

Ситуация

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

Что сделали

• Проведён аудит функциональности и финансовой эффективности
• Проанализирована совокупная стоимость владения (TCO) обеими системами, включая лицензии стороннего ПО, инфраструктуру и стоимость поддержки. Оценена степень покрытия бизнес-процессов каждой системой
• На основе метрик стабильности, масштабируемости и полноты функциональности выбрано целевое решение. Второе решение классифицировано как «дублирующее» и помечено к выводу из эксплуатации
• Разработан план консолидации данных и перевода пользователей на единую платформу

Результат

• Устранены двойные расходы на лицензии стороннего ПО, поддержку инфраструктуры и доработки. Экономия составила 24% от совокупных операционных затрат (OPEX) данного функционального направления (без учёта фонда оплаты труда)
• ИТ-бюджет консолидирован. Вместо двух хаотичных потоков финансирования выделен единый бюджет на развитие, что упростило финансовое планирование
• Консолидирована логика одинаковых бизнес-процессов. Устранены расхождения в расчётах, которые возникали из-за разной реализации алгоритмов в двух системах
• Ресурсы разработки сфокусированы на одном стеке. Новые функции теперь разрабатываются один раз и становятся доступны всему холдингу сразу, а не фрагментарно

Ситуация

ИТ-ландшафт холдинга со временем утратил единообразие. Помимо основных систем, в инфраструктуре одновременно сосуществовали пять различных систем управления базами данных, четыре системы обмена сообщениями и четыре инструмента мониторинга. Разные бизнес-направления использовали разные комбинации этих технологий для решения одних и тех же инфраструктурных задач. За каждым направлением были закреплены отдельные специалисты и выделена собственная инфраструктура. Как итог, компания оплачивала поддержку и лицензии для нескольких конкурирующих технологий (например, одновременно эксплуатировались RabbitMQ, Amazon SQS и ActiveMQ).

Что сделали

• Проведён аудит ИТ-ландшафта и анализ совокупной стоимости владения (TCO)
• Проанализированы затраты на поддержку и инфраструктуру по каждому бизнес-направлению. Полученные данные наглядно показали объём избыточных расходов, что позволило обосновать необходимость консолидации перед бизнесом
• Вся информация о текущем ландшафте была сведена в единый реестр. Разработана технологическая стратегия и утверждена целевая архитектура
• Утверждён целевой технологический стек и принципы единообразия. Это позволило удовлетворить текущие потребности бизнеса и предусмотреть применение при будущем развитии, используя только утверждённый набор технологий и исключая необоснованное внедрение новых инструментов

Результат

• Устранены избыточные расходы на поддержку дублирующих друг друга технологий. Экономия составила порядка 18% затрат на лицензии стороннего программного обеспечения и 35% расходов на облачную инфраструктуру
• Консолидация технологического стека позволила направить на 30% больше ресурсов (человеко-часов) на разработку новой функциональности без увеличения общего ИТ-бюджета
• Упрощение ландшафта снизило риски сбоев. Вместо четырёх разных систем мониторинга инженеры теперь смотрят в одно «окно», что сокращает время реакции на инциденты

Ситуация

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

Что сделали

• Проведён сравнительный анализ функциональности и оценка совокупной стоимости владения (TCO)
• Функциональность самописной системы была сопоставлена со штатными механизмами low-code платформы с учётом долгосрочного плана развития бизнеса
• Подтверждено, что встроенные инструменты low-code решения полностью покрывают текущие и прогнозируемые требования к отчётности
• Рассмотрены сценарии возможного несоответствия в будущем. Сформированы подходы на случай уникальных требований, которые платформа не сможет закрыть
• Выявлены существенные избыточные затраты на фонд оплаты труда команды поддержки и инфраструктуру для параллельного решения

Результат

• Перевод подготовки расчётов на штатную функциональность low-code платформы позволил полностью снять расходы на поддержку, доработку и инфраструктуру самописного генератора. Высвобожден ресурс целой команды разработки
• Исключён дублирующий контур отчётности. Архитектура стала прозрачнее, а количество поддерживаемых систем сократилось, что снизило риски сбоев и упростило сопровождение
• Консолидация на одной платформе устранила риск расхождений в данных, которые возникали из-за разной реализации алгоритмов в самописной системе и на платформе

Ситуация

Бюджет команды, поддерживающей проект, ежегодно увеличивался, при этом количество ошибок в продукте не сокращалось. Каждый новый выпуск приводил к новым сбоям и требовал привлечения дежурных специалистов для стабилизации системы. Анализ показал, что около 70% времени команды уходило на устранение последствий ошибок в устаревшем коде. Дефекты воспроизводились снова и снова из-за архитектурных ограничений и неоптимальных технических решений, принятых в прошлом. Расходы на поддержку и исправление стали непропорционально высокими.

Что сделали

• Проведён аудит распределения затрат (TCO) и анализ причин инцидентов. Аудит показал, что точечные исправления не дают эффекта, так как в большинстве случаев решаются следствия проблем, а не сами проблемы
• Обоснован отказ от рискованного переписывания с нуля. Спроектирован план постепенной замены компонентов: наиболее проблемные участки переписываются с учётом утверждённых подходов по разработке и архитектуре, а старый код постепенно изолируется. Работы выполняются силами внутренней команды под архитектурным надзором. Это позволяет сохранять знание бизнеса и планомерно снижать долю легаси-кода

Результат

• Снижение OPEX: затраты на сопровождение и исправление ошибок снижены на 37%. Высвобожденные средства направлены на оплату труда команды, занятой плановым рефакторингом
• Новая реализация проблемных участков устранила необходимость в постоянных исправлениях
• Высвобожденный ресурс команды направлен на реализацию новой функциональности в рамках текущего бюджета

Ситуация

В производственном контуре существовал разрыв между двумя ключевыми системами. Из-за отсутствия штатного интерфейса операторы выполняли ручной перенос документов: копирование данных и повторный ввод. С ростом объёмов производства потребность в ручном труде росла линейно: требовалось всё больше ставок операторов. Риски человеческого фактора (опечатки) приводили к финансовым потерям и рассинхронизации данных между системами. Ресурс сотрудников уходил на рутину.

Что сделали

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

Результат

• Снижены затраты на фонд оплаты труда (прямая экономия OPEX), оптимизировано количество операторов, ранее занятых ручным вводом
• Исключены финансовые убытки, вызванные ошибками ввода
• Время обработки документа сократилось с нескольких минут до секунд. Данные в обеих системах стали актуальными
• Исключён человеческий фактор. Устранены опечатки, потеря документов и рассинхронизация информации

Ситуация

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

Что сделали

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

Результат

• Общие затраты на инфраструктуру сокращены на 22% за счёт вывода вспомогательных систем из дорогостоящего отказоустойчивого контура
• Дорогая инфраструктура зарезервирована только для критичных систем, обеспечивающих непрерывность производства
• Второстепенные сервисы работают на площадке соразмерной конфигурации, что исключило переплату за неиспользуемые ресурсы
• Появилась возможность наращивать тестовые среды без закупки дорогостоящего оборудования высокого класса