<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1907245749562386&amp;ev=PageView&amp;noscript=1">
Event_bg

The Leonardo Blog

All Posts

Process Architecture vs the Organisation Chart

Process Architecture vs the Organization Chart l Qoute-1 

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.

Case-For-Process_fig2

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’. Case-For-Process_fig1

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

  • Make it clear from the start that creation of the process architecture makes no change to authorities defined by the org chart.
    No change at all.
  • Set up process governance arrangements so that the responsibilities for process execution are very clear. Don’t create an environment where there is constant tension about who is in charge.
  • It is entirely reasonable for people to be concerned if they think vague changes are being made to their responsibilities. Adopting a process view for the organization is a big change—a single presentation and web page is not change management.

“I see a process name that is clearly about department X, so where is the process for my department?”

  • Frequent repetition is required to properly embed the idea that the organization chart and the process architecture are different and unrelated.
  • If possible (and it may not be), avoid using terms that appear in the organization chart in the first three levels of the process architecture.
  • This is another example of the fear and uncertainty mentioned above. Invest considerable time and effort in discussing the role of process architecture.

“I’m a senior executive, so I don’t need to get involved in documenting processes.”

  • This is a critical issue as active involvement throughout the organization is required if process architecture is to have any meaning.
  • Involve executive teams from the start and continually through the development project. Do not wait for a month or two and then present the ‘final’ product expecting immediate buy-in. Think about how to include and bring up to speed all those people who were not in the many development workshops and other conversations.
  • Emphasize that the process architecture shows how the organization executes its strategy, so it is a worthy topic for executive involvement.

“Doesn’t that process architecture look a bit like the organization chart”

  • 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.
  • Acknowledge that there may be apparent similarities and use that to reemphasize that the chart and the architecture are very different things sharing the same starting point.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.

 

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.

Watch 7 Enablers of BPM Video


1 https://en.wikipedia.org/wiki/Organizational_chart. Accessed 27 March 2018.

Roger Tregear
Roger Tregear
Roger is a Consulting Director with Leonardo. He delivers consulting and education assignments around the world. This work has involved many industry sectors, diverse cultures, and organization types. Roger briefs executives, coach managers, and support project teams to develop process-based management. Several thousand people have attended Roger's training courses and seminars in many countries - and Roger frequently presents at international business conferences. Roger has been writing a column on BPTrends called Practical Process for over 10 years. This led to the 2013 book of the same name. In 2011, he co-authored Establishing the Office of Business Process Management. He contributed a chapter in The International Handbook on Business Process Management (2010, 2015). With Paul Harmon in 2016, Roger co-edited Questioning BPM?, a book discussing key BPM questions. Roger's own book, Reimagining Management, was published in 2016.

Related Posts

The Ultimate Guide to Process Modelling

A new day, a new process modelling project. The project plan has been signed off, reference documentation was gathered, all stakeholders have been identified and now…now what? While process models increase in popularity and most businesses seem to agree that process models are indeed a good way of representing how an organisation creates and delivers value, there is little to no guidance on what a good process model is, how to create one and how to successfully go about executing a process modelling project. While this guide does not claim to be a silver bullet for all your process modelling problems (look at our Modelling Excellence framework for that!), it aims to be a guide for Project Managers and BPM Professionals in every stage of the modelling journey, regardless of whether you’re just kicking off a new modelling project, are in the middle of a major project, or are just looking for a refresh. Please note that this guide does not address steps to set up or configure a process modelling tool. It is focused on the activity of process modelling.   Let’s get started! This section includes topics that should be covered prior to kicking off any process modelling project. If a project is already underway, but struggling, we recommend revisiting this section to ensure the basics have been covered. If your project is already underway and going well, you may opt to skip ahead to the “Business Process Modelling” section. It’s all about the purpose… Firstly, ensure the purpose for modelling has been identified and agreed upon by all stakeholders. Whether it is communication, training, process measurement, improvement or configuration of a workflow tool, any modelling effort must serve a purpose. Major decisions such as “What modelling tool is the right one?” as well as minor decisions such as “Should I include this detail in my model?” can easily, logically and consistently be answered once the purpose has been identified. Consequently, if a clear purpose for modelling cannot be identified, no time and money should be spent on modelling as the models would end up being waste. The start of a process modelling project is also a good time to identify additional use cases for process models and pitch those to the stakeholders. The more use cases there are, the more robust the business case for process modelling becomes. Models that are re-used often are valuable to the organisation, rather than just useful for a one-off project. This does not mean that creating models for one-off use is waste. Although we generally recommend maintaining and re-using process models as much as possible, there are many valid use cases for and circumstances under which organisations choose to create process models that will be deleted once the project is completed. We do however emphasise that this purpose needs to be clearly identified and agreed upon, so nobody comes looking for the model two years later and needs to then kick off another modelling project since the former models are either out-of-date or nowhere to be found. Understanding the purpose of modelling will also help Modellers in the information elicitation and model validation stages of the project. They must always be prepared to explain what they are doing, why they are doing it and how it benefits the organisation. A strong pitch for modelling, tied back to the purpose, will help to keep stakeholders focused during workshops.

Moving From Continuous Improvement to Continuous Process Management

  Continuous process improvement is a common organizational aspiration, and it is one of the most difficult things an organization can attempt. The continuous aspect is quite a challenge, as is realizing business performance improvements—especially once the easy and obvious changes have been made. Organizations need an ‘internal improvement engine’ that replaces insistence with evidence.

Process Architecture vs the Organisation Chart

  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.