We have seen commission systems for well over 20 years now, all with the promise of automation and miracles. In many cases this requires some substantial effort, whether configuring the commission system or developing integrations that require high skill set levels, substantial time to test and are prone to bug fix issues for years to come.
There is also the fact that it typically requires a technology professional or IT person to create a lot of these applications to succeed with a specific skill around the exact application you choose to purchase. Learning these technologies doesn’t really interest many people who want to learn how to understand and motivate salespeople.
One of the first things we have seen in applying digital transformation to the older SPM technologies, is how do you lift data and place it into these systems? Before, you would either use SQL, SQL tunneling, ETL programs, API’s, FTP or a myriad of other possibilities. With the recent coming of RPA and AI applications into the toolset of many commission experts, using archaic methods of transfer can now be a thing of the past. No longer do you need to do endless testing to make sure that the commas line up correctly, or that the data brought in matches the expected location.
By using RPA in commission systems you can ensure that the screen by which information was entered can be transferred exactly, in real time, to the commission system and expected rows. This means that the method of landing that information will look exactly like a person making the change or entry. This allows for the highly tested front end of many commission applications to be leveraged and will require only review of the movement of the screen-scraped information. Further, with many RPA systems going to citizen developer, an HR professional knows their process of entering data to create a person in an HR system – they can easily do a one-time entry and transfer using RPA.
At Lanshore, we have been instituting these use cases for many of our customers. One use case example is transferring Anaplan territory data into SAP commission systems. By leveraging RPA, you can move in-application Anaplan information at the time it hits the data tables over to SAP (formerly Callidus) commission tables. The benefit of this is that the Anaplan architecture is not properly matched to the effective data in its native state that the SAP architecture has. When one uses RPA transfer in real time it does several things:
Firstly, it allows for the use of end-state architecture (since you’re using RPA, you don’t have to match this architecture using a sophisticated ETL program, effectively recreating the proper date-effective architecture that Anaplan is missing) of SAP to consume and use the new territories in real time, correctly allowing for changes that can be recognized at the time of occurrence. Secondly, it avoids the time costing and resources costing transfer of the ETL program.
In some cases we have been taking data transfer load times from over 40 hours down to minutes (aggregated RPA time frame). This is because two things are happening. First, you are processing all the data into a format on a nightly basis using non-natural data manipulation in the ETL program to match the two systems.
Second, you are reliant on the landing area being perfect, and that the file will be picked up in an adequate time frame. In the second case, if there is an issue with the file system, you could be waiting days for a proper timeout and likely need to go to support desk help. Extraction of newly created territories is automated as well through RPA for any additional analysis by compensation administrators. Finally, you are also avoiding the time it takes to reconcile and validate between the systems as this is the number one killer of time, resources and money in the SPM industry.
Building the use case for this territory transfer was quite simple as these transfers are done by a segment of the population and result in the modification of two systems that affect all other downstream systems. The RPA could be either attended or unattended, depending on how users prefer to use the application. The overwriting decision to use attended is giving the user final say in when the data transfer happens, so that they feel comfortable about the state of the information that has been landed. Let’s take our above use case of territory movement.
The person in charge of territories, whether it is a sales operations or sales manager, will go into Anaplan and make the change to the territory. This could be a change to the geography like adding a new zip code, or it could be a change excluding a key account, maybe it is a change to add a certain product set. This person then reviews the change and submits it. In the case of ETL, you would consolidate all of the changes of everyone at the end of the day/week (whatever defined period they have to run the data transfer) and load into the system.
Usually this is an end of the day process. In the case of RPA, you would have it kick off immediately after the submission of the territory change. RPA would pick up the information from the screen, and other determined locations where a user would go to pull information, login to the SAP system, in this case, and enter the details as a user would in SAP.
SAP would then apply its systematic data changes and effectivity and you would have a territory update. If this sounds simple to you, that’s because it is. You are not having to do heavy PLSQL modifications, you’re not having to figure out how to land data in a specified format, you’re not having to create credentialing that is done by IT and you as a user are in charge of when it runs. It is human psychology to be afraid of something new or change to the existing system, but using RPA is simple, cost effective, error free and requires very low maintenance with zero technical skills.
The territory movement is one use case that we have created for people, but there are several others. Kicking off calculations, bringing in transactional data, adjustments, validations, automating response to disputes, dispute management among several that we have completed.
Additional thoughts by Paul Devlin in regards to RPA’s impact on the SPM industry:
RPA is the ability to inject new points of intelligently automated control into a digital ecosystem. It is not a replacement for highly efficient bulk transfers, nor is it the death knell for proven methods. As a new possibility, of putting speed and intelligence and correctness where a human sat before, however, it delivers a tremendous new power to system designers. What had to be viewed, understood, keyed, re-keyed, checked, transferred, re-checked can now be just a box in a design.
Of course app topology remains relevant, of course exceptions will surprise, of course it is a journey. Think of the possibilities, though – these bots can record to a central repository their entire operational history. Information never previously available, the success and failures of administrators and analysts, becomes measurable. Pain points self-document in real time.
Business processes ripe for RPA are rife with cross-system human fuddling. To imagine a network of control points where that fuddling can be systemically improved, reported upon, by itself that is a great thing. Add the fact that in design there were no doubt many small and tricky integrations that were not cost-effective. Many times RPA can change the landscape, dancing bears who can sing, all that. As teams of bots apply themselves to different tasks in a subsystem, management is able to navigate change much more efficiently – no longer need one sit with Reginald and Polly and ask what happened or what happens if.
SPM systems are multifarious – this package, that package, this infrastructure or another, heaps of legacy code, often no system at all, just a collection of staff and spreadsheets. The impact of RPA will vary considerably based on the maturity/coherence of the existing system. Sometimes the impact could be marginal, sometimes utterly transformative. RPA should be thought of as an additional enabling method. Sometimes it can prove to be the difference maker.