IT/OT Academy Deep Dives

Summary

What happens when the same person has to solve the data problem in a candy factory and in a water treatment plant? Gregory Grauwels started as an automation engineer, writing PLC and SCADA code and taking service calls at 2 a.m. He later became Group OT Manager at Cloetta, with a mission to standardise eight candy factories and more than 100 production lines. Today he is IT/OT Director at Waterleau, leading a digital team that ranges from hardcore developers to OT engineers connecting edge devices to PLCs. In this final session of the cohort, he shares what a decade of building unified namespaces (UNS) taught him, including what didn’t work.

At Cloetta, he found eight factories measuring OEE with eight different vendor systems. His answer was to stop chasing the perfect standard and prove value cheaply. He used Ignition, one extra counting sensor per line and a local Sparkplug UNS. He stayed below the plant manager’s signing threshold, and a whole factory cost about €50,000, against roughly five times that for the classic Siemens stack. The biggest shift was to define which data you need and make it a purchasing requirement for vendors. He also stepped away from PackML after realising he was paying extra just to get data in a different format.

His most important finding is that a UNS is great for real-time streaming but breaks down with history. When an operator corrects an event a week later, the calculated OEE changes, and a snapshot-based UNS can’t follow. At Waterleau, lab data arriving every week or two caused the same problem. They moved from an Ignition-only stack to a Postgres/TigerData platform with an MQTT broker and a Superset BI layer. It is version controlled and CI/CD driven, and it is built to scale to hundreds of plants. The key lesson is that technology is rarely the issue. Know what you want to achieve and who signs off the budget, and speak that person’s language.

In this session

00:08 Welcome and the last session of the cohort
01:33 New student app: certificates, LinkedIn and physical certificates
02:44 Launch of the IT/OT Academy Deep Dives, with one year of free access
05:24 Introduction of Gregory and kick-off
07:08 Gregory’s journey: automation engineer, Monsanto, Cloetta, Waterleau
08:45 The industry 3.0 stack and why real plants are more complex than the diagrams
15:26 Meet Cloetta: brands, scale and sites
19:29 How a wine gum is made, from batch to continuous to packaging
28:16 Group OT manager: eight factories, 100+ lines and the digitalisation mission
33:13 Miro: pilots that never made it past the pilot stage, and why
39:50 Meet Waterleau: water treatment, recovered energy and smart finance models
49:22 The Waterleau digital team and its mix of IT and OT profiles
50:20 Miro: the skill nobody taught you
55:27 Two in-house products: engineering platform (WIP) and SmartLab
56:44 Recurring revenue from plant data
1:02:50 Break
1:03:25 Digital maturity: start with knowing what is happening now
1:05:54 Miro and discussion: how to deliver value fast, and “don’t aim for the moon”
1:12:12 From the ISA-95 pyramid to the unified namespace
1:17:36 Q&A: one UNS for the whole company? Hallucinations on missing data and UNS as a single point of failure
1:24:16 Poll: who has a UNS in production?
1:26:16 The big shift: data requirements for vendors and the PackML lesson
1:29:45 Seven years of standardising across factories, and why greenfield is easier
1:33:21 The Ignition architecture, the €50K factory and staying below the signing threshold
1:37:31 Sparkplug B vs flat MQTT, and the problem of historical data
1:40:23 The Waterleau stack: Ignition to Postgres/TigerData, EMQX and Superset
1:45:03 Advice: build a home lab, and how AI coding speeds it up
1:48:01 Sweet Harmony Treats repos on GitHub
1:49:26 Closing remarks, next deep dive and certificates

Summary

What happens when the person running IT also takes charge of the people who keep the water flowing? Stephanie, who spent almost three decades in IT with no OT background, took that job at Halifax Water. She traded her desk for a hard hat, a 50-pound climbing harness and an H2S sensor, and went down PRV chambers and up reservoir towers to see what her new OT teams deal with every day. In this session she shares what she learned: why patching takes 30 minutes in IT and nine months of planning in OT, and why a single arc flash cabinet reminds you that the two worlds carry very different risks.

She also shows how Halifax Water brought both teams under one leader. There is one technology policy manual built on NIST CSF, with separate IT and OT standards only where they matter, and incident response plans that run IT and OT scenarios together. She explains the "IT/OT kill switch", a big red button that cuts remote access between the business network and the plants. She closes with candid Q&A on change management, data ownership and why data governance never ends. The key lesson is that unification starts with people. Get them into the same room, and sometimes into the same field boots.

In this session

00:00 Welcome and kick-off
00:53 Live poll: how well do we know IT and OT?
01:33 Meet Halifax Water
02:16 Stephanie's journey from IT programmer to executive
04:19 Poll results: cooperation levels and top themes
06:24 How OT got bounced around before unification
07:06 IT vs. OT: patching, lifecycles and risk tolerance
09:48 Boots on the ground: PRV chambers, towers and arc flash panels
15:19 80+ interviews and the unified technology strategy
17:23 One leader, one team: the new organisational structure
18:05 Enterprise architecture: firewalls and remote access
18:47 One technology use manual with NIST CSF
20:52 Incident response and the IT/OT "kill switch"
22:14 Auditing and centralised logging
22:58 Data analytics dashboards for OT and executives
23:42 Q&A: leading the change from silos to unification
27:07 Q&A: island mode and how the kill switch works
29:54 Why speaking both languages builds trust
32:01 Q&A: linking OT data with ERP, finance, GIS and HR
35:24 Q&A: data ownership, standards and governance
38:09 Closing remarks and how to connect

Summary

What does it take to build a Unified Namespace in a real manufacturing company, beyond the architecture diagrams? Bram, a former ExxonMobil automation engineer who now leads digital transformation at a large bakery group, takes you through the full journey. He starts with disconnected PLCs scattered along 250-meter production lines, and shows why cybersecurity had to be a design criterion from day one. He also shows how treating the factory as a black box turns a vague digital ambition into a business case a CFO can approve. Along the way you hear what happens when two sites both report "OEE" and mean different things, how a dual naming convention lets OT engineers keep their familiar tag names while the enterprise works from a clean asset structure, and why headcount reduction is rarely the real prize.

This session is full of practical lessons that don't show up in vendor slides. Bram explains why operators and process experts need to be on the project team from the start, how to build trust through transparent calculations, and how to use peer validation so rollout speeds up (the first 100 lines were slow, the next 200 were fast). He also shares his technology choices, from Litmus to TimescaleDB over Influx, and introduces the "six batteries of change" model. The live discussion adds real depth, with participants from utilities, pharma and IoT platforms pushing back on topics like standardization, derived data and where the master naming convention should live.

In this session

00:00 Welcome and Bram's background
04:47 Round table: who's in the room
10:13 The starting point: disconnected PLCs and the case for a UNS
16:31 Cybersecurity from day one: ISA-95 layers and OT control
21:55 The roadmap: use cases, standardization, pilots and rollout
25:50 Q&A: selling standardization when every plant is unique
27:26 Finding the value: treating the factory as a black box
32:04 Pilots and change management: two factories and a burning platform
36:46 Q&A: getting sites on board with trust and a carrot
42:13 Getting projects approved: size of the prize and the CFO
49:55 Pilot results: waste reduction and man-hours per ton
53:00 Debate: headcount reduction vs. productivity
59:11 People: co-designing dashboards and building the right project team
1:11:04 Process standardization: when two sites define OEE differently
1:14:12 The target IT/OT architecture
1:20:28 Naming conventions: asset structure vs. tag names
1:27:31 Derived data and the limits of a UNS namespace
1:32:16 Q&A: where does the master naming convention live?
1:39:18 Change management: the six batteries of change
1:43:10 Practical tip: screenshot-based tag mapping with process engineers
1:45:34 Technology choices: Litmus, TimescaleDB and platform selection
1:49:28 Closing thoughts

Summary

Why do so many AI initiatives never make it from pilot to real impact? Jan Meskens, a data and AI strategist, calls it the gap between hype and reality, and he doesn't just describe it, he makes the audience try to diagnose it. He starts with a churn-prediction story from 2016 to show how much easier AI has become to apply today. Then he shares two honest use case stories that both looked promising and both stalled. One was a "guru" chatbot built to relieve two indispensable founders, and it got lost in translation because it didn't understand what the company's own terms meant. The other was an AI model that predicted realistic production times, and it worked, but it never reached production because the people it affected didn't trust it. You get to guess why before he reveals the answers.

The second half moves from lessons to a method. Jan explains why AI is only one small piece of a much larger puzzle, and why a pile of use cases is not a strategy. He introduces a quadrant for defining your AI ambition: AI explorers, operators, innovators and AI-native enterprises, each with real-world examples. From there he shows how to turn ambitions into use cases and a transformation program that builds shared foundations while you keep learning and adapting. He closes with five pitfalls to avoid, including trying to do everything at once and underestimating culture. If you've ever wondered why your AI pilot didn't scale, or how to stop starting over with every new use case, this one is for you.

In this session

00:00 Welcome and session kick-off
01:34 Data and AI strategy: between hype and reality
03:42 Why most AI initiatives fail to bridge the gap
05:08 Part 1, AI technology: a churn story from 2016
12:48 What changed in 10 years: team size, time to market, packaged AI
17:33 Part 2, AI speedboats: two honest use case stories
18:58 Use case 1: the "guru" chatbot and the indispensable founders
22:27 Exercise: why did the pilot fail?
26:54 Lost in translation: the missing context
34:37 The fix: semantic mapping, metadata and smarter chatbot UX
39:26 Use case 2: AI for production planning
44:22 Exercise: why didn't it reach production?
47:13 The real answer: people, trust and change
52:51 AI is a small piece of a bigger puzzle
59:53 Part 3, strategy: why a list of use cases isn't one
1:02:44 The AI ambition quadrant
1:04:52 Explorers, operators, innovators and AI-native: examples
1:14:30 From ambitions to use cases and roadmap horizons
1:16:35 The AI transformation program and the foundational accelerator
1:20:05 Pilots, scaling and adapting your plan every quarter
1:23:31 Five pitfalls to avoid
1:29:05 Closing

Summary

What if the key to improving a production line isn't a smarter algorithm but a better conversation with the people on the floor? Raf, who has worked in industry and now bridges IT, OT and lean teams, shares the story of a high-speed packaging line where leadership said "improve OEE" and nobody knew where to start. He introduces a simple framework of people, process and technology, and challenges a common trap: "paper on glass", where screens replace whiteboards but nothing really changes. He also explains why proof of value matters more than proof of concept, and why you should start small but with the end in mind.

The use case brings it all to life. Thousands of PLC fault codes become a handful of reason codes, checklists appear automatically when a changeover starts, and AGVs, weighing cells, LED emergency buttons and clickable camera clips fix the small delays that quietly eat up a shift. Raf adds "human intelligence" to the data with logbook links and escalations, and the line gets better for the people running it. In the Q&A he covers how a network of "digital ambassadors" and trusted peers took the pushback out of change, and why small, incremental investments can add up to big step changes.

In this session

00:00 Welcome and housekeeping
02:24 Raf's background and the plan: two insights, one use case
04:43 The challenge: improving OEE on a high-speed packaging line
07:02 Insight 1: people, process and technology
10:13 Build or buy? On-prem vs. cloud, internal vs. external
13:22 From project to process: building internal capability
16:35 The use case: OEE across a linked line and fault codes to reason codes
19:39 Paper on glass: digitization vs. digitalization vs. transformation
24:13 Conway's law: how design shapes the way people work
25:48 Start small, with the end in mind
27:23 Proof of concept vs. proof of value vs. MVP
33:37 Bringing data to people: real-time visualization and the morning meeting
37:26 Planned downtime, changeovers and automatic checklists
39:50 AGVs and synchronizing flows with data
42:06 Adding human intelligence: logbook, actions and videos
45:56 IoT buttons and weighing cells: fixing small delays
50:34 Cameras: a clickable video clip for every stop
52:51 Don't force choices: keeping reason codes simple
53:39 Industry 4.0 and insight latency: the human side
56:45 Q&A: what scalable really means
1:00:39 Q&A: organization, digital ambassadors and winning over resistance
1:07:44 Q&A: side effects of OEE and incremental investment
1:10:01 Closing

Summary

Why do factories that make completely different products, from Dutch peppernuts to cartridges to whey protein, run on the same few dozen building blocks? Marnix, a chemical engineer with a self-described "out of control" hobby for OT, has modeled more than 100 sites worldwide and has found that the answer lies in the verbs. Equipment and products change from site to site, but the process (evaporate, filter, mix, heat) stays the same. In this session he shows how ISA-95 and ISA-88 give you a shared language to describe any manufacturing organisation. He also shows how a library of about 60 process operations works like Lego bricks, letting you assemble a model of any plant and then move from process to equipment.

The practical payoff is large. A good process model is the foundation for naming conventions, context, operational excellence programs and scaling a data strategy across lines and sites. Marnix also takes on the hard questions: how to bridge ERP and shop floor, who should own the model (local complexity cannot be managed from a distant central function), and how a two-tier tagging approach splits enterprise and site naming. He ends with a challenge. Walk into a control room, look at the paper specifications on the wall, and ask why they aren't digital yet.

In this session

00:00 Welcome and Marnix's background
02:10 Thinking in Lego bricks: why standards matter
04:55 What we really mean by "process"
06:18 ISA-95: a common language for factories
09:05 ISA-88: from units to operations and actions
10:31 Process, product or equipment? Think in verbs
13:17 Unit operations: a library of ~60 building blocks
14:43 From process model to equipment model (the peppernut factory)
18:52 Why modeling matters for operational excellence and scale
21:36 The model as the basis for context and naming conventions
22:16 Q&A: bridging ERP and shop floor scheduling
27:07 Q&A: ISA-95 beyond physical modeling and maintenance data
29:57 Operational monitoring templates and mapping tables
32:06 Who owns the model? Conway's law and the IT/OT divide
35:38 The physical hierarchy debate
36:20 Two-tier tagging: enterprise vs. site
43:34 Carrots vs. sticks and untangling messy tag coding
44:54 Mind the gap: why paper specs still rule the control room
49:01 Key takeaways