Alexis Nicolaÿ
email: alexis.nicolay@polytechnique.edu

Sylvain Lenfle

EXPERIMENTING AND PROTOTYPING TO DESIGN COMPLEX SERVICES -THE REMOTE ASSISTANCE CASE STUDY

Keywords: Complex services, service conception, service prototyping, service value proposition, service ecosystem, remote assistance, case study, longitudinal case

This article presents a longitudinal study setting out the prototyping process implemented between March 2013 and December 2016 to develop a new service: remote assistance. This form of prototyping is original on several accounts: its duration, the degree of co-design alongside the pilot customer (the French Navy) and the proximity between the individual component parts of the prototype (artefacts, environments and processes) and the 'live' service that has become apparent. This prototyping contrasts significantly with the vision of Rapid Prototyping. We demonstrate that, in addition to facilitating the emergence of a service solution, it also enables the service concept to be developed (in terms of the value proposition) in ways that achieve a much closer match to customer requirements. Lastly, we show that it enables the introduction of a true service ecosystem and promotes committed involvement in it.

INTRODUCTION

Imagine a North Sea oil platform producing several hundred thousand barrels of oil per week. Or an aircraft carrier: a military, strategic and political resource owned and operated by only the largest armed forces. Both are extremely complex systems in which even the slightest malfunction could have terrifying consequences, especially in terms of safety and the environment.

The article we are now introducing describes the first steps towards a new service: remote assistance in a military context. More specifically, we show how an atypical prototyping process has been implemented to enable the co-design of this service, whose complexity is a direct function of its environment. Indeed, remote assistance is to be implemented to what Karl Weick & Kathleen Sutcliffe (2011) among otherscall High Reliability Organizations or HROs. Here, combat ships. We argue that prototyping is a way to answer to what Lynn Shostack (1991, p.75) states as one of the most difficult aspect in dealing with a service: describing it.

In this contribution, we begin by describing the conceptual framework surrounding the case study before going on to present it in detail. In a first section, we outline a vision of the goals and resources of prototyping. In doing so, we will not confine ourselves to taking simply a 'service' approach, but will extend our investigations into the 'product' world. More specifically, we will introduce the model produced by Sihem Jouini and her colleagues (2014), which makes a distinction between stimulators, demonstrators and prototypes.

In the second and third sections, we successively present the broad outlines, followed by the detailed prototyping process for the case study at the heart of this article: remote assistance. This service project is innovative for both the customer and the service provider. It encompasses technical and organisational problems that could not have been overcome without the prototyping process we describe.

In the fourth and final section, we discuss the lessons of this case history and its contributions from the theoretical point of view and the practical takeaways for the designers of complex services in general. On this subject, we highlight three key points.

Firstly, we present a prototyping approach rarely -if ever -applied to services. The originality of this approach can be seen in three ways:

-The prototyping period (around four years); -An incremental prototyping which, in its final phases can be characterised in almost all its aspects as being very close to the 'live' service as it would be implemented; -The very close involvement of the pilot customer as co-designer of the service from the very earliest stages of the project. These three original features set our case study significantly apart from the dominant visionespecially in design thinking -of rapid prototyping (e.g. [START_REF] Brown | Design Thinking[END_REF].

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. In doing so, we show that the exploratory aspect of prototyping is not confined solely to the initial stages of design.

Lastly, we describe the role of prototyping in constructing the service ecosystem (in the sense of [START_REF] Mitleton-Kelly | Ten Principles of Complexity and Enabling Infrastructures[END_REF]. Rarely described beyond the prototype communication function, this role nevertheless played a decisive part during the design process and in gaining the commitment of the customer beyond the prototyping stage.

THEORETICAL SCOPING: PROTOTYPING FOR COMPLEX SERVICES

In this first section, we begin with a brief review of literature as the basis for understanding the concept of service prototyping. In the second section, we introduce the goals and basic approach that lie at the heart of this contribution: the case study that we develop in subsequent sections.

1.1

What is prototyping? The theoretical approach

In the literature, whether product-focused or service-focused, and although grey areas still remain, the issue of prototyping has been amply studied. The broadest definition of what a prototype should be is certainly that adopted by 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. [START_REF] Jeantet | La coordination par les objets dans les équipes intégrées de conception produit[END_REF][START_REF] Junginger | Product Development as a vehicule for Organizational Change[END_REF], LIM et al., 2008, etc.). From a service perspective, as part of his doctoral research project, Johan Blomkvist (2011) provided a detailed analysis of definitions for prototyping and prototypes. He says that "prototypes [...] are the representations of ideas and the artefacts that designers use when prototyping" (p.54). The author believes that three elements identified by himself in the majority of definitions constitute the definition of a prototype: -Prototypes are representations, embodiments or manifestations; -They represent ideas described as hypotheses or assumptions about the future; -Prototypes must enable these ideas to be tested in order to evaluate the degree to which they succeed in meeting the specified criteria.

The literature on New Product Development (NPD) and Product Design identifies three key roles for prototyping in the product design phase2 [START_REF] Rhinow | Prototypes as boundary objects in innovation processes[END_REF]. The first of these roles relates to exploration. By assisting in visualising the object that is the focus for exploration, the prototype facilitates a more effective convergence of effort between the contributors to the prototyping process. The second role is that of supporting evaluation. Enabling users to experience the product provides the designer with feedback that improves the overall understanding of user requirements and expectations, allows ideas to be tested and involves users in the design process. Lastly, the third role of prototyping as identified by Rhinow et al. (ibid.) relates to communication. The author then describes a system that brings team members closer together by 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. [START_REF] Houde | Chapter 16 -What to Prototypes Prototype[END_REF].

The same considerations appear in service-related literature addressing the issue of prototyping. Johan Blomkvist & Stefan Holmlid (2010, p.5) 3 divide the usefulness of prototyping between communication and learning. 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. (ibid.). So for services, as with products, prototyping therefore has three main aims: exploration, evaluation and communication.

As the brief overview of the 'product' and 'services' prototyping literature shows, the initial impression is that there are no major differences between these two worlds. In fact, the key prototyping goals identified apply equally to products and services. Readers will also note that Tim [START_REF] Brown | Design Thinking[END_REF], the man who gave us the definition of prototyping at the beginning of this section, makes no differentiation between service and product prototyping. The author simply emphasises that although prototypes of a service innovation are not necessarily physical, they must nevertheless be tangible. In this respect, he recommends filming the service prototyping process to materialise the 'experiment' conducted.

We have discussed the purposes of prototyping, so let us turn now to its resources. In the following paragraphs, we present a characterisation of prototyping artefacts developed by Sihem Ben Mahmoud-Jouini and her colleagues (2014). Although developed 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 they apply perfectly to the development of complex services.

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 following table presents these functions.

As the table above shows, 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 [...]". They 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 the exploration and demonstrate the progress made as the basis for identifying "an integrated feasible and relevant solution". 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. Positioned 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.

Process of demonstration

As part of this case study, we report on the involvement of one of the authors as part of the actionresearch project [START_REF] David | La recherche-intervention, cadre général pour la recherche en management[END_REF] forming part of his doctoral studies. The lead author was a hands-on 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 rest of this contribution is essentially an overview and discussion of a longitudinal case study [START_REF] Yin | Case Study Research: Design and Methods[END_REF] of the prototyping process for a new military service: remote assistance. In light of the review of literature presented in the previous section, we will demonstrate 1) the relevance of the complex service design model developed by Jouini et al. (op.cit.); 2) the originality of the remote assistance case study relative to the main contributions on service prototyping; and lastly 3) the contribution made by this case study in terms of theory and the practice of professionals.

The choice of a longitudinal case study is dictated by a number of considerations. The first is the period covered by the case study: around four years between March 2014 and December 2016. The many events we refer to and the changes seen in the service concept and prototyping methods used necessitate a clear and long-term view in order to establish consistency. Such a lengthy period is also fairly unusual in service prototyping. A longitudinal study was the only way of retracing those contours.

The second aspect is the complexity of the network of the 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 considered to be a single entity. In the case study, we make reference to all the contributors (departments and entities of the French defence ministry) within the confidentiality limitations permitted by this sector. Here again, referring to the diversity of contributors without referencing the narrative within its overall timeframe would have been prejudicial.

OUTLINES OF THE REMOTE ASSISTANCE CASE STUDY

This section begins by setting out the background basics of the remote assistance service from the customer and service provider perspectives. We then present the service resources that emerged from the prototyping approach adopted. The goal of this section is to show the reader the aim of the prototyping approach and the complexity of the service to be designed.

Technical assistance without remote assistance

To fully understand why the remote assistance service is relevant, it is important to understand the 'traditional' structure of support provided to military forces engaged in operations in the event of an equipment failure or incident (grouped together under the term 'technical event', which we will use from this point of the case study onwards). For this purpose, we will take the fictional example of a technical event occurring on a ship on operational duty off the Arabic Peninsula (cf. Figure 1, below).

On-board a warship, the crew provides the first line of technical expertise. When crew members find themselves confronted by a malfunction whose cause they cannot diagnose themselves or which cannot be repaired with the resources and skills available on board, this is the point where the technical support procedure is triggered to involve the manufacturer in resolving the technical event.

The formal commencement of this procedure is the issue of a report sheet describing the technical event, its circumstances, etc.

Where the equipment failure proves severe enough to justify such action, the warship must 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.

For the manufacturer, the technical event report sheet is the starting point for preparing a technical support assignment. Personnel with specialised knowledge of the equipment concerned identify a number of possible causes, and prepare the resources needed to confirm the diagnostic evaluation and carry out the repair. They then travel to the port to which the warship has returned (Djibouti in our example). The repair work proper then begins. In some instances, the diagnosis and resolution of a technical event can be completed in less than two hours. On completion of repairs, the warship returns to its operational area (another passage of 72 hours in our example).

With such an organisational structure, it could take the warship away from its mission for longer than a week purely to undergo repair or maintenance work taking a few hours at most. Downtime on this scale clearly has a financial cost, but more importantly, it also has an operational cost. A warship leaving a theatre of operations leaves a gap in military capability. At best, this gap can be filled by another vessel (again at a cost); at worst, it may compromise the mission or put other operational warships in danger.

Lastly, the cost of the technical response assignment itself, especially in terms of the travel and accommodation costs of a team made up of two, three or four people over a period of several days, can very quickly mount up to a significant amount.

Remote assistance makes it possible to drastically reduce ship downtime. Better still, it avoids the need for the vessel to leave the theatre of operations, thereby limiting the operational cost. Lastly, it may avoid the need for costly on-site technical support where the equipment failure concerned can be effectively resolved by the crew.

Source: The authors

Remote assistance resources

As we said earlier, the first line of technical expertise is that of the operational navy crew. The second line of expertise is also military. It is represented by the home-based services responsible for equipment maintenance. This second line of expertise is fundamentally essential given that specialised knowledge is sometimes scarce aboard certain warships. This situation is a direct result of the high levels of automation found on some warships, which has considerably reduced crew sizes. Lastly, the third line of expertise is that of the manufacturer.

Remote assistance consists of linking all three of these lines of expertise and providing them with the communication resources required to conduct -insofar as is possible -a diagnostic analysis of a technical fact, and resolve the issues involved without the need to send out technical support, and without the warship having to leave its theatre of operations. Given the nature of the information exchanged, these communications must be highly secure.

The general operating principle of remote assistance is summarised in the following diagram:

For remote assistance, military hardware earmarked for operational use is fitted with a 'deployable kit'. This kit takes the form of audio and optical equipment (cameras, boroscopes, Google glasses, etc.), and communication resources and protection 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 buildings and manufacturer premises. The following diagram shows the typical configuration of such a facility and the main items of equipment used:

Source: The authors

Figure 2 -The operating principle of remote assistance

The majority of the hardware items contained in deployable kits and/or remote assistance rooms are commercially available off-the-shelf solutions. Although the networking and cryptography resources required are of a higher level of complexity, the necessary technical skills and resources already exist within the armed forces (and are often exclusive to them) or can be sourced from specialist service providers.

The underlying technical solution for providing remote assistance is therefore well understood and relatively mature. Nevertheless, extensive experimentation campaigns have been conducted to succeed in building such systems. The experiments set out to resolve a number of technical and organisational unknowns, at the same time as demonstrating the value of such a service to potential customers. As such, it is very much a service prototyping process. We present this process in the next section.

THE REMOTE ASSISTANCE PROTOTYPING PROCESS

The timeline shown in Appendix 1 sets out the sequence of events leading up to implementation of the remote assistance project proper from July 2016 onwards. The author first became involved in the project in November 2014.

We identify four major stages within this timeline. In the model produced by Sihem Ben Mahmoud Jouini et al. (op.cit., cf. Table 1), these correspond to the four final stages of the development process: We present these four stages in the paragraphs that follow.

Concept selection: the initial experiments

From a design viewpoint, remote assistance is a remarkable project in the sense that from its very inception, the service has been co-designed with a pilot customer: the French Navy. As soon as the Source: The authors internal company funding was allocated at the start of 2013, contact was made in order to present a remote assistance service project, to include a demonstration element.

To establish that cooperation, a number of formal and informal meetings were held involving representatives of the manufacturer and 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 information systems security considerations. Without these decisions taken at a high level within the Ministry of Defence, the prototyping process we are now describing would not have been possible. In this context, the manufacturer's project teams highlight the decisive role played by a naval officer in championing the case of remote assistance to the military hierarchy. The presence of many former military personnel within the company was also a determining factor for the establishment of successful dialogue.

Two experiments were conducted during this first development phase.

The first was conducted on the manufacturer's premises in April 2014. As a result, two out of six possible deployable kit solutions were adopted (cf. Figure 2): -One solution is based on a single item of equipment with integral optics and software interface similar in appearance to an SLR camera (limiting the hands-free aspect); -The other is a tablet-based software interface interacting with a number of optical accessories (a more modular solution). Demonstrations of both solutions have been conducted in the presence of French Navy representatives.

The experimental protocol was limited to simply 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. This was the basis for the decision on which hardware should be included in the deployable kits in the subsequent prototyping phases.

The second experiment was conducted approximately six months later in October 2014. It was conducted onboard a naval vessel alongside in the Brest naval base. This demonstration replicated the system implemented at the manufacturer's premises, and was therefore not intended to demonstrate new functionalities. Its major challenge was to measure the constraints imposed by the onboard environment: narrow passages and companionways, confined spaces, unlit spaces, etc. This conclusive demonstration was a decisive step for remote assistance inasmuch as it gave the crew a clear impression of how remote assistance could contribute to their onboard operations.

The two experiments summarised above are a perfect match for the description of the role played by demonstrators in the initial phases of development given in the model developed by Sihem Ben-Mahmoud Jouini et al. (op.cit., see previous section): "Provide a relevant empirical support to analyse and select different innovation concepts". We also note that all three key functions of prototypingexploration, evaluation and communicationwhere instrumental in this first phase, as in the following ones. Beyond confirming the validity of both Jouini's model and the key features of prototyping, we here clearly inscribe our case study as a prototyping one.

It was following this initial phase of experimentation that a preliminary definition of the remote assistance value offer was developed. It took the following form: "To provide a channel for delivering the manufacturer expertise required to enable remote diagnostic analysis and guided responses"4 . This value proposition reflects a very "technical" acceptance of remote assistance. As we will see, the description of this vision was broadened significantly during the experimental period.

Concept development: the sea trials campaign

As we said earlier, the network aspects were not addressed by the initial experiments. It is worth repeating that remote assistance interfaces two networks:

-A military network in which a satellite link between the warship on operational duty and an onshore military base is key ; -A specific or (secure) Internet-based network connecting the military base with the manufacturer facilities. The networks form a critical component of remote assistance both in technical terms (configuration, encryption, etc.) and in terms of use: 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 campaign of experiments to resolve these uncertainties.

Two types of test were planned for the campaign run in April 2015: trials conducted alongside in the Port of Toulon and sea trials. Since the remote assistance demonstrator had to be connected to the French navy network to enable these trials to take place, it was first essential to demonstrate its network safety and obtain permission from the military authorities. For this purpose, a security test was conducted using a reference platform to replicate the network. The aims of this second phase of experimentation were as follows 5 :

-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 improvements 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.

Again, it is very apparent that exploration, evaluation and communication goals where explicitly assigned to this phase of the prototyping process.

As a result of the various constraints imposed by the French warship selected to take part in the experiment, the campaign was concentrated into eight days. The dockside tests were conducted during the first five days. These tests consisted of linking 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, the satellite link was used to conduct five test 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 onboard the ship, and another onshore.

This test campaign generated a very comprehensive body of 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 staff responsible for the tests noted that:

"We had a positive response from [shore-based] Naval personnel. Onboard [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 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".

Once again, the demonstrator used during this testing campaign played precisely the role identified by Sihem [START_REF] Ben | Creative artefacts. How stimulators, demonstrators and prototypes contribute to the creative process[END_REF] see Table 1): [to] "provide a design context to develop the concept into an innovative integrated solution".

Several months after this experimentation campaign, in July 2015, a second version of the remote assistance value proposition was put forward by the manufacturer. This places remote assistance within a broader concept of being an "extended support service for surface warships". Compared with 5 These aims originated in the experimental protocol drafted by the manufacturer the first form of the value proposal 6 , the second version puts less emphasis on the technical benefits of remote assistance. Based on an idea of permanent technical support availability, remote assistance is combined with two other service propositions (not developed in this contribution). This change clearly reflects that:

-The manufacturer teams had a more detailed understanding of the mechanisms at work in the remote assistance service (beyond its technical aspects); -The end users (in this case, the French Navy) had embraced the concept of remote assistance having experienced it.

Solution evaluation and validation: end-to-end testing

The third part of the remote assistance prototyping process consisted of 'plugging in' the manufacturer 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 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 working 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 defence Ministry authorities 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 context. This 3'09'' video has no voiceover, and illustrates how remote assistance can deliver technical support by focusing on:

-The process stakeholders -The system functions -The procedures implemented to repair malfunctions rapidly The majority of this video was shot during the sea trials campaign conducted in April 2015. It therefore presents remote assistance in its true environment. The video successfully fixed an image of the remote assistance concept in the minds of the French Navy and the organisational structure 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.

The experiment was conducted in October 2015. It consisted of establishing communication between a warship (via satellite), the Brest naval base and one of the manufacturer's facilities. Again, this demonstrator fulfilled the purpose described by Jouini et al.: [to] "provide a design context to experiment and validate an innovative integrated solution".

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 onboard two warships for an initial period of six months. A second agreement signed in June 2016 extended the experimental programme to include a further warship, and extended the period by a further six months.

Under the terms of this agreement, the manufacturer provided the French Navy with two remote assistance kits and crew training support. The goal was to enable the pilot customer to gain hands-on experience of the remote assistance system, which had previously been operated almost exclusively by the manufacturer's own employees. This approach perfectly fulfils the criterion of prototype utility defined by Jouini et al (2014): [to] "Provide a tool for testing the adequation of the developed solution to the specifications". 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 on the manufacturer's premises for the purposes of the experimental programme. The following photograph shows this prototype remote assistance room.

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 on one of its systems. The crew were not able to identify the cause of the problem. Contacted initially by phone, the remote 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 procedure ("even if it is not the ultimate solution") and avoid causing further problems as a result of ineffective attempts at repair. On the other hand, they note that the level of pressure imposed on the vessel's crew fell significantly the moment that the connection was made. More specifically, they had the following to say on this same subject: "the crew members are reassured to have someone to speak to, but it is still important to build trust". They see the ability to use the same terminology and have a clear understanding of the constraints that apply onboard 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 fact that the technical assistants were not physically present and therefore were not subject to the stressful situation onboard made it easier to assess the issues involved.

The success of this response very definitely demonstrated the feasibility and value of the remote assistance service. A letter of thanks from the Chief of Naval Staff to the Chairman and CEO of the manufacturer underlines the impact that this response had at the highest levels of the military.

In March 2016 (when the long-term experimental programme had been in place for three months), a third version of the remote assistance value proposition was issued by the manufacturer. The definition refers to offering "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".

So by this point, remote assistance is no longer seen as simply a user need, but as a way of improving the existing support service. This new value proposition reflects a more general overview of the Source: The manufacturer Figure 4 -A (prototype) remote assistance room remote assistance concept to address the fundamental need of users for hardware availability. In other words, remote assistance should contribute to a situation where users have the equipment required to deliver their missions. In the broader sense, hardware support is no longer seen as an end in itself, but as a resource available to the armed forces. We should emphasise that, 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 codesign involvement is a clear indication that the experimental programme has enabled all its stakeholders to arrive at a shared understanding of the potential benefits of the service within the customer's live operational environment.

DISCUSSION OF THE CASE STUDY AND ITS CONTRIBUTIONS

A prototyping approach rarely applied to services

The experimental process we have described differs significantly from most of the service prototyping case studies described in existing literature. We identify three largely interdependent aspects that make the case history we have presented particularly original:

-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

A long-term experimental programme

First and foremost, this prototype was tested using a series of experiments conducted over a fairly long period of time. Covering the period between March 2013 and December 2016, the prototyping process took approximately three years and nine months in total. This is very different to the relative dominance of the rapid prototyping mindset, which is especially prevalent in design thinking. As demonstrated by Tim [START_REF] Brown | Design Thinking[END_REF], this refers to the view 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 viewpoint. Our prototyping approach has sought to gain experience in conditions as close as possible to those of the 'live' service, and focused on lengthy testing campaigns. The example provided by the fourth phase of experimentation that we refer 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 to make the benefits of remote assistance available to warship crews, and for them to gain experience of it under live operational conditions.

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

Continuing 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 relate to the notion of fidelity as described by Stepahn Thomke (2003, p.7). Stefania Passera and her colleagues (2012) also speak of fidelity / resolution in their SPPF (Service Prototyping Practical Framework). 7 The relationships between SPPF components are shown in the Appendix 2 diagram. 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 7 It will also be noted that the authors make explicit reference to Brown (op.cit) and RIES (2011, not referenced). They stress that "Well-designed, small-scale prototypes are an efficient way to learn and test specific hypotheses of new concepts, but there is not a single way to 'do it right'".

the "general level of verisimilitude of the service prototype" (the sum total of the fidelity of distinct aspects). They illustrate this difference as follows:

The following table charts the six stages of the prototype as presented by ourselves 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. The functions of the individual prototyping artefacts at each stage in the development process as defined by Sihem Ben-Mahmoud Jouini et al. (2014, cf. Table 1) are shown at the bottom of the table. This table provides an effective illustration of the complementary nature, progression 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' [START_REF] Star | Institutional Ecology, 'Translation' and Boundary Objects: Amateurs and Professionals in Berkely's Museum of Vertebrate Zoology[END_REF][START_REF] Carlile | A Pragmatic View of Knowledge and Boundaries: Boundary Objects in New Product Development[END_REF] between the onboard world and that of the onshore support function (particularly for the manufacturer). As Carlile (ibid.,p.452) Many authors highlight the role of these boundary objects in the development of new service concepts generally, and prototyping in particular (e.g. [START_REF] Bertoni | Boundary Objects for PSS design[END_REF][START_REF] Exner | Innovation in Product-Service System Engineering based on early customer integration and prototyping[END_REF]. It is in this context that the remote assistance kits were the subject of particularly close attention from the initial phases of remote assistance prototyping. A number of demonstrators comprising the deployable kits only were experimented with both by warship crews and the manufacturer's technical assistants before a single solution was stabilised for use 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 in which 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 also followed the Jouini et al. (2014) model stage-forstage, 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.

In terms of resolution and fidelity, this provokes two 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 the authors stress (PASSERA et al., 2012, p. 9), there is no consensus in the literature regarding the optimum level of resolution for a prototype. The case study we are developing here provides something of an answer: 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.

Very close customer involvement in the prototyping process

Lastly, the third original feature of the prototyping process we have described is the level of pilot 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 achieves consensus in the literature, both for products and services. On the other hand, the desirable degree of involvement varies from author to author. Stephan Thomke's article of 2003 published in the Harvard Business Review on the prototyping process used by Bank of America is one of the most cited in the context of 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 (TOMKE, 2003, pp.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. (op.cit.) include the audience as one of the factors in their Service Prototyping Practical Framework (cf. Appendix 2). The authors make clear that the prototype should be designed from the outset with the target audience in 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. Appendix 1) shows, the pilot customer (the French Navy) 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 experimental. This, again, sets us apart from the dominant vision of prototyping.

Innovative service concept generation through prototyping

As we have said in the first part of this contribution, the three key roles of prototyping are exploration, evaluation and communication [START_REF] Houde | Chapter 16 -What to Prototypes Prototype[END_REF]BLOMKVIST & HOLMLID, 2010 ;[START_REF] Rhinow | Prototypes as boundary objects in innovation processes[END_REF]. 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 this service concept evolves with the prototyping process 9 : 1. November 2014: "To provide a channel for delivering the manufacturer 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". This evolution demonstrates a widening and more general approach to the remote assistance service offer, moving away from an approach focused on remote assistance as a 'delivery channel' towards the integration of the same remote assistance service 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 evolutionary change between 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 in order to significantly improve the capability of the customer to successfully deliver its missions.

We argue that to achieve this innovative vision of remote assistance, all three functionsi.e. exploration, but also evaluation and communicationhad 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. [START_REF] Thomke | R&D Comes to Services: Bank of America's Pathbreaking Experiment[END_REF]. In Jouni's et al. (2012) "phases of the creative process" (see Table 1) "inspiration" and "ideation (concept generation)" are the two first ones. They are supported by "stimulators" which 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 show no use of "stimulators"; but our sequence of value propositions shows that the functions of stimulators where carried out by the demonstrators and prototypes.

4.3

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 in the main by the Naval 'workforce': vessel commanders (the 'pashas'), the crew members responsible for shipboard maintenance and operation of weapon systems, the onshore support teams, etc. All contributed their operational experience to arrive at a clearer definition of requirements in terms of functionality and operational constraints. As experts in their own vessels, these are the same people who facilitated the experimentation process onboard the warships concerned.

The second role is that of promoting the value of the remote assistance service to decision-making bodies. The operational personnel clearly have a critical level of influence in this role. The ultimate power onboard their own vessels, the opinion of the 'pashas' is paid very close attention at Naval Staff level. The same is true of the 'Programme Officers' (POs). For every major weapons programme, these POs are responsible for ensuring that the functions delivered (in this case, those of a warship) respond fully to the requirements expressed by the Naval Staff. They act as a kind of drive belt connecting operational personnel with the Naval Staff. This 'drive belt' was a decisive factor in favour of remote assistance.

The third and last role is that of decision-maker. This role can be very clearly seen in the timeline of the remote assistance prototyping process (cf. Appendix 1), 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 dockside, these decisions were required between every two stages of the experimental programme. The military hierarchy is structured such that once a decision has been made, implementing it is greatly facilitated.

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, a good 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[START_REF] Bertoni | Boundary Objects for PSS design[END_REF]. In a wider context, the terms Business Ecosystem (e.g. [START_REF] Moore | The death of competition: leadership and strategy in the age of business ecosystems[END_REF][START_REF] Lewin | On the edge in the world of business[END_REF], IANSITI & LEVIEN, 2004) and Social Ecosystem (e.g. [START_REF] Mitleton-Kelly | Ten Principles of Complexity and Enabling Infrastructures[END_REF] 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 network, 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 in 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 highranking 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 depict the progressively growing ecosystem in the following Figure 6. There, we highlight that, in the manner depicted in Bruno Latour's et.al. (1990) "socio-technical graphs", the evolution of the different demonstrators and prototypes allowed to rally more and more 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 [START_REF] Houde | Chapter 16 -What to Prototypes Prototype[END_REF]. The buy-in was achieved mostly by the interlinkage of codesigners, 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. In any event, during the long-term experimental programme that constituted the final stage of the prototyping process, almost all the stakeholders concerned with co-designing and co-producing the 'live' service were involved.

CONCLUSION

There remains a great deal more to be said on the subject of remote assistance. We have limited ourselves to exploring the prototyping process, and even within the scope of that exploration, there is a good argument to be made that we have not covered every issue. The subsequent stages of the project, in which the lessons learned from the prototyping stage will form the basis for a service contract, will be every bit as fascinating and instructive.

So by way of a conclusion, we will summarise the lessons learned from the case study as developed and discussed here. These lessons contrast with a vision put forward largely by certain authors on the subject of design thinking (e.g. [START_REF] Brown | Design Thinking[END_REF], according to which 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.

Firstly, the prototyping process we described for the remote assistance was both lengthy and very close to the 'live' 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 further demonstrated that 'heavy', '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 further developed the service concept. Furthermore, we argued that the concept ideation is not limited either to the exploratory function of prototypes nor to the earliest phases of prototyping.

From the very start of this lengthy process and throughout 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.

Figure 1 -

 1 Figure 1 -Technical support with and without remote assistance

  1. Concept selection: the initial experiments 2. Concept development: the sea trials campaign 3. Solution evaluation and validation: end-to-end testing 4. Development of the solution into a new service: long-term experimentation

Figure 3 -

 3 Figure 3 -Typical configuration of a remote assistance room

  In the terminology used by PASSERA et al. (ibid.), each 'component' represents a new 'level of detail'.

Figure 5 -

 5 Figure 5 -Fidelity and resolution of a service prototype Source: PASSERA et al., 2012, p.10

  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 knowwhat they worry about -as concretely as possible to the problem at hand."

Figure 6 -

 6 Figure 6 -The building of a service ecosystem Source: PASSERA et al., 2012, p.10

Table 1 -

 1 Prototyping artefactsconcentrated mainly in the concept selection phases and the subsequent development and testing of a solution in response to it.

Their use is Source: JOUINI et al., 2014

This also ledSihem Ben Mahmoud-Jouini et al. (2014) to demonstrate that prototyping is a relatively generic term covering multiform methods and requiring characterisation. We present and use this characterisation of prototyping resources later in this section.

In this article, the authors advance a service practitioner approach by developing 6 case studies. However, the article also refers to other trends in services research (p.2): design theory, management and the systemic approach (especially Product Service Systems or PSSs), and design techniques (such as service blueprinting).

This definition of the remote assistance value offer is taken from an internal company document of November 2014.

For the record, this was: "To provide a channel for delivering the manufacturer expertise required to enable remote diagnostic analysis and guided responses".

In the long-term experiment, we consider that the service procedures are simulated in the sense that they do not form part of a contract, that they have not been stabilised, and that they have never been formally approved by the service stakeholders. The way in which the response of December 2015 proceeded demonstrates that common sense prevailed over formality.

It is worth repeating that we evaluate the evolution of the service concept in the context of the different value propositions developed in parallel with the prototyping process.

LIST OF TABLES AND FIGURES