DMADV: Designing a Process That Doesn’t Exist Yet

DMAIC takes a process, measures it and fixes it. For it to work, there has to be a working process in place.

In some jobs, however, there is no such process. A new plant is opening, a new business unit is being set up, the company is moving to an ERP for the first time, or the current setup is so broken that rebuilding it will be quicker than improving it. In these situations DMAIC runs into a wall: there is no baseline to measure and no root cause to analyse.

DMADV is the path Six Sigma uses for this kind of work. It is sometimes also called DFSS — Design for Six Sigma. It has five steps, and although the first three share their letters with DMAIC, their content is different.

Define     Measure     Analyse     Design      Verify
   →           →           →           →
                                                  │
                             after go-live, it is │
                          handed over to DMAIC ───┘

Define

We write down what is being designed and for whom. Here the “problem statement” of DMAIC is replaced by a scope statement: “The order–production–shipment chain of the newly opened Gebze plant will be set up on the existing ERP.”

In this step we clarify four things:

• Boundary. Which process chain we touch and where we stop. Is the new plant’s accounting in scope or not?
• Stakeholders. Who will use it, who will approve, who will read the reports.
• Constraints. Budget, dates, compatibility requirements with existing systems, legal requirements.
• What success means. What we will look at when the project ends to say “it worked”.

The last point is the one skipped most often, and the whole of the next step rests on it.

Measure

In DMAIC this step measures current performance. In DMADV there is no performance to measure; instead we measure expectations.

The method: you talk to the users (VOC — Voice of the Customer) and translate what they say into measurable criteria (CTQ — Critical to Quality). The difference matters:

What is said                         →  Translated into a criterion (CTQ)
"Order confirmation should be fast"  →  Confirmation ≤ 4 hours, for 95% of orders
"Stock should add up"                →  Count variance ≤ 2%, monthly
"Month-end should close early"       →  Close completed in 5 working days
"We shouldn't wait for reports"      →  Periodic report ready the next morning

On the ERP side the practical benefit of this step is large, because the CTQ list becomes the referee for later choices: the answer to “should this field be mandatory?” is given by looking at which CTQ that field feeds.

In projects that start without CTQs, choices are made according to people. The result is familiar: the system works, nobody can object, but nobody is happy either.

Analyse

Here we don’t look for a root cause; we generate alternatives and compare them. In the ERP world the set of alternatives usually consists of these four:

1. Use the standard module as it is — cheapest, fastest, least flexible.
2. Customise the standard — medium cost, maintenance burden at every upgrade.
3. Add a custom application alongside it — fits the need exactly, doesn’t touch the ERP core.
4. Integrate with another system — sensible if a ready-made system exists for the job; the data flow has to be built.

We weigh the alternatives against the CTQs. A simple table is often enough:

The purpose of the table is not to give the right answer but to record what the choice was based on. A year later, the answer to “why did we do it this way?” is right there.

Design

The chosen alternative is worked out in detail. In ERP projects, design consists of these layers:

• Data model and master data. Products, customers, suppliers, cost centers, unit codes. This is the most time-consuming and most underestimated part of new implementations.
• Process flow. Which document creates which, and in which situations a step can be skipped.
• Authorisation and approval. Who sees what, who approves above which amount.
• Screens and reports. Where users do their daily work. Whether the design stays on paper depends on this.

In this step we prefer to produce a prototype early; when a single unknown point needs to be clarified, we do it as a time-boxed spike. Showing a working screen instead of describing it in a meeting surfaces most design errors before go-live — which is exactly the job of the drag-and-drop design approach behind erpware Builder and TIVA Builder.

A note: trying to get the design perfect in one go is the trap DMADV falls into most often. It is enough for the design to be good enough and measurable in the Verify step.

Verify

We prove that the design really meets the CTQs written in the Measure step. “We tested it, it works” is not this step; measuring that it works is.

The sequence that works in the field:

1. Scenario testing. With real documents and real users, end to end. Not screen by screen, but along the process.
2. Pilot. A single warehouse, a single product group or a single plant. A design that works in a narrow area shows its real cost before it spreads.
3. Parallel running. For critical processes, the old and the new run side by side for a while; the difference between the two results reveals gaps in the design.
4. Post-go-live measurement. The CTQs are measured again in the first, third and sixth months.

We turn the measurement in the last point into a permanent indicator on ErpwareBI, so that measurement doesn’t stop when the project ends.

And this is where the handover happens: once the new process is live, responsibility for improvement moves out of DMADV and into the DMAIC cycle. DMADV builds something; DMAIC keeps it in place.

DMAIC or DMADV?

The last row is the debatable one. The question we ask when deciding is: is the skeleton of the current process right? If the skeleton is right and the problem is in execution, DMAIC is enough. If the skeleton itself is wrong — the wrong document flow, the wrong division of responsibility, the wrong master data design — improvement efforts only go as far as reinforcing the wrong structure.

Where do teams stumble?

Three patterns recur:

1. Measure is skipped. Design starts without CTQs. At the end of the project, success is measured as “did we go live?”; the calendar is measured, not quality.
2. Analyse is done with a single alternative. The first solution that comes to mind becomes the design. Because no alternatives were generated, no comparison can be made either.
3. Verify is confused with go-live. The system is switched on, the project is closed and no measurement is ever made. Six months later people say “it didn’t turn out as we expected”, but what was expected was never written down.

What the three have in common: they all speed the project up in the short term and cost dearly in the long run.

How we run it

We use DMADV not as a heavy programme but as the sequence we follow for newly built processes. We run the Define and Measure steps as part of Process Consulting, and the Analyse and Design steps under ERP Project Management. When what is needed is a screen or flow that isn’t in the standard, custom application development and Integration Studio come in; we make the Verify-step measurements permanent on ErpwareBI.

For the background of the method and which parts of it work in ERP: Six Sigma and ERP.