Which?

The many forms of process work – management, analysis, measurement, automation, innovation, mining, modeling, (re)design, simulation, accreditation, optimization, digitization, etc. – all demand an answer to a common question. Which process?

By any definition of a process, an organization will have at least hundreds, perhaps thousands, even tens of thousands, of them. Can we work with all of them? Given there are so many, they must form a complex multi-dimensional ecosystem with lots of interdependencies. How do we even know what they are?

For a particular organization, what are our processes? Which are unique to us? Which processes are common to everyone? Which should we focus on?

In an area where there are many different understandings, definitions, and approaches, there is general agreement that an organization’s processes should be documented in some hierarchical form and in various levels of detail. Whether it is called a landscape, architecture, hierarchy, or other term, this collection of named processes is a common starting point on the process management journey.

Then the warm feelings of harmonious agreement evaporate as we encounter different approaches, languages, and fundamental concepts about how to discover, collect, and curate the process collection.

My View

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 process architecture (PA), aka enterprise process architecture (EPA), that is then used daily as a strategic and operational management tool.

The process architecture is the primary artifact of process management and improvement. If you don’t have one, you aren’t doing process management. If you don’t have a documented and agreed understanding of the relationships and interdependencies between 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 process architecture primacy as it discovers, defines, and documents the value pathways. It is a daily aid to strategic and operational management in an organization focused on continuous improvement and delivery of service excellence.

Creating a process architecture 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 process architecture 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 process architecture focuses the organization wonderfully on understanding how it executes its strategy.

For me, a process architecture is something quite specific (examples later in this paper). It is a hierarchical model of the business processes of an organization, i.e., the pathways through which value is exchanged with customers and other stakeholders.

Usually created, initially at least, to include the three highest levels, the process architecture provides a powerful visualization and management tool. Over time, it comes to include not just the hierarchical description of process activities, but also the related resources, documentation, performance measures, measurement methods, and governance arrangements.

As I define and use it, a process architecture is a simple, but not simplistic, view of how the organization creates, accumulates, and delivers value. It is a practical and pragmatic management tool.

Some principles

I find these guidelines useful in conceptualizing, discovering , and using a process architecture.

1. Keep it simple – as simple as possible but no simpler. Management is a complex undertaking, and our goal should be to make it easier, not harder. There is no prize for the most complicated diagram.
2. Make it useful – be a solution, not a new problem. To provide a positive return on the effort involved in discovering and managing a process architecture, it must deliver practical benefits in management planning and operations.
3. Make it repeatable – strive for similarity at all levels of the hierarchy. Despite differences in scope and purpose, processes at different levels should be conceptualized with a set of shared attributes.

If the process architecture is simple, useful, and repeatable it will be a valuable strategic and operational management tool.

Defining a Process Architecture

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 paper. 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 used here is common enough showing management, core, and support (aka enabling) processes.

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

Both 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.

A process architecture is a hierarchy of processes. The examples show just two levels for the university and three for the hospital. When first developed, 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 our processes”. It’s processes all the way down!

Functional & Cross-Functional

I find the phrase “functional process” a contradiction in terms. Functions and processes are different entities. An organization’s processes are defined in the process architecture. The organization chart defines the functions.

These are two different views of the same organization. One is not derived from the other. I find it very useful to keep function and process separated both as concepts and operational entities.

At the highest levels of a process architecture, the processes are totally cross-functional or end-to-end. For example, the processes Care for Patient and Produce Graduate in the hospital and university examples. Each of those processes depends directly or indirectly on every other process in the architecture and every functional unit depicted in the organization chart.

[If you find a process or function that does not contribute in some way to the execution or management of the most important core processes of an organization, you might question its future.]

As we move down through the levels of the process architecture, the scope of the various processes reduces, they become narrower in terms of impact and involvement of organizational resources.

Go deep enough and a process will relate to the work of a department, team, or a role. Yes, you can say that these are “functional processes” in that they are processes executed wholly within a function, but for me it’s an unnecessary confusion of terms.

Also, be careful about “executed wholly within a function” because that may seem correct but not be accurate. Take a process like Hire Employee. We might say that’s a functional process belonging to HR – it’s executed wholly within HR. But that’s not correct. This is very much a cross-functional process with involvement from hiring manager, candidates, perhaps an external agency, finance/accounting, payroll, IT, building access etc. HR may run the process, but they can’t execute it alone. That’s true of many so-called functional processes.

We don’t need the “functional” adjective. It’s just a process. We have one architecture of processes and all we need to know is at which level the process exists. In the hospital example, Obtain Informed Consent is a Level 3 Core process.

Keep it simple, useful, and repeatable.

Discovering the Process Architecture

Process architecture development begins with organization’s statements of strategic intent in whatever form that is available – vision, mission, purpose, objectives, capabilities, mandates etc. To achieve an effective process architecture requires extended conversations amongst a range of stakeholders and decision makers to first ensure a shared understanding of the strategic intent, and then to visualize and document how that can be translated into the operational processes that execute the strategy. The conversations, and debates, about the architecture are just as powerful as the resulting artifact.

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

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

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 strategic intent. This gives process names and structures that resonate within the organization. Reference models are everyone else’s processes, and while that works well for management and support processes, core processes benefit from bespoke discovery.

The process architecture is never finalized or approved in a way that makes it hard to change. Every aspect 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 architecture is good enough to be actively used.

What next?

The process architecture is simply a management tool, albeit a very powerful one. Like all tools it must be used properly if benefits are to be realized. My 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 process architecture documentation needs to be maintained in a properly controlled way. There must only ever be one process architecture, one source of truth about value creation and delivery.

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

Using a Process Architecture

A well-formed process architecture 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 process architecture.

Concentrate organizational focus on value delivery. If you develop and maintain a process architecture, 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 a process architecture, 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 a process architecture, a list of stakeholders, and an assessment of the value delivered to them, are prerequisites.

Provide a repository of process information. A process architecture 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 a process architecture.

Understand process interdependencies. No process exists in isolation; change one process and others will also change. A process architecture 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 process architecture 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 paper. 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 a process architecture for your organization. Find the strategic intent statements and determine who the customers and other stakeholders are and your organization’s value proposition(s) for them. These are likely your highest-level core processes. 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 process architecture. Keep talking.

In Conclusion

A process architecture 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, a process architecture provides a unifying canvas for all process analysis, management, and improvement work.

Organizational performance is not optimized if we improve the performance of the ‘wrong’ processes. Wise, informed choices are needed to select the processes where realization of opportunities or resolving/avoiding problems will have the highest impact.

Which process? This might be the most important question.

Roger Tregear
Bungendore
March 2025