Operations Analysis Diagram- Price is Firm
knndrapeogleb
Emerald_msq_msq154209606..pdf
Managing Service Quality: An International Journal Service blueprinting and BPMN: a comparison Simon K. Milton, Lester W. Johnson,
Article information: To cite this document: Simon K. Milton, Lester W. Johnson, (2012) "Service blueprinting and BPMN: a comparison", Managing Service Quality: An International Journal, Vol. 22 Issue: 6, pp.606-621, https:// doi.org/10.1108/09604521211287570 Permanent link to this document: https://doi.org/10.1108/09604521211287570
Downloaded on: 30 October 2017, At: 12:09 (PT) References: this document contains references to 30 other documents. To copy this document: [email protected] The fulltext of this document has been downloaded 7672 times since 2012*
Users who downloaded this article also downloaded: (2011),"Business Process Blueprinting – an enhanced view on process performance", Business Process Management Journal, Vol. 17 Iss 5 pp. 732-747 <a href="https:// doi.org/10.1108/14637151111166169">https://doi.org/10.1108/14637151111166169</a>
(1982),"How to Design a Service", European Journal of Marketing, Vol. 16 Iss 1 pp. 49-63 <a href="https:// doi.org/10.1108/EUM0000000004799">https://doi.org/10.1108/EUM0000000004799</a>
Access to this document was granted through an Emerald subscription provided by emerald-srm:460696 []
For Authors If you would like to write for this, or any other Emerald publication, then please use our Emerald for Authors service information about how to choose which publication to write for and submission guidelines are available for all. Please visit www.emeraldinsight.com/authors for more information.
About Emerald www.emeraldinsight.com Emerald is a global publisher linking research and practice to the benefit of society. The company manages a portfolio of more than 290 journals and over 2,350 books and book series volumes, as well as providing an extensive range of online products and additional customer resources and services.
Emerald is both COUNTER 4 and TRANSFER compliant. The organization is a partner of the Committee on Publication Ethics (COPE) and also works with Portico and the LOCKSS initiative for digital archive preservation.
*Related content and download information correct at time of download.
D o
w n
lo ad
ed b
y G
ra n
d C
an yo
n U
ni v
er si
ty A
t 1
2: 0
9 3
0 O
ct o
b er
2 0
17 (
P T
)
Se r vice blu e p r in t in g a n d BP MN: a com p a r is on
Simon K. Milton Department of Computing and Information Systems,
The University of Melbourne, Melbourne, Australia, and Lester W. Johnson
Melbourne Business School, Melbourne, Australia
A b s t r a ct P u r p os e – The purpose of this paper is to compare and contrast a customer-focused service process diagram tool (blueprinting) with an organizational-focused process diagram tool (business process modeling notation, or BPMN). De s ign /m e t h od ology/a p p r oa ch – Using a hotel stay as an example, the paper presents both a service blueprint and a BPMN diagram. The authors then explicitly discuss the similarities, differences resulting from an ontological comparison of service blueprints and BPMN, and show where the two tools can be complementary. F in d in gs – The authors have found that one similarity is that service blueprinting segments processes into parts that are similar to BPMN’s idea of swimlanes. However, the swimlanes in service blueprinting separate customer actions, customer-facing employees’ actions and functions, and back-stage functions, actors, and information systems, thereby effectively mandating certain swimlanes for the purpose of analyzing points of contact between the firm and a customer. Another similarity is that service blueprinting deliberately differentiates between different functional areas and roles within each area to highlight, and IT systems. But it does this to make clear where actions move across organizational boundaries to avoid damaging service support, and also to explain to back-office staff their role in supporting on-stage customer interactions. Unlike BPMN, service blueprinting has physical evidence as front-stage indicators to customers of service quality and to constrain customer actions by carefully designing the servicescape. Re s e a r ch lim it a t ion s /im p lica t ion s – A limitation is that the paper only uses one example (a hotel stay). P r a ct ica l im p lica t ion s – The comparison provides service managers with guidance as to how to use the two tools interactively. Or igin a lit y/va lu e – Firms, to represent business processes, are using BPMN in increasing numbers. Knowing how BPMN supports and undermines service blueprinting is important, because service to customers is the ultimate goal for all firms. Therefore, representing service processes requires the parts of service blueprints to be supported in BPMN. Business process outsourcing adds further urgency for the need to adequately represent the parts of service processes in BPMN. Ke ywor d s Organizational processes, Modelling, Hotels, Service blueprinting, Business process modelling notation, Ontological analysis, Business process modelling P a p e r t yp e Research paper
1 . In t r od u ct ion Service-dominant logic (SDL) holds that “‘service’ is conceptualized as a process that represents the basis of social and economic exchange” (Vargo and Akaka, 2009). This service-centred view suggests that market exchange is the process of parties using their specialized knowledge for each other’s benefit – that is, for mutual service provision. This view raises the questions of what this process might look like, who are the actors in the process, what are the key parts of a service process, what interactions are there between actors in the process, and are these service processes special sorts of processes.
The current issue and full text archive of this journal is available at w w w.e m e r a ld in s igh t .com /0 9 6 0 -4 5 2 9 .h t m
Managing Service Quality Vol. 22 No. 6, 2012 pp. 606-621 r Emerald Group Publishing Limited 0960-4529 DOI 10.1108/09604521211287570
6 0 6
MSQ 22,6
D o
w n
lo ad
ed b
y G
ra n
d C
an yo
n U
ni v
er si
ty A
t 1
2: 0
9 3
0 O
ct o
b er
2 0
17 (
P T
)
SDL suggests that services are co-created processes involving a service provider and a customer. Ongoing service quality requires that the process be repeated with a predictable level of quality (Zeithaml et al., 1988). Customer experience (perception) is central to the quality of a service (process). Integrating different functions within the firm is also important. So how does a firm actually analyse its service deliver processes? One approach to representing a service is called service blueprinting, which was initially developed by (Shostack, 1984; Shostack, 1987).
Customers are recognized as important in the general business process literature. For example, Davenport (2005, p. 101) suggests:
A business process is simply how an organization does its work – the set of activities it pursues to accomplish a particular objective for a particular customer, either internal or external.
The contemporary representation of business processes is Business Process Modeling Notation (BPMN), an industry standard maintained by the Object Management Group (OMG) (OMG, 2011) (see www.omg.org/). BPMN is used as the basis for process representation, simulation (Afshar-Kazemi et al., 2011), and automation (Ter Hofstede, 2010). The latter two are important in contemporary service-oriented architectures (Erl, 2005) that are common in information technology (IT).
Since BPMN and service blueprinting purport to represent service processes, the obvious question that arises is what are the similarities and differences between service blueprints and BPMN diagrams? In order to answer this question, this paper contains a discussion of an ontological comparison of the features in service blueprints and BPMN, because both purport to represent some aspect of reality (the service and business processes of an organization). We use a recognized method of conceptual comparison (Milton and Kazmierczak, 2004; Wand and Weber, 1993) to compare service blueprinting with BPMN. The method has been used in comparing modelling formalisms in information systems.
Understanding the similarities and differences between BPMN and service blueprinting is important because business processes form the basis for corporate architecture. The degree of process integration and standardization is dictated by the relationship between the business units of the firm (Ross et al., 2006). Replication and standardization of processes is dependent on precisely articulating processes. Therefore representation of process using a standard notation, such as BPMN is important.
Modern corporations routinely engage in business process outsourcing (Mani et al., 2010). T his would also benefit from specifying the processes affected either for the completion of the process by the vendor or for integrating the process with the vendor. In both cases services experienced by customers may be affected by the outsourcing arrangement.
Summarizing, understanding in which ways BPMN supports and undermines service blueprinting is important. This is because processes are increasingly being represented using BPMN. Further, service to customers is the ultimate purpose of all internal processes. Therefore, standard articulation of service processes requires adequate representation of parts of service blueprints be supported in BPMN. Contemporary outsourcing of processes and employees creates even more urgency to adequately representing parts of service processes.
2 . Re p r e s e n t in g s e r vice : s e r vice blu e p r in t in g Service blueprinting was developed in the 1980s by Shostack (1981, 1982, 1984, 1987) and further analysed by Kingman-Brundage (1989, 1993, 1991) who called it service
6 0 7
Service blueprinting and BPMN
D o
w n
lo ad
ed b
y G
ra n
d C
an yo
n U
ni v
er si
ty A
t 1
2: 0
9 3
0 O
ct o
b er
2 0
17 (
P T
)
mapping instead of blueprinting. It essentially is a representation of the crucial aspects of a repeatable service process involving many actors and a customer (Bitner et al., 2008). Shostack (1984) suggested that blueprinting a service involves examining several issues. These are identifying processes, isolating fail points, establishing a time frame, and analysing profitability. She illustrated these concepts using a very simple service, namely a corner shoeshine parlor. With more complex services, the first three of these are still possible, but analysing profitability gets very difficult (but not impossible) as the complexity of the service delivery process increases. Her example of a blueprint for discount brokerage (Shostack, 1984, p. 138) illustrates this very well.
A blueprint takes the viewpoint of the customer, not the organization. Key features of service blueprints are customer actions, specifically interactions with individuals in the firm and/or technology (e.g. web sites) and the physical evidence that is seen by the customer during the various stages of service delivery. Actors can be people or even technology such as a web site. The crucial aspects are those that require consistent reproduction to realize the full design of the process (i.e. to minimize relevant gaps in service management). An example of a service blueprint in a hotel context is shown in Figure 1.
The service blueprint allows everyone in the organization to visualize an entire service process and its underlying business process(es). It makes explicit all points of customer contact and physical evidence is made explicit. Details of all service acts are noted on the blueprint. Firms that are successful in new services develop blueprints consistently using a systematic design and development process (Bitner et al., 2008):
objectives- idea generation- concept development- service design- prototyping- launch- feedback
Physical evidence
Customer actions
Onstage/visible contact employee actions
Backstage/invisible contact employee actions
Support processes
Enter booking in reservation
system
Update status of room in
reservation system
Make reservation
Make reservation for guest
Make up room
Take bags to room
Register guest in
reservation system
Arrive at hotel
Give bags to
bellperson
Greet and take bags
Process registration
Check in Go to room
*Ad *Hotel exterior
*Cart for bags
*Desk *Paperwork
*Lobby *Key
*Elevators *Hallways *Room*Employee
dress *Parking/ garage
*Web site
F igu r e 1 . Blueprint for a hotel stay
6 0 8
MSQ 22,6
D o
w n
lo ad
ed b
y G
ra n
d C
an yo
n U
ni v
er si
ty A
t 1
2: 0
9 3
0 O
ct o
b er
2 0
17 (
P T
)
The design process attempts to manage the gaps in the customer experience and in service quality and experience (Zeithaml et al., 1988). Blueprinting focuses on service design which must have clarity of outcomes and processes involving the customer and a clear understanding of how experience builds via touch points with the firm. Customer actions are central to a service blueprint, along with on-stage (visible) employee actions, back-stage (invisible) contact employee actions, and support processes (presumably not involving contact employees). Physical evidence is also shown across the top of a service blueprint, since the so-called servicescape (Bitner, 1992) has been shown to be a key element in a customer’s evaluation of service quality.
For virtually all services, customers must provide some input, and in many cases quite a bit. The management of this customer participation has been discussed at length by Fließ and Kleinaltenkamp (2004) using what they call the “production-theoretic approach of service processes” (Fließ and Kleinaltenkamp, 2004, p. 393), which treats the service consumer as a co-producer of the service. However, this increasing customer participation has a cost in that customer information needs to be taken into account. This may be inaccurate, delayed or misinterpreted by the service provider, making service delivery more difficult. Managing this is a key element in successful service delivery.
There is added complexity when actors in the service delivery are from disparate parts of the firm. Further, other companies may employ actors involved in service delivery. This is common in contemporary outsourcing practice in business.
So the key concepts in service blueprinting are given in the Table I. The theme of this paper is that one can relate a customer-focused service blueprint
to internally focused process representations such as BPMN diagrams. We now turn to a brief discussion of representing business processes in this way.
3 . Re p r e s e n t in g p r oce s s : BP MN BPMN is a graphical standard to “allow users to express the information flow, decision points and the roles of business processes in a diagrammatic way” (Ko et al., 2009, p. 754). BPMN is seen as “the state-of-the-art in the field” (Chinosi and Trombetta, 2012, p. 124) of business process modelling.
Business process modelling emerged from the need for people in an organization to communicate about business processes. Specifically, “provide a notation that is readily
Concept Definition
Action Actions that customers, front-stage personnel, back-stage personnel, and support staff perform in a service
Action flow Sequencing of actions Line of visibility Interface between customers and front-stage personnel Line of internal interaction Interface between front-stage and back-stage personnel Line of implementation Interface between back-stage and support personnel Communications flow Flow of communication between any participants in the service Actor categories Customers, front-stage personnel, back-stage personnel, support/
implementation personnel Props and physical evidence
Anything seen by the customer in the process of the service delivery T a ble I.
Core concepts in service blueprinting
6 0 9
Service blueprinting and BPMN
D o
w n
lo ad
ed b
y G
ra n
d C
an yo
n U
ni v
er si
ty A
t 1
2: 0
9 3
0 O
ct o
b er
2 0
17 (
P T
)
understandable by business users, ranging from the business analysts who sketch the initial drafts of the processes to the technical developers responsible for actually implementing them, and finally to the business staff deploying and monitoring such processes” (Chinosi and Trombetta, 2012, p. 126). BPMN can be used alone and with other modelling tools in the “description, simulation and execution of processes” (Chinosi and Trombetta, 2012, p. 124). Thus, beyond being a graphical standard, BPMN provides the foundation for automating parts of processes (e.g. seeking service providers prepared to meet the specific requirements automatically via technical services delivered through the internet), and for simulating processes.
BPMN is an initiative of the OMG and has substantial vendor involvement, including from prominent IT services and software companies such as IBM and SAP. BPMN builds on earlier process representation efforts (e.g. event process chains from SAP) and relates to the most prominent software analysis, design and development methodology called the rational unified process that is underpinned by OMG’s Unified Modeling Language (UML).
In Version 1.2 of BPMN (OMG, 2011) the focus was on representing processes from one organization’s viewpoint. However, Version 2 released in 2011 (OMG, 2011) has extended V. 1 to represent complex inter-organizational and multi-organizational processes found commonly today.
In this paper we restrict ourselves to the parts of BPMN that apply for processes within one organization. We do this to allow an exploration of basic service blueprints without the complexity of parts of the blueprint or process being completed by employees belonging to other service providers, nor the complexity where inter-organizational processes of other firms impinge on the service. We restrict our focus to consider the actors and IT systems, internal to the firm, and customers.
In this section we will represent the service blueprint shown earlier, and in so doing we will introduce the main concepts for BPMN. These have come directly from the documents sponsored by OMG and from academic summaries of the concepts (Fetke, 2008; Recker, 2011).
Figure 2 shows a BPMN representation of the service blueprint introduced earlier. It shows the business processes using swim-lanes. A “swim-lane” separates actors. Each swim-lane shows the tasks and activities each actor completes in the process from beginning to end. In this example, each actor is responsible for their own processes and do not take carriage of the process alone. The steps in processes, called activities or tasks, may be complex, comprising many simpler steps, or simple.
An “event” stimulates an actor’s activity. For example, the receipt of a message may trigger an activity. In this example the event of receiving a call at the call centre may cause the activity “record and confirm” for the call centre staff. T here are about 40 different types of events in the full richness of BPMN.
An “activity” shows when an actor completes some work. Activities are the core of describing the actual work completed. The work could be atomic, a “task”, or could be more complex comprising several tasks, called a “sub-process” or just an “activity”.
Arrows connect events, activities, and tasks, show the sequence of the process, and are called “flow”. T here are three types of flow that are used to:
(1) show the way a process is planned to execute, called “sequence flow”;
(2) show a flow of message, called “message flow”; or
(3) show a logical links between activities, called “association”.
6 1 0
MSQ 22,6
D o
w n
lo ad
ed b
y G
ra n
d C
an yo
n U
ni v
er si
ty A
t 1
2: 0
9 3
0 O
ct o
b er
2 0
17 (
P T
)
We describe each as follows. “Sequence flow” as the name suggests shows the sequence of events, activities, and
tasks that an actor within a swim-lane completes. This type of flow is drawn using a solid arrow. A flow has a start event and end event indicated by special symbols. Process flows can be placed within swim-lanes (e.g. for different actors). Several lanes can be placed in a “pool” (e.g. for several actors belonging to one department). Each lane shows the process for that lane, with connections to other lanes. A pool shows a logical grouping of lanes and plays no other role in the representation. The most common use of lanes is to separate actors (e.g. reception clerk). Actors in BPMN can be IT systems (e.g. SAP).
“Message flow” represents communication. “Message flow” is shown using a dashed headed arrow in the direction of the flow. A message can be constrained and therefore be in a specific form (e.g. a registration form) and therefore be a type of data object or may be informal (e.g. normal speech or a free-form letter).
“Association” is a very general link shown using a dotted line. It may have a direction but often does not and shows a logical link between activities and tasks. For example, a flow of data from one activity to another may be shown using a headed
Make reservation
Record and confirm
Park car
Make up room
Room status
Reservation
Reservation db
Reservation details
Room db Check-in process
Record booking process
Room details
Arrive
Greet and collect
car keys
Check-in guest
Check-in at reception
K e ys
K e ys
K e ys
R e
sp o
n se
R e
se rv
a tio
n d
e ta
ils
D e
ta ils
R o
o m
d e
ta ils
, e
le ct
ro n ic
k e y
D e ta
ils
G re
e tin
g
R e s p
o n s e
B o
o ki
n g
C u
st o
m e
r R
e c e
p tio
n s
ta ff
D o
o rm
a n
C a ll
c e n
te r
V a
le t
R o o
m s
ta ff
R e
se rv
a ti o n
s ys
te m
Go to room
F igu r e 2 . BPMN diagram for
a hotel stay
6 1 1
Service blueprinting and BPMN
D o
w n
lo ad
ed b
y G
ra n
d C
an yo
n U
ni v
er si
ty A
t 1
2: 0
9 3
0 O
ct o
b er
2 0
17 (
P T
)
arrow. The flow is often used to represent informal communication in a process. Alternatively, it could be used to link a text “annotation” to a component that explains the BPMN component. For example, a text label that says “this task involves processing payment” may label the task “payment” to help people to understand what the task involves.
Flow can be simple where activities and tasks are joined with an arrow showing the sequence of activity and task execution, as is the case shown above. However, flow can be made more complex by having ways of flow splitting to many activities or tasks, or joining of many activities to one. The splitting and joining of flow is shown using a diamond and is formally called a “gateway”. The type of split or join can be complex with five basic splits (e.g. a simple split to execute only one of the paths). The simplest show whether exactly one (exclusive “or”), more than one (“or”), or all (“and”) of the activities entering or leaving the join or split, respectively, are required prior to (join) or must follow (split).
Complex activities, comprising multiple tasks, are shown using a “þ ” symbol that indicates that more details of the activity can be found by drilling down. Further, activities in different lanes that are related can be associated using a dotted line. An example of both of these is the complexity and association between lanes of the “make reservation” customer activity with the “record and confirm” activity in the call centre, and the “record booking process” in the reservation system. This association and complexity in the process can be explored and is shown in Figure 3.
Each activity can have complex conditions, of which there are many in the standard, for completing with flow indicated for each condition. The example in Figure 4(a) shows processing of a credit card payment. There are three possible ways of completing the process. First, if the payment using card is accepted then flow continues normally and is shown using an arrow without an icon emerging from the task. Second, exceptional flow shown using the lightning bolt, is for when there is an exception beyond the actor’s control, with separate processing required. T hird, a failure flow, shown with an “X” at the start, is used to handle the delicate situation where the credit card is declined. Figure 4(b) shows an alternative way of handling
Call hotel’s 1800
number
Answer call
Cannot fill needs
Room query Room reservation
Reservation db
Ask for customer
preferences Check
availability Reserve
room
Complete call
Handle dissatisfaction
Negotiate preferences
C u
st o
m e
r C
a ll
ce n
te r
R e s e rv
a tio
n s
ys te
m
Conclude negotiation End call
F igu r e 3 . Make reservation detail in BPMN
6 1 2
MSQ 22,6
D o
w n
lo ad
ed b
y G
ra n
d C
an yo
n U
ni v
er si
ty A
t 1
2: 0
9 3
0 O
ct o
b er
2 0
17 (
P T
)
trouble with credit card handling could be supported using the “compensation” action for the task or activity where the task is reversed when any abnormal outcome occurs.
Activities or tasks can be labelled to show whether it repeats until a condition is met (e.g. in seeking quotes from suppliers), has several instances executing in parallel, or is for compensation (e.g. when the effects of the process is reversed). Compensation is best used where the reversal of the task is self-explanatory or does not require special attention in contrast to when the interaction may lead to challenging situations (e.g. where a customer may be offended).
Some processes explicitly pass flow from one actor to another by crossing swim-lanes. The hotel example requires separate autonomy of actors while requiring messages to pass between the actors. In this way actors communicate while maintaining their own flows. Communication is either unstructured (e.g. a verbal request for a room or an e-mail/letter to the hotel) using a “message flow” or structured communication (e.g. a specific form being completed by a customer and passed to the receptionist). Unstructured communication is shown using a dashed line, or “association”. Often documents label these flows. Dotted lines show more structured data flows between actors. These flows are more structured and often involve IT systems and follow a standard format.
Summarizing, we find 12 concepts at the core of BPMN. These are summarized in Table II . These concepts will be used in the method detailed in the next section.
4 . Me t h od of con ce p t u a l eva lu a t ion Recall we are comparing BPMN with service blueprinting. Specifically, we conduct a comparison of the concepts found in service blueprints with those found in BPMN. We do this to see the similarities and differences between the two representations. The aim is to see how well BPMN supports service blueprints, specifically, to find out the areas in which BPMN supports and areas in which it has shortcomings.
T he comparison used the method of conceptual comparison (Milton and Kazmierczak, 2004; Wand and Weber, 1993, 2002) to find similarities and differences as shown in Figure 5. Specifically, the concepts in service blueprints were compared one by one with BPMN. The approach has been used widely in information systems (Wand and Weber, 1993) to analyse modelling formalisms much like BPMN and service blueprinting by using the ontology implicit in each of the modelling formalisms as a basis for comparison. Thus, the aim of the method of conceptual evaluation is to compare the ontology embodied in BPMN with that embodied in service blueprints. In conducting a conceptual evaluation we are seeking to provide qualitative answers to:
. How well does BPMN capture reality relative to service blueprints?
Process credit card payment
Card declined Communication error
Problem with card
(b) Using compensation(a) Using explicit process markings
Process credit card payment
F igu r e 4 . (a) using explicit process
markings; (b) using compensation
6 1 3
Service blueprinting and BPMN
D o
w n
lo ad
ed b
y G
ra n
d C
an yo
n U
ni v
er si
ty A
t 1
2: 0
9 3
0 O
ct o
b er
2 0
17 (
P T
)
Essentially, BPMN and service blueprints are representations of reality. Each also contains modelling commitments to how reality is represented through the concepts (e.g. “activity” in BPMN) that lie behind the constructs used in models. These commitments equate to an ontology, or commitment to what exists, based on what is represented.
We use the method of conceptual evaluation to see how close the representations in service blueprints are supported by BPMN. By doing this, we are evaluating BPMN.
Concept Definition
Activity An activity is work that an organization performs in a process. An activity can be atomic or compound
Sub-process A sub-process is a non-atomic activity comprising more sub-processes or tasks Task A Task is an atomic activity and is used when the work in the process is not
broken down to a finer level of detail Event An Event is triggered (e.g. arrival of a message) and produces results (e.g. sending
a message). Events can cause the start of a process (start event), causes the end of a process (end event) based on some trigger, be in the middle of a process (intermediate event). Intermediate events can be part of specifying the end of a complex activity (e.g. triggered after a specific time has elapsed to case a sequence of tasks in a complex activity resulting in a flow commencing) or could trigger an activity to do something (e.g. compensation is to reverse the effect of an activity)
Sequence flow A sequence flow shows the order that activities will be performed in a process by connecting the activities together
Message flow A message flow shows a formal message passing from one process to another Association flow An association flow links artefacts (e.g. data objects and annotations) with other
process elements (e.g. activities and events). Information may be in the form of labels of process elements, or may be data that is informally communicated by actors
Message A message shows the contents of a communication between activities executed by different actors
Gateway A gateway controls the splitting and joining of sequence flows in a process using logical statements (e.g. only one of the split sequences are followed)
Swim-lane A swim-lane groups sub-processes by actor, by type of actor, or by IT system Pool A pool categorizes or groups two or more swim-lanes Data object A data object is data required for an activity, or produced by an activity Group A group indicates that process elements are logically related Annotation An annotation is a label provides additional meaning to readers (e.g. clarifying
the purpose of a process) T a ble II. Core concepts in BPMN
Blueprint ontology
BPMN ontology
Conceptual evaluation
Qualitative assessment of similarities and differences
F igu r e 5 . The method of conceptual evaluation
6 1 4
MSQ 22,6
D o
w n
lo ad
ed b
y G
ra n
d C
an yo
n U
ni v
er si
ty A
t 1
2: 0
9 3
0 O
ct o
b er
2 0
17 (
P T
)
The evaluation is to see how well BPMN supports the view on reality that service blueprints assumes through the concepts found in service blueprints.
As indicated in Figure 5 the inputs to the method of conceptual evaluation are the ontology embodied in service blueprints and the ontology embodied in BPMN. The output of the method is a list of similarities and differences between the concepts in service blueprints and those in BPMN and a qualitative analysis of those similarities and differences.
The method of conceptual evaluation has four basic steps. Step 1: determine the set of concepts from service blueprints to be used in a forward evaluation. This set of concepts we call the reference concepts. Step 2: determine the set of concepts from the ontology embodied in BPMN to be used in a backward evaluation. T his set of concepts we call the BPMN modelling concepts. Step 3: perform a forward and backward evaluation of the two sets of concepts and tabulate the results. Step 4: perform the analysis step in which the results are analysed. We explain the steps below.
The first step is to determine the basic set of concepts on which the comparison will be based. The concepts are based on the basic literature concerning service blueprints. We have already extracted these concepts earlier in Section 2 and summarized in Table I. The second step resembles the first and involves determining the set of concepts from BPMN. These are found in the literature concerning BPMN. We have similarly extracted these concepts earlier in Section 3 and we summarize these concepts in Table II.
The third step involves the comparison of concepts from each of the ontology embodied in service blueprints and the ontology embodied in BPMN. T he concepts embodying service blueprints drives the comparison and the presentation of the results uses the reference of service blueprints. Further, the comparison is at the level of concepts thus moving beyond the specific names or terms used to signify the concepts. Additionally, this step is subjective – there is no other way to undertake a conceptual evaluation of this nature.
The presentation of the results of the evaluation utilizes semiotic theory for two reasons. First, terms and concepts are clearly semiotically related. Second, comparison of concepts is semantic with semiotic theory providing an ideal basis for explaining semantic differences in terms. Specifically, each term through its associated concept in service blueprints or BPMN, spans part of a semantic field (Eco, 1976), or conceptual plane (Culler, 1976; Cruse, 2000). Alternatively, each term possesses an essential depth (Liska, 1996) which similarly evokes the conceptual span of a term. T he term “semantic field” labels these ideas and expresses the similarities and differences between concepts in service blueprints, the list of concepts in Table I, and those embodying BPMN, the list of concepts in Table II. Specifically, we use a graded indicator to express the similarities and difference.
When comparing a concept c (from service blueprints) with BPMN, there are three broad categories of results. First, BPMN may have total overlap with respect to c. Total overlap may be provided by one concept (e.g. d) or perhaps by several concepts (e.g. two concepts d and e). That is, there may be one concept or several concepts that together provide total overlap, in terms of semantic field, with the concept from service blueprints. The second possibility is where the overlap is partial. Finally, it may be that there is no overlap at all between BPMN and c from service blueprints.
Figure 6 shows the three categories of results pictorially. While the coverage of a specific concept is depicted in this figure as a sharp rectangle, the nature of semantic fields dictates that the boundaries between semantic fields are quite
6 1 5
Service blueprinting and BPMN
D o
w n
lo ad
ed b
y G
ra n
d C
an yo
n U
ni v
er si
ty A
t 1
2: 0
9 3
0 O
ct o
b er
2 0
17 (
P T
)
imprecise. This emphasizes the fact that the comparison is conceptual and that concepts may be partially covered and that a simple presence/absence is not ideal for evaluations of this nature.
Each of these categories of results can be indicated using symbols so that an idea of the results of the comparison can be conveyed easily in tabular form. This is called the indicative results. The three symbols for full coverage, partial coverage, and no coverage are (| ) (| p), and ( ), respectively.
The second dimension of the final step in the method is the qualitative result of evaluating BPMN using service blueprints explaining the indicative results from Step 3. The analysis of the qualitative results presents issues beyond the direct comparison of concepts and discusses issues such as the nature of the gaps in coverage that are evident from the results as presented in Step 3 and the implications of these on supporting service processes in BPMN resulting from the outcome of comparing service blueprints with BPMN.
5 . Com p a r is on of s e r vice b lu e p r in t s a n d BP MN 5.1 Results The results are summarized in Table III. It shows that broadly the main concepts in service blueprints are reflected in BPMN. Recall that the specific detailed analysis, derived by systematically stepping through each of the concepts in service blueprints provides depth to the comparison. This analysis covered in the paragraphs following Table III.
5.2 Discussion Service blueprints support specifying simple and complex actions. Actions can be described simply (e.g. process credit card) or can be a more complex representation
c d c d
c
c d
c d
e e
p X
F igu r e 6 . Degree of overlap in coverage of semantic field
Service blueprints concept BPMN
Action (simple and complex) | Action flow | Line of visibility Line of internal interaction Line of implementation Communications flow | Moments of truth | p Actor categories (four types) | p Props and physical evidence
T a ble III. Indicative results comparing service blueprints with BPMN
6 1 6
MSQ 22,6
D o
w n
lo ad
ed b
y G
ra n
d C
an yo
n U
ni v
er si
ty A
t 1
2: 0
9 3
0 O
ct o
b er
2 0
17 (
P T
)
(e.g. specifying the specific sequence of steps required to process a credit card). BPMN can similarly specify actions to different degrees of specificity and so supports the concept from service blueprints.
Service blueprints can represent the flow of actions and thereby structures the actions each actor performs. BPMN similarly fully supports the description of the flow of processes each actor performs. However, service blueprints sometimes do not show the flow explicitly as some time may pass between the actions an actor performs in the process, thus making the links between actions not necessary to show. This does not negate the implied flow between the processes. BPMN has a wide range of symbols to specify how each task or activity is performed and how sequences of these combine to describe the process. Blueprinting has a smaller set but nevertheless is likely to be able to describe similar ranges of action sequences. The detailed analysis of the semantics of blueprints compared with BPMN is not within the scope of this study.
There are three lines in service blueprinting: the lines of visibility, internal interaction, and implementation. BPMN does not directly support these. However, one could use BPMN to support these three lines by separating the three types of personnel, front-stage, back-stage, and support personnel, into different pools of swim-lanes. Annotation of the various pools would aid clarity in communicating that the lines are important in ensuring the customer receives support from all parts of the organization and that visible actors are particularly important in service delivery.
Communications flow described in service blueprints is fully supported by similar concepts in BPMN. However, communication between front-stage personnel and customers are called moments of truth. Specifically, moments of truth occur whenever a customer service representative interacts with a customer. This is shown on service blueprints as a crossing of the line of visibility that separates back-stage from front-of-stage actions. These are particularly important when something does not go according to the script of a smoothly running process. These are called moments of truth because there is a risk that the customer may be disappointed with the way the problem is handled and therefore will not see the service as true. For example, when processing a credit card for payment, the card may be declined. The way that a customer service representative handles such moments of truth is critical to customer satisfaction. BPMN has potential to fall short in representing moments of truth. This is because BPMN uses “compensation” to reverse a task’s effect. Thus, a payment task using credit card could be represented using “compensation” for cases when the card is declined. However, the way in which the actor handles the outcome of the credit card declination would vary widely between actors. A better way to handle this would be to disallow simple “compensation” actions in service blueprints represented in BPMN to avoid variable service outcomes in moments of truth.
Service blueprinting has four categories of actors: customers, visible front-stage personnel, back-stage personnel not visible to customers, and support personnel. BPMN can categorize actors using pools of swim-lanes but does not mandate the categorization described by service blueprinting. BPMN thus clearly can support these different types of actors. However, full support of service processes requires specifying pools of swim-lanes that separate the actor types into the four types specified. Specifically, this requires a pool for each of the types of actors. Each pool in turn could be divided into swim-lanes for specific actors (e.g. types of customer or different IT systems such as a web page). It is not clear where technology (e.g. a web page) fits within the traditional line of visibility and back-stage processes in service blueprinting.
6 1 7
Service blueprinting and BPMN
D o
w n
lo ad
ed b
y G
ra n
d C
an yo
n U
ni v
er si
ty A
t 1
2: 0
9 3
0 O
ct o
b er
2 0
17 (
P T
)
Props and physical evidence are important in blueprinting services. These are important because they help to reinforce characteristics of the service that help to reinforce the service design. For example, in a five-star hotel the props should reinforce customer views of the quality expected for that service. T hus, specifying props is critical in ensuring the service is realized in the quality expected. BPMN does not support representing props and physical evidence. This shortcoming needs to be addressed if BPMN is to be used to effectively represent services as blueprinted by service blueprinting. Communicating these aspects of services lies at the heart of ensuring that all employees understand and realize a service according to its design. Because BPMN representations are often used to communicate with IT staff, having explicit support of describing which aspects of IT act as props (e.g. the character and quality of the user interface of IT) helps to ensure the props reinforce the desired idea of the service for the customer (e.g. a budget airline such as Jet Blue maintaining a light-hearted enjoyable character in its web site).
Summarizing, BPMN broadly supports service blueprinting. First, actions, complexity in actions, and communications are fully covered by BPMN. BPMN can partly support actor categories through pools of swim-lanes, but discipline would be needed to use BPMN in this way. BPMN does not support a distinction between visible and back-stage actions, with the associated lines of visibility, internal interaction, and implementation, however, can be used to do so. BPMN does not support props and physical evidence.
6 . Con clu s ion s Service blueprinting is commonly used to represent service processes. Our comparison of the ontology implicit in service blueprinting with the ontology implicit in BPMN shows that BPMN can be used to diagram a service process, but it does this from a fundamentally different perspective compared with service blueprinting.
The customer-focused perspective of blueprinting is very useful in understanding the critical touch points driving service satisfaction. But underneath this lie business processes from the organizational perspective that can be best represented by BPMN diagrams.
In our view, based on the results of our comparison, the two process tools can be effectively used in tandem by service organizations desiring an improved service outcome. However, BPMN has specific shortcomings compared with service blueprints. These require extensions to BPMN to include representing props (and other evidence of service quality that are visible to the customer); a line of visibility (to adequately separate activities that are visible to customers from back-stage activities), line of interaction (between front-stage and back-stage activities), line of implementation (between back-stage activities and more general support activities); and guidelines to enable “moments of truth” to be carefully scripted in BPMN. Discipline in using pools and swim-lanes found in BPMN in specific ways to separate the different types of actors is also required.
Services are now central to most economies. BPMN is rapidly emerging as the standard for representing, simulating, and executing processes. Thus, improving BPMN to include key features of service blueprinting is important. Each firm must carefully describe processes that impact on other firms to which it provides services, as must firms expecting services from others. Additionally, as process standardization gathers pace, finding ways to adequately represent service processes in these standards is also important.
6 1 8
MSQ 22,6
D o
w n
lo ad
ed b
y G
ra n
d C
an yo
n U
ni v
er si
ty A
t 1
2: 0
9 3
0 O
ct o
b er
2 0
17 (
P T
)
Incorporating service blueprinting practices and formalisms into methodologies for business process modelling, mapping, simulation, and automation would lead to a clearer integration of the customer’s view of a service with technology used to underpin the service. Specifically, by showing how the technical component of service delivery relates to the customer, the process designer and analysts employed to recommend technology to support processes will be much more cognizant of the impact of technology on servicing customers. This is particularly important when IT services, through service-oriented architectures, provide automation.
Many organizations comprise business units where processes depend on other parts of the business. Specifically, business process standardization and integration across these organizations determines the level of agreement and shared representations of business processes (Ross et al., 2006). BPMN plays an important role in maintaining process plans for these organizations and is part of the essential infrastructure for enterprise architecture. Specifically, where processes are integrated between business units collaboration becomes critical with an implied service relationship between business units for these processes. Further, the prevalence of outsourcing in contemporary organizations adds to the importance of understanding how the standard way of representing business processes, BPMN, is different from service blueprinting. This is because by explicitly showing the relationship between actors from other companies and customers will help deliver a consistent service to the organization’s customers. Much of BPMN version 2.0 involves choreography of these complex inter-unit processes. This can be further extended to inter-organizational processes. Exploring how service blueprinting can improve the design of these processes is an interesting avenue of future research.
Re fe r e n ce s
Afshar-Kazemi, M., Toloie-Eshlaghy, A. and Abadi, P. (2011), “Application of simulation of queue network for reengineering of business processes”, European Journal of Economics, Finance and Administrative Sciences, Vol. 36, pp. 7-18.
Bitner, M.J. (1992), “Servicescapes: the impact of physical surroundings on customers and employees”, Journal of Marketing, Vol. 56 No. 2, pp. 57-71.
Bitner, M.J., Ostrom, A.L. and Morgan, F.N. (2008), “Service blueprinting: a practical technique for service innovation”, Califor nia Management Review, Vol. 50 No. 3, pp. 66-94.
Chinosi, M. and Trombetta, A. (2012), “BPMN: an introduction to the standard”, Computer Standards & Interfaces, Vol. 34 No. 1, pp. 124-34.
Cruse, D.A. (2000), Meaning in Language: An Introduction to Semantics and Pragmatics, Oxford University Press, Oxford.
Culler, J. (1976), Saussure, Fontana, CA.
Davenport, H. (2005), “The coming commoditization of processes”, Harvard Business Review, Vol. 83 No. 6, pp. 100-8.
Eco, U. (1976), A T heory of Semiotics, Midland, TX, Bloomington, IN.
Erl, T. (2005), Service-Oriented Architecture: Concepts, Technology, and Design, Prentice Hall, Upper Saddle River, NJ.
Fetke, P. (2008), “Business process modeling notation”, Wirtschaftsinformatik, Vol. 50 No. 6, pp. 504-7.
Fließ, S. and Kleinaltenkamp, M. (2004), “Blueprinting the service company: managing service processes efficiently”, Journal of Business Research, Vol. 57, pp. 392-404.
6 1 9
Service blueprinting and BPMN
D o
w n
lo ad
ed b
y G
ra n
d C
an yo
n U
ni v
er si
ty A
t 1
2: 0
9 3
0 O
ct o
b er
2 0
17 (
P T
)
Kingman-Brundage, J. (1989), “The ABC’s of service system blueprinting”, in Bitner, M.J. and Crosby, L.A. (Eds), Designing a Winning Service Strategy, American Marketing Association, Chicago, IL, pp. 30-3.
Kingman-Brundage, J. (1991), “Technology, design and service quality”, International Jour nal of Service Industry Management, Vol. 2 No, 3, pp. 47-59.
Kingman-Brundage, J. (1993), “Service mapping: gaining a concrete perspective on service system design”, in Scheuing, E.E. and Christopher, W.F. (Eds), T he Service Quality Handbook, American Management Association, New York, NY, pp. 148-63.
Ko, R., Lee, S. and Lee, E. (2009), “Business process management (BPM) standards: a survey”, Business Process Management Jour nal, Vol. 15 No. 5, pp. 744-91.
Liska, J.J. (1996), A General Introduction to the Semiotic of Charles Sanders Peirce, Indiana University Press, Bloomington, IN.
Mani, D., Barua, A. and Whinston, A. (2010), “An empirical analysis of the impact of information capabilities design on business process outsourcing performance”, Management Information Systems Quarterly, Vol. 34 No. 1, pp. 39-62.
Milton, S.K. and Kazmierczak, E. (2004), “An ontology for data modelling languages: a study using a common-sense realistic ontology”, Journal of Database Management, Vol. 15 No. 2, pp. 19-38.
Object Management Group (OMG) (2011), “Business process model and notation (BPMN)”, available at: www.omg.org/ (accessed April 2011).
Recker, J. (2011), Evaluations of Process Modeling Grammars: Ontological, Qualitative and Quantitative Analyses using the Example of BPMN, Springer Verlag, Berlin, Heidelberg and New York, NY.
Ross, J., Weill, P. and Robertson, D. (2006), Enterprise Architecture as Strategy, Harvard Business School Press, Cambridge, MA.
Shostack, G.L. (1981), “How to design a service”, in Donnelly, J. and George, W.R. (Eds), Marketing of Services, American Marketing Association, Chicago, IL, pp. 221-9, 281.
Shostack, G.L. (1982), “How to design a service”, European Jour nal of Marketing, Vol. 16 No. 1, pp. 49-63.
Shostack, G.L. (1984), “Designing services that deliver”, Harvard Business Review, Vol. 62 No. 1, pp. 133-9.
Shostack, G.L. (1987), “Service positioning through structural change”, Jour nal of Marketing, Vol. 51 No. 1, pp. 34-43.
Ter Hofstede, A. (2010), Moder n Business Process Automation (Electronic Resource): YAWL and its Support Environment, Springer, Heidelberg.
Vargo, S.L. and Akaka, M.A. (2009), “Service-dominant logic as a foundation for service science: clarifications”, Service Science, Vol. 1 No. 1, pp. 32-41.
Wand, Y. and Weber, R. (1993), “On the ontological expressiveness of information systems analysis and design grammars”, Jour nal of Information Systems, Vol. 3 No. 4, pp. 217-37.
Wand, Y. and Weber, R. (2002), “Research commentary: information systems and conceptual modeling – a research agenda”, Infor mation Systems Research, Vol. 13 No. 4, pp. 363-76.
Zeithaml, V.A., Berry, L.L. and Parasuraman, A. (1988), “Communication and control processes in the delivery of service quality”, Journal of Marketing, Vol. 52 No. 2, pp. 35-48.
A b ou t t h e a u t h or s Simon K. Milton received his PhD from the University of Tasmania’s Department of Information Systems. In his dissertation he reported the first comprehensive analysis of data modelling
6 2 0
MSQ 22,6
D o
w n
lo ad
ed b
y G
ra n
d C
an yo
n U
ni v
er si
ty A
t 1
2: 0
9 3
0 O
ct o
b er
2 0
17 (
P T
)
languages using a common-sense realistic ontology. He continues his interests in the ontological foundations of modeling languages and formalisms, and the implications of top-level ontological commitments in information systems modelling. His recent interest extends to the value and use of ontologies to business and biomedicine. He holds a senior lectureship in the Department of Computing and Information Systems at The University of Melbourne. Simon K. Milton is the corresponding author and can be contacted at: [email protected]
Lester W. Johnson is Professor of Management (Marketing) at the Melbourne Business School, The University of Melbourne. He has a BA from the University of New Hampshire and an MA and PhD from the University of Connecticut. His research focuses on customer satisfaction and consumer behaviour in services. He has published in the Jour nal of the Academy of Marketing Science, Journal of Retailing, International Journal of Research in Marketing, Journal of Service Research, Journal of Advertising Research, European Journal of Marketing, Jour nal of International Marketing and numerous other marketing and business journals, as well as three books. He is currently the Editor of the Australasian Marketing Jour nal. He is a Fellow of both the Australia and New Zealand Marketing Academy and the Australian Market & Social Research Society.
To purchase reprints of this article please e-mail: r e p r in t s @e m e r a ld in s igh t .com Or visit our web site for further details: w w w.e m e r a ld in s igh t .com /r e p r in t s
6 2 1
Service blueprinting and BPMN
D o
w n
lo ad
ed b
y G
ra n
d C
an yo
n U
ni v
er si
ty A
t 1
2: 0
9 3
0 O
ct o
b er
2 0
17 (
P T
)
T his article has been cited by:
1.Pornprom Ateetanan, Sasiporn Usanavasin, Kunio Shirahada, Thepchai Supnithi. From Service Design to Enterprise Architecture:The Alignment of Service Blueprint and Business Architecture with Business Process M odel and Notation 202-214. [Crossref]
2.Arnela Ceric, Steven D'Alessandro, Geoff Soutar, Lester Johnson. 2016. Using blueprinting and benchm arking to identify m arketing resources that help co-create customer value. Journal of Business Research 69:12, 5653-5661. [Crossref]
3.ChengColin C.J., Colin C.J. Cheng, ShiuEric, Eric Shiu. 2016. Exam ining the link between service modularity and firm perform ance. Journal of Service Theory and Practice 26:5, 696-720. [Abstract] [Full Text] [PDF]
4.Florian Bär, Kurt Sandkuhl, Rainer Schm idt. On the M aturity of Service Process M odeling and Analysis Approaches 356-367. [Crossref]
5.Arm ando Calabrese, M ichele Corbò. 2015. Design and blueprinting for total quality m anagement im plementation in service organisations. Total Quality M anagement & Business Excellence 26:7-8, 719-732. [Crossref]
D o
w nl
o ad
ed b
y G
ra n
d C
an yo
n U
n iv
er si
ty A
t 1
2 :0
9 3
0 O
ct o
be r
2 01
7 (
P T
)
