Congratulations! You’ve achieved your goal of bringing EPM into your enterprise. But that doesn’t mean you can now stop getting stakeholder buy-in for your EPM initiatives.
As we wrote in a previous blog article, you will need to get internal stakeholders on your side if you want to achieve successful EPM adoption in your organization. As we said then, that outreach calls for a lot of active engagement with those outside of finance and IT. But that engagement doesn’t end once stakeholders start using the software. In fact it becomes even more critical. That’s especially true for software running in the cloud. One of the cloud’s great advantages is that adoption typically requires much less of a financial commitment, particularly up front — so it’s a commitment that is easier to walk away from if stakeholders aren’t happy. Now that EPM is here, people’s expectations need to be met, and managed. And that is an ongoing process.
It starts by knowing that now is when your stakeholder relationships are most at risk.
What Happens After the Sale
Ask any successful salesperson and they’ll tell you that the selling job doesn’t end once the contract is signed. (It’s one reason customers are so frequently asked these days to fill out satisfaction surveys — to keep them as customers.) The risk of a “return” is always greatest within the first few days or weeks after purchase and, although it diminishes over time, never completely goes away. Loyalty, on the other hand, usually takes time and must be earned. That’s an especially challenging and critical task when it comes to internal EPM stakeholders, for several reasons:
- The “customer” is less “sold” to begin with. Some of the stakeholders who are most dependent on EPM success may not have even known what “EPM” is. They may not have even been looking for this type of a solution until you brought it up. So they’re less naturally committed to EPM to begin with. Which means they’re more likely to join a chorus of EPM naysayers if issues crop up than if they themselves were EPM enthusiasts. They’ll just know something is wrong and they really won’t care why.
- EPM cuts across the org chart. Making stakeholders happy (or coming to their aid if they’re not) is made harder because EPM, by definition, is an enterprise-wide product. So it’s not just about business people not being tech savvy or tech people not being business savvy; it’s also about manufacturing not being sales savvy, legal not being logistics savvy, HR not being engineering savvy, and so on. If a key promise of EPM is to drive enterprise performance by connecting operational to financial data — you have to deal with the fact that operational data and financial data are not monolithic. Across the org chart, some data is more relevant and relatable than others. Making those evaluations and connections is only just beginning the day the EPM system is turned on.
- There’s a learning curve. If you’ve ever waited five years or more to buy a new car you know what we’re talking about. Sometimes the easiest way to use new technology is by forcing it (if you can) to work like old technology. That usually also means giving up some of the new technology’s benefits. (A classic case in the EPM realm is Excel, which is why a good EPM offers an Excel-like interface even though spreadsheets may not always be the best way to conceptualize complex data.) Of course, if people are working harder to do things after EPM adoption the same way they did them before, it is understandable why they might ask, “What’s the point?” It is also understandable why they might soon lose patience if a good answer is not quickly forthcoming.
So Choose Your EPM Partner Carefully
Keeping stakeholders happy in the days and weeks following an EPM startup requires more than just paying attention to them (although that’s a good start). Fundamentally, it requires skills and tools most organizations don’t have in-house. Take the learning curve challenge. Your EPM can offer intuitive self-service features that enable stakeholders to empower themselves. However, self-service requires not only the right technology but also knowledge of what types of self-service best supports different user stories. A partner that has enabled many similar user stories in the past can optimize self-service more quickly and precisely for your users than can a partner that has not.
Likewise for the two other challenges — building loyalty among less committed users and bridging knowledge domains — both of which also demand highly specialized skills and experience. That’s in terms of both domain expertise — as in finance and technology — as well as teaching skills.
Great technologists are not always great communicators, so you need some who are.