Practical BPM: Process Maps

	Bookmark This Page Email This Page Format for Printing Submit an Article Read More Articles
	Related Tools & Articles A Hierarchy of Processes How To Create Better Looking Process Maps An Overview of Business Process Modeling
	Discussion Forum "I would really appreciate seeing some screenshots of process maps. Not the whole process but just part of it -- some little piece of it, with a bit of explaining about what the map is showing so I can understand just how detailed we should make our processes..." Contribute to this Discussion

By Rashid N. Khan

A process map is a graphical representation of a business process. It describes the step-by-step sequence of tasks that have to be performed in order to take one case, or incident, of a business process from initiation to completion. The purpose of a well-defined process map is to graphically illustrate the essence of the business process. By simply looking at it, you should be able to determine the purpose and overall flow of the process.

The process map for the sample business process sketched in Figure 1 is presented in Figure 2. As the map shows, it's remarkably similar to the sketch. However, the similarity is misleading because there's a lot of process logic encapsulated inside a process map. By itself, the process map defines the default flow of the business process under normal conditions. The map shows that after a user initiates an incident by completing the Request step, the next step is the Supervisor step. After the Supervisor step the process takes one of three paths depending on whether it has been approved and the amount of the purchase. Likewise, if the recipient of the Supervisor step returns the incident because of incorrect or incomplete information, the process will go back to the Request step. The flow, or the sequence of steps after the Supervisor step, is readily apparent.

Figure 1: A sketch of a simple purchase requisition process.

From this simple example it can be discerned that a process map is made up of the following components:

Steps

A step represents a discrete task in the process that is performed by an individual, group of individuals, a sub-process or a computer application.

In reality, more than one task may be performed at the same step. The exact breakdown or granularity of the tasks performed at each step is a decision best made by the process designer or analyst. The important point is that a step represents one or more tasks that are performed together before the process can move on to the next step.

Since a step or task in a process can be performed by individuals, applications or other processes, steps can be of three different types: user steps, application steps or sub-process steps. In Figure 2, the Request, Supervisor, Controller, Purchasing and GM are user steps, since individuals perform these tasks. The Disapprove and Print PO steps are automated application steps that are used to send an email notification and print the purchase order using third-party applications.

Figure 2: A process map of that same process.

Links

Links join steps together to indicate the flow of the process from one step to another. Links provide directional information. They originate at one step and end at another. This indicates that when the originating step is completed, the destination step is activated and the work flows from the originating step to the destination step. In Figure 2, the Request step is linked to the Supervisor step to represent the fact that when the Request step is completed, the Supervisor step will be invoked.

Links also signify the default path that the process will take when any step is returned. For example, a user may receive a task but not complete it because of the lack of some information or the need for clarification. The user will want to "return" the process instead of simply aborting the case.

Junctions

Junctions are dummy steps. They don't represent a task. However they perform very useful functions in process maps since they can be used to represent forks in the road where a process path splits into multiple paths, or multiple paths converge into one. In some BPM solutions, junction steps can have event condition tables associated with them. These condition tables essentially represent the rules that dictate the path that the process will take based upon conditions that have been defined for the business process.

Anchors

Anchors are graphical artifacts that are used to change the direction of links in a process map. Their sole purpose is to provide a clear representation of the process. In the example in Figure 2, anchors are placed at several points to straighten the links and improve readability of the process map. Anchors are also useful for combining multiple process paths into one path to make it easier to represent complex process maps. Figures 3 and 4 illustrate this benefit. Figure 3 shows a section of a process map that has four steps: A, B, C and D. After the completion of any of these steps, the process has to activate all three of the following steps: E, F and G. The sheer number of links makes the map unnecessarily complex in appearance.

Figure 3: A process map without anchors.

By using anchors, the process map can be greatly simplified as illustrated in Figure 4.

Labels

Labels uniquely identify each step in a process map. They can also be used to display annotations on the map for explanations or clarifications.

Conditions

Every business process must deal with special conditions and exceptions. The number of special conditions and exceptions increases with the size of the organization. A process map uses conditions to enable process designers to effectively encapsulate business rules and exceptions. (I'll explore conditions in a future article because of their importance.)

Process Variables

Process variables are the pieces of information related to a process that a BPM solution uses in order to make decisions or take actions.

Figure 4: A process map with anchors.

Business processes deal with a wide variety of data in different formats. A majority of the business data routed by a BPM solution is contained in other systems that are connected to the BPM solution, such as databases, electronic document management systems and record management systems. However, business processes must have easy and real-time access to a subset of this information that can be used to make decisions about routing and flow that is context aware and based on the business information being routed or gathered.

Process variables provide a mechanism for doing this and making routing decisions dynamic and sensitive to real-time business information.

Forms

Electronic forms provide the user interfaces for the participants of business processes. Modern BPM solutions route information to the participants. Forms are the windows that enable users to review the information, enter new data or make decisions. It should be noted that enterprise application integration (EAI) systems don't use forms because the participants in EAI processes are computer applications rather than individuals. For EAI systems, the equivalent functionality is provided by data transformation and mapping that allows information provided by one application to be transformed and mapped to corresponding information fields in third-party applications. (I'll cover data transformation and mapping in a future article as well.)

Useful Links

This article is an excerpt from Rashid Khan's Business Process Management: A Practical Guide. Order your copy here:
http://www.bpmenterprise.com/yDQ

Ultimus
http://www.ultimus.com/

About the Author:

Rashid N. Khan is the founder and Chief Technical and Strategy Officer of Ultimus Inc., a pioneer in business process management and workflow automation. Prior to establishing Ultimus, founded Sintech Inc., a leader in advanced software for mechanical testing. Rashid sold Sintech to MTS Systems in 1989, where he worked for a five years as a vice president and general manager. During this period he took the company through ISO 9000 certification. This experience made him aware of the need for business process management and workflow automation. Rashid obtained two undergraduate degrees from MIT in computer science and political science. Khan is the author of Business Process Management: A Practical Guide, has published numerous articles and spoken at a number of events. Contact Rashid N. Khan at info (at) ultimus.com or visit http://www.ultimus.com.

Rate This Article:  Current Rating: 3.62   Poor    Excellent                1    2    3     4    5   View all top-rated articles

Copyright © 2003-2008 – BPMEnterprise.com, CTQ Media LLC. All Rights Reserved
Reproduction Without Permission Is Strictly Prohibited – Request Permission

---

Publish an Article: Do you have a process management tip, learning or case study?
Share it with the largest community of Business Process Management professionals, and be recognized by your peers.
It's a great way to promote your expertise and/or build your resume. Read more about submitting an article.