Document-centered information systems to support reactive problem-solving in manufacturing

ELSEVIER Int. J. Production Economics 38 (1995) 31-58

intemational joumfal of

production economics

Document-Centered Information Systems to Support Reactive Problem-Solving in Manufacturing

Anant Balakrishnan a, Ravi Kalakotab, Peng Si Ow C and Andrew B. Whlnston b

a Sloan School of Management, M. I. T., Cambridge, MA 02139 email: [email protected]

b Center for Information Systems Management, University of Texas at Austin Austin, TX 78712-1175 email : (kalakota, abw)@uts.cc.utexas.edu

c IBM, Austin, Texas

This paper develops and illustrates a methodology for building document-based information systems to support collaborative manufacturing problem-solving. The paper begins with an exploratory case study to understand the information requirements for reactive problem-solving in manufacturing. We focus on the communication mechanisms, decision-making processes, and implementation issues to address problems that arise due to materials shortage in an electronics assembly plant. Based upon observations from this case study, we describe a conceptual framework for computer-supported reactive problem-solving that emphasizes parsimony and generalizability. The framework consists of 4 layers-organizational process, computational process. data/information model. and network architecture-to link the necessary interactions between people, application systems, database structures, and hardware. To better support the collaborative needs of reactive problem-solving, we extend existing manufacturing information models to incorporate collaborative distributed hypermedia (or interlinked networks of structured multimedia documents), and provide details of a novel strategy to develop computer support for effective reactive problem-solving.

1. INTRODUCTION

esneciallv since managers can no lonaer rely on tr&itio&l mechanisms such as inv&tory-and time buffers to absorb uncertainties and shocks.

To achieve and maintain world-class standards in a competitive marketplace, manufacturing companies are emphasizing “agile” manufacturing-providing the right product or service quickly at low cost, with high quality, and in small lot sizes-through just-in- time manufacturing. greater supply chain integration, concurrent engineering, organization redesign. and increased emphasis on teamwork and organizational learning. The task is especially challenging in industries such as electronics assembly that are characterized by rapid technological changes. and dramatically shrinking product lifecycles. The increasing interdependence and integration of all functions along the innovation and supply chain-design, materials, production, distribution, suppliers- requires more information-sharing and coordination within and across organizational boundaries in order to respond swiftly, but cost effectively, to the changing environment

Information technology (IT). broadly defined to include hardware and software of all kinds, is seen as the key enabler to facilitate the necessary organizational, cultural and process changes to accomplish the ambitious organizational transformation and quantum leap goals. The information system must provide relevant and accurate information rapidly to the right people: it must eliminate the overhead associated with accessing, exploring and analyzing data for routine, as well as unstructured scenarios, facilitate collaboration, and provide support mechanisms for continuous improvement and organizational learning.

Recent advances in IT, such as network publishing, client/server computing, distributed database servers and distributed hypermedia on TCP/IP networks provide the necessary computing and communication infrastructure to support the collaboration and coordination needs of the emerging tightly-coupled organizations.

0925-5273/94/$09.50 @ 1995 - Elsevier Science B.V. All rights reserved. SSDI 0925-5273(94)oooO9-7

32 A. Balakrishnan et al. / Int. J. Production Economics 38 (199.5) 31-58

These advances in technology are useful only if we rethink the basis for manufacturing information systems. For instance, to provide widely accessible, consistent, and up-to-date information, manufacturing-related documents, such as product catalogs, technical manuals, production schedules, engineering designs, and problem reports, are increasingly being digitized and placed on servers or distributed on CD- ROMs. As electronic publishing becomes prominent in manufacturing, research needs to focus on issues involving representation, categorization and management of these rich document-based data warehouses.

This paper attempts to understand and address one component of the manufacturing information system, namely, supporting the process of reactive problem-solving in procurement and manufacturing operations. Reactive problem-solving refers to mechanisms for monitoring and correcting procurement, production, and delivery processes to accommodate unanticipated changes in the environment. Quick response and speedy resolution of problems is critical for tightly- coupled systems such as just-in-time (JIT) or continuous flow manufacturing systems that operate with minimal or no safety stocks and safety times. A disruption in any segment of the chain propagates to the rest of the system, so problems must be resolved quickly in order to maintain acceptable asset utilization levels. In the absence of a well-designed and established resolution process, reactive problems often tend to motivate myopic managerial actions that are solution-centered, restrict innovation, and limit the number of alternatives that are considered due to intense time and performance pressures. Although our main focus is reactive problem- solving, data gathered from this process also forms the basis for continuous improvement and learning. So. one of the functions of the coordination system is to provide the linkage between short-term problem solving and long- term improvement activities.

Developing a coordination support system for reactive problem-solving first requires characterizing operational problems in manufacturing and their information requirements, examining current problem resolution processes, and identifying opportunities for computer-based support. Accordingly, we began this study by working with a large electronics (surface mount) assembly

facility that produces printed circuit boards for computers. To limit the scope of the study, we decided to focus on materials (bare boards and components) shortage problems. In our experience with many companies in the electronics assembly industry, materials shortage is a pervasive problem, leading to frequent disruptions in production schedules, unanticipated setups on the line, and slippage in delivery dates. Materials shortage is also a “multifunctional problem”, requiring inputs and action by suppliers, material managers, production supervisors, quality control personnel, sales representatives, and customers. Therefore, this problem provides a rich domain to observe, conceptualize, and validate systems to support coordination for reactive problem-solving. As part of our study, we interviewed managers and observed several production meetings at the plant. We used this experience to classify the types of reactive problems that managers face, and develop a conceptual problem-solving framework that forms the basis for our proposed information system design.

The remainder of this paper is organized as follows. Section 2 presents our observations in the plant from the point of view of collaboration and coordination for problem-solving. Ba&sed on the case study and a review of the literature on problem-solving, we describe a layered framework in Section 3 that clarifies the different decision support and computing needs during different phases of the process. The purpose of this framework is to highlight the interdependencies between the design of various subsystems-from the user interface to the hardware. The framework is quite generic, permitting implementers to choose a consistent subset of system features that match their specific contexts. Section 3 contains an overview of each layer; subsequent sections discuss each layer in greater depth. Section 4 presents the reactive problem-solving process layer, the organizational process and people interactions (physical or electronic) necessary during each phase of problem-solving. Section 5 describes the computational (hypermedia) process layer that integrates the organizational problem-solving process and the representation of information in the computer system. Finally, Section 6. presents the data/information model to organize the diverse information sources in manufacturing for hypermedia access and processing.

A. Balakrishnan et al. / Int. J. Production Economics 38 (1995) 31-58 33

2,

Component Suppliers Inter-Plant Suppliers External Vendors

e.g. Memory, e.g. Resistors,

Raw Cards Microprocessors

l Stock Room

PPL 1 PPL 2 PPL 6 0.0

Screening

* Topside SMT Placement

9 Reflow

+ Clean-

v Backside Sh4T Placement

* Piq-in-hole Placement

* Manual Placement

* Wave Solder

* Router

v In-circuit Test

* Environmental Stress Ter

9 Final Verification Test

Pull Production Line Process

Customer Order

PPL Schedule

Pack *

Figure 1 : Overview of the Manufacturing Process used in the Case Study

CASE STUDY: MATERIALS SHORTAGE IN ELECTRONICS ASSEMBLY

This section provides a brief overview of the manufacturing operations at the electronics assembly plant we observed, and discusses the nature of day-to-day operational problems with particular emphasis on materials shortage, and the current mechanisms to address these problems. The discussion should help us understand the multifunctional interactions necessary to identify, resolve, and implement solutions to materials shortage contingencies. We can then address issues of information support for this process.

2.1 Overview of Electronics Assembly Operations The plant, called Electronic Card Assembly

and Testing (ECAT), has a staff of 2,000,

working three shifts, and assembles approximately 6,000 electronic circuit boards daily primarily for PC and UNIX workstations. The ECAT division is an intermediate stage in a vertically integrated electronics company _ _ _ _ _ : The plant receives bare printed wtrmg boards and components from various internal (i.e., other divisions of the company, not necessarily co- located) and external suppliers; it ships assembled boards to system assembly divisions as well as directly to distributors and customers. The boards use predominantly surface mount technology (SMT). Figure 1 shows the sequence of processing steps in a typical SMT assembly line (see Prasad [1989] for a detailed description of SMT assembly processes). The ECAT facility operates several SMT assembly lines in parallel to assemble over 120 board types. Each line, called a Pull Production Line or PPL, contains the necessary equipment to fully assemble, test, and

34 A. Balakrishnan et al. / ht. J. Production Economics 38 (1995) 31-58

pack printed circuit boards. To minimi._? setups lines, and shipment of finished products to and maximize equipment utilization, each PPL customers. The materials organization is assembles a limited (predetermined) set of similar responsible for procuring boards, components and products that share many common components supplies, and ensuring adequate supply to meet and require similar processing steps. However, the PPLs’ needs. Component inventory represents products might be dynamically reassigned from the largest class of assets in the plant; hence, unit one PPL to another in order to accommodate cost and inventory levels are important contingencies such as the breakdown of a line or performance metrics for materials management. high priority for shipping certain products. The Managing component inventories effectively is PPLs attempt to operate as continuous flow critical to the business due to significant manufacturing (CFM) operations, with a strong economies of scale, obsolescence, and long emphasis on short-cycle manufacturing. procurement lead times for certain parts.

Each PPL has a manager who is responsible for the quality, throughput, flow time, cost, and delivery performance of that line. To exploit economies of scale and coordinate the different lines, support functions such as purchasing (materials), production planning and control (floor control), and quality are “centralized” for the entire plant. Managers for each of the functional areas-materials, PPLs, floor control, accounting, quality, distribution-report to the Plant Manager. Figure 1 shows the process flow and interrelationships between the various functions in the plant (for convenience, the figure shows only one PPL in detail). Floor control is responsible for scheduling the lines, setting production targets, and providing training to direct employees. Distribution handles the receipt

2.2 Planning and Problem-resolution Mechanisms ECAT employs an elaborate planning

process to develop and monitor long, medium and short-term plans in consultation with other divisions of the company. Every month, the Scheduling department generates a build plan, with inputs and approvals from the materials, production and sales organizations. This plan is fed into the MRP system, which then creates parts order recommendations sufficient to cover the period until next regeneration-normally four or five weeks (see Figure 2). Unanticipated events such as demand shifts, equipment breakdown, or materials shortage must be accommodated through reactive scheduling; we refer to such contingencies as reactive problems.

of corn nents, delivery of components to the

Coordinates Monthly Delivery Commitments

Planning Process to Customer

Monthly Commitments to Customers

bnsmit :o suppliers

weekly targets for PPL

Shipments to Customer

Figure 2 : Manufacturing Planning, Scheduling and Execution Process


Although some of the day-to-day problems can be avoided through systems and procedural improvements (e.g., by improving material control), many contingencies are inevitable due to the dynamic marketplace and the close interdependence between vendors, ECAT and its customers. In general, reactive problems arise due to internal or external events. Examples of internal events include machine breakdown, poor process yield, absenteeism, design changes, and poor planning practices. External events refer to sudden shifts in the marketplace, vendors’ quality and delivery problems, and so on. We can also view reactive problems as unanticipated disruptions of resource availabilities; this view leads us to classify problems according to the affected resources, namely, labor (e.g., absenteeism), equipment (e.g., malfunction or breakdown), and materials (e.g.. quality or availability).

Continuous Flow Manufacturing permits ECAT to be responsive to customer needs with minimal inventories. However, this mode also makes the PPLs very susceptible to reactive problems. Consequently, production is monitored very closely in formal, scheduled meetings (during shift changeovers, daily in the morning and afternoon, and weekly) where day-to-day production problems and weekly performance are discussed. In addition, the floor control group is responsible for monitoring performance continuously (to eliminate delays in reporting problems and taking corrective action), and the plant has several expediters to address urgent materials and production needs.

At the start of each shift, every PPL spends 30 minutes reviewing component inventory levels, work-in-process, week-to-date production levels. and problems encountered during the last shift. At the 9:00 a.m. production status review meeting, the PPL manager raises problems that require assistance from manufacturing support groups, such as materials shortages, information system failures, and process degradation. Attendees at this meeting typically include all the PPL managers, the floor control supervisor(s), representatives from each of the support groups, as well as a representative from a sister plant that supplies the bare boards. The topics discussed at this meeting are:

(i) New or ongoing problems that surfaced during the shift changeover meetings. An appropriate support group might be

assigned the responsibility for resolving each problem. In turn, the support group might request the formation of a cross- functional team to investigate the problem in greater depth.

(ii) Teams responsible for resolving prior problems provide status reports on their work. These reports include descriptions of proposed solutions that various support groups have an opportunity to review for any unforeseen consequences. For example, the quality group might challenge an engineering solution to reduce stress test time in response to a bottleneck at this operation because of this solution’s potential impact on the quality of the fmished product.

(iii) The group reviews the status of resources, identiftes potential problems, and decides necessary changes in production and procurement plans. The agenda typically includes:

(a) a report on critical parts: (b) quality problems reported by customers; (c) process yields; (d) shipping discrepancies: and, (e) printed wiring board fabrication and

delivery schedules.

In general, no one records the minutes of the 9:CKl a.m meeting, but copies of each presentation are distributed to attendees, and relevant reports are mailed to distribution lists that extend beyond the meeting participants. Depending on the urgency of problems raised during the meeting, temporary fixes might be proposed while the team works on a more permanent, comprehensive solution to the original problem.

The ECAT plant manager holds a daily 1245 p.m. meeting to review overall business performance metrics and long-term objectives with senior functional managers, discuss new product and process introductions, communicate customer feedback and demand trends, and discuss the more severe short term order fulfillment problems. Senior managers are responsible for providing guidance to the operating managers by prioritizing the problems that are critical to the business.

The use of monitors, expediters, meetings, and ad hoc teams for coordination and problem- solving is quite commonplace in industry. Our purpose in attending the meetings at ECAT was to gain a better understanding of the purpose, characteristics, pitfalls and decision support

36 A. Balakrishnan et al. / Int. J. Production Economics 38 (1995) 31-58

opportunities for these generic coordination mechanisms. Meetings serve a valuable purpose in breaking down the “functional silos”, facilitating participative management, establishing camaraderie, and enabling rapid, coordinated response to contingencies. However, the size of the group, its composition, and the frequency of meetings must be carefully planned to ensure that they are productive and do not waste managerial time. Information systems can supplement meetings for routine communication, information-sharing, agenda-setting and preparation. Also, daily meetings tend to focus on the many current and pressing problems of the day. Consequently, short-term solutions that alleviate the symptoms temporarily might get institutionalized (because the original stimulus is temporarily out of view, and recent problems get higher priority) without pursuing longer term solutions to completion. Without formal mechanisms and timetables to review pending issues and track the frequency and impact of various problems, this process can potentially create a vicious circle, resulting in much wasted time and effort. For instance, unresolved problems resurface after some time, and may also cause other problems that are, in turn, addressed through additional fixes and so on. Therefore, information systems can play an important role in improving coordination effectiveness by recording decisions, tracking progress on various projects. and providing data on previous problem instances.

2.3 Collaboration to Resolve Materials Shortage Problems Let us now examine a particular class of

problems which we refer to as “materials shortage”. Materials shortage is said to occur when a needed component is not available on time to commence assembly of a product as scheduled. Note that, in surface mount assembly, the production of a particular board can begin only if &l the components needed for that board are available. Consequently, the shortage of even a single part can disrupt production, delay shipments, and increase unit costs (due to unanticipated setups, overtime for assembly workers, and expediting costs).

Figure 3 shows the origins and consequences of materials shortage contingencies in electronics assembly. Although this set of problems is not exhaustive, the figure captures a large percentage of day-to-day production problems at ECAT and many other electronics assembly facilities.

As Figure 3 illustrates, materials shortage has many root causes, including delayed deliveries from vendors, poor quality of components, low assembly yield, inaccurate demand forecasts, changing customer requirements, engineering change orders, errors in the MRP and materials control system, and poor planning. The problem is especially acute at ECAT because it uses a vast number (over 7000) of components; each of the 120 board types that ECAT assembles requires 100 to 300 components, and the plant consumes approximately 4 to 5 million components per day. The direct costs plus opportunity costs for each PPL can exceed tens of thousands of dollars per hour; hence, ensuring an uninterrupted supply of the correct sets of components at the right time is critical.

Let us highlight some important features of materials shortage problems:

(i) Almost all the functions in the Dlant can potentially cause materials shortage: from vendors who supply poor quality parts late, materials planners who do not plan adequate safety stocks, engineering organizations that issue frequent design changes, production personnel who are unable to control the processes and ensure consistent yield. marketing people who cannot provide good forecasts, to customers who change their requirements at short notice.

(ii) Resolving materials shortage problems requires cooperation by many different functions: vendors might agree to expedite shipments, material planners might arrange for emergency shipments from other facilities, PPLs might reschedule their production, and the sales organization might negotiate with customers to delay their shipments.

(iii) Reactive problem-solving addresses the immediate need, i.e., to procure the needed component as quickly as possible, and/or postpone the product requirement as much as possible. On the other hand, the long- term solution must address the root cause. The players involved in developing and implementing the reactive solution might not necessarily be responsible for or participate in the long-term improvement process.

(iv) Although “materials shortage” is a common phenomenon, it is not a routine or repetitive problem since each occurrence of materials shortage might pertain to a


different component and have a different systems such as the CFM environment) and root cause. requires effective coordination between multiple

Thus, resolving materials shortage problems functions. quickly is critical (especially in tightly-coupled

38 A. Balakrishnan et al. / In;. J. Production Economics 38 (1995) 31-58

We wish to address the following questions. What is the nature of the collaborative process needed to resolve materials shortage problems? What are the necessary information and material flows? What is the nature of technology required to support the collaborative requirements?

Let us examine the mechanisms and processes at ECAT to address materials shortage problems. The materials organization classifies components into two categories: key and non-key parts. By definition, a non-key part has minimal dollar value: the plant does not maintain rigorous inventory records for these parts, and often the

(E3

I Go to Line

Clerk

plant negotiates a “Contract Line Delivery” (CLD) with the supplier, i.e., the supplier is responsible for maintaining a specific inventory level. Materials management devotes considerably more attention to monitoring inventory levels-at the stock room and tbe PPLs- for the key parts. Figure 4 shows the rough sequence of information flows and events for shortage of a key part. Although this figure represents the interactions as a sequential process, resolving materials shortage problems is very much a concurrent and collaborative effort with simultaneous exploration of many different alternatives.

Generates 5 day Critical component list from

run Critical List sent to Materials

?ollaborative Uecison Making e.g. Production Status Meeting

Figure 4: Materials Shortage Workflow Diagram

A. Balakrishnan et al. / hr. J. Production Economics 38 (199.5) 31-58 39

Because materials shortage is disruptive and occurs relatively frequently, ECAT has specially designated an individual as the critical parts coordinator (CPC). Every morning, the CPC uses a computer system (called the Logistics System) to identify components with remaining inventory less than or equal to 5 days (at predicted usage rates), and distributes the critical parts report (via electronic mail) to about 25 production control (PC) analysts. Each PC analyst deals with a particular subset of components, working directly with the supplying divisions or the corporate procurement center (for parts supplied by outside vendors). The PC analyst is responsible for ensuring that the supply pipeline has sufficient orders for his/her parts to cover production needs, while monitoring and controlling inventory costs. When they receive the critical parts list, the PC analysts check the status of orders, and inform the CPC regarding anticipated problems with the supply stream (and the reasons for these problems). Typically, they confer with suppliers to ensure that orders that are due in the immediate future will arrive as scheduled, expedite orders if necessary, or simply reconfirm that the inventory quantities recorded in the plant’s materials logistics systems are correct. For the most critical components, the CPC often calls the respective PC analysts to ensure that they have adequate information by 9:OO a.m. to report on the status and acquaint managers with potential problems during the production status meeting. At the meeting, manufacturing managers might challenge the inventory quantities specified in the inventory report, particularly the quantity of materials on the manufacturing floor itself. In these cases, the CPC requests (after the meeting) a production control person to take a physical count of the inventory, or search for the missing quantities.

When the follow-up actions for a critical part suggest an imminent shortage, Floor Control initiates and coordinates actions on many fronts to react to this contingency. The Floor Control organization has a team of 5 members assigned to each PPL. When a materials contingency arises, the team that is responsible for the affected PPL is immediately notified, as is the senior materials planner responsible for that component. The materials planner will work with the PC analysts handling the scarce components to find extraordinary ways to alleviate the supply problem. For instance, one option might be to look for other sources, e.g. at sister piants. other suppliers and distributors. Another would be to

use substitute components that are acceptable to board designers and engineers. MeanwhiIe, a Floor Control team member prepares contingency schedules for the affected PPL in case the materials organization is unable to procure the component or a suitable substitute on time. Rescheduling the PPL involves assessing the customer impact of delaying production and delivery of the affected product, and deciding which other product must be assembled in its place (given the current setup of the PPL, the due dates of different orders, etc.). FIoor Control needs to keep close tabs on the progress of the materials organization’s efforts to determine if changing the production schedule is inevitable. Conversely, Floor Control might discover that the schedule disruption has no effect on the customer, e.g. if the customer has adequate on-hand inventory of this product, in which case the materials organization must be informed so that they can refocus their efforts and avoid disproportionate expense to expedite the component.

If the cost to procure an emergency shipment of a critical component exceeds a certain threshold, senior management needs to be involved to decide if the additional expense is worthwhile. If materials shortage cannot be avoided, the planning/floor control group must contact the customer to re-schedule the order, and also work with the PPL to implement a change in the production schedules. Materials shortage problems are further complicated because several parts might simultaneously become critical, and certain parts are common to multiple products. Suppose the plant has insufficient supply of two or more components needed for the same product, and suppose these components are assigned to different PC analysts (for instance, if they are supplied by different vendors). What if one of these components is available (say, from a distributor) at a higher price? In theory, procuring this component at higher cost is worthwhile only if the other component can also be expedited; otherwise, the board assembly must be postponed anyway. However, without coordination among PC analysts, the plant might incur unnecessary costs to expedite one component without actually increasing throughput or delivering the product on time. Another complication arises when a critical component is common to several different products, possibly assembled on different PPLs, that are concurrently scheduled, and current supply is inadequate to meet the immediate needs of all the PPLs. In this case, Floor Control must

40 A. Balakrishnan et al. / ht. J. Production Economics 38 (1995) 31-58

also decide how to allocate the available inventory among PPLs, and which PPL(s) must be rescheduled_ This process involves extensive consultation, interactions and negotiations with several PPL managers, customers, and other stakeholders.

If the inventory records are inaccurate, then materials shortage might not manifest itself in the S-day critical parts list but much later, when the assembly worker gets ready to setup the PPL for a new product. but discovers that one or more components needed for the product are not available for loading on the placement machines. In this case. the worker contacts the PPL line clerk to obtain the necessary part. If the part is not available in PPL inventory. the clerk queries the logistics system to find out whether the plant’s stock room has this part. If found, the clerk places au order through the logistics system, and Distribution delivers the part to the production line. Otherwise, the clerk escalates the problem to a higher level by informing the materials expediter or planner about the part shortage. The materials expediter is a senior manager whose sole responsibility is to solve these crises in conjunction with other groups. The materials expediter faces three possible courses of action: (i) inform the appropriate PC analyst to expedite delivery of that part, (ii) transfer parts from other PPL lines that might have this component in their inventory, or get the part from sister plants, and/or (iii) postpone the assembly of this particular board to a later date, and inform the management, customer and PPL scheduler. Deciding which action to pursue requires coordination with different teams, functions and organizations. The decision process is collaborative; the materials expediter serves primarily as a mediator and facilitator in this process.

To summarize, this section has described a common reactive problem, materials shortage, in the electronics assembly context. We have examined the causes. mechanisms, solutions, and coordination needs to resolve this class of problems in au actual production setting. Multi- product, multi-line facilities such as ECAT face additional reactive problems due to shortage of other resources (e.g., labor or machines) and changes in demand. For instance. when a PPL goesdown due to, say, breakdown of a placement machine, management must decide how to reallocate production to the remaining PPLs, and also simultaueously take actions to repair the machine. This contingency requires interactions

between different PPL managers, process engineers and maintenance crews, sales, customers, distribution, and scheduling. Similar multi-function collaboration is needed when customers change their orders, or engineering releases a design change. In general, the planning and reactive problem-solving process must be geared towards dynamically matching supply and demand to achieve the following objectives (Bang, Decker, Gisler and Haugen [1990]): (i) scheduling final production to current customer demands so that final product is delivered JIT to the customer, (ii) managing customer orders to be consistent with the supply schedule, (iii) implementing inventory buffers in the supply pipeline to respond to global sourcing and changing customer and market requirements, and (iv) using scheduled delivery pulls and forecasts to communicate delivery and start requirements to suppliers based on customer order requirements. In turn, the scheduling function must account for constraints imposed by machine capacity, operation sequence, lot size, waiting time, and workforce availability.

3. FRAMEWORK FOR REACTIVE PROBLEM-SOLVING

As the materials shortage example shows, reactive problem-solving entails complex multifunctional interactions. The nature and type of interactions depends on the problem, and varies with time for a given problem. Our objective is to explore how to harness the potential of the new and emerging information technologies, including network publishing, client/server computing, distributed databases, and distributed hypermedia on TCP/IP networks to solve reactive problems. Based on our observations in the case study, we have developed a conceptual framework consisting of four layers to support the requirements of reactive problem-solving in a computing environment. This section outlines the framework, and provides a brief description of each layer.

To motivate our approach, we begin by discussing certain principles and requirements for computer-based coordination support systems.

1. Effective problem-solving requires a structured “organizational process” that systematically proceeds through different phases from problem detection and diagnosis through corrective action and learning. The phases differ in terms of the

A. Balakrishnan et al. / Int. J. Production Economics 38 (1995) 3158 41

people involved, the nature of their interactions, and the type of information required_

2. To provide computer-based support for the organizational problem-solving process, we require a corresponding “computational process layer”, a computing environment that facilitates and directs electronic interactions between different agents during the various phases of reactive problem-solving. This layer also aids in structuring and linking the vast amount of information being generated in the reactive problem-solving process.

3. The computational process layer needs to access and store relevant information, both qualitative and quantitative, for problem analysis, decision-making, and organizational learning. This “data/information layer” must have the capability to provide an integrated and transparent way to access product and process information, and facilitate the movement of the necessary manufacturing- related information.

4. Since the agents involved in problem- solving interactions might not necessarily be co-located. the information system must be implemented on a distributed network architecture with appropriate software support in terms of access protocols, etc.

These observations suggest that in designing a computer-based support system for reactive problem-solving, we must first understand and specify the organizational process, and select suitable software and hardware to facilitate this process. In turn. the software consists of a computational process overlayed on an information model. The information model must be consistent with and be supported by a distributed network (software) architecture. Figure 5 shows a layered framework that reflects these four subsystems.

I Organizational F%ocess Layer I

I Computational (Hypermedia) Process Layer I

I Problem-Solving Data/ Information Model I

Computing Network Architecture and Protocols

Figure 5: Hierarchica Framework

We next briefly describe the purpose of each layer and their interdependencies. Subsequent sections address the top three layers in more detail; this paper does not explore in depth the issues relating to the network architecture layer except for some comments in the concluding section.

The organizational process model describes the various phases of the managerial interactions and communicationdither face-to-face, over the phone, electronically, or via mail-necessary to identify and solve reactive problems. Problem- solving involves the collection of pertinent information about the problem, the interpretation of that information to determine specific problem types and causes, and development of action plans (Nadler and Tushman U9801). From the case study and relevant literature in problem- solving (primarily Dewey [ 19101. Newell and Simon 119721, Mintzberg et al. 119761). we have identified four key phases in the reactive problem-solving process -- problem identification, diagnosis, solution formulation, and solution implementation. Each phase has distinct information, collaboration and coordination needs. The problem-solving effort not only produces an action plan but also generates organizational learning. In Section 4, we elaborate on these different phases, with particular emphasis on the IT support needed for each phase.

We separate the necessary software to support the organizational problem-solving process into two layers-a computational process layer overlaid on the data/information model. The computational process model specifies how the organizational process is reflected in the computing environment. It serves as the interface between users and data, encoding the social rules that regulate the interaction between various agents in each phase of the problem-solving process, facilitating commuication and collaboration among these agents, and providing the necessary information-sharing and analysis tools during each phase of the problem-solving process, and encodi. In this context, the notion of hypermedia is extremely useful as a framework for organizing, structuring and navigating networks of interlinked textual, numeric and multimedia information relevant for problem- solving (Gronbaek and Trigg [1994]). The basic elements of hypermedia are nodes (elements of text or graphics) and links between the nodes (connections indicating a relationship).

42 A_ Balakrishnan et al. / lnnt. J. Production Economics 38 (1995) 31-58

Hypermedia is a natural medium for supporting collaborative work, particularly the idea generation, idea evaluation. and information management tasks in reactive problem-solving. These tasks require sharing documents, creating annotations, providing multiple views of a common set of materials, and cross-referencing information. Hypermedia systems are also well- suited for distributed processing and storage environments. Section 5 discusses the elements of a hypermedia process layer in the context of reactive problem-solving, extending it to include multimedia documents.

The datafinformation model describes the common underlying representation of parameter, status, transactional, and qualitative information. It provides an integrated and transparent way to access, process, and exchange document-based information across a spectrum of machines, applications, and agents. The network architecture iayer defines the hardware and protocols that support the distributed information model. In practice, managers exchange information primarily through documents (including multimedia documents such as interactive technical manuals and CAD/CAM images), and so the data/information model should be document-based, incorporating not only text and numeric data but also structured text, images, graphics and even audio. The information model must provide support for both product and process information. Product information deals with the characterization and description of parts and sub-assemblies for use in the design, procurement, and production processes, including changes and accumulated knowledge during the product’s entire life cycle. Process information refers to the composite body of documents that is assembled and transformed during the problem-solving process (e.g., problem reports, requisition forms and routing slips). In Section 6. we illustrate with several examples the structure of a document-based data model. We introduce the concept of encoding manufacturing documents, eliminating paper-intensive processes and enabling the “fluid” delivery and access of electronic data

4 ORGANIZATIONAL PROCESS LAYER

The organizational theory literature suggests several frameworks for problem-solving (e.g., Dewey’s [19103 framework of reflective thought, Simon’s [1%5] trichotomy of intelligence-design-

choice, and Mintzberg et al. [19761’s seven step method for strategic decision-making). The TQM literature emphasizes principled problem-solving and improvement methodologies such as the “Plan-Do-Check-Act” (PDCA) cycle and the Seven Step method (Juran and Gryna [1988]). This latter method consists of two phases: the Diagnostic phase, including theme selection, data collection & analysis, and causal analysis, and the Remedial phase consisting of solution planning and implementation, evaluation of effects, standardization, and reflection on process. Much of the literature on problem-solving and decision making focuses on describing normative processes applicable to generic problem-solving (Nutt, 1984) rather than on addressing issues of how organizational subunits collaboratively solve unstructured reactive problems in day-to-day operations, and which data/information model or computing technology can best support this collaboration.

Figure 6 presents our view of the typical reactive problem-solving process. The process begins by observing symptoms and recognizing that a problem exists and must be addressed. The specific problem must be identified, defined. and diagnosed using aids such as fiihhone diagrams. Problem diagnosis for reactive problem-solving might differ in its nature and depth from root cause analysis for long-term improvement. The third phase consists of developing a strategy to resolve the immediate problem, and formulating the necessary action plans. This phase often requires iteration and coordination between different functions to address tradeoffs, promote goal congruence, and ensure complementary rather than contradictory actions. Coordination refers to the means of integrating or linking together different organizational subunits whose decisions and actions are interdependent, (i.e., the actions of one subunit not only defines the available options of other subunits, but also impacts their performance) in order to achieve the organizational goals (McCann and Galbraith [198 11, Van de Ven, Delbecq and Koenig [1976]). Information systems can support this integration by providing facilities for information sharing, communication, collaboration, and synchronization of decisions and actions. Finally, the implementation phase consists of executing the reactive action plan, and reporting the results. The reactive problem-solving process also generates input to root cause anaiysis and long- term improvement, and provides the opportunity to learn and improve upon the problem-solving process itself.

A. Balakrishnan et al. 1 ht. J. Production Economics 38 (1995) 31-58 43

Problem Problem Formulating Implementing Identification + Diagnosis -Reactive Solutions d %aXiVe SOhtion -

Manufacturing Process

Improvement

Organizational Learning

Figure 6 : A Framework for Reactive Problem-Solving in Manufacturing

In this section, we elaborate on each phase of reactive problem-solving Figure 6, considering both organizational issues and the challenges of developing computer-based support.

transferable to another situation; and (iv) algorithmic solutions are not possible. Reactive problems span both categories.

4.1 Problem Identification Phase Rittel [1980] proposed a general

CIassification of problems into two broad categories: “tame” and “wicked”. Tame problems: (i) have well constrained goals: (ii) can be formulated with precision; (iii) are recurring and not unique; and (iv) have algorithmic solutions. On the other hand, wicked problems: (i) have complex and vague goals; {ii) can only be stated in an approximate way, and the definition of the problem changes with time, resources and context; (iii) are unique and the solution is not

Reactive problems surface when workers or managers detect a threat or observe a variance in their performance metrics (i.e., deviation in a performance metric is the typical symptom). To anticipate and identify problems quickly, organizations must choose the right metrics and leading indicators that can predict problems, develop the ability to recognize the core problem from a multiplicity of symptoms, and communicate problems quickly to the appropriate level once they are detected.

I Higher-Levels of Management I

Production Status *Meeting

A

Receiving & Shipping

0 Oval-Boxes indicate

- groups present in the Production Status Meeting

Figure 7: Problem-Escalation Hierarchy

44 A. Balaicrishnan et al. / Inc. J. Production Economics 38 (1995) 31-58

Figure 7 shows the different organizational levels involved in dealing with materials shortage problems. At ECAT, the 5-day critical list, monitored by the material control group, is supposed to serve as the alarm for potential materials shortage. However, due to deficiencies in the material control system, the impending shortage of certain might go unnoticed, in which case the problem is detected only at lower levels in the hierarchy when the PPL worker starts setting up the machines. If the problem cannot he resolved through communication with other groups at the same level (inventory clerks), it is escalated to a higher level in the organization. In this case, the problem must be communicated swiftly to the materials manager, PPL manager, and floor control supervisor so that they can initiate the reactive problem-solving process. Each escalated problem is assigned a priority level, and an associated problem resolution time, based upon the impact of the shortage on the PPL’s performance. If the problem cannot be resolved within the time limit, the manager is alerted and the problem is further escalated to the the production status meeting where a cross- functional group representing production, inventory, materials, quality, engineering, shipping and supplier representatives attempt to resolve the problem.

4.2 Problem Diagnosis Phase Problem diagnosis entails understanding,

through appropriate data gathering and cause- effect analysis, the factors that precipitated the problem. The lack of inadequate information systems support, combined with the intense time and performance measures, contributes to inadequate attention to this important phase of the problem-solving process. As Adams [ 19861 notes:

“. . the natural response to a problem seems to be to try and get rid of it by finding an answer -- often taking the first answer that occurs and pursuing it because of one’s reluctance to spend the time and mental effort needed to conjure up a richer storehouse of alternatives from which to choose. This hit-and-run approach to problem solving begets all sorts of oddities -- and often a chain of solution-causing-problem- requiring-solution. ad infinitum.”

In the reactive setting, problem diagnosis must often be performed using incomplete and even inaccurate information. The computing system can improve diagnostic effectiveness by integrating the large number of manufacturing

documents for cross-referencing and conditional branching. For example, to identify the source of an equipment malfucntion, a technician generally performs a number of tests, on the basis of which a diagnosis is made and a repair procedure is prescribed. The information base must outline each step of the testing procedure, based on the original symptoms and the outcomes of the previous tests, and then specify the repair actions necessary u) fix the problem.

We can distinguish problem diagnosis activities along two dimensions: spatial and temporal. In the spatial dimension, problem diagnosis could be either local or global. Local diagnosis, usually intra-functional, involves only a few participants. For example, a process engineer might resolve an equipment problem with the help of a specialized technician, or the PPL inventory line clerk might resolve a material shortage problem without escalating it. Global diagnosis, on the other hand, spans departmental boundaries, and is often necessary for high priority problems that require exploration on multiple fronts.

In the temporal dimension, we can distinguish between short-term and long-term diagnoses. Short-term diagnosis focuses on feasible “myopic” options to address the immediate contingency. Long-term diagnosis, on the other hand, is a detailed, systematic effort to identify the root causes of the problem, and correct or eliminate these root causes through design, process or operations improvement. As Figure 3 illustrates, problems such as materials shortage can have many different root causes. For instance, a “bridge” defect on a printed circuit board (when a solder bump spans two adjacent solder pads) might be caused by poor board design or improper soldering. Deciding which of many contributing factors to address requires dialog among various functional managers, and an established procedure to resolve conflicts. In general, organizations must use data from their reactive problem-solving experiences to prioritize and guide their long-term diagnosis and problem- solving activities.

4.3 Reactive Solution Formulation And Evaluation Phase Evaluating potential solutions to the problem

and developing an action plan requires generating many different alternatives, assessing the effectiveness of each alternative, and exploring the actions needed to accomplish the immediate objectives. The process of deciding the best

A. Balakrishnan et al. / Int. J. Production Economics 38 (1995) 31-S8 45

course of action must balance the need to “optimize” the solution, while meeting stringent deadlines and resource constraints. The solution phase uses two basic techniques: search and design. Search is evoked to find past solutions to the problem, whereas, design refers to developing solutions to a novel situation or modifying past solutions to fit current needs. Deciding which solution to adopt might requires input from different functions. For instance, to reschedule a board (i.e., delay its assembly) due to materials shortage, we need information about backorders and customers’ willingness to wait (from sales), anticipated delivery dates from suppliers (from materials management), flexibility of production schedules (from floor control), etc. Similarly, to expedite a shipment from a vendor. we need information on how much the vendor can ship, arrival, and cost.

In this phase, the design of coordination arrangements to integrate “boundary spanning” workflows (compared to, say, intrafunctional coordination) is especially important and challenging. This design is made difficult as the different subunits involved in reactive problem- solving have differing perceptions of interdependence, and disagree over strategies because: (1) asymmetries exist in their status and access to information, (2) different subunits have varying performance and reward criteria, (3) some subunits are pursuing long-term goals and proceed systematically (e.g., by identifying and addressing root causes) whereas others have a short-term orientation, (4) task ambiguities stimulate unilateral actions to reduce ambiguities through informal sources, and (5) difference in training and knowledge bases create semantic barriers and perceptual diversity (McCann and Galbraith [1981]). To overcome these difficulties, a large amount of ad hoc or informal coordination actually takes place in resolving short-term production problems. Ad hoc mechanisms include face-to-face communication, group discussions, bargaining and negotiation, and incentive mechanisms.

How to design information technology to support ad hoc coordination structures in a reactive problem-solving context? Researchers have proposed several broad classification schemes for coordination mechanisms (March and Simon [19581; Thompson [19671; Argote [1982]). One such scheme distinguishes between three types of mechanisms: programmed coordination, non-programmed coordination, and coordination by feedback . In programmed

coordination, the activities are dictated by organizational goals and objectives, and plans are specified in advance by the organization. This mode of coordination is characterized by mechanisms such as pre-established plans, schedules, forecasts, formalized rules. policies and procedures, and standardized information and communication systems. Once the prespecified blueprint of action is implemented, its use requires minimal communication between subunits responsible for performing the individual tasks. In non-programmed coordination, on the other hand, activities are not specified in advance, but usually occur as a result of some emergency. Finally, coordination by feedback combines features of both programmed and non- programmed modes; it is ‘defined as the mutual adjustments made to an original plan based upon new information. Materials shortage problems might often require these latter two types of coordination. Clearly, the type of computer support best suited for reactive problem-solving depends on whether the interactions and responses to different contingencies are relatively well-structured and share common patterns. We can encapsulate well-structured coordination mechanisms in software to ensure quick and efficient handling. But, if the interactions and sequence of actions are complex, sequence and state-dependent, and vary widely from one scenario to the next, then collaborative support via hypermedia process models might be most appropriate.

4.4 Reactive Solution Execution Phase As the supply chain becomes more closely

integrated, reactive solutions require monitoring the actions by various agents along this chain. So coordination plays an important role in the effective implementation of solutions. The implementation phase consists of the following activities : (i) notifying agents about actions that need completion; (2) providing agents with specific information and tools to complete actions; (3) reminding agents with alerts, triggers and follow-ups to synchronize workflow; (4) providing instantaneous access and visibility of the status of the workflow; and. (5) provide feedback on the success and failure of various actions in the schedule to enable organizational learning.

Integration of the different manufacturing subsystems, containing product, process, inventory. scheduling, purchasing, and yield information. would enable managers and planners to track and the transactions spawned by action


plans. The ability to create applications triggers that are activated on certain conditions or actions permits distributed automation of task events. Automatic forwarding of transactions from one queue to another facilitates more flexible scheduling and control. Although workflow computing is in its adolescence, it is evolving quite rapidly with the agent-task model, making automated coordination practical. Once the reactive plan is implemented, the effects of the actions must be assessed for correctness. If the solution has a satisfactory outcome, then it must be standardized and stored for future reference when similar problems recur.

4.5 Experiential Learning From Problem-Solving Experience from problem-solving is central

to the creation of knowledge and organizational learning. According to March [1991], organizations accumulate knowledge over time from their members, storing it in their norms, procedures, rules and forms. Accelerating this learning process to cope with the increasing rate of change in technology, markets, and the operating environment, is important. Senge [19903 identified two types of learning: generative leaming based upon creativity and innovation, and adaptive learning LO cope with changes in business environments. Argyris and Schon [1978] differentiate between single-loop leaming where organizations adjust their behavior relative to fixed goals, norms, and assumptions, and deutero or double-loop learning where the goals, norms and assumptions, as well as organizational behavior, are themselves open to change.

Generative and deutero learning apply to detailed root-cause analysis and long-term improvement activities, while adaptive and single-loop learning are necessary for reactive problem-solving. As we noted earlier, the frequency, severity. and persistence of day-to-day operational problems must serve as inputs to prioritize long-term improvement projects, and the experience with reactive solutions provides data for root cause analysis and long-term solution planning. IL is useful LO distinguish between learning and memory. Learning is a process which affects the cognition and preferences of managers, and in turn influences future actions. Managers learn by understanding and reflecting on current processes and improvement projects. Understanding involves both inferring new knowledge, and discarding obsolete and misleading knowledge.

Organizational memory, on the other hand, is the capability to organize, store and manage information that is generated in an organization. Computing has traditionally supported organizational memory through the use of databases, but has not adequately addressed the problem of organizational learning.

5. HYPERMEDIA PROCESS LAYER

This section discusses how the hypermedia process layer (HPL) can provide an appropriate computing formalism to support the collaborative needs that we identified in Section 4 for different phases of the organizational problem-solving process model. We use the HPL in two ways: as a modeling tool for organizing collaborative tasks and activities, and as an structural tool for linking the decisions and information flows in the problem-solving process. As a modeling tool, we use hypertext’s ability to fashion knowledge from information. Hypermedia nodes deconstruct the linear sequence inherent in printed materials, making possible flexible combinations. Links indicate the relationship among nodes (through types and attributes), creating a conceptual graph, similar to a semantic network. In Section 5.1, we examine this aspect of HPL for modcling the structured discourse and argumentation processes in the problem diagnostic and solution formulation phases The goal here is to examine hypermedia support for the “behavioral” or “process-oriented” perspective (Leggett and Schnase [1994]), to orchestrate the interaction between individuals during the process of diagnosis and solution formulation_ Currently, much of this interaction takes place primarily through the telephone or a face-to-face meetings. Our goal is LO develop a flexible computer-based environment, based on IBIS (Kunz and Rittel [1970]) and Toulmin’s (1958) argumentation schema, to augment the traditional forms of interaction and better support the notion of “collaboration as a conversation” (Winograd [1987]).

As a structural tool, HPL provides the basis for linking underlying data models, and providing navigational structures suitable for supporting problem management and coordination. Structural hypermedia (or hypertext) refers LO the ability to group or link in a non-linear fashion several nodes (or information elements). These nodes can represent diverse elements in the reactive problem-solving process, ranging from coarse grain elements such as tasks or activities in

A. Balakrishnan CC al. / ht. J. Production Economics 38 (1995) 31-58 47

a particular phase to fine grain elements such as specific documents containing different “media” (text, graphics, sound, video). In Section 5.1. we examine how argumentation and problem management can use hypermedia’s facilities for authoring. linking, browsing and retrieving interconnected documents or data structures, regardless of form or location, to effectively track problems and actions across functional boundaries. Problem management, including problem tracking, feedback analysis, and historical reporting. can exploit the hypertext node/link structure to create a thread linking all the information relevant to a particular problem, from identification to resolution.

5.1 Collaborative Process To illustrate the HPL concepts, let us focus

on the collaborative diagnosis and solution formulation phases during reactive problem- solving. The collaborative process is a dialog (even though only one person might be involved) in which possibilities (or issues) are set forth, expanded, challenged, and supported (see Figure Xb). Participants in this process model and explore various diagnostic and solution scenarios, each characterized by the time, expense, and political risk involved. The practice of surfacing and testing the implicit mental models of various managers helps build consensus. Why is consensus important? Agreement on the structure of the mental model of the problem quickly leads management to identify the assumptions (or root causes) that drive the problem, validate these assumptions, and swiftly pinpoint elements of the plan with the highest impact and/or greatest uncertainty. By obtaining consensus on these planning “leverage points”, the dialog can focus on strategic issues, and management can quickly and confidently select and agree on a direction that meets the organizational goals, assign resources, and set performance targets. Agreement on a mental model of the root causes permits management teams to become both more rigorous in reviewing their strategy, and more creative in developing their strategic options.

How to achieve consensus? On-line communication tools serve as the medium for propagating information about specific problems and their resolution. The complexity in managing and organizing the electronic communication space grows exponentially when many probIems (often in the hundreds) are being solved simultaneously in the manufacturing environment. One of the challenges from a computing standpoint is to bring “order to chaos”

by coordinating the flow of information and interaction in the on-line communication process during reactive problem-solving. We propose decomposing the communication space into more manageable sub-spaces, one corresponding to each phase of the organizational problem-solving process. Figure 8a shows the hierarchy within the “on-line problem activity space”, the overall structure of the reactive problem-solving communication space, for one problem. We refer to the sub-spaces as problem (or content) space, diagnosis (or argumentation) space, solution (or planning) space and action (or coordination) SpZiCC

Space 5.1.1 Using IBIS to Structure Problem

Our view of collaborative problem-solving shares some features with the Issue Based Information Systems (IBIS) approach (Kunz and Rittel [1970]) and the Toulmin’s schema of Argumentation (Toulmin [ 19581). Specifically, our approach combines the IBIS discourse model as a macro structure with a micro argumentation structure according to Toulmin [1958]. Combining a macro structure with a micro structure has been proposed by Kopperschmidt [1985]. but has not been implemented in an organizational context. Examples of computer- based systems which support IBIS macro structures are graphical IBIS (gIBIS, Conklin and Begemann [1988]) and Procedural Hierarchical IBIS (PHIBIS, McCall et al. [1990]). These systems were developed to capture the design rationale for collaborative software projects and environmental designers. Participants in the on- line discussion argue about design issues by taking positions and making arguments for and against those positions. Correspondingly, these systems employ three basic node types: issues, positions, and arguments. One of criticisms of IBIS and its derivatives, is the abstract nature of the node types. Most early systems were designed to support argumentative writing, and did not address the question of embedding hypertext structure in an organizational process. We next describe a structure of nodes, based on the Toulmin schema, that constitute the reactive problem-solving hypertext structure.

The problem space is concerned with setting up an agenda, indicating the urgency of the situation, specifying the time frame for finding a solution and defining the main issue that must be addressed. The specification of the main issue (“Facing shortage of sub-assembly X”) could in


turn create a hierarchy of sub-issues (“Is it due to shortage of a component Z”); (“Is it due to lack of component quality?“); (“Is it due lack of sufficient inventory?“). These sub-issues then serve as topics, or root nodes, for individual argumentation networks in the diagnostic phase.

The agenda of important issues is not only a planning device for idea generation, but also a structuring mechanism to control downstream activities_ The planning phase contains the other three phases, thus guiding the other three phases.

Figure ga: Communication Space in Hierarchical Reactive Problem Structure

After identifying the goals of the intended activity, the problem-solving process enters the diagnostic phase during which managers can incorporate various scenarios (alternative hypotheses about the causes), test the hypotheses, and develop a consensus on their mental models of the causes of the reactive problem. In this space, the team (e.g., Floor Control, Engineering, Materials, Quality and Management) can acquire information about the issues identified in each scenario in two ways. First, the group might generate hypothesis about the problem and relate them to each other (e.g. as a part-whole relationship). Then, the discussion is structured as an argumentation network in order to obtain a representation of the ideas and mutual relationships. Second, the group can access additional information including relevant documents produced in previous problem situations, or databases and documents from external sources, referenced whole or in part. In turn these references might create a new chain of arguments and rebuttals. The communication and information retrieved during the diagnosis phase might range from brief comments on an idea to complete multimedia documents (such as audio or video of some prior meeting) which can be viewed and used as inclusion in the intended

Figure Sb: Structure of Dialogue

argument network. We elaborate on this feature in Section 6.

Once each of the scenarios has been developed for the disaggregated elements of the problem. the group can reach a consensus on plausible assumptions for solution planning. The planning phase builds upon the diagnostics activities (e.g. argumentation) to isolate and agree upon potential causes for the problem and formulate action plans. This phase might include building models to validate the planned solution, or testing the plan’s robustness to various environmental uncertainties. Each identified cause in the diagnostic phase might generate alternative solutions, and each proposed solution can generate different actions (or set of actions) in the action phase.

5.1.2 Computer-based Argumentative Schema Our approach combines the problem-solving

phases (or the macro hypertext structure) as the main organization principle with the microstructure represented by argumentation. The macro structure is based on an enhancement of the IBIS framework, while the Toulmin schema provides an anailysis at the micro level. At the macro level, our approach differentiates between the different node types of the problem-


solving process, namely, problem issues, problem causes, and arguments about the causes. After a cause has been identified and agreed upon, another node hierarchy, consisting of problem cause, solutions to alleviate problem causes, and arguments about the various solutions, is utilized to identify solutions. Once a solution is accepted by all the participants, the group develops an appropriate plan of action.

The argument schema is subsumed in the diagnosis, solution and action phases as participants debate various alternatives. To represent arguments, we adopt and extend the schema proposed by Toulmin (1958). one of several argumentation models with specialized language and constructs. Figure 9 shows the different elements of a complete argument in the Toulmin schema. The ‘datum” element links the argumentation schema with the extended IBIS schema that was discussed in the urevious

section. The “datum” reflects the posture, possibly debatable, that an individual adopts in an argument. In the schema “datum” and “claim” are required elements; “warrant”, “backing” and “rebuttal” are optional. The relation “so” links a datum and claim; for instance, “We have a severe shortage of 25 ohm resistors, capacitors and 80486 Microprocessors on Production Line 5” -SO-> “it is not possible to meet our production targets”. Since we are dealing with common sense arguments instead of formal logic reasoning, an argument is more readily accepted if one can provide a “warrant” which legitimates the “so” relation via the “since” relationship. The warrant provides a general rule which justifies the “so” conclusion. In a further step, the “warrant” can be backed by a “backing” giving supporting evidence for the validity of this rule. In order to handle exceptions from the rule one can use the element “rebuttal” which questions the claim.

-E&S

I

I

BACKING Oualitv Control I

Figure 9: Example of Toulmin Argumentation Scheme

The Toulmin schema deals with common sense reasoning and hence suffers from a lack of detaiI that makes it difficult to implement in a computer environment. For instance, the schema does not guide the system developer regarding design decisions about the implicit structure of nodes such as DATUM. CLAIM or REBUTTAL. It provides no justification for the choice of the labels SO, UNLESS etc. for the links between these nodes. Assuming that all the interaction takes place via electronic mail, we have developed templates that can be used for implementing the “enhanced” Toulmin schema in

a computing environment. Figure 10 contains an example of one such template for a REBUTI’AL, written in SGML (Appendix A provides a brief introduction to SGML and its role in describing the logical structure of documents). The advantages of this representation are the specification of the data fields, the data types allowed in the data field within the context of an electronic message, and the ability to parse the instance using the parser to validate the fact that it conforms to the actual definition. Similar templates can be easily developed for other nodes in the Toulmin schema.

50 A. BAlAkriShnUn et al. / ht. J. Production Economics 38 (1995) 31-58

<!DCXXYPERRBU’lTALl <! ELEMENT REBUTTAL - - ((Date & Sender & Receiver & Subject_Summary ). Body_of_Rebuttal) > c!Al-TlXT RBBUlTAL refld ID #REQUIRED>

<!ELEMENT (Data I Sender I Receiver I Subject_Subject_Summary) - 0 (WCDATA) > <!ELEMENT Body-of-Rebuttal - 0 @aragraph)* <! ELEMENT paragraph -0 (#PCDATA I LINK I Figure): c!-- Hypertext relationships between documents --> c! ELEMENT Figure -0 (graphic, caption) > <IELEMENT (graphiclcaption) - 0 (WCDATA) > <!ELEMENT list 00 (name+) > <!ELEMENT (name) -0 (#PCDATA) > <!ELEMENI’ LINK -0 EMPTY> <!ATTLIST LINK

idref IDREP #IMPLIED -- starting point -- href RURL; #IMPLIED -- destination node -- rel CDATA #IMPLJED -- forward relationship type -- rev CDATA #IMPLIED -- reverse relationship type -->

I> K.:-..-- In. cK.mm1 T,.--l,.4- r-- . Dr?D,,T’F* W

A novelty of our approach is the use of hypertext links (LINK) within the template to reference other documents in our DATA/INFORMATION model discussed in Section 6. Hypertext links to reference external documents can be used to increase the suength of the rebuttal by providing supporting evidence. A REBUTTAL instance can have multiple LINK elements placed strategically interspersed with the text to deliver the greatest impact. This feature provides a means to describe the relationship between this and other documents. The destination of the LINK can be located anywhere in the organizational network to link to any type of manufacturing information (see Table 1 below for a list of some manufacturing documents). Each document can be of any media type (text, image (e.g. JPEG files), audio (e.g. AVI files), video (e.g. MPEG files)).

This type of representation is both powerful and elegant to implement. The person who is reading the REBUTTAL can activate the link (by clicking on it) and the browser would then follow the address (URL) to the destination node, retrieve the document and present the information. This type of access from the collaborative or argumentation process to widely dispersed, multi-media manufacturing information is of vital importance to increase the speed and quality of decision-making in reactive problem-solving, especially information proliferates and the available response time Shrinks.

Table 1: Representative List of Documents Referenced during Reactive Problem-Solving Balance-of-stores (Stock) Record: An inventory card indicating the order quantity, quantity on hand, quantity allocated for future production. and balance available for future use. Bill of Materials (Routine Sheet): Called the Operation Master; used for production scheduling, cost accounting, and for purchasing departments. This document also lists the standard time estimate. Bin Tag: Materials delivered to a stockroom are tagged with the appropriate part number, description, location and quantity. Master Schedule: Using the forecast information or customer’s orders, lists the production requirements of a given product for a division or department of the company. Parts catalog : A document containing the specification, design -- geometry, tolerances etc. __ of components. This is primarily used by the engineers in design and materials managers in purchasing. Parts Lisl: Is a listing of all parts and sub- assemblies need to produce a given item. Production Schedule: Sometimes referred to as salendar schedule used to authorize production runs. Production Suecification Sheet: Lists the components of the item being produced along with a description

A. Balakrishnan et al. / Int. J. Production Economics 38 (1995) 3X-58 51

of each component, the operation to be performed and other engineering information needed by ~anttfacturing..

urc ase Recutsition: Authorizes the purchasing department to order a particular raw material, part or supply_ PurchasinP Follow-up: a reminder form necessary to maintain a follow-up procedure to ensure deliveries being made as promised. ReceivinP Slip: Used by the receiving dock personnel to check incoming materials and supplies. The quantity of goods received is compared with the quantity ordered.

6. DATA/INFORMATION LAYER

The Data/information model provides a common database and consistent representation of the various types of quantitative and qualitative information in manufacturing including (i) production parameters (e.g., bill of materials for each product, information for each machine), (ii) materials, production, and shipping status information, (iii) transactional data, i.e.. data on various events (arrivals of shipments, completion of lots), (iv) logs of problems, discussions, and so on, (v) product information (description of components and sub-assemblies). The model provides both product and process information and is a critical element of the infrastructure needed to support and integrate various phases of the reactive problem-solving process.

Previous work on manufacturing information systems design focuses on the relational database model, with text and numeric data, to model repetitive, structured information processing needs for manufacturing (Stonebraker [1994]). A variety of manufacturing/enterprise integration models and architectures have heen proposed based on the relational model: Manufacturing Resource Planning (MRP-II). Computer Integrated Manufacturing - Open Systems Architecture (CIM-OSA) (ESPRIT consortium AMICE [1989]), IS0 -- Standard for Exchange of Product Data (STEP/PDES) (IS0 10303 [1993]). These models while helpful as reference models provide minimal assistance in formulating data/information models that can handle multimedia document-based information in formats that are often difficult to access, synthesize and interpret.

In this section, we elaborate on the data/information model and the structure of documents associated with reactive problem-

solving. For brevity and ease of information modeling, we ignore the fact that these documents might be distributed across networks, departments and systems. The implementation of distributed “document databases” on a network architecture is a promising direction for further research. Section 6.1 presents a document-content structure model based on a graph grammar called SGML (Standard Generalized Markup Language), and Section 6.2 describes the semantic layer to describe the hierarchy of data elements in the manufacturing information base as well the structure of manufacturing processes.

6.1 Data/Information Model Recent advances in document technology

have made it possible to extend the manufacturing information model to include structured documents capable of supporting many data types. The data/information model that we present uses the well-established concept of context free grammars to model documents. Open Document Architecture (IS0 8613) and Standard Generalized Markup Language (IS0 8879) are two important developments in this domain. ODA is primarily concerned with the development of standards to permit interchange of structured office documents, while SGML provides a framework for modeling hierarchical data annlications (see Goldfarb 119901) . We use SGkio model text and multimedia databases in the manufacturing context.

For reactive problem-solving, the data model must support the notion of views and composition. Different agents need different views of the data. Consider, for instance, data in the component database. Engineers and production managers need to know available standard components and CAD information for specifying valid substitutes, materials planners monitor the inventory status of all components, while the PPL manager is concerned about the number of pieces allocated to his/her line. A common data/information model ensures that everyone gets consistent, up-to-date information, eliminating arguments about the definition and validity of the basic information that each agent uses to support his/her positions. To support these requirements, we partition the data/information model into two layers: the semantic layer and the document content layer (see Figure 11).

The semantic layer defines the views and other semantic rules for capturing the document

52 A. Balakrishnan et al. /ht. J. Production Economics 38 (1995) 31-58

characteristics that are useful in collaborative activities specified by the hypermedia process layer. Using concepts similar to a database schema, the semantic layer defines general document characteristics that are common across all applications. The bill of materials is one example of a semantic structure; it provides a unifying framework to encapsulate component documents describing the makeup of individual parts. The information presented is derived from data stored in textual. graphical, audio, or video

form in a revisable database which is composed of logically connected, but randomly accessible, data elements. The document content layer describes individual document structures using document grammars defined by SGML, analagous to the description of tables in relational databases. Conceptually, the semantic layer pertains to information about documents or a class of documents, and the content data layer deals with information structures within documents.

Purchasing View

Engineering Vie

Physical Databas

Production Vie-

Management Vi

semantic layer) -. Logical Database of

SGML Documents Physical Databas

t

Diffenxt Views during Problem-Solving

Domain &cific definition written using Domain

Definition id Mapping Actual Document written in Document Storage

Definition and Hypermedia Manipulation Language

Definition Language (SGML)

Figure 11: Parts of the Da&Information Model

4.2 Representing Intrinsic Document Content Finding the appropriate knowledge

representation structures for product information, one that is well-suited to information sharing, is critical for reactive problem-solving. For instance, managers or technicians in the field need to access and browse through vast libraries containing information for hundreds of board types and thousands of component types to diagnose and trouble-shoot. The Document Content layer is concerned with the logical representation of content and structure within a document component.

Our goal is to show that the use of SGML document representations will provide more timely, high-quality component information to the problem-solving process. A document component is the basic object provided in the database storage layer. The atomic component is an abstraction replacing the widely used but weakly defined concept of ‘node’ in a hypertext (Conklin [1987]). The document component includes a content specification represented by the SGML Document Type Definition (DTD). the actual content and a set of attributes, a presentation specification, and a set of links to other relevant documents. The DTD defines the rules for the construction of the document. in

other words, the document grammar. The contents of a link component is a list of specifiers, each including a component type specification, location address as well as anchor identifiers. An example of a such a link is (ftp://cism.bus.utexas.edu/), a Uniform Resource Locator used in the widely used World Wide Web wide-area information systems.

The range of possible content/structure that can be included in a component is not restricted. Text, graphics, animation, simulation, video and many other data types are possible candidates for inclusion inside a component. Today, component information is published mainly in printed form, and the transcription of that information into CAD libraries and technical handbooks is typically an expensive manual process, one that is often replicated by each organization that uses a given component. To avoid this costly repetition, it is important to develop a specification technique to standardize the mechanisms for the exchange of electronic component information.

The following figure shows the logical representation of component information into four distinct categories: Administrative, Engineering, Manufacturing and Diagnostic. Each category is again further refined into specific sub-categories . For instance, the administrative category can be

A. Balakrishnan et al. / Inf. J. Production Economics 38 (1995) 31-58 53

further partitioned into product data, product information and material assets (see Figure 12).

Adminstrative Engineering Manufacturing Diagnostic

Adminstrative

<Product_Material_Asset> <Product_name7 &roduct_Numti &wneX=. cVersion_IJh cVersion_date> cIIlfo_source> <country_of_otiginB

cManufacturer_Namez= cManufacturer_CAGE_Code>

<Copyrigh_and_Tradernark.w &erms_and_Conditiow

cFYoduct_Support, <Product Data>

&ken&g/Access_Contml~ -zDocurnen_Set_listz-

<Replaces> <Derived_From> <Replaced-by>

<Safety_Regulations> cRelated_Specs_list> cSecurity_Classification>

cTariffs_and_Customs_Tex~ <Product_Description_tex~

cProduct_Status>

Figure 12: Information categorization in a Electronic Component

We have developed several prototype document type definitions for use in reactive problem-solving, one of which we present below. This DTD has be parsed with the SGMLS parser (a free public-domain parser used validate correctness of the SGML document instance) . Although this DTD is not comprehensive enough to cover all the information categories outlined in Figure 12, it serves to illustrate the concept.

c!DOCTYPE ComponentJnformation [  <!ENTITY % Graphic_Types

“Image I Vector I GIF I EPS I PICT I CGMChar ICGMClearIBMPIMETlTIFFICDR”>

c!ELEMENT Component - 0 ((Admin & Engineering & Production & Diagnostic_Info?)>

c!ELEMENT Admin - 0 (Name, Manufacturer, Supplier ) >

<!ELEMENT Engineering - 0 (Description, Schematic?, Reference+ ) >

<!EI_.EMENT Production - 0 (Manufacturing_Parameters) >

c!ELEMENT Diagnostic_Info - 0 (Problems, Symptoms, Solutions) >

c!ELEMENT Description - 0 (paragraph)+ z= c!ELEMENT Schematic 0 0 (#PCDATAI

Qureltable) z c!ELEMENT (Reference) - 0 (#PCDATA ) >

c!ELEMENT Manufacturing_Parameters - 0 (Placement_info. Operating_conditions) >

c!ELEMENT (Placement-info, Operating-conditions) - 0 (#PCDATAI figureltable) >

c!ELEMENT (Problems, Symptoms, Solutions) - 0 (##PCDATAI figuteltable) >

<!ELEMENT (paragraph) 0 0 (#PCDATA I figure I table)+ z=

c!ELEMENT (figure) - 0 (graphic, caption) ) > c!ELEMENT (graphic) - 0 (%Graphic_Types;))> c!ELEMENT (caption) - 0 (#PCDATA) ) >

Next, we present an abbreviated instance of a component description (Texas Instruments 74LSUO NAND gate) containing Administrative, Engineering, and Production information. We can supplement this description with schematics, timing diagrams and simulation information, e.g. VHDL or Verilog models, to aid engineers in the design as well as the problem-solving process.

54 A. Bnlnkrishnan et al. / Int. J. Production Economics 38 (1995) 31-58

cCommen0 The following component information is for a Texas Instrument 74LSO0 c/Comment, cComponen0 tAdmin>

<Name> SN74LSOO </Name> cManufacturen Texas

Instruments </Manufacturer> <Supplier> Texas Instruments,

Dallas </Supplier> </Admin> <Engineering>

<Description> Quadruple 2-Input Positive NAND Gates. These devices contain four independent 2-input NAND gates. The SN5400. SN54LSOO. and SN54L&O are characterized for operation over the full military temperature range of -55 C to 125 C. The SN7400, SN74LSOO. and SN74SOO are characterized for operation from 0 C to 70 C.

</Description> <Schematic> SN74LSOO.VHDL

c/Schematic> <Reference> PortDef smt2O.std.lst

c/Reference> <Reference> ViewMapDef OO.sim

</Reference> c/Engineering> <Production> <ManufacturingParameters>

<Placement information> . . . c/Placement_inforr&tion>

cOperating_conditions> .__ c/Operating_condition0 </ManufacturingParameters> c/Production> cDiagnostic_Info> . . . . . . _ c/Diagnostic_Info> c/Component>

A good data representation technique can aid many different activities during reactive problem- solving. For instance, activities that need to be supported by a shared component data sheet content model include:

l Component selection: Provide component information for purchasing, materials management and engineering that is robust enough to enable selection of components by features, parametric searches, data sheet keywords, and device product number.

l Diagnosis: Associate problem symptoms, root causes and other relevant information with the components to develop a component history useful for problem- solving. Link to Interactive Electronic Technical Manuals (IETM).

- Physical layout (e.g. MCM or PCB): Provide the necessary package footprint information to drive physical layout tools and machine controllers.

l Library loading: Include CAD-sensible data necessary to create the libraries required for the design process activities.

9 Design verification (simulation): Provide the necessary models to enable design verification using simulators (VHDL, Verilog etc.)

Several organizations (e.g. CommerceNet. Pinnacles Group, CAD Framework Initiative, National Institute of Standards Organization, CALS-Department of Defense) are currently developing document type definitions (DTD) (using SGML tagsets) to represent the logical structure of product information for their application domains. The purpose of these DTDs is to enable the encoding of information stored in these documents for reuse by different users.

6.3 Composite Documents Instead of thinking of documents as

monolithic entities, we can define them as a composition of components. Composite components provide a hierarchical structuring mechanism. For instance, a book is a document consisting of components such as chapters, sections, paragraphs etc. As we noted earlier, we are interested in representing the internal structure of manufacturing documents. A manufacturing document that is used extensively in reactive problem-solving is the product information document. Some examples of product documents used in the electronics manufacturing include ASIC design kits, standard parts, power supplies and connectors.

The document content layer simply describes the structure of the document without specifying how to use the document for a particular problem- solving setting. Should use behavior be embedded at the document level or in a layer outside the document? By including behavior inside a document, it usage may be subtly restricted at the design stage, creating unanticipated side-effects. We propose encoding the semantics of documents in a separate layer that is built on the logical structure. The semantic layer explains what the behavior of document elements must be given certain conditions, and how document content will be viewed by the user.

The goal of the semantic layer is to define collections or groups of documents which have a

A. Balakrishnan et al. / Int. J. Production Economics 38 (199.5) 31-58 55

common identity or behavior. Collections play an important role in document databases. A Collection is a way of aggregating related documents or document elements. Document grouping is similar to the process of kitting in manufacturing where any required components can aggregated as single part number to facilitate easier management. A composite document may be assembled from the constituents or produced by specializing other documents, or both. An example of the semantic layer is used extensively in manufacturing is the Bill of Materials (BOM). The BOM identifies which components go into an assembly, describes their order of manufacture, and specifies where each component is located in the item being manufactured. The BOM focuses on partial document clusters that make up different segments of the assemblies. These clusters further define a product in terms of a nested decomposition into constituent elements. For some products, decomposition results in lengthy and complex lists of constituents that require considerable effort to manage properly. A machine processable domain-level schema representation for abstractions such as the BOM will facilitate the exchange and extension of the information model relevant to document groups (clusters) and document networks (hypertext links). The goal is to facilitate the exchange of schema information via the network, and promote the ease of maintenance of the information model.

Semantic organization plays a very important part in problem-solving. Given the large number of documents that are being generated during the problem-solving process, it is extremely important to be able to organize the document space into categories, both for the purpose of management and indexing. Document management involves generating queries to retrieve information. Queries are a high-level specification of objects of interest from the document database. Queries are generated over the instances (actual documents in the database) or the logical document strncture. It important to understand why querying in the document model is different from the relational model. In the document model, queries are expressed over collections of documents, resulting in attempts to find optimum strategies for expression evaluation. In the reIationaI model, queries are cast in terms of well-defined operators over very simple structures (i.e.. normalized relations). An index, on the other hand, is a precomputed query. By looking up the desired answer in the index, we identify documents that have yielded that answer, thereby eliminating the need to do a search.

Amon et al. [1994] provides more information on document indexing, query formulation and processing.

CONCLUSIONS

This paper has presented the requirements of a electronic document-based coordination system for reactive problem-solving, motivated by a study of the multifunctional materials shortage problem in electronics assembly. In order to better understand what type of computer support is most appropriate for reactive problem-solving, and how best to design a system that can provide this support, we developed a conceptual framework linking the organizational problem- solving processes to the computing environment through a four-layer hierarchy. Starting with the top layer, we explored the information needs and collaboration characteristics during each phase of the organizational process-from problem identification, through diagnosis, solution planning, and implementation. The computational (hypermedia) process layer mirrors the organizational process, serving as the software platform to orchestrate the communication, information access, and collaboration needs of each phase. We then presented a data/information model implemented using SGML. SGML provides a means to identify or “tag” the information elements of documents with great flexibility so that the structure of the information in the document and the relationships of its parts may be described with the clarity required to allow automated assembly, disassembly, modification and reassembly of the information elements.

The discussions in this paper have identified several promising research directions to pursue in this important arena of coordination support systems: (i) Developing procedural interfaces: These interfaces specify how applications at the process layer will interact with the data described by the information model. The concept of a document as a centrally located object having different instances is losing ground to the concept of a document object as a networked compound entity that pulls in other materials when accessed. In turn this networked entity concept requires procedural interfaces and real-time network connections_ Real-time network connections are fast becoming part of a document’s access apparatus through mechanisms such as Universal Resource Name (URN) and Universal Resource Locator (URL) (Berners Lee [ 19931). (ii)


Developing strategies to locate the right information quickly in a manufacturing context: Rapid and accurate information search and retrieval are essential in a time-constrained, quick response manufacturing environment. Effective indexing of the information space is also essential, to avoid brute force information search and retrieval methods and promote browsing. Browsing is necessary since precise queries are difficult to formulate in a problem-solving process (Salton 119891). (iii) Data visualization algorithms and techniques for transforming data into multiple display formats on target machines: As manufacturing firms move towards greater product customization, it is difficult to predict in advance what information is relevant and how it can/should be used in problem-solving. To support this trend, computing systems must permit the creation of dynamic structures requiring different visualization and display formats (Halasz [1989]) which are generated on demand depending on the problem at hand,

To summarize. in this paper, we have presented a novel document-centric approach to support manufacturing coordination and problem- solving. Information technology is a key enabler to cope with rapid technological changes, increasing customer involvement, and greater supply chain integration. Today’s monolithic manufacturing information systems are one of the biggest impediments to agility. Applications are “hardwired”, held together using software and database interfaces, and are not flexible or amenable to full integration, maintainability, and upgradability. Our approach and preliminary results show promise in overcoming some of these obstacles.

REFERENCES

Adams, J.J.. Conceptual Blockbustine: A guide to better &&I 3rd cd. Reading MA: Addison- Wesley. 1986.

Argo& L., “Input Uncertainty and Organizational Coordination in Hospital Emergency Units”, Admlnstrative &ience Ouarterlv. Vol. 27, pp. 420-434.1982.

Amon. D, R. Kalakota and A.B. Whinston, &J SGMmsed Met&dolorrv for Catalog General&n for Distributed Document a. Working Paper, Center for Information Systems Management, University of Texas at Austin, 1994.

Argyris, C. and D.Schon, Qrqanizational . . Lea rune. A Theorv-in-Action Perspective.

Reakng, MA: Addison-Wesley, 1978. Bang, D., J. Decker, R. Gisler and D.Haugen,

“Synchronizing Manufacturing and Materials Flow”, Proceedinpg

oey Electronics Manufacturing Technol Svmoosium, pp. 252-255, IEEE, 1990.

Bemers-Lee, T.. “Uniform Resource Locators”, Internet Request for Comments (RFC), 1993.

Conklin and Begeman, gIBIS: A hypertext tool for exploratory policy discussion. ACM Trans, Jnf. Svstems. ~01.6, no.4 pp.303-331, 1988.

Dewey, I., How we think. Boston: D.C. Heath, 1910.

Drucker, P., “What we can learn from Japanese Management”, Harvard Business Review, Vol. March-April, pp. 80- 122, 197 1.

Duncan, R., “Characteristics of Organizational Environments and Perceived Environmental Uncertainty”, Adminstrative Science Ouarterlv, Vol. 17, pp. 313-327. 1972.

ESPRIT consortium AMICE, 1989. m Systems Architecture for CIM, Springer- Verlag, Berlin.

Gerwin, D., “Relationships between Structure and Technology”, In Handbook of Orpanizational Desien, Nystrom and Starbuck (eds.) Vol. 2, pp. 3-38,198l.

Gresov, C., “Exploring Fit and Misfit with Mulitple Contingencies”, Adminstrat’ e Science Ouarterlv, Vol. 34, pp. 431_453,19819v.

Gronbaek, Kaj ; R.H. Trigg. Design issues for a Dexter-based hypermedia system, Co, un’cations of the ACM, Vol. 31 ; No. 7 ; pp.?&l: 1994.

Halasz, F. Reflections on NoteCards: Seven issues for the next generation of hypermedia systems. Commun. ACM 31, 7 (July 1988), pp.836852.

IS0 8613 . In r fo mation Processine Svste ms -- TX ; fi Architecture CODA). International Organization for Standardization. Ref. No. IS0 8613:1988. Geneva/New York, 1988.

IS0 8879 . information Processing -- Text and Sta d Gene 1 ed Office Svstems __ ndar ral’z

Markuo J.a 4us~ge (SGMLl. International Organizationnfor Standardization. Ref. No. IS0 8879: 1986 (E). Geneva/New York, 1986.

IS0 10303, Industrial automation systems and intePration - Product data eu ese tat o a d exchan~. National Instit:ter ofnStinndarnds (ftp://dove.nistgov). 1993.


Lawrence, P. and J. Lorsch, 1967. “Differentiation and Integration in Complex Organizations”, ’ Admlnstrative w. Vol. 12, pp. l-47.

Leggett, John J. and John L.Schnase,Viewing Dexter with open eyes; the Dexter Hypertext Reference Model, Communications of the a, Vol. 31 : No. 7 : pp. 76, February, 1994

March, J.G. and H.A.Simon, Oreanizations. New York: Wiley, 1958.

March, J.G., “Explorations and Exploitations in Organizational Learning”, Qrpanization Science, Vol. 2. No. 1, pp. 71-87. 1991.

McCall, R.. P. Bennet. P. d’oronzio, J. Ostwald, F. Shipman, N. Wallace, “PHIDAS: A PHI- based Design Environment Integrating CAD Graphics into Dynamic Hypertext”, in Hvne text: Conceots. Svstems and Aooli~ations, Proceedings of the European Conference on Hypertext, INRlA, France, November 1988 (eds. A. Rizk. N.Streitz and J.Andre). Cambridge University Press, Cambridge.

McCann, J. and J. Galbraith, “Interdepartmental . . Relations”, In Handboo o 0 ga at o a Desirm. Nystrom and SLbuLk ;cdsn)t,zVil!21, pp. 60434, 1981.

M&&berg, H.. Duru Raisinghani and A. Theoret, “The Structure of “Unstructured” Decision Processes”, Adm-nstrat’ e

lv,Vol. 21. pp.r246-2Xr,v1977. Science

Ouarter Nadler. D. amd Tushman, M.L., “A congruence

model for diagnosing organizations”, Qrtzanizational Dynam as. Winter, 1980.

Newell, A. and H. Simon. Human Problem %:2ing. Englewood Cliffs, N.J. Prentice-Hall,

Nutt, P., “Types of Organizational Decision Processes”, Adminstrat’ e Science Ouarterlv, Vol. 29, pp. 4 14-450,19i&.

Prasad. R. P.. &face Mount Technology; Princioles a d Pract’cc Van Nostrand Reinhold, NewnYork 198i9 ’

Rittel, H. and M.Webber, ‘“Dilemmas in the General Theory of Planning”, Policv Sciences, Vol. 4, pp. 155-169. 1973.

Salton, G. Another Look at Automatic Text- Retrieval Systems. Commun. ACM, 29(7), pp. 648-656. 1989.

Senge. P.M., “The Leader’s New Work: Building Learning Organizations”. Sloan Manacemea Review, pp. 7-22, Fall 1990.

Stonebraker, M. Readi w in D&ase Svw , Morgan Kaufmann. San Mateo. CA 1994.

Thompson, J. D.. Qreanizations in Action. New York: McGraw-Hill, 1967.

Toulmin, S., The Uses of ArPument. Cambridge University Press, 1958.

Van de V&r. A., A. Delbecq and R. Koenig, “Determinants of Coordination Modes within Organizations”, American Sociolonical Review, Vol. 4 1, pp_ 322-338, 1976.

Winogmd. T.. A Language/Action perspective for the design of cooperative work, Human- Comouter Interaction, 3(l), pp. 3-30, 1987.

Witte, E., “Field research on complex decision- making processes-The phase theorem”, International Stud’es in Management and

‘on, pp. l&-182, 1972. Oreanizah

APPENDIX A

Standard Generalized Markup Language (SGML)

SGML is a meta-language for describing the logical and content structures of a document in a machine processable syntax. Because SGML does not target any one application, it can be used as a tool for all types of electronic document applications -technical, financial, office, insurance, or legal publishing. It is used to describe textual or multimedia data. Unlike other traditional databases, multimedia data is unfielded. Identifying the location of product code in a data stream is easy in traditional data processing, but this operation is more complex in multimedia processing since no standard database definition is available for reference. Instead we must devise a way to describe the data organization in unfielded multimedia document sin an universal yet flexible manner. Where a particular element starts and ends is based upon where it occurs in relationship to other elements and on identifiers marking its starting and ending positions. SGML describes each element’s permissible positions and relationships to other elements in the document. S GML is used:

to describe the logical structure of electronic documents in unambiguous grammar called Document Type Defmition (DID).

to assure automated quality control over adherence to that structure by document parsing, and

58 A. Balakrishnan et al. / Int. J. Production Economics 38 (199.5) 31-58

- to deliver and store digital text in the most easily maintained and updated form.

The use of a document type definition (DTD) one of the most powerful concepts underlying

iGML, defines a specialized markup language for use with a specific application. Through an SGML document type definition, an application can rigorously and strictly define the structure of a class of documents such as job guides, flight manuals. fault isolation procedures, etc. These definitions can be tailored to fit the linguistic terms of the application. A segment of a maintenance manual tagged using SGML is shown below. The text in the angle brackets “4’ and 3” represents the markup. It is important to note that the use of markup transforms a previously unstructured document into a more structured entity on which operations like join, queries, and aggregates or views can be defined. To illustrate the idea of descriptive markup, let us look at a simple segment of a memo DTD. For memos only a simple data model is required. The main text consists of a set of paragraphs, notes and lists. Within paragraphs and notes one can embed text, highlighted phrases and lists. The two parameter entities @text and %phrases) defined here allow the definition of the following model to be simplified, or made more explicit. Note the use of parentheses to make the entity a separate subgroup of the model it is embedded in.

c!DOCI’YPE memo [ <!ENTITY 96 text “(listlfootnotelparagraph)+” > c!ELEMENT memo --((to&from&date& subject?), %text+ <!ELEMENT (toifromklate) - 0 (#PCDATA) ) > c!ELEMENT subject 0 0 (#PCDATAl%phrases;)+ -(figmeltable) > <IELEMENT (paragraph) 0 0 (#PCDATAlfigureltable)+ > <!ELEMENT (figure) - 0 (graphic, caption) ) >

Using this DTD it is possible to validate all the memos that are produced to check for conrectness and completeness. A valid instance of a memo that conforms to this DTD is given below:

<memo> <to> Jim <from> Tom <date> July, 20 1994 <subject> Shortage of 5 ohm resistors

<paragraph> We are facing a severe shortage of 5 ohm resistors on production line 5. c/paragraph> c/memo>

Such markup allows us to do SQL type queries on what were earlier full-text databases. It is not necessary to refer to all blocks of text as a paragraph or a section when it might be more appropriate to refer to one block of text as the data sheet, another block of text as a diagnostic step, another block of text as a problem checklist, etc. This ability to tailor descriptive tags to the application helps facilitate data access. As a language for text description. SGML is not procedural nor is it concerned with the output device or even the absence of one. The SGML document can be processed for on-line screen delivery, audio delivery, machine-to-machine delivery, paper delivery, database loading, or for all of these purposes. Because it is not better suited for one type of delivery method over another, it is not less suited for any one type of delivery method. It has no biases toward or against the description of tabular material, mathematical formulae, or other complicated textual constructs. Perhaps its most attractive feature is that text coded in SGML. can be used in many different ways without conversion or manual intervention with the data. A variety of output requirements can be overlaid on the logically structured document to serve the most diverse needs.

Document-centered information systems to support reactive problem-solving in manufacturing

Documents

Transcript of Document-centered information systems to support reactive problem-solving in manufacturing