<figure><img src="image_1.png" /></figure>

ifip

International Federation for Information Processing

This document is the original author manuscript of a paper submitted to an IFIP
conference proceedings or other IFIP publication by Springer Nature. As such, there
may be some differences in the official published version of the paper. Such
differences, if any, are usually due to reformatting during preparation for publication or
minor corrections made by the author(s) during final proofreading of the publication
manuscript.
# Co-creating through Robotic Process Automation - The role of consultants in a public sector automation journey

Björn Johansson¹[0000-0002-3416-4412] and Fredrik Söderström²[0000-0002-2422-0900]

Linköping University, SE-581 83 Linköping, Sweden

Department of Management and Engineering,

Division of Information Systems and Digitalization

¹bjorn.se.johansson@liu.se

²fredrik.soderstrom@liu.se

**Abstract.** This short paper reports on an ongoing study related to automation journeys in public sector organizations. From interviews with Robotic Process Automation (RPA) consultants, we highlight and discuss the specific capability of “making technology work” by referring to and using a core capability framework. The capability of making technology work, which we see as needing attention from both suppliers and customers if the adoption of the automation technology should be successful. We argue that this capability becomes a crucial capability; from the start of the journey and after arriving at the destination, if successful, co-creation should happen and be continuously a fact.

**Keywords:** Robotic Process Automation, RPA, co-creation, IS capabilities.

## 1 Introduction

This paper discusses the role of consultants' when a public sector organization develops automation by using Robotic Process Automation (RPA) technology. RPA can be described as front-end automation of business processes where software robots mimic the behaviour of human system interaction (Lacity and Willcocks, 2016). Therefore, RPA is often described as a technology that should be driven by business departments themselves rather than the IT-department (Aguirre and Rodriguez, 2017). RPA basically means integration using the user interface/front-end, indicating that this solution could be described as *Lightweight IT* instead of traditional advanced back-office integration, i.e. *Heavyweight IT* (Bygstad, 2017). Accordingly, this type of development could be seen as an endeavour that potentially starts from the perspective that civil servants in a public sector business departments want to further develop their business by using RPA technology to automate business processes (Söderström et al., 2021, Uskenbayeva et al., 2019). It could be that the civil servants see a need or a possibility for the business department to improve and streamline its business through this type of digitalization. Therefore, a request might be made to the IT department, and for different reasons, the IT department might be a bit resistant. This resistance could
result from civil servants searching for an option to improve operations by themselves and then identifying RPA as a potential solution. The result could be that the business department contacts an RPA supplier (Toll and Söderström, 2020). After doing this, it becomes a question of what competencies the civil servants need and what competencies the RPA consultant needs to provide. All this results in the following research question addressed: What do the stakeholders in this RPA development endeavour need to do? This question then addresses what competencies or capabilities each stakeholder (Civil servants and RPA consultants) need to have and how the interaction between these stakeholders needs to be conducted for co-creation to happen in this context. In this short paper, we introduce the question and the topic by presenting theoretical grounding in the next section, followed by a research method section and a discussion section in which we discuss the capability of making technology work, before the final section that presents concluding remarks and forthcoming research.

## 2 Theoretical grounding

This research has as a starting point the core capability framework by Feeny and Willcocks (1998). From that, the discussion around the role of the stakeholders (RPA consultants and civil servants) and what competence and capability are needed to have successful co-creation related to RPA is highlighted. The first thing that needs to be clarified is what co-creation means in this context. RPA co-creation could be described as the development of business processes that comes from the interaction between a provider/supplier of RPA and the actual usage of the RPA. This requires collaboration between the two parties, and they must understand each other clearly. For instance, this could be related to middlemen's work (Mahnke et al., 2008) in an outsourcing relationship or the role of consultancy (Bessant and Rush, 1995) in technology transfer. For public organizations that start to use RPA software, developing RPA technology further is probably not part of their competencies and hence not a core competency. Therefore, it can also be claimed that in most cases, organizations need to be aware of this need for knowledge transfer and actively procure this competence from the supplier. Accordingly, co-creation occurs when implementing and using the software, which can be described as a service as business logic or service logic (Grönroos and Ravald, 2011). This also stipulates that the user organization needs some form of capability or capabilities for this business logic to become successful. One of the questions addressed in this paper is what kind of competencies the supplier of RPA sees as needed in the user organizations. We use a framework developed by Feeny-Willcocks to explore this, which consists of three internal intersecting areas and includes nine core IS capabilities as presented and defined shortly in Table 1 below.

<table><caption>**Table 1.** Core IS capabilities defined [1]</caption><thead><tr><th>#</th><th>Core IS capabilities</th><th>Definition</th></tr></thead><tbody><tr><td>1</td><td><em>Leadership</em></td><td>Integrating IT effort with business purpose and activity.</td></tr><tr><td>2</td><td><em>Business<br>Thinking</em><br><em>Systems</em></td><td>Ensuring that IT capabilities are envisioned in every business process.</td></tr></tbody></table>
<table><thead><tr><td>#</td><td>Core IS capabilities</td><td>Definition</td></tr></thead><tbody><tr><td>3</td><td>Relationship Building</td><td>Facilitates the broader dialogue, establishing understanding, trust and cooperation amongst business users and IT specialists.</td></tr><tr><td>4</td><td>Designing Technical Architecture</td><td>Creating the coherent blueprint for a technical platform that responds to present and future business needs.</td></tr><tr><td>5</td><td>Making Technology Work</td><td>Rapidly troubleshoot problems disowned by others across the technical supply chain and identify how to address business needs that cannot be appropriately satisfied by standard technical approaches.</td></tr><tr><td>6</td><td>Informed Buying</td><td>Analyse the external market for IT/e-business services; select a sourcing strategy to meet business needs and technology issues; lead the tendering, contracting, and service management processes.</td></tr><tr><td>7</td><td>Contract Facilitation</td><td>Ensure the success of existing contracts for IT services.</td></tr><tr><td>8</td><td>Contract Monitoring</td><td>Holding suppliers to account against both existing service contracts and the developing performance standards of the services market</td></tr><tr><td>9</td><td>Vendor Development</td><td>Identifying the potential added value of IT/e-business service suppliers.</td></tr></tbody></table>

## 3 Research method

The research partly described in this paper builds on a qualitative interpretive case study (e.g. Walsham, 1995) performed among two consultancy firms (suppliers) with expert knowledge and competence in automation and RPA. The aim is to determine what capabilities these suppliers think a potential customer needs to have about automation technology. As presented in the theoretical grounding, we see the IS core capabilities framework by Feeny and Willcocks (1998) as a suitable approach to further explore this area. The framework was used as a guide for interviews and analysis. Accordingly, in this paper, we present our thoughts about the capability of making technology work from a supplier perspective when a customer adopts RPA.

<table><caption>Table 2. Interviews</caption><thead><tr><td>#</td><td>Date</td><td>Role</td><td>Supplier</td><td>Duration</td></tr></thead><tbody><tr><td>1</td><td>2020-06-01</td><td>Manager</td><td>S1</td><td>45 mins</td></tr><tr><td>2</td><td>2020-06-04</td><td>Head of Business Area</td><td>S1</td><td>55 mins</td></tr><tr><td>3</td><td>2020-06-04</td><td>Business Analyst</td><td>S1</td><td>60 mins</td></tr><tr><td>4</td><td>2020-06-15</td><td>Senior Project Manager</td><td>S2</td><td>90 mins</td></tr><tr><td>5</td><td>2020-10-14</td><td>Developer</td><td>S2</td><td>70 mins</td></tr><tr><td>6</td><td>2020-10-14</td><td>Developer</td><td>S2</td><td>60 mins</td></tr><tr><td>7</td><td>2020-11-25</td><td>Business Analyst, Technical Lead</td><td>S1</td><td>90 mins</td></tr><tr><td>8</td><td>2021-05-31</td><td>Senior Project Manager</td><td>S2</td><td>60 mins</td></tr></tbody></table>
Data collection consisted of eight (8) semi-structured interviews with representatives from two (2) consultancy firms specializing in automation and RPA. All respondents were actively involved in projects concerning automation and RPA. Respondents' roles ranged from management, project manager, developers, business analyst and technical lead. A detailed overview of interviews is shown in Table 2 above. The two supplier firms were of similar size and categorized as SMEs. Both firms specialize in developing and delivering solutions and services in automation and RPA to customers in the private and public sectors. Accordingly, these firms have a similar service offering to their customers, consisting of consultancy and support regarding business/process automation as part of digital transformation. The interviews were recorded, transcribed, and analysed based on the described Core IS Capability framework (Feeny and Willcocks, 1998). Questions asked during the interviews followed an interview guide covering service offerings, solutions, work practices, lessons learned, and recurring challenges. We slightly adjusted the original framework by Feeny and Willcocks (1998) during this study to increase its applicability in the focused research context. We justify this change because we believe that the initial framework was influenced by the original context of outsourcing IT services.

# 4 Discussion

During RPA automation, the technological platform is implemented and deployed within the adopting organization, as in other types of automation. The RPA platform thus becomes part of the organization's current internal technological infrastructure. Accordingly, there are differences between customer and external service providers regarding the continuous delivery of technology services and infrastructure. Also, while major outsourcing contracts involve significant financial investments, RPA implementations have a lower financial entry. Based on these motives, in the current research stage presented in this short paper, we have chosen to delimit the discussion by focusing on capability five, "making technology work". This capability refers to how there is in-house knowledge and competence to rapidly react, troubleshoot and solve technological problems (Feeny and Willcocks, 1998). According to Kirchmer and Franz (2019), RPA is a digital enabler applied or discussed in many organizations as a potential technology addressing business needs. However, Kirchmer and Franz (2019) also claim that many organizations struggle to realize the full potential of RPA, referring to statistics that state that 30-50% of RPA initiatives fail.

Thus, Kirchmer and Franz (2019) conclude that there is a need for approaches that support identifying processes to automate, improve those business processes considering the end-to-end process context and sustain the results through appropriate governance and hybrid workforce management. Moreover, Juntunen (2018) states that to develop, implement, and maintain RPA successfully, there is a need for internal RPA competence. There is a need to complement existing in-house technical competencies, skills, and knowledge with support from external partners' technical resources. The capability of "making technology work is, according to Kasraian et al. (2016), a crucial
capability in the operation phase of RPA. Empirical data from suppliers confirm this
need for technological knowledge transfer from supplier to the customer and
knowledge development concerning RPA (e.g. Senior Project Manager, S2). The sense
of what technical knowledge and competence of RPA is needed to be developed and
maintained in-house seems to be no different from other technologies. Thus, the IT-
support function still needs to solve emerging technical issues during phases such as
implementation, maintenance and support and further development of an RPA solution.
We, therefore, argue the capability of making RPA technology work includes high
levels of competence regarding the technological architecture and solution, i.e. the RPA
platform, as well as the processes and operations of the organization. This competence
should include how the organization operates in the current and how the organization
can be developed in the future and therefore has a strong relation to and is dependent
on the former capability of business systems thinking. Knowing the importance of
knowledge transfer and training demands is also necessary when procuring RPA related
services. Hence, this relates to the possibility of having co-creation between supplier
and customer in the case of RPA adoption. The adopting organization must understand
what is needed to have the technology work, while the provider must understand what
they need to provide for successful co-creation through RPA. This is not only required
for the initial stage; it is also related to ongoing processes to manage, maintain, and
develop the RPA solution.

# 5 Concluding remarks and forthcoming research

In this short paper, we describe the potential of using the core capability framework to highlight what is needed to focus on for parties when the adoption of RPA takes place. The focus was directed to the capability of making technology work, which we see as needing attention from both suppliers and customers if the adoption of the automation technology should be successful. By highlighting the need to have a close relationship within this endeavour, it can be concluded that this is a key to having successful co-creation. The next step would be to explore other ongoing relationships between suppliers and customers in their automation journey. This will enable the development of clear advice to give both suppliers and customers on how to start the journey and how to be able to enjoy the final destination.

# 6 Acknowledgements

The research presented in this paper was funded by AFA Insurance; an insurance
company owned by Sweden's labour market parties.

# References

Aguirre, S. & Rodriguez, A. 2017. Automation of a Business Process Using Robotic Process Automation (RPA): A Case Study. *Applied Computer Sciences in Engineering*.
Bessant, J. & Rush, H. 1995. Building bridges for innovation: the role of consultants in technology transfer. *Research policy*, 24, 97-114.

Bygstad, B. 2017. Generative innovation: a comparison of lightweight and heavyweight IT. *Journal of Information Technology*, 32, 180-193.

Feeny, D. F. & Willcocks, L. P. 1998. Core IS capabilities for exploiting information technology. *Sloan management review*, 39, 9-21.

Grönroos, C. & Ravald, A. 2011. Service as business logic: implications for value creation and marketing. *Journal of service management*.

Juntunen, K. 2018. Influence of contextual factors on the adoption process of Robotic process automation (RPA): Case study at Stora Enso Finance Delivery.

Kasraian, L., Sammon, D. & Grace, A. 2016. Understanding core IS capabilities throughout the IS/IT service co-production lifecycle. *Journal of Decision systems*, 25, 290-301.

Kirchmer, M. & Franz, P. Value-driven robotic process automation (RPA). International Symposium on Business Modeling and Software Design, 2019. Springer, 31-46.

Lacity, M. C. & Willcocks, L. P. 2016. A new approach to automating services. *MIT Sloan Management Review*, 58, 41-49.

Mahnke, V., Wareham, J. & Bjorn-Andersen, N. 2008. Offshore middlemen: transnational intermediation in technology sourcing. *Journal of Information Technology*, 23, 18-30.

Söderström, F., Johansson, B. & Toll, D. 2021. Automation as migration? – Identifying factors influencing adoption of RPA in local government. *European Conference of Information Systems (ECIS 2021)*.

Toll, D. & Söderström, F. What is this' RPA'they are selling? EGOV-CeDEM-ePart-*, 2020. 365-370.

Uskenbayeva, R., Kalpeyeva, Z., Satybaldiyeva, R., Moldagulova, A. & Kassymova, A. Applying of RPA in administrative processes of public administration. 2019 IEEE 21st Conference on Business Informatics (CBI), 2019. IEEE, 9-12.

Walsham, G. 1995. Interpretive case studies in IS research: nature and method. *European Journal of information systems*, 4, 74-81.