Problem Solving and the Lean Journey

Samuel Obara has published a great new book titled Toyota by Toyota: Reflections from the Inside Leaders on the Techniques That Revolutionized the Industry. This book comprises chapters written by former Toyota associates from locations around the world detailing their experiences learning, understanding, and leading Lean culture and methodologies.


Samuel was the main editor and composed a chapter on the problem-solving PDCA (plan-do-check-act) method. I recently asked him: "Why is problem solving so important along the Lean Journey?" Here is his response:


When introducing and implementing Lean techniques, one will certainly face many problems. For example, we cannot connect processes without hitting several problems; we cannot lower inventory levels without unveiling new problems; we cannot adjust to Takt time without encountering all sorts of problems.


With so many new problems being created so fast, solving them in an effective way becomes vital to solidify the success of each step in the Lean journey. Adopting early a methodology that has been proven effective can avoid the frustration of the constant hitting or missing. In today’s competitive environment, the winner is whoever misses the least.


One question that can start an effective discussion is: How well are we using the problem-solving methods that are widely available and have been proven effective? Sometimes the impression is that we overlook the connections between the facts and always end up with the solution we had preconceived way before we started.


Another question is: Why are we so afraid of problems? In many organizations people simply abolished the word problem. This forbidden word has now officially been replaced by opportunities. This attitude tells me people really have great fear of problems. As my colleague and mentor Darril Wilburn always says, "Opportunities are taken, problems must be solved.” He reminds me that problem solving is such a fundamental and intricate element of TPS/Lean that Toyota calls problem solving "the Toyota Business Practice." In reality, the common job description of all associates is problem solver.


Because a Lean journey implies that problems will always be created, we must ensure that we develop problem solvers that truly state the problem and understand the root causes. The better we are the less we fear.

How does problem solving function in your company? Does your company use a specific methodology?

Psychological Barriers to Lean Initiatives?

Chris Ortiz has published many books on kaizen and its benefits, but his recent book -- The Psychology of Lean Improvements: Why Organizations Must Overcome Resistance and Change the Culture -- covers an entirely different area of Lean initiatives: the psychology behind why businesses avoid Lean transformations. I recently spoke to Chris and asked him, "Why are there psychological barriers to Lean initiatives?" Here is his insightful response:

Change is never easy. Even in micro-amounts, we as humans avoid change. Even though positive transformation can result, changing paradigm, breaking old habits, and discarding established routines can be tough transitions for anyone, management included. Resistance to change will come in a variety of forms and we as consultants can see it at all levels.

You can sense the anxiety in people when their work area is being changed and more severally when there is no real reason why (or at least in their minds). Front-line workers may or may not see Lean as “leaning people out.” Improved productivity and reduced cycle times may be perceived as less work, and then less jobs. Unless the company is nearing complete bankruptcy, Lean is not intended to eliminate jobs.

One psychological barrier is the concept of victimizing. Victimizing is the sense people have that the company is reducing waste with no real reason. It almost borders on a feeling of being personally attacked. People become very attached to their space and oddly enough, to things they don’t own. There is sense of oneness with the means at their disposal. Often it is the only place at work they feel they have control over. As the team is sorting tools and removing what is deemed unnecessary, I often hear from resistant workers, "What are YOU going to do with MY tools?" This is a good example of what you will have to deal with. People often find something "negative" or out of place to recognize and not the effective aspects.

This is just part of the resistance to change even if it does not involve the person making the comment. Fear of change. We all have it. We all deal with it differently. Some of us accept change immediately, some take a little time, others never get there.

What do you think of Chris' thoughts? Does his summation reflect your experiences? How have you overcome the resistance to improvement? Lean has been labeled "anti-intuitive" -- Is that a strong factor that leads to resistance?

The Self-Balancing Line Method -- The "What" and "Why"

I met Gordon Ghirann about five years at an Association for Manufacturing Excellence (AME) conference. At that time, he was giving a presentation at the conference about the benefits of "Self-Balancing" line method. Now, in 2012, he has published a book on the method titled The Basics of Self-Balancing Processes: True Lean Continuous Flow.

I recently spoke with Gordon about this method and asked him quite plainly: "Why should the 'self-balancing' method be implemented at manufacturing organizations?" Here is his response:

First, it is quick to implement and very flexible. This is important if you are in a start-up mode and/or having frequent changes to your processes. The laborious task of trying to exactly divide the work content evenly is eliminated. With Self-Balancing, adding or removing work content does not cause your line to go out of balance, nor does adding or removing operators.

Second, even if your line is fairly stable, Self-Balancing has consistently been over 30% more productive than traditional line-balancing methods. This occurs mainly because all operators are allowed to work to their full potential (with all their natural variances), and the wasteful process of repeatedly setting the unit down between operators (only to pick it up later) is eliminated. The hand offs between operators with Self-Balancing promotes teamwork and communication, as well as breaking up the dehumanizing and repetitive work normally associated with assembly lines.

Finally -- but there are many more -- you should implement Self-Balancing because it works. Whether it is an assembly line, service operation, or moving anything one piece at a time between people... it works, Traditional line balancing has many flaws, and is not designed to create continuous flow; never has, never will. Self-Balancing was developed to create flow. It has a bias for flow. Anything short of that is not Self-Balancing, and seeing true continuous flow for the first time is a beautiful (and nearly perfect) thing. It's what you have been waiting for.

What do you think of Gordon's remarks? I'd be interested in hearing from anyone who has used the Self-Balancing process and whether it has produced greater results than other line-balancing methods. How has it affected inventory and variation?

What is 3P and Why Should I Use It?

I recently spoke with Allan Coletta, who is the author of a new book titled The Lean 3P Advantage: A Practitioner's Guide to the Production Preparation Process, and asked him directly: "What is 3P and why should it be used when developing new products?" Here is Allan's full response:

Lean 3P (Production Preparation Process) is an event-driven process for developing a new product concurrently with the operation that will produce it. 3P is a game-changer that results in better products that require less initial capital investment and lower ongoing costs.

Previously, Lean had been largely relegated to fixing existing problems in our manufacturing plants. 3P takes Lean principles upstream into the new product development arena, and applies them liberally at the point in the process where they can have the most influence on both product and operation. Enormous advantages are created by deeply understanding customer needs and developing alternative designs that will create breakthrough benefits. Time is no longer spent trying to fix “baked-in” problems.

New products and new operations require many functional groups working together, but traditional development is typically a series of successive sub-optimizations and hand-offs. Time pressure and a passion to quickly reach a design decision squashes innovation.

Lean 3P brings stakeholders together and sequentially takes them through a process where products are developed alongside of the manufacturing operations. Design engineers interact with process engineers, marketing, and research & development team members; each declaring their preferences and capabilities and developing alternative options against agreed criteria. Manufacturing and maintenance teams weigh in with preferences for operability and maintainability, standardization, ergonomics and flow.

The Lean 3P advantage is about rapid learning, collaboration, and innovation, and it works with new or established products and on any sized project. Companies in virtually every industry are applying Lean 3P to drive competitive advantage.  

Why do you think of Allan's thoughts on 3P? Have any of you applied 3P when developing new products? What were the results?

GE Goes Lean In Louisville

This very interesting article about GE Appliances' new hybrid water heater manufacturing facility in Louisville, Kentucky was just posted on the BuildingOnline site yesterday. Other than the potential to create 1,300 jobs in the USA by 2014, this facility has the distinction of producing the first GE Appliances' product -- the GeoSpring™ Hybrid Water Heater -- "designed and built using Lean manufacturing principles."

Although the piece mainly focuses on the benefits of the new product, it does point out that the that Lean initiative there"uses a cross-functional team of employees - including hourly manufacturing workers - to design the product and the manufacturing process." I'd actually be quite interested to hear more about the leadership and strategy that exists within the facility because these are the areas that sustain the initiative for the long term. It's up to the leadership now -- right at the beginning -- to build and hone the continuous-improvement culture throughout all areas of the facility. The application of some waste-reducing tools will generate some initial improvements and foster teamwork, of course, but it's the example set from "top down" that reduces that risk of the initiative stalling after a short period.

What do you think of GE Appliances' plans for this new facility? What do you think will be the key factors to a successful Lean system at this new manufacturing plant?

Here's a GE-produced video that focuses on the collaboration and teamwork at this facility:

The Denver Health & Hospital Authority -- The Results Are In

Over on the Hospitals and Health Networks site, I read this great article about the Denver Health organization's incredible benefits resulting from its six-year Lean journey. Patricia A. Gabow, CEO of the Denver Health and Hospital Authority, believes the $135 million financial benefit since 2006 is a result of the adoption of Lean management techniques. In addition, in 2011, the hospital evidently saw "$46 million in financial benefits from Lean projects."

Other than the amazing benefits discussed in the article, I found this detail quite interesting: "There are 16 value streams and an organized method for picking improvement projects. Some are short term, others extend over multiple years, such as revenue cycle, the OR and community health. Each value stream has an executive sponsor and a steering committee that meets monthly. Gabow reviews metrics for all of the value streams and rapid-improvement events every month."

What do readers working in the healthcare industry think of this format for value stream maps? Are your maps used in the same fashion?

After winning the coveted Shingo Prize for Operational Excellence (the first healthcare organization to achieve this feat) , Denver Health now offers its own Lean Academy. Check out the video presented at the Shingo Award ceremony:

Lean and Agile Software Development: How Do We Make It Happen?

Recently, I had the chance to speak in person with Michael Levine, author of a new book published this past December titled A Tale of Two Transformations: Bringing Lean and Agile Software Development to Life. His book provides entertaining and thought-provoking guidance on making organizational change.

I asked Michael about one of the paradoxes of bringing Agile software development into organizations -- Although Agile preaches the centrality of the self-managed team, in practice many Agile migrations are imposed top-down by strong-willed executives. Can this really work? Here is his response:

Organizations vary dramatically from each other, and these variations must drive the approach to introducing Lean and Agile techniques effectively. An organization that is performing adequately and for which the risk of disruption is high must be addressed differently than an organization that is performing unacceptably and for which change is urgent.

That is why I draw out two approaches to change: Drive People, a top-down approach focused on processes and tools, and People Driven, an enabling approach focused on people, learning, and organizational design.

Ultimately agile success depends on becoming People Driven – aligning the skills and perspectives of the team members to the work at hand, with broad understanding and embrace of Lean and Agile principles. Some organizations can begin their Lean/Agile journey with a low-risk, gradual People Driven approach from the start; others do not have the capability or the time and need the kick-start of a Drive People approach. Both can work, so long as the end-game is a self-sustaining, continually improving People Driven culture.

What do you think of Michael's points? Do any readers who work in software development have any opinions or experiences to share in regard to Agile software development in a Lean organization?

The Visual Author

Happy New Year! I hope everyone had a healthy and happy holiday season.

CRC Press, the parent company of Productivity Press, recently established a YouTube channel that will feature many Productivity Press authors discussing performance-improvement topics as well as methodologies explored in their respective books. I've decided to feature a sample of some recent videos in this blog post.

Patrice Boutier speaks about his forthcoming book The Seven Kata: Toyota Kata, TWI, and Lean Training here:


Robert Hafey discusses Lean Safety: Transforming your Safety Culture with Lean Management here:



Larry Fast discusses The 12 Principles of Manufacturing Excellence: A Leader's Guide to Achieving and Sustaining Excellence here:
"


Daniel Markovitz discusses A Factory of One: Applying Lean Principles to Banish Waste and Improve Your Personal Performance here:



Please let me know your thoughts on these videos as we plan to shoot more and suggestions are always welcome.

"Lean Versus MRP" or "Lean and MRP"?

I attend many Lean conferences throughout the year that focus on different areas of the supply chain. Presenters there often state how the concept of material requirements planning (MRP) is outdated and works as a detriment to Lean thinking. In addition, there have been many articles published that discuss the "Lean versus MRP" debate. I recently had an email conversation with Derek Singleton about this very topic. Derek is an enterprise resource planning (ERP) market analyst and writes for the Software Advice website. He has some interesting ideas about the use of software during the planning process, and I'd like to share his thoughts here:

Three Ways Manufacturing Software Can Adjust to Lean Principles

There’s a long-standing debate between manufacturing planning strategies. The debate is between proponents of material requirements planning software -- better known as MRP software -- and lean manufacturing advocates.

The crux of the dispute boils down to whether sophisticated software tools are needed to adequately plan production. Proponents of MRP software believe that today’s complex manufacturing challenges require formal planning tools to get an accurate picture of the production requirements. Lean advocates, on the other hand, argue that these planning tools actually get in the way of accurate planning because they’re too slow and transaction-intensive to pace to actual consumption, or adjust to demand fluctuations.

Three Components to Incorporate in Manufacturing Software

I see three main ways that manufacturing software can evolve to adapt to the demands of lean manufacturing. Each way focuses on bringing lean principles front and center of manufacturing software packages.

1. Make Value Stream Mapping a Core Software Component - One of the most important tools in lean manufacturing is create a value stream map to outline the flow of information and materials in the manufacturing plant. Modeling how information and materials flow through a shop floor will allow manufacturers to more easily identify production bottlenecks.

2. Monitor Cycle Times Intensely - The most important metric to know in manufacturing is how long it takes for materials to arrive on the dock and to leave in a completed product. In order to improve cycle times, these times need to be monitored and tracked. A subset of monitoring and tracking cycle times is keeping track of production status.

3. Locate Key Places to Add or Remove Inventory - While there’s ample functionality in manufacturing software for determining what to stock and how much to stock, there is little functionality to help manufacturers figure out where to stock. Functionality that can tell a manufacturer where to stock will help them figure identify the best places to protect against volatility, which will ultimately help avoid product shortages.

These are a few ways that I can see manufacturing software changing to adapt to the requirements of lean manufacturing. However, I’d like to hear your thoughts. What needs to change in manufacturing software to adapt it to lean manufacturing principles?

What do you think of Derek's ideas? What are your views on the role of MRP within a Lean initiative?

What are We Learning from Our Projects?

Recently, I had the chance to speak in person with Dr. Willis Thomas, author of a new book published in November 2011 titled The Basics of Project Evaluation and Lessons Learned. His book provides the framework to conduct lessons learned using the Project Management Body of Knowledge (PMBOK) as a standard.

When I asked Willis why he chose the PMBOK approach for lessons learned he replied:

Project managers trust and are comfortable with the PMBOK for five Process Groups (Initiation, Planning, Executing, Monitoring/Controlling and Closing) and nine Knowledge Areas (Communications, Cost, Human Resources, Integration, Procurement, Quality, Risk, Scope and Time). Many project managers run projects using these categories.

The approach I take is very simple; to overlay what has been done right, done wrong and could have been done differently using these 14 process group and knowledge area categories. This matrix, creates a 5x9 table of 45 categories, with three variables per category (right, wrong, differently), which results in potentially 135 elements for review.

This compartmentalizes the collection process for lessons learned so that it is situation-specific. The project team can then determine what lessons to review -- that is, what went right during project initiation regarding communications. Of course, each factor should allow for comments to detail characteristics of the lesson.

A primary goal for lessons learned should not only be to avoid making the same mistakes in projects (summative reflection), but to strategize for improvement (formative thinking). This approach can help project managers to be consistent in their approach to evaluating projects.

What do you think of Willis' advice? Have any of you used this process?