Transcription
A few years ago, the grocery retailer, Littal, had a $600 million SAP disaster. How is this even possible, and what are the lessons we can learn from that? That's what we'll talk about in today's video. My name is Eric Kimberling. I'm the CEO of Third Stage Consulting. We're an independent consulting firm that helps clients throughout the world with their digital transformations and their ERP implementations.
Littal is a big grocer based out of Germany, and they have 12,000 locations over 30 countries throughout Europe and even the United States. Very large organization. And in 2018, they went through an SAP implementation. They spent $600 million on this implementation, and it was a complete disaster.
Before we jump into why this project failed, let's talk about why we categorize this project as a failure. Well, first of all, and probably most obviously, the fact that they spent $600 million on the implementation. That in and of itself suggests that something probably went wrong. I know Littal is a big organization, but that seems excessive to spend $600 million on an SAP implementation. But perhaps even more damning is the fact that the project failed. They couldn't use the software the way it was deployed, and after spending $600 million on it, they abandoned the SAP system and reverted back to their legacy system. So, by all measures, this qualifies as an unmitigated disaster. And so what I want to do in the rest of this video is talk about why the project failed, what some of the lessons are that you can take away from it.
Before we dive too far into today's content, I want to share a little bit of information about Third Stage Consulting and who we are. Third Stage Consulting Group is an independent, technology-agnostic provider of consulting services to help clients through their digital transformations. We help with digital strategy and software selection, as well as implementation planning. And during implementation, we provide services related to program management, organizational change, business process improvement, as well as enterprise architecture. These are just some of the services we provide. We have offices in North America, as well as Europe and Asia Pacific. So if you'd like to learn more, I encourage you to check out our Resource Center, which includes a number of resources that will help you through your digital transformation, and you can access that for free using the QR code here or the links below. You can also reach out to me directly if you'd like to discuss your digital transformation and brainstorm ideas on how to improve where you're headed on your journey. Now let's jump back into today's [Music] content.
One of the biggest issues that Littal appeared to have in this project is that there was a resistance to change relative to what SAP provided in terms of business processes and functionality. One specific example that's apparent in the public record about this failure is that prior to the SAP implementation, Littal had valued their inventory based on what they purchased the inventory for. SAP, on the other hand, the version they installed, based it on the actual retail value of the inventory—so two completely different ways of valuing inventory. Now I'm not going to debate in this video which method of product costing is right, whether it should be based on purchase price or sales price, but the point is there was a big disconnect between the way Littal operated and the way SAP operated.
Now, of course, Littal had a couple different options or ways they could handle this. They could have chosen a system that supported the way they really wanted to do the inventory valuation, which is based on purchase price, or they could have forced their organization to change to the purchase price inventory valuation and basically gone through the organizational change efforts to ensure that people could adapt to the software. But what they did instead was sort of the worst of all worlds, which is they customized the software. So they tried to change SAP to fit the way they had done things in the past. Now maybe the old way that they had valued the inventory was the right way or the best way for them as an organization, but it could also be that they were resisting change. They might have been resisting the fact that SAP did things differently, and they just didn't want to change the way they did things. And in any given implementation, you're going to run into disconnects like this, but the key is to recognize what's really important to your business and what don't you want to change, and what are the things that you do need to change or you should change because there's no point in recreating the wheel when software maybe does things a little bit differently than you are doing them today. So there's no one-size-fits-all right or wrong answer when it comes to this, but resistance to change and the effect it has on the overall implementation of something that's very real, and that resistance to change and the after effect and the things that they did to adjust to that resistance to change were things that caused this project to spiral out of control, to take longer than expected, and also to cost a lot more than they ever [Music] expected.
I mentioned earlier about how there was a change resistance, or resistance to change, as it relates to the way Littal's legacy systems work versus the way SAP worked, and that led to customization. And customization is another big problem that the company had, not just with this one example that I gave a moment ago, but in general, there's just a lot of customization that the team chose to undertake as a result of their implementation. Now anytime you're implementing an off-the-shelf system like SAP or any of the other leading ERP systems in the marketplace, there's a certain amount of base functionality that the systems have. There's a certain amount of configuration and personalization you can do with that software, but you want to be careful not to completely change or break the way the software is built. And that's what happened with Littal—is they customized so much that they ended up breaking the system and creating a lot of other issues on the technical side that were very hard to work through. This increased the risk of the project; it increased the cost; and it also increased the timeline that it took to deploy the technology. And not only that, but what it does too when you customize the software as much as Littal did is it sort of traps you into that software longer term, and it makes it very hard to switch away from that software. In fact, we're seeing that exact same thing with other SAP customers we work with right now where they have a legacy SAP system that was highly customized, and they're afraid or can't move to S/4HANA because they don't know how to untangle all that customization, that custom code they developed in SAP years or decades ago. So this is certainly something that Littal fell into the trap of, and it's something that contributed to their overall failure.
The technical resources that a software vendor or a system integrator is going to bring to you are probably going to be the most expensive resources on your project. On an hourly or per-person basis, it's just going to cost a lot of money to bring these people in, and you do need a certain amount of outside expertise, outside technical expertise that you may not have internally. But in the case of Littal, they over-depended on outside consultants and outside system integrators, largely because they didn't have the skill set or the capacity internally to handle a lot of the work that they needed to do. Now again, you do need to rely on outside consultants and outside resources to bring in the competencies you don't have, but there's a fine line there. If you go too far to the extreme of just completely outsourcing the project to a third party, which it sounds like is what Littal did, that's going to lead to a lot of failure issues. You're going to run into cost overruns; you're going to run into a lack of transparency and accountability on the part of the system integrator; and ultimately, you, the implementing organization, are not going to have ownership and control over the project if you let your system integrator manage the entire thing. And Littal, from what I understand, just didn't have the capacity or the time to spend a lot of time managing those different work streams at the system integrators we're working on, and with that open checkbook that led to a lot of budgetary overruns and time overruns along the way. So it's really important as a takeaway here that you find that right balance of leveraging outside consultants and outside technical implementers, but don't rely on them so much that it blows your budget and it makes your team sort of in this learned helplessness mentality that leads to a lack of ownership of the [Music] project.
One of the root causes of this failure at Littal leads to their internal executive team. There was a lot of turmoil amongst the executive leadership team at the time they were going through the SAP implementation. There was turnover on the team; a lot of new team members came in at the executive level, and that created a certain amount of inconsistency and misalignment amongst that internal team. And when you have that level of inconsistency and misalignment at the top ranks, that's going to trickle down to your project, and it's going to trickle down to the front lines during a transformation like this. So you have shifting priorities, have a shifting goal line as far as what it is that this project should look like as a result of the fact that your executive team is turning over, as in the case of Littal. And even if you don't have high turnover at your organization, it's really important that you make sure your executive team is all on the same page with what exactly this transformation or this project means to your organization, and it's really important that those executives also make tough decisions that need to be made as part of the implementation. And I'm not talking about simple yes-no types of answers of do we customize or not, or do we stay on budget or do we not. The questions and the answers that need to be asked are not that simple; they're more like questions around how much do we really want to standardize? Do we want all 12,000 stores, in this case at Littal, do we want all 12,000 stores to operate the same? Do we want different regions to operate independently or separately from the parent company? Those are big strategic decisions that only executives can make, and if you don't have clarity on that, you don't have alignment at the top, you're leaving your SAP or your ERP project team out to figure it out on their own, and they're probably going to have to guess what they think is right, which is probably not going to fit what the organization wants or needs. So it's really important to take away and learn from this that your executive team is aligned before you start the implementation because if you spend time making key strategic decisions all along the way while the meter is running on these expensive outside vendors and technical consultants, your budget's going to go way over; you're going to delay the project; and you'd be much better to slow down the implementation, make these key decisions up front, get that alignment, then start the implementation.
When we testify in court cases involving SAP failures, one of the questions we often get asked on the stand in court is, "Does SAP work?" Oftentimes, there's finger-pointing at the product, saying the product didn't work; therefore, the project failed; therefore, the operations came to a complete halt, and that sort of thing. And most of the time, we find that SAP, or any other ERP system for that matter, gets wrongly blamed for the issues that happen in a project like this. SAP has been used by some of the world's largest organizations for decades now, so the software works. It may not work the way you want it to; it's not perfect; there may be things that you want to change or that you wish SAP did differently, but the fact of the matter is the software does work. The question becomes, does it work for you as an organization? And just as importantly, does the implementation work? Are you implementing the product in a way that's going to work for your business? Are you navigating those decisions and those change management issues and those operational optimization issues and the internal alignment issues? Are you navigating all that stuff effectively? None of that stuff has anything to do with SAP, but yet SAP oftentimes gets blamed when something goes wrong on one of those other fronts. So it's really important to recognize that you need to make sure you've got the right product, first of all. The product has to fit what it is you're trying to do longer term, and once you've done that, you also need to make sure you implement it well and effectively.
So these are some of the lessons and takeaways from this mass disaster at Littal. I'd love to hear your feedback. What do you think went wrong here? What stands out to you the most as far as this particular case study and why the project failed? I'd also love to hear if you've had any similar battle wounds or lessons that you've learned from implementing SAP or any other ERP product for that matter. And also, I encourage you to download our guide to successful S/4HANA implementations. If you're looking to implement the newer version of SAP's S/4HANA, this is a guide you don't want to miss. You want to read this; it contains best practices and lessons to ensure that your successful in your S/4HANA implementation. And by the way, this guide is not sugar-coated. We're not here to tell you how awesome SAP is; we're here to share with you how to make your project more successful. You can read that guide for free on our website by scanning the QR code right here or you can go to the links below. So hope you found this information useful, and hope you have a great day.