Case Study 10: LeasePlan Paid $100 Million for a SAP System That Never Went Live
International automotive fleet management company LeasePlan has been hit by a massive bill for a failed SAP implementation. LeasePlan has since dropped SAP to pursue an alternative IT infrastructure, citing the “monolithic nature” of the ERP system as being incompatible with its more agile needs — but not before sinking almost €100 million into its SAP efforts.
Established in the mid-1960s, LeasePlan is one of the world’s leading fleet management and driver mobility companies, with 1.8 million vehicles under management in more than 30 countries, and approximately 6,600 employees. Their core business involves managing the entire vehicle life-cycle for their clients, taking care of everything from purchasing and maintenance to car remarketing.
Timeline of Events
At this point of time LeasePlan has offices across 32 countries and is owned by a consortium consisting of the Volkswagen Group (50%), Olayan Group (25%), and Mubadala Development Company (25%).
Each location operates under the same brand, but each country uses its own model to do so.
Alfonzo Venturi, CIO for LeasePlan Australia, explained that every country was basically allowed to do its own thing; run its own IT, and manage its own activities.
“Yes, we all reported up, but we had autonomy to really do what we wanted to. If you can imagine 32 entities with 35 leasing solutions — so very expensive, with no agility at all,” he explained. “Any change would take a long time and it just wouldn’t allow us to do any of the new technology sharing that our customers are wanting today.”
In 2016, LeasePlan, headquartered in the Netherlands, picked up a new 100 percent shareholder in LP Group BV, which represents a consortium that includes Dutch pension fund service provider PGGM, Denmark-based pension fund ATP, GIC, Luxinva SA, and investment funds managed by TDR Capital LLP.
“In all the due diligence prior to the acquisition, they saw that there was a major opportunity in IT,” according to Venturi. “I think they started realising that something had to be done and they couldn’t continue the way we were going.”
This kicked off a large programme aimed at designing and building a Core Leasing System (CLS) based on SAP’s enterprise resource planning technology which was used at LeasePlan Australia since 2010. It was here the trouble began.
Venturi was asked to visit a number of European countries to perform a feasibility study and assess the possibility of putting the Australian-based solution in place.
He conducted a proof of concept for three LeasePlan entities, which Venturi said ticked all the boxes. Following the closing of the acquisition, the new owner wanted to see this stretch to the rest of the world.
Venturi then performed a full assessment of each country and it was decided he would lead the way with replacing the legacy systems in 15 countries in Europe — as a first step — taking the baseline of what he did in Australia and filling in the country-specific gaps.
India-based system integrator and SAP partner HCL Technologies has been brought in as a strategic partner.
SAP will provide a host of solutions to LeasePlan “to support our main operations end-to-end, achieve efficiency and straight-through processing”.
These are SAP Leasing at the back-end, Fiori for user experience (UX), Ariba for procurement, Hybris for e-commerce and product content management, S/4HANA (including for the new insurance business) and Business Objects for reporting and analytics/business intelligence (BI).
The deployment will be done on the Amazon Web Services (AWS) cloud. The Australian operations that already have SAP’s tech deployed on-premise on IBM’s servers will continue to operate as is for the time-being.
The first country to go live is planned to be the head office in the Netherlands, slated for October 2017.
This will be followed by the roll-out of a single instance of the system across 15 countries, mainly in Europe plus Australia (new SAP components, such as Hybris) and New Zealand.
This phase is set to be completed by October 2020. There will be two main deployment stages per year — in April and October. These will be “big bang” go-lives in the majority of countries, with a couple of exceptions where the operations are deemed too big. In these cases, go-lives will be phased by customer segment.
“We will go live with the minimal viable product, and expand functionality at a later stage,” Venturi says.
The remaining countries will follow at later stages as well.
All legacy systems will be switched off.
As the company’s new owners sought to drum up interest in shares ahead of a stock market launch, LeasePlan announced the plans to use SAP to streamline and smooth internal operations across all of LeasePlan’s country organisations, making the group more efficient and lowering total costs of ownership.
When LeasePlan subsequently launched its initial public offering in October 2018, the company repeatedly stated that it had high expectations of the benefits its new SAP system would bring.
This was supposed to be a chief reason for investors to factor in a considerable IT-driven efficiency in their valuation of the lease company. Not all investors however fell for the charm offensive, however.
LeasePlan found investors were unwilling to pay what its shareholders had set as a target, and in the same month it was announced, LeasePlan abruptly called off its initial public offering, blaming the deterioration in “market conditions”.
In the 12 months since the called off IPO, the worst possible scenario has unfolded for LeasePlan. In September 2019, the company finally pulled the plug on the major SAP project. A total investment of €98 million has been deemed unrecoverable and subsequently impaired from the firm’s books.
CEO Tex Gunning in a recent meeting with shareholders said, “The system is not fit for purpose in the emerging digital world. The monolithic nature of the SAP system hinders its ability to make incremental product and service improvements at a time of accelerated technological change. As a consequence, the system is being restructured.”
Instead, LeasePlan will now press forward with work on an alternative IT solution, which it has called a “Next Generation Digital Architecture”. Rather than placing its faith in one supplier from now on, the car leasing company is opting for a combination of best-of-breed third-party solutions combined with a deeper in-house involvement. The company will now leverage leading off-the-shelf solutions for various modules (e.g. contract management, insurance claims, predictive maintenance) and combine them with existing LeasePlan best practices to form its new infrastructure.
This approach is, according to Gunning, better suited to the “digital revolution” taking place in the global lease industry. It will allow for a more scalable and flexible IT infrastructure, smoother product deployments and updates, and will enhance integration with third-party systems to speed up innovation.
What Went Wrong
Since LeasePlan is a private company, and currently there is no public lawsuit going on, it is hard to find information about what actually went wrong.
But in conducting research for this case study, I found a number of warning signs that should have tipped off the company, its team, and its consultants that this was going to be a very difficult project.
Here are a few of the warning signs, which were found in articles with various quotes from LeasePlan executives touting the merits of the transformation:
> The company was consolidating 35 systems into one, which is typically a Herculean task in and of itself.
> The company failed in a past SAP implementation at one of its affiliates, which took 4 years to implement and another 3 years to “settle down” after go-live.
> The company’s CIO touted its “extremely aggressive plan” for rolling out the new technology, which is typically not a good thing.
> LeasePlan was pursuing a big bang rollout strategy for most countries it operated, which creates a high-risk profile for most organizations.
> The team acknowledged that change management would be difficult, but that they had it under control with a “comprehensive change management” plan.
How LeasePlan Could Have Done Things Differently
Consider your industry-specific needs and solutions
Fleet leasing is a fairly unique industry. Standard, off-the-shelf ERP systems are less likely to address the variety of distinctive needs of companies in this space.
You may also be in a similar industry. For example, digital transformations are typically more difficult for industries and companies such as these that are unique:
> Financial services
> Complex, engineer-to-order manufacturing
> Utilities and energy
> Any industry with field services
> Fast-changing industries
> Companies that are actively disrupting the status quo in their respective industries
Be skeptical of concepts like SAP’s Model Company, Oracle’s Unified Model, NetSuite’s Suite Success and other ERP software industry hoaxes that may mislead you to unrealistic expectations.
Industry best practices baked into software don’t exist. Neither do silver bullet implementation solutions. It is important to plan and execute accordingly.
If you fit into any of the categories above, it is less likely that a single-vendor solution is going to be the best fit for your strategic and operational needs. It is more likely that a best of breed approach with multiple technologies is going to be a more viable option.
Align technology with your business model
Digital transformations are too often misaligned with an evolving business model and overarching corporate strategy. It is nearly impossible to succeed in this type of situation.
Not only is LeasePlan in a unique industry, but it was also actively disrupting its industry with new platforms such as CarNext.com and its Car-as-a-Service business models.
This entrepreneurial spirit and new ways of doing business are typically not playing to the strengths of S/4HANA. This misalignment likely created problems during the transformation.
It is important that you understand your business model and define how your digital transformation or project will support that bigger-picture strategy. If you don’t see or don’t define the connection for the rest of your team, then you’re not ready to be starting a large-scale transformation.
Be a responsible buyer of technology
Being a responsible buyer of technology and outsourced software development services, and working well with suppliers during projects are crucial skills for any organization.
Yet, the absence of those skills explains more project failures in third-party projects than any other factor. You will find some prominent examples of these among these and other project failure case studies.
Some may argue that suppliers should have all the skills required to make their projects a success, but any company relying completely on the skills of a supplier is making themselves dependant on good luck.
If you are not a ‘responsible buyer’ then you risk not spotting when the supplier and/or the project is failing. Things will always start to drift and get off track. That’s a normal part of complex business transformations like these. But the key is how we identify risks, mitigate risks, and take action when warranted.
That could mean firing our systems integrator before we are $100M in the hole. It could mean that we pivot on our strategy when we see that the original plan isn’t working. Or it could mean that we divert resources from technical workstreams so we can double-down on our organizational change management strategy.
A responsible buyer of third-party systems and systems development will have excellent knowledge, understanding and experience in defining, planning, directing, tracking, controlling and reporting systems development projects. They will know what should be done, when, why and how.
In many projects the supplier should be running the above-mentioned processes as part of helping a buyer achieve their target business outcome (after all, the supplier is expected to have done a great many projects of this type). However, this does not mean that the supplier will, in fact, be doing all of those things.
That’s why it is vital that the buyer themselves knows what needs to be done.
In most large technology projects, it is excellence in program and project management that is the crucial factor in determining success — not knowledge of technology. This is often true in situations when, for example, a project is being carried out across an organization (especially a global organization); across a group of companies in collaboration; or on behalf of a central marketplace and its participants (such as a stock exchange).
In large business-critical projects neither the supplier nor the buyer should be doing any aspect of the project in isolation, as doing so will increase the risk of failure. This isn’t just a need for transparency, it is a need for active communication plus active confirmation and verification that messages have been received and understood.
The following three excuses for total project failure will never work in court:
1) “I was drunk,”
2) “I thought the buyer or supplier knew what they were doing,” and
3) “I thought the buyer or supplier was doing it, not me.”
If you are the buyer and you do not have all the necessary skills and experience to be able to define and control important projects (which is perfectly understandable as in most companies they don’t happen very often), there is an easy fix for this problem: Hire a very experienced interim executive to act on your behalf, even if the supplier will still do most of the project management and other work. You can delegate authority for doing the project management to the supplier but you cannot delegate responsibility.
Responsibility for the project — including responsibility for it failing — always rests ultimately with you, the buyer.
Other Project Failure Case Studies
> For an overview of all case studies I have written please click here.
Originally published at https://www.henricodolfing.com.