EULE2: A Knowledge-Based System for Supporting Office Work Ulrich Reimer, Andreas Margelisch, Bernd Novotny, Thomas Vetterli Swiss Life Information Systems Research Group Postfach CH-8022 Zurich, Switzerland email:
[email protected] 1. Introduction At Swiss Life, as in many other companies, office workers for customer support are no longer specialists dealing with certain kinds of office tasks only, but are becoming generalists who must deal with all kinds of tasks. There are many laws and company regulations which take influence on how a certain task is to be performed properly. As a consequence, the work of this new generation of office workers is quite demanding and urgently calls for a better support. For this purpose, the Information Systems Research Group of Swiss Life has developed a knowledge-based system, called EULE2, that aims at providing a user with a maximal guidance in performing office tasks he may not be familiar with. A research prototype is completed and we are now in the phase of developing the first official version which is intended to become deployed. In the following, Section 2 characterizes EULE2 as a user sees the system. Subsequently, the architecture of EULE2 is outlined (Section 3). EULE2 and issues of knowledge management it is related with are addressed in Section 4. Section 5 concludes the paper and gives an outlook on future work. 2. The EULE2 System as Seen by the User An office task can be visualised as a graph (cf. Figure 1). Its nodes stand for states in which the user must perform certain actions, like entering data about a new customer, or obtaining an endorsement from a manager. Some of the actions (like generating letters) are performed by EULE2 (possibly delegating it to another application system), the others are done by the office worker, telling EULE2 when they have been completed. Only when all actions associated with a state have been performed the user can change to a subsequent state1. The possible transitions to a subsequent state are indicated by the links of the office task graph. They are associated with conditions that must 1
It should be noted that here, unlike in state-space graphs, an action does not cause a transition into another state.
be fulfilled to reach the corresponding, subsequent state. Depending on the outcome of the actions performed in the current state one (and only one) of the transitions becomes permitted. The transition conditions derive from law and the company regulations (see Section 3). An office clerk starts work with EULE2 by selecting an office task and entering task-specific data as requested by the system (EULE2 takes most of the data needed from various data bases and does not request it from the user). As long as the office task is not completed each state has one or more possible subsequent states. From the data given EULE2 decides which path to follow in the graph. However, nothing is done automatically. The control of which state to enter next stays with the user but he cannot go on to states (and thus associated actions) that are not permitted. Subsequent states may be illegal (indicated by red arcs) or permitted (indicated by a green arc). The office worker may decide to go to a permitted subsequent state, may inquire why it has become permitted, or may ask why the transition to one of the other states is not allowed. When the office worker goes to a subsequent state he encounters a new list of actions that must be performed. The office task is finished when a terminal node in the graph is reached. The above description may give the impression that EULE2 is a kind of workflow management system. However, this is not the case, although some of its functionality can indeed be found in a workflow management system, too (see Section 4 for a further discussion). The following, extremely simplified (!) example of the office task “bankruptcy” gives an impression of how strongly law and regulations determine how an office task is to be executed. This is not only characteristic of the insurance domain but for other domains, too (as we know for certain for the banking and energy supply domains). Thus, the approach we have taken with EULE2 is of a general relevance and not confined to the insurance domain.
Figure 1. An office task as a user of EULE2 sees it Example: The office task sketched schematically in Figure 2 describes what an office clerk must do if he gets informed that somebody went bankrupt (it is a simplified version of the graph partially shown in the screenshot of Figure 1). The Bankruptcy Office publicly announces all cases of bankruptcy. Everybody who holds properties of the bankrupt is obliged by law to report them to the Bankruptcy Office. The property an insurance company may hold of a bankrupt is an insurance where the bankrupt is policy holder. Whenever an office clerk is informed of an opened bankrupt proceeding, he must check if such an insurance exists (state S0). When the bankrupt is not policy holder of an insurance the office clerk destroys the notification of bankrupt and closes the case (state S1). Otherwise, the office clerk must report the insurance to the Bankruptcy Office (state S5), unless an exception is defined by law. One kind of exception states that a provident insurance is exempt from seizure. In such a case it is therefore not necessary to report them to the
Bankruptcy Office. Instead, the office clerk informs the bankrupt that he remains policy holder (state S2). An insurance where the spouse, the children or both are the only beneficiaries is also exempt from seizure. By law such an insurance is transferred to the beneficiaries as soon as the policy holder goes bankrupt. The office clerk informs the beneficiaries that they are the new policy holders (state S3). The beneficiaries have the right to accept or reject the transfer of the insurance. They accept the transfer by sending a certificate issued by the Debt Collection Office to the insurance company. The reception of the certificate is a necessary precondition for Swiss Life to issue a new policy and to send copies to the new policy holders (state S4). By sending a note to the insurance company the beneficiaries can reject the transfer of the insurance. When an office clerk receives a note of rejection he reports the insurance to the Bankruptcy Office (state S5) because it is up to the Bankruptcy Office to decide what to do with the insurance.
Enter data
S0: about the bankrupt
bankrupt is not a policy holder
S1:
Close case: Destroy notification of bankruptcy
S2:
bankrupt has a provident insurance
bankrupt has an insurance where the spouse and/or children are the only beneficiaries
Send letter to the bankrupt that he remains policy holder
S3:
Send letter to the new policy holders; wait for answer
beneficiaries accept
Send insurance
S4: policy to the new policy holders
otherwise
beneficiaries decline
S5:
Send letter to the Bankruptcy Office
Figure 2. An extremely simplified example of an office task graph
3. Architecture of EULE2 To achieve its functionality EULE2 needs a considerable amount of knowledge about • the office tasks, mainly consisting of • a partially ordered set of states, • for each of these states the associated actions to be performed, • the objects (or instances) to be manipulated and the concepts they belong to, • all the laws and regulations that must be obeyed by the office tasks. Although that knowledge could in principle be hardcoded into a program, EULE2 can in practice only be realized as a knowledge-based system where the knowledge is represented declaratively. The following reasons can be stated: • Maintainability: Office tasks, regulations and law change over time. Especially company regulations are quite often revised or extended. To make EULE2 of any use to an office worker requires that the knowledge can be updated very quickly and with small effort. • Dynamic explanation generation: Using a system like EULE2 should not render an office clerk more and more incompetent over time. Consequently, any assistance the system gives must be accompanied by the offer of an explanation why certain things are to be done in the way as indicated (i.e., according to which law and/or regulations). The dynamic generation of explanations (in contrast to canned text) is only possible with a knowledge-based system where it is always clear on the base of what knowledge which inference results have been obtained.
• Consistency of the modelled knowledge: When the knowledge employed by EULE2 is represented declaratively many consistency and plausibility checks become possible. It could for example be checked if any two regulations are contradictory, or if it is possible that none of the states subsequent to a certain state in an office task may be valid because all the transition conditions are violated. These checks considerably help to avoid an incorrect modelling of the knowledge.
Figure 3 shows the architecture of EULE2. Each subcomponent of the underlying knowledge base system is dedicated to one of the three kinds of knowledge covered by EULE2 as mentioned above. The component “office tasks” knows the description of all office tasks in terms of a transition graph with conditions attached to the transition links that lead from one state to a possible subsequent state. This component also comprises the instantiations of the currently active office tasks. The “terminology and objects“ component contains all concept definitions and their instances. It employs a terminological logic. The “law and regulations” component comprises the description of relevant sections of law and of the company regulations. Since a law introduces either an obligation or a right and says when it holds we represent law by firstorder deduction rules that will deduce an obligation or right (as a new instance of the concept ‘obligation’, resp. ‘right’) whenever this can be done in the course of performing an office task (i.e., when the required data is available). The conditions for the state transitions in an office task are first-order formulas, too. They only refer to the existence of a certain right or obligation instance but do not know under which conditions they hold. In this way, we decouple knowledge about law as much as possible from knowledge about office tasks.
Regulations either define obligations and rights, too, or make explicit statements under which conditions a certain activity in an office task is permitted or forbidden. In the latter case they could formally be represented directly as part of the transition conditions in the office task component. However, to avoid mixing up of different kinds of knowledge and to keep the knowledge base modular they are represented in the law and regulations component, too. In the transition conditions a reference is made to the relevant regulations. A more detailed description of how EULE2 works can be found in Reimer et al. 98. office clerk
dialog environment
results
requests/changes
EULE2 EULE2 controller
provides
provides
changes
provides
knowledge base system
office tasks
checking transition conditions
provides
terminology
provides
objects
law + regulations deducing rights, obligations
instantiation changes
Figure 3. Architecture of EULE2 4. EULE2 and Knowledge Management Knowledge Provision and Knowledge Maintenance In guiding the user through an office task EULE2 supplies him with exactly that knowledge that he needs at a certain moment, namely what to do next and why (the latter only if he is interested to know). Thus, EULE2 is an example of a just-in-time knowledge provision system as discussed since recently in the literature (also referred to as an “electronic performance support system” – cf. Cole et al 97). Moreover, since EULE2 is a system that provides people with knowledge they need and ensures that every user always gets up-to-date knowledge EULE2 is also to be considered a knowledge management system that captures an important part of the organizational memory. Two main issues arise: • An adequate support for maintaining the knowledge in EULE2 is mandatory for its practical usability. Our
own experience with representing the knowledge needed for an office task showed that it is even for knowledge engineering experts quite difficult to get the knowledge correctly represented. Since the people who will be responsible for maintaining the EULE2 knowledge base should not need to be knowledge engineering specialists (and ideally not even computer scientists) we need a knowledge engineering tool for EULE2 that relieves its user from having to know the formal representation formalisms used inside EULE2 as much as this is possible. To this end, a high-level knowledge representation language is being developed that is especially tailored to represent the kinds of knowledge needed for EULE2 (Reimer 98). In terms of the representational levels introduced in Brachman 79 the high level language is on the conceptual level while the internal formalisms are on the logical level (except the terminological logic). Thus, the representation constructs the language offers already introduce certain fundamental concepts, like obligations, rights, regulations, and actions. The move from the logical level of the EULE2 representation formalisms to the conceptual level of the high-level language introduces a representation ontology (like the Frame Ontology in Gruber 92 – not to be confused with a domain ontology). Knowledge represented in the high-level language is automatically compiled down into the internal representation formalisms. • The knowledge of EULE2 needs to be integrated with the knowledge of other systems that has to go into an organizational memory, too. One of the situations where this problem arises is the required coexistence of EULE2 with a future workflow management system whose knowledge is partly complementary with the knowledge in EULE2 and partly overlapping it. We discuss this issue in more detail in the following. Integrating Knowledge for Organizational Memories As already mentioned, EULE2 is in some sense similar to a workflow management system. However, a close analysis reveals that, in fact, EULE2 is rather complementary to a workflow system. The Workflow Management Coalition defines a workflow system as “A system that defines, creates and manages the execution of workflows through the use of software, running on one or more workflow engines, which is able to interpret the process definition, interact with workflow participants and, where required, invoke the use of IT tools and applications.”2 Thus, a workflow system coordinates tasks where more than one person is involved. It knows which subtasks must be performed by which (kind of) people and manages the 2
http://www.aiai.ed.ac.uk/project/wfmc/DOCS/glossary/glossary.html
flow of control between people, possibly accompanied by a flow of documents. EULE2, in contrast, has a more local view and supports one office worker only, this however at a degree of detail which by far surpasses the abilities of existing workflow systems. This is possible because EULE2 has much more knowledge about the office tasks, about the relevant law, and about company regulations. Consequently, a future version of EULE2 will be coupled with a workflow system such that EULE2 possesses all the knowledge needed to decide what must be done next in an office task while all the remaining functionality (like the GUI, controlling the workflow, tracking, etc.) will be provided by the workflow system. Most of the knowledge resides with EULE2, but also the workflow system has knowledge. For example, the concepts it knows must include those that EULE2 knows about. Additionally, the office task graph of EULE2 is part of the workflow description, however without the transition conditions which are only known by EULE2. Actually, we encounter a situation where certain knowledge is in the knowledge base of EULE2 as well as in the knowledge base of the workflow system. A coupling must be designed in such a way that this knowledge becomes integrated. Particularly, • redundancies must either be avoided or automatically been taken care of, • the knowledge must be accessible by other systems (including users querying it) as if being part of only one knowledge base, • different views must be supported, e.g., in the case that the workflow system knows the same concept as EULE2 but has additional attributes associated with it (and vice versa). Since EULE2 as well as a workflow system employ knowledge that is of crucial value to the adequate functioning of an organization it is quite probable that (part of) this knowledge is also of relevance to further (maybe future) information systems. This leads to the general problem of integrating knowledge from several information systems. Capturing and integrating all this knowledge is to be seen as a main activity in building an (electronic) organizational memory (van Heijst et al. 96; Abecker et al. 97). The issues arising with integrating knowledge from different information systems for the purpose of creating a new (or extending an already existing) organizational memory are discussed in more detail in Reimer 98. 5. Conclusions and Outlook We have outlined the functionality and architecture of EULE2, a knowledge-based system that supports an office worker in performing office tasks in compliance with law and company regulations. EULE2 is designed as a tool the user directly works with, instead of being an additional,
advice giving system. By always giving the user exactly that knowledge currently needed EULE2 realizes a just-intime knowledge delivery system. EULE2 has several impacts on issues of knowledge management. We have shortly discussed the problem of knowledge maintenance, and have addressed the problem of integrating the knowledge in EULE2 with the knowledge of other information systems in order to create an organizational memory. A research prototype of EULE2 is completed and has been presented to potential users for evaluation. We are now in the phase of developing the next version, which is intended to become deployed. References Abecker, A., A. Bernardi, K. Hinkelmann, O. Kühn, and M. Sintek (1997): Towards a Well-Founded Technology for Organizational Memories. In Artificial Intelligence in Knowledge Management. Papers from the 1997 AAAI Spring Symposium. ed. B.R. Gaines, and R. Uthurusamy. Menlo Park: AAAI Press. http://ksi.cpsc.ucalgary.ca:80/AIKM97/AIKM97Proc.html
Brachman, R. (1979): On the Epistemological Status of Semantic Networks. In: Associative Networks, ed. N.V. Findler. Academic Press, pp.3-50. Cole, K., O. Fischer, and P. Saltzman (1997): Just-inTime Knowledge Delivery. Communications of the ACM, vol.40, no.7, pp.49-53. Gruber, T.R. (1992): A Translation Approach to Portable Ontology Specifications. Knowledge Acquisition, vol.5, pp.199-220. Reimer, U. (1998): Knowledge Integration for Building Organizational Memories. Technical Report, Swiss Life, Information Systems Research Group, 1998. Reimer, U., A. Margelisch, and B. Novotny (1998): Making Knowledge-Based Systems more Manageable: A Hybrid Integration Approach to Knowledge About Actions and Their Legality. In Dynamic Worlds: From the Frame Problem to Knowledge Management, ed. B. Fronhöfer, and R. Pareschi. Kluwer. (to be published) van Heijst, G., R. van der Spek, and E. Kruizinga (1996): Organizing Corporate Memories. In 10th Banff Workshop on Knowledge Acquisition for Knowledge-Based Systems, 1996. http://ksi.cpsc.ucalgary.ca/KAW/KAW96/KAW96Proc.html
