Acquiring Knowledge for Business Process Re-Engineering

Hugh Cottam, Nigel Shadbolt and Nick Milton

University of Nottingham, Artificial Intelligence Group,Department of Psychology, University Park,

Nottingham NG7 2RD. United Kingdomhdc, nrs, nrm@psychology.nottingham.ac.uk

AbstractThe field of Business Process Re-Engineering (BPR) aimed at enabling the large scale re-design of processeswithin organisations. BPR initiatives are by nature highlyknowledge intensive activities. In this paper we argue thatthe knowledge based nature of BPR has not previouslyreceived sufficient recognition. We explain how BPRinitiatives can be assisted through the use of techniques andtools that have their origins within the knowledgeengineering community. In particular, we demonstrate theincorporation of knowledge acquisition (KA) techniquesand the use of ontologies within a toolset that supports BPR.This toolset, named the Structured Process Elicitation andDemonstration Environment (SPEDE) has been developedto support both the acquisition and management ofknowledge during BPR. SPEDE is currently being appliedand validated within the aerospace and automotiveindustries.

IntroductionThe concept of Business Process Re-engineering (BPR)has undoubtedly had immense impact on business thinkingin recent years. There are many large organisations thatclaim to be embracing BPR and achieving significantbenefits e.g. AT&T, Ford, Texas Instruments and RankXerox (Burke & Peppard, 1995). However, BPR has a highassociated failure rate, and is far from being an exactscience. It is a vague concept that encompasses a plethoraof explanations and definitions. The BPR literature, as awhole, is often contradictory. Individual texts tend toreflect a particular consultant’s preference, and theaccompanying methodologies are normally expressed at avery high level. The result is a lack of detailed guidance asto how high level re-engineering goals can be achieved.This has often led to high cost, high risk BPR initiatives. Itis our claim that this lack of guidance originates in a poorunderstanding of the knowledge requirements of a re-engineering initiative. This in turn leads to unconstrainedand unguided knowledge acquisition (KA), followed poorly planned and unsupported knowledge management.Because many of the problems associated with doing BPRare knowledge based, the experiences of the knowledgeengineering community can be usefully brought to bear inthis context.

The Structured Process Elicitation and Demonstration

Environment (SPEDE) is a methodologically groundedtoolset that provides support for BPR. It guides knowledgeacquisition and knowledge management throughout thelifecycle of a BPR exercise using a combination offeatures. In particular SPEDE concentrates on the use ofKA techniques and ontologies to support the acquisitionand organisation of process knowledge during BPR.

Business Process Re-Engineering (BPR)

There exists an extensive literature addressing the subjectof Business Process Re-engineering (BPR). An analysis the methods described in the literature (Bach et al, 1996)reveals both the number of methods in existence and theextent to which they contradict each other. However, thereare general observations that we can make about thesemethods. Two key concepts stand out as providing a unityto the field and distinguishing it from other businessimprovement approaches:

o The provision of dramatic improvements in anorganisation’s performance, as measured by such factorsas cost, quality, and time.

¯ A focus on process (as opposed to, say, the structure ofthe business).

There is considerable debate within the BPR literature as towhat a process is. One definition is that a process is "asequence of activities performed on one or more inputs todeliver an output to the customer of a process" (Talwar,1994). Typical examples of business processes are newproduct design, component manufacture, or sales anddistribution. However, simply stating that we are taking aprocess perspective does not tell us what it is that we mustknow about these processes. The precise knowledgecontent of the models that we construct of these businessprocesses will depend upon our goals at a particular stagewithin a BPR initiative. Uncovering this content, outlininggeneric aspects of processes, and understanding BPR goalsare key research aims of the SPEDE project.

11

From: AAAI Technical Report WS-98-13. Compilation copyright © 1998, AAAI (www.aaai.org). All rights reserved.

SPEDE

I¯

¯

¯ IInformation Flow ¯

I

design activity. The resulting first pass process definitionthen enters the design-analysis loop. Each design step is

Figure 1: The SPEDE Design-Analysis Loop

SPEDE - Methodological SupportWithin SPEDE we find it useful to characterise BPR as adesign task. The main goal of BPR is to design (or re-design) a business process in order to improve some aspectof the business’s performance. The fact that our designobject is a process rather than a product, has importantimplications for how we provide support for such a designtask. Rather than prescribe a rigid methodology for BPR,SPEDE attempts to identify possible sub-tasks withinprocess design and provide tools and techniques to supportthose subtasks. BPR methodologies commonly make anAS-IS/TO-BE distinction. An AS-IS model captures someaspect of an existing process, whereas a TO-BE modelprescribes an aspect of an intended new process. BPRmethodologies tend to recommend either an AS-IS or aTO-BE emphasis, such that designing a new processshould either commence by, modelling and then analysingthe AS-IS or by synthesising the TO-BE from scratchaccording to certain requirements and constraints. TheSPEDE approach discards this traditional AS-IS/TO-BEprocess dichotomy, and replaces it with the concept of aniterative design-analysis loop that includes knowledgeacquisition.

The SPEDE design-analysis loop shown in Figure 1 is atop level decomposition of the activities associated with aBPR initiative. SPEDE supports those activities within aBPR initiative that occur after the initial conception of theinitiative, and before the actual implementation of the newprocess. The concelbtion stage supplies requirements andconstraints for SPEDE. These initial inputs are used duringa preliminary KA activity that involves furtherrequirements elicitation along with more general KA.These act together as inputs to the first pass through the

followed by an analysis step. Every iteration back throughthe design stage will be preceded by some form of KAactivity. The SPEDE method will eventually produce as afinal output, a new process description in such a form thatit can be implemented.

This high level method description is based on the ideathat BPR can be broken down into a number of types ofactivity. Within SPEDE our initial breakdown includes theactivity groupings; preliminary KA, design, analysis andKA. These groupings are used in a very broad sense; e.g.analysis could include checking against originalrequirements, critical path analysis, computer basedprocess simulation, or presenting a proposal to implementthe new process to senior management. It can be seen thatSPEDE is not prescriptive in its methodology. Instead, itaims to provide the components with which users candefine for themselves the organisation of the activitiesassociated with their own BPR initiative. Advice on how todo this is provided in the form of a hypertext basedPrinciples And Methodology Support system (PAMS).

Assistance in the organisation of BPR activities is alsoprovided in SPEDE through the use of knowledgerequirement templates. These templates each consist of aKA activity that is performed in order to enable a designactivity, that precedes a particular analysis activity. Thetemplates include a definition of the knowledge that mustbe gathered during the KA activity. In this manner theydefine the knowledge requirements of design-analysisactivities within BPR. These are explained in greater detaillater.

In addition to the high level methodological support wehave described, SPEDE also provides tools, techniques andadvice that support the actual activities within BPR. Withinthis paper we shall concentrate on describing those tools

12

within SPEDE that support KA. Our emphasis is uponsoftware-assisted knowledge acquisition, and the tools andmethods we describe have their origins within knowledgeengineering. The SPEDE KA tools are customisations andadditions to the PCPACK knowledge engineeringworkbench (http://www.isl.co.uk/pc_pack.html) which is commercial package developed by Epistemics Ltdfollowing research on the VITAL project (Shadbolt, Motta,and Rouge, 1993).

The SPEDE KA tools make particular use of ontologiesas both an organising principle for knowledge and as ameans of enabling knowledge re-use. The ontologiesprovide a structure not only for the organisation ofknowledge once it is gathered but also for organising andguiding the KA activities themselves.

The Use of Ontologies

It is important that within our discussion of processknowledge re-use we do not lose sight of the overall goal.This goal is to design a better process with less effort.SPEDE has identified the knowledge gathering element ofBPR as both a major drain on effort and as being an areawhere substantial improvement can be achieved. Re-use ofprocess knowledge is one of the main mechanisms bywhich we believe this improvement in the quality andefficiency of knowledge gathering, modelling and designcan be achieved.

Re-use of process knowledge can be achieved in anumber of different ways; both in the form of theknowledge that will be re-used, and in the method bywhich that knowledge is re-used. Process knowledge re-usecan occur at both a specific and a generic level. At thespecific level, old process designs can be selected and re-used for a new process. This may involve a degree ofadaptation of the old design to suit the new situation. Atthe generic level we may use process descriptions that areconsidered to be applicable across a class of situations. Wecan also use generic descriptions that act as templates toconstrain the form and content of the knowledge gathered.A template is applicable across a class of situations butmust be instantiated/populated with specific knowledge.Within SPEDE we refer to these as knowledge templates.Both generic processes and knowledge templates willrequire selection and may require some adaptation to thecurrent situation. In summary, SPEDE has identified threeforms of re-usable process knowledge: specific processdescriptions, generic process descriptions and knowledgetemplates.

Ontologies have been chosen as a principal mechanismwithin SPEDE for process knowledge re-use. There are anumber of reasons for this. Firstly, ontologies are astructured approach to the representation of genericknowledge. They can be used both to express genericprocess descriptions and knowledge templates. Secondly,an important issue is the selection and use of any re-usableprocess knowledge. This becomes problematic as soon asthe knowledge repository grows to a reasonable size.

Ontologies can be used as an indexing system for bothgeneric and specific process descriptions, as we will show.

The Role of Ontologies

In spite of the increasing interest in ontologies there is stillvery little agreement on precisely what items they shouldcontain and the manner in which they should be structured.The most commonly used definition of an ontology is thatit is an "explicit specification of a sharedconceptualisation" (Gruber 1993). This roughly outlineswhat an ontology is, but doesn’t explain what it is for. Thesimplest answer would be that the purpose of any ontologyis to perform some type of knowledge sharing function.This knowledge sharing can take on many different forms:knowledge sharing within software applications, betweensoftware applications, knowledge sharing in the form of re-use, knowledge sharing to arrive at a commonunderstanding or to achieve integration. These many formsof knowledge sharing indicate the widely differing tasksand groups of agents that ontologies can support. It is thisdiversity in the purpose of ontologies that is a major reasonfor the lack of consensus on their content and structure. Inorder that they can be utilised in an optimal fashion theSPEDE ontologies have been designed to support specifictask and user requirements associated with performing aBPR initiative.

The Structure of OntologiesA survey of the recent ontological literature (Noy andHafner, 1997) outlines the space of possibilities for thestructure of ontologies. Ontologies can be taxonomically oraxiomatically based. They can be constructed using onelarge taxonomy (e.g. CYC, Lenat and Guha, 1990), or theycan be structured around a number of smaller taxonomies(e.g. TOVE, Gruninger and Fox, 1995). The concepts these smaller taxonomies can then be linked by relations.The nature of the taxonomies themselves can also vary.The links in the hierarchy can be limited to just "is-a-subtype-of" relationships, in which case the division ofconcepts into subconcepts is disjoint (multiple inheritancewill normally also be allowed). Alternatively thetaxonomic breakdown can occur on a number of paralleldimensions. This latter approach means that the resultingcategories cannot be disjoint unless a category is createdfor every possible combination of parallel distinctions. Anyof the taxonomy based approaches can lead to taxonomiesthat are either sparse or dense at their top level, and canhave different degrees of tangledness (though taxonomiesusing many parallel dimensions are likely to become verytangled). Ontologies may also vary in the level to whichthey are task dependent. CYC is a good example of anontology that is task independent, where as the PHYSSYSontology (Borst, Akkermans, and Top, 1997) is stronglylinked to engineering tasks. There exists strong debatewithin the ontological engineering community as to thetask dependent and independent character of ontologies.

The decision to commit to a particular structure for

13

ontologies will depend heavily on the purpose to which theontologies are applied. Within the SPEDE project thisrelationship between the structuring of ontologies and theirgoals has been explored more thoroughly.

A Process Ontology to Support KA in SPEDE

Below is the SPEDE general process ontology. Theontology given lists basic process object types along withpre-defined attributes and relations for that object type. Allbasic objects types can be organised in a taxonomy for thatparticular type using the "is-a-subtype-of" relation. Thelocal taxonomies are then linked via relations, e.g. the "HasData Input" relation links a task concept with a dataconcept. This is a base ontology that is designed to supportprocess KA. We use the term KA here in a broad sense thatembraces both knowledge elicitation and knowledgemodelling. The ontology is designed to force thedistinction during KA between basic process object types:task, data, result, role, organisational group, agent, productitem, cost, location, resource, requirement. These basicprocess object types have been decided based on anextensive analysis of existing ontologies, enterprise andprocess modelling formats, and the knowledgerequirements of the analysis activities conducted duringBPR. We have listed the ontology (though not in itsentirety) to illustrate its nature and scope. There are alsoadditional concepts that are being considered for inclusionin the base ontology such as: skill, communication link,goal, metric, risk, quality. It is envisaged that the baseontology will undergo modifications following furtherexperimentation.

The base ontology is closest in structure to the virtualenterprise ontologies from the TOVE project. It shouldhowever be noted that the SPEDE ontology is primarilyaimed at supporting KA, whereas the TOVE ontology isaimed at the support of enterprise databases and deductivecapability over such databases. The formal logicdefinitions have been omitted from our listing for the sakeof brevity (These formal definitions are required in order toremove ambiguities).

ProcessConcept ID:Name:Attributes: Start Time, Finish Time,

DurationHierarchy Relations: Has Sub-Process, Has Parent

ProcessSequence Relations: Ends Before Starts, Starts

Before Ends, Starts BeforeStarts, Ends Before Ends,Starts After Ends, Ends AfterStarts, Starts After Starts, EndsAfter Ends, Meets, Contains

Resource Relations: Uses, Produces, Consumes,Releases

Data Relations: Has Data Input, Has DataOutput

Other Relations: Is Performed By, HasLocation, Has Result

RoleConcept ID:Name:Relations: Has Members, Has Constraint, Has

Group, Has Authority Link, IsEmpowered, Has Goal, Has Agent,Requires Skill

Organisational GroupConcept ID:Name:Relations: Has Role, Has Constraint, Has Group,

Has Authority Link, Is Empowered, HasGoal, Has Location, Has Members

AgentConcept ID:Name:Relations: Has Role, Has Constraint, Has Group,

Has Authority Link, Is Empowered, HasGoal, Has Location, Has Skill

Location

IConcept ID:Name: I

ResultConcept ID:Name:Type Attribute: Fail, Pass, True, False, Continue,

ReturnRequirement

IConcept ID:Name: I

Data ItemConcept ID:Name:Type Attribute: Electronic, Paper

Product ItemConcept ID:Name:Type Attribute: Complete Product, Assembly,

Component, FeatureRelations: Has Sub-Part, Has Requirement, Has

Constraint, By-Product of, Product of,Has Location

ResourceConcept ID:Name:Type Attribute: Raw Materials, Facility, Tool, Operator,

SpaceMotility Mobile, StationaryAttribute:Consumption: Continuous, DiscreteUnit of Length, Area, Volume, Weight, Time,Measure: Manhours

14

Cost Per Unit: ]

fRelations: Has Location

Table 1: SPEDE General Process Ontology

Knowledge Acquisition and Tool Support

In this section we describe how new KA tools have beendeveloped to support the acquisition of process knowledgeand to facilitate re-use. We then go on to show how thishas allowed the utilisation of previously developed KAtools within a process context

Ontologies are used in SPEDE as the building blocks forthe construction of well structured process descriptions.There are two levels of use for the ontology based tools inSPEDE:

* the developer accesses a library of ontologies using apurpose built SPEDE ontology editor in order toassemble ontologies that are more specific both in terms

of task and domain. These are then handed to themodelling level user.

¯ the modeller browses the ontologies handed down tothem from the developer in order to construct aknowledge description of some aspect of a process. Asdiscussed earlier this will normally be part of a KAactivity that fulfils the requirements of design andanalysis activities at a particular stage within BPR. Theontology will reflect this intention.

This distinction between the two user levels correspondswith a marked difference in the level of ontologicalengineering competency expected of the developer leveluser and the modelling level user. This is reflected in thedesign of the tools that support each level of ontology use.

Figure 2: Ontology Editor

15

designer

Figure 3: Process Design Tool

~-,,,- .................................................................................................................................................................................... ........ ¯ 111111111111i~#~

(attribute)depadme~

design analysis accou~e~verage duretior outsourced

yes no

Crankshaft Concept Anely~Crank - Balance

testStatic Stiffness

Static Stiffness Hand CStatic Stiffness FE Mad

Torsional VibrationCrank - Classical Stiffne8Basic Bearing Analysis

Crankshaft Detail AnalysisBending Dynamics Analy~Bearing AnalysisCrank Strength

50005000

...... 450050008000

50004000

50005000

.: 2000 ~--~..................... 2500 ....

Block Concept AnalysisMechanical Strength

2000 ];.::;:2000 -- ~ J’ii!;::.

~ ~ ~ !;~ii~...... ~ :3000 ~ . ......

2000

Figure 4: The Matrix Tool

16

SPEDE ontologies that support diagrammatic processdescriptions make certain high level distinctions betweenconcepts. At the highest level the primary distinction madewithin the ontology is the decision as to the basic objecttype: e.g. task, data, agent, result, e.t.c. This is thefundamental modelling commitment that must be madewhen adding any object to a process model, and isreflected in the design of the ontology editor pictured inFigure 2. The SPEDE ontologies supporting diagrammaticprocess modelling are a set of local taxonomies (for basicobject types) that are linked by relations. This baseontology was listed in table 1. Figure 2 shows a tasktaxonomy selected within an ontology for modelling theanalysis of designs within new product introductionprocesses. Other basic object taxonomies can be selected,including those representing data, agefits, results, e.t.c. Therounded rectangles represent task concepts and the linksrepresent "is-a-subtype-of" relationships. Numerical orcategorical attribute values can be assigned to concepts,and these are inherited down the "is-a-subtype-of"relationship.

The tool supports the hypertext documentation of eachconcept, which enables the provision of advice andexplanation to the users of the ontology. The ontologyshown in Figure 2 represents a theory of design analysisthat is specialised for the automotive industry. Thisincludes tasks that perform design analysis, the dataassociated with those tasks, the agents that perform designanalysis, the decision points within design analysis, andpossible return values for design analysis processes. Figure3 shows how the process design tool can be used to browseand access the ontology in order to build an instance modelof a process that utilises design analysis. The figure showsthe ontology browser being used to select a task conceptfrom the ontology. An instance of this concept is thencreated in the process instance model.

The Link to Existing KA Tools. The ontology basedKA tools that we have described, enable existing KA tools(i.e. those that are part of the PC Pack commercial toolset)to be applied in the process context. Three tools haveproved particularly useful when applied in this manner.Firstly, the matrix tool shown in Figure 4 allows the user to

process but if you take producing drawings (the most importantand the actual detail of the parts. How we about

~. Each of these has other processes involved, scyou’ct start this and what would b e involved in each o f thes e, butthis is the best thing I have for a g~el d~0pment p~ from

~Sh. SO I was just goin~around this. So these are the

effectively. So these four are referred to as phases, so does that:they hap~ ~quentially?. They’d overlap. These are in ...................you’d start here, you’d start with ~equir~ents then do somedesign. Once you’ve got your concept fightdefinition of the parts. Oncemake that reality, by

Figure 5" The Protocol Editor

17

assign attributes and values of those attributes, to bothconcepts and instances. Thus concepts that are present inthe ontologies constructed using the ontology editor(shown in Figure 2) can have attributes and valuesassociated with them.

In Figure 4 process concepts are listed top to bottomalong the left hand side. The indentation of these reflectsthe hierarchy depicted in Figure 2. Instances can also beshown in this hierarchy, though in the example given theyare not. Attributes are arranged in Figure 4 from left toright along the top of the figure. The attributes shown infigure 4 indicate the department that a process is usuallyperformed in, the average duration of a process andwhether a process can be outsourced or not. As can be seenthe first and last of these have associated categoricalvalues, whereas the middle one has a numerical value. Theattributes can be arranged in a deep hierarchy though theones depicted in Figure 4 are merely a flat set of attributes.The toolset also supports the inheritance of attribute valuesdown the concept hierarchy. Thus, it should be noted thatin Figure 4, a dark bar in a box indicates that a particularconcept has that value for a categorical attribute. A lightbar indicates that a concept has inherited that value from aparent concept. Numerical values are inherited in a similarmanner though the colour coding is not easily

distinguished in Figure 4. It can be seen that for the toplevel process concept in Figure 4 no value has been definedfor "average duration". In this situation, the matrix tooldisplays the numerical range associated with that attribute.The toolset also supports multiple inheritance, andconflicting values are flagged in the matrix tool when aconcept inherits different values from different parentconcepts.

The second existing KA tool that can now be appliedmore easily within a process context is the protocol editor.This is shown in Figure 5 being used to highlight atranscript that was used to populate the tools shown infigures 2, 3, 4 and 6. The transcript shown has been elicitedfrom an expert on the application of design analysis withinprocesses. The tool allows the user to highlight the textwith various pens. Different colour pens indicate that aparticular section of text is the label for a concept, anattribute, an attribute value, e.t.c. Having labelled the textin this manner the tool can automatically generate theseobjects in an underlying database that can then be accessedby the other tools that we have discussed.

The third existing KA tool is shown in Figure 6. This isa repertory grid tool that enables the user to assess thesimilarity of both concepts and the attributes that are usedto describe them. This is based on a technique known as

Figure 6: The Repertory Grid Tool

18

cluster analysis. Attributes must be chosen such that theyhave two poles representing the limits of a value on a scalefrom 1 to 9. The various concepts are then rated for eachattribute using these scales. In the example shown inFigure 6, a number of process concepts are beingcompared, and these are arranged along the top of thefigure. The attributes that are being used to compare theconcepts are arranged along the left of the figure. Theattributes used are as follows:-

Computer Based -- (Poles: not to heavily)Average Duration -- (Poles: short to long)Outsourced -- (Poles: never to often)Associated Reliability -- (Poles: low to high)Department -- (Poles: always analysis to always design)Associated Cost -- (Poles: cheap to expensive)

The numbers shown in the grid in Figure 6 indicate therating that concept has been given for a particular attribute.The lines that are shown at the side of the grid represent adendrogram. A closer linking of the lines that are attachedto either concepts or attributes indicates a higher degree ofsimilarity between either those attributes or the concepts(based on the information given). This is a powerful technique that can be used as a prompt to elicit:

¯ new higher level attributes or concepts, to describegroups that are similar.

¯ new attributes to differentiate between concepts that havebeen analysed as similar based on the information so fargiven.

¯ correlations between different attribute values, in theform of rules.

Discoveries such as a stable super-ordinate class ofconcepts or attributes will then often lead to reformulationof the ontology concerned.

Knowledge Templates

The process KA within SPEDE is performed to meet theknowledge requirements of a particular stage within a BPRinitiative. The content and structure of SPEDE processmodels will depend on a number of interdependent factors:

¯ The BPR goals may be to minimise cost, minimise time,maximise quality, or more likely to combine a number ofthese goals within more specific requirements andconstraints.

¯ The analyses that will be performed on the processmodels also impose certain knowledge requirements.

¯ The knowledge that the process models must contain inorder for implementation of the re-engineered process totake place.

As can be seen, there are a number of factors that imposeknowledge requirements upon our SPEDE processknowledge acquisition. We can view the cycle of stages in

a BPR initiative as representing a knowledge flow. Bybetter understanding this knowledge flow we can betterdirect and constrain the knowledge acquisition throughoutthe BPR initiative. A simple example is the differencebetween the knowledge requirements of an analysis stagein BPR and those of the implementation stage. Clearly, theanalysis is likely to require a much smaller amount ofknowledge than the implementation. In addition to this theanalysis might well result in extensive modification beingnecessary to the process design, therefore requiringadditional KA. It would seem sensible to suggest that theKA associated with implementation not be performed untilthe process design is stable. However, this judgement mustbe combined with an estimate of the additional costsassociated with performing KA in separate stages. Thelinking of high level requirements to the type of knowledgeto be acquired can be explicitly supported within SPEDEusing knowledge templates. Examples of ontologyconfiguration provided in the form of knowledge templateswould be the following.

A Knowledge Template for Critical Path Analysis.Table 2 shows a subset of the general process ontology. Itprovides a template for the knowledge required to performcritical path analysis on a process.

ProcessConcept ID:Name:Attributes: Start Time, Finish TimeHierarchy Relations: Has Sub-ProcessSequence Relations: Ends Before Starts, Starts Before

Ends, Starts Before Starts, EndsBefore Ends

Table 2: Knowledge Template for Critical Path Analysis

A Knowledge Template for Role Definitions. Table 3shows a template for the knowledge required to make roledefinitions associated with the tasks within a process.These role definitions also make use of knowledge aboutagents, organisational groups and the locations, constraintsand authority links that are associated with these. Tasksequencing knowledge is only required to ensure that toomany roles are not assigned to concurrent tasks.

ProcessConcept ID:Name:Attributes: Start Time, Finish TimeHierarchy Relations: Has Sub-ProcessSequence Relations: Ends Before Starts, Starts Before

Ends, Starts Before Starts, EndsBefore Ends

Other Relations: Is Performed By, Has LocationRole

Concept ID:Name:Relations: Has Members, Has Constraint, Has

Group, Has Authority Link, IsEmpowered, Has Goal, Has Agent,Requires Skill

19

Organisational GroupConcept ID:Name:Relations: Has Role, Has Constraint, Has Group,

Has Authority Link, Is Empowered, HasGoal, Has Location, Has Members

AgentConcept ID:Name:Relations: Has Role, Has Constraint, Has Group,

Has Authority Link, Is Empowered, HasGoal, Has Location, Has Skill

LocationConcept ID:Name: I

Table 3: Knowledge Template for Role Definition

The SPEDE tools and methodology are being put throughcontinuing assessment in large scale industrial enterprisesin the UK, such as Rover and Rolls Royce Aerospace. Thisis aimed at improving the quality and design of the toolsetand accompanying methodology, but also at populating thetoolset with real-life complex examples.

Considerable work has also been done within theSPEDE project on developing techniques and methods foracquiring process knowledge in the form of structurednatural language descriptions. A grammar and naturallanguage process ontology have been constructed to assistin this. Further work is required to provide tool support forthese descriptions and to establish mappings to theontologies discussed in this paper.

SPEDE reflects a growing trend within the field ofknowledge engineering; that the lessons learnt about theacquisition, organisation and use of knowledge within thearea of knowledge based systems are widely applicableelsewhere.

SPEDE facilitates the application of knowledgeacquisition tools, techniques and methodology to theactivity of acquiring and managing process knowledgewithin the context of BPR. A principal mechanism fordelivering knowledge re-use and enabling knowledgeorganisation within SPEDE is the use of ontologies. Thereare great advantages to using ontologies in this context:

¯ They provide a means of generally facilitating knowledgere-use. In particular this is possible within groups andorganisations, but may also be viable acrossorganisations.

¯ They provide links from common clearly defined termsto process models gathered from a potentially widenumber of sources across the organisation. This has greatbenefits for enabling the meaningful interpretation andanalysis of the models.

¯ They can be used to express knowledge requirementtemplates that guide KA according to the activitiescarried out during BPR.

In summary, SPEDE views BPR as a knowledge based

design activity. It provides users with the tools, techniquesand methodology to support the acquisition, organisation,management and re-use of the knowledge associated withperforming BPR. In so doing it greatly reduces the costsand risks of doing BPR.

Acknowledgements

The work described was carried out under the EPSRCInnovative Manufacturing Initiative (IMI). The SPEDEproject is being jointly undertaken by the ArtificialIntelligence Group at the University of Nottingham, theWarwick Manufacturing Group, the Keyworth Institute atthe University of Leeds, Rolls Royce, Rover andComputervision.

References

Bach, V., Brecht, L., Hess, T. & Osterle, H. 1996.Enabling Systematic Business Change: Integrated methodsand software tools for Business Process Redesign.Wiesbaden: Verlag Vieweg.

Borst, W.N., Akkermans, J.M., and Top, J.L. 1997.Engineering Ontologies. International Journal of HumanComputer Studies 46, 365-406. Special Issue on UsingExplicit Ontologies in KBS Development

Burke, G. & Peppard, J. 1995. Business Process Re-engineering: Research Directions. In G. Burke & J.Peppard (eds), Examining Business Process Re-engineering: current perspectives and research directions.London: Kogan Pages 25-37.

Gruber, T.R. 1992. ONTOLINGUA: A Mechanism toSupport Portable Ontologies, KSL-91-66, KnowledgeSystems Laboratory, Stanford University.

Gruber, T.R. 1993. Towards Principles for the Design ofOntologies Used for Knowledge Sharing, KSL-93-04,Knowledge Systems Laboratory, Stanford University.

Gruninger, M. and Fox,M.S. 1995. The Logic of EnterpriseModelling. In J. Brown and D.O.Sullivan (eds)Reengineering the Enterprise pp. 83-98. Chapman andHall.

Lenat, D. B. & Guha, R. V. 1990. Building LargeKnowledge-Based Systems. Reading, MA: Addison-Wesley.

Noy, F. N. & Hafner, C. D. 1997. The State of the Art inOntology Design, AI Magazine, Fall 1997, 18-3.

Shadbolt, N., Motta, E., & Rouge, A. 1993. Constructingknowledge based systems. IEEE Software, November, 34-38.

Talwar, R. 1994. Re-engineering - a Wonder Drug for the90s? In C. Coulson-Thomas (ed), Business Process Re-engineering: Myth and Reality. London: Kogan Page.

2O

21