Первый куб: OLAP-отчёт вместо дня в Excel

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

Претензия справедливая. У компании - торговля, три региона, несколько сотен SKU, и желание понять, какой товар где и когда продаётся. Задача не экзотическая. Но существующий инструментарий её не закрывал: учётная база - 1С в клиент-серверном режиме на SQL Server, отчёты в ней написаны под конкретные разрезы, всё остальное - запрос программисту и ожидание.

Почему Excel тут не лечится

Выгрузка в Excel решает другую задачу - зафиксировать факт, а не исследовать его. Если нужен срез «регион + товарная группа», программист делает один запрос. Нужен «регион + период» - другой. Нужен «товарная группа + период + менеджер» - звони снова. При этом каждый такой запрос к боевой базе либо нагружает её в рабочее время, либо делается ночью с задержкой на сутки.

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

Что такое куб и зачем он нужен

OLAP - Online Analytical Processing - это не продукт, это подход. Данные из учётной системы загружаются в специальную структуру, где каждое измерение (регион, товар, период, менеджер, канал продаж) является осью. По любой комбинации осей можно получить агрегат - сумму, количество, среднее - без нового SQL-запроса к исходной базе.

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

Для среднего бизнеса это стало доступно относительно недавно: раньше OLAP был территорией дорогих корпоративных систем. Сейчас Microsoft выпустила Analysis Services как часть SQL Server, и лицензия уже есть у многих клиентов, которые пользуются SQL Server 2000.

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

Источник данных - та же 1С на SQL Server. Ночью по расписанию запускается ETL-процедура: вытаскивает из учётной базы проводки за прошедший день, очищает, приводит к единому виду и загружает в отдельную аналитическую базу. Куб строится поверх неё - боевая 1С вообще не знает, что её данные куда-то уходят.

Измерения получились такие:

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

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

Фронтенд - Excel с подключением к Analysis Services через OLE DB. Финдиректор уже умеет работать в Excel, учить новый интерфейс не нужно. Сводная таблица подключается к кубу, измерения перетаскиваются мышкой - и всё.

Что получилось на практике

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

Отчёт, который раньше готовился день (запрос - ожидание - выгрузка - форматирование), теперь открывается за несколько секунд.

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

Что пока не решено

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

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

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