There's a conversation that repeats in every Portuguese factory. The CEO says: "I need to know whether we're going to meet the production target this week." The operations director consults the Excel file. Twenty minutes later, after phoning the shift supervisor, talking to the warehouse and doing sums in their head, they reply: "I think so, but there's a problem on line 3." This isn't inefficiency. It's the norm. And it's the worst enemy of an OKR that actually works.

OKRs (Objectives and Key Results) arrived in Portuguese factories as a promise: clear targets, transparency, alignment. But 70% of the implementations we've seen failed not because the methodology was bad, but because they got stuck between the paperwork of the meeting and the silence of the shop floor. The director knows what the target is. The operator doesn't. And the data that should be feeding the dashboard is still on a shift sheet or in a conversation next to the machine. That's why 70% fail — not for lack of ambition, but because they try to measure what they can't capture.

The problem isn't the methodology. It's that in Portugal, only 53.7% of companies used an ERP in 2025 — without an integrated data core, the OKR works on sand. According to INE data (2025), integration between operational systems and analytics tools is still the exception, not the rule. This means that when a company defines an OKR, the first barrier isn't ambition. It's the ability to automatically capture the data the metric requires.

The bureaucracy that kills OKRs

A well-defined OKR looks simple: "increase machine availability from 72% to 80% in Q2." But when the implementation begins, the question no one wants to ask comes up: where does the data start?

We see this repeatedly. The company buys a nice dashboard, puts the target in it, and then waits for the data to arrive on its own. It doesn't arrive. What arrives is an emergency meeting two weeks later because no one can explain why the indicator suddenly jumped 15% in a day. Or why it dropped without anything having changed. Or why the number IT is showing doesn't match what the shift supervisor has in their head.

The reason is simple: between the OKR and the dashboard there's a capture vacuum. Without a system that automatically collects data from the shop floor, without clear integration between operations and BI, the OKR is held hostage by manual reports, outdated consolidation in Excel, different interpretations of each metric (does a 5-minute stoppage count as downtime?), and delays between the fact and the visualisation. The data you see on the dashboard is from yesterday. The decision you take is about the past.

This isn't a technology problem. It's a design problem. And this is precisely where most Portuguese industrial companies fail.

From the shop floor to the dashboard in real time

There's an abysmal difference between "having an OKR" and "being able to manage an OKR". The first is a document. The second is a living system.

When we work with a textile or metalworking factory implementing OKRs, the first question we ask isn't "what's your target?" — it's "where does the data you need to measure that target live?" Because if the answer is "in the previous shift, on the phone with the warehouse, or on a piece of paper sitting on the desk", then they're not ready for OKRs. They're ready to read a blog about OKRs.

The capture of operational data has to be automatic. Not because it's elegant, but because it's the only way for an OKR to be both ambitious and credible. Without this, what remains is a target that everyone knows is impossible to verify with rigour. And that kills commitment.

An OKR without automatic data capture is a management promise no one can keep, because no one can prove they kept it.

This means that before putting an OKR on a dashboard, the IT team and the operations director have to agree on three things.

What the source of truth is. If the OKR is "increase machine availability", the data has to come from a single place — it can be an industrial terminal connected to the machine, it can be an MES system, it can be automatic integration between the ERP and an IoT sensor. What it cannot be is "let's check three systems and then take an average". This destroys trust. When a metalworking factory in the Vale do Ave tries to measure OKRs using data that comes from three different sources, the result is always the same: a two-hour meeting to explain why the numbers don't match.

What the collection frequency is. A weekly OKR needs daily data, otherwise management is blind. A quarterly OKR can live with weekly data. But this has to be decided at the start, because afterwards it's difficult to change without redesigning the entire capture system.

What the acceptable latency is. Does the dashboard need to show yesterday's data? Today's? Now's? If it needs "now", then you can't use a report that comes out once a day. We see companies that define OKRs requiring real-time information and then use an Excel that they update on Fridays. This isn't negligence. It's a lack of alignment between what's promised and what's built.

Why Portuguese companies get stuck in the middle

We see this frequently: the company has an ERP (maybe an MULTI ERP, maybe a QAD Adaptive, maybe another). It has financial and production data in there. But that data doesn't talk to the BI. Or it does talk, but with a 24-hour delay. Or it talks only to some modules.

The result is that when the CEO asks "are we on track to meet the margin target this month?", the answer isn't a line on a dashboard. It's a 90-minute meeting with the controller, the sales director and IT.

Most Portuguese industrial companies have systems that work in silos. The ERP talks to accounting. The production system talks to the machine. The BI talks to whatever it can reach. No one talks to anyone in real time. When they start implementing OKRs, they discover this the hard way: in the middle of a follow-up meeting, when the number the dashboard shows doesn't match the number the operations manager has in their head.

The solution isn't more bureaucracy. It isn't creating a new report. It isn't asking the shift supervisor to fill in an extra form. The solution is to design data capture so that it's invisible to the people doing the work. The operator doesn't want to know they're feeding an OKR. They just want to do their job. The data has to flow as a side effect of normal operations, not as an additional cost. This is what real-time production capture enables: the terminal the operator already uses to record production simultaneously feeds the OKR, without any additional work.

Three signs that your OKR is doomed before it starts

First sign: the target is nice, but no one can explain where the data comes from. If you ask "how are we going to measure this?", and the answer is "IT will look into it", then you're not ready. IT has to be involved from the design of the target, not after it's ready. This isn't bureaucracy. It's engineering.

Second sign: the collection frequency is different from the decision frequency. If the OKR is monitored weekly, but the data only arrives monthly, the OKR is useless. It's like trying to drive a car looking in the rear-view mirror. The decision you take on Monday is based on data from three weeks ago.

Third sign: the dashboard doesn't ask questions, it just shows numbers. A good OKR dashboard isn't a table of metrics. It's a system that says: "we're below target — what changed since yesterday?" If the only thing the dashboard does is show a red or green number, then you're not using OKRs. You're using a traffic light.

Concrete case: when automatic capture changes the game

A textile factory in the Vale do Ave with 120 employees had a simple OKR: "reduce the decision time on production adjustments from 90 minutes to 30 minutes in three months." It seemed ambitious but realistic. Until they started implementing it.

The problem arose in the first week: decision time wasn't a single metric. It included data collection time (45 minutes), consolidation time in Excel (20 minutes), and the alignment meeting time (25 minutes). Without automatic capture, it was impossible to measure only the real decision time — everything was mixed together.

When they implemented automatic real-time production capture connected to Qlik Sense, the scenario changed completely. The data reached the dashboard without manual intervention. The collection time disappeared. The consolidation time disappeared. The meeting time dropped to 10 minutes because the dashboard already showed the answer. Result: real decision time went from 90 minutes to 15 minutes in seven weeks. They saved 75 minutes per decision, which meant 6 hours a week of meetings avoided — time that went back into production.

This wasn't magic. It was the direct effect of having designed data capture as a prerequisite, not as an afterthought. The OKR only worked because the engineering behind it was done first.

An OKR that depends on a meeting to be explained isn't an OKR. It's an excuse disguised as management.

What we learned (and where we were wrong)

Five years ago, when we started implementing OKRs with clients, we thought the challenge was choosing good metrics. We were wrong. The challenge is ensuring that the metric you choose is the same one the system can measure every day, without failures, without interpretations.

We saw a textile factory in the Vale do Ave that defined an OKR to "increase the production cycle by 12%". It sounded good. But then we discovered that "production cycle" meant different things depending on who was talking. For the production manager it was machine time. For the warehouse it was delivery time. For IT it was processing time in the ERP. When they put it all together, the OKR disappeared. Literally, they couldn't measure it because the metric was a ghost of three different definitions.

This is common. And it's avoidable. All it takes is for someone at the start to say: "before putting this into an OKR, let's align on three things: what this is, how we're going to measure it, and who is responsible for ensuring the data arrives every day." A metalworking factory in Oliveira de Azeméis that did this managed to go from OKRs no one believed in to OKRs that guided real decisions. The difference wasn't the methodology. It was having a system that automatically captured what needed to be measured.

When this happens — when there's a system that captures automatically, when the dashboard updates without manual intervention, when everyone knows exactly what's being measured — OKRs stop being a management chore. They become a reflection of the real operation. At that point, they stop being bureaucracy. They start being useful.

The question you should ask at the next meeting

Ask your IT team: "If I defined an OKR today, how long would it take for the data to reach the dashboard, automatically, every day?" If the answer is "two weeks" or "a month", then you have an architecture problem. If the answer is "never, because the systems don't talk to each other", then you have a bigger problem.

And ask your operations director: "How many hours a week does someone spend consolidating data manually for management reports?" Because that time — that time that comes out of production's pocket — is the invisible cost of not having an OKR that works. It's the cost of being stuck between the paperwork and the dashboard. When you can eliminate that time, when the data flows automatically from the shop floor to the dashboard, that's when you discover that OKRs weren't the problem. The problem was the engineering behind them.

Frequently asked questions

What is an OKR and why does it fail in Portuguese factories?

An OKR (Objectives and Key Results) is a methodology for clear, aligned targets. In Portuguese factories, 70% of implementations fail not because of the methodology, but because the targets get stuck between meetings and the shop floor. The operator is unaware of the target, and the data remains on paper or in informal conversations, without automatic capture to feed the dashboard.

What is the biggest obstacle to implementing OKRs in production?

The biggest obstacle is the capture vacuum between the OKR and the dashboard. Without a system that automatically collects data from the shop floor and integrates operations with analytics tools, the OKR is held hostage by manual reports in Excel, different interpretations of metrics and delays between the fact and the visualisation.

Why is automatic data capture important?

Automatic capture is essential because an OKR without it is a promise impossible to verify with rigour. Without automatic data, the target becomes ambiguous and kills commitment. It's the only way for an OKR to be both ambitious and credible, allowing management to make decisions on current data, not on the past.

What should the source of truth be for an OKR?

The source of truth should be single and agreed between IT and operations. It can be an industrial terminal, an MES system or integration between the ERP and IoT sensors. It should never be "check three systems and take an average", as this destroys trust and generates clarification meetings about discrepancies in the numbers.

How to choose the data collection frequency for an OKR?

A weekly OKR requires daily data for effective management. A quarterly OKR can work with weekly data. This decision must be taken at the start of the implementation, since changing the capture system afterwards is complex and disruptive to the entire operation.

What does acceptable latency mean in an OKR dashboard?

Latency is the delay between the fact occurring and appearing on the dashboard. It must be aligned with the need: if you need data "now", you can't use an Excel updated weekly. Many companies define OKRs that require real time but use outdated reports, creating critical misalignment.

Why don't Portuguese ERPs solve the OKR problem on their own?

Although 53.7% of companies use an ERP in 2025, integration between operational systems and analytics tools is still the exception. ERPs work in silos: they talk to accounting, but not to BI in real time, or with 24-hour delays. Without real integration, the OKR works on fragmented and outdated data.