97-094, Revised May 27, 1997

A Path-based Approach To
Information Technology in
Manufacturing

David M. Upton
Andrew P. McAfee

Copyright © 1997 David M. Upton and Andrew P. McAfee

Working papers are in draft form. This working paper is distributed for purposes of comment and discussion only.
It may not be reproduced without permission of the copyright holder. Copies of working papers are available from
the authors.
 A Path-based Approach to Information Technology in Manufacturing
David M. Upton
Andrew P. McAfee

1. Introduction
One of the most important changes in manufacturing in recent years has been the shift in the role of
operations managers from mere custodians of capital equipment, to one that emphasizes continuous
improvement and local invention. Manufacturers have realized that the key to creating competitive
advantage through operations lies in developing distinctive capabilities, rather than solely in
periodically buying the latest production equipment. Dogged, incremental improvement and an
increasing reliance on an internal capacity to hone and improve new process technology have
characterized the methods used for developing such capabilities. Many notable manufacturers have
made two benefits of this approach manifest. First, it makes ongoing improvement a part of
everyone’s job – not just that of a select few. Second, the deep knowledge that is developed allows
the operation to adapt to new requirements, remain flexible as business requirements change, and
develop new capabilities through experimentation and local invention.

Recent trends in the management of information systems in manufacturing companies, however,

reflect a change in the opposite direction, particularly for the set of technologies collectively
described as Enterprise Resource Planning systems. Enterprise Resource Planning (ERP) systems, as
the name suggests, pervade the whole company and shape the way the business works at many levels.
More and more manufacturing operations are installing ERP, and the development of information
systems in operations is increasingly characterized by very large implementation projects. The
systems installed are often complex and monolithic, making local experimentation (that might
improve performance or adapt to changing requirements) forbiddingly expensive and difficult. In
short, information systems in many manufacturing companies have come to mirror many of the
features traditionally associated with capital-intensive production equipment.

This trend is intriguing, given the increasing importance of information systems in manufacturing.
Current demands for increased long-term flexibility, broader product ranges, and rapid response all
require information systems that are adaptable and have the capacity to be molded to the changing
needs of the business.
 A Path-based Approach To Information Technology - 1

This paper explores this trend, and suggests some approaches that might be used by managers
concerned about its consequences for their operations. Section 2 reviews two archetypal models for
how improvement in operations is accomplished. Building from this, Section 3 proposes some
principles for the continuous improvement of manufacturing information systems and describes a
path-based model for developing them in a more flexible way. Section 4 examines the technology of
Enterprise Resource Planning (ERP) systems (an important and rapidly growing category of
manufacturing information systems) and looks at the reasons for their growth. Section 5 considers
how ERP systems and the recent modifications of their technology might affect the long-term
improvement paths of operations. Section 6 presents some conclusions, along with precautions that
managers might take to ensure that the benefits of ERP are realized without sacrificing long-term
flexibility.

2. Information Systems and Operations Improvement

2.1. Information Systems in Manufacturing

Much of the research to date at the intersection of operations improvement and advanced
manufacturing technology (AMT) has focussed on AMT that directly assists in the physical
transformation of materials, such as flexible manufacturing systems (Jaikumar (1986)), machine tools
(Hirschhorn and Mokray (1992)), and automated process control equipment (Zuboff (1988)). In
manufacturing-based research, comparatively less work has focused on operations information
systems, or the hardware and software used for the higher-level coordinative processes such as
production control, procurement or logistics. However, most sizable manufacturers use some form of
manufacturing resource planning (MRP) software, and employ a broad range of information
technology for financial systems, order fulfillment, production planning and scheduling, distribution
requirements planning (DRP), quality management, human resource management, and other similar
activities. These systems can be important determinants of manufacturing performance. Recently, a
growing number of companies have adopted large-scale enterprise resource planning (ERP) systems,
usually from one vendor, which subsume many of these functions. These systems and their growth
are described in greater detail below.

Because of the increasing pervasiveness and importance of information systems, IT management has
become inseparable from operations management for many companies. By 1996, for example, 87%
of operations managers cited at least a joint responsibility for IT decision-making (Fulcher (1996)).
However, at the same time as the importance of information technology has increased, has become
2 - A Path-based Approach To Information Technology

more distributed and has affected a broader range of business functions, the technology involved
increasingly demands knowledge that is distant from that imparted to traditionally-trained operations
and information systems managers. This has fuelled a trend towards the outsourcing of information
technology to external organizations (McFarlan and Nolan (1995)). While many plants have
embraced the idea of ongoing improvement of physical processes, these ideas have yet to percolate to
the information systems associated with manufacturing. Such systems still tend to be changed with a
“big bang” rather than through ongoing, incremental improvement.

2.2. Approaches to Operations Improvement

In the early stages of the ‘quality revolution’ Hayes and Wheelwright (1984) identified two
archetypal paths for performance improvement in operations (see Figure 1). One approach was to
undertake a series of ‘strategic leaps’, such as building a new factory, installing radically new process
technology, or acquiring a supplier. The other approach was to take a series of relatively small steps
whose individual impact might be small, but which cumulatively delivered substantial performance
gains over time. This incremental approach is at the core of most continuous improvement
methodologies.

Competitive Effectiveness Competitive Effectiveness

‘
Incremental
improvement

Figure 1: Competitive Effectiveness over Time (source: Hayes and Wheelwright (1984)).

The authors described distinguishing features of each approach. Strategic leaps usually demand a
major expenditure of funds, and considerable outside expertise. Timing is critical with this approach,
since the projects not only demand large amounts of capital but also depend on a single ‘event’ –
 A Path-based Approach To Information Technology - 3

finishing the project and delivering value. Since most improvement work is periodic in this model,
and since each leap may require different skills, it is difficult to maintain all required skills in house,
so it is often more efficient to look outside the company for the expertise required to make a leap.

Lower level employees are typically not an integral part of a strategic leap. They are usually affected
by the decisions made, since they are the recipients or final users of any new process, technology, or
equipment. The decisions themselves, however, and often their implementation, are considered the
domain of ‘experts.’ Strategic leaps usually require that lower-level employees be trained on new
technologies, but not that they be involved in selecting or installing them.

Incremental improvement, conversely, demands considerable involvement at the lower and middle
levels of the organization. This approach relies very little on large projects and expenditures, but
does require an intimate, ongoing knowledge of the operation. A central tenet of continuous
improvement is that the most fruitful sources of new ideas and progress are those closest to the work.

With either approach there are risks and benefits. With the incremental approach, the danger is that a
genuinely novel and successful way of carrying out operations emerges, and the incrementalist is left
behind with an operation that no amount of improvement will bring to parity with the new model.
The risk of the strategic leap approach, however, is that a breakthrough may simply not appear at the
appropriate time, meaning that the company will fall prey to the incremental improver who simply
passes it by.

Hayes and Wheelwright pointed out, however, that the risks with the two approaches are not
symmetrical. A strategic leaper usually finds it very difficult to “turn on” incremental improvement
skills if they are required, because they have atrophied over time. The incrementalist, meanwhile, is
often able to adopt a new breakthrough technology, albeit a little more slowly than its leaping
counterpart. They concluded that:

fact, our recent experience with a handful of leading firms in different

countries suggests that developing the capabilities to make ongoing
incremental improvement may actually enhance an organization ’s ability to
make occasional leaps. This is particularly true in industries where
improvements are complex, resource intensive, and multidisciplined in
nature. ”
4 - A Path-based Approach To Information Technology

3. A Path-Based Approach to the Development of Information Systems

3.1. Characteristics of Manufacturing Technologies that Facilitate Continuous Improvement

In the years since Hayes and Wheelwright pointed out the advantages of an incremental approach,
continuous improvement has become an almost universal goal, and a wide variety of methodologies,
philosophies, and ‘toolkits’ have been developed to help achieve it. Within manufacturing,
researchers examining advanced manufacturing technologies (AMTs) have explored how these
technologies can facilitate continuous improvement, instead of being merely the vehicles by which
operations effect ‘strategic leaps’ (this work is summarized in Adler and Winograd (1992) and Adler
(1992)). This research has yielded largely consistent conclusions, which can be abstracted into three
principles for operations improvement with AMTs.

3.1.1. Modularity

A first broad principle in designing technologies that facilitate improvement after installation is
modularity: building a system so that, as far as possible, a change in one element does not demand
change throughout the whole system. If a manager is solely concerned with "initial" performance, the
advantages of modularity may be minimal. However, in the long term, modularity facilitates the rapid
adoption of new process elements because it allows a process to be adapted to changing
circumstances, makes it much easier to address system-wide problems, and permits local
experimentation with one element of a system without disrupting the process as a whole.

Jaikumar and Bohn (1992) illustrate the importance of this characteristic in their examination of a
high performing Japanese matchmaking facility. Although its integrated operation was excellent
(thus presumably obviating the need for machine upgrades or extensive experimentation), 40% of
machinery was replaced each year, and iterative experimentation and problem solving were constant.
The line’s designers had insisted that all equipment and technology be modular so that, over time, it
could continue to out-perform the competition by replacing components – rather than the whole

3.1.2. Accessibility

Accessibility concerns the ease with which the people in an operation can change salient parameters
of a technology (for example, the speed of a milling machine) for experimentation or tuning.
 A Path-based Approach To Information Technology - 5

Accessibility is important for the simple reason that systems operating as “black boxes” are extremely
difficult to improve. For example, in many sophisticated processes the ability to change and
experiment is usually confined to a small group of engineers. To make matters worse, these engineers
are often former vendors or consultants, instead of current employees.

There is evidence that implementing low accessibility AMTs can adversely affect performance. In a
study of 61 fine paper plants, Upton and McAfee (to appear) found that higher levels of changeover
automation (automation intended to control the process of changing paper grades) were associated
with higherrates of paper web breakage. These breaks are catastrophic failures, causing the entire
plant to be shut down and re-initialized, and changeover automation was intended, at least partially, to
reduce them. However, this automation had the opposite effect across the plants studied. One
explanation for this paradoxical finding is that high levels of automation served to render the
papermaking machinery less accessible during changeovers, and therefore to make grade changes a
static, unimprovable process. In plants with low levels of changeover automation, meanwhile,
experiementation, learning, and improvement around grade changes could continue to take place, and
so breakage rates decreased. The greater accessibility of the changeover process in these plants, in
other words, may help explain their observed lower rates of catastrophic failure.

3.1.3. Inclusiveness

A final design principle for fostering ongoing improvement is inclusiveness. This principle stresses
involvement of the people who will use equipment during its design and implementation, an
awareness of the impact that the changes will have on the existing social system and on the skills of
the workforce, and the dangers of treating new process technologies as means to remove the need for
people and their skills. Adler and Winograd (1992) call the combination of these principles
“usability,” or designing manufacturing technology with primary consideration for how it will fit into
the human system of the operation, and how people will employ and improve it over time. This
principle can be used to inform the design of all operations processes, not just automated ones.
Including operators in the design and implementation of a process not only provides valuable inputbut
also builds an understanding of why the process works the way it does, and - most important - fosters
a sense of ownership and involvement that provides a platform for ongoing improvement.

3.2. A Path-Based Approach to Information Technology Development

To apply these three principles in the context of operations information systems, it is useful to
consider two contrasting approaches for implementing information technology. The first archetypal
6 - A Path-based Approach To Information Technology

model for how operations design and develop their IT base is characterized by installations, or
progressive waves of large systems which are put out to tender or bought from suppliers, and which
periodically become obsolete as time goes on. IT projects within this model are large, long, and
complex. They deliver value when they are complete. Users are typically involved before the project
is started (to determine requirements), and after the technical work is done (to provide training and
help confer ‘ownership’ of the system). The major challenges with this approach are to specify
precisely in advance all the requirements of the system, manage the vendor or the IT group to avoid
cost and delivery overruns, and find ways to insure against premature obsolescence and the possibility
that circumstances may have changed by the time the system is complete. Modularity, accessibility,
and inclusiveness are not stressed because these systems are not intended to be improved after
implementation; they are simply intended to perform as promised.

The second model views IT development in an operation as a path in which multiple technological
phases (such as networking, software and processing devices) overlap, evolve, and are mutually
dependent. In these circumstances, a prime concern is developing the ability to integrate new
elements and provide compatibility with existing ones. Projects are small and fast and intended to
start paying off quickly, allowing local experimentation and delivering value along the way. Users are
involved as part of this process. This model requires less long-range planning and large-project
management, but more ongoing direction-setting and technical expertise inside the operation.
Modularity, accessibility, and inclusiveness are primary concerns with this approach.

Differences between the two models are summarized in Table 1 below:

Table 1 Installation-based and Path-based models for IT development

Installation-based Path-based

Role of IT Supportive/Peripheral to Operation Integral part of Operation

Project size and number Large, few, infrequent Small, many, frequent

Development Approach Build then install Prototype and evolve

Delivery of Value When project is complete On-going

Heavy use of proprietary

Source of technology/software interconnection code, proprietary Standards in common use
standards

Control, efficiency, accommodating all Integration, interconnection, flexibility,

Primary functional concerns
requirements at once progressive delivery of requirements
 A Path-based Approach To Information Technology - 7

Installation-based Path-based

Locus of Technical Control Vendor/IT group Operation itself

Experimentation Limited Frequent opportunities

Installation, Project and Vendor Ongoing management of

Primary Managerial Effort
Management interconnection standards

3.3. Architectural Impediments to Continuous Improvement in Information Systems

The path-based approach to the development of operations information systems promises many of the
advantages that are associated with continuous improvement. There is an important additional
consideration, however: information systems are highly interdependent. While it is frequently
possible to adjust a lathe or milling machine in isolation, a change in an information system is likely
to cause other systems that rely on the data it produces to fail. Similarly, a change in a networking
protocol will only be useful if the other devices on the network are able to translate that protocol.
With information systems, in other words, local changes often have global consequences.

For this reason, enterprise information systems require the specification of an encompassing
architecture. An architecture defines how the components of a system will function and fit together as
a coherent whole (Henderson and Clark (1990)). Traditional information systems management
satisfies architectural needs by monolithic design: the system is designed at a point in time, so that all
of its components fit together well, and function together.

A path-based approach to information systems, meanwhile, does not demand that all components be
specified (or even anticipated) in advance. It sees the existence of pre-existing ‘legacy systems’ as a
fact of life, and accepts at the outset that new modules and new technologies will be added, and that
the total system will evolve progressively as time goes on. Rather than specifying precisely which
components will form part of the whole, an architecture for a path-based system specifies the
principles by which they are added or changed. As such, the architectural metaphor is closer to that of
a town or city, rather than a building (for an elegant example of architectural principles at this level,
see Alexander, Ishikawa and Silverstein (1977)). For information systems, this means establishing
principles for how various sub-systems must communicate rather than how they work internally. This
principle is the foundation of object-oriented programming (Henderson-Sellers (1996)), yet its
advantages are similar at the enterprise level. It results in modular systems, in which different
modules may be provided by different vendors. It allows local change and adaptation with less
8 - A Path-based Approach To Information Technology

complex and less severe global consequences. Finally, it permits the operations managers or
department managers to select and adapt sub-systems appropriate to the task at hand (provided they
conform to the interconnection standards) rather than to be constrained to use the sub-system dictated
by the single vendor of a total system.

3.4. Enabling Technologies for Continuous Improvement in Information Systems

These architectural principles are demanding, and it has not always been possible to take a path-based
approach to the development of large information systems. For much of the history of enterprise
computing, architectures have been monolithic (indivisible into components) and closed
(incompatible with products from other IT vendors). A mainframe computer, housing all memory,
storage, and processing power, hard-wired to a group of ‘dumb’ terminals, has been the historical
epitome of a monolithic, closed system. Even some architectures labeled ‘client-server’ have merely
replaced terminals with PCs, and mainframes with minicomputers.

The 1990’s, however, have seen a genuine growth in architectural technologies that allow operations
to develop information systems as a continuous path rather than as a series of discontinuous strategic
leaps. Two of the most important are true client-server architectures1, which facilitate more modular
systems, and open standards, which allow hardware and software products from different vendors to
be combined more easily.

3.4.1. Client-Server Architectures

Client-server systems are the architectural analog of modular programming. Modular programs
separate pieces of software into their constituent parts, and allow each part to be developed with
greater independence from the system as a whole. Client/server systems make use of the fact that it is
then unnecessary to have all modules executed within the same memory space. Within such
architectures, the calling module becomes the "client" (that requesting a service), and the called
module becomes the "server" (usually running on another machine, which provides the service).

1 We define “true” client-server as one in which the client device carries out computational activity beyond merely
supplying a graphical user interface.
 A Path-based Approach To Information Technology - 9

(e.g. NT running SQL server)

Business Logic Tier

(e.g. Warehouse Management
System)

Presentation Tier
(

Figure 2: A three-tier client-server architecture

An important recent trend in distributed computing has been the shift toward three-tier client-server
architectures (see Figure 2). A three-tier architecture introduces a server (or an "agent") between the
client requesting information and the server providing it. A wide range of functions can be performed
by such agents. They can, for example, run a Web server, which sends queries to a data-server, then
delivers the results back to a Web-based client. They can also integrate responses from multiple data-
servers, so that – to the client – there appears to be single, unified response. Intermediate servers
(often termed “application” servers) run the logic that is needed to translate a request into data
queries, and deliver the results in a useful and integrated form to the client. This further modularizes
the system, and allows system development to be broken into more manageable pieces. Each tier in
the architecture has a specific task to perform making it relatively easy to identify and isolate
problems as well as to substitute components individually (clients, agents, or servers) for which
requirements have changed.

3.4.2. Open Standards

In the early nineteenth century, every factory that needed to bolt one thing to another invented its own
threading system to do so. Slowly, manufacturers of fastening systems emerged, and nuts and bolts
were made by a variety of specialized manufacturers. While many vendors sold nuts and bolts, it was
only rarely that a nut from one manufacturer would fit on the bolt of another. In 1841, Joseph
10 - A Path-based Approach To Information Technology

Whitworth made a recommendation to the Woolwich Arsenal (the equivalent of the Department of
Defense) for the standardization for coarse-thread bolts. The adoption of this standard for nuts and
bolts meant that products from different fastener manufacturers could be substituted, with the
knowledge that nuts and wrenches would still fit. The Whitworth thread standard was widely
published, and since no one company owned the standard, no one could be precluded on proprietary
grounds from making nuts and bolts to the standard. It thus became perhaps the first example of an
open standard, or an agreed-upon interface between components that is not subject to the control of a
single commercial entity.

Developing open standards for computer interconnectivity, however, has proved more difficult than
for nuts and bolts. The reason for this is that computers communicate at many different levels, and
broad agreement on standards must exist at each of these. For the task of delivering a message from
one computer to another, the OSI (Open Systems Interconnect) Group has agreed upon a model for
what these levels are. The lowest levels are concerned with the physical connection of the devices, the
middle levels define how the message is addressed and how delivery is assured, and the higher levels
prescribe how the information is encoded, compressed, and delivered to final applications. At each of
the seven levels in the model, there are many available standards. An open system is one that relies on
open standards at each of the various levels; probably the most prominent example of an open system
is the Internet.

The importance of open-standards in providing long-term flexibility for enterprise information

systems is difficult to overemphasize. Without broadly available interconnection standards,
companies may be locked in to one vendor, be unable to develop sub-systems that are peculiar to their
own requirements, or only be able to change their information systems in lockstep with a particular
vendor. Without open standards, in other words, client server systems are like Lego models in which
the bricks have been glued together.

4. Enterprise Resource Planning Systems

The tension between installation-based and path-based approaches is illustrated by the recent history
of Enterprise Resource Planning (ERP) software, which is, along with the World Wide Web, probably
the most significant recent development in corporate information technology. In particular, the
growth and progressive development of these systems shows how the shortcomings of the
installation-based approach and the availability of new technologies and open standards are
combining to spur development of systems that facilitate path-based information technology.
 A Path-based Approach To Information Technology - 11

ERP systems comprise functions such as accounting, customer order fulfillment, manufacturing,
materials management, human resources and financial systems. They provide close integration
among these activities by ensuring that all transactions draw on a common database, and by
eliminating incompatibilities among different software systems. These advantages, along with others
discussed below, make ERP systems very attractive, especially to larger firms with a patchwork of
incompatible legacy systems. Because many manufacturing companies are in this situation, ERP has
been especially popular in this sector.

The recent growth in ERP implementation has been explosive. $5.2 billion in ERP systems were sold
in 1996, and the market is expected to continue to grow at 30-40% in coming years (Parker (1996)).
As Figure 3 below shows, this growth translates into nearly $20 billion in ERP sales by 2001.

Figure 3: Actual and Estimated ERP Sales, 1994-2001

4.1. Example: SAP’s R/3 System

SAP AG of Walldorf, Germany is the dominant ERP vendor, with a 1997 market share three times
that of its largest competitor2. SAP was founded in 1972 with the goal of producing integrated
application software for corporations. Its first major product was the R/2 system, designed for a
mainframe environment. SAP was one of the first ERP vendors to recognize that the client-server

2 Source: SAP web site www.sap.com, downloaded 2.15.98

12 - A Path-based Approach To Information Technology

computing technologies developed in the 1980s were likely to replace the established mainframe
architectures of many large firms. The company began work on a client-server product in 1987 and
released the R/3 system in 1992.

R/3 sales have fueled rapid growth at SAP. By 1996, the firm was the world’s fourth largest software
company. Expansion was especially rapid in North America, where SAP grew from a very small
presence in 1992 to over $1 billion in sales in 1996. This success was due to the confluence of a
number of factors, some of which apply to ERP in general and some to SAP in particular. These are
described below:

4.1.1. Frustration with existing client-server and mainframe systems

As companies moved from mainframe environments to client-server based systems, they often
discovered that client-server computing alone was not the solution to inflexible, outdated mainframe
environments. Client-server systems were prone to degenerate into an incoherent collection of
disparate sub-systems, which were not only ineffective as an integrated whole, but were also
expensive and difficult to maintain (Sullivan (1996)). Enterprise-wide information systems, such as
SAP’s R/3 have promised to rescue companies from expensive tangles of unintegrated client-server
systems. ERP provides an information system that is consistent across the company, including a wide
range of business functions – from manufacturing to finance. ERP takes advantage of modern three-
tier client-server technologies, while still delivering a mainframe system’s consistent information and
functionality.

4.1.2. Marketing Strategy

SAP has formed partnerships with a number of large consulting firms. Together, they sell ERP to
executives as part of a broader business strategy, rather than selling it to Information Systems
managers as a piece of software. Most ERP software sales are bundled with the managerial and
information technology consulting services required for its installation. ERP vendors are careful to
point out that their software has such important strategic implications that CEO’s should be directly
involved in the purchasing decision. This change of “customer” is important in ensuring that the large
expenditures required for ERP software and consulting are authorized.

4.1.3. Reengineering and Best Practices

ERP has been bundled with the set of operations improvement techniques labeled ‘reengineering’.
ERP vendors such as SAP have embedded a body of ‘best practices’ for business processes (such as
 A Path-based Approach To Information Technology - 13

how to take a customer order or receive goods into inventory) into their software, and encourage its
customers to use them. Adoption of these best practices is typically accomplished through a re-
engineering effort led by consultants.

4.1.4. The ‘Year 2000 ’ Problem

Many legacy systems treat dates as two-digit numbers. They will therefore truncate 2000 into 00,
leading to the prospect of a variety of damaging errors as the year 2000 approaches. The problem is
pervasive and difficult to correct; many firms who might otherwise have waited longer to upgrade
their systems have decided to opt for wholesale replacement. This has further fuelled the growth of
ERP installations.

4.2. Configuration and Modification

Although ERP systems are intended as "standard" applications that do not require significant
modification for each customer, it is still necessary to configure them when they are installed to meet
the peculiarities of particular kinds of business. Configuration in R/3, for example, is accomplished
by changing settings in R/3 configuration tables.

R/3’s approximately 8000 tables prescribe how the system functions and how users interact with it
(Bancroft (1996)). To configure the system, external installers typically build models of how a
process should work, then turn these into ‘scripts,’ and finally translate scripts into table settings. For
example, after writing a script that defines how a new customer order would be entered, the installer
would know whether the order taker should have the ability to override the product’s ‘price’ field on
the order entry screen.

During an implementation, this configuration activity must be replicated for all relevant processes and
requires a great deal of time and external consulting expertise. People who are experts at this work,
and who understand the impact of each table change, are features of every R/3 implementation.

4.3. Implementation Issues

To many CEOs seeking to disentangle their existing outdated and incompatible information systems
while simultaneously cutting internal IT budgets, ERP systems have appeared to be a silver bullet. In
one large project, a firm can apparently solve some of its most difficult enterprise-wide computing
problems. In addition, companies with outdated business practices and mediocre internal IT
development groups can gain access to a set of practices and software far superior to those currently
in place.
14 - A Path-based Approach To Information Technology

However, single-vendor ERP’s legitimate advantages over many legacy systems, and its strong sales
growth, belie the problems that customers have experienced. These issues are summarized in a recent
Wall Street Journal article describing SAP’s R/3:3

“The software is fiendishly complex and expensive to configure. Companies must

play host to armies of consultants who sometimes charge as much as five times what
the software itself costs and can stay on the job for years … Some companies have
seen their R/3 project budgets double … Then there is the human factor. Because
R/3 is so complicated, it is usually cheaper for companies to change the way their
people work than to change the way the system works. ”
Another recent article on R/3 implementations also stresses the degree of change required to existing
processes:4 “The good news about SAP is that it’s a totally integrated system… The bad news about
R/3 is that it’s a totally integrated system, requiring companies to modify their business procedures to
conform to SAP’s strict integration requirements.”

These concerns have apparently been substantial enough to overwhelm any actual, perceived or
anticipated benefits of the system at some companies. Dell Computer and Ikon Office Solutions, for
example, have abandoned their ERP implementations. The Chief Information Officer of Ikon, in
explaining the decision, cites the following concerns:5

"There were a number of factors that made us decide this project was more
challenging than beneficial for us. When we added everything up-human factors,
functionality gaps, and costs incurred-we decided our environment is ill-defined for
SAP …We were very short in our own systems and process expertise. We made errors
on our side in estimating the amount of business change we'd have to make as part of
this implementation ”
The time, expense, and degree of organizational and process change required thus seem to be
prevalent concerns around ERP, and to have scuttled some implementations. Another potential issue
was raised in an analyst’s report to companies considering R/3 that highlighted the extent to which
the system relied on closed, as opposed to open, standards: 6

“ …companies need to restrict the use of SAP's proprietary tool ABAP4 and R/3 data
formats in two ways: Wrapper R/3 messages and transactions with standard

3 White, J. B., S. Ascarelli and D. Clark (1997). “German R/3 Software is a Hit, but Installation is a Nightmare,”The Wall
Street Journal March 14, 1997: A1.

4 Xenakis, J. J. (1996). “Taming SAP,”CFO March, 1996: 23-30.

5 White et al, ibid.

6 Cameron, B., G. F. Colony, et al. (1996). Packaged Application Strategies: The Prudent Approach To R/3. Cambridge,
MA, Forrester Research, Inc.
 A Path-based Approach To Information Technology - 15

interfaces. [and]... Don't let applications outside of R/3 use R/3's data formats …
Forrester believes that the R/3 cartel will not be competitive in the delivery of
systems that touch customers, suppliers, and business partners. Don't use R/3 for
new customer connection applications …R/3's 1980s technology will not let you keep
pace with the Internet-led explosion of new connections with customers. ”
Despite its use of three tier client server architectures, then, R/3 still relies on proprietary standards
for much of its interconnectivity.

Taken together, these concerns imply that implementing ERP systems slots companies into an
installation-based, as opposed to a path-based, approach to their operations information systems.
Putting the software in place is lengthy and costly, there is heavy reliance on outside expertise, as
well as heavy use of proprietary code and closed standards, and updates and experimentation are
likely to be infrequent because of the associated difficulty and expense.

4.4. Responses to Long-term Flexibility and Short-term Implementation Concerns

The fierce debate in the IT community concerning whether implementing ERP amounts to pouring
‘liquid concrete’ over a company’s information systems and business practices has stimulated ERP
vendors to make significant changes to their software, and to address a number of the issues described
above. SAP’s substantive responses, for example, can be divided into two categories: technical and
procedural. Technical responses are modifications (either planned or completed) to the software to
incorporate more open standards or allow R/3 to interface more easily to other applications.
Procedural responses include changes that SAP and its partner consulting firms have made to the
implementation process in an effort to shorten it.

4.4.1. Technical Responses

In 1995, SAP released R/3 version 3.0. This update included features7 intended to make the system
and its data more accessible, including:

• ALE (Application Link Enabling): A messaging technology that allowed coupling of

physically separate R/3 installations and databases, and information transfer between
R/3 and other applications.

7 Descriptions of these features are presented in the SAP Document: R/3 System: The Business Framework. Wayne, PA,
SAP America, Inc. (1996)
16 - A Path-based Approach To Information Technology

• Business Objects: Version 3.0 defined over 170 ‘business objects’, or representations of
R/3 transactions, events, and information in object-oriented (OO) programming terms.
Definition of these objects allowed the possibility of communicating with these objects
using standard OO techniques.

• BAPIs (business application programming interfaces): 3.0 also introduced BAPIs, or

pre-defined methods by which other applications could communicate with R/3’s
business objects. BAPIs were intended to be compatible with Microsoft’s OO standards.

R/3 version 4.0, which was released in 1997, expands on these technologies and concentrates on
extending the system to the Internet and intranets. Version 4.0 includes over 100 additional BAPIs,
largely devoted to Internet functionality. SAP has also announced support for CORBA, an industry-
wide open OO standard.

4.4.2. Procedural Responses

In addition to incorporating more open technologies into R/3, SAP has taken steps to promote
approaches that offer the potential to shorten total lead time and expense. These procedural responses
have been described in case studies, sponsored by SAP, of specific implementations. They include:

• Minimal software modification: One case study8 states that “A relatively short timeline and a
‘no modification’ policy contributed to the team’s focus… They added no custom reports
and wrote no additions to the system.” Another study9 found that “The implementation team
emphasized that packaged software had been purchased and that it was not a custom system.
For situations which R/3 could not handle… the system was augmented but not changed.”

• Business process modification: According to a case study10, one ‘critical success factor’ for
the implementing company was “The fact that they implemented the system first, and then
organized their practices and structure to fit the software also allowed them to focus on
getting the system in as quickly as possible.” This implies that the firm’s processes were
altered to meet the needs of the software, rather than the reverse. This is in keeping with an

8 Benchmark Implementations: Fujitsu Microelectronics, Inc. Cambridge, MA, Benchmarking Partners, Inc.
(1997)

9 Scalea, R., R. Linsalata and L. Plazonja (1996). The ROI Report. Featured Company: Computervision. Boston, Scalea &
Company.

10 Benchmarking Partners, ibid.

 A Path-based Approach To Information Technology - 17

approach of minimal modifications and extensive training; future users are educated on the
current capabilities of the system, and expected to change their jobs to take advantage of
these capabilities once the new system is in place.

• Training and change management. Case studies also emphasize the importance of training
to change the way that people work. A senior manager cited in one11 maintains that “The
tendency is to focus on all the mechanical things you have to do in order to make this thing
work. The reality is you have to spend at least as much time preparing people for the change
and the impact on their lives as you did developing the mechanical things. Otherwise, you
get resistance, you get people who absolutely refuse to do this, and you get breakage in the
organization.”12

In summary, it appears that SAP is making a concerted effort to distance itself from the perception
that its products are monolithic and closed, or simply mainframe-based software updated for a newer
hardware platform. At the same time as emphasizing openness, however, it is also encouraging
companies to shape their processes around R/3’s existing functionality (rather than vice-versa) to
shorten implementation times.

5. ERP and Operations Improvement

5.1. ERP Implementation as a ‘Strategic Leap’

Despite recent efforts by SAP and other ERP vendors, ERP systems continue to display many of the
characteristics of the ‘strategic leap’ projects described by Hayes and Wheelwright over ten years
ago. First, very few ERP systems are installed without external expertise. Some vendors only
permit sales that are bundled with their partner’s consulting services. Second, timing is critical, since
ERP projects not only demand large financial expenditures but also depend on a single event –
completing the installation and ‘flipping the switch’ on the new system. Third, decisions concerning
the installation of the system are made at a high level in the organization, creating what Hayes and
Wheelwright describe as a “Win-big/lose-big” environment. Fourth, lower-level employees, while

11 Benchmarking Partners, ibid.

12 White, J. B., S. Ascarelli and D. Clark (1997). “German R/3 Software is a Hit, but Installation is a Nightmare,”The Wall
Street Journal March 14, 1997: A1.
18 - A Path-based Approach To Information Technology

affected by the decisions made (since they are final users of the system), are rarely involved in design
decisions. Because of the complexity of ERP, the important decisions themselves and their
implementation, are the domain of ‘experts.’

A number of hazards associated with large-scale monolithic ERP implementation can be identified.
The first, and most obvious, is the problem of being locked-in to a particular ERP vendor. Upgrades
to the system will usually come from that vendor, and will presumably require more help from
consultants. The rhythm of subsequent system development is therefore set by the software vendor
rather than the company itself. Associated with this is the fact that the installed systems can be
difficult to change and improve once they are installed, especially if a firm has contracted for much of
the expertise required during the implementation instead of developing it internally. Existing ERP
implementations are reasonably easy to configure at the time of installation, but much more difficult
to continually adapt and shape over time.

5.2. Toward a Path-based Approach

As ERP companies change their software to accommodate concerns about their monolithic nature, it
is worthwhile to consider whether the particular changes described above offer the potential for
ongoing improvement, using the continuous improvement principles of modularity, accessibility, and
inclusiveness outlined in section 3.1 (this discussion will continue to use SAP’s R/3 as the ERP
system under consideration).

It seems clear that R/3 is becoming a more modular software system. ALE, BAPIs, and Business
Objects are all technologies that allow SAP’s software to interact more easily with other applications,
and to make it a less monolithic system. To continue this trend, the company has announced that
future revisions of R/3 will separate human resources and logistics functions from the rest of the
system and treat them as individual (and substitutable) components. While R/3 remains an extremely
large and tightly integrated software system, it has become more amenable to outside applications,
and to extension and replacement of its functionality.

These technical modifications also have the potential to make the system more accessible. SAP’s
adoption of widely used object-oriented techniques, and its progressively decreasing reliance on the
proprietary ABAP/4 language, mean that more programmers will be able to work on the system, and
that it will be less of a ‘black box’ to implementing companies. BAPIs, for example, appear to be
standard ‘hooks’ for importing and exporting data, among other tasks. These tools can provide firms
with much greater access to their information.
 A Path-based Approach To Information Technology - 19

The recent procedural modifications to R/3 implementation, however, indicate that SAP may be
reducing the post-implementation accessibility of the system to the company. An emphasis on
minimal modification, and on adoption of pre-defined ‘best practices’ means that companies may not
have significant opportunity to learn about the system they are putting in place, or to develop the
skills required to access and change it. A reliance on external consultants, as opposed to internal IT
resources, can worsen this problem.

These same procedures may also reduce the inclusiveness of an ERP implementation. At first glance,
it appears that a strong emphasis on training can only increase inclusiveness. However, training and
education intended to reinforce the idea that users must become accustomed to adventitious,
unmodified best practices can have the opposite effect. Users may become familiar with the ERP
screens and transactions that they are expected to use in their jobs, but they may not feel that they
involved in designing them, or that these tools have captured the task knowledge that they possess.
To use an analogy, a training program designed to teach shop-floor workers how to maintain, support,
and interact with a new robotics line would not in itself increase the inclusiveness of the technology,
while an effort to solicit and capture the operators’ knowledge about the tasks to be automated would
be much more inclusive. Much of the information available about current approaches to ERP
implementations indicates that they resemble the former example instead of the latter.

6. Conclusion
By considering the future improvement path of new information systems, as well as the extent to
which they relieve existing problems, managers can do much to enhance their long-term benefits. In
summarizing research on the relationship between information technology and firm-level
productivity, Brynjolffson (1994) states that:

“Perhaps the most important reality is that despite what the statistics say
about the ‘average ’ return on IT investment, each manager must decide
which projects are worthwhile. There is no bank where companies can
deposit IT investments and withdraw an “average ” return … Productivity
does not automatically follow IT dollars -- it takes a lot of hard work. ”
The concept of a path-based, as opposed to an installation-based, approach to managing information
technology, and the principles of modularity, accessibility, and inclusiveness are proposed here as
steps toward helping with this important managerial task. It seems clear that stewardship of
information systems will continue to be a critical part of an operations manager’s job, especially as
available options proliferate.
20 - A Path-based Approach To Information Technology

One such option that appears to offer the integrated information of ERP and the improvability of a
more modular, or path-based approach, is a ‘best of breed’ system. Such a system combines the most
suitable products from a variety of vendors, often linked by a database ‘backbone’ for information
consistency. The danger with a best of breed approach is that it can collapse into a morass of
incompatible systems, and prove no better than the legacy patchwork it was intended to replace.
However, the modern client-server architectures and open standards described in section 3.4, and the
recent extensions to R/3 described in section 4.4, indicate that more straightforward communication
among different information systems is rapidly becoming possible. This provides an opportunity for
ERP systems not only to deliver a step-change in performance, but also to carry the potential for
ongoing improvement, thus avoiding the ‘periodic-change’ trap described by Hayes and Wheelwright
(1984).

Operations managers in this new environment will have three important tasks with respect to their
information systems. First, they will need to ensure that their IT architectures support open
interconnectivity among applications to allow for future business (and hence system) changes. For an
operation in a comparatively static business, installing ERP from a single vendor and accepting the
system’s functionality as given, little open interconnectivity may be required. Ongoing architectural
stewardship becomes critical for companies in more changeable environments, which are taking a
path-based approach, and are implementing systems that look more like ‘best of breed.’

Second, managers within both operations and IT will need to ensure that their organizations possess
the skills required not only to maintain the systems in use, but also to modify, experiment with, and
improve them. Even a system that is highly modular and open can become inaccessible if people,
through lack of training or lack of practice, lose the capability to change it.

Finally, those responsible for information systems implementation can encourage users to be involved
throughout the development process, and as more than just eventual and periodic recipients of a new
tool developed elsewhere. End-user training on ‘best practices’, the focus of many current ERP
implementation efforts as described above in section 4.2, is not the same as inclusiveness. People
working with existing systems often have an extensive, rich and relevant knowledge base about the
requirements of their jobs and the improvements that would be most helpful. By using this
knowledge, developers not only take advantage of it, but also encourage the commitment of
employees to the success of the system and their involvement in its future, ongoing development path.
 A Path-based Approach To Information Technology - 21

REFERENCES

R/3 System: The Business Framework. Wayne, PA, SAP America, Inc. (1996).
Bancroft, N. H. (1996). Implementing SAP R/3. Greenwich, CT, Manning Publications, Inc.
.
Benchmark Implementations: Fujitsu Microelectronics, Inc. Cambridge, MA, Benchmarking
Partners, Inc. (1996).
Adler, P. S., Ed. (1992). Technology and the Future of Work. New York, Oxford University Press.
Adler, P. S. and T. A. Winograd (1992). The Usability Challenge. Usability: Turning Technologies
into Tools. Ed. P. S. Adler and T. A. Winograd. New York, Oxford University press.
Adler, P. S. and T. A. Winograd, Eds. (1992). Usability: Turning Technologies into Tools. New
York, Oxford University press.
Alexander, C., S. Ishikawa and M. Silverstein (1977). A Pattern Language. New York, Oxford
University Press.
Brynjolffson, E. (1994). “Technology's True Payoff,” InformationWeek October 10.
Cameron, B., G. F. Colony, et al. (1996). Packaged Application Strategies: The Prudent Approach To
R/3. Cambridge, MA, Forrester Research, Inc.
Fulcher, J. (1996). “Ahead of the Pack,” Manufacturing Systems May, 1996 (5): 18.
Hayes, R. H. and S. C. Wheelwright (1984). Restoring our Competitive Edge: Competing Through
Manufacturing. New York, John Wiley & Sons.
Henderson, R. M. and K. B. Clark (1990). “Architectural innovation: the reconfiguration of existing
product technologies and the failure of established firms,” Administrative Science Quarterly 35 (1).
Henderson-Sellers, B. (1996). A Book of Object-Oriented Knowledge : An Introduction to Object-
Oriented Software Engineering, Prentice Hall.
Hirschhorn, L. and J. Mokray (1992). Automation and Competency Requirements in Manufacturing:
A Case Study. Technology and the Future of Work. Ed. P. S. Adler. New York, Oxford University
Press.
Jaikumar, R. (1986). “Postindustrial Manufacturing,” Harvard Business Review
(November/December): 69-76.
Jaikumar, R. and R. Bohn (1992). “A Dynamic Approach to Operations Management: An Alternative
International Journal of Production Economics 27: 265-282.
McFarlan, W. F. and R. L. Nolan (1995). “How to Manage an IT Outsourcing Alliance,” Sloan
Management Review (Winter): 9-23.
Parker, K. (1996). “Great Expectations,” Manufacturing Systems December (12): 10-14.
Scalea, R., R. Linsalata and L. Plazonja (1996). The ROI Report. Featured Company:
Computervision. Boston, Scalea & Company.
22 - A Path-based Approach To Information Technology

Sullivan, R. L. (1996). “Postpartum Blues,” Forbes February 26, 1996: 106-112.

Upton, D. M. and A. P. McAfee (to appear). “Computer Integration and Catastrophic Process Failure
Production and Operations Management.
White, J. B., S. Ascarelli and D. Clark (1997). “German R/3 Software is a Hit, but Installation is a
The Wall Street Journal March 14, 1997: A1.
Xenakis, J. J. (1996). “Taming SAP,” CFO March, 1996: 23-30.
Zuboff, S. (1988). In the Age of the Smart Machine: The Future of Work and Power. New York,
Basic Books.