A computational tool that supports formal diagnosis of process design

A computational tool that supports formal diagnosis of process design

Pedro Ramosa,*, Jose Luiz Fiadeirob

aDepartment of Informatics, ISCTE, Av. das ForcËas Armadas, EdifõÂcio ISCTE, 1600 Lisbon, PortugalbDepartment of Informatics, Faculty of Sciences, University of Lisbon, Campo Grande, 1700 Lisbon, Portugal

Received 22 December 1997; received in revised form 11 May 1998; accepted 5 June 1998

Abstract

Computational tools that support process design have been used widely in organisation. These tools usually provide methods and notations

(formal or diagrammatic) that are used to describe and simulate the behaviour of processes, and validate them with the users. The validation

procedure supports mainly syntax validation and consistency analysis against organisation constraints (structure, tasks, documents, etc.). No

further analysis is made with regard to the compliance of a process design with respect to organisational requirements. In this paper we

present a software tool which detects designs that do not accomplish prerequisites supplied by the organisation. The software tool is

supported by formal techniques from arti®cial intelligence and computer science. q 1998 Elsevier Science B.V. All rights reserved.

Keywords: Process design; Diagnosis applications; Software support

1. Introduction

Computational tools that support process design have

been used widely in organisations [1±3]. These tools

usually provide methods and notations (formal or diagram-

matic) that are used to describe and simulate the behaviour

of processes, and validate them with the users. The valida-

tion procedure mainly supports syntax validation and

consistency analysis against organisation constraints (struc-

ture, tasks, documents, etc.). No further analysis is made

with regard to the compliance of a process design with

respect to organisational requirements. As Earl and Khan

[4] state, organisations prescribe rules that should be consid-

ered in the design for structured processes.

In this paper we present a software tool (DDD Ð Deontic

Diagnosis of Process Design) that can be used in a formal

way to analyse the compliance of a process design with

respect to organisation rules (principles) that the organisa-

tion assumes a design must comply with. Using DDD, the

user can detect incorrect and incomplete designs, and be

guided to choose between alternative designs. As an appli-

cation domain, we use control rules for accounting proce-

dures compiled by Chen and Lee [5].

DDD is supported by techniques from arti®cial intelli-

gence and computer science, namely the Theory of Diag-

nosis and Deontic Logic. It is not very common to use

formal techniques in organisational domains. However,

formal approaches provide a solid and rich framework to

describe core concepts and relationships between them.

Formal languages are universal and notably rich and ¯ex-

ible. With them, it is possible to analyse relationships

between concepts and ensure the correctness of the conclu-

sions we draw.

The main contribution of DDD is it shows that a software

tool which supports organisational process aided design can

be easily enriched by using formal languages and theories.

In Section 2, a general description of the framework that

underlies DDD is presented. In Section 3, we present an

example of an Order Delivering Process. This example

will be used throughout most of the paper. In Section 4

we introduce the formal techniques that support DDD

(Theory of Diagnosis and LDD, a formal deontic language).

In Section 5 we present the DDD software and show some

features provided by the software, namely how DDD can

guide the user during design.

2. Framework

The main goal of the software tool (DDD) presented in

this paper is to help the designer make better process designs

by using general rules (principles) that the organisation

assumes a design must comply with. DDD supplies different

features like the detection of incorrect (deviations from the

rules) and incomplete designs, and the capacity to help

the designer deal with alternative choices (namely with

Information and Software Technology 40 (1998) 555±565

INFSOF 3940

0950-5849/98/$19.00 q 1998 Elsevier Science B.V. All rights reserved.

PII: S0950-5849(98)00082-2

* Corresponding author. Tel.: 1 351 1 793 5000; fax: 1 351 1 796

4710; e-mail: [email protected]

con¯icting rules). Fig. 1 shows the structural relation-

ships between the following main components of the global

framework.

² Organisational structure Ð the set of structural concepts

that characterise a speci®c organisation, e.g., agents,

tasks, hierarchies. These concepts are independent of

the processes. They describe the ®xed components over

which the processes ``¯ow''.

² Process description Ð the description of the process

design. The description is made with typical primitives

used in organisational processes, e.g., assign, output_-

to_task.

² General organisational knowledge Ð the de®nitions

(e.g., available, informed) and rules (e.g., if a task is

assigned to a collective agent, the task is assigned to

all the members of the collective agent) common to all

organisations.

² Principles Ð the general rules that characterise the ideal

behaviour of an organisation. Each organisation decides

which rules should be used. Usually the rules that guide

the design are general rules (e.g., no employee can be

assigned to a control task if the decision to control is

assigned to an agent up in the hierarchy). We are inter-

ested in forms of diagnosis of process design that report

violations of such principles.

² Diagnosis Ð the diagnosis procedure that detects viola-

tions of the principles.

As described in Fig. 1, the user must design a process and

specify general principles. The user can also describe the

structure of the organisation and design the process (process

description) using a diagrammatic language. The translation

from the diagrammatic language to a textual formal

language is one step of the diagnosis procedure. We chose

to adopt a declarative formal language because we want to

use formal deduction methods in the diagnosis procedure.

The interaction between the software tool and the user is

crucial. The diagnosis procedure can be executed at any

time during the design. As a result of running the diagnosis

procedure the user is informed of the ``mistakes'' he has

done so far and what is left to do. In the present version of

DDD, the user must supply all the information in a declara-

tive language.

3. Example Ð order delivering process

In order to better understand diagnosis in organisational

process design, we present an example of an Order Deliver-

ing Process. This example is adapted from Chen and Lee

[5]. The same authors have also compiled all the general

accounting rules used in it. This example will be used

throughout the paper.

To avoid frauds in organisational accounting procedures

some control rules are often used. Consider the process

design in Fig. 2.

The process is as follows: the Stock Manager receives an

order (from a salesman, for example), ®lls up an Internal

Delivering Order (Fu_IDO) and sends it to the Warehouse

which has to ®ll up an Outgoing Delivering Order

(Fu_ODO); after ®lling the Outgoing Delivering Order

(ODO) the Warehouse sends it to the Client together with

the goods. After receiving the same order, the Accounting

Department ®lls up the Invoice and stores it in the Invoice

File. With this design, a fraud might occur involving, for

example, the Stock Manager and the Warehouse (they can

retrieve more goods from the warehouse than the amount

considered in the invoice).

The following ®ve rules exemplify some concerns of the

organisation about potential frauds (the rules assume that

there are control tasks that control operational tasks):

Rule 1: ``When a control task exists, it must be furnished

with the supporting documents'';

P. Ramos, J.L. Fiadeiro / Information and Software Technology 40 (1998) 555±565556

Fig. 1. Architecture of the framework.

Fig. 2. Example of an order delivering process that allows fraud.

Rule 2: `Ìf a control task uses a supporting document, the

supporting document should be transferred

directly from the task that produces the

supporting document'';

Rule 3: `À control task and the operating task it intends

to control should be segregated into two different

agents'';

Rule 4: ``The position assigned to a control task cannot

be lower in the formal power hierarchy than the

position of the operating task to be controlled'';

Rule 5: ``The agent in charge of a control task should be

socially detached from the agent responsible for

the corresponding operational task''.

Consider also the following speci®c rule and the organisa-

tion structure presented in Table 1:

Rule 6: `Ònly one employee that works for at least three

years in the organisation can be the Warehouse

Manager''.

In Fig. 3, the same order delivering process is (re)de-

signed in order to ful®l the rules. The process is as follows:

the Stock Manager (John) receives an order, ®lls up an IDO

and sends it to the Stock/Invoice Controller (Phil) assigned

to the task Verify Internal Delivering Order (Ve_IDO); after

receiving the same order the Accounting Department (Ann)

®lls up the Invoice and sends it to the Stock/Invoice Control-

ler; if the values of the two documents are equivalent, the

Stock/Invoice Controller stores the Invoice and sends the

IDO to the Warehouse (David) who has to ®ll up an

Outgoing Delivering Order (Fu_ODO); after ®lling the

Outgoing Delivering Order (ODO) the Warehouse sends it

to the Client together with the goods, and sends a copy of the

ODO to the Stock/Invoice Controller.

The purpose of the task Verify Internal Delivering Order

(Ve_IDO) is to control the task Fill up an Internal Delivery

Order (Fu_IDO), which is done by using the supporting

documents Invoice and IDO. The purpose of the task

Check Delivering Order (Ck_DO) is to control the task

Fu_IDO, which is done by using the supporting documents

copy_ODO and IDO. The role of the Stock/Invoice Control-

ler is to prevent frauds.

As can be easily checked, all the rules are ful®lled. For

example, Rule 4 is ful®lled because Phil is hierarchically

superior to John. Given the previous design (Fig. 3) a diag-

nosis framework should report that there are no violations in

the design.

Scenario 1. Consider now an incomplete attempt to design

an order delivering process where: (1) no one is assigned yet

to Fu_ODO (Warehouse Manager); (2) David is the Stock/

Invoice Controller; (3) instead of sending the invoice to the

Stock/Invoice Controller, Ann stores it in the Invoice File;

and (4) the copy of the ODO is not sent to anyone yet.

Some situations are unambiguous: Rule 4 is ful®lled

because David is hierarchically superior to John; Rule 2 is

violated because the invoice is not transferred directly to the

Stock/Invoice Controller. Other situations require a deeper

analysis:

1. How should a diagnosis report the impossibility to ful®l

simultaneously Rules 3, 5 and 6 in what concerns the

assignment of the task Fu_ODO (notice that given Rule

6 only David and Paul can be assigned, but given Rules 5

and 3 Paul should not be assigned and David should also

not be assigned)? Is the impossibility a consequence of

previous design choices made by the designer, or does it

remain whatever choices are made by the designer?

2. Should a diagnosis report that Rule 5 can also be violated

because the designer has not yet assigned anyone to the

task Fu_ODO (it is possible to assign Paul to the task, but

that will be a violation of the rule because David and Paul

are socially close)? Or should we consider that a diag-

nosis must not report that situation because there is no

violation yet?

3. Should the designer ``prove'' that David and John are not

socially close (in order to ensure that Rule 5 is not

violated)?

P. Ramos, J.L. Fiadeiro / Information and Software Technology 40 (1998) 555±565 557

Table 1

Organisation structure

Agents: John, Ann, Phil, Paul, David

Roles: Stock Manager, Warehouse

Manager, Accounting

Department Manager, Stock/

Invoice Controller

Phil is hierarchically superior to John

David is hierarchically superior to John

David and Paul are socially close

Only David and Paul have worked for more than

three years in the organisation.

Fig. 3. Example of an ideal order delivering process.

In the next section we show how formal approaches to

diagnosis and reasoning can provide a precise way to answer

these questions. In Section 5 we show how DDD supports

those approaches.

4. Formal contributions to the diagnosis of processdesign

It is not common to use formal techniques in organisa-

tional domains. However, formal approaches usually

provide a solid and rich framework to describe the core

concepts and relationships between them. Moreover, when

we want to have a deductive system (i.e., to derive conclu-

sions based on given information, such as the detection of

potential frauds given a process design), it is very important

to be certain about the correctness of the conclusions. Soft-

ware tools are usually the ®nal goal, but they are not expres-

sive enough to provide the kind of analysis described above.

Formal languages (like logic) are universal and notably rich

and ¯exible. With them, it is possible to analyse relation-

ships between concepts and ensure the correctness of the

conclusions we draw. If a software tool implementation is

based on a formal language, like DDD, it is possible to

discuss the approach at a higher level of abstraction, without

having to know the details of the implementation.

4.1. Theory of diagnosis

In the framework proposed by Chen and Lee [5] for the

evaluation of internal accounting control procedures, the

idea of having general rules guiding organisational diagno-

sis is already present. However, this framework is not

supported by a theory of diagnosis. For instance, situations

(1) and (2) described in Section 3 are partially answered by

the theory of diagnosis, and are not answered by Chen and

Lee's framework. In this section we brie¯y introduce the

classical Theory of Diagnosis and show how it can be

extended to be used for the diagnosis of process design.

4.1.1. Model-based reasoning approach to diagnosis

The Model-Based Reasoning (MBR) approach to diagno-

sis has been studied for several years (for a survey of this

topic see [6]). Numerous applications have been built, most

of all for diagnosis of physical devices. The basic paradigm

is the interaction between prediction and observation.

Predictions are expected outputs given the assumption that

all of the components of a system are working properly (i.e.,

are working according to the model of the structure and

behaviour of the system). If a discrepancy between the

output of the system (given a particular input) and the

prediction is found, the diagnosis procedure will search

for malfunctions in the components of the system (the

correction of the model is assumed).

The contribution of Reiter to the theory of diagnosis has

become a standard in the ®eld of diagnosis theory. His

``Consistency-Based Approach'' [7] was the ®rst one to

formalize the MBR approach to diagnosis. The main goal

is to eliminate system inconsistency, identifying the mini-

mal set of abnormal components that is responsible for the

inconsistency. An abnormal component (AB(c)) is a compo-

nent that, given a speci®c input, does not produce the

expected output.

De®nition Ð Reiter Diagnosis. Given a system (SD,

COMP, OBS) where SD is the system description, COMP

is the set of components of the system and OBS are the

observations, a diagnosis is a minimal set D # COMP

such that:

SD < OBS < {AB�c�uc [ D} < { : AB�c�uc[ COMP 2 D} is consistent �1�

In the de®nition, : means not. This de®nition is based on

the Principle of Parsimony, according to which a diagnosis

is a conjecture that some minimal set of components are

faulty (i.e., it is not rational to assume that all components

are damaged if it is possible that only one damaged compo-

nent explains the error).

MBR can also be applied to diagnosis of process design.

The role of symptoms (evidence of malfunctioning) is

crucial in the MBR approach because it guides the diagno-

sis. However, there are situations in which, even if it is not

possible to detect the malfunctioning of a system, a preven-

tive diagnosis is recommended. Process design diagnosis is

one such situation.

In the MBR approach, there is a strong relationship

between the inputs and outputs of a system: the outputs

are the result of component behaviour given the inputs.

Given an expected behaviour of the components, the

outputs can be predicted. In process design diagnosis,

the Organisation Structure is the input of the system.

The System Description corresponds to the Process

Design, together with the General Organisational Knowl-

edge. The components are the parts of the design that are

in the scope of the rules. Rules are used to check for

abnormalities (violations) of the components. Assuming the

ful®lment of the rules, there is nothing to be predicted. This

happens because there is not a real output that can be

observed. Evidence of malfunction appears later when the

process runs in the organisation. However, in order to ensure

that the process design ful®ls the rules, a preventive diagnosis

is needed.

4.1.2. Model-based reasoning approach to diagnosis of

process design

Consider the example presented in Section 3. Given the

organisation structure and the general organisational knowl-

edge, it can be deduced that, in a correct design, the follow-

ing speci®c rules (particular cases of the general rules),

among others, must be followed (task_output_input_task


(Task1, Output1, Task2) means that the output Output1 of

task Task1 goes to task Task2):

R1: :(assign(Fu_IDO, Phil) and assign(Ver_IDO,

John));

R2: task_output_input_task(Fu_Invoice, Invoice,

Fu_IDO);

R3: task_output_input_task(Fu_ODO, Copy_ODO,

Ck_DO).

Given Scenario 1 (Section 3), namely the assignment of

Ve_IDO to David, the designer must ensure that:

R4: : assign(Fu_ODO, David);

R5: : assign(Fu_ODO, Paul).

It is not compatible to assume that the empty set (D1 �{ }) is a diagnosis. If that is assumed, it means that all rules

are ful®lled, namely R2 (task_output_input_task(Fu_In-

voice, Invoice, Fu_IDO)), which is incompatible with

Scenario 1. However, it can be assumed that D2 � {R2} is

a diagnosis. If we consider that an abnormal behaviour of

one role is its negation (AB(R2) � : R2), a diagnosis D2 �{R2} means that there is no inconsistency between the

design and the following assumptions (R1, R3, R4 and R5

ful®lled, R2 not ful®lled):

: (assign(Fu_IDO,Phil) and assign(Ver_IDO, John)):

: (task_output_input_task(Fu_Invoice, Invoice,

Fu_IDO));

task_output_input_task(Fu_ODO, Copy_ODO, Ck_DO);

: assign (Fu_ODO, David);

: assign(Fu_ODO, Paul).

The design does not say that assign(Fu_ODO, Paul) is

false, but it also does not say either that assign(Fu_ODO,

Paul) is true; so, it is possible to assume that there is no

violation of the rule. Any set that contains the violation of

R1 (assign(Fu_IDO,Phil) and assign(Ver_IDO, John))

cannot be a diagnosis because it is inconsistent with the

fact (represented in the design) that : (assign(Fu_IDO,Phil)

and assign(Ver_IDO,John)).

4.1.2.1. Benevolent and exigent diagnosis

Let us consider that in Scenario 1 the designer assigns the

task Verify Internal Delivering Order to Phil (assign(Ver_-

IDO, Phil)), instead of assigning it to David. As a

consequence of general Rule 4 (Section 3), Paul should

not be assigned to the task Fill up Outgoing Delivering

Order ( : assign(Paul, Fu_ODO)). Since the designer has

not yet assigned anyone to the task Fu_ODO, there is not a

violation yet, but the violation can occur if Paul is assigned

to that task.

In spite of not knowing anything about the ful®lment of

that rule, an MBR approach based on the Parsimony Prin-

ciple `àccepts'' that situation (that is, a diagnosis will not

report that rule). That happens because there is no evidence

of the violation of the rule. The Parsimony Principle follows

the rule `ìnnocent until proven guilty''.

If it is really important that the task is not assigned to

Paul, a design which does not commit it with respect to that

assignment must be avoided. Indeed, if the rule is not

enforced, it is possible that, during the implementation of

the process in the organisation, the task is assigned to Paul.

To avoid this undesired situation, the diagnosis should alert

to the `ìncompleteness'' of the design. When it is important

to ensure that all rules are ful®lled, and not only detect

violation of the rules, the Parsimony Principle is much too

benevolent (it is like the assumption of the ful®lment of

rules in the absence of information). In that case, an approach

based only on minimal diagnosis is not adequate and an

exigent diagnosis (where unful®lled rules are detected, i.e.,

``guilty until proven innocent'') is more suitable.

To deal with the notions of benevolent and exigent diag-

noses, we do not consider the Parsimony Principle to be a

built-in feature of diagnosis, but an extra logical principle

that can be applied or not. We choose to have a more general

and independent diagnosis de®nition (Potential Diagnosis)

over which principles, like the Parsimony Principle, can be

applied.

Underlying the notion of exigent diagnosis we are consid-

ering a different principle (opposite to the Principle of Parsi-

mony): a diagnosis is a conjecture that a maximal set of

rules can be violated. In order to capture the notion of

exigent diagnosis, a computation of maximal sets is

required. In the Fig. 4 we illustrate the kind of useful infor-

mation that can be presented during the design.

Consider the six following speci®c rules and Scenario 1:

R1: assign(Fu_ODO,Paul) or

assign(Fu_ODO,David);


R3: : assign(Fu_ODO, Paul);

R4: task_output_input_task(Fu_Invoice, Invoice,

Fu_IDO);

R5: : (assign(Fu_IDO,Phil) and

assign(Ver_IDO,John));

R6: task_output_input_task(Fu_ODO, Copy_ODO,

Ck_DO).

Each set in the tree represents one consistent set of

violated rules. Vi means violation of rule Ri (for example,

{V2,V4} means that it is consistent to assume the violations


Fig. 4. Consistent violation sets.

assign(Fu_ODO, David) and : task_output_input_task

(Fu_Invoice, Invoice, Fu_IDO), and the ful®lment of rules

R1, R3, R5 and R6). All consistent sets of violated rules are

considered in the ®gure. The sets are ordered by set inclu-

sion.

The three minimal sets are the only three diagnoses

according to Eq. (1). In order to capture the so-called

Exigent Diagnosis, maximal sets are required. Indeed the

sets {V2,V3,V4,V6} and {V1,V4,V6} must be understood as

the ``work to be done''; that is, all the rules that are not yet

ful®lled, but ought to be. Given the two exigent diagnoses,

the user knows that it must ful®l rules 4 and 6, and must also

ful®l rules 2 and 3 or, alternatively, rule 1 (notice that it is

not possible to violate simultaneously rules 1, 2 and 3; that

is the reason for having two exigent diagnoses). Notice that

rule 5 (already ful®lled) does not appear in any set, and rule

6 (not violated or ful®lled yet) does not appear in minimal

sets).

Given the entire diagram, the designer has a clear picture

of what should be done and what ``mistakes'' have been

done so far. If we do not consider the possibility to change

previous design decisions, and assuming that the rules does

not change, the designer knows that, whatever is done, any

diagnosis will always be in the original diagram.

All consistent sets of violations (all sets of the tree) are

Potential Diagnoses, minimal sets are Benevolent Diag-

noses and maximal sets are Exigent Diagnoses. Formally,

De®nition Ð Potential Diagnosis. Given a system (ORG,

PD, RL) where ORG is the organisation structure and general

organisation knowledge, PD is the process design and RL are

the rules, D is a potential diagnosis iff D # RL and:

ORG < PD < { : �r�ur [ D} < {rur

[ RL 2 D} is consistent �2�Considering POT, the set of all potential diagnoses:

De®nition Ð Benevolent Diagnosis.

D is a benevolent diagnosis iff D

[ POT and D is minimal in POT �3�De®nition Ð Exigent Diagnosis.

D is an exigent diagnosis iff D

[ POT and D is maximal in POT �4�

4.1.2.2. Implicit and explicit violations and con¯icting rules

In question (i) (Section 3) we said that a diagnosis should

report the impossibility to ful®l simultaneously several

rules. Consider the four following speci®c rules and

Scenario 1:

R1: assign(Fu_ODO, Paul) or assign(Fu_ODO,

David);


R3: : assign(Fu_ODO, Paul);

R4: task_output_input_task(Fu_Invoice,Invoice,

Fu_IDO).

It is impossible to ful®l simultaneously R1, R2 and R3

(R4 is already violated). Indeed, Section 2 gives us three

alternative diagnoses: D1 � {R1,R4}; D2 � {R2,R4}; D3 �{R3,R4}. In every diagnosis R4 is violated, and there is no

diagnosis where R1, R2 and R3 are simultaneously ful®lled

(i.e., D4 � {R4} is not a diagnosis). The set {R1,R2,R3} is

called an Implicit Violation Set. Formally, we have,

De®nition Ð Implicit Violation Set.

IVDi is an Implicit Violation Set iff IVDi is a minimal set

such that

IVDi # RL and ORG < PD < {rur [ IVDi} is inconsistent

�5�Informally, it is not possible to ful®l all the rules related

with the violations in IVDi (at least one violation will occur).

This de®nition corresponds to Reiter's de®nition of Con¯ict

Set.

For a particular process description it is possible to have

several violation sets. We call Vk an Implicit Violation iff

there exists one IVDi such that Vi [ IVDi.

De®nition Ð Explicit Violation.

Vk is an Explicit Violation iff {Vk} is an implicit

violation set�6�

Informally, if Vk is an explicit violation then the rule

related with Vk is always violated unless the designer

changes the design (R4 is explicit violated).

As mentioned in question (i) (Section 3), it is not suf®-

cient to alert the designer that it is impossible to ful®l simul-

taneously R1, R2 and R3 (i.e., deduce that {R1,R2,R3} is an

implicit violation set). It is important to know if that impos-

sibility is a consequence of previous design choices made by

the designer or the impossibility remains whatever the

designer does (i.e., it results from a con¯ict between the

rules).

A con¯ict between rules occurs when, whatever options

the designer takes, it is impossible to ful®l these rules

together (in the example there are not con¯icting rules; in

Fig. 3 all rules are ful®lled).


Fig. 5. Potential diagnoses after ful®lling rules R1 and R2.

De®nition Ð Con¯icting Rules.

CODi is a Conflicting Rule Set iff CODi is a minimal set

such that CODi # RL and ORG < {rur

[ CODi} is inconsistent

�7�

Notice that all con¯icting rule sets are implicit violation

sets. The only difference between the de®nitions of Eqs. (5)

and (7) is that in Eq. (7) we leave out the process design (the

rules are inconsistent with the organisation, whatever the

design).

In the example related to the potential diagnoses diagram

presented in Fig. 4, we have two implicit violation sets:

{V1,V2,V3} and {V4}, and no con¯ict set. If the designer

chooses to assign Paul to the task Fu_ODO (ful®l rules 1

and 2, violating rule 3), the potential diagnosis diagram will

be as presented in Fig. 5.

In this section we presented how the Theory of Diagnosis

can be extended in order to deal with questions (i) and (ii)

(Eq. (3)). More detailed information is available in [8].

Question (iii) raises a different problem. As will become

clear in the next section, that question is related with the

representation and interpretation of the rules.

4.2. Formal logic

As mentioned at the beginning of Section 4.1, we want to

use formal deduction within the diagnosis procedure.

Formal logic is a rich and ¯exible language, suitable to

represent and analyse relationships between concepts, and

to infer correct conclusions.

It is not our purpose to present a full description of the

logic we developed (LDD, language for deontic diagnosis)

for the diagnosis of process design [9, 10]. However, a brief

description is required in order highlight some characteris-

tics of the software we have built.

Deontic Logic (DL) is based on the concept of obligation.

The notion of obligation can be used to explicitly represent

ideal situations. For example, when we say that a designer

must ensure that assign(Fu_ODO, David) is false, we are

saying that, in order to ensure that an ideal design is made,

the designer is `òbliged'' to make assign(Fu_ODO, David)

false. In DL obligations are represented with the O operator.

The situation above is modelled by the sentence

O(: assign(Fu_ODO, David)). With this operator, ideal

and actual situations can coexist, even when ideal situations

do not occur. For example, it is possible to have simulta-

neously O(: assign(Fu_ODO, David)) and assign(-

Fu_ODO, David). When such a situation occurs we say

that the obligation is violated.

DL has been applied to several domains, for example: an

agent's responsibility within organisations [11], con®denti-

ality in databases [12] and security in computer systems

[13]. Here we show how deontic logic can be easily used

in aided process design.

4.2.1. Conditional obligations

Most of the rules that guide the design of a process are

better represented in a conditioned way (for example, `Ìf

one person is lower in the formal power hierarchy than

another person [condition] then the ®rst one cannot control

the second one''). We consider that a conditional obligation

has two components: the design action that indicates what

the designer should do, and the context (condition) that

describes the situation in which the design action should

be done. That distinction is crucial in our approach.

Conditional obligations are represented with Von

Wright's dyadic operator O[_/_] [14]. The obligation O[p/

q] should be read as `ìf the context q is the case, there is an

obligation to perform the action p''. The sentence

O[: assign(Fu_ODO, Paul)/assign(Ck_DO, David)] is an

example of a conditional obligation.

4.2.2. Structural and design concepts

In our approach to process design in organisations, two

types of concept are considered: Structural and Design

concepts. Structural concepts represent the organisation

structure, i.e., what is ®xed in the organisation and cannot

be changed as a consequence of a process (re)design. For

example: ability, existing tasks, kinds of tasks, employees.

Design concepts are those that can be manipulated by the

person that designs the process. They can be understood as

``design actions''. For example: assign tasks to agents,

redirect outputs.

We assume that it makes no sense to have obligations

according to which a process designer has to act over the

structure of the organisation. It follows from that assump-

tion that, whatever the context might be, any obligation

where the action is represented by a structural concept is

not a valid one. For example, the rule if the task Approve

Budget is assigned to John, John must be the Head of

Department (HD) can only be valid if it is interpreted as a

restriction upon the action of assigning task Approve Budget

to John, and not as an obligation to decide that John is the

Head of Department if the task is assigned to John (being

the Head of Department is a structural concept).

4.2.3. Detachment

In what concerns the detachment of the condition in a

conditional obligation (infer the obligation on the design

action when the condition is true), we follow the approach

of Carmo and Jones [15]. In their approach, the condition

can only be detached if (among other restrictions) it repre-

sents a ®xed situation.

In our approach, ®xed situations correspond to structural

characteristics of an organisation. Indeed, when the condi-

tion of an obligation is a structural concept and the condition

holds, the detachment can be made. For example, consider

the rule: if John is the HD he should be assigned to the task


Approve Budget. If John is the HD, whatever the designer

does, John will always be the HD and the designer should

assign him the task Approve Budget. Notice that design

decisions are not ®xed. All that is designed can be undone

until the design has not ended.

4.2.4. Conditioned obligations is an exigent diagnosis

As mentioned in Section 4.1.2.1, an exigent diagnosis

does not only detect violations of obligations, but also

reports obligations that are not yet ful®lled. Given the de®-

nition of exigent diagnosis (Eq. (4)), it is consistent to

assume that a conditional obligation can be violated (i.e.,

be a member of an exigent diagnosis), even if the condition

and the action are unknown (it is not possible to infer if they

are true or false). However, in our view, a diagnosis should

not report all conditional obligations that can be violated.

The next two examples illustrate the kind of conditional

obligations that should be considered in an exigent diagno-

sis. The second example answers the question (iii) we posed

in Section 3.

Consider again the following rule: if the task Approve

Budget is assigned to the HD, the HD can not be assigned

to the task Prepare Budget. If, in the design, the tasks

Approve Budget and Prepare Budget are not assigned to

anyone yet, we do not consider that an exigent diagnosis

should report the unful®lment of that obligation (it would be

an extremely exigent diagnosis). However, if the task

Prepare Budget is assigned to the HD, we believe that,

even if the designer has not made any commitment with

respect to the task Approve Budget, an exigent diagnosis

should report that situation (i.e., from the design it should be

deduced that the condition does not hold).

However, it is not always the case that a decision not to

execute an action (when the truth value of the condition is

unknown) should be reported in an exigent diagnosis.

Consider the following rule: if John is assigned to the task

Prepare Budget and he is socially close to Ann, Ann can not

be assigned to the task Approve Budget. Suppose the

designer assigned Ann to the task Approve Budget and

John to the task Prepare Budget. Consider also that we do

not know if Ann and John are socially close, and that

``socially close'' is a structural concept (it is ``®xed''). If

that situation is reported in an exigent diagnosis it means

that the designer should assume that Ann and John are not

socially close. However, as it was said before, since the

designer should not act in the organisation structure, he

cannot be obliged to enforce anything on the social lives

of Ann and John.

A conditional obligation should only be considered in an

exigent diagnosis if: (1) the condition is true or (2) the action

is not performed and the condition is not ®xed. From now

on, all obligations that can be considered in a diagnosis

(exigent or not) will be called Applicable Obligations.

4.2.5. Con¯icting obligations

In Section 4.1.2.2 we mentioned that the framework

should help the designer to make decisions when there are

implicit violation sets or con¯icting sets. In those situations,

the designer must choose between the ful®lment of one

obligation and the ful®lment of other obligation(s). Casta-

nÄeda's proposal [16] for handling con¯icting obligations

seems to be suitable for our approach. The general idea is

to accept con¯icts and have a supra-normative system that

tells which obligation prevails whenever a con¯ict is

detected. Considering the amount of obligations that can

rule a design, it is preferable to allow the organisation to

express the preferences in terms of sets of obligations. For

this purpose, grouping obligations in different normative

systems seems to be a suitable approach. The organisation

should de®ne criteria for grouping the obligations (for

example, by department). Since con¯icts can occur in real

situations, the language must allow con¯icts between

normative systems.

The obligation Oi[p/q] should be read as `ìf the context q

is the case, there is an obligation to perform the action p,

given the normative system i''.


Fig. 6. Aliases and implicit violation sets.

5. DDD software tool

The software tool is implemented in LPA Win Prolog.

Prolog (Programming in Logic) is a declarative powerful

computational language, appropriate to develop applica-

tions based on logic. We have not yet implemented the

graphic interface for the design of processes. In this version,

the components described in Fig. 1 (process description,

organisation structure, the rules and the general organisa-

tional knowledge) must be supplied through logical propo-

sitions.

Our purpose is to describe the functionality of DDD.

Regarding the implementation of the framework, we choose

the following main options. All the consistency checks are

made with Semantic Tableaux [17]. LDD is not fully imple-

mented. The inference procedure is guided in order to obtain

only the applicable obligation (in logical terms, we do not

have a complete system). Con¯icting obligations are

allowed and detected, but, in DDD, we assume that the

data supplied by the user are consistent (except, as presented

later, if the user updates the design using the DDD menus).

In this section we use again the previous example


Fig. 7. Potential diagnoses diagram.

Fig. 8. Potential diagnoses diagram.

(Scenario 1 and Fig. 4). The data are supplied into DDD as

presented in Table 2. To avoid a large number of formulas,

we just present in Table 2 a subset of it. In order to obtain the

subset of Table 1, another set of formulas has been intro-

duced. For example, org(assign(fu_ido), john) limp (neg

assign(fu_ido))) is a consequence of a more general rule

that stands that just one person can be assigned to the task

fu_ido.

The predicate ctrl_task associates one task with the corre-

sponding task that controls it (e.g., ctrl_task(chk_do,-

fu_odo) means that the task chk_do controls the task

fu_odo). The predicate hier_sup(phil,john) means that phil

is hierarchically superior than john. The predicate soc_clo-

se(paul,david) means that paul is socially close to david. We

use the symbols `ànd'', `òr'', ``neg'' and ``limp'' for the

usual logical operators: conjunction, disjunction, negation

and material implication. The ®rst argument of the O opera-

tor (an integer) is related with the sets of obligations that are

grouped together (Section 4.2) and used to help the designer

choose between con¯icting rules (we come back to this

subject at the end of this section).

Given that information, DDD computes all the applicable

obligations. For to clarity and because of space limitation on

screen, DDD assigns aliases to the obligations. In Fig. 6 we

can see the applicable obligations (and the corresponding

aliases) generated by DDD. The word true in the context

component of the obligation means an unconditional obli-

gation.

In Fig. 7 we present the potential diagnoses diagram

generated by DDD. The user can expand or reduce the

diagram in order to have better perception of bigger

diagrams. The numbers in the left top of each diagnosis

(box) are also related with con¯icting rules and are

explained at the end of the section. In Fig. 6 we can see

the two implicit violation sets: {V1} and {V2,V3,V4}.

The user can click the mouse in any diagnosis in order to

obtain more detailed information (the corresponding obliga-

tions and information about the state of the obligations:

Violated, Ful®l or Not Ful®l). The same information can

be obtained with the menus, as exempli®ed in Fig. 7. Asso-

ciated with the alias V2, we have the Not Ful®l (neither

ful®lled neither violated) obligation O(assign(fu_odo,paul)

or assign(fu_odo,david)/true). The last entries in the menu,

for each component (context and action design), decompose

the members of the obligation: for each argument of a

conjunction there is a submenu with the arguments of the

disjunction. In the example, there is no context (it is an

unconditional obligation) and no conjunction. The question

mark on the right of each formula indicates that the user has

not committed him/herself yet about the ful®lment or viola-

tion of the formula (equivalent to Not Ful®l). For each argu-

ment of the disjunction (assign(fu_odo,david),

assign(fu_odo,paul)) there is a submenu in which the user

can decide what to do (update the design): Ful®l the formula

(assigning the task to paul), Violate the formula (explicitly

determine that the task is not assigned to paul) or delay the

decision (Not Ful®l). DDD only allows consistent decisions.

For example, the user cannot ful®l V1, V2 and V3.

At any moment the user can redesign the diagram. In Fig.

8 we present the diagram resulting from the assignment of

paul to the task fu_odo. Notice that, given the previous

decision, obligation O(assign(fu_odo,paul) or assign(fu_o-

do,david)/true) becomes ful®lled and does not appear as an

applicable obligation. Notice that one possible way to ful®l

the conditional obligation presented in Fig. 8 (V4) is to

choose Violate in the condition (assign(chk_do,david)).

5.1. Con¯icting rules

In Section 4.1.2.2 it was mentioned that in the presence of

an implicit violation set (IVDi), the designer knows that it is

not possible to ful®l all the obligations related with the

violations in IVDi (at least one violation will occur). In

Section 4.2 we mentioned that the organisation should

group the obligations in sets (normative systems) and

express the preferences in terms of those sets. For example,

in Table 2, the organisation considers that the fourth and

sixth obligations are grouped together in the same normative

system (the ®rst argument of the obligation Ð 2 Ð is the

identi®cation of the normative system).

The general idea is to have a supra-normative system (we

call it normative system 0) that tells which obligation

prevails whenever a con¯ict between normative systems is

detected. The representation of the supra-normative system

0 (NS0) that is proposed is a very simple one: the organisa-

tion uses rules that explicitly tell which normative system

prevails when there is a con¯ict between two normative

systems. The result of these rules will be the NS0. The

obligations of NS0 are not deduced in the LDD language.

NS0 obligations are additional formulas added by a diag-

nosis procedure that uses the NS0 organisational rules.

Those obligations are only relevant in a diagnosis context.

The schema of the rules is the following one (the meaning

is that normative system i prevails upon normative system j,

assuming that i ± j)1:

De®nition Ð NS0 Rule.

�Viol�a=b�i [ IVDk ^ Viol�a 0=b 0�j [ IVDk� ! O0�a=b�

In order to help the designer to choose between ``paths''

in a potential diagnoses diagram, it is suf®cient to order the

potential diagnoses. Potential diagnoses can be ordered with

the following rules: (1) a potential diagnosis is to be referred

upon another one if it has less (or the same amount) viola-

tions of ``normal obligations'' (obligations that are not part

of the normative system 0); (2) if two potential diagnoses

have the same number of violations of ``normal obliga-

tions'', the preferred diagnosis is the one that has less viola-

tions of obligations of the normative system 0. It is possible


1 In DDD it is only necessary to write the predicate prefer(6,3) to express

that normative system 2 prevails upon normative system 3.

to have other ordering criteria. Nevertheless, we assume that

the number of violations is more important than the number

of ``wrong'' choices when there are con¯icting obligations.

Formally,

De®nition Ð Preference Relation. pdi s pdj (potential

diagnosis i is preferred over potential diagnosis j) iff

(symbol # means a function count):

#{Viol�a=b�k.0 : Viol�a=b�k [ pdi} # #{Viol�a=b�k.0

: Viol�a=b�k [ pdj}

#{Viol�a=b�k�0 : Viol�a=b�k [ pdi} # #{Viol�a=b�k�0

: Viol�a=b�k [ pdj}

�8�

In the example of Fig. 6, DDD only considers the prefer-

ence relation prefer(6,3); i.e., if the designer has to choose,

he must ful®l obligations of NS2 system 2 and accept viola-

tions of NS3 obligations. The numbers in the left top of each

diagnosis (box) represents the preference order: diagnosis

{V1,V4} is preferred upon diagnosis {V1,V2}. As a conse-

quence of that preference relation, in the actual state of the

design (Fig. 6), the designer must consider that the ``work to

be done'' is represented by the set {V1,V3,V4,V5} and not

{V1,V2,V5} (it is the only ``path'' that does not ended in

{V1,V2}).

6. Conclusions

A software tool (DDD) was presented which supports the

formal analysis of compliance between process designs and

organisation rules. DDD is supported by formal techniques

from arti®cial intelligence and computer science, namely by

an extension of the Theory of Diagnosis with the notion of

exigent diagnosis. DDD is also based on a deontic language

LDD and corresponding inference mechanism which allow

us to deal with ideal and actual (not necessary ideal) situa-

tions. The resulting formal approach supports a highly

enriched analysis of a process design. This approach was

illustrated with control rules for accounting procedures.

DDD is still a specialised software tool and requires the

support of an expert user. However, a ¯exible and easy

interaction between the software tool and the user is crucial

to make it usable. In future versions we intend to supply a

diagrammatic language for the design of processes.

Acknowledgements

This work was partially supported by the Esprit WG 8319

(ModelAge), contracts PSCH/OGE/1038/95 and UNIDE/

ISCTE.

References

[1] G. Lyons, Application of information technology in the redesign and

implementation of business processes, in: Proceedings of the IFIP

TC5/WG5.7 Working Conference on Re-engineering the Enterprise,

Galway, Ireland, 1995.

[2] G. Abeysinghe, K. Phalp, Combining process modelling methods,

Information and Software Technology 39 (1997) 107±124.

[3] D. Berkeley, P. Humphreys, F. Quek, Dynamic process modelling for

organisational systems supported by SASOS, in: Proceedings of the

Third International Working Conference on Dynamic Modelling of

Information Systems, Noodrwijkerhout, The Netherlands, June 1992.

[4] M. Earl, B. Khan, How new is business process redesign? European

Management Journal 12 (1) (1994) 20±30.

[5] K.-T. Chen, R. Lee, Schematic evaluation of internal accounting

control systems, Research Monograph No. RM-1992-08-01, Euridis,

Erasmus University Research Institute for Decision and Information

Systems, 1992.

[6] R. Davis, W. Hamscher, Model based reasoning: troubleshooting, in:

H.E. Shrobe (Ed.), Exploring Arti®cial Intelligence: Survey Talks

from the National Conferences on Arti®cial Intelligence, Morgan

Kaufmann, San Mateo, CA, 1988, pp. 297±346.

[7] R. Reiter, A theory of diagnosis from ®rst principles, Arti®cial Intel-

ligence 32 (1987) 57±95.

[8] P. Ramos, J.L. Fiadeiro, Organisational process aided design, in:

Conference on Systemics, Cybernetics and Informatics (SCI), Focus

Symposium on BPR, May 1997.

[9] P. Ramos, J.L. Fiadeiro, A deontic logic for diagnosis of organisa-

tional process design, in: Fourth International Workshop on Deontic

Logic in Computer Science (DEON'98), Bologna, Italy, 1998.

[10] L. Van der Torre, P. Ramos, Y.-H. Tan, J.L. Fiadeiro, The Role of

diagnosis and decision theory in normative reasoning, in: ModelAge,

4th Workshop on Formal Models of Agents, Italy, 1997.

[11] F. Santos, J. Carmo, Indirect action, in¯uence and responsibility, in:

M. Brown, J. Carmo (Eds.), Deontic Logic, Agency and Normative

Systems, Springer, Berlin, 1996, pp. 194±215.

[12] F. Cuppens, R. Demolombe, A deontic logic for reasoning about

con®dentiality, in: M. Brown, J. Carmo (Eds.), Deontic Logic,

Agency and Normative Systems, Springer, London, 1996, pp. 66±80.

[13] A. Jones, M. Sergot, On the characterisation of law and computer

systems: the normative systems perspective, in: J.-J.Ch. Meyer, R.J.

Wieringa (Eds.), Deontic Logic in Computer Science, John Wiley and

Sons, London, 1993, pp. 275±305.

[14] G.H. Von Wright, Deontic logic and the theory of conditions, in:

Deontic Logic: Introductory and Systematic Readings, in: Hilpinen

(Ed.), Reidel Publishing, Holland, 1971, pp. 159±177.

[15] J. Carmo, A. Jones, A new approach to contrary-to-duty obligations,

in: D. Dute (Ed.), Defeasible Deontic Logic, vol. I, Synthese Library,

1996 (in press).

[16] H.-N. CastanÄeda, The paradoxes in deontic logic: the simplest solu-

tion to all of them in one fell swoop, in: New Studies in Deontic

Logic, in: Hilpinen (Ed.), Reidel Publishing, Holland, 1981.

[17] M. Fitting, First-Order Logic and Automated Theorem Proving,

Springer-Verlag, New York, 1990, Ch. 3.


Documents

A computational tool that supports formal diagnosis of process design