FineBI в России

Логи FineBI 6.1.6 не достать запросом к fine_record_execute

@Ola_la_S хотела вытянуть логи использования платформы. Подключение проходит, а SQL-запрос к таблице fine_record_execute падает с ошибкой.

Разгадку дал @tipadima: на FineBI 6.1.6 журналы живут в Elasticsearch, и читать их надо оттуда. Плагин экспорта в обычную базу есть для FineReport, для FineBI он не находил. Можно подключиться к Elasticsearch напрямую. Или копировать журналы скриптом в MySQL, и такой скрипт он выложил на GitHub. Сам выбрал скрипт: после смены версий структура журналов менялась, но в целом работает без нареканий.

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

Выходит, у каждого пути своё место поломки: скрипт ломается при смене версии, прямое подключение тихо перестаёт получать строки. Поэтому после любого обновления первым делом стоит проверить, что новые строки приходят.

Спасибо за помощь @tipadima. Если вы уже ловили ноль новых строк из Elasticsearch, подскажите в @FineBIChat, что помогло

Источник: https://t.me/finebichat/30072
Скрипт: https://github.com/tipadima/finebi_export_logdb

#FineBI #FanRuan #Elasticsearch #логи #администрирование #BI

DORA выходит из отдельной вкладки

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

Если ради каждого вопроса нужно открывать ещё одну систему, даже полезный агент рискует остаться инструментом для редких случаев. В DORA 1.2 заметная часть изменений как раз про то, чтобы приблизить агента к повседневной работе. Релиз вышел 1 сентября 2026 года.

Во-первых, появилась мобильная версия. С телефона можно обратиться к агентам, продолжить разговор и открыть материалы из библиотеки. Важная оговорка: это доступ через мобильный браузер, а не отдельное приложение. Открыть DORA можно напрямую, через мобильный FineBI или через корпоративную рабочую платформу после настройки интеграции.

Во-вторых, расширились возможности API. Теперь корпоративный портал или бизнес-приложение может обращаться к агенту DORA: вести диалог, работать с сессиями, файлами и настройками агента. Это уже другой сценарий - не «пригласить сотрудника в ИИ-платформу», а встроить аналитику в систему, где у него и возник вопрос.

Есть и менее заметные, но практичные изменения. Для одного агента можно настроить несколько языковых моделей, чтобы пользователь выбирал подходящую под задачу. А если при предварительном обновлении данных из FineBI один источник выдаст ошибку, остальные продолжат обновляться; проблемный источник можно будет найти по уведомлению и открыть в FineBI для разбора.

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

И здесь хочется задать вопрос уже не про возможности модели: в каком рабочем процессе агент действительно пригодится, а где он станет ещё одной вкладкой?

Подробнее - в описании DORA 1.2

#DORA #FineBI #FanRuan #ИИ #DataAgent #бизнесаналитика

Каждый неверный ответ в викторине про DEF_SUB верен для другой формулы

В викторине 28 сентября спрашивали, что покажет DEF_SUB(SUM_AGG(Продажи),[Категория]) в таблице с измерениями Регион и Категория. Ответили 18 человек, верно 11 (61%). Разбирать тут стоит сами ошибки: каждый неверный вариант оказался правильным ответом на соседнюю функцию семейства DEF.

Три функции отличаются одним: откуда они берут измерения для расчёта.
• DEF: только из формулы. Что лежит в таблице, ей всё равно.
• DEF_ADD: измерения таблицы плюс те, что названы в формуле.
• DEF_SUB: измерения таблицы минус названные в формуле.

Возьмём условные цифры. Север: мебель 100, техника 300. Юг: мебель 200, техника 400.

✅ Верный ответ (11 голосов): продажи региона, одинаковые во всех его категориях. Таблица даёт Регион и Категорию, формула вычитает Категорию, остаётся Регион. В обеих строках Севера будет 400, в обеих строках Юга 600.

«Продажи категории по всем регионам» (3 голоса) так считает DEF(SUM_AGG(Продажи),[Категория]). DEF берёт только названное измерение: мебель 300, техника 700 в каждом регионе. Ошибка понятная: у DEF измерение в скобках - то, по которому считают, у DEF_SUB - то, которое выбрасывают.

«Как обычный SUM_AGG» (3 голоса) даёт DEF_ADD(SUM_AGG(Продажи),[]): измерения таблицы без добавок, в строках 100, 300, 200 и 400.

«Общие продажи по всей таблице» (1 голос) даёт DEF(SUM_AGG(Продажи)) без измерений: 1000 во всех строках.

Зачем DEF_SUB, если есть DEF? Он следует за таблицей. Добавьте в неё Месяц, и та же формула начнёт считать по Региону и Месяцу, а DEF(SUM_AGG(Продажи),[Регион]) останется по региону. В справке FineBI так считают средние продажи на регион по кварталам: в таблице Квартал и Регион, формула DEF_SUB(SUM_AGG(Продажи),[Регион])/DEF(COUNTD_AGG(Регион)). Первая часть считает продажи квартала без разбивки на регионы, вторая считает регионы во всей таблице.

Запомнить просто: SUB значит «вычесть». Всё, что в скобках у DEF_SUB, из расчёта уходит.

Какую из трёх DEF-функций вы используете чаще и где она вас подводила? Расскажите в @FineBIChat

Подробности - в справке FineBI: https://help.fanruan.com/finebi-en/doc-view-1990.html

#FineBI #FanRuan #DEF #формулы #викторина #аналитикаданных

FineOps 2.40.0: бэкапы проектов больше не привязаны к диску сервера

Когда бэкапы проектов съедают диск сервера FineOps, выход до сих пор был один: расширять физический диск или перемонтировать каталог. В Китае вышла FineOps 2.40.0, и в ней это наконец решается настройкой.

Место хранения бэкапов теперь задаётся самостоятельно, в том числе можно писать их в собственное хранилище S3. Раньше копии лежали в смонтированном каталоге на сервере FineOps, и нехватка места превращалась в работу с дисками.

Второе изменение для тех, кто разворачивает FineOps в корпоративной сети. При развёртывании нового проекта и при добавлении узла к существующему можно указать BIP узла. Это IP-адрес стандартного моста Docker docker0, через который контейнеры без своей сети получают адреса. Если подсеть по умолчанию уже занята, раньше развёртывание могло упасть. Теперь адрес выбирают заранее.

Проверка ресурсов при добавлении и расширении компонентов стала мягче: узлу достаточно 7/8 от оценки. Компонент, которому по оценке нужно 8 ГБ памяти, встанет на узел с 7 ГБ свободной. Но запас в 1/8 касается только оценки, а не работы: после развёртывания за CPU, памятью и состоянием компонентов нужно следить, при постоянной нехватке добавлять ресурсы.

И системная проверка FineOps научилась смотреть проекты FineDataLink:
- рекомендуемое число ядер для контейнера FineDataLink выросло с 6 до 8;
- новая проверка смотрит, хранит ли FineDataLink журналы в Elasticsearch, и советует переключиться на него, чтобы избежать проблем с производительностью и падений.

Это релиз про эксплуатацию, а не про новые возможности. Самое ценное в нём - S3: резервная копия на диске самого сервера FineOps зависит от этого диска, а своё хранилище её от него отвязывает. Смягчённая проверка ресурсов, наоборот, упрощает развёртывание ценой лишней обязанности следить за узлами после него.

Описание релиза на сайте вендора: https://help.fanruan.com/fineops/doc-view-249.html

#FineOps #FineDataLink #FanRuan #DevOps #бэкап #BI

#дайджест

Всем привет! Главная тема недели: подключить LLM к данным просто, трудно объяснить ей, что эти данные значат. Об этом говорили в Лондоне на Big Data LDN, туда же ведёт новый шаг Dora. А в аналитике напомнили о старой ловушке: неуникальный ключ тихо умножает итоги.

🛠 Администраторам
• Ucell перешла с Apache Superset на FineBI. Самое полезное в кейсе - эксплуатация: в марте из-за сбоя в очистке версий начал расти объём данных, и на сервере стало заканчиваться место. Причину нашли, политики хранения и очистки настроили. Следующий шаг Ucell - переход с 6.1 на 7.0.

📊 Аналитикам
• Объединение таблиц размножает показатели при неуникальном ключе. Левое объединение в FineBI работает как left join: остаток по SKU повторится в каждой строке заказа. Две таблицы фактов лучше связать в модели темы - она сначала агрегирует, потом соединяет.

💼 Тем, кто отвечает за BI
• Big Data LDN 2026: у корпоративного ИИ проблема с контекстом. Агенту мало доступа к таблице продаж: ему нужно знать, какой период закрыт, где возвраты и кому доступен срез. Иначе быстрый связный ответ придётся перепроверять с начала.
• ИИ не должен сам решать, что считать просрочкой. В Dora 1.1 источником агента может быть модельный набор показателей FineBI: модель понимает вопрос, а правила расчёта берутся из управляемого слоя.

💬 Из чата
• Водопад чистой прибыли @Ola_la_S получил продолжение: @sur_kenny добавил соединение конца и начала через сортировку dim_sort, «для красоты».
• Всё ещё без ответа: в выгрузке в Excel в FineBI 7 вместо 1.23 появляется 000, помогает только ручная смена формата ячейки. Если решали, подскажите @birekrust в чате.

🧩 Викторины недели
• Что покажет DEF_SUB(SUM_AGG(Продажи),[Категория])? Ответили 30, верно 17 (57%). Чаще ошибались на «продажи категории по всем регионам», а DEF_SUB убирает категорию, и остаются продажи региона.
• Что будет с суммой продаж после Left Join со справочником, где код повторяется? Ответили 30, верно 20 (67%). Шестеро решили, что сумма не изменится: Left Join сохраняет строки заказов, но повторяет каждую под каждым совпадением.

🏆 Самые активные за 30 дней
🥇 @Ola_la_S - вопросы, из которых вырос лучший водопад месяца
🥈 @sur_kenny - формулы почти на каждый вопрос и доработка водопада на этой неделе
🥉 @tipadima - три пути к логам FineBI в Elastic и свой скрипт

📅 23 октября - Fine Day 2026 в Москве
Тему этой недели продолжим офлайн: дискуссия ПИК, ДИКСИ, СИБУР и АвтоВАЗ о том, что нужно данным и командам, чтобы ИИ заработал, миграция с Qlik и Power BI, опыт Московской биржи и демо-зоны FineBI 7.0 и Dora, куда можно принести свою задачу. Участие бесплатное, после регистрации пришлём чек-лист «Готовы ли ваши данные к ИИ-агенту?». Регистрация

👇 Что разобрать подробно в следующем выпуске? Ставьте реакцию:
🔥 - как проверить уникальность ключа до объединения
👍 - модельный набор показателей для Dora
🤔 - чек-лист готовности данных к агенту

ИИ в аналитике: что происходит после красивого демо

На Smart Data 2026 в Ухане обсуждали не только то, как задать вопрос данным. Гораздо интереснее оказались кейсы о том, что происходит дальше: можно ли доверять ответу, кто заметит сбой и как превратить найденную проблему в действие. Вот несколько выступлений, которые это хорошо показывают.

«Гранд Трейд» начала с доверия к цифрам.Компания собрала единую модель данных и каталог, а затем развивала self-service в FineBI и FineReport. По данным выступления, активных пользователей аналитики стало в 3,1 раза больше - 376 человек, а дашборды заменили более 50 Excel-отчётов. Важен порядок: сначала договорились о данных, потом упростили работу с ними.

ОТП Банк применил ИИ к самой BI-платформе. При росте аудитории FineBI с 150 до более чем тысячи активных пользователей в месяц поддержку по-прежнему ведут три человека. Команда собрала операционный дашборд и подключила агентов для отслеживания проблем с обновлением данных. По словам спикера, поиск причины сбоя сократился с двух часов до пяти минут.

Китайские коллеги из JinkoSolar показали производственный сценарий на финале конкурса, проходившего в рамках конференции. В цехе по нарезке кремниевых пластин связали данные FineBI, правила из базы знаний и Dora: агент готовит отчёты, предупреждает об аномалиях и помогает искать причины обрывов режущей проволоки. Но решение о производственном действии остаётся за мастером или инженером - рекомендации ИИ требуют подтверждения. По данным команды, средний показатель обрывов снизился на 3,3%.

А в докладе «МЕТРО» прозвучал вопрос, объединяющий эти истории: кто внутри компании отвечает за то, чтобы ИИ применяли к подходящим задачам и не теряли контроль при масштабировании? Похоже, следующий этап для BI - не просто научиться отвечать быстрее, а встроить ответ в процесс, где его можно проверить и использовать.

Источники:
https://habr.com/ru/companies/glowbyte/news/1086624/
https://auth.fanruan.com/thread-154497-1-1.html

#SmartData2026 #FineBI #Dora #FanRuan #ИИ #BI

ИИ-агент отвечает настолько точно, насколько готовы ваши данные

Если у «выручки» три версии в разных отчётах, агент возьмёт одну и ответит уверенно. Как проверить данные заранее, разберём 23 октября в Москве на Fine Day 2026 - офлайн-конференции GlowByte по FineBI.

💡 В программе:
• Lance Lee, FanRuan: что сейчас происходит с ИИ
• ПИК, ДИКСИ, СИБУР и АвтоВАЗ: что нужно данным и командам, чтобы ИИ заработал
• Мосбиржа, ОТП и DataYoga: что закрывает BI, а что LLM, проверка данных через CI/CD, как учить команды
• демо-зоны FineBI 7.0 и агентов Dora: приносите свою задачу

📌 Пт 23.10, 14:00-21:00, Москва, бесплатно.
Приходите командой: заявку каждый подаёт сам, с рабочей почты. Проверка занимает 1-3 дня, подайте до 20 октября. Письмо не пришло - event@glowbyteconsulting.com

После заявки пришлём чек-лист «Готовы ли ваши данные к ИИ-агенту?»: 25 вопросов о метриках, доступах и доверии.

👉 Заявка: https://clck.ru/3WLLV9

#FineDay #FineBI #DORA #GlowByte

ИИ не должен сам решать, что считать просрочкой

Допустим, руководитель спрашивает: «Покажи долю просроченной задолженности по сегментам».

Если дать ИИ доступ к обычным таблицам, ему ещё предстоит самостоятельно понять:
- на какую дату брать остаток;
- какие договоры считать просроченными;
- включать ли реструктурированную задолженность;
- какой показатель использовать в знаменателе;
- как учитывать валютные договоры.

В результате можно получить безупречный график с неправильным бизнес-смыслом.

В DORA 1.1 появился более зрелый подход: источником данных для агента теперь может быть модельный набор показателей из FineBI. Это готовый бизнес-контур, в котором уже собраны нужные показатели и измерения, зафиксированы связи и правила расчёта.

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

И вот это уже действительно важное отличие от сценария «прикрутим чат к базе».

Большая языковая модель хорошо понимает вопрос пользователя. Но она не должна придумывать логику расчёта показателя. Эту часть лучше оставить управляемой модели данных:

пользователь формулирует вопрос → DORA понимает намерение → FineBI предоставляет согласованные показатели и измерения.

Так естественный язык становится новым способом работы с корпоративной аналитикой, а не альтернативным способом написать SQL.

Вторая доработка версии 1.1 касается поиска по дашбордам. DORA и раньше могла находить показатели в подключённых панелях и отвечать на вопросы по ним. Теперь настроенные для агента знания стабильнее учитываются в процессе поиска. Это позволяет дополнить цифры бизнес-правилами, терминологией и контекстом, которые не хранятся непосредственно в полях дашборда.

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

Главная фишка DORA 1.1 - не очередной способ задать вопрос данным. Это попытка связать ИИ с уже управляемой системой показателей:

модель понимает язык, а FineBI отвечает за бизнес-смысл цифр

На момент выхода версии 1.1 модельные наборы показателей находились в стадии внутреннего тестирования FineBI. Релиз опубликован 13 августа 2026 года и совместим с FineBI 7.0.8 и выше.

Подробнее о версии:
https://help.fanruan.com/dora-en/doc-view-77.html

#DORA #FineBI #FanRuan #ИИ #DataAgent #бизнесаналитика #GlowByte

Big Data LDN 2026: у корпоративного ИИ обнаружилась проблема с контекстом

23–24 сентября в Лондоне прошла Big Data LDN. Один из самых заметных сюжетов конференции - что должно находиться между LLM и корпоративными данными, чтобы агент не просто находил цифры, а понимал, какие из них можно использовать и что они означают. Теме контекста организаторы посвятили отдельную сцену: там обсуждают семантику, графы знаний, RAG и качество ответов.

К этой задаче вендоры подходят со своих сторон. BI-платформы хотят дать агентам доступ к уже описанным показателям и аналитическим моделям. Платформы данных - управлять доступом и работой с источниками. Каталоги данных развиваются в сторону слоя, который объясняет агенту связи между таблицами, происхождение данных и бизнес-термины. Это видно даже по тому, как участники выставки описывают свои продукты: Lightdash говорит о BI-агенте на основе семантического слоя dbt, Atlan - о передаче корпоративного контекста агентам, Collibra - о едином управлении данными, моделями и агентами.

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

В программе 23 сентября эту тему хорошо раскрывают два доклада - с разных сторон:

Хуан Секеда из ServiceNow говорит об онтологиях и графах знаний. Его фокус - не на том, как нарисовать ещё одну схему данных, а на более трудной задаче: как зафиксировать общее понимание данных в компании и не превратить создание семантической основы в бесконечный проект.

Рис Гриффитс из Deasy Labs смотрит на другую часть корпоративного контекста - документы. Если в хранилище лежат дубли, устаревшие инструкции и файлы с чувствительной информацией, передать всё это агенту «для полноты картины» - плохая идея. В анонсе доклада предлагается оценивать качество документов по тому, помогают ли они ИИ находить правильный ответ, а не только по формальным признакам качества данных.

Пожалуй, именно здесь сейчас и развивается индустрия. Способ подключить LLM к данным уже не самая интересная часть задачи. Гораздо важнее решить, какой контекст ей передавать, как поддерживать его актуальность и как проверить полученный ответ.

Единого подхода пока не видно - зато стало гораздо понятнее, почему одного чата поверх корпоративных данных недостаточно.

Те же вопросы продолжим обсуждать 23 октября в Москве на FineDay 2026 - уже применительно к реальным задачам корпоративной аналитики. На дискуссии «AI-Ready» поговорим о том, какие данные и бизнес-правила нужны агенту, кто отвечает за их подготовку и как проверить его ответ до того, как на его основе примут решение. А в демо-зоне можно будет посмотреть, как с данными работают ИИ-агенты Dora, и обсудить собственный сценарий с экспертами.
👉 Программа и регистрация.

#BigDataLDN #FineDay #ИИ #LLM #BI #DataGovernance #аналитикаданных

Объединение таблиц в FineBI размножает показатели при неуникальном ключе

Объединение таблиц «слева-справа» в FineBI выглядит как способ поставить две таблицы рядом. Работает оно как join по строкам, и при неуникальном ключе показатели копируются, а итог после суммирования выходит неверным.

На форуме FanRuan это всплыло в двух вопросах пользователей FineBI. В первом продажи хранятся построчно по заказам и уже сведены в среднедневные продажи по артикулу (SKU), а остатки лежат отдельной сводной таблицей по SKU, без заказов. Нужен отчёт об оборачиваемости запасов, но прямое объединение двух таблиц даёт проблемы. Во втором хотели показать рядом две таблицы показателей с одинаковыми измерениями.

Способы объединения в FineBI повторяют SQL: левое работает как left join, правое как right join, пересечение как inner join, полное как full join. Это объединение на уровне строк. Если значение ключа встречается несколько раз, строки второй таблицы копируются под каждое совпадение.

На примере из первого вопроса это видно сразу. В таблице остатков у артикула одна строка, а в продажах по заказам у того же артикула их столько, сколько было заказов. После объединения остаток повторится в каждой строке заказа, и сумма остатков по этому SKU умножится на число его заказов.

Копия измерения анализу не вредит. Копия показателя после суммирования даёт неверный итог. Хуже всего при связи «многие ко многим».

Ещё две детали ключа легко пропустить. Поля с одинаковыми именами FineBI сам добавляет в условие объединения. А пустые значения (null) в ключе друг с другом не совпадают, и строки с ними теряются. Источник предлагает заменить null, например, на «0». Я бы делал это осторожно: если пустых ключей с каждой стороны несколько или «0» уже встречается как настоящий код, замена сама даст «многие ко многим».

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

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

А когда оба показателя из одной таблицы, склейка не нужна совсем: в кросс-таблице задают измерение и кладут оба показателя рядом.

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

Вопросы на форуме FanRuan: https://bbs.fanruan.com/wenda/question/231737.html и https://bbs.fanruan.com/wenda/question/231767.html

#FineBI #FanRuan #BI #моделированиеданных #аналитикаданных #бизнесаналитика

Перейти с Apache Superset - не значит просто перенести дашборды

23 сентября вышла новость о том, как Ucell вместе с GlowByte Soft перешла с Apache Superset на FineBI.

И в этом кейсе интересно не само название новой платформы, а то, как принималось решение.

Когда компании выбирают замену BI, легко свести всё к сравнению интерфейсов и количества визуализаций. Но для Ucell главным критерием была функциональная преемственность: важно было сохранить сложную аналитику, LOD-выражения и табличные вычисления, работу с геоданными, а также интеграцию с Oracle, PostgreSQL и Hive. FineBI закрыл эти требования и дополнительно предложил гибкое управление ролями и рабочими пространствами.

Но выбор платформы оказался только началом.

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

А затем началась настоящая эксплуатация.

В марте 2026 года из-за сбоя в механизме очистки версий начал аномально расти объём хранимых данных. На сервере стало заканчиваться место. Команда GlowByte локализовала причину, восстановила работу системы и настроила политики хранения и очистки - хотя этот случай находился за пределами стандартного вендорского SLA.

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

Сегодня Ucell существенно расширила количество лицензий FineBI, а сотрудничество перешло в формат долгосрочной поддержки. Следующий этап - переход с FineBI 6.1 на версию 7.0.

Получился хороший пример того, из чего на самом деле складывается переход на новую BI-платформу:

функциональная преемственность → проверка архитектуры → интеграция → эксплуатация → поддержка → масштабирование

Не эффектное демо, а система, которая должна работать в реальном контуре.

Читайте полную историю проекта в материале UZA
https://uza.uz/ru/posts/glowbyte-soft-pomogla-ucell-pereyti-s-apache-superset-na-finebi_912355

#FineBI #Ucell #GlowByte #ApacheSuperset #BI #бизнесаналитика #миграцияBI #Узбекистан

#дайджест
Неделя, когда BI стал предсказуемее 🔍

Всем привет! Коротко о главном: FineBI научился точнее фильтровать и понятнее объяснять ошибки, FineOps - сам искать, где сломалась сеть, а мы честно поговорили о том, почему ИИ-агент не отменяет порядок в данных. В чате тем временем собрали водопад, которого нет в документации.

🛠 Администраторам
• FineBI 7.0.12 уже можно ставить. Фильтр по дате теперь с точностью до секунды: срез «каждый день на 08:00» больше не нужно изобретать. Плюс понятные ошибки при объединении Excel с базой и отдельное право на создание self-service тем.
• FineOps 2.39.0: сетевая диагностика и сбор логов FineBI, FineReport и FineDataLink одной операцией. Меньше переписки «это не у нас» между админами, инфраструктурой и поддержкой.

📊 Аналитикам
• Заглянули в китайский FineBI 7.0.13: скользящие средние и накопительные итоги без оконных функций, прямо в стандартной теме. А ещё поиск забытых дашбордов по автору и дате и их массовое удаление. Ждём международную версию.
• Как понять, что команда готова работать в FineBI: одна рабочая задача из пяти шагов, и всё ясно без анкет.

💼 Тем, кто отвечает за BI
• DORA не решит проблему доверия к BI. Агент отвечает уверенно, даже когда контекста нет, и в этом риск. Пять вопросов до пилота и запись FineTalk с Т2 и СИБУРом.
• Поддержка FineBI - это не только «написать вендору»: что можно отдать внешней команде, не отказываясь от вендора.

💬 Из чата
• История недели. @Ola_la_S нужен был водопад чистой прибыли, который перестраивается при выборе любых двух кварталов и проекта. В документации только статичный вариант, но уже на следующий день в чате появилось «Upd. Получилось🎉» с формулами. @sur_kenny тут же показал свой вариант, покороче.
• @Serg0fan666 спросил, как раскрасить сводную таблицу градиентом по строке. Из коробки градиента нет, но @sur_kenny собрал его из DEF-мер.
• Пока без ответа: при выгрузке в Excel в FineBI 7 вместо 1.23 появляется 000. Сталкивались? Подскажите @birekrust в чате.

🏆 Самые активные за 30 дней
🥇 @Ola_la_S - больше всех вопросов и лучший водопад месяца
🥈 @sur_kenny - отвечал формулами почти на всё
🥉 @tipadima - подсказал три пути к логам FineBI в Elastic и поделился своим скриптом

📚 Формулы @sur_kenny похожи на магию? Это DEF-функции. Разбираем их на онлайн-интенсиве для команд: DEF-ADD, DEF-SUB, DEF + EARLIER, три дня по 2-3 часа. Подробнее

👇 Что разобрать подробно в следующем выпуске? Ставьте реакцию:
🔥 - водопад по шагам
👍 - скользящие расчёты из 7.0.13
🤔 - как готовить данные к DORA