Service system fundamentals: Work system, value chain, and life cycle

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 disciplines: marketing, operations, and computer science.

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.¹ Service systems are work systems.

• The service value chain framework augments the work system framework by introducing functions that are associated specifically with services.² It 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.¹

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) professionals. 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 nonautomated services; customized, semi-customized, and non-customized services; personal and impersonal services; repetitive and non-repetitive services; 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 disciplines 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.

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”³ 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.”⁴ In some views of service, interactions with human customers are of the essence, such as Carlzon's term “moments of truth”⁵ and Teboul's book Service Is Front Stage.⁶ 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.”⁷ Whereas Brown et al., in another IBM Systems Journal paper states 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.”⁸

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 perishability—“(a) do not distinguish services from goods, (b) only have meaning from a manufacturing perspective, and (c) imply inappropriate normative strategies.”⁹

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, conflicting views of service are surely an obstacle to current attempts to develop a new science of services¹⁰ 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. Fundamental 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 governmental 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 distribution 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.

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 identifies nine elements that are part of even a rudimentary 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 technology show that a change in the processes and activities might call for a change in any of those elements, and vice versa.

Figure 1

The work system framework is designed to emphasize 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 framework uses processes and activities instead of a business process, which is often interpreted as a highly structured set of steps. Processes and activities 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.”¹¹ 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. Technologies (not IT) is used because multiple technologies 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 information 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 organizational culture and relevant regulations, policies and procedures, competitive issues, organizational history, 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, information, and technologies; and identify products and services for primary and secondary customers.

• As the analysis proceeds, the work system framework can guide the analysis through the use of questions and templates related to individual work system elements. Broadly applicable characteristics 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 recommendation. For example, a proposal to change technology without changing anything else is often incomplete.

• Throughout an analysis, the work system framework 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.

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 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.¹²

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 nontechnical individuals think about situations in system terms.¹³

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 augments the work system framework by introducing activities and responsibilities that are associated with services. 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 responsibilities 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 assumptions:

• Services are often coproduced by service providers and their customers. Therefore, a full understanding 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 services based on negotiated commitments (such as service-level agreements) under which the service 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 activities by both the service provider and the customer.⁶

• 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.

Figure 2

The inclusion of service concepts within the service value chain framework leads to characterizations of service systems that augment typical characterizations 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 characterizations 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.

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 identifying 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.²

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 responsibilities, rather than on details of technology and information.

• It identifies the job roles that are involved.

• It brings customer responsibilities into the analysis.

• It identifies steps involving service interactions (rows with both provider and customer responsibilities) 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 columns 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 recommendations about performing specific steps more successfully 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 and the extent to which they might cause new problems.

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, development, and implementation phases. Unplanned changes are ongoing adaptations and experimentation that change aspects of the work system without performing formal projects.

Figure 3

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 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, documentation, procedure specifications, and training materials. 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¹ 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 adaptations and experimentation. In contrast with control-oriented versions of the SDLC, the WSLC treats unplanned changes as part of the natural evolution of a work system.

There are many ways to use the three frameworks individually and in combination. The most important 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 centralization, 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 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.¹⁴ 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 identifies 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.

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 under headings such as Web services and service-oriented architectures.

As an example, consider another banking application, the automated handling of mortgage loan applications by IndyMac Bank.** As described in a recently published case study¹⁵ 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 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 application, 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 information 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 competitive environment, especially how competitors obtain and process loan applications. Other aspects of the environment include any federal and state regulations 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 conditions 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 payments.

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 subsequently 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 automated 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 decomposition 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 customers 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, Umapathy and Purao¹⁶ 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 messaging. 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.

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 usefulness 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 customers, 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 icebergs because only so much can be visible. The full usefulness of the frameworks presented here depends 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 concepts related to each part of the three frameworks could form the basis of a body of knowledge¹⁷ for services. A preliminary step in that direction is a proposed conceptual architecture for Sysperanto, an ontology for understanding and analyzing systems in organizations.¹⁸ That architecture calls for identification 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 subordinate 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 framework 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 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 2×2 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 documentation that is desirable for programming.

Real-world and instructional application. The ultimate 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 combination, 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 designing service systems.

Toward a science of service. The development of a science of service or a science of service systems¹⁹ 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.

Accepted for publication August 13, 2007; Published online January 19, 2008.