Table of contents
Key Takeaways
- Many companies have yet to make the transition to real-time, responsive, agile systems.
- Companies must identify core critical business capabilities, risks, and failure points.
- Focus first on a good definition of the problem you want to solve and the business outcome you want to achieve.
With more than three decades of supply chain and digital transformation experience at Procter & Gamble and General Electric, Mark Dorfmueller talks with TraceLink’s Roddy Martin about the importance of operational resilience.
Transcript:
With more than three decades of supply chain and digital transformation experience at Procter & Gamble and General Electric, Mark Dorfmueller talks with TraceLink's Roddy Martin about the importance of operational resilience.
Roddy Martin: Mark, welcome to the TraceLink thought leader series. I look forward to this discussion with you. Procter & Gamble, as you well know is rated very high in my best practices database, in every sense. Simply because the transformations that P&G brought about 10 years ago, many companies are still trying to figure them out.
I think the secret sauce was the way that P&G looked so holistic and comprehensively at all the changes. They weren't technology projects disconnected from people projects. I'm not saying the world was perfect, but I think you were way ahead of many of the other transformation efforts I've seen.
In particular, what I'd really like to focus on is the idea that agile is back in vogue. There's obviously the side of agile that says we can do software development in an agile way, but we can also do lean and supply chain, and manufacturing in an agile way. That's more focused on resilience of business operations.
One of the changes that that P&G spearheaded in the industry was flipping from supply‑centric to shopper‑centric demand‑driven. That's not a trivial transformation. The systems weren't set up to be demand‑driven, the infrastructure wasn't.
What I'd really appreciate is for you to introduce yourself and talk a little bit about how P&G thought about the enterprise architecture view of this massive transformation, because without the enterprise architecture, this simply wouldn't be possible. Welcome, and it's a pleasure to have you here.
Mark Dorfmueller: Thank you, Roddy. Just a, I guess a short introduction of myself. I spent almost eight years at General Electric, and then another almost 30 years at Procter & Gamble. I've served in a lot of different roles and capacities in that role, including enterprise architecture, but I've spent probably 20 years against supply chain.
Worked in telecommunications and globally running all of their voice, video, and data. I've had quite a deep technology view of things and very specific business capabilities view of things.
At one point, I was even the business architect for the company trying to work through the challenge of: How do we take our big ideas to market faster? It was taking us quite a number of years to be able to roll something out globally, we needed to cut that in half.
To your question about agility, the way I think about agility today is, many large enterprises are really stuck in the same problem still.
They have now put in 50 years of systems of record, if you will, that are built around ERP types of systems that are still operating in a 1960s or '70s mode, meaning that they are still operating overnight, daily, weekly, monthly kind of cycles, where your business in many cases is operating at a much faster cycle.
Many companies have shifted to e‑commerce, more and more of their business is in that space. Yet, they're still trying to operate off of supply chain planning systems in particular, which have really been built in a totally different way.
They're built for batch basically. They're really not built for real‑time responsive agile systems. Companies are acquiring more and more businesses. Those businesses are not operating back in the batch modes.
They're operating really in the 21st century here and being able to respond to the cadence of business with not only your systems, but your processes, is an important aspect of agility.
Not all of your businesses need to operate real time, but many of them do and you need to have systems, both from a technology standpoint, but a business process standpoint as well, that can adjust to whatever the cadence of that internal business is, internal or external.
All of that has to really be designed in a way that's first, focusing on the consumer, whoever that consumer is you've talked about. In our dialogue earlier, we were talking about the patient being the consumer in some of the supply chains that you're working with.
That's your consumer in that case. What does it look like when you're talking about the patient-as-the-shopper, metaphor? What is the translation?
How do you talk about that, and then think about the event to patient to treatment as a value stream versus consumer point of sale back to really manufacturing, to be able to build an Agile System and a Resilient System in that manner is really a challenge with some of the building blocks that are still being offered to most companies?
Roddy: Right. Mark, one of the points, I don't know if you know Mike Whitman, but Mike Whitman comes from J&J. I had him on our LogiPharma panel, and he used to run the Tylenol operation at McNeil at J&J.
He said, "We did a back‑of‑the‑cigarette‑box calculation one day at McNeil, and we came up with the fact that there were 500,000 potential failure points on a medium‑sized manufacturing operation." For an architect, that's a nightmare, right?
There's no way that you can build every possible scenario around 500,000 failure points. That's really, I think, what makes a successful Enterprise Architect at business level or not. You can get mired in the detail and lost in very complicated stuff, or you can take a very pragmatic business point of view and say, "Let's do some sort of analysis and find out where are likely to be the biggest fires that we need to deal with fast."
Mark: Yeah.
Roddy: How do you get the business to think along those lines?
I know there's no magic source but are there any secret things that you found really worked to get the business thinking along the right lines.
Mark: You have to take advantage of, Roddy, the situations that are going to occur. One of the opportunities we had was, there was an incident. It was a fairly big one caused us to have to start to reevaluate the resilience of our business and all the capabilities.
The first question was, "What are the critical business capabilities that we have within in P&G. I don't think that question had really been asked from that standpoint.
It was always asked, prior to that, what are the IT systems I need to have up to keep me running and business criticality was really spent, really defined around the applications, not around the business process.
As a part of that incident, we really rethought and redefined everything around the business capabilities that we needed to keep running. Being able to take an order from a customer was considered a critical business capability, as sort of rationale.
Roddy: Right.
Mark: You should never be in a position not to take an order from your customer was the rationale. We basically said, "OK, we need to be able to take orders. We need to be able to produce product, and we need to be able to ship it to the customer so that it can be sold to our consumers."
We need to be able to then receive invoices and make payments to our suppliers. We need to manage all the master data, so there was a number of things around financial that we had defined as critical.
Finally, there were some things around human capital, if you will. You needed to make sure that you can pay your employees, that you can make sure your shareholders can still execute stock transactions that they may need to do, and that your retirees are supported.
With hundreds of business capabilities, we narrowed it down to 10. Then, we looked at what are the process fail points. What are the system's fail points, single points of failure that you might get into and what are all of the things that you might have to go fix in that case.
From there, it really wasn't all systems. It was as much what's your supplier? What's your materials? Do you have single points of failure there? Any one of those things out of those 10 capabilities would mean our business could not run.
Roddy: What I love about that is the simplicity of it. I mean one of the challenges I found, and you and I have spoken about this quite a few times, is that I would have the board of directors say, "Roddy, I want you to go and do your enterprise architecture stuff, but keep those people out of the room because they confuse us."
I think, unfortunately, I see too many cases where enterprise architecture is turned into a lab experiment. There's reams and reams of documents and specifications and the business says, "Look, just get on with it and make it work."
What struck me as you were telling the story is, "Hey, let's boil this down. This business is not that difficult." Someone takes an order, someone makes a product, someone ships the product.
Let's not over‑complicate it because I'd rather us look at the business in a simple way and identify our risks because we're more likely to see the risks. If we start breaking it down into 500,000 failure points, it's just going to turn into something that kills itself under its own weight.
I know this is an obvious question for you, but what role did the business play in that because I also think that sadly, IT runs off into a corner, and this is not an anti‑IT discussion, but IT runs off into the corner and comes up with these big plans that confuse the business. What wrong did the business play in those discussions?
Mark: It's a very important one because we worked with the supply chain chief officer, the HR chief officer, and our finance chief officer, who happened to be the three people who are on our Business Continuity Team, when any incident would occur.
They're the guys who actually call the shots when something happens. We use them as the sounding board on which capabilities were the most critical because you can imagine, everyone wants to be included. My part of the business is critical too, so they wanted money to be able to do whatever enhancements they want.
They were the ones who got to say, "These are the capabilities we care about, and these are the processes we wanted you to work on and make sure that all the IT in the business process capability, from a process standpoint, all of those single points of failure are really showing up."
We identified, in that scenario, it still ended up being quite a bit. There were over 300 points of failure that we had to deal with just on the IT side and they had some things on the business process side that they had to also correct.
That was how we went about it and they were our sounding board. They were the team that would make the decision because, ultimately, if there was an incident, they had to deal with it.
Roddy: You took the words right out of my mouth. You can't prepare all of this for them, and then expect them to react in a scenario and say, "Hang on, this is not what I would have done."
What you've actually done is crystallized their mindsets around the scenarios that you could codify and said, "Let's build this into this business continuity scenario," so that when you have to flick switches, you're probably going to flick the switches that we'd all spoken about because we hopefully got it 90 percent right.
Where we got it up a little wrong, it's much easier to do the 10 percent. I think the point is a best practice and that is that you cannot do this in isolation of the most senior business leadership that's going to have to respond in a business continuity crisis scenario, because if you do, there's a good chance you're going to get it wrong.
Mark: We did one other thing too, Roddy. We did a lot of work on really resilience, if you will, where resilience was defined as the ability to operate and never go down.
This wasn't about disaster recovery. This was about operational resilience. I don't want to have to execute a disaster recovery plan, not that we didn't have those.
Roddy: Right.
Mark: The investments weren't even on DR. We had a lot of DR. We said, "OK, keep that part going, but what we want to really focus on is I don't ever want to go down."
What do I need to do to ensure that? Will my systems and my processes be able to support that? When you get into that, then it becomes a more interesting question and many of today's, I'll call it systems of record, really are not designed to be resilient.
Roddy: I know it's an unfair question to you and I'm not asking you to name companies, but I mean, do you see anything's really changed in the last 10 years in the companies that you worked for, would see, etc.? Do you see anything changing because I seriously have not seen people stick their heads out and say, "I got this right."
Why is it that I have to use P&G for 10 years as the only best practice example. You've got to see other things happening. Do you or don't you?
Mark: I think Amazon and...
Roddy: Sure.
Mark: There are a couple of others that are masters now in supply chain in particular, but when you looked at process resilience, Roddy, it may be the love for the business that P&G. P&G people feel they are part of the business, that they are the business.
Whether it was keeping an IT system resilient, or whether it was keeping a line on a manufacturing floor, we called it process reliability.
It was really keeping that line up and running, so that you had very few outages and downtimes where you're now putting in MES systems that are measuring microseconds of jams and small variations and fill weights, just real attention to detail to drive value for the business.
That was usually a combination, even on the factory floor, it wasn't just the engineers. Information was important.
It was a collaboration between IT and our engineering organization to be able to collect the data, to be able to analyze, to be able to find the faults that were there, and then be able to build business cases to correct those process resilience issues on the line.
Roddy: What you just triggered in my mind is the smell of P&G. People are at home caring about the business as they are about their jobs, as they are about their products. That is an epitome of P&G.
That is what stands out for me as the absolute shining example on why P&G is such a good caring supply chain organization.
Mark: Yeah, it was not uncommon for any one P&G person to know 3,000 people within the company on it. It's a company of about 100,000, but 3,000 people. They're not in one function, they're in finance, they're in engineering.
We always work together to really solve the problems regardless of what function expertise was needed to be able to do that. Very collaborative. Love the business. They really see their job as helping consumers lives be better. You see the value of that.
Roddy: I'm going to just mention an example of where I sat in the annual reviews of projects that P&G did just to make a point of how integrated it was, just to illustrate the point. I'm going to ask you, it has been a really great session with you, just to highlight the one piece of advice you would give some young supply chain professional who's been tasked to let's come up with a blueprint plan.
We're going to get to that. Let me first make this point that every year, I was invited to attend the P&G project review. I tell everybody, the thing that absolutely stood out was you'd have a project leader, some IT folks, some business process folks, and some HR related folks.
They talk about what NOS this project added to P&G. Not whether the project was finished on time and budget. What did it actually do for the business?
That's an absolute deal breaker in some companies because IT projects are somewhere over there and people projects are somewhere over here and this process changes. They don't seem to bring it together. What comment would you make along those lines?
Secondly, go straight into what's the one piece of nugget advice you would say to somebody on how to think about, "I got to build agility, here's how you need to think about the journey that you're going to take because this is not possible to do overnight."
Mark: For the younger person coming into this, one of the things that I would really want them to understand is focus on the business capabilities that your company has. I don't mean that in a general sense. I mean, if you don't know what those capabilities are, and what those value streams really look like, and who's running each one of those processes and how they are connected, you've got some work to do.
Roddy: For example, and I'm sorry to interrupt you. For example, launching a new product or acquiring a new product in another geography. Those are examples of capabilities. Right?
Mark: Those are capabilities, but they're one.
Roddy: Tip of the iceberg. Right?
Mark: Tip of the iceberg. In the work that I did one, I'm trying to take big ideas to market. The company knew, everybody knew you need marketing. You need brand, you need the innovation, R&D layers in your product supply. Then, the customer, they knew it at that level.
Down deeper, they each one knew their piece of the work that would take them that idea and get it out to the market. Nobody had actually taken the time to map out and understand what the capabilities are, end‑to‑end, from the idea generation all the way out to the customer.
What does that take? What does that look like? Where are the problems in there that are really causing us to take so long to get our big ideas out in the market? You need to have that big view, so that you can focus in on the few things.
There happen to be 40 something processes involved in taking a big idea to market. There were only seven of them that really were causing the biggest challenge for Procter & Gamble to get them out to market faster. [indecipherable 22:02] ended up being the ones that we focused on.
The second part of this, Roddy that I would say is understand the problem. Don't focus on the solution, focus on the problem first and get it defined. Make sure that you have a good definition of the problem, you're working with your executives to understand that, and that you're focusing on the outcome that you want.
It should always have business outcomes, whether that's NOS, or cost savings, or productivity. Whatever it might be, but make sure it has a business outcome.
Roddy: Yeah. That is a very good piece of advice because I do think that was so heavily biased towards buying a solution system. Let's go and buy an ERP system or let's go and buy a planning system. We then become focused on making that system work, not defining the problem that we're actually trying to solve. I mean, that's a really great piece of advice.
As simple as what it may be, I really don't unfortunately hear a lot of people talk in that language. There's teams all over the business looking for new solutions, but not necessarily teams working with the business to really clearly define the problems and the capabilities the business has to build to be agile under of these disruptive scenarios.
Mark: In many cases, I've even seen with all the focus on startups in the past 10 years, many times people are saying, "Here's a startup. What problem can I solve with it?"
You don't want to start there. You really want to start with what's your business problem and then really apply it. Understand what you already have in that space. If you understand the problem, that problem's up against the business capability, what do you have in that space? What problem are you really trying to solve? What do you need new to be able to do that?
Roddy: Mark, on that note, it's really a privilege to have you once again and to talk to you once again and have you on this thought leadership series.
Roddy: There are quite a few ex‑P&G people scattered around like Alessandro De Luca, and Jake Barr, and others. There is a good handful of P&G experience embedded into the series. It's an absolute pleasure to have you. Thank you once again for the time.
Mark: Thank you, Roddy.
Return to: The Patient-Driven Supply Network
