Ночная витрина: утром свежие цифры вместо звонка аналитику

Разговор с финдиректором начался с фразы, которую мы слышим примерно раз в квартал: «Почему у Ивановой одни цифры, у Петрова другие, а в 1С третьи - и никто не может объяснить, какие правильные?»

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

Задача стала понятна: нужна одна аналитическая база, которая забирает данные из учётной системы ночью и к утру показывает свежие цифры. Без ручных выгрузок, без промежуточных Excel-ов, без «позвони Ивановой, у неё последняя версия».

Как выглядела исходная схема

Клиент - производственная компания, учётная система - 1С в клиент-серверном режиме на SQL Server. Данные там есть: продажи, закупки, остатки, себестоимость. Проблема не в отсутствии данных, а в том, что выгрузить их в удобном виде без программиста невозможно. Штатные отчёты 1С заточены под бухгалтерию, а не под управленческий взгляд. Управленческий взгляд требует другого разреза - не «оборотка по счёту 41», а «маржа по продуктовым группам в динамике по неделям».

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

Что построили

Схема, которую мы поставили, несложная, но требует аккуратности в деталях.

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

Ночью, когда нагрузка минимальна, запускается ETL-пакет на SSIS - вытаскивает из учётной базы изменения за прошедший день, очищает, приводит к единой модели и загружает в аналитическую базу. Процесс занимает от 20 до 40 минут в зависимости от объёма. К восьми утра всё готово.

Поверх аналитической базы - несколько преднастроенных отчётов в Reporting Services. Финансист открывает браузер, выбирает период, смотрит цифры. Один источник, одна версия данных.

Где была основная работа

Техническая часть - не самая трудоёмкая. Основная работа ушла на три вещи.

Первое - модель данных. Структура в 1С заточена под бухгалтерский учёт. Аналитическая модель устроена иначе: факты (продажи, поступления, списания) и измерения (товар, контрагент, период, склад, менеджер). Привести одно к другому - это не просто написать select, это понять, как компания реально смотрит на свой бизнес. Несколько сессий с финдиректором и коммерческим директором, где мы рисовали на бумаге «что вы хотите видеть» - обязательный этап. Без этого получится красивая база, которую никто не использует.

Второе - качество данных в источнике. Как только начали смотреть на данные в аналитическом разрезе, немедленно вылезло то, что в 1С годами прятали под ковёр: незаполненные реквизиты, дублирующиеся контрагенты, товары без категории. В OLAP-кубе всё это сразу видно - появляется загадочная строка «не указано» с приличной суммой. Пришлось выделить время на чистку справочников в 1С. Неприятно, но правильно: лучше увидеть проблему сейчас, чем продолжать считать управленческие отчёты по грязным данным.

Третье - договориться с людьми. У финансистов выработан рефлекс: «в 1С правда, остальное - приблизительно». Первые недели они звонили и уточняли: «А эти данные точные? А почему сумма не совпадает с тем, что у меня в отчёте за прошлый месяц?» Пришлось объяснять, что данные те же самые - просто теперь они смотрят на вчерашний день, а не на месяц назад. Доверие приходит постепенно.

Что получилось

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

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

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

Если похожая задача есть - посмотрите, что мы делаем в части хранилищ и BI. Часто хватает одного разговора, чтобы понять, реально ли это сделать на вашем стеке и что это даст.