Despite a decade or more of restructuring and downsizing, many U.S. companies are still unprepared to operate in the 1990s. In a time of rapidly changing technologies and ever-shorter product life cycles, product development often proceeds at a glacial pace. In an age of the customer, order fulfillment has high error rates and customer inquiries go unanswered for weeks. In a period when asset utilization is critical, inventory levels exceed many months of demand.
The usual methods for boosting performance—process rationalization and automation—haven’t yielded the dramatic improvements companies need. In particular, heavy investments in information technology have delivered disappointing results—largely because companies tend to use technology to mechanize old ways of doing business. They leave the existing processes intact and use computers simply to speed them up.
But speeding up those processes cannot address their fundamental performance deficiencies. Many of our job designs, work flows, control mechanisms, and organizational structures came of age in a different competitive environment and before the advent of the computer. They are geared toward efficiency and control. Yet the watchwords of the new decade are innovation and speed, service and quality.
It is time to stop paving the cow paths. Instead of embedding outdated processes in silicon and software, we should obliterate them and start over. We should “reengineer” our businesses: use the power of modern information technology to radically redesign our business processes in order to achieve dramatic improvements in their performance.
Every company operates according to a great many unarticulated rules. “Credit decisions are made by the credit department.” “Local inventory is needed for good customer service.” “Forms must be filled in completely and in order.” Reengineering strives to break away from the old rules about how we organize and conduct business. It involves recognizing and rejecting some of them and then finding imaginative new ways to accomplish work. From our redesigned processes, new rules will emerge that fit the times. Only then can we hope to achieve quantum leaps in performance.
Reengineering cannot be planned meticulously and accomplished in small and cautious steps. It’s an all-or-nothing proposition with an uncertain result. Still, most companies have no choice but to muster the courage to do it. For many, reengineering is the only hope for breaking away from the antiquated processes that threaten to drag them down. Fortunately, managers are not without help. Enough businesses have successfully reengineered their processes to provide some rules of thumb for others.
What Ford and MBL Did
Japanese competitors and young entrepreneurial ventures prove every day that drastically better levels of process performance are possible. They develop products twice as fast, utilize assets eight times more productively, respond to customers ten times faster. Some large, established companies also show what can be done. Businesses like Ford Motor Company and Mutual Benefit Life Insurance have reengineered their processes and achieved competitive leadership as a result. Ford has reengineered its accounts payable processes, and Mutual Benefit Life, its processing of applications for insurance.
In the early 1980s, when the American automotive industry was in a depression, Ford’s top management put accounts payable—along with many other departments—under the microscope in search of ways to cut costs. Accounts payable in North America alone employed more than 500 people. Management thought that by rationalizing processes and installing new computer systems, it could reduce the head count by some 20%.
Ford was enthusiastic about its plan to tighten accounts payable—until it looked at Mazda. While Ford was aspiring to a 400-person department, Mazda’s accounts payable organization consisted of a total of 5 people. The difference in absolute numbers was astounding, and even after adjusting for Mazda’s smaller size, Ford figured that its accounts payable organization was five times the size it should be. The Ford team knew better than to attribute the discrepancy to calisthenics, company songs, or low interest rates.
Ford managers ratcheted up their goal: accounts payable would perform with not just a hundred but many hundreds fewer clerks. It then set out to achieve it. First, managers analyzed the existing system. When Ford’s purchasing department wrote a purchase order, it sent a copy to accounts payable. Later, when material control received the goods, it sent a copy of the receiving document to accounts payable. Meanwhile, the vendor sent an invoice to accounts payable. It was up to accounts payable, then, to match the purchase order against the receiving document and the invoice. If they matched, the department issued payment.
The department spent most of its time on mismatches, instances where the purchase order, receiving document, and invoice disagreed. In these cases, an accounts payable clerk would investigate the discrepancy, hold up payment, generate documents, and all in all gum up the works.
One way to improve things might have been to help the accounts payable clerk investigate more efficiently, but a better choice was to prevent the mismatches in the first place. To this end, Ford instituted “invoiceless processing.” Now when the purchasing department initiates an order, it enters the information into an on-line database. It doesn’t send a copy of the purchase order to anyone. When the goods arrive at the receiving dock, the receiving clerk checks the database to see if they correspond to an outstanding purchase order. If so, he or she accepts them and enters the transaction into the computer system. (If receiving can’t find a database entry for the received goods, it simply returns the order.).
Under the old procedures, the accounting department had to match 14 data items between the receipt record, the purchase order, and the invoice before it could issue payment to the vendor. The new approach requires matching only three items—part number, unit of measure, and supplier code—between the purchase order and the receipt record. The matching is done automatically, and the computer prepares the check, which accounts payable sends to the vendor. There are no invoices to worry about since Ford has asked its vendors not to send them. (See the diagram, “Ford’s Accounts Payable Process…,” for illustrations of the old and new payables processes.)
Ford didn’t settle for the modest increases it first envisioned. It opted for radical change—and achieved dramatic improvement. Where it has instituted this new process, Ford has achieved a 75% reduction in head count, not the 20% it would have gotten with a conventional program. And since there are no discrepancies between the financial record and the physical record, material control is simpler and financial information is more accurate.
Mutual Benefit Life, the country’s eighteenth largest life carrier, has reengineered its processing of insurance applications. Prior to this, MBL handled customers’ applications much as its competitors did. The long, multistep process involved credit checking, quoting, rating, underwriting, and so on. An application would have to go through as many as 30 discrete steps, spanning 5 departments and involving 19 people. At the very best, MBL could process an application in 24 hours, but more typical turnarounds ranged from 5 to 25 days—most of the time spent passing information from one department to the next. (Another insurer estimated that while an application spent 22 days in process, it was actually worked on for just 17 minutes.).
MBL’s rigid, sequential process led to many complications. For instance, when a customer wanted to cash in an existing policy and purchase a new one, the old business department first had to authorize the treasury department to issue a check made payable to MBL. The check would then accompany the paperwork to the new business department.
The president of MBL, intent on improving customer service, decided that this nonsense had to stop and demanded a 60% improvement in productivity. It was clear that such an ambitious goal would require more than tinkering with the existing process. Strong measures were in order, and the management team assigned to the task looked to technology as a means of achieving them. The team realized that shared databases and computer networks could make many different kinds of information available to a single person, while expert systems could help people with limited experience make sound decisions. Applying these insights led to a new approach to the application-handling process, one with wide organizational implications and little resemblance to the old way of doing business.
MBL swept away existing job definitions and departmental boundaries and created a new position called a case manager. Case managers have total responsibility for an application from the time it is received to the time a policy is issued. Unlike clerks, who performed a fixed task repeatedly under the watchful gaze of a supervisor, case managers work autonomously. No more handoffs of files and responsibility, no more shuffling of customer inquiries.
Case managers are able to perform all the tasks associated with an insurance application because they are supported by powerful PC-based workstations that run an expert system and connect to a range of automated systems on a mainframe. In particularly tough cases, the case manager calls for assistance from a senior underwriter or physician, but these specialists work only as consultants and advisers to the case manager, who never relinquishes control.
Empowering individuals to process entire applications has had a tremendous impact on operations. MBL can now complete an application in as little as four hours, and average turnaround takes only two to five days. The company has eliminated 100 field office positions, and case managers can handle more than twice the volume of new applications the company previously could process.
The Essence of Reengineering
At the heart of reengineering is the notion of discontinuous thinking—of recognizing and breaking away from the outdated rules and fundamental assumptions that underlie operations. Unless we change these rules, we are merely rearranging the deck chairs on the Titanic. We cannot achieve breakthroughs in performance by cutting fat or automating existing processes. Rather, we must challenge old assumptions and shed the old rules that made the business underperform in the first place.
Every business is replete with implicit rules left over from earlier decades. “Customers don’t repair their own equipment.” “Local warehouses are necessary for good service.” “Merchandising decisions are made at headquarters.” These rules of work design are based on assumptions about technology, people, and organizational goals that no longer hold. The contemporary repertoire of available information technologies is vast and quickly expanding. Quality, innovation, and service are now more important than cost, growth, and control. A large portion of the population is educated and capable of assuming responsibility, and workers cherish their autonomy and expect to have a say in how the business is run.
It should come as no surprise that our business processes and structures are outmoded and obsolete: our work structures and processes have not kept pace with the changes in technology, demographics, and business objectives. For the most part, we have organized work as a sequence of separate tasks and employed complex mechanisms to track its progress. This arrangement can be traced to the Industrial Revolution, when specialization of labor and economies of scale promised to overcome the inefficiencies of cottage industries. Businesses disaggregated work into narrowly defined tasks, reaggregated the people performing those tasks into departments, and installed managers to administer them.
Our elaborate systems for imposing control and discipline on those who actually do the work stem from the postwar period. In that halcyon period of expansion, the main concern was growing fast without going broke, so businesses focused on cost, growth, and control. And since literate, entry-level people were abundant but well-educated professionals hard to come by, the control systems funneled information up the hierarchy to the few who presumably knew what to do with it.
These patterns of organizing work have become so ingrained that, despite their serious drawbacks, it’s hard to conceive of work being accomplished any other way. Conventional process structures are fragmented and piecemeal, and they lack the integration necessary to maintain quality and service. They are breeding grounds for tunnel vision, as people tend to substitute the narrow goals of their particular department for the larger goals of the process as a whole. When work is handed off from person to person and unit to unit, delays and errors are inevitable. Accountability blurs, and critical issues fall between the cracks. Moreover, no one sees enough of the big picture to be able to respond quickly to new situations. Managers desperately try, like all the king’s horses and all the king’s men, to piece together the fragmented pieces of business processes.
Managers have tried to adapt their processes to new circumstances, but usually in ways that just create more problems. If, say, customer service is poor, they create a mechanism to deliver service but overlay it on the existing organization. Bureaucracy thickens, costs rise, and enterprising competitors gain market share.
In reengineering, managers break loose from outmoded business processes and the design principles underlying them and create new ones. Ford had operated under the old rule that “We pay when we receive the invoice.” While no one had ever articulated or recorded it, that rule determined how the accounts payable process was organized. Ford’s reengineering effort challenged and ultimately replaced the rule with a new one: “We pay when we receive the goods.”
Reengineering requires looking at the fundamental processes of the business from a cross-functional perspective. Ford discovered that reengineering only the accounts payable department was futile. The appropriate focus of the effort was what might be called the goods acquisition process, which included purchasing and receiving as well as accounts payable.
One way to ensure that reengineering has a cross-functional perspective is to assemble a team that represents the functional units involved in the process being reengineered and all the units that depend on it. The team must analyze and scrutinize the existing process until it really understands what the process is trying to accomplish. The point is not to learn what happens to form 73B in its peregrinations through the company but to understand the purpose of having form 73B in the first place. Rather than looking for opportunities to improve the current process, the team should determine which of its steps really add value and search for new ways to achieve the result.
The reengineering team must keep asking Why? and What if? Why do we need to get a manager’s signature on a requisition? Is it a control mechanism or a decision point? What if the manager reviews only requisitions above $500? What if he or she doesn’t see them at all? Raising and resolving heretical questions can separate what is fundamental to the process from what is superficial. The regional offices of an East Coast insurance company had long produced a series of reports that they regularly sent to the home office. No one in the field realized that these reports were simply filed and never used. The process outlasted the circumstances that had created the need for it. The reengineering study team should push to discover situations like this.
In short, a reengineering effort strives for dramatic levels of improvement. It must break away from conventional wisdom and the constraints of organizational boundaries and should be broad and cross-functional in scope. It should use information technology not to automate an existing process but to enable a new one.
Principles of Reengineering
Creating new rules tailored to the modern environment ultimately requires a new conceptualization of the business process—which comes down to someone having a great idea. But reengineering need not be haphazard. In fact, some of the principles that companies have already discovered while reengineering their business processes can help jump start the effort for others.
Organize around outcomes, not tasks. This principle says to have one person perform all the steps in a process. Design that person’s job around an objective or outcome instead of a single task. The redesign at Mutual Benefit Life, where individual case managers perform the entire application approval process, is the quintessential example of this.
The redesign of an electronics company is another example. It had separate organizations performing each of the five steps between selling and installing the equipment. One group determined customer requirements, another translated those requirements into internal product codes, a third conveyed that information to various plants and warehouses, a fourth received and assembled the components, and a fifth delivered and installed the equipment. The process was based on the centuries-old notion of specialized labor and on the limitations inherent in paper files. The departments each possessed a specific set of skills, and only one department at a time could do its work.
The customer order moved systematically from step to step. But this sequential processing caused problems. The people getting the information from the customer in step one had to get all the data anyone would need throughout the process, even if it wasn’t needed until step five. In addition, the many handoffs were responsible for numerous errors and misunderstandings. Finally, any questions about customer requirements that arose late in the process had to be referred back to the people doing step one, resulting in delay and rework.
When the company reengineered, it eliminated the assembly-line approach. It compressed responsibility for the various steps and assigned it to one person, the “customer service representative.” That person now oversees the whole process—taking the order, translating it into product codes, getting the components assembled, and seeing the product delivered and installed. The customer service rep expedites and coordinates the process, much like a general contractor. And the customer has just one contact, who always knows the status of the order.
Why Did We Design Inefficient Processes?
Have those who use the output of the process perform the process. In an effort to capitalize on the benefits of specialization and scale, many organizations established specialized departments to handle specialized processes. Each department does only one type of work and is a “customer” of other groups’ processes. Accounting does only accounting. If it needs new pencils, it goes to the purchasing department, the group specially equipped with the information and expertise to perform that role. Purchasing finds vendors, negotiates price, places the order, inspects the goods, and pays the invoice—and eventually the accountants get their pencils. The process works (after a fashion), but it’s slow and bureaucratic.
Now that computer-based data and expertise are more readily available, departments, units, and individuals can do more for themselves. Opportunities exist to reengineer processes so that the individuals who need the result of a process can do it themselves. For example, by using expert systems and databases, departments can make their own purchases without sacrificing the benefits of specialized purchasers. One manufacturer has reengineered its purchasing process along just these lines. The company’s old system, whereby the operating departments submitted requisitions and let purchasing do the rest, worked well for controlling expensive and important items like raw materials and capital equipment. But for inexpensive and nonstrategic purchases, which constituted some 35% of total orders, the system was slow and cumbersome; it was not uncommon for the cost of the purchasing process to exceed the cost of the goods being purchased.
The new process compresses the purchase of sundry items and pushes it on to the customers of the process. Using a database of approved vendors, an operating unit can directly place an order with a vendor and charge it on a bank credit card. At the end of the month, the bank gives the manufacturer a tape of all credit card transactions, which the company runs against its internal accounting system.
When an electronics equipment manufacturer reengineered its field service process, it pushed some of the steps of the process on to its customers. The manufacturer’s field service had been plagued by the usual problems: technicians were often unable to do a particular repair because the right part wasn’t on the van, response to customer calls was slow, and spare-parts inventory was excessive.
Now customers make simple repairs themselves. Spare parts are stored at each customer’s site and managed through a computerized inventory-management system. When a problem arises, the customer calls the manufacturer’s field-service hot line and describes the symptoms to a diagnostician, who accesses a diagnosis support system. If the problem appears to be something the customer can fix, the diagnostician tells the customer what part to replace and how to install it. The old part is picked up and a new part left in its place at a later time. Only for complex problems is a service technician dispatched to the site, this time without having to make a stop at the warehouse to pick up parts.
When the people closest to the process perform it, there is little need for the overhead associated with managing it. Interfaces and liaisons can be eliminated, as can the mechanisms used to coordinate those who perform the process with those who use it. Moreover, the problem of capacity planning for the process performers is greatly reduced.
Subsume information-processing work into the real work that produces the information. The previous two principles say to compress linear processes. This principle suggests moving work from one person or department to another. Why doesn’t an organization that produces information also process it? In the past, people didn’t have the time or weren’t trusted to do both. Most companies established units to do nothing but collect and process information that other departments created. This arrangement reflects the old rule about specialized labor and the belief that people at lower organizational levels are incapable of acting on information they generate. An accounts payable department collects information from purchasing and receiving and reconciles it with data that the vendor provides. Quality assurance gathers and analyzes information it gets from production.
Ford’s redesigned accounts payable process embodies the new rule. With the new system, receiving, which produces the information about the goods received, processes this information instead of sending it to accounts payable. The new computer system can easily compare the delivery with the order and trigger the appropriate action.
Treat geographically dispersed resources as though they were centralized. The conflict between centralization and decentralization is a classic one. Decentralizing a resource (whether people, equipment, or inventory) gives better service to those who use it, but at the cost of redundancy, bureaucracy, and missed economies of scale. Companies no longer have to make such trade-offs. They can use databases, telecommunications networks, and standardized processing systems to get the benefits of scale and coordination while maintaining the benefits of flexibility and service.
At Hewlett-Packard, for instance, each of the more than 50 manufacturing units had its own separate purchasing department. While this arrangement provided excellent responsiveness and service to the plants, it prevented H-P from realizing the benefits of its scale, particularly with regard to quantity discounts. H-P’s solution is to maintain the divisional purchasing organizations and to introduce a corporate unit to coordinate them. Each purchasing unit has access to a shared database on vendors and their performance and issues its own purchase orders. Corporate purchasing maintains this database and uses it to negotiate contracts for the corporation and to monitor the units. The payoffs have come in a 150% improvement in on-time deliveries, 50% reduction in lead times, 75% reduction in failure rates, and a significantly lower cost of goods purchased.
Link parallel activities instead of integrating their results. H-P’s decentralized purchasing operations represent one kind of parallel processing in which separate units perform the same function. Another common kind of parallel processing is when separate units perform different activities that must eventually come together. Product development typically operates this way. In the development of a photocopier, for example, independent units develop the various subsystems of the copier. One group works on the optics, another on the mechanical paperhandling device, another on the power supply, and so on. Having people do development work simultaneously saves time, but at the dreaded integration and testing phase, the pieces often fail to work together. Then the costly redesign begins.
Or consider a bank that sells different kinds of credit—loans, letters of credit, asset-based financing—through separate units. These groups may have no way of knowing whether another group has already extended credit to a particular customer. Each unit could extend the full $10 million credit limit.
The new principle says to forge links between parallel functions and to coordinate them while their activities are in process rather than after they are completed. Communications networks, shared databases, and teleconferencing can bring the independent groups together so that coordination is ongoing. One large electronics company has cut its product development cycle by more than 50% by implementing this principle.
Put the decision point where the work is performed, and build control into the process. In most organizations, those who do the work are distinguished from those who monitor the work and make decisions about it. The tacit assumption is that the people actually doing the work have neither the time nor the inclination to monitor and control it and that they lack the knowledge and scope to make decisions about it. The entire hierarchical management structure is built on this assumption. Accountants, auditors, and supervisors check, record, and monitor work. Managers handle any exceptions.
The new principle suggests that the people who do the work should make the decisions and that the process itself can have built-in controls. Pyramidal management layers can therefore be compressed and the organization flattened.
Information technology can capture and process data, and expert systems can to some extent supply knowledge, enabling people to make their own decisions. As the doers become self-managing and self-controlling, hierarchy—and the slowness and bureaucracy associated with it—disappears.
When Mutual Benefit Life reengineered the insurance application process, it not only compressed the linear sequence but also eliminated the need for layers of managers. These two kinds of compression—vertical and horizontal—often go together; the very fact that a worker sees only one piece of the process calls for a manager with a broader vision. The case managers at MBL provide end-to-end management of the process, reducing the need for traditional managers. The managerial role is changing from one of controller and supervisor to one of supporter and facilitator.
Capture information once and at the source. This last rule is simple. When information was difficult to transmit, it made sense to collect information repeatedly. Each person, department, or unit had its own requirements and forms. Companies simply had to live with the associated delays, entry errors, and costly overhead. But why do we have to live with those problems now? Today when we collect a piece of information, we can store it in an on-line database for all who need it. Bar coding, relational databases, and electronic data interchange (EDI) make it easy to collect, store, and transmit information. One insurance company found that its application review process required that certain items be entered into “stovepipe” computer systems supporting different functions as many as five times. By integrating and connecting these systems, the company was able to eliminate this redundant data entry along with the attendant checking functions and inevitable errors.
Think Big
Reengineering triggers changes of many kinds, not just of the business process itself. Job designs, organizational structures, management systems—anything associated with the process—must be refashioned in an integrated way. In other words, reengineering is a tremendous effort that mandates change in many areas of the organization.
When Ford reengineered its payables, receiving clerks on the dock had to learn to use computer terminals to check shipments, and they had to make decisions about whether to accept the goods. Purchasing agents also had to assume new responsibilities—like making sure the purchase orders they entered into the database had the correct information about where to send the check. Attitudes toward vendors also had to change: vendors could no longer be seen as adversaries; they had to become partners in a shared business process. Vendors too had to adjust. In many cases, invoices formed the basis of their accounting systems. At least one Ford supplier adapted by continuing to print invoices, but instead of sending them to Ford threw them away, reconciling cash received against invoices never sent.
The changes at Mutual Benefit Life were also widespread. The company’s job-rating scheme could not accommodate the case manager position, which had a lot of responsibility but no direct reports. MBL had to devise new job-rating schemes and compensation policies. It also had to develop a culture in which people doing work are perceived as more important than those supervising work. Career paths, recruitment and training programs, promotion policies—these and many other management systems are being revised to support the new process design.
The extent of these changes suggests one factor that is necessary for reengineering to succeed: executive leadership with real vision. No one in an organization wants reengineering. It is confusing and disruptive and affects everything people have grown accustomed to. Only if top-level managers back the effort and outlast the company cynics will people take reengineering seriously. As one wag at an electronics equipment manufacturer has commented, “Every few months, our senior managers find a new religion. One time it was quality, another it was customer service, another it was flattening the organization. We just hold our breath until they get over it and things get back to normal.” Commitment, consistency—maybe even a touch of fanaticism—are needed to enlist those who would prefer the status quo.
Considering the inertia of old processes and structures, the strain of implementing a reengineering plan can hardly be overestimated. But by the same token, it is hard to overestimate the opportunities, especially for established companies. Big, traditional organizations aren’t necessarily dinosaurs doomed to extinction, but they are burdened with layers of unproductive overhead and armies of unproductive workers. Shedding them a layer at a time will not be good enough to stand up against sleek startups or streamlined Japanese companies. U.S. companies need fast change and dramatic improvements.
We have the tools to do what we need to do. Information technology offers many options for reorganizing work. But our imaginations must guide our decisions about technology—not the other way around. We must have the boldness to imagine taking 78 days out of an 80-day turnaround time, cutting 75% of overhead, and eliminating 80% of errors. These are not unrealistic goals. If managers have the vision, reengineering will provide a way.