Hoofdstuk 3 Automatisering en beslissingsprocessen

Hoofdstuk 3 Automatisering en beslissingsprocessen

3.1 Inleiding In hoofdstuk 2 is het gebruik van modellen in het beslissingsproces beschreven. De aard van de modellen hangt samen met de vorm van ondersteuning die door informatiesystemen kan worden geleverd. In dit hoofdstuk staat het ondersteunen van dit beslissingsproces met behulp van een computer centraal. De invloed van computers op het beslissingsproces is in de loop van de tijd groter geworden. In de beginjaren was de computer met name gericht op het verwerken van gegevens (zie paragraaf 3.2). In de loop van de tijd werden computers meer gericht op het programmeren van goed gestructureerde problemen (paragraaf 3.3) en later ook op de ondersteuning bij het nemen van beslissingen in geval van minder goed gestructureerde problemen (paragrafen 3.4 en 3.5). Aan de hand van die ontwikkeling kunnen een aantal fasen worden onderscheiden36. Deze fasen zijn: 1. verwerken van gegevens, Electronic Data Processing (EDP), 2. oplossen van goed gestructureerde problemen, Management Information Systems (MIS), 3. de twee voorafgaande plus de ondersteuning van de besluitvorming, Decision Support Systemen (DSS) en Kennissystemen (KS). In de laatste jaren is een trend waar te nemen naar de integratie van kennissystemen en decision support systemen, die tot uitdrukking komt in systemen met namen als kennisgebaseerde beslissingsondersteunende systemen en aanverwante termen. Deze ontwikkeling wordt beschreven in paragraaf 3.7. 36 De hier beschreven fasering moet niet worden verward met de groeifasen van het gebruik van informatiesystemen in een specifieke organisatie, zoals die door Nolan zijn gespecificeerd. In eerste instantie onderscheidt Nolan (Gibson en Nolan, 1974) vier fasen, nl.: initiation, diffusion, formalization en maturity. Dit aantal breidt hij later uit tot zes (Nolan, 1979), initiation, contagion, control, integration, data en maturity.

54

Hoofdstuk 3

De hierboven genoemde fasen beschrijven zowel de historische ontwikkeling van informatiesystemen in het algemeen als het gebruik van informatiesystemen in een specifieke organisatie. Boersma (1989) maakt een onderscheid tussen concrete en abstracte informatiesystemen. Een abstract informatiesysteem is een model, een afbeelding van een reëel systeem. Het abstracte systeem speelt een rol bij de ontwikkeling van het concrete systeem. In dit hoofdstuk wijzen wij bij het gebruik van de term informatiesysteem op het concrete informatiesysteem, tenzij expliciet anders vermeld. Een organisatie moet de fasen in de genoemde volgorde doorlopen omdat de latere fasen zijn gebaseerd op de eerdere fasen. Zo vormen bijvoorbeeld de in de EDP-fase ontwikkelde bestanden de basis voor de andere vormen van informatieverwerking. De invloed van de verschillende fasen op het beslissingsproces loopt sterk uiteen. De EDP-fase heeft ten hoogste een indirect effect op de besluitvorming. Specifieke decision support systemen en kennissystemen zijn daarentegen direct gericht op specifieke beslissingsprocessen. In de volgende paragrafen worden de verschillende systemen en de invloed van deze systemen op de besluitvorming beschreven.

3.2 Electronic Data Processing Electronic Data Processing (EDP) vormt de eerste fase in het gebruik van computers binnen organisaties. Deze fase wordt gekenmerkt door het automatiseren van arbeidsintensieve, relatief eenvoudige en frequente verwerkingen van gegevens. Het automatiseren van deze regelmatige verwerkingen heeft met name tot doel een efficiency-verhoging te realiseren. Met beslissingsprocessen binnen organisaties heeft deze fase nog weinig van doen. Ten hoogste worden bepaalde overzichten vervaardigd die bij het verwerken van de gegevens als bijprodukten ontstaan. De EDP-fase heeft een grote invloed gehad, en heeft die nog steeds, op de werkverdeling rond de dataverwerking in organisaties. Een groot deel van de standaardverwerkingen van gegevens worden nu succesvol uitgevoerd door computers. Salarisadministratie, facturering en voorraadregistratie zijn voorbeelden van gegevensintensieve processen die uitstekend door computers kunnen worden uitgevoerd. EDP omvat de toepassing van computers bij routinematige gegevensverwerkende activiteiten in een organisatie. In de loop van de tijd zijn computers daarnaast in toenemende mate toegepast bij veelvoorkomende kantoortaken. Een belangrijk deel van deze taken wordt gevormd door één of andere vorm van communicatie. Kantoorautomatisering richt zich op de ondersteuning van deze communicatie binnen organisaties. Alter (1992) definieert kantoorautomatisering als: ‘An office automation system facilitates everyday communications and information processing tasks in offices and business organizations.’

Deze communicatie kan betrekking hebben op spraak, tekst en beelden (Hicks, 1993). De ondersteuning kan diverse vormen aannemen, afhankelijk van het type

Automatisering en beslissingsprocessen

55

communicatie. Tekstverwerking, elektronische mail (e-mail), desktop-publishing en fax-transmissies zijn gericht op tekstcommunicatie. Spraakverwerking (zowel menselijke spraak als door de computer gegenereerde spraak), telefoon en videoconferencing zijn gericht op spraakcommunicatie. Beeldcommunicatie wordt onder andere ondersteund door middel van desktop-publishing en fax-transmissies. Uit de voorgaande opsomming blijkt dat bepaalde middelen gericht zijn op meer dan één type van communicatie. Een fax wordt bijvoorbeeld zowel gebruikt bij de communicatie van tekst als de communicatie van beelden. Kantoorautomatisering heeft betrekking op de communicatie binnen organisaties. Recente ontwikkelingen maken communicatie en datatransport tussen organisaties mogelijk. De ‘electronic highway’37 biedt de mogelijkheid internationaal en intercontinentaal te communiceren. De ‘electronic highway’ biedt een informatieinfrastructuur voor de communicatie van tekst, beeld en spraak, alle in digitale vorm. Het belang van een goede infrastructuur wordt beschreven door Porter (1990): ‘a nation’s industry depends on a modern and improving infrastructure. This is particular true in advanced transportation, logistics and telecommunications, all integral to introducing modern technologies and to competing in foreign markets. Both firms and governments have a responsibility in creating and upgrading infrastructure.’

Door de technologische ontwikkelingen op het gebied van computers en telecommunicatie, wordt de elektronische infrastructuur een steeds belangrijker deel van de totale infrastructuur (Kettinger, 1994). Kettinger beschrijft welke functionaliteit een dergelijke infrastructuur moet bieden: ‘The vision of the proposed national information infrastructure is one of a universally accessible widely distributed, private and public interconnected networks that permit access to a variety of databases and that can transmit voice, text, images, video, and virtually any other format for depicting information to anyone, at any time, in any place.’

Kettinger beschrijft de ontwikkeling van deze informatie-infrastructuur aan de hand van een innovatiediffusiemodel38. De eerste gebruikers van de informatieinfrastructuur waren vooral te vinden in de wetenschappelijke wereld. Het gebruik bestond met name uit elektronische mail. In de daarop volgende fasen maken ook bedrijven, bibliotheken, scholen etc. gebruik van de infrastructuur. In de volwassenheidsfase benadert de infrastructuur de in het vorige citaat beschreven

37 De Amerikaanse term highway wordt hier gebruikt omdat de vertaling ‘electronische snelweg’ geen recht doet aan de oorspronkelijke betekenis van het woord. De ruimte en vrijheid die het begrip highway impliceert wordt niet goed weerspiegeld door de Nederlandse equivalent van dat woord. 38 Kettinger (1994) hanteert het model van McFarlan en McKenney. Dit model bestaat uit de fasen: (1) technology identification and initial investment, (2) technological learning and adaptation, (3) rationalization and control en (4) maturity / wide spread technology transfer.

56

Hoofdstuk 3

functionaliteit. Informatiesystemen van organisaties kunnen direct worden aangesloten op netwerken. De financiering van de infrastructuur verandert bij het doorlopen van de ontwikkelingsfasen. De eerste fase is met name gebaseerd op overheidssteun en adhoc financiering. In de latere fasen zal de commerciële exploitatie van de infrastructuur belangrijker worden.

3.3 Management Information Systems De tweede fase die wordt onderscheiden is die van de Management Information Systems (MIS). Davis en Olson (1987, pag. 6) definiëren een MIS als: ‘an integrated, user-machine system for providing information to support operations management, and decision making functions in the organization. The system utilizes computer hardware en software; manual procedures; models for analysis, planning, control and decision making; and a database’

De MIS-fase richt zich ten opzichte van EDP minder op de verwerking van gegevens en meer op het aanleveren van informatie. Hierbij is het onderscheid tussen gegevens en informatie van belang. Gegevens representeren feiten, objecten etc. Informatie betreft zodanig verwerkte gegevens dat de betrokken persoon er een betekenis aan kan toewijzen. Met een MIS kunnen bijvoorbeeld periodiek vaste overzichten worden vervaardigd die het verloop van allerlei kenmerken in de organisatie weergeven. Wekelijks wordt bijvoorbeeld de debiteuren- en crediteurenpositie getoond. Naast deze periodieke standaardrapportering is het tevens op beperkte schaal mogelijk specifieke rapporten te genereren. De invloed van MIS op het beslissen in organisaties bestaat uit het automatiseren van bepaalde keuzefasen. Goed gestructureerde problemen kunnen, na modellering, met behulp van een algoritme worden opgelost. Een voorbeeld van een dergelijk probleem is de bepaling van de optimale bestelhoeveelheid. Frowein (1990) merkt op dat de MIS-fase geen succes blijkt te zijn. Hij draagt hiervoor twee redenen aan. De organisatie omvattende modellen komen niet echt uit de verf omdat een koppeling tussen modellen op verschillende niveaus in de organisatie nodig is. Deze koppeling is met mathematische modellen moeilijk te realiseren mede doordat de doelstellingen van de organisatie niet altijd kunnen worden vertaald naar doelstellingen van de afzonderlijke afdelingen. De tweede reden die hij noemt is de door Bosman en Sol geconstateerde scheiding tussen planning (problemen waarop een MIS vaak is gericht) en administreren. De administratie kan vaak de benodigde gegevens niet leveren. De problemen die in de MIS-fase werden opgelost zijn goed gestructureerde problemen die vervolgens met behulp van een algoritme kunnen worden opgelost. Bekende toepassingen in deze categorie zijn de netwerkplanningsystemen en de voorraadreguleringssystemen. In deze systemen is de problematiek van de keuze in software (men kan zeggen formele regels) vastgelegd.


57

3.4 Decision Support Systemen De term Decision Support Systeem (DSS39) is geïntroduceerd door Scott Morton in 1971. De betekenis van het begrip is direct uit de woorden af te leiden. De term beslissing (decision) benadrukt dat dergelijke systemen zijn gericht op het nemen van beslissingen en niet alleen op het verwerken van gegevens en informatie. ‘Support’ duidt erop dat het systeem niet gericht is op het vervangen van de beslisser maar op de ondersteuning van de beslisser. Systeem geeft aan dat er sprake is van geïntegreerde aanpak waarbij de gebruiker, de machine c.q. de computer en de probleemcontext een rol spelen. Sinds de introductie van het begrip DSS is er door een groot aantal auteurs een groot aantal verschillende interpretaties van DSS opgesteld. Er bestaat een grote spraakverwarring over wat nu precies als een DSS moet worden opgevat. Uitgaande van de term DSS kan elk systeem, waarbij op één of andere manier sprake is van ondersteuning bij het nemen van een beslissingen, als een DSS worden gekwalificeerd. Op deze manier kan bijna elk systeem, behalve de puur transaktieverwerkende systemen, als een DSS worden aangemerkt. Een dergelijke definitie die geen indeling geeft is weinig zinvol. Om hieraan tegemoet te komen zijn diverse scherpere definities ontwikkeld. Sommige benadrukken hierbij de functionaliteit van het systeem terwijl andere de technische aspecten centraal stellen. Elementen die in deze definities terugkomen zijn: het al dan niet gestructureerd zijn van beslissingen, de niveaus van DSS software en de componenten van DSS software Decision Support Systemen zijn bedoeld om de beslisser te ondersteunen bij het nemen van beslissingen, en niet zozeer deze beslisser te vervangen. Deze aanpak erkent de cognitieve beperkingen van de mens en probeert de zwakke punten in het functioneren van de mens te ondervangen door middel van ondersteuning met behulp van een computer. De DSS aanpak probeert de sterke punten van de mens en de computer samen te voegen. Thierauf (1982) schrijft over decision support systemen: ‘Fundamentally, the main thrust of decision support systems is on decisions in which there is sufficient structure for the computer and quantitative models to be of value but where the user's judgement is essential.’

Met andere woorden, het probleem wordt niet volledig door de computer opgelost, de mens behoudt een significante en zelfs doorslaggevende rol in het beslissingsproces. Spraque en Carlson (1982) definiëren een DSS als: ‘A DSS is an interactive computer based system that helps decision makers to use data and models to solve unstructured problems’

De ondersteuning vindt plaats door het beschikbaar stellen van methoden en data. Het moet voor de beslisser mogelijk zijn toegang te krijgen tot bepaalde databases 39 Afhankelijk van de context verwijst de afkorting DSS naar het begrip decision support systeem in enkelvoud of meervoud.

58

Hoofdstuk 3

om over de noodzakelijke gegevens te beschikken. Deze gegevens komen voor een groot deel uit bestanden, die in de EDP-fase tot stand zijn gekomen. Tevens moet de beslisser mogelijkheden worden geboden gegevens te manipuleren met behulp van modellen. 3.4.1 Gestructureerde en ongestructureerde beslissingen In veel definities van DSS komt naar voren dat deze systemen gericht zijn op het ondersteunen van ongestructureerde problemen. Goed gestructureerde problemen kunnen op een andere en eenvoudiger manier worden opgelost. Zoals reeds bij de bespreking van MIS is genoemd, worden in die fase bepaalde formaliseerbare problemen in de software vastgelegd. DSS daarentegen zijn gericht op die problemen waarbij nog wel van enige structuur sprake is, zodat computers kunnen worden gebruikt, maar waar de inbreng van de beslisser van doorslaggevend belang is. Sol (1980, pag. 5) definieert goed gestructureerde problemen als problemen die voldoen aan de volgende drie voorwaarden: 1. the set of alternative courses of actions or solutions is finite and limited; 2. the solutions are consistently derived from a model system that shows a good correspondence; 3. the effectiveness or the efficiency of the courses of action can be numerically evaluated. Ongestructureerde problemen voldoen niet aan een of meer van deze voorwaarden. De gestructureerdheid van een probleem kan persoons- en tijdgebonden zijn. Een probleem dat voor iemand op een bepaald moment niet gestructureerd lijkt, kan na uitvoerige bestudering toch gestructureerd zijn of gestructureerde componenten bevatten. Naast het onderscheid tussen goed en slecht gestructureerde problemen kan het onderscheid worden gemaakt tussen programmeerbare en niet programmeerbare problemen (Simon, 1960): ‘Decisions are programmed to the extent that they are repetitive and routine, to the extent that a definite procedure has been worked out for handling them so they won't have to be treated de novo each time they occur. Decisions are nonprogrammed to the extent that they are novel, unstructured and consequential, there is no cut and dried method for handling the problem because it hasn't arisen before, or because its precise nature and structure are elusive or complex, or because it is so important that it deserves a custom-tailored treatment.’

Vaak worden de programmeerbare problemen gelijk gesteld aan de goed gestructureerde problemen en de slecht gestructureerde problemen aan de niet programmeerbare problemen. Sol (1980) wijkt hier vanaf door te stellen dat beslissers oplossingen kunnen vinden voor slecht gestructureerde problemen die kunnen worden geprogrammeerd. De goed gestructureerde problemen zijn op deze manier een deelverzameling van de programmeerbare problemen.


59

Van belang is de vraag waar de ondersteuning van slecht gestructureerde problemen zich op richt. Die vraag kan in een aantal vragen worden onderverdeeld: 1. Richt de ondersteuning zich op alle fasen van het proces van beslissen of op één daarvan? 2. Richt de ondersteuning zich op een bepaalde functie of op een bepaald niveau? 3. Richt de ondersteuning zich op het gebruik van formele regels, informele regels of beide? 4. In welke vorm wordt die ondersteuning gegeven? In het algemeen wordt in de literatuur aan deze vragen weinig aandacht besteed. In paragraaf 3.8 komen wij, na de bespreking van de verschillende varianten van beslissingsondersteunende systemen, op die vragen terug. 3.4.2 Niveaus van DSS software Een manier om tot een structurering van het begrip DSS te komen is de door Sprague en Carlson (1982) gedefinieerde opdeling in drie niveaus van DSS software: DSStools, een DSS-generator en een specifiek DSS. Door recente ontwikkelingen kunnen hier een aantal niveaus aan worden toegevoegd, nl. de generieke DSS, kennissystemen en de integratie van deze categorieën (zie de paragrafen 3.4.5, 3.5 en 3.7). DSS-tools De DSS-tools c.q. gereedschappen vormen de basis voor zowel de specifieke DSS als de DSS-generatoren. Met de gereedschappen kunnen specifieke DSS worden gebouwd maar in de meeste gevallen is het raadzamer om met de gereedschappen een DSS-generator te ontwikkelen. De gereedschappen die bij het ontwikkelen van een DSS of SDSS kunnen worden gebruikt, hebben betrekking op lineair programmeren, simulatie, spreadsheets, grafieken-generatoren en tekstverwerking. DSS-generator Sprague en Carlson (1982) definiëren een DSS-generator als: ‘A DSS generator is a package of related hardware and software which provides a set of capabilities to build specific DSS quickly and easily’

Een DSS-generator bestaat uit een verzameling componenten waarmee een specifiek-DSS kan worden ontwikkeld. De componenten kunnen bestaan uit de in de vorige paragraaf gedefinieerde gereedschappen. De bouwer van een DSS-generator moet een keuze maken welke gereedschappen in de generator worden opgenomen. Specifiek DSS Het specifiek DSS (SDSS) is gericht op een specifiek probleem en één beslisser die dat specifieke probleem heeft. De gebruiker van het systeem kan de gegevens uit de databank en de methoden uit de methodenbank gebruiken om zijn beslissingsproces te modelleren. Het specifiek DSS hoeft niet het gehele beslissingsproces van

60

Hoofdstuk 3

intelligence tot choice te beslaan. Het SDSS kan zijn gericht op één of meerdere fasen van het beslissingsproces. Dit is niet per definitie alleen de keuzefase. Een SDSS kan ook gericht zijn op de probleemherkenning, de probleembeschrijving en/of het genereren en evalueren van alternatieven. De gebruiker van het systeem kan de beslisser zijn of een intermediair die het systeem gebruikt. De constructie van een specifiek DSS Een specifiek DSS kan direct met behulp van de gereedschappen worden ontwikkeld. Een in de meeste gevallen efficiëntere manier voor het ontwikkelen van een SDSS is het gebruik van een DSS-generator. Een DSS-generator maakt het mogelijk op een vrij eenvoudige wijze een eerste versie, oftewel een prototype40, van een SDSS af te leveren. Ervaringen met het gebruik van dit prototype kunnen aanleiding zijn tot het doorvoeren van wijzigingen. Deze wijzigingen hebben betrekking op het verbeteren van fouten, het aanpassen van het systeem aan nieuwe wensen etc. Benbasat en Nault (1990) concluderen op basis van diverse empirische onderzoeken: ‘DSS usage is higher, and user satisfaction, attitudes, and perceptions are more favorable when prototyping and iterative design are used.’

3.4.3 Componenten van een DSS-generator Een DSS-generator wordt vaak beschreven als een systeem bestaande uit drie componenten. Een methodenbank, een databank en een gebruikersinterface. Een specifiek DSS bezit in veel gevallen dezelfde drie componenten. Gebruikersinterface De gebruikersinterface is van belang voor de interactie tussen de gebruiker en het systeem. De gebruikersinterface is hierdoor van grote invloed op de acceptatie van het systeem. Als de gebruiker een beeldschermopbouw herkent zal de kans op acceptatie van het systeem groter zijn. Deze herkenning wordt gerealiseerd door bijvoorbeeld overeenkomsten na te streven tussen het beeldscherm en de daarvoor gebruikte formulieren. Bennett (1983) beschrijft de interactie tussen de computer en de gebruiker van de generator aan de hand van drie zaken, die richtlijnen geven bij het construeren van een user-interface: • What the user sees. Hetgeen de gebruiker op het beeldscherm ziet is bepalend voor de interactie en het gebruik van het systeem. Het beeld bepaalt de context van de interactie. De kwaliteit van deze interactie zal bepaald worden door de overeenkomsten tussen de context en de ervaringen van de gebruiker. Als de context goed overeenkomt en herkenbaar is, zal de gebruiker de informatie herkennen en weten welke acties uit te voeren. • What the user has to know. 40 Zie hoofdstuk 4 voor een uitgebreide beschrijving van prototyping.


•

61

De gebruiker moet een zekere kennis hebben om de getoonde informatie te begrijpen en te interpreteren en om op basis van deze informatie een specifiek DSS te kunnen bouwen. Voor de bouw van een SDSS moet de gebruiker in elk geval enige kennis hebben van de in de generator beschikbare methoden. What the user can do. Wat kan de gebruiker doen in het gebruik van het systeem? Bij de beantwoording van deze vraag is het van belang te weten welke functies en commando's beschikbaar zijn en hoe eenvoudig het is hulpschermen op te roepen.

De gebruikersinterface is voor een groot deel bepalend voor de gebruiksvriendelijkheid van het systeem. De gebruiksvriendelijkheid wordt in deze paragraaf besproken omdat deze met name onder invloed staat van de gebruikersinterface41. Voor een deel is de gebruiksvriendelijkheid afhankelijk van softwarematige aspecten. Voor een ander deel is de gebruiksvriendelijkheid afhankelijk van de hardware waarop en de omgeving waarbinnen het systeem wordt gebruikt. Factoren die de gebruiksvriendelijkheid beïnvloeden zijn (Kendall en Kendall 1992, Davis en Olson 1985, Sprague en Carlson, 1982): • de dialoog • het schermontwerp • de gebruikersinterface • de responsietijd • de feedback • de ergonomie Het gebruiksgemak van een systeem staat ondermeer onder invloed van de manier waarop de dialoog tussen de gebruiker en het systeem inhoud is gegeven. Mogelijke invullingen van deze dialoog zijn: natuurlijke taal interfaces, vraag en antwoord interfaces, menu’s, invoeren uitvoerformulieren en commando interfaces. Verder wordt het gebruiksgemak bepaald door de manier van bediening. Was tot voor kort het toetsenbord de enige manier om interactief met de computer om te gaan, de laatste tijd worden steeds meer systemen ontwikkeld die met de muis, een lichtpen, een touch-screen of zelfs met spraakherkenning kunnen worden aangestuurd. Coll et al. (1994) onderzoeken de snelheid van werken met, het aantal fouten door en de voorkeur voor de verschillende vormen van besturing. Zij concluderen dat met de muis werken sneller is dan werken met een lichtpen of het toetsenbord. Daarnaast concluderen zij echter dat het gebruik van het toetsenbord minder fouten oplevert. De participanten van het onderzoek zeggen de muis voor algemeen gebruik te prefereren. Een computerscherm dient zodanig ontworpen te zijn dat het relevante informatie op een heldere wijze weergeeft. Davis en Olson (1985) beschrijven twee richtlijnen voor het ontwerpen van een scherm: (1) geef alleen gegevens weer die essentieel zijn 41 De in deze paragraaf besproken aspecten van de gebruiksvriendelijkheid zijn ook van toepassing op de andere in dit hoofdstuk besproken systemen zoals kennissystemen en executive information systems.

62

Hoofdstuk 3

voor het nemen van die beslissing of het uitvoeren van die specifieke actie, en (2) geef alle relevante informatie op één scherm weer. Verder beschrijven zij richtlijnen als: plaats items bij elkaar die logisch samenhangen, plaats de items in een logische volgorde, plaats belangrijke items meer naar boven en meer naar links op het scherm en laat voldoende ruimte tussen de afzonderlijke items zodat de items duidelijk gescheiden blijven. De manier van interactie wordt in de jaren negentig steeds meer gedomineerd door de zogenaamde ‘Graphical User Interfaces’ (GUI). Microsoft Windows en XWindows zijn voorbeelden van deze GUI’s. De GUI’s zorgen voor een belangrijke standaardisatie van de interactie tussen de gebruiker en het systeem. Diverse soorten programma’s hebben vergelijkbare menustructuren, dialoogvensters etc. Met behulp van de muis, menu’s en drukknoppen geeft de gebruiker commando’s aan de computer. Het aanleren van een nieuw programma, dat dezelfde interface-conventies naleeft, zal veel sneller verlopen42. De mate van gebruiksvriendelijkheid en dan met name de mate van ergernis, wordt voor een groot deel beïnvloed door de responsietijd van het systeem. De wachttijden mogen niet te hoog oplopen en moeten met name consistent zijn. Het consistent zijn betekent dat opdrachten met een soortgelijke complexiteit een vergelijkbare responsietijd dienen te hebben (Davis en Olson, 1985). Indien de responsietijd meer dan een aantal seconden bedraagt, moet de gebruiker in ieder geval feedback krijgen dat de opdracht in uitvoering is genomen. Een gebruiker heeft behoefte aan feedback tijdens het werken met de computer. De gebruiker moet weten dat de invoer juist is verwerkt of dat de computer bezig is een opdracht uit te voeren. Kendall en Kendall (1992) onderscheiden 7 typen van feedback. Het bevestigen van invoer door het afbeelden van de invoer op het scherm, het bevestigen van correcte invoer (b.v. ‘Ready’), het geven van een foutmelding bij onjuiste invoer, het aangeven van een bewerking (b.v. ‘Wait’), het bevestigen van het afronden van een bewerking (b.v. ‘Done’), het geven van een foutmelding indien een opdracht niet kan worden uitgevoerd en tenslotte het beschikbaar stellen van meer gedetailleerde hulpinformatie (b.v. ‘Assist’). De ergonomie van een systeem wordt niet door softwarematige aspecten bepaald. De ergonomie wordt beïnvloed door de hardware zoals het beeldscherm, het toetsenbord, de ruimtelijke opstelling van beide, de verlichting van de kamer, het meubilair etc. Methodenbank Een tweede component van een DSS wordt gevormd door de methodenbank (Brennan en Elam, 1986). Deze bank bevat methoden waarmee bepaalde problemen conceptueel kunnen worden gemodelleerd. Met de gegevens uit de databank kunnen de conceptuele modellen empirisch worden gemaakt en kan met die modellen worden geëxperimenteerd. Bekende voorbeelden van methoden in DSS-generatoren 42 Hertogs en Helms (1995) beschrijven een onderzoek door een Amerikaans adviesbureau waaruit blijkt dat bij mensen die met Windows werken gevoelens van frustratie en vermoeidheid in vergelijking met niet grafische interfaces zijn gehalveerd. Daarnaast konden de proefpersonen sneller en beter omgaan met voor hen onbekende programma’s.


63

zijn: lineair programmeren, simulatie en statistische analyses. De beslisser moet zelf kiezen op grond van de kenmerken van het probleem of de situatie, welke methode in een bepaalde situatie moet worden toegepast. Databank De derde component van een DSS is de database oftewel databank (Garnto en Watson, 1986). De databank bevat gegevens die de beslisser kan opvragen of die kunnen worden gebruikt voor het opstellen en doorrekenen van modellen. De gegevens uit de databank kunnen uit verschillende bronnen afkomstig zijn. Zowel gegevens van binnen de organisatie als gegevens van buiten de organisatie kunnen voor het nemen van beslissingen van belang zijn. Het probleem hierbij is dat de vereiste gegevens niet altijd beschikbaar zijn in de transactie-database. De gegevens zoals de tussenaankomsttijden in geval van een simulatiemodel zullen afzonderlijk moeten worden verzameld en vastgelegd. Het uitvoeren van zoekacties en selecties op databases kan een groot beslag leggen op de capaciteit van het systeem. Om de normale verwerkingen, die gebruikmaken van de database, niet te vertragen kan een speciale database voor de DSS worden ontwikkeld en onderhouden. Hierbij moet men wel organisatorische maatregelen treffen teneinde te waarborgen dat de DSS-database een getrouwe afspiegeling van de overige databases vormt. 3.4.4 DSS en beslissingsprocessen Een SDSS is gericht op het ondersteunen van een beslissingsproces van de beslisser. De beslisser behoudt een doorslaggevende rol bij het nemen van beslissingen. Het SDSS kan, zoals hiervoor reeds is beschreven, één of meerdere fasen van het beslissingsproces ondersteunen. De beslisser maakt gebruik van de beschikbare methoden en gegevens, maar vult zelf het beslissingsproces in. Hofstede (1992) beschrijft het beslissen met behulp van een DSS aan de hand van een aantal geschakelde niveaus (zie Figuur 3-5). Figuur 3-5 suggereert dat de informatie over de omgeving en over het probleem wordt gefilterd door de persoons- en managementcontext. Op dezelfde wijze wordt de gevonden oplossing gemanipuleerd door de management- en persoonscontext. In de management- en persoonscontext wordt de oplossing gemanipuleerd omdat het model zoals opgenomen in het SDSS bepaalde aspecten buiten beschouwing laat. Het model abstraheert bepaalde persoonlijke aspecten, zoals persoonlijke voorkeuren en doelstellingen en bepaalde management aspecten, zoals de samenhang met en invloed op andere beslissingen. Uit de figuur blijkt dat de persoonscontext het meest dominant is. De beslisser bepaalt welke informatie wordt gebruikt en neemt de uiteindelijke beslissing.

64

Hoofdstuk 3 Environment Personal context (learning, goals, attitudes) Management context (objectives, other problems) Problem context as Information supported by DSS

adopted solution

Real problem

Figuur 3-5 : Probleemoplossen met behulp van een DSS. Het model van Hofstede van het probleemoplossen met behulp van een SDSS geeft geen volledige beschrijving van het gebruik van een SDSS. Bij het gebruik van een SDSS moet een beslisser zelf het model invullen. Hij bepaalt zelf welke methoden in welke samenhang worden toegepast en welke gegevens hierbij een rol spelen. Hierbij spelen eigen beslissingsregels een rol. De ‘problem context as supported by DSS’ in Figuur 3-5 kan in dat geval niet worden gezien als een losstaande component waarover de persoonlijke en management context worden geschoven. Er is een interactie tussen de diverse componenten, inclusief de omgeving. Het model van Hofstede is wellicht beter toepasbaar op het gebruik van generieke Decision(zie volgende paragraaf). In dergelijke systemen wordt een conceptueel model aangeleverd waarna de beslisser het model empirisch maakt en bepaalde beslissingen kan evalueren. In deze situatie bepaalt de beslisser welke informatie hij al dan niet wil gebruiken en de beslisser kan het systeem ‘overrulen’ indien de uitkomsten niet bevallen. Bij het aanleveren van een model door een Executive Information System (zie paragraaf 3.6) kan ook worden gesproken over ‘a problem context as supported by the system’. Het model bepaalt de probleemcontext. Onderzoeken met betrekking tot de effecten van het gebruik van decision support systemen leveren geen eenduidige conclusies op. Benbasat en Nault (1990) beschrijven een groot aantal empirische onderzoeken waarvan sommige verbeteringen laten zien door het gebruik van DSS en andere onderzoeken geen verschillen tonen tussen gebruikers die wel of niet worden ondersteund. Benbasat en Nault (1990) noemen als mogelijke oorzaken van deze tegenstrijdige conclusies: het verschil in de mate van ondersteuning die door het DSS wordt geboden, de complexiteit van het gebruik van het DSS, gebrek aan toetsen om de kwaliteit van het DSS vast te stellen en tenslotte een verschil in training van de DSS gebruikers. Daarnaast geldt dat verschillende onderzoeken de effecten van het DSS gebruik op zeer uiteenlopende manieren hebben geoperationaliseerd. In de meeste onderzoeken


65

wordt uitsluitend gekeken naar de uitkomsten, bijvoorbeeld de winst of de tijd die men nodig heeft voor het nemen van een beslissing. Het beslissingsproces wordt niet geëvalueerd. Benbasat en Nault (1990) stellen dan ook: ‘It is ironic that even though the fundamental studies in this field have placed emphasis on understanding the influence of computerized support on changes in decision processes, few Management Support System studies that examine these relationships have emerged.’

Het gebruik van een DSS hoeft echter niet uitsluitend te zijn gericht op het totstandkomen van kwalitatief betere beslissingen. Keen (1986) noemt behalve dit voordeel nog elf andere: het groter aantal alternatieven dat wordt bekeken, een beter begrip van de organisatie en de omgeving, een snellere response op onverwachte omstandigheden, ad-hoc analyses, nieuwe inzichten, een betere communicatie, een betere beheersing, kostenbesparingen, effectief groepswerk, tijdbesparingen en tenslotte een beter gebruik van beschikbare gegevens. Uit deze opsomming blijkt dat betere beslissingen slechts één van de mogelijke voordelen is. Alter (1992) pleit ervoor de hele discussie over decision support systemen en de hieraan gerelateerde begrippen en definities aan de kant te schuiven en zich weer te concentreren op datgene dat echt essentieel is, namelijk het verbeteren van de beslissingsprocessen. De activiteiten van mensen moeten als uitgangspunt worden genomen bij het bestuderen van beslissingsprocessen. Alter classificeert informatiesystemen aan de hand van de mate waarin het systeem de manier van werken bepaalt (als hulpmiddel, voorschrijvend of als vervanging van de mens) en het niveau van coördinatie (individu, groep, organisatie) dat het systeem ondersteunt. Alter (1992) concludeert: ‘Instead of starting by saying we are going to study DSS, we should start by saying we are going to study ways to improve decision making. This will focus attention on what is important, will eliminate wasted effort distinguishing between overlapping and poorly defined types of systems, and may lead to more applicable results.’

Alter benadrukt de beslissingsprocessen, maar deze processen kunnen vanuit een groot aantal gezichtspunten worden bestudeerd. Iedere discipline benadrukt en bestudeert bepaalde zaken van het beslissingsprobleem. Men zal binnen een discipline dus wel moeten aangeven welke zaken worden bestudeerd. Binnen de informatiekunde zal de nadruk liggen op faciliteiten om deze beslissingsprocessen te ondersteunen. Daarbij zal naar de mogelijkheden van decision support- en expertsystemen worden gekeken. Deze systemen moeten niet om het systeem zelf worden gebruikt, maar omdat een dergelijk systeem een goede ondersteuning biedt in een specifieke situatie (zie Paragraaf 3.7.1 voor een beschrijving van de toepasbaarheid van beide categorieën van systemen).

66

Hoofdstuk 3

3.4.5 Generieke decision support systemen Naast de hiervoor beschreven categorieën van decision support systemen onderscheidt Stegwee (1992) generieke decision support systemen (GDSS43). Dergelijke generieke systemen zijn gericht op een klasse van gelijksoortige problemen. Met die gerichtheid onderscheidt een GDSS zich van een SDSS, gericht op een specifiek probleem en een specifieke beslisser, en een DSS-generator, gericht op een grote verzameling van mogelijke problemen. Door dit verschil in toepasbaarheid van een generieke DSS zal ook het ontwikkelingsproces anders verlopen. Stegwee (1992) splitst de ontwikkeling van een generieke DSS in een aantal stappen. De ontwikkeling van een generieke DSS moet daarbij duidelijk onderscheiden worden van het daaropvolgende gebruik van het generieke DSS. Net als bij een SDSS geldt dat een GDSS op verschillende manieren kan worden geconstrueerd. Een GDSS kan rechtstreeks met behulp van de benodigde tools worden ontwikkeld (zie paragraaf 3.4.2 voor een beschrijving van deze tools). Daarnaast bestaat de mogelijkheid gebruik te maken van een generator. Ook bij een GDSS dienen faciliteiten beschikbaar te zijn voor het toegankelijk maken van databases, het gebruik van methoden en het specificeren van de interactie met de gebruiker (de database management component, de modelbase management component en de gebruikersinterface). Deze faciliteiten kunnen ter beschikking worden gesteld door een dergelijke generator. De hierna te beschrijven stappen (zie Figuur 3-6) zijn gericht op het ontwikkelen van het generieke DSS. Het uitgangspunt voor het ontwikkelen van een generieke DSS is een klasse van problemen. De eerste stap bestaat uit het waarnemen en beoordelen van een voorbeeldprobleem uit een dergelijke klasse. Vervolgens wordt het probleem op een conceptueel niveau beschreven. Hierbij worden de doelstellingen geformuleerd en het probleem beschreven. Deze fase resulteert in een conceptueel model van de probleemklasse. Dit conceptuele model wordt vervolgens ondergebracht in een computerprogramma, het generieke DSS. Na de constructie van het generieke DSS moet dit systeem worden getest. Hiertoe wordt een experimenteel model opgesteld. Dit experimentele model is een empirische beschrijving van één probleem uit de gedefinieerde probleemklasse. Het experimentele model is een empirisch model. De term experimenteel geeft echter aan dat het een beschrijving van een fictieve case betreft. Gegeven de kenmerken van dit specifieke probleem wordt het generieke DSS omgezet in een experimenteel SDSS. Dit SDSS biedt een beschrijving van het experimentele probleem en kan worden gebruikt binnen het beslissingsproces. Door het gebruik van dit specifieke DSS wordt de functionaliteit van het generieke DSS getest. Als het specifieke DSS de verschillende testen doorstaat, leidt dit tot de acceptatie van het generieke model. Afwijzing van het specifieke DSS kan aanleiding zijn tot het opnieuw doorlopen van één van de voorgaande fasen. 43 Niet te verwarren met Group Decision Support Systemen. ‘A Group DSS aims to improve the process of group decision making by removing common communication barriers, providing techniques for structuring decision analysis, and systematically directing the pattern, timing or content of discussion’ (DeSanctis en Gallupe, 1987). Zie voor meer informatie over Group DSS, Gallupe en DeSanctis (1988), Watson et al. (1988), Dickson et al. (1993).


Problem Class

67

Observation and assesment of problem instance Formulation of objectives and description of problem instance

Conceptual model

Transformation of conceptual model into generic dss

Generic DSS

Testing of the generic DSS Construction of experimental model

Experimental model

Transformation of generic DSS into specific DSS

Experimental SDSS

Testing of specific DSS

Accepted Generic DSS

Figuur 3-6: Ontwikkeling van het generieke DSS 3.4.6 Generieke DSS en beslissingsprocessen. De vorige paragraaf heeft uitsluitend betrekking op het construeren van het generieke DSS. Voor het ondersteunen van specifieke beslissingen dient het generieke DSS verder te worden ingevuld. Nadat het generieke DSS is ontwikkeld kan het systeem bij problemen uit de probleemklasse worden toegepast. Gegeven het conceptuele model zoals dat in het generieke systeem is ondergebracht wordt een empirisch model voor de specifieke probleemsituatie geconstrueerd. Met behulp van dit empirisch model wordt het generieke DSS omgezet in een SDSS gericht op een specifiek probleem. Het empirisch model dient geverifieerd te worden. Het gebruik van dit SDSS kan betrekking hebben op één of meerdere fasen van het beslissingsproces. Het empirisch model kan worden gebruikt bij de probleemherkenning, de probleembeschrijving, het genereren en evalueren van alternatieven en tenslotte het kiezen van één van de alternatieven.

68

Hoofdstuk 3

3.5 Kennissystemen De vierde categorie van systemen betreft kennis- of expertsystemen. Deze systemen vormen een deel van het onderzoeksgebied van de Artificial Intelligence (AI). Minsky definieert AI als: ‘AI is the science of making machines do things that would require intelligence if done by man.’

Andere onderzoeksgebieden binnen de AI zijn onder andere natuurlijke taalsystemen, patroonherkenning en robots (Nebendahl, 1988). Een expertsysteem44 wordt door Feigenbaum (1982)45 gedefinieerd als: ‘an intelligent computer program that uses knowledge and inference procedures to solve problems that are difficult enough to require significant human expertise for their solution.’

Wanneer een onderscheid tussen expert en kennissystemen wordt gemaakt, is dit vaak op basis van de bron van de kennis waarop het systeem is gebaseerd46. Indien de kennis afkomstig is van een menselijke expert wordt gesproken over een expertsysteem. Als de kennis van meerdere bronnen afkomstig is, spreekt men van een kennissysteem (Puppe, 1993). Naast de menselijke expert kunnen bijvoorbeeld documenten als kennisbron worden gebruikt. In de loop der tijd zijn systemen ontwikkeld in diverse toepassingsgebieden47. In kennissystemen wordt kennis over een specifiek domein gerepresenteerd. Uit deze voorgaande zin mag niet worden geconcludeerd dat in andere informatiesystemen geen kennis wordt vastgelegd. Wel geldt dat de aard van de gemodelleerde kennis in kennissystemen anders is. Kennissystemen maken een scheiding tussen de kennis waarmee wordt geredeneerd, de kennisbank, en het mechanisme dat met deze kennis redeneert, het redeneermechanisme (Lucas en van der Gaag, 1988). Schuwer en Kusters (1990) stellen dat deze scheiding de volgende logische stap was na de scheiding tussen systeem-software en bewerkings-software en de daaropvolgende scheiding tussen gegevens en applicaties. De AI was in de beginjaren met name gericht op het redeneren. Een voorbeeld van onderzoek uit deze periode is de General Problem Solver. In de daaropvolgende periode kwam men tot de constatering dat het vastleggen van veel domeinkennis nodig is voor het nabootsen van het gedrag van experts (Simon, 1991). Simon (1991) stelt:

44 Zie Oldenkamp (1993) voor een aantal definities van kennissystemen. 45 In Grant (1986) 46 Schuwer en Kusters (1990) definieren het onderscheid op basis van de prestatie van het systeem: ‘Onder een expert systeem wordt vaak een kennissysteem verstaan met prestaties vergelijkbaar met die van een menselijke expert.’ 47 Zie bijvoorbeeld De Witte en Kwee (1987a, 1987b, 1988) voor toepassingen in de medische wereld, het onderwijs en industie en Mertens et al. (1988) voor diverse toepassingen binnen organisaties.


69

‘In general, we need to have some combination of inferencing capability and knowledge, and every expert system makes provision for that.’

De scheiding tussen kennis en het redeneermechanisme biedt de mogelijkheid op basis van één en hetzelfde redeneermechanisme meerdere kennissystemen te implementeren. Wanneer de kennisbank wordt vervangen door een kennisbank met de kennis uit een ander kennisdomein ontstaat een kennissysteem voor een ander probleemgebied. Hoewel een redeneermechanisme voor meerdere toepassingen kan worden gebruikt, zijn er wel verschillende inferentiestrategieën denkbaar. De kennissysteemschil moet wel over de geschikte inferentiestrategie beschikken. Hieruit kan worden geconcludeerd dat één en hetzelfde inferentiemechanisme kan worden gebruikt voor meerdere kennissystemen, maar dat hierbij wel de voorwaarde geldt dat het inferentiemechanisme over de juiste redeneerstrategieën beschikt. Er is dus wel degelijk een samenhang tussen het probleemgebied en het inferentiemechanisme. 3.5.1 Componenten van een kennissysteem Een kennissysteem is opgebouwd uit een aantal componenten. Deze componenten zijn: de systeeminterface, de gebruikersinterface, het redeneermechanisme en de kennisbank. Een kennissysteemschil voor het ontwikkelen van een kennissysteem bevat daarnaast een ontwikkelaarsinterface. De samenhang tussen de verschillende componenten is in Figuur 3-7 weergegeven.

Systeem Interface

Gebruikers

Redeneer

Ontwikke-

Interface

mechanisme

laars Interface

Kennis Bank

Figuur 3-7: Kennissysteemschil Een kennissysteem bestaat uit alle in Figuur 3-7 genoemde componenten behalve de ontwikkelaarsinterface. Een kennissysteemschil bevat alle componenten behalve de kennisbank. De schil biedt faciliteiten voor het ontwikkelen van een kennissysteem en het daaropvolgende gebruik van het ontwikkelde systeem. Ontwikkelaarsinterface Om een kennissysteem te ontwikkelen is met name de ontwikkelaarsinterface van belang. Deze biedt een editor of een menugestuurde interface waarmee de

70

Hoofdstuk 3

systeembouwer de diverse facetten van een kennissysteem, zoals bijvoorbeeld de produktieregels, kan ontwikkelen. In een editor kan de ontwikkelaar de regels intypen waarbij hij zich aan een bepaalde syntax moet houden. Via menu's kunnen regels worden geconstrueerd door de commando's, syntax-woorden, objecten en kenmerken uit lijsten te selecteren. De ontwikkelaarsinterface maakt geen deel uit van het uiteindelijke kennissysteem. Deze interface is alleen van belang tijdens de constructie van het systeem. Kennisbank Om een kennissysteem in staat te stellen te redeneren met kennis over een specifiek domein moet deze kennis op één of andere manier worden vastgelegd. In de loop van de tijd zijn een aantal kennisrepresentatietechnieken ontwikkeld. In de beginfase van het gebruik van expertsystemen lag de nadruk op produktieregels voor het modelleren van kennis. Een bekend voorbeeld van een dergelijk systeem is MYCIN (Buchanan en Shortliffe, 1985). Andere manieren voor het vastleggen van kennis zijn frames, scripts en semantische netwerken. Kennis wordt ontwikkeld door training en ervaring. Klein en Methlie (1990) maken het onderscheid tussen ‘deep’ en ‘shallow knowledge’. De ‘shallow knowledge’ bestaat uit allerlei vuistregels en ‘short cuts’ om tot een oplossing te komen. De ‘deep knowledge’ is gebaseerd op theorieën, axioma’s en wetmatigheden die de onderliggende samenhang beschrijven. Het beschrijven van de ‘shallow knowledge’ leidt tot een systeem dat vergelijkbaar is met de redenering van een expert op basis van zijn heuristieken. Het vastleggen van de shallow knowledge heeft echter tot gevolg dat de kennis is gericht op een specifiek probleemgebied. Het toepassingsgebied van het kennissysteem is daardoor beperkt. Veel expertsystemen zijn met name gebaseerd op de ‘shallow knowledge’. Volgens Simon (1986) kan dit op twee manieren worden uitgelegd: ‘You can draw two kinds of conclusions from that. One is that we are going to have to go a long way in deepening these systems. The other conclusion you might draw, and I think in considerable measure a valid conclusion, is that we are sometimes kidding ourselves about how deeply modeled is the situation human beings use in order to solve problems.’

Het vastleggen van kennis is niet voldoende. Deze kennis moet vervolgens worden toegepast, er moet met de kennis worden geredeneerd. De wijze van redeneren is afhankelijk van de kennisrepresentatietechniek. Met regels wordt anders geredeneerd dan met frames of semantische netwerken. Wel geldt dat in veel gevallen een vertaalslag mogelijk is van de ene representatietechniek naar de andere. Produktieregels Kennis kan worden vastgelegd in zogenaamde produktieregels (zie paragraaf 2.4.4. voor een beschrijving van regelmodellen waarin dergelijke regels worden gemodelleerd). Dit zijn regels met een zogenaamde ‘if.. then ..’ structuur. Als aan de voorwaarden van een regel is voldaan, dan mogen de conclusies worden getrokken. Regels representeren kleine losstaande stukjes kennis. Dergelijke losstaande stukjes kennis worden ‘chunks’ genoemd (Giarratano en Riley, 1989). Een voordeel van de


71

regel-representatie is dat de regels makkelijk zijn te interpreteren. Daarnaast kan ook het redeneerproces duidelijk worden gevolgd doordat is vastgelegd aan welke voorwaarden moet zijn voldaan om een regel uit te voeren. De samenhang tussen de regels wordt echter niet expliciet gemodelleerd. Het inferentiemechanisme brengt een samenhang tussen de regels aan. Agarwal en Tanniru (1992) stellen: ‘Conventional programming languages exhibit low transparency (i.e. an individual line of code provides little information about the program’s overall functionality) and high behavior visibility (i.e. the sequence of code execution can be determined easily). Rule based formalisms, on the other hand, exhibit high transparency (each rule provides information about its logical context) and extremely low behavior visibility (the sequence of rule firings is difficult to determine a priori).’

Semantische netwerken In een semantisch netwerk wordt de betekenis van een object beschreven door de relaties met andere objecten weer te geven. Fysieke of abstracte objecten of concepten worden in knooppunten weergegeven. De relaties tussen deze knooppunten geven de aard van de relatie tussen de objecten weer. Bekende relaties hierbij zijn 'has-a' voor het beschrijven van het feit dat een object een bepaald kenmerk bezit en 'is-a' voor het feit dat een object gerekend mag worden tot een ander objecttype. Naast deze twee vaak gebruikte relaties kunnen allerlei andere relaties worden toegevoegd. De relaties worden in een netwerk gespecificeerd. Men noemt deze netwerken semantische netwerken. Semantische netwerken bieden een goede mogelijkheid om associaties vast te leggen. Deze associaties kunnen verschillend van aard zijn. De aard van de samenhang wordt met behulp van de naamgeving van de pijlen aangegeven. Scripts Scripts worden gebruikt om de opeenvolgingsrelaties van activiteiten en gebeurtenissen in situaties te beschrijven. In veel situaties bezit een mens kennis over de 'normale' gang van zaken. Een script helpt bij het doorgronden en interpreteren van een situatie en geeft richtlijnen hoe te handelen in die situatie (Gioia en Poole, 1984). Luger en Stubblefield (1989, pag. 363) omschrijven een script als: ‘a structured representation describing a stereotyped sequence of events in a particular context.’

Een script bestaat uit een aantal componenten: • De ingangscondities beschrijven de eisen waaraan voldaan moet zijn voordat een script van toepassing is. • De resultaten beschrijven de veranderde feiten nadat een script is uitgevoerd. • De 'props' beschrijven de objecten en subjecten die in het script een rol spelen.

72

Hoofdstuk 3 • Subjecten in een script spelen een bepaalde rol. • Een script kan tenslotte bestaan uit een aantal scènes. Een scène vormt een afgebakend stuk uit een script.

Het bekendste voorbeeld van een script is het restaurantscript van Schank en Abelson (1977). Schank, die het script in de jaren zeventig introduceerde, beschrijft hierin de normale gang van zaken vanaf het moment dat een klant een restaurant binnenkomt tot aan het afrekenen en vertrek van deze klant. Op basis van een script kan geredeneerd worden over een specifieke situatie door deze te vergelijken met de standaardpatronen. Als bepaalde gebeurtenissen zich hebben voorgedaan kan met grote waarschijnlijkheid worden geconcludeerd dat de daaraan voorafgaande gebeurtenissen ook hebben plaatsgevonden. Als in het restaurantscript iemand het restaurant na betalen verlaat kan hieruit worden afgeleid dat deze persoon hiervoor een bestelling zal hebben geplaatst, zijn maaltijd geserveerd zal hebben gekregen en deze maaltijd waarschijnlijk zal hebben opgegeten. Frames Net als scripts is het doel van frames de samenhang tussen kennis te modelleren. Zodoende kan ‘common knowledge’ in een structuur worden vastgelegd. In het voorbeeld op de volgende pagina is aangegeven dat een vogel vliegt. Door deze ‘common knowledge’ op een hoog niveau in de framestructuur vast te leggen hoeft deze kennis niet bij elke soort vogel of elke individu te worden vastgelegd. Het verschil tussen scripts en frames is dat scripts tijd- c.q. volgordegebonden zijn. Binnen de databasewereld is het gebruikelijk de werkelijkheid te beschrijven aan de hand van objecttypen, objecten en kenmerken. Een objecttype definieert een klasse van objecten. Objecten worden binnen de AI-wereld vaak als frames aangeduid. Kenmerken van objecten worden hierbij als 'slots' aangemerkt. Alle informatie die betrekking heeft op een bepaald concept wordt in één frame opgeslagen. Hierbij kan het onderscheid worden gemaakt tussen frames die een klasse van objecten beschrijven en frames die een individueel object beschrijven. De eerste categorie van frames worden klasse-frames genoemd en de tweede categorie instanties. De klasseframes geven een conceptuele beschrijving van de typen objecten oftewel objecttypen. Een objecttype wordt gedefinieerd door een opsomming van de kenmerken die van belang zijn voor dat type. Een instantie daarentegen beschrijft een individueel object door de waarden van de kenmerken empirisch in te vullen (zie entiteiten en objecten bij simulatiemodellen). De klasseframes worden bij het ontwikkelen van het systeem gespecificeerd. De instanties kunnen van tevoren worden gespecificeerd, maar kunnen ook dynamisch tijdens het gebruik van het systeem worden gecreëerd, gebruikt en eventueel weer worden verwijderd. Bij de dynamische creatie bevat een instantie de specifieke gegevens van een object die tijdens die consultatie van belang zijn. Bij de beoordeling van een kredietaanvraag kunnen zodoende de specifieke gegevens van een klant in een instantie van het klasseframe klant worden vastgelegd.


73

Bird superclass: vertebrate reproduces by: lays-eggs covering: feathers flies: true

flightless bird

songbird

scavenger

superclass: bird

superclass: bird

superclass: bird

flies: nil

diet: bug, seeds

diet: garbage, carion

penquin

canary

sparrow

superclass:flightless bird

superclass: songbird habitat: tropical

superclass: songbird habitat: north america

habitat: southpole diet: fish

opus

tweety

instance of: penquin

instance of: songbird

Figuur 3-8: Hiërarchie van frames (Luger, 1989) Frames kunnen onderling worden verbonden door het definiëren van relaties tussen de frames. Bij de weergave van frames is het gebruikelijk uitsluitend de 'is-a' oftewel de 'is-een' relaties te specificeren. Dit in tegenstelling tot de semantische netwerken waarin een groter aantal typen relaties wordt gespecificeerd. Met de 'is-a' relatie kan worden aangegeven dat een klasse een subklasse is van een hogerliggende klasse of dat een instantie behoort tot een bepaalde klasse. De frames en de samenhang tussen de frames kunnen in een hiërarchische structuur worden weergegeven. Een dergelijke structuur wordt een frametaxonomie genoemd (Lucas en van der Gaag, 1988). De hogerliggende frames in deze structuur geven een meer algemene beschrijving van een concept. De frames, die hieronder liggen, geven een meer specifieke beschrijving. In het voorbeeld (Figuur 3-8) geeft het frame 'bird' de meest generieke c.q. algemene beschrijving van vogels, de daar onderliggende frames geven een meer specifieke beschrijving van de diverse soorten vogels. Een klasseframe beschrijft de relaties met de andere klassen en geeft aan welke kenmerken voor objecten van die klasse van belang zijn. De klassen bevatten geen feitelijke gegevens, wel kan een defaultwaarde voor een kenmerk worden gespecificeerd. De feitelijke gegevens worden opgeslagen in de instanties van klassen. Dit is te vergelijken met de recordstructuur binnen databases. De structuur geeft aan welke kenmerken van belang zijn voor een bepaald objecttype, maar bevat geen specifieke gegevens. De feitelijke gegevens worden opgeslagen in de records die individuele objecten beschrijven. Een frame in de taxonomie erft de eigenschappen van de hogerliggende frames. In het voorbeeld van Luger is in het meest generieke frame vastgelegd dat vogels

74

Hoofdstuk 3

kunnen vliegen. Alle onderliggende frames erven dit kenmerk. Dit leidt tot de conclusie dat alle vogels kunnen vliegen. Deze bewering is echter niet waar voor pinguïns en struisvogels. De verstekwaarde die van het generieke frame wordt geërfd zal op een of andere wijze teniet moeten worden gedaan. Een mogelijkheid hiertoe is het in een meer specifiek frame aangeven dat vogels, die tot die soort behoren, niet kunnen vliegen, of algemener gesteld dat de objecten die tot dat type behoren een andere waarde voor dat kenmerk bezitten. Bij de overerving wordt dan van het kenmerk in het meest specifieke frame uitgegaan om de waarde van het kenmerk van de instantie vast te stellen. Zoals in de inleiding op de verschillende kennisrepresentatietechnieken is gesteld, is er vrijwel altijd een vertaalslag mogelijk van de ene kennisrepresentatietechniek naar de andere. Puppe (1993) stelt bijvoorbeeld: ‘From a higher level, the rule based and object based representations of knowledge can be regarded as two different ways of viewing the same basic network of objects and relationships in which either the nodes or the relationships are taken to be more important.

De overerving is ook in de vorm van regels te modelleren (zie Figuur 3-9). Twee frames, waarvan één de frameklasse ‘vogels’ beschrijft met als kenmerk ‘vliegt’ met de verstekwaarde 'true' en één instantie die een individueel object beschrijft, kunnen in de vorm van regels worden gemodelleerd door gebruik te maken van de modus ponens. Deze regel werkt als volgt. De regel 'als het een vogel is dan kan het vliegen', en het feit dat de instantie een vogel is, is voldoende om daaruit te concluderen dat het vogeltje kan vliegen. Bij complexere structuren zal er een groot aantal regels nodig zijn. Bij uitzonderingsgevallen, pinguïns kunnen niet vliegen, zijn er nog meer regels nodig. In dergelijke gevallen is het handiger om deze structuur in de vorm van een frametaxonomie te specificeren zodat een beter overzicht wordt behouden. Frames

Regels

Bird if X is-a Bird then X flies

flies: true

X is-a Bird is-a X flies Tweety Instance of Bird

Figuur 3-9: Overerving versus redeneren met regels Een instantie of een klasse erft dus de kenmerken van een hogerliggende frameklasse. De voordelen om dergelijke gegevens als ‘default’-waarde in die frames te specificeren, worden beschreven door Winston (1992, pag. 183):


75

‘Shared knowledge, located centrally, is easier to construct when you write it down, easier to correct when you make a mistake, easier to keep up to date as times change, and easier to distribute because it can be distributed automatically.’

De voornaamste methode van redeneren berust dus op overerving. Naast overerving wordt frequent gebruikgemaakt van zogenaamde 'demons'. Met name de if-neededen if-added-demons worden vaak gebruikt. Demons zijn kleine procedures die worden uitgevoerd wanneer aan een bepaalde voorwaarde is voldaan. Voor de ifneeded-demon geldt de voorwaarde dat het redeneermechanisme een waarde voor het kenmerk, waarbij de demon hoort, probeert af te leiden. De if-changed-demon wordt uitgevoerd wanneer de waarde van het bijbehorende kenmerk verandert. Hybride kennisrepresentatievormen; produktieregels en frames Regels en frames als kennisrepresentatietechniek hebben beide hun sterke en zwakke punten. Beslissingsregels kunnen op een vrij directe wijze worden omgezet in produktieregels. De beslissingsregels van een expert kunnen op een gedetailleerde manier worden beschreven. Regels geven een beschrijving van opzichzelfstaande stukjes kennis. ALS aan de voorwaarden van een regel is voldaan DAN mogen de conclusies worden getrokken. Deze vorm van modelleren heeft als voordeel dat de regels afzonderlijk makkelijk zijn te interpreteren. Het redeneerproces is ook makkelijk te reconstrueren en uit te leggen, omdat een redeneerproces bestaat uit de koppeling van individuele regels. Het feit dat regels losstaande stukjes kennis beschrijven wordt vaak als argument aangevoerd voor de uitbreidbaarheid en modulariteit van kennissystemen. Het toevoegen van nieuwe kennis in de vorm van nieuwe regels heeft geen invloed op de betekenis van de bestaande regels. Dit voordeel wordt echter vaak teniet gedaan door het feit dat het overzicht over de verschillende regels verloren gaat. Agarwal en Tanniru (1992) stellen: ‘Modifications to the knowledge base often lead to unanticipated inconsistency and redundancy problems.’

Gebleken is dat bepaalde omvangrijke regel-gebaseerde systemen niet meer te onderhouden zijn, maar totaal opnieuw moeten worden ontwikkeld (O’Neal en Edwards, 1994). In een omvangrijk systeem kan de samenhang tussen de regels erg ondoorzichtig worden. Puppe (1993) spreekt dan ook over ‘rule spaghetti’. Het toevoegen van regels kan tot ongewenste neveneffecten leiden. Dit geldt met name wanneer de selectie van regels uit de 'conflictset' is gebaseerd op de volgorde van de regels in de kennisbank, of op de volgorde waarin de regels in het systeem zijn ingevoerd48. Deze selectiemethode kan onverwachte neveneffecten hebben. Dit geldt 48 O’Neal en Edwards (1994) laten door middel van een experiment zien dat de inzichtelijkheid van een regelbank mede wordt bepaald door de volgorde waarin de regels worden gepresenteerd. Door het gegroepeerd weergeven van samenhangende regels neemt de inzichtelijkheid toe. In hoeverre de regels gegroepeerd kunnen worden weergeven is afhankelijk van de mogelijkheden die de expert system shell hiertoe biedt.

76

Hoofdstuk 3

met name wanneer naast het afleiden van feiten tevens acties in de conclusies worden uitgevoerd. Door een 'verkeerde' oftewel niet goed overwogen volgorde kunnen externe programma's onnodig vaak worden aangeroepen of er worden onnodige vragen aan de gebruiker gesteld. De ene regel kan op een efficiëntere manier naar een conclusie leiden dan een andere regel. Efficiënt heeft hier met name betrekking op het aantal malen dat een extern programma wordt aangeroepen of het aantal malen dat een vraag aan de gebruiker wordt gesteld. Het onnodig aanroepen van externe programma’s of het stellen van te veel vragen aan de gebruiker verhoogt de irritatie bij de gebruikers en verhoogt daarmee de kans op afwijzing van het systeem. Agarwal en Tanniru (1992) beschrijven het gebruik van afhankelijkheidsdiagrammen om het overzicht te behouden over de samenhang tussen de regels. Deze ‘dependency diagrams’ zijn met name geschikt bij het onderhoud van de kennisbank, het toetsen van de inhoud van de kennisbank en het hergebruik van kennis. Regels zijn niet zozeer geschikt om gegevens van objecttypen in het bestudeerde domein weer te geven, en de samenhang tussen de objecttypen te beschrijven. Frames zijn daarentegen juist zeer geschikt om een hiërarchie van objecttypen te definiëren en de bij de objecttypen behorende kenmerken vast te leggen. Turban stelt (1988): ‘Production rules do not provide a totally effective representation facility for many ES applications. In particular, their expressive power is inadequate for defining terms and for describing domain objects and static relationships among objects.’

Frames zijn geschikt om statische kennis en statische structuren te beschrijven. Regels zijn hiernaast uitermate geschikt om (beslissings-)regels te modelleren. Juist omdat regels en frames elkaar uitstekend aanvullen zijn er diverse expertsysteemschillen ontwikkeld, die van beide kennisrepresentatietechnieken gebruikmaken (zie bijvoorbeeld Mockler (1992) en Zahedi (1993)). Turban vervolgt met (1988) ‘The frames provide a rich structural language for describing the objects referred to in the rules and a supporting layer of generic deductive capability about those objects that does not need to be explicitly dealt with in the rules. Frame taxonomies can also be used to partition, index and organize a system's production rules.’

Als de regels en frames worden samengevoegd als kennisrepresentatiemechanisme kunnen de voordelen van beide worden gecombineerd (Kowalski en Stipp, 1990). De regels hebben betrekking op de kenmerken van objecten. De verwijzing naar een specifiek kenmerk kan met behulp van een zogenaamd Object-Attribuut-Value-triple (O-A-V). Een object heeft een of meer kenmerken, en deze kenmerken kunnen een specifieke waarde hebben. In produktieregels kan op deze manier eenduidig naar de waarde van een kenmerk van een object worden verwezen. Uit het citaat van Turban (1988) blijkt dat frametaxonomieën kunnen worden gebruikt om de produktieregels te organiseren. De produktieregels bevatten


77

verwijzingen naar kenmerken van objecten, doordat in de conclusie of in de voorwaarden van een regel uitspraken over dat kenmerk zijn opgenomen. De regels kunnen dus worden gegroepeerd naar de kenmerken waarnaar verwezen wordt. Deze groepering kan een positieve invloed hebben op de inzichtelijkheid van het systeem. In frames worden al if-added- en if-changed-demons in samenhang met specifieke kenmerken van specifieke frameklassen gedefinieerd. Naast deze demons kunnen de regels ook in samenhang met deze kenmerken worden beschreven. Alle regels en procedures die naar een specifiek kenmerk verwijzen, kunnen dus worden gegroepeerd naar dat kenmerk of naar het object waartoe het kenmerk behoort. Modulaire opbouw kennisbank In de voorgaande paragrafen zijn een aantal representatievormen van kennis beschreven. De kennis in een specifiek probleemdomein kan hiermee worden gemodelleerd en opgeslagen in een kennisbank. In een specifieke probleemsituatie zal moeten worden besloten welke vorm van kennisrepresentatie het best kan worden toegepast. Een andere keuze die moet worden gemaakt heeft betrekking op het al dan niet opsplitsen van de kennisbank in meerdere modulen. Een modulaire opbouw van de kennisbank biedt, net als een modulair opgebouwd programma, enkele voordelen. Door een modulair opgebouwde kennisbank behoudt de ontwikkelaar een beter overzicht over de verschillende regels. Dit bevordert de inzichtelijkheid van de kennisbank, delen van kennis die bij elkaar horen worden in een module opgeslagen. Het behoud van het overzicht biedt voordelen bij het onderhoud van het systeem. Dit geldt voor het onderhoud bestaande uit het opsporen en verbeteren van fouten maar ook voor het onderhoud dat betrekking heeft op het aanpassen van het systeem aan nieuwe ontwikkelingen. Tenslotte heeft de opdeling nog praktische voordelen. Afzonderlijke modulen zullen minder regels bevatten. Het inferentiemechanisme hoeft dan ook minder regels te doorzoeken en te evalueren. Als gevolg hiervan zal het inferentieproces sneller verlopen. Het modulair opbouwen van een kennisbank is alleen zinvol als er duidelijk te onderscheiden deelproblemen bestaan. Of een dergelijke opsplitsing mogelijk is moet worden besloten op basis van een onderzoek naar de taak van de expert en dus de taak van het kennissysteem. Er is een aantal mogelijkheden voor het opsplitsen van een kennisbank in modulen. De systeemleer (Zie bijvoorbeeld Kramer en Smit, 1987) geeft richtlijnen voor het opsplitsen van een systeem in deelsystemen. Deze richtlijnen hebben voor een groot deel betrekking op de minimalisatie van de interactie tussen de verschillende deelsystemen. Voor kennissystemen betekent dit dat regels die op één of andere manier samenhangen, in één en dezelfde module van de kennisbank moeten worden opgeslagen. Botten et al. (1985) beschrijven vijf criteria voor het opdelen van een systeem: • maximum independence of subsystems • minimum interface complexity • minimum subsystem complexity

78

Hoofdstuk 3

• minimum overall subsystem complexity • maximum comprehensibility Een andere methode voor het opsplitsen van een kennisbank in meerdere modulen is de taakstructuur van Steels (1992). De taakstructuur wordt door Steels gedefinieerd als de opsplitsing van taken in subtaken, die vervolgens ook weer in subtaken kunnen worden opgedeeld. De taakstructuur is vergelijkbaar met de Work Breakdown Structure (WBS) zoals die binnen projectmanagement wordt gebruikt. De WBS geeft een hiërarchische ordening van de taken die binnen een project moeten worden uitgevoerd om de doelstellingen van het project te realiseren. De taakstructuur kan in de vorm van een boomstructuur worden weergegeven. Niet alle takken van een dergelijke boom, oftewel niet alle subtaken, hoeven in een specifiek geval te worden doorlopen c.q. te worden uitgevoerd. Als er een keuze bestaat tussen bepaalde takken dan kan dit worden aangegeven met de OR-operator. De taakstructuur kan vervolgens als uitgangspunt dienen bij de opsplitsing van de kennisbank in verschillende modulen. De taakstructuur verdeelt uiteindelijk de totale taak in een aantal subtaken, die in afzonderlijke modulen van de kennisbank kunnen worden opgeslagen. Gebruikersinterface De gebruikersinterface bepaalt de manier van interactie tussen de gebruiker en het systeem. De gebruikersinterface is zodoende bepalend voor de formulering van vragen aan de gebruiker, de manier waarop de gebruiker vragen kan stellen omtrent het redeneerproces of extra informatie kan krijgen omtrent de vragen van het systeem, en de presentatie van de resultaten van een consultatie. De gebruiksvriendelijkheid van het kennissysteem (zoals beschreven in paragraaf 3.4.3) staat voor een groot deel onder invloed van deze gebruikersinterface. Systeeminterface In een specifieke consultatie van het systeem worden bepaalde gegevens ingevoerd. Naast het invoeren van de gegevens door de gebruiker is het tevens mogelijk gegevens uit bijvoorbeeld een database te halen. Indien opgeslagen gegevens nodig zijn, is het niet handig de gebruiker deze op te laten zoeken en in te laten voeren in het systeem. Naast de tijd die dit kost, werkt dit ook fouten in de hand. Naast het inlezen van gegevens uit het bestand is het ook mogelijk een extern programma op te starten dat de waarden van bepaalde kenmerken vaststelt. Segev en Zhao (1994) wijzen op het feit dat kennissystemen die worden toegepast in verschillende bedrijfsfuncties in toenemende mate toegang moeten hebben tot grote databases. ‘... access to large amounts of business data is difficult because current ES technology lacks necessary data management functions, such as efficient search of disk resident data, query optimization, concurrency control, and so on. However, many business decisions must be made based on large amounts of data, and therefore, an appropriate technology is required.’

Zij beschrijven drie manieren om een database management systeem (DBMS) en een kennissysteem (KS) te integreren: (1) het opnemen van een inferentiecomponent in


79

het DBMS, (2) het uitbreiden van het KS met een DBMS-component of (3) het KS en het DBMS als twee afzonderlijke componenten voort te laten bestaan met een interface tussen beide. Segev en Zhao (1994) werken het idee van het onderbrengen van een inferentiemechanisme in een DBMS als volgt uit: regels kunnen worden gebruikt om nieuwe gegevens af te leiden uit de opgeslagen gegevens of om bepaalde (database)acties uit te voeren. Naast het toegankelijk maken van gegevens afkomstig uit andere bronnen dient de systeeminterface tevens te fungeren als koppeling met andere programmatuur. Voor de diverse subtaken van de expert en het expertsysteem kan worden onderzocht hoe een dergelijk subprobleem het best kan worden aangepakt. Bepaalde taken kunnen met behulp van een algoritme worden opgelost. Andere taken kunnen met behulp van kennistechnologie worden gemodelleerd, en weer andere taken kunnen nog steeds het best door mensen worden uitgevoerd. Met name het onderscheid tussen subproblemen die met behulp van een algoritme kunnen worden opgelost en subproblemen die met kennistechnologie worden gemodelleerd, moet expliciet worden gemaakt. In principe is het mogelijk de meeste problemen met behulp van regels te modelleren. Dit is echter niet altijd even zinvol. Subproblemen die met een algoritme kunnen worden opgelost kunnen beter met behulp van een procedurele taal, zoals C of Pascal, worden beschreven Het aanroepen van een extern programma is in veel gevallen alleen zinvol als er gegevens worden uitgewisseld tussen het kennissysteem en het externe programma. Een mogelijke oplossing is de interactie via een tussenliggend databestand te laten verlopen. Het expertsysteem schrijft de relevante waarden naar het bestand, het externe programma leest deze waarden in, voert hier enkele bewerkingen op uit en schrijft de resultaten weer terug naar het databestand. Het kennissysteem kan tenslotte deze waarden weer inlezen en het redeneerproces vervolgen. Een andere en veel fraaiere oplossing is de gegevensuitwisseling via het geheugen van de computer te laten verlopen. Hierbij is er sprake van een directe uitwisseling van gegevens via het interne geheugen van de computer. Of deze laatste vorm van uitwisseling mogelijk is, is afhankelijk van de faciliteiten die geboden worden door de expert system shell. Inferentiemechanisme In de kennisbank is de kennis omtrent een specifiek domein vastgelegd. Een van de meest gebruikte vormen van kennisrepresentatie is die van produktieregels. De regels beschrijven kleine afzonderlijke stukjes kennis. Zoals bij de beschrijving van de produktieregels is aangegeven, wordt bij het modelleren van de regels de samenhang tussen de regels niet gespecificeerd. De samenhang wordt namelijk bepaald door het inferentiemechanisme. Wil een inferentiemechanisme zinvol met regels kunnen redeneren, dan moet een bepaalde samenhang tussen de regels bestaan. De regels in een kennisbank hangen onderling samen doordat verschillende regels dezelfde kenmerken in hun voorwaarden of conclusies hebben, of doordat de conclusie van de ene regel de voorwaarde van een andere regel vormt.

80

Hoofdstuk 3

De eerste vorm van samenhang leidt tot de definitie van zogenaamde regelgroepen. Het inferentiemechanisme moet bepalen welke regel van zo'n regelgroep als eerste wordt geëvalueerd. De tweede vorm van samenhang leidt tot de vorming van ‘rule chains’. De regels worden gekoppeld doordat de conclusie van de ene regel de voorwaarde van één of meer andere regels vormt. Bij het redeneren wordt vaak de afleidingsregel Modus Ponens (Bonevac, 1990) toegepast. Als A geldt en er geldt A → B dan kan hieruit worden afgeleid dat B geldt. Deze uiterst simpele vorm kan op moeilijker problemen worden toegepast door te veronderstellen dat A uit meerdere voorwaarden bestaat en B meerdere conclusies bevat. Backward chaining De regels kunnen zowel voor voorwaarts- als achterwaarts redeneren worden gebruikt. Bij achterwaarts redeneren wordt uitgegaan van het doel, oftewel de hypothese die moet worden geëvalueerd, stel bijvoorbeeld kenmerk C. Naar alle waarschijnlijkheid bestaan er meerdere regels die de doelvariabele in de conclusie hebben, bijvoorbeeld B → C en D → C. Deze regels worden in de conflictset opgenomen, waarna een van deze regels door het inferentiemechanisme wordt geëvalueerd, stel B → C. Hiertoe wordt de voorwaarde van de desbetreffende regel bekeken. Als de voorwaarde waar is, mag de conclusie worden getrokken en is er dus een uitspraak over de doelvariabele bereikt. Als de waarheid van de voorwaarde van de regel niet bekend is kan dit leiden tot de evaluatie van andere regels die een uitspraak doen over dat kenmerk, bv. A → B. Het kenmerk in de voorwaarde, waarvan de waarheidswaarde onbekend is, wordt dan het subdoel B, waarna het inferentiemechanisme eerst de waarheidswaarde van dat kenmerk probeert vast te stellen. Op deze wijze ontstaat een keten van regels om een uitspraak te doen over de doelvariabele. Wanneer de evaluatie van een regel geen resultaat oplevert kan een andere regel in de conflictset worden geëvalueerd, D → C. Dit proces gaat door totdat een uitspraak over de doelvariabele is bereikt of totdat is gebleken dat geen waarheidswaarde kan worden vastgesteld. Forward chaining Bij voorwaarts redeneren wordt uitgegaan van een verzameling feiten. Het inferentiemechanisme probeert nieuwe feiten af te leiden door regels, die de bestaande feiten in de voorwaarde van de regel hebben, te evalueren en eventueel uit te voeren wanneer aan de voorwaarde is voldaan. Er kunnen meerdere regels zijn die een kenmerk in de voorwaarde hebben opgenomen. Deze regels worden gegroepeerd in een regelgroep. Een regelgroep wordt bij voorwaarts redeneren dus gevormd door die regels die in de voorwaarde naar dezelfde variabelen verwijzen. Het vuren van een regel kan nieuwe feiten opleveren, zodat het inferentiemechanisme regels die het nieuwe feit in de voorwaarde hebben kan evalueren. Conflict-resolution Bij voorwaarts redeneren leidt een nieuw feit tot de evaluatie van regels die dat feit in de voorwaarde hebben opgenomen. De conflictset bestaat uit alle regels die op


81

basis van een feit in de kennisbank geëvalueerd kunnen worden. Bij achterwaarts redeneren worden regels geëvalueerd die een uitspraak doen over de doelvariabele (of het tijdelijke subdoel). De conflictset bestaat in dit geval uit de regels die de doelvariabele in hun conclusie hebben opgenomen. Bij zowel voorwaarts- als achterwaarts redeneren kan de conflictset uit meer dan één regel bestaan49. Omdat niet alle regels tegelijkertijd geëvalueerd kunnen worden, zal het inferentiemechanisme een keuze moeten maken welke regel het eerst verwerkt zal worden. Vaak zal bij deze keuze een eenvoudig criterium worden toegepast, zoals de volgorde waarin de regels in de kennisbank zijn opgeslagen of de volgorde waarin de regels zijn ingevoerd. Bij gebruikmaking van één van deze selectiecriteria wordt dus expliciet naar de volgorde van de regels gekeken. Hiernaast is het ook mogelijk de volgorde van de verwerking van de regels afhankelijk te stellen van bepaalde kenmerken van de regels. Het selectiecriterium is hierbij gebaseerd op kenmerken van regels. Holsapple en Whinston (1986) noemen een aantal van deze selectiecriteria: • eerste regel in de regelset, • regel met hoogste prioriteit, • regel met de laagste kosten, • regel met de minste onbekende variabelen, • regel met de hoogste zekerheidswaarde voor de onderzochte variabele, • random volgorde. Voor het toepassen van deze selectiecriteria geldt de voorwaarde dat het inferentiemechanisme het betreffende selectiecriterium ondersteunt. Het inferentieproces wordt complexer indien er sprake is van onzekerheid. De feiten waarover een kennissysteem beschikt zijn vaak onzeker. Daarnaast bestaat de mogelijkheid dat een bepaalde conclusie niet met zekerheid op basis van de gegeven feiten kan worden getrokken. De complexiteit van het redeneren met onzekerheid heeft geleid tot een aantal uiteenlopende benaderingen. Deze benaderingen zijn: • de vage logica waarin geprobeerd wordt het redeneren met niet scherp omlijnde begrippen te representeren (Voorbraak, 1990), • de niet monotone logica als formalisering van redeneringen waarbij conclusies worden getrokken op basis van onvolledige informatie (Voorbraak, 1990), • en het redeneren met numerieke onzekerheden zoals de Bayesiaanse Methode, het certainty factor model en de Dempster-Shafer theorie (Lucas en Van der Gaag, 1988). 3.5.2 Kennissystemen en beslissingsprocessen. In kennissystemen worden de regels die worden gebruikt in het beslissingsproces expliciet gemaakt. Hierbij betreft het zowel de formele als de informele regels. De 49 Indien slechts een regel in aanmerking komt is geen sprake van een conflict, en is de term conflictset niet van toepassing.

82

Hoofdstuk 3

regels worden gemodelleerd in een regelmodel (zie hoofdstuk 2). Het gebruik van regelmodellen maakt het mogelijk de gebruiker adviezen te geven. Op basis van de gemodelleerde beslissingsregels en de probleemsituatie kan het inferentiemechanisme met een advies komen. Het inferentiemechanisme heeft hierbij de controle over het redeneerproces. Het kennissysteem kan een oplossing aandragen. Of de aangedragen oplossing daadwerkelijk wordt uitgevoerd, is afhankelijk van de mate waarin de organisatie het gebruik van het systeem heeft voorgeschreven. Het kennissysteem kan bij volledige informatie een beslissing voorschrijven. Echter, een kennissysteem beschikt vaak niet over alle benodigde kennis (hetzelfde geldt overigens voor de mens). Kennissystemen zijn gericht op een specialistisch probleemgebied en kunnen binnen dat probleemgebied worden toegepast50. De mens heeft een grotere algemene kennis en kan problemen daardoor in een breder kader en ander daglicht zien. Een kennissysteem kan dus slechts als voorschrijvend systeem worden gebruikt indien sprake is van een afgebakend probleemgebied. In andere situaties is een kennissysteem nog wel degelijk zinvol toepasbaar. Naast het voorschrijven van beslissingen kan het systeem ook worden gebruikt als adviserings- of ondersteuningsmiddel in een beslissingsproces. Dit sluit aan bij het door Bosman (1993) gemaakte onderscheid tussen de nietgestandaardiseerde-, semi-gestandaardiseerdeen gestandaardiseerde kennissystemen. Er is sprake van een niet-gestandaardiseerd kennissysteem indien de beslisser besluit van één of meer fasen van het beslissingsproces een regelmodel en daarvan afgeleid een kennissysteem te maken. De semi-gestandaardiseerde kennissystemen zijn met name gericht op het geven van adviezen. De systemen worden gebouwd door materiedeskundigen en kennistechnologen. De gebruiker heeft een grote vrijheid de adviezen van het systeem al dan niet op te volgen. De laatste categorie wordt gevormd door de gestandaardiseerde kennissystemen. De vrijheid de adviezen al dan niet op te volgen is bij deze systemen nagenoeg geheel verdwenen. Het beslissingsproces is volledig door het systeem overgenomen. Deze systemen vindt men met name in het primaire proces binnen de dienstensector. Voorbeelden van toepassingen van dergelijke systemen zijn het beoordelen van verzekeringsaanvragen, het toekennen van sociale uitkeringen etc. Er is relatief weinig empirisch onderzoek verricht naar de effecten van het gebruik van kennissystemen (Benbasat en Nault, 1990). Het vaststellen van de kwaliteit van een dergelijk systeem is meestal beperkt gebleven tot het vaststellen van de validiteit van de adviezen van het systeem. Wognum en Lippolt (1991) stellen echter dat een technisch succesvol project niet per definitie hoeft te resulteren in een operationeel systeem. Belangrijke andere succesfactoren zijn het daadwerkelijk aanpakken van een probleem, de hoogte van het budget en de beschikbare

50 Fraser et al. (1989) beschrijven een architectuur voor het integreren van expertsystemen die deelgebieden afdekken: ‘In many situations, ES will provide direct aid to a decision maker, but in more complex cases, several ES’s covering different but related knowledge will be needed’. Mogelijke inconsistenties tussen de afzonderlijke expertsystemen lossen zij op met een afzonderlijke module, de Conflit Resolver.


83

menskracht. De organisatorische aspecten en de houding van gebruikers zijn veelal meer bepalend voor het succes van een kennissysteem dan de technische factoren. Kennissystemen hebben net als decision support systemen als doel het ondersteunen van het beslissingsproces. Er zijn echter enkele duidelijke verschillen tussen beide soorten systemen. De verschillen en overeenkomsten tussen kennissystemen en decision support systemen zullen nader worden beschreven in paragraaf 3.7.

3.6 Executive Information Systemen De in de vorige paragrafen beschreven systemen richten zich met name op de uitvoerende en lagere managementniveaus in de organisatie. Topmanagers maken nauwelijks tot geen gebruik van deze systemen. Voor het niet gebruiken van deze systemen door managers is een aantal redenen aan te dragen: de aard van het werk van managers maakt het gebruik van deze systemen niet voor de hand liggend, sommige managers staan afkerig tegenover het direct werken met een computer, de technologie is moeilijk te gebruiken, en tenslotte sluiten de bestaande informatiesystemen niet aan op de informatiebehoeften van het topmanagement (Watson et al., 1991). Het topmanagement is met name aangewezen op stafmedewerkers voor het verzamelen, analyseren en presenteren van gegevens. In tegenstelling tot de andere hiervoor besproken systemen richten Executive Information Systemen (EIS) zich wel op het topmanagement. De term EIS is in 1982 geïntroduceerd door Rockart en Treacy. In de loop van de tijd is er door verschillende auteurs een groot aantal definities van een EIS opgesteld. Veel kenmerken van een EIS keren in deze definities terug. Millet en Mawhinney (1992) definiëren een EIS als een: ‘a system that integrates information from internal and external data sources enabling executives to monitor and request information of key importance to them via customized presentation formats’.

Turban (1990) definieert een EIS als: ‘a computer based system that serves the information needs of executives. It provides rapid access to timely information and direct access to management reports. It is very user-friendly, supported by graphics, and provides exceptions’ reporting and ‘drill-down’ capabilities.’

De eerste definitie benadrukt de interne en externe afkomst van gegevensbronnen. De tweede definitie benadrukt de opvraagmogelijkheden in de vorm van uitzonderingsrapportages en ‘drill-down’-mogelijkheden. Deze kenmerken in samenhang met andere in de literatuur beschreven karakteristieken van een EIS resulteren in de volgende lijst van kenmerken van een EIS (Turban, 1990; Millet en Mawhinney, 1992; Preedy, 1990; Watson et al., 1991; Rainer et al., 1992; Schenk en Holzbach, 1993):

84

Hoofdstuk 3

• Het EIS wordt direct door de topmanagers gebruikt. • Het systeem dient uitermate gebruiksvriendelijk te zijn. • ‘Drill-down’-mogelijkheden: interessante informatie kan op een gedetailleerder niveau worden bekeken. • Exception reporting: het systeem signaleert uitzonderingen die een aanwijzing kunnen zijn voor een probleem. • Trendanalyse: het systeem biedt de mogelijkheid trends te herkennen, ondermeer in de vorm van grafieken. • Het systeem biedt toegang tot interne- en externe gegevensbronnen. • Filteren en comprimeren van data en het in de loop van de tijd volgen van belangrijke grootheden. • Gegevens worden getoond in grafische, tabulaire of tekstuele vorm • Het weergeven van gegevens omtrent kritieke succesfactoren speelt een belangrijke rol. Een belangrijk kenmerk van een EIS is het toegankelijk maken van allerlei soorten gegevens. De gegevens kunnen daarbij vanuit diverse gezichtspunten worden benaderd. De gegevens kunnen bijvoorbeeld worden geselecteerd naar tijdvakken, business units, produktcategorieën etc. Deze opvraagmogelijkheden dienen bij de ontwikkeling van het EIS te worden gedefinieerd. Dit betekent dat een dergelijk systeem rigide is. Bij wijzigende informatiebehoeften zullen de ‘views’ op de data en daarmee het systeem moeten worden aangepast. Preedy (1990) onderscheidt vier mogelijke indelingen van de gegevens. 1. interne versus externe gegevens 2. historische data versus voorspelling omtrent toekomstige activiteiten 3. financiële maatstaven versus fysieke hoeveelheden 4. numerieke data versus tekstuele gegevens Een EIS biedt in principe de mogelijkheid met al deze gegevenssoorten en indelingen om te gaan. Het accent ligt echter vaak op de meer gestructureerde, routinematige gegevens zoals die uit de organisatie voortkomen. Een belangrijk onderscheid is dat tussen interne en externe informatie. De interne informatie is voor een groot deel afkomstig uit het bestaande management informatiesysteem binnen een organisatie. Een goed ontwikkeld management informatiesysteem is dan ook een essentiële voorwaarde voor het goed functioneren van een EIS (Millet en Mawhinney, 1992). Interne informatie kan ook van participanten afkomstig zijn, bijvoorbeeld in de vorm van geruchten, ideeën, voorspellingen etc. Het verkrijgen, analyseren en vastleggen van ook deze informatie is arbeidsintensief, maar vergroot de diversiteit van de informatie in het systeem (Watson et al., 1991). De externe informatie kan afkomstig zijn uit externe databases (die gekocht kunnen worden) of kan door de organisatie worden verzameld, geanalyseerd en vastgelegd. Voor acceptatie door het topmanagement moet het Executive Information System zeer gebruikersvriendelijk zijn. Houdeshel en Watson (1987) bewerkstelligen dit door de toegankelijkheid te vergroten door elke gebruiker een terminal te geven, het aantal benodigde handelingen om bepaalde gegevens op te roepen te minimaliseren en de responsietijd van het systeem zo klein mogelijk te maken. Daarnaast moet de


85

gebruikersinterface zodanig zijn opgezet dat de benodigde training voorafgaand aan het gebruik van het systeem zo klein mogelijk is. Bij de constructie van een EIS wordt veelvuldig gebruikgemaakt van programmatuur die als een generator kan worden aangemerkt. Bij het gebruik van een EIS zijn met name de communicatiefaciliteiten van groot belang. Dit betreft zowel de communicatie met de gebruiker als de communicatie met databases. De methodencomponent is binnen een EIS van minder groot belang, omdat de bewerking van gegevens beperkt is tot simpele operatoren zoals het berekenen van totalen en gemiddelden. De faciliteiten voor de communicatie kunnen ter beschikking worden gesteld door een EIS-generator. EIS-generatoren zijn in toenemende mate beschikbaar op de markt. 3.6.1 EIS in vergelijking met ESS, MIS en DSS De termen Executive Information Systems en Executive Support Systems worden vaak door elkaar gebruikt. Watson et al. beschrijven EIS als een subset van ESS. Het verschil tussen ESS en EIS komt tot uitdrukking in de volgende functionaliteit: • ondersteunen van elektronische communicatie • data-analyse mogelijkheden • tools zoals een elektronische agenda De verschillen tussen een MIS en een EIS zijn in de praktijk niet altijd even duidelijk. De functionaliteit van veel systemen die de naam EIS dragen kan ook door een MIS worden geboden (Millet en Mawhinney, 1992). Voor een EIS geldt dat het systeem niet alleen interne gegevens dient te bevatten maar ook externe. Daarnaast moet een EIS zijn gericht op een directe interactie met het topmanagement en niet alleen op het leveren van periodieke standaardrapporten. Het onderscheid tussen een DSS en een EIS is ook niet altijd even scherp. In de literatuur wordt vaak gesproken over een gegevensgericht DSS (Sprague en Carlson, 1982; Huizingh, 1995). Een gegevensgericht DSS biedt de mogelijkheid gegevens in de database te benaderen. Bij deze definitie van een gegevensgericht DSS is het verschil met een EIS beperkt tot het niveau in de organisatie waarop het systeem wordt gebruikt. Een EIS wordt direct gebruikt door het topmanagement, het DSS wordt gebruikt door analisten en stafmedewerkers. Daarnaast bestaat nog een verschil in de mate van flexibiliteit van beide systemen. Een DSS biedt de mogelijkheid de data op allerlei manieren te benaderen. Het gebruik van een EIS is vaak beperkt tot het gebruik van voorgedefinieerde gezichtspunten met betrekking tot deze data. Om het onderscheid tussen een EIS en een DSS duidelijk te maken hebben wij de term DSS gereserveerd voor systemen die niet alleen uit een databank bestaan maar ook een methodenbank omvatten. Een DSS moet de mogelijkheid bieden de beschikbare gegevens met behulp van modellen te analyseren. Het onderscheid tussen een MIS een EIS en een DSS is in Tabel 3-5 weergegeven.

86

Hoofdstuk 3

Tabel 3-5: Een vergelijking van MIS, DSS en EIS (gebaseerd op Millet and Mawhinney, 1992).

MIS DSS

EIS

Primary Purpose Internal Monitoring Support Decisions

Primary Users All Level Managers Staff and intermediaries

Primary Output Predefined periodic reports Analytic Reports and suggestions

Internal and external monitoring

Executives

Pre-defined and customized presentation

Primary Operations Summarize Information Model, solve, suggest, analyze Integrate, present and track CSF

Time Orientation Past Present Future Past Present

3.6.2 EIS en beslissingsprocessen Houdeshel en Watson (1987) stellen dat de gegevens die een EIS ter beschikking stelt van belang zijn voor het nemen van beslissingen. Het systeem vervult een rol in het beslissingsproces door problemen te signaleren en informatie omtrent deze problemen ter beschikking te stellen. Daarnaast biedt het gebruik van een dergelijk systeem indirecte voordelen, zoals een beter begrip van de informatiebehoeften. Leidner en Elam (1994) beschrijven een onderzoek naar het effect van het gebruik van een EIS op het nemen van beslissingen. Hierbij specificeren zij hypothesen omtrent de invloed van het gebruik op de snelheid waarmee een probleem wordt herkend, de snelheid waarmee een beslissing wordt genomen, en de uitgebreidheid van de analyse van het probleem (het aantal alternatieven dat wordt ontwikkeld en geëvalueerd). De mate van gebruik wordt geoperationaliseerd aan de hand van de frequentie van gebruik en de periode sinds het eerste gebruik. Leidner en Elam vinden significante positieve correlaties tussen de hiervoor genoemde beslissings- en gebruiksvariabelen. Deze positieve correlaties bevestigen de hypothesen omtrent een positieve invloed van het gebruik van een EIS op het beslissingsproces. De gevonden correlaties hebben een waarde tussen 0,31 en 0,48.

3.7 Integratie van kennissystemen en DSS Mars (1990) wijst op een trend kennissystemen te integreren met bestaande conventionele systemen51. Met name de integratie van kennissystemen en (generieke) DSS krijgt steeds meer aandacht. Kennissystemen en decision support systemen hebben beide hun voor- en nadelen. In de paragrafen 3.4.4 en 3.5.2 zijn decision support- en kennissystemen in relatie tot het beslissingsproces besproken. De verschillen en overeenkomsten zullen in paragraaf 3.7.1 nader worden besproken.

51 Een grotere nadruk op formele mehoden en meer aandacht voor de te representeren kennis zijn twee andere trends die Mars (1990) signaleert.


87

Ondanks deze verschillen bestaan er toch goede mogelijkheden voor de integratie van beide soorten systemen, zie paragraaf 3.7.2. 3.7.1 Kennissystemen versus decision support systemen Een specifiek DSS biedt faciliteiten voor het ondersteunen van het beslissingsproces. De beslisser c.q. gebruiker van het systeem kan zelf bepalen welke methoden en data hij wil gebruiken (mits deze mogelijkheid natuurlijk binnen de DSS-generator wordt geboden). Een kennissysteem is wat betreft de invulling van het beslissingsproces minder flexibel. De beslissingsregels die in de diverse fasen van het beslissingsproces worden gebruikt, zijn beschreven en vastgelegd in de kennisbank. Het inferentiemechanisme bepaalt vervolgens de samenhang tussen de regels en structureert op deze wijze de manier waarop een of meerdere fasen van beslissingsproces worden doorlopen52. Het kennissysteem, of nauwkeuriger gesteld het inferentiemechanisme, bepaalt de manier waarop het redeneerproces wordt ingevuld. Binnen het redeneerproces kunnen vragen aan de gebruiker worden gesteld. Door de antwoorden kan de gebruiker enigszins de richting van het redeneerproces beïnvloeden, maar dit blijft een reactie op een vraag van het systeem. Een belangrijk verschilpunt tussen kennissystemen en decision support systemen is het feit dat kennissystemen adviezen geven en DSS niet. Kennissystemen geven op basis van de karakteristieken van het probleem en de gemodelleerde (formele en informele) regels advies aan de gebruiker. SDSS zijn dus flexibeler in gebruik, maar gaan minder ver in hun ondersteuning van het beslissingsproces. Een kennissysteem genereert wel adviezen maar heeft een beperkt toepassingsgebied. Doukidis (1988) stelt: ‘Although both DSS and ES have similar aims, they achieve them in completely different ways. The main difference are the boundary of the problem-space and the way to tackle the problem. DSS encourages the user to explore a wide problem-space. Instead of a fixed problem solving process, the system provides a flexible problem solving environment of tools and data for the user to play with in his own way. The ES approach on the other hand bounds the problem area into well defined domains. Past experiences on repetitive tasks are formulated as problem-solving processes for future use. The system’s operation is goal-oriented and it is usually system-driven.’

In Tabel 3-6 zijn enkele verschillen tussen kennissystemen en decision support systemen opgenomen.

52 Het systeem kan het hele beslissingsproces structureren indien het kennissysteem het gehele beslissingsproces omvat. Dit is echter niet waarschijnlijk.

88

Hoofdstuk 3

Tabel 3-6: Decision support systemen versus kennissystemen. 1. 2. 3. 4. 5.

Decision support systeem Ondersteunend Flexibel Breed toepassingsgebied User-driven Eenmalige problemen

1. 2. 3. 4. 5.

Kennissysteem Adviserend Star Afgebakend probleem domein System-driven Herhalende problemen

Naast deze verschillen in het gebruik van deze systemen zijn er ook duidelijke verschillen in de ontwikkeling van beide soorten systemen. Bij het ontwikkelen van DSS ligt de nadruk op prototyping (zie Alavi en Napier, 1986; Guimaraes en Saraph, 1991). Bij de ontwikkeling van kennissystemen zijn een aantal stromingen te onderscheiden. Prototyping wordt ook bij de ontwikkeling van kennissystemen toegepast53. De doelstellingen van prototyping in de ontwikkeling van kennissystemen zijn (Tolmie, 1994): • prototype development educates the knowledge engineer in the domain and its problems, • the prototype demonstrates whether the artificial intelligence techniques that were applied are powerful and flexible enough to solve the problem, • the prototype shows whether critical technical requirements can be met, • the prototype establishes the feasibility of the system. Naast prototyping zijn allerlei gestructureerde methoden ontwikkeld. Voor een deel zijn deze gericht op het expliciet maken van kennis (zie bijvoorbeeld Wright en Ayton (1987) en Seagle en Duchessi (1995)) en het vervolgens analyseren en structureren van deze kennis. Voor een ander deel zijn de methoden gericht op de systeemontwikkeling. Voorbeelden van deze laatste categorie zijn KADS (Knowledge Analysis and Design Support), Desire en Structured knowledge engineering (SKE) (Smulders, 1990; Breuker en Wielinga, 1986; Keller,1987). Deze methoden bestrijken het volledige ontwikkeltraject van kennisacquisitie tot implementatie (Schmidt en Oskamp, 1991). Bij KADS ligt de nadruk op de kennisacquisitie en bij Desire op het ontwerp. Lippolt en Stemerdink (1991) concluderen op basis van een enquête dat 51% prototyping gebruikt voor het ontwikkelen van een kennissysteem (voor het PC-platform), 28% gebruikt knowledge engineering methoden en 28% gebruikt hiervoor algemene software engineering methoden. Bij de mainframe gebruikers ligt dit laatste percentage hoger.

53 King (1989) experimenteert met het ontwikkelen van simpele expertsystemen door de experts zelf. Mogelijke problemen die hij constateert zijn gelegen in het gebruik van de expert system shells en in het structureren van de aanwezige kennis.


89

3.7.2 Generieke DSS in combinatie met een kennissysteem Ondanks de verschillen tussen kennissystemen en decision support systemen is recentelijk een stroming waar te nemen die de grens tussen beide soorten systemen probeert te slechten. Dit sluit aan bij de opinie van Alter (1992) dat het verbeteren van het beslissingsproces centraal moet staan en niet de technologie. Om problemen op te lossen, moet men zich niet fixeren op kennissystemen of decision support systemen, maar moet men de componenten gebruiken die goed toepasbaar zijn. Deze trend heeft geleid tot systemen die luisteren naar namen als kennisgebaseerde decision support systemen (Klein en Methlie, 1990), ES-DSS (Turban en Watkins, 1986) en intelligente DSS (van Weelderen en Sol, 1993; Gottinger en Weimann, 1992). De essentie van deze systemen is dat niet uitsluitend de modelcomponent en de datacomponent van een DSS worden gebruikt, maar dat kennis wordt opgeslagen, zoals bij een kennissysteem het geval is. De elicitatie en representatie van deze kennis is belangrijk bij het ondersteunen van de besluitvorming (Doukidis, 1988). Jarke en Radermacher (1988) stellen: ‘the essence of intelligence may be - properly understood - the ability to model relevant parts of reality in a meaningful way and to draw relevant conclusions (inferences) from such models as a basis for further actions.’

Door gebruik te maken van deze kennis kan tegemoet worden gekomen aan het door Keen (in Jarke en Radermacher (1988)) geuite bezwaar dat de huidige DSS uitsluitend passieve ondersteuning bieden bij het oplossen van problemen en dat dergelijke systemen geen (actieve) adviezen geven aan de beslisser. Onderzoekers in diverse velden hebben allerlei complexe methoden ontwikkeld die echter alleen door specialisten kunnen worden gebruikt. Jarke en Radermacher (1988) veronderstellen dat het gebruik van kennisrepresentatietechnieken extra ondersteuning kan bieden bij het gebruik van een DSS. Doordat een generieke DSS gericht is op een klasse van problemen kan het gebruik van een generieke DSS worden ondersteund met behulp van een kennissysteem. Het ondersteunen van het gebruik van een specifieke DSS is niet praktisch. Deze ondersteuning vergt namelijk de constructie van een specifieke DSS en de elicitatie van kennis van één of meerdere experts over het gebruik van dit systeem. Het probleem zal echter reeds lang zijn opgelost voordat het systeem is gerealiseerd, aannemende dat een kennissysteem daadwerkelijk kan worden gebouwd. Gegeven de gerichtheid van een SDSS op een specifiek probleem wegen de voordelen van de ondersteuning door middel van een kennissysteem niet op tegen de nadelen. Een van de bekendste nadelen is de grote investering voor de arbeidsintensieve bouw. Die investering zal niet renderen als er uiteindelijk, uitzonderingsgevallen daargelaten, maar één gebruiker is. Vanwege de gerichtheid van een generieke DSS op een bepaald type probleem ligt ondersteuning van het gebruik van een GDSS door middel van een kennissysteem meer voor de hand. Kennissystemen zijn zinvol toepasbaar indien een bepaalde gelijksoortige beslissing meerdere malen moet worden genomen. Het

90

Hoofdstuk 3

generieke DSS kan bij elk probleeminstantie uit die klasse worden gebruikt. De kennis die nodig is om het generieke DSS in een probleemsituatie te gebruiken kan hierbij ter beschikking worden gesteld. De kennis omtrent dat probleemgebied, in de vorm van vuistregels, normen, ratio’s en dergelijke, worden in het kennissysteem vastgelegd. Bij het oplossen van een specifiek probleem uit de gedefinieerde probleemklasse kan deze kennis worden toegepast. Bij een beslissingsondersteunend systeem kan deze kennis bijvoorbeeld betrekking hebben op vuistregels voor het vaststellen van het aggregatieniveau van activiteiten in een activiteitennetwerk, normen voor de omrekening van het aantal functiepunten in mensmaanden en ratio’s in de vorm van inspanningsverhoudingen tussen de verschillende fasen van het project.

3.8 Conclusies Uitgaande van het proces van beslissen zoals omschreven in paragraaf 1.3 gaan wij ervan uit dat ondersteuning van elk van de fasen van het beslissingsproces mogelijk moet zijn (vraag 1 in paragraaf 3.4.1). Die ondersteuning zal zich vooral richten op de informele regels (vraag 3). Dit omdat het kenmerk van slecht gestructureerde problemen het ontbreken van formele regels is. Dat betekent dat de ondersteuning van planningprocessen, in de in paragraaf 1.6 gegeven betekenis van dit begrip, weinig zin heeft. De ondersteuning zal bij voorkeur worden gegeven in de vorm van een advies aan een beslisser in een bepaalde functie op een bepaald niveau (vraag 2 en 4). Met name de ondersteuning van de informele regels en het geven van een advies resulteren in een voorkeur voor het gebruik van een generieke DSS met een kennissysteem.

Hoofdstuk 3 Automatisering en beslissingsprocessen

Recommend Documents