SCAMPER: Turn One Diagnosed Cause Into Seven Changes Worth Sizing

SCAMPER is an idea generation tool. In Ci Flow it applies the seven SCAMPER prompts, Substitute, Combine, Adapt, Modify, Put to other use, Eliminate and Reverse, to generate creative solution variations for a process element you already understand.

The timing matters. SCAMPER belongs in the Improve phase of RDMAICS. By the time you open it, Recognise has told you the problem is worth attention, Define has scoped it, Measure has baselined it, and Analyse has named a cause. SCAMPER does not find the cause. It turns the cause into options.

Reach for it when you have one candidate solution and a nagging feeling that it is the only one anyone thought of. That is the failure mode SCAMPER is built against. Teams converge on the first idea, usually the most expensive one, and never test it against cheaper alternatives. Seven prompts force seven angles.

Reach for it also when the obvious fix is blocked. If you cannot replace a system, Adapt and Reverse may still be open to you. The prompts work as a checklist of directions, not a sequence of steps.

The tool ships with sample data so you can see the shape of a completed worksheet before you build your own. This example is fictional. It is there to teach the method, not to report a real result.

The case is an accounts payable invoice process. The diagnosed pain sits across data entry accuracy, cycle time, purchase order matching and approval delay. That is a broad front, which is exactly when SCAMPER earns its place. A single cause with a single fix does not need seven prompts. A cluster of related causes does.

Each row in the worksheet names the current element, the proposed change and the expected benefit. The benefit is where the discipline lives. An idea without a sized benefit is a preference. An idea with a sized benefit is a candidate for a pilot.

The worksheet has four working columns beyond the row number. The SCAMPER action, the current element, the proposed change and the expected benefit. One idea per row. Resist the temptation to stack three ideas into one row, because you will not be able to size them separately later.

Here is the sample worksheet in full, in the order the prompts run:

Look at what the seven prompts actually produced. They are not variations on one theme. They attack different parts of the process and they carry different costs.

Substitute and Adapt both reach outside the process for something better. Substitute swaps manual data entry for OCR with auto-populate. Adapt imports fuzzy-match rules from e-commerce into purchase order matching. Both are technology-led. Both will need build effort.

Combine and Eliminate work on the process shape. Combine merges the scan and match steps into one capture-match flow. Eliminate removes manual filing entirely by auto-archiving on payment. These tend to be cheaper, because you are taking things away rather than adding them.

Modify and Reverse work on the rules. Modify adds threshold-based auto-delegation to approval routing. Reverse pre-approves low-value invoices so the approval happens before the work, not after. Rule changes often need no build at all, only agreement and a policy update. Put to other use is the odd one out here. It takes an asset you already own, the vendor portal, and asks it to do a second job.

The result panel reports a SCAMPER workspace built from the worksheet. It counts 7 ideas across 7 groups, then lists each group with its single idea and the expected benefit attached.

The grouping is by method category. The tool states plainly that no false process sequence is implied. That note is doing real work. A numbered list invites the reader to assume row one comes before row two. It does not. The order is the order of the prompts, nothing more.

Seven groups holding one idea each tells you something useful about coverage. Every prompt fired. No prompt was skipped, and no prompt was overworked at the expense of another. If you ran the same worksheet and found four ideas under Substitute and none under Reverse, that imbalance would be the signal, not a problem with the tool.

A result screen also offers an AI review that explains what the workspace shows. Treat it as a second reading, not a verdict.

The output is not a plan. It is a shortlist with sized gains, which is what you need to choose a pilot.

Start by sorting on the shape of the benefit. Some of these ideas quote an error rate change, such as reducing entry errors from 35% to 8%, or reducing mismatches from 22% to 5%. Some quote time, such as cutting cycle time 15 min, cutting approval delay 3.2 hrs, or removing 8 min per invoice. One quotes coverage, cutting cycle time for 70% of volume. One quotes a quality effect with no number at all, improving scan quality.

That last point is a decision in itself. Put to other use produced an idea with no sized benefit. You can still pilot it, but you will need to decide how you would measure scan quality before you start, otherwise you will not know whether it worked.

Then look at dependencies. Improving scan quality through the vendor portal plausibly helps the OCR substitution. Pre-approving low-value invoices plausibly reduces the volume that the auto-delegation rule ever has to touch. Pick a pilot that does not quietly steal the gain from another candidate, or pilot the enabler first.

Finally, size against effort. A rule change that cuts approval delay 3.2 hrs may beat a build that reduces entry errors, not because the gain is larger, but because you will see it this month.

The most common mistake is running SCAMPER before Analyse is finished. The prompts will happily generate seven ideas about the wrong element. You will then pilot one, see no movement, and conclude that the method failed.

The second mistake is treating the expected benefit as a forecast. It is an estimate made before the pilot. The sample data says OCR plus auto-populate would reduce entry errors from 35% to 8%. That is a target to test, not a result to report. Keep the two separate in your language and in your reporting.

The third is skipping prompts that feel awkward. Reverse feels awkward in most processes. In this worksheet it produced the idea with the broadest reach, covering 70% of volume. Work the prompt even when the first answer is nonsense. The second answer is usually where the value sits.

The fourth is writing vague proposed changes. Improve approvals is not a change. Threshold-based auto-delegation is a change, because someone can build it and someone else can test it.

SCAMPER does not validate anything. It generates and organises. The 7 ideas and 7 groups in the result are a count of what you entered, not a judgement on whether any of it will work. The tool has no view on feasibility, cost, risk or regulatory constraint.

It does not rank. The grouping is by method category, and the tool is explicit that no sequence is implied. Nothing in the output says that cutting approval delay 3.2 hrs matters more than removing 8 min per invoice. That comparison is yours to make, with your own knowledge of volumes and effort.

It does not check your numbers. If you write an expected benefit that is optimistic, the tool carries it forward without comment. Sizing the gain is a judgement you make from Measure phase data, and the pilot is what confirms or corrects it.

It does not find causes. If you have not done Analyse, SCAMPER will not rescue you. And it does not replace Control and Sustain. A piloted change that works still needs a control plan, a measure that stays in place, and an owner. SCAMPER gets you to the pilot. The rest of RDMAICS gets you to the gain that holds.