One Cockpit, Not Four Portals: Getting a Single OEE Number Out of a Mixed CNC Fleet

There is a specific kind of Monday morning that only happens in a contract machine shop. You have four machine-tool portals open. Each was included with the machine, each is competently built, and each is telling you a different truth about the same week.

This article is about how that happens, what it actually takes to get one honest number off a mixed fleet, and the four decisions you have to make before anyone connects a single cable.

Industrial Reality Check

The newest cell reports 78 percent OEE. The two mid-life machines report 71 and 64. The 1998 machine reports nothing at all, because it has no portal, so somebody wrote its downtime on a clipboard and the clipboard is in the foreman's van.

You need one number for the customer audit on Thursday. You have four numbers and a clipboard.

The instinct at this point is to work out which portal is lying. That instinct is wrong, and following it costs shops months. None of the portals is lying. They are each answering a slightly different question, correctly, and nobody ever agreed which question you were asking.

What follows is the version of that morning nobody puts in a brochure. The production meeting spends its first twenty minutes not on what to do about the loss, but on which number is real. A quality manager quietly maintains a parallel spreadsheet because they stopped trusting all four. The customer asks for a capacity commitment and the honest internal answer is "somewhere between 64 and 78 percent, depending which screen you believe." That is not a reporting inconvenience. It is a shop that cannot price its own capacity with confidence, which eventually shows up in the margin rather than in the dashboard.

Why the Problem Exists Structurally

Industry material has a habit of describing the multi-vendor machine park as a transitional problem — something you grow out of once the fleet modernises. In a contract shop it is not transitional. It is the business model.

A Lohnfertiger buys capability when a customer contract justifies it. Machines arrive in the order the order book demanded them, across two or three decades, from whichever builder had the right envelope, the right accuracy and the right delivery date that quarter. A shop with twelve machines and five builders is not badly run. It is a shop that bought what the work needed, which is the correct behaviour for a business that sells capacity rather than a product line.

The consequence is structural: you cannot buy a single-vendor answer to a multi-vendor question.

Every machine builder's digital offering is designed, reasonably, around its own installed base. It will be excellent for their machines and silent about everyone else's. Four excellent portals do not add up to one shop view, and no amount of licence spend changes that — because the gap is not a feature gap. It is a scope gap. Asking a builder's portal to report on a competitor's machine is asking it to be a different product.

This is worth being clear-eyed about, because it determines where you spend. The portals are not the problem, and replacing them is usually waste. They are genuinely good at machine-level diagnostics, service history and builder-specific detail — the things that need deep knowledge of that machine. The mistake is asking them to also be a shop-level reporting system, a role none of them was built for and none of them will grow into.

Architecture Deep Dive

OEE is a simple formula with a deceptive amount of judgement inside it.

OEE = Availability × Performance × Quality

Nobody disputes the arithmetic. Every disagreement between your portals lives in the definitions underneath it, and there are four places where reasonable engineers reasonably differ.

Fork 1 — what counts as "planned"

Availability is uptime divided by planned production time, so everything depends on what you agreed to call planned.

Is a scheduled tool change planned downtime, or a loss? Is the twenty minutes of morning warm-up production time? What about the gap between two jobs, when the machine is available and there is simply nothing to run — fleet problem, scheduling problem, or excluded entirely?

One portal excludes warm-up. Another counts it as a loss. Same machine, same week, several points of OEE apart, both defensible. This single choice moves the number more than most people expect, and it is the one most often left undecided because it feels like a detail.

Fork 2 — where the ideal cycle time comes from

Performance compares actual output against a theoretical best, and that best has to come from somewhere. Shops draw it from at least three places: the builder's rated cycle, the CAM-calculated cycle for that specific part, or the best cycle actually achieved on that machine in the last quarter.

These are not close to each other. The builder's rated cycle applied to a part it was never rated for makes a well-run machine look chronically underperforming. Best-ever-achieved flatters performance and hides real drift — it silently re-baselines every time somebody has a good day. Mixed fleets almost always end up mixing sources, because each portal defaults to whatever its own builder considered sensible.

Fork 3 — when a part is counted, and where scrap lands

Quality sounds like the easy term. It is not, because it depends on where in the process the count happens.

Count at the machine, and scrap found later at inspection never returns to that machine's OEE — the machine looks better than it was. Count after inspection, and the number is honest but arrives days late and cannot be used to run the shift. Count rework as good and quality flatters; count it as scrap and it punishes twice for one event.

Fork 4 — what "running" means to the control

This is the one that surprises people, and where mixed vintage bites hardest.

Controls expose machine state at genuinely different resolutions. A modern control distinguishes cutting, rapid traverse, tool change, feed hold, alarm state and program end as separate conditions. An older control may expose one bit meaning "the spindle is turning."

If one machine reports feed hold as a stop and another reports it as running, you are not comparing two machines. You are comparing two definitions wearing the same word.

What your controls can actually emit

Before this becomes practical, you need a sober view of what your existing machines can tell you today — without a retrofit, without replacing anything. Machine data leaves a control through a small number of well-understood routes, and knowing them by name is the vocabulary you will use to hold a vendor conversation.

OPC UA, and umati on top of it. OPC UA is the broadly adopted industrial standard for structured, secure machine communication. On its own it defines how to talk, not what to say — which is why two OPC UA machines can still be mutually unintelligible. That gap is what umati exists to close: a companion specification driven from the German machine-tool industry through the VDW, standardising what a machine tool should call things, so that a given state means the same thing on two machines from two builders. Where you have it, it is the cleanest route available, and it is the direction the industry is genuinely moving rather than a standard waiting for adoption.

MTConnect. An open, read-only standard originating in the American machine-tool sector, publishing machine state over plain HTTP in a structured document. Read-only is a feature here, not a limitation: it cannot write to your control, which makes for a much shorter conversation with whoever is responsible for that machine still making parts on Friday.

Modbus over TCP. Old, extremely widely implemented, far simpler than the two above — registers and coils rather than a semantic model. Nothing tells you what a value means; you supply that knowledge, and you maintain it. For many auxiliary devices and older equipment it is what is actually there.

Nothing at all. The case the brochures skip, and in a real shop often a third of the fleet: no network port, no documented protocol, or a control whose data option was never licensed. The honest options are a discrete signal off the machine — a stack-light state, a cycle-start contact, a current clamp on the spindle drive — or structured operator input at the panel. Both are legitimate. Both are lower resolution than a modern control, and any plan that quietly assumes otherwise will fail at exactly the machine you most needed to measure.

A note on scope: capability here is properly described by protocol, not by machine brand. Whether a specific control exposes a specific data point depends on its software version, its licensed options and how it was commissioned. Anyone who answers that question in a first meeting, without having looked at your fleet, is guessing.

A note on the machines you have already bought: since 12 September 2025, Article 4 of the EU Data Act has entitled the user of a connected product to the readily available data it generates, in a machine-readable format and free of charge, and Article 5 lets you have that data sent to a third party of your choosing. That does not turn a portal into a data model — it establishes access, not a format — but it changes the opening position of the conversation with a builder whose portal holds your machine's history.

The pattern that works

Shops that reach one honest number converge on the same shape, and the order matters more than the tooling.

First, agree the definitions — on paper, before anything is connected. One definition of planned time. One rule for ideal cycle time. One place where parts are counted and one rule for rework. One shared loss taxonomy: a short list of named reasons a machine was not producing. Keep it short. Six to ten reasons a shift lead can pick without thinking beat forty categories that get logged as "other."

Second, collect state, not just numbers. The most valuable thing to capture is not a count but what condition the machine was in when a value was produced. A cycle time without machine state cannot be interpreted later. This is the difference between data you can audit in six months and data you have to take on trust.

Third, give every signal one address. One consistent naming structure across the shop — site, area, line, cell, machine, component. It sounds bureaucratic until the first time you add a machine and nothing downstream needs rewiring, or the first time someone asks what a number meant last March and you can answer without opening four systems.

Fourth, compute the number once, centrally — from the agreed definitions, over the collected state. Not in each portal and then reconciled in a spreadsheet.

Fifth, publish the definition next to the number. A number whose definition is visible survives a customer audit. A number whose definition lives in someone's head does not.

Why Most Consolidation Projects Fail to Scale

Most shops do not fail at connecting one machine. They fail between the third machine and the twelfth, and the failure modes are consistent enough to name.

The pilot picks the easy machine. The newest cell, best documented, richest data, no argument about definitions because there is only one machine. It works beautifully, proves nothing about the fleet, and sets an expectation the rest of the rollout cannot meet.

Definitions get deferred to "phase two." Connecting is concrete and satisfying; agreeing what planned time means requires production, quality and maintenance in one room disagreeing. So the cabling happens first, and the shop ends up with a fast, well-engineered pipeline delivering numbers nobody trusts — which is the same position as before, with a licence fee.

The unreachable machines are left as a footnote. Eleven of twelve machines connected reads like success until the twelfth is the bottleneck, which it often is, because old machines get the awkward jobs. A fleet number that silently excludes a third of the fleet is not a fleet number.

One person becomes the integration. A capable maintenance engineer holds the mapping between tags and meaning in their head. It works, until they are on holiday during an audit. If the knowledge is not written into the model, it is not a system — it is a person, and people are not a scaling strategy.

The works council is consulted after the design is fixed. By then every accommodation is expensive, so the conversation becomes adversarial and the rollout stalls at exactly the point it was supposed to accelerate.

Governance, Security and EU Compliance Considerations

In a German shop, governance decides whether the project happens at all. It deserves to be a design input, not a hurdle at the end.

The works council. Any system that watches machines can be argued to watch the people operating them. That argument is not paranoia — it is the Betriebsrat doing precisely the job it exists to do, with genuine co-determination rights under the Betriebsverfassungsgesetz. The design answer is structural separation decided at the start: machine data and person data separated by design rather than by policy; the machine, not the operator, as the unit of analysis; and the actual data model shown to the works council early, in a meeting where changing it is still cheap.

Two cautions from experience. Avoid framing the system in terms of workforce productivity, individual performance or operator comparison — not because it reads badly, but because it describes a system nobody should build. And if a system can attribute an action to a named individual — any system with logins or approval steps can — say so plainly rather than claiming it never happens. A works council that finds an unmentioned capability on screen will not extend the benefit of the doubt again, and would be right not to.

GDPR. Machine data is generally not personal data, right up until it can be linked to a shift roster. The moment a machine number plus a timestamp can identify who was operating, you are processing personal data whether you intended to or not. Decide deliberately where that line sits, and write down the answer.

Security posture. A monitoring system that can write to a control is a different risk conversation from one that cannot. Read-only collection, network segmentation between OT and IT, and local buffering so a network interruption does not become a production incident are the baseline expectations. For shops in scope of NIS2, the supplier questions arrive whether or not you were ready for them; being able to describe your OT data path precisely is most of the work.

Decision Framework for Platform Evaluation

Judge any option against five criteria, in this order.

1. Fleet coverage, stated honestly. Not "supports major controls" — a machine-by-machine list of what will be reached, by which protocol, and what will not be reached at all. The willingness to name the gaps is the signal.
2. Definition ownership. Whose definition of availability ends up in the number, and can you change it later without a professional-services engagement?
3. Reconstructability. Can you answer, six months on, what was measured, over what window, in what machine state? If not, the number cannot survive scrutiny.
4. Independence from any one builder. If consolidating requires committing to one builder's ecosystem, you have re-created the original problem with an extra layer.
5. Exit. What do you own if you stop paying? Historical data is yours or it is not. Establish this before signing, not after.

Executive Summary — Board-Level Interpretation

For a board or a Geschäftsführer, the argument reduces to three sentences.

One. The shop cannot currently price its own capacity with confidence, because it does not have a single agreed measure of what capacity it has. Every commitment made to a customer carries an unquantified margin of error, and that error is absorbed silently in margin.

Two. The fix is mostly organisational, not technical. The expensive part is agreeing definitions across production, quality and maintenance; the connection work is comparatively routine. Budgets that fund only the technical half reliably produce a fast pipeline of numbers nobody trusts.

Three. The return does not come from the dashboard. It comes from being able to say, to a customer or an auditor, exactly what a number means and how it was derived — which is what converts an operational metric into a commercial one.

Sequenced properly, this is a project with a visible result inside a quarter. Sequenced backwards — cabling first, definitions later — it is a project that consumes a year and ends in a spreadsheet.

Practical Implementation Checklist

Before anything is connected

• Write the fleet inventory: every machine, its control, whether it can speak, and by which protocol.
• Mark the machines that cannot speak. Decide now what happens to them — discrete signal, operator input, or explicitly out of scope.
• Convene production, quality and maintenance. Agree the four forks: planned time, ideal cycle source, count point and rework rule, machine-state definitions. Write them down and have them signed.
• Agree the loss taxonomy. Six to ten reasons, in the words the shop floor already uses.
• Show the works council the data model. Early, while it is still cheap to change.

During connection

• Start with a representative machine, not the easiest one. Include one difficult machine in the first wave.
• Capture machine state alongside every value, from day one. Retrofitting state later means re-interpreting history you cannot re-collect.
• Apply one naming structure from the first machine, not the fifth.

Before it is trusted

• Reconcile against a known week by hand. If the computed number and the manual reconstruction disagree, resolve it before anyone reports the number upward.
• Publish the definition alongside the number, in the same view.
• Rehearse the audit question: pick a shift from three months ago and reconstruct why the number moved.

A note on where we stand

We build software in exactly this space, so we are not a neutral party and it would be silly to pretend otherwise. What this article deliberately does not do is describe what our software does. The product is under active development as this is written, and a capability sentence written this month would be a description of last month's product, published under a real company's name. We would rather say nothing than say something that is checkable and wrong by the time you read it.

So judge any supplier, including us, on the five criteria above and on nothing else: a machine-by-machine coverage list that names its gaps, definition ownership, reconstructability, independence from any one builder, and what you own if you stop paying. A vendor who will not answer the fifth question in writing has answered it.

If you want to sanity-check your own position before talking to anyone, we publish a free self-assessment at criussoftware.com/res/kits/readiness/. It asks for a work email and returns a scored result. It is a self-check, not an audit, and it will tell you honestly if the answer is that you are not ready to connect anything yet.

Questions worth asking in your next review

1. If three people in your shop were asked what counts as planned production time, would you get one answer or three?
2. Where does the ideal cycle time in your performance number actually come from — the builder's rating, the CAM calculation, or the best shift anyone ever ran?
3. At what point in your process is a part counted, and where does scrap discovered at inspection land?
4. Which machines in your fleet cannot report anything today, and what is the specific plan for them — not the aspiration, the plan?
5. For any OEE figure you reported last quarter, can you reconstruct what was measured, over what window, in what machine state?
6. Are machine data and person data separated structurally in your design, and has the works council seen that design rather than been told about it?
7. If your monitoring supplier stopped trading tomorrow, which of your historical production data would you still have?

The part that matters

The four portals on your screen are not the problem, and consolidating them is not primarily a technology project.

It is an agreement — about what planned means, about where ideal cycle time comes from, about when a part is counted — written down before any cable is pulled, and then computed once instead of four times. The shops that reach one honest number are rarely the ones that bought the most capable platform. They are the ones that decided what the number meant before they went looking for it.

The 1998 machine still will not tell you much. But a shop that knows exactly what that machine cannot say, and has decided what to do about it, is in a materially stronger position than a shop with four confident dashboards that quietly disagree.

One number, one definition, visible to anyone who asks. That is worth more on Thursday morning than four portals ever were.

Sources

All sources were opened and read on 23 September 2026.

1. OPC 40501-1, OPC UA for Machine Tools, version 1.02 — the umati companion specification that standardises what a machine tool reports to MES, SCADA, ERP and analytics systems. umati.org/industries_machine-tools/
2. umati — the VDW-hosted initiative for open, OPC UA-based interfaces across the machine-building industries; some 25 companion specifications published, around 30 in development. umati.org
3. Betriebsverfassungsgesetz § 87 Abs. 1 Nr. 6 — co-determination on "technischen Einrichtungen, die dazu bestimmt sind, das Verhalten oder die Leistung der Arbeitnehmer zu überwachen". gesetze-im-internet.de/betrvg/__87.html
4. Regulation (EU) 2016/679 (GDPR), Article 4(1) — "personal data" means any information relating to an identified or identifiable natural person, including identification indirectly by an identifier or a combination of factors. gdpr-info.eu/art-4-gdpr/
5. Regulation (EU) 2023/2854 (Data Act), Article 4 — where data cannot be accessed directly from the connected product, the data holder makes readily available data accessible to the user without undue delay, free of charge, in a structured, machine-readable format. data-act-law.eu/article/4/
6. Data Act, Article 5 — on the user's request the data holder makes readily available data available to a third party of the user's choosing. data-act-law.eu/article/5/
7. VDW press release, 9 September 2026 — German machine-tool order intake up 12 percent in the second quarter of 2026 and 14 percent in the first half; capacity utilisation stabilised at around 75 percent. vdw.de
8. AMB 2026, Messe Stuttgart, 15–19 September 2026 — the biennial metalworking exhibition where umati and OPC UA interfaces are shown on the machines themselves. messe-stuttgart.de/amb
9. MTConnect standard documentation index, current version 2.5.0 (January 2026). docs.mtconnect.org

Write the fleet inventory first: every machine, its control, whether it can speak, and by which protocol. It costs an afternoon, and it is the first document a supplier cannot talk around.