In March of this year, I posted a blog titled “Process Work v. Knowledge Work – The Emergence of Performance Management“.
There are various labels applied to the current Performance Management market such as: Enterprise Performance Management [EPM], Corporate Performance Management [CPM] and Business Performance Management [BPM]. For clarity and simplicity sake, I am going to use the acronym “EPM” to represent the category going forward.
Two of the application leaders in the EPM market are Oracle and SAP and they define EPM accordingly:
Oracle. EPM applications are a “broad range of strategic and financial performance management processes …[sic] that drive profitable growth by delivering predictable results, improving transparency and compliance, and increasing business alignment.”
SAP. “Enterprise performance management starts with aligning operational plans, budgets, and resources to strategic objectives. It involves providing every information worker with contextual access to data they need to make faster, wiser decisions.
While the goal may be for EPM to involve “every information worker”, the reality is that EPM applications are primarily process-oriented and targeted to relatively small operations teams who are tasked with planning, modeling, budgeting and measuring the business. With few exceptions, EPM solutions are not designed for the Front Office LOB.
Directionally, though, applying Back Office-like performance management techniques to the Front Office to enable better business decisions by LOB is a tremendous opportunity. Using advanced mathematical modeling and statistical analysis with historical, current and forecast data rather than relying upon qualitative assessments just intuitively makes sense.
For example, here are some common business decisions that are typically made by individuals in the LOB using ‘best guess’ practices:
- Sales Rep – What is the price I should quote and negotiate that is most likely to be approved by the customer and simultaneously maximize revenue for my company and my commission check?
- Sales Manager – What forecast should I submit for my team based upon the current deals in the pipeline and the historical close rates of my sales reps?
- Marketing Manager – What is the best price for my product line based upon the overall market forecast?
- Customer Support Representative - How long should I remain on the phone with this customer to address their concern?
To better address these business issues, a new class of realtime, analytical applications that use predictive analytics and statistical modeling techniques are beginning to appear in the Front Office.
These solutions use the data created through business and market transactions (e.g. SAP, Oracle) and enable the LOB organization to make much better business decisions that align with overall corporate objectives. To distinguish these revenue-oriented applications from their Back Office EPM brethren, I apply the label “Revenue Performance Management” or RPM.
Below are six primary areas of difference between EPM and RPM application requirements.
F&A/IT v. Line of Business
In the Back Office, F&A and IT own the resources and make the decisions that affect how the company manages and reports the business. Traditionally, these organizations have the people with the technical skills, domain expertise to use development tools to configure and customize and manage the systems and applications, and the budgets they need to run business systems such as: accounting, order management, payroll, tax, etc.
In the Front Office, Line of Business managers are in charge but in many cases neither they nor their organizations have access to capital budgets nor the technical personnel and/or expertise required to design, deliver and manage the applications they need to run their organizations. For example, Front Office groups such as Marketing, although potentially responsible for millions of $ in demand generation investment, have for years had to rely upon arcane tools such as email/spreadsheets to manage their function.
Cost Centers v. Revenue Centers
In the Back Office, the primary objective is cost containment. Every business process is analyzed to identify and remove overhead. Once an optimal method is determined by F&A/IT for a corporate business process (e.g. Create Purchase Order and Secure Approvals), an “internal policy” is generated and a corporate-wide mandate issued to drive compliance. Few, if any, are allowed to deviate from the policy.
In contrast, the Front Office is primarily focused on revenue generation. Since most companies can’t mandate revenue from their prospects/customers, they must incent the Front Office organization to identify and capture as much revenue as it possibly can. “Incentive Compensation” plans, bonuses, SPIFFs, etc. must be designed with the intent to find, secure, optimize and reward revenue production.
Static v. Dynamic
In the Back Office, every effort is made to stabilize business processes so that they don’t change and generate unnecessary overhead and errors. In the Front Office, change is the operative word. Customers change. Competitors change. Markets change. Territories change. The Front Office of a company must be able to quickly adapt and adjust to change. To address this side of the organization, applications must be easy to implement and manage and be extremely flexible. Relying upon an over tasked or in the case of small companies, a non-existent, IT organization is a non-starter.
As I stated in a previous post, I believe the primary reason Salesforce.com has become so successful is that it was the first company to recognize that with “internet-based computing”, the term used at the time, you could virtually eliminate IT. They pioneered the concept with SMBs and as their products have matured – enduring skeptics – they have gradually worked their way into the LOB organizations of large enterprises.
It is indisputable that Tom Siebel and Pat House, co-founders of Siebel Systems, identified and created what we now all know as the CRM market. However, Marc Benioff was shrewd enough to recognize that his delivery and business model was a better way to deliver CRM solutions to SMBs that have minimal IT support and LOBs inside larger companies who are tired of waiting on IT.
As described in Clayton Christensen’s book “The Innovator’s Dilemma”, Salesforce.com may not have created the CRM market but its disruptive innovation has exploited it.
Realtime v. Batch
The Business Intelligence market emerged out of the requirement for operational teams to be able to use transactional data to generate better business insight. Where online transactional processing (OLTP) was optimized to enable applications to quickly capture and view transactions, for reporting and analysis a different database structure/format was required. This led to the formation of online analytical processing (OLAP) and formed the basis of the Business Intelligence market.
The EPM market emerged in the Back Office out of OLTP/OLAP applications as companies realized they needed new applications that enable them to better plan, model and set budget targets for the business.
In a similar way, the RPM market is emerging in the Front Office. However, there is one very big difference between EPM and RPM.
With EPM, applications are designed more often around batched data. While response time is important, if a report takes a while to run it may be inconvenient but it isn’t usually catastrophic to the business. Not so, with RPM applications. Here, the interactions can be in realtime and application performance is always critical. For example, if a customer asks a sales rep a question on the phone, the sales rep needs to be able to reply quickly. He can’t wait on the application .
Since the Front Office has few IT resources, RPM applications can’t rely upon IT to configure, manage and maintain them. They must be highly flexible, configurable; they must be SaaS-based. Consequently, the database and analytical architecture for RPM applications must be completely different than their EPM counterparts.
Voluntary v. Involuntary
If you perform a Back Office and/or operations function it is likely you must use an application to accomplish many, if not all, aspects of your job. For example; processing payroll, generating a purchase order, configuring an order, identifying a performance issue on a network, doing an audit, etc. These all require you to engage with an application to accomplish your task.
In the Front Office, other than a few applications (e.g. email), you may only interact occasionally with an application to accomplish your functional objectives. As a result, it is critical that Front Office applications are easy to interact with and generate easy to identify advantages to the individual using them. Otherwise, they won’t be used. RPM solutions, while needing to be quite sophisticated underneath, must have a very simple User Interface and must be able to be administered and managed by the Front Office organization on its own.
Subjective Data v. Objective Data
By far, here is what I believe is the biggest difference between the Back Office and the Front Office.
With relatively few exceptions, the Back Office is driven by objective data. A Purchase Order is either approved and signed or it isn’t. An entry into the General Ledger has either been made or it hasn’t. Revenue is either recognizable or it isn’t. And, these decisions can be made at a relatively slower rate than the Front Office.
In contrast, the Front Office is largely driven by subjective data and the decisions must be made much more rapidly to respond to immediate customer and/or market demands. What should the sales forecast be? How many widgets should I build? Are my sales territories optimized to maximize revenue? Am I spending too much/little money on support? Today, the answers to these questions are determined by largely by human judgment.
The CFO abhors “guesses” and wants to make decisions based purely upon facts. The CSO (Chief Sales Officer) lives in a world of ambiguity and must rely upon a series of educated guesses. If the CFO of a public company certifies the S-1 is correct and it isn’t, she might go to jail. If the head of Sales gets the forecast wrong, she might lose her job but isn’t likely to go to jail.
Therefore, the goal of RPM is to enable the Front Office to convert what has been primarily been subjective data into objective data so that the Back Office and the company overall can make better business decisions.
I have put my money where my mouth is with respect to Revenue Performance Management. I have made several investments to date in companies that have built realtime, analytically-based solutions targeted at the Front Office:
- Marketo (www.marketo.com)
- Cloud9Analytics (www.cloud9analytics.com)
- SignalDemand (www.signaldemand.com).
Each of these companies has designed and is currently delivering SaaS-based Revenue Performance Management solutions. Marketo, in fact, was the first to position itself as a Revenue Performance Management company. Each is using analytics to help LOB organizations make better business decisions by converting what has been highly subjective data into objective data.
My underlying going-in thesis is that the world doesn’t necessarily need more transactional applications or business intelligence (reports/dashboards) for operational teams. Those markets are defined and owned by well-known incumbent brands.
The big market opportunity is in Revenue Performance Management; using applications that utilize data created by OLTP/OLAP that enable LOB organizations to make better decisions. By definition, these must be SaaS-based. Therefore, for the reasons I’ve discussed in previous blogs, it’s not going to be the incumbent brands that can capitalize upon this opportunity.
Only time will tell if I am right.