Alter 2012

This article was downloaded by: [130.133.8.
114] On: 01 July 2015, At: 04:29

Publisher: Institute for Operations Research and the Management Sciences (INFORMS)
INFORMS is located in Maryland, USA
Service Science
Publication details, including instructions for authors and subscription information:
http://pubsonline.informs.org
Metamodel for Service Analysis and Design Based on an

Operational View of Service and Service Systems
Steven Alter,
To cite this article:

Steven Alter, (2012) Metamodel for Service Analysis and Design Based on an Operational View of Service and Service Systems.
Service Science 4(3):218-235. http://dx.doi.org/10.1287/serv.1120.0020
Full terms and conditions of use: http://pubsonline.informs.org/page/terms-and-conditions
This article may be used only for the purposes of research, teaching, and/or private study. Commercial use
or systematic downloading (by robots or other automatic processes) is prohibited without explicit Publisher
approval, unless otherwise noted. For more information, contact [email protected].
The Publisher does not warrant or guarantee the articles accuracy, completeness, merchantability, fitness
for a particular purpose, or non-infringement. Descriptions of, or references to, products or publications, or
inclusion of an advertisement in this article, neither constitutes nor implies a guarantee, endorsement, or
support of claims made of that product, publication, or service.
Copyright 2012, INFORMS
Please scroll down for articleit is on subsequent pages
INFORMS is the largest professional society in the world for professionals in the fields of operations research, management
science, and analytics.
For more information on INFORMS, its publications, membership, or meetings visit http://www.informs.org
SERVICE SCIENCE
Downloaded from informs.org by [130.133.8.114] on 01 July 2015, at 04:29 . For personal use only, all rights reserved.
Vol. 4, No. 3, September 2012, pp. 218235

ISSN 2164-3962 (print) ISSN 2164-3970 (online)
http://dx.doi.org/10.1287/serv.1120.0020
2012 INFORMS
Metamodel for Service Analysis and Design Based on

an Operational View of Service and Service Systems
Steven Alter
University of San Francisco, San Francisco, California 94117, [email protected]
his paper presents a metamodel that addresses service system analysis and design based on an operational view of
service that traverses and integrates three essential layers: service activities, service systems, and value constellations.
The metamodels service-in-operation perspective and underlying premises diverge from a view of service systems as systems
of economic exchange that has appeared a number of times in the journal Service Science.
In addition to the metamodel itself, this papers contributions include an explanation of eight premises on which it is
based plus clarifications concerning concepts such as service, service system, customer, product/service, coproduction and
cocreation of value, actor role, resources, symmetrical treatment of automated and nonautomated service systems, and the
relationship between service-dominant logic and service systems. Many articles have discussed these topics individually; few,
if any, have tied them together using an integrated metamodel.
Key words: service science; service system; work system; service system metamodel
History: Received March 18, 2012; Received in revised form May 24, 2012; Accepted May 28, 2012. Published online in
Articles in Advance August 22, 2012.
Need for Usable, Design-Oriented Models

Building on previous developments in services marketing, service operations, and economics, the recent initiative
to develop a science of service has generated many service-related academic programs, many articles and white
papers, and several books, as well as this journal, Service Science. At this early stage in the development of
service science, leading proponents have concluded that Service Science is built on top of the Service Dominant
Logic (SDL) worldview (Spohrer and Maglio 2009, Vargo and Lusch 2004[a]) (Spohrer et al. 2010, p. 4),
whereby the essence of service systems involves arrangements, negotiations, and competition in the context of
economic exchange. The SDL worldview deals with many fundamental topics, but its focus and level of analysis
are distant from everyday operational issues that are intertwined with service system analysis, design, and
innovation. For example, Grnroos (2011) dissects the concepts of value creation and value cocreation in depth
and proposes significant revisions to some of the foundational premises of SDL. Regarding one central idea,
he concludes that foundational premise #6the customer is always a co-creator of valueis misleading even
though it is repeated over and over again in the literature (p. 292). Searching for synergies between SDL and
the operational view of service systems emphasized in this paper, Alter (2010c) concludes that those two views
seem like second cousins, with some commonalities but little familiarity. Overall, it is possible that premature
closure regarding the centrality of SDL as the foundation of service science might delay the development of
service science by taking for granted a highly abstract approach that is difficult to use in real-world situations.
This paper proposes a different approach that facilitates description and analysis of service systems from a
management viewpoint. This approach also provides a basis for more detailed descriptions required to build
software support for services in operation. The proposed approach links a simple definition of service with
a straightforward definition of service system that can be represented at different levels of granularity. This
paper applies those definitions in a metamodel of service-in-operation that provides a direct path for addressing
issues that must be resolved in moving from the general concept of a service to the details of service systems.
The metamodel is only partially consistent with the economic exchange model because it focuses on service
systems in operation, is on a different level of analysis, and uses some terms differently. (A metamodel is a
summary of relationships between concepts for producing conceptual models of specific situations in a domain.
For example, the inclusion of the concepts informational entity and actor role in the metamodel implies that
a conceptual model of a specific service system should identify informational entities and actor roles within that
specific system.) This papers alternative view of basic service science concepts can be used to support analysis
and design for service systems, including decomposition of service systems during analysis and design efforts.
Contribution
This papers primary contribution is a metamodel for describing service systems. To highlight the differences
between this papers approach and existing approaches that emphasize economic change, this paper identifies
218
Alter: Metamodel for Service Analysis and Design
Service Science 4(3), pp. 218235, 2012 INFORMS
219
eight underlying premises that express a distinct perspective related to service and service systems. These
premises help to clarify other views of service and service systems. They are also the basis of an integrated
metamodel that spans three levels of concern within service science: service activities, service systems, and
value constellations, thereby extending an earlier metamodel (Alter 2010a) developed to provide an integrated
view of social and technical aspects of work systems. By spanning three levels of analysis, the metamodel
articulates a cohesive view of topics that are usually discussed separately and often in a highly abstract way that
is difficult to operationalize when analyzing or designing service systems. Consistent with Grnroos (2011), the
metamodel views coproduction/cocreation of service as an optional feature of service systems rather than as a
defining characteristic of service in general. Its integrated view of sociotechnical service systems and completely
automated service systems supports decomposition of sociotechnical systems into smaller sociotechnical subsystems and totally automated subsystems, an essential issue in designing IT-enabled service systems. Overall,
the metamodels integrated view of value constellations, service systems, and service activities could facilitate
service analysis and design processes. Its specificity and clarity related to basic terms may contribute more
directly to service system analysis and design than some of the theoretical literatures distinctions related to the
nature of service, service systems, economic exchange, and value propositions.
Organization
The next section explains eight premises that are the basis of the metamodel. These premises form a unique
perspective related to service science topics such as the definition of service and service system, coproduction/cocreation of value, service-dominant logic, and value constellations. The coverage of the metamodel
explains its structure, uses an example to illustrate its potential application, and describes how it is related to
typical service science topics. The Discussion and Conclusion sections explain more about the nature of this
papers contribution and the potential usefulness of the metamodel.
Eight Premises Related to Services and Service Systems

Consider everyday services and service systems such as entertainment services, Internet service provision, plumbing services, transportation services, medical services, rental services, postal services, Web services, and software
development. Surprisingly, some of these services do not fit commonly cited definitions or characteristics of
service. For example, a plumbers work is not intangible and often is not experienced directly by a customer who
may be elsewhere. A vaccination transfers ownership of a physical thing. Subway service is neither customized
nor subject to negotiation between a provider and customer. Also, the emphasis on economic exchange in SDL
is only tangentially useful for analyzing central aspects of medical and transportation services, where economic
exchange is often far removed from direct interactions between providers and customerssimilarly for Web
services, where the provider and customer are computerized entities.
This section identifies eight premises that are the basis of the service system metamodel presented later. These
premises are directly related to the nature of services and service systems, but they overlap only partially with
the perspectives and definitions of service, service system, and related concepts in the nascent service science
literature. Specification of these premises illustrates alternatives to stated or unstated premises that inform views
of service science that are sometimes taken for granted. Underlying this papers approach is the assumption that
unlike genomics or astrophysics, the potential impact of service science depends on providing straightforward
concepts and principles that are understandable to typical university students and business professionals while
also supporting complex analysis at a high level of sophistication wherever that is genuinely needed.
1. Service science should cover the full gamut of service-related situations: The full gamut of service-related
situations ranges from simple everyday services to complex service systems that serve entire societies. Ideally,
service science should cover every type of activity that most people consider a service, including
services for external and internal customers;
automated, IT-reliant, and nonautomated services;
customized, semicustomized, and noncustomized services;
personal and impersonal services;
repetitive and nonrepetitive services;
highly interactive services and services with very little interaction;
long-term and short-term services; and
services with varying degrees of self-service responsibilities.
Even a cursory look at the service science literature reveals that many articles about service science exclude
some of these situations, either implicitly or explicitly. Discussions of service that emphasize the nature of
220
economic competition tend to focus on service for external customers and ignore service for internal customers,
such as payroll, human resources, and internal consulting services. Views of service that assume that the essence
of service is about service interactions between people tend to ignore highly or totally automated services. Other
views of service assume that service is essentially personal and usually customized, contrary to the essence of a
number of the services mentioned above. Ideally, the service science definition of service and service system
should cover every type of service situation.
2. Services are acts performed for others: Service science currently lacks a commonly agreed-upon, readily
usable definition of service that applies to almost all situations that most business professionals, computer
scientists, and other researchers would consider services. Existing definitions of service include the following.
Any act or performance that one party can offer to another that is essentially intangible and does not
result in the ownership of anything (Kotler and Keller 2006, p. 402).
A provider-client interaction that creates and captures value (IBM Research 2009).
A time-perishable, intangible experience performed for a customer acting in the role of a coproducer
(Fitzsimmons and Fitzsimmons 2006, p. 4).
A process in which the customer provides significant inputs into the production process (Sampson and
Froehle 2006, p. 331).
A change in the condition of a person, or of a good belonging to some economic unit, which is brought
about as the result of the activity of some other economic unit, with the prior agreement of the former person
or economic unit (Hill 1977, p. 318).
The application of specialized competences (knowledge and skills) through deeds, processes, and performances for the benefit of another entity or the entity itself (Vargo and Lusch 2004a, p. 2).
Service is value-creating support to another partys practices. As suggested by Normann (2001), this
support may either relieve customers from taking on some task or enable them to do something that otherwise
would not be possible to accomplish or would be accomplished less efficiently or effectively (Grnroos 2011).
A service is generally implemented as a course-grained, discoverable software entity that exists as a
single instance and interacts with applications and other services through a loosely coupled (often asynchronous),
message-based communication model (Brown et al. 2005).
We adopt a simple, dictionary-like definition of service from Alter (2008c, p. 64; 2010d, p. 202): Services
are acts performed for others, including the provision of resources that others will use. To provide symmetrical
treatment for human and automated services for people and services performed by one automated entity for
another (such as Web services), a more general version of the definition from the same sources is services are
acts performed for other entities including the provision of resources that other entities will use.
Both versions of our definition are consistent with the idea in Ramrez (1999) that customer value includes
labor saving value and enabling value. Our definition applies to the three types of value configurations discussed
by Stabell and Fjeldstad (1998): value chains, value networks, and value shops. It covers special cases such
as self-service and automated services for people. In self-service, service providers provide resources that are
used by customers performing self-service activities, whereby the service is the provision of resources, not the
self-service activities. In automated services for people, machines perform the service activities. Both versions
of the definition are consistent with most of the definition in Vargo and Lusch (2004a), except that our definition
stipulates that services are acts performed for others. Thus, activities performed only for ones own benefit, such
as cleaning ones own office or climbing a mountain, are not considered services unless those acts are performed
so that someone else will benefit.
3. Every economic activity is a service: By our definition of service, any economic activity is a service
because it involves purposeful action performed for the benefit of someone else (or something else, in the case of
programs operating under service computing). A focus on services is still useful when thinking about almost any
system in a business because it highlights service metaphors and characteristics often associated with service.
Of special value are the numerous service-related design dimensions (Alter 2010d) that are potentially important
but often overlooked when trying to design or evaluate systems in organizations, such as the extent of customer
responsibility for service activities, the extent of coproduction, and the extent to which activities are onstage or
backstage.
By assuming that every purposeful action performed for the benefit of others is a service, our definition
bypasses the long-standing inability to distinguish between products and services in a way that is genuinely
valuable for designing service systems. Instead, our definition accepts the foundational premise from SDL
that goods are distribution mechanisms for service provision (Vargo and Lusch 2004a, p. 8), according to
which distinctions between products and services may not be fundamental for understanding how value is
delivered. If a service is an act performed for others, then the production of physical things can be viewed as
221
services. Consistent with Vargo and Lusch (2004b), our definition of service does not rely on characteristics
often associated with service, such as intangibility, customization, simultaneity of production and consumption,
time perishability, or involvement of customer interactions or experiences.
Several other implications of our definition are noteworthy. First, the most direct recipients of services may
not perceive their value. For example, a student may not perceive the value of a classroom exercise, an addicted
individual may not perceive the value of a treatment, and a taxpayer may not perceive the value of tax-related
services by tax agencies. These examples illustrate that most service systems have multiple types of customers
with disparate or even conflicting interests. In addition, because laws and ethical codes differ from place to place
and time to time, an assumption that services must be legal or ethical would imply that a lawyer or ethicist
might be required to determine whether something is a service.
4. Product versus service is best viewed as a set of design dimensions, not a simple dichotomy: In relation
to service analysis and design in real-world situations, definitional distinctions between products and services
are much less important than design characteristics that are continuous variables on dimensions ranging from
product-like to service-like. In this context, product-like implies a greater concentration of characteristics
often associated with products, such as tangibility, durability, and ownership; service-like implies a greater
concentration of characteristics associated with services. An offering typically viewed as a product may have
many service-like features, and vice versa.
Consider a series of related educational offerings: a traditional textbook, its online version, an online version
with interactive exercises, an online version with interactive exercises and interaction with an expert, and, finally,
an interactive person-to-person tutorial by an instructor. Each successive modification transforms the productlike book into something that is more service-like until the last approach is clearly a service. Similarly, the
provision of meals can be made more product-like by moving toward prepackaged fast-food meals; it can be
made more service-like by moving toward a fine-dining experience that still consists of tangible things delivered
to customers. Similar examples involve various forms of information distribution, medical care, and many kinds
of work that are performed for customers.
Accordingly, it is unnecessary for the metamodel to differentiate between products and services. Instead, the
metamodel gives the name product/service to anything that is produced by a definable activity in a service
system. It treats an entire service systems products/services as whatever the service systems customers receive,
use, and/or benefit from in a direct way. On the other hand, the metamodel recognizes characteristics that are
often associated with products or services (e.g., commodity versus customized, tangible versus intangible, and
impersonal versus personal). It treats such distinctions as continuous design dimensions, essentially characteristics of a specific product/service.
The design dimension related to the coproduction of value is of special interest because coproduction or
cocreation of value is viewed as essential in SDL and is treated by Sampson and Froehle (2006) as a defining
characteristic of service. From our viewpoint, it is more useful to follow Grnrooss (2011) view that cocreation
of value is optional and to recognize a continuum from minimal through extensive cocreation by the customer.
The customer does nothing.
The customer provides a request for service but does little else (minimal level of cocreation).
The customer participates in parts of service fulfillment processes (beyond specifying requirements).
The service occurs through multiple service interactions, including direct participation by customers.
A self-service approach is used, whereby the customer performs self-service processes and activities using
resources provided by the service provider.
For understanding, analyzing, and improving specific product/service offerings, the interesting question is not
whether value is coproduced, but rather the extent to which customers are or should be coproducers or cocreators
of value. The changes might move toward more cocreation or less. For example, customers who just want
something to be done would try to minimize the extent of cocreation (e.g., services such as cleaning houses or
shoveling snow). In contrast, customers who want to be involved might find ways to engage more directly with
service providers whom they find interesting or inspiring.
5. Service systems are work systems: We define a service system as a work system that produces services,
i.e., that performs acts for others, which may include producing physical things and/or information. The work
system framework shown in Figure 1 identifies nine elements for understanding a work system. These elements
constitute the core of a systems analysis method for business professionals called the work system method (Alter
2006, 2008a, 2008b).
A work system is a system in which human participants and/or machines perform processes and activities using
information, technology, and other resources to produce products/services for internal or external customers. All
work systems that produce something for the benefit of others are service systems, whether or not economic
222
Figure 1. Work System Framework
T
CUSTOMERS
S
N
T
E
R
M
A
N
T
O
PRODUCTS/SERVICES
E
G
I
I
V
E
PROCESSES and ACTIVITIES
PARTICIPANTS
INFORMATION
TECHNOLOGIES
INFRASTRUCTURE
exchange is involved (e.g., service systems directed internally within organizations). Placement of the customer
at the top of the work system framework reflects the work systems goal of producing products/services for
customers, rather than just performing activities. All of the elements of the work system framework will be
reinterpreted in a more detail-oriented service system metamodel explained later. The work system framework
has proven effective at a summary level of understanding. Experience with hundreds of analyses based on the
work system framework shows that the metamodel can be used as the basis of tools designed to clarify details
that are not important at a summary level.
Because a service system is a work system, the nine elements of even a basic understanding of a service
system are the same as the elements for understanding a work system. Table 1 defines each of the nine elements
of the work system framework as though they are elements of a service system. The rest of this paper uses the
term service system except where it is necessary to use the term work system as part of an explanation of
the origin of the ideas.
Our definition of service system overlaps with the definition in the glossary of the CMMI (Capability Maturity Model Integration) for Services, version 1.3 (Software Engineering Institute 2010, p. 498): An integrated
and interdependent combination of component resources that satisfies service requirements. A service system
encompasses everything required for service delivery, including work products, processes, facilities, tools, consumables, and human resources. Note that a service system includes the people necessary to perform the service
systems processes.
In contrast to our definition, a number of service system definitions and related connotations in previous issues
of Service Science rely more directly on concepts associated with SDL (Vargo and Lusch 2004a).
Service Science defines service as value cocreation phenomena that occur when service system entities
interact according to value propositions that guide the application of competence for mutual benefit (Spohrer
et al. 2010, p. 4, italics in original).
The foundations of service systems are (1) a dynamic configuration of resources, (2) a set of value
cocreation mechanism[s] between suitable entities, (3) an application of competencies-skills-knowledge of any
person(s) in job or stakeholder roles, (4) an adaptive internal organization responding to the dynamic external
environment, [and] (5) learning and feedback to ensure mutual benefits or value cocreation outcomes. Thus
Service systems are open systems capable of improving (a) the state of another system through sharing or
applying its resources, [and] (b) its own state by acquiring external resources (Spohrer et al. 2009) (Spohrer
et al. 2010, p. 5).
The smallest service system centers on an individual as he or she interacts with others, and the largest
service system comprises the global economy. Cities, city departments, businesses, business departments, nations,
and government agencies are all service systems. Every service system is both a provider and client of service

223
Table 1. Definitions of Elements of a Service System Based on the Work System Framework and Viewing a Service System
as a Work System
Customers. Customers are recipients of a service systems products/services for purposes other than performing provider
activities within the service system. External customers are service system customers who are the enterprises customers,
whereas internal customers are service system customers who are employed by the enterprise, such as customers of
the enterprises service system for payroll. Customers of a service system may be active participants in the service
system (e.g., patients in a medical exam, students in an educational setting, clients in a consulting engagement). In other
situations, customers request service activities and play no other role in the service system. The image of the customer is
largely an illusion for many important service systems that have different customer types whose interests are different and
possibly divergent, such as a medical service system that serves patients, but provides information for insurance companies,
government agencies, and other external customers. The distinction between direct beneficiary and paying customer is
important wherever service systems are evaluated, at least partially, by paying customers who are not service beneficiaries.
Products/services. Service systems exist to produce products/services for internal or external customers. The term product/service is used because outputs of most service systems exhibit a combination of product-like and service-like characteristics. Product/services are received and used by customers within the service system, within other service systems, or
outside of the context of service systems (as when a service systems customers do not use its products/services for the
benefit of others).
Processes and activities. The actions that occur within a service system are service activities. In some service systems those
activities constitute a process because they have a clear sequence whose individual steps are performed using defined
methods. Other service systems include service activities that may be performed in different ways and in different orders
depending on the judgment of the participants. Activities within a service system are assumed to be the activities that
actually occur, rather than the activities that are supposed to occur. These activities include workarounds that often become
part of organizational routines (Feldman and Pentland 2003) when prescribed activities are too cumbersome to perform or
cannot be performed because of inadequate resources or transient problems.
Participants. Participants are people who perform activities within a service system, including both users and nonusers of
IT. Failure to include participants and their characteristics in service system analysis and design automatically would omit
important sources of variation in the results. Inclusion of the term participant instead of the term user avoids ignoring
important participants who do not use computers and minimizes confusion from referring to stakeholders as users, whether
or not they actually use the technology in a service system. Customers participate in service systems to differing extents.
Information. All service systems use and/or create information, which in the context of service systems can be expressed
as informational entities that are used, created, captured, transmitted, stored, retrieved, manipulated, updated, displayed,
and/or deleted by processes and activities. Typical informational entities include orders, invoices, warranties, schedules,
income statements, reservations, medical histories, rsums, job descriptions, and job offers. Informational entities may
contain other informational entities. For example, orders may contain line items and documents may contain chapters.
Technologies. Almost all significant service systems rely on technology, which may take on one of two operational forms:
(1) tools that are used by service system participants and (2) automated agents, hardware/software configurations that
perform totally automated activities. That distinction is crucial as service systems are decomposed into successively smaller
subsystems, some of which are totally automated.
Environment. Factors in a service systems environment may have direct or indirect impacts on its performance, aspiration
levels, goals, and requirements for change. A service systems environment includes the relevant organizational, cultural,
competitive, technical, regulatory, and demographic environment within which the service system operates, and that affects
the systems effectiveness and efficiency. Organizational aspects of the environment include stakeholders, policies and
procedures, and organizational history and politics, all of which are relevant to the design of many service systems.
Infrastructure. Infrastructure includes relevant human, informational, and technical resources that are used by a service
system but are managed outside of it and are shared with other service systems. From an organizational viewpoint, such
as that expressed in Star and Bowker (2002), infrastructure can be subdivided into human infrastructure, informational
infrastructure, and technical infrastructure, all of which can be essential to a service systems operation.
Strategies. Strategies are conscious allocations of resources to achieve goals. Strategy levels that are relevant to service systems include enterprise strategy, organization strategy, and service system strategy. In general, strategies at the three levels
should be in alignment, and service system strategies should support organization and enterprise strategies. Unfortunately,
strategies at any of the levels may not be articulated or may be inconsistent with reality or with beliefs and understandings
of important stakeholders.
Note. Based on Alter (2006, 2008a).
224
that is connected by value propositions in value chains, value networks or value-creating systems (Normann
2001) (Maglio and Spohrer 2008; cited by Vargo and Akaka 2009, p. 33).
The SDL approach to service systems tends to be quite abstract, focuses on economic exchange rather than
business operations, and treats anything from an individual to the global economy as a service system (Alter
2011a). Concepts such as cocreation of value, value proposition, shared information, and reciprocal service
provision sometimes seem overstated for everyday service systems such as those mentioned previously. Also,
assumptions about mutual benefit sometimes seem exaggerated, as in service situations with conflicting motives,
ambiguous or intentionally misleading value propositions (e.g., advertising), and information asymmetry, and
where service beneficiaries are not paying customers and may have neither information nor decision rights for
choosing among value propositions from different service providers. This papers more operational definition of
service system is easier to apply across a wide range of service situations. On the other hand, it does not try to
address the challenge of characterizing the nature of economic exchange.
6. Service system analysis and design should recognize conflicting stakeholder interests: Each of the typical
services mentioned at the beginning of this section has multiple customer and stakeholder groups, often with
conflicting perceptions of the need for and quality of various things produced by the service system. Thus, the
frequently encountered concept of the customer is often insufficient for describing, designing, or evaluating
service systems. It is more realistic to assume that sociotechnial service systems often have multiple customer
groups and stakeholders whose interests may conflict.
At minimum, interests of customers often conflict with interests of providers because customers are most
concerned with characteristics of whatever they receive from a service system (e.g., cost, quality, reliability),
whereas providers are also concerned with the systems efficiency. Although an idealized service system should
provide excellent service in an internally efficient manner, organizing for internal efficiency may reduce responsiveness to customers and may increase their costs. For example, an organizations accounts payable system may
be designed to maximize the efficiency of accounts payable clerks within the general constraint of paying the
bills on time. From the viewpoint of that service systems customers, immediate payment upon receipt of the
invoice would be more convenient and more profitable.
There also may be goal conflicts between different groups of customers. For example, an information system
that provides up-to-the-minute operational results may satisfy top managements desire to have current information but may cause problems for lower-level employees, who would rather analyze their own operational results
before having to respond to inquiries from managers who receive the same data at the same time. In contrast
with that simple example, complex supply chains and complex service systems in society, such as water systems,
transportation systems, and medical systems, have many different customer groups with significantly different
concerns.
7. Service system analysis and design should recognize impacts of human intentions, capabilities, and variability on service quality: Service system designers and participants are humans whose intentions, capabilities,
and performance variability may affect service quality in many important ways. Issues related to human variability, motivation, information asymmetry, moral hazard, workarounds, bricolage (making do with whatever is
available), and emergent change abound in the organizational behavior and sociotechnical systems literature.
Exceptional dedication and effort may generate outstanding results even with relatively poor resources; inattention and lackadaisical effort may lead to mediocre results even with the best resources; personal agendas
may undermine service system designs regardless of the level of resources. Consequently, careful description,
design, or evaluation of a service system should clarify underlying assumptions about service system participants
because any of the following might describe reality.
The relevant service systems are computerized entities that operate based on computer programs and
therefore do not have participants even though participants in other work systems created and maintain them.
Service system participants are dutiful components of service systems who will perform specified processes and activities consistent with designers intentions and managements goals.
Service system participants are fallible components of relatively fragile service systems that cannot control
participants activities directly but only guide those activities through a combination of training, incentives,
punishments, monitoring, and feedback. Service system participants may have personal agendas and goals that
differ from explicit or implicit goals of service systems and their designers and owners.
8. Service system analysis and design should recognize complementary systems within value constellations:
Normann and Ramrez (1994) extend Porters (1985) idea of value chain analysis with the concept of value constellation, where value is coproduced by actors who interface with each other. They allocate the tasks involved
in value creation among themselves and to others, in time and space, explicitly or implicitly. : : : Coproducers
constantly reassess each other, and reallocate tasks according to their own views of the competitive advantage
225
they perceive each other to have (p. 54). In service system terms, a value constellation is a combination of
service systems that operates across different enterprises to satisfy customer needs. Unlike a supply chain whose
basic structure follows a multilayer bill of materials even if some of the suppliers may change, value constellations for services are assumed to exhibit occasional redefinition and reallocation of responsibilities as new
players create new offerings that may replace or repackage existing activities. Extensions of that idea appear in
various strategy-oriented discussions of value configurations, such as Stabell and Fjeldstad (1998) and Tapscott
et al. (2000).
A given service system may be part of many different value constellations. For our purposes, a value constellation is a set of complementary service systems whose individual operation and interactions contribute to
an identifiable type of service for an identifiable group of customers. The idea of value constellation is of great
potential importance in service science because few, if any, firms can provide all the resources needed to support
value creation by their customers. Detailed attempts to locate service systems within value constellations would
go beyond merely identifying outsourced or out-tasked activities. It would take more of a system view and
would focus on service system characterizations of both the value constellation itself and the various service
systems that it includes.
Metamodel for Service System Analysis and Design

The service system metamodel depicted in Figure 2 (Alter 2011b) is based on the eight premises outlined in the
previous section:
1. It covers the full gamut of service-related situations, including services for external customers and for
internal customers; automated, IT-reliant, and nonautomated services; customized, semicustomized, and noncustomized services, and so on. It supports decomposition of sociotechnical service systems into smaller service
systems, some of which may be totally automated.
2. It views services as acts performed for others (which might be other entities in the case of totally automated services).
3. It treats every economic activity as a service, even though that premise is not central to its purpose of
representing operational service systems.
4. It views product versus service as a continuum, not a dichotomy. It does that by including an entity type
called product/service that has many design dimensions and other characteristics.
5. It treats service systems as work systems by defining many of its entity types as reinterpretations of
elements of the work system framework (see Figure 1).
6. It recognizes conflicting stakeholder interests by including service system environment, organization environment, and enterprise environment, each of which may include noncustomer stakeholders along with culture,
history, policies, competition, and other aspects of the surrounding environment.
7. It recognizes quality-related impacts of human intentions, capabilities, and variability by including an
entity type called participant and assuming that attributes of participants include skills, knowledge, incentives,
interests, and other characteristics that affect human action.
8. It views service systems as components of value constellations.
The service system metamodel in Figure 2 revises and extends a work system metamodel (Alter 2010a)
that was developed to support more detailed analysis than is afforded by the work system framework. That
framework is effective as the basis for preliminary analysis of IT-reliant service systems but is less effective as
a tool for more detailed analysis. The work system metamodel provided clarifications concerning topics such as
why goals were not mentioned explicitly in the work system framework, how customers can be participants, the
relationship between participants and users, and the possibility of largely symmetrical treatment of sociotechnical
work systems and totally automated work systems. Each element of the work system framework is represented
in the metamodel, although most are reinterpreted in a more detailed way. For example, information becomes
informational entity, technology is divided into tools and automated agents, and activities are performed by one
of three types of actors. As in the work system metamodel, the service system metamodel in Figure 2 uses
shading to distinguish between reinterpretations of elements in the work system framework and other concepts
that are not in the work system framework.
Entity Types in the Metamodel
Representation decisions in the metamodel attempt to maximize understandability while revealing potential
omissions from a service system design process. The metamodel uses an icon for composition (see the legend
at the bottom of Figure 2) to identify elements that are likely to be decomposed into smaller elements in some
226
Figure 2. Metamodel for an Operational Service System Within a Value Constellation

Value constellation
environment
affects >
Value constellation
affects >
Environment
affects >
Enterprise environment
Enterprise
affects >
Organization environment
Organization
affects >
Service system environment
< guides
Strategy
Enterprise strategy
< guides
Organization strategy
< guides
Service system strategy
< provides (0 .. *)
Infrastructure
SS social
infrastructure
supports >
Service system
< has interactions other

than input/output (0.. *)
Other
service system
< guides (0..*)
SS technical
infrastructure
contains > (0.. *)
< provides (0..*)
SS information
infrastructure
Process
< provides (0 ..*)
< provides (0 ..*)
provides > (0 .. *)
contains > (1.. *)
contains > (2.. *)
< used as (0.. *)
Informational
entity
< uses product/service while

participating in (0.. *)
produces > (1 .. *)
Resource
< uses (1..*)
Activity
Product/service
used by > (1 ..*)
performed by > (1.. *)
Customer
Technological
entity
< receives and

uses (1..*)
< performs (1.. *)
Actor role
< performs (1 ..*)
< performs (1 .. *)
Participant
uses > (0..*)
Tool
Automated
agent
Customer
product/service
Noncustomer
participant
received and
used by > (1 ..*)
< performs (1.. *)
Customer
participant
Other
resource
A
A affects > B
Generalization: A is a kind of B
Composition: B consists of one or more As
Note. Many elements in the conceptual model have goals, attributes, performance indicators, and related principles, patterns,
and generalizations that do not fit into a one-page representation, and that must be included in more detailed explanations.
analysis and design situations. It names relationships and uses the pointed ends of < and > to indicate the
direction of relationships.
Each entity type in the metamodel has numerous attributes that are not shown in the metamodel but that
might be shown in a second level in a more detailed representation (e.g., as attributes of a class in a UML
(unified modeling language) class diagram). Many entity types have multiple goals, characteristics, metrics, and
relevant principles that cannot be displayed in a one-page representation but could be included in a computerized
227
representation that could be displayed based on a users information needs. For example, attributes of a participant include various types of knowledge and skills, level of motivation, and incentives. An informational
entitys attributes related to size, form, coding scheme (if any), precision, and accuracy depend on the type of
informational entity (e.g., database or document). Most entity types have at least several goal attributes that may
be mutually inconsistent in any specific situation. For example, the role of noncustomer participant may have
a daily output goal but may also have other goals related to error rate, responsiveness to the service systems
customers, or other aspects of quality.
Integrating Service Activities, Service Systems, and Value Constellations
The metamodel for service system analysis and design in Figure 2 covers three levels:
service activities: methods and other details of specific service activities within service systems;
service systems as a whole, and their immediate relationships to and interactions with their customers and
other systems that affect them; and
value constellations: representing the role of a service system within broader value constellations.
The revision of the work system metamodel (Alter 2010a) that produced the service system metamodel in
Figure 2 started with terminology changes, such as replacing the term work system and its abbreviation, WS,
with the term service system and its abbreviation, SS. Value constellation and value constellation environment
were inserted at the top center of the metamodel. The metamodel says that a value constellation consists of one
or more service systems, that a value constellations environment affects the value constellation, that a value
constellations environment is part of the environment that might be considered when designing a service system,
and that the value constellation might affect strategy at any of three levels: enterprise, organization, and service
system. A value constellation is assumed not to have a strategy because it consists of many semi-independent
service systems that are not centrally controlled and that will change and evolve based on their owners priorities.
Resources, Structure, and Intention
Figure 2 is organized to emphasize the interplay of resources, structure, and intentions. In general, the metamodel
is laid out with resources on the left side, structural and operational elements in the middle, and elements related
to intention on the right. The central elements in the metamodel are the service system itself (upper middle),
the activities that it performs (lower middle), and relevant value constellations (top middle).
Resources for a service system include participants, technological entities, informational entities, and other
resources used by activities. Nonhuman resources might be produced by previous activities within the service
system, or they might come from other service systems, from the environment, or from any of three components
of the infrastructure. The entity type other resources refers to noteworthy resources that are not informational
entities, technological entities, or human participants. Examples include office buildings, transportation equipment, and natural resources such as a sunny climate, which might be very important for service systems in a
resort hotel.
Structure starts with the value constellation, enterprise, and organization. Value constellations contain a number
of service systems. Value constellations constitute part of a service systems environment and affect the strategies
of the enterprise, organization, and service system itself. Organizations consist of service systems that may or
may not include a well-defined process but that must contain at least one activity. Each activity is performed by
one or more actor roles, including noncustomer participant, customer participant, and automated agent.
Concepts related to intentions that are visible in the metamodel include product/service, customer, and strategy.
Strategies summarize intentions for using resources to produce products/services. Product/service and customer
appear on the side for intention because the purpose of a service system is to produce products/services for its
customers. Other concepts related to intentions such as goals, metrics, characteristics, and incentives are relevant
to service systems but are not shown in Figure 2. Instead, they are treated as attributes of specific elements or
relationships.
Impacts of Other Service Systems
Research related to interactions between tasks or systems has studied topics such as task interdependency
(Thompson 1967), coordination theory (Malone et al. 1999, Crowston et al. 2006), and loose coupling theory
(Orton and Weick 1990). The most obvious interactions between service systems are related to inputs and
outputs, i.e., receipt and consumption of resources provided by other service systems and the production of
products/services for use by other customers associated with other service systems. The metamodel includes
an entity type called other service system and other types of interactions (labeled as interactions other
than input/output) because such interactions may be important in designing service systems. Such interactions
228
include sharing of human participants and other resources, various forms of interference that occur accidentally,
and requirements that one service system may impose on another either implicitly or explicitly (Alter 2010a, b).
Example Illustrating Three Levels of Analysis and Design

Within this papers page limits it is impossible to explain the rationale for each representation choice in the
metamodel, including naming of entity types and relationships between entity types. Because the elements of the
work system framework were defined in Table 1 and the metamodel specifies relationships that are reasonably
clear, our next step is to illustrate how the metamodel can be used in the three levels mentioned earlier: service
activities, service systems, and value constellations. We use a simplified example related to payment for medical
services provided in a small medical clinic in the United States. This example is a combination of several
different real-world situations (e.g., Fuhrmans 2007, Emanuel 2011).
The example involves a medical clinic whose patients have medical insurance that covers at least part of most
medical services. Different patients have different insurance policies from different insurance companies that
cover different services and provide different levels of payment to different groups of physicians. After providing
medical services for a patient, a doctor fills in a paper form identifying the services that were provided and
the length of the office visit. In some, but not all cases, the doctor supplies industry-standard codes identifying
specific services that were provided. In some cases the doctors adjust service codes based on known payment
policies of specific insurance companies. In other cases they may not know the service codes or may be unsure
whether the services are covered by the patients insurance. The clinics billing specialists record this information
using medical billing software. In unusual cases they may have difficulty figuring out which codes are applicable.
At the end of each day, the office sends the entire days billing information to a recently formed billing company
that was created as an intermediary between small clinics and large insurance companies. The billing companys
medical billing specialists examine the information from the clinic, correct some bills, call for clarifications of
other bills, and forward the adjusted bills to the insurance company. The insurance companys medical billing
specialists decide whether each billed service is covered by the patients insurance, and if so, at what level of
payment. Doctors and patients receive notifications of payments to doctors and additional amounts due from
patients.
Consistent with all eight premises that were discussed earlier, the service system metamodel guides the
description of this situation at three levels.
Value constellation: Analysts focusing on the highest level of overview are interested in the relevant value
constellation, which consists of service systems including providing medical services at the clinic, creating initial
bills at the clinic, inspecting and adjusting the bills at the billing company, and determining payments at the
insurance company. The limited knowledge of the billing staff in small clinics created the opportunity for billing
companies to play a new intermediary role in the value constellation. It is possible that future legislation will
expand, diminish, or eliminate the role of such intermediaries or of insurance companies.
Service system: Analysts focusing on specific service systems within the value constellation can use the
metamodels description of a service system in terms of concepts such as process, activity, actor role, participant,
informational entity, and technological entity.
Service activity: Analysts focusing on each activity in detail can use the metamodels guidance for identifying all resources that an activity uses and all products/services that it creates, some of which will be resources
for subsequent activities.
Table 2 summarizes the value constellation as though it were a single service system. In looking at the
value constellation in more detail, each of the steps listed in Table 2 under Major processes and activities
could be represented as a separate service system in its own right by identifying in more detail exactly how
those processes and activities are performed. Successive decomposition of each of those service systems would
eventually isolate totally automated subsystems that provide information or support decision making, thereby
translating a general business-oriented view of the situation to the level of detail that programmers need in order
to produce software. The metamodel treats the totally automated subsystems as automated agents that are service
systems in their own right and therefore can be described using the metamodel.
Because a central goal of the metamodel is to support analysis and design for service systems, we will illustrate
the use of the metamodel by explaining how it applies to the three levels of analysis and design mentioned
earlier. Encompassing all three levels within an integrated metamodel has several important advantages. First,
it encourages consideration of big-picture issues and detail-oriented issues, instead of focusing on one and
essentially ignoring the other. In addition, it provides an analytical decomposition path from the higher levels to
the lower levels, plus the corresponding traceability back to the higher levels.
229
Table 2. Value Constellation for Medical Payment Determination, Summarized as a Single Service System
Customers
Products/services
Billing specialist at clinic (receives payment decision)

Patient (receives medical care payment decision)
Medical services for patient

Initial bill for services rendered
Adjusted bill produced by billing company
Payment decision by an insurance company
Notification for doctors billing specialist and patient
Major processes and activities
Doctors provide medical services and complete a paper form describing services rendered.
Billing specialist at the clinic enters billing information using billing software.
Billing specialist at the clinic sends a batch of bills to the billing company.
Billing specialist at the billing company analyzes and revises bills based on knowledge of medical billing terminology
and practices of patients insurance company.
Billing specialist at the billing company transmits bill to insurance company.
Payment specialist at the patients insurance company uses customized payment analysis software to analyze bills and
decide on payment to doctors and additional amount to be paid by patient.
Payment specialist at the patients insurance company notifies doctors billing specialist and patient of payment decision.
Participants
Doctors
Patients
Billing specialists at the clinic
Billing specialists at the
billing company
Payment specialists at
insurance company
Information
Technologies
Patients medical history

Description of services rendered
Coded description of
services rendered
Initial bill
Revised bill
Provisions and coverage
of patients insurance policy
Payment decision
Paper medical records

for patients
Electronic billing system at
clinic and billing company
Claim analysis software at
the insurance company
Level 1: Environment, Strategy, and Value Constellation

Analysis and design of service systems needs to consider environment and strategy on three levelsenterprise,
organization (e.g., department), and service system, plus relevant value constellations and the environment within
which those value constellations exist. The related entity types appear in the upper part of the metamodel.
Information and insights about the environment and about internal competences and capabilities can be used
to reconsider the strategy of the enterprise, the organization, and the service system itself, and to evaluate
whether strategies on the three levels are aligned. At all three levels, those strategies include value propositions for customers of the enterprise, organization, and service system, respectively, and internal strategies for
using resources to produce products/services, including the extent of coproduction. For externally facing service
systems, consideration of value constellations calls for clarity about this service systems role in each relevant
value constellation and possibilities for playing that role more efficiently or effectively, perhaps by expanding or
contracting it. In the medical payments example, each enterprise in the value constellation is concerned about
whether its operational roles might change, might be absorbed by other enterprises, or might disappear from the
value constellation, as could happen with new healthcare legislation or regulations.
Level 2: Big-Picture View of the Service System
At a local level, a big-picture view of the operation of a service system summarizes customer groups, primary
products/services produced for those customer groups, processes and activities, participants, and information
and technology that is used. Table 2 presented this type of summary for the simplified value constellation using
the format of a work system snapshot (Alter 2006, 2008b). Similar tables can be produced for subsystems
related to each of the steps in Table 2, such as the service system of producing the original bill at the clinic
and the service system of deciding what to pay. Analysis at this level was pursued successfully in projects
by MBA students as discussed in Truex et al. (2010, 2012), which reported on observations related to 75 and
301 management briefings, respectively. The briefings were written using a work system analysis template that
was primarily at this second level of analysis. The template was organized around a work system snapshot and
included a number of questions related to evaluating how well the work system was operating and how it might
230
Figure 3. Using Elements of the Metamodel to Provide a More Detailed View of Information Summarized in Table 2
Activity
Customer
participants
Non-customer
participants
Informational
entities
Technological
entities
Product/services
Provide medical
services
Patient
Doctor
Patients medical
history
Any technology
used in providing
service
Diagnosis
Description of
service rendered
Description of
service rendered
Coded
description of
services
Initial bill
Batch of initial
bills
Paper and pen
Description of
service rendered
Completed coding
of service by
doctor for patient
Initial bill
Patients
insurance policy
Revised bill
Revised bill for
service
Billing software
used by billing
company
Revised bill for

service
Patients
insurance policy
Payment decision
Claim analysis
software used by
insurance
company
Software for
transmitting
payment
decisions
Current symptoms
Fill in paper
billing forms
Enter billing
info in to billing
software
Doctor
Transmit bills to
billing company
Billing
specialist in
clinic
Billing
specialist in
billing company
Billing
specialist in
clinic
Analyze and
adjust bill
Transmit
revised bill to
insurance
company
Decide on
payment
Transmit
payment
decision to
doctor and
patient
Doctors
billing
specialist
Patient
Billing
specialist in
billing
company
Payment
specialist at
insurance
company
Payment
specialist at
insurance
company
Billing software
used by clinic
Billing software
used by clinic
Billing software
used by billing
company
Transmission of
bills to billing
company
Revised bill for
service
Transmission of
revised bill to
patients insurance
company
Payment decision
Transmission of
payment decision
to doctor and
patient
be improved. Note that the work system snapshot is sufficient for understanding the scope of the system being
summarized but does not specify essential details such as which information and technology are used for each
step and what is produced by each step. Those details require the more focused representation outlined by the
metamodel.
Level 3: Service Activities and Other Operational Specifics
As illustrated by Figure 3, a more detailed view is required to clarify specifics that must be understood in order
to create and maintain an efficient and effective service system. The relevant entity types appear in the lower
part of the metamodel, starting with activities; actor roles that perform each activity; customer participants,
noncustomer participants, and/or automated agents that play each role; resources that are used for each activity;
product/services produced by each activity; and subsequent use of those product/services in subsequent activities
within the service system or by the service systems customers outside of the service system. Analysis on this
level of detail is necessary for decomposing a service system into subsystems, some of which may be totally
automated. The third level brings the analysis and description closer to the types of details that can be represented
in UML, which is a standard for object-oriented analysis and design.
Figure 3 assumes that each step in Table 2 is treated as an activity within a service system. For each step it
shows the customer and noncustomer participants, the informational entities and technological entities, and the
products/services produced. Similar tables can be produced by expanding each activity as a subsystem, a separate
service system that can be summarized using the same type of table. The detailed flow of logic (e.g., forks and
joins) can be represented as conditional activities or as subordinate subsystems.
Discussion
The metamodel and the underlying definitions express a number of service science concepts in ways that
represent progress for service science. This papers coverage of the eight premises underlying the metamodel
231
explained that some concepts expressed in the metamodel diverge from more established views in service science.
The metamodel treats service systems as operational systems rather than as systems of economic exchange.
Using that perspective leads to the three levels of analysis and design explained previously. A possible challenge
for proponents of the economic exchange view of service systems would involve creating a different metamodel
based on economic exchange and showing how that could be used for service system analysis and design. One
of the advantages of the metamodel in Figure 2 is that the terms and relationships are relatively familiar and can
be used to represent most service situations. This type of practicality was demonstrated by the example shown
here and by previously mentioned results from Truex et al. (2010, 2012). The next stage in developing the
metamodel would involve working through many examples to make sure that the different layers are useful and
internally consistent when applied to complex examples.
Actors, Products/Services, and Resources
The efficacy of the metamodels representation of actors, products/services, and resources should be examined
in both simple and complex situations because different representations might have been used in each case.
Actor roles. A product/service produced by an activity may be used by customer participants, noncustomer
participants, and/or automated agents in subsequent activities, or it may go to customers outside of the service
system. The metamodel recognizes that two out of three types of actor roles are played by human participants
whose personal characteristics (i.e., attributes of the entity type participant) include capabilities, competencies,
and incentives that could determine whether a service system operates as intended.
Products/services. Treating the output of a service activity as a product/service with no explicit distinction
between products and services is consistent with the SDL view of products versus services. Important attributes
of product/services are characteristics that can be measured along separate dimensions that range from productlike to service-like (e.g., degree of customization and extensiveness of customer interaction). Those attributes
and many other important characteristics are not visible in the representation of the metamodel in Figure 2
but are easy to include in computerized representations of the metamodel. Other attributes for product/service
entities include directly measurable performance indicators as well as subjective assessments such as quality or
customer value.
Resources. The metamodel recognizes that each activity uses human, informational, technological, and/or other
types of resources and that each activity produces informational, technological, and/or other types of resources
that may be used in other activities or that are received by customers outside of the service system.
Coproduction and Cocreation of Value
Coproduction and cocreation of value are central topics in many views of service and service systems. Defining
services as acts performed for the benefit of others helps in seeing that there are different degrees of coproduction.
Triggering action by requesting something (e.g., the definition of service provided by Sampson and Froehle 2006)
represents a minimalist version of coproduction. Assume that each activity in a service system is performed by
one or more actor roles involving customer or noncustomer participants. If a customer participants request is the
first of 20 activities and the next 19 are performed by noncustomer participants, then we might say the service is
coproduced even though only 5% of the steps involve coproduction. From a service system design perspective,
the much more interesting point about coproduction is the design decision about how extensive coproduction
should be within a particular service system and how much responsibility customer participants should bear for
which activities.
The concept of value cocreation goes beyond coproduction because it concerns how and where customers
capture value. As noted in Alter (2008b, 2010d), aspects of value creation may extend across an entire service
system even when tangible products are produced, such as through easier ways of negotiating service commitments, preparing for service instances, specifying what is desired, and performing other activities related to the
service. When a service (defined here as an activity performed for others) generates tangible things that are
transferred to a customer, much of the value capture occurs when the customer uses those things, often in other
service systems that have other participants and other goals. The metamodel assumes that such a situation is
outside the boundaries of the service system that is being analyzed. The alternative would involve stretching
the service systems boundary to include subsequent value capture by a range of different customers in different types of service systems or personal activities that they are involved with. Thus, the metamodel represents
coproduction of value in a useful way but does not deal with value capture that extends outside the boundaries
of the original service system.
232
Relation to Other Topics Often Associated with Service or Service Management

Because the metamodel tries to cover any real-world service system, it is useful to see whether it covers many
of the ideas that are often associated with one or another aspect of service or service management. We will look
at a number of topics that appeared as questions about the metamodel from previous discussions and critiques.
Many other topics might have been chosen. In each case, assume that someone discussing the metamodel said,
Yes, and what about X? where X is one of the following topics.
Time. The concept of time does not appear in Figure 2. The metamodel assumes that time can be treated
implicitly through its appearance in attributes of activities (such as triggers, business rules, and metrics) and in
attributes of product/services (such as availability dates and expiration dates).
Service-level agreements. The metamodel does not require service-level agreements (SLAs) because many
service systems do not have SLAs. Where an SLA is relevant for a particular service system, the SLA would
be treated as an attribute of the service system. The process of deciding on the SLA would be a management
process that is separate from the service system in operation, just as the production of application software is
different from the operation of a service system that uses the software.
Service quality. The metamodel does not contain an explicit concept of service quality. In any specific situation,
attributes of specific product/services and specific activities would include the relevant metrics, some of which
would be metrics for service quality.
Service climate. As with service quality, the metamodel does not contain an explicit concept of service climate,
which can be treated as an attribute of several different entity types including service system, service system
environment, organization environment, and enterprise environment.
Service encounters. The metamodel does not represent service encounter as a predefined concept. Service
encounters occur in activities in which both customer participants and noncustomer participants play a role or
in which customer participants use resources provided by the service system owner. For example, activities in
which customer participants make direct use of tools provided by the service provider (as in self-service use of
an e-commerce website) might be considered service encounters because the tool represents the intention and
competence of the service provider. The metamodel ignores service encounters that are not explicit activities in
a service system, such as when a banks loan officer is friendly to a customers child while the customer is in
the bank.
Service blueprinting. The metamodel says nothing specific about service blueprinting, but it potentially covers
many of the basic concepts, such as the five components of a service blueprint (Bitner et al. 2008): customer
actions, onstage contact employee actions, backstage contact employee actions, support processes, and physical
evidence. The metamodel treats customer actions as activities performed by customer participants. It treats
onstage and backstage contact employee actions as activities performed by noncustomer participants. In many
situations it would treat support processes as processes and activities in other service systems within the same
value constellation. Physical evidence at each step would be an attribute of the related activity or of a particular
product/service that is produced. Concepts such as the line of interaction, line of visibility, and line of internal
interaction could be inferred in some situations but not in others. For example, specific activities that have both
customer participants and noncustomer participants would typically be above the line of interaction in a service
blueprint.
Best practices. The metamodel uses the concepts process and activity to describe whatever practices occur
in a service system. It expresses no view about whether those practices are best practices for any particular
situation or for any larger class of similar situations. In general, the thinking underlying the metamodel views
best practices as a marketing claim by vendors and consultants who often cannot know situation-specific issues,
requirements, and constraints that may be unique to a particular service system in a particular setting (e.g., see
Wagner et al. 2006).
IT service management. The metamodel says nothing in general about disparate groups of service systems
that often appear under umbrella headings such as IT service management. The metamodel could be applied to
incident management, access management, release and deployment management, or any of the other processes
that are generally included in IT service management (e.g., those listed in itSMF 2007). It provides a way to
think about each of those processes in service system terms, thereby demonstrating that the successful operation
of the process involves not only the idealized definition of the process but also situational factors such as
characteristics of the participants and availability of key resources.
Enterprise architecture. The metamodel does not contain the concept of enterprise architecture because enterprise architecture is often far removed from the operational service systems on which the metamodel is focused.
For example, assume that a multinational corporations remote office in a city in South America wants to use
the metamodel to design a new service system for dispatching service technicians. Service analysts or designers
233
would have to consider the relevant environment and the available infrastructure, but it is doubtful that they
would have to consider a complete enterprise architecture.
At the more limited level of service system architecture, the metamodel could potentially interface with many
of the tools that are associated with enterprise architecture, such as ArchiMate (from the Open Group), the
IT architecture ecosystem and Business Process Modeling Notation (BPMN, both from the Object Management Group), component business modeling (from IBM), event-driven process chain (from ARIS), and others.
A separate research project would be required to work out the interfaces, overlaps, and disconnects in each case.
Decomposition within service systems. The metamodel treats the roles of participants and automated agents in
a somewhat symmetrical manner, thereby facilitating the creation and use of tools for tracing the decomposition
of service systems as part of analysis and design processes. That decomposition can be done in many different
ways depending on the goals and interests of the person doing the decomposition. For example, an IT professional
might want to decompose the service system to completely isolate automated activities that might involve
the reuse of existing automated IT services or creation of new IT services. Someone interested in decision
making might decompose a service system to isolate key decisions that have an important impact on the service
systems performance. In either case, the decomposition would have to identify which activities belong to which
subsystem. The resources produced and used by each activity within the original service system could be the
basis of an initial test of whether the decomposition lost anything, as the production and/or use of each resource
would still occur somewhere in the subsystems or would be replaced by the production and/or use of resources
that are subdivided differently. The structure of the metamodel and the accommodation for isolating automated
agents support that type of decomposition.
Techniques and tools. One of the goals of the original metamodel in Alter (2010a) was to inspire a set of easyto-use tools in the form of tables based on links in the metamodel. Such tables devote one column to a specific
entity type in the metamodel (e.g., activity, participant, informational entity within a service system) and devote
another column or several columns to directly related entity types or attributes. Typical tables might include
participants in all activities at a particular level of decomposition; informational entities used by each activity; or
a set of characteristics or metrics related to activities, informational entities, or participants (Alter 2008b). The
use of such tables might lead to a new type of front end to rigorous modeling tools such as UML and BPMN
that specify details more precisely, including detailed flow logic. It is possible to extend those tables to develop
hierarchy-oriented tools that traverse different levels of decomposition. Those tools might incorporate guidelines
for successive decomposition based in part on system decomposition guidelines in the computer science literature
(for technical artifacts), in the organization literature (for departmentation and division of labor), and possibly
in other literatures.
Conclusion
This paper started by questioning whether the new discipline of service science is coming to premature closure
concerning a widely repeated assertion that service-dominant logic is the foundation of service science. This
paper presented an alternative perspective on service systems through a metamodel based on concepts and
premises that are unique in a number of ways. The underlying definition of service is consistent with the more
complex SDL definition of service, but it is different from many definitions of service in terms of characteristics
that apply to some services but not to others. The metamodel was designed to traverse three levels of analysis
and design in order to integrate concepts at those three levels. Except in initial explorations and discussions
posed broadly in terms of mission statements and value propositions, it would be risky to analyze or design
real-world service systems without considering most of the entity types in the metamodel.
This papers contributions to service science started with comments and clarifications concerning basic concepts such as service, service system, customer, product/service, coproduction and cocreation of value, actor
roles, resources, symmetrical treatment of automated and nonautomated service systems, and the relationship
between SDL and service systems. Many articles have discussed these topics individually. Few, if any, have tied
them together using an integrated metamodel. In addition, the way in which the metamodel was used to summarize and unravel the example creates a challenge for SDL and any other comprehensive view of service. How
would SDL unravel this example? What questions would it lead an analyst to ask, and would those questions
be helpful for practical analysis and design efforts in this type of situation?
Limitations
Although this papers ideas and the metamodel that integrates them represent progress for service science, a
number of limitations should be mentioned. The metamodel is a theoretical construction whose precision and
234
usefulness have only been tested in hypothetical examples and informal inspection of many small case studies.
The metamodel spans three levels of discussion but does not go to the level of detailed workflow logic that is
included in formal modeling tools.
The metamodel identifies topics that should be considered in service system design but does not provide a
process for design or innovation. The work system life cycle model (Alter 2006, 2008a, b) addresses part of that
issue by outlining an iterative process through which work systems (almost all of which are service systems,
as noted earlier) evolve over time through a combination of planned change (formal projects) and emergent
change (incremental adaptations and workarounds). Ideas from the work system life cycle model might be
combined with ideas from the literature on product and service design and innovation to create a better way of
visualizing different paths for service design and innovation. Beyond this papers scope, it would be interesting
to analyze design and innovation processes from the literature to see which parts of the metamodel they consider
and which parts they ignore.
This paper contributes to discussions of fundamental issues related to service, service systems, and service
system analysis and design. Great progress has occurred on many fronts in recent years. There are many ideas,
many viewpoints, many interesting examples, and many ambitions. This paper contributes by integrating ideas
in a way that has not been presented in the past and which could be the basis of future theoretical developments
and empirical research.
References
Alter S (2006) The Work System Method: Connecting People, Processes, and IT for Business Results (Work System Press, Larkspur, CA).
Alter S (2008a) Defining information systems as work systems: Implications for the IS field. Eur. J. Inform. Systems 17(5):448469.
Alter S (2008b) Service system fundamentals: Work system, value chain, and life cycle. IBM Systems J. 47(1):7185.
Alter S (2008c) Service system innovation. Barrett M, Davidson E, Middleton C, DeGross J, eds. Information Technology in the Service
Economy: Challenges and Possibilities for the 21st Century (IFIP 8.6 Conf.) (Springer, New York), 6180.
Alter S (2010a) Bridging the chasm between sociotechnical and technical views of systems in organizations. Proc. 31st Internat. Conf.
Inform. Systems 4ICIS 20105 (St. Louis). http://aisel.aisnet.org/icis2010_submissions/54.
Alter S (2010b) Including work system co-existence, alignment, and coordination in systems analysis and design. Proc. 16th Americas Conf.
Inform. Systems (Lima, Peru). http://aisel.aisnet.org/amcis2010/190.
Alter S (2010c) Service systems and service-dominant logic: Partners or distant cousins? J. Relationship Management 9(2):98115.
Alter S (2010d) Viewing systems as services: A fresh approach in the IS field. Comm. Assoc. Inform. Systems 26(11):195224.
Alter S (2011a) Making a science of service systems practical: Seeking usefulness and understandability while avoiding unnecessary
assumptions and restrictions. Demirkan H, Spohrer J, Krishna V, eds. The Science of Service Systems (Springer, New York), 6172.
Alter S (2011b) Metamodel for service design and service innovation: Integrating service activities, service systems, and value constellations.
Proc. 32nd Internat. Conf. Inform. Systems 4ICIS 20115 4Shanghai, China5. http://aisel.aisnet.org/icis2011/proceedings/servicescience/8.
Bitner MJ, Ostrom AL, Morgan FN (2008) Service blueprinting: A practical technique for service innovation. Calif. Management Rev.
50(3):6694.
Brown AW, Delbaere M, Eeles P, Johnston S, Weaver R (2005) Realizing service-oriented solutions with the IBM rational software
development platform. IBM Systems J. 44(4):727752.
Crowston K, Rubleske J, Howison J (2006) Coordination theory: A ten-year retrospective. Zhang P, Galletta D, eds. Human-Computer
Interaction and Management Information Systems: Foundations (M.E. Sharpe, Armonk, NY), 120138.
Emanuel EJ (2011) Billions wasted on billing. Opinionator (blog), November 12, http://opinionator.blogs.nytimes/2011/11/12/billionswasted-on-spending.
Feldman MS, Pentland BT (2003) Reconceptualizing organizational routines as a source of flexibility and change. Admin. Sci. Quart.
48(1):94118.
Fitzsimmons JA, Fitzsimmons MJ (2006) Service Management, 5th ed. (McGraw-Hill, New York).
Fuhrmans V (2007) Billing battle: Fights over health claims spawn a new arms race. Wall Street J. (February 14) A1.
Grnroos C (2011) Value co-creation in service logic: A critical analysis. Marketing Theory 11(3):279301.
Hill TP (1977) On goods and services. Rev. Income Wealth 23(4):315338.
IBM Research (2009) Services science, management and engineering. Accessed January 4, 2012, http://researchweb.watson.ibm.com/ssme/
services.shtml.
itSMF (2007) An introductory overview of ITIL V3: A high-level overview of the IT infrastructure library. Accessed January 4, 2012,
http://www.best-management-practice.com/gempdf/itSMF_An_Introductory_Overview_of_ITIL_V3.pdf.
Kotler P, Keller K (2006) Marketing Management, 12th ed. (Prentice Hall, Upper Saddle River, NJ).
Maglio PP, Spohrer J (2008) Fundamentals of service science. J. Acad. Marketing Sci. 36(1):1820.
Malone TW, Crowston K, Lee J, Pentland B, Dellarocas C, Wyner G, Quimby J, et al. (1999) Tools for inventing organizations: Toward a
handbook of organizational processes. Management Sci. 45(3):425443.
Neely A (2008) Exploring the financial consequences of the servitization of manufacturing. Oper. Management Res. 1(2):103118.
Normann R (2001) Reframing Business: When the Map Changes the Landscape (John Wiley & Sons, New York).
Normann R, Ramrez R (1994) Designing Interactive Strategy: From Value Chain to Value Constellation (John Wiley & Sons,
Chichester, UK).
Orton JD, Weick KE (1990) Loosely coupled systems: A reconceptualization. Acad. Management Rev. 15(2):203223.
Porter ME (1985) Competitive Advantage: Creating and Sustaining Superior Performance (Free Press, New York).
Ramrez R (1999) Value co-production: Intellectual origins and implications for practice and research. Strategic Management J. 20(1):4965.
Sampson SE, Froehle CM (2006) Foundations and implications of a proposed unified services theory. Production Oper. Management
15(2):329343.
235
Software Engineering Institute (2010) CMMI for Services, version 1.3. Technical Report CMU/SEI-2010-TR-034, ESC-TR-2010-034,
Carnegie Mellon University, Pittsburgh.
Spohrer J, Maglio P (2009) Service science: Toward a smarter planet. Salvendy G, Karzwowsky W, eds. Introduction to Service Engineering
(John Wiley & Sons, New York), 330.
Spohrer J, Golinelli GM, Piciocchi P, Bassano C (2010) An integrated SS-VSA analysis of changing job roles. Service Sci. 2(1/2):120.
Stabell CB, Fjeldstad D (1998) Configuring value for competitive advantage: On chains, shops, and networks. Strategic Management J.
19(5):413437.
Star SL, Bowker GC (2002) How to infrastructure. Lievrouw L, Livingstone S, eds. Handbook of the New Media (Sage, London), 151162.
Tapscott D, Ticoll D, Lowy A (2000) Digital Capital: Harnessing the Power of Business Webs (Harvard Business School Press, Boston).
Thompson JD (1967) Organizations in Action: Social Science Bases of Administrative Theory (McGraw-Hill, Chicago).
Truex D, Alter S, Long C (2010) Systems analysis for everyone else: Empowering business professionals through a systems analysis method
that fits their needs. Proc. 18th Eur. Conf. Inform. Systems 4Pretoria, South Africa5. http://aisel.aisnet.org/ecis2010/4.
Truex D, Lakew N, Alter S, Sarkar S (2012) Extending a systems analysis method for business professionals. Helfert M, Donnellan B, eds.
Eur. Design Sci. Sympos. 2011 (Communications in Computer and Information Science, Vol. 286) (Springer-Verlag, Berlin), 1526.
Vargo SL, Akaka MA (2009) Service-dominant logic as a foundation for service science: Clarifications. Service Sci. 1(1):3241.
Vargo SL, Lusch RF (2004a) Evolving to a new dominant logic for marketing. J. Marketing 68(1):117.
Vargo SL, Lusch RF (2004b) The four service marketing myths. J. Service Res. 6(4):324335.
Wagner EL, Scott SV, Galliers RD (2006) The creation of best practice software: Myth, reality, and ethics. Inform. Organ. 16(3):251275.
Steven Alter is a professor of information systems at the University of San Francisco.

He earned a Ph.D. from the Massachusetts Institute of Technology and extended his
thesis into one of the first books on decision support systems. He served for eight
years as vice president of Consilium, a manufacturing software firm that went public and was later acquired by Applied Materials. His research concerns developing
systems analysis concepts and methods that can be used by typical business professionals and can support communication with IT professionals. His latest book, The
Work System Method: Connecting People, Processes, and IT for Business Results, is a
distillation and extension of ideas developed in four editions of an information systems
textbook that he published previously. His articles have appeared in Harvard Business
Review, Sloan Management Review, MIS Quarterly, the IBM Systems Journal, and the
Communications of the Association for Information Systems, among others.

Alter 2012

Uploaded by

Copyright:

Available Formats

Alter 2012

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Alter 2012

Uploaded by

Copyright:

Available Formats

This article was downloaded by: [130.133.8.

114] On: 01 July 2015, At: 04:29

Metamodel for Service Analysis and Design Based on an

To cite this article:

Vol. 4, No. 3, September 2012, pp. 218235

Metamodel for Service Analysis and Design Based on

Need for Usable, Design-Oriented Models

Alter: Metamodel for Service Analysis and Design

Service Science 4(3), pp. 218235, 2012 INFORMS

Eight Premises Related to Services and Service Systems

Alter: Metamodel for Service Analysis and Design

Service Science 4(3), pp. 218235, 2012 INFORMS

Alter: Metamodel for Service Analysis and Design

Service Science 4(3), pp. 218235, 2012 INFORMS

Alter: Metamodel for Service Analysis and Design

Service Science 4(3), pp. 218235, 2012 INFORMS

Figure 1. Work System Framework

Alter: Metamodel for Service Analysis and Design

Alter: Metamodel for Service Analysis and Design

Service Science 4(3), pp. 218235, 2012 INFORMS

Alter: Metamodel for Service Analysis and Design

Service Science 4(3), pp. 218235, 2012 INFORMS

Metamodel for Service System Analysis and Design

Alter: Metamodel for Service Analysis and Design

Service Science 4(3), pp. 218235, 2012 INFORMS

Figure 2. Metamodel for an Operational Service System Within a Value Constellation

Service system environment

Service system strategy

< has interactions other

< guides (0..*)

contains > (0.. *)

< provides (0..*)

contains > (1.. *)

contains > (2.. *)

< used as (0.. *)

< uses product/service while

< uses (1..*)

used by > (1 ..*)

performed by > (1.. *)

< receives and

< performs (1 ..*)

uses > (0..*)

< performs (1.. *)

Composition: B consists of one or more As

Alter: Metamodel for Service Analysis and Design

Service Science 4(3), pp. 218235, 2012 INFORMS

Alter: Metamodel for Service Analysis and Design

Service Science 4(3), pp. 218235, 2012 INFORMS

Example Illustrating Three Levels of Analysis and Design

Alter: Metamodel for Service Analysis and Design

Service Science 4(3), pp. 218235, 2012 INFORMS

Billing specialist at clinic (receives payment decision)

Medical services for patient

Major processes and activities

Patients medical history

Paper medical records

Level 1: Environment, Strategy, and Value Constellation

Alter: Metamodel for Service Analysis and Design

Service Science 4(3), pp. 218235, 2012 INFORMS

Paper and pen