Business Process Management: Why Do You Model?

The first question most executives ask when I explain how we organize an improvement project is along the lines of “can we skip the process modeling?” They either believe all the processes have already been modeled or they know their employees are saturated from all the modeling or other consulting efforts. The reality is that I rarely find off the shelf materials (process and metrics models) that I can use without significant rework. In this article I want to make a case to model less, not more. Let’s start with why you model.

Modeling for the purpose of modeling. Companies exploring BPM tend to start with a company-wide modeling exercise. “You can’t fix, what you don’t understand, so let’s document all processes in the company”. Over time this becomes a burden to the modelers and the business. Processes change constantly, therefore the documentation ages quickly. This repository requires a large group of modelers to create and maintain. A typical characteristic of this type of modeling exercise is the process fatigue described in the introduction.

Modeling to support an enterprise architecture or service oriented architecture. These efforts are driven by IT departments building an inventory of systems they support. They want to understand where these systems impact the business. No argument so far. The modeling that links the application to the process is often referred to as process modeling. This is incorrect for several reasons. First, the modeling does not normally capture processes that are not supported by systems. (see insert). Second, these modeling efforts describe how systems interact not how processes interact. Third, is your IT staff really the best resources to describe how you run your business?

In many companies demand planning is still primarily done in spreadsheets. Spreadsheets with estimates are used to judge supply and demand numbers by different groups, in Sales & Operations Planning meetings or different geographies. The final results are loaded in the ‘planning’ systems. The ‘excel-system’ and processes may not be visible to IT as they do not require formal IT support.

Modeling for quality purposes. Quality management systems (such as ISO 9000) or SOP programs are examples of this. This type of documentation stems from the drive to have repetitive performance. “We document it so everybody can do it the same way.” The materials are most often instructional to the person that needs to execute the activities, task oriented and rarely crossing organizational boundaries. Experience shows that this documentation does not always represent how the work is actually done, but describes how it should be done.

These are the main reasons I found. The usability of these models in a process improvement project is limited. To fix process problems I need to understand what is done, how it is done, why it is done, who does it, how it is automated, what information is used, and how well it is done. So, why would you model? My Recommendation is that you model to solve a business problem. Model or document only what you need to support your problem analysis. This type of modeling – which is a combination of process and metrics modeling – will be considered valuable.

Where do you start?

I start with a high level metrics model. Many call this a scorecard. Create a table with the key metrics for your line of business. As you may have read in one of my previous articles I prefer standard metrics such as SCOR. Collect current performance data for these metrics and, if feasible, some benchmarking data. Columns 1 through 6 in figure 1.

Figure 1, Example scorecard

Review these metrics with the process owner and agree on the area (metric) of improvement (column 7 in figure 1). Each high level metric is the result of the performances of it’s component metrics. One or more of these components will be showing poor performance. Find these ‘out of band’ component metrics.

For example the cash-to-cash cycle time has a simple formula:

Cash-to-cash cycle time = inventory days of supply + days sales outstanding –days payables outstanding.

If you pay your suppliers much faster than your customers pay you then you are basically financing part of your customers’ credit. This is one of the reasons why your cash-to-cash cycle time may need improvement. You can do the math and use this formula to find which component would need to move in what direction to improve the cash-to-cash cycle time for your business.

The next step is to find the processes to improve. Using a BPM framework such as SCOR provides you with the linkage between metric and process. In my example SCOR will direct you to the planning processes. Focus your modeling on these processes and measure the performance of these processes and their components. This will provide you with relevant data for your analysis.

When do you stop?

Those that model for the first time ask me these types of questions; When do I stop? How much detail do I need to collect? Do I need to measure each activity? The answer is simple: you model until you have the answer. Remember you were going to find the root cause of the performance gap. By the time you have found what part of the planning process is disconnected, uses the wrong information, or is missing you have achieved the objective. Don’t go into more detail than you need.

Going back to the question of the executive “can we skip the process modeling?” Probably not, but we will only model what we really need. Don’t emphasize that modeling is the most important part of process management. It is not. Solving the problem is. Explain you use modeling to support your problem analysis. My short list for modeling less:

• Model for the right reason;
• Model only what you need to support your analysis;
• Stop when you have the answer;

And for your modelers: modeling is in their comfort zones, challenge them to greater things. But like always, don’t take my word for it; prove it to yourself in practice.