Between 2012 and 2014, I worked on two large manufacturing connectivity projects in the beverage industry. At the time, nobody called them IIoT projects. They were described as manufacturing intelligence or production reporting initiatives. SAP MII happened to be the platform used to implement them.
Looking back, what stands out is not the technology. It is how familiar the challenges still feel today.
The goals were simple and very practical. Connect shop floor equipment. Collect production and quality data. Make sense of it. Share it with operations and corporate teams in a consistent way.
One project was a single beverage plant in Ireland. The other was a regional hub based in Dubai, responsible for multiple plants across the Middle East, Africa, and Asia. Same company. Same industry. Very different scale and complexity.
A Single Beverage Plant. Ireland
The Ireland project was a relatively small beverage production site with one main line. The scope focused on production tracking, quality monitoring, and OEE reporting.
From today’s perspective, this was a classic brownfield manufacturing environment. Legacy PLCs. Limited documentation. Signals that existed, but were not always trustworthy or clearly defined.
SAP MII was used as the central layer to aggregate and visualize data. Connectivity relied on standard industrial protocols and existing historians. The platform itself was not the hard part.
What mattered was understanding the process.
The plant had one automation engineer who knew the line inside out. He understood which signals reflected reality and which ones were misleading. When data looked wrong, the issue was usually not technical. It was contextual.
Beverage manufacturing has its own operational rhythm. Production runs, cleaning cycles, changeovers. A temperature or flow value does not mean the same thing at all times. Without that context, dashboards lie.
We designed logic around how the line actually operated. Data collection rules changed depending on production state. Calculations reflected real operational behavior, not idealized models.
The scope stayed controlled. Templates were reused. Custom logic was kept to what was strictly necessary. The project went live in roughly six months. Stable, validated, and usable.
Regional Beverage Operations. Dubai
The Dubai project exposed a very different set of challenges.
This was not about one plant. It was about standardizing manufacturing visibility across a regional beverage network. Multiple sites. Different equipment vendors. Different historians. Different naming conventions. Different levels of automation maturity.
The objective was to create a common way to look at production, quality, OEE, and downtime across all sites.
Before any value could be delivered, basic connectivity issues had to be addressed. OPC servers. Kepware. Legacy historians. Serial communications. Tag names written differently at every site, sometimes even in different languages.
None of this was new technology work. It was data normalization and structure work. The same type of work IIoT teams still struggle with today.
We aligned data into consistent production models so that metrics meant the same thing everywhere. That effort took time. It was manual. It was not glamorous. But without it, nothing else would have worked.
Physical constraints also played a role. Infrastructure behaved differently in extreme heat. Hardware failures delayed testing. These realities never appear in architecture diagrams, but they shape project timelines.
Coordination was another challenge. Teams were spread across regions and time zones. Decisions required alignment between corporate, regional, and local stakeholders. Progress was slower, not because of tools, but because of governance.
What These Projects Had in Common with IIoT Today
Even though these were not IIoT projects, the core challenges are the same ones seen in modern IIoT programs.
Connectivity was hard, not because protocols were missing, but because environments were inconsistent.
Data quality mattered more than dashboards.
Naming conventions, ownership, and alignment between IT, OT, and operations defined success more than platform features.
In both projects, value came from practical use cases. OEE was implemented early because it gave plant teams something concrete. Downtime tracking changed behavior because it was tied directly to operator input and maintenance decisions.
Quality data became powerful only when it was placed in production context. A failed batch meant something only when it could be traced back to process conditions, equipment, and time.
These patterns map directly to what IIoT aims to do today.
What Would Be Easier Today
There is no question that these projects would be easier to implement now.
Connectivity stacks are more mature. Cloud platforms reduce infrastructure friction. Event-driven architectures simplify data distribution. Concepts like Unified Namespace make data modeling clearer.
But easier does not mean trivial.
If the same projects were run today without fixing data structure, ownership, and governance, the outcome would not be very different.
Modern tools accelerate execution. They do not replace fundamentals.
Why This Story Still Matters for IIoT
These beverage manufacturing projects were not IIoT initiatives. But they dealt with the same reality that IIoT tries to address.
Brownfield equipment. Fragmented data. Organizational silos. The need to turn signals into decisions.
That is why this story belongs in an IIoT blog.
It is a reminder that while technology evolves, the hard parts remain stubbornly human and structural. Data still needs context. Someone still needs to own it. Operations still need solutions that fit how plants actually run.
Final Reflection
These projects were not perfect. There were delays, compromises, and difficult trade-offs. But they delivered value and created a shared operational language across beverage plants.
Today’s IIoT platforms make many things easier. They do not change the nature of the problem.
Progress in manufacturing has always been about solving the same challenges a little better each time.
Leave a Comment