A mandatory ERP system; the differences between users’ expectations and experiences A qualitative case study
Lydia van den Berg S3445895 14 April 2020
University of Groningen Supervisor: dr. J.F.J. Vos Co-assessor: prof. dr. A. Boonstra Faculty of Economics & Business
2
Abstract
Purpose – If a system is mandatory, users’ satisfaction is a better predicter of adoption than the traditional adoption. Therefore, this research explored a part of the adoption process by using Expectation-Disconfirmation Theory (EDT), which explained users’ satisfaction as the difference between the experiences and expectations. So, the purpose of this research is to investigate how and why the users’ experiences of a mandatory Enterprise Resource Planning (ERP) system in the post-implementation phase differs from their expectations in the pre-post-implementation phase.
Methods – For this research, a qualitative case study was performed in an organization where a mandatory ERP system was being implemented. In order to compare users’ expectations with their experiences, ten employees were interviewed twice: in the pre-implementation phase and the post-implementation phase. This gave insights in the differences and the contextual factor that influenced the differences. Basing the comparison on disconfirmation (difference between expectation and experience) enabled to distinguish contextual factors that impacts the similarities or differences between the users’ expectations and experiences. In this research, users’ disconfirmation has been investigated on two aspects: the systems’ capabilities and the systems’ value.
Findings - Users’ experiences of the systems’ capabilities differed from their expectations more often than those of the systems’ value. The disconfirmation of systems’ value either was simple or negative; mostly simple. The users’ disconfirmation of systems’ capabilities was approximately evenly
distributed. The users’ disconfirmation of systems’ capabilities seemed to be influenced by expectations of capabilities, setbacks during the implementation and self-sustainability. The users’ disconfirmation of systems’ value seemed to be influenced by satisfaction with the old system,
expectations of capabilities, trust in the implementation, timing, feeling of support and setbacks during the implementation
Conclusion – The users’ expectations and experiences of the systems’ capabilities differed more often than those of the systems’ value. The difference is caused by various contextual factors.
3
Table of content
Abstract ... 2
Introduction ... 5
Literature Review ... 7
Implementing an ERP system ... 7
Users’ adoption in mandatory contexts ... 8
Expectation-Disconfirmation Theory (EDT) ... 9
Adding components 'capabilities’ and ‘value’ to EDT ... 9
Expectations in the pre-implementation phase. ... 10
Experiences in the post-implementation phase. ... 11
Disconfirmation and satisfaction. ... 11
Contextual factors ... 12
Limitations of EDT ... 12
Methods ... 14
Research approach and empirical setting ... 14
Data collection ... 14
Data analysis... 16
Results ... 18
Within embedded case analysis ... 18
Cross embedded case analysis ... 23
Discussion ... 28
Key concepts ... 28
Disconfirmation ... 29
Contextual factors disconfirmation of capabilities and value... 29
Contextual factors disconfirmation of capabilities. ... 30
Contextual factors disconfirmation of value. ... 30
Limitations ... 30
Recommendations for future research ... 32
4
References ... 35
Appendix A - Questions first interview ... 40
Appendix B - Questions second interviews ... 42
5
Introduction
A successful ERP-implementation is crucial for an organization; problems during the implementation can lead to an enormous failure. A striking and recent example of this is Pluripharm in Alkmaar, one of the largest suppliers of pharmacies and hospitals in the Netherlands, who faced inventory issues as a result of problems during the ERP-implementation. Around 80 pharmacies in the Netherlands switched to another supplier, which forced Pluripharm to let go 180 of their 480 employees (Leupen, 2019). Pluripharm is not the only firm who experienced struggles during the implementation of an ERP system. In 2012, Bloch, Blumberg and Laartz conducted a research by University of Oxford and McKinsey on more than 5000 IT projects. They found that 50% of the projects with budgets above the 15 million dollars were on average 45% over their budget, delivered 56% less value than expected and were 7% behind schedule. Moreover, 17% of the projects developed so badly that they threatened the existence of the business.
This example of Pluripharm and the disturbing statistics point out that it is crucial to create a broad landscape of knowledge about implementing ERP systems, in order to maximize the change of a successful implementation. Various researchers emphasized the significant role of the user in the success or failure of an ERP implementation. Chang et al. (2008) even claim that the usage and therefore success of an ERP system depends most significantly on the users. The systems’ user has a crucial role, because their behaviour can support the implementation by being adaptive, or they can counteract the implementation by being resistant (Garg & Garg, 2013). The behaviour of persons that are resistance to organizational change, has a significant impact on the effectiveness of the change (2013). The users’ behaviour is caused by their adoption of the system (Abdinnour & Saeed, 2015; Ajzen, 1991; Badewi, 2016; Bargh, Chen, & Burrows, 1996; Breckler, 1984; Garg & Garg, 2013). In the ERP literature, adoption is often conceptualized as the users’ acceptance of the ERP system in the final stage (Haddara & Zach, 2012). In this research, the user is considered to be an employee of the company, which has to perform tasks in the system.
6 However, the traditional adoption models such as technological acceptance model (TAM; Davis, Bagozzi, & Warshaw, 1989), the theory of planned behaviour (TPB; Ajzen, 1991) and the diffusion of innovation theory (DoI; Rogers, 1995), which will be explained in the literature review, are not originally built for mandatory technologies, which an ERP system often is (Hwang et al., 2016). The models assume that the use of a technology is a free choice of the (potential) users. Since users’ satisfaction of a technology is a more suitable predictor of users’ adoption in a mandatory environment (Delone & Mclean, 1992), Expectation-Disconfirmation Theory (EDT) was used for this research. EDT explains satisfaction by disconfirmation, which is the difference between expectations and experiences. Satisfaction of users is defined as an emotion-based response to an IS. It represents the users’ emotional state, affective attitude or feelings about the system over time (Bhattacherjee & Premkumar, 2004; Doll & Torkzadeh, 1988).
Although EDT is acknowledged in IT literature (such as e-health), there is to the best of my knowledge no research related to ERP systems. Furthermore, researchers rarely investigate expectations and experiences separately, but only examine the disconfirmation afterwards. Investigating the expectations and experiences separately is important to examine the indirect effects too (Lankton & McKnight, 2012; Venkatesh & Goyal, 2010). Furthermore, it provides insight in the users’ feelings about the system by time order, since the expectations are before and the experiences after the implementation (Lankton & McKnight, 2012). This research delved into adoption, using EDT, and compare users’ expectations of the system with their experiences. Thereby, it filled the described gaps by investigating the expectations and experiences separately, in a case with a mandatory ERP system.
In order to examine the process of satisfaction as predictor of adoption of mandatory systems, the aim of this research is to answer the question:
“How and why does users' experiences of a mandatory ERP system in the post-implementation phase, differ from their expectations in the pre-post-implementation phase?”
I answered this question through a qualitative case study. I found the company Tech as an appropriate company to perform this case study, I described the reason more deeply in the Methods section. The results of this study provided new insights in how and why the users’ expectations and experiences differ, and disconfirmation occurs. Since ERP systems are used for all kinds of
7
Literature Review
Implementing an ERP system
An ERP system is defined as “comprehensive packaged software solution, which seeks to integrate the complete range of business processes and functions in order to present a holistic view of the business from a single information and IT architecture” (Klaus, Roseman & Gable, 2000, p.141). Davenport (1998) explains that ERP systems comprise software modules, which allow companies to integrate and automate most business functions by sharing and accessing common data, information and practices. ERP systems are designed to facilitate the information flow. The most characteristic features of an ERP system are that various organizational functions are integrated, which allows the organization to enter information only once, and that the information is available across the
organization with real-time updates (Davenport, 1998).
The implementation of an ERP system is, compared to other IT projects, related to radical organizational change (Bingi, Sharma & Godla, 1999). It is not only about a system development; it is also about the redesign of processes and structure, managing a complex environment and dealing with questions and difficulties of employees. An ERP implementation places enormous stress on the business resources and time and changes the way the business is managed (Badewi, 2016; Davenport, 1998; Kumar, Maheshwari & Kumar, 2003). ERP systems and various enterprise systems such as cloud computing, big data and basic office application systems, are the main technologies in mandated environment (Hwang et al., 2016). A mandated use environment is explained as one “in which users are required to use a specific technology or system in order to keep and perform their jobs” (Brown, Massey, Montoya-Weiss & Burkman; p. 283).
The increasing usage of ERP systems, their large impact on the organization and the fact that most ERP implementation projects fail to achieve their objectives (Chakraborty and Sharma, 2007), have drawn the attention of scholars. The users’ adoption of ERP systems, which is considered to be a key to the success of the system, received much attention (Hwang et al., 2016). One of the most difficult tasks for management during the implementation, is creating positive attitudes of the users towards the adoption (Hwang et al., 2016). The support of the users is even considered to be more important for an effective implementation than the support of the top management (Maditinos, Chatzoudes & Tsairidis, 2011). When the users of an ERP system do not support the innovation and are resistance, it is a major barrier to reap the benefits of the system (Garg & Garg, 2013). Therefore, it is crucial to gain insight in the user’s adoption decisions.
8 preparing for the new system; in the post-implementation phase, the system is introduced, the
organization is managing the change and the employees started using the system (Bertram, Fixsen and Blase, 2015).
Users’ adoption in mandatory contexts
Users’ adoption is a key to the success of an ERP system (Hwang et al., 2016). In the ERP literature, adoption is often conceptualized as the users’ acceptance of the ERP system in the final stage (Haddara & Zach, 2012). Traditional models that are often used in the adoption research, are the technological acceptance model (TAM; Davis, Bagozzi, & Warshaw, 1989), the theory of planned behaviour (TPB; Ajzen, 1991) and the diffusion of innovation theory (DoI; Rogers, 1995; Lai, 2017; Leung & Chen, 2019; Taherdoost, 2018). TAM predicts the users’ acceptance and use of a technology by three main factors: perceived ease of use, perceived usefulness, and attitude towards use Davis (1989). TPB, developed by Ajzen (1991), predicts behaviour across many settings and can be applied to IS use. The DOI model explains how an innovation is getting spread (adopted) through members of a social system over time by combining three components: the characteristics of the adopter and the innovation, and the innovation decision process (Rogers, 1995). It can be applied at multiple levels: individual, organizational or global (Taherdoost, 2018).
The problem with using these traditional models to investigate ERP adoption, is that the models were originally built and tested for technologies that were not mandated in nature, while ERP systems are mostly mandated for users (Hwang et al., 2016). The traditional models do not sufficiently explain and predict use and adoption of mandatory technologies since the intention to use, frequency of use and time of use is mainly determined beyond the user; for example by the manager (Brown et al., 2002; Hsieh, Rai, Petter, & Zhang, 2012; Hwang et al., 2016; Gallivan, 2001). The traditional models neglect the complexities of the situations in which the choice to use a system is made at higher levels of the organization and thereby is beyond the user(Hwang et al., 2016).
However, the fact that users of a mandatory system will have no choice than use it, does not mean that they adopt the system. In these situations, users attitudes can be contrary to their behaviour; they can have a negative attitude towards adopting the system, but still use it because they are told to and do not risk their job (Brown et al., 2002; Hwang et al., 2016). If users are dissatisfied about the mandated use, the consequences can be counterproductive; it can frustrate the employees, comprise their work and in the end impact the customer – for example by the decreased service quality – negatively (Hsieh et al., 2012). Other potential consequences of users’ negative attitudes of the mandated system are declined job satisfaction, reduced performance, destructive behaviours (behaviours that might put off
9 users’ satisfaction is suggested a better predictor(Hsieh et al., 2012; Delone & Mclean, 1992). The users’ satisfaction captures the users’ mental adoption of the system and the behavioural consequences (Wang, Hsieh, Butler, & Hsu, 2008). Satisfaction of users is defined as an emotion-based response to an IS. It represents the users’ emotional state, affective attitude or feelings about the system over time (Bhattacherjee & Premkumar, 2004; Doll & Torkzadeh, 1988); it is a subjective evaluation of the systems’ pleasurable level of fulfilment (Leung & Chen, 2019; Oliver, 1996). Leung and Chen (2019) distinguished another possibility of examining the users’ satisfaction; they say that it is a critical factor that influences the user’s continuance intention of using the system (Leung & Chen, 2019).
Expectation-Disconfirmation Theory (EDT)
A theory that allows to explain the users’ satisfaction and thereby measure the adoption in case of a mandatory technology, is the Expectation-Disconfirmation Theory (EDT). In the IS context, EDT explains how the users’ satisfaction of a system is created as they form initial expectations, use and experience the system, and compare their experience against their initial expectations. Since 1993, EDT was introduced in the information systems adoption research to explain users’ satisfaction and to explain why and how the reactions of users change over time (Bhattacherjee & Premkumar, 2004; Lankton & McKnight, 2012; Szajna & Scamell, 1993; Venkatesh & Goyal, 2010). However, the theory is compared to other adoption models overlooked and not often used by researchers in the field of IS adoption(Lankton & McKnight, 2012). EDT has its origin in the consumer behaviour research and marketing (Oliver, 1977; Oliver, 1980; Oliver and DeSarbo 1988). Over the years, it has been applied in many other fields, such as leisure behaviour (Madrigal, 1995), human resources (Korman, Wittig-Berman, & Lang, 1981) psychology (Phillips and Baumgartner, 2002) medicine (Joyce & Piper, 1998) and service quality (Kettinger & Lee, 2005).
Adding components 'capabilities’ and ‘value’ to EDT
In order to make the field in which users have expectations and experiences more specific,
components which are derived from the perception literature can be added to EDT. The components were used by Abdinnour and Saeed (2015), who also considered expectations and experiences of ERP system users in their research. They compared the user’s perception in the post-implementation phase with the perception in the pre-implementation phase. They both conceptualized perception by four components; acceptance, capability, timing and value. Acceptance is defined as the user’s attitude towards the new system; capabilities are defined as the functionalities of the new system; the timing is defined as the appropriateness of the speed of the implementation, and value is defined as the overall benefit of the new system (Abdinnour & Saeed, 2015). These components were derived from
10 The comparison of Abdinnour and Saeed (2015) between the expectations and experiences shows that users’ perception towards an ERP system change over time. Although these authors
performed research for perception literature, the components can also be applied to EDT – and thereby adoption literature –, since users’ expectations and experiences arise from their perception. The components ‘capabilities’ and ‘value’ are added to the model in order to specify the field in which users have expectations and experiences. The components ‘acceptance’ and ‘timing’ are considered to be contextual factors, since these are no characteristics of an ERP system and therefore not a relevant component of satisfaction (directly), but rather a situational characteristic.
The point of view for this research is based on EDT of Oliver (1977) and is shown in Figure 1. The components of the model are explained in the next subheadings. The components of the model that are circled by a dotted line, are part of this research. The other components are a clarification of how this research is part of the adoption literature.
Expectations in the pre-implementation phase.
The expectations are for EDT defined as the users’ set of beliefs about the performance of the system, before they used it (Olson and Dover 1979). So, in the context of an ERP-implementation; these expectations are formed in the pre-implementation phase. The pre-implementation phase is a critical period that precedes the introduction of the new ERP system. The fact that the activities and the chosen implementation strategy have a direct impact on the implementation process and outcome, is what makes this period critical. There is – despite the pre-built software and in-built business process function supplied by ERP – no industry standard ERP implementation strategy (Ali & Miller, 2017). The pre-implementation phase involves activities such as planning the system’s introduction, providing training and deciding the implementation strategy (Abdinnour et al., 2003).
11 Experiences in the post-implementation phase.
The experience is the set of beliefs about how the system performed during or after the usage (Cadotte, Woodruff, & Jenkins, 1987). So, in the context of an ERP-implementation; these
experiences take place in the post-implementation phase. In the EDT literature, the terms ‘experience’ and ‘performance’ are used interchangeably, since users experience the performance of the system (Lankton & McKnight, 2012). Users’ experiences with the system can differ or can be equal to their expectations, which they formed in the pre-implementation phase. The post-implementation phase is the period after the introduction of the system, in which the system is tested, checked, assessed and evaluated (Nah, Lau, & Kuang, 2001). In the initial period after the introduction of an ERP system, most businesses experience negative sentiments from users (Ross & Vitale, 2000). After the
implementation, realignment about various issues is needed often; what to do with the legacy system, how to integrate the ERP system, how to revise business processes. This necessary realignment has a significant share in many implementation failures (Soh, Kien, & Yap, 2000).
Disconfirmation and satisfaction.
Disconfirmation is the users’ subjective comparison that can result in the thought that the performance was worse, the same or better than expected, so it shows the difference between the expectations and the actual experiences (Oliver, 1980). An experience which is better than the expectations, leads to a positive disconfirmation. If the experience is equal to the expectation, there is a simple confirmation. An experience which is worse than the expectation leads to a negative
disconfirmation (Oliver et al. 1994; Olson and Dover 1979). According to EDT, the expectations, experiences and disconfirmation all can affect satisfaction (Lankton & McKnight, 2012). Because of the added components ‘value’ and ‘capabilities’ of Abdinnour and Saeed (2015) to the EDT, the possible disconfirmations for this research are on those aspects. So, users’ experiences of systems’ value are better, equal or worse compared to their expectations, which lead to positive disconfirmation of value, simple confirmation of value and negative disconfirmation of value. Also, their experiences of systems’ capabilities are better, equal or worse compared to their expectations, which lead to positive disconfirmation of capabilities, simple confirmation of capabilities and negative disconfirmation of capabilities.
12 Although researchers adopted the EDT model to explain the satisfaction and thereby adoption of IS users, they rarely investigate expectations and experiences separately, but only examine the
disconfirmation afterwards. This is because of the difficulty to examine the expectations in time 1 and experiences and disconfirmation in time 2, during a longitudinal study (Lankton & McKnight, 2012). Only measuring the disconfirmation, instead of measuring the expectations and experiences separately, is in the EDT theory known as direct measurement of confirmation. Investigating the expectations and experiences separately is important to examine the indirect effects too (Lankton & McKnight, 2012; Venkatesh & Goyal, 2010). Furthermore, it provides insight in the users’ feelings about the system by time order, since the expectations are before and the experiences after the implementation (Lankton & McKnight, 2012).
Contextual factors
Both the expectations as the experiences are influenced by contextual factors, which can be many (Somers and Nelson, 2001; Sternad Gradisar & Bobek, 2011). By applying EDT to an ERP implementation, contextual factors can be defined as the characteristics of implicit and explicit circumstances or situations in which the implementation takes place (Dey, 2001). A contextual factor can be the user’s attitude towards the system, or the speed of which the implementation process is going (these are the components ‘acceptance’ and ‘timing’ from Abdinnour and Saeed, 2015; as described earlier in this chapter). Other examples of contextual factors from the literature that influence how users think about a technology, are top management support, co-operation,
technological complexity (Bueno & Salmerón, 2008), readiness for change (Shivers & Charles, 2006) external factors such as social influences or computer experience (Sternad et al., 2011) and uncertainty avoidance, satisfaction and involvement of users (Alhirz and Sajeev, 2015).
Limitations of EDT
A potential limitation of using EDT in information systems adoption literature, is that EDT has a psychological nature(Spreng, MacKenzie, & Olshavsky, 1996). The expectations and experiences of users can be influenced by various psychological factors (i.e. low self-esteem). It is possible that information systems adoption researchers, who do not have expertise in psychological field, are only able to measure the ‘hard’ and factual factors that influence the users’ expectations and experiences. Another potential limitation of EDT is its assumption that the expectations, experiences and
disconfirmation proceed in that order. Some authors suggest that users may form expectations while they are experiencing the system (Grimmelikhuijsen& Porumbescu, 2017).
14
Methods
Research approach and empirical setting
In order to explore how and why users’ expectations and experiences of a mandatory ERP system differ, theory development in this study was needed. This could be appropriately done through a qualitative case study (Eisenhardt, 1989; Van Aken, Berends, & Van der Bij, 2012). The qualitative case study was performed at the company Tech, which is located in the Netherlands. Tech is a
pseudonym for the real name of the organization, which is because of their anonymity not used in this report. It is a family company that has grown a lot over the years; at the moment, the organization has 70 employees. It is a technology company; they sell their machines and robots over dozens of
countries. The employees of Tech have been working with Microsoft Dynamics NAV – hereafter called ‘old’ or ‘current’ system – for several years. However, excessive customization of this system and the growth of the organization created the need for a new ERP system, Microsoft Business
Central. The implementation of the ERP system affected the organization as a whole; all employees, in varying degrees, were mandated to work with the ERP system.
One member of the management team – hereafter called the change initiator – came with the idea to implement a new system. He found support with the other management team members; they agreed and helped to make a rough plan with a big-bang approach. However, the upcoming
implementation was considered to be the project of the change initiator. The organization hired a freelance ERP-consultant in February 2019, who would help them to map the processes, choose a suitable ERP system and transfer knowledge about the system. The plan was to start with the system in September 2019; in case of an ordered product, they would start the process in both systems in order to test the new system. However, the project was delayed; only in December 2019, the first persons started to do their daily work in the system. On the first working day of January 2020, the whole organization transferred to the new system.
The change in this organization provided a suitable case because during this research, the organization was going through two different implementation phases of a mandatory ERP system. This gave the opportunity to measure the users’ expectations in the pre-implementation phase and measure the users’ experiences in the post-implementation phase. Therefore, I was able to compare users’ expectations with their experiences, consider the differences between them and investigate the contextual factors that influenced the differences.
Data collection
15 which was taken in the pre-implementation phase, took place in December 2019. In this phase, the organization and future users were preparing for the new system. The second set of interviews, which was taken in the post-implementation phase, took place in January 2020. It was a few weeks after the ‘big bang’, the organization was managing the change and users were trying to find their way through the system. Both set of interviews were taped. The date of the interviews and their length in minutes is shown in Table 1. The interview questions were semi-structured, which enabled to compare the answers of the respondents, but also provided space to ask appropriate follow-up questions, and be adaptive on the situation. The interview protocol of the pre-implementation phase is added in Appendix A, the interview protocol of the post-implementation phase is added in Appendix B. In order to maintain the anonymity of the respondents’, their function or role in the implementation process was not exposed. Some of the respondents worked closely together; they are located in the same department and communicate, collaborate and cooperate with each other. This is shown in the second column of table 1.
16 Table 1 Duration interviews
The respondents were also observed passively between the first and second set of interviews; during the implementation. This means that I was not part of the conversations, but just sat behind them; silently keeping an eye on the respondents. During the observations, I paid attention to the situation where the respondents were in, and the events that occurred during the implementation. An example of an event is that the data of the old system was not properly transferred to the new system. The observed situation, events and the respondent’s response on events, gave starting points for the second set of interviews.
Data analysis
All interviews were done in the mother tongue of the respondents: Dutch. The recordings of the conducted interviews were transcribed literally. Therefore, the language of these transcripts is Dutch. The coding process started with a set of deductive codes. Examples of these codes were
‘experiences with systems' capabilities’ and ‘feeling of involvement’. During the coding process, some inductive codes arose. An example of an inductive code is ‘trust in implementation’ and
‘self-sustainability with the system’. Appendix C contains a codebook, in which each code was provided with a description and sample quotes of the respondents.
17 disconfirmation and contextual factors were for each respondent summarized in tables. The
comparison of their expectations of and experiences with the system and direct statements of themselves in the post-implementation phase (“the functionalities were better than expected), made disconfirmation visible. The disconfirmations of value and capabilities that showed up, was the answer of the ‘how’ part of the research question.
18
Results
This chapter contains the findings of this research. It starts with a within case analysis, which consist of a general insight in the disconfirmation of capability and value in the implementation phases, an insight in the contextual factors and examples of respondents with different disconfirmations. After that, a within case analysis is described and a cross-case analysis in the section after that.
Within embedded case analysis
In the pre-implementation phase, 50% of the respondents was positive about the new systems’ capabilities, 30% had mixed feelings and 20% was negative about it. In the post-implementation phase, 40% was positive and 60% had mixed feelings. Of all respondents, 40% had a positive disconfirmation of the systems’ capabilities; two respondents went from mixed feelings to positive, and two respondents went from negative to mixed feelings. 30% of the users had a simple
confirmation of capabilities; two respondents were positive, and one respondent had mixed feelings in both phases. 30% of the respondents had a negative disconfirmation of the systems’ capabilities; they went from positive to mixed feelings. Concerning the systems’ value; except for one user who had mixed feelings, all respondents were positive about the systems’ value in the pre-implementation phase. In the post-implementation phase, 50% of the respondents were positive, and 50% had mixed feelings. 60% of the respondents had a simple confirmation of the systems’ value; 40% of the respondents had a negative disconfirmation of the systems’ value; they went from positive to mixed feelings. None of the respondents had a positive disconfirmation of value. The expectations,
experiences and disconfirmation of capabilities and value are visible in table 2. A ‘+’ means a positive disconfirmation, a ‘0’ means a simple confirmation, and a ‘-’ means a negative disconfirmation.
21 Examples of embedded cases
This section provides two examples of embedded cases. The choice for the described respondents is based on their opposites: the first respondent has a simple confirmation of value and a positive disconfirmation of capabilities, while the second respondent has negative disconfirmation of systems’ value and a simple disconfirmation of systems’ capabilities (since no respondents had a positive disconfirmation of value or a negative disconfirmation of capabilities, these two are the most opposite).
Example of respondent with a simple confirmation of value and a positive disconfirmation of capabilities
Pre-implementation: R6 is satisfied with the old system: “perfect, it works perfect”. He has
little knowledge about the new system. His expectations about the systems’ capabilities are negative; he is afraid that the new system will be slower and will miss the personalised options that the old system had. However, he is positive about the systems’ value: he thinks that the (different) way of working with the system will improve the processes and expects that the new system will help them to get rid of all existing workarounds. He has a positive attitude towards the change; he thinks that stagnation means decline and considers it as a challenge. R6 has a low feeling of involvement and regret that. R6 does not have trust in the implementation, and expects trouble: “I ordered materials in advance and I’ve got the parts; if the system doesn't work well, we can still produce […] Probably not quite how it should be, but yeah”. R6 is negative about the timing: “It goes way too fast. Uncontrolled fast". R6 has an outstanding low feeling of support and complains about this throughout the interview. He wished that there had been a transparent plan of action, which had been communicated much earlier; this should have given the opportunity to test the system.
Post-implementation: The implementation of the system brought less trouble than R6 expected. He
22 Example of respondent with a negative disconfirmation of systems’ value and a simple disconfirmation of systems’ capabilities
Pre-implementation: R3 has mixed feelings about the old system; it has some major drawbacks but in
general, it works fine for him. He has low knowledge of the new system: “I did not even spend a day on it”. R3 perceives the need for change and has a positive attitude towards the change. He wants to go along with the changing company and believes that the new system will add value, by saying “I think it will bring benefits to our department”. He has positive expectations about the new systems’
functionalities. He is positive about the timing of the system, by saying “I am ready for it” and “I think our department is ready”. R3 feels prepared and expects that the implementation will have low impact for him: “It will not differ much for my work”. R3 feels heard and moderate involved and has a strong feeling of support by the change team. Although R3 has trust in the implementation, he also expects trouble; “We have pretty tight delivery times. If the system gets in the way, the delivery time becomes longer and then we have a problem”. He complains about the practice exercises of the new system; only little exercises were practiced in the new system before the implementation, and not a whole project as it would be in reality. He also would like some general information about the system; like where which settings are. And while the implementation for this respondent is planned barely a month later, he is not sure about the implementation date: “I think in January, right?”.
Post-implementation: R3 has mixed feelings about the support of the change team; sometimes they
helped them with problems in the system quickly, and sometimes it took a longer time. The system was way less equipped as he thought it would be, which resulted in many setbacks during the
23
Cross embedded case analysis
For this case, a pattern could be distinguished among the embedded cases (respondents). Among the respondents of the case, three main groups could be formed with (almost) similar
disconfirmations of both capabilities and value. The first group consisted of four respondents (R1, R6, R7 and R8) with a simple confirmation of value and a positive disconfirmation of capabilities. The second group consisted of two respondents (R2 and R5) with a simple confirmation of systems’ value and negative disconfirmation of systems’ capabilities. The third group consisted of respondents (R3, R4, R9 and R10) with a negative disconfirmation of systems’ value and a simple or negative
disconfirmation of systems’ capabilities. By comparing the contextual factors of these respondents within each group, there were (except for group 2) only a few clear similarities. The contextual factors on which they were similar are in the table 4 and table 5 shown by a grey cell shading.
24 Table 5 Distinguished groups of case and their contextual factors post-implementation phase
So, since the respondents with similar disconfirmations of both capabilities and value did only have a few contextual factors in common, it seems to be not enough ground for an analysis. Therefore, the respondents (embedded cases) are compared to each other based on each disconfirmation differently, which means that they are grouped twice. First, the respondents with similar disconfirmation of systems’ capabilities are grouped. Secondly, the respondents with similar disconfirmation of systems’ value are grouped. This section shows similarities of the respondents with a positive, simple or negative disconfirmation of capabilities, and compares the characteristics of the groups. It also shows similarities of respondents with a simple and negative disconfirmation of value and compares the characteristics of the groups.
Similarities of respondents with a positive, simple or negative disconfirmation of
capabilities. In the text below, the similarities of the respondents with each kind of disconfirmation of capabilities are described, for both the pre- and post-implementation phase. Factors in which they differ greatly, are ignored. For example, if the involvement of the three respondents with negative disconfirmation of capabilities vary from low to moderate to high, it is not described. After the description of similarities within each group, the groups are compared with each other.
Positive disconfirmation of capabilities. In the pre-implementation phase, each respondent
25 mixed feelings about the systems’ capabilities but were all positive about the systems’ value. They all had a simple confirmation of systems’ value.
Simple confirmation of capabilities. The respondents with a simple confirmation, all had
mixed feelings or were not satisfied about the old system in the pre-implementation phase. They all felt moderate or low involved in the implementation process, and all expects some trouble with the implementation. They all felt moderate or low supported by the change team. They all had mixed feelings or were positive about the systems’ capabilities and had positive expectations of systems’ value. In the post-implementation phase, they all had mixed feelings or were negative about the timing of the implementation. They all had mixed feelings or were positive about the systems’ capabilities. They all had mixed feelings about systems’ value, and therefore had a negative disconfirmation of systems value. They felt low supported by the change team, and their feeling about the setbacks during the implementation was negative or moderate.
Negative disconfirmation of capabilities. The respondents with a negative disconfirmation, all
had mixed feelings or were not satisfied about the old system in the pre-implementation phase. They all had some trust in the implementation. They all had positive expectations about the systems’ capabilities and were positive or had mixed feelings about the systems’ value. In the post-implementation phase, they all had mixed feelings or were negative about the timing of the
implementation. They all had mixed feelings about the systems’ capabilities and had mixed feelings or were positive about the systems’ value. Their feeling of support by the change team was low or moderate, and they all had low self-sustainability with the system. Their feeling about the setbacks during the implementation was negative or moderate. They all had a positive prospect about the future.
Comparing the groups. In order to compare the groups based on different disconfirmations of capabilities, values were related to each factor of each respondent. If a factor was positive or high, the worth was 1, if a factor was neutral, mixed feelings or moderate, the worth was 0 and if a factor was negative or low, the worth was -1. For example, of the respondents with positive disconfirmation of systems’ capabilities, two had a high self-sustainability of the system (both value: 1) and two had a moderate self-sustainability of the system (value: 0) This means that the respondents with positive disconfirmation of systems’ capabilities scored on average 0,5 on the self-sustainability with the system. The respondents with negative disconfirmation of the systems’ capabilities all had a low self-sustainability with the system (all three a value of -1). This means that the respondents with negative confirmation of systems’ capabilities scored on average -1 on the self-sustainability with the system, and therefore had lower self-sustainability of the system. The differences between the groups are shown in table 6. This table shows for each contextual factor which group were most positive about something, which were the least positive or most negative, and which group was in-between. For example, the 10th column of table 6 shows that the respondents with positive disconfirmation of
26 the lowest sustainable and respondents with a simple disconfirmation in-between. When all members of the groups agreed on a factor, a contextual factor that probably impacts the disconfirmation is distinguished. So, when all respondents of positive disconfirmation are positive or moderate about their feeling of setbacks, and all respondents with a negative disconfirmation are negative or moderate about the setbacks, there is an agreement. When all respondents with a positive disconfirmation are divided on their feeling (positive, moderate and negative), there is no agreement. When some of them are positive, some negative and some mixed feelings, there is no agreement). The factors on which such an agreement exists, is shown in grey shaded cells of table 7.
Similarities of respondents with a simple or negative disconfirmation of value. In the text below, the similarities of the respondent with each kind of disconfirmation of value are described, for both the pre- and post-implementation phase. Factors in which they differ greatly, are ignored. After the description of the similarities, the characteristics of the groups are compared.
Simple confirmation of value. The respondents with a simple confirmation of value only had in
common that they all felt positive or moderate about setbacks.
Negative disconfirmation of value. In the pre-implementation phase, respondents with a
negative disconfirmation of value all felt moderate or low involved, and they all expected (some) trouble. They had mixed feelings or were not satisfied with the old system. They all felt low or moderate supported by the change team. They were positive or had mixed feelings about systems’ capabilities and were positive about systems’ value. In the post-implementation phase, the majority (75%) of the respondents with negative disconfirmation of value was negative about the timing of the implementation. They were still positive or had mixed feelings about the systems’ capabilities; the majority (75%) had a simple confirmation of systems’ capabilities. They all had mixed feelings about the systems’ value. The majority of this group (75%) felt low supported by the change team, and they were negative or moderate about their feeling of setbacks during the implementation. Their prospect of the future was positive or moderate.
27 Table 6 Comparing the groups of respondents based on disconfirmation of systems’ capabilities
28
Discussion
This chapter describes the key concepts, the limitations, the recommendations for future research and managerial implications.
Key concepts
This research explored how and why users' experiences of a mandatory ERP system in the post-implementation phase differ from their expectations in the pre-post-implementation phase. The results of this research contribute to the adoption literature on ERP systems by investigating contextual factors, while keeping the fact that the technology is mandatory, into account. Traditional adoption models as TAM, TPB and DOI are not originally built for mandatory technologies, as an ERP system often is. The models assume that the use of a technology is a free choice of the (potential) users. Since users’ satisfaction of a technology is a more suitable predictor of users’ adoption in a mandatory environment (Delone & Mclean, 1992), EDT was used for this research. EDT explains satisfaction by
disconfirmation, which is the difference between expectations and experiences. This research also expands the EDT literature by applying the theory to a context with an ERP system; previous research applied it to IT in general or other technologies.
Since researchers who apply EDT rarely investigate expectations and experiences separately, but only examine the disconfirmation afterwards, this research contributes by investigating them separately. That is important, because it allows to examine the indirect effects too (Lankton & McKnight, 2012; Venkatesh & Goyal, 2010). Furthermore, it provides insight in the users’ feelings about the system by time order, since the expectations are before and the experiences after the implementation (Lankton & McKnight, 2012). An example of an indirect effect that occurred in this research, was that the respondents who did not experience the setbacks during the implementation as being negative, felt (more) positive about the systems’ timing in the post-implementation phase. This will be explored later in this chapter.
29 Disconfirmation
How the experiences differ from their expectations, is shown by the investigated disconfirmation. Three out of ten respondents had a single confirmation of systems’ capabilities, while six out of ten had a single confirmation of systems’ value (table 2). That means that users’ experience with systems’ capabilities did more often differed from their expectations than the experiences and expectations of the systems’ value differed. Four out of ten respondents had a negative disconfirmation of systems’ value. The users’ disconfirmation of capabilities was almost evenly distributed: four had a positive disconfirmation, three had a simple confirmation and three had a negative disconfirmation. The disconfirmation of systems’ value either was simple or negative. This is probably due to the fact that only one respondent had mixed feelings about systems’ value in the pre-implementation phase; the other nine respondents were positive in that phase.
Contextual factors disconfirmation of capabilities and value.
Why the experiences differ from the users’ expectations, was explored by contextual factors (table 3). There are two contextual factors that have impact on both disconfirmation of capabilities and
disconfirmation: the expectations of capabilities and setbacks during the implementation (table 6 & 7). Expectations. The more positive the expectations of systems’ capabilities in the
pre-implementation phase, the more negative the disconfirmation of capabilities. Also, respondents with negative disconfirmation of value had more positive expectations of systems’ capabilities than respondents with a simple disconfirmation. The respondents that had positive expectations of the capabilities in the pre-implementation phase, were often the ones who believed that not much would change. Some of them even said that it would be the same system, but some buttons would be replaced. However, the new system was less similar to the old system than they thought it would be. Furthermore, not all of the data was (correctly) transferred to the new system, which made some functionalities of the system not usable yet, or useful but cumbersome with a lot of required actions. For most respondents with positive expectations, this was the main reason that they experienced the systems’ capabilities less positive and started to doubt about the systems’ value.
The fact that most respondents had other experience with the systems’ capabilities than they expected, might have to do with the lack of training they received; almost all respondents complained about it. Training is important in forming realistic expectations. When users are unknown with a system, they tend to rely on initial expectations to form satisfaction judgements (Lankton, 2012). Training can be used to correct these initial expectations.
30 (some) trouble, only one of them had a positive feeling about the setbacks during the implementation. So, although they were ‘prepared’ for trouble, most of them still felt moderate or negative about either the number of setbacks, or about the impact of setbacks, or both.
Contextual factors disconfirmation of capabilities.
Except for the factors expectations of capabilities and setbacks during the implementation, the factor self-sustainability also seemed to influence the users’ disconfirmation of systems’ capabilities.
Self-sustainability. The higher the users’ feeling of self-sustainability in the
post-implementation phase, the more positive their disconfirmation of capabilities. The self-sustainability seems to have to do with users’ technological skills or their confidence. Users with technological skills were able to find their way in the system because of for example technological knowledge, previous systems they used, or they knew how to search on the internet what they were looking for. Among the users who did not have that much technological skills, it seemed to be a matter of confident. Some of the users with less confident, expressed that they dared not to try; they were afraid to make mistakes in the system what would negatively impact their selves or their colleague. This could also have a link with their skills; it is a possibility that this low confidence comes from low technological skills. Other users were more confident; they saw the system as a trial and error. Some expressed their frustration about the lack of training and testing and argued that they tried the system as they want to, because the change team barely told them anything; so, problem for the organization. This factor
‘self-sustainability’ can be compared with self-efficacy, which is someone’s belief in his or her ability to perform a task. Self-efficacy is in the adoption literature also acknowledged as important factor (Elkhani, Ahmad and Soltani, 2014). Self-efficacy is influenced by transformational leadership; with higher self-efficacy, the chance that users will experiment with systems functionality and learn the system quickly, will increase (Elkhani et al., 2014).
Contextual factors disconfirmation of value.
Except for the factors expectations of capabilities and setbacks during the implementation, the factors that also seemed to influence the users’ disconfirmation of systems’ value, were satisfaction with the old system trust in the implementation, feeling of support and timing.
31 Trust. The respondents with negative disconfirmation of value were less trustful about the
implementation (in the pre-implementation phase) than the respondents with simple confirmation of value. Almost all respondents expected (some) trouble during the implementation. Uncertainty about the situation, plan of action, changes for their tasks and the moment of implementation, was by various respondents mentioned as the main reason for the lack of trust in the implementation. Even in the post-implementation phase, there was still uncertainty among the participants about the situation; whether the limitations and failures of the new system were temporary or permanent, who had to fix it, when it would be fixed and whether their tasks would change later on.
Feeling of support. Respondents with negative disconfirmation of value were more negative about their feeling of support by the change team in the post-implementation phase. Respondents
complained about the fact that the change team only existed of two members; the ERP consultant, who did not even work fulltime for Tech, and the change initiator, who had to lead the change besides his own job and daily tasks. In the post-implementation, many respondents realized that they were far from were they should be, the system did not yet work how it should be, and they did not know what other obstacles would occur. As one of the respondents expressed: “if there is a fire everywhere [referring to all obstacles that can occur], and you have not enough people with knowledge, you know what will happen; the whole thing will burn down. So, I don't know if [change initiator] can handle all of that” (R7). So, the situation was uncertain, and they felt lack of support. Garg and Garg (2013) argue that low support of the management is one of the critical factors of ERP implementation failure. Also, a charismatic form of leadership such as transformational leader impacts the self-efficacy (Elkhani et al., 2014), which is comparable to self-sustainability.
Timing. Respondents with negative disconfirmation of value were in the post-implementation phase more negative about the timing than respondents with simple confirmation of value. Awa, Uko, & Ukoha (2017) emphasized the importance of measuring adoption in more than one stage, since the influence of variables can vary in the different stages; they may lose meaning and weight overtime. The factor ‘timing’ proved their point in this research: the respondents with negative disconfirmation of value were more positive about timing in the pre-implementation phase than respondents with simple confirmation. This turned around in the post-implementation phase; the respondents with simple confirmation became more positive and the respondents with negative disconfirmation of value became more negative about the systems’ timing.
32 have been implemented on a later moment, after testing, training and fully set up. Remarkable is that the users’ who were positive or had become more positive about the timing in the post-implementation phase, felt moderate or positive about the setbacks during the implementation. So, it is a possibility that users felt (more) positive about the systems’ timing in the post-implementation phase because they did not experience the setbacks during the implementation as being negative.
In short: users’ experiences of the systems’ capabilities differed from their expectations more often than those of the systems’ value. The disconfirmation of systems’ value either was simple or negative; mostly simple. The users’ disconfirmation of systems’ capabilities was approximately evenly
distributed, but the positive disconfirmation of capabilities slightly surpassed the others. The users’ disconfirmation of systems’ capabilities seemed to be influenced by expectations of capabilities, setbacks during the implementation and self-sustainability. The users’ disconfirmation of systems’ value seemed to be influenced by satisfaction with the old system, expectations of capabilities, trust in the implementation, timing, feeling of support and setbacks during the implementation.
Limitations
Because of time limitations, the second set of interviews took place around a week after the system was introduced to the users and the users started to perform their daily work in it. This seemed to be too short after the ‘big bang’; respondents sometimes had a hard time answering an interview question because they did not know how a certain issue would work out in the future.
Recommendations for future research
Some of the respondents worked closely together, as shown in table 1. Although their mutual characteristics were not enough base to write about it in the Results section, some of them seemed slightly similar. It would be interesting to investigate the role of social influences on the users’ disconfirmation.
Tech is a family company, and most employees have been working there for a long time. In the conversations outside of the interviews, several of them expressed that they love to work for this company, are motivated and proud of the company and do not want to work anywhere else. Therefore, some of them condone certain things they do not like (i.e. lack of communication) by citations as: “ah well, that’s how it goes here” (R5). It would be interesting to perform this research in an organization that is not a family business. Also, this research was performed in a single organization, a technology organization; it would be interesting to perform the research in multiple organizations, or organization from different branches.
33 respondents also felt not involved, future can find out whether there is a relation between those two contextual factors by investigating to which extent users can be (personally) prepared by providing them a specific role in the change.
As mentioned in the limitations, it would be valuable if the second set of limitations takes place a few weeks or months later. It would also be interesting to add more moments of measuring, to explore the development of disconfirmation.
For this research, the disconfirmation is examined by comparing the expectations and
experiences of systems’ value and capabilities. It would be interesting to measure the disconfirmation on other variables than those.
Because of anonymity, it was not possible to include demographic factors to the research. It would be interesting to investigate how for example the sex, age, experience or function influence the disconfirmation.
Lastly, quantitative research is needed to confirm the links in this research; whether the expectations and experiences of systems’ capabilities do differ more often than those of the systems’ value, and the impact of the contextual factors.
Managerial implications
Managers should give the (potential) users more insight in the implementation process of the mandatory ERP system. They should communicate plans and deadlines. This can give users a better feeling of timing, and create trust by showing that aspects are thought trough. The respondents expressed often their insecurities, as well in the pre- as post-implementation phase. Most of them did not even know for who, when, why and what going to happen till weeks before the change, and this made some of them feel considered unimportant and not appreciated: “we worked five years with the other system, we really knew the ins and outs. After five years, you only got involved in the last two months before the new system” (R6). Some of them said that they did not even want to be involved in decisions, but just want to be informed.
Managers should not ‘sell’ the system among the employees, but create realistic expectations in the pre-implementation phase. If users’ expectations are too high, a negative disconfirmation and thereby decreased satisfaction is more likely. However, a too low expectation can also be negative for the satisfaction; it can make the users doubt on the trustworthiness or credibility of the organization (Venkatesh & Goyal, 2010). As mentioned in the section Key Concepts, training is important in forming realistic expectations. So, managers should not neglect the importance of training and testing. In this case, there was a lot of insecurities in both implementation stages, low trust, low
34 Managers should give much attention to the questions who will lead the change and who will assist in the change. Respondents of this research often complained about the fact that only one part-time ERP consultant and one manager (besides his own job) were responsible for the change. Most of them felt low supported, and missed a clear path to follow. Since many of the respondents in this case felt low involved, managers could create specific roles for the user.
35
References
Abdinnour, S., & Saeed, K. (2015). User perceptions towards an ERP system: Comparing the post-implementation phase to the pre-post-implementation phase. Journal of Enterprise Information
Management, 28(2), 243-259.
Abdinnour, S., Lengnick-Hall, M., & Lengnick-Hall, C. (2003). Pre-implementation attitudes and organizational readiness for implementing an Enterprise Resource Planning system. European
Journal of Operational Research, 146(2), 258-273.
Ajzen, I. (1991). The theory of planned behavior. Organization Behavior and Human Decision
Processes, 52(2), 179-211.
Alhirz, H., & Sajeev, A. (2015). Do cultural dimensions differentiate ERP acceptance? A study in the context of Saudi Arabia. Information Technology and People, 28(1), 163-194.
Ali, M., & Miller, L. (2017). ERP system implementation in large enterprises – a systematic literature review. Journal of Enterprise Information Management, 30(4), 666-692.
Awa, H., Uko, J., & Ukoha, O. (2017). An Empirical Study of Some Critical Adoption Factors of ERP Software. International Journal of Human-Computer Interaction, 33(8), 609-622.
Badewi, A. (2016). The impact of project management (PM) and benefits management (BM) practices on project success: towards developing a project benefits governance framework.
International Journal of Project Management, 34(4), 761-778.
Bargh, J., Chen, M., & Burrows, L. (1996). Automaticity of Social Behavior: Direct Effects of Trait Construct and Stereotype Activation on Action. Journal of Personality and Social Psychology,
71(2), 230-244.
Bertram, R., Fixsen, D., & Blase, K. (2015). Improving Programs and Outcomes: Implementation Frameworks and Organization Change. Research on Social Work Practice, 25(4), 477-487. Bhattacherjee, A., & Premkumar, G. (2004). Understanding Changes in Belief and Attitude Toward
Information Technology Usage: A Theoretical Model and Longitudinal Test. MIS Quarterly,
28(2), 229-254.
Bingi, P., Sharma, M., & Godla, J. (1999). Critical Issues Affecting an ERP Implementation.
Information Systems Management, 16(3), 7–14.
36 https://www.mckinsey.com/business-functions/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value
Breckler, S. (1984). Empirical validation ofaffect, behavior, and cognition as dis- tinct components of attitude. Journal ofPersonality and Social Psychology, 47(6), 1191-1205.
Brown, S., Massey, A., Montoya-Weiss, M., & Burkman, J. (2002). Do I really have to? User
acceptance of mandated technology. European Journal of Information System, 11(4), 283-295. Bueno, S., & Salmerón, J. (2008). TAM-based success modeling in ERP. Interacting with Computers,
20(6), 515-523.
Cadotte, E., Woodruff, R., & Jenkins, R. (1987). Expectations and norms in models of consumers satisfaction. Journal of Marketing Research, 24(3), 305-314.
Chakraborty, S., & Sharma, S. (2007). Enterprise Resource Planning: An Integrated Strategic Framework. International Journal of Management and Enterprise Development, 4(5), 533-551.
Chang, M., Chang, I., Hwang, H., Liaw, H., Hung, M., Chen, S., & Yen, D. (2008). A neural network evaluation model for ERP performance from SCM perspective to enhance enterprise
competitive advantage. Expert Systems with Applications, 113(2), 1809-1816.
Davenport, T. (1998). Putting the enterprise into the enterprise systems. Harvard Business Review,
76(4), 121-131.
Davis, F., Bagozzi, R., & Warshaw, P. (1989). User acceptance of computer technology: A comparison of two theoretical models. Management Science 35, 35(8), 982–1003. Delone, W., & McLean, E. (1992). Information system success: the quest for dependent variable.
Information Systems Research, 3(1), 60-95.
Dey, A. (2001). Understanding and using context. Personal and Ubiquitous Computing, 5(1), 4-7. Doll, W., & Torkzadeh, G. (1988). The measurement of end-user computing satisfaction. MIS
Quarterly, 12(2), 259-274.
Elkhani, N., Ahmad, M., & Soltani, S. (2014). The effects of transformational leadership and ERP system self-efficacy on ERP system usage. Journal of Enterprise Information Management,
27(6), 759-785.
37 Garg, P., & Garg, A. (2013). An empirical study on critical failure factors for enterprise resource
planning implementation in Indian retail sector. Business Process Management Journal,
19(3), 496-514.
Grimmelikhuijsen, S., & Porumbescu, G. (2017). Reconsidering the expectancy disconfirmation model. Three experimental replications. Public Management Review, 19(9), 1272-1292. Haddara, M., & Zach, O. (2012). ERP Systems in SMEs: An Extended Literature Review.
International Journal of Information Science, 2(6), 106-116.
Hsieh, J., Rai, A., Petter, S., & Zhang, T. (2012). Impact of User Satisfaction with Mandated CRM Use on Employee Service Quality. MIS Quarterly, 36(4), 1065-1080.
Hwang, Y., Al-Arabiat, M., & Shin, D. (2016). Understanding technology acceptance in a mandatory environment: A literature review. Information Development, 32(4), 1266-1283.
Hwang, Y., Al-Arabiat, M., Shin, D., & Lee, Y. (2016). Understanding information proactiveness and the content management system adoption in pre-implementation stage. Computers in Human
Behavior, 64, 515-523.
Joyce, A., & Piper, W. (2002). Expectancy, the Therapeutic Alliance, and Treatment Outcome in Short-Term Individual Psychotherapy. Journal of Psychotherapy Practice and Research, 7(3), 236-248.
Kettinger, W., & Lee, C. (2005). Zones of Tolerance: Alternative Scales for Measuring Information Systems Service Quality. MIS Quarterly, 29(4), 607-621.
Klaus, H., Rosemann, M., & Gable, G. (2000). What is erp? Information Systems Frontiers, 2(2), 141-162.
Korman, A., Wittig-Berman, U., & Lang, D. (1981). Career Success and Personal Failure: Alienation in Professionals and Managers. Academy of Management Journals, 24(2), 342-360.
Kossek, E. (1989). The acceptance of human resource innovation by multiple constituencies.
Personnel Psychology, 42(2), 263-281.
Kossek, E., Young, W., Gash, D., & Nichol, V. (1994). Waiting for innovation in the human resources department: godot implements a human resource information system. Human Resource
Management, 33(1), 135-159.
38 Lai, P. (2017). THE LITERATURE REVIEW OF TECHNOLOGY ADOPTION MODELS AND
THEORIES FOR THE NOVELTY TECHNOLOGY. Journal of Information Systems and
Technology Management, 14(1), 21-38.
Lankton, N., & McKnight, H. (2012). Examining Two Expectation Disconfirmation Theory Models: Assimilation and Asymmetry Effects. Journal of the Association for Information Systems,
13(2), 88-115.
Leung, L., & Chen, C. (2019). E-health/m-health adoption and lifestyle improvements: Exploring the roles of technology readiness, the expectation-confirmation model, and health-related information activities. Telecommunications Policy, 43(6), 563-575.
Leupen, J. (2019, January 25). IT-flop bij medicijngroothandel Pluripharm kost 180 banen. Retrieved from fd.: https://fd.nl/ondernemen/1287010/it-flop-bij-medicijngroothandel-pluripharm-kost-180-banen?_ga=2.68266582.654526549.1573719637-1031053877.1573719637#
Maditinos, D., Chatzoudes, D., & Tsairidis, C. (2011). Factors affecting ERP system implementation effectiveness. Journal of Enterprise Information Management, 25(1), 60-78.
Madrigal, R. (1995). Cognitive and Affective Determinants of Fan Satisfaction with Sporting Event Attendance. Journal of Leisure Research, 27(3), 205-227.
Nah, G., Lau, J., & Kuang, J. (2001). Critical factors for successful integration of enterprise resource planning. Business Process Management Journal, 7(3), 285-296.
Oliver, R. (1977). Effect of expectation and disconfirmation on post-exposure product evaluations: An alternative interpretation. Journal of Applied Psychology, 62(4), 480–486.
Oliver, R. (1980). A cognitive model of the antecedents and consequences of satisfaction decisions.
Journal of Marketing Research, 17(4), 460–469.
Oliver, R., & DeSarbo, W. (1988). Response determinants in satisfaction judgments. Journal of
Consumer Research, 14(4), 495–507.
Oliver, R., Balakrishnan, P., & Barry, B. (1994). Outcome Satisfaction in Negotiation: A Test of Expectancy Disconfirmation. Organizational Behavior and Human Decision Processes, 60(2), 252-275.
Oliver, R. (1996). Satisfaction: A behavioral perspective on the consumer. New York: McGraw Hill. Olson, J., & Dover, P. (1979). Disconfirmation of Consumer Expectations through Product Trial.
39 Phillips, D., & Baumgartner, H. (2002). The Role of Con sumption Emotions in the Satisfaction
Response. Journal of Consumer Psychology, 12(3), 243-252.
Ptak, C., & Schragenheim, E. (2000). ERP: Tools, Techniques, and Applications for Integrating the
Supply Chain. New York: St. Lucie Press.
Rogers, E. (1995). Diffusion of innovations (4e ed.). New York: Free Press.
Ross, J., & Vitale, M. (2000). The ERP revolution: Surviving vs thriving. Information Systems
Frontiers, 2(2), 233-241.
Shivers, S., & Charles, A. (2006). Ready, set, go: examining student readiness to use ERP technology.
Journal of Management Development, 25(8), 795-805.
Soh, C., Kien, S., & Yap, J. (2000). Cultural fits and misfits: is ERP a universal solution?
Communication ofACM, 43(4), 47-51.
Somers, T., & Nelson, K. (2001, January 3). The Impact of Critical Success Factors across the Stages of Enterprise Resource Planning Implementations. Proceedings of the 34th Annual Hawaii
International Conference on System Sciences.
Spreng, R., MacKenzie, S., & Olshavsky, R. (1996). A reexamination of the determinants of consumer satisfaction. Journal of Marketing, 60, 15-32.
Sternad, S., Gradisar, M., & Bobek, S. (2011). The influence of external factors on routine ERP usage.
Industrial Management & Data Systems, 111(9), 1511-1530.
Szajna, B., & Scamell, R. (1993). The effects of information system user expectations on their performance and perceptions. MIS Quarterly, 17(4), 493-516.
Taherdoost, H. (2018). A review of technology acceptance and adoption models and theories.
Procedia Manufacturing, 22, 960-967.
Venkatesh, V., & Goyal, S. (2010). Expectation Disconfirmation and Technology Adoption: Polynomial Modeling and Response Surface Analysis. MIS Quarterly, 34(2), 281-303. Wang, W., Hsieh, J., Butler, J., & Hsu, S. (2008). Innovate with Complex Information Technologies:
A Theo retical Model and Empirical Examination. Journal of Computer Information Systems,
