How does the adoption of business intelligence (BI) and scorecard processes impact the lines of sight inside a manufacturing organization. Join us as Mark Lack, manager of business intelligence, Mueller, Inc. traces the implementation path of Mueller’s leading-edge BI strategy.
Made Possible By
Sponsor
BlackLine Does your finance department remain bogged down in the trenches using spreadsheets to accomplish complex accounting and finance tasks? It’s time to reinvest your people’s time in high-value activities and enter the age of modern finance. Learn more. Visit www.Blackline.com
“Once you can show people what they don’t know and they can use that information to make good decisions and help their part of the organization, at that point people will sign on and be much more forthcoming in assisting you.”
The following is an edited abstract from the CFO Thought Leader podcast featuring Mark Lack, manager of strategy analytics and business intelligence at Mueller Inc., and Jack Sweeney, co-host of CFO Thought Leader.
CFOTL: How did you go about examining your system to find and fix the root causes of some 3,000 instances of damaged material being shipped to clients?
Lack: In that situation we started by saying, “What’s the problem?” The problem is feedback from customers to our sales organization that our material is consistently arriving damaged – not big material, it was small pieces of material that prevented our customers from finishing their jobs. And so this was a very intense conversation we had on how do we fix this problem. You begin by looking at it.
If things are damaged once they get to the customer – we put it on flat bed trucks and ship it all over the country – if it’s damaged when it gets to the customer then we need to look back and say, “Was it damaged when it left here?” And the answer was no. So we knew it wasn’t happening in the manufacturing process, and you isolate that. So it must be in how we transport it to the customer.
As we started looking at it, we were about to buy a new piece of packaging equipment, saying, “Okay, we’re going to bundle this in such a way that there’s no way it can get damaged in transport.” We were about to buy it when the CEO walks into my office saying, “Hey Mark, I just bought SPS [supply chain software] for you. I think I’d like you to look at this data before we make this purchase and determine very quickly what the real problem is.” He was thinking, do we need to wrap or package every single piece? Or are there only certain pieces we need to package? What is it that we need to do? Let’s get down to some detail on this. He’s thinking we have all this data, why don’t we do the analysis?
I worked overnight and the software was great. It did all the heavy lifting for me. I looked at three million rows of invoice transactions over a period of time and I took the number of damage instances that we could identify during that time. I found that there were 3,000 out of that three million. Three thousand is a lot of instances but over three million it’s a very statistically insignificant number. Though statistically it was insignificant, that doesn’t mean the customer still didn’t have a problem we needed to fix.
You could look at things by saying, “Well, we’re 99 percent effective. We can pat ourselves on the back for that.” But the customer still is being inconvenienced. What is nice about big data is that we can then look down even deeper, and we came to find out that most damages, a majority, were special requests by customers. That was ah-ha! It was over 70 percent. So we looked at the 70 percent of the 3,000 damages to special requests.
That was interesting because we have mostly manufacture stock items that go on buildings or roofs. But these were special requests. As we got into it we realized that when a customer called and said, “Hey, I’ve got a problem with this,” we’d just call it damaged and remake it. So from the selling process, we were remaking product or having damaged product that was measured or manufactured incorrectly based on incorrect specifications. We started looking at this as a transportation material protection issue, and it really became a sales process in how we collect the information from the customer.
We couldn’t have been further from the real issue. We had a problem, but it wasn’t the problem we were trying to solve. That’s when we approached it in a completely different way than where we had begun.
CFOTL: What kind of advice you can give to finance executives out there who are leading these types of initiatives?
The following is an edited abstract from the CFO Thought Leader podcast featuring Mark Lack, manager of strategy analytics and business intelligence at Mueller Inc., and Jack Sweeney, co-host of CFO Thought Leader.
CFOTL: How did you go about examining your system to find and fix the root causes of some 3,000 instances of damaged material being shipped to clients?
Lack: In that situation we started by saying, "What's the problem?" The problem is feedback from customers to our sales organization that our material is consistently arriving damaged – not big material, it was small pieces of material that prevented our customers from finishing their jobs. And so this was a very intense conversation we had on how do we fix this problem. You begin by looking at it.
If things are damaged once they get to the customer – we put it on flat bed trucks and ship it all over the country – if it's damaged when it gets to the customer then we need to look back and say, "Was it damaged when it left here?" And the answer was no. So we knew it wasn't happening in the manufacturing process, and you isolate that. So it must be in how we transport it to the customer.
As we started looking at it, we were about to buy a new piece of packaging equipment, saying, "Okay, we're going to bundle this in such a way that there's no way it can get damaged in transport." We were about to buy it when the CEO walks into my office saying, "Hey Mark, I just bought SPS [supply chain software] for you. I think I'd like you to look at this data before we make this purchase and determine very quickly what the real problem is." He was thinking, do we need to wrap or package every single piece? Or are there only certain pieces we need to package? What is it that we need to do? Let's get down to some detail on this. He's thinking we have all this data, why don't we do the analysis?
I worked overnight and the software was great. It did all the heavy lifting for me. I looked at three million rows of invoice transactions over a period of time and I took the number of damage instances that we could identify during that time. I found that there were 3,000 out of that three million. Three thousand is a lot of instances but over three million it's a very statistically insignificant number. Though statistically it was insignificant, that doesn't mean the customer still didn't have a problem we needed to fix.
You could look at things by saying, "Well, we’re 99 percent effective. We can pat ourselves on the back for that." But the customer still is being inconvenienced. What is nice about big data is that we can then look down even deeper, and we came to find out that most damages, a majority, were special requests by customers. That was ah-ha! It was over 70 percent. So we looked at the 70 percent of the 3,000 damages to special requests.
That was interesting because we have mostly manufacture stock items that go on buildings or roofs. But these were special requests. As we got into it we realized that when a customer called and said, "Hey, I've got a problem with this," we'd just call it damaged and remake it. So from the selling process, we were remaking product or having damaged product that was measured or manufactured incorrectly based on incorrect specifications. We started looking at this as a transportation material protection issue, and it really became a sales process in how we collect the information from the customer.
We couldn't have been further from the real issue. We had a problem, but it wasn't the problem we were trying to solve. That’s when we approached it in a completely different way than where we had begun.
CFOTL: What kind of advice you can give to finance executives out there who are leading these types of initiatives?
Lack: The first thing everybody says is, "Oh, I embrace change. I love change." But the real answer is – and this is anecdotal, I don't have any stats to back it up –we don't. As much as we may profess to like change, we don’t. And so whenever you begin a process of recording or highlighting information that people haven't seen before that affects them, they take it personally.
What's going to happen is, anecdotally, or our gut feeling, or we've always done it this way, that’s a huge barrier to success in any new initiative. And with data and processes around data there's really no difference in that sort of situation. So what I would recommend is what I had to do in a lot of ways. I had to perform black ops.
I didn't get a whole lot of support at the beginning from the organization because they thought, “Oh, here's an analysis, why are you crawling through my data? What are you looking for?” In reality, I needed to understand their processes so I could feed the information back to them so they could understand their processes better and then make improvements. I had to show them things they didn't know. I had to take the age-old wisdom of what we thought was the case and then use the data to show this is really what the case is. Once you do that, once you can show people what they don't know and they can use that information to make good decisions and help their part of the organization, at that point people will sign on and be much more forthcoming in assisting you.
What I'm describing was 10 years ago, when I first started this process. Now I'm the information guy. People come to me, "Hey Mark, I need some research done on this. Can you get this for me?" With our business intelligence systems we're deep into this. Absolutely I can get you the answer. And so I went from being an adversary to a trusted confidant and a trusted friend. The data and the information that I provide is only there to help them. It's not there to affect them or change them, it's so that they can do their job better.
That's one thing to do and, two, ignore your critics. People will say, "Where did you get this data? Is this the same that my data over here says?" We all have our different sets of data. Some people track data by hand in a spreadsheet or in a notebook, others have it in the system. So what we said was, if it's not in our system, we're not going to recognize it.
The next thing is if your critics are going to come and say, "Look, our information here says this. This information I've been keeping over here separately says this." Well, if your data is not in our system we're not going to recognize it. If that data is important to you, you need to put it in the system, we'll help you put it in the system. The other thing we find is that information is power. So when critics look and say, "My data says something different," if your data does say something different and it's important, then let's share it with everyone.