What Industrial Consultants Won't Tell You

The most common thing I see in industrial AI programmes is a company that has skipped Layer 1 and gone straight to Layer 2. Layer 1 is a unified, governed data foundation - a reliable, timestamped, single version of operational truth that every function reads from. Layer 2 is AI, machine learning, and predictive analytics. The two are not interchangeable. You cannot have Layer 2 without Layer 1.

Vendors don't tell you this because they sell Layer 2 products. System integrators don't tell you this because Layer 1 is less glamorous and harder to pitch at board level. And so organisations buy an AI demand planning tool and train it on siloed, inconsistently formatted, politically adjusted data - and then spend 18 months wondering why the forecast accuracy has not improved.

The sequencing is non-negotiable: master data rationalisation, then integration, then analytics, then AI. Every organisation that has built a sustainable AI capability in manufacturing or supply chain followed this sequence. Every organisation that skipped it has a failed AI project somewhere in their portfolio.

Every PdM vendor will show you a demonstration where a model predicts a bearing failure three weeks in advance. What they won't show you is the 18 months of labelled failure history the model was trained on, the data engineering required to get clean sensor feeds, and the CMMS integration that turns a prediction into a work order.

In practice, a PdM programme on a new asset group - one that does not have structured historical failure data - typically requires 6–12 months of data collection before a reliable supervised model is possible. The first phase of any honest PdM programme is not modelling. It is sensor deployment, data pipeline construction, and CMMS integration. The model comes third.

This doesn't mean PdM isn't worth pursuing. It is - typically 15–25% reduction in unplanned downtime once the programme matures. But the organisations that get there are the ones that planned for the real timeline, not the vendor's pilot timeline.

The third thing most industrial consultants will not say out loud is this: the goal of a data programme is not to make more decisions faster. It is to make better decisions in the decisions that matter. There is a meaningful difference.

I have seen organisations deploy 40-metric dashboards that nobody opens, because the signal-to-noise ratio is so low that the dashboard requires a data analyst to interpret it before an operations manager can use it. The analytics investment produced more data, not better decisions.

The programmes that deliver sustained operational value focus on three to five high-value decision points - replenishment, maintenance scheduling, shift planning - and instrument those specifically. Not everything worth measuring is worth optimising. Clarity about which decisions you are trying to improve, and how the data will change those decisions, is the discipline that separates programmes that compound from programmes that stall.

You do not need to be technical to tell whether a consultant is selling the foundation or skipping it. Three questions do most of the work. The first: "Show me a client who skipped the data foundation and still built a sustainable AI capability." An honest answer is that there isn't one — and a consultant who produces a confident counter-example is usually describing a pilot that never reached production.

The second: "What does your data-readiness assessment look like before any model is built?" If the answer is a model demo rather than an assessment of source systems, master data, and integration, you are buying Layer 2 on an absent Layer 1. A serious engagement starts by mapping where your operational truth lives — ERP, MES, SCADA, spreadsheets — and how trustworthy it is, before a single forecast is attempted.

The third, and the one that protects you after go-live: "Who owns the Power BI semantic model and the data definitions once you leave?" If the consultant cannot answer it, you are buying a dependency, not a capability. The right model leaves you with a governed foundation your own team can run — which is exactly what the Fractional CDO engagement is designed to hand over, rather than a black box only the vendor understands.

The abstract advice — foundation first — only helps if you can picture what it builds to. In a typical mid-market industrial estate, Layer 1 means pulling the ERP (SAP S/4HANA, SAP ByDesign, or Microsoft Dynamics 365), the MES, the warehouse system, SCADA tags, and the inevitable spreadsheets into one governed store. We do that on Microsoft Fabric: source systems land in OneLake through Azure Data Factory and real-time connectors, modelled once into a consistent structure rather than copied five times.

On top of that sits a Power BI Direct Lake semantic model — one definition of OEE, OTIF, fill rate, and cost per unit that finance, operations, and the plant floor all read from. That is the whole point of the foundation: the argument about "whose number is right" ends, because there is one number with the lineage attached. Only then does manufacturing analytics become trustworthy enough to act on, and only then does predictive analytics have something clean to learn from.

None of this requires ripping out the ERP or the MES. The systems of record stay where they are. What changes is that the analytics layer stops being a patchwork of exports and starts being a governed product — maintained by a small team, not a five-vendor integration programme. That distinction is the difference between a capability that compounds and one that needs rebuilding every time a source system changes.

The shape differs by sector but the sequence does not. In manufacturing the first foundation win is usually live manufacturing analytics — OEE and downtime off the PLCs. In FMCG it is connecting distributor sell-out to the planning system so forecast accuracy and fill rate stop being month-end guesses. In logistics it is OTIF and DIFOT visible by lane rather than reconciled in a spreadsheet, and in EPC it is earned value calculated from connected cost and schedule systems. Different first metric, same dependency: the governed data layer has to exist before any of it is trustworthy.

Plenty of teams know the sequence and still stall. The usual reason is not technical. It is that nobody owns the data foundation. Master data rationalisation — agreeing what a "material", a "site", or a "customer" actually is across systems — is unglamorous, cross-functional, and politically awkward, so it drifts without a single accountable owner. The integration work is straightforward; the agreement on definitions is the hard part.

This is the gap the Fractional CDO model is built for: senior, embedded data leadership that owns the foundation and the definitions a few days a week, without the cost of a full-time hire. The second failure mode is treating governance as a document rather than a build — a policy PDF that nobody enforces, instead of access controls, lineage, and audit trails wired into the platform. Governance that lives in the data layer holds; governance that lives in a binder does not.

And the honest limit: this sequencing assumes the will to do the boring part. If leadership wants the AI headline without funding the foundation, no consultant — and no platform — can close that gap. The projects that succeed are the ones where the operations leader and the CFO both accept that the first six weeks buy a foundation, not a forecast.

If you are weighing an AI investment, the most useful thing you can do first is not evaluate models. It is to name the three to five decisions you want to improve — replenishment timing, maintenance scheduling, shift planning, demand sensing — and trace, honestly, whether the data those decisions need is currently trustworthy, timely, and in one place. In most industrial businesses it is not, and that answer is more valuable than any vendor demo.

From there the work is concrete and short. A six-week Discover and Foundation build connects the priority systems into a governed Microsoft Fabric lakehouse with a first set of Power BI reports the operations team uses daily. That delivers first value — a number people trust — before the predictive maintenance or forecast accuracy work begins, not after a six-month programme. It also de-risks the AI investment, because by then you know whether the foundation can carry it.

The uncomfortable truth the headline roadmaps skip is that this is a digital transformation of sequence, not scale. You do not need a bigger programme. You need the right order — unify the data, predict with AI, act with automation — and the discipline to fund the first step properly. Every sustainable industrial AI capability I have seen was built that way. None were built by skipping it.