The analytics stack conversation usually starts with a vendor demo and ends with a platform nobody uses. It goes better if you start from three questions: where does the data live now, who will maintain the pipeline, and what is the shortest path to the first decision that changes.
Map what you already have
Most mid-sized manufacturers have four or five data islands: the ERP, a production or MES system, a quality database that is often a shared spreadsheet, an attendance or HR system, and machine controllers that log locally. Before choosing anything, write down for each: what it stores, how it can be read (API, database access, CSV export, screen only), and who owns it.
The "screen only" ones are the constraint. A system you can only read through its UI will define the ceiling of your automation, and the honest options are to buy the integration module, replace the system, or accept manual entry.
The three tiers, and which one you need
| Tier | What it is | Right when |
|---|---|---|
| Spreadsheet plus scheduled export | Excel or Sheets, refreshed from ERP exports | Under ~50 users, one site, questions change weekly |
| SQL database plus BI tool | A reporting database, nightly loads, a BI layer | Multiple systems to join, definitions need governing |
| Warehouse plus transformation layer | Columnar warehouse, versioned SQL transforms, BI | Multi-site, audit requirements, a data team of 2+ |
Skipping a tier rarely works. A factory with no reporting database and no analyst will not successfully operate a warehouse with a transformation framework, regardless of what the pilot showed.
SQL is the durable skill
Whatever tool you buy, the people who succeed are the ones who can write SQL. BI tools change every four years; the SQL knowledge transfers. If you are budgeting for training, put it here before you put it into any vendor-specific certification.
The join that breaks everything
Almost every manufacturing analytics project hits the same wall: the ERP item code and the production system item code do not match. Solve this once, properly, with a mapping table that is owned by a named person and version controlled. Every workaround downstream is a permanent tax.
Governance beats tooling
A metric catalogue — one row per metric, with formula, source, owner and refresh — prevents more pain than any platform feature. Keep it in the same repository as the SQL that implements it, so a definition change and its implementation move together.
What to build first
Build the report that someone currently produces by hand every week. It has a known consumer, a known definition, and a measurable time saving. Delivering that in three weeks buys the political capital for everything else. Starting with a predictive maintenance proof of concept, which is what everyone wants to start with, spends that capital before you have earned it.
A note on cost
Per-seat BI licensing punishes exactly the behaviour you want — wide, casual access to numbers. If the licence cost makes you ration logins to managers, the operators who could act on the data never see it. Price a capacity-based or self-hosted option before committing, and count the seats you actually want, not the seats you can justify today.
Discussion0
Sign in to join the discussion.