Sound business process architecture requires key traits
Business processes require a coherent enterprise-level architecture. In this excerpt from his new book, Roger Burlton identifies key traits business processes should share.
Business process management, or BPM, is a system to create and improve activities intended to lead to the achievement of specific organizational goals in an agile manner. In his new book, Business Architecture: Collecting, Connecting, and Correcting the Dots (Technics Publications, 2022), author and BPM expert Roger Burlton guides readers through the process of creating a reusable and adaptable understanding of your organization's design.
Burlton stresses that business processes should be "reusable assets"; this can be accomplished by taking an "enterprise-level view" of all processes, which reveals certain key traits. Burlton outlines those traits that aid creation of a useful business process architecture in this excerpt from Chapter 7.
A sound enterprise-level view of all processes at the higher levels (not workflow-level yet) will exhibit some key traits:
Organizationally agnostic
Business processes typically do not correlate to an organization's formal reporting structure. Certainly, the work described by the processes in the architecture, at some level of detail, will be performed by people, equipment or technologies. However, end-to-end value creation is driven by our external party relationships, not our internal hierarchy, which may change much more often. A good test of the quality of an organization's process architecture is to ask if the process structure could survive a significant reorganization unscathed. If the answer is no, it is a poor process architecture and will have to be changed often when such changes occur. It will get out of date fast.
.png)
Click here to get a copy of
Business Architecture:
Collecting, Connecting, and
Correcting the Dots.
Technologically agnostic
Technological services or implemented capabilities typically enable the processes of the organization. Given the availability of Enterprise Resource Planning (ERP) suites and other off-the-shelf software, it is especially tempting to follow the vendor's implicit design for the organization's processes. However, there is not always a one-to-one correlation between the two. Each process may have more than one enabling technology in use, and multiple processes typically employ a particular technology. The perspectives are different. Falling into the trap of following the technology in a one-to-one mapping effort to create the overall process map will not result in an end-to-end view of the organization's world that can deliver business outcomes to stakeholders. Unfortunately, this is a common trap that IT software developers often exhibit due to their laser focus on getting code to run first.
Value chains
Organizations can have multiple lines of business, products, services, markets and geographies. Trying to mix and match all of these into one consolidated process architecture would be ideal. Still, it may be unwise due to the effort's disparate nature, sheer size and complexity. Instead, it may be more feasible to build architectures around a single value chain at a time, each with its own unique value proposition. For example, retail banking is quite different from wealth management and what happens on the trading floor. To be sure you have well-formed value chains, check to see if the processes are truly different and serve different stakeholders, measures and goals.
Consistent naming
Organizations that have effectively named their processes typically use commonly understood language (i.e., no jargon), have ensured they are quantifiable and use an action-oriented verb-noun convention. Avoid nouns such as the order process. Nouns are for data and things. Avoid gerunds or suffixed verbs, such as marketing. That's for departments. Avoid vague, lazy verbs such as manage technology. Those are for functions or job descriptions. Instead, results or outcomes of value should be clearly visible in the name, such as settle claim and not handle claim. The closing event representing the targeted result of the process should be derived easily by inverting the name, such as claim settled. The process value goal or purpose should be apparent in the name.
