Summarize the Content of the Blog
Most discrete manufacturing companies approach digital transformation the same way. Get the data out, structure it, contextualize it, build dashboards, deliver reports. It makes sense on paper. The tools are there, the integrators are lined up, the budget got approved. But it breaks almost every time, and it breaks for a reason nobody wants to talk about.
The sequence is wrong.
The Standard Flow and Why It Fails
So here's what most strategies look like. You've got data sources everywhere, PLCs, SCADA systems, historians, MES, ERP, quality systems. Step one is to start contextualizing the data. Map it to assets, add process hierarchy, engineering units, shift information, all the stuff that makes raw tag data actually mean something. Step two, build dashboards and reports on top of that context layer. Step three, hand it to the business.
The problem is step one. Contextualization before investigation puts the cart before the horse.
Think about what you're actually asking someone to do.
That's not a data engineering task. That's a domain knowledge task. And the person who usually gets stuck with it is the automation and controls engineer, because they're the only one who can access the raw data in the first place.
But their priority is keeping the facility running, not building semantic models. So they do the best they can with what they know, tag by tag, and the contextualization reflects the perspective of one role rather than the combined knowledge of the process engineers, quality engineers, and manufacturing engineers who actually use the data to make decisions.
The result is a context layer built on assumptions instead of validation. Dashboards get built on top of it, and the people who need to trust those dashboards don't, because the context doesn't match what they know to be true about their process. So they go back to Excel and rebuild it themselves.
What Investigation First Actually Looks Like
So what if you flip it? Instead of data sources to contextualization to dashboards, you go data sources to investigation to contextualization to dashboards.
The difference sounds subtle but it changes everything about who's involved and when.
Investigation first means ingesting all the raw data into a platform where your subject matter experts can actually query it, explore it, correlate it across sources in real time. Not a CSV export they have to request from someone else. Not a snapshot frozen in time. Live data, continuously flowing, accessible to the people who understand what it's supposed to look like.
So now the process engineer can query OPC-UA tag data alongside quality records and batch information and actually see the relationships as they happen. They're not waiting for someone to build them a report. They're doing the analysis themselves, directly against the live data stream, using their domain expertise to identify what matters.
This is where the contextualization gets built correctly. The SME investigates the raw data, finds the patterns, identifies which tags actually correlate to the process outcomes they care about, figures out what average line speed actually needs to mean for their specific operation. Then you build the UNS or whatever your contextualization framework is around what they've proven, not what someone assumed.
Engineers love this. We call these proofs. You investigate the raw data, identify the patterns, then contextualize based on what you've found. But you're not done. You validate the contextualization by investigating again, this time through the structure you built, confirming that what the UNS represents actually matches the process reality. That round trip, investigate to contextualize to validate, is the proof. The contextualization becomes a framework built on evidence, not convention.
The Technical Sequence
So to lay it out explicitly:
What most companies do: Data Sources → Data Manipulation and Context → Dashboards and Reports
This breaks because you're asking someone to decide which data matters before anyone has investigated what questions need answering. There are thousands of tags in a typical plant, and they're all important, it just depends on the context. Do you want all of them or a select few? Without investigation, you're guessing. And the structure you build reflects those guesses. The dashboards that get built on top of it don't get trusted, because the people who need them know the context doesn't match their reality.
What actually works: Data Sources → Investigation (real time, by SMEs) → Data Manipulation and Context (validated) → Dashboards and Reports
The investigation phase is where the SMEs interact with the live data, identify what's important, and define the context based on what they've proven to be accurate. The contextualization that follows is grounded in real process knowledge. The dashboards that come after actually get trusted and used, because the people who need them were involved in defining what the data means.
And here's the thing, it can be iterative. You don't have to get the full contextualization perfect before you start getting value. Ingest the raw data, investigate, build some initial context around what you've validated, then investigate again to verify the context is accurate. Each pass refines the structure. Each pass builds more trust.
Where UNS and Industry 4.0 Fit
People hear "Unified Namespace" and think that's where you start. Build the UNS, get the ISA-95 hierarchy mapped out, define your topic structure, and then the data flows and everything works.
I think UNS is valuable. But it's a contextualization tool, and contextualization is step two, not step one. If you build your UNS before your SMEs have investigated the raw data and identified what context actually matters for their operation, you're going to end up with a namespace that looks clean on paper but doesn't reflect how the process actually works.
Every plant is different. The tag naming conventions alone can vary between facilities in ways that would make a software engineer weep. The UNS needs to be informed by the people who understand the process, not defined in a conference room based on a reference architecture diagram.
Empower the Right People
There's a bigger issue underneath all of this. The industry right now is focused on building solutions for the automation engineer. The tools, the interfaces, the workflows, they're all designed for the person who manages the control system. But the people who actually need the data are the process engineers, the quality engineers, the manufacturing engineers. The domain experts.
These are the people this industry needs to empower. They're the ones who know what "good" looks like on their line. They're the ones who can tell you whether a variance is noise or a real problem. They're the ones whose expertise should be scaling across the operation instead of getting buried in spreadsheets.
How We Think About This at bitsIO
This is exactly why we approach engagements the way we do. We don't show up with a dashboard and leave. We embed with the team, work side by side with the people who actually understand the operation, and help them investigate their own data first. The contextualization comes from their understanding, not from a template we brought in from the last plant.
I think the companies that get this right are the ones that stop trying to contextualize data before the people who understand it have had a chance to investigate it. Don't fall into the same trap everyone else has. Let your experts lead the process, build structure around what they've validated, and the transformation will follow.
Frequently Asked Questions (FAQ)
