JOURNAL OF INFORMATION TECHNOLOGY THEORY AND APPLICATION.docx

JOURNAL OF INFORMATION TECHNOLOGY
THEORY AND APPLICATION
ISSN: 1532-3416
Volume 17 Issue 2 Paper 2 pp. 5 – 21 July 2016
How to Structure Business Transformation Projects:
The Case of Infineon’s Finance IT Roadmap
Maximilian Röglinger
FIM Research Center, University of Bayreuth
[email protected]
Manuel Bolsinger
FIM Research Center, University of Augsburg, Germany
Björn Häckel
Matthias Walter

Abstract:
Although project management, benefits management, change
management, and transformation management are
everyday terms in many organizations, projects still experience
high failure rates. Business transformation projects in
particular are prone to fail because they affect multiple
enterprise architecture layers, involve many stakeholders, last
several years, and tie up considerable amounts of corporate
capital. To handle their complexity, scholars recommend
structuring business transformation projects into portfolios of
interdependent, yet smaller and, thus, manageable
projects. So far, little guidance on how to do so exists. To share
first-hand experience and stimulate research, we
present and reflect on a project conducted with Infineon
Technologies in which we co-developed Infineon’s finance IT
roadmap. The finance IT roadmap served as the foundation for
transforming Infineon’s finance IT setup to tackle
future challenges of financial management in the semiconductor
industry from an integrated business, process, and IT
perspective.
Keywords: Business Transformation Management, Enterprise
Architecture, Finance IT Setup, Project
Decomposition, Project Portfolio Management, Semiconductor
Industry.
Jan vom Brocke was the Senior Editor for this paper.
6 How to Structure Business Transformation Projects: The Case
of Infineon’s Finance IT Roadmap

Volume 17 Issue 2 Paper 2
1 Introduction
Business transformation is about fundamental change (Rouse,
2005). Centering around the orchestrated
redesign of an organization’s genetic architecture, business
transformation projects involve many
stakeholder groups, affect multiple layers of the enterprise
architecture, last several years, and tie up
considerable amounts of corporate capital (Abraham, Aier, &
Winter, 2015; Morgan & Page, 2008;
Safrudin, Rosemann, Recker, & Genrich, 2014). Moreover,
despite their enormous potential impact on
corporate success, business transformation projects are prone to
fail (Dehning, Richardson, & Zmud,
2003; Nelson & Morris, 2014). For instance, The Standish
Group (2013) classifies 38 percent of large-
scale projects (i.e., projects with a labor content greater than
US$10 million) as failures.
Against this backdrop, researchers have investigated business
transformation from different angles for
years. From a descriptive perspective, Safrudin et al. (2014)
crafted a typology of business transformation
projects based on 20 real-world cases. Abraham and Junglas
(2011) investigated at a healthcare
company how a coordinated information systems (IS)
implementation process contributed to
organizational transformation and found that the linkage
between IS implementation and business
strategies promoted coordination. Abraham et al. (2015)
analyzed which properties enterprise architecture

models should have to overcome knowledge boundaries in
business transformation projects. From a
prescriptive perspective, Uhl and Gollenia (2012) proposed the
business transformation management
methodology to serve as a comprehensible, adaptable, holistic,
and integrative approach to business
transformation, to balance rational and emotional aspects of
transformation, and to provide execution
guidance.
Because one particular reason for why business transformation
projects fail is a lack of up-front
preparation and planning, we focus on program and project
management activities. In particular, we focus
on program planning and integration and scoping management
(Rosemann, Recker, Safrudin, &
Marketsmueller, 2012). In the business transformation lifecycle
model—which includes the “envision”,
“engage”, “transform”, and “optimize” phases—the program and
project management activities mainly
relate to the “engage” phase. In this phase, scholars recommend
structuring business transformation
projects into portfolios of interdependent, yet smaller and, thus,
manageable projects (Stiles, Uhl, & Stratil,
2012). In fact, only four percent of all projects with a labor
content less than US$1 million have been
reported to fail (The Standish Group, 2013). Though being
extensive and multi-faceted, related work
provides little guidance on how to structure business
transformation projects—be it the literature on business
transformation management itself or the literature on related
disciplines such as project management,
project portfolio management, and enterprise architecture
management. The project management body of
knowledge, for example, fits standalone projects well but hardly
applies to business transformation projects

(Project Management Institute, 2013). Methods from project
portfolio management help select and schedule
projects from predefined project portfolios but not to identify
these portfolios (Bardhan, Bagchi, & Sougstaf,
2004). Finally, the aforementioned business transformation
management methodology provides detailed
guidance on many topics related to program and project
management, but it does not discuss how to
structure business transformation projects (Rosemann et al.,
2012).
To address this gap and stimulate research, we share first-hand
experience on how to structure business
transformation projects gained in a project with Infineon
Technologies in which we co-developed
Infineon’s finance IT roadmap. In Section 2, we introduce the
context of Infineon Technologies and focus
particularly on the future challenges of financial management in
the semiconductor industry. We also
outline the problem statement of Infineon’s finance IT roadmap
project. After that, in Section 3, we
elaborate on the objectives, main tasks, and outcomes of all
project phases. In Section 4, we reflect on
related lessons learned. In Section 5, we conclude by discussing
our study’s implications for future
research.
Contribution:
To provide first-hand experience on how to structure business
transformation projects, this paper reports on a project
with Infineon Technologies in which we co-developed
Infineon’s finance IT roadmap. The paper elaborates on the
objectives and outcomes of all project phases and on related
lessons learned. It also shares insights into the project’s
main tasks (i.e., conceptualize and operationalize the target

state, identify and prioritize gaps, compile a project
portfolio, and derive transformation roadmaps) and tools (i.e., a
modular project framework, fulfillment-importance
matrix, project templates) that proved useful in the Infineon
case. Finally, the paper showcases how researchers and
practitioners can collaborate to solve complex real-world
problems.
Journal of Information Technology Theory and Application 7
2 Case Context and Problem Statement
Infineon Technologies is a global market leader in the
semiconductor industry. In the 2014 fiscal year,
Infineon generated revenue of about €4.3 billion. As of
September 2014, Infineon employed approximately
29,800 people at 21 research and development (R&D) and 12
manufacturing locations worldwide. With its
semiconductor and system solutions for automotive and
industrial electronics and for chip card and
security applications, Infineon focuses on three central
challenges facing contemporary society: energy
efficiency, mobility, and security. As with other companies
operating in the semiconductor industry,
Infineon faces ever-stronger demand- and supply-side
challenges, which makes a sophisticated IT-based
financial management setup strategically important.
From the demand-side perspective, the semiconductor industry
is highly volatile and short-term oriented

because, for one, due to fast technological progress and the
rapid pace of innovation, most
semiconductors have an extraordinarily short lifecycle and high
depreciation. Moreover, many customers
of semi-conductor companies face high demand uncertainty
themselves. For example, the automotive
industry is highly dependent on business cycles. To cope with
their own demand uncertainty, customers of
semiconductor companies are likely to place and cancel orders
of substantial volume on short notice. On
the contrary, they expect an availability of several decades for
some products. Both circumstances make
managing the demand side in the semiconductor industry
challenging.
From the supply-side perspective, the semiconductor industry is
comparatively sluggish and requires a
long-term orientation because, for one, establishing and
maintaining production facilities requires huge
investments and considerable ramp-up time. Production
facilities often lead to initial investments
exceeding €100 million and do not amortize in less than 10 to
15 years. When considering the demand-
side dynamics, calculating business cases for such investments
is challenging. Production facilities need
continuous updating and streamlining to keep up with the
innovation pace due to product variety and cost-
reduction pressure. Semiconductor production also requires
firms to coordinate globally distributed supply
network. Finally, semiconductors rely on precious metals and
rare earths, which have volatile prices by
themselves and whose availability throughout upcoming decades
is at risk.
To address the demand- and supply-side challenges governing
the semiconductor industry, Infineon

Technologies decided to transform its finance IT setup.
Infineon’s finance IT setup included all processes
operated and services offered by Infineon’s financial
management department and the IT support of these
processes and services. The transformation of Infineon’s
finance IT setup was an architectural
transformation since parts of Infineon’s enterprise architecture
had to be overhauled; the core business
concepts were not the subject of change (Safrudin et al., 2014;
Wu, Rose, & Lyytinen, 2011). To prepare
the transformation of Infineon’s finance IT setup, we supported
Infineon to conduct the finance IT roadmap
project. The project’s overarching objective was to determine
the target state of Infineon’s finance IT setup
and provide concrete guidance in terms of a project portfolio
and possible roadmaps on how to transform
the previous finance IT setup in three to five years.
We believe for several reasons that the transformation of
Infineon’s finance IT setup is a suitable case for
discussing the program and project management activities of the
business transformation lifecycle model.
First, Infineon’s business and IT departments were heavily
involved in the business transformation project.
Second, Infineon’s finance department offered services in
different organizational contexts and with
heterogeneous requirements on process and IT support, such
that the project’s overall complexity was
very high. Based on our experience, one can find similar
transformation projects in many other companies
worldwide. Therefore, in our perception, the transformation of
Infineon’s finance IT setup was much more
closely related to a typical than to a particular case.
3 The

Solution
3.1 Project Setup and Overview
The head of Infineon’s financial management department, who
directly reported to the chief financial
officer, initiated and sponsored the finance IT roadmap project.
A workshop involving Infineon’s financial
management department identified the need to transform
Infineon’s finance IT setup. Thus, both senior
management and the entire department supported the project.
The project’s core team comprised four
corporate and four academic members. To account for the
project’s interdisciplinary nature and to cover
all relevant layers of Infineon’s enterprise architecture, two
corporate team members stemmed from
8 How to Structure Business Transformation Projects: The Case
of Infineon’s Finance IT Roadmap

Infineon’s finance department, whereas the other two worked
for the IT department. Two corporate team
members, who shared the role of the project manager from
Infineon’s side, were department heads to
ensure that the finance IT roadmap project was equipped with
sufficient decision authority and sufficiently
connected with the senior management. As for the academic
team members, two members had a
background primarily in financial management, whereas the
other two had their background primarily in
business process management, enterprise architecture
management, and IT. The academic team
encompassed two post-doctorate researchers and two PhD
students. The academic team members’ role
was to enrich Infineon’s experience with academic knowledge,
to prepare and conduct interviews, and to
help compile the project portfolio and transformation roadmaps.
To help the team members exchange
information among themselves, the academic team members
worked three days per week on site. They

spent the rest of the week at university to synchronize with
colleagues doing research in similar areas.
The finance IT roadmap project took nine months and comprised
three phases: 1) conceptualizing and
operationalizing the target state, 2) identifying and prioritizing
gaps, and 3) compiling a project portfolio
and deriving transformation roadmaps. Because we
conceptualized the target state top-down and
compiled the project portfolio bottom-up, the finance IT
roadmap project followed a mixed top-
down/bottom-up approach. Before starting the project, the team
reached consensus on strategic
guidelines regarding the project’s phase plan and the project
results. Figure 1 overviews all project phases
including objectives, main tasks, and outcomes. We discuss
each phase in turn from Section 3.3.1 to
Section 3.3.3.
Figure 1. Structure of the Finance IT Roadmap Project
3.2 Project Guidelines
Before starting the finance IT roadmap project, the team agreed

on strategic guidelines with respect to the
project’s phase plan and results that we had to consider
throughout the project. The academic team
members derived initial versions of most guidelines from
related academic knowledge, and they iteratively
prioritized, selected, and configured the guidelines in close
collaboration with the corporate team
members. Infineon proposed other guidelines (e.g., guideline 4).
We chose project portfolio management
and enterprise architecture management as primary reference
disciplines for two reasons. First, the
finance IT roadmap project aimed to structure the
transformation of Infineon’s finance IT setup and
provide guidance via transformation roadmaps. Thus,
knowledge about project portfolios and project
interactions was highly important. Second, with the
transformation of Infineon’s finance IT setup being an
architectural transformation, we needed to think across multiple
enterprise architecture layers and to
consider interactions among these layers. Overall, the project
team agreed on five guidelines. Below, we
present the final set of guidelines together with selected
justificatory references where applicable.

1. Involve multiple stakeholder groups and management layers:
the finance IT roadmap
project needed to involve multiple stakeholder groups and
management layers. Involving
multiple stakeholder groups (e.g., departments such as finance,
operations, and IT) fosters
operational business IT alignment, which is a success factor for
transforming strategic plans
into operations (Wagner & Weitzel, 2012). Involving multiple
stakeholder groups also helps
create a shared understanding of the transformation project’s
target and, therefore, drives
transformation success (Abraham et al., 2015). As for Infineon,
this guideline was particularly
important because Infineon is a global company whose
departments are predominantly located
in multiple countries and each country has its own peculiarities

regarding financial
management. Due to the variety of processes operated and
services offered by Infineon’s
finance IT setup, the project also had to consider multiple
management layers. Indeed, top-
down initiatives often fail due to a lack of coordination among
organizational levels (Fonstad &
Robertson, 2006).
2. Involve multiple enterprise architecture layers: the
transformation’s scope dictated that the
transformation not focus solely on IT. Rather, we committed to
consider multiple enterprise
architectures layers (e.g., business model, processes, application
systems, and IT
infrastructure) and interactions between neighboring layers
(Abraham et al., 2015; Winter &
Schelp, 2008) because research has shown that treating business
transformation projects as
purely IT driven is a critical failure factor and that a holistic
approach considering multiple
architecture layers is a success factor of organizational design
and transformation (Braun &
Winter, 2007).

3. Consider project interactions: due to the high number of
projects we expected to be
necessary to transform Infineon’s finance IT setup, we had to
consider interactions among
projects throughout the entire transformation, which included
specifying individual projects and
compiling the resulting project portfolio. Considering project
interactions ensures that one can
flexibly adapt transformation roadmaps in response to changes
in the business environment,
management priorities, and available resources (Ghasemzadeh &
Archer, 2000; Martinsuo,
2013; Morris & Jamieson, 2005). Because the transformation
had a timeframe of several
years, intertemporal and scheduling interactions were
particularly important (Bardhan et al.,
2004).
4. Parsimoniously document the resulting project portfolio: due
to the high number of
projects necessary to transform Infineon’s finance IT setup, we
had to document the project
portfolio resulting from the finance IT roadmap in a
parsimonious manner. This documentation

had to go far beyond a mere project list. Rather, the
documentation had to comprehensively
overview and visualize projects, interactions among projects,
and management priorities such
that Infineon could use it both as a foundation for deriving
transformation roadmaps and as a
tool for adjusting transformation roadmaps.
5. Align the project portfolio with the transformation target: we
had to align the resulting
project portfolio with the target state envisioned for the
transformation (Patanakul & Shenhar,
2012). For each project, one had to be able to clearly argue how
and to what extent it
contributed to the overall transformation (Rosemann et al.,
2012).
3.3 Project Phases
3.3.1 Phase 1: Conceptualize and Operationalize the Target
State
In the first phase, we conceptualized and operationalized the
target state of Infineon’s finance IT setup. To
do so, we first conceived an initial set of high-level

requirements based on a structured literature review.
We deliberately refrained from extensively analyzing and
documenting Infineon’s existing finance IT setup
for several reasons: first, in a global company such as Infineon
Technologies, such an endeavor would
have taken months. Second, starting with the finance IT target
setup helped develop a bolder vision of the
future and avoid getting stuck in the existing setup’s problems.
Third, we analyzed the existing finance IT
setup throughout the second phase. To ensure that the high-level
requirements complied not only with the
academic state-of-the-art knowledge but also with the
peculiarities of Infineon, we refined the initial set of
high-level requirements throughout multiple review rounds with
the corporate project team members.
Figure 2 shows the final set of high-level requirements that we
used in the finance IT roadmap project.
With the transformation of Infineon’s finance IT setup being an
architectural one, we structured the high-
10 How to Structure Business Transformation Projects: The
Case of Infineon’s Finance IT Roadmap

level requirements along three layers derived from enterprise
architecture management (i.e., business
requirements, process-related and organizational requirements,
and IT-related requirements).
As a theoretical lens, we relied on value-based management and
related disciplines such as business
process management, business intelligence, and corporate
performance management to cover all
involved enterprise architecture layers. We chose value-based
management as our guiding paradigm as it
emphasizes cash flow, future, and risk orientation (e.g.,
Rappaport, 1986). Value-based management
directly affects corporate activities such as risk management,
cash flow management, investment and
project valuation, planning and forecasting; it also affects the
interfaces of these activities that one uses to
operational finance services (e.g., Aretz & Bartram, 2010; Hahn
& Kuhn, 2012; Malmi & Ikäheimo, 2003).
All these activities were important for Infineon’s financial
management activities and, thus, for the finance

IT setup. Our choosing value-based management was in line
with the aspirations of Infineon’s financial
management department. In the workshop in which the financial
management department identified the
need for transforming Infineon’s finance IT setup, it also
decided to strengthen its cash flow, future, and
risk orientation. Thus, in line with the objectives of Infineon’s
financial management department, we chose
value-based management as a perspective to promote
organizational transformation.
Figure 2. High-level Requirements of the Finance IT Target
Setup
As a foundation for the gap analysis we performed in the second
phase, we operationalized the high-level
requirements via low-level requirements. Low-level
requirements had to be on such a low level of
abstraction that we could discuss the target state of Infineon’s
finance IT setup (and, more importantly,
gaps between the target state and the existing finance IT setup)
with corporate experts in relation to their
daily processes. The process we used to deriving low-level

requirements was similar to that for deriving
high-level requirements. The project team derived an initial set
of low-level requirements (as far as
possible in accordance with academic state-of-the-art
knowledge) and continuously refined until the set
sufficiently covered all fields of action. In the end, at least one
low-level requirement had to cover each
high-level requirement. The final catalog of low-level
requirements that captured Infineon’s finance IT
target setup included 169 low-level requirements. Some
examples include: “Outlier analysis (anomaly
detection) is performed (e.g., to identify sales
outliers/anomalies in a data set of a region, product, sales
representative, or season)” and “Data for analytical purposes
(e.g., planning, forecasting, and reporting) is
retrieved from a core data warehouse and multiple dependent
data marts”.
Due to the high number of low-level requirements, we relied not
only on the three layers derived from
enterprise architecture management but also on Infineon’s
finance service catalog to structure the low-
level requirements. Infineon’s finance department had
conceived the finance service catalog just before
the finance IT roadmap project started. It included all services

offered by Infineon’s financial management
department, including operational services (e.g., accounting,
operational tax services, and working capital
management) and analytical services (e.g., planning, targeting,
analytics, and reporting). One could easily
communicate this second dimension in Infineon. It also helped
ensure completeness when deriving low-
level requirements and selecting low-level requirements for
interviews in the second phase. To fine-tune
the low-level requirements’ understandability, we conducted
pretests with selected corporate experts. As a
result, we enriched the low-level requirements with Infineon-
specific examples and with open-ended
follow-up questions to obtain richer insights as input for the
second and third phases.

3.3.2 Phase 2: Identify and Prioritize Gaps
In the second phase, we identified and prioritized gaps between
the status quo and the target state of
Infineon’s finance IT setup. We first conducted semi-structured
interviews based on the low-level
requirements derived in the first phase with corporate experts
from different stakeholder groups. We also
interviewed selected senior managers to obtain insights from
both an operational and a management
perspective. The corporate project team members proposed all
interviewees in accordance with Infineon’s
finance service catalog.
The questionnaire used for the interviews included selected
low-level requirements and the corresponding
follow-up questions that matched with interviewees’ area of
expertise. We included these questions in the
questionnaire because they helped the interviewees prepare the
interview and the interviewers discuss
the requirements in a comparable manner across all interviews.
At the end of the questionnaire, we
included overarching questions to elicit the interviewees’
expectations concerning the transformation of
Infineon’s finance IT setup, perceived complexity drivers, and

principal pain and opportunity points
regarding the finance IT setup. To identify gaps, the
interviewees also had to quantitatively rate to what
extent Infineon was already fulfilling the low-level
requirements (from “poor” to “excellent”) and how
important it was that they were excellently fulfilled in the
future (from “not at all” to “business critical”) on
six-point Likert scales. Overall, we conducted 33 semi-
structured inter-views with finance and IT experts in
charge of different finance services (e.g., head of tax
management, head of IT, and heads of finance in
different geographical regions). We also interviewed six senior
managers from Infineon’s finance and IT
community. Because most interviews involved more than one
interviewee, including several members
from the interviewees’ teams, we interviewed 86 experts in
total. Each interview lasted about two hours
and covered approximately 30 low-level requirements.
After we conducted all interviews, we aggregated the
quantitative results for each low-level requirement
and assigned them to quadrants (which imply a specific option
for action in line with the associated
fulfillment and importance values) of a fulfillment-importance
matrix. The fulfillment-importance matrix

slightly resembles a mirrored version of Gartner’s Magic
Quadrant except the latter’s “ability to execute”
dimension corresponds to the former‘s “current extent of
fulfillment” and the former’s “importance of
excellent fulfillment” dimension replaces the latter’s
“completeness-of-vision” dimension (Gartner, 2015).
Figure 3 shows the results for all 169 low-level requirements.
The “Invest!” quadrant encompasses all low-
level requirements with a low fulfillment and high importance
of excellent fulfillment. We treated all low-
level requirements located in this quadrant as gaps. The idea is
that, by transforming Infineon’s finance IT
setup, Infineon successively closes all gaps and moves the
associated requirements to the “Manage
Excellence!” quadrant. The “Manage Excellence!” quadrant
includes requirements with a high fulfillment
and high importance of excellent fulfillment. There were small
or no gaps regarding the requirements in
this quadrant. Therefore, we excluded these requirements from
further analyses. The main challenge of
this quadrant was to maintain the high level of fulfillment and
management attention over time, particularly
during the transformation of Infineon’s finance IT setup. The
“Reprioritize! or Disinvest!” quadrant
encompasses all requirements with high fulfillment and low

importance of excellent fulfillment. Considering
the effort required for maintaining high levels of fulfillment,
the low-level requirements located in this
quadrant may have been underestimated or cause unnecessarily
high effort, which kept valuable
resources away from the transformation project. Thus, there are
two options: reprioritize requirements
(i.e., increase their perceived importance of excellent
fulfillment), or disinvest them (i.e., reduce service
levels, staff, or IT support). The first option leads to a
migration toward the “Manage Excellence!”
quadrant, and the second option leads to a migration toward the
“Ignore!” quadrant. Finally, the “Ignore!”
quadrant encompasses all requirements featuring a low
fulfillment and low importance of excellent
fulfillment. Management should not emphasize these
requirements. Therefore, we excluded these
requirements from further analyses as well. The requirements
located in the “Invest!” quadrant were not
the only source of gaps: there were also gaps related to
requirements located in the other quadrants,
which we identified by contrasting their quantitative rating
against the interviewers’ impressions from the

interviews. We further enlarged the catalog of gaps by
analyzing the qualitative insights from the follow-
up, the overarching questions, and the interviews with senior
managers.
For our analysis, we defined the quadrants of the fulfillment-
importance matrix by interpreting fulfillment
values less than or equal to 4 and importance values less than 3
as low. Choosing these borders, we
accounted for the circumstance that interviewees tended to be
uncertain about whether to choose 3 (i.e.,
the requirement tended not to be well fulfilled / not so
important) or 4 (i.e., the requirement tended to be
well fulfilled / important).
In sum, almost no low-level requirements were located in the
“Ignore!” and the “Reprioritize! or Disinvest!”

quadrants. On the one hand, this finding corroborated the
validity of our low-level requirements. On the
other, it showed that Infineon did not overinvest in particular
topics of the finance IT setup. We located
many requirements in the “Manage Excellence!” quadrant, a
finding that indicates the fact that Infineon did
a good job regarding some central topics of the finance IT
setup. Most interestingly, low-level
requirements located in the “Invest!” quadrant (i.e., the gaps)
were almost equally distributed across the
layers of the enterprise architecture. That is, treating the
finance IT roadmap project as a purely IT-driven
transformation endeavor would have neglected about two thirds
of the relevant gaps.
Figure 3. Fulfillment-importance Matrix Derived from 33 Semi-
structured Interviews
3.3.3 Phase 3: Compile a Project Portfolio and Derive
Transformation Roadmaps
In the third phase, we compiled a portfolio of interdepending
projects that we expected to close the gaps
between the status quo and the target state of Infineon’s finance

IT setup. Thus, we clustered the
identified gaps into groups, each of which the project team
members were convinced they could tackle in
a single project. This procedure ensured that each project
aligned with the target state of Infineon’s
finance IT setup. While defining projects, we catered for
interactions such as successor/predecessor
relationships.
To document the resulting project portfolio in a parsimonious
manner, we conceived a modular project
framework. The framework’s dimensions referred to the
processes operated by Infineon’s financial
management department and to cross-process topics discovered
during the grouping of gaps. We chose
this matrix-like structure because, according to the experience
gained throughout the finance IT roadmap
project, we could unambiguously assign some gaps to distinct
finance processes and others to distinct
topics that spanned multiple processes (e.g., advanced
analytics). We grouped projects according to the
processes operated by Infineon’s finance department and not in
line with the services that the finance
service catalog covered because there also were gaps regarding
some internal finance processes that

influenced several services. Moreover, the people from
Infineon’s financial management were familiar with
process thinking. The final project framework included only
those finance processes for which we
identified gaps. We marked cells of the project framework as
“not applicable” if we could derive no
respective project. We referred to projects that referred neither
to a distinct process nor to a cross-process
topic as standalone projects and collected them separately.
Figure 4 shows the project framework’s
overall structure.
Figure 4. Overall Structure of the Modular Project Framework
The modular project framework distinguishes process-specific

projects and cross-process topics. Process-
specific projects close gaps that relate to a distinct process but
not to a cross-process topic. One may
need multiple process-specific projects to close all gaps
identified for a particular process. The framework
assumes that one can address processes independently, which
leaves considerable degrees of freedom
when deciding on the sequence one should implement projects.
We specified process-specific projects
using a brief project description, benefits, and opportunities,
drawbacks and risks, an arbitrary number of
work packages, direct interactions with other projects, and
further comments. Cross-process topics
address all gaps that refer to a distinct topic (e.g., advanced
analytics). The specification of a cross-
process topic briefly describes the related topic, benefits and
opportunities, drawbacks and risks, work
packages, direct relationships with other projects, and further
comments. In contrast to process-specific
projects, work packages of a cross-process topic split into
preparatory, general, and process-specific work
packages. This structure enables configuring projects for
concrete process/topic combinations. One must
execute general work packages for each process intended to be
improved according to the cross-process

topic. One must execute process-specific work packages only
for a distinct process. Table 1 shows a
partly anonymized specification of the cross-process topic
“advanced reporting”. A concrete process/topic-
specific project may also require preparatory work packages to
be carried out beforehand if it is the first
project referring to this topic. We considered
successor/predecessor relationships among cross-process
topics that restrict the sequence in which one can implement
process/topic-specific projects.
Table 1. Specification of the Cross-process Topic “Advanced

Reporting” (Partly Anonymized)
Cross-process topic: advanced reporting
Brief description
This cross-process topic aims to improve the reports with
respect to their coverage of information needs and their
creation processes. In particular, this topic includes the
development of ….
Addressed high-level requirement
Main benefits and opportunities Main drawbacks and risks
1
Consistent report design in line with the state-of-the-
art.
1 Flexibility to adapt reports to specific needs of
management may be reduced.

2 … 2 …
I—Preparatory work packages Scope Goals
1
Evaluate in detail the existing reporting application landscape
within IFX regarding
their ability to cover information needs and the manual effort
required for creating
reports.
IT -
2 … Functional …
II—General work packages Scope Goals
1
Adapt and implement company-wide reporting guidelines in
existing reporting
applications which according to preparatory work package 1
will still be in use in
the future. Thereby consider information needs of the report
recipients.

Functional …
2
Establish regularly feedback process between report recipients
and report
creators regarding the fulfillment of the report recipient’s
information needs as well
as the decisions that resulted from the reports.
Process -
3 […] IT …
III—Process-specific work packages Process Scope Goals
1
Improve automated reporting on R&D projects (and their risks)
under consideration of company-wide reporting guidelines.
…
IT …
2

Improve (ex ante) reporting on main risks of investments
(especially demand risks and sales risks) under consideration of
interdependencies between different product lines and the
company-wide reporting guidelines.
…
Functional …
3 … … IT …
Direct relationships to other projects / topics Type
1 Flexible data management in a single data source Predecessor
2 … Predecessor
Further comments
…
Because the project framework so far only structured projects
and did not contain information about
priorities or interactions, we extended the project framework to
indicate priorities via colors and to arrange

all projects referring to a distinct process in a pseudo-sequential
order using numbers and letters (Figure
4). Colors indicate the priority of distinct processes as a
foundation for deriving transformation roadmaps.
In line with the quantitative rating of the gaps conducted in the
second phase, colors indicate whether the
implementation of a distinct project is of very high importance
(“red”), high importance (“orange”), or
medium importance (“yellow”). The more important the projects
related to a distinct process, the higher
the process’s priority. In Figure 5, it would be more important
to implement projects related to risk
management than projects related to tax management. Because
business transformation projects are not
restricted to a single process at a time, the number of processes
that one may address in parallel depends
on the resources available, the results of business case analyses,
and other ongoing projects. Numbers
help cluster projects into rollout waves. Using the numbers 1 to
3, we suggest implementing projects
marked with “1” before “2,” and “2” before “3.” If appropriate,
one can also have more than three

implementation waves. In a rollout wave, one may further
prioritize projects using small letters because
some projects may be important (i.e., the associated cell in the
project framework is red) but need to
implement other potentially less-important projects beforehand
(e.g., to comply with
successor/predecessor relationships). One can implement a
project that has only a number assigned at
any point in the associated rollout wave. In this case, the colors
may help determine in what order to
implement the projects. Consequently, the project framework
does not only contain a single project
sequence. Rather, it allows one to derive multiple
transformation roadmaps that one can adjust to new
information and to changing market environments and
management priorities.
Based on our assessment in the second phase, we identified gaps
with respect to finance processes such

as consolidation, internal charging, inventory valuation, risk
management, and tax management.
Furthermore, we identified cross-process topics such as data
management, advanced analytics, and
advanced reporting. This resulted in a project framework similar
to that shown in Figure 5. For
confidentiality, we cannot show the complete project framework
developed during the finance IT roadmap
project at Infineon. Due to the cross-process nature of the
identified topics, numerous admissible project
sequences comply with the successor/predecessor relationships
that one can compile into concrete
transformation roadmaps. Each transformation roadmap
candidate reflects different management
priorities regarding cross-process topics and finance processes.
Figure 5. Project Framework used for Infineon’s Finance IT
Roadmap Project (Partly Anonymized)
4 Lessons Learned from the Case
Based on the experience gained throughout the finance IT
roadmap project, we identified four major
lessons learned in project post-completion reviews both in the

academic project team and with the entire
core team. Therefore, the lessons learned include the entire core
team’s assessment (i.e., four academic
team members and four corporate team members). Because the
corporate team members worked for
Infineon’s financial management and IT department (even in
different areas of these departments), the
lessons learned reflect all relevant stakeholder groups’
assessments.
1. Well prepared is half-transformed: one of the most
challenging tasks in the finance IT
roadmap project was to derive the high-level requirements that
characterize the finance IT
target setup on different layers of the enterprise architecture
and, in particular, to
operationalize these high-level requirements in terms of low-
level requirements. At first, we

planned to derive requirements in a few weeks. However, we
realized quickly that this task was
more complex than anticipated and, in line with the critical
importance of the requirements for
validating our project outcomes, we decided to take much more
time to specify the
requirements. As such, we could incorporate the latest research
results regarding IT-supported
value-based management into the high- and low-level
requirements. Moreover, we ensured
that the low-level requirements covered all services from
Infineon’s finance service catalog,
had an appropriate level of abstraction, and were written to be
easily understandable by the
intended interviewees. To ensure the validity and
appropriateness of our requirements, we
conducted multiple review rounds with the corporate project
team members. We also took the
time to map low-level requirements to not only different layers
of the enterprise architecture but
also Infineon’s finance service catalog. Thus, we ensured that
the interviewees were

confronted with requirements only from their area of expertise.
Our experience throughout the
interviews and, even more importantly, from identifying
projects based on the interview results
and presenting how we derived the project framework showed
that this additional investment
was worthwhile. In the end, it took about two months to define
and validate the low-level
requirements. If we had stuck with the initial project plan (a
few weeks for the same task), the
project outcome would have been much less sophisticated.
2. Let corporate and academic project team members conduct
the interviews: the
interviews we conducted were challenging. On the one hand,
interviewees had deep
knowledge regarding tasks in their area of expertise and
extensive implicit knowledge about
how Infineon as a company behaved, which occasionally
complicated how we interpreted what
the interviewees said. On the other hand, we had to make the
purpose of the finance IT
roadmap project clear and acquire as much information as
possible from the interviewees in
quite a short timeframe. Against this backdrop, both corporate

and academic project team
members conducted the interviews. The academic team members
were more familiar with
interview techniques and could take on the neutral perspective
of outside observers. Due to
the personal relationship between the corporate project team
members (who were themselves
department heads) and the interviewees, we could quickly
establish a trusting atmosphere and
received constructive and reliable information. The corporate
project team members also
served as “translators” among the interviewees and the
academic team members when we
needed additional knowledge to correctly grasp the meaning of
some statements made
throughout the interviews. If only academic team members had
conducted the interviews, the
corporate team members (particularly the department heads)
would have saved a significant
amount of time. However, we would have missed relevant hints,
particularly with respect to the
open-ended follow-up questions, which pointed to gaps of the
finance IT setup. If only
corporate core team members had conducted the interviews, the
interviews would have been

biased towards those problems and ideas the corporate team
members already had in mind,
which would have significantly impacted the project’s
credibility because Infineon considered
the neutral academic perspective an important factor for its
finance IT roadmap project.
3. Establish a central transformation governance entity:
successfully implementing a
business transformation project requires a central governance
entity for multiple reasons. First,
business transformation projects require team members from
different business and IT
departments and internal and external project team members to
be coordinated. Second, the
interactions in the project portfolio must be managed centrally
to be able to react to changes in
management priorities and the business environment. Third,
only a central governance entity
can further develop the project framework and transformation
roadmap, monitor the
implementation progress, and decide how to proceed in case of
multiple alternatives. Fourth,
such a central entity can serve as a single point of contact for
business and IT departments. In

this capacity, it must collect and prioritize change requests that
originate from the operational
business and affect the transformation endeavor. In the finance
IT roadmap project, we
established such a central project governance entity, the finance
IT office, which included
experienced finance and IT experts from all involved
organizational entities such as central
services, divisions, operations, and regions. Establishing the
finance IT roadmap was essential
for anchoring the finance IT roadmap in Infineon’s
organization. Otherwise, it would have been
unclear which organizational entity should take on
responsibility for the finance IT roadmap, a
circumstance that would have impeded the transformation of
Infineon’s finance IT setup.
4. Provide more than one transformation roadmap: the main
outcome of the finance IT
roadmap project was a project framework that helped Infineon
document project portfolios in a

parsimonious manner and derive concrete transformation
roadmaps. When developing the
project framework, we refrained from proposing a single
roadmap for transforming the existing
finance IT setup into the finance IT target setup. We knew that
a single roadmap would simply
not have been enough, particularly in a dynamic environment
such as the semiconductor
industry whose business environment may change quickly and
whose business cycles heavily
impact companies’ priorities and project budgets. To prevent
the transformation roadmap from
ending up as a “paper tiger” in the drawer of some senior
managers, we needed to make the
transformation roadmaps easily adaptable, which is why we not
only specified projects but also
considered interactions among projects and management
priorities. Of course, a single
transformation roadmap would have been much easier to derive

and communicate, but a
single roadmap for Infineon would have been had much less
utility, particularly if one considers
the long planning horizon of the transformation of Infineon’s
finance IT setup and the demand-
and supply-side challenges on financial management in the
semiconductor industry.
5 Conclusion
Despite their importance for organizational change and the high
failure rates, little guidance on how to
structure business transformation projects exists. To share first-
hand experience and to stimulate related
research, we report on a project with Infineon Technologies in
which we co-developed Infineon’s finance
IT roadmap. The finance IT roadmap served as foundation for
transforming Infineon’s finance IT setup to
tackle future challenges of financial management in the
semiconductor industry from a business, process,
and IT perspective. We outline the objectives, main tasks, and
outcomes of all project phases and reflect
on lessons learned from the Infineon case. The case of the
finance IT roadmap project also showcased
that project teams comprising corporate and academic members

can tackle challenges that neither
corporate nor academic teams would be able to tackle alone. We
confirmed this assessment for the
finance IT roadmap project in the post-completion reviews we
conducted.
As inherent to case descriptions, our insights are limited to the
Infineon case. From a research
perspective, it would be interesting to advance the ideas
developed in the finance IT roadmap project
towards a full-fledged method for structuring business
transformation projects using, for example,
situational method engineering as research method. To do so,
researchers should discover which parts
and to which extent one needs to abstract a project’s main tasks
and the tools used to document
intermediate or final results (e.g., the catalog of high- and low-
level requirements, the fulfillment-
importance matrix, or the modular project) such that they apply
to other project contexts. Researchers
should also investigate which parts of the resulting method
should be customizable with respect to
different contexts and which factors drive customization.
Experience from similar projects would be
extremely helpful as well.

Despite the single-case character of this study, we hope that the
presented experience from the finance IT
roadmap project, the ideas on how to structure business
transformation projects, and the lessons learned
help corporate transformation managers and researches until we
see further development from a research
perspective.
References
Abraham, C., & Junglas, I. (2011). From cacophony to
harmony: A case study about the IS
implementation process as an opportunity for organizational
transformation at Sentara healthcare.
The Journal of Strategic Information Systems, 20(2), 177-197.

Abraham, R., Aier, S., & Winter, R. (2015). Crossing the line:
Overcoming knowledge boundaries in
enterprise transformation. Business & Information Systems
Engineering, 57(1), 3-13.
Aretz, K., & Bartram, S. M. (2010). Corporate hedging and
shareholder value. Journal of Financial
Research, 33(4), 317-371.
Bardhan, I., Bagchi, S., & Sougstad, R. (2004). Prioritizing a
portfolio of information technology investment
projects. Journal of Management Information Systems, 21(2),
33-60.
Braun, C., & Winter, R. (2007). Integration of IT service
management into enterprise architecture. In
Proceedings of the 2007 ACM Symposium on Applied
Computing (pp. 1215-1219).
Dehning, B., Richardson, V. J., & Zmud, R. W. (2003). The
value relevance of announcements of
transformational information technology investments. MIS
Quarterly, 27(4), 637-656.

Fonstad, N. O., & Robertson, D. (2006). Transforming a
company, project by project: The IT engagement
model. MIS Quarterly Executive, 5(1), 1-14.
Gartner. (2015). Gartner magic quadrant. Retrieved from
http://www.gartner.com/technology/
research/methodologies/research_mq.jsp
Ghasemzadeh, F., & Archer, N. P. (2000). Project portfolio
selection through decision support. Decision
Support Systems, 29(1), 73-88.
Hahn, G. J., & Kuhn, H. (2012). Designing decision support
systems for value-based management: A
survey and an architecture. Decision Support Systems, 53(3),
591-598.
Malmi, T., & Ikäheimo, S. (2003). Value based management
practices—some evidence from the field.
Management Accounting Research, 14(3), 235-254.
Martinsuo, M. (2013). Project portfolio management in practice
and in context. International Journal of
Project Management, 31(6), 794-803.

Morgan, R. E., & Page, K. (2008). Managing business
transformation to deliver strategic agility. Strategic
Change, 17(5-6), 155-168.
Morris, P. W. G., & Jamieson, A. (2005). Moving from
corporate strategy to project strategy. Project
Management Journal, 36(4). 5-18.
Nelson, R. R., & Morris, M. G. (2014). IT project estimation:
Contemporary practices and management
guidelines. MIS Quarterly Executive, 13(1), 15-30.
Patanakul, P., & Shenhar, A. J. (2012). What project strategy
really is: The fundamental building block in
strategic project management. Project Management Journal,
43(1), 4-20.
Project Management Institute. (2013). A guide to the project
management body of knowledge (PMBOK
guide). Newton Square.
Rappaport, A. (1986). Creating shareholder value: The new
standard for business performance. New
York, NY: Free Press.

Rosemann, M., Recker, J., Safrudin, N., & Marketsmueller, R.
(2012). Program and project management.
In A. Uhl, & L. A. Gollenia (Eds.), A handbook of business
transformation management
methodology. Farnham, UK: Gower Publishing.
Rouse, B. W. (2005). A theory of enterprise transformation.
Systems Engineering, 8(4), 279-295.
Safrudin, N., Rosemann, M., Recker, J., & Genrich, M. (2014).
A typology of business transformations.
360°—the Business Transformation Journal, 10, 25-41.
Stiles, P., Uhl, A., & Stratil, P. (2012). Meta management. In A.
Uhl, & L. A. Gollenia (Eds.), A handbook of
business transformation management methodology. Farnham,
UK: Gower Publishing.

The Standish Group. (2013). Chaos manifesto 2013—think big,
act small. Retrieved from
https://larlet.fr/static/david/stream/ChaosManifesto2013.pdf
Uhl, A., & Gollenia, L. A. (2012). A handbook of business
transformation management methodology.
Farnham, UK: Gower Publishing.
Wagner, H.-T., & Weitzel, T. (2012). How to achieve
operational business-IT alignment: Insights from a
global aerospace firm. MIS Quarterly Executive, 11(1), 25-36.
Winter, R., & Schelp, J. (2008). Enterprise architecture
governance: The need for a business-to-IT
method. In Proceedings of the 2008 ACM Symposium on
Applied Computing (pp. 548-552).
Wu, W. W., Rose, G, M., & Lyytinen K. (2011). Recognizing
and managing innovation points in large IT
projects. MIS Quarterly Executive, 10(3), 121-132.

About the Authors
Maximilian Röglinger is an Associate Professor of Information
Systems at the University of Bayreuth.
Maximilian serves as Deputy Academic Director of the
Research Center Finance & Information
Management (FIM), where he co-heads the research group on
customer relationship and business
process management. Maximilian also works with the Project
Group Business & Information Systems
Engineering of the Fraunhofer FIT. Most of his work centers
around business process management,
customer relationship management, and digital transformation.
He publishes in journals such as Business
& Information Systems Engineering, Business Process
Management Journal, Decision Support Systems,
Journal of the Association for Information Systems, and Journal
of Strategic Information Systems.
Maximilian is highly engaged in projects with companies such

as Deutsche Bank, Infineon Technologies,
Radeberger Group, and Siemens. He earned his PhD at the
University of Augsburg, and holds a Diploma
in Business & Information Systems Engineering from the
University of Bamberg.
Manuel Bolsinger studied Business Mathematics (BSc) and
Finance & Information Management (MSc)
at the University of Augsburg and at the TU München,
respectively. From 2010 to 2015, Manuel worked
as a research associate at the Research Center Finance &
Information Management (FIM), where he
finished his doctoral thesis on value-based business process
management in 2014. During his doctoral
studies, he collaborated with various industry partners such as
Infineon Technologies, Hilti, and
GEWOFAG Holding.
Björn Häckel is an Interim Professor of Business Engineering
with a major in Finance, Operations, and
Information Management at the University of Augsburg. Björn
serves as Deputy Academic Director of the
Research Center Finance & Information Management (FIM),

where he heads the research group "IT-
based Financial Management". He also works with the Project
Group Business & Information Systems
Engineering of the Fraunhofer FIT. His research topics include
the application of financial methods to the
evaluation and management of IT investments and IT portfolios.
Moreover, he is working on the IT-
enabled identification, quantification, and management of
systemic risk in value networks. He publishes in
journals like Business & Information Systems Engineering,
Decision Support Systems, Electronic Markets,
Journal of Decision Systems, Journal of Innovation and
Technology Management, and The Data Base for
Advances in Information Systems. He is highly engaged in
projects with companies such as BMW
Financial Services, Carl Zeiss, Deutsche Bank, and Infineon
Technologies. He earned his PhD at the
University of Augsburg, and holds a Diploma in Business
Administration from the University of Augsburg.
Matthias Walter studied Business Administration at the
University of Augsburg with major in Finance &
Information Management. Since 2010, he has worked as a
research associate at the Research Center

Finance & Information Management (FIM), where he finished
his doctoral thesis on risk management in
late 2015. During his doctoral studies, he further collaborated
with industry partners such as GEWOFAG,
Infineon Technologies, and Radeberger Group.
Copyright © 2016 by the Association for Information Systems.
Permission to make digital or hard copies of
all or part of this work for personal or classroom use is granted
without fee provided that copies are not
made or distributed for profit or commercial advantage and that
copies bear this notice and full citation on
the first page. Copyright for components of this work owned by
others than the Association for Information
Systems must be honored. Abstracting with credit is permitted.
To copy otherwise, to republish, to post on
servers, or to redistribute to lists requires prior specific

permission and/or fee. Request permission to
publish from: AIS Administrative Office, P.O. Box 2712
Atlanta, GA, 30301-2712 Attn: Reprints or via e-
mail from [email protected]
Reproduced with permission of the copyright owner. Further
reproduction prohibited without
permission.
How Multinational Corporations Use Information Technology to
Manage Global
Operations
Jonathan Whitakera, Peter Ekmanb, and Steve Thompsona
aUniversity of Richmond, Richmond, VA, USA; bMälardalen
University, Västeräs, Sweden
ABSTRACT
Despite a generally acknowledged importance of information
technology (IT) in enabling global strategy

and a broad understanding of the manner in which IT enhances
coordination and reduces cost, few
studies have focused precisely on how multinational
corporations (MNCs) use IT to facilitate globaliza-
tion. To address this gap in the literature, we conduct a case
study across four large MNCs, and use
primary data to develop predictive propositions on the
characteristics of products, processes, and
customers that impact the ways in which MNCs use IT to
manage their global operations.
KEYWORDS
Multinational; MNC;
international; information
technology; global
Introduction
Over the past 50 years, international markets have contributed
an increasing share of revenues and profits for multinational
corporations (MNCs). For example, the share of international
profits as a percentage of total profits for US firms rose from
5%
in the 1960s to over 25% during the 2000s [1]. The increase has
been particularly dramatic over the past decade, as US corporate

overseas profits increased at a double-digit pace for 22 consecu-
tive quarters [49]. US firms have also found higher returns on
sales in foreign markets than in domestic markets, and less
variability in earnings compared with domestic operations [18].
This trend is expected to continue and accelerate in the
future, because globalization is an important vehicle for MNCs
to manage revenue growth and cost reduction. Globalization
provides opportunities for revenue growth by expanding opera-
tions into new geographical areas, and opportunities to reduce
costs and increase profitability through economies of scale and
scope [4]. It presents multinational firms with strategic oppor-
tunities that are not available to purely domestic firms, such as
the ability to acquire inputs from multiple locations and serve
diverse markets [2]. Globalization also enables firms to access
global availability of talent to reduce cycle time, spur
innovation,
and maintain or improve quality [29]. Among the 30 companies
in the Dow Jones Industrial Average, the 10 that get the largest
share of their sales abroad were expected to see revenues grow
by
an average of 8.3%, and the 10 that do the least business outside
the US were expected to showmuch lower average revenue gains
of 1.6% [27].

However, the advantages associated with globalization come
with several risks in managing business operations across coun-
try borders. A presence in diverse locations presents MNCs
with higher levels of complexity, variability, unfamiliarity, and
uncertainty [52]. Entry into foreign markets creates local adap-
tation costs, and location differences create difficulties to
transfer products, services, processes, and information between
headquarters and subsidiaries in various countries. Executives
at MNCs face the challenge of managing the operations of their
subsidiaries with each other and with headquarters to admin-
ister the firm as a coordinated global network [11]. To manage
these risks and achieve the desired level of administrative
coordination, firms deploy a wide range of mechanisms, of
which several include a critical role for information technology
(IT) systems [19]. Despite a generally acknowledged impor-
tance of IT in enabling global strategy and a broad under-
standing of the manner in which IT enhances coordination
and reduces cost, few studies have focused precisely on how
MNCs use IT to facilitate globalization [36].
The purpose of this article is to build depth and under-
standing for the mechanisms through which MNCs use IT to
facilitate globalization. We use case study data derived from
interviews with the top IT and business executives in four

large MNCs to identify differences in application of the
mechanisms. This article contributes to research and practice.
From a research perspective, this article more clearly illus-
trates the theoretical mechanisms of value chain configura-
tion, value chain coordination, and local responsiveness that
have been identified in prior research. Based on these theore-
tical mechanisms, this article also develops three predictive
propositions that will enable researchers to extend their study
of IT and globalization. From a practice perspective, our case
studies demonstrate that the manner in which global firms
use IT will vary based on the type of product, type of process,
and type of customer.
Background and theoretical framework
IT enables firms to globalize their operations and achieve
foreign revenues and foreign profits through three mechan-
isms—value chain configuration, value chain coordination,
CONTACT Jonathan Whitaker [email protected] University of
Richmond, Management Department, Robins School of
Business, 1 Gateway Road,
Richmond, VA 23173, USA.
JOURNAL OF COMPUTER INFORMATION SYSTEMS

2017, VOL. 57, NO. 2, 112–122
http://dx.doi.org/10.1080/08874417.2016.1183426
© 2017 International Association for Computer Information
Systems
and local responsiveness. Value chain coordination refers to
the coordination of similar value chain activities (such as
procurement or production) across different geographic loca-
tions, and involves the management of information to make
decisions related to the activities and the management of
knowledge and resources necessary to perform the activities
[38]. IT systems facilitate value chain coordination and
knowledge flows through the provision of rich transmission
channels and knowledge management systems for the transfer
and absorption of knowledge by headquarters and subsidi-
aries. IT systems greatly expand the type, frequency, speed,
and volume with which MNCs can input, store, extract, and
exchange structured information and unstructured knowledge
throughout the firm [12]. The systems enable firms to com-
municate knowledge to personnel in headquarters or subsidi-
aries who have the best experience and capabilities to make
specific decisions, and provide infrastructure to share, distri-

bute, and absorb knowledge across geographic and functional
boundaries, and to coordinate activities and develop strategic
opportunities [20].
Value chain configuration refers to the manner in which
firms build the capacity to perform value chain activities
globally and disperse those activities across different geo-
graphic locations [26]. By reconfiguring its value chain activ-
ities, a firm can achieve efficiencies through centralized
administrative coordination, control of resources, and perfor-
mance measurement [45], and can produce and innovate in
low-cost markets and sell in high-return markets. Firms can
use IT to extract information and knowledge components of
production inputs and business processes, and move those
components around the world to perform each value chain
activity in the location where it can be best accomplished [34].
IT systems enable MNCs to treat subsidiaries as component
pieces, which allows firms to locate activities across subsidi-
aries and geographies as appropriate [15]. In local responsive-
ness, firms implement changes in product features,
production and distribution approaches, advertising messages,
and pricing to tailor for local markets [40]. IT systems are an
integral component of local responsiveness [31]. Firms can
use their IT and communications architecture to draw
together marketing, research and development (R&D), and

production experts with the unique skills and knowledge of
a particular local market, which enables the firm to respond
and adapt to products and services that are tailored for cus-
tomers in that market [42].
While early global IT research [21] generated helpful
insights by mapping IT configurations to the traditional strat-
egy typologies of multi-domestic, global, international, and
transnational1 [3], subsequent research notes the need to
progress beyond the typologies for at least three reasons.
First, typologies with a limited number of options may not
be able to explain the full set of considerations firms use to
organize their foreign subsidiaries and global IT operations
[10]. Second, IT has increased the ability of firms to simulta-
neously achieve a degree of global efficiencies and local
responsiveness, which are the traditional strategy tradeoffs
[47]. As more firms use IT to pursue global efficiencies and
local responsiveness, traditional strategies increasingly
become blurred [42]. Third, the strategy typologies are diffi-
cult to operationalize, and there may be differences between a
firm’s actual positioning and its aspiration [25]. Therefore, to
complement prior research and generate further insights on
global IT, we categorize firms based on more objective mea-
sures from prior research, such as whether the firm’s primary

product is durable versus nondurable, and whether the end
user for the firm’s primary product is industrial customers or
individual consumers. Because IT powers multiple processes
across the firm, we perform our analysis based on a distinc-
tion between front-office processes and back-office processes.
Below we provide further background on the distinctions
between types of goods, customers, and processes.
Durable goods and nondurable goods
Firms can be classified based on the nature of their products
and services. For example, manufacturing firms can be classi-
fied based on whether they make durable goods or nondur-
able goods. Durable goods last for a longer period of time and
nondurable goods last for a more limited period, and the
stability of prices for durable goods is greater than the stability
of prices for nondurable goods [28]. The nature of goods
impacts processes throughout the firm. Firms that manufac-
ture durable goods must allocate more resources to R&D and
emphasize production efficiency and product quality [16].
Firms that manufacture nondurable goods must focus on
the acquisition of market share through competitive pricing,
and the constant development of additional markets [13]. As
we will discuss below, the use and impacts of IT can differ
based on the nature of products and services produced by the

firm [53].
Industrial customers and individual consumers
Firms can also be classified based on whether the end users of
their products are industrial customers or individual consu-
mers. The market for industrial customers is more concen-
trated than the market for individual consumers [50].
Industrial customers have larger transaction volumes per cus-
tomer, while individual consumers have intermittent transac-
tions with lower dollar values per transaction. While
industrial products are more standardized because technical
specifications do not vary across countries [5], consumer
products are less standardized because consumer preferences
are more idiosyncratic to local cultures and tastes [46]. Firm
relationships with industrial customers are more prevalent,
complex, balanced, and long-standing than relationships
with individual consumers [17].
1A multi-domestic strategy is based on a portfolio of
autonomous domestic companies with a focus on local
responsiveness, an international strategy is
based on home country expertise with a focus on control, a
global strategy is based on scale economies with a focus on
integration, and a transnational

strategy is based on a headquarters-subsidiary network with a
simultaneous focus on global integration and local
responsiveness [3].
JOURNAL OF COMPUTER INFORMATION SYSTEMS 113
Front-office and back-office processes
The operations of a firm can be viewed as two sets of business
processes—front-office processes and back-office processes
[41]. Front-office processes are those through which the
firm interacts directly with the customer, and include market-
ing, sales, and service. While back-office processes are also
important to the firm’s operations, they do not interact
directly with the customer. Back-office processes include
finance, accounting, IT, and human resources (HR). The
extent of customer contact influences the challenges inherent
in each set of processes and the resulting focus of the firm
[56]. Front-office processes must cope with uncertainty result-
ing from customer involvement and unique requests, which
create inefficiencies and increase operating costs. Firms must
configure their front-office processes to address the human
relations aspect of customer contact, and to be flexible to

customize products and services to customer requirements
[37]. Because customers do not directly interact with back-
office processes, customers may not perceive back-office pro-
cesses as part of the firm’s value proposition. This places
pressure on firms to standardize and automate to enhance
the efficiency and effectiveness of back-office processes. Firms
generally make larger capital investments related to back-
office processes compared with front-office processes, with
the objective to reduce the long-term cost of back-office
processes [44].
Methodology and case study firms
We designed this research project as a multi-case study. Case
studies involve a holistic, in-depth investigation of phenom-
ena that cannot be studied independently from the context in
which they occur [39]. The use of multiple cases enables
cross-analysis of a phenomenon in diverse settings, which
increases the volume of evidence and robustness of findings
[9]. It is desirable to have a common context across cases, to
provide a degree of consistency for comparison and contrast,
and some control factors that allow for generalization [8].
Multi-case studies focus on analytical generalization rather
than statistical generalization to the full population [23].

Our selection of four cases for this article is consistent with
the recommendation of four to five cases for multi-case study
research [7], and with the guidance that fewer than four cases
may lack empirical grounding [8]. We agreed to provide con-
fidentiality to our case study firms, and we do not disclose the
identity of the firms in this article. One firm manufactures and
sells finished equipment to industrial customers, and we call
this “Equipment firm” in this article. The second firm manu-
factures and sells components to industrial customers, and we
call this “Parts firm.” The third firm manufacturers and sells
durable household goods, and we call this “Household Goods
firm.” The fourth firm manufactures and sells consumer pro-
ducts, and we call this “Consumer Products firm.”
The four firms in our study have a common context. All
four firms are included on the 2011 Forbes Global 2000 list of
the world’s largest publicly traded firms, and have annual
revenue of over US$1 billion. All four firms are headquartered
in Northern Europe, have over 50% of sales outside the home
country, and have Europe and North America as two of their
top three sales markets. The equities of all four firms are
publicly traded on European and US exchanges. Our unit of
analysis is the firm, with the European headquarters and
North American subsidiary of each firm as subunits of ana-

lysis. Table 1 shows a profile of our four case study firms.
While our case study firms have a common context to
allow for comparison and contrast, they also represent diverse
settings to explore the manner in which MNCs use IT to
coordinate global operations. Equipment firm and
Household Goods firm manufacture durable products, and
Parts firm and Consumer Products firm manufacture non-
durable products. Equipment firm and Parts firm products are
used by industrial customers, and Household Goods firm and
Consumer Products firm products are used by individual
consumers. Applying the criteria discussed above to segment
firms based on the nature of products and nature of custo-
mers, Table 2 shows that we have one firm in each quadrant.
We adopted the positivist approach in this research,
because we believe the manner in which MNCs use IT to
coordinate global operations is an objective phenomenon that
can be identified by deductive logic, and that can be accu-
rately described by senior executives in our case study firms
with limited room for interview participants to construct their
own meaning [39]. Based on the positivist approach, our goal
was to combine data sources from the European headquarters
and US subsidiary of our case study firms to arrive at a unified
set of insights for the manner in which MNCs use IT to

coordinate global operations. Consistent with one appropriate
application of case study research, we use data from our case
study firms to develop predictive propositions that can be
tested in future empirical research [55].
Table 1. Corporate profile of case study firms.
Equipment firm Parts firm Household Goods firm Consumer
Products firm
2011 Forbes Global 2000 rank Top 1000 Top 1000 Top 1000
Top 2000
Annual revenue US$5+ billion US$5+ billion US$10+ billion
US$1+ billion
Founded 1800s Early 1900s Early 1900s Early 1900s
Employees 10,000+ 30,000+ 50,000+ 3,000+
Countries with operations 10+ 25+ 50+ 20+
Countries with mfg. facilities 10+ 15+ 15+ 5+
Largest market Asia Europe North America Europe
2nd largest market Europe Asia Europe North America
3rd largest market North America North America Latin America
Rest of world
Notes: Data in this table is based primarily on each firm’s 2010
annual report, which is closest in time to data collection for this

research project.
Approximations are intended to maintain anonymity of the case
study firms.
114 J. WHITAKER ET AL.
Similar to the majority of published IS case studies, we
used face-to-face, in-depth, semi-structured interviews as our
primary source of data. In-depth interviews enable researchers
to understand participant descriptions and accounts of actions
and events [54]. We conducted a total of 21 interviews with 18
interviewees, at the level of three to five interviews per case
and a threshold of 20 total interviews recommended by [7].
Even more important than meeting the recommended thresh-
old is our belief that that the number of interviews enabled us
to receive a complete picture of IT operations at the European
headquarters and North American subsidiaries for our case
study firms [32]. An important element that strengthens the
validity of our data is that we interviewed senior executives
that have the most accurate and comprehensive understand-
ing of IT and business strategy at each firm [48]. For example,
we interviewed the Chief Information Officer (CIO) for all
four firms, and also conducted interviews with other senior

executives with titles such as Chief Technology Officer (CTO),
Deputy CIO, Regional CIO, Regional IT Vice President (VP),
Regional Director, and Regional Controller. Table 3 provides
a list of interviewees for our case study firms. In addition to
the interviews, members of the research team reviewed some
information in annual reports, news coverage, and websites to
learn more about the firms and to provide context for case
study material. Given the extended timeframe of multiyear IT
implementations at our case study firms, observation was not
a suitable method to collect data for this research project.
In most cases, the research team initially contacted the
CIO, and the CIO provided access and introduction to other
IT and business executives in Europe and the US. Most inter-
views were conducted in person at the executive’s offices in
Europe and the US, most interviews lasted between one and
two hours, and most interviews involved more than one
member of the research team. While most executives were
interviewed once, some executives were interviewed multiple
times. The research team followed a consistent interview
pattern across firms by first meeting with European head-
quarters personnel, then meeting with US subsidiary person-
nel, and then meeting again with European personnel. Most
interviews were conducted over a period of 15 months from

March 2009 to June 2010.
We used semi-structured interviews because we were
familiar with the questions to be asked but unable to predict
the answers, and semi-structured interviews enable research-
ers to obtain the required information while giving partici-
pants freedom to respond and illustrate concepts [39]. Before
the interviews, the research team prepared structured inter-
view guides to ensure that all important issues were covered
during the interviews and to increase comparability across
firms. Consistent with strategy research that identifies differ-
ences between headquarters and subsidiaries, the research
team formulated different research questions for European
headquarters and US subsidiary personnel to capture their
respective perspectives on global business processes and IT
operations [14]. The main questionnaire items shown in
Appendix A are consistent with prior research on the role of
headquarters in an MNC [6], relationship between headquar-
ters and subsidiaries [30], information exchanged between
headquarters and subsidiaries [24], responsibilities and deci-
sion-making between headquarters and subsidiaries [33],
business functions in an MNC [41], role of IT in an MNC
[2], and types of IT infrastructure and applications in an
MNC [22].

Some interviewees showed and discussed confidential
materials during the interviews (for example, one CIO pre-
sented material that was to be discussed with the Board of
Directors the following week). While the research team took
active notes on these materials during the interviews, we did
not receive a paper or electronic copy of confidential materi-
als. Shortly after each interview, a research team member
prepared detailed notes from the interview [54]. Other team
member(s) who attended the interview reviewed, refined, and
added to the interview notes as necessary. The detailed notes
for each interview were then finalized and maintained in a
case collection. We added some background material to the
first set of interview notes for each firm, including items such
as company and financial information, news coverage, and
professional background on the interviewee. Total notes
across the four firms included approximately 100 single-
space pages containing 45,000 words.
The active involvement of multiple research team members
in interviews strengthened the validity of data. In addition to
triangulation of investigators in data collection, we triangu-
lated data across interviewees and firms and maintained a
linkage among research questions, data, and conclusions.
Before we discuss the analysis and predictive propositions,
we begin with a brief summary of each firm in our case study.

Equipment firm
Equipment firm is the second largest business unit of a global
equipment firm that was founded during the 1800s, and is one
of the world’s four largest firms in this segment. Equipment
firm sells to industrial customers through independent and
firm-owned dealerships. Asia is the leading market for
Equipment firm, Europe is the second leading market, and
North America is the third leading market. While Equipment
Table 3. List of interviewees.
Europe North America
Equipment firm Global CIO Regional IT VP
Regional CIO Regional IT VP
Parts firm Global CIO Regional Controller
Deputy CIO (2) Regional Controller
Household Goods firm Global CIO (3) Regional IT Director
Global CTO Regional Controller
Global IT Director (2)

Consumer Products firm Global CIO Regional CIO
Deputy CIO (2) Regional Director
Regional Director
Notes: Numbers in parentheses indicate multiple meetings with
an interviewee.
Four interviews included two simultaneous participants from the
case study firm.
The Global CIO of Parts firm departed the firm during the
research project.
The Global CIO of Consumer Products firm joined the firm
during the research
project.
Table 2. Categorization of firms by product and customer
characteristics.
Industrial customer Individual consumer
Durable product Equipment firm Household Goods firm
Nondurable product Parts firm Consumer Products firm

firm manufactures most products for the North American
market in three manufacturing facilities throughout the
Americas, some large equipment products are manufactured
only in Asia and then imported to North America. In terms of
corporate strategy, Equipment firm is nearing completion of a
multi-decade transformation from specialty equipment provi-
der to total solution provider, and this transformation has
included multiple acquisitions of rival equipment firms to
complete the product portfolio. For example, Equipment
firm recently made a major acquisition in North America
and acquired majority ownership of an Asian firm. In terms
of organization structure, Equipment firm has reorganized
from a geographic structure to a functional structure to
encourage holistic business processes across regions. The
R&D function is responsible for developing new products,
the operations function is responsible for building products,
and the sales function is responsible for selling products. In
the reorganization, IT is a shared service across business
functions with approximately 200 IT personnel.
In terms of IT, Equipment firm initiated a major global
Enterprise Resource Planning (ERP) implementation during
the mid-2000s. The CIO communicated to our research team

that the implementation was 70% complete as of Summer 2010,
including the transition of legacy systems for some large acqui-
sitions. The ERP system includes modules for global supplier
and customer information, order handling and delivery, man-
ufacturing, finance, and HR. As Equipment firm progresses
with its ERP implementation, the firm is beginning to leverage
the ERP for global processes. For example, Equipment firm is
beginning to use the ERP to gain visibility to its global
customer
base to optimize pricing, visibility to its global supplier base to
optimize procurement, visibility to its global inventory and
manufacturing data to optimize production and inventory
management, and visibility to financial data to optimize profit-
ability. However, Equipment firm has not yet defined all of the
associated global processes. For example, Equipment firm has
not yet identified the global processes for customer informa-
tion, because dealers have historically been reluctant to provide
customer information to Equipment firm because they want to
protect their customer relationships.
Since Equipment firm sells a significant volume through
independent dealerships, Equipment firm faces the IT challenge
that dealer systems are not standardized and not consistently
integrated with Equipment firm throughout the dealer net-
work. The North American IT Director estimates that

Equipment firm is integrated with 40% of its dealers in that
market. Dealers who are integrated have visibility to Equipment
firm inventory and order status throughout the dealer network.
Equipment firm then has visibility to dealer stock and sales
data for Equipment firm products (some dealers also sell pro-
ducts from other firms). Equipment firm is implementing a
new dealer management system in Europe, and is encouraging
dealers to participate in the implementation so dealers can
check inventory and receive support from Equipment firm.
Parts firm
Parts firm was founded over 100 years ago, and quickly
became a global firm. Within 15 years, the firm’s sales force
covered 100 countries across five continents. Parts firm now
has over 100 manufacturing and operational sites in over 25
countries, and is supported by over 10,000 distributors in
another 100 countries. Europe is the leading market for
Parts firm, Asia is the second leading market, and North
America is the third leading market. Parts firm has grown
organically and through acquisitions. The firm sells four pro-
duct lines and is organized into three divisions with 40 seg-
ments based on the customer’s industry. In addition to the
divisional structure and customer-facing segments, Parts firm

has shared services organizations for back-office functions
such as finance and IT.
Given the variety of geographies, customer segments, and
product lines at Parts firm, the divisions operate in a fairly
autonomous manner. Core functions related to production,
such as R&D and manufacturing, are performed at the divi-
sional or segment level. The divisions require flexibility in
production and delivery because they need to adapt to rapidly
changing customer needs. There is some coordination
between divisions and headquarters on product-related func-
tions such as procurement and marketing, and more coordi-
nation on back-office functions such as finance. The divisions
transmit quarterly financial results to headquarters, and head-
quarters has a global financial system that synthesizes and
integrates the relevant data to provide a global view of finan-
cial performance.
The Parts firm IT organization and infrastructure mirrors
the corporate structure. Because of the decentralized nature of
R&D and manufacturing, and the flexibility required by the
divisions, each region and product line may have its own
process, applications, and data. For example, Parts firm is
required to maintain separate and secure data on its sales to
the US Department of Defense. The IT organization has 80

full-time equivalent staff at headquarters, and over 1,000 full-
time equivalent staff at over 300 locations around the world.
Because parts specifications can be fully defined and pub-
lished in a catalog, Parts firm is increasingly relying on elec-
tronic commerce sales in some product lines (over 50% of
total orders and approaching 100% for some niche segments).
While Parts firm is undertaking some projects to unify the IT
infrastructure, in other cases Parts firm has determined that it
is not worthwhile to centralize IT systems because the cost of
the required upgrades and implementation exceeds the scale
of the divisions and products.
Household Goods firm
Household Goods firm was founded almost 100 years ago,
and is one of the top three global firms in its industry. This
industry is heavily concentrated in manufacturing and sales
channels, and firms in this industry have faced significant
margin pressure in recent years. In response to the competi-
tive environment, Household Goods firm has adopted a focus
on cash flow and profitability. Household Goods firm is
currently organized based on four regions (Europe, North
America, Latin America, and Asia) and four functional areas
(Branding, HR, Finance, and Legal). While the regions are
currently autonomous and accountable for their own financial

performance, the firm is taking steps to move from a regional
116 J. WHITAKER ET AL.
structure to a centralized structure. The firm had developed
global councils to offer some central coordination for func-
tions such as procurement and marketing. During the time of
our case study, Household Goods firm moved beyond global
councils to name global directors for procurement, R&D, and
manufacturing. The firm is undertaking other initiatives to
centralize operations. For example, Household Goods firm is
considering ways to harmonize and share components in
products across regions, and will then investigate sharing
product platforms across regions. Household Goods firm is
also looking to establish global R&D centers of excellence for
each product type, and will then consider establishing global
manufacturing centers of excellence in cases where it is fea-
sible to manufacture and transport products and components
across geographies.
The IT organization and applications have closely followed
overall developments for Household Goods firm. As the firm
has faced increased margin pressure, the number of IT staff

has declined by 1/3 over the past decade, and the firm has
consolidated 60 data centers to two data centers over the past
three years. Household Goods firm currently has about 750 IT
employees, with 200 IT staff focused on IT architecture, 500
IT staff focused on IT applications, and 50 IT staff focused on
IT financial control. Consistent with its strategy to centralize
and standardize operations, the firm is undertaking a global
technology standardization project that is fully supported by
the CEO. Project objectives are to harmonize processes and
improve efficiency to strengthen controls, lower costs, manage
risks, and increase information transparency that will support
better decisions. Household Goods firm is progressing from
30–40 disparate ERP instances to a single ERP system
(although some locations may have a different implementa-
tion or instance) to achieve common master data, and the
project involves multiple functions including sales and order
processing, procurement, manufacturing, financials, and HR.
One function not planned for standardization is the manage-
ment of local sales channels.
Consumer Products firm
Consumer Products firm was founded almost 100 years ago,
and is a global leader in its segment. Northern Europe is the
largest market for Consumer Products firm, and the US is the

second largest market. The firm manufactures most products
in the region in which the products are sold. Consumer
Products firm believes it has significant potential to grow
market share and sales in the US, and it recently entered
into a joint venture with a larger firm to distribute its
products in countries outside of Northern Europe and the
US. In addition to market share and sales growth, Consumer
Products firm is pursuing global efficiencies and is in the
process of changing its organization from a regional structure
to a product structure.
Consistent with this change in organizational structure,
Consumer Products firm has combined its IT personnel into
a single global unit. There are approximately 50 IT personnel
at Consumer Products firm. While there are currently no
common IT applications or business processes between the
European headquarters and US subsidiary, the firm has an
objective to centralize the IT platform across geographies for
finance, manufacturing, marketing, and administration.
Consumer Products firm currently sends financial and market
share data from the plants and divisions to headquarters, and
has a high priority to develop a global supply chain system.
However, the firm will maintain unique sales and distribution
systems in each region. The different IT platform for sales and

distribution is consistent with the difference in business pro-
cesses and consumer preferences in the Northern European
and US markets. For example, in Northern Europe, Consumer
Products firm owns the distribution channel, and in the US
the product is distributed through independent distributors.
Consumer Products firm used IT to overcome an interest-
ing challenge in the US market, where a significant portion is
sold through small retailers and the product is not scanned
when sold. Because the product is not scanned, Consumer
Products firm is not able to receive or analyze consumer
purchase data from small retailers. Consumer Products firm
addressed the challenge by purchasing delivery data from the
independent distributors, not only for its products but also for
competitor products. The firm developed an application to
analyze data on its sales and competitor sales, and equips its
sales personnel with this data and analysis to provide con-
sultative selling and category management expertise to retai-
lers. This example illustrates the unique sales and marketing
challenges faced by Consumer Products firm in each market,
with the need for tailored IT systems to address market-
specific challenges. Table 4 provides a summary of the busi-
ness profile for each case study firm, and Table 5 provides a
summary of the IT profile for each case study firm.

Propositions
Building on prior research that describes the mechanisms
through which IT facilitates globalization, in this article we
enhance understanding of the contexts in which certain
mechanisms may be more applicable for firms with specific
Table 4. Business profile of case study firms.
Equipment firm Parts firm Household Goods firm Consumer
Products firm
Strategy Transformation from specialty to total
solution provider
Organic growth and acquisitions Industry under significant
margin pressure
Significant room for US sales and
market share growth
Structure Reorganized from geographic to
functional structure
Divisional structure based on

customer segments
Moving from regional to
global structure
Moving from regional to product
structure
Sales channel Sells through independent and firm-
owned dealerships
Sells primarily through
distributors
Sells primarily through large
retailers
Sells primarily through small retailers
in the US
IT organization Shared service across business
functions
Shared service across divisions Significant reduction in IT
staff

Combined IT personnel into single
global unit
characteristics. Below we provide evidence based on analysis
of our case study firms to develop three predictive proposi-
tions regarding the manner in which MNCs use IT to manage
global operations. These propositions can be tested in future
empirical research.
Value chain configuration
While IT systems enable MNCs to disperse value chain activ-
ities across geographic locations, the nature of IT use for value
chain configuration will vary based on the type of product.
Because durable goods require higher levels of R&D and
capital investment [16], durable goods manufacturers face
increased pressure to centralize production. Therefore, we
expect durable goods manufacturers to use IT to support
centralized production. The two durable goods manufacturers
in our case study have centralized production in low-cost

countries. Equipment firm produces its largest lines of equip-
ment in two low-cost countries, and Household Goods firm
has moved production to low-cost countries in recent years.
These durable goods manufacturers use IT to support the
centralization of production. For example, Equipment firm
uses information from sales and marketing (customer
demand, pricing, and aftermarket requirements) in the
R&D and manufacturing of new products. Equipment firm
has relied on acquisitions to round out its product portfolio,
and the firm implements its global ERP system to integrate
acquisitions into its global network. As Equipment firm
brings its operations and acquisitions onto its global ERP
system, it can leverage this data for the configuration of
other value chain activities. For example, Equipment firm
can use data on its global supplier base to optimize pro-
curement, data on its global customer base to optimize
pricing, data on global manufacturing to optimize produc-
tion and inventory management, and financial data to opti-
mize profitability. For products produced in the US,
Household Goods firm sources about 1/3 of its components
from low-cost countries. Household Goods firm is begin-
ning to look at ways to share components across regions,
with a long-term objective to share platforms across regions.
The movement of production and sourcing across regions,

JOURNAL OF INFORMATION TECHNOLOGY THEORY AND APPLICATION.docx

JOURNAL OF INFORMATION TECHNOLOGY THEORY AND APPLICATION.docx

Recommended

Recommended

More Related Content

Similar to JOURNAL OF INFORMATION TECHNOLOGY THEORY AND APPLICATION.docx

Similar to JOURNAL OF INFORMATION TECHNOLOGY THEORY AND APPLICATION.docx (20)

More from croysierkathey

More from croysierkathey (20)

Recently uploaded

Recently uploaded (20)

JOURNAL OF INFORMATION TECHNOLOGY THEORY AND APPLICATION.docx