Mobile Services for Vehicles
Mobile Services for Vehicles
Kuschel, Jonas, IT University of Göteborg, 412 96 Göteborg, Sweden, email@example.com
Dahlbom, Bo, IT University of Göteborg, 412 96 Göteborg, Sweden, firstname.lastname@example.org
In recent years the modern vehicle has developed into a sophisticated sensor and computing environment. This development has been motivated by an ambition to enhance operations. In order to increase customer service and revenues, vehicle manufacturers are now interested in using the sensor data generated in the vehicle for remote vehicle services, i.e., mobile services connecting the vehicle to service stations while on the road. Our results from three years of case studies in collaboration with a vehicle manufacturer indicate, however, that it will not be possible to make such services profitable unless the vehicle manufacturer is willing to open up the vehicle for external service providers. The reluctance to do so, we argue, is a consequence of the product focus still characterizing vehicle manufacturers, in spite of a growing understanding of the need for a more customer oriented service perspective. Using information infrastructure theory, we argue for an open information infrastructure that can distribute costs, and support the development of both product and customer oriented services across different business sectors. Our paper is a contribution to information infrastructure theory and to a theory of services, by pointing out some important dependencies between services and information infrastructures.
Keywords: Information infrastructure, services, remote vehicle services, open systems.
Adam Smith (1776) did not think much of services: “…services generally perish in the very instant of their performance, and seldom leave any trace or value behind them…” (op.cit., p. 135). However, the automation of services (Levitt 1972) has resulted in services becoming more like products which can be sold again and again and, of course, Internet has become the major platform for doing so. Product companies today improve their business by offering services (Henkoff 1994). These services are still dominated by services supporting the product (SSP) as distinct from services supporting the client’s activities when using the product (SSC) even though the latter are considered to be more profitable in the long run (Mathieu 2001). The trend towards services in general and the focus on services supporting products in particular, e.g. vehicle repair services, is also evident in the vehicle industry. In the last ten years, interest has grown in the development of services based on remote access to vehicle sensor data, generated by a number of sensors involved in controlling and operating different parts of the vehicle. Remote Vehicle Diagnostics (RVD), i.e., remote surveillance of vehicle operations, has been described as a particularly promising service (Gartner 2002). The more general trend towards vehicle services has been named telematics, but has so far been a major disappointment for the vehicle industry (Chatterjee et al. 2002). Our research does not have the ambition to describe or analyze the failure of telematics in all its complexity, but focuses instead on the more positive task of understanding what it would take to make remote vehicle services a viable business opportunity for vehicle manufacturers.
Empirically we build on a three year long soft case study (Braa et al. 1997) in collaboration with a vehicle manufacturer. The empirical work shows that there is a demand for remote vehicle services to support current work processes. However, interviews and workshops with managers indicate that development, maintenance and hardware costs do not balance possible earnings. In the absence of a business case, nothing happens, the development of mobile services to improve and enrich the use of vehicles has come to a standstill. In general, the managers express a rather narrow corporate or even business unit perspective on such services, consonant with the absence of infrastructural thinking in their efforts to develop remote vehicle services. A broader perspective on the vehicle as a platform for services would introduce new possibilities for revenues we think, and we therefore analyze the problem using Information Infrastructure (II) theory (Hanseth et al. 1996; Star et al. 1996) and service theory (Mathieu 2001). Our analysis leads us to propose a server based universal II (Hanseth et al. 2004) that mirrors sensor data and is owned by the vehicle manufacturer, but open to external service providers. Such an infrastructure would carry both services supporting the product and more general services supporting the customer using the product. Among the latter there could be services integrating vehicle use with other customer operations, or services sharing experiences between vehicles, such as informing each other automatically about slippery roads. Considering the many important roles played by vehicles in modern society, there ought to be a market for a great number of important services of such a nature.
Our contribution in this paper is twofold, addressing the vehicle industry in particular and II theory in general. To the vehicle industry we propose a distinction between the vehicle manufacturer’s role as infrastructure provider and a more general role as service provider, similar to how such distinctions have been discussed for telecommunication operators. The idea is that external service providers will leverage services from which the vehicle manufacturer as infrastructure provider can benefit. Our second, more general, contribution addresses the content of II theory, which describes one of the important tasks of infrastructures as that of handling heterogeneity. Based on our findings we argue that heterogeneity does not evolve by itself in the design process, but rather requires an explicit understanding of the role of an open infrastructure. Such an understanding is only made possible by abandoning the narrow product perspective on customer services still prevailing in many companies.
The paper is organized as follows. In section 2, we outline challenges in building an II and how to understand the associated notion of service. This is followed, in section 3, by a presentation of the research setting and method applied. The empirical results are reported in section 4, and then analysed in section 5, using the theoretical framework. Finally, in section 6, we discuss how the development of remote vehicle services can be promoted by means of an open II.
2 THEORETICAL BACKGROUND
Our theoretical framework is a combination of two theories, service theory and II theory. The service theory helps us to analyze the vehicle manufacturer’s conceptualization of services and the II theory provides an understanding of how to promote the development of services, by providing a feasible business case for such services.
Since Daniel Bell (1973) first described the Western world as becoming a “post-industrial society,” focus on products and production has gradually shifted to an interest in the role of services and the productivity of service work. Western economies are now service economies, with services making up the greater part of the gross domestic product and most people in service occupations (Wölfl 2005). Classical economists, from Adam Smith to Karl Marx, did not think much of services, viewing them as for ever labour intensive, menial tasks outside the realm of a developing industrial economy. In contrast, modern economies depend on a complex system of increasingly knowledge intensive services such as information services, knowledge services, financial services, logistic services and public services. Contemporary economists view them as important drivers of economic development.
From a product-oriented perspective this shift from products to services means that products are turned into services or accompanied by different services. This is sometimes described as the servitization of business (Vandermerwe 1988). Using the same perspective, Mathieu (2001), among others, argues for a classification of services into services supporting products (SSP) and services supporting clients (SSC). The former are mostly standardized and consist of services addressing the product’s operation rather than the client’s usage (see figure 1). Interviewing managers in the micro-electronics industry, Mathieu (ibid) found that they accepted this distinction, considering SSPs to be traditional, well-known services whereas SSCs were more innovative, promising, and untested service ideas. When Levitt (1972) writes about services he seems to be thinking primarily of SSPs, arguing that the more complex the product, the more it will be dependent on accompanying services.
Figure 1. The different foci between SSP (left) and SSC (right)
With a product-oriented perspective, services become part of the product, or at least something delivered with the product, rather than business process activities. Services are something you package, prize and deliver, just as you do with products. They increase the products’ value, ensure a more efficient use of the products, protect against breakdowns, and so on. Both producers and consumers will think of such services in the same way they think of products. To the extent that it is possible, services will become standardized and mass produced just like the products. So if services, like labour more generally, were labour intensive manual tasks in the days of Smith and Marx, today they are becoming (Levitt 1972) standardized, mass produced, more and more automated, just like products. Information technology and Internet play important roles in such service development and packaging. With information technology, especially the increasing trend of ubiquitous computing, it also becomes possible, as Fano and Gershman (2002) argue, to make such mass produced services more and more custom oriented without having to involve any human labour.
2.2 Information Infrastructure
Van de Ven (2005) argues that technology innovations often require companies to cooperate and form joint ventures, to “run in packs,” as he puts it. Cooperating by sharing common system features is a strategy well known within computer science and IS research. We speak of using the same software platform (Edwards et al. 2003), the same toolkit (Dey et al. 2001), framework (Ponnekanti et al. 2001), middleware (Nakajima et al. 2004), software infrastructure (Banavar et al. 2002) or II (Hanseth et al. 1996). To sort out the relations between these different terms or concepts is an exercise in its own right, which we shall pass over. Instead we hope to cover most of these different aspects of common system features by discussing some general characteristics of IIs. Doing so we will make use of Nielsen’s (2006) four analytical core concepts for building IIs, i.e. heterogeneity, evolution, control, and standardization.
The central role of IIs is to support a wide range of usage and activities (Hanseth et al. 1997). But this heterogeneity of services is only made possible by a heterogeneous system (Hanseth et al. 2004). Heterogeneity has been described as a major challenge in II literature according to Nielsen (2006), but he points to heterogeneity as not only a challenge but the very condition for IIs to secure their growth. Reporting from the development of an II for mobile content services in Norway, Nielsen (ibid) argues that encouraging and embracing different system builders’ perspectives was significant for the success of the II.
Heterogeneity is a challenge to be coped with even in the long run since the building blocks of an II must be flexible enough so that new functionality can be added to support future services (Nakajima et al. 2004). Since IIs are designed to be useful for a long time, all needs of future services cannot be known in advance (Edwards et al. 2003). This continuous evolution has to be handled by modularization and gateways to subsystems adding new features before they are integrated as part of the infrastructure (Hanseth et al. 1998), making modularization preferable to building one big system, Hanseth and Braa (2000) argue. Thus, IIs are described as evolving based upon what already exists, i.e. the dependency path, and what networks are connected (Hanseth 2000). Nielsen (2006) speaks of this process as an interplay between evolution and construction, describing it as a political process, controlling and guarding the stability of the II.
Nielsen (2006) is interested in the mechanisms controlling the development of IIs. Ciborra et al. (2000), on the contrary, describe the development of IIs as out of control and drifting. Hanseth and Lyytinen (2004) point out that infrastructures are shared among communities of different size and shape, distinguishing between corporate, business sector, and universal infrastructures. A universal infrastructure, for instance, is generally open to all possible users whereas a corporate infrastructure is limited to a single organization and its partners.
IIs require standardizations, i.e., socio-technical agreements about the properties of the infrastructure interface towards other infrastructures or systems (Hanseth et al. 1997). This could be either the standardization of railway track widths to enable travel between two different railway networks or the standardization of TCP/IP to allow communication between various applications through, e.g., the Internet. Since standardization is a mutual agreement between different representatives, negotiations may be tedious. Dahlbom (2000) describes infrastructures and standards as a relic of the material world whereas information technology is immaterial and in essence a gateway technology making universal standardization less important. Hanseth et al. (1996) describe this phenomenon as the tension between standardization and flexibility in II.
3 RESEARCH CONTEXT AND METHOD
This paper belongs in the tradition of interpretative IS research (Walsham 1995), relying on a soft case study (Braa and Vidgen (1997) to explore the possible use of mobile services in vehicles. In contrast to the positivist hard case study (Yin 2003), a soft study focuses on the reasoning rather than the representativeness of the case. In our research we have been more interested in understanding the phenomena under study, than in quantifying them. To obtain an understanding of the vehicle industry’s approach to remote vehicle services, we collaborated extensively with a vehicle manufacturer of trucks, buses, construction equipment, power generation and marine engines. During three years of research (see figure 2), we spent time at repair service, customer care, strategic planning and software development departments. By this we gained knowledgeable insights into the vehicle manufacturer’s operations and ways of thinking. Most of the research activities were conducted in active collaboration with personnel from the manufacturer, providing us with continuous input and feedback. In what follows, we describe our method in more detail.
The initial objective of this research was not to contribute to II theory, but to understand why the vehicle industry struggles unsuccessfully with developing remote vehicle services, even though research analysts (Gartner 2002) and others predict these to be an important future source of revenue for vehicle manufacturers. Our research strategy was simple. We began by focusing on the most promising remote vehicle service inquiring into the nature and context of this type of service. Remote Vehicle Diagnostics (RVD) has been highlighted as the most promising future service (ABIresearch 2003), and this opinion was confirmed in initial discussions we had with representatives from the vehicle industry. Initially, we wanted to determine in which way RVD could improve and evolve current repair service work by a process of cultivation, as described in Dahlbom & Mathiassen (1993).
Figure 2: Timeline of the research activities
By conducting an ethnographic field study (see e.g. Schultze 2000) we gained detailed insight into the actual work practice. An ethnographic approach has become increasingly popular in IS research and even among consultants as people in general have become increasingly aware of the difference between what people say they do and what they actually do. In our research we obviously wanted to look beneath the surface described in most analyst reports. Our study focused on service technicians in the marine service industry. Four different local service centres in Sweden, involving eight service technicians, and a central support group at the manufacturer headquarter were part of the study. The study was conducted in 2003 and we spent a total of four days at the service centres (5 hours per day) as well as approximately one to two days a week during two months at the central support centre that handles more advanced support issues. The data was collected by note-taking and photographs with additional annotations at the end of the day.
The empirical findings did only partially elucidate our problem, however. Technical aspects and economic feasibility of remote vehicle service development had to be taken into account as well. Therefore, we developed three different prototypes addressing design ideas inspired by the field work. The prototyping work was conducted by one of the researchers in close cooperation with three groups of master students. Core technologies and evaluation equipment were provided by the vehicle manufacturer. The prototypes were then discussed with the company in two different workshops with a focus on their technical and economic feasibility within the organization. Two different departments were targeted in the workshops, the marine engine (private yachting) and the power supply department (power supplies can be generators or be part of a special vehicle, e.g. a fork lift). The first workshop was attended by eight employees, four students and one researcher. The employees represented managerial, technical and operative competence. The second workshop gathered six employees, two students and one researcher. Also here different competences were represented. Two of the attendees represented the spare parts department, responsible for the development of systems supporting aftermarket services within all business units, providing a more comprehensive perspective.
In addition to these workshops, personal communication and unstructured interviews discussing the issue of remote vehicle services took place throughout the research work. Two such meetings were particularly important in providing the typical economic and strategic perspective in the company. One was with a general manager responsible for remote vehicle services within the vehicle manufacturer and the second with a manager for repair services at the truck division. Due to non-disclosure agreements, workshops and personal communications were only documented by note taking.
4 EMPIRICAL RESULTS
In what follows we report our empirical results, organized by the different steps within the soft case study. First, the field study indicates that RVD constitutes of a number of different services rather than a single system-like service that automates vehicle diagnosis. Secondly, the prototype development work shows that remote vehicle services share a number of general features. Thirdly, the workshops affirm the operative and economical benefits of the services discussed, but also that possible earnings do not balance the costs, an observation that was confirmed by additional personal communications.
4.1 Field Work
Within parts of the vehicle industry, RVD has been proposed as a fully automated, diagnosis substitute for on site repair technicians, i.e. a diagnostic system. However, by studying the actual work practice of conducting repair service, we found that RVD should not be understood as one diagnostic system, but as a number of different services supporting repair service practice. As follows, we will provide three main examples from our field work to illustrate this.
Most notably, our fieldwork points to the importance of involving the customer in the diagnostic process. Current repair services always begin by interviewing the customer about the problem occurred. The service technicians use the interviews to confirm and falsify hypotheses about the problem by discussing different possible causes. This working procedure can be explained by what Orr (1996) describes as repair technicians acting like psychologists to fix the customer. The central role of customers in the diagnostic process indicates that future RVD services have to support technicians to get in contact with the customer as early as possible, i.e. when the problem actually occurs. In this case RVD plays the role of problem notification, to initiate the customer driven description of vehicle problems, rather than as automated diagnosis.
Secondly, we found that it is not unusual that problems reoccur after the repair service is performed. Often this happens because the service technician, in spite of seriously trying to do so, did not correctly identify the actual cause of the problem. Sometimes, the service technician simply wants to rapidly test different solutions, “prototyping” as it were, in order to minimize repair costs. During our study we documented, e.g., a case in which a customer was asked to do some test driving with test devices attached to the engine. This shows another application of RVD, i.e., to evaluate the effects of repair services, or to perform long term tests of particularly interesting aspects of vehicle operation by the service technician. From a customer perspective, this guarantees a high level of successful service.
Thirdly, we refer to RVD as a support service for the central support department that handles more complex problems which cannot be solved by common service technicians in the field. Today, the support team has to rely on the customer’s and the service technician’s problem descriptions or even try to reconstruct the problem in a test setting. However, in a number of cases support technicians have to travel to the site in order to use appropriate diagnostic tools. To prepare for a visit at the site or even instruct the co-located service technician remotely, RVD would be beneficial. In this case RVD is more of an advanced diagnostic and service supporting remote collaboration between service technicians and the central experts.
In summary, our field study indicates that RVD is a more complex process than one might think and that the different parties involved require more than one setup of RVD service. In addition, RVD is only a small subset of possible remote vehicle services of interest to the various parties involved in vehicle use (drivers, transport companies, customers, and authorities). It would therefore be unwise to form pessimistic judgments about the possibilities of remote services based on a limited testing of simple diagnostic services.
4.2 Prototype development
Based on the field work results, we developed three different prototypes. We will not outline in what way these prototypes relate to the field work, but discuss the prototypes from a information system architecture point of view. The development of the first service resulted in an embryo for a generic platform, since we identified both hardware and software components that could be reused in future services. When we developed two more prototypes they both contributed to the generalization of the platform features, but they also benefited since building blocks did not have to be developed twice. Thus, as a consequence of developing three prototypes, we have implemented a platform that provides remote communication with the vehicle system through a general server based interface. Remote vehicle services that require access to vehicle sensor data, communicate with the vehicle via a web service interface implementing the Simple Object Access Protocol (SOAP). By means of a platform we aimed to minimize both complexity for future service development and the implementation time for each service. By choosing a high level interface rather than a low level, vehicle bus oriented interface, the master students engaged in the prototype development did not need vehicle technology competence. Furthermore, the platform mirrors the sensor vehicle data, thus avoiding data redundancy by services requesting identical data. Instead of here going into details regarding the platform and its technical implementation, we want to emphasize the high level interface approach and the fact that remote vehicle services share a number of building blocks.
In addition to technical evaluations, we organized two workshops in which the prototypes were discussed. The first workshop focused on how repair workshops and the vehicle manufacturer could benefit from getting real time notifications about vehicle errors and how to finance such a service. Workshop attendees proposed to offer the service to customers as an add-on, and service workshops to pay for receiving vehicle error notifications. However, the service was discussed as a system, where the total cost has to be covered by customers and workshops. In the end, such a system for vehicle error notification was rejected by the workshop attendees since the investment costs would be intensive and direct revenues unsure and limited. Nevertheless all workshop attendees agreed upon the benefits of remote vehicle services in general.
The second workshop discussed a prototype to remotely reconfigure and update the vehicle software. The workshop attendees discussed the savings by not sending out service technicians and agreed that there would be a significant potential to save costs. Nevertheless, when discussing the investment costs, the group concluded that the savings would probably not balance the cost.
4.4 Personal Communications
One of the researchers maintained a continuous dialogue with employees at the vehicle manufacturer. Services related to engine maintenance, vehicle operations or internal processes were discussed frequently, whereas services supporting the customer’s use of the vehicle or other third party services were rarely discussed.
Two personal communications stand out. First, we had a discussion with the general manager responsible for remote vehicle services who stated that there might be a number of potential remote vehicle services. However, he requested strong business cases within the organization to account for financing the implementation of remote vehicle service technology in all vehicles. At the point of interview, in 2003, he was still doubtful whether revenues from internal services would balance the total cost.
At the second meeting, in 2006, with the general manager and a manager responsible for the truck service division, they more clearly stated the need for an infrastructure serving a multitude of services as opposed to one system. Nevertheless, they still argued that the services provided by the vehicle manufacturer would by themselves have to generate income balancing the investment costs.
Vehicle manufacturers are currently discussing the pros et cons of remote vehicle services. Their conclusion so far is that remote vehicle services are not yet economically feasible, lacking a viable business model. Using II theory and service theory to analyse our results, we want to suggest such a business model. In doing so we make use of Nielsen’s (2006) four analytical categories for II building together with Mathieu’s (2001) distinction between customer oriented services (SSCs) and product oriented services (SSPs).
As our ethnographic field study indicates, there is a need for a number of possible and useful remote vehicle services related to repair, as opposed to one single automated remote diagnostic service. Our prototype development shows that a platform can be developed that contributes common building blocks to such different services. This heterogeneity of services has to be supported by an II, we argue. Our study also reveals the organization’s belief that revenues from possible services do not balance the investment and maintenance costs. Therefore, we here argue for the need of extending the prevailing concept of service among vehicle manufacturers to increase the level of heterogeneity. Mathieu’s (2001) observation that product companies tend to focus on the development of SSPs is true of vehicle manufacturers. Their service offers, e.g. financial, repair, insurance or fleet management services, all relate to the vehicle per se. They fail to respond to the important role played by vehicles in today’s society, a role which opens up for a broader range of SSCs. By SSCs we mean services that support customers using vehicles, both directly and indirectly. Thus, for example, vehicle manufacturers do not provide appropriate services to integrate vehicle sensor data, e.g., fuel consumption, in existing transport information systems (Andersson et al. 2005). Other possible examples of SSCs are insurance services based on the actual use of the vehicle, authority services to control the emission within certain geographical areas, toll collect systems that are independent of road side infrastructure, or advertisement services to route to the most optimal gas station where the customer receives a discount. Some of these services are speculative and some might result in great savings. What these examples show is that real time information, describing the state of a vehicle, is useful in future remote vehicle services. This strengthens the heterogeneous perspective on remote vehicle services, which is best supported by an II. Our empirical findings confirm as well Nielsen’s (2006) argument that heterogeneity is the very condition for IIs, i.e. vehicle manufacturers have to encourage different service providers in order to succeed in developing an II.
Designing an infrastructural support for remote services requires an II that is universal, i.e., open to different service providers. This will increase heterogeneity and decrease control as opposed to, e.g., a corporate II (Hanseth et al. 2004) where the vehicle manufacturer would maintain control within the corporation. Such loss of control will not be easily accepted by a vehicle manufacturer. However, as Nielsen and Aanestad (2005) point out in the case of developing a mobile phone content service platform in Norway, technical control can be combined with open access for service providers. Overcoming this fear of losing technical control is an important step in beginning to reflect on their business model. Andersson (2006) observes that vehicle manufacturers do not want to leave the business to somebody else when it comes to sharing vehicle sensor data. This reluctance towards openness is also evident in our study, where the personnel only reflect upon services developed by the vehicle manufacturer. Even though this phenomenon of control over technology to create favourable revenue streams is common (Shapiro et al. 1999), it is fatal for the emergence of future remote vehicle services.
To involve a broad spectrum of service providers, standardization is required. There is a current standard on how to access vehicle sensor data (the FMS standard). Since this standard is implemented on the physical vehicle data bus, each remote vehicle service provider has to install mobile communication software and hardware to offer services remotely. As a better alternative, we propose a server side standardization of the II, as implemented in our prototype. By this the standardized II can be based on common underlying software standards such as SOAP and facilitate the development of remote vehicle services since vehicle specific technical knowledge will not be required and integration with other systems and services is easily supported.
A server side and software based II will enable continuous evolution of the infrastructure. Advancements can be modularized, connected through gateways and integrated into the II without changes to the physical infrastructure. Consequently, a server based universal II mirroring the vehicle data is preferable to handle future changes. The importance of enabling evolution is obvious in this case since it would be unwise to even speculate about what future services will be like.
The vehicle industry is, as restrictions by the European Commission (2002) indicate, a monopolistic industry not used to sharing revenues with third parties. Thus, sharing information with other companies is not part of vehicle manufacturers’ current business models. This reluctance towards openness and cooperation has to be changed to enable the evolution of remote vehicle services, we argue.
Vehicle manufacturers would profit from information sharing as opposed to keeping the data and developing services on their own. By means of a universal II, a broad spectrum of companies would be able to easily develop services that are either novel or integrate vehicle sensor data in existing services. Since estimating and handling risk is a core issue for vehicle manufacturers, inviting other companies to develop remote vehicle services could divide the risk among service providers and the vehicle manufacturer as infrastructure provider. Service providers then account for the risk of their services to succeed and vehicle manufacturers’ risk is to attract a sufficient number of service providers to use the II. Attracting service providers requires a straightforward technical interface and pricing model. In this paper we propose a high level server based II interface that aims to enhance the development of remote vehicle services without any deeper knowledge or investments in vehicle technology. By this, service providers can launch their services with reasonable investment costs. Vehicle manufacturers will economically benefit from service providers through a fee linked to the usage of the II. By this service providers can more easily calculate their risk and vehicle manufacturers benefit from all services implemented on the II.
The proposed concept of II and the distinction between the roles as infrastructure provider and service provider is not novel per se. Road networks have for a long time been the best example of such an open platform for services. Recently the Internet has become something of a model for how a universal infrastructure can be used by different service providers. In view of the deep understanding that vehicle manufacturers must have of the role of open roads, one may very well wonder how they can fail to see the obvious advantage of providing an open infrastructure, inviting external service providers. Our research indicates three possible motives for such reluctance:
• Vehicle manufacturers think of services as augmenting products, rather than as supporting the user of the product.
• Vehicle manufacturers have no real tradition of joint ventures, of cooperating with other branches of industry to share revenues.
• Vehicle manufacturers are risk aversive and extremely focused on quality, thus not easily persuaded to give up control over their product.
Together, these three characteristics of vehicle manufactures make it very difficult to introduce universal IIs in vehicles. Fundamentally it is a question of developing a more adequate understanding of services, decoupling them from products. It is not easy for product oriented companies to perform such a re-conceptualization of what services are all about, but we think that such a re-conceptualization is necessary for vehicle manufactures to play a more active role in developing open IIs supporting the development of a rich variety of vehicle services.
A comparison with reactions to recent deregulations of the telecom market can shed light on the situation in the automotive industry. The major move of deregulation (or rather re-regulation) has been to separate infrastructure owners from service providers. In practice, this has generally meant that traditional monopolies have been forced to split into two companies, and the infrastructure owner then being forced to open up their infrastructure for competing service providers. This process has been difficult to implement. The Swedish former telecom monopolist, for example, still retains both infrastructure and operation, and has been in constant legal conflicts with its competitors, being accused of not really opening up its infrastructure. This conflict between the infrastructure owner and the multitude of competing telecom operators is mirrored in a similar conflict between operators and mobile service developers. Many of the telecom operators have been reluctant to open their mobile business for a multitude of service providers, preferring to monopolize the mobile service provision to their customers. As a result the development of mobile IT services has been frustratingly slow, especially when compared to the development in markets in which telecom operators have chosen a different strategy, most notably of course NTT DoCoMo in Japan.
We can identify the same three levels – infrastructure, operation and services – in the vehicle industry. The vehicle industry is an obvious infrastructure owner, or perhaps we should say, is becoming a more obvious such candidate. Today there are many examples of vehicles using navigation systems, for example, with an infrastructure supplied not by the vehicle producer but by some computer company. And of course mobile telephony is seldom part of the vehicle infrastructure today. We might have a development with computer or telecom companies supplying the infrastructure for remote services, access to the Internet, telephony, and so, in the vehicles. And yet, the most obvious candidate for ownership of that infrastructure, we believe, is the vehicle producers in view of the important role played by vehicle data in future remote services. Telecom operators are of course even more likely candidates as operators. Their competence in providing quality of services, billing, security, and so on, is obviously needed. When it comes to the actual service provision, the vehicle producer today is obviously intent on monopolizing this business, protecting their customers. At best they may consider a joint effort together with a telecom operator, like in the Swedish Wireless Car initiative. This protective spirit will hinder the development of remote services just as it has hindered the development of the mobile services business, we believe.
The vehicle industry is reluctant to invest in remote vehicle services today, suffering as they are from previous telematics ventures. As a result, useful services are not becoming available. Van de Ven (2005) argues that companies have to cooperate in order to develop knowledge intensive technologies, i.e., to focus on their distinctive competencies and cooperate with other companies providing the missing parts. He argues that “running in packs” will be more successful than “going it alone.” Thus, cooperation is required to push forward the innovation and development of remote vehicle services by a broad spectrum of service providers. Relying on Information Infrastructure (II) theory, we argue that a universal high level, vehicle based II is needed to support the development of both customer and product oriented remote vehicle services. For vehicle manufacturers to accept such a proposal it seems that they have to abandon their narrow proprietary, product perspective in favour of a more cooperative service perspective. Unless they begin to realize the full potential of vehicle services, this promising new market for useful services will remain unexplored.
ABIresearch “Remote Diagnostics May Become One of Aftermarket Telematics’ Killer Apps, Says ABI.”
Andersson, M. “Ubiquitous Transportation Systems: Negotiating Context through a Mobile-Stationary Interface,” Proceedings of the 14th European Conference on Information Systems, Gothenburg, Sweden, 2006.
Andersson, M., and Lindgren, R. “The Mobile-Stationary Divide in Ubiquitous Computing Environments: Lessons from the Transport Industry,” Information Systems Management (22:4) 2005, pp 65-79.
Banavar, G., and Bernstein, A. “Software Infrastructure and Design Challenges for Ubiquitous Computing Applications,” Communications of the ACM (45:12) 2002, pp 92-96.
Bell, D. The Coming of Post-Industrial Society: A Venture in Social Forecasting Basic Books, New York, 1973, p. 507.
Braa, K., and Vidgen, R. “An Information Systems Research Framework for the Organizational Laboratory,” in: Computers and Design in Context, M. Kyng and L. Mathiassen (eds.), MIT Press, Cambridge, MA, USA, 1997, pp. 381-400.
Chatterjee, A., Kaas, H.-W., Kumaresh, T.V., and Wojcik, P.J. “A Road Map for Telematics,” pp. 100-109.
Ciborra, C.U., Braa, K., Cordella, A., Dahlbom, B., Failla, A., Hanseth, O., Hepsø, V., Ljungberg, J., Monteiro, E., and Simon, K.A. From Control to Drift: The Dynamics of Corporate Information Infrastructures Oxford University Press, Oxford, 2000.
Commission, E. “Commission Regulation No 1400/2002 of 31 July 2002 on the application of Article 81(3) of the Treaty to categories of vertical agreements and concerted practices in the motor vehicle sector,” European Commission.
Dahlbom, B. “Postface: From Infrastructure to Networking,” in: From Control to Drift: The Dynamics of Corporate Information Infrastructures, C. Ciborra, K. Braa, A. Cordella, B. Dahlbom, A. Failla, O. Hanseth, V. Hepsø, J. Ljungberg, E. Monteiro and K.A. Simon (eds.), Oxford University Press, Oxford, 2000, pp. 212-235.
Dahlbom, B., and Mathiassen, L. Computers in Context: The Philosophy and Practice of Systems Design Blackwell, Cambridge, MA, USA, 1993.
Dey, A.K., Abowd, G.D., and Salber, D. “A Conceptual Framework and a Toolkit for Supporting the Rapid Prototyping of Context-Aware Applications,” Human-Computer Interaction (16:2-4), Dec 2001 2001, pp 97-166.
Edwards, W.K., Bellotti, V., Dey, A.K., and Newman, M.W. “Stuck in the Middle: The Challenges of User-Centered Design and Evaluation for Infrastructure,” Proceedings of the SIGCHI conference on Human factors in computing systems, ACM Press, Ft. Lauderdale, Florida, USA, 2003, pp. 297-304.
Fano, A., and Gershman, A. “The future of business services in the age of ubiquitous computing,” Commun. ACM (45:12) 2002, pp 83-87.
Gartner, G. “Telematics Industry Outlook: Think Outside the Vehicle,” Technical Report RPT-0902-0163, Gartner G2.
Hanseth, O. “The Economics of Standards,” in: From Control to Drift: The Dynamics of Corporate Information Infrastructures, C. Ciborra, K. Braa, A. Cordella, B. Dahlbom, A. Failla, O. Hanseth, V. Hepsø, J. Ljungberg, E. Monteiro and K.A. Simon (eds.), Oxford University Press, Oxford, 2000, pp. 56-70.
Hanseth, O., and Braa, K. “Who’s in Control: Designers, Managers – or Technology? Infrastructures at Norsk Hydro,” in: From Control to Drift: The Dynamics of Corporate Information Infrastructures, C. Ciborra, K. Braa, A. Cordella, B. Dahlbom, A. Failla, O. Hanseth, V. Hepsø, J. Ljungberg, E. Monteiro and K.A. Simon (eds.), Oxford University Press, Oxford, 2000, pp. 56-70.
Hanseth, O., and Lyytinen, K. “Theorizing about the design of Information Infrastructures: Design Kernel Theories and Principles,” in: Sprouts: Working Papers on Information, Environments Systems and Organizations, 2004.
Hanseth, O., and Monteiro, E. “Inscribing Behaviour in Information Infrastructure Standards,” Accounting, Management and Information Technology (7:4) 1997, pp 183-211.
Hanseth, O., and Monteiro, E. “Changing Irreversible Networks,” Proceedings of the 5th European Conference on Information Systems, Aix-en-Provence, 1998.
Hanseth, O., Monteiro, E., and Hatling, M. “Developing Information Infrastructure: The Tension between Standardization and Flexibility,” Science, Technology, & Human Values (21:4) 1996, pp 407-426.
Henkoff, R. “Service is Everybody’s Business,” in: Fortune, 1994, pp. 48-60.
Levitt, T. “Production-line Approach to Service,” Harvard Business Review (50:5) 1972, pp 41-52.
Mathieu, V. “Product Services: From a Service Supporting the Product to a Service Supporting the Client,” Journal of Business & Industrial Marketing (16:1) 2001, pp 39-61.
Nakajima, T., Fujinami, K., Tokunaga, E., and Ishikawa, H. “Middleware design issues for ubiquitous computing,” Proceedings of the 3rd international conference on Mobile and ubiquitous multimedia, ACM Press, College Park, Maryland, 2004, pp. 55-62.
Nielsen, P. “A Conceptual Framework of Information Infrastructure Building: A Case Study of the Development of a Content Service Platform for Mobile Phones in Norway,” in: Department of Informatics, University of Oslo, Oslo, 2006.
Nielsen, P., and Aanestad, M. “Infrastructuralization as Design Strategy: A Case Study of a Content Service Platform for Mobile Phones in Norway,” Proceedings of the 28th Information Systems Research Seminar in Scandinavia, Kristiansand, Norway, 2005.
Orr, J. Talking about machines: An ethnography of a modern job Cornell University Press, Ithaca, NY, 1996.
Ponnekanti, S., Lee, B., Fox, A., Hanrahan, P., and Winograd, T. “ICrafter: A Service Framework for Ubiquitous Computing Environments,” Proceedings of the 3rd international conference on Ubiquitous Computing, Springer-Verlag, Atlanta, Georgia, USA, 2001, pp. 56-75.
Schultze, U. “A Confessional Account of an Ethnography about Knowledge Work,” MIS Quarterly (24:1) 2000, pp 3-41.
Shapiro, C., and Varian, H.R. Information Rules Harvard University Press, Cambridge MA, 1999.
Smith, A. An Inquiry into the Nature and Causes of the Wealth of Nations, 1776, p. 447.
Star, S.L., and Ruhleder, K. “Steps Toward an Ecology of Infrastructure: Design and Access for Large Information Spaces,” Information Systems Research (7:1) 1996, pp 111-134.
Walsham, G. “The Emergence of Interpretivism in IS Research,” Information Systems Research (6:4) 1995, pp 376-394.
Van de Ven, A.H. “Running in Packs to Develop Knowledge-Intensive Technologies,” MIS Quarterly (29:2) 2005, pp 365-378.
Vandermerwe, S. “Servitization of Business: Adding Value by Adding Services,” European Management Journal (6:4) 1988, pp 314-324.
Wölfl, A. “The Service Economy in OECD Countries,” Organisation for Economic Co-operation and Development.
Yin, R.K. Case Study Research: design and methods, (3rd ed.) Sage Publications, Thousand Oaks, 2003.