ASSESSMENT AND DESIGN OF SERVICE SYSTEMS:THE STRUCTURE OF SERVICE SYSTEMS

THE STRUCTURE OF SERVICE SYSTEMS

Most service-management concepts discussed so far clearly show an affiliation to either the produc- tion line view or the human resource or customer and marketing-oriented view on services. These different views have not been integrated much, mainly because very different scientific disciplines are involved. Obviously, both approaches are needed. Nowadays service processes are highly complex and call for the application of sophisticated methods from industrial engineering, while on the other hand the outcome depends heavily on the performance of employees and customers.

One way to handle this complexity is to apply a system view to services, as proposed by several authors (e.g., Lovelock 1995; Kingman-Brundage 1995). Systems are made up of elements bearing attributes and the relationships between those elements. Elements may be (sub)systems themselves. If the elements of a service system are defined as those different components that have to be designed and managed, then the most elementary system model for services is made up of three basic elements:

1. Customer: The customer normally initiates a service delivery process and performs certain tasks within it. The customer partly reflects the outcome dimension of service quality by being either satisfied or dissatisfied with the service.

2. Resources: Human and material resources perform defined functions within a service process and interact with the customer. They reflect the structure dimension of service quality.

3. Process: Processes can be viewed as the definition of interactions between the resources and the customers in a service system. However, there are reasons for defining them as the third basic element within the system. Assuming the production line approach, processes are objects that carry information regarding the service, especially in IT-based services. They exchange information with other elements in the system or even control them to a certain degree.

For several reasons, it seems useful to define a fourth basic element within the system, namely service products. So far, the notion of a service product has not been used in a clearly defined way. However, in recent years the term product has been used more frequently to express the idea that services can be developed and produced in a defined and repeatable way. Defining the concept of products within a service system therefore yields several benefits:

• So far, the outcome dimension of a service has been considered mainly from the customer’s point of view, taking outcome quality as equivalent to customer satisfaction. However, aiming only at customer satisfaction means that service quality easily becomes a moving target. This can be avoided by integrating all relevant information regarding the outcome of a service into a product model that is communicated internally and (to an appropriate extent) externally.

• The definition of a product clearly separates the outcome of a service from the way it is delivered. The product therefore acts as an interface between the market and customer view on a service (‘‘what is delivered’’) and a production or process view (‘‘How it is delivered’’).

• Product models support the modular set-up of services. Services that are offered with a wide range of variants are difficult to handle, particularly if the service depends heavily on infor- mation technology. A potential solution is the division of a service in separate modules that can be bundled according to the customer’s needs. This also greatly supports the development of new products or variants because they (and the corresponding software systems) only have to be assembled from existing parts.

A product model for services cannot simply consist of a one-to-one application of traditional product concepts from manufacturing. Instead, the product model must be derived from the essential characteristics of service processes. This can be achieved by an analysis of generic models of service delivery (e.g., the universal service map [Kingman-Brundage 1995] or the process model [Eversheim et al. 1997]) that yields those points within a service process that require information from a product model. Thus, a typical service process can be described in the following way:

1. A service is initiated by the definition of a service concept (Heskett et al. 1997) that is com- municated to the market and its targeted customers. The required resources are assigned in parallel.

2. Potential customers decide to contact the service provider in order to obtain additional infor- mation or to order the service instantaneously. For this purpose, the ways in which customers gain access to the service have to be defined and communicated. Traditionally, customers enter the service facility in person (e.g. a restaurant, a car repair shop). Depending on the particular service concept, this may be replaced by telephone or Internet access or a combination of those. In any case, an access system has to be defined that is located directly at the line of interaction between customer and service provider.

3. If the customer decides to order the service, some specifications regarding the desired variant have to be recorded by the access system.

4. The service delivery process must then be activated, using the specification that has been collected by the access system. First, however, a consistency check must be performed in order to verify whether the desired variant of the service is obtainable.

5. If the variant is valid, the configuration of the service will be set up, that is, those delivery processes that are required for the particular variant are activated.

6. If a process includes participation of the customer, the customer must be informed about the expected outcome and form of the cooperation. Results produced by the customer must be fed back into the delivery process.

7. As soon as all threads of the delivery process (carried out by the service provider or the customer) have been terminated, the outcome will be delivered and an invoice sent to the customer.

8. If the results are satisfactory, the contact between customer and service provider comes to an end and the overall process is finished. The customer may order some additional service or may return later to issue a new order. If the results leave the customer dissatisfied, a service- recovery procedure may be initiated or the customer may simply terminate the business rela- tion.

The information needed to control such a process is normally distributed between the people involved (employees and customers) and the documents that define the processes. However, the reasoning outlined above shows that it is useful to combine some elements within a product model. These considerations lead to the product model depicted in Figure 4, which uses an object-oriented notation according to the Unified Modeling Language (UML).

Using the object-oriented notion of a system, the individual elements of the product model are displayed as classes that have a unique name (e.g., ‘‘Service Product’’), bear attributes (e.g., ‘‘External Product Information’’), and use methods for interaction with other classes.

The product model is centered around the class Service Product. This class identifies the product, carries information for internal use, and provides all information regarding valid configurations of the product. Service Product may be composed of other, less complex products, or it may be an elementary product. It relates to a class Service Concept that defines the customer value provided by the product, the customers and market it aims at, and the positioning in comparison to its com- petitors. The class Service Product is activated by whatever provides the customer’s access to the service system. Access Module carries information on the product for external distribution and re- cords the specification of the product variant as requested by the particular customer. Access Module eventually activates Service Product, which subsequently checks the consistency and validity of the requested product configuration and sets up the configuration by ‘‘assembling’’ individual modules of the service. Then Deliver Product is carried out by activating one or several Service Functions that make up the particular product configuration. During and after the service delivery process Service Product may return statistics to the management system, such as cost and performance data. Also, Product Features may be attached to a Service Product, potentially including Material Com- ponents.

Each Service Product contains one or several Service Functions that represent the Outcome of the service. A Service Function carries information about the expected Quality Level (which may

be expressed by criteria like the ones used in SERVQUAL and a relation to the internal or external service delivery processes that realize this function. Jaschinski (1998) names six different types of service functions, four of which can be expressed within the product model:

1. A Basic Function contains the basic outcome a customer expects from the service, such as the transportation from location A to location B in the case of an airline.

2. An Add-on Function realizes some additional features that enhance the service compared to its competitors. Staying with the airline example, the large variety of meals or the lounges in the airport are such Add-on Functions.

3. Infrastructure is needed in many cases in order to enable the customer to use the service at all. An example is the check-in counters in the airport that provide the necessary preparation for boarding an airplane.

4. Customer Participation denotes the part of the service’s outcome that is produced by the customer. An example is the automated self-check-in that is used by several airlines.

According to Jaschinski (1998), interaction between customers and service provider and access to the service system represent two more functions. Within this product model, interaction is defined by the element Customer Interaction, of which Access Module must be regarded as a special in- stance.

The product model therefore acts as a central hub of a service system, coordinating the interactions of customers, employees, material resources, and processes. The product is activated by a customer, then initiates the required processes, which in turn call for necessary resources. This model explicitly shows the correlation between the elements of a service system and may serve as a template for designing a service from a product designer’s point of view.

Based on this concept, a framework for the assessment of a service system will be introduced in the next section that serves as a methodology for continuous improvement.