If you read this Column, or have read almost any of my previous Columns, you will see that I am very keen on the development of a reasonably simple, but seriously realistic, and supremely pragmatic Business Process Architecture (BPA) that is then used on a daily basis as a strategic and operational management tool. I'll summarize that briefly in the next couple of paragraphs and then tease it out some more in the rest of the Column. As with everyone else who expresses views on BPM, I shall state them as though they are Indisputable Facts, Acts of God, Laws of Physics, and Cosmological Constants. The world would obviously be a better place if everyone just agreed with me. However, I can't avoid the bizarre fact that there are people with other views. If you are one of them, I'm up for a conversation.
A BPA is the primary artifact of process management and improvement. If you don't have a BPA, you aren't doing process management. If you don't have a documented and agreed understanding of the relationships and interdependencies between your key business processes, then you can't be sure you are really doing effective process improvement. Cross-functional business processes are the only way any organization can deliver value (products or services) to customers, and other stakeholders outside the organization. This gives the BPA primacy. A BPA discovers, defines, and documents the value pathways. More than just a picture or a model, the BPA is a daily aid to strategic and operational management in an organization focused on continuous improvement and delivery of service excellence.
Creating a BPA is not a trivial exercise, and since it will always be subject to change and the exploration of greater detail, it is a never-ending job. Nevertheless a useful, working BPA can be developed in a few months and the immediate value of doing so can be remarkable. Quite apart from creating a solid basis for effective ongoing process management, discovery of the BPA focuses the organization wonderfully on really understanding how it executes its strategic intent.
If you read the above as strong, uncompromising, and unbending, then you start to understand my point of view. Let me explain…
What is a BPA?
For me, a BPA is something quite specific. It is a hierarchical model of the business processes of an organization. Usually created, initially at least, to include the three highest levels, the process architecture provides a powerful visualization and management tool. Over time, the BPA comes to include not just the hierarchical description of process activities, but also the related resources, documentation, performance measures, measurement methods, and governance arrangements.
I am not talking about what might generally be called a “Business Architecture” or some variation on that and the other artifacts of “Enterprise Architecture”. I am talking about the documentation of the highest levels of business processes in an organization, i.e. the pathways through which value is exchanged with customers and other stakeholders.
The increasingly common predilection to want to define every object in an organization, and then show its relationship to every other object via an impressively complicated and abstract diagram, seems to me to be of limited benefit to business managers. Organizational management is difficult enough without creating more complexity. A comment I hear regularly amongst managers, especially senior executives, is that the frameworks they see are too complicated and offer little practical benefit in day-to-day operational management. They want something that is practical, proven, and effective.
As I define and use it, a BPA is a simple, but not simplistic, view of how the organization creates, accumulates, and delivers value. It is a practical and pragmatic management tool. Figure 1 shows an example.
Figure 1 shows the top two levels of business process for a university. Now, many readers will have suggestions about how it could have been done differently, but that's not the point of this Column. This example was thought to be a very good reflection of the university operation by some 100 people who participated (and argued, and debated, and challenged, and disputed, and contested … after all, it was a university!).
The format of the BPA picture used here is common enough showing management, core, and supporting (aka enabling) processes. At this level, the modelling requirement is quite simple and the most useful tool might be ‘pen and paper'. Beyond this level, of course, if you intend to do serious process management and improvement, then you need a good repository-based modelling tool and the related infrastructure and expertise to use it properly.
Figure 2 shows another BPA example, this time for a teaching hospital.
Both of these examples of the highest levels of a process architecture hierarchy represent everything that the organizations do. The university creates graduates, conducts research and contributes to society. The hospital cares for patients, develops healthcare professionals, carries out research, and reaches out to improve community health. In both cases there are many other management and supporting processes that make those core activities possible.
The value propositions of, for example, create graduates and care for patients are embedded in the BPA because the highest level processes were derived from the organization's strategy. An organization's strategic intent is executed via its business processes so the BPA shows how strategy is operationalized.
A BPA is a hierarchy of business processes. The examples above show just two levels for the university and one for the hospital. When first developed, two or three levels of the BPA is usually sufficient. Over time, many more levels are defined and detailed as required to address specific organizational performance issues. Every process can be decomposed into sub-processes, so there is no theoretical depth limit. However, in practice, we go only as deep as is needed to address a particular issue. It makes no sense to say “we will identify all of our processes”.
Having documented a BPA, the obvious next question is how do we measure and manage performance of the processes so identified. That's a topic for another time, and you'll find much of that discussion in my previous Columns. Suffice to say here that the BPA does need to be maintained and that this needs to be done in a controlled and coordinated way. This is at the heart of process-based management.
Using a Process Architecture
A well-formed BPA is a powerful management and decision making tool that can be used in many ways, some of which are outlined below.
Focus on value
Visualize the organization's processes. If processes are to be managed and improved they must be defined, collected, and collated – that's a BPA.
Concentrate organizational focus on value delivery. If you develop and maintain a BPA you are constantly focused on value delivery via the business processes.
Expose ‘value pathways'. Value is created, accumulated, and delivered across the organization chart. A process view means this critical aspect is proactively managed.
Gain agreement about process deliverables. To agree on a BPA it is necessary to get agreement about the processes, what value they should deliver, and to whom.
Provoke powerful conversations. When you ask “who are our customers and what value do they get from us?” get ready for powerful and valuable conversations.
Engage all stakeholders (internal and external). To develop a BPA, a list of stakeholders, and an assessment of the value delivered to them, are prerequisites.
Provide repository of process information. A BPA model provides a single place where all process information can be stored or linked, a portal to the process view.
Define interfaces to external parties. Processes traverse organization boundaries to interact with external processes. Such interfaces can be defined in a BPA.
Understand process interdependencies. No process exists in isolation; change one process and others will also change. A BPA uncovers these interdependencies.
Prioritize process analysis/improvement activity. Every organization has many processes. Where is the Return On Effort in analysis and improvement?
Coordinate process project portfolio management. The output of one process is an input to another. Uncoordinated process change might just create a new problem.
Developing and maintaining a BPA is not about abstraction (or abstract art), it is about providing practical, proven, and effective support for the achievement of organizational performance goals through evidence-based, coordinated improvement in the ecosystem of business processes.
There are many things you might do in response to the issues discussed in this Column. Here are four practical steps you might consider doing now to get started on the creation of sustainable process-based management.
Just build it
You (yes, you) don't need permission to start building a BPA for your organization. Find the strategy statements and determine who are the customers and others stakeholders and your organization's value proposition for them. These are likely your core highest level processes (I'd call them Value Chains). Start decomposing those processes. You will need permission and agreement (and lots of it) to make it official, but you can start right now without anyone's approval.
Hang it on the wall
Once you've got something you and a few others think is reasonable, socialize it on internal websites or notice boards. ‘Hang it on the wall' and see what people say. Give folks the opportunity to comment and take note of who comments as well as what they say.
Continue the Discussion
You've started the process performance discussion with a group of people who have expressed interest in the idea of process and the BPA. Keep talking.