The Elsmar Cove Business Standards Discussion Forums More Free Files Forum Discussion Thread Post Attachments Listing Elsmar Cove Discussion Forums Main Page
Welcome to what was The Original Cayman Cove Forums!
This thread is carried over and continued in the Current Elsmar Cove Forums

Search the Elsmar Cove!

Wooden Line
This is a "Frozen" Legacy Forum.
Most links on this page do NOT work.
Discussions since 2001 are HERE

Owl Line
The New Elsmar Cove Forums   The New Elsmar Cove Forums
  Miscellaneous Quality Topics
  Poka-Yoke applied to Administrative Processes

Post New Topic  Post A Reply
profile | register | preferences | faq | search

UBBFriend: Email This Page to Someone! next newest topic | next oldest topic
Author Topic:   Poka-Yoke applied to Administrative Processes
erasmo_gonzalez
Lurker (<10 Posts)

Posts: 2
From:Mexico City, Mexico
Registered: Dec 1999

posted 21 December 1999 02:07 PM     Click Here to See the Profile for erasmo_gonzalez   Click Here to Email erasmo_gonzalez     Edit/Delete Message   Reply w/Quote
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
ITESM-CEM
Ph. (525)822-8961
Fax. (209)391-39-42
Email: erasmo_gonzalez@yahoo.com

IP: Logged

Marc Smith
Cheech Wizard

Posts: 4119
From:West Chester, OH, USA
Registered:

posted 22 December 1999 03:15 PM     Click Here to See the Profile for Marc Smith   Click Here to Email Marc Smith     Edit/Delete Message   Reply w/Quote
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.

IP: Logged

David Mullins
Forum Contributor

Posts: 248
From:Adelaide, South Australia, Australia
Registered: Nov 1999

posted 22 December 1999 07:14 PM     Click Here to See the Profile for David Mullins   Click Here to Email David Mullins     Edit/Delete Message   Reply w/Quote
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.

------------------

IP: Logged

erasmo_gonzalez
Lurker (<10 Posts)

Posts: 2
From:Mexico City, Mexico
Registered: Dec 1999

posted 22 December 1999 07:30 PM     Click Here to See the Profile for erasmo_gonzalez   Click Here to Email erasmo_gonzalez     Edit/Delete Message   Reply w/Quote
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

IP: Logged

Laura M
Forum Contributor

Posts: 299
From:Rochester, NY US
Registered: Aug 1999

posted 23 December 1999 05:11 PM     Click Here to See the Profile for Laura M   Click Here to Email Laura M     Edit/Delete Message   Reply w/Quote
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

IP: Logged

Kevin Mader
Forum Wizard

Posts: 575
From:Seymour, CT USA
Registered: Nov 98

posted 27 December 1999 09:05 AM     Click Here to See the Profile for Kevin Mader   Click Here to Email Kevin Mader     Edit/Delete Message   Reply w/Quote
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

IP: Logged

BRoyal
Forum Contributor

Posts: 22
From:Charlotte, NC
Registered: Nov 98

posted 03 January 2000 09:14 PM     Click Here to See the Profile for BRoyal   Click Here to Email BRoyal     Edit/Delete Message   Reply w/Quote
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

IP: Logged

Andy Bassett
Forum Contributor

Posts: 274
From:Donegal Ireland
Registered: Jun 1999

posted 14 January 2000 04:35 AM     Click Here to See the Profile for Andy Bassett   Click Here to Email Andy Bassett     Edit/Delete Message   Reply w/Quote
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

IP: Logged

Dean Wilson
Lurker (<10 Posts)

Posts: 1
From:Ann Arbor, MI, USA
Registered: Jan 2000

posted 01 February 2000 10:57 AM     Click Here to See the Profile for Dean Wilson     Edit/Delete Message   Reply w/Quote
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.

IP: Logged

Kevin Mader
Forum Wizard

Posts: 575
From:Seymour, CT USA
Registered: Nov 98

posted 02 February 2000 09:48 AM     Click Here to See the Profile for Kevin Mader   Click Here to Email Kevin Mader     Edit/Delete Message   Reply w/Quote
Dean,

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.

Regards,

Kevin

IP: Logged

All times are Eastern Standard Time (USA)

next newest topic | next oldest topic

Administrative Options: Close Topic | Archive/Move | Delete Topic
Post New Topic  Post A Reply Hop to:

Contact Us | The Elsmar Cove Home Page

Your Input Into These Forums Is Appreciated! Thanks!


Main Site Search
Y'All Come Back Now, Ya Hear?
Powered by FreeBSD!Made With A Mac!Powered by Apache!