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

На практике до дашборда было ещё далеко.

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

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