Value Configuration Design – an Evolution in Adequate

Business Process Design

Eng Chew, Igor Hawryszkiewycz and Michael Soanes.

Department of Information Technology, University of Technology, Sydney, Australia.

{Eng.Chew, Igor.Hawryszkiewycz, Michael.G.Soanes}@uts.edu.au

Abstract. Process breadth and depth completeness is an important factor for

evaluating process design adequacy. Current process design strategies and tool-
sets poorly support the breadth and depth of business process logic resulting in
incomplete business process designs. A framework that integrates the process,
activity and resource viewpoints is proposed to address this inadequacy. This
integrated viewpoint results from refocusing business process design practice
from the traditional individual process silos towards integrated enterprise-wide
process network design. Labeled as Value Configuration Design, enterprise-
wide process design is the next evolution towards adequate business process
design. .

Keywords: business process design, adequate process design, value configu-

ration design. .

1 Introduction

This paper discusses the issue of design adequacy in the context of enterprise-wide
business process design. Process design and management is a core part of our indus-
try-practice-based process innovation research program, which stems from our re-
search group’s industry experiences.

Traditionally business process design and design adequacy tend to address a specific
business process in isolation. A business process is defined simplistically as a flow of
predictable activities that are performed by multiple resources to achieve a business
outcome.

Porter[1] introduced the concept of the value chain as a series of activities (both pri-
mary and support) that add value in contributing to the delivery of customer require-
ments. The value chain concept was later extended by Stabell and Fjeldstad[2] into
value configuration, defined as a network of value chains. Value configuration de-
notes the fact that in practice, an enterprise commonly networks with several partners
and suppliers in servicing its customers.

The value configuration models the enterprise-wide business process as a network of

inter-dependent core processes. Designing individual core business processes in isola-
tion, without the enterprise-wide view, can lead to a sub-optimal process design when
aggregated into the total value network.

Value configuration design requires a process engineering methodology which en-

sures the resultant value configuration will deliver the customer value (requirements)
in line with the business strategy. Our research aims to develop the methodology,
which will serve as a practical process innovation tool for process managers.

This paper describes part of our progress towards that goal and focuses on the issue of
design adequacy. It discusses the criteria for design adequacy and defines the concept
of process (breadth and depth) completeness as a measure of design adequacy. A
framework is also proposed to address completeness in the context of value configu-
ration design.

2 Requirements for a Process Engineering Methodology

A process engineering methodology must (a) allow process designs to be validated to

meet both the business strategic and operational requirements, and (b) define the sys-
tematic steps for designing each core process (strategic or unique and commodity) to
not only meet the specific customer value propositions articulated by the strategic in-
tent, but also be agile for ongoing changes due to the changing business environment.
From the strategic viewpoint, the methodology must validate the alignment of the
process design to the strategic intent (or value discipline): operational excellence, cus-
tomer intimacy or product leadership that the enterprise stands for, as well as any
mandatory regulatory compliance (such as Sarbanes Oxley) requirements [Kaplan &
Norton 3]. From the operational viewpoint, the methodology addresses the process
design’s functional and performance requirements, reflecting the stakeholders and,
most importantly, the customers’ requirements.

This paper focuses solely on process design adequacy from the operational viewpoint
of our methodology. Future papers will describe the complete process engineering
methodology in detail.

3 Criteria for Process Design Adequacy

The criteria used for evaluating software quality are a useful starting point as criteria
for evaluating business process design adequacy. Many variations of software quality
criteria exist. However a common thread is the division of requirements into func-
tional and non functional. [Wikipedia 4].

Analogously, we define process design adequacy from two dimensions: ‘functional’ –

referring to process completeness; and ‘performance’ referring to other quality as-
pects: understandability, conciseness, portability, consistency, maintainability, test-
ability, usability, reliability, structuredness, efficiency and security. Design adequacy
is defined as the minimum set of process functional and performance requirements
that meet the stakeholders (particularly the customers) requirements. For the purpose
of this paper, we focus specifically on the completeness (functional) dimension of
business process design as the means for measuring and implementing adequate proc-
ess design.

4 The Completeness Dimension of Business Process Design

We define business process design completeness as having two variables:

1. The minimum scope of the total suite of business processes within the value con-
figuration of an organization that is considered mandatory by the stakeholders.
This includes both primary and support processes.
2. Within each selected (core) business process, the minimum scope of activities
that must be designed as part of executing instances of a business process to meet
mandatory stakeholder requirements.

The second variable (core process design) is the more complex part of evaluating
process design completeness and is expanded in the next sections.

5 Breadth / Depth Complexity Matrix Concept

Soanes [5] introduced the concept of the breadth / depth complexity matrix to de-
scribe the inadequacy of (or lack of completeness in) individual business process de-
signs.

Production
Groupware
Workflow
Coarse Q1 Q2
Depth Complexity

Grain
Footprint of typical
process

Fine Q3 Q4
Grain
Procedural
Manual
Code

Structured Unstructured
Breadth Complexity
Fig. 1. Process Breadth / Depth Complexity Matrix
Breadth complexity is defined as the range of activity types within a business process
ranging from highly structured systemic to unstructured ad-hoc activities.

Depth complexity is defined as the abstraction levels of process logic within a busi-
ness process ranging from very coarse process logic (e.g. work passing from one re-
source to the next) to very granular process logic (e.g. navigation between fields on a
data capture screen).

Soanes proposed that the footprint of typical processes crosses multiple breadth /
depth quadrants of the above matrix. To illustrate the mapping, a simple real world
business process example was used that has a footprint that includes aspects of all
quadrants. This ranged from coarse-grain depth level, highly structured routing be-
tween human resources (Q1); coarse-grain depth level, unstructured interactions oc-
curring within an email system (Q2); fine-grain depth level, highly structured flow of
functions and screens embedded as procedural code in the transaction system (Q3);
and fine-grain unstructured (Q4) process knowledge that is manually implemented.

Soanes concluded that existing process design strategies and toolsets tend to special-
ise in one quadrant of the matrix. Given individual processes can span multiple
breadth/depth segments, this specialisation strategy can result in multiple process de-
sign strategies and toolsets being used within the one process. This means a signifi-
cant percentage of business activities performed have been excluded from the scope
of the business process design and are thus not controlled and tracked by the BPMS
implementing the business process designs. It results in inefficient and ineffective
business operations – an undesirable outcome of inadequate (core) process design.

6 Process Design Framework to Facilitate Completeness

We propose the following framework (Figure 2) as a practical method for modeling

the process breadth and depth complexities:
Process
on
os e
m p iv
iti
co urs
De Rec

Manage

Activity Resource
Fig. 2. Process / Activity / Resource / Management (PARM) framework.
The Process / Activity / Resource / Management (PARM) framework defines four
viewpoints of business processing that need to be integrated and managed as part of
the design considerations (in response to stakeholder requirements) for each core
business process:

• The Process viewpoint focuses on the controlling, guiding and restricting of the
flow of activities performed for specific process instances. Its measurable objec-
tive is to meet the customer’s end to end service delivery expectations.
• The Activity viewpoint focuses on the facilitation of an environment to manage
human activity with the recognition that human resources will prioritise their own
execution of multiple activities across multiple processes simultaneously based
upon their own individual work practices. The execution sequence is not deter-
ministic – contrary to conventional process design which assumes that activities
will be executed deterministically as prescribed by the design. Its measurable ob-
jective is to provide the most effective (both productivity and quality) environ-
ment for the completion of all work across all processes – reflecting the process
(knowledge) worker’s cognitive decision making behaviour which is unstruc-
tured.
• The Resource viewpoint forecasts, plans, schedules and assigns resources to ac-
tivities. Its measurable objective is to maximize the utilization and therefore the
efficiency of the total resource pool. This viewpoint captures the process (re-
source) manager’s requirements.
• The Management viewpoint integrates the process, activity and resource view-
points through balancing the tension between service, cost and quality expecta-
tions. It reflects the requirements of the business owner of the process.

Breadth complexity requirement is modeled by the alignment and integration of the

process, activity and resource viewpoints, with the “breadth” being accentuated by the
activity viewpoint which explicitly models both structured and unstructured behav-
iours.

The recursive decomposition of the framework parameters (an activity at one level of
abstraction can be decomposed as a process at the next lower level of abstraction), en-
ables breadth complexity to be managed at multiple levels of depth complexity.

The assignment of a resource to perform an activity on a process instance creates the

link between the process and activity viewpoints. This assignment can be an active re-
source management strategy based upon optimising a pool of resources (more appli-
cable to production workers), or can be a passive resource management strategy based
upon individual resources prioritising their own assignments (more applicable to
knowledge workers).

Process design completeness is achieved through a consistent and integrated approach

to modeling and managing the process, activity and resource viewpoints.

The management viewpoint integrates the process design into the business strategy.
Decomposition of the business strategy into measurable objectives provides the pa-
rameters for balancing the tension between the process viewpoint objectives (service),
activity viewpoint objectives (effectiveness) and resource viewpoint objectives (utili-
sation).

Traditional process design strategies and BPMS toolsets are inadequate as they tend
to focus only on the process viewpoint and seldom include the activity and resource
viewpoints. Activities are an essential part of process design strategies. However the
existing prescriptive toolsets cannot model the non-deterministic less structured ac-
tivities.

Furthermore, there is poor support for the resource viewpoint. Most BPMS tools will
support simulation as a means of identifying the optimisation of resource allocation.
However as Reijers and van der Aalst [6] highlight, a simulation model typically fo-
cuses on a single process while the people involved distribute their time over multiple
processes.

7 PARM Framework Implementation

A new process engineering methodology (and associated BPM tool) is required that
supports a process designer using the PARM framework to ensure adequate value
configuration design. It is a core part of our on-going research program at UTS. Its
detailed solution, however, is outside the scope of this paper which aims to address
practical design issues and introduce the new integrated concepts. Below we highlight
some existing initiatives that address various aspects of the PARM framework re-
quirements.

van der Aalst et al [7] describes case handling workflow as "a new paradigm for sup-
porting flexible and knowledge intensive business processes.” Case handling work-
flow is characterised by defining what can be done to achieve a business goal with the
knowledge worker actively deciding how to reach that goal.

Process mining’s goal is to reverse engineer a process model from activity event logs.
van der Aalst et al [8] proposes that to allow for operational flexibility, workers
should be allowed to deviate from the pre-specified process design (they use the term
“workflow”). Process mining is then proposed as a means of providing a feedback
loop that monitors actual deviations to adapt the process design to changing circum-
stances and detect imperfections in the design.

Many parties (eg Enix [9]) are proposing the integration of BPM and the business
rules approach (as advocated by Ross [10]) as a key future development in addressing
unstructured exceptions within structured process flows.

Case handling, process mining and the business rules approach integration with BPM,
are examples of attempting to address breadth / depth complexity by extending the
process viewpoint.
Activity theory is the basis of a number of initiatives that focus on the activity view-
point. Activity theory is defined by Adams et al [11] as “a powerful and clarifying de-
scriptive tool focusing on understanding human activity and work practices…”

Adams et al leverages activity theory principles to propose the concept of worklets as

“a repertoire of self-contained sub-processes that can be applied in a variety of situa-
tions depending on the context of the particular work instance.”

Human Centred Work System Design is an initiative by NASA to define processes for
the Mars mission based upon activity theory principles. Sierhuis and Clancey [12]
state “the notion of a human-centered work system is one based on work practice, i.e.
what people actually do, as opposed to a machine-centered approach that tends to fo-
cus on the flow of products and work through a work system often ignoring the way
people in the organisation prefer to work. ”.

Harrison-Broninski [13] has introduced the concept of Human Interaction Manage-

ment (HIM). He states that “current mainstream techniques and tools for work sup-
port…deal only with "mechanistic" business processes. HIM extends this to include
support for "human-driven" processes focused on human creativity and collabora-
tion”.

Within the BPM domain, best practice for resource management is the simulation ap-
proach. It is recognised that there is a need to address the resource viewpoint within
BPM as per Russell et al’s [14] definition of the resource patterns associated with
BPM. Apart from the progress commercial vendors have achieved with resource op-
timisation (e.g. SAP in the enterprise resource planning domain), there are interesting
developments in many diverse areas such as Grid computing [Buyya 15] that could be
applicable to the BPM domain.

It is envisaged that our evolving process engineering methodology will be developed

from an integration and adaptation of existing initiatives and best practices to achieve
the multiple viewpoints of the PARM framework.

8 Conclusion

It is proposed that process breadth and depth completeness is a major evaluation crite-
rion of adequate process design. Completeness is restricted by the current process de-
sign strategies in their inability to address the breadth and depth of business process
logic.

The PARM framework is proposed to overcome these limitations. It allows business

process owners to holistically manage and integrate the process, activity and resource
viewpoints in line with stakeholder requirements.
This in turn requires moving beyond the traditional approach of designing and manag-
ing individual business processes in isolation towards an integrated view of process,
activity and resource. This integrated view is labeled “value configuration design”, in
reference to the broader goal of configuring the total value network of multiple proc-
esses consisting of overlapping and independent activities with resources multitasking
across multiple activities simultaneously.

The future work is to fully develop a total process engineering methodology and BPM
tool that incorporates a value configuration design architecture, modeling approach
and implementation requirements. This will most likely be an integration and exten-
sion of a number of existing initiatives that are already attempting to address the
breadth / depth complexity challenge.

References

1 Michael E. Porter. Competitive Advantage 1985.

2 Stabell and Fjeldstad. Configuring value for competitive advantage. On chains, shops and
networks. Strategic Management Journal 1998 Volume 19 Number 5 pages 413-417.
3 Kaplan and Norton. The Strategy Focused Organization. September 2000.
4 Software Quality Factors at http://en.wikipedia.org/wiki/Software_quality
5 Michael G. Soanes. Process Design Strategies to Address Breadth and Depth Complexity.
4th International Conference, BPM 2006. September 2006.
6 H.Reijers, W.Van Der Aalst. The effectiveness of workflow management systems: Predic-
tions and lessons learned - - International Journal of Information Management, 2005.
7 W.M.P. van der Aalst, M. Weske, and D. Grunbauer. Case Handling: A New Paradigm for
Business Process Support. Data and Knowledge Engineering, 53(2):129—162, 2005.
8 van der Aalst, W. M. P.; van Dongena, B. F.; Herbst, J.; Marustera, L.; Schimm, G.; Wei-
jters, A. J. M. M. Workflow mining: A survey of issues and approaches. Data & Knowledge
Engineering, Volume 47, Issue 2 , November 2003, pages 237-267. Elsevier.
9 Enix Consulting Limited. Business Rules are from Mars and Processes from Venus at
www.enix.co.uk.
10 Ronald G. Ross. Principles of the Business Rules Approach. 2003.
11 Michael Adams, David Edmond and Arthur H. M. ter Hofstede, 'The Application of Activity
Theory to Dynamic Workflow Adaptation Issues', In The Seventh Pacific Asia Conference
on Information Systems (PACIS-2003), July 2003, Adelaide, Australia, p 1836 - 1852.
12 M. Sierhuis and W. J. Clancey, Modeling and Simulating Work Practice: A human-centered
method for work systems design, IEEE Intelligent Systems, vol. Volume 17(5), 2002.
13 Harrison – Broninski. Human Interactions – the heart and soul of business process manage-
ment. 2005.
14 Nick Russell, Wil M.P. van der Aalst, Arthur H.M. ter Hofstede, and David Edmond,
Workflow Resource Patterns: Identification, Representation and Tool Support, Proceedings
of the 17th Conference on Advanced Information Systems Engineering (CAiSE'05) , vol-
ume 3520 of Lecture Notes in Computer Science, pages 216-232. Springer-Verlag, Berlin,
2005.
15 D.P. Spooner, J. Cao, S. A. Jarvis, L. He, and G. R. Nudd. Performance-aware Workflow
Management for Grid Computing. The Computer Journal, Oxford University Press, London,
UK, 2004.