Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

Servitization takes many forms. But common to all of them is that, to a greater or lesser extent, the relationship with the customer changes, as compared to a ‘base case’ relationship of a manufacturer providing a physical artefact in exchange for a payment. Servitization also changes some of the links between activities within the provider organization or organizations: it may require new activities to be carried out by the manufacturer, or by third-party firms providing complementary elements, and the establishment of new inter-connections between existing activities within the manufacturing firm. It may also increase the number of points of contact between provider(s) and customer, as well as change the nature of those contacts.

The purpose of this chapter is to examine these changing connections and contacts within and between firms, in a servitization context. Our starting point is the fundamental operations management (OM) concept of the process, and the observation that servitization tends to increase the complexity of these processes. Following Simon (1962), we take complexity to be a function of the number of process elements (e.g. actors, activities, tangibles) and the extent to which they are inter-related, and examine this phenomenon in terms of its architecture. As part of this approach, we adopt as our theoretical framework the modularity theory of the firm, more specifically the notion of interfaces as part of that theory (Langlois 2002; Baldwin 2008). By examining interfaces in particular, we aim to complement other studies of the ‘shift to service’ that have emphasised strategy and organizational culture (Baines et al. 2009) and the need for new capabilities (Matthyssens et al. 2009; Ulaga and Reinartz 2011). Our essential argument is that understanding and managing process interfaces helps to both attenuate and manage the complexity that arises from the ‘shift to service’.

2 Processes in Operations Management

Processes have become the central notion of operations management. For example, ‘all operations produce products and services by changing inputs into outputs using an “input-transformation-output” process’ (Slack et al. 2010: 11). Processes can be identified at micro-level—e.g. an individual workstation such as a machine tool—or the very macro e.g. the entire supply chain for the production of a garment—and anything in between.

Construing what happens in a business as an operations process provides a basis for many analytical and practical moves. At the tactical level, the output of the process can be measured to see how it compares to customer requirements or other benchmarks; process capacity and cycle-time can be defined and managed; particular stages of the process can be identified as targets for improvement efforts. At a more strategic level, processes can be chosen or designed so as to be able to excel in one operations performance criterion rather than another—for example, low cost rather than high flexibility—in keeping with the logic of the ‘trade-off’ (DaSilveira and Slack 2001). Processes might also be subjected to pervasive performance improvement initiatives such as ‘lean’.

The difference between manufacturing processes and service processes has been a long-standing topic of discussion in operations management, and this is particularly relevant here, since servitization entails the adoption of more service processes by manufacturing firms. In OM thinking (as in marketing), services used to be distinguished from products on the basis of factors such as ‘intangibility’ (Sasser et al. 1978). More recently, service processes have been defined as those to which the customer provides inputs:

With services, customers are suppliers of significant inputs to the service production process. These inputs include customer minds and selves, customer belongings and/or customer information. (Sampson 2000: 351)

Our concern, then, is how shifting to such processes presents new challenges to manufacturers, and what to do about this. Sampson’s definition of service processes is uncannily similar to Thompson’s classic description and exemplification of so-called reciprocal interdependence between organizational ‘parts’:

A third form of interdependence can be labelled reciprocal, referring to the situation in which the outputs of each become the inputs for the others. This is illustrated by the airline which contains both operations and maintenance units. The production of the maintenance unit is an input for operations, in the form of a serviceable aircraft; and the product (or by-product) of operations is an input for maintenance, in the form of an aircraft needing maintenance. (Thompson 1967: 55)

Reciprocal interdependence, Thompson argues, is the most difficult form of interdependence to co-ordinate (his others being pooled interdependence and sequential interdependence). As such, manufacturers need to find a way to mitigate that difficulty as they shift to service, and we suggest that a focus on interfaces can be a useful part of that endeavour.

3 Modularity and Interfaces

Before considering servitization, it is necessary to set out a little of the background to the notion of interfaces. And to do that, it is necessary to outline some of the concepts of modularity, which, in contemporary management studies, has its roots in the work of Herbert Simon (1962, 1991 [1969]). His conception was of artifacts—humanly sythesised objects, buildings, organizations and more—designed to achieve a purpose, given a particular environment in which to perform. Although he didn’t use the term ‘modular’, he argued that artifacts subject to dynamic environments benefit from ‘near-decomposability’—essentially the same as modularity—whereby each sub-system and sub-sub-system has many interdependent connections between the elements within it, but relatively few connections with elements in other sub-systems. Interestingly for the present discussion, although he didn’t use the term ‘modular’, he did (a little grudgingly, perhaps) introduce the term ‘interface’:

An artifact can be thought of as a meeting-point—an “interface” in today’s terms—between an “inner” environment, the substance and organization of the artefact itself, and an “outer” environment, the surroundings in which it operates. (Simon 1991 [1969]: 6)

‘Interface’ here is used to refer to the whole artifact’s meeting its environment: by extension, we could consider each sub-system or module to be an artifact within an artifact, and each link between these subsystems as interfaces, too.

The potential of Simon’s idea of ‘near-decomposability’ has been extensively used in studies of modular product design (Sanchez and Mahoney 1996; Ulrich 1995), but was formalised and extended to examine the organization of tasks more generally by Baldwin and Clark (1997, 2000). They argue that modular systems design should involve ‘visible design rules’ and ‘hidden design parameters’. The notion of information hiding, derived from computer science, suggests that complexity can be reduced by hiding information about the detailed design and functioning of one module (‘hidden design parameters’), from all other modules, so as to avoid huge information processing costs arising from high levels of interdependence. The ‘visible design rules’, then consist of:

  • ‘architecture, in other words, what modules will be part of the system, and what their roles will be;

  • interfaces, that is, detailed descriptions of how the different modules will interact, including how they will fit together, connect and communicate;

  • standards, for testing a module’s conformity to the design rules…and for measuring one module’s performance relative to another’ (Baldwin and Clark 1997: 86)

The (few) visible design rules are widely communicated, whereas the hidden design parameters are only communicated within the module to which they relate. In this way, modular systems, and the interfaces that are a vital part of them, attenuate complexity.

4 Service Interfaces

As we have seen, modularity and interfaces have been studied in the context of artifacts, products, software and, to some degree, organizations. Although there are also some attempts to apply modularity to service operations, most existing discussions of service modularity only deal with the structural relationships between modules (i.e. the architecture).  For example, we might be concerned with breaking down the total experience of travelling on a cruise ship into its constituent elements: restaurant meals, swimming, entertainment and so on (Voss and Hsuan 2009). The purpose of service modularity on this view is to enable various combinations of these elements (modules) in such a way as to provide a high variety of total experiences while benefiting from economies of scale in the production of each constituent element. Economies of scale result from the organization replicating essentially the same (say) restaurant process module on many different ships. Similarly, various elements of care can be combined in different ways for elderly citizens with different needs (De Blok et al. 2010). In the latter example, the modularity also allows flexible re-specification of an individual client’s service package, as his or her condition and requirements change.

Both of these accounts in fact emphasise the modules much more than the interfaces between them, and acknowledge that service interfaces are as yet poorly understood:

Second there is a need for empirical study in greater detail of particular areas, in particular that of interfaces between modules/services, an area posited as important but where we have little detailed understanding. Outsourced services would provide a powerful base for study of interfaces. (Voss and Hsuan 2009: 560–561)

So, what constitutes the interface in services? Let us explore some of the examples already used, and some others with which we may be familiar. In the examples of cruise liner service (Voss and Hsuan) and in elderly care (De Blok et al. 2010), the module is a subset of the activities provided by the service provider for the benefit of the customer. To the extent that the activities in one subset are independent of activities in any other, they are modularFootnote 1 (Langlois 2002).

When discussing product modularity, what is considered is the end result—the product (e.g. Ulrich 1995), and we consider the physical elements that constitute modules. In the ideal modular product there is a ‘one-to-one mapping from functional elements….to the physical components of the product’ (Ulrich 1995: 422). In the examples of what we will for the time being call services, we are considering a process, in which the customer may or may not play an active part. So what constitutes that service process? It is manifest in the work done by service staff and the physical infrastructure that is used. This is what we have previously (Araujo and Spring 2006), after Gadrey (2000), called a ‘sociotechnical capacity’(STC): customers pay to access a sociotechnical capacity for certain periods of time, on certain terms. For example, an elderly person may pay to attend a day care centre for a three-hour period, temporarily using its facilities and being helped by its staff. Other services are what Gadrey terms ‘requests for intervention’, where the STC is brought to bear on the customer or on entities for which the customer is responsible. For example, a physiotherapist might visit an elderly person in their home to diagnose and treat a particular condition. In both cases, as emphasised by Sampson and Froehle (2006), the customer may (will!) provide inputs of one form or another.

As such then, the service module might be characterised by the people that deliver it and the equipment used and, without an ‘end product’, an important (maybe the only) delineation of the boundaries of a service module is achieved by writing—writing specifications and charters, policies and procedures. Michel Callon (2002) describes such a process of ‘objectification’ in the creation of ‘product-files’ for the definition of service offerings (again, the context is cruises…), and of ‘handbooks’ and ‘bibles’ for the definition of the role of each member of staff in the delivery of the service. These do not just describe the service, they construct it and, in some senses, they are the service. Selviaridis and Spring (2010) analyse the collaborative design of third-party logistics services as periodic temporary stabilizations of what is otherwise a constantly changing set of activities; these stabilizations are achieved in large part through the writing and re-writing of contracts and associated service level agreements.

Take also university education—a modular service familiar to many of us. Modules consist of a set of experiences of teaching and learning. But they are objectified above all by writing: writing module outlines, learning outcomes, assessment elements, reading lists, and are associated with course mnemonics and learning credits. In this way, they are objectified and made manageable (Czarniawska and Mouritsen 2009) in such procedures as timetabling, the award of degrees and the measurement of faculty workloads. They are crisply demarcated in relation to the primary actors they involve by such procedures as registration, which defines who can sit examinations and submit assessed work and, perhaps, who has access to online learning technologies and by the assignment to faculty members of roles such as module coordinators, defining who is responsible for carrying out assessment and teaching. Modules should avoid overlap in content and should collectively offer the possibility of constructing a coherent degree in, say, operations management, while offering some choice to the student.

What of interfaces here? It is inappropriate to apply many of the definitional elements used for product interfaces to something like a degree module. There is not, as in Simon’s definition, a ‘meeting-point’ in time and space. One module does not, in any meaningful way, communicate with another: information is not purposefully transmitted across a boundary in the way that it is in modular products between, say, a personal computer and its printer. Perhaps in this sense the interface only exists in the mind of the participants, in how they (e.g. the students) see a relationship between the content of one module and the content of another. The inter-modular connection is, however, formalised in at least one way—by the definition of pre-requisites i.e. that in order to take module B, a student must have successfully completed module A. But again, this doesn’t involve the transmission of information between modules. It could, however, be seen as involving the transfer of people—or, more generally, service recipients—between modules. Taking into account all these examples, it seems that interfaces in services are elusive and multifaceted phenomena.

5 Some Key Characteristics of Interfaces

Baldwin and Clark’s definition of architecture only explicitly distinguishes between hidden design parameters and visible design rules in terms of whether they are widely or only locally known (i.e. within the module). Later, Baldwin (2008) examines the special case of interfaces that enable transactions, arguing that transactions between firms can best be brought about at ‘thin’ crossing points, where there is very limited interdependence between the activities on one side of the crossing-point and those on the other. Baldwin stresses that such a state of affairs doesn’t just happen, but is achieved through work to define what is to be transferred, and to devise both a basis for counting or measuring it, and a means of remunerating the supplier. This work results in what Baldwin terms ‘mundane transaction costs’, which might be incurred by one firm, by a pair of trading partners, or by a much larger group of organizations.

An illustrative example of the latter is INCOTERMS, the international system for defining the respective rights and responsibilities of buyer and seller in the international shipment of goods. INCOTERMS allow buyer and seller to define, in one three-letter acronym selected from a small range of options (e.g. FOB, standing for “Free on Board”), responsibilities for a range of activities involved in such shipments, including transportation, insurance, loading and unloading. The alternative to using INCOTERMS in such a situation might be for the two trading partners to interactively define, negotiate and agree on the details of each of the activities, from scratch. This would be a ‘thick’ interface.

Puranam and Jacobides (2005) argue that part of the thickness of such interfaces arises from under-specification and the need for ‘rich’ information to deal with ambiguous or subjective issues, which in turn requires a great deal of interaction to define what is to be done. This echoes Thompson’s notion of ‘reciprocal interdependence’.

6 Servitization and Interfaces

Having explored modularity and interfaces in service settings, it is now necessary to return to the focal theme of servitization. Servitization has been defined, discussed and exemplified in Part 1 of this book. For the purposes of this discussion, we will take as a rough organizing scheme the typology of Product-service systems (PSS) of Arnold Tukker (2004), combined with the base case of a completely ‘unservitized’ product sale. Hence we have four models:

  • Product sale

  • Product-oriented PSS

  • Use-oriented PSS

  • Result-oriented PSS

The focus in Tukker is on the nature of the relationship and interaction in the dyad between supplier and customer. Implicitly (and examined more explicitly elsewhere, see Lay et al. (2009)), an important element of the distinction between these categories is rooted in property rights. Interestingly for our present purpose, property rights also plays an important part of Langlois’ treatment of modularity (Langlois 2002) and, by implication, interfaces. The supplier-customer relationship is not the only site of interfaces that we might be concerned about, however. Especially in more complicated servitization contexts, there may be several organizations or organizational units involved in providing a servitized offering to a customer. For example, a supplier of commercial vehicles may outsource field maintenance activities to a network of maintenance providers using a franchise approach (Karatzas 2013), and leading to a triadic structure between the manufacturer, any individual customer, and the relevant service depot (cf. Li and Choi 2009). This leads to more potential interfaces at organizational boundaries.

Interfaces may also be construed between elements of the offering, as well as between organizations or organizational units. In some way, the maintenance service process of our truck manufacturer’s depot will come into contact with the trucks to be maintained; one might even say that the maintenance process comes into contact with the process in which the truck is used. This will have a structural aspect, dealing in effect with the division of labour and the rights and responsibilities of each party (e.g. the customer carries out routine checks on tyre pressure, but the provider arranges for and pays for longer-term tyre monitoring and replacement). It will also have a processual aspect, which is concerned with where and when the activities that connect the two modules are carried out (e.g. the depot staff have to schedule tyre replacement events for when the truck is not being used, and when it is at a convenient location). This temporal and spatial aspect of processual interfaces is a recurring theme.

6.1 Product Sale

At one end of the spectrum is the simple transfer of ownership of a physical product, with no service elements at all. In the extreme form of this model, the customer would independently be able fully and accurately to convey a specification of its needs ex ante, and the supplier would then provide the product in exchange for payment. ‘Pareto is supposed to have said that we do not need the consumer to be present at all so long as he leaves us a snapshot of his preferences.’ (Langlois and Cosgel 1998: 107)

In Baldwin and Clark’s terms, there would be a very thin (structural) interface constituted by the specification, and a simple processual interface that would define when and where the product would be delivered. Although the data transferred via the structural interface might be considerable in volume, there would be no need for any interaction and the data would not be ‘rich’ (Puranam and Jacobides 2005). Allowing for a little more interaction, there might be some form of technical advice offered by the manufacturer to assist the customer in identifying the most appropriate product to buy; the interface here might be configured by a standard requirements capture form or standard applications engineering procedure. Again, in Baldwin’s approach, this would provide a carefully controlled ‘common ground’ between customer and supplier, reducing to a minimum the ad hoc interaction between staff (and processes) on either side of the boundary.

6.2 Product-Oriented PSS

Product-oriented PSSs involve the sale of additional service elements such as a maintenance contract or spares and consumables. They might also involve more wide-ranging technical support than basic advice in selecting a product, extending to process improvement and the like. In some instances, the provision of additional services might be rather discrete and isolated events. For example, a piece of capital equipment might be subjected to an annual check and re-calibration; parts that are intended to wear in the normal course of use could be replaced on a routine basis. Parts and/or pre-defined service interventions (defined by writing, as discussed above) would be transacted in exchange for payment. A breakdown would require a one-off episode of diagnosis and repair, and a more iterative definition of the transaction may ensue. Then, the interface between provider process and customer process becomes thicker (in the sense of Baldwin and Clark—what is to be transacted requires iterative definition) and richer (in the sense of Puranam and Jacobides—there is a need for ‘qualitative problem-solving’ (Langlois 2002)).

The process interface would need to take account of the user’s production schedule and hence when it is appropriate to carry out the standard service tasks, but would not need to take account of any specific or idiosyncratic circumstances of the machine’s use: in that sense it is predominantly a processual interface. Breakdowns and repairs may entail a less clear-cut division of labour as both customer and provider might play a part in the diagnosis stage. The processes to make, ship and transfer the product to the customer, maintain and repair it, and provide spares and consumables, would remain relatively discreet and would be initiated by customer request. If circumstances dictate that more maintenance is required, it is essentially the customer’s problem, and the customer’s job to request it. And the customer must play a leading role in ‘joining the dots’—managing the implications of an asset being under maintenance or broken down, perhaps.

6.3 Use-Oriented PSS

In use-oriented PSSs, ownership of a piece of equipment remains with the manufacturer. In Baldwin and Clark’s terms, the thin interface is based on the definition of a transactable unit of access to the product and associated technical capabilities: the measured kilometre flown in ‘power-by-the-hour’, perhaps. The logic of these arrangements from the customer’s point of view has many facets, but one is surely that the user just wants to depend on availability of the capacity for which they pay, without concerning themselves with how that capacity is provided (except insofar as, in contrast to ‘result-oriented PSSs’ (below), the central product is specified and remains constant). The process of providing this use, however, may require multiple processual interfaces with the customer, in order to coordinate the logistics of maintenance and repair, and to monitor the use and condition of the equipment which is, of course, the manufacturer’s property.

According to Tukker’s scheme, some use-oriented PSSs can include arrangements whereby the asset is not used exclusively by one customer, but used successively by multiple customers (renting, such as plant hire) or simultaneously by multiple customers (pooling, such as in contract warehousing). These introduce extra interfaces—temporal in the case of renting, e.g. the need to explicitly delimit the period of use of a piece of equipment, and to institute systems for assessing the condition of the equipment as it is passed from one user to the next (as in private car hire). In pooling, it may be necessary to partition the asset itself in some way: for example, some users of shared warehousing will require that their products are not mixed physically with those of other users.

6.4 Result-Oriented PSS

In use-oriented PSSs, just discussed, responsibility for achieving the required outcome is still the responsibility of the customer, since the manufacturer is only required to provide access to the asset. As we move to result-oriented PSSs, the responsibility shifts even more to the manufacturer/provider. Result-oriented PSSs also eliminate any attachment to a particular physical asset, and leave to the manufacturer/provider’s discretion what assets will be used in providing the required result. The thin transaction interface here depends on the specification and measurement not of access, but of outcome. The manufacturer/provider has the responsibility and prerogative to change assets and processes to achieve outcomes in the face of changing circumstances or to make use of new technologies, perhaps. As such, the provider may need to re-design processes and customers’ roles within them—in contrast to the use-oriented PSS, where the degree and open-endedness of interaction will be much less. In result-oriented PSSs, then, the provider needs not only to have process interfaces defined as well as possible, but procedures for re-defining them as the need or opportunity arises.Footnote 2

7 Managing Interfaces in Servitization

As Langlois (2002) reminds us, modularisation is only of value under circumstances where the environment is differentiated or dynamic.Footnote 3 In the examples discussed earlier, modularity helps provide varied experiences for cruise passengers, customised and adaptable care for the elderly, and a variety of degree programmes for students. And as we move through the four models from product sale to result-oriented PSS, the responsibility for coping with changes in the environment shifts progressively from customer to provider. If the purpose of modularisation—and hence the management of interfaces—is to attenuate the effects of environmental disturbance, then as they ‘shift’ to service through the four archetypes, manufacturers should pay more attention to interfaces between elements of the PSS they provide, within their firm and between their firm and suppliers and complementors.

Some use- and output-oriented PSSs are referred to under the banner of ‘systems integration’ (Prencipe et al. 2003). But what becomes clear from the modularity perspective adopted here is that, in joining the elements of product and service together to create a product-service system, it would be unwise to adopt an integral architecture, as might be suggested by the term ‘systems integration’. Precisely because many previously un-connected or weakly connected elements are being brought together, some modularisation will be necessary to avoid the consequences of the exponentially-increasing number of possible interconnections between elements. This is nothing new: as Puranam and Jacobides (2005) note, ‘… Lawrence and Lorsch (1967) make clear that task decomposition and the creation of modules (differentiation) goes hand in hand with mechanisms for coordination that penetrates the boundaries of the resulting modules (integration)’. So, in an output-oriented PSS potentially encompassing the manufacturing, operation, maintenance, procurement, re-specification and even re-design of the product/asset, the need for effective design and use of interfaces is at its most critical for the manufacturer/provider.

8 Final Comment: Interfaces and Knowledge

In this brief discussion of interfaces in services and servitization, we have emphasised the typical operations management concerns of process specification and execution, leading to what we have termed structural and processual interfaces. Somewhat in keeping with Thompson’s approach, we are mainly concerned with defining and coordinating what needs to be done, rather than how to know what to do in the first place. Nevertheless, we are well aware that that the division of labour causes and is caused by differentiation and specialisation in knowledge (Loasby 1996); we are also aware that, as Baldwin also notes, ‘The domain of transactions is a domain of action: goods are made; services are performed; compensation is paid and received. But research has shown that a firm’s knowledge is generally not coterminous with its actions’ (Baldwin 2008: 160). As such, we leave the systematic analysis of servitization and knowledge interfaces for another day.