What data for changeover monitoring and improvement?

CapacityMaximizing the exploitation of critical Capacity Constraint Resources (CCRs), so called bottlenecks, is crucial for maximizing revenue. Changeovers usually have a significant impact on productive capacity, reducing it with every new change made on those resources that already have too few of it.

Yet changeovers are a necessary evil, and the trend is going for more frequent, shorter production runs of different products, so called high mix / low volume. Consequently, changeovers must be kept as short as possible in order to avoid wasting the precious limited productive capacity of Capacity Constrained Resources (CCRs).

Monitoring changeover durations at bottlenecks is a means to:

  • reinforce management’s attention to the appropriate CCR management
  • analyze current ways of changing over
  • improving and reducing changeovers duration

Management’s obsession should be about maximizing Throughput of the constraints.

To learn more about this, read my post “If making money is your Goal, Throughput is your obsession”.

What data for changeover monitoring?

When starting to have a closer look at how capacity is lost during changeovers, the question is: besides direct periodic observations, what data are necessary and meaningful for such monitoring?

Before rushing into a data collecting craze, here are a few things to take into account:

In the era of big data, it is admitted now that one never has enough data. Yet data must be collected somewhere and possibly by someone. The pitfall here is to overburden operators with data collection at the expense of their normal tasks.

I remember a workshop manager so passionate with data analysis that he had his teams spent more time collecting data than to run their business.

Chances are that your data collection will be manual, by people on shop floor. Keep it as simple and as short as possible.

This a matter of respect for people and a way to insure data capture will be done properly and consistently. The more complicated and boring the chore, the more chances people will find ways to escape it.

Take time to think about the future use of data, which will give you hints about the kind of information you need to collect.

Don’t go for collecting everything. Essential fews are better than trivial many!

Be smart: don’t ask for data that can be computed from other data, e.g. the day of the week can be computed from the date, no need to capture it.

Example of data (collected and computed)

  • Line or machine number
  • Date (computed)
  • Week number (computed)
  • Changeover starting date and hour
  • Changeover ending date and hour
  • Changeover duration (computed)
  • Changeover type
  • Shift (team) id.

Explain why you need these data, what for and how long presumably you will ask for data capture. Make yourself a note to give data collectors regular feedback in order to keep people interested or at least informed about the use of the data.

Data relative to resources with significant excess productive capacity can be ignored for the sake of simplicity and avoid overburdening data collectors. Yet chances are that some day you’ll regret not having captured those data as well, and soon enough. Make your own mind about this.

Monitoring: what kind of surveys and analyses?

There are roughly two types of analyses you should be looking for: trends and correlations. Trends are timely evolutions and correlations are patterns involving several parameters.

Trends

One key trend to follow-up is changeover duration over time.

Monitoring by itself usually leads to some improvement, as nobody wants to take blame for poor performance i.e. excessive duration. As frequently things tend to improve spontaneously as soon as measurement is put in place, I use to say measurement is the first improvement step.

The first measurements set the crime scene, or original benchmark if you will. Progress will be appraised by comparing actual data against the original ones, and later the reference will shift to the best sustained performance.

In order to compare meaningful data, make sure the data sets are comparable. For instance certain changeovers may require additional specific tasks and operations. You may therefore have to define categories of changeovers, like “simple”, “complex”, “light”, “heavy”, etc.

Over time the trendline must show a steady decrease of changeover durations, as improvement efforts pay off. The trendline should fall quickly, then slow down and finally reach a plateau* as a result of improvements being increasingly difficult (and costly) to achieve, until a breakthrough opens new perspectives: a new tool, simplified tightenings, another organisation…

Changeover duration

*See my post Improving 50% is easy, improving 5% is difficult

>Consider SMED techniques to recover capacity

Correlations

Looking for correlations is looking for some patterns. Here are some examples of what to check:

Is there a more favorable or unfavorable day of the week? If yes, understanding the cause(s) behind this good or poor performance can lead to a solution to improve everyday performance.

Does one team outperform underperform? Is one team especially (un)successful? The successful team may have better practices than the lower performing ones. Can those be shared and standardized?

For instance if one team consistently outperforms, it could be this team found a way to better organize and control the changeover.

If it is the case, this good practice should be shared or even become the standard as it proved more efficient.

I happen to see the performance data from a night shift in a pharma plant being significantly better than the day shifts. Fewer disturbances during the night was the alleged cause.

Be critical: an outstanding team may “cut corners” to save time. Make sure that all mandatory operations are executed. Bad habits or bad practices should be eradicated.

Conversely, poor performing teams may need to be retrained and/or need coaching.

Is one type of changeover more difficult to master? Search for causes and influencing factors. Some engineering may be required to help improving.

These are only some examples of patterns that can be checked. Take time to consider what factor can have some influence on changeover ease and speed, than check how to test it with data and how to collect these data.

Note that correlation is not causation. When finding a pattern, check in depth to validate or invalidate your assumptions!

Speak with data

All the data collection and analysing is meant to allow you and your teams to speak with data, conduct experiments in a scientific way and ultimately base your decisions on facts, not beliefs or vague intuitions.


Bandeau_CH160601View Christian HOHMANN's profile on LinkedIn

3-color system for Goal Trees

In this 5 minute excerpt from the Logical Thinking Process (LTP) Alumni reunion with Bill Dettmer, June 2016 in Paris, France, I explain my 3-color system for assessing the current reality with a Goal Tree.

The 3-color system is a visual management tool to assess the organization’s readyness to achieve its Goal and shows where to act in priority.

You’ll find several articles on this topic here on my blog, for instance:


Bandeau_CH40_smlView Christian HOHMANN's profile on LinkedIn

Does Value Stream Mapping apply to Product Development?

Value Stream Mapping (VSM) is a great tool to map processes. It started in manufacturing where it is used to understand physical and information flows and quickly spread to administrative processes. It is even used in hospitals.

As Product Development is a process, so yes VSM can be used.

However, development activities have some specificities compared to manufacturing which require to adapt VSM to Development and also bring some limitations to VSM used in Development.

>Lisez-moi en français

The first limitation is similar to manufacturing if the activity is high mix / low volume. In such a case, the specificities may outweigh the commonalities, thus drastically reduce the interest of VSM as the time spent to map the process vs. valuable informations to get from the map isn’t worth it.

If this isn’t the case, and if the Product Development process is underperforming and needs improvement, VSM “manufacturing-style” can be used to map and analyse the development process despite other limitations. It is “good enough” to surface the biggest obstacles to better performance.

Having used VSM to describe and analyze an automotive equipment maker product development process, I could identify improvements leading to a potential 30 to 40 % Lead Time reduction depending of the nature of the project. This is consistent with what I call the Lean rule of thirds, i.e. reducing wastes or improving performance 30%.

Later on, with a more mature Product Development process this type of VSM may show its limitations.

VSM pitfalls and limitations in Development

There are many differences between manufacturing and development. For instance the definition of “value-added” is relatively easy in manufacturing while more elusive in development. Takt time is a key concept for production but does not make sense in development*. Loops are wastes in manufacturing but iterations are valuable in development.

*Takt time in manufacturing is the rate of customers’ demand. In development takt time can be the rate of new projects or product launches decided by the company.

Concurrent activities are seldom in manufacturing but common in Lean Development, and so on.

Therefore the transposition of Lean Manufacturing methods and tools is possible to some extend but with great care and adaptation. One warning about this is to be found in “The Lean Machine” Productivity Press. pp. 131–132:

Key learning about the difference between TPS and LPD is summarized in the advice Jim Womack gives Harley Davidson’s Dantaar Oosterwal; “Don’t try to bring lean manufacturing upstream to product development. The application of Lean in product development and manufacturing are different. Some aspects may look similar, but they are not! Be leary of an expert with experience in lean manufacturing that claims to know product development”.

On the other hand, Allen Ward and Durward Sobek recommend to “learn from Lean Manufacturing to improve labs and prototype shops”, in Lean Product and Process Development, Lean Institute Inc, 2014 second edition p.42.

Other resources about VSM for Product Development exist. Here are only few chosen examples:

Ronald Mascitelli discusses the usage of VSM in his book “Mastering Lean Product Development”, Technology Perspectives 2011, pp. 187-190.

There is a paper of interest by Darwish, Haque, Shehab, and Al-Ashaab, “Value stream mapping and analysis of product development (engineering) processes”  that can be downloaded here:  https://www.researchgate.net/publication/272565743

Finally, the Lean Aerospace Initiative (LAI, MIT) proposed the Product Development Value Stream Mapping (PDVSM) specifically designed for Product Development. The Manual version 1.0 (Sept. 2005) can be downloaded for free from several sources, including MIT:

https://dspace.mit.edu/bitstream/handle/1721.1/83453/PDM_1003_McMan_PDVSM.pdf?sequence=1

Wrapping-up

Value Stream Mapping does apply to Product Development with limitations in mind and/or adaptation to the specificities of development activities. Before rushing to map such a process, give yourself time to consider if the time invested will really be worth it, especially if the process is not likely to be common to many new developments.

VSM is great but is only one tool among others. The value of the analysis does not come from the map but from the “brain juice” the analyst(s) throw in to sift out improvement potential and identify issues and obstacles to overcome.

Feel free to comment and share your thoughts and experience. If you liked this post, share it!


Bandeau_CH160601View Christian HOHMANN's profile on LinkedIn

Why No One Talks About TPM Anymore?

Total Productive Maintenance (TPM) was a big thing in the late 1980s, got lot of attention, tried to go from “maintenance” to “management” and finally faded out into oblivion.

This analysis is my own, you may respond in comments.

Total Productive Maintenance (TPM) originated in Japan with Nippondenso in the 1960s and is an evolution from Preventive Maintenance principles introduces to Japan from the USA.

TPM grow popular in the west with other “Japanese methods” in the 1980s when Toyota Production System (TPS) was not known nor the word “Lean” used for manufacturing.

TPM in a nutshell

TPM proposed a framework of 8 pillars aiming at getting the most out of lines, machines and equipment especially by reducing machine downtime and increasing machine availability. The 8 pillars are:

  • Autonomous Maintenance
  • Planned Maintenance
  • Quality Maintenance
  • Focused Improvement
  • Early Equipment Maintenance
  • Education and Training
  • Health, Safety & Environment
  • TPM in Office

Their naming and order (may) vary according to sources. “Six big losses” were identified as obstacles to better machine effectiveness:

  1. Breakdown losses
  2. Setup and adjustment losses
  3. Idling and minor stoppage losses
  4. Speed losses
  5. Quality defects and rework losses
  6. Startup / yield losses

These six losses’ measurement were combined into a single KPI: Overall Equipment Effectiveness (OEE), still very popular and widespread in industry.

TPM was striving to improve OEE by developing the personnel’s maturity about the 8 pillars and reducing the 6 losses.

Early years till today

TPM brought tremendous improvements in operations and work conditions. Despite the machine-orientation TPM had also influence on operations management and at some point was supposed to translate into broader application, attempting to go Total Productive Management.

Alas, TPM was strongly machine shop and shopfloor connoted and never got much attention outside of these playgrounds. Furthermore, Lean became highly fashionable and easier to transpose in any activity, thus got all attention.

In my humble opinion TPM was bound to fail from the moment it was presented as a maturity-driven approach to improvement, requiring organizations to go through a multiyear program, step by step implementing every pillar. The pitch was that eventually performance will raise once personnel is trained and gets experienced with TPM. After some years of continuous effort, the organization will be mature enough to apply for one of the PM awards awarded by the Japan Institute of Plant Maintenance (JIPM) or local representative body.

Of course, the journey toward maturity would require consultants’ support, making it a long, costly and still risky one. With the competitive challenges getting tougher, few CEOs would commit to such a slow approach with questionable ROI, very much machine-effectiveness oriented.

Nowadays OEE, quick changeover and setup techniques like Single Minute Exchange of Die (SMED) are seen as part of the Lean Body of Knowledge and TPM very seldom mentioned.


Bandeau_CH160601 View Christian HOHMANN's profile on LinkedIn

We are all Lean now. What’s next?

Every once in a while, for nearly 30 years, the question arises: “what’s the next big thing after Lean?”, suggesting that the askers are done with Lean. We write July of 2016 and it seems that everybody is Lean now.

Many people have been repeatedly exposed to Lean methods and tools, have been involved in Lean workshops, kaizen events, sketched Value Stream Maps and identified wastes, sorted out, cleaned up and rearranged stuff 5S style.

They have seen improvements, celebrated the workshop’s success and were dismissed with a feeling of mission accomplished. Others didn’t see a clear outcome, noticeable improvement or a sustainable result and resumed their regular work.

Both may have a legit feeling of being done with Lean, the first because their objectives were met, the latter because Lean doesn’t work.

Almost everybody has heard about Lean, in good or bad, in manufacturing or administration, in hospitals or software development. Lean is a word that found its way into the business lingo, and hearing it often makes it familiar.

There is also the growing impatience as everything speeds up and the instant satisfaction sought by everyone becomes commonplace. Few people are able to commit to a very long and tedious journey towards excellence in the Lean way, most would prefer periodical quantum leaps. Just as they replace their smartphone from one model/generation to the next, keeping up with fashion or state-of-the-art technology.

Of course we are far from done with Lean and very very few companies I’ve visited can claim being Lean. Nevertheless I can understand the fading interest in Lean and the need to reinvigorate it with something new and effective.

Something new means something new to people they didn’t know about until now, not necessarily new per se. Effective means bringing positive results system-wide, not a local optimisation.

My advice would be to consider Throughput Accounting, Critical Chain Project Management and the Logical Thinking Process.

This is not about the next big thing AFTER Lean but the next big thing WITH Lean!

Throughput Accounting (TA) is not really accounting but rather a Throughput-based decision-making approach. In a nutshell, TA shifts focus from cost reduction to Throughput increase and optimization. Follow this link to know more.

Critical Chain Project Management (CCPM) revisits Critical Path Method, the prevalent project management method that failed so far to get developers and project teams to finish on time. CCPM makes sure that projects finish on time and that, thanks to continuous improvement Lean and CCPM style, project durations can be shortened in future.

Logical Thinking Process (LTP) copes with system-wide complex problems. It provides logical tools and methods to surface and neutralize false assumptions, beliefs, conflicting objectives and the like that hinders the organization achieving its goal.

Giving a try with any or all TA, CCPM and LTP, will reveal new potentials and focusing points for Lean to exploit them. Lean isn’t gone soon.


Bandeau_CH160608View Christian HOHMANN's profile on LinkedIn

My takeaways from throughput accounting, the book

I knew the author, Steven M. Bragg from his podcast series “Accounting Best Practices with Steven Bragg” before I came across his book “throughput accounting, a guide to constraint management” published by Wiley & sons, 2007.

Book presentation

The hard cover book has 178 pages, 10 chapters, easy to read in neat presentation and legible fonts, with numerous tables, graphs and illustrations to back up all the provided examples and case studies.
It claims to contain the tools needed to improve companies performance for accountants, financial analysts, production planners or production managers.

The book starts head on by introducing the basics of Theory of Constraints (ToC) in an uncommon, and for me daring way: explaining very briefly the Drum-Buffer-Rope (DBR) logic, in chapter 1 (page 1!).

It is daring because it’s a shortcut putting DBR upfront when it’s usually presented to newbies (long) after explaining the bottleneck concept and the differences between traditional manufacturing, trying to run every resource at full utilisation rate, versus the ToC approach where “only” the bottleneck matters (this is another shortcut, but of mine…).

It goes on with presentation about the different types of constraints, not all being bottlenecks, discussing the nature of the constraint (page 5). The Throughput Accounting (TA) KPIs are presented page 7 and 8 before diving into the financial aspects of TA.

Chapter 2 is about Constraint Management in the factory, starting with how to locate the constraint and how to manage the constrained resource. The various hints are clearly targeting managers or readers keeping some distance from shopfloor as they give enough insight without being too detailed. No people will go through and get bored, the various hints are condensed within few lines, without giving up anything important.

Four pages deal with policy constraints, again something of interest for managers and readers that may have influence within their own organization to educate their colleagues about the drawbacks of some policies and hopefully change them. The importance of constraint buffer comes page 25 followed by the importance of proper batch sizes and machine setups.

Chapter 3 is about throughput (TA) and traditional cost accounting concepts and starts with the emphasis on cost versus Throughput and goes on with all the consequences describing why traditional cost accounting – companies that means – is suffering from several problems.

This chapter is important for people not very familiar with accounting, especially in operations, because it explains some of the decisions that make no big sense when considered from operations point of view. It is also important for those familiar with traditional cost accounting for to understand the limitations and problems brought up by that approach.

Chapter 4 is about Throughput and Financial Analysis Scenarios and from page 59 to 86 take the readers through 14 different scenarios, from Low Price, High Volume Decision to Plant Closing Decision.

Chapter 5 is on Throughput in the Budgeting and Capital Budgeting Process, chapter 6 about  Throughput and Generally Accepted Accounting Principles and chapter 7 about Throughput and Control Systems.

Chapter 8 details Throughput and Performance Measurement and Reporting Systems, interesting because it links the operations’ reality to usable KPIs, e.g.

  • Ratio of Throughput to Constraint Time Consumption
  • Total Throughput Dollars Quoted in the Period
  • Constraint Utilization
  • Constraint Schedule Attainment
  • Manufacturing Productivity
  • Manufacturing Effectiveness
  • Order Cycle Time
  • Throughput Shipping Delay
    And more.

Chapter 9 is named Throughput and Accounting Management and addresses 12 decision areas among which: Throughput Analysis Priorities, The Inventory Build Concept, Investment Analysis, Price Formulation.

Finally chapter 10 presents 7 Throughput Case Studies each of them in a couple of pages.

My takeaways

The book is easy to read and to all concepts are easy to understand thanks to the simple ways the author puts them. Not being an accounting specialist at all, I always liked the simple, pragmatic and concise ways Steven Bragg explains accounting rules or practices. This book is not different.

Reading “throughput accounting, a guide to constraint management” reinforced both my knowledge and my interest in throughput accounting, as well as the conviction about throughput accounting being a powerful and crucial decision-making approach.

I’ve marked dozens of pages with sticky notes highlighting my points of interest and/or inspirations for posts on my blog, reinforcing my consulting approach, etc.

Throughput accounting

Almost all companies have their management heavily influenced by traditional cost accounting and most of them make ill-oriented decisions. With the book’s content help, it is easier to explain to CFOs and CEOs why their decisions are biased by false assumptions or outdated rules, something that can be quite shocking to them.

The book doesn’t come cheap, but as it explains, quit reasoning in terms of cost savings and consider how much (intellectual?) Throughput it can leverage.


Bandeau_CH160608View Christian HOHMANN's profile on LinkedIn

What is a critical root cause?

A root cause is the beginning of the cause-effect relationship*. Thus when working down the chain of causes and effects from a problem to its cause, a Root Cause Analysis (RCA) meets causes themselves being effects of some underlying causes and so on, down to the root cause from which everything about the problem originated.

According to wikipedia, a root cause “is an initiating cause of either a condition or a causal chain that leads to an outcome or effect of interest. Commonly, root cause is used to describe the depth in the causal chain where an intervention could reasonably be implemented to improve performance or prevent an undesirable outcome.” https://en.wikipedia.org/wiki/Root_cause

In “The Logical Thinking Process, A Systems Approach to Complex Problem Solving”, my mentor and friend Bill Dettmer defines a root cause as:

  • *The beginning of the cause-effect relationship
  • The lowest cause in the chain before passing outside the sphere of influence – the most basic thing one can do something about
  • The first cause beyond the sphere of influence, where someone can’t personally do anything about

In the context of the Logical Thinking Process (LTP) and more specifically when working with Current Reality Trees (CRT), a root cause is an entity with arrows coming out but no arrow going in. In this context a root cause is not necessarily something negative.

So far for the root cause, but what is a critical root cause?

Critical root cause

According to Dettmer, a root cause can be a historical event of the past or a fact of life nobody can do anything about. A root cause can also be out of the sphere of influence to change. Therefore, in order to solve problems and remove Undesirable Effects (UDEs), the problem solvers must search for critical root causes, which are defined as:

A policy, practice or prevalent behavior that constitute the lowest level of causality in existing reality lying within someone’s sphere of influence to change. (p108).


Bandeau_CH160601View Christian HOHMANN's profile on LinkedIn

Redefining “problem” (with Goal in mind)

In problem solving or continuous improvement workshops a problem is usually defined as a gap between the actual situation and the desired situation, and thus a problem causes an unsatisfactory situation or an UnDesirable Effect (UDE).

This definition, while true, is somewhat too vague to be useful when working on solving problems and continuous improvement.

Indeed, in a business environment* many things can be qualified “undesirable situation” or “undesirable effect”, from bad tasting coffee to important production equipment breakdown, from laser printer toner stockout to quality control rejecting an important production batch.

In most business environments improvement opportunities are literally infinite.

*business environment can be very vague as well, I suggest every reader to transpose this article into his/her environment.

From these few examples it becomes obvious that the too broad definition of problems need some refinement. The limited time and resources of an organization should not be wasted on every so-called problems, but instead solely focused on the critical ones.

Failing to do so bears the risk of spending time and burning up resources to solve “problems” without any system-wide noticeable positive effect. That’s what happens to so many Lean initiatives or continuous improvement programs, draining significant resources for frustrating results.

So, how to select the problems worth coping with?

In a business environment the organization exists to achieve a Goal, itself subordinated to the achievement of several objectives. When something hinders the organization to achieve its objectives, hence its Goal, the hinderance is worth attracting (all) focus for problem solving.

In “The Logical Thinking Process, a  Systems Approach to Complex Problem Solving”, Bill Dettmer defines a UDE as “something that really exists; something that is negative compared with the system’s goal, Critical Success Factors or Necessary Conditions.” This definition is linked to The Goal Tree and if this one is properly built, the understanding of what an UDE is will be straightforward and unquestioned.

Now with the organization’s Goal in mind, a “problem” can be understood as an UnDesirable Effect (UDE) being an obstacle for the organization to achieve its objectives, its Goal. Anything felt undesirable but not directly threatening the achievement of the objectives or Goal is an annoyance at best.

Does it mean anything NOT threatening the objectives and Goal is not worth considering?

While priority must clearly be given to issues and UDEs hindering the organization to achieve its Goal, some “annoyances” should be taken care of as well. Things making job or life easier for employees for instance may not directly contribute to corporate objective achievement but can help improve morale, ergonomics, safety and the feeling of being important enough to the organization to deserve some attention.

Well, how to select these “problems” worth considering?

This is where methodologies handover to management, “science” handover to “art” and plain rationality to humanity. It’s up to managers to sense what is to be done, why and to what extend.


Bandeau_CH160601View Christian HOHMANN's profile on LinkedIn

June 2016 LTP Alumni Reunion

June 2016, right after the 6-day Logical Thinking Process (LTP) training course with Bill Dettmer in Paris, France, the first LTP Alumni Reunion took place.

The 2-day reunion’s intent was to bring together former LTP students who attended one of Bill Dettmer’s numerous courses, share experience and “war stories” and start building a community. Bill was also proposing a hands-on workshop to demonstrate how to build a Current Reality Tree with tighter logic using the syllogism.

I participated as an alumni (2015) as well as a host. The event was hosted in our (Marris Consulting’s) offices in downtown Paris

The reunion proved to be a success, although the participants were limited in numbers (seats were not limited) mostly because of personal agendas.


Listen to Bill Dettmer opening the reunion


One participant was not a “true” alumni as he did not (yet) take the LTP course, but came in as a “guest observer”. Nevertheless, Jean-Luc was familiar with the TOC Thinking Processes and had personal experience using them.

In this video I am discussing the learnings from this event with Bill on the very evening of the last day.

As decided during the reunion, we will keep on proposing periodical reunions, yearly probably for gathering in some place and every six months in between with a live webinar.

We also created a LTP Linkedin discussion group to have a common space for announcements, sharing and promoting LTP: https://www.linkedin.com/groups/8555389

The future alumni reunions will be relatively open to newcomers upon invitation and the LTP group will remain open to non-alumni.

I hope to meet you somewhere in near future!


Bandeau_CH160608View Christian HOHMANN's profile on LinkedIn