Jan 13 2020
“Human work engineering” is neither a major in any university nor a job title I have ever encountered. As a specialty, it would integrate content currently filed under Human Factors, Ergonomics, Safety, Human-Machine Interfaces, Usability Engineering, Mistake-Proofing, and Jidoka into a consistent approach to production and service delivery.
But wait! Isn’t it what Industrial Engineering (IE) was supposed to be?
Nov 30 2015
Chet Marchwinski recently exhumed a 2011 discussion about Poka-Yoke that had been started by the following question:
I’m a manufacturing engineer and since I have started participating in kaizen workshops, I have noticed that production supervisors tend to disconnect some of the poka-yokes we’ve put in place in the machines. When I challenge them about this they argue that operators can’t run production and cope with the complexity of our machines. I am perplexed by this and wondered whether you’d have a comment.
In short, I can think of two reasons for production supervisors to disconnect Poka-Yoke:
The following paragraphs elaborate on these points.
Nov 8 2014
“Shigeo Shingo developed processes, called “devices,” which made errors much less likely. In one of the examples used by author Harry Robinson, Shingo created a process where workers were required to take two small springs and put them into a dish before assembling a switch (which used the two springs). While this seems like a waste of time, it stopped the workers from forgetting to put the springs into the switch to start with, which saved an enormous amount of time by preventing technicians being sent to customer locations for repair.”
Source: www.compaid.com
What could possibly go wrong? Placing two springs in a dish prior to assembly not only adds a handling step, but it neither physically prevents a mistake, nor immediately detects it once made. A new operator, or one who fills in for another who has the flu, is likely to skip this step, particularly if necessary to sustain the pace.
This example not like any Poka-Yoke I am used to, like the slots in my printer that are shaped so that an ink cartridge of the wrong color won’t go in, or the food processor that is started by pressing on the lid. These devices actually make mistakes impossible without adding any work, so that there is no incentive to bypass them.
And it’s not difficult to imagine methods that might have worked with the switches. For example, the springs, presumably prop the buttons up, and a whisker hanging over the assembly line might be triggered only if the switch is tall enough…
This article made me wonder whether Shingo, the inventor of the Poka-Yoke concept, had actually come up with this dish idea. It is indeed on p. 44 of his book, “Zero Quality Control: Source Inspection and the Poka-Yoke System,” and he does call it a Poka-Yoke, even though he didn’t coin the term until two years later.
It is the only example I remember seeing in the Poka-Yoke literature that does not meet the requirements of being 100% effective and not adding labor.
Devices and methods that make errors less likely are useful too, but not mistake-proof. It is usability enginering. If you make operations easy to understand with intuitive, self-explanatory user interfaces, mistakes may be so rare that you don’t need mistake-proofing. It’s fine, but it’s not mistake-proofing.
See on Scoop.it – lean manufacturing
Jun 21 2014
“Poka-yoke is a Japanese term that means “mistake-proofing”. It surfaced in the 1960s, and was first applied in the car manufacturing industry. Poka-yoke is credited to industrial engineer Shigeo Shingo.”
Source: sixrevisions.com
That IT specialists should be interested in the Poka-Yoke concept is natural. There are, however, consequential inaccuracies In the way it is described in many English-language sources, including Wikipedia.
The example given as the first Poka-Yoke is a redesign of a switch assembly process that involved presenting springs on a placeholders so that the operator would not forget to insert one.
Assuming this is a true example, it has two characteristics that make it different from the other examples given in Shingo’s book or in Productivity Press’s big red book of Poka-Yoke.
First, having a placeholder does not physically prevent the operator from making a mistake. A classical example of a system that does is one that puts a lid on every bin except the one the operator needs to pick from.
Second, this example adds labor to the operation, which means that the preparation step of placing the springs in the placeholder is likely to be by-passed under pressure. This is why it is a requirement for a Poka-Yoke not to add labor to the process.
For the same reasons, a multi-step deletion process in a software interface does not qualify as a Poka-Yoke. If you do multiple deletes, you end up pressing the buttons in rapid succession, occasionally deleting items you didn’t intend to, while cursing the inconvenience of these multiple steps.
Having different, incompatible plugs certainly made it impossible to plug the keyboard into a port for an external disk. USB, however, was an improvement over this, because, with it, the machine figures out the purpose of the connection. A connector that you can insert in any orientation is even better. It saves you time, and there is no wrong way to plug it in. This is a genuine Poka-Yoke.
There are other, useful approaches that make mistakes less likely without preventing them outright. Don Norman and Jacob Nielsen call them “usability engineering.” They should certainly be used in user interface design, but not confused with Poka-Yoke.
Jan 16 2014
See on Scoop.it – lean manufacturing
“Human Errors, Poka Yoke are concepts brought to life from my experience with coffee cup. One can learn a lot about Poka Yoke and Human Errors. This is a story about what a coffee cup taught me about how poor design in our products and systems invite human error.
Many years ago, I had to travel to Dublin every few months for work. […] One very early morning while waiting for the taxi to pick me up at my hotel to take us to the airport, my colleague with whom I was traveling with at the time had ordered coffee while I ordered a Coke since I’m not a coffee drinker. They brought him his coffee in this cup.”
With its unsightly bumps and nooks, the “fancy cup” you show is not even pretty, which makes you wonder what the designer had in mind. The issues you bring up, however, are more about usability engineering in Don Norman’s sense, than Poka-Yoke.
A properly designed handle is self-explanatory in that any user who has never seen a cup will immediately understand what it is for. But it doesn’t make the cup mistake-proof: there is nothing physically preventing you from pouring coffee onto it while it is upside down.
Usability engineering is about controls that look and feel distinctive to the touch — as opposed to rows of identical buttons — that give you feedback when you have activated them, that have shapes that naturally lead you to use them properly, that respect cultural constraints in the meaning of shapes and colors, etc.
Applying these principles in designing human interfaces reduces training costs and the risk of errors. It is valuable, but it does not prevent errors.
Incidentally, why do so many cultures, including Japan and China, use cups with no handles? An alternative to handles to avoid burning your fingers is the double-walled cup, and I have seen some from China. Otherwise, I have resorted to the Arab way of holding a handleless tea cup: between my thumb on the bottom and my index finger on the rim.
See on www.shmula.com
Feb 20 2022
Visual Management
[Featured image from Edward Tufte’s Envisioning Information)
Tracey Richardson started a spirited discussion on LinkedIn just by posting this quote, presumably from Toyota training materials, and asking “what else would you add to describe ‘Visual Management’”:
Continue reading…
Contents
Share this:
Like this:
By Michel Baudin • Management • 4 • Tags: ISOTYPES, Toyota, TPS, Usability Engineering, Visible Management