Working papers in Information Systems GENERIFICATION AS ECOLOGY Petter Nielsen WP 1/2016 Copyright © with the author(s). The content of this material is to be considered preliminary. Information Systems Group Department of Informatics University of Oslo Gaustadalléen 23b P.O.Box 1080 Blindern N-0316 Oslo Norway http://www.mn.uio.no/ifi/english/research/groups/is/ Working Papers in Information Systems, University of Oslo 1/2016 Generificaiton as Ecology Petter Nielsen Dept. of informatics University of Oslo P.O. Box 1080 Blindern 0316 Oslo Norway pnielsen@ifi.uio.no Abstract: Making software packages generic and implementing them in organizations is a key activity in systems development. This paper reports from a study of the implementation of a web shop software package in a multinational Telecom company. The aim of the paper is to improve our understanding and conceptualization of such processes. To reach this aim, we use an ecological lens to extend the common perspective on generification and implementation of large scale and corporate-wide software systems in the existing literature. Through the discussion, we show the strengths of this perspective on generification as ecology as bringing focus to the open and multi-levelled nature of generification, the blurred distinction between generification and implementation processes as well as the co-evolving nature of parallel software package implementation projects. This paper is an argument to break up the restricted project focus in information systems research and appreciate the non-lonely nature of organisational implementation projects. Suggested bibliographic references: Nielsen, P. (2016). Generification as Ecology. Working Paper 1/2016. Retrieved from University of Oslo, Information Systems Working Papers website: http://www.mn.uio.no/ifi/english/research/groups/is/publications/working-papers-in-information-systems 2 Working Papers in Information Systems, University of Oslo 1/2016 1. Introduction The challenge of inflexible legacy systems, the cost and scarcity of internal IT resource and the promise of significant cost-savings motivate organisations to use software packages. Developed by software vendors, software packages are not particularly tailored for one organisation, but sensibly designed to serve a range of different organisations and contexts. By reaching a generic nature, through what Pollock et al. (2007) have termed generification work, a significant portion of the investment and maintenance costs of the software becomes shared among many. To achieve their generic nature, software packages must be based on a future-oriented architecture and capture requirements from a wide audience of organisations over time. Although vendors strive to support all organisational requirements, organisations investing in software packages will usually discover that needed functionality is lacking in package. Thus, software packages are usually customised and extended to meet local and often idiosyncratic requirements as a part of its organizational implementation (in this paper we are using implementation as a short form for implementing software in an organization). The choice to invest in a software package by organizations therefore requires careful considerations not only with regard to the choice of vendor and package, but also whether the benefits and the costs of implementing software packages in organizations outweigh in-house developed or commissioned software. Multinational companies are inclined to see a software package as having the potential not only to reduce costs but also as a tool to standardise technology and practices across the organisation. Implementing software across different national contexts is at the same time challenging as it usually involves idiosyncratic and local specificities, related to practices, capabilities, software systems, strategies and market particularities. Still, software vendors are able to make generic software packages, and multinational companies are able to implement them as global standards. Based on a case study of web shops in a multinational telecom company, this paper analyses and discusses the processes involved and the strategy applied when implementing a software package. This discussion adds to and attempts to contribute to the body of research on the standardisation and implementation of large scale and complex information systems in global organisations (e.g. Ciborra et al., 2000). In this body of research, software is seen and understood not as independent code, but in an intricate interplay with multiple levels of organisations, architectures, technology, and people. The case discussed is therefore not simply about defining a software package with optimal functionality and implementing standardised software cost-efficiently. It is so much more than just that; it is about an intricate web of projects and processes of digitalisation, integration, transformation, architecting, diverse local practices, governance and organisational politics. In concurring with the work of Pollock et al. (2007) on generification and generification work, this paper emphasises the need to focus on how general solutions are made generic, and not only on how difficult it is to make the general specific. The existing body of research on the implementation of software packages in global organizations (standardisation) and the development of standardized software packages (generification) has focused on the conflict between local and global needs and strategies 3 Working Papers in Information Systems, University of Oslo 1/2016 for incorporating local requirements into global standards. In this paper, it argued that both the standardization and the generification literature at the same time have had a too narrow perspective on standardization and generification. It appears as processes of generification is closed and confined within vendor driven projects and that organisations implement software packages one at the time. The empirical focus on generification has been on software vendors and their strategies. The organisations implementing the software packages are treated only as participants involved in requirement gathering activities and the specification of functionality done by the software vendors. Research on the implementation of software packages in global organizations are not taking seriously into account that individual projects “… only constitutes one of many different projects, activities, ventures, undertakings, problems, issues, decisions, and solutions that gradually pass through the history of its organizational context.” (Engwall, 2003, p. 805). This “lonely” project perspective is common in the studies of information systems projects in general, and packaged software projects in particular (Elbanna 2010). Despite a number of studies of the implementation of software in global organisations and generification strategies and processes, we still have limited knowledge about how software packages are implemented in multinational companies due to a limited project focus. In this paper, we present as study from the point of view of a team implementing a web shop software package in a multinational company. The aim of the research is to understand and better conceptualize this process. At the core of the findings from this research, we emphasize the open, multi-level nature of generification as performed by vendors but also by the implementing organisation as well as the parallel nature of software package implementation projects. We argue that research to a larger degree should open its prevailing limited project focus and discuss the generification of software packages and the implementation of software packages in multinational companies as generification as ecology. Through the analysis, we illustrate the relevance of such a perspective. The main contribution of the paper lies in empirically describing a different generification and implementation story, and filling a gap in the literature on implementing large scale and complex information systems in global organisations by conceptualizing the implementation of software packages as processes unfolding in parallel with other implementation processes and generification as a process involving the implementing organization beyond being a source of requirements. The rest of the paper is designed as follows. In the following section, related research on software package implementation and ecology is discussed. In section three, the qualitative research approach used in this paper is described and discussed. In section four, a case study of the implementation of web shops in a multinational telecom company is presented, followed by a discussion of this process and its dimensions of generification work in section five. 2. Related Research: From Independent Software Projects to Ecosystems 2.1 Implementation of Software Packages While information systems are commonly seen as having the potential to solve a wide range of organizational problems, the literature on how information system implementation projects may be challenged is extensive (for example Hirschheim and Newman, 1991; Swanson, 1988; Walsham, 1993). The more particular challenges of and organizational strategies for implementing software packages have also received 4 Working Papers in Information Systems, University of Oslo 1/2016 substantial attention in the literature. For example, arguing for the potential in packages over custom developed systems, Lucas et al. (1988) early introduced an implementation model based on challenges related to package-organisation misalignment and vendor dependency. Soh and Sia (2004) further explored the potential misalignment between the context of implementation and the context where the software package is embedded. Information systems must be aligned with institutional structures, whether imposed by the nation-state or professions, or voluntarily acquired based on experiences, management decisions or preferences. Software packages are also commonly promoted as reflecting best practices. This has however been questioned – how best practice can be context-free and readily acquired, stored and transferred (Yeow and Sia, 2008). Complicating this further is the complexity of organisations, which typically consists of sub-units with their own particular needs. Other researchers have focused more on the process nature of implementing software packages. Larsen and Myers (1999) questioned package-driven business process re-engineering and how success only can be evaluated over time because software will have implications on the organisation more at large. Pozzebon and Pinsonneault (2005) draw the attention towards the role of internal members (those being involved in configuration) and how external consultants may play a crucial role in the implementation of configurable packages. Further, Hong and Kim (2002) illustrate how packaged software has challenges related to uncertainty in acquisition and hidden cost in implementation. 2.2 Organizational Complexity Software solutions are increasingly interdependent, large scale and assembled from a variety of components not under the control of a single governing body, i.e., they are complex (e.g., Hanseth & Lyytinen, 2010). They are no longer developed and managed as stand-alone and monolithic, but are built and implemented as parts of a larger whole. While systems developers may use conventional systems development methods to develop software components, aligning with and becoming a part of the larger “network” is a different task. A task not only about decomposing complicated requirements and deriving optimal technical designs, but grappling with the complexity that emerges from the heterogeneity of other systems to relate to, other parallel processes and projects, players involved, and the lack of overall control. This complexity poses a challenge to existing theoretical and methodological perspectives in software engineering in general (Sommerville et al., 2012). There is a need to capture and work with the development and implementation of software as based on complex coalitions, emerging and developing over time. The plethora of actors of different kinds involved, the dimension of time and the introduction of software packages as a process of negotiations, must be taken into account (Monteiro et al., 2013). This complexity is not (yet) well reflected in the literature. For example, there is a vast literature on implementation of Enterprise Resource Planning (ERP) systems, reviewed by Aloini et al. (2007). Studying the risks involved in large ERP projects, they summarize a range of important aspects to be considered in implementation projects: Technology, market, financial, operational, organizational and business. They also describe different phases of the ERP life-cycle, from concept (selection), implementation (deployment and integration) to postimplementation (evolution). But at the same time, this literature is not taking into account scale and complexity – software packages are described as packages in terms of being software (only), provided by a single vendor and implemented for one, dedicated purpose. 5 Working Papers in Information Systems, University of Oslo 1/2016 2.3 Standardisation and Generification Due to the components’ heterogeneity and dispersed nature and networked nature, standards are essential building blocks in large-scale and complex information systems (Lyytinen & King, 2006; Hanseth, 2000 and Ciborra et al., 2000). These systems, such as for example enterprise resource planning (ERP) and customer relations management (CRM) systems, which can span multiple organisations and multiple countries, rely on standards to be the glue that holds them together. At the same time, as standards diffuse, more radical changes become difficult centrally to implement and disseminate because the users are distributed and are not under central control, and standards in turn become cumulatively more change resistant (Egyedi, 2002; Hanseth et al., 1996). For that reason, standards are more than neutral technical specifications. A key challenge highlighted in the literature on global standards is that the spread of standards across various settings also requires sensitivity to local contexts by allowing local and situated practices to continue. Universal standards introduced top-down will challenge existing practices with the risk of breaking them down or that the new standard will be rejected. Standardised software comes with risks and potentially substantial costs, making it challenging, if possible at all, to “transport” standards between contexts (e.g., Hanseth & Braa, 2001; Berg, 1999; Walsham, 2001). Making software relevant in one local context may also make the same software irrelevant in others (standardization), software will get entangled with other software (embeddedness) (Monteiro et al., 2013) and there is an inherent mismatch between visions of global and standardized practices and the reality of a wide variety of micro-practices throughout a global organization (Hepsø et. al 2009). Pollock et al. (2007) has pointed to this standardisation literature as being overly focused on the misalliance between standards and local practices and the work necessary to make global standards work locally. They emphasise the need to also take into account the less investigated and understood processes of making software work across contexts. Despite all difficulties, it is hard but still possible to use the same systems and software packages in different settings. They have thus argued for shifting “… the debate from understanding how technologies are made to work within particular settings to how they are built to work across a diverse range of organisational contexts” (Pollock et al., 2007, p. 254). They label this process of making the generic out of the specific generification work, work that enables vendors of software packages to treat different local sites as the same, and develop software packages travelling across context efficiently. At the centre of generification work is the trade-off between the particular and the generic in terms of e.g. prioritising requirements according to their relevance across the customer base and striking a balance between functional diversity and the requirements for local customisation. The standardisation and the generification literature relate to the complexity perspective. However, both strands have a focus on standardisation and generification as processes strategically driven centrally by one focal actor and in a rather unidirectional top-down fashion. Either, the standard is portrayed as propagated from a headquarters in a multinational company to local operations (commonly failing or with limited success), or a vendor is releasing a software package to certain customers. Requirements will be gathered from the local operations or the customers, but the standard and the software package is made centrally. In that sense, the discussion only captures standardisation and generification as processes under the control of a single governing body, as linear and as 6 Working Papers in Information Systems, University of Oslo 1/2016 decoupled from the implementation of the software. Further, the implementation process is portrayed as lonely, as only one software package is implemented in an organization at a time. 2.4 A Software Ecosystem Perspective In this paper, we argue for taking an ecological perspective on generification. The concept of ecology is borrowed from biology and used by information systems researchers to describe networks of diverse actors influencing each other’s and being mutually dependent within a specific (eco)system. Both the standardization and generification literature is based on a rather broad and encompassing socio-technical perspective, taking into account not only the software but also the social in terms of the role of different actors, local practices and institution. In this paper, we argue that these discourses still miss out on key dimensions of generification and the implementation of software in multinational companies, namely the multi-level nature of generification and the simultaneous unfolding of software package implementation projects. We will show that this is a crucial part of the software ecology and key to understand the unfolding of the project described in the case study in this paper. In their review the software ecosystem research, Manikas and Hansen (2013) point at the early definitions of software ecosystems as collections of interconnected software products. Relating to the idea of relations between software systems, Lungu et al. (2010) apply a project oriented perspective and argues that software systems are not developed by projects totally independent of other software projects. Rather, projects unfold at the same time and are influenced by and influencing other projects. Lungu et al. argue for an ecosystem perspective to illuminate these interdependencies and therefore define software ecosystems as: “… a collection of software projects which are developed and evolve together in the same environment.” (p. 265). Manikas and Hansen (ibid) suggest combining these and other definitions into the following definition: " … a set of actors on top of a common technological platform that results in a number of software solutions or services.” (p. 1297). This definition moves beyond the pure technical definition of Lungu et al. (2010), by introducing the social dimension of actors. At the same time, it considers particularly the rather recent phenomena of software platforms, upon which different actors can undertake their software development. Motivated by the prevalence of customizable and configurable products, Dittrich (2014) argues for the importance of better understanding how the development and evolution of software products differs from project-based development of software systems. Based on several case studies, she identifies key differences between project-based and what she terms software eco-systems, related to the interaction of different actors, the technical design and the organization of software development. With a particular focus on software platforms, Dittrich questions the project, and its closure in scope, effort and time, as an adequate point departure. Software platforms involve software development beyond making the platform. Not only will platforms be maintained, but they also open up for continuous innovation and customization to meet local needs. Dittrich further identifies three key features of product software development within ecosystems: 1) Parts of the design and innovation is deferred to other actors closer to the use context; 2) multiple layers of actors customizing and configuring software is involved; 3) and development is 7 Working Papers in Information Systems, University of Oslo 1/2016 driven by different factors such as bug fixes, the need for new features and technical reengineering. In this paper, we are not considering software platforms in particular, but organizational contexts where generification is unfolding on multiple levels and several different actors are implementing different software systems at the same time. While independent in the sense of being based on different approaches, strategies, timelines, and managed and run by different people, the projects also influence each other. Their interdependency spans different technical as well as the social levels in ways which cannot be fully anticipated, what we can term co-evolution (Jansen and Nielsen 2006). Together, these co-evolving processes make up an ecosystem involving multiple and different actors (developers, managers, users etc.) and software packages and generification on multiple levels (by vendors and organisations implementing the package). To summarize, in this paper we will discuss the implementation of a software package in a multinational company. We are extending the existing research on generification and standardisation by applying a broader ecology perspective on implementation and generification by taking into account the multi-level nature of generification and the coevolution of multiple implementation projects. 3. Research Method The empirical setting of this research is the multinational telecommunication company Telco. With its corporate headquarters located in Europe, Telco is one of the larger mobile operators, with 150 million customers, 30.000 employees and, at the time of the study, operations in 11 markets across Europe and Asia. It has a leading position in mobile, Internet and TV services in its home market, while its international presence is primarily based on mobile operations. The particular focus in this paper is an initiative by the Industrialisation Unit (IU) in the corporate headquarters in Telco to renew the local, independent and not standardised web shops in the various Telco operations. This initiative was grounded on activities dating back to 2009, leading up to an attempt to implement a standardised web shop software package during 2012. The initiative turned out to be overly challenging and ultimately failed to reach its primary aims, at least in terms of establishing a globally standardised web shop. These challenges and the complexity of the process triggered the interest of the author to conduct an analysis of the initiative, and what the author saw as a process of increasing openness and interconnection between processes and projects. The author was employed in the R&D unit of Telco, organised as a part of the IU from 2006 to 2012. Engaged as a resource from the R&D unit in the business development programme promoting the web shop initiative, the author was instrumental in driving parts of the standardisation process from the IU side and participated throughout the process. The author was further involved in concrete local web shop projects in markets in Europe as well in Asia. The author also participated in an assessment of the status of web shops and eCommerce in general in all of the operations. Throughout these activities, in addition to other forums and meetings, the author was a part of the ongoing discussions related to web shops on a variety of levels: in the IU, in the operations and in Telco in general. Finally, the author was also engaged in active discussions with the potential vendors of web shops’ software packages. 8 Working Papers in Information Systems, University of Oslo 1/2016 The primary aim of the researcher was not to tease out some “objective” truth about the initiative, but rather, through interpreting the different perspectives of the various people involved, to provide a deeper understanding of the process and to conceptualise this related to standardisation and generification. The researcher thus followed an interpretative kind (Walsham, 1993; 1995) of exploratory case study approach (Yin 2003). A key source for this case study was the experiences of the author. Through his efforts and participation in the implementation process and other related processes, the author developed a deep understanding of what was going on. Because the case study was planned after the initiative was “terminated”, the author was not a participating observer, but rather started out as a pure participant and ended up doing interviews with the other participants post hoc and as a reflecting practitioner. As a participant, the author was deeply involved and interacted in meetings globally and locally, discussion at the IU, discussions with operations, discussions with vendors, and discussions with other units within the IU (sourcing and technology in particular). This research approach will necessarily come with a certain bias. In particular, the researcher was an advocate for standardising the web shops and had the vantage point of the IU throughout the process. This will necessarily be reflected in the choice of data collected and the way they are interpreted. For example, the perspectives and concerns of the software vendors and the Telco operations are less prominent and only based on the researchers interpretations. Their actions are also interpreted in the light of an ultimate goal of standardisation. At the same time, it is the IU vantage point and perspective which triggered and is driving this paper’s argument for conceptualising generification as ecology. This paper is attempts to establish and show the relevance of this perspective by discussing a case of a process driven from and by the corporate headquarters. Establishing whether this conceptualisation also make sense in other cases and from the vantage point of a software package vendor or the local operations of a multinational company will require more research. The fundament of the case study is the author’s recollection of the project and central events. Based on this, a first skeleton of the case was written out. Already at this point in time, the two central themes of this paper was identified and pursued further. One key issue was the way in which the web shop project interacted with and how it was influenced by other parallel software implementation projects. The other was the strategy behind and the attempts towards developing a “local generification” process on top of the software package. Guided by these two fundamental issues, several interviews were conducted to understand what was going on and documents were analysed to see how strategies were reflected. All the web shop project participants from the IU were interviewed. The motivation for only using these “internal” sources was partly because of ease of access. Also, the focus was on the approach of IU in this particular initiative. An alternative would have been to broaden the scope and interview the “whole” network of actors involved or certain slices of it more in depth. This was not possible within the constraints of time and resources. The influence and strategy of the “external” actors are still represented based on the interaction experienced by the author and the interviewees. In addition to the interviews, a range of presentations and other document were collected. A particular focus when analysing the documents was how the web shop project was related to other software implementation projects. The data sources are summarised in table 1 below. 9 Working Papers in Information Systems, University of Oslo Interviews Documents 1/2016 #6 February 2013 Project Manager, Programme Manager, Project Participants from distribution team (2), architecture group in the IU and sourcing group in the IU Total 7 hours, recorded and transcribed (total 54.000 words) #32 May 2009 – January 2013 24 presentations, 5 Minutes of Meetings, 2 Preparation documents and 1 discussion document Presented to project steering committee, the IU management meetings, global management meetings and global management boards Table 1 Data sources The interviews did not follow any written interview guide. They were all fully recorded and transcribed. The interviewees were asked to broadly describe the unfolding of the project, the strategy applied, how this project was different compared to other projects they had participated in, and key challenges and issues. The interviewees were also asked to reflect on what they and Telco could learn from the project. Notes were taken during the interviews. After the interviews, based on the previously identified key issues of parallel implementation projects and the multiple levels of generification, interesting insights were identified from the notes and structured in a separate document. Further, during the transcription of the interviews, key events, challenges, and approaches were highlighted in the text. Subsequently, this text and its highlights were revisited and reflected upon by the author. Also, the transcriptions were searched to build a clear timeline of the project. Finally, the notes and the highlighting in the interviews were seen together, offering key themes to focus on in the description of the case as well as the key issues addressed in the discussion. The contents of the documents were also used to confirm and better understand the strategy and approach of the IU during the project, as well as to document the unfolding of the project. 4. Case: Standardising the Web Shops in Telco In this section, a case study of the implementation of a standardised web shop in Telco is described. We start out by describing the multinational telecom operator Telco, before we go into the details of the implementation project. Telco is a multinational telecom operator, with a decentralised organisation composed of largely independent operations in 11 markets in Europe and Asia. While certain organizational functions are placed at the corporate headquarters, the operations are by and large governed locally. This offers the operations the flexibility to develop their organisations according to their local markets. This organisational setup is, at least from a historical point of view, closely related to the very different nature of the countries Telco operates in. For example, the markets are different in maturity when it comes to the mobile networks in operation (second, third and fourth generation of GSM) and the market sizes range from 600,000 to 1.2 billion inhabitants (and potential customers). As a side-effect of this setup, Telco has as many IT stacks as operations, and there is only a minimum of coordination and standardisation across. Therefore, one important area for improving cost-efficiency identified by the Telco corporate headquarters is to strengthen the coordination of the IT function. Their ambition is to leverage on scale and volume and the unit responsible for this process is the industrialisation unit (IU). 10 Working Papers in Information Systems, University of Oslo 1/2016 4.1 The eCommerce Team and the Web Shop Initiative IU has a dedicated eCommerce team working with web shops. Web shops in Telco have historically been treated as a fringe channel for sales and service, with the wellestablished and traditional retail shops being in focus. As a result, the web shops have been disconnected from other channels. One consequence of this is that customers buying a phone in a Telco web shop cannot pick it up in a retail shop, and the retail shop will not be aware if the customer has been active in the web shop. Telco has not previously coordinated and standardised their web shops globally. This has led to there not only being 11 different web shops in terms of software, but also 11 different web shop strategies and organisations along several dimensions. First, some web shops are based partly on software packages and partly on internal software development efforts, while others are bespoke software. Second, some have fully automated solutions managing complete sale processes, while others are more or less manual. Third, some web shops are operated internally while others have components run by external partners. Fourth, some web shops are partially integrated with back-end support systems while others are run as independent channels. Fifth, some web shops are focused only on selling mobile phones while others focus on top-ups of prepaid subscriptions. This illustrates how the different operations have aligned their web shop with other internal systems, partners in their local markets, as well as according to the market they are operating in. From the very beginning, the eCommerce team appreciated web shops as something more than just selling products and services online. A web shop must deliver powerful and flexible capabilities. These capabilities include linking the web shop and back-office systems to reuse customer and product information and streamline sales and service processes, and the flexibility to launch new products and campaigns in the web shop swiftly. Relevant back office systems include customer relation management, Enterprise Resource Planning and supply chain management. The dialogue between those responsible for the local web shops in Telco and the eCommerce team, and outputs from assessments made early in 2011, indicated that the web shops in Telco performed far below expectations. This was in terms of the sales and service functionality they offer to customers and the functionality and flexibility they offer those administrating the sales and service activities in the web shops. There was a common understanding that customers are not likely to have a particularly positive experience using the different web shops of Telco. At the same time, those administering the channel struggle to be agile enough to meet rapidly changing market demands and have to rely heavily on scarce IT resources and cumbersome manual processes to make things work. During summer and fall of 2011, the eCommerce team launched a Request for Information (RFI) project on web shops. The objective of the RFI was to get more information about different web shop software packages and their vendors, as well as address the feasibility and the potential cost-efficiency of a common and standardised solution in all Telco operations. In the longer term, the aim of the RFI was also to lay the ground for a future Request for Quotations (RFQ) project culminating in the procurement and implementation of a standard web shop software package. A range of mature software packages from different vendors were identified through the RFI, offered by large software companies (like IBM and Oracle) and niche web shop software companies 11 Working Papers in Information Systems, University of Oslo 1/2016 (like Hybris and ElasticPath). While being different in focus, size etc., they all offered more or less the same web shops from a functional point of view. Some of them also offered a telecom accelerator—a template/blueprint for what mobile operators typically require as extra functionality to be able to use the package and thus reduce the time to implement it. The RFI project concluded by identifying 5 potential web shop vendors who seemed capable of delivering the functionality, the user experience and required cost-efficiency for Telco. However, none of the vendors had substantial experience delivering a standard web shop throughout a multinational telecom company. Related to this, the RFI project concluded with a set of key issues to be examined further. The heterogeneity of the back-office systems in the different operations was identified as the most prominent challenge, raising issues of integration costs as well as the possibility and real potential of standardisation. Another conclusion was that there was a need to work with the operations to persuade them to use standard functionality. This strategy had to take into account that some mature operations would possibly feel a standardised software package was inferior compared to what they already had in certain areas where more immature operations would consider it far more advanced than necessary. In terms of business case, the RFI project also identified that market size and online transaction volumes varied significantly from operation to operation. A possible need for a differentiated business model and/or more than one standard to cover basic and advanced web shops according to market potential was identified. Finally, the functional role of the web shop was also questioned: It can, for example, master customer and product data, or just link up with other systems offering this functionality. 4.2 Local and Global Requirements Through meetings and discussions with the operations, a broad range of requirements was identified. In addition to the standard web shops functionality, a range of key areas was pointed out with regard to reducing manual work (automation), independence from IT while making changes (flexibility), and supporting customers as they move between different channels (cross-channel). These requirements were results of the operations’ experience with their own web shops, as well as their knowledge of other, better performing ones. In addition to these functional requirements and the importance of integration, the operations also pointed to other non-functional areas of importance. First, they were concerned about being able to use local system integrators for the implementation and maintenance of a standard web shop. They argued that using a global system integrator would require a lot of resources in terms of bringing them up to speed on the local IT stack. At the same time, a concern was raised that local presence is a requirement in order to secure flexibility and appropriate maintenance. Second, it was also a concern that with increasing transaction volumes in the web shop, the web shop must be scalable. The requirement of uptime will increase accordingly and failover mechanisms (both if the web shop and the back-end systems are failing) become critical. Third, the investment costs of the web shop had to be aligned with the transaction volume in the local market so as to secure a viable business model. Fourth, while some of the immature operations were focused on offering a simple web shop solution for basic phones, the more mature markets required the standard to offer a more advanced web shop (e.g. with Apps for smartphones). The eCommerce team also identified several areas where local and global requirements were at least potentially in conflict. First, a central issue is the amount of integration work 12 Working Papers in Information Systems, University of Oslo 1/2016 to be done due to the heterogeneity of the existing stack of back-office systems. If 80 per cent of the costs of a web shop are related to customisation and integration work, standardising the last 20 per cent will not result in substantial cost savings. The ability to standardise on integration and functionality across the different operations, with a “Telco layer”, was accordingly identified as critical. Second, autonomy was identified as a challenge related to operating a global software package over time. Should the web shops be operated with implementations in all operations, regionally or centrally, and how should change requests and maintenance be performed? Moving processes and decisions away from the local operations will reduce costs globally, but also reduce local flexibility and autonomy. Fourth, the way existing web shops were integrated also seemed challenging. Some of the operations have outsourced parts of the web shop value chain, and parts of the web shop were offered by a third party. While swapping the software to a standardised one did not seem so challenging, the third parties also provided functions in the value chain, such as stock management, distribution and servicing of mobile phones. This setup is much harder to change. To deal with both local and global requirements at the same time, the eCommerce team chose a strategy to involve and work closely with the different operations as well as the other units in the IU. While acknowledging that not all requirements could be met, nor all conflicts between local and global interests solved entirely, staying close to the other involved entities in the process was seen to be important to developing and keeping a common understanding of the promises of and challenges related to a global web shop. 4.3 Relating to other Initiatives: Heterogeneity and Complexity The web shop project did not unfold in a vacuum, but in parallel with and in interaction with a range of other local projects and initiatives by IU. Here, a few of them are briefly described to illustrate the context. A large parallel initiative was run by the IU to identify ways to collocate server parks as well as maintenance and operations staff globally in Telco. Moving towards a shared service organisation, the strategy of Telco was to leverage group synergies, economy of scale and competence, substantial cost reduction through off-shoring, quality improvement through standardisation and reduction of local IT system costs. The eCommerce team saw the success of a standardised web shop for Telco in terms of costsaving potential related to initial investments, but also related to maintenance costs and governance and thus dependent on a shared service centre. However, the shared service centre project was an ongoing project and it could at the time not offer the eCommerce project inputs on how the web shop could be supported, and specify the involved cost elements and potential savings using the future shared centre. The lack of an operative shared service centre not only introduced risk in the business model of the web shop project, but also mandated the initiative to request a software package that could be run locally in the short term, and equally important in regionally or globally service centres in the longer term. The IT unit of the IU was also running a Telco technology architecture project. Their plan was to introduce a standardised architecture and back-office stack throughout Telco on the basis of several design principles ranging from service-oriented architecture (SOA), open interfaces, fine-grained application components to master data management. Through a significant transformation, the ambition was to introduce SOA in the different 13 Working Papers in Information Systems, University of Oslo 1/2016 operations, but also a total back-office system renewal. Telco did not have a global IT architecture and the local architectures of its operations were not optimal, typically struggling with legacy systems and accumulating complexity. From the architecture project’s point of view, the web shop project was an interesting case since they recognised this channel as a central component in the overall architecture, not at least in a digital future. The requirements an efficient web shop poses for integration with backoffice systems were at the same a very strong argument for a renewed and common architecture across Telco. Therefore, during 2012, the architecture project got themselves deeply involved in the web shop project, using it somewhat as a pilot. While the architectural principles championed by the architecture project were reflected in the web shop project, the ongoing nature of the architecture discussions took considerable time and resources. More importantly, the architecture project did not have a fixed functional architecture to support the web shop initiative, but only one in the making. Even more importantly, it turned out, was the fact that the ambitions of the architecture project failed to get enough backing in Telco. Spending significant time with potential vendors during 2011 and 2012 with the aim of identifying a partner and running a proof-of-concept with one of the operations, the architecture project did not get adequate funding from the IU to continue during the autumn of 2012. The web shop initiative therefore had to continue without any clear idea of the future situation in terms of a common architecture. One of the Asian operators also opted for a local web solution in 2011. The eCommerce team could not stop this process, but tried to be pragmatic by pushing the operation to choose a software package from one of their short listed vendors, and in particular persuade them not to choose to develop the web shop from scratch or together with a local partner. The management in the operation agreed that their initiative should be aligned with Telco requirements and they somewhat volunteered as being a pilot. At the same time, they chose a software package and a vendor in a setup that became problematic from a global point of view. First, the selected software package, when compared to other packages, required the most customisation. It was open and flexible, but very little came out-of-the box. One explanation for this choice was cost, since this solution was far cheaper than other options in terms of licences. Second, the contract was not with the software vendor but a small, local integration and implementation partner. This partner agreed to make any customisation for a very low fee, being truly eager to work with this operation. While these decisions can be justified from a local perspective, they were problematic from a global point of view. In particular, the choice of a local implementation partner that had no footprint outside the country made their contractual relationship non-reusable. At the same time, the operation claimed the solution was to be a pilot for the global IU initiative, even if it was not possible to use the same contract across Telco. Another of the Asian operations also decided on a web shop autonomously during the fall of 2012. Their recently hired web shop manager got tough targets and to deliver on them he had to improve the existing web shop quickly. He found his key challenge as the lack of available technical resources for implementing, operating and maintaining a web shop in the local operation. From his point of view, taking part in the IU initiative would take too long and the local market did not generate the volume of transactions he believed would justify a larger investment. Based on previous experiences running web shops as a software-as-a-service model, the manager quickly adopted a web based web shop 14 Working Papers in Information Systems, University of Oslo 1/2016 developed and hosted by a third party. The lack of a standardised architecture and service centre made this decision easy for him. As a final example, during 2011 and into 2012, a digital web shop project was launched by a different Telco Group Unit dealing with digital services. This initiative primarily focused on digital content for smartphones, and not the traditional operator products and services (mobile phones and subscriptions). In early 2012, Telco signed a group-wide agreement with a vendor to deliver a standardised web shop for digital services. While not initially being coordinated, the eCommerce team and the digital services team tried to coordinate their efforts to create synergies and to avoid any overlaps in functionality. This coordination was in particular triggered by the fact that the operations were confused and did not understand the differences between the digital content web shop and the web shop. As a consequence of the coordination activities, the web shop project removed sales of digital content from its scope beyond requiring the web shop to be able to be integrated with a digital storefront. This did however backfire as the digital web shop project was put on hold due to lack of actual buy-in from the operations later in 2012. While initially challenging the web shop project as a “competitor”, the digital web shop project ended up challenging it with an unattended question about how to deal with digital content. To summarise, numerous global and local initiatives influenced and partly overlapped the web shop implementation projects as well as other initiatives. For the local operations and the other units in IU, the choice of renewing the web shop is not only about going for a software package or not. The operations and IU are also considering different operational models locally, and their choice of approach is influenced by issues including transaction volumes, business cases, and internal capacity for implementation, operation and maintenance, as well as considerations related to integration, cross-channel, and flexibility and controlling the value chain. 4.4 Planning and Running the Web Shop RFQ In September 2012, the Request for Quotations (RFQ) was launched and five web shop vendors were invited to participate. The RFQ documentation requested the potential vendors to describe their web shop software and indicate compliance to 446 requirements. In addition to indicating compliance, vendors were asked to indicate whether compliance was generic or would require customisation. Further, the vendors were requested to give price models for a licensed software package and a software-as-a-service solution. The eCommerce team analysed each of the responses and returned to each of the vendors to clarify certain issues. After this, the vendors presented their solution as well as how their solution would handle a set of use cases for the eCommerce team as well as representatives from the operations. The evaluation of the different solutions was based on three core areas: degree of customisation necessary, requirement scores, and showstoppers. To be used as a standard, the solution was to be described as composed of the generic software package (out-ofthe-box), a suggested generic “Telco layer” on top of this for all the operations in Telco, as well as what needs to be customised particularly for each operation. With the development of a generic “Telco layer” on the top of a software package, Telco particular functionality and integration points could be developed only once and reused in the 11 operations. The ratio of functional requirements across these different layers was used as evaluation criteria, where the target was to have as much functionality in the core product, 15 Working Papers in Information Systems, University of Oslo 1/2016 alternatively in the “Telco layer”, as possible. The second area was the scoring according to the 446 requirements. The third area of showstoppers consisted of key critical areas considered important for the success of the web shop. As more soft and qualitative criteria, this concerned compliancy to certain requirements related to multi-channel support, integration approach, and the possibility to be run from a shared service centre. 4.5 Terminating the RFQ Process In December 2012, the project concluded by shortlisting 3 vendors and was ready to start preparing these vendors for commercial negotiations. However, just before starting this process, it became clear that the project would not get a governance model and a clear coordinating role related to a common “Telco layer”. The support for this centrally and from the operations was too weak. Consequently, in practice, there was no decision that web shops and any standardisation activities were to be the responsibility of the IU. In this situation, the eCommerce team did not see any value in pursuing the initiation of a negotiating process with the vendors. Without a standard and some sort of central governance, they did not see any merits of pursuing the matter any further and so the project was terminated. This journey somewhat ended up as a closed circle for the eCommerce team. From identifying the challenges of the independent web shops, establishing requirements in collaboration with the operations, culminating in the formalisation of and preparation for a standard. But, finally then, coming back to square one with independent web shops only and just the continued role of supporting individual operations. The consequences of this way of termination, and what can be called the failure of this project, can be debated. In hindsight, it is pertinent to also reflect upon what could have been done different. The project participants from the IU and the operations had a steep learning curve, establishing a common understanding on what web shop software package can deliver and what it takes to make and accept one common standard. At the same time, the project did not have the required backing from the global level. Another important factor was the failure of parallel projects in delivering e.g. a common architecture, an operative service centre and a web shop for digital content. With these other components in place or in a more mature stage, the web shop project may have ended differently. 5. Discussion The success and failure of standardising software packages in global organizations have been attributed to different factors, ranging from the features of generification processes, the flexibility of software to the nature of institutionalized local practices. The key argument and contribution of this paper lies in its focus on the implementation of a software package in global organisations as unfolding in a dense and complex environment of multiple projects. What we have seen is that the generification space is an ecosystem composed of multiple parallel implementation projects and multiple levels of generification activities. These loosely interconnected initiatives and projects are not necessarily well coordinated while at the same time being dependent on another for their success. 5.1 Parallel Implementation Projects Generification work has been described as focusing on two types of requirements. First, it has captured the fine balance of choosing what functionality to include in the software package and what needs to be custom made at the user site (Pollock et al., 2007). By 16 Working Papers in Information Systems, University of Oslo 1/2016 aggregating functional requirements from a range of customers, software vendors adjust and refine their software packages to accommodate what is common and most important for the most important customers. Second, as long as the software package will interact with other information systems, the generic nature of the software also relates to how easily it can be integrated in a larger IT portfolio (Johannessen & Ellingsen, 2009). In the case of Telco, the web shop project was tightly related to other, parallel projects. For example, the total cost of software packages includes licence and customisation, but also its operation. Operating and hosting the web shops in only one or a few (e.g., regional) sites will save costs. At the same time, the availability of resources to implement and handle a local instance of the software package varies across Telco operations. For some of the operations, there was a lack of resources dedicated for the web shop. Under these circumstances, the software package is irrelevant if it is not backed with additional resources. One approach to this already available in the market is web shops offered as software-as-a-service. While limited on flexibility, with this model the service provider is fully responsible for the operation. Furthermore, the resource situation may change and the willingness and ability to operate locally, regionally and globally may change over time. Thus, the generic nature of the web shop is also related to the operational models supported. In the case of Telco, the ongoing establishment of a shared service centre confused the web shop projects by creating uncertainty about how it would influence the business model as well as whether it would be established in time. Another example is the need for a web shop to be integrated with back-end systems to obtain the required user experience and support for those administering the web shop. For the IU, the web shop had to work with a variety of local architectures. There was no global architecture, and the existing local ones were far from optimal and some of the operations lacked what others had as core components in the architecture, such as a product database. While a global architecture was in the making, this was also an ongoing project. This architecture initiative showed interest for the web shop project and offered input to the architecture of the web shops and its relation to other software components in Telco. In doing so, it delayed the web shop project slightly. More important, when the architecture project was terminated, the web shop project was left with uncoordinated architectures in the 11 operations. The web shop project did not come up with any straight forward solution to this challenge, but approached it by suggesting two different solutions to serve mature and immature operations and their architectures. A requirement related to the software-as-a-service solution serving immature operations lacking important components in the architecture (for example product catalogue) was also that it should be possible to swap to a software package more tightly integrated with the back end system when the operations become ready in the future. To summarise, software attributes in terms for functionality and integration support were prominent parts of the standardisation and implementation of the web shop software package. However, defining and implementing the web shop software package did not unfold alone, but significantly influenced by parallel projects such as the implementation of a shared service centre, renewal of the architecture and the web shop for digital content. The argument here is not to attribute the successfulness of the web shop project to these parallel, but co-evolving projects. Rather, we have shown that ignoring them would leave us with less explanatory power and a weaker understanding of the implementation project. 17 Working Papers in Information Systems, University of Oslo 1/2016 This is reflected in our case as the influence of the parallel projects such as those related to digital content, architecture and shared service centre. 5.2 Multiple levels of generification In the case of Telco, generification work was not an activity performed only by a software vendor in response to organisational requirements, but proceeding in layers also involving Telco in their implementation the software package. When Telco evaluated the different software packages, it became evident that they all required significant work to deliver the needed front-end functionality and back-end integration. While the software packages appeared generic, they were also deemed not generic enough as a standard. They required too much additional implementation work to achieve the necessary economy of scale of a standard. To deal with this, Telco suggested a strategy where they would develop their own generic “Telco layer” on top of the software package. With a “Telco layer”, time-to-market was expected to be shorter, the need for customisation for each operation less and the business case for a standard more viable. This approach is interesting in several ways. The introduction of a second layer of generification comes with another level of trade-offs between local flexibility and global standards. While Telco accepts the limits in the generic nature of the software packages, the question about how much the “Telco layer” should cover functionally and integration-wise remains. From the global Telco perspective, the “Telco layer” should cover as much as possible. For the less mature operations, a turnkey web shop would be preferred. For the mature operations, this is more complicated as the functionality already may exist in other software components. Thus, “internal generification” for Telco was about dealing with and prioritising diverging needs of the operations much in the same way as the software package vendors are dealing with their customers. The economic rationale behind standardising as much as possible may have deep implications on flexibility and the functional architecture of the local operations. At the same time, a “minimum” standard that fits all will lose its generic nature if it necessitates too much particularisation work. This two-layered model and the involved trade-offs between the generic and the particular illustrate a situation with multiple layers of generification work going on. If the operation of a standardised web shop is not made right, it is likely to fragment as a standard over time because the operations will develop their own functionality at the cost of the “Telco layer” and the software package. The “Telco layer” adds complexity to this, since it is not always trivial to decide where new functionality should be implemented— locally, in the “Telco layer” or in the software package. Thus, for Telco and its operations, it is not only the software but also the internal process where new requirements are handled which has to be adequate across different contexts, and thus generic. Generification work in this context is about governing the balance between the particular, the Telco specific and the software package in a way that makes the web shop relevant operationally, and for Telco as a standard over time. Another level of complexity in this setting was the approach to centralisation in the implementation (software) and the operation of the web shops (operational model). For example, the operation of the web shop can be central, while the common software code base can be minimal. Or the code base can be completely standardised, while the web shops can be operated locally and independent. One particular approach to this was the use a software-as-a-service solution. The choice to take this approach was based on accepting the very limited possibilities for customisation. The merit of this approach was that the software code does not travel at all. 18 Working Papers in Information Systems, University of Oslo 1/2016 It comes as a package where the functionality is set and the maintenance and operation is taken care of by the external service provider. The generification argument of Pollock et al. (2007) is based on changing the focus from how difficult it is to implement standardized software in global organizations with different local needs, to how it is actually possible to make global standards. They describe how generification can be based on strategies of discrimination and focus on development of the functionality which makes most value for the most valuable customers. While at the same time offering a good enough product for those not so valuable. This is a strategy which is working. In this paper we have described generification as a process unfolding on many levels, and not confined to organizations developing software packages, but also global organizations making their own, second level, generic package. In many ways, this global organization is facing the same challenges when it comes to give priority to different users and requirements as described by Pollock et al. (ibid). In addition, this second level must also relate to a more fixed customer base – they have to serve all organizational units. It is also less clear who the “most valuable customer” is. In the case of Telco, this was challenging because those business units being ready to implement was most immature and operating in the most immature markets. They therefore also had the weakest business case to invest in a new web shop. To summarize, a perspective on generification as unfolding on multiple levels makes sense to understand the web shop project in Telco. While the software vendors already had made their generic packages, Telco pursued a similar process to make the package generic enough to become a standard. At the same time, their relation to the operations was of a different kind compared to a typical vendor – customer relationship. With this perspective we blur the distinction between the generification and implementation of software packages. And we have shown in the case of Telco that generification is not a project by the software vendors where they finalize the software package, but it unfolds on different levels and it will continue also after the implementation of the software package. 6. Concluding Remarks Telco is a case of a large multinational telecom company, with small governance structures that leave each of its operations to operate mostly as they see fit (with resulting heterogeneity in strategy, organisation, architecture and IT portfolio). The pursuit of the standardisation of web shops, an area considered to be on the fringe by Telco and its operations, is then perhaps an extreme case. In a more “perfect” world, the different operations would have been more centrally controlled and standardised and web shops considered a more important channel. But still, Telco will continue to implement different software packages at the same time and in parallel. They will co-evolve and at certain point in time will intersect and influence each other for good or for bad. As a multinational company, Telco will also need to pursue ways to achieve the right standardised and generic nature of the software package implemented. The particular strategy described in this paper to pursue a local generification process on top of the already generified software package will also be relevant. The empirical research and conceptualisations related to the implementation of large scale and corporate-wide software systems by Ciborra, Hanseth and associates 19 Working Papers in Information Systems, University of Oslo 1/2016 distinguishes itself by dominating the information systems field and by taking, as well as extending, an ensemble view (Orlikowski and Iacono 2001) of information technology by taking into account what they term information infrastructures’ distinctive properties (socio-technical, networked, distributed, etc.). This conceptualisation also explicitly draws upon Actor-Network Theory (ANT) (e.g. Monteiro 2000) and pictures the developments of information infrastructure as an evolutionary process which is intrinsically linked to the interplay between human and technical components. Interestingly, where this literature on the implementation of large scale and complex information systems is based on a socio-technical perspective and explicitly arguing for taking into account heterogeneity and complexity, they describe the context of implementation projects as more or less exempt of other implementation projects. This paper makes the important argument that the implementation process cannot fully be understood if detached from other parallel implementation projects. Implementation projects are not likely to lonely, and their faith is likely to be influenced, if not dictated by other co-evolving implementation projects. In addition, this paper argues for taking into account that generification work unfolds on multiple levels and in a much more blurred and distributed fashion compared to what has been discussed before by Pollock et al. 2007. In this paper we have shown the strength of a perspective on generification as ecology when it breaks up the common perspectives on generification as confined within a vendor project, the blurred borders between generification and implementation, and the co-evolving nature of implementation projects. References Aloini, D., Dulmin, R., and Mininno, V. 2007. “Risk management in ERP project introduction: Review of the literature,” Information & Management (44), pp. 547-567. Berg, M. 1999. “Patient care information systems and health care work: A sociotechnical approach,” International Journal of Medical Informatics (55), pp. 87-101 Ciborra, C. et al. 2000. From Control to Drift: the Dynamics of Corporate Information Infrastructures, Oxford: Oxford University Press. Dittrich, Y. 2014. “Software Engineering Beyond the Project – Sustaining Software Ecosystems”, Information and Software Technology, (56), pp. 1436-1456 Egyedi, T. 2002. “Standards Enhance System Flexibility? Mapping Compatibility Strategies onto Flexibility Objectives,” in Proceedings of EASST 2002 conference, Responsibility under Uncertainty: Science, Technology and Accountability. N. Brown, U. Felt and N. G. e. al. (eds). University of York. July 31 - August 3. Elbanna, A. 2010. “Rethinking IS Project Boundaries in Practice: A Multiple-projects Perspective”, Journal of Strategic Information Systems, (19), pp. 39-51. Engwall, M. 2003. “No Project is an Island: Linking Projects to History and Context”, Research Policy, (32), pp. 789–808 Hanseth, O. and Braa, K. 2001. “Hunting for the treasure at the end of the rainbow. Standardizing corporate IT infrastructure,” Computer Supported Cooperative Work, (10:3-4), pp. 261292. Hanseth, O., Monteiro, E. and Hatling, M. 1996. “Developing Information Infrastructure: the Tension between Standardisation and Flexibility,” Science, Technology and Human Values (11:4), pp. 407-426. Hanseth, O., Jacucci, E., Grisot, M., and Aanestad, M. 2006. “Reflexive Standardization: Side Effects and Complexity in Standard Making,” MIS Quarterly, (30:2), pp. 563–581. 20 Working Papers in Information Systems, University of Oslo 1/2016 Hanseth, O., Lyytinen, K. 2010. “Design theory for dynamic complexity in information infrastructures: the case of building internet,” Journal of Information Technology (25), pp. 1-19. Hepsø, V., Monteiro, E., and Rolland K. 2009. “Ecologies of e-Infrastructures”, Journal of the Association of Information Systems, (10), pp. 430-446 Hirschheim, R., and Newman, M. 1991. “Symbolism and Information Systems Development: Myth, Metaphor and Magic,” Information Systems Research (2:1), pp. 29-62. Johannessen, L. and Ellingsen, G. 2009. “Integration and Generification—Agile Software Development in the Healthcare Market,” Computer Supported Cooperative Work (18), pp. 607–634. Jansen, A. and Nielsen, P. 2005. “Theorizing Convergence: Co- Evolution of Information Infrastructures”, Scandinavian Journal of Information Systems, (17:1), pp. 67-100 Larsen, M. and Myers, M. 1999. “When success turns into failure: a package-drive business process re-engineering project in the financial services industry,” Journal of Strategic Information Systems (8), pp. 395-417 Lucas, C. H., Walton, E. J., and Ginzberg, M. J. 1988. “Implementing Packaged Software,” MIS Quarterly (12:4), pp. 537-549. Lungu, M., Lanza, M., Gîrba, T., and Robbes, R. 2010. “The Small Project Observatory: Visualizing software ecosystems”, Science of Computer Programming, (75), pp. 264-275 Lyytinen, K. and King, J. 2006. “Standard Making: A Critical Research Frontier for Information Systems Research,” MIS Quarterly (30), pp. 405-411. Manikas, K. and Hansen K. 2013. “Software Ecosystems – a Systematic Review”, The Journal of Systems and Software, (86), pp. 1294-1306 Monteiro, E., Pollock, N., Hanseth, O., and Williams, R. (2013). “From Artefacts to Infrastructures,” Computer Supported Cooperative Work (22), pp. 575–607. Monteiro, E. 2000. "Actor-Network Theory and Information Infrastructure." Pp. 71-83 in From Control to Drift: the Dynamics of Corporate Information Infrastructures, edited by C. Ciborra. Oxford: Oxford University Press. Orlikowski, W., and Iacono, S. 2001. "Research Commentary: Desperately Seeking the "IT" in IT Research - a Call to Theorizing the IT Artifact." Information Systems Research, (12:2), pp. 121-134. Pollock, N., Williams, R., and D’Adderio, L. 2007. “Global Software and Its Provenance: Generification Work in the Production of Organizational Software Packages,” Social Studies of Science (37), pp. 254-280. Pozzebon, M., and Pinsonneault, A. 2005. “Global-local Negotiations for Implementing Configurable Packages: The power of Initial Organizational Decisions,” Journal of Strategic Information Systems (14), pp. 121-145. Soh, C., and Sia, S. K. 2004. “An Institutional Perspective on Sources of ERP PackageOrganization Misalignment,” Journal of Strategic Information Systems (13), pp. 375-397. Sommerville, I. et al. 2012. “Large-scale complex IT systems,” Communications of the ACM (55:7), pp. 71-77. Swanson, E. B. 1988. Information System Implementation: Bridging the Gap Between Design and Utilization, Homewood, IL: Irwin Walsham, G. 1993. Interpreting Information Systems in Organizations, Chichester, UK: Wiley. Walsham, G. 2001. Making a World of Difference: IT in a Global Context. Chichester: Wiley. Walsham, G. 1995. “Interpretive Case Studies in IS Research: Nature and Method,” European Journal of Information Systems (4:2), pp. 74-81. Yin, R. 2003. Case Study Research: Designs and Methods. Thousand Oaks, California: SAGE Publications. Yeow, A. and Sia, S. 2008. “Negotiating ‘‘best practices’’ in package software implementation,” Information and Organization (18), pp. 1-28. 21