Inclusive Over Intrusive Growth
Objective: Change is something that can be difficult for many teams and individuals to deal with. For many organizations, the introduction of the automation capabilities provided by RPA represent a swift departure from the “It’s done this way because it’s always been done this way” approach that many operations teams take. In this learning experience, we’ll discuss some of the resistance that some organizational teams may have to adopting RPA, and how the CoE can take an inclusive approach to turn them from despising RPA to delighting in RPA.
Change is something that can be really challenging for many individuals to deal with. Change brings with it uncertainty, the potential for, at least short term, instability, and possible insecurity as change requires that we adapt to something completely new. For those that work in IT, dealing with change is really what we do on a daily basis – integrating with a new platform/service, implementing a new software, or creating a technical solution where none previously existed. In many operational roles however, change comes much less frequently, and is often times less well received. While this could seem like its “not my problem” as a CoE lead – the reality is that for RPA efforts to truly scale, automation initiatives required contributions from those outside of IT as well as within IT. For that reason, its vitally important that CoE leads are cognizant of the impact that change may have on individuals in other teams, and that leaders minimize the uncertainty that can be brought about by change through strategic efforts to engage everyone in the automation efforts.
As such, its recommended that CoE leads, factories, and business leaders take an inclusive over intrusive approach. An illustrative intrusive approach says You guys are doing this all wrong. These processes are broken and not well documented. I’m coming in and automating things to clean up the mess that you’ve created – now, get out of my way – where as an inclusive approach says Automation enables us to automate some of these tasks to focus on higher value efforts. How can people in operational roles upskill and/or play a role in the ongoing automation efforts to better facilitate the success of the program and ensure the organizational success. To that effect, lets take a look at a few examples of how CoE’s can create an inclusive environment that drives the success of RPA initiatives through an organization.
Upskilling Opportunity…with Support
The first inclusive opportunity for people in operational/business roles where RPA is being explored is through upskilling opportunities. Upskilling is a workplace practice of training/teaching employees new skills that will aid them in their work, and the ongoing efforts of the organization. Upskilling places a focus on continuous learning and represents an organizational investment into investing in employees. In the case of Automation Anywhere, this investment fortunately is free with many of the learning trails and videos available at Automation Anywhere University. As individuals show interest in learning to build their own bots to assist with the automation efforts of the organization, the CoE can point them to helpful available resources that can aid them in that journey. As individuals complete the Automation Anywhere University training, point them to tutorials/build-along-videos on the Automation Anywhere Developer Portal while encouraging them to pursue their Automation Anywhere Certification. Additionally, the CoE may consider developing some of it’s own training materials that could be taught live in person (or online) to help people learn what RPA is about and get their first taste of bot building to see if its something they may be interested in. Finally, it’s important that individuals are well supported as this may be the first development/process building that many of them have ever done – consider providing “Office Hours” for those who are new to RPA or having issues with a particular bot/feature to drop in and have their questions answered in a safe, non-judgmental space. Consider setting this time up for new developers only as to keep the questions from going above everyone’s head should a more experienced bot builder drop in for assistance.
In the Bringing on Citizen Developers learning experience we’ll dive deeper into some of the best practices for getting citizen developers (those without traditional development experience) up to speed as well as some different ways to make the best use of their contributions. For now, suffice it to say that organizations that can provide a safe, non-judgemental place for employees to explore learning a new skill that may not immediately come natural to them (building bots) – will find scaling their RPA practice to come the most naturally.
Upskilling Opportunity in Action
Maya from a Fortune 100 financial services institution developed a 1 day RPA crash course that individuals from any department in the organization could attend. The course walked through getting a workstation set up for building bots, a brief background on RPA, and several hands on labs that take students through building real bots. The bot building tutorials walked attendees through building bots that interfaced with Microsoft Excel, various web applications, and thick client apps that students at the organization were already familiar with. Those who wanted to take things to the next level were encouraged to check out the instructional material at Automation Anywhere University. Those who were not interested in building bots of their own going forward, got a taste of what bots are capable of and were given the opportunity to explore additional roles that could add value to the RPA program. The course was so successful that over 100 people were able to try it out within the first 6 months – including several executives from the organization. Not only did this provide a great opportunity for employees to learn more, but it also was great for spreading awareness for the RPA program and seeking out additional executive supporters.
Not Everyone Has to Build Bots
While providing the opportunity to learn to build bots is important, ultimately not everyone in operational/business roles will have a desire to continue learning to build their own automations – and that is completely fine. There are many roles that can add immense value to automation initiatives which could be explored by those who are not interested in bot building may find to be a better fit. While these roles may not immediately (or ever) find themselves as full time commitments, they still can empower employees to try their hand at new tasks while still contributing to the efforts of the organization’s digital transformation and automation efforts.
Process Mining: Process Mining is the exercise of identifying and documenting processes that make for good automation opportunities. As a part of this process, team members may take on tasks such as process documentation, process improvement, identification of what steps within a process would/wouldn’t be a good fit for RPA, and an understanding of the process scope – How many employees does it take to support the process? How much time does it takes to support the process? What service level agreements (SLAs) are tied to this process? Employees who have an interest/background in process improvement or who are well versed in how different business processes are intertwined typically excel in this area.
Opportunity Analysis: Bots can’t be built unless there are specific automation opportunities that have been identified and documented for a factory/CoE to build. But how do those get prioritized? Employees with an interest in the analysis of an opportunity may find that the most interesting part of the bot build lies well before the build actually gets started. In performing opportunity analysis, team members will need to gather all the information they can about a particular process in an effort to determine the potential time and dollar savings that an automation may provide to the organization. These details become especially valuable when the CoE, factory, or business unit needs to prioritize which automations opportunities should next be pursued. Employees interested in the financial/time/savings calculations of automation opportunities tend to excel in this area.
Testing/Quality Assurance: RPA developers can follow process documentation and test with all the sample data that they are given – but they still likely wont know the processes inside-out in the same way that some employees who are intimately familiar with said processes. In this way, employees who are familiar with the businesses processes being automated (or those who will be working alongside the bots for human-bot collaboration efforts) can add immense value to automation efforts by providing testing and quality assurance support. Because these employees know the processes so well, they can know when data the bot is returning may be off, or how to test the bot with different criteria. This testing is important to the bot building process as it can help reduce the incidence of a bot being deployed that fails to meet the needs of the business in a production environment. Employees who are very familiar with the organization’s business processes and/or those with an eye for detail can provide excellent testing/QA support.
Upskilling Opportunity in Action
After attending a Maya’s 1-day bot building bootcamp, Nathan was excited about the prospect of automation in the organization, but wasn’t terribly interested to continue building bots of his own. After learning about many of the supporting efforts that could add value to the organizations automation efforts, Nathan went back and did some brainstorming with his team to identify automation opportunities within their own department. Because he’d learned about RPA in the 1 day bootcamp he attended – he generally knew about many of the capabilities of the technology, and set to work documenting processes that hadn’t previously been well documented, as well as coming up with some of the metrics to help the bot building factory prioritize automation efforts. Because of the lift he had given to the factory in taking care of much of the “upfront” work, he was asked by other business groups within the organization to help with documenting and prioritizing their RPA opportunities. In this way, Nathan found that he could play an important role in the ongoing automation and digital transformation efforts of the organization without needing to build bots himself.
Change can be challenging for individual and teams to adopt. Knowing that employees may feel intimidated, concerned, and put-off going into this, CoE leads and business leaders should be ready to provide opportunities for employees to engage with bots in as many ways as possible. Leaders and RPA CoE leads can’t always make people feel completely comfortable with the adoption of RPA (change) – but its important that they focus on the things that can help minimize discomfort while individuals and teams are beginning to adopt this technology that will augment the future of their work.