investigation on risks faced by sap consultants when...

Investigation on risks faced by SAP Consultants when maintaining and

supporting SAP ERP 6.0

A study submitted in partial fulfillment

of the requirements for the degree of

Master of Science in Information Systems

at

THE UNIVERSITY OF SHEFFIELD

by

Luis Alberto Ramos Salazar

September 2012

1

Abstract

Background: The literature presents no identical study on ERP maintenance risks as it is

extremely limited. The ERP maintenance risks have not been categorized according the main

ERP maintenance activities in any other study. However, the literature helped identify the main

ERP maintenance activities: ERP maintenance administration, ERP changes, ERP user support,

ERP enhancements, and ERP updates.

Aims: The aims were to identify the main ERP maintenance and support activity categories. In

each category then the risks can be identified to generate a list of risks on ERP maintenance.

Methods: Different method approaches are discussed in this dissertation. An inductive and

qualitative approach is selected as the methodology for this study. More specifically, the

researcher conducted 8 semi-structured interviews with SAP consultants who are currently

working in a maintenance project for the case company Neoris. Findings are reported in a

narrative analysis format and concept maps were used to summarize risks.

Results: The results identified 47 risks pertaining to the responses from the third-party SAP

consultants. The narrative analysis was used to report the story on the experiences with dealing

with risks. In addition, concept maps summarize the risks for each participant. A cross-

comparison was performed for the risks on the findings.

Conclusions: There was found a list of 47 maintenance risks summarized in five categories. This

list can be used for further research on ERP maintenance risks.

2

Acknowledgements

This dissertation has given me more in depth knowledge on ERP systems and means a great

accomplishment for my professional and academic careers. My future endeavors will be greatly

benefited by the skills obtained from this study. This could not have been realized with the help

of Dr. G.C. Alex Peng who guided me throughout the academic year and helped me with any

doubts related to the topic. Therefore, as my supervisor I would like to thank him for his

guidance, support, and assistance in the completion of this dissertation.

In addition, my classmates were also part of brainstorming ideas and giving advice on the related

research. Their discussion on their studies was really helpful in the creation of mine. Moreover,

they contributed greatly to this study.

Also, my family and friends in my country were always supportive and cheering me up to

complete the dissertation. My parents and sisters were always there for anything I needed.

My tutors and professors at the University of Sheffield provided an excellent environment of

study. In fact, I would like to thank them for their teachings throughout this Master’s program.

Lastly, the participants to my study were the most valuable resources. I would like to thank the

SAP Consultants from Neoris, who are all my former coworkers, for participating in the study

and given me the time to interview them.

3

Content

Chapter 1. Introduction ................................................................................................................... 9

1.1 Introduction and Research Background .................................................................................... 9

1.2 Problem Statement .................................................................................................................... 9

1.3 Research Question .................................................................................................................. 10

1.4 Research Objectives ................................................................................................................ 10

1.5 Research Methodology ........................................................................................................... 10

1.6 Structure of dissertation .......................................................................................................... 11

Chapter 2. ERP Systems and ERP Maintenance .......................................................................... 12

2.1 Introduction ............................................................................................................................. 12

2.2 ERP Market ............................................................................................................................. 12

2.3 ERP Life Cycle ....................................................................................................................... 13

2.4 ERP Maintenance Activities ................................................................................................... 16

2.4.1 ERP changes .................................................................................................................... 17

2.4.2 ERP user support.............................................................................................................. 18

2.4.3 ERP enhancements........................................................................................................... 19

2.4.4 ERP updates ..................................................................................................................... 19

2.5 ERP Maintenance Providers ................................................................................................... 20

2.6 ERP Maintenance Risks .......................................................................................................... 22

2.6.1 What is Risk? ................................................................................................................... 22

2.6.2 Definition of maintenance risk......................................................................................... 23

2.6.3 Summary of ERP maintenance risks in the literature ...................................................... 24

2.7 Conclusion .............................................................................................................................. 25

Chapter 3. Methodology ............................................................................................................... 27

3.1 Introduction ............................................................................................................................. 27

3.2 Research Approach ................................................................................................................. 27

3.3 Case Study Strategy ................................................................................................................ 27

3.4 Case Company ........................................................................................................................ 28

3.5 Research Design...................................................................................................................... 29

3.6 Data connection ...................................................................................................................... 30

3.6.1 Interview .......................................................................................................................... 30

3.6.2 Types of Interview Approaches ....................................................................................... 30

3.6.3 Design of Interview Questions........................................................................................ 31

3.6.4 Interviewees ..................................................................................................................... 31

4

3.6.5 Interview administration .................................................................................................. 31

3.7 Data Analysis .......................................................................................................................... 32

3.8 Summary ................................................................................................................................. 33

Chapter 4. Results and Findings ................................................................................................... 34

4.1 Introduction ............................................................................................................................. 34

4.2 ERP Maintenance Activity Categories ................................................................................... 34

4.3 Discussion of Individual Interviews ....................................................................................... 34

4.3.1 Interview One: IT Manager/Team Leader 1 .................................................................... 35

4.3.1.1 Risks in ERP maintenance administration ................................................................ 35

4.3.1.2 Risks in ERP changes ............................................................................................... 37

4.3.1.3 Risks in ERP user support......................................................................................... 37

4.3.1.4 Risks in ERP enhancements...................................................................................... 38

4.3.1.5 Risks in ERP updates ................................................................................................ 39

4.3.1.6 Conclusion ................................................................................................................ 39

4.3.2 Interview Two: IT Manager/Team Leader 2 ................................................................... 40






4.3.2.6 Conclusion ................................................................................................................ 45

4.3.3 Interview Three: Sr. Consultant 1 .................................................................................... 45






4.3.3.6 Conclusion ................................................................................................................ 50

4.3.4 Interview Four: Sr. Consultant 2 ...................................................................................... 51






5

4.3.4.6 Conclusion ................................................................................................................ 54

4.3.5 Interview Five: Jr. Consultant 1 ....................................................................................... 54






4.3.5.6 Conclusion ................................................................................................................ 58

4.3.6 Interview Six: Jr. Consultant 2......................................................................................... 58






4.3.6.6 Conclusion ................................................................................................................ 62

4.3.7 Interview Seven: Analyst 1 .............................................................................................. 62






4.3.7.6 Conclusion ................................................................................................................ 66

4.3.8 Interview Eight: Analyst 2 ............................................................................................... 66






4.3.8.6 Conclusion ................................................................................................................ 69

4.2 Cross-comparison of Multiple Interviews .............................................................................. 70

4.2.1 Risks in ERP maintenance administration ....................................................................... 71

4.2.2 Risks in ERP changes ...................................................................................................... 72

4.2.3 Risks in ERP user support................................................................................................ 72

4.2.4 Risks in ERP enhancements............................................................................................. 72

6

4.2.5 Risks in ERP updates ....................................................................................................... 73

Chapter 5 Conclusion and Recommendation ................................................................................ 74

5.1 Conclusions ............................................................................................................................. 74

5.2 Recommendations ................................................................................................................... 74

5.3 Limitations .............................................................................................................................. 75

5.4 Future Research ...................................................................................................................... 75

Bibliography ................................................................................................................................. 77

Appendix I. SAP Global Service Partners .................................................................................... 85

Appendix II. Interview Questions Template ................................................................................. 86

Appendix III. Ethics Forms........................................................................................................... 88

7

List of Tables

Table 1. SAP Global Service Partners (SAP, 2012a).

Table 2. Cross-Comparison of ERP maintenance risks (Peng & Nunes, 2009; Salmeron &

Lopez, 2010; Salmeron & Lopez, 2012).

Table 3. Risks in ERP maintenance and support

Table 4. 47 Risks on ERP M&S

8

List of Figures

Figure 1. Magic Quadrant for SAP Application Service Providers, Europe (Gartner, 2011).

Figure 2. Stages and Outcomes

Figure 3. Individual Discussion and Cross-Comparison Findings

Figure 4. Concept Map – Risks identified by IT Manager/Team Leader 1


Figure 6. Concept Map – Risks identified by Sr. Consultant 1


Figure 8. Concept Map – Risks identified by Jr. Consultant 1


Figure 10. Concept Map – Risks identified by Analyst 1


9

Chapter 1. Introduction

1.1 Introduction and Research Background

Enterprise Resource Planning (ERP) systems are complex information systems that automate the

company’s business processes in a single database for all the functional areas (finance, sales,

human resources, manufacturing, marketing, etc.) of a company in order to have integrated

information available to every employee throughout all the different departments (Holland &

Light, 1999; Leon, 2007). In addition, an ERP system can bring substantial benefits, which have

been difficult to assess by researchers, for a company such as increasing productivity,

competiveness, and profitability (Goeke & Faley, 2009). The main reasons that companies

decide to adopt an ERP include the standardization of business procedures across the different

locations of a company, corporate growth, better customer service, reduced operational costs,

and improved decision making (Markus & Tanis, 2000; Themistocleous, et al., 2001; Esteves,

2009). In fact, ERP systems are considered one of the greatest IT innovations of the decade and

researchers have paid close attention to generate ERP related research (Al-Mashari, 2003;

Salmeron & Lopez, 2012). For this reason, the emphasis on ERP research topics have emerged in

recent years and academics are filling in the gaps with more relevant research on ERP. However,

there is a lack of literature on ERP maintenance risks or any other ERP post-implementation

study. There are several studies on risks, but a few have focused on risks related to ERP

maintenance and support (M&S) (Salmeron & Lopez, 2010; Salmeron & Lopez, 2012; Peng &

Nunes, 2009).

1.2 Problem Statement

The general problem of this study is the risks affecting ERP third-party consultants when

maintaining and supporting an ERP. Therefore, the main focus of the research can be described

by the following problem statement:

10

‘How are third-party consulting companies identifying, managing, and assessing risks when

performing ERP maintenance?’

1.3 Research Question

The research question that this study strives to answer is: “What risks are encountered by

consultants when maintaining and supporting an ERP for clients from an IT consulting

company standpoint and what are the most common risks?

1.4 Research Objectives

In order to support the aim and answer the main research question, the objectives have been

established as:

• Conduct an extensive literature review on ERP such as market, life-cycle, maintenance

providers, and maintenance activities.

• Complete a literature review on the general IS/ERP maintenance risks that have been

identified by past researchers.

• Identify and explore the main risks that consultants face when working for a client in an

IT consulting company (third-party).

1.5 Research Methodology

The methodology being used is inductive and qualitative research approach. Inductive as the

results are purely derived from responses from interview questions administered via a video chat

session. The interview method consists of the use of semi-structured interviews. This helps with

the follow up questions and does not limit the interviewer while conducting the interview

11

process. A case study was used that involved 8 third-party consultants from an IT consulting

company. Also, the narrative analysis and concept maps were used to identify the risks.

1.6 Structure of dissertation

Chapter 1. This chapter is used to introduce the concept of ERP and ERP maintenance risks as

being a newly research area. Most importantly, the problem statement helps the researcher

identify what is needed in companies that provide the ERP maintenance service. Also, the

research question and objectives are discussed in order to guide the direction of the study.

Chapter 2. This chapter investigates the relevant literature review for this study. The ERP

maintenance providers such as third-party consulting companies are discussed. Most important,

the ERP maintenance activities were investigated to determine the five main categories for the

risks.

Chapter 3. The methodology chapter describes the case company, data collection, and interviews.

In addition, the way on how the results and findings are presented using an inductive approach

with narrative analysis and concept maps.

Chapter 4. This chapter represents the results from the interviews. A cross-comparison analysis

is conducted to reflect the findings.

Chapter 5. The conclusion and recommendations are provided in this chapter. A list of

limitations is given and what can be done in future research.

12

Chapter 2. ERP Systems and ERP Maintenance

2.1 Introduction

Enterprise resource planning systems have been increasingly adopted by organizations around

the world according to the researchers and practitioners in this area (Al-Mashari & Zairi, 2000;

Peng & Nunes, 2009; Law et al., 2010; Salmeron & Lopez, 2012). With this current trend, there

are many topics around ERP that have been discussed and studied such as implementation

projects. However, there is an existent gap in the literature related to ERP Maintenance and

Support (M&S) as is mentioned by several researchers such as Salmeron and Lopez (2012) and

Peng and Nunes (2009).

2.2 ERP Market

In 2011, Forrester reported that the global ERP market was estimated to be worth $45.5bn in that

year and was forecasted to grow to $50.3bn in the following four years; thus, this explains the

increasing use and implementation of ERP systems in organization worldwide (CBR, 2011). A

similar estimation provided by AMR Research valued the ERP market at $47.7bn in 2011

(Jacobson et al., 2007). According to researchers, such as Barton (2001), Sia et al. (2002), and

Jacobson et al. (2007) from AMR Research, for the past decade the ERP market has been mostly

dominated by the big three vendors SAP, Oracle, and Microsoft Dynamics in that respective

order.

In addition, a 2011 ERP vendor market study, conducted by Panorama Consulting Group (2011),

SAP occupied 24% of the ERP market followed by Oracle with 18%, and Microsoft Dynamics

with only 11%. As of today, Gartner reported SAP as being the number one ERP vendor with

25.5% market share of the global ERP market in relation to their performance in 2011 (SAP,

2012b). Specifically to Europe, Gartner (2011) emphasized that SAP is the dominant player for

ERP solutions for companies in the region not only because of its headquarters in Germany, but

its service providers generate the most revenues from Germany followed by United Kingdom,

13

Netherlands, France, the Nordic countries all together, Italy, Belgium, and Spain. Another

interesting factor in this market trend is discussed in the newest report by Panorama Consulting

Group (2012) which studied the organizations’ ERP selection preferences when choosing a new

ERP system with 35% choosing SAP, 24% Oracle, and 17% Microsoft Dynamics. SAP’s brand

name recognition and years of experience as the market leader continuous to overrun other

vendors in the ERP market till now. As the market leader, it opens a huge window of opportunity

for third-party IT consulting companies to compete in the acquisition of maintenance and support

(M&S) contracts with the organizations that have newly acquired SAP ERP or are in the lookout

for lower cost outsourcing options that provide M&S consulting services for any ERP.

2.3 ERP Life Cycle

As discussed by Al-Mashari and Zairi (2000), Hecht et al. (2011), and Salmeron and Lopez

(2012), an ERP implementation in a company is not the end of the ERP project, since it requires

continuous maintenance to help make improvements and enhancements throughout the rest of its

life cycle. In relation to this, the ERP life cycle will be studied and the literature showed that

different researchers divided the ERP life cycle into different phases.

According to Esteves and Pastor (1999), the ERP life cycle is composed of the following six

phases:

1. Adoption decision phase: Managers evaluate the need of acquiring an ERP system to

improve their performance and business processes. The benefits and goals of the

enterprise will be discussed in relation to the direction in which the ERP will lead the

ERP adopted orgnization.

2. Acquisition phase: The selection of the best IT consulting company to implement the

selected ERP is conducted together with the agreed contract. In addition, the return on

investment is calculated, the project’s cost, and maintenance services are evaluated.

14

3. Implementation phase: Consists of customization and installation of the ERP into the

company’s environment; users are also trained before the system is up and running. This

stage ends with the go-live.

4. Use and Maintenance phase: This is just after the go-live where users are utilizing the

system to perform the business processes in the company. The system errors,

malfunctions, or improvement requests are handled in the maintenance of the system.

This specific phase is the target of the study and is considered the post-implementation

stage together with the following two phases.

5. Evolution phase: New capabilities are added that brings new benefits for the company.

This phase is also part of the study as it relates to ERP changes, enhancements, and

updates.

6. Retirement phase: This is the last phase where an ERP is being replaced by a newer

system. In fact, this is the last phase of the Post-Implementation stage.

Similarly, other researchers described an ERP life cycle by simply compacting it into a four

phase model. For example, Law et al., (2010) described a more recent ERP life cycle consisting

of the following four phases: adaptation, acceptance, routinization, and infusion. The author

stated that the last two phases are related to the Post-Implementation stage where routinization

can be viewed as the use and maintenance phase, and infusion is part of the maintenance and

evolution phases as shown by Esteves and Pastor (1999). In a study about the critical players and

activities in an ERP life cycle, Somers and Nelson (2004) included the same phases as Law et al.

(2010) ERP life cycle, but added initiation and adoption before the other four stages. In this case,

the initiation and adoption phases can be seen as the adoption decision phase defined by Esteves

and Pastor (1999). Another four phase model was described by Markus and Tanis (2000) which

included the following four phases: chartering, project, shakedown, and onward and upward.

15

Here the project phase is the implementation stage where the system is being configured,

integrated, tested, users are trained, and the rollout is completed. In relation to this study, the

shakedown and onward/upward phase are the post-implementation stage where the key players

such as IT maintenance personnel (in-house or third-party consultants) are involved in

maintaining, supporting end users, providing upgrades and continuous improvements until the

system is retired or replaced in the future (Markus & Tanis, 2000).

In relation to this study, it is necessary to stress that maintenance and support comes after the

implementation stage. Therefore, a life cycle on implementation stage will be discussed below.

Nah et al. (2001) described a five phase model on implementation stage as following:

1. Plan phase: This phase is where consultants define the targets, implementation strategy,

implementation scope, and available resources.

2. Blueprint phase: The AS-IS situations are taken into consideration together with the

creation of functional specifications and the level of customizations needed by the client.

3. Realisation phase: This is where modifications are done to the specifications, units are

tested, user training plan is generated, and functional development is carried out.

4. Final preparation phase: This phase deals with the user training onsite, migrating data,

solving any errors, and conducting a final test of the integrated system.

5. Go-live/Support phase: The system is installed in the production environment and last

details such as further training or fixing system errors may also be required.

It is of great value to discuss a life cycle of the ERP maintenance phase, which is part of the

post-implementation stage and the focus of this study, explained by Nah et al. (2001) in a case

study on ERP maintenance. The author divides the maintenance phase into the following four

phases:

16

1. Introduction phase: This phase is after the go-live and goes on for the first few months.

System usage is usually low since the users are getting to know the system or in some

cases are working in parallel with legacy systems. User support is high, so the requests on

how to use the functionalities of the system are the main type of requests being raised.

2. Growth phase: During this phase, the end users are more knowledgeable and confident

when using the system. This is when users will begin with requests such as change

requests dealing with minimum modifications to the system.

3. Maturity phase: In this phase is where major enhancements will be made to exploit the

capacity and functionalities of an ERP system. In addition, the system is being used at its

greatest capacity by the users in the company.

4. Decline phase: This phase is where the system is not meeting the users’ and company’s

expectations anymore. The IS managers decide whether they need to retire the system,

upgrade to a newer version, or keep operating with that system.

With the rapid change in technology, the life span of an ERP is decreasing and needs to be

constantly maintained and evolved with the implementation of new business requirements,

enhancements, and updates; this will increase the quality and extend the life span of the ERP

system if performed by the correct IT personnel in the M&S phase (Law et al., 2010). The

importance of ERP maintenance and support has been stressed by IS researchers, such as Law et

al. (2010) and Salmeron and Lopez (2012), which considered M&S as a major factor in the

success of an ERP adoption in an organization.

2.4 ERP Maintenance Activities

ERP maintenance has been considered by Hecht et al. (2011), Salmeron and Lopez (2012), and

Ng et al. (2003) as being a critical part of the post-implementation phase, after system goes live

to its removal, consisting of several activities that are provided by IT professionals to maintain,

17

enhance, and support the ERP system. In order to do so, companies have established

maintenance models with the purpose of controlling user maintenance requests such as bug fixes,

enhancements, changes to reports, or merely support of any type required by end users which

may go either to a help desk, IT Manager, or directly to the external consultants (Law et al.,

2010; Ng et al., 2003). In addition, prioritization of user requests is a critical task being

performed by a committee or IT Manager in order to evaluate the request’s impact or priority;

thus, a high impact requires immediate attention by consultants while a low impact may

sometimes be left aside for the near future (Law et al., 2010; Salmeron & Lopez, 2010). Also, an

efficient maintenance model between users and maintenance consultants is essential to keep

track of the progress of the requests, as well as, increase the speed of problem resolution,

coordinate work, and maintain both parties in active participation in the maintenance request

(Nah et al., 2001; Ng et al., 2003).

Furthermore, an organization, e.g. third-party maintenance provider, needs to carry tasks to

control, administrate, and handle ERP maintenance requests effectively; however, there is a lack

of adequate ERP maintenance standards or models in these organizations (Ng et al., 2003;

Salmeron & Lopez, 2012). Ng et al. (2003) discussed the first tasks that need to be carried out

before the maintenance request is being transferred to a consultant which include forecasting

workload, identifying the correct consultant for the specific request, and evaluating the Service

Level Agreement (prioritization/classification/timing) criteria for each request. For this reason,

the first main ERP maintenance activity category has been identified as ERP maintenance

administration which has been described in detail above. Apart from ERP maintenance

administration, an extensive review of the literature also identified another four categories of

ERP maintenance activities: ERP changes, ERP user support, ERP enhancements, and ERP

updates.

2.4.1 ERP changes

ERP changes can include simple customizations such as a change in configuration that will add

functionality to the ERP system, amend a report, or change screen displays (Light, 2001; Hecht

18

et al., 2011). Also, ERP changes deals with selecting new modules, changing parameters in the

system’s configuration, and modifying code to fix an error; as a result, requires testing and

acceptance by end users before any changes can be transferred to the production environment

(Hecht et al., 2011, Law et al., 2010; Salmeron & Lopez, 2010) Specifically, Light (2001)

studied two case companies where ERP changes were made such as changes to functionality,

system configuration, reports, and displays where the implications were studied and whether or

not an upgrade can affect these changes; the findings reflected that upgrades will not affect these

types of changes, but that maintenance personnel is essential for doing it right and avoid any

issues while performing an ERP change.

2.4.2 ERP user support

End users receive training before an ERP goes live which is believed to be insufficient according

to Park and Kusiak (2005) since continuous training should be provided by the consultants in the

maintenance stage and throughout its existence. In fact, Ng et al. (2001) stated that user support

requests are higher when the system is first implemented since the end user are not familiar with

the systems processes, interfaces, functionalities, etc., and also an ERP is extremely large making

users more cautious when using it. Furthermore, Park and Kusiak (2005) described the

continuous training provided by M&S personnel explains real case scenarios, aside from test

case scenarios before implementing the system, and help them with better understanding of the

system’s transactions and business processes executed in the system.

In addition, Imtihan et al. (2008) and Ng et al. (2002) described ERP user support as a main

maintenance activity that is related to the user requests for the consultancy on system behaviour,

functionalities, and user training. User support is not necessarily provided with formal training in

the maintenance stage, but can be comprised of online training material, documentation, and

manuals (Law et al., 2010; Hecht et al., 2011). The most important user support tasks are to help

the end users on how to use the system, create how-to documents, solve system errors, extreme

cases of bugs which require reporting to the vendor, and conduct live training sessions with the

users (Hecht et al., 2011).

19

2.4.3 ERP enhancements

One of the most important objectives in maintenance is the ERP optimization which requires

specific activities to be performed in the enhancement of the ERP system in order to keep the

system aligned with the business strategy and company’s goals (Hecht et al., 2011, Salmeron &

Lopez, 2012). In order to have a better system performance throughout its post-implementation

phase, Peng and Nunes (2010a) stressed that further add-ons and new components must be

implemented to improve the system’s functionality which is done through a system

enhancement. Though enhancements may bring benefits to the users, Light (2001) stressed that

enhancements once implemented require maintenance throughout the rest of their usage life

which result in more cost to the company.

Enhancements also deal with future customizations to the system which are also associated with

increased ERP costs to the client, can take a long time to implement, and are considered to be out

of reach of the vendor when providing maintenance and updates (Somers & Nelson, 2004).

Therefore, the high cost of these enhancements discourages companies from enhancing the

system. As a result, the system will eventually not meet the business operation needs and user

expectations. In spite of the high expense incurred by the client, Ng et al. (2002) stated that ERP

enhancements is a major activity in M&S and that it involves 64% of the user’s change requests

which help the user satisfy special departmental needs such as a new report or a new program.

2.4.4 ERP updates

An interesting recommendation given by Hecht et al. (2011) is that when updating an ERP

system the company has to consider which update is necessary and evaluate if the benefits of the

upgrade outperform the current benefits since updates have a high cost. To prove this, Jovicic et

al. (2012) stated that an ERP update (version) can be valued at one third of the project’s current

investment and suggested that a company can strategically skip a version by upgrading to the

20

following version when available. A similar estimation of the cost of an ERP update is of 30% of

the ERP implementation costs (Granebring & Révay, 2005). In fact, the ERP vendor will often

control the frequency and extent of ERP updates which are regularly delivered together with the

help of third-party or in-house consultants (Nah et al., 2001; Hecht et al., 2011). According to

Hecht et al. (2011), ERP updates include the installation of patches, support packages, new

versions, technical updates, and functional updates that serve to correct bugs, add functionalities,

or improve system performance. In some cases, updates may affect customizations and it is the

consultant’s responsibility to fix errors or malfunctions regarding customized functionality

(Light, 2001).

Therefore, Ng et al. (2002) stressed that preventing testing and an impact analysis must be

conducted before implementing an update in order to avoid any re-work or re-application of

customizations or previous modifications to the system. It is said that updates may sometimes

not affect the system, but are necessary to keep up with the vendor’s support version (Ng et al.

2002; Hecht et al., 2011).

2.5 ERP Maintenance Providers

In the maintenance phase of an ERP, a company can use a third-party IT consulting company to

gain higher expertise, access to the newest technology, and most importantly reduce their

maintenance costs (Shehab et al., 2011; Esteves & Pastor, 1999). Simultaneously, the

maintenance and support of an ERP can be performed by both internal and external consultants

(third-party) which regularly provide the services for a lower cost than in-house consultants that

is one of the main reasons why it has become a common solution for companies to outsource

ERP maintenance (Markus & Tanis, 2000; Salmeron & Lopez, 2010; Shehab et al., 2011). As

mentioned by Shebab et al. (2011), outsourcing ERP M&S can imply a risky strategy for a

company due to the security issues that may arise; as a result, companies tend to have their own

IT support personnel who deal with the main core modules and outsource the ERP modules that

have a less impact to the company or when in-house consultants require the assistance from

high-experienced third-party consultants.

21

In relation to third-party consulting companies, Gartner has studied the leaders of the largest

ERP (SAP) Application Service Providers (ASPs) for several years and positioned Accenture

(third-party) as one of the leaders of ERP Service Providers in 2009 due to its commitment to the

client and economically assisting their clients to achieve business value (Accenture, 2009). To

reflect its most recent position, Gartner (2011) continued to report Accenture as the leader

followed by IBM, Capgemini, and Logica in its 2011 Magic Quadrant for SAP ASPs in Europe

as shown in Figure 1.

Figure 1. Magic Quadrant for SAP Application Service Providers, Europe (Gartner, 2011)

According to every ERP adopting company, an end user can raise a maintenance request that can

either go to the company’s ERP in-house maintenance team, vendor, or a third-party consultant

depending on the agreed source established by the client (Salmeron & Lopez, 2010; Ng, 2001).

In 2008, SAP vendor was involved in a controversial issue when it was planning on increasing

22

their maintenance fees to their current customers; as a consequence, customers were looking for

SAP partners that provided the services at a lower cost and high quality. Therefore, SAP was

obliged to keep its current fees since customers were willing to switch to third-party providers

for reducing costs (InformationWeek, 2008). Moreover, it is of great importance to point out

some of SAP’s Global Service Partners listed by SAP (2012a) as trusted and most experienced

consulting companies that can implement, develop, and support their ERP systems in diverse

industries across the globe. The list includes 23 large consultancies such as Accenture,

Capgemini, Deloitte, Neoris, Infosys, IBM, PwC, HP, Fujitu, Logica, among others. The full list

and their websites can be found in Table 1 in Appendix I.

To summarize the maintenance providers, the extensive literature review pointed out to the

following three options for providing M&S of an ERP system:

1. ERP Vendor

2. In-house consultants

3. Third-party consultants

The study focuses on a third-party consulting company for this reason it was described more in

depth in relation to the other two options. The ERP maintenance market is highly competitive

and complex due to IT consulting companies provide high skilled professionals, ERP experience,

and advanced tools similar to the vendor (Granebring & Révay, 2005). However, in many cases

the in-house consultants are supported by third-party consultants as well, so this means a

company is not limited to one source only (Markus & Tanis, 2000; Salmeron & Lopez, 2010;

Shehab et al., 2011).

2.6 ERP Maintenance Risks

2.6.1 What is Risk?

23

A risk can be described by several researchers that study risk management in different areas,

thus, it can have different definitions. One researcher on risk management, Carter et al. (1996),

defined a risk as an event triggered by a cause that creates an effect or consequence that cannot

be determined with certainty; per se, one risk may have several causes or a cause may have

several risks. In information systems, Elky (2006) defined a risk as a potential harm or

vulnerability derived from a process or factors that lead to a failure such that it can negatively

impact the IS. According to these authors, IS risk management is essential to understand,

respond, mitigate, and prevent risks that can destroy the integrity of the system which can lead to

an adverse consequence to the organization’s daily operations.

2.6.2 Definition of maintenance risk

According to Salmeron and Lopez (2012), a maintenance risk is an event that may or may not

occur in the activities of ERP maintenance which means it cannot be taken into account for

certainty and if it does occur it may cause serious damage. The authors described that

maintenance projects regularly have a high employee turnover which implicate a high risk to the

project as one major maintenance risk. There are numerous risks which are intuitively managed

as they occur. For example, a programmer may leave unfinished work and it will be time

consuming to replace or continue on their work by a new programmer (Salmeron & Lopez,

2012). In addition, Peng and Nunes (2009:2) provided the following definition of a risk that is

exclusive to the ERP post-implementation stage: “The occurrence of any event that has

consequences or impacts on the use, maintenance, and enhancement of the implemented ERP

systems.”

In the context of this study, the researcher has created the definition of a risk in ERP M&S as:

“The occurrences of events that can affect the quality of maintenance activities carried

out by third-party consultants.”

The established definition will be taken into account in the identification of risks faced by third-

party consultants when executing the ERP maintenance activities.

24

2.6.3 Summary of ERP maintenance risks in the literature

The literature about ERP maintenance risks is scarce and few researchers have focused on this

area. The extensive review on the literature has proven the huge gap that even Salmeron and

Lopez (2010) have stressed the lack of literature in this research area and have summarized risks

from other literatures that include all phases of the ERP life cycle. These two researchers have

cited Peng and Nunes 2009 study as being the only ERP post-implementation risks study

identified and that presented a risk ontology on a stage that includes maintenance. In fact, Ng et

al. (2003) conducted a study on how an ERP software modification is being performed which

precedes the ERP maintenance procedure and the ERP maintenance preparation stages in which

risks are forecasted and minimized in the preparation stage, but does not list the risks that may

occur when modifying the ERP system.

One significant study on ERP post-implementation risks is the one conducted by Peng and Nunes

(2009). The researchers identified 40 risks on ERP post-implementation phase in four different

aspects by extensively analysing the literature review. Thereafter, a study conducted by

Salmeron and Lopez (2010) identified 30 maintenance risks specifically to the maintenance

phase and classified them according to the maintenance phases such as analysis, design, and

implementation phases. Later on, Salmeron and Lopez (2012) analysed the risk impact of 34

ERP maintenance risks in order to help IT managers handle the risks more effectively, foresee

the consequences, and have a better control over maintenance projects. To summarize the ERP

maintenance risks, a cross-comparison of the risks identified in the three studies has been

performed. Similar or identical risks have been identified and summarized in the following table:

ID ERP Maintenance Risks

R1 ERP end users are reluctant/resistant to the system

R2 Unknowledgeable ERP maintenance team cannot support the end users

R3 Inappropriate IT infrastructure including hardware and software

25

R4 Poor documentation such as manuals and ERP know-how

R5 Lack of support from top management for the maintenance project

R6 Lack of training of ERP end users

R7 Unclear direction of the firm's strategy

R8 Poor establishment of the ERP's further development and quality standards

R9 Conflictive and non-cooperative ERP maintenance team members

R10 High turnover and loss of qualified ERP maintenance personnel

R11 ERP-related requests are not reported promptly

R12 Lack of support from the vendor

R13 Incorrect integration of the ERP modules

R14 Poor establishment of maintenance procedures

Table 2. Cross-Comparison of ERP maintenance risks (Peng & Nunes, 2009; Salmeron & Lopez, 2010;

Salmeron & Lopez, 2012).

As stated by Salmeron and Lopez (2012), there are very limited studies that have been published

in order to identify, address, or provide solutions to ERP maintenance risks. For this primary

reason, the study aims to identify the main risks that third-party functional consultants face when

performing the tasks of maintenance and support of an ERP system. The purpose is to fill in the

gap that is currently in place on this area and provide findings that will be useful for future

academic or industrial research.

2.7 Conclusion

According to the literature review, the ERP maintenance phase has not been explored in detail.

There is clearly a lack of research on ERP maintenance such as its risks. The dominant player in

the ERP market, SAP, is the ERP that the third-party consultants maintain and support all around

the world. When investigating on ERP maintenance activities, the researchers helped determine

the five ERP maintenance activity categories: ERP maintenance administration, ERP changes,

26

ERP user support, ERP enhancements, and ERP updates. The investigation of the risks for this

study will be conducted in those five activity categories.

The study will obtain results from actual SAP consultants performing M&S to different clients

from the standpoint of third-party consultants. Therefore, this study differentiates from the

previous studies, such as the ones by Salmeron and Lopez (2012) and Peng and Nunes (2009),

due to the risks are related to third-party consultants not from the users’ standpoint or the

organization that adopted an ERP system. As a result, the risks may be different or similar to the

ones described in the literature review. The summary of the 14 maintenance risks is only for

reference purposes and does not limit the study in any form. In fact, the wide range of risks from

various researchers will be used in comparing the findings.

27

Chapter 3. Methodology

3.1 Introduction

The methodology used for this study will be presented and described on how the data will be

collected, analysed, and reported in the study. For this reason, the inductive and qualitative

approach is discussed first. Then, the case study strategy is used for the case company. After, the

stages and outcomes will be discussed briefly.

3.2 Research Approach

For this study, it has been determined that the use of an inductive and qualitative approach will

be the most appropriate to use to find the main risks in ERP maintenance. The method of semi-

structured interviews will be used to interview third party SAP consultants (Creswell, 2003). In

order to increase the validation and avoid any misinterpretation of the most important and

common risks found in the interviews, a narrative analysis will be used together with concept

maps. The inductive approach is given priority to the qualitative aspect since there is little

information on risks in the literature. Furthermore, a triangulation method will be used to collect

different data from the two stages for finding results (Peng & Annansingh, 2012).

3.3 Case Study Strategy

According to Colorado State University (2012), a case study has been used by many researchers

to examine individuals or groups by using interviews, tests, writings, etc.; it is a form of

qualitative studies that triggers creative and innovative ideas by the participants. This is a main

reason why this study has chosen a case study strategy. Also, the fact that the researcher has

worked in the case company makes it easier to have access to the group of participants and

understand their experiences.

28

3.4 Case Company

Neoris is a worldwide business and IT consulting firm, it was born from the forward-looking

solutions it created for CEMEX in December 12, 2000, being this one of the world’s largest and

most remunerative producers of cement. Neoris is a subsidiary of CEMEX. The company set up

direct contact with their clients, in order to provide an improvement in their performance during

the whole process of their business. This company also offers practical and visionary business

solutions supported by their exclusive worldwide delivery model, simultaneously assisted with

cutting-edge IT services, leading to solutions that have been innovated, built, deployed and

operated by qualified IT professionals. Neoris is the largest Mexican IT consulting and Latin

America’s second largest. Neoris was also recognized in 2011 by the IAOP as one of the world’s

best providers of outsourcing services, as well, the company was granted as a Top Outsourcing

Leader in Latin America by the Global Services. Neoris has approximately 1,000 employees,

with profits of $100 million a year and with operating offices all over the world such as Mexico

City, Monterrey, Buenos Aires, Santiago de Chile, Sao Paulo, Rio de Janeiro, Madrid, and

Barcelona, having its corporate office in Miami (Neoris, 2012). In 2011, SAP (2012a) awarded

Neoris as a Global Service Parter.

29

3.5 Research Design

Figure 2. Stages and Outcomes

The first stage involves collecting literature review on ERP such as maintenance providers,

maintenance activities, and maintenance risks. Due to limited studies on maintenance risks, the

focus will be to find new data from SAP consultants currently working in M&S for a third-party.

The second stage uses semi-structured interviews to collect extensive data from 8 consultants.

The data will be transcribed in order to analyse the risks that were identified during the interview

process. A comparison analysis will be conducted with all the responses to determine a full list

of risks. The study aims to provide risks that are not found in the literature review as there are

few studies.

30

3.6 Data connection

3.6.1 Interview

According to Fox (2006), the use of interviews is extensively used for qualitative research and it

can have a high quality data collection if the interview design and interviewer’s skills are highly

elaborated. In addition, the author described an interview as an excellent data collection

technique which consists of verbal communication between the participant and the researcher.

Another researcher stated that interviews allowed people to express their situation from their

own personal opinion and freely discuss the topic being studied (Kvale, 1996). The study’s main

focus is qualitative so the verbal aspect is essential. As a result, the study will use the interview

method.

3.6.2 Types of Interview Approaches

Several researchers use different interview approaches depending on their type of research. Fox

(2006) described the three different types of interviews below:

Structured: Identical questions to every respondent and mostly have pre-coded responses;

this type is widely used for quantitative research.

Semi-structured: Similar to structured, as it has planned questions in advance but this are

open to further discussion or changes. Pre-codes are not possible as no answers are

known.

Unstructured: Focuses on very open ended questions or may sometimes not have any

questions but prepare them as the interview progresses based on certain topics.

31

The semi-structured interviews will be used for this study as it is the more effective type for the

research.

3.6.3 Design of Interview Questions

The first question will help the researcher understand what are the main activities conducted by

the participant. The second and third questions have been designed to obtain the risks in the ERP

maintenance administration category which question two deals with the administration of

requests and question three with the tools being used. Then, questions four and five are related to

ERP changes with four related to changes to the system and five deals with the testing of the

changes. The sixth question deals with ERP user support which is mainly about risks when

providing training to end users. The seventh question is focused on exploring the risks when

performing an ERP enhancement. Lastly, the eighth question focuses on ERP updates and their

risks.

3.6.4 Interviewees

The interviewees are all current SAP consultants working on a maintenance project for several

clients for the third-party consulting company Neoris. Initially, there were 10 participants but

due to a busy schedule one interview was left unfinished and another was never conducted. The

list comprises of 8 consultants:

Two IT Manager/Team Leaders

Two Sr. Consultants

Two Jr. Consultants

Two Analysts

3.6.5 Interview administration

32

The participants were in another country and had a different time schedule. The best way was to

set a time that was most convenient for them to log on to Skype. This software was used to

administer the interviews. Then, MP3 Skype Recorder, which is free software, was used for

recording the interviews which took from 50 minutes to 1 hour 20 minutes. Also, Word was used

to document the transcripts.

3.7 Data Analysis

The first step is to analyse the individual interviews one by one and identify the main risks in the

interviewee’s responses. The narrative analysis is the method used to analyse and report the

results and findings. According to Bold (2012), narrative uses a storytelling format to describe

the interesting responses and come up with a final product or elements. In addition, the author

mentioned that it triggers human sense by representing the actual experiences by a group of

people when being interviewed. In addition, Riessman (1993) stressed that narrative analysis is

valuable to discuss the stories of interviewees that are narrating a personal experience in their

lives. For this reason, the narrative analysis is an appropriate method for reporting the

experiences of the third-party consultants as shown in Figure 3.

33

Figure 3. Individual Discussion and Cross-Comparison Findings

At the end of each interview analysis, a concept map was created which summarized the risks in

each ERP M&S category. Those concept maps were used to create the final list of risks into a

summarized table. In addition, it assisted with the cross-comparison of risks identified by all the

consultants in a single category. The use of concept maps is common among researchers such as

in Peng and Nunes (2010b) study on the cultural impacts on utilizing an ERP system. In addition,

Peng and Annansingh (2012) studied post-implementation risks and developed concept maps

which were used to correlate and identify the risks more effectively.

According to Lanzing (1997), the analysis technique of a concept map is an old method

developed in the 60’s by Joseph Novak from Cornell University. Lanzing (1997) and White

(2011) defined a concept map as a form of representation of concepts, ideas, or knowledge which

can be networked or interlinked with each other for the purpose of assessing, communicating, or

organizing data information. For this main reason, concept maps were used to identify and

organize ERP M&S risks faced by the third-party consultants.

3.8 Summary

The method of inductive and qualitative approach is the most appropriate since the case study

requires interviews. In addition, the results will be significantly expressed in a narrative analysis

format which reflects the outcomes from the experience of industry experts. Concept maps are

used to summarize the risks which help in the organization of the extensive list of risks. The case

study of 8 SAP consultants from Neoris will be interviewed in the following chapter.

34

Chapter 4. Results and Findings

4.1 Introduction

In this study, the results and findings was divided into two sections respectively: discussion on

individual interviews and cross-comparison of multiple interviews. As explained in the

methodology chapter, the narrative analysis was used to report the results from the third-party

consultants as it explains the risks discussed by the participant and important quotes. In the

results section, concept maps will illustrate and summarize all the risks identified in each of the

five ERP maintenance activity categories after each interview. Thereafter, in the findings section

a complete table will be created with the use of all the risks identified by all the participants in

each category. In addition, a cross-comparison on the risks by all the participants will be

discussed in each category as well.

4.2 ERP Maintenance Activity Categories

According to the extensive research on the literature review, the main activities performed by

ERP maintenance consultants were analysed. This pertains to what ERP consultants need to do

in order to perform maintenance to the system and support to the end users. When end users raise

a maintenance request, it is related to these following categories:

ERP maintenance administration

ERP changes

ERP user support

ERP enhancements

ERP updates

4.3 Discussion of Individual Interviews

35

The individual interviews will provide a complete concept map with all the risks pertaining to

each of the five ERP maintenance activity categories according to a specific consultant. For this

reason, the risks that are discussed in each category have been transferred to a concept map in

order of appearance. This concept map will be used for the conclusion of each interview as it

summarizes the risks that the consultant identified in every category. The interviews were

arranged in the following order: IT Manager/Team Leader 1, IT Manager/Team Leader 2, Sr.

Consultant 1, Sr. Consultant 2, Jr. Consultant 1, Jr. Consultant 2, Analyst 1, and Analyst 2.

4.3.1 Interview One: IT Manager/Team Leader 1

In the ERP maintenance project, the IT Manager/Team Leader 1 described the main activities in

the job such as making sure that all the maintenance tasks by the consultants are executed,

administrating maintenance requests from several clients, following up on the team members in

order to keep the requests within the Service Level Agreement (SLA) and service quality

established with the client. Also, the IT Manager/Team Leader 1 is the main representative of the

consulting company; any issues between the users and the third-party consultants are escalated to

the IT Manager/Team Leader 1.

4.3.1.1 Risks in ERP maintenance administration

In the administration and control of user requests, the IT Manager/Team Leader 1 mentioned that

one main risk when administrating user requests is the wrong prioritization of maintenance

requests. This in fact can lead to negative consequences to the business as described below:

When a user request has been prioritized incorrectly, the operation of the business

can be affected. For example, if you are attending a request with a low priority,

but there is a high priority request that was not given that classification. That high

priority that is not being attended as such may stop the business operation, e.g.

invoices not being created, payroll not being made, or end-month activities may

36

be detained which are extremely important to the client (IT Manager/Team

Leader 1).

Due to this, the IT Manager/Team Leader 1 also stated that other risks may result from this

occurrence. For example, the users may view the maintenance team as not providing a high

quality service and users may lose trust on the maintenance team. The IT Manager/Team Leader

1 also mentioned that work overload is a main risk in this category which leads to consultants not

being able to keep up with all the requests and this can cause friction between the user and the

consultant. Another main risk is the lack of a good communication with the end user:

A user may be offshore, so if there is a bad communication the user gets a wrong

impression that the consultant is not attending the request. It is important to

establish a good communication in order to let the user know about your activities

and progress of their request (IT Manager/Team Leader 1).

The IT Manager/Team Leader 1 stated that unclear requests are common since there is always a

lack of information given on the request which may sometimes cause the consultant to work on

something that the user did not required. For this reason, a good communication must be

established after receiving the request.

Supporting tools to administrate the maintenance requests are important because they help the

consultants administrate and manage the requests more efficiently (Ng et al., 2003). However,

Salmeron and Lopez (2012) stressed the inadequacy of the maintenance administration tools as a

risk. The IT Manager/Team Leader 1 described the tools as having a lack of functionalities:

The tools used for the administration of requests do not provide functionalities

such as statistics, alerts, email linkage, monitoring of requests, status of request,

etc. If the tool is not efficient then the consultant wastes time in administrating the

requests and delays the response time (IT Manager/Team Leader 1).

37

4.3.1.2 Risks in ERP changes

The IT Manager/Team Leader 1 stated that an ERP change can have negative impacts on the

system:

A user wants to change a field on a report, but further up the line may not be

validated. The original design of the system may not permit the change. For

example, users can affect other users in different processes such as when a adding

an internal order field on a report However, there may be other ten users that use

the same report that did not require that change. The user may not know on the

validation of the specific change and consultants may not know about the change

requested and its impacts (IT Manager/Team Leader 1).

The IT Manager/Team Leader 1 described that when a change is being made there should

be a testing process established by IT governance. Salmeron and Lopez (2012) identified

the risk of lack of a test process. Also, if a change affects two modules there should be

users and consultants with expertise on both modules. If the change is performed

incorrectly it may stop the operation of the users. In addition, the test scenarios may be

missing when a change is performed.

4.3.1.3 Risks in ERP user support

The IT Manager/Team Leader 1 identified the first risk as the user not having a proper training

on the use of the ERP system processes:

38

A user may conduct a process in the system such as running a report. Due to not

having the proper training the user can be providing wrong information to its

suppliers because the user is executing a report with the wrong parameters (IT

Manager/Team Leader 1).

For this reason, the consultants should have knowledge of the internal business process in

order to assist the user with that type of training. The system will not tell the user that

those parameters may be wrong. The consultant should train the user on different

scenarios.

4.3.1.4 Risks in ERP enhancements

The IT Manager/Team Leader 1 stated that most of enhancements are handled by Sr. Consultants

as the impacts should be analysed in detail as it can affect many processes. The experience is

essential in working with enhancements to prevent risks:

When an ERP does not meet all the user expectations, an enhancement will help

improve the system. The risks are similar than those in ERP changes but in a

greater scale. Risks may arise that is why time and effort in evaluating the

enhancement is required. The enhancement’s design should be developed in detail

as a wrong design may make the enhancement fail or exceed its time schedule (IT


For this reason, a risk is the incorrect design of the enhancement. Also, due to the lack of

knowledge of the system or internal business processes by the consultant an enhancement

may not be necessary as it may sometimes be solved by standard processes not known by

the consultant.

39

4.3.1.5 Risks in ERP updates

The IT Manager/Team Leader 1 stressed that an update is a major change in the system. The

users may sometimes require additional training on new functionalities or features. The risks

may be as simple as someone may not operate a report or as complicated as it can stop the

operation of the business. An extensive testing plan is performed by the IT consultants involved

with the upgrade. In addition, the tests are done extensively in testing environments or a

production environment duplicate “sandbox”.

The IT Manager/Team Leader 1 stated that the main risk is that updates mostly affect

customizations such as new tables, new reports, new business transaction, new programs, etc. but

can also affect standard processes. The vendor provides OSS Notes to fix these errors.

Consultants may need to fix or re-work on customizations. In some cases, a risk may be the lack

of documentation on customizations.

4.3.1.6 Conclusion

40


The risks identified from the IT Manager/Team Leader can vary from other consultants as the

administration of requests is major role in his position. The focus is clearly on that area as he is

more knowledgeable and deals with administrating, handling, and coordinating requests. One

main risk that pertains to the role as an IT manager is the work overload. That risk should be

prevented with a good management of the resources and coordinating the right assignment of

requests to the team. The IT Manager knows all the risks in all the activities due to past

experience as a consultant. In conclusion, the IT Manager needs to make sure the team provides

a high quality system by preventing and mitigating these risks.

4.3.2 Interview Two: IT Manager/Team Leader 2

41

The IT Manager/Team Leader 2 represents the IT consulting company and is the first contact

between the IT Manager of the client and the third-party company. Also, the IT Manager/Team

Leader 2 is responsible of coordinating a team of consultants in order to clarify any specific

cases with the users, comply with the procedures established with the client, and attend the

priorities of the end users.


The IT Manager/Team Leader 2 stated that prioritization of a user request is very important for

the consultants as a high priority request requires assertive and immediate attention since it may

affect the daily operations of the business. Another major risk identified by the IT

Manager/Team Leader 2 was that of the saturation of work:

The saturation of work on the maintenance team may be caused by not solving the

root-cause of a major problem which in turn raises many duplicated requests

related to that same problem (IT Manager/Team Leader 2).

In relation to user education, Salmeron and Lopez (2012) classified the lack of training by end

users as a risk in maintenance. The IT Manager/Team Leader 2 mentioned that users are not

being trained on the different types of maintenance requests such as a system error, user support,

change request, enhancement, etc., and cannot differentiate between requests:

There is a need for IT governance by the client to define the different types of

maintenance requests. The consultant is able to change a type of request if it is

aligned with the IT governance. For example, a request was classified as a system

error by the user, but the consultant evaluated the request as a change request. A

system error can affect the operation of the system while a change request deals

with improvements or system changes that are not urgent (IT Manager/Team

Leader 2).

42

The IT Manager/Team Leader 2 described the administration tools as complicated since

consultants should perform many steps on the tool, e.g. a change request requires several

approvals that need to be managed inside the tool and there is a huge amount of emails sent to

the team about all the requests. This causes a waste of time since the consultant needs to be

checking the tool frequently. It can be inferred that there is a lack of functionalities in the tools.


The IT Manager/Team Leader 2 stated that a small process may impact a bigger process due to

the testing missed all the possible scenarios:

The user is just part of a process and cannot see the big picture of the process. It

occurred in the Finance Transformation in Company A which impacted

production environment. There should be process owners that can be interviewed

by consultants in order to understand all the scenarios and evaluate risks. A

validation rule on an account was created in the system where it affected postings

from an external system (IT Manager/Team Leader 2).

The lack of test scenarios is a main risk when testing a change. First, consultants need to

test and the user should have the whole context of the business process and able to accept

the testing or re-test.


The IT Manager/Team Leader 2 stated that users are curious to know more functions of the

system. In some cases, user request training on transactions that they do not have authorization:

43

Users may request training on a business process but in fact it does not pertain to

the user’s area. The consultant can provide the training without knowing that and

it means that improper training to the users was given, Therefore, the training

should be given according to the department and business processes that the user

run and according to a user level, not being too technical (IT Manager/Team

Leader 2).


The IT Manager/Team Leader 2 expressed that enhancements have a high control by IT

committees since they are costly:

Every department should request its director to assign budget to an enhancement

required by the area. An enhancement can sometimes run out of control and a

small enhancement such as a new report can turn into a project. The risks

associated with this are that the enhancement exceeds in time and cost. (IT


That is why a good design and evaluation study is conducted before its implementation.


The IT Manager/Team Leader 2 mentioned that the vendor creates a list of the critical processes

that the update will impact. Thus extensive testing is performed in every environment to prevent

any issues. There are not many issues if the tests are conducted before the update and issues

fixed accordingly:

44

Processes may stop working or transactions may be doing improper procedures.

However the vendor publishes all the notes in order to fix any errors, bugs, or

issues. If the solution is not available the consultant contacts the vendor which

gets a rapid response time. The main risk is affecting customizations as the vendor

does not support them (IT Manager/Team Leader 2).

45

4.3.2.6 Conclusion


The IT Manager/Team Leader 2 stressed the importance of fixing root-causes of problems to

avoid repetition and duplicated requests from users. In addition, the tools for administrating

requests are not efficient and create a number of risks in the ERP maintenance administration

category. When dealing with enhancements, she has to make sure it is completed on schedule.

4.3.3 Interview Three: Sr. Consultant 1

The Sr. Consultant 1 assists the end user with the evolution of the system, fixes any system

errors, or provides the maintenance tasks that allow the user to successfully operate the system.

46

The experience on the system can be transferred to the end user and help maintain the best

practices recommended by the ERP vendor.


The Sr. Consultant 1 stated that any request is seemed as a priority for the user. However, cases

that stop the operation should take precedence to other requests. The Sr. Consultant 1 described

that sometimes a failure to meet the Service Level Agreement occurs when:

There is a high priority that requires immediate attention, but cannot comply with

the SLA since it may take hours or even days to complete even if it affects a

whole department. In addition, the users may think it can all be performed in a

short time or perceive that the consultant does not know how to solve the case (IT


For this reason, the consultant needs to explain the request, describe what will be done, and keep

in constant communication with the user. This is done to avoid the risk of miscommunication of

the requirements (Salmeron and Lopez, 2010).

The Sr. Consultant 1 described that the administration tools can be complicated and consultants

do not have full knowledge since each client has different tools:

A client may be accessed through a VPN which makes it complicated as you

cannot be connected with other clients at the same time. There was once an issue

where an administration tool erased the database on all the requests for the client.

Also, there are different tools for one client. These tools need to be linked since

one is for a change request, another for tracking the change, and a third for testing

(Sr. Consultant 1).

47


The Sr. Consultant 1 discussed a major issue that occurred with change requests in a company:

In Company A, a consultant clicked on an incorrect option to move a change

request into the production system which cause to move all old transport into the

production environment and a big list of reverses were needed (Sr. Consultant 1).

In addition, the Sr. Consultant 1 stated that changes should be validated by the person

responsible of the business process. Users may sometimes request a change in a report but that

user was not the business owner. Therefore, it affects other users. Also, changes should be

evaluated when there is a high rate of usage of that process in a specific time where it does not

affect any critical operations. Furthermore, the Sr. Consultant 1 mentioned that some consultants

may not know about the change being requested. Another important point, is not considering all

the test scenarios:

A change is now in production system but the user brings a new case scenario

which was not considered. Therefore, all the variables should be analysed in the

testing process. In some cases, the scenarios are limited to single parameters or a

single user. In Company A, a case scenario was considered for a single user and

not multi-user which other users could not access the transaction simultaneously

(Sr. Consultant 1).


48

The Sr. Consultant 1 mentioned that you can provide training on the processes or transactions

conducted in the system but cannot provide internal business process training:

Let us suppose that this field is about the type of payment, e.g. cash, debit card,

check, and the user needs training on how to use and what to select. The

consultant does not have the knowledge of the internal business processes as the

partners or suppliers may require only a specific type of payment. Consultant

provides improper training (Sr. Consultant 1).

The user may think that the consultant provides the entire processes of the system, but

instead it may require a co-worker that is in his department to provide the internal

business process training.


The Sr. Consultant 1 mentioned that an enhancement can sometimes be fulfilled by a standard

transaction but the consultant is not knowledgeable:

An enhancement was requested by the user and the consultant is working on the

analysis but lack of knowledge and experience blocks the consultant on standard

solutions such as activating a new module or standard configuration (Sr.

Consultant 1).

Another main risk related to enhancements is that it may exceed time since user can come up

with new scenarios or functionalities.


49

The Sr. Consultant 1 stated that when updating to a new ERP version the vendor is really helpful

in providing all the information about the update. When asked about customizations, the Sr.

Consultant 1 said the following:

When an ERP is at the final version many processes are left untested and it may

have new errors that have not been resolved by the vendor. Customizations are

affected. For example, customizations may be using a table that the vendor

changed or no longer uses so it will affect the client’s customization. It is easy to

analyse the main processes or objects that will be impacted by the update since

the vendor provides full detail of tables, structures, fields, etc. Newer modules are

the most impacted by updates. It can also lead to modules being stopped

completely (Sr. Consultant 1).

50

4.3.3.6 Conclusion


The Sr. Consultant 1 stated that all the risks are better managed with experience. When

conducting tests, it is important to test all the scenarios in order to not affect any system process.

Also, the greatest numbers of risks were identified in the first category ERP maintenance

administration. The Sr. Consultant 1 deals more with enhancements as being the consultant with

the most experience and also in providing training to the end users on complicated processes,

Therefore, the risk on lack of knowledge of internal processes is important.

51

4.3.4 Interview Four: Sr. Consultant 2

The Sr. Consultant 2 follows the rules and guidelines established with the clients in order to

provide M&S services on a timely manner with high quality. End users experience problems at

the time of performing their processes, as a support team, we provide solutions such as a new

functionality, development, or process in order to fulfil a new requirement.


In relation to a user request, the Sr. Consultant 2 explained that the lack of information on a user

request is the most popular risk that consultants face. As a consequence, the consultants cannot

understand the request as mentioned by Salmeron and Lopez (2012) and deliver a wrong solution

to the user who then loses credibility. In other words, the maintenance team provides low quality

service which can have the negative results of losing the account. Also, the Sr. Consultant 2

mentioned that the wrong assignment of requests is a frequent problem with no big issues unless

it is a high priority.

Furthermore, the Sr. Consultant 2 described why there is work overload:

If the team has one or two consultants who have a lot of experience, work

overload is caused by the user who only wants to deal with them and not with the

rest of the staff (Sr. Consultant 2).

The Sr. Consultant 2 mentioned that dealing with different clients requires managing different

tools:

Each tool has its own change management process and it becomes confusing for

the consultants. Different rules apply to each client and it is hard to know all the

timings on SLA, tools, or business processes. In fact, the user keeps track of the

service delivery agreement which included documenting the incident’s history.

52

Consultant may provide the solution on time, but if failed to document it will not

reflect the action (Sr. Consultant 2).


A main common risk is the failure to document a change request. The Sr. Consultant 2

mentioned that the change should be properly documented with information such as why the

change was requested, nature of the change, who requested the change, and when it was

implemented. The Sr. Consultant 2 described that there is the risk of affecting other users:

A change can be viewed by other users as an issue. Then they will create a

maintenance request probably with a high priority. A different consultant may not

be aware that the change was conducted previously by another consultant. The

consultant may also think it is an issue and if it is in month-end close it will be

treated as high priority (Sr. Consultant 2).

The Sr. Consultant 2 stressed that a main risk when testing changes is the lack of test scenarios

and lack of knowledge of both parties. However, the users and consultants share blame as both

need to work together to consider all the test cases. If missed it may generate changes to a

functional specification or re-programming. The lack of information in testing environment is a

common risk:

Four months ago, there was a case where exchange rates in testing environment

(Quality System) were missing which resulted in successful tests. However, when

the change was transported to production environment, where exchange rates are

complete, the change did not work. Programmers had to modify the program

which took several days to modify (Sr. Consultant 2).

53


The Sr. Consultant 2 stated that some users can have bad intentions when asked about a specific

field. For example, the user found a field that does not need but if not used it can affect further

processes. In addition you may provide improper training by directing training to one direction:

In one specific case, I followed the user on how to pay to a vendor with the

standard functionality. It turned out that they had an external system to make

payments so the training was inappropriate for the user (Sr. Consultant 2).


The Sr. Consultant 2 mentioned that he is often involved with enhancements and main risks are

the wrong design and lack of knowledge of the consultant:

A simple development can become a “monster” and can get out of the hands of

the consultant. A wrong definition can lead to major problems when developing

the enhancement. If not well designed, documented, tested, can lead to exceeding

its planned time and can be a waste of money (Sr. Consultant 2).


The Sr. Consultant 2 stated that when updates are conducted an extensive plan for testing is

conducted for every object in the system such as interphases, programs, tables, fields, screens

etc. The mains risks identified were that customizations such as user exits, field exits, new tables,

or new programs. Consequences can lead to shipments or payments not being made. It is

necessary to review the impacts and test all the affected objects impacted.

54

4.3.4.6 Conclusion


The Sr. Consultant 2 stressed that by providing a low quality service that can be a result of other

risks such as lack of knowledge form the consultants or the administration tool is not helping in

the service of the client. A negative consequence impacting the entire third-party firm can be

losing a client. Also, in dealing with enhancements, the third-party needs to keep the established

schedule.

4.3.5 Interview Five: Jr. Consultant 1

The Jr. Consultant 1 provides support 24/7 to the different clients and different versions of SAP.

Support with end user requests, improvements, enhancements, and move-to-support projects

from new clients.

55


Any request is always a priority for the user. For this reason, the Jr. Consultant 1 mentioned that

the validity of the priority should be made to confirm its severity. Also, users cannot differentiate

a normal request such as a failure of the system from an enhancement:

Consultants need to identify if what the user is requesting can be done with

standard configuration and no need for new programming code. In fact, a normal

request should be completed in 40 business hours if not it needs to be considered

as an enhancement (Jr. Consultant 1).

In addition, the Jr. Consultant 1 stressed that wrong assignment and work overload are

two common risks that occur mostly in the month-end close. Requests increase in high

peak operations of the system and consultants can have many requests at the same time.

Also, wrong assignment of requests is linked to the miscommunication between

consultants of different modules.

The risks related to the tools used in ERP M&S were also addressed by the Jr. Consultant 1:

If there will only be one tool for all the clients it will be easier to administrate the

requests but consultants need to switch from one tool to another. Training new

consultants on all the tools can be confusing. In some cases, a VPN is required to

connect to the client’s system (Jr. Consultant 1).


A common risk when making a change is that a change can impact other users, processes, or

modules. For example, the Jr. Consultant 1 stated that a change can affect a table or a table that is

being used by another development. In addition, the lack of information in testing environments

56

is also discussed by the Jr. Consultant 1 as the systems in different environments are not always

consistent.

Consultant needs to generate master data in testing environments. In addition, the

test scenarios can be affected by this. As well as, not considering all the scenarios

but the consultant should be able to ask about the case scenarios and “think out of

the box”. The user may sometimes not have the knowledge of what is being tested

or vice versa (Jr. Consultant 1).


It is easier to provide training to an experienced user because that user knows the internal

processes:

A new user regularly does not know the system and the internal processes. The

consultant should be trained on the internal business processes in order to provide

a proper training. Also, you cannot assign an analyst to provide the training since

if conducted the analyst may not respond to all the questions and user loses

credibility and there is wrong or a lack of documentation to reference (Jr.

Consultant 1).


The Jr. Consultant 1 stated that enhancements are costly:

A new user can request a new report which can cost $5,000 dollars and this is

where the administration is in charge of evaluating the cost-benefit analysis. The

57

report required can be fixed manually in Excel and so it may not be valid since

there is no added value to the business (Jr. Consultant 1).

Enhancements can exceed time due to missing scenarios or user requests new

functionalities or the design was not complete. As a consequence, a programmer may

take more time.


The Jr. Consultant 1 stressed that an update such as a support package requires a script that

includes all the required transactions that should be tested:

A consultant should have tested all the processes in development, and quality

testing systems in order to pass on to production. This does not mean that

everything will work correctly. Issues occur which can be escalated to the vendor.

The vendor may take a day or more but if the operation is stopped there is the

need to fix it immediately with a workaround (Jr. Consultant 1).

58

4.3.5.6 Conclusion


The Jr Consultant 1 identified the main risks to be in the ERP changes as the lack of test

scenarios may cause errors to the system. Also, lack of data for testing environments is critical

for providing a better understanding of a change in the system. The escalation of requests are

common when performing an update and mentioned that they provide a good service.

4.3.6 Interview Six: Jr. Consultant 2

The Jr. Consultant 2 provides support services such as knowledge transfer of ERP business

processes, satisfy the client’s needs, and work on new requirements.

59


The Jr. Consultant 2 started the discussion of risks by saying that the users do not know the

differences between the types of maintenance requests. Also, the users are not well trained on

prioritization but some do know by experience. A user may say that a process is not working but

it can be a simple parameter that is not being inputted correctly. This can also be part of internal

business processes specifically to the client:

In some cases, the consultant does not know the internal processes of the client.

Although an ERP is mostly standard some customizations are made specifically to

the business. The users may not know the processes due to a lack of training and

documentation (Jr. Consultant 2).

Similarly, Salmeron and Lopez (2012) and Peng and Nunes (2010) identified the risks: lack of

training of end users and the poor documentation on ERP. The Jr. Consultant 2 mentioned that

the tools are very helpful in administrating the requests. However, if a consultant is assigned to

different clients it tends to cause confusion when managing the tools and each client have

different guidelines.


The Jr. Consultant 2 stated that a change request such as a system configuration may lead to the

failure of the system due to the consultant’s lack of knowledge on what the change may impact:

The user requested a field to be mandatory but the consultant followed through

without checking or knowing other processes that are linked to that business

process. As a result, an automatic process did not required that field to be

obligatory, so the system fails (Jr. Consultant 2).

60

Furthermore, the lack of test scenarios is a common risk identified by the Jr. Consultant

2. The consultant should have the knowledge of the scenarios as the end user regularly

trusts the consultant when making a change to the system. It is important to define the

scope of the change. When asked about the lack of information, the Jr. Consultant 2

explained that the data in different environments is never consistent as the system is

changing every second.


When providing training, the Jr. Consultant 2 stated that it is essential to establish real case

scenarios to provide a proper training:

When operating the system, users are experimenting with the system. Some users

ask training on processes that are not configured in the system; in turn, the

consultants advise on alternatives such as configuring that option or may provide

improper training when not noticing that the client does not have that

functionality (Jr. Consultant 2).

Furthermore, the Jr. Consultant mentioned that there is no proper training manuals to

show the user.


The Jr. Consultant 2 stated that sometimes a user requires an enhancement which does not create

a benefit for the business:

First, a AS-IS is shown to the user. Then, a TO-BE where sometimes the user

makes changes to the design or does not want that enhancement anymore and is

being cancelled. The analysis requires time and cost as the consultants should bill

61

the hours to the client even if it is only the analysis phase. User do not have the

knowledge to understand what are the implications of an enhancement as think it

can be done in less time and may sometimes not bring any benefits (Jr. Consultant

2).


The Jr. Consultant 2 stated that there may be failures in functional or technical sides. In addition,

there are several risks that occur due to the lack of testing:

Testing is an essential task when updating a system. A list of impacts should be

verified so that the processes are clearly identified. This will prevent the system to

operate without failing any processes which due occur. Not knowing what the

update can affect in the system can cause a process to fail. Customizations may be

affected so it is essential to have a backup to reverse to the previous version in

case update fails and generate dump errors. Escalating to vendor is a solution (Jr.

Consultant 2).

62

4.3.6.6 Conclusion


The Jr. Consultant 2 identified the most risks in the ERP changes category as he mentioned that

it is the one he deals the most. In addition, the risks related to administration are because of the

complicated tools used for every client.

4.3.7 Interview Seven: Analyst 1

The Analyst 1 helps the end users on running business activities related with the ERP system

such as configuration changes and provide new business solutions.

63


The Analyst 1 mentioned that being the least experienced maintenance member the risks may be

greater. When the procedures are well established the priority of the requirements is not a risk.

The Analyst 1 stated that many risks may arise from workload and lack of knowledge:

The lack of knowledge may lead to a misunderstanding of the requirement or

deliver a wrong solution. The excessive work can conflict with the SLA and

create a bad communication with the user. Thus, the user will lose credibility and

think that the service is not in accordance to the policies and contract (Analyst 1).

Clearly, the management of different tools is a complicated task performed by the Analyst

1which may cause failure to meet the SLA and increase response times:

Consultants must learn all the different complicated tools. These are linked to the

SLA of the client which may fail to comply. For example, a change to the system

may be rejected due to an error inputted in the tool (Analyst 1).


The consideration of the scope and impacts of a change must be evaluated as stated by the

Analyst 1:

By not considering the scope and impacts, an inconformity by other users may

arise as a change may impact their processes. The consultant may not be aware

that it was affecting other processes or users (Analyst 1).

64

In addition, the Analyst 1 stated that the lack of documentation on previous changes can

lead to a wrong administration of future changes or re-working may be extremely

difficult. The Analyst 1 stated that a main risk is that of lack of test scenarios:

All the test scenarios should be considered to prevent failures in the production

environment. In production, a user may encounter that a process was executed in

several ways that were not tested so the change is not working completely and

needs another change request in the system (Analyst 1).


The training to user may be improperly conducted:

The data in a testing environment is used to provide a training to the user but this

environment may not have all the data to generate the real case to explain the

entire process. In addition, this cannot be done in production unless the training is

done to execute a current business process that the user needs. In addition, the

how’s provided and manuals created for the users must not be technical and easy

to understand (Analyst 1).


The risks faced in working with enhancements are:

The lack of knowledge of the enhancement that has never been carried out can be

difficult to estimate its duration and cost. Also it is hard to conduct a feasible

study to determine if the enhancement will bring benefits to the client. When

65

creating the functional specification a wrong estimate and design can be provided.

As an analyst, the experience from the Sr. is required (Analyst 1).


The Analyst 1 stated that the consultants assist in the testing of all the core processes before any

update is performed:

The risks can be related to processes that are not standard since this can be the

most affected by an update. Also, the vendor does not provide support for errors

dealing with customizations. This is why a test plan is of great importance to the

business in order to detect errors or changes in transactions that are not standard.

The main risk can be the lack of documentation needed to fix the customizations.

(Analyst 1).

66

4.3.7.6 Conclusion


The Analyst 1 stated that most risks are in the ERP changes category as he deals with more

requests such as changes in displays, reports, or configurations on a daily basis. In addition, the

tools for the administration of requests are too complicated and there are different tools for each

client which generates confusion.

4.3.8 Interview Eight: Analyst 2

The Analyst 2 main role is to support the client with configuration changes, help when change

requests or not routing correctly to the managers, or assist the user with any questions.

67


The Analyst 2 described three main risks such as wrong prioritization, wrong assignment, and

lack of information that affect the administration of requests:

Users raise requests with high priority even if it is not an urgent request or just

affecting one user. Also, the Service Desk or end user assigns the request to a

wrong team due to a lack of knowledge on the area. User does not follow up when

consultants need more information in order to solve their request (Analyst 2).

The Analyst 2 explained that the administration tools are so complicated and have many steps for

a single activity that when invalid it needs repetition. Also, the lack of functionalities was

discussed such as not sending live notifications on the status of a request.


The Analyst 2 classified the main risk when performing a system change it may impact the

functionality of a specific process:

In the Human Capital Management side, the risk might take effect on a dynamic

action that involves a set of predetermined infotypes with a specific logic. Other

risk is that the new configuration will impact indirectly other configuration of the

ERP; that is why any change requested by the end user needs to be reviewed

before starting to work on it (Analyst 2).

Also, the Analyst 2 stated that a change in the system may impact the system and may stop

specific processes. This is a result of a lack of proper tests which may lead to user not

understanding the tests for the change.

68


The Analyst 2 classified the main risk when providing training to be:

Some of the risks are that users are not prepare to receive a great amount of

information because they are stubborn or/and refuse to embrace new technologies.

Also when user never handles a computer or do not have the proper training on a

similar technology the training and knowledge transfer becomes very difficult

(Analyst 2).

Also, Salmeron and Lopez (2012) described a main risk to be that users are reluctant to use the

system.


The Analyst 2 stated that as an analyst with less experience he does not usually work with

enhancements but have assisted the Sr. Consultant:

The main risk when creating a functional specification is that the user not always

know what they want or continuously want more changes derived from the main

issue, but not always the changes have consistency which can make an

enhancement take longer than expected (Analyst 2).


When conducting an ERP update, the Analyst 2 stated that:

69

The main risks are that production activities can be impacted by system failure

and the company will not be able to meet the production or other operational

goals. Also, there exists the risk that the updates contain inconsistencies with the

current version of the ERP and the patches will not help at first not even with the

standard processes. Therefore, the team in charge of the update will have to work

extra time to fully prepare the ERP for the update (Analyst 2).

4.3.8.6 Conclusion


In summary, the Analyst 2 stated that users are reluctant to the system and that do not know how

to use the system. Even a maintenance request is done with lack of information which is a risk

70

when dealing with requests. Analyst 2 has assisted with enhancements but does not know a lot of

the implications.

4.2 Cross-comparison of Multiple Interviews

A cross-comparison was made on each of the five ERP maintenance categories to summarize the

findings and reflect the risks from all the participants and limited researchers. Since the study is

inductive and no identical study has been conducted before, the findings are mainly based on the

data collected in this study’s results.

ERP M&S Activity

Categories Risks in ERP Maintenance

ERP Maintenance

Administration Wrong prioritization of maintenance requests

Maintenance team provides low quality service

Work overload

Lack of good communication with the end user

Lack of information on the maintenance request

Tools for administrating requests lack functionalities

Waste of time when using administration tools

Duplicated requests raised by end users

Users cannot differentiate between the types of maintenance requests

Administration tools are complicated to use

Fail to meet Service Level Agreement (SLA) (completion time according to the

priority)

Consultants lack of knowledge on different administration tools for each client

Unknowledgeable ERP maintenance consultants

Losing a client

Wrong assignment of requests

Consultants fail to document incident’s history

Miscommunication between consultants

Lack of training of users

Poor documentation on ERP processes

ERP Changes Managers do not validate the change request

System does not permit the change

ERP change affects other users

Inappropriate test process

Consultants have no knowledge on the change

71

Lack of test scenarios

Changes may affect other processes/modules

Failure of documenting a change

Lack of data in testing environments

Failure of the system due to a change

Lack of documentation on previous changes

Users lack of training

Consultants lack of knowledge on internal business processes

ERP User Support Users lack of training

Consultants lack of knowledge on internal business processes

Incorrect training provided by consultants

Manuals are too technical

Lack of documentation such as manuals

ERP Enhancements Incorrect design of the enhancement

Inexperienced consultants working on an enhancement

Enhancement exceeds planned time

Enhancement exceeds initial cost

ERP Updates Updates affect customizations

Updates affect standard processes

Lack of documentation on customizations

Escalate issues to vendor

System processes fail

Lack of testing

Table 4. 47 Risks on ERP M&S

4.2.1 Risks in ERP maintenance administration

It is of great value to mention that the participants in the study had similar experiences and risks

may be the same. For the administration, all of the consultants agreed that the tools are difficult

to use, complicated, and lack functionalities. This generates negative consequences such as not

complying with the Service Level Agreement which is the time they need to complete a request

and respond to the user. In addition, a wrong prioritization of requests is a major risk since it

prevents the consultants from providing solutions adequately to the severity of the request. It

determines the timing that be allocated to a request. In addition, several consultants such as Jr.

72

Consultant 2 and Sr. Consultant 1 mentioned that users think everything is urgent. Time is

wasted in using the administration tools. Work overload is a big one as the consultants have

different clients.

4.2.2 Risks in ERP changes

The most important risk identified here is that a change performed in the system can affect

further processes, modules, or other users. In addition, as mentioned by IT Manager/Team

Leader 1 the consultants may not know what are the implications of a change and how it can

affect the system. Also, the consultants stressed the importance of testing when making a change

to the system. Lastly, the test process is sometimes not well established and the test scenarios are

impossible to identify all.

4.2.3 Risks in ERP user support

In this category there are not many risks as providing training to the user is a risky category. The

only major risk identifies is the lack of internal process knowledge of the consultants. Also, it is

difficult to know this due to dealing with several clients and each from a different industry. The

processes and tools are different. Another main risk is the lack of proper documentation such as

training manuals.

4.2.4 Risks in ERP enhancements

Enhancements can turn into big projects according to the participants. In addition, time and

money can be wasted in the evaluation or creation of an enhancement when not well designed.

The enhancements are worked by experienced consultants only. Extensive testing plans are

needed here to avoid any system failures or impacts on customizations.

73

4.2.5 Risks in ERP updates

According to the participants, updates should be handled with care and testing is a major part of

them. The vendor can assist them with any issues. However, for customizations the consultant

should take responsibility to fix them.

74

Chapter 5 Conclusion and Recommendation

5.1 Conclusions

The study has created a list of 47 risks which have identified the most number dealing with the

administration of maintenance requests followed by ERP changes. This are the most common as

ERP changes are performed on a daily basis to fix errors, or simply change a configuration in the

system that is necessary for the daily operation of a business. As mentioned in the literature, user

support is high at the beginning of the post-implementation phase and tends to decrease after

time. There was found that there are no major risks involved with the ERP user support and has

no major impact. ERP maintenance administration is a risky category since the case study was on

a third-party so this is quite important in order to comply with the regulations and contract with

their clients. In addition, it is essential for providing a high quality service to the users. The risks

will serve as a starting point for future academics that would like to study the risks encountered

in ERP M&S.

5.2 Recommendations

By studying the risks identified, there is clearly a lack of a proper administration of user requests

in third-party consulting companies. Also, risks may affect the perception of the client and

perceive that consultants do not provide a high quality service. However, the risk of work

overload can be the reason of not providing a better service. In addition, the risks identified in

the study can help other researchers or professionals understand what risks can be mitigated and

create a risk management strategy. A better understanding of risks in the maintenance phase is

one major contribution to the IS field. In summary, there needs to be more research on the area to

help practitioners better understand the implications of working or supporting an ERP system.

ERP projects may fail in this phase so it is essential to maintain high standards and service to

keep an operable system.

75

5.3 Limitations

There were certain limitations to this study which are discussed below:

The case study included functional SAP consultants working on a third-party consultant

(Neoris) which limits the results to the experience in one company. However, the clients

service many different clients from different industries. Also, this imposes a limitation as

the risks can be different if consultants attend one client only or several clients.

The ERP maintenance activity categories are the same for all the modules even if the

participants were from three modules only. However, there can be slight differences from

respondents from different modules.

The participants work for a Mexican IT consulting company which provide services to

clients headquartered in US and Mexico. This may limit the study geographically.

The number of participants and time constraint can limit the study’s outcomes.

The interviews were conducted in Spanish and English depending on the participant’s

preference. The Spanish interviews may be a limitation due to the translation of the

responses.

5.4 Future Research

Due to a time limitation, the study had to be exclusive to a small group of SAP third-party

consultants to find the risks when maintaining and supporting an ERP system. However, it is a

valuable asset to the area as it is extremely limited. The risks faced from third-party consultants when

performing their main activities are clearly different from the ones in implementation projects or

76

analyzing it from the user or client’s perspective. The study can be used as a reference for future

research and hope to have created a list of 47 risks in the ERP maintenance and support phase of the

post-implementation stage.

Word Count: 14976

77

Bibliography

Accenture. (2009). Gartner Positions Accenture in the Leaders' Quadrant for ERP Service

Providers, Europe [Online]. http://www.accenture.com/us-en/Pages/insight-gartner-leaders-

quadrant-erp-providers-europe.aspx [Accessed 5 May 2012].

Carter, B., Hancock, T., Morin, J. & Robins, N. (1996). Introducing RISKMAN The European

Project Risk Management Methodology. London: The Stationery Office.

Al-Mashari, M. (2003). “Enterprise Resource Planning (ERP) Systems: A Research Agenda”.

Industrial Management & Data Systems [Online], 103, 22–27.

http://www.emeraldinsight.com.eresources.shef.ac.uk/journals.htm?issn=0263-

5577&volume=103&issue=1&articleid=850108&show=html [Accessed 12 May 2012].

Al-Mashari, M. & Zairi, M. (2000). “The Effective Application of SAP R/3: A Proposed Model

of Best Practice”. Logistics Information Management [Online], 13(3), 156–166.


6053&volume=13&issue=3&articleid=852121&show=html [Accessed 5 May 2012].

Barton, P. (2001). Enterprise Resource Planning Factors Affecting Success and Failure

[Online]. St. Louis, Missouri: The University of Missouri.

http://www.umsl.edu/~sauterv/analysis/488_f01_papers/barton.htm [Accessed 28 April 2012].

Bold, C. (2012). Using Narrative in Research. London: SAGE Publications Ltd.

CBR. (2011). “ERP Market to Grow to $50.3bn in 2015: Forrester”. CBR [Online], 6 May.

http://enterpriseapplications.cbronline.com/news/erp-market-to-grow-to-503bn-in-2015-

forrester-060511 [Accessed 11 May 2012].

Colorado State University. (2012). Writing Guide: Case Studies [Online].

http://writing.colostate.edu/guides/research/casestudy/ [Accessed 11 May 2012].

http://www.accenture.com/us-en/Pages/insight-gartner-leaders-quadrant-erp-providers-europe.aspx

http://www.accenture.com/us-en/Pages/insight-gartner-leaders-quadrant-erp-providers-europe.aspx

http://www.emeraldinsight.com.eresources.shef.ac.uk/journals.htm?issn=0263-5577&volume=103&issue=1&articleid=850108&show=html




http://www.umsl.edu/~sauterv/analysis/488_f01_papers/barton.htm

http://enterpriseapplications.cbronline.com/news/erp-market-to-grow-to-503bn-in-2015-forrester-060511

http://enterpriseapplications.cbronline.com/news/erp-market-to-grow-to-503bn-in-2015-forrester-060511

http://writing.colostate.edu/guides/research/casestudy/

78

Creswell, J. (2003). Research Design: Qualitative, Quantitative, and Mixed Methods

Approaches, 2nd

ed. SAGE Publications, California, USA.

Elky, S. (2006). An Introduction to Information System Risk Management [Online].

http://www.sans.org/reading_room/whitepapers/auditing/introduction-information-system-risk-

management_1204 [Accessed 25 August 2012].

Esteves, J. (2009). “A Benefits Realisation Road-Map Framework for ERP Usage in Small and

Medium-Sized Enterprises”. Journal of Enterprise Information Management [Online], 22, 25-35.


0398&volume=22&issue=1/2&articleid=1771429&show=html [Accessed 4 August 2012].

Esteves, J. & Pastor, J. (1999). “An ERP Lifecycle-based Research Agenda”. In: First

International Workshop on Enterprise Management Resource and Planning Systems EMRPS

[Online]. 359–371. http://jesteves.com/EMRPS99.pdf [Accessed 11 May 2012].

Fox, N. (2006). Using Interviews in a Research Project. The NIHR RDS for the East Midlands /

Yorkshire & the Humber.

Gartner. (2011). Magic Quadrant for SAP Application Service Providers, Europe [Online].

http://www.gartner.com/technology/reprints.do?id=1-18CLJQU&ct=111215&st=sb [Accessed

29 July 2012].

Goeke, R. & Faley, R., (2009). “Technical Opinion: Do SAP Successes Outperform Themselves

and Their Competitors?”. Communications of the ACM [Online], 52(10), 113–117.

http://cacm.acm.org.eresources.shef.ac.uk/magazines/2009/10/42487-do-sap-successes-

outperform-themselves-and-their-competitors/fulltext [Accessed 12 May 2012].

Granebring, A. & Révay, P. (2005). “Enterprise Resource Planning Competence Centres: A Case

Study. Kybernetes [Online], 34 (9/10), 1551-1562.

http://www.sans.org/reading_room/whitepapers/auditing/introduction-information-system-risk-management_1204

http://www.sans.org/reading_room/whitepapers/auditing/introduction-information-system-risk-management_1204

http://www.emeraldinsight.com.eresources.shef.ac.uk/journals.htm?issn=1741-0398&volume=22&issue=1/2&articleid=1771429&show=html

http://www.emeraldinsight.com.eresources.shef.ac.uk/journals.htm?issn=1741-0398&volume=22&issue=1/2&articleid=1771429&show=html

http://jesteves.com/EMRPS99.pdf

http://www.gartner.com/technology/reprints.do?id=1-18CLJQU&ct=111215&st=sb

http://cacm.acm.org.eresources.shef.ac.uk/magazines/2009/10/42487-do-sap-successes-outperform-themselves-and-their-competitors/fulltext

http://cacm.acm.org.eresources.shef.ac.uk/magazines/2009/10/42487-do-sap-successes-outperform-themselves-and-their-competitors/fulltext

79


492X&volume=34&issue=9/10&articleid=1524341&show=html [Accessed 10 August 2012].

Hecht, S., Wittges, H., & Krcmar, H. (2011). “IT Capabilities in ERP Maintenance – A Review

of the ERP Post-Implementation Literature”. ECIS 2011 Proceedings [Online], 14.

http://is2.lse.ac.uk/asp/aspecis/20110013.pdf [Accessed 20 July 2012].

Holland, C., & Light, B. (1999). “A Critical Success Factors Model for ERP Implementation”.

Software, IEEE [Online], 16(3), 30–36.

http://ieeexplore.ieee.org.eresources.shef.ac.uk/stamp/stamp.jsp?tp=&arnumber=

765784 [Accessed 1 May 2012].

Imtihan, M., Ngadiman, M., & Haron, H. (2008). “An Alternative Model for ERP Maintenance

Strategy”. In: SNPD ’08 [Online]. Proceedings of the Ninth ACIS International Conference on

Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing,

2008. 6-8 August 2008, Phuket. IEEE Computer Society.

http://ieeexplore.ieee.org.eresources.shef.ac.uk/stamp/stamp.jsp?tp=&arnumber=4617467

[Accessed 19 July 2012].

InformationWeek. (2008). “SAP Outlines Updated Maintenance Fee Plan”. InformationWeek

Software [Online], 7 November.

http://www.informationweek.com/news/software/enterprise_apps/212001106 [Accessed 1 May

2012].

Jacobson, S., Shepherd, J., D’Aquila, M. & Carter, K. (2007). The ERP Market Sizing Report,

2006–2011[Online]. Boston, MA: AMR Research, Inc.

http://www.gtm.sap.com/uk/solutions/business-suite/erp/pdf/AMR_ERP_Market_Sizing_2006-

2011.pdf [Accessed 30 April 2012].

Jovicic, B., Devedzic, V., Djuric, D., & Sendelj, R. (2012). “Agile ERP systems development: a

technical perspective”. In: ISEC ’12 [Online]. Proceedings of the 5th India Software Engineering

http://www.emeraldinsight.com.eresources.shef.ac.uk/journals.htm?issn=0368-492X&volume=34&issue=9/10&articleid=1524341&show=html

http://www.emeraldinsight.com.eresources.shef.ac.uk/journals.htm?issn=0368-492X&volume=34&issue=9/10&articleid=1524341&show=html

http://is2.lse.ac.uk/asp/aspecis/20110013.pdf


http://www.informationweek.com/news/software/enterprise_apps/212001106

http://www.gtm.sap.com/uk/solutions/business-suite/erp/pdf/AMR_ERP_Market_Sizing_2006-2011.pdf

http://www.gtm.sap.com/uk/solutions/business-suite/erp/pdf/AMR_ERP_Market_Sizing_2006-2011.pdf

80

Conference. 22-25 February 2012, Kanpur, India. New York, USA: ACM.

http://dl.acm.org.eresources.shef.ac.uk/citation.cfm?id=2134254.2134266&coll=DL&dl=ACM

[Accessed 8 August 2012].

Kvale, S. (1996). Interviews: An Introduction to Qualitative Research Interviewing. California:

SAGE Publications Inc.

Lanzing, J. (1997). The Concept Mapping Homepage [Online].

http://users.edte.utwente.nl/lanzing/cm_home.htm [Accessed 28 August 2012].

Law, C., Chen, C., & Wu, B. (2010). “Managing the Full ERP Life-cycle: Considerations of

Maintenance and Support Requirements and IT Governance Practice as Integral Elements of the

Formula for Successful ERP Adoption”. Computers in Industry [Online], 61(3), 297–308.

http://www.sciencedirect.com.eresources.shef.ac.uk/science/article/pii/S016636150900195X

[Accessed 5 May 2012].

Leon, A. (2007). Enterprise Resource Planning [E-book]. New Delhi, India: Tata McGraw-Hill

Education.

http://books.google.co.uk/books?hl=en&lr=&id=pTGDy2GX_sUC&oi=fnd&pg=PT20&dq=leon

+enterprise+resource+planning&ots=Aps7Dd90q3&sig=XlGX29vLzvFLLAs9pkEDinXkIOg#v

=onepage&q=leon%20enterprise%20resource%20planning&f=false [Accessed 28 April 2012].

Light, B. (2001). “The Maintenance Implications of the Customization of ERP Software”.

Journal of Software Maintenance and Evolution: Research and Practice [Online], 13, 415–429.

http://wwwkrcmar.in.tum.de/lehre/lv_materialien.nsf/intern01/7394346C17575A26C1256E2A00

5731C3/$FILE/0113%20Light.%20The%20maintenance%20implications%20of%20the%20cust

omizations%20of%20ERP%20software.pdf [Accessed 22 July 2012].

Markus, M. & Tanis, C. (2000). “The Enterprise Systems Experience-From Adoption to

Success”. Framing the Domains of IT Research: Glimpsing The Future through the Past

http://dl.acm.org.eresources.shef.ac.uk/citation.cfm?id=2134254.2134266&coll=DL&dl=ACM

http://users.edte.utwente.nl/lanzing/cm_home.htm

http://www.sciencedirect.com.eresources.shef.ac.uk/science/article/pii/S016636150900195X

http://books.google.co.uk/books?hl=en&lr=&id=pTGDy2GX_sUC&oi=fnd&pg=PT20&dq=leon+enterprise+resource+planning&ots=Aps7Dd90q3&sig=XlGX29vLzvFLLAs9pkEDinXkIOg#v=onepage&q=leon%20enterprise%20resource%20planning&f=false



http://wwwkrcmar.in.tum.de/lehre/lv_materialien.nsf/intern01/7394346C17575A26C1256E2A005731C3/$FILE/0113%20Light.%20The%20maintenance%20implications%20of%20the%20customizations%20of%20ERP%20software.pdf



81

[Online], 173, 207–173.

http://falconinc.xs4all.nl/navision/navision%20documentation/markus_experience.pdf [Accessed

28 April 2012].

Nah, F., Faja, S., & Cata, T. (2001). “Characteristics of ERP Software Maintenance: A Multiple

Case Study”. Journal of Software Maintenance and Evolution: Research and Practice [Online],

13, 399-414.

ftp://79.136.251.172/aristarh/MAXQDA/send/send/Characteristics%20of%20ERP%20software!!

!.pdf [Accessed 22 July 2012].

Ng, C., Chan, T, & Gable, G. (2001). “A client-benefits oriented taxonomy of ERP

maintenance”. In: IEEE International Conference on Software Maintenance [Online].

Proceedings of the IEEE International Conference on Software Maintenance. 7-9 November

2001, Florence.



Ng, C., Gable, G., & Chan, T. (2002). “An ERP-Client Benefit-Oriented Maintenance

Taxonomy”. The Journal of Systems and Software [Online], 64 (2), 87-109.

http://www.sciencedirect.com.eresources.shef.ac.uk/science/article/pii/S0164121202000298


Ng, C., Gable, G., & Chan, T. (2003). “An ERP maintenance model”. In: HICCS’03 [Online].

Proceedings of the 36th Hawaii International Conference on System Sciences. 6-9 January 2003,

Hawaii. IEEE Computer Society.



Panorama Consulting Group. (2011). 2011 Guide to ERP Systems and Vendors [Online]. Denver,

CO: Panorama Consulting Group LLC. http://panorama-consulting.com/Documents/2011-

Guide-to-ERP-Systems-and-Vendors.pdf [Accessed 1 May 2012].

http://falconinc.xs4all.nl/navision/navision%20documentation/markus_experience.pdf

ftp://79.136.251.172/aristarh/MAXQDA/send/send/Characteristics of ERP software!!!.pdf

ftp://79.136.251.172/aristarh/MAXQDA/send/send/Characteristics of ERP software!!!.pdf




http://panorama-consulting.com/Documents/2011-Guide-to-ERP-Systems-and-Vendors.pdf

http://panorama-consulting.com/Documents/2011-Guide-to-ERP-Systems-and-Vendors.pdf

82

Panorama Consulting Group. (2012). Clash of the Titans 2012: SAP vs. Oracle vs. MS Dynamics

[Online]. http://panorama-consulting.com/clash-of-the-titans-2012-sap-vs-oracle-vs-ms-

dynamics/ [Accessed 1 August 2012].

Park, K. & Kusiak, A. (2005). “Enterprise Resource Planning (ERP) Operations Support System

for Maintaining Process Integration”. International Journal of Production Research [Online], 43,

3959–3982. http://business.management6.com/Enterprise-resource-planning-%28ERP%29-

operations-support-system-for-download-w8831.pdf [Accessed 5 July 2012].

Peng, G. C. & Nunes, M. (2010a). “Barriers to the Successful Exploitation of ERP Systems in

Chinese State-Owned Enterprises”. International Journal of Business and Systems Research

[Online], 4 (5/6). 596-620. http://eprints.whiterose.ac.uk/11113/ [Accessed 20 July 2012].

Peng, G. C. & Nunes, M. (2010b). “Exploring Cultural Impact on Long-Term Utilization of

Enterprise Systems.” In: HICSS 2010 [Online]. Proceedings of the 43rd

Hawaii International

Conference on System Sciences. 5-8 January 2010, Honolulu, HI. IEEE Computer Society.



Peng, G. C. & Nunes, M. (2009). “Surfacing ERP Exploitation Risks through a Risk

Ontology”. Industrial Management and Data Systems [Online], 109 (7), 926-942.

http://eprints.whiterose.ac.uk/9830 [Accessed 20 July 2012].

Peng, G. & Annansingh, F. (2012). Experiences in Applying Mixed-methods Approach in

Information Systems Research, 'Information Systems Research and Exploring Social Artifacts:

Approaches and Methodologies', IGI Global.

Reissman, C. (1993). Narrative Analysis. California: SAGE Publications Inc.

http://panorama-consulting.com/clash-of-the-titans-2012-sap-vs-oracle-vs-ms-dynamics/

http://panorama-consulting.com/clash-of-the-titans-2012-sap-vs-oracle-vs-ms-dynamics/

http://business.management6.com/Enterprise-resource-planning-%28ERP%29-operations-support-system-for-download-w8831.pdf

http://business.management6.com/Enterprise-resource-planning-%28ERP%29-operations-support-system-for-download-w8831.pdf

http://eprints.whiterose.ac.uk/11113/


http://eprints.whiterose.ac.uk/9830

83

Salmeron, J. & Lopez, C. (2010). “A Multicriteria Approach for Risks Assessment in ERP

Maintenance”. Journal of Systems and Software, [Online], 83(10), 1941–1953.



Salmeron, J. & Lopez, C. (2012). “Forecasting Risk Impact on ERP Maintenance with

Augmented Fuzzy Cognitive Maps”. IEEE Transactions on Software Engineering [Online],

38(2), 439 –452.

http://ieeexplore.ieee.org.eresources.shef.ac.uk/stamp/stamp.jsp?tp=&arnumber=5680917&tag=

1 [Accessed 11 May 2012].

SAP. (2012a). SAP Global Alliance Partners – SAP Global Service Partners [Online].

http://www.sap.com/our-partners/find-a-partner.epx [Accessed 12 August 2012].

SAP. (2012b). SAP Named Worldwide Market Share Leader for Enterprise Resource Planning

[Online]. http://www.sap.com/corporate-en/press.epx?PressID=18813 [Accessed 5 May 2012].

Shehab, E., Thomassin, M. & Badawy, M. (2011). “Towards a cost modelling framework for

outsourcing ERP systems”. In: Improving Complex Systems Today [Online]. Proceedings of the

18th ISPE International Conference on Concurrent Engineering. 4-8 July 2011, Massachusetts,

USA. Eds. Daniel D Frey, Shuichi Fukuda, Georg Rock.

http://dspace.lib.cranfield.ac.uk/handle/1826/7332 [Accessed 20 August 2012].

Sia, S., Tang, M., Soh, C., & Boh, W. (2002). “Enterprise Resource Planning (ERP) Systems as a

Technology of Power: Empowerment or Panoptic Control?”. ACM SIGMIS Database [Online],

33, 23–37. http://dl.acm.org.eresources.shef.ac.uk/citation.cfm?doid=504350.504356 [Accessed

28 April 2012].

Somers, T. & Nelson, K. (2004). “A Taxonomy of Players and Activities Across the ERP Project

Life Cycle”. Information & Management [Online], 41 (3), 257-278.


http://ieeexplore.ieee.org.eresources.shef.ac.uk/stamp/stamp.jsp?tp=&arnumber=5680917&tag=1

http://ieeexplore.ieee.org.eresources.shef.ac.uk/stamp/stamp.jsp?tp=&arnumber=5680917&tag=1

http://www.sap.com/our-partners/find-a-partner.epx

http://www.sap.com/corporate-en/press.epx?PressID=18813

http://dspace.lib.cranfield.ac.uk/handle/1826/7332

http://dl.acm.org.eresources.shef.ac.uk/citation.cfm?doid=504350.504356

84



Themistocleous, M., O’Keefe, R., & Paul, R. (2001). “ERP and Application Integration:

Exploratory Survey”. Business Process Management Journal [Online], 7(3), 195–204.



White, H. (2011). How to Construct a Concept Map [Online].

http://www.udel.edu/chem/white/teaching/ConceptMap.html [Accessed 28 August 2012].



http://www.udel.edu/chem/white/teaching/ConceptMap.html

85

Appendix I. SAP Global Service Partners

SAP Global Service Partner Website

Accenture www.accenture.com

Atos www.atos.net

Capgemini www.capgemini.com

Cognizant www.cognizant.com

CSC www.csc.com

Deloitte www.deloitte.com

Fujitsu www.fujitsu.com

HCL AXON www.hcl-axon.com

Hitachi – Hitachi Consulting www.hitachiconsulting.com

HP www.hp.com

IBM Global Business Services www.ibm.com

IDS Scheer Consulting www.softwareag.com

Indra www.indracompany.com

Infosys www.infosys.com

itelligence www.itelligence.ag

L&T Infotech www.lntinfotech.com

Logica www.logica.com

Mahindra Satyam www.mahindrasatyam.com

Neoris www.neoris.com

PwC www.pwc.com

Tata Consultancy Services www.tcs.com

T-Systems www.t-systems.com

Wipro www.wipro.com

Table 1. SAP Global Service Partners (SAP, 2012a).

86

Appendix II. Interview Questions Template

Interview Questions Template

The purpose of these questions is to identify the risks that the third-party consultant faces when

performing the main activities in the following ERP maintenance activity categories: ERP

maintenance administration, ERP changes, ERP user support, ERP enhancements, and ERP

updates. The responses will be used solely for reporting the findings of the study. Please feel free

to discuss any doubts or ask any further questions while the interview is being conducted.

Interview Questions

1. What is your current job position in the IT consulting company? What are the main ERP

maintenance and support activities that you perform?

2. In the administration of user requests, what are the risks that may arise when handling,

coordinating, and controlling the user requests? (e.g. wrong prioritization, incorrect team

assignment of maintenance request, work overload, unable to communicate with end

user, unclear request)

Follow-up: What could be the consequences of the risk? (This follow up question will go

after interviewee describes one risk or several risks on all the following questions and

may or may not be needed)

3. Are the tools, including software and resources, used for the administration of

maintenance user requests efficient, e.g. easy to use, user friendly? What risks may bring

to your maintenance tasks related to ERP maintenance administration? e.g. when not

working, not sending warnings on time limit for an expiring request, complicated

interfaces.

Follow-up: What could be the consequences of the risk?

4. When performing ERP changes, e.g. change in configuration, add functionality, amend a

report, change screen displays, what are the risks encountered while making an ERP

change?


5. When an ERP change is being tested, what can go wrong in this entire process? Please

provide examples. E.g. user not being able to test the change or user does not have the

knowledge of what is being tested.


87

6. User support deals with assisting users on how to use the system or fix errors in the

system as two major examples. What are the risks that a consultant may face when

providing training and knowledge support to users?


7. How often do you work with an ERP enhancement? What can be the possible risks

related to the approval, creation of the functional specification for the enhancement, or

working with an enhancement?


8. How are ERP updates (patches, new versions) dealt with in order to avoid any issues with

your clients ERP system? What are the risks that can arise when an ERP update is being

performed?

Follow up: Is preventive testing conducted before and after the upgrade? Why is it

necessary?

88

Appendix III. Ethics Forms

Ethics Infosheet 1. Research Project Title:

Investigation on risks faced by SAP Consultants when maintaining and supporting SAP ERP 6.0.

2. Invitation paragraph

You are being invited to take part in a research project that will help me identify the main risks

that you encounter in your job. It is important to explain to you the research’s scope and how you

will contribute to the study. Please read the following information carefully and feel free to ask

any questions. Take time to decide whether or not you wish to participate. Your participation

will be of great value to me and the study.

3. What is the project’s purpose?

The study aims to identify the main risks that third party functional consultants face when

performing the tasks of maintenance and support of ERP systems. The study will start in June

and will be completed by September 3, 2012.

4. Why have I been chosen?

Currently, you are working as an SAP Functional Consultant for one of the modules in an IT

consulting company. The study aims to investigate further on the risks that you face when

maintaining and supporting SAP. A group of 15-20 consultants will take part in the study.

5. Do I have to take part?

You have the option to participate in this study or decline your participation. If you do decide to

take part you will be given this information sheet to store in your files and be asked to sign a

consent form. In addition, you may be able to withdraw at any given time with no implications.

6. What will happen to me if I take part?

You will be asked to take part in a semi-structured interview conducted by phone or Skype

whichever is more convenient for you. During the interview process, you will be asked questions

regarding risks that you have encountered as an SAP consultant and be able to provide open

answers and opinions. The interview process should last about an hour and will be arranged at

89

the most suitable time for you. After the interview, the data will be transcribed and the researcher

may contact you to clarify any details or ask any further questions. A quantitative approach will

be used to identify the most frequent risks. Your contributions are the main source for the

findings on this specific study.

7. What do I have to do?

Your participation in the interview is the main activity.

8. What are the possible disadvantages and risks of taking part?

If any change to an interview’s schedule, the interviews can be rescheduled for another day.

There are no risks or disadvantages identified.

9. What are the possible benefits of taking part?

There are no direct benefits associated with your participation. However, it may be useful for

you to know the risks that you and your peers are experiencing.

10. What happens if the research study stops earlier than expected?

The research will have a specified duration from June to September 2012.

11. What if something goes wrong?

Any complaints that you may have about the study or the researcher may be handled by the

Supervisor Dr. G. C. Alex Peng by emailing [email protected]. In addition, complaints

not attended by the Supervisor can be directed to the University’s ‘Registrar and Secretary’.

12. Will my taking part in this project be kept confidential?

All the information collected about you during the study will be kept strictly confidential and

only accessed by the researcher. Your name or details will not be given to anybody and no names

will appear in the publication of the study.

13. What type of information will be sought from me and why is the collection of this

information relevant for achieving the research project’s objectives?

The answers provided by you in the interviews will be of great value to identify the main risks

that consultants face when maintaining and supporting SAP ERP.

14. What will happen to the results of the research project?

The results of the research will be completed in September 3, 2012 with the completion of the

dissertation done by the researcher. A copy of the results will be emailed to you if requested to

mailto:[email protected]

90

the researcher. Your name will not be used in any part of the study. Also, the findings may be

used for subsequent studies in the same topic as little research has been done before.

15. Who is organising and funding the research?

The research is conducted by a masters student for the University of Sheffield.

16. Who has ethically reviewed the project?

This project has been ethically approved via the Information School department’s ethics review

procedure. The University’s Research Ethics Committee monitors the application and delivery of

the University’s Ethics Review Procedure across the University.

17. Will I be recorded, and how will the recorded media be used?

The interview will result in an audio and/or video recording which will be stored in my personal

laptop. The data will be used for further analysis and identify the risks given by all the

participants. The recordings will be strictly used for the study and no other use will result

without your written permission, and no one outside the project will have access to the

recordings. At the end of the project, the recordings will be eliminated.

18. Contact for further information

The contact information on the researcher and supervisor is provided below.

Researcher: Supervisor:

Luis Alberto Ramos Salazar Dr. G.C. Alex Peng

[email protected] [email protected]

Tel. +447950421811

A copy of the information sheet should be stored by you in your personal files. A consent form

will be emailed to you. The consent form should be signed and emailed to the researcher before

taking part in the study.

Your participation will be appreciated and will provide great value to the outcome of the study.

Thank you for your participation.



91

Title of Research Project:

Investigation on risks faced by SAP Consultants when maintaining and supporting SAP ERP

6.0.

Name of Researcher: Luis Alberto Ramos Salazar

Participant Id: Please write your initials after each question.

I confirm that I have read and understand the information sheet dated

May 27, 2012 explaining the above research project

and I have had the opportunity to ask questions about the project.

I understand that my participation is voluntary and that I am free to withdraw

at any time without giving any reason and without there being any negative

consequences. In addition, if I do not wish to answer any particular

question or questions, I am free to decline.

Contact number of researcher: +447950421811

I understand that my responses in the recorded media will be kept strictly confidential. I give

permission for members of the research team to have access to my anonymised responses. I

understand that my name will not be linked with

the research materials, and I will not be identified in the

report or reports that result from the research.

4. I agree for the data collected from me to be used in future research

I agree to take part in the above research project.

________________________ ________________ ____________________

Name of Participant Date Signature

(or legal representative)

_________________________ ________________ ____________________

Name of person taking consent Date Signature

(if different from lead researcher)

To be signed and dated in presence of the participant

Luis Alberto Ramos Salazar May 27, 2012 __Luis Ramos__________

Lead Researcher Date Signature

To be signed and dated in presence of the participant

Copies:

Once this has been signed by all parties the participant should receive a copy of the signed and dated

participant consent form, the information sheet and any other written information provided to the participants. A

92

copy of the signed and dated consent form should be placed in the project’s main record which must be kept in a

secure location.

University Research Ethics Application Form

for Undergraduate & Postgraduate-Taught Students

This form has been approved by the University Research Ethics Committee (UREC)

Complete this form if you are an undergraduate or a postgraduate-taught student who plans

to undertake a research project which requires ethics approval via the University Ethics Review

Procedure.

Your Supervisor decides if ethics approval is required and, if required, which ethics review

procedure (e.g. University, NHS, Alternative) applies.

If the University’s procedure applies, your Supervisor decides if your proposed project should be

classed as ‘low risk’ or potentially ‘high risk’.

*PLEASE NOTE THAT YOUR DEPARTMENT MAY USE A VARIATION OF THIS

FORM: PLEASE CHECK WITH THE ETHICS ADMINISTRATOR IN YOUR

DEPARTMENT*

This form should be accompanied, where appropriate, by all Information Sheets / Covering Letters /

Written Scripts which you propose to use to inform the prospective participants about the proposed

research, and/or by a Consent Form where you need to use one.

Further guidance on how to apply is at:

www.sheffield.ac.uk/ris/other/gov-ethics/ethicspolicy/approval-procedure/review-procedure

Guidance on the possible routes for obtaining ethics approval (i.e. on the University Ethics

Review Procedure, the NHS procedure and the Social Care Research Ethics Committee, and the

Alternative procedure) is at: www.sheffield.ac.uk/ris/other/gov-ethics/ethicspolicy/approval-procedure/ethics-approval

Once you have completed this research ethics application form in full, and other documents

where appropriate, check that your name, the title of your research project and the date is

contained in the footer of each page.

If your Supervisor has classed the project as ‘low risk’:

Email this form, together with other documents where applicable, to your Supervisor; and

Sign and date Annex 1 of this form and provide a paper copy to your Supervisor.

Important Note for Supervisors:

Following the ethics review the Supervisor must provide the academic department’s Ethics

Administrator with a copy of the ‘low risk’ research ethics application that s/he reviewed and a

completed Ethics Reviewer’s Comments Form indicating the ethics decision that s/he took in

relation to it. The Ethics Reviewer’s Comments Form can be downloaded here:

www.sheffield.ac.uk/ris/other/gov-ethics/ethicspolicy/further-

http://www.sheffield.ac.uk/ris/other/gov-ethics/ethicspolicy/approval-procedure/review-procedure

http://www.sheffield.ac.uk/ris/other/gov-ethics/ethicspolicy/approval-procedure/review-procedure

http://www.sheffield.ac.uk/ris/other/gov-ethics/ethicspolicy/approval-procedure/ethics-approval

http://www.sheffield.ac.uk/ris/other/gov-ethics/ethicspolicy/approval-procedure/ethics-approval

http://www.sheffield.ac.uk/ris/other/gov-ethics/ethicspolicy/further-guidance/universityprocedure2/reviewersc

93

guidance/universityprocedure2/reviewersc The Ethics Administrator reserves the right to consult

the Chair of the academic department’s Ethics Review Panel (or equivalent) of s/he has concerns

that projects classed as low risk should in fact have been classed as potentially high risk.

If your Supervisor has classed the project as potentially ‘high risk’:

Email this form, together with other documents where applicable, to your department’s Ethics

Administrator; and

Ask your Supervisor to sign and date Annex 2 of this form and provide a paper copy of it to your

department’s Ethics Administrator.

Ethics Administrators are listed at:

www.sheffield.ac.uk/polopoly_fs/1.99105!/file/Ethics-Administrators.pdf

University Research Ethics Application Formfor Undergraduate & Postgraduate-Taught Students

I confirm that I have read the current version of the University of Sheffield

‘Ethics Policy Governing Research Involving Human Participants, Personal

Data and Human Tissue’, as shown on the University’s research ethics website

at: www.sheffield.ac.uk/ris/other/gov-ethics/ethicspolicy

A1. Title of research project: Investigation on risks faced by SAP Consultants when maintaining and

supporting SAP ERP 6.0.

A2. Name of Student: Luis Alberto Ramos Salazar

Department: Information School Email:

X

http://www.sheffield.ac.uk/ris/other/gov-ethics/ethicspolicy/further-guidance/universityprocedure2/reviewersc

http://www.sheffield.ac.uk/polopoly_fs/1.99105!/file/Ethics-Administrators.pdf

http://www.sheffield.ac.uk/ris/other/gov-ethics/ethicspolicy

94

[email protected] Tel.: 07950421811

Name of Supervisor: Dr. G.C. Alex Peng

A3. Proposed Project Duration:

Start date: 06/08/2012 End date: 09/03/2012

A4. Mark ‘X’ in one or more of the following boxes if your research:

involves adults with mental incapacity or mental illness

involves prisoners or others in custodial care (e.g. young offenders)

involves children or young people aged under 18 years

involves using samples of human biological material collected before for another purpose

involves taking new samples of human biological material (e.g. blood, tissue) *

involves testing a medicinal product *

involves taking new samples of human biological material (e.g. blood, tissue) *

involves additional radiation above that required for clinical care *

involves investigating a medical device *

* If you have marked boxes marked * then you also need to obtain confirmation that appropriate

University insurance is in place. To do this email [email protected] and request a copy of the

‘Clinical Trial Insurance Application Form’.

It is recommended that you familiarise yourself with the University’s Ethics Policy Governing Research Involving

Human Participants, Personal Data and Human Tissue before completing the following questions. Please note that

if you provide sufficient information about the research (what you intend to do, how it will be carried out and how

you intend to minimise any risks), this will help the ethics reviewers to make an informed judgement quickly

without having to ask for further details.

95

A5. Briefly summarise:

The project’s aims and objectives:

The study aims to identify the main risks that third party functional consultants face when

performing the tasks of maintenance and support of ERP systems.

Complete a literature review on the general IS/ERP maintenance risks that have been identified

by past researchers. Identify the risks in terms of probability, impact and frequency.

The project’s methodology:

The study will use a mixed-method approach to find the main risks in ERP maintenance. The

sequential exploratory is used to collect qualitative data via semi-structured interviews to third

party SAP consultants. However, the methodology used is predominantly inductive approach and

is given priority to the qualitative aspect.

A6. What is the potential for physical and/or psychological harm / distress to

participants?

No physical or psychological harm has been identified

A7. Does your research raise any issues of personal safety for you or other

researchers involved in the project? (especially if taking place outside working hours or off

University premises)

No

If yes, explain how these issues will be managed

A8. How will the potential participants in the project be:

Identified? The participants are employees of my former employer and most of them I worked

with before.

Approached? I will contact the participants by email or phone.

Recruited? Participants that have been identified will participate if they accept to do so.

A9. Will informed consent be obtained from the participants?

96

YES X NO

If informed consent or consent is NOT to be obtained please explain why. Further guidance

is at: www.sheffield.ac.uk/ris/other/gov-ethics/ethicspolicy/policy-notes/consent

A9.1. This question is only applicable if you are planning to obtain informed consent:

How do you plan to obtain informed consent? (i.e. the proposed process?):

The informed consent will be sent to the participants via email. Once they have accepted their

participation in the study, they will submit the consent back to the researcher via email.

A10. What measures will be put in place to ensure confidentiality of personal data, where

appropriate?

Information will only be available to the researcher and will not be uploaded to any other

media apart from his own laptop. No personal information will be stored

A11. Will financial / in kind payments (other than reasonable expenses and compensation

for time) be offered to participants? (Indicate how much and on what basis this has been

decided)

No

A12. Will the research involve the production of recorded media such as audio and/or

video recordings?

YES X NO

A12.1. This question is only applicable if you are planning to produce recorded media:

How will you ensure that there is a clear agreement with participants as to how these

recorded media may be stored, used and (if appropriate) destroyed?

The agreement for recorded media will be stated in the consent form in order for participants to

agree to be recorded during the interview process. Data will be destroyed after a certain time.

Guidance on a range of ethical issues, including safety and well-being, consent and anonymity,

confidentiality and data protection’ are available at:

www.sheffield.ac.uk/ris/other/gov-ethics/ethicspolicy/policy-notes

Annex 1

For Undergraduate & Postgraduate-Taught Students

Student Declaration

http://www.sheffield.ac.uk/ris/other/gov-ethics/ethicspolicy/policy-notes/consent

http://www.sheffield.ac.uk/ris/other/gov-ethics/ethicspolicy/policy-notes

97

(The student completes Annex 1 if the Supervisor has classed the student’s

proposed research project as ‘low risk’)

The Supervisor needs to receive an electronic copy of the form, and other documents where

appropriate, plus a signed, dated paper copy of this Annex 1 ‘the Student Declaration’.

Full Research Project Title: Investigation on risks faced by SAP Consultants when maintaining

and supporting SAP ERP 6.0.

In signing this Student Declaration I am confirming that:

The research ethics application form for the above-named project is accurate to the best of my knowledge

and belief.

The above-named project will abide by the University’s ‘Good Research Practice Standards’:

www.sheffield.ac.uk/ris/other/gov-ethics/good

The above-named project will abide by the University’s ‘Ethics Policy Governing Research Involving

Human Participants, Personal Data and Human Tissue’:

www.sheffield.ac.uk/ris/other/gov-ethics/ethicspolicy

Subject to the above-named project being ethically approved I undertake to adhere to any ethics

conditions that may be set.

I will inform my Supervisor of significant changes to the above-named project that have ethical

consequences.

I will inform my Supervisor if prospective participants make a complaint about the above-named project.

I understand that personal data about me as a researcher on the research ethics application form will be

held by those involved in the ethics review process (e.g. my Supervisor and the Ethics Administrator) and

that this will be managed according to Data Protection Act principles.

I understand that this project cannot be submitted for ethics approval in more than one

department, and that if I wish to appeal against the decision made, this must be done through the

original department.

Name of Supervisor: Dr. G.C. Alex Peng.

Name of student: Luis Alberto Ramos Salazar

Signature of student: Luis Alberto Ramos Salazar

Date: May 27, 2012

UNIVERSITY OF SHEFFIELD - INFORMATION SCHOOL

http://www.sheffield.ac.uk/ris/other/gov-ethics/good

http://www.sheffield.ac.uk/ris/other/gov-ethics/ethicspolicy