Transforming Software Business Models into Business Processes
Markus Schief
1
, Amir Bonakdar
2
and Tobias Weiblen
2
1
SAP Research, CEC Darmstadt, Darmstadt, Germany
2
SAP Research, CEC St. Gallen, St. Gallen, Switzerland
Keywords: Business Model, Software Industry, Business Process, Strategy, Implementation, Software-as-a-service.
Abstract: Changed business models, such as induced by Software-as-a-Service, require an effective implementation in
a firm’s organization. This study clarifies the relation between business models as an implementation of a
company’s strategy, and business processes, as an abstraction of a company’s operations. The presented
transformation framework provides specific meaning to the industrial setting of a software vendor morphing
to a SaaS model. Both underlying concepts, the business model and the value chain, as a coarse-grained
view on business processes, stem from software industry research. The explorative findings cover a detailed
description of the transformation framework as well as an exemplary expert survey that can serve as a refer-
ence for software firm decision makers. Thus, the study provides profound insights into the potential opera-
tional impacts of business model changes.
1 INTRODUCTION
Companies are continuously striving for more agility.
One of the challenges is the rapid translation of
changes in a company’s strategy to its operations. For
example, the introduction of Business ByDesign
required SAP to revise its traditional business model
(BM). It was SAP’s first major product designed as a
SaaS solution and it required changes in the firm’s
operational processes, such as, for instance, in the
volume provisioning and management of multi-tenant
systems. Finally, the release to market was postponed
as the firm could not cope with the operational chal-
lenges (Beal, 2008). Thus, in the light of an increas-
ing shift towards SaaS solutions, software firms such
as SAP need to be supported in analyzing the impact
of BM innovations on their operations.
Unfortunately, a gap between business strategy
and business processes (BPs) hampers companies’
agility. Al-Debei and Avison (2010) propose to close
this gap with the BM concept, which can be used to
“translate the broad strategy into more specific busi-
ness architectural, co-operational, value propositional,
and financial arrangements”.
Building upon that claim the main goal of this pa-
per is to clarify the relation between BMs and BPs,
based on literature review and inductive reasoning.
Throughout the study, a software firm morphing from
an on-premise to a SaaS solution provider will be
used as an exemplary showcase. The structure of this
paper is as follows. Section 2 provides a background
on transformation concepts and the associated chal-
lenges. In section 3, a framework supporting the
transformation from BMs to BPs for software busi-
nesses is presented. Section 4 prioritizes areas that are
of particular importance in the BM to BP transforma-
tion of a fictional software company that changes its
business model. Reflecting the huge number of com-
binatorial scenarios and the related effort to analyze
each of them, we propose a content enriched trans-
formation matrix that can serve as a reference model.
It can support software firm decision makers to
evaluate BM options. Section 5, finally, concludes the
paper.
2 RELATED WORK
The transformation of BMs into BPs relates to the
research field of enterprise architecture (EA), which
aims at modelling a firm’s most important artifacts
and their mutual interdependencies. In 2008, Aier, et
al. provided a systematic state of the art review cov-
ering related literature and findings from entrepreneu-
rial praxis. Though a lot of research has been done in
this area, they show that publications follow diverse
perspectives. To differentiate and classify the various
approaches, an analysis framework based on Winter
167
Schief M., Bonakdar A. and Weiblen T..
Transforming Software Business Models into Business Processes.
DOI: 10.5220/0003967401670172
In Proceedings of the 14th International Conference on Enterprise Information Systems (ICEIS-2012), pages 167-172
ISBN: 978-989-8565-12-9
Copyright
c
 2012 SCITEPRESS (Science and Technology Publications, Lda.)

and Fischer (2007) is proposed. It disaggregates the
enterprise architecture into five layers: Strategy, Or-
ganization, Integration, Software/Data, and IT-Infra-
structure. Surprisingly, Aier et al. (2008) conclude
that aspects on the strategy layer are only addressed
by few researchers (Aier and Schönherr, 2006);
(Braun and Winter, 2007).
In addition to the research conducted in the EA
domain, the BM can be considered as a concept that
addresses the EA strategy layer. According to a state
of the art review by Morris et al. (2005) a BM en-
courages the entrepreneur to (a) conceptualize the
venture as an interrelated set of strategic choices; (b)
seek complementary relationships among elements
through unique combinations; (c) develop activity
sets around a logical framework; and (d) ensure con-
sistency between elements of strategy, architecture,
economics, growth, and exit intentions. Although
Morris et al. (2005) identify a need for a translation of
a BM into operational decisions, they do not describe
explicitly how to cascade a BM into operations.
Further approaches transforming BMs into opera-
tions are revealed by Burkhart et al. (2011), Brews
and Tucci (2003), and Van Putten and Schief (2011).
Though a lot of research has been done in the EA-
field, artifacts on the strategy level and their trans-
formation into operations have not yet been addressed
sufficiently. Researchers from the BM domain pro-
vide generic approaches, but most often lack specific
guidance that can be used in practice. Referring to the
EA state-of-art literature review by Aier et al. (2008),
our study is contributing to the alignment of the the
first two layers: strategy and organization.
3 TRANSFORMATION
FRAMEWORK
3.1 BM of a Software Firm
While several definitions of BMs can be found, no
established standard exist so far (Burkhart et al.,
2011). Approaches either define a taxonomy, allow-
ing to classify a BM based on a finite number of BM
types, or they provide a reference model, allowing to
describe an infinite number of BMs. Examples of
such BM conceptualizations are REA (Geertsa and
McCarthy, 2002), and e3-value (Gordijn and
Akkermans, 2001). Beyond generic BM concepts,
industry specific ones are proposed. For the software
industry, various conceptualizations as well as tax-
onomies are available. Thereof, the conceptualization
proposed by Schief and Buxmann (2012) is highly
comprehensive and builds upon the economic
properties of the software industry. Their BM concept
spans three layers. The first layer consists of five
groups: Strategy, Revenue, Upstream, Downstream,
and Usage. On the second layer, each group com-
prises four elements. Thus, 20 elements serve as the
conceptual building blocks of the BM. The third
layer, finally, contains pre-defined manifestations for
each element.
3.2 Value Chain of a Software Firm
The concept of the value chain was initially intro-
duced by Porter (1985) as a tool for developing and
sustaining competitive primary activities. By disag-
gregating a firm into its various activities, the value
chain model allows to describe the activities, i.e.
operations or BPs, performed by a firm. We hence
suggest that the hierarchical decomposition of a
firm’s activities starts with the value chain model.
The coarse-grained activities comprise finer-grained
activities, which can be described and implemented
as BPs.
Pussep et al. (2011) propose a unified value chain
concept for the software industry. This value chain
contains typical activities performed by software
firms. The software value chain comprises eleven
activities: product research, component procurement,
product development, user documentation, production
and packaging, marketing, implementation, training
and certification, maintenance and support, opera-
tions, and replacement. For our BM to BP transfor-
mation model, we adapt the software value chain by
removing the activity “user documentation” and re-
placing it by separating the activity “maintenance and
support” into two distinct activities. The rationale
behind is that we judge maintenance and support as
two very major activities with respect to the daily
operations of a software firm.
3.3 Framework
With a few exceptions (Al-Debei and Avison, 2010);
(MacInnes, 2005), most literature has taken a static
perspective on BMs. The implicit assumption is that
BM choices are rarely adjusted. However, BMs often
do not remain steady over time, for instance, in order
to keep in line with changing environments (Afuah
and Tucci, 2003). As a result, de Reuver, Bouwman
and MacInnes (2007) argue that BMs need to be
aligned with external changes during all phases from
development to exploitation. In our transformation
process (Figure 1) we assume that a strategic trigger
(e.g., the rise of SaaS) calls for a review of one or
multiple BM elements within a present BM configu-
ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems
168

ration.
A
identifie
d
alternati
v
serves a
s
concept,
dent var
i
trix (Ap
p
shows t
h
standing
arising
b
analyzin
affected
discuss
t
assumin
g
ing all o
t
finally,
p
with a
c
N
otably
,
modelin
g
various
activitie
s
up to a
b
activity,
ture, i.e.
to chan
g
Fig
u
As
a
ment, w
e
from an
the valu
e
b
e rema
r
are high
l
design,
d
reflect a
tiple cus
t
A
s soon as
t
d
, the challe
n
v
e elemen
t
s
o
s
the indepen
d
representing
iable. The co
p
endix) is he
n
h
eir interdep
e
of the relati
o
b
y combinato
r
n
g the impac
t
BM elemen
t
t
he relations
fo
g
a change o
f
t
her elements
p
otential risk
s
c
ertain BM c
h
,
following t
h
g
, we inves
t
business pro
s
, roles, info
r
b
usiness proc
e
we investiga
t
the BP profil
g
e.
u
re 1: A
p
roces
s
a
fictional ch
a
e
assume that
on-
p
remise t
o
e
chain activi
t
r
kable. BPs t
h
l
y likely to c
h
d
evelopment,
multi tenanc
y
t
omers on on
e
t
he affected
n
ge is to esti
m
o
n operations
d
ent variable
a
operational
B
rresponding
t
n
ce built upo
n
e
ndencies. T
o
o
ns and to co
p
r
y change sce
n
t
on the affe
c
t
individuall
y
fo
r each BM
e
f
that elemen
t
fixe
d
. Based
s
, costs, and
b
h
ange scenar
i
h
e notions o
f
t
igate the p
o
cess attribut
e
r
mation, syst
e
e
ss profile. F
o
t
e the extent
t
e of the asso
c
s
for BM to BP
a
nge exampl
e
the operatin
g
o
a SaaS mo
d
t
y “developm
e
h
at are associ
a
h
ange. For ins
and testing
y
concept to
a
e
system.
BM element
m
ate the imp
a
. The BM co
a
nd the value
B
Ps, as the d
e
t
ransformatio
n
n
both concep
t
o
ease
t
he
u
p
e with comp
l
n
arios, we pr
o
c
ted BPs for
y
. That mean
s
lement, ever
y
t
only while
k
on this found
a
b
enefits asso
c
i
o can be de
r
f
business p
r
o
tential impa
c
e
s (e.g. asso
c
e
ms etc.) tha
t
o
r each value
t
o which the
s
iated BPs, is
l
transformatio
n
e
of one B
M
g
model is ch
a
d
el. The imp
a
e
nt” is suppo
s
a
ted to this a
c
t
ance,
t
he so
ft
processes ne
a
llow running
t
s are
a
ct of
o
ncept
chain
epen-
n
ma-
t
s and
u
nde
r
-
l
exity
o
pose
each
s
, we
y
time
k
eep-
a
tion,
c
iated
r
ived.
r
ocess
c
t on
c
iated
t
sum
chain
s
truc-
l
ikely
n
.
M
ele-
a
nged
a
ct on
s
ed to
c
tivity
ft
ware
ed to
mul-
4
4.1
By
l
tion
s
spac
stati
o
BM
s
ele
m
ties.
one
lect
e
ver
y
appl
i
corp
nue
p
let
e
strip
p
oi
n
infl
u
tion
s
imp
a
opi
n
cha
n
was
p
roc
p
roc
W
uati
o
exp
e
diff
e
op
m
p
roc
was
197
5
resu
l
cho
s
und
e
too
k
cha
n
fro
m
man
i
p
act
of t
h
dist
r
that
mor
e
indi
v
p
erf
o
rem
a
on
r
TRANS
F
AREAS
Method
l
ooking at c
h
s
as the inde
p
e for analysi
s
o
ns for a sin
g
s
could be a
n
m
ent changes
o
As
t
his is n
o
exemplary st
a
e
d as a starti
n
y
typical soft
w
i
cation soft
w
orate custom
through supp
o
e
set of B
M
ed backgrou
n
n
t fixed, the
e
u
enced by 75
s
. This leads
t
a
ct – a num
b
n
ions on. The
n
ge on the B
P
evaluated on
ess changes
n
ess required”
.
W
e asked a s
a
o
n of chang
e
e
rience accu
m
e
rent value c
h
m
ent, marketi
n
ess to arrive
derived fro
m
5
), with the
g
l
t (Häder, 2
0
s
en for both,
j
e
restimating
a
k
three rounds
:
n
ge impact.
F
m
its starting
i
festation wa
s
per value ch
a
h
e resulting m
r
ibuted amon
g
showed a cr
o
e
than on
e
v
idual re-ass
e
o
rmed. 3.
J
o
i
a
ining diffe
r
e
emaining cel
l
ORMAT
I
h
anges in B
M
p
endent varia
b
s
. Not consid
e
g
le BM elem
e
n
alyzed with
o
n each of th
e
o
t viable, we
r
a
rting scenar
i
n
g point for
w
are company
w
are in-house
,
e
rs, and gen
e
o
rt options a
n
manifestati
o
n
d in the App
e
e
leven value
c
possible cha
n
t
o 825 requir
e
b
er that is fe
a
impact of a
n
P
s in a certa
i
a 5-
p
oint sca
l
n
eeded” to 5
“
.
a
mple of thre
e
e
impact. T
h
m
ulates to m
o
h
ain areas su
c
n
g, consulti
n
at a single
m
the Delp
h
g
oal to arriv
e
0
00). A risk
-
j
udgment an
d
a
ny impact.
:
1.
I
ndep
e
F
or each B
M
manifestatio
n
s
evaluated i
n
a
in activity. 2.
a
trices. The
r
g
the experts,
o
ss-expert de
v
e
scale-
p
oin
t
e
ssment of p
r
nt di
s
cussio
n
nces. A gro
u
l
s with a de
v
I
ON FOC
U
M
elements’
m
b
le, we open
e
ring multipl
e
m
ent, 2.6*10
12
regards to
i
e
11 value ch
a
restrict our a
n
i
o. The BM
t
the analysis
that develop
s
, sells licen
s
e
rates additi
o
n
d upgrades.
T
o
ns is indica
e
ndix. With t
h
c
hain activiti
e
n
ges in BM
m
e
d estimates
o
a
sible to obt
a
n
isolated B
M
i
n value chai
n
l
e reaching f
r
“full changes
e
experts for t
h
h
eir software
m
ore than 20
u
ch as resear
c
n
g, and sup
p
transformati
o
h
i method
(
e
at a conse
n
-
averse appr
o
d
aggregation
,
The analysi
s
e
ndent asses
s
M
element, t
h
o
n to a pote
n
n
terms of pr
o
Pair-wise co
r
esults of rou
n
with cells h
i
v
iation in est
t
. Subseque
r
evious esti
m
n
and reso
l
u
p discussion
v
iation larger
U
S
m
anifesta-
up a vast
e
manife-
potential
i
mpact of
a
in activi-
n
alysis to
h
at is se-
depicts a
s
standard
s
es to i
t
s
o
nal reve-
T
he co
m
-
t
ed by a
h
e starting
e
s can be
m
anifesta-
o
f change
a
in expert
M
element
n
activity
om 0 “no
and new
h
eir eval-
industry
years in
c
h, devel-
p
ort. The
o
n matrix
(
Linstone,
n
sual end
o
ach was
,
to avoid
s
process
s
ment of
e change
n
tial new
o
cess i
m
-
mpa
r
ison
n
d 1 were
ghlighted
i
mates of
n
tly, an
m
ates was
l
ution of
focusing
than one
TransformingSoftwareBusinessModelsintoBusinessProcesses
169

was used to exchange arguments and rationales for
certain ratings. Individual matrices were adjusted
during the discussion, so that these remaining major
differences could be resolved.
The three individual matrices resulting from
round 3 were combined into the final transformation
matrix by transferring the highest estimate given for
each cell.
4.2 Results and Discussion
The resulting matrix, which exhibits the influence of
BM element changes on a company’s process struc-
ture in form of a heat map (Appendix). Overall, an
isolated change of a single BM element results in
“complete” or “high” effects on the process structure
in 20.6% of cases (Figure 2). The corresponding BM
elements and BP activities should receive highest
attention when planning and implementing BM
changes. It is remarkable, though, that more than half
(53.5%) of the possible BM element changes have no
or low impact on the process structure in a certain
area. Thus, it is worthwhile to focus attention on
those areas that feature higher change sensitivity.
Figure 2: Aggregated results of transformation matrix –
change sensitivity.
Strong dependencies exist in areas where “up-
stream”, “downstream”, and “usage”-related BM
elements meet related value chain activities. Yet,
cross-dependencies between those blocks exist as
well. Most prominently, a change of the operating
model on-premise to on-demand causes major
changes to the “upstream” product development and
packaging processes. Clearly, the existing processes
in these areas have to undergo major changes to re-
flect the new SaaS delivery model. Stronger relation-
ships than the operating model decision are only
found between two more strategic BM elements and
the BP structure (see Figure 3):
Product Portfolio changes have a disruptive effect
on all processes when the company decides to shift its
main focus from products to services. Value Chain
Coverage – the “make, ally, or buy” decision – can
also have massive consequences for a company’s
entire process structure.
Most/least influencing BM elements
[# of activities impacted „complete“ or „high“]
1 Product Portfolio (11)
Value Chain Coverage (11)
3 Operating Model (7)
…..
17 Pricing Model (1)
Technical Platform (1)
Target Customer Type (1)
Support Model (1)
Figure 3: Transformation sensitivity of BM elements.
Most/least sensitive BP activities
[# of elements affecting „complete“ or „high“]
1 Product Development (11)
Marketing (11)
3 Implementation (10)
…..
8 Product Research (5)
Component Procurement (5)
10 Training & Certification (4)
Replacement (4)
Figure 4: Transformation sensitivity of BP activities.
Another interesting aspect can be found from
looking at those BP activities that are most strongly
influenced by BM changes (Figure 4): product devel-
opment, marketing, and implementation. Since the
latter two activities frequently involve partners, those
partners will also be strongly affected by changes to
related BM elements.
The above findings show the practical relevance
of the proposed transformation matrix. As the (so far
separate) entities BM and BP are now linked by the
transformation matrix, a new “tool chain” for the
impact analysis of strategic decisions becomes avail-
able. Once the strategic decision, such as the intro-
duction of a new SaaS offering, has been translated
into required BM changes, the impact on the com-
pany’s processes are immediately visible. The trans-
formation matrix illustrates that this decision leads to
major changes, and thus challenges, to processes in
the development and operations areas – which were
exactly the areas that caused the delay in SAP’s new
SaaS offering (Beal, 2008). As this example shows,
the matrix allows decision makers to identify which
parts of the organization would be affected by a
strategic decision and, in a second step, which
consequences in terms of change effort its implement-
tation would mean. Feeding back these results into
the strategy planning process should lead to more
informed decisions and more realistic timelines.
4.3 Limitations
The straightforwardness of the proposed model
Category Occurrence Share
4 – Complete 25 3.0%
3 – High 145 17.6%
2 – Medium 214 25.9%
1 – Low 200 24.3%
0 – None 241 29.2%
825 100.0%
ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems
170

comes at the price of some limitations, the first and
foremost being its inherent industry focus. By basing
the model on the software industry BM and value
chain concepts, the results cannot be transferred to
other industries.
The assumption of the ceteris paribus condition
when evaluating change impact is another simplifica-
tion. The model does not allow conclusions about the
combined effect of simultaneous changes to two or
more BM elements.
Lastly, the focus on effects on business process
attributes tends to neglect “soft” effects of BM
changes; dependencies such as emerging training
requirements, HR consequences, or organizational
resistance are not considered.
5 CONCLUSIONS
The rising importance of Software-as-a-Service chal-
lenges software firms’ BMs. This article develops a
transformation framework to translate BM challenges
into firms’ operations. The framework allows the user
to describe, analyze, and simulate the impact of BM
changes on BPs. This link between strategic decisions
and a company’s operations is extremely valuable for
fast-moving industries such as the software industry.
Thus, it contributes to both, to the investigation of
changes associated to SaaS and to the challenges
addressed by the research in the enterprise architec-
ture field.
REFERENCES
Afuah, A, Tucci, C. (2003). Internet BMs and Strategies.
Boston, MA: McGraw-Hill.
Aier, S., Riege, C. and Winter, R. (2008).
Unternehmensarchitektur - Literaturüberblick und
Stand der Praxis. Wirtschaftsinformatik, 50(4), 292-304.
Aier, S. and Schönherr, M. (2006). Status Quo
geschäftsprozessorientierter Architekturintegration.
Wirtschaftsinformatik, 48(3), 188–197.
Al-Debei, M. M.; Avison, D. (2010). Developing a Unified
Framework of the BM Concept. European Journal of
Information Systems, 19(3), 359-376.
Beal, B. (2008). SAP delays on-demand ERP. Retrieved
Januar 31, 2012, from http://searchsap.techtarget.com/
news/1311843/SAP-delays-on-demand-ERP.
Braun, C. and Winter, R., (2007). Integration of IT Service
Management into Enterprise Architecture. In
Proceedings of the ACM Symposium of Applied
Computing. New York.
Brews, P. J. and Tucci, C., (2003). Building Internet
Generation Companies: Lessons from the Front Lines
of the Old Economy. Academy of Management
Executive, 17(4), 8-24.
Burkhart, T., Krumeich, J., Werth, D. and Loos, P., (2011).
Analyzing the BM Concept - a Comprehensive
Classification of Literature. In Proceedings of the
International Conference on Information Systems,
Shanghai.
de Reuver, M., Bouwman, H. and MacInnes, I., (2007).
What Drives BM Dynamics? A Case Survey. In
Proceedings of the 8
th
World Congress on the
Management of eBusiness, Toronto.
Geerts, G. L., McCarthy, W. E., (2002): An Ontological
Analysis of the Economic Primitives of the
Extended-REA Enterprise Information Architecture.
International Joural of Accounting Information Systems
3, 1–16.
Gordijn J., Akkermans J. M., (2001) Designing and
evaluating e-business models. IEEE Intell Syst –
Intelligent e-Business, 16(4), 11–17.
Häder, M. (2000). Die Expertenauswahl bei Delphi-
Befragungen. Arbeitspapier, Zentrum für Umfragen,
Methoden und Analysen. Mannheim: ZUMA.
Linstone, H. A., (1975). The delphi method - techniques
and applications. Reading, MA: Addison-Wesley.
MacInnes, I., (2005). Dynamic BM Framework for
Emerging Technologies. International Journal of
Services Technology and Management, 6(1), 3-19.
Morris, M., Schindehutte, M. and Allen, J., (2005). The
Entrepeneur’s BM: Toward a Unified Perspective.
Journal of Business Research, 58(6), 726-735.
Porter, M.E. (1985). Competitive Advantage. London: The
Free Press.
Pussep, A., Schief, M., Widaija, T., Buxmann, P. and Wolf,
C. M., (2011). The Software Value Chain as an
Analytical Framework for the Software Industry and Its
Exemplary Application for Vertical Integration
Measurement. In Proceedings of the Americas
Conference on Information Systems. Detroit.
Schief, M. and Buxmann, P., (2012). BMs in the Software
Industry. In Proceedings of the 45
th
Hawaii
International Conference on System Sciences. Hawaii.
Van Putten, B. J. and Schief, M., (2011). The Relation
Between Dynamic BMs and Business Cases. In
Proceedings of the 5
th
European Conference on
Information Systems and Evaluation. Como.
Winter, R. and Fischer, R., (2007). Essential Layers,
Artifacts, and Dependencies of Enterprise Architecture.
Journal of Enterprise Architecture, 3(2), 7-18.
TransformingSoftwareBusinessModelsintoBusinessProcesses
171

APPENDIX
Element Manifestation(asis)
Product
Research
Component
Procurement
Product
Developme nt
Production&
Packaging Marketing Implementation
Training&
Certification Operations Maintenance Support Replacement
InvestmentHorizon 4‐Complete 2‐Medium 2‐Medium 0‐None 3‐High 2‐ Medium 1‐Low 2‐Medium 1‐Low 1‐Low 3‐High
SubsidenceModel 0‐None 1‐Low 0‐None 0‐None 1‐Low 0‐None 0‐None 0‐None 0‐None 0‐None 0‐ None
IncomeMode l
GrowthMode l 1‐ Low 1‐Low 1‐Low 0‐None 1‐Low 0‐None 0‐None 0‐None 0‐None 0‐None 0‐ 
None
SpeculativeMod el 4‐Complete 2‐Medi um 2‐Me di u m 0‐None 3‐High 2‐ Me di u m 1‐Low 2‐Medium 1‐Low 1‐Low 3‐High
SocialMode l 1‐ Low 2‐Me dium 2‐ Medium 0‐None 3‐High 0‐ None 0‐None 0‐None 1‐Low 0‐None 1‐Low
CrossFinance 0‐None 1‐Low 0‐None 0‐None 2‐Medi um 0‐ None 0‐None 0‐None 1‐Low 0‐None 0‐None
UniqueSellingProposition 2‐Medium 3‐High 2‐Medium 2‐Medium 3‐High 3‐ High 2‐Medium 3‐High 3‐High 3‐High 2
‐Medium
Quality 2‐Medium 2‐Me di u m 2‐ Me dium 1‐Low 1‐Low 2‐Medium 1‐Low 2‐ Medium 3‐High 2‐Medium 1‐Low
Features
InnovationLeadership 2‐Medium 3‐High 2‐Me di um 0‐None 2‐Medi um 3‐ High 2‐Me di u m 3‐Hi gh 2‐Medium 3‐High 2‐Medium
Efficiency 1‐Low 3‐ High 2‐Medi um 2‐Medi um 1‐Low 2‐ Medium 0‐None 3‐High 3‐Hi gh 2‐Medium 2‐Medium
IntimateCustomerRelationship 2‐Medium 0‐None 1‐Low 0‐None 3‐High 3‐ High 1‐Low 3‐High 2‐Medium 3‐High 2‐Medium
NetworkLeverage 2‐Medium 0‐None 1‐Low 1‐Low 3‐High 2‐ Me di um 0‐None 3‐Hi gh 2‐Medium 1‐Low 2‐Medium
OneStopShopping 1‐Low 3‐High 1‐ Low 0‐None 2‐Me di um 2‐ Me di um 0‐ None 3‐High 1‐Low 1‐Low 2‐Medium
ProductPortfolio 4‐Complete 4‐Complete 4‐Complete 4‐Complete 4‐Complete 4‐Complete 4‐Complete 4‐Complete 4‐Complete 4‐Complete 4‐Complete
Hardware Control 2‐Medium 2‐Me di um 3‐ High 3‐High 2‐ Medium 2‐ Me di u m 1‐Low 0‐None 3‐High 2‐Medium 2‐
Medium
SystemSoftware 1‐Low 1‐Low 3‐High 2‐Me di u m 2‐ Me dium 2‐ Me di um 1‐Low 1‐Low 2‐Medium 1‐Low 0‐None
Midd l eware /Database 1‐Low 1‐Low 2‐Me di u m 1‐Low 1‐Low 2‐ Medium 1‐Low 1‐Low 2‐Medium 1‐Low 0‐None
ApplicationSoftware
Mobile&WebApplications 1‐Low 1‐Low 1‐Low 2‐Me di um 2‐ Medium 2‐ Me di u m 2‐Me di u m 1‐Low 1‐Low 1‐Low 0‐None
Softw.orientedServices 4‐Complete 4‐Complete 4‐Complete 4‐Complete 4‐Complete 4‐ 
Complete 4‐Complete 4‐Complete 4‐Complete 4‐Complete 4‐Complete
ValueChainCoverage 4‐Complete 4‐Complete 4‐Complete 4‐Complete 4‐Complete 4‐Complete 4‐Complete 4‐Complete 4‐Complete 4‐Complete 4‐Complete
Make
Ally 3‐High 3‐High 3‐ High 3‐High 3‐ High 3‐ High 3‐High 3‐Hi gh 3‐Hi gh 3‐High 3‐High
Buy 4‐Complete 4‐Complete 4‐Complete 4‐Complete 4‐Complete 4‐Complete 4‐Complete 4‐Complete 4‐Complete 4‐Complete 4‐Complete
LicenseModel 3‐High 3‐High 3‐High 1‐Low 2‐Medium 2‐ Medium 0‐None 0
‐None 3‐High 3‐ High 2‐ Medium
SellRights 2‐Medium 3‐High 3‐High 1‐Low 2‐Me di u m 1‐ Low 0‐None 0‐None 3‐High 3‐High 2‐Medium
SellUsageRights
Freeware 0‐None 1‐Low 1‐Low 1‐Low 2‐Medi um 0‐ None 0‐None 0‐None 1‐Low 3‐High 2‐Medium
OpenSource(w/oinheritance) 2‐Medium 2‐Medium 3‐ High 0‐None 2‐Medi u m 1‐Low 0‐None 0‐None 3‐High 3‐High 0‐None
ViralOpenSource 3‐Hi gh 3‐ High 3‐High 0
‐None 2‐Medi um 2‐ Medium 0‐None 0‐None 3‐High 3‐ High 0‐None
PricingModel 0‐None 0‐None 2‐Medium 0‐None 3‐High 0‐ None 0‐None 2‐Medium 0‐None 0‐None 0‐None
Usage Based 0‐ None 0‐None 2‐Medi u m 0‐None 3‐High 0‐ None 0‐None 2‐Medium 0‐None 0‐None 0‐None
Usage Independent
MarketPenetration 0‐None 2‐Medium 0‐None 3‐High 3‐ High 3‐ High 1‐Low 3‐Hi gh 1‐Low 3‐High 2‐Medium
Low 0‐ None 2‐Me di um 0‐ None 3
‐High 3‐ High 3‐ Hi gh 1‐Low 3‐High 1‐Low 3‐High 0‐None
Medi um
High 0‐None 2‐Medi u m 0‐ None 3‐High 3‐High 3‐ Hi gh 1‐Low 3‐High 1‐ Low 3‐High 2‐Medium
OperatingMargins 3‐High 2‐Medium 3‐High 1‐Low 2‐Medium 3‐High 1‐Low 3‐High 2‐Medium 2‐Medium 0‐None
Low 2‐ Medium 1‐Low 2‐ Medi um 1‐ Low 2‐Me dium 2‐ Me di um 1‐ Low 2‐Medium 2‐Medium 2‐Medium 0‐None
Medi um
High 3‐High 2‐Medium 3‐High 1‐Low 2‐Medium 3‐ 
High 1‐Low 3‐High 2‐ Medium 2‐Medium 0‐None
TechnicalPlatform 1‐Low 1‐Low 3‐High 1‐Low 0‐None 2‐Medium 1‐Low 2‐Medium 2‐Me dium 1‐Low 0‐None
Java 1‐Low 1‐Low 3‐High 1‐Low 0‐None 2‐ Me dium 1‐Low 2‐Medium 2‐Medium 1‐Low 0‐None
C1‐Low 1‐Low 3‐High 1‐Low 0‐None 2‐ Me dium 1‐Low 2‐Medium 2‐Medium 1‐Low 0‐None
C++
C# 1‐Low 1‐Low 3‐High 1‐Low 0‐None 2‐Me di u m 1‐Low 2‐Medium 2‐Medium 1
‐Low 0‐None
PhP 1‐Low 1‐Low 3‐High 1‐Low 0‐None 2‐Me di u m 1‐Low 2‐Medium 2‐Medium 1‐Low 0‐None
Python 1‐Low 1‐Low 3‐High 1‐Low 0‐None 2‐Me di um 1‐Low 2‐Medium 2‐Medium 1‐Low 0‐None
(Visual)Basic 1‐Low 1‐Low 3‐High 1‐Low 0‐None 2‐Me di u m 1‐Low 2‐Medium 2‐Medium 1‐Low 0‐None
Objective‐C1‐Low 1‐Low 3‐High 1‐Low 0‐None 2‐ Me dium 1‐Low 2‐Medium 2‐Medium 1‐Low 0‐None
Perl 1
‐Low 1‐Low 3‐High 1‐Low 0‐None 2‐ Me dium 1‐Low 2‐Medium 2‐Medium 1‐Low 0‐None
JavaScript 1‐Low 1‐Low 3‐ High 1‐Low 0‐None 2‐Medium 1‐Low 2‐Medium 2‐Medium 1‐Low 0‐None
Others 1‐Low 1‐Low 3‐High 1‐Low 0‐None 2‐Me di u m 1‐Low 2‐Medium 2‐Medium 1‐Low 0‐None
Paradigms 2‐Medium 1‐Low 3‐High 3‐High 2‐Medium 2‐Medium 2‐Medium 3‐Hi gh 3‐Hi gh 3‐High 1‐Low
SOA
CloudComputing 2‐Medium 0‐None 2‐Medi u m 3‐
High 2‐Medi um 2‐ Medium 1‐Low 3‐High 2‐ Medium 1‐Low 0‐None
Lean 2‐Medium 0‐None 3‐High 0‐None 0‐None 0‐None 1‐Low 0‐None 3‐High 3‐High 1‐Low
Mul ti ‐ Tenancy 2‐Medium 0‐None 3‐High 0‐None 0‐None 1‐Low 1‐Low 3‐High 0‐None 2‐Medium 0‐None
Mobile 2‐Medium 0‐None 2‐Me di um 0‐None 2‐Medi um 2‐ Medium 2‐Me d ium 1‐Low 1‐Low 1‐Low 0‐None
Security 2‐Medium 1‐Low 3‐High 1‐Low 0‐None 0‐None 2‐Me di um 3
‐Hi gh 2‐Medium 2‐Medium 0‐None
WebServices 2‐Medium 0‐None 3‐High 0‐None 0‐None 0‐None 1‐Low 0‐None 1‐Low 1‐Low 0‐None
Web2.0 2‐Medium 0‐None 2‐Me di u m 0‐None 2‐Medi um 0‐ None 2‐Me d i um 0‐None 0‐None 1‐Low 0‐None
Real‐time 2‐ Medium 0‐None 2‐Medi um 0‐None 0‐None 1‐Low 1‐Low 2‐Medium 0‐None 1‐Low 0‐None
Locali zation 0‐ None 1‐Low 3‐High 0‐None 3‐High 1‐ Low 1‐Low 1‐Low 0‐
None 2‐Medium 0‐None
Local 0‐None 1‐Low 1‐Low 0‐None 3‐High 1‐ Low 1‐Low 1‐Low 0‐None 2‐Medium 0‐None
AMERICAS 0‐None 1‐Low 3‐High 0‐None 3‐High 1‐Low 1‐Low 1‐Low 0‐None 2‐Medium 0‐None
EMEA
APJ 0‐None 1‐Low 3‐High 0‐None 3‐High 1‐ Low 1‐Low 1‐Low 0‐None 2‐Medium 0‐None
DegreeofStandardization 1‐Low 3‐High 3‐High 3‐High 1‐Low 3‐ High 3‐High 0‐None 3‐Hi gh 2‐ Medium 1‐Low
IndividualProduction 1‐Low 3‐ High 3‐High 3‐High 1‐Low 3‐High 3‐High 0‐None 3‐High 2‐Medium 1‐Low
BatchProduction 1‐Low 3‐ High 2‐Medi um 3‐ High 1‐ Low 2‐Me di um 2‐Medi um 0‐ None 2‐Medium 1‐Low 0‐None
BulkProduction
Channel 1‐Low 1‐Low 1‐Low 3‐High 3‐ High 3‐ High 0‐None 0‐None 0‐None 0‐None 1‐Low
SalesAgents
Retail 1‐Low 1‐Low 1‐Low 3‐High 3‐ High 3‐ High 0‐None 0‐None 0‐None 0‐None 1‐
Low
Online 1‐Low 1‐Low 1‐Low 3‐High 3‐High 0‐None 0‐None 0‐None 0‐None 0‐None 0‐None
Telesales 1‐Low 1‐Low 1‐Low 1‐Low 3‐High 0‐ None 0‐None 0‐None 0‐None 0‐None 0‐None
Events 1‐Low 1‐Low 1‐Low 1‐Low 3‐High 0‐ None 0‐None 0‐None 0‐None 0‐None 0‐None
Targe tIndustries 2‐Medium 0‐None 2‐Medium 0‐None 3‐High 3‐ High 2‐Medium 2‐Medium 0‐None 1‐Low 0‐None
Agri.,Forestry,And
Fishing 2‐Medium 0‐None 2‐Medium 0‐None 3‐High 3‐ High 2‐Me di u m 2‐Medium 0‐None 1‐Low 0‐None
Mini ng 2‐ Medium 0‐None 2‐Medi um 0‐ None 3‐High 3‐High 2‐Me di u m 2‐Medium 0‐None 1‐Low 0‐None
Construction 2‐Medium 0‐None 2‐Medium 0‐None 3‐High 3‐ High 2‐Me di u m 2‐Medium 0‐None 1‐Low 0‐None
Manufacturing
Trans/Comm/Elect/Gas/Sanitary 2‐Medium 0‐None 2‐Medi u m 0‐None 3‐High 3‐ High 2‐Me di um 2‐Medium 0‐None 1‐Low 0‐None
Trade 2‐Medium 0‐None 2‐Medium 0‐
None 3‐High 3‐High 2‐Me di um 2‐Medium 0‐None 1‐Low 0‐None
Finance/Insurance/RealEstate 2‐Medium 0‐None 2‐Medi um 0‐None 3‐High 3‐ Hi gh 2‐Me d i um 2‐Medium 0‐None 1‐Low 0‐None
Services 2‐Medium 0‐None 2‐Me dium 0‐None 3‐High 3‐High 2‐Me di u m 2‐Medium 0‐None 1‐Low 0‐None
PublicAdministration 2‐Medium 0‐None 2‐Medium 0‐None 3‐High 3‐High 2‐Me di u m 2‐Medium 0‐None 1‐Low 0‐None
Targe tCustomerSize 2‐Medium 0‐None 3
‐High 1‐Low 3‐High 3‐ Hi gh 2‐Medium 2‐Medium 1‐Low 2‐Medium 1‐Low
PrivateIndividuals 2‐Medium 0‐None 3‐High 1‐Low 3‐High 3‐ High 2‐Me di um 2‐ Medium 1‐Low 2‐Medium 1‐Low
SmallOrganizations 2‐Medium 0‐None 3‐High 0‐None 2‐Medi u m 3‐ High 1‐Low 2‐Medium 0‐None 2‐Medium 1‐Low
Medi umOrganizations 1‐Low 0‐None 2‐Me di u m 0‐None 2‐Medi um 1‐ Low 1‐Low 1‐Low 0‐None 1‐Low 1‐Low
LargeOrganizations
Targe tCustomerType 1
‐Low 0‐None 2‐Medium 1‐Low 2‐Medium 1‐Low 3‐High 2‐Medium 2‐Medium 2‐Medium 0‐None
Use r
Devel oper 1‐Low 0‐ None 2‐Medi u m 1‐Low 2‐Me di u m 1‐ Low 3‐High 2‐Medium 2‐Medium 2‐Medium 0‐None
OperatingModel 2‐Medium 0‐None 3‐High 3‐High 3‐High 3‐ High 2‐Medium 3‐High 3‐ High 3‐ High 2‐Medium
OnPremise
OnDemand 2‐Medium 0‐None 3‐High 3‐High 3‐ High 3‐ High 2‐Med i um 3‐ High 3‐ High 3‐ High 2‐Medium
Support
Model 0‐None 0‐None 0‐None 0‐None 2‐Medium 0‐None 0‐None 2‐Medium 2‐Medium 4‐Complete 0‐None
StandardSupport 0‐None 0‐None 0‐None 0‐None 2‐Medium 0‐ None 0‐None 2‐Medium 2‐Medium 4‐Complete 0‐None
FewSupportOfferings
CustomerSpecificSupport 0‐None 0‐None 0‐None 0‐None 2‐Me di um 0‐ None 0‐None 2‐Medium 2‐Medium 4‐Complete 0‐None
MaintenanceModel 0‐None 0‐None 2‐Medium 2‐Medium 1‐Low 0‐ None 0‐None 3‐High 3‐High 2
‐Medium 2‐Medium
Weekly 0‐None 0‐None 2‐Medi um 2‐ Medium 1‐ Low 0‐None 0‐None 3‐Hi gh 3‐Hi gh 2‐Medium 2‐Medium
Monthly 0‐None 0‐None 2‐Medium 2‐Me di u m 1‐ Low 0‐None 0‐None 3‐High 3‐ High 2‐ Medium 2‐Medium
Quarterly 0‐None 0‐None 2‐Medi um 1‐Low 1‐ Low 0‐None 0‐None 3‐High 3‐High 2‐Medium 2‐Medium
Biyearly
Yearly 0‐None 0‐None 1‐Low 1‐Low 1‐Low 0‐None 0‐None 3‐High 3‐Hi gh 2‐Medium 2‐Medium
Repl aceme ntStrategy 0‐
None 0‐None 3‐High 0‐None 1‐Low 2‐ Medium 1‐Low 3‐High 3‐High 2‐Medium 3‐High
OneRelease 0‐None 0‐None 3‐High 0‐None 1‐Low 1‐ Low 1‐Low 2‐Medium 3‐High 2‐ Medium 3‐High
FewReleases
ManyReleases 0‐None 0‐None 2‐Medi u m 0‐None 1‐Low 2‐Me di um 1‐Low 3‐Hi gh 3‐Hi gh 2‐Medium 3‐High
BusinessModel ValueChainActivities
ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems
172