22 Seconds to Burn – Excel VBA Teaches Lean Execution

Background:

Excel VBA has once again provided the opportunity to demonstrate some basic lean tenets.  The methods used to produce the required product or solution can yield signficant 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 used 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 http://en.wikipedia.org/wiki/Computus that produces the correct date for Easter Sunday.

In our search for the Easter Algorithm, we also found another algorithm that uses a different method of calculation and also provides the correct results.  We were pleased to have two working solutions and initially did not spend too much time thinking about the differences between the two methods.  If both routines produce the same results then we should choose the one with the faster execution time.  We decided to perform 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 how many “calculations” are performed at any given moment, the number quickly grows beyond comprehension.

Testing:

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.  The test times (measured in seconds), were recorded 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 to be 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 are perceived to be producing similar products and performing 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.

Improvements

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 as presented was used 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. Where integer division is required, 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)” where integer results are 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.

Results:

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 they are more flexible by definition, the result may be significantly diminished performance.  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 that may be outside of your current business or industry.
2. Benchmarking a current practice against another existing practice may be 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 where procedures or methods are executed.  Ambiguity and lack of clarity create waste as additional resources are expended that may not be required.
4. Improvements can be made to an existing process 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 may be 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!

Notable EXCEL anomalies, nuances, subtleties:

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!

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!

Lean Execution: Competing with Giants – It’s all about Speed

Sometimes you need a break from reading and learn from others who are truly walking the talk.  We trust you will find this video, “Competing with Giants – It’s all about Speed“, featuring Dominic Orr, CEO of Aruba Networks, as interesting and thought provoking as we did.

This short clip will be done in less time than it takes to make popcorn.

Another clip that expounds on the first – wonderful insights for business and entrepreneurs:

Enjoy!

Until Next Time – STAY Lean!

Agility Through Problem Solving: a Model for Training and Thinking

We tend to use analogies when we are discussing certain topics, introducing new concepts, or simply presenting an abstract idea.  Analogies are intended to serve as a model that people understand, can relate to or identify with, and, more importantly, remember.  Our challenge is to identify a simple model that can be used to teach people to identify and solve problems – a core competency requirement for lean.

We have learned that teaching people to see problems is just as important as teaching them to solve problems.  Our education system taught us how to use the scientific method to solve problems that were already conveniently packaged in the form of a question or modeled in a case study.  Using case studies for teaching is typically more effective than traditional “information only” or “just the facts” methods.  (The government of Ontario is presently considering a complete overhaul of the education system using case studies as a core instruction method.)

The effectiveness of any training people receive is compromised by time – the retention span.  Our school systems are challenged by this at the start of every school year.  Teachers must re-engage students with materials covered in the last semester or topics covered prior to the break.  In business we may be too eager to provide training at a time when current business activities are not aligned for the new skills to be practiced or exercised.  A commitment to training also requires  a commitment to develop and routinely exercise these skills to stay sharp.

One of the fundamental rules of engagement for lean is to eliminate waste, where value added activities are optimized and non-value added activities are reduced or eliminated.  Although it may appear that we have identified the problem to be solved, in reality we have only framed the objective to be achieved.  We understand that the real solution to achieving this objective is by solving many other smaller problems.

The Sudoku Analogy – A Model for Finding and Solving Problems

A favourite past time is solving Sudoku puzzles, the seemingly simple 9 x 9 matrix of numbers just waiting for someone to enter the solution.  The reasons for selecting and recommending Sudoku as an introductory model for training are as follows:

1. Familiarity:  Sudoku puzzles are published in all daily newspapers and numerous magazines and they have become as popular as cross-word puzzles.  Most people have either attempted to solve a puzzle or know someone who has.
2. Rules of Engagement:  the rules of the game are simple.  Each standard Sudoku puzzle has 9 rows and 9 columns that form a grid of 81 squares.  This grid is further divided into nine 3 x 3 sub-sections.  The challenge is to enter the digits 1 through 9 into the blank spaces on the grid.  Every row, column, and 3 x 3 sub-section of the grid must contain one and only one of each digit.  We refer to these as “rules of engagement” as opposed to “framing the problem”.
3. Degrees of Difficulty:   Sudoku puzzles are typically published in sets of 3 puzzles each having varying degrees or levels of difficulty.  Each level typically requires more time to complete and requires the player to use more complex reasoning or logic skills.  The claim is that all puzzles can be solved.
4. Incremental or Progressive Solutions:  Sudoku solutions are achieved incrementally by solving instances of smaller problems.  In other words, the solution builds as correctly deduced numbers are added to the grid.  New ”problems” are discovered as part of the search for the final solution.
5. Variety:  every Sudoku game is different.  While some of the search and solve techniques may be similar, the problems and challenges presented by each game are uniquely different.  Although the rules of engagement are constant, the player must search for and find the first problem to be solved.
6. Single Solution:  a multiple number of solutions may appear to satisfy the rules of the game, however, only one solution exists.  Learning to solve Sudoku puzzles may be a challenge for some players, however, even seasoned Sudoku players can be stumped by some of the more advanced level puzzles.  To this end, they are ever and always challenging.
7. Skill Level:  Sudoku puzzles do not require any math skills.  Numbers are naturally easier to remember and universal.  Letters are language dependent and the game would lose international appeal.
8. Logical:  deductive reasoning is used to determine potential solutions for each empty square in the grid.  As the game is played, a player may identify a number of potential solutions for a single square.  These final solution will eventually be resolved as the game is played.

In practice

We recommend introducing the team to Sudoku using an example to demonstrate how the game is played.  It is best to discuss some of the strategies that can be used to find solutions that eventually lead to solving the complete puzzle.  The Sudoku model will allow you to demonstrate the following ten objectives:

1. Look for Options:  The solution for the problem to be solved may consist many other smaller problems of varying degrees of difficulty.
2. Break down the problem:  There may be more than one problem that needs to be solved.  Every Sudoku puzzle represents many different problem instances that need to be resolved before arriving at the final solution.  Each incremental solution to a problem instance is used to discover new problems to solve that also become part of the overall solution.  This may also be termed as progressive problem solving.
3. Multiple solutions – One Ideal:  There may be times where more than one solution seems possible.  Continue to solve other problems on the grid that will eventually reveal the ideal single solution.
4. Prioritizing:  more than one problem instance may be solvable at the same time, however, you can only focus on one at a time.
5. Focus:  Problem solving involves varying states of focus:
   • Divergence:  Expand the focus and perform a top-level search for a problem from the many to be solved
   • Convergence:  Narrow the focus on the specific problem instance and determine the specific solution.
6. Test and Validate:  Every problem instance that is solved is immediately verified or validated against the other squares on the grid.  In other words the solution must comply with the rules of engagement.
7. Incubation:  some puzzles can be quite difficult to solve.  Sometimes you need to take a break and return later with a fresh eyes approach.
8. Action:  There is no defined or “correct” starting point.  The first problem instance to be resolved will be as unique as the number of players participating.  No matter where you start, the finished solution will be exactly the same.
9. Tangents:  when entering a solution into a square, you may notice other potential problems or solutions that suddenly seemed to appear.  It is very easy to digress from the original problem / solution.  This is also true in the real world where “side projects” somehow appear to be the main focus.
10. Method:  There is no pre-defined method or approach to determine what problem to solve first.  The only guiding principles for discovering the problem instance to be solved are the rules of engagement.

Lean companies train their teams to see problems and break them down into smaller problems with solvable steps.  Sudoku demonstrates the process of incremental or progressive problem solving.  Even with this technique it is possible to enjoy major break through events.  There are times when even seasoned Sudoku players will recognize the “break through point” when solving a puzzle.

Solve time is another element of the Sudoku puzzle that may be used to add another level of complexity to the problem solving process.  Our objective was not to create a competitive environment or to single out any individual skill levels whether good or bad.  Lean is a TEAM sport.

In Summary:

Sudoku solvers are able to hone their skills every day.  Perhaps Sudoku Masters even exist.  Imagine someone coming to work with the same simple focus to eliminate waste every day.  Although there is no preset solution, we are able to identify and consider any number of potential problems and solve them as quickly as we can.  The smaller problems solved are a critical part of the overall solution to achieve the goal.

Most professional athletes and musicians understand that skills are developed through consistent practice and exercise.  Repetition develops technique and speed.  Imagine a culture where discovering new opportunities or problems and implementing solutions  is just a normal part of the average working day.  This is one of the defining traits that characterize high velocity companies around the world.

Truly agile companies are experts at seeing and solving problems quickly.  They discover new opportunities in every day events that in turn become opportunities to exercise their problem seeing and solving skills.  Crisis situations are circumvented early and disruptions are managed with relative ease – all in a days work. 

The next time you see a Sudoku puzzle you may:

• be inclined to pick up a pencil and play or
• be reminded of the time you were inspired by the game to solve problems and reach new goals or
• simply reflect on this post and ponder your next break through.

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!

Lean STAR From 6 Deadly Job Networking Mistakes

Sometimes we are inundated with e-mails especially from some of the “Groups” we subscribe to.  Today, one e-mail in particular caught our attention and led us to read a post titled “6 Deadly Job Networking Mistakes” that eventually brought us to a well written article by Gill Corkindale titled, “6 Networking Mistakes And How to Avoid Them“.

If you or someone you know is looking for a job, this article is definitely worth reading.  Finding a job is never an easy task, however, learning to network can make it less of a burden when people are in a position to help each other.  STAR was used as an acronym in the article to help job seekers create stories, or STAR stories.

The concept of creating STAR stories appealed to us as we work with people to help them see, solve, and share problems.

LEAN STAR

The ability to see problems and resolve them quickly is one of the core competencies, or skills, that are emphasized and exercised daily in every lean organization.  The best Lean organizations also emphasize sharing the new knowledge with the team and throughout the company.  (The basic tenets are:  See it, Solve it, Share it, and Teach others to do the same.)

The STAR process adopted from the article can provide a very simple approach to knowledge sharing and provides a very straightforward strategy.  As presented directly from the article …

STAR stands for Situation, Task, Achievements and Results; it’s an easy way to tell a concise story that lets your talents and achievements speak for themselves.  An example might be:

Situation: The customer services division of your company was losing customers, had falling revenues and a conflict-ridden team

Task: To stem the loss of customers, improve customer service, restructure the team and develop new products

Achievements: You held on to key accounts, resolved the conflict, rebuilt team morale and increased the visibility and positive reputation of the department.

Results: Increased revenues (figures), a high-performing customer service team, innovative products (examples) and happy customers.

A STAR story should take no more than five minutes to relate and should include enough detail to pique your contact’s interest without overwhelming him or her.

The acronym can certainly be applied to most problem solving events that we are challenged with on a daily basis.  The simplicity of the approach makes it easy to adopt and prevents the process from becoming overly complex.  The intent is to make improvements in real-time.  The objective is to keep the process simple and task oriented.  They are not intended to become “projects”.

Describe the situation, understand the tasks to be completed and planned results, execute the actions and report  achievements, and report actual results.

Situation:  Lost time decanting parts into smaller container for use at the machine.  Operator reach is excessive and can be reduced – potential repetitive strain injury, fatigue factor.

Tasks:  Eliminate decanting sequence and excessive reaching for parts.  Reduce operator fatigue and potential for stress-strain injury (decanting requires periodic bending, reaching, lifting (below and above waist level). Use drop-side container and stand to convey parts directly to operator.  Time to be saved:  25 minutes per shift.

Achievements:  Change to part conveyance using gravity feed and slide was achieved while line was still operating, no down time incurred, and no operational cost increases.  Demonstrated commitment to improve safety – eliminated risk of injury and eliminated ergonomic impact of decanting operation.  Reduced floor space required to store parts at the operation – 6 square feet.  Eliminated potential to damage parts during decanting operation (dropped parts – typically up to 4 per shift).

Results:  Completely eliminated decanting operation.  Gravity feed is used to convey parts directly and in closer proximity to the operator – reduced reach and no lifting required.  Actual time saved per shift was 30 minutes.  Employee less fatigued and able to focus on immediate tasks at hand.  Productivity improvement of 60 parts per shift.

Typically, any variances between planned and actual outcomes are subject to further review.  Both positive or negative variances to expectations indicate that the process is not fully understood or the problem solving process is itself at fault.  Understanding the variance is a new learning opportunity in itself and is part of the discovery process.

Lean STAR stories

Sharing the lessons learned or documenting new knowledge may be uncomfortable for organizations that are just starting their lean journey.  For some people who are relatively new to lean and problem solving in real-time, this can be a very stressful and intimidating process.  Following the STAR acronym presents a user-friendly approach to documenting and sharing that can easily be learned by anyone.

Some companies are very adept at preparing lessons learned and maintaining best practices.  Larger corporations may even assign the task of documenting and sharing this information to intermediate or senior level staff.  For a company just starting their lean journey, the “sharing” process is not a normal part of daily operations and may be awkward and unorthodox in actual practice.

The objective of lean is to develop the problem solving skills throughout the organization – at ALL levels.  Lean organizations are learning organizations and adopting this approach will help any company to learn more to and also to become better teachers.  Turning people into Lean STARS will give everyone a story to tell.

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.

• The TRIZ Journal:  http://www.triz-journal.com.  A clear overview of TRIZ and the principles of TRIZ can be found at http://www.triz-journal.com/archives/what_is_triz/
• The official Altshuller Institute for TRIZ Studies:  http://www.aitriz.org/
• Comprehensive TRIZ and more:  http://www.mazur.net/triz/

TRIZ Principles

40 Inventive Principles with Examples:

Examples for each of the 40 Inventive Principles can be found at the following link:  http://www.triz-journal.com/archives/1997/07/b/index.html

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:

http://www.triz-journal.com/archives/1997/07/matrix.xls

The TRIZ Journal ARTICLES:

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 http://www.realinnovation.com/content/c080623a.asp

WEB Sites:

• http://www.TRIZ-Journal.com
• http://www.mazur.net/triz/
• http://www.realinnovation.com
• http://www.aitriz.org/
• http://www.ideationtriz.com/home.asp
• http://www.trizgroup.com
• http://www.triz40.com

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:

Technology

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 http://www.mazur.net/triz/ 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!

 

 

Contingency Plans – Crisis Management in Lean Organizations

Contingency Planning For Lean Organizations – Part IV – Crisis Management

In a previous post we eluded that lean organizations are likely to be more susceptible to disruptions or adverse conditions and may even have a greater impact on the business.  To some degree this may be true, however, in reality, Lean has positioned these organizations to be more agile and extremely responsive to crisis situations to mitigate losses.

True lean organizations have learned to manage change as normal course of operation.  A crisis only presents a disruption of larger scale.  Chapter 10 of Steven J. Spear’s book, ”Chasing the Rabbit”, exemplifies how high velocity, or lean, organizations have managed to overcome significant crisis situations that would typically cripple most organizations.

Problem solving is intrinsic at all levels of a lean organization and, in the case of Toyota, problem solving skills extend beyond the walls of the organization itself.  It is clear that an infrastructure of people having well developed problem solving skills is a key component to managing the unexpected.    The events presented in this chapter demonstrate the agility that is present in a lean organization, namely Toyota in this case and it’s supplier base.

Training is a Contingency

Toyota has clearly been the leader in Lean manufacturing and even more so in developing problem solving skills at all levels of the organization company-wide.  The primary reason for this is the investment that Toyota puts into the development of people and their problem solving skills at the onset of their employment with the company.  The ability to see problems, correct them in real time, and share the results (company-wide) is a testament to the system and it’s effectiveness has been proven on many occassions.

Prevention, preparation, and training (which is also a form of prevention) are as much an integral part of  contingency planning as are the actual steps that must be executed when a crisis situation occurs.  Toyota has developed a rapid response reflex that is inherent in the organization’s infrastructure to rapidly regain it’s capabilities when a crisis strikes.

Crisis Culture

We highly recommend reading Steven J. Spear’s “Chasing the Rabbit” to learn and appreciate the four capabilities that distinguish “High Velocity” organizations.  The key to lean is creating a cultural climate that is driven by the relentless pursuit of improvement and elimination of waste.  Learning to recognize waste and correcting the condition as it occurs requires keen observation and sharp problem solving skills.

Creating a culture of this nature is an evolutionary process – not revolutionary.  In many ways the simplicity of the four capabilities is it’s greatest ally.  Instilling these principles and capabilities into the organization demands time and effort, but the results are well worth it.  Lean was not intended to be complex and the principles demonstrated and exemplified in Chasing the Rabbit confirm this to be true.  This is not to be construed as saying that the challenges are easy … but with the right team they are certainly easier.

Until Next Time – STAY Lean!

"Click"