Many years ago, \u201cscreen scraping\u201d was the answer to all our automation woes. We could spend hours creating the automation to pull down a few fields from screens just to cut and paste that information onto our workstation so we could then do some manual follow-up.<\/p>\n
Years later, we began to develop Application Program Interfaces (APIs) so that we could integrate with existing systems to once again \u201cscrape\u201d data but also have some logic behind it to perform a higher level of integration, including the real-time update of those integrated systems.<\/p>\n
Once again, though, it took time to create those APIs, if they were unavailable as part of the application package. And with it arose issues on testing, application availability, rapid changes to the integration app. The list goes on.<\/p>\n
That brings us to today and the use of Robotic Process Automation (RPA)<\/a>. It seems that you cannot pick up a trade publication (yes, I am old, and I still like to hold a magazine in my hand) without hearing about RPA, artificial intelligence (AI) or machine learning<\/a> (ML).<\/strong><\/p>\n It is the \u201cbe all and end all\u201d of the automation journey. Or so they would have you think.<\/p>\n Don\u2019t get me wrong. Whether in the workplace, at school, or at home, automation is transforming our lives. After all, isn\u2019t that what all technology sets out to do – or at least tries to do? But it may not be the \u201csilver bullet\u201d that many vendors would lead you to believe.<\/p>\n There are several issues that I see taking place with RPA implementations<\/a> that the tool vendors may not or will not share with you. I’ve also seen several issues that arise during development that are not found during discovery:<\/p>\n I don\u2019t think I have seen nor heard any one of the vendors say just the opposite, and I would have to strongly disagree with them. You will hear that it is just \u201cdrag and drop\u201d and does not require an extensive skill set so your \u201ctypical\u201d business user can create a bot.<\/p>\n Don\u2019t be fooled. This is technical work and requires design experience and technical acumen.<\/strong><\/p>\n Does this mean that a business user could not do the work? No, but someone who has development and design experience will deliver a more robust product than someone who does not have the skill set.<\/p>\n You may hear this from your users and for the most part, it is an accurate statement. What they don\u2019t share with you is the nuances that they encounter as they run through their process and the \u201cshortcuts\u201d they may take to complete their work.<\/strong><\/p>\n You must remember that as you build your bots, they are like a \u201cnew hire,\u201d if you will, performing the same role as someone sitting at a desk. The bot needs to know as much as it can about the process and even the little nuances encountered by the users. Will you get every little piece? Absolutely not.<\/p>\n But going into your process discovery sessions with the user, knowing that you need to \u201cdig a little deeper,\u201d will help to uncover most of those items that can fall outside of the rules-based mentality of robotic process automation.<\/p>\n Just because a bot is now executing your process, it does not necessarily mean that it will always run faster than a human.<\/strong><\/p>\n About 99.9 percent of the time it will but there will be those occasions where it seems to run slower. That is normal. Once again, remember that the bot is executing steps just like a human would and just like a human, there are issues outside of their control – such as a website that is down, internal outages, system upgrades and more.<\/p>\n What a bot can do for you though in those situations, is continually check to see when services are available so they can continue to process again.<\/strong><\/p>\n In most cases, human operators end up doing other things and it could be hours before they came back to complete their work while a robot may have completed that same work hours ago.<\/p>\n I like to use the analogy that you cannot take nine women and have a baby in one month. That\u2019s not how it works. Same thing with a bot. Just because you throw another bot at a process does not necessarily mean it will run faster.<\/strong><\/p>\n But, if you design your automation correctly, you can have bots call other bots to perform other pieces of the process, in essence, providing a certain level of parallelism that you might need for your automation to be more successful.<\/p>\n Communication, communication, communication! There tends to be little communication at the outset of an RPA initiative<\/a>, but that quickly becomes an issue when the bots are no longer running as expected or at all.<\/p>\n There needs to be a great deal of communication between the teams building the bots and the teams who maintain and update the applications, websites, and directories that the bot is using to integrate with.<\/strong><\/p>\n The RPA team cannot manage things in a silo or can the application and infrastructure teams. They must work as a cohesive unit.<\/p>\n There are several comments, suggestions and complaints that you will hear as you begin to roll out your RPA initiative. (Doesn\u2019t that usually hold true for almost all technology initiatives?)<\/p>\n But do not let that discourage you from moving forward. RPA plays an important role in your organization\u2019s automation maturity<\/a> and in your overall process excellence<\/a> initiatives.<\/p>\n Make sure that you do your research and that you clearly engage staff from across the enterprise to help move automation forward.\u00a0<\/strong>Don\u2019t allow the naysayers and those who may be directly impacted by automation slow down your progress.<\/p>\n Get them on board. Bring them into the process early on so that they can become more educated on why RPA is good for them and their company.<\/p>\n Give them enough ammunition so that they can effectively champion your RPA efforts and help to increase revenues, improve data and process quality, and enrich customer and employee experience.<\/p>\n RPA may not be the \u201csilver bullet\u201d of technology solutions, but it certainly is a piece that you want in your holster. If designed for long-term growth, can have you shooting for the stars.<\/strong><\/p>\n\n Robotic Process Automation Issues<\/h2>\n
1. It is so easy. Anyone can do it.<\/h3>\n
2. That\u2019s how I run through the process each and every day.<\/h3>\n
3. It\u2019s slower than I expected. What\u2019s up with that?<\/h3>\n
4. Let\u2019s throw another bot at the process to improve the performance!<\/h3>\n
5. The bot isn\u2019t working. It looks like someone made changes to the application we are integrating to.<\/h3>\n
Final Thoughts on RPA<\/h2>\n