7: The Hunt For Reengineering Opportunities
The object of reengineering is a process. One does not reengineer a business unit - that is a mere reorganization. A unit may be reorganized in the wake of process changes - different tasks will be done by different people, so jobs and relationships change - but this is a side-effect and not the primary object of reengineering.
Processes are what companies do. In order to achieve a given goal, a series of tasks must be performed, and given that companies pursue the same goals again and again, it finds an efficient way to organize the work required. That is, when an invoice must be paid, it is not a new or unusual problem and the company does not need to decide how to proceed - it has a process in place to take care of this routine task.
One way to get a better grasp of a process is to consider its beginning state (what situation exists that requires action) and end state (what results are achieved as a result of action). A few examples:
- Manufacturing: starts with raw materials and results in finished goods
- Selling: starts with a lead and results in an order
- Fulfillment: starts with an order and results in a shipment
- Service: starts with an inquiry and ends in a resolution
- Strategy Development: starts with market requirements and ends in a business strategy
The "process map" is a formal document that maps the flow of work, much in the way that an electronic diagram maps the flow of current through circuitry: it starts at one point, flows through various elements, is changed as a result, and ends at another point. Diagramming the process helps everyone understand the work flow, and often the act of diagramming helps to identify some of the awkward and inefficient parts. Ideally, a process map will be very simple: there is a clear and understandable flow from beginning to end.
Processes also kick off other processes. Sales starts with an lead and results in an order, and the order is fed into the fulfillment process to result in a shipment, and it likely kicks off a separate process for collecting the associated payment, etc. There is some argument to be made as to whether these are separate processes at all - for example, a firm that manufactures when a product is ordered may regard its manufacturing process to be a sub-process of order fulfillment.
A very important point, not to be overlooked, is that most business processes start and/or end with a customer. There are a small number of processes in which a customer is not involved (hiring begins with an opening and ends with a new hire, compliance starts with a law and ends with a policy, etc.) and these tend to be processes that do not generate revenue for the organization.
The author returns to the point that business units are not processes - they are people who perform tasks as part of the process. Thus, there is no "accounts payable" process, but the task (or sub-process) of paying an invoice is part of the process of procurement.
Process maps do not require months of work to construct. You may be able to gather enough information to describe a given process in a single week, though several weeks is the norm for some of the more complex processes within an organization.
The as-is process map does not require much thought, merely asking questions (what happens, then what happens) and connecting the dots. People may be surprised when they see the full scope of a process in which they have participated in a simple step, but there should be no surprises or objections.
Choosing the Processes to Reengineer
Once the processes are known and mapped, deciding which ones require reengineering can be a difficult matter: trying to do all at once is impractical. Firms tend to focus on:
- Processes that have the greatest cost savings or revenue improvement
- Processes that are causing the most organizational headaches
- Processes that have the greatest benefit to customers
- Process that can quickly or easily be changed
The author suggests a more diagnostic approach - considering problems as "symptoms" in choosing which processes require attention.
Extensive information exchange, data redundancy, and rekeying
This symptom is generally the result of unnecessary and arbitrary fragmentation of a process. It could once be detected by the piles of paper moving from one office to another, and is now largely hidden on computer networks - another example of automating bad process with technology. And generally, when that fails, the organization turns to faster or better technology rather than reconsidering the process.
Wherever there is a handoff, the first question to ask is whether a task might be more efficiently handled by a single person. Generally, the answer is yes, and reengineering merely brings together the pieces of work being done by multiple individuals. Where multiple parties must be involved, it begs the question of whether the work must be done sequentially, and cannot be done simultaneously, given shared data.
Inventory, buffers, and other assets
Ideally, a firm would manufacture products just in time to sell them - but because they have difficulty predicting the level of demand, they maintain an inventory of goods in case they need them. The same can be said of supply inventories, petty cash accounts, and even the number of employees sitting idle for times when the workload increases.
These buffers can be reduced or eliminated by processes that are more efficient and predictable, and greater information sharing across the organization as well as with suppliers and customers.
High ratio of checking and control to value adding work
A lot of administrative work is created by fragmented processes to ensure that each person is doing their task according to procedures and their work output meets standards. This is largely necessary to track work through the system and discover exactly what went wrong when irregularities occur. None of this adds any value, and much of it can be eliminated.
Some amount of checking and control is unavoidable, but a single quality-assurance check is more efficient than checking multiple times along the way.
In many instances, the administrative duties reflect a distrust of people to do their work the right way (ritual) as opposed to being concerned about outcomes. The more of a process a single employee handles, the less the need for ritual behaviors, and the less the need to maintain records to prove who is to blame.
Rework and redundancy
This symptom generally indicates that there is poor communication among different departments that are doing parts of the same job. The reason a piece of work must be sent back to be corrected often has to do with poor guidance rather than poor workmanship, and when the same piece of work is done multiple times by different people, it is clear that none of them are aware that others are doing the same thing.
Such miscommunications occur when there are too many people involved in a process and information is not shared effectively. But rather than improving communication, which creates a separate nonproductive task, reducing the number of people required eliminates the need for documentation and enables defects to be recognized and corrected sooner.
Complexity, exceptions, and special cases
Processes grow complex over time. They general begin as a simple task, but every time an unusual set of circumstances arise, the process becomes encumbered with additional steps to deal with contingencies, and even tasks that could be done simply must pass through multiple redundant steps. Also, when something significant changes (such as changing to a new supplier), the existing process is preserved rather than reconsidered - and what happens is that the number of exceptions and special cases increases.
(EN: The author doesn't mention an insidious cause of complexity and bloat, which is overreaction to mistakes. Consider the example in which an invoice was overpaid, so a step is added for an additional person to compare checks against invoices before they are mailed out to ensure it doesn't happen again.)
In other instances, operations have been confounded by standardization, which means defining a single set of steps that will account for any contingency. This results in a single, long process that prevents simple things from being done simply - everything has to flow through the same process.
People work around the system
In some companies, the high-performing employees are those who find ways to circumvent processes and rules to get things done efficiently. There can be no better sign that procedures do more harm than good as when the people who need to get things done seek to avoid it.
Unfortunately, people who work around systems are hiding problems and causing others. One case the author mentioned is a client whose fulfillment process looked terrible on paper, but customers were very happy with getting their orders shipped quickly and accurately. Meanwhile, the sales process looked good on paper, but it was not producing the results that were believed to be possible. On closer inspection, it was found that salespeople were going to the warehouse personally and delivered the orders to their customers. This mean they were working around fulfillment process, and the time they spent making deliveries was not being spent on selling.
(EN: I find it a bit odd that the author failed to include a significant symptom of process issues, which is customer satisfaction. Very often, customers are dissatisfied or leave as a result of a business process that impacts them, and makes the company difficult to work with because he customer must play their part in a senseless process and deal with the labyrinthine bureaucracy. A firm that has processes ironed out can be flexible rather than rigid in serving customers.)
Understanding Processes
Before a reengineering team should proceed to redesign a process, the team should seek to thoroughly understand the existing one: what it is intended to do, how well it performs, and the critical issues that are involved. Because the team means to replace the process, it is not productive to slavishly reconnoiter its every nook and crevice, but it should understand the reason the existing process exists as a means to ensure that its value is preserved.
Analysis in detail is fairly easy and people are comfortable with the task, and it gives them an "illusion of progress" because it involves a lot of talking, meetings, and reams of diagrams and documentation. None of this moves us any closer to understanding the reason for the process to exist. Moreover, the act of performing an in-depth analysis leads us to regard the existing process as important and worth preserving in spite of its inefficiencies - which results in no significant improvements.
Also, those who analyze a process are best served by starting at the end - with the person who consumes the output of the process - to determine if what they are getting really serves their needs. When the consumer of a process is the customer, the impact to the organization can be significant. Even when it is an internal consumer, their needs (served or desired) provide valuable insight to knowing what parts of the existing process are functional, dysfunctional, or entirely missing.
In dealing with the consumer, ask about their needs. To ask question such as "how should the document be formatted" presumes that a document is the solution to their problem - and it may not be. Instead of speaking to the product they are currently getting, speak to the degree to which their needs are being served.
The person who consumes the output of a process is more important than the people who perform the process. To focus on the actors is to find a quicker and more efficient way for them to deliver mediocre or unsatisfactory results.
The author also speaks to the value of observing rather than asking. In an interview or survey, people tell the querent what they think he wants to hear, or say what they think they ought to say, which is often out of joint with what they really do, think, and need. This is especially true when people are breaking rules and working around policies and procedures to get things done - they will not tell you this, and will speak highly of the system that they are not actually using.
Participating is another option: have the analyst do the task so that they get first-hand experience about the efficiencies and difficulties that are involved.
When turning back to the process, what is important to understand is "what" and "why" rather than "how." When you know what needs to be accomplished, you can set aside the things that are presently done and take on an unencumbered consideration of the things that might be done.
There's a brief mention of benchmarking, which can be used in two senses. The first is to use the present process as a benchmark for specific metrics, which can be used to prove the value of the process that replaces it. Your reengineering process is a success if it beats the existing process, in terms of speed, cost, quality, etc.
In another sense, benchmarking is often used to mean bringing in processes from other firms - that is, if your competitor is better at doing something, copy how they do it. This is not recommended, as benchmarking in this way means that you aspire to be almost as good as your competition - which guarantees that even if you succeed, you will be a step behind them.
Looking to other firms can spark ideas - and they can do this with firms in any industry. For example, all companies purchase materials, such that a supermarket can learn from a coal mine, a hospital can learn from a movie theater, and the like. Some of the greatest ideas come from well outside a given industry.
A last point is that when you are seeking to understand current processes, you should not be looking for ways to fix them. Improving an existing process results in a marginal gain, and it can undermine support for a reengineering process if you identify "quick wins" that produce a 20% gain and abandon a reengineering process that might triple the throughput. Making a process more efficient can be a worthwhile effort, but it is different to reengineering.