Australasian Journal of Information Systems Doolin et al. 2025, Vol 29, Research Article Theorising RPA as Socio-Technical Change Received 15 Sep 2024, accepted 09 Aug 2025 after 2 rounds of review with Arif Perdana as accepting Senior Editor, Michael Davern and Stuart Black as Editors in Chief 1 Theorising Robotic Process Automation as Socio- Technical Change: A Process Study Bill Doolin1 Business School Auckland University of Technology New Zealand Email: bill.doolin@aut.ac.nz Angsana A. Techatassanasoontorn Business School Auckland University of Technology New Zealand Lena Waizenegger Business School Auckland University of Technology New Zealand Erin Wallace-Carter Business School Auckland University of Technology New Zealand Abstract Robotic process automation (RPA) is increasingly adopted as a relatively inexpensive automation solution to reduce routinised and repetitive tasks and to initiate an organisation’s broader automation programme. Prior research has focused on highlighting RPA benefits for organisations with suggestions on how to maximise benefits and avoid challenges in RPA implementation. There is less understanding of the emergent and dynamic nature of RPA implementation. Drawing on key elements of socio-technical change, we conducted a process study of RPA implementation in a university. From our analysis, we identified five process patterns: initiation, mobilisation, configuration, adaptation, and evaluation, each of which has different implications for organisational trajectories of RPA implementation. Our findings also offer insights into how the changing role of RPA as an epistemic, technical, and agentic object is intertwined with the dynamics of automation and augmentation in RPA’s conception, development, incorporation into work routines, and evaluation of the initiative’s future. Keywords Robotic process automation, Implementation, Process study, Socio-technical change, Case study. 1 Introduction Robotic process automation (RPA) is a technology that employs software agents, known as software robots or ‘bots’, to automate low to medium-skilled tasks in a business process according to pre-defined rules by interacting with other systems through their user interfaces. RPA has received attention because of its perception as a minimally invasive and relatively 1 The authors are listed alphabetically. Australasian Journal of Information Systems Doolin et al. 2025, Vol 29, Research Article Theorising RPA as Socio-Technical Change 2 inexpensive solution for the rapid automation of routine tasks involving structured data and deterministic outcomes that were previously reliant on mundane and repetitive manual labour (Aguirre and Rodriguez 2017; Herm et al. 2021; Hofmann et al. 2020; Syed et al. 2020). Increasingly, RPA is also viewed as a way to expand an organisation’s broader automation programme by combining RPA with process mining tools to assist in identifying candidate processes for automation (e.g., Leno et al. 2021; van der Aalst et al. 2018), or with artificial intelligence (AI) technology to build cognitive or intelligent automation (Engel et al. 2022; Herm et al. 2021; Lacity and Willcocks 2021). However, it has been reported that 30-50% of RPA implementations result in failure (EY 2017) and there are suggestions that only a quarter of organisations gain the full benefits from their RPA deployments (Asatiani et al. 2023). RPA implementation is often presented as a sequence of clearly defined, deterministic phases with well-contained success factors, and the focus is typically on the early phases of the broader RPA life cycle (Asatiani et al. 2023; Syed et al. 2020). While prior research on RPA has provided valuable insights, the dynamic nature of RPA implementation is reflected in RPA’s susceptibility to changes in the underlying technological infrastructure or business process, the quality of input data, and willingness of users to adapt their work to accommodate a bot (Plattfaut et al. 2022; Santos et al. 2020; Syed et al. 2020; Waizenegger and Techatassanasoontorn 2022). In addition, RPA implementation differs from that of more traditional information systems in terms of the nature of the processes supported, integration with other systems, implementation and maintenance costs, flexibility and scalability, and user interaction (Coombs et al. 2020; Hofmann et al. 2020; Staaby et al. 2021; Syed et al. 2020). Unlike prior RPA research that has focused on static success factors, in this study we unpack the temporal, socio-technical dynamics shaping RPA outcomes. To improve our understanding of the dynamics of RPA implementation and the interrelated changes to technology, structures, work processes and employee roles that shape the course and outcome of RPA implementation, we conceptualise it as a temporally emergent process of socio-technical change (Langley et al. 2013; McLeod and Doolin 2012). We explore the socio- technical interactions that occur in the RPA trajectory, which commences with an organisation’s positive imaginaries of RPA technology and its role in automating repetitive work and augmenting human employees (Raisch and Krakowski 2021), extends to the materialisation and configuration of software robots and their assimilation into work routines, and finally to organisational decisions on the future of the RPA initiative. We use the notion of objects (Engeström and Blackler 2005) to understand how RPA technology is conceptualised and the multifaceted roles it plays in the evolving journey of an organisation’s RPA initiative. Hence, we pose the following research question to underpin our study: How does the organisational RPA journey unfold over time and how is RPA as an object implicated in this trajectory? While the focus of our study is on the full RPA life cycle from inception to development, implementation, post-implementation, and the decision to scale up or down the automation, in the following we use the term RPA implementation in the general sense for the sake of simplicity. Our study makes two important contributions to the literature. First, we identify key process patterns that offer a nuanced understanding of how contingent interactions between socio- technical elements in ongoing practices explain the dynamic and emergent trajectory of RPA implementation. Second, drawing on the dual purposes of RPA in automating work processes Australasian Journal of Information Systems Doolin et al. 2025, Vol 29, Research Article Theorising RPA as Socio-Technical Change 3 and augmenting human employees, we explain the changing roles of RPA as epistemic, technical and agentic objects and their implications in the RPA implementation process. In the following, we summarise prior research on RPA implementation before introducing the process approach to socio-technical change used in our study. We then outline our methods of data collection and analysis. Drawing on the findings of a case study of an RPA initiative in a university, we develop a process model that traces the dynamic interactions between the RPA technology, human actors and work practices that together shape the key activities that constitute different patterns of RPA implementation. We also explore how RPA evolves as an object of epistemic interest and material artefact or agent in the processes and work practices of the organisation. 2 Prior Research on RPA We organise insights from the RPA literature into two major streams of studies. The first stream focuses on RPA as an effective automation technology that facilitates process improvements for organisations. The second stream primarily highlights RPA benefits for organisations and potential challenges in the implementation process. The first stream of studies emphasises the appealing technological characteristics of RPA and its potential. RPA shapes work practices by automating repetitive tasks in organisational processes. As a technology, RPA can often overlie existing legacy applications without the need for significant changes to the underlying infrastructure, business logic, or data access layers (Hofmann et al. 2020). In addition, as a development platform, RPA with its intuitive user interfaces and low-code environment fosters rapid implementation of software robots (Plattfaut and Borghoff 2022). The bots can interact with multiple systems and work autonomously to perform routine tasks (Kokina and Blanchette 2019). While some studies emphasise the capability of the bots to mimic human action and hence access systems through the user interface (Syed et al. 2020), the bots can also access and post data to an application through an application programming interface or request tables from a system database through SQL queries (Hofmann et al. 2020). As the user interface can change through system updates and upgrades, some RPA developers prefer these latter approaches. Finally, more recent studies propose an integration of RPA with advanced automation technologies such as AI to expand organisational automation initiatives and potentially enhance the benefits of automation for employees (e.g., Benbya et al. 2021; Engel et al. 2022; Haase et al. 2024; Moderno et al. 2024). In the second stream of research, a range of studies present the benefits of RPA for organisations in terms of productivity, speed, cost of data processing, error reduction, process consistency, compliance, and customer satisfaction (Aguirre and Rodriguez 2017; Haase et al. 2024; Hofmann et al. 2020; Kokina and Blanchette 2019; Santos et al. 2020; Syed et al. 2020). In addition, RPA promises to relieve employees from the repetitive and mundane parts of their jobs, leaving them to do more interesting and high-value activities such as those that require creative thinking, judgment, and social skills (Güner et al. 2020; Hofmann et al. 2020; Lacity and Willcocks 2021; Santos et al. 2020; van der Aalst et al. 2018). Other studies argue that RPA is likely to reconfigure work processes by creating new tasks and divisions of labour between bots and the human employees working alongside them (Andersson et al. 2022; Dey and Das 2019; Ranerup and Henriksen 2019; Staaby et al. 2021; Waizenegger and Techatassanasoontorn 2022). For example, depending on the scope of the bot’s functionality and the underlying Australasian Journal of Information Systems Doolin et al. 2025, Vol 29, Research Article Theorising RPA as Socio-Technical Change 4 infrastructure, the bot will throw exceptions that require human employees to intervene and make judgements or decisions (Dey and Das 2019; Techatassanasoontorn et al. 2023). In addition to highlighting RPA benefits and changes to work processes, some studies have also identified challenges critical to successful RPA implementation, including selecting processes that can deliver the most value after being automated (Asatiani et al. 2023; Farinha et al. 2024; Plattfaut et al. 2022; Santos et al. 2020; Schmitz et al. 2019), balancing concrete deliverables in the short term with scalable solutions and maintainability in the longer term (Lacity and Willcocks 2016; Santos et al. 2020; Viehhauser and Doerr 2021), and stakeholder and change management such as managing employee expectations (Asatiani and Penttinen 2016; Dey and Das 2019; Haase et al. 2024; Plattfaut et al. 2022; Santos et al. 2020; Syed et al. 2020). Other reported challenges are integration issues between the bot and the applications it interfaces with (Santos et al. 2020), the bots’ access control implications (Syed et al. 2020), and the building of internal knowledge and skills on RPA from a vendor or external consultant (Hallikainen et al. 2018). While RPA implementation is often presented as a seemingly straightforward process to automate repetitive tasks and augment humans in their work, some studies suggest that RPA implementation is more complex. Pre-automation process improvements and selection of processes for automation that interface with stable external applications may be required. The desirability of close collaboration between developers and process owners necessitates the participation of multiple actors in configuring and maintaining bots. Indeed, some organisations implementing RPA have challenged the espoused view that process owners who become bot managers do not need technology-related skills. Finally, RPA implementation involves interconnected changes to work processes and employee roles that require communication of RPA’s impact and limitations as well as employee training. Human-bot collaboration may be needed to realise the benefits of automation and augmentation of work (Kokina and Blanchette 2019; Plattfaut et al. 2022; Santos et al. 2020). 3 Studying RPA Implementation as Socio-Technical Change To develop a deeper understanding of the dynamics of RPA implementation across the RPA life cycle, we adopt a process perspective that examines change as complex, multi- dimensional, temporally emergent and indeterminate (Cloutier and Langley 2020; Van de Ven and Poole 2005). Process studies analyse patterns in a sequence of events that lead to a particular outcome to open up the ‘black box’ of the process by which change occurs (Langley 1999). Process studies are concerned with developing knowledge of how and why particular change outcomes unfold in often unpredictable ways over time by focusing on interrelated events, activities, interactions and trajectories (Cloutier and Langley 2020; Fachin and Langley 2017; Langley et al. 2013). Process analysis is built on data that is typically longitudinal, qualitative and collected in actual organisational settings (Langley 1999). In-depth interviews with organisation members are one method for soliciting accounts of the events and activities that constitute a trajectory of change (Abdallah et al. 2019; Fachin and Langley 2017). Langley (1999) outlines various techniques for analysing process data to conceptualise events and detect patterns between them. A narrative strategy involves constructing a detailed story from the data that conveys the unfolding process and dynamics that have led to the particular outcome being explained. Temporal bracketing involves structuring the description of a sequence of events and activities Australasian Journal of Information Systems Doolin et al. 2025, Vol 29, Research Article Theorising RPA as Socio-Technical Change 5 into ‘brackets’ or episodes with some level of internal continuity. These episodes serve as units of analysis for the construction of the process narrative (Langley 2023). The ordering of these episodes constructs a narrative temporality for analytical purposes rather than temporal evolution in real time (Fachin and Langley 2017). Visual mapping is a useful complementary technique for analysing and displaying the large amounts of process data as more abstract representations using diagrams (Langley and Ravasi 2019). The output of the process analysis is a process model that reveals the underlying generative mechanism that shapes the process towards an emergent outcome and enables its interpretation and explanation (Cloutier and Langley 2020; Fachin and Langley 2017; Pentland 1999). To inform our process analysis, we conceptualise RPA implementation as a process of socio- technical change (Lyytinen and Newman 2008; McLeod and Doolin 2012; Salmimaa et al. 2018). Technology implementation in an organisation is a function of dynamic interactions between the technology, the human actors who appropriate it for particular purposes, and the institutional context in which it is deployed (Orlikowski 1992). We use a set of five core concepts to selectively focus on the elements of socio-technical change that are important in our analysis: technology, focal actors, practices, context, and effects. Technology represents the digital apparatus required to facilitate RPA implementation. This includes the RPA platform and software robots, development tools and relevant elements of the organisation’s technological infrastructure. The decisions and actions involved in implementation are mediated by the properties and capabilities of the technology, which may both enable or constrain action, in turn requiring accommodations such as revisions to the form of technologies, the conduct of human activities, or the plans and goals of actors (Pickering 1995). We draw on the notions of epistemic, technical, and agentic objects to explain the changing roles of RPA technology in the implementation process. An epistemic object is “an object of investigation that is in the process of being materially defined” (Nicolini et al. 2012, p. 618). Epistemic objects are incomplete, emergent and expansive with the capacity to unfold indefinitely (Knorr Cetina 2008; Nicolini et al. 2012). These abstract objects become technical objects when their interpretation is stabilised, and they become defined. They are turned into concrete instruments or tools (at least temporarily) with the static quality of a material object (Ewenstein and Whyte 2009; Rheinberger 2011). Objects such as software robots can be viewed as both epistemic objects (in their open forms) and technical objects (in their closed forms). Finally, agentic objects are software-based artefacts with the ability to act with “specific rights for task execution and responsibilities for preferred outcomes” (Baird and Maruping 2021, p. 317). Software robots can be considered agentic objects in their instantiation in the automation of routine work practices. Furthermore, the treatment of RPA bots as digital employees with their own user accounts, LAN IDs, and often human-like names, which execute tasks and processes autonomously underlines their agentic nature. In our study, we propose that RPA’s initial status as an open-ended epistemic object becomes progressively defined and (temporarily) stabilised as it materialises in the form of one or more software robots (technical objects), which in turn are integrated into the organisation’s workflows as agentic objects capable of acting with a degree of autonomy. By incorporating the notion of objects, we extend prior socio-technical change models to better capture the evolving role of technology in the change process. Australasian Journal of Information Systems Doolin et al. 2025, Vol 29, Research Article Theorising RPA as Socio-Technical Change 6 Focusing on socio-technical change also directs our attention to the role of focal actors (Pentland 1999). These are the project participants and stakeholders who shape the course of RPA implementation through their engagement in various project activities and influence in the development of software robots. They include managers, system owners, developers, support staff, vendors, and future business users of RPA. These individuals perform defined roles and possess particular knowledge and skills, expectations and interests, and values and beliefs that shape their perceptions, interpretations, decisions and actions (McLeod and Doolin 2012). Their actions are oriented toward the attainment of planned goals (Leonardi 2015) in the execution of their tasks in RPA implementation. The third key component of the dynamic interactions between actors and technology in socio- technical change are the theories and routines that provide a framework for action (Glaser 2017). We characterise these as practices – recurrent modes of action and knowledge that constitute socially recognised and ordered ways of thinking and performing an activity (Gherardi 2009; Leonardi 2015; Nicolini and Monteiro 2016). Existing practices discipline human actions by providing a repertoire of concepts, norms, values and procedures embedded in particular bodies of knowledge and institutionalised methods of action (Pickering 1995). They legitimate who may act in specific circumstances and particular courses of action (Nicolini and Monteiro 2016). Differing practices can create tensions and conflict, for example, between established and new ways of performing activities or from the introduction of new technologies (Nicolini and Monteiro 2016). In the context of this research, important practices are likely to include established approaches to project management, solution development and testing, vendor-specific approaches to RPA implementation, and customary ways of performing work in the processes where automation will occur. Actors in technology implementation draw on established practices, engage with technology and act within the structures and properties of the context in which this interaction occurs. This includes both the organisational context – e.g. available resources, the formal and informal structure and relations of the organisation, and its culture of institutionalised norms and rules – and aspects of the external socio-political and economic environment in which the organisation is located (Lyytinen and Newman 2008; McLeod and Doolin 2012). These contextual conditions of possibility are interpreted and mobilised by actors to understand, rationalise and legitimate their choices and behaviour (McLeod and Doolin 2012). Finally, the contingent interactions between actors, technology and practices have intended and unintended effects on the socio-technical change process that shape the trajectory of technology implementation (McLeod and Doolin 2012; Salmimaa et al. 2018). These effects influence future interactions by acting on or structuring the various elements of ongoing socio- technical change (Feldman and Orlikowski 2011). This may include confirmation or change in the scope, objectives and deliverables of the project, actors’ reflective evaluation of their actions resulting in confirmation or change in their positions or intentions, and modification to the technologies used in the project or the introduction of new technologies and artefacts (McLeod and Doolin 2012). Table 1 presents the definitions of the key concepts on socio- technical change and objects used to guide our theory development. Australasian Journal of Information Systems Doolin et al. 2025, Vol 29, Research Article Theorising RPA as Socio-Technical Change 7 Concept Definition Technology The digital apparatus required to facilitate RPA implementation (e.g., RPA platform and software robots, development tools, technological infrastructure). Epistemic objects Abstract objects that are incomplete, emergent and expansive with the capacity to unfold indefinitely. Technical objects Objects with stabilised and defined interpretations representing concrete tools with the static quality of material objects. Agentic objects Software-based artefacts with the ability to act with endowed rights to execute responsible tasks. Focal actors Key actors, including project participants and stakeholders in RPA implementation. Practices Recurrent modes of action and knowledge that constitute socially recognised and ordered ways of thinking and performing an activity in RPA implementation. Context Contextual conditions (e.g., resources, structure, culture, norms) that define the range of possible actions available to actors during RPA implementation. Effects Intended and unintended effects on the socio-technical change process that shape the trajectory of RPA implementation. Table 1. Definitions of Key Concepts 4 Methods To answer our research question, we conducted a case study of a university that has implemented RPA in its student admission process. We sought and obtained ethical approval for the study from our university’s ethics committee. The case study organisation was selected because it has a relatively complex operating environment with a range of core and support processes that could be automated. In addition, the RPA project studied was the organisation’s first RPA initiative and involved an overseas vendor working with a local IT team. Our access to the organisation allowed us to study an RPA project through implementation and into the start of the post-implementation, ‘business as usual’, phase. We anticipated that this would help us better understand the impacts of RPA and its autonomous software robots in a work setting as well as the implementation environment. Like many universities, the organisation we studied experiences pressure to keep costs low and run their processes as efficiently as possible. RPA was regarded as a potential technology with which to achieve these performance goals, and it was decided to implement an RPA pilot project to evaluate how RPA could be leveraged at the university. 4.1 Data Collection We followed the RPA deployment at the university for three years from late 2019 to late 2022. Our data collection occurred in two phases. The first phase took place from November 2020 to May 2021 and the second from August to November 2022. During phase 1, one of the authors conducted thirteen semi-structured interviews with the IT Manager as project sponsor; four members of the IT project team: the Project Manager, Developer, Application Support Analyst and Test Analyst; two representatives from the RPA vendor: the Relationship Manager and Solutions Architect; and six employees from the process work team: the Admissions Manager and five Admissions Officers. Interviewing participants from all involved teams allowed a holistic picture and rich accounts of the key events and activities in the RPA implementation process to be captured. The interview guidelines covered: a) description of the interviewee’s current role and responsibility, b) their perception of the RPA implementation and the challenges that occurred, c) the actions and strategies that were taken to facilitate the Australasian Journal of Information Systems Doolin et al. 2025, Vol 29, Research Article Theorising RPA as Socio-Technical Change 8 implementation project and d) the effects on the work practices of the work team employees. The author also observed a project team meeting that showcased the progress of the software robot development and provided the opportunity to see the bot in action. She was provided with copies of the RPA solution design, the vendor’s operating model for RPA deployment, and a plan for scaling RPA use. These documents provided useful context for the conduct of the interviews that were our primary data collection method. During phase 2, some two years after the bot went live, the same author conducted eight semi- structured interviews with the project sponsor (now Deputy CIO), Developer, Application Support Analyst (now a Solutions Architect), Admissions Manager, three Admissions Officers who worked alongside the bot, and the Product Owner, a new participant responsible for further implementation of RPA in the university. The interview guidelines covered: a) changes to job profile since the previous interview and how the RPA deployment had impacted their work, b) the goals of implementing RPA, expectations of RPA performance and how these goals and expectations have been realised, c) perceptions of RPA and experiences managing and working alongside RPA, and d) any plans to expand the university’s RPA programme. Table 2 provides details of the interviewees. Some participants offered a strategic or managerial perspective, some were knowledgeable about technical details and systems integration, and others provided insights from the user perspective. We obtained the informed consent of our interviewees and maintained participant confidentiality by anonymising quotes and referring to the interviewees using generic job titles. Each interview took between 30 and 60 minutes, was conducted in person or via Microsoft Teams, and was recorded and transcribed. Once each interview was completed, key insights were written down and periodically discussed within the author team. Participant Gender Time in position Job title (role in implementation) Interviews completed 1 Female <10 years Admissions Officer A (subject matter expert) Phase 1 and 2 2 Female <10 years Admissions Officer B Phase 1 and 2 3 Female 10+ years Admissions Officer C Phase 1 4 Female 10+ years Admissions Officer D Phase 1 5 Female <10 years Admissions Officer E Phase 1 and 2 6 Female 10+ years Test Analyst Phase 1 7 Male <10 years Project Manager Phase 1 8 Male 10+ years Admissions Manager (process owner) Phase 1 and 2 9 Male <10 years Application Support Analyst; then Solutions Architect Phase 1 and 2 10 Male 10+ years Developer Phase 1 and 2 11 Male <10 years IT Manager (project sponsor); then Deputy CIO Phase 1 and 2 12 Male <10 years Solutions Architect (vendor representative) Phase 1 13 Male <10 years Relationship Manager (vendor representative) Phase 1 14 Male 10+ years Product Owner (of RPA programme) Phase 2 Table 2. Summary of Interviewees 4.2 Data Analysis Our data analysis consisted of three steps. In the first step, the author who collected the data conducted an initial thematic analysis of the data set (Braun and Clarke 2006). She read the interview transcripts to familiarise herself with the data and then coded the data inductively Australasian Journal of Information Systems Doolin et al. 2025, Vol 29, Research Article Theorising RPA as Socio-Technical Change 9 using initial codes. Conceptually related codes were then grouped into themes, which were reviewed to identify potential relationships between them. Alongside the coding and theme development process, theoretical memos describing and specifying each theme were produced and discussed with the rest of the author team. Some of the themes that emerged from this phase of the data analysis were drivers of the RPA project, roles, skills and resources issues during the implementation process, and changes of work practices – including an evolving distribution of responsibilities between the software robot and human employees. In the second step, the author team used the results of the initial data analysis to construct a timeline and table of 24 critical events and activities in the RPA implementation. This synopsis included the nature of the event or activity, the key actors involved and their associated actions, and the outcome of those actions on the project. This enabled us to establish the patterns of events within the temporal unfolding of the project (Glaser 2017). In the third step of the data analysis, the data set was re-analysed by all authors to develop a temporal narrative of the RPA implementation that focused on analysing the observed events in the RPA implementation as a process of socio-technical change. All authors independently reviewed the interview transcripts and recoded the data, focusing on actions considered analytically important and how these actions were organised temporally (Østerlund and Carlile 2005), the interactions between key actors, technologies and established practices, how context was implicated, and the consequences of these interactions for shaping the RPA implementation trajectory. Throughout this step of the data analysis, the author team had frequent discussions to reflect on the codes used and consider any differences in coding between the team members. This ensured that data was being consistently analysed while leveraging the multiple points of view brought to the analysis by the authors. Categories and ideas emerging from this step of the data analysis were then synthesised to create a shared understanding and agreed interpretation of the RPA implementation process among the author team (Cornish et al. 2014; Crawford et al. 2000). 5 Findings Based on our data analysis, we explain the emergence and development of RPA in our case study as unfolding in five ‘brackets’ (Langley 1999) or episodes, the temporal order of which is analytically important to our explanation. That is, the episodes are analytically sequenced and there may be temporal overlaps in the real time sequence of the RPA implementation programme. We use the five analytical episodes we identified to structure and present our findings in the process narrative below. Figure 1 provides a summary of the major milestones in the real time of the RPA deployment. Figure 1. RPA Project Milestones Australasian Journal of Information Systems Doolin et al. 2025, Vol 29, Research Article Theorising RPA as Socio-Technical Change 10 5.1 Episode 1 We distinguished the first episode as the activities required to establish the RPA project. This primarily involved identifying RPA as a technology of interest and then defining the project objectives and determining the approach to RPA implementation. The potential for RPA to add value to the university was identified through an established practice of monitoring technological developments: “We sort of monitor the hype curves … and RPA has been there for quite some time” (IT Manager). The CIO and two other senior managers visited several organisations to observe and evaluate RPA programmes and subsequently decided to try “implementing something in the RPA space” (IT Manager) at their university. From a technology perspective, the senior managers viewed RPA as an established technology with potential yet uncertain benefits to the university: “[RPA] needs to be shown to work in our environment … We don't need to do the proving of the technology” (IT Manager). Figure 2. Socio-Technical Change in Episode 1 It was decided to commence with a pilot project as a proof of concept that could be funded from within the IT operating budget without obtaining capital funding. A related objective involved developing familiarity with the RPA technology, reflecting a longstanding practice of developing in-house technical knowledge and expertise. The initial return on investment would be secondary to these considerations and the pilot project would be judged a success if “we have learned what bots are, that we have a feel for whether they would work in our environment” (IT Manager). Figure 2 illustrates the salient aspects of the socio-technical interactions in this episode. Various activities in the RPA implementation process provide sites for the context- bound interactions between actors, technology and practices that lead to ongoing effects on the RPA trajectory. Australasian Journal of Information Systems Doolin et al. 2025, Vol 29, Research Article Theorising RPA as Socio-Technical Change 11 5.2 Episode 2 The second episode concerned the assembling of resources required to commence the RPA project. These included an RPA vendor, a project team, and a candidate process to automate, together with obtaining buy-in from the business unit involved. Compatibility with the IT team’s way of working was an important consideration in selecting a vendor that could assist with the RPA implementation: “What they were saying resonated with our environment” (IT Manager). Financial constraints and the aim of developing in-house technical expertise meant a collaborative process would be followed: “Which was us doing the bulk of the work and they’re just upskilling us” (IT Manager). The vendor provided two representatives to work with a project team from the university to achieve the desired “capability build” (Relationship Manager). The university’s project team comprised a Project Manager, Developer, Application Support Analyst (to ensure compatibility of the RPA solution with the university’s operating environment), and Test Analyst (responsible for quality assurance of the developed RPA solution). The vendor had requested a developer be dedicated to the project full time. However, this was not possible: “They’re thinly spread. So, you can’t just get someone full time” (Project Manager). The IT Manager was aware that the team responsible for processing student applications for admission to the university’s academic programmes had several candidate processes that were rule-based, repetitive and high volume. The Admissions Manager was enthusiastic: “He saw this as a new employee … the bot as someone that can help him out of a tight spot” (Solutions Architect). The processing of domestic school leaver applications was chosen for the RPA pilot. This process involves running a report in the student management system to identify school leaver applications, performing a series of checks (including accessing an external university entrance system), and generating a letter with a provisional offer of acceptance: “This seemed to be the simplest one to start off with and had the most impact because we are talking thousands of applications potentially that staff members won't need to actually touch” (Admissions Manager). A software robot would process straightforward applications that involved simple rule-based steps and did not require human interpretation and decision-making skills to assess. This would remove a large volume of mundane work for the Admissions team: “Just click, click, click and send the offer. There's no thinking about this” (Admissions Officer A). The Admissions Manager and Admissions Officer A were added to the project team (the latter as a subject matter expert) to assist with requirements gathering and user acceptance testing. At this relatively early stage, RPA was conceptualised in ways that aligned with the commonly stated affordances of this automation technology. For example, the Solutions Architect suggested that efficiency was a primary motivation: “They don't want to get rid of anyone … [They] just want to drive efficiency.” He linked that motivation to the espoused advantages of software robots: “As you know, a bot, if it’s programmed correctly, it will never make a mistake … It just sits there and does the same thing.” The Admissions Manager also shared this idealised conception of how bots work: “We shouldn’t have a backlog because [the bot] will be working all the time.” The Project Manager explained the rationale for the project as: “Freeing people up who are doing repetitive jobs and allowing them to spend it on doing tasks that carry [higher] value.” Automation was envisaged working seamlessly alongside this augmentation of employees’ work: “You should only have to have humans manage the exceptions … From the end user point of view, [the automation] should be almost invisible” (Test Analyst). Australasian Journal of Information Systems Doolin et al. 2025, Vol 29, Research Article Theorising RPA as Socio-Technical Change 12 The implementation was not expected to cause a large amount of disruption: “We are not anticipating any whole scale workforce changes” (IT Manager). However, most of the Admissions team were not told of the decision to implement RPA until informed in a meeting after the project was underway. This lack of communication caused anxiety and uncertainty among some employees: “What happens when it comes in? Will it actually help us or take away our jobs?” (Admissions Officer B). This was exacerbated when the COVID-19 pandemic increased uncertainty around the university’s financial situation and concerns about job security. The Admissions Manager sent his team a detailed email about the project rationale and how it would affect them. He followed this up with periodic emails keeping the employees informed on progress. Those who expressed concerns were generally reassured: “I talked to my manager about it … [and] he was like hoping this RPA will help us … So, I wasn't too worried after all” (Admissions Officer B). Figure 3 illustrates the salient aspects of the socio-technical interactions in this episode. Figure 3. Socio-Technical Change in Episode 2 5.3 Episode 3 The third episode focused on the development of an RPA solution, from process mapping and solution design, through creation of a software robot, to user acceptance testing. The development approach followed in the project was heavily shaped by the vendor’s preferred approach to RPA development and implementation: “We bought their process so that they could train us on how to develop [RPA]” (Application Support Analyst). The development approach created a steep learning curve for the Developer. He was supported by the vendor, who provided document templates and advice as needed. The Developer communicated with the Admissions team to prepare the ‘as-is’ process document and was also responsible for writing the process definition and solution design documents: “As a developer we don’t usually do documentation … That was a bit of a challenge” (Developer). He was able to implement some process improvements: “Some shortcuts on how they process it … to make sure that process the bot Australasian Journal of Information Systems Doolin et al. 2025, Vol 29, Research Article Theorising RPA as Socio-Technical Change 13 is doing is efficient” (Developer). The Developer found that developing bots was very different to the programming techniques he usually applied: “There’s a little bit of logic, but it’s not really hard-core development … I was out of my comfort zone.” To upskill himself, he completed a series of RPA training modules and then worked closely with the Solutions Architect to learn to build the bots from the solution design document. The Test Analyst participated in their daily online meetings. Given her knowledge of the underlying systems, some issues were avoided or resolved as they arose: “The more requirements you get sorted out, the less testing you have to do … It’s built right to start with” (Test Analyst). To perform its tasks, the bot needed to interact with the university’s student management system (SMS), which “wasn’t a great application to automate on” (Solutions Architect). This introduced a level of complexity to the bot development process and several technical challenges emerged that required the Developer to work closely with SMS support team. As a non-Web-based application, some controls were hidden from the bot or were difficult for it to access. Changes were made to the SMS software and “implemented in the new version of the software to make the process more efficient for the bot” (Solutions Architect). For other tasks in the process, the Developer leveraged the bot’s technological capabilities to access the backend of the SMS database to retrieve data instead of going through the user interface. This sped up the process, and the process flow was changed to remove this inefficient step: “The bot can actually go directly to the database, or it can call an API … [which] a human can’t” (Solutions Architect). Figure 4. Socio-Technical Change in Episode 3 A single unattended robot license had been acquired for using the bot in the production environment. However, given the importance of the bot’s integration with the SMS, it was considered necessary to test the bot in the SMS staging environment before it went into production. This required purchase of a second license, adding to the project cost in already constrained IT budget. The Test Analyst constructed a range of scenarios for which the subject matter expert provided dummy data. The results of the testing were checked by the Australasian Journal of Information Systems Doolin et al. 2025, Vol 29, Research Article Theorising RPA as Socio-Technical Change 14 Admissions Manager and subject matter expert, and any errors in the configuration files corrected. Once user acceptance testing had been completed, the bot went into production. Figure 4 summarises the salient aspects of the socio-technical interactions in this episode. 5.4 Episode 4 The fourth episode described the process of learning to work with software robot once it was in production, including monitoring its performance and making modifications to it. Once the bot went into production, its output was monitored by the Admissions team for any errors in its processing. Detected problems required technical adjustments to how the bot did its work: “I had to change the configuration” (Developer). In addition, changes to the student application process itself after the bot’s initial development required updating the RPA script to ensure the bot could continue working. Addressing these issues highlighted the difficulties of testing the bot in the staging environment. The monitoring of the bot also revealed how its performance was dependent on the underlying system: “If SMS crashes then obviously the bot can’t continue doing its work, or it times out, or something goes wrong” (Admissions Manager). High usage of the SMS by university staff and students during business hours caused slow response times, which adversely affected the bot’s performance when it was interfacing with the system. The Admissions Manager suggested at times the bot became so slow that: “[If] one of my staff members processed the application, they would be quicker.” New releases of the SMS became a major issue as they sometimes caused the integration between the bot and SMS to fail: “[The bot] is expecting this [element], but the element was not there anymore, or its changed” (Developer). Until the issues were resolved the Admissions team needed to resume manual processing of applications. The project team requested advance notification of SMS updates to ensure they had time to test the integration in the staging environment. Given the periodic releases of SMS updates, the Test Analyst became concerned about the practicalities of maintaining the bot in the post-implementation phase. Her preference was to test the bot’s integration with SMS upstream in the SMS test environment. However, this would require a third robot license, something financial constraints precluded. Instead, the team relied on anticipating potential issues in proposed SMS releases and catching any that did arise in the staging environment. The main interaction between the bot and the Admissions staff involved the management and processing of any cases the bot could not process: “It will come [through] to the exceptions report” (Admissions Officer A). They needed to check for specific cases that the bot was known to be unable to detect and to manually process such non-standard applications. However, at times the bot presented exception cases for applications that it was programmed to process, causing them to question: “Why is this in my workload?” (Admissions Officer E). Once they understood the various scenarios causing the bot’s incorrect processing of these applications, the staff learned how to correct the issue and resubmit to the bot for processing: “[If] you know that is the case, then you just change it. And then I just go, ‘I’ll leave that for the bot to do tomorrow’” (Admissions Officer E). Exception management and structured handovers to the bot represent essential parts of the human-bot collaboration that enabled the bot to complete its work. Figure 5 summarises the salient aspects of the socio-technical interactions in this episode. Australasian Journal of Information Systems Doolin et al. 2025, Vol 29, Research Article Theorising RPA as Socio-Technical Change 15 Figure 5. Socio-Technical Change in Episode 4 5.5 Episode 5 The final episode involved post-implementation activities, including assessing the outcome of the initial RPA project and considering the potential for scaling the RPA programme further within the university. Despite the time saving achieved being less than anticipated, the IT Manager felt that the RPA pilot had been successful: “We’ve learned a great deal … We've demonstrated value and the bot itself is adopted and being used.” The Admissions Manager could see the potential for further enhancements to the bot to enable it to handle more complex application cases. Reflecting on how RPA is often marketed as a low-effort automation technology, the Solutions Architect emphasised the effort involved and the importance of having access to skilled developers: “You still have to do a significant amount of analysis and development to make full use of RPA.” An outcome of the pilot was the design of a multi-tiered support model for RPA within the university: “I think we’ve set that up so that it can be scaled. It was one of the learnings … What is the support model for these bots that we will be creating at the university?” (IT Manager). However, tracking the bot’s performance proved difficult. The reporting module of the RPA platform came at an additional cost, so the university relied on transaction footprints in the SMS, although this lacked detail and accuracy. Post implementation, members of the Admissions team seemed to accept the bot’s role in automating routine application processing: “I don't really notice it. It’s something that’s happening in the background” (Admissions Officer E). Often, they would refer to the bot as a “colleague” or “someone [that] helps”: “The feeling that you have a new team member who is actually helping you in your daily workload” (Admissions Officer B). It enabled them to focus on other tasks, such as processing more complex applications: “I would much rather be doing other applications that I have to use my brain and think about it … The bot doing that other work is a good thing” (Admissions Officer E). Some appreciated the opportunity to take on more specialised roles: “When the bot came in, I got to learn other things in other areas” (Admissions Officer B). At the same time, some Australasian Journal of Information Systems Doolin et al. 2025, Vol 29, Research Article Theorising RPA as Socio-Technical Change 16 looked back on the routine work they no longer did with a degree of nostalgia: “Just to give the brain a rest” (Admissions Officer D). Relative costs underlaid a decision to migrate from the existing RPA platform to a platform offered by the provider of the university’s main software ecosystem: “It makes more financial sense for us … We don’t have a lot of money” (Product Owner). The new platform was considered suitable: “The maturity has improved to the point where [the vendor] would be happy to recommend it” (Deputy CIO) and had clear advantages: “[All individuals] would be trained on one platform” (Deputy CIO). Reporting functionality was not at an additional cost from this provider and bulk robot licenses could be obtained, providing more freedom over RPA implementation in additional business units. While the original bot would need to be reimplemented with the new platform, this was not anticipated to be onerous, “Just a lift and shift of the technology” (Deputy CIO). As preparation for scaling the RPA programme, the potential for automating two further processes was explored. However, their frequency was deemed insufficient to offset the development time. This highlighted the need for scrutiny of target processes for automation to ensure they represent an adequate return on investment. Ultimately, progress on expanding the RPA programme beyond the initial pilot stalled, primarily due to limited capacity within the IT team, a lack of capital funding for expansion and changing priorities in the university: “We’ve lost the momentum” (Deputy CIO). From the vendor’s perspective, this was a missed opportunity: “An RPA programme is only good if you can scale it … If you just put one bot in … then you’re not going to get benefit from your RPA programme” (Solutions Architect). Figure 6 summarises the salient aspects of the socio-technical interactions in this episode. Figure 6. Socio-Technical Change in Episode 5 Taken together, the five episodes present a temporal and contextualised account of the RPA implementation that enables us to better understand the emergent process of socio-technical change shaping the RPA implementation trajectory. By bracketing related events and activities Australasian Journal of Information Systems Doolin et al. 2025, Vol 29, Research Article Theorising RPA as Socio-Technical Change 17 together into a sequence of analytical episodes we produced a structured process narrative that reveals how various context-bound interactions between actors, technology and practices lead to ongoing effects on the trajectory of RPA implementation in our study. In the following section we use our process narrative to conceptualise underlying process patterns, along with the changing role of RPA as an object of interest, to derive a process model that can help interpret and explain the trajectory and outcome of RPA implementation. 6 A Process Model of RPA Implementation In our analysis of the case study, we treat RPA implementation as a process rather than a formula or specification (Bygstad et al. 2010). While RPA implementation is often planned and organised in relation to an established operating model or framework, its outcome is at least partially emergent and dependent on a dynamic process of socio-technical change that unfolds over time. As outlined earlier, we frame our understanding of socio-technical change involved in RPA implementation as the effects of contingent interactions between human actors, technological artefacts and work practices that occur during key implementation activities. Based on the preceding five episodes identified in our findings, we abstracted five key process patterns occurring in the trajectory of an RPA implementation: initiation, mobilisation, configuration, adaptation and evaluation. They form a sequence of analytically interesting interactions (Abdallah et al. 2019) that cluster different activities in the RPA implementation process. The intention is to abstract a conceptualisation of RPA implementation as a dynamic and emergent process that can be generalised across settings while retaining a recognisable connection to our empirical findings (Cornelissen 2017; Langley and Ravasi 2019). While we do not claim that these five patterns are necessarily definitive or exhaustive, we suggest that they are highly likely to influence the development and eventual outcome of RPA implementation within an organisational context. Figure 7 presents our process model of RPA implementation. The five process patterns that we abstracted from our findings are shown in their analytical temporal order. Three large, curved arrows represent the dynamics of the socio-technical interactions comprising each pattern. To illustrate the analytical flow of patterns in an RPA trajectory, we use two different types of arrows. The solid arrows represent the likely trajectory, while the dashed arrow exiting the evaluation pattern represents the possibility of multiple trajectory outcomes. The changing status of RPA as an object of interest in the RPA implementation process is depicted in italics, moving from a relatively open concept to a progressively closed technical object and agent, before being re-opened as future paths for RPA within the organisation are contemplated. In the remainder of this section, we discuss the implications of these five patterns for RPA implementation. We also discuss the changing role of RPA as an epistemic, technical and agentic object along the RPA trajectory and how this influences the dynamics of RPA implementation. Australasian Journal of Information Systems Doolin et al. 2025, Vol 29, Research Article Theorising RPA as Socio-Technical Change 18 Figure 7. A Process Model of RPA Implementation 6.1 Initiation Initiation refers to the process by which RPA is introduced into an organisational setting. The idea of RPA must be formed, an objective for this form of automation programme established, and an approach to implementation decided. How senior managers in the organisation conceptualise or frame RPA as an applicable technology in the context of their organisation has an important influence on how the RPA implementation is established and structured, at least initially. Framing is a form of ideational work (Ritvala and Kleymann 2012). In performing it, managers construct an opportunity for process automation in relation to their perceived organisational needs, articulate RPA as a solution drawing on knowledge about it available in the wider context and define its importance to the organisation while setting expectations around it. The latter involves establishing an understanding of the role of RPA in the organisation’s work processes and technological infrastructure (Bygstad et al. 2010). During initiation, RPA is an epistemic object by virtue of its open-ended nature and what is not yet known (Nicolini et al. 2012; Rheinberger 2005). At this stage of its implementation, RPA is in the process of being materially defined, characterised by projection rather than being a definitive object (Knorr Cetina 2008). The open-ended nature and the lack of completeness of RPA generate strong interest and motivation from the focal actors wanting to realise the possibilities of RPA to automate processes in the organisation. Australasian Journal of Information Systems Doolin et al. 2025, Vol 29, Research Article Theorising RPA as Socio-Technical Change 19 6.2 Mobilisation Mobilisation refers to the process of assembling the human, technological and financial resources required for RPA implementation. Resource mobilisation is a form of work that involves finding and securing social, cognitive and material support for an initiative (Ritvala and Kleymann 2012). It may include, for example, establishing collaborative arrangements that facilitate the RPA implementation process, such as those with RPA consultants or vendors, the creation of a project team, and the identification of a suitable target process for automation (Asatiani et al. 2023; Farinha et al. 2024). Internal and external stakeholders need to be enrolled to engage with the RPA initiative. This may involve creating awareness of the project’s importance, aligning different stakeholder interests and formalising commitments (Bygstad et al. 2010). Employees need to be socialised to the idea of RPA and educated in the knowledge of how working alongside software robots will impact their practices. Financial and technological resources must also be secured, including, for example, funding for the initial implementation and subsequent expansion of the automation initiative and the purchase of sufficient robot licenses to enable a straightforward implementation. As the implementation proceeds towards mobilisation, RPA, as an epistemic object fuelled by its incompleteness, continues to be a source of motivation to keep the project in motion. Key activities to select a compatible vendor, assemble a project team, and identify a suitable process help extend RPA’s properties from having unbounded automation possibilities to affording idealised automation capabilities to relieve human employees from high-volume, mundane and rule-based tasks. In turn, these imagined automation capabilities confer RPA with promising augmentation benefits for employees. 6.3 Configuration Configuration refers to the process of RPA solution development. The technical work involved centres around process mapping and improvement, design of an RPA solution, integration with existing systems, and development and testing of bots before they are put into production. Key aspects include defining boundaries and rules (Lawrence and Suddaby 2006) in relation to the processes and systems within which RPA is to be established, fitting the solution to the organisation (Bygstad et al. 2010), and configuring the RPA software to select, integrate and fine tune the functionalities of the bots (Brugali and Gherardi 2016). While RPA interfaces generally require few programming skills and effort (Aguirre and Rodriguez 2017), some education and skill development may be required in familiarising employees with potentially novel practices of RPA development and implementation, as well as connecting those practices and associated knowledge bases to established ways of working and organising (Lawrence and Suddaby 2006). In particular, it is important to develop awareness of the fact that RPA development differs from traditional software development. First, RPA development is tightly linked to business processes (Asatiani et al. 2023), thus requiring close collaboration between software developers and key users who understand the process tasks in programming a bot. Second, RPA development usually does not require writing code, which many software developers are used to doing. Instead, RPA development interfaces involve drag and drop icons to automate a process (Hallikainen et al. 2018; Lacity and Willcocks 2016), which may lead some software developers to question the misalignment of their expertise with the project’s needs, as shown in our case study. Therefore, organisations may need to carefully prepare software Australasian Journal of Information Systems Doolin et al. 2025, Vol 29, Research Article Theorising RPA as Socio-Technical Change 20 developers and provide appropriate training to help them develop RPA expertise and cultivate organisational RPA capabilities. During configuration, the underlying activities focus on turning RPA from an epistemic object into a technical object endowed with automation capabilities for a chosen process. RPA’s automation potential takes centre stage in developing bots while its possibilities to augment and benefit human employees stay in the background. During this process, developers need to correctly configure a bot’s automation capabilities by carefully replicating how a human would interact with other computer systems and, in some cases, taking advantage of a bot’s technical capabilities to bypass a user interface and interact directly with a computer system (Lacity and Willcocks 2016; Santos et al. 2020). Although previous studies often claim that RPA does not disturb the underlying systems (Lacity and Willcocks 2016) or require changes to IT infrastructure (Santos et al. 2020), this may not always be the case. Configuring a bot may require technical interventions to make changes to underlying systems the bot interacts with, coordination with these systems’ owners, and an ongoing need for testing. 6.4 Adaptation Adaptation refers to the process by which the RPA technology and organisational systems and practices are reconfigured and adjusted to fit with each other after the bots are placed in production. Bot performances must be managed and maintained as new exceptions, breakdowns and contingencies arise in the flow of organisational activities (Orlikowski 1996), and the deployment of the new technology may trigger changes to work processes and practices as employees adapt to working alongside the bots. Although human actors plan their actions in the implementation and use of a new technology, any stabilisation of a solution is achieved “through a series of ongoing and situated accommodations, adaptations, and alterations … enacted over time” (Orlikowski 1996, p. 66; Leonardi 2015). In the adaptation process, the bot, as a technical object with automation capabilities, becomes an agentic object to provide intended augmentation benefits to human employees. The bot completes work tasks autonomously on employees’ behalf by leveraging the existing technological infrastructure similarly to how a human employee would do. If working as intended, such an object is invisible and taken for granted (Nicolini et al. 2012). A bot only becomes visible when it breaks down, especially when the underlying work process and the systems it interacts with change (Asatiani and Penttinen 2016; Santos et al. 2020), leaving employees frustrated and creating doubts about the benefits of RPA. Turning a bot into a productive agentic object may require additional time and resources that cannot be fully anticipated at the beginning of the project. Once the bot as an agentic object has been put into action alongside human employees, automation and augmentation become mutually enabling and constituent of one another through the bot’s automation of high-volume, low-complexity tasks, freeing the human to work on tasks that require judgements. The extent to which augmentative benefits are achieved depends on whether employees are willing and able to adapt their ways of knowing and working to accommodate the bot (Faraj et al. 2018). As our study shows, augmentation may require ongoing and often ‘invisible’ work by human actors (Baptista et al. 2020) to accommodate the bot’s technological limitations. Australasian Journal of Information Systems Doolin et al. 2025, Vol 29, Research Article Theorising RPA as Socio-Technical Change 21 6.5 Evaluation Evaluation refers to the process by which an organisation learns from their experiences with the RPA deployed and decides how to proceed with the wider automation programme. It requires reflection and review of the performance of the bots against previously defined goals, although these may have been adjusted as the RPA implementation unfolded over time. Managers need to decide whether RPA implementation is “fixed-term or continuous in nature, a stepping stone to large-scale automation or instead a fix for a specific problem” (Asatiani et al. 2023, p. 114). Various trajectory outcomes are possible as the result of the evaluation process, including expanding and scaling up the RPA programme (requiring further mobilisation of resources), scaling down RPA efforts once the project is completed (with continued maintenance of a one-off solution), or pivoting to a new platform or sourcing model based on some combination of internal and external expertise (Asatiani et al. 2023). Each requires an evaluation of the benefits to be gained against resource and capacity requirements. By the stage of evaluation, RPA has gone through various projections to unfold its capacity as an epistemic object, with seemingly unbounded automation opportunities during initiation, to acquire the affordances of idealised automation capabilities with augmentation potentialities for employees during mobilisation. In configuration, RPA turns into temporary instantiations of configured and tested bots as technical objects with defined characteristics and capabilities to make RPA ready to be absorbed into the practice of doing work. During adaptation, RPA in the form of a software robot becomes a functional agentic object to augment employees in their work routines, while coexisting as a technical object with well- specified capabilities to automate routinised work. Although the bot as a technical and agentic object becomes taken for granted and considered sufficiently stable to support employees’ work, during evaluation, RPA retains its quality as an epistemic object with its perpetual unfolding capacity and lack of completeness (Knorr Cetina 2008). This is apparent in the developing understanding of the potentials and realities of scaling automation, and how the organisation’s ‘wants’ prompt the search for new objects to work with (Knorr Cetina 2008). 7 Conclusion 7.1 Theoretical Contribution Reflecting on our research question, we were able to develop an explanation of the emergent process of RPA implementation in a particular organisational setting. By combining a process perspective with a theoretical understanding of socio-technical change, we explained how contingent interactions between technology, human actors and established practices shaped the RPA trajectory. Drawing on our process analysis of RPA implementation in the case study, we abstracted five key process patterns—initiation, mobilisation, configuration, adaptation and evaluation—each of which has different implications for RPA and its implementation. Together, these five patterns form the basis of the process model we propose for characterising the temporal emergence and evolution of an RPA programme. The process model offers a more analytical explanation of the complex, indeterminate nature of RPA implementation and how multiple potential RPA outcomes are possible across different settings. In addition to highlighting key process patterns that explain the dynamic and emergent trajectory of RPA implementation, our study also offers a better understanding of how the changing role of RPA as an object of interest and the varying emphasis on its dual purposes of automation and augmentation influence the course of RPA implementation. In automation Australasian Journal of Information Systems Doolin et al. 2025, Vol 29, Research Article Theorising RPA as Socio-Technical Change 22 software robots take over seemingly mundane, repetitive tasks from human employees, while augmentation involves collaboration between bots and human employees, the latter handling non-routine exceptions that bots could not process or taking outputs from bots to work on downstream tasks (Lacity and Willcocks 2016; Raisch and Krakowski 2021). Our analysis reveals intricate interdependencies between automation and augmentation by highlighting their dynamics in the conception, development and incorporation of RPA into work routines. We use the notions of epistemic, technical, and agentic objects to explain the changing roles of RPA and its automation and augmentation purposes in the implementation process. In RPA implementation, actors across various roles work together to endow a software robot with innate automation capabilities waiting to be rendered from a potential automated agent into actuality in a work routine. The focus of RPA implementation is twofold: (1) to turn RPA as an epistemic object into a technical object in the bot development process and then an agentic object when it is put into use alongside human employees in their work routines, and (2) to evolve and further explore RPA as an epistemic object in the pursuit of scaling automation. 7.2 Practical Implications RPA implementation involves collaboration among diverse actors with different roles and potentially different aspirations for RPA’s immediate and future outcomes. It is important to establish an appropriate organisational structure with dedicated financial and human resources to internalise and consolidate knowledge from vendors and consultants, guide knowledge exchange, coordinate efforts, and manage emergent issues throughout the RPA implementation process in an organisation (e.g. a centre of excellence, Willcocks et al. 2019). Communication is important, particularly around changes in process flows and the impact of RPA on employees. During RPA initiation and mobilisation, the primary focus is on automation and its strategic value, with relatively less attention on augmentation. Employees are often left to imagine for themselves how a bot that has yet to be developed is likely to impact task complexity, work intensity, and job security (Riemer and Peter 2020). This tension can be exacerbated when employees are not well informed about RPA and how the bot works, increasing their concerns about the impact on their work. Ideally, employees impacted by the introduction of bots into their work routines should be engaged soon after initiation and periodically during critical events throughout the implementation (Lacity and Willcocks 2016). The RPA literature has emphasised the importance of careful selection of processes to be automated (Farinha et al. 2024; Plattfaut et al. 2022; Santos et al. 2020). Our study suggests carefully assessing the underlying systems a process interacts with, from both a technical perspective (interface design, frequency of changes) and a governance perspective (ownership of systems and willingness to cooperate), to avoid downstream implications and unwanted outcomes on bot performance. Careful consideration of the nature of the RPA development and the required resources may avoid misperceptions or complications in the implementation process. Tensions may arise from the availability of particular actors’ roles and time commitments, technical skills and learning required to master RPA development, and collaboration with a vendor (Asatiani et al. 2023). Some of these tensions are relevant to IT projects generally and can be anticipated (Plattfaut et al. 2022). RPA is considered relatively easy to configure a bot to automate processes (Lacity and Willcocks 2016). In our study, the experienced developer assigned to the RPA project saw the work of bot configuration as a downgrade to his programming expertise. Australasian Journal of Information Systems Doolin et al. 2025, Vol 29, Research Article Theorising RPA as Socio-Technical Change 23 However, it is also possible that some developers may view RPA as an opportunity to upgrade their expertise and position themselves as more business relevant. 7.3 Limitations and Future Research A limitation of our research is that we only examined RPA implementation in one organisation. Clearly, further case studies would increase confidence in our findings. In particular, comparative case studies in other industries would explore the effects of context in shaping RPA trajectories and outcomes. Salient structural or cultural factors within the specific context of the university we studied included limited financial and human resources for RPA implementation, its instigation by the IT function (rather than a business unit) as a proof of concept for the university, and shifting organisational priorities in a changing educational environment. Nevertheless, the theoretical insights, particularly the conceptual model of RPA implementation as a dynamic and emergent process, offer a useful basis for understanding RPA implementation trajectories more generally. The underlying process patterns that we abstract in our model are transferable, or at least adaptable, across multiple contexts. Although we followed the use of RPA over two years after the bot was deployed, we could not further explore the continued use of RPA and scaling of automation to gain deeper insights into emerging changes and long-term implications. Finally, questions in the interviews were related to both historical and current events (Kimberly and Bouchikhi 1995) leading to the possibility that our participants might not be able to recall all the details from the former (Lyytinen et al. 2009). We addressed this by asking similar questions to triangulate accounts of key events and activities with multiple participants. Our findings suggest that some software developers used to coding in traditional software development may find RPA development experience potentially challenging to their expertise and thus the impact on their professional identity deserves further investigation. For example, future studies may examine potential threats or opportunities software developers experience with RPA development and their differing responses to preserve, strengthen, adjust or expand their occupational identity (Vaast and Pinsonneault, 2021). Other studies could explore the tensions that may occur when developers interact and collaborate with non-technical employees who become involved in RPA development without the software-specific knowledge of regular developers (Siemon and Kedziora 2023; van den Broek et al. 2021). Some scholars encourage researchers to pay attention to the tensions between the automation and augmentation of human work (Benbya et al. 2021) and the need to focus on process improvements without neglecting employee’s quality of work life (Haase et al. 2024; Riemer and Peter 2020). We encourage future studies to take a human-centred view to critically examine the long-term implications of the implementation of RPA and other automation technologies in organisations. Future research could also build on our conceptual model by studying the dynamics and process patterns in further RPA implementation settings or the implementation of other automation technologies, including those with more agency and intelligence, such as conversational agents and AI-powered applications (Baird and Maruping 2021; Farinha et al. 2024; Fügener et al. 2022; Haase et al. 2024; Moderno et al. 2024; Seeber et al. 2020; Siemon 2022). For example, it may be worthwhile for comparative case studies to explore how the introduction of AI and machine learning as part of intelligent process automation may accelerate the trajectory of RPA implementation and shape the contours of the process patterns identified in our study. Another option is to explore how the use of AI-powered tools to Australasian Journal of Information Systems Doolin et al. 2025, Vol 29, Research Article Theorising RPA as Socio-Technical Change 24 support developers shapes the dynamics of the configuration process in RPA implementation. As RPA platforms increasingly integrate AI into various RPA development activities (e.g., process selection, process orchestration), future research could explore how AI as another digital apparatus changes the course of RPA implementation compared with those implementation contexts with no AI involvement. References Abdallah, C., Lusiani, M., & Langley, A. (2019). Performing process research. In Boyd, B., Crook, T. R., Lê, J. K., & Smith, A. D. (Eds.) Standing on the Shoulders of Giants: Traditions and Innovations in Research Methodology (pp. 91-113). Emerald. Aguirre, S., & Rodriguez, A. (2017). Automation of a business process using robotic process automation (RPA): A case study. In Figueroa-García, J., López-Santana, E., Villa- Ramírez, J., Ferro-Escobar, R. (Eds.) Applied Computer Sciences in Engineering (pp. 65-71). Springer. https://doi.org/10.1007/978-3-319-66963-2_7 Andersson, C., Hallin, A., & Ivory, C. (2022). Unpacking the digitalisation of public services: Configuring work during automation in local government. Government Information Quarterly, 39(1), 101662. https://doi.org/10.1016/j.giq.2021.101662 Asatiani, A., Copeland, O., & Penttinen, E. (2023). Deciding on the robotic process automation operating model: A checklist for RPA managers. Business Horizons, 66(1), 109-121. https://doi.org/10.1016/j.bushor.2022.03.004 Asatiani, A., & Penttinen, E. (2016). Turning robotic process automation into commercial success – Case OpusCapita. Journal of Information Technology Teaching Cases, 6(2), 67–74. https://doi.org/10.1057/jittc.2016.5 Baird, A., & Maruping, L. M. (2021). The next generation of research on IS use: A theoretical framework of delegation to and from agentic IS artifacts. MIS Quarterly, 45(1), 315-341. https://doi.org/10.25300/MISQ/2021/15882 Baptista, J., Stein, M. K., Klein, S., Watson-Manheim, M. B., & Lee, J. (2020). Digital work and organisational transformation: Emergent digital/human work configurations in modern organisations. Journal of Strategic Information Systems, 29(2), 101618. https://doi.org/10.1016/j.jsis.2020.101618 Benbya, H., Pachidi, S., & Jarvenpaa, S. L. (2021). Special issue editorial: Artificial intelligence in organizations: Implications for information systems research. Journal of the Association for Information Systems, 22(2), 281-303. https://doi.org/ 10.17705/1jais.00662 Braun, V., & Clarke, V. (2006). Using thematic analysis in psychology. Qualitative Research in Psychology, 3(2), 77–101. https://doi.org/10.1191/1478088706qp063oa Brugali, D., & Gherardi, L. (2016). HyperFlex: A model-driven toolchain for designing and configuring software control systems for autonomous robots. In A. Koubaa (Ed.), Robot Operating System (ROS) (pp. 509-534). Springer. https://doi.org/10.1007/978-3-319-26054- 9_20 Bygstad, B., Nielsen, P. A., & Munkvold, B. E. (2010). Four integration patterns: A socio- technical approach to integration in IS development projects. Information Systems Journal, 20(1), 53-80. https://doi.org/10.1111/j.1365-2575.2007.00280.x Australasian Journal of Information Systems Doolin et al. 2025, Vol 29, Research Article Theorising RPA as Socio-Technical Change 25 Cloutier, C., & Langley, A. (2020). What makes a process theoretical contribution? Organization Theory, 1(1), 1-32. https://doi.org/10.1177/2631787720902473 Coombs, C., Hislop, D., Taneva, S. K., & Barnard, S. (2020). The strategic impacts of Intelligent Automation for knowledge and service work: An interdisciplinary review. Journal of Strategic Information Systems, 29(4), 101600. https://doi.org/10.1016/j.jsis.2020.101600 Cornelissen, J. (2017). Editor’s comments: Developing propositions, a process model, or a typology? Addressing the challenges of writing theory without a boilerplate. Academy of Management Review, 42(1), 1-9. https://doi.org/10.5465/amr.2016.0196 Cornish, F., Gillespie, A., & Zittoun, T. (2014). Collaborative analysis of qualitative data. In U. Flick (Ed.) The SAGE Handbook of Qualitative Data Analysis (pp. 79-93). SAGE. Crawford, H. K., Leybourne, M. L., & Arnott, A. (2000). How we ensured rigour in a multisite, multi-discipline, multi-researcher. Forum Qualitative Sozialforschung / Forum: Qualitative Social Research, 1(1), Article 12. https://doi.org/10.17169/fqs-1.1.1122 Dey, S., & Das, A. (2019). Robotic process automation: Assessment of the technology for transformation of business processes. International Journal of Business Process Integration and Management, 9(3), 220-230. https://doi.org/10.1504/IJBPIM.2019.100927 Engel, C., Ebel, P., & Leimeister, J. M. (2022). Cognitive automation. Electronic Markets, 32, 339- 350. https://doi.org/10.1007/s12525-021-00519-7 Engeström, Y., & Blackler, F. (2005). On the life of the object. Organization, 12(3), 307-330. https://doi.org/10.1177/1350508405051268 Ewenstein, B., & Whyte, J. (2009). Knowledge practices in design: The role of visual representations as ‘epistemic objects’. Organization Studies, 30(1), 7-30. https://doi.org/10.1177/017084060808301 EY (2017). Get Ready for Robots: Why Planning Makes the Difference Between Success and Disappointment. https://assets.ey.com/content/dam/ey-sites/ey-com/en_gl/topics/emeia- financial-services/ey-get-ready-for-robots.pdf Fachin, F. F., & Langley, A. (2017). Researching organizational concepts processually: The case of identity. In Cassell, C., Cunliffe, A. L., & Grandy, G. (Eds.) The SAGE Handbook of Qualitative Business and Management Research Methods. (pp. 308-327). SAGE. https://doi.org/10.4135/9781526430212 Faraj, S., Pachidi, S., & Sayegh, K. (2018). Working and organizing in the age of the learning algorithm. Information and Organization, 28(1), 62-70. https://doi.org/10.1016/j.infoandorg.2018.02.005 Farinha, D., Pereira, R., & Almeida, R. (2024). A framework to support robotic process automation. Journal of Information Technology, 39(1), 149-166. https://doi.org/10.1177/02683962231165066 Feldman, M. S., & Orlikowski, W. J. (2011). Theorizing practice and practicing theory. Organization Science, 22(5), 1240–1253. https://doi.org/10.1287/orsc.1100.0612 Fügener, A., Grahl, J., Gupta, A., & Ketter, W. (2022). Cognitive challenges in human–artificial intelligence collaboration: Investigating the path toward productive delegation. Information Systems Research, 33(2), 678-696. https://doi.org/10.1287/isre.2021.1079 https://doi.org/10.1177/02683962231165066 Australasian Journal of Information Systems Doolin et al. 2025, Vol 29, Research Article Theorising RPA as Socio-Technical Change 26 Gherardi, S. (2009). Knowing and learning in practice-based studies: An introduction. Learning Organization, 16(5), 352-359. https://doi.org/10.1108/09696470910974144 Glaser, V. L. (2017). Design performances: How organizations inscribe artifacts to change routines. Academy of Management Journal, 60(6), 2126-2154. https://doi.org/10.5465/amj.2014.0842 Güner, E., Han, S., & Juell-Skielse, G. (2020). Robotic process automation as routine capability: A literature review. In Proceedings of the 28th European Conference on Information Systems (ECIS). https://aisel.aisnet.org/ecis2020_rp/153 Haase, J., Kremser, W., Leopold, H., Mendling, J., Onnasch, L., & Plattfaut, R. (2024). Interdisciplinary directions for researching the effects of robotic process automation and large language models on business processes. Communications of the Association for Information Systems, 54(1), 579-604. https://doi.org/10.17705/1CAIS.05421 Hallikainen, P., Bekkhus, R., & Pan, S. (2018). How OpusCapita used internal RPA capabilities to offer services to clients. MIS Quarterly Executive, 17(1), 41-52. https://aisel.aisnet.org/misqe/vol17/iss1/4 Herm, L. V., Janiesch, C., Reijers, H. A., & Seubert, F. (2021). From symbolic RPA to intelligent RPA: Challenges for developing and operating intelligent software robots. In A. Polyvyanyy, M. T. Wynn, A. Van Looy, & M. Reichert (Eds.) Business Process Management (pp. 289-305). Springer. https://doi.org/10.1007/978-3-030-85469-0_19 Hofmann, P., Samp, C., & Urbach, N. (2020). Robotic process automation. Electronic Markets, 30(1), 99-106. https://doi.org/10.1007/s12525-019-00365-8 Kimberly, J. R., & Bouchikhi, H. (1995). The dynamics of organizational development and change: How the past shapes the present and constrains the future. Organization Science, 6(1), 9-18. https://doi.org/10.1287/orsc.6.1.9 Knorr Cetina, K. (2008). Objectual practice. In M. Mazzotti (Ed.), Knowledge as Social Order (pp. 1-15). Routledge. https://doi.org/10.4324/9781315591148 Kokina, J., & Blanchette, S. (2019). Early evidence of digital labor in accounting: Innovation with Robotic Process Automation. International Journal of Accounting Information Systems, 35, 100431. https://doi.org/10.1016/j.accinf.2019.100431 Lacity, M. C., & Willcocks, L. P. (2016). Robotic process automation at Telefónica O2. MIS Quarterly Executive, 15(1), 21-35. https://aisel.aisnet.org/misqe/vol15/iss1/4 Lacity M., & Willcocks, L. (2021). Becoming strategic with intelligent automation. MIS Quarterly Executive, 20(2), 169-182. https://aisel.aisnet.org/misqe/vol20/iss2/7 Langley, A. (1999). Strategies for theorizing from process data. Academy of Management Review, 24(4), 691-710. https://doi.org/10.2307/259349 Langley, A. (2023). Approaches to studying continuity and change. In Hernes, T., & Feuls, M. (Eds.) A Research Agenda for Organisational Continuity and Change (pp. 225-246). Edward Elgar. Langley, A., & Ravasi, D. (2019). Visual artifacts as tools for analysis and theorizing. In Zilber, T. B., Amis, J. M., & Mair, J. (Eds.) The Production of Managerial Knowledge and Australasian Journal of Information Systems Doolin et al. 2025, Vol 29, Research Article Theorising RPA as Socio-Technical Change 27 Organizational Theory: New Approaches to Writing, Producing and Consuming Theory (pp. 173-199). Emerald. https://doi.org/10.1108/S0733-558X20190000059010 Langley, A., Smallman, C., Tsoukas, H., & Van De Ven, A. H. (2013). Process studies of change in organization and management: Unveiling temporality, activity, and flow. Academy of Management Journal, 56(1), 1-13. https://doi.org/10.5465/amj.2013.4001 Lawrence, T. B., & Suddaby, R. (2006). Institutions and institutional work. In Clegg, S. R., Hardy, Lawrence, T. B., & Nord, W. R. (Eds.) The SAGE Handbook of Organization Studies (pp. 215-254). SAGE. https://doi.org/10.4135/9781848608030.n7 Leno, V., Polyvyanyy, A., Dumas, M., La Rosa, M., & Maggi, F. M. (2021). Robotic process mining: Vision and challenges. Business & Information Systems Engineering, 63(3), 301-314. https://doi.org/10.1007/s12599-020-00641-4 Leonardi, P. M. (2015). Studying work practices in organizations: Theoretical considerations and empirical guidelines. Annals of the International Communication Association, 39(1), 235- 273. https://doi.org/10.1080/23808985.2015.11679177 Lyytinen, K., & Newman, M. (2008). Explaining information systems change: A punctuated socio-technical change model. European Journal of Information Systems, 17(6), 589-613. https://doi.org/10.1057/ejis.2008.50 Lyytinen, K., Newman, M., & Al-Muharfi, A.-R. A. (2009). Institutionalizing enterprise resource planning in the Saudi steel industry: A punctuated socio-technical analysis. Journal of Information Technology, 24(4), 286-304. https://doi.org/10.1057/jit.2009.14 McLeod, L., & Doolin, B. (2012). Information systems development as situated socio-technical change: A process approach. European Journal of Information Systems, 21(2), 176-191. https://doi.org/10.1057/ejis.2011.43 Moderno, O., Braz, A. C., & Nascimento, P. (2024). Robotic process automation and artificial intelligence capabilities driving digital strategy: A resource-based view. Business Process Management Journal, 30(1), 105-134. https://doi.org/10.17705/1CAIS.05421 Nicolini, D., Mengis, J., & Swan, J. (2012). Understanding the role of objects in cross- disciplinary collaboration. Organization Science, 23(3), 612-629. https://doi.org/10.1287/orsc.1110.0664 Nicolini, D., & Monteiro, P. (2016). The practice approach: For a praxeology of organisational and management studies. In Langley, A., & Tsoukas, H. (Eds.) The SAGE Handbook of Process Organization Studies (pp. 110-126). SAGE. https://doi.org/10.4135/9781473957954 Orlikowski, W. J. (1992). The duality of technology: Rethinking the concept of technology in organizations. Organization Science, 3(3), 398-427. https://doi.org/10.1287/orsc.3.3.398 Orlikowski, W. J. (1996). Improvising organizational transformation over time: A situated change perspective. Information Systems Research, 7(1), 63-92. https://doi.org/10.1287/isre.7.1.63 Østerlund, C., & Carlile, P. (2005). Relations in practice: Sorting through practice theories on knowledge sharing in complex organizations. The Information Society, 21(2), 9-107. https://doi.org/10.1080/01972240590925294 Australasian Journal of Information Systems Doolin et al. 2025, Vol 29, Research Article Theorising RPA as Socio-Technical Change 28 Pentland, B. T. (1999). Building process theory with narrative: From description to explanation. Academy of Management Review, 24(4), 711-724. https://doi.org/10.2307/259350 Pickering, A. (1995). The Mangle of Practice: Time, Agency, and Science. University of Chicago Press. https://doi.org/10.2307/3106908 Plattfaut, R., & Borghoff, V., (2022). Robotic process automation: A literature-based research agenda. Journal of Information Systems, 36(2), 173-191. https://doi.org/10.2308/ISYS-2020- 033 Plattfaut, R., Borghoff, V., Godefroid, M., Koch, J., Trampler, M., & Coners, A. (2022). The critical success factors for robotic process automation. Computers in Industry, 138, 103646. https://doi.org/10.1016/j.compind.2022.103646 Raisch, S., & Krakowski, S. (2021). Artificial intelligence and management: The automation- augmentation paradox. Academy of Management Review, 46(1), 192-210. https://doi.org/10.5465/amr.2018.0072 Ranerup, A., & Henriksen, H. Z. (2019). Value positions viewed through the lens of automated decision-making: The case of social services. Government Information Quarterly, 36(4), 101377. https://doi.org/10.1016/j.giq.2019.05.004 Rheinberger, H. (2005). A reply to David Bloor: "Toward a sociology of epistemic things." Perspectives on Science, 13(3), 406-410. https://doi.org/10.1162/106361405774287973 Rheinberger, H. (2011). Consistency from the perspective of an experimental systems approach to the sciences and their epistemic objects. Manuscrito, 34(1), 307-321. https://doi.org/10.1590/S0100-60452011000100014 Riemer, K., & Peter, S. (2020). The robo-apocalypse plays out in the quality, not in the quantity of work. Journal of Information Technology, 35(4), 310-315. https://doi.org/10.1177/0268396220923677 Ritvala, T., & Kleymann, B. (2012). Scientists as midwives to cluster emergence: An institutional work framework. Industry and Innovation, 19(6), 477-497. https://doi.org/10.1080/13662716.2012.718875 Salmimaa, T., Hekkala, R., & Pekkola, S. (2018). Dynamic activities for managing an IS-enabled organizational change. Business & Information Systems Engineering, 60, 133-149. https://doi.org/10.1007/s12599-018-0524-6 Santos, F., Pereira, R., & Vasconcelos, J. B. (2020). Toward robotic process automation implementation: An end-to-end perspective. Business Process Management Journal, 26(2), 405-420. https://doi.org/10.1108/BPMJ-12-2018-0380 Schmitz, M., Dietze, C., & Czarnecki, C. (2019). Enabling digital transformation through robotic process automation at Deutsche Telekom. In N. Urbach & M. Röglinger (Eds.) Digitalization Cases: How Organizations Rethink Their Business for the Digital Age (pp. 15- 33). Springer. https://doi.org/10.1007/978-3-319-95273-4_2 Seeber, I., Waizenegger, L., Seidel, S., Morana, S., Benbasat, I., & Lowry, P. B. (2020). Collaborating with technology-based autonomous agents: Issues and research opportunities. Internet Research, 30(1), 1-18. https://doi.org/10.1108/INTR-12-2019-0503 Australasian Journal of Information Systems Doolin et al. 2025, Vol 29, Research Article Theorising RPA as Socio-Technical Change 29 Siemon, D. (2022). Elaborating team roles for artificial intelligence-based teammates in human- AI collaboration. Group Decision and Negotiation, 31, 871-912. https://doi.org/10.1007/s10726-022-09792-z Siemon, D., & Kedziora, D. (2023). From accountant to software developer – Transforming employees with robotic process automation (RPA). Proceedings of the 56th Hawaii International Conference on System Sciences (pp. 4244- 4253). https://aisel-aisnet-org/hicss- 56/in/digital_transformation/6 Staaby, A., Hansen, K., & Gronli, T. M. (2021). Automation of routine work: A case study of employees’ experiences of work meaningfulness. Proceedings of the 54th Hawaii International Conference on System Sciences (pp. 156-165). https://aisel-aisnet-org/hicss- 54/cl/ai_and_future_work/4/ Syed, R., Suriadi, S., Adams, M., Bandara, W., Leemans, S. J. J., Ouyang, C., ter Hofstede, A. H. M., van de Weerd, I., Wynn, M. T., & Reijers, H. A. (2020). Robotic process automation: Contemporary themes and challenges. Computers in Industry, 115, 103162. https://doi.org/10.1016/j.compind.2019.103162 Techatassanasoontorn, A. A., Waizenegger, L., & Doolin, B. (2023). When Harry, the human, met Sally, the software robot: Metaphorical sensemaking and sensegiving around an emergent digital technology. Journal of Information Technology, 38(4), 416-441. https://doi.org/10.1177/02683962231157426 Vaast, E., & Pinsonneault, A. (2021). When digital technologies enable and threaten occupational identity: The delicate balancing act of data scientists. MIS Quarterly, 45(3), 1087-1112. https://doi.org/10.25300/MISQ/2021/16024 van den Broek, E., Sergeeva, A., & Huysman, M. (2021). When the machine meets the expert: An ethnography of developing AI for hiring. MIS Quarterly, 45(3), 1557-1580. https://doi.org/10.25300/MISQ/2021/16559 Van De Ven, A. H., & Poole, M. S. (2005). Alternative approaches for studying organizational change. Organization Studies 26(9), 1377-1404. https://doi.org/10.1177/0170840605056907 van der Aalst, W. M. P., Bichler, M., & Heinzl, A. (2018). Robotic process automation. Business & Information Systems Engineering, 60(4), 269-272. https://doi.org/10.1007/s12599-018- 0542-4 Viehhauser, J., & Doerr, M. (2021). Digging for gold in RPA projects – A quantifiable method to identify and prioritize suitable RPA process candidates. In La Rosa, M., Sadiq, S., & Teniente, E. (Eds.) Advanced Information Systems Engineering (pp. 313-327). Springer. https://doi.org/10.1007/978-3-030-79382-1_19 Waizenegger, L., & Techatassanasoontorn, A. A. (2022). When robots join our team: A configuration theory of employees' perceptions of and reactions to robotic process automation. Australasian Journal of Information Systems, 26, 1-33. https://doi.org/10.3127/ajis.v26i0.3833 Willcocks, L., Hindle, J., & Lacity, M. (2019). Keys to RPA Success: How Blue Prism Clients Are Gaining Superior Long Term Business Value Knowledge Capital Partners Executive Research Report. Australasian Journal of Information Systems Doolin et al. 2025, Vol 29, Research Article Theorising RPA as Socio-Technical Change 30 Copyright Copyright © 2025 Doolin, B., Techatassanasoontorn, A. A., Waizenegger, L. and Wallace- Carter, E. This is an open-access article licensed under a Creative Commons Attribution-Non- Commercial 4.0 Australia License, which permits non-commercial use, distribution, and reproduction in any medium, provided the original author and AJIS are credited. doi: https://doi.org/10.3127/ajis.v29.5451 https://creativecommons.org/licenses/by-nc/4.0/deed.en https://creativecommons.org/licenses/by-nc/4.0/deed.en