Skip to main content

Role of Management in a Lean Manufacturing Environment

Gary Convis, President, Toyota Motor Manufacturing Kentucky

Since this column is meant to link automotive engineers with lean manufacturing, I would like to share my personal experience as a mechanical engineer who started out in the traditional way of manufacturing, and along the way discovered a much better way - the Toyota Production System.

I will describe what it was like to transplant this philosophy to American soil, in hopes that anyone attempting to change the culture of an existing plant towards "lean manufacturing" can benefit from my experience and observations. In particular, I intend to focus on the role of management in a TPS (or any lean manufacturing) environment.

In 1964, I took my hot-off-the-press BSME diploma and went to work for GM in their management training program. Later I joined Ford and worked my way up through Quality, Engineering, Maintenance and Manufacturing Management. During this 18-year stint I became acutely aware that our industry was in trouble. We were stuck in doing things the same old way, and that way was not getting the job done. We couldn't respond to the changing market. Worst of all, the people working in our plants couldn't make things better, even though they had plenty of good ideas, because they were bogged down by the rigid, traditional structures.

So I was ready for something new, and I found it - or rather, it found me, when Toyota recruited me to help start up NUMMI -- Toyota's joint venture with GM. For Toyota, it was a cautious first step; they were not at all sure that Americans could learn how to apply the Toyota Production System. But I was convinced that American workers were just as good as workers anywhere, or at least they could be, if they were allowed to perform up to their potential.

That was in 1984. I was part of the NUMMI team for 15 years, and it was a great experience. TPS proved to be highly successful at NUMMI, in spite of the fact that Toyota took it into a plant that had been closed two years earlier, and hired back most of the same people who had worked there before. Toyota's way of managing and manufacturing enabled us to make a total turnaround of that plant. Encouraged by NUMMI's success, Toyota built a plant in Kentucky, where I am now President.

In my opinion, the key to the successful implementation of TPS at NUMMI, and TMMK, and at the other Toyota plants in North America, has been the total commitment on the part of everyone to make it work. By that I mean, all levels of the organization, from team members to the senior managers, have to be aware of the fundamentals of TPS and have to make their best efforts to practice and improve them day-by-day. This is much easier said than done, and I'll come back to this point later.

One of the fundamental elements of TPS that management must be fully committed to is the "customer-first" philosophy. Typically, organizations envision the customer only in terms of the person who purchases the final product at the end of the process. TPS has a different view.

Essentially, each succeeding process or workstation or department is the customer. In a Toyota plant, we work very hard to ensure that all team members and all departments realize their dual role: they are at once the customers of the previous operation and the suppliers to the next operation downstream.

For this concept to flourish, there must be no artificial barriers walling off one area from another or one department from another. Rather, the entire organization shares problems and must work together to ensure that a solution is found. Therefore, it is critical for the successful implementation of TPS that all managers support this idea and aggressively seek to solve problems, even if they are not directly within their scope of control. This all-hands-on-deck attitude is essential in a TPS environment.

The Toyota Production system is an integrated and interdependent system involving many elements. I like to think of it as a triangle, where one side is philosophy, one side is technology, and the other side is management. Cradled in the middle of the triangle is what TPS is really all about - people. Human development is at the very core of TPS. It is often overlooked, as people seize on the more tangible aspects of TPS. Engineers are particularly likely to latch on to tools like kanban, heijunka, and jidoka, and think they have captured the essence of TPS.

Of course the tools are important. TPS uses the technical elements, such as kanban, just-in-time, small lot delivery, Jidoka or quality in the process, heijunka or leveling of demand, visual control and 5S or clean, orderly worksites, to manage the day-to-day production system as efficiently as possible.

But the basic tenet of TPS is that people are the most important asset, and, for that reason, management must have a shop-floor focus. Toyota managers are taught that all value-added activities start on the shop floor; therefore the job of managers is to support the team members. Production team members appreciate management on the shop floor only when they can see that we are out there to help them do their jobs, not as part of a command structure, bent on telling them what to do.

In my experience, the most common roadblock to the successful implementation of TPS is the failure on the part of management - and particularly senior level leaders - to understand TPS as a comprehensive approach to manufacturing and management. Too often, company leaders lack the total commitment to, and understanding of, TPS, that are essential to its adoption, and are unwilling to be involved in its day-to-day implementation and application. TPS is not simply a set of concepts, techniques and methods, which can be implemented by command and control. Rather, it is a fully integrated management and manufacturing philosophy and approach which must be practiced throughout the organization from top to bottom and consistently applied and kaizened day in and day out.

Another common reason TPS implementations fail is that managers try to implement individual elements instead of the entire TPS approach. Since the elements of TPS are integrated and interdependent, any attempt to implement TPS only partially is bound to produce very unsatisfactory results.

For TPS to work effectively, it needs to be adopted in its entirety, not piecemeal. Each element of TPS will only fully blossom if grown in an environment that contains and nourishes the philosophies and managerial practices needed to support it. I liken this to a greenhouse, where just the right combination of soil, light, temperature, humidity, water and nutrients allow plants to grow and flourish. If any one of these elements is removed, the plants will weaken and eventually die.

TPS is an interlocking set of three underlying elements: the philosophical underpinnings, the managerial culture and the technical tools. The philosophical underpinnings include a joint shop-floor, customer-first focus, an emphasis on people first, a commitment to continuous improvement or kaizen, and a belief that harmony with the environment is of critical importance. The managerial culture for TPS is rooted in several factors, including developing and sustaining a sense of trust, a commitment to involving those affected by first, teamwork, equal and fair treatment for all, and finally, fact-based decision making and long-term thinking.

All of these facets of TPS - the philosophical mindset, the managerial culture and the technical tools - must be in place and in practice for TPS to truly flourish and provide the high-quality, high-productivity results it is capable of producing.

What have I learned from my experience with the Toyota Production System, that I can pass along to you? First, I have learned that the human dimension is the single most important element for success. Management has no more critical role than motivating and engaging large numbers of people to work together toward a common goal. Defining and explaining what that goal is, sharing a path to achieving it, motivating people to take the journey with you, and assisting them by removing obstacles - these are management's reason for being.

I'll never forget the wise advice given me by a man I grew to respect and admire very deeply, Mr. Kan Higashi, who was our second president at NUMMI. When he promoted me to vice president, he said my greatest challenge would be "to lead the organization as if I had no power." In other words, shape the organization not through the power of will or dictate, but rather through example, through coaching and through understanding and helping others to achieve their goals. This, I truly believe, is the role of management in a healthy, thriving, work environment.

Gary Convis is President, Toyota Motor Manufacturing Kentucky. He is the first American president of a Toyota vehicle manufacturing plant (anywhere in the world).

Post a Comment

Popular posts from this blog

Escalate, Escalate, Escalate!

What is escalation at organizations? Is it a way to solve problems? Is it a way to report things? Is it a way to put more pressure? Is it a CYA technique? What is it? How do you use it at your organization? How other colleagues of yours use escalation? Really, think about it and observe.

At IT service companies, leadership measures the performance of IT Help Desk by number of escalated work items over a period of time. The less escalation the better. The reasons are simple:

It is cheaper for companies if an IT Help Desk Specialist resolves an issue than an experienced technical specialist at one or two level higher. This is simple math, one gets $X and the other get $X*2And when client gets result fast, he/she will be happier. So, less escalation equals happier client in IT Services. Client raise an issue, IT Help Desk Specialist resolve it, BOOM, Next!

At organizations, It is amazing (sadly) to see how much lower level managers escalate problems, that they and their fellows can resol…

DAD Inception Phase Workshop Agenda

Disciplined Agile Delivery (DAD) realised the reality of the projects and introduced back phases to Agile community. Whoever works in a project based company, especially a project based company where projects are usually less than one year in length and each are for different clients, understands the reality of Agile in such environment. When you start working on a new project for a new client, it is essential to go through a phase that you get to know each other better, to understand the business purpose of the project, to understand the scope of the project, to know what are the high level architecture and what technologies are going to be used and who is the initial team, and if funding is available and also when things must be delivered and to whom.
In answering these questions you may need to meet with different people, run couple of workshops and brainstorming sessions. And this is called Inception Phase. As DAD is more like a goal oriented decision framework and not a prescrip…

Collocation is not the silver bullet for success and agility

To collocate or not to collocate? Most companies that are new to agile have been "consulted" by a "Scrum" Agile Coach, who suggested that they must break their organisation and have cross-functional teams to sit together in one location. Is that the recipe for success?.. Is it really?

Even though collocation has its benefits, it is not the necessary condition for a successful delivery team. Collocation as a dogmatic view may hurt you more than you think, and will not necessarily help you to deliver more successful products.

I am neither for nor against collocation, but I have experienced and worked with both approaches. And each sometimes worked very well and sometimes failed. All the variations of teams geolocation (collocated, fully-dispersed, partially-dispersed, or distributed) can work. It all depends on how the collaboration model is setup, what is the context and conditions, and how much the team and organisation are aware of each other, and are aligned.