Наблюдения
по результатам наших аудитов

Ситуация

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

Что сделали

• Проведён аудит функциональности и финансовой эффективности
• Проанализирована совокупная стоимость владения (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% за счёт вывода вспомогательных систем из дорогостоящего отказоустойчивого контура
• Дорогая инфраструктура зарезервирована только для критичных систем, обеспечивающих непрерывность производства
• Второстепенные сервисы работают на площадке соразмерной конфигурации, что исключило переплату за неиспользуемые ресурсы
• Появилась возможность наращивать тестовые среды без закупки дорогостоящего оборудования высокого класса

Ситуация

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

Что сделали

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

Результат

• Стоимость хранения журналов снижена в 3 раза за счёт переноса исторических данных из дорогого хранилища в дешёвое
• Остановлен неконтролируемый рост объёма данных на дорогой инфраструктуре
• Цикл разбора инцидентов не изменился. Актуальные журналы доступны на быстрых дисках в пределах операционного окна
• Исторические данные сохранены в архивном хранилище и доступны по запросу

Ситуация

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

Что сделали

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

Результат

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

Ситуация

История операций за 20 лет хранилась в рабочей базе данных вместе с оперативными данными. База данных росла, под неё наращивались серверные мощности и диски, резервное копирование перестало укладываться в ночное технологическое окно. В ходе аудита дополнительно выявили, что персональные данные, подпадающие под ФЗ-152, хранились бессрочно, что создавало риск штрафа по ст. 13.11 КоАП.

Что сделали

В оперативной БД внедрено партиционирование таблиц по временным периодам. Это позволяет отключать старые партиции от регулярных запросов и выполнять их массовое удаление из «горячего» хранилища. Выгруженные данные переносятся в холодное архивное хранилище, доступ к которому осуществляется по запросу. Для соблюдения ФЗ-152 настроены политики хранения: записи с персональными данными автоматически выгружаются в архив и удаляются из оперативной БД по достижении установленных законом сроков.

Результат

• Объём оперативной базы данных сокращён на 65% благодаря архивации исторических данных
• Исключён риск штрафов по ч. 6 ст. 13.11 КоАП: сроки хранения персональных данных по ФЗ-152 соблюдаются автоматически, факты удаления фиксируются в системных логах

Ситуация

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

Что сделали

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

Результат

• Снижен отток клиентов – время оформления сокращено до минимума
• Текущие мощности обслуживают в 2 раза больше заказов без дополнительных инвестиций в инфраструктуру
• Сбои во внешних сервисах больше не блокируют оформление, обработка автоматически повторяется, сохраняя стабильность системы

Ситуация

Около сорока систем обменивались данными напрямую через синхронные запросы (точка-точка). Любое изменение в одном компоненте создавало риск каскадных отказов у соседних, а сетевая задержка в одном из компонентов приводила к остановке работы всей цепочки. Каждая новая интеграция требовала написания уникального связующего кода, связанность росла, а поддержка превращалась в постоянный рефакторинг, что замедляло развитие.

Что сделали

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

Результат

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

Ситуация

Производственная система на Delphi использовалась для управления цехом, но стала бутылочным горлышком. Любое изменение в коде несло риск остановки конвейера, так как система напрямую управляла контроллерами через специфические библиотеки. Специалистов на рынке мало, их поддержка обходилась в 1,5–2 раза дороже рыночной нормы, а устаревший стек не позволял интегрировать современное оборудование. Стоимость простоя производства исчислялась миллионами в час, поэтому фактически любые доработки в системе были заморожены.

Что сделали

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

Результат

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

Ситуация

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

Что сделали

• По результатам аудита спроектирована и внедрена распределённая схема с осознанным принятием рисков
• Второй ЦОД в другом регионе введён в эксплуатацию с постоянной асинхронной репликацией базы данных. Это сохранило высокую скорость записи данных, но потребовало зафиксировать окно возможной потери данных (RPO) в несколько секунд
• Для исключения эффекта Split Brain внедрён кворум-механизм в независимом сетевом сегменте, который автоматически определяет главную площадку (master)
• Спроектирован и автоматизирован регламент переключения
• Проведены учения в технологическое окно с полной имитацией отказа: команда физически выключила основной ЦОД, замерив фактическое время восстановления

Результат

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

Ситуация

Платформа стабильно работает на текущей базе клиентов, однако заявленный бизнес-план предполагает кратное увеличение клиентской базы. Технический аудит выявил критическую архитектурную недостаточность: используется монолитная база данных с общей схемой, не предусматривающая изоляции данных клиентов. Нагрузка от операционных транзакций (OLTP) и аналитических запросов (OLAP) конкурирует за одни и те же физические ресурсы. При достижении определённых порогов объёмов данных деградация производительности становится нелинейной. Текущая архитектура не способна обеспечить заявленный рост без полной переработки слоя хранения, что требует остановки разработки новых функций на длительный срок.

Что сделали

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

Результат

• Выявленные архитектурные ограничения классифицированы как критический технический долг. Объём необходимых капитальных вложений (бюджет на инфраструктуру и фонд оплаты труда команды на период доработок) учтён в качестве дисконта к итоговой стоимости сделки
• Покупатель получил объективные данные вместо прогнозов продавца. В структуру сделки включён механизм Earn-out: часть выплаты привязана к успешному завершению этапа изоляции данных, что защищает покупателя от приобретения нефункционального актива
• Срок технической готовности платформы к масштабированию (6–9 месяцев) теперь учитывается отдельно от юридических сроков закрытия сделки
• Сформирован реалистичный график расходов на ближайшие 12 месяцев. Покупатель понимает, что в первый год владения активом маржинальность снизится из-за необходимости финансирования экстренной модернизации, не заложенной в исходный бизнес-план продавца

Ситуация

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

Что сделали

• Проведён аудит цепочки прав путём сопоставления юридических документов с фактической историей разработки
• История изменений кодовой базы сопоставлена со списком подрядчиков и периодами действия договоров. Спорные участки кода выделены с точностью до модулей и авторов
• По каждому спорному участку определено текущее состояние прав на основании текстов договоров и актов (согласно ст. 1296 ГК РФ)
• Сформирован перечень компонентов, по которым отсутствует документальное подтверждение перехода прав
• Разработан план урегулирования: для каждого такого компонента определён алгоритм действий – от подписания дополнительных соглашений о ретроспективном отчуждении прав до получения нотариально заверенных заявлений от бывших сотрудников и фрилансеров

Результат

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

Ситуация

Кодовая база продукта содержала компоненты с открытым исходным кодом. В ходе аудита выявлены зависимости, распространяемые на условиях «вирусных» лицензий, в частности GNU GPL/AGPL. Данные лицензии юридически обязывают владельца продукта раскрыть исходный код всего продукта при его распространении. Для коммерческой SaaS-модели или поставки on-premise это означало бы полную потерю исключительных прав на проприетарную часть продукта и передачу конкурентам всей интеллектуальной собственности.

Что сделали

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

Результат

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

Ситуация

В ходе операционной деятельности продукта накоплен массив персональных данных клиентов (миллионы записей). На момент проверки выявлены критические нарушения Федерального закона № 152-ФЗ: нарушение принципа целеполагания – сроки хранения данных не установлены и не привязаны к целям обработки (ч. 7 ст. 5 152-ФЗ); в тестовых средах использовались полные копии продуктивных баз данных, что создавало риск утечки и нарушало требование локализации (ч. 5 ст. 18 152-ФЗ); учёт обращений субъектов к своим данным и логирование доступа не велись, что делает невозможной защиту при проверках Роскомнадзора. Ответственность по ст. 13.11 КоАП РФ за данные нарушения (штрафы до 3% от выручки или до 18 млн рублей) переходит к покупателю в полном объёме вместе с активом.

Что сделали

• Проведён комплексный аудит управления жизненным циклом персональных данных
• Проведён анализ процессов сбора и хранения, определены точные категории данных, их местонахождение (включая тестовые среды) и объём в количественном выражении
• Рассчитана потенциальная сумма штрафов по ст. 13.11 КоАП с учётом масштаба системы
• Разработан план устранения: установлены юридически обоснованные сроки хранения для каждой категории данных; сформулированы требования к очистке тестовых сред и внедрению деперсонализации данных; разработана архитектура внедрения журналов обращений и системы управления согласиями

Результат

• Выявленный регуляторный риск отражён в соглашении о купле-продаже в виде обязательств продавца по устранению нарушений до закрытия сделки
• Покупатель получил количественную оценку объёма данных, подлежащих очистке, что позволило точно рассчитать бюджет на приведение системы в соответствие
• Запущены работы по плану приведения процессов обработки персональных данных в соответствие с 152-ФЗ с оценкой трудоёмкости в человеко-часах
• Устранение использования полных копий в тестовых средах исключает риск катастрофической утечки и блокировки ресурса Роскомнадзором
• Внедрение журналов обращений и сроков хранения переводит компанию из зоны «неконтролируемого риска» в зону прозрачного комплаенса, готовую к плановым и внеплановым проверкам регулятора

Ситуация

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

Что сделали

• Проведён аудит архитектуры, программного кода и процессов разработки
• С помощью специализированных инструментов проведён анализ модулей с высокой частотой изменений
• Рассчитан объём работ по рефакторингу критических модулей, внедрению автоматизированного тестирования и устранению дублирования бизнес-правил
• Сроки достижения поставленных целей пересчитаны с учётом необходимости выделения 20–30% времени на борьбу с техническим долгом

Результат

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