Академический Документы
Профессиональный Документы
Культура Документы
Department of Industrial Engineering, Yildiz Technical University, Yildiz, Istanbul 34349, Turkey
Production Department, Audio Electronics, Umraniye, Istanbul 81260, Turkey
a r t i c l e
i n f o
Keywords:
Enterprise software selection
Qualitative and quantitative objectives
Fuzzy multi-criteria decision making
procedure
Multi-objective programming
ERP
a b s t r a c t
Previous methods for enterprise software selection generally take into account the attributes that are
restricted to some nancial factors, such as costs and benets. However, the literature lacks studies on
considering the evaluation of both functional and non-functional suitability of software alternatives versus various requirements. This study presents a new decision support system for combining these two
kinds of evaluation to select suitable enterprise software. A hierarchical objective structure that contains
both qualitative and quantitative objectives is proposed to evaluate software products systematically.
This approach uses a heuristic algorithm, a fuzzy multi-criteria decision making procedure and a multiobjective programming model to make nal selection decision. All the phases of presented method are
applied in an electronic companys ERP software selection project to validate it with a real application.
The satisfactory results are obtained during this project. The company can select the right software to
t its business processes instead of adapting its business processes to t the software.
2008 Elsevier Ltd. All rights reserved.
1. Introduction
Severe market competition has dramatically transformed the
business environment with the result that companies need to reduce total costs, maximize return on investment, shorten lead
times, and be more responsive to customer demands. Highly dynamic markets call for effective enterprise software systems to enhance competitive advantage (Wei, Chien, & Wang, 2005).
Organizations have several options for acquiring business software
applications. Acquisition through development includes development by an internal IT group or custom development by third parties. Alternatively, organizations may acquire software through the
purchase of pre-developed congurable systems from software
vendors. Over time this approach has become the dominant means
of software acquisition, accounting for approximately 70% of corporate business software expenditures (Holland & Light, 1999).
Due to the growth in specialized software companies, coupled with
diverse skill requirements, and rapidly changing technology, organizations are increasingly purchasing enterprise software packages
instead of custom developing their own software applications
(Sherer, 1993). Enterprise software packages are pre-written by a
vendor to provide a set of standard functions usable by a wide variety of companies, regardless of size or industry. Commercial off the
* Corresponding author. Tel.: +90 212 3832873; fax: +90 212 2585928.
E-mail address: cgungor@yildiz.edu.tr (C.G. S
en).
0957-4174/$ - see front matter 2008 Elsevier Ltd. All rights reserved.
doi:10.1016/j.eswa.2008.06.070
5273
5274
ESSM and the criteria used for the evaluation process. To clearly
present the proposed ESSM, a stepwise procedure is described.
Fig. 2 shows the proposed enterprise software selection procedure.
2.1. Form a project team and conduct BPR
Software selection process affects several functions in the organization; therefore, such a decision should be made according to
the consensus of a cross-functional team of decision makers with
various points of views and who represent different services of
the company. Hence, the rst step of our approach is to form a
team that consists of all related managers and supervisors of a
company, such as a general manager, production manager, quality
manager, IT manager and R&D manager. In essence, an enterprise
software project involves not only installing a new information
technology system to replace the legacy system, but also reshaping
the business processes to overcome the challenges of a dynamic
market (Wei & Wang, 2004). The software package requires not
only integration with existing systems, but also some customization to the idiosyncratic business processes of the adopting organization. The project team can develop the functional requirements
of enterprise software during the business process reengineering
(BPR), and then incorporate these characteristics appropriately into
the decision model. Therefore, it is necessary to undertake to BPR
to rationalize and standardize the workows of all business processes in advance.
2.2. Identify the criteria for enterprise software selection
A requirements analysis of a software system is often considered to be one of the most crucial steps in the software acquisition
process (Liu, 1998), in which statements describing the functions
and characteristics of the forthcoming software system should be
developed and agreed upon. In order to achieve high user-satisfaction and high feasibility, the software requirements should be carefully specied and analyzed. The software requirements are
divided into two separate categories: functional and non-functional
(Karlsson, 1997). In this step, project team decomposes both functional and non-functional requirements into a hierarchical criteria
set.
The functional requirements are the core of the statement,
describing the functions of the software system that are expected
by the stakeholders. Functional requirements typically describe
the relationships between all valid (and invalid) inputs to the software system and the corresponding outputs of the software system. Our framework relies on user-dened functional
requirements instead of a short-list of evaluator-generated criteria
to determine product suitability. The cross-functional team can
easily gather the basic functional requirements during the BPR
analysis. These requirements may be represented in a list of process and business related functions, scenarios or use-cases, and
should include essential user requirements and standards. In some
organizations, comprehensive market research is called for, indepth interviews with users are carried out, and current versions
of software systems are analyzed. Such basic requirements are often both vague and non-veriable. Hence, we propose to expand
these primary requirements into secondary and tertiary, more detailed requirements.
In many software acquisition methods functional requirements
are resolved, but non-functional requirements (NFRs) are more or
less deliberately put aside (Karlsson, 1997). Representing and
modelling NFRs such as usability or reliability may be less straightforward, since such requirements are often inherently problematic.
Traditionally, features of a system that are not covered by its
functional description have been called non-functional requirements
(NFRs) (Bosch & Molin, 1999; Buschmann, Meunier, Rohnet,
5275
5276
8
>
< x l=m l; l 6 x 6 m;
lM~ x u x=u m; m 6 x 6 u;
>
:
otherwise:
0;
In this study, the importance weight of each functional and nonfunctional criteria, and the rating values of software alternatives versus non-functional criteria are considered as linguistic terms, LVk
(k 1; 2; . . . ; K), such as very strong, strong, medium, weak and none
(LV1 = very strong-VS, LV2 = strong-S, LV3 = medium-M, LV4 = weakW, LV5 = none-N). These linguistic terms can be expressed via triangular fuzzy numbers as shown in Table 1. The membership functions
of the ve linguistic values are shown in Fig. 4.
Using the fuzzy representation to quantify a human response
requires a defuzzication process. Defuzzication is dened as
the mapping of a fuzzy set F to elements of the universe considered
signicant with respect to F (Yager & Filev, 1994). There are a lot of
well known techniques in transforming a fuzzy set to a crisp deterministic value (Roychowdhury & Pedrycz, 2001). In this paper, a
defuzzication operator, namely, RAGE (RAndom GEneration),
which performs a random experiment to select the element is
used. The reason for using this procedure is that it is easy for the
decision makers to use and calculate. The RAGE method treats
the membership function as a probability distribution and uses a
random experiment to generate a crisp deterministic value within
the domain of the linguistic response.
Consider a fuzzy decision D which is a fuzzy subset of {d1, . . . ,dk}
with a membership function lD : fd1 ; . . . ; dk g ! 0; 1: An operator
R
Defuzz : Ffd1 ; . . . ; dk g ! fd1 ; . . . ; dk g is called the randomized
defuzzication operator for the fuzzy decision D if
R
Defuzz D dj ;
Membership function
Domain
Triangular (l, m, u)
Very strong
Strong
7.5 6 x 6 10.0
5.0 6 x 6 7.5
7.5 6 x 6 10.0
2.5 6 x 6 5.0
5.0 6 x 6 7.5
0 6 x 6 2.5
2.5 6 x 6 5.0
0 6 x 6 2.5
Medium
Weak
None
lD di
; i 1; . . . ; I:
i1 lD di
Pdi pi PI
2. Divide the unit interval into n intervals, one for each element di
of the fuzzy decision D. Denote these intervals:
Ri ai ; bi i 1; . . . ; n:
a1 0
b1 P1 ;
ai bi1
bi ai Pi :
wi
M
X
Defuzz LV m
8i;
k
m1
wij
M
X
Defuzz LV m
8i and j;
k
m1
R
where Defuzz LV m
k is the outcome of the random experiment from
the appropriate membership function for linguistic variable LVk that
wi
Nwi PI
wij
Nwij Pni
i1 wij
i1 wi
5277
2, . . . ,S) are assigned by using the same scale. The reason for using
a numerical scale instead of fuzzy set theory is that the fulllment
for functional requirements is not relative. It is easy for decision
makers to reach consensus on the breadth of coverage of a functional requirement like the system must be able to print out invoices for an alternative.
Thereafter, the heuristic algorithm is performed as depicted in
Fig. 5. This algorithm allows comparing psijks to eijks and determining the functional suitability score of s. alternative (fsijk) for each
tertiary system requirement. By applying this algorithm, functional
suitability score for each secondary (fsij) and primary (fsi) system
requirement, and the overall functional suitability score of s. alternative are also obtained. This algorithm produces the scores varying in the range of [0, 1].
Beginning of this step, an acceptable level of functional coverage, f (f e [0, 1]), which indicates the degree of optimism of the
decision makers, has to be determined. A larger f represents a lesser degree of optimism. Software alternatives with the functional
5278
suitability score that is higher than or equal to f are selected for the
detailed evaluation. In other words, meeting at least f percent of
system requirements is enough to purchase an enterprise software
for this organization. On the other hand, if no product meets an
acceptable level of functional coverage, f, as determined by the
decision makers, building a custom-designed application is the
only way to meet specic system requirements. In this case, the required capabilities must rely on custom development rather than
purchasing a packaged product. Consequently, this step of our proposed method supports the organizations build or buy decision.
2.4.2. Perform non-functional suitability analysis
In non-functional suitability analysis, team members rate nonfunctional criteria determined in Section 2.2 to indicate how well
each product performs. The importance weights of non-functional
criteria are similarly computed like the importance weight of functional requirements. It is dened w0i as the weight of main nonfunctional criteria ci (i = 1, 2, 3); w0ij the weight of sub-criteria cij
(j = 1, 2, . . . , n(i)), and w0ijk the weight of sub-criteria cijk (k = 1,
2, . . . ,n(j)). The terms differ from those used to describe the importance weight of the functional requirements; however, the computation strategy is identical. Finally the normalized weights of
criteria, Nw0i , Nw0ij , Nw0ijk , are calculated by using following
equations:
w0
Nw0i P3 i
10
0
i1 wi
0
wij
Nw0ij Pni ;
0
i1 wij
0
wijk
Nw0ijk Pnj
0
i1 wijk
11
12
Thereafter, the product ratings under the lowest level criteria on the
hierarchical structure are computed by using the same linguistic
variables and defuzzication procedure. Dene Rsijk (s = 1, 2, . . . ,S)
as rating of s. product under sub-criteria cijk (i = 1, 3; j = 1,
2, . . . ,n(i); k = 1, 2, . . . ,n(j)). It is computed by following equation
for quality characteristics and socio-economic factors:
PM
R
m
m1 Defuzz LV k
Rsijk
i 1; 3 and 8s;
13
nfsij
nj
X
Rsijk Nw0ijk
i 1; 3 8j and s;
14
k1
nfsi is the non-functional suitability score of s. product for main criteria ci and is calculated by using following equations:
nfsi
ni
X
nfsij Nw0ij
i 1; 3 8s;
15
Rsij Nw0ij
i 2 8s:
16
j1
nfsi
ni
X
j1
nfs
3
X
i1
nfsi Nw0i
8s:
17
Min: z P l
!
ki dsi l 1 or 2
Pl
ki dpi l 1 or 2
s:t:
S
X
fs xs ds1 1
s1
nfs xs ds2 1
s1
s1
t s xs dp2 dp2 T
s1
xs 1 Choice constraint;
dpi ; dpi P 0 i 1; 2;
xs 0 or 1 s 1; 2 . . . ; S;
where xs, takes values of 0 or 1, where 1 represents that software s
is selected and 0 represents otherwise; Pl, represents priorities assigned to the main objectives (l = 1, suitability; l = 2, project factors); ki , represents the weights attached to the deviation
P
variables associated with suitability objectives, ( 2i1 ki 1); ki,
represents the weights attached to the deviation variables associated with project factors, (i = 1, total cost of ownership; i = 2,
P2
implementation time and
i1 ki 1); fs, represents functional
suitability score of software s; nfs, represents non-functional suitability score of software s; TCOs, represents total cost of ownership
of software s; ts, represents estimated completion time for imple
menting software s; dsi , represents the deviation variables associated with suitability objectives (i = 1, functional suitability; i = 2,
non-functional suitability); dpi ; dpi , represents the deviation variables associated with project factors (i = 1, total cost of ownership;
i = 2, implementation time); TCO*, represents the best value for the
total cost of ownership across all software alternatives; T*, represents the best value for implementation time across all software
alternatives.
The resulting solution represents the best choice for the decision maker.
3. An actual evaluation
The proposed approach was applied to Audio Electronics of Turkeys electronic industry to prove the applicability and validity of
this method in an actual industrial environment. Audio Electronics
is an ISO 9001:2000-certied manufacturer of audio and video
intercom systems for apartments and villas. Since 1979, Audio
has grown from a modest origin to a company with a nationwide
reputation for reliable products of innovative design. It has more
than 1500 different products and exports to at least 20 countries.
In recent years, increased product variety, accelerated technological innovation, and a shortened product life cycle have forced
the subject company to improve intra-rm processes. After initial
talks with several consulting rms, top management brought in
one of them to help the company with their improvements. The
5279
company began to reorganize into a cross-functional, matrix organization structure in terms of its hierarchical structure. Meanwhile,
a cross-functional team was charged with reengineering the companys supply chain processes to better meet customer needs. One
of the key conclusions from these efforts was that the organization
could not prosper with its current information system. The companys most recent major investments in information technology
had been made over ve years earlier. Since, the LOGO Classic
has been used as a commercial automation solution in the company. This system is provided by Turkeys largest independent software vendor Logo Business Solutions. It is the most commonly
used small business solution in Turkey, which was developed
according to customer requests and regularly collected directions
since the rst version. Logo Classic includes accounting, inventory,
invoice, bank, safe deposit, xed assets, ination accounting, additional tax, payroll, fast production, and navigator modules. However, in Audio, all modules of the system were not implemented,
and some of the existing modules have not been operated effectively. Logo Classic System has been used for only storing bill of
material (BOM) data, routing, cost, and accounting information.
The consensus among Audios management team was that the
company was information poor and needed to be cut loose from
its existing system. There were also major concerns about being
able to grow the company and become more global without an
integrated information capability. In these circumstances, in order
to meet the companys new business needs, the consulting rms
team and Audios management team have decided to replace the
existing system with a new enterprise resource planning (ERP) system that would lead to an overall organizational improvement.
Consequently, an effective software selection process has become
necessary.
First of all, in order to conduct ERP selection and project implementation, three cross-functional teams are formed according to
the companys organizational structure. These teams are: (i) technical team, (ii) nancial team, and (iii) logistics team. The technical
team is responsible for all customization and development projects, as well as hardware infrastructures; the nancial team is
responsible for all nance-related activities in the ERP project.
The logistics team consists of the representatives of production,
purchasing, R&D, product management, sales, and marketing
departments. They are responsible for all issues related to their
operations, such as master planning, production planning, forecasting, scheduling, all material movements, BOM validation, and
project management. These teams are guided by Audios management team and supported by consultants.
Next, the members of these three teams interview with the
users in all departments to learn their expectations and the perceived needs of the software. In this step, we assist team members
by providing a detailed functional requirements checklist that consists of three levels and contains more than 600 requirements for
different functional areas. This checklist has been developed based
on our experience as consultants to help different companies select
an ERP, and our experience as an implementer of ERP systems. The
team members consider the requirements listed in this checklist
and, in the event that a different requirement occurs during the
interviews in each department, it is added to the checklist. This
checklist is found to be very useful in collecting data. Since the detailed BPR analyses have already been performed, users can easily
decide what kinds of requirements should be met by ERP software.
Team members record these requirements and categorize them by
the seven main business units, such as logistics (LOG), production
planning (PP), sales management (SM), nance management (FM),
human resources management (HRM), information technology (IT)
and the others (OTH).
Regarding non-functional criteria, the team members reached
consensus on using our proposed criteria hierarchy template rep-
5280
wlogistics
3
X
Defuzz LV m
VS 9:04 9:86 9:47 28:37:
m1
The values 9.04, 9.86 and 9.47 are obtained from a random
experiment using the triangle distribution for very strong. These
weights are then normalized by using Eqs. (8) and (9). Example
calculations for logistics main requirement are illustrated in
Table 2.
Team members assign numerical values (0, 1, 2 or 3) to each
tertiary system requirement indicating the expected performance
value of the resulting software system (eijk, k = 509 in our case)
by reaching consensus. Afterwards, each vendor is given about
3 h to address the system requirements and formally demonstrate
their product. During these demonstrations, the breadth of coverage for the s. candidate product (psijk, s = 7 in our case) are assigned
by using 03 scale. The heuristic algorithm is performed as depicted in Fig. 5 to obtain functional suitability score for each secondary (fsij) and primary (fsi) system requirement, and the overall
functional suitability score of s. alternative (fs). The results of the
algorithm are depicted in Table 3.
By the team members, acceptable level of functional coverage, f,
is determined as 0.75. Since there exist alternatives with the
functional suitability score that is higher than or equal to f, team
members decide to continue the software selection process. Consequently, IAS, MS Axapta, Uyumsoft and Mapics are selected for the
detailed evaluation (s = 1, 2, 4, 6).
Afterwards, the leaders of each of the three teams, the MIS manager (DM1), the nance manager (DM2), and the production
manager (DM3) are asked to perform non-functional suitability
analyses. Each of them establishes the weights of each non-functional criterion in the form of linguistic variables. These opinions
are recorded in separate spreadsheets for each of the three decision
Table 2
Linguistic assessments and aggregated weights for logistics functional requirement
Functional requirements (i = 1, j = 1, 2, . . . 7)
Decision makers
LOG
Organizational structure
Logistics master data
Purchasing
Vendor evaluation
Stock management
Warehouse management
Reporting
DM 1
DM 2
DM 3
VS
VS
M
S
M
VS
S
VS
VS
M
VS
VS
VS
VS
VS
VS
VS
M
VS
S
S
VS
VS
VS
28.37
20.77
26.27
23.50
23.11
27.29
26.41
27.22
0.16
0.12
0.15
0.13
0.13
0.16
0.15
0.16
Table 3
The obtained results from functional suitability analysis
Functional requirements (i = 1, 2 , . . . ,7)
Normalized weights
Alternatives
(Nwi)
s=1
s=2
s=3
s=4
s=5
s=6
s=7
LOG
PP
SM
FM
HRM
IT
OTH
fs (s = 1, 2, . . . ,7, f = 0.75)
0.16
0.17
0.16
0.16
0.10
0.15
0.10
0.97
0.93
1.00
0.98
0.49
0.99
0.00
0.83
0.88
0.98
0.98
0.95
0.91
1.00
0.88
0.94
0.84
0.31
0.82
0.68
0.89
0.91
0.00
0.65
0.90
0.74
0.81
0.90
0.86
1.00
0.12
0.79
0.56
0.66
0.64
0.66
0.82
0.49
0.00
0.57
1.00
1.00
0.97
0.99
0.78
0.94
0.74
0.94
0.73
0.77
0.84
0.68
0.76
0.94
0.00
0.71
5281
Decision makers
Socio-economic factors
Vendor capability
Training and support
Vendor reputation
R&D technology
Consulting service
Service ability
DM1
DM2
DM3
S
VS
M
VS
VS
M
VS
S
VS
S
VS
VS
M
VS
VS
S
M
VS
VS
M
S
makers. Afterwards, the weights of all criteria (w0i s, w0ij s and w0ijk s)
on the hierarchical structure are calculated. These calculations
are illustrated for socio-economic factors main criterion in
Table 4. Suppose two of three decision makers think that the
importance degree of the socio-economic factors (c3) is strong
and one of them thinks it is very strong. Then w03 is calculated:
w03
2
X
Defuzz
23.45
28.36
17.62
27.56
26.00
16.60
27.79
0.30
1.00
0.15
0.24
0.22
0.14
0.24
linguistic variables and defuzzication procedure. These calculations are illustrated for socio-economic factors main criterion
in Table 5. Suppose all of three decision makers think that rating
of IAS (s = 1) under sub-criteria R&D technology (c313) is medium.
Then, R1313 is calculated using equation (13) as:
P3
R1313
R
m
LV m
S Defuzz LV VS 6:98 8:10 8:37 23:45:
m1
R
m
m1 Defuzz LV M
This process is repeated for each product and all criteria on the
hierarchical structure. Once all these data are transferred to
another spreadsheet, the nfsijs, nfsis and nfss are now easily computed by using Eqs. (14)(17). Table 6 gives the results for each
product.
Team members obtain estimates of total cost of ownership and
implementation time for selected software alternatives through
The values 6.98 and 8.10 are obtained from a random experiment using the triangle distribution for strong, 8.37 is obtained
from a random experiment using the triangle distribution for very
strong. These ratings are then normalized by using Eqs. (10)(12).
Thereafter, the product ratings under the lowest level criteria
(Rsijk) on the hierarchical structure are computed by using the same
Table 5
Example calculations for the product ratings under the socio-economic factors
Alternatives
Non-functional criteria
(i = 1, j = 1, k = 1, 2, . . . ,5)
s=1
Decision makers
s=2
s=4
s=6
DM1
DM2
DM3
DM1
DM2
DM3
DM1
DM2
DM3
DM1
DM2
DM3
R131k
R231k
R431k
R631k
VS
S
M
M
M
S
S
M
S
S
M
S
M
VS
VS
VS
M
VS
S
VS
S
S
VS
VS
S
VS
VS
S
S
S
VS
VS
S
S
S
S
VS
VS
VS
VS
VS
S
VS
S
VS
S
VS
S
S
M
S
VS
M
S
VS
M
S
VS
S
VS
7.75
7.38
5.98
7.43
8.00
9.96
7.81
9.85
6.55
7.78
8.76
7.96
8.63
9.67
9.49
7.28
7.64
5.65
9.64
8.63
Table 6
Non-functional suitability scores of software alternatives
Non-functional criteria
Normalized
weights
Nw0i
Nw0ij
Alternatives
Product ratings
Rsijk
s=1
0.36
0.34
Socio-economic factors (i = 3, j = 1)
Vendor capability
Overall non-functional suitability score nfs (s = 1, 2, 4, 6)
0.30
s=2
s=4
s=6
0.18
0.17
0.18
0.15
0.17
0.15
0.10
0.11
0.09
0.10
0.10
0.09
0.10
0.09
0.11
0.11
1
s=1
7.82
6.00
6.59
7.57
5.82
6.00
5.24
6.96
5.40
6.92
7.78
7.56
6.81
5.30
7.88
5.55
9.45
9.46
8.39
7.75
8.29
8.38
9.41
9.22
8.06
9.53
7.98
7.05
5.63
8.04
7.85
7.11
9.38
7.67
7.60
7.41
nfsi
s=2
8.83
7.59
9.02
7.23
7.57
7.89
s=4
8.47
7.99
7.37
7.94
6.16
7.47
s=6
s=1
s=2
s=4
s=6
6.64
8.06
7.57
7.85
6.56
8.80
7.59
6.96
7.28
8.41
8.84
7.66
6.80
0.68
8.42
0.84
7.96
0.80
7.49
0.75
8.02
7.79
8.82
8.55
6.51
7.37
6.97
7.48
5.30
7.69
6.20
7.71
5.74
8.56
6.61
7.37
7.28
8.41
8.84
7.66
5282
Table 7
Quantitative measurements of software alternatives
4. Conclusions
Quantitative measurements
8.5
1.5
1
4
1
0.4
0.3
0.3
0
16
12
x2
8.4
0.6
1
4
1
0.4
0.3
0.3
0
15
16
x4
5.5
1.5
1
3
4
0.4
0.3
0.3
3
15
6
x6
9.5
0.5
1
4
1
0.4
0.3
0.3
0
16
12
Table 8
Results of scenarios [obtained vs. (targeted)]
k1
k2
k1
k2
fs
nfs
TCOs ($0000)
Ts (month)
xs
0.70
0.70
0.30
0.30
0.70
0.70
0.30
0.30
0.94 (1)
0.79 (1)
0.84 (1)
0.80 (1)
15 (15)
15 (15)
16 (6)
6 (6)
x2
x4
interviews with four vendors. Table 7 provides data on the estimated time and total cost of implementing each ERP software.
Team members are asked also to identify the weights attached to
the deviation variables associated with suitability objectives and
project factors. These values are determined as k1 0:70; k2
0:30; k1 0:70; k2 0:30 by reaching consensus.
Based on these data and the previously computed functional
and non-functional suitability scores, we can formulate the goal
constraints for this problem. This 01 goal programming model
is solved using LINDO (version 6.1) in a few seconds of computer
time. This version of LINDO includes the capability to prioritize a
set of objectives using the preemptive goal option. The preemptive goal command performs Lexico-optimization on the model.
The problem is solved using two different orders of preemptive
priorities as requested by the decision making team. In the rst set
of scenarios, the ordering is Psuitability, Pproject, respectively. The second set of scenarios is associated with viewing project factors as
most important. The results are summarized in Table 8. The rst
row is associated with the rst scenario. For this scenario, the
results are summarized as follows: x2 1; ds1 0:06; ds2
0:16; dp1 dp1 dp2 0; dp2 10. MS Axapta is chosen consuming the total cost of $150,000. We will use 10 more months of
1; ds1 0:21; ds2 0:20; dp1 dp1 dp2 dp2 0. The model is
also solved using different k and k weights that are varied from 0
to 1. However, the selected alternatives are not changed in these
scenarios with any values of k and k.
After these scenario analyses, the project team recommended
MS Axapta (x2) as the most suitable selection for the company.
The decision making team is impressed with the analysis that we
presented. They can integrate qualitative objectives like maximizing functional and non-functional suitability, and quantitative
objectives like minimizing implementation time and total cost of
ownership. The decision makers of the company believe that proposed approach is a useful tool providing the ability to examine
various scenarios and assess the sensitivity of the solutions to
changes in priorities. By using our process grounded in mathematics and decision theory, the selection time, as well as the cost of
ERP software implementation and maintenance is reduced.
References
Ayag, Z., & R.G.zdemir (2006). An intelligent approach to ERP software selection
through fuzzy ANP. International Journal of Production
Research, 126
(preview article).
Bosch, J., & Molin, P. (1999). Software architecture design: Evaluation and
transformation. In Proceedings of the IEEE engineering of computer based
systems symposium (ECBS99) (pp. 410).
Buschmann, F., Meunier, R., Rohnet, H., Sommerland, P., & Stal, M. (1996). Patternoriented software architecture a system of patterns. Chichester: John Wiley &
Sons.
Brito, I., & Moreira, A. (2004). Integrating the NFR framework in a RE model. In
Workshop of the 3rd international conference on aspect-oriented software
development (pp. 2833). Lancaster, UK.
Chen, K., & Gorla, N. (1998). Information system project selection using fuzzy logic.
IEEE Transactions on Systems, Man, and Cybernetics-Part A: Systems and Humans,
28(6), 849855.
Detyniecki, M., & Yager, R. R. (2001). Ranking fuzzy numbers using alpha-weighted
valuations. International Journal of Uncertainty, Fuzziness and Knowledge-Based
Systems, 8(5), 573592.
5283