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

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

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

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

Как проверить 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-объектов

#МашаАн

Да настройте вы уже эти лифты…🛗

Всем привет! На связи Дима Кротов. После нескольких лет в профессии у каждого из нас появляется «профдеформация»: стоматолог первым делом смотрит прикус, дизайнер — отступы и шрифты, а аналитик… не может пройти мимо криво работающего лифта 😳

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

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

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

✅ Целевая: время от нажатия на кнопку до доставки на целевой этаж
🔷 Прокси: среднее время ожидания лифта, количество промежуточных остановок
🛑 Контр: доля пустых рейсов, износ лифта

А по пути можно ещё и какой-нибудь CSAT замерять🙂

Ок, а какие алгоритмы подобрать, если лифт вызывается через ввод этажа в вестибюле? У меня получилось несколько вариантов (названия я придумал сам, не судите строго):

1️⃣Batching (группировка заявок) — система собирает заявки за «интервал сбора», затем группирует людей с близкими целями в одну кабину (батчи), минимизируя число остановок и общее время поездки.

2️⃣Zoning (зональное разделение) — этажи делятся на зоны (например, 1–7, 8–14, 15–20). В зависимости от введённого пользователем этажа, система направляет его в лифт, обслуживающий именно эту зону. Это снижает количество «пересечений» между зонами и ускоряет доставку, однако разные зоны могут пользоваться разным спросом, из-за чего может простаивать свободный ресурс.

3️⃣Nearest (ближайший в своей группе) — из сгруппированных заявок система выбирает кабину, которая быстрее всех сможет забрать пассажиров и отвезти их по маршруту с минимальным «пробегом» без пассажиров.

Супер, мы близки к решению. Надо понять, как задизайнить тест.

Это оказалось непросто. Лифты работают в комплексе, и эффект от работы алгоритмов надо оценивать на целом лифтовом холле, а их у нас в бизнес-центре целых… один. Как вариант, можно сделать time‑based A/B (crossover) — переключаем всё здание между алгоритмами по дням или сменам, например: чётные/нечётные дни, утренние/вечерние смены. Или можно попробовать засетапить синтетический контроль — сконструировать его из комбинации данных других зданий или периодов, однако на практике такое сделать крайне непросто. При наличии похожих бизнес‑центров можно также попробовать сделать Difference‑in‑Difference.

Тут, конечно, придется позаботиться о логировании: фиксируем каждый вызов → поездку, промежуточные остановки, пустые рейсы, технические инциденты. Убеждаемся, что тест небесполезный: рассчитаем нужный объём выборки [кол‑во сотрудников × поездок на человека] и MDE.

На этом мой разгон закончился, так как лифт наконец-то довез меня до нужного этажа)

Как думаете, какой алгоритм был бы эффективнее? 🎯

P.S. Если вам зашла история про разбор аналитических кейсов в жизни — ставьте 🤓 и кидайте идеи задачек в чат. Разберём в следующий постах!

#ДимаКр