Привет, Habr! Совсем недавно я опубликовал статью про Self-Service BI: что же это такое и зачем он нужен крупным компаниям. Но теперь хочется немного отойти непосредственно от Self-Service и вернуться в целом к построению BI-систем. В 2021 году я выступал на Analyst Days с одноименным докладом. Запись выступления ниже (казалось бы, причем тут автомобили?):

Но чтобы не оставлять вас наедине с видео я решил написать некое summary в данной статье. Очень надеюсь на то, что оно будет очень полезно начинающим (и не только) BI-аналитикам. Поехали?

Выбор платформы

Непосредственно выбор BI-платформы не должен происходить в виде "...а вот у них такая система, мы такую же хотим!" или "Гартнер сказал - эта лучше всего, берем ее...", "...а вот эта дешевле, давайте ее..." . Не надо гнаться за "модными" инструментами только ради них самих. Всегда нужно обосновывать выбор под ваши конкретные цели и задачи. И не всегда нужен PowerBI или Tableau, где-то хватит "экселя" (не шутка). Особенно если вам нужны таблицы:

Прототип

Прототип всему голова. В любой непонятной ситуации просто создайте прототип. В мире BI его можно делать сразу в том инструменте, в котором планируется создание самого конечного дашборда. Например, в том же Power BI можно спокойно сгенерировать/импортировать ручные/фейковые данные и нарисовать драфт отчета. Времени займет немного, но пользы на весь дальнейший проект. Это как с созданием автомобиля - всегда в начале создается прототип и только потом серийная версия.

Разбивка отчетов

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

Унификация метрик

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

Безопасность

Допустим, что отчеты по ролям мы разделили, все хорошо. Но что, если одним отчетом внутри отдела планируют пользоваться несколько менеджеров пониже, каждый из которых должен видеть только свои цифры?

В таком случае необходимо разграничивать доступ для конкретных пользователей. Это так называемая row-level security (RLS). Особенно остро встает такой вопрос, если пользователи компетентные в техническом плане. И даже при преднастроенном отчете, например, в PowerBI, со скрытыми фильтрами на их отдел, могут зайти, например, в эксель и посмотреть там на уровне источника данных все, что они захотят.

Требования к данным

А теперь к самому важному этапу работ по построению BI-системы для аналитика - это написание требований на обработку данных. Мы помним, что в классической архитектуре у нас обязательно присутствует DWH (Data Warehouse) с несколькими уровнями преобразования данных, а также, например, с аналитическими кубами поверх DWH. И самой разработкой уже занимаются дата-инженеры, а требования для них подготавливает аналитик.

Так вот, на практике очень часто встречается тот факт, что требования написаны «грубо», только абстрактно описывая конкретный показатель: например, простой SQL-скрипт на источнике, или, что сильно хуже – бизнес-формула без маппинга с физическими значениями в базе данных. Как подготовить под это модель данных – не всегда сразу понятно. Разработчики пытаются сделать ее «на лету», тратят время и без бизнес-контекста иногда делают ее не поддерживаемой. Поэтому аналитики должны заранее фиксировать требования ко всем уровням преобразования данных: например, Staging (STG) / Detail Data Storage (DDS) / Data Marts (DM) / Cube / Dashboard. Пусть даже не одни, а совместно с разработкой – но ДО самой разработки. От того, насколько качественно будет спроектирована и описана модель данных, напрямую зависит качество всей BI-системы.

Тестирование

Аналогично написанию требований ко всем этапам преобразования данных, тестирование должно происходить также на всех этих этапах. То есть по слоям, которые я упоминал ранее: загрузили в STG - проверили, загрузили в детальный слой хранилища – проверили, и т.д.

В идеале (в таком контексте) у нас должны быть формализованы детальные требования, на основе которых можно оперативно составить и провести такие тесты. Если их нет – будет сильно сложнее локализовать ошибку на финальных этапах. Также не стоит забывать про тестирование финальных отчетов с заказчиком. Даже если вы изначально закрепили все требования и согласовали прототип – это не означает, что в реальном отчете на реальных данных спустя N времени у заказчика они не изменятся. К этому надо быть готовым.

Бренд

Практически у каждой компании есть своя корпоративная стилистика. И при построении BI-системы мы должны будем соблюдать внутренние политики компании относительно бренда. Обычно, интерфейсы большинства корпоративных ИТ-систем приводят к единой палитре. Плюс, зачастую, конкретные цвета используются под конкретные показатели: например, все бюджетные значения отмечаются синим, а все фактические – фиолетовым. Это тоже стоит учитывать, чтобы у пользователей не было вопросов, почему везде все разное :)

Производительность

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

В самом начале лучше сразу заложить запас, потому что потом может быть больно. Думаю, никому не хочется попасть в такую ситуацию: сделали систему, думали будет около 10 пользователей и 5 отчетов, потом стало 500 пользователей и 30 отчетов – и все виснет :)

Мобильные версии

На дворе у нас уже 2023 год, люди давно и активно используют смартфоны и другие мобильные устройства для работы. У нас уже есть отчет, большой и красивый. (Клик на 1 фото) Но что будет, если попытаться в лоб открыть его на телефоне через браузер?

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

Печатные версии

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

Правильно, выйдет плохо :) Если вы знаете, что кто-то из пользователей планирует печатать конкретные отчеты (например, перед собраниями или для собственного анализа), то есть смысл физически создать их отдельные копии, которые будут подходить для таких целей. Меньшее количество информации, простые графики и меньшее количество цветов. Это сильно поднимет совокупный рейтинг системе, которая будет позволять даже в такой нечастой ситуации обеспечить запросы пользователей.

Статистика использования

Итак, отчеты мы сделали, много и для разных ролей. Но тут может возникнуть вопрос – ими реально кто-то пользуется? Если да – то как?

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

Инструкции

BI-отчеты могут быть не для всех юзеров сразу понятны. Плюс - могут прийти новые сотрудники, или другие представители роли, которые пока не в курсе происходящего. Поэтому нужно прорабатывать гайды к моменту запуска системы в удобном для пользователей формате (например, PDF со скриншотами). Конечная система должна быть удобной и понятной для пользователя. Но если он сразу не «въехал», что делать – он должен быстро понять, куда ему подсмотреть.

Цель системы

Последний, но наверное самый важный пункт - цель BI-системы. Мы можем столкнуться с проблемой, что наша система становится частью некого другого процесса или другой системы. Давайте вспомним, что BI система должна помогать в принятии управленческих решений. И, к сожалению, многие забывают про суть управленческой отчётности: гонятся за деталями, которые в итоге оказываются почти никому не нужны. А также за сотыми долями в цифрах, когда на самом деле важен лишь тренд и взаимосвязь показателей. Поэтому очень важно направлять коллег в нужное русло и "фильтровать" многочисленные запросы от пользователей.

Итоги

А теперь давайте кратко подведем итоги, что мы успели с вами обсудить:

1. Не забывайте про контекст при выборе платформы для BI-системы;

2. Сразу создавайте максимально детальный прототип;

3. Разбивайте отчеты для каждой роли и области;

4. Не забывайте про Row-Level security;

5. Фиксируйте требования к каждому этапу преобразования данных…

6. ... и тестируйте также!

7. Не забывайте про то, что вы работаете в рамках бренда…

8. …и что люди хотят получать данные быстро!

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

10. Настройте отчет со статистикой;

11. И не забудьте «рассказать» пользователям про отчеты с помощью гайдов.

А самое главное – помните про исходную цель BI-системы!