Руководитель просит «сделать дашборд по доставке», а аналитик не знает, какие цифры должны повлиять на решение. ИИ для дашбордов полезен уже на этом этапе: он помогает сформулировать рабочий вопрос, разобрать определения метрик и подготовить ТЗ для BI-команды. Начните со смысла панели и источников данных, а не с выбора красивого графика.
С какого рабочего вопроса начинается дашборд
Хороший дашборд отвечает на повторяющийся вопрос конкретного человека. Например, директор по операциям каждую неделю решает, где требуется разбор просроченных доставок. Ему недостаточно общего числа заказов: нужны доля доставок в срок, изменение по неделям, регионы с отклонениями и путь к деталям. В рекомендациях Microsoft по проектированию Power BI первым стоит вопрос об аудитории и ключевых показателях, которые помогают ей принимать решения.
Перед диалогом с ИИ заполните короткий бриф:
| Вопрос | Пример для службы доставки |
|---|---|
| Кто смотрит? | Операционный директор и руководители регионов |
| Какое решение принимают? | Выбрать регион и причину для разбора на еженедельной встрече |
| Как часто обновляется панель? | Каждое утро; решение принимается раз в неделю |
| Что считается отклонением? | Порог согласуют с владельцем процесса; его нельзя придумать по выборке |
| Куда перейти за деталями? | Список заказов и причин задержки с правами доступа по роли |
Промпт для первого прохода:
Ты помогаешь сформулировать ТЗ для BI-команды. Читатели: операционный директор и руководители регионов. Цель: еженедельно находить причины просроченных доставок. Задай вопросы о решениях, метриках, периодах, фильтрах и источниках. Не предлагай графики, пока определения показателей не согласованы.
Такой запрос полезнее, чем «нарисуй современный дашборд». ИИ вынесет неизвестное наружу. Владелец процесса ответит на вопросы, после чего аналитик сможет выбрать данные и визуальную структуру.
Начните с вопроса руководителя; определения показателей и критерии приёмки закрепите до разработки.
Как описать метрики и структуру данных
Название колонки ещё не означает согласованную метрику. Поле delivered_at хранит момент события; «доля доставок в срок» требует формулы, периода, набора заказов и правил исключения. Если один отдел исключает отменённые заказы, а другой включает их в знаменатель, два правильных вычисления дадут разные значения.
Для каждого показателя попросите ИИ собрать «паспорт метрики»:
| Поле паспорта | Что зафиксировать |
|---|---|
| Название и вопрос | «Доля доставок в срок»; где сроки ухудшились? |
| Определение и формула | Числитель, знаменатель, условие «в срок», исключения |
| Единица и точность | Процент, правило округления |
| Период и часовой пояс | Неделя по дате доставки или оформления заказа; локальное время или единая зона |
| Срезы | Регион, тип доставки, канал; какие из них реально доступны |
| Источник и владелец | Таблица заказов, справочник регионов, ответственная команда |
| Обновление и контроль | Время загрузки, сверка с операционным отчётом |
Зерно таблицы — то, что представляет одна строка. Если строка означает событие изменения статуса, один заказ может встречаться несколько раз. Сумма amount по такой таблице удвоит выручку, если её не агрегировать по заказу. Передайте ИИ описание зерна и связей между таблицами; попросите указать возможные ошибки объединения и вопросы к владельцу данных. Формулу и итоговые числа утверждает аналитик на полном наборе.
Возьмём учебный расчёт. За неделю было 100 завершённых доставок, из них 84 прошли до обещанного клиенту времени: доля равна 84%. Но что делать с двумя заказами, у которых поле обещанного времени пусто? Если исключить их из знаменателя, результат изменится; если считать просроченными — тоже. В ТЗ должно быть отдельное правило для таких строк. Кроме того, неделя может определяться по дате создания заказа или по дате фактической доставки. Эти варианты отвечают на разные вопросы, поэтому ИИ должен перечислить оба, а владелец процесса выбрать один.
Проверь словарь полей и определения показателей ниже. Для каждой предложенной метрики выведи формулу, зерно, период, фильтры, возможные дубли и вопрос к владельцу данных. Не рассчитывай итоговые KPI, если определений или полного набора нет. [Словарь полей и бизнес-правила.]
В современных BI-системах модели данных и бизнес-определения тоже становятся опорой для ИИ. Например, Google описывает, как словари терминов, описания колонок и семантическая модель помогают диалоговой аналитике соотносить пользовательский вопрос с нужными полями. Обычный чат без доступа к вашей модели данных такой опоры не имеет: её нужно предоставить в брифе.
Какие графики выбрать для решения, а не для украшения
Попросите ИИ предложить несколько компоновок после согласования метрик. Каждая визуализация должна отвечать отдельному вопросу. Для доставки это могут быть:
| Вопрос | Подходящая форма | Что проверить |
|---|---|---|
| Выполнен ли целевой уровень? | Карточка KPI с целевым значением и периодом | Не смешаны ли недели и месяцы |
| Когда началось ухудшение? | Линия по неделям | Одинаковы ли состав заказов и правила расчёта |
| Где отклонение сильнее? | Горизонтальные столбцы по регионам | Есть ли достаточный объём заказов в каждом регионе |
| Какие заказы требуют разбора? | Таблица деталей с фильтрами | Кому разрешено видеть идентификаторы клиентов |
Один экран может показать общий статус и точки входа в детали; всё остальное оставьте в отчёте. Microsoft рекомендует не перегружать панель и выбирать формы по данным, а не ради разнообразия. Для сравнения категорий обычно легче читать столбцы, чем 3D-диаграмму или набор круговых графиков (руководство Power BI).
Сравните два макета в тексте: вариант A ставит четыре KPI наверху, линию тренда под ними и таблицу проблемных регионов справа; вариант B начинает с карты регионов. Если директор сначала проверяет общую динамику, A может быть удобнее; если решение территориальное, B стоит тестировать. Попросите ИИ объяснить, на какой вопрос отвечает каждый блок и что пользователь сделает после просмотра. Так макет становится проверяемой гипотезой, а не вопросом вкуса.
Можно ли загрузить только фрагмент большой таблицы
Да, если задача — понять структуру полей и подготовить вопросы для ТЗ. Передайте словарь колонок и небольшой обезличенный фрагмент с типичными строками и краевыми случаями: пропущенная дата, отменённый заказ, повторный статус, разные регионы. Случайные первые пять строк часто скрывают проблему. Фрагмент помогает ИИ предложить варианты группировки и графиков, но не даёт права считать показатели для всего бизнеса.
Например, опишите колонки order_id, region, promised_at, delivered_at, status, status_changed_at. Укажите, что каждая строка — событие статуса, а не заказ. Если показать три строки одного заказа, модель должна предупредить о риске двойного счёта. Если регион в части строк пуст, нужно узнать правило восстановления, а не автоматически подставлять соседний.
Попросите аналитика собрать демонстрационный фрагмент намеренно: одну обычную доставку, одну просроченную, одну отменённую, заказ с двумя событиями статуса и запись с пустым регионом. Впишите в запрос число строк полного набора и период, из которого взят фрагмент. Тогда модель может обсуждать структуру и пограничные условия, не притворяясь, что пять строк представляют весь месяц. Идентификаторы клиентов, адреса и телефоны для такого обсуждения не нужны.
Ниже словарь полей и учебная выборка из таблицы событий. Определи, какие вопросы о структуре и качестве данных нужно закрыть до расчёта доли доставок в срок. Предложи подходящие виды графиков и поля для них. Не вычисляй показатели по всей компании из фрагмента; пометь, каких данных и правил не хватает.
Большую рабочую таблицу загружайте только в разрешённый контур с нужными правами. Для обсуждения макета часто хватает схемы полей и обезличенных примеров. После согласования структуры BI-команда проверит реальные распределения, пропуски и аномалии на полном наборе. Даже в специализированном Copilot для Power BI ответы зависят от видимых данных и устройства модели: в документации Microsoft отдельно описаны ограничения при плотных таблицах и выборке. Тем более нельзя принимать вывод обычного чата по маленькому фрагменту за аудит данных.
Как превратить разговор с ИИ в ТЗ для BI-команды
ТЗ должно позволять аналитикам построить панель и понять, когда задача выполнена. Перенесите из переписки согласованные определения в документ, а неизвестное оставьте открытым вопросом с ответственным. Не выдавайте предложенную ИИ формулу за утверждённую.
Минимальный шаблон:
- Пользователи и решения. Кто читает панель, как часто и какие действия предпринимает.
- Источники. Таблицы, владельцы, зерно строк, связи, доступы и частота обновления.
- Метрики. Формулы, единицы, периоды, часовой пояс, фильтры, исключения и контрольные значения.
- Макет. Для каждого блока: вопрос пользователя, тип графика, поля, сортировка, переход к деталям.
- Сценарии проверки. Контрольный период, несколько заказов с известным статусом, граничные случаи и сверка с текущим отчётом.
- Приёмка. Владелец бизнеса подтверждает смысл и интерфейс, аналитик — расчёты и качество данных, администратор — права доступа.
На основе согласованного брифа и словаря полей собери черновик ТЗ по этим шести разделам. Для каждой метрики покажи источник правила и отметь «требует решения», если формула или владелец не согласованы. Добавь вопросы к BI-команде и проверочные примеры. Не придумывай отсутствующие поля.
На встрече с BI-командой покажите не только сгенерированный макет, но и список спорных определений. Например, «доставлено вовремя» может считаться по обещанному времени для клиента или внутреннему нормативу склада. Если этот выбор не сделан, график будет выглядеть уверенно при ошибочной постановке задачи.
Приёмку тоже можно описать через два-три известные записи. Заказ, доставленный на минуту раньше обещанного времени, должен попасть в числитель; доставленный позже — нет; отменённый должен обрабатываться по утверждённому правилу исключений. Проверьте расчёт вручную на этих записях, затем на агрегате за контрольную неделю. Отдельно попросите будущего пользователя пройти путь от общей карточки KPI до конкретного заказа: если он теряется, даже верная цифра не помогает принять решение.
Что показывают два англоязычных кейса
В кейсе Sabancı Holding (Microsoft, май 2025 года) группа компаний сначала объединила данные разных бизнесов в Microsoft Fabric и использовала Power BI для визуализации. Copilot помогает аналитической подготовке, а интерпретацию результатов и стратегические решения делают сотрудники. Для заказчика дашборда здесь полезен порядок: общий слой данных и определения появляются раньше выводов ИИ.
В кейсе Virtua Health (Microsoft, апрель 2026 года) организация свела разные источники в единую среду Fabric, а Copilot поверх Power BI помогает представлять резюме человеческим языком. Это иллюстрирует второй шаг: после модели данных и визуализации можно добавить текстовое объяснение для читателя. Кейс не подтверждает, что обычный чат сам построит рабочую панель из файла или что созданное резюме можно принять без специалиста.
Оба материала опубликованы поставщиком платформы, поэтому воспринимайте их как описания конкретных внедрений, а не как универсальный прогноз эффекта. Для своего проекта измерьте, быстрее ли руководитель находит нужный регион, реже ли аналитик вручную объясняет показатель и совпадают ли значения с утверждённым отчётом.
FAQ
Может ли ИИ сам выбрать все KPI для дашборда?
Он предложит кандидатов и вопросы к данным. Бизнес-владелец утверждает, какие решения важны; аналитик проверяет формулы, источники и сопоставимость периодов.
Нужно ли загружать всю таблицу в чат?
Для брифа и макета обычно достаточно схемы полей, правил расчёта и обезличенной выборки с граничными случаями. Полный набор нужен для проверки качества данных и значений метрик в разрешённой аналитической среде.
Чем ТЗ отличается от HTML-прототипа дашборда?
Прототип показывает возможный экран. ТЗ фиксирует источники, определения, доступы, обновление и критерии приёмки, без которых красивый экран может показывать неверные цифры. Для создания HTML-прототипа есть отдельная подборка промптов.
Как проверить, что график полезен?
Дайте будущему пользователю конкретный вопрос: «В каком регионе на этой неделе ухудшилась доставка и какие заказы нужно разобрать?» Если он не может ответить по панели или не понимает период и формулу, измените макет или подписи до разработки.
Начните с одного решения и двух-трёх метрик, которые его поддерживают. В Agent Roi можно подготовить бриф, сравнить варианты структуры и собрать черновик ТЗ; затем согласуйте определения с владельцами данных и передайте проверенный документ BI-команде.
Больше материалов по теме — в разделе «Данные, Excel и аналитика».
