Теперь короткий комментарий от нас, потому что одну вещь в таких материалах обычно опускают.
Дата-агент наследует то состояние данных, которое у вас есть на момент внедрения. Если «выручка» считается тремя разными способами и каждый живёт в своём отчёте, агент унаследует все три и будет уверенно отвечать по любой из них. Раньше расхождения всплывали на совещании, когда два человека приносили разные цифры. Теперь их будет проговаривать система, и звучать это будет убедительнее.
То же с правами доступа. Пока дашборд открывает человек, ограничение по площадке или юрлицу работает как фильтр интерфейса. Как только данные тянет агент и сам рассылает сводки, тот же фильтр становится контуром безопасности. Матрицу доступа стоит пересмотреть до пилота, а не после.
Поэтому совет вендора начинать с одного сценария мы поддерживаем, но добавим к нему подготовительный шаг: сначала нужно договориться об определениях метрик и зафиксировать их в модели данных, а только потом подключать агента.
Мы в GlowByte занимаемся именно этим слоем: строим хранилища и модели данных, приводим в порядок метрики и права доступа, внедряем и мигрируем BI-платформы, в том числе
FineBI, и помогаем внедрять Dora. Если планируете агентов поверх своей аналитики, напишите нам на
bi@glowbyteconsulting.com, посмотрим вашу схему и подскажем, с какого сценария разумнее стартовать.
А в комментариях интересно почитать, кто уже пробовал агентов над своим хранилищем и что из этого вышло.