¹Department of Computer Science, Faculty of Computing & Information Technology, King Abdulaziz University, Jeddah, Saudi Arabia

²Department of Computer Science, University of Maryland, College Park, USA

^3,4Department of Information Systems, Faculty of Computing & Information Technology, King Abdulaziz University, Jeddah, Saudi Arabia

Corresponding author Email: waljedaibi@kau.edu.sa

Article Publishing History

Introduction

In 2010, King Abdulaziz University (KAU) in Jeddah, Saudi Arabia decided that there was a need to improve, integrate and automate its administrative and finance business processes. It was decided that acquiring an ERP system would create the basis for the future evolution of KAU’s transition to an efficient, productive and fully integrated business environment, and it would keep pace with the evolution of the e-government system by providing an automated platform that can be integrated with other public sectors. It went through an RFP and bidding process, chose an implementer and developed an ERP System. The implementation which was anticipated to take 18 months, took 36 months and cost about 25% more than was expected from the original bid and the system was not fully implemented, i.e., only the Finance and Control were run in parallel with the existing system. At the time, the system was partially developed but not deployed. This presented an opportunity to analyze the problems involved and pose a solution based upon this analysis. It is important that we understand what went wrong and how we could have done a better job in the next implementation of an ERP.

This paper focuses on KAU’s experience with contracting out the ERP system, i.e., the writing the RFP and selecting the bidder. Our approach has been to ‘learn by application’ [14], where we use observation of what happened to evolve the method we used. We began by characterizing the approach that was used and the consequences of various decisions that were made. We then identified the problems encountered based upon analysis of the available data and interviews with members of the KAU project management team. To assure a broad view of problems, we identified documented problems from the literature that were similar to the ones we experienced and supplemented that set with problems specific to the local environment. This analysis provided input for the development of several techniques that we believe would minimize the number of surprises and challenges that arose and contributed to a more successful ERP deployment. We packaged these techniques into a new method that allows us to compare and evaluate ERP proposals. We then applied the method to a subset of the organization’s business process as a pilot to check the feasibility and usability of the method.

The method aims at providing sufficient information before the implementation begins that would help an organization write a better RFP and do a better job of assessing the relative effort of the submitted bids. We believe our experience was not unique; many organizations have struggled with implementing an ERP [7, 8, 9, 10,11]. In fact, many organizations, who have achieved a successful ERP implementation, were successful on the second try [1].

Background For The Study

King Abdulaziz University (KAU) was established in 1967 as a national university aimed at spreading higher education in the western area of Saudi Arabia. It offers university education to both female and male students [2]. The university has witnessed much improvement in quality and quantity since it was first established, becoming one of the more distinguished universities in terms of the number of students, the number of scientific and theoretical fields of study, and the quality of its programs. It is also the only university in Saudi Arabia that offers certain specializations such as Sea Sciences, Geology, Nuclear Engineering, Medical Engineering, Meteorology, Aviation, and Mineralogy.

The main administrative business departments of the University are Human Resources, Finance and Accounting, Budgeting and Planning, Procurement and Contract, and Warehouse and Inventory. These business departments report to KAU’s vice president for approval of major decisions. TABLE I lists the main business processes in the Procurement and Contract department. It shows the status of automation of the business processes in the current KAU legacy system. We will refer to this table later when we map KAU business processes into the selected ERP system. It will help us identify the gap between current KAU business processes and the selected ERP system, as well as giving us an indication of how many of these processes are covered in the new system compared to the KAU legacy system.

The University developed its legacy based administrative system over a 17 year period. It was developed using COBOL-CICS and the IBM DB2 database on an IBM mainframe machine. The system was composed of human resource business functionalities which had evolved to an effective level. The Accounting and Finance system was also developed to include most business functionalities. The least developed systems were the procurement and contract modules and the warehouse and inventory modules. Each of these business modules evolved separately.

During the implementation of the ERP system we selected at KAU we faced some challenges and they can be categorized as follows:

1. Functional issues
2. Insufficient business functionalities
3. Lack of integration between business modules
4. Data inconsistency, inaccuracy and incompleteness
5. Incomplete Business Process automation
6. Technical issues
7. Un-normalized Database tables
8. Lack of support for Web-based applications
9. Lack of documentation
10. Unstructured applications landscape

A major issue with the current legacy system is the lack of integration of the various business modules. Each department is functioning as a silo, independent of the other business departments (see figure 1). This creates a collection of information silos within the legacy system where information is not shared between modules [3]. Every module has its own database tables with different fields and different encoded names for each business unit. This created a huge set of data inconsistency and redundancy problems in the system and information flow between those systems was severely limited. Another issue with the legacy system is that it lacks support for web technologies to port the modules to a new web-based system. Due to these complexities, most business processes were not automated; most of the work was done manually where the end-user fed the final data into a form on the screen so that a formatted report could be printed on official paper. Also, legacy applications were not well documented so it was difficult for developers to maintain the system and database tables were not normalized causing a lot of data problems.

So, it was very clear that KAU had to enhance its administrative business processes through the acquisition of an ERP system. We decided to conduct an ERP readiness report [4, 5]. The readiness exercise was conducted over 10 weeks. We hired International consultants who had experience in ERP project implementation and management. The scope of the readiness assessment was to evaluate KAU business processes (a sample of these business processes are shown in table I with their status in the legacy system), organization maturity and IT readiness. The findings encouraged KAU to proceed with acquiring an ERP system. We prepared the RFP as described in [6, 13] where we discuss the RFP preparation process in details.

Table 1: Some Business Processes Status in the Legacy System

Modules/Business Processes	Status in Legacy System
1. Purchasing
1.1 Purchase Requisition	Not implemented
1.2 Purchase Requisition Approval	Not implemented
1.3 Quotation Process	Not implemented
1.4 Purchase Order	Partially implemented
2. Inventory and Warehouse Business Processes
2.1 Goods Receipt with Gov. Serial Number & Warehouse Books Interval Number	Implemented
2.2 Request (Reserve) Stock from Warehouse with approval workflow	Not implemented
2.3 Goods Issue Stock from Warehouse with Gov. Serial Number & Interval Number	Implemented
2.4 Goods Receipt or Goods Issue Cancellation	Not implemented
2.5 Return Asset to Warehouse	Partially implemented
3. Logistic Invoice Processes
3.1 Enter Invoice	Partially Implemented
3.2 Advance Payment	Not implemented
4. Vendor Registration
4.1 Register new vendor by KAU	Partially Implemented
4.2 Maintain/Update Vendor Data By KAU	Not implemented
4.3 Register/Maintain/Update Vendor Data By Vendor using online services	Not implemented

ERP implementations pose several common challenges to enterprises [7, 8, 9]. Although the lack of proper communications between the parties involved in the project was reported as the overriding problem [7], there were other interesting challenges encountered. For example, the resistance to change in updating existing business processes, the lack of training on the new system and technologies, and the existence of fewer experts than needed by the project. A crucial piece of advice by others is not to treat an ERP project as “just another IT project” but rather a transformational project for the whole enterprise [10]. In almost all cases, enterprises should look at an ERP project from a different point of view in the sense that they provide a window of opportunity for re-evaluation of the business processes and may possibly lead to improving them.

Success of ERP projects is deeply affected by how change is managed throughout all related activities. In particular, rigorous controls must be placed on the number of desired customizations applied to the eventual system [11]. A customization is a new or additional functionalities applied to the system as required by process owners (POs), a full definition of customization is provided later (section IV.B. Details of the Method) in step 3 of our method. Continually changing and inconsistent requirements are viewed as impediments to success as they waste project resources and raise frustration amongst team members [9].

Additional challenges arise based upon certain environmental constraints and in our case we witnessed a couple of these. First, there was a critical issue with language and system localization in which it was required to implement a code change in the core of the system. For example, in the ERP system we used, the database imposed a 40 character limit in name fields which was insufficient for the use of the Arabic language [6, 13]. We also encountered a suite of challenges with data due to the organizational changes in the enterprise that were going on at the same time. There was not a problem in mapping the organizational structure and financial organizational structure (i.e. Budget allocation structure and related accounting activities) to the ERP system. However, there were mismatches between data of the two structures that yielded slightly different sets of views such as different field tag names and different data type for the same field in different views. As a result, we were faced with problems that required data to be cleansed and mapped correctly. Negotiations on any data related issues required a complicated process of reviews followed by a lengthy administrative approval process.

Being a government agency requires strict adherence to all government policies and procedures. The rules say what must be done, not how to do it, so there are several ways a rule could be implemented and still be correct. So having different implementations should not have created a problem. However, we encountered problems in mapping the local implementations of business processes to the ERP system as in some situations a local valid interpretation of a business rule was not easy to map into the ERP implementation of the rule.

By default ERP systems are shipped with a set of best practice business processes characterized in workflows and a set of tools to design and/or extend them. However, KAU business process owners expected that all current business processes would be mapped to the new system as is. This represented a major source of customizations to the ERP standard workflows and hence additional costs on the project that was not accounted for in the original project RFP. It should be noted here that it is not uncommon to customize some workflows to reflect essential local business processes which must stay as-is. In our experience, the reluctance to compromise on changes and accept more effective business process implementations can be attributed to a lack of understanding that (1) the new system was supposed to improve their processes and (2) the new process was actually an improvement, e.g., it allowed integration, but had the same effect as the as-is process. We also encountered cases where the business owners resisted changing the as-is business processes due to personal views and/or simply intransigence. In other cases, change was perceived as creating more work in the future workload and rejecting it seemed like an easy out.

Translation from Arabic to the English language was another challenge we faced; especially since there was no consensus on the meaning of certain terms in the Arabic language to start with. Different departments sometimes had a different understanding of the meaning of the same term. In some cases this was acceptable since it reflected terms that were only used internally within the particular department. Reaching agreements to unify terminology, however, was not an easy venture for either the KAU management team or the ERP implementation team.

Validation of entry fields in all screens posed another key challenge. Although there was a minimal set of validations checks in the legacy system, as the implementation progressed, users felt the new system should be more vigilant by providing an extensive range of validation rules and checks for all types of data entry fields, e.g. direct fields and derived values. For example, users requested that based on values entered in field date_of_birth a validation check must be executed to apply the rule: “Employee age must be LESS THAN 60 years old at the time of appointment”.

While validation checks are an integral part of modern software systems and are included as default in normal application, extensive checks attached to derived values resulted in a plethora of customization requests for almost all ERP screens. Two issues that characterize this challenge are:

1. New validation schemes needed to be designed and developed to satisfy evolving user requests.
2. We needed to integrate them with validation techniques already defined in the ERP system.

Validation is not a trivial process [12]. Some validation schemes were designed and developed to satisfy business process owner’s and user’s requests. However, it was not always possible to design and develop validation rules that would satisfy their requests as there was not sufficient related data to do so. For example, if some data is entered at a specific entry field, and the user require a validation rule to be applied to it, then that might affect or restrict another field in the same form or another screen. So, validation on field has to be thoroughly investigated and negotiated with the users before applying them.

In general, it was clear that users had imprudently high expectations of the ERP project implementation. Initial ERP project goals were to achieve higher levels of efficiency, transparency, and improved budget utilization. User and business owners, nevertheless, felt it was an opportunity to automate every administrative aspect of the organization as they were already doing it; a clear deviation from the original project plan. There was a lack of project vision especially since ERP projects are of a transformational nature when compared to automation projects. Enterprise organizations should expect a gradual growth in organizational maturity level after an initial ERP implementation; and if it is placed within a phased-development track, it will certainly yield in more improvements in the future.

We define our terminology for the sake of consistency. We will use the terms organization and client interchangeably to mean the purchaser of the ERP system. We will use the term vendor to mean the ERP system provider which is being used as the base for the client’s transformed system. We will use the terms contractor and bidder for the responder to the RFP, using the vendor’s ERP system as the base for their proposal.

An Experience-Based Approach

As stated above, ERP projects are complex transformational projects and, in almost all cases, span several departments of the enterprise. Challenges will always occur while progressing towards a successful deployment of the final system. They will most likely continue to appear as the enterprise organization evolves and implementation environments keep changing. As a result, challenges are an essential part of the game and we believe they should be handled positively; any plans to eliminate them are not practical and can waste valuable project resources. Instead, an ERP project management team should put forth plans to manage and limit their impact. A first step is to gain early knowledge of their existence and develop a clear vision of what lays ahead in the project path. Analysis of each challenge and its associated difficulties is needed so that remedies can be discussed with the involved parties. As can be expected, challenges within a single department are easier to manage than those hovering over the territories of two or more departments. The latter requires a lengthier process of reviews, discussion of possible remedies, and negotiations.

Based upon the lessons learned from our unsuccessful first experience we present a method for exposing challenges early to gain insights into their nature and to assess their relative impact on the implementation. The approach suggests a major juxtaposition of effort, up-front, which allows an organization to learn before making a commitment, to better understand what they really need. It allows for the opportunity to bring business owners on board early, allowing them to prioritize their needs and shows them the cost of not compromising the implementation of some of their current as-is business processes. The degree of the impact of not compromising is reflected in the amount of customization needed in the sense that unsolved challenges will result in business owners requiring major customizations to the implementation. Our method devises an early evaluation process for ERP project bids from which we can learn the expected number of changes required to the system’s implementation. The goal is to discover, expose, and treat sources of ERP changes in the best way possible.

Overview of the Evaluation Method

The method we present here is based on early assessment of organizational needs, evaluating them against what is offered by more than one potential ERP solution. The evaluation is fine grained at the level of the specific enterprise business processes, exploring the degree of change required by the different ERP system solutions proposed. Applying the method must precede any effort towards setting up and/or executing an ERP implementation plan; and it will enable enterprise organizations to:

1. Explore their business processes in details,
2. Classify their business process needs,
3. Match organizational business processes to what each ERP offers, and
4. Develop a clear understanding of what level of change each ERP solution requires.

In more detail, here are the three major processes and documents developed by the method as shown in figure 2:

Phase 1 – Requirements Exploration:

Step1: Preliminary Requirements involves building a preliminary requirements document which documents all the current, as-is business processes in a consistent organized form and provides an indication of how much flexibility is available for the contractor. Abstractions of these two pieces of information are represented in the first two columns of the evaluation matrix as presented in TABLE II. Each row of the evaluation matrix represents information about a particular business process. The first column contains the name of the process as it exists in the legacy system. The next column represents the flexibility with respect to each of the business processes as will be explained in Step 1 below. This represents the version of the requirements that goes into the RFP for the bidders. It is the initial step for the bidding process.

Phase 2 – Contractor Requirements Analysis:

The matrix set up by the client is filled in by the contractor, with the vendor’s support. It is characterized by steps 2 and 3, in which the interested contractors create a mapping of the client’s needs to the vendor’s system and the contractors’ estimate of what will be required to implement the client’s business process relative to the vendor system. Each row of the evaluation matrix represents information about a particular business process.

Step 2: Process Mapping: Identify the closest processes in the vendor’s ERP system to the listed set of processes in the legacy system.

Step 3: Change Identification: Characterize the changes to the ERP system that are needed

Phase 3 – Matrix Evaluation and Negotiation:

Step 4: Relative Effort Analysis: The client analyzes the relative effort required to make the changes for each business process

Step 5: Process Modification: The project management team negotiates with the business process owners, armed with the relative effort data to make the modification to the implementation of each specific process, so they can understand what the ERP system offers and the cost of not adapting to the new processes. Based upon the outputs of this discussion, a final requirements document is created.

Step 6: Contractor Selection: Using the final requirements document, the client evaluates the proposals by estimating the relative effort and time involved based upon the amount and type of change needed to the vendor’s system and picks the contractor with the best relative offer. Note that if two of more contractors bid the same vendor system, it would be possible to compare implementations in detail to help with the selection.

Details of the Method

The steps of the method are explained as follows:

Step 1

Define an as-is document of the business processes (BPs) with the support of the processes owners. A business process consists of mainly 4 parts:

1. A template,
2. Input data,
3. Business rule(s), and
4. Workflow and approval cycle.

For each business process, process owners (POs) are all encouraged to recommend potential improvements to the process and are made aware of the necessity of integrations with other business processes. The business processes are defined as the set of steps needed to be performed, the business rules followed, the forms needed for the process, the approvals required, and the outputs expected, such as reports that need to be generated. A by-product of this step should be the creation of a relationship with the POs, preparing for change and making them aware of the need for integrating their processes with other POs. The result is an exploratory requirements document that describes each as-is process and the level of importance and flexibility specified by the POs. An example set of classifications for a sample set of business processes are provided in TABLE II. Classifications are:

1. M: Mandatory

A mandatory process is a must have; it must be part of any ERP implementation.

1. GTH: Good to Have

A good-to-have process does not necessarily have to be part of the ERP implementation, but it is good to have if possible.

1. NU: Not Urgent

A not-urgent process is a one that is not needed right away in the upcoming ERP implementation. Flagging a BP as NU does not exclude it from future ERP implementation upgrades, but business owners at this early stage are okay to continue using it as is.

A set of questions can be sent by the bidders to the client; identifying such things as can a business process be changed in some way to minimize effort. These questions will be answered with the advice and consent of the POs. The exploratory requirements document and responses to the bidder’s question are used by the bidders to select the most appropriate vendor for the enterprise.

Step 2

The contractor matches the organization BP’s to those offered by their selected ERP system. TABLE III shows an example snapshot of KAU business processes and their match in the ERP they selected, i.e. SAP. Matching processes does not signify full equivalence between two processes but rather the ERP process that is the best match to the organization’s process. For instance, SAP standard BP “Create purchase requisition (PR)” does not necessarily embodied the exact internal steps and logic required by its matched KAU BP, but it is the one the bidder will customize to achieve the specified process.

Step 3

The client provides a matrix for the bidders to fill in where they propose their chosen vendor’s system and whether that process is standard, needs additional configuration, needs some level of customization, requires a third party integration, or requires the writing of extra code. They also suggest how they can provide certain customizations to minimize the effort by certain reasonable modifications to the business processes in accord with the client’s statements of flexibility. By the end of this process, the client will have the ability to estimate the relative effort required to implement each of the bidder’s proposals and what opportunities are available to make changes to the business processes that would lower effort. TABLE IV shows an example analysis of KAU/SAP processes as was analyzed by a contractor. The analysis is based on vendor’s and contractor’s response and reviewed by subject matter experts (SMEs) from the within the organization. The organization is expected to have their own product and functional consultant and/or a third party BP consulting firm. Vendor and contractor response should mark matched organization/ERP business processes with symbolic qualifiers for expected change as follows:

Standard (S)

meaning the required business process exists as a standard in the vendor’s system and it can be used as is or with minimum configuration, i.e., no major effort is needed to make it usable.

Configuration (CF)

meaning the process is supported by the vendor system but requires a setting or adjustment of the parameters or adding a new field or adding a new approval cycle. These types of adjustments are supported by the vendor’s system. The benefit of configuration is to provide flexibility within the system to allow the alignment of the ERP functions with the PO requirement by using standard functionalities exist in ERP product.

Customization (CZ)

Meaning the PO requirement cannot fulfilled using standard functionalities provided by vendor/ERP, to incorporate these requirements it might require enhancing the system by developing new or additional functionalities e.g. describing new screens, changing field positions on forms, integrating processes, or introducing new forms. You still have to integrate these changes with the system but without changing the existing vendor source code. This form of customization has the long term problem that the extension might not be compatible with future updates and releases of the system.

Third Party Integration (TPI)

Meaning that the ERP system cannot provide a major functionality required by PO, without the contractor adopting some other system to fulfill this requirement, but it requires the integration of this system with ERP. For example, if you want to implement a smart card or finger print recognition capability in the system, then you need to use a party integration. This involves customization and the added negotiation and interaction with the third party code which might include its own non-compatibility evolution. It may also involve source code change if the third party system is not set up to be integrated with the vendor’s standards of integration.

Change Source Code (CSC)

Meaning the vendor code must be changed. This has the short term problem of extending the functionality of the existing system and also has that long term problem that this new code might not be compatible with future updates and releases of the system. An example of the need for changing source code is if an algorithm within the ERP system is not fulfilling the process owner requirement and the algorithm needs to be modified. Needless to say, CSCs rarely occur.

Step 4

After reviewing and approving contractors’ responses, numerical weights are assigned on each process to note how much change is expected when choosing a specific ERP solution. Figure 3 depicts numerical weights to be given to symbolic qualifiers and TABLE V shows the actual worksheet. For example, if a business process is rated as standard, there is minimal cost associated with the implementation, let’s say we assign that a value of 1. If the business process is rated as requiring a configuration, we assign a value of 2, as it is a least twice the work of a standard. For customization, we assign a value of 4 to 6 as we consider it two to three times as complicated as a configuration. Performing third party integration is most likely at least twice the effort as a customization, so we assign it an 8 to 12. A source code customization can be anywhere from a 12 to 16 due to it both short term and long term effects.

Figure 1: Information silo between business departments

 

Figure 2: Evaluation method phases and steps

 

Figure 3: Symbolic qualifiers and their nurmerical weight values

These values are provided based upon the experience from our own KAU implementation where the standard processes have been implemented by the contractor with minimal effort such as Enter Invoice (TABLE V: 3^rd row), whilst some other business processes associated with customization and it required considerable effort such as Online Registration (TABLE V: 6^th row). On other hand, some of the business processes did not match ERP standard functionalities, thus the customization was not pebble, to incorporate such type of processes the contractor must integrate a functionality provided by a third party into the system and it required more effort of a customization, for example a single sign-on subsystem was added as a TPI (TABLE V: last row).

The categories selected here were based upon our experience with the KAU implementation. But another client might want to select different categories and different rating values. Based on TABLE IV in step 3, numerical weights are assigned to each symbolic quantifier.

Table 2: A Snapshot of KAU BPs classified according to organization needs
KAU Business Processes	KAU Needs
Invoice
Enter Invoice	M
E-Invoice	GTH
Advance Payment	M
Vendor Registration
Register and Maintain Vendor Data by KAU	M
Online Registration by Vendor	NU
Material Master
Create/Change Material Master (General Data)	M
Batch Management	NU
Login (Technical Requirement)
Single Sign-In	NU

TABLE V shows a partial list of real KAU BPs assigned numerical weights by a potential contractor reflecting the amount of changes they expected to apply during implementation. Numbers of interest to the client are the summation of weights per category of change expected (figure 4.) We suggest the following metrics:

• TS: Total Standards
• TCF: Total Configurations
• TCZ: Total Customizations
• TTPI: Total Third Party Integrations
• TCSC: Total Change Source Code

Table 3: A Snapshot of KAU BPs matched with SAP Business Processes
KAU Business Processes	SAP Standard Business Processes
1. Procurement Business Processes
1.1. Purchase Requistion
Create Purchase Requisition (PR)	Create Purchase Requsition (PR)
Budget & Planning Dept. Approval or Self Finance Approval	Define approval strategy/wprkflow
Dept. Manager or Dean approval	Define approval strategy/wprkflow
1.2. Quotation Process
Create Request for Quotation (RFQ)	Create Request for Quotation (RFQ)
Get response from supplier	Supplier can respond by email or through the system (Maintain Quotation)
Quotation Selection Process	Online selection
Get approval from committee	Get approval from manager (Can define more than approval)
1.3. Purchase Order Process
Cretae Purchase Order	Cretae Purchase Order
Get approval	Define approval strategy/wprkflow
1.4. Bid Process
Create Bid	Create Bid
Supplier Repsonce	Supplier Participation
Bid Opening Process	Techniocal Envelop Evaluation
Technical Evaluation for Bid	Commecial Envelop Evaluation
Bid slection process	Bid selection/rejection

 

Table 4: Analysis of KAU/SAP processes to reflect expected change per BP
KAU Business Processes	Contract Response
	SAP Standard	Work Requirement
3. Invoice
Enter Invoice	Create and Post Invoice	S
E-Invoice	E-Invoice	CF
4. Vendor Registration
Register new vendor by KAU	Suplier Registration	CZ
Maintain/Update Vendor Data By KAU	Maintain Suuplier	CZ
Register/Maintain/Update Vendor Data By Vendor using online services	Online Registration	CZ
5. Material Master
Create/Change Material Matser	Create/Change Material Matser	CZ
Create/Change Material Matser	Create/Change Material Matser (Material Type)	CF
6. Login (Technical Requirement)
Singlr Sign-In	N/A	TPI

 

Table 5: Weight assignment to symbolic qualifiers
KAU Business Processes	Contract Response		Weight
	SAP Standard	Work Requirement
3. Invoice
Enter Invoice	Create and Post Invoice	S	1
E-Invoice	E-Invoice	CF	2
4. Vendor Registration
Register new vendor by KAU	New Vendor Master	CZ	6
Maintain/Update Vendor Data By KAU	Update Vendor Master	CZ	4
Register/Maintain/Update Vendor Data By Vendor using online services	Supplier Online Registration	CZ	6
5. Material Master
Create/Change Material Matser	Create/Change Material Matser	CF	2
Block Material	Block Material Matser	S	1
Delete Material	Delete Material Matser	S	1

In the example given above the final estimated relative effort of the change is: TS = 3, TCF = 4, TCZ = 16, TTPI = 10, and TCSC = 0. Hence, it is expected that major change effort will be dedicated to customizing the implementation, while no code change will be required. TTPI value indicates that this slice of the project needs a moderate effort to adapt parts of the system during implementation to integrate with a functionality provided via a third party. Values for TSs and TCFs show the numbers for expected effort of change required, and this example they represent a minor concern.

Step 5

The matrix analysis provides an insight into the relative amount of work each bidder’s proposal will take. So it is easy to see which proposals are better as each ERP BP is analyzed to understand how much it requires change to comply with the organization’s BP. This provides a sense of how much work will be involved implementing each business process. A discussion should ensue as to what requirements expectations might be changed based upon the amount of work for each requires. For example, if a process can be modified so it is a configuration rather than a change source code, there would be a great saving. This discussion will be carried out in collaboration with the process owners (POs) and they are able to see the cost of sticking to a particular as-is process. This might convince them to be more flexible in their requirements.

Step 6

Based upon the analysis, the bidder requiring the minimum amount of effort would most likely be selected as the winner. However, how the bidder selected and characterized the particular changes should be considered in terms of what it says about the quality of the bidder.

Figure 4: Metrics for total expected change per category

 

 

 

 

 

 

 

Conslusion

The proposed approach aims at addressing the challenges of contracting out for an ERP system. It focusses on the need to begin learning about what is needed by the client and what is available from the ERP vendor and the contractor before choosing a contractor and beginning the implementation. The requirements document provides information about the as-is business processes and insights about the perceived flexibility for change and saves this information in the evaluation matrix. The matrix as filled in by the contractor offers insights into the level of effort required to implement each process, paving the way for negotiation before the contract is let. It gives the option to the client of motivating minor and even major changes in business processes by recognizing the value/cost relationship for implementing various processes as-is or modified. Early preparation helps the client understand what As-Is business processes are important to re-evaluate or reengineer to minimize the customization.

It provides a basis for comparison of the various proposals with respect to relative effort estimation and an understanding of how the effort is distributed. It minimizes the risks that might show up during implementation and provides a way to understand what trade-offs are possible.

The weaknesses are that the client has to be willing to spend the effort up-front and do a great deal of learning about themselves, the vendor, and the contractor. It requires the early commitment of top level management to take responsibility for understanding the effect of the change on the organization as a whole, getting involved with process owner to help make the compromise when there is a need for change, and empowering the project manager to make the changes when they are beneficial. For example, top level management is needed when a process owner is unwilling to accept a change that lessens the cost or improves the overall integration
process.

This method has been derived based upon the analysis of experience with the implementation of an ERP system. We have applied it to a subset of the organization business process as a pilot to check the feasibility and usability of the method. We plan to extend this method so that it covers other factors that we view as important to the success of ERP implementation projects. For example, enterprise data readiness, team competency, alignment of ERP enterprise goals, and change management requirements.

Acknowledgments

This project was funded by the Deanship of Scientific Research (DSR), King Abdulaziz University, Jeddah, Saudi Arabia. The authors acknowledge and extend their gratitude towards DSR for its technical and financial support.

References

1. K. M. Lui and K. C. C. Chan, “Rescuing troubled software projects by team transformation: A case study with an ERP project,” IEEE Trans. Eng. Manage., vol. 55, no. 1, pp. 171–184, Feb. 2008.
2.  http://www.kau.edu.sa/Pages-Our-History.aspx
3. Jun Xu and Mohammed Quaddus, “Using Information Systems for Enhancing Internal Operation: Enterprise Resource Planning Systems”, Chapter 7, DOI: 10.2991/978-94-91216-89-3_7. Atlantis Press 2013
4. De Soysa, S., and J. Nanayakkara. “Readiness for ERP Implementation in an Organization: Development of an Assessment Model.” Information and Automation, 2006. ICIA 2006. International Conference on. IEEE, 2006.
5. Sammon, David. “Towards a model for evaluating organisational readiness for ERP and data warehousing projects.” (2004).
6. Adnan Al Bar, Victor Basili, Wajdi Al Jedaibi, Abdul Jawad Chaudhry, An Analysis of the Contracting Process for an ERP system, SEAS-2013, Computer Science Conference Proceedings in Computer Science & Information Technology (CS & IT) series, Dubai, UAE, November 2-3, 2013.
7. Tanya Bondarouk & Maarten van Riemsdijk, “Successes and failures of SAP Implementation: A learning Perspective”, International Journal of Technology and Human Interaction, Volume 3, Issue 4, 2007.
8. Derek S. Dieringer, “ERP Implementation at Nestlé”, [online] available at: http://www.uwosh.edu/faculty_staff/wresch/ERPNestlé.htm June 24, 2004.
9. Kristi I. Wenrich & Norita Ahmad,” Lessons Learned During a Decade of ERP Experience: A Case Study” International Journal of Enterprise Information Systems, Volume 5, Issue 1, 2009.
10. Lykkegaard & Jsozef Gemela, “SAP In The Mid – Sized Enterprise: Lessons Learned In Europe and Africa”, International Data Corporation (IDC), January 2009.
11. Bob Lewis, “Six lessons from a lightning ERP rollout”, InfoWorld, November 2011.
12. Hong, Kyung-Kwon, and Young-Gul Kim. “The critical success factors for ERP implementation: an organizational fit perspective”Information & Management 1 (2002): 25-40.
13. Adnan Al Bar, Victor Basili, Wajdi Al Jedaibi, Abdul Jawad Chaudhry, An Experience-Based Evaluation Process for ERP Bids, Advanced Computing International Journal (ACIJ), Vol. 5, No. 1, January 2014.
    1. R. Basili,, “Learning through Applications: The Maturing of the QIP in the SEL”,in Making Software, Andy Oram and Greg Wilson, eds., O’Reilly, 2011.