At the turn of the century, Frederick Taylor revolutionized the workplace with his ideas on work organization, task decomposition, and job measurement. Taylor's basic aim was to increase organizational productivity by applying to human labor the same engineering principles that had proven so successful in solving the technical problems in the work environment. The same approaches that had transformed mechanical activity could also be used to structure jobs performed by people. Taylor came to symbolize the practical realizations in industry that we now call industrial engineering (IE), or the scientific school of management.1 In fact, though work design remains a contemporary IE concern, no subsequent concept or tool has rivaled the power of Taylor's mechanizing vision.

As we enter the 1990s, however, two newer tools are transforming organizations to the degree that Taylorism once did. These are information technology–the capabilities offered by computers, software applications, and telecommunications–and business process redesign–the analysis and design of work flows and processes within and between organizations. Working together, these tools have the potential to create a new type of industrial engineering, changing the way the discipline is practiced and the skills necessary to practice it.

This article explores the relationship between information technology (IT) and business process redesign (BPR). We report on research conducted at MIT, Harvard, and several consulting organizations on nineteen companies, including detailed studies of five firms engaged in substantial process redesign. After defining business processes, we extract from the experience of the companies studied a generic five-step approach to redesigning processes with IT. We then define the major types of processes, along with the primary role of IT in each type of process. Finally, we consider management issues that arise when IT is used to redesign business processes.

IT in Business Process Redesign

The importance of both information technology and business process redesign is well known to industrial engineers, albeit as largely separate tools for use in specific, limited environments.2 IT is used in industrial engineering as an analysis and modeling tool, and IEs have often taken the lead in applying information technology to manufacturing environments. Well-known uses of IT in manufacturing include process modeling, production scheduling and control, materials management information systems, and logistics. In most cases where IT has been used to redesign work, the redesign has most likely been in the manufacturing function, and industrial engineers are the most likely individuals to have carried it out.

IEs have begun to analyze work activities in non-manufacturing environments, but their penetration into offices has been far less than in factories. IT has certainly penetrated the office and services environments–in 1987 Business Week reported that almost 40 percent of all U.S. capital spending went to information systems, some $97 billion a year– but IT has been used in most cases to hasten office work rather than to transform it.3 With few exceptions, IT's role in the redesign of non-manufacturing work has been disappointing; few firms have achieved major productivity gains.4 Aggregate productivity figures for the United States have shown no increase since 1973.5

Given the growing dominance of service industries and office work in the Western economies, this type of work is as much in need of analysis and redesign as the manufacturing environments to which IT has already been applied. Many firms have found that this analysis requires taking a broader view of both IT and business activity, and of the relationships between them. Information technology should be viewed as more than an automating or mechanizing force; it can fundamentally reshape the way business is done. Business activities should be viewed as more than a collection of individual or even functional tasks; they should be broken down into processes that can be designed for maximum effectiveness, in both manufacturing and service environments.

Our research suggests that IT can be more than a useful tool in business process redesign. In leading edge practice, information technology and BPR have a recursive relationship, as Figure 1 illustrates. Each is the key to thinking about the other. Thinking about information technology should be in terms of how it supports new or redesigned business processes, rather than business functions or other organizational entities. And business processes and process improvements should be considered in terms of the capabilities information technology can provide. We refer to this broadened, recursive view of IT and BPR as the new industrial engineering.

Taylor could focus on workplace rationalization and individual task efficiency because he confronted a largely stable business environment; today's corporations do not have the luxury of such stability.6 Individual tasks and jobs change faster than they can be redesigned. Today, responsibility for an outcome is more often spread over a group, rather than assigned to an individual as in the past. Companies increasingly find it necessary to develop more flexible, team-oriented, coordinative, and communication-based work capability. In short, rather than maximizing the performance of particular individuals or business functions, companies must maximize interdependent activities within and across the entire organization. Such business processes are a new approach to coordination across the firm; information technology's promise–and perhaps its ultimate impact–is to be the most powerful tool in the twentieth century for reducing the costs of this coordination.7

What Are Business Processes?

We define business processes as a set of logically related tasks performed to achieve a defined business outcome. This definition is similar to Pall's: "The logical organization of people, materials, energy, equipment, and procedures into work activities designed to produce a specified end result (work product)."8

A set of processes forms a business system – the way in which a business unit, or a collection of units, carries out its business. Processes have two important characteristics:

• They have customers; that is, processes have defined business outcomes, and there are recipients of the outcomes. Customers may be either internal or external to the firm.
• They cross organizational boundaries; that is, they normally occur across or between organizational subunits. Processes are generally independent of formal organizational structure.

Common examples of processes meeting these criteria include:

• developing a new product;
• ordering goods from a supplier;
• creating a marketing plan;
• processing and paying an insurance claim; and
• writing a proposal for a government contract.

Ordering goods from a supplier, for example, typically involves multiple organizations and functions. The end user, purchasing, receiving, accounts payable, etc., and the supplier organization are all participants. The user could be viewed as the process's customer. The process outcome could be either the creation of the order, or, perhaps more usefully the actual receipt of the goods by the user.

Our examples so far are of large-scale processes that affect whole organizations or groups. There are more detailed processes that meet the definitional criteria above. These might include installing a windshield in an automobile factory, or completing a monthly departmental expense report. IT-driven process redesign can be applied to these processes, but the implications of redesigning them may be important only in the aggregate. In many of the firms studied, analyzing processes in great detail was highly appropriate for some purposes, for example, the detailed design of an information system or data model to support a specific work process. However, the firms that were truly beginning to redesign their business functions took a broader view of processes.

A Brief History of Process Thinking

Process thinking has become widespread in recent years, due largely to the quality movement. Industrial engineers and others who wish to improve the quality of operations are urged to look at an entire process, rather than a particular task or business function. At IBM, for example, "process management will be the principal IBM quality focus in the coming years."9 But process discussions in the quality movement's literature rarely mention information technology. Rather, the focus is usually on improving process control systems in a manufacturing context; when IT is discussed, it is in the context of factory floor automation. Recent IE literature also borders on process thinking when advocating cross-functional analysis,10 although, as we will discuss, cross-functional processes are only one possible type of process.

Other than quality-oriented manufacturing process redesign, most processes in major corporations have not been subject to rigorous analysis and redesign. Indeed, many of our current processes result from a series of ad hoc decisions made by functional units, with little attention to effectiveness across the entire process. Many processes have never even been measured. In one manufacturing company studied, for example, no one had ever analyzed the elapsed time from a customer's order to delivery. Each department (sales, credit checking, shipping, and so on) felt that it had optimized its own performance, but in fact the overall process was quite lengthy and unwieldy.

Even fewer business processes have been analyzed with the capabilities of IT in mind. Most business processes were developed before modern computers and communications even existed. When technology has been applied, it is usually to automate or speed up isolated components of an existing process. This creates communication problems within processes and impediments to process redesign and enhancement. For example, in a second manufacturing firm studied, the procurement process involved a vendor database, a materials management planning system, and accounts payable and receivable systems, all running on different hardware platforms with different data structures. Again, each organizational subunit within the process had optimized its own IT application, but no single subunit had looked at (or was responsible for) the entire process. We believe the problems this firm experienced are very common.

Redesigning Business Processes with IT: Five Steps

Assuming that a company has decided its processes are inefficient or ineffective, and therefore in need of redesign, how should it proceed? This is a straightforward activity, but five major steps are involved: develop the business vision and process objectives, identify the processes to be redesigned, understand and measure the existing process, identify IT levers, and design and build a prototype of the new process (see Figure 2). We observed most or all of these steps being performed in companies that were succeeding with BPR. Each step is described in greater detail below.

Develop Business Vision and Process Objectives

In the past, process redesign was typically intended simply to "rationalize" the process, in other words, to eliminate obvious bottlenecks and inefficiencies. It did not involve any particular business vision or context. This was the approach of the "work simplification" aspect of industrial engineering, an important legacy of Taylorism. An example of the rationalization approach appears in a 1961 "Reference Note on Work Simplification" from the Harvard Business School:

A good manager asks himself why things are done as they are, extending his inquiry to every aspect of the job and the surroundings in which it is performed, from the flow of paper work to the daily functioning of his subordinates. . . . He is expected to supply the stimulus and show that job improvement or simplification of work is not only important but also is based on commonsense questioning aimed at uncovering the easiest, most economical way of performing a job.11

Our research suggests strongly that rationalization is not an end in itself, and is thus insufficient as a process redesign objective. Furthermore, rationalization of highly decomposed tasks may lead to a less efficient overall process. Instead of task rationalization, redesign of entire processes should be undertaken with a specific business vision and related objectives in mind.

In most successful redesign examples we studied, the company's senior management had developed a broad strategic vision into which the process redesign activity fit.12 At Xerox, for example, this vision involved taking the perspective of the customer and developing systems rather than standalone products; both required cross-functional integration. At Westinghouse, the vision consisted largely of improving product quality. Fords involved adopting the best practices of Japanese automobile manufacturers, including those of Mazda, of which it is a partial owner.

Each of these visions implied specific objectives for process redesign. The most likely objectives are the following:

• Cost Reduction. This objective was implicit in the "rationalization" approach. Cost is an important redesign objective in combination with others, but insufficient in itself. Excessive attention to cost reduction results in tradeoffs that are usually unacceptable to process stakeholders. While optimizing on other objectives seems to bring costs into line, optimizing on cost rarely brings about other objectives.
• Time Reduction. Time reduction has been only a secondary objective of traditional industrial engineering. Increasing numbers of companies, however, are beginning to compete on the basis of time.13 Processes, as we have defined them, are the ideal unit for a focused time reduction analysis. One common approach to cutting time from product design is to make the steps begin simultaneously, rather than sequentially, using IT to coordinate design directions among the various functional participants. This approach has been taken in the design of computers, telephone equipment, automobiles, and copiers (by Digital Equipment, AT&T Bell Labs, Ford, and Xerox, respectively).
• Output Quality. All processes have outputs, be they physical – such as in manufacturing a tangible product–or informational–such as in adding data to a customer file. Output quality is frequently the focus of process improvement in manufacturing environments; it is just as important in service industries. The specific measure of output quality may be uniformity, variability, or freedom from defects; this should be defined by the customer of the process.
• Quality of Worklife (QWL)/Learning/Empowerment. IT can lead either to greater empowerment of individuals, or to greater control over their output. Zuboff points out that IT-intensive processes are often simply automated, and that the "informating" or learning potential of IT in processes is often ignored.14 Moreover, Schein notes that organizations often do not provide a supportive context for individuals to introduce or innovate with IT15 Of course, it is rarely possible to optimize all objectives simultaneously, and in most firms, the strongest pressures are to produce tangible benefits. Yet managers who ignore this dimension risk failure of redesigned processes for organizational and motivational factors.

Some firms have been able to achieve multiple objectives in redesigning processes with IT. American Express, for example, set out to improve the cost, time, and quality of its credit authorization process by embedding the knowledge of its best authorizers in an "Authorizer's Assistant" expert system. This successful redesign led to a $7 million annual reduction in costs due to credit losses, a 25 percent reduction in the average time for each authorization, and a 30 percent reduction in improper credit denials.

Finally, all firms found it was important to set specific objectives, even to the point of quantification. Though it is difficult to know how much improvement is possible in advance of a redesign, "reach should exceed grasp." Setting goals that will stretch the organization will also provide inspiration and stimulate creative thinking. For example, a company might decide to reduce the time to bring new products to market by 80 percent. In the accounts payable process at Ford, the "stretch" goal was to eliminate invoices–to pay suppliers upon receipt of their products or services. This goal has been achieved with help from an information system to confirm expected deliveries at the loading dock. As a result, Ford has eliminated three-quarters of the jobs in accounts payable.

Identify Processes to Be Redesigned

Most organizations could benefit from IT-enabled redesign of critical (if not all) business processes. However, the amount of effort involved creates practical limitations. Even when total redesign was the ultimate objective, the companies we studied selected a few key processes for initial efforts. Moreover, when there was insufficient commitment to total redesign, a few successful examples of IT-enhanced processes became a powerful selling tool.

The means by which processes to be redesigned are identified and prioritized is a key issue. This is often difficult because most managers do not think about their business operations in terms of processes. There are two major approaches. The exhaustive approach attempts to identify all processes within an organization and then prioritize them in order of redesign urgency. The high-impact approach attempts to identify only the most important processes or those most in conflict with the business vision and process objectives.

The exhaustive approach is often associated with "information engineering" (developed by James Martin in the early 1980s), in which an organization's use of data dictates the processes to be redesigned.16 For example, one information engineering method, employed at several divisions of Xerox, involves identifying business activities and the data they require using a data-activity matrix. The clusters of data activity interactions in the cells of the matrix are the organizations major business processes. Once processes are identified, Xerox managers prioritize them in the order in which new IT applications support should be provided. Although process identification in some Xerox divisions has taken as little as three months, many companies find this approach very time consuming.

The alternative is to focus quickly on high-impact processes. Most organizations have some sense of which business areas or processes are most crucial to their success, and those most "broken" or inconsistent with the business vision. If not, these can normally be identified using senior management workshops, or through extensive interviewing.17 At IBM, the salesforce was surveyed to determine the relative importance of various customer support processes; the generation of special bids emerged as the highest priority and was the first process to be redesigned.

Companies that employed the high-impact approach generally considered it sufficient. Companies taking the exhaustive approach, on the other hand, have not had the resources to address all the identified processes; why identify them if they cannot be addressed? As a rough rule of thumb, most companies we studied were unable to redesign and support more than ten to fifteen major processes per year (i.e., one to three per major business unit); there was simply not enough management attention to do more. And some organizations have abandoned the exhaustive approach.18

Whichever approach is used, companies have found it useful to classify each redesigned process in terms of beginning and end points, interfaces, and organization units (functions or departments) involved, particularly including the customer unit. Thinking in these terms usually broadens the perceived scope of the process. For example, a sales manager may be aware that there are inefficiencies in customer order entry. A skilled process consultant might decide that the whole process– negotiating, receiving, and fulfilling orders – needs to be redesigned. Whether the problem is broken down into three processes or viewed as one is not important; expanding the scope of the process analysis is the key issue.

High-impact processes should also have owners.19 In virtually all the process redesigns we studied, an important step was getting owners to buy in to both the idea and the scope of process redesign at an early stage. In several companies, managers felt that the process owner's job should be either above the level of the functions and units involved, or, if on the same level, that the owner should be willing–and able–to change the status quo. The difficulty, however, is that some processes only come together at the CEO level. In this situation, the CEO should designate a senior manager as owner and invest him or her with full authority Processes that are fully contained within a single function or department can normally be owned by the manager of that area.

Understand and Measure Existing Processes

There are two primary reasons for understanding and measuring processes before redesigning them. First, problems must be understood so that they are not repeated. Second, accurate measurement can serve as a baseline for future improvements. If the objective is to cut time and cost, the time and cost consumed by the untouched process must be measured accurately Westinghouse Productivity and Quality Center consultants found that simply graphing the incremental cost and time consumed by process tasks can often suggest initial areas for redesign. These graphs look like "step functions" showing the incremental contribution of each major task.

This step can easily be overemphasized, however. In several firms, the "stretch" goal was less to eliminate problems or bottlenecks than to create radical improvements. Designers should be informed by past process problems and errors, but they should work with a clean slate. Similarly, the process should not be measured for measurement's sake. Only the specific objectives of the redesign should be measured. As with the high-impact process identification approach, an 80–20 philosophy is usually appropriate.

Identify IT Levers

Until recently, even the most sophisticated industrial engineering approaches did not consider IT capabilities until after a process had been designed. The conventional wisdom in IT usage has always been to first determine the business requirements of a function, process, or other business entity, and then to develop a system. The problem is that an awareness of IT capabilities can –and should – influence process design. Knowing that product development teams can exchange computer-aided designs over large distances, for example, might affect the structure of a product development process. The role of IT in a process should be considered in the early stages of its redesign.20

Several firms accomplished this using brainstorming sessions, with the process redesign objectives and existing process measures in hand. It was also useful to have a list of IT's generic capabilities in improving business processes. In the broadest sense, all of IT's capabilities involve improving coordination and information access across organizational units, thereby allowing for more effective management of task interdependence. More specifically, however, it is useful to think about IT capabilities and their organizational impacts in eight different ways (see Table 1).

There are undoubtedly other important IT capabilities that can reshape processes. Organizations may want to develop their own lists of capabilities that are specific to the types of processes they employ. The point is twofold: IT is so powerful a tool that it deserves its own step in process redesign, and IT can actually create new process design options, rather than simply support them.

Design and Build a Prototype of the Process

For most firms, the final step is to design the process. This is usually done by the same team that performed the previous steps, getting input from constituencies and using brainstorming workshops. A key point is that the actual design is not the end of the process. Rather, it should be viewed as a prototype, with successive iterations expected and managed. Key factors and tactics to consider in process design and prototype creation include using IT as a design tool, understanding generic design criteria, and creating organizational prototypes.

IT as a Design Tool.

Designing a business process is largely a matter of diligence and creativity. Emerging IT technologies, however, are beginning to facilitate the "process" of process design. Some computer-aided systems engineering (CASE) products are designed primarily to draw process models. The ability to draw models rapidly and make changes suggested by process owners speeds redesign and facilitates owner buy-in. Some CASE products can actually generate computer code for the information systems application that will support a modeled business process.

Several Xerox divisions, for example, are moving directly from process modeling to automated generation of computer code for high-priority processes. They report improved productivity and high user satisfaction with the resulting systems. A further benefit is that when the business process changes, the IS organization can rapidly modify the affected system. Use of code generation products generally presumes that process designers will use the exhaustive approach to process identification.

Generic Design Criteria.

Companies used various criteria for evaluating alternative designs. Most important, of course, is the likelihood that a design will satisfy the chosen design objectives. Others mentioned in interviews included the simplicity of the design, the lack of buffers or intermediaries, the degree of control by a single individual or department (or an effective, decentralized coordinative mechanism), the balance of process resources, and the generalization of process tasks (so that they can be performed by more than one person).

Organizational Prototypes.

Mutual Benefit Life's (MBL) redesign of its individual life insurance underwriting process illustrates a final, important point about process design. At MBL, underwriting a life insurance policy involved 40 steps with over 100 people in 12 functional areas and 80 separate jobs. To streamline this lengthy and complex process, MBL undertook a pilot project with the goal of improving productivity by 40 percent. To integrate the process, MBL created a new role, the case manager. This role was designed to perform and coordinate all underwriting tasks centrally, utilizing a workstation-based computer system capable of pulling data from all over the company. After a brief start-up period, the firm learned that two additional roles were necessary on some underwriting cases: specialists such as lawyers or medical directors in knowledge-intensive fields, and clerical assistance. With the new role and redesigned process, senior managers at MBL are confident of reaching the 40 percent goal in a few months. This example illustrates the value of creating organizational prototypes in IT-driven process redesign.

Creating prototypes of IT applications has already gained widespread acceptance. Advocates argue that building a prototype of an IT change usually achieves results faster than conventional "life cycle" development, and, more important, that the result is much more likely to satisfy the customer. Building prototypes of business process changes and organizational redesign initiatives can yield similar benefits.21 The implications of this extension are that process designs, after agreement by owners and stakeholders, would be implemented on a pilot basis (perhaps in parallel with existing processes), examined regularly for problems and objective achievement, and modified as necessary. As the process approached final acceptance, it would be phased into full implementation.

Defining Process Types

The five steps described above are sufficiently general to apply to most organizations and processes. Yet the specifics of redesign vary considerably according to the type of process under examination. Different types require different levels of management attention and ownership, need different forms of IT support, and have different business consequences. In this section, we present three different dimensions within which processes vary.

Understanding and classifying the different types of processes is important because an organization can appear to be a seamless web of interconnected processes. With various process types in mind, a manager can begin to isolate particular processes for analysis and redesign, including activities that, without process thinking, might otherwise be overlooked.

Three major dimensions can be used to define processes (see Figure 3). These are the organizational entities or subunits involved in the process, the type of objects manipulated, and the type of activities taking place. We describe each dimension and resulting process type below.

Defining Process Entities

Processes take place between types of organizational entities. Each type has different implications for IT benefits.

Interorganizational processes are those taking place between two or more business organizations. Increasingly, companies are concerned with coordinating activities that extend into the next (or previous) company along the value-added chain.22 Several U.S. retail, apparel, and textile companies, for example, have linked their business processes to speed up reordering of apparel. When Dillard's (department store) inventory of a particular pants style falls below a specified level, Haggar (apparel manufacturer) is notified electronically. If Haggar does not have the cloth to manufacture the pants, Burlington Industries (textile manufacturer) is notified electronically. As this example of electronic data interchange (EDI) illustrates, information technology is the major vehicle by which this interorganizational linkage is executed.

For most companies, simple market relationships are the most common source of interorganizational processes. All the tasks involved in a selling-buying transaction form a critical process for sellers, and an increasingly important one for buyers seeking higher quality, cost efficiency, and responsiveness. Yet much of the focus has been on a simple transaction level, rather than on an interorganizational business process level. Again, how EDI is used illustrates this point.

Buyers and sellers have used EDI largely to speed up routine purchasing transactions, such as invoices or bills of materials. Few companies have attempted to redesign the broader procurement process–from the awareness that a product is needed, to the development of approved vendor lists, or even to the delivery and use of the purchased product. In the future, sellers will need to look at all buyer processes in which their products are involved.

Moreover, many firms will need to help the buyer improve those processes. Du Pont's concept of 'effectiveness in use" as the major criterion of customer satisfaction is one leading approach to measuring the effectiveness of interorganizational processes. Du Pont is motivated not simply to sell a product, but to link its internal processes for creating value in a product, to its customer's processes for using the product. This concept led Du Pont to furnish EDI-provided Material Safety Data Sheets along with the chemicals it sells to its customers to ensure their safe use.

Westinghouse used an interorganizational process approach in dealing with Portland General Electric (PGE), a major customer of power generation equipment. PGE managers called upon Westinghouse's Productivity and Quality Center, a national leader in process improvement, to help them implement EDI, but the Westinghouse team asked if it could analyze the entire process by which PGE procured equipment from Westinghouse and other suppliers. They found that, while implementing EDI could yield efficiencies on the order of 10 percent, changing the overall procurement process, including using EDI and bypassing the purchasing department altogether for most routine purchase orders, could lead to much greater savings. In one case, the time to execute a standard purchase order, for example, could be reduced from fifteen days to half a day; the cost could be reduced from almost $90 to $10.

A second major type of business process is interfunctional. These processes exist within the organization, but cross several functional or divisional boundaries. Interfunctional processes achieve major operational objectives, such as new product realization, asset management, or production scheduling. Most management processes–for example, planning, budgeting, and human resource management–are interfunctional.

Many manufacturing companies that focused on quality improvement found that producing quality products and services required addressing difficult interfunctional issues. Yet most firms have never even listed their key interfunctional processes, let alone analyzed or redesigned them, with or without the aid of IT.

Two companies that recently analyzed their key interfunctional business processes are Baxter Healthcare Corporation and US Sprint Communications Company Baxter's 1985 merger with American Hospital Supply provided the context for a major analysis of key business strategies, and the alignment of the IT infrastructure with those strategies.23 As part of a seven-month IT planning effort, the company defined twenty-nine major interfunctional processes and analyzed the current and future role of IT in supporting them. For example, in the distribution area, the company identified order entry, inventory, warehouse management, purchasing, transportation, and equipment tracking as key processes. The success of this IT planning effort led Baxter to incorporate the process definition approach into its annual corporate planning process.

At US Sprint, well-publicized problems with the customer billing system prompted the company's IT function to develop a model of information flows for the entire business as part of a comprehensive systems improvement program. This model defined the critical information and key interfunctional processes necessary to run the business. Sprint is now assigning ownership to key processes and continuing to identify improvements–and ways to measure them –in each process. The systems improvement program raised the IT organization's composite internal quality index by more than 50 percent in one year.24

A major problem in redesigning interfunctional processes is that most information systems of the past were built to automate specific functional areas or parts of functions. Few third-party application software packages have been developed to support a full business process. Very few organizations have modeled existing interfunctional processes or redesigned them, and companies will run into substantial problems in building interfunctional systems without such models.

Interpersonal processes involve tasks within and across small work groups, typically within a function or department. Examples include a commercial loan group approving a loan, or an airline flight crew preparing for takeoff. This type of process is becoming more important as companies shift to self-managing teams as the lowest unit of organization. Information technology is increasingly capable of supporting interpersonal processes; hardware and communications companies have developed new networking-oriented products, and software companies have begun to flesh out the concept of "groupware" (e.g., local area network-based mail, conferencing, and brainstorming tools).25

Several companies, including GM's Electronic Data Systems (EDS), are exploring tools to facilitate the effectiveness of meetings and small group interactions. At EDS, the primary focus is on enhancing the interpersonal processes involved in automobile product development. The company's Center for Machine Intelligence has developed a computer-supported meeting room, and is studying its implications for group decision making and cooperative work.26

We should point out that IT can make it possible for employees scattered around the world to work as a team. As an example, Ford now creates new car designs using teams that have members in Europe, Central America, and the United States. Because Ford has standardized computer-aided design systems and created common data structures for the design process, engineers can share complex three-dimensional designs across the Atlantic. Similarly, a small team at Digital Equipment used the company's electronic mail and conferencing capabilities to build the core of a new systems integration business. The team was scattered around the United States and Europe and only rarely met in person.

Defining Process Objects

Processes can also be categorized by the types of objects manipulated. The two primary object types are physical and informational. In physical object processes, real, tangible things are either created or manipulated; manufacturing is the obvious example. Informational object processes create or manipulate information. Processes for making a decision, preparing a marketing plan, or designing a new product are examples.

Many processes involve the combination of physical and informational objects. Indeed, adding information to a physical object as it moves through a process is a common way of adding value. Most logistical activities, for example, combine the movement of physical objects with the manipulation of information concerning their whereabouts. Success in the logistics industry is often dependent on the close integration of physical and informational outcomes; both UPS and Federal Express, for example, track package movement closely.

The potential for using IT to improve physical processes is well known. It allows greater flexibility and variety of outcomes, more precise control of the process itself, reductions in throughput time, and elimination of human labor. These benefits have been pursued for the past three decades. Still, manufacturing process flows are often the result of historical circumstance and should usually be redesigned before further automation is applied. This is particularly true in low volume, job shop manufacturing environments.27 Redesigners of physical processes should also consider the role of IT in providing information to improve processes; Shoshana Zuboff has described this "informating" effect in detail for the paper industry.28

Strangely, the proportion of informational processes already transformed by IT is probably lower than that of physical processes. True, legions of clerks have become unemployed because of computers. But the majority of information processes to which IT has been applied are those involving high volume and low complexity. Now that these processes are well known even if not fully conquered, the emphasis needs to shift to processes that incorporate semistructured and unstructured tasks and are performed by high-skill knowledge workers. Relevant IT capabilities include the storage and retrieval of unstructured and multimedia information, the capturing and routinizing of decision logic, and the application of far-flung and complex data resources. A computer vendor's advertising videotape, for example, illustrates how artificial intelligence and "hypertext," or mixed-media databases, combine to lead a manager through the process of developing a departmental budget. The IT capabilities in the video are available today, but they are rarely applied to such information-intensive yet unstructured processes.

Defining Process Activities

Our examples of business processes have involved two types of activities: operational and managerial. Operational processes involve the day-to-day carrying out of the organization's basic business purpose. Managerial processes help to control, plan, or provide resources for operational processes. Past uses of IT to improve processes, limited as they are, have been largely operational. We will therefore focus almost entirely on managerial processes in this section.29

Applying IT to management tasks is not a new idea. The potential of decision support systems, executive support systems, and other managerial tools has been discussed for over twenty years. We believe, however, that the benefits have not been realized because of the absence of systematic process thinking. Few companies have rigorously analyzed managerial activities as processes subject to redesign. Even the notion of managerial activities involving defined outcomes (a central aspect of our definition of business processes) is somewhat foreign. How would such managerial processes as deciding on an acquisition or developing the agenda for the quarterly board meeting be improved if they were treated as processes–in other words, measured, brainstormed, and redesigned with IT capabilities?

The generic capabilities of IT for reshaping management processes include improving analytic accuracy, enabling broader management participation across wider geographical boundaries, generating feedback on actions taken (the managerial version of "informating" a process), and streamlining the time and resources a specific process consumes. Texas Instruments and Xerox's corporate headquarters provide excellent examples. See IT-Driven Process Redesign at Rank Xerox U.K.

Texas Instruments has developed an expert system to facilitate the capital budgeting process. Managers in a fast-growing and capital-intensive TI division were concerned that the time and experience necessary to prepare capital budget request packages would become an obstacle to the divisions growth. The packages were very complex and time consuming, and few employees had the requisite knowledge to complete them accurately. The expert system was developed by two industrial engineers with expertise in both the technology and the budget process.

TI's system has radically improved the capital budget request process. Requests prepared with the system require far less time than the manual approach and conform better to the company's guidelines. One experienced employee reported a reduction in package preparation time from nine hours to forty minutes; of the first fifty packages prepared with the system, only three did not conform to guidelines, compared to an average of ten using a manual approach.30

At Xerox Corporation headquarters, IT has been used to improve the review of division strategic plans. Prior to the development of the company's Executive Information System (EIS), the planning process was somewhat haphazard; each division prepared its planning documents in a different format and furnished different types of information to corporate headquarters. Plans often came in too late for the corporate management committee to review them before the quarterly or annual review meeting. The EIS was developed to include standard information formats and a user friendly graphical interface enabling fast comprehension. Divisional plans are now developed on the EIS and delivered instantaneously over Xerox's network to all corporate management committee members. These members can now read and discuss the plans beforehand and can move directly to decisions at the review meetings. The workstations are even used in the meetings themselves, allowing revisions to be made and agreed upon before adjournment. As one manager put it, ". . . [the system] lets us communicate at higher speed and in greater depth."31

Management Issues in IT-Enabled Redesign

Companies have found that once a process has been redesigned, several key issues remain. These include the management role in redesigned activity, implications for organization structure, new skill requirements, creating a function to perform IT-enabled BPR, the proper direction for the IT infrastructure, and the need for continuous process improvement. We discuss each below.

Management Roles

Perhaps the greatest difficulty in IT-driven redesign is getting and keeping management commitment. Because processes cut across various parts of the organization, a process redesign effort driven by a single business function or unit will probably encounter resistance from other parts of the organization. Both high-level and broad support for change are necessary.

To perform the five redesign steps described above, several companies created a cross-functional task force headed by a senior executive. These task forces included representatives from key staff and line groups likely to be affected by the changes, including IT and human resources. It was particularly important that the customer of the process be represented on the team, even when the customer was external. The team composition was ideal if some members had some record of process or operations innovation involving IT.

As the redesign teams selected processes and developed objectives, they needed to work closely with the managers and staff of the affected units. Managing process change is similar to managing other types of change, except that its cross-functional nature increases the number of stakeholders, thereby increasing the complexity of the effort.

It was also important to have strong, visible commitment from senior management. Employees throughout the organization needed to understand that redesign was critical, that differences of opinion would be resolved in favor of the customer of a process, and that IT would play an important role. In many cases, the CEO communicated any structural implications of the redesign effort.

An example of the importance of the CEO's role is found at GUS Home Shopping, the largest home shopping company in Europe. GUS undertook a $90 million project to redesign its logistical processes with IT. Redesign objectives involved both cost and time: to be able to sell a product within five minutes of its arrival on the loading dock, and to be able to deliver a product to the customer's door at an average cost of sixty cents. The company's managing director commented on his role in meeting these objectives:

To change our business to the degree we have [done] demands integration. How involved should the managing director get in designing computer systems? My view is totally, because he's the one who can integrate across the entire organization.32

Process Redesign and Organizational Structure

A second key issue is the relationship between process orientation and organizational structure. Certainly someone must be in charge of implementing a process change, and of managing the redesigned process thereafter. But process responsibilities are likely to cut across existing organizational structures. How can process organization and traditional functional organization be reconciled?

One possible solution is to create a new organization structure along process lines, in effect abandoning altogether other structural dimensions, such as function, product, or geography. This approach presents risks, however; as business needs change, new processes will be created that cut across the previous process-based organization. This does not mean that a process-based structure cannot be useful, but only that it will have to be changed frequently.

While no firm we studied has converted wholly to a process-based structure, a few organizations have moved in this direction. For example, Apple Computer recently moved away from a functional structure to what executives describe as an IT oriented, process-based, customer satisfaction-driven structure called "New Enterprise." The company relishes its lack of formal hierarchy; Apple managers describe their roles as highly diffuse, and team and project based.

A more conservative approach would be to create a matrix of functional and process responsibilities. However, because of the cross-functional nature of most processes, the functional manager who should have responsibility for a given process is not always easy to identify. The company may also wish to avoid traditional functional thinking in assigning process responsibilities. For example, it may be wiser to give responsibility for redesigning supplies acquisition to a manager who uses those supplies (i.e., the customer of the process), rather than to the head of purchasing.

New Skill Requirements

For process management to succeed, managers must develop facilitation and influence skills. Traditional sources of authority may be of little use when process changes cut across organizational units. Managers will find themselves trying to change the behavior of employees who do not work for them. In these cases, they must learn to persuade rather than to instruct, to convince rather than to dictate. Of course, these recommendations are consistent with many other organizational maxims of the past several years; they just happen to be useful in process management as well.33

Several organizations that are moving toward IT-driven process management are conducting programs intended to develop facilitation skills. These programs encourage less reliance on hierarchy, more cross-functional communication and cooperation, and more decision making by middle- and lower-level managers. Such a program at American Airlines is being used to build an organizational infrastructure at the same time a new IT infrastructure is being built.

An Ongoing Organization

Organizations that redesign key processes must oversee continuing redesign and organizational "tuning," as well as ensure that information systems support process flows. In most companies, the appropriate analytical skills are most likely to be found in the IT function. However, these individuals will also require a high degree of interpersonal skills to be successful as the "new industrial engineers." The ideal group would represent multiple functional areas, for example, information systems, industrial engineering, quality, process control, finance, and human resources.

There are already some examples of such process change groups. Silicon Graphics has created a specific process consulting group for ongoing process management; it is headed by a director-level manager. At United Parcel Service, process redesign is traditionally concentrated in the industrial engineering function. The UPS group is incorporating IT skills in the IE function at a rapid rate, and creating task forces with IT and IE representation for process redesign projects. Federal Express has gone even further, renaming its IE organization the "Strategic Integrated Systems Group," placing it within the Information Systems function, and giving it responsibility for designing and implementing major IT-driven business changes.

Process Redesign and the IT Organization

Just as information technology is a powerful force in redesigning business processes, process thinking has important implications for the IT organization and for the technology infrastructure it builds. Though few IT groups have the power and influence to spearhead process redesign, they can play several important roles. First of all, the IT group may need to play a behind-the-scenes advocacy role, convincing senior management of the power offered by information technology and process redesign. Second, as demand builds for process redesign expertise, the IT group can begin to incorporate the IE-oriented skills of process measurement, analysis, and redesign, perhaps merging with the IE function if there is one. It can also develop an approach or methodology for IT-enabled redesign, perhaps using the five steps described above as a starting point.

What must the information systems function do technologically to prepare for process redesign? IT professionals must recognize that they will have to build most systems needed to support (or enable) processes, rather than buy them from software package vendors, because most application packages are designed with particular functions in mind. IT professionals will need to build robust technology platforms on which process-specific applications can be quickly constructed. This implies a standardized architecture with extensive communications capability between computing nodes, and the development of shared databases. However, like the organizational strategies for process management described above, these are appropriate technology strategies for most companies, whether or not they are redesigning processes with IT.

Continuous Process Improvement

The concept of process improvement, which developed in the quality movement, requires first that the existing process be stabilized. It then becomes predictable, and its capabilities become accessible to analysis and improvement.34 Continuous process improvement occurs when the cycle of stabilizing, assessing, and improving a given process becomes institutionalized.

IT-enabled business process redesign must generally be dynamic. Those responsible for a process should constantly investigate whether new information technologies make it possible to carry out a process in new ways. IT is continuing to evolve, and forthcoming technologies will have a substantial impact on the processes of the next decade. The IT infrastructure must be robust enough to support the new applications appropriate to a particular process.

Summary

We believe that the industrial engineers of the future, regardless of their formal title or the organizational unit that employs them, will focus increasingly on IT-enabled redesign of business processes. We have only begun to explore the implications and implementation of this concept, and only a few companies have ventured into the area. Many companies that have used IT to redesign particular business processes have done so without any conscious approach or philosophy. In short, the actual experience base with IT-enabled process redesign is limited.

Yet managing by customer-driven processes that cross organizational boundaries is an intuitively appealing idea that has worked well in the companies that have experimented with it. And few would question that information technology is a powerful tool for reshaping business processes. The individuals and companies that can master redesigning processes around IT will be well equipped to succeed in the new decade–and the new century.