Implementing Incent could be very exciting for a customer especially the Admin who is caught up with the manual and painful exercise of calculating and managing everything on spreadsheets. Having a system does not only take away all the manual work from the Admin but also gives the end-user more visibility to their statements. Whether it’s suitability, turnaround time, reporting capabilities, routing of plan documents, or time spent to reconcile, everything is taken care of by the tool itself giving Admin the flexibility to focus on more critical tasks.
However, while implementing a system, there are a few things a Comp team should think over or discuss internally before meeting the implementation team for requirements. These things can make a huge difference to the success of the project and improves the scalability and long-term sustainability of the project.
In this blog, we discuss some of these things:
Understanding the change: Many times, customers feel that implementing a system means everything is automated and hence minimal work is needed when a system is built. It is important to understand, that when a system is implemented, the Admin should know the system enough to perform basic functionalities like:
- Navigating to reference data like HR information, Quota information, etc.
- Knowing how to load Transactions and how to calculate commissions out of a system.
- Generating reports and validating the data.
Hence, it’s important as a customer to understand that even though the manual work around data consolidation, calculation, and reconciliation is minimized, updating reference objects, performing system-related tasks, and validating results and reports are still needed.
Getting your plan documents finalized before Kick-Offs: Many times it has been seen that when a product is purchased and the customer meets with the Sales team, plan documents from previous years are used as standards to list down the SOW since plan documents for the current year are not finalized. It is important for a customer to understand that if their plan documents are finalized by the time Kick Offs start, it results in better and smooth operations during KO calls.
Your associated consultant can easily figure out the gaps in SOW if any and will be able to list all requirements sooner in the project. As soon as the requirements are over, the implementation team works on designing the solutions. With full requirements at their disposal, they can come up with the best possible design as per your needs. Continuous changes to the requirements during the implementation could result in changing the design/ or thinking of workarounds depending upon how deep the team is with its implementation when the change was identified.
This puts a lot of stress on the entire team. There are cost implications, deadline issues, re-planning, risk of the system becoming more unstable, etc. which no one desires.
Plan doc and Scalability: When a system is implemented, as a Comp Admin, one should always think of the system to last for years, and hence effort should be made to standardize the plan documents and keep them at the minimum possible number. This does two things: The minimum number of plans is easy to manage as an Admin and can be scalable to new hires.
Plan Docs which are too complicated or target only very few people have often seen as one-off plans and most of the customers change those plans in the following years sometime in the current year itself. It has been seen that companies that are starting new or are still figuring out their Comp plans end up with as many plan documents as the number of people in the organization. It is important to list down key KPIs and how these can be standardized across a group of people.
Naming convention and standard fields: Some of the key questions discussed during the Kickoff calls are about Standard fields and Naming Conventions.
When is Employee ID used? As best practices, a company should be able to provide the HR ID or the ID that is sent to the Payroll team for processing. It is not suggested to make use of any system ID here like SFDC ID because it created a dependency on that system. What if you have people who are not in Salesforce? It also impacts the longevity and scalability of the solution. What if Salesforce does not exist in the future?
Discussion around Position Naming Convention: A customer will be asked a series of questions to figure out the Position Naming Convention in Incent. The position plays an important role in Incent because not only does it maps an employee to the Title, but credits are calculated only for an active position.
As best practices position names should be such that a new position can be easily created when someone changes plans. On most occasions, changing plans is directly dependent on changing titles. As such a new position record needs to be created. The main thing is whether attainment should get reset to zero when someone changes the title or should it continue from the previous title.
Using standard fields in People and Orders and how many custom fields are needed? Incent has the capabilities of having any number of custom fields in the People or Order form to meet customer needs. However, as a customer, it should be important to understand what all absolute necessary fields are.
Fields which are needed for calculation purposes, reporting needs, or being used in downstream systems are necessary to be stored in Incent, however, it has often been seen that customer tries to bring in a lot of fields from source data which plays no role and are stored in Incent for no reason. Also, some reports in Incent can only show standard fields to the end-user, hence it is encouraged to make most of the standard fields and limit the number of custom fields in Incent.
Importance of system integration testing: Most customers like to automate the transactional data or HR data from source systems like Workday, SFDC, etc. The most common data sources are SFDC load where Connect tool has the capability to pull data directly from SFDC to Incent. If data comes from any additional sources, it is loaded via SFTP where a customer needs to ensure placing a file on an SFTP location, and Connect process loads the file into Incent. In order to ensure a successful integration built, a successful SIT is needed. Some key things needed from the client for SIT to be successful are:
- Provide all necessary data for multiple months to consultants prior to kick-off
- Ensure that technical field names are provided which is needed for mapping
- If possible, ensure that for testing purposes Sandbox environment is mapped to Incent in case of SFDC data pull. This helps to manipulate the data and test edge case scenarios.
- Ability to manipulate the data in the source system when requested by consultants during Implementation.
Importance of User Acceptance Testing: During Implementation, UAT is the most important and engaging exercise for the customer. Not only does the customer expected to perform different test scenarios, but it’s also the first time the customer is able to do hands-on Xactly Incent. Hence, there are some key things that customers should ensure:
- The customer owns the UAT and hence customer should think and prepare all possible scenarios while performing UAT.
- The customer should test all business functionality as per the requirements given.
- The customer should test all edge cases and also perform testing in multiple periods.
- Customers should test scenarios around New Hire, Termination, Role Change, Leave of absence, etc.
- Customers should also test standard reports, pods, and dashboards and provide their feedback.
- An end-to-end dry run at least in one period should be performed by customers to ensure they learn the system enough in the presence of the Implementation team to get comfortable using the system once they are life.
- The customer should test all Connect processes and test if all expected transactions are getting loaded.
- Apart from Component testing, all ancillary features like SAML/SSO login, Plan Document, Reporting needs, Estimator, Illustrator, Show Me, etc. should also be tested.
- Finally, customers should not do parallel testing. It is often seen that customer thinks of running their current calculation and comparing the results in Incent, which is not the best practice for a number of reasons. Firstly, the project scope doesn’t have enough time frame to perform parallel testing. Secondly, parallel testing doesn’t cover all scenarios. Thirdly, a lot of times requirement changes in Incent, and hence those results will not match. Fourthly, there are issues with offline calculation/current calculations. Finally, parallel testing for one month can take up to 2+ weeks of time, hence it should be avoided. Rather, 2-3 payees per plan should be picked up and their data should be modified to test all possible business scenarios.