PROCESS MODELLING FOR SERVICE PROCESSES
Modelling methods extensions for specifying and analysing customer integration
Karsten Klose, Ralf Knackstedt, Jörg Becker
European Research Center for Information Systems, University of Muenster, Leonardo-Campus 3, Münster, Germany
Keywords: Service Processes, Customer Integration, Method Engineering, Business Process Management, Outsourcing,
Contract Formulation
Abstract: Service Provider business processes require extensive customer participation. Due to the customer’s
substantial impact on the successful implementation of performance processes, measures of customer
interaction must be planned meticulously. At present, there are numerous modelling techniques for a model-
based structuring of these processes. Admittedly, most of these models provide only general operations for
model modifications such as the ability to delete and add elements. This paper demonstrates possible
extensions for process modelling techniques which are intended to assist service providers in analysing their
processes with particular regard to customer integration and contract formulation.
1 INTRODUCTION
Active customer participation is one of the most
important success factors in service processes
(Lasher & Ives & Jarvenpaa, 1991; Henderson,
1990; Fließ & Kleinaltenkamp, 2004). Strictly
speaking, without customer participation, services
processes can not take place (e. g. Fließ &
Kleinaltenkamp, 2004; Chase, 1978; Lovelock &
Young, 1979) because it is essential for service
providers to integrate external factors in order to
accomplish their service processes. Service
providers are inevitably dependent on customer
information about their service requirements.
Furthermore, they often depend on additional
external factors such as human resources, legal
rights, and the assets at their disposal (Fließ &
Kleinaltenkamp, 2004; Kelly & Skinner & Donelly,
1992).
Consequently, one of the most important goals
for service providers is to ensure an appropriate
customer integration in service processes (Palmer &
Cole, 1995). The foundation of successful customer
integration is already determined within the pre-
contract phase and at the point, where the service
contract is concluded. At this very early point of
time, service providers and customers have to
negotiate and define exactly how the service process
is going to be accomplished. However, contract
formulation is a complex task, because a broad
variety of experts from different academic
disciplines (e. g. law, business administration, and
information technology) are involved. Therefore, the
aim of this paper is to develop a methodological
support for the specification and analysis of
customer activities in business processes of service
providers, which also supports the appropriate
definition of service contracts. For that reason, we
combine the Event-Driven Process Chains (EPC)
(Scheer, 2000; Nüttgens & Rump, 2002; Nüttgens &
Rump, 2003) from the information research area and
the ServiceBluePrinting approach (Fließ &
Kleinaltenkamp, 2004; Kingman-Brundage, 1989;
Kingman-Brundage & George & Bowen 1995;
Shostack 1982; Zeithaml & Bittner 1996) from
marketing research forming an integrated method.
The remainder of the paper is organised as
follows. Section 2 presents our modelling methods
extensions to support the specification and the
analysing of customer integration. Section 3
illustrates the applicability of our approach by
analysing experience from a project where the
method has been applied. Finally, conclusions are
presented in Section 4.
2 MODELLING METHOD
EXTENSIONS
Our approach aims to provide a checklist-based
preparation of process models. It comprises of
260
Klose K., Knackstedt R. and Becker J. (2005).
PROCESS MODELLING FOR SERVICE PROCESSES - Modelling methods extensions for specifying and analysing customer integration.
In Proceedings of the Seventh International Conference on Enterprise Information Systems - DISI, pages 260-265
Copyright
c
SciTePress
specific components presented below, that extend
common process modelling techniques. Hence, we
contribute to process modelling method
development. The following components feature
suitable rules for the above-mentioned area of
additional problem-solving techniques. The most
important components and their relationships are
illustrated in the meta model in Figure 1. This
Entity-Relationship-Model is a meta model, because
it describes linguistic extensions of process
modelling methods. The most important components
are:
Segmentation
schema
(S)
Seg-PME-
Ass.
(0,n)
Segment
(Seg)
S-Seg-Ass.
(2,n) (1,1)
Central question
(CQ)
Seg-CQ-Ass.
(1,n)
(0,n)
Process model
element (PME)
(0,n)
(0,n)
Segment
structure
(0,n)
Segment group
(SegGrp)
Seg-SegGrp-
Ass.
(0,n) (1,n)
SegGrp-
CQ-Ass.
(1,n)
(0,n)
Figure 1: Meta model for a methodical extension of
process models
Segmentation schema: In order to facilitate an
appropriate process analysis, specifications for
segments of process models have to be developed.
The design of these segmentation schemas is
essential for a theoretical foundation of the
checklists provided. For example, from a knowledge
management perspective, it is highly relevant to
distinct function in terms of data created, data
stored, data distributed or data used. At least, a
segmentation schema has to distinguish two
segments. Each segment belongs exactly to one
segmentation schema. A segmentation schema can
be suitable for more than one perspective. In turn,
one perspective can access several segmentation
schemas. The segmentation structure expresses that
segments can comprise other segments. Whereas
segments structures are used to depict refinement
relationships, segment groups allow for
miscellaneous compositions of segments.
Central Questions: Checklists are compound of
central questions that provide process analysts with
design options. In context of knowledge
management, for example, central questions have to
ask if data stored by a specific function is used in
other functions as well. Central questions are
assigned to segments or segment groups. Central
questions that simultaneously address different
process modelling areas are predestined for an
assignment to segment groups. All central questions
of a segmentation schema result in a perspective
specific checklist.
Assignment of segments to process model
elements: By means of an assignment of segments to
process model elements checklist are linked to
process models. For example, the assignment can be
realised through a direct or indirect attribution of
process model elements. In case of a direct
attribution, segment descriptions are used as
attribute values of process model elements. In case
of an indirect assignment, rules are defined and
computed which derive the corresponding segments
through origin process model attribute values which
are used independently from our approach for other
purposes of process modelling.
According to the meta model in Figure 1,
corresponding segments must be identified that
constitute the segmentation schema. Appropriate
perspectives on customer activities are presented in
different theoretical concepts from marketing theory.
For a bilateral consideration of a business
relationship, we propose the following distinction
(see Figure 2).
Firstly, it must be determined which activities are
perceived as corporate internal opposed to
external. This is reflected by the outsourcing
/make-or-buy decision. In the ServiceBlue-
printing approach this distinction is regarded in
Front-
office
Facility
Prepa-
ration
Support
Front-
office
Service provider
or company internal
(standardization)
(stakeholder)
comprehensive
(stakeholder)
individual
Beyond perception
of business partner/
stakeholder
Outsourcing/
Make or Buy
Facility
Prepa-
ration
Support
Customer
or company external
(standardization)
(stakeholder)
individual
(stakeholder)
comprehensive
Beyond perception
of business partner/
stakeholder
potential or
execution
Visible Visible
potential or
execution
Figure 2: Segmentation schema for customer integration management.
PROCESS MODELLING FOR SERVICE PROCESSES - Modelling methods extensions for specifying and analysing
customer integration
261
the line of interaction.
Within a bilateral business relationship, both
from the company’s point of view and from that
of the business partner, it must be decided
whether activities are executed individually for
each business partner or comprehensively for all
business partners. Standardization aspects affect
all business relationship participants (Service-
Blueprinting line of order penetration).
In case of comprehensive processes, a distinction
must be drawn between potential processes
(ensuring the company’s operating capability)
and execution activities that establish
performance processes. Potential processes are
called facility processes; execution activities are
called preparation processes (ServiceBlue-
printing line of implementation).
Individual stakeholder processes can be
differentiated with respect to their reference to
customers. Direct customer-contact activities are
so-called front-office processes; activities
without direct customer contact are called
support processes (ServiceBlueprinting line of
visibility).
The decision as to whether to make activities
visible is not solely limited to the business
partner under consideration. The visualization of
comprehensive activities between partners has to
be considered as well. For each activity, it is
necessary to record which activity aspects are
visible to the business partner and how this
visibility is to be established organisationally and
technically. Activities with direct business
partner contact are visible per se. As opposed to
other categorisation approaches, Figure 3
emphasises the orthogonal relationship between
visibility and standardization. In the bilateral
case, this question should be answered both from
the company’s point of view and from that of the
external partner. In the case of considering
another business partner, the question of
visibility must always be discussed individually
with each respective business partner.
Furthermore, a distinction must be made between
activities that are visible by themselves and those
that become visible through information
activities regarding to certain aspects.
Since the customer depicted on the right side of
Figure 2 may maintain customer relationships on his
own, the provider aspects are reflected on the
customer side. Hence, the same segments count for
this aspect.
The question of institutionalising functions at a high
level of granularity has already been addressed,
where the decision on outsourcing or make-or-buy
was elaborated. Within the scope of designing a
company organization structure, this question has to
be addressed further at a lower level of granularity.
Thus, further differentiations of the company’s
organization structure are not made here.
The questions appear in related approaches,
especially in form of ‘shifting the lines’ which
define the boundaries of the different areas of
activity (Fließ & Kleinaltenkamp, 2004). Table 1
contains an excerpt of the decision terms for
different areas of activity proposed in the
segmentation schema. For the purpose of this paper,
the below-listed questions focus on the perspective
of IT service providers. Likewise, central questions
for the remaining area of activities can be posed.
Examples for the appliance of the questions are
given in Section 3.
Table 1: Excerpt of central questions for analysing
customer activities in service processes
Segment Customer Activities
In which customer processes does the service provider wish
to participate? Which is the relevant customer process that is
to be supported by the service provider?
Which specific tasks of customer processes are to be
provided by the service provider? Is cooperation with other
companies necessary or reasonable in order to map the
complete customer process?
Which activities in the performance creation process are
adopted by the customer?
What is the impact of customer involvement on the process?
Where do problems occur if customers do not contribute in a
required timely, qualitative and quantitative manner (e. g.
service requirements and other information)?
How can adequate customer involvement be accelerated to
simplify provider planning activities (e. g. by timely
contribution demands)?
How can customer involvement be simplified from the
customer perspective (e. g. by pooling customer activities in
a timely manner and on-site)?
Must the division of work between provider and customer to
be changed (shifting of line of outsourcing / make-or-buy)?
How can the deployment of communication channels and
media (e. g. internet portals, call centres) at the customer
interface be improved?
Which customer contact channels and media are to be
offered to which customer groups at what stage of market
transaction?
Are the number and quality of customer interaction points
adequate or to be improved?
What customer data is to be collected from which interaction
channel?
ICEIS 2005 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
262
Segment Front-office Activities
Where is the process line of visibility towards the customer?
Are activities that are perceived as relevant, visible to
customers?
What is the (estimated) customer judgement on visible
activities? What data is to be collected in what form to
evaluate visible activities from the customer perspective?
Which aspects of front-office activities should be visible to
customers?
Which channels (internet, phone etc.) should be used to
provide customers with the required information? Should a
push or pull principle be used?
Segment Support Activities
How is customer data to be evaluated and managed so as to
utilise them for subsequent processes?
What are internal coordination problems?
between customer contact and support staff?
with regard to the cooperation of support staff?
with regard to the cooperation of front-office staff?
How can internal cooperation be improved? What types of
coordination functions and systems are necessary or
reasonable (e. g. access to shared databases)?
Is the centralisation or decentralisation of certain tasks
preferable?
Which organisational unit is to be associated to these tasks?
Which aspects of front-office activities should be visible to
customers?
Which channels (internet, phone etc.) should be used to
provide customers with support activities that have been
made visible? Should a push or pull principle be used?
Should support activities be relocated?
In order to facilitate the application of our approach,
a process modelling technique must be selected and
integrated into the segmentation schema. In this
context, the EPC has been selected. EPCs are
directed graphs which comprise three basic elements
(functions, events and logical connectors) indicating
the control flow (Scheer, 2000). In addition to basic
notation objects, EPCs can easily be enriched with a
large number of additional objects (e. g.
organizational units, application systems, and
outcomes) which leads to the extended event-driven
process chain (eEPC). Various extensions of the
EPC can be found in specific domains such as
knowledge and document management, e-
Government, or risk management (Nüttgens &
Rump, 2002; Nüttgens & Rump, 2003). We apply
the following widley-used extensions in our
approach (cp. e.g. Scheer, 2000):
An application system is a piece of software
supporting a certain function.
An organisational unit represents any type of
organizational entity found within a company,
for example within subsidiaries, divisions,
departments, or special project teams.
A detailed function refers to a more detailed
model. It is used with regard to the readability of
process models.
Additionally, specific extensions with regard to the
analysis and specification of customer activities
have to be made:
Segments (and their corresponding areas of
activity) extend the conceptual aspects of the
eEPC for a proper analysis of customer activities.
Each function of the EPC is a specialization of
‘process model element (PME)’ of our meta
model in figure 1. In consequence, business
process functions can be divided in specific
segments building up the areas of activity. The
above-mentioned detailed functions are generally
not assigned to a specific area of activity,
because the underlying detailed models may be
segmented into different areas of activity.
As business relationships initiate the negotiation
and formulation of contracts, business process
models can also be used as a sound basis for the
structuring and formulation of contracts.
Especially complex business processes require
time-consuming pre-contract, completion and
post-contract phases involving experts from
different working areas and scientific domains
(such as business administration, information
technology, and law). As a result,
communication problems and ambiguities arise,
which can be handled by business process
models. Using business process models as an
attachment to contracts provides an appropriate
communication tool and a structured procedure
for the negotiation and formulation of contract
paragraphs. Therefore, (contract) paragraphs are
assigned to functions of the process models.
Thus, we extended the meta model of the eEPC
by the entity type ‘paragraph’ and the
relationship type ‘paragraph structure’.
For the application of the extension, corresponding
notation constructs are needed both for segments and
paragraphs. We propose to illustrate the activity
areas by means of the swimlane notation which
leads to a segmentation of business processes
(Scheer, 2000). Alternative notations could also use
different colours for an alignment to segments (each
colour representing a specific area of activity). To
represent paragraphs we used rectangles including
paragraph symbols and numbers which refer to a
detailed description of the underlying contract
clauses.
PROCESS MODELLING FOR SERVICE PROCESSES - Modelling methods extensions for specifying and analysing
customer integration
263
3 UTILISATION OF THE
APPROACH
The application of our approach can be structured
into four phases. During the first phase, as-is models
of service provider’s business processes are
generated. For this purpose, a business framework
should be used. Moreover, existing contracts of the
company have to be investigated as they determinate
the as-is situation. Based on the framework and on
the exiting contracts, as-is business processes can be
identified and documented. In Phase 2, an analysis
of the business process models takes place with
special attention to customer activities. In this phase,
business process designers are supported by means
of the central questions catalogue which has been
developed. By answering these questions, process
designers are effectively assisted in identifying
strengths and weaknesses in their customer
processes. Based on both, the answers to the central
questions and the created as-is models, to-be models
can be created, that allow for higher levels of
customer-integration in each area of activity in phase
3. The to-be models are on the one hand the
foundation of the final implementation phase,
because they represent the requirements definition of
business processes to be implemented in the
information systems. On the other hand, they can be
used for the contract negotiation and design between
the service provider and customer.
Our method for customer integration has been
applied at a medium-sized IT service provider which
offers broad IT infrastructure support for its
customers on such areas as acquisition, installation
and maintenance of hard and software, configuration
of networks, and IT consulting in general. For the
most part, the customers (currently 550) are tax
consultancies, solicitors, management consultancies,
wholesaler, and retailer. The customer integration
management method has been applied with regard to
the procedure model.
Phase 1: As-is modelling: Initially, a business
process framework for the as-is service processes
has been developed. The IT service provider under
consideration exhibits seven core processes and
eight support processes that are embodied in value
chains. Each value chain consists of several
subordinated value chains that in turn comprise
detailed process models. In the following, we focus
on the processes ‘Project preparation’ and ‘Project
performance’ of the IT service provider which are
subordinated processes of the core process ‘project
business’.
Phase 2: Customer activities analysis: For the
analysis of the as-is models, the central questions
catalogue was applied. Thus, the level of customer
integration in each process business model is
analysed.
Answering, for example, the central question
‘Which activities in the performance creation
process are adopted by the customer?’ (see row
‘customer activities’ in Table 1) reveals for the
as-is model of the ‘Project performance’, that
customers are nor explicitly informed about
preparations they have to make (e. g. provisions
of rooms, availability of necessary staff
members, access to information systems) in
order to ensure a frictionless service
performance. Moreover, customers are not
regularly informed about the current project
status and upcoming project milestones.
Answering the central question ‘Which aspects
of support activities should be visible to
customers?’ exposes for the ‘Project preparation
process’, that no customer integration in the
support area has taken place during the
preparation phase of outsourcing projects. Thus,
customers had no opportunity to follow or
participate in the process.
Phase 3: To-be modelling and contract
formulation: The analysis of the as-is models
resulted in a variety of requirements with respect to
a higher level of customer integration in each area of
activity.
Requirements formulated for the ‘Project
performance process’ were, for example, that
necessary customer preparations are explicitly
communicated by the IT service provider. In
return, the customer ensures their observance.
Within the to-be model the two additional
functions ‘Transfer customer preparations’ and
‘Make preparation’ were introduced in the front-
office and customer area. The according
paragraphs have been assigned to the process
functions. Paragraph 3.2 of the IT outsourcing
contract comprises, for example, that the service
provider has to inform the customer about the
above-mentioned preparations two weeks in
advance. Moreover, the customer has to be
reminded one day before the on-site appointment
takes place. Additional process design
recommendations can be found in several new
functions and events (e. g. ‘Send delivery delay
notice’, ‘Check observance of project plan’, and
‘Post-processing of appointment’).
Requirements exposed for the ‘Project
preparation process’ were, for example, that
important information for the customer should be
ICEIS 2005 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
264
communicated as early as possible (such as
determination of a project manager or contact
person for technical questions, pre-existing
documentations about the IT infrastructure of the
customer). Thus, several new functions were
created within the front-office area of activity
(e. g. ‘Present project manager to customer’,
‘Transfer evaluation’, and ‘Transfer project plan
to customer’).
Phase 4: Implementation: Finally the requirements
documented in the to-be models have to be
implemented. The implementation of the above-
mentioned additional events from the ‘Project
preparation and Performance process’ facilitated
customers in a very early phase of the project to
knew, where, why, and which services will take
place and in which parts he/she has to participate.
Furthermore, customers were able to evaluate
support services performed by the service provider.
Hence, they were able to understand the resulting
invoice in detail. Moreover, the business process
models supported the efficient and effective
formulation of the corresponding outsourcing
contracts (not only at the point where the contract
was concluded, but also in the pre- and post contract
phases).
4 CONCLUSIONS
The application of the proposed method showed that
the identification of improvement potential of
business processes in the context of service
providing, can be supported efficiently by using a
number of central questions. To some extent, these
central questions indicate specific options for action.
At minimum, they indicate critical points which
must in turn be examined in more detail.
Segments allow – in an upstream analysis step
a segmentation of process models into separate
fields of functions or areas of activity. Furthermore,
they enable the formulation of segment-specific
central questions for comprehensive corporate
process models that are more specific than a global
list of questions. In addition, they allow for a
focussing of analysis.
The eEPC proved to be a process modelling
technique which can be extended without difficulty
for the analysis of customer integration and contract
formulation. It should be mentioned, however, that
the proposed concept is designed to be easily
transferable to other process modelling techniques.
For this purpose, adequate model elements must be
identified which are suitable for assignment to
segments.
REFERENCES
Chase, R. B. (1978). Where does the customer fit in a
Service Operation. Harvard Business Review, 56 (6),
1978: pp. 137-140.
Fließ, S., & Kleinaltenkamp, M. (2004). Blueprinting the
service company: Managing service processes
efficiently. Journal of Business Research, 57 (4),
2004: pp. 392-405.
Henderson, J. C. (1990). Plugging into strategic
partnerships: the critical IS connection. Sloan
Management Review, 30 (3), 1990: pp. 7-18.
Kelly, S. W., Skinner, S. J., & Donelly, J. H. (1992).
Organizational Socialization of Service Customers.
Journal of Business Research, 25 (3), 1992: pp. 197-
214.
Kingman-Brundage, J. (1989). The ABC’s of Service
System Blueprinting. In Bitner, M. J., Crosby, L. A.
(Eds.) Designing a Winning Service Strategy. AMA.
Chicago, pp. 30-33.
Kingman-Brundage, J., George, W. R., & Bowen, D. E.
(1995). “Service logic”: achieving system integration.
International Journal of Service Industry
Management, 6 (4), 1995: pp. 20-39.
Lasher, D. R., Ives, B., & Jarvenpaa, S. L. (1991). USAA-
IBM partnerships in information technology:
management the image project. MIS Quarterly, 15 (4),
1991: pp. 551-565.
Lovelock, C. H., & Young, R. F. (1979): Look to
Customers to Increase Productivity. Harvard Business
Review. 57 (3), 1979: pp. 168-179.
Nüttgens, M., & Rump, F. (2002). EPK 2002 –
Geschäftsprozessmanagement mit Ereignisgesteuerten
Prozessketten. In Proceedings of the first Workshop
der Gesellschaft für Informatik e. V. (GI). Trier.
Nüttgens, M., Rump, F. (2003). EPK 2003 –
Geschäftsprozessmanagement mit Ereignisgesteuerten
Prozessketten. In Proceedings of the 2nd Workshop
der Gesellschaft für Informatik e. V. (GI). Bamberg.
Palmer, A., & Cole, C. (1995). Services marketing.
Principles and practice. Englewood Cliffs. New York.
Scheer, A.-W. (2000). ARIS – Business Process Modeling.
Springer. Berlin, 3
rd
edition.
Shostack, G. L. (1982). How To Design a Service.
European Journal of Marketing, 16 (1), 1982: pp. 49-
63.
Zeithaml, V. A., & Bittner, M. J. (1996). Services
Marketing. Irwin McGraw-Hill. New York.
PROCESS MODELLING FOR SERVICE PROCESSES - Modelling methods extensions for specifying and analysing
customer integration
265