Recently, we worked with an organization that had made a decision to outsource one of their major processes. This decision was driven by the fact that they had been struggling unsuccessfully to reduce costs of the process for years, and research indicated that outsourcing the process would not only reduce costs by approximately 25%, but would also deliver performance improvement. Further, their direct competitors were already outsourcing this same process and market forces mandated that this organization move quickly to reduce costs . “We’ve got to do this to stay in business,” they explained. “We can manage the other major processes, but we need to capture that 25% cost reduction if we are to stay competitive.”

The senior manager we were working with was acquainted with the basic concepts of process change and explained that he had been trying to promote a better understanding of the benefits of an enterprise approach to process improvement but had met with little success. “We have been looking at sub-subprocesses and trying to improve them. We’ve gotten some good results, but I now realize that, while we know something about smaller sub-processes, we have no idea how our larger, major processes work together.”

We generally urge companies to create business process architectures in order to understand their core processes. Companies who have developed these process architectures are in a much better position to make decisions about outsourcing and acquisitions, as well as when and how to make major changes in their business models. When everyone understands the company’s major processes, then any major change is easier to describe, plan and implement. On the other hand, if a change is required and there is not a common understanding of exactly what is involved, then everyone is much more likely to make mistakes in the process of communicating the problem and planning for the transition.

This same manager believed that his company needed to launch a major effort to understand its processes – quickly – before it lost control. He went on to say that he planned to purchase a modeling tool and assemble a team of people to model, not only the process to be outsourced, but all the other major processes that interfaced with that process.

At this point, we suggested taking a step back to think about the problem a little more carefully. Yes, it would be nice to understand all the processes in the company in quite a bit of detail, but it really wasn’t required at this point. For one thing, it would take time to model all the processes, and for another, his people were new to modeling which meant they would have to learn to use the tools – too much risk associated with getting it right in the time allotted.

After some discussion, we arrived at the high-level process diagram shown in Figure 1. In essence, the manager thought of the company as made up of four major processes. One was being outsourced, and the other three would remain under company management. Obviously, these are major processes – like manufacturing, sales, and new product development – and there are lots of interactions between these major processes. Figure 1 only represents a subset of the important flows between these processes.

We suggested that they didn’t need to model the process to be outsourced. The outsource vendor was, presumably, going to redesign the process in order to achieve the savings they had committed to delivering. We suggested a better course of action would be to define and control the inputs and outputs to the outsourced process – provide the outsource vendor with the inputs required to achieve the results they had agreed upon. Beyond that, they really didn’t need to know how the outsource vendor managed the process.

In the long run, the company would probably want to model and understand its major processes in a more precise way, but in the short run, we suggested, they should be more concerned about what inputs or outputs would make a difference. Would the outsource vendor reduce what they charged if any of the inputs arrived more quickly or in a different form? Similarly, would any of the company’s remaining processes become more efficient or effective if the outsource vendor could provide inputs in a different manner or format? If they needed precision, they should focus on the business rules that defined how they would evaluate specific inputs and outputs. Similarly, they should consider how they currently measured the existing flows, what managers monitored those measures, and what those managers did when any given flow failed to meet the established criteria.

When we develop a company’s business process architecture we invariably do it top-down. We begin by defining the company’s major value chains, products, and customers. Then, we drill down, one layer at a time. Next, we develop a diagram very like the one in Figure 1. Finally, we proceed to decompose each of the process boxes to identify sub-processes, and continue until we understand all the major relationships. Given, however, that time was limited and that decisions needed to be made, we suggested the company stick with the diagram in Figure 1 and try to learn as much as they could, at exactly that level of decomposition.

We assembled a team of senior managers to discuss the problem and working with the diagram in Figure 1 we defined the inputs to the process to be outsourced and we discussed the outputs that were, in turn, inputs to other processes. We defined rules for key decisions and discussed measures and the managers responsible for taking corrective action if the flows were off target. At some points, we identified sub-processes within the existing three company processes that generated or received outputs, but we focused primarily on the flows themselves, on their nature, quality and quantity, on problems the company had with the existing flows, and on what differences would result in any change in any of those flows.

We identified two inputs that would make a difference in price and efficiency. They were both generated by Major Process A, and we decided that the next process effort at the company should focus on defining the sub-processes of Major Process A and then on drilling down into the specific sub-processes associated with those two inputs to see how they could be improved.

The point here is simple. It would not have been practical for the company to have launched into a major process architecture initiative when they were already committed to outsourcing a specific process. In hindsight, they would have been better off had they done that several months ago but, at this point, there wasn’t time to do it. Luckily, they didn’t need to do it. They could approach the problem, top-down, identify the major processes that interfaced with the process to be outsourced, and then focus on the inputs and outputs to define the process and its relationships with other key processes. This was enough information to help define the outsourcing contract, and it provided the company with a systematic way to move forward as they undertook more process modeling in the months ahead.

Modeling is not an end in itself. It’s difficult to do right and it takes time. The trick, for business people trying to understand and improve processes, is to do the minimum modeling necessary to gain the understanding required to make good decisions.

Till next time,