Content uploaded by Steven Alter
Author content
All content in this area was uploaded by Steven Alter on Jan 17, 2014
Content may be subject to copyright.
Service system fundamentals:
Work system, value chain,
and life cycle
&
S. Alter
Service systems produce all services of significance and scope, yet the concept of a
service system is not well articulated in the service literature. This paper presents three
interrelated frameworks as a first attempt to define the fundamentals of service
systems. These frameworks identify basic building blocks and organize important
attributes and change processes that apply across all service systems. Although
relevant regardless of whether a service system uses information technology, the
frameworks are also potentially useful in visualizing the realities of moving toward
automated service architectures. This paper uses two examples, one largely manual
and one highly automated, to illustrate the potential usefulness of the three
frameworks, which can be applied together to describe, analyze, and study how
service systems are created, how they operate, and how they evolve through a
combination of planned and unplanned change.
INTRODUCTION
Is there any unified view of service that is genuinely
useful and goes beyond providing a definition of
service or a solution to a situation-specific problem?
This question presents a substantial challenge
within the current state of knowledge because the
term service is used extensively but with different
meanings and connotations in three distinct disci-
plines: marketing, operations, and computer sci-
ence.
This paper proposes that a service system is a useful
fundamental unit for understanding, analyzing, and
designing services in all three disciplines. It presents
three frameworks that provide a foundation for
understanding and analyzing service systems. These
frameworks can be used to organize and access a
wide range of relevant concepts and principles.
The work system framework uses nine basic
elements to provide a system-oriented view of any
system that performs work within or across
organizations.
1
Service systems are work systems.
The service value chain framework augments the
work system framework by introducing functions
that are associated specifically with services.
2
It
Ó
Copyright 2008 by International Business Machines Corporation. Copying in
printed form for private use is permitted without payment of royalty provided
that (1) each reproduction is done without alteration and (2) the Journal
reference and IBM copyright notice are included on the first page. The title
and abstract, but no other portions, of this paper may be copied or distributed
royalty free without further permission by computer-based and other
information-service systems. Permission to republish any other portion of the
paper must be obtained from the Editor. 0018-8670/08/$5.00 Ó2008 IBM
IBM SYSTEMS JOURNAL, VOL 47, NO 1, 2008 ALTER 71
presents a two-sided view of service processes
based on the common observation that services
are typically coproduced by service providers and
customers.
The work system life cycle model looks at how
work systems (including service systems) change
and evolve over time. It treats the life cycle of a
system as a set of iterations involving planned and
unplanned change.
1
The frameworks and related concepts form the basis
of a flexible, business-oriented analysis and design
method that can be used at different levels of detail
by business and information technology (IT) pro-
fessionals. The frameworks and the analysis and
design approach are applicable to a wide range of
services: services for external customers and for
internal customers; automated, IT-reliant, and non-
automated services; customized, semi-customized,
and non-customized services; personal and imper-
sonal services; repetitive and non-repetitive servic-
es; long-term and short-term services; and services
with varying degrees of self-service responsibilities.
This paper proceeds as follows. Inconsistencies
between definitions of service from different disci-
plines illustrate the desirability of a unified approach
to understanding services. A summary of the work
system framework shows that service systems can
be understood and analyzed in terms of the
elements of a work system. The work system
snapshot, a formatted one-page system summary,
illustrates the usefulness of the work system
framework. The service value chain framework
identifies service functions that appear in many
service systems, and therefore should be considered
when analyzing or designing a service system. A
tool called a service responsibility table illustrates
the usefulness of the basic logic of the service value
chain framework. The summary of the work system
life cycle model emphasizes how it is different from
the system development life cycle (SDLC) model
that is often used to describe software development
projects. The next section summarizes how the
three frameworks can be applied individually or in
combination and at various levels of depth by
business and IT professionals. An additional section
moves toward a computer science view by bringing
totally automated service systems into the picture.
The final section summarizes the contributions of
the paper and identifies areas for future research.
BEYOND A DEFINITION OF SERVICE
Researchers in marketing, operations, and computer
science have discussed and analyzed services from
vastly different viewpoints in recent years, resulting
in inconsistent and sometimes contradictory views
of the essential nature of services. Many definitions
of service ‘‘contain a common theme of intangibility
and simultaneous consumption’’
3
such as ‘‘any act
or performance that one party can offer to another
that is essentially intangible and does not result in
the ownership of anything.’’
4
In some views of
service, interactions with human customers are of
the essence, such as Carlzon’s term ‘‘moments of
truth’’
5
and Teboul’s book Service Is Front Stage.
6
In
contrast, Cherbakov et al., in a recent IBM Systems
Journal paper that discussed service orientation and
componentization, state: ‘‘The component that
consumes business services offered by another
business component is oblivious to how the
provider created the business service.’’
7
Whereas
Brown et al., in another IBM Systems Journal paper
state that a service ‘‘is generally implemented as a
coarse-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.’’
8
Disagreements about the essential nature of services
also exist within disciplines. For example, Vargo and
Lusch argue that four prototypical characteristics
often believed to distinguish services from goods—
intangibility, inseparability, heterogeneity, and per-
ishability—‘‘(a) do not distinguish services from
goods, (b) only have meaning from a manufacturing
perspective, and (c) imply inappropriate normative
strategies.’’
9
Even if different communities of practice can live
with their own somewhat inconsistent views of
service, conflicting views of service surely cannot
facilitate effective communication between business
and IT practitioners and between business and
computer science researchers. Furthermore, con-
flicting views of service are surely an obstacle to
current attempts to develop a new science of
services
10
and new academic programs focusing on
services.
Progress with a new science of services requires
understanding and concepts that go far beyond
finding an acceptable definition of service. Funda-
ALTER IBM SYSTEMS JOURNAL, VOL 47, NO 1, 2008
72
mental comprehension of service should explain
how services are performed and how services
change over time. Since all services of significance
are produced through service systems, a way to
understand and analyze service systems should
encompass many of the fundamentals of service.
In contrast to typical analysis and design approaches
that emphasize data, workflows, and technology,
the three frameworks in this paper summarize the
fundamentals of service systems from a business
viewpoint using concepts that reflect the semantics
and business context of services. These frameworks
can be used to organize many additional concepts
related to each element of the frameworks. Aspects
of the same frameworks might also be used to
interpret and possibly explain or extend computer
science concepts related to service orientation and
componentization.
Taken together, the three frameworks provide a rich
and broadly applicable model of how services
operate and evolve. They create a platform for
comparing service situations, identifying important
special cases of services, and describing service-
design strategies. In turn, these ideas can contribute
to research about the relative advantages and
disadvantages of different service methods and
approaches in the presence of specific situational
characteristics.
In its exploration of service systems, this paper
adopts Vargo and Lusch’s definition: Services are
‘‘the application of specialized competences
(knowledge and skills) through deeds, processes,
and performances for the benefit of another entity or
the entity itself.’’ By that definition, almost any
purposeful system within a business or govern-
mental entity can be viewed as a service system
because competences are being applied to produce
something for someone. Within Vargo and Lusch’s
proposed service-dominant logic, ‘‘goods are distri-
bution mechanisms for service provision.’’ Hence,
the either-or distinction between goods and services
is unimportant for understanding service systems
even though it may be quite important for other
purposes, such as characterizing an economy.
WORK SYSTEM FRAMEWORK
Service systems are work systems. A work system is
a system in which human participants or machines
perform work using information, technology, and
other resources to produce products and services for
internal or external customers. Information systems,
projects, and supply chains are all special cases of
work systems. For example, an information system
is a work system in which all the work is devoted to
processing information. Although a service system
might seem to be another special case, Vargo and
Lusch’s definition of service implies there is no
significant distinction between work systems in
general and service systems in general.
The work system framework (Figure 1) was
originally developed to help business professionals
recognize and understand IT-reliant systems in
organizations. The work system framework identi-
fies nine elements that are part of even a rudimen-
tary understanding of a work system. Four of these
elements (processes and activities, participants,
information, and technologies) constitute the work
system. The other five elements fill out a basic
understanding of the situation. For example, no
analysis of a service system is complete without
some understanding of the customer’s view of
whatever the system produces. The double-headed
arrows in the work system framework express the
need for alignment between the elements. The
arrows also convey the path through which a
change in one element might affect another element.
In particular, the arrows linking processes and
activities to participants, information, and technol-
Figure 1
The work system framework
(adapted and slightly updated from Reference 1)
Customers
Infrastructure
Products and Services
Processes and Activities
Information Technologies
Participants
Environment
Strategies
IBM SYSTEMS JOURNAL, VOL 47, NO 1, 2008 ALTER 73
ogy show that a change in the processes and
activities might call for a change in any of those
elements, and vice versa.
The work system framework is designed to empha-
size business rather than IT concerns. In contrast to
inwardly facing analysis models that overemphasize
producer concerns and underemphasize customer
concerns, the work system framework places the
customer at the top because the primary goal of a
work system is to produce products and services for
customers. The work system framework does not
preclude the possibility that customers will perform
self-service steps, however, because a customer can
also be a participant.
The terms included in the work system framework
reflect a number of distinctions that are sometimes
overlooked. For example, the work system frame-
work uses processes and activities instead of a
business process, which is often interpreted as a
highly structured set of steps. Processes and activi-
ties covers a full range of situations that might
involve highly structured workflows and ‘‘artful
processes’’ whose sequence and content ‘‘depend on
the skills, experience, and judgment of the primary
actors.’’
11
The term participants (not users) is
included because important roles in a work system
may be played by people who are not direct users of
IT. The information in the system might include
databases, documents, shared knowledge, or even
unrecorded discussions and commitments. Tech-
nologies (not IT) is used because multiple technol-
ogies may be relevant to the analysis. Even when a
work system is a service system, it is assumed to
produce products and services because the actions it
performs for its customers might include the
creation and transfer of physical things or informa-
tion as part of the services provided. The customers
include the direct beneficiaries of whatever a work
system produces, plus other customers whose
interest and involvement is less direct. Three
additional elements fill out an understanding of a
work system. The environment includes organiza-
tional culture and relevant regulations, policies and
procedures, competitive issues, organizational his-
tory, and technical developments. Infrastructure
consists of human, information, and technical
resources that are used by the work system but are
shared with other work systems and managed and
controlled outside the work system. Strategies of the
firm, organization, and work system should be
aligned, although in many situations they may not
be articulated clearly. An articulated work system
strategy includes the value proposition of the work
system for its internal and external customers and
its production strategy.
Most work systems can be subdivided several times
into successively smaller subsystems that can also
be described using the work system framework.
Decomposition into smaller work systems is useful
for analyzing some work systems that are easily
divisible. Decomposition into successively smaller
work systems becomes meaningless at the point
when the subsystem contains only one activity that
is worth analyzing.
The work system framework can be used in a
variety of ways:
At the beginning of an analysis, a template called a
work system snapshot (discussed next) can be
used to clarify the scope of an existing or proposed
service system; summarize the participants, in-
formation, and technologies; and identify products
and services for primary and secondary custom-
ers.
As the analysis proceeds, the work system frame-
work can guide the analysis through the use of
questions and templates related to individual work
system elements. Broadly applicable characteris-
tics and other properties of individual elements
can support a deeper analysis.
At the recommendation stage, the nine elements
can be used to clarify exactly what changes are
proposed and to sanity-check the recommenda-
tion. For example, a proposal to change technol-
ogy without changing anything else is often
incomplete.
Throughout an analysis, the work system frame-
work can help the analyst focus on the system of
doing work rather than just the software or
hardware that is used by people who do the work.
Work System Snapshot
The work system framework is the basis of a work
system snapshot, which summarizes a work system
on a single page by identifying its customers, products
and services, processes and activities, participants,
information, and technology. At the beginning of an
analysis, creating and discussing a work system
snapshot can be useful in clarifying and attaining
ALTER IBM SYSTEMS JOURNAL, VOL 47, NO 1, 2008
74
agreement about the scope and purpose of the work
system that is being analyzed. The environment,
infrastructure, and strategy are not included in the
work system snapshot in order to make it easier to
use and to allow it to fit on one page. Those topics
are considered as the analysis goes deeper. Table 1
shows a work system snapshot related to a
hypothetical loan application and underwriting
system that combines functional characteristics
from a number of different real-world systems.
12
Although more research is called for, research to
date indicates that work system snapshots and a
work system approach are useful for summarizing
systems in organizations and for helping nontech-
nical individuals think about situations in system
terms.
13
Table 1 Work system snapshot for a loan application and underwriting system for loans to new clients
12
Customers Products and Services
Loan applicant Loan application
Loan officer Loan write-up
Risk-management department and top management of the bank Approval or denial of the loan application
Federal Deposit Insurance Corporation (FDIC), a secondary customer Explanation of the decision
Loan documents
Processes and Activities
Loan officer identifies businesses that might need a commercial loan.
Loan officer and client discuss the client’s financing needs and discuss possible terms of the proposed loan.
Loan officer helps client compile a loan application including financial history and projections.
Loan officer and senior credit officer meet to verify that the loan application has no glaring flaws.
Credit analyst prepares a loan write-up summarizing the applicant’s financial history, providing projections explaining
sources of funds for loan payments, and discussing market conditions and applicant’s reputation. Each loan is ranked for
riskiness based on history and projections. Real estate loans all require an appraisal by a licensed appraiser. (This task is
outsourced to an appraisal company.)
Loan officer presents the loan write-up to a senior credit officer or loan committee.
Senior credit officers approve or deny loans of less than $400,000; a loan committee or executive loan committee approves
larger loans.
Loan officers may appeal a loan denial or an approval with extremely stringent loan covenants.
Depending on the size of the loan, the appeal may go to a committee of senior credit officers, or to a loan committee other
than the one that made the original decision.
Loan officer informs loan applicant of the decision.
Loan administration clerk produces loan documents for an approved loan that the client accepts.
Participants Information Technologies
Loan officer
Loan applicant
Credit analyst
Senior credit officer
Loan committee and executive loan
committee
Loan administration clerk
Real estate appraiser
Applicant’s financial statements for
the last three years
Applicant’s financial and market pro-
jections
Loan application
Loan write-up
Explanation of decision
Loan documents
Spreadsheet for consolidating infor-
mation
Loan-evaluation model
MS Word template
Internet
Telephones
IBM SYSTEMS JOURNAL, VOL 47, NO 1, 2008 ALTER 75
The work system framework and work system
snapshot apply to service systems because service
systems are work systems. The next framework
focuses specifically on services.
THE SERVICE VALUE CHAIN FRAMEWORK
The service value chain framework augments the
work system framework by introducing activities
and responsibilities that are associated with servic-
es. Every element of the framework is important for
many service systems, although some may not be
important for specific service systems.
The service value chain framework (Figure 2)
outlines service-related activities and responsibili-
ties of both the service provider and the customer.
These activities may occur before, while, and after a
specific service is delivered to a specific customer.
The framework is based on the following assump-
tions:
Services are often coproduced by service providers
and their customers. Therefore, a full under-
standing of a service system requires attention to
the actions and responsibilities of both the service
provider and the customer.
Customers of a service system are individuals,
groups, or organizations that receive benefits
created by the activities within a service
system.
The same basic ideas about services apply
regardless of whether services are directed at
external customers, internal customers, or
both.
Customer satisfaction is affected by the complete
set of activities, responsibilities, and experiences
that typical customers associate with acquiring,
receiving, and benefiting from a particular service.
Many service situations involve delivery of ser-
vices based on negotiated commitments (such as
service-level agreements) under which the service
Figure 2
Service value chain framework (from Reference 2, by permission)
Service
encounters
Provider’s Responsibilities
Provider setup
Provider’s
internal follow-up
Handle
service request
Fulfill
service request
Customer-facing
follow-up
Service Delivery
Create
awareness of
the service
Negotiate
commitment
(if any)
Value
capture
Customer’s Responsibilities
Make
service request
Participate in
fulfillment
Provider-facing
follow-up
Customer’s
internal follow-up
Customer’s
preparation
Service Consumption
Become
aware of
the need
Negotiate
commitment
(if any)
Create and improve service system Create and improve related systems
ALTER IBM SYSTEMS JOURNAL, VOL 47, NO 1, 2008
76
may be delivered continuously or repeatedly in the
future.
For many services, each instance of service
delivery includes an explicit or implied service
request from the customer.
Although the fulfillment of a service request is
typically viewed as the core of most services,
activities related to awareness, negotiation, setup,
handling of the request, and follow-up are also
important determinants of internal performance
and customer satisfaction.
Services involve front-stage and back-stage activ-
ities by both the service provider and the
customer.
6
Some services require follow-up by the provider or
the customer, or both. In some cases follow-up is
related to a single service instance (e.g., Was the
installation okay?). In other cases, it may refer to
multiple service instances (e.g., How responsive is
your account manager?).
The customer may experience benefits as the
service is produced or may experience benefits
later. Value capture is a customer’s process of
receiving benefits from the efforts of the provider
or from self-service.
The inclusion of service concepts within the service
value chain framework leads to characterizations of
service systems that augment typical characteriza-
tions and metrics for work systems in general. For
example, terms such as complexity, resilience,
speed, and efficiency can be used to describe any
work system. Some of the additional characteriza-
tions that are specifically relevant to service systems
include the relative balance of responsibilities
between providers and customers, the relative
importance of commitments that govern instances of
service delivery, and the relative amount of effort
that goes into back-stage preparation versus front-
stage customer interactions.
Service responsibility tables
The two-sided format of the service value chain
translates directly into a useful and flexible analysis
tool called a service responsibility table (SRT). The
simplest form of an SRT seems like a simplification
of a swim-lane diagram, with one column identify-
ing provider responsibilities, with a second column
identifying corresponding customer responsibilities,
and with specific provider and customer roles
indicated clearly. See the first two columns of
Table 2.
2
Use of a two-column SRT early in the analysis of a
service system serves several purposes. Based on
user preference, it might be used instead of a work
system snapshot at the beginning of an analysis
because:
It clarifies scope and context of the service without
requiring research about the detailed logic of
workflows. For this purpose, it is much simpler
than a flowchart or other graphical form of
representation (which will be needed later in the
analysis to clarify detailed logic and other specifics
that are not needed for an initial understanding).
It focuses attention on activities and responsibil-
ities, rather than on details of technology and
information.
It identifies the job roles that are involved.
It brings customer responsibilities into the analy-
sis.
It identifies steps involving service interactions
(rows with both provider and customer responsi-
bilities) and other steps that are not visible to
customers.
As the analysis continues, it is easy to add one or
two additional columns to an SRT or to use a series
of SRTs that address different aspects of the
analysis. For example, the third column in the SRT
in Table 2 identifies problems and issues associated
with specific activities in the same hypothetical loan
application and underwriting process that was the
subject of the work system snapshot in Table 1.
‘‘Problems and issues’’ is one of many possible
topics for additional columns. As shown in Table 3,
other common analysis topics for additional col-
umns as the analysis unfolds include business rules,
information used, and reasons for delays, errors,
and rework. Since only a limited number of columns
can be viewed comfortably, the analysis might use a
series of SRTs that maintain focus by reusing the
same two left-hand columns and including whatever
third or fourth columns might be relevant. A
software SRT tool could allow the user to include
many additional columns and display them or hide
them at will.
SRTs can also be used to summarize recommenda-
tions about performing specific steps more success-
fully or about adding or eliminating steps. Likewise,
extended versions of SRTs can summarize the extent
to which recommended changes would probably
solve problems related to specific responsibilities
IBM SYSTEMS JOURNAL, VOL 47, NO 1, 2008 ALTER 77
and the extent to which they might cause new
problems.
WORK SYSTEM LIFE CYCLE MODEL
Both the work system framework and the service
value chain framework represent static views of
how a service operates at a particular point in time.
To fill out the picture, the work system life cycle
model (WSLC) in Figure 3 provides a dynamic view
of how work systems (including service systems)
change over time. The WSLC is an iterative model
based on the assumption that a service system
evolves through a combination of planned and
unplanned changes. The planned changes occur
through formal projects with initiation, develop-
ment, and implementation phases. Unplanned
changes are ongoing adaptations and experimenta-
tion that change aspects of the work system without
performing formal projects.
Except when a work system is being created for the
first time, the WSLC starts with the operation and
maintenance phase, in which an existing work
Table 2 Three-column service responsibility table including a column for problems and issues
Provider Activity or Responsibility Customer Activity or Responsibility Problems or Issues
Loan officer identifies businesses that
might need a commercial loan.
Loan officers are not finding enough
leads.
Loan officer contacts potential loan
applicant.
Potential loan applicant agrees to dis-
cuss the possibility of receiving a loan
Loan officer discusses loan applicant’s
financing needs and possible terms of
the proposed loan.
Potential loan applicant discusses fi-
nancing needs.
Loan officer is not able to be specific
about loan terms, which are deter-
mined during the approval step,
which occurs later.
Loan officer helps loan applicant com-
pile a loan application.
Loan applicant compiles loan applica-
tion.
Loan applicant and loan officer some-
times exaggerate the applicant’s finan-
cial strength and prospects.
Loan officer and senior credit officer
meet to verify that the loan applica-
tion has no glaring flaws.
20%of loans applications have glar-
ing flaws.
Credit analyst prepares a loan write-
up summarizing the client’s financial
history, providing projections of
sources of funds for loan payments,
etc.
10%rate of significant errors, partly
because credit analysts use an error-
prone combination of several spread-
sheets and a word-processing pro-
gram.
Much rework due to inexperience of
credit analysts.
Loan officer presents the loan write-
up to a senior credit officer or loan
committee.
Meetings not scheduled in a timely
manner.
Questions about exaggerated state-
ments by some loan officers.
Senior credit officer or loan committee
makes approval decision.
Excessive level of nonperforming
loans.
Rationale for approval or refusal not
recorded for future analysis.
Loan officer informs loan applicant of
the decision.
Loan applicant accepts or declines an
approved loan.
25%of refused applicants complain
reason is unclear.
30%of applicants complain the pro-
cess takes too long.
Loan administration clerk produces
loan documents for an approved loan
that the client accepts
ALTER IBM SYSTEMS JOURNAL, VOL 47, NO 1, 2008
78
system is operated and maintained through small
fixes and adaptations. When management decides
that a significant work system improvement is
needed, an initiation phase identifies the scope,
goals, and resources of the project. The development
and implementation phases have business-oriented
meanings in the WSLC. Development encompasses
the acquisition, configuration, and creation of
resources needed for implementation of the planned
change in the organization. These resources include
debugged software, installed hardware, documen-
tation, procedure specifications, and training mate-
rials. In contrast to computer science definitions of
implementation (as in implementing an algorithm),
implementation in the WSLC is the process of
making desired work system changes operational in
the organization. This involves far more than
attaining initial use of new software. Most IT groups
lack the authority and power to enforce work
system changes in other functional areas. More
detailed explanations
1
of the WSLC reveal a large
number of common issues and guidelines, such as
why executives in charge of a work system that is
being created or improved should play an active role
in the implementation, whether or not the project is
led jointly.
The WSLC is fundamentally different from the
frequently cited system development life cycle
(SDLC). First, the SDLC is basically a project model
rather than a system life cycle. (Even iterative
development models are basically concerned with
iterations within a project.) Second, the system in
the SDLC is essentially a technical artifact that is
being programmed. In contrast, the system in the
WSLC is a work system that evolves over time
through multiple iterations. This evolution occurs
through a combination of defined projects and
incremental changes resulting from small adapta-
tions and experimentation. In contrast with control-
Table 3 Examples of typical topics for additional columns of an SRT
Topics related to problems or issues Topics related to the structure and
requirements of the system
Topics related to performance metrics
Problems and issues
Participant or interpersonal issues
Information issues
Technology issues
Training issues
Points of friction
Reasons for delays, errors, and rework
Communication issues
Conflicts with culture or policies
Legal or regulatory issues
External dependencies
Conflicts with other systems
Goals and requirements
Preconditions
Triggers
Business rules
Business or legal constraints
Post-conditions
Special cases
Significant exceptions
Alternative paths or methods
Knowledge or skill requirements for
participants
Participant incentives
Information used
Information generated
Technology used
Products and services produced (and
used in other systems by customers or
provider organizations)
Possibilities for change
Features that cannot change
Benefits provided to customers
Activity rate
Duration (cycle time)
Delay between steps
Defect rate
Rework rate
Downtime
Provider cost
Customer cost
Customer complaints
Information accuracy
Information timeliness
Information availability
Information security
Technology performance
Key performance gaps for important
steps (a gap is the desired vs. current
value of an important metric)
IBM SYSTEMS JOURNAL, VOL 47, NO 1, 2008 ALTER 79
oriented versions of the SDLC, the WSLC treats
unplanned changes as part of the natural evolution
of a work system.
USING THE THREE FRAMEWORKS
There are many ways to use the three frameworks
individually and in combination. The most impor-
tant and most general application in relation to
service systems is in supporting the analysis, design,
and improvement of those systems. A complete
analysis of a specific service system involves a large
number of topics that can be organized using the
three frameworks. For example, the work system
framework can be used to organize topics that are
related to specific elements of a service system, such
as the processes and activities or the information.
Similarly, the service value chain framework can be
used to organize topics that are specifically related
to services. The WSLC model can be used to
organize topics related to the evolution of a service
system through iterations of planned and unplanned
change.
The frameworks and related ideas can be used in
various ways in five different roles (recognizing that
the same person may play multiple roles). The scope
and level of detail differs across the roles and across
different situations. In all cases, the analysis and
design of a system should include typical steps of
identifying the problem and system, performing an
analysis, and producing a justified recommendation.
Role 1. Executives want their subordinates to
perform thoughtful analysis of service systems but
often are not directly involved in details. While
participating in a discussion, they can use the work
system framework to think about whether the
service system and problem were defined, whether
the analysis covered all elements of the service
system, and whether the recommendation identified
proposed changes in each element.
Role 2. Strategists for service systems should think
about those systems in big-picture terms. By
providing organized access to design variables, the
frameworks have potential for helping managers
and business professionals perform the strategist
role more effectively. (It is doubtful whether the
strategist role is taken seriously in many systems
analysis situations, especially since most tools and
techniques focus on producing documentation and
getting the details right.) Some design variables for
strategists are related to service systems as a whole,
such as flexibility, scalability, degree of centraliza-
tion, and degree of virtuality. Others are related to
specific elements of the work system framework,
such as the complexity, variety, rhythm, and degree
of structure in processes and activities. Yet other
Figure 3
The work system life cycle model (from Reference 1, by permission)
Unanticipated adaptations
Redesign
Continue
Ter mi nate
Accepted for
operation
Recognition of
non-adoption
or excessive
workarounds
Recognition of infeasibility in vision, goals, or resources
Ready for implementation
Unanticipated adaptations
Unanticipated opportunities
Ready for
development
Recognition of
infeasibility in
vision, goals,
or resources
Unanticipated opportunities
Implementation
Operation and
Maintenance
Initiation
Development
ALTER IBM SYSTEMS JOURNAL, VOL 47, NO 1, 2008
80
variables are related to service characteristics
implied by the service value chain framework, such
as the extent of coproduction, parameters of
negotiations, and relative amount of effort in
preparation versus fulfillment of specific requests.
Role 3. Managers need to make sure that service
systems operate efficiently and effectively. They
need to understand operational details because they
can neither control nor improve the results without
a grasp of how the service system operates and how
it satisfies the customer’s wishes and needs. On the
other hand, they do not need to start with high-
precision tools such as flowcharts and database
schemas. Instead, they can use an SRT to identify
the main steps in the workflow, and then can use
additional columns to organize their thinking related
to elements of the work system framework such as
information, technology, participants, and products
and services produced. For example, unless the
service system is totally automated, when thinking
about participants they should consider skills,
knowledge, incentives, and organizational issues
related to each step.
Role 4. Implementors of service system changes
need the same types of understanding required in
the manager role, but also need to understand
change management. The WSLC and more detailed
topics related to each part of it are potentially useful
for them because the WSLC emphasizes the entirety
of the service system change, rather than just
software development and testing.
Role 5. Consultants and IT professionals need to
understand enough about a service system to
perform technical analysis and design tasks. When
producing, configuring, and maintaining hardware
and software the service system relies upon, IT
professionals need to focus on a large number of
computer- and network-related details that business
professionals never need to know. In addition to
understanding the parts of the service system that
use IT directly, they should recognize that focusing
solely on IT-reliant steps and activities creates
blinders that limit their potential contribution and
may lead to misunderstandings that undermine IT
applications. Consequently, IT professionals are
more successful if they can communicate effectively
with people in strategist, manager, and implementor
roles. All three frameworks might help them in their
own understanding of the situation and in their
communication with others.
Use of the three frameworks and related concepts
and tools for the five roles might lead toward
heuristic but non-algorithmic guidelines for linking
documentation for one role with documentation for
other roles.
14
For example, a two-column SRT
provides a useful starting point for producing a more
precise process definition in the form of a flowchart,
event-driven process chain, or other formalism. A
three-column SRT that identifies business rules for
each step would help in producing a more formal
process definition. A three-column SRT that identi-
fies information used by each step could be a
starting point for developing entity relationship
diagrams. A three-column SRT that identifies actual
or desired computerized support for specific steps
could be a starting point for developing Unified
Modeling Language** (UML) use cases. In all cases,
IT professionals can fill in the logic or details that
are not fully specified by business professionals.
AUTOMATED AND NONAUTOMATED SERVICES
The three frameworks describe service systems from
a business viewpoint and make no assumptions
about whether IT is involved. There is a huge
conceptual gap between services that are perceived
directly by customers versus services that operate
deep within computerized infrastructures. That gap
leads to the question of whether three business-
oriented frameworks are also relevant to invisible
automated services discussed by technologists un-
der headings such as Web services and service-
oriented architectures.
As an example, consider another banking applica-
tion, the automated handling of mortgage loan
applications by IndyMac Bank.** As described in a
recently published case study
15
that did not use the
three frameworks, loan applications are submitted
online and are evaluated automatically by a
proprietary underwriting engine that ‘‘returns a
price and underwriting guidelines to the Web site in
about a minute or less. Previously, the industry
norm was three weeks.’’ The process includes
generating a ‘‘tri-merge credit report’’ on the
borrower, determining the loan programs for which
the borrower qualifies, pricing the loan based on the
loan amount and credit characteristics, generating
underwriting guidelines under which the loan will
be approved, and displaying the results to the loan
applicant. The segmented, automatic operation of
the underwriting engine is based on process
standards and disciplines that seem similar to the
IBM SYSTEMS JOURNAL, VOL 47, NO 1, 2008 ALTER 81
componentization discussed in conjunction with
service-oriented architectures.
The IndyMac example fits into the three frameworks
as follows:
Work system framework. The processes and activities
were mentioned above. The only participant is the
customer because all other activities are performed
automatically. The information includes the appli-
cation, the borrower’s credit information, the
parameters of available loans from different sources,
and the pricing and conditions generated by the
underwriting engine. The technology that the
customer sees is the Web site, but the relevant
hidden technologies include credit scoring models,
credit databases, and the proprietary underwriting
engine. The products and services include the terms
and conditions of the loan, information captured for
the IndyMac marketing analysis, and any informa-
tion made available to regulatory bodies. Customers
include the loan applicant and others who receive
information created by the service system. Key
aspects of the environment start with the competi-
tive environment, especially how competitors obtain
and process loan applications. Other aspects of the
environment include any federal and state regula-
tions that may apply. Infrastructure is especially
important in this automated system. Its technical
infrastructure includes the Internet and other
networks that provide required information. Its
informational infrastructure includes personal credit
information from credit rating services that sell
information to any legitimate business user. Its
human infrastructure includes the people who
maintain the service system and who are therefore
best viewed as part of a separate service system that
maintains the technology in the automated service
system. The strategy of the service system is based
on automating the processing of loan applications
and then linking the results to other systems for
funding the loan, receiving periodic payments, and
selling the loan.
Service value chain framework. The creation and
testing of the underwriting engine and related
modules obviously must precede service delivery.
Customers must become aware of the existence of
IndyMac. The delivery of the service begins with the
request in the form of a loan application filled out
online. The fulfillment involves automated back-
stage processing to determine the terms and condi-
tions of the available loans, to lock in rates, and to
verify that the data provided by the applicant is
correct. After the customer accepts the offer, other
back-stage processes fund the loan. The customer’s
follow-up includes submitting monthly loan pay-
ments.
Work system life cycle model. The current version of
the application and underwriting system is notably
different from earlier application and underwriting
systems that responded to applicants after several
weeks. A series of innovations leading from largely
manual processes to highly automated processes
were implemented by various lenders and subse-
quently adapted by their competitors. In each of its
innovations and significant adaptations, IndyMac
followed the WSLC steps of initiating a project that
would accomplish the change, developing and
testing whatever technologies and procedures were
required, and implementing the desired procedural,
organizational, and technical changes.
It is clear that tools such as the work system
snapshot and the SRT (Tables 1 and 2) can be used
to summarize and analyze IndyMac’s highly auto-
mated service systems from a business viewpoint.
The same ideas can be used to summarize and
analyze subsystems, such as loan underwriting and
loan pricing. Each of the totally automatic IndyMac
subsystems at the top level can be viewed as a
separate service system that performs work for a
customer, and therefore can be analyzed using the
same tools. Each of those subsystems might be
decomposed further into its own subsystems. It is
not clear, however, whether using the frameworks
and related tools at additional levels of decomposi-
tion would yield insights about how the IndyMac
loan-processing system operates or could operate
more effectively. At the point where each subsystem
is totally automatic, human participants and cus-
tomers no longer play a direct role, inputs and
outputs are clearly defined, and the analysis focuses
on the technical performance of computerized
processes and the infrastructure they rely upon. (As
noted earlier, people are part of the infrastructure
that keeps the automated systems running, but are
not part of the automated systems themselves.)
Moving further toward a computer science view of
services, most of the concepts in the service value
chain framework are related to terms and models
used to describe Web services. For example,
ALTER IBM SYSTEMS JOURNAL, VOL 47, NO 1, 2008
82
Umapathy and Purao
16
present a reference model
for classifying Web services standards. They use
that model to organize standards from three
different initiatives related to Web services (W3C,
Semantic Web services, and ebXML). Concepts in
the service value chain framework map into most of
the terms in their framework, such as contract
establishment, proposal and negotiation, capability
search, capability exposure, guarantee, and mes-
saging. Although beyond the scope of this paper, in
future research it will be worthwhile to explore
possible mappings between the service value chain
framework and the functions included in various
Web services standards. The result might be greater
clarity about conceptual links between visible
service functions performed by people, automated
service functions performed by computers under
direct human control, and totally automated Web
service infrastructure capabilities.
CONCLUSION
The first sentence of this paper posed the challenge
of providing a unified view of service that is
genuinely useful and goes beyond providing a
definition of service or a solution to a situation-
specific problem. It addressed that challenge by
showing how three interrelated frameworks can be
used together to describe and analyze how service
systems are created, how they operate, and how
they evolve through a combination of planned and
unplanned change. Two of the frameworks, the
work system framework and work system life cycle
model, are relevant to understanding and analyzing
service systems because service systems are work
systems. The third framework, the service value
chain framework, augments the work system
framework by introducing ideas related to how
services are coproduced.
Usefulness and breadth of applicability. The useful-
ness of the three frameworks and of concepts that
can be organized based on the frameworks was
demonstrated by the discussion of work system
snapshots and SRTs. The breadth of applicability
was demonstrated by the examples, which in
various ways involved external and internal cus-
tomers, automated and nonautomated services,
customized and semi-customized services, personal
and impersonal services, and different degrees of
self-service responsibilities.
Deeper layers. Frameworks are analogous to ice-
bergs because only so much can be visible. The full
usefulness of the frameworks presented here de-
pends on whether those frameworks organize and
link to important topics at other levels of detail. For
example, the usefulness of SRTs depends partly on
easy access to the concepts and topics that might be
used in additional columns.
Hierarchical codification of several layers of con-
cepts related to each part of the three frameworks
could form the basis of a body of knowledge
17
for
services. A preliminary step in that direction is a
proposed conceptual architecture for Sysperanto,an
ontology for understanding and analyzing systems
in organizations.
18
That architecture calls for iden-
tification of typical components (nouns), actions
(verbs), characteristics (adjectives), performance
indicators (adverbs), relationships, phenomena, and
generalizations related to each work system element
and to the work system as a whole. Almost all of
those properties should be inherited by service
systems, information systems, projects, and supply
chains, since all are special cases of work systems.
Inheritance from work systems in general to special
cases could provide an efficient way to organize the
body of knowledge for special cases of service
systems by placing relevant properties and other
knowledge at the highest applicable level.
Alternative frameworks. Usefulness and breadth of
applicability would be good criteria for evaluating
alternatives to the frameworks presented here. For
example, a service system framework that focused
totally on customer interactions could certainly
address important issues but probably would not
provide insight about services in which customer
interaction is nonexistent or relatively unimportant.
On the other hand, focusing totally on work systems
in general (hence omitting the service value chain
framework or something like it) would imply that
ideas specifically about services would not be
considered or would be included only in a subordi-
nate layer. Suffice it to say that comparison with
alternative models would be highly beneficial.
Automated service systems. The conclusion of the
IndyMac example showed why it is not clear how far
it is useful to go when analyzing totally automated
service systems based on the work system frame-
work and service value chain framework. The
conclusion also noted the possibility of developing
mappings between the functions in the service
value chain framework and functions represented in
IBM SYSTEMS JOURNAL, VOL 47, NO 1, 2008 ALTER 83
Web services standards. It is not clear whether the
fundamentals of service systems will need to include
an additional, computer-oriented framework at the
point where infrastructure subsystems perform
work automatically.
Better links between business analysis and technical
analysis of systems. Ineffective communication
between business and IT professionals is a long-
standing problem. Other than abstract 232 matrices
and Six Sigma** tools (many of which require
extensive training and data collection), there are few
analysis tools for business professionals, most of
whom require direct guidance from consultants or
IT professionals when trying to understand formal
documentation produced through IT tools such as
CASE (computer-aided software engineering) and
UML tools. As explained earlier, SRTs may provide a
link between the less-formal analysis that is
appropriate for business professionals and the
highly formal, high-precision analysis and docu-
mentation that is desirable for programming.
Real-world and instructional application. The ulti-
mate test of the ideas presented here is whether they
help practitioners and researchers analyze and
improve service systems, and whether they help
instructors teach about service systems. The two
examples in the paper illustrate that the frameworks
can be applied at a business-system level. Classroom
experience and personal testimonials to date suggest
that the three frameworks are useful to M.B.A.
(Master of Business Administration) and E.M.B.A.
(Executive Master of Business Administration)
students, both in class work and in their own
professional work. Field-testing of the usefulness of
all three frameworks, individually and in combina-
tion, would require experiments or pilot studies.
After training, users would be compared to non-
users trying to perform similar tasks related to
recognizing, understanding, analyzing, and design-
ing service systems.
Toward a science of service. The development of a
science of service or a science of service systems
19
could benefit substantially from an internally
consistent and inclusive set of ideas that help in
interpreting service research and practice and in
organizing instructional programs. The proposed
fundamentals of service systems, or something
similar, might meet this need because all significant
services are delivered through service systems.
**Trademark, service mark, or registered trademark of Object
Management Group, Inc., IndyMac Bank, F.S.B., or Motorola,
Inc., in the United States, other coutries, or both.
CITED REFERENCES AND NOTES
1. The work system framework (presented here in a slightly
updated form) and the work system life cycle model are
explained in substantial depth in S. Alter, The Work
System Method: Connecting People, Processes, and IT for
Business Results, Work System Press, Larkspur, CA
(2006).
2. S. Alter, ‘‘Service Responsibility Tables: A New Tool for
Analyzing and Designing Systems,’’ AMCIS 2007, Amer-
icas Conference on Information Systems, Keystone, CO
(Aug. 9–12, 2007).
3. J. A. Fitzsimmons and M. J. Fitzsimmons, Service
Management: Operations, Strategy, and Information
Technology, 5th Edition, p. 4, Irwin/McGraw-Hill, Boston
(2006).
4. P. Kotler and K. L. Keller, Marketing Management, 12th
Edition, p. 402, Prentice Hall, Upper Saddle River, NJ
(2006).
5. J. Carlzon, Moments of Truth, Harper Collins, New York
(1989).
6. J. Teboul, Service Is Front Stage: Positioning Services for
Value Advantage, Palgrave Macmillan, New York (2006).
7. L. Cherbakov, G. Galambos, R. Harishankar, S. Kalyana,
and G. Rackham, ‘‘Impact of Service Orientation at the
Business Level,’’ IBM Systems Journal 44, No. 4, 653–668
(2005).
8. A. W. Brown, M. Delbaere, P. Eeles, S. Johnston, and R.
Weaver, ‘‘Realizing Service-Oriented Solutions with the
IBM Rational Software Development Platform,’’ IBM
Systems Journal 44, No. 4, 727–752 (2005).
9. S. L. Vargo and R. F. Lusch, ‘‘The Four Service Marketing
Myths,’’ Journal of Service Research 6, No. 4, 324 (2004).
10. H. Chesbrough and J. Spohrer, ‘‘A Research Manifesto for
Services Science,’’ Communications of the ACM 49, No. 7,
35–40 (2006).
11. C. Hill, R. Yates, C. Jones, and S. L. Kogan, ‘‘Beyond
Predictable Workflows: Enhancing Productivity in Artful
Business Processes,’’ IBM Systems Journal 45, No. 4,
663–682 (2006).
12. The table is from page 17 of Alter (2006), mentioned in
Reference 1. The example is presented in depth in
Chapter 8, pages 103–114.
13. The work system method was developed partly as a
response to difficulties experienced by M.B.A. and
E.M.B.A. students trying to analyze systems. See S. Alter,
‘‘Pitfalls in Analyzing Systems in Organizations,’’ Journal
of Information System Education 17, No. 3, 295–302
(2006). The work system framework was used to analyze
e-commerce Web sites in D. E. Petrie, ‘‘Understanding the
Impact of Technological Discontinuities on Information
Systems Management: The Case of Business-to-Business
Electronic Commerce,’’ Ph.D. dissertation, Claremont
Graduate University, Claremont, CA (2004). The useful-
ness of the work system framework was tested directly in
D. Petkov and O. Petkova, ‘‘The Work System Model as a
Tool for Understanding the Problem in an Introductory IS
ALTER IBM SYSTEMS JOURNAL, VOL 47, NO 1, 2008
84
Project,’’ Proceedings of the 23rd Information Systems
Education Conference (ISECON 2006), Dallas (Nov. 4,
2006), http://isedj.org/isecon/2006/3524/ISECON.2006.
Petkov.pdf.
14. In contrast, a substantial amount of ongoing research
addresses the need to translate automatically between
different modeling tools and methods for IT professionals
such as event-driven process chains, UML, and Business
Process Execution Language (BPEL). Examples include:
W. M. P. van der Aalst, ‘‘Formalization and Verification
of Event-driven Process Chains,’’ Information and Soft-
ware Technology 41, No. 10, 639–650 (1999), B. Korherr
and B. List, ‘‘A UML 2 Profile for Event Driven Process
Chains,’’ in Research and Practical Issues of Enterprise
Information Systems, A. M. Tjoa, L. Xu, and S. Chaudry,
Editors, Springer, New York (2006), pp. 161–172, and J.
Ziemann and J. Mendling, ‘‘EPC-Based Modelling of BPEL
Processes: A Pragmatic Transformation Approach,’’
Proceedings of the 7th International Conference on
Modern Information Technology in the Innovation Pro-
cesses of the Industrial Enterprises (MITIP 2005), Genova,
Italy (2005).
15. E. Krogh, O. A. El Sawy, and P. Gray, ‘‘Managing Online
in Perpetual Perfect Storms: Insights from IndyMac
Bank,’’ MIS Quarterly Executive 4, No. 4, 425–442 (2005).
16. K. Umapathy and S. Purao, ‘‘A Theoretical Investigation
of the Emerging Standards for Web Services,’’ Informa-
tion System Frontiers 9, No. 1, 119–134 (2007).
17. Prior attempts to develop bodies of knowledge for
specific fields include SWEBOKt, a proposed body of
knowledge for software engineering. A. Abran, J. W.
Moore, P. Bourque, and R. Dupuis, Editors, SWEBOK:
Guide to the Software Engineering Body of Knowledge,
IEEE Computer Society, Los Alamitos, CA (2004), www.
computer.org/portal/cms_docs_ieeecs/ieeecs/education/
certification/SWebok_2004.pdf.
18. S. Alter, ‘‘The Architecture of Sysperanto, a Model-Based
Ontology of the IS Field,’’ Communications of the AIS 15,
No. 1, 1–40 (2005).
19. See Reference 10. Also see J. Spohrer, P. P. Maglio, J.
Bailey, and D. Gruhl, ‘‘Steps Toward a Science of Service
Systems,’’ IEEE Computer 40, No. 1, 71–77 (2007).
Accepted for publication August 13, 2007.
Steven Alter
School of Business and Management, University of San
Francisco, 2130 Fulton St., San Francisco, CA 94117
(alter@usfca.edu). Dr. Alter is a Professor of Information
Systems at the University of San Francisco. He received a B.S.
in Mathematics and Ph.D. in Management Science from MIT.
After teaching at the University of Southern California he
served for eight years as cofounder and Vice President of
Consilium, a manufacturing software firm that was acquired
by Applied Materials in 1998. His teaching and research focus
on 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, consolidates and extends research that has
appeared in many leading journals. &
IBM SYSTEMS JOURNAL, VOL 47, NO 1, 2008 ALTER 85
.
2008
Published online January 19,
