A new “field” inspiring many definitions and evaluations of the many definitions available for the much-buzzed-about “Robotic Process Automation” concept, I particularly like that of Leslie Willcocks, an LSE professor specialized on the subject: “RPA takes the robot out of the human”. Who hasn’t indeed, while keying in a list of data or transactions into our beloved SAP GUI, felt like a poor robot?
Seriously though, if the gains to be expected from RPA seem alluring (between 30 to 200% ROI in certain cases, still according to Wilcocks), as with all other IT strategies, it is not risk-exempt.
Chris DeBrusk lists five main risks in his article:
non-standardized bot deployment creating quality assurance issues
bots relying on legacy systems slowing innovation within the company
disappointing results brought about by too rapid and broad bots deployment
resistance from business-process owners to automation of their tasks
bots becoming a pervasive approach holding back other process and IT improvement approaches
RPA, the business-process owners and IT teams…
While I agree most of these points should be scrutinized, I think number 4 (resistance to automation from business-process owners) is overrated: in my 20 years project experience, I’ve never really met anyone seriously not willing to suppress the repetitive and non-cognitive part of their job. Everyone wants to concentrate on the interesting and value-creating part of their responsibilities – providing they keep control. My argument here is that a successful RPA implementation must not suppress visibility and control from business-process owners, on the contrary. It must empower them to directly assess productivity gains and let them intervene at any point in the process to correct potential errors (yes, because errors still can occur, mostly for technical reasons, with an RPA solution).
Another point in mitigating the risks evaluated by Chris DeBrusk is the inclusion of IT teams in any RPA strategy or project, at an early stage, as is also advised by Willcocks. Some RPA tools tend to be intelligible and non-technical enough so that non-IT teams can use them directly – which is definitely an asset. However, IT should at least be included to evaluate if the RPA tool does actually not interfere with data structure, integrity and security, and if it fits correctly within the company IT framework and strategy.
A guide to understanding the RPA market
I liked the segmentation (“streams”) imagined by Wilcocks to segment the RPA market. I’m sharing a little chart below inspired from his thoughts.
As you have noticed from the many articles and publications around the subject, a lot of IT solutions are now claiming to be part of this market. I think it’s interesting to use this grid to evaluate their arguments. Since our main focus is on SAP, I also did this exercise on our own XSBS toolkit to check to which category it belonged.
RPA and SAP: room for robots you pilot
As most SAP users, expert or not, have experienced, we spend a disproportionate amount of time retrieving and keying in data or transactions against the actual useful analysis and decision-making time. Significant productivity gains can be expected if you decide to do something about it. You just need to ask around and all SAP users will have ideas about how they could free-up time to manage more work or dedicate more time to research and analysis if they could cut on the robot-like work they must deal with.
With a toolkit such as the modular XSBS solution, you can scale up from a single POC project within a department focusing on a specific process to multiple tools supporting many different teams and processes without limitation nor technical risk: each tool (X’App) connects to SAP via fully secured and authorized BAPI, just like any real user would, except it does it much faster and expedites transaction lists or data entry lists. It can also expedite rule-based decision making and automate further while providing full control to the end-user, who can check in a friendly Excel environment that everything went alright. Each implemented X’App is fully reusable in that it can be quickly modified to accommodate for any unforeseen change in the process or in the business. There is no IT involvement required except for the necessary coordination and integration within the IT roadmap and strategy. Full IT involvement and in-house X’App development is also an option should it be preferred by the company.
The robot in you
No need to name your robots, like I’ve seen in some projects (!) – they are just an extension of yourself and do what you would have done, except they do it faster, across different SAP systems, in an orderly and fully documented fashion – and they do it with your SAP user (so they won’t do anything you are not authorized to do). You can opt for a fully gradual implementation, making sure you reap the benefits at each new implemented X’App.
So, if you want to get control of the robot in you and multiply your work output – you know where to call!
Daniel Lellouche - CEO and Founder - XSBS Solutions
Comments