As technologies become more accessible, there is a temptation to treat them as consumer-based applications. When you build a Facebook page, there isn’t any thought given to requirements, testing, deployment, or production operations. You can simply use the functions and widgets made available through the user interface and add content, posts, personal details, and interests.
This ease of use, flexibility and instantaneous development ushered in by the consumerization of tech has created an expectation of seamless experience requiring no design or planning. With ease of use as one of the main selling points of RPA, referred to as “democratization” of the technology by most RPA vendors, users tend to have the same expectation as their Facebook experience. This places the focus on how easy it is to build a bot, but neglects the effort it takes to manage the bot environment.
While RPA vendors are offering robust capabilities and rapid bot advancement in their low code development kits, it is still critical to account for how your program will operate. We see many companies struggle with their production bots because they have failed to adequately plan for the necessary operational components to ensure their RPA programs run smoothly.
Here, we focus on digital operations in the continuation of our series of key considerations when scaling your RPA program.
Operations1. Embed digital and RPA into your organization in a more significant way.
Establish a traditional helpdesk support model for day-to-day issues with tier one support handled by the digital worker supervisor, and skilled RPA resources handling tier two and three issues.
Track reported complications and complete root cause analysis, which will provide you with valuable insight as to where you need to adapt and improve your program. Use these insights to immediately improve what you can, and keep stakeholders informed about future developments in order to maintain support and confidence of the teams who have embraced automation.
One effective way to gain support for proposed program modifications is to manage them like an agile team. Allow interested stakeholders to help set sprint scope, and participate in definition and implementation of any changes.
2. Managing infrastructure will become a full-time job.
If your program leverages any type of virtual infrastructure, be prepared to provide a high degree of support. Some focus areas include:
- Monthly software patches that overwrite machine settings needed for bots to operate smoothly in both a development and production capacity.
- Procurement support and installation to Virtual Machines (VM) for unique applications and software of different departments.
- The licensing costs of some applications will make it prohibitively expensive to buy a copy for every machine used by the developer and robots.
- You may need to adjust your machine image strategy to account for the needs of different departments. Different bots will need access to different software packages, which may make it impossible to maintain a single machine image.
- Process owners will need dedicated support when bots fail to execute time sensitive business processes. Typical Service Level Agreements (SLA) may be insufficient to ensure business operations are not negatively impacted. Support will include keeping the machine healthy, and troubleshooting bot failures that can span infrastructure, RPA platform, coding, and system access areas.
3. Active enablement can make a difference in both process owner perception of RPA and the speed of development.
At a program level, you may need to be more active in enabling automations. Establishing new roles is a good way to help process owners to be successful, such as:
- Helping process owners select use cases.
- Evaluate business value factors.
- Facilitate code reviews process design document signoff.
- Host use case reviews between IT security and process owners to facilitate effective communication between these groups.
- Troubleshoot code during development and deployment.
4. Design processes and tools as simplistic as possible.
Your stakeholders will have a varying degree of technical literacy. Delivering a successful bot to production has as much to do with technical competence as it does with understanding how to work in a project environment following a methodology that stresses good process understanding and some degree of formality. For example, a process owner who is operationally literate may lack the skills to meet project schedule commitments. One key area where you can help is by ensuring that they request production bot credentials early enough in order to address any issues prior to attempting to deploy the bot to production. As you develop your tools and governance processes, strive to design one that is lightweight and nimble, and that a typical end user can understand.
5. Ensure stakeholders understand the rules of the road by designing policies end users can understand.
When you need to use technology-centric verbiage in your policy to prevent ambiguity, provide a summary in non-technical language and a method for program stakeholders to easily obtain guidance when needed. A policy that nobody can understand is no more useful than lacking a policy and applying inconsistent guidance and enforcement.
6. Migrate from an inward to an outward focus.
Rather than concentrate all of your energy on how to do things better and faster internally, consider how to leverage RPA to more adequately serve your customers. This is an important pivot in order to shift to a truly digital organization. Even programs operating at scale struggle to make this change. One way to measure how well you are transitioning is to calculate the number of information domains and process silos across use cases. Collect these elements as part of the use case intake and build metrics to illuminate whether they are increasing in organizational complexity.
7. Your initial program structure may need to adapt to work at scale.
Operating at scale will affect your approach to licensing, staffing, support team roles and responsibilities. Pay attention to what is working well and what is not, and then respond. Try to anticipate where you will need changes so that your initial program structure can adapt to the new demands. For example, you may learn that decentralized development is less effective than you anticipated, or you realize that you are understaffed for centralized development because more departments do not wish to build a bot development capability within their team.
Program structure and governance is not one size fits all. Each capability of your operating model comes with advantages and tradeoffs. Finding the right balance for your organization is the key to success, and in order to do that, don’t be reluctant to make big changes to program structure.