Enterprise BPM

Summary

I’ve been working In the financial sector (banking & insurance) for several years now. Several customers
and projects have passed the revue. An increasing number of regulations (Basel II, Solvency II, Sox,
HIPAA, …) complemented by a growing complexity in the different business domains, has made of
business process modeling a hot topic.

It is remarkable to see how many different viewpoints exist on the topic of business process modeling.
The opinions do not only differ in the objectives of the modeling, but also on the scope, the approach,
methodology, the content of the modeling, the form and notation, … The output of the process varies
from a very general description with many possible interpretations, to something very detailed focusing
on different aspects of the business. Putting all the different things together, it appears a lot of people
have a different notion of what business process modeling is.

The purpose of this article is to give some insights on what business process modeling means at
enterprise level. Despite the fact that many initiatives start with a project based approach in a very
limited part of the business, the investment is much lower and the success rate is higher when you start
a top down approach. This article will provide a definition of enterprise business process modeling, and
its main building blocks. It will elaborate on business process modeling in context of an enterprise, and
in context of other techniques to describe distinct aspects of an enterprise (often referred to as
enterprise business modeling). Furthermore, it will emphase the role of each building block of a process
model, and it’s significance for the enterprise in scope of the modeling process.

The purpose is not to explain how to do things in practice, or who needs to do this work. It will explain
how to build a solid base for modeling meaningful and correct business processes in an enterprise
context. The practical side on how to start the modeling job or who has the responsibility over the
work is kept for a future article.

Before diving into the details of this article, I’d like to thank Tim Daniels, Stef Devos and Jan Wilmaers for
their contribution to this article.

Copyright © 2009 Tim Musschoot

Enterprise BPM (Re)Defined
The first issue you encounter when googling on BPM is the dubious meaning of the abbreviation BPM.
Sometimes it stands for Business Process Modeling, sometimes it is being referred to as Business
Process Management. The master of all dictionaries (Wikipedia) describes Process Management as

“Business process management (BPM) is a field of management focused on aligning

organizations with the wants and needs of clients. It is a holistic management approach[citation
needed] that promotes business effectiveness and efficiency while striving for innovation,
flexibility and integration with technology. Business process management attempts to
continuously improve processes. It could therefore be described as a "process optimization
process".”

So process management needs … processes, otherwise there Is nothing to manage and optimize. This
leads us to the second meaning of BPM : Business Process Modeling, the real scope of this article.

Sadly, anyone who starts to look for more information on business processes en business modeling will
encounter a big list of concepts en notations that are often confusing and contradictory. In order to
fully understand the remainder of this article, it is important to know the meaning of the different
concepts used.

The key player in the domain is without any doubt : the business. Everything starts here. Modeling the
business in its true form is generally considered to be business modeling. What exactly is this true form?
What exactly is business modeling? When we look at the most popular reference nowadays
(Wikipedia), the definition of business modeling redirects us to business process modeling. When we
look a little further to the term ‘business model’, we get a completely different meaning. A business
model is described as

“A business model is a framework for creating economic, social, and/or other forms of value”

In terms of business modeling, in the sense of describing the business model, the following terminology
is used to describe the domain:

“Business modeling is the activity that delivers a broad range of informal and formal
descriptions to represent core aspects of a business, including purpose, offerings, strategy,
infrastructure, organizational structures, trading practices, operational processes and policies”

Looking at the definition of a business modeling, the operational processes appear to be only a part of
the scope. Hence, why is under some definitions business modeling limited to the modeling of the
business processes?

Discarding a potential discussion on the use of terminology, it should be clear that business modeling is
much more than just modeling the (operational) processes of the business. Business modeling is the

Copyright © 2009 Tim Musschoot 2 / 13

process of modeling all relevant aspects of the business. Relevant in this context means the aspect is
involved either in the value‐making of the business (operational aspect), either in the governance of the
business, or either in a supportive domain towards the business.

Business Process Modeling will hence focus on the process part of the business, in relation to the other
aspects of the business that are targeted by business modeling. It is not to be considered a separate
topic that has its own life besides business modeling. It should be considered as an integral aspect of
business modeling, where the focus is on the process aspect of the business, and where the other
information in scope of the whole business modeling can/will be put in context of the process aspect.
The result of BPM will be called a business process model. This is a model of one or more business
processes, that defines the ways in which operations are carried out to accomplish the intended
objectives of an organization. A business process model remains an abstraction and depends on the
intended use of the model. It can either describe the workflow or the integration between business
processes. In practice, business process models contain multiple levels. The deeper you get into the
level hierarchy, the more details of the business process will be visible.

In newer articles and reference work, this notion of business modeling is being called business process
modeling. With the explicit notion not only the behavioral aspect is being modeled, but all aspects.

What do we mean by “Enterprise BPM” then? The first half of the title “Enterprise BPM” relates to the
scope of the business domain. In this case, we focus on the enterprise as a whole. There are in practice
many ways BPM has entered an enterprise. The approach to make the project successful will be
different when the project initiative and scope are limited to a local division of the enterprise, or when
the intake is located at enterprise level. When aiming to achieve a successful BPM implementation at
enterprise level, the best place to start is in fact the enterprise as a whole. An approach where local
initiatives are combined will only result in success if an enterprise wide framework is set up. A
framework where the local initiatives can be hang upon.
In this sense, we consider Enterprise BPM to be the modeling of all processes in the enterprise, as part
of and in context of the total enterprise business model. The modeling is not necessarily the whole
enterprise (at once), but all modeling activities are oriented towards the enterprise as a whole. In
practice, this implies all artifacts (later called building blocks) of the modeling process are directly
related to the enterprise itself, and the processes are considered to be in a clearly identifiable sub
domain of the enterprise as a whole.

In Figure 1 you can find a visual representation of the position of business process modeling in the
context of business modeling (of an enterprise).

The illustration shows you two of the main domains of an enterprise, the business and the IT part. Both
will have several aspects of their domain described and visualized in separate models. The most
important aspects will be described in the next paragraphs, when the building blocks of a business
process are described. The business process model will take a number of artifacts of the domain specific
models as input at different levels, to meaningfully describe the behavioral aspect of the organization.

Copyright © 2009 Tim Musschoot 3 / 13

The illustration is based on the ICOM (Input, Control, Output & Mechanism) principle from IDEF0
(reference [6]).

Figure 1 BPM in scope of business modeling

What’s in business process modeling

Introduction
In the past, several people have asked me if there is a detailed checklist of items that are included in
business process modeling. I do not believe there is one. As stated before it is all about modeling the
relevant aspects of your business processes. Relevance in this case is not a personal opinion, but strictly
depends on the context you’re working in. As discussed before, business process modeling has to be
seen in the global scope of enterprise modeling, focused on the behavioral aspect of the business.
However, one can rarely be limited to the behavioral aspect alone, without looking to the other aspects
of the business (organization, roles, information, …). If you omit the context of the process you are
modeling, you risk losing all significance. The result might be open for ambiguity, and no longer
understood by the business.
However, there is a big difference between omitting the context, and not entering into details on the

Copyright © 2009 Tim Musschoot 4 / 13

context. In fact, the objectives of the modeling assignment will determine what part of the context you
need to model, and in what level of detail.

Some practical examples of different objectives are :

• Aligning different business lines in their way of work (pre‐reorganization phase, company
mergers & acquisitions, …)
• Aligning business with IT
• Requirements modeling
• Business Improvement
• Modeling for Compliance (Sox, HIPAA, Basel II, Solvency II, …)

Bruce Silver has a couple of interesting articles on the levels of business modeling (see reference [1] and
[2]). He talks about 3 levels of business modeling:

• Descriptive modeling : high level, often simplified and easy to communicate models, containing
the fundamental concepts such as pools & lanes, tasks and sequence
• Analytical modeling : detailed modeling containing all tasks and exception paths. Contains all
relevant aspects to the business process.
• Executable modeling : detailed modeling where the model can be executed directly by an
automated system

In brief he explains business modeling as a process that starts with a top level approach. In the first
step, the boundaries are defined. In the next steps the model is annotated with more and more detail.
The amount of detail depends on the level you want to achieve.

Going back to the practical examples I provided, you can separate them in 2 different classes. It is clear
that when you model some high level business processes in order to align different business lines or
when you want to streamline their way of collaboration, you will not need to provide the same amount
of detail as when you are modeling requirements towards an automation system or when you want to
improve business processes. The objectives are entirely different. Modeling to simply describe and
understand the base concepts of how a business operates, is a clear example of descriptive modeling.
Drawing some schemes in order to increase mutual understanding is key here. You are not interested in
the business rules, information flows, or even assuring the way you model things is syntactically
consistent and correct. Characteristics of these models is they have a very limited lifetime, and have a
very limited scope. An example can be found in Figure 2.

Copyright © 2009 Tim Musschoot 5 / 13

 Figure 2 Example of descriptive modeling

Whenever you want to do analytical thinking on how your business works, you need to prove process
correctness, prove data consistency is assured when handled by a process, or you want to introduce key
performance measurement points, it is clear you’ll need a lot more information in order to get any wiser
from the models drawn. The effort you’ll need to put into these models is significantly higher than the
effort you’ll put in descriptive models. As you are putting more effort (hence more budget) in the
modeling process, it is recommended to produce a result that actually fits the purpose. Some examples:

• If you are modeling business processes to do assure the mutual comprehension between
business and IT, it is mandatory to involve both stakeholders in the modeling process. If not,
you’ll put yourself in a very difficult position. You’ll need to explain and justify your work for
both the business and IT. The only way to assure the work done matches reality is to involve
both in the process, and perform continues double‐checking with both parties.
• If you are modeling business processes to be able to measure and optimize the work of the
business (the approach taken by Lean & Six‐Sigma), you need to be sure you model enough
information in a correct and consistent way, allowing you to be able to draw the correct
conclusions. A model that is either incorrect, partial, inconsistent, … will certainly lead you to a
decision that is merely based upon a weak representation of the business, and not of the
operational aspects of the business itself.
• If you are modeling the business in order to put requirements for automated business process
steps in context, you need to be sure the level of quality of your work done fits the minimal
quality criteria of user requirements. Meaning (not exhaustively) : be correct, complete,
unambiguous, consistent, … If not you will certainly miss your objectives. In this case, you will
not only focus on the behavioral aspects, but you need to include all relevant business rules, the
input and output information of each step, … What you omit will simply not be realized.

The main focus of this article is on the contents of analytical business process modeling. Descriptive
modeling will be a simplified version of analytical modeling. Executable modeling will be very much
bound to the technology you are using to execute the process. The focus will be on realization details
next to business details. These latter are currently not to be considered the most important part of
BPM. The notation used to model business processes is in this context considered to be irrelevant.

Copyright © 2009 Tim Musschoot 6 / 13

There are many different ways to model a specific topic. As long as all relevant aspects are modeled in a
consistent way, the notation you use to model is in se irrelevant. It is all about the content.

The foundations
Until now, I focused on defining business process modeling and putting it into the context of an
enterprise. In this paragraph, we’ll take a more closer look at the building blocks of a business process
model.

In order to fully understand the relevance of the building blocks of a business process model, it is
important to start at the business modeling level. As mentioned before, business modeling is all about
modeling the relevant aspects of your business. When talking about the possible aspects, we are talking
about the business organisation, the different processes that make the business work, the information
that allow the business to work, the different information streams throughout the business operations,
the business rule and regulations that control the business operations, the constraints and quality
standards such as KPI’s, the way the business interacts with the outside world, …

There is no standard checklist that tells you exactly what aspects of your business you should model.
However, you don’t need to start from scratch. There are different reference models available that help
you in describing the different parts of an enterprise. One of the best known and most widely used
models is the Zachman Framework (reference [3]). It provides a way to describe the business side of the
enterprise by answering 6 simple questions. These questions allow you to discover what aspects are
important for modeling. The questions are : What? How? Where? Who? When? Why?

The answers to those questions allow you to classify the different aspects of your business into specific
aspects that can be modeled.

The “What?” question will allow you to discover all relevant information for your business.
Common examples are “What is a client?”, “What is an order?”, “What is a product?”, … They
will allow you to model the information part of your business.

The “How?” question will allow you to discover the operational/functional aspect of your
business. This will result in a process model describing the business processes.

The “Where?” question will make you discover the geographical aspects of your business. Doing
business in a small or midsized company where everybody is located in the same building is
fundamentally different then dealing with divisions located in other countries.

The “Who?” question deals with the players in the game. Here you model the different roles in
the organization, and the relation between the roles. The relation can be hierarchical, a chain of
reporting, explicit or implicit, …

Copyright © 2009 Tim Musschoot 7 / 13

 The “When?” question will deal with all timing aspects, events and cycles relevant to the
business. It will give you an answer to questions such as ‘Who’s doing what at what time?’ or
‘What is the trigger to start …’.

The “Why?” question is the most difficult to answer. Its objective is to model the business
drivers and business strategy. It is typically described in a business plan containing both the
business goals and the strategy that will be used to achieve those goals. This topic will be
considered out of scope for the rest of this article.

Modeling an enterprise implies you model all aspects of that enterprise. Modeling business processes
will focus on the ‘How’ aspect of the business, in contexts of the other aspects. The level of detail in
which you model the context will actually depend on the scenario you’re working in. In the case of
analytical business process modeling, not only the activities will be relevant, but also the information
handled by the process, the setup of the organization (the players in term of the geographical aspects),
and not to forget the timing aspect. The ‘Why’ aspect will rarely be modeled by a single proces, but all
processes together will be in function of the business strategy.

The number of scenario’s where a very high/vague level of detail has any added value, will be very
limited. When omitting one or more building blocks from you model, you’ll open the door for
interpretation, misconception and you increase the difficulty for both business and IT stakeholders to
read the models. That’s why in practices, descriptive modeling has a very limited added value.

The building blocks defined are in practice both autonomous and interwoven. They all represent an
isolated view on a particular aspect of your business, but they only have a significance to the business
when they are put together. For example : you can model all information of an insurance contract, and
all business rules applicable in the insurance domain, but the importance of each aspect of each model
is only visible when the whole picture is considered : in what moment in time, in what process, what
business rule applies and what information part is captured.

The “Where” and the “Who” domains are often called the Environment. It places the enterprise your are
modeling in context. Both the internal visible aspects (internal enterprise) as the external visible aspects
(enterprise to world) are being represented here.

Building blocks
1. Environment
One of the fundamental aspects of business modeling, is the way the business is organized. It is one of
the easiest parts of the business to model. Most enterprises have a company map that explains the split
of the company in different business divisions, different roles, and the relation between the roles. This
is the first pillar of the business organization.

The second pillar is the physical organization of the enterprise. It is clear that an organization where
everybody is seated in the same building floor will work entirely different then a geographically spread
company with headquarters in Brussels, sales divisions on all continents, and manufacturing facilities

Copyright © 2009 Tim Musschoot 8 / 13

located in Africa and the middle‐east. This information is crucial and will be used as input for almost all
other building blocks of your model.

Beware that the environment as mentioned here focuses on the internal environment of the enterprise.
It shows the aspects that are visible from outside, but does not represent the aspects of the outside
world (the external environment).

The consolidated information on the business environment is a crucial part for the rest of the business
modeling. As mentioned before, all other aspects of the business will depend on this organization. If
you are modeling a process between 2 different business domains split over 2 continents, this will be
entirely different then modeling a process between two actors in the same business entity. Defining this
model upfront will be crucial for the rest of the modeling approach.

Why is this the easiest part of the modeling? Most businesses know very well how they are organized.
Almost everywhere there is a hierarchy available containing the complete structure of the organization.
Furthermore, information about the different sites the enterprise is located in, will not be hard to
obtain. The organization of the business is something that is rarely open for discussion. Especially when
you start by a top down approach, you can quickly achieve results. The discussion can start once you
enter the level of detail where the lowest level of roles are identified. Often, role definitions are
relatively vague and prone to interpretation. Assigning people to one or more roles is often even more
tricky. However, this last step is not a mandatory requirement for business modeling.

Besides the organization structure, there are other aspects that are considered to be important for the
environment model. Many enterprises have established governance boards or have other informal
channels such as partnerships. As they have an impact on how the enterprise operates, it is relevant to
mention these too.

2. Business processes
The business processes mark the behavioral aspects of the business. They will offer a structured view
on all activities performed by all roles in the business organization. Typically, the different business
processes are organized in a hierarchical structure. The top‐level will present all top‐level business
processes that realize the business value of the enterprise. It is often referred to as the Business Process
Model. The more you go down in the structure, the more you enter into the details of the process. At
the lowest levels you find the different activities that are performed in terms of the process.

The processes can either be value‐creating (the so‐called value chains, see [4]), or supportive. Both are
business processes that are significant for the operating of the business.

Business processes are not to be seen as independent of the other building blocks, the most important
blocks of a business process are:

• Roles and organizational information

• Activities & tasks, assigned to roles
• Task sequencing (Control flow)

Copyright © 2009 Tim Musschoot 9 / 13

 • Information and information flow
• Rules and constraints

As mentioned in the description, the existence of a business organisation model is a prerequisite to be

able to model business processes. Processes will, by nature, assign a specific task to a specific role.
Hence it requires the existence of a role. Processes will be organized by using pools and swimlanes.
This organization will be based upon the business organization itself. If you make the roles abstract and
unconnected from the business, you’ll make it impossible for business users to read the processes you
model.

The knowledge of the different business domains in the organization model, and the information
captured in the location model (geographical spread) will allow you to model exactly what is control
flow and what is data flow.

3. Business information
Nowadays, almost everything is about information. Whether your business is a financial institution
where you have clients with bank accounts or insurance policies, or you are in the manufacturing
business where you assemble different types of cars composed of different parts, or in the distribution
business where clients put orders that are composed of goods that need to be manufactured in different
steps using different parts acquainted in resellers all over the world… It makes absolutely no sense to
talk about a client placing an order, when you do not describe the characteristics of the client and the
characteristics of the order.

Modeling information in terms of a process is essential to know how information is handled by that
process. For every step in the process, you need to able to know what information is
considered/required present at input, and what information Is produced at the output. It allows you to
remain consistent and complete in the definition of your process. The sequence of two steps in a
process model is consistent when the input data of the successor can be directly linked to the output
information of the previous steps.

Information is not necessarily modeled in terms of the processes only. In many financial institutions, a
(partial) enterprise information model is present. The processes will deal with part of the information of
this enterprise wide model.

4. Business rules, constraints & quality standards

Business rules are generally described as statements that aims to influence or guide behavior and
information in an organization. They are to be considered as the rules of engagement of the business
you are modeling. They contain all aspects that make the business unique. I’ve never encountered 2
organizations or business domains having exactly the same business rules.

Business rules apply either to the process part of the business in scope of the modeling process, or to
the information/data part of business. They can apply on the ensemble of business processes or data
(often called invariants), to a specific step in a business process or specific information part treated by a
dedicated process.

Copyright © 2009 Tim Musschoot 10 / 13

Examples of business rules are:

• Invariant : a customer must be minimum 18 years of age

• Process specific : in order to be able to purchase a specific product, the customer must be above
21 years old
• Information bound : the tree fuel types for a car are petrol, diesel and LPG

Business rules are essential to business modeling. They describe the essence of the different activities,
processes and information illustrated by the model.

In some cases just modeling the information, the flow and the business rules will not be sufficient.
Sometimes it is as important to model the business dedicated aspects alone. For example : how can you
model the fact a general legislation, not bound to your business domain, enforces you to follow a
specific procedure. A practical example : sending a letter by registered post. If you work in a wholesale
department and you need to send invoices to your customers on the other side of the world, you need
to respect a minimum period after the invoice is sent and before you can sent a reminder. This is not
necessarily related to your business rules, but to the fact it might take some time to deliver the message
by mail. These kind of specificities are considered to be constraints. They do not related directly to the
functionality offered, but have a certain impact on the way that functionality is offered.

Another example is the quality of the services you offer. If you have a specific SLA that is enforced in a
contract with your customers, you need to model this somewhere in the description of your business.
Not only will you be required to model this, you’ll also need some kind of contingency procedures to
mitigate the risk of not being compliant to this SLA. The SLA itself is an example of a quality attribute. It
can apply to a whole process, or to a part of it. It can also apply to information (example : retention
policies, data quality control measures, …). The quality of the service you are modeling will be key to
perform process performance measurement and business process improvement.

When looking at the requirements engineering domain, all non‐functional requirements are to be
considered as constraints and/or quality standards. However, I will not handle this topic here in detail.

Putting it all together

In Figure 3 you can find the relation between the building blocks of a business process model. The same
context illustration is used as before. It should be clear that the term ‘building block’ is considered to be
very strict. Meaning : you cannot have a correct business process model if you omit one of the blocks.
The information that is present in one of the blocks is one thing. However, the most important aspect is
the information that is in all blocks together. You can compare this to modeling a house. You can have
a view with the walls, and a view with the different windows. However, only the combination of both
will give you an idea about what you exactly mean. For business modeling the same logic applies. The
consistency of all aspects in all building blocks is what really defines the business model. It is all about
business processes transforming inputs into outputs, applying specific business rules and constraints
during the transformation process, to realize the strategic goal of the business as an organization.

Copyright © 2009 Tim Musschoot 11 / 13

 Figure 3 Business Modeling Building Blocks

Sometimes the question arises on how to assure consistency of the model. There is no simple rule to
define consistency. Neither is there a checklist you can run over you model to know it is consistent.
There are some simple guidelines that allow you to detect inconsistency, but the best way to find out is
by setting up a peer review. Let someone else explain to you the model (s)he made. If the explanation
matches your original attempt, you know you’ve done a good job. It is rarely a good idea to judge
and/or review your own work. Detecting inconsistency can be done by matching the different building
blocks in the model. For every step in the process, check what the available input information is, and
what the produced output is. The action of the step, in combination with the business rules and
constraints that apply to the step, should transform the input to the output. This simple procedure can
be considered as a first sanity check on the performed work, but does not assure correctness of the
work performed. A peer review by people who know the context has a serious added value in this case.

References

[1]. BPMS Watch : BPMN’s Three Levels (Bruce Silver, BPMInstitute.org, May 8th, 2008)

Copyright © 2009 Tim Musschoot 12 / 13

 [2]. BPMS Watch : BPMN’s Three Levels, Reconsidered (Bruce Silver, BPMInstitute.org, December
2nd, 2008)
[3]. Zachman Framework, John Zachman (http://www.zachmaninternational.com/)
[4]. Michael Porter, Value Chain Analysis (http://en.wikipedia.org/wiki/Value_chain )
[5]. Business Process and Business Rule Modeling: A Representational Analysis (Michael zur
Muehlen, Marta Indulska, Gerrit Kamp)
[6]. IDEF0 : http://www.idef.com/idef0.html

About the author

Tim Musschoot is a Senior Enterprise Architecture Consultant. He has almost 10 years of experience in
the financial sector. Starting his career in IT as Software Engineer he now works in the domains of
Enterprise Architecture, Project Management and IT Governance. He is currently working at inno.com, a
center of expertise specialized in complex and innovative projects, where significant company and
technology change is envisaged. He is contributing to the Business Architecture service offering where
inno.com helps customers defining and realizing their corporate strategy. Here, he is using BPM not
only for the modeling and management of business processes at business side, but at enterprise wide
level assisting both business and IT in their joint effort realizing the company strategy and objectives,
over their own boundaries

Copyright © 2009 Tim Musschoot 13 / 13