Who Needs IT Anyway?

When it comes to Robotic Process Automation or RPA, the general school of thought is that business or process owners should take ownership. In addition, RPA tools are frequently being marketed as “programming-lite”. That is, even non-IT savvy business users are able to use the tools to configure the bots themselves.

The corollary of the above factors is that a false impression is often created. Many organizations think that there is no need to involve IT in their RPA journey.

Isn’t this great? After all, who likes to deal with IT? These IT folks speak in lingo which we don’t understand. And they are always slow, inflexible and very expensive.

Well, hold your horses.

Fact is that IT plays an important role in your RPA Centre of Excellence or your RPA tiger team, however you call them. This article explores the roles and responsibilities of IT in your RPA setup, and the common pitfalls.

Infrastructure

The most obvious area where IT needs to be involved in is infrastructure. Regardless of whether the bots are deployed on premise or in the cloud, IT needs to provision for and to setup the necessary environments – Development, UAT and Production.

This applies not only to the RPA tool itself (bots, control tower and designer), but also any applications which the bots interface with.

Accordingly, it is considered a good practice to involve IT as early in the process as possible. After all, it takes time and resources to get the required infrastructure up and ready.

Notwithstanding this, IT must be prepared to setup the infrastructure in short notice. This is because RPA implementations typically have a shorter lifecycle as compared to a traditional IT deployments. And they follow the agile, not waterfall, methodology. Consequently, you will not be able to realise the quick time-to-value promised by RPA unless your IT is able to keep up.

Access Management

Because bots mimics the actions of a human employee, you will need to grant them access to the various applications that they interface with. For accountability purposes, it is highly recommended that bots be given their own unique IDs (along with access rights), rather than to use your employees’ IDs.

Again, in most organizations, this falls under the jurisdiction of IT. For organizations which are large and complex, this request for access might take a while.

At the same time, you need to be mindful of the commercial aspects as well. Generally speaking, additional IDs imply additional licenses. So it is good to engage IT early to understand the current licensing arrangements and to work out the budgetary impact (if any).

Automation Development

There are many aspects to this.

Firstly, depending on your requirements, a pure-play RPA deployment might not be sufficient. Some of the technologies that often work hand-in-hand with RPA includes OCR and ETL. If these terminology sounds foreign to you, it’s time to consult your IT.

Secondly, despite the best efforts of the RPA software vendors, our experience shows that at the minimum, some technical know-how will greatly facilitate the development of the bots. In many cases, it is impracticable for a layman to configure the bots himself or herself.

For an illustration, consider exception handling. You cannot handle exceptions unless you are familiar with concepts like Try Catch. And exception handling is one of those things that can make or break your RPA implementations.

Thirdly, you need to ensure that your solution design, including the bots configurations, is scalable, maintainable, traceable and reusable. Failure to do so may result in growing pains as you transition from PoC or Pilot to enterprise-wide deployments. This also means that you do not realise economies of scale as you may be unable to reuse common components.

Needless to say, this is pretty much IT’s core competence. This is not to say that IT should be solely responsible; rather a cross-functional approach might be beneficial.

Lastly, do consider your support mechanism as well. The unattended bots run 24/7 so you need to ensure the proper support structure is in place. Do you want to establish your own support team, or can you leverage the existing support infrastructure that is already in place?

Governance

It’s all about governance.

Because the bots are essentially pieces of software codes, it is vital that your chosen RPA tools meet your organization’s enterprise and data security requirements. Get IT onboard early during the tool evaluation stage. The last thing you want is your entire RPA project to be canned just prior to go-live because it doesn’t meet your security requirements.

Also, ensure continuity and resilience by working with IT to architect a solution that incorporates High Availability and Disaster Recovery.

Tell me where I’m going to die, that is, so I don’t go there

This article highlights the common pitfalls that you may encounter in your RPA journey. This discussion is not meant to be doctrinal – individual circumstances may vary, thus requiring a different approach. If anything, the key takeaway here is that you should engage IT as early as possible in your RPA journey.

If you would like to find out more about this topic, please feel free to get in touch with us.

Thanks for reading!

###

For more insights and to keep up to date on the latest in Robotic Process Automation and Artificial Intelligence, you can subscribe to our mailing list on the right. Also, like us on Facebook to follow our latest blog posts. Lastly, feel free to drop us your comments in the comment box below. We would love dearly to hear from you.