Problem
Someone rebuilds the same number every Monday. It’s wrong by Tuesday.
The dashboard is the easy part. Keeping it true is the job. Exports go stale the moment an order changes, so the weekly KPI gets stitched back together by hand — pulled from the ERP, the store, and finance, reconciled in a spreadsheet, and out of date again before the meeting ends.
The dashboard Always on live data
The dashboard the team opens is the data the business just wrote.
Revenue, open orders, margin, the alerts that fired overnight — all on one surface, because PA reads the same tables the ERP, the store, and finance write to. Nothing is exported and reconciled first. The number is already here, and it’s already true.
What you get back
Not another dashboard to maintain. One less system to keep true.
The weekly rebuild, gone
The number recomputes itself the instant an order is written, so no one stitches it back together from exports on Monday morning. The hour the rebuild used to eat is the hour you get back.
A figure finance can stand behind
Every KPI reads the same orders, invoices, and ledger entries finance closes the books on, not a copy that drifted overnight. The dashboard and the close agree because they’re the same rows.
Alerts that are records, not emails
A threshold breach is written to the audit trail with who saw it and when, so an alert is something you can trust and trace — not an email that may or may not have sent.
Trends without a second system
Every period is stored with its breakdown as the value moves, so trends and comparisons are already there. No warehouse to feed, no nightly job to babysit.
A KPI, end to end
Define a number once. Then watch it keep itself true.
A KPI on PA isn’t a chart you rebuild. It’s an object you set up once on your live tables — and its recompute, its thresholds, and its history come with it, all on the same database the business already writes to.
-
Define
Point it at a real table.
You pick what to measure and where it lives — orders, accounts, the ledger. The indicator reads the source row, not a nightly copy of it, so there’s no model to assemble first.
-
Recompute
It updates on write.
When an order is written, the indicators that depend on it recompute in the same transaction. There’s no nightly job catching up at 02:00 — the number is right at 02:14 because the order and the metric moved together.
-
Threshold
It warns by itself.
Say when a number should warn you and who it should reach. The breach is logged to the audit trail, so the alert is a record you can trust — not an email someone has to confirm went out.
-
History
It keeps its own trend.
Every period the value is stored with its breakdown, so trends, comparisons, and “why did this move” are already there — queried in place, with no separate warehouse to feed.
What you don’t run
The reporting pipeline your team doesn’t have to keep alive.
Most analytics needs a chain of moving parts before the first chart is true — and someone has to own every link of it. PA reads the operating tables directly, so the chain isn’t shorter. It isn’t there.
- data warehouse
- read replica
- nightly ETL job
- BI extract / star schema
one PostgreSQL the tables you already write to are the tables PA reads Lineage
ServiceNow’s Performance Analytics had the right idea: make KPIs first-class objects with history and thresholds. We extended it past one vendor’s tables.
There, indicators live over ServiceNow’s own data. Here they read across CRM, OMS, ecommerce, and Financial Management on one PostgreSQL — so an indicator can join customers to orders to the ledger without a single export. Same shape of idea, applied to the whole business instead of one system.
Proof
Running on real data at Serbia’s largest book publisher.
Laguna runs commerce, inventory, customers, and finance on one platform. PA reads those operating tables directly, so a cross-module question that used to mean an export and a wait is answered in the room — on the same numbers the books close on.
Boundary
What’s live — and what’s still on the roadmap.
Live indicators on the operating model are in production. The heavier analytical depth is honestly marked planned, not implied.
- Indicators defined on live CRM, OMS, ecommerce, and finance tables
- Recompute on write — values true in the same transaction
- Stored period history with breakdowns, no separate warehouse
- Thresholds, alerts, and escalation as configuration
- Every breach logged to the audit trail
- Long-range column-store depth for heavy historical scans planned
- Predictive forecasting (ARIMA / Prophet) planned
- Natural-language alert thresholds planned
- Scheduled narrative summaries of what moved and why
- Cross-customer benchmarking views
Bring one KPI your team rebuilds from a spreadsheet every Monday.
We’ll define it as an indicator on live data while you watch, set a threshold, and show it recompute as an order is written — so you can decide whether the Monday rebuild ever needs to happen again.