На нараді дві команди показують різну кількість виконаних замовлень. Перша рахує замовлення за датою створення, друга за датою завершення. Обидва звіти можуть правильно виконувати свої правила, але відповідати на різні питання. Цей умовний приклад показує, чому виправлення варто починати з визначення показника, а не з формули на екрані.
Сформулюйте питання без назви звіту
«Скільки замовлень команда завершила протягом місяця?» і «Що сталося із замовленнями, прийнятими цього місяця?» потребують різних наборів. Погодьте, яке рішення залежить від відповіді: оцінювання навантаження, контроль незавершених робіт чи планування наступного періоду.
Запишіть подію, одиницю підрахунку, період і статус. Для кожного слова наведіть приклад запису, який входить до набору, та приклад, який не входить. Так суперечка про правильність графіка перетворюється на перевірку умов.
Зрівняйте деталізацію до порівняння
Один рядок може означати замовлення, товарну позицію або зміну статусу. Після приєднання історії статусів одне замовлення може повторитися. Випадкове застосування DISTINCT приховає симптом, але не пояснить, який запис потрібен.
Документація Microsoft про зіркову модель розрізняє факти та виміри й наголошує на послідовній деталізації фактів. Для нашої перевірки це означає: спочатку визначити, що саме представляє рядок, потім обирати спосіб підрахунку. Це принцип моделювання, а не вимога використовувати конкретний BI-продукт.
Зведіть розбіжність до конкретних записів
Візьміть однаковий зріз джерел і зафіксуйте час вивантаження. Порівняйте ідентифікатори: що є лише у першому наборі, лише у другому та в обох. Для кожної групи перевірте дату події, статус і правила виключення.
У нашому прикладі замовлення створене наприкінці одного місяця, а завершене на початку наступного. Воно має різне місце у двох звітах. Після узгодження питання ця різниця стає поясненою, а не помилкою, яку потрібно приховати.
| Перевірка | Питання | Доказ |
|---|---|---|
| Період | Яка подія визначає дату? | Запис на межі двох місяців |
| Деталізація | Що представляє один рядок? | Ідентифікатор та повтори після об’єднання |
| Свіжість | Які джерела вже надійшли? | Час і склад останнього завантаження |
Приймання має залишити відтворюваний доказ
Збережіть визначення, вибірку, очікуваний результат і погодження власника показника. Окремо вирішіть, чи перераховувати історію після зміни правила. Нове визначення не варто непомітно змішувати зі старими значеннями.
E-Data Consulting починає пілот аналітики з такого протоколу. Джерела можуть бути в A5.ERP або інших системах; доступні поля, спосіб отримання й періодичність перевіряємо для конкретної конфігурації. Наступний крок: обрати одну розбіжність і пройти шлях до первинного запису.
Питання та відповіді
Чи потрібно залишати лише один звіт?
Ні. Різні рішення можуть потребувати різних зрізів. Потрібні зрозумілі назви й визначення, щоб їх не порівнювали як один показник.
Чи може новий дашборд усунути розбіжність?
Лише якщо виправлено правило, джерело або перетворення. Зміна оформлення сама по собі не змінює значення даних.
Джерело та метод
Microsoft Learn: Star schema. Приклад і порядок приймання вище є редакційним методом, а не цитатою зі стандарту чи описом реального клієнтського кейсу.