Guest Articles

Why don’t we see more poka-yoke in the office?

Poka-yoke (a.k.a. mistake-proofing) is everywhere.  It’s in my coffee maker to ensure the water is hot before it can be dispensed for brewing.  It’s in my car to ensure my foot is on the brake before I can shift into reverse or drive.  As a young quality engineer in the 1990’s, I was enamored with poka-yoke because of its simplicity and effectiveness.  My favorite application of poka-yoke for manufacturing was the use of a lock and key design to prevent orientation errors. It was simple and inexpensive, yet it was practically 100% effective.  A part could never be installed upside-down because the lock and key design made it physically impossible.

Prior to learning about poka-yoke, my solutions to quality and process issues focused primarily on documentation and training people.  Unfortunately, improving the human element rarely resulted in the effectiveness I desired.  Humans are beautifully magnificent, but we are not machines. We embody variation because we fatigue, forget, get distracted, misunderstand, etc.  Humans will make mistakes, which is why we need poka-yoke.  Once I came to respect this fact, the more effective I became at my job.  I didn’t abandon the pursuit of improving the human element, but I complimented it with poka-yoke whenever possible and practical.  Not only did manufacturing quality improve for the customer, but it was fun and rewarding for the team.  Win-win!

This story is not unique.  Manufacturing has benefited from the application of poka-yoke for decades.  Poka-yoke is practically a given on the shop floor, but it is strangely absent in the back-office.  As mentioned in last month’s Chalmer’s Street newsletter, knowledge workers have countless examples of incomplete forms and inconsistent workflow.  As a business process consultant, I attest that these examples are real and commonplace, regardless of the industry.  Back office business processes are all too often neglected and their quality would be considered shameful by manufacturing standards.

So why don’t we see more poka-yoke applied to back office business processes?  I believe the answer lies in the tools or lack thereof.  Poka-yoke is most effective when we can physically force the desired path.  Physical tools for manufacturing at scale have been available for as long as I’ve been alive.  They are refined, effective, and affordable.  It’s a no-brainer to use them for poka-yoke.  Unfortunately, tools for manufacturing physical products aren’t very useful for the information based processes of the back office.  The proper poka-yoke tools for the control of information are not mills and lathes, but computers and software.  And, of course, computers and software are relatively new to the business world.

Back in the 1990’s, office computers were more of a bonus than a ubiquitous standard.  I remember filling out forms by hand (yes, paper and pencil) and placing them in physical envelopes for distribution.  There was very little we could do to improve the effectiveness of exchanging information because we didn’t have the tools.  All we had was documentation and training, but it was clear that the cost, availability, and usefulness of information technology was going to improve drastically in the not too distant future.


In the 2000’s, information technology for the office was definitely a thing, but costs and resources were prohibitive.  Technically, I could get a software program written to control my back office process with full on poka-yoke, but it was going to cost a fortune because it had to be programmed from scratch.  From my experience, the cost per process was over a million dollars,  which was almost never justified.  And if I could justify the cost, I was put in a queue waiting for the programmers to become available, which would be never unless my project was required to keep the lights on.  If I did get a programmer to work on my project, I only got one shot to get it right because the programmer would move on to the next project.  This one-and-done approach was almost useless because the reality is that most processes require time and iterative changes to stabilize and improve.

For back office business processes, the 2000’s were a bit of a tease.  I could see the possibilities, but they were untouchable.  As a consolation, I was given Excel, email, and SharePoint and told to just do my best.  Sound familiar?  Though these tools were markedly better than paper, they were prone to errors, cumbersome to keep updated and never quite hit the mark. Email and MSExcel simply were not designed to control processes.

It is now the end of the 2010’s, and due to the maturity of the cloud and low-code platforms, I am happy to report that I can finally apply poka-yoke to any back office business process cost effectively and quickly.  The cloud has enabled real-time information sharing for everyone to operate from the latest version of the truth.  Low-code has put the power of app development into the hands of non-programmers by leveraging drag-and-drop interfaces to assemble applications instead of programming them from scratch.  Today, improvement professionals can brainstorm in the morning and have the ideas prototyped for testing by the end of the day.  It’s really quite brilliant and empowering for the team.

Though technology has presented new ways to poka-yoke processes, I am finding that many improvement professionals aren’t aware of low-code, and so they continue to accept error prone back-office processes.  This is unfortunate, because it’s really quite fun and rewarding to solve process problems that were once untouchable.  We no longer have to live with incomplete forms or inconsistent workflow because we can build poka-yoke into our business processes through low-code.  Improvement professionals took a significant step forward when we moved from paper to spreadsheets.  Two decades later, we are doing it again by stepping up from spreadsheets to low-code.  If you aren’t doing it already, it might be time to give your back-office business processes some poka-yoke love with low-code!

This article was written by Matt Hubbard.  Matt is co-founder of Calabash, a consulting firm specializing in process-driven solutions using low-code application platforms.  If you’d like to learn more about low-code, Matt can be reached by email at