The Industrial IoT Blog

Let me tell you what IIoT consulting has really been like for me—across automotive, metals, pharma, food, and a few other places where things get built, mixed, or assembled. I’ve been at this since before “Industry 4.0” was a thing, and I’ve seen the good, the hard, and the stuff nobody puts on PowerPoint slides.

How It Starts: Connecting Machines, Data, and People

The core of IIoT consulting, at least in my world, is pretty simple to say and very hard to do: connect machines, data, and people so plants run smarter, not just faster. I started with SAP xMII back in 2005, wiring up lines so plant operators could see real-time data instead of waiting for yesterday’s Excel sheet. Fast forward to now, and we’re talking about plant-wide central data brokers, advanced analytics, and edge-to-cloud architectures that span entire global networks. But the heart of the work hasn’t changed: make life easier for the folks on the shop floor, and give decision-makers real visibility without drowning them in noise.

Typical Consulting Engagements: The Real Problems

Most projects kick off with a familiar pattern. A manufacturer wants to “go digital,” but their plants are a patchwork of old PLCs, homegrown apps, and maybe a couple of shiny new IoT pilots that don’t talk to anything else. Here’s what I actually see:

• Disconnected Systems: Plants often run different MES, historian, and automation systems—even inside the same company. No standard integration, lots of manual workarounds, and plenty of double entry.
• Custom Integrations Everywhere: Every site has its own way of getting data from machines to ERP. Some use flat files, some use OPC, some use homegrown scripts that only one person understands.
• Resistance to Change: Operators and engineers have been burned by “IT projects” that made their lives harder, not easier. There’s skepticism, and honestly, they’re right to be cautious.
• Data Overload, Not Insight: Once you connect everything, you get more data than anyone can handle. The trick is making it useful, not just available.

For example, at one large food and beverage client, we had 11 plants, each with its own way of tracking inventory, production, and scrap. Some had partial MES, some relied on SAP ERP for everything, and some had nothing but paper and spreadsheets. The first step was just mapping what was actually there—no fancy tech, just a lot of whiteboards and walking the floor. Only then could we start standardizing interfaces and building a simple, unified portal for operators. The result? Less double entry, fewer errors, and a foundation for real analytics.

What Actually Works: A Few Patterns

Over the years, I’ve learned a few things that consistently work, no matter the industry:

• Start Small, Show Value Fast: Don’t try to “boil the ocean.” Pick one line, one process, or one pain point. For instance, we once reduced a 16-step operator task (piece counting) down to a single click with the solution. That got buy-in faster than any slide deck could.
• Bridge OT and IT: The best results come when automation engineers and IT folks actually talk to each other. I’ve spent a lot of time translating between these worlds—explaining why a PLC can’t just “send data to the cloud,” or why IT security rules can’t just be ignored on the shop floor.
• Standardize Where You Can: Use templates and accelerators for things like production execution, maintenance management, and quality dashboards. This isn’t just about speed—it’s about making support and future upgrades manageable. I’ve built and reused templates for everything from OEE dashboards to mobile maintenance apps, saving months on each rollout.
• Keep Operators in the Loop: If the people using the system aren’t involved from day one, you’ll end up with a solution nobody wants. Some of the best ideas (and the fastest fixes) have come from plant operators who know the real process bottlenecks.

Tools and Tech: What’s Under the Hood

I’ve been lucky to work with a lot of different technologies, and here’s what’s made a difference:

• Historians: AVEVA PI and Aspen Tech IP.21 for local data. These are the backbone for time-series data, but they don’t scale well globally.
• MES: SAP ME, DMC, and OEE modules. The key is integrating these with both shop floor and ERP, not just using them as islands.
• Connectivity: OPC UA, MQTT, and lately, Unified Namespace (UNS) patterns—especially for multi-site architectures. UNS decouples producers and consumers of data, making the whole thing more scalable and future-proof.
• Edge and Cloud: Edge platforms (like Ignition, HighByte) for local processing and resilience; cloud platforms (Azure IoT Operations, AWS SiteWise) for analytics and global access.

One project stands out: we had to connect hundreds of lab and production devices across dozens of sites, ensure compliance, and build an architecture that could feed both local dashboards and global analytics. We used a hybrid edge-cloud model, with strict data domain ownership and regular workshops to keep everyone aligned. It wasn’t easy, but it’s the only way to get both agility and compliance in a regulated environment.

Lessons Learned (the Hard Way)

If I had to sum up the biggest lessons from IIoT consulting, they’d be these:

• You Can’t Skip the People Part: Technology is easy compared to change management. If you don’t bring plant teams along, the project will stall—or worse, the new system will get bypassed.
• Legacy Systems Are Here to Stay: There’s always another old PLC, a mystery database, or a 20-year-old SCADA system to integrate. Don’t fight it—find ways to bridge and contextualize.
• Data Quality Is Everything: More data isn’t better if it’s not accurate, contextualized, and available when needed. Data domain owners and clear lifecycle management are a must.
• Documentation and Knowledge Sharing Matter: We learned to document everything—not just for compliance, but to keep knowledge from walking out the door when someone retires or moves on.
• Regulatory and Cybersecurity Are Non-Negotiable: Especially in regulated and critical industries, you have to bake compliance and cybersecurity into every layer—from the PLC to the cloud.

Honest Opinion: The Hype vs. Reality

Here’s my unpopular opinion: most IIoT projects fail not because of technology, but because of over-promising and under-delivering. There’s too much focus on “AI” and “digital twins” before the basics are right. If you can’t get real-time, accurate data from your machines, no amount of analytics will save you. Start with the fundamentals—connectivity, data quality, operator usability—and build from there. The fancy stuff can come later, and it’ll actually work.

Closing Thoughts

IIoT consulting isn’t glamorous, but when it works, it’s deeply satisfying. I’ve seen plants go from chaos to clarity, operators get home earlier because their jobs are simpler, and companies actually use their data to make better decisions. None of it happens overnight, and none of it happens without a lot of listening, patience, and humility. If there’s one thing I’d tell anyone starting out: focus on the real problems, don’t chase the buzzwords, and always, always bring the people with you.