Use a structured approach to select the appropriate level of effort for your root cause analyses

To be or not to be: How to map business processes properly.

By William D. Conner, III, CMRP, P.E., ABB Reliability Services North America

1 of 2 < 1 | 2 View on one page

There are literally hundreds of business processes in the reliability and maintenance toolkit. Many of these might produce business inefficiencies, potentially increasing costs or adding time and energy burdens to everyone involved in reliability. Money-saving projects might be delayed; failures go unresolved; and spare parts aren’t on bills of materials or aren’t ordered in time.

Companies review business processes regularly when there are major business changes, such as upgrading or changing enterprise asset management (EAM) systems. Too often, the review is only to determine if the revised or new EAM can accommodate the current business processes. While this is critical to the success of any EAM implementation, it doesn’t guarantee that the current business processes are the most efficient or take full advantage of the EAM.

Consider these definitions:

  • Business processes — the interconnected systems by which a company performs standard tasks
  • Business process map — a diagram that shows the steps and alternative paths through the business process, indicates the overall functional roles and responsibilities, and defines decision points
  • As-is map — the chart depicting the current state of the business process
  • To-be map — the chart depicting the defined future state of the business process being mapped

Business process mapping

Figure 1. Business process analysis
Figure 1. Business process analysis

In addition to ensuring business processes meet the need of the EAM and vice versa, business process mapping should be one of the “evergreen” tools used for continuous improvement (Figure 1). Evergreen refers to a practice that continues over time to ensure that the intended results are always current. This often refers to annual process reviews, such as PM task optimization. The purpose of the mapping is to:

  • Identify the current practices, roles and responsibilities
  • Define the desired, future practices, roles and responsibilities
  • Identify the obstacles to implementing the future state
  • Develop an implementation plan to achieve the future state

The most critical tool for business process mapping and improving business processes is the people assigned to the analysis team. The team needs to represent every organizational function that uses the current process.

Figure 2: General Process
Figure 2: General Process

There usually are policy and procedure documents available that define the process being studied. There might also be flow charts that give a pictorial view of the process and any connections to other business processes. Requisitions have an approval process, followed by a purchasing process, followed by receiving. Parallel to these processes are invoice receipt and approval and then disbursement. The business process team needs to have its charter defined, and it’s likely that there will be many teams over time to address all connections.

Business process method

Every business process has a defined start and a defined end (oval blocks). In the most simple case, there are no interconnections to other processes.

Figure 2 shows an analysis of a one-step business process. The process starts; a decision (diamond block) is needed. The positive decision (Yes) results in an action (rectangle) while the negative (No) decision ends the process.

The reality looks more like Figure 3. Note the purchasing business process is not defined in this map. Determining the number of items to be held in inventory is a separate analysis involving a number of factors (lead time, cost, criticality).

Where to start

Figure 3: Expanded process
Figure 3: Expanded process

Once the team is assembled and chartered, the first step is to define the process in its current state. This is the as-is process map. If this is a completely new process, however, the first step is to define the endpoint of the process: what do you want to achieve?

It’s tempting to skip the as-is step. After all, “everyone” knows how the process works. This would be true, except that everone knows how it works from their own perspectives. Part of the as-is process mapping is to review several things:

  • Is the endpoint of the current process defined?
  • What other business processes are related to the process being analyzed?
  • Are there roles and responsibilities defined in the policies and procedures related to the process?
  • Is it possible to define the transaction costs of the current process?
1 of 2 < 1 | 2 View on one page
Show Comments
Hide Comments

Join the discussion

We welcome your thoughtful comments.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.


No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments