READING TIME: 7 MINUTES
There are couple of questions related to Robotic Process Automation (RPA) that I still haven’t managed to figure out yet, as the answers are not straightforward in my opinion. Some of these questions are: Who is the customer when we talk about RPA Solutions? Whose needs should be fulfilled? Are there bigger principles we should adhere to other than people’s wishes? Is anyone using agile properly when they use it within their RPA projects? Can we even utilise agile in any way in RPA?
Let me introduce you to my thought process in order for you to understand where I’m coming from, as I think the answers to these questions really determine what kind of quality we deliver during RPA projects.
In the last couple of years, I’ve been seeking contents about the critiques of the current practices on how software development projects are using Agile. Most of them agree in one thing: we’re still missing the point on why the Agile Manifesto was necessarily phrased in the first place. The key though behind the manifesto is that when you have an idea of a product, you simply cannot build an entire solution based on loose ideas.
So in order to avoid such issues when you finally build everything and it immediately become obsolete and come out ot be not really what the customer wants anymore, you start delivering in small incrementations based on a Minimum Viable Product (MVP) and see how the customers/users respond to features what has just been built. In terms of response, they collect data on how frequently they use it, or whether it’s something they can properly utilise, if it’s matching with their needs.
There are two key differences when we talk about RPA:
- It almost never relies on vague ideas. You’ve got a process in hand that probably has been executed for years, even if it hasn’t been documented yet, and people are spreading the knowledge of it mouth-to-mouth like a folk tale.
- There’s no clear definition of a user, who the solution should appeal to.
Who is the customer?
There are multiple counterparts within an RPA Initiative. There’s a project sponsor. There’re the process owners. There are the process delivery departments. You probably have the internal RPA team who’s operating the solutions. And each and every one of them have a good idea on how a solution should look like. If you incorporate all of their ideas, your project’s delivery time can easily double or triple, while the benefits are not changing.
That’s the point where we have to bring in two Agile principles: (1) only build functions that they will use and what is absolutely necessary for them, (2) build an MVP first and proceed with building other functionalities later.
Do they really want a report about unprocessed items in the middle of the night, when by the time they arrive to the office the next day, the solution will process those as well? Do they really need to apply coloring to a spreadsheet that contains raw data from a website? 9 out of 10 cases, they don’t need any of these when they start to see the MVP working out just fine. When they can convince you that they absolutely need it, it has a 75% chance they’ll never use it. These figures are only based on my experience. So we don’t quite need to build overly fancy solutions, and an MVP should be sufficient for the vast majority of the processes.
But then the question arises: what is considered an MVP, especially within RPA, and in what scale of the process should we apply that? To the entire process? To a sub-process of it? To a part of a sub-process? Where should we really stop? Well, what I usually do is that I break the processes down to pieces that can produce helpful/meaningful results even standing by themselves, and search for the key business intention behind them, that is usually based on financial or operational principles.
Having principles as customers?
Alright, that was a long and confusing sentence, let me elaborate on that. You take a huge process, like a consumer loan process. Cut it up to meaningful pieces with helpful results, like loan application, credit evaluation, granting the amount, etc. And start searching for the key business intentions behind each of them. For example the main goal of granting the loan is that the customers get the appropriate amount of money debited to the given bank accounts when the firm approved their loans. This way, the core business intention with key principles will be your main RPA customers and you can avoid having long debates around what color should you apply to a report file that no one will ever read.
Serving business intentions and principles is a grateful job, since their requirements are simpler and clearer (e.g.: the customer gets the money), their fundamentals are lying within laws and regulations, and they don’t really give a damn about anything else fancy. They don’t even care if the firm’s internal rules are twisted, and you need to straighten them to simplify the execution. They give you the flexibility to do that. And as most companies should adhere to the core business intentions to stay lean without crossing the line, they are mostly persuadable to leave their old practices for the sake of common sense.
So in reality, an RPA MVP should only consist of the absolutely necessary steps to reach a core business intention by taking the main principles into consideration. Of course, the RPA solution should be sustainable: easy to operate and maintain, but we have the best practices to achieve that.
What about Agile?
If you’ve reached that far in reading this article, you’ve managed to read about two Agile way of delivery: the MVP and only building features that are necessary and useful.
Agile encourages close collaborations between several professional fields during delivery, that proves to be quite useful during RPA implementations as well, since multiple process execution-related questions can arise during developments even if our processes are thoroughly documented.
If you’ve managed to slice up your processes to meaningful chunks, the way I mentioned earlier, you can apply continuous delivery on those chunks, but you shouldn’t deliver/showcase the solutions any earlier than they become useful for the organisation. Like, why would anyone be interested in a robotic solution that can only register half of the necessary data to close a transaction? Wouldn’t really make sense, and you’d spend tremendous amount of wasted time making it presentable.
With this article, I wanted to give you a thought on how we could make everyone happy by developing solutions that are basically just doing what the business processes were intended to do in the first place, without building completely unnecessary features into our solutions. This way, we could save time and have an optimal level of complexity during our deliveries.
As I’ve seen, RPA projects could become neverending stories unless we watch our scopes closely, instead of trying to fulfill all wishes that are coming in our way. Be lean, be agile, but most importantly: be sensible.
Would you like your robots to be effective and efficient at the same time? Feel free to drop us a message and let’s talk!
Original article: https://www.linkedin.com/pulse/do-we-need-fight-off-rpa-projects-scope-balint-laszlo-papp/
