I started working with industrial data integration in 2005, and one of my first major projects was at a large pulp and paper manufacturing site in Brazil. This was back in 2006-2007.
At that time, nobody was calling it “IIoT.” The term wasn’t popular yet. Cloud wasn’t the default. “Unified Namespace” wasn’t part of the conversation. MQTT wasn’t everywhere. And most plants weren’t thinking in terms of “data products” or “industrial platforms.”
But the problems we were solving were the same problems we still solve today. In many ways, it was an IIoT project before IIoT had a name.
The plant was huge. It ran 24/7 with integrated operations across pulp production and paper manufacturing. There were miles of piping, massive digesters cooking wood chips into pulp, and paper machines running at insane speeds.
The operation had everything you’d expect from a real process industry site.
DCS systems controlling the process. Quality labs producing results around the clock. Production tracking happening in spreadsheets. SAP ERP in the back office. Lots of data. Lots of systems. Zero alignment.
Nothing talked to each other.
The company scope. What we were walking into
This wasn’t a “single-use-case” environment.
It was a full industrial ecosystem with multiple production areas and multiple teams, each with their own priorities and their own definition of success.
From a scope perspective, the project touched several layers of the business:
Shop floor process and automation scope
- Continuous pulp cooking and recovery processes controlled by DCS
- Multiple paper machines producing different grades and formats
- On-site utilities that impacted production stability (steam, water, energy)
- Instrumentation spread across thousands of sensors and control loops
- Operational events like stops, slowdowns, wash-ups, and grade transitions
Quality scope
- Quality labs running physical and chemical tests 24/7
- Manual sampling routines. With delays between sampling, results, and action
- Frequent unit conversions and manual data entry
- Grade-specific quality targets (moisture, ash, brightness, basis weight, etc.)
- Root-cause discussions that always came back to “who has the right data?”
Production tracking scope
- Shift-based reporting and manual reconciliation
- Production declared once per shift (sometimes once per day)
- Downtime categories inconsistent across lines and teams
- Grade change events not consistently captured
- A lot of tribal knowledge in the control room. Almost none of it digitized
ERP and business scope
- SAP ERP being the “official record” for inventory and costing
- Finance not trusting manufacturing numbers because timing and accuracy were off
- Planning suffering because actual production never matched schedules
- Material consumption not matching what was being booked
- Goods receipts and confirmations happening late, sometimes “fixed” afterward
So even though it started as a manufacturing visibility and integration initiative, it quickly became clear this was also a business alignment project.
Where SAP MII came in (and why it mattered)
The integration layer used SAP MII (at the time often referred to as SAP xMII), because it was one of the few platforms built specifically for this “shop floor to top floor” problem.
And it wasn’t being used as a fancy dashboard tool. SAP MII was used as the glue.
It sat in the middle of a messy reality where everything was disconnected:
- OT systems in the DCS world
- Quality data in lab databases
- Production reporting living in spreadsheets
- ERP processes waiting for clean transactions
- People trying to run a 24/7 operation with inconsistent information
SAP MII became the place where those signals and events were translated into something usable and consistent.
Looking back, that is one of the closest “early IIoT platform” patterns I’ve seen.
Today, we’d describe it as an industrial integration and contextualization layer. We’d probably implement parts of it with edge gateways, brokers, streaming pipelines, and cloud services.
But the purpose is the same.
The real problem wasn’t “real-time visibility”
When we arrived, the request sounded simple.
“We need real-time visibility.”
But once you ask “visibility of what?”, you realize it’s never one thing.
Operations wanted live production rates. Quality wanted faster lab results. Planning wanted to know why output never matched the schedule. Finance wanted to understand material consumption and costing.
The problem wasn’t missing dashboards. The problem was that nobody had a shared truth.
Every department had their own numbers, their own spreadsheets, their own explanations, and their own version of “reality.” When things went wrong, people didn’t solve problems. They argued about which data was correct.
Today, we’d call that a classic IT/OT integration gap. It’s also one of the main reasons IIoT programs exist. Not because we love new technology. Because plants need consistent, trusted data that flows from equipment to decisions.
What we built. And what we’d call it today
Back then, the architecture didn’t have fancy names, but the pattern was clear.
We created an integration layer between the shop floor and the business systems using SAP MII.
We pulled real-time signals from process controllers. Temperatures, pressures, flow rates, and all the continuous variables that define a pulp and paper process minute by minute.
We connected quality results so lab data could show up quickly, without manual re-entry, delays, and mistakes.
We tracked production events. Start, stop, grade changes, downtime reasons. We also used that flow to support ERP updates for inventory, goods receipts, and costing.
And we delivered dashboards so people could see what was happening now, not tomorrow.
In today’s language, that solution was basically this:
- OT data acquisition + normalization
- Time series data modeling (even if we didn’t call it that yet)
- Production event modeling and contextualization
- A shared operational truth across functions
- A foundation for performance improvement (OEE)
- A data pipeline that supported ERP transactions, not just reporting
It wasn’t cloud IIoT. But it absolutely had the mindset of IIoT. Machines produce signals. Signals become data. Data becomes decisions.
The translation layer. Integration was not just “connecting tags”
Even back then, the “technology list” was familiar. Automation had proprietary protocols. Different vendors. Different tag structures. Different naming conventions. Different levels of reliability.
Quality ran in its own world. Production tracking lived in spreadsheets. ERP waited for inputs that arrived late, incomplete, or inconsistent.
So the job was translation.
To build the bridges.
To connect the dots.
And to transform raw signals into something that production, quality, planning, and finance could all trust.
That’s what SAP MII did well for the time. Not perfect, but powerful!
Why process manufacturing makes this harder (and more interesting)
Pulp manufacturing is continuous. There’s no clear “batch” boundary like you have in pharma. Material moves through a long chain of process stages, and the process behaves like a living system.
So connecting systems is only half the work.
The other half is understanding the process deeply enough to turn raw signals into meaningful information.
Yield calculations weren’t just math. They required process knowledge.
Quality losses weren’t instant. They could show up downstream hours later.
Production “rate” could look good while quality was falling apart.
This is exactly why IIoT is not just connectivity.
IIoT is context.
What worked. The value came from trust
The biggest win was production tracking.
Before, production was reported manually once per shift, with reconciliation, corrections, and debates. After the SAP MII integration layer went live, reporting became continuous and automated.
For the first time, the plant could see what it was producing, as it was producing it.
Quality integration was another clear success.
Lab results went from being delayed by hours to being available immediately. That changed grade transition decisions and reduced off-spec production.
And once SAP ERP was connected to actual production, finance finally trusted the numbers.
That might sound small, but it wasn’t.
When finance trusts plant data, conversations change. Instead of defending numbers, people start improving performance.
The OEE request. Simple formula, hard reality
Once the core data foundation was stable, the next request was predictable.
“Can we build OEE?” OEE sounds simple. Availability times performance times quality. Three numbers. But continuous processes don’t behave like clean discrete machines.
Availability is obvious when a machine is stopped. It’s not obvious when it’s running slow because of a quality issue.
Performance gets messy when product grades change and target speeds change with them.
Quality losses can show up long after the defect was introduced, especially when paper is converted downstream.
So we built a lot of logic.
Downtime capture needed the right level of detail. Quality events had to be linked back to the right production run. Grade changeovers had to be accounted for properly.
It wasn’t perfect, but it was reliable enough to drive daily improvement conversations.
And once people trust OEE, they stop debating the math and start fixing the process.
Honest opinion. We overbuilt in the wrong places
Looking back, we over-engineered some things.
We built dashboards that looked great in demos but didn’t fit daily work. Operators wanted simple, fast screens. Plant leadership wanted one-page summaries.
We spent too much time making things impressive and not enough time making them useful.
We also underestimated the importance of data quality at the source. Garbage in, garbage out.
If a sensor drifted or a tag was configured wrong, SAP MII would show the wrong number in real time. That creates noise and mistrust fast.
Performance tuning was another lesson. Pulling thousands of signals in a continuous process is heavy. Database design, caching, and update frequency decisions mattered a lot. We learned that after the first performance meltdown.
What I’d do differently now (with an IIoT mindset)
If I could redo this project today, with everything we know now, I’d change a few things.
1) Start with one high-value use case
Not “integrate everything.” Pick one production line or one pain point. Make it rock solid, then scale.
2) Standardize earlier
Custom mappings become technical debt fast. A standardized equipment hierarchy and naming convention would’ve made everything easier later.
3) Build data quality monitoring into the platform
Not as an afterthought. Data drift, stale values, broken tags. This will happen. It needs detection and alerting.
4) Separate “integration” from “visualization”
SAP MII was strong as an integration and transformation tool. For pure operator visualization, a dedicated HMI/SCADA approach is often simpler and more natural. Trying to force one platform to do everything creates complexity over time.
Final thoughts
That pulp and paper project in Brazil taught me that technology is rarely the hardest part. Understanding the process is hard. Building trusted data is hard. Getting adoption is hard.
Back then, we didn’t call it IIoT. But the foundation was already there.
We were building a system where shop floor signals could become business decisions. Faster. More reliable. With less debate and more action.
The principles are still valid today. Understand the process. Define the data. Start small. Scale what works. Focus on value, not features.
That’s what I learned on one of my first big manufacturing integration projects. And it still shapes how I think about IIoT today.
Leave a Comment