An On-Premise ERP Upgrade Horror Story (and a permanent solution!)
Ok, so the upgrade was not a total horror story. As on-premise ERP upgrades go, this one went fairly well. The company is a mid-sized enterprise with a moderate level of system customization. Compared to other upgrades, this one was in the middle in terms of complexity and risk.
The upgrade project lasted approximately ten months. The project was well staffed with functional and technical experts and an engaged user base. The project ran like an upgrade project should as we hit key milestones for development, testing and training. Overall, the project was going well.
So why did the project sponsor, say “I never want to do another ERP upgrade project ever again”?
• Mysterious Performance Issues. We tested the application at production level volumes for all major interfaces and processes ran at or better than the production run times. After go live, key processes that ran in minutes on the old version were running for hours. What happened? It worked in test, and we hadn’t changed any code. We called our talented Database Administrator (DBA) in to help resolve the issue. The DBA worked closely with the ERP software/ database vendor, as well as the infrastructure team. He was stuck and so were we. After nine days of discovery, someone suggested that we try and switch the Dirty Data Trust Factor Switch (not the real name mind you) from on to off. And it worked! The project sponsor asked naively, but insightfully, “Why would we ever need to know what this switch does?” Good question– it should have all just worked, right?
• The Long Weekend of Angst and Hope. The project ran for ten months. We did design, development, testing and training. Then came the go live weekend. The 120 hour plan was going well until about hour 68. That is when the train went off the track. The process steps that ran in minutes were now running in hours (sound familiar?). Did we have a problem or not? The upgrade scripts are long and complex. We ended up finishing the upgrade at hour 114, eating into every bit of buffer that was built into the plan. The project sponsor quietly noted, “Wow. We would have been in serious trouble without that guy.” Good point, why does it take so much effort, specific expertise and faith to upgrade your financial applications?
• Lots of Work and No Real Value Delivered. During the upgrade, our sponsor noted that so many of the company’s resources were working on the project. About half way through the upgrade project, our sponsor asked about the value we were gaining from the upgrade. Although there were some noticeable benefits in several process areas, like collections, most processes would remain pretty much the same. This legacy on-premise ERP had been around for decades, and the upgrades became less and less impactful in terms of value. The project sponsor once again asked an innocent, but spot on question that all CFOs and CIOs should be asking, “So why are we doing this project?” The answer was simple, though unsatisfying– because we have to keep up with the ERP software vendor’s release to stay on support.
• Is this the latest version of the software? As mentioned previously, the application spanned not only finance, but most employees. We were doing one of our training sessions for these users. We covered the new process and what was changing. At the end of the session, one user asked–“Is this the latest version of the software?” Everyone chuckled, and I assured him it was. But why did he ask the question in the first place? He was asking the question as a consumer not a transaction processor. He wanted the application to look, feel and interact with him like other applications do in his daily life. He wanted it to be easy to use and accessible not only from his desktop but on his mobile device. The on-premise ERP software vendors seldom deliver ground breaking innovation in their releases. The reality of on-premise old ERP is that they have a hard time innovating. Their code is complex and built on an “upgrade” approach that just adds fixes on top of fixes on top of fixes. They can’t move fast enough to keep up with the pace of technology.
“The 120 hour plan was going well until about hour 68. That is when the train went off the track. The process steps that ran in minutes were now running in hours”
And now the rest of the story . . .
After upgrading the financial system, our client had a new challenge. The same ERP software vendor informed them that they will need to start thinking about upgrading their other platforms. Our sponsor wisely asked, “Is there another way?” Thankfully, there is. Over the past five years, the popularity of cloud applications for finance has exploded. A 2013 Gartner study (Adoption of Cloud ERP, 2013-2023) shows that 47 percent of companies plan to move their core ERP systems into the cloud by 2018. CFOs are moving to the cloud for many reasons–here is why!
1. With cloud applications, you subscribe to an application and focus your efforts and energy on your business, not the technology stack. This means you never need to know about the Dirty Data Switch!
2. The cloud application provider takes care of the technical portion of the upgrades, releasing them two to four times a year. The upgrades take place over a few hours and allow you peace of mind that experts are taking care of the upgrades not only for you, but for all of their users at once!
3. There is some work with cloud upgrades, but at a fraction of the cost and effort. Your focus is on understanding and deploying the new features, completing regression testing, and making sure your interfaces and reports still work (they should!). You measure the efforts in days and hours, not months.
4. Innovation is constant. The cloud applications are based on new technologies that enable innovation. They are often built on open standards versus proprietary languages and third party add-ons. They are built for how we work today (mobile), not how our parent’s worked!