Most of the work we do today involves interactions with machines. It is true not only in manufacturing but in many other business processes. The machinist works with machining centers, the pilot with an airplane, the surgeon with a laparoscopy robot, the engineer with a variety of computer systems,…, not to mention the automatic appliances that relieve us of household chores. In fact, I think that being good at working with machines is so essential that I wrote a book about it. For the short version, see the following A3/tabloid infographic. To enlarge it, click on the picture, and then on “View full size” in the bottom right-hand corner.
I own two dishwashers in two homes, different models from the same brand, bought in the same store, and both on a service contract. For the first one, the model number is SHE55R56UC; for the second one, SHE65T55UC. Today, we needed help on the first one, but customer service shipped us parts for the second one, which the repair technician discovered when unpacking them.
Whether you manage operations with paper and pencil as in 1920 or use the state of the art in information technology (IT), you need clean data. If you don’t have it, you will suffer all sorts of dysfunctions. You will order materials you already have or don’t need, and be surprised by shortages. You will make delivery promises you can’t keep, and ship wrong or defective products. And you will have no idea what works and what doesn’t in your plant.
I have never seen a factory with perfect data, and perhaps none exists. Dirty data is the norm, not the exception, and the reason most factories are able to ship anything at all is that their people find ways to work around the defects in their data, from using expediters to find parts that aren’t where the system thought they were, to engineers who work directly with production to make sure a technical change is implemented. Mei-chen Lo, of Kainan University in Taiwan, proposed a useful classification of the issues with data quality. What I would like to propose here is pointers on addressing them.
A free guide that you can download from ERP Focus makes vendor selection the first of an 11-step implementation process, while defining success is the last. In other words, they have you choose who you buy from before having a clear idea of what you are trying to accomplish.
It reminds me of a meeting at a client site where ERP implementation was about to begin. “This train has left the station,” I was told. The purpose of the meeting was to draw a “Value Stream Map” for the whole plant, in preparation for ERP, and the participants included managers from Manufacturing, Quality, Production Control, Maintenance, Purchasing, Sales, and Engineering.
This is a translation of Bodo Wiegand’s latest newsletter, about Lean in Germany, followed by my comments:
This week I was with a company that is on its way to implement industry 4.0. All machines were networked. The manager could see from his desk which machines were running and which were not. All data were collected centrally and also shown locally to the machine operator. The trend was easy to see. One third of the machines had a malfunction. With an average OEE of 62%, the machines do not always run.
“As long as we buy new machines, we have to live with this,” was his answer to my question.
But, it was not only the newest, but also the older machines that don’t need to be smeared with oil and dirty, even even while generating chips. Provided on request, the Fire-Fighting-factor reported to us by the maintenance technicians was above 75%. The chief knew exactly: 76.6%. An OEE of 62% and 76.6% Firefighting means in plain language: In this business, there is no stable processes.
But what drives intelligent managers then to link his whole company, only to find that the processes are unstable? With some thought they could have discovered this without networking and invested first in stabilizing the processes. Introducing Industry 4.0 For industry on unstable processes will fail. The crucial question: how I manage to stabilize the processes and avoid unplanned shutdowns?
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:
- No production supervisor in his right mind would disconnect devices that make the work easier for operators. If they do disconnect them, the most likely explanation is that the devices described as “Poka-Yoke” actually add work for the operator. If you have to pick a part from one of ten open bins in front of you, you will spend precious seconds finding the right one; if all bins are covered with lids except the right one, not only are you physically prevented from picking the wrong one but you don’t have to look for it. It makes your job easier. On the other hand, if you have to scan a bar code on the part to validate the pick, it adds to your work load and your supervisor will pull the plug on the next production rush.
- The manufacturing process is not ready for Poka-Yoke. A production supervisor is quoted in the question as saying “operators can’t run production and cope with the complexity of our machines.” This suggests that the line has process capability issues that must be addressed before implementing Poka-Yoke.
The following paragraphs elaborate on these points.
Philip Marris and I got to know each other on line, by participating in the same discussion groups, and met in person last year. The following conversation was recorded a month ago, in the Marris Consulting office in Paris:
Philip Marris: Hi, Michel, welcome to Paris! I am glad to take this opportunity to ask you about one of your books that I love, called Working with Machines. As far as I know it is one of the rare books on that subject, at least in terms of treating it in as much detail as you do, and it is about a subject very close to my heart, which is the relationship between the worker and the machine. Can you tell me what made you want to write the book and what the main messages are?
Michel Baudin: Well, what made me write it is that putting together systems of people and machines is central to manufacturing, and one of the things I learned from Kei Abe early in my career in consulting. There are a number of techniques like the work-combination chart, which is a typical tool of this area, and there is not very much written about it in English. You have books about automation, but the American books about automation say nothing about people. It’s like people are an afterthought. You get books about FMSs, and you see diagrams of machines, but you never see information about what people are supposed to be doing.
“There are many different ways to measure manufacturing speeds. Depending if you need the losses included or not, if you want parts per time or its inverse or only a time, single processes or entire systems, actual or current values, you may have a completely different number. This post will help you to sort out what is what…”
Sourced through Scoop.it from: www.allaboutlean.com
Michel Baudin‘s comments:
The main conclusion from this post is that, when discussing production speed, you should define your terms if you want to avoid confusion.
Jidoka (自働化) isn’t just “stop and fix” or “stop and call.” It is a complete approach to automation that includes building in the ability of a machine to stop when it malfunctions but also includes many other things. Sakichi Toyoda’s Type-G loom didn’t just stop when the yarn broke, it also had automatic shuttle change, which reduced the need for human intervention in its normal operations, and was a breakthrough that had eluded everybody else.
What passes for “business analytics” (BI), as advertised by software vendors, is limited to basic and poorly designed charts that fail to show interactions between variables, even though the use of scatterplots and elementary regression is taught to American middle schoolers and to shop floor operators participating in quality circles.
But the software suppliers seem to think that it is beyond the cognitive ability of executives. Technically, scatterplots are not difficult to generate, and there are even techniques to visualize more complex interactions than between pairs of variables, like trendalyzers or 3D scatterplots. And, of course, visualization is only the first step. You usually need other techniques to base any decision on data.