Using Cases for Process Modelling: An Example from the Water Supply Industry
Guy Saward University of Hertfordshire College Lane, Hatfield, Herts AL10 9AB, UK e-mail
[email protected]
Abstract. This paper describes the use of cases as a process representation technique and shows how case base reasoning can be used to navigate through, or execute a complex control process. The work is based on a prototype decision support application for a UK water utility company in which two processes were modelled - one diagnostic and one operational. A brief description is given of how processes are represented as cases and how those cases are are used to animate the business process.
1 Introduction Case base reasoning is traditionally seen as a problem solving technique to be applied where an effective model cannot be created [1,2]. A prototype decision support application for a UK water utility company, provisionally titled Cascade (Cbr ASsisted Customer ADvicE), demonstrates how an existing process model can be captured as cases. Each path through the process model can be viewed as a script comprising a series of questions and actions, as described in section 4, which is akin to a procedural schemata [3]. The system iteratively matches a given process scenario against the set of all possible scripts, resulting both in the selection of the appropriate script and the incremental execution of the script as described in section 5. Cascade differs from traditional CBR where the search process is driven by the data and is either programmed as part of a matching algorithm, or is generated from the data. Nearest neighbourhood algorithms are an example of the former where a (partial or complete) set of attribute values is matched, using a static algorithm, against existing attribute value sets. Inductive techniques such as ID3 are an example of the latter where the resulting decision tree matching process is focussed on partitioning the cases for fast retrieval. In Cascade, a process model is used to generate the data for the cases. The resulting cases can be viewed as generic or model cases, as opposed to the concrete, or instance cases created from experimental, observed or theoretical data. Although the engineering of model cases is not a new concept [4], the concept of engineering a matching process is new and is akin to the knowledge engineering employed in traditional rule or model based systems [5].
2 Significance Separating the decision making process or business logic from a complex system implementation is critical for a number of reasons. For any utility market in the UK (water, gas or electricity), consistency of execution and application of regulatory principles provide strong evidence of compliance with industry regulations. The separation of application and business process also allows business processes to be altered without changing the system implementation. The engineering of generic process cases retains the utility of cases as episodic knowledge which is one of the key benefits of CBR [6,1]. It has also been argued that cases are a good starting point for heuristic model building [7]. The Cascade application supports this and allows the argument to be taken one stage further by suggesting that cases are a better representation than rules. This is based on the view that cases do not force an unnatural decompilation of knowledge into rule sets. Cases provide a “vertical”, end-to-end view of the problem solving process incontrast to rule sets that typically implement horizontal slices through an inference model. The need for knowledge engineering raises the spectre of the Knowledge acquisition bottle-neck. However, the prevalence of process modelling techniques in industry means that the knowledge engineering can be limited to facilitating and validating the construction of process models. The simple translation of process models into implemented cases should also reduce the requirement for knowledge engineering per se.
3 Process Overview Two processes were mapped as part of the Cascade prototype: a diagnostic process concerned with water quality and an operational process related to billing. Existing flow charts were used to facilitate the construction of more detailed process models. The process models include additional steps that were used to drive the end user GUI. The knowledge for the processes was elicited in four 2 hour workshops and validated in a further two workshops. Table 1. Process Summary Statistics
Process Attributes Sub-processes Decision points / actions Routes through sub-process Total routes Longest path (steps) Cases Longest case (# of steps)
Process 1 4 37 27 720 32
Process 2 8 110 114 43 million 60
26 8
55 12
Each process was split into a number of sub-processes. Each path through the subprocess was implemented as a case. The cases were created using Inference’s CBR3 Professional Author tool. Rules were used to link the sub-processes given the relatively small size of the problem domain and the project time scales. Meta-cases could have been used to link the sub-processes [8, 9] although this would have involved recursive use of the CBR3 Search Engine. The number of elements in each process is shown in table 1.
4 Representing Processes as Cases Figure 1 shows part of a generic contact screening process derived from an application built for a UK water utility company. A flow chart notation is used as it is easy for business analysts and users to understand. Diamonds represent decision points with the arrows representing potential answers. The rounded boxes represent links to other parts of the process. Confirm subject is change of occupancy
No
Go to Subject Selection
Yes
Is the move within 8 weeks
No
Advise customer to reapply nearer move date
Ok
Go to Close Contact
Yes
Does agent have skills for this process
No
Go to Reroute Contact
Yes
Fig1. Process fragment showing part of the operational procedure for change of occupancy To represent the process fragment in figure 1 as cases, each path through the process model is represented as a single case in which questions become case attributes, and
answers become attribute/value pairs. This results in the four cases shown below in table 2. Table 2. Example cases derived from Figure 1.
Attributes # 1 2 3 4
Decision Point Description Subject confirmed Move in 8 weeks Advise reapply Appropriate skills
Case 1 No
Case Attribute Values Case 2 Case 3 Yes Yes No Yes Ok No
Case 4 Yes Yes Yes
Representing the process as cases could be viewed as slicing the process vertically into inference chains, in contrast to a fine grained rule-based approach which would slice the process up horizontally and focus on individual inferences. In defining each case, only those attributes that have a value are associated with the case as shown by Case 2 in figure 2. This case has been authored using Inference’s CBR3 tool in which attributes are stored as questions and values as answers to the questions.
Fig2. Edited case window showing Case 2 from table 1.
5 Case Base Process Animation The Case-Based Process is animated by an iterative case-base search algorithm. In this way, Case-Based Processes combine the knowledge engineering approaches of rule-based systems with the simple, generic retrieval algorithms of case-base reasoning. The search algorithm used is based on iterative case retrieval using a nearest neighbour algorithm. The value for attribute 1 is determined, either through user intervention or some external system interaction, and all cases are scored and
ranked. The highest scoring case is used to determine the next attribute value. The attribute order, which can be varied on a case by case basis, is used to select the next unfilled attribute. A value is then determined for this attribute, the cases are re-scored and re-ranked and the process repeated. For the cases in table 1, if the subject is confirmed as change of occupancy (attribute 1), cases 2,3 and 4 are equally ranked and the system will determine whether the move is within 8 weeks (attribute 2). If it is (attribute 2 = "Yes"), then the search moves on to determine whether the agent has the skills appropriate to work through this process. The incremental case retrieval for Case-Based Processes (CBP) is analogous to the use of decision trees built on top of case bases [10,11] but differs in that: • the sequence of decision points in decision trees are derived from structure of the data underlying the cases, while cases in CBP are engineered to implement a particular sequence of inferences; • traversing a decision tree leads to specific cases which are the solution, while the process of selecting cases in CBP is actually animating the decision making process - there is no solution to be enacted once a case has been selected; • decision trees are just that – they are limited to tree structures, while CBP allows for network (non-tree) structures. Although knowledge engineering has been applied to CBR [7] the idea of engineering the search or retrieval process rather than the cases themselves represents a change in emphasis. Where a process requires the execution of an action or procedure by an external agent, it is included in the CBP as an attribute or decision point with an appropriately worded title, e.g. “Advise customer to reapply nearer move date”. The possible responses to this direction depend on the possible outcomes to the CBP invoked action.
6 Conclusions The figures from table 1 illustrate how a relative small number of cases can be used to model complex processes. . The technique described is applicable to a wide range of industries. This case study, along with research based on another 2 studies is the basis of on-going research investigating the use of cases as a representation technique. This compares the use of cases with other techniques such as rule-based systems and looks at the issues of process decomposition. Other results focus on the use of cases as a single technique for integrating model-based reasoning and experiential data.
References 1. Kolodner, J., Case-Based Reasoning, Morgan Kaufmann, 1993 2. Watson, I., Applying Case-Based Reasoning: Techniques for Enterprise Systems, Morgan Kaufmann, 1997
3. Turner, R.M., Adaptive Reasoning for Real World Problems: A Schema-Based Approach, Lawrence Erlbaum, 1994 4. Bartsch-Sporl, B., Towards the Integration of Case-Based, Schema-Based and Model-Based Reasoning for Supporting Complex Design Tasks, Proceedings ICCBR-95, Springer, 1995 5. Wielinga, B.J., Schreiber, A. T., Breuker, J.A., KADS: A Modelling Approach to Knowledge Engineering, Knowledge Acquisition, 4, 1992 6. Simoudis, E., Using Case-Based Reasoning for Customer Technical Support, IEEE Expert, 7(5) , 1992 7. Strube, G., Enzinger A., Janetzko, D., Knauff, M., Knowledge Engineering from a Cognitive Science Perspective, Proceedings ICCBR-95, Springer, 1995 8. Bergmann, R., Wilke, W., On the Role of Abstraction in Case-Based Reasoning, in Proceedings EWCBR-96, Springer, 1996 9. Saward G., Shankararaman, V., Process Modelling Using Cases, University of Hertfordshire Technical Report 357, in preparation 10. Quinlan, R. 1986. Induction of Decision Trees. Machine Learning 1, 81-106. 11. Quinlan, R., 1993. C4.5: Programs for Machine Learning. San Mateo, CA: Morgan Kaufmann.
