A Framework for the Design of Service Systems Yao-Hua Tan Department of Technology, Policy and Management Delft University of Technology, Delft, The Netherlands Wout Hofman TNO Information and Communication Technology, Delft, The Netherlands Jaap Gordijn Department of Computer Sciences, Vrije University Amsterdam, Amsterdam, The Netherlands Joris Hulstijn Thaurus and Delft University of Technology, The Hague and Delft, The Netherlands Abstract We propose a framework for the design and implementation of service systems, especially to design controls for long-term sustainable value co-creation. The framework is based on the software support tool e3-control. To illustrate the framework we use a large-scale case study, the Beer Living Lab, for simplification of customs procedures in international trade. The BeerLL shows how value co-creation can be achieved by reduction of administrative burden in international beer export due to electronic customs. Participants in the BeerLL are Heineken, IBM and Dutch Tax & Customs. Keywords Service science, service systems, value co-creation, service innovation lifecycle, e3-control, e3-value H. Demirkan et al. (eds.), Service Systems Implementation, Service Science: Research and Innovations in the Service Economy, DOI 10.1007/978-1-4419-7904-9_4, © Springer Science+Business Media, LLC 2011 51 52 Y.-H. Tan et al. 1 Introduction Over the past decades, services have become the most important part of economies (Heineke and Davis 2007). Basically, the service economy refers to the service sector. It leads to more sophisticated forms of cooperation, or what is called value co-creation (Spohrer and Kwam 2009). As Spohrer also points out, service systems are dynamic configurations of resources that interact via value-proposition-based interactions with governance mechanisms. Basic questions in this respect relate to Service Science, Management, Engineering and Design (SSMED). We focus, in particular, on the value co-creation in the setting of services that are offered by a service system; i.e. where a composed service is offered by a provider to an individual customer based on outsourcing parts of the composed service. An example of such a service offering is the mobile services that are offered to individual customers on their mobile phones, which is typically offered by a mobile operator, various content providers and a billing organization. Up till now most attention in service systems was focussed on analysing value propositions in a bi-lateral relation between customer and service provider, whereas we will argue that there is also a second important dimension to value propositions, namely in the collaboration between organizations to produce a joint value offering to a customer. Our basic research question in this context is: Which conceptual models and tools can be used for (re)design Business-toBusiness and Business-to-Government services in service systems? To answer this question, we present in this chapter a coherent framework for the design of service systems from a business perspective, which consists of two models for the conceptual part of the design process, and two tools that support the actual service system design, in particular in a network setting. We perform an extensive case study of service redesign in international trade to demonstrate that both the models and the tools of our design framework are useful and adequate for answering our research question. This chapter is structured as follows. First we present both models, namely the Service Innovation Aspects Model and the Service Innovation Life Cycle Model. Subsequently, we present the two conceptual modelling support tools, e3-value and e3-control. The case study elaborates on the application of these models and tools to service redesign in the Beer Living Lab. The chapter ends with a discussion of research implications and conclusions. 2 Service Innovation Aspects Model The Service Innovation Aspects Model addresses the conceptual aspects of the design process such as coordination and governance between the business analysis of services and identifying IT services to improve value exchange in a service system (Fig. 1). We distinguish the following aspects in this model: A Framework for the Design of Service Systems 53 Service Innovation Aspects Business services decompose organizations in service bundles Architecture Governance Business Applications Infrastructure coordination service framework trust, control supporting IT Services Service Oriented Architecture Fig. 1. Service Innovation Aspects model •฀ Services: The actual publication of value propositions with their conditions defined by parameter values. Typically, these services can be composed dynamically to meet customer requirements. •฀ Supporting IT services: Design of IT services for value exchanges, technically realized by for instance Web services according to a Service Oriented Architecture (SOA). •฀ Governance: Coordination and alignment of business and IT services, performance and service level agreements at business and IT level, trust and control mechanisms for fair distribution of value co-creation. •฀ Architecture: A conceptual approach to IT service modelling to support value exchange. Service is the key concept to support value propositions of actors in an organizational network, since this concept only specifies (part of) the behaviour of an actor that is externally visible to other actors. ‘Service’ as such should not only constitute value propositions, but also requires governance mechanisms for uncertainty reduction (Spohrer and Kwam 2009). The service concept abstracts from internal resources of a service provider to meet customer requirements. A service provider can autonomously allocate its internal resources meeting a customer requirement and outsourcing part of the required service. A service should also refer to policies and performance metrics. A policy refers to conditions and assumptions under which value can actually be exchanged. Metrics of a service refer to aspects like availability and performance and the basis for Service Level Agreements (Spohrer and Kwam 2009). To support a value proposition, interaction behaviour for actual value exchanges, interaction semantics, reachability (technical communication protocols, etc.), and non-functional properties need to be specified. We will call actual value exchanges according to a predefined interaction behaviour and semantics business transaction. Thus, we distinguish between a value proposition published as a service and its actual value exchange by a business transaction. 54 Y.-H. Tan et al. Non-functional properties of IT services supporting value propositions include aspects like availability, reliability and performance. These non functional IT service properties that can be specified by an existing framework influence the metrics of a service. We will focus here on the governance of service systems and architectural aspects of those systems, since much research has already been done on the other two aspects of our Service Innovation Aspects model. We will especially discuss the impact of these changes to government authorities. Governance comprises not only issues like open standards and security, but also services for discovery of value propositions with their related IT services, for example, auditing actors in a service system for applying controls according to agreed governance mechanisms, etc. Open standards and their semantics need to be globally accepted to implement a service system at a global scale. Trade and transport are examples of global service systems that require open standards. Most probably, semantics differs for each actor in such a (global) service system and additional mediation functionality is required. Standards and their semantics have to be available to all actors, either for free or at reduced (administrative) costs. Security is a second aspect of governance. In a setting of a (global) network of organizations, a federated security mechanism must be offered since not all actors will use the same security provider. One must be able to validate the identity of actors in an open environment like the Internet, where each actor can choose its preferred identity provider. A mechanism where these identity providers can be trusted needs to assure that identity of actors can be validated. Service discovery of business and IT services is a third aspect of governance. Although standards have been developed for IT service discovery (e.g. Fensel et al. 2008, Quartel et al. 2007), discovering services is still complicated, because commercial issues are at stake. Careful consideration needs to be given on how to structure service discovery results. There are best practices that show how to offer the results, e.g. the airline booking systems, see (Petzinger 1995). Auditing, a fourth aspect of governance, could be implemented by periodic or behavioural auditing, e.g. behavioural auditing might be supported by monitoring and analysing the actual behaviour of a service system based on, for instance, process monitoring (Aalst et al. 2007). Behavioural auditing adds trust to service systems, since it will immediately detect flaws in the system. Auditing firms could be actors that play an important role in auditing service system. Finally, one of the most important aspects of governance is the fair distribution of co-created value between all actors in a service system. A fair win-win situation must be created, otherwise partners of the service system will drop out, and the service system will not be sustaible. We use e3-control to model processes for sustainability of value co-creation with a fair win-win situation for all actors in a service system. Architectural aspects of service systems are related to concepts such as ‘business process’, ‘business service’, ‘resource allocation’, and ‘transaction protocols’ as the basis for IT services (Lankhorst 2005). With these concepts, we are able to build a model that allows us to distinguish services from a business and IT perspective for value propositions and introduce the concept of business transaction for actual value exchanges. It allows us to align business and IT services. We will elaborate on these concepts in more detail and argue that proper definitions are a A Framework for the Design of Service Systems 55 prerequisite for service systems. As we have stated before, business services are the publication of a value proposition by a service provider. Value propositions can be expressed in different ways that need to be recognized by both customers and a service provider, e.g. a joint goal like the transportation of cargo. Different approaches like Spohrer and Kwam (2009), and Fensel et al. (2008) use different terminology and define these terms loosely, or not at all. For instance, Spohrer and Kwam (2009) mentions business goals, whereas Fensel et al. (2008) introduce the concepts of ‘goal’ and ‘capability’, meaning that a goal denotes a customer requirement and a capability the offering by a service provider. These two concepts, goal and capability, can be applied to both business and IT services. Since a joint business goal is the basis for service discovery or mediation between a goal and a capability (Fensel et al. 2008), these concepts have to be defined unambiguously. Basically, a value proposition not only encompasses a business activity that can be performed by a service provider, but also prices, conditions and IT services with their non-functional requirements for actual value exchange. An example of a business activity is ‘transport’ that is supported by a business process offering a variety of business services like express transport (individual cargo items that have a maximum weight and are transported by air) or container transport. To be able to perform a particular business activity, resources may have to be allocated. A service provider has to allocate resources (Spohrer and Kwam 2009), e.g. a production line for beer production, to produce value for a customer. A customer should only be aware that a service provider is committed to a value exchange for a particular service. Each actor of a service system should implement a coordination mechanism over resources that are under its control. Resource allocation to meet customer requirements is based on negotiation between that customer and a service provider and relates to a value proposition. A negotiation mechanism comprises various aspects of a value proposition, e.g. costs, duration, start and ending time, and places or stages. During negotiation, both actors try to reach an agreement resulting in a contract as a commitment for actual value exchange. Dietz (2006) defines negotiation as a coordination act with an intention and a proposition. Coordination acts are supported by a transaction protocol. A basic protocol consists of ‘request’, ‘promise’, ‘state’ and ‘accept’, needs to be implemented by IT services, and can be decomposed in different phases: information or service discovery phase, negotiation phase which can lead to a contract, delivery phase in which value is actually exchanged based on the result of the negotiation phase, and a cancellation phase required for cancelling a contract and its agreed value exchange. A negotiation may lead to a commitment for value exchange of a service provider based on an existing service, which implies that that provider is actually willing to allocate resources. After a customer has accepted that proposition, resources have to be allocated according to the proposition. Support of a transaction protocol by IT services allows us to transform value propositions directly into IT services. We still have to extend this modelling approach with rules for internal orchestration. McGovern et al. (2006), Hofman (1994) already introduced a set of rules based on the coordination of distributed resources. 56 Y.-H. Tan et al. Fig. 2. Service Innovation Life Cycle 3 Service Innovation Life Cycle Model Service innovation considers reorganizing (parts of) a service system with the objective to obtain business advantages with respect to value exchanges by introducing new services. In fact, service innovation implies a new value proposition (Edvardsson and Olsson 1996). Service innovation can be classified by introducing new services, improving the operation, or increasing growth of services (Curtis and Henderson 2006). Other business improvements like logistics improvement can also be expressed as value co-creation for a service system. Service innovation starts with one particular actor of a service system that wants to introduce a change for improving operations. Existing value exchanges are reconsidered to express business advantages in terms of cost reduction in the service system under consideration (service operation innovation). An innovation life cycle model is required to gradually introduce changes in the total system. The Service Innovation Life Cycle model presented here discusses the introduction of changes in existing service systems with respect to the introduction of new services. The model (Fig. 2) presents a number of phases that have to be taken into consideration for service innovation. The model consists of three phases in which alternative solutions are evaluated before the actual implementation will take place. The phases are: •฀ Service Exploration: Possible scenarios are generated and considered to analyze changes from a business strategy viewpoint. •฀ Service Engineering: One or more options are explored in more detail. Their value is considered in the context of the value exchanges in which an organization operates. Cost/Benefit analyses are made on the basis of the value analysis and changes in processes are explored. Governance A Framework for the Design of Service Systems 57 and control mechanisms are developed to guarantee a fair distribution of benefits in the network, and hence a sustainable network. •฀ Service Management: IT Infrastructure and testing phase. One of the options is developed in more detail and tested in practical situations. Processes and information exchange are defined, tested, and managed (change management, operational management, etc.). Before actually implementing service systems it must be understood – on a high level – what the system will do and how this will impact its individual actors. This is vital since mistakes made in the early phases of service system design can have large (financial) consequences later on (see further Gordijn and Akkermans 2003; Yu 1995). Another consideration is that in the initial phase one wants to abstract as much as possible from implementation details in order to facilitate an open-minded approach and out-of-the box thinking. This latter consideration holds, in particular, for business analysts (and even top-level management) who typically do not have a very technical background. So, the first step is to explore how an actor of a service system will interact with other actors in the same service system from various perspectives (see outer circle alignment model). In particular, the analysis of value exchanges between partners is essential to identify value proposition. Only after the exploration phase is completed, further design (and alignment) should be considered; these additional steps are however outside the scope of this paper. To explore the interaction of a system/organization with its environment four different perspectives are taken into consideration. Considering various perspectives on a system to separate concerns is well-known in traditional requirements engineering (e.g. Nuseibeh et al. 1994). Although each perspective takes a different viewpoint, they all view the same phenomenon, which is in our case the interaction within a service system. We consider the following perspectives to be relevant: •฀ The business perspective that encompasses the business strategy perspective, which considers how other actors influence the strategic position of an actor, and also which collaborations in a network setting might be used to jointly offer a bundled service, and the value creation perspective, which considers how value is created by the service system in which the actors operates •฀ The computational perspective encompassing the process perspective, which considers the cross-organizational coordination processes to support the value creation, and the IT perspective, which considers information systems that interact with their surrounding to exchange information with a variety of technology, e.g. portal technology and web services We must note that stakeholders decide which perspectives are actually explored. Stakeholders can find perspectives irrelevant, simply because they are at that point not (yet) interested in the specific concern explored by a perspective. A consequence of having multiple perspectives on a service system and its interactions is that each perspective should be properly aligned with the others. However, alignment between the perspectives should not only be intra-organizational, which 58 Y.-H. Tan et al. considers alignment decisions between perspectives within a single organization; alignment should also be created between organizations leading to truly co-created value for all partners. This results in two more alignment issues: (1) inter-organizational alignment within a perspective, which considers alignment decisions per single perspective but between multiple organizations (e.g. interoperability between crossorganizational IS), and (2) inter-organizational alignment between perspectives, which considers alignment decisions between perspectives and between multiple organizations (e.g. value co-creation based on alignment of business – and IT services). A naive way to reason about alignment is to use a kind of top-down or “waterfall” approach as known from traditional software engineering methods. Each perspective would then be developed sequentially, and in a top-down way. This is, at least for the exploration phase, not a realistic approach. In the numerous case studies that we conducted (Derzsi and Gordijn 2006), innovative ideas came from the IT service perspective (e.g. new technologies), process perspective (e.g. process optimization) or value co-creation perspective (e.g. joint business opportunities). Also, the service system is continuous and fast moving in terms of enterprises, services, and technologies. So, we consider the alignment process a continuous and iterative “tuning” between the four perspectives within an organization and between organizations. The business strategy and the IT perspective are considered most relevant, since the stakeholders require an IT service design in a service system to improve processes from a business perspective. Value exchange analysis in service systems is a well-known construct for both understanding the business strategy of an actor (see e.g. Porter 1980) and information systems (see e.g. Wieringa 2003). To this end we make both the “business strategy” and “IT” operational in terms of interactions of actors in a service system, resulting in interactions at strategic and IT level. 3.1 Software Support Tools: e3-Value and e3-Control To develop service systems, the tools e3-value and e3-control can model different aspect of those systems. Whereas e3-value can be used to model and analyze value exchanges in service systems, e3-control is used to make the value co-creation in a collaborative environment sustainable by modelling processes in more detail. Process modelling in service systems presents safeguards to sustainable value co-creation for all actors involved. This section discusses both tools, and their applicability is illustrated in the next section by the Beer Living Lab case study. 3.2 Value Co-creation Modelling: e3-Value A first step in service system (re)design is the development of a value model, focusing on value creation (Porter 1980), distribution and consumption. The e3-value methodology and its supporting tools can be used to support design of a value model A Framework for the Design of Service Systems 59 of a service system. The e3-value methodology differs from other business modelling languages, because it focuses not on the modelling of business processes or very highlevel strategic issues, but rather on the modelling of value exchanges between actors in the economic sense (Anderson et al. 2006).1 This modelling of value exchanges is, in particular, useful for analysing value co-creation among business partners of a service system in a network setting. The e3-value methodology (Gordijn and Akkermans 2003) can be used to construct a value model, representing it graphically in a structured way, and performing an economic sensitivity analysis of this model. The e3-value methodology provides modelling concepts for showing which parties exchange resources of economic value with whom, and expect what in return. The methodology has been applied in a series of case studies including media, news, banking and insurance, electricity power, and telecommunication companies to design value models of network organisations (Gordijn and Akkermans 2003). Most of the currently available design methodologies lack a value-based view representing what the value proposition is; rather they focus on business processes representing how a value proposition is implemented. There are a few value chain design methodologies, which provide concepts for describing value constellations in service systems settings, for example the AIAI Enterprise conceptual framework (Uschold et al. 1998) or the Resource Event Agent (REA) (Geerts and McCarthy 1999) conceptual framework. However, these frameworks only focus on the description of the final result, and do not support the value chain design process itself. Other business modelling methodologies (see Pateli and Giaglis 2004 for an overview) offer only generic conceptual frameworks, and do not provide software tools to support the actual modelling in a proper analysis. Tapscott et al. (2000) offer a graphical diagramming approach to represent economic exchanges between enterprises, however, compared to e3-value, it has several drawbacks; e.g. it has no notion of economic reciprocity, economic activity, it does not allow the profitability assessment of individual organisations, and lacks the proper level of formality. Figure 3 shows in the upper part the legend of e3-value constructs used in the example in the lower part. For instance, ‘actor’ is represented by a square and has a name like ‘buyer’. We explain the concepts of the e3-value methodology the simple example, e.g. a buyer obtains goods from a seller, offers money in return, and according to the law, a seller is obliged to pay the value-added tax (VAT). This is conceptualised by the following e3-value constructs: •฀ Actor. An actor is perceived by its environment as an independent economic (and often legal) entity. In a sound, sustainable, business model each actor should be capable of making profit. The example shows a number of actors: a buyer, a seller, and a tax administration. 1 For further info on the tool see www.e3value.com, where also free demo versions of the tool can be downloaded. 60 Y.-H. Tan et al. Fig. 3. e3-Value model of a purchase with tax payment •฀ Value Object. Actors exchange value objects, which are services, products, money, or even consumer experiences. The important point here is that a value object is of value for one or more actors. Good and payment are examples of value objects, but legal compliance to pay tax is also a value object. •฀ Value Port. An actor uses a value port to show a value proposition to its environment. The concept of port enables to abstract away from the internal business processes. •฀ Value Interface. Actors have one or more value interfaces, grouping reciprocal, opposite-directed value ports. A value interface shows the value object an actor is willing to exchange, in return for another value object via its ports. The exchange of value objects is atomic at the level of the value interface. •฀ Value Exchange. A value exchange is used to connect two value ports with each other. It represents one or more potential trades of value objects between value ports. These concepts show bilateral links between customers and service providers, but cannot yet show value chains in which more than two actors are involved. For this purpose dependency paths (based on Buhr 1998) between value interfaces are introduced: a dependency path connects the value interfaces in an actor and represents triggering relations between these interfaces. A dependency path consists of dependency nodes and segments: •฀ Dependency Node. A dependency node is a stimulus (represented by a bullet), a value interface, an AND-fork or AND-join (short line), an OR-fork or OR-join (triangle), or an end node (bull’s eye). A stimulus represents a consumer need; an end node represents a model boundary. A Framework for the Design of Service Systems 61 Fig. 4. Example of a profitability sheet •฀ Dependency Segment. A dependency segment connects dependency nodes and value interfaces. It is represented by a link. •฀ Dependency Path. A dependency path is a set of dependency nodes and segments that leads from a start stimulus (consumer need) to an end stimulus. The meaning of the path is that if values are exchanged via a value interface, then other value interfaces connected by the path also exchange values. Additionally, profitability sheets are used to support cost-benefit analysis for each individual actor (Fig. 4). The advantage of e3-value is that it contains a minimal number of basic constructs, which makes it easy to understand and apply, even for non-technical marketers or business analysts. It is important to understand that an e3-value model only models an ideal situation with a given structure. The Principle of Reciprocity as defined in e3-value is the requirement that if an actor offers something of value to someone else, this actor always gets in return something what s/he wants. Hence, it assumes that all actors behave correctly. The violation of the principle of reciprocity (e.g. an actor receiving something without returning another service for it) can be seen as a violation of an obligation, which would lead to incorrect e3-value models with a value interface with only one incoming or outgoing value object; e.g. delivering goods and not receiving a payment in return. 3.3 Sustainability: e3-Control Even the most profitable business models will not be adopted by a company, if their interests in the business model are not properly safeguarded, and if there are no control mechanisms in place that will guarantee that they will obtain a fair share of the profits or benefits. e3-control provides sustainability of value co-creation by focussing on the design of inter-organizational controls. It is a methodology for control procedure analysis and redesign (Kartseva et al. 2004, 2005, 2006, 2010; Tan and Gordijn 2005; Liu et al. 2006, 2007, 2010) based on the key ideas of (1) structured modelling approach, (2) process-based analysis, and (3) value-based analysis. It has been shown that structured modelling approaches can be used as a means to solve complex inter-organizational problems (e.g., Baida 2006; Franken 62 Y.-H. Tan et al. and Janssen 1998; Gordijn and Akkermans 2003; Janssen et al. 2006). Process-level analysis of control issues follows ideas of other researchers (e.g., Chen and Lee 1992; Weigand and De Moor 2003), building on previous research (e.g., Arens and Loebbecke 1999; Bons et al. 1999; Geerts and McCarthy 1999) and best practices that consider control as a process element (COSO 1992). The main reason for using a process-level analysis is that the large knowledge base on designing controls, which is the basis of e3-control, focuses on analyzing operational tasks, or business processes (Bons et al. 1999; Chen and Lee 1992), and describes control with checking procedures based on the (electronic) exchange of business documents as a process. A broad consensus exists in the literature that the design and analysis of control is about identifying actors, activities and exchanges of business documents, and in particular the interdependencies between these concepts. Control principles are rules prescribing these interdependencies. A well-known control principle is Segregation of Duties, which states that when an activity is checked in an organization, the actor checking the activity should be different from, and socially detached from, the actor that is executing the activity. If this principle is not complied with, then likelihood of fraud in the checking is high. By applying control principles from auditing and accounting literature to process models (e.g. Romney and Steinbart 2003; Starreveld et al. 1994), we are able to identify control flaws, and to propose control mechanisms to handle these flaws. For a detailed description of e3-control’s process level analysis, we refer to Liu et al. (2006, 2007). Finally, e3control uses also a value model analysis to reason about controls (Kartseva et al. 2005), to model the value that can be lost by some actor in a network, if no controls are implemented. The e3-value methodology is used in e3-control to model this value analysis. We refer to the value model as ideal model, meaning that it reflects the situation when all actors fulfil their obligations. The ideal situation can be violated in the sub-ideal situation, which is the case that a value exchange does not hold reciprocally; e.g. in the purchase example the seller commits fraud and does not pay VAT accordingly. The e3-control methodology is visualized in Fig. 5. Value Perspective step 1: preliminary analysis Process Perspective step2:2: step controlproblem problem control identification identification Value Perspective step 3: 3: step control mechanism mechanism control redesign redesign step 4: evaluation Fig. 5. e3-Control: value and process perspectives combined into a redesign method A Framework for the Design of Service Systems 63 The key ideas of e3-control are applied as follows: 1. A value analysis using e3-value is performed to understand the existing business model and to identify which value exchanges between actors in a service system are at risk. 2. Once the weak points in a value model have been identified, a processlevel analysis of these points follows. It facilitates an understanding of how – in the business processes – value can be lost by actors. 3. The next step in process analysis is the development of corrective measures, i.e. new governance and control mechanisms, resulting in revised business processes. 4. Finally, the new business processes and control mechanisms may alter the business model; in particular require new control services and actors that provide these services. Therefore in the final step the value analysis is redone and it is investigated how the suggested changes influence the business model, and it is evaluated whether the new business model is feasible for the actors involved. As Fig. 5 shows, evaluation can be followed by redesign of control mechanisms or even restarting at the preliminary analysis in accordance with the Service Innovation Life Cycle Model discussed earlier. After evaluating one possible solution, alternative solutions may be investigated. Thus, e3-control is a support tool for a specific step in the Service Innovation Life Cycle Model, in particular in service engineering. To perform the analysis in steps 2 and 3 the Unified Modelling Method (UMM) is applied. 3.4 Beer Living Lab The Beer Living Lab, abbreviated to BeerLL, is a living lab case study that was conducted in 2006–2007 as part of the research project ITAIDE.2 Participants in the BeerLL were Heineken NL, a large Dutch beer producer, Heineken UK, an independent company that buys beer from Heineken NL, a UK retailer, the Dutch Tax Administration, IBM as a service provider and the VUAUniversityAmsterdam for project management, analysis, and redesign. In the BeerLL innovative IT was piloted to replace paper-based control procedures by electronic customs procedures to improve security and efficiency of international supply chains in the beer industry. This pilot was conducted with real container shipments of beer to England and the United States.3 2 The ITAIDE project is funded by the 6th Framework IST Programme of the European Commission, for further information see www.itaide.org. 3 Heineken ships on average 40,000 (!) containers to the US, so the potential benefits of simplification of customs procedures are very significant for Heineken. 64 Y.-H. Tan et al. This section explains the current As-Is situation of doing business with paperbased customs procedures, with its potential risks. Subsequently, the proposed To-Be situation is presented based on IT innovations. Finally, we illustrate how our framework was used in the BeerLL to design the new electronic customs procedures. 3.5 Current As-Is Situation The current As-Is situation is as follows. Within the European Union (EU), goods (and people) can move freely from one EU Member State to another. In case these goods are imported from a country outside the EU, import taxes have to be paid in the Member State where these goods are becoming EU goods and can move freely. Similar procedures and excise payments are applicable to exporting goods to countries outside the EU. When goods are produced and sold in the EU, a producer needs to pay excise in the EU Member State where the goods are actually consumed. Hence, if a Dutch beer producer exports beer to a retailer in the UK, that sells the beer to English consumers, the excise has to be paid by the English retailer to the UK Tax office and the producer has to offer proof of excise payment. These goods can already be physically located in that country, without paying excise in a so-called excise warehouse. Excise has to be paid when these goods leave the excise warehouse and are to be consumed. The so-called Administrative Accompanying Document (AAD) is the core document for excise-free export within the EU. The document provides shipment data for customs personnel and is proof that, after the document is signed by a tax office in the country of consumption, excise has been paid. This paper-based control procedure with the AAD is known to be vulnerable for fraud since it requires a paper-based administration by all parties involved. It could operate correctly if one AAD always relates to one container for which excise is paid at once. However, a container may contain a variety of consumer products, potentially with different excise percentages. Furthermore, as the transport between EU Member States increases, the number of AAD’s received increases and Dutch Tax will not have sufficient personnel to validate all AAD’s. 3.6 Proposed To-Be Situation The To-Be situation of the BeerLL describes how the paper-based procedure could be replaced by a completely paperless procedure by introducing two IT innovations, namely smart container seals for real-time monitoring of beer containers and services for sharing information. First of all, we present both IT innovations and, secondly, show how risk reduction is achieved applying these innovations. The smart container seal is a tamper proof seal developed by IBM (TREC device) for container tracking and tracing with GPS, detection of unauthorized opening of a container, and monitoring the physical condition of the container content A Framework for the Design of Service Systems 65 (e.g. temperature and humidity). It can be programmed with business rules; e.g. it can give periodic alerts with respect to its position. The seal’s unique reference number is linked to a Movement Reference Number identifying shipment data from customs perspective. The seals need to be managed by a service provider; they need to have a unique identification number and reverse logistics has to be in place. This service provider needs to be trusted to cater for the security issues of the seals. Introduction of services for sharing information between business partners and customs authorities is the second IT innovation piloted in the BeerLL. Services provide customs authorities access to shipment data stored in a companies’ ERP system, and whenever any governmental agency – whether dealing with export, excise, VAT or any other regulation – wishes to obtain data concerning a shipment, it can retrieve – or “pull” – this data from that system. Services were implemented using (1) standards for product descriptions, such that information from Heineken’s system was interpretable for Dutch Tax, and (2) standards for the implementation of services. Each organization in the BeerLL had its own database which contains a replication of (part of) the data of its internal IT system. Discovery services are required to interactively retrieve data from various databases and present the results to an end-user. Whilst a harmonised data structure is used, the data retrieved from different databases is always presented in the same way. Figure 6 shows Heineken, which replicates its purchase order data to a database (EPCIS), Dutch customs that replicates reports and alert data to their database, which is accessible to UK Customs, and Safmarine, a subsidiary of the Maersk container shipping line. Safmarine replicates the Bill of Lading into their EPCIS. The Bill of Lading contains all relevant shipment data for transport purposes, like container size and type, container number, weights, temperature, and parties Fig. 6. Service-oriented architecture applied in the BeerLL 66 Y.-H. Tan et al. involved in the shipment. Furthermore, data in the EPCIS database of Safmarine is enriched with container tracking and tracing and physical status data gathered and generated by TREC alerts. A device independent portal with integration functionality (the Shipment Information Sharing Services (SISS) developed by IBM) provides an actor specific discovery service for secure data access based on a unique seal number. In this way, customs can for instance access the data stored by Heineken and Safmarine in the EPCIS databases of these two companies. EPCGlobal (see www.epcglobal.org), a subsidiary of GS1 (see www.gs1.org), provided the IT service specifications for communication between the portal and the EPCIS databases and the harmonised data structure of the EPCIS databases. With these two innovations, Dutch and UK Customs have access to all container movements and their excise status, which makes the AAD obsolete. Shipment declarations are no longer required, since all transport movements are transparent to customs authorities. Control procedures are improved, because tracking and status information of containers is always accessible to customs authorities. Customs authorities have to take the initiative for monitoring transportation and assurance of excise payment. This differs from the current procedure, in which Heineken NL has to present, upon request from Dutch Customs, an AAD as evidence of excise payment. 3.7 Analysis of the BeerLL with e3-Control The applicability of our framework and tools is illustrated by a value – and process level analysis of BeerLL (see Beer Living Lab 2007; Baida et al. 2007, 2008) as discussed hereafter. A value-level analysis, yielded the following insights: •฀ Understanding of the BeerLL by analysing value exchanges between actors in the service system. •฀ Exploration of weak points in the business model. •฀ Understanding changes of the existing business model by introduction of the two IT innovations. This chapter only provides a few insights and examples of value models. First of all, we present the value models of the As-Is and To-Be situation and, secondly, we present the process analysis. Figure 7 is one of the value models that we developed in Step 1 of modelling the Beer Living Lab with e3-control. It shows the network of actors that participate in the value chain where Heineken NL sells beer to Heineken UK and consumption of the beer by end consumers. Actors (visualized as rectangles) exchange (visualized as blue lines) objects of economic value (text labels). The value chain starts at the start stimulus of the actor “Consumer UK” and follows the scenario along the value exchanges (blue lines) and dependency paths (dashed lines). The figure shows two sub paths: A Framework for the Design of Service Systems 67 Fig. 7. e3-Control As-Is model of the BeerLL •฀ A value exchange between Heineken UK and a carrier, where Heineken pays a fee in return for transport services. •฀ A value exchange between Heineken UK and Heineken NL: Heineken NL sells beer to Heineken UK. Following this dependency path, we can see that in order to be exempted from excise payment in the Netherlands, Heineken NL has to provide Dutch Customs export (data) evidence about the excise free shipments. In case the beer is transported from an excise warehouse to the supermarket, two sub paths represented by an OR gate are feasible: •฀ The UK-based retailer in its role of Excise Warehouse pays excise to the UK authorities. •฀ The UK-based retailer defaults and does not pay excise duties for the beer that it sold to the UK-based supermarkets. This sub path represents a fraud case. Whilst these sub paths are modeled by an OR gate, only one of the sub paths will be executed. A sub-ideal situation exists, which cannot be modeled by e3-value. The e3-control modelling tool allows modelling sub-ideal situations to identify possible problems with respect to control. This is indicated by the value exchange with dotted lines; i.e. “No Legal Compliance” and “No Payment Excise”. Modelling of 68 Y.-H. Tan et al. sub-ideal value exchanges is an extension in e3-control to e3-value to enable modelling of control flows. The second part of e3-control is modelling the To-Be situation (step 4 of e3control, Fig. 8). The major difference between this and the previous value model is the introduction of a new actor – TREC service provider – to cope with the control problems we have mentioned. As we have described before, a TREC service provider supports the logistics of the seals and, in the BeerLL, hosts the portal and the EPCIS databases. This will give the following opportunities: 1. Since TREC can monitor the state of a container and the TREC service provider provides sufficient monitoring and control to Dutch Customs, Dutch Customs has proof of excise payment in the UK. 2. TREC service provider offers and extra control by submitting information (automatically generated by TREC) to both Dutch Customs and UK Customs that can be used to match excise payment. 3. Heineken NL is able to provide all relevant accountability data to qualify as an AEO (Authorised Economic Operator), which leads to considerable benefits and cost reductions to Heineken. 4. TREC service provider is able to improve the supply chain management of the beer transport for the carrier, which has immediate benefits and cost reductions also for Heineken NL and Heineken UK. By comparing the To-Be model with the As-Is of step 1, the value of performing step 4 becomes visible. First, we identify changes in actors and in linkages between actors. Secondly, the To-Be model also supports a profitability (cash flow) and business analysis: (1) reduction of administrative burden of all private parties and (2) fraud reduction for customs authorities. The total profitability depends on the business model of the new services required by the introduction of both IT innovations and their adoption by all stakeholders. The seal service provisioning is a typical example of a networked service offering. Various services have to be bundled, which refers to the governance aspects of our Service Innovation Aspects Model. First, there should be a seal provision service offered by an actor, including seals logistics. Secondly, there should be a mechanism to process and store seal data linked to a container number and a Movement Reference Number. Third, the services have to be implemented and published by companies and a service discovery portal is required according to agreed standards and semantics. This requires services of a standardization body, like GS1 and EPCglobal. Finally, there should be federated security service providers, because the distribution and use of digital certificates has to be at a global scale and there exists no globally acting Certification Authority (CA). Most governments issue their own digital certificates and act as a CA. Hence, federation is needed to provide global coverage. An additional complexity of this network formation is that for each of these services the investment profile is quite different. For example, consider millions of container movements with relative less investment for TREC devices compared with investments for developing a CA 69 Fig. 8. e3-Value To-Be model of BeerLL A Framework for the Design of Service Systems 70 Y.-H. Tan et al. Fig. 9. Step 2 of e3-control: process model of the BeerLL As-Is situation federation to provide global security coverage and operating the complete service system. The value modelling and underlying profitability analysis was used extensively to make a detailed scenario-based analysis of the profitability for each of these services, and to determine which actor was most likely to provide these services. One of the solutions is that container owners provide the seal services as built-in functionality of their containers. The value analysis for a seal service showed that these services are primarily profitable for the transport of high-value goods (mobile phones, electronic components etc.). For commercial reasons we are unable to provide more details about these more detailed value models for seal services. Steps 2 and 3 of e3-control consist of a process-level analysis focussing on the business processes that realize the As-Is and To-Be business models. A process analysis is required for value co-creation sustainability by all actors involved. Figure 9 shows the highest level As-Is process model that was constructed in Step 2 of the BeerLL. It illustrates the basic principles of the paper-based AAD approach and is refined in various steps to, for example, use case diagrams and activity models that include swim lanes for each actor, using the Unified Modelling Language (UML). Process analysis specifies how processes are affected by the introduction of the a container seal and the TREC service provider. Detailed models can be found in (Beer Living Lab 2007). Process analysis yielded the following insights (Fig. 10): •฀ Based on a combination of IT innovations such as the TREC smart container seal and services, paper-based administrations become obsolete. A Framework for the Design of Service Systems 71 Fig. 10. Step 3 of e3-control: process model of the To-Be situation •฀ Current EU procedure for export and intra-community supplies of excise goods based on a paper document does not comply with control principles and is therefore vulnerable to fraud and misuse. •฀ The BeerLL concept complies with audit and control principles and solves the control risks that we identified for the paper-based customs procedure. Figure 10 shows the To-Be process of Step 3 of the BeerLL redesign, where all the evidence of movements of beer containers is stored in EPCIS databases that are accessible to Dutch and UK customs authorities. The database contains all relevant data for customs purposes, which is also present at the AAD document. In particular, a TREC can be programmed to send a signal when it crosses the Dutch border, which is an automated export evidence for Dutch Customs. The data stored in the EPCIS database of Heineken NL replaces the role of the To-Be-verified paper export declaration. 4 Conclusions In this paper we have discussed two models, the Service Aspects model and the Service Innovation Life Cycle Model, and two conceptual modelling tools, e3-value and e3-control to support the re-design of Business-to-Business and Business-toGovernment services. To validate the adequacy and usefulness of the models and tools, we have conducted an extensive case study, the BeerLL, of the redesign of 72 Y.-H. Tan et al. value chains in international trade with the introduction of two IT innovations (smart seals and services). The BeerLL case study provides a clear example of what we called the second dimension of value propositions in service systems, namely that services are typically offered by collaborative service system of service providers. First of all, it is clear that no single actor is able to provide seal services, so it is a truly networked service offering. Secondly, to design the seal service, it appears to be essential to find a service system setting that is not only profitable as a whole, but profitable for every partner participating in the service system. The most complicated part of a seal service is to determine the value co-creation among the actors in the service system. In particular, to determine for each actor (1) the profitability of the value model of his own service contribution, and (2) to design controls that guarantee for each actor the fair distribution of profitability of the total service system to each of the actors in that system. In both steps the tools e3-value and e3-control are proving to be useful for analysis and design. Regarding the research question, we can now say that applying these tools in practice enabled us to model weaknesses in control procedures and to redesign these procedures by introduction of extra controls based on new technology that is provided as a networked service offering provided by a service system. In other words, the tools have been adequate for the redesign task and have provided useful insights. We expect the research to have the following implications. Regarding theory, the combination of value-based modelling (e3-value and e3-control) and service oriented models (Service Aspects model and the Service Innovation Life Cycle Model) has proved beneficial. It provides another step towards reconciling these mutually beneficial modelling perspectives for service design. Regarding practice, we expect that these insights will help practitioners to better understand the impact of regulation change on service redesign. In future research, we will further investigate the separation of the design phase and operational phase in the life-cycle of service systems, and further define the underlying concepts of this contribution. Acknowledgments This research was partially supported by the integrated project ITAIDE (Nr.027829), which is funded by the 6th Framework IST Programme of the European Commission (see www.itaide.org). References Anderson, J.C., Narus, J., Narus, A., and van Rossum, W. (2006). Customer value propositions in business markets. Harvard Business Review, 84(3), pp. 90–99. Arens, A. and Loebbecke, J. (1999). Auditing, an Integrated Approach, 8th edition, Prentice Hall, Englewood Cliffs. Baida, Z. (2006). Software-aided Service Bundling – Intelligent Methods and Tools for Graphical Service Modeling, Ph.D. thesis, Vrije Universiteit Amsterdam, The Netherlands. Baida, Z., Rukanova, B.D., Wigand, R.T., and Tan, Y.H. (2007). Partnership: The story of how Heineken’s supply chain benefits from tight collaboration with government. Supply Chain Management Review, 11(7), pp. 11–12. A Framework for the Design of Service Systems 73 Baida, Z., Rukanova, B., Liu, J., and Tan, Y.H. (2008). Preserving control in trade procedure redesign – The Beer living lab, electronic markets. The International Journal, 18(1), 53–64. Beer Living Lab (2007). Beer Living Lab, Final Report, D5.1:5, ITAIDE. Bons, R.W.H., Lee, R.M., and Wagenaar, R.W. (1999). Computer-aided auditing and interorganizational trade procedures. International Journal of Intelligent Systems in Accounting, Finance and Management, 8(1), pp. 25–44. Buhr, R.J.A. (1998). Use case maps as architectural entities for complex systems. IEEE Transactions on Software Engineering, 24(12), pp. 1131–1155. Chen, K.-T. and Lee, R. M. (1992). Schematic evaluation of internal accounting control systems EURIDIS Research Monograph, Erasmus University Rotterdam. COSO (1992). Internal Control-Integrated Framework. The Committee of Sponsoring Organizations of the Treadway Commission, New York. Curtis, K. and Henderson, A. (2006). Hiding in plain sight: service innovation – a new priority for chief executives. IBM Institute for business value. Somers, New York. Derzsi, Z. and Gordijn, J. (2006). A framework for business/it alignment in networked value constellations. In T. Latour and M. Petit, editors, Proceedings of the Workshops of the 18th International Conference on Advanced Information Systems Engineering (CAiSE 2006) Namur University Press, Namur, B, pp. 219–226. Dietz, J.L.G. (2006). Enterprise Ontology – Theory and Methodology, Springer, Berlin. Edvardsson, B. and Olsson, J. (1996). Key concepts for new service development. The Service Industries Journal, 16(2), pp. 140–164. Fensel, D., Kerrigan, M., and Zaremba, M. (eds.) (2008). Implementing Semantic Web Services – The SESA framework, Springer, Heidelberg. Franken, H. and Janssen, W. (1998). Get a grip on changing business processes: Results from the Testbed project. Knowledge and Process Management, 5(4), pp. 208–215. Geerts, G. and McCarthy, W.E. (1999). An Accounting Object Infrastructure for KnowledgeBased Enterprise Models. IEEE Intelligent Systems and Their Applications, 14(4), pp. 89–94. Gordijn, J. and Akkermans, H. (2003). Value based requirements engineering: Exploring innovative e-commerce idea. Requirements Engineering Journal, 8(2), pp. 114–134. Heineke, J. and Davis, M. (2007). The emergence of service operations management as an academic discipline. Journal of Operations Management, 25, pp. 364–374. Hofman, W.J. (1994). A conceptual model of a Business Transaction Management System, Ph.D. thesis, Uitgeverij Tutein Nolthenius, The Netherlands. Janssen, M., Gortmaker, J., and Wagenaar, R.W. (2006). Web service orchestration in public administration: Challenges, roles and growth stages. Information Systems Management, 23(2), pp. 44–55. Kartseva, V., Gordijn, J., and Tan, Y.-H. (2004). Value-based business modelling for network organizations: Lessons learned from the electricity sector. Proceedings of the 12th European Conference on Information Systems (ECIS’04), Turku. Kartseva, V., Gordijn, J., and Tan, Y.-H. (2005). Towards a modelling tool for designing control mechanisms for network organisations. International Journal of Electronic Commerce, 10(2), pp. 57–84. Kartseva, V., Gordijn, J., and Tan, Y.-H. (2006). Inter-organisational controls as value objects in network organisations. Proceedings of the 18th Conference of Advanced Information Systems Engineering (CAiSE06), Springer Verlag, Berlin pp. 336–350. Kartseva, V., Hulstijn, J., Gordijn, J., and Tan, Y.-H. (2010). Control patterns in a healthcare network. European Journal of Information Systems, 19, 320–343. Lankhorst, M. (2005). Enterprise Architecture at work, Springer, Heidelberg. Liu, J., Baida, Z., Tan, Y.-H., and Rukanova, B. (2006). Designing controls for e-government in network organizations. Proceedings of the 13th Research Symposium on Emerging Electronic Markets, September 23–25, Stuttgart, Germany, pp. 22–36. 74 Y.-H. Tan et al. Liu, J., Baida, Z., and Tan, Y.-H. (2007). e-Customs Control Procedures Redesign Methodology: Model-Based Application. Proceedings of the 15th European Conference of Information Systems (ECIS 2007), St. Gallen, Switzerland. Liu, J., Higgins, A., and Tan, Y.-H. (2010). IT enabled redesign of export procedure for high value pharmaceutical product under temperature control: the case of drug living lab. Proceedings of the 11th Annual International Conference on Digital Government Research (DG.O 2010), ACM International Conference Proceeding Series. McGovern, J., Sims, O., Jain, A., and Little, M. (2006). Enterprise Service Oriented Architectures – Concepts, Challenges, Recommendations, Springer, Dordrecht. Nuseibeh, B., Kramer, J., and Finkelstein, A. (1994). A framework for expressing relationships between multiple views in requirements specification. IEEE Transactions on Software Engineering, 20(10), pp. 760–773. Pateli, A.G. and Giaglis, G.M. (2004). A research framework for analysing business models. European Journal of Information Systems, 13(4), pp. 302–304. Petzinger, T. Jr. (1995). Hard Landing: The Epic Contest for Power and Profits That Plunged the Airlines into Chaos, Times Books, New York. Porter, M.E. (1980). Competitive Advantage. Creating and Sustaining Superior Performance, The Free Press, New York. Quartel, D.A.C., Steen, M.W.A., Pokraev S., and Sinderen M.J. van (2007). COSMO: A conceptual framework for service modelling and refinement. Information Systems Frontiers, 9(2–3), pp. 225–244. Romney, M.B. and Steinbart, P.J. (2003). Accounting Information Systems, 9th edition, Prentice Hall, New Jersey. Spohrer, J. and Kwam, S.K. (2009). Service Science, Management, Engineering and Design (SSMED) – An emerging discipline – Outline and references. International Journal on Information Systems in the Service Sector, 1(3). Starreveld, R.W., de Mare, B., and Joels, E. (1994). Bestuurlijke Informatieverzorging, Deel 1, 4th edition, Samsom, Alphen aan den Rijn (in Dutch). Tan, Y.H. and Gordijn, J. (2005). A design methodology for modeling trustworthy value webs. International Journal of Electronic Commerce, 9(3), pp. 31–48. Tapscott, D., Ticoll, D., and Lowy, A. (2000). Digital Capital – Harnessing the Power of Business Webs, Nicholas Brealy Publishing, London. Uschold, M., King, M., Moralee, S., and Zorgios, Y. (1998). The enterprise ontology. The Knowledge Engineering Review, 13(1), pp. 31–89. van der Aalst, W.M.P., Reijers, H.A., Weijters, A.J.M.M., van Dongen, B.F., Alves de Medeiros, A.K., Song, M., and Verbeek, H.M.W. (2007). Business process mining: An industrial application. Information Systems, 32(5), pp. 713–732. Weigand, H. and De Moor, A. (2003). Workflow analysis with communication norms. Data & Knowledge Engineering, 47, pp. 349–369. Wieringa, R.J. (2003). Design Methods for Reactive Systems, Morgan Kaufman, San Fransisco. Yu, E. (1995). Models for supporting the redesign of organizational work. In COCS ’95: Proceedings of Conference on Organizational Computing Systems, ACM Press.