1. Information security (IS) blocks, delays the start of RPA development
Excessive IS “over-caution” delays RPA development and launch—often by months. The IS reasoning is rarely disclosed, but The Lab suspects it may result from a lack of understanding by the IS organization of how RPA works at a detailed level. RPA bots simply automate tasks that humans perform daily or even hourly. Bots do not permanently store data. They present less risk than employees in IT or customer service. Regardless, IS often begins by halting bot development and subsequently requesting extraordinary, often unfeasible security precautions. These are rarely, if ever implemented. However, the net effect is typically avoidable and significant delay with no incremental gain or loss of existing security protocols/status.
Proposed Solution:
• Prior to the start of RPA development, begin by having IS staff gain a deeper understanding of RPA operations.
• Ask IS staff to identify prospective risk exposure based on this review – before development begins.
• Document clear “ground rules” for IS reviews during RPA development, including service levels of these reviews: speed, intensity, documentation.
• Project sponsors should participate in establishing these IS ground rules.
• Sponsors should prepare to initially (often frequently) “nudge” IS staff to expedite reviews, eliminate delays and generally adhere to these jointly developed ground rules.
2. IT’s exploration of non-RPA solutions (e.g., APIs) postpones development of each RPA candidate
Left unchecked, IT “solution exploration” can hold up RPA selection, scoping and development process by weeks or months (or even derail it altogether). Typically, IT staff view RPA as a “last resort” for automation. This is not because they oppose RPA bots, but rather because IT staff are often unfamiliar with the business, the business processes or business requirements. They are more familiar—and more comfortable—with traditional automation methods, such as APIs or native application development (i.e., “hard coding”). Consequently, IT staff frequently search for these more traditional, comfortable solutions in lieu of RPA bots. Unfortunately, these are almost always more costly, more complicated, less effective and slower to implement than RPA, dramatically increasing the development costs and deployment timeline for automation.
Proposed Solution:
• Prior to the start of RPA development, begin by having IT staff gain a deeper understanding of RPA operations.
• Coordinate with business units to prioritize low-complexity, high-payback RPA bots.
• Build momentum for RPA implementation by rapidly installing “simple” bots.
• Keep “solution exploration” concentrated within a small group of staff who understand:
– The advantages of RPA (speed, modularity, etc.)
– The benefits targeted by the organization (e.g., operating leverage)
3. It is difficult (or impossible) to attract and hire RPA development talent
Attracting and hiring effective RPA developers has proven difficult, particularly for banks. RPA is a relatively new technology – and developers with RPA experience are in high demand. Banking can be seen as stodgy and boring—a far cry from the excitement of cutting-edge technology. Typically, therefore, experienced RPA developers seek out, and are sought by, tech companies and similar organizations. This makes finding knowledgeable developers a challenge and complicates efforts to establish an effective RPA Center of Excellence capable of making a measurable difference reducing the manual work effort that permeates banking operations. Overcome these challenges by looking for non-traditional RPA developer candidates—people with the interest, capabilities and enthusiasm to learn.
Proposed Solution:
• Broaden the search. Instead of searching specifically for RPA developers, target individuals with experience using object-oriented programming languages (e.g., Java, C++, PHP, etc.).
• Hire from within. Identify and interview tenured staff with object-oriented programming experience.
• Look to the business units. These associates are intimately involved with their business processes, and many of them will jump at the opportunity to learn how to automate their own mundane work.
• Offer training incentives for associates interested in building their RPA capabilities.
4. High RPA development staff turnover exposes the organization
Due to high demand for RPA talent, RPA developer turnover is typically higher than-average, leaving the business at risk for significant RPA development delays. High turnover also creates exposure related to maintenance for existing bots (i.e., those configured by departing staff). To mitigate these risks, the business should look to hire from within. In addition, maintaining standards (templates, procedures, documentation) is vital to ensuring RPA program sustainability.
Proposed Solution:
• Identify and screen internal candidates who have a history (i.e., tenure) with the organization, and an interest in staying. Build around those team members.
• Supplement internal hires with new, external candidates, but expect and plan for higher-than-normal turnover for those external hires.
• Implement incentives for RPA team members. For example, provide a cash bonus for each successful bot launch.
• Develop and centrally store standard documentation “packages” for each “live” or in-development bot
• Invest in standard tools and templates for RPA scoping, development and maintenance. These ensure repeatability, predictability of RPA program processes.
5. Lack of investment in RPA training impairs RPA development/COE efforts
Management often resists investing time to formally train or develop RPA talent, despite claiming RPA as a “top priority.” In some cases, rather than devoting full time staff to RPA, organizations instruct resources to split time between RPA tasks and other existing job duties. At worst, the lack of investment in upfront training prevents the organization’s RPA program from ever getting off the ground. At best, it impairs RPA development speed, quality and sustainability.
Proposed Solution:
• Devote four to six weeks up front to formal RPA training. For example, allow new developers to complete the UiPath “academy” training, which requires about 160 hours to complete.
• Dedicate resources fully to the RPA program. Evenly splitting RPA staff time 50/50 with other, non-RPA tasks is counterproductive.