EVALUATION OF ENTERPRISE RESOURCE PLANNING IMPLEMENTATION AND USE: A CASE

STUDY OF SYSTEMS APPLICATIONS AND PROGRAMMING IMPLEMENTATION AT THE

COMMON MARKETS EASTERN AND SOUTHERN AFRICA BANK (COMESA BANK), NAIROBI,

KENYA.

Ken Lukongodo

A project Dissertation submitted in partial fulfillment of the regulations governing the award of the degree

of M.Sc in Management of Information Technology, University of Sunderland 2003.

Project Supervisor: Norman Parrington.

Abstract

This paper reports on a case study of an enterprise resource planning (ERP) system implementation in a

financial institution. Many organisations embark on ERP projects without appreciating typical issues and

problems that may be encountered during the implementation. This has resulted in many unforeseen

difficulties being experienced by would be implementers resulting in numerous cases of implementation

failures.

In January 2002 the eastern and southern African trade and development bank, unveiled its latest

application acquisition SAP/R3, although the project had been 6 months late the system went live with no

hitches. Post implementation reviews offers organisation the ability to take stock of what has happened and

chart the way forward based on lessons learned. Both quantitative and quantitative techniques were used to

analyse the data collected on management and user satisfaction, system selection criteria, implementation

objectives and system penetration

The paper establishes that the ERP implementation in this organisation is a success and points out the

factors that contribute to this. Users who see SAP R/3 as a positive contribution towards their working

environment have accepted it. Management, users and the implementation partners all have a role to play in

the implementation of SAP R/3. The system has already brought tangible benefits to the organisation. SAP

R/3 is poised as the system of choice to propel the organisation into the information age.

i
Table of Contents
Abstract............................................................................................................................................................ i
Table of Contents............................................................................................................................................ ii
1. Introduction ............................................................................................................................................ 1
1.1. Research area .................................................................................................................................. 1
1.2. Research Questions......................................................................................................................... 2
1.3. The research site ............................................................................................................................. 2
1.4. Project Justification & significance ................................................................................................ 3
2. Literature Review ................................................................................................................................... 5
2.1. What is ERP.................................................................................................................................... 5
2.2. History of ERP................................................................................................................................ 6
2.3. ERP Vendors .................................................................................................................................. 7
2.4. Reasons for ERP Implementation................................................................................................... 8
2.5. Benefit Dimensions ........................................................................................................................ 9
2.6. Implementation ............................................................................................................................. 12
2.7. Dimensions of ERP implementation............................................................................................. 18
3. Critical Success Factors........................................................................................................................ 21
3.1. Project Team Selection and Management..................................................................................... 21
3.2. Top Management Support ............................................................................................................ 23
3.3. ERP Package/Vendor Selection.................................................................................................... 23
3.4. Change Management .................................................................................................................... 24
3.5. Effective Communication ............................................................................................................. 25
3.6. Monitoring and Evaluation of Performance.................................................................................. 26
3.7. Business Plan and vision............................................................................................................... 27
3.8. Education and Training................................................................................................................. 28
3.9. Cost Control.................................................................................................................................. 28
3.10. Data Accuracy and Systems Testing......................................................................................... 29
4. Methodology......................................................................................................................................... 30
4.1. Case Study .................................................................................................................................... 30
4.2. Sample Selection .......................................................................................................................... 31
4.3. Data Collection Methods .............................................................................................................. 31
4.4. Materials Distributed. ................................................................................................................... 31
4.5. Questionnaire Structure ................................................................................................................ 31
4.6. Questionnaire Content .................................................................................................................. 32
4.7. Secondary Data Review................................................................................................................ 32
4.8. Problems Encountered and Solutions ........................................................................................... 32
5. Data Analysis and Results .................................................................................................................... 33
5.1. Research Analysis Tool ................................................................................................................ 33
5.2. Respondents Analysis ................................................................................................................... 33
5.3. Duration of Using SAP in the organisation .................................................................................. 34
5.4. User Roles in the System .............................................................................................................. 34
5.5. Modules Used ............................................................................................................................... 35
5.6. Amount of Time of SAP............................................................................................................... 36
5.7. Rating of Usability of SAP ........................................................................................................... 37
5.8. Reporting ...................................................................................................................................... 38
5.9. Education and Training................................................................................................................. 39
5.10. Technical Support..................................................................................................................... 41
5.11. Communication......................................................................................................................... 42
5.12. Overall Systems Assessment .................................................................................................... 43
5.13. Project Management ................................................................................................................. 44
5.14. Objective Achievement............................................................................................................. 45
5.15. Business Process....................................................................................................................... 46
5.16. Controlling and Risk Management. .......................................................................................... 46
5.17. Project Outcome ....................................................................................................................... 47
5.18. Selection Criteria ...................................................................................................................... 48
5.19. Assumptions. ............................................................................................................................ 49

ii
6. Discussion............................................................................................................................................. 49
6.1. Limits of Study ............................................................................................................................. 52
7. Conclusions and recommendations ...................................................................................................... 52
8. References ............................................................................................................................................ 52
AcknowledgementsAppendix I – Questionnaire .......................................................................................... 58
Appendix I – Questionnaire.......................................................................................................................... 59
Appendix II – Interview Schedule ................................................................................................................ 60
Appendix III – Data Analysis ....................................................................................................................... 61
Appendix IV – Project Schedule .................................................................................................................. 62

iii
1. Introduction
1.1. Research area

The uncontrolled and often reactionary nature of information technology (IT) revolution has led to a

situation where numerous specialized programs designed to fulfill specific needs in the organization. These

programs although complete and functional in there own right are not “aware” of the existence of other

programs in the organization. According to Ross, (1999) this leads to a scenario where there is duplication

of programming effort, functionality and data input effort. Maintenance of these programs is difficult and

costly because the programs were designed in different periods and probably run on different platforms,

some of which may have become obsolete along the way. In some cases some of the programmers who

authored these piecemeal efforts had already left the organization taking with them knowledge required to

maintain these programs.

The implementation of enterprise resource planning (ERP) software has been advocated as a response to

the need to consolidate information from different sources and to help reduce level of data capture and

storage redundancy (Davenport, 2000). The popularity of ERP is evidenced by a study that showed that

nearly 19 percent of organizations in across all sectors have installed ERP systems with another 34 percent

of the surveyed institutions at the investigation, pilot or implementation stage (Davenport, 1998). ERP

implementations represent over 80% of new large-scale infrastructure in companies, and are becoming

accepted as the standard approach in small and medium sized enterprises (Holland et al. 2000).

Although numerous press articles and promotional research briefings are available, serious academic

research into the ERP phenomenon has only now began emerging. The growing interest in ERP packages

may be partially explained by the vast amounts of money literally thrown into the path of the consultants

who implement ERP, and the highly publicized failures and success of companies that are brave enough to

venture into the real of ERP (Daniel et al 2000, Aladwani 2001). Recent estimates have shown that ERP

spending would grow from $21.02 billion in 1998 to about $72 billion in the year 2002 this figure reflects

2.7 per cent to 6.4 per cent of overall IT spending during these periods (Heald and Kelly 1998 in Al-

Mashari 2000; Chung and Snyder 2000).

1
1.2. Research Questions

The following research questions are addressed in this dissertation: -

• Has the implementation satisfied the company in terms of its completeness as set out at the onset

of the implementation?

• What were the objectives set out for the implementation of the ERP system and to what extent

have these objectives been met?

• What were the criteria for selecting the current ERP system?

• What is the extent of ERP system use and the level of employee acceptance of the system in the

organization?

• Examine future strategy for ERP in the organization

• What is the vision for the ERP in the organization? What strategic potential for the use of the ERP

system has management set?

1.3. The research site

The PTA bank was established in November 1985 pursuant to Article 9 of the provisions of the Treaty

(1981) establishing the preferential trade area for eastern and southern Africa (PTA) which has since been

transformed into the common markets of eastern and southern Africa (COMESA), however the COMESA

bank is still commonly referred to as the PTA bank.

A report commissioned by the bank in early June 2000 stated in part “both users and clients have expressed

their concerns and frustrations due to the inability by the technologies employed by the bank to provide

2
required information at the required time with the expected accuracy. The current system has increased

paper work and has contributed in burdening rather than facilitating the operations of the bank”. The main

packages in use were “of the shelf” packages that included CMS accounting software, Microsoft Excel and

an in house written program for payroll.

PTA Bank embarked on an ERP implementation by signing a contract with a local consulting firm

Soluziona Kenya on 19th March 2001 to install an ERP system using application and products in data

processing (SAP) R/3 architecture. Soluziona proposed scope of work for implementing human resources

(HR), material management and financials management (FI).

The proposed sub modules for implementation in HR are personnel administration, organization

management, payroll, travel management, recruitment and training. In materials management (MM) the

proposed sub modules include purchase requisition and quotation management, purchase orders goods

receipt invoice verification and logistics information system. While in financial management systems (FI)

cash, treasury and funds management, cost centre accounting, overhead costs and costs controlling, general

ledger and accounts payable were the sub modules proposed for implementation.

1.4. Project Justification & significance

ERP systems are very costly to implement both in time and capital, further ERP installations also require

drastic changes in the way the organization does business both internally and externally. The uncertainty

generated by this can cause depreciation in value of the company in the eyes of investors. Although there

are many success stories associated with ERP implementation, there are also very dramatic failures that

have occurred over the years.

Sauer, (1993) argues that although early systems failures could be written of as aberration and acceptable as

part of the learning experiences towards a foolproof implementation process. The facts do not support this!

A semi annual survey conducted by A.T. Kearny a management consultant firm based in the United States

asked over 250 major corporations around the globe about the impact that information technology has had

3
on the corporate strategic agenda. The percentage of CEOs who were “very satisfied” with their ERP

efforts dropped from 62 per cent in 1995 to only 10 per cent in 2000. Similarly, the percentage of

respondents who expressed complete dissatisfaction increased from 2 percent to 31 percent within the same

period (Willis and Willis-Brown, 2002).

Lau and Nah, (2001) conclude that because of the high failure rate of ERP implementations, studies

targeting implementations and critical success factors should be encouraged in this area. They further argue

that better understanding of the process brought about by these studies would lead to more successful

implementations. According to Silverman, (2000) in Okolica 2000, it was once assumed that after

implementation technology would automatically be adopted through out the organization however in

practice as much as 40% of all information systems projects fail or are cancelled.

The most compelling reason why organizations would like to assure their ERP implementation bids is that

more often than not the cost of failure is much more than the direct costs of the implementation. There are

various costs attached to systems failures including financial costs, wasted investment in equipment and

labour. Other costs include inability to offer service or highly visible systems where failure could lead to

injury or loss of life. One of the most cited ERP implementation failures in recent literature is that of

FoxMeyer Drugs. FoxMeyer drugs one of the largest distributors of pharmaceuticals to hospitals started its

SAP implementation of 1993, one and a half years and $100 million dollars later FoxMeyer could hardly

process 1/40 of its orders and even these had data errors. In August, 1995 FoxMeyer, once a $ 5 billion

company went bankrupt. In 1998 its bankruptcy trustees filed a $500 million against suit SAP and another

$500 million suit against the implementers Andersen consulting (Mendelson, 2000).

Siriginidi, (2001) argues that although past ERP implementation research has been described as factor

research, and only involves a “post mortem” of static factors and therefore of little use in explaining the

dynamics of ERP implementation it nevertheless plays an invaluable role in advancing our understanding

of ERP implementation success.

4
Most research today is geared at only evaluating implementation, however users who remain with the

system after implementation need to adopt the system and actually use it to solve everyday problems. The

study of ERP should therefore be coupled with the study of adoption so that would be implanters can get a

chance to evaluate both pre and post implementation results and gain from the experience of others.

There are significant differences in ERP strategies across organizations, primarily in terms of how they are

initially implemented, and how they are linked to other systems (Holland et al 2000). It is hoped that this

case study will give a glimpse of the implementation success and failures that could be emulated or avoided

to ensure success in similar situations.

2. Literature Review

2.1. What is ERP

Koch, (2002) in his exceptional treatise ‘The ABCs of ERP’ argues that enterprise resource planning, or

ERP doesn’t live up to its acronym ‘forget about planning-it doesn’t do that-and forget about resource, a

throwaway term. But remember enterprise part. This is ERP’s true ambition. It attempts to integrate all

departments and functions across a company onto a single computer system.

According to Aladwani, (2001) ERP systems are integrated set of programs that provide support for core

organizational activities such as manufacturing and logistics, finance and accounting, sales and marketing,

and human resources. ERP systems help different parts of organizations share data and knowledge, reduce

costs, and improve management of business processes. Due to its company-wide “awareness” it is able to

perform complex “what if” analysis from different scenarios ranging from number of staff to material

availability.

ERP provides a backbone to enterprise-wide information systems. At the centre of this enterprise software

is a central database that draws from and feeds data to modular applications that operate a common

computing platform, thus standardizing business processes and data definitions into a unified environment.

5
ERP systems provide consistency and visibility across the entire enterprise; data only needs to be entered

once and then becomes available at all required levels (Injazz 2001; Mendelson 2000).

2.2. History of ERP

ERP can be regarded as one of the most innovative technology to have come out of the 1990s era. The

move from function based to process based IT systems has been well received by the business community

making it the most sought after technology in today’s business world. ERP has its humble beginning from

manufacturing based systems of the 1970s era that were used to identify materials and components

requirements. (Al-Mashari 2002)

In the early 1960s and 70s when computing power become affordable companies began to automate

business process through materials requirement planning (MRP) and financial processing through payroll

and general ledger software. MRP was developed in the 1960s at IBM and quickly become the defacto

production control paradigm. MRP consists of procedures that convert forecasted demand for manufactured

product into requirements schedule for components, subassemblies and raw materials (Mendelson 2000).

MRP continued improvement through out the 1970s to include more business functions. In the early 1980s,

MRP expanded from a material planning and control system to a company-wide system capable of

planning and controlling virtually all the firms’ resources. This approach was so fundamentally different

from the original concepts of MRP that a new term was coined for it by Wight (1980); manufacturing

resource planning (MRP II). MRP II was designed to integrate primary functions i.e. production,

marketing, and finance and other functions such as personnel, engineering and purchasing into the planning

process (Injazz 2001).

With new strides being made in the materials management and production processes, financial and supply

chain management, it was not long before the thought of integrating all these systems into one

comprehensive package was mooted. The term ERP was coined by a highly successful consulting firm -

6
Gartner group of Stamford, Connecticut, USA, in the early 1990s. ERP was then viewed as the next

generation MRP II software with added features of quality control, process operations, management, and

regulatory reporting. (Chung and Snyder 2000; Al-Mashari 2002)

One fundamental difference between MRP II and ERP is that whilst MRP II has traditionally focused on

the planning and scheduling of internal resources, ERP strives to plan and schedule external supplier

resources as well. Traditional MRP and MRP II applications may not be up to the challenges posed by

present day manufactures seeking to capitalize on the competitive advantages offered by an integrated

supply chain, ERP has evolved to play an integrated support in the creation of a supply chain (Injazz 2001).

2.3. ERP Vendors

There are numerous companies that offer ERP solutions in an equally numerous number of industry

platforms. Differentiation between the companies comes from perceived strengths in certain areas of their

ERP offerings, implementation methodologies and underlying infrastructure requirements.

Systems Anwendungen, Und Prudukte in Datenverarbeitung or Systems, Application and Products in Data

Processing (SAP) AG is the leading ERP vendor with a market share of over 40 percent and a revenue base

of over 7.4 Billion Euros. SAP AG was founded in 1972 and has invested heavily in vertical, industry-

specific business and now offers an impressive 19 industry specific solutions. The industry “solution maps”

provides functionality from SAP and its partners for complete, end- to-end industry specific processes. SAP

is currently modeling all its offerings around the Internet called the mySAP.com business portal. Its

integration module offers a single sign-on to enterprise systems.

Other players in the market include Oracle that is primarily a database software company and the second

largest software company after Microsoft. Oracle’s strength is in its accounting offering Oracle financials

and occupies the second position after SAP in the ERP business in terms of revenue and implementation

base. PeopleSoft started as a human resource management system in 1987, and is regarded 'the' company to

beat in terms of human resource functionality offering. In order to provide a more holistic package to their

7
customers they ventured into non-traditional niches e.g., finance, materials management, distribution,

supply chain planning, manufacturing and human resources. In 1996 in an attempt to consolidate its hold

on the SCM area and broaden its market base PeopleSoft purchased Red Pepper and in the same vein

acquired Vamtive in 1999 for its customer relations offering. J.D. Edwards is worth mentioning not only

because it is an old player in the field having been founded in 1977 but also because its offering has been

targeted at medium size companies. It is also considered a more flexible system to work with. Rather than

buying out competition as other major vendors are doing, it is tightly integrating its systems with other

smaller companies that are experts in their niches.

2.4. Reasons for ERP Implementation

The number of enterprises going in for ERP systems is growing rapidly. Managers who have struggled at

great frustration and expense with incompatible information systems and inconsistence operating practices

are quick to grasp at information systems which promise long and overdue relief from the shortcomings of

earlier systems (Davenport 98)

The concerns to be kept in mind by the decision makers while implementing the ERP can be divided into

three categories: short term, medium term and long term. The short-tem may include compliance with

problems such as Y2K, single European currency, shifting from legacy systems. The medium term issues

mainly centered around the return on investment (ROI) of ERP. The long term issues cover incorporating

business best practices from the industry into the enterprise’s systems and procedures (Siriginidi 2000).

Keller and Teufel (1998), and Rick (1997) in A-Mashari (2002) note that competence resulting from ERP

systems being designed on best practices and their ability to standardize business process and systems are

the major drivers to ERP implementation. Organizations view ERP-enabled standardization as a vital

means to integrate diverse organizational systems, provide seamless access to information organization-

wide and a tool for making informed decisions (Al-Mashari 2002).

8
Okolica, (2000) notes that most companies profess to have installed ERP systems in order to remain

competitive, to raise productivity, and to improve decision-making. Other companies implement ERP

simply because their main competitor has moved to ERP and feel that if they don’t implement soon they

would at a disadvantage. Whatever the reasons that a company implements ERP the underlying goal is for

the company to gain a benefit from ERP which would in turn give it an advantage over its competitors.

These sentiments are echoed by Lorin et al (2002) who conclude that although many organizations consider

ERP implementation risky, ERP systems do yield substantial benefits to firms that adopt them, and that the

adoption risks do not exceed the expected value.

2.5. Benefit Dimensions

Each company that implements ERP has it own aspirations hopes and believes. It is therefore not possible

to have a definitive set of benefits that fit all organizations perfectly (Markus 1999). Further O’Grady

notes that some organizations set ambitious goals and expect wide-ranging benefits from implementation,

while others set superficial goals with no regard to the capabilities of the ERP systems. In either case, the

organization is likely to recognize and assess only those benefits that are expected, neglecting unplanned

for benefits because they are not documented as such. A full range of benefits assessment is only possible

when management understands the full complement of the capabilities of the systems.

Although it is not possible to assess benefits of ERP without first looking into the reasons for

implementation, for purposes of research it is possible to offer a broader framework citing areas in the

company where benefits were expected. In providing such a classification Shang and Seddon, (2000) are

however quick to mention that not all enterprises are expected to get benefits in each of the mentioned

dimensions, instead what they have come up with is a blueprint of benefits that are achievable with ERP

system. They hope that in so doing they are providing a more comprehensive and objective way of

assessing benefits of ERP systems.

The five benefit dimensions as described by Shang and Seddon (2000) are discussed below.

9
2.5.1. Operational Benefits

They authors note that due to the automation and removal of redundant processes a reduction, leading to

more streamlined and leaner processes provide benefits by speeding up processes, substituting labor and

increasing productivity. Many companies have benefited dramatically from the streamlining processes of

ERP implementation. AutoDesk, a computer aided design software company reported a decrease from 2

weeks to 24 hrs in its order fulfillment process. Davenport, (2000) notes that IBM storage systems reduced

the time required to re-price all of its products from 5 days to 5 minutes, the time to ship a replacement part

from 22days to 3 days and the time to complete a credit card check from 20 minutes to 3 seconds.

2.5.2. Managerial benefits

Benefits to managers revolve around the ability of the manager to make quick decisions from a centralized

database with the comfort and knowledge that data from all divisions whether remote or local has been

factored in the decision making process. Mendelson, (2000) cites a case of how Cisco systems who are a

leading network infrastructure provider harnessed its ERP to attain market leader status in the global

networking industry, by building an interactive knowledge based relationships with its customers, business

partners, suppliers and employees.

2.5.3. Strategic benefits

Strategic benefits imply long term, rather than short term benefits realization. According to the authors

these are benefits that support business to growth, support business alliance including external linkages to

suppliers and generate product differentiation. The flexibility and scalability of ERP systems allow

businesses to explore new areas and also maximize current potential. Mendelson, (2000) notes that this

category also encompasses the benefits that might be obtained if the company was to decide to use the full

capacity of the system in terms of e-business and inter-organizational linkages. Ward and Griffith, (2002)

argue that strategic planning in information systems seeks to assure that the organization will be in a

position to take full advantage of emerging equipment and software technology to satisfy requirements

throughout the planning period. At the tactical level, management must make certain that enough resources

10
are available to support the short term data processing requirements of the organization as, for example, in

assuring that as transaction volumes increase the ensuing workload can be handled by the systems.

2.5.4. IT infrastructure benefits

These benefits includes the reduction in cost of provision of IT services due to their homogeneous nature as

opposed to providing the same for different systems. The cost reduction includes administrative, training

and support of the legacy systems. Its infrastructure consists of shareable and reusable IT resources that can

act as a backbone for present and future transactional needs of the company. Further the extensibility of the

ERP systems mean that it will be cheaper to roll out the system to more users (Mendelson 2000).

2.5.5. Organizational benefits

Siriginidi, (2001) reports that ERP projects are often associated with major shifts in the way companies do

business a process known as business process reengineering (BPR). Indeed some researchers argue that the

organizational benefits attributed to ERP actually evolve from these process changes rather than the actual

implementation of the ERP software (Davenport 1998). BPR makes enterprises more customer-focused and

responsive to changes in the market place by building in industry best practices and reshaping corporate

structures around business processes. Further it provides for a tighter integration of functions to support

process based management. CIMA, (2000) notes that these changes lead to a more flattened organizational

structure which empowers users and increases their morale. Organizational learning behaviour is also

supported by the accumulation of information supported by retrieval methods.

O’Leary (2000) and Gupta (2000) introduce another aspect of organizational benefits when they point out

that ERP systems provide a backbone for the communication and collaboration with other organizations.

Business warehouse modules in ERP allow supplier, partners and customers to search one repository to

extract information from a common database. The resulting collaboration is beneficial to the concerned

parties because they can anticipate each other requirements before they are apparent on the “shop floor”.

2.5.6. Limitations

11
The lure of the “promised land” and numerous success stories all paint a rosy picture on the ERP systems

front. However the growing number of horror stories about failed or out-of-control projects should send a

chill down the spine of even the most astute adherent of ERP systems. Some companies have scaled back

or even abandoned projects after investing years and others have seen the final costs of their ERP

implementation balloon to up to 50 % over budget in both time and money, according to Davenport, (1998)

these are the lucky few because the not so lucky have been forced out of business, bankrupted and buried

by the very systems they pinned their futures on.

ERP by the very nature of the problem that they try to solve, i.e. that of integrating all aspects of an

organizations processes, are extremely complex pieces of software. The technical challenges therefore

posed in installing, configuring and customizing the systems is enormous. Issues ranging from the

hardware and underlying operating system platforms have to be considered, statutory requirements have to

be factored in and finally business processes have to be incorporated into the design of the system

(Davenport 1998; Mendelson 2000).

Davenport, (2000) argues that although the technical aspects of the project can be somewhat daunting, the

biggest problems are business related. He notes that ERP systems impose their logic on a company’s

strategy, organization and culture. The systems logic may conflict with the logic of the business; it may

push for integration where the company requires separation or push a company towards generic production

process where customized processes would have been more effective. If a company rushes to implement an

ERP system without having a clear understanding of business requirements then the organization may start

serving the ERP system instead of the ERP system serving it.

2.6. Implementation

2.6.1. Theoretical Framework

12
Selecting and implementing an ERP system, and the process changes that go with it, is undoubtedly a

complex undertaking. Regardless of a company’s size or perceived resources ERP implementation is not

something to attempt without a great deal of careful planning. Most CEOs now recognize that ERP

implementation can be a risky, long, tedious and a costly affair (Donovan 2002).

According to Schneider, (1999) the comprehensive nature of ERP is also the root of its greatest

disadvantages. He argues that since ERP integrates operations from the very top and touches almost every

facet of the organisation, the implementation of ERP often requires massive reorganization of IT resources,

fundamental changes in corporate culture, business processes and management. Siriginidi, (2000) notes that

the scope of ERP implementation encompasses what is often referred to as the entire value chain of the

enterprise, from prospect and customer management through order fulfilment and delivery.

Software Development Paradigms

The “software crisis” in the late 1960s was brought about by numerous software implementation failures

characterized by cost overruns and poor service delivery. The lack of software methodologies has been

cited as a major cause of the crisis. The term “software engineering” was coined with a view to equate

software production with engineering processes and hopefully bring to software production the same

structure and process evident in the main stream engineering fields (Sommerville, 1989). In order to fully

embrace engineering principles, software production needed a life cycle to guide the development process.

Further tools and techniques to manage the various stages of the life cycle were required (Griffiths, 1998).

The waterfall model proposed was first described in the 1970s. The stages in this life cycle are shown to

occur in steps flowing from one to another much like multiple waterfalls, since then there have been many

refinements and variations to the model (Sommerville, 1989). Structured methodologies were first applied

at the programming stage of the life cycle. The methodology was later developed for use in the stages of

the systems development. The term structured was used to denote a methodical and ordered approach to

systems development. Structured methodologies are termed as technical methodologies and to reinforce the

perception that the development of computer systems is essentially a technical problem (Gibson et al.

13
1999). These methodologies are characterized by superficial or no interaction between the end users and

the implementation staff, the IT staff were the drivers of the whole process from inception to the end.

Avison and Fitzgerald, (1995) in Gibson et al (1999) note that even with the technical improvements

associated with structured methods and advanced engineering techniques, projects continued to fail. It was

evident that there were other factors in play, social and organizational factors were now cited as being

equally or more important than technical ones in determining project outcomes.

Mumford (1991) in Gibson et al. (1998) introduces ETHICS systems development methodology, which is

an acronym for effective technical, and human implementation of computer based systems. ETHICS falls

under a group of methodologies referred to as soft systems because they advocate for “people” involvement

in the process of systems engineering. Ethics was designed around the principles of user participation in

systems development.

Other methodologies include PRINCE, which was developed by the British government and defines the

organisational structure of the project and its stages, the structure and content of the project plans, and a set

of controls that ensure that the project is proceeding as planned. These three, together with the products of

the project and the activities, which produce them, comprise the PRINCE components (ESI 1998).

Gibson et al (1999) argues that although early systems development strategies that came about out of the

software crisis 1960s and help in laying a foundation in implementation of ERP, they nevertheless assert

that ERP implementation is fundamentally different. ERP explicitly links strategy, organization, business

process and IT systems together into a coherent framework and therefore requires a methodology that

embraces both the social and technological aspects of ERP implementation, further a socio-technical view

of the implementation process ensures that the technology fits closely and compliments the social and

organization factors.

14
Esteves and Pastor, (2001) report that SAP felt that it was losing business due to the highly publicised

failure rate and long implementation periods of ERP systems in the field. It embarked on the search of a

methodology, which would give its products a greater chance for success and also shorten the

implementation period. In 1996 SAP introduced the accelerated SAP (ASAP) structured implementation

methodology. ASAP was hailed as the first method to utilize the experience and expertise obtained from

the thousands of implementation that SAP had commissioned worldwide.

ASAP specifically targets small to medium size firms who want to enjoy the benefits of an enterprise wide

information system solution. It features 5 well developed phases know as the ASAP road map, they are:

project preparation, business blueprint, realization, final preparation and go live & support. Each phase

consists of work packages that are structured activities and where each act activity is composed of a group

of tasks. For each task, a definition, a set of procedures, results and roles are provided in a detailed ASAP

road map documentation. A survey conducted by Input, (1999) in Esteves and Pastor (2000) shows that

ASAP reduced the implementation time from an average of 15 months using standard implementation to 8

months.

2.6.2. ERP Life Cycle

Project life cycles serve to define the beginning and end of a project. The project life cycle also serves to

determine transitional actions at the beginning and end of the project, the project life cycle therefore can be

used to link the project to the ongoing operations of the performing organization (PMBOK, 2000)

ERP implementation life cycle differs markedly from that of other software development cycles; first from

a software point of view ERP is complete. The functionality already built into the system is usually more

that what is required by any one organisation. Rather than designing a system to meet the sometimes-

idiosyncratic ways of working, the adopters of an enterprise system often change the organizations ways to

fit the package. Consequently, adopters forgo or minimize the analysis of current information analysis,

which is the hallmark of traditional software engineering cycles.

15
The process of configuring ERP software is fundamentally different from that of software programming, it

involves adapting the generic functionality already present in the system to fit particular needs whereas

programming involves creating new functionality. Rather than having information technology specialist

implement these configurations, functional area specialists trained in the ERP implementation process

perform these duties. This has consequently altered the composition of and roles played by software

implementation staff (Markus and Tanis 2000). The role of pure information technology “gurus” is

therefore often minimized to providing the enabling infrastructure for the ERP to run on.

Organizations implementing ERP systems can be described as moving through phases which are

characterized by key players, typical activities, characteristic problems, appropriate performance metrics

and a range of possible outcomes. Several authors have tried to classify these phases, Esteves and Pastor

(1999) have elucidated six phases: adoption decision, acquisition, implementation, use and maintenance,

evolution, and retirement. Markus and Tanis, (2000) have described four phases which in my opinion

covers the key aspects of ERP implementation i.e. ERP choice, vendor selection, design and implementation,

and going live. They further note that each implementation is a unique experience due to the different paths

that organisations can take to attain different goals in each phase e.g. whether to hire consultants or make it

an in-house project or whether to let IT or business executives to champion the project. The four phases are

discussed in detail below.

2.6.2.1. Phase I Chartering

This is the initial stage and includes decisions leading to the funding of an enterprise system. The key

players in this phase include vendors, consultants, company executives and IT specialists. The key

activities include expounding the need for and ERP system, selecting a project leader preparing preliminary

budgets and schedules. Top management is usually not consulted until the later stages of this phase. Errors

of judgment can crop up here which will have a great impact on the success for the project e.g. the decision

to perform the work in-house or hire consultants. (Markus and Tanis 2000). This phase includes the

definition of system requirements, its goals and benefits, and analysis of the impact of adoption at a

business and organizational level (Esteves and Pastor 1999). The possible outcomes according to the

16
authors are, the idea is abandoned, the decision is reschedule pending further investigations or a go ahead

is given.

2.6.2.2. Phase II Project

This stage reflects the point where ERP implementation process is in the “get up and go” stage, executives

are selected to be sponsors of the project. Management makes a decision on whether this will be basically

an IT project or a business driven project with participation of IT. Esteves and Pastor, (1999) note that best

fit software selection is carried out to minimize customization, the best fit is identified by a process of

current process definitions and BPR where the process deviates too far from best practices. It is at this point

where a consulting company is engaged and contract terms worked out. The key activities in this phase

include configuration, customization data conversion, system integration, documentation, rollout and

training of users. Possible outcomes are either the project is abandoned due to cost overruns and/or by not

meeting core requirements of the business or the systems is adopted because satisfactorily meeting the

functional demands of the business (Markus and Tanis 2000).

2.6.2.3. Phase III Shakedown

This is the stage where the company comes to grips with the ERP system. The phase can be said to be

complete only when “normal operations” have been achieved by the organization or when a company

decides to abandon the project (Mendelson, 2000). The consulting team may be asked to stay on board

albeit with skeleton crew or asked to leave depending on the technical capabilities of the organization. Bugs

are usually discovered at this stage and reworks or workarounds are developed to cope with them.

Emphasis is placed on the functionality, usability and adequacy of the system in emulating business

processes (Esteves and Pastor 1999).

2.6.2.4. Phase IV Onward and Upward

This phase continues from the shakedown stage until either when the ERP system is replaced or a major

upgrade is required. As users continue to familiarize themselves with the system they discover needs for

new enhancements or simplification of processes which require reconfiguration of the system. When user

17
feedback is handled appropriately this phase becomes a continuous improvement phase with greater

benefits being realized than envisaged at the onset. One important function in this phase is ERP

implementation evaluation, it helps the executive to ether give the implementation a clean bill of health in

terms of successfully meeting set objectives or deciding that its investment has been unsuccessful

(Esteves and Pastor 1999; Marcus and Tanis 2000).

2.7. Dimensions of ERP implementation

ERP implementation is a company wide endeavour and therefore lends itself to influences from the whole

organizations. In order to raise the probability of a successful ERP implementation we need to understand

the impact if any, different aspects of an organization have on the process. Esteves and Pastor, (1999)

identify four dimensions or viewpoints that affect the way an organization interacts with the four phases

described above. These viewpoints are discussed below.

2.7.1. Technology/Product

This dimension relates to a particular vendors product offering in terms of functionality, usability and the

related infrastructure including hardware and software requirements. Esteves and Pastor,(1999) note that a

thorough understanding of the software tool’s capability is needed in order to harness its full potential in

terms of maximizing benefit to the organization.

ERP software being extremely complex software is hard to configure and customize. Configuration refers

to the act of activating or deactivating parameters given in a certain module, whereas customization refers

to addition of functionality not present in the original or standard configuration. According to Appleton,

(1997) in Kraemmegrgaard and Moller (2000) argues that the standard software is often loaded with

features which people tend to use even though those features may not be helpful in moving the company

towards profitability, quality out put or efficiency. A well thought out configuration would help to alleviate

this, keeping active only the functionality that supports core business of the organization.

18
Ross, (1998) in Kraemmegrgaard and Moller (2000) notes that when implementing an ERP system two

important design decisions exist. First the company has to decide on whether or not to accept the

processing logic embedded in the software. Second, the company has to decide whether or not to

standardize its processes.

The extent of customization impacts on the length the implementation. Another important issue to

remember is that the more removed a system is from the standard version, the harder it is to support and

integrate with other systems or with future upgrades. However it is important to note that this is a price that

enterprises might be wiling to pay especially if the changes impact on core business functionality without

which the ERP system would be of little use to the organization (Kraemmegrgaard and Moller 2000).

2.7.2. Organizational/People

The term implementation traditionally meant the technical phase of a software project. However

implementation of ERP system are often said to be more about changing people than changing software,

more organizational development than technological development (Kraemmegrgaard and Moller 2000).

Gibson et al., (1999) argue that ERP software implementation requires a non traditional approach that seeks

a balance between the business process design, software configuration, and project management rather than

laying emphasis on the technical aspect of software implementation.

ERP implementation tends to change the power and authority structures in organizations (Aladwani 2001).

Therefore conflicts of interest are likely to occur between participants. In order to minimize these conflicts

all those who are affected by the changes must be involved in the decision making process. Gibson et al

(1999). Roles in ERP are usually foreign to the actors and require new skills to perform them adequately.

A learning environment has to be put in place to minimize the impact of new skills requirement on the

adoption of the system (Esteves and Pastor 1999). As a result of these role changes power users emerge

who know about the new business processes and are able to explain how to use ERP systems not only in

their respective functions but across the whole organization, they become channels and brokers of tacit

knowledge of the ERP system. This leads to centralization of power towards the power users but at the

19
same time decentralization by allowing management structures to be streamlined towards flatter and more

flexible organizations (Davenport, 1998).

Kraemmegrgaard and Moller (2000) argue that an organizations’ history plays a role in the implementation

of ERP in the organization, through history the organization has developed assumptions about what is the

dominant power structure, values, language and role of technology. These assumptions govern how

procedures, rules and instructions are viewed in the organization. The organization history therefore not

only tells us what has taken place but what the future may hold for the organization.

2.7.3. Business/Process

Hammer, (1999) in Markus and Tanis (2000) notes that best practices represent a powerful reason to adopt

ERP systems without modification because few organizations can claim to have business processes that

have maximized cross-functional efficiency and effectiveness. Further, Jacobs and Bendoly (2003) argue

that for BPR to improve the operation of the organization, it should not be used with intent of

accommodating the system but rather it should be intent on instilling best practices that are supported by

the ERP system.

Siriginidi, (2000) argues that BPR makes companies more attuned to global competitive strategies,

achieves results by reshaping corporate structures around business processes rather than complete

automation of the business. However it is important to note that although this works very well in industries

where differentiation of processes is not crucial in terms of customer perspectives, Davenport, (1998) notes

that if differentiation plays a crucial role, then standardization would undermine the company’s source of

differentiation and lower its competitive advantage in the market.

BPR usually suggests a radical departures from what is perceived as the norm of doing business in an

organization. As a result changes are usually met with at best – passive resistance and at worst by active or

destructive resistance. Resistance slows down the implementation because valuable time is spent on

20
conflict resolutions. However it is important to note that resistance can be useful in pointing out areas of

weakness in the ERP system (Umble et al 2003).

Jacobs and Bendoly, (2003) note that before reengineering can produce desired results there must be time

devoted to understanding actual processes currently in use in the organization and allow for eased

introduction of new processes.

3. Critical Success Factors

The critical success factors embody the handful of things that must go right in order for any undertaking to

meet its objectives (Robson, 1994). Implementing an ERP system is not an inexpensive or risk-free

venture, in fact, 65 per cent of executives interviewed in a recent survey, believe that ERP systems have at

least a moderate chance of hurting their business because of potential implementation problems (Umble et

al 1999). Most authors have determined that it is worth their while for companies to examine factors that

can be considered critical to the success of ERP implementation before embarking on an implementation

(Umble et al 1999; Nah and Lau 2001). Although authors have not agreed on a definitive list of what they

consider critical factors, some of the differences can be explained by the cross section of different

industries that ERP is implemented. Robson, (1994) argues that although critical success factors (CSFs) are

specific, they differ from industry to industry, between organizations in the same industry and sometimes

from one period to another within the same organization. The factors that influence the composition of

CSFs at any one time include:- industry specific factors, competitive strategy/industry position,

environmental factors, temporal factors and managerial position.

3.1. Project Team Selection and Management

As noted earlier ERP implementation is a complex affair. Excellent project management skills are required

in handling the project and this starts by selecting a team that will carry out the implementation. The team

should be structured to emphasize the far-reaching effects of the ERP system i.e. as much as possible all

functional areas should be included in the team composition. This has the added advantage of making the

users of the system own the decisions made and also ensures that people with on the ground knowledge of

21
business systems are included in its automation. (Bernroider and Koch 2001). Nah and Lau (2001) note

that a good mix of consultants and internal staff helps to develop the necessary in-house technical skills and

knowledge for post implementation use. Vosburg and Kumar (2001) note that the hiring of consultants to

assist with the ERP implementation is an effective strategy if organizations ensure that all work done by the

consultants is understood and documented, this will ensure that implementation knowledge does not leave

the organization after the consultants work is complete.

After selecting the team the question of leadership of the team needs to be addressed, the traditional answer

to this has been “an IT specialist”. Kirsch, (2000) argues that the success of software projects does not rest

on IT professionals alone. Users play a critical role including; furnishing knowledge to the project,

exercising control and providing full or partial leadership to projects. Ignoring or minimizing the role of

users is likely to result in impeded project progress.

Successful ERP implementation requires that the organization engage in excellent project management.

This includes a clear definition of objectives, development of both a work plan and resource plan and

careful tracking of project progress. The team should be given a clear mandate with the ERP project being

the top and only priority, team members should be assigned full time to the implementation where possible.

The project plan should establish aggressive, but achievable, schedules that instil and maintain a sense of

urgency (Umble et al., 2003).

Although many of the techniques of general management are applicable to software management, software

projects have certain characteristics that make them different: invisibility, software is not a tangible

therefore there is no immediate way to judge the progress of a software project, unlike in the case of say a

bridge construction; Complexity, software projects are usually more complex than other engineered

artefacts; flexibility, software can be changed easily this is both its strength and weakness, because

changing software is easy, careless and/or unplanned software changes may lead to catastrophes (Cotterell

and Hughes 1995).

22
3.2. Top Management Support

Umble et al., (2003) notes that many researchers recognize the need for strong leadership, commitment and

participation of by top management. This is because executive level input is critical when analyzing and

rethinking existing business processes. He further suggests that the executive presence in the form of a

management committee should be committed to enterprise integration, understands ERP, fully support the

cost, demands payback, and champions the project. Nah and Lau, (2001) propose that the project sponsor

should be a high ranking executive who has the power to set goals and legitimize change, the champions

work would also include selling the project to the whole organizations.

Kraemmegrgaard and Moller, (2000) note that it is important to put someone “in charge” of the

implementation to create a coalition of employees supporting the implementation. They however point out

that the management should not only be present to pay the bills but to take up active roles in the

implementation process. Aladwani, (2000) argues that ERP implementation can only be accomplished

when senior management is the totally committed to the initiative. Management commitment and support is

the ultimate strategy that will secure the necessary conditions for successfully introducing the change

brought by ERP into the organization.

Agarwal, (2000) citing several authors points out that deliberate managerial action can have a profound

impact on individual acceptance of information technology. Managers can provide overt support through

appropriate communication, provide adequate resources, and structure systems development efforts to

guarantee close interaction between technology providers and technology workers.

3.3. ERP Package/Vendor Selection

Choosing the right ERP package is not easy. The enterprise has to not only identify information needs, but

also has to ensure that the information infrastructure provides the right support to serve the enterprise its

customers and suppliers. Some ERP packages provide better solutions in certain functional areas.

PeopleSoft started off as a human resource management system and they still excel along these lines,

23
further other vendors have been associated with certain industries and tend to provide a better product mix

in those areas (Mendelson 2000).

Functionality, systems reliability and fit with parent/allied organizations have been ranked as the three most

important criteria used for selecting an ERP package. Research carried out on successful ERP

implementations, where success means that the ERP package met the set objectives as laid out at the time

of implementation, 79 per cent consider functionality a key area in ERP package selection. It is interesting

to note that parent company and companies allied to had a great influence (64 per cent) on ERP package

selection while reliability also scored at 64 percent. (Kumar et al 2001).

Most organization did not rank ease of use and a few only considered total cost of ownership in selecting

systems although cost escalation was perceived as a risk. Davenport, (2000) argues that the fact that best fit

business processes was not considered crucial indicates that most companies preferred to do customization

or business reengineering to get the fit. However Al-Mashari et al., (2003) quoting a research by

Everdingen et al..(2000), completely differ with this view when they point out that the best fit with current

business procedures is the most important criteria. Other consideration identified by Siriginidi, (2000)

include stability and history of the vending company, availability of local implementation support, domain

knowledge of the supplier and previous experience in their specific industry.

3.4. Change Management

There mere mention of the word change brings apprehension, mistrust and defensive feelings to the

forefront. This is because change brings with it uncertainty. The human element which is entrenched in

individuals, groups and organization behaviour commonly referred to as organizational culture plays an

important role in determining the failure or success of proposed changes. These fears whether ill founded or

true have to be allayed in order to get the cooperation and involvement of the employees in implementing

change.

24
Change management is the process of planning, controlling, coordinating, executing and monitoring

changes that affect ones service or product delivery environment. The objectives of change management

include; implement only necessary change, manage change to ensure that service or product levels are not

impaired, reduce risk to a bare minimum, record change progression for evaluation and communicate

change effectively across the whole company (Allan, 1997).

From the literature review we have established that ERP implementation more often than not precipitates

far reaching changes in the organization structure and processes. Umble et al., (2003) notes that the existing

organizational structures and processes found in most companies are not compatible with the structure,

tools, and types of information provided by ERP systems. Roberts and Barrar, (1992) in Nah and Lau

(2001) argue that a culture with shared values and common aims is conducive to success. Organisations

should have a strong corporate identity that is open to change. Change management efforts should include

involvement in the design and implementation of business processes and the ERP system. Change

management should start at the charming stage and continue through out the project life cycle (Wee, 2000).

3.5. Effective Communication

Communication is important in all projects and more so an ERP project where team members may include

both staff member and external consultants. Esteves and Pastor, (2000) note that communication should be

of two kinds i.e. inwards between project team members and outward to the whole organization. The

communication effort should be done at regular intervals to ensure that users are kept abreast with project

status.

Kraemmegrgaard and Moller, (2000) that communication to employees and managers is essential for

creating an understanding and approval of the implementation. Communication must start early in the

project, and for it to be effective it should be a two way process understanding the needs of the receiver and

analyzing the extent and nature of the coming changes. They further argue that for communication to be

effective there is need to avoid information avalanches, communication should be tailored in such away

that it is received and understood by the target audience, it should therefore start with an overview of the

25
system and reason for implementing it, anticipated changes and how they will affect operations including

new organization structures.

An open communication policy needs to be adopted to ensure that all stakeholders have a say in the

decisions made by the team which will make the users own the whole process systems such as email are

appropriate though face to face or telephone systems should be used in serious situations (Al-Mashari et al.,

2003).

3.6. Monitoring and Evaluation of Performance

Measuring and evaluating performance is a very critical factor for ensuring success of any organization and

indeed for ensuring a ROI on ERP investment. Cottrell and Hughes, (1995) point out those meaningful

measurements can only be done against concrete and well-defined objectives. Seddon et al., (1999) argues

that it is very difficult to measure the ‘success’ of information systems especially ERP systems because

there is no established standard for its evaluation. He further notes that there is no single measure of

success but rather different perceptions of success influenced by context.

Markus and Tannis, (2000) argue that any attempt to measure the performance of an ERP system will fail if

the goals and objectives of the ERP implementation are not taken into account. E.g. if two companies

implement the same ERP system and one company’s goal is to replace a legacy system and another

increase market share different metrics need to be used to evaluate their success or failure. They have

defined three categories of evaluation metrics; Project metrics these are the classic performance measures

which include schedule, budget, and functional scope. Early operational metrics are used during the shake

down phase or early operational phase of the system and include usability and reliability of the system.

Longer term business results these fit in the strategic outlook of the organization e.g. adaptability and

extensibility of the ERP system.

26
Many information systems related success studies have been conducted seeking to identify how to define

and measure the success of information systems, a measure of “actual usage” and “perceived usefulness”

have been put forward as suitable measures of success( Esteves and Pastor 2001).

3.7. Business Plan and vision

Trying to implement ERP systems without first considering the business implementation is a disastrous

undertaking. There should be a clear business model of how the organization should operate in support of

the of the implementation effort (Davenport, 1998).

In order to rally staff behind a common goal, the corporate mission, objectives, and strategy must be well

developed. Key people throughout the enterprise should create a clear, compelling vision of how the

company should operate in order to satisfy customers, empower employees and facilitate suppliers. This

will help steer the direction of the project throughout the ERP life cycle (Umble et al 2003; Nah and Lau

2001).

Donovan, (2002) suggests that there is need to develop a business strategy that will give the organization a

competitive advantage. This should be followed by an analysis of current business processes enabling a

“road map in order to” to be prepared between the desired state and the present state.

Osterle, (1995) in Gibson et al., (1999) notes that in order to plan ERP implementation for success

Organisations need to look at the existing business structure and processes framework and compare these

with those offered by the ERP system. Process modelling tools are available either as part of the ERP

system or as stand alone software (Gibson et al., 1999). Kumar et al., 2001 notes that unclear strategic

direction and vision for the use of ERP systems is a challenge to many ERP implementation teams.

Al-Mashari et al., (2003) suggest benchmarking as a way of ensuring optimization of the potential available

to the business. This he says encourages the inclusion of new ideas, knowledge and best practices in ERP

system adoption.

27
Al-Mashari et. Al., (2003) suggests that the plan should incorporate the management of any legacy systems

that were present before the ERP systems. Each of the legacy systems may provide valuable support for a

particular business task and it is therefore imperative that an organization plans the transitions of legacy

systems carefully with a comprehensive and well thought out plan. This will ensure that information

blackouts do not occur during the implementation phase.

3.8. Education and Training

Lack of training has emerged as one of the most significant reasons for ERP systems implementations

failure. Full benefits of ERP can not be achieved if the users are not using the system properly. There is

need to select an appropriate plan for end user training and education. The training should be geared

towards the effective understanding of the various business processes which are reflected in the ERP

applications (Gupta, 2000). Umble et al., (2003) notes that if employees do not understand how a system

works, they will end up inventing their own process to get the job done which may not be in line with best

practices.

Umble et al., (2000) notes that executives often dramatically underestimate the level of education and

training required to implement an ERP system. They must be willing to spend money to ensure that the

level of training is raised to the optimal level; they note that a figure range of 10-15 per cent of the total

implementation budget has been suggested as adequate. On-going training is a prerequisite for successful

ERP Implementation. The implementation plan should consist of a comprehensive training programme,

with a delivery date on training well before “go-live” date. This should be coupled by periodic exchange of

ERP experiences by users (Vosburg and Kumar, 2001)

3.9. Cost Control

Despite the benefits that ERP software can give to an organization, they are very expensive even under

ideal implementation institutions. The cost of ERP software itself can range from hundreds of thousands of

dollars to several million dollars. This cost is further escalated when consultants are hired do undertake the

28
selection, configuration, customization and implementation of the system. In addition to these costs

associated costs may include network infrastructure, servers and software (Al-Mashari et al., 2003).

Hitt et al., (2002) establishes that implementation of ERP systems require substantial investment of time,

money and internal resources, a typical installation may cost about US. $ 15 million and can be as high as 2

to 3 per cent of total revenues. Installation may take between one and three years, with benefits only

starting to accrue after an average of about 2.5 years.

Organisations implementing ERP incur more costs than the license fees levied by the respective vendors.

The red flags according to Ramrath, (2002) are consulting costs, maintenance costs and data definition

costs. He however points out that although there is need to cut down costs, the only thing more costly than

using consultants to implement ERP systems is not using them.

The most important aspect of cost control is planning, organizations should first take stock of the in-house

expertise available, after deciding on the number of consultants required they should then be given clear

objectives and requirements. Osterlan, (2000) further advices that senior executives of the company should

interview the contract staff and spell out clearly what their expectations are to the consultant. A contract

should be drawn out covering each individual qualification and expected role in the project and also outline

how staff changes should be handled.

3.10. Data Accuracy and Systems Testing

Data accuracy can be said to be three fold first legacy data must be shown to be correct before upload,

second the upload process should not corrupt the data and third input of new data should be validated.

Umble et al., (2003) argue that data accuracy is an absolute necessity when dealing with ERP systems. Due

to their integrated nature an error in one module can have a negative domino effect in other parts of the

system. This can be solved by training users on the importance of data entry and data entry procedures. As

discussed above in communication, employees must be convinced that the new systems represents new and

29
better ways of working by ensuring that they are kept abreast with the progress of implementation and user

adoption.

To ensure that everyone follows the new processes parallel systems should be carefully monitored. Any

parallel systems should be run with direct knowledge of the ERP implementation steering committee.

ERP implementation should be tested, first to check whether the technical aspects of the systems work e.g.

workflow paths are followed correctly and second to ensure that the business process configurations are

practical i.e. they match what is physically possible on the ground (Al-Mashari et al., 2002).

4. Methodology

The research was done in the form of a case study on the implementation of Saps' R/3 enterprise system at

PTA bank, Nairobi. Consent for the study was granted by Director of Finance Mr. Alex Gitari, it was

granted on the premise that the research would also help the organization to evaluate their ERP system

implementation and adoption.

4.1. Case Study

A case study examines a phenomenon in its natural settings, employing multiple data collection methods to

collect information from an entity. Case study allows for in-depth examination of an entity for

comprehensive analysis and extensive description of events occurring in that entity (SAO, 2002). Gibson

et al., (1999) argues that case studies can be used to build on theory in order to understand the

implementation process of ERP software.

Nielsen, (2002) notes that case studies are preferred over field research, because a field study is usually

more time consuming. The research questions posed in this paper can be satisfactorily answered using a

case study approach, further the fixed timeframe of the project necessitates the use of a case study approach

to minimize the time taken in data collection.

30
4.2. Sample Selection

A preliminary survey was done to determine the number of users in the organization who had been exposed

to the ERP system. The instrument used was an email questionnaire asking whether the respondent had

used the ERP system. The sample for the survey was then limited to the respondents who answered “Yes”

to having used the ERP system in the organization.

4.3. Data Collection Methods

Case studies are likely to be much more convincing and accurate if they are based on several different

sources of information, following a corroborating mode (CSU, 2003). A variety of data collection methods

were used. Including, face to face interviews, posted questionnaires, e-mail questionnaire and historical

data review.

4.4. Materials Distributed.

A covering Letter was sent out via email to minimize use of paper. The letter outlined the nature and scope

of the study and the expected benefits to the organisation. The letter also gave the intended interviewees an

assurance on the confidentiality of the research. This letter was accompanied by a preliminary

questionnaire intended to provide the criteria for the selection of the non-random batch of interviewees.

The main users survey and implementers was distributed questionnaire via hard copy. The questionnaire

was designed to enable the research to gather quantitative data by means of a structured section, which

would be ideal for statistical analysis and get qualitative data from open-ended questions used to clarify and

seek opinion from the respondents.

4.5. Questionnaire Structure

The questionnaires had two basic types structured and unstructured. Structured questions took the form of

checklists, rating scale and simple Yes/No. Unstructured questions were mainly open-ended questions that

required some form of elaboration.

31
4.6. Questionnaire Content

The questionnaire content was discussed with a doctorate student researcher, the project supervisor and 3

users in the organizations and their suggestions incorporated in the final draft questionnaire. Koul, (1988)

notes that although survey by use questionnaires is one of the most commonly used methods of data

collection it is often the most abused. The researcher should ensure that the questionnaire is neither too

long and nor too short getting the balance right involves factoring in the subject matter, scope of the study

and target audience.

The users’ questionnaire was designed to solicit response from day to day users of the systems and

consisted of 24 questions. It is further divided into sections, which provides user information, system

interaction, training and support. The management questionnaire was designed to assess senior

managements role and view of ERP implementation and adoption. The implementer’s questionnaire was

designed to gather data from the implementation team both internal and external to the organisation.

4.7. Secondary Data Review

Data was also collected from historical documentation. These were sourced from the Information services

file archives. The documents include training manuals, implementing team correspondence and reports.

4.8. Problems Encountered and Solutions

4.8.1. One of the biggest problems encountered was the availability of time due to increased workload

and travelling, caused by a major change in the ERP system during this project. The author

minimised the impact to the project by scheduling literature reviews when out of the duty station

for prolonged periods of time

4.8.2. A number of key staff were not available for interviews either due to prior commitments or

because they had left the organisation. Where possible they were contacted fore rescheduling or

sent the questionnaire by email.

4.8.3. The small size of the sample may make the data statistically unreliable.

32
5. Data Analysis and Results

Data analysis for case studies is somewhat unusual in that much of the data collected is qualitative rather

than quantitative (SOA 2003). Although case studies are generally non probabilistic in nature, descriptive

statistics have been used where appropriate to provide credence to conclusions made from the data. Care

has also been taken to include as many structured questions as possible without detracting from the value of

non-structured questions in seeking opinions from the user. Coding of the responses also provided away of

converting qualitative data to quantitative values for analysis.

5.1. Research Analysis Tool

The qualitative research analysis tools used include Microsoft Excel and SPSS Version 11. SPSS was

selected because of its ability to handle social statistics and advanced coding capabilities dealing with

questions with multiple responses. Microsoft excel was used to plot out graphs from analytical data derived

from SPSS.

5.2. Respondents Analysis

STRUCTURE OF SAMPLE INTERVIEWED BY DEPARTMENT

Questionnaire Response Analysis
CFBD
PMD 11%
25 90%
21%

20
15
10
5 10% ACS
32%
0
Responded Valid Spoilt
User Count
FIN
36%

Figure 1 Figure 2

Figures used all used the following key:

PMD = Portfolio Management and Development

CFBD = Credit Facilities and Business Development

ACS = Administration and Corporate Affairs

33
FIN = Finance

The preliminary investigation identified 25 users who were eligible to answer the questionnaire based on

the criteria that they used the ERP system in the organisation of these 21 respondents were able to hand in

their questionnaires in time for analysis a response rate of 84 percent. Two of the returned questionnaire

were not usable because although the users indicated they used the ERP system it turned that one was an

information system assistant who backed up the system and the other thought that the ERP system was the

general system for email, file and printer sharing. 19 of the responses representing 90 per cent were viable

for analysis. Figure 1 shows the demographic distribution of the respondents according to departments.

5.3. Duration of Using SAP in the organisation

The user base is relatively young with 74 per cent of the users having used the system for less than 1 year.

Duration of SAP Usage

5%
21%
21% Less than 6 months

More than six months but less

than one year
More than one year

No Response

53%

Figure 3

However, a user base of 21 per cent has used the system for over one year. Users in Finance and

Administration and Corporate affairs have the bulk of experience in the system.

5.4. User Roles in the System

H I: Basic user roles; initiation and Information roles are more abundant and evenly distributed in

the organisation, while technical and supervisory roles; approver and facilitator are more

34
 restricted.

R OLE I N SA P

25
1

20 No Response
10
Information
15

Facilitator
2
10 2
3 Approver
2

5
1 3 Initiator
2
7
4 4
2 3
0
Total CFBD ACS FIN PMD

D e p a r t me n t s + T o t a l s

Figure 4

All the user roles mentioned in the questionnaire are found in the organisation, finance and administration

and corporate services are the only departments with initiator and approver roles in the organisation.

Information retrieval is the only role shared universally. Facilitating role is confined to the finance

department.

Accept Hypothesis I.

5.5. Modules Used

H II: Core banking modules; treasury and finance control will have a higher usage rate than specialised

or technical departmental modules such as work bench, materials and human resources.

35
 MODULES USED

120%

100%
100%
Finance and control
80% 75% Materials management
71%

Business workflow
60%
47% 47%
50%
50% Treasury
43%
43%

40% 33%
Human Resources
29%
21%
21% 21%
25% Work Bench
17%
17%
20% 14% 14%

5%

0%
Total CFBD ACS FIN PMD

Department +Totals

Figure 5 Note. The percentages maybe greater than 100 because a user may use more than one module.

Overall, all modules implemented in the system are utilised in the organisation. The treasury and finance

and control module are the most widely used in the organisation both at 47 percent whilst the workbench

module is the least used at 5 per cent of the users.

Accept Hypothesis II.

5.6. Amount of Time of SAP

H III: SAP system is a core system, which necessitates that at least 50 per cent of users time should be

spent on SAP.

AMOUNT OF TIME SPENT ON SAP

80% 75%
71%
70%

60%
50%50% 50%
50% Less than 10%

40% 37%
32%32% 33% More than 25% but less
30% 25% than 50%
20% 17% More than 50%
14%14%

10%
0% 0%
0%
Total CFBD ACS FIN PMD

Department +Totals

Figure 6

36
37 per cent of the users spend more than 50 per cent of their working time on sap. The credit finance and

business development has the highest rate of system usage with 50 per cent of users interviewed spending

more than 25 per cent on the system and a further 50 per cent spending more than 50 per cent of their time

on the system. Finance has the highest number of users who spend less than 10 per cent on the system (71

per cent).

Accept Hypothesis III.

5.7. Rating of Usability of SAP

H IV: The system has been designed with ease of use in mind and users the logical flow of data

supports the laid down processes and procedures.

RATING OF USERBILITY OF SAP

Mean Scores Calculated out of a weighted score of 4 where the most positive score is 4 and the
most negative is 1
4

3.1 3.1
3
2.9
3 2.8

1
Avg. Mean Understanding Easy to enter data Easy to correct Logical flow mirrors
Terminologies erroneous data procedures

Questions + Average

Figure 7Users overall rated the SAP system as user friendly with an average mean of 3.0 computed from

four metrics; terminology used, data entry, error correction, and logical flow of data entry. Ease of

understanding terminology used and data entry were rated the most highly at 3.1 while data correction was

rated the lowest at 2.8

37
 RATING OF USERBILITY OF SAP BY DEPT
Mean Scores Calculated out of a weighted score of 4 where the most positive score is 4 and the most
negative is 1

3.2 3.1 3.1

3.1 3.1 3.0 3.0 3.0 3.0 3.0 3.0 3.0 3.0 3.0
2.9
3 2.8

2.5 2.5 2.5

Understanding Terminologies
2.0 Easy to enter data
2
Easy to correct erroneous data
Logical flow mirrors procedures

0
Total CFBD ACS FIN PMD

Department + Average

Figure 8

Finance and project management had the lowest range in usability ratings with a .5 difference in finance

and none in portfolio management and development. Credit finance and business development and

administration and corporate services had the highest range with 1.0 and .7 respectively.

Accept Hypothesis HIV.

5.8. Reporting

V: Sap reports are accurate and easy to understand

VI: Reports produced are unique to SAP and cannot be derived easily from other sources.

38
 EVALUATION OF SAP REPORTS
Mean Scores Calculated out of a weighted score of 4 where the most positive score is 4
and the most negative is 1

4.0
3.4
3.5 3.3 3.3
3.2
3.1 3.0 3.0 3.0 3.0
3.0
2.7
2.4 2.5 2.5 2.4 Accuracy of SAP Reports
2.5 2.3

Understanding of SAP Reports

2.0

1.5 Availability of SAP Reports from other

sources
1.0

0.5

0.0
Total CFBD ACS FIN PMD

Departments + Average

Figure 9

Accuracy of reports had an overall rating of 3.2; understanding of reports got a rating of 3.1. The notion

that sap reports could be obtained from other sources was rejected by users and given a low rating of 2.4.

Accept Hypothesis V and VI.

5.9. Education and Training

H VII: Combination of both formal and on the job training increases the effectiveness of the training

received.

H VIII: The longer the training period the greater the understanding and effectiveness of training

received.

H IX: The number of users using a certain module is positively related to the number of users trained

in the module

39
 EFFECT OF TYPE OF TRAINING ON ITS EFFECTIVENESS
Mean Scores Calculated out of a weighted score of 4 where the most positive score is 4 and
the most negative is 1
4.0

3.5 3.3

3.0 2.8

2.5
2.0
2.0

1.5

1.0

0.5

0.0
Formal classromm training Informal on the job Both formal and on the job
Variables

Figure 10

Users who were given both informal and on the job training gave the highest rating 3.3 whilst those who

only received classroom training gave it the lowest rating.

Accept hypothesis VII

EFFECT OF DURATION OF TRAINING ON ITS EFFECTIVENESS

Mean Scores Calculated out of a weighted score of 4 where the most positive score is 4 and the
most negative is 1
4.0

3.5 3.3
3.0
y = 0.1417x + 2.5833
3.0 2.8 2.7

2.5

2.0

1.5

1.0

0.5

0.0
One day More than one but less than a More than 1 week but less More than one month
week than a month
Duration

Figure 11

Those who received more than one month of training scored it effectiveness the highest at 3.3 however

those who received more than one week abut less than a month scored it the least at 2.7. Users trained for

more than one day but less than a week scored it at 3.0. Range between the rankings was low at 0.6.

40
Accept Hypothesis VIII.

Modules Trained in Versus Modules Used

Trained Use Correlation

Finance and control 7 9

Materials management 3 4 Column 1 Column 2

Business workflow 3 4 Column 1 1

Treasury 9 9 Column 2 0.9600595 1

Human Resources 2 4

Work Bench 1 1

Table 1.

Correlation between the modules trained and module used was positive at 0.96.

Accept Hypothesis IX.

5.10. Technical Support

H X: There is adequate system support that ensures that the system is available for users.

41
 SYSTEM SUPPORT
Mean Scores Calculated out of a weighted score of 4 where the
most positive score is 4 and the most negative is 1

4.0 3.3 3.3

3.0 3.0
3.0 3.1 2.53.0 3.0 3.1 3.3
System
2.0 Availability
1.0 Availability of
0.0 support

Avg. CFBD ACS FIN PMD

Mean
Department + Average

Figure 12

Systems availability and system support have been rated highly in the organisation 3.0 and 3.1 respectively.

The biggest range between system availability and support availability is found in credit finance and

business development at .5.

Accept Hypothesis X.

5.11. Communication

H XI: There is a positive attitude towards communication between users and systems facilitators.

Users regularly provide feedback and are in turn consulted for input.

42
 COMMINICATION
POSITIVE ATTRIBUTES

120%

100% 100% Provides feedback to

100%
implementation & support
86%
staff
80% 75%
67% Consulted for input
60%
50%

40%
31%
33% Involved in assessing
25% training needs
17%
20% 14%

4%
0% 0% 0%
0%
Avg. CFBD ACS FIN PMD

Department + Average

Figure 13

86 per cent of users say that they provide feedback to support and implementation staff. However only 31

per cent say that they were consulted for their roles in the system, further only a paltry 4 per cent say that

they were involved in assessing their training needs.

Reject Hypothesis XI.

5.12. Overall Systems Assessment

H XII The current system has catered for the requirements of the users.

H XIII The system has had a positive effect on work in the organisation.

OVERALL PERFORMANCE
POSITIVE ATTRIBUTES

120%

100% 100%
100%

84%

80% 75% 75%

67%

60%
Likes of the system
50% 50%
47% Effect of implementation

40%
29%

20%

0%
Total CFBD ACS FIN PMD

Department + Average

Figure 14

43
Only 47 per cent of the users interviewed expressed full satisfaction with the current systems functionality.

The finance department gave the lowest rating where only 29 percent approved of the system.

Reject hypothesis XII.

There is a consensus that the system has had a positive effect on the organisation. This is reflected across

the entire organisation with the lowest positive comments being in administration and corporate services

where 67 per cent agreed.

Accept Hypothesis XIII.

5.13. Project Management

H XIV: The project was staffed and managed professionally.

Variables tested include appropriate software and technology use, team experience in domain,

management reviews and configuration management.

Project Management Analysis

Mean Scores Calculated out of a weighted score of 4 where the most positive score is 4 and the most negative is 1

3.6
3.5 3.5 3.5
3.5

3.4 3.4

3.3 3.3

3.2

3.1
3.0
3.0

2.9

2.8

2.7
Software Support Team Experience Technology Use Management Reviews Configuration Avg. Mean
Management

Questions

Figure 15

All variables were scored highly with the least being a mean of 3.0 for project management software use

three variables were rated at 3.5 (Team experience, Technology use and Configuration management). The

average mean was 3.4.

Accept Hypothesis XIV.

44
5.14. Objective Achievement

H XV: The project was successfully completed within the stipulated time and within budget.

H XVI: The specified functionality was successfully incorporated into the ERP system.

Objectives

Objective Outcome

Integrated system Achieved

Functionality Achieved

Budget Achieved

Time Not Achieved - 6 Months

Timely Reports Achieved

Strategic IT use Achieved

Table 2: Objectives set out. Source: Interview with

senior management.

Objectives Achievement
Mean Scores Calculated out of a weighted score of 4 where the most positive score is 4 and the most
negative is 1

3.6
3.5 3.5
3.5

3.4

3.3

3.2
Series1
3.1
3.0
3

2.9

2.8

2.7
Financial Time Functionality

Questions

Figure 16

Financial and Time variables all got a high score of 3.5 and 3.0 respectively, and this would tend to support

hypothesis XV however data from documentation and interview with management does not corroborate

this, although the project met the financial objectives the time objective was not met.

45
Reject Hypothesis XV.

Functionality scored 3.5. No evidence from other sources disproves this.

Accept Hypothesis XVI.

5.15. Business Process

H XVII: Systems requirements given to the consultants represented what the client

wanted

Sy s t e ms R e qui r e me nt s
M e a n Sc or e s C al c ul a t e d out of a we i ght e d s c or e of 4 whe r e t he mos t pos i t i v e s c or e i s 4
a nd t he mos t ne ga t i v e i s 1

3. 3
3. 3
3. 3

3. 2

3. 2

3. 1
Ser i es 1
3. 1
3. 0
3. 0

3. 0

2. 9

2. 9
Cus t omer Requi r ement s Change Requi r ement s

Quest i ons

Figure 17

The implementers agreed that the customer requirements were precise and that any changes were within

acceptable range by rating the variables at 3.0 and 3.3 respectively.

Accept hypothesis XVII.

5.16. Controlling and Risk Management.

H XVIII: The client adequately handled cost control and risk

management

46
 R i s k M a na ge me nt & C ont r ol
M e a n Sc or e s C a l c ul a t e d out of a we i ght e d s c or e of 4 whe r e t he mos t pos i t i v e s c or e i s 4 a nd
t he mos t ne ga t i v e i s 1

3. 55
3. 5
3. 5

3. 45

3. 4

3. 35
Ser i es 1
3. 3
3. 3
3. 25

3. 2

3. 15

3. 1
Qual i t y A s suar anc e Ri s k M anagement

Quest i ons

Figure 18

Quality assurance and risk management were rated at 3.5 and 3.3 respectively.

Accept hypothesis XVIII.

5.17. Project Outcome

H XIX: The implementation team, management and users were satisfied with the project.

P r oj e c t Sa t i s f a c t i on
M e a n Sc or e s C a l c ul a t e d out of a we i ght e d s c or e of 4 whe r e t he mos t pos i t i v e s c or e i s 4
a nd t he mos t ne ga t i v e i s 1

3. 6
3. 5
3. 5

3. 4

3. 3 3. 3

3. 2
Ser i es 1
3. 1
3. 0
3

2. 9

2. 8

2. 7
T eam Sat i s f ac at i on M anagement Sat i s f ac t i on Cus t omer Sat i s f act i on

Quest i ons

Figure 19

47
The implementers all rated these variables highly. The highest rate was 3.5 for team satisfaction with the

project user satisfaction was rated at 3.3 while the lowest was management satisfaction, which was rated at

3.0.

Accept hypothesis XIX.

5.18. Selection Criteria

Product Analysis

Company Product Price (US$) Score Comments

Software Tailor Made 245,435.00 Not Tested

Technologies

Group

Infosys BANCS2000 610,401.00 71 Required functionality

Technologies NOT available, Not

Integrated

System SAP R/3 620,000.00 87 Functionality available,

Aplication Fully Integrated

Products

Computer Equinox 805,861.00 71

Systems Universal

Associates Banking System

Citi Corp I-FLEX 825,030.00 65

Information

Technologies

Industries

Satyam Tailor Made 1,367,520.00 Not Tested

Computer

Services

48
Table 3.

Criteria used to rank the systems include level of integration, User friendliness, local support, cost,

completeness, implementation time, reporting, domain experience, hardware software dependence and

software stability.

SAP R/3 selected as best fit for the organizations requirements.

5.19. Assumptions.

5.19.1. The records kept by the organisation with respect to the implementation reflect a true

representation of events as they occurred during the project.

5.19.2. Data provided by the users was free of any coercion and duress and that it was volunteered in good

faith to facilitate the research.

6. Discussion.

The case study has answered questions posed at the beginning of the study that largely centered on the

evaluation of the implementation and adoption of an ERP system at PTA bank.

ERP system implementation projects are complex and taxing commitments. A steering committee ensures

that the project does not loose focus on the core business processes of the organization by maintaining a

“bigger picture” outlook towards the project. It provides management with a way of monitoring the

implementation process at a closer level, this can be done by facilitating management review as was the

case in this implementation. The steering committee played a crucial role in uniting different departments

behind the system by the fact that the team consisted of users drawn from the various departments.

The selection of an ERP system is the proverbial first step on a very long journey. If it is not executed

carefully then the whole journey is put at risk. The steering committee went to great lengths to search for

49
system that would suit the bank. A comprehensive criteria scorecard was maintained and used to select the

most suitable candidate, which was identified as SAP/R3 (Table 3).

The percentage of users in the organization is lower than expected for an ERP installation, further the

amount of time spent on SAP is very low with only 37 percent of users spending more that 50 percent of

their computer time on the system (Figure 6). This means that there are still a large number of processes

that occur outside the system. This is confirmed by the absence of the basic user roles in CFBD and PMD

departments (Figure 4). Taking into consideration that these departments are the drivers for core business

activities in the bank this is an alarming state of affairs! Subsequent interviews with departmental personnel

revealed that although there is a process in the system that takes a deal from the application, offer and

finally the contract stage, only the contract stage is captured by the system. This in essence denies the

organization valuable information in terms of analyzing deals that did not go through versus those that did.

The contact age of users compared to the age of the SAP system in the organization is very low (Figure 3).

Restructuring in the organization, where some of the users who had been trained at great expense to the

organization left, caused this. This means that the majority users have not had enough time to interact with

the system to the level where they are confident to offer suggestion for its improvement. It may also lead to

the system being taken for granted because the new users do not have the experience of how things were

before the implementation. Hiring back one of the consultants into the organization to bridge the

knowledge gap has alleviated the problem.

Communication is a key component in ERP system adoption in organizations. Users felt that although they

provided feedback to the facilitator group. They were not consulted in creating their roles or in assessing

their training needs (Figure 13). Although a mitigating factor is the fact that most of the users currently on

the system found the ERP system in place, there is need to consult the users on issues that affect them.

Usability of software is an important aspect of quality assurance. The system has been well received by the

users who agree that the system is easy to use and has a logical data flow concomitant with the current

50
process and procedures (figure 7 & 8). This view is further supported by the assertion by the implementers

that system requirements given to them were precise with little or no change required, and that the

functionality objectives were met (Figure 15). Although users felt that correcting erroneous data in the

system was tedious interviews with the facilitators revealed that this was necessary in order to maintain the

data integrity of the system.

ERP systems are installed due to their ability to process data and provide information to users in the form

of reports. Users felt that the system provided accurate and easy to understand report. Users felt that the

system provide information that could not be readily available form other sources, this means that the level

of SAP adoption is high because users rely on the system to provide key information for decision-making

(Figure 9).

When introducing new software to an organization, user training is essential for the correct usage of the

system. This much more crucial in an ERP system because users sometimes not only need to learn about

the new software but often also have to contend with new processes introduce into the organization. Users

felt that the combination of formal-classroom and on the job training was the most effective in imparting

skills. The duration for training was also considered a factor in its effectiveness, it is important to match the

curriculum with the time to ensure that each topic is covered adequately (Figure 10 & 11). The training

regime at PTA bank for SAP has been well targeted and individuals were only trained in modules that they

actually used. This saves the company valuable resources in terms of time spent

Cost control and risk management will directly impact on the successful implementation process or

abandonment of the project due to cost overruns or other unforeseen risk. The steering committee was quite

astute in reducing the risk to a minimum during this implementation. One of the most successful aspect of

cost and risk management occurred when the system delivery date was not met. However, because PTA

bank had signed a fixed cost contract to be paid out in installments pegged on milestone delivery, this did

not impact negatively on the budget of the project even though the project was over 6 months overdue.

51
6.1. Limits of Study

6.1.1. The organisation is still in its early stage of interaction with the ERP system, the long-term impact

of the ERP system could not be investigated.

6.1.2. Some second had data provided by the ERP vendors were not easily verifiable. An attempt was

made to corroborate data from other researchers.

6.1.3. The retrospective nature of the study means that some information might have been left out due to

memory lapses.

7. Conclusions and recommendations

The implementation has by far and large satisfied users and management who profess that it has had a

positive effect on the way the company conducts business. Objectives set out by the organization for

implementing the ERP system. It is important however, for the organization to adopt an attitude of

continuous business improvement towards SAP to ensure that the system stays synchronized with the

company as new process and procedures emerge.

SAP R/3 is in use in the whole organization, users have accepted the system as the way forward in the

organization. There is however, the need to ensure that data is captured at source to enable the system to

function as it was intended, this will involve ensuring that new members of staff are exposed and trained to

actively interact with the system as fast as possible.

SAP R/3 is set to remain the flagship software for the company for a long time to come. The future for SAP

is envisaged as the vehicle for a move towards realization of a paperless office with electronic document

processing and storage.

8. References

AGARWAL, R. 2000. Individual Acceptance of Information Technologies. Framing the Domains of IT

Management: Projecting the Future through the Past., ed. R.W. Zmud. 2000, Pinnaflex Inc: Cincinnati. P

52
85-104.

ALADWANI, A. A. (2001). Change management strategies for successful ERP implementation, Business

Process Management Journal, 7/3, p266-275

ALADWANI, A. M. (2001) Change management strategies for successful ERP implementation. Business

process management 7/3 2001 p266-275 MCB University Press.

ALLAN, G.W., (1997). A Holistic Model for Change Control. New York: Plenum

Al-MASHARI, M. (2002). Enterprise Resource Planning Systems: a research agenda. Industrial

Management & Data Systems 102/3 2002 p. 165-170.

Al-MASHARI, M.; Al-Mudimingh, A. And Zairi, M., (2003) Enterprise Resource Planning: taxonomy of

Critical Factors. European Journal of Operational Research www.sciencedirect.com .

BERNROIDER, E. And Koch, S (2001) ERP Selection Process in Midsize and Large Organisations.

Business Process Management Journal 7(3) 2001 p 251-257

BRADLEY, J. (2002). ERP Systems Implementation and Management Theory. Paper presented at the

2002 Information Resources Management Association International Conference, Seattle, WA and included

in the conference proceedings, Issues & Trends of Information Technology Management in Contemporary

Organizations, Mehdi Khosrow-Pour, Ed. Idea Group Publishing, Hershey, PA

CHUNG, S. H. And SNYDER, C. A. (2000). ERP adoption: a technological evolution approach.

International journal of agile management systems 2/1 p 24-32 MCB university press.

CHUNG, S. H. (2000). ERP adoption: a technical evolution approach. International Journal of Agile

Management Systems 2/1, 2000 p.24-32

CIMA 2001 Technical Briefing – Enterprise resource Planning (ERP) – An overview, Chartered Institute

of Management Accountants London.

COTTRELL, M & Hughes, B, Software Project Management, International Thomson Press, London, 1995

CSU (2003) Writing Guide: Case Study

53
http://writing.colostate.edu/references/research/casestudy/pop3f.cfm

DAVENPORT, T. H. (1998). Putting the Enterprise into the Enterprise System, Harvard Business Review,

Jul-Aug., 76 (July/August) p121-131

DAVENPORT, T. H. (1998). Putting the enterprise into the enterprise system, Harvard Business Review,

July-august 1998 v 76 n4 p121-132, Harvard Business School Publishing.

DAVENPORT, T. H. (2000). Mission Critical: Realizing The Promise of Enterprise Systems, Harvard

Business School Press, Boston.

DONOVAN, R.M 2002 Successful ERP Implementation the First Time

http://www.crm2day.com/crm_articles/

ESI 1998 Software Engineering Project Management and Metrication European Software Institute

http://www.esi.es/ESSI/Reports/All/10616/Report/index.htm

ESTEVES, J. And Pastor, J. (2001) Analysis of Critical Success Factors Relevance Along SAP

Implementation Phases. Seventh Americas Conference on Information Systems 2001 p1019 1025

ESTEVES, M. J. And Pastor, J. (1999). An ERP Life Cycle-based Research Agenda, Venice, First

Workshop in Enterprise Management and Resource Planning: Methods, tools and Architecture.

ESTEVES, M. J. And J. A. Pastor (2000). Towards the Unification of Critical Success Factors for ERP

Implementations. Http://www.lsi.es/~jesteves/bit2000.htm accessed 10/29/2002

GIBSON, N., Holland, P. C. And Light, B. Enterprise Resource Planning: A Business Approach to System

Development. In Proceedings of the 32nd Hawaii International Conference on System Sciences. 1999.

Hawaii.

GUPTA, A. (2000) Enterprise resource planning: The emerging organizational value systems. Industrial

management and data systems. 100/3 p114-118.

HITT, L. M, WU, D.J. AND ZHOU, X. Investment in enterprise resource planning: business impact and

productivity measures. Journal of Management Information systems, summer 2002, Vol 19 No. 1 p 71-98.

54
M.E Sharpe, Inc

IBM Global Services (2000) Using IT change management processes to navigate the transition to e-

business Copyright IBM Corporation 2000

INJAZZ J. C. (2001). Planning for ERP systems: analysis and future trend Business Process Management

Journal Vol 7 No. 5 2001 p 374-386 MCB university press.

JACOBS, F. R. And Bendoly, E. (2003) Enterprise resource planning: Development and Directions for

Operations Management Research. European Journal of Operational Research 146 (2003) p233-240

KIRSCH, L.J., ed. Software Project Management: An Integrated Perspective for an Emerging Paradigm.

Framing the Domains of IT Management: Projecting the Future through the Past., ed. R.W. Zmud. 2000,

Pinnaflex Inc: Cincinnati. 285-304.

KLAUS, H.; ROSEMANN, M and G. GABLE (2000). What is ERP? Information Systems Frontiers, 1980,

p.141.

KLAUS, H.R., M and G. Gable, What is ERP? Information Systems Frontiers,, 2000: p. 141.

KOCH, C. (2002). The abcs of ERP. ERP Research centre CIO Magazine

http://www.cio.com/research/erp/erpbasics.html

KOUL, L. Methodology of Educational Research. 2nd ed. Vikas Publishing House PVT Ltd. Delhi

KRAEMMEGRGAARD, P. And Moller, C. (2000) A Research Framework for Studying the

Implementation of Enterprise Resources and planning (ERP) systems. Proceedings if IRIS 23 Laboratium

for Interaction Technology Udevalla 2000

MARKUS, M.L. and C. Tanis, The Enterprise System Experience - From Adoption to Success, in Framing

the Domains of IT Management: Projecting the Future through the Past, R.W. Zmud, Editor. 2000,

Pinnaflex Inc: Cincinnati.

MENDELSON, H. (2000). ERP overview. Graduate School of Business, Stanford University, Stanford

NAH, F.F. and J.L. Lau, Critical Factors for Successful Implementation of Enterprise Systems. Business

55
Process Management Journal, 2001. 7(3): p. 285-296.

NIELSEN, L. J. (2002) IMPLEMENTING AN ERP SYSTEM IN A UNIVERSITY ENVIRONMENT: A

CASE STUDY FROM THE AUSTRALIAN HES Faculty of Engineering and Information Technology

Griffith University http://www.ecommerce.cit.gu.edu.au/cit/docs/theses/jnielsen_Dissertation_ERP.pdf

(accessed 04/02/03)

O’LEARY, D. E (2000) Enterprise resource planning systems: Systems, Life Cycle, electronic Commerce,

and risk. Cambridge University Press Cambridge.

OKOLICA, C. (2000). Factors Affecting Systems Implementation: The case of Enterprise Resource

Planning Systems, Proceedings of the 16th Annual conference of the International Academy for Information

Management.

OSTERLAND, A. (2000) Blaming ERP, CFO Magazine January 2002

PAYNE, W. (2002). The time for ERP? Work Study 51/2 p 91-93MCB UP Limited.

PMI’s A Guide to the Project Management Body of Knowledge (PMBOK® Guide) - 2000 Edition

ROBEY, D., ROSS, W. J. AND BOUDRUE, M. C. (2000). Learning to implement enterprise systems: An

explanatory study of the dialectics of change. Georgia state university

ROBSON, W. 1994 Strategic Management and Information systems: A Integrated Approach Pitman

Publishing London.

ROSS, J. (1999). Dow Corning Corporation: Business Processes and Information Technology, The Journal

of Information Technology, 1999 14,

SAO (2002) State Auditors Office Methodology Manual: Data Analysis Modules

http://www.sao.state.tx.us/Resources/Manuals/Method/default.html

SCHNEIDER, J. (1999). Human touch sorely needed in ERP CIO Magazine March 2

SEDDON, P.B., D.S. Staples, R. Patnayakuni, R. And M.J. Bowtell, "Dimensions of Information Systems

Success", Communications of the Association of Information Systems, 1999.

56
Http://cais.isworld.org/articles/2-20/article.htm

SHANG, S. And SEDDON, P.B. (2000) “A Comprehensive Framework for Classifying the Benefits of

ERP Systems”, Americas Conference on Information Systems (AMCIS 2000), Aug 10-13, 2000, Long

Beach, California.

SIRIGINIDI, S. R (2000). Enterprise resource planning in reengineering business, Business Process

Management Journal, 6/5 2000, p376-391

SIRIGINIDI, S. R (2000b). Enterprise Resource Planning: Business Needs and Technologies. Industrial

Management and Data Systems 100(2) 2000 p81-88 MCB University Press

UMBLE, E. J; Haft, R. R. And Umble, M. M. Enterprise Resource Planning: Implementation Procedures

and Critical Success Factors.

VOSBURG, J. And Kumar, A (2001) Managing Dirty Data in Organisations Using ERP: Lessons from a

Case Study. Industrial Management & Data systems 101(1) 2001 p 21-31.

WARD, J. And GRIFITHS, P. (1998) Strategic Planning for Information Systems, 2nd Edition, J. Wiley

WIGHT, O. W. (1984). Manufacturing resource planning: MRP II, Oliver Wight LTD. Publications, Essex.

WILLIS, T. H. And WILLIS-BROWN, A. H. (2002).Extending the value of ERP, Industrial management

and data systems 102/1 p35-38 MCB university press.

57
Acknowledgements

58
Appendix I – Questionnaire

59
Appendix II – Interview Schedule

60
Appendix III – Data Analysis

61
Appendix IV – Project Schedule

62