---
title: "Goal systems in e-commerce: OKR, Balanced Scorecard, or just a KPI tree?"
description: "OKR, Balanced Scorecard, KPI tree, Hoshin Kanri and MBO — five goal systems for one shop. Which one fits is decided by your data, team size and decision tempo, not by the trend."
canonical_url: "https://nuonic.de/en/insights/goal-systems-ecommerce-overview"
last_updated: "2026-11-03"
---

There is a sentence that reliably comes up in strategy workshops and sounds
as though something had been decided: "We're doing OKR now." Six months
later, two quarters' worth of objectives sit in a Confluence space, half the
key results never had a value entered against them, and the monthly meeting
argues about the same revenue figures as before.

The problem was not OKR. OKR works — in organizations whose data and decision
tempo fit it. The problem was that the system question was never treated as a
question. It was treated as a matter of taste, and the answer came from the
conference talk someone had seen in the spring.

The [first part of this series](/en/insights/measurable-ecommerce-strategy)
covered why goals without numbers are not goals. The
[second part](/en/insights/kpi-definitions-ecommerce) covered what a metric
has to look like for nobody to negotiate it any more. This article deals with
the layer above: what structure do those metrics actually hang in? Five
systems are candidates. They are not equivalent, and above all they are not
freely interchangeable.

## A goal system and an operating rhythm are two different things

Before the five candidates come to the table, a distinction whose absence
sinks most rollouts. There are two questions, and they are almost always
thrown into one pot:

**The goal system answers: what is being steered?** Which goals exist, how
they relate, which metrics each one hangs on, who owns it. That is a question
of structure.

**The operating rhythm answers: when are decisions made?** Which question
belongs in the weekly cycle, which in the month, which in the quarter. Who
attends, on which state of the numbers, and what the meeting produces. That
is a question of process.

A goal system without an operating rhythm is a document — nobody notices when
a gap opens up. An operating rhythm without a goal system is a standing
meeting in which what matters gets renegotiated every week. Both occur, and
both feel like steering without being it.

This article deals exclusively with the first question. The rhythm gets its
own part, because it decides at least as much about success as the choice of
system does.

## The five candidates

### MBO — Management by Objectives

The ancestor, described by Peter Drucker in 1954 in "The Practice of
Management". The idea: manager and employee agree on goals instead of
assigning tasks. Performance is measured by degree of attainment, usually
over a financial year and often tied to compensation.

In e-commerce you rarely meet MBO under that name, but constantly in
substance: annual goals per department, assessed at year end, with a bonus
attached. The strength is clear accountability. The weakness is the coupling
to compensation — as soon as a goal determines someone's pay, the negotiation
is no longer about the right goal but about an attainable one. And the annual
horizon fits badly with a channel in which the competitive environment,
platform rules and demand shift on a quarterly cycle.

### Balanced Scorecard — four perspectives and a chain

Introduced in 1992 by Robert Kaplan and David Norton in Harvard Business
Review, as an answer to reporting that was purely financial
([Harvard Business Review](https://hbr.org/1992/01/the-balanced-scorecard-measures-that-drive-performance-2)).
The core idea: financial metrics are lagging. They say what happened, not
what will happen. So three further perspectives are added — customer,
internal processes, learning and growth — and a cause-and-effect chain is
stretched between them.

For e-commerce this is more relevant than its corporate reputation suggests.
Translated, the chain reads roughly: product data quality improves
filterability, better filters lower the abandonment rate in the listing, that
lifts the conversion rate, that lifts contribution margin. Every one of those
steps is measurable. Which is exactly why it also becomes visible when a step
is merely asserted.

The weakness: the complete scorecard is too heavy for a shop with 25 people.
Four perspectives with four to five metrics each is twenty metrics that have
to be maintained. In practice the usable part is not the form but the
principle — separate leading from lagging indicators and make the chain
between them explicit.

### OKR — focus for a bounded period

Born at Intel, spread through Google, popularized by John Doerr. An objective
is qualitative and directional, a key result is a number with a baseline, a
target and a deadline. What Matters puts it this way: key results are
"specific, time-bound, and aggressive yet realistic" and above all
"measurable and verifiable" — you either meet them or you don't, with no gray
area ([What Matters](https://www.whatmatters.com/faqs/okr-meaning-definition-example)).

The strength of OKR is focus and communication. Three objectives per quarter
force a choice, and because they are public, every team knows what the others
are working on. That is precisely the point at which, according to HBR,
execution fails in two-thirds to three-quarters of large organizations — not
on the strategy, but on coordination across unit boundaries
([Harvard Business Review](https://hbr.org/2015/03/why-strategy-execution-unravelsand-what-to-do-about-it)).

The weakness: OKR is not a measurement system. It assumes the numbers behind
the key results exist and update themselves. Introduce OKR without having
defined the metrics and you get a quarterly ritual in which someone
eventually estimates percentages. And the quarterly cycle does not fit every
business — an assortment with two hard seasonal peaks does not slice neatly
into four equal parts.

### KPI tree — decomposing the goal

Not a management system in the narrow sense but a calculation structure,
often called a driver tree. The target metric sits at the root, below it the
factors it is composed of, and below those the drivers a team can actually
move.

For e-commerce this is the most natural form, because the target quantity can
be decomposed arithmetically: contribution margin from orders, basket value,
margin and return rate; orders from sessions and conversion rate; sessions
from channels. This decomposition is not a metaphor but an equation — you can
check the arithmetic.

The strength is the low barrier to entry: the tree needs no ritual, no
cascading and no quarterly planning. It needs only defined metrics. The
weakness is that it says nothing about prioritization and nothing about
accountability. A tree shows which driver moves the goal most — it does not
say whether that driver is also the cheapest one, and it does not answer who
decides.

### Hoshin Kanri — alignment across levels

From Japanese lean management, often called policy deployment. The Lean
Enterprise Institute describes it as "a strategic framework for building
sustained high performance and producing results through structured
plan-do-check-act (PDCA) thinking" that aligns functions and activities
"vertically and horizontally — from the CEO to the front line and across
departments" with strategic objectives
([Lean Enterprise Institute](https://www.lean.org/lexicon-terms/hoshin-kanri/)).

Its characteristic element is the reciprocal alignment between levels: goals
are not passed down but negotiated until the level that has to deliver also
considers the target level achievable. That is conceptually strong and in
e-commerce almost always oversized. Hoshin Kanri earns its keep in
organizations with several hierarchy levels and long value streams. A
twelve-person shop team does not need multi-stage alignment mechanics, it
needs one shared document.

## The comparison at a glance

<table>
<thead>
  <tr>
    <th>
      System
    </th>
    
    <th>
      Time horizon
    </th>
    
    <th>
      Granularity
    </th>
    
    <th>
      Data requirements
    </th>
    
    <th>
      Overhead
    </th>
    
    <th>
      Typical misuse
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <strong>
        MBO
      </strong>
    </td>
    
    <td>
      Year
    </td>
    
    <td>
      Departmental goals
    </td>
    
    <td>
      low
    </td>
    
    <td>
      low
    </td>
    
    <td>
      tied to pay, so targets get negotiated down
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Balanced Scorecard
      </strong>
    </td>
    
    <td>
      Year to multi-year
    </td>
    
    <td>
      4 perspectives, 12–20 metrics
    </td>
    
    <td>
      high
    </td>
    
    <td>
      high
    </td>
    
    <td>
      rolled out in full when only the chain was needed
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        OKR
      </strong>
    </td>
    
    <td>
      Quarter
    </td>
    
    <td>
      3–5 objectives, 2–4 key results each
    </td>
    
    <td>
      medium to high
    </td>
    
    <td>
      medium
    </td>
    
    <td>
      introduced as a reporting substitute, without KPI definitions
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        KPI tree
      </strong>
    </td>
    
    <td>
      continuous
    </td>
    
    <td>
      target metric down to drivers
    </td>
    
    <td>
      medium
    </td>
    
    <td>
      low
    </td>
    
    <td>
      built in Miro and never touched again
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Hoshin Kanri
      </strong>
    </td>
    
    <td>
      Year, on a PDCA cycle
    </td>
    
    <td>
      several levels
    </td>
    
    <td>
      medium
    </td>
    
    <td>
      high
    </td>
    
    <td>
      introduced in a flat organization
    </td>
  </tr>
</tbody>
</table>

Which of these systems can be selected in nuonic Lens today is listed
further down in a table of its own.

The column that decides most in practice is **data requirements**. All five
systems assume that the numbers they invoke exist, are bindingly defined, and
update without manual work. Where that is not the case, the choice of system
is irrelevant: each of them then degenerates into a document that gets
maintained twice and forgotten afterwards.

## Which system fits which shop

The decision hangs on three variables, and none of them is a preference.

**Your data.** Are the most important metrics defined and automatically
available? If not, the answer is always the KPI tree — not because it is the
best system, but because it is the only one that also starts with three
metrics and immediately shows which number is missing. Everything else comes
later.

**Organization size.** Below ten people in e-commerce nobody needs a goal
system with cascading — a KPI tree with named owners and a monthly meeting is
enough, and anything beyond that costs more time than it returns in clarity.
Between ten and fifty the real need appears, because several teams work on
the same target quantity without noticing: this is where OKR plays to its
strength, laid on top of an existing KPI tree. Above fifty the Balanced
Scorecard's cause-and-effect chain becomes worth it, because the distance
between a measure and its effect on the financial numbers grows too large to
hold in your head.

**Decision tempo.** How fast does a change of direction have to take hold? A
D2C shop with a performance marketing share decides on budget weekly and on
assortment monthly — annual goals alone are worthless there. A B2B merchant
with framework agreements, tenders and budget cycles on the customer side has
genuine annual rhythms, and a quarterly cycle cuts its processes apart
artificially.

In practice this nearly always produces the same order, regardless of shop
size: **the tree first, then the focus, then the chain.** The KPI tree
clarifies what the goal is composed of. OKR sets which branch gets moved this
quarter. The Balanced Scorecard's perspectives make sure the leading
indicators do not get lost along the way. Start in the reverse order and you
build rituals before you have numbers.

## Where F.O.C.U.S. sits in this landscape

A question that reliably comes up at this point: is F.O.C.U.S. then the sixth
system? No — and the distinction matters enough to make it explicit.

The five systems above each answer one question *within* ongoing operations:
how do I decompose the goal, what do I focus on this quarter, which chain
connects a leading indicator to a financial figure. Our
[F.O.C.U.S. framework](/en/framework/focus) answers a different question —
namely when in the course of a project each of those questions is even due:

- **Facts** supplies the baseline. A goal system set up before the first
measurement sets its targets by guessing.
- **Objectives** is the phase in which the goal system, the KPI definitions
and the planned trajectory are created — everything this article and the
previous one describe sits here.
- **Constraints** clarifies the uncomfortable variant: a goal the data cannot
support is not a goal but a limitation that belongs on the table.
- **Execution** is the set of measures with a hypothesis, a measurement
window and an owner.
- **Scaling** is the operating rhythm as a permanent state — the part that
decides whether the structure still holds a year later.

From that follows the sequence that saves the most argument in projects:
**objectives do not come first, they come after facts.** Set the goals first
and measure afterwards, and you have to correct the goals after the first
measurement — losing exactly the commitment you introduced a goal system for.

F.O.C.U.S. therefore replaces neither OKR nor the Balanced Scorecard. It is
the bracket in which they get their place. How the five systems and the five
phases interlock in detail is a topic of its own, and gets the closing
article of this block.

## What all five systems presuppose

Whatever the choice, there are three preconditions. If one is missing, every
one of the five systems fails in the same way.

**Defined metrics.** Every number a goal invokes needs a formula, a source
system, a time reference, an exclusion rule and a stability rule. That is the
subject of the [previous article](/en/insights/kpi-definitions-ecommerce) and
cannot be retrofitted: a key result without a KPI definition is a statement
of intent, and a branch in the KPI tree without a definition is an assertion
about an arithmetic relationship.

**A planned trajectory, not just a target.** "€120,000 contribution margin by
year end" is not a steerable goal, it is a final state. It becomes steerable
through the expected path to get there, because only comparing actuals
against the planned trajectory makes a gap visible while it can still be
closed. Without one, you notice the deviation in December.

**Named owners.** One person per goal and per metric, not a team. They decide
in case of doubt how something is interpreted and whether a change to the
goal is justified. "The team owns the goal" means in practice that nobody
owns it.

## The most common mistake: two systems in parallel, neither binding

The most expensive mistake is not the wrong choice. It is the choice that was
never made.

The pattern is always the same. There are annual goals from the management
plan, because the bank and the shareholders want to see them. There has been
OKR for two years, because the e-commerce team introduced it. And there is a
dashboard with forty tiles that at some point started being called "the KPI
tree". Three structures that aggregate the same metrics differently, and none
that anyone invokes in case of doubt.

The consequence is not chaos — there is too much documentation for that. The
consequence is arbitrariness: where three legitimate structures exist, the
one that fits the desired outcome wins every meeting. That is exactly what
the HBR research on strategy execution identifies as the core problem — not
missing plans, but missing commitment across units.

The repair is uncomfortable and quick: one structure is marked as binding,
the others are declared views on top of it or abolished. The annual goal stays
in the tree as a target value, it does not become a parallel system. The OKRs
hang off branches of the tree, not beside it. The dashboard shows what is in
the tree, and nothing more.

Two further patterns are worth mentioning, because both look like progress.
The first is **the system as a project**: the rollout gets a project plan, a
workshop and a template — and ends with the rollout instead of with the first
review. The second is **switching systems in answer to a data problem**: OKR
isn't working, so let's try the scorecard. When the numbers are missing,
changing the system only changes the form in which they are missing.

<faq-section :items="[{"question":"What is the difference between a goal system and an operating rhythm?","answer":"The goal system defines what is being steered — which goals exist, how they relate and which metrics they hang on. The operating rhythm defines when decisions are made, meaning which question belongs in the weekly, monthly or quarterly cycle. Without a rhythm, even the best goal system stays a document that nobody checks when a gap opens up."},{"question":"Which goal system fits a small shop team?","answer":"Below roughly ten people, a KPI tree with named owners and one monthly meeting is enough. It needs no ritual and no cascading, only defined metrics, and it immediately shows which number is missing. Systems built on a quarterly cycle or several hierarchy levels cost more time at this size than the clarity they return."},{"question":"Can you use OKR and Balanced Scorecard together?","answer":"Yes, but only with a clear division of roles. The Balanced Scorecard describes the standing system of perspectives and the cause-and-effect chain, while OKR sets the change focus for a quarter on top of it. It only becomes a problem when both run as independent goal structures and neither is marked as binding. Then every meeting decides again which one applies."},{"question":"Why do OKR rollouts fail so often?","answer":"Because OKR is a focus and communication system, not a measurement system. It assumes the metrics behind the key results are defined and update without manual work. Without that foundation you get a quarterly ritual in which someone eventually estimates percentages — and the cause lies not in the system but in the state of the data."},{"question":"What is a planned trajectory and why is a target not enough?","answer":"A target names only the final state, such as a contribution margin at year end. A planned trajectory describes the expected path there, month by month. Only comparing actuals against that path makes a gap visible while it can still be closed. Without one, the deviation becomes apparent when the period is almost over."}]" background="default" label="FAQ">

Common questions about goal systems in e-commerce.

</faq-section>

## Why we're building nuonic Lens for this

The system question has an uncomfortable side effect: in practice it is not
decided once but re-decided every couple of years. A change in management, a
new head of e-commerce, a consultancy with a house method — and the structure
gets rebuilt. What gets lost in that rebuild is not the form. What gets lost
are the metric definitions, the goal history and the reasoning for why a
target was set the way it was. We have accompanied this rebuild several times
in projects and seen the same thing every time: the numbers do not survive a
change of system, because they hung inside the system instead of underneath
it.

That is why [nuonic Lens](/en/insights/measurable-ecommerce-strategy) is
built so that the model determines only the arrangement — not the data. What
gets stored is the guiding statement, the horizon and the review rhythm, and
underneath them the goals with owner and budget, the metrics attached to each
goal with a baseline and a target value, and the measures with an expected and
a measured effect. There is **one** goals table, not four. Which slot a goal
occupies is what the model says; what gets stored stays the same. Switching
models rearranges the goals and throws nothing away.

### Which systems Lens covers today

**Four models can be selected in nuonic Lens: F.O.C.U.S., OKR, Balanced
Scorecard and a free structure. KPI tree, Hoshin Kanri and MBO cannot.**

<table>
<thead>
  <tr>
    <th>
      System
    </th>
    
    <th>
      Available in Lens
    </th>
    
    <th>
      How it is represented
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <strong>
        F.O.C.U.S.
      </strong>
    </td>
    
    <td>
      <strong>
        Yes
      </strong>
    </td>
    
    <td>
      Model with five phases — facts, objectives, constraints, execution, scaling
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        OKR
      </strong>
    </td>
    
    <td>
      <strong>
        Yes
      </strong>
    </td>
    
    <td>
      Model without predefined slots — goals as a list with a score
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Balanced Scorecard
      </strong>
    </td>
    
    <td>
      <strong>
        Yes
      </strong>
    </td>
    
    <td>
      Model with four perspectives — financial, customer, process, learning
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Free structure
      </strong>
    </td>
    
    <td>
      <strong>
        Yes
      </strong>
    </td>
    
    <td>
      The "custom" model — goals sit side by side, without slots
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        MBO
      </strong>
    </td>
    
    <td>
      <strong>
        No
      </strong>
    </td>
    
    <td>
      not its own model; rebuildable as an annual cycle via "custom" plus a yearly review rhythm
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        KPI tree
      </strong>
    </td>
    
    <td>
      <strong>
        No
      </strong>
    </td>
    
    <td>
      baseline and target value per metric exist, the decomposition into drivers does not
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Hoshin Kanri
      </strong>
    </td>
    
    <td>
      <strong>
        No
      </strong>
    </td>
    
    <td>
      not covered
    </td>
  </tr>
</tbody>
</table>

The honest gap is the KPI tree — of all things the system this article
recommends to small teams as the entry point. A baseline and a target value
per metric are there; decomposing a target quantity into its drivers is not.
That is the next step, and not coincidentally the most demanding one: a tree
is only worth as much as the arithmetic relationships it asserts.

Even so, the benefit of where it stands today is exactly the one that matters
for the system question: the decision becomes reversible. Start with
F.O.C.U.S. and switch to OKR a year later because the team has grown, and you
keep the guiding statement, the goal history, the metrics and the measures —
the arrangement changes, not the data. That takes away what makes the system
question so expensive today: its finality.

Lens is not another dashboard and not a replacement for an ERP or analytics.
It reads from the sources that are connected anyway and holds the structure
together — the business decisions about which goal applies and what gets
prioritized stay with the company.

nuonic Lens is still in development — for the time being there is no public
sign-up and no pricing. If you want to follow the series or talk about it
early, [just get in touch](/en/contact).

## The next step

Three checks you can run in an hour:

1. **Ask three people from different areas which goal system applies at your
company.** If you get three different answers, you do not have the wrong
system — you have none.
2. **Take your most important goal and check whether it has a planned
trajectory.** A target value at a deadline and nothing else means the
deviation surfaces on the deadline.
3. **Check whether every initiative currently running maps to a goal.** What
cannot be mapped is either indispensable operations — or there is a goal
that officially does not exist.

The next article goes deep on the system most often introduced and most often
misunderstood in e-commerce: OKR. Objective and key result, the difference
between a key result and a measure, committed versus aspirational — and the
abort criteria that tell you OKR is too much overhead for your shop.

If you would rather not build the goal structure alone: that is exactly what
we do in [consulting](/en/services/consulting), and in
[growth](/en/services/growth) we run it as a cycle with before-and-after
measurement. How we connect the phases is described in the
[F.O.C.U.S. framework](/en/framework/focus).
[Get in touch](/en/contact) — a conversation with the people who also build it.

## Sources and further reading

- [Harvard Business Review: The Balanced Scorecard — Measures that Drive Performance](https://hbr.org/1992/01/the-balanced-scorecard-measures-that-drive-performance-2)
- [Harvard Business Review: Why Strategy Execution Unravels — and What to Do About It](https://hbr.org/2015/03/why-strategy-execution-unravelsand-what-to-do-about-it)
- [What Matters: What is an OKR? Definition and Examples](https://www.whatmatters.com/faqs/okr-meaning-definition-example)
- [Lean Enterprise Institute: Hoshin Kanri — Resource Guide](https://www.lean.org/lexicon-terms/hoshin-kanri/)

## Keep reading

- [KPI definitions in e-commerce: metrics nobody negotiates any more](/en/insights/kpi-definitions-ecommerce)
- [Measurable strategy in e-commerce: why goals without numbers are not goals](/en/insights/measurable-ecommerce-strategy)
- [F.O.C.U.S. — the methodology behind our projects](/en/framework/focus)
- [Consulting: decisions on a data basis](/en/services/consulting)
- [Growth: scaling is a system](/en/services/growth)
