Why Name Business Processes?
Business processes are important organizational assets, and a process architecture (the catalog of an organization’s business processes) is an important asset register. Think of it as the BPM equivalent of an organization’s register of fixed assets, like land, buildings, equipment, and so on. A process architecture with well-named processes provides a strong foundation for organizations to “talk process.”
However, unlike fixed assets, which have physical manifestations with well-defined boundaries, business processes are logical constructs. You can’t touch and feel a process in its entirety or clearly see its boundaries. When you name a fixed asset, like an organization’s headquarters building, there is a shared understanding about the fixed asset that is being talked about.
In contrast, even for a well-named process like 'Engage supplier', there is a possibility of different stakeholders having a different understanding of the process. (Even more so, companies who make one of the top five mistakes when naming business processes will find it much harder to work collaboratively.)
Avoiding Misunderstanding
The problem is aggravated during the business process discovery stage. Many business process discovery workshops get disrupted by discussions about whether a specific activity or a case should be part of the business process.
Speaking from personal experience, I remember a discovery workshop for the business process 'Engage supplier' where the participants discussed what the process actually was without any end in sight, only to realize they had completely different notions of the process to begin with!
For one group of stakeholders, 'Engage supplier' meant the complete supplier sourcing process, from identifying a need for a supplier to on-boarding the supplier into the organization’s supplier management and invoicing systems. For the other group of stakeholders 'Engage supplier' only meant notifying the supplier about a need and obtaining supplier quotes. As you can guess, the 'Engage supplier' business process could not be discovered during the workshop.
So, what can be done to avoid this scenario? What are the minimum aspects of any given process that must be specified to name business processes effectively, as well as build a shared understanding of the process?
Scope is the Word
Human beings are sensory beings by nature. To unambiguously name business processes, the 'shape' of the process needs to be made explicit, and this requires the boundaries of the process to be made 'visible'. Thus, to answer the question posed in the prior section, to name business processes effectively, and build a shared understanding of a process, the boundary or scope of the process needs to be specified.
Three aspects of a process scope need to be specified at a minimum:
- Trigger(s) The events that trigger the process.
- Result(s) The results of the process execution for each stakeholder group.
- Dimension(s) If the process is limited in scope along some dimension, that scope needs to be explicitly specified. In most scenarios the following scope dimensions need to be considered:
a. Geographic scope Is the process relevant only to a limited geographic area? For example, an organization will have different 'File taxes' processes for the different geographies it operates in.
b. Segment scope Is the process relevant only to a limited customer segment? For example, the process 'Resolve customer query' may be different for different customer segments.
c. Product scope Is the process relevant only to a limited set of products / services that the organization offers? For example, the process airlines use to transport customers is very different from the process to transport commercial packages, though if you travel economy class frequently, you might disagree!
Some aspects of the scope can be incorporated in the process name itself. Many organizations name their processes in the 'to' convention, as in ‘Order to Cash (O2C)’ or ‘Trouble to Resolve (T2R)’. In others, scope dimensions are made explicit in the name, e.g. 'Resolve High Touch customer query'. Even in these situations, it is prudent to make the scope of the process clear by explicitly specifying the three dimensions of process scope.
Scope before Flow
To make process discovery workshops effective, gain agreement on the name and the scope of the process either before or during the first part of the discovery workshop. This creates a shared understanding of the process to be discovered. The rest of the discovery can then be framed within the agreed process boundaries. Thus, identifying process scope before discovering process flow will result in a more structured and effective discovery workshop.
SAP Signavio Collaboration Hub enables organizations to form a shared understanding of its processes and their scope, as shown in the example below. The 'Procure items' process is triggered by the 'Parts required' event and results in either parts being procured or retrieved from storage, or cancelled due to delivery problems.
Next Steps
Business processes are organizational assets, and they need to be managed and improved. For organizations to 'talk process', a business process architecture needs to be defined, with properly named and clearly scoped processes. The business process architecture provides a foundation for an organisation’s Business Process Management initiative.
If you’re ready to get started with your own Business Process Management initiative, and want to see how the SAP Signavio Process Transformation Suite can help you get the most out of your clearly-named and scoped process models, sign up for a free 30-day trial today.