Do we really need Center of Excellence for RPA?

A Center of Excellence (CoE) is essentially the way to embed RPA deeply and effectively into the organization, and to redistribute accumulated knowledge and resources across future deployments. This is actually a shiny penny term that is used heavily in the RPA world. But unfortunately, the CoE is yet another item of absolute dogma in the RPA world that, as defined and currently implemented, directly and significantly contributes to the ongoing failure of RPA initiatives. Nearly every organization selling and supporting RPA claims that CoEs are critical to success. A Center of Excellence is NOT critical to the success of an RPA initiative. It prevents the success of the initiative and is completely opposed to what has been the unified hue and cry of the RPA world for the last decade. How could it be that consultants, vendors, pundits and analysts all be wrong about having an RPA CoE? The following points lay out my case.

CoE misconception: Excellence should be centralized 

The most important goal of a Center of Excellence is to consolidate and strengthen all expertise, experience and resources connected with RPA in a single group to maximize the usefulness of these resources in deploying RPA across an organization.  On its face, does this statement make any sense at all?  In my opinion to maximize the effective acceptance of RPA across an organization, we need to separate RPA resources from that group.  People who are already RPA experts should be put together with other people with RPA proficiency to help spread that knowledge to the rest of the organization.  

CoE misconception: CoEs Ensure Code Reuse

A Center of Excellence (CoE) allows for the reuse of code by maintaining a consolidated catalog of code and making this accessible to others. But are you sure that one BOT, built to perform a unique set of tasks, ever be reusable for another task? There is a firm belief in the RPA world that considerable portions of the code in BOT’s can be use again in automating other practices/processes. Does this make sense? Think about those manual tasks that continue in most organizations. Those tasks typically transfer data from one information system to another. Divisions between these and other tasks have been mercilessly removed from most business processes through years of Lean initiatives. Hence, these remaining tasks are inevitably unique to those systems and little or none of that task is likely replicated in another process in the organization. After closely monitoring the BOT's functionality, found that only process that ever seen have significant use is logging into a system. Most of the organization recognizes this process fragmentation as a major hurdle to scaling & adoption of BOT's.

CoE misconception: CoEs Create and Enforce Best Practices

A Center of Excellence (CoE) allows best practices for how to develop BOT’s to be collected, maintained and enforced across the organization. This is somewhat true, in that there are certain methods or techniques that are better to perform tasks or functions, but how those tasks and functions are performed in the context of an entire process is rarely if ever replicated from one situation to another. Few of the best practices that a CoE can establish and enforce add value at this granular level.  Alternatively, there exist all kinds of best practices on how to perform tasks and processes within the business function that owns them. The truly valuable expertise to be used in BOT development does not lie with the BOT’s coders; rather it lies with the BOT’s sponsor and co-workers. This expertise cannot and should not be centralized outside of the business function. All employees log into their system in the same way, but after that they almost all perform entirely different tasks and activities.

CoE misconception: CoEs Should Decide What Bots to Invest In

Many CoEs are given the responsibility of deciding which processes and tasks should be automated, based upon the belief that the CoE has the best perspective on what BOT’s are good at, and where they can add value.  But, again, if the relevant expertise in making such decisions lies with the business, not the technicians, and if in the end both the cost and the benefit of the BOT accrues to the business, it is the business who should make this decision, not a separate RPA CoE. Some CoE’s seek to be federated, where the business joins with the technology team and jointly make such decisions. This may work if all parties to the federation carry some degree of funding and cost sharing.  But to be successful, the decision to invest in BOT and not that one must lie solely with those parties who will pay for and benefit from it.  Of course, guidance from those with technical and operational experience is critical, but the decision must lie with those with budget authority.

From CoEs to CoS's

If RPA CoEs are a cause of failure, what’s the alternative?  We can call it a Center of Support, or CoS. A CoS does hold expertise, processes, tools, and knowledge for successfully creating, deploying and supporting BOT’s, but their job is to support the distributed functional expertise that lies within each business unit. The role of a CoS is to enable the business to acquire and maintain BOT’s as effectively as possible, but not to govern or control all aspects of BOT ownership. A CoS may be funded by IT, or by the business, and in either case must manage their own costs as effectively as possible as a service bureau to the business.  However, unless and until the RPA team has sufficient scale and scope to have a budget to be self-sustaining and self-funding, they should be a CoS, not a CoE.

By separating the cost of delivering RPA from the benefits of using RPA a CoS improves transparency and reduces the likelihood that the business will realize many of the financial failures.  The CoS must know, accurately, their cost to deliver and support functioning BOT’s to the business.  The business must then know what the expected benefit of that BOT will be, and if the subsequent business case is justified.  By making each party responsible for their half of the equation, there is less chance of miscommunication, manipulation or just plain old ‘happy ears’ when deciding whether or not to leverage this technology.

So, what do I personally propose as an alternative to the almighty CoE? A CoS, where all of the technical, support and project management resources are held as a service bureau, to be leveraged by the business when, where and if the business so chooses.  The CoS assists the business in determining if a chosen task or process is a good candidate for automation, assessing the costs and benefits of that BOT, and how best to create and run that BOT, but does not decide what BOT should be pursued.  When a CoS assumes that role too, they morph into a CoE, which will eventually work at odds with the business, rather than in agreement with it.  Such a CoE, may be where organization should be, even must be, when you have hundreds of BOT’s in production.  But, if we start with a CoE model, the statistics clearly show that you’ll likely never get there.

--------------------------
------------------
----------

Comments

Post a Comment

Popular posts from this blog

Generative AI & Meta-Leaders

In the wake of advances in generative AI and large language models (LLMs), there is excitement about what the technology means for businesses. But we should not forget that this advancement is also posing a catch-22 situation to the traditional leadership. The transformative potential and rapid acceleration of generative AI are creating an imperative for them to act quickly. They should rethink their skillsets and develop new skillsets like – ability to make better sense of data insights, ability to ask better questions, ability to learn from smart mistakes etc. It is true that ChatGPT has taken the world by storm. In just 5 days since its launch in November last year, it gained one million users, a feat that no other popular online services have managed to achieve. But it is not the only generative AI tool, others include Midjourney and Dall-E for images generation, GitHub Copilot for coding, and even conditional generative adversarial networks (cGAN) such as Pix2Pix, developed by
Read more

Good automation! Select right process for RPA

Someone said very rightly – “Automation is good, so long as you know exactly where to put the machine.” In all my previous blogs I wrote about BOT failure, ROI Modelling, Cost saving, RPA Governance, CoE, POC, POV etc. But then I realized that before taking a deep dive into any of these subjects, first we need to have a right RPA process identification & prioritization methodology in place. Everybody across the industry agrees that Robotic process automation (RPA) can make a big difference for organizations tormented by repetitive routine processes – the kind that suck up the productivity of people whose time would be better put toward more important work. But many are confused by what seems to be a deceivingly simple question — which are the right processes for RPA? The poor choice of process for initial pilot is the leading root cause for failure to meet customers’ expectations. Robotic Process Automation (RPA) doesn’t suit every process and in majority of cases we don’t have
Read more

RPA Exception Handling – Be in control

Companies in every major industry are turning to semiautonomous computers (better known as BOTs) to automate large- and small-scale business processes. This technology replaces human intervention in back-office operations, improving operational efficiency, reducing costs and increasing margins. However, organizations cannot employ this technology effectively unless the BOTs are engineered properly. And one of the most important component of this BOT engineering is Exception handling or in simple words right categorization of the errors and then developing solutions around the same to deal with those errors to meet the expectations of the RPA owner. Occasionally, in the course of its work, an RPA BOT definitely encounter a situation it was not programmed to handle – and, in those cases, it will stall. Those cases can be for foreseeable reasons – security or access constraints – or it can be for unforeseeable reasons – like missing or incorrect data. Increasingly, RPA developers are ab
Read more