Flow engineering: dynamic batching and sorters to stop chasing orders

# Flow engineering: dynamic batching and sorters to stop chasing orders

Smartly grouping orders reduces format changes. Dynamic batching and classification systems (sorters) optimize your flow.

Too many things are left “halfway,” pieces “go missing” at the last minute, sequencing is redone based on urgency, and completed projects struggle to leave the shop.

When I see this pattern, I don't interpret it as a lack of effort. I interpret it as a lack of flow engineering.

In this post, I talk about two levers that, when used well, stabilize chaos without killing flexibility: dynamic batching and sorters (physical or digital). I'm not going to give you a manual to implement them. I'm going to show you how I detect if you need them, where they usually add value, and what the risks are of doing it wrong.

## What is “flow engineering” in a project environment?

I call flow engineering the intentional design of these four things:

• • How work enters (release: what is released, when, and under what conditions).
• • How it moves (routes, buffers, priorities, and constraints).
• • How it is decided (visible rules, not decisions by intuition).
• • How it ends (completion as an objective, not “activity”).

In a project environment, variability is real. That's why the flow is not “ordered” with more pressure. It's ordered with rules.

And here is where dynamic batching and sorters come in.

## Dynamic batching: grouping without becoming rigid

If “batching” sounds like “making large lots” to you, I understand. Many people reject it because they associate it with:

• • waiting
• • WIP accumulation
• • and a feeling of slowness.

Dynamic batching is not about inflating lots. It's about grouping in the right place and for the right amount of time, according to what is limiting the system at that moment.

I explain it like this:

• • fixed batching = “I decide the lot and the system adapts”
• • dynamic batching = “I decide the rule and the lot emerges”

### Typical examples (without going into implementation)

• • grouping by material to reduce tool changes in a critical station
• • grouping by edge/finish type to avoid costly setups
• • grouping by hardware compatibility to minimize searches and errors
• • or grouping by logistics sequence to prepare kits without breaking the plan.

The key is that the lot is not defined by whim, but by a question:

What hidden cost am I buying if I DON'T group here?

## Sorters: when the problem isn't producing, but directing the flow

A sorter is not just a machine. For me, a “sorter” is any mechanism that makes the work go to the right place with the minimum of friction.

It can be:

• • physical: diversion lanes, ordered buffers, classification stations, conveyors with decisions.
• • digital: routing rules, visible queues, WIP limits per zone, and a system that says “this goes here” without discussion.

The typical error is thinking that a sorter is bought to “be more modern.” I see it the other way around: it is justified when the flow already exists, but the organization of the flow is consuming your energy.

My criterion is simple:

if classification and re-routing consume as many hours as production, you are paying a flow tax.

## When I suspect you need dynamic batching (diagnostic signals)

I don't decide based on trends. I decide based on observable symptoms.

### 1) The bottleneck changes location every week

When the constraint “moves,” many companies believe that means “we are flexible.” I interpret it as instability.

Dynamic batching helps when the real constraint exists, but you are feeding it poorly: with changes, with a chaotic mix, or with incomplete entries.

### 2) Setups dominate the day

If in critical stations there are:

• • frequent stops
• • repeated adjustments
• • constant cleaning
• • excessive verification

…and the feeling is that “there is a lot of work to produce little,” dynamic batching is usually more profitable than “running faster.”

### 3) There is rework due to predictable incompatibilities

When errors are not “accidents” but patterns (material, hardware, machining, drilling, edges), grouping by compatibility reduces failures before they are born.

### 4) Urgency decides the sequence

If the production criterion is “whoever shouts the loudest,” dynamic batching can create a superior rule: protect the critical station and stabilize the queue.

## When I suspect you need sorters (physical or digital)

### 1) Your WIP is “moving” but not “at its destination”

If you see work everywhere (aisles, carts, corners) and no one can say with certainty:

• • what is ready
• • what is blocked
• • what is missing
• • and which station needs it

…the problem is not capacity. It's addressing.

### 2) Picking and searching eat up the day

When the team invests too much energy in:

• • finding pieces
• • regrouping
• • moving from one side to another
• • “making space,”

a sorter (or a digital routing system) stops being a luxury and becomes a stabilizer.

### 3) The end of the process is a lottery

If finishing depends on “getting” the last pieces, on “gathering” what was dispersed, or on remembering where something was left, you need flow order, not more push.

### 4) Internal conflict grows

Where there are no flow rules, politics appears:

• • “they've pushed this ahead of me,”
• • “mine was more urgent,”
• • “if I don't do it, it won't go out.”

Well-designed sorters reduce conflict because they reduce ambiguity.

## The question that separates a real improvement from an expensive complication

I always ask this question before talking about technology:

Is your main problem transformation or coordination?

If it's transformation (slow machines, poor quality, insufficient capacities), a sorter won't save you.

If it's coordination (routes, priorities, buffers, completeness), a sorter can be a multiplier.

And with batching it's the same:

• • if you don't know what the limit is, grouping can be a patch
• • if you know what the limit is, grouping can be a lever.

## Real risks: how this idea breaks when done poorly

### Risk 1: “automating” a chaos

If your process doesn't have clear rules, putting in a sorter turns chaos into a faster chaos.

The machine does not order by itself. It only executes decisions.

### Risk 2: batching that creates “toxic lots”

If you group by convenience and not by constraint, you generate:

• • waiting
• • unbalance
• • and aged WIP.

Dynamic batching demands limits. Without limits, you create internal inventory disguised as efficiency.

### Risk 3: the system becomes incomprehensible

If no one understands why something goes to one lane or another, the operation starts to “skip” rules. And then you lose the most valuable thing: predictability.

### Risk 4: dependence on poor data

In project environments, if the product information, variants, or routes are inconsistent, the classification fails.

It's not an argument against sorters. It's an argument in favor of data governance.

## My mental framework: where it's best to group and where it's best to individualize

A rule that works for me:

• • I group where the cost of changing is high (setups, tool changes, calibration)
• • I individualize where the cost of waiting is high (client promise, final synchronization, installation).

The common error is trying to individualize everything, everywhere, all the time. That usually creates “perpetual urgency.”

The goal is not “small lot.” The goal is reliable flow.

## Quick diagnostic checklist (without giving away the implementation)

If you answer “yes” to several, I don't “implement things”: I design the flow with you.

• • Do you change the sequence several times a day due to urgencies?
• • Does WIP grow even though the team is at maximum capacity?
• • Are there critical stations with too many setups and micro-stops?
• • Does searching/picking consume hours every week?
• • Does finishing projects depend on “gathering” scattered pieces?
• • Is the internal conflict over priorities constant?
• • Is internal traceability weak (you don't know what is blocked and why)?
• • Is the real constraint unclear or “jumping around”?

If these signals appear, dynamic batching and sorters are usually part of the conversation… but always after a question:

What flow rule are you missing to stop chasing orders?

## Closing: when flow improves, the promise stops being faith

I like to measure success with one thing: less chasing.

• • less “where is it?”
• • less “I'm missing this”
• • less “I'm putting this in because of urgency”
• • less “I'll fix it later”

Flow engineering is moving from pushing work to directing it.

If you want, I'll review it with you in a 15-minute diagnosis: I'll identify your coordination tax, your real constraint, and if dynamic batching and sorters make sense in your case.

Express Diagnosis