Automation Maintenance and Support – A Necessary Evil ​

Just saying the words maintenance and support can prompt scowls and groans. But a thoughtful maintenance and support strategy for your automation program is critical to success.

Why?

Without one, whoever developed the automation will end up supporting it. While this may work for the first few weeks the automation runs in production, failing to create a strategy ensures the time needed to develop subsequent automations is debited by the amount of time spent on maintaining and supporting the automations already in production. As more automations go live, more time is spent on maintenance and support; this hinders scaling.

Strengthen your relationship with IT and specific automation stakeholders

A maintenance and support strategy should include specific components; the first is about stability. Why do automations break in production? There are several reasons:

1. The user interface and/or application changed; since RPA typically interfaces with application screens directly, changes to the layout or other attributes can cause the automation to fail.
2. Something in the environment changed; these can include system pop-ups or upgrades to core software such as Microsoft Office, etc.
3. Inputs changed; what the automation is expecting has changed
4. Missed requirements during the development process

Any of these scenarios can happen at any time in the automation environment, creating a lack of visibility into changes until they occur in production.

In an ideal scenario, the linkage between the automation program, specific automation stakeholders and IT should be very tight. When an upgrade is pushed to SAP, for example, there should be testing of the automations in a non-production environment before the upgrade is live, so automation changes can be handled proactively. Nearly every automation center of excellence (CoE) sees this as a problem. The problem may seem small if a CoE has deployed a limited number of automations. But when scaling to a large number of automations, this can become a major problem. 

Boost the benefits of existing automations and continuously improve digital labor

The second component of the maintenance and support strategy should be benefits realization. Many would say that, once the automation is developed, the benefits are calculated and the team should move on to the next one. And for the team developing the automation, that is correct. But this misses a potential “boost.” Part of a true maintenance and support strategy is continuously evaluating the current automation estate to determine how additional benefits and value can be brought forward. This requires a close relationship with the associated business stakeholders. 

Consider automation A, which is being used by the Finance organization. A monthly governance meeting between automation stakeholders for automation A (and other finance automations) and IT will help confirm the following:

1. Any issues with the automation, including suggested fixes
2. Processing metrics specific to the benefits of the automation, including numbers of completed transactions and processed dollars of transactions
3. Automation platform metrics, with statistics for utilization of the automation and associated platforms
4. Enhancement requests
5. Upcoming changes from IT, the automation platform and the business
6. Optimization suggestions from the automation CoE, the business and IT

Automations should undergo a yearly health check to evaluate ongoing benefits to the appropriate stakeholders. Do not leave an automation to run in perpetuity. Opening the dialogue with the business and IT in a monthly governance meeting will give you an opportunity to discuss how to bring additional benefit. 

If you are a business stakeholder working with digital labor and automations, have you ever looked at the automation output and then spent another hour or two manipulating it? Or taken the output and then performed two or three additional steps that could be automated? This is the “boost factor.” 

Benefits of existing automations can be boosted simply by exploring possible extensions to the front or back of what has already been built. This is not limited to RPA – consider all forms of automation technology to boost the benefit! This is often a missed opportunity for both opening up dialogue with the business and maximizing the value from automation.

Create an automation inventory and build maintenance and support checkpoints into the development lifecycle

No discussion on maintenance and support is complete without mention of maintainability. A citizen developer approach can make maintainability even more difficult because it requires consistently applied standards and common elements. If your CoE uses multiple vendors and citizen developers, maintainability may already be an issue.

Begin by creating an automation inventory that lists the associated automations, stakeholders and application interactions, including application environment availability, benefit metric measurement, bot/automation ID, health check date and common object usage. This will also help when IT informs the CoE of an upcoming upgrade or application change; the inventory can be used to identify which automations are impacted.

Maintainability is also enhanced when the maintenance and support team is involved early in the development cycle. After all, they will be the ones supporting the automation post go-live, so it only makes sense to involve them early in the development process. Be sure there are checkpoints at each of the following stages:

• Design – a review by the maintenance and support team may identify considerations about how the live environment acts since they have day-to-day experience; it also may provide recommendations on the overall design and usage of common objects.
• Last sprint of the development cycle – review the end-to-end automation running in the development environment and all artifacts including the final design document and runbook / operations guide.
• UAT – ideally, the maintenance and support team is heavily engaged in UAT as this should be as close to production simulation as possible; automation behavior should be understood by maintenance and support as well as how the business engages with the automation, the automation output and the maintenance and support team.
• Hypercare – engagement during hypercare is critical to see what issues crop up when executing in the live environment, including updates to the automation and runbook; coming out of hypercare, the maintenance and support team should have a thorough understanding of the automation as well as any backlog of issues or change requests/enhancements.

Identify your approach to staffing maintenance and support – consider a partner

Last but not least, don’t forgot the people side of maintenance and support. If you’re reading this, you might be saying to yourself, I have fewer than twenty automations, so this seems like overkill. But I would ask you to consider why you have only twenty automations? It is likely you are unable to scale because of a lack of reliability, maintainability, governance, communication or strategy related to maintenance and support.

Central to a strong maintenance and support strategy is the people performing the roles and responsibilities. As mentioned earlier, too often the developer inherits maintenance and support obligations because no one else is identified. Or it is thought that the business users/stakeholders can perform maintenance and support. Neither one of these approaches is sustainable.

A dedicated maintenance and support function is required for an automation program to be successful.  Resources need to be focused on maintaining the automations as well as performing enhancements and “boosting” the existing automation estate. Additionally, the platform requires occasional care and feeding to keep current and ensure new releases are tested appropriately. Many automation programs try to do this in-house and typically fail.

Maintenance and support is considered by many to be unglamorous grunt work. It can be hard to identify resources who want to do this work and then want to keep doing it. Turnover and attrition are high. Once an individual is experienced enough with the platform, they often want to work on new development. This is one of the reasons why we see in-house programs fail and why the task of support may fall to the developer who built the automation.

As someone who personally worked in maintenance and support for almost a decade, I will say it can be a very exciting role. Consider how your CoE will position this role and the potential for career growth. Consider the following:

1. Typically, maintenance and support teams support automations built by a number of different developers. This allows them to get to know the methods that were used so they can understand why certain approaches work better than others.
2. Interaction with the platform at a deeper level will help the folks tasked with maintenance and support to learn the ins and outs of the platform itself.
3. Experiencing the need to triage quickly can develop skills that otherwise would remain undeveloped.

How should you staff your maintenance and support team? Consider the needs of your automation program, the growth in the coming years as well as your expansion into other automation technologies.  It may make sense to get help providing this function from a partner. However, if your program is staffing this team in house, ensure you have solid roles and responsibilities along with a clear job description, identify a career progression plan for the team members and treat the maintenance and support team as a critical part of the overall program.

There is absolutely no need for an automation CoE or program to struggle with scaling if there is executive commitment to the program. A strategy for maintenance and support is critical to elevate automation benefits. If you are struggling, ISG can help. Contact us to get started.