- This is one part to a multi-part online compensation guide: Back to Main Menu to access the other articles.
If you are changing how your program worked (as opposed to relaunching the same program with basic year-over-year updates) and find that your new program is not working then Customer Support may be unable to provide consultation to troubleshoot design flaws. All new programs and changes to existing programs are best done in conjunction with a paid professional services engagement, as they are trained in implementation, best practices and program design.
Testing Best Practices
- TEST TEST TEST: One of the main causes of unexpected or less than desired results from the SuccessFactors Application is when you do not allow enough time for testing, or fail to perform comprehensive and exhaustive testing of your forms and processes. We find the most common problems could have been prevented if only better testing had been performed before launch.
Yes, our application is a very easy-to-use UI, but never forget your unique individualized comp program has been custom-built from the ground up based on your specifications. That typically takes weeks if not months to do during implementation. Re-launching the same program without making any design changes is relatively easy, however, making even small changes to your original design can be complex and may require re-engaging Professional Services.
- Tip: First relaunch your previous program to confirm that the old program you will be copying is still working itself. This is a very important step as it provides a baseline to go back to should you encounter issues along the way.
- If your source program no longer works when you launch a test form, then before you proceed to copy it you will need to identify what is wrong in the original program. Attempting to build a new program from an old broken one is a very bad practice.
- One of the first things customer support will ask you if you log a case, is to see your last known working version and to confirm via a test worksheet that this is not the sourece of any current issues.
- We will roll back to that last known working version rather than attempt to locate what you have broken along the way, which can be very time consuming.
- From your last known working version make small changes and retest at multiple checkpoints so that if additional changes break the program you will likely know which recent change broke it.
- Do NOT spend days making changes only to test at the end, as it becomes almost impossible for support to try to figure out what is root cause of issue. Support will most likely need you to roll-back to a previous working version.
- Always build into any change process at least 4 weeks of design and test time. Allow even MORE time if you will be configuring this yourself. If this is not done Customer Support may not be able to process your new request in time for your launch as changes can take up to 2-3 weeks to process. Therefore, it is important when creating your own templates and processes that you aim to be completed well in advance of your launch, in case of unexpected issues.
- NEVER launch a new process at short notice, or under an aggressive timeline that fails to allow you to test EVERY aspect of the worksheet, process, data and reports. It should be carried out by multiple testers, using real data, and from the aspect of every role that will be involved. E, EM, EA, EH etc.
- Consider in your testing, not just how the worksheet should work, but also consider how the worksheet shouldn’t be working as you review results. Put yourself in the end-user’s shoes by logging in as each test user involved.
- Purposely make out of process mistakes to test unexpected results, as it is common for an end user to do things you had not imagined they would.
- When testing a new worksheet, be sure you complete a sufficient number of forms so that you can also test all reports to be used.
- Document your results for future reference. Should an issue be spotted later in the process, you will be able to refer back to your testing results to see if the issue was apparent then but missed, or if it was working in the past and a new bug has been introduced into the SuccessFactors Application.
- If you need to restrict access to the SuccessFactors application during your process you can limit access by either removing people from the Default User Group Assignment or removing Access permissions.
- Keep data backups. Before you import new data into the SuccessFactors Application make a backup and keep in a safe place.
A Word About Production vs Test Sites
Please keep in mind that production and test are not connected in any way, entirely separate sites and therefore not likely in-sync. As you load new data into each site, such as goals, compensation data, and templates etc, the sites become out of sync. Therefore when you develop and test a template in your test site, the results cannot be assumed to be exactly as you will encounter in production as data may not be the same, and most issues for compensation are related to data.
Add additional time for another round of testing in production on top of what is planned for your test site.
Add time in case you need to reconfigure your form templates to work in production.
You may want to consider paying a fee for SuccessFactors to clone your entire production site to overwrite test so that it is an exact byte for byte copy. This can save additional design and configuration time with complex process launches as it brings a more consistent experience to the testing phase within both instances.
Best Practices for Production preparation:
KBA , sf compensation cycle preparation , sf comprecommended , LOD-SF-CMP , Compensation Management , How To