Global Optimum vs Local Optimum: What the Difference Means in Practice

These two terms come from systems thinking and operations research, but their practical implications are directly relevant to how organisations design KPIs.

A global optimum is the best possible performance of the entire system end to end. In business terms, it reflects how well the organisation delivers value to the customer across the full value stream, from the first step in a process to the moment the customer receives the outcome.

A local optimum is the best possible performance of an individual function, team, or step within that system.

This is not a theoretical concern. It plays out in real organisations every day, in manufacturing, customer support, software delivery, finance, and any function where work crosses team boundaries before it reaches the customer.

Why Local KPI Optimisation Feels Right But Often Backfires

It is tempting to believe that if every team hits its KPIs, the organisation must be performing well. The logic seems sound: good parts should make a good whole.

But organisations are systems, not collections of independent units. Work flows across teams. Handoffs matter. Delays most often occur between functions, not within them. When KPIs are defined locally, teams naturally optimise for their own metrics, even when that optimisation creates friction, cost, or delay somewhere else in the value stream.

This is how well-intended measurement systems generate unintended consequences. No one is acting in bad faith. Everyone is doing exactly what they are measured to do. The problem is in how the measurement system was designed.

Three Real-World Examples of Local vs Global Optimisation

Manufacturing: Machine utilisation vs customer responsiveness

A production team is measured on machine utilisation. To maximise utilisation, they produce large batches. The local KPI improves. But inventory increases, lead times grow, and the organisation becomes less responsive to changes in customer demand. The team is performing well by its measure. The system is performing worse by the customer's measure.

Customer support: Handling time vs end-to-end resolution

A support team is measured on average handling time. To reduce call duration, agents rush conversations or transfer issues to other teams. Handling time goes down. But repeat contacts increase, escalations rise, and the time from initial contact to actual resolution grows. The local metric looks better. The customer experience gets worse.

Software delivery: Velocity vs reliability

A development team is measured on velocity or the number of features delivered per sprint. They ship more code faster. Meanwhile, incidents increase, deployment complexity grows, and the time to deliver stable value to users actually lengthens. Speed at the team level has created fragility at the system level.

In each case, the problem is not the team. It is the KPI. The measurement was defined at the wrong level of the system.

How to Design KPIs That Drive Global Optimisation

The most reliable way to encourage global optimisation is to anchor measurement in end-to-end value stream metrics. These metrics reflect how work flows across the organisation and how value is experienced by the customer, not how efficiently any single team processes its share of the work.

Examples of end-to-end value stream metrics include:

• - Lead time from customer request to delivery
• - First-time-right rate across the full value stream
• - End-to-end resolution time for customer issues
• - Rework rate across functions and handoffs
• - Cost or effort per outcome delivered to the customer
• - On-time delivery across the full process, not just the final step

End-to-end metrics naturally encourage collaboration because no single team can improve them alone. Improving lead time requires every function in the flow to coordinate. Reducing rework requires handoffs to be examined, not just individual steps. These metrics shift the unit of accountability from the team to the value stream.

The Danger of Over-Focusing on Team-Level KPIs

Team-level KPIs are not inherently bad. They become dangerous when treated as the primary measure of success rather than as diagnostic indicators.

Common failure modes of local KPI systems include:

• Rewarding activity over outcomes. A team completing tasks quickly looks good locally even if those tasks are not the bottleneck and the queue sits elsewhere.
• Shifting problems downstream. Teams optimise to get work off their plate, not to ensure it arrives in good condition at the next step.
• Creating inter-team conflict. When teams are ranked against each other on local metrics, incentives to collaborate disappear.
• Hiding systemic bottlenecks. The real constraint often lives between functions, not within them. Local KPIs make it invisible.
• Measuring what is easy, not what matters. Volume, speed, and utilisation are easy to count. Value delivered is harder to measure but more important.

A Practical KPI Design Framework for Operational Excellence

A balanced measurement approach separates outcome metrics from diagnostic metrics and ensures both are used for the right purpose.

1. Start with a small set of end-to-end value stream metrics tied directly to customer value. These are your north-star measures of system performance. Three to five well-chosen metrics are better than twenty fragmented ones.
2. Use team-level KPIs as diagnostic indicators, not definitions of success. When an end-to-end metric moves in the wrong direction, team KPIs help identify where in the system the problem originated.
3. Review metrics regularly for unintended local optimisation. If a team's KPI is improving while an end-to-end metric is deteriorating, the local metric is probably creating a problem somewhere downstream.
4. Encourage trade-off discussions rather than target chasing. Some local optimisations genuinely improve the whole system. Others do not. The only way to know is to examine the trade-off explicitly.
5. Make the value stream visible to everyone. Teams optimise for what they can see. When people can see how their work connects to the customer outcome, they make better decisions about where to focus improvement effort.

This is where process clarity becomes a precondition for good KPI design. You cannot define meaningful end-to-end metrics without first understanding how work actually flows across functions. That requires structured process mapping, not just data from existing dashboards.

Famla AI helps organisations build the process understanding that good KPI design depends on. By mapping how work actually flows end to end, teams can identify where value is created, where it is delayed, and where local optimisation is masking systemic problems, before designing the measurement system that will guide improvement.