Leveraging an ERP migration to achieve maximum impact as a data team

Learnings and challenges from turning a complex project with a tight deadline into an opportunity

Within the wide spectrum of migrations encountered in our day-to-day operations in technological enterprises, few match the magnitude and complexity of an ERP (Enterprise Resource Planning) migration. ERP is a software system that enables companies to run their core business, such as finance, HR, manufacturing, supply chain, services, procurement and others. Adevinta chose SAP S/4 HANA as a Finance CORE to integrate O2C, P2P, and R2R (order to cash, purchasing and collecting) areas of the company. This required a shift in business models within a company spanning various brands and sectors such as Adevinta (umbrella of Spain brands Fotocasa, coches.net, Infojobs and milanuncios; leboncoin in France; mobile.de and Kleinanzeigen in Germany; Subito in Italy and Marktplaats in the Netherlands).

How did we fit into this complex migration project?

I was the Data Product Owner of the team responsible for consolidating financial and sales data. We were entrusted with the task of maintaining all our local analytical data after migrating from a local ERP system in Spain, Navision, to a unified multi-country model solution with SAP tool.

Our journey was not merely a technological transition, there were many lessons to be learned and knowledge to be gained through this long project. Now I can share what we learned should you or your team ever find yourself in a similar project or situation.

Why was this project such a big challenge?

A migration of this type always involves new challenges. Many of these issues are not considered at the beginning of the project by a team focused on data consolidation:

1. Revamping Financial Infrastructure: The transition to SAP represented a profound restructuring of Adevinta’s financial backbone. The development and implementation of the new SAP S4HANA platform, spanning three countries, was entrusted to an external international consulting company. This magnified the project’s complexity because the consultants did not have a good knowledge of our company and processes — we had to start the project from scratch. Moreover, conducting operations in English, within teams that usually work in Spanish, introduced an additional layer of complexity.

2. Convergence of Systems: One of the significant hurdles faced during the migration project was converging disparate ERP and CRM systems across three different countries. Each country had its own local ERP system, and integrating them into a unified platform within a tight timeline of four months posed substantial challenges. At the time of the migration, we had two different CRMs in Spain (CRM2015 for two of our brands and CRM365 for the other three), forcing us to maintain a local system to integrate orders. This allowed us to meet operational deadlines but also generated future technical debt. Ensuring seamless interoperability, data consistency and functional alignment across these diverse systems demanded meticulous planning and coordination.

3. Maximising Data Value: The third challenge we faced was creating a valuable domain data product from raw operational data of a system like ERP, designed to fulfill several business processes and functions, which requires extensive domain expertise. We were not autonomously consuming the data directed from the tool, so we had to align with the SAP tech team and the Enabling Platform team in charge of the company’s middleware. We needed to understand which API events were needed, which fields and dictionaries to use, the granularity of the data, and the frequency of these API events to maintain our local reports and KPIs.

4. Commitment to a Year-Long Project: Over the course of a year (from October ’22 to October ‘23), sustaining team morale and commitment while staying engaged in a complex project can be challenging. The duration of the project, coupled with the intensity of the migration process, may strain team members’ motivation and focus. Additionally, the need for extended hypercare (extended support and dedication after the end of the migration) adds to the pressure of ensuring smooth transitions and maintaining operational stability. Keeping the team motivated, committed, and connected throughout the project’s duration is crucial for success.

5. Convergence of migrations and deliverable dates in parallel with other projects: At the same time, our data team found themselves immersed in migrating our data infrastructure from Azure to AWS. Undertaking two significant migrations in parallel posed a technical challenge to the team by having to learn new tech features in the new platform. On the positive side, this convergence, coupled with not being tied to a legacy platform, allowed us to consider a new path for data and build our layers according to the project. While the major migration projects were happening, we also managed other deliveries or BAUs for different stakeholders, so it was more important than ever to prioritise the management of the PO and create a specialised squad for each relevant topic.

All these challenges forced a multidisciplinary collaboration, which extended beyond the external consultants’ firms, to encompass various internal teams. These included the local ERP and CRM teams, sales administration department, financial, planning analysis department, and multiple other data teams that need the data we will provide. Each team played a crucial role in ensuring a smooth transition and maintaining data integrity.

How did we manage to do this?

Our journey unfolded through several significant milestones that I believe every project, no matter its size, should have. I truly believe that if one of these steps were missing, the project would not have ended successfully. In fact, I have to highlight that the most important one, contrary to popular belief, is at the beginning of the project. This is when you are gaining context, recognising the realities of the situation and creating a relationship with your users and stakeholders:

1. Assessment of the Previous State (AS-IS): We meticulously examined our existing processes, workflows, data usage, KPIs and dashboards with the help of the other data teams involved. Also, we initiated conversations with our users and stakeholders to understand their day-to-day needs and the possible gaps they had in the process. At this point, we detected inconsistencies in some of the current data or lack of value, so it was an opportunity to refine our data practices and enhance analytics.
2. Understanding the new operational mode (TO-BE): With SAP as our new backbone, we delved deep into understanding the operational changes it brought. We had to consider the mandatory fields and concepts in the new system, detect local needs and loss of detail in granularity, plus any new functional data or flow, etc.
3. Solution: Identify gaps, define workarounds, and design the new workflow: Bridging the gaps between the AS-IS and TO-BE states was essential. It involved extensive alignment with stakeholders and creative problem-solving. I can confirm it was the longest step of the project; even after delivery, we had to revisit this activity. Because a significant number of decisions had to be made that impacted the final product, I strongly recommend documenting each one, regardless of how small or common sense it may seem at the time.

1. Implementation and testing: We developed and rigorously tested the new workflows and models in a controlled environment using this phase to raise any incidents, ask for any missing fields, or request integration changes to our local or cross-functional teams.
2. Deployment: On the day of go-live, we deployed all developments and meticulously validated the system’s performance against expectations.
3. Documentation and onboarding: Documenting all the functional aspects of the process relevant for understanding the data, the new data workflow, the data product built, and training other teams was crucial to ensuring smooth adoption by users. Additionally, we had a period of hypercare where we closely monitored all integrations and reported the first revenue closing month. At the same time we, we kept and continue to keep our stakeholders informed by automating all possible messages through Slack.

What did we learn, and what would I have done differently?

My advice for any other Product Owner or Product Manager who faces a project of these characteristics is the following:

• You and your team should have an End-to-End process understanding and local business knowledge. This means listening to and accompanying the key persons of the local process as they work. You will also need to gain a comprehensive understanding of the sales and billing processes and the financial intricacies. Lack of this knowledge can result in incomplete implementations.
• It is essential to do a robust AS-IS analysis at the beginning of the project. It helps identify critical capabilities early on and prevents oversights.
• Stakeholder engagement and teamwork: Involving all stakeholders — from CRM managers to end-users — fosters project success and post-launch sustainability. Creating good communication between the different teams is crucial.
• Detect main indicators to analyse the business and therefore, design the model according to it. These KPIs helped us identify the main dimensions that we should create and avoid superfluous metrics and information
• Minimise technical debt — otherwise you will pay a high cost after the project delivery.

If I could start this project again, I would place more emphasis on these topics from the beginning to get a better recognition of the project:

• Involve the sales force in the project from the beginning to make them aware of the challenges and risks involved. In this way, we will manage expectations and be prepared for the possible effects it may entail. In our case, sales force KPIs and customer relationships were affected due to incidents in the different steps of the integration. The change could have been better received if stakeholders had been aware of the project’s possible effects.
• Another critical point in this type of migration is how important it is to keep local talent with knowledge of the business present in all parts of the integration. These people can define the TO-BE state of the model and raise possible incidents long before anyone else.

In conclusion, Adevinta’s ERP migration journey with SAP S/4 HANA stands as a testament to the importance of thorough preparation, inclusive stakeholder engagement and unwavering commitment to tackling large-scale technological transformations. Each step was instrumental in ensuring a successful outcome, from assessing the previous state to understanding the new operational mode and bridging the gap with innovative solutions.

I hope the lessons learned from Adevinta’s journey serve you as guiding principles for companies embarking on similar endeavours, emphasising the importance of adaptability, collaboration and communication.

Acknowledgements:

Thanks to my soulmates in this journey, Meritxell Gonzalez and Jordi Escola and to the rest of my team, Marc Benavent, Kevin Vazquez, Xavier Aznar, Jose Aguilera and Daniel Ramirez, together we make a uniquely magnificent team. This project could not have been successful without the huge support and valuable knowledge of Gemma Garriga and Raquel Benitez, who were always there for us. Also, thank our traveling companions David Nicolau, Romina Gallinal, Jose Antonio Sancho and Rocio De Soto. Finally, I can’t finish without thanking our manager Laura Marques, and the project lead, Cristina Gonzalez, for her unconditional support, trust and freedom of decision they gave us.