Когда отчёты жили в разных системах, а ответы нужны были сегодня

Контекст

Поддержка ежедневно генерировала большой объём данных, но собрать из них цельную картину было непросто. Одни показатели жили в CRM, другие — в телефонии, третьи — в отдельных выгрузках. Аналитики тратили время не на поиск причин, а на подготовку данных. Неожиданно выяснилось, что один и тот же показатель в разных отчётах мог считаться по-разному. На обсуждениях всё чаще спорили не о причинах изменений, а о том, чьи цифры правильнее. Новые Excel-файлы помогали лишь ненадолго — ручной работы становилось только больше.

Роль

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

Действия

Начали с разбора всех источников данных и договорились, какие показатели должны считаться единым источником истины. После этого спроектировали хранилище и построили ETL-конвейер, который автоматически собирал данные из разных систем. Для визуализации выбрали Apache Superset. Затем постепенно переносили отчётность в единую среду, проверяли расчёты, убирали дублирующие показатели и приводили дашборды к общей логике. Несколько решений пришлось пересматривать уже в процессе — сначала казалось, что структуры данных хватит, но реальные сценарии быстро показали её слабые места.

Результат

Подготовка отчётности стала занимать заметно меньше времени, потому что большая часть данных собиралась автоматически. Руководители начали смотреть на одни и те же показатели вместо того, чтобы сравнивать разные версии отчётов. Аналитики смогли уделять больше времени поиску причин изменений, а не подготовке выгрузок. Когда возникал вопрос о работе поддержки, нужные данные уже были собраны в одном месте.