Abstract
The teaching case addresses the governance of robotic process automation at Nordea, a large banking group operating primarily in the Nordic region. Nordea has deployed numerous software robots, for a wide range of business processes, from transaction-processing work and both internal and external reporting all the way to interaction with end users in handling of General Data Protection Regulation (GDPR)-related queries. The scene is set with a meeting where three people discuss the current state of robotic process automation implementation at Nordea: Group Head of Robotics Agnieszka Belowska Gosławska, Head of Robotic Process Automation Operations Piotr Stolarczyk and Acting Head of Robotics Execution Jaroslaw Motylewski. The presentation outlines several governance-related issues and decision points that must be addressed in connection with any deployment of robotic process automation at somewhat large scale within a company. The key issues are related to the software’s development and maintenance, robotic process automation governance and IT infrastructure. Students who have worked through the case should be able to (1) describe archetypal and hybrid governance modes for robotic process automation and (2) evaluate their advantages and disadvantages for solid infrastructure and effective software development and maintenance.
Introduction
On a sunny Monday afternoon in July, Agnieszka Belowska Gosławska (Group Head of Robotics), Piotr Stolarczyk (Head of Robotic Process Automation (RPA) Operations) and Jaroslaw Motylewski (Acting Head of Robotics Execution) sit down in a cool, air-conditioned meeting room overlooking Helsinki’s ‘Finance Valley’, Vallila. The whole city has been bathed in sunshine for weeks, with temperatures rising above 30°C, which is not that common in this northern capital. For the past few years, Agnieszka and Piotr have been preoccupied with numerous implementation projects deploying RPA, and development meetings such as this one are long overdue. Now, there is finally time to sit back and take stock – to discuss the current state of RPA at Nordea Group and plan its future evolution and growth.
Nordea is the Nordic region’s largest financial services group and one of the biggest banks in Europe. The group serves close to 10 million personal-banking customers and more than half a million corporate clients in four Nordic countries: Denmark, Norway, Finland and Sweden. Nordea has its origins in the Nordics, having been formed through several fusions of traditional Nordic banks, mainly in the 1990s. Currently, Nordea employs around 30,000 personnel and enjoys annual operating income of EUR 9 billion, with total assets of EUR 550 billion to its name. Group headquarters is in Helsinki, where we join our trio.
Nordea is similar to most large banks in actively pursuing the deployment of RPA in several areas of business, and this development has brought the number of RPA implementations to today’s 360+ robotised processes. Illustrating the wide variety of business processes currently handled by software robots, Agnieszka and Piotr review the list of RPA-infused processes, which range from processing transactions, through reporting (internal and external), to interacting with end users by handling GDPR-related queries.
At the beginning of Nordea’s RPA journey, it was not easy to determine which processes would be suitable for such automation. Today, however, the bank has a relatively clear approach to discerning suitable potential: the processes should be high-volume, regular, batched, reliant on structured data and stable systems, and subject to few planned changes and upgrades. Although RPA is poised to disrupt work processes and even annihilate some jobs, most employees – to Agnieszka, Jaroslaw and Piotr’s surprise – are not opposed to RPA. They have identified software robots as a good opportunity to offload mundane, manual actions and thereby focus their attention on more meaningful, value-adding work.
‘So, we have come quite a way on our RPA journey and been able to prove that RPA is a useful tool for us, right?’ asks Agnieszka, continuing: ‘What do you see as the main areas for improvement, going forward?’ Piotr ponders for a while and then says, I see at least a couple of areas that we should really address. First, we should be able to centralise more, so that RPA deployments across Nordea can become more financially efficient, or stay decentralised but be more efficient in executing the processes. Anyway, I feel that we really need to boost efficiency in completing RPA projects.
Jaroslaw adds: ‘We should also be able to better manage reusable components and make the most of them. I’m thinking about a repository of past RPA objects, used in older bots. How could we leverage those for the future?’
Agnieszka listens carefully to the concerns of the other two. She then responds, I agree – we need to address the challenges related to the governance of RPA at Nordea. It feels that we need to seek the best possible balance in our hub-and-spokes model, with, on one hand, centralisation in the form of a centre of excellence handling most parts of the RPA transformation and, on the other, decentralisation in the form of satellite business units having responsibilities related to RPA. We would need to take a deep dive into that and critically assess our fundaments for moving forward. Also, as it was decided last year that we are an SOD [segregation-of-duties] business function, we need to stay efficient as a business-driven unit, co-operating closely with other functions, including Group IT. What makes this set-up so demanding is that RPA is, by nature, something that the business side needs to drive but, at the same time, we have to remember the importance of compliance and security requirements, which need to be aligned and governed in collaboration and with mutual support among all the business functions involved.
Piotr nods in agreement and continues the line of thought: ‘It seems that this is developing towards a quite straightforward workshop assignment. How should we proceed? I’m swamped with deployment work for several software robots, with limited time for this type of assignment’.
The three feel that a shared view emerging from brainstorming would aid in analysing the current situation and developing guidelines for future action. However, they conclude that, for this sort of assignment, a brainstorming workshop involving any external consultants is not consistent with Nordea’s policy. At this point, Agnieszka thinks of a thesis-level student recently recruited from a local university’s business school as a trainee member of the RPA team. She sends an instant message to ask about availability. The student quickly replies, asking for details about the assignment. ‘Why don’t you join us? We are in the Finlandia meeting room’, Agnieszka sends back. Not much later, there is a knock on the door. The student enters the room, and Agnieszka, Jaroslaw and Piotr begin explaining the assignment.
Setting the scene – RPA’s penetration of knowledge work
Piotr opens up his laptop and hooks it up to the projector. ‘Although you are probably very familiar with RPA as a technology and with the opportunities it gives companies, maybe it would be useful to review the main traits of the technology, so that we are on the same page’, he says. He starts explaining. A slide appears on the meeting room’s projection screen, outlining the main characteristics of Nordea’s RPA journey.
Almost 10 years ago, the bank initiated broad-based centralisation of business functions. One key element of this was the initiative of building the Nordea Operations Centre in Poland. This enabled many services to be simplified, improved and optimised in the course of migration between countries. It also served as concrete proof of Nordea’s multinational pedigree and inclusive culture, through streamlining aimed at taking advantage of broad and multilingual talent pools (Piotrowicz and Kedziora, 2018).
The background information clarified the definition of RPA, as a set of tools to emulate human actions in computer systems. The piece of software typically interacts with graphical user interfaces, performing the actions a human would take with the systems. This approach has turned out to be one of the most impressive and popular means of delivering efficiency gains in repetitive business processes quickly (Kedziora and Kiviranta, 2018). Because RPA is rules-based, configuring the software necessitates breaking down the underlying business process into unambiguous rules. Often, the configuration work for RPA, by breaking the business process into components, reveals deficiencies in the logic applied. That, in turn, results in natural, incremental improvements to business processes.
RPA is often regarded as the epitome of lightweight technology (Bygstad, 2016), in that it is relatively easy to implement and does not require heavy IT investments. Sometimes, the RPA implementation can even be completed without the involvement of the company’s IT department (staff often refer to this phenomenon as ‘bypassing IT’).
Several decisions face a company that envisions embarking on an RPA journey. First, one must evaluate the company’s business processes and decide where to implement RPA. The second issue involves the system type – for instance, the company needs to choose between proprietary and Open Source RPA systems. Another of the decisions is whether to outsource any steps in the development and deployment. Finally, larger organisations in particular need to establish a governance model for their RPA.
Regarding the first decision, companies may choose from among several frameworks that can aid in evaluating the various business processes’ amenability to RPA. With RPA’s central advantage lying in its efficiency, high transaction volumes and susceptibility to human error are often seen as indicating the suitability of a given process for RPA. As long as the company’s system environment is stable, RPA can be configured to access data from multiple systems, so the criteria of stability of the system landscape and a need to access multiple systems are frequently applied to RPA candidate processes. Since RPA is rules-based, a suitable task for it can be decomposed into unambiguous rules and exhibits low cognitive requirements with regard to its processing. Owing to the nature of RPA as rules-based and targeted at high-volume operations, a process highly amenable to RPA often exhibits limited need for exception handling (Asatiani and Penttinen, 2016; Penttinen et al., 2018).
Traditionally, companies have addressed the second decision listed above by opting for established RPA system providers such as Blue Prism and UiPath. Recently, RPA software based on Open Source solutions has entered the market. Driving ‘democratisation’ of the RPA landscape, these solutions enable companies to implement RPA without the prohibitive annual subscription costs associated with commercial RPA products. The main obstacle in using the Open Source solutions without an intermediary is that one must carry out scripting or programming work in the development and deployment phases. Therefore, acquiring commercial RPA software remains the most popular way to implement RPA. Partially because there exist only a handful of commercial RPA system providers, in contrast to the wide range of Open Source variants, numerous local entities can assist in the implementation of commercial solutions. This leads to the third decision, on the extent of outsourcing in an RPA project’, says Piotr. He continues his presentation by addressing it.
In any RPA implementation, companies need to consider what to outsource, to how great an extent and to whom (Asatiani et al., 2019b). In the end, configuring and deploying such automation is a highly local endeavour. The company must understand that, however wise it might seem to outsource the development to external service providers, even a very well-implemented RPA solution requires some element of constant monitoring and maintenance. Whenever the system encounters a problem, a human agent must step in. The company utilising RPA must have processes in place for catering to these unexpected events, known as escalation procedures. ‘So, you understand that outsourcing includes considerable risks from a maintenance perspective?’ confirms Piotr. That said, well-established service providers’ extensive experience in RPA implementation enables them to assist in shortlisting suitable software vendors and identifying processes suited to RPA. Piotr says, ‘They can even assist in the RPA configuration’; however, he concludes thus, ‘But I really feel that any company implementing RPA must accumulate the relevant, necessary competencies in maintaining the RPA’.
Sensing that Piotr has reached the end of his review of RPA technology, the student takes the initiative: Thank you for this informative presentation of RPA, Piotr. While I’m quite well-versed in RPA, I didn’t know that there are so many things that companies need to decide on before moving forward with it. If we now turn more to the issue at hand, what seems to be the most pressing concern at Nordea with RPA? In other words, why am I here?
The current RPA governance model at Nordea and the pain points identified
Agnieszka responds, ‘Before you arrived, we talked about some of the issues we’re having with RPA development at Nordea. Many of them revolve around governance matters. Here is a slide that depicts how RPA is organised and governed today at Nordea’.
The RPA governance model at Nordea changed 3 years ago, with a transition from siloed, small RPA teams operating in separate locations to the hub-and-spokes model currently employed. Before that transition, some small pioneering efforts and pilot projects were completed with Blue Prism software, but those initiatives were in no way mutually coordinated. The systems were built independently by business units with varying understanding of the technology and related methods, and the projects were handled locally, with no common guidelines in place. Hence, the early years of robotic operations at Nordea can be described as decentralised.
Things changed as the number of active RPA projects grew significantly. At present, Nordea acts from a centrally operated centre of excellence (CoE) that applies the above-mentioned hub-and-spokes model for RPA work, designed to render all benefits and costs associated with RPA transparent. The CoE team began by creating mutual alignment internally and a shared focus that would allow Nordea to start taking steps towards becoming an industrial-level user of RPA. Today, Nordea has more than 300 robotised processes, translating into 4.3 million cases handled by robots – equivalent to returning 427,000 usable hours to the business. The company employs 130 people working with robotic activities. In addition to bringing consistency and accountability, the chosen governance model boosts the efficiency of RPA deployments: the scale efficiencies of the CoE as the hub are complemented by local knowledge held by the business units that form the spokes. The CoE itself uses a model of operation that concentrates on three core aspects of the value chain:
‘Laying the tracks’ that enable robotisation: the platform, guidelines and sign-offs (Robotics Strategy and Methodology);
‘Building the trains’ for developing the software robots (Robotics Execution and Robotics Development);
‘Running the trains’ for day-to-day operation and maintenance of the robots (Robotics Operations).
Thus, Nordea’s hub-and-spokes model is a hybrid model built around four main units: the Strategy and Methodology Team, the Execution Team, the Development Team and the Operations Team.
The Strategy and Methodology Team
The Strategy and Methodology Team is a small group focused on developing foundations, a solid framework, standardised documentation and best practice for the robotics CoE. Facilitation is an important part of the team’s work. Nordea perceives RPA as an enabling technology for implementation of its company strategy, one geared for efficiency of business processes, and it is the responsibility of the Strategy and Methodology Team to ensure a good fit between pursuit of RPA and Nordea’s strategy. The team are responsible for making sure that a solid methodological frame is in place for the transformation connected with RPA, so as to ensure strategic alignment with Nordea’s IT and the company’s compliance capabilities, resources, systems, employees and processes. In each project, the team’s core responsibilities include establishing a stable environment for RPA’s smooth integration with other systems and with group policies, to guarantee that the software performs in line with the intended outcomes.
Also, the Strategy and Methodology Team is designated as the owner of licencing relations with the robotics CoE’s key vendors. This demands in-depth follow-up on the dynamically evolving Blue Prism platform and the licencing models involved, ‘keeping an eye on everything’ to make sure that the bank gets the most from its vendor’s solution stack. One key factor in this is that the platform is far from static, so the team must address the latest elements to be incorporated into Blue Prism’s client and cloud solution both, such as the Process Discovery tool, a function called ‘Decipher’ that provides optical character recognition (OCR) functions, and the Digital Exchange app interfacing with online shop functionality, all of which employ pre-built cognitive technologies linked to the system’s elements of artificial intelligence via machine-learning connectors. Hence, the team can be understood as a source of product management capability. This is articulated in the scope of its ownership, which covers the entire robotics services portfolio and the standard-framework approach applicable throughout the automation cycles: from an idea’s submission and evaluation, through solution development, programming and deployment, all the way to production use and continuous improvement.
The student has been paying close attention to what Agnieszka and Piotr have to say about Nordea’s approach to RPA. Beginning to gain a better understanding of the Strategy and Methodology Team’s roles and responsibilities, she interrupts by probing potential challenges facing the team: As I understand it, the challenge for the Strategy and Methodology Team involves unclear aspects of responsibilities for ensuring effective future development of software robots once they’ve been deployed. The RPA landscape is changing rapidly, with introductions of new features to the RPA technologies and with those technologies’ coupling with various evolving advanced technologies such as machine learning and OCR. Now that Nordea has designated teams responsible for distinct sides of RPA development and deployment, one can ask which team should be accountable for extending the current deployed robots and making them more efficient. Also, which teams should be assigned the tasks of gauging these technologies’ feasibility for the automated processes or soon-to-be-robotised processes? Today at Nordea, this responsibility seems to be scattered across several teams in that the day-to-day work of Operations Team members includes observing the robots and drawing conclusions, while business-related contact is handled through the Execution Team and still other work is done by the Development Team and Operations Team as they maintain the robots.
Piotr nods in agreement and responds, Ultimately, the hands-on knowledge and competence should be ‘on the ground’, resting with the people who configure the robots. With regard to selecting the optimal integrated technologies for automating the selected set of tasks or the given process, this should be subject to broader discussion, with an analyst and developer paired up to guarantee alignment between business needs and practical ways of addressing them. But before any of this is possible, the Strategy and Methodology Team must gather basic knowledge of these technologies and conduct proof-of-concept projects. These are run independently of normal RPA projects, so they shouldn’t affect delivery of the Blue-Prism-related robots or the operations part of production.
The student nods and continues, The second potential pain point I can see here is related to difficulties in reaching common understanding and approaches to things like documentation, vocabulary, and common reporting practices across all four core teams. There should be proper formalised communication, business-review, and reporting mechanisms designated across all teams, but that would be difficult to achieve since the members of the various teams have such different backgrounds. Their completely different education, approach, and mindset mean that the Execution Team’s business experts speak a different language from the engineers in the Development Team. Also, it would be ideal to involve representatives from all the core units in developing the methodology and templates, but, again, there are difficulties due to the differences across teams.
Piotr muses, I’d say we should build on diversity instead of making it a blocker. Clearly, the language, experience, needs – sometimes even personal priorities – differ, but at the end of the day they should be aligned with the robotics CoE’s mission, vision, targets, and key performance indicators. The success factors will consist of 1) a uniform understanding of what we as the robotics CoE strive to achieve and of the performance level desired; 2) regular management reviews of performance and actions where needed; 3) a clear mandate and set of responsibilities for the Strategy and Methodology Team as the team accountable for methodology, documentation, and standards; and 4) collaboration across the value chain, for optimal results. Let’s remember that the standards that hold up best are the ones that operations teams understand and commit to. Those teams’ engagement in establishing and improving on certain ways of working is the key here. I would challenge the claim that it’s difficult to involve people because of differences. They will get involved as long as they see that the intention is to make things better or easier.
The Execution Team
Also small, the Execution Team is a global constellation of local individuals who are the ‘spokes’, acting as project managers and pipeline hunters. Composed of business analysts representing each respective country where the company operates, this team serves as a bridge between Nordea’s internal deployers of RPA and the robotics CoE. The Execution Team focuses on promoting the use of RPA across the group’s various business units, teaching the local units about RPA and its key features and benefits, searching for processes amenable to automation and rendering the selected processes ‘robotisation-ready’. Later in the work cycle, the members work alongside business experts to analyse process descriptions from an end-to-end value chain perspective in an attempt to improve the steps and logic of the process. For fully exploiting the capabilities of automation, it is important for the Execution Team to set and follow clear criteria for deeming a task suitable for RPA. The ‘quick wins’ associated with RPA are commonly connected with manual tasks that are repetitive and rule-based. Many financial tasks at Nordea fulfil these criteria and, hence, appear suited to RPA. Generating bills, keeping transaction records up-to-date, and uncovering errors in processing fall squarely into this category. These high-volume processes promise the fastest cost reductions and reaping the greatest financial benefits.
However, tasks performed in nonstable environments are subject to many unpredictable alterations, hence the requirement for the Execution Team to ensure that RPA candidate processes be set in a stable environment with predefined information systems. Having collected and evaluated the details of each process, the Execution Team prepare calculations for each RPA business case and add those projects that ‘make the cut’ to the RPA pipeline. Finally, the analysts in the team assist the business units’ decision-makers in prioritising among RPA projects, where their order in the pipeline is based on the business case calculations and the various types of value that transformation via RPA may bring. Accordingly, the Execution Team can be characterised as having some ownership of Nordea’s RPA ‘Project Portfolio Management’ and, thereby, responsible for prioritising among the implementation projects and overseeing their rollout. The team manages the implementations at business unit level and reports to the respective business units on the RPA projects’ progress. After production deployment of a software robot, analysts with the Execution Team function as service-delivery managers for that robot, reporting on the results and collaborating with business teams in the relevant area for continuous improvement and good scalability of the robotised processes. These activities represent a very important element of the evolution of the robotics CoE value chain, particularly in light of the considerable expansion of the Blue Prism platform’s capabilities.
Now having a better sense of the Execution Team’s role in Nordea’s RPA deployment, the student asks Piotr, ‘How does the Execution Team ensure safe deployment of software robots? The team would need to establish a proper audit trail for their software robots and make sure end users are compliant in their RPA use’. She recalls that in the days before the hub-and-spokes model, Nordea’s software robots were deployed by business units independently, and she posits that the ‘organisational distance’ between the business units and the robotics CoE’s teams has rendered it much more difficult to arrange actions between the business units and the RPA teams such that they are seamless. She offers an example: ‘Now that the end users are geographically dispersed, how can the Execution Team keep tabs on potential rogue end-user behaviour with RPA and penalise noncompliance in the business units?’
Piotr replies, I’m not sure I fully recognise the picture you’re drawing here. If you’re referring to robots developed by the business units, it’s a concern more for Developers and Operations [the Development Team and Operations Team] (production) that these are adhering to good standards. That’s because the robotics CoE has migrated dozens of satellite processes and encountered issues with running and maintaining some of them. In turn, that can create dissatisfaction in the business units with the robotic solution’s quality and reliability. To me, there’s no ‘end user’s rogue RPA behaviour’ if by ‘end user’ we mean the business team that prepares input for the robot and uses its output. The worst thing that can happen here is that the robot just doesn’t process incorrect input.
The Development Team
The third team involved, the Development Team, is a centralised unit composed of robotics developers. Most members are based in Łódź, Poland, but there are some developers in all the Nordic countries also. The developers estimate the work load associated with each RPA deployment (in essence, judging the time required to configure and code the software robot), then develop and configure the robot, take part in its testing and deployment for production use and handle more advanced bug-fixing. These roles are vital even though software in the RPA domain is perceived as noninvasive, lightweight technology and (since it is viewed as not demanding in-depth programming knowledge) considered rather quick to learn. Although this uses the presentation layer to access the systems in question rather than being embedded in existing systems via programming interfaces, not all is necessarily ‘smooth sailing’. Some functions and features may demand the skills of software architects, and certain components might have to be tackled by engineers with several years of experience in the relevant programming language(s). At present, since Blue Prism is offering a free community version of the platform and also a 90-day trial edition, the relevant personnel at Nordea find it fairly easy to start learning the key elements of designing Visual Business Objects (VBOs) and gain familiarity with the principles of the Microsoft.NET Framework (in C#). Multiple certification paths follow for more advanced professionals (e.g. the Microsoft Certified Professional Developer or Blue Prism Robotic Operating Model, or ROM, architect programme).
To shed some light on the Development Team’s potential pain points, the student raises a point with Piotr: I have a question about the testing of software robots. Before a software robot can be placed in production use, it has to be tested, naturally, but making sure the testing is sophisticated and detailed enough is challenging because of the ‘organisational distance’ between the business unit and the Development Team. Also, the Development Team must find it a struggle to reduce the number of exceptions and to reduce the dependence of Nordea’s software robots on graphical user interfaces through application programming interface [API] integration, right?
Echoing an earlier comment, Piotr responds, ‘I’m not convinced that “organisational distance” is the best way to describe the root cause’. He expands on this: I’d say that priorities may differ, in the sense that the business team would like to get the robot out in production use quickly and start using it, while Developers and Operations would prefer to release as reliable a solution as possible. In the long run, everybody should be interested in having a stable, low-maintenance robot. However, we also have to recognise and act on short-term needs and limitations. For example, we might need to release a sub-optimal robot to support urgent business priorities and then improve it ‘on the fly’, or we may simply have to get used to the fact that the number or variety of test cases is limited and testing would take unacceptably long.
The student thanks Piotr for the answer and turns to the next item she has identified for attention: The second potential pain point that I see emerging here is related to Nordea’s legacy systems, complex IT architecture, and technical debt. By operating on top of existing legacy systems, the group’s software robots are liable to contribute to accumulating technical debt.
She hastens to acknowledge that the Development Team do seek ways to reduce technical debt by, for example, strictly following industry standards and, in addition, aiming to ensure that servers, the virtual desktop infrastructure (VDI), user IDs, password resets and so on work well for users, but she points out that the issue remains: ‘Overall, the team strive to develop RPA in a way that prevents Nordea’s complex IT setup from becoming an issue for robots in production. But how to do this . . .’
This time, Piotr can offer a more unequivocal response: ‘I can definitely confirm that this is a problem. In addition, we hope that applying more advanced technologies than RPA, such as API integration, will reduce dependency on the UI layer’.
Feeling more confident, the student continues, The third potential pain point that I can see for the team here is related to reusability of components. One of the planned benefits behind Nordea’s hub-and-spokes governance model was to be able to harness the payoffs of reusability of RPA components. This has turned out to be quite difficult, though, and Nordea hasn’t been able to manage and make the fullest use of the repository of objects used in connection with older robots thus far.
She points out the team’s further challenge of wrestling with the objective of permitting multiple VDIs to run processes – that is, of avoiding process-specific VDIs.
Piotr responds, Well, we can say that the part about VDIs is a fact. It’s standard for the same VDIs to be used for multiple processes, reducing costs and the bulk of the infrastructure. I am quite optimistic also about the use of standard objects. Given that the vast majority of Nordea’s production robots have been configured by and are maintained by the robotics CoE, they use standard objects by definition, at least for the most common target applications and actions. This effect is further enhanced by the requirement that the Design Board review and approve all projects.
The Operations Team
Finally, the Operations Team is composed of controllers who focus on maintaining the production-stage robots. The maintenance work entails monitoring the software, handling the associated scheduling and performing simpler bug-fixing. Another important role of members of the Operations Team is to provide the ‘after-care’ assistance associated with stakeholder management. This is crucial, as they are the primary contact point for the business units with regard to day-to-day operations and hence must keep in touch with the individual units well. Having clear testing requirements in place enables more rapid turnaround in Nordea’s RPA maintenance, speedier failover to redundant systems and smoother updates. Appropriate, extensive RPA testing by the Operations Team ensures that the robots can detect errors, learn from mistakes and improve in output accuracy. Solid testing infrastructure in conjunction with strong RPA software maintenance renders continuous monitoring more straightforward, and attention can be directed instead to detecting, correcting and preventing any RPA irregularities that might arise after system changes. Moreover, the Operations Team is responsible for ensuring high-quality robot code and high predictability levels, alongside support and control of the robot evolution process. These mechanisms can guard against the robots’ failure and deterioration.
Sensing that a suitable time has arrived for interrupting the presentation with a question, the student asks, How can the team respond effectively to unusual disruptions in RPA functioning? I mean that these difficulties too could stem from what I’m calling the organisational distance between the Operations Team and the business units where software robots are deployed, and it could get accentuated in time-critical business processes, with huge problems for Nordea’s business resulting if those processes are unavailable. When issues appear, the Operations Team would need to make sure a dedicated IT unit is able to support the robotics personnel and help co-ordinate IT-related actions aimed at getting the software up and running again. It seems as if Nordea is now addressing these issues reactively, listing the disruptions by priority and escalating them to task forces accordingly. A better option would be to handle them proactively, but isn’t this tricky with the current set-up, since it would require efficient knowledge-sharing between the Development Team, Execution Team, and Operations Team and also between the relevant business unit and the Operations Team? Wouldn’t that be the only way to implement proactive handling of these disruptions?
Piotr responds, I’d say that the IT-related issues are easier to handle, thanks to Nordea’s extensive IT set-up and the mature procedures and well-documented technologies in place. At the other end, with user-interface, business-process, and robot-input changes, advance information is indeed often the key that enables the robotics CoE to update or adjust the robot proactively, what we call preventive maintenance. As for whether ‘organisational distance’ is the best way to refer to the issue, I’m not sure. There’s likely a distance factor involved, but in my opinion it’s more about awareness and understanding of how business processes, applications, and robots overlap and depend on one another. In the labyrinth of potential points of failure, information and collaboration are crucial.
The student moves on to the next matter: access management. She asks, From a security and privacy perspective, it’s important to retain control over access rights to the software robots, but with the responsibilities scattered across the teams now, is it hard for the Operations Team to manage access rights to every single robot and make sure they are recorded properly?
Piotr clarifies, The Operations Team doesn’t actually manage robot access – this is done by the robot users’ line managers, who are physically present in the business units. What
The student has one more comment on the team’s role: My third observation about potential pain points for this team is related to ensuring and improving efficiency in running the robots. The team’s objective is to synchronise run-times effectively and get the most from 24/7 robot capacity. To do so, the Operations Team should make sure the processes can be carried out in various timeslots, even at night and on weekends. Also, although the team aims to minimise the robots’ maintenance needs and prevent system updates from causing disruptions, these actions are difficult in practice, since the team needs to coordinate and operate numerous robots, across numerous Nordea business units.
Piotr offers some elaboration: The number of robots relative to the number of licences available, against business expectations, is a crucial factor. There’s clearly a limit to the number of processes or cases that can be handled with this finite number of licences, especially when most are constrained by expectations of running only during office hours. While we’re clearly good at utilising our licences well, the main thing to consider here is that robots and humans usually need to work together. Humans typically depend on receiving input from robots within a certain time window, beyond which the robot’s output is no longer timely [within the SLAs’ limits] or even is rendered redundant. A good balance of ‘day’ and ‘night’ [or long-response-period] processes is important, though not easy to achieve.
The student has been left with much to think about. In addition to the four core teams discussed, there are two small IT teams assisting the robotics CoE. Robotics IT is dedicated to improving Nordea’s RPA platform with regard to technical elements (e.g. gateways, backups, data storage, databases, virtual private networks (VPNs) and proxies, and Redis caching). Technical Operations, meanwhile, is responsible for attending to the underlying infrastructure required for RPA deployments (setting up connections, virtual machines, VPNs and access rights) and for assisting the CoE with associated routine operations.
Challenges for the future
All four participants in the meeting consider it to have been successful in that the student now has quite a good understanding of the current RPA governance model at Nordea. The student starts writing notes to summarise the main areas with potential for problems (shown in Table 1), saying, While I understand the path leading to Nordea’s current RPA governance model, from our discussion I can see several possibly problematic areas that could bring serious hindrances to Nordea’s future harnessing of the benefits of RPA. I see these problems as related to four main areas: software development, software maintenance, RPA governance, and IT infrastructure. In terms of software development and maintenance, there are potential issues with exception-handling, integration of new technologies, and ensuring the reusability of RPA components. With RPA governance, one can see potential for problems related to standardisation and improving already robotised processes efficiently. As for IT infrastructure, the complexity of Nordea’s IT landscape adds to the difficulty of employing software robots.
Piotr nods in agreement and adds, While we feel that our governance model has evolved from decentralised, siloed RPA development and deployment to a more federated model with the robotics CoE, we find that there are several potential problem areas that might expand and escalate into serious issues if we don’t mitigate the risks involved and take preventive action to guard against those risks. If you can provide us insights on these issues, that would surely help us going forward.
The main potential pain points of RPA deployment at Nordea.
RPA: robotic process automation; IT: information technology.
Before closing the meeting, Piotr, Jaroslaw, Agnieszka and the student agree on a schedule for preparing a draft report on the topic, which will be reviewed and fleshed out for submission to Nordea’s decision-makers. The student will make the following contributions to the report.
Task 1
Analyse Nordea’s hub-and-spokes governance model and evaluate alternative solutions – whether to consolidate more activities with the robotics CoE or decentralise them to the various business units. In this work, the student could rely on some of the key academic literature on IT governance overall (e.g. Brown et al., 2005; Cummings, 1995; Peterson, 2004; Weill, 2004; Weill and Ross, 2005; Williams and Karahanna, 2013; Wu et al., 2015) and on governance of RPA in particular (Asatiani et al., 2019a). Specific questions to be addressed by the student include the following:
What are the alternative IT governance models documented in academic literature?
Should lightweight IT (Bygstad, 2016) be governed in a different manner than heavyweight IT?
Assess the characteristics of RPA and evaluate their impact on IT governance.
Assess the implications of centralising more tasks to the CoE or decentralising more tasks to business units at Nordea.
Present a recommendation of RPA governance to Nordea (continue as is, centralise more tasks to CoE or decentralise more tasks to business units).
Task 2
Assess the recommendation output from Task 1 and evaluate its implications with regard to the challenges facing operations going forward (outlined in Table 1). Here, the student might find use in the research on process automation (e.g. Davis and Hufnagel, 2007) and operations-level analysis of human–automation interaction (e.g. Asatiani et al., 2019c; Salovaara et al., 2019). Specific questions to be addressed by the student include the following:
Assess the implications of your suggestion of recommended RPA governance model to the potential pain points identified in Table 1.
Assess the implications of your recommendation to the four main teams (the Strategy and Methodology Team, the Execution Team, the Development Team and the Operations Team) presented in the case.
The student leaves the meeting confident that she will be able to contribute to the project and to completing these two interrelated tasks. She quickly returns to her desk and opens her laptop’s Web browser. For initial familiarisation with the basics of RPA, she first hits on a website on the topic containing useful links to industry reports, news articles and videos (http://www.roboticandcognitiveautomation.co.uk/). Following up on the links found on the website, she discovers four recent books on RPA, from the perspectives of service automation robots and future of work (Willcocks and Lacity, 2016), RPA risk mitigation (Lacity and Willcocks, 2017), RPA enabling triple win (i.e. value to shareholders, customers and employees; Lacity and Willcocks, 2018) and strategic issues related to RPA deployment (Willcocks et al., 2019). She also makes several searches on Google Scholar and collects many promising links to academic papers on RPA deployments. These address such topics as establishing a CoE in automation (Anagnoste, 2018), selecting RPA-amenable business processes (Asatiani and Penttinen, 2016), characterising RPA use cases (Fung, 2014), conducting a case study of RPA (Lacity and Willcocks, 2016), organising RPA with loose versus tight coupling (Osmundsen et al., 2019) and developing an RPA implementation framework (Rutschi and Dibbern, 2020). Other materials she may find useful describe a case study of digital transformation using RPA (Schmitz et al., 2019), one of RPA as an instance of lightweight IT (Stople et al., 2017), and work positioning RPA in the toolkit of automation technologies (Van Der Aalst et al., 2018).
Footnotes
Declaration of conflicting interests
The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.
Funding
The author(s) received no financial support for the research, authorship, and/or publication of this article.
