Major Activities

Figure 13.3 provides an overview of what’s involved in the planning phase. Figure 13.3 uses a process diagram to show who is involved and what happens in what order. Most of the tall activity boxes represent meetings in which members of all the groups get together to review proposals and agree on plans. These meetings and the consensus-building effort that they represent are an important aspect of any major business process improvement project.

Most of the detailed work of this phase is done by the facilitator in conjunction with the steering team. Phase 1 involves:

• • The executive committee appointing a project sponsor and creating a steering team. They in turn appoint a facilitator and a process redesign team. Most of the detailed work is undertaken by the project facilitator, who interviews senior managers and those currently involved with the process. The facilitator creates and presents draft documents for the sponsor and steering team to review and approve.
• • Refining the scope of the process to be analyzed and redesigned. If the corporate committee created documents describing strategy changes, goals, measures, and a description of how the process should be changed, then one begins with them. (This information can be documented on an organization diagram and on an organization goals and measures worksheet, or in any other reasonable format.) The sponsor, steering team, and facilitator should begin by reviewing everything that has been documented. If no documentation of this sort has been prepared, then the team should create it. Unless the BPM group has already done so the team should also review or create a value chain or process relationship diagram to ensure that everyone understands how the specific project fits with other corporate processes. If the project is large the team may want to create a high-level process diagram, define the major subprocesses that make up the overall process, and define their relationships. In this case the team may also subdivide into different groups to then focus on different subprocesses, or they may prioritize the analysis and improvement of subprocesses.
• • Reviewing project goals. The team should review the goals set for the project and explore how they relate to corporate strategy and goals. If the process is large or complex the team may want to identify which subprocesses lead to which goals or create subgoals for different subprocesses. If a process management system is going to be created or redesigned, then managers from the different functional units should definitely be included on the redesign team.
• • Scoping the project, which once achieved needs to be described and a business case for the project needs to be built. We have discussed this in some detail using the gap model in Chapter 8. The team will review and document project assumptions, requirements, and constraints. The more familiar the team becomes with the specific process, the more likely it will see alternatives or identify constraints that the corporate committees overlooked. The team should document every assumption and constraint it identifies to clarify its thinking about the nature of the process. Facilities, manufacturing machines, computer hardware, and software systems are often sources of constraints. Changing them, or working around them, can often impose huge costs on a project and render an effective redesign impossible. It’s important to find out what constraints might limit redesign as early as possible.
• • Creating a project schedule and budget. As the team learns more about the specific project it is planning it will either create a schedule and a budget or refine one developed by the BPM group.
• • Benchmarking data that describe industry averages for specific types of tasks. Or, in some cases benchmarking data that describe what competitors have achieved. In most cases it’s hard to get good benchmark data, although they are widely available for packaged applications from vendors and in some industries from associations. If benchmark data are to be used to determine minimal goals for a redesign effort this fact should be identified in the planning stage and a plan developed to secure them.
• • Determining who will take part in the actual analysis effort and identifying the members of the process redesign team. In most cases only some of the members of the team will actually take part in the workshops in which the process is analyzed. The overall team should determine who will take part and arrange for them to be available for the time required. The analysis and design work will take place during meetings, which are often called workshops. It’s best to have a neutral, trained facilitator to run the process, and we’ll assume one is available throughout the remainder of this discussion.

Outcome

This phase ends with a detailed project plan for a specific business process that has been approved by the executive committee, the BPM group, the process sponsor, and the project steering committee. When everyone agrees on the plan it’s time to begin Phase 2.

Major Activities

Figure 13.4 presents an overview of Phase 2 of the process redesign project. The activities of this phase are undertaken by the process redesign team, guided by the facilitator. Phase 2 involves:

• • Ensuring that things move quickly and smoothly. The facilitator usually reviews the plan and interviews a variety of stakeholders to get up to speed on the process and the problems that call for a redesign. In addition, to ensure that the process design team gets off to a good start the facilitator will often create a first-draft version of the process. In this case, rather than having the team define the process from scratch, the facilitator begins by proposing an overview of the process and then works with the process redesign team to refine the first-draft version. This is a reasonably painless way to introduce organization and process diagrams. The facilitator puts up diagrams of a process the team is familiar with and talks them through it. As the diagrams are easy enough to understand the team quickly gets into identifying activities or flows that are wrong or missing.
• • Documenting the current (As-Is) process and using process diagrams to document an As-Is version of the process. If the process is large begin with a high-level As-Is process relationship diagram that identifies the key subprocesses. Then develop a separate As-Is process diagram for each subprocess. Repeat this process until you arrive at an As-Is process diagram that shows activities and describes the process in as much detail as the team feels necessary. The goal isn’t analysis for its own sake, but a diagram with enough detail so that the team can easily see what will need to be changed to improve the process and to achieve the project’s goals. A good facilitator can help the team focus on creating “just enough” analysis and avoid getting lost in details.
• • Agreeing upon the names of processes, subprocesses, inputs, outputs, and activities. Different groups often use different terms to refer to the same processes and activities. One important outcome of a process analysis should be an agreement on what processes and outputs should be called. This is especially hard if many different functional groups are involved, and it’s very hard if multiple companies are involved.
• • Identifying any “disconnects” or deficiencies in the current As-Is process. Record findings on a process analysis and improvement worksheet. Activities are linked by lines that show where inputs to the activity come from and where outputs go. The lines should be labeled. The flows between activities can be products, documents, information (data), or money. If the inputs or outputs are complex it is probably worth describing them on the process analysis and improvement worksheet.
• • Determining the necessary characteristics of each activity. As we’ve said before we use the term activity to describe the smallest unit of the process we intend to model. Each activity needs a name, and it should probably also be given a written description to be sure everyone will know just what it entails. An activity can be performed by an individual, automated by a software system, or performed by a combination of a person and a software system. You should note how each activity is performed. In other cases it may be important to document how decisions are made during an activity. If the flow from an activity branches it is often useful to include information about how the path a given output takes is determined. If many different business rules are used to make decisions it might be worth listing the rules that are applied. If specific goals, subgoals, or quality measures are associated with an activity they should be defined. All of this information should be noted on an activity worksheet or recorded by means of a software tool. This is another point at which interviewing and group facilitation skills are required and where a knowledge of change management will pay off. The team will need to interview people, individually or in groups, to get information about the As-Is process and its problems. The questions to be asked should be well thought out. Moreover, as team members interview employees they will also have to answer questions about the changes that might take place. Employees will want to know what the team is trying to accomplish. Employees will usually leave these interviews with an initial bias for or against change, depending on how the project is explained to them. If the team members are skillful in explaining the project in a way that makes sense to the interviewees and suggest how the work will benefit them the interviewees are much more likely to support the project in the future.
• • Developing a process management design. Usually, a subset of the entire process design team made up of managers meets to document the current management process. As we have suggested, the management process involves organizational, process, and functional aspects. It also involves establishing goals and measures for the process as a whole and for each subprocess and activity. And it involves actually taking measures and evaluating deviations from the expected results. If this has been done in the past, then existing managers should be able to provide specific data on which activities and subprocesses have been performing well or failing in the recent past. Similarly, there should be documentation on corrective actions that have been attempted. If these data don’t exist the As-Is management team should at least document the structure that does exist and develop a document specifying where the management process breaks down. At a minimum the team should develop a good idea of who is specifically responsible for managing each existing subprocess and activity. Although we have not emphasized it up to this point a process redesign effort typically requires changes in both the specific activities that make up the process and in the management system that monitors and controls the process during its everyday use. In our examination of hundreds of business processes we have consistently found that there were more problems with the management systems that control the process than with the activities that comprise the process. That is why the team should consider how the management system will support the process before going into the specifics of process redesign. Useless or poorly ordered activities will result in an inefficient process. On the other hand, even a relatively well-designed process that is managed by supervisors who haven’t established clear measures or who don’t reward behavior that is critical to the success of the process is just as likely to be inefficient. In reality, in any major process redesign effort we usually find opportunities to improve both the process structure and the management system. We will devote a subsequent chapter to management and measurement problems. If the team plans to do cost studies, then each activity should be analyzed to determine its cost, the time it takes, the outputs produced per unit of time, and so forth. Time and cost can be documented on an activity table, but if you are really going to do cost studies and compare alternatives, then it’s much better to use a software product and enter the information into tables associated with the activity on the software’s product diagrams. This is done on an activity cost worksheet.
• • Refocusing on the project goals and challenging old models and assumptions. After process analysis is complete it’s usually useful to revisit the goals, assumptions, and constraints defined during Phase 1 and to challenge each one. Can it be achieved? Can you do better? Is the assumption or constraint valid? Is there some alternative that will ease or remove the constraint? Revise the goals, assumptions, and constraints as appropriate. This is a good point at which the team might redraw the gap model to summarize what they have learned and what changes they are considering.
• • Recommending changes in the effort as necessary. If, in analyzing the current version of a process, the team realizes that assumptions are wrong or that opportunities exist that weren’t previously recognized they should communicate their recommendations to the steering team or the executive committee and suggest changes in the scope of the project effort. Do not proceed to a redesign phase with flawed goals or assumptions. That’s just a formula for a project that will end in acrimony.
• • Summarizing all the findings in a redesign plan. At the end of the effort the redesign team should summarize their findings and propose a general approach to the redesign of the process. This redesign plan should take into account all the assumptions, constraints, and opportunities the team has discovered.
• • Presenting and defending the redesign plan before all the higher level committees and obtaining their approval. Depending on the organization, this may be a public process or it might take place on a one-on-one basis. The key thing at the end of each phase is to obtain the approval and commitment of all those who will later have to ensure that the new process is actually implemented. As with other employees, the team will need to explain the project in terms each executive will understand, explaining the benefits of the change for that executive. If an important manager doesn’t accept the proposal it’s better to stop and either deal with the objections or come up with a new design. The alternative is to create a plan that will be “dead on arrival,” because one or more key managers won’t support implementation.

Outcome

The outcome of this phase is a set of documents and models describing the existing (As-Is) process, a draft plan for the redesign of the existing process, and the support of all key senior managers.

Major Activities

The major activities in Phase 3 are illustrated in Figure 13.5. Phase 3 involves:

• • Reviewing the As-Is process, improving goals, and identifying specific opportunities to change the As-Is process. Depending on the scope of the design team’s mandate and the schedule the team may focus on very specific types of improvements or may relax all possible assumptions and speculate about radically different ways of organizing the process. This is the point at which the redesign team ought to do some brainstorming and consider really innovative options.
• • Generating a list of possible Could-Be processes and considering the benefits of each. If someone is skilled in TRIZ (from the Russian for “theory of inventive problem solving”) this is a good point to use this innovation technique to help generate some alternative possibilities. In most cases the solution will be obvious and the tendency will be to move quickly from the existing process to the obvious To-Be process. That tendency should be resisted if possible and some time should be spent considering if a real breakthrough is possible. A breakthrough isn’t likely, but when it occurs it often results in huge savings or sharp increases in productivity, so it’s worth considering. Consider how you might reverse each of the major assumptions, and what would result if you did do. What if your agents went to the employee, instead of having them come to your office? What if you shipped the item unassembled, and let the employee assemble it?
• • Designing the new or improved process. The team’s decisions should ultimately result in a new process that is documented on a To-Be process diagram. In complex projects the team may create several alternative Could-Be process diagrams and then choose among them. The new design should eliminate disconnects and unneeded activities and streamline the activities, subprocesses, and the overall process whenever possible.
• • Designing a management process to support the new To-Be process diagram. The management process should specify who is responsible for each activity and subprocess. It should also establish measures for activities and subprocesses. This should be indicated on a role/responsibility worksheet.
• • Rationalizing reporting relationships. In some cases changes in a process may suggest a new organizational chart that regroups employees and creates reporting relationships that will allow improved accountability and efficiency. New processes will often require that new employees and new reporting relationships are created. In either case the team should prepare a new organization chart indicating the hierarchy and reporting relationships of employees involved in the new or redesigned process. When appropriate, the process redesign team should review the actual jobs or roles involved in the process, and determine which functional managers will be responsible for which of the new process activities. This information is recorded on one or more process/responsibility worksheets.
• • Costing or simulating new process options. In some cases design teams will want to compare alternative Could-Be process options with each other or with the current As-Is business process. Or, if the process is new, the team may want to simulate it to learn more about it. This can be very valuable, especially if the process is complex. Simulation often reveals problems that no one notices when simply looking at diagrams. To do costing or simulation, however, the team will have to use a software tool and will need the support of someone who has experience in building cost or simulation models. If the team is already using a tool like IBM’s Blueworks or Qualisoft’s Qualiware, which are designed to represent To-Be process diagrams and do simulation, it will simply be a matter of entering more specific information about how each of the activities will function. If a spreadsheet is to be used, then the team will want to document the costs and times involved in each activity on an activity cost worksheet.
• • Providing detailed documentation of new activities. If specific activities (i.e., jobs, software systems) are being modified or created they should be documented on an activity worksheet. When the team arrives at a fully documented To-Be process design it should arrange to present the proposal to the executive committee, project manager, and steering team. It’s important that these groups not only understand the new process but also approve it. These are the senior managers who will have to work to ensure that the new process is actually implemented. A lukewarm approval from senior management is a recipe for a failed implementation phase.

Outcome

The outcome of this phase is documentation describing the new process and management structure that the design team proposes. This design will probably not be in enough detail to satisfy the requirements of software developers or of job analysts, but it should be sufficient to convey to business managers the exact changes that are being proposed. The redesign plan should be approved by senior managers.

Major Activities

Figure 13.6 provides an overview of the activities in Phase 4. As Figure 13.6 suggests, Phase 4 involves additional participants in the new process development effort. Although representatives of IT have probably been involved in the earlier phases, at this point they will shift and become active on IT software development teams if new software applications need to be created. Similarly, HR specialists will probably work with other human performance specialists to redesign jobs and provide needed training if new jobs need to be created or if new skills need to be provided for those already working on the process being redesigned.

The managers on the process redesign team, working with others in their various functional areas, should refine the management systems, managerial job descriptions, and measures required to ensure that all managers involved with the new process will understand the changes required and the new criteria by which their performance will be judged.

Various groups will test their work individually, and then if it’s a large process it will probably be given some kind of field trial to ensure all the pieces work together before the new process completely replaces the old.

This phase varies in length, depending on the nature of the changes that were selected during the redesign phase. It also varies because different specialized groups may become involved in this phase. Thus this phase usually begins with the development of a new plan by the steering team, working in conjunction with the various groups that will actually develop the infrastructure needed to implement the new process.

In a typical case IT people will be engaged to create or acquire new software to implement activities in the new process that are to be automated. In the course of this activity they will probably need to refine the To-Be process diagrams to create more detailed workflow models, use case models, and any of a variety of other software diagrams, depending on the nature of the software application to be developed.

HR people will be engaged to create new or modified job descriptions and to negotiate needed changes with unions and existing employees. Training people will develop materials necessary to train employees to perform new tasks. In the course of their work human performance analysts will probably develop job diagrams and prepare job analysis worksheets. (See Chapter 6 for a discussion of how HR might follow up the work of the process redesign team.)

In a similar way, if changes in offices or factories are required, logistics teams may be involved to acquire or reconfigure space for the new project.

During this same period the managers involved in the effort should create or refine their management system. If the company is already organized around processes, and the process team is headed by the manager for the process being redesigned, then it will be much easier. In this case it is a matter of refining how the process management team functions and checking all existing goals and measures to ensure that they conform with changes in the process. If, on the other hand, the company is not organized around processes this is the point at which they ought to consider doing so. Obviously, a shift in the management of the organization will need to involve the executive committee and cannot be undertaken lightly. A project manager will need to be appointed. Managers currently reporting to department heads will need to be reoriented to become members of the process team and to report to the process manager. Goals, measures, and incentive systems will need to be renegotiated. Some measures and incentives may continue to flow from the department structure, but most should be tied to the overall performance of the process. If a company is really converting to process management this can easily become a redesign project in its own right.

The alternative—to redesign a process and then leave subprocess managers responsible to department heads and not to an overall process manager—is a recipe for failure. In spite of the redesign, departmental managers will tend to manage to achieve goals chosen for departments and not for the process, and silo thinking will tend to reinsert gaps and disconnects where information and materials are passed between departmental units.

Outcome

This phase ends when the various groups developing infrastructure and resource materials needed to implement the new process have completed their work and tested their materials.

Major Activities

Figure 13.7 provides an overview of what takes place in Phase 5. Few people like change. We all rely on habitual behaviors to make our tasks easier, and change upsets all that. Major changes, in which some employees are laid off and others need to learn to use new software systems, result in even more dissatisfaction. If employees, supervisors, and managers don’t see the reason for the change, it’s much worse. Thus a good transition plan calls for meetings that acquaint everyone involved with the nature of the change and the reasons for it.

It also requires managerial pressure to ensure there is no backsliding. Senior managers on the project steering team need to communicate their support for the change to the managers below them. The new management system needs to provide ways for senior managers to measure the results of the change, and everyone needs to understand that those measures will be carefully watched to make sure the new process works as designed.

If the change is extensive, then individuals need to be designated so that anyone having problems can get in contact with someone who can deal with the problem. Senior managers should follow up their initial meetings with subsequent meetings to let everyone know that the desired new results are being obtained and that management appreciates everyone’s effort.

The activities of this phase vary greatly according to the nature of the new process, the amount of change required, management support, and the resistance offered by those currently performing the process. In many cases the work of this phase will be subcontracted to a team of change management specialists.

If the organization has used a Business Process Management Software tool that not only models but monitors process activities on an ongoing basis, then the manager and others involved in the process rollout will want to take advantage of the tool’s capabilities to monitor the process as it is used and perhaps to modify activities to assure that the process meets its targets and goals.

Outcome

The outcome of this phase is a new process. Beyond the transition, managers will need to work to ensure that the new process meets its goals and to identify new problems that will require subsequent changes. Maintaining a process is a full-time management job.

Agile Methodologies

In this chapter we have described a detailed, step-by-step process redesign methodology. The methodology was designed to be comprehensive, in the sense that we intended to introduce practitioners to most of the concepts and techniques that you might use in a large-scale redesign project. In most actual redesign efforts you will only find yourself using a subset of the processes we have described. Some redesign projects will call for automation and some will not. Some will involve decision making and will involve using business rules and others will not. Our goal here is to assure that you would have a large toolbox and a good idea of when various tools might be appropriately used.

In addition to being comprehensive our methodology is designed as a top-down methodology. We begin by considering all the things that we might do to improve an organization’s performance. We often begin by looking at a value chain and asking where within the value chain we can make changes that will have the largest impact on the organization.

An alternative approach is to start with a specific process that is broken, often a low-level process than can be easily understood. This approach is often termed a bottom-up approach. Methodologies like Lean and Six Sigma are often used in this way. Small teams are trained in these methodologies and then asked to improve processes within their own workgroups or business units.

Still another approach, which is also often associated with Lean or Six Sigma, is termed Agile BPM. The current popularity of Agile approaches derives from work done by software developers in the late 1980s and early 1990s. Earlier, software developers often used large-scale, top-down software development methodologies that required developers to work through a complex series of steps in order. This approach worked well for very large projects and for the software languages used in earlier times (e.g., for corporate accounting applications), but didn’t work nearly so well as software developers started to develop smaller software applications (e.g., for an app to run on a smartphone) written in a modern programming language.

The software people who developed the first Agile software development methodologies emphasized the following ideas:

• • Develop the application in modules.
• • Complete each module independently of others.
• • Try to organize your work so that you can execute and test a module at the end of each week.
• • Develop an approximation of what you want to create and then extend it to be better.
• • Work in small teams so that everyone knows what’s going on.

In the decades since Agile programming became popular, people have used the term more broadly and in some cases indiscriminately. Sometimes you read articles that suggest that every organization ought to be agile, and reading between the lines you realize that all they are saying is that organizations ought to be as flexible as needed and respond to changes as quickly as they can—a truism everyone can endorse.

Applied to process work Agile usually refers to bottom-up approaches where small teams work on small projects limited to a few activities. There’s nothing wrong with such an approach, although it’s better for improving existing processes and it’s not very good for responding to major transformations.

Consider Figure 13.8, which pictures a matrix. Along the horizontal axis we list the steps in a process methodology like the one we have described above. Along the vertical axis we indicate iterations each done one after the other. A team considers the process redesign being considered and asks itself what a first approximation of the solution might look like. What simple first approximation would allow the client to get a good idea of the changes the team might implement? Ideally, a first approximation could be done in a week or two at most. The team then proceeds to undertake the first implementation and roll it out. The team works with the clients to determine if the first implementation is a move in the right direction. Assuming it is the team then proceeds to do another round, adding features to improve the initial implementation. Again, the goal is to complete the second round in a week or two at the most. This process continues with small steps undertaken by a small team. Each implementation is completed, rolled out, and tested with clients to assure things are moving in the right direction. Then another round takes place until everyone is satisfied that the process has been improved as much as possible.

Another use of Agile, when applied to process work, involves doing the work via a single iteration, but omitting as much complexity as you can by using very smart tools. In the 1980s and in early business process reengineering efforts it was common to create process diagrams that listed every single activity that occurred in very large processes. Thus a flow diagram of an auto production line process might cover a large wall with diagrams. Most of the activities shown in the diagrams didn’t need to be changed. Some project efforts got lost in the analysis effort, kept diagramming more subprocesses and defining steps within tasks, and never seemed to get around to actually redesigning the process. In a similar way, we have seen teams begin by trying to enumerate corporate goals or competencies, argue about how many competencies they need, and never get down to figuring out how to create a useful process.

We suggest creating stakeholder diagrams and then turning them into process scorecards. Done correctly, with a balanced emphasis on satisfying management and customer stakeholders, this approach can quickly generate the goals for an organization and show how they link to specific value chains and subprocesses within. Similarly, we recommend using scope diagrams before thinking about doing process flow diagrams. A scope diagram, done in a group with appropriate managers and employees, can quickly identify the major problems a process has. Then we recommend simply drilling down and making flow diagrams for the specific problems identified in the scope diagram. Don’t waste time with comprehensive flowcharts. Diagram only the specific subprocesses or activities you need to understand to make changes to improve the performance of the process.

Don’t think that you need to use all of the techniques we have described. Create a small process improvement team, create a simple process diagram to establish boundaries, do a stakeholder diagram and then a scope diagram, and then decide what else you need to do. You can create your own agile approach simply by using this methodology as a suggested approach rather than a required set of steps. Be agile and create your own business process methodology as you go to reflect the needs of the situation you face.