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

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

[Marc]

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.

Regards,

Erasmo A. González
ITESM-CEM

[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.

Laura

[Kevin Mader]

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!

Regards,

Kevin

[BRoyal]

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