Apex: scope
Swallow operations, finance, devices, and membership in one bite. Without three to five KPIs you must watch, the platform has no acceptance face.
The word “platform” easily lifts a project to a height you cannot accept: real-time, full volume, every subject, plus a platform team. Ask for all three at once and you fall into a death triangle—scope, cycle, and trust crack together.
Left: people
Without a definition owner, the platform is another database. Someone takes leave and the numbers fork immediately.
Right: sources
ERP and POS primary keys still drift. The faster you build the warehouse, the more systematically you are wrong.
Must you have one? Not necessarily. One or two source systems, few KPIs, a weekly meeting that can close on a dashboard and drill-down: an operations dashboard, alerts, and a necessary floor screen are enough. Why you need a dashboard first: Why an operations dashboard is not optional. Master data and APIs are the platform’s ticket in, not its accessories. See Without master data, visualization lies and Once APIs are standardized, the next chart is faster.
When should you talk about a platform in earnest? Systems still growing, more than three private extracts, the same KPI copied everywhere, adding a chart requiring another project. What you lack then is scheduling, quality, and contracts. See More systems connecting: standardize APIs or draw charts first. Even then, you need not start from the slogan “enterprise data platform.” Start with a subject warehouse and extract receipts. Cost: What dashboards or a data platform cost, and how long they take. Tool vs custom: Off-the-shelf BI vs a custom dashboard: what actually differs.
The sequence DaXi recommends (you can stop on any layer):
- Definition sign-off + a drillable operations dashboard
- Store / material / customer mapping + alerts to people
- A few reconcilable APIs so the next chart reuses them
- When sources and extracts multiply, add scheduling and a subject warehouse
Treating the warehouse as an exhibit is not the same as a decision entry; see Treating systems as a warehouse exhibit vs a decision entry. From brief to launch as engineering: From brief to launch: how a data project actually runs. To judge which layer you are on, go to the Data service page and send the KPIs you must watch and the systems you have. Do not start with “we want a big-data platform.”
If the boss already promised a “platform” at an industry event, define it as APIs, mapping tables, scheduling, and reconciliation—not another conceptual layer. Light five weekly-meeting numbers first; then the platform has the right to grow. Floor and alerts stack on demand. See Alerts pushed to people, so exceptions rarely sit overnight and How a shop-floor screen keeps crews out of the office.
If five weekly-meeting numbers cannot light in a year, stop the scope
If a platform project cannot light the five numbers the weekly meeting uses in a year, stop the scope instead of adding people. A platform with no business acceptance inflates headcount before value.
A real-time pipe is the most expensive corner of a platform. Do it locally where the floor beat needs it. Most operations KPIs are fine at T+1. Do not use real-time to prove a platform exists.
On staffing, mid-size companies rarely can feed a “platform department.” Definition owners should be finance and operations leads. Implementation only guards extracts and reconciliation. Treat the platform as an org upgrade and the project ends in hiring. If nobody looks at the dashboard, check for an owner before expanding the platform; see Nobody looks at the dashboard. Is it still worth building. Until multi-system conflicts are written into a reconciliation table, the warehouse only stores the conflict deeper; see When every system calculates its own numbers, what breaks.