Selling packaged software: an ethical analysis

Within the IS literature there is little discussion on selling software products in general and especially from the ethical point of view. Similarly, within computer ethics, although there is much interest in professionalism and professional codes, in terms of accountability and responsibility, the spotlight tends to play on safety-critical or life-critical systems, rather than on software oriented towards the more mundane aspects of work organisation and society. With this research gap in mind, we offer a preliminary ethical investigation of packaged software selling. Through an analysis of the features of competition in the market, the global nature of the packaged software market and the nature of product development we conclude that professionalism, as usually conceived in computer ethics, does not apply particularly well to software vendors. Thus, we call for a broader definition of professionalism to include software vendors, not just software developers. Moreover, we acknowledge that with intermediaries, such as implementation consultants, involved in software selling, and the packaged software industry more generally, there are even more “hands” involved. Therefore, we contend that this is an area worthy of further study, which is likely to yield more on the question of accountability

Addressing business agility challenges with enterprise systems

It is clear that systems agility (i.e., having a responsive IT infrastructure that can be changed quickly to meet changing business needs) has become a critical component of organizational agility. However, skeptics continue to suggest that, despite the benefits enterprise system packages provide, they are constraining choices for firms faced with agility challenges. The reason for this skepticism is that the tight integration between different parts of the business that enables many enterprise systems\u27 benefits also increases the systems\u27 complexity, and this increased complexity, say the skeptics, increases the difficulty of changing systems when business needs change. These persistent concerns motivated us to conduct a series of interviews with business and IT managers in 15 firms to identify how they addressed, in total, 57 different business agility challenges. Our analysis suggests that when the challenges involved an enterprise system, firms were able to address a high percentage of their challenges with four options that avoid the difficulties associated with changing the complex core system: capabilities already built-in to the package but not previously used, leveraging globally consistent integrated data already available, using add-on systems available on the market that easily interfaced with the existing enterprise system, and vendor provided patches that automatically updated the code. These findings have important implications for organizations with and without enterprise system architectures

Risk Profiles in Individual Software Development and Packaged Software Implementation Projects: A Delphi Study at a German-Based Financial Services Company

The aim of this paper is to compare risk profiles of individual software development (ISD) and packaged software implementation (PSI) projects. While researchers have investigated risks in either PSI projects or ISD projects, an integrated perspective on how the risk profiles of these two types of information system (IS) projects differ is missing. To explore these differences, this work conducted a Delphi study at a German-based financial services company. The results suggest that: First, ISD projects seem to be more heterogeneous and face a larger variety of risks than the more straightforward PSI projects. Second, ISD projects seem to be particularly prone to risks related to sponsorship, requirements, and project organization. Third, PSI projects tend to be predominantly subject to risks related to technology, project planning, and project completion. Finally, in contrast to available lists of risks in IS projects and irrespective of the project type, the paper found a surprisingly high prominence of technology and testing-related risks

Reasons behind ERP package adoption: a diffusion of innovations perspective

Enterprise Resource Planning (ERP) packages have been widely adopted and it is becoming clear that this is driven by multiple rationales that may be simultaneously at odds and complimentary. In this paper, we aim to develop a greater understanding of these rationales by taking ERP packages to be innovations and analysing their adoption with reference to the theory of diffusion of innovations. In particular, we consider the attributes of ERP packages that may affect their adoption such as relative advantage, compatibility, complexiblity, trialability and observability. We argue that users’ perceptions of these attributes are not always accurate and these ’misconceptions’ can further explain reasons for ERP adoption or rejection. Although our analysis aims to provide rich insights into the adoption of ERP packages, the results of the study are arguably of further interest to the more general study of packaged software and the more established literature on custom development

An Empirical Study of Operational Performance Parity Following Enterprise System Deployment

This paper presents an empirical investigation into whether the implementation of packaged Enterprise Systems (ES) leads to parity in operational performance. Performance change and parity in operational performance are investigated in three geographically defined operating regions of a single firm. Order lead time, the elapsed time between receipt of an order and shipment to a customer, is used as a measure of operational performance. A single ES installation was deployed across all regions of the subject firm\u27s operations.Findings illustrate parity as an immediate consequence of ES deployment. However, differences in rates of performance improvement following deployment eventually result in significant (albeit smaller than pre-deployment) performance differences. An additional consequence of deployment seems to be an increased synchronization of performance across the formerly independent regions

Investigating the Feasibility of Open Development of Operations Support Solutions

The telecommunications Operations Support Systems supply chain must address many stakeholders: R&D, Product and Requirements Management, Purchasing, Systems Integration, Systems Administration and Users. While the management of next generation networks and services poses significant technical challenges, the present supply chain, market configuration, and business practices of the OSS community are an obstacle to rapid innovation. Forums for open development could potentially provide a medium to shorten this supply chain for the deployment of workable systems. This paper discusses the potential benefits and barriers to the open development of OSS for the telecommunications industry. It proposes the use of action research to execute a feasibility study into the open development of OSS software solutions within an industry wide Open OSS project

SAP-Related Education - Status-Quo and Experience

Integrating Enterprise Systems solutions in the curriculum of not only universities but all types of institutes of higher learning has been a major challenge for nearly ten years. Enterprise Systems education is surprisingly well documented in a number of papers on Information Systems education. However, most publications in this area report on the individual experiences of an institution or an academic. This paper focuses on the most popular Enterprise System - SAP - and summarizes the outcomes of a global survey on the status quo of SAP-related education. Based on feedback of 305 lecturers and more than 700 students, it reports on the main factors of Enterprise Systems education including, critical success factors, alternative hosting models, and students’ perceptions. The results show among others an overall increasing interest in advanced SAP solutions and international collaboration, and a high satisfaction with the concept of using Application Hosting Centers

Traveling of Requirements in the Development of Packaged Software: An Investigation of Work Design and Uncertainty

Software requirements, and how they are constructed, shared and translated across software organizations, express uncertainties that software developers need to address through appropriate structuring of the process and the organization at large. To gain new insights into this important phenomenon, we rely on theory of work design and the travelling metaphor to undertake an in-depth qualitative inquiry into recurrent development of packaged software for the utility industry. Using the particular context of software provider GridCo, we examine how requirements are constructed, shared, and translated as they travel across vertical and horizontal boundaries. In revealing insights into these practices, we contribute to theory by conceptualizing how requirements travel, not just locally, but across organizations and time, thereby uncovering new knowledge about the responses to requirement uncertainty in development of packaged software. We also contribute to theory by providing narrative accounts of in situ requirements processes and by revealing practical consequences of organization structure on managing uncertainty

Fears and Triggers: A Conceptual Study of Vendor-Supplied Maintenance and Maintenance Deferral of Standard Package Software

Enterprises rely more on Information Systems (IS) and software than ever before. However the issue of maintaining a vendor-supplied IS, in particular standard packaged software, has been poorly represented within academic literature. This paper presents a conceptual study that synthesises the current state of research concerning the deferral or execution of vendor-supplied maintenance by the purchasing organisation. Based on a systematic review process that adopts the purchaser’s viewpoint, a series of fears and triggers emerge and are captured from the literature. Fears are articulated as reasons for the purchasing organisation deferring the installation of vendor-supplied maintenance, whereas triggers are events that upset the equilibrium of the purchasing organisation’s IS or software and require the installation of the vendor-supplied maintenance to proceed. Although prevalent in literature, fears and triggers have not previously been recognised as an area of focus for academic research