Подход к созданию BI у отдельно взятого заказчика

Решил задокументировать свои соображения по поводу стратегии работы с заказчиком для облегчения работы по созданию BI-проекта. Как сделать процесс взаимодействия между ИТ-подрядчиком, группой разработчиком и заказчиком, наиболее продуктивным? Мой опыт и мысли на эту тему записаны ниже.

1.     Прынцыпы

Время вперед

Машина времени уже изобретена,

вот только движется она только в будущее

Все процессы развиваются во времени. Поэтому любой показатель привязывается к моменту времени. Детализация может производиться до секунды (для производственных процессов), до часа (для учета чеков), до дня (для обычных управленческих процессов). Обычно достаточно детализации до дня (даты события).

С другой стороны временной промежуток может для отчетности собираться в отчетные периоды. Требуется определиться с тем, какими отчетными периодами мыслит (управляет) заказчик.

Следующий объект временной отрезок, внутри которого группируются события внутри отчетного периода. Т.е. оперируя месячным отчетным периодом, можно разбить его на отрезки день, неделя, декада, 1-я и 2-я половины месяца, и, наконец, месяц.

Сравнимость

— Петька, приборы?

— Двадцать!

— А что — двадцать?

— А что — приборы?

Если мы выводим на экран какой-либо фактический показатель, то сам по себе он ничего не значит. Значение он обретает только в контексте сравнения много это или мало (хорошо или плохо). Обычно показатели сравнивают с планом, а это автоматически требует с заказчика плана по показателю. Иногда сравнивают с базовым периодом (аналогичным периодом прошлого года, предыдущий месяц, то, что называют like-4-like-аналитика), назовем такой период — история.

Следствием, является то, что нужно быть готовым отображать 3 одновременных показателя дающих представление:

  • Факт/история — что изменилось?
  • План/история — план адекватен? есть запланированные предпосылки для отклонений плана от достигнутого?
  • Факт/план — Как идут дела по сравнению с запланированным?

В идеальном случае можно отображать исторические данные нескольких отчетных периодов, не только текущие планы, но и будущих периодов.

Аггрегируемость

— Ты видишь суслика?

— Нет!

— А он там есть!

Любой показатель может иметь смысл на самом нижнем уровне иерархии. Таким образом, любой показатель может быть применим как ко всей организации, так и к её части, организационному или функциональному разрезу.

Принципиальное отличие BI от систем отчетности — возможность провалиться на нижележащий уровень иерархии с сохранением набора отображаемых показателей (естественно, из значения поменяются).

2.     Данные

Факты

— Сколько будет 2×2

Инженер: — Четыре!

Маркетолог: — OK, Siri, сколько будет 2×2?

Продавец: — А скока нада?

В большинстве случаев факты не надо искажать в BI. В большинстве случаев событие бинарно: вчера его не было, а сегодня уже случилось. Все это верно, за, быть может, единственным исключением: учет работ в системе управления проектами. Работы ведутся непрерывно, а надзор приходит редко, в результате получается кривая 0-10-50-100%, которую было бы хорошо сгладить по отрезкам времени 0-5-10-30-50-75-100%.

А, вот еще одно исключение: приведение показателей к системе СИ (СГС, имперской), первичной валюте, либо базовой единице измерения.

Отдельная тема искажения фактов — мэппинг. Мэппинг бывает следующих типов:

  • Тривиальный — заменить коды объектов их названиями.
  • Определенный — когда известно, что определенные данные нужно подменять, либо пропускать. Например, когда имеется реестр, в котором 2 разных артикула товара, приводятся к одному, либо технологические услуги из реестра не должны отражаться в BI.
  • Неопределенный — когда в случае отсутствия какого либо атрибута, например, объема товара, нужно по формуле рассчитать его из веса товара и плотности. Хотите еще примеров: расчет себестоимости, на основании стоимости и типовой маржи.

Буду неустанно повторять — BI не учетная система, она не должна показывать идеально выверенные данные посмертного учета. BI-система должна предоставлять возможность принять верное управленческое решение.

Отдельная большая тема: выверка данных — повод для другой статьи. Необходимо согласовать, какие отчеты будут использоваться для сверки данных, при необходимости должна быть декларирована возможность расхождения. Типовой пример: расчет НДС в SAP и 1С может отличаться на копейки из-за различий в алгоритмах округления.

Планы

Есть ли у вас план, мистер Фикс?

Есть ли у меня план? Конечно, есть!

Как уже было отмечено, планы — неотъемлемая часть BI. Это означает, что для каждого отдельно взятого КПЭ необходимо расписать этот показатель на отрезки времени. Пусть имеется целевой показатель инвестиций на год. Его нужно расписать по дням (желательно рабочим) если, конечно минимальный временной отрезок — день. Или, например, целевой показатель аварий — он должен быть спрогнозирован, исходя из целевых значений поэтапного снижения, по временным отрезкам. Часть показателей, может не иметь размерности времени, например доли в процентах, тем не менее, это хорошее упражнение для формирования модели данных.

Ретроспектива

— А сколько вам лет?

— Восемнадцать!

— Ничего, этот недостаток со временем проходит.

Необходимо предусмотреть ввод и пересчет фактических показателей из прошлого для отображения в BI. Детализация событий должна быть адаптирована под текущую модель данных. Вряд ли нас могут заинтересовать проводки 3-х летней давности с привязкой к исполнителю (который давно уволился, а организационная структура минимум три раза поменялась, но при этом резко снижается трудоемкость ввода старых данных (особенно с бумаги).

С другой стороны BI делается не на один год, а буквально через 12 месяцев мы будем иметь полностью наполненный массив исторических данных.

3.     Пользователи

Я не знаю, зачем и кому это нужно…

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

Пока не определен пользователь — заказчик BI, двигаться дальше, создавать модель данных, подключаться к источникам нет смысла. Вариант: а соберите нам все данные не проходит. Например, в 1С более 1000 (одной тысячи) объектов, у каждого десяток атрибутов, т.е. речь идет всего лишь о 10 тысячах полей, не считая собственно записей…

Даже одни и те же факты разные пользователи интерпретируют по-разному. Для продавца перевыполнение плана продаж в 2 раза — предвкушение бонуса, для логиста — надвигающаяся головная боль, связанная с отсутствием товара.

4.     Актуальность

Турист в поезде: — Далеко ли до Таллина?

Через два часа: — Теперь далеко!

Абстрактно можно выделить типовые задачи:

  • Стратегическое управление
  • Оперативное управление
  • Аналитическая работа, ретроспективный анализ, тренды и т.п.

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

Требуется определиться какие данные, как часто вы будете получать. Полная ежесуточная перегрузка данных, может занять 25 часов, очевидно, что такой подход неприменим. На помощь может придти инкрементальная выгрузка.

5.     Представления

Слепцов спросили, что такое слон?

— Он похож на лиану — сказал дотронувшийся до хвоста

— Он похож на змею — сказал потрогавший хобот

— Он похож на пальму — сказал ощупавший ногу

— Он похож на стену — сказал похлопавший слона по боку.

Определив пользователей, собрав с них требования, можно попробовать сформировать модель данных, а затем перейти к представлениям, в зависимости от требований конкретного пользователя и его задач. Можно я не буду рассказывать, как строить абстрактную модель данных и создавать интерфейс пользователей?

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

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

В цветовой палитре не используется красный цвет — он зарезервирован для привлечения внимания к важным отклонениям либо ошибкам.

6.     Исключения

Исключения из правил лишь подтверждают наличие правил

Следует четко описать, что делать с пустыми строками (str.lenght=0) и нулевыми строками (isnull(str)). Необязательно это решение согласовывать с заказчиком, но поведение системы должно быть документировано.

В случае появления null в числовых данных BI система может производить замену на средние (типовые) значения, предоставляя возможность получения примерных данных в случая отсутствия точных. Пример: в случае отсутствия стоимости работ, BI система может проставить среднее значение, чтобы агрегировать показатели на уровень организации, это незначительно снизит точность, но повысит устойчивость, в случае отсутствия единственного показателя от линейного подразделения.

Необходимо отдельно оговорить, что делать с неконсистентсностью справочников и документов. Если неконсистентность обнаружена, кто в каком порядке её устраняет (и нужно ли её устранять).

Следует отметить, что превышение мощности справочника над мощностью выборки данных (в справочнике есть объекты, которых нет в наборе данных) — нормальное явление, но требуется согласование с заказчиком, обрезка несуществующих элементов (inner join). Отдельный случай, когда в справочнике задваиваются ключи. BI может восстановить ключи, сделав их синтетическими, а может просто взять первый попавшийся элемент. Не оставляйте это на волю случая, задокументируйте и согласуйте с представителем организации.

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

7.     Отмазка

2 13 45

33 08

6 16 35

8 8 8!

Термины «может», «должен», «хочет» использованы в соответствии с RFC 2119. В процессе подготовки статьи ни один термин не пострадал.

Комментируйте!

B3

.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Подпишись на Data-Daily!

Введите email и будьте в курсе!

Подпишись!