ТОП-10 причин переделать или похоронить свеженький BI-отчёт. Где «соломки подстелить»?

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

Чтобы запомнить все нюансы и в следующий раз их учесть, мы делаем себе пометки, чек-листы, описываем процессы. Делюсь своими 10 «татуировками» BI-щика 😊

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

Сначала наводим порядок, потом автоматизируем.

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

Визуал отчёта должен соответствовать флоу его использования.

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

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

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

Знать про доступы и ограничения заранее = понимать, как заложить и в модель, и в визуал все эти нюансы.

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

Вопросы, много вопросов заказчику. Критическое мышление вкупе с лёгким недоверием заказчику в части заверений о бизнес-логике и её неизменности. И опыт разработки масштабируемых моделей.

А давайте сделаем ABC-анализ проектов? А давайте. Или организуем скоринг заказчикам на этапе пресейла, чтобы понимать, с кем работать, а с кем – нет. Как вы думаете, были ли в обоих случаях проекты, которые попали в категорию «уберите это немедленно»? Конечно были. Сделали с ними что-нибудь? Не-а. И задачи такой, как оказалось, никто не ставил. Посмотрели на распределение ABC, посмотрели на скоринг. Убедились, что и без цифр было понятно, что с ними работать не надо. Закрыли отчёт и поехали дальше. Со всеми этими же заказчиками.

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

У заказчика система бюджетирования – раз в неделю обновляются все бюджеты. И система хранит в себе все данные за каждую неделю. И нужно показать сравнение любых двух бюджетов. Легко! Но на деле оказалось, что «данные все, да не все». А есть кое-что, что не бюджетируется. Живёт в статусах «да» и «нет», без истории изменения этих статусов. И ладно если есть хранилище, можно организовать эту историчность там. А если его нет? И мы не проверили на старте, что бюджетируется действительно всё.

Продумываем всю логику и проверяем возвращаемые системами данные – до старта разработки.

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

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

Иногда у очень распространённых и популярных систем случается отсутствие API. Когда я с этим реально столкнулась, мне было сложно поверить. Решила даже в какой-то момент, что я гуглить разучилась. Бывает другое – API не отдаёт тех данных, которые есть внутри системы и очень нужны для построения отчёта. Или отдаёт, но при этом нагрузка на систему так сильно возрастает, что приходится принимать дополнительные меры. Или отдаёт, но в таком виде, что данным требуется дополнительная обработка, хранилище или что-то ещё.

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

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

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

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

Больше публикаций на тему внедрения BI и DDDM - в нашем телеграм-канале. Буду рада видеть вас в числе подписчиков 😉

Мария Дробинская, Руководитель BI-направления Sibedge