Cellular Flow Design: Turn a Diagnosed Cause Into a Pilot Worth Running

Cellular Flow Design does one job. It helps you design work cells that group related process steps and resources so you minimise handoffs and improve flow. A cell is a small, self contained unit of work. Everything the cell needs sits inside it. Work enters, work leaves, and nobody has to chase a queue in between.

The tool sits in the Improve phase of RDMAICS. That placement matters. By the time you open it, you should already have a diagnosed cause from Analyse. Improve is not where you go looking for problems. Improve is where you convert a cause into a change worth piloting, and where you size the gain before you commit people and money to it.

Reach for Cellular Flow Design when your Analyse work points at fragmentation. Typical signals include work bouncing between teams, long waits between short tasks, repeated rework at the same joins, and no single owner for an end to end outcome. If the cause is something else entirely, such as a measurement error or a supplier defect, a cell design will not help you.

Use it before you write a pilot plan, not after. The design is the thing you pilot. If you cannot describe the cells, the steps inside them, the resources and the takt, you are not ready to run anything.

Everything below uses the sample data that ships with the tool. This case is fictional. It exists so you can see the mechanics without the noise of a live process.

The case is an invoice to payment process. The diagnosed cause is excessive handoffs. Work passes between capture, matching, approval and payment, and each pass creates a queue. The design response is four cells, each with its own steps, its own resources and its own takt time in minutes.

The four cells are a Capture cell, a Match cell, an Approval cell and a Payment cell. Each carries a named benefit: single-piece flow, automated flow, reduced handoffs and a closed loop. Those benefit labels are not decoration. They are the claim you are going to test in the pilot.

The worksheet asks for five things per row. Cell, steps in cell, resources, takt in minutes, and benefit. Keep each row to one cell. Resist the urge to add commentary columns. The discipline of five fields is what makes the design comparable across cells.

In the sample, the Capture cell contains ingest and populate, uses an OCR system, and carries a takt of 3 minutes. The Match cell contains the 3-way match, uses a rules engine, and carries a takt of 1 minute. The Approval cell contains route and approve, uses an approver plus workflow, and carries a takt of 5 minutes. The Payment cell contains pay and archive, uses a payment system, and carries a takt of 6 minutes.

Two rules help when you populate the sheet. First, a step belongs in the cell that has the resource to finish it. If the step needs a resource that sits in another cell, you have just designed a handoff back in. Second, name the resource specifically enough that someone could go and check whether it is available.

The tool returns a structured improvement output built from the worksheet. It reports four populated worksheet rows, with the first four shown. Each row is grouped under its benefit heading, then restated with its cell, steps, resources and takt.

So the result reads as four blocks. Single-piece flow holds the Capture cell at 3 minutes. Automated flow holds the Match cell at 1 minute. Reduced handoffs holds the Approval cell at 5 minutes. Closed loop holds the Payment cell at 6 minutes.

That re-ordering by benefit is the useful part. It forces you to read the design as a set of claims rather than a list of boxes. You can see immediately that the claim with the longest takt is the closed loop Payment cell at 6 minutes, and the shortest is the automated Match cell at 1 minute.

The tool also offers an AI review that explains the result in plain language. Treat it as a second reader, not as a decision.

Takt is how you size the gain without guessing. In the sample, the four cells carry takt times of 3, 1, 5 and 6 minutes. Read across them and the shape of the design becomes obvious. The Payment cell at 6 minutes and the Approval cell at 5 minutes set the pace. The Match cell at 1 minute has slack.

That tells you where a pilot will actually move the needle. If you shorten the Match cell, nothing downstream improves, because 1 minute was never the constraint. If you shorten the Approval cell or the Payment cell, the whole chain responds. The design has, in effect, nominated its own pilot scope.

It also tells you where to expect queues. A cell running at 1 minute feeding cells running at 5 and 6 minutes will build a backlog unless you control release. That is a design question to settle now, not a surprise to discover in week three of a pilot.

Size the gain in the units the cells already give you. Minutes per cell. Do not convert to a dollar figure at this stage. You have not measured volume or variation yet, and a converted number invites a commitment the design cannot support.

Cellular Flow Design is a decision aid, so be clear about which decisions it serves. It helps you choose a pilot boundary, because the cell is the natural unit to pilot. In the sample, you could pilot the Approval cell alone at 5 minutes and leave the other three as they are.

It helps you assign ownership. One cell, one owner, one set of resources. The Capture cell owner owns the OCR system and the ingest and populate steps. There is no ambiguity about who answers when the cell misses takt.

It helps you decide what to measure in Control. The benefit column is the measure. For the Match cell, you measure whether flow stayed automated. For the Payment cell, you measure whether the loop stayed closed. Each cell gives you one claim and one takt figure to watch.

Finally, it helps you decide what not to do. Four cells is a small design. If your worksheet runs to twenty rows, you are describing the current process, not redesigning it.

The most frequent mistake is drawing cells along existing team lines. If the Approval cell is simply the approvals team with a new label, you have renamed a handoff rather than removed one. Cells should follow the work, not the org chart.

The second mistake is listing resources the cell does not control. If the Payment cell needs a resource that belongs to the Capture cell, the design is not closed. Walk each row and ask whether the cell could finish its steps if the other three cells went dark for an hour.

The third mistake is treating takt as a measured average. Takt is the pace the cell has to hold. The 3, 1, 5 and 6 minute figures in the sample are design targets. Confusing a target with a current state measurement will make your pilot results unreadable.

The fourth is skipping the benefit column, or writing something vague in it. If you cannot name one benefit per cell, the cell has no reason to exist as a separate unit.

Cellular Flow Design will not validate your diagnosis. It accepts whatever cause you bring from Analyse. If the real problem is upstream data quality, the tool will still produce a neat four cell design, and that design will still fail in pilot. Validation belongs in Measure and Analyse, not here.

It will not balance the line for you. The sample shows takt times of 3, 1, 5 and 6 minutes. The tool reports those figures. It does not tell you how to even them out, how much buffer to hold between cells, or what release rate to use. Those remain engineering judgements.

It will not estimate cost, headcount, savings or payback. There is no financial model behind the worksheet. Any benefit case you build has to come from separate volume and cost data that you gather yourself.

It will not confirm that the resources exist or are available. Naming an OCR system, a rules engine, an approver with workflow and a payment system is a design statement, not a procurement check. Somebody still has to confirm each one can be dedicated to its cell.

And it will not tell you whether the design is better than the current process. The worksheet holds four rows describing the future state only. The comparison is yours to make. What the tool gives you is a design clear enough to pilot and specific enough to argue about before you spend anything.