SERVICE-ORIENTED BUSINESS PROCESS MANAGEMENT

Václav Repa

University of Economics, Prague, W.Churchill sqr. 4, Prague, Czech Republic

Keywords: Business Process Management, Service Level Agreement, Process Modelling.

Abstract: This paper deals with the role of the concept of services in the area of Business Process Management and

Reengineering. It describes the process of the Business Processes System Design which is a part of the

Methodology for Business Processes Analysis and Design. The paper argues in support of thinking in terms

of services as being much more useful and the general principle to be limited to the area of technology and

software systems development only.

1 INTRODUCTION - BUILDING

PROCESS MANAGED

ORGANIZATION

This paper describes the process of the Business

Processes System Design which is a part of the

Methodology for Business Processes Analysis and

Design – MMAPB. The design technique covers the

whole process from the identification of the basic

activities to the design of key and supporting

processes as late as the building of the resulting

infrastructures. The tools used by the methodology

are based on common standards BPMN (BPMN,

2006), UML (UML, 2004), and Eriksson/Penker

Notation (Eriksson and Penker, 2000). The root of

the methodology is defined in the formal meta-

model (

Repa, 2000) as a part of the development

project OpenSoul (

OpenSoul, 2000). The key ideas of

the modelling method are described in (

Repa, 2008),

and (

Repa, 2004).

A very important tool in the structuring of the

processes is the principle of services. It allows us to

discover the basic supporting processes in the bodies

of key processes, their clarification with the exact

definition of the interfaces between processes, and,

finally, the exact definition of the needs and

possibilities of the supporting infrastructures.

The paper argues in support of thinking in terms

of services as being much more useful and the

general principle to be limited to the area of

technology and software systems development only.

The first complete explanation of the idea of process

management as a style of managing an organization

has already been published (Hammer and Champy,

1993). The authors excellently explain the historical

roots, as well as the necessity, of focusing on

business processes in the management of the

organization. The major reason for the process-

orientation in management is the vital need for the

dynamics in the organization’s behaviour. It has to

be able to reflect all substantial changes in the

market as soon as possible. The only way to link the

behaviour of the organization to the changes in the

market is to manage the organization as a set of

processes principally focused on customer needs. As

customer needs are constantly changing, the

processes in the organization should change as well.

That means that any process in the organization

should be linked to the customer needs as directly as

possible. Thus, the general classification of

processes in the organization distinguishes mainly

between:

 Key processes

, i.e. those processes in the

organization which are linked directly to the

customer, covering the whole business cycle

from expression of the customer need to its

satisfaction with the product / service.

 Supporting processes

, which are linked to the

customer indirectly - by means of key

processes which they are supporting with

particular products / services.

Whilst the term ‘’key process’’ typically covers

whole business cycle with the customer - it is

focused on the particular business case; the

supporting process is typically specialized just to the

particular service / product, which means that its

product is more universal - usable in a number of

284

Repa V. (2009).

SERVICE-ORIENTED BUSINESS PROCESS MANAGEMENT.

In Proceedings of the International Conference on Knowledge Management and Information Sharing, pages 284-287

DOI: 10.5220/0002299302840287

 SciTePress

business cases. This approach allows the

organization to focus on the customers and their

needs (by means of the key processes), and to use all

the traditional advantages of the specialization of

activities (by means of the supporting processes) at

the same time. Key processes play the crucial role -

by means of these processes the whole system of

mutually interconnected processes is tied together

with the customers’ needs. Supporting processes are

organized around the key ones, so that the internal

behaviour, specialization, and even the effectiveness

of the organizations’ activities are subordinated to

the customers and their needs.

Such a view of the behaviour of the organization

is quite different from the traditional one. Mainly,

the key processes represent an unusual view of

communications and collaboration within the

organization. In traditionally managed organizations

the organization structure reflects just the

specialization of work; it is static and hierarchical.

The concept of key processes brings the necessary

dynamics to the system – key processes often

change according to the customer needs, while

supporting ones are relatively stable (the nature of

the work is relatively independent of the customers’

needs). At the same time, the key processes

represent the most specific part of the organizations’

behaviour, while the supporting ones are more

general and standard. Thus, the supporting processes

are the best candidates for possible outsourcing

while the key ones should be regarded, rather, as an

essence of the market value of the organization. So,

we have a system of processes with very different

“speeds”. To ensure the necessary communication

among them, we need to have the interface working

like a differential gear. Firstly, we need to define the

parameters of each connection point of two

processes with respect to both sides of this relation –

as the service offered by the supporting process to

the supported one. This way the idea of a process

managed organization perfectly fits the idea of the

service-oriented structure of a system.

2 THE PROCEDURE

Figure 1 expresses the procedure of the business

processes system design as a set of succeeding /

parallel steps.

In following paragraphs, some details of the

particular steps are described.

1. Analysis of the existence of

necessary activities

and their ordering

in the context of the key processes;

Uncovering key processes

(thick version)

3. Thinning key processes - getting off all actions which can

be regarded as a standalone supporting process –

Identifying supporting processes

Tuning the system of processes.

Key vs. Supporting processes, refining the Global process Model

5. Detailed description of the

interface

among processes

(

SLA

)

Tuning the processes

detailed description.

Revision of the key processes,

their events, and reactions..

Building resulting infrastructures

System of roles, responsibilities, rights, productivity evaluation, quality evaluation

and control, organization elements, etc. etc. etc. etc. etc. …………….

Figure 1: Procedure of the business processes system

design.

2.1 Step 1: Analysis of the Existence of

Necessary Activities

In this step, the basic natural sequences of activities

are revealed. The main subject of interest in this step

is the natural succession of activities in the regular

form as people know them, work flows, legal

procedures etc. These sequences of activities serve

in later steps as the basis for revealing the proper

structure of the process system. Necessary activities

(and their basic causal consequences) form the basis

of the supporting processes. At the same time, they

are the roots of the key processes as well. Thus the

given set of natural activity sequences will be

restructured in order to identify the key and

supporting processes.

2.2 Step 2: Uncovering the Key

Processes

The aim of this step is to show the key processes.

Each key process represents, in fact, the way of

achieving the key type of product. The structure of

the key process can, thus, be derived from the life

cycle of the key product, as a final result of the

process. The key process is a process by which the

organization realizes some external value – value for

its customers.

For example, it is obvious that the key product of

the university is education. That means that the key

process of the university is the education process.

On the other hand, the key product of the university

is obviously not the Study program accreditation as

it does not realize any external value in itself – it

rather helps the key process; ‘education’; to realize

the value of education.

In the first version of the model, the key

processes naturally contain a number of supporting

activities and sub-processes (contextually). It is the

SERVICE-ORIENTED BUSINESS PROCESS MANAGEMENT

285

important task for following steps to free key

processes of all supporting activities (see below).

2.3 Step 3: Thinning Key Processes

Every key process is naturally “long” because it

covers the whole business case from the

identification of the customer need till the

satisfaction of this need by the product (service). As

a result, the previous step has shown that the key

processes are also “thick” – they contain a number

of supporting activity chains. This step strives to

remove, as much as possible, the supporting

activities from the key processes. We are speaking

about the “thinning” of the key processes.

All action chains which can be regarded as

supporting chains, arise from the key processes on

the principle of „outsourcing“ them into standalone

supporting ones (even, possibly, outside the

organization): Any relatively standalone,

continuous, homogenous, and generalizable part of

the process will be removed from the key process,

generalized, and established as a supporting process.

As a result of this removal some control activity

(managing the supporting service delivery) remains

in the key process in the original place of the

removed supporting activity chain.

In the step 5, the interface to the original

(mother) key process will be described including the

basic parameters of the product / service (see the

principle of SLA below).

2.4 Step 4: Tuning the System of

Processes

After thinning the key processes it is necessary to

rework and elaborate models in detail, and complete

the structure of the Global process model. In the

previous step, new supporting processes were

discovered, and the structure of each key process

was simplified, consequently. The content, as well

as the structure of the Global process model, has

been changed and new interfaces among the

processes have been created.

2.5 Step 5: Detailed Description of the

Interface among Processes

Interfaces among processes, which have arisen in the

previous two steps, must be elaborated in detail.

Great attention should be paid to the interface

among key and supporting processes.

In this step, every interface is described in the form

of „SLA“ (Service Level Agreement – see following

paragraph for details).

2.6 SLA (Service Level Agreement)

Under the term SLA, we mean an analogy to the

Service Level Agreement widely used in

outsourcing relationships. This form of agreement

represents the universal view of any co-operation

interface. This view is naturally compatible with the

need for financial evaluation of services, building

the system of productivity and quality metrics, etc.

Every SLA should contain:

 Product description (service characteristics, its

meaning, value, sense);

 Basic product parameters in measurable units;

 Product quality metrics (how to measure quality

as a general product attribute);

 Product “price” which reflects the necessary

costs of the supporting process or offered

service.

In fact, such a description of the interface

between two processes represents the real business

agreement of these processes. It means that there is

no difference between the “internal” (see step 3

above), and the real, outsourcing. Thus, this way of

thinking perfectly prepares the situation for the

possible outsourcing of all supporting processes

where it is suitable.

2.7 Step 6: Tuning the Processes’

Detailed Description

Parallel to step 5, the revision of the key processes

run, their events, reactions, and tuning of this

description with the Global model, should be

performed. Models are completed with actors,

inputs, outputs; and overall revision of the Global

model of processes is made in this step.

2.8 Step 7: Building the Resulting

Infrastructures

The final step of the procedure represents the

interface to the subsequent activities of the

organization building process. This step consists of

the elaboration of the process interface in order to

analyze the possibilities for realizing the service

which the supporting process represents (the

supplier part of the SLA).

Activities of this step lead to the creation of both

main infrastructures:

KMIS 2009 - International Conference on Knowledge Management and Information Sharing

286

 the basic requirements for the organizational

infrastructure are analyzed with the definition

of roles, their responsibilities, communication

procedures, and other organizational aspects

which follow on from the mutual

competencies of both attendees of the business

relation represented by the SLA;

 Similarly, the technical infrastructure needs can

be specified this way (necessary production

and workflow technology support, as well as

the necessary Information System services).

3 CONSEQUENCES AND

CONCLUSIONS

This paper discusses the concept of services in the

light of Business Process Management and the

Reengineering phenomenon. The paper just outlines

some basic contingencies which follow on from the

inspiration by the theory of services in the area of

process management. It points out the significant

similarities among different areas of possible

application of the “service-oriented thinking”, such

as software development, process management,

outsourcing, etc. It also points out the obvious

convergence of all these phenomena – outsourcing

as an original area of the SLAs is the principal way

of recognizing the substantial differences between

the key and supporting processes which, at the same

time, directly corresponds to the need to tie the

system of business processes in with the enterprise

strategy on one hand, and with the supporting

technology on the other hand.

The basic conclusion from the previous

paragraph is: the concept of services should be

regarded as a general principle for recognizing the

interface between two substantially different areas

connected with some common sense. This paper

shows how this concept works as a guide for

specifying the interface between the various types of

processes (key versus supporting ones) which differ

mainly in the reasons and “speed”, and are mutually

asynchronous. It also shows how this principle can

be used for specifying the interface between the

system of processes and supporting infrastructures

(technology as well as organization). A similar area

of application of this principle is the interface

between the strategic activities and process

management of the organization which is not

presented in this paper. This interface is the main

subject of the work of R.Kaplan and D.Norton

(Kaplan and Norton, 2004). Their theory could be

also significantly extended this way.

SLA, as a principle, rather than a universal way

of defining details of this interface – measurable

parameters of the service.

The paper also describes basic procedure for

analyzing and designing the system of business

processes in the organization with respect to the

consequential activities (Building the resulting

infrastructures). In this way, it outlines what should

be an area of future development of the

methodology.

ACKNOWLEDGEMENTS

The work presented in this paper is supported by

Czech project GAČR 402/08/0529 Business Process

Modelling.

REFERENCES

BPMN, 2006. Business Process Modeling Notation

Specification, OMG Final Adopted Specification,

February 2006, dtc/06-02-01

(http://www.bpmn.org/Documents/OMG Final

Adopted BPMN 1-0 Spec 06-02-01.pdf)

Eriksson, H.E., Penker, M., 2000. Business Modeling with

UML: Business Patterns at Work, Wiley, 2000, ISBN

978-0-471-29551-8.

Hammer, M., Champy, J., 1993. Reengineering the

Corporation: A Manifesto for Business Revolution.

London: Nicholas Brealey Publishing.

Kaplan, R.S., Norton, D.P., 2004. Strategy Maps:

Converting Intangible Assets into Tangible Outcomes,

Harvard Business School Press.

OpenSoul, 2000. OpenSoul Project

(http://opensoul.panrepa.org)

Repa, V., 2000. Business System Modeling Specification:

http://opensoul.panrepa.org/metamodel.html

Repa, V., 2004. Business Processes and Objects in an

Information Systems Development Methodology. In:

ABRAMOVICZ, Witold (ed.). Business Information

Systems – BIS 2004. Poznan . Wydawnictwo

Akademii Ekonomicznej w Poznaniu. ISBN 83-7417-

019-0.

Repa, V., 2008. Process Dimension of Concepts. In:

JAAKKOLA, H., KIYOKI, Y., TOKUDA, T.

Information Modelling and Knowledge Bases XIX.

Amsterdam. IOS Press. ISBN 978-1-58603-812-0.

ISSN 0922-6389.

UML, 2004. UML Superstructure Specification, v2.0

document 05-07-04, Object Management Group.

SERVICE-ORIENTED BUSINESS PROCESS MANAGEMENT

287