College of Business Administration

University of Rhode Island

2004/2005 No. 5

This working paper series is intended tofacilitate discussion and encourage the

exchange of ideas. Inclusion here does notpreclude publication elsewhere.

It is the original work of the author(s) andsubject to copyright regulations.

WORKING PAPER SERIESencouraging creative research

Office of the DeanCollege of Business AdministrationBallentine Hall7 Lippitt RoadKingston, RI 02881401-874-2337www.cba.uri.edu

William A. Orme

Mark Lehrer

Business Software as a General-Purpose Technology:Experience-Driven Design Innovation in ERP Systems

Business Software as a General-Purpose Technology:

Experience-Driven Design Innovation in ERP Systems

Prof. Mark Lehrer College of Business Administration

University of Rhode Island Kingston, RI 02881 USA

phone: (401) 874-7882

fax: (401) 874-4312

LEHRER@URI.EDU

11 November 2004

University of Rhode Island Working Paper

Please do not Quote or Cite without Permission

Business Software as a General-Purpose Technology:

Experience-Driven Design Innovation in ERP Systems

ABSTRACT

General Purpose Technologies (Bresnahan and Trajtenberg, 1995; Helpman, 1998) have been hitherto conceptualized as upstream technical inventions whose downstream commercialization requires sector-specific complementary investments. This article points up the existence of a different class of general purpose technologies that – unlike the classic cases of dynamos, transistors, and computers – originate downstream as special purpose technologies in specific sectors and then evolve upstream into general purpose technologies through discovery of broader applications that lead to design breakthroughs in product embodiment of the technology. The evolving design of enterprise resource planning (ERP) software exemplifies this process of „technology generalization.“ Technology generalization is related to the process of technological convergence (Rosenberg, 1972; 1976), but lays the emphasis on design improvements enabled by the accumulation of experience and exposure to multiple environments rather than on changes in industry structure.

1

Business Software as a General-Purpose Technology: The Rise of ERP Systems

1. Introduction

The advent of enterprise resource planning (ERP) systems in the 1990s created a

major new category of standardized software dominated by a handful of large software

companies (SAP, PeopleSoft, Oracle, Baan). Notwithstanding the odd terminology, ERP

refers simply to an integrated suite of business application software supporting the firm’s

basic functions (manufacturing, finance, marketing, etc.). The hallmark of modern ERP

software is that, with the necessary customization, it can be implemented across a wide

range of firms and industries, displacing the traditional reliance on idiosyncratic firm-

specific business software. As such, ERP systems would appear to be a good example of

General Purpose Technologies, or GPTs (Bresnahan and Trajtenberg, 1995; Helpman,

1998). Frequently cited examples of GPTs include electric motors and steam engines

(Bresnahan and Trajtenberg, 1992; Rosenberg and Trajtenberg, 2001), dynamos and

computers (David, 1990), transistors and semiconductor chips (Helpman and Trajtenberg,

1998b). Lipsey, Bekar and Carlaw (1998) endeavor to draw up a first inventory of GPTs.

GPTs are technological innovations with the capacity to diffuse across a wide set of

industries. Related notions include macroinventions (Mokyr, 1990), strategic sectors

(Zysman and Tyson, 1983), technoeconomic paradigms (Freeman and Perez, 1988) and

2

other variations on Kondratiev’s waves-of-innovation model (Schumpeter, 1939; Freeman

and Louca, 2001). Common to all of these concepts is the ambition to provide a micro-

macro link between the generation of new technological knowledge at local levels and

economic growth at more global levels. A fundamental issue is one of multiple complex

complementarities entailed by new technologies with wide-scale applications. Most new

technologies, far from being plug-and-play products, require substantial complementary

investments in order to fit into the existing production system (Tushman and Anderson,

1986; Anderson and Tushman, 1990).1 The existence of innovation complementarities

across sectors in the diffusion of new technologies leads to appropriability problems and

hence also to innovation lags (Bresnahan and Trajtenberg, 1995), productivity lags (David,

1990) and cyclical patterns of expansion and investment (Freeman and Perez, 1988;

Helpman and Trajtenberg, 1998a).

Innovation complementarities also create a potential critical mass problem.

Adoption of a new technology may hinge on additional R&D investment, standardization,

and large-scale production of the core technology in question; yet these economically

necessary and efficient supply conditions may fail to materialize in the absence of demand

across a wide number of industrial sectors. In other words, GPTs present an economic

chicken-and-egg problem akin to that treated in the literature on dominant designs

(Abernathy and Utterback, 1978; Utterback, 1994).

The interest of the EPR case lies in the particular path of resolution of this chicken-

and-egg problem. In a nutshell, ERP systems did not begin as general purpose

technologies. Instead, they began as specific purpose technologies that evolved into

generic purpose technologies through repeated installation and redesign of the core product

3

to cover an increasing range of applications. The evolution of SAP’s core ERP products,

the R/2 and R/3 systems as recounted below, exemplifies the process of “technology

generalization”: the process of refining a technology product so that it accommodates the

needs of a range of industries rather a specific industrial application. This process is not

specific to ERP systems nor is it even uncommon; parallels will be pointed out in machine

tools and chemical engineering.

ERP systems belong to a class of GPTs that differ from classic technologies like

dynamos, transistors, and computers. For while these latter GPTs began upstream as

general-purpose technologies that had to be adapted to specific applications, ERP systems

are representative of technologies that first arise downstream as special-purpose

applications and evolve through learning and design improvements into GPTs. Their

economic implications therefore differ from those of the GPTs most commonly analyzed in

prior literature. In particular, the appropriability problem posed by innovation

complementarities is less pronounced than for innovations like dynamos, steam engines,

and semiconductors.

2. General Purpose Technologies: Definitions and Variations

An advantage of the GPT concept, originally formulated by Bresnahan and

Trajtenberg (1992), is definitional parsimony. As represented in Figure 1, a GPT is a

technology that can be applied across a variety of application sectors (AS). All variations

of the GPT concept assume the marginal cost of adapting the GPT to a new AS to be non-

trivial, although economic models of the cost function vary (Bresnahan and Trajtenberg,

4

1995; Bresnahan and Gambardella, 1998; Helpman and Trajtenberg, 1998a). The marginal

cost of sector adoption depends also upon the level of investment in the GPT occasioned by

adoption among other sectors (innovation complementarities). For example, the cost of

introducing microprocessor chips into telephones will be lower if microprocessors have

already been adopted by other sectors (computing, radio, etc.) whose demand has

stimulated prior R&D and improvements in the basic GPT. Two types of positive

externalities may lead to socially sub-optimal diffusion of GPTs due to the

nonappropriability of rents. First, “horizontal” externalities among different application

sectors result in a coordination problem in which latent demands for a common GPT lack

effective aggregation. Second, a “vertical” externality between a GPT and an application

sector may prevent GPT inventors from appropriating the full benefits the GPT, thereby

leading to underinvestment and undersupply of the GPT (Bresnahan and Trajtenberg,

1995).

-- Insert Figure 1 About Here --

Innovation complementarities affect the sequence of application sectors adopting

GPTs. GPTs diffuse first to sectors in which adoption costs or low and then to sectors for

which the cost of adoption is lowered by prior diffusion of the GPT. The history of

electricity exemplifies the process (Passer, 1953). After the invention of electromagnetic

dynamos in the 1860s, large-scale industrial applications of high-voltage electricity

emerged first in lighting (1870s), then transportation (1880s), and later capital equipment

(1890s). The complementarities were both horizontal and vertical. The proven feasibility

5

of high-voltage electricity for lighting (first arc-lighting in the 1870s, then incandescent

lighting in the 1880s) drove the supply and technology development of central electricity

plants (i.e. investment and R&D in the core GPT), which was crucial to the next major AS,

namely electric streetcars, which required vast amounts of power from a centralized source.

The industrial use of electricity for applications like electrochemistry accelerated when

centralized power generation was achieved on a high scale in the 1890s using AC instead

of DC, another major advance in the core GPT (Passer, 1953).

In similar fashion, transistors diffused quickly to sectors like hearing aids and

computers but much more slowly in sectors like telecom and automobiles where they were

difficult to incorporate into a complex pre-existing production infrastructure (Braun and

MacDonald, 1978; Helpman and Trajtenberg, 1998b). The adoption sequence is depicted

in Figure 2. The dynamo (electromagnetic generator) and transistor are two examples of

GPTs that were invented in research laboratories as major technical breakthroughs whose

path of industrial adoption was difficult to foresee. While Werner Siemens was a co-

inventor of the dynamo and instantly intuited electricity’s potential to transform the

industrial world (Feldenkirchen, 1997a: 53-4), his company subsequently lagged in the

development of high-voltage applications after failing to anticipate the boom in electric

lighting and central generating plants (Feldenkirchen, 1997b). A similar irony prevailed in

transistors, invented by Bell Labs for use in telephony but not actually adopted in

telecommunications until much later than in other application sectors (Braun and

MacDonald, 1978). In sum, the dynamo and transistor are good examples of GPTs whose

invention preceded commercial innovation. Put differently, the dynamo and transistors fit

6

the linear R&D model with sequential stages of basic research, development for specific

applications, and industrial commercialization.

-- Insert Figure 2 About Here --

The friendly amendment to the innovation literature raised here is to point out the

existence of GPTs that originate through a different kind of process In particular, many

GPTs actually begin as special purpose technologies whose general applications only

become apparent over time. Here, too, complementary investments in the core technology

are necessary for diffusion across application sectors, but the basic technical challenge is

different. Instead of investing in development of a generic technological invention to fulfill

a specific commercial purpose, the basic task may be one of redesigning an already

commercialized technology so as to widen its range of deployment. As producers of a

novel technology learn about its broader applications, they may find ways to unbundle the

technology from its specific original application and redesign it as a GPT suitable to serve a

multitude of application sectors.

This process of “technology generalization” is schematized in Figure 3. In contrast

to the linear model of R&D, technology generalization underlines the incorporation of

information feedback from downstream market applications into the upstream innovation

(R&D) process (von Hippel, 1988; Gibbons et al., 1994). Figure 3 illustrates a process of

GPT emergence driven by the accumulation of high-level design knowledge as a new

technology finds application beyond its initial AS. In top-down GPTs like the dynamo and

transistor, the first commercial breakthrough involves tailoring the upstream technology to

7

a downstream application sector; the critical complementarity is a vertical one. In the class

of GPTs examined here, the initial complementarities are more horizontal; the accumulated

experience of applying a similar technology across multiple application sectors results in a

GPT based on a breakthrough in design. This is somewhat analogous to processes of

market feedback leading to a dominant design in “lead markets” (Beise, 2001).

-- Insert Figure 3 About Here --

One question left open by the foregoing discussion is whether GPTs are

components of the end product or of the capital goods that produce the end product. In

fact, GPTs can refer to both. Since ERP systems are capital goods, much of the following

discussion will be most germane to capital goods. The process of technology

generalization can clearly apply to consumer products as well, however; the personal

computer notably comes to mind as a product whose range of applications has increased

over time, with feedback from each generation of technology leading to design

improvements facilitating yet further extensions of product functionality. Of course, the

personal computer has also been a capital good since the inception of spreadsheets;

generally speaking, the macroeconomic effects of GPTs are most significant for

technologies with complementarities across sectors in both business and consumer product

sectors, for it is here that GPTs are most tangible as forces generating increasing returns

and nonconvexities across the entire economy (Helpman and Trajtenberg, 1998a: 82). The

ensuing focus on capital goods GPTs is thus duly noted here as a limitation of the present

analysis.

8

3. Technology Generalization in Capital Goods: ERP and Its Predecessors

ERP systems did not begin as general purpose capital goods. Instead, they evolved

into them. The history of machine tools in the 19th century reveals similar dynamics. The

American system of manufacturers, based on interchangeable parts, first took root in arms

manufacture but later diffused to other manufacturing sectors. The concrete transmission

mechanism of cross-sector diffusion was machine tool production (Rosenberg, 1972;

1976). For example, turret lathes, which allowed multiple cutting operations to be

performed on a workpiece, originated in firearms production but later spread to virtually all

metalworking industries.

Another key innovation was the milling machine, which allowed regular spiral

grooves to be imparted into metal pieces so that the pieces could be assembled with less

filing and fitting of parts. The origin of the milling machine is considerably different from

that of the transistor. At first the milling machine was simply a superior piece of

machinery for producing firearms. Its qualities as a GPT emerged gradually through a

process of iterative market experience and design improvement:

The firearms industry was also the source of the milling machine … The versatility of the milling machine was greatly increased during the Civil War when the Brown and Sharpe Company of Providence, Rhode Island, a firm which had been engaged in sewing machine production, attempted to develop a new method for making twist drills … The result was the universal milling machine … Within ten years after Brown and Sharpe produced the first universal milling machine in 1862, the firm had sold similar machines to manufacturers of hardware, tools, cutlery, locks, arms, sewing machines, textile machinery, printing machines, professional and scientific instruments, locomotives, to machine shops and foundries, and to machine tool manufacturers. In subsequent decades, with each new product innovation, universal milling machines were sold to a succession of firms producing cash registers,

9

calculating machines, typewriters, agricultural implements, bicycles, and automobiles (Rosenberg, 1972: 104-5). The progressively widened application realm of the milling machine exemplifies the

process of technology generalization, which consists above all in design improvement, a

point central to the analysis of ERP systems below. Rosenberg’s own term, “technological

convergence” (1976: 16), is obviously related but lays more emphasis on changes in

industry structure resulting from the growing similarity of basic production techniques

employed across manufacturing sectors. The central 19th-century industrial development

studied by Rosenberg is the emergence of machine tools as an independent sector; prior to

the 1850s, most manufacturers had to produce their own specialized machine tools.

“Technological convergence” refers to the economic process by which a general-purpose

machine tool industry emerged in place of specialized in-house machine tool production by

final manufacturers; following Stigler (1951), Rosenberg’s chief interest is the division of

labor and vertical disintegration. “Technology generalization,” in contrast, refers more to

intellectual breakthroughs underlying the design of products like machine tools; the

following analysis stresses the accumulation of technical and market knowledge resulting

in breakthrough or dominant designs (Utterback, 1994; Beise, 2001). In the case of milling

machines, this process is summarized in Figure 4.

-- Insert Figure 4 About Here –

The intellectual breakthrough required by technology generalization is above all

one of abstraction. Making a specific purpose technology tractable to a wider range of

industrial application requires a broader grasp of the technology’s basic function. In

10

milling machines, for example, a leap had to be made from “a machine that engraves

interchangeable stocks and barrels so that they can be screwed together” to “a machine that

creates grooves in any interchangeable parts that need to be screwed together.” In practice

such abstraction may result from the exposure to multiple industries and thus the

opportunity to perceive components and procedures that are common to a broad range of

industrial applications. First movers in the development of GPTs out of specific purpose

technologies are often those firms who were early in exploring multiple user industries

rather than remaining specialized in a given user group. This was fairly evident in the

history of Brown and Sharpe in the 19th century (Hounshell, 1984: Ch. 2) and SAP in the

20th century. Like milling machines, SAP’s business software did not begin as a general

purpose capital good. Instead, it evolved into one. What began as a product most useful to

chemical and machinery companies proved adaptable to ever wider categories of firms.

An example of technology generalization through abstraction is the discipline of

chemical engineering, which Rosenberg (1998) classifies as a GPT and which bears

resemblance to ERP software in its pattern of emergence. Before the establishment of the

chemical engineering field, the process of making chemicals was highly firm-idiosyncratic,

as was the associated terminology. Though chemical engineering courses had been offered

since the 1880s as a mixture of mechanical engineering and chemistry, the field’s

boundaries remained murky until WW1 when the analysis of “unit operations” caught on as

the specific province of chemical engineers. Arthur D. Little first articulated the basic

principles of what he initially called unit actions in 1915 as follows: “Any chemical

process, on whatever scale conducted, may be resolved into a coordinated series of what

may be termed ‘unit actions,’ as pulverizing, mixing, heating, roasting, absorbing,

11

condensing, lixiviating, precipitating, crystallizing, filtering, dissolving, electrolyzing and

so on” (Little, 1933: 7). The accomplishment of Little and his colleagues at MIT was to

transcend specific chemical properties by articulating at an abstract level what sets of

operations were involved in the handling and making of chemicals. The character of

chemical engineering as a GPT was subsequently shown by the discipline’s fecund

applications not only to chemicals, but also to petroleum, plastics, synthetic fibers, and

synthetic rubber. The chemical engineering discipline furnished a technical vocabulary and

accumulating stock of scientific knowledge that could be utilized across multiple industries

(Rosenberg, 1998).

A.D. Little’s formulation of fundamental principles of chemical engineering

apparently derived from his prior experience as a consultant in various manufacturing

industries, especially paper and pulp. Rosenberg (1998: 178) surmises: “It seems

reasonable to conclude that Little’s consulting experience … sharpened his awareness of

the extent to which entirely different product lines were making use of similar operations.”2

The pioneering of ERP software by SAP reveals a quite analogous process: as SAP gained

acquaintance with the requirements of a widening circle of corporate customers, it also

gained a more abstract understanding of firms’ generic “unit operations” (to borrow Little’s

term) and gradually acquired the knowledge necessary to design a business software

package supporting the business functions of firms from virtually any industry setting.

4. Technology Generalization in ERP Systems: The Case of SAP

12

The origin of modern ERP systems is largely coextensive with the history of SAP

AG of Germany. When SAP introduced its R/3 software suite in 1992, there was no other

product on the market that could match either its functionality (a suite of integrated

business applications for the various functions of a firm: Finance, Production, Human

Resources, etc.) or its technical architecture (R/3 had a client-server architecture at the time

when client-server architectures were fairly new but making dramatically rapid inroads on

mainframe and minicomputer architectures). Other subsequent vendors of ERP software

packages (PeopleSoft, Baan, Oracle, JD Edwards) were essentially followers and imitators

of SAP; SAP thus enjoyed a first-mover advantage and has consistently enjoyed a 30-40%

global market share in ERP installations, three times the share of the next-largest ERP

vendor, Oracle (Norris et al., 1998: Ch. 8; Rashid, Hossain, and Patrick, 2002). Its initial

monopoly allowed SAP to charge very high prices (typically about $2000-$3000 per

company employee for the basic license) while accumulating over 17,000 customers by

2001 (Rashid, Hossain, and Patrick, 2002: 10). Growing to over $3 billion in annual sales

since 1998, SAP has consistently remained the fourth-largest software company in sales,

behind only Microsoft, Oracle, and Computer Associates.

Although R/3 was SAP’s blockbuster product on world markets, it was not the first

SAP product that could be considered a GPT. R/3’s predecessor R/2 was likewise a suite

of integrated business software suitable for use by almost any firm in any industry. R/2

came be widely installed throughout corporate Germany in the 1980s, but outside the

German-speaking world R/2’s application was limited mainly to SAP’s bread-and-butter

industries of chemicals and petroleum (Plattner, 2000). In the 1980s the alternative to an

ERP system was simply not to have one at all and to rely instead on a patchwork of

13

heterogeneous business software systems that were loosely coupled rather than tightly

integrated. This was the route taken by most companies outside Germany prior to the

1990s, and of course loose coupling offers certain advantages (Orton and Weick, 1990;

Brusoni, Prencipe, and Pavitt, 2001).

The sudden preference of companies worldwide for the tightly integrated software

that SAP offered derived from a conjunction of supply and demand shifts. The transition to

client-server networks entailed a massive overhaul in corporate hardware systems, thus

providing a window of opportunity for one-time large-scale overhauls of corporate IT

systems in which accumulated legacy business software was jettisoned and replaced with a

unified ERP package. The Y2K scare exacerbated this tendency toward wholesale

replacement. Since “re-engineering” was in vogue in the 1990s, many companies

overhauled their business processes and IT systems in synch. As a cohort of Cooper &

Lybrand consultants put it, “an SAP software installation and a business process re-

engineering effort go hand in hand” (Norris et al., 1998: 7). Finally, SAP’s track record

was firmly established by the 1990s; the feasibility of tightly integrated software systems

(in contrast to loosely coupled patchworks) was now empirically demonstrated and

believed in by the critical partners of SAP, the Big Six accounting firms and IT consulting

companies.

A stylized representation of sectoral diffusion of ERP systems, based on the

experience path of SAP, is depicted in Figure 5. Chemical and petroleum firms were lead

adopters of ERP systems, followed by machinery makers. This can be seen in the customer

history of SAP. Its first customer (1972) was the newly established German subsidiary of

UK chemical giant ICI. SAP’s first foreign subsidiary was in Switzerland where SAP

14

predominantly served the Swiss chemical, pharmaceutical and machinery companies. The

first UK customer was ICI, while DuPont, Mobil and Dow Chemical were among the first

R/2 buyers in the US. Indeed, SAP expressly set up its first US subsidiary in Philadelphia

“so as to be near to the chemical and petroleum companies” (Plattner, 2000: 40). R/3 was

originally developed for medium-sized firms but soon proved a favorite of multinational

companies looking to coordinate their cross-border operations on client-server systems. In

addition to the core base of chemicals, petroleum and machines, manufacturers of food,

electronics, and computers were also rapid adopters of SAP’s ERP software.3 In contrast,

SAP software was slower to diffuse to service industries and the public sector. Especially

for government services, PeopleSoft was perceived to offer a more suitable product,

presumably on the basis of its own experience trajectory.

-- Insert Figure 5 About Here –

In the case of IT products, it makes sense to relate technology generalization not

only to generalization across industries, but also across hardware platforms. SAP’s early

products were tailored to IBM mainframes owned mainly by large companies. R/2 ran on

both IBM and Siemens mainframes. R/3, developed primarily in UNIX, was hardware-

independent and was suitable for large as well as for medium-sized companies, thus

allowing SAP to enlarge its customer base substantially. The evolution of SAP’s business

software from a specific purpose to a general purpose technology therefore consisted of

two main strands, namely increasing functional generality across industries and easier

portability across hardware platforms, both of which served to diffuse ERP systems more

15

widely. In the 1990s, hardware specifications ceased to be an important constraint. For

example, the process of porting R/3 onto Windows NT required only five days of coding

(Plattner, 2000: 42).

The following analysis provides an historical reconstruction of the design decisions

that transformed SAP’s business software into a GPT. Interestingly, the history of ERP

development at SAP reveals an-inverted U-curve in the level of technology generalization

over time, peaking in 1992 with the introduction of R/3. Thereafter, SAP actually began

introducing more industry-specific version of its software, thereby reversing the trend of

producing an ever more universal single standardized software package. The reasons for

this and its implication for our understanding of GPTs will be explored.

5. Evolution of Business Software Design at SAP

Methodology. The following reconstruction is based on a combination of

interviews with German IT experts and a variety of published sources. The author

interviewed the directors of two Fraunhofer Institutes specializing in information

technology and attended six industry association meetings and fairs in the German IT

sector to better understand the sectoral specificities of the German IT sector.4 SAP

permitted the author to attend an SAP-sponsored customer event in Berlin and conduct

brief interviews with a half dozen managers of SAP and SAP partner firms.5 SAP also

directed the author to two monographs that document the company’s history in

considerable detail on the basis of extensive interviews with top SAP managers (Meissner,

16

1997; Plattner, 2000). In the interest of verifiability, references to published sources will

be the preferred means of documenting the basic facts and conclusions derived below.

Background Information on Business Software. Until the 1990s, business processes

were considered too firm-idiosyncratic to permit standardization of business application

software other than for highly specialized tasks. Although standard software packages for

business did become common after 1969 (the date of IBM’s court-mandated unbundling of

hardware and software), these programs were function-specific (accounting, payroll, etc.).

All major ERP vendors started out selling function-specific software: SAP specialized

originally in accounting and purchasing, PeopleSoft in human resources, and Baan in

manufacturing (Meissner, 1997: 86-7; Rashid, Hossain, and Patrick, 2002). Packaged

software was co-specialized to specific hardware, with varying costs of portability across

hardware platforms.6

Reusable Software Code: SAP’s Original Idea. SAP was founded in Walldorf,

Germany by five ex-IBM programmers in 1972. At the time, computers were so expensive

that SAP had to conduct all of its product development on customer premises; SAP did not

own its own computer until 1980. Like many IT professionals in the 1970s, SAP’s first

manager-programmers had to store and transport their computer programs in boxes of

punch cards. If only for technical reasons, SAP’s early software programs had to be fairly

customized, given the need to optimize the use of costly CPU time and the fact that

reproducing software code was still relatively expensive; in other words, scale economies

were lower than in the PC era.

SAP’s basic strategy was to economize on coding costs by reusing algorithms as

programming work migrated from one customer to another. This strategy had to be

17

partially concealed, however, for the market at the time demanded that “you have to offer

users something specifically tailored to them” (firm founder Dietmar Hopp, cited in

Meissner, 1997: 48). In other words, SAP’s initial customers always believed they were

buying a specific purpose technology customized to their needs, which in part they were.

The economies of reusing code were so great that SAP often realized net profits of 50%

during the 1970s (Plattner, 2000: 22). Given the benefits of recycling software code, SAP

used its accumulated experience to enlarge the standardized core code with ever more

adjustable settings and parameters. By expanding the range of such settings and

parameters, SAP could reduce the amount of code that needed to be specially written for

each individual’s premises.

By way of illustration, SAP programmers developed parameters encompassing

language, time zone, tax laws and currency variables to serve the needs of multinational

companies. It was a locational advantage of SAP’s European base that the company had to

support multiple languages and tax laws from early on. One of the most significant product

enhancements resulted from the decision to support Japanese for R/2 in the 1980s, which

required developing a double-byte version of the entire software, the costliest engineering

modification SAP had ever engaged in until then. SAP took on the project because “the

German multinational chemical companies asked us to go to Japan, then DuPont asked us

to as well” (Plattner, 2000: 48). The result of this engineering change was that SAP’s

software could also support other languages requiring double-byte characters, such as

Chinese and Korean. SAP’s support of multiple currencies resulted in a competitive

advantage, since multiple currencies were “a complexity which US software has trouble

coping with” (Plattner, 2000: 49).

18

From Reusable Code to General Purpose Technology: R/2. By incorporating ever

more parameters to fit an ever greater variety of application environments, SAP’s business

software acquired an increasing level of functionality and application generality over time.

In 1979, SAP embarked on development of its first truly generic software suite, R/2. Its

outstanding characteristic was real-time entry and analysis of data on a time-sharing system

that served and integrated all of the firm’s different functions. Computer-generated reports

could be produced at any time, rather than, as was customary, at the end of the month when

printouts from different company IT systems were assembled and reconciled by human

analysts (Ceruzzi, 2003: Ch. 3).

Completed in 1981, R/2 was designed for mainframe systems using timeshare

terminals. Originally coded for IBM computers, R/2 was ported in the early 1980s onto a

common platform so that it could be installed on the mainframes of Siemens as well.

Within ten years, R/2 quietly conquered the German market for large-business software on

mainframes. The IT magazine Computerwoche noted in 1990: ‘Almost unnoticed by the

general public, SAP AG of Walldorf has acquired a quasi-monopoly in commercial

software for IBM-370 computers in the Federal Republic with the modular standard

software package R/2’ (Meissner, 1997: 53). At its height, R/2 had 2200 installations.

Its rapid diffusion notwithstanding, R/2 was costly to install. This was because

R/2’s general-purpose flexibility entailed a high level of product complexity. Each

installation necessitated years of parameter-setting to conform to specific customer

requirements. The installers of an R/2 or R/3 package typically fill out tens of thousands of

different tables over a process of 1-2 years; if ERP installation also coincides with a

process of business re-engineering, such an installation can take 2-4 years (Cooke and

19

Peterson, 1998; Norris et al., 1998). Indeed, R/2 and R/3 are so exceptional in their degree

of complexity that a normal installation utilizes only about 20% of the package’s total

functionality (Norris et al., 1998: 23).

Another implementation cost imposed by R/2 ensued from the requirement of

imposing homogenous terminology (common definitions, data sets, interfaces, etc.) across

sub-units within the company. Only so could R/2’s cross-functional capability be

operationalized. Given the high coordination, implementation, and complexity costs that

R/2 installation entailed, R/2 was only feasible in large companies whose business

processes were highly routine and relatively stable over time. Firms in Germany’s leading

industries generally fit this description. Germany has come to specialize in “medium-tech”

industries based on mature core technologies while lagging in faster-moving high-tech

industries (Casper, Lehrer, and Soskice, 1999; Siebert and Stolpe, 2002).7 Germany’s

home-country strength in chemicals, energy and machinery provided a good fit with ERP

software that was suited to highly codifiable and stable firm practices.

An outstanding feature of R/2, and inseparable from its character as a GPT, was the

level of abstraction that informed the product’s design. Most business software of the time

was designed to mirror existing practices in all of their functional idiosyncrasies. That is,

accounting software mirrored existing accounting practices, purchasing software was built

on existing purchasing practices, and so forth. One of Germany’s leading MIS professors,

August Wilhelm Scheer, recalled how SAP’s software transcended such tendencies through

unprecedented abstraction:

What especially impressed me was that the [SAP] data model made clear the parallel between purchasing and sales. Because more or less the same concepts

20

appear in both areas. With sales it’s called “customer,” with purchasing “supplier,” but in both you have bills, payment warnings, sales conditions, so that the whole structural similarity became clear. And I suddenly saw: this is a new approach to management thinking! This was the integration idea, that book value information like debit accounting belonged together with operative processes like sales. This involved different thinking from what we had in management school, where we were told something about financial accounting but where later in discussing operating issues like logistics the book values were no longer discussed. Both of these effects, integration and the formalization of representations, i.e. business modeling, got me interested in SAP (cited in Plattner, 2000: 82). The level of abstraction in ERP software increased in another aspect as well. As its

functional flexibility increased, SAP’s business software essentially evolved from a set of

programs into kind of operating system that required programming in order to become

functionally operative. The general-purpose nature of SAP’s software meant that R/2 and

R/3 did nothing when merely taken out of their box, but rather constituted a new IT layer

on top of which the firm-specific functionality had to be constructed as a separate layer of

parameters and supplemental software code.8 The process of abstraction is endemic to IT

development where multiple layers of software have accumulated to facilitate program

adjustments as well as to provide interfaces among different information and

communication systems. Indeed, IT developers actually use the term “abstraction layer” to

refer to a software program that provides a generic platform so that a given IT component

or layer can interface more easily with other IT components or layers.9

6. Complexity Limits to Technology Generalization, Part One: Scale – The Development

of R/3

21

For all intents and purposes, R/2 constituted a GPT. R/2 was a general purpose

software package that could and did diffuse to a variety of application sectors. ERP

technology continued to evolve, however. The further evolution of ERP systems sheds an

interesting light on bottlenecks entailed by the process of technology generalization. The

two bottlenecks of interest here are scale and implementation cost. The interesting aspect

of ERP systems, as experienced by leading developer SAP, was that the scale bottleneck

could be more or less overcome through design innovation, whereas the complexity

bottleneck could not. Design innovations were able to make ERP systems capable of

running on IT systems of any size, but they could not, in the final analysis, reduce the

complexity emanating from the diversity of task environments that ERP systems had to

operate in. SAP ultimately went back to developing more specific-purpose ERP software;

the result was an inverted U-shaped curve in the level of technological generality of SAP’s

ERP software over time.

The potential downside of technology generalization illustrated by ERP systems is

technical complexity. Since SAP achieved the broadening of application scope by adding

parameters to its ERP software, the ultimate result was a plethora of parameters and

settings that users had to make choices about. R/2 was predicated on the assumption that

only companies able to afford large mainframe computers could take on the effort and

expense of implementing ERP software. Following advances in hardware and new IT

architectures, SAP developed its next ERP product, R/3, to tap the market of medium-sized

firms; R/3 made ERP technology potentially accessible to companies of all but the lowest

size, as it could run on very large as well as very small IT systems. However, there was no

development from R/3 to any kind of R/4 that could overcome the implementation cost

22

bottleneck that had always dogged ERP systems. Instead of developing a new GPT called

R/4, SAP ultimately retreated from developing a single general-purpose ERP product and

began offering industry-specific versions of its ERP software. SAP overcame the scale

bottleneck by redesigning its GPT; it was not able to overcome the implementation cost

bottleneck in this way.

From Large to Scaleable GPT: R/3. SAP’s follow-up product, R/3, formed the

basis of its ERP market leadership beyond German borders. R/3 replaced the IBM-inspired

mainframe architecture of R/2 with UNIX-centered client-server architecture. Thanks to

this, R/3 was scalable, permitting the company’s ERP system to be augmented at will by

adding servers and clients. Through technical advances in PCs and microprocessors, the

power of client/server systems could equal that of mainframe systems. While SAP

managers did not foresee this turn of events, SAP in the early 1990s nonetheless found

itself with a monopoly on modular ERP systems that could run on a client/server

architecture. Serendipity played a major role in both the development and diffusion of R/3.

Development of R/3 began in 1988, when R/2 was slowly reaching saturation

within the German large-company market. In developing ERP software for medium-sized

companies, SAP originally conceived R/3 as a complement, not a successor to R/2. Even

when R/3 was introduced in 1992, SAP was unaware of the potential market of large

multinational companies for R/3. Expressed in GPT terms, SAP did not know, in

embarking on development of R/3, that it was about to generalize its ERP software from

large-firm applications to cover medium-sized firm applications as well. SAP did not

originally believe that a single ERP package could suit both large-firm and medium-sized

firm markets.

23

SAP’s ability to develop a GPT for firms of all sizes was demonstrably indebted to

the accumulation of new experience, albeit not so much in new application sectors as in

new IT programming environments. R/3 was not originally developed with UNIX,

Windows, PCs, workstations, or any of the other IT icons of the 1990s in mind.

Nonetheless, development work on R/3 did bring SAP into the realm of UNIX, relational

databases, and the programming language C, all part of the later hegemony of PC-based

client/server networks. SAP embarked on R/3 to follow the announced technology

trajectory of IBM, SAP’s primary hardware complementor. IBM had outlined its Systems

Application Architecture (SAA) as a method for creating overarching compatibility across

IBM equipment. Since IBM’s own operating system for SAA was not yet released, SAP

performed its development on a mixture of IBM and UNIX machines. R/3 ended up as a

UNIX-based system when the SAA program of IBM fell behind schedule. As coding of

R/3 neared completion, SAP found itself unable to make R/3 operational on IBM hardware.

It was a mixture of accumulated IT experience and unexpected crises that induced

SAP to generalize its ERP technology beyond IBM hardware specifications in 1991. SAP

was scheduled to present the debut of R/3 at the 1991 CeBIT fair in Hanover, yet only six

weeks before the fair SAP determined that it could not do so on IBM equipment. Rather

than cancel its presentation, SAP elected to engage in massive technical improvisation to

save face. Having just received new UNIX workstations, SAP managers scrambled to port

R/3 onto one of them. The unanticipated outcome was that R/3, a gigantic software

package designed to run on IBM 370 mainframes, actually fit entirely onto a single

workstation:

The only lie we told [at the Hanover fair] was this. R/3 itself was on the machine. It was a lie, because we said the R/3 system is in Walldorf on the mainframe, this

24

here is just the UNIX terminal. The truth was that the whole R/3 system ran locally in this tiny machine … We had to hide this sensation; nobody at the time could have comprehended it. (Plattner, 2000: 98-9) In preparing for the CeBIT fair, SAP deepened its experience with UNIX-based

equipment and awareness of what technological progress in workstations and PCs was

achieving. SAP’s management admitted that, due to its IBM orientation, “we almost

missed the PC because we thought it was a toy” (Plattner, 2000: 46). Shortly after the

Hanover fair some SAP customers began expressing interest in UNIX-based systems,

which previously were used mainly in academic institutions. A maneuver to save face at

the CeBIT fair thus resulted in a new design trajectory for R/3. SAP ended up developing

R/3 specifically for UNIX rather than for IBM equipment. By 1992 SAP was able to roll

out R/3 on UNIX machines independently of any manufacturer. By 1993, it was clear that

R/3 would scale higher than R/2 with improvements in hardware; in that year, a version of

R/3 for Windows NT was developed.

Though SAP initially sold R/3 as planned to medium-sized firms, Chevron’s

surprise purchase of R/3 opened SAP’s eyes to the potential of client/server ERP systems

for large firms. Thereafter R/3 diffused rapidly among sought by global companies looking

to integrate their cross-border operations on increasingly standardized server and PC

hardware. In the years 1990-1999, SAP’s turnover increased 20-fold from DM 500 million

to over DM 10 billion (5 billion Euro).

One final design detail is worth mentioning. In converting R/3 to a UNIX-based

client/server system, SAP pioneered the three-tier client-server architecture that has now

become common (Rashid, Hossain, and Patrick, 2002). In the early 1990s, client/server

architectures were mainly two-tier: either “fat-client” or “fat-server.” SAP’s three-tier

25

architecture places the database on a centralized server (“database level”) and the user

interface on the clients (“presentation level”). SAP’s design innovation, emanating from

trial and error in development of R/3, was to place the applications on an intermediate level

of decentralized servers (“application level”). The advantage of this design, later emulated

throughout the IT industry, was that it avoided informational traffic jams in accessing

applications.

7. Complexity Limits to Technology Generalization, Part Two: Implementation Cost – The

Development of Industry Solutions

The increasing application generality of ERP software came at the expense of

greater product complexity. The fact that most SAP installations use only about 20% of the

package’s total functionality are an indication of this complexity. Anything but a plug-and-

play product, R/3 encompasses about 25,000 different tables that can be filled out

(“parameterization”) to permit customization of the product to a given customer’s premises.

Such complexity entails high implementation costs, including supplemental software

coding to perform customer-specific tasks not covered within the R/3 package. One large-

scale survey estimated SAP installations in the US to cost an average of $20 million, with

larger firms frequently spending over $100 million (Cooke and Peterson, 1998). Of this,

only 14% on average was for the software license; 70% of the total cost went toward

implementation and 16% toward hardware. This mirrors the ERP rule-of-thumb that the

cost of implementing ERP software generally runs above five times the purchase price of

the basic software license (Schwarz, 2000: 27). In fact, the most widespread criticism of

26

SAP (and other ERP systems) concerns precisely their complexity, which almost always

requires SAP or (more often) an external accounting, consulting or IT company to play a

major hand in ERP implementation. An article specifically charging that R/3’s “high

system complexity results in inflexibility” was widely cited in the German business press,

much to SAP’s chagrin (Meissner, 1997: 139). The evolution of ERP software illustrates

the possible trade-off between complexity and generality of technology.

Not surprisingly, then, a major strategic effort of SAP since the mid 1990s centered

on reducing the complexity and cost of implementing R/3. An example is Accelerated SAP

(ASAP), a methodology for implementing SAP in 6-9 months (rather than 2-4 years) for

customers of moderate size and business complexity. More telling, however, are SAP’s

growing set of “industry solutions,” namely supplementary modules designed to suit the

requirements of users in specific industries. Such industry solutions, developed in

collaboration with key users and consulting partners, help users economize on the amount

of parameterization and supplementary coding required by ERP implementation.

One can regard such industry-specific modules as a step backward from prior efforts by

SAP to upgrade its ERP software into an ever more universal, one-size-fits-all technology.

Instead, the application universality of SAP’s ERP software peaked with the introduction of

R/3, while many subsequent developments essentially involve customization of R/3 to

different industries. Such industry solutions have been developed for the following sectors:

• Aerospace and defense • Automotive • Banking • Chemicals • Consumer products • Engineering and production • Health care

27

• High tech and electronics • Insurance • Oil and gas • Pharmaceuticals • Public sector • Retail • Telecommunications • Utilities

SAP’s shift to industry-specific versions of its ERP software amounts to a reversion to the

classic case of a GPT that needs to be tailored to industry-specific applications. The

industry solutions are overlays placed on top of the generic R/3 software; they are

essentially semi-customizations designed to lessen the burden of installation in specific

industries. SAP’s industry solutions constitute industry-specific investments in the basic

GPT, thereby conforming to the original conception of GPTs as technologies whose use in

specific application sectors requires supplementary sector-specific investment (Bresnahan

and Trajtenberg, 1995).

The process of technology generalization can thus be limited by complexity

constraints. The level of technological generality of ERP systems at SAP reveals

something of an inverted U-curve, with generality across industries and hardware platforms

rising and peaking with the introduction of R/3 in 1992, but decreasing thereafter with the

continuing introduction of new industry-specific modules from the mid 1990s on. Within

the company, the willingness to back away from an all-encompassing single product

involved something akin to a strategic inflection point (Burgelman and Grove, 1996) in

which variations were accepted precisely as variants and not as additional variables

needing to be programmed as new parameters in the basic package:

28

We always had a deep fear of them [variants] … We always had this fear and in historical perspective it came into our heads as we transformed R/1 into R/1.5 on IMS … So it is now an important process that is taking place and must take place with us, that we recognize variants simply as such and not compulsively make a simple variant into a complex one that is close to generic in nature (Plattner, 2000: 133-4). Another way to put the matter is that SAP encountered initially increasing and later

diminishing returns to technology generalization. Analogous patterns can probably also be

found in many histories of product standardization, though technology generalization is not

always the same kind of process: whereas standardization endeavors to homogenize a

product across application areas, technology generalization can also aim at enhancing the

product’s capability to perform heterogeneous tasks across a variety of environments.

8. Conclusion: Technology generalization and dominant designs

ERP systems constitute a class of GPTs for which the economic bind posed by

innovation complementarities is less significant than for dynamos and transistors whose

invention in the laboratory preceded industrial application. One can almost say of ERP

software that innovation preceded invention: it was in the act of reusing and enlarging

software code that a general purpose technology emerged in stages out of a specific

purpose one. Thus, ERP belongs to a class of general purpose technologies that palliate the

externality problem by originating as an economically feasible technology in a specific

sector and diffuse with decreasing marginal costs of adoption in other sectors, leaving in its

wake an accumulation of experience that can be used to broaden the design of the

technology to fit an increasing range of applications. We called this process technology

generalization.

29

The technology generalization process bears some resemblance to the

crystallization of a dominant design. A dominant design constitutes a key step in the

maturation of a new technology from one that is used in many changing variants to one

whose basic design is both stable and suitable for wide-scale application (Abernathy and

Utterback, 1978; Anderson and Tushman, 1990). Dominant designs facilitate serial

production. Prior to a dominant design, heterogeneity in supply and demand engenders

high production costs and prices, whereas the emergence of such a design permits

economies of scale and ultimately significant price reductions. The process of technology

generalization likewise facilitates serial production. In standard software products, of

course, scale economies are particularly pronounced.

In many cases, the dominant design can be seen as the logical and economic

endpoint of the technology generalization process. The dominant design is not to be

confused with a hit product like SAP’s R/3. Rather, the dominant design applies to general

product characteristics across vendors. In the case of ERP systems, such a design clearly

materialized. Rashid et al. (2002: 7-8) list the major characteristics of ERP systems as

follows:

• Modular design comprising many distinct business modules such as financial, manufacturing, accounting, distribution, etc.

• Use centralized common database management system (DBMS)

• The modules are integrated and provide seamless data flow among the modules, increasing operational transparency through standard interfaces…

The general practice is to have three-tier architecture:

• Presentation Layer: graphical user interface (GUI) or browser of data entry or accessing system functions;

• Application Layer: business rules, functions, logic, and programs acting on data received/transferred from/to the database servers;

30

• Database Layer: management of the organization’s operational or transactional data including metadata; mostly employs industry standard RDBMS with structured query language (SQL) provisions. (Rashid, Hossain, and Patrick, 2002: 7-8)

The quoted description of typical state-of-the-art ERP systems amounts to a list of the

major design decisions made by SAP and subsequently imitated by SAP’s followers. SAP

pioneered the integration of functional modules on top of a centralized database using

precisely the three-tier architecture of presentation, application, and database layers.

Nonetheless, these core design characteristics do not really capture the specific effects of

technology generalization in the evolution of ERP systems. The cross-sectoral suitability

of modern ERP systems like SAP’s R/3 depends principally on the programmed flexibility

within the various modules themselves (finance, manufacturing, etc.) rather than on the

software package’s overall product architecture. From the foregoing case study on SAP it

can be reasonably conjectured that this programmable flexibility resulted more from the

accumulated experience of writing business software than from general IT design decisions

governing the overall product architecture. In fact, the principles of customizable standard

business application software that informed SAP’s product development were entirely

foreign to the established principles of software engineering at the time (Plattner, 2000:

190).

This raises the final question of whether technology generalization as defined here

is useful primarily for analysis of “programmable” products like software. Certainly one

recurrent strand in the history of software engineering progress consists in techniques to

leverage the easy reuse of code through subroutines, object-oriented programming, and so

forth. Many of the most useful computer programs are not those that perform the final user

31

functions, but are themselves tools to write other programs, the obvious example being

programming languages like FORTRAN, C, and Java. This fact has resulted in an

accumulation of programming layers in IT systems, illustrating the famous von Neumann

principle of the nonseparability of programs and data. Without a doubt, large-scale ERP

software packages fit into this trend. Requiring extensive parameterization and

customization, they are in some ways more like programming tools than final user

programs. They constitute additional layers in corporate IT systems in the sense that the

specific business functions have to be programmed on top of a generic ERP software

package like R/3.

However, one reason for thinking that technology generalization is not a software-

specific phenomenon is precisely that programming and programmability are not specific to

software. Programs are at the core of all complex systems, social, managerial, and

biological (Beniger, 1986). It is not just that antecedents of software go back to at least the

Jacquard loom with its manually programmable weaving patterns. A growing number of

scholars have concluded that the so-called information revolution forms a continuum with

the industrial revolution (Yates, 1989; Chandler and Cortada, 2000; Freeman and Louca,

2001). Technological advances in production since the 18th century have repeatedly

created the need for new means to coordinate and control larger-scale systems (Chandler,

1977; Beniger, 1986). The history of management is largely the history of coordination

and control technologies, and it is probably in the context of such technologies that ERP

systems are to be placed.

In whatever sectors new control and coordination technologies have emerged, the

potential to utilize them in other sectors (i.e. the potential for technology generalization)

32

has always been latent. For example, the technology of interchangeable parts began in

military hardware and remained largely confined to this sector for fifty years before

diffusing widely to other sectors (Hounshell, 1984). Similarly, the history of modern

managerial hierarchies using information technology to coordinate complex production

systems began with railroad companies using the telegraph and new principles of

organization that later diffused to other sectors (Chandler, 1977). Perhaps the most

spectacular example of technology generalization is the assembly line, generally thought to

have originated in meatpacking before making its spectacular breakthrough in Ford’s auto

works. The diffusion of the assembly line through many industries in the 20th century

subsequently demonstrated how this GPT had hardware components (physical

contraptions) as well as what one could broadly call “software” (here: managerial

practices). Assembly lines and ERP systems alike require that a basic tool be customized

to the firm’s particular context and implemented with a deep set of experience-based

managerial skills. Like ERP systems, the assembly line is no plug-and-play product.

33

REFERENCES Abernathy, W.J. and J.M. Utterback 1978 "Patterns of industrial innovation." Technology Review, 80(7): 40-47. Anderson, P. and M.L. Tushman 1990 "Technological discontinuities and dominant designs: A cyclical model of technological change." Administrative Science Quarterly, 35: 604-633. Beise, M. 2001 Lead markets: Country-specific success factors of the global diffusion of innovations. Heidelberg: Physica-Verlag. Beniger, J.R. 1986 The control revolution: Technological and economic origins of the information society. Cambridge, MA: Harvard University Press. Braun, E. and S. MacDonald 1978 Revolution in miniature: The history and impact of semiconductor electronics. Cambridge: Cambridge University Press. Bresnahan, T. and A. Gambardella 1998 "The division of inventive labor and the extent of the market." In E. Helpman (ed.), General purpose technologies and economic growth: 253-281. Cambridge, MA: MIT Press. Bresnahan, T.F. and M. Trajtenberg 1992 "General purpose technologies: "Engines of growth?"." Working Paper, NBER. Bresnahan, T.F. and M. Trajtenberg 1995 "General purpose technologies: "Engines of growth"?" Journal of Econometics, 65: 83-108. Brusoni, S., A. Prencipe, and K. Pavitt 2001 "Knowledge specialization, organizational coupling, and the boundaries of the firm: Why do firms know more than they make?" Administrative Science Quarterly, 46: 597-621. Burgelman, R.A. and A.S. Grove 1996 "Strategic dissonance." California Management Review, 38(2): 8-26. Casper, S., M. Lehrer, and D. Soskice

34

1999 "Can high-technology industries prosper in Germany? Institutional frameworks and the evolution of the German software and biotechnology industries." Industry and Innovation, 6(1): 5-24. Ceruzzi, P.E. 2003 A history of modern computing. Cambridge, MA: MIT Press. Chandler, A.D. 1977 The visible hand: The managerial revolution in American business. Cambridge, MA: Harvard University Press. Chandler, A.D. and J.W. Cortada (ed.) 2000 A nation transformed by information: How information has shaped the United States from colonial times to the present. Oxford: Oxford University Press. Cooke, D.P. and W.J. Peterson 1998 SAP implementation: Strategies and results. New York: The Conference Board. Curran, T. and G. Keller 1998 SAP R/3 business blueprint. Upper Saddle River: Prentice Hall PTR. David, P.A. 1990 "The dynamo and the computer: An historical perspective on the modern productivity paradox." American Economic Review, Papers and Procedings, 80(2): 355-361. Feldenkirchen, W. 1997a Siemens: Von der Werkstatt zum Weltunternehmen. Munich: Piper. Feldenkirchen, W. 1997b Werner von Siemens: Inventor and international entrepreneur. Columbus: Ohio State University Press. Freeman, C. and F. Louca 2001 As time goes by: From the industrial revolution to the information revolution. Oxford: Oxford University Press. Freeman, C. and C. Perez 1988 "Structural crises of adjustment, business cycles, and investment behavior." In G. Dosi et al. (ed.), Technical Change and Economic Theory: 38-66. London: Pinter. Gibbons, M. et al. 1994 The new production of knowledge: The dynamics of science and research in contemporary societies. London: Sage. Helpman, E. (ed.) 1998 General purpose technologies and economic growth. Cambridge, MA: MIT Press.

35

Helpman, E. and M. Trajtenberg 1998a "A time to sow and a time to reap: Growth based on general purpose technologies." In E. Helpman (ed.), General purpose technologies and economic growth: 55-83. Cambridge, MA: MIT Press. Helpman, E. and M. Trajtenberg 1998b "Diffusion of general purpose technologies." In E. Helpman (ed.), General purpose technologies and economic growth: 85-119. Cambridge, MA: MIT Press. Hounshell, D.A. 1984 From the American system to mass production 1800-1932. Baltimore: Johns Hopkins University Press. Lehrer, M. 2005 "Two Types of Organizational Modularity: SAP, ERP Product Architecture and the German Tipping Point in the Make/Buy Decision for IT Services." In D. Grimshaw and M. Miozzo (eds.), Knowledge intensive services and changing organizational forms: Cheltenham: Edwad Elgar. Lipsey, R.G., C. Bekar, and K. Carlaw 1998 "What requires explanation?" In E. Helpman (ed.), General purpose technologies and economic growth: 15-54. Cambridge, MA: MIT Press. Little, A.D. 1933 "Chemical engineering research: Lifeblood of American industry." In S.D. Kirkpatrick (ed.), Twenty-Five Years of Chemical Engineering Progress. New York: American Institute of Chemical Engineers. Meissner, G. 1997 SAP - Die heimliche Software-Macht. Hamburg: Hoffmann und Campe. Mokyr, J. 1990 The lever of riches: Technology, creativity and economic progress. Oxford: Oxford University Press. Norris, G. et al. 1998 SAP: An executive's comprehensive guide. New York: John Wiley & Sons. Orton, J.D. and K.E. Weick 1990 "Loosely coupled systems: A reconceptualization." Academy of Management Review, 15: 203-223. Passer, H.C. 1953 The electrical manufacturers 1875-1900. Cambridge, MA: Harvard University Press.

36

Plattner, H. 2000 Dem Wandel voraus. Bonn: Galileo Press. Rashid, M.A., L. Hossain, and J.D. Patrick 2002 "The evolution of ERP systems: A historical perspective." In L. Hossain, J.D. Patrick, and M.A. Rashid (eds.), Enterprise resource planning: Global opportunities and challenges: 1-16. Hershey: Idea Group Publishing. Rosenberg, N. 1972 Technology and American economic growth. New York: Harper. Rosenberg, N. 1976 Perspectives on technology. Cambridge: Cambridge University Press. Rosenberg, N. 1998 "Chemical engineering as a general purpose technology." In E. Helpman (ed.), General purpose technologies and economic growth: 167-192. Cambridge, MA: MIT Press. Rosenberg, N. and M. Trajtenberg 2001 "A general purpose technology at work: The Corliss steam engine in the late 19th century US." Working Paper, CEPR. Schumpeter, J.A. 1939 Business cycles: A theoretical, historical and statistical analysis of the capitalist process. New York: McGraw-Hill. Schwarz, M. 2000 ERP-Standardsoftware und organisatorischer Wandel. Wiesbaden: Deutscher Universitäts-Verlag. Siebert, H. and M. Stolpe 2002 "Germany." In B. Steil, D.G. Victor, and R.R. Nelson (eds.), Technological innovation and economic performance: 112-147. Princeton: Princeton University Press. Stigler, G.J. 1951 "The division of labor is limited by the extent of the market." Journal of Political Economy, 54(3): 185-193. Trescott, M.M. 1982 "Unit operations in the chemical industry: An American innovation in modern chemical engineering." In W.F. Furter (ed.), A century of chemical engineering: 1-18. New York: Plenum Press. Tushman, M.L. and P. Anderson 1986 "Technological discontinuities and organizational environments." Administrative Science Quarterly, 31: 439-465.

37

Utterback, J.M. 1994 Mastering the dynamics of innovation. Boston: Harvard Business School Press. von Hippel, E. 1988 The Sources of Innovation. New York: Oxford University Press. Yates, J. 1989 Control through communication: The rise of system in American management. Baltimore: Johns Hopkins University Press. Zysman, J. and L. Tyson 1983 American industry in international competition: Government policies and corporate strategies. Ithaca: Cornell U. Press.

38

Figure 1: Generic Framework of GPTs

GPT

AS1 AS2 AS3 AS4

GPT = General Purpose Technology

AS = Application Sector

Source: Bresnahan & Trajtenberg, 1992

Figure 2: Top-Down Diffusion Pattern

Transistor

Hearing Aids

Computers Radios Telecom

Basis: Bresnahan & Trajtenberg, 1992; Helpman & Trajtenberg, 1998

General Purpose Technology:

Autos

Early Adopting Application Sectors:

Later Adopting Application Sectors:

39

Figure 3: Bottom-Up Diffusion Pattern

GPT

AS1

Application Sectors for Newly Developed GPT

SPT

AS2 AS3 AS4 AS5

GPT = General Purpose

Technology

SPT = Special Purpose

Technology

Application Sectors for Technological Generalization of

SPT into a GPT

design in

novation

Figure 4: Development of Milling Machines

Universal Milling

Machine

Firearms

Application Sectors for Universal Milling

Machines

Basis: Rosenberg, 1972

Lincoln Miller

Sewing Machines

Textiles Trains Etc.

General Purpose

Technology

Dominant Design For Firearms

Production

Application Sectors for Technological Generalization of

Milling Machines

design innovation

40

Figure 5: ERP Development at SAP

R/2 & R/3

Chemicals/ Petroleum

Application Sectors for Newly Developed ERP

System Software

Basis: Plattner, 2001

R/1

Machinery MNCs High Tech

R/2 and R/3 = General Purpose

Technology

R/1 = Special Purpose

Technology (But With Reusable

Components)

Application Sectors for Technological Generalization of

SAP’s Business Software

Etc.

design

innova

tion

41

42

ENDNOTES

1 For example, Rosenberg and Trajtenberg (2001) show how George Corliss devised a variation of the19th-

century steam engine that was suitable for more delicate uses in textile manufacturing.

2 This is not to deny alternative interpretations of how the concept of unit operations arose. For example,

Trescott (1982) connects Little’s concept of unit operations to contemporaneous ideas of scientific

management and mass production.

3 A good idea of the sectors of early diffusion can be gleaned from an SAP primer which claims that as of

June 1996, the list of Fortune 500 American companies using SAP software included: “7 of the top 10

pharmaceutical companies; 7 of the top 10 computer companies; 7 of the top 10 petroleum companies; 6 of

the top 10 electronics companies; 8 of the top 10 chemical companies; 8 of the top 10 food companies”

(Curran and Keller, 1998: xxi)

4 The institutes were the Fraunhofer Institute for Computer Graphics (Darmstadt) and the Fraunhofer Institute

for Software and Systems Engineering (Berlin). 5 The gracious intervention of Barry Nalebuff in this matter is gratefully acknowledged.

6 While versions of high-level languages like FORTRAN might not vary greatly in semantics across different

mainframe manufacturers, the configuration of data storage and input/output devices could vary substantially,

making complete rewrites of the software necessary.

7 In other words, SAP benefited from a domestic industrial environment in which firm processes were more

standardized and, in all likelihood, more explicitly codified than in other countries. See Lehrer (2005).

8 SAP actually supplies its own high-level programming language, ABAP, to code tasks that are beyond the

scope of the software package’s generic capabilities; the percentage of specially programmed code frequently

comprises up to 10% of the total ERP installation code.

9 Abstraction layers are abstract in the sense that they convert the product-specific parameters of IT

components into more generic terms.

Our responsibility is to provide strong academic programs that instill excellence,confidence and strong leadership skills in our graduates. Our aim is to (1)promote critical and independent thinking, (2) foster personal responsibility and(3) develop students whose performance and commitment mark them as leaderscontributing to the business community and society. The College will serve as acenter for business scholarship, creative research and outreach activities to thecitizens and institutions of the State of Rhode Island as well as the regional,national and international communities.

Mission

The creation of this working paper serieshas been funded by an endowmentestablished by William A. Orme, URICollege of Business Administration,Class of 1949 and former head of theGeneral Electric Foundation. This workingpaper series is intended to permit facultymembers to obtain feedback on researchactivities before the research is submitted toacademic and professional journals andprofessional associations for presentations.

An award is presented annually for the mostoutstanding paper submitted.

Founded in 1892, the University of Rhode Island is one of eight land, urban, and sea grantuniversities in the United States. The 1,200-acre rural campus is lessthan ten miles from Narragansett Bay and highlights its traditions ofnatural resource, marine and urban related research. There are over14,000 undergraduate and graduate students enrolled in seven degree-granting colleges representing 48 states and the District of Columbia.More than 500 international students represent 59 different countries.Eighteen percent of the freshman class graduated in the top ten percentof their high school classes. The teaching and research faculty numbersover 600 and the University offers 101 undergraduate programs and 86advanced degree programs. URI students have received Rhodes,

Fulbright, Truman, Goldwater, and Udall scholarships. There are over 80,000 active alumnae.

The University of Rhode Island started to offer undergraduate businessadministration courses in 1923. In 1962, the MBA program was introduced and the PhDprogram began in the mid 1980s. The College of Business Administration is accredited byThe AACSB International - The Association to Advance Collegiate Schools of Business in1969. The College of Business enrolls over 1400 undergraduate students and more than 300graduate students.

Ballentine HallQuadrangle

Univ. of Rhode IslandKingston, Rhode Island