Technovation 22 (2002) 15–39
www.elsevier.com/locate/technovation
A generic model and design representation technique of service
products
Qinhai Ma
b
a,*
, Mitchell M. Tseng b, Benjamin Yen
b
a
Department of Management and Industrial Engineering, Northeastern University, Shenyang, PR China
Department of Industrial Engineering and Engineering Management, Hong Kong University of Science and Technology, Hong Kong
Abstract
Service businesses have developed into an important economic force. Provision of various quality service products to more
demanding customers is the key for organizations to retain a competitive advantage. Design is important for making such intangible
products “visible” and manageable, and is considered as the key to service quality. A good understanding of the architectural aspects
and a design representation technique of service products are needed to facilitate the product design practice and effective production
and marketing. What constitutes a unit of service product and how is the product represented (depicted) formally? These questions
remain unanswered. The fuzziness in identifying service product construction and the lack of an appropriate design representation
method are recognized as the main reasons for the undeveloped design tradition for service products. In this paper, the architectural
perspectives from which to view service products are provided by proposing a generic model based on the concept of customer
service experience, which delineates the elements involved in specifying a service product design. Based on the model, an approach
to the design representation of service products is proposed. The implications for service management are also presented.  2001
Elsevier Science Ltd. All rights reserved.
Keywords: Service product; Model; Design representation
1. Introduction
Nowadays service businesses (industries) have
developed into an important economic force and have
become an integral part of modern society (Illeris, 1996;
Cook et al., 1999). Service industries often provide
social/personal services, transportation, finance, advertising, repair, distribution, or communication support for
manufacturing industries. Healthy manufacturing industries depend on the good performance of service businesses. Service industries facilitate goods-producing
activities. Manufacturing industries and service industries become complementary and closely related. Moreover, economic development and the changes in the standards of living have caused changes in human
consumption patterns; human needs are satisfied with not
* Corresponding author. Tel.: +86-24-23913802; fax: +86-2423891569.
E-mail address: maqinh@mail.sy.ln.cn (Q. Ma).
only physical goods but also services — these two
together raise and improve the quality of living.
The growing importance of the service industry has
prompted greater attention being paid to service operations management (Johnston, 1994). Especially over the
last ten years, organizations have increasingly improved
their own service operations. Many service sectors have
sought and made use of various enhancement programs
to improve their operations in an attempt to be highly
competitive.
Fig. 1 shows the conceptual model of service operations systems. We are interested in the result of the
operations — service products or services1 — which are
at the core of service operations management. Only
when the “what” to be produced is determined can a
service operations system be designed and further proceed in the right direction. Provision of quality service
1
The International Organization for Standardization defines service as a subset of product (ISO 9004-2, 1991).
0166-4972/01/$ - see front matter  2001 Elsevier Science Ltd. All rights reserved.
PII: S 0 1 6 6 - 4 9 7 2 ( 0 0 ) 0 0 0 8 5 - 7
16
Q. Ma et al. / Technovation 22 (2002) 15–39
Fig. 1. Service operations systems.
products to more demanding customers is necessary for
organizations to retain a competitive advantage.
1.1. Design for quality service products
A service product has its unique characteristics. These
include intangibility, inseparability, perishability and
heterogeneity (Bateson, 1995; Hope and Muhlemann,
1997). “A service may more often mean a product (a
commodity, an output or outcome) of an immaterial nature, for instance a consultation, a sale, a journey, a withdrawal of money from one’s bank account, a concert,
research.…” (Illeris, 1996). Hill (1977) defined a service
as a change in the condition of a person or of a good
belonging to some economic entity, brought about as the
result of the activity of some economic entity. In other
more simple terms, services are deeds, processes, performances or acts that a service operations system provides to customers (Berry, 1980; Lovelock, 1992; Zeithaml and Bitner, 1996; Hope and Muhlemann, 1997).
Goncalves (1998) treated services as special offerings.
Services are often treated as experiences. It was proposed that when a customer purchases a service, he or
she purchases an experience created by the service operations of a service organization (Bateson, 1995; Tseng
et al., 1999). “Because services are experiences, moods
and emotions are critical factors that shape the perceived
effectiveness of service encounters” (Zeithaml and
Bitner, 1996).
Regarding this abstract product, most research focuses
on its quality and customer satisfaction issues. Dimensions of service quality, quality assessment methods and
factors affecting service quality, customer satisfaction
and retention, such as service personnel, facilities, facilitating goods, etc., are investigated both theoretically and
empirically (Berry et al. 1988, 1990; Parasuraman et al.
1988, 1991; Bitran and Hoech, 1990; Bitner, 1992;
Lockwood and Jones, 1989; Ghobadian et al., 1994;
Mattsson, 1994; Sulek et al., 1995; Ennew and Binks,
1999). In addition, there has been a tremendous amount
of research on service classification. Most service classification schemes “appear to be to provide readers and
managers with significant strategic insights for the management and positioning of service systems and organizations” (Cook et al., 1999).
When we imagine a manufactured product like a TV
set, we have a clear product boundary and could determine a product unit. We could not imagine even a simple
manufactured product like a child’s toy being produced
without detailed engineering design specifications and
representation. The thought of designing quality into
products has been widely accepted in manufacturing.
Although the role of design in service organizations has
been poorly defined, designing service products has
attracted attention among researchers (Grönroos, 1990;
Chase and Youndahl, 1992; Hollins, 1992). Service products can indeed be designed. Design is even important
for making such intangible products “visible” and manageable, and it is considered as the key to quality. “A
thoughtfully and [adequately] designed service can lead
to great customer satisfaction. Good service design thus
has a strong impact on perceived service quality and on
the attitude and demeanor of service providers” (Sisodia,
1992). In a sense, designing service products to maximize quality and customer satisfaction facilitates organizations obtaining substantial competitive advantage.
Through design, the situation where service products
have often evolved ad hoc to their present states and
organizations compensate for the absence of welldesigned service products by trying to please customers
through extravagant remedies, can be changed. If a service product is not designed carefully before being
launched, it would be difficult for employees to deliver
it correctly and quality problems follow (Grönroos,
1990). Of course, in addition to good designs, quality
service products also require that service production be
well planned and proceed correctly.
1.2. Architectural conceptualization and
representation of service products
In order to facilitate and advance the design practice
and the effective production and marketing of service
products, an architectural conceptualization with a
higher degree of formalization and a tailored design representation technique are needed. The conceptualization
must characterize the rationale about the “physical” realization, i.e., the construction of service products from
parts to the whole in the engineering design view. With
such a conceptualization, a good understanding of the
architectural aspects and the representation of service
products can be attained and the fuzziness in identifying
the “abstract” product can be minimized. It can perform
as a common context for both systematic considerations
Q. Ma et al. / Technovation 22 (2002) 15–39
of design solutions and effective coordination and communication among different participants in design activities. Moreover, it can facilitate defining service product
design methodologies. This follows the underlying thesis
in design theory: “the design process is, of course,
dependent on the object to be designed, but can be studied and presented in a general form. The more concrete
the object class is, the more completely can the design
process be defined” (Hubka and Eder, 1996). In simple
terms, “we need a good model of services as objects to
be produced, marketed, and consumed” (Grönroos,
1990).
A design representation technique is desired to build
service product design representations. A service design
representation means a description or an account made
in a written form to specify, visualize, construct and
document the design solution of the object being
designed. It serves the following purposes: (a) demonstrating the internal properties of a service product being
designed; (b) testing and improving the design solution
by effectively conducting systematic examination of
whether the product conforms to target customers and
where the improvement opportunity exists; (c) aiding
design thinking2; (d) facilitating understanding, coordinating, and communicating the design. A representation
intends to contain adequate information for service product implementation, acts as a bridge connecting the
design domain with the operations system, and provides
more explicit guidance for service operations management. The representation of a service product would
enhance a profound understanding of what a service
operations system tries to convey to customers.
1.3. Related work
A limited literature has been devoted to the conceptualization and the representation of service products
from the architectural perspective. The concept of the
service package is proposed in the early literature. The
service as a product is described as a package or bundle
of different services — the core service (or substantive
service) and the auxiliary services (or extra services)
(Eiglier and Langeard, 1981; Langeard and Eiglier,
1987; Sasser et al., 1978; Norman, 1984). By realizing
the necessity of thorough understanding of service products for development, Grönroos (1990) suggested a
model of service as a product that can be developed,
produced, and delivered, marketed and consumed.
According to Grönroos, the service as a product consists
2
While a representation is being scanned by designers at any stage
of the design process, cues may evoke relevant information about
details to be attended to, about constraints that have been violated,
about alternatives that have not been considered — information that
is outside the focus of attention when previous decisions are made
(Simon, 1995).
17
of (1) a basic service package, which includes elements,
namely, core service, facilitating and supporting services, and goods; (2) an Augmented Service Offering,
where accessibility, interactions and customer participation aspects of service production and delivery are
added; and (3) image and market communication. Fitzsimmons and Fitzsimmons (1994, 1997) defined a service package as a bundle of four components: supporting
facility, facilitating goods, explicit services, and implicit
services. Emphasizing that service marketers should be
focused on enhancing and differentiating “realities”
through manipulation of tangible clues, Berry and Seiders (1992) discussed the physical environment, communications, and price, and showed that this evidence
shapes and facilitates impressions and perceptions of service quality. In Zeithaml and Bitner (1996), three categories of service evidence are distinguished: people, process and physical evidence, and are then considered as
factors presenting marketed services. Edvardsson and
Olsson (1996) presented a frame of reference for the socalled service development, which includes three main
types of developments: the development of the service
concept, the development of the service system
(company’s staff, the customers, physical/technical
environment, and organization and control) and the service process development.
In general, the literature appears to analyze
(decompose) service products from different focuses and
in various categorized aspects. These types of conceptualizations can aid to some extent the design and strategic positioning of service products. Even though their
usefulness is limited due to some weaknesses, these
studies are the leading work toward the architectural
conceptualization of service as a product, and form the
basis on which a further attempt is made to model service products with a higher degree of formalization suitable for design. The major weaknesses are identified as
follows. Basically, they do not include a transparent and
formal conceptualization of service products in terms of
structural integration of consolidated elements. Consequently, what constitutes a service product is still not
well characterized. Developing a service product model
is most likely beyond the focus of some of the work, for
example, Berry and Seiders (1992), Zeithaml and Bitner
(1996), and Edvardsson and Olsson (1996). Second,
some components are abstract and thus difficult to capture. The core service and auxiliary services are very
broad, and may cause ambiguity in distinguishing
between them. A similar problem can be found in
Fitzmmons’s service package concept, where it is difficult to handle the explicit service and implicit service
when trying to design and represent them explicitly.
Third, Grönroos’s model could be confusing. We can
argue that core service, facilitating services (and goods),
and supporting services (and goods) may totally generalize a service product. Indeed, we cannot arbitrarily
18
Q. Ma et al. / Technovation 22 (2002) 15–39
say that these elements do not say anything about the
process elements that materialize the customer’s perception of service quality without considering their secondary specifications. As parts of a service product, they are
not merely the concepts but the substance. For example,
the core service of an airline service product is transportation, which naturally has the elements, such as the customer’s participation and the interactions (contacts) with
the aircraft and the staff on board, as its constructs.
Therefore, it would be reasonable to consider the
elements like accessibility of the service, interaction and
consumer participation as “decomposed components” of
the basic service package rather than some parallel parts
with it. Similarly, image and market communication are
simply among the total service experience evidences,
which may have impact, to some extent, on customer
perception of service quality. Also, they should not be
regarded as parallel with the basic service package.
Regarding representation of service product, the service blueprint (Shostack, 1984) with its related versions
(Kingman-Brundage, 1992) would be counted as an earlier relevant attempt. Unfortunately, we are not aware of
any recent literature in representing services as products
that can be designed, produced, marketed and consumed.
A service blueprint depicts in a simple way the operations process of a service system and captures a service
as its product. Its utility is identified in the literature as
service quality improvement and control, and productivity improvement (Kingman-Brundage, 1992; Fitzsimmons and Fitzsimmons, 1994; Bateson, 1995; Ramaswamy, 1996; Zeithaml and Bitner, 1996; Hope and
Muhlemann, 1997). However, it has some weaknesses if
it is to be used for service product design. First of all,
it does not separate the depiction of a service from that
of its operations. In this way, service products may be
difficult to conceptualize and visualize from the design
and marketing perspective. Second, a service product
design requires many specifications of aspects that are
geared to the total customer perception of product quality than the flowchart would suggest. For example, how
do we express the design specifications of service facilities (seating room, for instance) that the customer has
contact with? The customer has an impact on the service
product he or she perceives. How are the expected qualifications of the customer and the required customer training represented? Third, the technique is basically a traditional flow diagram and lacks normative notation
definitions. For example, the meanings of the box and
arrows are often ambiguous and inconsistent and not
well defined (Congram and Epelman, 1995).
In fact, the design tradition (practice) in service products has not yet developed much. The management of
service organizations is far too often guided by the operations focus and limited consideration of the design of
their products. Perhaps among the main reasons for this
are the fuzziness in identifying a service product from
the architectural perspective and the lack of a representation technique that is tailor made for the product
design. As a result, in practice, service products usually
result from haphazard evolution over time with vague
identification, rather than through systematic designing.
1.4. Purpose of the article
This article first tries to consolidate the views on service products by proposing a conceptualization (an integrated schematic representation) that provides an architectural perspective from which to think systematically
about the underlying design elements that are general for
the definition of various service products. This generic
model of service products helps reduce the fuzziness of
the boundaries in defining a service product and achieve
a design with a high degree of integrity by taking the
insight and findings in the field of service research.
Second, on the basis of the model, the paper introduces
a design representation technique with which one could
demonstrate a service product design by means of formal
written description. The result of the research may be
useful in practice and in research on service product
design and operations management.
Section 2 presents a service product model built on
the concept of customer service experience (Bateson,
1995) by absorbing previous work. Section 3 provides
a representation technique. Closing remarks are provided
in Section 4. Abstraction and generalization and system
design methods are the underlying research methodology
followed in this research.
2. A generic model of service products
Being aware of the active role of the customer, a
model of service products has to be customer oriented
and geared to the total customer quality perception of
services (Grönroos, 1990). It is easily realized that a
natural way of conceptualizing a service product is along
the course of customer service experience, i.e. from the
customer protocol. Accordingly, consider the definition:
a service product — an output or a transaction unit of
service organizations have with their customers — is
defined as a customer service experience. This definition
means that what a service operations system generates
for its customers and what customers purchase or perceive of services are indeed customer service experiences. A customer service experience refers to the totality that the customers experience starting from entering
(or pre-entering) to leaving a service operations system
with value perceptions.
The customer receiving the services must participate
in the service operations, even if the level of customer
participation — low, medium or high — may be different. Starting from entering the operations system, the
Q. Ma et al. / Technovation 22 (2002) 15–39
customer driven by the goal of added benefits will
behave or act following the routine explicitly or
implicitly established as the operations logic until leaving the system. In the process, the customer as both consumer (“buyer”) and “co-producer” may contact service
personnel, make use of service facilities, wait or line up,
receive information or facilitating goods, etc. All the evidence accumulated by the customer over time constitutes
a customer service experience. That is, the customer
leaves with an experience added, which physically
shapes what the customer “buys” in terms of experience
evidence, and what the resources of the operations system are transformed into.
Certainly, the customer makes assessments of the utility of the service experience based on perceptions of
what is experienced. The reason why customers experience a service operations system is that they consider
it represents values they are looking for. In a service
experience, the customers make judgments about what
they perceive and consequently have value perception
(positive or negative); their satisfaction or dissatisfaction
(if any) thus comes about (Tseng et al., 1999).
Taking recognition as the point of departure, our
attempt to create a generic model is provided in Fig. 2.
The model illustrates the underlying generic components
and their relationships involved in specifying a customer
service experience. These components can be important
for defining, positioning and differentiating service products.
Fig. 2 shows that customers, the customer process
flow, multiple (one or more) activity inputs, and multiple
activity outcomes together define a customer service
experience (a service product). In turn, multiple customer activities and execution transitions assemble into
a customer process flow. A customer activity associates
with multiple inputs and outcomes. Inanimate physical
evidence, contact employee, and fellow customer
environment are three kinds (sub-classes) of activity
input. An activity outcome can be an event or an inanimate physical evidence.
2.1. Customer
A customer service experience always corresponds to
a consumption unit. A consumption unit may be an individual (a person), a group of people or an organization.
A customer refers to an individual who participates in
service operations and consumption. For a consumption
unit, one or more customers may be involved in a customer service experience. The customers are the individuals embodying a consumption unit.
The customers are an indispensable base “material”
or part on which a service product can be developed.
There are no service products to be produced without
customers. Taking the role of the qualified participants
of a consumption unit and the actors of customer activi-
Fig. 2.
19
A generic model of service products.
ties, the customers perceive and evaluate what they
experience. Consequently, a customer must have an
impact on the service he or she perceives and be a source
of variation in the quality of service products (Griliches,
1992). In addition, the presence of one type of customer
discourages the presence of another, preferred, type of
customer (Berry and Seiders, 1992).
Thus, the qualification of the customers is an
important part of the design specifications of a service
product in identifying the target customers. The customers can be characterized in terms of attributes such
as age, gender, profession, education, health status or a
combination of them. The customer’s tendency in consumption, for example, economizing, ethical, personalizing and convenience (Fitzsimmons and Fitzsimmons,
1994) may also be used in the description of the customers. For an organization consumption unit, the necessary information about the organization should be associated with the description of the customers.
2.2. Customer process flow
Customer process flow is an aspect of specifying a
service product in terms of what the customer’s “job”
20
Q. Ma et al. / Technovation 22 (2002) 15–39
entails, that is, how the customers participate or “journey” over time from entering to leaving a service delivery system. A customer process flow can be defined as
a network of customer activities that takes one or more
inputs and generates outcomes. It includes both the customer’s “work” to be performed (activities, operations,
or actions) and how the “work” moves between each
sphere (execution orders or temporal and logical
relationships among the activity executions).
Different types of service product may require different customer process flows. In the extreme, the puzzling
customer process flow must lead to defective service
products and disruption to customer satisfaction. The
right service product design and effective production
should orient towards a customer process flow that is
logical and reasonable from both the customer’s view
and an organization’s concerns.
executions of some defined customer activities. The temporal and logical relationships can be classified into three
basic types.
2.3. Customer activity
These relationships form possible structures for a customer process flow and the way customers behave in
the structures.
In a service product, a customer process flow contains
multiple customer activities; each customer activity is
associated with multiple actors, inputs, and outcomes. A
customer activity refers to a behavior unit that defines
what and how the customers do or operate during a service experience. For example, in a car rental service product, a customer reserving a car, using the car, returning
the car, and billing, etc., are customer activities. Searching for and collecting items and then checking-out are
two of the customer activities in a supermarket service.
Each customer activity represents an opportunity for service operations to reinforce or establish customer service perceptions.
The characterization of an activity includes several
aspects of information: processing time, frequency of
occurrence, execution conditions, and its scenario
description (activity script), etc.
A customer activity can, if necessary, be decomposed
further. Decomposition breaks down the activity in the
form of process flow that consists of a set of activities
of less abstract detail and the execution transitions.
Decomposition is the “exploded” description of an
activity, one level lower in the abstraction of details. It
maps an activity in terms of another process flow.
Decomposition follows the “divide and conquer” principle, a powerful mechanism for managing complexity.
By applying this principle repeatedly, it is possible to
specify a customer process flow to any level of detail
from high to low levels of abstraction.
2.4. Execution transition
In principle, if a process flow is constructed
(described) of more than one activity, execution transition must exist. An execution transition refers to a set
of temporal and logical relationships among the
앫 S(ai⫺aj ): the temporal and logical relationship
between activity ai and aj is sequential, meaning that
activity aj is performed only after the completion of
activity ai. In other words, the execution of one
activity depends on the completion of another.
앫 P(ai⫺aj ): the temporal and logical relationship
between activity ai and aj is parallel, meaning that
activities ai and aj are executed either synchronously
or asynchronously.
앫 O(ai⫺aj ): the temporal and logical relationship
between activity ai and aj is optional, meaning that
only one of ai and aj can be executed under some conditions.
2.5. Activity input
Inputs refer to what is put in or processed
(manipulated) by the customers when acting on their
“journey”. Each customer activity involves one or more
inputs, which become the primary evidence of a service
experience. The inputs have far-reaching implications on
adequate specifications of a service product and on customer benefit perceptions. Three kinds of inputs are
further distinguished: inanimate physical evidence, contact employee, and fellow customer environment. These
will be explained in later sections.
2.6. Activity outcome
An activity outcome refers to the target or goal of an
activity. It indicates the result brought about by a customer activity. Each customer activity has outcomes. For
example, an outcome of the customer activity “drawing
money at ATM” can be “correct amount of money drawn
conveniently”. The customer activity outcome is the reason why the activity is necessary regarding a service to
be delivered. When the customer operates by processing
the input, the outcome is expected. From a design point
of view, designers need to specify the outcomes when
designing a customer activity.
The experience of the outcomes embodies customer
perception of the service benefit. The more satisfied customers feel about their activity outcomes, the more competitive is the service product. An excellent service is
created only when every outcome of the customer activities is orchestrated in a superior way. To maintain overall satisfaction, each customer activity has to maintain
Q. Ma et al. / Technovation 22 (2002) 15–39
its own outcomes separately to an appropriate satisfaction level.
Two kinds of outcome are conceptualized: inanimate
physical evidence and events. They will be explained in
sections that follow.
2.7. Inanimate physical evidence
Inanimate physical evidence refers to material cues or
tangible objects that the customers utilize during a service experience. As a kind of input or outcome associated with customer activities, the evidence is processed
by customers and contributes to their experiences subsequently. There has been profound inquiry on this evidence in the context of service businesses. It has been
concluded that the evidence plays an important role in
a customer’s perception of a service. The evidence provides conditions for or enhancement of the performance
of customer activities and the customer’s perception of
service quality, customer values, and customer satisfaction (Bitner, 1992; Berry and Seiders, 1992; Bateson,
1995; Zeithaml and Bitner, 1996; Hope and Muhlemann,
1997; Davies et al., 1999).
From the customer point of view, the evidence may
be established to function as ambient evidence, aesthetic
evidence, a functional facility, a facilitating article, or
marketing communication evidence. Note that the functions are not mutually exclusive for an entity of inanimate physical evidence. This means that an entity may
have multiple functions. Ambient evidence function
refers to the function of creating an environment of temperature and humidity, illumination, noise, odors (smell),
and safety, etc. The influence of the function factors is
“typically neutral or negative, for example, customers
avoid a certain restaurant because it is ‘noisy’” (Berry
and Seiders, 1992). Aesthetic evidence function refers to
the customer’s perception of aesthetics. The function has
strong potential for producing positive customer perceptions and encouraging approach behavior. The Function
of functional facility is to provide customers with
instructions, assistance, support, and/or a means for performing their activity tasks. For example, signage and
technical systems such as tools, devices or equipment
(for instance, ATM in banking, telephone system, Internet system, and electronic commerce system) mainly
have this function.
Facilitating article function conveys to the customers
the value perception resulting from the ownership of certain items or goods that are useful in their own right
or for the information they carry. Supplies from service
providers, goods the customer purchases, customer’s
belongings that are serviced, facilitating items delivered
(along with ownership) to the customers, and the articles
or documents created through customer activities are
often considered to have this function. For example, food
items on an airline, company brochures, replacement car
21
parts, legal documents, medical supplies, or goods being
sold, allow customers to possess and consume them.
Especially important are the deliverables from a service
provider which can present customer benefits in terms
of how well the objects meet their needs. Those articles
may receive more attention when they are the key determinants of customer satisfaction in a service experience.
Marketing communication refers to the function of communicating a service product to customers in the preentering stage and/or the stages of further experience.
Functions such as advertising, displaying menu selections in restaurants, displaying the goods selections in
a supermarket, and brochures (catalogues) facilitate the
service through accessibility and convenience and
enhance service perceptions.
Inanimate physical evidence can be described in terms
of its design attributes and functions. For example, a potted plant may be put in a waiting room for the aesthetic
function. In this case, the attributes of the physical evidence to be described in some service products may
include the type of plant, size, and spatial layout, etc.
Note that although the service provider may not control
some of the evidence, it often needs to be included in
the definition of a service product as necessary experiential evidence.
2.8. Event
An event is a noteworthy change in state or a significant occurrence that has a location in time and space.
When state changes are important enough for us to
acknowledge, they are called events. Sometimes, it is
appropriate to view the outcomes of a customer activity
in terms of what events occur, and thus declare and specify them in a service product. For example, the events,
“order made” and “food collected” can be considered as
the outcomes that are associated with the customer’s
food-ordering activity with respect to a restaurant service. In this respect, although physical objects are
involved, they are not really produced from that activity.
Often, the relevant facts are stated to describe an event.
2.9. Contact employee
Contact employees refer to the service personnel with
whom the customers have contact either face-to-face or
at a distance. Examples are the actors in an entertainment
(drama appreciation) service and the table servers in a
restaurant service. When customers have contact with
front-line personnel, the contact employee is then processed as an input of the customer activity. For instance,
the actors in an entertainment service constitute an
important part of the input associated with the customer
activity of “appreciating drama.”
Often, it is the contact employee that determines the
perception of a service and customer satisfaction and
22
Q. Ma et al. / Technovation 22 (2002) 15–39
loyalty (Bitran and Hoech, 1990; Czepiel, 1990; Schneider and Bowen, 1993; Kelley, 1993; Lockwood and
Jones, 1989; Zeithaml and Bitner, 1996). There is a great
number of factors involved in the contact employee,
which critically influence service quality. Research has
shown that customers generally desire courtesy, good
attitude and helpfulness of the contact employees, and
improper employee operations (behaviors) will frequently cause customer dissatisfaction. Customers want
to be treated with respect and fairness and to know that
the employee cares about their satisfaction (Bitran and
Hoech, 1990). Customers expect the contact employee’s
manners to be reliable, responsive or assured. This exerts
customer demands on the employees’ attributes that
should include flexibility, tolerance for ambiguity, professional skills, an ability to monitor behavior and
change it on the basis of situational cues, and empathy
for the customer.
Contact employees should be specified in terms of
desired properties. For example, the requirements for
contact employees’ biographical data, education background, attributes, professional skills, and training programs, or service operations can be included.
2.10. Fellow customer environment
In some contexts, customers have to act simultaneously in the presence of other customers of other
consumption units. Thus, the environment created by the
fellow customers often affects the nature of the customer’s service experience. Differing fellow customer
environments embody to some extent the variation
among service products which organizations offer.
The noticeable elements (attributes) characterizing fellow customer environment include crowding and social
behavior norms. These factors can either enhance or hinder customer perception of service quality and satisfaction (Martin and Pranter, 1989). In some situations, such
as educational classrooms, restaurants, trains, parking
areas, and shopping centers, the customer will be disturbed by a lot of excessive crowding or fellow customers’ behaviors that are incompatible with social
norms, thereby having a negative effect on perception
of service. Sometimes, it is true, at sporting events, in
movie theaters, and in other entertainment venues, for
example, that an appropriate number of fellow customers
can enhance the service experience (Zeithaml and
Bitner, 1996).
The fellow customer environment should, if anything,
be specified in a service product design. The specification represents a promise that service operations will
make efforts to control the environment to some standard.
3. Design representation technique
3.1. Considerations
A language with well-defined syntax and semantics
provides means for designers to represent a design using
common representation formalism. To approach a language as a technique for service product representation, we
first identify the following considerations — functional
requirements and technical criteria.
3.1.1. Functional requirements
First, the functional requirements or the purposes of
the envisioned representation language are clarified.
3.1.1.1. Facilitate documenting the design of a service
product In designing a service product, designers need
to write down (record) and accumulate their design
decisions on either the components or the assembly. By
doing so, designers can also be reminded of what has
been made and what will be made further through normative guidance. On the other hand, designers need to
modify and edit their ideas. Therefore, the language
should be defined so that designers can be allowed to
represent effectively the various aspects of a service product into an integrated and “tangible” blueprint or design
specification in a well-organized written format.
3.1.1.2. Support design verification It is a necessary
step to verify the product alternatives prior to putting the
design into practice. To achieve effective verification of
design alternatives, sufficient, systematic, and unambiguous information is required to capture potential merits of a service product, such as reliability, responsiveness, empathy and so on. Consequently, the language
should be such that effective verification can be supported by the analyzable representation of a service
design, which accommodates adequate information.
3.1.1.3. Facilitate understanding and communicating a
service product among concerned parties As we are
well aware, a team is often responsible for a design task
and operations management will use the final design
plan. This naturally raises the demand for understanding
and communicating the design among the concerned parties to share it with each other.
With an easily understood representation, the designers can effectively cooperate. An understandable design
plan can provide consistency in its use in managing service operations, such as resource allocation, scheduling,
employee job assignment and training, and customerrole instructing, as well as service operations control
and coordination.
Therefore, the representation language must be able to
offer such formalism that the representation of a service
Q. Ma et al. / Technovation 22 (2002) 15–39
product design is easy to understand and communicate.
People can thereby work together more effectively.
3.1.2. Major technical criteria
The major technical criteria that the language has to
satisfy are then established as follows.
3.1.2.1. Be service product tailored This means that
the language should, in technical features, be tailor made
for the design representation of service products.
Specifically, the service product domain knowledge
should be brought into the definition of the language
which can represent the various aspects of a service product articulated in the generic model. When the syntactic
and semantic constraints are loosely defined, the language is often less competent in providing guidance on
how to represent a service product design and it is apt
to cause ambiguity in understanding and communication
among the community efficiently.
3.1.2.2. Maintain appropriate formality of representation Formality is the formal property of a language,
representing the rigidity and the degree of symbolism of
its applications. The required level of formality may
depend on the purpose served by the representation and
the agent responsible for enacting it. The design representation of a service product is for people to use and
implement. Expressiveness and comprehensibility are
more crucial for human understanding. Product models
will not be used if they cannot be understood. Conversely, a representation should be of such a formality
that it supports people in analyzing a design for verification and reduces the ambiguities that may be caused in
understanding and implementation. That is, the language
should maintain appropriate formality of a service representation.
3.1.2.3. Support flexible granularity of representation
Granularity refers to the extent of detail to which an
object is modeled or represented. As a general guide, if
some part of a service product design is well known
among the concerned parties, larger grained elements
may be applied to the representation. Conversely,
elements with finer granularity are required so as to provide sufficient specifications about the design and avoid
the situation where the description is at too large a
granularity to provide the sufficient details required.
Both large and small granularity may be needed
depending on different needs.
Hence, the language should support flexible granularity: a service can be represented through modeling
elements in any detail level required for verifying,
understanding and communicating a design.
3.1.2.4. Maintain easiness in use and unambiguous
interpretation in meaning That is, the language must
23
have well-defined syntax in terms of completeness, clarity and normativeness. It must also be clear and consistent in the semantic definitions so as to maintain unambiguous interpretation in meaning of a design
representation.
3.2. Representation technique — a language for
design representation
As implied by the proposed generic model, the design
representation of service products is indeed the representation of a process that integrates the functional perspective, behavioral perspective, informational perspective,
and organizational perspective (Curtis et al., 1992;
Wang, 1994; Jablonski, 1995). There is a body of literature emphasizing process representation to support process management including process diagnosis, process
(re)design, process automation, etc. As the core of process representation, modeling (representation) techniques or languages have been investigated. There are
two classes of process modeling languages using formal
notations: visual diagrammatic language and programming process modeling languages. Since the programming process modeling language (AMICE, 1993; Vernadat, 1993; Sutton et al., 1990) has strong limitations in
readability and understandability, most process representations have employed diagrams. Following Curtis et al.
(1992), we maintain that the diagrammatic process
modeling language can offer a promising approach to
service product representation. Diagrammatic representation that combines graphic notations and natural language-like strings as the formalism of appropriated formality can facilitate people’s understanding, and
accurate communication and analysis. Appendix A provides a summary of the major diagrammatic process
modeling languages in the literature.
Considering the requirements stated above, we find
the process modeling approaches could not serve the
design representation of service products well, due to
their weaknesses. All the modeling languages are general
rather than service product tailored. Thus, they appear
to be incapable of representing the aspects of, and have
little guidance to, a service product design. In addition,
their capability in handling flexible granularity is also a
concern for supporting design verification, understanding, and communication.
Object-oriented (OO) modeling notions and methods
(Rumbaugh et al., 1991; Booch, 1994; Martin and Odell,
1996; Harmon, 1998) are powerful for dealing with
modeling complexity in the real world and building a
model in a comprehensive, expressive, understandable
and structured formalism. We recognize that the notions
and technique can provide an innovative and effective
way of conceptually representing the design data about
service products.
Taking into consideration the suggested generic
24
Q. Ma et al. / Technovation 22 (2002) 15–39
model, the requirements on the representation language,
and OO modeling methodology, we seek to expand on
existing process modeling methods by proposing a language for blueprinting service products. This language
provides the common constructs that collectively form
the basis for a service product representation in a visual
diagrammatic format that is composed of simple graphs
and narrative text structured in a uniform way.
In order to specify the proposed language, we adopt
a combination of formal method and precise natural language. The concerned benefits include:
앫 Adopting a formal method to improve the correctness,
rigidity and conciseness of the language specification
and to reduce ambiguities and inconsistencies;
앫 Using natural language to make the specification
comprehensive and easily understood.
This language allows the representation of a service
product design in two parts. The first part, called the
Customer Process Flow Diagram (CPFD), diagrammatically describes the customer journey from a process flow
viewpoint. It contains the circumscribed customer activities (behavior units) and how their executions interrelate
with each other. The second part, called the Experience
Entity Representation Diagram (EERD), allows depiction of service product design data about the inputs, outcomes and the customer, as well as their relevance to
each other and to customer activities.
3.2.1. Customer process flow diagram
3.2.1.1. Primary constructs and arrangement rules
Syntactically, the primary building blocks of CPFD
include: StartPoint, AchievementPoint, CustomerActivityClass, ArrowLink, SequentialJunction, AuxiliaryNode. The following rules define the schema in
which these primary constructs are connected to build
the CPFD of a service product.
R1. For a StartPoint,
앫 there is only one ArrowLink such that it connects
the StartPoint by its tail end.
R2. For an AchievementPoint,
앫 there is only one ArrowLink such that it connects
the AchievementPoint by its arrow end (head).
R3. For a CustomerActivityClass,
앫 there exist only two different ArrowLinks, one connects the CustomerActivityClass by its arrow end
and the other by its tail end.
R4. For an AuxiliaryNode,
앫 there is only one ArrowLink such that it connects
the AuxiliaryNode by either its arrow end or its
tail end.
R5. For an ArrowLink, any one of the following cases
is valid:
앫 its tail end connects to a StartPoint and the arrow
end connects to a SequentialJunction.
앫 its tail end connects to a SequentialJunction and
the arrow end connects to a CustomerActivityClass.
앫 its tail end connects to a CustomerActivityClass
and the arrow end connects to a SequentialJunction.
앫 its tail end connects to a SequentialJunction and
the arrow end connects to an AchievementPoint.
앫 its tail end connects to a SequentialJunction and
the arrow end connects to another SequentialJunction.
앫 its tail end connects to a SequentialJunction and
the arrow end to connects an AuxiliaryNode.
앫 its tail end connects to an AuxiliaryNode and the
arrow end connects to a SequentialJunction.
R6. For a SequentialJunction,
앫 there is one or more ArrowLinks that connect the
SequentialJunction by their respective arrow
ends, and
앫 there is one or more other ArrowLinks that connect
the SequentialJunction by their respective tail
ends.
R7. For two different SequentialJunctions,
앫 there exists either only one or no ArrowLink that
directly connects the two SequentialJunctions by
its ends.
3.2.1.2. Semantics and notations of the constructs
3.2.1.2.1. CustomerActivityClass This is an object
class notion based construct tailored to represent customer activities in a service product. It describes all
(potential) unique customer activities that possess similar properties and are carried out by the customers following a same pattern. For example, “ordering food”
may be defined as a customer activity class describing
all the “ordering food” activity instances in every day
restaurant service products.
A CustomerActivityClass has a name, attributes, and
an operation. An activity attribute represents a structural
property of a class of customer activities. In general, a
customer activity class may include the following
properties:
앫 processing time — the duration of an activity
앫 frequency of occurrence — how frequently the activities occur
앫 execution timing — requirements on the relative timing (synchronization) of the execution (starting or
completion) with that of other activities
앫 constraints — conditions that need to be met for an
occurrence of an activity to start, continue, or terminate (stop)
앫 other assertions
Q. Ma et al. / Technovation 22 (2002) 15–39
Fig. 3.
CustomerActivityClass notation.
An activity operation describes the behavioral property of a class of activities, i.e., the processing steps of
the customer activities. An activity starts when its operation is triggered; an activity terminates when its operation stops.
A CustomerActivityClass is drawn as a solid-outline
rectangle with three compartments, a top, a middle and
a bottom, separated by horizontal lines and occupied by
sub-constructs. The top compartment holds an
ActivityName expressing the name of an activity class;
the middle compartment is for showing the attributes
given by ActivityAttributes; the bottom compartment
holds the operation given by an ActivityOperation. For
example, CustomerActivityClass notation is shown in
Fig. 3.
Writing the name, attributes and operation follows the
syntax below, which is written in BNF-like form (see
Appendix B).
ActivityName 芰= Ica : Gerund-phrase // Gerundphrase: a gerund phrase string
Ica 芰= CA IntegerNumber
IntegerNumber 芰= 1兩2兩3兩…
ActivityAttribute 芰= ActivityAttributeName = ↵Attribute
Value
ActivityAttributeName 芰= String // String: a string
AttributeValue 芰= STF // STF: a written representation in strings, tables, figures or
the combination of them
ActivityOperation 芰= ActivityOperationName {↵Activity
Script}
ActivityOperationName 芰= Gerund-phrase ( )兩Verbphrase ( )
ActivityScript 芰= (PrototypicalActionSequence兩Script)
[decomposition: ↵DecompositionDiagram] // Item in [ ] is optional
PrototypicalActionSequence 芰= Event ; (ActorAction ;
Event)+.
Event 芰= Noun-Phrase PastParticiple-Phrase //
Noun-Phrase: a noun phrase; PastParticiple-Phrase: a past participle phrase
ActorAction 芰= Verb Noun-Phrase // Verb: a verb
string.
An Ica gives a code shown by the reserved word CA
(meaning customer activity) followed by an integer num-
25
ber to identify a customer activity class. A Gerundphrase is a gerund phrase and is used as a part of a name
string that can be understood literally. An ActivityAttributeName denotes the name of an activity attribute and
an AttributeValue the value of attribute. An ActivityOperationName and an ActivityScript define a name and
specification of the activity operation, respectively. An
ActivityOperationName can be either a Gerund-phrase
or a Verb-phrase (a verb phrase). An ActivityScript can
be shown in two alternative modes: one is the prototypical action sequence and the other is script.
A PrototypicalActionSequence specifies the operation
of an activity in a prototypical action sequence. It is
shown in restricted, template natural language. An Event
means an event and an ActorAction the actor’s action. In
general, a PrototypicalActionSequence contains the most
important events and the actor’s actions that offer a concise understanding of the operation of a class of customer activities. For example, consider a CustomerActivityClass named as “ordering food” for a catering
service. The PrototypicalActionSequence can be composed as follows:
Customer arrived (at counter);
Make an order;
Order placed;
Wait for fulfilled order;
Order prepared;
Collect food;
Order completed.
A Script denotes an ActivityScript in a script mode. A
Script declares, in more flexible natural language, the
prescriptive or proscriptive actions of the customer, the
critical conditions under which the actions happen, as
well as the involved inputs or outcomes. As an example,
consider the same CustomerActivityClass named as
“ordering food”. A Script may be shown as follows:
When a customer arrives at food counter, he/she states
his/her order. After the order is placed, the customer
may wait for order fulfillment. When the order has
been prepared, the customer checks and collects food
he/she ordered. During the period, the customer may
have an evaluation on the behavior of the employee
he/she contacts.…
If a CustomerActivityClass is highly complex, it may
need to be decomposed into a component process. For
this purpose, an optional item marked by the reserved
word decomposition can be chosen as a part of the composition of the ActivityOperation. A DecompositionDiagram expresses diagrammatically the decomposition of
a customer activity, which can be built following the
same method as for building CPFD.
26
Q. Ma et al. / Technovation 22 (2002) 15–39
Fig. 4. An example of customer activity.
Fig. 5.
Fig. 4 shows an example customer activity given by
CustomerActivityClass.
3.2.1.2.2. ArrowLink and SequentialJunction They
are the building blocks for representing precedence
execution transitions in the customer process flow. An
ArrowLink denotes one-way traffic to “transmit” the
execution control flow. In other words, an ArrowLink
paves a section of road for an activity execution movement (transition) from the completion or termination of
some activities to the starting of others.
A SequentialJunction is just like a “transformer” to
transform its incoming execution control flows into its
outgoing execution control flows. The incoming
execution control flows of a SequentialJunction refer to
the execution control flows on the ArrowLinks that connect the SequentialJunction by their head ends. The outgoing execution control flows refer to the execution control flows on the ArrowLinks that connect the
SequentialJunction by their tail ends. A set of control
conditions (rules) under which the incoming execution
control flows transform into outgoing execution control
flows makes up the transformation mechanism.
An ArrowLink is drawn as an adorned arrow line with
two ends called the head end (arrow end) and tail end,
respectively. The adornment sits just above the arrow
line, identifying an ArrowLink by a string. A SequentialJunction is shown as an adorned solid bar attaching
with a dash-rectangle tag. The adornment sits by the
solid bar, identifying a SequentialJunction by a string.
On the tag, strings represent the transformation mechanism (control conditions). Note that when a SequentialJunction connects only two ArrowLinks, the tag is
allowed to be omitted. In this case, the default control
condition is when the in-coming ArrowLink receives
execution control flow then the out-going ArrowLink
does.
Fig. 5 show an example of an ArrowLink and a
SequentialJunction.
The strings in the box attached on the solid bar are
represented in predicate formulas, which provide a useful, convenient and flexible mode to express the control
conditions in concise propositions. To serve the string
Example of ArrowLink and SequentialJunction.
composition, we suggest two predicates3, several connectives, and related semantics conventions.
Predicates:
앫 signal(x): Arrowlink x has execution control flow.
앫 event(e): event e occurs.
Connectives: ⵩, ⵪, 丣, G, →
Conjunction “⵩” means “and”; Disjunction “⵪” is translated as “or”; 丣 indicates “exclusive or”; Negation “G”
is translated as “not”; Conditional symbol “→” means
“if …, then …”.
Related semantics conventions:
앫 For ArrowLink x that connects a CustomerActivityClass by arrow end, when signal(x) becomes
true, an activity defined by the connected CustomerActivityClass will eventually happen (start).
앫 When an activity defined by a CustomerActivityClass completes or terminates (stops),
signal(x) becomes true for ArrowLink x connecting
the CustomerActivityClass by its tail end.
앫 When a StartPoint is initiated, signal(x) becomes
true for ArrowLink x that connects the StartPoint.
앫 For ArrowLink x that connects an AchievementPoint, when signal(x) becomes true, a customer service experience ends.
앫 For pair AuxiliaryNodes r1 and r2, signal(x) is true
for ArrowLink x that connects AuxiliaryNode r1
implies that signal(y) is also true for ArrowLink y
that connects AuxiliaryNode r2.
Thus, we can express:
앫 which activities will eventually start after one or more
activities complete or terminate
앫 which activities are performed in parallel
앫 which activities are performed optionally
3
Users can define other predicates, if necessary.
Q. Ma et al. / Technovation 22 (2002) 15–39
Fig. 6. A fragment of a customer process flow.
The following examples illustrate strings on the tag
for expressing the precedence execution transitions.
Example 1. Consider J1 and J2 in the diagram shown
in Fig. 6. The control condition expressed by the tag of
J1 expresses the execution transitions: after the completion of the activities preceding the ArrowLink ar1, all
three activities eventually are executed. The control condition expressed by the tag of J2 follows the execution
transitions: the necessary condition under which some
activities following ar8 are performed is the completion
of activity CA1 and CA2, or CA3.
There may be some events that occur along with the
completion of activities. Certain events are often considered as the cause of triggering other activities. In this
case, predicate event(e) can be used for the control condition definition.
Example 2. The control condition regarding J2 shown
in Fig. 7 follows the execution transition, and is translated into the tag attached on J2.
After activity CA2 finishes,
— if event, e1: idle barber found, then activity CA3
will be performed;
— if event, e2: no idle barber found but queue length
acceptable, then activity CA4 will be performed;
— if event, e3: no idle barber found and queue length
not acceptable, then activity CA5 will be performed.
In Fig. 7 the tag of SequentialJunction J1 is omitted.
As mentioned previously, the default control condition
is that when the in-coming ArrowLink ar1 receives
execution control flow then the out-going ArrowLink ar2
gains execution control flow.
3.2.1.2.3. StartPoint and AchievementPoint
A
StartPoint denotes a start point. It indicates the initiation
of a customer process flow or a decomposition of a customer activity. A start point attribute may be needed to
express the name of a customer process flow or the ownership of an activity’s decomposition. An AchievementPoint denotes the finishing (ending) point of a customer process flow or a sub-process flow described by
an activity’s decomposition. The finishing point marking
27
the end of the customer process indicates that a unique
customer service experience finishes. The finishing point
of an activity’s decomposition indicates that the activity
has been accomplished or terminated. If necessary, an
achievement point attribute can be provided to indicate
the noticeable “achievements” and/or the process flow
(or sub-process flow) that ends.
A StartPoint is shown as a circle; strings can be
placed in the circle to indicate the start point attribute.
An AchievementPoint is a rounded rectangle; strings can
be placed in it to note its attribute. Examples are shown
in Fig. 8.
3.2.1.2.4. AuxiliaryNode
An AuxiliaryNode is a
supplementary notation for expressing execution transitions and indicating where an execution control flow
goes or comes from. It must be used when there are
execution control flows going out of or coming in from
a decomposition diagram. This symbol is also recommended for use when trying to make the diagram
more orderly and readable and avoiding a crowded layout. An AuxiliaryNode connecting an ArrowLink by the
head end indicates where the execution flow on the
ArrowLink goes to, while an AuxiliaryNode connecting
an ArrowLink by the tail end indicates where the
execution flow comes from. Two AuxiliaryNodes with
the same index number are a match. Fig. 9 shows the
notation of the construct, where the index number can
be any form of a string.
3.2.2. Experience entity representation diagram
3.2.2.1. The primary constructs and arrangement rules
The building blocks of the diagram include the
instances of the primary constructs: CustomerActivityClassAlias, X-Class, Generalization, Association,
Composition, ContainmentByReference. The following
arrangement rules define the schema in which the constructs are connected to build an EERD.
R8. For a CustomerActivityClassAlias,
앫 there exist some Association and some X-Class
that describe the participating customer such that
the Association connects by its ends the CustomerActivityClassAlias and the X-Class, respectively;
앫 there exist some Association and some X-Class
that describe the activity input such that the Association connects by its ends the CustomerActivityClassAlias and the X-Class, respectively; and
앫 there exist some Association and some X-Class
that describe the activity outcome such that the
Association connects by its ends the CustomerActivityClassAlias and the X-Class, respectively.
R9. For an X-Class,
앫 there exist some Association, Composition, Generalization and/or ContainmentByReference such
28
Q. Ma et al. / Technovation 22 (2002) 15–39
Fig. 7.
The tag attached on J2.
Fig. 10.
Fig. 8. Example notations of Startpoint and Achievementpoint.
Fig. 9.
AuxiliaryNode construct.
that they connect the X-Class by their respective
ends.
R10. For an Association,
앫 one of its ends connects to a CustomerActivityClassAlias and the other end connects to an
X-Class, or
앫 each of its ends connects to an X-Class.
R11. For a Generalization, Composition or ContainmentByReference,
앫 each of its ends connects to an X-Class.
3.2.2.2. Semantics and notations of the primary
constructs
3.2.2.2.1. CustomerActivityClassAlias
A CustomerActivityClassAlias stands for a class of customer
activities described in the CPFD. In other words, it is
the alias of a customer activity class. It takes the common form shown in Fig. 10. In the box, ActivityName
Notation of CustomerActivityClassAlias.
follow the same syntax as described in CustomerActivity,
identifying a predefined customer activity class.
3.2.2.2.2. X-Class
This is an object class based
construct for describing inanimate physical evidence,
contact employees, events, and fellow customer environments, which associate with a customer activity class
such as inputs or outcomes. Actors are also represented
by this construct.
A name must be prepared to identify an X-Class for
general understanding of the object represented by the
construct. The attributes of an X-Class may be declared
as design specifications of an input or outcome for
understanding and implementation. For example, consider supermarket services. Designers may consider
“shopping physical evidence” as an (or some) object
class. To specify the component of the shopping service
product, design parameters such as temperature, space
size, and decoration may be given for a defined object
class. An X-Class may have several noticeable attributes
to be declared and described. Besides the specification of
static properties (attributes), the description of dynamic
properties — functions or operations by which the class
of objects are concerned as input or outcome, may also
be included in an X-Class.
An X-Class is denoted by a solid-outline rectangle
with three compartments separated by horizontal lines.
The top compartment holds a sub-construct XClassName for declaring the name of an X-Class. The
middle compartment holds sub-constructs X-ClassAttri-
Q. Ma et al. / Technovation 22 (2002) 15–39
Fig. 11.
An example of X-Class.
butes for declaring the attributes of an object class
defined to describe input or outcome. Sub-constructs, XClassOperations, may be placed in the bottom compartment to describe operations of an X-Class. Fig. 11 shows
an example of X-Class.
The involved sub-constructs follow the syntax below:
X-ClassName 芰= Ix : Noun-phrase
Ix 芰= X IntegerNumber
X-ClassAttribute 芰= X-ClassAttributeName = AttributeValue
X-ClassAttributeName 芰= String
X-ClassOperation 芰= X-ClassOperationName { XClassOperationSpecification}
X-ClassOperationName 芰= Verb-phrase ()
X-ClassOperationSpecification 芰=STF
An Ix gives a code to index a defined X-Class and a
Noun-phrase here denotes its literal identification. An XClassAttribute declares an attribute of an X-Class. An
X-ClassAttributeName and AttributeValue together produce the description of an attribute. An X-ClassAttributeName is the identifier of an X-ClassAttribute and an
AttributeValue assigns the named attribute a value. Corresponding to each X-ClassOperation, an X-ClassOperationSpecification explains in more detail the noticeable
behaviors or functions of the defined objects.
In order to specify a class of inputs or outcomes associated with a class of activities, multiple X-Classes may
be needed to define and link together through constructs
Association, Generalization, Composition or ContainByReference. They define a full descriptor of a class of
inputs or outcomes.
3.2.2.2.3. Generalization, Association, Composition,
and ContainmentByReference These adopt, both syntactically and semantically, the notion of “generalization”, “association”, “composition” and “containment
by reference” in OO modeling methodology (UML,
1997; Booch, 1994; Rumbaugh et al., 1991). They are
used to link the inputs, outcomes and actors with an
activity class. Sometimes, the input, outcome or actor
needs to be represented in multiple object classes (XClasses). In this case, the relationships among them can
29
be represented by these constructs to give a full descriptor of a class of inputs, outcomes or actors. Fig. 12 shows
the basic graphical notations of these constructs.
An Association is shown in a solid line with two
naked tail ends (distinguished arbitrarily as tail end a
and tail end b) for connecting two constructs. A Generalization is a solid line with a triangle end. A Composition with a solid diamond end, while a ContainmentByReference is a solid line with a hollow diamond end. If
there is more than one Generalization, Composition or
ContainmentByReference that connects the same construct, a compact tree-like form with one shared end and
line segment can be used (UML, 1997).
For convenience in drawing only, the line segment
may be drawn using various styles, including orthogonal
segment, oblique segment, and curved segment. In order
to avoid a crowded diagram layout, especially in the case
where some classes have multiple relationships with
others and the relationships cannot be represented at a
compact space due to diagram arrangement, each construct can be broken into two parts with breaking and
connecting symbols attached. For example, a Generalization can be in the form as shown in Fig. 13.
An Association connecting two declared object classes
maps an association relationship — the coordination
relationship (not whole/part or generalization
relationship) — between the corresponding objects
(instances) of the associated classes. By the construct,
the most important information about associations
between some classes of objects can be represented. For
example, Associations are always declared between a
CustomerActivityClassAlias and some X-Classes, which
expresses the inputs, outcomes and actors that a planned
customer activity involves. Both ends of an Association
may connect the same class symbol. Such a link implies
an association between two different objects of the
same class.
In the OO concept, aggregation refers to a “partwhole” or “a-part-of” relationship which is built
between classes of objects. In an aggregation relationship, one object represents the component and the other
the assembly. An assembly is called the aggregate and
the components are called the parts. The parts may or
may not exist apart from the aggregate or appear in
multiple aggregates. Aggregation is inherently transitive (Rumbaugh et al., 1991). Aggregation can be
further distinguished into composition and containment
by reference (Booch, 1994). A composition relationship
denotes the strong form of aggregation that requires
that a part instance (component) be included in a composite (an assembly). A Composition here complies
with the above composition concept semantically. An
assembly class connects with the solid diamond end of
a Composition and its component class at the other end.
A ContainmentByReference follows the semantics of
containment by reference in OO modeling method-
30
Q. Ma et al. / Technovation 22 (2002) 15–39
Fig. 12.
Fig. 13.
Basic graphical notations of relationships.
A Generalization in broken format.
ology. Different from composition relationship, a containment by reference denotes a less direct kind of
aggregation.
The semantics of Generalization also follow the OO
generalization concept. A generalization means a taxonomic or inheritance relationship between a general class
and a more specific class. A generalization presents akind-of link between a class (sub-class) and another class
(super-class). The class connecting the tail of a Generalization refers to the sub-class and the class connecting the triangle-end of the Generalization the superclass. A sub-class inherits properties from local
(segment) declaration and all the relationships of its
super-class. A sub-class presents a variant of its superclass and extends more refined information.
In order to achieve semantically clearer expression of
the relationship represented by Association, Generalization, Composition or ContainmentByReference, some
attributes can be specified. This can be achieved by putting adornments on a construct. The sub-constructs for
the adornments include RelationshipName, Role, Multiplicity and AuxiliaryNote. A RelationshipName is used
only to name an Association and provide a simple understanding of the relationship. It is shown in the form of
a literal word string.
Each end of the Association, Composition or ContainmentByReference constructs has a Role and a Multiplicity
adornment standing by. A Role at the same end as a
class construct indicates the role played by the class in
a relationship. Since the role played by a class, which
connects at the diamond end, always implies “whole,
aggregate or assembly” and “part” at the tail end, a Role
is often omitted at the diamond end of a Composition or
ContainmentByReference. A Role is also represented in
a literal word string.
A Multiplicity here has the same meaning as the multiplicity concept in OO methodology. It specifies how
many instances of the class at a given end (the one bearing the Multiplicity) of a relationship relate to a single
Fig. 14.
The format of an AuxiliaryNote.
instance of an associated class at the other end of that
relationship. A Multiplicity specification is shown in the
format (UML, 1997):
Lower-bound .. Upper-bound,
where a Lower-bound and an Upper-bound are literal
integer values. In addition, the asterisk (*) character may
be used for an Upper-bound, representing an unlimited
bound. A Multiplicity is also allowed to comprise a single *. Then it is equivalent to 0..*. For example, 0..1, 2,
1..*, 1..5 are some valid specimens of Multiplicity.
AuxiliaryNote is an optional construct. An AuxiliaryNote is attached for auxiliary specification of an
Association, Composition or ContainmentByReference
when the important or special explanation of such a
relationship is needed. The use of an AuxiliaryNote can
provide a more detailed explanation of the associated
Roles, Multiplicity and other additional information
about the concerned relationship, such as relationship
constraints or rules. Fig. 14 shows the format of an
AuxiliaryNote. The auxiliary explanation is shown on the
tag in literal word (natural language) strings.
Fig. 15 illustrates an Association with sub-constructs
for adornments.
3.3. Illustrative example
A Gas company is a leading provider of gas energy
to the residential customers in a city. It has had a good
image amongst its large number of customers thanks to
its provision of quality natural gas. To remain successful
in competitive climates, the company has held the managerial philosophy of customer orientation. Recently, they
have even emphasized that the company should not just
provide customers with natural gas, but provide accessible solutions to their problems encountered in day-today living facilitated by utilizing gas appliances to keep
people well-fed and clean.
Q. Ma et al. / Technovation 22 (2002) 15–39
Fig. 15.
An example of Association.
Accordingly, it was decided that the gas service
should be developed into an even more customer-oriented direction by enhancing customer benefits by marketing services. The company has recognized that the
good working condition of gas appliances utilized by
customers is important to simplify their day-to-day living because, otherwise, it may reduce the utility of gas
energy, cause malfunction or even seriously endanger
the customer’s safety. Therefore, to commit to greater
levels of customer services, they have decided to add
regular inspections and preventive maintenance of residential gas appliances.
In essence, the company is trying to produce and market improved gas service products. We may apply our
proposed service product conceptualization and design
representation technique to identify and portray the gas
service product. Our attempt to do so is partially shown
in Figs. 16, 17 and 18 (see Appendix C) only for the
sake of illustrative explanation. Fig. 16 shows the main
body of the CPFD of the improved gas service product,
where activity CA4 presents a newly added component.
Fig. 17 illustrates a more detailed description of the
operation of CA4 shown in Fig. 16, i.e., the decomposition of CA4. Fig. 18 is a fragment of the EERD of the
service product, where we give only the design specifications of the experience entities — customers, activity
inputs, and activity outcomes — that are associated with
the activities: CA1, all the decomposed activities of
CA4, and CA5. In the modified design, customer activity
CA4 and its associated experience entities (shown in Fig.
18) present the changes of the gas service product in
design, which subsequently require the redesigning,
managing and streamlining of the service operations.
These include making inspection schedules and adding
personnel resources and other necessary resources such
as tools and gas appliance parts.
4. Closing remarks
This paper has proposed a generic model of service
products and a coherent technique for product design
representation. The generic model maintains that the
products that service operations systems or companies
31
produce and market to customers are customer service
experiences. This architectural (structural) conceptualization of the service product is established by integrating
the factors found through previous research, which
present the customer service perception and determine
service quality and customer satisfaction, into a systematic general definition of customer service experiences.
Well-defined syntax and semantics specify the proposed
technique or language by which a service product design
is represented in two diagrams, namely, a customer process flow diagram (CPFD) and an experience entity representation diagram (EERD), which, in turn, are built
by instantiating the defined common constructs coherent
with the generic model.
Basically, the generic model and the technique may
contribute to the knowledge of service product design.
The conceptualization in terms of consolidated architectural elements underlying a service product provides a
thorough understanding of what a service product is, and
which components, and their inter-relationships, define
a service product. It organizes an integrated scheme that
can help designers take insights, findings and successful
practice in the field into new service product designs.
The design representation technique offers a solution of
representing service product designs. It is geared to the
conceptualization of service products, has well-defined
syntax and semantics, leads to diagram-based design
representation, and adopts OO modeling notions and
techniques. These features allow designers to easily record and document a service product design, and for the
design representation to be comprehensive, consistent
and easy to understand, as well as being highly expressive with the appropriate formalization. For example, with
OO notations and techniques, the product design information can be represented at any particular level of
granularity as necessary. Commonly accepted representational notations in the form of text, tables or figures
are allowed to describe the properties of the object
classes made to define a type of service product. Graphical notations and mathematical predicate expressions,
combined with the activity execution constraints
expressed as the activity attributes, provide the capability
of explicitly specifying various possible execution
relationships.
This will facilitate and enhance service businesses in
the basic paradigm of systematically developing and
designing products, and accordingly designing and managing operations to produce the desired products.
According to the generic model, a service product
presents a customer’s entire value addition chain. Customers have expectations about their service products
based on their value consideration and cumulative life
experience or knowledge. When customers participate in
service production, they always feel how they can be
satisfied regarding their value perception. Therefore,
before being launched, a service product design must be
32
Q. Ma et al. / Technovation 22 (2002) 15–39
validated by analyzing the customer value it can create
and the production feasibility through considering the
defined target customers, the customer process flow
(how the customers journey), and the inputs and outcomes associated with customer activities. For example,
avoiding or capturing such customer activities that are
thought unexpected by the customers. Design representation is a strong aid for validation in various analyses
such as expert team analysis and simulation, etc.
A design representation is a good visual aid in documentation of a service product. The representation of
validated service product design can serve as a guideline
for designing and managing service operations. By taking the representation as the point of departure, managers
can systematically plan and implement service operations needed to generate the service product, for
example, an employee work flow consisting of front-line
employee activities and back-line employee activities,
front-line provider personnel selection and job assignment, and facilities and layout, etc. The representation
can also be used in employee training as a tool for helping employees understand systematically how the product is associated with their efforts, from the customer’s
perspective, and enable them to see beyond their own
narrow job domains. Thus, employees’ consciousness
concerning customer service may be enhanced. As a service product, design may be re-utilized for the product
redesign or similar product designs, the representation
may be stored in a database and become an aid to the
further utilization in a company.
As we have noted, few service organizations have
clear representations of their products. The model and
representation technique can also be applied to portray
the product that the organizations are marketing to the
customers. The current service product representations
provide an organization with a complete recognition of
what its “products” are and with adequate information
for effectively carrying out systematic examination of
whether a product conforms to target customers and
where the improvement opportunity exists. For example,
when customers participate in a service operationssystem, they always want to know the rules, the guide and
orientation for their service journey. Through close and
careful scrutiny, we try to find out whether the current
product and operations can realize this customer need.
In a supermarket, goods on shelves present the customer’s core value. For these kinds of contact objects,
the management should always keep the question in
mind: “Are there items about which customers feel satisfied?”
This research provides a well-formed framework of
discourse on the basics of service operations management and marketing to explain what service product is
and to address the factors of service experiences and service quality in a systematic way. Furthermore, it is hoped
that the generic model can be used as the theoretical
framework for empirical studies on the impacts of the
elements defining a service product on customer service
quality perceptions and customer satisfaction in different
service contexts. In particular, a further issue worthy of
address would be to study the impacts of changes in the
customer process flow on service quality and customer
satisfaction. The development of service product design
methodology and a computer aided design environment
(software) are most relevant for further research. Systematic design methodology has been well explored and
accepted in the context of manufacturing goods (Pahl
and Beitz, 1996; Suh, 1990). But what about service product design from a systematic engineering viewpoint?
What design process should be followed so as to incorporate more effectively customer needs or values into
the design of a service product? A design approach that
can lead to good service product designs is desirable.
We envision a computer aided design environment that
can help in effectively and efficiently recording, storing,
editing and reviewing or even animating and simulating
a service product design that involves time-consuming
paper work (graphical drawings).
Q. Ma et al. / Technovation 22 (2002) 15–39
33
Appendix A. A summary of existing diagrammatic
process modeling languages
Table 1
Category
Language
Advantages
Disadvantages
Simple process diagram
Traditional flow chart
•
Simple
Material flow diagram (Baudin, 1990)
•
Easy to use and understand
• Unable to express complicated execution
relationships
• Lacks the capability to deal with process
representation with multiple perspectives
Acyclic network (Kerner, 1989; Hajdu,
1997)
Advanced process diagram; tend to express Process flow-entity diagram (Grabowski et
more information about process
al., 1996)
EPC & EPC* (Evet-driven Process Chain)
(Zukunft and Rump, 1996; Kim and Kim,
1997)
IDEF3 (Mayer et al., 1992; Kusiak et al.,
1994; Plaia and Carrie, 1995)
• Useful for simple or high level
representation of the processes from
functional and behavioral perspectives
• Suitable for process analysis in terms of • Limited capability in expressing behavioral
operation time and resource consumption
perspective of a process
• Lacks the capability to represent multiple process
perspectives and their details
• Incorporates the advantages of a
traditional flow chart
• Provides simple grammar for the
representation of informational perspective
• Capable of expressing most execution
relationships by simple syntax and
semantics
• Simple way to represent informational
and organizational perspectives
• Explicit representation of the
associations between the participating
objects and the function units
• Capable of expressing most execution
relationships and execution timing by
simple syntax and semantics
• Provides a mechanism to express
functional units and to list the participating
objects
• Limited capability to represent functional,
behavioral and informational perspectives
• No mechanism for representing organizational
perspective
• Unable to handle Exceptional and nondeterministic execution relationships and execution
timing
• Limited capability to represent informational,
organizational and functional perspectives at a
detailed level
• No mechanism to represent relationships among
the participating objects
• Unable to handle exceptional and nondeterministic execution relationships
• No structured and diagrammatic formalism for
expressing informational and organizational
perspectives on a detailed level
• No mechanism to represent the relationships
among participating objects
Event diagram (Martin and Odell 1992,
• Powerful to express behavioral
• Lacks the capability to express informational and
1995)
perspective (various execution relationships) organizational perspective
• No mechanism to express details of functional
perspective
Petri net (Peterson, 1981; Aalst, 1994;
• Powerful to express behavioral
• Lacks a structured format to express
Aalst and Hee, 1996)
perspective (various execution relationships informational and organizational perspectives on a
flexible and detailed level
• Suitable for qualitative process analysis • Limited representation of the functional
perspective details
• Less readable execution relationships
RAD (Role Activity Diagram) (Ould, 1995; • Strong representation of roles
• Unable to express complicated execution
Abeysinghe and Phalp, 1997)
(organizational perspective) and
relationships
dependencies (interactions) between process
steps within roles
• Lacks the capability to express informational
perspective
• Limited representation of the functional
perspective details
Functional description diagram
IDEFO (US Air Force, 1981; Plaia and
Carrie, 1995; Hunt, 1996)
Object flow diagram (Martin and Odell
1992, 1995)
Use case diagram (Jacobson, 1992, 1995)
• Well-defined mechanism to represent
functional, informational and organizational
perspectives with a high understanability
• Directness in expressing the associations
between the participating objects and the
function units
• Strong representation of informational
perspective
• Explicit representation of the
associations between the participating
objects and the function units
• Simple way to model informational
perspectives with easy-to-understand
notations
• Limited representation of the functional
perspective details
• Lacks a structured format to express
informational and organizational perspectives in a
flexible and detailed level
• Unable to express behavioral perspective
• Limited representation of the functional
perspective details
• Unable to express behavioral perspective
• Unable to express behavioral perspective
• Limited representation of the functional
perspective details in a structured formalism
34
Q. Ma et al. / Technovation 22 (2002) 15–39
Appendix B. BNF-like form
We define a BNF-like form to express the production
rules by which to build constructs which appear in juxtaposed symbols. The BNF-like form is as follows:
M芰=awhere the left-hand side is a single non-terminal symbol M, and the right-hand side a is a string of non-terminal
symbols and/or terminal symbols. The sign “芰=” is an operator read as “is constructed by” or “is composed of.” Basically, a production in this form can be interpreted as: a specimen of M takes the form a in which all the non-terminal
symbols have been replaced by their specimens. On the
“right-hand side”, the notations that will be used just for
syntax specification, but not as syntactic symbols, include:
“|”, “+”, “ ” and//”. The notation ““|” is read
as “or alternatively”, meaning that a specimen of a “parent”
symbol will take a specimen of one of the listed symbols.
The notation “+” indicates that the previous grouping may
be repeated zero or more times sequentially. The notation
“ ” is used just to indicate that it is allowed to put all or
part of the content of the symbol that immediately follows
the sign in another place by creating (user-self defined) a
link (reference) to indicate the location of that content. The
notation “//” is an annotation mark for annotating in natural
language the contextual conditions, constraints or some
related note with respect to the concerned production.
Appendix C.
Figs. 16–18
Fig. 16. The CPFD of a gas service product.
Q. Ma et al. / Technovation 22 (2002) 15–39
Fig. 17. Decomposition of activity CA4.
35
36
Q. Ma et al. / Technovation 22 (2002) 15–39
Fig. 18.
A fragment of the EERD of a gas service product.
Q. Ma et al. / Technovation 22 (2002) 15–39
Fig. 18. (continued)
37
38
Q. Ma et al. / Technovation 22 (2002) 15–39
References
Aalst, W.M., 1994. Putting high-level Petri nets into work industry.
Computers in Industry 29, 45–54.
Aalst, W.M., Hee, K.M., 1996. Business process redesign: a Petri-netbased approach. Computers in Industry 29, 5–26.
Abeysinghe, G., Phalp, K., 1997. Combining process modeling
methods. Information and Software Technology 39 (2), 107–124.
AMICE, 1993. CIMOSA: Open System Architecture for CIM, 2nd ed.
Springer-Verlag, Berlin.
Bateson, J.E., 1995. Managing Service Marketing, 3rd ed. Harcourt
Brace College Publishers.
Baudin, M., 1990. Manufacturing Systems Analysis. Yourdon Press
Computing Series.
Berry, L.L., Parasuraman, A., Zeithaml, V.A., 1988. The service quality puzzle. Business Horizons 31 (5), 35–43.
Berry, L.L., Zeithamal, V.A., Parasuraman, A., 1990. Five imperatives
for improving service quality. Sloan Management Review Summer,
29–38.
Berry, L.L., 1980. Services marketing is different. Business May-June,
24–29.
Berry, L.L., Seiders, K., 1992. Managing the evidence in service businesses. Design Management Journal 3 (1).
Bitran, G.R., Hoech, J., 1990. The humanization of service: respect at
the moment of truth. Sloan Management Review 31 (2), 89–96.
Bitner, M.J., 1992. Servicescapes: the impact of physical surroundings
on customers and employees. Journal of Marketing 56 (2), 57–71.
Booch, G., 1994. Object-oriented Analysis and Design.
Benjamin/Cummings Publishing Company, Inc.
Chase, R.B., Youndahl, W., 1992. Service by design. Design Management Journal 3 (1), 9–15.
Congram, C., Epelman, M., 1995. How to describe your service. International Journal of Service Industry Management 6 (2), 6–23.
Cook, D.P., Goh, C.H., Chung, C.H., 1999. Service typologies: a state
of the art survey. Production and Operation Management 8 (3),
318–338.
Curtis, B., Kellner, M., Over, J., 1992. Process modeling. Communications of the ACM 35 (9), 75–90.
Czepiel, J.A., 1990. Service encounters and service relationships:
implications for research. Journal of Business Research 20 (1),
13–21.
Davies, B., Baron, S., Harris, K., 1999. Observable oral participation
in the servuction system: toward a content and process model. Journal of Business Research 44 (1).
Edvardsson, B., Olsson, J., 1996. Key concepts for new service development. The Service Industries Journal 16 (2), 140–164.
Eiglier, P., Langeard, E., 1981. A conceptual approach of the service
offering. In: Hartvig Larsen, H., Heeds, S. (Eds.), Proceedings of
the EAARM Xth Annual Conference, Copenhagen School of Economics and Business Administration, May 1981.
Ennew, C.T., Binks, M.R., 1999. Impact of participative service
relationships on quality, satisfaction and retention: an exploratory
study. Journal of Business Research 46 (2).
Fitzsimmons, J.A., Fitzsimmons, M.J., 1994. Service Management for
Competitive Advantage. McGraw-Hill International Editions,
New York.
Ghobadian, A., Speller, S., Jones, M., 1994. Service quality: concepts
and models. International Journal of Quality & Reliability Management 11 (9), 43–66.
Grabowski, H., Furrer, M., Renner, D., Schmid, C., 1996. Implementation of information system supporting engineering process based
on World Wide Web. In: Scholz-Reiter, B., Stickel, E. (Eds.), Business Process Modeling. Springer, Berlin.
Griliches, Z. (Ed.), 1992. Output Measurement in The Service Sectors.
NBER Studies in Income and Wealth, vol. 56. University of
Chicago Press, Chicago.
Goncalves, K.P., 1998. Services Marketing: A Strategic Approach.
Prentice Hall, Englewood Cliffs, NJ.
Grönroos, C., 1990. Service Management and Marketing. Lexington
Books, Lexington, MA.
Hajdu, M., 1997. Networks Scheduling Techniques for Construction
Project Management. Kluwer Academic Publishers, Dordrecht.
Harmon, P., 1998. Understanding UML: The Developer’s Guide: With
a Web-based application in Java. Morgan Kaufmann Publishers,
San Francisco.
Hill, T.P., 1977. On goods and services. Review of Income and Wealth
23 (4).
Hollins, W.J., 1992. Design in service industries. Design Management
Journal 3 (1), 76–82.
Hope, C., Muhlemann, A., 1997. Service Operations Management.
Prentice Hall, Englewood Cliffs, NJ.
Hubka, V., Eder, W., 1996. Design Science. Springer, Berlin.
Hunt, V.D., 1996. Process Mapping. Wiley, New York.
Illeris, S., 1996. Service Economy. Wiley, New York.
ISO 9004-2, 1991. Quality Management and Quality System Element.
Jablonski, S., 1995. On the complementarity of workflow management
and business process modeling. SIGOIS Bulletin 16 (1), 33–38.
Jacobson, I., 1992. The Object-oriented Software Engineering.
Addsion-Wesley Publishing Company.
Johnston, R., 1994. Operations: from factory to service management.
International Journal of Service Industry Management 5 (1), 49–63.
Kelley, S.W., 1993. Discretion and the service employee. Journal of
Retailing 69 (1), 104–126.
Kerner, H., 1989. Project Management: A System Approach to Planning, Scheduling and Controlling. Van Nostrand Reinhold.
Kim, H., Kim, Y., 1997. Dynamic process modeling for BPR: a computerized simulation approach. Information & Management 32,
1–13.
Kingman-Brundage, J., 1992. The ABCs of service system blueprinting. In: Lovelock, C.H. (Ed.), Managing Service, 2nd ed. Prentice Hall, Englewood Cliffs, NJ.
Kusiak, A., Larson, T., Wang, J., 1994. Reengineering of design and
manufacturing process. Computer Industry Engineering 26 (3),
521–536.
Langeard, E., Eiglier, P., 1987. Servuction, Les marketing Des Services. Wiley, New York.
Lockwood, A., Jones, P., 1989. Creating positive service encounters.
Cornell Hotel & Restaurant Administration Quarterly 29 (4), 44–
50.
Lovelock, C.H., 1992. Managing Service, second ed. Prentice Hall,
Englewood Cliffs, NJ.
Martin, C.I., Pranter, C.A., 1989. Compatibility management: customer-to-customer relationships in service environments. Journal of
Services Marketing 3 (3), 5–15.
Martin, J., Odell, J., 1992. Object-oriented Analysis and Design. Prentice Hall, Englewood Cliffs, NJ.
Martin, J., Odell, J., 1995. Object-oriented Analysis and Design. Prentice Hall, Englewood Cliffs, NJ.
Martin, J., Odell, J., 1996. Object-oriented Method — Pragmatic Considerations. Prentice Hall, Englewood Cliffs, NJ.
Mattsson, J., 1994. Improving service quality in person-to-person
encounter: integrating findings from a multi-disciplinary review.
The Service Industries Journal 14 (1), 45–61.
Mayer, R.J., Cullinane, T.P., Knappenberger, W.B., Perakath, B.,
Wells, M.S., 1992. Information integration for concurrent engineering (IICE). IDEF3 Process Description Capture Method Report,
AL-TRF1992-0057. Air Force Systems Command, Wright-Patterson Air Force Base, OH.
Norman, R., 1984. Service Management. Wiley, New York.
Ould, M.A., 1995. Business Processes. Wiley, New York.
Pahl, Beitz, 1996. Engineering Design: A Systematic Approach.
Springer, Berlin.
Parasuraman, A., Zeithaml, V.A., Berry, L.L., 1988. SERVQUAL: a
Q. Ma et al. / Technovation 22 (2002) 15–39
multiple-item scale for measuring customer perceptions of service
quality. Journal of Retailing 64 (1), 12–40.
Parasuraman, A., Zeithaml, V.A., Berry, L.L., 1991. Refinement and
reassessment of the SERVQUAL scale. Journal of Retailing 69 (1),
140–147.
Peterson, J.L., 1981. Petri Net Theory and The Modeling of Systems.
Prentice-Hall, Englewood Cliffs, NJ.
Plaia, A., Carrie, A., 1995. Application and assessment of IDEF3 —
process flow description capture method. International Journal of
Operations and Production Management 15 (1), 63–73.
Ramaswamy, R., 1996. Design and Management of Service Processes.
Addison-Wesley Publishing Company, Inc.
Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorensen, W.,
1991. Object-oriented Modeling and Design. Prentice Hall, Englewood Cliffs, NJ.
Sasser, W.E., Olsen, R.P., Wyckoff, D.D., 1978. Management of Service Operations: Text and Cases. Allyn & Bacon, London.
Schneider, B., Bowen, D.E., 1993. The service organization: human
resources management is crucial. Organizational Dynamics 21 (4),
39–52.
Shostack, G.L., 1984. Designing services that deliver. Harvard Business Review 6 (1), 133–139.
Simon, H.A., 1995. Problem forming, problem finding, and problem
solving in design. In: Collen, A. (Ed.), Design and System. Transaction Publisher.
Sisodia, R.S., 1992. Designing quality into services. Design Management Journal 3 (1), 33–39.
Suh, N.P., 1990. Principle of Design. Oxford University Press, Oxford.
Sulek, J.M., Lind, M.R., Marucheck, A.S., 1995. The impact of a customer service intervention and facility design on firm performance.
Management Science 41 (11), 1763–1773.
Sutton, S., Heimbigner, D., Osterweil, L.J., 1990. Language constructs
for managing change in processes centered environments. In: Proceedings of the Fourth SIGSOFT Symposium on Software Development Environments. Software Engineering Notes, 15 (5), 206–
217.
Tseng, M., Ma, Q., Su, C.J., 1999. Mapping customers’ service experience for operations improvement. Business Process Management 5
(1), 50–64.
UML, 1997. UML: Notation Guide, Version 1.1, http: www.rational.com.uml.
US Air Force, 1981. In:. Integrated computer aided manufacturing
(ICAM) architecture Part II. Functional modeling Manual (IDEF0),
vol. IV. Air Force Material Laboratory, Wright-Patterson AFB,
Ohio.
Vernadat, F., 1993. CIMOSA: enterprise modeling and integration
using a process based approach. In: Yoshikawa, H., Goossenaerts,
J. (Eds.) Information Infrastructure Systems for Manufacturing.
North-Holland, Amsterdam.
Wang, S., 1994. OO modeling of business process. Information Systems Management 11 (2), 36–43.
Zeithaml, V.A, Bitner, M.J., 1996. Services Marketing. McGraw-Hill,
New York.
39
Zukunft, O., Rump, F., 1996. From business process modeling to
workflow management: an integrated approach. In: Scholz-Reiter,
B., Stickel, E. (Eds.) Business Process Modeling. Springer, Berlin.
Qinhai Ma received his B. Eng and M. Eng
degrees in Management Engineering from
Northeastern University (NEU), China, and his
Ph.D. degree in Industrial Engineering and
Engineering Management from Hong Kong
University of Science and Technology
(HKUST). He previously served as a lecturer in
the Department of Management and Industrial
Engineering, NEU and as a research associate
in the Department of Industrial Engineering and
Engineering Management, HKUST. He is currently an associate professor at the Department
of Management and Industrial Engineering, School of Business Administration, NEU. His research interests include service systems engineering
and management, business process management, product data management, and information system analysis and modeling.
Mitchell M. Tseng joined the Hong Kong University of Science and Technology (HKUST)
faculty as the founding department head of
Industrial Engineering and Engineering Management in 1993 after working in industry for
almost two decades. He started his career in
industry as a manufacturing engineer and progressed through several management and executive positions in IT industry; His research interest is in Systems Design and Mass
Customization. He held faculty positions at the
University of Illinois at Urbana-Champaign and
Massachusetts Institute of Technology. He has also been consulting for
several leading companies in the US and Asia. Professor Tseng earned
both his M.S. and Ph.D. degrees in Industrial Engineering from Purdue
University. He is an active member of CIRP.
Benjamin Yen received his B.S. degree in
Computer Science and Information Engineering
from the National Chiao-Tung University, Taiwan, his M.S. degree in Computer Science and
both M.Phil. and Ph.D. degrees in Industrial
Engineering and Operations Research from
Columbia University, USA. Before he joined
HKUST as an assistant professor at the Department of Industrial Engineering and Engineering
Management, he collaborated with many companies and research labs in the USA, such as
Siemens, Bell Labs, Philips Labs, Paragon Management Systems, etc. He also has been serving as an associate editor and
guest editor for the Journal of Electronic Commerce Research, Industrial
Engineering Research, and the Annual Journal of Institute of Industrial
Engineers (HK). His research interests include electronic commerce in
industrial applications, production information systems, information technology in supply chain management, and scheduling theory and systems.