RPA software offers users the tantalizing possibility of being able to simply 'hit record and go' at the beginning of an enterprise automation initiative. But organizations that are seeing the greatest returns are slowing the initial process down, and framing their initiatives as they would treat any major technology migration.

At UIPath’s recent User Summit in New York City, one of the hottest topics was the right pace of RPA implementation, with UIPath’s customer and partner panels devoting a considerable amount of time to the topic. And the message was clear: RPA is a technology that encourages an implementation rate faster than the customer might want to sign up for.

That very idea is a strange one for most veteran IT and business executives, who are used to IT project implementations going slower than expected, with fiscal returns further in the future than they might have hoped. So when a technology like RPA does come along that promises to enable users to ‘hit record and go’, why shouldn’t beleaguered line of business heads take those promises at face value and get moving with automation today? After all, automation is often part of a larger digital transformation initiative, with expectations that projects will be self-funding through savings. Shouldn’t technologies, like RPA, that generate material cost reductions be implemented as quickly as possible?

It’s a fair question. But there are four simple reasons why RPA projects should still be managed in a stepwise fashion, like any other IT or business project:

• Technical debt mounts quickly in too-quick RPA implementations. The ‘hit record and go’ philosophy might offer some minimal return in a short period of time, but federating the automation creation process means that multiple users often create similar automations for similar tasks, wasting time and resources consumed later in consolidating different versions of the same robot down to a single bot. In addition, individual users often create related-task bots based on their original automation scripts, multiplying the task of bot consolidation later. Often, organizations find that they have to start over completely, and only then do they undertake a more formal approach
• Installing RPA through a traditional project framework brings stakeholders together. Automation is a technology that has the potential to bring IT and business stakeholders together in an enterprise service delivery partnership – or drive them apart with turf battles and finger-pointing. Establishing rules up front for which business units should be involved in automation design, which in automation coding, which in automation governance, and which in automation innovation establishes ground rules that all parties involved can respect and buy into for the long term, avoiding larger-scale conflict that can emerge when the process is entered into too quickly up front
• Designing for scale demands both innovation and centralization. As automation demand scales both in terms of breadth of services within the organization and the number of workers involved, the need for centralization of automation design and deployment increases commensurately. Innovation can actually proceed faster in many organizations being managed from a CoE or automation ‘lighthouse’ than through trial and error at the desktop level. Add in the additional demands on automation systems that result from global organizations demanding localized automations and in-language service, and that scale factor becomes a critical component in achieving peak fiscal return from an RPA initiative
• Most RPA providers rely on integration partners for ‘right-speed’ deployment and support. Across the RPA sector, strong partnerships have evolved between RPA software developers and major integrators and consulting service providers, and for good reason – the latter bring experience in change management, process design, and implementation at scale to the former’s technological innovations. This has quickly become a proven combination, and one that is returning significant fiscal and operational value to enterprise-scale organizations. Short-circuiting that value return chain by cutting partner perspective and capability out of the equation might again save some dollars and time in the short run, but will end up being more costly as RPA is scaled up.

RPA presents IT and business leaders with an alluring combination of immediacy of access, significant potential fiscal returns, and low to non-existent stack requirements on deployment. Organizations that have jumped into the deep end of enterprise automation from the ‘hit record and go’ perspective might see some immediate fiscal returns, but ultimately, they are selling short the full promise of professionally-managed automation projects executed in partnership between lines of business and IT. Providers like UIPath that are emphasizing speeding up implementation are doing so with a structured framework in mind – so that once the process is designed for scale, and implementation rules and procedures are put in place, the actual software component of the solution can proceed into deployment as quickly as possible.

But in the end, a few additional weeks or even months spent in up-front work can better enable enterprise-level organizations to achieve their peak automation return. Moreover, this approach saves costly rework and redesign stages that inevitably stretch a ‘hit record and go’ implementation out to the same project timeline, or often much longer, than a more structured approach. As strange as it may sound, the best practices in RPA deployment involve slowing down… in order to go faster.