Implementation during design : Developing understanding about service realisation before implementation

Abstract Design has been mentioned as potential support in the shift from a value-in-exchange to a value-in-use perspective that is part of servitization. However, these discussions pay little attention to the role of design(ers) for implementing 1) the change in perspective of the organisation and 2) specific (product) service systems, which are both required for successful servitization. We argue that implementation as a concept needs to be part of service design processes in order to timely articulate how to implement new services, and what resources need to be shaped in service system(s) involved for successful value co-creation. We analyse a workshop in a technology-dominant service development project and show that using a service (process) perspective and concrete cases could be a way to integrate conversations about implementation in the design phase of PSS and service development. For technology-dominant services specifically, this can uncover factors for successful integration of technology and service.


Introduction
Servitization of a company's offering requires a transition from product to service focus (Vandermerwe & Rada, 1988;Baines, Lightfoot, & Kay, 2009), which means a transition from a value-in-exchange perspective to a value-in-use perspective (Vargo & Lusch, 2008;Grönroos & Gummerus, 2014). The role that design can play in such a transition in technology-dominant development and organisations has been discussed both in general (e.g. Verganti, 2009) and for a service context specifically (Candi, 2007;Sangiorgi et al., 2012;Calabretta et al., 2016). However, the focus in these works is on the design phase of service development projects. When it comes to the contribution of design with regard to implementing services as part of the transition to a service orientation, the complexity of this issue is discussed (e.g. Lin, et al., 2011, Calabretta et al., 2016Overkamp and Holmlid, 2016) but there is still much room for research (Teso and Walters, 2016).
In this paper, we contribute to this discussion by introducing the concept of implementation during design and presenting ways to start conversations about realisation of service as value-in-use (Grönroos & Gummerus, 2014) already during both the design and definition of service and productservice systems development projects.
More specifically, we analyse conversations during a workshop that was part of a technologydominant B2B service development project, which is aimed at improving troubleshooting on trucks and buses. We look specifically at what understanding about service realisation is developed in the conversations.
The paper is set up as follows: first we give a brief background to servitization and product-service systems (PSS) as a part of that transition. We present benefits and barriers of servitization, what design can contribute in this transition and how implementation could be part of the design of product-service systems. Then we present the setup of the workshop that was organised and analyse the results in terms of conversation topics during the workshop and how these are relevant for successful service implementation. Based on this we suggest how implementation as a concept can be(come) part of service design processes and what role designers could have in this.
Servitization thus involves a shift from a value-in-exchange perspective to a value-in-use perspective, where a consumer does not necessarily own the product(s) in the service (Baines et al., 2007). In other words: consumers do not necessarily own the operand resources in the service (Vargo & Lusch, 2008). Becoming what Oliva & Kallenberg (2003) call a "pure service organisation" entails shifting focus from transaction-based services to relationship-based services on the one hand and from professional to operational services on the other hand. The mind-set of a company has to change from increasing market share to developing strong relationships with the most profitable customers (Wise & Baumgartner, 1999). This requires not just a change in offering, but also a change in the focus of the organisation (Brax, 2005, p.152), which entails changes in the company's processes and capabilities (Baines et al., 2009;Huikkola, Kohtamäki, & Rabetino, 2016).
Such a change in mind-set is considered beneficial for the organisation from a financial, strategic and marketing perspective (Vandermerwe & Rada, 1988;Vandermerwe, 2000;Oliva & Kallenberg, 2003;Brax, 2005;Baines et al., 2009). However, there are also challenges and barriers for servitization (Mathieu, 2001) and the level of success that companies can achieve with (a transition towards) offering product-service combinations also depends on the characteristics of the products that these companies produce and the context of use for those products (Jovanovic, Engwall, & Jerbrant, 2016). Furthermore, the required mind-set change can be difficult, both for provider and customer (Baines et al., 2007;Beuren et al., 2013;Mont, 2004). Companies can have difficulties seeing services as a source of income rather than a cost (Gebauer, Fleisch, & Friedli, 2005) or lack the knowledge or human resources to develop and implement services successfully while maintaining a constant level of service quality (Annarelli, Battistella, & Nonino, 2016;Gebauer, Fleisch, & Friedli, 2005). Customers can be reluctant to give up ownership, especially if it has symbolic status (e.g. with cars) (Mylan, 2015).
Still, implementation of product-service systems is proven to be difficult (Jovanovic et al., 2016) and is increasingly being mentioned as a topic for future research (Annarelli et al., 2016). It is acknowledged that "better understanding of issues concerning implementation and monitoring of PSS, definition of the roles and capabilities of the stakeholders involved" are amongst the challenges that PSS development faces (Vasantha, Roy, Lelah, & Brissaud, 2012). Yet, companies often focus their efforts on designing product-service systems, rather than working towards implementing them. (Kindström & Kowalkowski, 2009). Ideally implementation is a topic on the agenda before the project arrives at the delivery and sales stages (ibid.). In other words, during design time or development time of a service, rather than during implementation time or performance time of the service (Holmlid, 2012). Developing this knowledge well in advance can for instance allow managers to anticipate the need for additional staff, which reduces risks of service quality erosion and helps prevent sunk cost fallacies (Gebauer, Fleisch, & Friedli, 2005). Concrete suggestions regarding how to facilitate conversations regarding implementation during design are, however, mostly missing, Halse et al. (2010) being one of the exceptions. Therefore, we investigate how the concept of implementation can be introduced during the design of services and what role design(ers) could have in this.

Method
We are involved in a technology-dominant service development project that is aimed at improving the process of troubleshooting and repairing heavy vehicles (trucks and busses), using a combination of advanced algorithms and the introduction of new steps to the process of troubleshooting. Both the existing and the new service are product-service systems. The existing service of troubleshooting and repairing can be seen as product-oriented service (Mathieu, 2001;Tukker, 2004). Elements of the new service include the possibility to monitor the condition of the vehicle and an extension of the existing call centre role of the organisation's helpdesk (focussed on connecting driver and workshop), to include remote troubleshooting in the future version of this helpdesk role. Both are elements of an intermediate service (Huxtable & Schaefer, 2016).
We conducted a workshop in this development project. During the workshop, five members of the development team participated (the project leader, three engineers and one computer scientist), who are responsible for the development of different parts of the technology required in the service. The workshop was facilitated by one of the authors. The workshop took four hours and the workshop programme and times for each part are detailed in Table 1.
The workshop was video recorded and this recording was transcribed verbatim. The author who facilitated the workshop went through the transcript once and inductively coded it (Bernard, 2006), in an approach based on Grounded Theory (Strauss & Corbin, 1998): the codes were iteratively made and grouped, and the emerging categories tested on the remainder of the data, to end up with a small number of themes in the end (Creswell, 2014). Then, the authors held an analysis meeting where they went through the transcript and discussed their findings. Finally, a compilation was made of the initial and shared insights from the data. The focus of this paper is on the conversations that took place in the group during assignments 2 and 3. Since assignment 1 formed the warm-up for assignments 2 and 3, we briefly discuss its setup and contents here. During assignment 1, participants were given an A3-size paper on which two steps in the process were pre-printed (see Figure 1): problem with a truck (left) and problem solved (right). Each participant was asked to draw what they thought the future process of troubleshooting and repair would look like if the technology is successfully developed and deployed. The aim with this assignment was to let each participant individually think about what the service process should look like according to them. This allowed them to form their own opinion, before the conversation in the group in assignment 2.
At the end of the assignment, each participant presented his/her individual view on the service process, to let all participants get an idea of each other's views on the process. Assignment 2 -Mapping of the collective process view During this assignment, the individual views were combined into one collective, generic process view for the service process, which was developed on a whiteboard. For this process view, the workshop leader used a template where the process was divided into four rows (see also Figure 2), lightly based on Grönroos' (2008) definition of service: • Actions: what happens in a specific step in the process?
• Goals: what is the aim of the step?
• Actors: who/what is involved in each step?
• Resources: what is needed in each step, in terms of tools, information, etc.?
The participants were first asked to look for similarities amongst their individual process views from assignment 1 and then mention steps to fill possible gaps that remained in the process. The collective view was built up layer by layer: the layer actions was completed before moving on to goals, etc. These layers were not pre-printed, to be able to deal with them one at the time, to prevent that people would directly go into details for one step and to allow flexibility for the workshop facilitator in terms of what layers to focus on. The beginning and endpoint we printed and glued on post-it notes. The author who facilitated workshop facilitated the dialogue, but had a passive role in the creation of the content of the process view. Assignment 3 -Testing the collective view In this assignment, the collective, generic view was assessed using scenario cards. The scenario cards contained information about an aspect of the context in which a problem with a vehicle occurred (see Figure 3). These contexts were described from the perspective of one of the actors involved (e.g. driver, owner, mechanic, etc.). During the assignment, the group members discussed what the specific instance of the generic service process from assignment 2 would look like, given the particular situation described on the scenario card. The situation descriptions on the cards were based on observational and interview data collected by of one of the authors during a one-week contextual study at a garage for trucks and buses.

Resources
For this assignment, the participants were divided into two groups, where people working together on a specific aspect of the technology were distributed over the two groups, to create a spread in the views and perspectives during the dialogues in the two groups. Both groups drew their scenario cards randomly from one stack of 17 cards. The instructions were given verbally and handed out in print, as reference for the groups.

Results
Here, we present what was discussed during assignments 2 and 3. We focus on the dialogues regarding value (co-)creation and roles of the service actors.

Assignment 2
The second assignment led to the formation of a collective, generic view of the service process, based on the individual views from assignment 1 (see Figure 4).

Figure 4. Result of assignment 2, where the individual views are combined into one collective view, starting from when there is a problem with a truck (left-hand side) and ending when the problem is resolved (right-hand side) The process view on the whiteboard contains information from the dialogue regarding what actions should be taken in the service process, by which actors and what information is needed in those actions.
On a general level, the development of the collective view of the service process meant that participants made aspects of the service more concrete, which lead to questions and the discovery of knowledge gaps: More specifically, the participants mostly talked about: value creation and co-creation, roles of the service actors, relations between the existing and the new service, and context of the service process. Due to space limitations, we focus on first two topics, below.
The participants talked both about value co-creation through direct interaction between actors and value creation through indirect interactions (Grönroos & Ravald, 2011). Value co-creation was, for instance, discussed by participant #2: Situations where an actor uses information provided by the software as a resource for value creation were also discussed: Participant #3: it is some person there with some skill, taking the information and making something useful of it.
Participant #2: the backoffice support or the algorithmic explanations that you can assist this person with.
Furthermore, participants talked about the specific interactions that would take place in a touchpoint and what the outcomes of those interactions should be: Participant #4: as I see it, when the truck comes to the workshop, everything is prepared with spare parts and tools and… set up and everything and then they just fix it and send it When defining value (co-)creation and interactions in touchpoints, participants also discussed who would interact with whom and how. They talked about (their view of) actors in the service today: Participant #2: that's the person or the call centre the driver contact when they get a problem and they hook up the driver with the appropriate workshop.
Participant #2: they might have at the workshop some person that has the role of preparing the jobs.
The participants also defined actor roles for the future service: Participants also defined the responsibility, decision making, and tasks of the actors:

Participant #3:
Probably it's the mechanic, together with the driver that decides "okay, now it is okay, this truck." Participant #1: that when you schedule a time and when you have a handover to the workshop then who is going to take care? So, it's kind of a decision of who is going to solve this problem.

Assignment 3
Just as during the development of the generic process view, participants voiced questions and uncertainties regarding the dynamics between different actors and what would be ideal from the perspective of a certain actor: Participant #2: how does the system learn that we have frozen goods? (…) We need to ask that, I guess. And of course, being able to input and…do something useful with it. Participant #5: But the driver must tell [the future] helpdesk that.

Participant #3:
When I thought about this, I didn't think the system had this information. That was the [future] helpdesk who knew this.
Besides this, the conversations focused on the concerns of actors: Participant #2: So, driver is stressed, I guess. Or concerned, at least.

Participant #4:
Shortly the card says that it's a demanding customer that wants to know every next step: what the cost will be and what to do.
Related to this, participants discussed how the technology could (be made to) support value creation of different actors: Participants #2: you have this information that you have a work plan and that you have all the deadlines, in order to get the troubleshooting tool useful in making the recommendations. In some way, [the troubleshooting tool] needs to consider these circumstances.
Participant #3: it might be possible to design the system like that, that the system doesn't have [contextual information], but then it needs to be able to give sufficient decision support so that the user that has this additional information can still make a decision.

Discussion
Based on existing literature, we identified a need to make implementation as a concept part of service design, in order to timely articulate how to implement a new service, and what (and how) resources need to be shaped in the service systems involved, for successful value (co-)creation. The dialogues during the workshop include aspects that are relevant for successful realisation of the service.
Firstly, roles and responsibilities of the different actors (including non-human actors) were defined, including whether these actors co-create value in direct interactions or create value for themselves through indirect interactions (Grönroos & Ravald, 2011). This points to what resources need to be shaped in which service system to make this value co-creation and value creation possible.
Secondly, the participants discussed how the technology should be integrated in the service, in order to successfully realise the technology's role in value (co-)creation. This provided insights and questions that are relevant for further development of the technology and defining which functions should be included in the software. For technology-dominant service development processes in particular, such conversations are valuable for further technology development and deployment.
Thirdly, the service perspective taken in the workshop made it possible to discuss functions on service level, rather than a technology level alone. This meant that it could be discussed whether a certain function of the service should be achieved through deployment of the technology or realised by a human actor. For instance: To be able to give good advice on a course of action, should knowledge regarding the context (e.g. truck has frozen cargo) be entered into and considered by the software or should this information remain with a human actor (e.g. the helpdesk personnel). Thereafter, it is possible to discuss what resources thus need to be shaped in which service system, to make them available for either value co-creation or value creation.
A common denominator in these dialogues is that they surfaced when making elements of the service process concrete, which participants were asked to do in the workshop. During this process, the participants made assumptions and raised questions about elements of the service -today and in the future -that the participants themselves did not know enough about. Towards implementation, such assumptions need to be checked and the knowledge gaps need to be filled. If an incomplete image of current service systems remains in place throughout the service development process, this poses the risk of wrongly defining which resources need to be shaped in today's service systems (and how), in order to prepare these systems for (their role in) value (co-)creation in the future.
A role for designers in implementation during design could be to collect these assumptions and test them, as well as gathering unanswered questions, finding out who can answer them and involving these actors in the service development and implementation.
The combination of the generic service process perspective and the specific cases on the scenario cards also made it possible to discuss the variety that could take place in the service. Yet, not all elements of a service were caught during the workshop. In part, the participants were aware of this: Several actors in the service were not mentioned in the dialogues (e.g. customer of the transport company). It is not clear whether the participants were aware of this.

Conclusion
Servitization and the transition towards offering product-service systems is potentially beneficial for production-based companies. However, there are barriers for this shift to take place. Furthermore, to increase the odds of achieving successful value (co-)creation in product-service systems and services, their realisation should be a topic of discussion before they are being implemented.
Therefore, we argue that in order to timely articulate how to implement service systems, and what resources need to be shaped in the service systems involved, implementation as a concept needs to be part of service design processes.
In this paper, we investigated how conversations regarding realisation of a service could become part of the development process for these services. We have shown how making a generic representation of a future service process and assessing this with specific scenarios, can provide support for articulating value (co-)creation process, actor roles and responsibilities, as well as point out questions and knowledge gaps that need to be considered for successful service realisation. This research thus contributes to addressing the challenges in PSS and service development that are related to implementation in general as well as the definition of service (actor) roles and capabilities specifically.
Since service implementation has not been researched extensively in service design research, there are ample interesting topics for future research: How can an implementation focus be introduced early stages of a service development project? What understanding of future value co-creation situations can be developed in such early stages of service development and how could this knowledge be used towards service implementation? How do service designers already work with implementation during early stages of service development and what are additional ways in which they can do so?
For technology-dominant services and product-service systems in particular, we have shown that mapping the service process can also uncover aspects that are relevant for successful integration of the technology in the service process. Discussing technology development from a service perspective also opens up for a dialogue regarding where certain service functions should lie; in the technology or with another service actor.