Keeping the Customer Satisfied: Field Service and the Art of Automation

The “Maytag repairman” is the familiar image of field service. When servicing electronic equipment such as computers, however, the job is significantly more demanding than fixing washing machines. Not only are computers more complex than most other machines, they are also more central to the ongoing operations of an organization. Increasingly, everything an organization does depends upon electronic equipment in some way. Large computer systems are often expected to run 24 hours a day, 365 days a year. When computers are such an integral part of an organization’s operations, maintaining the equipment is tantamount to keeping a person’s heart beating and blood circulating. Thus, unlike the idle television caricature, field service engineers are increasingly viewed as the paramedics for electronics who can quickly and ably respond to system crashes. At the same time that field service has become more demanding, the complexity of the job has increased. The “machinery” of the modern organization is less often composed of gears turning, typewriters clattering, and paper being shuffled. Instead, the sights and sounds of the modern organization consist of screens glowing, keys clicking, and, to the uninitiated, an assemblage of opaque, “black boxes.” Inside these boxes is a miniature world that gives no clue as to the nature of its inner workings. The field service engineer’s (FE) job and function have been growing while the size of the technology itself has been shrinking. His or her skill is less often exercised as a skilled craftworker in the repair of a part and more often as a skilled analyst who can understand the abstract workings and nature of electronics to identify the problem and trace it to the malfunctioning component. The required manual skills are often minimal, just enough dexterity to swap out a bad part for a good one usually suffices. At the same time, the scope of field service has expanded from just repairing worn and broken or defective parts to collecting information about design defects and debugging equipment that may have been released prematurely.

The Structure of Software Design

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 Dimensions of Software Design: Challenges of Effective Design for the Workplace

Software design is enmeshed in the social world of organizations. Software embodies characteristics of the organizations within which and for which it is created. This book has dealt with both of these dimensions; first, the social dimensions of the software design process and, second, the nature of work organizations that the user inhabits and the implications for software design. In this final chapter we develop some general propositions about social dimensions of software design and the implications of software adoption for organizational change. First we draw some concluding observations about two processes. Our research, coupled with related work of others, suggests that crucial to understanding software design (and technology design in general) are the role of history in the long life cycle of software design, especially the redesign of technology by its users, and the politics of software design. Technology design is a process with a life cycle of its own. During this process, design changes occur from the initial stage of determining user requirements through the design and development of the software and then continues during its implementation and use. In retrospect, it is possible to show how different aspects of any particular technology were established at various stages. However, it is not possible to deduce all the attributes of the technology without following the design process through implementation and ultimate use. Understanding the constraints that a technology will impose on the users’ (and the organization’s) “action space” thus requires an examination of the social as well as the technical history of its development. Organizational politics are crucial in the early phases of technology development and provide opportunities for those in positions of power in the user organization to exercise the most explicit influence. Furthermore, past technology and organizational choices form patterns that are institutionalized and form the structure shaping current technology choices (cf. Kling, 1987,1993; Thomas, 1993). Thus, the initial stages of technology definition provide partial constraints on the action of users when the technology is implemented. The late life cycle stages of design are the result of a continual process of actors interpreting and negotiating the technology design and use within structural bounds of hierarchical power, resources, authority and autonomy.

Software Design, Social Choices, and the Workplace

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.

Banking and a Tale of Two Systems

The 1980s were the worst of times for many in the banking industry. Following the deregulation of the early 1980s, the industry nearly went into shock as more than 2,000 banks and savings and loans failed. Banking could no longer be characterized as a staid enterprise of blue pin-striped suits and “banker’s hours.” Deregulation and competition made traditional ways of doing business obsolete and, in many cases, disastrous for banks that failed to adapt. A record number of banks were unable to make the transition successfully and, among those that survived, it was a difficult period that required them to reassess their operations. Software developed for the banking industry during this period reflected the contradictions of an industry in transition. Some banks tried to maintain their traditional values and operating procedures in their system design requirements. However, some software developers found that changes in the banking environment and their own software market required them to consider different values and methods of service delivery in their designs for new systems. A brief account of the industry’s evolution with computer systems sets the stage for the cases presented in this chapter. Banks are large users of computer systems and were among the first large commercial institutions to use computers. Design of banking systems has been affected by changes in technology, external regulation, competition, and the labor market. These changes have combined to define the operational objectives of new computer system designs. During the 1950s and 1960s, banks installed large mainframe systems for back office transaction processing, such as account updating, on a batch system mode. By the 1970s large banks had invested extensively in mainframe computer systems and smaller banks were beginning to adopt computer systems as prices dropped and smaller computers became more powerful. In both large and small banks, computer applications were increasingly introduced to support front office transactions of tellers and customer service representatives in branch offices. Because these systems make data instantly available for a variety of steps in processing transactions, they integrate people throughout the banking organization.

Software in the Workplace

“The Workplace” conjures up images of cavernous factories where people stand shoulder-to-shoulder, dwarfed by huge machines. Though probably a popular image, it describes the conditions of work for less than 15 percent of the working population. Instead, a greater number of people find themselves face-to-face with a computer monitor, whose small displays they depend on for conducting their work. The computer has come to be an intermediary as we do our work. The keyboard, replacing various tools of the trade, has become the common instrument of work, not just in services but also in manufacturing. Work now involves sending instructions to various machines that perform the required tasks, whether retrieving data or turning lathes. Within organizations it has also distanced supervision. Instead of the boss breathing down the worker’s neck, “objective” data on performance are collected and reviewed remotely, at a supervisor’s pleasure and leisure. The mediation of work and regulation of the workplace through use of computer software raises anew central questions about how work should be organized and how the design of software dynamically shapes and reflects the structure of the workplace. New software systems (which expanded, in part, because of new hardware technology) not only dramatically increase the use of information, but also change the structure and working conditions of organizations. The “conversations and connections” that constitute an organization or business are “embodied in the structure of the computer system,” according to Winograd and Flores (1986, p. 169), and thus software design is also the design of the user organization. Depending upon the choices made, computer systems can “reduce the space of possibilities open to workers in organizing their activities” or they can generate new possibilities. In this respect, software is increasingly significant in its effects as it has become an important “process technology” throughout the advanced industrial economies of the world. Until recent years, software was an adjunct technology for most organizations. It was used for a limited set of organizational functions and one or two specific departments were its only direct users. It was commonly viewed as a technology subsidiary to hardware, providing support functions rather than crucial operations for achieving the organization’s goals.

Introduction

The concept of social values shaping technology design seems oddly out-of-place to many. Isn’t the design of technology the province of engineers? Aren’t values and technology and other social issues really outside the scope of engineering? Engineering decisions are not, after all, based on philosophy and sociology some would argue. Efficiency and economy are the objective criteria for making design decisions and these can be determined through a relatively precise calculus. Making these determinations is an objective engineering task not a matter of subjective preferences and interpretation. There is error, of course, and unintended consequences are inevitable, but these are matters to be corrected by better science and engineering. Following in this vein, one might argue that the link between technology design and quality of worklife is even further removed from the concerns of engineering. Technology is delivered “as is” and the work organization must accommodate it. Perhaps technology can be fiddled with at the margins for better ergonomics for example, but again, the essence of design is independent of quality of worklife concerns. To take this argument a step further, it is commonly stated that, for most people, work is not an activity for pleasure but for sustenance. We may wish it were otherwise, but it just isn’t so. Changing technology or other aspects of worklife is, therefore, of limited value in improving the human condition. (In fact, if changes made for worklife improvements decrease productivity, they could be detrimental by lowering prosperity and thus the quality of life outside of work.) One engineer (Florman, 1981, p. 103), writing that “blaming technology” is an “irrational search for scape goats,” states that “alienation cannot be cured by a fascinating job any more than it can be cured by a clean apartment.” Engineers should thus concentrate on designing technology the best they can and leave social issues or workplace concerns to others. It is only the application and implementation of technology that is relevant for social science. So runs the argument in many a discussion about how technology should be designed for the workplace.

Social Shaping of Technology

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.

Understanding and Managing Software Acquisition

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.