Щоденне зведення керівнику з кількох систем: як побудувати надійний ШІ-звіт

Коротка відповідь: надійне щоденне зведення починається не з моделі, а з погоджених метрик і перевірених даних. Розрахунки і агрегати виконує код, який можна перевірити і відтворити. Модель лише пояснює вже пораховані числа людською мовою. Якщо якесь джерело недоступне або не оновилося, читач звіту має це бачити, а не отримувати вчорашнє значення під виглядом сьогоднішнього.

Головна умова: неповні або недоступні дані не є нулями. Часовий пояс, валюта і словник метрик фіксуються до першого звіту. Після статті ви зможете описати процес зведення з п'яти джерел, визначити перевірки якості даних, розділити в шаблоні факт, інтерпретацію і рекомендацію та налаштувати поведінку звіту при збоях.

П'ять джерел і один словник

Типове щоденне зведення для операційного керівника або власника збирає дані з кількох систем. Для цієї статті візьмемо п'ять умовних джерел:

• CRM: нові ліди, угоди за етапами, оплачені угоди.
• Реклама: витрати, покази, кліки, заявки з рекламних каналів.
• Платежі: надходження коштів за період.
• Підтримка: нові звернення, вирішені звернення, час першої відповіді.
• Облік: виставлені рахунки, дебіторська заборгованість.

Головна проблема таких зведень не технічна. Різні системи по-різному рахують одне й те саме. «Лід» у рекламному кабінеті та «лід» у CRM можуть бути різними сутностями. «Вчора» для сервера в UTC і для керівника в Києві закінчується в різний час. «Оплата» в CRM означає позначку менеджера, а в платіжній системі фактичне надходження.

Тому перший артефакт проєкту: словник метрик. Для кожного показника в ньому записано:

• Назва і визначення: що саме рахується, словами, зрозумілими керівнику.
• Джерело: з якої системи і якої таблиці чи звіту береться значення.
• Формула: як рахується, включно з фільтрами (наприклад, без тестових угод).
• Період: календарна доба в конкретному часовому поясі, тиждень з понеділка, місяць.
• Валюта: у якій валюті показується і за яким курсом та на яку дату перераховується, якщо джерела в різних валютах.
• Статуси: які статуси вважаються «оплачено», «закрито», «вирішено».
• Відповідальний: хто може змінити визначення.

Словник погоджується з керівником, для якого будується звіт. Без цього модель чесно пояснюватиме числа, які кожен читач розуміє по-своєму.

Отримання вихідних даних

Дані можна отримати кількома способами, і вони суттєво відрізняються за надійністю.

API систем. Найкращий варіант для регулярного процесу. Ви отримуєте структуровані значення з полями, ідентифікаторами і часовими мітками. Можна контролювати фільтри і повторювати запит.

Вивантаження файлів. Таблиці, які система формує за розкладом або вручну. Прийнятно, якщо формат стабільний і є контроль, що файл свіжий і повний.

Сховище даних. Якщо в компанії вже є сховище, куди збираються дані з систем, зведення краще будувати з нього. Тоді перевірки якості і визначення метрик живуть в одному місці.

Скриншоти дашбордів. Технічно модель може «прочитати» число з картинки, але для щоденного процесу це найслабший варіант. Точні значення з таблиць у вигляді зображень можуть вилучатися ненадійно, тому коли важлива точність, використовуйте структуровані таблиці або текстові файли. До того ж на скриншоті не видно фільтрів, періоду і часу оновлення.

Окремо варто продумати час збору. Системи оновлюють дані з різною затримкою: рекламні кабінети можуть уточнювати витрати за попередній день ще кілька годин, платіжна система може передавати надходження пакетами, а менеджери закривають угоди в CRM із запізненням. Якщо зібрати дані о 06:00, частина вчорашніх значень ще може змінитися. Тому в словнику для кожного джерела корисно записати, коли дані за добу вважаються стабільними, і формувати звіт після цього часу або прямо позначати попередні значення як попередні.

Корисне правило: кожне значення в зведенні має бути простежуване до конкретного запиту до конкретного джерела з конкретним періодом. Якщо цього не можна показати, значення не варто включати.

Контроль якості

Між отриманням даних і розрахунком варто поставити перевірки. Вони виконуються кодом, а результат кожної перевірки впливає на те, що побачить читач.

Типові перевірки:

• Дублікати. Один лід чи платіж не повинен рахуватися двічі. Перевіряється унікальність ідентифікаторів.
• Пропуски. Обов'язкові поля (сума, дата, статус) заповнені. Записи з пропусками рахуються окремо, а не мовчки відкидаються.
• Допустимі значення. Статуси з дозволеного списку, суми невід'ємні, дати в межах періоду.
• Зв'язки. Оплата посилається на угоду, яка існує в CRM.
• Свіжість. Коли джерело оновлювалося востаннє. Якщо система платежів не отримувала нових даних з учорашнього ранку, запит до неї може технічно пройти успішно, але повернути застарілі дані.
• Валюта і часовий пояс. Значення в різних валютах не додаються без перерахунку. Дати приводяться до одного часового поясу до групування за днями.

Інструменти для перетворення даних, як-от dbt, мають готові перевірки саме такого типу: унікальність, заповненість, допустимі значення, зв'язки між таблицями, а також контроль свіжості джерел. Якщо ваша команда вже використовує подібний інструмент, перевірки варто додати туди, а не дублювати в коді звіту.

Результат перевірок не лише блокує або пропускає дані. Він потрапляє у зведення як частина фактів: «у даних CRM знайдено 3 записи без суми, вони не включені в розрахунок».

Розрахунок показників

Усі розрахунки виконуються до того, як дані передаються моделі. Модель отримує вже пораховані значення, їхні визначення і результати перевірок.

Чому не варто просити модель рахувати самостійно:

• Відтворюваність. Код дає той самий результат на тих самих даних. Відповідь моделі може відрізнятися між запусками.
• Перевірюваність. Формулу в коді можна прочитати і протестувати. Розрахунок усередині відповіді моделі перевірити складно.
• Масштаб. Суми і середні по тисячах рядків надійніше рахувати кодом, ніж передавати рядки в контекст моделі.

Навіть коли модель сама пише і виконує код аналізу, як це вміють деякі інструменти, відповідальність за перевірку залишається за людиною. Перш ніж покладатися на висновок, людина має переглянути згенерований код, результати й припущення. Для щоденного процесу простіше один раз написати і перевірити розрахунки, ніж щодня перевіряти нові.

Що передається моделі:

• значення показників за поточний і порівняльний період;
• визначення кожного показника зі словника;
• результати перевірок якості і свіжості;
• перелік недоступних джерел;
• правила формулювань: що можна стверджувати як факт, а що лише як можливе пояснення.

Зведення з доказами

Корисне зведення чітко розділяє три типи тверджень.

Факт. Число з джерелом, періодом і формулою. «Нових лідів у CRM за 10.10: 120».

Інтерпретація. Можливе пояснення зміни, явно позначене як гіпотеза. «Можлива причина: рекламна кампанія, запущена 09.10. Потребує перевірки». Модель не повинна стверджувати причинно-наслідковий зв'язок без аналізу.

Рекомендація. Що варто перевірити або зробити і хто відповідальний. «Перевірити з маркетингом, чи змінилися налаштування кампанії».

Нижче навчальний приклад. Усі числа вигадані для пояснення.

Навчальне зведення за 10.10 (дані на 08:00 за київським часом)

Як має звучати текст зведення для останнього рядка: «Дані про надходження коштів за 10.10 недоступні: система платежів не оновлювалася з 09.10, 06:00. Відповідальний за інтеграцію сповіщений». Як не має звучати: «Надходження впали до нуля» або «Надходження залишилися на рівні вчорашнього дня». Обидва варіанти вигадують факт.

Кожен рядок зведення в повній версії містить посилання на звіт у системі-джерелі, щоб керівник міг перевірити число одним кліком, і ім'я відповідального за показник.

Помилки і доставка

Щоденний процес обов'язково колись зіткнеться зі збоєм. Важливо заздалегідь визначити, як поводиться звіт.

Недоступне або застаріле джерело. Звіт формується як частковий. Читач бачить, яке джерело недоступне, дату останніх даних і що з цього не можна порахувати. Показники, які залежать від недоступного джерела, не розраховуються з підставленими значеннями.

Невдалі перевірки якості. Якщо перевірка критична (наприклад, масові дублікати платежів), показник не публікується, а в звіті з'являється пояснення. Якщо некритична, показник публікується з приміткою.

Позначка часткового звіту. На початку зведення одним рядком: «Звіт неповний: недоступні дані платежів». Керівник не повинен шукати це в кінці тексту.

Повторна доставка. Якщо звіт перегенеровано після виправлення даних, нова версія позначається як оновлена, з часом і переліком змін. Два різні звіти за одну дату без позначки створюють плутанину: незрозуміло, якому вірити.

Журнал. Для кожного звіту зберігаються вхідні дані, результати перевірок, пораховані значення, текст моделі і час доставки. Це дозволяє відповісти на питання «чому у звіті було це число» через тиждень.

Відповідальний за збої. Конкретна людина отримує сповіщення, коли джерело недоступне або перевірка не пройдена, і має інструкцію, що робити.

Висновок

ШІ-зведення для керівника надійне тоді, коли модель працює в кінці ланцюжка: після погодження метрик, отримання структурованих даних, перевірок якості і розрахунку кодом. Модель формулює пояснення, але не рахує і не вигадує причин. Недоступні дані показуються як недоступні.

Що можна зробити на своєму процесі:

1. Складіть словник метрик для зведення: визначення, джерело, формула, період, часовий пояс, валюта, статуси і відповідальний. Погодьте його з керівником.
2. Для кожного джерела оберіть спосіб отримання даних: API, вивантаження або сховище. Відмовтеся від скриншотів дашбордів як основного джерела.
3. Додайте перевірки: дублікати, пропуски, допустимі значення, зв'язки, свіжість, валюта і часовий пояс.
4. Перенесіть усі розрахунки в код і передавайте моделі лише пораховані значення, визначення і результати перевірок.
5. Затвердіть шаблон зведення, де факт, інтерпретація і рекомендація розділені, а кожна цифра має джерело, період і формулу.
6. Визначте поведінку при збоях: частковий звіт з позначкою на початку, позначення оновлених версій, журнал і відповідальний за сповіщення.

Якщо вам потрібне щоденне зведення з кількох систем, якому можна довіряти, команда BotLabs може розібрати це з вами на 15-хвилинній консультації. Обговоримо, з яких систем береться кожен показник, які визначення потрібно погодити і як звіт має поводитися, коли джерело недоступне. Наступним кроком визначимо, з якого набору метрик почати.

Часті запитання