KPI Trend Anomaly Monitor

Close is when logistics leaders need a trustworthy read on whether the period's operating KPIs held, slipped, or only looked fine because volume hid the damage. On-time delivery, cost per shipment or per lane, and damage rate are the usual scoreboard. The problem is not that these numbers are unavailable. It is that humans cannot reliably notice when a trend has left its normal band while a dozen other metrics still look calm.

Dashboards in Tableau or Power BI already show the lines. Planners already load the same series into Anaplan for the next cycle. What those tools do not do by default is decide, with a stated baseline and a statistical bar, that today's move is unlikely under recent history and worth an alert. Without that bar, teams either ignore the chart until a customer complains or chase every wiggle as if it were a crisis.

A KPI trend anomaly monitor closes that gap. It compares live KPI series to a baseline window, tests for statistically significant deviation, and surfaces root contributors with enough identifiers that ops can investigate. It does not replace investigation. When the baseline is unstable, it returns empty rather than inventing confidence.

The monitor focuses on a small set of quality-relevant logistics KPIs that close teams already own:

• On-time performance (by network, mode, or contracted service level)
• Cost KPIs (unit cost, cost variance to plan, or lane-level cost where the data model supports it)
• Damage rate (claims, refusals, or recorded damage events normalized to volume)

Each KPI is identified by a durable KPI ID so alerts, tickets, and audits point to the same definition. The baseline window is explicit: start and end of the comparison period, plus any aggregation grain (day, week, rolling N periods). Contributor IDs name the dimensions or entities that drove the deviation: carrier, lane, DC, product family, customer segment, or other keys present in the fact model.

Alerts are empty when the baseline is unstable. Unstable means too few observations, structural breaks (network redesign, tariff change, new WMS cutover), or variance so high that a "significant" move cannot be distinguished from noise. Silence in those cases is a feature. A false green or a noisy red both waste the close calendar.

Ops still investigates. The monitor's job is to cite what moved, against which baseline, and which contributors concentrate the signal. Root-cause work, customer calls, and corrective actions stay with people and with follow-on analyzers.

Baseline construction should be boring and auditable. A typical pattern is a rolling window of completed periods that excludes the current close period, with optional seasonality alignment (same weekday mix, same holiday flag set) when volume is strongly seasonal. The window length is a policy choice: long enough to estimate central tendency and dispersion, short enough that the business still looks like the business under review.

Significance is not "the line went down." It is a test that the observed KPI value (or short-run trend statistic) is unlikely under the baseline distribution at a pre-agreed threshold. Implementations vary: control-chart style limits, robust z-scores, change-point detection, or supervised models trained to predict expected KPI levels given volume and mix. Platforms such as DataRobot can host or score those models when the team prefers managed ML over hand-tuned limits. The product requirement is the same either way: every alert must state the KPI ID, the baseline window used, and the contributor IDs that explain the mass of the deviation.

Contributor attribution should be conservative. Rank contributors by how much of the KPI gap they explain when the series is decomposed by known dimensions. Cap the list. Prefer stable IDs over free-text labels. If attribution confidence is low, emit the anomaly with contributors marked incomplete rather than inventing a story.

A useful alert is a structured object, not a screenshot. At minimum it should include:

• KPI ID and human-readable label matching the enterprise definition
• Observed value and unit for the close period (or the monitored grain)
• Baseline window (inclusive dates or period keys) and baseline summary (mean, median, or expected value plus dispersion measure)
• Significance method and threshold (so auditors know why it fired)
• Contributor IDs with contribution share or ranked impact
• Data freshness and source system stamps

Empty output is valid when:

• Observation count in the baseline window is below policy
• A declared change event overlaps the window (network, pricing, measurement change)
• Residual variance after mix adjustment still exceeds the significance budget
• Required dimensions for contributors are missing or join-incomplete

Empty should be logged with a reason code. That log is what prevents "the AI said everything was fine" arguments when the truth is that the model refused to score.

Downstream systems can open an ops case only when the alert is non-empty. Pairing with a root-cause exception analyzer turns contributor IDs into ordered hypotheses. Pairing with predictive delay detection helps separate on-time KPI slips that were forecastable mid-period from those that appeared only at close.

Tableau and Power BI remain the exploration layer. The anomaly monitor should publish alert rows and contributor breakdowns that those tools can filter, not replace the dashboards people already trust. Anaplan (or equivalent planning) should consume the same KPI IDs so a close-period anomaly can flag whether the next plan's assumptions still match reality. DataRobot (or an equivalent model host) is optional infrastructure for training and monitoring the detectors themselves: feature drift on the KPI predictors, champion-challenger thresholds, and scheduled retrain after a stable baseline rebuild.

Do not conflate this monitor with forward-looking commercial tools. A lane profitability forecaster answers what margin may do next. A contract renewal negotiation brief packages commercial leverage. The anomaly monitor answers a narrower close question: did quality-critical KPIs depart from a stated baseline with enough statistical weight to demand investigation, and if so, which entities should ops open first?

Shared KPI IDs across these workflows matter more than shared vendors. If on-time in the BI semantic layer, the planning model, and the anomaly service disagree on definition, every alert will be contested.

Treat alerts as quality signals in the close checklist, not as automated blame. Recommended operating rules:

1. Require a named owner for each KPI ID (ops, quality, or finance partner depending on the metric).
2. Triage non-empty alerts within a fixed SLA before close sign-off on that KPI family.
3. Record investigation outcome against the alert ID: confirmed issue, mix artifact, data defect, or accepted variance.
4. Rebuild baselines only through a controlled change, with the prior window archived for audit.
5. Never auto-close a customer or carrier dispute from an anomaly score alone.

Over time, confirmed alerts become training labels for better detectors and for exception playbooks. False positives that survive triage should tighten thresholds or fix contributor joins. Repeated empties on a KPI that later fails a customer audit usually mean the stability gates are too strict or the change-event calendar is incomplete. Fix the gates; do not pressure the model to always speak.

The quality outcome is evidence discipline: each alert cites KPI ID, baseline window, and contributor IDs; unstable baselines yield empty results; humans still investigate. That is enough for close teams to stop staring at every chart equally and start opening the few deviations that the numbers themselves cannot explain.