One of the main challenges during process modeling is to set the appropriate level of abstraction, which depends on the objective and audience. There are a couple of concepts and techniques that can put light on that.
Similarly to writing, get to know the language is not enough. Syntax and grammar are prerequisite, but there are much more required to properly coin a good text.
Objective
Depending on the process map purpose, it might be categorized as follows.
Make sure the objective is clear and everyone involved have the same understanding.
Notation
BPMN is in fact the most accepted notation for process modeling. With the advance of the BPM Systems (BPMS) capable to execute BPMN models, there is an opportunity to use the same notation for different purposes, allowing an incremental design from high level descriptions down to executable process models.
When mapping process to be socialized or criticized by a broad audience, not necessarily expert on the notation, excessive use of advanced notation may turn out to be a problem. Sometimes, a sticky note explaining the control logic will help more than an advanced control backed up by a complex concept. Of course, for automation purposes the model must be syntactically and grammatically correct.
There are other modelling languages and techniques that might work best depending on the situation, as EPC, VSM, IDEF0, and SIPOC. Avoid stick to only one notation.
Private or Collaborative
A private process diagram describes the activities internal to a business entity, and contains all activities and control flows.
The abstract (public) process diagram represents the interaction of a private process with an external participant, thus only the activities relevant to determine the public interactions are shown. And the collaboration (global) process shows the interaction between two business entities, where the activities represent the message exchange between the two participants.
Abstraction level
Apart from the notation, the challenge is to find out the appropriate level of detail to be added to the model. There are 3 different aspects to be considered: 1) amount of analytical info, 2) process modeling levels, and 3) Hierarchical decomposition. All three aspects should be well thought out before to start process mapping activities.
The APQC’s Process Classification Framework (PCF) is used here as a reference model to discuss modeling levels and process hierarchy.
Analytical Information
For analysis purposes, the map might capture as much information as possible. The map may well include elements to represent Gaps, Questions, Risks, Cost, Time, and so on.
A BPMN diagram can be overlaid with analytical info for descriptive or analysis purposes. Alternatively, other methods such as Value Stream Mapping (VSM) can be used for process analysis.
It is important to determine the notation and make sure the team involved knows what to capture and how to depict the analytical information within the model.
Process modeling levels
Depending on the objective and audience, may not be relevant to show all the decisions controls (if any), neither every single alternative path or exception elements. The pyramid below provides a clear categorization of modeling levels, from a high level map of the enterprise, as value chain or functional domains, down to implementation models.
During process discovery initiatives, conceptual and logical levels (as described above) could be used to provide the context and scope. When processes flows start to be captured, worth it cover the overall scope at the logical level, and then refine the models down to business physical level including decisions and other flow controls. If the wider view of the flow has not yet been described and agreed, the audience may end up overwhelmed with low level details, failing to map a more pertinent comprehensive flow.
Hierarchical Decomposition
Business process can be organized in a hierarchical structure, preferably starting from the enterprise high level view, whether the company’s Value Chain, Functional Domains or Business Units. The image below shows the APQC’s PCF high level reference map representing the process categories within a organization.
To build the hierarchical model, the high level elements are then decomposed into logical components. Thus, each level provides a different abstraction of the business process. The APQC’s PCF defines the following levels of a process hierarchy.
Very often during process mapping questions arise about the appropriate level of detail to be added to the diagrams. “Should we map just the high level activity? Or, should we break it down into each step involved?”
It is worthwhile to agree in advance with the team the decomposition level of interest at that time. Build up a common vocabulary to refer to each level, and use it to support process mapping initiatives.
Ideally, the diagrams should stick at the same level, and also respect the process boundaries at a specific level.
For instance, take the “Market and Sell Products and Services” process category (L1), which decomposes as shown below. A process map for L3 process “Define offering and customer value proposition” should represent the flow of L4 activities under that process. The flow should not mix up L4 and lower level tasks (L5). Also, the flow diagram should not cross the boundary of that L3 process. In order to represent how the L3 processes are linked in a broader process, a separate diagram can be created (see End-to-end flows section below).
When conducting interviews or design workshops, it is common to come up with very complex flows, lacking balance in terms of scope and details, looking like spaghetti. However, after the discovery sessions it is important to re-organize the flows in a structured and consistent manner, following a decomposition method as discussed above.
End-to-end flows
End-to-end process flows spans over multiple organization areas. An end-to-end process should start with the request and then extend to the point where the request is fulfilled and the outcome is delivered from the requester perspective.
For instance, the end-to-end flow Order-to-service, start with the order creation, and completes only when the service is provided to the customer. To fulfill the request, a chain of L3 process might be engaged, including manage sales, payments, select supplier, customer care, and so on.
End-to-end models allow analysts to asses performance as perceived by external clients once it exposes the aggregate performance of all process chain contributing to fulfill the requests.
Note that an end-to-end process represented at the activity level (L4) is likely to be hard to read or analyse due to its complexity and size. Instead, the end-to-end flow can be better represented as a flow of linked L3 process. Thus, each L3 process can be decomposed and represented in a separate diagram.
When looking at a flow of linked L3 process, one can drill down a L3 process to assess the details at the lower level (counting on the mapping tool to provide such navigation).
Additionally, mapping the end-to-end flow at level 3 promotes an organized way to reuse process models. It avoids replication of entire L3 process flows within different end-to-end flows.
Pools and swimlanes
Process swimlanes are used to organize activities associated to a specific role or function within a business unit. Questions regarding the appropriate function to be represented by the swimlanes are raised frequently. “Should the swimlane represent the division, the team or each individual role within the team?”
In BPMN a Pool represents a major process participant, usually a business unit or department. The pool can be split into lanes to represent the internal roles or functions for which the activities are then assigned.
As a rule of thumb, the organization can assign a process (L3) to a pool representing the business unit or team accountable for the process. And the activities (L4) are then assigned to swimlanes within the pool.
Note that even not distinguishing the concepts of pool and swimlane (using just generic lanes); the decomposition level would naturally determines what to be represented by the swimlanes, either business unit/ team, or individual roles.
Process Inventory
Process hierarchy is the key to organize the high volume of artifacts, whether to maintain a enterprise-wide process repository, or to organize process artifacts within a large scale project.
A process catalog organized into levels of decomposition provides a consolidated view of all process in scope (project or organization-wide). At the higher level, a enterprise-wide map can be used to frame the processes according to the functional domain or business unit.
Additionally, a process portal (usually in the company’s intranet) can bring a navigable visual map of the enterprise processes, and can also mash up additional information including performance indicators, process owners and others.
Reference Process Frameworks might accelerate the adoption of a enterprise-wide process inventory. For instance, the APQC provides PCF for variety of industries; and SCOR provides a framework for supply chain management. Also, the telecom industry can count on the widely accepted TM Forum Frameworx, which provides a comprehensive reference model.
Email me when Marcelo Stival publishes or recommends stories