Managing Enterprise Resource Planning System Customisation

Post-Implementation

The Case of an African Petroleum Organisation

Sharif Gool and Lisa F. Seymour

Department of Information Systems, University of Cape Town, Cape Town, South Africa

Keywords: ERP, Enterprise Resource Planning, Enterprise Systems, Modifications, Customisation, Customization.

Abstract: Implementing an Enterprise Resource Planning (ERP) system is a challenging endeavour. One dominant

challenge is to determine when to customise the ERP system to match organisational requirements and when

to rather change business processes to fit standard ERP delivered functionality. However, there is agreement

that ERP customisation needs to be managed. While research has been done in understanding drivers of ERP

customisation during an implementation, little research has focused on the post-implementation journey. This

paper describes factors impacting ERP customisation post-implementation. The study is an interpretive single

organisational case study in a multinational African petroleum organisation. The study identifies multiple

reasons for the need for customisation post-implementation and describes practices that organisations can

employ to manage customisation, including staff training interventions, systematically removing

modifications and approval processes. This paper contributes to our understanding of ERP customisation and

should be a value to practitioners trying to manage customisation post-implementation.

1 INTRODUCTION

Enterprise Resource Planning (ERP) systems have

transformed the way organisations operate and are

supported by software. ERP systems provide process

templates that claim to embody current best business

practices (Esteves and Pastor, 2016). Yet there is an

inherent misfit between the processes of the business

and the functionality offered by the packaged

solution. Therefore, in order to achieve functional

alignment between the system and organisational

processes, some ERP customisation is necessary

(Buonanno et al., 2005). It is wiser to minimise

customisation to reduce post implementation

maintenance costs (Kholeif, Abdel-Kader and Sherer,

2007). Yet many organisations struggle to control the

proliferation of customisation (Panorama Consulting,

2017) and the drivers for customisation post-

implementation are not well understood. Hence this

paper describes factors impacting ERP customisation

post implementation. To achieve this, a brief

summary of ERP systems as well as the customisation

drivers are presented. This is then followed by the

research method, the study’s findings and conclusion.

2 LITERATURE REVIEW

Unlike bespoke software, ERP software packages are

not custom built to match the needs and business

processes of one specific organisation (Fryling,

2015). Instead, ERP systems, such as SAP ERP, are

organisational needs across a diverse global

landscape (Haines, 2009; Luo and Strong, 2004).

These systems enable an organisation to automate,

standardize and integrate their business processes

across functional divisions (Aslam, Coombs and

Doherty, 2012). The major value from ERP systems

accrues post-implementation, although there is little

research on this (Cao, Nicolaou and Bhattacharya,

2013). There are many ERP lifecycle phases after go-

live (Brehm and Markus, 2000).

ERP vendors inscribe industry “best practices”

into their pre-packages software. In reality these “best

practices” are common business processes (Antero,

2015). The success of an ERP implementation hinges

largely on being able to identify a fitting match

between these ERP standard processes and the

organisation’s business processes (Cao et al., 2013).

Yet, there are many different industries and

Gool, S. and Seymour, L.

Managing Enterprise Resource Planning System Customisation Post-Implementation.

DOI: 10.5220/0006676401110119

In Proceedings of the 20th International Conference on Enterprise Information Systems (ICEIS 2018), pages 111-119

ISBN: 978-989-758-298-1

111

organisations within those industries that operate

differently from one another (Pan et al., 2015). As

every organisation is unique and operates differently,

the implementation of the general standard solution

offered by vendors can be inadequate (Davis, 2005).

To achieve a fit between the business processes

required and the system, customisation of the system

or changing the business process is necessary (Luo

and Strong, 2004). In this paper, focus will be given

to the customisation of the ERP system.

There are many ways of categorising ERP

customisation or tailoring (Brehm, Heinzl and

Markus, 2001; Hustad, Haddara and Kalvenes, 2016).

They can be categorised into three categories: module

customisation, table configuration and ERP

programming. Module customisation refers to

selection of various modules. Table configuration

refers to the setup of table parameters that alters the

functionality of the modules according to the

requirements set out by the organisation. ERP

programming includes the programming of screen

masks, extended reporting, user exits, enhancements,

extensions, interface developments and code

modification. Code modification refers to the actual

modification of the standard delivered system source

code (Luo and Strong, 2004). Unfortunately, the most

commonly used term, ERP customising, is often

misused. The SAP ERP menu refers to table

configuration as customizing and in contrast many

articles and users when referring to customising

imply code modification. Therefore in reviewing the

literature we loosely use the term customisation

which in most cases implies ERP programming.

An ERP’s ability to compete within the

hypercompetitive ERP environment market is

determined by how well it keeps up with

technological innovation (Antero, 2015). Therefore,

ERP vendors release a continuous flow of upgrades

and fixes which ERP adopters need to implement

post-implementation (Brehm and Markus, 2000). The

more modifications, the more development and

testing time is required to deliver the solution. This

effort is duplicated at each ERP upgrade when code

modifications are overwritten and need to be

reapplied (Zach, 2012). As a result of this, post

implementation costs continually rise (Esteves and

Pastor, 2016). Functionality offered by ERP vendors

also takes preference over all forms of ERP

programming as the vendor is responsible for its

support (Light, 2005) and hence costs are reduced.

While practitioners have stated that the ideal level of

ERP customisation should be between 10 and 20% of

code modified (Panorama Consulting, 2017),

customisation is known to increase post

implementation (Esteves and Pastor, 2016). The

literature identifying factors driving customisation

was reviewed in this paper and was found to focus

predominantly on the implementation stage and the

definition of what constituted customisation was

found to be vague. For parsimony sake, these factors

are presented with the findings. As ERP

programming is the form of ERP customisation with

the highest long term cost an understanding of its

drivers is needed.

3 RESEARCH METHOD

Despite the recommendations from literature that

discourage excessive ERP programming, the amount

increases after the ERP system has gone live. Hence

the main question posed is “What impacts ERP

programming at post implementation stage.” An

embedded interpretive single case study was

conducted as it is suitable for answering descriptive

questions (Yin, 2012) enabling a rich understanding

of the underlying factors impacting customisation.

Company Z studied is a multinational petroleum

organisation that has a presence in many sub-Saharan

African countries and had been running SAP for

longer than 20 years. They had their own internal

ERP team within their Information Systems (IS)

department. The initial implementation project

brought about substantail code modifications and

created a culture that accepted and invited this

practice. Their ERP had undergone numerous

upgrades that were very challenging due to the large

amount of ERP programming. In 2016 they were

upgrading to the latest EHP8 version and in line with

SAP’s future road map they were planning to migrate

to S/4HANA, and needed to reduce their custom

objects. This provided the ideal setting to understand

factors that impact ERP programming. The

university’s ethics committee approved the study.

Data triangulation included semi-structured

interviews and secondary data in the form of change

notes extracted from the call logging system. To

restrict the study, we chose to sample customisation

on the core modules of Finance (FI), Sales and

Distribution (SD) and Materials Management (MM).

We were given access to 990 change notes submitted

between 2012 and 2016 but focused our review on

requests completed through ERP programming in the

three modules. The convenient and purposive

sampling strategy for interviews included users who

requested customisation (U1-U3), internal functional

consultants responsible for the various modules (C1-

C3), senior management of functional departments

ICEIS 2018 - 20th International Conference on Enterprise Information Systems

112

(M1-M3) as well as technical consultants and a

technical manager (T1-T2). Hybrid inductive and

deductive thematic analysis which was then followed

allowed specific themes to be identified and

compared with theoretical ones and validated or

invalidated (Braun and Clarke, 2006).

In terms of limitations, while we performed 11

interviews, which is more than similar studies, we did

not test for theoretical saturation and it is possible that

more themes could emerge with further interviews. A

second limitation is that other than the two technical

staff interviewed, other respondents were not able to

differentiate between ERP modifications and other

forms of ERP customisation. We were also not easily

able to do this differentiation in the call logs reviewed

and hence the call logs were not that useful. We are

also not able to clearly argue generalisation outside of

the context studied. This study does focus on a large

organisation and a mature ERP product.

4 FINDINGS AND DISCUSSION

Table 1: Contrasting this study’s findings with literature.

Literature factors impacting

customisation across all

phases

Factors impacting

programming during post-

implementation

Inexperienced and revenue

maximising external

consultants

(-) Experienced and

knowledgeable internal

consultants

Lack of ERP knowledge in the

organisation

(+) Insufficient ongoing user

training focusing on business

processes

(+) Lack of handover between

users

Organisational resistance to

change processes

(+) Organisational resistance to

change processes

Lack of involvement of

operational departments

(+) Business preference of

bespoke over standard

functionality

(+) Involvement of operational

departments

ERP systems with high

complexity

(+) ERP Systems with high

complexity and extensive

functionality

ERP systems with low

maturity

Not applicable in this case

top management support

(-) top management support

(-) Customisation approval

processes

(-) Systematically removing

modifications

ERP and organisational misfit

(+) ERP and organisational

misfit

Strategically important or

differentiated business

(+) Strategically important or

required functionality

Legislative requirements

(+) Legislative requirements

(+) Country differences

(+) An evolving industry

Table 1 summarises the factors found and contrasts

these with factors identified in the literature which

impact customisations at any phase. The table

includes a plus (+) sign to indicate factors increasing

and a minus (-) for those reducing ERP programming.

4.1 Experienced and Knowledgeable

Internal Consultants

ERP consultants can promote customisation

reduction by rejecting requested customisation based

on the standard provisions (Davis, 2005) and are

better able to convince an organisation to modify a

business process instead (Ko, Kirsch and King,

2005). Yet, well experienced experts are also able to

thoroughly assess whether any strategic advantage is

gained by retaining a specific business process

(Haines, 2009) and are able to promote customisation

(Rothenberger and Srite, 2009). In contrast,

consultants with less experience are less able to

discourage and avoid customisation (Haines, 2009;

Rothenberger and Srite, 2009). In worse situations,

consultants may encourage customisation as it is seen

to be a source of revenue and can maximize billable

hours (Haines, 2009; Rothenberger and Srite, 2009).

In Company Z, the consultants were internal not

external and there was no exploitation of revenue

generation. The consultants were very experienced

having implemented the specific ERP system for

more than a decade. Individual learning was a

common practice amongst the consultants that

enabled their awareness of standard ERP

functionality. This was carried out by visiting ERP

vendor support websites and User Group or Special

Interest Group events (Table 2).

Table 2: Data supporting knowledgeable consultants and

avoiding modifications.

“SAP SD consultant since 1998.” (C2)

“We do the research; we go through the SAP user

groups and we learn what’s the new functionality.

What’s new, what SAP has done away with” (M3)

“we will advise them of possible solutions and how we

would be able to configure the system or even

introduce custom objects to satisfy their need.” (M1)

“as SAP consultants we need to apply our minds more,

look at the business requests and see how best the

request can be met in the system with, with the

information, with the functionality that is there, with

the fields that is there.” (M2)

“I have made use of the online ordering defaults table

to avoid hardcoding in the program; this will assist the

consultant to do only the CONFIG if future rollouts are

required.” (Call logs)

Managing Enterprise Resource Planning System Customisation Post-Implementation

113

Users were dependent on the consultants bringing

standard ERP functionality to their attention.

However there was a long history of modifications

performed to meet user’s requirements (Table 2).

Consultants were recently reducing modification by

providing alternate forms of customisation that would

prevent code modifications in the future. For example

performing table configuration or introducing custom

objects or using existing fields. Hence, experienced

and knowledgeable internal consultants were able to

avoid modifications.

4.2 Insufficient Ongoing User Training

Focusing on Business Processes

The relationship between the business and

implementation specialists needs to be closely

monitored and managed in an effort to gain as much

insight into ERP systems as possible from the

information rich consultants (Chen, Law and Yang,

2009). Customisation requests can then be put

forward from a better, more informed position

(Parthasarathy and Sharma, 2014).

In contrast, lack of knowledge and awareness of

the standard functionality results in custom

development requests, over-customisation and

duplication of standard functionality (Haines, 2009;

Hustad et al., 2016). Organisations that lack ERP

knowledge tend to hand the responsibility of the

project over to consultants. User’s lack of knowledge

of the ERP system also causes too much reliance on

ERP consultants who may be in favour of

customisation (Rothenberger and Srite, 2009).

Table 3: Data supporting training.

“MM training course and SAP actually offered it here

at Company Z a couple of years ago. I just can’t

remember …but we received a certificate for that.”

(U3)

“I think that users that we have here not all of them are,

are sort of familiar and understand in depth the process

aspect and integration so there’s a lot of room for

improvement in that area.” (M1)

“They don’t have the big picture; they are only

concerned with what they do. They only know what the

transactions that they execute, they don’t have the

bigger picture.” (M3)

Some users interviewed created the impression

that they were trained well, even getting SAP

certifications (Table 3). However, there is evidence

that users still lack understanding on how the system

integrates the various modules across processes.

Managers highlighted the importance of training that

covers end to end processes that users are involved in

(Table 3). Having a better understanding of the entire

process will enable users to understand their

contribution or impact on the other sub processes.

Hence insufficient ongoing and user training for users

focusing on business processes was identified as an

enabler of programming.

4.3 Lack of Handover between Users

A new theme that emerged was the duplication of

functionality caused by lack of suitable handover

between users. Users would request custom

developments to assist them in their job functions.

When they no longer filled that job role, the necessary

handover to the subsequent user is not done

sufficiently. The new user then requests similar

functionality and the existing custom programmed

objects lie dormant in the system (Table 4). Hence a

lack of handover between users increased

programming.

Table 4: Data supporting insufficient handover.

“there’s always a loss of knowledge when there’s a

hand over from one person to the other” (M2)

“people will request something that gets built and then

they use it and then that user maybe leave and then it is

not known out there, it’s not used.” (C2)

“if you move onto another department, you’re not

going to use that report anymore, you don’t handover to

the new resource” (C3)

4.4 Organisational Resistance to

Change Processes

Fear of personal disadvantages and threats that the

system may replace human resources results in low

ERP acceptance (Rothenberger and Srite, 2009). Low

project or system acceptance results in resistance to

change processes to standard practices offered by

standard ERP systems (Rothenberger and Srite,

2009). In contrast, the more comfortable and

experienced an organisation is with the ERP system,

the higher the chances are that they will embrace and

promote its use (Aslam et al., 2012). In this study

there was organisational resistance to change but in

contrast to during implementation, resistance was not

from a position of fear or lack of communication. The

users had sufficient experience with the ERP system

and were in favour of its use.

ICEIS 2018 - 20th International Conference on Enterprise Information Systems

114

4.5 Business Preference of Bespoke

over Standard Functionality

Resistance to change business processes was found to

be high in Company Z and confirmed the literature

theme. It appeared that users prefer to apply changes

to the system based on their sense of ownership and

therefore the potential advantages offered by

adopting standard practices are often overlooked.

Therefore resistance to standard functionality

appeared to be driven from a business perspective,

especially when they were used to getting

modifications, as shown in quotes in Table 5. Hence

a preference of bespoke functionality drives

modifications.

Table 5: Data supporting preference of bespoke over

standard functionality.

“They may have a solution to doing whatever they are

doing but it may not be giving them exactly what they

want from their own business point of view” (C1)

“when it comes to customisation because people are

used to it, they love it, they ask for it but when you take

them to standard there is always a resistance” (M3)

“if you advise them on whichever standard way out

there they only already have their mind fixed on what

they wanted” (C3)

4.6 Operational Department

Involvement

Including functional business units in discussions

with ERP implementers influences user acceptance of

process changes because they are part of the exercise

and hence minimises unnecessary ERP customisation

(Pan et al., 2015). In addition, involvement of

operational departments enables consultant insight

into the business and affects their solutions proposed

(Haines, 2009) which can influence customisation.

Having the support of the organisation to adhere to

the standard functionality offered by the ERP will

further discourage needless customisation

(Rothenberger and Srite, 2009). Yet this factor was

proven irrelevant at post-implementation stage as

requests are initiated by operational department users.

ERP consultants sit together with the users to

thoroughly understand their requirements and various

meetings are held before their requests are approved

and formally logged for action. Hence, unlike during

implementation, in post-implementation, operational

departmental involvement does not lead to reduced

modifications.

4.7 ERP Systems with Extensive

Functionality and Complexity

The less mature an ERP system is, the higher the

chances that there will be additional customisation

required to cater for functionality not delivered with

the standard solution (Haines, 2009; Rothenberger

and Srite, 2009). In addition, the more complex the

system, the greater the chances of misunderstanding

functionality, resulting in customisation (Haines,

2009; Rothenberger and Srite, 2009).

Immature ERP systems are seen to be the cause of

many modifications (Haines, 2009; Rothenberger and

Srite, 2009). However, in this case the system that the

organisation implemented has matured over the last

two decades and this has resulted in a significant

reduction in the amount of modification that would

have been necessary if it hadn’t. Hence this factor was

not relevant. However, the system does offer a large

amount of standard functionality that Company Z had

not completely utilized. Hence in this case large

amounts of existing functionality appeared to be a

driver of modifications as consultants were not fully

aware of all functionality. (Table 6).

Table 6: Data Supporting Underutilization Functionality.

“I think at Company Z we bought a Rolls Royce and

we used a Mini Cooper, we are not using ERP to its

fullest and it is also because people don’t know what is

out there” (M3)

4.8 Top Management Support

During an implementation, consultant management is

seen to be critical and the support of top management

to avoid customisation is necessary (Haines, 2009;

Rothenberger and Srite, 2009). Top management can

encourage the adoption of the standard practices and

support business users deflecting customisation

requests (Haines, 2009; Rothenberger and Srite,

2009). All participants were aware of the recent

strategy of the IS department that standard solutions

to requests take preference over modifications. The

mindset to avoid modification had been well adopted

throughout the organisation indicating effective

communication. Top management had set key

performance targets to achieve this objective. When

adoption of standard functionality is driven from top

management, the culture of the organisation is altered

and users are less resistant to adopting standard

functionality (Table 7). Hence top management

support is needed to reduce modifications.

Managing Enterprise Resource Planning System Customisation Post-Implementation

115

Table 7: Data supporting top management support.

“The perception is motivated by the reality that we

have as part of our Strategy that goes up to the CIO

level. He is aware that preparation for future upgrades

like I mentioned earlier on to S/4HANA, that there is a

very strong drive to clean-out our system” (M1)

4.9 Customisation Approval Processes

In Company Z strict approval processes for all user

requests had been put in place which included

approval from business process owners and ERP

functional division management before commencing

any work (Table 8). This reduced the amount of

requests and limited modifications. Hence an

approval process can reduce modifications.

Table 8: Data supporting customisation request process.

“It has to go through a lot of approvals. From their side,

from business side, when they submit a request it goes

through a number of approvals.” (C1)

“When the requirement comes in, it is a work request

that the user is able to submit via the intranet and then

it goes to the work management team, they direct it to

the IT managers… and then we endorse it and it gets

sent to the back to the work management team and

from there it will go to level 3 manager which is the

business process owner, who then further endorses it

and looks at how long it will take and whether it will

actually add value to the business operation.” (M1)

4.10 Systematically Removing

Modifications

The development team was monitoring all custom

objects that hadn’t been used over long periods of

time to identify which objects can be removed from

the system (Table 9).

Table 9: Data supporting removing modifications.

Most of the stuff become obsolete because SAP has

improved and that is when we have to investigate and

bring new solutions (C3)

4.11 ERP and Organisational Misfit

While ERP adoption has a high failure rate, it is seen

to be highly challenging in developing countries

where implementations face specific difficulties over

and above those found in industrialised countries

(Hawari and Heeks, 2010). Some of these difficulties

have been ascribed to ERP designed assumptions of

devolved decision making not fitting with cultures of

high power distance (Hawari and Heeks, 2010) found

in many developing countries. Other difficulties stem

from large differences between Western “best

practice” inscribed in the ERP system and ways of

doing business in developing countries (Hawari and

Heeks, 2010). The greater the misfit, the more

customisation is performed (Hustad et al., 2016).

Practitioners recommend redesigning processes prior

to choosing an ERP to ensure a better fit (Kimberling,

2012). In this study many cases of misfit were found

which are now described.

4.12 Strategically Important or

Required Functionality

Practitioners recommend customising ERP systems

for business processes that give you competitive

advantage (Kimberling, 2012). Customisation

enables the differentiation of a business unit and

therefore business units that are of high strategic

importance are known to request more customisation

(Haines, 2009; Rothenberger and Srite, 2009).

Despite the evolution of the ERP standard system that

brings along new functionality with every upgrade,

there are still a few areas where functionality was

lacking. Users that believe value adding business

requirements are not covered by standard

functionality motivate for the system change. This

could be a requirement to satisfy internal needs,

customers or auditors as shown in Table 10.

Table 10: Data Supporting Required Functionality.

“Our competitors had something similar and if we

didn’t have a like offering, our customers would have

gone to competitors instead of us” (U1)

“It wasn’t exactly a legal requirement of the affiliate

but it was more like a standard agreement with their

customers, that’s what the customer’s expected” (U1)

“we had to go customisation because SAP could not

give that to us but it was also an Audit requirement”

(U3)

4.13 Legislative Requirements

Certain industries can have laws and regulations that

are not covered by standard functionality (Hustad et

al., 2016). In the case of multi-national African

Company Z there were many modification requests

for legislative requirements as shown in Table 11.

Hence legislative requirements not covered in

standard functionality can drive modifications.

ICEIS 2018 - 20th International Conference on Enterprise Information Systems

116

Table 11: Data supporting legislative requirements.

“the customisations or the requests that we get are as a

result of, um, legislative requirements per country that

are different” (M2)

“Mozambique law now requires local currency and

exchange rate to be printed on all invoices where

document currency is not equal to local currency. I

have created a new column on SAP Form

Z_INVOICE_INT_MZ which is used to calculate the

local currency” (call log)

4.14 Country Differences

The affiliate country business partners brought about

various reasons for ERP programming. When new

affiliates are incorporated, they need to align with the

standard of the Head Office. Therefore, additional

configuration as well as the necessary development is

required. The language barriers between the different

countries presented a need for modification that

fulfilled the requirement for solutions to be delivered

in various languages (Table 12).

Table 12: Data supporting country differences.

“Our customisation, is let’s say in essence is more if

there is a new affiliate going in” (C2)

“the other challenges would be depends on the, the

level of the, the education levels and stuff in the, in the

affiliate and the experience of the people” (M2)

“changes to the ERP system is not always easy and

especially if you have a language barrier” (U2)

4.15 An Evolving Industry

Another new theme that was identified through

interviews was industry evolution which resulted in

modifications (Table 13). The organisation’s business

processes also changed with time leading to

modification to support the business change.

Table 13: Data supporting evolving industry.

I am happy with the keeping things standard, but SAP

needs to keep updating the standard so that it keeps

working to the way things are evolving (M3)

So there’s a lot of things because the industry is always

in a state of flux (U2)

5 CONCLUSION

There are various drivers of ERP customisation

reviewed in the literature but these studies mostly

focus on the implementation stage of the ERP system.

This study conducted at a single multi-national

African petroleum organisation described 15 factors

that impact ERP programming, in particular code

modification, post implementation.

In contrast to during implementation, users did not

resist changing processes from a position of fear or

lack of communication during post implementation.

While low ERP knowledge at implementation is

attributed to insufficient user training, at post-

implementation it is attributed to problems with user

handover and insufficient holistic business process

training. While literature notes that insufficient

involvement of operational departments during the

project results in increased customisation, in post-

implementation, involvement of operational

departments increases programming and business

tends to prefer bespoke solutions over standard

functionality.

Literature notes that external consultants who are

inexperienced or striving to maximise revenue can

increase customisation, while in post-implementation

organisations tend to have internal consultants who if

experienced can reduce ERP programming.

This study also described multiple requirements

for programming. ERP systems with standard

processes can never completely fit the processes of all

organisations irrespective of country, industry or

business model. Misfits were identified due to

legislation gaps, customer needs, country differences,

strategically differentiated processes and evolving

business needs. Also noted are problems with ERP

vendors not keeping up with the pace of evolving

industry changes.

From a practical perspective, following from

these 15 factors, the following recommendations for

organisations to reduce modifications are made.

Firstly all new requests need to go through an

appropriate approval process and secondly a

systematic process to remove modifications needs to

be employed. Yet these processes need to be

supported by organisational interventions. Firstly

ensuring that newly employed users receive

appropriate training and handover. Secondly, internal

consultants need to continuously keep up to date with

new functionality so they are able to identify where

standard functionality can be used and thirdly, top

management needs to support these interventions

This study was restricted to certain core financial

and logistics modules. In many cases post-

implementation was found to be different to during

the implementation phase. A limitation in this and

prior studies has been the ability to differentiate

between different forms of customisation and ERP

programming solutions. These solutions have

different impacts on long-term costs. While ERP

Managing Enterprise Resource Planning System Customisation Post-Implementation

117

modifications need to be reapplied and tested with

each upgrade, other solutions can be completely

upgrade proof and then there are many variants in

between. More research is needed that can

differentiate between these. While this paper focused

on ERP programming, more research is needed on

when standard processes should be adopted and when

organisations need to differentiate themselves.

Practitioners have referred to keeping a stable core

and a flexible edge. These areas are unclear and

organisations require guidance. Especially as Gartner

urges organisations to manage Bimodal IT, balancing

stability and exploitative behaviour with exploratory,

agile innovation (Horlach, Drews and Schirmer,

2016). Furthermore, the role of business process

management, process mapping and business

architecture in driving ERP projects is understudied.

REFERENCES

Antero, M. 2015. A Multi-case Analysis of the

Development of Enterprise Resource Planning Systems

(ERP) Business Practices. PhD Thesis, Copenhagen

Business School, Institut for IT-Ledelse, Department of

IT Management.

Aslam, U., Coombs, C., Doherty, N. 2012. Benefits

Realization from ERP Systems: the Role of

Customization. ECIS 2012 Proceedings. http://aisel.

aisnet.org/ecis2012/142

Braun, V., Clarke, V. 2006. Using thematic analysis in

psychology. Journal of Chemical Information and

Modeling, 53(9), 1689–1699. http://doi.org/10.1017/

CBO9781107415324.004

Brehm, L., Heinzl, A., Markus, M. L. 2001. Tailoring ERP

systems: a spectrum of choices and their implications.

Proceedings of the 34th Annual Hawaii International

Conference on System Sciences, 1–9. http://doi.org/

10.1109/HICSS.2001.927130

Brehm, L., Markus, M. L. 2000. The divided software life

cycle of ERP packages. In Proceedings of 1st Global

Information Technology Management (GITM) World

Conference, pp. 43-46.

Buonanno, G., Faverio, P., Pigni, F., Ravarini, A., Sciuto,

D., Tagliavini, M. 2005. Factors affecting ERP system

adoption: A comparative analysis between SMEs and

large companies. Journal of Enterprise Information

Management, 18(4), 384–426. http://doi.org/

10.1108/17410390510609572

Cao, J., Nicolaou, A. I., Bhattacharya, S. 2013. A

longitudinal examination of enterprise resource

planning system post-implementation enhancements.

Journal of Information Systems, 27(1), 13-39.

Chen, C., Law, C., Yang, S. 2009. Managing ERP

implementation failure: A project management

perspective. IEEE Transactions on Engineering

Management, 56(1), 157–170.

Davis, A. 2005. ERP Customization Impacts on Strategic

Alignment and System Agility. Proceedings of the

Southern Association of IS (SAIS), 249–255.

http://aisel.aisnet.org/sais2005/45

Esteves, J., Pastor, J. A. 2016. Towards a unified ERP

implementation critical success factors model. In

Proceedings of the Portuguese Association for

Information Systems Conference (Vol. 1, No. 1).

http://dx.doi.org/10.18803/capsi.v1.%25p

Fryling, M. 2015. Investigating the effect of customization

on rework in a higher education enterprise resource

planning (ERP) post-implementation environment: A

system dynamics approach. Journal of Information

Technology Case and Application Research, 17(1), 8-

40.

Hawari, A.A. Heeks, R., 2010. Explaining ERP failure in a

developing country: a Jordanian case study. Journal of

Enterprise Information Management, 23(2), pp.135-

160.

Haines, M. N. 2009. Understanding Enterprise System

Customization: An Exploration of Implementation

Realities and the Key Influence Factors. Information

Systems Management, 26(2), 182–198. http://doi.org/

10.1080/10580530902797581

Horlach, B., Drews, P., Schirmer, I. 2016. Bimodal IT:

Business-IT alignment in the age of digital

transformation. Multikonferenz Wirtschaftsinformatik

(MKWI), 1417-1428.

Hustad, E., Haddara, M. and Kalvenes, B. 2016. ERP and

Organizational Misfits: An ERP Customization

Journey. Procedia Computer Science, 100, 429-439.

Kholeif, A., Abdel-Kader, M. G., Sherer, M. 2007. ERP

customization failure: Institutionalized accounting

practices, power relations and market forces. Journal of

Accounting & Organizational Change, 3(3), 250–269.

http://doi.org/10.1108/18325910710820292

Kimberling, E. 2012. Why BPR Should Happen Before

Your ERP Implementation Available http://panorama-

consulting.com/five-reasons-why-business-process-

reengineering-should-happen-before-your-erp-

implementation/

Ko, D.-G., Kirsch, L. J., King, W. R. 2005. Antecedents of

knowledge transfer from consultants to clients in

enterprise system implementations. MIS Quarterly,

29(1), 59–85. http://doi.org/10.2307/25148668

Luo, W., Strong, D. M. 2004. A Framework for Evaluating

ERP Implementation Choices. ICEIS 2004 -

Proceedings of the Sixth International Conference on

Enterprise Information Systems, 51(3), 460–465.

http://doi.org/10.1109/TEM.2004.830862

Panorama Consulting. 2017. 2017 Report on ERP Systems

& Enterprise Software. Retrieved from

https://www.panorama-consulting.com/resource-

center/erp-industry-reports/2017-report-on-erp-

systems-and-enterprise-software/

Parthasarathy, S., Sharma, S. 2014. Determining ERP

customization choices using nominal group technique

and analytical hierarchy process. Computers in

Industry, 65(6), 1009–1017. http://doi.org/

10.1016/j.compind.2014.03.003

ICEIS 2018 - 20th International Conference on Enterprise Information Systems

118

Rothenberger, M. A., Srite, M. 2009. An investigation of

customization in ERP system implementations. IEEE

Transactions on Engineering Management, 56(4), 663–

676. http://doi.org/10.1109/TEM.2009.2028319

Yin, R. K. (2012). A (very) brief refresher on the case study

method. Chapter 1, Application of Case Study

Research, 3-20.

Zach, O. 2012. Identifying reasons for ERP system

customization in SMEs: a multiple case study. Journal

of Enterprise Information Management, 25(5), 462–

478. http://doi.org/10.1108/17410391211265142

Managing Enterprise Resource Planning System Customisation Post-Implementation

119