If you have been following my work (thank you), you will know that I am very keen on the development of a reasonably simple, but seriously realistic, and supremely pragmatic Enterprise Process Architecture (EPA) that is then used on a daily basis as a strategic and operational management tool. This is the 'big picture' of process-based management.

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 mine as if they are Indisputable Facts, 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.

An EPA is the primary artifact of process management and improvement. If you don't have an EPA, 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 to customers and other stakeholders outside the organization. This gives the EPA primacy. An EPA discovers, defines, and documents the value pathways. More than just a picture or a model, the EPA is a daily aid to strategic and operational management in an organization focused on continuous improvement and delivery of service excellence.

Creating an EPA 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 EPA can be developed in a few weeks and the immediate value of doing so can be remarkable.

As well as creating a solid basis for effective ongoing process management, discovery of the EPA focuses the organization wonderfully on understanding how it executes its strategy.

If you read the above as strong, uncompromising, and unbending, then you start to understand my point of view. Let me explain…

What is an EPA?

For me, an EPA 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 EPA 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.

As I define and use it, an EPA 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. A University Example EPA

Figure 1 shows the top two levels of business process for a university. 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 EPA 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 expertise to use it properly.

Figure 2 shows another EPA example, this time for a teaching hospital.

Figure 2. Hospital EPA Example

Both of these examples 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 management and supporting processes that make those core activities possible.

An EPA is a hierarchy of processes. The examples show just two levels for the university and one for the hospital. When first developed, two or three levels are 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." It's processes all the way down!

Having documented an EPA, 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 EPA 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.

Discovering the EPA

EPA development begins with organizational strategy. The EPA shows how organizational strategy is executed. To achieve an effective EPA requires extended conversations amongst a range of stakeholders and decision makers to first ensure a shared understanding of the strategy, and then to visualize and document how that can be translated into the operational processes that execute the strategy.

It is possible to develop a form of EPA quickly and with little conversation. ChatGPT et al would probably do a reasonable job even faster. However, such an EPA will not have credibility, will not be well understood, and ultimately will be significantly less useful. The conversations, and debates, about the EPA are just as powerful as the resulting EPA.

The relatively small effort involved in developing the EPA pays great dividends. People who go through the EPA development exercise often say that they are surprised how much better they now understand the organization, its strategy, and how it really works.

It is important for all involved to have a good and shared understanding of the theory, structures, and practice of process-based management, i.e., of why and how the EPA is a key management tool. Therefore, the first step in the EPA development project is a short education seminar.

Some 5–10 architecture development workshops are the critical core of the project. These workshops develop the EPA and are attended by the EPA Development Team (DevTeam), and other specialists as required.

Analysis commences at the highest level of the EPA core processes, usually referred to as level 1 (or L1). At L1 the questions are what does this organization deliver and to whom. Many organizations will have just one or two highest-level core processes; others may have more but seldom more than four or five.

Workshop attendees discuss the strategy and its execution, generating many ideas for process naming and structures. Such powerful and often-robust interactions bring the strategy to life. The workshops are not just about drawing diagrams; they are about uncovering insights into how the organization works to deliver on the promises made in its strategy documents (vision, mission, objectives, purpose, mandates, etc.).

Once the first level of core processes has been agreed, the next levels are defined through thoughtful decomposition of the higher-level processes. How does this process start, how does it finish, and what happens in between?

Developing management and support processes is much easier as a reference model can be used as the starting point. The method is to test if the process exists, if it is called a different name, and then to ask if there are any processes that were not in the reference model.

I don't use reference models for core processes, preferring to start with a 'blank sheet' and the strategy. This gives process names and structures that resonate within the organization. It's worth remembering that reference models are everyone else's processes, and while that works well for management support processes, core processes require bespoke discovery.

The EPA is never finalized or approved in a way that makes it hard to change. Every aspect of the EPA can be changed at any time in the future, and such improvements should be expected and encouraged. However, it is necessary to reach a point where all stakeholders agree that the EPA is good enough to be actively used.

What next? The EPA is simply a management tool, albeit a very powerful one. Like all tools it must be used properly if benefits are to be realized. The common practice is to select a small number (often three) of pilot or demonstration processes to be actively managed using all the concepts of process-based management. Process Owners are assigned to each process, and they are helped in the initial development of the body of knowledge they need to be able to facilitate performance improvement.

Of course, the EPA documentation needs to be maintained in a properly controlled way. There must only ever be one EPA.

Since the EPA is derived from strategy, it is only when strategy changes that the EPA needs to be refreshed. Changing the organization chart does not change the EPA.

Using a Process Architecture

A well-formed EPA 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 an EPA.

Concentrate organizational focus on value delivery. If you develop and maintain an EPA, 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 an EPA, it is necessary to get agreement about the processes, what value they should deliver, and to whom.

Enhance communication

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 an EPA, a list of stakeholders, and an assessment of the value delivered to them, are prerequisites.

Provide a repository of process information. An EPA model provides a single place where all process information can be stored or linked, a portal to the process view.

Facilitate process performance management

Communicate process performance information. To focus everyone on value delivery, process performance needs to be defined, measured, reported, and discussed.

Define interfaces to external parties. Processes traverse organization boundaries to interact with external processes. Such interfaces can be defined in an EPA.

Understand process interdependencies. No process exists in isolation; change one process and others will also change. An EPA 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 an EPA 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.

In Practice

There are many things you might do in response to the issues discussed in this column. Here are four practical steps you might consider taking 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 an EPA for your organization. Find the strategy statements and determine who are the customers and other 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.

Test performance

Pick a process and try to measure its performance. If it was working well, how would you know? How is it performing? Is the performance gap something that should be fixed now?

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 EPA. Keep talking.

In Conclusion

An EPA is the primary artifact in process-based management. It shows how the organization creates, accumulates, and delivers value, i.e., how it executes its strategy.

More than just a picture, an EPA provides a unifying canvas for all process analysis, management, and improvement work.

# # #