SAP Commissions
Testing strategy
hero image

Table Of Contents

In 2018, SAP’s acquisition of marked a pivotal moment in the evolution of their flagship Incentive Compensation Management product. Renamed as SAP Commissions, the product is undergoing a comprehensive architecture rewrite, transitioning to core SAP technologies and rebranded as SuccessFactors Incentive Management. This transformative change is a response to the ever-evolving landscape of technology and a strategic move to align with SAP’s broader ecosystem.

The crux of this transformation lies in the departure from the existing architecture, which is based on Oracle. This change is not merely a technological shift but a strategic necessity. The current Oracle-based architecture is set to lose support beyond 2026, prompting a critical decision for existing customers. They now find themselves at a crossroads, faced with the choice of either upgrading to the SAP HANA platform hosted on Google Hyperscalers or exploring alternatives within the Incentive Compensation Management (ICM) and Sales Performance Management (SPM) landscape.

One of the common mistakes when selecting the target platform and an implementation partner is an assumption that “they will do the job”.

In the end it’s only natural that after migration (regardless of if the target platform will be SuccessFactors Incentive Management or a new platform like CaptivateIQ, Anaplan or Varicent) the new system will produce exactly the same results as the old one.

But how to prove it? 

Critical for success – the testing strategy

Testing strategy heavily depends on the approach taken for historical data migration.

There are a few strategies here, ranging from not migrating any history at all, through migration of aggregated payout results, to full system migration along with data to recalculate historical results.

All of these approaches have pros and cons and should be carefully considered, but they have tremendous impact on the testing strategy.

A common testing approach is to take a period or two of historical data, run both the old and the new system, and expect the same results.

There are however quite a few things that need to be taken into account: Compensation rules might have changed, the current data looks different than in the past. If history is not migrated (and if so – how?) this kind of testing may even be impossible to execute.

Another (very important!) consideration should be data loading testing.

How many files should be loaded and compared between platforms?

Only recent ones or also historical?

A full year worth of data?

All these considerations should be discussed with your implementation partner.

A few practical hints from Sands Partners:

  • Do insist on the testing strategy defined in migration SOW in great detail. This should include description of tests, their scenarios and breadth in terms of number of periods.
  • Parallel runs are critical to prove that both systems produce the same results from live data. Do consider that this may incur dual license cost for the duration of tests.
  • Infinite quality requires infinite budget. Do think about number of tests to execute.
Get in touch with an ICM Expert
We're here to support your Incentive Compensation Management journey.
Leave us a message and we'll get back to you.
Copyright © 2024 Sands Partners. All rights reserved. Privacy policy.