Poka-Yoke applied to Administrative Processes - Sales, Accounts Payable, HR



Poka-Yoke applied to Administrative Processes

Dear Forum Members:
This is the first time I am writing to the forum although I have been reading the postings for a long time. I hope you could help me on this issue.

I am working on a project of implementing POKA-YOKE methodology in Administrative Processes (Sales, Accounts Payable, Accounting, HR,etc). Due to the nature of this POKA-YOKE tool, most of the books I have read describe examples only on manufacturing. I need to prepare a presentation with examples of POKA-YOKE devices applied to Administration. I made some examples but I think I need to go deeper into the issue, specially when using POKA-YOKE devices into the administrative procedures.

Any help or direction will be highly appreciated.

Thanks Amigos,

With my best regards,

Erasmo A. Gonzalez


Fully vaccinated are you?
I haven't really thought about Poke-Yoke in this respect. However - if you'll cite the examples you have thought of here they may 'jolt' some of us into thinking and then we may come up with some ideas for you.

David Mullins

The only areas that come to mind so far are data entry into on-screen fields, where the program used requires certain field parameters to be completed before processing can occur - e.g. as frequently used in account generation.
Hard copy forms certainly aren't poka yoke. Electronic forms can be partially poka yoke if they can be printed or processed until required fields are completed.
Basically I can't think of anything to successfully poka yoke in an admin environment outside of computer processing activities.



Thanks Mr. Smith for your kind response!
I know that POKE-YOKE´s devices usually are physical devices such as posts, alarm stops, one-way devices, etc. My conclusion from this devices are that in administrative processes we could "translate" this devices into checklists (i.e. a checklist used by sales representatives to enter as much information as needed for accepting a sales order for a new client -the first time done o.k.- and trying to avoid future defects when invoicing (In my opinion that could be the usage of one of the POKE-YOKE´s principles: inspect where the error could possibly be made).

Other example: Business Travel Expenses. It´s a shame but in my country some executives try to collect fake hotel & restaurant receipts to make their companies reimburse them for more expenses than they really paid for. I think we could try to avoid this problems if I could create a one-way procedure (my poke-yoke device) such as implementing an expense "roof" of expenses or giving the executives a corporate card so the major part of their business expenses could be concentrated in one single bill.

I think that probably this examples could sound simple cases that require more administrative controls rather than using a poke-yoke device, however I am applying for a quality leader position and this is like an assessment presentation. The company is asking me to apply Poke-yoke to administrative processes as a proof of my quality skills.

Thanks again for your help, Mr. Smith.


Erasmo A. González

Laura M

You can have a "process flow diagram" for admin processes as easily as a manufacturing process. Look at places where the process breaks down....dates missed, passed due invoices, etc. The "potential failure modes" can then be assessed for "poke-yoke." I guess in the electronic world, its easy to think of computers, but in an office with paper you can color code, make labeling more effective, use a white board for due dates of quotes or whatever...anything that make things more obvious for the users. If everything is electonic...you still have the garbage in, garbage out theory, where if people simply make a typo, its hard to catch...manufacturing may use redundant "inspection". Can you?

I'm going to be doing a "continuous improvement" class for a service organization involved with issuing unemployment checks, lining up training, and matching employees with employers, using this kind of technique. It may be too late for your project, but I will let you know if the employees come up with anything, as we will be working through real examples in the class. Again, I think the most useful tool is the PFD, looking for the opportunities. Good Luck.


Kevin Mader

One of THE Original Covers!
I like Laura's recommended approach, simple and structured. I have to admit that the first thing that popped into my head was David's example (as it probably does for many). Nothing wrong with selling the obvious, as it is invisible to many.

Color coding of forms is a great method. In one of our organizations, this is done to separate processing of inbound production data, and used by another organization to differentiate sales programs for different customers. Each process has benefitted on the lead and tail ends by reducing errors and improving on cycle-times. Also benefits in the intangible areas of improved relations between groups and increased employee goodwill. Just plain simple PDCA in a continuous improvement effort.

I applaud taking a methodology primarily sold as an 'Operations' improvement tool and using it elsewhere. Too often, the focus of Quality improvement remains with the Manufacturing department, as with ISO or QS9000 (my projection: micromanaging philosophies). Consider the 'whole', improve the 'whole'.

Best of luck on your endeavor!




A technique that we have found useful in some non-manufacturing environments is to combine "lessons learned" with a checklist. This approach has been particularly successful in our systems design group.

A guidebook has been developed over the years that is based on lessons learned, the experience of the engineers, and examples from the literature and other sources, including suppliers. It is organized based on a flow of the process of designing a new system -- at each step of the process, the systems people turn to that section in the book.

This book is proprietary -- it provides a real competitive advantage in an extraordinarly complex situation - designing spacecraft. It is also a living document; the engineers are expected to keep adding to it from each project or program.

About 2 years ago I started a similar "guidebook" for our receiving inspection group (yes, I know; a long story). The inspectors maintain the guidebook on-line and say it is very helpful. We have more than 15,000 unique part numbers we deal with in lots from 1 to 1,000, so writing individual receiving inspection instructions for each part would be time consuming. With the guidbook, they can turn to, say, sheetmetal parts and there is a checklist and some lessons learned.

I am also working with a supplier to develop such a guidebook for his programming and manufacturing engineering groups.

You might be able to do the same thing in the administrative areas you are working with. This smacks of APQP and FMEA, but in a format that would be user-friendly for admin types.

Good luck

Ben Royal

Andy Bassett

Poke Yoke a brilliant but simple techniques, icant get this out of my head when i am designing processes, if it is a Manufacturing Process or a Admin Process, i am always thinking how can we guarantee or be certain that the next step in the chain will happen, for exampple in one particular company the relevant engineer was supposed to issue a Engineering Change Release when he changed the index on a part in the computer, but this was only happening 46% of the time, so we reprogrammed the computer to do a screen print-out automatically.

The success rate was now 85%, but we still had the problem of the Engineer remembering to circulate the Sheet. So then we re-programmed the computer tp print the sheets automatically in the Purchase and Stores, very nearly 100% Poka-Yoke.

As i said, i now have this in the back of my mind whenever i am writing a procedure 'How can i Poka Yoke the links between the steps in the process,?

Andy B

Dean Wilson

Poka Yoke engineering is subject to subtle oversights that become obvious only with use of the product. With my 1993 luxury Japanese autombile I can mention two instances.

The central locking system after engine start locks all doors. This action is based on time only, which is only a few seconds after starting. The locking operation should be dependent on at least one additional function, that is, that the shift lever has been moved to the forward or reverse driving position. Movement of the shift lever to the drive position assumes that a driver is seated and ready to go. Actually, closing the door for warm-up with the engine running while I am scraping the windshield results in a locked car. Fortunately, I had a spare key when that happened. It is a major oversight for Poka Yoke engineering.

The second instance is a truly subtle oversight. If the passenger (my wife) operates her passenger door power window switch at the same time as I do with the equivalent window switch on my driver door, the window will stop at some midpoint and remainder inoperative from either switch! That is the way it is explained in the owner's manual. Of course, we do not dare try it.

Poka Yoke is no substitute for human engineering. It is at best supplemental to and complementary to good design practices.

Dean W.

Kevin Mader

One of THE Original Covers!

Your comment on this being a complimentary activity in the design process is right on the money in my opinion. Other complimentary tools, such as the FMEA, might have been the tool to detect issues of lockout with the engine running, or simoltaneous operation of window controls rendering a window useless (hopefully it doesn't get too cold up there in Ann Arbor this time of year). What puzzles me is that the manufacturer detected this failure mode, but only warned against doing this. Could this have been the decided action (placing a warning statement in the owners manual)? Apparently so.


Top Bottom