Hoff совместно с компанией Hoff Tech – основным техническим партнером в области разработки и поддержки ИТ-инфраструктуры, запустил новое корпоративное хранилище данных для оптимизации бизнес-аналитики и поддержки управленческих решений. Особенностью проекта стало быстрое внедрение и его окупаемость за год. О реализации проекта рассказывает Максим Смирнов, CDO Hoff Tech и номинант на премию Data Award.

- Как в Hoff пришли к реализации проекта, какова до сих пор была инфраструктура для работы с данными?

В компании была крупная, но слабо структурированная база данных на Microsoft SQL Server и набор OLAP‑кубов. Такая связка хорошо работала на раннем этапе развития компании: скорость разработки была максимальной, разработчики почти не были ограничены архитектурой, но отказоустойчивость фактически оставалась на последнем месте.

- Какие были проблемы, что не устраивало?

Со временем технический долг в виде многочисленных «костылей» привел к тому, что скорость разработки снизилась в несколько раз по сравнению с изначальной. Разработчикам приходилось тратить много времени на разбор кода без единого фреймворка и документации, вместо того чтобы делать новые фичи. По оценкам сотрудников, до 30% рабочего времени разработчики тратили на взаимные консультации и разбор запутанного кода. Низкая стабильность системы приводила примерно к двум критичным инцидентам каждую неделю.

- Какие задачи требовалось решить?

Предстояло создать единую платформу для сквозной аналитики и поддержки управленческих решений во всех ключевых бизнес‑направлениях компании. Целью было повысить скорость предоставления аналитической отчетности и автоматизировать формирование витрин данных для ключевых направлений: продаж, логистики, маркетинга, финансов и клиентского сервиса. Важной задачей была оптимизация бизнес‑процессов и повышение эффективности работы подразделений за счет внедрения data‑driven‑культуры и современных инструментов аналитики.

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

- Какой подход был выбран к созданию платформы данных?

Мы выбрали классическую архитектуру хранилища данных (DWH) на базе MPP‑системы Arenadata DB, чтобы минимизировать архитектурные риски, исключить неопределенности и реализовать проект в сжатые сроки. При этом учли современные подходы к построению дата‑платформ: обеспечили стабильный забор данных из операционных систем и реализовали потоковую загрузку, чтобы снизить задержки и повысить актуальность данных.

- Что с архитектурной точки зрения представляет собой решение?

В основу технологического стека легли Arenadata DB как MPP‑платформа для хранения и обработки данных, система потоковой передачи данных Apache Kafka и оркестратор ETL‑процессов Apache Airflow. Для управления корпоративными данными и метаданными используется Arenadata Catalog, а для аналитической визуализации и работы бизнес‑пользователей — Power BI.

- Какие проблемы возникали в ходе реализации проекта, как их решали?

Больше всего проблем возникло с реализацией потоковой загрузки данных. Ядро Arenadata DB изначально оптимизировано под пакетную загрузку и заметно деградирует по производительности при загрузке маленькими порциями. Поэтому мы пересмотрели архитектуру интеграции и приняли решение забирать данные из Kafka агрегированными партиями с укрупнением окон загрузки (например, раз в сутки или по бизнес‑событиям), что позволило сохранить производительность DWH при сохранении требуемой актуальности данных.

Дополнительной сложностью стала необходимость загружать данные из систем‑источников в Kafka в формате с описанной Avro‑схемой для соблюдения требований безопасности и повышения производительности. Для некоторых команд разработки это стало серьезным барьером: им пришлось осваивать новые инструменты и дорабатывать свои системы. Мы усилили внутренние команды, подготовили шаблоны и ввели практику «документации как кода» на основе инструмента DocHub по схемам и топикам Kafka, чтобы ускорить внедрение и снизить количество ошибок.

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

Необходимо было также преодолеть сопротивление изменениям: переход на data‑driven‑подход требовал от бизнеса отказаться от «эксельной» самодеятельности и прийти к единому «источнику истины». Мы ввели понятие «владелец данных», зафиксировали ключевые метрики и порядок их расчета и в результате сократили почти на 50% объем витрин, запланированных к миграции, сфокусировавшись только на действительно востребованных.

- Что получилось особенно удачным?

Это одно из первых в российском ретейле промышленных хранилищ данных, где полностью реализован переход от классической пакетной загрузки через ETL к высокопроизводительной потоковой интеграции данных. Решение использует современные стриминговые технологии (Kafka, CDC, Debezium) для непрерывного сбора и обработки информации во всех ключевых бизнес‑процессах, обеспечивая минимальные задержки при передаче данных и снижая нагрузку на legacy‑системы. Масштабируемая архитектура позволяет гибко расширять мощности хранилища и контролировать производительность на уровне многотерабайтных корпоративных систем.

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

- Какие результаты достигнуты?

Платформа охватила более 1,3 тыс. рабочих мест и стала единым источником данных для ключевых бизнес‑подразделений. На 30% снизились совокупные затраты на аналитику и разработку: штат команды уменьшился на семь человек за счет естественной текучести (мы не нанимали замену), при этом высвобожденные ресурсы были переориентированы на реализацию новых фичей и проектов вместо поддержки технического долга.

На 20% снизилось потребление ресурсов серверов отчетности благодаря рефакторингу, переносу расчетной логики в витрины и оптимизации запросов. За счет единых расчетных витрин сократились затраты на подготовку и согласование отчетности: уменьшилось дублирование отчетов и ручных сверок между подразделениями, повысилась эффективность ИТ‑специалистов уделяющих меньше времени поддержке устаревшего решения. Повысили надежность и отказоустойчивость системы: ушли от регулярных критических сбоев в отчетности, количество инцидентов сократилось в четыре раза, стабилизирован SLA по доступности данных для бизнеса.

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

- За счет чего окупаются инвестиции? Какие дата-продукты уже были реализованы на базе нового хранилища?

Помимо сдельной оплаты труда сотрудников склада, реализовавшей сложную мотивационную модель и повысившей прозрачность затрат на персонал, можно упомянуть набор витрин и отчетности для ключевых доменов: продажи, логистики, склада, финансов, e‑commerce, клиентского сервиса, — построенный на основе 21 функциональной витрины первого этапа проекта, что позволило бизнесу получать консолидированную аналитику по основным процессам из единого источника.

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

- Удалось ли в итоге создать data-driven-культуру? Какие действия для этого предпринимались и в чем выразился результат?

Мы сделали большой шаг вперед, но до полноценной data‑driven-культуры нам еще далеко. Внедрили роли владельцев данных, описали ключевые метрики и закрепили единые правила их расчета. Запустили единый каталог данных и витрин, начали переводить «самописные» Excel‑отчеты в промышленные витрины и дашборды. По ряду доменов (продажи, склад, HR) данные действительно стали основой для регулярных управленческих решений, и количество конфликтующих цифр заметно сократилось.

При этом часть пользователей по‑прежнему живет в старой парадигме. Некоторые менеджеры продолжают просить «выгрузку в Excel, как раньше», а не заходить в готовые дашборды. Не все подразделения приняли идею, что «истина» — в корпоративных витринах, а не в локальных файлах и разовых расчетах аналитиков. Формально владелец данных есть, но не везде это стало реальной ролью с полномочиями и ответственностью: иногда решения по метрикам все еще принимаются «по договоренности», а не по правилам.

Если честно, результат сейчас можно описать так: у нас появились инструменты и процессы для data‑driven подхода, есть первые сильные кейсы, снизилось количество противоречивых отчетов и ручных согласований. Но культура еще остается смешанной: часть бизнеса уже опирается на данные по‑настоящему, а часть воспринимает новую платформу как еще один источник информации, а не как основу принятия решений. Это честная точка, от которой мы продолжаем двигаться дальше.

- Каковы направления развития проекта?

Наша задача — развивать проект так, чтобы экономить не только усилия ИТ‑специалистов, но и время бизнес‑пользователей на анализ и принятие решений по данным.

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

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