INCLUDING PEOPLE IN COMPUTER INTEGRATED MANUFACTURING DESIGNS
Professor Terry Winograd, Department of Computer Science, Stanford University, USA
Nancy (Tigger) Newman, CIM Software Engineering Co., Ltd., Hong Kong
Peter P. Yim, CIM Systems (Singapore) Pte. Ltd., Singapore
Presented at the ICCIM'91 Conference (Oct. 2-4, 1991, Singapore)
System designers often try to replace humans in systems, limit their actions, or simply avoid areas where humans are inevitably involved. This tendency severely limits the effectiveness of the resulting systems. This paper presents the language/action approach to system design, providing illustrations of why design approaches to computer integrated manufacturing need to design systems with human capabilities and limitations in mind. It then presents a basic introduction to the language/action approach and some of the area's current research and tools.
I. THE NEED FOR AN INCLUSIVE APPROACH
Eighteen years after the term "Computer Integrated Manufacturing (CIM)" was coined, CIM has grown from an abstract concept about only the manufacturing plant, to a reality which can include an entire manufacturing enterprise, encompassing marketing, engineering, production design, logistics, administration, finance and a wide variety of other vital functions. With this system integration comes a need for recognizing, allowing for, and using the fact that people are involved in all manufacturing enterprises.
Many projects have tried to minimize or eliminate manufacturing's reliance on humans by adopting a planning/knowledge perspective to look at models for the planning and automation of the product design, scheduling, and production work that people are doing. Much of the work in artificial intelligence has focused on this goal of eliminating reliance on humans for many tasks. There has been progress along these lines, but the "lights out" factory of the future, the dream of the 1980's, is nowhere near commonplace. This is partly due to our current inability to replicate all human functions.
A number of people, including computer scientists who have been part of developing artificial intelligence systems (for example, Winograd and Flores (1)), have challenged the idea that we are anywhere near creating machines that are truly intelligent. There are deep debates about whether true artificial intelligence will ever be possible, but it is clear that despite early promises, artificial intelligence has not come close to achieving results that would make humans unnecessary in any but the most straightforward aspects of manufacturing and other realms of practical activity.
Artificial intelligence has provided valuable tools for Computer Integrated Manufacturing, providing decision support, job shop scheduling, process planning, assembly robots, monitoring systems, and a variety of other aids to manufacturing. In addition to other technologies involved in computer integrated manufacturing, artificial intelligence techniques have been very successful in supplementing and augmenting human capabilities. However, humans are still involved in a wide variety of jobs such as design, planning, decision making and exception handling.
This is especially apparent when integration is designed for an entire manufacturing enterprise, not just the factory floor. To be successful, a manufacturing enterprise needs to not only have an excellent factory floor, it also needs competent marketing, company planning, distribution, financial and other support.
Many projects have tried to include people from an information/communication perspective that deals with the problems of sharing and standardizing the information produced and used by various people and programs. This perspective still doesn't focus on people as drivers of the process, rather it treats them as producers and consumers of objects of information, such as memos, reports, blueprints, etc. The issues that get considered under this perspective include the structure of specifications, how the tooling instructions are transmitted, the process of going from the specifications to purchase orders for the various components, etc.
We are approaching the problem from a third starting point, the language/action perspective, which focuses on the means for organizing and coordinating work. This perspective does not exclude other approaches, but puts them inside a framework that looks not only at what is supposed to happen, but why it should happen, and what are the possible solutions if events don't happen as planned.
In focusing on the form and transmission of information, traditional computer system design tends to fall short of clearly identifying the underlying work that is currently being accomplished and easily misses the possibility of changing the process to make it more effective, instead of just making the current system faster. This neglect stems not from a lack of caring, but from the use of a different set of questions: a set that relies much more on formal job or task descriptions than on a sense that jobs or tasks are part of how groups of people interact to get things done. The language/action perspective begins with a different set of questions designed to go beyond the job descriptions to discover the context of the current tasks and reveal the potential for improvement and the need for maintaining a capability for negotiation, correction, and anticipatory action.
Part of the language/action perspectives then, is an understanding that formal job or task descriptions tell only part of the story, a very idealistic part of the story. The language/action perspective helps to avoid the following idealistic assumptions that underlie many projects:
Fully describable: All of the different factors that are relevant to people in determining their actions can be expressed as part of the model and their interactions included in the associated charts or rule bases.
Fully online: The user will be able to access the system whenever it is relevant to the work, and will check for updated information whenever it might have an impact on what is going on.
Fully informative: As work progresses, the user will enter reports on all aspects of the work to keep the databases up to date so the models can be kept updated.
Fully accurate: Entries in the model will correspond to what is actually going on, and people will carry out their activities to faithfully correspond to it.
Fully responsible: When given a task, the user will agree on a completion time and complete it as specified.
Of course, nobody takes this ideal as the reality, but in much of the discussion of computer integrated manufacturing, the focus of design is on those aspects that would support the idealization, with emphasis placed on developing techniques for information sharing, model updating, task reorganization, etc. There is correspondingly little attention to what it means to operate computer integrated manufacturing enterprises in a world where human assistance is necessary and involves the following realities of human behavior.
Partially informative and accurate: People leave things out, make mistakes, and often just can't be bother to take time out to do the "paperwork", even if it is on a CRT screen or portable terminal or workstation. This results in two design requirements: to have the system robust in handling missing or faulty information and to organize it so that from the point of the people being asked to enter information (not just the people who will use it down the line), there is a real payoff in entering the information.
Partially responsible: Only a small part of the business of managing a CIM enterprise can be adequately modeled with the kind of planning and rational decision making that we find in theoretical books and that we often imitate with artificial intelligence programs. To manage is to be continually able to cope with unexpected breakdowns and to see and act on new possibilities. This includes the fact that people will often not do what is expected of them. They may simply fail or they may do something different or even better. They often postpone doing things (especially things that aren't directly needed for their own actions), change their minds, and need to be reminded to do things.
The key to keeping things going in the face of these realities is to be in communication (thus the current popularity of "management by walking around") and to keep maximal clarity in mutually understanding the state of the commitments that one person or organization makes to another. This is a "people oriented" rather than "model oriented" view of the work and is the focus of the language/action approach to design.
II. THE LANGUAGE/ACTION APPROACH
It is the communication that people have with each other that binds together and makes successful the entire CIM enterprise: material, purchasing, stores, equipment, shop floor, finance, administration, strategic planning, methodologies, information, knowledge, computer software and hardware, quality assurance, etc. These factors all need to work in concert to achieve the goals of the enterprise and interact successfully with suppliers, creditors, customers, regulatory agencies, etc. The language/action perspective provides a technique of modeling and analyzing these commitments and interactions between different entities within the enterprise and with outside entities.
This modeling is focused on workflows, the patterns of communication and commitment that people use in working together. A full explanation of the language/action approach will not be given here but can be found in the literature, such as Winograd & Flores (1), Flores & Ludlow (2), Flores (3), Winograd (4), Dunham (5), Kensing & Winograd (6), and Newman & Winograd (7). The following list briefly summarizes the major aspects of the language/action approach.
1. Workflows are made up of communications (speech acts). Everything else, such as products produced, documents produced, etc. can be analyzed in terms of their place within this overarching framework of language/actions.
2. This language/action framework is composed of fundamental speech acts, including the following:
request: an agent requests a product or service from another agent, such as customers requesting products, the materials department requesting supplies from purchasing, the finance department requesting capital from the bank, or an employee requesting annual leave.
promise: an agent agrees to provide the requested service or product, such as promising to deliver a product or to pay a newly hired employee.
report: an agent reports that an action has been completed or an event has occurred, such as a report that all promised goods have been delivered or that a certain machine has been repaired.
declare: an agent declares something to be true, and thereby makes it true, such as the purchasing department declaring that a given vendor will be put on the preferred vendor list or the engineering department declaring that all equipment are required to have routine maintenance once every month.
3. These and other language actions are linked into coherent patterns, which can be found in every work setting. In previous language/action work, these patterns of language actions have sometimes been called "conversations"; in more recent work (including this paper) we refer to them as "workflows" to reflect their purposeful nature and to avoid the connotations of undirectedness that often accompanies the word "conversation".
One type of typical workflow moves from a request, such as a person requesting supplies, to a promise, such as a vendor agreeing to deliver, to a report that the goods were delivered, to a declaration that the goods were satisfactorily received and payment should be made.
4. These workflows are themselves linked together through agents, breakdowns, and routines.
Agents: Agents can be individuals, companies, departments, organizations, etc. workflows can be linked through an agent that participates in both workflows.
Breakdowns: Breakdowns are declarations by an agent that something is missing or new, a solution to a problem that needs to be handled or an opportunity that needs to be considered, plus a declaration that how the situation is resolved will make a difference to some agent. (Breakdowns are referred to as 'gaps" in some recent language/action literature to avoid the unnecessarily negative connotations of "breakdown"; even when work is running smoothly, there is always something that still needs to be resolved in an unfinished job, even if it is only the next standard step in the process.) Workflows can be linked through breakdowns, as one workflow's breakdown can trigger actions in other workflows or even cause a new workflow to be started. For example, the incoming quality control department's acceptance of a shipment of components triggers the "declare satisfaction" stage of the workflow in which the components were requested from the vendor. On the other hand, if the incoming quality control department does not approve the shipment, this can trigger a new workflow for deciding the disposition of the components.
Routines: Routines bring together a series of language actions and physical activities which recurrently are done together as part of carrying out a role. Typically they have a clear spatio temporal continuity, as in the routine that store clerks go through to process incoming material or the routines that people do upon coming into their workplace in the morning. Workflows can be linked through routines since a single routine can contain actions that participate in several different workflows.
5. Many of these workflows and the interconnections between workflows are recurrent and can be used as a basis for the design of integrated systems. These recurrent workflows and interconnections can be seen when analyzing a manufacturing enterprise's interactions both internally and externally. Externally, these include requesting bank financing, offering products to customers, requesting supplies, reporting completion of jobs, requesting payment, etc. Internally, the patterns can be seen as well in supply requests, job scheduling to meet commitments to customers, staffing assignments, annual leave requests, union negotiations, license and permit applications, etc. All of these workflows are interlinked in ways that can be modeled, analyzed and designed for by the language/action approach.
By focusing on the language actions, workflows and their interconnections, the language/action approach provides an effective technique for designing integrated, realistic systems that take into account both the inherent need for humans to be involved in the manufacturing enterprise, and the reality that projects commonly are not fully describable, the system not fully online, the user not fully informative to the system, the data entry and people's actions not fully accurate, and the people's actions not filly responsible. The language/action approach avoids these common systems design pitfalls through designing with the existence of people, their capabilities, limitations, creativity, and their participation in workflows in mind. Rather than automating official job descriptions as do many design approaches, it provides a structured approach to determining current work practices and interconnections, and to redesigning and providing appropriate computer support for those patterns.
III. EXAMPLES OF CURRENT RESEARCH AND TOOLS USING THE LANGUAGE/ACTION APPROACH
The language/action approach is already being used for analysis and system construction in various fields. This section will present some types of work using this approach, along with brief descriptions and relevant citations for each type listed, including one published in these proceedings.
1. Conversation Management Groupware
The Coordinator System [TM] program, developed by Action Technologies, Inc., provides a general basis for managing workflows, tying together electronic mail communication into structured workflows, integrated with a conversational database, personal and group calendars, file management, and many other facilities, as discussed in Flores et al. (8), and Winograd (9). The design of The Coordinator is based on the original language action work done by Winograd and Flores. (Winograd is a co-founder and a consultant of Action Technologies, Inc.) The Coordinator provides a structure based on the universal patterns of workflow, but does not provide for more specific patterns that are based on the recurrent structure of a specific work task or organization.
2. Studies of Coordination Intensive Work
In depth studies of coordination intensive work have been conducted to provide the language/action approach with a corpus of rich data to explore and further develop the analytical framework. In these studies, detailed observations were made of work in settings such as the operations room coordinating ground activities for an airline at a major airport (Kensing & Winograd (6)), and the coordination center for people and equipment in a large construction firm (Newman & Winograd (7)). These observations were organized into "work maps" using the language/action framework. The goal of such maps is to serve as the basis for identifying possibilities for system design, and anticipating the effects they will have in changing workflow patterns. In these studies the goal was not to produce a design, but to refine the application of the language/action perspective by dealing with the complexities of real situations in the analysis.
3. Workflow Design and Application Platform
New platforms and program for designing and executing workflows are being developed under the context of "Business Design Technology" by Action Technology and its associates. The technology goes beyond the general support provided by The Coordinator to incorporate user designed workflows. These user designed workflows are created from the basic workflow types (requests, promises, offers, etc.). Both user-designed and basic workflows model important business processes, including the pervasive cycle of "Customer Makes Request", "Performer Promises To Fulfill Request", "Performer Reports Completion", and "Customer Declares Satisfaction".
This technology is designed as a platform which links other pre-existing databases, transaction processing, and other systems with the workflow structure, control, and monitoring. In addition, these workflows can include automated agents and inter-process linking. This development will provide a generic platform whereby businesses can design systems to enable "customer satisfaction" by driving towards and tracking the completion of workflows. A fuller description is provided by Dunham (5).
4. Integrated Man-Machine Manufacturing
Yim (10), Newman, and their CIM Systems and Software Engineering colleagues are developing the system architecture, the modeling technique and CASE methodology in what Yim has termed CIM3 (Computer Integrated Man-Machine Manufacturing) Systems. They are incorporating the language/action perspective into traditional Computer Integrated Manufacturing system designs -- integrating not only the "islands of automation", but also the people in manufacturing enterprises to form integrated man-machine manufacturing systems. It is envisaged that the system thus created shall more adequately support managers coping with irregularities and complexities of the real manufacturing world. For example, consider the use of the language/action perspective to model the order cycle (which starts with a customer placing an order and ends with the customer's acceptance of the delivery). This example clearly shows that the system is very much a "pull system" that is consistent with the JIT (just in time) concept that is gaining much popularity in management, especially in the manufacturing world. In addition to their theoretical and systems development, Yim, Newman, and their colleagues are using this work to build a pilot implementation of CIM3 in a printed circuit board assembly (PCBA) plant.
In this paper we have introduced an overall approach which will be of increasing importance to the computer integrated manufacturing community. The language/action approach addresses a set of questions which are commonly ignored or their answers dangerously assumed by other design approaches. The language/action approach allows an integrated approach to including humans into computer integrated systems, allowing more feasible and effective solutions which are more comprehensive as well, integrating more aspects of a manufacturing enterprise than was previously possible.
(1) Winograd, Terry and Fernando Flores, "Understanding Computers and Cognition: A New Foundation for Design", (220 pp.) Norwood, NJ: Ablex, 1986.
(2) Flores, Fernando C., and Juan J. Ludlow, "Doing and Speaking in the Office", in G. Fick and R. Sprague (eds.), DSS: Issues and Challenges, London Pergamon Press, 1981.
(3) Flores, C. F., "Management and Communication in the Office of the Future", Unpublished doctoral dissertation, University of California at Berkeley, 1981.
(4) Winograd Terry, "A Language/Action Perspective on the Design of Cooperative Work," Human Computer Interaction, 3:1 (1987 88) pp. 3 30.
(5) Dunham, Bob, "Business Design Technology: Software Development for Customer Satisfaction", IEEE Press, Proceedings of the 24th Annual Hawaii International Conference on Systems Sciences, 1991, 792 798.
(6) Kensing, Finn, and Terry Winograd, "The Language/Action Approach to Design of Computer Support for Cooperative Work", to be presented at the IFIP TC8 Conference on Collaborative Work, Social Communications, and Information, Helsinki, August 1991.
(7) Newman, Nancy (Tigger), and Terry Winograd, "Whats Going on Here? Using Interpretive Workflow Mapping with the Language/Action Perspective to Analyze Current Work Patterns", in progress
(8) Flores, Fernando, Michael Graves, Bradley Hartfield, and Terry Winograd, "Computer Systems and the Design of Organizational Interaction", ACM Transactions on Office Information Systems, 6:2 (April, 1988), pp. 153-172
(9) Winograd, Terry, "Where the Action Is," BYTE, December, 1988, pp. 256A 260.
(10) Yim, Peter, "CIM3 - Computer Integrated Man-Machine Manufacturing Systems, An Introduction, ICCIM'91 Proceedings, Oct. 1991.
- end -