Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Pres 110_Steven Alter Jan 27 2016


Published on

ISSIP Service Innovation Weekly Speaker Series
Pres 110_Steven Alter Jan 27 2016

  • Be the first to comment

Pres 110_Steven Alter Jan 27 2016

  1. 1. Integrated, Operational Perspective on Service and Service Systems Steven Alter, University of San Francisco, Jan. 2016 . A nagging issue at the core of service science is lack of a single, universal definition of service that is useful across all service contexts. Table 1 shows a selection of published service definitions, all of which are useful in some contexts but not in others. Here is a simple, dictionary-like definition that applies almost everywhere: A service is an act or group of acts performed to produce or facilitate outcomes for the benefit of others. This definition supports different portrayals of service that are especially relevant to particular service situations. For example, many IT groups like to portray service as outcomes governed by service level agreements, the hospitality industry focuses more on interactions and value co-creation, and computer scientists emphasize totally automated services such as web services. Also notice that the definition of service implies that almost every economic activity (including the creation or modification of physical things) can be viewed as a service regardless of whether it is directed inside a firm or to external customers. BP1. Many valid portrayals of service from a single definition Why should anyone care about this integrated, operational perspective? An integrated, operational perspective on service and service systems should be useful to anyone who wants to analyze, design, implement, or evaluate services or service systems. This perspective is also relevant to marketing and competitive analysis because realistic value propositions need to be implemented through realistic operational systems. This perspective should help in resolving debates about isolated concepts such as the definition of service, definition of service system, and nature and importance of service interactions, co-production of services, value co-creation, and value propositions. Debates about isolated topics ido not provide an integrated approach for understanding operational systems that actually produce services. This perspective should also help in visualizing the areas where SDL, service dominant logic (often cited as the core of service science), applies most directly and areas where it is not as pertinent. What does this perspective cover? This perspective covers any service or service system: --- Simple or complex --- Sociotechnical or automated --- One-time or repetitive --- For benefit of external customers or for internal customers within the enterprise --- Involving economic exchange or quite distant from economic exchange --- Barely interactive with customers or highly interactive with customers --- Within one organization or crossing multiple organizations (e.g., supply chains) Examples of such services and service systems: haircuts, gardening services, medical care, transportation, education, package delivery, consulting, Web services, network maintenance, architectural design, process outsourcing, bug fixes, customer support, software customization, traffic control, water supply, and public safety services. Five Basic Premises (BPs) Five basic premises are relevant to almost all services and service systems. : BP1. Many valid portrayals of service from a single definition.. Services are acts or groups of acts performed to facilitate or produce outcomes for the benefit of others. That definition supports specific portrayals that are especially relevant to specific situations. BP2: Visualizing services as product/services. The distinction between product and service is ineffective for describing or fulfilling customer needs. Most offerings to internal and external customers often combine characteristics associated with products in everyday conversation and characteristics associated with services. The concept product/service is useful for practical analysis, design, implementation, or evaluation of services and service systems. It leads to positioning a product/service in relation to multiple design dimensions. BP3: Focusing on responsibilities, visibility, and value capture. Implementing and operating service systems that produce product/services requires design decisions related to responsibilities, visibility, and value capture. Relevant decisions include the division of responsibilities between providers and customers, the visibility or invisibility of specific information or activities to providers and customers, and the capture of value by providers and customers across all service interactions and related activities. BP4: Recognizing operational variability and noncompliance by providers and customers. A realistic, operational view of services and service systems needs to consider variability of every aspect of a service system and the possibility of noncompliance with expectations and/or specifications for activities of both providers and customers. BP5. Treating service systems as work systems. Non-improvised services are produced by service systems that are work systems. Work system theory can be used for understanding and improving services and service systems. A work system metamodel is useful for understanding various definitions of service along with taken-for-granted concepts such as service interaction, service modularity, co-production, and value co-creation. Portrayal Definition acts for others “an act or performance that one party can offer to another that is essentially intangible and does not result in the ownership of anything.” (Kotler and Keller 2006, p. 402) acts for others “value-creating support to another party’s practices” (Grönroos 2011, p. 285) acts for others the “application of skills and knowledge (operant resources) for the benefit of another party” (Vargo and Lusch 2008, p. 6) outcomes “a change in the condition of a person, or a good belonging to some economic entity, brought about as a result of some other economic entity, with the approval of the first person or economic entity.” (Hill 1977, p. 318) outcomes “an essentially intangible set of benefits provided by one party to another.” (Clerc and Niessink, 2004 p. 104) outcomes “A means of delivering value to Customers by facilitating Outcomes Customers want to achieve without the ownership of specific Costs and Risks.” (ITIL 2011, p. 66) guaranteed outcome “Services are guaranteed sets of outcomes and experiences, delivered across particular places, times, and platforms, by the processing or rendering of customer assets; or the provisioning of valued resources.” (Iqbal 2014) interaction “a time-perishable, intangible experience performed for a customer acting in the role of a co-producer.” (Fitzsimmons and Fitzsimmons 2006, p.4) response to request “intangible activities customized to the individual request of known clients.” (Pine and Gilmore 1999, p.8) response to request situations in which “the customer provides significant inputs into the production process.” (Sampson and Froehle 2006, p. 331) value co- creation Foundational premise #6 in the 2008 version of S-D logic says “The customer is always a co-creator of value.” (Vargo and Lusch 2008) basis of exchange Foundational premises #1 and #2 of S-D logic say “Service is the fundamental basis of exchange.” and “Indirect exchange masks the fundamental basis of exchange.” (Vargo and Lusch 2008). software entity that encapsulates functionality A service “is generally implemented as a course-grained, discoverable software entity that exists as a single instance and interacts with applications and other services through a loosely coupled (often asynchronous), message-based communication model.” (Brown et al. 2005) “The component that consumes business services offered by another business component is oblivious to how the provider created the business service.” (Cherbakov et al. 2005) software entity that encapsulates functionality “Services constitute encapsulated and exposed functionality drawing from core artifacts, e.g., those related to business processes, applications, objects, and resources. ... Whereas business process activities are said to be orchestrated across collaborating resources, service capabilities are delivered to consumers by providers. ... They provide functionality aimed at delivering value to consumers in terms of expected outcomes, subject to delivery constraints, e.g., availability, pricing, copyright or disclaimers. In doing so, they alleviate consumers with ownership of resources, costs or risks.” (Oberle et al. 2013, p. 158) BP5. Treating service systems as work systems . Figure 3: Three Components of Work System Theory 1) Definition of work system: a system in which human participants and/or machines perform work (processes and activities) using information, technology, and other resources to produce specific product/services for specific internal and/or external customers. 2) Work system framework: a static view of a work system as it exists during a particular time interval when it retains its identity and integrity even though it may change slightly through small adaptations, workarounds, and personnel changes. This framework identifies nine elements of even a basic understanding of a work system 3 Work system lifecycle model: a dynamic view of how work systems change over time through a combination of planned and unplanned change. The planned changes occur through projects with initiation, development, and implementation phases. The unplanned changes occur through adaptations and workarounds. Non-improvised services are produced by service systems that can be viewed as work systems. The concept of work system has been used for decades by sociotechnical practitioners and researchers. The operational view of services and service systems is based on work system theory – WST (Alter, 2013), which contains three components shown on the right: WST is the basis of the work system method (WSM),a systems analysis method in which the system of interest is a work system. Different versions of WSM have been used by many hundreds of MBA and Executive MBA students in the USA, India, China, and Vietnam. WSM first identifies the work system that has main problems or opportunities that launched an analysis. The “as is” work system is summarized based on the work system framework (on the right). The analysis focuses on measures of performance, key incidents, structural flaws, responsibilities of providers and customers, value capture, and other issues. The product of WSM is a proposed "to be" work system whose performance should be better than the existing work system. Shown below is version #6 of a work system metamodel that reinterprets the elements of the work system framework in more detail. The work system framework is good for thinking about the work system’s scope at the beginning of an analysis. The metamodel fills in many details that are needed to specify how the work system will actually operate. That level of detail is essential for specifying business processes and related software. Unfortunately the metamodel’s level of detail involves so many boxes and arrows that it is too complex to show to most business professionals. Nonetheless, aspects of the metamodel provide an operational view of many service science concepts. Parts of the metamodel are explained in a small font on the lower right. Below are implications for key service concepts. Enterprises and value constellations consist of work systems. Work systems always contain at least one activity. They may contain one or more business processes if a set of activities is sufficiently interrelated and sequential to qualify as a process. Activities use resources to produce one or more product/services from activity that may be used as a resource for subsequent activities and/or may contribute to a product/service offering. A product/service offering may combine multiple product/services from activities. Thus, only some of the product/services from activities are included in product/service offerings that are received or used by customer work systems, and hence by customers. Product/service offerings may or may not be governed by a service level agreement that is a type of commitment. Formal service level agreements are essential in some situations, especially for service offerings defined through extensive negotiations, but are unnecessary in other situations. Customer work systems create value for customers using their own resources plus product/service offerings produced by the provider work system. Resources used by an activity may include human resources (participants), informational resources, technological resources, and other resources. The metamodel includes specific types within each resource type to minimize the likelihood of omissions in an analysis. Activities are performed by actor roles. Actor roles can be performed by three types of entities, noncustomer participants, customer participants, and automated agents. In medicine, a doctor is a noncustomer participant, the patient is a customer participant, and software that automatically identifies drug interactions is an automated agent. The outcome of activities that use human resources (participants) depends on attributes of those participants, such as knowledge/expertise, skills/capabilities, performance metrics, and motives. Technological resources used in an activity may include tools used directly by participants (e.g., a truck) or an automated service that operates autonomously after being launched (e.g., a search engine). Informational resources may include many types of informational entities such as transaction records, plans, forecasts, goals, guidelines, rules, structures, commitments and other information such as documents, video, images, messages, and even conversations. Other resources used by an activity may include physical entities; time; resources from the environment such as organizational culture, laws, standards, regulations, and policies; and resources from shared infrastructure including shared human resources, shared informational resources, and shared technical resources. Both the work system and customer work system may interact with other work systems with positive and/or negative impacts on the operation of either work system. Almost every economic activity can be viewed as a service by the definition above. Distinguishing strictly between products and services is rarely useful when analyzing or design service systems. It is more useful to think in terms of product/services that might combine characteristics often associated with products or with services in everyday conversations. That bypasses confusions that occur when activities usually described as services lack characteristics often associated with services, such as intangibility, heterogeneity (customization), inseparability (consumption as production occurs), and perishability. For example, it is easy to identify services that are not intangible (e.g., fixing the foundation of a client’s house), are not customized (e.g., transportation on a subway), are not consumed as produced (e.g., creation of a contract that will remain in force for years), and are not perishable (e.g., education, which ideally should last a lifetime). Those examples illustrate why focusing on yes/no distinctions is less useful than recognizing and using multiple design dimensions, such as the extent to which the customer receives value from things versus actions, the extent to which an offering is standardized versus customized, and the extent to which an activity results in ownership of something. To illustrate this point, Table 2 positions five different medical services quite differently along as set of design dimensions even though all five would typically be viewed as services. Characteristics of some of the medical service examples contradict definitions of service in Table 1. For example, an artificial hip’s recipient becomes the owner of an expensive physical object (the surgically implanted prosthesis) that obviously is not intangible, is not consumed as it is produced, and is much more than an experience. Many aspects of vaccinations at a public health clinic are quite product-like because they are standardized, transactional rather than relational, involve transfer of ownership (of the vaccine dose), and accommodate little customer discretion. BP2. Visualizing services as product/services More product-like <<-------------------------------------->> More service-like Customer value from things that the customer receives -------E-------------D-A------------CB- Customer value from provider actions Customer value from things that the customer uses --------E--------- D-A -------------C—B Value from experience that the provider co-produces Production of value by the provider -----------D-------C---A-E------------B- Co-production of value by the provider and customer Standardized, scripted interactions and products -E-D-------------C-----------------AB— Customized, non-scripted interactions and products Value from tangible features of whatever the provider produces -D-A-B------------C-----E--------------- Value from intangible features of whatever the provider produces Transferred to customer and used later ---E-------------------------A---D----BC Consumed by customer during production Produced by provider with little or no co-production ----D-E-----------------C---------A---B- Customer plays extensive role in co-production Transfer of ownership ------AD------------E--------------BC— Non-transfer of ownership Transaction-based interactions -EDC----------------------A-----------B- Relationship-based interactions Interactions not concerned with the customer’s emotional state -----E----------D---C---------------AB- Interactions concerned with the customer’s emotional state Examples: A = surgery to install an artificial hip B= extended courses of physical therapy for recovery from serious injuries C = pre-employment physical exams D = vaccinations provided at a public health clinic E = standardized, web-based wellness course provided by a vendor for employees of a university Table 2. Placement of Five Hypothetical Medical Product/Services across Multiple Design Dimensions (Alter 2012, p. 28) BP3. Focusing on responsibilities, visibility, and value capture Table 1. Portrayals of Service Implied by Different Published Definitions of Service Implementing and operating service systems that produce product/services requires design decisions related to responsibilities, visibility, and value capture. Figure 2 shows a service value chain framework that emphasizes those topics. The service value chain framework depicts generic activities and responsibilities of both service providers and customers. These activities and responsibilities may occur before, during, and after delivery of a specific product/service to a specific customer. The framework’s bilateral form is based on the common observation that services tend to be co-produced by service providers and service consumers. That framework incorporates typical categories of service activities and responsibilities, such as negotiating commitments, performing set-up prior to instances of service delivery, handling service requests, fulfilling service requests, and performing follow-up. Other aspects of the framework represent important service design issues such as the governance of service instances by service level agreements, the form and frequency of service encounters, the distinction between front-stage vs. back-stage activities, and the importance of value capture by both customer and provider. It addresses responsibilities, visibility, and value capture in the following ways: Responsibilities. Understanding the production of product/services requires attention to activities and responsibilities of both service providers and service customers. This is equally true regardless of whether the customers are internal or external to the enterprise. There are many situations such as medical care or custom software development in which inadequate performance by either providers or customers undermine the best efforts of the other party. Visibility. The extent of mutual visibility for providers and customers across the activities in the service life cycle is a fundamental design decision. For example, a software developer’s customer might be quite concerned about exactly how the software was tested. Conversely, a doctor might want more visibility about the extent to which a patient actually follows medical advice. The vertical lines inside of the service delivery and service consumption rectangles separate the things that are visible versus invisible to the provider and customer. Service encounters are mutually visible, while other activities may or may not be mutually visible. Figure 1. Different Portrayals of Service Figure 2. Service Value Chain Framework Illustrating Relevance of Responsibilities, Visibility, and Value Capture Value capture. The value capture indications on both sides of the framework say that that both customers and providers capture value and that value capture occurs throughout the service life cycle. For example, both the customer and the provider usually value the experience of dealing with service partners who are easy to work with and who meet their commitments Operational variability and noncompliance with expectations and/or specifications for activities of both providers and customer often affect or even undermine real world outcomes of service processes and business models. Sources of variability include factors such as human error, accidents, unanticipated interactions with other systems, and noncompliance with process specifications. Noncompliance may result from any combination of inadequate training, inadequate execution, exception conditions, adaptations, workarounds, and attempts to bypass processes for personal benefit. Table 3 identifies a number of possibly surprising ways in which compliance with rules and expectations is sometimes detrimental and noncompliance is sometimes beneficial. In other words, realistic description, analysis, design, or implementation of product/services and service systems needs to account for operational variability and compliance and noncompliance by both providers and customers. BP4. Recognizing operational variability and noncompliance by providers and customers Beneficial Detrimental Compliance Beneficial compliance  wholehearted compliance  halfhearted compliance Detrimental compliance  working-to-rule  malicious compliance  self-serving compliance  thoughtless compliance Noncompliance Beneficial noncompliance  working around unrealistic processes  working around unduly restrictive controls  working around inadequate hardware/software  working around malfunctions and temporary obstacles  prioritizing higher goals over process specifications  cheating slightly to accomplish higher priorities Detrimental noncompliance  accidental noncompliance  well-meaning but harmful noncompliance  fraudulent or malicious noncompliance Table 3. Combinations of Beneficial and Detrimental Compliance and Noncompliance Figure 1 shows how different portrayals of service are related to the simple definition above. Starting with service as acts performed for others, the Figure shows a path to other portrayals based on adding concepts such interactions, outcomes, value co-creation, economic exchange, or automation. Notice how totally automated services differ from co-created services. Customer work system. Separating out the provider work system and the customer’s value creating work system emphasizes that customers create value for themselves. It also raises the challenge of what to say about value for the customer when there is no visibility of customer work systems. Provider and customer responsibilities. Customer responsibilities appear in two places: 1) wherever customer participants perform actor roles within provider work systems and wherever customer activities in customer work systems produce value for customers. Coproduction. Coproduction occurs wherever customer participants perform actor roles in activities within a provider’s service system. Deciding whether something qualifies as a service because coproduction is present would say yes to a 20-step process consisting of one customer request followed by 19 provider activities. It is more useful to examine the extent and form of coproduction, and ask whether more coproduction or less (i.e., less encapsulation or more) would be preferable for providers and/or customers Value co-creation. This occurs, at least to some extent, wherever activities in the customer’s value creating work system coincide with activities in the provider’s work system. The metamodel reflects the view that firms facilitate value creation by customers through provision of human, material, and informational resources for customer use. Value co-creation is optional since suppliers decide whether and how to engage directly with customers’ value- generating processes. (Grönroos 2008; 2011) Customer experience. The customer experience is a combination of the experience of interacting with the provider and the experience of attaining value that is facilitated by the provider’s product/service offerings, whether or not the provider work system is at all visible to customers at that point. Self-service. In a self-service work system (e.g., buying books online), customer participants use resources (such as web sites) that are made available by a service provider to allow the customer to perform personally beneficial activities independently without interacting with noncustomer participants. Value proposition. In marketing communications value propositions sometimes are imprecise, inaccurate, exaggerated, or intentionally misleading. Assuming that value propositions are meant to reflect operational realities, the concept of value proposition can be treated as an attribute of a product/service offering i.e., a statement of what the customer would have to give up in order to receive and use the product/service offering and why that would be a good idea. The metamodel’s implications related to key concepts of service and service systems What are the alternatives to this operational view? This very large single slide summarizes an integrated, operational view of service and service systems. Almost all service systems can be described, analyzed, implemented, and evaluated using the ideas discussed here, although, as is noted in the very small print at the bottom of the metamodel, many of the ideas have goals, attributes, performance indicators, and related principles, patterns, and generalizations that do not fit into a one page representation. On the other hand, lack of additional detail surely is not a genuine obstacle for asking whether this integrated operational perspective on service and service systems makes sense. Here are the main questions to think about: 1) Do the five basic premises suffice as the basis for an operational understanding of services and service systems? If not, what is incorrect, misguided, or missing? 2) Have these ideas been presented previously in a complete and cogent form? If so, where was that done and to what extent were those ideas accepted and used? 3) Many researchers say that service dominant logic is the basis of service science . How does SDL provide an operational basis for understanding and analyzing service and service systems? Does it need to be complemented by other sets of ideas such as those explained here? © 2016, Steven Alter, all rights reserved