logo
Tune to your processes... Pусский | Română
News
BOSTON, June 16, 2014  - MEGA has introduced HOPEX Regulatory Compliance to help companies meet...
Upcoming events
Thursday, August 28 | 11:00am EDTIntegrating processes across the organization can often lead to...
.
árnyék

Webinars

MEGA Byte #8: Streamlining Process Management Using Process Frameworks

Newsletter sign up:

Demo request

News > BPMN for Business - The Role of the Customer

BPMN (Business Process Management Notation) continues to gain popularity among users and vendors. As most readers know, this notation was created by a committee of individuals drawn primarily from the leading modeling vendors in the 2004-2005 timeframe. (1) It was specifically designed to support a BPMS programming language like BPEL. The idea was that one would be able to model a process and then generate code from the model. To do this, the notation needed to be rigorous and complex, so that one could draw a diagram that covered all the detail that a software system would need in order to generate a working application. BPMN currently provides that rigor and detail, and the result is that a detailed BPMN diagram can be quite complex.

Most business people, however, are not interested in developing a BPMN diagram capable of generating code. It requires focusing on too many details that only a software developer would understand. Thus, from the beginning, the BPMN committee agreed to develop a second version that would consist of a core set of the more detailed complete notation set. Your author was present at this first BPMN committee meeting and was a strong advocate of this approach. The objective was to provide business people with a core notation that would allow them to develop a description of a business process. Then, if a BPMS application was to be developed, a business analyst or software developer would extend the initial diagram to make it capable of generating code. This approach would allow both business people and software developers to use a common notation without requiring business people to master the details of a notation that is complex enough to generate software.
Some make this distinction clear and discuss the business uses of the core notation and the extensions as a way to prepare BPMN diagrams for code generation. Others blur the distinction, or focus only on the entire BPMN notation and treat BPMN as if its only purpose is as a modeling notation for software developers.
Others, like BPTrends Associates, who develop and deliver training courses on process analysis for business people, confine themselves almost entirely to the core BPMN notation and even add items to the core notation that are only used by business managers as they seek to understand their existing processes or to create new and improved process designs.
Another goal of the initial BPMN committee was to make BPMN as compatible as possible with the OMG’s UML activity diagram notation. This was to assure that those using UML – the most popular notation for software development – would find it easy to understand a BPMN diagram. With this in mind, BPMN adopted the swimlane framework that was originally created and popularized by Geary Rummler and Alan Brache in their 1990 book, Improving Performance. In the mid-Nineties, the Rummler-Brache notation was adopted by IBM and used in LOVEM, a technical methodology that extended swimlanes to incorporate swimlanes for software applications.
The BPMN committee was interested in being able to model collaborative software applications and thus introduced a new rigor and discipline into the BPMN swimlane diagrams, using the concept of pools to differentiate swimlanes that were part of a single process and shared data, and those that were independent and situated in separate pools.
As I have read articles on BPMN, and especially articles on the business uses of BPMN, I have been disappointed to discover that few authors seem to respect the expressive power of the customer swimlane.
Geary Rummler originally developed “swimlane diagrams” to do three things. The first goal was to show the flow of a process from one activity to the next. The second goal was to show who was responsible for each activity. All the activities within a single swimlane were the responsibility of a single business unit or individual. In the case of high level processes, the swimlanes were generally given departmental names. As the process diagrams became more detailed, the swimlanes became more specific and, ultimately, designated the roles of the individuals performing specific activities. The third goal was to show how the process interacted with the customer(s) of a process. The customer(s) swimlanes were generally placed at the top of the diagram. Suppliers and technical support swimlanes are usually placed at the bottom. (2) Figure 1 provides a very simple BPMN diagram using only core notation.


 

Business process analysts have always been concerned with the customer. The Six Sigma folks talk about the Voice of the Customer (VOC) and it has recently become popular to speak of Outside-In as a way of emphasizing the importance of starting with the customer. It is the ultimate customer who usually triggers the process by asking for a product or service. Moreover, the success of the process is usually determined by the satisfaction experienced by the customer. This is true in the case of manufacturing processes that deliver products to customers and it is also true in service processes where the customers and the process personnel interact to generate a service. In all cases, every process analyst should be aware of all of the places where a specific process or subprocess interacts with the customer.
In more complex cases, there can be multiple customers and it’s easy to find yourself doing diagrams with two or three customer swimlanes at the top. In more fine grained processes, the customer for a given subprocess might be another subprocess that depends on the process-in-focus for their inputs. (Some analysts speak of the latter as internal customers).
When one is considering developing software for a sub-subprocess of a larger process, it’s conceivable that one might create a BPMN diagram without using swimlanes. But, whenever one is focusing on large processes, and especially if one is a business analyst trying to redesign a process, it is absolutely critical to use swimlane diagrams to define the interaction between the process and the customer. Good metrics depend on knowing where the process and the customer interact. Good process redesign depends on knowing how any change in the process will impact how the process interacts with customers.
I have written in other Advisors about how, in many cases, BPTrends recommends modeling the customer process in detail. In essence, one begins by focusing on the customer swimlane as if it describes the process you are focusing on. What does the customer do, in what order? When does the customer have to make decisions, etc? In a March 2009 book review of Lean Solutions (James Womack and Daniel Jones, Free Press, 2005) I described how Womack and Jones advocated a similar approach and even went so far as to model the value add of each customer activity.
Most companies claim that they want to make customers happy. Companies that are serious about this goal study what their customers have to go through to do business with them, and then seek to “redesign” their customer’s process – experience – to make it easier, faster, and more pleasant.
The idea of starting with the customer, of focusing on the customer’s process, and improving the interfaces between the customer and the business process, were in Rummler-Brache from day one. They are potentially there in UML activity diagrams and in BPMN swimlane diagrams if modelers and analysts will simply take advantage of the customer swimlane.
Processes today are more customer-oriented than ever, and the Internet and product customization are all increasing the importance of highly refined customer-process interfaces.
The BPMN customer swimlane is one of the most important innovations in process modeling in the last two decades. Every process practitioner owes it to him or herself to understand this tool and to make good use of it.

Paul Harmon
 
.