Kimball, DWH и кейсы

Зачитался Ральфом Кимбалом "Data Warehouse Toolkit". В этой восхитительной книге технические аспекты, связанные с построением хранилищ данных (Data Warehouse) сопровождаются бизнес-кейсами разных задач анализа.

Интересно например, что скидки (allowances — на уровне контракта, и discounts — на уровне поставки) в конечном счете разбиваются на каждую продуктовую позицию в каждой продаже по какому-либо правилу, что позволяет, в итоге, считать маржинальность по каждому продукту.

Казалось бы, дали скидку на весь счет (заказ) одной строкой, зачем её делить в анализе, тем более, если для этого требуется какое-то правило? А вот зачем — может оказаться, что определенные продукты покупают чаще клиенты, которые получают скидки, или определенные продукты чаще продаются в условиях, когда предоставляются скидки, в итоге, какие-то продукты уходят с меньшей маржой.

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

Ralph Kimball "Data Warehouse Toolkit" это волшебная книга, которая учит правильно проектировать DWH. Приведённые кейсы, иногда похожие в разных отраслях, влияют на принципы проектирования систем поддержки принятия решений вообще — для всего класса систем.

Разнесение затрат (Cost Allocation)

Аналогично разделению скидки по товарным позициям, затраты в производственной организации так же должны разделяться по многим позициям — продуктам, структурным подразделениям и так далее. Это называется cost allocation — разнесение затрат.

Глядя на картинку сквозных процессов, можно обнаружить, что это матрица — она состоит из пересечений процессов и функциональных единиц.

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

В целях cost allocation бизнес-процессы не нуждаются в пошаговом описании, а лишь в определении границ.

Хранилище Данных (Data Warehouse)

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

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

Нужно ли так сложно?

Мне приходит мысль, что управленцы делятся на тех, кто "считает", и тех кто "чувствует".

У тех, кто "чувствует" спрос на анализ возникает после сбоев, снижения качества, либо с потерей прибыли.

У тех, кто "считает" спрос на анализ есть сам собой. Он заложен в логике принятия решений.

Постройте DWH сначала для решения простой задачи — соберите исторически верные данные. Например, накопите продажи в разрезе измерений с полной атрибутивной моделью; накопите разные факты — нехватка остатка, недопоставка, прямая маржа (без сложного разнесения себестоимости).

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

BI решение сначала станет источником достоверных данных, затем драйвером изменений.