In leveraging the cloud’s economies of scale, EPM presents unique opportunities and risks. The biggest risk occurs when the migration is just about moving EPM to the cloud.
Of all the applications that could move to the cloud, you might think EPM would offer the greatest financial return. And you’d be right. Enterprise performance management goes to the very heart of why cloud computing was invented: to boost performance and lower costs. What cloud computing accomplishes by sharing computing assets on a massive scale, EPM accomplishes by the intelligent application of financial assets across the enterprise. EPM empowers by virtue of its ability to connect data and people across silos — an ability cloud computing can greatly magnify as a common, scalable space where all those connections happen with optimum efficiency.
But there is a risk EPM efficiency won’t improve after migrating or might get worse. That happens when migration teams ignore special factors that determine how well EPM performs in the cloud — in which case they can easily make any of five mistakes:
Running EPM in a silo. If EPM’s advantage over previous financial software is that it unites data and people across silos then running EPM in a silo defeats the purpose of EPM. That is why you will typically find that on-prem EPM has been carefully wired to other applications, such as ERP and CRM. The mistake is to break these connections when you move EPM offsite. How and where these connections are reestablished — cloud app to cloud app or cloud app to on-prem app — is obviously a more complex question than just how to move an app to the cloud. Every cloud provider employs its own mechanisms and rules for how this kind of connection takes place, how it is made secure, and how it is managed. Those mechanisms and rules then must be applied both on the EPM side and on the side of every app or data store the EPM software talks to.
No special financial accounting expertise. It is obvious from the previous paragraph that migrating EPM to the cloud requires special expertise. But besides the integration challenge just discussed, another challenge is that EPM is complex financial accounting software. Just at a basic level, migration teams would be hard pressed to know if the migration had not somehow broken the software if they did not have a thorough knowledge of what the software is supposed to do. But to truly leverage EPM, the migration team’s financial knowledge can’t just stop at financial accounting. They must also bring insight into how the EPM software actually boosts business performance. That’s a rare mix of skills.
Not the right service mix. Cloud infrastructure and enterprise application providers both recognize the need to offer customers added value beyond just infrastructure and applications. That’s why they work with migration partners like Strafford — so customers receive holistic solutions they might otherwise have to patch together themselves. These solutions include services like application performance monitoring and health checks, IT and end-user helpdesk support, and application consulting such as on to how build a complex formula, visualization, or link to a new data source.
Lack of accountability. Obviously, when you do work with a cloud application services partner there needs to be clear accountability as to who is responsible for what. These responsibilities should be set forth in easy-to-read documents with clear performance deliverables, milestones, and benchmarks. Where SLAs are concerned you would want to see guarantees for metrics like transaction speeds, application availability, and helpdesk response times. Partners should also provide evidence that promised tasks are in fact carried out and with what results. One example is health checks — a complete inventory of the health status of the financial ecosystem. Another is documentation of the details and results of data migrations and backup/restore tests.
No stakeholder pre-sell. As we have written before, one of the biggest mistakes organizations can make concerning any EPM initiative is not getting internal stakeholders on board first. That goes double when the EPM initiative is migrating EPM to the cloud. On the one hand, stakeholders will probably look forward to the cloud’s on-demand scalability and the potential to do a lot more on their own without waiting for IT. On the other hand, when asked to collaborate in the migration effort themselves, they may resist investing the needed time, data, and functional expertise required to make on-demand self-service work for them. Stakeholders must thus be thoroughly brought up to speed beforehand on how impending changes will support their particular role.
EPM is not your typical application, so moving EPM to the cloud is not your typical cloud migration. Mixing EPM and cloud ultimately compounds the benefits of both, but only if you know how to avoid the risks.