Production support

We have started to see some negative style articles about RPA, especially about scalability and maintainability. On the one hand, we are glad that we passed the period of narcissism and started to blow off the hype bubble. On the other, these articles usually depict only one side of an issue and look like fighting with windmills or trying to criticize something that one has not tried.

In this small article, we want to share thoughts about RPA maintainability and I hope to spark a bit of discussion by it.

Sheer growth of support activities

In our opinion, as a rule of thumb, you need one professional developer to support ten automated processes. By an automated process I mean an activity that with manual operations takes about 3-15 minutes and usually involves 2-5 different IT systems. For a medium-sized company, it will average between 10 to 20 bots.

An experienced team of an architect, a BA, and two developers should be able to automate about 20 processes in a year (roughly 4 weeks per process end to end from starting requirements elicitation to deployment in production).

What do these two simple metrics mean for us? They mean that in about a year, a good developer will create support activities for himself for the rest of their life.

Culprit

Let us calculate what resources we would need to automate the same 20 processes using the traditional IT automation approach. From my experience, in the companies considering RPA, the process I described before will take at least 4 months from requirement elicitation to deployment in production using a traditional IT approach. Sometimes, it takes significantly more time and almost never it takes less than 3 months. An average team for this project will at least include an architect, BA, a dev lead, and two developers. With two teams working in parallel, that approach will take a bit more than 3 years to automate 20 processes.

After three years of efforts of at least six developers, it is reasonable to expect to keep at least two developers in support in order to maintain products that have been created. Annual support cost of 15% of development costs looks like a fair amount.

Surprisingly, when we refer to RPA and the same resources for support, that number looks scary. It appears to be over 100% cost of support per development-year. Yes, RPA is very efficient in terms of development speed, but it does have the same efficiency in terms of support costs and that is I believe a very important point.

Challenges

It poses some challenges for our community. We know that everyone loves to create new functionality and features and fewer people love to maintain it. If we look at an average IT department we would see roughly 50/50 split between development and support. In RPA space, in a three year’s time, we will see 20/80 split between development and support. I believe companies should be prepared for that and act preventatively.

Can we increase RPA maintainability? We can to some degree, but there is a fundamental thing that is hard to change – process flexibility. I would expect the process to be slightly changed during the year at least 2-3 times. If the process is stable, then there might not be a need in RPA in the first place–it would probably be already automated anyway. Maintaining virtual environments, software updates, and testing, accommodating layout changes, changing of inputs and output formats–all together create some form of a toll to any automation.

Therefore, whenever we create a business case for an RPA, we should always consider hiring an additional RPA developer to support each 10 processes planned for automation. This is an additional work for a specialist to process controllers who will oversee robots from a business side and who will work on exceptions.

Hope

Since the toll of support will be very high in recent years, we need to start looking into these challenges and think about possible solutions. Here are a few thoughts regarding this.

1. Invest into robots

Invest into robots to maintain robots in order to increase developer or bot ratio for support. Current control rooms of the biggest RPA vendors are not really supporting proper bots maintaining. For example, bots can "freeze" during their execution and there is no way the control room will be able to pick it up. For these cases, we must be able to build an additional bot that will be receiving a status report from the colleagues and restart them should the need arise.

Another important thing is scheduling that takes time. In order to optimize our robot utilization, we might use these robot bosses to control the queue of tasks and distribute them among its pool of bots by applying queue optimization algorithms.

I also hope vendors will start looking into alternatives to control rooms, such as applying hive minds into robots as this would be a significantly more efficient and robust solution than control rooms. Having a decentralized brain would help robots to schedule and rearrange on the go and would eliminate risk of the system failure due to only one critical component failure such as a control room.

2. RPA developers attrition rate

Doing support is no fun, at all. Every support guy wants to be a developer, this is our realm and we need to think of how this can be resolved. One option might be in creating robot bosses that can be built by support guys. In this case, their job would be much more interesting. In addition to that, we need to create and communicate a clear career path in RPA space – what are the milestones in RPA career, what a young RPA supporter will do in one year time, what they can do in three years time. Constant reassigning RPA support developers to different teams and regular switching between development and support might be useful for cross-pollination of skills and recirculating the energy among the developers.

3. Build enough RPA developers supply

Becoming an RPA developer is not something that can be achieved in two weeks despite the fact that many vendors and training agencies claim this possibility. You can become RPA developer in two weeks only if you have a great wealth of knowledge and development experience. There are many development concepts one needs to be aware of in order to become a decent RPA developer. These concepts include: object-oriented design and programming, algorithmic complexity, decision trees and tables, visibility of variables, document object models, database design theories, regular expressions use, XML and XSD, APIs, pagination, scripting languages to name a few. There will be a shortage of people with these skills on the market and we need to invest in building our own supply of them by sponsoring additional IT courses in Universities and the proliferation of proper online education. In the meantime, our hope should be in looking at the graduates of technical universities across the world and making sure that no one quits from the profession due to lack of opportunities. Countries such as India, China, Ukraine, and a few others have a good foundation to provide such resources, and we need to find a way of efficient placement of these resources in our companies.

4. Enhance remote collaboration practices

Building robots in-house can be extremely efficient. By applying proper Agile practices, we can fire up our development speeds to unbelievable heights. However, there is no way that we can have enough RPA developers on-premises due to the sheer demand that arises. While the USA and Australia are increasing the complexity of getting working visas for offshore candidates, demand is growing, and all good resources are disappearing from the market in a matter of hours. Therefore, we have to learn how to embed RPA developers from offshore locations into Agile approach of development and support and as a result achieve levels of development efficiency somewhat close to what we can have on-premises. Basically, we need to have efficient collaboration tools for:

1. Mapping robot journeys and tracking the progress of development (as an example, tools like StoriesOnBoard from Hungarian startup and JIRA from Atlassian with story mapping add-on)
2. Screen-sharing in order to show how SMEs do their work (tools like Teamviewer, Skype, and Google Hangout)
3. Constantly switched on online chat and audio with imitation of a physical office environment (a tool like Sococo aiming into this category)
4. Online tools to share documents and collaborate on them (Google Docs, Office 365, and Confluence from Atlassian might be good candidates for this)

Conclusion

We have a challenge that we never had before and we need to act wisely but fast enough. We hope this article will sparkle some ideas in the mind of readers and you will move a step forward in our automation journey.