Susan A. Sherer

Critical Success Factors for Manufacturing Networks as Perceived by Network Coordinators

While networking among small and medium‐sized manufacturing firms (SMEs) is a growing phenomenon, there has been little empirical study of the factors that lead to the success of these networks. This study identifies the following eight success factors for manufacturing networks of SMEs, which are ranked by perceived degree of importance to the success of the network: (1) participant character; (2) chief executive officer (CEO) support; (3) confidence; (4) dedication; (5) capabilities; (6) external relationships; (7) intermediary; and (8) information technology. Four success factors were perceived to be significantly more important in joint production and marketing networks compared to joint learning and resource sharing networks: (1) participant character; (2) confidence; (3) external relationships; and (4) information technology.

From supply‐chain management to value network advocacy: implications for e‐supply chains

Purpose – To introduce a broader concept for supply‐chain management (SCM), the notion of value network advocacy.Design/methodology/approach – The historical roots and the traditional terms used to describe SCM are explored to show how their meanings have led to specific types of information systems to support SCM. The limitations of these systems are demonstrated with case studies. Then the concept of value network advocacy is introduced to address these limitations, and implications of this term are explored.Findings – The term SCM has its historical roots in the control of fulfillment activities that support the linear physical flow of goods from suppliers to manufacturers to distributors to retailers. Consequently many information systems (IS) applications that support the supply chain have a similar focus. These systems often separate supply from demand management and focus on linear information flows. Often they are implemented without reengineering business processes. A broader concept, value netwo...

Information Systems Risks and Risk Factors: Are They Mostly About Information Systems?

This article is the second of two whose goal is to advance the discussion of IS risk by addressing limitations of the current IS risk literature. The first article [Alter and Sherer, 2004] presented a general, but broadly adaptable model of system-related risk that addressed the limited usefulness of existing IS risk models for business managers. In this article, we focus on organizing risk factors to make them more useful and meaningful for business managers. This article shows how the nine elements of the work system framework can be used to organize the hundreds of risk factors in the IS risk literature. It also shows that many of the most important and most commonly cited risk factors for IS in operation and IS projects are actually risk factors for work systems in general. Furthermore, risk factors initially associated with one type of system (e.g. ERP implementation) are often equally relevant at other levels (e.g., information systems projects or work systems in general). Over half of the risk factors in a representative sample of the IS risk literature are valid for work systems in general. This conclusion is a step toward useful risk diagnostic tools based on an organized set of risk factors that are meaningful to business managers and IT professionals.

Software fault prediction

Abstract Cost-effective and timely software development methods are essential today as software costs and backlogs escalate while applications are developed in rapidly changing environments. Focusing testing efforts on those portions of the code with the largest number of faults can reduce development costs and time, but requires prediction of the potential location of faults. This study is an attempt to determine whether these predictions can be made by applying neural networks to predict faults in several National Aeronautics and Space Administration software development projects. We found that neither code size nor subjective factors describing the problem, schedule, personnel, process, product, and development environment provided enough information with which to predict the total number of faults in highly fault-prone modules. However, if faults tend to cluster, then identification of fault-prone modules through initial testing could guide subsequent testing efforts that focus on these modules.

The three dimensions of software risk: technical, organizational, and environmental

The technical dimension of software risk results from uncertainty in the task and procedures, the organizational dimension results from poor communication and organizational structure, and the environmental dimension results from changing environments and problems with external relationships with software developers and/or users. Risk management procedures that address each risk dimension are surveyed, suggesting that future work should concentrate on managing the organizational dimension of risk, in particular, the culture changes that accompany the installation of new information systems, and the environmental dimension, i.e., reducing risk in relationships with both software vendors and partners in information alliances and continually adapting systems to changing environments.<<ETX>>

Editorial—IT Investment Payoff in E-Business Environments: Research Issues

E-business environments pose unique challenges to the measurement of information technology payoff. In this paper we discuss some of those challenges as stemming from issues such as the productivity paradox, level of measurement, choice of metrics and the process of measurement. Further, we discuss those characteristics that make investments in E-business environment different from other types of IT investment. In doing so, we draw upon the contribution of the papers in this special issue of Information Systems Frontiers and conclude with our proposal for areas where further research needs to be conducted.

Purchasing software systems: managing the risk

Abstract Companies no longer develop customized systems for every application. In fact, the growth in specialized software companies, coupled with diverse skill requirements, rapidly changing technology, and increased demand for automated applications provide impetus for purchasing software products. These must often be tailored in order to satisfy unique requirements, then integrated with existing facilities. Software purchase can reduce some components of risk, such as attempting to produce a system with inadequate technology or personnel. However, it can increase others; e.g., the system fails to provide needed functionality or the buyer becomes dependent upon the supplier for future support. We discuss the different components of risk in software purchase and then focus on the risk that the software fails to operate correctly in the user environment. A case study demonstrates how formal methodology to assess failure risk can be integrated into decisions regarding the purchase and installation of software.

A cost-effective approach to testing

A method for assessing the differential risk of failure among a systems modules is proposed. The procedure has three components: external-risk assessment, module exposure, and module-failure likelihood. External-risk assessment is a consideration of the systems environment, almost independent of the softwares details. To estimate module exposure, the model relates individual modules and their potential faults to the external-failure modes and their economic consequences by reverse-engineering the specifications and analyzing each modules expected use. To estimate failure likelihood, the method uses a reliability model. The method constitutes theoretical foundation for the cost-effective development of software that attempts to reduce the risk of failure. Managers can use the failure-risk estimates to better determine how much testing effort can be economically justified.<<ETX>>

Managing risk beyond the control of IS managers: the role of business management

While most research has focused on managing technical and project risks in information systems, there are many other components of information systems risk that are currently not evaluated and managed effectively. We identify different sources of risk in both intra- and inter-organizational information systems. Many risks are not well managed because they are beyond the control of the software project manager. We suggest that senior business managers should be responsible for managing organizational risk particularly in the early and later stages of an information systems implementation project. These managers must communicate the importance of new systems and change incentive structures to promote effective system use. We suggest the need to evaluate collaborative risk in inter-organizational information systems and provide guidelines for managing this risk using a joint business management team or a trusted intermediary.

IS project selection: the role of strategic vision and IT governance

The prioritization of information systems projects is a function of the strategic vision of the organization. We develop a model of the IT selection process that is based upon the influence of strategic vision. Strategic vision influences both the type of projects considered, the resources allocated to information systems, and the processes and mechanisms for justifying IT investments. Two of the processes that influence the final project selection are the reporting structure of the IS organization and the involvement of a steering committee for investment prioritization. We suggest that this influences the criteria used to make IT investment decisions.