🎅 Advent of UiPath 2020

News Challenges
35

I would like to post something related to this purpose of the Advent Challenge Series

We are seeing awesome solutions posted to these pages in response to the Challenges. So much so that I’m almost tempted to go back to writing code-heavy solutions.

Disclaimer: I love getting things done in concise code. Sometimes it is not just unavoidable, but darn efficient as well!

And therein comes a real-world challenge.
Before succumbing to the temptation each time, I try to remind myself that for most part impersonating the human user is where RPA solutions in general distinguish themselves from traditional back-office or code-first automations.

When presenting demos or proof of concepts, I feel that it becomes easier for us to justify the need for RPA by building a demo that is closer to actions of front-line business groups than showing them something that runs several lines of code. And when we demonstrate code-heavy solutions, the tech-savvy audience are quick to respond by asking or saying the following:

  1. So, if you are writing code, why do we need to do it in UiPath? Can’t we do it using tools that we already have?
  2. Is UiPath an integration tool? Because the code you just showed us can also be written using the “Execute Script Task” in our integrations tool
  3. Why are we doing it this way? I have APIs that can do that, why do we need to use RPA?

My concern is that if we build code-heavy RPA Solutions, it is possible that all of the control of salient business functions will be taken away from frontline business groups and the pressure to deal with them will fall squarely on the RPA teams. This pressure would further compound if these processes suffer failures, or if a slight workaround needs to be exercised to make the Automation behave differently in Production.

That said, the above argument loses ground if the Automation is completely Unattended because by making something Unattended, the business user moves out of the technical equation and the RPA team becomes the point of contact for this Automation during its lifetime.

Hopefully, the concept of RPA will become more clearer to business groups and stakeholders as days progress. But at the same time, I think the way we present RPA to them becomes that much more important.

Now why did I post this? I was talking to a person yesterday who comes from HR background. In response to that conversation, I quickly built a solution of an old RPA Challenge #16 and posted a video of it. I believe that this would give her clarity on what RPA can do for her organization. I’m posting that video here again because the RPA Challenge is now considered legacy.

These are just my thoughts and experiences. Approaches and opinions will vary.
For now, we’re more focused on how we can foresee, conceptualize and build better Human-Robot interfaces by going above and beyond the simple act of a Robot imitating human actions.
Doing so would put Business users in the driving seat and allow them to steer their automations through variations within the allowable scope of their intended functionality.

We’ve done it at least twice and we think it works! :slight_smile:

thanks! :+1:

4 Likes