Mark Stacy is a highly regarded SAP Supply Chain consultant who helps customers find and plug the profit leaks in their Procure to Pay process. We’ve worked extensively together building metrics and dashboards for manufacturing companies and I’m excited to have him on the show.
Mark shares with us
- Building reports that people care about (and use!)
- Establishing quick wins to build momentum towards the big goal
- Focusing on the need instead of the ask (and why it’s so important)
- Choosing between a top-down versus bottom-up approach for introducing change
- Knowing when specifications are not enough (and how to get around them)
Connect with Mark Stacy
Welcome to Experts & Influencers, the podcast where we go behind the scenes of enterprise projects, and help you untangle some of the expensive problems we deal with. Here’s your host, Hau Ngo
Hau Ngo: Hi and welcome to Experts & Influencers, the podcast that takes you behind the scenes on projects in large companies. Today, I’m excited to have my friend and business partner Mark on the show to talk about building metrics that drive process change in your supply chain.
Now, Mark Stacy is a supply chain consultant who helps the company identify inefficiencies in the pay process, and he has a special ability to speak to different teams in our organization, analyze our data, and then translate what he has found in dollar amounts, so that management and leadership can understand the bottom line. Mark, welcome to the show.
Mark Stacy: Good afternoon Hau, thanks for having me!
Hau: It’s great to have you. Mark, just to give everyone a bit of background, we worked together before in the past doing some purchasing metrics for a building materials company. One thing I saw early on was your reputation among your peers, you had this reputation of being the guy on the spotlight projects, you were always the guy the executives cared about. Was that intentional? How do you all into that pattern?
Mark: Sure, you develop a reputation over time and those things do land in your lap. But developing that reputation is the hard part, and I think for me, the biggest thing, or the way I found my way on those things consistently, I made sure I was always working on what my customers, my client, cared about the most.
I very rarely would go in and have a solution and be stuck to it, or have some – it’s so common in our industry to develop a process or have some new technology or bell and whistle we want to unveil. But then, we roll it out and the adoption level is next to nothing. We’re always confused, like “oh, it’s such a wonderful new tool, a new dashboard, a report,” but no one is using it. We tend to make the mistake, not a mistake, but wondering why that’s happening. For me, I always approach everything…I never want to build something no one is going to use.
So, if you’re building things people are going to use to build things they care about, I typically am only building what they’re asking for. There are a couple different ways to get your clients or customers to do that – to get you to build the things they’re excited about. A great example is with our current project, our current engagement we’re on right now with an electronics manufacturer, and, I mean, if you think back how to where we started two months ago on this discussion. They wanted to engage with us, you were in the earliest discussions, talk through the progression of where we were and where we are now.
Hau: Sure. I think a lot of independent consultants and agencies can relate to the long sale cycle it takes to figure out where you can best help a certain customer. This current one we’re both serving, I think I started the outreach maybe a year ago where the client asked me, “hey, there are some metrics we’d like and there’s an app building company that has these metrics out of the box. Should we go with them?” And I’d say, well you could, but, those metrics may not be specific to your company or how you do things.
We had that conversation, I’d periodically check in on them. And the funny thing is, during those 12-month follow-up cycles, I was getting a better sense of where they were technically and I had a sense of where they may need help. The funny thing is, a couple of months ago, the manager reached out to me and said “okay, we have an initiative that we need better metrics. Great. They have a budget. Super. But they didn’t know what to do.
I was talking to the IT manager who is very proficient in this space about how we can help his business counterpart? How do we deliver metrics that matter to them? I think that’s very interesting because we’re having to have conversations with two different groups of people. If you recall, during our proposal process, it took almost two months. That scope changed several times depending on who we spoke to.
Mark: It did. Thinking back on it, even at the time, we recognized, they clearly weren’t sure what to work on. They had already run into this issue, they’d spent time and money building reports, and no one was even looking at them. I think they’d already been burned that one time and they were being extra cautious that they were working on the right thing.
That’s the beauty, and I think where we can perfectly highlight our process. We have an ability to come in and, in the scenario, we eventually said you know, let’s stop worrying about the end game, let’s just find a way we can quickly help you right now, because once we’re in, we’ll be able to give you the recommendation you’re looking for.
So, what did they do? They brought us in. They asked us to look at these two very, very specific issues that had been long-standing and a thorn in their side for years. They said we’ll give you a month, come in, take a look at this, you’re going to work with a small team, help them resolve this issue.
Our mission was very pointed and quick – we jumped in, and we used that small window to implement this process I’d been using successfully for many, many years, which is, okay, we’re going to come in, work on what looks to be 1 percent of the whole view. With that, we’re going to be able to understand the processes and the issues, upstream and downstream from this very small window that are causing problems here.
From there, we started reaching out to different teams. Just like we did with this current engagement, we start talking to the procurement team, the manufacturing team, the shipping guys, the people managing sales documentation, and just in the context of the tiny role, you start hearing common themes.
It’s funny, cross-functionally, people tend to know where the bottleneck is, what the big problems are, what the big opportunities are. So, so often, you hear a common thing about what’s causing the problem – why are we doing this stuff outside of the system? Why can’t we pinpoint the problem? In this particular case, the common thread has been they have no idea what their lead times are. They don’t know what their customers are expecting. They don’t know how accurately they’re hitting customer requests or fulfilling orders. There are so many questions they can’t answer because at a baseline level, they don’t have simple common metrics we tend to see across the industry.
With that very small window, the first two weeks we already had a very solid idea for A) not only where we as an organization could provide the most value and identify what work we could do that would highlight our client with the most opportunity to save money, we also had a clear definition of what it is that matters most to all the people we’re working for. That’s such a huge thing.
We were asked to come in and work and implement a new bell and whistle, but without the why we’re doing it, or the understanding why someone would care about what we’re going to build, you can expect the adoption rate to be zero. That’s how the process is different. We really get to the core of what our customers need, what they care about, what’s going to provide them with the most value and then we leverage.
It doesn’t need to be fancy at all, most often. We were building queries in ECC, twenty-year-old technology, and think of the praise we’re getting. In the most archaic, generic form of a solution, because it hits to the core of what they need
Hau: It’s actually funny you mention this archaic, twenty-year-old technology, because in retrospect, you know, one of the things I like to do is prototype quickly, get feedback and pivot if we have to. I do recall I spoke to one of your users on the new report you made, we call it Dashboard, but let’s be honest, it’s the ugliest thing you can see. It’s not Fiori, it’s not mobile responsive, it’s just ugly SAP GUI right?
Whenever I speak to the people on that team, it’s useful. Are we on the right track, does it help you day to day? Their eyes light up. It would take them an hour or day or more, and every time the data changed they had to redo it again. The fact that you don’t have to spend a lot of money –
I recall the initial conversation with this one client, they were looking at anything to help them out. They were looking at predictive, cloud, real-time data replication, and I think strategically, that’s where they wanted to go. I think in the bigger sense of things, we can help them get there. But our initial question, after the first few calls were “okay, we know where you want to go, but how do we get you there?” what is the first step, what are the building blocks, the foundational metrics you need, and how you stand in comparison to your peers. One of the first questions was what does your inventory look like? How are you doing on a day-to-day basis, and I don’t remember if they were able to give us a number, do you?
Mark: They weren’t. They were flying blind. It was pretty obvious early on. It gets to another really important point about the process. You can build reports and use the greatest tools and technology and do all kinds of flashy things, but if you’re building it for a user group that isn’t asking for or doesn’t care, or maybe eventually they will care –
I think another good example is we have clients who want to optimize inventory or some process. I’m happy to build things like that for them, but only when they’re ready. So often, people want to implement some new technology or new process without first gaining momentum or getting the right people to care about it.
That’s another key thing, a different part of our process. We’re not just going to build that final report you’re asking for, that’s a waste of our time and our money. I want to build impactful reports and tools for our clients that really affect change.
The first thing you have to do is back away from the end game, like what you’re thinking is where you want to be. And you strategize and develop a path to get there. Without leadership support or the people whose jobs are going to be changing at some point – you have to find a way to get them to care about what you’re doing.
I call it the spotlight type report or set of metrics, that really opens people’s eyes to say “hey, I know optimization is a buzzword, but here’s a report that shows you what you’re missing out on or losing because you’re doing things incorrectly.” Yeah, it might cost a bit of money, and it might cost some time and take more energy, you might have to hire another person, but if at the end of the day you can look at the metrics and say I’m going to take those steps because we’re’ going to save 10 percent, those are the types of things that the people who can drive change care about.
The trick is, more of an art than a science, the trick is to build reports in such a way that really highlights the opportunity in terms of real dollars. When senior leadership sees dollar signs, they drive change, they push for change, they want to be updated on a weekly basis, and when senior leadership cares, that flows down to the people who are doing the real work – manufacturing, purchasing, shipping, customer service people. Senior leadership pressure on them to change is really important.
It’s the only thing that really works when it comes to changing a process or affecting real change, you can probably elaborate on it, too. Time and time again, you build the right report and you know it’s good because the people you’re eventually going to work with ask you for help. It’s like, “man, my boss calls me up and tells me I have to do things differently, how can you help me do that?” and that’s where those optimization type reports start to come into play.
You build out those things and dashboards, the end of the day, you have all these users who would be angry with you, you’re making them do things differently, but because of the way you’ve driven the change from the top down, you’re almost a hero. Like, you came in and saved the day, thank you so much. It’s a weird thing. If you do it wrong, or the traditional way, the reaction is often the opposite.
Hau: Early in my career, I was on these large, multi-year implementation where I was building in the dark. Right? Because there are so many layers between the business and the analyst and the project manager, that when the reports get to production, it’s a year or two later and it’s targeting the wrong thing. It’s built for the wrong purpose.
Where I’m going with that now is that, if you were to remove technology, if you take the technical pieces aside, don’t worry about how the report looks, but instead focus on what the ultimate business problem that you identified and having those conversations to make people care. I think that’s the bigger thing we’re trying to touch on here.
I feel like a lot of times when we come into a customer for the first time, it’s almost like business therapy, right? The first set of conversations we have, it would always revolve around the theme, let’s just air it out and tell us what’s wrong, and tell us where we can be the most impact. Then, based on our experience, we can guide them on where we should start and how it maps into the overall strategic plan.
I think that’s something most teams don’t think about. The inter-team communication. Seeing things from the inner circle. I think most likely IT, and I think this is pretty common, they say, the most common complaint is I built it the exact way I said it, and they’re asking for a fourth thing, and I’m not going to do it four times, even though I’ve done it to spec, it’s never right.
On the business side, they say it’s mostly right, but I don’t trust it. The numbers are off, the data is off, the metrics are off, and I can’t tell you why. There’s too much data. I don’t trust the data. It’s like you need a, not an impassionate, but impartial third-party to come in like a marriage counselor and have those two teams speak to each other, wouldn’t you agree
Mark: For sure. And, it’s funny you say, business therapy, a lot of ways, it’s exactly what it is, especially as consultants, coming in, and impartial party arbitrator almost, and a couple things about that. I think it’s easy for people who are technical to lose sight –
A spec is one thing. A spec is great. A good, solid thing. I think what really provides value is again what sets our process apart. A little more improved. I’m not satisfied with just being told what to build, I want to understand. Through the years of industry experience between us, we understand the process.
We understand SAP, how everything is linked. How the slightest mistakes or shortcuts have this huge effect and can mess things up and force people to do things outside the system when you get to production and sales areas. When it comes to optimizing, those shortcuts, they negatively impact your ability to create anything meaningful.
From a technological perspective, where you’re saying I’ll build the spec, it’s not good enough. It’s never going to be right. If you don’t understand why the data coming into it is bad, you don’t know what to do to change it. We can stop it at the start and say we get where you’re trying to go, but the problem is, this data is bad because it’s not in the system, or non-existent, or the system can’t do what you want.
So, lets’ build this first set of reports to first fix the initial issues that are blocking you from building what you’re asking for. Let’s fix what’s going on in the middle that’s going to be the end of the day report that’s going to give you what you want, and you sort of forgo with that approach. You omit this thing where you don’t trust the data coming in. we never get to that point, because we’re never going to build a report with bad data.
Hau: yep. Perfect. I would say you know, we’re hitting the half-hour mark here.
I’d love to get your take on specifically the steps you take when you go into a brand-new organization to identify the metrics that make people care. I know we talked about, making the right people care about the right metrics and not so much about the technology side, how to get people talking and caring together.
If I could get you on a future episode, I would love to dive into the exact step you take that people who are listening can apply in their industry, the steps you take specifically to identify those people, identify the metrics, and how you approach the building process and engagement process for making that change.
Mark: Absolutely, that’s such a critical part of the process of building things that first of all are impactful and correct and that people will trust. Also, just critical part of building the right things. Unless you know what to build and why, you can expect to spend an inordinate amount of time building things people never touch, which is my pet peeve.
It drives me crazy to build things that no one is ever going to use. It’s a black mark. There’s that understanding, that approach, drilling into who to talk to, when and why and how, such a critical part of building impactful and useful reports.
Hau: Awesome. I’m definitely looking forward to that next conversation. With that, Mark, when the show here, if you could tell the folks here where to find you. How can we contact you online?
Mark: Sure, you can certainly find me, Mark Stacy, on LinkedIn. Also, our organization now has a webpage, (inaudible) to see what we’re up to and get some more information about our results, our methodologies, all that good stuff is on there as well. Always look for us at conferences, all those things, whenever a bunch of SAP people gets together, Hau and I are usually around.
Hau: Awesome, thanks, Mark.
Mark: Thanks, Hau.
Thanks for listening to the Experts & Influencers Podcast. Learn how problems are solved at the biggest companies and apply it to your project at expertsandinfluencers.com