About the importance of RPA Maintenance: Webinar Q&A
We recently held a webinar around the topic of RPA Maintenace and its importance in scaling your RPA program. After discussing why maintenance is needed in the first place and what’s the best way to organize your maintenance unit with Coley Vahey, Country Manager US & Canada at Digital Workforce and Elias Levo, Head of Run Management at Digital Workforce, we opened the discussion for questions. We received lots of great questions during the webinar and since we couldn’t get to all of them during the session, we decided to make a Q&A post covering the questions raised by the audience. In case you missed the webinar, you can see it from the recording any time you want.
The key takeaways from the webinar included:
- How to accelerate your current RPA program?
- How to calculate the business impact of process downtime?
- What is driving the need for a dedicated RPA maintenance setup?
- How to set up your maintenance team?
- Demo – this is how a Managed RPA maintenance service works in real life
Check out below Elias’s answers to questions about RPA Maintenance!
Q&A
How do you categorize the change and decide if it should be handled in maintenance mode or project mode?
It’s important to distinguish why the change is needed i.e., is it a part of Incident Management, or is it the change requested by the business due to changes in the requirements of a process. Currently, Run Management handles all duties required to restore a process if it fails.
Incident Management – When an RPA-solution has failed
It is important that the maintenance organization is able to implement the changes required to restore the process so that the business impact of the failure is kept to a minimum. To make this efficient, we have identified two categories of changes:
- Standard Changes
Technical changes to a solution that is used to tackle e.g. changes in target applications. These typically cover re-identifying an element in the application to the RPA tool, adding to its wait time, or improving recovery logics. The Standard Changes do not impact the business logic of the process. These are also preapproved by the customer, which means that Run Management can implement these independently to ensure that incidents are resolved as soon as possible.
- Normal Changes
Some incidents might require tweaks in the business logic. If a change requires changes in the workflow of the solution, business output, or scheduling, Run Management must request approval from the customer to implement these changes.
Change Requests
When the process requires changes as of added business requirements, implementation of new inputs or target applications, or new workflows, the changes are always initiated by the business unit owning the RPA solution. This happens by defining the change. Based on this definition, Run Management creates a work estimate for the customer. In change requests, the size of the change impacts from where it should be implemented.
Run Management handles changes that are smaller than 2-3 person-days of workload. More extensive changes are recommended to be handled by the delivery unit.
Hello, would you please recommend how to attract people to do the maintenance job over the new development? As currently it is not attractive at all, so people rather do both than separating the teams.
We faced a similar situation in Run Management early last year. Partly this was also impacted by the fact that operations work might occasionally be quite hectic. I would recommend focusing on the following:
- Adding responsibilities and mandate to the unit
The Run Management team at Digital Workforce has a very strong mandate in acting as the quality gate of processes that are incoming to the service. The Maintenance unit is also acting in the longer-term improvement of the RPA solutions, not only recovering them when they fail. This makes it possible to create a backlog of development tasks to improve the solutions i.e. the maintenance unit gets to do development tasks also.
- Show the importance of the unit
As operations is typically acting when a process fails, which might create a hectic environment, it is important to actively tell about the importance of the service both to the maintenance unit and its stakeholders – What was the difference we made?
You mentioned RPA Supervisor – is this the tool created by a company with the same name and has its base in Norway?
Yes, this is the tool that we have implemented to our Robot as a Service -RPA platform.
What skills do you need to manage a bot in run?
All of our specialists in Run Management are at least accredited to the RPA tools that are supported by the service. Most of the team have also passed the more advanced certificates of the technology vendors. I highly recommend creating a strong foundation in the usage of the RPA tools. As RPA solutions have a business impact, it is important that most of the incidents are handled as soon as possible when they emerge.
The training to master RPA-tools is also available for you – all specialists on-boarding to our team go through the RPA trainings found on https://dwfacademy.com/rpa-training/. These trainings give the foundation in maintaining the solutions technically.
It is also important to focus on the processes such as Incident and Problem management and also the foundations in ITIL. All specialists in Run Management take the latest ITIL-training when joining the team.
How do you ensure RM has all the time the latest information about customer requirements for the process development? Like naming standards etc. And how you validate that maintenance quality?
This is a really important point – we have got circa 270 processes from 35 customers in the service. Ensuring the latest information from customers and a jointly agreed way of working is crucial.
We handle this with
- Strong Change Management processes
Fundamentally the naming conventions, best practice, and so on should be quite stable. If the customer would decide to change the approach in best practice and, e.g., naming conventions would be changed, we typically coordinate this jointly with the customer
- Documentation
Each customer and solution in the service has an operational playbook. If changes occur for a customer or process, this is also updated to the documentation.
- Co-operation with the customer
To succeed with a maintenance service, it is important to have a commonly agreed operating model – How do we communicate of changes, who does what, etc.
Also, a jointly agreed way of communicating changes needs to be set up with our customers – if, e.g., naming conventions would change, it is naturally important that we get this information from the customer as well so that we’re able to act.
- Daily, weekly, bi-weekly, and monthly internal meeting practicalities for knowledge sharing.
The operations unit delivering the maintenance for RPA solutions work tightly together as a global team. With the large customer and process portfolio in the service, it is important to have continuous routines for the team to go through changes in different environments.
Almost all solutions are created with templates and best practices originating from the technology vendors. This means that conceptually they are quite similar. Our team is quite experienced in working with several different customers and has the ability to handle issues even though the customer environments have some differences in detail.
What are the criteria for accepting a process into your service? Quality gate?
The Quality Acceptance of Run Management focuses on
- Solution quality – Technology vendors best practice as a foundation¨
- Production performance – The solution has been executing well during the first weeks in production (we call this hyper care). This is evaluated based on the completion ratio of the solution, i.e, how many sessions of all scheduled sessions were completed successfully, and how well did the solution process the transactions. If the solution has high crash rates or a major amount of transactions are not handled as they should, the hyper care period should be extended to resolve these problems in the solution.
- Production maintainability – This covers sufficient logging of the solution for troubleshooting purposes and the following documentation
- Process definition document to scope the current process
- Solution Description Document to explain the design of the solution
- Handover details (DWF document delivered to the customer) to act as an operations playbook
If, for example, a P1 keeps occurring for a process, do you still only pay the fixed price?
The customer only pays one monthly fixed fee per the automated business process. This means that the solution can run every day, multiple times a day or as several parallel sessions run by different RPA runtime resources.
The monthly fixed fee includes
- Quality approval, production transfer, monitoring, standard changes and scheduling of processes
All processes are monitored 24/7 by Digital Workforces automated monitoring.
In case you have any questions or would like to get more information about the topics covered in this webinar, please feel free to contact Coley Vahey, our Country Manager in the US and Canada, or Elias Levo, Head of Run Management.
Coley Vahey
Country Manager, US & Canada
+130 9532 8866
coley.vahey@digitalworkforce.com
Elias Levo
Head of Run Management
+358 50 464 6775
elias.levo@digitalworkforce.com