Ownership of RPA should be with the business

Technology, such as Digital Workers (RPA), is integrated in everything we do these days. For example, cars have embedded software. Is that software owned by IT, just because it is software, or should it be owned by the business, as it is part of the product that the customer derives value from? The line is blurred. We have seen approaches from – “it is software so it should be owned by IT” to “the business owns everything”.

In an agile world, business is ultimately accountable to the customer so they should own everything. The business needs to determine priorities, requirements and the timelines by which results have to be delivered. IT can provide skills that facilitate the process, cover gaps in skills but ultimately deliver to the targets set by the business.

So, where does the ownership of the technology asset lie in the end? Philosophically, the organisation as a collective owns it. However, if we need to pinpoint down to an individual/role within the organisation, it should be the person that is accountable for the service that the technology enables.

RPA, i.e. Digital Workers, can be confusing. RPA is a piece of technology that is deployed to automate repetetive tasks. Whilst it is software, RPA is designed to aid a business user in carrying out their tasks. The ownership, i.e. what it needs to do, when it is needed by, etc., for the solution should lie with the business.

This is tricky in financial services where the use of software/computing applications is quite strong. This makes IT a powerful force in the organisation and the procedures that they follow are quite “robust”. Since RPA is a piece of software, it is but natural to think of it as an IT project.

Taking a lesson from manufacturing in the previous century, this behaviour is analogous to the traditional batch & queue manufacturing. In the late 1900s, when the the airline industry was booming, large companies in the industry were struggling with internal batch & queue procesess and siloed thinking. High costs, long lead times and defects were ingrained in almost every organisation. In an industry where lives literally depend on reliability, costs, lead times, and rooting out every defect was like gospel.

However, this was not sustainable. They couldn’t keep pace with customers. In the second half to late 1900s, most companies started implementing Lean Manufacturing by focusing on value, the customer and eliminating waste. One of the critical steps in this journey was re-defining ownership of value to the customer and giving that role authority to make changes.

For RPA, financial services organisations must adopt the principles of lean manufacturing by means of adopting Agile. By focusing on value generation and making the ownership of value clear, they can increase speed of deployment, eliminate defects, cut down on waste whilst increasing customer/employee experience.

Two of the key benefits of this shift highlighted by CIO.com (https://www.cio.com/article/3393473/the-agile-approach-five-benefits-for-financial-services.html) in an opinion article are a shift from a project to a product mindset and innovate continuously and responsibly.

We believe that taking an agile approach for RPA in financial services is a must if the automations are to deliver quick and reliable results.

In a recent deployment at a customer a shift from agile to traditional waterfall approach (why this happened is worthy of a book rather than a blog) resulted in the project taking 3x longer than planned. The results were more reliable but speed was lost and any change now is slower to roll out as it has to go through a long process of testing and validation, just like an IT project. The business has become a consumer/recipient of an IT service rather than the owner of the automation.

Get success with RPA – ask us how.