Business Process Management - The Design Phase

Recently somebody asked me what some of the key reasons of failure are for new teams adopting Business Process Management or SCOR. The number one risk is obvious: lack of sponsorship. A close second however is the inability to prove the value (of the team). One of the biggest start-up problems is the focus on getting a project started - get busy. That’s really when the clock starts ticking for proving your value (Now the company is actually spending money on your great idea). Many (start-up) teams have problems getting beyond the analysis phase of a project.

Recently somebody asked me what some of the key reasons of failure are for new teams adopting Business Process Management or SCOR. The number one risk is obvious: lack of sponsorship. A close second however is the inability to prove the value (of the team). One of the biggest start-up problems is the focus on getting a project started - get busy. That’s really when the clock starts ticking for proving your value (Now the company is actually spending money on your great idea). Many (start-up) teams have problems getting beyond the analysis phase of a project. They do everything right: scope out the project properly, capture process and metrics data and perform the analysis to root cause the problem. But then they stall. They present their findings and solutions to sponsors and stakeholders and feel they have solved the problem. Next project, please.

Unfortunately this leaves the sponsors and stakeholders with a big question: How do I get to the solution? Yes, you have added value by identifying what is causing the problem and what the direction is to resolve it. But now you need to help your sponsor understand what needs to be done to get there. For this you need to move to the Design phase. The Design phase addresses two questions:

1. What is the detailed solution? Describe how the process will need to operate to resolve the problem. This is referred to as the future state, the desired state or the to-be state.
2. What is the project plan or how to get there? Describe what needs to be done to get from how we do things today (and have always done them) to a better way of doing them.
   Experience shows teams generally spend more time working on the detailed solution, but we know understanding and organizing time and resources is equally as important.

The Detailed Solution.

 The analysis of an average SCOR or BPM project yields approximately 25 solutions to pursue. These may range from “Let’s call Mary today and ask her to copy Bill and Suzy on the report…” to “We need to remove a distribution center from the physical flow…” Each of these solutions requires a different scale of effort and each may require a different level of detail in the solution. Calling Mary probably requires a 1 page explanation why Bill and Suzy need to copied, so Mary can get the right approvals. Rerouting material flows requires more detailed documentation. You’ll have to consider thinking about inventory levels, how transportation is scheduled, how the product is handled, how the product is received. This includes specifications on how appropriate systems would support these processes. Generally, you end up documenting the business rule changes in the systems that will enable the new process.

So, how do you generate this type of detailed documentation? A good all-purpose solution is a cross-functional team workshop. Bring a process design team together and start with explaining the problem, the approach taken and the outcome (solutions). For each solution walk-through the end-to-end process and discuss how the process would need to work. (Make sure you have IT in the room to validate your software capability assumptions). Capture all details discussed in the walk-through: What and how is it done, who does it, what software and tools are used, which rules apply, what is failure/success, etc. A workshop requires a strong facilitator (read: discussion leader).

 There are two major risks in these design workshops: deviation from the solution, and focusing on how to get there before you have determined where to go. An example: Someone who is very vocal insists on “Let’s make the distribution center processes faster.” But we’ve already decided “No, we are removing the DC altogether as it is not adding value.” Keep on track with the main decision. Another example: “We cannot give that business to that freight forwarder; we don’t have a contract with them.” Of course you could give that work to a freight forwarder, getting the contract is an action item on our how-to-get-there list, not an obstacle that prevents us from doing it.

The Project Plan

 By now you may have realized that many of the solutions you identified may require changes in the same processes. You will find that each process you address has unique change management requirements. Think of our distribution center example. The party that used to send materials to the warehouse needs to be informed about the new shipping requirements (perhaps more frequent smaller shipments). If another outcome is to provide the party that used to receive the materials from the DC with electronic notifications, then that requires another change in the shipping processes of the sending party. The changes that need to be made in the shipping process of the sending party may be interdependent. All these types of activities and interdependencies are captured in the project plan. 

 How to develop the project plan? For each party in your process and for each process determine the changes that need to take place. If you have a process map or model of the current state the comparison to the future state is not difficult. Focus on the types of change activities that need to be deployed: Training development, training staff, availability of tools, changes to software, availability of resources, communications needs, new performance metrics and measurement processes, testing, and so on. Next determine the interdependencies of these change activities. For example: developing training materials before training your staff is obvious, but you also don't want to train too early, yet you do need to start communicating about the change early. For each of these change activities you also need to determine the resource needs. At this point, don’t worry about how many, but determine what you need, since you will only know how many after all plans are integrated in your deployment plan. As an example, answer the question: what type of resource do I need for training and how long does a training take?

 What is a deployment plan? A deployment plan addresses how the actual change activities will take place. In my example above I have many options on how I roll out the change: Pilot and Big Bang (test one party and then deploy everywhere else), Central governed (allow each party to develop and deploy their own plans), One party at a time, and so on. A risk for developing the project plan is the focus on deployment issues. Remember that you have to change both the shipping process and the notification process for all sending parties, the workload of this effort is determined in deployment planning.

The take-aways? You must complete the design phase to have a successful program which is seen as valuable; Separate the discussions of what, how and when to the appropriate phase of your project; And to complete the design phase you need to design the change, not just the process. And like always, don't take my word for it; prove it to yourself in practice.

Caspar H. Hunsche is Managing Director and co-founder of Process Core Group (PCOR.com). He is the original author of the Customer-Chain and Design-Chain reference models. He is a practitioner, trainer and advocate of standards based process management.