Offshoring Sales Performance Management Implementation Components

Based on my experience and on common sense, there are some project components which are easier to offshore than others.

Requirements and Functional Design

Early phases of a project are more challenging to offshore; these phases include the requirement gathering and the functional planning of the project. Offshoring these activities can be difficult because they require a lot of interaction with stakeholders, users and subject matter experts. This type of interaction usually works much better face-to-face than over the phone.

Technical Design, Implementation and Testing

Once the architecture of the project is established, components of the technical design, implementation and testing phases are good candidates to be offshored. Interaction with project stakeholders will obviously be necessary, but the “what” of what needs to be done should be obvious.

Sales Performance Management Implementation

There are many strategies to leverage an offshore team to implement a sales performance management application. Compensation plans can be divided between on-shore and offshore teams, or both teams can collaborate on all the plans. I prefer the collaboration approach; coordination will be a bit more complicated, but many of the risks will be mitigated. As a result, the onshore team will have a clear idea on the status of the offshore team at all time, and there will be less communication issues such as misunderstandings of the requirement and functional design documents.

Here is a list of several common SPM activities which in my experience are good candidates to be offshored. If the design documents are detailed enough, there is no reason why an offshore team could not work on everything. However, there is probably less risk in offshoring well defined activities.

1. ETL: A large project will use an Extract, Transfer and Load (ETL) tool to move data where it can be used by the SPM solution. With proper access, an offshore team can make a significant contribution to this process.
2. Configuration Management: An implementation is usually carried in different environments; development, various testing envionments, and production. Moving the latest files from one environment to the next can be very time consuming, and often can’t be performed while a team works in the environment.
3. Reference Data: Loading all the reference data including participants, titles, positions, relationships, territories, etc are activities which will not impact the building of plans, until required for testing.
4. Quotas, rate tables and lookup tables: Creating and updating these objects can be a very time consuming activity.
5. Formulas and rules: Sometimes, several formulas and rules which are almost identical to each other are required. Not all SPM solutions have an easy “clone” feature, making this activity very tedious.
6. Processing: Also called pipeline in Callidus TrueComp, with a large number of participants and of transaction (in late testing phases), processing can take up to several hours. It can be very nice for the onshore team to work on the implementation during the day and come back the next morning to find the results ready and analysis of issues that occured.
7. Testing: Testing can be a tedious job. As I discussed before, test scripts should exist which will be executed again and again… and again. Some of the first testing phases such as unit testing and system testing can be almost entirely offshored, but later phases such as integration testing and user acceptance testing are often kept onshore to be able to better monitor quality.

Note: Offshoring all the boring and repetitive activities could have negative impacts on the moral and efficiency of the offshore team, just as it would on any team.

Does anyone have other examples of SPM components which can be offshored easily?

Advertisement

Sales Performance Management Glossary

There is a lot of very specific terminology used in the world of sales performance management. Different vendors may use different terms, so it is important when starting a project to make sure everybody understands what is what to avoid any confusion.

Callidus has an excellent lexicon of incentive compensation terminology. Here are some important terms used frequently:

Bonus: A performance-based reward or payment to an individual, team, business unit, or work force, made in cash, stock, options, or other form.

Calendar: A set of continuous, non-overlapping periods that define when a compensation plan is in use.

Commission: One type of incentive, often expressed as a percentage of sales, gross margin or dollar amounts per unit sold.

Credit: The amount of credit received for making a sale, where revenue is usually the measure for sales credit, although sometimes the number of units or some other measure is used.

Draw: Cash payment advanced against future income. There are two types: non-recoverable and recoverable.

Formula: A method of calculating compensation that relates pay opportunity to performance achievement, generally falling into one of three categories: 1) Unlinked incentive formula; 2) Adjusted-value incentive formula; and 3) Linked-incentive formula.

Lookup Table: Multi-dimensional: Created by the user to store values for use in rules and formulas.

Participant / Payee: Person participating in your company’s variable compensation program.

Plan: A collection of rules that specify how to compensate the participants assigned to that plan.

Position: Defines a specific, unique job.

Quota: A predetermined sales performance goal, expressed as a percentage, percentage change, in absolute numbers, or in units sold.

Quota Attainment: The percentage calculated from dividing the amount of sales credit earned (represented by a performance measure amount) and the quota for a performance period and participant.

Rate Table: One-dimensional: A lookup table used for calculating commissions. The first column in the table represents ranges of quota attainment. The second column represents the pay-out rate for transactions within that range.

Rule: A way to filter and calculate in the form of an “if-then” statement. The “if” contains a Boolean expression that selects objects from the database (for example, which transactions to use). The “then” part contains formulas that calculate and save new values.

SPIF: Acronym that stands for “Sales Promotion Incentive Fund.” SPIF is a loose term referring to an on-the-fly addition to the compensation plan used to motivate the sales force in a particular way by providing additional sales credit or payment for certain types of sales.

Territory: A way of defining which transactions a participant should be credited with. It is usually a geographic area, but could also be an industry or a specific set of customers.

Title: Occupational grouping, such as engineers, systems analysts, etc. Titles are used to group similar positions related by job function across the organization.

Transaction: The original sales data, wich includes sub-line data on an order.

Variable: A placeholder in a rule or formula for a fixed value, rate table, or territory.

Stick to a Naming Convention – It’s not Rocket Science!

Wikipedia has one of the best definitions on the net for a “naming convention”: A naming convention is a convention for naming things. Awesome!

In the Enterprise Incentive Management and Sales Performance Management world, this means naming all plan objects in a consistent way. Naming will vary from tool to tool and there is not a single set of best practices that can be followed. Most vendors provide some recommendations, but it’s up to the implementers to decide which naming format will be used. Since there is no generally accepted “convention”, it may be more accurate to call this a naming strategy.

Why is sticking to a naming strategy important:

Incentive Compensation Management is not difficult. What makes ICM systems complex is the volume of plan elements (plans, rules, formulas, tables, variables, etc..) A large implementation can quickly become a jungle if not everybody agrees on a common way of naming different objects. Not only will it make building and testing the system easier, a good naming strategy will especially be important once the original implementation team is gone and others have to understand the logic of the system. Finally, aside from clarity, a naming strategy will also help search for plan components more efficiently.

Choosing a naming strategy

As I said, since all applications do not share the same objects, and also because each application works differently, I cannot provide a silver bullet for all situations.

Generally, I try to stick to these principles:

• Make the name descriptive
• Use abbreviations to identify object type
• Begin object name with its object type abbreviation

For example, a credit rule could be called CR_AE_description. Some systems could have a direct credit rule and an indirect credit rule; in such case my abbreviation could be DC and IC instead. In some systems I may want to prefix a formula with F (if all objects can be displayed in the same view), if not, then it would not be necessary to explicitly say that a formula is a formula.

Naming of output is also important: The importance of naming an object may be obvious, but in the case of rules, the output of such rule should also be named carefully. A result name that makes sense can often by “Rule name _ result” or something similar.

Getting Started…

It is important to define a naming strategy early on in the project – before any detailed / technical design documents are created. The strategy should be illustrated on one page to enable the implementers to quickly see how to name the different objects. This “page” should be distributed to everyone involved in the implementation and be given to new joiners as well.

The first steps in defining the naming strategy is to find out if the application being used has a set of best naming practices or standards. In the case of an upgrade, it is important to stick to previously used naming strategy.

Happy Naming!

Incentive Compensation Meets HR at The Super Sexy HR Carnival

After missing 34 HR carnivals, I finally contributed an article for the 35th, hosted on Jon Ingham’s Strategic Human Capital Management (HCM) Blog.

My featured article is the recent story “The Saga of Purchasing an ICM System“, describing some of the common issues faced when purchasing and starting the implementation of an incentive compensation management solution.

Visit the carnival on Jon’s blog – it’s filled with very interesting and insightful topics from every area of HR.

EIM Solution Maintainability – Should you care about this?

People often consider buying an Enterprise Incentive Management (EIM) solution based on several criteria including cost, performance, ease of implementation, support, etc. One factor that if often overlooked in my opinion is the system’s maintainability.

What is Maintainability?

ISO 9126 defines maintainability as the ease with which a software product can be modified in order to:

• correct defects
• meet new requirements
• make future maintenance easier, or
• cope with a changed environment

Why is Maintainability important?

The ability to modify a software system is obviously important for any type of system, but it is particularly important for an EIM solution. Why? Because compensation plans, organizational data, quotas, etc typically change at least once a year. Modifying this information is not a task equally easy to perform in all software packages.

How to find out if a EIM solution is maintainable?

Any vendor will say their solution is maintainable… only an opinion from an unbiased person with experience implementing the particular EIM solution will be able to give a true account of how easy it is to maintain the application.

Effective dating plays a big role in maintainability. Being able to modify the information at anytime, but with changes effective only at a certain date, is critical to maintain a system.

Another key aspect of maintainability to consider the impact of year end on the plans. Some of the important information to find out is:

• Are the plans still going to work at year end?
• If plans need to be modified, how big of a change is it?
• How easy is it to modify the quotas?
• What about the rate / lookup tables?
• If formulas are embeded within the tables, do those need to be modified as well?
• How easy is it to move people in different positions?
• What do I do when people leave the company?

It is not atypical to see a somewhat complex logic which could be impacted by a simple change. For example, a formula referencing a table which contains another formula pointing to a quota. If the quota values can just be updated, it’s not a big deal. If a new quota needs to be created, then the formula will also need to be updated to reflect the new quota.

Another example is when an EIM solution needs to be able to handle last year’s orders at last year’s rates. Depending on the system, this could mean creating new rules, new formulas, new tables, new quotas, etc.

It may not all be about the Product

Implementing a software package is a bit like custom development. A quality architecture results in the possibility to re-use components. Some programming languages are easier to maintain than others; as we discussed, the same goes for EIM solutions. However, no matter how good a programming language, a bad programmer can make the maintenance a nightmare. A bad EIM implementation team can also make the system’s maintenance very hard, no matter how good the product is.

The bottom line:

Finding out the details about how maintainable an EIM solution is, is as important as finding out other characteristics such as how easy it is to implement it. You do not want to have to re-implement every plan every year; not only because it is time consuming, but also because major changes imply bigger risks.

The first part of the battle is to select an EIM solution which will make maintenance as painless as possible, but the battle is not won until the solution has been implemented properly.

Review of Centive Compel On-Demand EIM Solution

It has been a few weeks already since Sarah Carlisle, Director of Product Management and Bob Conlin, Chief Marketing Officer at Centive agreed to give me a detailed demonstration of Centive’s on-demand Sales Performance Management solution called Compel.

About Centive
Let’s talk about Centive for a moment: Centive has been around for a while; the company was founded in 1997 and originally focused on delivering on-premise Enterprise Incentive Management (EIM) solutions for very large companies. By 2004, Centive saw an opportunity to leverage the growing on-demand market and began developing the first on-demand sales compensation management solution – this time targeting mid-market companies. In May 2005, Centive released Compel. Shortly thereafter, they divested their original on-premise application business to ensure a focus on the on-demand market.

Compel Review
Compel is another leading on-demand EIM/SPM application with a value proposition almost identical to other applications and companies I have reviewed including Callidus, Varicent and Xactly. One nice aspect of Compel is that all its functionalities are bundled within the core application (no additional modules are required for reporting, modeling, analytics, etc.). Compel is a SAS70 Type II attested application and offers AppExchange-certified integration with SalesForce.com. Centive also has an OEM reseller agreement with ADP where Compel is sold as “ADP-ICM powered by Compel.”

Many companies like Adobe, Salary.com, McKesson, Cars.com and Sterling Commerce selected Compel to automate their sales compensation.

Compel Interface
There are 3 main “views” for Compel, each for a different type of user: the sales user view, the manager/executive view and the compensation administrator view. All views have one attribute in common: they are all very interactive. Any report or charts displayed will provide additional information when the cursor hovers over them. Clicking generally results in drilling down to get more detailed information.

Sales User
The main screen for the sales user displays at a glance all the information the salesperson needs to know. On the left portion of the dashboard they can see their total compensation, along with some details of how the total was derived. Clicking on the underlined amounts will result in showing more details.

The central portion of the screen represents in a graphical format their year-to-date total compensation, and analytics showing earnings and performance (sales vs. target) for each of their plan measures.

The bottom portion of the screen show alerts which can be either system generated or input by a business user, and more details on measure results.

Hovering over a graph displays additional information:

Drilling down from the Incentive Payment section shows information at the transaction level:

Another very interesting feature of the salesperson dashboard is the ability to display sale opportunities (from salesforce.com or other CRM/SFA systems) and the effect they have on the rep’s total compensation:

Manager View
The manager view has a very similar look and feel to the salesperson view, but displays information for the entire team:

Results can also be expanded to easily find details about how a transaction was commissioned:

Comp Admin View

This is where plans are created and configured.. Unlike other systems I have worked with, Compel abstracts the process of creating calculation and crediting rules through their Plan Builder wizard. Plans are created by defining and grouping the “Measures”by which reps will be compensated. First, the measure name, description, period, and type of measure is specified.

The next step consists in specifying what is being measured, and defining any filters (for example, exclude sales to existing customers):

The administrator just needs to choose the appropriate option and click on “Next” to the next configuration window.

Other systems have a component approach, and maintain a component library. In Compel you build measures. You can clone measures or plans, so if you need to build a new plan it is easy to clone an existing measure and re-use it as is or modify it using the plan builder wizard

Effective Dating:
I described effective dating when reviewing the latest version of Xactly Incent and discussed how critical effective dating is in my opinion. Centive uses effective dating for everything: people records, quotas, measures, plans, transactions, results, reports, etc . which makes its maintenance much easier. It also solves the difficult problem of handling prior period adjustments – Compel recognizes the crediting rules, roll-ups and structures that were in place at the time of the original transaction, and trues-up the adjustment to the current period.

The following plan builder screen capture shows how each plan uses effective dating:

Conclusion
I would probably need to work with Compel to make-up my mind about if I like the concept of how plans are built, since it is so different from the other applications I have seen. It’s very exciting to see a different way of thinking.

What I can say is that configuring a plan seems to be a very user-friendly step-by-step task. The user interfaces for sales people and managers are also very clean and display all the required information at a sight. Compel also seems to offer all the functionalities anyone could be looking for, and does so without the need to purchase additional modules.