Visual management (Andon) on the shop floor: signals that stop in time before margin breaks

# Visual management (Andon) on the shop floor: signals that stop in time before margin breaks

Signals, not shouting: stop early to learn.

If a deviation only “exists” once it becomes rework, urgency, or a complaint, your shop floor isn’t managing operations: it’s managing consequences.

I use Andon with one simple belief: problems don’t get solved when they appear; they get solved when they become visible early enough and someone has the right (and backing) to act. Without that loop, the story repeats: the best operator becomes a human radar, the supervisor runs nonstop, and leadership finds out when margin has already paid.

This is not an implementation manual. You won’t find a step-by-step. What you will find is what matters in my diagnostics: signals, risks, decision criteria, and trade-offs that tell you whether Andon would help or whether it would become decoration.

## Andon isn’t a board: it’s a response contract

Andon is often reduced to “put up lights” or “install a screen”. I treat it as an operational contract with three parts:

• • An unambiguous signal (anyone can understand it without asking).
• • A real right to stop or escalate (no right, no system).
• • A consistent response (no response, the signal becomes noise).

Remove one piece and it collapses: nobody uses it, everything becomes an “alert”, or it turns into a blaming tool.

## The true cost of “seeing late” is higher than people think

When you see problems late, you pay in ways few teams add up:

• • hidden rework (minutes that become hours)
• • invisible queues (waiting between steps)
• • priorities that flip because of urgency
• • quality “negotiated” to protect a date
• • internal tension (“I told you”, “nobody said”, “same again”).

The danger isn’t that incidents exist. The danger is your system discovers them when the cheap options are gone.

Andon doesn’t remove problems. It moves the moment of truth forward: when you still have room to decide.

## Signals that your shop floor needs Andon

I don’t ask “do you have Andon?”. I look for symptoms:

• • incidents travel through hallway talk or chat and get lost
• • the supervisor is the system (if they’re absent, everything slows)
• • urgency spikes at the end of the day or week
• • defects are fixed downstream because “stopping upstream wastes time”
• • the same failure repeats under different names
• • planning is met “at the expense of quality” or “at the expense of people”.

If that sounds familiar, Andon can be leverage—because of economics, not aesthetics.

## The common failure: decorative Andon (signal without consequence)

I’ve seen Andon as a set: screens nobody watches, signals that change nothing.

Typical causes are predictable:

• • the signal accuses instead of helping
• • no real right to stop (it gets punished)
• • response depends on who’s present
• • everything becomes urgent (no impact hierarchy)
• • measurement is used for control, not learning (people hide).

That version doesn’t just fail—it damages culture by making problems visible without building response capacity.

## The system’s heart: what a signal must trigger

Without giving a recipe, I want signals to reliably trigger decisions at three levels:

### Containment

A fast decision to prevent propagation. Not “solve”, but “don’t worsen”.

### Brief diagnosis

A minimal agreement about the nature of the issue (variation, missing standard, material, tool, information, coordination). If you can’t name the type, you only manage symptoms.

### Escalation with criteria

Not everything should escalate. But what must escalate should do so without drama or politics. I watch whether the system can distinguish:

• • issues that threaten final quality
• • issues that block flow
• • issues that repeat
• • issues that create safety risk
• • issues that change the plan.

Without that distinction, the shop floor lives in alarm mode—and in alarm mode, nobody learns.

## Andon is culture in action: if stopping feels unsafe, Andon doesn’t exist

Here’s the line between real Andon and “Andon marketing”: what happens to the person who triggers the signal?

If triggering means:

• • being labeled slow
• • being seen as problematic
• • being exposed
• • being socially punished

people will stop triggering. Problems return to the old pattern: late, private, expensive.

I want the opposite: signaling as professionalism. That requires clear boundaries—when to trigger, what it means, what it doesn’t mean, and how response works.

## The invisible dependency: without standards, Andon amplifies noise

A shop floor with weak standards confuses variability with “normal”. And if everything is normal, nothing is a problem.

Andon needs at least:

• • a minimum of standard work (living, not bureaucratic)
• • shared agreements about what “acceptable” looks like (without publishing numeric thresholds)
• • and a common language for typical causes.

Without that floor, every signal becomes an endless debate.

So when a team asks me for Andon, I first observe one thing: can the system consistently distinguish correct work from improvised work?

## The real trade-off: stop early vs run into rework

The most common fear is: “if we stop, we lose output.”

I get it. But the miscalculation is this: not stopping also stops you, just later, more expensively, with more collateral damage.

My lens isn’t ideological. It’s practical:

• • if stopping prevents propagation, it’s cheap
• • if stopping prevents repetition, it’s investment
• • if stopping protects promises, it’s reputation defense.

Andon isn’t “stop for stopping”. It’s decide earlier.

## Diagnostic questions I use

• • Where do you discover defects: where they’re created or at the end?
• • Who has real authority to say “stop” without asking permission?
• • What happens when someone flags a problem: help or judgement?
• • How many problems repeat under different names?
• • Is urgency an exception or an identity?
• • Do you have a common language for causes (not culprits)?
• • How much of the plan depends on firefighting?

If the answer is “it depends on who’s there”, Andon isn’t tech—it’s governance.

## Quick checklist: are you ready for Andon?

Yes/no:

• • I can describe “blocker” signals without arguing.
• • A response loop exists and doesn’t depend on one person.
• • Flagging issues isn’t punished (formally or socially).
• • A minimum standard exists to separate variation from normal.
• • Repeated issues are treated as system signals, not personal failure.
• • There are review moments that create decisions, not just information.

Failing some doesn’t mean “don’t do Andon”. It means: your first battle won’t be technical; it will be rules and culture.

## Closing

Andon, properly understood, protects quality, flow, and margin without turning the shop floor into a permanent crisis room. It’s not a board. It’s a pact: clear signal, right to act, consistent response.

Diagnóstico express