Methodology
Best-Practice Analysis sits in the Improve phase of RDMAICS and converts what works elsewhere into solution elements you can actually test. This guide walks through the built-in sample data, the result the tool returns, and the decisions it supports before you commit resources.
Best-Practice Analysis asks a narrow question. Someone else has already solved a version of your problem, so what did they do, and what part of it can you use? In the product's own words, the tool lets you document best practices observed in benchmark organisations and translate them into actionable solution elements for the future state.
The second half of that sentence is the work. Observing a practice is easy. Adapting it to your own constraints, naming the change you would actually make, and stating the gain you expect is where most benchmarking exercises stop short. The tool forces all three into the same row.
Use it in Improve, after Analyse has told you what is driving the problem. If you do not yet have a diagnosed cause, you are shopping, not improving. You will collect interesting practices and attach them to nothing.
There is a specific moment in a project where this tool earns its place. You have measured the process. You have analysed it. You know the cause. Now you need candidate changes, and you would rather not invent them from scratch.
Best-Practice Analysis gives you a structured way to borrow. It also gives you a defensible record of where each idea came from, which matters when a sponsor asks why you chose one change over another.
The screenshots in this guide show the tool loaded with its built-in sample data. The case is fictional. It is there so you can see the shape of a completed worksheet before you build your own.
The scenario is an invoice processing function. The diagnosed causes sit around manual handling, approval queues and matching failures. Four best practices have been observed and recorded.
The first is touchless invoicing via OCR and ERP integration, observed at Competitor A. The second is tiered approval by value threshold, observed in an internal business unit. The third is a vendor self-service portal, recorded as best-in-class. The fourth is continuous matching-rule tuning, observed at Competitor B. Three carry High applicability. One carries Medium.
Each row has five fields and each one does a job. The Best Practice field records what you observed, stated plainly. Observed At records the source, which may be a competitor, an internal unit, or a general best-in-class reference. Applicability is your judgement on whether the practice can work in your context.
The Adapted Solution Element is the field people under-use. It is not a restatement of the practice. It is the version you would build. Touchless invoicing via OCR and ERP integration becomes OCR capture with auto-posting. Tiered approval by value threshold becomes auto-delegation under $5K. The vendor self-service portal becomes a portal for submission and status. Continuous matching-rule tuning becomes a monthly rule review cadence.
Expected Impact is the sizing step. In the sample data, OCR capture with auto-posting carries Cycle time -40%. Auto-delegation under $5K carries Approval delay -60%. The portal carries Scan quality +50%. The monthly rule review cadence carries Mismatch -70%. Each one names a metric and a direction, which is what makes it testable later.
The tool builds a workspace from the worksheet. The sample data produces 4 ideas in 2 groups. The grouping is by applicability. High holds 3 items. Medium holds 1.
The workspace carries a note worth reading. Ideas are grouped by method category, and no false process sequence is implied. That is a deliberate guard. A vertical list invites people to read it as a running order. The tool is telling you that position on the board is not a plan.
Each card shows the adapted solution element with its expected impact underneath. In the High group you see OCR capture with auto-posting at Cycle time -40%, auto-delegation under $5K at Approval delay -60%, and the monthly rule review cadence at Mismatch -70%. In the Medium group you see the portal for submission and status at Scan quality +50%. The tool also offers an AI review that explains the result if you want a second reading.
The first decision is what to pilot. Three ideas sit in the High group. That is your short list. Applicability is a filter on feasibility, and feasibility is what separates a pilot from a proposal.
The second decision is sequencing, and the tool explicitly declines to make it for you. You have to weigh expected impact against effort. The monthly rule review cadence carries the largest single stated impact at Mismatch -70% and is a cadence change rather than a system build. Auto-delegation under $5K carries Approval delay -60% and is a rule change. OCR capture with auto-posting carries Cycle time -40% and is an integration.
The third decision is what to park. The portal for submission and status sits at Medium applicability with Scan quality +50%. Parking is a decision, not a failure. Record it, with the reason, so it can be revisited when conditions change.
The fourth decision is how you will measure the pilot. The expected impact fields give you four distinct metrics to baseline. If you cannot measure cycle time, approval delay, scan quality or mismatch rate today, that is a gap to close before the pilot starts.
The most common failure is copying the practice instead of adapting it. A row that repeats the observed practice word for word in the Adapted Solution Element column has skipped the translation step. You are then committing to someone else's context.
The second failure is treating expected impact as a forecast. It is a hypothesis stated in a form that can be tested. The sample data says Cycle time -40%, not that cycle time will fall by 40 per cent in your process.
The third is overstating applicability. If every row reads High, the grouping stops filtering anything and the workspace becomes a flat list again.
Be clear about the limits. Best-Practice Analysis does not validate anything. It records what you observed and what you judged. The sample data shows 4 ideas and 2 groups because four rows were entered and applicability was rated three times High and once Medium. Change the ratings and the groups change. The tool has no independent view.
It does not calculate cost, effort or return. There is no implementation time in the sample data and no dollar saving beyond the $5K delegation threshold, which is a rule parameter rather than a benefit. You will need a separate business case.
It does not confirm that the observed practice actually produced the result claimed at the source organisation. Benchmark data is often second-hand. Treat Observed At as provenance, not proof.
It does not tell you the order to implement in, and it says so on the face of the workspace. Sequencing depends on dependencies, capacity and risk, none of which appear in the worksheet. Use the tool to narrow the field and size the prize. Then take the short list into a pilot design, and let the pilot settle the argument.
RDMAICS, A3, Just Do It and Kaizen projects with the full Lean Six Sigma toolset, AI interpretation and tollgate presentations built from your real evidence.
5S Workplace Design converts a confirmed root cause into five concrete future-state actions with owners and dates. This guide walks through the tool's built-in sample case and shows how to size the gain before you commit to the change.
Read the article
Batch-Size Optimisation takes a diagnosed cause and turns it into a change you can pilot with a number attached. This guide walks through the tool's built-in sample data, from four candidate batch sizes to a single recommended answer.
Read the article
Setup Reduction / SMED takes a diagnosed cause and turns it into a change you can test. This guide walks through the tool's built-in sample data, task by task, and shows how to read the result before you spend anything.
Read the article