When we speak of hard problems in automating variable compensation we are not speaking of cold fusion. Hard problems in variable compensation usually consist of delivering solutions for cases that
1. are outrageously demanding of computational resources
2. have complexity that would shame the famous Rube Goldberg
3. are radically riddled with exceptions
4. All of the above
What follows is a little list, we'll keep it live, of things that have proved difficult. Sometimes there is a best practice (like "Don't do that!") that will save one from the pitfall. Othertimes seemingly not.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
A simple example of a maybe not so hard a problem is the aggregation-drives-rate-selection-to-be-applied-to-rows-that-drive-aggregation. It's the classic Tommy sold 4 million dollars of product, which means he's paid 7%, but we have to stamp each transaction that drove the aggregation with that 7%. There's no way around looking at/touching these transactions twice. It's not like there's any fiendish complexity here initially, it's just a pain. When later we learn that if one of these aggregated elements aggravated the buyer, who returned it, and now Tommy's sales are 3.87 million, and that means sorry, Tommy, 6% is what you really deserved and we will take back the difference and report why. Now it's a world of hurt. We reach out for a merciful and reasonable person to just book the delta in the current period - but, oh - to grasp air.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Here's one that you don't come across every day but that will toast the socks of most VCATs. Let's say that a VCAT is a Variable Compensation Automation Tool. Conceptually it's simple as pie. Maybe I'm a sales executive who has become convinced that new customers are key to increased market share and total sales. I don't really want to sell less to my current customers, in fact, I'd be delighted to sell more, but I don't want to pay accelerated commission for upselling/inside sales. I mandate therefore that each existing customer shall have their own quota, and that rates shall decelerate once the quota for the customer is attained. Further I mandate, because not all things are equal, that rate of this deceleration may vary by customer. Hehe. You know these things can get worse too. Perhaps attaining quota for 75% of a rep's customers triggers a special annual bonus, or, worse, modifies the schedule of deceleration. Who needs celery anyway?
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
When we speak of the troubled and monstrous however, it is the word "Retroactively" that stirs fear in the righteous. Everything that has ever been is, of course, true - until we redefine it and delta the new definition of history against the the previous defintiion of all history. We'll stick with the new definition of all history until next month, when we do it again. Maybe we'll look back a year, or two. Retroactivity is the ultimate rathole you hope to avoid. It's better to hunt for it, of course, and to make sure to what extent the business has commited to specific systemic behaviors regarding it. I've worked with customers where the raw CPU demand of their regularly schedlued retroactive processing was a perceptible stress on the local power grid. Can't turn on the AC now. Most of all, in these cases, it's about understanding the classes of retroactive change that may occur. Is it merely that compensible events may be re-stated? Can a rep's plan or plan variables be re-stated? Do reports look the same in cases of re-statement?
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Tell us a story. Write to This email address is being protected from spambots. You need JavaScript enabled to view it.. We'll publish it, with or without attribution, as you prefer, as long as it seems a true and valuable caution. Thank you.