1 Introduction

Defined as the ability to identify, assimilate, and apply external knowledge (Cohen & Levinthal, 1990a), absorptive capacity (AC) has become a powerful analysis tool to uncover how organizations explore and integrate new knowledge (Zahra & George, 2002a). AC has been accepted as an important construct for IS scholars in the last two decades to study learning processes associated with enterprise systems (Gao et al., 2017; Liu et al., 2013; Marabelli & Newell, 2014; Roberts et al., 2012).

AC literature focuses on the construct of learning in a static manner (Roberts et al., 2012; Vasconcelos et al., 2019). AC is usually conceptualised as a knowledge stock that leads to creative, competitive advantage and innovation (Cohen & Levinthal, 1990a; Dyer & Singh, 1998; García-Sánchez et al., 2018; Todorova & Durisin, 2007; Tsai, 2001). There is an awareness that AC is context sensitive and that changes in context could act as triggers for change of AC (Machado et al., 2020; Marabelli & Newell, 2019). However, the evolution and the development of AC itself has not been in focus. Indeed, how it develops in a constantly changing context has not yet been studied. It is clear that change is the nature of every business. This could be caused by business strategy change, people moving, supply chain development, technology improvement. Hence, AC context is changing constantly overtime ( Allen et al., 2002; Denicolai et al., 2016; Van Den Bosch et al., 1999). There still is a lack of empirical studies which examine the dynamics of AC development over in a changing context. This paper presents such an empirical study that tracks the AC of an organisation over more than a ten-year period buffeted by huge changes. The paper addresses the following two research questions:

  1. 1)

    What is the role of context change in the long-term AC development in an enterprise system project?

  2. 2)

    How AC and enterprise system practice co-construct and co-evolve in a changing context?

Construing ERP implementation as the underpinning of AC in an organization’s enterprise system implementation is common in IS. The implementation is described as the process of attempting to respond to new knowledge by enhancing the learning ability. The system implementation is a continuous learning process to explore and exploit new knowledge (Chadhar & Daneshgar, 2018; Nandhakumar et al., 2005; Saad et al., 2017; Upstill-Goddard et al., 2016), but the longitudinal assessment of enterprise system has been less touched (Sedera & Lokuge, 2020). In order to uncover the development of AC under the changing context, this study adopted a case study about 15 years’ ERP system practice at a steel manufacture group, which covers the initial system installation, a series of system upgrades, until the business owner changed, and the system was abandoned. This paper contributes to the IS literature by offering a framework, which reflects the long-term co-evolution process between AC and the information system. The framework highlights the influence of contextual change in this process. Our methodological approach to AC analysis and enterprise system practice in synthesizing this framework is qualitative. Compared to quantitative methods commonly used AC analysis (Gao et al., 2017), qualitative analysis allows an in-depth analysis of learning and practice over time (Neuman, 2010). This paper also uncovers the value and the demand for a long-term case study on AC and information system.

The rest of this paper is structured as follows: Section 2 provides a review of AC literature and highlights critical gaps. Section 3 presents the chosen longitudinal case study and offers some in-depth insights on why AC is a major organizational capability in an IS project in a changing context. A timeline is adopted to show the interplay and syntheses between AC, enterprise system and work practice. Section 4 analyses the data between 2004 and 2018 and develops an AC model in enterprise systems implementation. The final section presents conclusions and identifies avenues for future research.

2 Theoretical Background

2.1 Absorptive Capacity in the IS Literature

Absorptive capacity (AC) has its prominent role in IS research. As mentioned earlier, Cohen and Levinthal (1990a) defined AC as “the ability of a firm to recognize the value of new, external information, assimilate it, and apply it to commercial ends”. Subsequent studies conceptualized it as either an asset (i.e., knowledge base)(Boynton et al., 1994; García-Sánchez et al., 2018; Lane et al., 2006) or as a capability (substantive or dynamic) (Denicolai et al., 2016; Gao et al., 2017; Roberts et al., 2012). Both concepts are static and limiting. An asset is defined as anything tangible or intangible that a firm owns, controls, or has access to on a semi-permanent basis (Helfat & Peteraf, 2003). When viewed as an asset, AC is conceptualized as relevant prior knowledge possessed by the focal unit (Roberts et al., 2012). This static perspective equates it with the firm’s knowledge base (i.e., the level of knowledge it possesses at any single point in time). As such, its analysis operationalizes AC with variables that serve as proxies for the knowledge base, such as R&D intensity and patents (Tsai, 2001), management of intangibles (Sánchez et al., 2000), knowledge transferring (Xu & Ma, 2008) and supply chain alignment (Machado et al., 2020).

AC is clearly a substantive organizational capability (a high-level routine or set of routines) to gain, utilize, and release intangible resources (Golgeci & Kuivalainen, 2020; Zou et al., 2016). It confers a set of decision options on an organization’s management for producing significant outputs of a particular type (Zollo & Winter, 2002), or options which firms can use to identify, assimilate, transform, and apply external knowledge (Bharati et al., 2014; Roberts et al., 2012). AC measures as a capability include compensation policies, dominant logic, knowledge-sharing routines, and competencies (Marabelli & Newell, 2019; Marttila et al., 2017; Patterson & Ambrosini, 2015; Upstill-Goddard et al., 2016). There is onside agreement in conceptualizing AC as a capability embedded in the organization for utilizing external resources (Bharati et al., 2014; Gao et al., 2017; Mariano & Walter, 2015).

2.2 The Construct of Absorptive Capacity

Reframing the construct of AC, this study examines alternate ways of studying it. For instance, Dyer and Singh (1998) propose a method that contrasts with the single-loop learning process described by Cohen and Levinthal. They view AC as an iterative process of exchange (modifying assumptions). Lane and Lubatkin (1998) develop the idea of “relative absorptive capacity”. They assess AC as a learning dyad –in which a firm’s ability to learn from another firm depends on similarities in their knowledge bases, organizational structures, and dominant logics. Zahra and George (2002a) provide a procedural view of AC as a dynamic capability and suggest that the construct has potentially two general states. The first is when firms acquire and assimilate new knowledge. The second is when firms transform and exploit new knowledge. Lane et al., (2006) propose a reconceptualization of AC. They model AC, its antecedents, and its outcomes, based on Cohen and Levinthal’s (1990a) three processes (recognition, assimilation, and application of new external knowledge), seen as sequential and based on exploratory learning, transformative learning, and exploitative learning. Todorova and Durisin (2007) focus on the efficiency of AC, and introduce a framework that captures its dynamism through the addition of feedback loops. In 2015, Patterson and Ambrosini (2015) reconfigure the construct by exploring the “new” interactive AC and interactive process flow sequence. Even more scholars integrated the AC as part of their framework on system adaptation (Gopalakrishna-Remani et al., 2019), new product development (Chang et al., 2016) and research and development (Denicolai et al., 2016; Gao et al., 2017). In summary, many scholars try to redefine the construct of absorptive capacity, but their conclusions are neither complete nor mature and settled.

AC, as an important theory to understand the knowledge processing processes in an organization, clearly plays an important role in studying IS. Empirical AC research generally focuses on snapshot analysis. Lack of longitudinal research hampered the development of a comprehensive view of the phenomena. The literature has also been restricted exclusively to quantitative orientation. Thus, empirical studies concentrated on specific measurement of AC and/or its outcomes (Gopalakrishna-Remani et al., 2019; Roberts et al., 2012). Several scholars have tried to operationalize it and its outcomes (innovation) using patents and other indicators of R&D unit performance (Gao et al., 2017). However, using the same measure for both the dependent and the independent variables makes it difficult to compare and evaluate AC outcomes. Even studies that differentiate these constructs, still produced inconsistent results. For instance, Meeus et al., (2001) and Mowery et al. (1996) use R&D units to proxy for AC, while Tsai (2001) uses patents to proxy for innovation. Mowery et al (1996) show that R&D intensity is only poorly related to organizational learning. Lane et al., (2006) question the appropriateness and validity of this proxy-based approach to analyse AC. Operationalizing AC constructs using tangible outcomes (i.e. numbers of patents) led to scholars often overlooking less concrete outputs such as within-firm capabilities to acquire, manage, and exploit knowledge over time and dynamically. This suggests that there is a need to use a qualitative lens to deepen our understanding of AC as the capability from a higher-level process perspective and to extend our understanding into its longitudinal development.

2.3 Call for Uncovering the Dynamic Nature of Absorptive Capacity from a Longitudinal Perspective

Despite various re-conceptualizations of AC, only a few have a theoretical focus on how AC develops, why and under what conditions. Zahra and George’s (2002a) highly cited article describes AC as a dynamic capability and a set of organizational routines. Its potential in studying the AC development process is largely overlooked (Maldonado et al., 2019). Representative papersFootnote 1 on AC treat the construct only partially or develop just one level of analysis. Dyer and Singh (1998) make an important contribution presenting AC as a double-loop learning process that is (or may be) related to performance and competitive advantage. Although their arguments are convincing about the extent to which AC impacts relational rent, but they do not discuss the actual process. While Zahra and George (2002a) capture the dynamic of AC and treat it as a process, as later noted by Todorova and Durisin (2007), they still do not integrate other views of AC as a continued process (Gao et al., 2017). Their construct proposes a sequence of “phases” in the learning process with little attention to the longitudinal iterative nature of this process (Zou et al., 2016), as recently pointed out in a review and reconceptualization study by Vasconcelos et al. (2019). From this perspective, an enterprise system can be regarded as a continuous umbrella project. This situates the project in a constantly changing and dynamic context (Imre, 2016; Marabelli & Newell, 2009). The logical extension of this perspective is that a longitudinal view is needed to investigate the concomitant absorptive capacity processes (Vasconcelos et al., 2019).

In summary, although AC is accepted as an important theory in IS and has been applied in a diverse range of research, still there are clear gaps: a) use of a qualitative lens can deepen our understanding of AC as the capability from a process perspective, b) a further understanding of organisational AC from the longitudinal aspect and its development are needed, and c) uncovering the synergy of AC, system adaptation and business changes through an integrated view is needed. Towards addressing those gaps, in this paper, a continuous process to model organisational AC will be adopted during our data presentation and interpretation.

3 Methods and Research Context

3.1 Research Methods

In line with Walsham (1993), this study adopts an approach that assumes that reality, including the organizational actor domain, is a social construct. This approach is consistent with our aims in the study. The study regards AC as an essential dynamic capacity of an organization and aims to move beyond the traditional view that treats AC as an objective reality (defining antecedents and drivers) with predictable outcomes that contribute to organizational learning (measuring the outcomes). We believe that long-term studies, e.g., observing an enterprise system appropriation, provide an insightful way to understand the overtime interaction between AC and organizational change. A longitudinal case study will also allow meaningful insights into showing how knowledge processing and organizational performance are co-evolved in a changing environment (Fisher et al., 2008), and how organizational operation developed through various organizational actors, social context and exogenous factors and the historical context (Rao and De’, 2015; Wu et al., 2021). This is consistent with Wagner and Newell (2006)’s view that full implementation of a technology (in which the system is exploited effectively by users and managers) involves continuous adaptation between the information system (IS) and the organization.

A large scale enterprise system is a packaged software that integrates processes, activities, and disparate data from multiple departments (Ali & Miller, 2017; Davenport & Montgomery, 2000). Implementation of such a system is a long and complex process. Knowledge processing capability is required to understand the potential of such a large-scale IS, and to appropriate and exploit its potential for organizational performance (Acar et al., 2017; Marabelli & Newell, 2019).

Therefore, studying the long-term enterprise system appropriation enables the collection of rich information on how knowledge processing capability and business practice are matured and co-constructed over time. The next section shows our interpretive approach and its advantages here: 1) it is helpful to understand the dynamics between knowledge processing processes and working practices through the enterprise system appropriation; 2) it is necessary to uncover the long-term development of AC; and 3) it is able to provide an integrated view about the influence of contextual changes on AC and system related working practices.

3.2 Case Selection

The case organization is a large-scale privately-owned iron and steel company (OgemaFootnote 2) in China. The fully integrated business of Omega covers mining, coking coal, iron and steel production, and steel remanufacturing. Apart from its operation bases and factories—Omega also has trading subsidiaries in southern China, Australia and New Zealand. In 2015, Omega had about 7000 employees and an annual turnover of 1 billion USD. However, the overproduction in the Chinese steel industry and changed banking policy in 2014 led to serious business rescission. As a result, in 2016, the business ownership moved to public hands (specifically to the local government), and by 2018 the business finally closed. The observed enterprise system within Omega was initiated in 2004. The system gradually rolled out throughout the organisation during the ensuing 14 years. It gradually covered the entire organization covering both operations and executive management levels. Due to the business crisis in 2016, the system use was gradually rolled back. It was withdrawn from the entire organization including management level, and was restricted to the financial, sale, inventory management and bookkeeping only. Until 2018 the system was finally abandoned with the closure of the business.

4 Data Analysis

4.1 Data Collection

The data in this study was collected using multiple tools: interviews, observations and from documents. Data collection commenced in February 2004 and was completed in April 2018. During this period, author, Kai, was working on the enterprise system project as ERP team leader from 2004 to 2007. The data collected from 2008 to 2012 was part of his PhD study (Wu, 2012), and he revisited Omega in 2013 and 2018, in multiple times 2018 further data collection studies were completed. In general Kai visited Omega six times, with each visit lasting approximately 15 days. In each visit he interviewed between 15 to 25 key users, which included the senior managers, IT staffs, ERP consultants and key users on latest project updates. Each visit also included the onsite observation for watching the system operation and participating project meeting to experience system use and user behaviour in the real context between 3 – 5 days. The documents collected includes the ERP project documents, consulting reports, ERP project diary company documents and meeting records between 2004 and 2018 for 265 documents in total.

In essence, the case is based on retrospective data collection (2004–2007), longitudinal work (2008—2012), and retrospective data collection (2013–2018). Interviewees were selected by both judgment and snowball sampling method (Marshall, 1996; Taherdoost, 2016). The interviews were semi-structured, as they were guided by the research objectives and questions (Kallio et al., 2016; Wright & Wright, 2002). Structured questions with prompts to guide the interviewee were used. This elicited feedback from users about the IT capabilities, learning development, knowledge management and their own assessment of periodical changes during the system implementation, working practices and contextual changes.

The next section presents the data analysis and interpretation about the Omega enterprise system project. This illustrates the longitudinal view covering events that have led to the appropriation of the system and its impact on related working practices in the changing context. Figure 1 illustrates the timeline of the defining events at Omega.

Fig. 1
figure 1

Omega enterprise system implantations and uses

Full size image

4.2 Data Interpretation

This section provides a narrative of the enterprise system implementation and deployment in Omega over a period spanning fifteen years. In early 2004, Omega decided to acquire the X ERP system from Octopus.Footnote 3 During the ten years that followed, Omega took a series of system implementation practices to broaden the scope of the system use from bookkeeping at the Information Centre to also provide a management tool providing a holistic view of the organization. In essence the system also became a strategy support and development asset. However, in 2014, the steel industry overproduction and financial market restriction caused a series of business crises at Omega, such as the departure of key people, change in the business ownership, and in 2018 finally the closure of the business. In this case, the use of the ERP system started from almost ‘zero’ and developed gradually into a strategic asset, but the business recession eventually caused the system to be abandoned. Omega enterprise system story provided us with a unique opportunity to examine a full lifecycle of an organization’s enterprise system from implementation, use and maintenance to decommissioning.

From the project documentation, interviews with key actors, and on-site observations, six project phases were identified. Each phase is characterised by its own timeline and a cluster of implementation activities, use practices and context changes. The six phases demonstrate the entire lifecycle of Omega’s enterprise system project. The system was initiated in early 2004 and went ‘go-live’ in the middle of 2005 with two rounds of system installations. In the following three years, Omega took an unusual practice to apply the system as a data recording machine at the Information Centre for recording the business data daily (Phase One: Business Data Recording). In the middle of 2007, the system was deployed into various departments to support the real work processes (Phase Two: Business Support). Since 2009, Omega took a series of actions to broaden the system application to support management (Phase Three: Management Tool). In 2012, Omega began to replace their existing system with the “next generation” enterprise system (B/S architecture system) for supporting the new business structure and managing their expanding global supply chain. After one and half year’s business consultation and system configuration, Omega adopted a ‘new’ system at the Supply Chain Management Department (SCMD) (Phase Four: A Strategic Asset).

In 2014, due to overproduction of the steel products and a growing stockpile, the Chinese central government tightened credit access for the steel industry as a whole. This external event led to Omega business recession, and the Y system project deployment was stopped at the SCMD as well (Phase Five: Business Crisis). In 2016, Omega’s initial business owner eventually sold Omega’s majority stake to the local government so that they can repay their business loans. In the following two years’ time, the business was continually constructed, and it finally closed in 2018. The scale of the enterprise system was reduced accordingly and finally abandoned (Phase Six: New business owner). These six phases are not strictly sequential. They overlap as shown in Fig. 1.

In Fig. 1, the orange hexagons show the various phases of system operation from implementation and expansive use to contraction, and the grey rectangles demonstrate the project phases from the start to business closure. The system implementation and use are in sequence but clearly overlap. For example, when the system deployment was not completed yet in the entire organization, some departments already started to use the system to improve their business and support the decision making. Hence, Phase Two and Phase Three overlap during that period. A deeper analysis is conducted in the next section. We take a deeper look at the six phases of the Omega project under the theoretical lenses of absorptive capacity to uncover how Omega system implementation and organizational changes co-evolve over time in the dynamic context.

4.2.1 Phase One: System Installation and Data Recording Practice—Early 2004 to Middle 2007

In early 2004, Robert was appointed by the Chairman to act as a CEO. His overseas education helped him understand the power of enterprise systems. At that time, Omega had very limited IT experience and almost “zero” enterprise system knowledge. Kai recalls that: “When Robert asked me to start an ERP project, I knew almost nothing about ERP… We followed the consultation advice and adopted a ‘big bang’ implementation… But six months later, as Kai recalled: 30% of the system inventory record did not match with the paper book record”. The failure has been summarized as: exceeding project scope, inadequate data preparation, human mistakes and insufficient business knowledge. [Vignette: Extracts from “X System Implementation Report 3.0″].

Based on the failure experience, Omega has taken a series of actions for success adopting the system. As Kai observed, there are three major actions taking the major roles, as recruiting new IT staffs and setting up an enterprise system team at a new Information Centre (IC); then e-scoping the implementation from 9 system modules to 4 modules and limiting the application from business departments to IC only.

In the two years that followed, the business departments provided their paperwork on a daily basis to IC. The system operators input data manually into the system. The operation was described by Jane, CIO in Omega, as “the hardest time for X system project” [Interview September 2009]. Leng, the ERP system technician later said: Finally, we could basically know the system and the business. [Interviewed February 2010].

Author was working on this project during this period of time. Based on his observation, this ERP project has been described as the new CEO initiated the ERP project for upgrading the ‘management’, the ‘zero’ pre-related knowledge and ‘big pond’ system implementation, caused the first system installation failure. Through the two years system operation in IC, both system and business knowledge have been assimilated into the IT staffs.

4.2.2 Phase Two: Using System to Support Business Processes—Middle 2007 to Late 2009

As the system and business knowledge was assimilated among the IT staffs and the system use was stabilized in the IC, in mid-2007, Omega decided to deploy the system. This was first done into the business units, and then into the manufacturing units.

In order to assimilate the knowledge from IC into the business units, and force staff to learn the system operation, Omega has setup the temporary company regulation. The key rules are as the follows:

  • All system operators have been assigned from IC into the business units.

  • If the employees who have been assigned to operate the system cannot learn basic computer system operation in 15 days, they will be fired.

  • The employee responsible for their mis-operation related issues.

  • The company HR and office departments monitor the execution of this policy.

[Omega ERP System Project Regulation 2007 V2]

Through these series of actions, the system has been adopted by the business units, as the CEO Robert described: “the system has become part of their daily works and the business was working on the system”.

Based on the interview and 5 days on site observation, Kai noticed that through the two rounds of system deployments, Omega was able to assimilate and deploy the system knowledge outside the IC into the business units and the manufacturing units. The system was integrated into the business to share and process data.

4.2.3 Phase Three: System Applied as a Management Tool—Late 2008 to Middle 2012

After late 2008, Omega took a series of steps to acquire the new system knowledge for improving the business management, which are Office Automation – in later 2008; Logistics Management – in early 2009; and Vendor Managed Inventory – in early 2010. [Vignette: Extracts from “X System Report 2010”]. By implying these modules Omega was able to exploit the advancement in the system (i.e., refining, extending, and leveraging existing competencies through the X system), as Jane explained:

I noticed that some higher prices (paid higher prices for purchasing the spare parts and equipment). I cannot just tell them directly and must keep some “face” to them, so I decided to use the system to control this. [Interview September 2011].

In addition, the accumulated IT and enterprise system knowledge enabled Omega to step forward to develop the in-house system for supporting its business demands. As Jane explained:

Since 2009 we started to develop some small application by ourselves to manage the logistics and monitoring the product quality. [Interview May 2014].

Through the system knowledge assimilation in the business units, Omega’s senior management level was able to recognize the value of ERP system. Therefore, the ERP system application has been improved from data recording to management support.

4.2.4 Phase Four: System Adopted as a Strategic Asset – Late 2012 to Late 2014

In 2012, as the business developed, Omega business structure changed from several individual companies into a coherent group company. In the same year, Omega started to purchase raw materials from overseas suppliers directly and set up a Supply Chain Management Department (SCMD) to manage the international and domestic logistics (transactions, ordering and so on). However, the pre-existing X system could not support these emerging business requirements. Omega had to look for a new ERP solution and then the Y system project was initiated. The implementation was divided into several steps, as Vincent (IT staff at IC) explained:

We want to do it (Y system implementation) module by module. Robert (CEO) needed the sales and logistics, and so we just start from these two modules… We could develop the middleware to connect the X system and the Y system. [Interview September 2013]

In early 2014, Jane (CIO) was moved into the role of head of Supply Chain Management, just before the Y system configuration was completed and the start of the system initiation. She recalled:

I have moved into the SCM Department. It is hard for me involve into too much on the ERP system (to manage the system implementation at some other departments and branches), but I implemented the Y ERP system at my department. [Interview September 2015]

Based on the onsite observation, author has noticed that the ERP system has become part of the daily work and the staff at Omega has regarded the IT as a useful tool to improve work condition and solve the work problems.

4.2.5 Phase Five: Business Crisis – Late 2014 to Later 2016

In late 2014, for controlling the steel overproduction in China, the Chinese government took control of the steel production in every province and tightened bank credit for the whole steel industry. This caused immediate business recession at Omega where had reduced its steel production from 8 million tonnes to 5 million tonnes per annum. Key people also departed the company, and ‘new’ bank policy precipitated a financial crisis for Omega. All these external but profound business changes required the enterprise system application to be reconfigured. In January 2016, the SCM head Jane (prior CIO) resigned. The situation has been described by the CIO Wei as follows:

There was no one continually managing the Y system implementation and re-configurating the X system. As a result, the ERP system application in Omega was rolled back to where it was 10 years ago…. The system once again acted only as a booking machine to record business data. [interview September 2017]

Yanhua from Warehouse department said that: “Due to the large amount of mis-data in the system, we just working on the Warehouse Module, and the data from Purchase and Finance modules were different”. [interview September 2017].

During the time author was observing the system operation at Omega, he noticed that the ERP system had become very problematic, the data at among various modules were inconsistent, and the system operators had toconstantly manually amend the system data.

4.2.6 Phase Six: ‘New’ Business Owner – Late 2016 to Later 2018

For repaying its debt to the bank, Omega had to sell its steel remanufacture subsidiaries in Shenyang city in late of 2016. The upheaval continued and later Omega’s 80% share was sold to the local government to repay further debt to the bank. As the ‘new’ business owner was coming onboard and most of the high-level managers had been replaced, but substantial staff remained at their same positions in Omega. However, the local government was not able to solve Omega’s business crisis, and in early 2018 Omega was slated to close. The constantly changing and deteriorating business also required concomitant system changes. The situation has been described by Wei as the following:

After Jane left, no one could really coordinate the cross-department system reconfiguration. As the ‘new’ business owner came, all the senior managers have been replaced. The company was in chaos. The system was running in isolation at each department… We discussed to start a ‘Z’ ERP system project to replace the current system, but due to the financial difficulty and disagreement amount various departments, it had not been initiated. [interview in March 2018]

Moreover, according to the contract, the system data needed to be retained. The situation has been described by Min (the ‘new’ manager at SCMD) as the following:

The prior owner did not want to leave the company data to the new owner. Therefore, only the basic data (for recording the business assets, manufacture, and accounting) has been kept in the system (management data has been deleted from the system) and the system was full of mis-data. However, this is the only resources for the us to know what we have and to plan the future manufacture and sale, all the paperwork has been taken away. ... Even now we are relying on it to close and to pay for the resignations. [interview in March 2018]

Omega’s case study provides us a precious opportunity to investigate the role of absorptive capacity over a fifteen years’ time with full lifecycle of the system including implementation, use and close. The period started in 2004 when a “new” CEO, Robert joined Omega and initiated the ERP project, experienced a serial of turbulent phases, and ended as the company closed in 2018.

This longitudinal case study clearly illustrates how AC, system implementation and working practices are all co-constructed and co-evolved in a turbulent context. The context changes were largely unpredictable and led to both incessant internal and external change. There were changes acting as contextual triggers (CT) which led to a series of system implementations and changes in working practices. Table 1 summarizes the contextual trigger, absorptive capacity, system implementation and related working practice from 2004 to 2018 according to the six project phases from the above discussion.

Table 1 The contextual trigger, absorptive capacity, system implementation, and system related working practice in Omega enterprise system project
Full size table

Based on the above discussion and Table 1, Fig. 2 below depicts the dynamic interactions between contextual changes, absorptive capacity, the ERP system implementation and the related work practices.

Fig. 2
figure 2

The interacting processes of contextual trigger, absorptive capacity, system implementation and system related working practice in Omega

Full size image

In Fig. 2, the top grey rectangles demonstrate the various system related working practices, which highlight the penetration of the system into the fabric of Omega and also the major benefits of the enterprise system. The blue rectangle in the middle presents the transformative and shifting organisational absorptive capacity. The system implementation is shown as the series of orange rectangles in the bottom. Finally, the clouds in the bottom row illustrate the series of contextual triggers which caused the changes of system implementation and working practice. Their conditioning and enabling influences are indicated through by the arrows (the mapping for each ID can be found in Table 1). Overall Fig. 2 demonstrates how context change impacted the enterprise system implementation and its related working practice in Omega throughout fifteen years of concomitant ERP projects.

5 Discussion

5.1 The Role of AC in Enterprise System Project from a Longitudinal Perspective

Combining the findings from the Omega case study and results in literature, this subsection argues that AC constantly transforms throughout the enterprise system project lifecycle. Changes of system implementation and working practice have direct impact on this transformation. From the longitudinal perspective, the Absorptive Capacity (AC), the enterprise system implementation, and the related working practice are constantly co-evolving. In addition, context changes act as triggers that impact both system implementation and working practice, and how AC itself transforms. In this section, we look at each of these three perspectives in details.

The Transforming Nature of AC

The processes of enterprise system implementation and use in complex organization are not linear in sequenced phases, but they are concurrent and overlap. This has been identified as the endless process of revisions and enhancements (Markus et al., 2000) where each process encompasses different degrees of knowledge exploration and exploitation (Marabelli & Newell, 2019). As a result, the various dimensions of AC are constantly changing through the enterprise project lifecycle. Importantly, this change cannot be depicted or construed as one continuous smooth function, but rather it transpires as a collection of ‘step changes’ that fluctuate up and/or down when viewed from a longitudinal perspective. In certain periods of time, it is increasing dramatically, other times it is remaining the same or even decreasing.

As we documented, Omega started the enterprise system project with almost ‘zero’ pre-related system knowledge, as the IT manager did not even know what the acronym “ERP” stands for. Throughout the system installation, and in five years of operation, knowledge was gradually acquired and assimilated into the body of the organization propagating from the Information Centre (IC) to other business units including manufacturing units and Supply Chain Management Department (SCMD). The system related management knowledge was concurrently assimilated and exploited from external consultants to internal managers to support the business management, decision making and even business auditing. After the X ERP system, knowledge penetrated the full body of Omega, the management team exploited the ‘new’ system requirements and started to acquire knowledge for the next generation ERP system (Y ERP system). However due to subsequent business restriction, this Y ERP knowledge was assimilated and transformed only into the SCMD. The subsequent restrictions earlier described led to Omega’s AC to go in reverse and constantly drop. Omega lost capacity to exploit the X ERP knowledge for adjusting to contextual changes, and let alone to future explore and exploit the Y ERP knowledge outside of SCMD. In the following five years, as the key knowledge shareholders constantly left and the business structure dramatically changed, the AC was further reduced; finally, as the business closed, the AC was essentially ‘zero’.

It is well accepted that technologies can encourage knowledge management and learning in organization (Iyengar et al., 2015), such as by implementing knowledge management systems (Kuo & Lee, 2009; Lee et al., 2007; Wang et al., 2007) and enterprise system (Acar et al., 2017; Chadhar & Daneshgar, 2018). ERP project-related AC development is critical, as organisations learn through its members whose commitment is imperative (Cohen & Levinthal, 1990a; Hamilton et al., 2016). This is particularly true in the long term as the enterprise system is bound to change (Mustonen-Ollila & Lyytinen, 2004; Newman & Sabherwal, 1996). This study has clearly shown that AC, as a dynamic capability, transforms throughout the entire project life cycle at different speeds. The change can be in both directions, either increasing or decreasing, and is directly impacted by transformations of the system and related working practices.

Co-evolving Process of System Implementation, Working Practice and AC

In an enterprise system project, AC plays a mediator role for conditioning the interactions between system implementation and its related working practice (Upstill-Goddard et al., 2016; Zou et al., 2016). In an enterprise system project, the system implementation and the related working practice encompass and enhance the AC simultaneously (Liu et al., 2013; Marabelli & Newell, 2019). The system implementation, working practice and AC support and impact each other.

In the Omega case study, its initial ‘Big Bang’ ERP installation started with almost ‘zero’ AC, as the IT manager said, ‘I even do not know what ERP stands for’. After 5 months of implementation, the first system installation failed and missed its slated operation date. In the second system installation, the system operation knowledge was assimilated into the IC. In this implementation the related departments provided their daily data by paper to the IC for manual data entry into the system. Through the subsequent two years of system operation at IC, the ERP knowledge was assimilated and transformed to all IT staff. The system knowledge was further assimilated into the business department as IT staff were assigned into different business departments to support system operation, and the system replaced all paperwork. The system became a management tool for auditing, decision making and business automation. As the business developed with the new ERP system, new system requirements were pursued. Y ERP system project was initiated, and new ERP knowledge was acquired and assimilated into the SCMD. In the following 5 years, the changed market conditions caused some of the system ‘gate keepers’ and ‘boundary spanners’ to leave the company, business owner changed, IT support became lacking and system breakdowns became more frequent. Not surprisingly, the AC dropped. Finally, the company closed, and the system was decommissioned.

From the longitudinal perspective, Omega case study clearly shows how AC, system implementation and the related working practice are co-constructing and co-evolving over time. There is a strong interplay between both. Changes in one impacts the other. Changes in the system for example requires support and this impacts the absorption processes of all involved. The clear lesson is that for an enterprise system project, we should consider this co-construct and co-evolution process to harness the system advantages in the shortest period possible to absorb the continuous inevitable changes.

The Role of Change

Change is the nature of any business and one of the most threatening aspects in enterprise system implementation and use (Altamony et al., 2016; Lichtenthaler, 2009). AC is a context sensitive phenomenon responsive to change and change directly or indirectly impacts related system implementation and work practice (Marabelli & Newell, 2019). Therefore, to understand the dynamics among the AC, working practice and enterprise system implementation and use, we cannot avoid the impact of contextual changes in our modelling.

In 15 years, Omega ERP project experienced a series of predictable, unpredictable, internal and external contextual changes. All acted as triggers leading to the changes in system implementation and working practices in different ways and degrees. In 2003 the popularity of the ERP system and ‘new’ general manager initiated the ERP system. As the system knowledge penetrated into the staff mindset through the system use, the system implementation and the related working practices were changed accordingly. The changes on the international market of raw material supply, business structure and ERP system upgrade all acted together to instigate the initiation of the Y ERP system project. The change on financial market and product market led to the Y system project failure and downscale of the business. Accompanying the ‘new’ business ownership and company closing, effectively took the system use back 15 years to the very starting point. Throughout the 15 years of its lifetime, some changes had positive impact on the development of AC and provided the organisation with competitive advantages. Others clearly had a negative impact on AC and decreased the organisation’s performance. It is important to note from this case study that triggers do not act in isolation. Rather, they often work together to cause changes on system implementation and working practices.

It is worth mentioning here that the ability to absorb new knowledge from external resources can provide significant benefits (Ferreras-Méndez et al., 2015). Such as, when an organisation’s AC is increased, the organisation’s goal will shift from measuring performances to observing emerging market opportunities and threats (Cohen & Levinthal, 1990b). This, in turn, could read in the future to forming appropriate responses to relevant opportunities and threats for the co-evolution of AC, enterprise system implementation and working practice.

Advantages and Lessons from the Longitudinal View

In this case study, we conducted three phases of data collection. Initially, this was simply a pragmatic decision due to the researcher’s dynamic link to the company itself and their own insights about the inner working of the company. However, their own AC awareness also evolved during the study. These two dynamic factors, the link with the company and the stages in AC awareness and how they impacted each period of the data collection are shown in Table 2. Indeed, these two factors and particularly the evolution of AC awareness in context, highlight the need for longitudinal data collection to expose any bias and uncover the long-term trends in AC in general.

Table 2 Research Method Evolution
Full size table

As the research method evolved during the long study, and this had a decisive impact of the data collection activities and focus, it is also important to delineate the lessons learnt along the boundaries where the shift occurred. Indeed, the different nature of the lessons also suggest different theoretical contributions for each phase. Hence, the findings are demonstrated and summarised in Table 3. Phase 1 illustrated the importance of matching system implementation and usage to the prevailing organisational AC. Phase 2 illustrated the tight coupling between AC and enterprise system practices. It illustrated their co-evolution process. Finally, phase 3 highlighted the impact of external factors and contextual change on the evolution of AC. Lessons and theoretical contributions of each phase are further detailed in Table 3.

Table 3 The findings from the longitudinal view
Full size table

This longitudinal study provides us with a richer picture about the dynamic aspects of absorptive capacity. This is compelling evidence for the value of adopting a longitudinal view to investigate the ERP implementation and use in organizations. The study involves a standard longitudinal data collection for 5 years. For practical reasons retrospective data on both sides of this five years period enables us to further expand the length and the scope of the study. This method illustrates how studies spanning multi decades can be possible for IS studies. The fifteen years of the study describes the full lifecycle of the ERP project, from start to boom and then decommissioning. A notable lesson from this longitudinal study is that short term failures can be viewed as part of an overall adaptation process where the organisational absorptive capacity catches up with organizational goals. However if the organization persists with a project, with deeper awareness of its own absorptive capacity and how it evolves, the project will eventually bring the intended benefits to users.

5.2 The Mediator Role of AC in Enterprise System Implementation and Use

Drawing on the substantive model of the Omega enterprise system process and the above findings, a generalized model is presented in this section. The model adopts the social constructive perspective, which explains the technology appropriation results from the constitution of human users, social histories and organizations (Orlikowski, 2010). Figure 3 shows the intermediate role of AC in enterprise system implementation and use in a dynamic context.

Fig. 3
figure 3

The intermediating role of AC in enterprise system implementation and use under the dynamic context

Full size image

According to Omidvar et al. (2017), the changes on antecedents (pre-condition) enable the development of AC. These changes have been identified and extended from internal prior knowledge, working practice and system structure (Marabelli & Newell, 2019; Martinkenaite & Breunig, 2016), to external marketing, technology, and supply chain (Golgeci & Kuivalainen, 2020; Omidvar et al., 2017; Saad et al., 2017). Through this longitudinal study, these changes are further defined as activation triggers from internal and external organizations in predictable or unpredictable ways. These triggers are interconnecting and overlapping to enable the change of system implementation and working practice in the different ways.

The changes on system implementation practice enabled the related working practices, but conditioned by AC. A feedback loop exists in that the changing system related working practices also facilitate and enable the following system implementation (again conditioned by AC). However, the AC is not only a conditioning agent, but itself is also liable for change and transformation in the process. The system implementation transforms it as new knowledge is acquired and assimilated into the adopting organization and the working practice too develops the AC. ERP systems must present knowledge easily and effectively for understanding and appropriate assimilation for all users (Lee et al. 2007). However, the effectiveness of ERP systems for all users to absorb its knowledge relies on a culture that develops and shares knowledge which requires developing trust in technology and in people (Kayas et al., 2008). Importantly, the enabling, conditioning and transformation processes are not linear. They also overlap.

As competition demands organizations to leverage knowledge, the need for knowledge increases (García-Morales et al., 2007). For organizations which are effective at managing knowledge, their ability to innovate also improves for gaining a strategic competitive advantage, and organizations which outsource their systems give away their control because the outsourcing provider operations may not be aligned with their own (Iyengar et al., 2015). Knowledge management and its transfer require organizations to provide a full commitment from the start in order to succeed (Iyengar et al., 2015; Saad et al., 2017). Even if organizations are entirely committed to knowledge management, knowledge transfer barriers can still exist, such as, causal ambiguity, and recipient's AC (Szulanski, 1996). The AC is dynamic and not static (Zahra & George, 2002b). A dynamic capability gains an advantage when its dimensions gain resources and competencies (Teece et al., 1997). This means that AC can change over time depending on other factors.

6 Conclusion and Limitations

The prevalent theme in the IS Management and innovation literature is that firms rely on their absorptive capacity (AC) to acquire new external knowledge to gain competitive advantage. Scholars have examined AC from the process and construct perspectives (Lane et al., 2006; Orlikowski, 2010; Roberts et al., 2012). Their chief aim has been to deepen understanding about how firms synthesize knowledge from external sources into improved performance. However, extant studies have been silent about the dynamic nature of AC and its evolution. This is the gap that this paper targets. The present study can also be seen as a contribution to the analyses of the construct view of AC initiated by Zahra and George (2002a). Different studies have contributed to the construct study with various results, either providing additional layers or elements, or narrowing down on feedback paths (Mariano & Walter, 2015). The ambiguity in these results is caused by the context sensitivity of AC or the varying methodologies adopted. Our approach to reduce the ambiguity is to investigate the high-level construct of AC rather than the internal and underlying processes of the construct.

This study regards the AC as one process and uncovers its construct with due consideration of its situated context and long-term development. As a result, we develop a model that combines AC, system implementation and related working practice under a social context. The fifteen years’ case study uncovered dynamic interactions between AC, system implementation and related working practice under the changing context. From this longitudinal perspective the benefit of ERP system adaptation emanates from the co-construction and co-evolution of the system implementation, AC and the system related working practices. In this co-construct/ co-evolving process, the AC plays a mediator role, as it conditions the interaction between the system implementation and the related working practice. The state of AC is one critical factor whether or not the ERP system use in an organization meets the business demands. At the same time, the ERP system implementation practice and the working practice are other important factors that also transform the AC itself. This transformation allows the AC to condition the interaction between the ERP system practice and working practice in a dynamic manner. Furthermore, the observed effects of ERP system contextual changes provide somewhat surprising results. Although previous study about AC uncovered its context sensitive characteristics, the context change could trigger the AC to percolate new knowledge into system implementation and use (Todorova & Durisin, 2007; Volberda et al., 2010). Our results further this finding and suggests that the ERP project contextual change acts as the action trigger which leads to the change on both system implementation and working practice, which drives the co-construct and co-evolving process. Moreover, this study also shows the value of adopting the lengthy long-term view on IS, as short-term failure is only part of the adaptation process and consistent work will eventually bring the intended benefits to the organization.

From a practical perspective our study suggests that to deploy an enterprise system and pursue its benefits, firms should develop the AC and account for its inevitable evolution. It is important to account for the AC context. Managers should bear in mind that trying to acquire external knowledge without considering the existing AC may lead to project failure and even decrease the firm’s performance. In an enterprise system project, the AC, system implementation and related working practice are co-construct and co-evolving over time. It is essential for an adopting organization to maintain the harmony among them to reduce the project risk. The success in one period of time cannot guarantee the future success. AC is transforming all the time and can be developed through ‘learning by doing’, adding external resources and distributing related knowledge. AC can be decreased as key knowledge stakeholders are lost or through changing working practice. This co-construct and co-evolving process is context sensitive and contextual changes could act as change triggers. Contextual triggers can be internal, external, predictable, or unpredictable. A change monitoring process by key project stakeholders is required to maintain AC. The enterprise system adopting organization should focus on maintaining and developing AC with a long-term view.

This study has some inherent limitations that also suggest future research possibilities. First, the data were gathered at only one firm in the longitudinal study. A broader survey from various firms and industries may provide further insight into the structure of the model, adding perhaps more details of the factors and relationships amongst them. Second, the research focus is on the high-level constructs amongst the AC, system use and related working practice. More elaborate study into finer elements of those constructs is likely to add further value for applying the model in real word applications.