Businesses typically care about only three things: 1) Increasing Revenue, 2) Reducing Cost, and 3) Cost Avoidance. But it isn’t always easy to connect the work to one of these three outcomes.
Reducing scrap. Reducing lead time. Decreasing accidents. Making quicker decisions. These are things it is easier to connect to our work. These are outputs.
So how do the outputs tie to the outcomes? That is where a benefits map can help.
The benefits map takes the deliverables of the work (on the left) and ties them to the outcomes (on the right) by way of the outputs (in the middle).
Properly designed work has known deliverables. Getting to how theses deliverables are going to change known metrics connects them to the outputs. Then it is working with the customer to think about how changing those outputs will create a better outcome for the business.
The last step is to quantify the benefit to the outcome.
There are two positives to this method. The first is the team has to stop and think about how the work will benefit the business. Just the awareness alone creates teams that more in touch with how they are affecting the business.
The second is the people doing the work become more engaged int he work. They can see a visual of how they are making an impact.
Understanding how your work is helping the business is a key component in employee engagement. The Benefits Map is a simple but effective tool to help engage people.
I saw a post from Michel Baudin, Is OEE a Useful Key Performance Indicator? I don’t think it is. A few years back I wrote a blog about OEE and how it is very unclear as to what is really happening in a facility. It violates nearly every rule as to what is a clear and relevant metric.
Michel’s post started out with a bit from Jeffrey Liker’s post about OEE. This is the piece I found interesting from Jeffrey Liker:
Ignacio S. Gatell questions whether companies using OEE really understand it, can explain it clearly to their customers, and understand what it means to compare OEE as a KPI across plants. He questions whether even plant managers understand how it is calculated and what it means.
The only good argument for OEE is that at a macro-level in a plant it provides a high level picture of how your equipment is functioning.
I have to agree with Liker’s statement. OEE is good for a macro level idea of what is happening but you can’t understand what is happening without splitting it up into the components. Seems like Michel Baudin is thinking the same thing.
It is an overly aggregated and commonly gamed metric that you can only use by breaking it down into its constituent factors; you might as well bypass this step and go straight to the factors.
This is one of those blogs that gives me some of my sanity back. OEE seems to be so entrenched in “good business practices” it is hard to get people to move away from it. I get a lot of looks like I am completely crazy when I bring up my point of view. Thanks, Jeffrey and Michel. I see I’m not the only one now.
My wife saw a post by a shop owner on Etsy this week that just drove us both absolutely crazy. The shop owner posted how you should determine your wholesale and retail pricing.
The first step was to determine your costs. What are your costs of materials? Even what is the cost of your time? While I agree with that logic, the cost of my time can be very subjective, but it makes sense. There was a exhaustive list of what to include in determining the cost of a product. A very large portion of it we agreed with.
After this is when it got interesting.
According to the shop owner, your wholesale pricing should be double your costs. Your retail pricing should be double your wholesale pricing.
The shop owner was very firm that this is the only way to price.
Based on this logic, you are entitled to a 75% profit margin when selling it in retail and a 50% margin when you are selling wholesale.
So why are people going out of business?
Because, this is not correct at all. The price is set by the consumer. If the consumer, sees value in your product at that price then they will pay for it. If they don’t, they won’t.
As a shop owner, it is your responsibility to control your costs to help control your profit. If your costs are low and the market is willing to pay a very high price then you will get a large profit margin, but if the opposite is true then you may lose money.
If everyone deserved a 75% profit margin then no one would be going out of business. Just because you are in business does not mean you deserve a profit. If you want a profit…earn it. Know your market. Set the price appropriately and then control your costs.
This is the heart of entrepreneurship.
There was an interesting story a couple of weeks back about the use of HGH in Major League Baseball (MLB). It took years but there is finally testing for performance enhancing drugs, including human growth hormone (HGH).
The part that was most interesting from a lean and metrics standpoint was about the base lining of HGH. Instead of using baseline data for the amount of HGH a person should have established by the World Anti-Doping Agency (WADA), MLB is establishing their own baseline. What is even more incredible is the MLB is telling players when they will be tested for the baseline.
A MLB player can load himself with HGH in preparation for the test. This would be no different than a department manager saving some of the extra production from the week before and print the finishing tickets the next week so both weeks look good. MLB’s baseline procedure would allow players to skew the baseline to the high side. Players could continue to take HGH as a performance enhancing drug and still “be within the baseline.”
This is gaming the system to your benefit and missing the true intention of what is trying to be accomplished. This is why the principle of directly observing the work is so important. When you go and see what is actually happening gaming the system becomes harder because you see the finished product on the floor waiting for tickets or that players might be juicing up for the baseline test.
A balanced scorecard and direct observation can help prevent gaming the system.
As the year comes to an end, companies and organizations start to evaluate how they performed for the year and what they need to do to make next year better.
The planning for the new year starts with objectives. What is it the company needs to do to be successful in the upcoming year? Reduce costs. Increase sales. Bring new products to market.
Objectives are only half of the work though. Too often, I see companies set objectives above but never publish a goal for the objective.
Can I reduce costs by $1 and be successful? $100 million? What?
How much do I need to grow sales? What part of the company’s market needs to grow in sales?
How many new products need to hit the market? How much revenue to new products need to generate?
Without answers to these questions how are people suppose to know if they are being aggressive enough during the year? Maybe we only need to reduce costs by 5% or maybe it is 25%. The answer to this question will inform how you go about reducing costs, growing revenue or bring new product to market.
As leaders, we need to set goals/targets for each objective. Then we need to give updates during the year to understand how we are progressing towards these objectives.
These isn’t new or earth shattering. But it is something I see quite a few companies neglect.
What are your objectives for next year? What is your goal for that objective?
This doesn’t have anything to do with poultry, but more with the age old question of which comes first. (Although, if you’d like to talk about actual chickens, let me know.) When pushing forward a continuous improvement mindset, one of the first obstacles is in understanding where your biggest problems are. This is often an issue because the structure doesn’t exist to gather, compile, and filter data from the operation. Using an A3 format as an example, it becomes very difficult to get past the first step if you can’t quantify where you are in relation to your ideal state. Or, if you can’t quantify the relative impact of potential causes on the outcome you are measuring.
In general, this leaves you with a couple of choices. Choice A is to go forward with what you have and make changes based on what information you have available. Choice B is to put the brakes on for a while and focus your improvement efforts on improving the measurement and reporting systems. Both of these options have upside and downside.
If you follow the path of Choice A, you can start down the path of training people in the methodology and mindset of Lean problem solving. Those are good things, plus you get the visibility of “implementing Lean”. The downside of this path is that you really don’t have a good idea of the relative scope of issues and you risk working on something that isn’t that impactful or has to be undone when seen in better context.
Following Choice B, you will most likely end up with a more whole understanding of what you should be working on and why. However, you run the risk of losing support as others don’t see anything happening and people start to question when the “real work” will start.
So…which comes first…the problem solving or the measurement system? The short answer that I have come across is this: It depends. In theory, an effective measurement system highlights the problems that need to be addressed and is a must to have in place. In practice, not all organizations are patient enough to build the core of the metrics system without pushing the ‘execution’ phase along quickly. One of the skills involved in leading Lean (or, really, leading anything), is the understanding of where you may or may not have cultural (or individual) support to be patient or you need to “just do it”, building context of the picture on the fly. As uncomfortable as it may be, your people, your culture, and your environment trump the textbook roadmap almost every time.
A couple of months ago, Joe wrote a great blog on Problem Solving Pitfalls. I have read that post few times. Partly because Joe and I made some of those mistakes together. Partly because I think there is another to add to it.
Just because data is being collected does not mean it is useful.
Too many times I have watched people (including myself) use data because it was available. It was not the data that would tell the story of the process. You may have to decide what data would be helpful and devise a way to collect the data. he data does not have to be what is available in a computer. Having it captured by hand is a viable way to collect the data. The data may only need to be collected for a specific amount of time during the problem solving process. Once the problem has been solved, there may be no need to collect the data.
This can be difficult but it will be well worth the effort in the long run. You will get a better picture of the problem you are trying to solve and in turn this will lead to an easier time getting to the root cause of the problem.
This is part of my reflections from the OpsInsight Forum in Boston.
There were a lot of technology companies presenting at the forum. The companies had a lot of pretty cool technology that could be used. AT&T presented their business mobility solutions. It was not around the iPhone. It was technology designed to bring real-time visibility to supply chain needs, inventory and performance dashboards.
I was very intrigued by what they were presenting. The lean thinker in me thought to slooooooow down. What would be the purpose of the technology? How would it help? It does no good to implement technology on something that will not drive any action.
Real-time technology for inventory, supply chain needs, and dashboards can have a negative effect. If the leadership is not in the habit of going and seeing what is happening all real-time technology will do is allow a quicker solution response without understanding what is actually happening.
The real-time technology can be a great enhancement for leadership that is in the habit of going and seeing. The quick alert of an issue can allow them to get to the area to witness the problem before it disappears. Since the leadership sees the problem in real-time they have a better understanding and can have a countermeasure in place quicker.
Without the real-time technology, the leadership may not find out about the issue until it has disappeared which means they have to wait for the issue to come up again in order to understand the problem or spend time recreating the issue. The team loses time before they can have a countermeasure in place.
If the leadership does not have the go and see mindset then all the real-time technology in the world will not help change the behavior. Technology is a wonderful thing, but “with great power comes great responsibility.”
This is part of my reflections from the OpsInsight Forum in Boston.
At the conference there were a few software companies that presented keynote speeches (IBM, CCI, and AspenTech) and breakout sessions (AT&T, Vecco International, and Llamasoft). During these sessions I heard a lot of the right things. They would explain that technology is not a silver bullet that will solve a companies problems. Technology enables a process. It isn’t the process. Organizations should put in technology only after it has established a process. In fact, Shekar Natarajan, from Pepsi Bottling Group, was asked what Pepsi did differently to win a national award for technology implementation. His reply was, “We considered technology last.”
It was said that a technology company should not sell a more advanced solution than what the client needs. Sometimes the client may not truly understand their options and want more than they are ready for, but the technology company should’t sell them that advanced solution because it will cause more problems.
Right on, right?
While I agree with what is said, that is not what I am seeing in practice. Why is this? I can think of two root causes for this: metrics and ignorance.
I am assuming the sales team has metrics that drive them to sell such as revenue generated or number of new clients. In my experience, sales teams are happy to sell the client whatever solution they want whether they need it or not. I assume they are afraid of losing a sale if they tell a client they need something less or the smaller sale will make the numbers harder to reach their metrics.
What about a metric for the sales team that has to do with the ease of implementation? Or customer satisfaction with the technology installed?
Second is ignorance. Ignorance by the company buying the technology. The company may think they know what they need based on their paradigms. In reality they are just covering up a symptom and not digging to the root cause of their issues.
It could be ignorance of the technology company, also. The people speaking at the conference are Vice Presidents and Directors. Maybe they don’t know what is actually happening in the field. Maybe they haven’t directly observed the behaviors and interactions at the client.
Whatever the case, what is said and what I have observed is not matching. Technology can be a great enabler if we put it in the proper context.