An International Journal for All Aspects of Design
ISSN: 1460-6925 (Print) 1756-3062 (Online) Journal homepage: http://www.tandfonline.com/loi/rfdj20
Implementation during design Developing
understanding about service realisation before
implementation
Tim Overkamp & Stefan Holmlid
To cite this article: Tim Overkamp & Stefan Holmlid (2017) Implementation during design Developing understanding about service realisation before implementation, The Design Journal, 20:sup1, S4409-S4421, DOI: 10.1080/14606925.2017.1352937
To link to this article: http://dx.doi.org/10.1080/14606925.2017.1352937
© 2017 The Author(s). Published by Informa UK Limited, trading as Taylor & Francis Group
Published online: 06 Sep 2017.
Submit your article to this journal
Article views: 12
View related articles
12th EAD Conference Sapienza University of Rome 12-14 April 2017 doi: 10.1080/14606925.2017.1352937
Implementation during design Developing
understanding about service realisation
before implementation
Tim Overkamp
a*, Stefan Holmlid
aaDepartment of Computer and Information Science, Linköping University, Linköping, Sweden
*Corresponding author e-mail: tim.overkamp@liu.se
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.
Keywords: service implementation, service perspective, servitization,
technology-dominant service development, product-service systems
1. 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., 2016; Overkamp 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 product-service systems development projects.
More specifically, we analyse conversations during a workshop that was part of a technology-dominant 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.
2. Background
The move towards servitization (Vandermerwe & Rada, 1988) includes offering various types of combinations of products and services, or product-service systems (PSS) (Goedkoop et al. 1999). These can be product-oriented (e.g. maintenance, warranty), use-oriented (e.g. rental, lease) or result-oriented (e.g. clean clothes instead of a washing machine) (Mathieu, 2001; Tukker, 2004; Baines et al., 2007; Bertoni et al., 2016).
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).
Besides PSS, service design has been mentioned as helpful in the servitization transition (Costa, Patrício, & Morelli, 2016; Wetter-Edman et al., 2014). Previous work has shown how service
designers can complement other design disciplines in PSS development (Holmlid, 2010) and how that helps service design(ers) (to get started) with servitization (e.g. Morelli, 2006; 2009; Sangiorgi et al., 2012). However, there has been limited discussion so far regarding benefits that service design can have towards realisation of servitization (e.g. Calabretta et al., 2016) and somewhat more developed discussions regarding implementation of (singular) services (Christiansen, 2015; Holmlid, Wetter-Edman, & Edvardsson, 2017; Lin, et al., 2011; Lønvik, Pettersen, & Verhulst, 2016; Yu, 2015; 2016). 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.
3. 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.
Table 1. Workshop setup
Introduction 10 min
Warm-up exercise 15 min
Assignment 1: Individual process view 15 min
Presentation of assignment #1 30 min
Assignment 2: Collective process view 105 min
Break 10 min
Assignment 3: Asses process view with scenarios 20 min
Presentation of outcomes assignment #3 15 min
Presentation with examples of value-creation based on technology 10 min Ideas for value creation using technology developed in project 10 min
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.
Figure 1. Template for assignment 1, where individual participants were asked to document what they think the service process will look like in the future, when the project in question is completed.
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.
Figure 2. Layers used for building the collective view on the service on a whiteboard. The collective view was built up layer by layer: first all the actions were noted down, the then goals, then the actors, etc.
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.
Actions
Goals
Actors
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.
Figure 3. Some examples of the text on the scenario cards that the participants could receive. Each text describes contextual information from the perspective of a specific actor in the process.
4. 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:
Participant #4: Yes. But I don’t know if we have that already. Do you know
[Participant#3]? Does the workshop calculate what to order?
Participant #2: But [the future h]elpdesk gives a recommendation of which
workshop to contact. Which role will aid the driver/manager on which workshop to contact?
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:
Participant #2: So, the [future] helpdesk, together maybe with manager, might
select [a] workshop first. And then contact it.
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:
Participant #1: So now we’re are talking about two different roles for the future
helpdesk. And one is actually assessing what the problem is and the other one is old goal [of booking the appointments]
This includes definition of the role of both human and non-human (e.g. software) actors in the service:
Participant #3: [T]he automatic monitoring or vehicle sends context information to
the back office.
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.
5. 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:
Participant #3: Because I think there are a lot of things outside there: you have to
take care of the cargo, and then the driver, and [whether] you are towing [the vehicle].
Participant #2: We haven’t discussed the economy here at all.
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.
6. 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.
References
Annarelli, A., Battistella, C., & Nonino, F. (2016). Product service system: A conceptual framework from a systematic review. Journal of Cleaner Production, 139(2016), 1011–1032.
Baines, T. S., Lightfoot, H.W., Evans, S. Neely, A., Greenough, A., Peppard, J., Roy, R., Shehab, E., Braganza, A ., Tiwari, A., Alcock, J. R., Angus, J. P., Bastl, M., Cousens, A., Irving, P., Johnson, M., Kingston, J., Lockett, H., Martinez, V., Michele, P., Tranfield, D., Walton, I. M. and Wilson, H. (2007). State-of-the-art in product-service systems. Proceedings of the Institution of Mechanical
Engineers, Part B: Journal of Engineering Manufacture, 221(10), 1543–1552.
Baines, T. S., Lightfoot, H. W., & Kay, J. M. (2009). The servitization of manufacturing; a review of literature. Journal of Manufacturing Technology Management, 20(5), 547–567.
Bernard, H. R. (2006). Research methods in anthropology (4th ed.). Lanham, MD: AltaMira Press. Bertoni, M., Panarotto, M., & Larsson, T. C. (2016). Boundary objects for PSS Design. Procedia CIRP,
47, 329–334.
Beuren, F. H., Gomes Ferreira, M. G., & Cauchick Miguel, P. A. (2013). Product-service systems: A literature review on integrated products and services. Journal of Cleaner Production, 47(2013), 222–231.
Brax, S. (2005). A manufacturer becoming service provider – challenges and a paradox. Managing
Service Quality: An International Journal, 15(2), 142–155.
Calabretta, G., De Lille, C., Beck, C., & Tanghe, J. (2016). Service Design for Effective Servitization and New Service Implementation. In Service Design Geographies. Proceedings of the ServDes.2016
Conference (pp. 91–104). Kopenhagen, Denmark.
Candi, M. (2007). The role of design in the development of technology-based services. Design
Studies, 28(6), 559–583.
Christiansen, L. (2015). Strategies and Tactics for Service Implementation. In Proceedings of the 4th
Participatory Innovation Conference (pp. 168–175).
Costa, N., Patrício, L., & Morelli, N. (2016). Revisiting PSS and Service Design in the Light of SD-Logic. In Service Design Geographies. Proceedings of the ServDes.2016 Conference (pp. 119–131). Creswell, J. W. (2014). Research design: qualitative, quantitative and mixed method approaches (4th
ed.). Sage publications.
Gebauer, H., Fleisch, E., & Friedli, T. (2005). Overcoming the service paradox in manufacturing companies. European Management Journal, 23(1), 14–26.
Goedkoop, M.J., Halen, C.J.G., van, Riele, H.R.M., te, Rommens, P.J.M., 1999. Product Service
Systems, Ecological and Economic Basics. Report for Dutch Ministries of Environment (VROM) and Economic Affairs (EZ).
Grönroos, C. (2008). Service logic revisited: who creates value? And who co-creates? European
Business Review, 20(4), 298–314.
Grönroos, C., & Gummerus, J. (2014). The service revolution and its marketing implications: service logic vs service-dominant logic. Managing Service Quality, 24(3), 206–229.
Grönroos, C., & Ravald, A. (2011). Service as business logic: implications for value creation and marketing. Journal of Service Management, 22(1), 5–22.
Halse, J., Brandt, E., Clark, B., & Binder, T. (2010). Rehearsing the future. Copenhagen, Denmark: Danish Design School Press.
Holmlid, S. (2010). Service Design and Product-Service Systems. In Proceedings of the 2nd CIRP IPS2
Conference (pp. 195–201).
Holmlid, S. (2012). Designing for Resourcefulness in Service: Some Assumptions and Consequences. In Miettinen, S. & Valtonen, S. (Eds.) Service Design with Theory (pp. 149-158). Lapland Univesity Press.
Holmlid, S., Wetter-Edman, K., & Edvardsson, B. (2017). Breaking free from NSD: Design and Service beyond new service development. In Sangiorgi, D. & Prendiville, A. (Eds.) Designing for service –
key issues and new directions (pp. 95–104). Bloomsbury.
Huikkola, T., Kohtamäki, M., & Rabetino, R. (2016). Resource realignment in servitization.
Research-Technology Management, 59(4), 30–39.
Huxtable, J., & Schaefer, D. (2016). On Servitization of the Manufacturing Industry in the UK. Procedia
CIRP, 52(2016), 46–51.
Jovanovic, M., Engwall, M., & Jerbrant, A. (2016). Matching Service Offerings and Product Operations: A Key to Servitization Success. Research-Technology Management, 59(3), 29–36. Kindström, D., & Kowalkowski, C. (2009). Development of industrial service offerings: a process
framework. Journal of Service Management, 20(2), 56–172.
Lin, M. C., Hughes, B. L., Katica, M. K., Dining-Zuber, C., & Plsek, P. E. (2011). Service design and change of systems: Human-centered approaches to implementing and spreading service design.
International Journal of Design, 5(2), 73–86.
Lønvik, S., Pettersen, I. N., & Verhulst, E. (2016). Achieving Readiness for Change for Successful Implementation of Service Design Projects : Learning from Change Management. In Proceedings of
NordDesign 2016, NTNU, Trondheim, Norway (10-12 August).
Mathieu, V. (2001). Product services: From a service supporting the product to a service supporting the client. Journal of Business & Industrial Marketing, 16(1), 39–61.
Mont, O. (2004). Institutionalisation of sustainable consumption patterns based on shared use.
Ecological Economics, 50(1–2), 135–153.
Morelli, N. (2006). Developing new product service systems (PSS): methodologies and operational tools. Journal of Cleaner Production, 14(17), 1495–1501.
Morelli, N. (2009). Service as value co-production: reframing the service design process. Journal of
Manufacturing Technology Management, 20(5), 568–590.
Mylan, J. (2015). Understanding the diffusion of Sustainable Product-Service Systems: Insights from the sociology of consumption and practice theory. Journal of Cleaner Production, 97(2015), 13–20. Oliva, R., & Kallenberg, R. (2003). Managing the transition from products to services. International
Journal of Service Industry Management, 14(2), 160–172.
Overkamp, T., & Holmlid, S. (2016). Views on Implementation and How they Could Be Used in Service Design. In Y. Akama, J. Blomberg, S. Clatworthy, & S. Holmlid (Eds.), ServDes.2016 - Geographies (pp. 205–214).
Sangiorgi, D., Fogg, H., Johnson, S., Maguire, G., Caron, A., & Vijayakumar, L. (2012). Think Services - Supporting Manufacturing Companies in their Move Toward Services. ServDes.2012 Conference
Proceedings Co-Creating Services; The 3rd Service Design and Service Innovation Conference; 8-10 February; Espoo; Finland, 253–263.
Strauss, A., & Corbin, J. (1998). Basics of qualitative research: grounded theory procedures and
techniques (2nd ed.). Thousand Oaks, CA: Sage publications.
Teso, G., & Walters, A. T. (2016). Service implementation: a framework to assess readiness of manufacturing SMEs. In Service Design Geographies. Proceedings of the ServDes.2016 Conference (pp. 78–90).
Tukker, A. (2004). Eight Types of Product-Service Systems: Eight Ways to Sustainability? Innovating
for Sustainability, 13(3), 246–260.
Vandermerwe, S. (2000). How Increasing Value to Customers Improves Business Results. MIT Sloan
Management Review, 42(1), 27–37.
Vandermerwe, S., & Rada, J. (1988). Servitization of Business: Adding Value by Adding Services.
European Management Journal, 6(4), 314–324.
Vargo, S. L., & Lusch, R. F. (2008). Service-dominant logic: continuing the evolution. Journal of the
Academy of Marketing Science, 36(1), 1–10.
Vasantha, G., Roy, R., Lelah, A., & Brissaud, D. (2012). A review of product–service systems design methodologies. Journal of Engineering Design, 23(9), 635–659.
Verganti, R. (2009). Design Driven Innovation. Boston, MA: Harvard Business Press.
Wetter-Edman, K., Sangiorgi, D., Edvardsson, B., Holmlid, S., Grönroos, C., & Mattelmäki, T. (2014). Design for Value Co-Creation: Exploring Synergies between Design for Service and Service Logic.
Service Science, 6(2), 06–121.
Wise, R., & Baumgartner, P. (1999). Go Downstream: The New Profit Imperative in Manufacturing.
Harvard Business Review, 77(5), 133–141.
Yu, E. (2015). Exploring different relationships between designers and clients in design practices for service development. In IASDR2015 conference - Interplay (pp. 2423–2436).
Yu, E. (2016). Understanding Service Design practices and contributions to New Service Development. Lancaster University.
About the Authors:
Tim Overkamp is a PhD student at Linköping University whose research focuses on service
implementation and potential benefits of introducing implementation as a concept during early stages of service development. He holds a master’s degree in Industrial Design Engineering from TU Delft.
Stefan Holmlid is professor in Design at Linköping University focusing on how new areas
for design influences and changes what design is, and focuses currently on design for service.
Acknowledgements: We would like to thank the workshop participants for their time and
contributions. This research was made possible by funding through the Vinnova program for Strategic Vehicle Research and Innovation (FFI), project DiaGuide2 Dnr: 2014-03942.
