Industrial Automation terms like Digital Plant, Digital Transformation, and MES get tossed around so much that I fear they are losing their meaning in the modern-day marketing miasma. I’m not here to sell you on my definitions, but I do want to clear the fog so we can all move forward with smoother conversations and a clearer strategy. At the end of the day, the point is to get more done with less. And that starts with speaking the same language.
We'll cover:
- Digital Plant - one step closer to lights-out
- Digital Transformation - time doesn't heal all technical debt
- MES - 20 ways to say OT software
- OEE - it is what you make it
- Unified Namespace - one name (space) to rule them all
- AI - an homage to context
- UX - the roadmap to success
- Vertech - your trusted guide
Digital Plant
What it is: A target maturity level for a manufacturing plant characterized by full automation and data digitization.
What people think it is: This image.
To understand Digital Plant, we must first understand programming. Programming is kind of an art, but it’s not like painting a picture. It’s kind of a science, but it’s not like building a house. It’s a young medium – after all, your computer thinks history began on January 1st, 1970. So we don’t have a lot of famous programmers to put on posters, and we don’t have a lot of code that we consider “masterpieces”.
I remember watching my nephew playing video games on the couch, and how fascinated I was by the ratio between how little he was doing and how much his character was doing in the game. His whole body was relaxed. He moved only one muscle: his thumb, and he moved it one millimeter. You could replace his caloric expense with a single Skittle. But his video game character, wearing full plate armor, leapt into the air, swung a giant sword, and sliced a monstrous dragon in two. My nephew did something small, but something big got done. That’s the input to output ratio, and what, ultimately, I’ve decided programming is: The field associated with getting the most done by doing the least.
That’s why the compiler was invented, so we could do less. It’s why we call it “coding”, because something simple that a human can understand gets encoded into something complex for a computer. It’s why programming as a medium has grown exponentially. Programmers are not superheroes. They do about the same amount of work as their predecessors did in 1970, but the things they get done are colossal. They are literally moving and shaping the world every day. The effort they contribute, by comparison, is minuscule. They edit text files. They push keys on a keyboard.
The Digital Plant is a product delivery system that has been programmed. Not because programming is cool or fun, but to allow companies to do less and get more done. Plant leaders have a personal, dollars-and-cents relationship with the amount of work done on their factory floors.
When I look down the production line and see someone scribbling values onto a paper clipboard instead of using a tablet, I see real time and revenue lost, because that data will have to be entered again into a computer later. If I see operators struggling to use outdated screens, if I hear questions about the state of production that can only be answered with a phone call to the factory floor, if I see lackluster data quality that has eroded everyone’s trust in the very system their livelihoods depend on, I see opportunities for plant digitization.
We should be doing less. We should be getting more done. “Plant Digitization” is the process of bringing every event and data point from the plant floor into a computerized record. Full digitization is a necessary step on the way to “Lights Out” manufacturing, that ideal, fully automated factory where humans are so unnecessary that robots go about their work in pitch darkness. There is no Lights Out manufacturing process that was not first a fully Digital Plant. So what are some key elements that make a digital plant fully digital, based on modern standards? Let's start with digital transformation.
Learn more about how we define Digital Plant Services (and key benefits) here.
Digital Transformation
What it is: An active campaign of plant data digitization.
What people think it is: A sequence of plant modernization that will just happen with the passage of time.
“I see plant floor improvements happening every day. Maybe if we do nothing, the system will trend toward digitization on its own?” I hope you don’t have this mindset! When left alone, a manufacturing system tends toward grafted components, which are a collection of short-term solutions held together by band-aids. Each solution may have been sufficient to fix the one problem that came up that day, but there was no forethought given to scalability, refactorability, or readability.
Clean, cohesive systems take active effort. Clean systems take discipline. Clean systems take investment:
- A bucket of hours set aside to pay down technical debt
- A team dedicated to iteratively improving process
- UX research to uncover underlying issues
- The expertise to know when systems should be replaced outright
Digital transformation requires a comprehensive strategy. Some plants are just starting this journey, while others are a few steps ahead. There’s an opportunity for everyone to catch up with the right plan.
MES
What it is: A layer of abstraction (software/framework/logic) between SCADA and ERP, where order processing takes place
What people think it is: One of 30 different things, depending on who you ask
How do we have a reliable conversation about an MES (Manufacturing Execution System) if we don’t agree on what it is? At Vertech, we tend to stick to ISA-95’s definition, which outlines 11 things the MES layer is responsible for:
- Resource Allocation: Determining availability and utilization for machines, personnel, and materials.
- Performance Analysis: Measuring and optimizing the rate of goods produced.
- Quality Management: Determining and increasing the quality of goods produced.
- Operations Management: Overseeing the comprehensive production process from initial order to finished goods.
- Labor Management: Tracking employee time, attendance, and skills.
- Document Control: Creating and controlling access to documentation, including contracts, specifications, and work orders.
- Dispatching Production Units: Determining the optimal sequence of production tasks and assigning them to resources.
- Product Track and Trace: Documenting a product’s path through the line with a product genealogy.
- Data Collection and Acquisition: Collecting data, although this is a centralization and validation step. The “meat” of the data collection occurs at the SCADA layer.
- Maintenance Management: Monitoring equipment health.
- Process Management: Optimizing the production process on an equipment-specific level.
One thing all the functions have in common: They don’t happen by chance. Each one takes a targeted and deliberate effort to define and improve. The MES solutions are a tool. We can use them to spark conversations, identify blind spots, and yield big returns. Let's dive into one of the most popular MES solutions... OEE.
Read more about developing a modern MES strategy here.
OEE
What it is: A tool for iterative improvement in a manufacturing environment
What people think it is: An opportunity to juke the stats
Economist Ronald Coase said, “Torture the data long enough, and it will confess to anything.” OEE (Overall Equipment Effectiveness) is a powerful metric that is thorough enough to account for most production activity, yet simple enough that everyone in the plant may take part in its improvement. When it first started catching on as a mathematical tool, early adopters were able to find inefficiencies and improve their processes. Then something unexpected happened: The metric found its way into quarterly reports. Some companies started tying OEE to production bonuses for their employees. Now, too often, OEE is a tool people use to make themselves sound better than they are.
Bear with me while I climb up on my soapbox. It is very easy to cheat OEE. I don’t ever coach OEE without describing exactly how to do so, and how useless the metric becomes the moment you cheat. OEE works by envisioning the perfect, idealized plant, one where we produce as often as possible, as fast as possible, and at the highest possible quality. Real-life plants are not perfect, so how do we measure up against this ideal?
How often we produce vs. how often we can possibly produce is called Availability, how fast we produce against how fast we can possibly produce is called Performance, and how high quality our products are relative to perfection is called Quality. Calculate these values independently of each other, then multiply them together. Their product is a percentage known as Overall Equipment Effectiveness, or OEE. In this framework, OEE goes up when we produce more often, faster, or higher-quality goods. Does it work like that in practice? Depends on who’s doing the math!
I have met plant managers who actually believe their job with OEE is to define the proper categories of equipment downtime so that downtime at their plant doesn’t look as bad. This is the opposite of what you’re supposed to be doing. You’re supposed to be putting together a narrative where you measure OEE in the beginning, and then you see it start out low, then, by iterative improvement, you measure it the same way and find it to be higher. The first time you ever measure it, it will be low. That’s the whole point! There are so many stat jukers out there that I no longer believe anyone’s claimed OEE until I take a look at the calculation on the backend. To me, hearing that a company’s OEE went from 20% to 30% over a six-month period is a better narrative than hearing that a company’s “alleged” OEE is 90%.
Follow these three rules to avoid being an OEE cheat:
- Do not cheat Availability by calling more things “Planned Downtime”.
You want to show everyone you take OEE seriously? Measure your equipment availability against a 24-hour clock. State that 100% equipment availability is 24 hours a day, 7 days a week. This may yield a harsh-looking Availability number, but it is a fair one. The only way to make this number go up is to run your equipment more often, which is difficult. By contrast, throwing in more Planned Downtime makes the number go up, and it’s easy. “But my machine needs maintenance!” Yes, and if you discover a new and clever way to get the same level of maintenance while cutting maintenance time in half, don’t you want credit for that? Don’t you want to see that reflected in Availability? - Do not cheat Performance by setting a lower production speed target.
Performance is the easiest one to cheat. Performance is supposed to be measured against the faceplate rate of production at a machine. That’s the number written on the side: “This machine produces 100 widgets per day”. However, many companies don’t have that faceplate rating, so they say the Performance number is their actual production speed against a target they pull out of thin air. Just like that, they’ve found a way to make Performance go up that’s much easier than increasing production speed. Just decrease the target whenever you want! If you want your Performance metric to be fair, dig through the logs and find the absolute fastest that machine has ever run. There’s your Performance target. - Do not cheat Quality by lowering the plant’s standard of quality.
This is the hardest one to cheat, because the quality standard of your product is actually set by the customer. Nevertheless, just like with Performance, we can cheat the Quality metric by lowering our own standard of what a quality good is. I hope the audacity of that suggestion tells you how wasteful, how flatly useless the notion of fudging our OEE numbers actually is.
The only useful data is accurate data. I say this with sincerity, you are better off not calculating OEE at all if you plan to let someone juke the stats.
There are times I come out of a client meeting and think the OEE metric has done more harm than good, and that it should never have been introduced. Then I work with a company that takes iterative improvement seriously. These companies would never tie OEE to a production bonus, because a metric ceases to be useful when we make it more important than the thing being measured.
Only those companies that are data-focused and pursue accurate information fanatically are the ones who stand to benefit from an OEE calculation. To begin to quantify those benefits, you can play around with Vertech's OEE calculator tool here.
Speaking of pursuing accurate information, let's talk data governance and UNS.
Unified Namespace (UNS)
What it is: A way to organize data into a single, structured source of truth that connects to your entire system.
What people think it is: Any collection or organization of data.
“Namespace” is not a general-purpose word. We stole it from computer science, and we should respect its origin. A namespace is just a collection of identified things, no two of which can have the same identity. “Variable1” containing the letter “a” cannot exist in the same namespace as “Variable1” containing the letter “b”. So how did this term make its way into the world of industrial automation?
Consider a small manufacturing business that set up their first plant with a single piece of equipment, a pump. They named it “Pump” in their system. It did not make sense to name it anything else. That’s what everyone called it. It wasn’t until four months later, when the factory added a second pump, that the pump had to be renamed “Pump 1”.
There is a time and resource cost associated with renaming a piece of equipment. They had to pay this cost again when a sister site was built, and the original Pump became “Site 1 Pump 1”. They would go on to put a total of 10 pumps in that first factory before realizing that “10” comes alphabetically before “1” in their computers. So they had to rename the pump “Site 1 Pump 01”. In a twisted case of linguistic determinism, the number of leading zeros limited the number of pumps their namespace could contain.
Was there a better way? In the Unified Namespace, it is understood from the beginning that each piece of equipment will occupy the same namespace. Their names reflect what the enterprise is today, and everything it could be. The Pump might be named “Enterprise X/Site 1/Line 1/Pumps/Pump 01”, and it will be named once. Every real-time data event in the system publishes into a collection of data that is governed by this namespace. Every request for data pulls from the same collection.
The work you put into fulfilling these two requirements centralizes and connects disparate systems. The architecture diagram of your plant goes from being a tangled mess of spiderwebs to looking like a wagon wheel, with the Unified Namespace as its hub.
There’s a lot more to say about the UNS, and you can read more here: Understanding Unified Namespaces for Digital Transformation. But I use the Pump 1 illustration in client meetings to show the value of long-term, enterprise-level planning.
A shared namespace is the natural outcome of full digitization. Taking the time to define that structure will save effort down the road. With a UNS, you can...
→ Access reconciled data across your enterprise.
→ Build sustainable applications that don’t break with every update.
→ Begin to think about adopting AI in a meaningful way.
.png?width=600&height=300&name=CTA-UNS-UAF-Whitepaper(2).png)
AI
What it is: An advanced tool that’s really good at pattern matching.
What people think it is: A magic bullet solution for every problem.
AI tools like ChatGPT and Gemini are now part of the mainstream, and I could not be happier. Not because these tools are always effective, but because ordinary people are getting to interact with them and see them occasionally fail. When we rid ourselves of the fantasy that AI will solve all our problems, we’re free to apply it to the set of problems it’s good at solving.
Follow these 3 tips to get the most out of your interactions with AI in an industrial environment:
- Understand sample size: If you ask an LLM (Large Language Model) a question that 2 million people have asked, you’re liable to get a good answer. That model had a lot of material to train on, so its confidence is high. Very specific questions that require individual expertise? Not so much. Stick to academic research papers and qualified sources.
- Don’t flood the prompt: AI might be powerful, but it has a finite ability to solve the problem you are asking about. If you are used to making ChatGPT respond like Bugs Bunny for a laugh, you should know that it has to spend resources adding “What’s up, doc?” that could have gone toward a better solution to your problem.
- Ask the right question: Startups are popping up everywhere that promise AI-based solutions to everything. They claim to be able to point an LLM at your company’s data and interrogate it with natural language. Often, when people use these tools, they come away disappointed. Why?
The answer lies in what’s being asked. I divide LLM queries into two types:
Type 1: How many products on Line 3 were defective yesterday?
Type 2: What 3 changes should I make in operations to improve revenue at my plant?
The first type translates naturally into a SQL query on data you have already collected. We can expect a reasonably good outcome from that question.
Unfortunately, executives have a habit of asking the second type. This type of question is subjective, takes multiple steps to solve, and has more opportunities for the model to fall into traps along the way.
Finding a relationship between variables is not useful if you’ve left the root cause out of your initial set. Is our set of input data comprehensive enough to give a real answer to this question? Probably not. We should expect a generic answer, one that is not truly based on our plant’s data.
You can apply this logic to any AI solution you evaluate. Your MCP (Model Context Protocol) should be more than just an API wrapper for an LLM. For AI to be effective, you need to go a step further and create a contextualized information layer that sits on top of your UNS. Then and only then can you tap into more of those executive-style questions.
Timebase by Flow Software is a solution that contextualizes data (including events and KPIs) and stores those results. This way, when you connect to AI, it doesn't rely on a loose interpretation of the data. It can access a buffet of engineering-level process knowledge of your plant. So, because of that increased contextualization, it can respond accurately. (We'll have more to say about this in the coming months.)
So yes, AI is just a tool. It's not a magic bullet. Enjoy experimenting with it, but remember that the real key to AI enablement is immaculate data hygiene (UNS) and context, context, context. You can't go wrong with a good foundation.
UX
What it is: User Experience, the field of study and expertise focused on human-centered product design
What people think it is: Something that is nice for apps and websites, but unnecessary in a plant floor environment
Here’s the thing: none of this digital transformation stuff works well without good UX research. You can make an educated guess about what operators, engineers, and supervisors need. But it's better to actually ask them. UX research done well uncovers the real pain points on the plant floor and gives you the evidence you need to build a rock-solid development roadmap.
In short, UX research is how you make sure the software / screens you build are solving problems instead of creating new ones. And that upfront work pays off later. Software adoption is smoother because it caters to how people really work, and risk drops off because you’re not relying on assumptions. (No one wants to change their project scope halfway through because they solved the wrong problem.)
A good example is the field of web design, which benefits greatly from comprehensive UX research and user studies. The time we spend viewing a page, where we click, and whether or not we got what we came for are all captured and subjected to analysis. This makes sense online because a website’s revenue is directly tied to clicks and utility. Large web design companies would never dream of installing a website without performing UX analytics as a follow-up. So who is applying the same scrutiny to your plant floor operator screens? Were they built to “just work”, or were they built with the comprehensive user experience in mind?
I have a lot to say about how a screen should look, but I’ve decided here to focus on UX. Here are 3 UX best practices that have nothing at all to do with aesthetics:
- Take the path of least surprise: It’s a mistake to think of screen design as a creative endeavor. The ones who decided what a UI should look like and how it should be used worked at IBM, Apple, and Microsoft in the 90s. They made the rules for checkboxes, scroll bars, and radio buttons, and now we follow them. Period. When your user interacts with plant controls, they should do exactly what the user expects. It’s a bad sign if I set up screens and have to book several extended training sessions to show operators how to use them. These same operators got around their phones and car dashboards just fine without any workshops, so my screens should be equally intuitive.
- Label buttons with an imperative statement: Every button should have a label with an imperative statement commanding the action the button will execute. The button that opens the door should be labelled “Open Door”, never “Door Open”. If you think this is obvious, count the number of times this rule is ignored the next time you look at an HMI screen.
- Add obvious separation between your controls and indicators: Behold, the bane of my existence:
Is it off? Is it on? Does the text indicate its current state or what will happen if I press the switch? The toggle button violates a very important rule: separate your controls and indicators. They should look different, occupy a different part of the screen, and no one should ever confuse the two.
As more disciplines converge in industrial automation, we cannot ignore the insights that come from good UI and UX design. UX Research is a proven industry standard in software development, and the quickest way to understand what will bring the most value to your plant. Staying current means your workforce can leverage the maximum benefits of digital systems rather than being held back by outdated processes.
Vertech
What it is: The trusted team of experts ready to deliver on your next Digital Plant project
What people think it is: The trusted team of experts ready to deliver on your next Digital Plant project
Vertech is a leading name in MES and Digital Transformation. We understand the value of good data, good UX, and industry knowledge. We’ve helped clients at all stages of their Digital Plant journey map out a solid strategy and quickly reach their potential. If you want to learn more about Plant Digitization, start here.
Comments