• No results found

The limits to outsourcing and the problem of inseparability

Table 4.1 Key features of sponsor organisations’ business models

5 Outsourcing and the emergence of new spaces for innovation

5.3 The limits to outsourcing and the problem of inseparability

There are important differences between standalone and integrated innovation activities. The increasing complexity of product development in the electronics industry is the main driver of standalone innovation outsourcing to India. Even

developers of subcomponents cannot generate/attract and maintain all resources and capabilities internally. This is not a novel insight. Other studies of the globalisation of innovation reach a similar conclusion. Cooke (2005), for instance, showed how biotechnology firms pioneered open innovation on a global scale, in order to overcome intra-firm knowledge constraints by tapping into the regional knowledge capabilities of clusters. Ernst (2005) showed how lead firms in the electronics industries used Asian suppliers for chip design. In both industries, innovating firms draw on knowledge from the global supply base and absorb it into their own products. They concentrate on the integration of new knowledge and resources for the development of new products. Hence, they play the role of systems integrators. This is typical of complex industries in which different firms with different

competences are required to handle the various stages in the product

development process (Brusoni 2005). This chapter has shown how this type of industry organisation drives specific activities in Indian software firms, such as those performed in the engineering services segment. Cost was an important element in the ‘location’ of these activities (in India), but cost did not drive the opening up of innovation in its own right. The complexity of knowledge was the main driver of openness and cost competitiveness arose in the second stage.

The outsourcing of integrated activities is different because the knowledge- seeking and cost-reduction elements came together in opening the innovation processes and underlying business models. In this sense, it is a novel form of open innovation and it has proven to be an immensely important category for the analysis of software innovation outsourced on a global scale. Yet it is not on the radar screen of the open innovation literature.

This new form of innovation outsourcing is prevalent in the primary and in the secondary software industries. In the first instance, the pressure to cut costs and speed up the development cycle is driving software organisations to outsource non-core activities. However, when this decision has been made there are

sometimes compelling reasons for incrementally adding higher-order activities. This not only solves the common problem of finding generally skilled software engineers in adequate numbers, but it also relieves constraints related to highly skilled

internal resources. These are now able to concentrate on high-priority projects or move into non-technical business activities altogether. These organisations reduced the opportunity costs of internal resources by relying on outsourcing of some high-end activities. By shifting over to what one informant termed ‘the business-side of things’, internal staff undertake activities that create more rent. Innovation outsourcing also reduces the substantial coordination costs associated with upfront investments undertaken during the elaboration phase. Business analysts and software architects construct the high-level design and the specifications at this stage. They need to write these specifications in a highly detailed form if the buyer intends to transfer them to a supplier who will take over during the construction phase. However, these investments can be externalised by involving the supplier in the elaboration phase. In other words, there are ‘linkage economies’ at play. Because the supplier firm performs high-level design activities as well as execution, it increases the efficiency of each of these activities. The supplier relies on the cognitive proximity of in-house staff in order to ‘transfer’ these specifications to the execution team in the offshore development centre.

This is a key difference between outsourcing guided by core competence strategy and outsourcing by firms that have adopted the open business model. D’Costa (2003; 2004) is the scholar who has undertaken the most in-depth assessment of the constraints associated with the core competence paradigm of software outsourcing. He showed that one of the key constraints arose from the way outsourcing relationships were structured:

No firm wants to co-locate critical projects overseas due to coordination and communication problems… These problems arise because of the ‘modular’ approach to software development. Each project/product is decomposed into self-contained modules, each with varying demand on tacit knowledge, making it possible to co-locate certain modules in certain places. However, the tension between increasing coordination costs and the criticality of certain modules limits what can be done offshore in India. Total learning with modular projects is constrained since exposure of Indian engineers to innovative projects is only partial. This hinders domain and systems integration expertise, spheres of considerable import for building competence. It also limits ‘transferability’ of tacit knowledge as user-based interaction is

geographically dispersed modular software outsourcing risky, thereby limiting suppliers’ market exposure.

(D’Costa 2004: 57)

This was confirmed in previous work by this author. Because of the ‘modular approach’ to software development, learning possibilities in the supply base tended to be constrained because exposure to critical capabilities and end-users was limited (Lema 2009a). The findings of the present study suggest, however, that outsourcing in the open business model shows different features.

In the core competence business model, buyers seek to limit outsourcing to implementation activities. These implementation activities are easier to codify than higher-order activities.

However, in the open business model, buyers often seek to leverage supplier assets in higher-order activities. This means that that the buyer needs to draw the supplier into the architecture and sometimes even the ‘vision’ of the project (see Table 3.2). Activities in these stages are much more difficult to codify and the previously ‘modular’ pinch-point interface between buyer and supplier changes character. The literature led us to hypothesise that requirement definition will be kept in- house by buyer firms. This was addressed in Section 5.2. However, as the three case studies showed, the advent of open business models means that in reality this is not clear-cut. The case material suggests that there are differences between buyer segments in this regard. Electronics and telecom firms mainly outsource problem-solving and innovation support activities. Engineering services tend to feed into highly coordinated networks and innovation processes in which Indian service providers play a specialised and bounded role. The buyers provide carefully defined and limited spaces in which suppliers can operate. In the

software buyer segments (primary and secondary), the adopters of open business models do not always follow such a practice. As the case studies illustrated, suppliers are now often invited to participate in requirement definition activities in a substantial way.

These differences are related to the pattern identified in the previous section which distinguished between standalone and integrated innovation activities. Using this terminology, the overall pattern that emerges is:

z When innovation takes a standalone character, software suppliers are not

engaged in problem-framing activities.

z When innovation and production are integrated, there is a greater scope or

incentive for involving suppliers in problem-framing activities.

The case studies indicated that innovation emerges as an incremental extension of ‘standard’ outsourcing and it becomes subject to competition and market dynamics. But these constraints are only translated into innovation outsourcing because of the advent of open business models in which an increasing number of assets – including assets that were until recently perceived as ‘core’ – are shifted from ‘fixed’ to ‘variable’ status in the client organisation. Software architecture capabilities, for instance, have become more variable. Buyer firms may deploy their own architects or use those of a supplier. This is where the integrated type of

57 This insight is generated not only from the examination of buyer–supplier relationships and information provided by client informants. Fieldwork on the supplier side that investigated ‘innovation events’ showed that suppliers operating in tightly connected settings were much more likely to engage in requirement definition than did ‘de-linked’ suppliers.

innovation outsourcing differs from standalone innovation outsourcing. The

development of products and systems is exactly what is outsourced. The logic that enables the sourcing-in of new knowledge and licensable commodity technology but prohibits the externalisation of ‘systems integration’ does not apply. This is why this type of outsourcing is associated with more opportunities for involving suppliers in problem-framing activities.57

These findings are somewhat counterintuitive. Because standalone innovative activities are undertaken within the realm of innovation (e.g. new product development), it is easy to assume that these are ‘most proximate’ to problem framing. However, loose connectedness means that different roles – e.g. systems integration versus modular component provision – can easily be assigned to separate organisations. Typically, there are relatively modest interactive

requirements. In this way, there are limits to functions of the product development processes that are externalised to software suppliers. First, only software-related functions are outsourced. Physical product design and related activities are typically kept in-house (or outsourced to specialised providers of hardware design services). Second, the interface between the software component and the overall product is specified by the overall product design (and the technical standards). This has implications for the division of labour between buyer and supplier. The buyer is overseeing the design of the overall product (e.g. a chip or wireless

Figure 5.1

Problem framing in standalone and integrated innovation