My company is a global consulting company that employs about 5000 people in >100 offices worldwide. We are replacing our old ERP and wondering if any of you have experience with doing an ERP implementation "agile"? What I mean by agile is releasing functionality throughout the migration process and not trying to do a "big bang" cutover on a three-day weekend with all hands on deck. If you have done this, how? Did you migrate functions (like invoicing) one at a time or did you migrate regions one at a time? Did this mean that you effectively had two ERPs for a period of time or did you figure out a way to avoid duplication? If you did this, what was your company's familiarity and comfort level with this kind of "agile" implementation?
Sort By:
Oldest
Director of Supply Chain in Services (non-Government)8 months ago
Hello James, that is kind of you to offer having a discussion. What timezone are you in? We are in Houston, TX (Central timezone).
CIO8 months ago
This is a great question, which I guess nowadays gets discussed in almost all the boardrooms; thanks for bringing it here. I've been involved in multiple global green-filed, brown-field ERP implementations and rollouts, across all big ERP systems i.e. SAP, Oracle, Dynamics 365 etc. etc. so I can speak from my personal experience.Breaking down an ERP system into functionality levels, such as invoicing, during migration can be challenging due to the interconnected nature of processes and applications in the ERP domain. This problem is pronounced if it's a global org with many offices worldwide and many LOBs. The complexity and dependencies within ERP systems often require a thoughtful and strategic approach to ensure a seamless migration.
If a much granular "agile-like" implementation is justified, which most likely may not be the case unless something very unique is on, normally at max you'd break the system at the ERP module level (e.g. purchasing, inventory, payables, receivables etc.) when deciding your rollout approach across various BUs or countries. I've seen such attempts being made by agile enthusiasts, coming from a software engineering background, but then badly failing at it!
The only "slight" exception to this conclusion would be when we have done refactoring/re-architecting of the ERP system itself - e.g. making the applications headless, using microservices architecture/ API gateways, having a separate fast-data access layer/caching techniques outside the core ERP DB etc. - in that case, surely there would be some extra control available, which could then add some additional flexibility during the migration. Having said it will still be far from what our traditional notion of "agile" project delivery is.
Hope this helps.
Director of IT in Energy and Utilities8 months ago
One approach you can consider is called a Global Template and Rollout - We used this for a multi-year, multi-country rollout with an SAP solution. The Global Template is common business processes, configuration items, development, etc. Depending on which business units would like to deploy to production first, the system will be configured to those specific needs, tested, and deployed. Strong governance is needed for these needs, configurations, and deployments to reduce or manage risk. The first BU will have pains with the deployment but will also 'win' with their specific needs deployed and subsequent deployments will benefit from previous BUs deployment, and testing but may lose out on their specific needs due to conflict with previous deployments. This scope had billing, collections, finance, plant maintenance, supply chain etc.We went through a global Workday deployment in multiple phases, which was a little easier to manage and deploy due to the scope being only HR.
Happy to chat if you need further details. I echo the thoughts outlined by Sumeet - spot on.
Retired - Former Executive Advisor, CEO / CIO in Manufacturing8 months ago
This may or may not be relevant to your task, but I thought I would share. Once upon a time I had the opportunity to talk with the CEO of a major EPR vendor. I posed questions as to the cost of these system, migrations, upgrading, deployment time, etc. His response (as best as I can recall): “Everyone thinks their ERP is unique, so they pay me to modify the system to operate the way they do things, then pay me again - and their staff - on new releases, and of course all this extra work and testing takes extra time.”
“While some companies have a ‘secret sauce’ build into their ERP system, most do not. So if they took my system as is and invested in the one-time cost of training their employees to use the system as delivered, their system would be ready to use much sooner with upgrades being cheaper and quicker.”
Our organization is ~20,000 people in ~100 countries worldwide. We have been on an ERP journey for the the past 4 years and with another 4 years ahead of us. This effort has seen us doing a consolidation of three large legacy ERPs, each of significant size and scope globally, into a two instance configuration of SAP S4/Hana Cloud - one instance per Business Unit (we have two BUs).
Our roadmap started with the introduction of Ariba in late 2019, Central Finance and IBP in early 2020, and then followed by regional deployments in North America (2021) and EMEA (2022). We were doing a system / technical upgrade in 2023 and then moving to a LATAM deployment (2024), followed by APAC (2025). That will round out a greenfield approach one of our two BUs. The other BU will be more of a brownfield approach, carrying over differentiating customizations from a legacy ECC environment into S4/Hana Cloud. That effort will be 2026 and 2027 to close out the program.
Also of note, we have 12-18 Tier II ERPs that are not substantial to our revenue or transactional volume that are left out of scope mentioned above.
Re your Q: We accomplished much of work during peak of COVID meaning we accomplished Discovery, Design, Build, Test, Deploy, and Support in a largely remote/virtual capacity. I would still consider this a traditional approach and not agile. But it was also not Big Bang - heard around the world. We went with a regional approach. Throughout our regional deployments, we have maintained the legacy system(s) and used our Central Finance capability (see above) to handle financial and street reporting, a big advantage and enabler.
RICEFW control remains the focus as scope is king/queen/jester.
Happy to discuss in a call, if learning more from our journey would help you.