Category: Uncategorized

READING TIME: 7 MINUTES

Robotic Process Automation is with us for a while now, and too many organisations still struggle to discover how high-quality robots could be successfully implemented at the fastest speed possible, while neither running out of deadlines, nor developing unreliable solutions that are not matching the business requirements.

Really impressive implementations can be attained by fine-tuning several success-critical factors, what are important before, during, and after the development of RPA robots.

1st Factor: Training, training, and training

First and foremost, you need a team of well-versed business analysts and/or developers, who can easily discover automation potentials and pitfalls, develop a reliable solution, and optimise to its best performance.

In the rush of making results out of RPA, essential trainings can be easily forgotten, resulting in subpar solutions on the way down the road, so we should be very careful on chanting “learning by doing”, because building a robot is pretty similar to building a house: without the necessary fundamental knowledge on how to use the tools what’s given, no one will be able to put together something that won’t collapse sooner or later.

2nd Factor: Quality of Planning

Let’s assume that well-trained professionals had been put together. Their first goal should be to understand the process – what they are about to automate – better than the business unit that is currently performing it.

An understanding has to be built even on a holistic view on the process: Where is it placed within the organisation’s Main Process Flow? What is the logistics/SLA of performing this task? Is there a dependency on another process to be finished in order to start our process? Is there another process that is dependent on our solution? Can we optimise the synergy between the processes?

 

 

But only having a holistic view wouldn’t enable us to automate the process with a high-quality, we need to dig deeper than that. The Process Steps have to be documented to the quality level of complete straightforwardness, that means if you bring in someone, who is absolutely not familiar with the process, s/he has to be able to perform it end-to-end without any questions, based solely on the document that has been prepared. I can assure you that your robot neither will ask any questions, nor will start to improvise, while it is doing its job.

Having your process well documented is just a really good start, but then you need to plan your robot accordingly, to match up with those requirements. That’s when you prepare your Solution and Process Design. Fortunately, one of the RPA Tool providers, Blue Prism is really giving us a helping hand on its own tool’s basic Solution Design principles.

The criteria of a well-designed robots in Blue Prism are:

1. It is Recoverable: your robot will eventually crash, so when it does, it has to be able to get back to the same point in the process, where it has left the item that is to be processed, either by itself, or after bug-fixing.
2. It is Scalable: your robot should be able to run on multiple machines without interfering with or blocking each other in any ways.
3. It is Reusable: it is highly probable that more than one of your processes are dependent on the same system that you are going to automate, so to avoid double work on developing those processes, build your components (objects and processes) in a way that those processes could use them as well.

Even though these points seem very trivial, a lot of solutions have been developed by using Blue Prism are missing at least one of these key principles. If any of these points are missing during the conceptualisation, it is really hard to implement them into the product afterwards.

3rd Factor: Fast and Effective Communication during Development

Now you have the A-team in place, and you have a high-quality plan on what the solution would look like in theory, so it’s time to start the development. Regardless of how high quality your plan is, a couple of unforeseeable issues will arise eventually that will need careful resolutions. And they need to be resolved fast, or you can cumulate a massive delay upon hesitations.

This is the moment, when you have to be really Agile, because fast and effective communication comes into the picture: issues need to be raised immediately, have to be discussed in a timely manner what is matching the severity of the problems, and a plan needs to be formed on the resolutions on the spot. One of the biggest pitfalls of RPA projects are the inaccurate or lack of communication between counterparts (even amongst team members), or delayed responses on the issues that cannot be temporarily bridged in the solution, so the development simply gets stuck.

4th Factor: Quality Solution running on a Quality Environment

How would you know if you have a Quality Robot or not? Well, the most important qualifier is that it is running as expected: accurately, stably, and reliably. It can simply recover from known Errors that are generated by the System(s) it is using, and it is generating reasonable amount of case Exceptions that are defined by Business conditions for further human processing, because those cases require special attention.

Ideally, this state should be reached by the end of the testing phases of the solution, by the time it is “going into production”. But the maintenance and monitoring of the solutions are just as important ways of quality assurance, as the rest of the steps above. Continuous improvements, fixes and patching minor errors can lead to a nearly 100% reliability, reducing time and effort on analysing the errors that are generated by the robot.

Of course, all of these are only viable on a Quality Environment that enables fast actions on the robots by its developers and its maintenance team. This involves proper infrastructure-wide installation, high-standard software credential management, and exceptional accessibility to the individual robotic desktops.

To sum up the points above

In order to increase the amount of successful implementations, you need a good infrastructure to set your team up for success, well-trained team members, who are not afraid of raising and resolving issues in a really short period of time by gathering really deep business understanding, and an exhaustive plan on the solution, so your team won’t need to improvise right from the start of the development.

Of course, these factors are not forming a comprehensive recipe for success, but I hope you found these hints useful for your future projects. If you have any other question or suggestions on how to build high-quality robots, please share them with us.

 

Original article: https://www.linkedin.com/pulse/how-build-exceptional-rpa-solutions-balint-laszlo-papp/

READING TIME: 8 MINUTES

As I’ve already written a few key things about how to build RPA robots properly, it’d be just fair from me to write something about how your RPA projects might eventually fail, so you could make preventive steps when you see the patterns of failure, before it’s too late.

Failing to combine Business Requirements with Technology

The most critical part before the development starts is that at least one person has to understand the requirements that are coming from the business and has to be able to combine those requirements with the technology that is available for the development.

It is a very bad setup, when Business Analysts only understand the so-called “business part” of the projects, and developers are only capable of formulating the “technology part” of the solution, without having any bridges between the two parts.

Wherever I’ve seen this happening, this Bridge of Understanding was never let to be built, because developers have been provided very restricted access to the Business Experts, saying that only Business Analysts should deal with “translating Business to IT and vice versa”, acting like a quasi-barriers of communication instead of understanding-enablers, even though key messages have disappeared during the translations due to misunderstandings or ignorance.

The solution is very easy: at this point, don’t just talk about “being Agile”, but let the developers have frequent conversations with Business Experts, who were performing these processes before, and help them understanding the business aspects of every process steps.

Overpromising and Underdelivering

This is a classic mistake, when inaccurate estimations are made right at the beginning due to the demolished Bridge of Understandings, and/or not having stable processes to automate in the first place.

UiPath is providing a very insightful Solution Designer guidance on how to estimate the effort that is needed to build a robot, and the most important thing they’re highlighting is that it is very difficult to estimate the build effort of something that has (never been built before) so many uncertain components.

I especially “love”, when one of the three sins are committed:

1. Making an estimation and setting up a scope, before someone with a high level of technical understanding would have seen the processes: having yes-men arranging scopes and deadlines is a setup to fail, regardless of the office politics.

1. Estimations are made based on the number of steps, not on the complexity of those steps

1. Abilities of the RPA developers and organisational bureaucracy are not factors when calculating the buffer-time: Building RPA robots is not a sprint, it’s a marathon for most of the organisations due to this.

The solution for these issues is not that easy: you need to have a Solution Designer, who has an understanding on both the business and the technological aspects of the RPA developments, and let him/her deal with the estimations and scoping.

Choosing the wrong tool

We have 3 leading RPA tools (Blue Prism, UiPath, and Automation Anywhere) on the market, but neither of them are ultimate solutions for your automation projects. Having only one of these tools are limiting the possibilities of implementation optimisation, but surely everything looks like a nail, if the only thing you have is a hammer, and a Swiss army knife cuts well, but you won’t start to maw the lawn with it.

The nature and the logistics of the process determine how advanced tool you need to choose for its automation. The systems used during the individual processes, the possible scalability needs, the process inputs’ and outputs’ complexity should be all part of the evaluation.

The solution for this is relatively hard: you need someone, who is aware of the capabilities of all (okay, at least two) of the above mentioned tools, and who is able to identify their suitability for the candidate-processes.

Sugarcoating

I’d say, from all of the points I’m listing in this article, this is causing most of the troubles during RPA developments. When it turns out that massive sugarcoating took place during the project, the consequences are usually disastrous.

Let’s imagine that the Process Discovery have failed, so your RPA developers don’t understand the process they need to automate. The deadline is not reasonable given the constantly emerging issues, but developers are not allowed to liaise with the Business-side for a fast resolution. The scope during the development has shifted, so the Solution Design can go into the dustbin, but this has only been announced with a two-weeks delay, when half of the product was already built. And the tool that has been chosen for automation turns out to be insufficient for the process that is about to be automated, so the developers are scripting crazily to develop additional functionalities that are missing from the RPA tool.

And when all of the above happened, somehow the project’s status is still GREEN, the deadline hasn’t moved even a day forward, even though it is obvious that it won’t be kept, but the communication goes like in the well-known meme below:

 

 

To be honest, to identify the sugarcoating from the outside of a project team is a challenge in itself. If you have a feeling that everything goes too good to be true, your gut-feeling is most probably right on this: someone is sugarcoating, so below the surface, something bad is already happening.

Well, isn’t it Agile enough to ask the developers halfway-though the deadline to show you the parts that are already working? If they can’t present you some progress, you can be pretty sure that someone is sugarcoating the sad facts.

It is very hard to solve the nature of the problem, because it is originated from fear. Unless building team-wide trust is a viable option, having someone who can objectively evaluate the progress on the projects is necessary.

Wanting to Sprint before Learning to Walk

RPA is not a field of immediate Big Wins. After choosing some tiny Proof of Concept processes, organisations tend to gain so much self-confidence that they immediately choose their most complex processes as automation candidates regardless of the fact that most of their developers have just learned how to use an RPA tool, and the logistics of building a robot (a.k.a. Delivery Methodology in Blue Prism) hasn’t been put in place yet.

Immediately implementing huge and buggy solutions will result in 3 main things:

1. Low morale both on the Business and the RPA side due to having no success stories, but failures and a lot of time spent on reworking the solutions
2. Bad foundations for future projects: as you haven’t started small, so the developers didn’t have time to experiment with the tools, and acquire the best practices. This results in medium competence and low understanding of the tool: a really bad combination.
3. As reusability and structuring were not aspects (since they didn’t even know about the existence of such aspects) during the development of the robot components, your team will need to redevelop the components again for their future projects.

The solution for this is highly depending on whether you’ve already committed this mistake or not. If you haven’t done it yet: it’s very easy, you just have to make sure to start small. If you’ve already made the mistake: you need to take two steps back, put the Methodology in place, train up your RPA team, stabilise the robotic infrastructure that includes fixing the bugs in the legacy processes, and after you’ve done all these, you can roll out with new projects.

To Sum It Up

As you can see from the points above, an RPA projects don’t collapse because Agile Methodology hasn’t been used during the developments. Projects collapse because certain crucial elements of Agile are missing, what would make sense adding without even thinking of Agile in the first place. I’d worth an article to write about what to use in RPA in terms of Agile, and what to definitely avoid. Maybe next time…

Should you have run into challenges in automation or be about to start using RPA, drop us a message and let’s start a discussion!

Original article: https://www.linkedin.com/pulse/rpa-project-has-collapsed-why-balint-laszlo-papp/

READING TIME: 6 MINUTES

I like to get to know new people, who are dealing with RPA, and I like to generate RPA-related contents, and the reason for these is quite simple: I get to know how we are currently dealing with Robotic Process Automation. And the current situation is – based on the insider information I get from various RPA experts and the reactions I got to my posts and articles – RPA really suffers to scale.

The reason for this suffering is that we hardly ever see the RPA Trinity put properly together: Methodology, Infrastructure, People. So let me elaborate what went wrong with these attributes that are necessary for a successful RPA Initiative.

Methodology

Even though leading RPA providers are giving us a ready-made Implementation/Delivery Methodology, we tend to reinvent the wheel just to feel smarter than the Best Practices.

RPA has a necessarily heavily documented way of delivery, and every document has a reason. The Process Definition Document (PDD) serves as a future reference for the process we automated, and a Business Continuity backup plan, if something goes wrong with the robot. The Solution Design Document (SDD) serves as a blueprint for our solutions before development, what we need to develop solutions that are medium or high complexity solutions, and serves as a snapshot of what has been built after we have developed our robotic process.

If you leave any of the above, you might feel that the developments are faster, but when you’d like to examine the processes in the future, you’ll spend loads of time reverse-engineering your past processes searching for reasons why they have been built like that. Ian Barkin is already foreseeing RPA Forensics experts in the future, who are specialised in such field. (Ian, if you are reading this, thank you very much for the hint, I already see what I’m going to deal with in the upcoming years!)

Couple of RPA Initiatives are neglecting documentation needs, and when they asked why they don’t do it, they just give a shrug and tell that they use Agile instead.

I wrote an article about robot development, and it only got a tiny fraction of the attention of my articles about robot planning and robot testing, so I guess RPA Teams are just constantly developing robots without a second thought whether they do it right or wrong. Without proper planning and proper testing, we can already place a bet on those robots’ (in)stability.

So the common methodology issues with many RPA Initiative is that they don’t emphasise on the planning and testing parts of the delivery, they just aim on development, and then they are surprised why their robots are barely coming through the pipeline or running in production the way they are intended to.

Infrastructure

I wish I could say that I’ve seen many proper Robotic Infrastructures, but believe it or not, they exist! What amazes me is that every leading RPA Tools have infrastructure setup guides to reach the maximum stability and security.

Yet, I’ve seen an infrastructure that was in an open office environment unprotected, you just needed to turn on the screen and you had complete access to the robotic control environment, and even to the resource machines, where they had their core ERP system installed with an SSO instance. Just imagine the catastrophe a stranger could cause by sneaking in, turning on the screen, logging into the ERP using the robot’s SSO, downloading the whole GL, and stealing it.

Another infrastructure has only Production Environment, where they conduct developments, testing, and live runs. A third one has mainly community versions installed on several laptops, and only a couple of virtual desktops has been set up as developer environment in order to save license cost. So their robots have been developed without the ability to connect to the main robotic database, where they could use Queues.

Security, Stability and Scalability are vital attributes of a properly built infrastructure. If we save effort or money on achieving any of these, that will hinder the build of quality robots.

People

Robotic Process Automation is still about people, who are collaborating to reach the most optimal solutions possible. Subject Matter Experts, Process Owners, Business Analysts, Solution Designers, RPA Developers, all are key stakeholders during robot developments. A chain is only as strong as its weakest link, so the disengagement of any of the areas above can cause serious troubles within the RPA Initiatives.

Subject Matter Experts are the ones, who come up with automation ideas, and who need to show their processes thoroughly in order to capture all the necessary details. Without their engagement, RPA Initiatives will fail to extend their pipelines.

Process Owners know the core business intentions of the processes, so when there’s a better way of conducting the process itself, they can evaluate if a change like this would undermine the business intention or it would result in a valid improvement.

Business Analysts are capturing the processes properly, and asking all the questions that are important to prepare the design of the robot. If they miss key knowledge about RPA, they’ll miss the whole point, and will fail to record everything necessary, resulting in additional negotiation rounds between the RPA Team and SMEs.

Solution Designers will prepare robotic blueprints based on the findings of the Business Analysts. If they don’t thoroughly understand the capabilities of the tool they are working with, their design will be subpar, so if a design like this will be handled over to a junior developer, the failure is guaranteed, as they’d not be able to improvise for the missing robotic components.

RPA Developers will build the robots themselves. Their competence on using the RPA tool is paramount. If they lack training on robot development, exception handling and best practices, the projects will result in subpar solutions.

Engagement, competence and collaboration between these participants are crucial for our success. We should avoid common pitfalls that would result in complete meltdowns.

Takeaways

RPA, especially in Hungary is yet to scale due to the lack of properly built elements that are mentioned above. Many first generation RPA CoEs that has been set up are waiting to be fixed before they could scale further, while second generation RPA CoEs are fortunately built on the lessons we learned from the first generation centres. I think the future is still very promising.

In case your RPA program seem to have got stuck or you are about to do it first time right let’s talk!

Original article: https://www.linkedin.com/pulse/why-rpa-suffers-scale-balint-laszlo-papp/

READING TIME: 6 MINUTES

The biggest question what the entire Robotic Process Automation (RPA) industry faces nowadays is that whether RPA will elevate or evaporate as a consequence of the current conditions at many companies, given that most of them have switched to survival mode as a response to the crisis.

I always firmly believed that RPA is a crisis-resistant technology to the level that RPA will even blossom at an event of an economic downturn. Now’s the time to see whether it was a false hope or a visionary divination.

What happened in the offices?

I really wouldn’t elaborate on the current market conditions, but more on the changes and challenges of the way we work in the offices, because in a blink of an eye, we were told in most countries to stay home and possibly avoid going to offices to limit the impact of the pandemic on our everyday lives.

And, oh boy, the vast majority of the companies were not prepared for that kind of BCP event. The paperless offices (like most Shared Service Centres in Hungary) struggled the least, they just had to make sure their staffs are well equipped for this manoeuvre. But they still feel the pressure that if this pandemic will escalate further, they could easily find themselves in difficult situations.

And there were the less digitally advanced offices (and even countries), where they needed to come up with something out of the blue, rearrange the SLAs, reorganise their teams, equip their staffs with the necessary tools to be able to work from home, and find out a way of handling the paper stacks to be able to carry on with their business critical activities. They faced this situation pretty much unarmed.

What happened with RPA?

The sudden impact varied depending on how well-established the teams were, and how seriously the higher management considered RPA as a business critical investment. It’s not a secret that most companies just got their hands on this technology and made mini-projects out of it that were crawling for years without a meaningful progress. Or created an insignificant initiative to test things out without disrupting much process-wise.

Meanwhile some new entrants had serious plans on an organisation-wide roll-out right from the beginning, so they built strong foundations: well-trained teams, excellent infrastructure, and a well-working delivery methodology. So they’ve managed to make an impact either on a smaller or on a larger scale.

In places, where the higher management’s commitment was negligible, the RPA teams’ budget is drying up, and are suffering pipeline-wise as well, so they are pretty much balancing on the verge of existence. But well-supported and well-established teams with a practical mindset were able to find crisis-critical processes that can help their organisations move forward, and they came out the gates storming to deal with the changed circumstances.

And here comes the brand new initiatives of the firms who waited for this technology to mature in order to consider making an investment into deploying it. RPA is inevitable.

What will change?

There’s a bad joke within the RPA industry saying that robots won’t ask for a sick-leave or a holiday. This only partially true, but nonetheless offensive statement has become exceptionally important in an event of a global pandemic generated crisis. Businesses have started to worry about the vulnerability of their own workforces, hence their entire business activities that are relying on them.

So the RPA ROI equation has immediately changed in many businesses’ mind with several factors on the benefit side, that should have been long considered other than the FTE savings they could reach by automation:

1. The value of a business process: the P/L impact if it’s not getting performed
2. The replacement cost of an expert to conduct the process: the cost and length of hiring, on/off-boarding, training, etc.

With these new aspects to think about, that 0.21 FTE activity conducted by a folk getting only £47k p.a. that implicitly ensures that the largest subsidiary’s cash liquidity has not dried up, or could prevent a £53m penalty that could come from regulators/authorities, might get a whole new shine on the RPA roadmap with its £247k cost of automation.

It’s really Time to Go Digital…

For RPA to excel, we need structured data getting manipulated or transferred by optimised and well-though-out (even on keystroke-level) processes. Having digitised data is a no-brainer for paperless offices, it’s more of a challenge for the rest. But having high-quality, structured data and well-though-out, even thoroughly documented processes are too often missing throughout all kinds of business units.

The first steps should be:

• Transforming the processes to eliminate paper-based documents as a medium of information (digital transformation), or at least implementing intelligent document processing tools in order to get structured data out of them (digitalisation)
• Documenting all processes on a keystroke-level with special attention to accurately clarify the decision points (whys) and process paths (hows).

Without clearly understanding the mere purpose of our processes, and without having the right tools, we cannot even start thinking about the optimal way of automation, not to mention making a proper design of the robots we need to build.

What’s next?

As Phil Fersht wrote, RPA died at many organisations. As I see, the common reason for that is that they failed to utilise even a quarter of the full potential of this technology. Now that the ROI equation has changed, these failed RPA projects will get a second/third/fourth chance. But this time they’ll have serious management commitment, so it’s really up to the competence of those involved in these new initiatives, whether it will succeed from now on, or fail for the last time.

If you are interested in the ways robots could help your organisation adapt to the ever recurring operational challenges do not hesitate to contact us!

Original article: https://www.linkedin.com/pulse/crisis-has-come-whats-rpa-balint-laszlo-papp/

READIN TIME: 7 MINUTES

Using Robotic Process Automation as a technology together with Lean Six Sigma to release bottlenecks, increase capacity and processing speed, and reduce errors is no-brainer. It’s not a trivial question though on how to use Lean methods while building RPA solutions or how RPA can use it to improve its own outputs. Nevertheless it worth giving this topic a thought or two.

1. Processes on Macro-level

It’s a widely known misconception that RPA should only focus on task automation. If that would be true, we should call it Robotic Task Automation, but we don’t do it for a reason. RPA Teams have to know how their solutions will fit into the wider landscape of enterprise processes.

This way, they should not only transform the tasks the business area wants to get automated, but have a say in how to modify front-to-back processes too, so the organisation can avoid having siloed processes that would result in no significant throughput improvement, as the system as a whole will still be just as slow as a sloth.

2. Processes on Micro-level

To quickly switch focus from macro to micro, the robotic solutions’ underlying tasks should be as lean as possible too. Robotic solutions should almost never replicate the processes the exact same way humans can do it, for two different reasons: our robotic capabilities can either do more (calling APIs, processing faster) and less (cannot improvise and deal with ambiguity) than their human counterparts. Let’s see what we should consider when we discover and document our processes, and design our solutions.

2/A Dig to the Core

It’s far not enough to know just as much from the processes as the person who’s performing it currently. Most often than not, they don’t really understand why those tasks have been designed the way they are executing them in their current states. So we must be more knowledgeable than that in all circumstances, since we are looking for the core business intention of the process.

Core business intentions are always the most simplistic description of a process we should adhere to. Maybe during the years, those tasks changed due to various reasons, but we need to dust them down to find why that process is designed to do and whether it’s still necessary.

When we find the core of the process, we won’t be arguing about details that don’t matter (like what colour should the fonts have when the solution sends out alerting e-mails), but we can rethink the entire setup. You wouldn’t believe, but there are undocumented processes, where they cannot recall decision points in the right execution order, so we need to detect and correct logical errors to comply with the core business intention.

2/B Cut the scope

“We want to get everything automated!” – Hold on champ, you probably don’t have the budget and time for that. So are we gonna just automate “the happy-path”? It’s not that simple either. Let’s consider the 80-20 rule. 20% of your process scenarios are executed for 80%+ of the items processed. If that’s not true, your process is either not standardised (go and reengineer it), or cannot be standardised. Either way, you shouldn’t deal with automating that in a condition like this.

So for the sake of saving development time and budget, and not overcomplicating our solutions, we need to focus on thoroughly discovering and documenting that 20%, and try to find ways on how to detect the rest, so we could send them for human handling. Scoping our processes right is not just saving time, but makes the maintenance more sustainable as well, if we don’t need to make sure that our solutions can properly process improbable scenarios that occur once in a decade at best.

2/C Technology optimisation

Due to robotic solutions’ better IT integration and capabilities, we can rethink the way a process can be conducted. For example no human can fruitfully use API calls, and generating XML/JSON files instead of using the application frontends. Captchas are there for a reason too, the data providers often forcing organisations to subscribe to the content they provide via webservices.

We shouldn’t tweak Excel files from the MS Excel UI, and we shouldn’t do that with Access databases or any MS product with appropriate interfaces either. Robotic solutions should only consume and output well structured data. If we can clean up a file’s format in order to achieve that, we should definitely go for it. No messy files or data structures are acceptable.

2/D Keystroke optimisation

In my opinion this could bring the least value for our solutions, but brings some value regardless. Keystroke optimisation is achievable if you know the core systems capabilities better than the person who’s executing the tasks on them. Knowledge about shortcuts within systems comes with time, when similar subtasks are getting automated spanning across various processes, and one team knows a better way on how to conduct them than the other. Reusable robot components play a big role in increasing developer efficiency in such scenarios.

3. Delivery Methodology

When we talk about Robotic Process Automation, we shouldn’t just take a look at business processes that should be automated, but the delivery methodology RPA uses to handle robotic solutions’ discovery, design, development, testing, deployment, operations and maintenance.

It’s somewhat true that every handover points could decrease the quality of the final solution. This is simple due to loss of information or misunderstanding the whole concept of the process that is about to be automated. Better documenting our own solutions is just one part of the solution, cutting the handovers by merging roles is another way to speed up deliveries. Of course having combined solution designer and business analyst roles has its cost, but the benefit of that is exceeding that at least double fold, as the maintenance cost will be significantly lower in the long run.

We should not just avoid the quality deterioration, but in every stage, we should focus on increasing the quality by documenting the process better than it was previously detailed, creating a better robotic solution design than the current state of process design, and developing it better than it was executed before. This will enable us to have more stable operations than we had before using RPA.

To sum it up, even if we don’t use the lean methodology in its classic form, the core mindset is still critical for the success of Robotic Process Automation.

In case your RPA program seem to have got stuck or you are about to do it first time right let’s talk!

Original article: https://www.linkedin.com/pulse/what-should-lean-rpa-balint-laszlo-papp/

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:

1. 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.
2. 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/

READING TIME: 6 MINUTES

It’s not a secret that before I started to deal with Robotic Process Automation (RPA), I worked at several large companies mainly in the mid-, and back office functions doing the exact same things I’m advising to automate nowadays.

Based on this hands-on experience with processes that are more suitable to be conducted by robots than humans on a daily basis, I advise RPA teams to look into more about why a process is conducted in the first place, and if it is a part of a much bigger picture, start cleaning them up by consolidation and standardisation before turning to automation. If we don’t do these steps together with a digital transformation initiative, we might end up with an unsustainable RPA even though it’s not the fault of the technology at all.

The steps we take before turning to automation are just as critical as defining, designing and building an algorithm (robot) for conducting our processes. But with all these, are we thorough enough to focus on the real value of processes, or are we automating just for the sake of automation? Let me tell you a couple of stories from my pre-RPA “career”:

Yes, I like to correct the same mistake… every single month!

I can hardly remember the specific details of this process, but the nature of the problem was that a withholding tax was booked incorrectly to one account instead of a different one… So my job would have been to check that general ledger account monthly for that erroneous entry and make a post so the amount is reflected on the proper account afterwards…

And I was like: how ignorant do we need to be not to find the source of the mistake and correct it there instead of patching the problem by conducting extra work? So I needed to send like 3 e-mails to find out that the person, who did this mistake didn’t even know that he was doing anything wrong, because that account was set to be the default for him when he was making that transaction. They changed the process on their side, and poof, I had one less task to do.

Calculate the value!

This one is a classic… I was given a task to calculate the value of around 150 trades one-by-one for a monthly valuation task. It took around 1.5-3 minutes to calculate one depending on the server’s calculation capacity and the complexity of the deal, so you can guess that this wasn’t my favourite process at the time, but people were conducting this for years before me. I couldn’t accept the reality that this was the best way to get the unadjusted value of such trades. So I raised an IT ticket in hope that they know a better way to get these out somehow.

Guess what, they knew a better way! As it turned out, the system has already calculated the amount on every closing cycle, so it took around 3 minutes altogether to get the results. Just imagine that a 1.5 hours long chat with an IT guy can save 60 hours a year, and I didn’t really need to use any automation, only a VLOOKUP in Excel. So, 300+ hours well wasted in the previous 5 years…

Hello! Are you there?

I needed to send a couple of information to fellow teams, as we thought these are essential information for their jobs to do. Well, I was always a bit sceptical about the reports I needed to send automatically to people I didn’t know anything about. So one day, I decided to put the following request to the top of the e-mails: “If you still need this info in the future, please reply to me!”.

Well, 3 out of 4 hasn’t replied so I knew they don’t need this information anymore. The 4th one came back to me saying: “Geez, are you still sending this? I don’t even remember why we needed this back then!”. Fair enough, 30 minutes less work for me, mate.

Faulty metrics

I could go on with these kind of stories, but I guess now you get my point: the fact that a process exists doesn’t mean that it has a purpose or it is necessarily creating a value that justifies the cost. That’s why I encourage everyone, who think that the single source of truth for measuring the benefits of RPA is the number of FTEs saved, to reevaluate their metrics.

What value would you put next to your processes? What are the possible consequences if you’d stop doing them? Are there any alternatives that are available for conducting them?

The value of a process equals to the value of the benefits it supports to achieve and the value of the unfavourable consequences it helps us to avoid.

These processes above had an FTE cost, surely. If you consider that a month-end-closing needed to be done in 5 working days and there was a plan to shorten that to 4, half a day per month worth like 0.125 FTEs! But would you rather spend money on building and operating robots for processes that has no intrinsic value, or make some calls and write some e-mails to eliminate them altogether?

That’s why we need to revise, reevaluate and restructure our end-to-end processes, instead of just throwing robots to tasks in the middle. The former is the most valuable… the latter is just too easy…

Would you like to implement robotic solutions that add real value to your business? We are happy to share our experience in selecting winning use cases as soon as you write us!

Original article: https://www.linkedin.com/pulse/processes-value-rpa-pipeline-creation-fallacy-balint-laszlo-papp/