Привет! На связи авторы Коммуналки. Возможно, вы уже успели познакомиться с нами через посты, а теперь мы хотим узнать больше о вас.

☑️ Зовём тыкнуть на пару кнопок в опросах ниже.

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

Спасибо, что вы с нами ❤️

Как проверить 1 000 объектов в BI-системе и не сойти с ума (а главное — зачем?)

Всем привет, сегодня на связи Маша Аничкова, и я расскажу, как мы недавно провели BI-субботник. И нет, мы не выходили чистить свои дашборды в субботу с мётлами)

Для начала договоримся о терминах: под BI-объектами в этом посте я буду подразумевать дашборды и то, из чего они состоят — в нашем случае это квери и чартсы. А также датасеты — источники данных для дашборда — что-то вроде витрины данных внутри BI-системы.

⭐️ Итак, сначала мы определили понятие проблемных объектов. В эту категорию вошли: малоиспользуемые, с неактуальным владельцем, медленные, с большой долей ошибок, дублирующиеся с другими объектами, использующие временные таблицы вместо продовых витрин. Конкретные критерии и информацию по всем объектам мы вывели в отдельный отчёт — Health Score. В нём можно посмотреть проблемные объекты по себе или по своему отделу, а также он даёт оценку по каждому критерию и общую оценку здоровья объекта.

⭐️ Далее мы продумали формат проведения субботника. В нашем случае это был «марафон по уборке», в котором поучаствовали почти все BI-разработчики компании. Мы задали конкретные даты проведения, чтобы в этот период мониторить участие и активно помогать консультациями. При этом каждый участник мог выбрать удобный день для проверки своих объектов. Это дало гибкость, ведь обычную работу и «срочные задачи от бизнеса» тоже никто не отменял, к сожалению.

Также мы сделали эксель-файл со списком проблемных объектов с детализацией по критериям. Отмечали в нём конкретные call to actions и статусы для каждого объекта: «фикс выполнен», «объект удалён», «фикс запланирован».

⭐️ Как это прошло?
За 3 недели проверили почти 1 000 объектов с плохим Health Score. В течение всего этого времени мы:
👉архивировали неактуальные объекты;
👉переносили черновики из продовых папок в личные sandbox-ы;
👉обновляли владельцев;
👉удаляли дублирующиеся датасеты;
👉работали над скоростью объектов;
👉планировали дальнейшие оптимизации.

⭐️ А для чего это нужно?
👉Улучшение перформанса. Медленная работа дашбордов — одна из основных причин неудовлетворённости пользователей.

👉Улучшение навигации по объектам. Если в отчётах нужно копаться, чтобы найти актуальные — это как минимум неудобно. К тому же пользователи могут случайно заглядывать в неактуальные отчёты и принимать неверные решения на основе некорректных данных.

👉Освобождение ресурсов CPU. Неиспользуемые или неоптимальные объекты съедают лишний ресурс — это может создавать дополнительные очереди на обновление и ухудшать перформанс хороших объектов.

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

А вы следите за качеством своих BI-объектов?
❤️ — у меня BI-объекты здорового человека
🙈 — у меня BI-объекты курильщика
🐳 — у меня пока нет своих BI-объектов

#МашаАн