Build reliable operational analyticsКак построить надёжную аналитику
Reliable analytics starts before a chart is drawn. Agree what an event means, which system supplies it and when a period is closed. Then prove that a small sample survives the full path from record to decision.Надёжная аналитика начинается до графика. Договоритесь о смысле события, его источнике и моменте закрытия периода. Затем проверьте на небольшой выборке весь путь от записи до решения.
The business questionРабочий вопрос
Create a metric contract containing name, owner, business question, source, event time, cutoff, numerator, denominator, exclusions and version. Choose a business time zone and a rule for late events. Never silently mix event time with import time.Создайте паспорт показателя: название, владелец, вопрос, источник, время события, граница периода, числитель, знаменатель, исключения и версия. Выберите рабочий часовой пояс и правило поздних событий. Не смешивайте незаметно время события и загрузки.
Metric definitions and scopeОпределения и состав показателей
Source reconciliation differenceРасхождение с источником
Report total minus the authoritative source total for the same status, period and currency. Explain differences by identified records; do not force the number to zero with an undocumented adjustment.Итог отчёта минус итог первичного источника при одинаковых статусе, периоде и валюте. Объясняйте расхождение конкретными записями; не обнуляйте его недокументированной поправкой.
Valid-record coverageПолнота корректных записей
Eligible records passing required ID, status and timestamp checks ÷ all eligible source records for the run. Quarantined records remain visible in the denominator.Подходящие записи, прошедшие проверку номера, статуса и времени ÷ все подходящие исходные записи запуска. Отложенные из-за ошибок остаются видимыми в знаменателе.
Freshness lagЗадержка обновления
Snapshot time minus the latest confirmed complete source watermark. The newest single event is not proof that the source is complete through that time.Время снимка минус последняя подтверждённая полная граница данных источника. Одно самое новое событие не доказывает полноту источника до этого времени.
A worked exampleПример расчёта
Illustrative run: a source contains 100 eligible orders. Ninety-eight pass required field checks; two lack valid timestamps. Coverage is 98%. The report may show the 98 valid records with a warning, but it must not claim a fully reconciled day.Условный запуск: источник содержит 100 подходящих заказов. У 98 корректны обязательные поля, у двух нет допустимого времени. Полнота — 98%. Отчёт может показать 98 записей с предупреждением, но не полностью сверенный день.
A late return recorded for yesterday arrives after the daily cutoff. Apply the agreed correction policy, retain the previous report version and show the return as the reason for the revision. An import rerun must not duplicate that return.Поздний возврат за вчера приходит после закрытия дня. Примените согласованное правило исправления, сохраните прежнюю версию и укажите возврат как причину пересчёта. Повторная загрузка не должна дублировать возврат.
Exceptions that change the readingИсключения, меняющие вывод
Source status meanings can change after an integration update. Treat an unfamiliar status as an unresolved mapping, not as a completed sale. Test new mappings on records before changing production totals. Keep evidence of who approved the definition.После обновления интеграции может измениться смысл статусов. Незнакомый статус — нерешённое соответствие, а не завершённая продажа. Проверяйте новые соответствия на записях до изменения итогов. Сохраняйте, кто согласовал определение.
Owner and operational decisionОтветственный и решение
The metric owner approves meaning; the data operator owns the run; the business reviewer accepts reconciliation. When these roles disagree, mark the report provisional and resolve the specific definition instead of allowing two competing versions of the same KPI.Владелец показателя утверждает смысл, оператор данных отвечает за расчёт, бизнес-проверяющий принимает сверку. При разногласии помечайте отчёт предварительным и согласуйте определение, не оставляя две конкурирующие версии одного KPI.
Acceptance checksПроверки приёмки
- A rerun with identical inputs produces the same totals and record count.Повторный расчёт на тех же данных даёт те же суммы и количество.
- A late event creates an explainable revision without duplication.Позднее событие создаёт объяснимую новую версию без дубля.
- A rejected record remains discoverable with its validation reason.Отклонённая запись доступна с причиной ошибки проверки.
Map the workflow to SABSUSСопоставьте процесс с SABSUS
Map each contract field to the records and export options actually available in SABSUS. Confirm update frequency and integration behavior. External transformations or a separate reporting layer may be needed; this playbook is not a claim of a built-in data warehouse.Сопоставьте поля паспорта с реально доступными записями и выгрузками SABSUS. Уточните частоту обновления и поведение интеграций. Могут потребоваться внешняя обработка и отдельная отчётность; этот регламент не означает встроенное хранилище данных.
Quick answersКороткие ответы
Which time should define the reporting day?Какое время определяет день отчёта?
Use the declared business event time and time zone, with a separate late-event policy.Заявленное время рабочего события и часовой пояс, с отдельным правилом поздних событий.
Can an invalid record simply disappear?Можно просто убрать некорректную запись?
No. Keep its identity, reason and effect on coverage visible.Нет. Сохраните номер, причину и влияние на полноту.
When is a report ready for decisions?Когда отчёт пригоден для решений?
When its scope, freshness and reconciliation status are understood and accepted by its owner.Когда владелец понимает и принимает его состав, свежесть и состояние сверки.