The Automation Paradox – Proceed with Caution
By Clinton Jones on January 3, 2014
In this new year of 2014- we are living in an automation paradox. The ability to automate processes doesn’t always provide the optimal and desired results. We have the ability to automate many processes, but how cautious do we need to be?
A recent article appeared in the IEEE spectrum on “the automation paradox” which was reflected with the question by Steven Cherry of “Would we be safer overall if we just accepted a few deaths due to software?” The concept is a little funny, since a lot of the software I’ve encountered over the years usually carries a EULA warning that states something like “…IS NOT INTENDED FOR USE IN THE OPERATION OF NUCLEAR FACILITIES, AIRCRAFT NAVIGATION OR COMMUNICATION SYSTEMS, AIR TRAFFIC CONTROL SYSTEMS, LIFE SUPPORT MACHINES OR OTHER EQUIPMENT IN WHICH THE FAILURE OF THE SOFTWARE COULD LEAD TO DEATH, PERSONAL INJURY, OR SEVERE PHYSICAL OR ENVIRONMENTAL DAMAGE”.
Want a real life example? Take the world of music. A deejay’s profession has transformed over the last couple of years, with the almost completely eliminating the need for tunes-minders or to drive a minivan brimming with boxes of CD’s. The MP3 standard and digitizing music into data files has effectively rendered that industry much more efficient. So much so that you could be carrying thousands of hours of broadcast grade audio media in your pocket in the same device that you make phone calls with. What’s the problem? There is now there is so much of it that it is difficult to manage unless you are an incredibly disciplined or organized person. I have terabytes of recorded media at home; songs, videos, movies, and photos that I have attempted to store in a sorted fashion. However, my volume has rapidly outstripped my discipline levels. I often become tense when I try to locate a certain file.
Automation -performing operations automatically
Back to the concept of the automation paradox. The idea is that automation is the operation of a particular activity which occurs automatically, without continuous input from an operator. The more reliable one considers an automation to be, the more complexity one will introduce to the automation and ultimately the less the operator can contribute to the resulting success. This is a paradox because it could be a contradiction. I have my audio tracks so now I don’t have to carry hundreds of discs from venue to venue. But because there is much of it, I only carry a portion of it. I have changed my usage model. I’ve switched from a phone that just makes calls, to a phone that makes calls, surf the webs, plays music and takes photographs but really, what do I use it mostly for? I have over sixty applications installed, but I only use two or three regularly. My guess is that you can see some parallels here with yourself? In theory, I don’t need my phone, mp3 player, camera and my laptop all at once, but which ones should I shed?
This topic is relevant in the realm of creating automations around SAP transactions because we assume that we can save time and energy by building scripts around all manner of actions in the world of SAP. However, sometimes we simply need to step back from the problem and evaluate whether we really should be modeling automations around things that we find annoying or which we think we can build automations around.
Should you build it because you can?
The message should be, even though you ‘can’ build a script around a given transaction or process in SAP, you should question if it is the right thing to do. For example, the transaction recording modes is building scripts using GUI scripting. While this method often works well, it is an area that has been frequently called out by SAP admins and auditors as an area to be cautious with. The challenge is that it leverages classic screen scraping and doesn’t rely on the field and screen definitions defined programmatically in the SAP transaction. One can sometimes land with unexpected outcomes and you can only assess success a review of the results is performed. Are you in the practice of checking your results?
Again, you can build a degree of checking and controlling into your recording, but the level of effort required may ultimately make it better to not build such an automation. I always encourage people to look at alternative ways to achieving the same objective, perhaps using multiple scripts or considering a BAPI or an SAP API, like a remotely enabled Function Module to achieve the same result. Irrespective of the approach you choose, testing will be key and playing through a number of use cases and scenarios will be pivotal to determining whether your automation is robust and reliable.
The script doesn’t run a defibrillator
Fortunately, all of this isn’t likely to be very life threatening. It’s not very likely you’re using that transaction recording to run a defibrillator, or fly an airplane. However, don’t underestimate the script’s importance though, especially if you are using it to do interesting things like maintain bills of materials for the manufacture and assembly of items. Keep in mind whether you are ultimately building something that will make more work for you in the long run, if something should go wrong. In the world of SAP, without a system restore, there is no undo, only the ability to fix forward.
About the author
Clinton Jones is a Director for Finance Solutions Management at Winshuttle where he has worked since 2009. He is internationally experienced having worked on finance technologies and business process with a particular focus on integrated business solutions in Europe, the Middle East, Africa and North America. Clinton serves as a technical consultant on technology and quality management as it relates to data and process management and governance for finance organizations globally. Prior to Winshuttle he served as a Technical Quality Manager at SAP and with Microsoft in their Global Foundation Services group.
Questions or comments about this article?
Tweet @uploadsap to continue the conversation!