Search Results

In today’s service-oriented economy, information systems are becoming the lifeblood of many organizations. As part of this trend, applications software is an increasingly important and little understood type of process technology. In this chapter we synthesize many of our findings and explore their implications for procuring software in organizations that deliver services. We will argue that it is during the procurement of software and in the planning processes that precede procurement that managers with insight about software design have the most to offer. This book has provided several extended examples of how mission critical software is used in service organizations by operational personnel to assist them in service delivery and by management for monitoring and control purposes. We have shown how service delivery becomes redefined in terms of the combined capability of workers and the integrative functionality designed into mission critical software. We have also shown how software may affect the structure of a service organization and the scope of individual jobs within it. Mission critical software thus serves important integrative functions, such as job restructuring and service redefinition, for the service delivery organization. Although vital to any company’s production capability, process technology is often viewed as an ancillary concern of top management when it comes to purchasing it. Procurement is thought to be best left to technicians who have both the time and inclination to preoccupy themselves with comparison shopping. Many managers are uncomfortable with technological decisions. In large organizations, decisions about new technology tend to be delegated to groups far removed from senior management. Only when procurement costs rise above a certain threshold will the level for such decisions be escalated in the organization. By then, assessments are usually reduced to some sort of financial payback calculation and the substantive issues associated with the proposed technology become submerged. The crucial shortcoming of this approach is that technology acquisition is an important strategic issue, not just a technical matter. By shaping the capabilities of the organization’s production function, process technologies, can dramatically affect productivity, quality, and the range of possibilities for making goods or delivering services.

The software industry really came of age in the 1970s and 1980s. This was a time of technological transformation in the workplace. The computer expanded from the backroom to the front office and evolved from simple data processing to integrated information systems. The growth of the independent software vendor led to an important change in software design. User firms began to purchase large, standard or semicustom systems from thirdparty vendors rather than purchasing software with hardware and having most applications software custom designed by an in-house programming staff. This added another dimension to the software design process: Software became the product of at least two organizations (the vendor and one or more user firms) and its design and production became mediated by the market. The organizational simplicity of software design occurring within one organization, as difficult a process as that may be, became relatively more complex organizationally. This chapter examines one part of the process of technology design and use: the activities internal to the software design firm. It concentrates on the structure and dynamics of the design process rather than on specific design decisions. The findings presented in this chapter are based on a survey of vendor firms and may represent a different perspective than findings on software developed within a user firm. By focusing on dynamics that transcend choices of particular individuals, we show how decisions are shaped and constrained by the structure of the design process itself. The three chapters following this one present case studies that describe specific choices of software features and functions and analyze the impacts of those choices on software users and customers. Taken together, this chapter and the case studies present the dual perspective necessary to appreciate how software is a socially constructed technology. The business applications software industry for mainframes and minicomputers is composed of hardware manufacturers such as IBM and Digital Equipment Corporation, several large vendors, and numbers of small specialty firms.

Social choices characterize applications software design as much as technical engineering issues. In examining software design as a social process we have identified as important issues the tradeoffs and compromises among competing interests and objectives of users and of others in the user organization, the process by which decisions of designers are shaped by their organization, and the role of various pressures in the market. The chapters in Part I explained and justified our basic premise that the interplay of such factors would significantly influence both explicit and implicit design choices. We emphasized how software designs necessarily reflect organizational choices about objectives of different users and others in both the vendor and user organizations. Then in Part II, for each of the cases we studied, we identified a range of design influences and the specific values underlying the social shaping of particular software features and functions. This chapter considers what we have learned from our several case studies and survey. The final two chapters translate these findings into an action agenda for managers (Chapter 8) and consider the implications for research in this area (Chapter 9). Crucial design choices about software that regulates operations of the user organization reflect social choices that may not necessarily be optimal choices. In fact, we found that for many choices there may not be an objectively optimal design; rather, the choices will favor some objectives over others with decisions shaped by organizational politics for example. Indeed, by providing greater integration within the organization, software systems lead to tighter “coupling” of structures in organizations, among different groups and between formal policies and informal practices. The following discussion of the three industries, banking, field service, and hospitals, focuses on the consequences of different choices in software design. The software, as part of its substantive task (e.g., storing information), was designed to automate and control procedures by formalizing them in design, emphasizing managerial control objectives over operations objectives, as it integrated the work of functionally different groups. This emphasis can be traced to the initial choices about features and functions of the software.

Artists leave behind their names on their work and, with their face and story, provide some insight into the design of their creations. Not so with workplace technology. The design of technology often appears as received wisdom. A band of technicians descends upon an office or a factory floor leaving behind artifacts bearing the labels of companies whose names are familiar but whose identities are really anonymous. In some abstract way we all know that inanimate objects are manufactured, the product of human design. Yet, as we handle and look at these artifacts we use everyday, we seldom know the whys and wherefores of their design. We may judge the technology as easy or difficult to use, helpful or unhelpful in accomplishing the task at hand, and regard it as good or bad. But the calculus that went into the design decisions almost always remains a mystery. If we inquire of the designers of a piece of technology, by which we mean those who engineered and made decisions about its features and functionality (decisions beyond its aesthetic appearance, which is a common connotation of design but too limited for our purposes), we are likely to be mesmerized by formulae, calculations, reports of the latest discoveries of science and state-of-the-art engineering. In short, we may be informed that “economy and efficiency” (with perhaps a bit of aesthetics thrown in) are the watchwords of engineering. Engineering is portrayed as an objective enterprise limited only by knowledge and creativity. Many would argue that, provided a task that is well defined and a mission to accomplish, the engineer can proceed to create the optimal technology. To the social scientist these explanations generally form an impenetrable wall that precludes further inquiry. Although the social impact of technology has been widely studied, technology itself is usually treated as a “black box.” Research instead tends to focus on what to do with the black box, how to implement it, not how to create it. Thus social scientists have contributed little (and are seen as offering little) to the task of technology design, except in such realms as human factors for the user interface, a contribution viewed as rather peripheral to the “real” task of engineering.