RPA: The Next Chapter In The Automation Story

Panel Discussion

We are talking about a very exciting technology that is transforming businesses and even our lives, that is Robotic Process Automation or RPA. The panelists are two analysts working in the customer experience field and two IBA experts.

Mark Hillary is a British technology writer and analyst, based in São Paulo, Brazil. Mark contributes to the global media focused on technology and has written several books on technology.  Mark advises national governments on technology policies and has advised the United Nations on the use of technology for development.

Peter Ryan is one of the foremost experts in customer relationship management. Peter received numerous prestigious awards in the customer experience field and is included in each iteration of the Nearshore Americas Power 50 influencers listings. In cooperation with Knowledge Executive, a specialized research & media house working with C-Level executives, Peter conducts annual vendor surveys to identify Top Offshore Customer Experience Delivery Points. This year, South Africa was selected as a number one BPO destination.

Therefore, we are going to discuss RPA in South Africa as a part of the generic RPA topic and I invited Dimitri Denissiouk, Managing Director at IBA South Africa, to help us explore the topic.

Sergey Zlobich, a Project Manager at IBA Group, will share a technical perspective on RPA, based on his many-year experience in RPA projects.

WHAT ARE THE BENEFITS OF RPA?

Mark:

I think that we’ve known about automation systems for a long time. We’ve seen workflow automation, but what’s really kind of changed with RPA is the ease of creating the automated workflows, so you know it’s very much focused on using a graphical user interface to train the agent or the bot in what needs to be automated, so that’s one of the big differences here that it’s much more simple now and really the business benefit is around reducing repetition, reducing mundane workflows, where I’m often writing about the customer service, customer experience space.

We see contact center agents that are often using multiple systems and transferring customer information from one system to another and traditionally this has been quite a manual, mundane repetitive process. There’s the potential for introducing errors, so you’re not only automating tasks and making it faster and simpler, and easier, but you’re also reducing the possibility of introducing errors as well. So there are multiple benefits.

Peter:

South Africa was selected as the most favored offshore location by enterprise customer experience buyers and I think there was a number of reasons. They’ve been very active and very aggressive in their promotion to the key demand markets, that is the United Kingdom, North America, Australia, and New Zealand. That’s one reason. I think another reason is the fact that there is a very strong reputation for quality in South

Africa: quality labor force, the willingness of the agents to be problem solvers and to go the extra mile and certainly a great cultural and linguistic affinity with the consumers that they tend to support now in terms of your question around the benefits of RPA. I think that Mark laid it out very nicely. I would say that from my perspective what I’ve been observing the length of time I’ve been in the contact center and the customer experience space.

Automation has had a series of stops and starts when I first got into this game in 2003-2004. There was talk that automation was going to kill the call center, was going to get rid of all the agents and everything was going to be automated, but very quickly we saw that the technologies were being deployed too aggressively without being stress tested properly and it sort of went into hibernation.

It’s had a rebirth of sorts over the past several years and I think with very good validation too the solutions are much more apropos, they’re much more realistic. And I think that the key benefit we’re seeing now is taking the mundaneness of an agent interaction at least in the initial stages out of a telephone call or a digital interaction, and what it’s doing is helping the workflow move a lot more quickly and a lot more efficiently. So, by the time you get to an agent, if you need to get to an agent after going through the automated interface, there’s a much better chance that your issue will be resolved in a more expeditious fashion from the standpoint of automation.

I think that there’s been some great strides, especially with the implementation of artificial intelligence and drawing that into the ability for automation to be able to interact more seamlessly, but the development continues and I think that the benefits are going to be seen for some time, especially as the competition in terms of the developers that are bringing the new solutions to the forefront, improve their solutions, and make them even more customer ready.

Dimitri:

Mark and Peter already talked about some of the obvious benefits. There are even less obvious benefits that RPA can bring, for instance reducing the risk because otherwise you would need probably to integrate two business applications and this is the risk of an impact on the existing environment, while RPA projects are generally low risk and let me call them non-invasive. They don’t disturb existing systems. Another non-obvious benefit is minimizing exposure of sensitive data, because now the robot works with the documents that may contain some private or sensitive data instead of humans. So there is less risk of exposure for this data.

Sergey:

I would like to add that we all think of RPA as a tool to improve some existing business processes and make them better, smoother, but actually, the technology also allows to introduce a brand new customer experience. It is faster than usual human processing. With a usual business process, it would be submitting requests and then after some time coming with a response that could be implemented at the same time. I mean with a short waiting time, which is measured in seconds instead of hours, so that is also a great benefit that technology can provide.

SOME COMPANIES COMPLAIN THAT RPA IS COSTLY. LET'S TALK ABOUT THE TOTAL COST OF OWNERSHIP IN RELATION TO RPA. HOW DO WE MAKE IT LOWER?

Peter:

I think that the discussion around RPA is one that has been lingering for a long time, but I would put it like this. When you find a good RPA system, one that works really well, one that has been stress tested and proves watertight, it’ll pay for itself very quickly in terms of being able to route customer interactions, in terms of being able to solve some interactions upfront and effectively, what that means is that you’re reducing the need for the human element and what we know is and I’m sure Mark can back this up that roughly speaking, the human element in a contact center accounts for 70 to 75 percent of the cost, depending on the location that you might be in now. When you factor the opportunity of taking the human element out of the contact center and being able to replace some of that with an RPA solution, that certainly might have an upfront capital cost, but will be significantly lower over the long term. I really believe that that’s a very compelling economic argument for deploying the solution, but the key here is to make sure that it’s going to be an efficient solution, one that’s going to work well, one that will obviously need tweaking and updating, but one that you can count on to get the job done, that will be a very cost-effective play over the long term.

Mark:

Yeah, I would just say that, and it probably goes to Sergey, that about half of the TCO is probably your development and deployment of the system itself. You know you have ongoing licensing and maintenance costs afterward, but the biggest chunk is to create it in the first place. So, I guess, working with the company that is implementing the system for you, and helping you to find the best vendor, you know, this kind of investment upfront in finding a great partner. Well, like IBA Group, for example, but this really does impact massively on the total cost of an RPA project.

Sergey:

As Mark said, I am usually on another side. When we are talking about the total cost of ownership, and we are saying that it is high, we always compare it with economics and with the business benefits we get from RPA implementation. And if that cost is not less than the benefits, that means probably that the business processes, which were implemented and automated, are not picked correctly, maybe they are not optimized enough or good enough to be automated. My idea is that for good implementation you should not think about having the total cost of ownership lower, you should think about making business benefits minus the total cost of ownership bigger, so always try to focus on that, not on just minimizing the total cost of ownership.

Dimitri:

I agree with what you already said. I can just add that the total cost of ownership consists of multiple elements or factors. It is license fees, development costs, the center of excellence, operating costs including OCR (optical character recognition), and maintenance of the platform, and also I can add business process maintenance. So, if you are looking to reduce or make it lower, then you need to analyze each of those elements, each of those factors, and see what can be done there. It’s a holistic approach. For instance, regarding license fees: you can compare what different vendors provide or even go for a platform with zero license fees. About operating costs: some OCR tools have a pay-per-use model, which means the more documents you recognize, the more you pay, but there are also open-source engines. So it’s really is a holistic approach.

WHAT WOULD YOU SAY IS BEST: CITIZEN DEVELOPERS OR PROFESSIONAL DEVELOPERS IN RELATION TO RPA?

Mark:

I think, this really depends on the kind of policies you’ve got within your organization, how you control source code, for example. I do think that, in general, we are moving towards an environment where professionals outside of the IT industry will need some sort of basic understanding of tools, like how to code a basic automation system. So we can imagine a future world where lawyers, accountants, doctors can learn how to automate processes that they previously couldn’t have. But clearly, you have the problem of source code control. I mean, if you have a big enterprise and you’ve rolled out a system and then everybody in the company can just tinker around and play with it, then clearly it can introduce problems. It’s a question of balance, how you control the system that’s being used.

Peter:

I really couldn’t disagree with what Mark said. I think that it’s great to have a robust team of people who have got their own ideas in terms of how development has to go forward.

That’s how we’ve seen some of the best innovations in technology over the course of the past two or three decades, and some of the huge leaps forward that we’ve all experienced as business people and consumers. At the same time, I think Mark is banging on in the sense that, unless there is some overriding control, in regards to how a community of developers is going to tinker and tweak around the edges. That could introduce more problems, so certainly encouraging innovation, encouraging, trying new things is absolutely essential, but making sure that there is some level of coordination is going to also be imperative.

Dimitri:

I would personally go for the Pro Developer approach because for Citizen Developers developing bots or automating the processes is not the main task. His or her focus will be shifted to their main duties. For Pro Developer it is the primary task. And, moreover, the Pro Developer has more experience, obviously, so, the bots created by the Pro Developer will be more reliable or easy to maintain and less error-prone. So I would go for the Pro Developer approach.

Sergey:

I’m a little bit an interested party here. So, I am on the developer side. I can see benefits for both approaches and, actually, the main benefit of the Citizen Developer approach is that it is very fast. So, if a business person does know the business problem and can do programming, then he can create his bot in several days, maybe even hours, if it is a simple bot, and you will never get that speed with separate developers. You will need to get a solution, design, budget, and time allocation and that is slower. But to advocate professional developers: all that steps are still required because when you create a good solution design, you usually ask some questions which you may not think about previously, and the questions or answers to the questions, could change the automation dramatically. So, instead of doing something very fast, you do the right thing slower and I think the second is better.

HOW ABOUT CENTERS OF EXCELLENCE? ARE THEY REALLY NEEDED? AND IF YES, SHOULD THEY BE IN-HOUSE OR EXTERNAL?

Mark:

I think that what we’re talking about here is changing the culture of an organization. If you are the CFO and you can see the potential for the organization of automating many individual processes, then you need a way to demonstrate that across the entire enterprise. I think that you definitely need a center of excellence to demonstrate the value of RPA. Personally, I would think that it could work internally or externally, but if you’re going to do it externally, then you need to have a – again, like I was saying about the implementation, – you need a partner that you can rely on, and, maybe, an independent partner, not a partner that is tied to one particular RPA vendor, for example. So, if you’ve got a great partner, then you could do this externally. Otherwise, you know, clearly, it’s a kind of an evangelism role within the organization to show people what’s possible.

Peter:

I think that some of the best innovations we’ve seen have come out of centers of excellence. And one of the things that I’m encouraged at, especially as I visit my friends in the CX technology industry, is to see so often that they have set up their own centers of excellence. Their own laboratories, in which they go out, they hypothesize, they construct, they test, and if it works – great, if it doesn’t – they start over. The reality is if you can have centers that are going to spend their entire time and are dedicated to developing the best possible solutions, whether it’s automation or otherwise, I don’t see anything wrong with that. I definitely agree with Mark that you should not exclude the possibility of working with outside partners that are in a position to bring perhaps solutions that the contracting organization might not have thought of. They can bring these to the table using an external organization that certainly has a great deal of merit in regards to making sure that a client gets the best possible technology that they’re looking for, that’s going to help them innovate, that’s going to help them position themselves more competitively. But the reality is: the only way the industry is going to move forward, in automation or any other aspect of a technical solution, is by developing that critical mass around thought leadership, trying new ideas, going out, making sure that these ideas are given as much scrutiny as possible, that they work. Take them out as aggressively as you can, implement them as aggressively as you can. If they don’t figure out and don’t work, then start afresh.

Dmitri:

I think it’s continuing discussion on a Pro-Developer and Citizen Developer. Regardless if we have business users or professional developers who create bots to automate some business processes, the question is who will own this bot. I mean, who will document it and maintain it, because in the future, if a business application got screens changed, this bot will stop working. So someone needs to fix it. I believe that bots should not be owned by individual business users or pro-developers, but should be owned by the organization itself. Therefore, the organization needs a unit, which will own those bots, will govern them, do all the maintenance, document them, and maybe it will have some guidelines and standards all the bots should follow. Therefore, this unit is definitely needed in organizations.

About external or in-house: I think, there is a mixture. The organization can have a hybrid center of excellence. That means some of the employees are in-house, and some are from a vendor or external partner. There is no standard. So each organization should work out its own way. I know that one big telecommunication group of companies of South Africa and southern Africa has around 80 employees in-house in the center of excellence and around 20 are external. So, this is like 80 to 20 proportions. But again, this is not a rule and each organization should check what works best for it.

Sergey:

Let’s make it short. When we are talking about a Center of Excellence, we should not think about a fixed structure. It’s an evolution. And in the very beginning of that evolution, it is very reasonable to involve some external vendors who will bring their expertise to help set it up fast and to a minimal required level. But then, ideally, I think that each organization should try to make it in-house, have an in-house center of excellence. I like the idea of a hybrid center of excellence. When you have some people in the center of excellence in-house and some are offshore developers, that should work and that is perfectly fine. But to my understanding, somebody should always be in-house.

HOW IS RPA GOING TO DEVELOP?

Mark:

I think that we see a difference between attended and unattended RPA, and the complexity of something that’s simple for a human like looking at a document and understanding the information there is actually quite a complex process. You need to digitize the document, you need to extract all the information, you need to validate whether it makes any sense, is correct. I think that you know the development as we move forward will be in the area of AI and machine learning, and being able to do those kinds of things that are simple for a human when you’re attending the RPA session and training a bot, so that more of it can actually be unattended, more intelligent systems able to learn from repeated processes.

Peter:

Everything Mark said, I think is bang on. There’s going to be a lot more development in terms of that unattended element and the ability to learn from what previous tasks have been. Equally, I think that automation is going to be a lot more straightforward not just for the individuals that implement the solutions for a client, but also for those who manage them. I think they’re going to be a lot more intuitive, a lot more user-friendly to the point where somebody who perhaps doesn’t have a great development or technology background will be in a position to administer them. And I also think that we’re going to see those smart solutions that Mark referred to become much more customer-friendly and I think we’re going to see that the basic automated solutions that are handling customer management query right now become much more complex in terms of the type of interactions they’re able to drive, which is going to benefit everybody.

Dmitri:

I concur with Mark and Peter, and I think that there will be more cognitive capabilities in RPA, so it will be able to automate not only simple workflow processes, but more complex business scenarios and it will manage unstructured data as an input or natural language or perhaps it will do some data mining and analysis, and maybe predictive analysis. And I think that all the RPA platforms will have machine learning and AI capabilities.

Sergey:

Almost everybody said about some cognitive capabilities and I agree that it would be definitely one of the points. I think that another point could be when the software would write its own code, write itself on its own. Several vendors already come to market with a solution that monitors user actions. They see repetitive actions across multiple users and after that, they provide information on these actions. Once you have that information, it is very easy to actually write a business process. So that can also be done automatically. Ideally, there would be a system, which is watching the employees saying ‘hey this is something that could be automated and it is automated automatically.

Irina:

I think this is a topic we could talk about for a long time. Probably, we should revisit it later on in the year to see how we are getting on. I’d like to thank Mark, Peter, Dimitri, and Sergey. Thank you for your time and your fantastic discussion. Thank you so much everyone for joining us. Please keep an eye on our publications, both text, and video. We hope to see you again soon.

Get in touch with us, if you are interested in learning more about RPA or other topics. Please share your thoughts and offer your topics for future videos by leaving your comments or suggestions here.