#аналитическая_платформа — Public Fediverse posts

Как разработать шаблон дашборда для разных подразделений

В одном из BI-проектов мы собирали управленческую аналитику для крупной образовательной организации. В одном контуре должны были работать данные о контингенте, успеваемости, задолженностях, финансах, нагрузке и других направлениях. Пользователи при этом были совсем разными: руководство смотрело на организацию целиком, учебные подразделения работали со своими процессами, кафедрам была нужна более глубокая детализация, финансовым специалистам - собственные показатели и периоды, а аналитикам - возможность проверить итог до исходных записей. Технически всё это можно было оформить десятками отдельных дашбордов. Взять первый отчёт, скопировать его, заменить заголовок, добавить несколько фильтров и повторить для следующего подразделения. На старте такой путь кажется самым быстрым. Макет уже есть, визуализации работают, пользователю можно довольно скоро показать знакомую картинку. Проблема начинается чуть позже. В одном отчёте меняется формула, а в остальных остаётся старая. Где-то появляется новый фильтр, где-то забывают обновить справочник. Один дашборд показывает данные на текущую дату, другой - на конец закрытого периода. Затем меняется структура организации, часть пользователей получает новые роли, и команда уже не понимает, сколько у неё версий одного и того же отчёта. Противоположный вариант тоже выглядит логично: сделать один универсальный дашборд, который умеет показывать всё всем. Обычно он быстро обрастает десятками вкладок, фильтрами на половину экрана и показателями, большая часть которых конкретному пользователю не нужна. Формально отчёт единый. Фактически каждый человек открывает его и заново ищет свой рабочий сценарий.

https://habr.com/ru/articles/1087764/

#BI #шаблон_дашборда #семантическая_модель #RLS #OLS #дизайнсистема #аналитическая_платформа #управление_данными #регрессионное_тестирование #масштабирование_BI

Почему внедрение BI не заканчивается публикацией дашборда

В одном из проектов мы развернули рабочую версию управленческой аналитики на сервере. Данные приходили из нескольких внутренних систем, часть доступа была организована через API смежной команды, а сверху уже строились витрины и дашборды. Первую версию показали руководству, получили согласование и перешли к дальнейшему развитию. На этом месте легко поставить мысленную галочку напротив пункта «BI внедрён». Сервер работает, отчёт открывается, цифры можно фильтровать, пользователи получили ссылку. Формально результат есть. Но через некоторое время платформа обновилась, и часть уже созданных дашбордов потребовала восстановления и переработки. Параллельно продолжали меняться источники, уточнялись показатели, появлялись новые запросы. Отчёт, который вчера был правильным, сегодня мог не обновиться, потерять связь с источником или просто перестать соответствовать процессу. Я не считаю эту ситуацию особенностью конкретной BI-системы. В нашем случае использовалась Visiology, но похожий сценарий возможен с Power BI, DataLens, Metabase и практически любым другим продуктом. Причина обычно находится не в одной кнопке и даже не в самой платформе. Проблема в том, что дашборд воспринимают как итог внедрения, хотя на самом деле это только пользовательский интерфейс большого контура. После публикации начинается не завершение проекта, а эксплуатация. И именно в этот момент становится видно, построили мы BI как организационный продукт или просто положили на сервер несколько красивых отчётов.

https://habr.com/ru/articles/1082112/

#BI #эксплуатация_BI #SLO #аналитическая_платформа #управление

Как выбирать BI-систему под реальные ограничения организации

В одном из проектов мне нужно было развивать управленческую аналитику в крупной образовательной организации. Данные уже были: учебные процессы, финансовые показатели, поступления и другие направления хранились во внутренних системах. Руководству требовались не очередные Excel-файлы, а единый BI-контур с дашбордами, детализацией и регулярным обновлением. На тот момент я уже работал с Power BI и DataLens, а рабочую версию управленческой аналитики мы развернули на сервере в Visiology. Прототип показали руководству и получили согласование на дальнейшее развитие. То есть на уровне первой демонстрации всё получилось: данные загрузились, дашборды открылись, показатели можно было обсуждать уже не на словах. Если смотреть только на этот момент, систему можно считать выбранной успешно. Но дальше началась обычная жизнь корпоративного ПО. Источники были доступны не напрямую, требования менялись, за сервер отвечала одна команда, за данные другая, а за отчёты третья. После обновления платформы часть дашбордов потребовала восстановления и переработки. Я не могу утверждать, что это универсальная проблема конкретного продукта: ситуация зависела от версии, конфигурации и локального контура. Но для меня это стало хорошим напоминанием, что BI выбирают не на день презентации. Его выбирают на несколько лет эксплуатации, обновлений, смены сотрудников и споров о том, кто вообще должен чинить отчёт в понедельник утром. После этого проекта я стал смотреть на BI не как на редактор графиков, а как на организационный продукт. У него есть пользователи, владелец, инфраструктура, SLA, стоимость изменений и накопленный технический долг. И если всё это не учитывать, система с лучшими визуализациями вполне может оказаться худшим выбором для конкретной организации.

https://habr.com/ru/articles/1082098/

#BI #выбор_BIсистемы #Power_BI #Visiology #DataLens #TCO #PoC #RLS #аналитическая_платформа #архитектура_данных

Контроль вертикальности и смещения: почему башни и мачты нуждаются в круглосуточном мониторинге

Геодезист с тахеометром стоимостью в несколько миллионов рублей приезжает на объект раз в месяц, квартал или год. Проводит все необходимые измерения, обрабатывает полученный результат и фиксирует отклонения, если они есть. А что происходит с башней между измерениями? Солнце нагревает одну сторону опоры и, в процессе деформации металла, отклоняется вертикальная ось. Или налетает штормовой ветер – и, в зависимости от высоты и конструкции башни, отклонения оси от вертикали могут достигать уже десятки сантиметров. При этом радиорелейная связь падает, качество сигнала деградирует, а вы продолжаете искать причину в помехах или оборудовании. Помочь с этой проблемой может система непрерывного мониторинга, которая работает 24/7, передаёт данные с интервалом от 5 до 60 минут и показывает реальную динамику отклонений с точностью до миллиметра. Меня зовут Оксана Эйнеш, я руководитель направления «Высокоточное позиционирование» в МТС. В нашей компании эксплуатируются тысячи антенных опор связи по всей России. Мы разработали для них собственную систему контроля деформаций. В этом материале я разберу, из чего она состоит, как работает и зачем вообще нужна, даже если у вас не вышка, а, скажем, дамба или ЛЭП.

https://habr.com/ru/companies/ru_mts/articles/1043246/

#контроль_деформаций #мониторинг_опор #инклинометры #NBIoT #высокоточное__позиционирование #антенные_опоры #геодезия #аналитическая_платформа #эксплуатационный_контроль #тепловая_деформация

Есть ли жизнь после Vertica или миграция DWH в Lakehouse

Всем привет! Меня зовут Дмитрий Рейман, я техлид аналитической платформы Авито. Последний раз мы подробно писали о нашей платформе почти четыре года назад — в статье «Эволюция хранилища данных в Авито» . С тех пор аналитическая платформа сильно изменилась — и по масштабу, и по сложности.

https://habr.com/ru/companies/avito/articles/979836/

#dwh #trino #vertica #mpp #аналитическая_платформа