Chapter 6

Why are organizational strategy and process

architecture important in BPM implementation?

The first question that the business should be asked at the commencement of
any BPM project is, what objectives and goals do you have for your processes?
The reply is often, we have not yet formulated those aspects, but could we first
start with reviewing and improving our processes? This is absolutely the wrong
way of approaching BPM, and even though organizations often understand
this, they want to do it anyway to obtain quick wins and easy results.

Organization strategy
Why is organization strategy important to
business processes?
Organization strategy is sometimes not considered in business processes.
Here, we list the reasons for this and discuss the conclusions that have
emerged from our experience and research.
1

There is no explicit strategy available. In most cases an implicit organization or business strategy exists, and it has the potential of causing
a conflict with any available explicit information. Another way of
approaching this is to look at the organizations objectives and how
it proposes to implement or achieve them.
In order to ensure that business processes are effectively and efficiently contributing to the organizations strategy, it is essential that the
objectives, and an outline of the strategy, are explicitly specified.
Without agreed upfront process goals, it is impossible to improve the

26

Business Process Management

processes while ensuring that they add value and contribute to the
organizations strategy and objectives. How does the project team
know it is heading in the right direction? The best thing to do in this
situation is to delay the process improvements project(s) until the
main objectives and strategic choices have been made.
Obtaining the strategic information will take too long. In this case, the strategic information is either not communicated or scattered throughout
the organization.
It is important to spend adequate time upfront in understanding
and obtaining this information rather than starting to look at
processes only to find at the end of the project that the assumptions
made at the start were incorrect. One method is to use project meetings with major stakeholders to elicit the strategic information and
promote the benefits of the project.
People involved are not capable of strategic thinking. Some believe that
operational personnel should not be bothered with, or confused by,
the strategic issues, on the basis that such personnel should be
focused only on operational issues.
This is not the case, as it is important for operational personnel
and managers to understand the strategic choices and their consequences. If this is not clear, then workshops are a useful method of
imparting this information and demonstrating how the strategic
issues affect their work and how they can contribute in making a
strategy successful. Operational participants start to highlight operational issues that they know are at odds with the strategic direction.
Without operational managers and personnel being informed of
and committed to the strategic direction, it is very challenging to
have a successful and effective business operation.
We have already prepared a list of wishes; we do not need to involve strategy.
Many projects start with a predefined wish list of improvements.
Most of these proposals are very operational and actually take the
current processes and settings for granted.
Often the biggest impact and success comes when strategic considerations are included in the analysis. This provides an opportunity to question and challenge some of the stubborn and ignored
tacit assumptions and constraints. Wish lists tend to be very operationally and short-term focused, whilst most organizations are faced
with fundamental changes which have substantial impact at the
strategic level.

What should be included within organization

strategy and process architecture in order to have
the right context for process review and process
improvement?
Sometimes discussions regarding a process review or process improvement
can take an unnecessarily long period of time, as people within the same

Chapter 6

Why are organizational strategy and process architecture important?

27

organization dont always have the same mindset when reviewing the processes because the information is tacit (in peoples heads). After providing everyone with the same context, most process issues can be resolved in a fraction
of the time it would have taken via the traditional method of discussion.
Unless there is a clear structure, all the various issues will be mixed up (e.g.
objectives, strategy, constraints, principles and guidelines). An explicitly formulated context ensures that every new argument can be placed within the
agreed context to determine the impact on the processes.
At a minimum, the issues that should be considered are the objectives of
the organization (the Balanced Score Card is a good method to specify and
measure these objectives), the strategic choice (e.g. customer intimacy, operational excellence or product leadership strategy), the business model (the
relationship with the customers, partners, competitors and the community at
large) and the main guiding principles of the organization (this includes the
values of the organization). In addition, there should also be principles specifically for processes. We refer to all these elements together as process architecture.
Process architecture ensures that all the relevant information, which consists of the foundation and guidelines for the process review and improvement, are made explicit and can be referred to. The impact of any internal
and external change can easily be determined.

Process architecture
Why do people fail to use the process architecture? Our research has shown
that people quote the following reasons:
1

We already have process models. Many people confuse process models

with a fully fledged architecture. We have seen people who proudly
show their elaborate process models, which have been published in
color on a poster. However, they become very quiet when asked
when it was last updated and how it is continually maintained.
Process architecture is much more than a process model; it also
includes the objectives, principles, strategies and guidelines that are
the foundation of the models. A process model is just a snapshot of
the current thinking, and does not provide sufficient guidance for
reviewing existing or creating new processes. In fact, the process the
organization goes through to create a commonly agreed process
architecture is more important than the eventual documented
architecture itself. It is during the process of creation that all the
important decisions are made, and the business gains an understanding and appreciation of the importance of the process architecture.
Creating the process architecture is more effort than the benefits to be derived
from it are worth. If management and the business are, in general,
negative about the need for process architecture, then this usually
indicates that they do not understand the importance of setting
rules and guidelines for process models and process structure. They

28

Business Process Management

may not have been through the workshops and decision-making

process associated with the creation of a process architecture.
A good process architecture will ensure that more time and effort
is saved by its use. It will also provide a means of communicating,
specifying and agreeing the process objectives and principles in a
way that it is clear for everyone. Where process architecture already
exists, it will be much easier to identify the impact of the suggested
changes against the agreed standard.
We have process architecture, but no one is using it. Many architects get
carried away with the creation of the organizations process architecture, making it more elaborate than it needs to be and forgetting
that its success is measured by the level of its use and the benefits it
provides to the organization.
A common mistake made by architects is that when the business
and management are not involved with the creation of the process
architecture, they run the risk of it becoming more complex and
elaborate than it needs to be. The first step is the involvement of all
the relevant stakeholders, if buy-in, agreement and usage are to
occur. The most successful architectures (that is, those actually
being used to support decision-making processes) are relatively
short and simple.
We have agreed on a common process architecture, but no one sticks to it. A
common process architecture has been agreed, and before the ink
has dried there are already all kinds of drivers to deviate from it new
legislation, new products, a customer request and so forth. Initially
the process architecture may be successful in suppressing these
exceptions, but it will not be able to withstand the pressure from the
business and management. The moment the first exception is granted, exceptions will increase at an alarming rate and within no time
the process architecture will become irrelevant. The more projects
deviate, the more the project risk increases.
It must be recognized that there will need to be deviations from
the agreed process architecture sometimes. The process architecture will need to adjust to business requirements and thus it will
need to be dynamic, rather than the static architectures of the past.
Therefore, rather than suppressing exceptions it is better actively to
manage them, ensuring that: there is a valid reason for the deviation, that the deviation is limited (thus remaining within a certain
bandwidth of the agreed process architecture), and that measures
are being taken to bring it eventually into alignment and compliance with the process architecture.