How to embrace RPA in SAP ECC (and make new friends)
TABLE OF CONTENTS
I know, too many TLAs right?
Robotic Process Automation is the next big thing.
The Google Trends graph below shows the interest in RPA sharply increased in early 2017 and has continued to rise since.
As with any new tech term, as soon as Gartner and Forrester latched on to RPA and started to publish research notes espousing the ‘important' stuff that SAP CIOs should be looking into, enterprises everywhere had it on their tech agenda.
Given that 9/10 of the World’s biggest companies run SAP*, it wasn’t too long before the SAP / RPA crossover kicked in. Most transactions in large enterprises run through their ERP system so SAP became the Plat-du-jour for Robotic Process Automation.
*I’m not sure this much repeated statistic is true these days
Companies like UI Path, Pega, Automation Anywhere and Blue Prism hit the market with cool RPA tools promising low-code, drag and drop workflow. Clearly, these guys and others promised Process Automation nirvana for SAP customers.
But before you leap, let’s explore RPA in a little more detail - for SAP and the other key applications that large enterprises rely on when they run their business processes.
And, consider whether SAP the right focus for RPA.
There’s a massive emphasis on business process documentation during SAP projects.
Armies of consulting teams and press-ganged business people spend months capturing swim lanes to describe as-is and to-be business processes. In reality, this is a money making machine for consulting firms. Because, as any business manager will tell you, these processes are rarely looked at again once the system goes live.
Business people don’t sit confused, scratching their heads sat at desks (or COVID-19 dining table alternative) trying to work out what to do next as they follow Visio flow charts with their index finger.
"Barbara, it says on this swimlane that I have to make a decision here before handing this Credit Memo across to the Approver Role - who is that again?"
No, they simply ‘do’ stuff.
And the stuff they do changes over time much more quickly than those flow charts can be updated.
Which means that the gap between as-is, to-be and as-is again widens over time.
Plus, there are so many process variations that it’s impossible to capture them all in Visio or whatever other magic snake-oil tool the last software sales guy sold to your CIO.
Most businesses don’t even capture the workarounds to their 'defined' processes formally.
Doing this alone enables business process owners to play catch-up and update their business processes and policies periodically. You know - the stuff you can't do that your processes say you should be doing, but your ERP systems don't support as intended because you rushed go-live and kicked them into the long grass to be fixed in BAU.
A large chunk of process deviations and workarounds are ‘off-system’ too. People use simpler, more flexible tools to record, organise, track and report on transactions.
The main culprit - Excel.
Maybe RPA for SAP isn’t where the cost reduction honey is - maybe it’s getting those off-system Excel processes in to SAP first.
Not automating them, but simply putting them in the place they should be.
Did RPA really arrive on the scene in 2017?
No. It didn’t.
The term RPA became the zeitgeist around 2017. However, the principles behind RPA go back much earlier on the tech-timeline.
In the mid 80s, I was a spotty teenager with an interest in BMXs and Home Computers. Cutting my teeth on a Sinclair ZX81 (with 1k of memory and a 16k add-on RAM pack) and then moving on to a ZX Spectrum (which I still have), I learned the basics of programming in my bedroom.
My parents were concerned.
They didn’t understand how I could make a blue block that I controlled with the keys (QAZX obviously) move around the screen as it was chased by a red block that got faster the longer I managed to escape.
My modern spin on this would be that it was AI.
But it wasn’t.
It was a couple of quadric equations.
Anyway, my Dad ran an engineering business at the time. So, rather than leave me locked in my bedroom looking like a pasty-white goth in sportswear, he took me to work during my school holidays and sat me in front of his firm's only PC - an IBM XT.
There, aged 14, I was exposed to my first spreadsheet - Lotus 1-2-3. Later, I found Borland Quattro Pro which was much cooler (think PC vs, Mac) - and I fell down a deep, dark hole of functions, equations and Macros.
Today’s cool kids who use Excel and Google Sheets never really saw those early spreadsheets. But they were the foundation of today’s everyday office suite tools.
And now, the business world pretty much runs on Excel.
Macros were the way you automated activities in spreadsheets. In the early days, you wrote your macro vertically in cells with a series of commands which would run as a linear script.
My whole world changed one day when I realised I could make the cell containing the macro command change depending on other cells.
Wow - dynamic programming.
Macros still exist in Excel today - although they’re a little less democratised and require users to know how to handle ‘code’. This shift in the 90s from simple Macros to Visual Basic (VB) Code based Macros in Excel changed a generation’s path on what was a healthy automation trajectory.
If Microsoft hadn't moved Excel Macros to Visual Basic, RPA would be commonplace today. Instead, automation shifted from a business task to an IT discipline. Fail.
Macros and automation became ’technical’ rather than ‘logical’.
Despite this, Macros are still popular. In fact, they seem to be more popular as search term than RPA until very recently - but have reduced significantly over the last 10 years.
So, RPA has been around in Excel for decades.
And it existed in Excel's forerunner spreadsheets 40 years ago.
That's Jurassic in tech timelines.
What about RPA for SAP though?
Early SAP versions (3.1h was my first) had a form of automation - Batch Input Sessions.
Batch Input Sessions were SAP’s version of RPA embedded in SAP in the mid 90s. Here’s an example.
Just like today’s best RPA tools, you could record an automated transaction, throw data at it and run it in the background.
It was the staple solution for SAP consultants and Super Users to upload spreadsheets of journals or update master data. Next, Win-shuttle arrived on the scene with a more elegant solution, better Excel integration and simple extract and re-import functionality. Winshuttle’s penetration of the SAP marketplace is high for a 3rd party SAP add-on tool. But, get talking to a SAP Centre of Excellence team about what they use it for and the response is usually a little ‘meh’.
Great market penetration but so-so customer adoption.
There are other existing semi-native automation tools in SAP that have been around for years too. Don’t forget that Batch Orchestration tools like Redwood and Atomic are primitive RPA tools.
On an event, do something.
Monitor for the existence of a file, do something with it.
The market for Batch Management tools pivoted to Automation tools in the 2010s - companies like UC4 rebranded as Automic and were subsequently acquired (due to their strategic vogue status of 'Automation') by ageing brands like Computer Associates.
Modern Batch Orchestration tools like Stonebranch take this traditional functionality and bring it into the 2020s - more visual, drag-and-drop, better dashboards and metrics.
How about Test Automation for SAP?
At its heart, Test Automation is RPA. It’s just RPA applied under a specific context.
The latest SAP Test Automation offerings from the Gartner Magic Quadrant Leaders are nothing short of mind-blowing. They’re able to work in a fast-paced, frequent release SAP environment and deal with the complexities and dependencies involved.
Move a field on a screen for usability. No problem, the automation tool detects it based on its ID and the script still runs.
Want to record a script and then throw 10 different data variants at it? No problem, record once and matrix out the data to generate 10 scripts from a single source. Then, change the script and all 10 versions adapt.
Need to test end-to-end scenarios across SAP, Success Factors, Salesforce and a web portal? No problem, modern test automation tools support multiple platforms and chaining of scripts.
You get the picture.
Many SAP consulting firms (especially offshore outsourcers) will implement Test Automation as an "automation trap" - they'll build cheap(ish) solutions on open-source software with proprietary scripting created and maintained by an army of people.
Mostly, they’re simply swapping a team of manual testers for a team who maintain automation scripts.
Buyer beware.
How do RPA tools work under the hood?
There are are plenty of available platforms that can be used to assemble automations scripts. Selenium for example is the mainstay of screen scraping on web based applications. If all you want to do is emulate scroll, move, cut and paste, you’ll find a developer on Upwork who can knock that stuff together in hours.
A home-spun RPA Proof of Concept is straightforward.
We've built our own in-house automation tools this way and even commercialised one that has transformed our CRM and Marketing Automation. It cost a few thousand pounds and now turns over more than it cost per month with a user base of >200 global customers.
The high-end tools often add a layer of sophistication on top of available components to simplify scripting, event triggering and chaining.
Cloud based platforms with microservices based APIs make things easier still.
Shift down from Enterprise level solutions to mid-market solutions and you’ll find that integration and automation are pretty much out-of-the-box. Need Hubspot to talk to Zoom? Literally, 5 minutes and it’s done.
There are flakey tools like Zapier and ITTT in the SME marketplace that aren’t scalable to Enterprise level. But writing APIs is pretty simple integration development work compared to proprietary SAP tools like PO/PI.
APIs are definitely one of the secrets to SAP RPA in the future.
When the SAP world starts to move away from IDOC and middleware heavy architecture to more nimble real-time integration, the possibilities for SAP automation will change significantly.
Same goes for batch processing. Why wait until end of day to process some back end processing en-masse when you can do it now? In fact, for modern customer experience, it absolutely needs to happen NOW.
But for that to happen, the the people making SAP design decisions have to unlearn.
They have to forget how things used to be done and adopt a different mindset.
If sports people followed the same Strength & Conditioning techniques used 3 decades ago, their performance and the overall quality of their sports (including the records they break) wouldn’t have changed.
The catalysts for this transformation aren’t the athletes and players themselves, but the S&C coaches who constantly learn and look for new ways to drive performance.
Same goes for Enterprise Software design - Architects and to some extent Programme Managers need to release that that there are newer, more modern ways to do things than the techniques used in the 90s.
Whilst there are plenty of solutions out there for both RPA and API orchestration, there’s a mindset shift required before the willingness to accept these technologies catches up with the technologies themselves.
Wind back 30 years and business people were automating business processes with Macros in Lotus 123 and Batch Input Sessions in SAP. These truly were Low Code capabilities.
Where did we lose the momentum on automation?
First, the shift to Code based automation in Excel by Microsoft took us down a different path in the 90s and 2000s.
Since then, we’ve simply taken our eyes off the prize because we’ve been distracted by 2 decades of offshoring and treating SAP as an Opex cost to reduce rather than a platform that's an enabler for competitive advantage.
If you want to talk with me about any of this stuff, grab 30 minutes with me here... Book some time to chat with me.
I'm always happy to talk to interesting and interested people.