What is Truth? Or, what does all this Data in my SPM System Really Mean?
Posted by: David Kelly on Sep 15, 2010
An SPM system can be one of the most complex systems in a company’s business environment because it solves one of the most complex problems a company has. The system’s job is to help align sales force behaviors with the company’s strategic goals. Good data – about the payees, about the company’s business drivers, about the plan elements like quotas and rates, and about the sales events – is critical to the process. Sourcing and maintaining that data is a significant challenge faced on every SPM project. Where the data is suspect – due to inaccuracy, untimeliness, or incompleteness – it puts the effectiveness of the entire SPM program at risk; the Payees begin concentrating more on making sure they’re being paid (at least) as much as (they think) they deserve and less on selling.
Quantum physics aside, let’s consider it a Law of the Universe that when you know two “facts” about the same thing, those facts probably ought to agree with each other, or at least, not disagree with each other too much. This puts us in the position of wanting to have different systems in a company’s business and IT infrastructure all agree about the facts of an event as much as possible. When multiple systems track the same event, but each has its own rules and ways of representing it, you open the door for disconnects.
As an example, your CRM system has the Sales Rep’s best guess about what the revenue for a potential sale will be. The system in which the order is booked will have an event (or several) that looks a lot like the event in the CRM system, but which could well have different values, dates, or rules applied. The fulfillment or supply chain management system might treat the business event completely differently (Widgets are out of stock until next month and will be shipped separately), and this might (or might not) be reflected in the invoicing system. Then G/L gets its hands on the financial side of the event (can’t recognize the revenue for those Rugalators until we get the acceptance doc from the customer). The odds are that some of these systems don’t play and share well with each other. But these are the systems that could be feeding events to the incentive compensation management system. So what is the “truth” of that sale? Ask the sales rep, and she will tell you it’s the number she entered in the CRM system, and what’s up with the stupid commissions system that it can’t even pay on the right amount?
In a way, the truth doesn’t matter, so long as we can find some version of reality that we can all settle on. If you have a nice chunky data warehouse that we can agree is the single source of truth (regardless of what the source systems say), it makes it easier to calculate, pay, report and justify incentives. But if the source of truth is disparate upstream systems, yellow stickies and voice mails, it becomes harder. Maintenance and synchronization of shared data becomes an important architectural consideration for bringing an incentive compensation system online. If shared data can be edited in one system, then all the other systems that use that data must be notified of the changes as well if the systems are ever to be reconciled. So the point to all of this is that your compensation plans are not necessarily the hardest part of your SPM implementation. The SPM system has tentacles that touch most systems in your company, and the interactions between them bring challenges that must be addressed as thoroughly as the comp plan “math”. Otherwise, truth can become a pretty slippery concept.
--------------------------
Author: David Kelly
David Kelly is an ICM Solutions Architect with Merced Systems. He has more than a decade of experience in translating ICM business requirements into maintainable, high-performing systems for many companies across various industries. He can be reached at david.kelly@mercedsystems.com.