In my working life I spend a lot of time working with client organizations to discover and capture useful models of their process architecture. In every country, industry sector, organization type and size, there is a common problem that bedevils every project.
We all, and I include myself here, can too easily slip into the habit of the last 100 years (or you might argue 1,000 years) of visualizing the organization as its organization chart.
Comments such as “What about the work they do in department X?” might just be a useful test for a developing process architecture, or they might indicate a lack of understanding of what the architecture represents.
Comments such as “I can’t see my department in the process architecture” mean there is a lot of work to be done to create the necessary shared understanding of what the process architecture is, and how it will be used.
In capturing a process architecture, we are not looking to redraw the organization chart; we are looking to reshape how we see, and think about, the organization and how it creates, accumulates, and delivers value to its customers and other stakeholders.
Defining (my view of) process architecture
A process architecture is a hierarchical model of the processes of an organization. Usually created, initially at least, to include the two or three highest levels, the process architecture provides a powerful visualization and management tool.
The process architecture includes not just the hierarchical description of process activities, but also the related resources, documentation, performance measures, measurement methods, and governance arrangements.
Developing a process architecture starts with the organizational strategy; it’s a top-down exercise. What does the strategy promise and to whom, i.e. what are the organization’s value propositions? Those delivery promises take us to the highest-level core processes and we work our way down from there—down as far as we need to, so that we can understand and improve.
Organizations get work done through collaboration across the organization (chart), so the process view can be see as a ‘horizontal perspective’.
Defining the organization chart
The organization chart is a diagram showing graphically the relation of one official to another, or others, of a company. It is also used to show the relation of one department or business unit to another, or others, or of one function of an organization to another, or others. An organizational chart typically illustrates relations between people, and teams of people, within an organization.1
Most organization charts are drawn showing the senior entities at the top, giving an essentially vertical picture of organizational management. Hence the organization chart gives us the ‘vertical perspective’.
Architecture & Organization
The process architecture and the organization chart are different and unrelated. One does not replace the other. They are not in competition. They are alternate views of the organization. We need both.
To put the problem simply, we too often manage the vertical (functional) perspective and give little attention to the horizontal (process) view; the direction in which work gets done is not actively managed in the traditional management model.
A useful test and talking point is that an organization might have a very significant reorganization and that will have no effect on the process architecture. Process architecture will only change if the strategy (value proposition) changes.
Some of the most common problems I see in documenting a process architecture are summarized below, along with countermeasures.
If an organization has been (re)designed to reflect the strategy, and the process architecture also reflects the strategy, then there will inevitably be some similarities between the org chart and the process architecture.
Common problems |
Possible countermeasures |
“I don’t want someone else, a ‘process owner’, telling me how to run my department.” |
|
“I see a process name that is clearly about department X, so where is the process for my department?” |
|
“I’m a senior executive, so I don’t need to get involved in documenting processes.” |
|
“Doesn’t that process architecture look a bit like the organization chart” |
|
Discovering and documenting the process architecture has no impact on the organization chart, and the chart should have no impact on the architecture. Processes, especially high-level cross-functional ones, are about what we do, not how we organize lots of people to contribute to the various parts.
To achieve and sustain viable process-based management, we need, not only a well-developed process architecture, but a shared understanding of the role of the architecture and how it is independent of the structure of the organization. If the process architecture becomes just a redrawn version of the organization chart, simply showing the processes executed within individual business units, then effective process-based management cannot be achieved.
1 https://en.wikipedia.org/wiki/Organizational_chart. Accessed 27 March 2018.