Article Preview
Top1. Introduction
The concept of service is defined as “a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks” (Rudd & Lloyd, 2007). This definition can be split in two parts: 1) a service delivers value to customers by providing them with the outcomes that they desire. 2) The service relieves the customers from dealing with the cost and risks associated with the outcomes they desire. We call the first part the “service offering” and the second part the “service implementation”. In the service design context, we use the term “service adopters” to refer to the customers who benefit from the service. This definition reminds us that service adopters often care more about the value they derive from a service than the way the service is implemented. In most cases a service is offered as a black box, without service adopters knowing how it is implemented. The service supplier, however, must make sure that the implementation is capable of delivering the value expected by service adopters. Service design is the act of aligning the value (i.e., the black box view as seen by service adopters, and the benefits to service supplier) with the implementation (the white box view as seen by the service supplier). The service supplier provides the service to service adopters for a reason. It benefits directly and indirectly from the relationship with service adopters. Direct benefits include service payments made by service adopters, i.e., value in exchange (Vargo et al., 2008). Indirect benefits can be the growth of the service adopter base leading to more service adopter payments, i.e., value in use (Vargo et al., 2008). Hence, the service supplier also finds value in the service. We therefore distinguish between service adopter value (i.e., the value created for the service adopter) and service supplier value (i.e., the value captured by service supplier). The service offering includes both these value propositions. The service provider sometimes engages in developing offerings in service systems such as open source or standard development and promotion projects. The value captured and created by the service provider in such projects is not within the scope of this paper.
In this paper, we show how the Systemic Enterprise Architecture Method (SEAM) can be used to design the service offering and the service implementation while aligning it with the service adopter and service supplier value. The foundations of SEAM are in General Systems Thinking (GST) (Weinberg, 2001) and in RM-ODP (International Organization for Standardization, 1995). GST is the study of principles that are applicable to any kind of system (e.g., business system or IT system). RM-ODP is a software engineering ISO standard that provides solid definitions for the SEAM concepts. SEAM is rigorously defined based on these systemic and software engineering concepts (e.g., object, state, behavior). SEAM federates multiple modeling techniques (such as discrete behavior, goals or quantitative models). SEAM has been applied for teaching (Wegmann et al., 2007) and consulting (Wegmann et al., 2005) since 2001. Prior applications of SEAM to service design have been published in Wegmann et al. (2008), Rychkova et al. (2008), and Golnam et al. (2011).
The service design process with SEAM comprises three phases as illustrated in Figure 1. First, we analyze the service offering and implementation as-is to identify how well the service offering is aligned with the value on the service adopter and service supplier side. We then identify the service improvement opportunities. This leads to the redesign of the service offering and implementation. The dashed arrow in Figure 1 suggests that the design process can be applied more than once for achieving continuous improvement.
In SEAM we conceptualize the service supplier and its environment as a hierarchy of systems that includes value segments, value networks, service supplier, departments, etc. Figure 2 illustrates this hierarchy of systems.
Figure 2. Hierarchy of systems in SEAM