Home > Community> Gemba Coach> In TPM, Isn't it needlessly costly to replace parts that are working fine? What do you think?

In TPM, Isn't it needlessly costly to replace parts that are working fine? What do you think?

Michael Ballé
1/28/2014
Permalink   |   5 Comments   |   Post a Comment   |  
  |   RSS

Dear Gemba Coach,

I have a question about Total Productive Maintenance. My management has hired a TPM consultant who makes us systematically replace certain parts in our equipment even though they’re working fine. This seems needlessly costly. What do you think?

Ahh... I have to confess I’m not a TPM expert. My very first gemba workshop was a consultant-driven TPM workshop and it remains a vivid memory: picture a young theory of knowledge PhD. Doctoral student cleaning parts in the gut of a huge cold-stamping press. This was the start of my long love affair with the gemba, but, I have to say, not with TPM. I have come across several such programs since with varying degrees of results and so, again, I’m weary of general statements. In some plants I’ve come across, TPM has been hugely positive to get the guys to realize they have to take care of the plant and not just run machines (or people for that matter) into the ground and then replace them. Muri remains the first, and to my mind, most bitter waste.

Over the years, I’ve also witnessed how Toyota engineers helped their suppliers with machine uptime and machine upkeep. It turned out to be quite different, as you can expect, and, if you bear with me as I take a detour, I’ll try to describe the gap.

As a young social sciences researcher I was studying how Toyota taught TPS to one of its supplier. One Toyota engineer convinced me then that, in order to really understand what I was seeing, I needed to get my hands dirty and do some kaizen myself, and so I started helping out a shop floor consulting firm as an extra pair of hands to run their workshops – these were the crazy days of five-days full immersion events and moving machinery around on Wednesday night and hoping the plant would restart on Thursday because top brass was coming on Friday. Looking back, it was completely nuts (a big hello to those of you who still do that), but tremendous fun (for the consultants, that is).

Lean vs. Lean

This is when my research work became very, very interesting because I slowly realized that the “lean” (it wasn’t called lean yet) the consultants were doing and the TPS the Toyota engineers were practicing looked the same but were qualitatively different. As a sociologist, I had landed in one of these rather unique events: a paradigm shift. Paradigm is a big word to describe a set of thoughts and practices in a certain field at a certain time – for instance the Newtonian paradigm describes the world as clockwork driven by gravity, whereas the Quantum paradigm describes the world as, well, a weird incomprehensible place driven by quantum equations our monkey-brains can’t quite grasp. A paradigm shift is when the dominant worldview shifts from one to the other, and as worldviews tend to be “sticky” that doesn’t happen very often. I came to accept that I should not try to understand TPS through the eyes of other engineers, but seek out what was different, not similar.

Back to TPM. All TPM programs have the same goals: maximize equipment effectiveness through a system of preventative maintenance throughout the equipment’s lifetime. Basically, it’s about reducing down time, speed losses and defects. We all agree.

The way to do this in the traditional paradigm is through a maintenance schedule. You use the data you have on equipment breakdown to analyze the most sensitive parts and how long they last, and, much as with your car’s service, you plan the maintenance schedule of every piece of kit. In practice:

  1. List all the equipment requiring maintenance work
  2. Assign priorities (ha!)
  3. Estimate costs
  4. Create a schedule
  5. Make sure all the parts needed are ordered on time
  6. Implement the calendar and review failure data.

Sensible? Of course this is far from simple because equipment is rarely available when scheduled, maintenance is often organized by functional specialties (electricians won’t touch mechanics, etc.) and the maintenance guys are rarely free when scheduled and finally, well, breakdowns to occur and every one will be pulled in getting the machine back to work and there goes your plan.

I suspect that this is what the consultant you mentioned set up for your plant – a rigorous (and probably smart) schedule of maintenance and parts replacement that should, in theory, pay for itself in machine availability and OEE.

Autonomous Team Members

What I saw Toyota engineers teaching their suppliers was rather different. They weren’t looking to establish a schedule upfront (thought that did happen on some things). They were trying to solve three specific problems:

  1. How do we improve team member’s autonomy with the machines they handle?
  2. How do we treat each equipment as an individual?
  3. How do we free the maintenance department from as many things as we can so they can focus on rapid intervention and complex tasks?

To grasp how different this is, think of kanban. In the old paradigm, kanban is about replacing MRP with cards – essentially replacing one production scheduling system with another. People are obsessed with calculating the ideal number of kanbans, with seeing the full flow of kanbans in their VSMs and so on.

TPS engineers were trying to do something rather different: they wanted the operators on the cell to be autonomous as regards to their logistics. Team members had to be able to tell at any moment:

  1. What they were supposed to work on now (the current production kanban)
  2. What they would do next (the next kanban in the launcher)
  3. Order the materials they needed for the next hour of production (the materials ordering kanban).

The system had to work to make team members autonomous as regards their logistics function. When you think about, it this is quite an endeavor: simplifying the logistics function to the point that team members can handle it without it breaking their cycle by distracting them from their work (think about what happens when one has to decipher a production instruction order). The spirit of kanban is cell autonomy, and the fact that when kanbans fail, the cell STOPS, CALLS (through the andon) and WAITS (rather than start working on another part – overproduction).

The same spirit applies to maintenance: how can team members be more autonomous in handling their own equipment. Well, the same simplifying hard work needs to be done until regular maintenance can be done by the team members themselves without losing more than 5 minutes of production time per shift. On the gemba this appears as:

  1. Clearly indicated checkpoints on the cell to show what needs to be maintained.
  2. Easy maintenance activity with clear instructions (cleaning, oil lubrication, etc.- should be self-explanatory.
  3. Constant training and coordination with maintenance technicians to further simplify maintenance.

With this in mind, we can now build a profile for the machine according to their age – I remember in Japan a Toyota supplier where all machines had a large sign stating their age, a few going back to before I was born – and their peculiarities. The maintenance parts ordering system can now work just-in-time with:

  1. Current parts on hand in stock replenishment
  2. Some specific parts with one part in stock and immediate replenishment when used
  3. Parts that need to be ordered when needed, but with a clear identified supplier and a taxi system to fly them in quickly.

In this way, the plant learns to do what your consultant is trying to get you to do without carrying the extra cost that you have – rightly – noticed.

Machines Are Your Patients

In the end, maintenance will increasingly be about big data. Toyota veterans tell me that they keep historical information on all their important machines and they can compare performance across the group! Clever IT is definitely needed, but not so much on the scheduling front, but on understanding each machine as one would a patient and drawing the right conclusions for engineering to focus on: what do they need to strengthen in the process to avoid repetitive problems.

The deeper point here is about changing one’s perspective. The insight of lean is not to try to maximize the efficiency of the system at system level (no matter how consultants project this onto lean) but about developing the autonomy of team members and equipment by knowing them as individuals and training them one by one. In this, the lean ideal is indeed that of craftsmanship – the pilot in love with his 1930s biplane, the old car enthusiast – within the context of mass production efficiencies. We need to seek that space in all we do, including maintenance.

I recently had the opportunity to visit Toyota’s first historical plant out of Japan in Sao Paulo in Brazil, where they showed me a 1937 press still making parts for the Corolla, in mint condition. Now, that is TPM!

5 Comments | Post a Comment
Keith Lodahl January 29, 2014

While as a maintenance geek I appreciate the history lesson, I think the short answer to the question is that if the parts being replaced have a history of failure at a certain point, and their failure prevents the equipment from producing when needed, then it is more costly to continue to run with the old parts.  I am sure that at times the existing parts can last longer, and at times new parts will fail prematurely.  All we can do is go with the normal condition, replace the parts, and keep the process going.

Michael Ballé January 30, 2014
Good point, but where is the learning process in that? As in, how are you going to kaizen your maintenance cost to reduce it?
Mark Jaben February 1, 2014
Michael,
....'the insight is to develop the autonomy of team members and equipment....' I really appreciate that.

I work as an emergency physician, and find that there are  layers of coordination/synchronization required for an individual to function autonomously in this tightly woven, highly interactive environment, in order 'to be autonomous as to their logistics.'
 
It manifests itself in the decision about which task to do next, of all the tasks I have to do right now for multiple patients, each at a different stage in their own process through the system, all at the same time.

That choice might benefit my work flow, but might also come at the expense of someone else's work flow and it may not be the best choice for the general flow in the emergency department as a whole, which might translate into not the best for the patient.

This reminds me of what the Lean construction movement talks about- namely, that individual subs do their work upon a substrate/ foundation of the overall project. In other words, the overall performance of an individual might be great, but the overall effect for the end consumer will not be its best if the worker has to do this work upon a foundation that is not solid and square'.   

Individuals will make the choice at that time based on what is beneficial to their individual work flow. But a better choice would incorporate the needs of the other workers also juggling their tasks among their many (and often different group of) patients all at the same time, as well as respond to the overall condition of the emeregnency department (has there been a sudden influx of patients? is the ED already full and overflowing? are there resources not available?) at that time and what is needed to keep the ED 'well,' ie, solid and square (available space for the next patient, available staff, inpatient beds available for waiting admisions, etc)--

This is a complex system, indeed. And why 'rules' about what task to do next aren't helpful--too many variables, changing too often. 

And why your prior post about Lean's insight is as a system to ask the right questions is so meaningful- the 'right' questions to focus on the 'right' leverage points in order to make the best choice of that 'next' task- and to kaizen your way to learn what it takes to do this even more effectively.

Also from a previous post of yours, 'the key insight was that your misconceptions add unnecessary cost to your method of production.'
Back to that 'stickiness' of our brains. But that is a bigger discussion we could have.

Thanks   
  
Michael Ballé February 3, 2014
Michael Ballé February 3, 2014

Great insights - I'm just back from a hospital gemba, and what you say is absolutely right. 

And complex.

What I find striking in such momentous organizations (8000 people working in the same location in that hospital) is how quickly the individual patient becomes an alibi to let each professional body do their stuff. They keep referring to "the patient" as an abstraction to justify corporatist rules - who has the right to decide what about patients. I'm not criticizing, just noting.

Which creates a favorable environment to approach lean as yet one more "solution". We already have doctors, nurses and logistics competing with their set of rules, and now managers bring in their own. For instance, we were in the emergency ward and the Quality Director (a good guy, no worries there) was horrified at the state of the work environment and arguing for "5S".

What's the pont of 5S without standardized work? I asked (not in those words). How does 5S help with a patient? the ward nursing manager got that immediately and suggested that his teams do simulations to see how they could corrdinate better with a patient at the center of the organization. This started to make more sense: 5S is a tool to develop each team member's autonomy in carrying out standardized work.

There is no standardized work in an emergency ward, by nature, but still, there are some standard activites, we were watching simply shifting a patient from first help stretcher to hospital bed - mess and confusion.

So absolutely, all of these concepts and tools have to be taken with CARE. A seventy old man in mild pain, but with mobility difficulties is not a child in severe pain. Within this difference, certain professional acts have to be carried out in absolute certainty and confidence. Let's focus on these, and use the lean tools to create the conditions for confidence for the patient (I believe confidence is part of the treatment) and for the pysician, in a way that libberates minds and eyes to see the SPECIFICITY of each patient. 

Having said that, I have to say my enormous respect for all that work in such jobs - it's easy to pontificate, but all I do is walk the gemba and I find the emotional load overbearing, so respect to you all who work for our well-being!