A Process Should Earn the Right to Become Standard

We spend a lot of time designing processes.

• We map the steps.

• Configure the technology.

• Write the requirements.

• Build the workflows.

• Train the people.

• Then we call it a process.

But there is a step that is often missing.

Prove it.

A process should earn the right to become standard.

That may sound obvious, but it is one of the places I see organizations get into trouble. A new process is designed, tested once, appears to work, and quickly becomes the new standard.

The problem is that one successful execution does not prove a process.

It proves that the process can work.

Those are two very different things.

The Smoke Test

I have seen this many times. The new process is ready to test, so the most experienced person in the operation is asked to run it. They are an athlete at the job. They know the product. They know the container. They know the equipment. They know the RF scanner. They know where things tend to go wrong. They have performed the job so many times that they have developed a level of finesse that is difficult to see from the outside. They know the exceptions before they happen. They know how to work around the small problems.

They are, in a sense, "one with the job."

And that is exactly why they are valuable during a test.

They can identify what slows them down. They can identify what doesn't make sense. They can find the rough edges in the process.

But there is a danger in stopping there.

The experienced operator can make a broken process look like a good process.

That is a smoke test. It tells us whether the basic pieces can come together. It does not tell us whether the process is ready for the operation.

Does It Keep Working?

The next question is much harder.

Can the average operator perform the process at pace, repeatedly, and at the required quality?

Now we are testing something different. We aren't testing whether someone can make the process work.

We are testing whether the process works.

There is a big difference.

A process that requires an expert to constantly interpret, adjust, or compensate for weaknesses is not a strong process.

The process should help the operator succeed.

And it needs to work repeatedly.

Not once.

Not ten times.

Think about running it a thousand times with all the variables in play.

• What happens when the conveyor jams?

• What happens when the RF scanner stops working?

• What happens when a location barcode won't scan?

• What happens when inventory is missing or the quantity isn't correct?

These aren't unusual events in an operation. They are part of the operation.

A resilient process doesn't require the entire operation to stop every time reality shows up.

It has ways to recover.

It has ways to continue.

It is, in some way, self-healing.

That is part of what we should be proving.

The Process Doesn't Exist by Itself

There is another level of proof that is often missed. The process has to work within the ecosystem. Every operation has something before it and something after it. A process can be extremely efficient in isolation and still make the overall operation worse.

• Make picking faster, but create congestion in packing.

• Make receiving faster, but create inventory accuracy problems downstream.

• Reduce labor in one area, but create additional touches somewhere else.

• Did we really improve the operation?

• Or did we simply move the work?

The operating system is bigger than any individual process.

So the final proof is not simply:

Does this process work?

It is:

Does this process make the system better?

• Does it leverage its inputs?

• Does it add value or reduce cost?

• Does it produce an efficient, digestible output for the next operation?

• Does it create positive collateral benefits upstream and downstream?

If the answer is no, it hasn't passed the proof test.

Don't Blame the People

There is one more piece that matters. The people doing the work have to be part of the proof. Too often, a process is designed by a team that has never actually done the job.

• The requirements are gathered.

• The technology is configured.

• The solution is presented.

• Then it reaches the floor and doesn't work as expected.

Who gets blamed? Usually, the people.

• "They aren't following the process."

• "They need more training."

• "They don't understand the new system."

Maybe. But maybe they were never set up for success. Maybe they weren't involved in understanding the current state. Maybe they weren't given a voice to explain why the existing process wasn't working. Maybe the solution was designed without understanding the Actual Place, Actual Process, and Actual People.

The Three Actuals matter here.

The people are not simply the recipients of the new process.

They are part of the proof.

If the people doing the work cannot make the process work, we need to understand why before we blame them.

So, What Does "Proven" Mean?

For me, it comes down to three questions:

Does it work?

Can the technology, people, and process accomplish the objective with quality?

Does it keep working?

Can an average operator execute it repeatedly at pace, including the normal exceptions and disruptions of the operation?

Does it make the system better?

Does it improve the operation before it, the operation after it, and the overall ecosystem?

If the answer isn't yes to all three, the process isn't ready to become standard.

And that's the point.

We don't standardize our ideas.

We standardize what we've proven.

A process should earn the right to become standard.

• Before we document it.

• Before we train it.

• Before we laminate it.

• Before we tell everyone, "This is the way we do it."

Prove it first.