Blog Archives

An Acceptable Range Does Not Equal A Baseline

When solving problems the first thing a person needs to understand is where they are starting from.  To do this they have to create a baseline.  A set of data for the current process and situation.  Without a baseline, a person will never know if they improved the process or made it worse.

When I say a baseline, I mean an understanding of data of the current situation.  I do not mean a range of what is considered normal.  A range does nothing but tell a person where they might expect the data to fall when creating a baseline under normal conditions.  A range can hide problems under the guise of being acceptable.  What if something is at a high end of an range and drops to a low end of the range?  This can still create problems.

For example, two parts have to fit together.  If both parts are at the high end of the range of their part variation they snap in perfectly.  Then one part drops to the low end of the range, while the other is at the high end of the range.  Now the parts don’t fit together and people are confused because both parts are within their acceptable range.  The issue is there never was a baseline created to understand both parts were at the high end and this condition created a good result.

The area I have the most frustration with this is in health care.  A person can go to the doctor wondering if they have hearing loss or damage.  The doctor tests you and says you are fine there is no damage or loss.  How do they know?  They never had a baseline from before to understand the person’s hearing is any different.  The doctors just tells the person they are fine because they are in the “normal” range.

The assumption is the range is built on lots of data over time and covers the 80-85% of the normal distribution of data, again assuming the data fits a normal distribution curve.  What if the person is someone at one of the extremes of the curve?  Doesn’t this change things?

I understand doctors need some tools to help them out.  That is what a range is a tool.  If a patient says something is not normal for them, the doctor can’t say they are normal because their test falls in a certain range.

Ranges are nice and can be helpful, but they are not a substitute for a baseline.  The baseline gives a more detailed picture.  Baselines help to problem solve and improve. So before judging if there is a problem, a person should ask, “Where did I start from?” or “What is my baseline?”

Production Sacrificed in the Name of Changeovers

Is it ever OK to value the number of changeovers you do in a day over your production numbers?  I say no.

I was with a customer recently that did just this.  The customer has done a great job of setting production goals for a press per shift.  On the production board, they write the production numbers in green if the meet or exceed the goal and in red if they do not.

Normally, this is great.  The customer is making the problem visible and easy to see.  Then I noticed that a number below the goal was written in green.  So, I asked about it.  The customer replied the operator did a lot of changeovers that day so we give them green if they do so many changeovers but don’t hit the production goal because the changeovers eat up a lot of their time.

The managers were giving a built in excuse for the operators to not meet the production goal.  If the goal was set with capability and meeting customer demand, then why is it alright to produce anything less than the goal?  This tells me they are not putting a big enough emphasis on changeover reduction.

The question should be changed to understand what is the changeover time needed.  If the largest number of changeovers I need to do in a shift is X and I am accounting for time T to do the changeovers, then my changeover time target should equal T/X.  Example: I allow 1 hour for changeovers and I need to be able to handle 10 changeovers in a day, then my changeover time target should be (60 min) / (10 changeovers) or 6 min/changeover.

If my current changeover time is more than 6 minutes, then I should be doing some sort of SMED (Single Minute Exchange of Die) activity to get the time to 6 minutes or less.

The number of changeovers can never be an excuse for why it is ok not to hit a production goal.  The mindset should be to continue to reduce the changeover time and ideally eliminate the changeover time so the production goals can be met.

Injuries are OK…as Long as We Have Fewer Than Last Year

How many times have you heard, “Safety is our #1 concern.  Safety above all else.”?  I have heard it with every company I have been a part of.  The very first thing I ask when I hear this remark is, what is your safety goal for this year?  To date, I have NEVER had anyone say zero.  In every case, it is some percentage reduction of injuries from the previous year.

If safety is so important, why can’t the stated goal be zero accidents/injuries?  I always follow up my first question with a second question asking if any accident/injury is OK.  I always get a resounding no.  So why is management afraid to state a goal of zero accidents/injuries?

I know stating it is one thing and behaviors are another.  You can state zero accidents but never do anything about it.  But, if you are serious about safety and will do whatever it takes to make sure no one gets hurt, then state that no accidents are acceptable at all.  Set the goal to zero.

I have been apart of a couple of companies that took safety very seriously.  One company had every computer boot up and display the corporate safety metrics, goals, and recent accident reports.  No one could turn this off.  It was visual and created a lot of talk about safety each and every day.  The display showed the current Year-To-Date metrics for every facility.  The company backed up this talk by spending money on safety whenever it was needed.  I can’t even recall a Return-On-Investment study ever being completed.  Also, every meeting had to start with a safety tip.  It might be a work safety tip, ergonomic tip, or a safety tip for home.  Not matter what safety was suppose to start every meeting.

Another facility I worked for won one of the worldwide safety awards after three years of improving to a near zero accident facility.  The plant manager never even hesitated to spend the money if it was truly going to help safety.  Employees were self policing their areas for near misses.  Safety was very important.

Neither company could ever some out and state a goal of zero accidents.  They might state a goal of 2 accidents for the year.  Why not just go ahead and say zero?  What is the hang up with stating this goal?

Money wasn’t just thrown at safety issues in the cases I mentioned.  There was a lot done without spending a dime.  I bring the issue of spending money because I have seen companies ask for a ROI study or payback on things that will improve safety.  Sometimes the improvement is to prevent an accident or injury that might occur.  How do you justify that?

The point is NO injury is acceptable.  Lets have the respect for the people and say that.  Let the people know we do care about their safety.

Data and Facts Are Not the Same

Last week Steve Martin had a great post about data and going to see what is actually happening over at theThinkShack blog.  It struck a nerve with me because it reflects something I seen happening on a regular basis.  I am tired of people trying to solve problems while sitting in a conference room.

I listen to comments like, “Well they aren’t using the right codes for the defect.” or “People just need to put the coding in the system properly and we could figure the problem out.”


Don’t misunderstand me.  Ten years ago you would have heard me say some of the same things.  So, I do have patience with teaching people to go and see.  Once I learned to go and see it became very freeing because I didn’t stress about what the data said.  I spoke to facts.

Data is a good thing.  I am not saying we should ignore data, but we need to know its place.  Data can help point us in the direction of problems.  It can tell us where we should go and look for facts.

Facts to me are what you actually see happen.  What you have observed.  It isn’t the hearsay you get in a conference room.   Facts explain what is actually happening and add deeper meaning to the data.

I lived a great example recently.  In a conference room, managers looked at the data and saw a problem that was happening.  They started talking about what was happening and why.  They asked if I would look into fixing it.  I said I would look at what is actually going on.  I spent 2 hours directly observing the work and realized the one problem they were talking about was actually several different problems out on the floor.  I asked the person actually doing the work to take a couple weeks worth of data based on what was actually happening.  The data showed they actually had 2 big problems that made up 80% of the total errors the original data showed.  I then did another hour of direct observation between an area that had the problem and an area that did not.  I was able to explain the problem with facts that I observed and data to support those facts to add concrete to what I observed.  At that point, there was some obvious ways to correct the situation.

Data and facts are different.  They are not substitutes for each other.  Data and facts can be a very strong combination when used together to understand a problem.

data directional

facts truths – use eyes – go and see

Link to Steve Martin’s Blog Post:

OEE vs. Flow

A very common metric that is tossed around in the lean world is Overall Equipment Effectiveness (OEE).  A couple of weeks ago I posted a blog about clear and relevant metrics and used OEE as an example of how it is not very clear or relevant to the people doing the work.  There is another hang up with OEE.  People become so focused on OEE that it starts to hinder flow.

When transforming the thinking of an area, people can latch onto OEE very easily because it is very silo’ed or machine focused.  The metric focuses on how much the machine is up and how efficient it is with its time and materials.  On the surface, this is all great.  So how does this hinder flow?

When creating flow we want to eliminate/reduce the work-in-process (WIP) between processes.  Once the machines are reliable we might try to create a work cell with several machines.  When creating the work cell it may be necessary to slow one of the machines down to match the pace of another machine.

If the focus is on OEE and not flow, the report will show the machine that was slowed down not being very efficient and cause the OEE to drop.  When this happens a traditional thought process would be to insert more work in order to keep the machine running at full speed.  When this happens, the extra work inserted into the processes causes a jam up of the work trying to flow through the cell.  This will cause lead times to increase and WIP to build back up between the processes.

The ideal state is to get the work flowing without stopping as much as possible.  Make the 80% of the work that is the norm flow and learn how to manage the other 20%.  If the 80% can flow with no effort, it means less work for the supervisors and managers because now they are not worrying about the 80% only the 20%, which is better than worrying about all 100% and managing the WIP it brings.

I know it sounds like I am against OEE but I’m not.  It can be a beneficial metric when used properly.  Like analyzing one single piece of equipment that is the constraint in a process in order to increase the capacity of the entire process or flow.

We shouldn’t focus on the equipment.  We should focus on the flow of the product.  The product should flow like a river.


Clear and Revelant Metrics

Over the last several years I have become very passionate about metrics.  Are they correct?  Do they drive the right behaviors?  Are they being looked at and used?  Not until recently did I spend some time reflecting on metric characteristics in areas that were using them successfully to drive improvement.  The two characteristics that I found were clear and relevant.  It sounds so simple and easy but I have seen so many failures in doing this.

First of all the metrics need to be relevant to the employees that are targeted to use them.  I have learned to ask the employees in an area I visit if the metric displayed mean anything to them.  A vast majority of the time the answer is ‘no’.  It used to be shocking at first but unfortunately now it isn’t.  This creates busy work for people maintaining the metric and adds waste to the system.  More importantly, it shows underlying disconnect between the people creating the metric (supplier) and the people using the metric (customer).  If the levels of management have a disconnect with the metrics, it is pretty safe to assume there are many more disconnects with in that supplier-customer relationship.

It isn’t only important that the metric is relevant to the people using it, it must also be clear.  It must be clearly understood, clearly connected to cascading up goals, and the goal must be clearly stated.  Too often, I see examples of metrics that are very unclear to the user.  An example might be having front line hourly employees using standard cost metrics.  It is very unclear what the front line employee can do to affect the standard costing.  This leads them to not drive improvement.  Another metric that I find very unclear is OEE (Overall Equipment Effectiveness).  This is one that is used by many companies to drive improvement.  I find it very unclear.  It is a product of three factors: yield’ uptime, and machine efficiency.

OEE = Yield x Uptime x Machine Efficiency

So, if OEE changes which one caused it to change?  Or worse yet, what if OEE stayed flat but it was because uptime increase and yield decreased?  Would anyone know?  The equipment is still performing the same according to the OEE.  In order to understand what is happening, you have to break apart the metric into the three components, so why add the over processing?  I have seen OEE misused so many times, but that is for another discussion.

When I have seen clear and relevant come together, I have seen greater improvements and greater buy-in.  One great example was an area manager where I work.  When asked if the current metric (packages completed) meant anything to the employees they said ‘no’ and ‘they don’t pay any attention to it’.  His uptime on a line was 2.6 hours / shift.  He wanted to get more packages per shift but that metric didn’t mean anything to the employees but uptime did.  The area manager connected number of packages completed in hours of uptime in order to make it relevant to the employees on the floor.  Then he took away all other metrics in the cell and asked them to hit 5.0 hrs of uptime per shift (he also gave them some problem solving help).  Within the first week the cell was hitting hours of uptime per shift.  Three months later he had to increase the goal to 6 hours per shift.  The area manager has been able to reduce the number of cells needed by 50% and eliminate the need for temporary employees in his area.  When an employee is asked what is their goal they clear state, “Six hours of uptime per shift.”  The connection between uptime and all the other management goals is clear as everything else has moved in the proper direction, cost, delivery, OEE, etc…..

So whenever you are looking at metrics, make sure they are clear and relevant and I will bet that once that connection is made you will be very successful.