2: Reengineering The Path To Change
Reengineering means "starting over." It does not mean looking for quick wins, jury rigging, or making minor changes while leaving the system intact - but instead, in means looking at the business afresh, as if the existing structures did not exist, and deciding what the best process is for achieving a given objective.
Reengineering Formally Defined
As a more formal definition of reengineering, the authors offer this: "the fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical, contemporary measures of performance, such as cost, quality, service, and speed."
Then a bit more on some of the key terms in this definition ...
"Fundamental" is meant to imply that the rethinking is done at a very basic level and includes questions about the business fundamentals: why do we do what we do? Why do we do it the way that we do it? Such questions cause people to reconsider the rules and assumptions by which they operate - and while in some instances may be obsolete, erroneous, and inappropriate.
It's particularly important to begin with fundamentals because many processes are based on givens that may not be given: considering the most efficient way to perform credit checks already assumes that they must be performed at all - without investigating whether the cost of checking would exceed the bad-debt losses the company would likely suffer if it didn't. You may be spending dollars to save dimes. Hence it's important to take nothing for granted.
"Radical" is the next term of importance - it's often mistaken simply to mean "substantial," but "radical" derives from the Latin word "radix," meaning "root" or "basis." It doesn't begin with considering how things are done, but why they are done, and whether they should be done. When you consider the core reason you are doing things, it strips away ritual behavior and misconceptions, and gives clearer purpose to the work.
"Dramatic" does mean that the changes from reengineering are likely to be substantial. It is not about making minor adjustments or marginal improvements, but significant changes that will have major consequences. When a firm wants or needs to make a 10% difference in its outcomes, a dramatic change is likely not necessary - and that's a good case for a situation in which the processes can be kept as they are and efficiency can be pursued. Marginal improvement requires fine-tuning.
"Processes" is the last keyword, which indicates the level on which reengineering is applied: it is not focused on a task, a structure, a department, or a job, but on the group of activities that are undertaken to create an output that has value to the customer. Per the earlier example, the process of delivering a good to a customer may be fragmented into several departments - each of which may have lost sight of the larger objective. The only way to regain this perspective is to consider the process itself.
Reengineering Case Studies
The author presents three case studies of reengineering as a means to illustrate how it is done in practice.
IBM Credit
The first case is the credit department of IBM corporation, which provided financing for businesses to purchase the equipment, software, and services IBM sold.
Its original processes for handling credit applications were "positively Dickensian" and took an average of six days, and up to two weeks, to go through various departments - and there was no way of knowing where a credit application might be at any given time. The long waiting period lost them credit business (customers would find other sources of finance) and even service orders (customers would check out other vendors while waiting).
To improve the process, they instituted a control desk - rather than passing work directly to the next department, it would go back to the control desk. This enabled them to know where an application was at any given time, but made service even slower (travel time for the documents).
It was found that working around the system produced faster results: if a manager walked a financing request around personally, getting someone in each office to do their bit and then carrying it to the next, the entire credit application could be processed in ninety minutes. This meant that the majority of the time taken to process requests was transit: applications gathered dust waiting in outboxes or interoffice mail to get to the next step.
The core problem was that the old process was designed to handle complicated applications, but was handling even straightforward ones. The first step was to create generalists, people who could process applications end-to-end, and who would call in a specialist only if needed. Another step was automating some of the routine tasks.
The result was reducing average turnaround from six days to four hours - without an increase in head count (and, in fact, a small reduction) and, during the same time, processing 100 times as many credit applications.
But more importantly, the method was reengineering. They could not have achieved the same results if they simply attempted to make the operation of each department more efficient, or improved the speed of inter-office mail processing. It required reconsidering the entire process.
Ford Motor Company
In the early 1980's, Ford Motors was looking to cut overhead and administrative costs and had targeted its 500-employee accounts-payable department. The executives believed they could reduce head-count by 20% by automating some of the tasks in the office - and the plan seemed pretty good until they visited Mazda, whose accounts-payable department consisted of five employees.
The author remarks that this was clearly a case in which management was focused on making tasks faster, by automating them, rather than revisiting the process. It's a critical distinction, because reengineering focuses on fundamental processes, not the actions of a specific organizational unit.
Thus encouraged to reconsider, Ford eventually discovered that there was not a problem with their accounts-payable department, but with their procurement process. Their existing processes involved a flurry of redundant paperwork - a purchase request, authorization, purchase order, shipping invoice, receiving invoice, and payment invoice. Everything usually matched, but when it didn't the discrepancies had to be traced and clarified - which sometimes took weeks and enormous amounts of time.
The new process eliminated most of the paperwork - for any order where the amount verified by the receiving clerk agreed with the purchase order, payment was issues automatically. If there was any dispute, it would be resolved immediately of the shipment would be rejected. Because human intervention was only needed in cases where things did not go as expected, Ford reduced staff from 500 people to 125, and its vendors took greater responsibility in making sure shipments were right.
Ford even discovered ways to further streamline its processes and reduce working capital in some plants by paying when a part is installed - that is, the vendor's parts, even on Ford's premises, still belonged to the vendor until they were installed on a vehicle. In effect, the supplier was financing Ford's parts inventory - but in exchange, it got an exclusive deal and a more predictable demand, enabling the supplier to better manage its own production and reduce its own inventory.
Again, this would not have been possible if Ford had focused merely on automating tasks in its accounts-payable department, but required it to reconsider the entire process of obtaining and paying for supplies.
And here, the author is able to take another jab at those who suggest technology drives change: the technology to automate accounting tasks existed - but the technology to enable supply chain integration had to be invented: the idea for the new process came first, the technology to facilitate that change came afterward. Had the process been improved using clipboards and photocopiers, it would have been only slightly less dramatic.
Kodak
In 1987, Kodak's strongest rival, Fuji, released a disposable camera to the market. Kodak had no competitive offering, and its traditional product design process required about 70 weeks. To reduce Fuji's lead, Kodak needed to sidestep its processes to be more efficient.
The main problem was that Kodak's design processes were largely sequential: the camera body was designed first, the shutter was designed next, the film-advance mechanism after that, etc., and each team would wait for the previous one to finish. And only when a prototype was completed would entirely separate teams design the manufacturing process for each part.
Kodak leveraged a design tool (CAD/CAM) that was largely used in aerospace engineering at the time, in order to enable designers to work simultaneously on parts of a digital model - that is, they could design their part in advance, and check the following day to see if the someone else's work created a problem for them and resolve it immediately. Just ten weeks into the process, the manufacturing engineers were able to begin their tooling design.
This process, called "concurrent engineering," enabled Kodak to cut its product development time nearly in half, to a 38-week process. Additionally, getting the manufacturing engineers involved early meant that their expertise could be leveraged, resulting in a product that is more easily and inexpensively manufactured, such that Kodak reduced manufacturing costs by 25%.
Recurring Themes
There are a few recurring themes in these case studies:
- Process orientation. In each of the cases, the firms did not merely look for ways to be more efficient in their current tasks, but reconsidered the entire process in a way that cut across organizational boundaries.
- Ambition. All three companies aimed for breakthroughs that would yield dramatic results, not minor changes that would result in marginal improvements.
- Rule-Breaking. Each of the companies broke with traditional methods of operating, questioning and ultimately abandoning assumptions.
- Leveraging Technology. While technology did not drive the changes, it was a significant supporting player in new processes.
What Reengineering Isn't and What It Is
The practice of coming up with a new name for the same old practices, or misusing a name to give gravity to a matter of little significance, is so commonplace that "reengineering" is disregarded even when it is used properly. Some guidance on how to avoid contributing to the clutter:
Reengineering is not the same as automation. While it often leverages information technology, it is different to mere automation. Automation replaces people with technology but keeps the processes the same, and does not question if the processes that are being automated are worthwhile or obsolete.
Reengineering is not downsizing. A downsizing effort reduces the number of workers because there is lower demand in the market - the goal is to reduce the staff because fewer people are needed to produce fewer products. Reengineering may eliminate staff, but as a consequence of making the same (or greater) output by more efficient processes.
Reengineering is not the same as reorganizing. Its goal is not to flatten the organization or reduce the number of managers by reorganizing the people who will continue to follow the same processes. Though, again, the same results may occur as side-effects to changing progresses in a way that eliminates the need for control and oversight.
On the topic of bureaucracy - companies that set out to reduce the number of administrators and managers without changing their processes are treating a symptom rather than a cause, and are doing themselves more harm than good. Bureaucracy is organizational duct-tape: simply remove the tape and the machine falls apart. People can't be arbitrarily removed from a system that needs them - the system must be changed so that their work is no longer needed.
Reengineering is not the same as quality improvement. There are some common goals and practices, but the fundamental difference is that quality programs seek to improve the existing processes without changing them. To do what we already do, but do it better, and generally by making small changes incrementally. Reengineering changes the processes, which entails significant changes.
Ultimately, the author feels the best distinction is in the original two-word definition: "starting over." Beginning with a clean sheet of paper, considering what is the right thing to do rather than what is already being done.