55

Experimenting and prototyping
in the design of complex services

Remote assistance: a case study

Alexis Nicolaÿ1, a

Sylvain Lenflea,b

a I3-CRG, École polytechnique, CNRS,

Institut Polytechnique de Paris

b Professor at Conservatoire National des Arts et Métiers(CNAM – LIRSA)

Introduction

This article describes the initial steps in developing a new service: remote assistance in a military context. More specifically, we show how an atypical prototyping process has been used to enable co-design of the service. Prototyping is highly complex at different levels, and we argue that prototyping is a way of responding to what Lynn Shostack (1992, p. 75) calls one of the most difficult aspects of dealing with a service: describing it. Indeed, it is the immaterial nature of services and their co-production with users that makes the prototyping process more complex. Even if the literature emphasizes the importance of “design and testing” at different stages of the innovation process (e.g. Scheuing & Johnson, 1989; Lovelock and Gummesson 2004), there is a lack of in-depth case studies that could help us understand the specificity of prototyping in services.

56

Thomke’s (2003) in-depth study of the Bank of America prototyping process pioneered the study of experimentation in services. Abramovici & Bancel-Charensol (2004) have also studied this question in relation to the French metro system. However, this literature is confined to business-consumer relations and showcases relatively simple services. By contrast, the services we look at in the defence sector involve customer-provider relationships that sometimes last for decades. The complexity of the ecosystem of actors in public and private sectors, and that of the underlying products and systems – e.g. missiles systems, fighter aircraft or nuclear submarines – are much more complex than the most commonly studied services such as banking, the restaurant business, hotels, or even healthcare. Such elements of complexity are found in many other Business to Business sectors, but are particularly acute in the defence sector. Hence this sector offers insights into “complex services”, together with an understanding of how to design and prototype them.

Our goal in this paper is to study this question in the case of complex, B2B services. This leads us to develop a longitudinal case study, covering the period from March 2013 to December 2016, of the remote assistance service between a major defence contractor and the French Navy. We focus on the role of prototyping in the design process. This case is original on several counts and notably in its duration, the degree of co-design involving the pilot customer (the French Navy), and the close relation between the individual component parts of the prototype (artefacts, environments and processes) and the “live” service. It contrasts significantly with the vision of Rapid Prototyping (e.g. Brown, 2008) most often described and prescribed for services. Thus, our research makes three principal contributions. Firstly, we present a prototyping approach rarely – if ever – applied to services. Secondly, we show that prototyping has enabled the development of the service concept beyond solely technical and organisational issues. We highlight this aspect by retracing the various iterations of the service value proposition throughout the prototyping process. Lastly, we describe the role of prototyping in constructing the service ecosystem (in the sense of Mitleton-Kelly, 2003).

The paper is organized as follows. Section 1 analyses the literature and describes the conceptual framework. Section 2 presents the research setting, data collection and the process of analysis. The detailed 57prototyping process is presented in section 3. Section 4 reflects on the case and what arises from it.

1. Literature review:
prototyping for complex services

Here, we begin with a section dedicated to a review of the literature regarding the concept of service prototyping. Then we introduce the goals and basic approach of the case study that we develop in the second part of this contribution.

Whether directed to products or services, although grey areas still remain, the issue of prototyping has been amply studied in the literature. One of the broadest definitions of the concept is certainly that of Tim Brown (2008, p. 3):

The goal of prototyping (…) is to learn about the strengths and weaknesses of the idea and to identify new directions that further prototypes might take.

This definition is very much in line with the body of literature on design thinking (in fact, the title of the article is Design Thinking). This definition of the prototype as resource and intermediary recurs in many contributions (e.g. Jeantet et al., 1996; Junginger, 2008; Lim et al., 2008; etc.).

The literature on New Product Development (NPD) and Product Design identifies three key roles for prototyping in the product design phase2 (Thomke, 2003a; Rhinow et al., 2012).

The first of these roles relates to exploration. By helping visualise the object that is the focus for exploration the prototype makes for more effective co-ordination between contributors to the prototyping process. The second role is that of supporting evaluation. This enables users to experience the product, provides the designer with feedback that improves the overall understanding of user requirements and 58expectations, allows ideas to be tested, and involves users in the design process. The third role of prototyping as identified by Rhinow et al. (2012) relates to communication. Team members are brought closer together, enabling a shared experience of the design object. In broader terms, the prototype is often described as a way of demonstrating the progress made during the design process in order to secure the commitment of project contributors outside the design team (e.g. Houde & Hill, 1997 or Henderson, 1999).

The same considerations appear in service-related literature addressing the issue of prototyping. Johan Blomkvist & Stefan Holmlid (2010, p. 5)3 distinguishes between communication and learning in the utility of prototyping. The latter category is itself subdivided into exploration and evaluation. The definitions attributed to these three terms, and the verbatim accounts of practitioners transcribed by the authors, are similar in overall terms to those reported by Rhinow et al. (2012).

From this overview of product and service prototyping we conclude that for services, as for products, prototyping has three main aims: exploration, evaluation and communication. As the brief overview of the “product” and “services” prototyping literature shows, there appear to be no major differences between these two worlds. In fact, the key prototyping goals identified apply equally to products and services. We note that Tim Brown (2008) makes no differentiation between service and product prototyping, and simply emphasises that although prototypes of a service innovation are not necessarily physical, they must nevertheless be tangible. He recommends filming the service prototyping process to provide a material record of the experiment.

Now that we have discussed the purposes of prototyping let us turn to its resources. In the following paragraphs we present a characterisation of prototyping artefacts developed by Sihem Ben Mahmoud-Jouini et al. (2014). Although this was elaborated in the context of new product development, we will refer to this work as the basis for characterising the various experiments conducted on remote assistance. We will also demonstrate that it applies to the development of complex services.

59

Tab. 1 – Prototyping artefacts.

		Artefacts
		Stimulators	Demonstrators	Prototypes
Phases of the creative process	Inspiration	Initiating and helping explore new and unfamiliar knowledge
	Ideation (concept generation)	Create a rich experience that generates pathways for original and relevant ideas
	Concept selection		Provide relevant empirical support for the analysis and selection of different concepts
	Concept development (innovative solution design)		Provide a design context to develop the concept into an innovative integrated solution
	Evaluation and validation of innovative solution		Provide a design context to experiment and validate an innovative integrated solution
	Innovative solution development into new product and/or service			Provide a tool for testing the fit of the developed solution with the specification.

Source: Ben Mahmoud-Jouini et al., 2014

The authors identify three types of prototyping artefact: the stimulators, the demonstrators and the prototypes. These artefacts address different goals in the successive phases of the development process.

The stimulators play a role in the earliest phases of the design process: “inspiration” and “ideation”. The authors describe them as artefacts intended to “stimulate the creativity of the designers […]”. 60They are described as “open-ended” objects offering an intentionally incomplete sensory experience (the terms used to describe them are “strange, poetic and playful”) in order to trigger curiosity, surprise and reflection.

The main function of the demonstrators is to coordinate exploration and demonstrate the progress made as the basis for identifying “an integrated feasible and relevant solution”. Their use is concentrated mainly in the concept selection phases, and in the subsequent development and testing of a solution in response to it.

Lastly, the function of the prototypes is to demonstrate that the solution developed (with the assistance of the demonstrators) meets the specifications set by users. Placed at the end of the development process, the use of (successful) prototypes is presented as the stage preceding the transition to the detailed design of a commercial solution, regardless of whether that solution is a product or a service.

There is therefore an important literature on the role of prototyping in the innovation process for products and services. However, concerning service innovation, we can identify two main weaknesses. First this literature deals with business to consumer situations for relatively simple services. Thomke’s (2003b) study of Bank of America’s is typical of this. Second, we highlight a lack of in-depth case study of the service prototyping process i.e. how it unfolds in organizations. The goal of our research is to fill this gap by providing a fine-grained description of the prototyping process of a complex business to business service. This will allow us to discuss the literature on service prototyping in the light of complex service design.

2. Research design and data

To study the prototyping process of complex services we took up an opportunity to work with a major defence firm linked to the French navy. Our research was in the context of a CIFRE contract, a French system that helps a firm hire a doctoral student. This gives us the opportunity to follow the prototyping process of a new service: remote 61assistance. Before describing our methodology for data collection in detail we shall provide an overview of this service, and analyze the design problems that it raises.

2.1 Case layout

In broad terms, remote assistance offers innovative ways of treating equipment malfunctions to the Armed Forces while on operations. To identify the innovation offered by the remote assistance we can describe the “traditional” organisation of technical support through the fictional example of a malfunction occurring on board a warship on operational duty off the Arabian Peninsula (cf. Appendix 1). On board a warship the crew provides the first line of technical expertise for diagnosis and repairs. Whenever necessary, the crew can call upon military and/or industrial expertise from the manufacturer through “technical assistance” procedures. Where the equipment failure proves severe enough to justify such action, the warship would leave the theatre of operations and put in to a friendly port. In our example, this port would certainly be Djibouti, where French forces maintain a permanent presence. It would take around 72 hours to complete this passage. In the meantime, the manufacturer would gather specialised personnel and equipment to establish a diagnosis, and prepare to carry out the repair or replacement of faulty parts. Upon resolution of the malfunction the warship would return to its operational area, representing another 72-hour passage in our example. In this example the warship could be away from its mission for more than a week, even though the repair or maintenance work itself might only take a few hours. Such downtime has potentially significant financial and operational costs. Indeed, a warship exiting a theatre of operations leaves a gap in military capability which, at best, can be filled by another vessel (again at a cost), and which, at worst, may compromise the whole mission.

Remote assistance consists in linking both on board and onshore industrial and military expertise. This concept makes it possible to drastically reduce the ship’s downtime and avoid the need for the vessel to leave the theatre of operations, thereby limiting operational cost. The general operating principle of remote assistance is summarised in the following diagram.

62

Fig. 1 – The operating principle of remote assistance.

To enable remote assistance, the fictional ship in our example would be fitted with a “deployable kit” composed of audio and optical equipment (such as cameras, borescopes, Google glasses, etc.), communication means and cryptography equipment in order to send and receive audio, images and data within secure transmissions. These “deployable kits” communicate with “remote assistance rooms” located in military and industry premises. Appendix 2 presents the typical layout of a “remote assistance room” to further illustrate the concept.

2.2 Data collection and analysis

Data was collected over a two years period. As part of his doctoral studies, and following the paradigm of action research (David, 2000), the lead author was an active member of the project team throughout the period from November 2014 to December 2016. In addition to this active contribution, the case study drew on the reports of many meetings and available archive material.

The choice of a longitudinal case study was dictated by a number of considerations. The first is the period covered by the case study: around 63four years between March 2013 and December 2016. The many events we refer to and the changes seen in the service concept and prototyping methods used demand a clear and long-term perspective to establish consistency. Such a lengthy period is also relatively unusual for service prototyping. The second aspect is the complexity in the network of prototyping process contributors. A single pilot body – the French Navy – was selected at the very earliest stage of the project. However, this body cannot be treated as a single entity. In the case study we make reference to all the contributors (departments and entities of the Ministry of Defence) within the limitations regarding confidentiality in this sector. Here again, referring to the diversity of contributors without placing the narrative within its overall timeframe would have been prejudicial to the study.

Following the paradigm of grounded research (Miles and Huberman, 1994; Eisenhardt, 1989; Yin, 2003), our analysis was made from detailed field notes – interview notes, transcripts of project meetings, company documents – compiled into detailed case studies for each phase of the prototyping process. This process was iterative, since cases were frequently updated after follow-up discussions with respondents. The case study report was re-read by key informants and discussed during bi-annual research meetings involving the author and members of the PhD steering committee involved in the prototyping process. These meetings simultaneously enabled the results presented to be confirmed, and the directions taken by the research to be discussed.

The remainder of this contribution discusses the longitudinal case study (Yin, 2009) of the prototyping process for remote assistance. In light of the literature review presented in the previous section, we will demonstrate i) the relevance of the model developed by Ben Mahmoud-Jouini et al. (2014) for complex service design; ii) the originality of the remote assistance case study relative to the main contributions to service prototyping; and lastly iii) the contribution made by this case study in respect of the theory and practice of professionals.

64

Acronyms

EMM: État-Major de la Marine (Chief of Naval Staff)

EMA: État-Major des Armées (Joint Chiefs of Staff)

UTC: Coordinated Universal Time

Fig . 2 – Timeline of the remote assistance prototyping process.

3. The remote assistance prototyping process

The timeline in Figure 2, sets out the sequence of events leading up to implementation of the remote assistance project, from March 2013 to July 2016. The author was involved in the project from November 2014 onwards, and continued after the completion of the prototype phase.

65

We identify four major stages within this timeline. In the model produced by Sihem Ben Mahmoud-Jouini et al. (2014., cf. Table 1), these correspond to the four final stages of the development process:

1. Concept selection: the initial experiments

2. Concept development: the sea trials

3. Solution evaluation and validation: end-to-end testing

4. Development of the solution into a new service: long-term experimentation

We present these four stages in the following paragraphs.

3.1 Concept selection: the initial experiments

From a design viewpoint, remote assistance is remarkable in the sense that from its inception the service has been co-designed with a pilot customer: the French Navy. From 2013, when the manufacturer decided to develop such a service, there were a number of formal and informal meetings between representatives of the manufacturer and of the French Navy. These meetings culminated in the granting of formal approval by the Chief of Naval Staff and authorisation from the Joint Chiefs of Staff regarding the security considerations of information systems. Without these decisions, taken at a high level within the Ministry of Defence, the prototyping process we are describing would not have been possible. The manufacturer’s project teams highlight the decisive role played by a naval officer in supporting the case for remote assistance in the military hierarchy. The presence of many former military personnel within the company was also a determining factor for the establishment of a successful dialogue.

Two experiments were conducted during this first development phase. The first was conducted on the manufacturer’s premises in April 2014. It sought to identify options for the most visible and critical element of remote assistance: the deployable kit (see Figure 1). This first experiment selected two of the six tested deployable-kit solutions. One was based on a single item of equipment, with integrated optics and software similar in appearance to an SLR camera; the other was a tablet-based software interface interacting with a number of optical accessories. Trials of both solutions were conducted in the presence of French Navy representatives. 66The experimental protocol was limited to demonstrating the capabilities and user-friendliness of remote assistance kits. In practical terms, the demonstration consisted of linking the remote assistance kits in one room to a PC in an adjacent room using a hard-wired link. The networking and configuration aspects were therefore not demonstrated.

The second experiment was conducted approximately six months later, in October 2014. It was conducted on board a naval vessel docked at Brest naval base. This demonstration replicated the approach tested at the manufacturer’s premises, and was not therefore intended to demonstrate new functionalities. Its major challenge was to measure the constraints imposed by the onboard environment: narrow passages and companionways, confined and/or unlit spaces, etc. This “hands-on” testing was a decisive step for remote assistance inasmuch as it gave naval crews a clear impression of how remote assistance could contribute to their onboard operations.

It was following this initial phase of experimentation that a preliminary formulation of what remote assistance service could offer was developed: “To provide a channel for delivering the manufacture’s expertise required to enable remote diagnostic analysis and guided responses”4. This value proposition reflects a very “technical” acceptance of remote assistance.

3.2 Concept development: the sea trials

As previously stated, the network aspects were not addressed by the initial experiments. It is worth repeating that remote assistance creates an interface between two networks (see Figure 1) making this issue a critical one for the feasibility of the service. One network is military, with satellite communications between the warship on operational duty and an onshore military base. The other is a specific or secured Internet-based network connecting the military base with the manufacturer’s facilities.

These networks form a critical component of remote assistance, both in technical terms (configuration, encryption, etc.) and in employment: the suitability of available bandwidth to achieve the required image quality and latency are two particularly important aspects that could downgrade the service, or even make it impossible to use. It was therefore decided to run a number of experiments to resolve these uncertainties.

67

Two types of test were planned for April 2015: trials conducted in dock at the Port of Toulon on one hand, and sea trials on the other. The aims of this second phase of experimentation were as follows5:

–To validate communication between the warship and the onshore installations;

–To verify correct operation of the system at sea;

–To verify the maximum and minimum levels of data transmission flow provided by the network at sea;

–To verify system user-friendliness and ease of deployment, and to identify any improvement required;

–To make the crew aware of the benefits of remote assistance;

–To develop a working method to be shared by the crew and the manufacturer’s technical staff.

We emphasise once more that exploration, evaluation and communication goals were explicitly assigned to this phase of the prototyping process.

Given the various constraints imposed by the French warship selected to take part in the experiment, the work was concentrated into eight days. During the first five days the dockside tests were conducted. These tests linked the moored warship to a control room located in the Toulon naval base via a French Navy terrestrial network. For the following three days, the warship was at sea off Toulon. During this period, satellite communications were used to conduct five sessions of one hour each to test a range of different remote assistance usage scenarios. For each test – onshore and at sea – one technical assistant provided by the manufacturer was present on board the ship, and another onshore.

This series of tests generated very comprehensive feedback, not only in terms of technical issues (e.g. image quality at different bandwidths), but also in terms of usage (e.g. using “radio” type diction to facilitate interaction). The manufacturer’s staff in charge of the tests noted that:

We had a positive response from [ shore-based ] Naval personnel. on board [ the warship ] , the crew had little involvement in the tests, as a result of having more important operational priorities. In informal conversations, the ship ’ s 68 officers were emphatic in stressing the importance of using the remote assistance system as a collaborative resource with no suggestion of questioning the skills of crew members.

Following these tests, in July 2015 a second version of the remote assistance value proposition was proposed. It emphasized remote assistance as being part of a broader concept of “extended support service for surface warships”. Compared with the first form of the value proposal6, the second version puts less emphasis on the technical benefits of remote assistance. This change reflects i) that the manufacturer’s teams had a more detailed understanding of the mechanisms at work in the remote assistance service, beyond its technical aspects; and ii) that the end users (in this case, the French Navy) had appropriated the concept of remote assistance after having experienced it.

3.3 Solution evaluation and validation:
the end-to-end testing

The third part of the remote assistance prototyping process consisted of “plugging in” the manufacturer’s component of the remote assistance system. Until this point, the various demonstrators had been focused on communication between two parties: shipboard naval personnel and their colleagues ashore in naval bases. This third phase of the prototyping process consisted of adding a third point of contact: the manufacturer. With this component in place, the remote assistance demonstrator covered the full range of system functionality.

Implementing this end-to-end test required a high level of collaborative work between defence ministry personnel and the manufacturer’s teams. Interfacing a military (ship-to-shore) network with a private network (connecting the port with manufacturer facilities) is by no means an easy task, and the Ministry of Defence had to be persuaded of the merits of doing so.

The remote assistance presentation video produced by the manufacturer played a major role in this regard. This 3’09’’ video with no voiceover illustrated how remote assistance can deliver technical support. It focused on:

69

–The process stakeholders;

–The system functions;

–The procedures implemented to deal rapidly with malfunctions in an operational context.

The majority of this video was shot during the sea trials conducted in April 2015. It therefore presents remote assistance in its true environment. The video successfully conveyed an image of the remote assistance concept to representatives of the French Navy and of the manufacturer. It played a crucial role in convincing the authorities to permit the interfacing of military and civil networks in order to conduct the ‘end-to-end’ experiment that was achieved in October 2015.

3.4 Development of the solution
into a new service: long-term experimentation

Encouraged by the success of the end-to-end demonstration, the decision was made to conduct a long-term joint experimental programme. Under the terms of an agreement signed at the beginning of December 2015 by the French Navy and the manufacturer, this joint experimental programme involved the provision of remote assistance kits on board two warships for an initial period of six months. A second agreement signed in June 2016 extended the experimental programme for six months and included a further warship. Under the terms of this agreement the manufacturer provided the French Navy with two remote assistance kits as well as crew training support. The goal was to enable the pilot customer to gain hands-on experience of the remote assistance system while in its real operational environment.

No contractual commitment to provide a remote assistance service was entered into under the terms of this agreement. Nevertheless, a permanent remote assistance unit was installed in the manufacturer’s premises for the purposes of the experimental programme.

In mid-December 2015 the opportunity arose to use the remote assistance system under live conditions. While on operational duty one of the naval vessels equipped with the remote assistance system suffered a failure in one of its systems. The crew were not able to identify the cause of the problem. Contacted initially by phone, the 70remote assistance unit was activated, and a remote assistance link established. Within approximately four hours, the collaborative efforts of the crew and the manufacturer’s technical assistants had made it possible to identify the source of the malfunction and replace the defective component. The warship was then able to continue its mission.

The technical assistants who provided the support service made the following two observations. On the one hand, the response had confirmed the relevance and suitability of remote assistance to guide and/or confirm the fault diagnostic analysis conducted by the crew, provide advice on a rapid repair and avoid causing further problems as a result of ineffective attempts at repair. On the other hand, they noted that the level of pressure imposed on the vessel’s crew fell significantly the moment that the connection was made. More specifically: “the crew members are reassured by having someone to speak to, but it is still important to build trust”. They see the ability to use the same terminology and having a clear understanding of the constraints applying on board an operational warship as being essential for creating this climate of trust. One of the technical assistants involved was a former Petty Officer in the French Navy. The ability to understand (and use) the appropriate military jargon very significantly facilitated the communication process. Lastly, the crew members commented that the physical absence of the technical assistants, so that they were not involved in the stressful situation on board, made it easier to assess the issues involved. The success of this response definitely demonstrated the feasibility and operational value of the remote assistance service.

In March 2016 (three months into the long-term experimental programme), a third version of the remote assistance value proposition was defined: to offer “improved systems availability, especially under operational conditions”. This wording is radically different from the previous two value propositions:

–“To provide a channel for delivering the manufacturer expertise required to enable remote diagnostic analysis and guided responses”;

–To provide an “extended support service for surface warships”.

71

By this point, remote assistance was no longer seen as simply a user need, but as a way of improving the existing support for military equipment. This new value proposition reflects a more general view of the remote assistance concept, addressing the fundamental need of the users, i.e. hardware availability to deliver their missions. Unlike previous value propositions, this version was not developed solely “behind closed doors” by the service provider. A series of meetings with the French Navy were held to refine the concept (particularly in terms of the nature of the requirement). It provides a clear example of the concept being co-designed by the service provider and the prospective customer. This co-design involvement is a clear indication that the experimental programme has enabled all its stakeholders to reach a shared understanding of the potential benefits and modalities of the emerging service.

4. Discussion of the case study
and its contributions

In this section, we discuss the results from the case study of remote assistance prototyping. Firstly, we show how our case inscribes itself within frameworks developed in our literature review. Secondly, we argue and demonstrate the originality of our case study with respect to service prototyping. We, then provide evidence that prototyping improves the quality of the design process for new services. Indeed, as we will see, the service concept changes during the process. Finally, we show how the prototyping process contributed to the development of a service ecosystem, a point rarely mentioned in the literature.

4.1 The case study inscribed
in the theoretical framework

Chronologically described in the previous section, we show here that remote assistance’s prototyping process matches step-for-step the model of complex prototyping developed by Sihem Ben Mahmoud-Jouini et al. (2014) and presented in our literature review.

72

Tab. 2 – Theoretical framework vs. case study.

		Steps of prototyping
		Phase 1		Phase 2		Phase 3	Phase 4
		Industry premises	In dock #1	In dock #2	At sea	End-to-end	In operation
		04/14	10/14	Trials 04/15		10/15	12/15 to 12/16
Roles of prototyping in Ben Mahmoud-Jouini et al. (2014)	Stimulators	No stimulator in remote assistance prototyping
	Demonstrators	Provide relevant empirical support for the analysis and selection of different concepts
				Provide a design context to develop the concept into an innovative integrated solution
						Provide a design context to experiment and validate an innovative integrated solution
	Prototypes						Provide a tool for testing the fit of the developed solution with the specification.

Interestingly, the table above allows us to highlight that the prototyping process for remote assistance did not involve the use of “stimulators”. Targeted mainly at the exploration of new knowledge and associated concepts, a possible explanation for their absence for remote assistance, is the relative “maturity” of both the provider and the customer with regards of the issues addressed by the prototyping process. In other words, both the manufacturer and the French Navy had in depth experience in dealing with technical malfunctions of the concerned equipment, 73prior to remote assistance prototyping. As such, “inspiration” and “ideation” were greatly facilitated and pre-existing knowledge was readily available for concept selection. Hence, the prototyping process started with demonstrators.

From the use of demonstrators and all the way through the development of the new service with the use of prototypes, our case study adhered step-for-step to the theoretical model. In that sense, we fully inscribe our case as a prototyping case, reinforcing the statement that models used for product are fully relevant for complex service design.

Symmetrically, our case study provides insights as to distinctive traits of service prototyping that do not appear in product development. Examples of such traits include the interactional nature of services between customers and providers (particularly seen in the final stage of our case study) or the use of immaterial artefacts such the remote assistance video. In the following three sections, we discuss in greater details the inputs of our case to service design.

4.2 A prototyping approach rarely applied to services

Although it closely matches the framework developed for products by Ben Mahmoud-Jouini et al. (see previous section), the prototyping process we have described differs significantly from most of the service prototyping case studies in the existing literature. We identify three largely interdependent insights that contribute to the originality of our case study, notably with regards to well established “rapid prototyping” (e.g. Brown, 2008) prescriptions and insights:

–It involves a long-term experimental programme;

–The solutions tested are those to be implemented as a live service;

–The customer was very closely involved in designing the prototype.

4.2.1 A long-term experimental programme

Prototyping included a series of experiments over a rather long period of time, between March 2013 and December 2016. Having approximately three years and nine months in total our case sets itself apart from the rapid prototyping mindset, something which 74is especially prevalent in design thinking. As demonstrated by Tim Brown (2008), rapid prototyping presumes that a prototype must be as limited as possible in terms of time, effort and investment. This viewpoint is summarised as follows: “The more ‘finished’ a prototype seems, the less likely its creators will be to pay attention to and profit from feedback.” (Brown, 2008, p. 3)

The approach we have presented is diametrically opposed to this perspective. Our prototyping approach has sought to gain experience in conditions that are as close as possible to those of the “live” service, and is focused on lengthy test periods. The example provided by the fourth phase of experimentation (referred to as the “long-term experimental programme”) is particularly significant in this respect. Initially scheduled for six months and subsequently extended for a further six months, this phase was intended to make the remote assistance prototype available to the customer in order for them to gain experience of it under live operational conditions.

4.2.2 A prototyping process that comes as close
as possible to the reality of the intended service

Following the same line of thought, and in contrast to that put forward by Tim Brown, our prototyping approach sought to create demonstrators and prototypes that reflected the reality of the intended service as closely as possible. In this sense, we turn to the notion of fidelity as described by Stefan Thomke (2003a, p. 7). Stefania Passera et al. (2012) also use the concept of fidelity/resolution in their SPPF (Service Prototyping Practical Framework).7 The authors use the term “fidelity” to describe the “closeness” of particular aspects of the prototype to the final “eventual design”, and the term “resolution” to describe the “general level of verisimilitude of the service prototype” (the sum total of the fidelity of distinct aspects). They illustrate this difference as follows:

75

Fig. 3 – Fidelity and resolution of a service prototype. Source: Passera et al. (2012).

The following table charts the six stages of the prototype as described in the previous section. The presence of the component parts of the remote assistance system within the prototyping artefact is evaluated for each of these stages. In the terminology used by Passera et al. (ibid.), each “component” represents a new “level of detail”.

Tab. 3 – Incremental implementation of service components in the prototyping.

		Steps of prototyping
		Industry premises	In dock #1	In dock #2	At sea	End-to-end	In operation
		04/14	10/14	Trials 04/15		10/15	12/15 to 12/16
Remote assistance components	Deployable kit + software	Multiple solutions	X	X	X	X	X
	Military network (Warship ↔ Port)			Proxy	X	X	X
	Complete network (Warship ↔ Port ↔ Industry)					X	X
	Remote assistance rooms					Proxy	X
	Service context				Simulated		X
	Service procedures						Simulated

(11/14) Trials on a complete network reference platform.

76

This table provides an illustration of the complementary nature, progressivity and increasing complexity of the demonstrators and prototypes used for the remote assistance service.

The deployable kits (containing tablets, cameras, optical accessories, etc.) and the software interface are the most visible components of the remote assistance service. It is also the newest component for warship crews. In this sense, the remote assistance kit can be considered as a “boundary object” (Star, 1989; Carlile, 2002) between the onboard world and that of the onshore support function (particularly for the manufacturer). As Carlile (2002, p. 452) explains:

[ A boundary object ] provides a concrete means for individuals to specify and learn about their differences and dependencies across a given boundary. [ It ] allows individuals to specify what they know – what they worry about – as concretely as possible to the problem at hand.

Many authors highlight the role of these boundary objects in the development of new service concepts generally, and prototyping in particular (e.g. Bertoni et al., 2016 and Exner et al., 2016). This is one of the reasons why “deployable kits” were the subject of particularly close attention during the initial phases of remote assistance prototyping, with a number of demonstrators being tried out before a single solution was stabilised in subsequent demonstrators. At each subsequent stage, the same pattern continued, with a new component added to the demonstrator until the final prototype was arrived at, where only the service procedures were “simulated”8. This incremental approach made it possible to refine the knowledge of all the remote assistance stakeholders at every stage in the prototyping process, and to refine the concept and resources to be implemented. We also demonstrate that the prototyping process has followed the Ben Mahmoud-Jouini et al. (2014) model stage-for-stage, from “concept selection” through to “solution development into new products and/or service”. This fact allows us to confirm the relevance of the model for complex services.

77

In terms of resolution and fidelity, this calls for two main comments. The first is that the level of resolution achieved by the final prototype is extremely high. However, this very high resolution was achieved progressively by the addition of new “levels of detail” or “components”. The second comment is that for each component, an initial “low fidelity” iteration was included first. We therefore demonstrate a progressive increase in resolution as a result of cumulating the addition of new components to demonstrators, and the increasing fidelity of individual components. As stressed by Passera et al. (2012 p. 9), there is no consensus in the literature regarding the optimum level of resolution for a prototype. Our case study provides an element of an answer in the case of complex B2B services: incrementally raising the level of prototype resolution to the point where it enables a comprehensive understanding and adoption of the individual components. We also demonstrate that “boundary objects” provide an interesting point of entry into a “high-resolution” prototyping process.

4.2.3 Very close customer involvement in the prototyping process

The third original feature of the prototyping process we have described is the level of customer involvement (the French Navy, in this case). The idea that one or more potential customers can – indeed should – take part in the prototyping process is something that meets with consensus in the literature, both for products and services. On the other hand, the desirable degree of involvement varies from author to author. Stefan Thomke’s article from 2003 published in the Harvard Business Review on the prototyping process used by the Bank of America is one of the most cited for service prototyping. The author explicitly recommends identifying, isolating and prioritising suggestions for experimentation, then scheduling them and designing them with no customer input. In the proposed model (Thomke, 2003a, p. 2-5), customers become involved only after prototype implementation. The aim is to work out experimentation problems without customers before the prototype is tested in a live environment. Stefania Passera et al. (2012) include the audience as one of the factors in their Service Prototyping Practical Framework. The authors make clear that the prototype should be designed from the outset with the target audience 78in mind in order to adapt the prototyping technique used (Passera et al., 2012, p. 11). Having the audience “in mind” is not the same as co-designing. Neither the degree of customer participation nor the experimentation phase during which this participation should take place are specified.

In the case of remote assistance, the pilot customer became involved at a very early stage and covered every aspect of prototyping, including its implementation. As the timeline (cf. Figure 2) shows, the pilot customer was consulted at the very beginning of the project. The co-design of the prototyping process included identifying the concepts to be tested and the design of the experiment. This, once again, sets us apart from the dominant vision of prototyping.

4.3 Innovative service concept generation
through prototyping

As stated in the first section of this paper, the three key roles of prototyping are exploration, evaluation and communication (Houde & Hill, 1997; Blomkvist & Holmlid, 2010; Rhinow et al., 2012). Although the overwhelming majority of authors indicate that these three functions of prototyping improve the quality of the design process for new services (particularly as a result of more innovative proposals), this process is rarely shown in case studies.

The remote assistance case study we have developed here offers an interesting perspective, in the sense that we have been able to demonstrate how the service concept evolved with the prototyping process9:

1. November 2014: “To provide a channel for delivering the manufacturer’s expertise required to enable remote diagnostic analysis and guided responses”;

2. July 2015: To provide an “extended support service for surface warships”;

3. March 2016: “To improve systems availability, especially under operational conditions”.

79

This development demonstrates a broader and more general approach to the provision of remote assistance, moving away from an approach focused on remote assistance as a “delivery channel” towards the integration of remote assistance into the broader objective of “systems availability”. It is clearly an effect of experimenting with the service. The widening of the concept into a more general approach occurred hand-in-hand with the experimental programme being more closely integrated into the live environment of the pilot customer. 

Beyond actually showing how prototyping can help the generation of innovative service concepts, we highlight that service concept generation is neither limited to early phases of prototyping, nor limited to the “exploration” function of prototypes.

In terms of technical artefacts, the remote assistance service has seen no major change involving the three versions of the value proposition. The concept has evolved as a result of incorporating other needs identified for and by the customer. This approach to service innovation is described by Faïz Gallouj & Olivier Weinstein (1997) as a “recombinative innovation”. The authors explain that “Innovation of this kind exploits the possibilities opened up by new combinations of various final and technical characteristics, derived from an established stock of knowledge and a given technological base or existing within a defined technological trajectory” (p. 550). In this instance, and in the most complete version of the service concept, remote assistance makes it possible to reconsider the way in which ‘traditional’ technical support is delivered so that the customer’s capacities are improved.

To arrive at this improved vision of remote assistance, all three functions – exploration, evaluation and communication – had a role to play throughout the prototyping process. We support this argument by pointing out that the iterations of the value proposition formulation occurred in close collaboration with the pilot customer (hence, communication). The new value propositions were identified, tested and reflected upon with the customer in parallel with and as integral part of the prototyping process.

The timeline of the three iterations of the service concept also show that “ideation” was not confined to the earliest stages of the service prototyping. This goes against the traditional vision of the prototyping process (e.g. Thomke, 2003a). In Jouni’s et al. (2012) “phases of 80the creative process” (see Table 1) “inspiration” and “ideation (concept generation)” are the first two. They are supported by “stimulators” that aim at “initiating and help exploring new and unfamiliar knowledge” and “creating a rich experience that generates tracks for original and relevant ideas”. Not only did the prototyping process that we described for remote assistance not involve “stimulators”; our sequence of value propositions shows that the functions of stimulators were performed by demonstrators and prototypes.

4.4 Prototyping as a way of creating the service ecosystem

The remote assistance experimentation programme was conducted from the outset in close collaboration with the pilot customer: the French Navy. We identify three key roles played by the Ministry of Defence during the experimental period:

–The role of co-designer;

–The role of promoter;

–The role of decision-maker.

The role of co-designer was fulfilled mainly by Navy “workforce”: vessel commanders (the “pashas” in naval lingo), the crew members responsible for shipboard maintenance and the operation of weapon systems, and the onshore support teams. All contributed their operational experience to achieve a clearer definition of requirements in terms of functionality and operational constraints. As experts in their own vessels, these are the same people who made the experimentation process possible on board the warships.

The second role is that of promoting the value of the remote assistance service to decision-making bodies. The operational personnel clearly had a critical level of influence in this role. Naval staff pays close attention to the opinion of the “pashas” since they are commanders of their ships. The same is true of the “Programme Officers” (POs). For every major armament programme, these POs are responsible for ensuring that the functions delivered (in this case, those of a warship) fully respond to the requirements expressed by the Naval Staff. They act as a go-between, connecting operational personnel with the Naval Staff. Their support was a decisive factor in favour of remote assistance.

81

The third and last role is that of decision-maker. This role can be clearly observed in the timeline of the remote assistance prototyping process (cf. Figure 2), with many authorisations and agreements necessary throughout the experimental programme. All of these decisions were taken at a very high level by the Joint Chiefs of Staff and/or the Chief of Naval Staff. Whether to authorise experimental protocols (particularly in the context of cyber security issues) or to make (already heavily committed) warships available to take part in experiments at sea or in dock, these decisions were required between every two stages of the experimental programme.

Identifying and convincing the right people in the earliest phases of the remote assistance study represented a significant part of the work involved in the remote assistance experimental programme. In this context, thorough knowledge of the customer’s organisational structures is a decisive factor. This knowledge was in large part facilitated by the many former naval personnel now employed by the manufacturer.

Over and above these three roles, the experimental programme enabled the gradual coming together of the extensive network of stakeholders making up the service ecosystem and gaining their commitment. This service ecosystem concept is referred to by many leading authors, including Stephen Vargo & Robert Lusch (2010). In a wider context, the terms Business Ecosystem (e.g. Moore, 1996, Lewin & Regine, 1999, Iansiti & Levien, 2004) and Social Ecosystem (e.g. Mitleton-Kelly, 2003) both refer, albeit with a few variations, to the same general vision. We adopt the definition given by Mitleton-Kelly of a social ecosystem:

Each organization is a fully participating agent which both influences and is influenced by the social ecosystem made up of all related business, consumers, and suppliers, as well as economic, cultural, and legal institutions.

(Mitleton-Kelly, 2003, p. 30)

The community of participating stakeholders gradually expanded as the remote assistance experimental programme progressed through its stages. This trend is driven by a number of factors.

The first is the increasing complexity of the experimental programme. The need to involve the skills required for the effective inclusion of additional components in demonstrators (military 82network, complete network, remote assistance rooms, etc.) made it essential to involve an increasing number of personnel and distinct entities. This applies equally to the internal organisational structure of the manufacturer, the pilot customer (the French Navy), the Ministry of Defence and the subcontractors. This upward trend in prototype complexity increases not only the number of system co-designers, but also the number of “decision-makers” required to make progress possible.

The second factor is the deliberate intention of the manufacturer to diversify the environments in which the experiments were conducted. Several different ships were involved at the naval bases of Brest and Toulon. This again increases the number of co-designers, although the main goal was to boost the number of “promoters”, notably by involving a growing number of ship commanders and other high-ranking officers.

Finally, increasing the number of “promoters” and the number of different events in the experimentation process (especially the live response delivered in mid-December 2015) creates a word-of-mouth effect. Distribution of the remote assistance presentation video also contributed to this process of raising awareness.

We outline the progressively growing ecosystem in the following Figure 6. There, we highlight that, in the manner depicted in the “socio-technical graphs” of Bruno Latour et al. (1990), the development of the different demonstrators and prototypes gained support from increasing numbers of promoters to the remote assistance concept. We argue that this phenomenon goes beyond the traditionally described role of prototypes as communication tools in order to secure the commitment of project contributors outside the design team (Houde & Hill, 1997). The buy-in was achieved mostly by the interlinkage of co-designers, promoters and decision-makers roles in order to allow the prototyping process to carry on. In other words, contributors were rallied more around the project of prototyping (with the aim of creating a “live” service afterwards) than around the different prototype demonstrations and experiments.

83

Fig. 4 – The building of a service ecosystem.

During the long-term experimental programme that constituted the final stage of the prototyping process, there was an involvement of almost all stakeholders with co-designing and co-producing the future “live” service.

Conclusion

We will summarise the lessons learned from the case study as developed and discussed here. As we have shown in the literature review, the existing works on prototyping in services emphasizes a vision largely influenced by the design thinking approach (e.g. Brown, 2008). In this perspective a prototype must be as limited as possible in terms of time, effort and financial investment in order that the designers can extract maximum benefit from the lessons of the prototyping process. 84This approach focuses on simple business-to-consumers services (e.g. Thomke, 2003a).

As we have seen, things change when dealing with complex business-to-business services. Indeed, in this case the long time-frame, the technical complexity of the service infrastructure and the number of actors involved modify the prototyping process. In this perspective the remote assistance case highlights three points.

Firstly, the prototyping process we described for the remote assistance was both lengthy and very close to the operational service (supposing a fair amount of investments both in terms of time and financial resources). It was nonetheless evaluated as both successful and rather innovative. We thus demonstrated that “product-type”, prototyping with demonstrators and prototypes were very much applicable to service design.

Secondly, through the case study of remote assistance we have presented the successive iterations of the service concept. Conducting such a long-term prototyping process was a conscious choice with the aim of integrating the service prototyping project into the day-to-day live environment of the pilot customer. We have shown that doing so has provided a better understanding of customer requirements and has led to significant evolutions of the service concept. Therefore, we argued that concept ideation is not limited either to the exploratory function of prototypes or to the earliest phases of prototyping.

Finally, from the very start of this lengthy process, and throughout all its stages, a large number of stakeholders (including crew members, warship commanders, members of the Joint Chiefs of Staff, manufacturers and subcontractors) have all been involved in, and associated with, the prototyping process. By interlinking the roles of co-designers, promoters and decision-makers, the prototyping process has been a determining vector in the construction of the “live” service environment as it should be implemented. Here again we have shown that this has contributed to resolving certain technical and organisational difficulties, and promoting innovation within the concept of service. This social dimension of the prototyping process is fundamental when dealing with business-to-business services involving large organizations. It goes beyond the “communication” function of prototyping frequently mentioned in the literature. Here the prototyping process plays a “conscription” role 85(Henderson, 1999). It helps recruit the network that will support the future operational service.

The remote assistance case thus provides important insight for service design when confronted with complex business-to-business services. This, of course, is only a first step. The case was probably excessively complex due to its military nature, which implies very high reliability and secrecy constraints (in particular in telecommunication network). No doubt that further research is needed in this important and, until now, neglected area.

86

Appendix i

Technical support with and without remote assistance

87

Appendix II

Typical configuration of a remote assistance room

88

References

Abramovici M., and Bancel-Charensol L. (2004), “How to take customers into consideration in service innovation projects”, The Service Industries Journal, vol. 24, no 1, p. 56-78.

Ben Mahmoud-Jouini S., Midler C., Cruz V. and Gaudron N. (2014), “Creative artefacts. How stimulators, demonstrators and prototypes contribute to the creative processes?”, Proceedings of the Academy of Management, Philadelphia, USA, August.

Bertoni M., Panarotto M., and Larsson T. C. (2016), “Boundary objects for PSS Design”, Procedia CIRP, Elsevier B.V., vol. 47, p. 329-334.

Blomkvist J. (2011), Conceptualising prototypes in service design, Licenciate of Philosophy Thesis (No 101), Linköping University (Sweden), Faculty of Arts and Sciences.

Blomkvist J., and Holmlid S. (2010), “Service prototyping according to service design practitioners”, Conference Proceedings, ServDes 2010, “Exchanging Knowledge”, Linköping (Sweden), Linköping University Electronic Press, 1-3 December.

Brown T. (2008), “Design thinking”, Harvard Business Review, vol. 86, no 6, p. 84-92.

Carlile P. R. (2002), “A pragmatic view of knowledge and boundaries: boundary objects in new product development”, Organization Science, vol. 13, no 4, p. 442-455.

David A. (2000), « La Recherche-Intervention, cadre général pour la recherche en management », Les Nouvelles fondations des sciences de gestion, Paris, Vuibert/FNEGE, p. 193-213.

Eisenhardt K. (1989), “Building theories from case study research”, The Academy of Management Review, vol. 14, no 4, p. 532-550.

Exner K., Damerau T. and Stark R. (2016), “Innovation in Product-Service System engineering based on early customer integration and prototyping”, Procedia CIRP, Elsevier B.V, vol. 47, p. 30-35.

Gallouj F. and Weinstein O. (1997), “Innovation in services”, Research Policy, vol. 26, no 4-5, p. 537-556.

Henderson K. (1999), On line and on paper, visual representations, visual culture, and computer graphics in design engineering, Cambridge, USA-MA, The MIT Press.

Houde S. and Hill C. (1997), “What to prototypes prototype?”, in Helander M., Landauer P. and Prabhu P. (Eds.), Handbook of human-computer interaction, North Holland, Elsevier Science B.V, p. 367-380.

89

Iansiti M., and Levien R. (2004), The keystone advantage: what the new dynamics of business ecosystems means for strategy, innovation and sustainablility, Boston (USA), Harvard Business School Press.

Jeantet A., Tiger H., Vinck D. and Tichkiewitch S. (1996), « La Coordination par les objets dans les équipes intégrées de conception produit », in De Terssac G. and Friedberg E. (Eds.), Coopération et conception, Toulouse (France), Éditions Octares, p. 87-100.

Junginger S. (2008), “Product development as a vehicule for organizational change”, Design Issues, vol. 24, no 1, p. 26-35.

Latour B., Mauguin P., and Weil G. (1990), « Comment suivre les innovations ? le graphe socio-technique ? », Annales des mines, no 20, p. 62-79.

Lewin R., and Regine B. (1999), “On the edge in the world of business”, in Lewin R. (ed.), Complexity: life at the edge of chaos, Chicago (USA), The University of Chicago Press, p. 197-211.

Lim Y.-K., Stolterman E., and Tenenberg J. (2008), “The anatomy of prototypes: prototypes as filters, prototypes as manifestation of design ideas”, ACM Transactions on Computer-Human Interaction, vol. 15, no 2, p. 1-27.

Lovelock C., Gummesson E. (2004), “Wither services marketing? In search of a new paradigm and fresh perspectives”, Journal of Service Research, vol. 7, no 1, p. 20-41.

Miles M. B., and Huberman A. M. (1994), Qualitative data analysis: An expanded sourcebook (2d ed.), Thousand Oaks, CA, US, Sage Publications, Inc.

Mitleton-Kelly E. (2003), “Ten principles of complexity and enabling infrastructures”, in Mitleton-Kelly E. (ed.), Complex systems and evolutionary perspectives on organisations, Amsterdam (Nl), Pergamon, p. 23-50.

Moore J. F. (1996), The death of competition: leadership and strategy in the age of business ecosystems, New-York (USA), HarperCollins Publishers.

Passera S., Härkkäinen H., and Reetta M. (2012), “When, how, why prototyping? A practical framework for service development”, Ispim Conference Proceedings, The International society for professional innovation Management, Barcelona, Spain, 17-20 June.

Rhinow H., Köppen E., and Meinel C. (2012), “Prototypes as boundary objects in innovation processes”, Proceedings of the 2012 international conference on design research society, Bangkok, Thailand, July.

Ries E. (2011), The Lean startup: how today’s entrepreneurs use continuous innovation to create radically successful businesses, New York, Crown Publishing Group.

Scheuing E. E., Johnson E. M. (1989), “A proposed model for new service development”, The Journal of Services Marketing, vol. 3, no 2, p. 25-34.

Shostack L. G. (1992), “Understanding services through blueprinting”, in Swartz T.A., Bowen D. E. and Brown S. W. (eds), Advances in services marketing and management, Greenwich, CT, JAI Press Inc., p. 75-90.

90

Star S. L., and Griesemer J. R. (1989), “Institutional ecology, ‘translation’ and boundary objects: amateurs and professionals in Berkely’s museum of vertebrate zoology”, Social Studies of Science, vol. 19, no 3, p. 387-420.

Thomke S. (2003a), Experimentation matters, Boston, USA-MA, Harvard Business School Press.

Thomke S. (2003b), “R&D comes to services: Bank of America’s pathbreaking experiment”, Harvard Business Review, vol. 81, no 4, p. 70-79.

Vargo S. L., and Lusch R. E. (2010), “From repeat patronage to value co-creation in service ecosystems: a transcending conceptualization of relationship”, Journal of Business Market Management, vol. 4, no 4, p. 169-179.

Weick K. E., & Sutcliffe K. M. (2007), Managing the unexpected: resilient performance in an age of uncertainty (2d Edition), San Francisco (USA), John Wiley & Sons.

Yin R. K. (2009), Case study research: design and methods (4th Edition), London, Sage.