Abstract: In tasks involving a variety of situations, people are often required to act flexibly, taking an appropriate course of action depending on varying situations. Instructions for performers of such tasks, therefore, have to show various possibilities and options as well as the underlying principle behind them. Describing possibilities and options in concrete terms leads to voluminous instruction, while describing principles in abstract terms leads to hard-to-interpret instruction. Striking a balance between them is a challenge. In this paper, the authors present their view and framework for discussion toward helping people meet the challenge. A case study is also presented where the authors demonstrate that their framework has the potential of identifying problems in existing practical manuals.
　　Key words: Instruction, organizational communication, organization management, knowledge communication.
　　1. Introduction
　　Communicating knowledge about how to perform a task is always difficult, especially when the task is complicated. Usually, the most common way to communicate such knowledge is to give instructions. Sometimes, instructions take the form of written manuals and are provided for tasks such as an operation of a chemical plant system, a call center operation, and so forth. Manuals of these tasks are vital not only to help new comers know how to perform the task, but also to share common knowledge among people involved in the task.
　　In order to ensure the task is performed as intended by those who give instructions, manuals are written with the aim of giving explicit instructions free of ambiguity. For example, some manuals for chemical plant operation describe the sequences of required operations in a well-structured form, defining contexts in a concrete manner and specifying exact buttons and levers to operate for each context as well as the order of those operations. Aiming to avoid ambiguity, such manuals sometimes end up being the compilation of case-by-case operation sequences, still falling short of covering all possibilities. In other words, manuals fail to convey principles and full range of possibilities as a result of its aim to take a rigorous, ambiguity-free form.
　　The problem of such rigorous instructions is that some receivers would do no more than simply following prescribed instructions, never becoming capable of handling undescribed situations flexibly. Unfortunately, there are many cases for which explicit instructions are not available, such as troubleshooting in software applications, incident handling in plant operation, demanding-customer handling in call center, and so forth. Facing novel, unfamiliar situations, they are at a loss to act, even if the situations can be addressed by making a small modification to what is described in the instruction.
　　In work settings, it is important for workers to be capable of dealing with such unfamiliar situations. If they could not deal with situations, appropriate performance would be hard to guarantee. Also, if they always consult well-experienced people every time they fail to find explicit instructions, such experienced workers may find it difficult to concentrate on their own work. This is all the more problematic if veteran workers are decreasing in number. Of course, it is almost impossible to make novices be experts simply by providing instructions. Still, giving them a bid of flexibility makes a big difference if they otherwise could do no more than following explicit instructions. To succeed in this, there needs to be a good medium of knowledge, giving readers the flexibility to take appropriate actions for variable situations.
　　However, giving such flexible instructions is not an easy task. The challenge here is how to balance the flexibility of abstract principles and the preciseness of concrete instances. Obviously, describing all alternatives in minute detail is impossible, since such concrete courses of action can be countless as is the case with troubleshooting of software errors. On the other hand, if one tries to describe instructions in a larger granularity, the number of alternatives may become of a manageable magnitude, but there is a risk of causing instruction receivers to be at a loss to act because such descriptions cannot easily translate themselves into concrete actions.
　　The goal of this research is to investigate a systematic way to provide instructions in the way that gives principled explanations that is flexible enough to enable people to handle variable situations and precise enough to guide them to concrete actions in variable situations. As mentioned, the challenge here is how to balance the both. In this paper, the authors present their research approach toward tackling this challenge as well as the current state of progress in discussion and investigation. This paper is organized as follows: Section 2 describes the authors’ framework based on which to represent their problem and discuss a strategy to cope with it; section 3 shows how their problem briefly sketched above can be somewhat formulated using the framework; in section 4, the authors discuss an appropriate modeling language for the description of the instructions that will be derived from the framework. The development of an appropriate modeling language will be an integral part of the final output of this ongoing research; section 5 introduces the whole picture of knowledge communication to identify problems of a higher-level that this research concerns; section 6 describes the case study where they demonstrate that their framework can be applied to the analysis and improvement of a real manual that is actually used in industry; finally, section 7 concludes the paper with the remark about the future course of action.
　　2. Framework for Discussion
　　In order to strike a balance between abstract principles and concrete instances, the authors have to have a way to capture both of them and links between them. If they can be made visible, that will serve as a framework for creating well-balanced instructions. The proposed framework is based on the idea of representing knowledge using what the authors call abstraction hierarchy. If some instances are derived from a certain model, rule, law, or any other form of general principle, that principle is said to be abstract as compared to those instances, while the instances are said to be concrete as compared to the principle. Likewise, if some means are to achieve a certain goal, the goal is abstract as compared to those means, and the means are concrete as compared to the goal. In short, something abstract is the reason why something concrete appears or is used. Consequently, one can find more concrete instances than abstract ones, for from one abstract principle or end come several (sometimes infinite) instances or alternative means. The abstraction hierarchy considered here has several layers each representing a certain degree of abstraction, and elements that are considered to be abstract to the same degree are situated on the same layer. Each layer is abstract to the lower one and concrete to the upper one. Thus, one can find more instances as she/he goes down along the hierarchy. The illustration of the abstraction hierarchy is given in Fig. 1. Note that this is just a rough sketch of the authors’ idea, just intended to help readers better understand it.
　　The authors greatly owe this abstraction hierarchy to Rasmussen [1]. Rasmussen, who had long studied human-machine interface in major physical systems such as plant operation systems, discovered that operators of such systems seemed to have several, intrinsically different information processing modes, using different modes depending on what the situation required. For example, when they saw that a certain number displayed on the control panel was within the predetermined safety range, the numerical comparison of the numbers was all what they did. A change was required when the number exceeded the range. They had to check other numbers and gauges as well to figure out what all those stood for, visualizing in their mind the system structure. Now their information processing mode was not of numerical processing but of functional reasoning. These are just two of several information processing modes that Rasmussen discovered. He then went on to propose a hierarchical representation of a physical system as it appeared to its operators, with the aim of developing a framework for designing a human-machine-interface. His premise was that if humans change their information processing mode, a human-machine-interface should also be designed so as to suit the needs of each mode. Different layers of the hierarchy provide different viewpoints from which to see a physical system. A valve, for example, is just a tool to open/close a path if the observer focuses on its physical function. However, it can be seen as a flow control tool from the viewpoint of general function and as a mass balance controller from the viewpoint of a more abstract function. Different viewpoints give the same object different recognitions. The aim of the hierarchy was to represent and organize such viewpoints. The framework tells that the information display should be designed so as to meet the needs of different viewpoints of humans. Although limited to physical systems structure, Rasmussen’s idea of representing human’s information processing as a travel along the abstraction hierarchy is a generally applicable framework for studying knowledge and its explanations.
　　3. Problem Elaboration
　　Based on the abstraction hierarchy, the authors can re-state their problem. First of all, they can say that if somehow organized, instructions are consistent in terms of abstraction level. Most instructions are given in a specific abstraction level. Take manuals of software applications for example. Some manuals give instructions by sequences of GUI (Graphical User Interface) level operations (e.g., “Select the file item on the menu bar”), while others, perhaps those for expert users, may use sequences of more granular operations like “Save the document in .txt format”, “Install the driver software with the bundled CD-ROM”. It is fair to say that the instructions of the second type are unlikely to coexist with those of the first type and vice versa, due to the difference in intended readers. The abstraction level differs across manuals, but mostly remains consistent within one.
　　Given that a set of instructions are provided in a consistent level of abstraction that is low enough for intended readers to comprehend the instructions (this level is called ground level), then the next step is how to help readers become capable of dealing with unexpected situations. If one tries to explain all possible solutions to every possible situation in the ground level, it may be infeasible due to an unacceptably large number of possibilities; the writer may not be able to recognize all possibilities and find sufficient pages to write them down on. A possible solution here is to raise the level of abstraction. Remember that from one abstract principle or end come several (sometimes infinite) instances or alternative means. Therefore, it follows that with a higher level of abstraction you can explain a broad range of possibilities with fewer descriptions. The problem here is how to balance between the flexibility of abstract principles and the preciseness of concrete instances. Writers are now demanded to explain a principle while showing a variety of possibilities derived from that principle, both in a comprehensible manner. On top of that, the description has to be smarter than simple enumeration of all possibilities at the ground level of abstraction; it is meaningless to make use of higher-level principles unless the resulting description becomes easier to comprehend than the original one.
　　Thus, the authors’ core problem can be formulated as follows: To investigate how to balance between the flexibility of abstract principles and the preciseness of concrete instances in a comprehensible manner, with the aim of helping instruction receivers become more capable of handling situations with no explicit instructions prescribed.
　　
　　Fig. 1 Illustrative sketch of abstraction hierarchy.
　　4. Modeling Language
　　The way of expression expands or constrains one’s ideas. If you describe a process using flowchart, for example, your attention goes to the order and the braches of well-defined steps, and you would not think of such things as players, synchronization, object, etc. These concepts, however, will come into your mind when describing the same process using the activity diagram which is a part of UML (Unified Modeling Language). This is why so many modeling languages have been proposed.
　　The authors’ hierarchically structured instruction also calls for an appropriate modeling language. Unfortunately, currently available modeling languages fail to show a promise. For example, there are many modeling languages intended for software systems development, from traditional ones like flowchart and dataflow diagram to such modern techniques like UML. They are fairly good at describing well-defined structures, but lack the flexibility to describe the variety seen in real-world tasks, demanding the modelers to make every instruction explicit. In fact, some professional developers already gave up using the modeling approach as means of eliciting requirements, and instead have tried to ensure effective communication with their clients by rapid repetitions of prototyping and feedback. After all, the modeling languages for software development need to be compatible with computer-oriented digital processes, and it is only natural that they cannot tolerate ill-defined possibilities in the real world. On the other hand, there is a modeling language which intends to describe human-involved processes. The functional modeling language IDEF0 [2], which was based on the SA (Structured Analysis) language [3], a graphical modeling language, has as its premise the belief that describing and managing human activities is important in order to make good use of information technology systems. Like the authors’ concept, the SA language features the hierarchic structure of a subject. Although its rigorous grammar does not immediately lead to flexible expressions, the SA language provides users with unique notations which, together with the hierarchic structure, successfully represent reasons and mechanisms. Careful study and some tailor of the SA language may bring the authors a promising method to express both abstract principles and concrete instances.
　　5. Knowledge Communication Model
　　Although the authors’ current problem has been already delineated, they now briefly sketch their grand model to situate their current investigation in the whole picture. The authors have been discussing how an instruction should be given to its receiver. Put in a broader perspective, those who give instructions also used to be novices in the past. They learned a lot by first-hand experience and instructions from yet other people. That is why they are now capable of handling variable situations; in their mind are lots of instances and abstract principles. To give instructions is to decode such abstract principles and transform them into visible descriptions. Then, the described instructions convey knowledge to instruction receivers. However, such an easy story is hardly the case. Unfortunately, experience is the hardest thing to communicate and the gap between those who experienced something and those who did not has been never seen bridged.
　　One possible reason is that some parts of experience are filtered out, not taken into account when abstraction occurs. Having experienced many instances and learning lots of pieces of knowledge, people for some reason try to generalize them and find some abstract principles. Although there is no established consensus on the process of abstraction, many would agree that the process is not as simple as a strict one-way sequence. Instead, it should be a kind of parallel process; from a set of instances comes an incomplete principle which has not yet taken a complete form. Once such an incomplete principle starts taking its shape, instances are sought that fit the incomplete principle well, gradually solidifying it. On the other hand, instances that do not fit well the principle are likely to be filtered-out, that is, neglected. Although there is no guarantee that the incomplete principle now under construction is the only valid principle that can explain everything, people often quit letting more than one principle coexist and instead choose a simple and easy understanding. Because principles and instances contradicting the incomplete principle are absent, instructions created by that person are destined to be biased.
　　Another possible reason is that the expressive power of the language used prevents principles and instances from being described properly. The type of language affects people’s thinking. When writing computer program code, no one would think how to write an analogy of a certain algorithm, because there is no way to describe an analogy using programming languages. On the other hand, usual people do not think of class or instance when writing a natural language. This is also because natural languages are not good at describing such concepts. In other words, devising a good language can create a solution to communication problems. That is why many languages have been studied and some of them have been used widely.
　　Yet another factor impeding communication is the gap of knowledge between provider and receiver of instructions. As said earlier, decent instructions are given in a consistent level of abstraction and that level is decided so that the intended receivers of the instructions can easily comprehend what the instructions tell them. It is obvious that a problem emerges when that is not the case. Consequently, communication becomes more difficult when the gap is larger between the level that intended receivers can understand and the one that the target principle belongs to.
　　Having discussed reasons for the difficulty in knowledge communication, the authors are now in the position to present the sketch of their big picture on knowledge communication as shown in Fig. 2. The instruction provider obtains abstract principles based on filtered experience and knowledge. Abstraction and selection are interrelated to each other. When trying to describe instructions, the provider has to deduce possible instances from principles and describe them along with the principles. Thus, deduced instances can be a useful guide for understanding the principles. If s/he fails to recognize important instances, however, the resulting instructions will have a potential failure however expressive the description language may be. The receiver of instruction receives the instructions and follows the same route as the provider, although there is no guarantee that the receiver understands the instructions as the provider intends. If the instruction receiver in Fig. 2 is to give instructions to yet another person, she/he is now a provider of instructions and has to give instructions instead of taking actions, continuing information relay. This is how an organization is managed and its strategy instructed by top managers is disseminated until finally implemented. Fig. 2 shows four types of filters, namely, selection, abstraction, deduction, and expression filters, each of which can be the cause of a communication failure. Some of the failures have been already mentioned, but the entire list is presented here:
　　Neglect of instances—receiver who has an incomplete principle still under construction neglects the instances that do not fit the principle well(interrelated to neglect of principles);
　　Neglect of principles—receiver who already had one principle, complete or not, do not create another one even though there are instances that cannot be explained fully by the existing principle (interrelated to neglect of instances);
　　Failure of abstraction—receiver recognizes instances but cannot find any principle behind them;
　　Failure of deduction—provider who has a relevant principle fails to provide some important instances derived from that principle;
　　Failure of expression—provider who has a set of relevant instances in mind fails to express all of them.
　　
　　Fig. 2 Illustrative sketch of knowledge communication model.
　　6. Case Study
　　In this section, the authors investigate a practical manual and see how their view can identify possible problems. The manual used here is the one for a power plant operation. It consists of three sections for start-up, shutdown, and emergency situations. The section for emergency situations consists of case-by-case references, each of which just describes a sequence of operations in rather granular terms. The sections for start-up and shutdown are each divided into about 40 steps; still each of those steps includes tens of events and operations. The exact button to operate or measure to observe is specified for each of such events and operations. Although each step has the label indicating what the step is for in terms of function, within each step is just a sequence of operations, making the purpose or intent of each operation invisible. When studying in detail, however, one can find that there are modular-like patterns of operations, such as pump starting-up pattern, valve closing pattern, pressure raising pattern, and so on. Sets of operations that seem to be an instance of a certain pattern often appear in several steps, but they are different in minute detail; a certain operation seen in one instance is absent from another; the order of operations is often slightly different from instance to instance. Of course, in the manual there is no description about to what extent these instances can be explained by a single principle. If there is a principle that can explain most of the instances, one can give principled explanations by combining the principle and instance-dependent variables. That will eventually help readers become more capable of dealing with variable situations since now they can learn the visualized principle.
　　The authors investigated seven instances of the pump start-up operation. Each instance is a sequence of operations for a different pump. The seven pumps are characterized by the combination of pressure level and type, which are summarized in Table 1. The sequences of operations for all the seven instances are shown in Fig. 3 where each vertical lane represents one instance.
　　As shown in Fig. 3, some operations are seen common in all instances, suggesting that there are invariant structures. Actually, one can find some invariant patterns specific to, for example, high pressure instances (e.g., one needs to stop PUMP X) and drain pump instances (e.g., one needs to confirm flow level and check sample quality). However, without any explicit principles behind the operations, no one can tell if those patterns are intrinsically true or they just appear by chance. It is also unclear to what extent generalization is possible. One thing that impedes generalization is the apparently arbitrary order of operations. The painted cells in the table indicate that the operations there appear in such orders that look bizarrely inconsistent from instance to instance. Do these different orders or timings for the same kind of operations have any reason or are they just the result of a careless arrangement? Without any explicit principle behind them, one cannot understand what is always true and what is variable, making seemingly possible generalization unobtainable and loosing the ticket to a greater capability of handling variable situations. This, however, means that simple additions of such principles could make a difference, and the benefit will probably deserve the space in the document and the effort of writers that are necessary for describing them. The authors also found that their point of view had the potential of indentifying the problems in the practically used manual.
　　Table 1 Seven pumps for seven instances.
　　
　　
　　Fig. 3 Operation sequences for seven instances.
　　7. Conclusions
　　In this paper, the authors presented their view and framework for balancing between the flexibility of abstract principles and the preciseness of concrete instances, which aims at helping instruction receivers become capable of dealing with variable situations where no explicit instructions are available. The authors also conducted the case study on the actual manual and demonstrated that their framework could help to identify problems and suggest possible improvements. Although the demonstration suggested the potential of this approach, they are fully aware that they have just presented a rough sketch of the problem and this approach. Further elaboration and delineation should follow as well as the discussion on what situations in the real world highlight the benefits of this approach.
　　References
　　[1] J. Rasmussen, Information Processing and Human Machine Interaction: An Approach to Cognitive Engineering, Elsevier Science Publishing, New York, 1986.
　　[2] Available online at: http://www.idef.com.
　　[3] D.T. Ross, Structured analysis (SA): A language for communicating ideas, IEEE Software Transaction Engineering SE-3 (1) (1977) 16-34.