Category: Lean Metrics

Getting the Bugs Out

We updated the link to “Chasing the Rabbit:  How Market Leaders Outsdistance the Competition and How Great Companies Can Catch Up and Win” authored by Steven J. Spear.  If you haven’t had a chance to add this book to your library, now is the time to get your copy.

Remember to visit our Lean Books page for other great selections too.  Readers are leaders and leaders are readers!

We’ve been extremely busy working on some exciting new projects.  We’ll be sharing our thoughts on these soon.

Until Next Time – STAY lean!


Lean, OEE, and How to beat the “Law of Diminishing Returns”

Are your lean initiatives falling prey to the Law of Diminishing Returns?  Waning returns may soon be followed by apathy as the “new” initiative gets old.  For those who have not studied economics or are not familiar with the term, it is defined by Wikepedia as follows:

The law states “that we will get less and less extra output when we add additional doses of an input while holding other inputs fixed. In other words, the marginal product of each unit of input will decline as the amount of that input increases holding all other inputs constant.

In simple terms, continued application of time and effort to improve a process will eventually yield reduced or smaller returns.  The low hanging fruit that once was easy to see and resolve has all but disappeared.  Some companies would claim that they have finally “arrived”.  We contend that these same companies have simply hit their first plateau.

Methods and Objectives

Is it inevitable that a process has been refined to the point where additional investment can no longer be justified financially?  The short answer is “Yes and No”.  As the Olympics are well under way, we are quick to observe the fractions of seconds that may be shaved from current world records.  If you’re going for Olympic Gold, you will need every advancement or enhancement that technology has to offer to gain the competitive edge.  These advances in technology are refinements for existing processes that are governed by strict rules.  Clearly, there are much faster ways to get from point A to point B.  However, the objective of the Olympics is to demonstrate how these feats can be accomplished through the physical skills and abilities of the athletes.

In business our objectives are defined differently.  We want to provide (and our customers expect) the highest quality products at the lowest cost delivered in the shortest amount of time.  How we do that is up to us.  Lean initiatives and tools such as overall equipment effectiveness (OEE) can help us to refine current processes but are they enough to stimulate the development of new products and processes?  Or, are they limited to simply help us to recognize when optimum levels have been achieved?

Radical change versus refinement

Objectives are used to determine and align the methods that are used to achieve a successful outcome.  This is certainly the case in the automotive industry as environmental concerns and availability of non-renewable resources, specifically oil and gas, continue to gain global attention and focus.  The objectives of our “transportation” systems are being redefined almost dynamically as new technologies are beginning to emerge.  At some point, the automotive industry leaders must have realized that continuing to refine existing technologies simply will not satisfy future expectations.  With this realization it is now inevitable that a radical powertrain technology change is required.  Hybrid vehicles continue to evolve and electric cars are not too far behind.

How to Beat the Law of Diminishing Returns

Overcoming the law of diminishing returns requires another look at the vision, goals, and objectives of the company and to develop a new, different, or fresh perspective on what it is you are trying to achieve.  The lean initiatives introduced by Toyota, Walmart, Southwest and many others were driven by the need to find a competitive edge.  They recognized that they couldn’t simply be a “me too” company to gain the recognition and successes they now enjoy.

The question you may want to ask yourself and your team is, “If we started from scratch today, is this the result we would be looking for?”  The answer should be a unanimous and resounding “NO”.  Get out your whiteboard, pens, paper, and start writing down what you would be doing differently.  In other words, it’s time to re-energize the team and refocus your goals and objectives.  Vision and mission statements are not tombstones for the living.  5S these documents and take the time to re-invigorate your team.

Turning a company around may require some new radical changes and we need to be mindful of the new upstarts with the latest and greatest technology.  They may have an edge that we have may just haven’t taken the time to consider.  We are not suggesting that you need to replace all the equipment in your plant in order to compete.  Proven technologies have their place in industry and the competitive pricing isn’t always about speed.  The question you may need to consider is, “Can our technology be used to produce different products that have been traditionally manufactured using other methods?”

While many companies pursue a growth strategy based on their current product offerings and derivatives, we would strongly suggest that manufacturers consider a growth strategy based on their process technology offerings.  What else can we make with process or machine XYZ?  We anticipate that manufacturing sectors will soon start to blend as manufacturers pursue products beyond the scope of their current industry applications.

Be the Leader

Leading companies create and define the environment where their products and services will thrive.  Apple’s “iProducts” have redefined how electronics are used in everyday life.  As these tools are developed and evolve, so too can the systems and processes used throughout manufacturing.  The collective human mind is forever considering the possibilities of the next generation of products or services.

There was a time when manned space flight and walking on the moon were considered unlikely probabilities.  Today we find ourselves discovering and considering galaxies beyond our own and we don’t give it a second thought.  How far can we go and how do we get there?  The answer to that question is …

Until Next Time – STAY lean!

22 Seconds to Burn – Excel VBA Teaches Lean Execution

Cover of "Excel 2003 Power Programming wi...
Cover via Amazon


VBA for Excel has once again provided the opportunity to demonstrate some basic lean tenets.  The methods used to produce the required product or solution can yield significant savings in time and ultimately money.  The current practice is not necessarily the best practice in your industry.  In manufacturing, trivial or minute differences in methods deployed become more apparent during mass production or as volume and demand increases.  The same is true for software solutions and both are subject to continual improvement and the relentless pursuit to eliminate waste.

Using Excel to demonstrate certain aspects of Lean is ideal.  Numbers are the raw materials and formulas represent the processes or methods to produce the final solution (or product).  Secondly, most businesses are using Excel to manage many of their daily tasks.  Any extended learning can only help users to better understand the Excel environment.

The Model:

We recently created a perpetual Holiday calendar for one of our applications and needed an algorithm or procedure to calculate the date for Easter Sunday and Good Friday.  We adopted an algorithm found on Wikipedia at that produces the correct date for Easter Sunday.

In our search for the Easter Algorithm, we found another algorithm that uses a different method of calculation and provides the correct results too.  Pleased to have two working solutions, we initially did not spend too much time thinking about the differences between them.  If both routines produce the same results then we should choose the one with the faster execution time.  We performed a simple time study to determine the most efficient formula.  For a single calculation, or iteration, the time differences are virtually negligible; however, when subjected to 5,000,000 iterations the time differences were significant.

This number of cycles may seem grossly overstated, however, when we consider how many automobiles and components are produced each year then 5,000,000 approaches only a fraction of the total volume.  Taken further, Excel performs thousands of calculations a day and perhaps even as many more times this rate as numbers or data are entered on a spreadsheet.  When we consider the number “calculations” performed at any given moment, the number quickly grows beyond comprehension.


As a relatively new student to John Walkenbach’s book, “Excel 2003 Power Programming with VBA“, speed of execution, efficiency, and “Declaring your Variables” have entered into our world of Lean.  We originally created two (2) routines called EasterDay and EasterDate.  We then created a simple procedure to run each function through 5,000,000 cycles.  Again, this may sound like a lot of iterations but computers work at remarkable speeds and we wanted enough resolution to discern any time differences between the routines.

The difference in the time required to execute 5,000,000 cycles by each of the routines was surprising.  We recorded the test times (measured in seconds) for three separate studies as follows:

  • Original EasterDay:  31.34,  32.69,  30.94
  • Original EasterDate:  22.17,  22.28,  22.25

The differences between the two methods ranged from 9.17 seconds to 8.69 seconds.  Expressed in different terms, the duration of the EasterDay routine is 1.39 to 1.46 times longer than EasterDate.  Clearly the original EasterDate function has the better execution speed.  What we perceive as virtually identical systems or processes at low volumes can yield significant differences that are often only revealed or discovered by increased volume or the passage of time.

In the Canadian automotive industry there are at least 5 major OEM manufacturers (Toyota, Honda, Ford, GM, and Chrysler), each producing millions of vehicles a year.  All appear to produce similar products and perform similar tasks; however, the performance ratios for each of these companies are starkly different.  We recognize Toyota as the high velocity, lean, front running company.  We contend that Toyota’s success is partly driven by the inherent attention to detail of processes and product lines at all levels of the company.


We decided to revisit the Easter Day calculations or procedures to see what could be done to improve the execution speed.  We created a new procedure called “EasterSunday” using the original EasterDay procedure as our base line.  Note that the original Wikipedia code was only slightly modified to work in VBA for Excel.  To adapt the original Wikipedia procedure to Excel, we replaced the FLOOR function with the INT function in VBA.  Otherwise, the procedure is presented without further revision.

To create the final EasterSunday procedure, we made two revisions to the original code without changing the algorithm structure or the essence of the formulas themselves.  The changes resulted in significant performance improvements as summarized as follows:

  1. For integer division, we replaced the INT (n / d) statements with a less commonly used (or known) “\” integer division operator.  In other words, we used “n \ d” in place of “INT( n / d)” wherever an integer result is required.  This change alone resulted in a gain of 11 seconds.  One word of caution if you plan to use the “\” division operator:  The “n” and “d”  are converted to integers before doing the division.
  2. We declared each of the variables used in the subsequent formulas and gained yet another remarkable 11 seconds.  Although John Walkenbach and certainly many other authors stress declaring variables, it is surprising to see very few published VBA procedures that actually put this to practice.


The results of our Time Tests appear in the table below.  Note that we ran several timed iterations for each change knowing that some variations in process time can occur.

EasterDay = 31.34375 Original Code uses INT( n / d ) to convert Division Results
EasterSunday = 20.828125 1.  Replaced INT ( n / d) with (n \ d)
EasterDate = 22.28125 Original Code – Alternate Calculation Method
Re-Test to Confirm Timing
EasterDay = 30.9375 Original Code uses INT( n / d ) to convert Division Results
EasterSunday = 20.921875 1.  Replaced INT ( n / d) with (n \ d)
EasterDate = 22.25 Original Code – Alternate Calculation Method
Re-Test to Confirm Timing
EasterDay = 30.90625 Original Code uses INT( n / d ) to convert Division Results
EasterSunday = 21.265625 1.  Replaced INT ( n / d) with (n \ d)
EasterDate = 22.25 Original Code – Alternate Calculation Method
Re-Test to Confirm Timing
EasterDay = 31.078125 Original Code uses INT( n / d ) to convert Division Results
EasterSunday = 9.171875 2.  Variables DECLARED!
EasterDate = 22.1875 Original Code – Alternate Calculation Method
Re-Test to Confirm Timing
EasterDay = 31.109375 Original Code uses INT( n / d ) to convert Division Results
EasterSunday = 9.171875 2.  Variables DECLARED!
EasterDate = 22.171875 Original Code – Alternate Calculation Method

The EasterSunday procedure contains the changes described above.  We achieved a total savings of approximately 22 seconds.  The integer division methods used both yield the same result, however, one is clearly faster than the other.

The gains made by declaring variables were just as significant.  In VBA, undeclared variables default to a “variant” type.  Although variant types are more flexible by definition, performance diminishes significantly. We saved at least an additional 11 seconds simply by declaring variables.  Variable declarations are to VBA as policies are to your company, they define the “size and scope” of the working environment.  Undefined policies or vague specifications create ambiguity and generate waste.

Lessons Learned:

In manufacturing, a 70% improvement is significant; worthy of awards, accolades, and public recognition.  The lessons learned from this example are eight-fold:

  1. For manufacturing, do not assume the current working process is the “best practice”.  There is always room for improvement.  Make time to understand and learn from your existing processes.  Look for solutions outside of your current business or industry.
  2. Benchmarking a current practice against another existing practice is just the incentive required to make changes.  Why is one method better than another?  What can we do to improve?
  3. Policy statements can influence the work environment and execution of procedures or methods.  Ambiguity and lack of clarity create waste by expending resources that are not required.
  4. Improvements to an existing process are possible with results that out perform the nearest known competitor.  We anticipated at least being able to have the two routines run at the similar speeds.  We did not anticipate the final EasterSunday routine to run more than 50% faster than our simulated competitive benchmark (EasterDate).
  5. The greatest opportunities are found where you least expect them.  Learning to see problems is one of the greatest challenges that most companies face.  The example presented in this simple analogy completely shatters the expression, “If it ain’t broke, don’t fix it.”
  6. Current practices are not necessarily best practices and best practices can always be improved.  Focusing on the weaknesses of your current systems or processes can result in a significant competitive edge.
  7. Accelerated modeling can highlight opportunities for improvement that would otherwise not be revealed until full high volume production occurs.  Many companies are already using process simulation software to emulate accelerated production to identify opportunities for improvement.
  8. The most important lesson of all is this:

Speed of Execution is Important >> Thoughtful Speed of Execution is CRITICAL.

We wish you all the best of this holiday season!

Until Next Time – STAY Lean!

Vergence Analytics

At the onset of the Holiday project, the task seemed relatively simple until we discovered that the rules for Easter Sunday did not follow the simple rules that applied to other holidays throughout the year.  As a result we learned more about history, astronomy, and the tracking of time than we ever would have thought possible.

We also learned that Excel’s spreadsheet MOD formula is subject to precision errors and the VBA version of MOD can yield a different result than the spreadsheet version.

We also rediscovered Excel’s Leap Year bug (29-Feb-1900).   1900 was not a leap year.  The leap year bug resides in the spreadsheet version of the date functions.  The VBA date function recognizes that 29-Feb-1900 is not a valid date.

Seasons Greetings

This year has been filled with many new experiences, hard times, great times, and many opportunities for learning.  While some may prefer to see this year pass sooner than later, 2009 is hopefully a year that presented many new opportunities and even greater challenges.

As lean practitioners, we learn to appreciate failure from a different perspective than most people would enjoy.  The focus is not the failure itself, but rather the causes and events that lead up to the failure that are significant.  To those who reflect on this past year and consider the many successes, we also suggest basking in some of the learning from the failures.  Learning what not to do is often the hardest and most costly lesson of all.

Of course, understanding our successes is of equal importance.  The objective is success by design.  Understanding the reasons for our success serves to confirm the effectiveness of current practices.

We are presently working on new discussion topics for the new year.  Overall Equipment Effectiveness has been one of the core topics over the past year and more recently our focus has shifted to problem seeing and solving.  We are evolving into a culture where AGILITY is quickly becoming one of the defining traits of today’s successful companies and new businesses.

Intelligent metrics demand effective and efficient measurement and analysis to be used in real-time.  By our definition, an Agile company is one that already understands and demonstrates lean practices.  A truly agile company is now looking at metrics to dynamically lead and manage the business, responding to events and developing strategy in real-time.  Their agility is demonstrated by the speed of execution and their continued list of successes as a result.

We have been developing some new spreadsheet templates that we plan to release in the new year.  The free downloads page and sidebar widget have proven to be a great success.  To achieve greater functionality, we will be using VBA (Visual Basic for Applications) in some of our future releases.  We have learned that Excel has a few limitations (and the odd bug) that require the use of VBA for our applications to perform as intended.

We are looking forward to 2010 and remain optimistic as the economy begins its slow recovery.  We will likely have a few more posts before the year ends, but knowing that some will soon be traveling or breaking early from work, we would like to wish all of our visitors best wishes for the holiday season.  We look forward to an exciting new year in 2010.

Until Next Time – STAY Lean!

Communication Breakdown – The Language of Lean

Getting people engaged and “on the same page” requires everyone to understand the language used to convey the message.  Even the method of disseminating information can create confusion.  Oral presentations can convey a completely different message than one delivered in writing.

The tone used in an oral presentation cannot be delivered in writing using the same words.  Voice inflections, body language, and atmosphere all add to the message.  How many times have you heard the expression, “When s/he spoke those words, you could almost hear a pin drop”.  It is obviously not just the spoken words but how they are delivered that create an aura of suspense or awe.

How does this apply to lean?  The answer is quite simple.  Don’t assume that people understand – just because you told them either verbally or in writing.  Lean is “hands-on” management.  Go to the process and see what is actually happening (or not happening).

If a picture is worth a thousand words, how many words would it take to describe the experience of seeing the real process first hand?  “Don’t just tell me – show me” are words that should be uttered most often by leadership, managers, or any lean practitioner.

The first step to implementing lean is going out to SEE what opportunities exist.  Unlike computer programs that have explicit meanings, people are intelligent and capable of interpreting the real message behind the words.  Computers do not have an intuitive sense.

The Language of Lean can be summed up in two words – QUICK ACTION.  Successful lean organizations understand that ACTION is truly LOUDER than WORDS.  See it, Solve it, Share it executed in real-time.

Until Next Time – Stay LEAN!

Software Modeling for Standardized Work

The concept of Standard Work is understood in virtually any work environment and is not exclusive to the lean enterprise.  Typically the greater challenge of standardized work is actually preparing an effective document that adequately describes the “work” to be performed.

The objective of standardized work is to provide a documented “method” for completing a sequence of tasks that can be executed to consistently yield a quality product at rate, regardless of the person who is performing the work.  The documentation typically created usually falls short of this expectation.

The Ideal Model for Standardized Work

We would expect to find examples of well documented standardized work at Nuclear Stations, Military Installations, in Aerospace, and many other places where risks are high and operation sequences are critical.  High velocity, lean organizations recognize that a disciplined process approach is the key to discovering opportunities for improvement and to support future “problem” solving activities if required.

Computer programs are perfect models of standardized work in action.  They perform the same tasks day after day, collecting, storing, and processing data.  We have certain performance expectations although we seldom understand the inner workings of the programs themselves.

This is certainly true for the computers we deal with in our personal lives such as mobile phones, instant banking machines, GPS mapping systems, or the many “gaming” programs that people play.  Our interactions with the “program” are limited to the HMI or Human-Machine-Interface and represents only a tiny fraction of the thousands of lines of computer code that are executing the transaction requests in the background.

The Software Development Model

Although few of us may ever write a program, we do understand that every instruction or line of code in a program is critical to the successful execution of the program as a whole.  Every line of code represents a specific instruction, process sequence, or step that must be executed by the computer.  Similarly, standardized work identifies the specific steps that must be followed to successfully complete the task.

Any time a computer system “goes down” or critical error occurs, someone in the IT department is looking for the source of the problem.  The software is typically written to at least provide a hint as to where the problem may be.  In some cases the solution may be as drastic as rebooting the system or as simple as reloading the specific application.

We should be able to perform a similar analysis when a process fails to perform to expectations or when we are confronted with quality issues or other process disruptions or failures.  The ability to consistently repeat a sequence of steps is directly correlated to the quality and level of detail described in the standardized work document.

Aside:  An example from the Quality department:

Gage Repeatability and Reproducibility studies, also know as Gage R&R studies, are often used to validate the effectiveness of a measurement system or method (fixture or equipment) for a specific application.  If the Gage R&R result is less than 10%, the gauge or fixture is deemed to be acceptable; greater than 30% renders the measurement system unusable for the application.    The results can be evaluated statistically to determine or differentiate whether the “problem” is repeatability (equipment variability) or reproducibility (operator variability).

When the measurement system fails to meet the requirements of the application, a significant amount of time and effort is expended to achieve an acceptable result.  The gauging strategy is reviewed, including part / fixture net locations, quantity of net pads and / or pins, net pad and / or pin sizes, clamping sequences, and clamping pressures; all efforts to improve the measurement system.  Instructions are revised and operators are retrained accordingly.

In contrast, we seldom see the same level of time and effort expended to develop, analyze, test and document standardized work at the machine or station where the work is actually being performed.  Although the process may be improved to yield a quality product, the method or work instruction to achieve a consistent result is not adequately described or defined.

Understanding the tasks to be performed and the time required to perform them is essential to determine effective process cycle times (rates) and also to understand where changes to the process may yield improved performance.  This is of particular importance for companies using OEE as a key process metric.

Note:  an indicator that standardized work methods should be reviewed occurs when excuses for poor performance are attributed to a “new operator” or “steep learning curve”.

Extending the Program Model Concept

We can all appreciate the “built-in” or inherent discipline of computers executing thousands of lines of code in the same sequence every time the program runs.  To add complexity to our model, consider the discipline and learning that is necessary to write the code itself.  The software development team must understand the purpose of the program, how it will be used, design and create a user interface, determine programming algorithms to achieve the desired results and functionality, and ultimately they must write the code that will perform these functions.

Anyone who has attempted to write a program, or knows someone who has, will also be familiar with the term “DEBUG”.  There may be at least as many hours spent testing and debugging code as there are when writing it.  Even after hundreds of hours of testing, some “Bugs” still make it into the real world.  Microsoft’s bug laden operating system releases have been the target of Apple Computer advertising campaigns for this very reason.

Some code may function without error when executed in isolation and some bugs may not be discovered until the module is interacting with the program as a whole.  In this regard, it is also important to consider the potential of interactions with other processes when developing standardized work.  Upstream and downstream operations may have a direct impact on the work being performed. 

The software development team must select the programming language that will be used to develop the final code and the individual programmers must also follow and understand the syntax and language protocols.  Although the product of the software development team is the “executable” program that the computer will run, we can be assured that the process for arriving at this final product is also quite rigorous.

Although we never get to see the native or original code, the modules are likely highly optimized, commented thoroughly, and well documented.  These comments are technically “non-value added” steps in the program, however, they usually describe the scope and purpose of the procedure or clarify any code intentions or algorithms.  These comments are valuable when debugging may be required or when the code is subject to future reviews.

The discipline of software development is not too far from the level of discipline that should be in place to develop standardized work.  The quality of standardized work processes would improve dramatically if each sequence was given the same level of scrutiny as a single line of code.

Making Improvements with Standardized Work

You may be wondering how flexibility exists in an environment of extreme discipline and rigid rules.  It is actually the rigidity and discipline that supports or encourages flexibility.  The discipline is in place to encourage managed change events without compromising current process knowledge or levels of understanding.  A well-defined process is much easier to understand and therefore is also easier to analyze for improvement opportunities.  The level of understanding should be such that a quantifiable margin or level of improvement can be predicted.

With reference to our software model, you will appreciate that the efficiency or speed of the program is dependent on the methods or algorithms that programmer used to develop the solution.  How many times have you stared at your computer wondering “what’s taking so long?”  The timing for a simple data sort can vary depending on the method or sorting algorithm chosen by the programmer.

The very language elements or functions that the programmer uses will have a profound effect on program execution time.  Many programmers have developed and use high precision “timing” functions to help optimize their code for efficiency and speed of execution.  Machine language level programmers are likely to know how many clock cycles each instruction requires.

Understanding the “process instructions” at this level creates very specific challenges with predictable outcomes and degree of certainty when changes are considered.  Changing an algorithm is quite different from simply changing a line of code within a specific function.  However, the scope, purpose, and impact of the change can be clearly defined and assessed in advance.

Last Words:

One of the more significant lean developments in manufacturing was the introduction of Quick Changeover and Single Minute Exchange of Dies (SMED).  The setup time reductions that have been achieved are truly remarkable and continue to improve with advances in technology.

When Quick Changeover and SMED programs were first introduced, most companies did not have a defined setup procedure or process.  The most significant effort was spent developing actual setup instructions:  identifying tasks to be completed, determining the sequence of events, who was responsible, and when they could be performed.

Ultimately external and internal setup activities were defined, setup teams were created, specific tasks and sequences of events were assigned and defined, and setup times were reduced from hours to 10 minutes or less.

Standardized Work is a fundamental element of Lean Manufacturing.  As notes are the language of musicians and make for great songs and sounds, so too is Standardized Work to a Lean organization.

Until Next Time – STAY Lean!

Using TRIZ for Problem Solving – Resources

In our first post on this topic, “Using Triz for Problem Solving – Introduction“, we provided a very basic introduction to TRIZ.  In the spirit of TRIZ, it is not our intent to rewrite or redefine the TRIZ process when excellent information is already available.  Our intent is to identify the few of the many excellent and exceptional resources that we have found.

What is TRIZ?

To learn more about TRIZ and it’s applications we suggest visiting the following web sites that present a tremendous amount of information on the development and application of TRIZ.

TRIZ Principles

40 Inventive Principles with Examples:

Examples for each of the 40 Inventive Principles can be found at the following link:

TRIZ Resources

The Contradiction matrix:

As you will have learned from reading the “What is TRIZ?” page from the link above, one of the tools of TRIZ is the Contradiction Matrix that consists of 40 elements.  The TRIZ Contradiction Matrix is available as an Excel Spreadsheet through the following link:


The Triz Journal presents many informative articles.  One very intriguing article, “TRIZ / Systematic Innovation Enhances Hoshin Kanri“, by Darrell Mann and Ellen Domb, demonstrates the principles of TRIZ in a unique application.

An excellent article, “Create a High Performance Culture with Hoshin Kanri”, by Frank Deno can be found at the following link

WEB Sites:

TRIZ Books:

A number of books are available on the topic of TRIZ.  Click here to preview the selections currently available.

TRIZ Challenges:

TRIZ is not without its challenges.  Although TRIZ has evolved over many years, it still remains relatively unknown and few companies seem to be ready to adopt this problem solving method.

An excellent article, “Enhancing TRIZ with Dr. Deming’s Philosophy“, by Ellen Domb and Bill Bellows, presents some interesting insights to this challenge.

We typically tend to avoid “labels” for the method we are using to solve a specific problem.  Unlike a surgeon “requesting specific tools (scalpel)” while performing an operation, our strategy tends to be a blended “hybrid” approach to problem solving; TRIZ happens to be one of the more effective methods that we have learned to use over the past few years.

The acceptance of TRIZ may be attributed to the current struggles many companies experience simply attempting to complete an 8D or 5-Why.  Of course, that would only be true of companies who are void of the Lean principles and methods – right?  TRIZ also has a perceived complexity that does not lend itself to ready adaptation as a company-wide problem solving tool.

We would recommend reviewing the many available books on the topic of TRIZ.  Integrating a tool such as TRIZ will require someone to become the leading expert.  Click here to see the various book selections that are available.

Unfortunately, for many companies, the discipline or the structure is simply not there to support effective problem solving efforts.  Perhaps if more time was spent solving the real problems, they would have more time to solve problems not yet realized.

Remember to get your TRIZ – Click Here!

Until Next Time – STAY Lean!

Using TRIZ for Problem Solving – Introduction

Using TRIZ for Problem Solving – Introduction

A famous quote from Albert Einstein, “The problems that exist in the world today cannot be solved by the level of thinking that created them.“, applies to the discussion of problem solving and more so to the topic of TRIZ, The Theory of Inventive Problem Solving, developed by Genrich S. Altshuller.

TRIZ – Theory of Inventive Problem Solving

Genrich S. Altshuller developed TRIZ based on his search for a standard method to solve problems.  At the very basic level, once a problem is identified the objective is to determine whether a similar problem has already existed elsewhere.  If so, study the solution and determine whether it can be incorporated into the current solution being sought.  Taken one step further, consider the possibility that a different perspective of the problem may also present a unique inventive solution.

It does not seem too far fetched that the problem to be solved has occurred elsewhere in a completely different context.  The solution that is found may also be out of the context but the concept may lead to an innovative solution for the current problem at hand where one never before existed.

The application of TRIZ requires an open mind.  We often bring our “tool box” of experience to the table and draw on those tools and our wealth of knowledge to create a solution.  TRIZ is a tool that can be used to create completely new and unique solutions to a given problem.  This doesn’t mean that we need to abandon our current technology and know-how; it simply means that there may be other options where the current know-how and / or technology may not apply or it may be applied in a manner that is quite different than it is today.

Identify the Real Problem to be Solved

Any problem solving method can only be successful if the true root cause is identified.  Once found, a clear and concise problem statement must be formulated to assure that the solution developed and implemented indeed addresses the true root cause.

Searching for Solutions:

Once a problem has been identified, the next question is, “How do we solve it?”  There are a number of techniques that can be used such as brain storming and idea mapping, however, one seldomly used technique is TRIZ:  Theory of Inventive Problem Solving.

Every day we are challenged with a diverse range of problems from machine malfunctions to defective parts.  The very nature of any company’s operations requires an immediate fix to restore operations to “normal”.  Recognizing that a problem exists is not the same as understanding what the problem is and effectively solving the problem requires that we have identified the true root cause and not just the symptoms.

Many tools are readily available to even help us address these concerns or identify where opportunities exist to make improvements.  Unfortunately, these tools seldom provide the solution to the problem.  Too often we are trapped inside the box of current thinking, technologies, standards, methodologies, present knowledge, and even company policy.  Our own levels of thinking and plausible solutions are influenced and limited by our current understanding and knowledge of the problem as well as our own experiences.

The Basis for Using TRIZ to Solve Problems:


In some cases, product or part designs themselves may be constrained as engineers and designers work to generate a design tailored to a specific, known, technology.  Quality Function Deployment is one strategy that provides a platform to explore alternative design and process approaches before committing to a specific technology or process.

It is worth noting that, although product design is critical, processes and technologies used to manufacture the product itself are often overlooked and seldom are the process constraints and their affects ever considered.  There are many examples where numerous hours are wasted attempting to develop tools using traditional technologies to produce parts that conform to the wishes of engineers and designers.

How do we actually go about solving problems where the technology or the design present constraints that prevent success?  This is the basis for TRIZ:  We have clearly identified the problem to be solved, now we need a solution to resolve it.

Problem Classifications

Although problems may have varying degrees of difficulty, the solutions for them can only fall into one of two overly simplified categories:  Known or Unknown.  While this classification may appear simple on the surface, consider the unknown solution.  Is it truly unknown or is it only unknown to you.
  1. Known:  Surrogate process already proven and only requires adaptation for the current situtation.  The “problem solver” has an awareness or experience related to the solution.
  2. Unknown:  Typically, solutions are often limited by the scope of experience of the person or person(s) attempting to solve the problem.
    1. The problem solver is not aware of the solution’s existence (Personal)
    2. The solution is outside the problem solver’s scope of experience, training, or field of expertise, but may exist within the company (Company)
    3. The solution is not known within the company but is known within the industry (Industry)
    4. A solution can be realized although it does not presently exist (Outside Industry).
    5. Requires an inventive solution that goes beyond improving the existing condition and is not known to exist anywhere.
  3. Although a solution may be found or developed internally, it may not necessarily be ideal.  We recommend continual review of trade journals, going to trade shows, and networking not only with industry peers but outside your areas of expertise as well.

We will pursue the TRIZ methodology as both a learning and problem solving method.  Often times the solution to a problem requires a different perspective to achieve an effective resolution.

Applying TRIZ in the real world:

TRIZ can be used to develop solutions in a wide range of applications.  As Contingency Plans are developed, you may determine that a solution is required to address a problem or crisis that company has not yet experienced.  As we have discussed, the information or solution to the pending “crisis” may already exist elsewhere.  Similarly, improvements to Overall Equipment Efficiency may require solutions to be developed to address problems or opportunities that are inhibiting continued improvement. 

We will continue to pursue the application of TRIZ in the real world and present a more detailed case study.  

Note:  We would also recommend and encourage you to visit for an indepth presentation and detailed discussion of TRIZ.  This site provides greater detail and background that is presently beyond the application or scope of this series.

Until Next Time – STAY Lean!



Lean is Eco-Friendly – Coke Shows How

Today’s front page of the Toronto Star (Monday 22-Nov-09) featured an article on Coke’s new Eco-Bottle. The revolutionary plastic made from sugar cane byproducts is not biodegradable but can be 100% recycled.

Are companies beginning to understand how their product or service may be impacting the environment?  Coca Cola has taken corporate leadership to the next level.  For Coca Cola, understanding how the “complete” product affects the environment has driven tangible change to make a difference.

While Coke’s new eco-bottle is welcomed news, environmentally friendly or Eco-Friendly products are only one aspect to consider in terms of impact to the environment.  Other considerations include how and where the product is manufactured and end-of-life disposal.  At least Coke has addressed the end-of-life disposal aspect.

An extension to the manufacturing process is supply chain management from origination to the final consumer.  The transportation required to supply raw materials, produce, package, and distribute the final product  is as much a concern to the environment.

There is as much activity, if not more, in waste management and recycling than in the manufacturing and distribution processes.  Every stage or phase of a product’s life cycle generates waste in various forms.

Waste management companies are subject to the same environmental impacts through their own supply chain and distribution management, the recycling and disposal processes, and packaging of the product whether or recycled or deemed true end item waste.

Coke at least has demonstrated how large companies can take responsibility for the products they sell.  As consumers, we still have to do our part by making sure the bottle makes it to the recycling bin.

When you are the leading softdrink company in the world it follows that if you can’t improve your product then improve the packaging. We’re sure this will be part of a new marketing campaign to promote Coke as an eco-friendly company – and so it should.

From a Lean Manufacturing perspective, Coke has clearly demonstrated that Lean extends to every facet of the business – inside, outside, and beyond.  This is improving relentlessly.

Until Next Time – STAY Lean!

We are not affiliated with Coca Cola, Coke, or it’s products and services.