The Hunt for Reengineering Opportunities

2 Intro Processes, not organizations, are the object of reengineering. Companies do not reengineer their sales or manufacturing departments; they reengineer the work that the people in those departments do. The confusion between organizational units and processes as objects of reengineering arises because departments, divisions, and groups are familiar to people in business, while processes are not

3 Intro… This topic illustrates how companies identify their business processes, suggests techniques for selecting the processes that should be reengineered and the order of their reengineering, and stresses the importance of understanding specific processes before attempting to redesign them.

4 Intro… Processes in a company correspond to natural business activities, but they are often fragmented and obscured by the organizational structures. Processes are invisible and unnamed because people think about the individual departments, not about the process with which all of them are involved. Processes also tend to be unmanaged such that people are put in charge of the departments or work units, but no one is given the responsibility for getting the whole job - the process - done.

5 Intro… Processes can be given names that express their beginning and end states. These names should imply all the work that gets done between their start and finish. Manufacturing, which sounds like a department name, is better called the procurement-to-shipment process. Some other recurring processes and their state- change names: Product development: concept to prototype Sales: prospect to order Order fulfillment: order to payment Service: inquiry to resolution

6 Intro… Just as companies have organization charts, they can have business process maps that give a picture of how work flows through the company. A process map also creates a vocabulary to help people discuss reengineering. Example – see other notes

7 Choosing Processes to Reengineer Once processes are identified and mapped, deciding which ones to reengineer and their order is not trivial. No company may reengineer all its high-level processes simultaneously. Typically, companies use three criteria to make their choices: Dysfunction: Which processes are in deepest trouble? Importance: Which processes have greatest impact on customers? Feasibility: Which of the company's processes are at the moment most susceptible to successful redesign?

8 Broken Processes In looking for dysfunction, the most obvious processes to consider are those that a company's executives already know are in trouble. The evidence is everywhere and generally hard to miss. A product development process that has not hatched a new product in five years can safely be said to be broken. If employees spend time typing data from a computer printout into a computer whatever process they are working on is probably broken. If people's work cubicle walls and computer screen are papered with Post-it notes reminding them to fix this or look into that, the processes involved are probably broken. Etc.

9 Broken Processes… The symptoms to look for in order to identify dysfunctional process include the following: Extensive information exchange, data redundancy and re-keying Problem: Arbitrary fragmentation of a natural process Problem: Arbitrary fragmentation of a natural process Inventory, buffers, and other assets Problem: System slack to cope with uncertainty Problem: System slack to cope with uncertainty

10 Broken Processes… High ratio of checking and control to value- adding Problem: Fragmentation Rework and iteration Problem: Inadequate feedback along chains Complexity, exceptions, and special cases Problem: accumulation onto a simple base

11 Important Processes Importance, or impact on outside customers, is the second criterion to consider when deciding which of the company's processes to reengineer and in what order. Even processes that deliver their outputs to customers inside the company may be of major importance and value to outside customers. However, companies can't simply ask their customers directly which processes are most important to them, because customers, even if they are familiar with the process terminology, have no reason to know in much detail the processes their suppliers use

12 Important Processes… Customers are a good source of information in comparing the relative importance of various processes, however. Companies can determine what issues their customers care strongly about – e.g. product cost, on-time delivery, product features, and so on. These issues then can be correlated with the processes that most influence them as an aid to creating a priority list of those processes that need reconstruction.

13 Feasible Processes Feasibility, entails considering a set of factors that determine the likelihood that a particular reengineering effort will succeed. One of these factors is scope. Generally, the larger a process - the more organizational units it involves - the broader its scope. A greater payoff is possible when a process larger in scope is reengineered, but the likelihood of its success will be lower. Broad scope means orchestrating more constituencies, affecting more organizations, and involving more managers who have their own agendas.

14 Feasible Processes… Similarly, high cost reduces feasibility. A reengineering effort that requires major investment in an information processing system, for example, will encounter more hurdles than one that does not. The strength of the reengineering team and the commitment of the process owner are also factors to be considered in assessing the feasibility of reengineering a particular process.

15 Understanding Processes Once a process has been selected for reengineering, a process owner designated, and a team convened, the next step is not redesign—not yet. The reengineering team must understand the current process. For example: what it does how well (or poorly) it performs critical issues that govern its performance etc.

16 Understanding Processes.. Since the team's goal is not to improve the existing process, it does not need to analyze and document the process to expose all of its details. Rather, the team members require a high-level view, just enough so that they have the intuition and insight necessary to create a totally new and superior design. A common error in reengineering is that at this stage reengineering teams try to analyze a process in detail rather than attempt to understand it.

17 Understanding Processes.. The best place for reengineering team to begin to understand a process is the customer end. What are the customer’s real requirements? What do customers want and what do they get? What problem do they have? What processes do they perform with the output?

18 Understanding Processes.. To understand customer requirements, the team might move in and observe and/or actually work with customers in their own environments. Doing this is another way in which gaining understanding differs from analysis. Interviews can be used. What people tell analysts, however, is what they think they should be doing, what they happen to remember, or what they've been told to say; they do not tell what they actually do. What people do and what they say they do are almost never the same.

19 Understanding Processes.. Observation is better. Even better is participation

20 Understanding Processes.. Another tool that is available to reengineering teams is benchmarking. Benchmarking means looking for the companies that are doing something best and learning how they do it in order to emulate them. The problem with benchmarking is it can restrict reengineering team's thinking to framework of what is being done in its own industry. Benchmarking can, however, spark ideas in the team.

21 Understanding Processes.. Once the team understands what the process customer might need, the next step is to figure out what the process currently provides - to understand the current process itself.

22 Understanding Processes.. Diagnosing the company's current processes, the reengineering team is learning a great deal about them, but not so that it can fix them. Fixing the old processes is not enough. Instead, the team is trying to study the existing processes so it can learn and understand what is critical in their performance. The more team members know about the real objectives of a process, the better they will be at its redesign.