Access to Dissertation - Information...

Information School.

Access to Dissertation

A Dissertation submitted to the University may be held by the Department (or School) within which the

Dissertation was undertaken and made available for borrowing or consultation in accordance with

University Regulations.

Requests for the loan of dissertations may be received from libraries in the UK and overseas. The

Department may also receive requests from other organisations, as well as individuals. The conservation

of the original dissertation is better assured if the Department and/or Library can fulfill such requests by

sending a copy. The Department may also make your dissertation available via its web pages.

In certain cases where confidentiality of information is concerned, if either the author or the supervisor so

requests, the Department will withhold the dissertation from loan or consultation for the period specified

below. Where no such restriction is in force, the Department may also deposit the Dissertation in the

University of Sheffield Library.

To be completed by the Author – Select (a) or (b) by placing a tick in the appropriate box

If you are willing to give permission for the Information School to make your dissertation available in

these ways, please complete the following:

x (a) Subject to the General Regulation on Intellectual Property, I, the author, agree to this dissertation

being made immediately available through the Department and/or University Library for

consultation, and for the Department and/or Library to reproduce this dissertation in whole or

part in order to supply single copies for the purpose of research or private study

(b) Subject to the General Regulation on Intellectual Property, I, the author, request that this

dissertation be withheld from loan, consultation or reproduction for a period of [ ] years from

the date of its submission. Subsequent to this period, I agree to this dissertation being made

available through the Department and/or University Library for consultation, and for the

Department and/or Library to reproduce this dissertation in whole or part in order to supply

single copies for the purpose of research or private study

Name:

Laurids

Rudolph Als

Department Information School

Signed

Laurids Als

Date

29/08/20

15

To be completed by the Supervisor – Select (a) or (b) by placing a tick in the appropriate

box

(a) I, the supervisor, agree to this dissertation being made immediately available through the

Department and/or University Library for loan or consultation, subject to any special restrictions

(*) agreed with external organisations as part of a collaborative project.

*Special

restrictions

(b) I, the supervisor, request that this dissertation be withheld from loan, consultation or

reproduction for a period of [ ] years from the date of its submission. Subsequent to this period,

I, agree to this dissertation being made available through the Department and/or University

Library for loan or consultation, subject to any special restrictions (*) agreed with external

organisations as part of a collaborative project

Name

Department

Signed Date

THIS SHEET MUST BE SUBMITTED WITH DISSERTATIONS BY DEPARTMENTAL REQUIREMENTS.

Dissertation Laurids Rudolph Als - reg. no: 140136270 30/08/2015

Page1 of 66

Dissertation COVER SHEET (TURNITIN)

Module Code: INF6000

Registration Number 140136270

Family Name Als First Name Laurids Rudolph

Assessment Word Count: 12202. Coursework submitted after the maximum period will receive zero marks. Your assignment has

a word count limit. A deduction of 3 marks will be applied for coursework that is 5% or more above or below the word count as specified above or that does not state the word count.

Ethics documentation is included in the Appendix if your dissertation has been judged to be Low Risk

or High Risk. (Please tick the box if you have included the documentation)

A deduction of 3 marks will be applied for a dissertation if the required ethics documentation is not included in the appendix. The deduction procedures are detailed in the INF6000 Module Outline and Dissertation Handbook (for postgraduates) or the INF315 Module Outline and Dissertation Handbook (for undergraduates)


Page2 of 66

Faculty of Social Science - Information School

Master’s Dissertation in MSc Information Systems

Author: Laurids Rudolph Als

Supervisor: Miguel Baptista Nunes

September 2015


Page3 of 66

Abstract

Background

This dissertation is conducted due to a significant gap in research in the area of ERP post

implementation risks and change management, which should be researched to help reduce the high

failure rates of ERP projects.

Aims

The aim is to explore the areas of Risk Assessment and Change Management in order to produce a

Risk Ontology including all relevant ERP post-implementation risks and their respective Change

Management strategies. In addition this research seeks to develop a new framework that merges the

two concepts into one cycle that serves as a framework for executing an integrated risk assessment

and change management programme.

Methods

This project is executed by doing an extensive literature review that establishes relevant theory

regarding the intricacies of risk assessment and a deeper look into different frameworks for the

change process in current theory. This knowledge is then used to create a Risk Ontology that gets

further developed by measuring the risks against those found in nine case studies to discover the

most important areas of risk. Change Management interventions and strategies are then identified in

literature to compile a list of all the relevant measures and strategies that can be used to counter the

risks in the ontology. These measures are matched with the risks so the ontology makes the link

between the risks and the change management required to mitigate the respective risks.

Results

This research has developed both a new integrated framework for risk assessment and change

management, found in chapter 6, but also a risk ontology to be used within that framework in an

ERP post-implementation stage – the ontology can be found in chapter 4 and includes all relevant

risks and change management strategies related to them.

Conclusions

This dissertation has narrowed the gap in research in the area of post-implementation in ERP

projects by providing new knowledge by means of a risk ontology and a framework on how to

approach risk assessment and change management.


Page4 of 66

Table of Contents

Abstract ............................................................................................................................................................. 3

Acknowledgements ........................................................................................................................................... 7

1. Introduction and context ............................................................................................................................... 8

1.1 Research aims and objectives.................................................................................................................... 10

1.2 Methodology summary ............................................................................................................................. 11

1.3 Practicalities............................................................................................................................................... 12

1.4 Ethical Aspects ........................................................................................................................................... 12

2. Literature review ......................................................................................................................................... 13

2.1 The failures and successes of ERP implementations ............................................................................. 13

2.2 Risk Assessment ..................................................................................................................................... 14

2.3 Interdependencies in risks ..................................................................................................................... 15

2.4 A gap in research – post-implementation risks ..................................................................................... 16

2.5 Categorization of risks ........................................................................................................................... 16

2.6 Culture and how it affects risks ............................................................................................................. 16

2.7 Change management............................................................................................................................. 18

2.8 Establishing the ontology from literature ............................................................................................. 29

2.9 An integrated Risk Assessment & Change Management Model ........................................................... 29

3. Methodology .............................................................................................................................................. 32

4. Risk Ontology for ERP Post-Implementation ............................................................................................... 34

5. Change Management Strategies and Interventions .................................................................................... 39

5.1 Human Interventions ............................................................................................................................. 39

HI.A – Process Consultation ..................................................................................................................... 39

HI.B - Third-Party Interventions ............................................................................................................... 42

HI.C – Teambuilding ................................................................................................................................. 42

HI.D – Organisation Confrontation Meeting ........................................................................................... 43

HI.E – Intergroup Relations Interventions ............................................................................................... 43

HI.F – Large Group Interventions ............................................................................................................ 44

HI.G – Performance Management ........................................................................................................... 44

5.2 Techno-Structural Interventions ........................................................................................................... 46


Page5 of 66

TSI.A – Structural Redesign ...................................................................................................................... 46

TSI.B – Downsizing ................................................................................................................................... 46

TSI.C – Business Process Reengineering (BPR) ........................................................................................ 46

TSI.D – Total Quality Management (TQM) .............................................................................................. 47

TSI.E – Organisation Redesign ................................................................................................................. 47

TSI.F – Culture Change ............................................................................................................................. 47

TSI.H – Organization Learning ................................................................................................................. 48

TSI.I – Built-to-Change Organization (B2C) .............................................................................................. 48

6. Discussion of the Risk Ontology & the Final Framework ............................................................................. 48

7. Conclusions and Summary ........................................................................................................................... 51

7.1 Further Research ................................................................................................................................... 52

8. Appendix ...................................................................................................................................................... 53

Appendix 1 – List and description of case studies ....................................................................................... 53

Appendix 2 – Functional Structure .............................................................................................................. 60

Appendix 3 – Divisional Structure ............................................................................................................... 60

Appendix 4 – Matrix Structure .................................................................................................................... 61

Appendix 5 – Network Structure ................................................................................................................. 61

Appendix 6 – Organization Design .............................................................................................................. 62

9. Bibliography ................................................................................................................................................. 63

Academic Papers: ........................................................................................................................................ 63

Books ........................................................................................................................................................... 64

Case Studies................................................................................................................................................. 65


Page6 of 66

Table of Figures and Tables

Figure 1 taken from Lihong et al (2008) .......................................................................................................... 12

Figure 2 - Peng & Nunes (2010) ....................................................................................................................... 18

Figure 3 taken from Hayes (2002) p. 54 .......................................................................................................... 20

Figure 4 taken from Cummings & Worley (2009) p. 180 ................................................................................. 22

Figure 5 - Draft Risk Assessment & Change Management Cycle model ......................................................... 30

Risk Ontology Table…………………………………………………………………………………………………………………………………….34

Figure 6 - The Johari Window: http://www.designedalliance.com/reflections-in-your-johari-window/ ...... 41

Figure 7 - Final Risk Assessment & Change Management Cycle model .......................................................... 49



Figure 10 taken from Cummings & Worley (2009) p. 344 ............................................................................... 61




Page7 of 66

Acknowledgements

I would like to give thanks to my family for moral support during this project as well

as my supervisor Miguel Baptista Nunes for invaluable guidance and assistance –

This project would not have happened for either of you.

Laurids Als


Page8 of 66

1. Introduction and context

Risk assessment is an important part of most major ERP projects. The nature of these projects

naturally leads to great changes in organisations, information and people. These changes must be

handled in order to ensure a successful implementation. This kind of change management is often

key in making sure that a new ERP system is a productive investment for a company, rather than a

decision that ends up losing the company money. Sumner (2000) Risk assessment is therefore

essential in assessing what exactly may happen after an implementation of a new system. This

assessment will give the organisation the information it needs to take action and ensure that risks

are kept to a minimum and mitigated as effectively as possible. Additionally, risk assessment will

give the organisation the information it needs, to ensure it can achieve the maximum potential of the

positive aspects of such a new system. Bose et al. (2006)

A study referenced by Aloini et. Al. (2009) has found that on the scale of 7400 Information

Technology projects, 34% were late or over budget, 31% were abandoned, scaled back or modified,

and only 24% were completed on time and on budget. This indicates a clear issue in IT and IS

projects, when only so few are completed on time and budget. As Aloini et al. (2009) states,

properly handled risk assessment is one explanation for how the issue could be solved. Risks

themselves they define as “an uncertain effect on project performance. Thus, efficient, effective

project management requires appropriate management of all sources of uncertainty within the

project.” They also argue that quantitative or qualitative risk assessment is a process for guiding risk

management activities by collecting and evaluating data on the severity of the potential effects

consequent to a risk factor and its probability of occurrence. This idea makes the point that risks

should be categorized and evaluated in order to be able to tackle them effectively. Such

categorization would allow risks to be prioritized so focus could be put on the most severe and

likely risks and less effort focused to the risks that are unlikely to happen.

Another view of risk is that of Huang et al. (2004) who divide risk into several categories, and the

one pertinent to ERP implementations is speculative risk, which involves gain or loss by an

organisation. They state that the implementation of a system “has the potential to reap great rewards

if the software reinforces productivity. Conversely, it may cause a loss, i.e. loss of investment“.

Thus Huang seems to agree with Aloini in the respect that an ERP should be handled carefully as it

can be a great loss to a company if it is not handled correctly, and can then end up being a great

financial or organizational liability.


Page9 of 66

These sources agree that risks and how they are managed in an implementation have a great deal to

say on whether or not a project will be completed on time and budget or indeed completed at all. If

the risks are identified, assessed and handled in an implementation then this will reduce the damage

of the risk factor. This is the main notion to be aware of with regards to risk assessment and impact

analysis. Fabi (2008)

Risks themselves are evidently important to identify as sources mentioned agree on the danger of

not paying attention to risks and their possible effects on a project. Peng and Nunes (2009)

categorize risks by four different categories, not unlike the categorization by Huang et al. (2004)

which is merely more broad and place the IS risks in one category rather than four. The categories

proposed by Peng and Nunes (2009) are:

Operational Risks

o These risks refer to risks that may occur in day to day work functions in the business

use of the ERP.

Analytical Risks

o These risks refer to risks that exist when management use the ERP system to provide

analytical information, such as forecasts and other strategic tools.

Organisation-Wide Risks

o These risks are those that impact the entire company and may be related to both

internal and external factors such as the company’s own users of the system or

external vendors.

Technical Risks

o These are risks related to technical factors that can impact the performance and

functions of the ERP system.

These categories are helpful for dividing up the many different risks existing in a project. As

evident by the categories themselves there are many different risks that may be encountered and on

many different levels. They may be operational risks that can happen in everyday use of the system

or risks that only occur when the system is being used in a certain way such as forecasting

production values and so on. Categories are thus important for keeping track of these many risks.

It is important to note that the risks that will be identified and analysed are focused on post-

implementation risks and as such not general project risks such as delayed deadlines and so forth.

These risks will be analysed as there is a strong need to establish and develop the necessary change


Page10 of 66

management measures that are needed for an ERP project to be successful, as evident by the

concerning numbers of failing IT projects in the industry mentioned previously. Edwards (2007)

Due to the noted importance of handling risks, this kind of assessment, categorization, evaluation

and prioritization is essential and will ensure that the company will be able to mitigate and deal with

the risks and not least be prepared for their occurrence.

1.1 Research aims and objectives

An issue mentioned by Kuifan (2011) is that there is very little research done in risks that occur

post-implementation in an IS project, one of the main reasons for this research in that particular

area. Ideally, this dissertation will identify, categorize and evaluate risks that have occurred in a

number of case studies and in literature. Furthermore this research will seek to come up with ways

to counter the different risks and mitigate the damage they could potentially deal.

Research questions are proposed as follows:

What are the post-implementation risks involved in an ERP implementation?

What kind of change management actions are needed in order for the risks to be mitigated?

This would allow for the creation of an ontology of all these different post-implementation risks, as

well as measures that can be put into action to counter those risks and mitigate, if not remove them.

It will often be impossible to entirely remove risk; however mitigation is an effective way of

ensuring better performance and success of a new system. Choi et al. (2012) This ontology would

be usable in future ERP implementations in the post-implementation stage to mitigate and counter

those risks. This would be a powerful tool for project managers and IS professionals in order to

keep a checklist of what might happen in the project and how to make sure everyone is prepared for

the risks involved. This allows a change management team to put out countermeasures in a timely

pre-emptive action, as opposed to the “fire-fighting” reactive method of responding to risks as they

happen. The reason for this is that a reactive method is far more expensive and can lead to risks and

the consequences of those risks evolving into much bigger and far-reaching problems than they

would have been if expected and mitigated early. This, in turn, will improve the currently poor

succesrate of ERP projects and ensure that a project can be delivered on time, on budget and to the

specified user requirements.


Page11 of 66

The objectives of the research are as follows:

A literature review will be carried out of both theoretical sources and case studies in order

to establish a framework for analysing ERP post-implementation risks.

This allows a number of case studies to be analysed in ways of risks that can be identified,

categorized and analysed

The analysis of the ERP post-implementation risks can then be used to form ways of

countering and mitigating these risks

A framework will be created that can be used to facilitate Risk Assessment and Change

Management in an ERP post-implementation.

An ontology will be created that lists the different risks along with their mitigation

strategies and interventions that IS professionals can use to manage future projects.

1.2 Methodology summary



The research questions listed above can be answered by desktop research that will analyse

qualitative information that has been critically reviewed and considered. Theoretical information

regarding ERP implementation risks will be gathered and used to analyse and discuss the aspects of

risk involved in a number of case studies from the same sector. The case studies selected will all

have been carried out by third parties and found in academic databases and then analysed to reach

new findings in the area of ERP post-implementation risks. ERP systems are very relevant to

analyse as these are very common in the industry and as such there will be sufficient and relevant

information. Esteves (2009) The model below will be used as a framework for the methodology for

this research as it clearly establishes the different phases of the process, starting with the research

question which has already been put forward. This will then lead on to the critical literature review

as mentioned. Afterwards the key categories of ERP post-implementation risks will be identified

and the case studies selected. This leads to a critical analysis of these case studies and the literature

where risks will be identified and categorised. This leads to a critical review of the information

gathered where the risks can be analysed to provide countermeasures and thus an ontology can be


Page12 of 66

formed which will extend the current theory. In addition, the theory will also be analysed to create a

new framework for approaching risk assessment and change management together in an integrated

model.

Figure 1 taken from Lihong et al (2008)

1.3 Practicalities

There will be no travelling or expenses involved in gathering resources and information as this is a

desktop study that will gather all necessary materials from online academic databases and libraries.

1.4 Ethical Aspects

This research is low risk as all information will be gathered from previously conducted case studies

and new theory will be drawn from this. The only cases where companies and projects can be

identified are where the information is already publicly available in the shape of the case studies

themselves.


Page13 of 66

2. Literature review

2.1 The failures and successes of ERP implementations

Hendricks et. Al. (2006) note that ERP systems have very high costs and as such are high risk

projects, but they also argue that in their research they have found that despite failures in the

implementation of some of these systems they have not found evidence of persistent negative

performance in relation to the investment in these systems.

The failures of ERP systems and IS systems in general is a troubling trend since so many of these

projects either miss their deadline, budget or user requirements. As mentioned by Motwani et al.

(2002) a failed IS project can cause significant financial and organisational problems for a

company. They note that Hershey Foods Corporation in 1999 reported a 19% drop in 3rd

-quarter

profits and a 29% increase in inventories over the previous year due to order processing problems

that were directly caused by their faulty $112 million ERP implementation. There are many such

examples of companies that have lost considerable amounts of money by investing in ERP and then

having the project fail.

Karimi et al. (2007) agree with the notion that many companies have had significant losses due to

an unsuccessful ERP implementation, however, they also find that a successful implementation has

in many cases led to significant reduction in inventory and in administrative costs, and millions of

dollars in logistics savings at firms like Dow Corning, IBM and Texas Instruments. They find that

in cases where an implementation has been unsuccessful, like with Hershey Foods, AMR

Corporation and FoxMeyer – it is often due to one or more organisational, technological, user, task ,

or environmental factors that affect adoption, implementation and outcome of innovations. They

also suggest that the organisational and technological factors are the most important in determining

the outcome of an implementation.

The obvious debate and research being focused on these ERP projects prove that they are an

increasingly relevant method of progress towards cost-cutting and improving efficiency. C &

Beaumont (2002). With the failure rates being so high, risk assessment becomes that much more

important. Some research has been made in part to analysing IS risks on their individual merits and

these are mostly pre-implementation risks.

Due to this, further research is needed in ways of compiling all the different risks together in an

ontology that can be used by managers and IS professionals to mitigate the loss of efficiency and


Page14 of 66

resources that occur when a project is unsuccessful. This is the research that this study plans to

provide. In addition, it will focus primarily on post-implementation risks that previously have not

been studied in great detail. Now that many more IS projects have had time to mature and succeed

or indeed fail in the long term, there is material for researching into what happens after an ERP

system is implemented.

2.2 Risk Assessment

As mentioned previously by Aloini et. Al (2009), Huang et. Al. (2004) and Peng and Nunes (2009)

Risk Assessment is a key component in any major IS or ERP implementation. As these projects

often involve large amounts of resources, manpower and effort - much consideration will need to go

into making sure that possible losses are kept to a minimum.

The Risk Assessment Cycle can be split into 4 simple different stages:

Identify Risks

The first stage simply involves establishing what risks are present and can affect the project

in any way.

Mitigate Risks

This stage involves designing measures that can counter the risks identified and help

mitigate the damage they can deal as well as the likeliness that they will occur.

Implement Systems and Procedures

During this stage the measures will be introduced into the organisation and will then be able

to help mitigate risks that may be present during an ERP implementation.

Monitor

This involves monitoring whether the countermeasures in place for the risks of the project

are still effective and this should be reviewed as the project moves along, to ensure risk

management is always present if anything changes or if change management measures are

not effective.

As mentioned there is a lack of research in this area, with regards to post-implementation risks and

these are in need of studying in order to allow IS professionals to not only prepare a company for

pre-implementation risks but also how to handle what may happen after it has been implemented.


Page15 of 66

Previous research has, as noted, been mainly focused on evaluating risks individually and this

research shall also be used in this study in order to establish the theoretical framework which the

study will be built around. Other case studies and research papers has taken this approach as well,

such as Motwani et al. (2002) who argues that since ERP implementation is changing business

processes of companies that implement an IS, they felt that business process change theory may

prove useful in explaining the outcome of the case studies. This argument makes sense, as certain

risks that will be explored in this study are related directly to the impact the system has on the

business processes and how these will need to change to accommodate and adapt to the new system.

Huang et. Al (2004) concludes that “proper risk assessment requires an understanding of: (1) what

the actual risks are; and (2) which of these risks managers perceive to be more deserving of their

attention.”

This notion is important, as risk assessment is exactly that – an IS professional will never be able to

remove risk entirely, it is merely a case of which risks they want to take and how they should be

mitigated and countered. Another point to this is the case that some change management measures

may be optional but many will indeed be obligatory. Certain risks will be worth taking in each

individual project relative to the reward they provide. Other risks provide no benefits and exist

merely as a potential point of damage to the project. These risks in particular should be mitigated

and countered. Change management measures are necessary as a tool to ensure that the risks

involved do not evolve into consequences that inflict financial, or otherwise damaging effects to the

project and the company implementing the system.

2.3 Interdependencies in risks

Both Gattiker and Goodhue (2005) and Aloini et al (2009) agree that a key point in doing a risk

assessment is understanding risk factor interdependencies and the relationships of risk to direct and

indirect consequences. This is due to how interconnected risks and their effects are, as they often

have a domino or snowball effect that can mean that the consequence of one risk can lead to more

risks and thus can end up causing a lot of damage to a project or a company. These

interdependencies and relationships will be explored in this study in relation to the different risks in

order to ensure that project managers may use this research to identify not only the ERP post-

implementation risks and the way to counter them but also how the different risks can be

interrelated and what risks generally occur together. This is presented with a number of case studies

where it is identified which risks are critical and thus are important to the respective case study.


Page16 of 66

All in all, the lack of research in this area is damaging not only to IS professionals who could

benefit from the knowledge but also to their clients and employers who are often lead into a project

with a team that does not have the necessary knowledge. As noted by Hong and Kim (2001) the link

between an organisational fit of ERP and ERP implementation success is not empirically validated

and thus many ERP vendors merely ignore the organisational fit and urge the client to have an

invalidated trust.

2.4 A gap in research – post-implementation risks

Current research is as mentioned focused on pre-implementation IS risks (Peng and Nunes 2009)

and the gap that exists post-implementation is important to research, as all sources that have been

listed in this review give a view that an IS project is not only a large financial opportunity for a

company, it is also an extremely volatile project that can end up costing a company a large amount

of money or even do severe damage to its productivity and organisational structure. They agree that

risks should be evaluated thoroughly and their possible consequences investigated and prepared for.

The sources do not all agree on the categorisation of risks but these will often be specific to certain

projects. Gattiker and Goodhue (2005) and Aloini et al. (2009) are of the opinion that

interdependency is a key factor in risk assessment, where other researchers such as Peng and

Nunes(2009) support a categorisation of risks that makes them easier to evaluate and get an

overview of.

2.5 Categorization of risks

The different sources also have different opinions on the most crucial areas of risk, where Aloini et

al.(2009) believe it to be organisational and technical risks, and Peng and Nunes (2009) put the

focus on organisational risks alone and less so on technical risks.

This study will try to take all views in mind when conducting this research, as it makes a great deal

of sense to categorise as it ensures clarity and that no risks are left unchecked – which is very

important in these types of projects. This research will also be able to give a viewpoint of what

areas have the most critical risks; however, this will vary greatly dependent on the different case

studies, the individual projects and the circumstances that surround them.

2.6 Culture and how it affects risks

As noted by Johansson et al. (2014) several cultural factors can impact an organisation and how it

operates. These include Power Distance, Individualism and Uncertainty Avoidance. These factors


Page17 of 66

are stated to create “culture-specific disadvantages and advantages, which respectively increase or

decrease the relevance of their related ERP implementation critical success factors.” and are

particularly important with regards to change management measures as these may be heavily

influenced by cultural factors that can render them to have no effect. The importance of culture on

change management is the reason for it being discussed in this research as it cannot be ignored if

cultural factors may impact the implementation to such a great extent.

Another author who supports this view is Peng & Nunes (2010) who identify cultural barriers which

can heavily influence an ERP implementation, after the implementation has taken place. The model

presenting these barriers is shown below in figure 2. They are centered particularly on

implementations taking place in Asian cultures where issues such as preservation of face may be

regarded higher than other issues as it is culturally very important and can relate to Power Distance,

Individualism and the general values of Asian culture.


Page18 of 66

Figure 2 - Peng & Nunes (2010)

2.7 Change management

As it has been established, risk assessment is very important in any major ERP projects as they are

large scale and involve a large amount of risk, resources and people. As noted by Nafjan & Al-

Mudimigh (N/A) ERP implementations are mostly not about technology but about people and the

processes they carry out. As such it presents a number of risks that must be carefully handled

through customized and carefully chosen change management measures that suit the particular

organisation and their individual project and people. In order to establish the necessary change

management measures it should first be established what change management actually is and why it

is necessary. Hayes (2002) describes Change Management as being about modifying or

transforming organisations in order to maintain or improve their effectiveness. He argues that the


Page19 of 66

entire organisational environment has changed in recent years, particularly people’s relationships

with:

Things: Advances in technology has enabled replacing technology as opposed to mending

and updating it. This technical advancement increases the rate of obsolescence. In addition,

the ever changing work environments and technology adds a high level of uncertainty to the

future and thus makes it less viable to invest in things that will last.

Places: Many work environments are now changing much more than previously and this

adds another level of uncertainty to people’s comfort zone and means that they may be more

cautious about change as they will have lived through many changes they did not feel

positively about.

People: an increase in the number of relationships and a decrease in the duration of these.

This adds to the uncertainty of the work environment, particularly for IT companies as they

have a high amount of people going in and out of the company as many IT workers will shift

between companies every few years.

Organisations: Accelerating change has created a need in organisations for being

continuously adapting. According to Hayes (2002), this increased adaptability in the

organisations themselves, has strained the adaptability of the employees themselves.

Ideas: Hayes (2002) also argues that the entire knowledge system is undergoing many

changes and thus increasing the rate at which people must re-evaluate what their reality is

and indeed what their ideas about their work are now and in the future.

All these changes that Hayes (2002) discusses are very alike those discussed by Penfold (1999) and

Pugh (2007) who respectively talk about a society and workplaces that are more and more centered

around information and an ever-changing environment as well as how change in information

services has become the norm. Genus (1998) also notes the importance of this and puts focus on

adaptability and flexibility as it is necessary for modern companies to respond to market

requirements and that companies must do this in order to stay competitive. This change is

happening on a large scale that effects the entire IT and information sector in particular and thus

demands that new projects such as ERPs that are inserted into an organisation must be managed

carefully as otherwise the idea of staying competitive and adaptable will not be realised and the

project will instead have negative effects relative to the risks of the project.


Page20 of 66

In addition Penfold (1999) also speaks of how the users of a new system will quite often have a

significant resistance to change as it is part of human nature and this is a big part of why change

management is so essential to an implementation.

Hayes (2002) establishes a systematic framework for how to approach a change management

process as shown in the model inserted below. The different stages are as follows:

Figure 3 taken from Hayes (2002) p. 54

Recognition

The first stage is the recognition for change. It involves the need for change due to

internal circumstances or external events. This requires a great deal of perception,

interpretation and decision making that must be handled very carefully, if this fails to

happen, an organisation may not change when it is required or indeed change when it

is not required. Both of these will lead to an undesired state of the organisation that

is not in its best interests.

Start of the change process

The process often starts with a feasibility study or a review of the organisation. The

questions asked are

o Who to involve

o What to make public (if anything)

o Who should have management responsibility


Page21 of 66

These questions will form the basis of the project and from there decisions can be

made if external consultants should be involved, dependent on whether or not the

organisation has members with the necessary skills. Additionally, in this stage a

change management team should focus on establishing a desire for change within the

employees. This often involves unfreezing the organisation and gaining acceptance

of the need for change.

Diagnosis

o Reviewing the present state

o Identifying the future state

During this stage, the team will analyse the current state of the organisation and

establish what a desired future state looks like. A current state can be identified by

means of current processes, culture and generally what problems exist and the

reasons for these. A future state should include all desired changes and be allowed to

be the changes the organisation needs, even and particularly if they are radical.

However, a team should still keep in mind what is realistic.

Prepare and plan for implementation

The idea with this stage is to produce an implementation plan. This is done by

analysing the current and future states to establish all the things that need to be done

for the proposed changes to become reality. It is important to include both technical

and human aspects as the soft parts of an organisation are essential. This centres on

the users of a system who are likely to resist the change and therefore action must be

taken to ensure they accept the new system and the changes it brings.

Implement change

In this step the established changes are implemented, shifting focus to actual

implementation rather than planning. This will have to be done differently depending

on the type of project, but often an iterative approach is necessary as it may be

relatively unknown exactly what the end goal is and several attempts may be

necessary to achieve the changes that the organisation is looking for. This requires

the iterative approach where each step is completed and then reviewed to ensure this

was the desired result and direction.


Page22 of 66

Review and consolidate

It is important that changes are kept up so that employees do not fall back into their

old habits and as such a change process will often be reviewed regularly after

implementation to ensure the implementation sustains momentum. In addition the

new behaviours of the users must be reinforced to set them in stone. This is primarily

done with reward systems and feedback.

This model will be used as a base framework for the change process that will be further developed

in chapter 2.9. This will be done with the model and theory of Hayes (2002) supported by the

following model by Cummings and Worley (2009).

Figure 4 taken from Cummings & Worley (2009) p. 180


Page23 of 66

Cummings & Worley (2009) are another of the basic pillars of knowledge with regards to

Organisational Development which is a key feature of change management. The authors are highly

respected and referenced within the field and go into great detail regarding necessary change

management and present a model for the activities that contribute to effective change management.

The model is applicable to most ERP implementations as it is not this model that needs to be

customised, what needs to be customized are the individual measures, which are the interventions

themselves that will be implemented to achieve the goals described in this model. Cummings and

Worley’s theory and this particular model is often used as a framework for the change management

process and has a number of steps:

Motivating change

o Creating readiness for change

This is necessary as mentioned previously it is a basic part of human nature to resist

change and therefore it is necessary to prime the organisation for change by

sensitizing it to pressures for change.

This can be done by managers being open and frequently exposed to new

perspectives and views and possibly surround themselves with devil’s

advocates that may force them to think differently.

Another way to create readiness is to reveal discrepancies between the

current state of the organisation and the desired state they may have in their

vision. If this reveal shines a light on lacklustre performance or otherwise

problematic issues, this may help motivate members of the organisation to

embrace and seek change to ensure that the company vision is achieved.

Finally, a change management team should create positive but more

importantly, realistic expectations about the results of the change in the

organisation. If members have realistic expectations that they believe in and

are engaged in achieving, the process will run much smoother and the chance

of achieving those goals will significantly increase and according to

Cummings and Worley (2009) it will serve as a self-fulfilling prophecy.

o Overcoming resistance to change

The inevitable resistance that will always be present in ERP implementations

needs to be overcome and there are a number of ways to do this.


Page24 of 66

The first way is by providing empathy and support for the personnel

going through the changes by engaging them and understanding how

they are experiencing the change and what problems they are having

with it. This will demand the change management team to be

understanding and engage in active listening in order to ensure they

understand the concerns of the employees and try to find ways of

overcoming them. These concerns should not be lightly overturned as

many employees will likely have similar concerns and if dismissed

this will only increase their level of resistance.

The second way of overcoming resistance is to put a great deal of

focus on how information is communicated to the organisation

members. There is invariably going to be rumours and a lot of gossip

going around internally about the project and the changes it brings

and the team can counter this by communicating often and effectively

to ensure rumours are not fuelled and everyone involved are included

in the information stream.

Finally, the team should not neglect to involve all users of the system

and the organisation in the change process. If they are involved in

planning and implementing the changes it will allow them a sense of

ownership of the project as well as the fact that the organisation

members may see the issues from a practical point of view related to

their responsibilities and as such provide valuable feedback about

how the change should be implemented.

Creating a vision

o Describing the core ideology

A core ideology is important to materialize the vision for change. It will contain the

key values of the organisation and help define who they are. It is not to be what the

organisation perceives about itself, but rather what cannot be separated from the

organisation, such as family with Lego and wholesomeness and imagination with

Disney. Cummings and Worley (2009).


Page25 of 66

o Constructing the envisioned future

Bold and valued outcomes

Setting goals for performance and human outcomes can effectively serve as

goals for the change process and can help motivate employees by giving

them a goal that is easy to grasp and measure to reach by a certain time with

the help of the new ERP system. Cummings and Worley (2009) mention

BHAGs (Big, Hairy, Audacious Goals) which serves as tangible goals that

can be easily measured and will energize employees for organisation action.

Desired future state

This state should be defined as what is necessary to achieve the bold and

valued outcomes defined previously. It describes what the organisation

should look like in the future and is meant to motivate employees and draw

them into the future and into the vision of the company and what it is going

to be.

Developing political support

o Assessing change agent power

A change agent can be both an internal in an organisation or an external consultant.

Both internal and external agents will have to assess their power within the

environment in order to effectively use it to help the change process. According to

Cummings and Worley (2009) there are 3 important factors to note, namely

knowledge, personality and the support of others. Knowledge affects an agent’s

power mainly through what experience he or she has and therefore leads to them

having a greater impact and a more respected opinion. Personality is important as

charisma in particular plays a big role when it comes to motivating employees to

participate actively in the implementation and embrace the changes coming. The

support of others contributes to power in the sense that it allows for resource

networks and access to information that leaves the agent in a better position to do

their job.

o Identifying key stakeholders

Many entities may have influence in an organization; it may be managers, unions,

certain executives or even the customers. These groups should be identified and

mapped to show their influence and thus allow the change management team to


Page26 of 66

identify where they need to focus on gaining support, as not doing so can be a major

blow to the acceptance of the new system as stakeholders may have power to inflict

resistance to the changes.

o Influencing stakeholders

This step consists of gaining the support of the stakeholders that were identified in

the previous step. Three methods are mentioned by Cummings and Worley (2009)

that are particularly useful when attempting to influence these stakeholders. These

are: playing it straight, using social networks and going around the formal system.

Playing it straight is the most widely used and consists of determining the

needs of the stakeholders and presenting them with information on how the

changes benefit them. This strategy, however, relies on the change agent’s

knowledge base so that they may be able to persuade stakeholders that the

changes are a logical way of solving their problems.

Using social networks consists of making use of social contacts within the

organisation and forming alliances with individuals and groups that deal with

the key decision makers. This is often used in projects where unions and

management are in a great deal of power.

The final strategy, which is going around the formal system, involves

bending the rules to make the changes happen instead of removing the

barriers that are keeping them from being implemented successfully. This

strategy requires a very powerful change agent with charisma and a good

reputation to allow them to bend the rules with a minimum amount of

reprisals.

Managing the transition

o Activity planning

This involves making a road map for all the activities involved in the implementation

and change process to link tasks with the goals identified in the core ideology and

the desired future state. Cummings and Worley (2009) mention that the key things to

keep in mind are that it should gain management approval, be cost effective and

remain adaptable as feedback is received.


Page27 of 66

o Commitment planning

This activity involves identifying the key people whose support is needed and

planning how to gain their support during the transition.

o Change management structures

During the transition it is important to have someone leading the efforts and this

should include people who can mobilize resources for change and have the respect of

the leadership. This can be a chief executive, a project manager, a committee of

representatives or a natural leader that has the necessary impact and trust throughout

the organisation. This will be different from project to project and should be

determined based on the organisational environment, power structure and relations.

o Learning processes

Four processes may be used to enhance the learning of new skills that will need to

take place during an ERP implementation.

The first is a system view of the organisation that creates a model of work

and change that shows how different employees support the organisational

processes and thus they can see how they make an impact. This enhances

their motivation and overall understanding of why the changes are positive.

The second involves creating shared meaning that utilize models, language,

tools and processes that provide people with an understanding of why the

changes are necessary and what impact they have. Creating a common view

of the changes supports the organisation in tackling the changes in a united

front.

The third practice is about reflecting on change experience. This process

involves evaluating how the change process has gone and reviews if anything

should be done differently.

The fourth and final practice involves decentralizing implementation

processes to the lowest level. This is known as “local self-design” and means

that the lowest levels of the organisation has an impact on the change process

and is useful since top management will not have the same understanding as

the people doing the work every day.


Page28 of 66

Sustaining momentum

o Providing resources for change

A change process involves many extra activities and generally requires financial and

human resources. This is especially needed if the organisation continues to run day

to day operations while undergoing the change process. This is necessary as the

performance will most often dip and therefore extra resources will help reduce this

as well as support the change activities as much training and consultation will be

necessary.

o Building a support system for change agents

Change agents spend most of their time supporting the organisation and the

employees and as such will go through a lot of pressure and tension. It is therefore

recommended to ensure that they have a support network, perhaps of a shadow

consultant that allows them to bounce ideas and thoughts off someone that is not

involved in the project directly.

o Developing new competencies and skills

As many implementations involve the personnel learning new skills it is important to

facilitate this by ensuring that the necessary training courses, counselling and

coaching is available. Social skills may also be necessary for the changes to be

implemented successfully and should therefore not be overlooked.

o Reinforcing new behaviours

This can involve implementing a rewards system to ensure that employees are

continuously reinforcing their new behaviour and making it the new norm. If left

unchecked employees may revert to their previous ways of working and this can

render the changes unsuccessful.

o Staying the course

Many projects are abandoned early as performance declines but this should be

anticipated as major organisational changes do not happen overnight and as such the

process should be supported properly to ensure the changes have time to manifest

themselves and the employees have time to adapt to their new work processes.


Page29 of 66

This model covers issues relevant to the entire change management process and as such will be

utilized when further developing a new change management framework in chapter 2.9. These

frameworks also provide useful information for how to tackle the change process in general.

2.8 Establishing the ontology from literature

The categories that recur in all the sources mentioned so far are mainly the ones presented by Peng

& Nunes (2009) that categorise implementation risks into 4 categories, namely operational,

analytical, organisation-wide and technical risks. These have been used for categorising the risks

named in the literature which can then be measured up against the selected case studies. Doing this

ensures that any risks presented in the ontology are the risks that actually have relevance to ERP

implementations in industry-projects. The ontology can be found in chapter 4.

All these risks are compiled from Sumner (2000), Peng & Nunes (2009) and Lihong et al. (2008).

The reason for gathering risks from all these different sources is that different authors place focus

on different kinds of risks and therefore the risks belonging to those categories will be more

elaborate whereas other areas may be lacklustre. By gathering from multiple sources this ontology

gives a more broad view that covers all the categories in detail.

The operational risks found are centered mostly around the staff’s inability and unwillingness to use

the system as well as on whether the system has the correct information.

The analytical risks are centered around whether the system is used for the right purposes and thus

serves the necessary strategies and indeed if the system is capable of supporting those strategies

such as sales forecasts and financial budgets.

Organisation-wide risks vary greatly and cover most risks that would otherwise not fit into any

other category and generally includes the risks that affect the entire organisation with everything

from lack of top management to issues with data access rights.

Technical risks focus on the risks that solely deal with the technical performance of the system.

2.9 An integrated Risk Assessment & Change Management Model

All the information gathered in this literature review will now be used to create a new model that

integrates risk assessment into the change management process that both are part of the same way

of thinking and can easily be used in ERP projects to create a systematic approach to the risk and

change process.


Page30 of 66

Figure 5 - Draft Risk Assessment & Change Management Cycle model (Final model is presented in chapter 6)

The stages are outlined here:

Diagnosis

Reviews the current state of the organisation and establishes a desired future state for the

organisation to work towards with the changes coming.

Problem Recognition & Risk Identification

This method incorporates the initial change management stage of identifying problems

within the company and if it would need to change, with the first stage of risk assessment

which identifies risks within the project implementation that will need to be mitigated in

order to minimise any potential damage. The change management issues can easily be

categorised into:

o Organisational Issues

o Group-Wide Issues

o Individual Issues

Design Risk Mitigation

This stage deals with risk assessment and simply involves designing the mitigation

strategies necessary for the risks identified.

Implement Risk Mitigation Systems and Procedures

This involves implementing all the systems and procedures that have been developed to

mitigate the implementation risks identified.


Page31 of 66

Start of the Change Process

As mentioned previously, the start of the change process involves identifying who is going

to be involved with the project as well as preparing the organisation for change, particularly

by unfreezing the organisation. More information on this has been given previously.

Prepare and plan for implementation

This involves developing the interventions necessary for the change process to be successful

and these are split into two categories:

o Human Interventions

These focus on the soft element of the organisation, improving communication,

teamwork, decision making as well as obtaining and retaining talented employees.

o Techno-Structural Interventions

These interventions are focused on structural issues such as departmental

coordination, labour division, work design and power distribution.

Implement Change & Monitor Risks

During the implementation the team may need to take iterative approaches to tailor the

implementation to the organisation and their environment, so there will never be the same

approach for two different projects.

o Monitor Risks

It is important to monitor the risks throughout the project and at the end to update

with any changes discovered during the process so that the risk table is always up to

date to ensure that risks are mitigated properly.

Review & Consolidate

During this stage the process is reviewed to ensure that all changes match the desires of the

organisation as well as reinforcing the new behaviours introduced to the employees.

This model is developed further in chapter 6 with conclusions from the rest of this research.


Page32 of 66

3. Methodology



This dissertation seeks to answer the above research questions by means of a desktop study. As

mentioned in the methodology summary this is done to qualitatively gather information from a

number of case studies. The desktop study approach has been chosen to be able to analyse a number

of different case studies to get a more broad perspective. A field study would provide a more in-

depth look at an individual case study; however this approach would be very time consuming and

would not give as complete a picture.

An extensive literature review has been completed in chapter 2 to establish current theory regarding

the importance of risk assessment, what it contains and how it should be categorized. It also

establishes and identifies the most important risks in ERP post-implementation that are present in

current literature. The literature review also identifies important theory regarding change

management, how current theory believes it should be structured and what it should focus on -

Finally a new Risk Assessment & Change Management model has been developed to merge the two

concepts of risk assessment and change management. This has been done as the two are currently

treated as two separate process cycles, whereas it would be much more efficient to merge them into

one process as the two concepts have a relationship based on significant interdependency. This

model can then be used by project managers and change management professionals to structure a

risk assessment and change management process in an ERP project.

The case study approach has been chosen as this is a direct look into industry-relevant issues that

ensure that all risks and change management theory are relevant to the industry and not just for

theoretical purposes alone. This ensures that the link between the theory and the real-world issues

that are actually present in ERP implementations remains intact and therefore the paper will give a

realistic picture of the risks that can be expected in such a project.

9 Case Studies have been picked to give a broad look of ERP implementations, mainly focused on

manufacturers of various industries but with additional case studies such as a pharmaceutical and

footwear manufacturers that have been picked, as the issues in those have been deemed useful for

this piece of research. The case studies have been used to establish the most important issues in


Page33 of 66

industry-relevant examples and to help make it clear which risk areas contain the most crucial risks

in ERP post-implementation projects.

Most of the case studies chosen have not conducted a risk assessment of their own, an issue rooted

in the significance of this research. This means that the case studies themselves often do not directly

note what issues they have had during their ERP implementation but it will be determined based on

the project description and information found in the case studies. Solution strategies are noted,

which link to the change management strategies further in this paper. In some case studies the

issues are so broad that only the most important solution strategies are mentioned and a single case

study has been too broad for a specific set of change management strategies to be determined. A

description of all case studies and their change management issues and solutions can be found in

appendix 1.

These case studies have been used to match up the risks between risk assessment theory and the

risks that can be identified in actual case studies, to reveal which issues are the most represented

and to give an industry context to the risks. This is shown in the Risk Ontology for ERP Post-

Implementation in chapter 4.

A list has been developed in chapter 5 of the most important change management interventions and

strategies; this is based on current change management theory. This extensive list of interventions

and strategies has then been applied to the Risk Ontology for ERP Post-Implementation found in

chapter 4. This then ensures that the ontology not only identifies the most important and likely risks

in an ERP post-implementation project but also lists the necessary interventions to counter and

mitigate those risks. This ontology then serves project managers and change management

professionals in ERP projects in the post-implementation stage to help ensure risks are identified

and countered and thus helps ensure a successful implementation. This can then be used in

conjunction with the Risk Assessment & Change Management model in Chapter 6.


Page34 of 66

4. Risk Ontology for ERP Post-Implementation

√ is noted by case studies that either explicitly or implicitly are affected by the risk in the table. X

notes the risks that are not affecting the respective case studies. HI are Human Interventions and

TSI are Techno-Structural Interventions. These can be found in the Change Management section

and are uniquely identified by letter. 1-9 are the identifiers for the case studies and are found in

appendix.

Operational

Staff

Risks

Syste

m

Risks

1

2

3

4

5

6

7

8

9

10

Operational staff

are reluctant to use

the system

Operational staff

input incorrect data

to the system

Sales staff are not

able to obtain

needed data and

information from

the system

Accounting staff

are unwilling to

release accounting

responsibility and

power to non-

account staffs

Non-accounting

staff are

unwilling/incapabl

e to take up

accounting

responsibilities

Lack of champion

Fail to maintain

up-to-date and

comprehensive

customer info files

System contains

inaccurate supplier

records

System contains

inaccurate or

incomplete bill of

materials

System contains

inaccurate

inventory records

1

√

√

√

X

X

√

X

√

√

√

2

√

√

√

X

X

√

√

√

√

√

3

√

√

√

X

X

√

√

√

√

√

4

√

√

√

√

√

√

√

√

√

√

5

√

√

√

X

X

√

√

√

√

√

6

√

√

√

√

√

√

√

√

√

√

7

√

√

X

√

X

√

X

X

X

X

8

√

√

√

X

X

√

√

√

√

√

9

√

√

√

X

X

√

√

√

√

√

HI A,C,D

,G

G

G

A,B,C

,D,E,

G

A,B,C

,D,E,

G

A,C,D

TSI D,F,H

D

D

D

D


Page35 of 66

Analytical

Staff

Risks

Syste

m

Utiliza

tion

Risks

11

12

13

14

15

16

17

18

Front-line

managers

refuse to use

the system

Managers

cannot

retrieve

relevant and

needed

information

from the

system

Fail to use

the system to

generate

accurate sales

forecasts

Fail to utilize

the system to

predict

demands of

new products

System fails

to support

sales

personnel to

provide

special sales

promotion to

existing

customers

System fails

to generate

appropriate

master

production

schedule

System fails

to generate

appropriate

material net

requirement

plan

Fail to use the

system to

generate

appropriate

financial

budgets

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

X

√

√

√

√

√

√

√

X

√

√

√

√

√

√

√

√

√

√

√

X

X

X

X

X

X

X

√

√

√

√

X

X

X

X

X

X

√

√

X

X

√

√

√

A,C,D

,G

G

G

D,F,H

D

D

D

D

D

D

D

Organisation

-wide

Person

nel

Risks

19

Top managers

make

important IT

decision

without

√

√

√

√

√

X

√

√

√

A,B,D

,G

F,H


Page36 of 66

20

21

22

23

24

25

26

27

consulting IT

experts and

system users

Failure to mix

internal and

external

expertise

effectively

Lack of

proper

management

control

structure

Top managers

do not

provide

sufficient

support to

ERP post-

implementatio

n

Fail to form

an efficient

cross-

functional

team to

continuously

review the

system

Lose qualified

IT/ERP

experts

Lose ERP-

related know-

how and

expertise

accumulated

over time

Users (both

staff and

managers) do

not receive

sufficient and

continuous

training and

reskilling

Users are

uncomfortabl

e to input or

retrieve data

from the

system

√

√

√

√

√

√

√

√

X

√

√

X

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

X

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

A,B,D

,G

D

A,B,D

,G

G,B,C

G,B,C

G

G

F,H

A,E

H,I

F,H

H


Page37 of 66

Develo

pment

Risks

Risk

Assess

ment

Risks

Misc.

Risks

28

29

30

31

32

33

34

35

36

Cannot

receive

sufficient and

proper

consulting

advice from

system

consultants

Direction for

further ERP

improvement

and

development

is unclear

Budget and

fund assigned

to ERP post-

implementatio

n is

insufficient

Ineffective

risk

identification

and

assessment

Ineffective

planning for

risk

mitigation

and/or

avoidance

Failure to

redesign

business

processes

Ineffective

communicatio

ns

Lack of

sensitivity to

user

resistance

Conflict

between user

departments

√

√

√

√

√

√

√

√

√

X

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

X

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

X

√

X

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

A,C,D

,F

D,F

A,B,C

,D,E

A,D,G

A,B,C

,D,E,F

D

H

B,D

C,D,F

C,D,F

C,D,H

,I

A,E,F,

H

D,F,H

,I

Technical

Comp

atibilit

y

37

Failure to

follow an

enterprise-

wide design

which

√

√

√

√

X

√

√

√

√

A,D

D,H,I


Page38 of 66

Risks

Techni

cal

Develo

pment

Risks

38

39

40

41

42

43

44

45

46

supports data

integration

Legacy

systems are

not

compatible

with new ERP

systems

bottlenecks

attempting to

build bridges

to legacy

applications

Invalid data is

not

automatically

detected when

getting into

the system

Hardware or

software crash

Technical

bugs of the

system are not

overcome

speedily

Legacy and

duplicated

data is not

properly

managed

Failure to

adhere to

standardized

specifications

which the

software

supports

ERP-related

problems are

not reported

promptly by

users

Cannot

receive

sufficient

technical

support from

system

vendors

X

X

√

√

√

√

√

√

√

√

√

√

√

√

√

X

X

√

√

√

√

√

√

√

X

√

√

√

√

√

√

√

√

√

√

√

X

X

√

√

√

√

√

√

√

X

X

X

√

√

√

X

X

√

√

√

X

√

√

√

X

√

√

√

√

√

√

√

√

X

√

√

√

√

√

√

√

√

X

√

√

A,D

D,G

D,G

D,G

D,G

D,H,I

D

D

D

D

D

D

D

D


Page39 of 66

Syste

m

Design

Risks

Data

Access

Risks

47

48

49

Overcomplica

ted designs

that may

result in

extremely

heavy and

complex

systems

Data access

right is

authorised to

inappropriate

users

Confidential

data is

accessed by

unauthorized

people

√

√

√

√

√

√

√

X

X

√

√

√

√

X

X

√

X

X

X

√

√

X

X

X

√

X

X

D,G

D

D

D,H

D

D

5. Change Management Strategies and Interventions

Interventions are the main tool that change management teams use to counter and mitigate risks and

they are placed into two categories: Human Interventions and Techno-Structural Interventions.

These are explained in more detail in the description of the Risk Assessment and Change

Management model developed in chapter 2.9. A number of interventions will now be identified that

can be used to counter the risks identified in the ontology. Cummings and Worley (2009) is the

primary source for these interventions with Hayes (2002) as a supporting source. “Consultant” and

“change management team” will be used as a term for the person(s) handling the change process

and have no difference in meaning with regards to the interventions.

5.1 Human Interventions

HI.A – Process Consultation

Process Consultation is a framework that aims to assist managers, employees and groups

assess their internal and external human processes such as communication, interpersonal

relationships, decision making and task performance. They are inserted to aid employees in

how problems should be tackled rather than the consultant tackling the problem themselves.

Cummings and Worley (2009) speak of a number of key concepts:

o Always stay in touch with the current reality


Page40 of 66

A consultant whether external or internal, should always keep up to date with data

about the client and the project in its current state as well as their own reactions,

thoughts and feelings about it.

o Access your ignorance

A great deal of information comes from the practitioner’s knowledge of what is

known, what is assumed and what is unknown. He or she should be aware that they

themselves are “an instrument of change”.

o Everything you do is an intervention

Every exchange between a change management team and employees can give

impressions of the situation, the project, as well as the problems in the organisation

and should be treated as such with great attention to all communications.

o The client owns the problem and the solution

o Timing is crucial

A client or users of a new system will have times where they are more likely to be

positive to a change or new information and this should be kept in mind as bad

timing can lead to entirely different and undesired results.

o Be constructively opportunistic with confrontive interventions

A consultant should be willing to take risks in order to seize moments for members

of an organisation where they may be able to clearly show them what issues they are

facing and thus provide clarity to those users.

o Everything is information

Errors will always occur and are the prime source for learning. A consultant or

change management team will never encapture everything and mistakes will be

made – how those mistakes are handled and what information is extracted from them

is important to the success of the project.

o When in doubt, share the problem

A basic intervention is to promote openness so that team members may share any

issues they have, to get input from their colleagues and thus reach a solution.

HI.A.1 - Individual Interventions

This intervention involves members of the project or the organisation on an

individual level and is designed to improve and promote effective communication

between the individual and others. This assesses how the individual communicates


Page41 of 66

during meetings and with their colleagues in general. The consultant will then seek

to make the individual aware of how they communicate and what they could

improve. A model that assists this process is The Johari Window as shown in figure

5 below. This model is particularly good for highlighting that some means of

communication may only be visible to others and the individual may not be aware of

them. The model is better applied in American or European settings and may not be

appropriate in different cultural settings.

Figure 6 - The Johari Window: http://www.designedalliance.com/reflections-in-your-johari-window/

HI.A.2 - Group Interventions

These interventions aim to improve the processes, content and the structure of the

members of the organisation as a group. Cummings and Worley (2009).

Process Interventions consist of sensitizing members to their internal

processes by making comments, questions or observations about

relationships in between the group and its members, the way the group solves

problems and how it operates.

Content Interventions help determine what the group works on by means of

comments, questions or observations about group membership, agenda

setting, review and testing procedures, interpersonal issues and conceptual

inputs on task-related topics.

Structural Interventions works in the same way as the previous two and aims

to address the methods the group uses to accomplish tasks and deal with


Page42 of 66

issues. The comments, questions and observations will focus on: inputs,

resources, methods for determining goals, developing strategies,

accomplishing work, assigning responsibility, monitoring progress,

addressing problems, relationship with authority, formal rules and levels of

intimacy.

HI.B - Third-Party Interventions

These interventions seek to resolve issues between two or more people internally in the

organisation. These issues can arise in many ways and is inherent in groups.

Cummings and Worley (2009) mention four strategies for dealing with these issues and

conflicts.

o Avoiding or blunting factors of ignition – This involves arriving at a clear

understanding of the issue and what triggers it and putting into place measures that

avoid or blunt those factors from happening.

o Set limits on the form of conflict – Informal gatherings before a formal meeting or

setting rules for when specific parties can interact can limit the amount of conflicts

between certain parties.

o Coping – This involves speaking to the parties involved and helping them reach a

way of coping with the conflicts so that they do not disrupt their environment.

o Eliminate the issue – This involves removing the roots of the problem, while this

may seem the easiest and best way to deal with an issue it is often not a viable

solution.

HI.C – Teambuilding

These interventions are aimed at improving relationships between members of the

organisation, improving interpersonal and problem solving skills as well as increasing team

performance.

HI.C.1 – Diagnosis

The diagnosis part of team building involves using assessment instruments such as

team surveys, interviews and observations to understand how the group operates.


Page43 of 66

HI.C.2 – Improvement

These methods are used to improve the issues found in the diagnosis part. Actual

team building activities will not be provided in this study as they should be

customized to the project at hand and there are many sources to be found on this

topic. Examples of ways of measuring the performance of individuals in team

building activities are given below:

Individual Coaching and Feedback

360 degree feedback

Third-party conflict resolution

Team building is on a group level used to improve group vision, mission, purpose

development, role clarification and decision rights.

HI.D – Organisation Confrontation Meeting

This intervention is aimed at mobilizing resources of the organisation to identify problems

and work on solving them. This is effective in bringing together an organisation, particularly

if there is a disconnect between top management and lower levels of the organisation. It

involves bringing together all departments of the organisation in order for everyone to have

a say with regards to what issues are present in the company and how they believe they

should be solved. There should be a great deal of focus on everyone being honest so that all

important issues can come to light.

HI.E – Intergroup Relations Interventions

These two interventions are aimed at solving problems between groups within the

organisation, such as different departments. These relationships should be attended to, in

order to ensure maximum organisational effectiveness.

HI.E.1 – Microcosm Groups

These are similar to Organisation Confrontation Meetings but differ in the way that

while groups are again formed to solve problems in the organisation, particularly

those related to company culture, structure and work processes – with microcosm

groups the group is run parallel in the way that the groups themselves are tasked with

diagnosing and analysing problems in the organisation, but a change management

team will observe the groups and diagnose the problems by looking at how the


Page44 of 66

members of those groups communicate and act during meetings and other

interactions.

HI.E.2 – Resolving Intergroup Conflict

Intergroup conflict revolves around conflicts between two groups or two departments

within the organisation. This conflict can both be negative and positive, as in some

cases conflict can promote competitiveness and be constructive, while in other cases

it merely breeds negative emotions and a defensive attitude towards other

departments where interdependence and coordination may be needed. This

intervention puts the two groups in conflict together and asks that they describe

themselves, the other group and how they think the other group would characterize

them. Then they are brought together to formulate ways of dealing with their

misconceptions and the issues that exist between them. This method makes it easier

to highlight issues that users themselves may not realise they are affected by, as well

as providing different viewpoints of the situation.

HI.F – Large Group Interventions

These interventions are much alike the Organisation Confrontation Meetings, but different

in scale as they typically involve large parts of, if not the entire organisation and they focus

on issues that affect the entire organisation such as developing new products, environmental

change, redesigning the organisation or introducing new technology and systems.

HI.G – Performance Management

Performance management is a process of defining, assessing, developing and reinforcing

employee work behaviour and outcomes. This intervention is effective in ensuring employee

development. This is important when change is due in an organisation, to ensure that

employees understand what changes are happening and why, as well as reassuring them of

their position within the new system. This is done by means of clear communication above

all else but also by means of goal setting, performance appraisal, reward systems and

training. If employees feel they are being involved in the new environment they will be

much less likely to resist a new system and the changes it brings.

HI.G.1 – Goal Setting

Goal setting is an important tool in setting a direction for any organisation but it also

influences employees to think in ways of those goals and work towards those goals.


Page45 of 66

Working toward a challenging yet realistic goal is often mentioned as a performance

booster among employees. The fact that the goals are challenging but realistic is key,

as the goals must present a challenge or the employees will not push themselves,

likewise if the goal is not realistic they will not push themselves as they do not see

the goal as being obtainable.

HI.G.1.0 – Management by Objectives

Managing by Objectives (MBO) is a commonly used strategy within goal

setting, and it simply involves aligning the organisation’s goals with the

employees’ personal goals. This is done by meetings that merge the personal

goals and the organisational goals to ensure one shared perception of the

goals and increase engagement to reach them.

HI.G.2 – Performance Appraisal

This intervention is a feedback system which creates the link between goal setting

and reward systems. Employees will have their performance measured and receive

feedback to match up with reward systems. This ensures that an employee is

rewarded for performance with the reward system and is one of the most common

tools for improving performance in organisations.

HI.G.3 – Reward Systems

Reward Systems are the final link in the employee performance process where they

are rewarded dependent on their performance. Rewards often include enriched jobs,

opportunities for decision making, base pay, stock options, bonuses, gain sharing,

promotions and benefits. These reward systems should be customized to the

organisational culture as different environments will value different kinds of

rewards. For instance, in some organisational cultures a pay rise reward will not have

an effect on employee satisfaction whereas enriched jobs may provide a significant

boost.


Page46 of 66

5.2 Techno-Structural Interventions

TSI.A – Structural Redesign

Structural Redesign is an important techno-structural intervention that is used to ensure that

an organisation’s structure matches that of a future strategy implemented alongside the new

ERP system. There are a number of structures that can be adopted such as:

o The Functional Structure, which promotes technical specialization, flexibility of

deployment as well as career development and communication. A model of this

structure is found in appendix 2.

o The Divisional Structure, which reduces complexity, focuses on divisional outcomes

and clients, allows diversification of skills and training as well as ensuring

accountability and departmental cohesion. A model of this structure is found in

appendix 3.

o The Matrix Structure, which emphasises cross functional product focus, flexibility,

functional learning and adaptability to environmental changes. A model of this

structure is found in appendix 4.

o The Network Structure, which enables a highly flexible and adaptable approach to

dynamic environments. It focuses resources on customer and market needs and

enables rapid global expansion. A model of this structure is found in appendix 5.

TSI.B – Downsizing

Downsizing is an intervention that aims to reduce the size of an organisation by means of

layoffs, redeployment, early retirement or by reducing the number of organisational units or

managerial levels by outsourcing, reorganisation or delayering. This is normally done due to

a merge or acquisition that has rendered jobs redundant. Another reason can be an

organisational decline in revenue or environmental or technological changes that lead to a

need for reducing the size of the organisation. It can also be necessary when a new

organisational structure is implemented, as seen in the previous intervention. Cummings and

Worley (2009)

TSI.C – Business Process Reengineering (BPR)

BPR is a key intervention in the implementation of ERP systems, as these bring about such

large changes to the work processes of an organisation. This change in work processes most


Page47 of 66

often demand a reengineering of the business processes of the company. This requires

fundamentally thinking about how business is conducted and how it can be redesigned to

suit the new system and thus be more efficient. With an ERP implementation this often

involves employees gaining new responsibilities as new options open up with this new

technology.

TSI.D – Total Quality Management (TQM)

TQM is an approach that can be included in a company strategy. It puts a great deal of focus

on quality. This is done by training, informing and empowering employees. This ensures

that employees throughout the organisation are empowered to enforce quality in the business

processes they deal with. Rewards should be tied to effectively ensuring quality results and

products that not only meet but exceed customer expectations.

TSI.E – Organisation Redesign

Organisational Redesign is an intervention that involves several change management

processes and strategies mentioned in previous interventions. The difference is that an

organisational redesign is broad and involves many different aspects. This redesign involves

reconfiguring organisational structure, work design, HR and management practices. A

model can be found in appendix 6 that shows the different parts to focus on, in redesigning

an organisation. These include business strategy, strategic fit, organisation structure, HR

practices, work design, management processes and design fit. These will not be explained in

detail as it is an extensive process.

TSI.F – Culture Change

Changing the culture of an organisation can be a powerful tool in shaping employee beliefs

and actions, but it is also a challenging one as culture is often deeply embedded in the

organisation and its employees. In order to successfully change the culture of an

organisation, Cummings and Worley (2009) note that it is important to formulate a clear

strategic vision to bring the change. Top management has to show a commitment and lead

the change by example. The organisation may need remodelling where necessary to

facilitate the new culture. It is also noted that it may be necessary to terminate deviants of

the new culture and ensure that new hires fit accordingly.


Page48 of 66

TSI.H – Organization Learning

This intervention focuses on improving an organisation’s ability to adapt, develop and share

knowledge internally. This becomes increasingly important as business environments are

ever changing and therefore renewal within businesses should not be ignored. Elements of

this intervention are increased focus on teamwork and favouring self-managing teams which

supports the sharing of information and continuous development of skills and knowledge.

This should be implemented across the entire business from the CEO to the lower levels of

the organisation.

TSI.I – Built-to-Change Organization (B2C)

This intervention is about building an organisation from the ground up to be flexible and

adaptable as opposed to stabile. This shares many elements of organisation learning but goes

much further in ensuring that all elements of the company are built to be ever changing

determined on new information and changes in the environment they operate within.

6. Discussion of the Risk Ontology & the Final Framework

All the information that has been gathered throughout this research has been used to develop the

Risk Ontology for ERP Post-Implementation. This has successfully brought together Risk

Assessment and Change Management in an easily readable ontology that connects risks with the

change management strategies and interventions that are used to counter and mitigate them.

However, the risk ontology will never be enough on its own for a given project. While it covers

most risks that can be expected, individual projects can have different circumstances that lead to

risks that are either not mapped in the ontology or risks that are present in the ontology but with

different circumstances, that may require a different approach in change management to mitigate

them. This is due to the fact that no two projects are the same and as mentioned previously many

factors will influence these projects.

The Ontology gives a thorough overview of risks in an ERP post-implementation, but it should be

used to give an idea of what to expect, as well as a checklist, if a change management team is

unsure if all risks have been identified. In addition, it should be used as a lookup tool, to find out

what change management strategies are relevant to the risks a certain project is facing.


Page49 of 66

Much like the risks, a change management team should not assume that all change management

strategies listed here needs to be used, or indeed that they do not need any other strategies or tools

than the ones listed – instead the environment of the current project should be analysed to ensure

that the strategies make sense in the target environment and will be an efficient mitigation tool for

the post-implementation risks they face.

The knowledge gathered thus far can now be used to further develop the Risk Assessment &

Change Management model that was presented in chapter 2.9.

Figure 7 - Final Risk Assessment & Change Management Cycle model

The difference between the draft model and this final model is the fact that the implementation and

monitoring stage has now been split into two phases that contain the Human Interventions and the

Techno-Structural Interventions respectively. Both processes still contain risk monitoring as this

should always be kept in mind as risks often change throughout an implementation.

The reason for splitting this stage into two processes is the fact that the Human interventions and

the Techno-Structural interventions are inherently separate as they deal with very different risks.

While these two processes deal with very different issues, they should still be run in parallel,

implementing the interventions together, as this makes for a more efficient roll-out. In addition it

makes the transition easier for employees to deal with, as they do not need to continuously adapt to

an ever-increasing amount of changes – rather they will have to get used to one set of changes


Page50 of 66

implemented at once. Running the processes in parallel also means that it can be done in less time;

however, it does require more resources as change management teams will have to be big enough to

run both implementations at the same time.

The model, in its final form, successfully merges risk assessment and change management into one

work cycle, one process. This combines two areas that traditionally have been dealt with separately

or not at all. This combined model ensures an efficient change process in a project and thus keeps

the risks of an implementation and the change management required to mitigate them tightly

interlocked without losing any aspects that were dealt with when the two areas were treated

separately. This means that all risks threatening to impact a project are identified and are treated

with the right change management strategies so the implementation may be successful.

This model of the Risk Assessment & Change Management Cycle can be used in conjunction with

the Risk Ontology of ERP Post-Implementation to help ensure a successful post-implementation

stage of a project.


Page51 of 66

7. Conclusions and Summary

All in all, this dissertation has discussed the area of risk assessment and change management. A

literature review has established important factors to take note of when conducting these processes

and structures have been established from literature. Additionally, a model has been created to

merge risk assessment and change management into one cycle. A risk ontology has been created in

chapter 4 on the basis of the literature review, with all relevant post implementation risks. These

risks were then measured against nine case studies, to see which risks were present in case studies

of ERP implementations from different projects. The case studies themselves were described to

establish the most important areas of risk in each study. From all this, a number of change

management strategies were identified that could be used to counter and mitigate the risks present

in the ontology. These solutions were listed under the relevant case studies, but more importantly

the risk ontology was updated, listing all the relevant risks and their change management

countermeasures together. This ontology can be used by project managers and change management

professionals alike to get an overview of what risks to expect post implementation of an ERP

system and how to counter and mitigate these. There have been many differing opinions on the

most important areas of risk in these implementations, but the area that has contained the most

critical risks in this study has been the organisation-wide risks, while the technical risks have not

presented as much of an issue as other case studies have found.

The research questions were:



Both questions have been explored in depth and answered with the Risk Ontology for ERP Post-

Implementation that lists all the important risks, as well as their relevant change management

strategies used to counter them. In addition a new framework has been developed to merge Risk

Assessment and Change Management into one cycle. There is a gap in the area of post-

implementation ERP projects and this research has made an attempt to close that gap by extending

the theory on how to handle that stage.


Page52 of 66

7.1 Further Research

While this study has provided insights in the area of post implementation risk assessment and

change management in ERP implementations, further research is required into the risks that were

not present in the selected case studies. Among those are issues related to power and transfer of this,

due to the new technology, issues of data access, as well as issues more pertinent to retail

companies such as sales promotions and so on. These issues have not been marginally present in the

9 chosen case studies and this would be beneficial to research in the future to give a more complete

picture.


Page53 of 66

8. Appendix

Appendix 1 – List and description of case studies

Case study 1 – Neway Valve Manufacturer

Author: Bose et al. Link: http://dx.doi.org/10.1016/j.im.2008.02.006

This case involves a Chinese valve manufacturer by the name of Neway. This company had issues

with the data obtained from their current ERP system which was not accurate or timely and as such

hindered their operations. Due to this they elected to implement an E-SCM system and an Oracle

database management system to work together with their existing ERP system. The new systems

meant that the company would face a number of significant changes and challenges, mostly

centered on changing the basic work processes that employees would undertake. This means that

the change management issues that are mostly in focus are those centered on how the personnel

react to the new technology. As it is a rather large scale project, handling these changes is important

and range from the personnel being prepared and ready to accept the new processes, a number of

issues with legacy data and the format of these fitting on new hardware as well as various

organisational issues. These issues can range from anything like managers making decisions

without consulting the necessary team members as well as members not having skills in certain

areas. However, the case study mentions that focus was put on management having a hands-on

approach to ensure business processes were realigned wherever necessary.

Solution strategies:

HI:

A, B, D, G

TSI:

F, H

http://dx.doi.org/10.1016/j.im.2008.02.006


Page54 of 66

Case study 2 – LG Electronics

Author: Sobyaninja & Mockuté Link: http://mdh.diva-

portal.org/smash/get/diva2:433002/FULLTEXT01.pdf

LG is one of the largest electronics manufacturers in the world and launched a five year project in

2010 to launch an Oracle E-Business Suite to unite the company as they have a large amount of

departments and subsidiaries that previously have used many different ERP systems, which has led

to much confusion and ineffective work processes when information has had to have been

integrated and translated between systems. The new system has been implemented to unite all

business functions under the same system to ease communication and give a more complete

overview of the company to management. This can overall improve productivity, reduce

maintenance costs and would be a great improvement to the eight different ERP systems in use at

the time of project launch. The change management issues that can be expected in a project of this

size cover most of the risks in the literature ontology as the system is a complete overhaul and

implementation across such a large company with wide reaching business functions and processes.


Too general to pinpoint.

Case study 3 – Pharmaceutical & Footwear Manufacturers

Author: Motwani et al Link: http://dx.doi.org/10.1016/S0925-5273(01)00183-9

This case study consists of two cases from a pharmaceutical company and a footwear manufacturer

respectively. Both companies had seen significant financial growth and were in need of an ERP

system to modernize their work processes to service their customers better.

The pharmaceutical company was focusing on modernizing their inventory management and as

such their issues were mainly focused around building a bridge between their legacy software and

the new ERP system to ensure better inventory management. This did however not go as planned

and the company ended up having severe difficulties as the system was much more advanced than

the current software. This could be attributed to poor training and integration into the company.

http://mdh.diva-portal.org/smash/get/diva2:433002/FULLTEXT01.pdf


http://dx.doi.org/10.1016/S0925-5273(01)00183-9


Page55 of 66

Other issues are however still relevant such as employees resisting the changes and the work

processes not being sufficiently redesigned.

The Footwear manufacturer was implementing a system to drastically improve their production and

inventory management as the current system had customer service representatives being left unable

to check stock immediately and could not get accurate information from the system in a timely

manner. This had a significant impact on customer service and the competitiveness of the company

and therefore they decided to implement an ERP system to handle all business processes and they

implemented with a partial rollout that saw certain subsystems released earlier to get employees

used to them and improve them wherever necessary. The change management issues in this case are

similar to those of the pharmaceutical company.


HI:

G

TSI:

A, B, C, D, E

Case study 4 – Pratt & Whitney Canada

Author: Tchokogue et al Link: http://dx.doi.org/10.1016/j.ijpe.2003.11.013

Pratt & Whitney Canada develops, manufactures and markets turboprop, turbofan and turboshaft

engines for industry use. They are reported to have a market share in their sector of about 24% at

the time of the case study. As the market of this company is highly competitive, they wanted to

improve their customer response time, reduce work in progress, increase inventory turnover and

increase visibility of inventory and operating costs. This project is quite a large scale project, as the

implementation affected more than 3000 employees in all departments of the company. The

implementation made heavy use of change management, utilizing change champions to support the

changes from within. In addition they took a systematic approach to business process reengineering.

Due to the scale of the project, most risks within the literature ontology are present in this

http://dx.doi.org/10.1016/j.ijpe.2003.11.013


Page56 of 66

implementation, albeit the company has taken many change management actions to counter these

risks and this has ensured a successful implementation. The risks related to redesigning business

processes and managing the resistance from employees are the most important in this particular case

study.


HI:

G

TSI:

C

Case study 5 – Alpha Heat Exchanger Manufacturer

Author: Fabi Link: http://dx.doi.org/10.1108/14637150810888064

Alpha is a small company specializing in producing heat exchangers. The company has 23

employees including 12 managers and had a turnover of €4 million in 2014. Their work processes

were mainly based around manual options as opposed to digital and the only IT packages they had

was a Microsoft Word/Excel package and software for accounting management and payrolls. In

addition most employees of the company were not used to using computers, which complicated

matters of implementing a new system. Management decided to implement an ERP system to

improve operational effectiveness and to know the value of its capitalized stocks. In addition they

wanted to automate production planning using a method other than the Excel sheet they were

currently using. Due to the low level of IT in the company, the change management issues and risks

are not focused around legacy software but instead focus on resistance from personnel, the redesign

of business process and finally successfully utilizing the system to create production planning

schedules and other operational activities.


HI:

A, C, D, F, G

http://dx.doi.org/10.1108/14637150810888064


Page57 of 66

TSI:

A, C, E, F, H

Case study 6 – Shagang Group

Author: Nunes & Peng Link: http://dx.doi.org/10.1108/17410381111099833

Shagang Group is a major Chinese privately owned enterprise group and is one of the ten largest

steel producers in the world. The group employs about 26.700 staff and ranks second after Lenovo

in China’s private enterprise groups. The company has had multiple ERP implementations: first an

Oracle solution in 1997 – This solution led to a number of crucial problems since it did not support

the company’s rapid expansion and could not be properly integrated with other systems and

applications. This lead Shagang Group to implement a second ERP system from SAP in 2003,

however, this solution is reported as not satisfying all business requirements. Due to this, the group

now utilizes diverse ERP modules provided by SAP, Oracle and Ufida. This is an interesting case

study that shows change management issues and risks particularly in the area of handling the

management of the project, the development risks involved as well as a lack of communication

between departments internally and the external consultants employed.


HI:

A, B, D, G

TSI:

A, D, E, F, H

http://dx.doi.org/10.1108/17410381111099833


Page58 of 66

Case study 7 – King Saud University

Author: Nafjan & Mudimigh Link: http://www.jatit.org/volumes/research-

papers/Vol23No2/5Vol23No2.pdf

The case study of King Saud University focuses on an ERP implementation project named Madar.

This project was formed to implement a new ERP system to improve the university’s overall IT

structure. The system was designed to handle financial, human resource/payroll, administrative

communications, inventory control and warehouse and employee service. Due to the fact that this

system is being implemented in a university, the change management issues are centered around the

resistance of the users. Resistance was reported from employees that were concerned that they

would not be able to use the new system and thus lose their value to the organisation. Another thing

that worried the future users was the reasoning behind the changes as well as the implications that it

will have. A change management team was set up to manage the process and provided

communication between the management team and the employees that were going to be using the

system. A great deal of focus was put on the employees in the financing department that felt they

were being threatened and action was taken to ensure that they received extra training and were

offered reassurances of their role.


HI:

A, D, G

TSI:

C, D, F, H

Case study 8 – Rolls Royce

Author: Yusuf et al Link: http://dx.doi.org/10.1016/j.ijpe.2003.10.004

Rolls Royce formed a partnership with an external consultancy (EDS) in 1996 to implement SAP in

the organisation. This was done as the company had a large number of legacy systems, which were

all expensive to update and maintain as well as the effect it had of separating departments into their

http://www.jatit.org/volumes/research-papers/Vol23No2/5Vol23No2.pdf




Page59 of 66

own units, as the different systems could not communicate. As Rolls Royce is a rather large

company, most risks in the literature ontology apply – however, resistance to change as well as

compatibility issues were expected to be a particular issue as the legacy systems had been used for a

long time. In addition to this, the structural changes and the needed change of business processes

was also a high risk as this was necessary for SAP to work effectively within the company.


HI:

G,

TSI:

C

Case study 9 – Automobile Supply Manufacturer

Author: Motwani et al Link: http://dx.doi.org/10.1016/j.compind.2005.02.005

In this case study, an automobile supplier was part of a larger group and inherited an Information

System from their parent company. This system was suited for a decentralized manufacturing

environment, but as the company grew, it developed a centralized supply chain and therefore the

system was no longer suitable. In addition, the system had been abandoned for future development

and it was therefore hard to update and maintain. This project is vulnerable to most risks in the

literature ontology but the necessary business process changes are the highest risk within this

particular case along with the resistance to change from the employees.


HI:

G

TSI:

C, H, I

http://dx.doi.org/10.1016/j.compind.2005.02.005


Page60 of 66

Appendix 2 – Functional Structure


Appendix 3 – Divisional Structure



Page61 of 66

Appendix 4 – Matrix Structure


Appendix 5 – Network Structure



Page62 of 66

Appendix 6 – Organization Design



Page63 of 66

9. Bibliography

Academic Papers:

Aloini et al. (2009) Risk assessment in ERP projects. Information Systems pp. 183-199. Retrieved

24 April 2015 from http://dx.doi.org/10.1016/j.is.2011.10.001

Bhandari et al. (2005) Analysing the Penetration of Knowledge Management Practices in

Organisations Through a Survey of Case Studies. Proceedings of the 4th

European Conference on

Research Methodology for Business and Management Studies (ECRM 2005), Université Paris

Dauphine, Paris, France. 21-22, pp. 37-45. Retrieved 23 May 2015.

C., J. Michael Tarn David & Yen Marcus Beaumont. (2002) Exploring the rationales for ERP and

SCM integration. Industrial Management & Data Systems, Vol. 102 Iss 1 pp. 26 – 34. Retrieved 23

May 2015 from http://dx.doi.org/10.1108/02635570210414631

Choi et al. (2012) Implementation of fashion ERP systems in China: Case study of a fashion brand,

review and future challenges. International Journal of Production Economics, Vol 146 pp. 70-81.

Retrieved 24 April 2015 from http://dx.doi.org/10.1016/j.ijpe.2012.12.004

Edwards, H. Keith. (2007) System Utilization and Changes in Implemented Information Systems: A

Case Study. International Journal of Computer Science. Retrieved 24 April from

http://www.jourlib.org/paper/2314765#.VWBvpk8n_RY

Esteves, J. (2009) A benefits realisation road-map framework for ERP usage in small and medium

sized enterprises. Journal of Enterprise Information Management, Vol. 22 pp. 25–35 Retrieved 23

May 2015 from http://dx.doi.org/10.1108/17410390910922804

Gattiker , Thomas F & Dale L. Goodhue. (2005) What happens after ERP implementation:

understanding the impact of interdependence and differentiation on plant-level outcomes. MIS

Quarterly. Vol. 29, No. 3. pp 559-585. Retrieved 24 April 2015 from

http://www.jstor.org/stable/25148695

Hendricks et al. (2007) The impact of enterprise systems on corporate performance: a study of ERP,

SCM and CRM system implementations. Journal of Operations Management. PP. 65-82. Retrieved

24 April 2015 from http://dx.doi.org/10.1016/j.jom.2006.02.002

http://dx.doi.org/10.1016/j.is.2011.10.001

http://dx.doi.org/10.1108/02635570210414631


http://www.jourlib.org/paper/2314765#.VWBvpk8n_RY

http://dx.doi.org/10.1108/17410390910922804


http://dx.doi.org/10.1016/j.jom.2006.02.002


Page64 of 66

Hong, Kyung-Kwon & Young-Gul Kim. (2002) The critical success factors for ERP

implementation: an organizational fit perspective. Information & Management. Iss 40 pp 25-40.

Retrieved 24 April 2015 from http://dx.doi.org/10.1016/S0378-7206(01)00134-3

Huang et al. (2004) Assessing risk in ERP projects: identify and prioritize the factors. Industrial

Management & Data Systems, Vol. 104 Iss 8 pp. 681 – 688. Retrieved 24 April 2015 from

http://dx.doi.org/10.1108/02635570410561672

Johansson et al. (2014) The Role of Organizational Culture On ERP Implementation. Retrieved 24

April 2015 from

http://www.pacis2014.org/data/IWITIF%20submissions%20proceedings/index.html

Karimi et al. (2007) The Impact of ERP Implementation on Business Process Outcomes: A Factor-

Based Study. Journal of Management Information Systems, Vol. 24, No. 1 pp. 101- 134. Retrieved

23 May 2015 from http://www.jstor.org/stable/40398884

Lihong et al. (2008) Supporting decision making in risk management through an evidence-based

information systems project risk checklist. Information Management & Computer Security, Vol. 16

Iss 2 pp. 166 – 186. Retrieved 24 April from http://dx.doi.org/10.1108/09685220810879636

Peng, Guo Chao and Miguel Baptista Nunes. (2009) Identification and assessment of risks

associated with ERP post-implementation in China. Journal of Enterprise Information

Management, Vol. 22 Iss 5 pp. 587-614. Retrieved 24 April 2015 from

http://dx.doi.org/10.1108/17410390910993554

Peng, Guo Chao and Miguel Baptista Nunes. (2010) Interrelated Barriers and Risks affecting ERP

Post-Implementation in China. Retrieved 24 April 2015 from

http://www.computer.org/csdl/proceedings/hicss/2010/3869/00/09-13-05.pdf

Sumner, M. (2000) Risk factors in enterprise-wide/ERP projects. Journal of Information

Technology. Iss 15 pp 317-327. Retrieved 24 April 2015 from

http://www.tandfonline.com/doi/abs/10.1080/02683960010009079

Books

Cummings, Thomas G and Christopher G. Worley. (2009) Organization Development & Change.

USA: Cengage Learning. Retrieved 18 June 2015.

http://dx.doi.org/10.1016/S0378-7206(01)00134-3

http://dx.doi.org/10.1108/02635570410561672

http://www.pacis2014.org/data/IWITIF%20submissions%20proceedings/index.html


http://dx.doi.org/10.1108/09685220810879636

http://dx.doi.org/10.1108/17410390910993554

http://www.computer.org/csdl/proceedings/hicss/2010/3869/00/09-13-05.pdf

http://www.tandfonline.com/doi/abs/10.1080/02683960010009079


Page65 of 66

Genus, A. (1998) The Management of Change, Perspectives and Practice. Oxford: Thomson

Business Press. Retrieved 18 June 2015.

Hayes, J. (2002) The Theory and Practice of Change Management. London: Palgrave Macmillan.

Retrieved 18 June 2015.

Penfold, S. (1999) Change Management for Information Services. UK: Bowker-Saur. Retrieved 18

June 2015.

Pugh, L. (2007) Change Management In Information Services. England: Ashgate Publishing

Limited. Retrieved 18 June 2015.

Case Studies

Bose et al. (2006) ERP and SCM systems integration: The case of a valve manufacturer in China.

Information & Management. Iss. 45 pp 233-241. Retrieved 20 June 2015 from


Fabi, Placide Poba-Nzaou Louis Raymond Bruno. (2008) Adoption and risk of ERP systems in

manufacturing SMEs: a positivist case study. Business Process Management Journal, Vol. 14 Iss.

4 pp. 530 – 550. Retrieved 20 June 2015 from http://dx.doi.org/10.1108/14637150810888064

Kuifan et al. (2011) Risks affecting ERP post-implementation: Insights from a large Chinese

manufacturing group. Journal of Manufacturing Technology Management, Vol. 22 Iss 1 pp. 107 –

130. Retrieved 20 June 2015 from http://dx.doi.org/10.1108/17410381111099833

Motwani et al. (2002) Succesful implementation of ERP projects: evidence from two case studies.

International Journal of Production Economics, Vol 75 pp. 83-96. Retrieved 20 June 2015 from

http://dx.doi.org/10.1016/S0925-5273(01)00183-9

Motwani et al. (2005) Critical factors for succesful ERP implementation: Exploratory findings from

four case studies. Computers in Industry, Vol 56 pp. 529-544. Retrieved 20 June 2015 from



http://dx.doi.org/10.1108/14637150810888064

http://dx.doi.org/10.1108/17410381111099833

http://dx.doi.org/10.1016/S0925-5273(01)00183-9



Page66 of 66

Nafjan, Abeer N and Abdullah S. Al-Mudimigh. (N/A) The Impact of Change Management in ERP

System: A Case Study of Madar. Journal of Theoretical and Applied Information Technology.

Retrieved 20 June 2015 from http://www.jatit.org/volumes/research-

papers/Vol23No2/5Vol23No2.pdf

Sobyanina, Elena and Ilona Mockuté. (2011) ERP post-implementation risk assessment – A study

of LG Electronics company. Retrieved 20 June 2015 from http://mdh.diva-

portal.org/smash/get/diva2:433002/FULLTEXT01.pdf

Tchokogue et al. (2003) Key lessons from the implementation of an ERP at Pratt & Whitney

Canada. International Journal of Production Economics, Vol 95 pp 151-163. Retrieved 20 June

2015 from http://dx.doi.org/10.1016/j.ijpe.2003.11.013

Yusuf et al. Enterprise information systems project implementation: A case study of ERP in Rolls-

Royce. International Journal of Production Economics, Vol 87 pp 251-266. Retrieved 20 June

2015 from http://dx.doi.org/10.1016/j.ijpe.2003.10.004







Application 004695Section A: Applicant detailsSection A: Applicant details

Created:Mon 8 June 2015 at 12:30

First name:Laurids

Last name:Als

Email:[email protected]

Programme name:MsC Information Systems

Module name:Information Systems ModellingLast updated:17/06/2015

Department:Information School

Date application started:Mon 8 June 2015 at 12:30

Applying as:Undergraduate / Postgraduate taught

Research project title:Risk Assessment and Associated Change Management in ERP implementations

Section B: Basic informationSection B: Basic information

1. Supervisor(s)

Name Email

Miguel Nunes [email protected]

2: Proposed project duration

Proposed start date:Mon 8 June 2015

Proposed end date:Tue 1 September 2015

3: URMS number (where applicable)

URMS number- not entered -

4: Suitability

Takes place outside UK?No

Involves NHS?No

Healthcare research?No

ESRC funded?No

Involves adults who lack the capacity to consent?No

Led by another UK institution?No

Involves human tissue?No

Clinical trial?No

Social care research?No

5: Vulnerabilities

Involves potentially vulnerable participants?NoInvolves potentially highly sensitive topics?No

Section C: Summary of researchSection C: Summary of research

Section C: Summary of researchSection C: Summary of research

1. Aims & Objectives

Research questions are proposed as follows: What are the implementation risks involved in an ERP implementation? What kind of change management actions are needed in order for the risks to be mitigated?

The research will be focused on implementation risks in Enterprise Resource Planning systemsalso known as ERPs. It is important to note that these risks are not project management risks perse such as project delays etc. The risks are focused on the change management area of animplementation. These risks present a significant threat to the implementation of a newInformation System and as such will be identified and analysed by looking at a number of casestudies found in academic databases and libraries. This will allow for further analysis of theserisks in relation to a project as well as identifying change management measures and actions thatcan be taken to minimize and mitigate these implementation risks and thus improve the chance ofa successful implementation. This will allow a compendium to be made of all the identified risksalong with the measures that can be taken to counter them.

2. Methodology

The research questions can be answered by desktop research that will analyse qualitativeinformation that has been critically reviewed and considered. Theoretical information regardingERP implementation risks will be gathered and used to analyse and discuss the aspects of riskinvolved in a number of case studies from the same sector. The case studies selected will allhave been carried out by third parties and found in academic databases and then analysed toreach new findings in the area of ERP implementation risks. ERP systems are very relevant toanalyse as these are very common in the industry and as such there will be sufficient andrelevant information. The methodology starts with the research question which has already beenput forward in this research proposal. This will then lead on to the critical literature review asmentioned. Afterwards the key categories of ERP implementation risks will be identified and thecase studies selected. This leads to a critical analysis of these case studies where risks will beidentified and categorised. This leads to a critical review of the information gathered where therisks can be analysed to provide countermeasures for the risks identified and thus a compendiumcan be formed which will extend the current theory.

3. Personal Safety

Raises personal safety issues? No

Pesonal safety management

- not entered -

Section D: About the participantsSection D: About the participants

1. Potential Participants

This research will analyse already completed case studies and as such will not identify any newparticipants to interview.

2. Recruiting Potential Participants

As mentioned previously this research is a desktop study that will analyse already completed casestudies and as such will not include any new participants, merely existing research is to beanalysed and form new theory.

2.1 Advertising methods

Will the study be advertised using the volunteer lists for staff or students maintained by CiCS? No

- not entered -

3. Consent

Will informed consent be obtained from the participants? (i.e. the proposed process) No

This will not be necessary for reasons stated above.

4. Payment

Will financial/in kind payments be offered to participants? No

- not entered -

5. Potential Harm to Participants

What is the potential for physical and/or psychological harm/distress to the participants?

No contact will be made to any participants, case studies will be referenced appropriately and assuch there is zero risk in this regard.

How will this be managed to ensure appropriate protection and well-being of the participants?

See above.

Section E: About the dataSection E: About the data

1. Data Confidentiality Measures

The research is focused on implementation risks and as such will not be discussing any personaldata.

2. Data Storage

All data generated by this project will be controlled and analysed by Laurids Als.

Section F: Supporting documentationSection F: Supporting documentation

Information & Consent

Participant information sheets relevant to project?No

Consent forms relevant to project?No

Additional Documentation

140136270.pdf (Document 009395) The final dissertation proposal has been enclosed and should provide any additionalinformation that may be needed.

External Documentation

- not entered -

Offical notesOffical notes

- not entered -

Section G: DeclarationSection G: Declaration

Signed by:Laurids AlsDate signed:Mon 8 June 2015 at 13:22

Downloaded: 25/08/2015 Approved: 17/06/2015

Laurids Als Registration number: 140136270 Information School Programme: MsC Information Systems

Dear Laurids

PROJECT TITLE: Risk Assessment and Associated Change Management in ERP implementations APPLICATION: Reference Number 004695

On behalf of the University ethics reviewers who reviewed your project, I am pleased to inform you that on17/06/2015 the above-named project was approved on ethics grounds, on the basis that you will adhere tothe following documentation that you submitted for ethics review:

University research ethics application form 004695 (dated 08/06/2015).

If during the course of the project you need to deviate significantly from the above-approved documentationplease inform me since written approval will be required.

Yours sincerely

Matt Jones Ethics Administrator Information School

https://www.shef.ac.uk/ris/other/gov-ethics/ethicspolicy/approval-procedure/review-procedure/changes-made-after-approval

Access to Dissertation - Information...

Documents

Transcript of Access to Dissertation - Information...