Alignment Architecture

Business Process Management

Version 1.3
 Versions
Version Date Modified By Modifications

1.0 01/02/2014 Peter De Kinder Initial Version

1.1 21/05/2014 Peter De Kinder Overhaul of chaptering + appendix elaboration
1.2 10/03/2015 Peter De Kinder Added process management diagram + OODA
1.3 29/12/2015 Peter De Kinder Elaborated Refinement Techniques

References
Document Date Description

OMG-BPMN Jan 2011 OMG Business Process Modeling Notation (BPMN) v2.0
OMG-BPMM June 2008 OMG Business Process Maturity Model (BPMM) v1.0
OMG-BMM Nov 2008 OMG Business Motivation Model (BMM) v1.1
O-BMM Sep 2010 Oracle Practitioner Guide – Creating a BPM Roadmap v3.0
O-BPE Dec 2010 Oracle Practitioner Guide – Business Process Engineering v3.0
O-GOV April 2011 Oracle Practitioner Guide – A Framework for BPM Governance v3.0
O-FND Sep 2010 Oracle Practitioner Guide – BPM Foundation v3.0
BS-BPMN Oct 2011 BPMN Method & Style 2nd Edition (Bruce Silver)
PH-BPC July 2007 Business Process Change 2nd Edition (Paul Harmon)
MMJS-ABFT Sep 2002 Agile Business for Fragile Times (Mary Pat McCarthy & Jeff Stein)
WCKRM-BOS Aug 2005 Blue Ocean Strategy (W. Chan Kim & Renée Mauborgne)
WFMC-PSB Sep 2014 Passports to Success in BPM (WFMC)

Prerequisites
Document Description

CM-ARCH Solution Architecture – Framework and Methodology

Alignment Architecture - Business Process Management  2/55

 Table of Contents
1 Introduction ........................................................................................................................................... 4
1.1 BPM as a Project ........................................................................................................................... 4
1.2 BPM as a Discipline ...................................................................................................................... 4
1.3 BPM in an Organization................................................................................................................. 5
1.3.1 BPM and Business Strategy ................................................................................................... 5
1.3.2 BPM and Enterprise Architecture ........................................................................................... 6
2 Purpose ................................................................................................................................................ 8
2.1 Requirements ................................................................................................................................ 8
2.2 Hurdles .......................................................................................................................................... 9
2.3 Constraints .................................................................................................................................. 10
3 Philosophy .......................................................................................................................................... 11
3.1 Business Concepts ...................................................................................................................... 11
3.1.1 Definition .............................................................................................................................. 11
3.1.2 BPM Levels .......................................................................................................................... 11
3.1.3 Process Lifecycle ................................................................................................................. 12
3.1.4 Knowledge Workers ............................................................................................................. 13
3.2 Best Practices ............................................................................................................................. 13
3.3 Pitfalls .......................................................................................................................................... 14
4 Tools and Techniques ........................................................................................................................ 16
4.1 Analysis Techniques ................................................................................................................... 16
4.1.1 Enterprise Scope .................................................................................................................. 16
4.1.2 Program Scope .................................................................................................................... 20
4.1.2.1 BPM Roadmap .............................................................................................................. 20
4.1.2.2 Capability Development ................................................................................................ 21
4.1.2.3 Process Refinement Strategies ..................................................................................... 22
4.1.3 Project Scope ....................................................................................................................... 23
4.1.3.1 Process Discovery ........................................................................................................ 23
4.1.3.2 Process Selection ......................................................................................................... 24
4.1.3.3 Process Design ............................................................................................................. 26
4.1.3.4 Process Testing ............................................................................................................ 26
4.1.3.5 Process Monitoring ....................................................................................................... 26
4.1.3.6 Process Refinement ...................................................................................................... 27
4.1.3.7 Process Security Analysis ............................................................................................. 29
4.1.4 Additional Considerations..................................................................................................... 30
4.1.4.1 Social BPM ................................................................................................................... 30
4.1.4.2 Business Analytics ........................................................................................................ 30
4.1.4.3 Business Process Outsourcing ..................................................................................... 32
4.2 Technical Concepts ..................................................................................................................... 33
4.2.1 Modeling and Simulation Tools ............................................................................................ 33
4.2.2 Process Analytics ................................................................................................................. 33
4.2.3 Business Activity Monitoring ................................................................................................. 34
4.2.4 Operations and Administration ............................................................................................. 35
4.2.5 Collaborations Component ................................................................................................... 35
4.3 BPM Suites.................................................................................................................................. 35
4.3.1 Developer versus Designer .................................................................................................. 35
4.3.2 Key Functionalities ............................................................................................................... 36
4.3.3 Advantages .......................................................................................................................... 37
5 Synergies ........................................................................................................................................... 38
5.1 Service Oriented Architecture...................................................................................................... 38
5.2 Enterprise Application Integration ................................................................................................ 38
5.3 Adaptive Case Management ....................................................................................................... 38
5.4 Business Decision Management ................................................................................................. 38
5.5 Enterprise Information Management ........................................................................................... 39
Appendix: BPM Maturity Model ................................................................................................................. 40
Appendix: Business Motivation Model ....................................................................................................... 43
Appendix: Process Classification Models .................................................................................................. 45
Appendix: Business Process Refinement Techniques ............................................................................... 49

Alignment Architecture - Business Process Management  3/55

 1 Introduction

1.1 BPM as a Project

Projects are driven by requirements, and thus so are the choices made surrounding architectures in those projects.
To categorize architectures we devise three different groups as shown in the illustration.

Illustration 1.1.1 – Architectural Categories

We position BPM Architectures in the Alignment Architecture Category, where we place those architectures that are
not only driven by a strong technological current, but by a business current as well. In this case the solution will not
only be strongly constrained in requirements by its technological components (more specifically the BPMS), but also
by the business processes defined.

1.2 BPM as a Discipline

Where up till World War II, when we speak of Business Process Management, it was all about work simplification,
we nowadays usually divide this effort into three streams of thinking. The Business Management stream where we
concern ourselves with the strategy of the enterprise and the structure of the industry it is situated in. Quality Control
is the school of thought where we focus on improving business processes, and finally information technology where
we try to automate these processes. Naturally BPMS components have the most allegiance with the third stream.

Illustration 1.2.1 – Business Process Management Evolution (Paul Harmon)

Alignment Architecture - Business Process Management  4/55

 The book “Business Process Management – The Third Wave” by Howard Smith and Peter Fingar characterizes this
evolution as the following three waves:
 The first wave (early part of the 20th century) focused on gaining higher efficiency in the day-to-day
operations of businesses with the introduction of Taylorism (or the scientific management theory), where
processes were present in spirit through work practices.
 The second wave focused on the adoption of packaged enterprise applications (ERP, SCM, CRM…) and
the utilization of business processes embedded in these applications. Processes are manually engineered,
and through one-time development activity practically cast in stone.
 The third wave focused on current efforts to recognize BPM as a holistic endeavor that a business
engages in to gain efficiency and agility in its operations while creating sustainable competitive advantage.
The ability to change processes becomes predominant over the ability to create them in the first place.
The reason for the emergence of this third wave and the most current incarnation of business processing, comes
from the limitations of the previous wave to adapt to the particularities of the enterprise in which it was rolled out, as
some of these systems are so complex that modifying them costs a large amount of expertise, time and money.
This adaptation is usually done by writing scripts or one-off coded extensions to these packages, of which studies
would indicate they take up as much as 20% of the initial investment, and in some cases prevent timely upgrades,
preventing the users from the benefits of progressive releases of these packages. They also lacked the element of
collaboration within the firm itself, as well as with other firms.
They also suffer from a lack of visibility over the entire process, which is mostly scattered over these systems. Not
only is there no mapping on which parts of the process are addressed by which tools, but there is also no support
for determining the gaps in the automation (and thus the monitoring) of the process. Once this overall coherence is
visible, the integration of said solutions also becomes a lot less difficult.
The success of rolling out a BPM approach within an organization depends in large part on how well the
organization can make process improvement part of the DNA of the organization, and their willingness to engage
fully in an iterative approach for BPM. A transition to a process-managed enterprise is complete when it exhibits the
following attributes:
 Process improvement is embedded in the business strategy
 Competitive advantage is supported throughout the value chain
 IT practices process-driven budgeting and resource allocation
 Key processes flow seamlessly through the value chain or key processes

1.3 BPM in an Organization

1.3.1 BPM and Business Strategy
Brett Champlin, president1 of the Association of BPM Professionals states that BPM is only one component of
business modeling, and that there are other areas of which extensive knowledge is needed to properly describe,
analyze, transform, and optimize a company’s business processes. The following information is of equal importance
and is not included in an enterprise BPM program:
 Enterprise or Line of Business Information
o High-level business context, describing the business’s relationship to Competitors, Regulators,
Suppliers, Business Partners, Customers, Community, …
o Strategic Objectives and Performance Metrics
o Controls and Constraints
o Markets and Consumers
o Products (goods and services)
o Locations
 Operational, Cross-Process Information
o Value Chains and Process Portfolios
o Operational Goals and Objectives
o Policies
o Performance Metrics and KPIs
o Organizational Structure and Roles
 Process-specific Information

1
At the time of this writing!

Alignment Architecture - Business Process Management  5/55

 o Activity Resource Requirements
o Revenue and costs, both activity-based and resource-based
o Job Aids (instructions for human performers)
 Technical Information
o IT Systems
o Services
o Data
Typically, all these information fields have describing models of their own, which in some way or another relate to
the Business Process Models (usually described by an Enterprise Architecture), or in the Business Strategy (as
described by the “Business Strategy - Analysis” document). Those that have been stricken through, are the topics
the writer of this document and Brett Champlin disagree on.

1.3.2 BPM and Enterprise Architecture

In enterprises, it is not uncommon for several architectures to coexist at any given time. Some of those address very
specific needs, while others are more general in nature. Enterprise Architecture (EA), or more specific TOGAF,
tackles this by using Architecture Partitioning. TOGAF stipulates the needs for this with following point:
 Addressing all problems within a single architecture is too complex
 Different architectures might conflict with one another
 Different (human) resources need to be leveraged for different elements of architecture at the same time,
and partitions allow for specific groups of architects to own and develop specific segments
 Effective architecture reuse requires modular architecture segments that can be taken and incorporated
into a broader solution

Illustration 1.2.1 – Architecture Content Aggregation (TOGAF)

A point of concern is that this partitioning strategy incurs the risk of producing a fragmented and disjointed collection
of architectures that cannot be integrated to form a coherent picture. For this to be mitigated, TOGAF proposes a
content framework (see illustration 1.2.1). Architectures are segmented, based on debt of detail, organizational
scope and architecture domains. The positioning of a BPM architecture in this segmentation is spanned over all
architectural domains. Its depth of detail is however situated on the lower two segments. The organizational scope
of the architecture is of course dependent on the adoption level of the architecture, and can range from enterprise-
wide to processes within an individual business unit.

Alignment Architecture - Business Process Management  6/55

 EA and BPM are very synergistic and highly complementary. Where EA will deliver value to the BPM effort by
identifying those processes in the value chain which offer the highest benefit to the business goals, BPM will deliver
value to the EA effort by operationalizing the future-state vision established by EA. And through this
operationalization, BPM creates detailed current- and future-state business models that enrich the EA models,
supporting other EA efforts such as information architecture and application portfolio rationalization.

Illustration 1.2.2 – BPM in a Project Cycle

In summary, the different branches of BPM will come into action during the cycle of implementation and governance
of a project where it is the preferred architectural choice (dependent on the requirements), and the BPM analysis
techniques can be viewed in such a cycle as shown on the illustration 1.2.2.

Alignment Architecture - Business Process Management  7/55

 2 Purpose

2.1 Requirements
For an organization to be successful, it needs to realize a simple truth, paraphrased from the well-known adage by
Heraclitus of Ephesus: It is in a constant state of change. And this state has a dual nature. The changes take place,
driven by internal as well as external influences.
As the internal workings of organizations evolve, so must the technologies that support them. Several factors are
now occurring simultaneously that inhibit the ability of prior technological solutions to support this constant
environment of change:
 Increasing Business Complexity: Organizational layers, products, and services grow and change in scope
and complexity.
 Increasing Number of Regulations and Compliance Requirements: New compliance issues emerge in
response to internal and external business standards and regulations.
 Increasing IT Complexity: Layers of disparate (and often siloed) information technology (IT) systems inhibit
broad-spectrum performance visibility and overall productivity.
 Increasing Data Complexity: Changing data and workflow inputs and the use of mobile devices and other
social technologies in the workplace increase the strain on IT departments’ ability to support organizations.
 Increasing Talent Pool Dynamics: The employees of a company are more than ever in flux with competition
and an aging workforce
Not only will organizations change from the reasons listed above, they also have to react to the reality of the market
they are operating in. We calls these external influences. Typically, in economically bad times, a company will seek
to make their processes more efficient and focus on reduced costs, where in economically good times, they will
improve their processes to offer better products and services in order to expand their customer base. According to
Treacy and Wiersema, the three value propositions are:
 Product Leadership: These companies focus on innovation and performance leadership. They strive to turn
new technologies into breakthrough products and focus on product lifecycle management.
 Customer Intimacy: These companies focus on specialized, personal service. They strive to become
partners with their customers. They focus on customer relationship management.
 Operational Excellence: These companies focus on having efficient operations in order to deliver the
lowest-priced product or service to their customers. They focus on their supply chain and distribution
systems in order to reduce the costs of their products or services.

Illustration 2.1.1 – Company Positioning Strategies

Alignment Architecture - Business Process Management  8/55

 BPM will attempt to alleviate these concerns by enabling an organization to possess the capabilities attributed to
business agility, as described by McCarthy and Stein2.
 Maintaining a continual focus on profitability and revenue growth
 Understanding central priorities and the importance of assessing and reporting on value
 A sustained commitment to communications that starts at the top
 Acquiring and filtering pertinent information from and to key constituents, rapidly
 Testing assumptions and frequently measuring results
 Having a performance culture
 Enabling shared decision making
 Adapting rapidly to change
As this is no trivial amount of work, the entire organization needs to shoulder this task. The BPM philosophy relies
heavily on and therefore will promote Business-ICT-Alignment. The important word here is "alignment". It is not just
about IT! It is not just about business! It is about working together - one of the major challenges of any BPM project.
Make no mistake, the introduction of a BPM architecture will change the way an organization functions. It will also
require a cultural changes as following needs will arise as well:
 Business user will need to be trained and incentivized to participate in modeling (becoming knowledge
workers)
 Business management needs to be committed to their team’s participation
 IT needs to accept the knowledge workers as modelers
 The organization will need to accept Process-Driven Agile development projects
This will result in a host of benefits, needed for an organization to remain competitive in its chosen market segment,
or as McCarthy and Stein dubbed it “a survivability edge that allows organizations to observe, react and factor
market changes into an embedded discipline of continual cost and growth refinement”:
 Increased efficiency (productivity improvements)
 Higher transparency and distributed workload
 Better quality and reduced opportunities for error rekeying
 Reduced costs
 Reduced turnaround times
 Enabling new business models
 Increase business involvement and responsibility
 Emergency preparedness and disaster recovery responsiveness
 Reduced time-to-market by decreasing development/deployment times
 Removal of dependency on key individuals
 Increased responsiveness to changing regulatory requirements
 Social Media Collaboration (or Social BPM). Rebranded by Gartner to “Design By Doing”

2.2 Hurdles
As with the introduction of any new concept within an enterprise, there will typically be a number of hurdles to
overcome when introducing an architecture that will impact the enterprise as a whole (enterprise-wide adoption
level). These hurdles can be divided into the following categories:
 Management hurdles: we need a positive management buy-in and a clear mandate for the intended
changes. We also need management to identify which processes align best with the business strategy.
 Organization Adoption hurdles: Some of the biggest challenges are to align staff to the new/changed
processes and customer requirements by ensuring there is sufficient internal education and
communication. Especially when the staff is part of different departments, it is imperative that they begin to
see that they are working in a company-wide process, and not competing against each other.
 Technology hurdles: The technology should support a large number of (if not all) requirements put forth by
the different stakeholders. In the case of BPM, this means sustaining a portfolio of business processes,
and making them work together seamlessly. This also includes the integration of existing systems into
these processes in a seamless manner.

2
“Agile Business for Fragile Times” by Mary Pat McCarthy & Jeff Stein (McGraw-Hill 2002)

Alignment Architecture - Business Process Management  9/55

 Except for the typical hurdles associated with such endeavors, there is also a human component to this approach,
which translates into the following pain points adopters will raise:
 It is something extra to do
 You have to take time out to really understand where everyone fits in
 You have to measure things you don’t normally measure
 You have to talk to and work with people that sit in the team beside you
 You identify weaknesses in your current methods
 You may have no idea who the customer is or what they think
 Managers are scared of the unknown
 It threatens power bases and hierarchical structures
 It drives changes… which many people feel uncomfortable with
We can summarize these pain points into the following topics: resistance to change and unsurmountable effort
anxiety. Each of these should be addressed with a proper change management strategy.

2.3 Constraints
One of the possible technical constraints is the level to which the chosen BPMS implements the BPMN2 standard. It
should be obvious that symbols not supported in the automation tool should be avoided in describing business
processes that are going to be automated. There is however a certain duality in this. One could also argue that the
choice of the BPMS is dependent on which symbols have been used in the business process description of the
business architecture.

Alignment Architecture - Business Process Management  10/55

 3 Philosophy

3.1 Business Concepts

3.1.1 Definition
Although no universal definition of the business process exists, and a wide range of these are postulated from
Adam Smith (The Invisible Hand) to Michael Porter (Five Forces Analysis) to Henry J. Johansson (Business
Process Reengineering), a set of characteristics can be distilled from this amalgam of statements:
1. Definability: It must have clearly defined boundaries, input and output.
2. Large and Complex: involving the end-to-end flow of materials, information and business commitments.
3. Cross-functionality: A process regularly can, but not necessarily must, span several functions.
4. Order: It must consist of activities that are ordered according to their position in time and space.
5. Dynamic: Constantly changing in response to customer demands and changing market conditions.
6. Customer-Oriented: There must be a recipient of the process' outcome, a customer.
7. Value-adding: The transformation taking place within the process must add value to the recipient, either
upstream or downstream.
8. Embeddedness: A process cannot exist in itself, it must be embedded in an organizational structure.
9. Dual natured: processes are both business and technical in nature.
The compromise to the definition of the Business Process Management Discipline has been attempted in 2015, and
specialists around the globe coined the following definition:
Business process management is a discipline involving any combination of modeling, automation,
execution, control, measurement and optimization of business activity flows, in support of enterprise
goals, spanning systems, employees, customers and partners within and beyond the enterprise
boundaries.

To me, this definition feels a bit too much as a compromise of sorts. This definition tries cramming every bit of
insight about the discipline into a single unified theory, and ends up being too broad and generic for my tastes. If I
want to use this theory to verify whether any activity in a transformational project (for example an IT development
project) is part of this discipline, I feel the answer would always be “yes”. The scope of the discipline has become
almost all encompassing with this definition.

3.1.2 BPM Levels

According to Bruce Silver3, BPM in the real world can be classified into 3 levels, based on how the model is used:
1. Descriptive modeling, the kind most BPM consultants typically talk about -- high-level, occasionally ignoring
BPMN's diagram validation rules, but easy to communicate across the organization, linked with a methodology
for how to do it. Level 1 modeling requires understanding of fundamental concepts such as pools and lanes,
tasks and sub-processes, and sequence flow, but not the complexities of BPMN's various flow control and
event patterns. Its goal is to simply document the process flows in an enterprise.
2. Analytical modeling, more detailed, showing all the steps, including the exception paths, required either to
analyze process performance using simulation or to create detailed requirements for an IT implementation.
Although Level 2 modeling requires disciplined thinking and attention to detail as well as an understanding of
BPMN's various decision and merge patterns, events, and exception handling patterns, it reflects a business-
oriented perspective and must thus be understandable by business users, and not just IT. Level 2 diagrams
must be both valid according to the rules in the BPMN spec, and organized effectively as hierarchical
representations of the end to end business process.
3. Executable modeling, where BPMN is part of the executable process implementation. While this capability of
BPMN is a major reason for its widespread adoption, modeling at this level is somewhat vendor tool-
dependent, as most BPM Suites do not support all of the gateway and event types defined in the BPMN spec,
and may offer their own proprietary extensions as well. Moreover, most tools ignore the BPMN spec's
implementation attributes, and instead provide equivalent implementation detail in tool-specific attributes of the
model's activities, gateways, and events. Its purpose is to enrich the Level 2 model with technical

3
BPMN Method & Style 2nd Edition – Bruce Silver

Alignment Architecture - Business Process Management  11/55

 specifications. Level 3 diagrams thus typically impose additional validation constraints beyond those of the
BPMN spec.

3.1.3 Process Lifecycle

Any process from the moment it is selected as a viable candidate for a BPM project, undergoes a number of states
positioned on the process Lifecycle (as seen on the illustration). These states are:
 Identified - The process has been selected for modeling and automated process management.
 Defined/Refined - The business aspects of the model have been captured, modeled, and refined to a
sufficient level to support this iteration of process optimization. On the first iteration through this cycle the
identified process selected for automation undergo process discovery and definition; on subsequent
iterations the process, having been already defined, is merely refined. (descriptive modeling)
 Outsourced – The process has been deemed opportune to be outsourced to a third party. This is followed
by a periodic assessment of whether or not to continue with the outsourcing or to consider the process for
refinement again.
 Designed - The technical aspects of the process model have been addressed including integrations,
message handling, interface specification, exception handling, security, transactions, etc. (analytical
modeling)
 Composed - All external integrations, message wiring, and security roles have been configured.
(executable modeling)
 Tested - Any software engineering needed to support the process has completed and has been tested
along with the process.
 Deployed - The executable process model, and all external dependencies, have been deployed into a
production environment.
 Approved - Final QA approval. All testing and user acceptance has completed. The model has been
commissioned and BPM system manages execution of the business process.
 Monitored - Process metrics being are collected and provide actionable business intelligence.
 Disposed – The process no longer has a purpose and all allocated assets are repurposed.

Illustration 3.1.3.1 – Process Lifecycle

Alignment Architecture - Business Process Management  12/55

 3.1.4 Knowledge Workers

Illustration 3.1.4.1 – Overview of Employee Interactions

People are at the heart of any meaningful process, be they customers or employees. The employees are
categorized by the level of involvement they have with the process, from simply performing the tasks within the
process to redesigning existing or creating new processes. They are also indicative of the level of empowerment
their job brings them (ranging from low to high on the illustration).

3.2 Best Practices

The idea to use a proven approach to BPM projects is to promote predictability, so that the results and costs of such
an undertaking can be determined in advance with a high degree of certainty. The clue here is to stick with the
recognized standards. Try to deviate from them as little as is needed for your project. It will also add to the
traceability to have the same governance approach. This way the impact analysis of changes is reduced in
complexity.
A BPM Architecture does not come from one set of stakeholders, but is rather a concert of many different roles. As
indicated in previous chapters, it serves to divide the workload and accountability across both IT and business
people. This comes from the need for a clear definition of duties. The importance of stakeholder analysis in these
types of projects cannot be understated. The illustration below shows a number of different roles we can include in
the analysis. Be sure to strive for an early participation of as much of the stakeholders as possible.

Illustration 3.2.1 – BPM Stakeholders (Oracle)

Alignment Architecture - Business Process Management  13/55

 Several other best practices are listed here:
 Work out your exit plan. This should be a component/process failure prevention strategy
 Have a watchful eye on the funding mechanisms in place, which can be leveraged to guide the evolution
of a BPM initiative
 Develop process manuals and trainings for internal use within the enterprise
 It is very important to have an accurate view on user expectations
 Make the assessment of the current state and the process selection a tightly time-boxed operation to
ensure timely completion of this phase
 Perform a timely evaluation of the IT assets available to the project, as it might impose limits and
constraints on the process analysis.
 Retool your processes for a balance between operational efficiency and organizational effectiveness. A
heavy concentration on lowering operational costs can hamper creativity and innovation. Alternatively,
constant innovation can create instability and adversely affect business operations.
A good way of starting a BPM initiative is Nathanial Palmer’s 90 day plan to getting started with BPM in an
organization. The first 30 days will be needed to define a starting point by defining the core goals, deliverables, and
assets in collaboration with the stakeholders to determine the scope and boundaries of the plan. This will also give
an indication of whether you will “go live” after 90 days, or will simply deliver some proofs of concept. The next 30
days will be spent devising the narrative of the processes, their look and feel, through a series of workshops. The
final 30 days will come with the task of defining the measuring points of the newly formulated processes in order to
secure buy in from senior management to extend the exercise to more processes.

3.3 Pitfalls
Sandy Kemsley4 has defined four myths of BPM projects, which are true in most organizations:
1. Business users WILL create executable process models
2. Business users/analysts CAN create executable process models
3. Business users/analysts WANT to create executable process models
4. IT WANTS business analysts to create executable process models
There will always be business guys and IT guys, and they have a different understanding of things. Business guys
will never be able to model complex business processes. Therefore, Business-IT-Alignment is very important, and
tooling cannot solve this problem. Business and IT have to work together to do BPM successfully.
The first statement we will call the Volition Myth. Vendors will try to create the “Field of Dreams” mentality of “If you
build it, they will come.” Meaning that if you provide your business users with the capability of creating and
maintaining their business processes, they will do so. The reality is that these people have more than enough work
without having to worry about this as well. They simply lack the time to put in the effort.
The second statement (called the Capability Myth) is what is generally presented by BPM solution vendors as the
“zero-coding” advantage, this is that business people will be able to change their applications without intervention of
the IT team, therefore cutting expenses and reducing the time-to-market. While this might theoretically be possible if
business processes are relatively simple and consist of only user tasks, the reality is that most BPM
implementations are still complex, and thus development projects, with all the requirements and best practices a
full-blown software development project entails. Not only do your business users need the analytical skills to
determine pain points in the process model, they need the modeling skills to properly translate their solution into the
model as well. Even in the case that this were true, they still don’t have an overview of the end-to-end process.
Consider for example that a web service is called in the process. Even if the tool easily allows the wiring of this web
service into the model, a business user still has no idea of the intricacies of the underlying infrastructure. They might
not realize the cost of calling such a service (towards performance of the system or even actual monetary cost in
the case of a subscription-based web service).
The third statement is known as the Desire Myth. In most companies, there is a long standing tradition of systems
functioning correctly being the sole responsibility of the IT department. As we have mentioned earlier in this
document, one of the goals of BPM architectures is that a joint accountability is created for the workings of such a
system between business users and IT. Most business users are not that keen on taking on this increased level of
responsibility.
The last statement is the Desire Redux Myth. The previous 3 myths address the qualms of the business users, but
there are also qualms in the IT department camp. As mentioned in previous myths, business users need a lot of

4
The Four Myths of BPM Projects: What IT Project Teams Need to Know (January 18th 2011)

Alignment Architecture - Business Process Management  14/55

 knowledge to be able to work well with process modeling, and most IT departments regard business users as being
unable to model even the logical view of a process. And in most cases, they are right. Mostly, process modelers are
business users that have been promoted into the job without any formal training. Process modeling isn’t something
you can grow into. You need the necessary knowledge. However, once you have mastered the modeling and
analytical skills, there is no reason why business users cannot become valued members of the process modeling
team.
The four myths are pitfalls that occur when trying to introduce BPM into an organization. However, once this
decision has been made, several pitfalls will crystalize during the rollout of the new architecture:
 Calculated ROI is usually incorrect for the first implementation...
 The additional effort required to refine a defined process is typically underestimated.
 The fixed-scope project management model (as defined by the Project Management Institute), has
repeatedly been shown to be too rigid to provide the flexibility demanded by a BPM project.
 Analysis Paralysis can occur when given too much time.
Where Sandy Kemsley focused on the misconceptions during the Business Process Modeling, Gartner on the other
hand lists their five pitfalls, based on the reasons why one should roll out a Business Process Modeling effort
throughout his enterprise.
Pitfall No. 1: Being Caught Unprepared to Demonstrate Value Delivered
With this pitfall, the BPM team may well have delivered some value to the organization, but if it did, it failed to keep
a record of these achievements, or to routinely communicate them to those that matter. All BPM projects should
start with an understanding of how success (outcomes) will be measured. It is vital to understand what the team is
trying to improve (with a baseline measurement) and the corresponding improvement (metric). This metric must be
communicated to the business, to clearly articulate the benefits delivered. The key is to learn the language of the
organization and to use that language to communicate success.
Pitfall No. 2: Deploying a BPMS without Understanding BPM as a Discipline
Deploying a cutting-edge business process management suite (BPMS) will solve nothing unless the organization
also applies BPM as a discipline. BPM is not about technology. Because it fundamentally changes how people
work, BPM is about change. The problem with relying solely on input from one subject matter expert, or group of
managers, is that the process documented will reflect only what the expert or managers "think it should be." This
"offline" analysis misses one of the greatest opportunities for improvement: mapping the real process. Also, very
few enterprises seem to build a business case around measurements before an implementation. The discipline of
BPM is heavily based on the idea that you can’t improve what you can’t measure.
Pitfall No. 3: Launching a BPM Effort Based on Perceived Problems, Without Validating the Facts
BPM activities must be based on facts and data, rather than reactions to those who shout the loudest. When
starting a BPM initiative, it is good practice to allot a period of time to set up and gather metrics before process
improvement work occurs. This period should be agreed to upfront, with the BPM steering committee or project
sponsors, to properly set expectations.
Pitfall No. 4: Developing BPM Capabilities without Delivering Business Value
A BPM team must build its capabilities, but this effort needs to be balanced with a degree of realism: the
organization wants to see some return on its investment, often relatively quickly. Effort must be made to deliver
benefits — even if they are relatively small at first — and to communicate them to the business so it can see some
return on investment and feel positive about maintaining funding.
Pitfall No. 5: Focusing on Mapping Processes Instead of Improving Processes
BPM teams can get lost in mapping processes, acting under the assumption that this mapping activity amounts to
"doing BPM." However, if these process maps are not used as a tool for bringing about real business improvements
— or if such productive use cannot be demonstrated — they have no inherent value. BPM teams need to track and
communicate the business value delivered.
Peter Schoof of BPM.com fame reiterates some of these pitfalls in his analysis of the main reasons why BPM
initiatives fail, but adds a significant one: “Don’t treat BPM as a project”. In which he means that a BPM initiative
should not be finite, as a project approach would suggest. For this, we should always envision continuity of the BPM
effort after the project introducing or elaborating on the discipline has ended.

Alignment Architecture - Business Process Management  15/55

 4 Tools and Techniques

4.1 Analysis Techniques

BPM approaches play on three spheres of influence within an organization: the enterprise scope, the program
scope and the project scope. Each of these scopes requires different actions to be undertaken to make them
successful.

Illustration 4.1.1 – BPM Adoption Scopes

4.1.1 Enterprise Scope

The main idea of a BPM effort is to make an organization self-sufficient in their process efforts, reducing reliance on
outside consultants, and have a continuous improvement, as well as an operational organization in place to watch
of the day to day happenings. At this scope, we have the three major flows: governance, project portfolio
management and operational management. These flows will mainly make up the workings of the Centre of
Excellence (CoE), an organization playing at all three scopes in different capacities. Change needs to be managed,
so these workings are focused on guarding and guiding the transformations of the organization.
The necessity of feedback loops with relevant information for the involved parties introduced several of such flows:
1. The operational loop: Providing status information of a product and/or service and capacity information of the
resources handling the products or services (giving information like “is a certain resource overflowing or
standing still”, “how is the flow of production of the product/service going as we speak”).
2. The tactical loop: Using the accumulated data of how your process is performing. This gives you information
about how the process of a product or service is performing over time based on data provided by the product
itself and/or the resources handling the product in various stages.
3. Strategic loop: In this loop the accumulated data is not so much used for process improvement purposes,
but is used to analyze the product and services that are offered. Is there any demand, does the client want
an alteration of the product or a no product at all.
Corporate Governance is about creating and maintaining an environment for success (effectiveness), ensuring
consistency and establishing accountability. An extension of this is Process Governance, which at its core defines
the mandates (or decision-making rights) associated with the selection and execution of enterprise process
improvement initiatives.

Alignment Architecture - Business Process Management  16/55

 Governance and Change Management in a BPM context are driven and monitored by a Centre of Excellence. This
is a centralized group with executive mandate, which has to accomplish a wide variety of governance practices. The
Oracle BPM approach divides these into categories, each with their own activities:
 BPM Vitality Governance: Strategies, standards, practices, infrastructure,… must be kept current with
business motivation and strategy, legal and corporate mandates ,and industry and technology progress
 Portfolio Governance: The management of BPM projects, assets, and associated metadata across the
enterprise. It establishes a common language through categorization, supports process identification and
selection, and ensures business alignment.
 Design-time Governance: Focus on business process change, spanning analysis ,definition and
management of the business processes
 Operational Governance: Day-to-day monitoring and correcting of process instances
 BPM Organization Governance: Management of organizational changes as a result of redesign and
improvement of business processes, as well as the cultural change

Illustration 4.4.2 – Process Governance (Oracle)

The first step in establishing a Centre of Excellence is determining what its mission statement will be. Trying to
cover all fields of governance at once will be a herculean endeavor, at least initially. Identify the needs of your
clients and focus on those first. Later, the other relevant fields can be annexed into a smooth running operation.
This also comes with determining how the success of the Centre of Excellence will be measured. For a Centre of
Excellence to work, it also needs a mandate stipulating its strategic focus and a funding model. It is imperative that
it has upper management backing for it to succeed with any measure of success.
As with every initiative of this scale, there is a certain amount of resistance to change. It is critical that the Centre
deals with changing the playing field, so that it has every chance to succeed. The following questions need to be
addressed at its inception:
1. Who will oppose this and who must be won over?
2. What will keep you from succeeding?
3. What must you change to set the stage for success?
4. Propose a remediation plan to change what must be changed.
5. Offer a realistic roadmap to the foundation – but deliver benefit along the way.
Since business processes drive business operations, the day-to-day work of employees included, the adoption of
this type of architecture necessitates a certain amount of change management to assist people to adapt to new or
changed processes, and get them excited over the improvements (cultural awareness). In order to avoid the usual
amount of resistance to change, the communication surrounding the benefits of this change and employee
retraining become a major player in the success story of any BPM adoption.

Alignment Architecture - Business Process Management  17/55

 For the communication to run smoothly, there are a few steps5 worth following:
1. Plan: Before you do anything, draft a communications plan. This should include the messages you want to
communicate, the mediums you will use to communicate and the timeframes for the communications. But
who are you communicating with…?
2. Identify your audience: Who will be the process owners? Who is involved? You need to ensure that these
people feel loved from day 1. More communication is better than less. Explain to them what you are trying
to do, what help you need from them and how you are going to perform the work.
3. Start off big: You may think that by identifying your key audience that you have covered all your bases, but
be sure to expand your communications to as many people as you can (within reason). There are always
people who are left out of the loop who feel that they should be involved. It’s important to make these
people feel that their opinions are being heard or they can inflict negative PR on your process change.
Remember, however, that the bigger the audience for communication the more general your
communication should be. Think of this as part of a marketing campaign within the organization that you
need to launch in order to sell the Centre of Excellence to its recipients.
4. Build Rapport: By this I mean that you should get to know your audience personally. The more you can
break down barriers and understand personality types the more likely they will be to co-operate with you.
Don’t be afraid to ask them about their lives outside of work. They may even start to think of you as a
human being!
5. Make it regular, consistent: Whatever communications you are performing you need to make sure that it is
regular. This is because it often takes time for a message to sink in. The world is so filled with
communication “noise” that it may take a number of communications before people start to “get it”. This is
why the communication needs to be consistent, in order to hammer home the message. It’s like beating a
drum over and over – eventually people will hear it and start to walk in step.
Ideally, change management already starts in the process design/redesign phase where we actively involve the
stakeholders. One should never dictate a customer what the process should be. Even if the process design is
obvious to the BPM consultant, it is vital that the customer comes to this conclusion on his own with the help of the
consultant. We need to guide him in the right direction, not push him.
This is likened by James Adonis to the hard power/soft power approach. When trying to get your employees to
adhere to policies and procedures, you have hard power and soft power at your disposal. Hard power is negative
motivation. This is when you intimidate employees into compliance. You issue warnings, reprimand them, and offer
greater (or fewer) tangible rewards. Soft power is when you get them to follow a new process via the art of
influence. He states seven ways of utilizing soft power:
1. Involve people: Get your employees’ buy-in before a new process is set up.
2. Explain yourself: Don’t just issue instructions. Explain the rationale behind them.
3. Verify understanding: Check that you and your team are on the same page.
4. Communicate openly: Once the new procedure is in place, ask staff for feedback.
5. Be credible: Display the desired behaviors you most want to see.
6. Be friendly: Employees are more prone to accept ideas from personable managers.
7. Repeat the process: Most of us need to hear stuff a few times before it sinks in.
Operational governance comes with its own set of best practices, but when regarding the change, one should not
only take into account the versioning of the business processes, but also how a system should react in the case of a
new version in relation to active instances of that process. Typically, two approaches can be determined. One is
letting the instances continue in the previous version of the process, and only new instances would start with the
new version. A second option is the migration (if possible) of all instances to the new version. Each of these options
has consequences for the enterprise, which should be weighed, perhaps even on a per change basis.
Each of the governance categories described above follows their proper continuous improvement loop, which
consists of the following phases:
 Assessment: The framework applies an incremental approach to defining and deploying a BPM
Governance model in which the assessment phase evaluates the BPM strategy to identify and prioritize
the current BPM challenges and assembles them into an initial BPM Governance roadmap.
 Strategy and Planning: Existing governance practices are evaluated alongside the BPM Governance
Framework to determine immediate governance needs, size the effort to match the scale of the BPM
program, and integrate with existing practices. The roadmap is further elaborated to expand the

5
Taken from the Process Ninja Blog

Alignment Architecture - Business Process Management  18/55

 governance capability in parallel with BPM rollout, while its effectiveness is evaluated with every
subsequent cycle of the improvement loop.
 Execution: Existing governance practices are updated while new ones are implemented according to the
established roadmap. As governance practices are implemented they are carefully monitored to collect
metrics concerned with the effectiveness of the BPM program and the impact of BPM governance.

Illustration 4.1.3 – Continuous Improvement Loop (Oracle)

For illustrating the management of individual processes, we have the Process Management Diagram, which was
initially developed by Geary Rummler and Alan Brache in their book “Improving Performance”. The main idea of this
diagram is to describe the tasks that a process manager should take to heart in order to ensure the proper workings
of the business processes. The diagram helps in the initial analysis of process problems, as well as the operational
follow-up of processes. In essence, it illustrates how a process manager will perform the change management of
said process.

Illustration 4.1.4 – Process Management Diagram

Alignment Architecture - Business Process Management  19/55

 4.1.2 Program Scope
4.1.2.1 BPM Roadmap
The program scope effort starts with an extensive assessment and process selection activity leading to a roadmap
planning. This is supported by numerous techniques and frameworks coming together as part of the working of the
before mentioned Centre of Excellence. The project scope effort will be the all-important implementation of the
business process automation, of which the most important techniques are highlighted in this chapter.
In order to draft up a roadmap, the architect has to establish what goals are valued, how they relate in a hierarchy
(applying the MoSCoW rating) , and which level of adoption (enterprise, business unit, project, ..) is needed, before
a gap analysis can be made between the current state and where this project needs to take the solution (future
vision definition). As with every current state, we assess it by employing a Maturity Model (see appendix). This will
in turn decide and hierarchically structure the capabilities needed, which is reflected in the Logical View of the
architecture.
The goals have been listed in detail in the requirements chapter, but not all of these apply to every level of maturity
of the BPM adoption. The goals to attain are sorted in the following hierarchy, with the score reflecting the different
maturity levels (Ad hoc scoring 1 and Managed scoring 5).
Goal Statement Score
Enable rapid response to changing business conditions (e.g. competition, market forces, acquisition, etc.) 5
Develop a cycle of continuous improvement of business processes. 5
Monitor business process efficiency and effectiveness of change based on KPIs 4
Improve business process transparency and visibility for improved control and consistency 3
Enable knowledge management through documented processes. 2
Facilitate streamlining of human tasks through automation. 2
Apply BPM to a limited set of projects to demonstrate the benefits of BPM and build credibility with the 1
business owners.
Improve business/IT alignment through common business process language and shared repositories 1

Once the capabilities are decided upon, and the proper business processes are selected (see chapter “Process
Selection”), the project will stipulate a planning for the implementation of these capabilities, and form a schedule.
Typically, the most effective horizon in terms of planning a BPM project is 2 to 3 years in throughput. It is of vital
importance that during the scope definition of the roadmap, all involved parties agree upon the adoption level,
ranging from enterprise adoption to project adoption.

Illustration 4.1.5 – BPM Roadmap (Oracle)

Alignment Architecture - Business Process Management  20/55

 4.1.2.2 Capability Development
Not all companies start with a full-blown BPM project. However, the sooner a company starts the process of
migration towards a process-driven enterprise, the more benefits can be reaped. Craig Ryan (aka the Process
Ninja) compares BPM to a garden, which demands a lot of attention and a significant cost to maintain. So he
willfully ignores this until the weeds grow to such a proportion that it takes half a day to clear them all. Half a day
that can be avoided by scheduling 10 minutes of work every two weeks. As with a BPM project, the time (and
budget) must be spent to put in place so that the process changes are never big enough to warrant a project of
themselves.

Illustration 4.1.6 – CMMI Levels applied to BPM Maturity

Paul Harmon of BPTrends divides company maturity using CMMI (see illustration), a simile also detailed in the
Business Process Maturity Model of OMG. He stipulates that most companies are in the level 1 to 2 bracket and are
just not quite ready for automation and optimization. The processes are ad hoc or just monitored for cost, schedule
and functionality, where success either depends on individual effort or an attempt to repeat earlier victories. When
companies reach maturity level 3, most processes have been documented and standardized, but the goals these
processes aspire to, have not yet been crystalized. Companies at level 4 are exceedingly rare, and have managed
to link their processes back to the company strategy and goals, where level 5 companies have a companywide
effort to continuously improve upon said processes and goals. This is a view very similar to BPM Maturity as defined
by the Object Management Group.
Transitioning a culture of heroes into an organization with the capacity for of repeatable success, requires it to chart
the majority of its processes and classify them into process maps. This will ensure visibility of the business
processes as well as reduce the effort needed for an ISO 9001:2008 certification. This certification is based on three
principals, which can all be supported by a proper BPM architecture:
 Tell me what you do (describe the business process)
 Show me where it says that (reference the procedure manuals)
 Prove that this is what happened (exhibit evidence in documented records)
A secondary benefit is the support in knowledge management this visibility achieves. In an economic climate ruled
by relatively high employee turnover rate and an aging workforce, knowledge that is possessed by employees is
constantly in danger of getting lost, and the effort to train new employees is higher than it needs to be. It also
introduces realistic commitments for work, based on previous work efforts and work requirements.
Once the majority of the processes has been captured, the alignment with the business strategy and its goals needs
to be made in order to determine the proper KPI’s to measure in the processes. This information will in turn feed the
business analytics effort with relevant data. As a result of this exercise, the processes can also be automated,
reducing defects and achieving process flexibility. Once automated, the KPI’s can be monitored by the IT systems.
Once we has a near complete picture of the process landscape within the organization, individual processes can

Alignment Architecture - Business Process Management  21/55

 also be redesigned more easily on an enterprise scope. The organization has reached a maturity level of
Standardized Processes.
After the business strategy alignment, we need to consider how to approach the question of process change. The
processes are evolving to a Predictable Level. There is a need to quantitatively understand, reduce, and control
variation in how work is performed. Process change ranges from analyzing and redesigning very specific business
processes to projects that seek to completely reconceptualize a major line of business. This step of process
refinement is elaborated in its proper chapter. With the capability to handle change, the possibility for it becoming an
innovation driver materializes. New ideas (such as for example Social BPM, or initiates derived from the business
analytics effort) can be rapidly expanded upon, and as a result be capitalized on. Processes can even undergo
corrective actions towards performance and quality goals while being executed.
To achieve a level where the organization has a system in place for continuously improving its processes, we need
to expand the mission of the Centre of Excellence to encompass all levels of governance surrounding the BPM
effort, as well as determine an approach for the business process reengineering. Not all methods (such as Lean or
Six Sigma) are beneficial to all organizations, and choices must be weighed and made to adopt the proper way
forward. Only this way does the organization strive for a continuous competitive advantage. The main categories for
improvement at this level of maturity are:
 Defect and problem prevention improvements
 Planned innovative improvements
 Continuous capability improvements

4.1.2.3 Process Refinement Strategies

Michael Hammer identifies three types of business that benefit from business process re-engineering (BPR). The
first is companies that are in big trouble, that are being beaten by competitors, that are losing money, that are just in
terrible shape. These companies turn to re-engineering as a last resort. The second group is composed of
companies facing major change. Everything is pretty good now, but they see on the horizon a very different set of
circumstances. An example of this is a business that is subject to changing regulations. This is the largest group of
companies that are re-engineering because almost every industry is in the throes of unbelievable change. And the
third group is filled with companies that are doing just fine, that don't see major change on the horizon, but they re-
engineer in order to get so much better than the competition that nobody will ever catch them. In short, his opinion
was that all businesses need BPR in one form or another to keep their competitive advantage.
Depending on the market situation, which is considered either a red ocean or blue ocean 6 market, we employ
different approaches to improve processes. We either apply innovation principles such as business value
management and business value engineering, or we apply optimization principles such as Six Sigma or Lean.
Adding business value to a process can be done through different approaches, but it boils down to addressing the
following five avenues, as defined by Gartner:
 Automating business processes: This approach has the goal of reducing the cost of doing business by
replacing human assets with computer assets, improving the overall quality of the process.
 Augmenting business processes: Not all processes (or partial processes) can be automated. This is mostly
the case for routine work. However, the non-routine work of human assets can still be augmented by
handing them the tools to efficiently do their work (such as for example search engines or knowledge
repositories)
 E-commerce execution: This approach exploits the Internet in order to make the different services and
products of an organization available to a larger audience.
 Externalizing the organization: This approach leverages the social media to gather information on the
needs of the customer in order to tune the value streams towards this insight. This is also call Social BPM
and is elaborated in a later chapter.
 Acting on novel signal patterns: This approach scans the ecosystem of the organization for subtle signs of
change in order to proactively play in to these changes. We employ Business Analytics to analyze and
comprehend this vast behemoth of information.
A comprehensive overview of process refinement and its applicable methodologies can be seen in the illustration
below. As stated, these techniques range from addressing optimization principles like performance improvement
and quality management to innovation principles such as customer bonding. We delve into these methodologies in
more detail with the appendix surrounding Business Process Refinement Techniques.

6
Blue Ocean Strategy – W. Chan Kim & Renée Mauborgne

Alignment Architecture - Business Process Management  22/55

 Illustration 4.1.7 – Process Refinement Techniques

4.1.3 Project Scope

4.1.3.1 Process Discovery
Process discovery (or identification) is not a trifle matter. Industry research has indicated that this step consumes
around 40% of the time and effort to roll out a BPM approach. This because discovery of existing processes is
largely a manual, time-intensive exercise conducted through meetings and human interactions. The information to
extract can be seen on the illustration below. One effective way for process discovery is however “walking the
process”. Instead of doing the workshops and interviews and documentation reviews, one can simply go to the
workflow and follow a process by literally walking along the different workers performing it. It allows for a visual
picture to form in the head of the consultant. This will not grant an exhaustive knowledge of the process, but it’s an
ideal first step.

Illustration 4.1.8 – Example Business Process Context Diagram (Oracle)

Alignment Architecture - Business Process Management  23/55

 Another way to discover the processes, is by analyzing the data that is available in an organization and attempting
to structure this in processes through the use of different algorithms (such as conformance checking, predictive
analytics, data analysis,…). This practice is called ‘Process Mining’. There are tools that facilitate this, but they
usually dictate stringent requirements for this discovery. For these tools to work, we need data in transactional
activity logs, which can be correlated. This information should be structured according to the eXtensible Event
Stream standard (XES). In short, we need to make sure that an activity log will always contain the following
information for each activity:
 The Business Process Context: A unique identifier with which we can correlate all activities part of the
same process instance
 The Process Step: A unique identifier for indicating which activity in the process has been logged.
 The Activity Timestamp: A time indication of when (and preferably how long) this activity took place.
A host of additional information, such as the performer identification and/or role, adds to the options we have for
analyzing the efficacy of the process. This information can also be used to run analytics on the process in order to
determine bottlenecks and other points of refinement.
However, unless the as-is state of a process is felt to be for the large part close to being optimized, spending time
documenting it in detail is a bit excessive. A simple workshop with the stakeholders to define and agree upon the
process is sufficient before reworking it completely. A simple drawing or photo beats the pages of detail we normally
produce for a process.

4.1.3.2 Process Selection

BPM projects are instantiated by the need to automate a business process. Typically, the processes in such a
project already exist (creation of an entirely new process is an unusual occurrence), so the activities (both human
and system) in such a process already exist in some form. The challenge for a BPM project is how to integrate
these activities. The secondary main goal is for continuous improvement. For this to be achievable we have a strong
requirement for being able to measure the day-to-day operations of these automated business processes.
Selecting which processes are valid or preferred candidates for a BPM project, can be done in two different ways.
The first way is the Strategic Approach, where we select the processes that are most in alignment with the business
goals and objectives. We view these processes as assets with a direct link to business value.
The Strategic Approach leans heavily on OMG’s Business Motivation Model (which is described in the appendix),
where we will match the processes against the business strategy and business values of the enterprise to
determine which processes are to be implemented first.
When a Strategic Approach is not possible due to the absence of business inputs (top-level models and business
motivation), we can still assess the processes win a second way, namely the Tactical Approach. Here we identify
process candidates without the assessment of Value Alignment, but rather we attempt to raise visibility and try to
gain senior management commitment for future BPM projects. If the scope of these processes is not yet clear (we
map this using the Business Capability Model). In this approach, we will be looking at core processes, as well as
“low-hanging fruit” for process improvement.

Illustration 4.1.9 – Business Capability Model

Alignment Architecture - Business Process Management  24/55

 Both approaches let us draw up a priority, based on process certification ratings, as well as a justification for the
selection, which we both record into the process selection list. These two approaches are visualized in the
illustration below.

Illustration 4.1.10 – Process Selection Method

Typically we gather the necessary information about the enterprise’s policies and procedures in six areas:
 Policy & Procedure Manuals
 People
 Legacy Code
 Enterprise Architecture Modeling Artifacts
 Databases (Operational & Data Warehouses)
 Automation
The process is added to the enterprise
process collection, which is preferably divided
into logical categories to improve the retrieval
ease of a relevant process. Several
classifications exist, from the more generic
ones like the Supply Chain Operations
Reference (SCOR) model or the Value
Reference Model (VRM) to more industry-
specific models like the Medicaid Information
Technology Architecture (MITA), which is
focused on the healthcare reimbursement
industry.
The standard classification we use will be the
Process Classification Framework (PCF) of
APQC, which is an expansion upon the Porter
Value Chain, and divides all business
processes within an enterprise into 11
classifications, as shown in the illustration.
For each of these classifications, the APQC
also has an elaboration per industry.
In these industry-specific elaborations, we
expand the classifications with process
groups relevant to that industry, and fill those
groups up with processes, made up of
activities taking place in those processes. For
example, if we take their PCF for the Education industry, we notice that classification 2.0 is renamed “Develop,
Deliver and Assess Curriculum, Assessment and Instruction”. One of the process group under this classification
would be “Develop Curriculum”, which contains the process “Align with Federal/State/Local Governments” with a
possible activity of “Align with Content Standards”.
Should a proper enterprise collection not exist (or not yet exist), we employ a BPM Tracker checklist to ensure no
process gets left behind. This is a basic Excel template that can be utilized much to the same effect an enterprise

Alignment Architecture - Business Process Management  25/55

 collection in terms of rendering visible the BPM effort within an organization, but should soon be migrated to an
automated solution.
The Data-Centric BPM approach by IBM however, indicates that another standard classification may exist in every
enterprise, namely that of the ad-hoc activities. These don’t have any process groups or processes as such, but are
rather a set of tools (read activities) that knowledge workers can use to deal with unexpected happenings in the
execution of a process. Modeling these tools into the system allows for them to be measured, and as such to
possibly be integrated in the next iteration of the process. Letting knowledge workers correct them directly on the
data stores, renders these actions largely invisible and unmeasured otherwise.
Several risks exist in this phase of the project. The first risk is that BPM benefits will not be realized because the
process may not be suited to automation or its automation may be beyond the current capabilities of the enterprise.
A second risk is that the business process selected may not even be a proper business process, but rather a sub
process or individual activity that should be handled by another component of the overall architecture. In short, we
should assess three things when selecting a business process candidate: suitability of the process to realize BPM
benefits, capabilities and maturity of the enterprise, and distinguishing the right kind of process for automation.

4.1.3.3 Process Design

To get acquainted with the Business Process Modeling Notation (BPMN) for describing processes, we suggest
reading Bruce Silver’s book “BPMN Method & Style 2 nd Edition”, which is a comprehensive journey through process
design. This is an explanation of the OMG standard “BPMN v2.0” by using examples to illustrate its use and
implications.
As indicated in both the book and the chapter on BPM levels, we design the process in three steps. The first of
which we use to define the happy flow of the process. We design the process to cover a normal pass-through,
focusing on manageable portions, and no exception flows are considered. Typically, we only use basic BPMN
symbols to promote readability for business users.
The next step is about elaborating the process details, in concert between the process analyst and the technical
analyst. All extra information surrounding general information (business exceptions, functional inconsistencies…),
process execution (exception flows, transactions, compensations…), and IT resource utilization (supporting assets,
information needs …) is added into the descriptive process.
Finally, the execution model is fleshed out in a third step, where the technical analyst wires the technical
configuration into the business process to make it executable on a BPMS engine. This is mapping the business
process activities to IT assets. There is also a need to analyze the cost of each of these activities (in terms of
performance, CPU cycles, memory assets, etc...) to scale the backbone to the support of the automation.

4.1.3.4 Process Testing

Business processes are tested through simulation. Most BPMS products support this functionality. In the case the
process has not been automated, setting up a way for collecting data and determining a baseline should be part of
the test plan. Simulation should verify whether the process conforms to the goals set out in the process design
(performance, quality, etc.) as well as verify whether the process conforms to the functional requirements without
bugs.

4.1.3.5 Process Monitoring

The BPM line is “monitor, manage, and optimize” with a strong focus on the empowerment of business users and
the enabling of continuous improvement of business processes. But to be able to optimize we first need metrics.
The advantages gained from process monitoring are:
 Conformance: the ability to verify that the process operates within specified values
 Performance: the ability to measure performance and gather the necessary metrics necessary to improve
 Better understanding of business process effectiveness and enabler for root cause analysis
 Competitive advantage: collecting the right information to maintain this advantage
 Understanding business value and providing justification for Strategic Changes
 Basis for automated responses to anticipated operational issues
When we use BMM to guide our process selection, we already have a mapping of the process onto the goals set
out from the business vision and strategy. The most important of these will be called critical success factors and will
have linked to them key performance indicators (KPI) that give us information on whether these goals are achieved
or not. These KPI’s will normally be linked to an acceptable range of metrics, the lower end being called lagging
indicators and the higher end being called leading indicators. However, not all KPI are created equal. Sometimes a

Alignment Architecture - Business Process Management  26/55

 strict hierarchy can be detected among them, resulting in a KPI tree. An example of which can be seen in the
illustration below.

Illustration 4.1.11 – KPI Tree Example

When automated monitoring is not possible due to constraints (financial, technical, etc.), an alternative is to apply
Activity-Based Costing (ABC). This methodology will help assign costs to each activity in a process, and as such a
business process refinement effort can take place without technological automation. ABC will determine a cost
based on three major categories: Fixed cost, variable cost and overhead cost.

4.1.3.6 Process Refinement

As indicated in the chapter on the BPM Lifecycle, in continuously improving enterprises there are usually at least
three iterative cycles for achieving operational excellence. In each of these cycles, we go through the steps of
selecting a process, designing it, implementing it, and monitoring the result. From the second cycle on, we no longer
speak of designing the process, but rather refining the process in order to achieve the needed/wanted
improvements to achieve performance and effectiveness objectives.
A common practice to evaluate whether a process necessitates rework, is to devise and apply process certification
ratings, based on criteria ranging from basic requirements (such as whether the process has a unique name or is it
properly documented) to operational requirements (such as the defect percentage) and value to the customer.
Other triggers for the need for these changes can come from several different angles, such as:
 New or changing business goals & objectives
 Known issues and suggestions
 Internal policies and business regulations
 Mergers & acquisitions
 Business process re-engineering effort
 …
Another trigger for process improvement might be to perform benchmarking against existing industry statistics. It is
important that the top 25% of competitors be taken as starting point, and not to employ benchmarking to strive for
the average. However, when employing this technique, the following steps should be adhered:
1. Evaluate the quality of the data source to properly understand the benchmark’s relevance. We need to
compare organizations that are very similar in terms of organizational structure and market geography, in
order to get a valid result.
2. Validate the calculation method used in the benchmark. When devising industry benchmarks, an
aggregation of several data points is done, mostly based on the average of the numbers. As mentioned
before, it is better to take the top 25%.
3. Remember not to compare apples to oranges when data sources are selected. The numbers used must be
relevant to the organization that is being benchmarked.
4. Take into account the complexity of the process. Avoid measuring the happy path, but prefer to aim for the
more complicated paths through the process.
Optimization principles strive towards a balance between efficiency and effectiveness of a process. We capture
these two factors in the 4 dimensions of performance. A large part is the cost of the process. Here we will try to
address the efficiency of the process. We also need to consider variety. Does our process have a large enough
customer heterogeneity to provide for the needs of our entire customer base? Evidently, time is a third dimension,
where we measure the responsiveness to demand. And finally, quality plays a role, where we make the distinction
between product performance (How good is the product quality?) versus product conformance (Is the product as

Alignment Architecture - Business Process Management  27/55

 good as promised?). There are many ways to improve a process, but these dimensions are a recurring factor in
each of these.
Process improvement runs the process through an additional iteration of the process lifecycle, and preferably does
this organized as a project. The phases of this project are shown in the illustration below, and are further elaborated
in the accompanying table. As a project, it faces the same difficulties as any other, some of which are a lack of
sustained management commitment and leadership, or their unrealistic scope and expectations. There can be a
resistance to change from several stakeholders in the process. Or there has been ineffective communication to
those most affected by the proposed changes.
Once we have determined the changes, an approval procedure is to be followed with all the stakeholders. This will
lead to an official GO/NO GO-decision, of which a NO GO-decision can result in either needing to reiterate our
Discovery-Design-Approval steps, or scrapping the BPR effort as no longer needed. In this case, we skip the
Implementation steps, and proceed immediately to the Wrap-up.

Illustration 4.1.12 – Process Refinement Project Approach

Phase Activities
TRIGGER: An appropriate process or set of processes was selected for process refinement
Startup  Identify key business drivers for change & assess consequences for not changing.
 Identify critical processes for reengineering.
 Identify executive sponsors & create steering committee of key stakeholders
 Gain executive support for the project.
 Prepare PMP: define scope; establish measurable objectives; inherit methodologies
and best practices from the BPM body of knowledge; and establish a high level
schedule.
 Obtain agreement with executive/senior managers on objectives & scope for the
project.
 Select the team.
 Select consultants or outside experts, where applicable.
 Hold kick-off meeting.
 Brief functional managers about the goals of the project; begin communications to the
organization.
 Train the team. (BPR; Benchmarking; Best Practices etc.)
 Begin change management activities and prepared a communication plan.
Discovery  Conduct interviews; surveys; focus groups to identify current & future needs.
 Interview employees and managers to understand issues and to brainstorm ideas for
change.
 Conduct literature and periodical research to understand industry trends and to find
best practices to add to body of knowledge.
 Examine “success stories” of other companies
 Identify gaps based on performance data.
 Review technology changes & options.
 Interview stakeholders & key senior managers.
 Organize workshops or seminars to address the topics of benchmarking, risk
assessment, etc.
 Gather data from external experts & consultants.
Design  Conduct what-if simulations.
 Generate models by using functional experts; develop hybrid model by taking the best
of each.
 Create vision of ideal process.
 Identify approach to process (see illustration 4.1.7.1)
 Define new process models.
 Design organizational model to align to new process.

Alignment Architecture - Business Process Management  28/55

  Define technology requirements; select platform to enable new processes.
 Separate short and long term improvements. (Emulate processes that cannot be
technology enabled immediately; allow flexibility for process change/enhancements.)
Approval  Prepare feasibility analysis of changes
 Prepare cost and benefit analysis; determine return on investment
 Assess impact on customers; employees; on competitive position.
 Prepare formal business case for senior managers/executives.
 Hold review meeting of present finds to steering committee & senior management for
approval.
MILESTONE: An official GO/NO GO has been decided upon. If GO, then the following phases occur, otherwise the
previous phases should be reiterated to achieve a more mature design.
Implementation  Complete detailed design of processes and organizational models.
 Develop supporting systems.
 Conduct pilot solutions and test on a small scale.
 Develop phased implementation plan and implement solution.
 Communicate the new solution to the employees; develop and implement a change
management plan.
 Develop training plan and train employees on new processes and/or systems.
 Develop phased deployment plan and deploy solution.
Wrap-up  Staged deployment of development
 Organize retrospective to gather experiences of the project
 Assimilate lessons learned into the BPM body of knowledge
 Issue final report to steering committee & senior managers.

4.1.3.7 Process Security Analysis

One topic for extra consideration during process design is the security needs analysis, which can be seen as part of
the technical analysis, where a match must be made between the authorization needed for the activities and the
security model implemented in the technological building blocks where the activity needs to be resolved.
First we need a logical data model mapping the different organizational layers onto our data object and activities.
The different mappings will be the enterprise, divided up into its semantic communities (or business units). Those
communities will be divided into departments. Next we map the different sources (or applications) to those
departments, and finally we list the mappings to the business entities. This number of layers is a standard starting
point, but the number of layers can vary depending on the structure of the enterprise.

Illustration 4.1.13 – Logical Data Model (Oracle)

The security analysis can be divided into 2 categories, each with their specific steps that determine the scope:
 Identity and Access Control
o Determine the mechanisms used to authenticate users interacting with the process
o Determine the mechanisms used to authenticate system interactions

Alignment Architecture - Business Process Management  29/55

 o Map identified roles/groups/people to identity management system entities
o Establish access control policies for process triggers (start, end and resume points)
o Determine authentication and/or identity propagation strategies
 Integrity and Confidentiality
o Review security classifications of data and/or content used by the process
o Determine security risks to information based on network exposure, location, and other items
o Identity encryption requirements to ensure the correct level of confidentiality
o Identify data masking requirements based on data classifications and user access levels
o Identify process and data integrity requirements that might necessitate digital signatures and/or
non-repudiation
o Determine the key management strategy
o Identify and address risks introduced via process execution (persisted state, cached data objects,
audit logging, cluster network traffic…)

4.1.4 Additional Considerations

Several disciplines emerging from other fields of IT, are starting to integrate with the BPM approach for mutual
reinforcement. All of these disciplines either serve as input for the processes, or handle the output of a process, or
are leveraged as activities with a process. For example, a social media event can trigger a process or business
intelligence can leverage the information provided by process instances for different purposes, even starting new
processes based on these results.

4.1.4.1 Social BPM

Social BPM presents itself in two distinct flavors. On the one hand, it uses Web 2.0 and Enterprise 2.0 style
collaboration portals where participants can share and influence process design and certain decision making
activities during process execution. This flavor has been renamed by Gartner in 2015 to Design-By-Doing. On the
other hand, we also speak of Social BPM when we allude to leveraging the organization’s outward social media
resources into internal business processes.
Nathaniel Palmer explains in “Passports to Success in BPM” that for Social Media, being one of Gartner’s Nexus of
Forces, to influence and drive your process optimization effort, you need to embrace the two factors governing over
it, namely trust and reputation. On Social Media you select your network not on experience or firsthand knowledge,
but rather on these principles. Much as the grain trade in ancient Rome, when information on a product can’t travel
faster than the actual product, trust becomes key in managing such flows. This leads to him determining three forms
of social interaction:
 Social Modeling: let the process modeling and discovery in your organization be led by social media
conventions
 Social Collaboration: using internal social networks to create virtual teams around activities and efforts
 Social Chatter: the Big Data of capturing social events and processing them to use as input for business
determinations, and goal driven activities

4.1.4.2 Business Analytics

The process monitoring ensures that the organization has a trove of useful data on which to work in order to get
further benefit from BPM. This data can be wielded in several distinct ways, the most common of which is business
intelligence (BI), namely obtaining process-centric information for decision-making and planning of strategies and
commercial and marketing actions. Performing detailed analytics on the information (both quantitative and
qualitative) registered by the process instances, renders insight into a range of possible areas of interest, such as
customer profiles, transaction trends, favorability of points of sales, etc.
An elaborated example of this is customer data and how it is positioned with respects to the ecosystem in which the
organization operates. For example, this data can be used to predict and eventualities. Such customer data comes
in four distinct flavors:
 Descriptive information: this includes the customer’s demographics, such as his name, address, gender,
marital status, estimated household income…
 Behavioral information: this includes transaction information such as order information, payment history,
and shipping addresses
 Interaction Information: this details when, where, and with whom interaction took place, what was
communicated and what was the outcome.

Alignment Architecture - Business Process Management  30/55

  Attitudinal Information: this includes information on the opinions, preferences, perceptions, moods… that
can be found internally in survey notes, email comments and open-ended inquiries typed into your website,
or social media.

Illustration 4.1.13 – 360° Customer View (IBM)

Gartner stipulates that there are five technologies that currently prevail in the IT Operations Analytics market:
 Complex operations event processing: The application of expert system-like rules and filters to streaming
operations data.
 Statistical pattern discovery and modeling: The automated construction of probability distributions that best-fit
either streaming or persisted numerical operations data and the drawing of statistical and logical inferences
from the probability distributions.
 Topology discovery and modeling: The automated discovery, presentation and smart scrutiny of complex
logical system topologies, as well as the use of topological representations to illuminate numerical and textual
operations data.
 Polystructured text search and text-based inference: The automated discovery of patterns, including key word
identification, in polystructured text files (typically log files), as well as the search of and reasoning about
lexical and semantic content based on those files
 High-dimension database modeling and analysis: The application of cube slicing and other multidimensional
structural searching techniques to high-dimensional, structured operations data.
These technologies can then be leveraged into an efficient implementation of the discipline of Intelligent Business
Operations (IBO). Gartner defines IBO as a style of work in which real-time analytic and decision management
technologies (such as a Business Process Monitor) are integrated into the transaction-executing and bookkeeping
operational activities that run the business. The basic idea is that BI and PM initiatives that support strategic
decisions are two or more steps removed from business operations, and thus these analytics become a
complementary source of input for these decisions. Organizations adopting a BPM Approach are very well
positioned to analyze where real-time analytics and decision management can improve their business. But as with
BPM, the impact of integrating real-time analytics into business operations and processes becomes instantly visible,
as it changes the way people do their jobs. It grants a strong visibility into how a company is run, and what is
happening in its external environments.
If we apply the principles of the OODA loop (Observe/Orient/Decide/Act) as popularized by John Boyd, the
technologies listed above, can be mapped to each of the steps of the loop, as shown in the illustration below. After
observing the data, an orientation phase based on that data should lead into deciding which actions to take in the
current improvement or innovation track.

Alignment Architecture - Business Process Management  31/55

 Illustration 4.1.14 – OODA Loop Applied to Intelligent Business Operations

4.1.4.3 Business Process Outsourcing

Business Process Outsourcing (BPO) is an approach where a selective number of processes are outsourced to a
third party. The nature or depth of this partnership should be clearly defined as part of the process governance.
Depending on the strategic import, complexity, change frequency and process interdependence, the tightness of the
partnership and in consequence the level of communication between the partners increases. We divide these
partnerships into three intimacy levels:
 Contractual Partners: The partnership is guided by contractual arrangements and SLA’s resulting in
minimum contact between the partners.
 Cooperative Partners: To successfully deal with process changes the level of communication is regulated
and frequent
 Partners in Success: The two companies are utterly dependent on each other for success, resulting in a
close cooperation and extensive communication.
Once the level of intimacy has been established, the need arises to assign assets of either partner on a per process
basis. These assets are the adoption of the way of working, whose people will execute or manage the process,
whose physical assets to use, and whose technology tools, use of partnerships for acquisition, etc.
It is of paramount importance that in BPO, regardless of the intimacy level, the companies set an escape hatch in
case the relationship doesn’t deliver on its needs. A solid BPO approach set exit clauses in the contractual
agreements, as well as stipulates a backup plan. At the very least, loss of information should be made impossible.

Alignment Architecture - Business Process Management  32/55

 4.2 Technical Concepts
The BPM conceptual architecture is composed of several core capabilities, identifying the major intersections within
the systems, and outlining the relationship between these capabilities. An overview presented by IBM for these
types of architectures can be seen in the illustration below.

Illustration 4.2.1 – BPM Conceptual Architecture (IBM)

4.2.1 Modeling and Simulation Tools

Modeling tools are the core of any BPM implementation. However, next to the process modelling a number of other
modeling capabilities also integrated into the tooling are an added benefit. These include the modeling and/or
implementation of UI components, collaboration dashboards, business rules, identities and roles …
Offering the possibility of simulation to the process modelers, gives them the tools to perform what-if analysis of
designed processes, as well as gauging the expected cost, performance, and resource utilization. Most simulation
tools do this by offering the possibility to create a script of sorts that the simulator utilizes to progress through the
different activities of the process. Random walk or Monte Carlo simulations are as of yet hardly ever a possibility.
An important capability is to be able to make the process loop closed. With this, we mean that the model that the
business analysts are working on (descriptive model) and the model the implementers are working on (executable
model) should stay in sync and the toolset should support this. An example of such a capability is Camunda Cycle.
This sync is important so that both groups can continue to be involved with the process refinement without too much
hassle of conversion.
Resource management is critical when working in a process-driven approach. We need to make sure that task
assignment considers the available resources for the execution of a task. One avenue to achieve this, is a business
calendar functionality where we can manage this availability at runtime on different levels (enterprise-wide or
department-wide holidays to employee-specific absences).

4.2.2 Process Analytics

Process Analytics is the practice of iterative, methodical exploration of business processes, with an emphasis on
statistical data. Fari Payandeh wrote a very illuminating example of the different categories of analytics in his article
“BI vs. Big Data vs. Data Analytics by Example”. The following paragraphs are an excerpt of this article.
Let’s say I work for the Center for Disease Control and my job is to analyze the data gathered from around the
country to improve our response time during flu season. Suppose we want to know about the geographical spread
of flu for the last winter (2012). We run some BI reports and it tells us that the state of New York had the most
outbreaks. Knowing that information we might want to better prepare the state for the next winter. These types of
queries examine past events, are most widely used, and fall under the Descriptive Analytics category.

Alignment Architecture - Business Process Management  33/55

 Now, we just purchased an interactive visualization tool and I am looking at the map of the United States depicting
the concentration of flu in different states for the last winter. I click on a button to display the vaccine distribution.
There it is; I visually detected a direct correlation between the intensity of flu outbreak with the late shipment of
vaccines. I noticed that the shipments of vaccine for the state of New York were delayed last year. This gives me a
clue to further investigate the case to determine if the correlation is causal. This type of analysis falls
under Diagnostic Analytics (discovery).
We go to the next phase which is Predictive Analytics. PA is what most people in the industry refer to as Data
Analytics. It gives us the probability of different outcomes and it is future-oriented. The US banks have been using
it for things like fraud detection. The process of distilling intelligence is more complex and it requires techniques like
Statistical Modeling. Back to our examples, I hire a Data Scientist to help me create a model and apply the data to
the model in order to identify causal relationships and correlations as they relate to the spread of flu for the winter of
2013. Note that we are now taking about the future. I can use my visualization tool to play around with some
variables such as demand, vaccine production rate, quantity… to weight the pluses and minuses of different
decisions insofar as how to prepare and tackle the potential problems in the coming months.
The last phase is the Prescriptive Analytics and that is to integrate our tried-and-true predictive models into our
repeatable processes to yield desired outcomes. An automated risk reduction system based on real-time data
received from the sensors in a factory would be a good example of its use case.

Illustration 4.2.2.1 – Analytics Categories

4.2.3 Business Activity Monitoring

The purpose of a Business Activity Monitor (or BAM) is twofold, monitoring both relevant KPI’s as well as the health
of business process instances. The data collected by this component enables both the business intelligence effort,
as well as the operational administration.
Gartner defines Business Activity Monitoring as providing access to real-time critical business performance
indicators to improve the effectiveness and response times of business operations. BAM is in essence a bridge
between Business Process Management and the Balanced Scorecard (BSC), introduced by Kaplan and Norton.
The idea is that BAM provides the metrics that can be used as input for process refinement to make the current
operations of a company more efficient and effective thus guaranteeing a company’s success in the long term by
increasing its agility to respond to changes in their environment and markets. The BSC comes into the picture for
matching the measured processes to the business strategy and values, so that these metrics can be weighted for
importance.

Alignment Architecture - Business Process Management  34/55

 With regard to process health, it gives administrators a heads up for responding to alerts an exceptional conditions.
Common scenarios of this are unhandled technical exceptions, processes that are stuck or stalled, excessive
processing times… Usually these occurrences will have coupled to them a set of escalation procedures on how to
resolve the issues that arose.

4.2.4 Operations and Administration

The Operations and Administration component should not only provide the administration options we usually
associate with software components (such as user management), but should also offer support for the follow-up of
processes. This means that the administrator should be able to easily find stalled and failed processes, determine
the cause of their incorrect behavior, and have the tools handy to rectify this situation.

4.2.5 Collaborations Component

The collaboration component is the heart and soul of the process execution. It allows knowledge workers to have a
comprehensive look over which tasks need doing, as well as allowing them to actually perform these tasks.
Typically it also allows for the reassignment of tasks, and even overviews of open tasks for supervisors. When a
business calendar on employee level is available, this is exposed to the knowledge worker via this channel as well.
When support for Social BPM exists in the component, a form of suggestion box is also present where knowledge
workers can formulate suggestions on how to fine-tune the different processes which they come into contact with as
part of the continuous improvement cycle for these processes. It also signifies that social interaction is possible
between knowledge workers, such as for example an integrated chat functionality

4.3 BPM Suites

4.3.1 Developer versus Designer
We define two very different types of BPM suites, namely the “developer BPMS” and the “designer BPMS”.
A developer-focused tool such as Activiti or JBoss jBPM is embedded directly into your container or standalone
application. You use your common development tooling and environment. You write source code including
corresponding unit tests. Usually, developer-focused tools are very lightweight, easy-to use, open source and offer
an API for your preferred language (e.g. Activiti is Java-based). You can start using it after some minutes. However,
developer-focused open source tools are not perfect. For instance, they often provide bad documentation and a
very rudimentary web frontend for modeling and monitoring.
On the other hand, there are designer-focused tools, which promise zero-coding. These tools are real products, not
just embeddable frameworks. You do not write source code. You create business processes in a graphical designer
via drag and drop. No coding is required. Decide for yourself if this is a pro or con. Sometimes, zero-coding might
be a con (remember the four myths about BPM - business analyst cannot model business processes). If you cannot
code anything or if you have to use ugly workarounds, then this can be a show-stopper for real world projects,
where the tool does not offer the feature, which you require.
Proprietary, designer-focused tools are very expensive and heavyweight solutions (e.g. you do not need to buy and
install just Oracle BPEL Suite, but also Oracle WebLogic Application Server, and several other products from the
Oracle stack). If you start installing such a suite on day 1, you probably will not be able to use it until at least day 2
(because installation is so complex and time-consuming). Contrary to developer-focused open source tools,
proprietary products offer high stability, powerful web frontends and good integration into other parts of your
development environment (if you use the whole stack from one vendor).
Besides heavyweight, proprietary BPM tools from large vendors such as Oracle or IBM, there is also some
designer-focused open source tools available, e.g. ProcessMaker or Bonita Open Solution. They are easy to setup
and learn. Usually, designer-focused open source tools are not as powerful as proprietary products. However, you
can add required functionality by yourself because they are open source.
So, the first question to answer for BPM tool choice is: Do I need / want a developer-focused tool or a designer-
focused tool? After you have made this decision, you can evaluate BPM tools by other criteria: Which features are
supported (e.g. a complex rules engine)? Is the tool extendable, can other software be integrated easily? Which
technologies are supported? How shall business processes be monitored? And so on...

Alignment Architecture - Business Process Management  35/55

 4.3.2 Key Functionalities
Gartner characterizes a BPMS as a tool supporting at least four key BPM use cases:
 Implementation of an industry or business-specific process application or solution
 Support for continuous process improvement
 Facilitation of a process-based SOA service design and service consumption
 Tooling support of Business-ICT collaboration (in particular business transformation initiatives)
Based on these characteristics, it has released its magic quadrant for BPMS in December of 2010, as shown below.
Other research groups such as Forrester, have made similar efforts to chart the market of BPMS vendors. A
noticeable lack of open source BPMS is however apparent in these charts.

Illustration 4.3.2.1 – BPMS Leader Positioning

When evaluating a BPMS implementation, one should take into consideration what functionalities are provided out-
of-the-box, as to match them with the requirements of the customer. This coverage should be weighed against the
cost of the suite, so we have an optimal value-for-money ratio. The matrix to consider is provided in the form of an
Excel (“BPMS Evaluation Template”).
The first block to consider is the modeling capability of the BPMS. Here we check for compliance with the BPMN 2.0
standard, as in how many of its modeling blocks are supported. The modeling tool should also provide support for
the forms associated with Human Tasks. We take into account the possibility of Stencil Sets. These are ways to
limit the number of BPMN modeling blocks are available to the business modelers. Much in the style of the
Microsoft Visio Stencil Sets. Every modeling tool should also have ways to both validate the process model against
the BPMN standard, as well as run simulations. These simulations can happen manually, with the modeler stepping
through the process and giving input, as well as scripted for automatic testing purposes or brute force simulations.
Finally we check for the possibility of runtime debugging of a process.
A second block is the summation of the technical concepts supported by the tool. The business calendar
functionality should detail its granularity (either enterprise level, business unit level or even employee level). And
when we examine task assignment, we look at RBAC, ABAC and dynamic person capabilities. Traditionally we will
also expect an event publisher for when we want to sync our process progress with other systems. The provisioning
of the user and group/role data towards other systems is a plus.
When deploying a process to environments, we will look for a staging strategy, with which we promote the process
versions through our different environments up to the production environment. It is important to see how the
deployment tool handles different versions of the process, and how the tool processes existing process instances
when deploying a new versions. Either he lets them continue in the process version they were started in, or he
migrates the instances to the new version. There should also be the possibility for process monitoring and analytics.
When regarding performance, the possibility of running the BPMS in a cluster is essential. Finally, the need for an

Alignment Architecture - Business Process Management  36/55

 archiving strategy of process data, as well as syncing capabilities with a possible disaster recovery environment
finish the list.
A point sometimes overlooked is the existing knowledge base of the product. This is usually strongly coupled with
the level of penetration the tool has in the current market. This will also assist in augmenting the adoption within an
enterprise.

4.3.3 Advantages
The advantages of BPM Suites could be summarized as follows:
Objectives BPM Suite Advantage
Increase Collaboration The BPM Suites communicate and share information, freeing it from controls that are
too stringent and objectives that are too narrow. BPM can easily dock within corporate
collaboration strategies to enable collaborative expansion.
Manage Change It is relatively easy to introduce changes in BPM solutions. BPM can also organize the
changes in repositories that maintain not only services but also complete BPM
solutions. Typically changes are realized with zero coding - through changing
executable forms or models - which are the re-usable assets of BPM solutions.
Intra and Inter Agency The dynamic repository of policies and procedures and the specialization directly
Re-Use supports this requirement and allows business units to share common practices and
then specialize for their particular objectives.
Cost Savings BPM Suites can be used to avoid waste and increase process efficiency. Waste can be
reduced in building solutions, while executing automated processes, and in monitoring
executing processes for continuous improvement. BPM Suites capture business
objectives and requirements directly: substantially reducing the cost of building
solutions. BPM Suites automate work: substantially reducing the cost of operating
agency services. BPM Suites continuously monitor and control work: substantially
reducing the cost of keeping processes in control.
Regulatory Compliance BPM Suites can directly capture and automate all the policies of regulatory compliance
in any domain, including financial. The controls for compliance can be automated. In
addition, since the dynamic BPM repository keeps an audit trail of all the changes,
agencies can easily find out the exact policies and procedures executed at a particular
point in time.
Transparency Policies and procedures are not “black boxes.” Through the appropriate access controls
and secure filtering, stakeholders can find out clearly and explicitly exactly what is being
executed in providing services either internally or to the clientele. Transparency of
enterprise policies and procedures could best be achieved through browsing the
dynamic BPM suite repository. Transparency of enterprise operations could best be
achieved through the business activity monitoring of executing processes.
Retiring Work Force Most enterprises have skilled workers who, as part of the baby boomer generation, will
be retiring in the next few years. These are knowledge workers. Through BPM suites
and proper discipline, enterprises can harvest the knowledge of these workers and
incorporate them into business process solutions.
IT Modernization BPM suites provide an agile business friendly process case management platform to
extend, expand, and modernize legacy solutions. This means new policies and
procedures are built in the BPM Suite, while accessing and leveraging legacy systems
of records, via service calls. The extension and integration can be bi-directional. This
means new policies and procedures can be captured in the BPM Suite and be invoked
from legacy systems: via service calls.

Alignment Architecture - Business Process Management  37/55

 5 Synergies

5.1 Service Oriented Architecture

BPM and SOA have a very natural synergy, as both architectures insist on a closer alignment between business
and ICT, and both strive towards a higher level of flexibility (or agility). When these two architectures are used in
tandem, the BPM architecture will focus more on the process level, while SOA plays more on the activity level.
When regarding the orchestration components of both architectures, the BPM will focus more on the orchestration
of the human interactions or the long-running system-centric processes (containing only automated tasks) where
visibility supersedes performance. SOA will tackle the short-running processes, and the long-running processes
where performance is prime.

5.2 Enterprise Application Integration

“The development and use of workflow technology has moved from simply supporting the routing of work between
people to routing work horizontally between resources (where the resource may be a person, but may also be a
system or even a machine) and vertically (controlling steps that will be performed at each point in the journey, such
as when programs will be invoked by the person, or actually invoking the program). And as data is being moved
between processes, there is typically integration with the processing systems – which pushes workflow into the
Enterprise Application Integration (EAI) arena.” – Charlie Plesums of the WfMC.
As indicated in the quote by Charlie Plesums, EAI is a supporting pillar in exposing company IT assets to be used
as actors in business processes to be automated. Similar to the SOA synergy, it also allows for the ownership of the
short-running processes.

5.3 Adaptive Case Management

Where BPMN is traditionally concerned with modeling the structured processes, the ACM discipline takes a look at
the unstructured ones. Where OMG is developing a proper modeling notation for these processes, called Case
Management Modeling Notation (CMMN), some gurus of the BPM community, not in the least Bruce Silver, have
postulated that we might consider extending BPMN to cover these unstructured processes, in such avoiding an
additional notation standard. We go into further detail about ACM and its relationship with BPM in the document
“Alignment Architecture - Adaptive Case Management”.

5.4 Business Decision Management

The Object Management Group positions Business Decision Management (or BDM) as a third pillar together with
ACM and BPM to effectively tackle any process management mission. In effect, they have developed notations for
each of these disciplines that interact in a very synergetic way. And any BPM initiative should indeed take account
of the business decisions that govern these processes, lest some problems arise during its effort. These problems
are the following:
1. Buried decisions: By merging the complexities of a business decision into a process, it becomes hidden. One
cannot evaluate, measure and improve the decision independently from the process.
2. Increased Process Complexity: The process becomes more complex than it needs to be, resulting in a spider
web of gateways and alternate routes.
3. Decision Duplication: The same decision might be used in different processes, making maintenance more
difficult, and increasing the danger of inconsistency.
4. Linked Evolution: The decision cannot evolve without the process changing.

Alignment Architecture - Business Process Management  38/55

 5.5 Enterprise Information Management
Enterprise Information Management (EIM) has a strong synergy with the BPM discipline, and as such can be easily
used as a sort of a gateway drug to the BPM stuff. Where the EIM layer adheres to the already 40 year old idea in
IT of abstracting data from the applications where it is treated, this can easily be expanded into the concept of
abstracting process flows and business logic using the BPMS layer.
EIM and Workflow BPM and ACM
Scope Single application, document or form; data Common UI and transactional thread spanning
and object model specific to application or multiple applications and process lifecycle; data
document; not shared structures based on process definition (or process
instance data) and separate from payloads or
applications where the work is performed
Security Application-specific, or authorization based Bound to roles defined by swim lanes and the
on document-specific or form-specific activities they contain; Role Based Access Control
processes (RBAC) applied to case folder, content or fine-
grained control of work items
Analytics Work item specific reporting, limited to a Advanced analytics enable identification and
single document, repository, or application reuse of patterns and exceptions, and operational
visibility
Data Visualization and manipulation of data Connectors to integrate external data into the case
Integration through forms or application-specific data folder of process instance. Manipulations of the
fields, and not accessible as a shared data through external services
service

Alignment Architecture - Business Process Management  39/55

 Appendix: BPM Maturity Model
Within the software industry, maturity is frequently assessed with the Capability Maturity Matrix (CMM) and its
successors. The Object Management Group has defined its proper Business Process Maturity Model (BPMM),
guided by its own Process Maturity Framework, and therefore stipulates 5 different states through which an
organization is transformed and its processes and capabilities are improved:
 Level 1: Initial — wherein
business processes are
performed in inconsistent
sometimes ad hoc ways with
results that are difficult to
predict.
 Level 2: Managed — wherein
management stabilizes the
work within local work units to
ensure that it can be
performed in a repeatable way
that satisfies the workgroup’s
primary commitments.
However, work units
performing similar tasks may
use different procedures.
 Level 3: Standardized —
wherein common, standard
processes are synthesized from best practices identified in the work groups and tailoring guidelines are
provided for supporting different business needs. Standard processes provide an economy of scale and a
foundation for learning from common measures and experience.
 Level 4: Predictable — wherein the capabilities enabled by standard processes are exploited and provided
back into the work units. Process performance is managed statistically throughout the workflow to understand
and control variation so that process outcomes can be predicted from intermediate states.
 Level 5: Innovating — wherein both proactive and opportunistic improvement actions seek innovations that
can close gaps between the organization’s current capability and the capability required to achieve its
business objectives.
Each of these level (past the initial level) corresponds to several process areas (see illustration A.1) that need to
be structured in what OMG divides into specific goals and practices as well as institutional goals and practices,
which for each process area boils down to the following:
1. Describe the Work
2. Plan the Work
3. Provide Knowledge and Skills
4. Control Performance and Results
5. Objectively Assure Conformance
 The practices of the Process Area should be institutionalized

Alignment Architecture - Business Process Management  40/55

 Illustration A.1 – OMG Process Areas

The Oracle BPM Maturity Model (see illustration A.2) also takes its cue from CMM and OMG, and measures BPM
capability against the predefined maturity levels, as well as take into account the level of BPM adoption in the
organization, which is called the Strategic Approach:
 Optimized - Metrics are being consistently gathered and are being used to incrementally improve the
capability. Assets are proactively maintained to ensure relevancy and correctness.
 Managed - The capability is being measured and quantitatively managed via some type of governance
structure. Appropriate metrics are being gathered and reported.
 Systematic - The approach has been reviewed and accepted by affected parties. There has been buy-in to
the documented approach and the approach is always (or nearly always) followed.
 Opportunistic - An approach has been decided upon and is being opportunistically applied. The approach
has not been widely accepted nor adopted. It may be informally defined, or if documented, may exist primarily
as “shelf ware”.
 Ad Hoc - Awareness of BPM exists and some groups are embarking on process automation. There is no BPM
plan being followed.

Alignment Architecture - Business Process Management  41/55

  No BPM - There is no BPM approach being taken. BPM is not underway.

Illustration A.2 – Oracle BPM Maturity Model

Alignment Architecture - Business Process Management  42/55

 Appendix: Business Motivation Model
The Business Motivation Model7 (BMM) is an OMG Specification for support of business decisions about how to
react to a changing world. An enterprise would use it by acquiring a BMM-compliant tool and then creating its own
BMM - populating the model with business information specific to the enterprise. There are two broad purposes:
 To capture decisions about reaction to change and the rationale for making them, with the intent of making
them shareable, increasing clarity and improving decision-making by learning from experience.
 To reference the outcomes of the decisions to their effect on the operational business (e.g. changes made
to business processes and organization responsibilities), providing traceability from influencer to
operational change.
The specification assumes that an enterprise BMM will stand alone, connected to the relevant parts of the
operational business by ‘placeholders’ – such as text references and URIs. An example of this model can be found
as the document “Alignment Architecture - BMM Example”.

Core Concepts
The BMM provides support in four areas, as illustrated in the diagram below:

The BMM is methodology-neutral, but a decision-making cycle is assumed:

 Influencers that can cause changes that might affect the enterprise are monitored;
 Changes that appear significant are assessed, taking account of relevant earlier assessments and
decisions and the effects of related influencers;
 Decisions are represented in Ends (which define what the enterprise has decided it wants to be) and
Means (which define what the enterprise has decided it needs to do in order to achieve its ends).
Influencers, assessments, and changes to ends and means are recorded in the enterprise’s BMM. Entries for ends
and means include references to those parts of the operational business that are affected.
Influencers
An influencer is something that an enterprise decides might affect it. There are two broad types:
 Internal Influencer: from within the enterprise (e.g. resource quality, infrastructure, habit).
 External Influencer: from outside the enterprise (e.g. customer, regulation, competition).

7
This text is taken from the paper “Overview of OMG Business Motivation Model – Core Concepts” by John Hall

Alignment Architecture - Business Process Management  43/55

 Influencers may (or may not) originate from recognized influencing organizations, such as regulators or competitors.
Assessments
When an influencer causes a significant change, the enterprise makes an assessment of its impact, identifying risks
and potential rewards. There may be multiple assessments, perhaps from different stakeholders. Assessments take
account of relevant earlier assessments and decisions recorded in the BMM, and of other influencers related to the
one causing the change. Assessments are supported by whatever business intelligence and risk analysis systems
the enterprise has; the BMM entry for an assessment includes references to the detail that supports it – reports,
studies, simulations, etc. – rather than containing the detail itself. The outcomes of an assessment are decisions
about ends and means.
Ends
Ends define what an enterprise wants to be – the states it desires to be in. There are three levels:
 Vision (optional): an easily-understood summary of what the enterprise considers itself to be, or aspires to
be. All objectives and goals should support (or, at least, not contradict) the vision.
 Desired Results:
o Goal: an enterprise state or condition to be maintained or approached in the medium to long term, e.g.
“To be one of the top three suppliers (by turnover) in our market”.
o Objective: a measurable, time-targeted step towards one or more goals, e.g. “To increase year-on-year
turnover by 2% in the current financial year”. Required or expected values of key performance
indicators are recorded as objectives, although not all objectives are based on key performance
indicators.
Desired results are supported by whatever progress management system the enterprise has. The BMM entry for a
desired result includes references to the detail that supports it, rather than containing the detail itself.
Means
Means define what an enterprise has decided it needs to do to achieve its ends. There are three kinds:
 Mission (optional): the enterprise’s primary activity. How it is carried out is defined in its courses of action.
 Course of Action: defines what the enterprise will do in support of one or more of its goals. There are two
kinds:
o Strategy: a major part of the plan to accomplish the mission, usually long-term and with a
significant impact on how the business operates, e.g. “Focus on repeat business from corporate
customers”
o Tactic: a course of action that supports one or more strategies - narrower in scope than a strategy
and may be short-term. For example, “Provide personal incentives for corporate bookings”.
There is no hard and fast distinction between strategy and tactic; it will vary from enterprise to enterprise. A
BMM entry for a course of action provides a summary description of the course of action, plus references
to the detail of the operational business - business processes, responsibilities assigned to organization
roles, deployment of assets and resources, etc. – where the course of action is realized.
 Directive: governs what courses of action can and should be adopted, and how they must or may be
realized:
o Business policy: a broad directive that needs further interpretation (in business rules) in order to
be put into practice, e.g. “Loans must be repayable”. Business policies may be documented in an
enterprise BMM, or in a separate policy management system.
o Business rule: reference to a rule in the operational business, e.g. “A home mortgage must not be
for more than 4 x the borrower’s salary”. Business rules make business policies practicable, and
guide business processes.

Scope
The scope of an enterprise BMM may be the entire enterprise, or an organization unit within it. Higher-level
organization units may appear to lower level units as influencing organizations, outside the ‘enterprise’ boundary,
and their directives may have the status of regulations. An enterprise BMM does not have to represent the entire
enterprise. A stakeholder can create a BMM of a partial view, referencing only those parts of the business that are
relevant to his/her responsibilities and decision-making authority.

Alignment Architecture - Business Process Management  44/55

 Appendix: Process Classification Models
Supply Chain Operations Reference Model
The SCOR model provides a framework that links business processes, metrics, best practices, and technology into
a unified structure. It is hierarchical in nature, interactive, and interlinked. The SCOR model supports supply chain
improvement by aiding the capture of an “as-is” current state from which the desired “to-be” future state can be
derived.
SCOR processes extend from your supplier’s supplier to your customer’s customer. This includes all customer
interactions from order entry through paid invoice; all product (physical material and service) transactions, including
equipment, supplies, spare parts, software, etc.; and all market interactions, from understanding aggregate demand
to the fulfillment of each order.
SCOR however does not describe every business process. It only concerns itself with the value chains, and doesn’t
include any supporting processes in its framework (such as for example HR or knowledge management). It also
doesn’t concern itself with the sales and marketing step of the Porter Value Chain. Its main purpose is to describe
your process architecture in a way that makes sense to key business partners.
The SCOR process reference model focuses on standard metrics to measure performance (Performance Metrics),
standard descriptions of management processes and a framework of process relationships (Processes),
management practices that produce best-in-class performance (Practices) and training and skills requirements
aligned with the processes, practices and metrics (People).
The SCOR performance focuses on five core supply chain performance attributes: Reliability, Responsiveness,
Agility, Costs and Asset Management. Coupled to these, it defines metrics on three hierarchical levels:
 Level 1 metrics are diagnostics for the overall health of the supply chain. These metrics are also known as
strategic metrics and key performance indicators (KPIs). Benchmarking level 1 metrics helps establish
realistic targets that support strategic objectives.
 Level 2 metrics serve as diagnostics for the level 1 metrics. The diagnostic relationship helps to identify the
root cause or causes of a performance gap for a level 1 metric.
 Level 3 metrics serve as diagnostics for level 2 metrics.

The SCOR processes are also defined in a hierarchical manner, which each level representing a sub-process of its
parent. The top level (or level 1) consists of 5 segments:
 Plan (P): The Plan processes describe the planning activities associated with operating a supply chain.
This includes gathering customer requirements, collecting information on available resources, and
balancing requirements and resources to determine planned capabilities and resource gaps. This is
followed by identifying the actions required to correct any gaps.
 Source (S): The Source processes describe the ordering (or scheduling) and receipt of goods and
services. The Source process includes issuing purchase orders, scheduling deliveries, receiving, shipment
validation and storage, and accepting supplier invoices.
 Make (M): The Make processes describe the activities associated with the conversion of materials or
creation of the content for services. It focuses on conversion of materials rather than production or
manufacturing because Make represents all types of material conversions: assembly, chemical
processing, maintenance, repair, overhaul, recycling, refurbishment, remanufacturing, and other material

Alignment Architecture - Business Process Management  45/55

 conversion processes. As a general guideline: these processes are recognized by the fact that one or
more item numbers go in, and one or more different item numbers come out of this process.
 Deliver (D): The Deliver processes describe the activities associated with the creation, maintenance, and
fulfillment of customer orders. It includes the receipt, validation, and creation of customer orders;
scheduling order delivery; pick, pack, and shipment; and invoicing the customer.
 Return (R): The Return processes describe the activities associated with the reverse flow of goods back
from the customer. The Return process includes the identification of the need for a return, the disposition
decision making, the scheduling of the return, and the shipment and receipt of the returned goods. (Repair,
recycling, refurbishment, and remanufacturing processes are not described using Return process
elements. See Make.)

A best practice is a unique way to configure a process or set of processes. This uniqueness can be related to the
automation, a technology used in the process, special skills applied to the process or a unique method for
distributing and connecting different processes. These practices are divided into four different categories: Leading
or Emerging Practices, Best Practices, Common Practices and Poor Practices.

Alignment Architecture - Business Process Management  46/55

 The final part of the equation is People. The SCOR framework provides a global view of the needs and issues
surrounding skills management for the people working with the processes in order to align these skillsets with the
strategic objectives. SCOR identifies the following key elements for these people:

 Skill: A Skill is the capacity to deliver predetermined results with minimal input of time and energy. Skills
are further defined by Experience, Aptitude, Training, and Competency levels. Examples of supply chain
skills include: master scheduling, import/export regulations, production planning, and risk mitigation.
 Experience: Experience is the knowledge or ability acquired by observation or active participation.
Experience is obtained by doing the work in a real-life environment and responding to a variety of
challenges that require different responses and actions. Example experiences include: cycle counting,
cross docking, and hazardous materials handling.
 Aptitudes: An Aptitude is a natural, acquired, learned, or developed ability to perform a certain kind of work
at a certain level. Example aptitudes include: accuracy, analytical, and leadership.
 Training: Training develops a skill or type of behavior through instruction. Examples of training are SCOR-
P certification and APICS CPIM certification. This element also includes on-the-job training.
 Competency: Competency levels describe the level or state of qualification to perform a certain role or
tasks. SCOR recognizes five commonly accepted competency levels: Novice, Experienced Beginner,
Competent, Proficient, and Expert

Process Classification Framework

APQC’s Process Classification Framework (PCF) is a taxonomy of cross-functional business processes intended to
allow the objective comparison of organizational performance within and among organizations. It serves as a high-
level, industry-neutral enterprise process model that allows organizations to see their business processes from a
cross-industry viewpoint. A general purpose framework exists, as well as more industry-specific elaborations,
containing information relevant to that industry.
The framework divides the processes in 5 levels, going from a broad process category to the individual tasks within
the process. The main focus here is to classify processes so to avoid duplicates, and a checklist of possible
processes so to verify all processes have been covered. This serves well in such analysis tasks as process
discovery. These levels are also represented in the numbering used. Each number consists of the following pattern:
<category nr>.<process group nr>.<process nr>.<activity nr>.<task nr>

An example BPM roadmap drawn up in a case study of APQC can be found in the document “Alignment
Architecture - BPM Roadmap Example”.

Alignment Architecture - Business Process Management  47/55

 Value Reference Model
With the Value Reference Model (VRM) you can begin to define the business process context for services. The
VRM supports the key issues and the gearing together of processes within and between the individual units of
chains (networks) for the benefit of Planning, Governing, and Execution (information - financial - physical flows) with
the objective to increase the performance (yield) of the total chain and support the ongoing evolution.

Strategic Level
The Top Level of the model encompasses all the high level processes in Value Chains and are represented through
the Process Categories Plan – Govern – Execute. The Level is defined to be the Strategic Level of the Model,
meaning that this is where high level decisions are made regarding how to gain a competitive advantage for the
Value Chain in scope.
An example of such a competitive advantage could be Increased Market Share through a Cost Optimized, Adaptive
Value Chain and extensive Collaboration with Customers and/ or network partners. By some this level of the model
is categorized as the C-Suite.

Tactical Level
The Second level of the model contains “abstract” processes decomposed from the Strategic Level. To implement
and fulfill the strategic goals set in the top level of the model hierarchy a set of tactics needs to be developed and
realized. Examples of such tactics can be in- or out-sourcing of activities within one - or multiple domains, change of
value chain planning such as (e.g. Sales and Operation Planning), focusing on product development to gain a
competitive advantage or changing from “push to pull” conditions for the supply network.

Operational Level
The third level of the model represents specific processes in the value chain related to actual activities being
executed. On this level focus is usually vertical business process improvements or business process re-engineering
as many name it. In a value chain perspective this is the level where fine-tuning occurs.

The Activities and Actions

These levels of granularity are not in scope of the Value Reference Model itself but present decompositions of the
VRM's third level of processes.

Alignment Architecture - Business Process Management  48/55

 Appendix: Business Process Refinement Techniques
Rummler-Brache Methodology
The most important contribution that Rummler and Brache made to the business process reengineering movement
was a single diagram, called the nine boxes model, which showed the relationship of the performance levels to each
of the performance dimensions. This has become the cornerstone of their methodology. The Three Levels of
Performance are the organization, process, and performer or people-levels. To effect change in an organization, it is
necessary to understand the potential impacts to all three levels. For example, a process change could mean
significant changes to job responsibilities and the skills required to execute those responsibilities. Failure to
adequately account for these interrelationships is a major cause of failed process implementations. The Three
Performance Dimensions are goals, design, and management. Having clear goals at each level ensures alignment
to desired results; having robust design at each level maximizes the efficiency of operations; and having good
management systems at each level ensures that the organization can survive and adapt to changes in the business
environment. A failure in any of these dimensions will also lead to performance problems.

Illustration A.4.1 – Nine Boxes Model

LEAN
Lean principles are derived from the Japanese manufacturing industry. The term was first coined by John Krafcik in
his 1988 article, "Triumph of the Lean Production System". The techniques can be traced much farther back to
ideas developed by Frederick W. Taylor, often called “The Father of Scientific Management.” In 1911, he published
his methods of applying scientific analysis and testing to manufacturing in a book called The Principles of Scientific
Management. Japanese companies used the concepts in this book to rebuild their businesses after World War II.
Among these companies, Toyota became particularly noted for its success in applying the techniques, refining them
in its automotive manufacturing process and renaming them the Toyota Production System (TPS).
Lean has been described as a manufacturing process, but it is much more than that. It encompasses all aspects of
business, including payments processing and project management as well as manufacturing. When a business
operates according to lean principles, all departments within a company work together to achieve two objectives:
 Increase the value of the product to the customer
 Reduce waste

Alignment Architecture - Business Process Management  49/55

 In the lean world, there are six kinds of waste in the manufacturing process:
 Defects: When a defective part is shipped to the customer, the customer must waste time and labor
identifying the defect and returning the defective part to the Operational Excellence Management (OEM).
The OEM's time and labor have been wasted in manufacturing the part.
 Transport: The parts the OEM ships to the customer should only be what the customer needs and should
be undamaged at the time of delivery. When these conditions have not been met, time and labor have
been wasted for the OEM and the customer.
 Timing: When the parts are shipped to the customer before the customer is ready to receive them, time,
labor, and other resources are wasted in storing the parts until they are needed. Also, when the customer
is ready to receive the part, the specifications for the part may have changed. Again, in this case, the
OEM's time and labor have been wasted.
 Waiting: This is the opposite of overproduction. When the customer must wait for a parts shipment, the
customer must divert manufacturing resources to other processes and the OEM’s time and labor are
wasted.
 Overproduction: When an OEM produces more parts than the customer wants or parts with features that
the customer does not need, the OEM's time and labor are wasted.
 Motion: To save time, the amount of effort for a worker to perform a task must be minimized. For example,
effort is wasted when there is too much distance between workstations, and a line worker must spend
more time carrying a part between them.
The application of Lean can be clearly defined in a set of principles:
 Precisely determine the customer-defined value of the product.
 Identify the product’s value stream.
 Ensure that the value flows uninterrupted through the manufacturing process.
 Establish the process so that the customer “pulls” the value from the producer.
 Continuously attempt to perfect the first four principles.
However, Lean is not a silver bullet that will always work. There always needs to be a reflection about whether the
Lean approach is sensible for the enterprise. Lean tries to improve enterprise by striving for a number of goals. If
these goals don’t match with your company values, Lean is not the methodology for you. These
goals/considerations are:
 Lean Is About Reducing the Number of Employees
 Lean Is About Making the Process Faster
 Lean Is About Making Everyone's Work Easier
 Lean Is About Reducing Inventory
 Lean works best when it is applied to all corporate operations, not only operational processes
 Lean Is Time-Consuming and Costly to Implement

Six Sigma
Six Sigma evolved from quality initiatives (TQM, etc.) and merged with process re-engineering efforts in the '90s. It
focuses on a set of statistical techniques for measuring efficiency of existing, well established processes with the
objective of making process improvements. Six Sigma generally defines three types of change efforts:
 Process management which is defined more narrowly than in the more general sense of BPM focusing on
the linkage between process and strategy in order to prioritize process change. This aspect of Six Sigma
relates to the business architecture efforts in the strategic analysis phase.
 Process improvement employs statistical techniques to incrementally improve process efficiency and
quality. This category of change effort is the primary focus of Six Sigma which techniques for organizing
teams for process improvement projects, applying statistical techniques to measure process effectiveness
and quality, and subsequent analysis of results.
 Process redesign refers to the more substantial process changes of the type that may be expected from
BPR/BRE.
At the heart of Six Sigma is a statistical analysis technique designed to identify opportunities for process
improvements by connecting processes to quality measures. More broadly it is a process improvement
methodology and governance discipline targeted toward departmental process teams. While Six Sigma does
recommend that measures should be related to strategic goals, individual projects typically focus on fine-grained
sub-processes and business activities using only a small set of targeted measures. At this level Six Sigma projects
can tackle a handful of processes for improvement in relatively short time spans (e.g. three processes every six
months), but it is not a suitable strategy for core business processes involving end-to-end value chains. That said, it
is a good introduction to the discipline of process improvement governance, albeit within departmental scope.

Alignment Architecture - Business Process Management  50/55

 This statistical analysis technique is formed into a Six Sigma project by using the DMAIC model. This model shapes
a project into 5 stages:
1. Define: The purpose of this stage is to clearly articulate the business problem, goal, potential resources,
project scope and high-level project timeline. This information is typically captured within project charter
document. Write down what you currently know. Seek to clarify facts, set objectives and form the project
team.
2. Measure: The purpose of this stage is to objectively establish current baselines as the basis for
improvement. This is a data collection step, the purpose of which is to establish process performance
baselines. The performance metric baseline(s) from the Measure phase will be compared to the
performance metric at the conclusion of the project to determine objectively whether significant
improvement has been made. The team decides on what should be measured and how to measure it. It is
usual for teams to invest a lot of effort into assessing the suitability of the proposed measurement systems.
Good data is at the heart of the DMAIC process
3. Analyze: The purpose of this stage is to identify, validate and select root cause for elimination. A large
number of potential root causes (process inputs, X) of the project problem are identified via root cause
analysis (for example a fishbone diagram). The top 3-4 potential root causes are selected using multi-
voting or other consensus tool for further validation. A data collection plan is created and data are collected
to establish the relative contribution of each root causes to the project metric, Y. This process is repeated
until "valid" root causes can be identified. Within Six Sigma, often complex analysis tools are used.
However, it is acceptable to use basic tools if these are appropriate.
4. Improve: The purpose of this stage is to identify, test and implement a solution to the problem; in part or in
whole. This depends on the situation. The purpose of this stage can also be to find solutions without
implementing them.
5. Control: The purpose of this step is to sustain the gains. Monitor the improvements to ensure continued
and sustainable success. Create a control plan. Update documents, business process and training records
as required.

Illustration A.4.2 – DMAIC Model

Evidently, these stages are geared towards process improvement and thus focus on existing processes. When
introducing new processes, Six Sigma offers the Design For Six Sigma (DFSS) methodology. DFSS seeks to avoid
manufacturing/service process problems by using advanced techniques to avoid process problems at the outset
(e.g., fire prevention). When combining this tools and techniques, these methods derive engineering system
parameter requirements that increase product and service effectiveness in the eyes of the customer and all other
people. This yields products and services that provide great customer satisfaction and increased market share.
These techniques also include tools and processes to predict, model and simulate the product delivery system (the
processes/tools, personnel and organization, training, facilities, and logistics to produce the product/service).

Alignment Architecture - Business Process Management  51/55

 Human Performance Technology

Illustration A.4.3 – Human Performance Technology Model

Human Performance Technology (HPT) is an engineering approach to attaining desired accomplishments from
human performers by determining gaps in performance and designing cost-effective and efficient interventions. This
methodology was pioneered by Tom Gilbert and originally determined the causes of these gaps into six categories
of which there is a lack:
 Consequences, incentives and rewards
 Data, information and feedback
 Environmental support, resources and tools
 Individual capacity
 Motives and expectations
 Skills and knowledge
Later on (as shown in the diagram below) a model for improving the performance was devised, based on resolving
these gap. The gap categories were expanded, as well as personalized by other authors for their proper
methodologies. And different nuances were also introduced into the equation based on the different types of
stakeholders: Customers, suppliers or employees. To close these gaps, the appropriate measures need to be
determined to address these causes. HPT attacks this issue with a phased approach:
 Analysis: The specific tasks to be performed are identified, as well as to what extent there needs to be
training or another type of performance support the job necessitates. Traditionally this is done through a
survey of the performers or through a facilitated panel of experts. The results enable the trainers to select
the tasks appropriate for training as well as the proper training methods.
 Design: The specific learning objectives (or performance objectives) are developed. Linked to these
objectives is a hierarchy of different levels and types of learning (such as stated by Robert Gagne). The
relevance of these types and levels is what we elaborate on. The idea is to deliver the training in such a
way that these types of learning (lectures, discussion, hand-on exercises…) are supported.
 Development: We develop the training based on the objectives and the types of learning that were decided
upon. This comes down to writing out the training, producing the teaching aids, etc.

Alignment Architecture - Business Process Management  52/55

  Implementation: Once the development of the training has been finalized, the trainings need to be given to
the target audience
 Evaluation: The effectiveness of the training is measured using the levels of learning evaluation pioneered
by Donald L. Kirkpatrick and elaborated by several others, as shown in the illustration.

Illustration A.4.4 – Levels of Learning Evaluation

Customer Experience Management

Customer Experience Management (CEM) mainly concerns itself with optimizing the experience customers have
with the internal processes of a business. Too often, there are parts of the process overlooked, because traditionally
we do not associate them with the process. Take for example an airline. The process for a trip entails enquiry,
collecting of bags, etc. However, for the customer, this process starts a lot earlier with the planning, picking a
transportation method to the airport, and ends much later, for example with touring the city he is visiting. This wider
view the customer has on the process, should be taken into account when optimizing it. Where Six Sigma focuses
on the process doing things the right way, CEM focuses on the process doing the right things.

Illustration A.4.5 – CEM Methodology

The methodology boils down to determining win-win situations, called successful customer outcomes, to follow this
up with running the proper process diagnostics, and based on those the process is improved.
The Successful Customer Outcomes (SCO) are determined by asking the following questions:
 Who is the customer?
 What is the customer’s current expectation?
 What is the process the customer thinks they are involved with?

Alignment Architecture - Business Process Management  53/55

  How do the things company does impact customer success?
 What does the customer really need from us?
These questions should lead to a one line statement that explains the actual SCO.
The process diagnostics effort focuses on three key indicators usually elicited through workshops:
 Moments of Truth: Any interaction with the customer; for example, a customer to person interaction, or a
customer to system interaction. These moments represent an opportunity in time in which to delight the
customer or to fail! Moments of truth should be eliminated where possible, and optimized where they have
to exist.
 Break Points: Any hand-off in the process. These represent potential points where the process could
break down. For example, transferring a phone call, or sending an email. Breakpoints are often the causes
of delays in the process.
 Business Rules: Any decision points or logic points in the process. These can add complexity, increase
effort, and be potential points of failure. Think of business rules as points in the process where you ‘must’
follow a particular way of doing things. Business rules are highly prone to obsolescence, and need to be
challenged!
Improving the process after the points of failure have been identified, is done in two simple steps: Eliminate and
Improve. Each Moment of Truth, Break Point or Business Rule represents an opportunity, both the more there are,
the more risk of failure we run. For each of these we need to consider whether to get rid of them (if possible) or to
improve them to find that balance of risk and opportunity.

Toyota Production System

Illustration A.4.6 – Concepts of the Toyota Production System

The main idea of the Toyota Production System (TPS) is to achieve the highest quality with the lowest cost in the
shortest time. For this, a successful marriage of two core concepts is proposed, namely Just-In-Time and Jidoka.
The first focusing on the idea of muda (or reduction of waste) and the latter focusing on the belief that quality checks
need to be built into each step of a process in order to optimize the quality of the products.
The principle of Just-In-Time is based on the idea of aligning production to the demand in the market. For this TPS
uses the term heijunka (or levelling the flow) where the TPS regulates in the influx of materials or assets needed for
production to arrive at the time they are needed in order to reduce inventory. Regulating the input is coupled with
Takt Time, which is the regulation of the work cycle to the demand through time planning of the worker force. In
order to have this flexibility and efficiency in our workflows, the concept of Kanban (or the pull system) is introduced
As stated, Jidoka is the practice of building in quality checks at each step of the process. Freely translated it means
automation with a human touch. Each team member in the process is responsible for quality checks of his tasks

Alignment Architecture - Business Process Management  54/55

 before passing the process along to the next step. If a problem is detected, the process is immediately halted (this is
called the andon cord, which can be pulled by any performer to halt the process), and a root cause analysis is
launched. In combination with this practice, devices or automation that make it more difficult or impossible to make
mistakes are introduced wherever possible (poka-yoke).
The root cause analysis is a group effort, and should lead to continuous process improvement. This is what TPS
calls kaizen. The first way to perform such an analysis is by utilizing an Ishikawa diagram (or fishbone diagram). We
start by listing the main cause (“Inefficient System” in the example) and drill down to the actual cause by asking the
5 Why’s. It is the guideline of TPS to ask at least 5 consecutive why‘s to get to the actual cause (Inefficient System
 Inefficient Customer Service  No Proper Customer Database  Paper-based  Low Price).

Illustration A.4.7 – Ishikawa Diagram & Pareto Chart Example

Once we map out the possible root causes in this diagram, we start collecting data to verify which of these causes is
the most likely to sit at the root of the problem. We therefor draw up these causes against the number of defects
they cause in what is called a Pareto Chart. Normally this point to an 80-20 split, hence the name of the graph. This
gives us a solid idea which root causes to address first in order to get the best return on investment.
Once the proper causes to tackle have been decided upon, the next step is to perform solution thinking on how to
prevent this cause from happening. Once our process reengineering has been finalized, we take it back into the
field by running small-scale experiments or simulations in order to detect whether or not the reengineered solution is
indeed better than the current process. When this renders a beneficial result, we deploy our new process into a
production environment.

Alignment Architecture - Business Process Management  55/55