Subscribe Now Subscribe Today
Research Article
 

ERP Software Selection using Fuzzy Methodology: A Case Study



B. Kutlu and E. Akpinar
 
Facebook Twitter Digg Reddit Linkedin StumbleUpon E-mail
ABSTRACT

In this study, it is aimed to illustrate that fuzzy logic can be used for selecting Enterprise Resource Planning (ERP) software for a liner shipping company. For this purpose, a shipping company in Turkey is selected as a case study. Traditional software evaluation techniques such as request for information/request for proposal and scripted scenario approaches are investigated together with fuzzy logic for this case. The results indicated that traditional techniques are necessary but not sufficient for ERP software evaluation in shipping industry and fuzzy methodology can also be used effectively.

Services
Related Articles in ASCI
Similar Articles in this Journal
Search in Google Scholar
View Citation
Report Citation

 
  How to cite this article:

B. Kutlu and E. Akpinar, 2009. ERP Software Selection using Fuzzy Methodology: A Case Study. Journal of Applied Sciences, 9: 3378-3384.

DOI: 10.3923/jas.2009.3378.3384

URL: https://scialert.net/abstract/?doi=jas.2009.3378.3384
 

INTRODUCTION

Packaged information systems and Enterprise Resource Planning (ERP) systems integrate information and processes of organizations. The acquisition of information system and software can be motivated by the need for a new information technology or changing the existing one, both may be aiming to reduce costs, support current way of doing business (Hecht, 1997), or to facilitate change in the ways of doing business and thus, to improve effectiveness or to gain strategic advantage (Silk, 1990; Fitzgerald, 1998). Large investments of money, time and expertise are required to configure and customize these generic software packages to the specific needs of organizations, sectors or countries (Davenport, 1998; Klaus et al., 2000). Another important problem of customization is the incompatibility of the customized version with the organization’s functions and systems (Butler, 1999; Kremers and Dissel, 2000; Sumner, 2000; Light et al., 2001). Some organizations choose to adapt the generic software without customization and change their processes accordingly (Klaus et al., 2000; Kumar and Hillegersberg, 2000; Bernroider and Koch, 2001; Everdingen et al., 2000), while others try to select the best fit software with minimum cost and minimum amount of customization (Light et al., 2001; Davison, 2002; Soh et al., 2000).

The main intend of software selection and/or evaluation is to identify the best alternative for the organization’s requirements. Most enterprises have critical processes that uniquely define the power that makes an organization successful. These critical processes should become critical requirements during a software selection process. If the software vendor fails to meet these critical requirements, they become fatal flaws that will adversely affect the implementation (O’ Connor, 2008).

Traditional software selection relies on a long list of functional requirements (sometimes in the range of thousands) that identify the vendors with the best functional fit (Verville and Halingten, 2003). Most enterprise applications are purchased after a process of investigation, piloting and comparison using Request For Information (RFI) and/or Request for Proposal (RFP) documents together with vendor demonstrations to evaluate the software technically and financially (Tatsiopoulos and Mekras, 1999; Ziaee et al., 2006).

These evaluation techniques are becoming increasingly inadequate for complex integrated systems. Enterprises can instead use a hybrid approach called scripted scenarios, as an alternative method for vendor selection (Peterson, 2003). A scripted scenario describes a unique problem that an enterprise wants to be resolved and give project teams an opportunity to express their vision for the business environment with the use of new software (Peterson, 2003). Scripted scenarios are valuable tools but they are not the only ones in the overall software evaluation process (Lin et al., 2006; Wu et al., 2007). It is the best to use them together with RFIs and RFPs and take into account the results of site visits, other reference checks and performance benchmarks.

Application vendors continue to support the rule of thumb that a 75 to 80% fit between business requirements and available functionality is good enough.

Fig. 1: Member functions for software acceptability

In order to increase this ratio and make a better selection new approaches are required such as fuzzy logic or neural networks.

Real world is vague and assigning rigid values to linguistic variables means that some of the meaning and semantic value is invariably lost. Fuzzy logic that is emerged from the development of fuzzy sets theory by Zadeh (1965), operates on a concept of membership such as the statement Software-X is acceptable and can be translated as Software-X is a member of the set of acceptable software and can be written symbolically as m (SOFTWARE ACCEPTABILITY), where m is the membership function that can return a value between 0 and 1 depending on the degree of membership.

Figure 1 shows, the membership function for the objective term (SOFTWARE ACCEPTABILITY) which has fuzzy sets Anot acceptable, Aindecisive and Acceptable. In this case when the score is 25 or below the software is not acceptable, when it is 75 or above it is acceptable. For values between 25 and 50 it is either Aindecisive but close to not acceptable where for values between 50 and 75 it is Aindecisive but close to acceptable.

The fuzzy set theory attempts to follow more closely the vagueness that is inherent in most natural language and in decision-making processes. Therefore, fuzzy logic has found many real-world applications that involve imitating or modeling human behavior for decision-making in the real world. Gungor Sen and Baracli (2006), specified in their study that decision making strategies such as fuzzy methods are becoming to be more and more important and will be better tools for appropriate ERP software selection. Xu et al. (2007) has applied fuzzy methodology successfully for ERP software selection of small and medium enterprises.

Shipping industry is one of the sectors that have limited number of related software producers with software already customized for their own customers. Traditional software evaluation techniques are not adequate for this industry. Most of the shipping companies use in-house developed software which is ineffectual. The aim of this study is to show that fuzzy logic can be used effectively for ERP software selection of shipping companies.

MATERIALS AND METHODS

The company that is considered as the real case application, is a medium-sized liner shipping company in Istanbul, Turkey, which is experiencing difficulties and delays in reviewing, approving, controlling and reporting operations between Head Office and Agencies due to processes that were overburdened with manual tasks, e-mail based workflow and lack of process information. Therefore, the company is in need of an information system to increase its effectiveness.

The company was established in 1996 within another company as a distinct, autonomous entity in order to accomplish the first national-flagged container transportation in the country. Company’s philosophy is to provide the best service with a workforce that is expert in their field. It provides services with 18 of its own ships and with 62 years of experience in transportation.

Company has a total of 5 departments: container movement control department, operations department, trade department, line management department and foreign accounts department. These departments will be used for determination of critical processes.

Mainly, AS 400 system is used at Head Office and agencies. Some patch programs are prepared to solve problems like special freight rate approval or free time extension for ports but these were not effective because of AS 400 database. Eighty percent of work is done manually. Agencies send fax or e-mail to inform the Head Office about operations they perform. Head Office users enter all data into current system as much as possible. Delays and errors occur frequently in stored data. There are a lot of paperwork and double entry to different software. Reports are prepared manually after a time consuming effort. Variety and correctness of the reports are very poor. Controlling agency operations are sometimes impossible. Company profitability calculations, line management, container control, ship husbandry, disbursement accounting can not be made efficiently with the current system.

A program that supports operations between Head Office and agencies as well as between agencies and customers is desired. Agencies should contribute to the system through internet, connect to the main server and perform authorized operations. In this way, the data will be entered only once. Container movements should be monitored on a daily basis. Line profitability, costs and revenues per voyage, per container and per port should be correctly calculated. Disbursement accounting between agencies and Head Office should be established. Customer relationship management should be supported. Several types of reports should be generated.

Goals of the new system can be summarized as:

Time saving
Real time information and provision of estimates
Cost reduction
Paperwork reduction
Less transactions and less errors with automated processes
Control on agents, equipments and vessels
Managing disbursement accounting
Allowing managers to concentrate on strategic tasks and future of business
Efficient documentation

There are only 3 major information system software vendor companies in shipping software business. The products of these companies have many differences in details and workflows. For this reason it is hard to evaluate the performances of these companies with traditional approaches. This study will combine RFIs and RFPs together with scripted scenarios. Subsequently, fuzzy logic will be used as decision aid in order to find the optimum software package.

The ERP software selection project started in March 2005 and ended in December 2006. The project is performed in 5 steps:

Project teams’ preparation
Preliminary RFI preparation
Scripted scenario and RFI development
Scoring of RFIs
Fuzzy evaluation

Project team is formed by including members from all departments as studies by Verville and Halingten (2003) and Wu et al. (2007) had suggested. In order to speed up the documentation process the team is divided into two: (1) Head Office Information Technology (IT) team and (2) Office team including members from. Daily meetings are performed for the preparation of RFI/RFP, scenario and scenario evaluation documents. These meetings proved that communications of departments were very poor. Every single Office team member prepared a requirements list for their own department. The requirements definition consisted of functional requirements, managerial requirements and technical requirements (Nikolaos et al., 2005; Van Staaden and Lubbe, 2006). Head Office IT team combined the requirements into 16 operational groups and prepared an RFI document for distribution to shipping software vendors. Questions in each operational group can furthermore be grouped as follows:

Functional: These questions referred to the business needs of the company based on specific operations of shipping industry. For vessel operations questions as ADoes the system allow multiple vessel details to be captured or Does the system hold port profiles of all seaports around the world? were added.

Managerial: This group consisted of questions related managerial needs of the company including financial and sales/marketing issues. Questions generated were associated with the reporting issues of management such as statistical reports, exception reports, agent performances and other performance metrics. Financial questions included invoice related topics as well as budgeting, exchange rates, transfer rates, freight charges, banker guarantees, cash and check receipts, etc. Sales and marketing questions are related to the information kept for customer profile, sales contact management, customer complaint handling, etc.

Technical: This group of questions dealt with type of reports (screen, print or file), internal and external information updates, data verification, information dissemination techniques (e-mail, fax, etc.), security, user rights and logging issues, other technical issues such as use of barcodes on forms, etc.

Scenarios are prepared with the help of Head Office IT team only for the critical processes of 5 departments as Wu et al. (2007) had suggested. An example is a quotation scenario for trade department including customer detail information, shipment type and corridor details, commodity and container details, route information, charges, detention and demurrage, development of processes for quotation closing, approval and finalization as well as booking from different resources (e.g., quotation, guideline or contract). A second RFI is prepared to evaluate vendor demonstrations of scripted scenarios. This RFI is prepared with the aid of Head Office IT team. In this phase questions are prepared to be more detailed and answer classifications are prepared differently to evaluate the degree of accomplishment. Questions are classified into two sections: (a) functional requirements and (b) reporting needs.

Table 1: RFI answer weights and meanings

RFI’s can be assessed by scoring of expected performance of an option and its relative importance to the decision (Nikolaos et al., 2005). The scoring of preliminary RFI is performed by question weights (defined at Office team meetings showing relative importance) and answer weights (defined at Head Office IT team meetings showing expected performance). Question weights used a 3-point scale; 1 being essential, 0.8 being desirable and 0.5 being nice to have (Axia, 2009). Answer weights are given in Table 1. At the end of the evaluation, question weights are multiplied by answer weights and then summed to form the total score of the vendor. There were total of 597 questions with a maximum score of 5789.

Scenario Demonstrations RFI consisted of two sections; functional and reporting needs. The question and answer weights are determined at Office team and Head Office IT team meetings (Axia, 2009). Question weights of every functional item are specified as 1 and every reporting item as 0.5. Answer weights of functional items are specified as 0 for Not Available, 3 for Modification Needed, 8 for Customization Needed and 10 for Available. Answer weights of reporting items are specified as 0 for Not Available, 1 for Modification Needed, 4 for Customization Needed and 5 for Available. At the end of the evaluation, question weights are multiplied by answer weights and then summed to form the total score of the vendor. There were 133 questions in this section with a maximum total score of 1215.

Lien and Liang (2005) stated in their study that there are three main factors in ERP software selection: cost, development time and performance. They have specified that cost is the most important factor and development time is the second important factor. For this reason, total RFI score, which is the indicator of performance, is used as input to fuzzy engine together with purchase cost and development time. Development time is retrieved from RFIs. Purchase costs are considered for 100 user licenses.

Membership functions for Purchase Cost are specified in the range of $20,000 to $45,000 (Fig. 2). This range is specified according to the prices of major ERP software packages on the market. Values greater than $40,000 indicate that the software is expensive. Values less than $25,000 indicate that the software is cheap. Values between $25,000 and $32,500 are classified as normal-cheap where values between $32,500 and $40,000 are classified as normal-expensive.

Fig. 2: Membership functions for purchase cost

Fig. 3: Membership functions for development time

Membership functions for Development Time are specified in the range of 50 to 350 days (Fig. 3). This range is specified according to the prices of major ERP software packages on the market. Values greater than 300 days indicate that the development time is long. Values less than 100 days indicate that the development time is short. Values between 100 and 200 are classified as medium-short where values between 200 and 300 are classified as medium-long.

Membership functions for RFI Score are specified by the team members in the range of 4500 to 7000 (Fig. 4) where 4500 being the minimum acceptable and 7000 being the maximum score. Values greater than 6200 indicate that the RFI score is high. Values less than 4700 indicate that the RFI score is low. Values between 4700 and 5500 are classified as average-low where values between 5500 and 6200 are classified as average-high.

Fuzzy rules are prepared by IT specialists according to the company needs, project duration constraints and the project budget. An example rule can be given as:

If (RFI score is high) and (development time is medium) then (output is excellent) (0.4).

MATLAB Fuzzy Toolbox is used for evaluations. Membership functions for the output compatibility is specified in the range of 0 to 100 (Fig. 5). Values less than 20 indicate that the compatibility is bad. Values greater than 90 indicate that compatibility is excellent. Values between 20 and 40 are classified as poor-bad, values between 40 and 60 are classified as good-poor, values between 60 and 75 are classified as very good-good, values between 75 and 90 are classified as excellent-very good.

Fig. 4: Membership functions for RFI score

Fig. 5: Membership functions for compatibility

RESULTS AND DISCUSSION

In the real case application, software selection process started with RFI scoring. Table 2 shows the preliminary RFI scores. According to these scores best candidates are Company A and Company B.

Table 3 shows the demonstration RFI scores. There is no clear distinction for the scores of all companies which are in the range of 84 to 87%.

According to total RFI scores of the companies, Company A is in the high score range with the value of 6,209. Both Company B and Company C are in average-high range with scores of 5,996 and 5,763, respectively.

Using results of traditional methods organization decided to buy the software from Company A and tried to implement it for a duration of 3 months. In the mean time the study is extended to incorporate fuzzy methods. Table 4 gives the input values of the fuzzy engine together with the results of the fuzzy evaluation.

The development time input pointed out that Company B can be a candidate with short development time and Company C can be the other candidate with low Purchase Cost. With the use of fuzzy methodology it was possible to categorize the companies distinctively. Company B is the best choice with the compatibility range of excellent-very good. Company A was in the range of very good-good where Company C was in the range of good-poor. The implementation is then further reviewed and found out that there was a popular discontent. The organization then decided to stop the first implementation which was not proceeding successfully and decided to switch to the software of Company B. The implementation of this software was successful and the software is running effectively since May 2008.

Table 2: Preliminary RFI scores

Table 3: Demonstration RFI scores

Table 4: Inputs and outputs of the fuzzy engine

This study is aimed at finding a fuzzy based model for ERP software selection of a liner shipping company. For this purpose; two project teams are formed, preliminary RFIs are prepared according to departmental requirements, scripted scenarios are prepared for the critical processes of the organization and results are evaluated by fuzzy methodology.

Based on the results it can be concluded that:

Traditional software evaluation methods, such as RFI scoring or scripted scenarios, are not sufficient for ERP software selection. This result differs from the studies of Lin et al. (2006) and Wu et al. (2007). This may be due to the fact that even though the software seems to have appropriate functionality for the organization, key issues such as development time and purchase cost can affect the final decision (Lien and Liang, 2005)
Fuzzy methodology is a better tool for ERP software selection. This result is in support of the study of Gungor Sen and Baracli (2006)
ERP software selection with fuzzy methodology can be used effectively for shipping industry. Xu et al. (2007) have specified that fuzzy methodology can be applied successfully for ERP software selection of small and medium enterprises

However, the proposed model is not without its limitations. It is limited to the findings of only one sector; therefore it can not be generalized. But the development of a general reference model can be a fruitful area for further study. Vendor site visits, vendors’earlier projects, number of successful projects, evaluation of companies that are currently using vendor software can be other factors that can affect the results and they may need to be further explored.

REFERENCES
1:  Axia, C., 2009. Rating Criteria for RFP. http://www.axia-consulting.co.uk/html/rating_criteria_for_rfp.html.

2:  Bernroider, E. and S. Koch, 2001. ERP selection process in midsize and large organizations. Bus. Process Manage. J., 7: 251-257.
CrossRef  |  

3:  Butler, J., 1999. Risk management skills needed in packaged software environment. Inform. Syst. Manage., 16: 15-20.

4:  Davenport, T.H., 1998. Putting the enterprise into the enterprise system. Harvard Bus. Rev., 76: 121-131.
Direct Link  |  

5:  Davison, R., 2002. Cultural complications of ERP. Commun. ACM, 45: 109-111.
Direct Link  |  

6:  Everdingen, Y.J., J. Hillegersberg and E. Waarts, 2000. ERP adoption by European midsize companies. Commun. ACM, 43: 27-31.
Direct Link  |  

7:  Fitzgerald, G., 1998. Evaluating information systems projects: A multidimensional approach. J. Inform. Technol., 13: 15-27.

8:  Gungor Sen, C. and H. Baracli, 2006. A brief literature review of enterprise software evaluation and selection methodologies: A comparison in the context of decision-making methods. Proceedings of the 5th International Symposium on Intelligent Manufacturing Systems, May 29-31, 2006, Department of Industrial Engineering, pp: 874-883.

9:  Hecht, B., 1997. Choose the right ERP software. Datamation, 43: 56-58.

10:  Klaus, H., M. Rosemann and G.G. Gable, 2000. What is ERP? Inform. Syst. Frontiers, 2: 141-162.
Direct Link  |  

11:  Kremers, M. and H. Dissel, 2000. ERP system migrations - a provider's versus a customer's perspective. Commun. ACM, 43: 53-56.

12:  Kumar, K. and J.V. Hillegersberg, 2000. Enterprise resource planning: Introduction. Commun. ACM, 43: 22-26.
Direct Link  |  

13:  Light, B., C.P. Holland and K. Wills, 2001. ERP and best of breed: A comparative analysis. Bus. Process Manage. J., 7: 216-224.
Direct Link  |  

14:  Lien, C. and S. Liang, 2005. An ERP system selection model with project management viewpoint a fuzzy multi-criteria decision-making approach. Int. J. Inform. Syst. Logistics Manage., 1: 39-46.
Direct Link  |  

15:  Lin, H., A. Lai, R. Ullrich, M. Kuca and J. Shaffer-Gant et al., 2006. COTS software selection process. Proceedings of the 6th International IEEE Conference on Commercial-off-the-Shelf (COTS)-Based Software Systems, February 26-March 2, 2006, IEEE Computer Society, pp: 114-122.

16:  Nikolaos, P., G. Sotiris, D. Harris and V. Nikolaos, 2005. An application of multicriteria analysis for ERP software selection in a Greek industrial company. Operat. Res., 5: 435-458.
CrossRef  |  

17:  O`Connor, S.C., 2008. Choosing the Right Enterprise Resource Planning (ERP) System: How to Avoid the 7 Fatal Flaws. Technology Research Library, Asia.

18:  Peterson, K., 2003. Scripted Scenarios Improve the Software Selection Process. Gardner Research Note, USA.

19:  Silk, D.J., 1990. Managing IS benefits for the 1990s. J. Inform. Technol., 5: 185-193.

20:  Soh, C., S.S. Kien and J. Tay-Yap, 2000. Enterprise resource planning: Cultural fits and misfits: Is ERP a universal solution? Commun. ACM, 43: 47-51.
Direct Link  |  

21:  Sumner, M., 2000. Risk factors in enterprise-wide/ERP projects. J. Inform. Technol., 15: 317-327.
CrossRef  |  

22:  Tatsiopoulos, I.P. and N.D. Mekras, 1999. An expert system for selection of production planning and control software packages. Prod. Plann. Contr., 10: 414-425.

23:  Verville, J. and A. Halingten, 2003. A six-stage model of the buying process for ERP software. Indust. Market. Manage., 32: 585-594.
CrossRef  |  

24:  Wu, J.H., S.S. Shin and M.S.H. Heng, 2007. A methodology for ERP misfit analysis. Inform. Manage., 44: 666-680.
CrossRef  |  

25:  Xu, X., Y. Jiang and Z. Shi, 2007. Implementation evaluation modeling of selecting ERP software based on fuzzy theory. Res. Practical Issues Enterprise Inform. Syst., 254: 727-737.
Direct Link  |  

26:  Zadeh, L.A., 1965. Fuzzy sets. Inform. Control, 8: 338-353.
CrossRef  |  Direct Link  |  

27:  Ziaee, M., M. Fathian and S.J. Sadjadi, 2006. A modular approach to ERP system selection: A case study. Inform. Manage. Comput. Secur., 14: 485-495.
CrossRef  |  

28:  Van Staaden, P. and S. Lubbe, 2006. A case study on the selection and evaluation of software for an internet organisation. The Elect. J. Bus. Res. Methods, 4: 57-66.

©  2021 Science Alert. All Rights Reserved