University of Groningen. Methoden en regels voor de Projectplanning Vrolijk, Hans Cornelis Johan

Transcriptie

1 University of Groningen Methoden en regels voor de Projectplanning Vrolijk, Hans Cornelis Johan IMPORTANT NOTE: You are advised to consult the publisher's version (publisher's PDF) if you wish to cite from it. Please check the document version below. Document Version Publisher's PDF, also known as Version of record Publication date: 1996 Link to publication in University of Groningen/UMCG research database Citation for published version (APA): Vrolijk, H. C. J. (1996). Methoden en regels voor de Projectplanning: een toepassing van beslissingsondersteunende systemen Groningen: s.n. Copyright Other than for strictly personal use, it is not permitted to download or to forward/distribute the text or part of it without the consent of the author(s) and/or copyright holder(s), unless the work is under an open content license (like Creative Commons). Take-down policy If you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim. Downloaded from the University of Groningen/UMCG research database (Pure): For technical reasons the number of authors shown on this cover page is limited to 10 maximum. Download date:

2 Hoofdstuk 6 Conclusies en evaluatie 6.1 Inleiding Hoofdstuk 1 beschrijft organisaties en met name de beslissings- en planningprocessen binnen organisaties. In hoofdstuk 1 is probleemstelling van dit onderzoek beschreven. In de hoofdstukken 2 tot en met 4 zijn verschillende aspecten van de probleemstelling aan de orde gekomen. In hoofdstuk 2 zijn drie methoden voor het maken van modellen beschreven. In hoofdstuk 3 is het gebruik van computers bij het ondersteunen van beslissingsprocessen nader uitgewerkt. In hoofdstuk 4 staat het probleemgebied van deze studie centraal. Dit alles heeft geresulteerd in het ontwerp van een beslissingsondersteunend systeem dat in hoofdstuk 5 is gepresenteerd. In dit hoofdstuk worden de conclusies op basis van de in hoofdstuk 1 gegeven probleemstelling beschreven en wordt aandacht besteed aan de validiteit van het ontwikkelde systeem. 6.2 Ontwerpen versus verklaren De bestuurlijke informatiekunde legt de nadruk niet zozeer op het verklaren maar op het ontwerpen. Bij het ontwikkelen van een informatiesysteem wordt een ontwerp van een systeem gemaakt waarmee doorgaans een probleem kan worden opgelost. Dit heeft ten opzichte van verklarende wetenschappen als nadeel, dat de generaliseerbaarheid vaak klein is. Bosman (1995) stelt: Een belangrijk verschilpunt tussen verklaren en ontwerpen is de mate van generalisatie. Ontwerpen betekent doorgaans het specificeren van een oplossing voor een bepaald probleem. Omschrijving van dat probleem staat centraal, van generalisatie kan niet of nauwelijks worden gesproken. Een beschrijving van een individueel probleem wordt in de wetenschapstheorie doorgaans niet gezien als een verklaring. Wil er van verklaren sprake zijn, dan moet een zekere generalisatie over meerdere, vergelijkbare, problemen mogelijk zijn. Verklaren en ontwerpen zijn niet twee totaal van elkaar gescheiden activiteiten. Vaak wordt verklaren gezien als een voorwaarde voor het maken van ontwerpen. De kennis die is verkregen met het vinden van een verklaring van een verschijnsel, of

3 198 Hoofdstuk 6 klasse van verschijnselen, biedt richtlijnen voor het proces van ontwerpen. Bij het gebruik van modellen om verklaringen van verschijnselen te geven worden details weggelaten (zie hoofdstuk 2). Dit wordt enerzijds veroorzaakt door de inzichtelijkheid en hanteerbaarheid van de modellen en anderzijds doordat men geïnteresseerd is in de hoofdlijnen en niet in de details van specifieke gevallen. Bij ontwerpen staan deze specifieke gevallen echter centraal. Bij het ontwerpen dient een vertaalslag te worden gemaakt van een algemene verklaring naar een specifieke situatie. Daarbij staat niet zozeer de generaliseerbaarheid maar de toepasbaarheid centraal en deze is juist afhankelijk van de specifieke situatie. Hierdoor wordt bij het proces van ontwerpen in veel sterkere mate gebruikgemaakt van materiekennis. We lichten dit toe aan de hand van een mathematisch model. De variabelen zoals die in een mathematische model worden gebruikt leveren slechts beperkte informatie voor het maken van een ontwerp. Bij het gebruik van variabelen worden details, zoals het gebruik van informele regels, weggelaten. Bij het maken van een ontwerp kunnen die informele regels van wezenlijk belang zijn. Bij het maken van bijvoorbeeld een plan op basis van een activiteitennetwerk dienen vragen te worden beantwoord teneinde de variabelen in te kunnen vullen. Zo moet worden vastgesteld welke activiteiten moeten worden uitgevoerd, welke opeenvolgingsrelaties tussen deze activiteiten bestaan, hoe lang een activiteit duurt, welke produktiefactoren hierbij nodig zijn etc. Voor het beantwoorden van deze vragen is materiekennis nodig die in veel gevallen de vorm van beslissingsregels aanneemt. Bij het ontwerpen worden met behulp van beslissingsregels tal van ontwerpbeslissingen genomen. Naarmate het ontwerp gedetailleerder zal zijn, zal men meer gedetailleerde kennis nodig hebben. Programmatuur in de informatica en de informatiekunde is een voorbeeld van een gedetailleerd ontwerp. Het in dit onderzoek centraal gestelde beslissingsondersteunend kennissysteem geeft dat duidelijk aan. Het ontwerp is gemaakt op grond van de overwegingen zoals die in de hoofdstukken 4 en 5 zijn beschreven. De samenhang tussen verklaren en ontwerpen kan nu als volgt worden aangegeven. Het maken van een ontwerp heeft betrekking op het vinden van een oplossing voor een probleem. Om dat probleem te kunnen specificeren is een beschrijving nodig van de bestaande situatie 99. Bij het maken van die beschrijving kan gebruik worden gemaakt van conceptuele modellen uit de verklarende wetenschappen. Aan de hand van die beschrijving kan worden gezocht naar een oplossing (zie Mitroff, 1974; Bosman, 1977 en Sol, 1982 voor een uitgebreide beschrijving van de hypothetisch inductieve modelcyclus). Het doorlopen van deze fasen lukt echter niet altijd doordat in bepaalde gevallen de vertaalslag van het beschrijvende model naar een model dat een oplossing biedt niet kan worden gemaakt. Aangezien problemen wel worden opgelost, bestaat er een groot aantal vuistregels voor het vinden van oplossingen. Het expliciteren van die 99 Zie paragraaf 2.3 voor een nadere uiteenzetting over het belang van het beschrijven van de bestaande situatie. Dit belang komt tot uitdrukking in een aantal stappen waarin achtereenvolgens een empirisch beschrijvend, een conceptueel beschrijvend, een conceptuele voorschrijvend en tenslotte een empirisch voorschrijvend model worden opgesteld.

4 Conclusies en evaluatie 199 vuistregels, in een proces van ontwerpen, biedt de mogelijkheid de tegenstelling tussen verklaren en ontwerpen te verkleinen. Simon benadrukt dit door te stellen: Our main tool of research has been to build systems and see how they operate. Some people who come to us out of mathematics, or who don't come to us but sit on the other side of the fence and heckle us, say how can you do that, what s the good of a science unless it has a theory? and we all look back at Newton s three laws of motion. We are never going to have three laws of motion in computer science. 6.3 Conclusies In hoofdstuk 1 is de probleemstelling geformuleerd als: op welke manier kunnen methoden en regels voor de projectplanning worden gemodelleerd en geïmplementeerd in een beslissingsondersteunend informatiesysteem. Op basis van deze probleemstelling zijn vijf deelvragen geformuleerd. In dit hoofdstuk zullen wij terugkomen op deze vragen vanuit het proces van ontwerpen dat is gevolgd: 1. In hoeverre de informele en formele regels met betrekking tot de projectplanning kunnen worden gemodelleerd en welke modelvormen zijn hiervoor het meest geschikt? 2. Welke methoden worden gebruikt bij de projectplanning? 3. Wat is een goede structuur voor een beslissingsondersteunend systeem met betrekking tot de projectplanning, voortbouwend op de antwoorden op de vorige twee deelvragen? 4. Welke richtlijnen zijn af te leiden ten aanzien van het ontwerp van een dergelijk systeem? 5. Is een dergelijk systeem te ontwikkelen? Modelleren van formele en informele regels In hoofdstuk 2 en 3 is aangegeven dat regelmodellen een adequaat middel zijn voor het modelleren van beslissingsregels zoals die worden gebruikt in beslissingsprocessen. In hoofdstuk 3 is behandeld hoe materiekennis in de vorm van produktieregels in een kennisbank kan worden gemodelleerd. De methoden uit de kunstmatige intelligentie bieden de mogelijkheid formele en informele regels te expliciteren en te modelleren. De beslissingsregels, zoals die worden gebruikt, zijn gemodelleerd voor zoverre deze in het ontwerp zijn opgenomen (zie hoofdstuk 5). Een aantal cases in combinatie met de beschikbare literatuur hebben als basis gediend voor het definiëren van de materiekennis in de vorm van beslissingsregels. In paragraaf 5.3 en Appendix A zijn de cases beschreven. Deze cases zijn bestudeerd om inzicht te krijgen in het verloop van de projectplanning.

5 200 Hoofdstuk 6 Uit deze cases blijkt dat bij de projectplanning op een groot aantal momenten vuistregels worden gebruikt. Vuistregels worden bijvoorbeeld gebruikt bij de keuze van een planningmethode, het al dan niet op individueel niveau specificeren van middelen, de aggregatie van een activiteitennetwerk etc. Vuistregels worden met name gebruikt om de activiteitsduur in te schatten. Op dat niveau spelen volgens de planners allerlei individu-gebonden factoren een rol. Verder worden bijvoorbeeld vuistregels toegepast op basis van algemene kenmerken van het project. Zo kan men op basis van verhoudingscijfers schattingen ten aanzien van bijvoorbeeld de ontwerpfase extrapoleren naar andere fasen van het project. Het verkrijgen en vastleggen van kennis wordt bemoeilijkt doordat niet alle beschikbare planningmethoden worden gebruikt. Dit vormt geen bezwaar indien dit een weloverwogen keuze is. De beslissingsregels die in een dergelijk geval aan de keuze ten grondslag liggen, kunnen dan worden gemodelleerd. Het niet gebruiken van de planningmethoden is echter in veel gevallen te verklaren door het niet beschikbaar zijn van de benodigde kennis. Kennis die nodig is om deze planningmethoden te gebruiken is echter wel te modelleren in een kennisbank. Er moet dan wel een andere bron worden gevonden voor deze kennis. Een bron voor het verkrijgen van deze kennis is bijvoorbeeld de beschikbare literatuur over deze planningmethoden. Op deze manier is gestreefd naar een integratie van de kennis van de menselijke expert (met betrekking tot methoden die worden gebruikt door die expert) en kennis die uit andere bronnen afkomstig is (kennis met betrekking tot methoden die in de huidige situatie niet worden gebruikt). Gegeven deze discussie en het in hoofdstuk 3 beschreven mogelijke onderscheid tussen kennissystemen en expertsystemen, willen wij voor een dergelijk systeem de term kennissysteem gebruiken. Daarnaast bestaat het probleem van de generaliseerbaarheid van bepaalde gehanteerde vuistregels. Sommige door de projectmanagers genoemde voorbeelden van vuistregels zijn dusdanig specifiek dat het niet zinvol is deze in het door mij ontworpen systeem te modelleren. Een voorbeeld van een dergelijke regel is het in paragraaf 5.3 beschreven voorbeeld van het schatten van de omvang van het rittenplanningsysteem van een kaasfabriek. Wat in dergelijke voorbeelden vaak wel generaliseerbaar is de manier van aanpak: zoek eerst naar bepaalde grootheden die van doorslaggevend belang zijn voor het ontwikkelen van dat specifieke systeem, bepaal dan de consequenties van deze grootheden op de kosten en de doorlooptijd van het project. Tenslotte wordt op basis van deze informatie een schatting van de kosten en de doorlooptijd gemaakt. De gehanteerde vuistregels zijn met name persoonsafhankelijk. Men erkent het belang van het gebruik van ervaringen, maar er vindt tot nog toe nauwelijks of geen overleg plaats omtrent vuistregels. Het afstemmen van dergelijke regels tussen verschillende personen wordt echter wel als zinvol aangemerkt. Op basis van het voorgaande concluderen wij dat het mogelijk is informele regels te expliciteren en te gebruiken in het beslissingsproces.

6 Conclusies en evaluatie Methoden voor de projectplanning De tweede deelvraag betreft de inventarisatie van methoden die worden gebruikt bij de planning van projecten. In paragraaf 1.8 is het onderscheid gemaakt tussen methoden met een breed toepassingsgebied en methoden met een eng toepassingsgebied. Deze deelvraag heeft betrekking op de methoden met een eng toepassingsgebied. De methoden met een eng toepassingsgebied zijn de methoden die zijn gericht op de oplossing van een bepaald type probleem. Uit de case-beschrijvingen blijkt dat sommige planningmethoden veelvuldig worden gebruikt. Het al dan niet gebruiken van de methoden wordt in de meeste gevallen overgelaten aan de planner. Voor het gebruik van de methoden bestaan over het algemeen ook weinig richtlijnen. Methoden die veel worden toegepast zijn met name netwerkplanningmethoden en methoden voor het maken van een kostenbegroting, en dan vooral functiepuntanalyse. Voor het gebruik van deze methoden, en met name voor het toepassen van de netwerkplanningmethoden, wordt vaak gebruikgemaakt van een softwarepakket. In veel gevallen wordt het pakket echter alleen als communicatiemiddel gebruikt en niet als analysemiddel. Het beslissingsproces wordt grotendeels door de menselijke planner doorlopen en ingevoerd in het programma. Het programma vervult dan alleen een rol met betrekking tot het presenteren van de gegevens omtrent de ingevoerde activiteiten en produktiemiddelen (bijvoorbeeld in de vorm van tabellen of afbeeldingen). De specificatie van een activiteitennetwerk wordt in de meeste gevallen gevolgd door een vergelijking van beschikbare en gevraagde middelen. Het oplossen van eventuele conflicten gebeurt in veel gevallen door middel van het handmatig verschuiven van activiteiten. De speling van een activiteit is een kenmerk die bij dit verschuiven nog wel eens een rol speelt. Het weinig toepassen van algoritmes wordt mede veroorzaakt door een gebrek aan inzicht in deze algoritmes. Uit de cases blijkt dat FPA in de oorspronkelijke vorm wordt toegepast. Hierbij wordt het alom geuitte advies het model te calibreren naar de eigen situatie genegeerd. Het gebruik van FPA is met name gericht op het brengen van een zekere mate van objectiviteit in de projectplanning. Naast het gebruik van de reeds gebruikte methoden bestaat er wel degelijk belangstelling voor het gebruik van methoden waarvan men nog niet op de hoogte is. Dit komt ondermeer tot uitdrukking in het in hoofdstuk 5 beschreven citaat: De neiging om te standaardiseren op een methode en een invalshoek leidt tot een enorme verstarring. Dit geldt zowel voor de toepassing van planningmethoden als systeemontwikkelingsmethoden. Het is belangrijk dat per situatie de keuze wordt gemaakt. (zie case bankbedrijf 1) Met name de Program Evaluation and Review Technique is bij de projectplanners onbekend of voor wat betreft het gebruik niet geheel duidelijk. Het aanbieden van methoden die nog niet worden gebruikt vergt echter wel een goede ondersteuning

7 202 Hoofdstuk 6 van dit gebruik. Kennis omtrent de toepasbaarheid en het gebruik van de methoden dient hierbij beschikbaar te zijn Structuur beslissingsondersteunend systeem Ter beantwoording van deze vraag is begonnen met in hoofdstuk 3 een beschrijving te geven van de ontwikkelingen in het gebruik van informatiesystemen ter ondersteuning van beslissingsprocessen. Hierbij is met name aandacht besteed aan decision support systemen (DSS) en kennissystemen omdat deze categorieën van informatiesystemen direct gerelateerd zijn aan het nemen van beslissingen. Als belangrijke verschillen tussen beide systemen is aangegeven dat kennissystemen adviezen geven en dat het merendeel van de kennissystemen gebaseerd is op regelmodellen. Dat geldt niet voor DSS. Tevens is aangegeven dat beide systemen elk hun sterke en zwakke punten hebben. Deze sterke punten sluiten elkaar niet uit, maar vullen elkaar juist aan. De conclusie is dan ook dat een integratie van deze systemen een instrumentarium oplevert waarmee de werkelijkheid met een rijkere verzameling van concepten wordt gemodelleerd. Een kanttekening die wij hierbij hebben gemaakt is dat het ontwikkelen van een kennissysteem voor een specifiek beslissingsprobleem oftewel in samenhang met een specifieke DSS, weinig efficient is. Een koppeling van kennissystemen aan generieke DSS ligt dan ook meer voor de hand. Een generieke DSS is gericht op een type probleem en daarmee op meer dan een specifiek probleem. De kennis omtrent dat type probleem wordt dan in een kennissysteem gemodelleerd. Deze conclusies ten aanzien van de ondersteuning van beslissingsprocessen in het algemeen zijn vertaald naar de ontwikkeling van het in hoofdstuk 5 beschreven systeem. Bij het ontwikkelen van dit systeem zijn diverse ontwerpbeslissingen genomen. Op basis van de bevindingen in de vorige paragraaf is gekozen voor de integratie van een kennissysteem en een generieke DSS. Het generieke DSS is gericht op een klasse van problemen. De methoden die geschikt zijn voor het oplossen van deze problemen zijn in de vorm van conceptuele modellen ondergebracht in het generieke DSS. Het gebruik van een dergelijk generieke DSS maakt een snelle ontwikkeling van een specifiek DSS mogelijk. Hiertoe moet het conceptuele model empirisch worden gemaakt. De keuze van de juiste methode en het daarmee samenhangende conceptuele model en het empirisch invullen van dit conceptuele model vereist kennis. Deze kennis is gemodelleerd met behulp van een kennissysteem. Dit kennissysteem assisteert bij de selectie van de meest geschikte methode en bij het construeren van het empirisch model op basis van het beschikbare conceptuele model Ontwerprichtlijnen Het beslissen over de uitvoering van projecten is een complexe bezigheid. Het oplossen van dit probleem op basis van traditionele mathematische modellen is niet volledig mogelijk. Kennis van de planner in de vorm van normen, formele en informele beslissingsregels maken een belangrijk deel uit van het beslissingsproces.

8 Conclusies en evaluatie 203 Wil men tot een zinvolle ondersteuning van het beslissingsproces komen, dan dient ook aandacht te worden besteed aan deze kennis. Dit leidt tot de formulering van de eerste ontwerprichtlijn: bij het ontwikkelen van informatiesystemen ter ondersteuning van beslissingsprocessen moet expliciet aandacht worden besteed aan de kennis ten aanzien van het doorlopen van dit proces. Het modelleren van deze kennis impliceert echter niet dat traditionele OR methoden geheel overbodig zijn. Een beslissingsprobleem bestaat uit een aantal deelproblemen. Deze verschillende deelproblemen kunnen op verschillende wijzen worden geautomatiseerd of ondersteund. De tweede ontwerprichtlijn die hieruit volgt luidt: bij het ontwikkelen van een systeem ter ondersteuning van de projectplanning dient een zorgvuldige afweging te worden gemaakt welke deelproblemen met behulp van welke modelvormen worden gemodelleerd. Voor de verschillende deelproblemen dient dus een afweging gemaakt te worden over de manier waarop de taak kan worden overgenomen of ondersteund. Een belangrijke eis hierbij is de hechte samenhang tussen de verschillende componenten. Het aantal extra handelingen om een analyse uit te voeren moet beperkt zijn. Het aantal handelingen wordt beperkt door een hechte samenhang tussen de verschillende componenten na te streven, zodat niet tussen de verschillende programma s geschakeld hoeft te worden. Het is hierbij met name van belang dat de gegevens slechts één keer worden ingevoerd. Het twee keer invoeren van dezelfde gegevens voor verschillende analyses zal de acceptatiegraad niet vergroten. Dit leidt tot de derde ontwerprichtlijn: er dient een hechte samenhang te bestaan tussen de deelproblemen. Deze eis is voor een groot deel bepalend geweest voor de keuze van de programmatuur (zie deelvraag 5). Tevens geldt dat de ondersteuning moet aansluiten bij zowel het probleem als de behoeften van de gebruiker; dit is de vierde ontwerprichtlijn. Een systeem ter ondersteuning van de projectplanning moet meerdere scenario s voor de ondersteuning bevatten. Dit om te voorkomen dat een planner in alle gevallen wordt opgezadeld met een zeer gedetailleerd plan terwijl hij of zij uitsluitend geïnteresseerd is een globale planning. Dit hangt samen met de eis dat de gebruiker invloed moet hebben op de analyses. Dit betekent ondermeer dat de gebruiker moet begrijpen wat er gebeurt. Het belang van de invloed van de gebruiker op het uiteindelijk functioneren van het systeem wordt goed geïllustreerd aan de hand van het citaat van Wastell et al. (1994): The system was simply to prescriptive, it attempted to impose a straitjacket on the user. your system has been designed to be idiot proof, the trouble is we re not idiots as one user drolly put it. Het voorgaande leidt tot de vijfde ontwerprichtlijn: de gebruiker dient invloed te kunnen uitoefenen op het proces van beslissen zoals dat doorlopen wordt. Dit geldt zowel voor de structuur van het beslissingsproces (de verschillende fasen die

9 204 Hoofdstuk 6 doorlopen worden) als op de daadwerkelijke invulling van bepaalde fasen van dit proces. Het beslissingsproces (zoals beschreven in paragraaf 1.3) is als uitgangspunt genomen voor het definiëren van de kennis die nodig is voor het doorlopen van het planningproces. Door het proces van beslissen als uitgangspunt te nemen wordt het voorschrijvende karakter aan de ondersteuning ontnomen. De organisatie dient een uitspraak te doen over het al dan niet voorschrijvend karakter van een dergelijk systeem. Om de gebruiker invloed te kunnen geven geldt de voorwaarde dat de gebruiker inzicht moet hebben in het functioneren van het systeem en het systeem moet gebruiksvriendelijk zijn (de zesde richtlijn). De opbouw van het systeem moet helder zijn voor de gebruiker en, indien mogelijk, zo veel mogelijk aansluiten bij de normale wijze van werken Ontwikkeling van een beslissingsondersteunend systeem In derde subvraag is aangegeven welke structuur gebruikt kan worden om een beslissingsondersteunend systeem te ontwikkelen. In de vorige deelvraag is een aantal richtlijnen voor het ontwerp van een beslissingsondersteunend systeem opgesteld. Op basis van de conclusies van de voorgaande twee deelvragen zal het proces van ontwerpen zoals dat is gevolgd, worden toegelicht. Het beschreven ontwerp van het beslissingsondersteunend systeem is in de vorm van een prototype gerealiseerd. Met dit prototype willen wij de haalbaarheid van een systeem bestaande uit kennissysteem- en GDSS-componenten ten aanzien van het modelleren van methoden en regels aantonen. De kennis ten aanzien van het proces van beslissen is opgenomen in het kennissysteem. De beslissingsregels zoals die gebruikt worden in het beslissingsproces zijn hiertoe in de kennisbank gemodelleerd. Met deze kennis ten aanzien van het doorlopen van het beslissingsproces en het gebruik van methoden wordt een soort van procedurele rationaliteit bewerkstelligd. Het voorschrijven van het proces van beslissen biedt een waarborg dat aan alle relevante problemen in het beslissingsproces aandacht wordt besteed. Zoals gesteld wordt de activiteit beslissen opgedeeld in een aantal subactiviteiten. Voor elk van deze activiteiten is gekeken op welke manier deze opgelost of ondersteund moet worden. Activiteiten die een sterk accent leggen op beslissen zijn in de vorm van beslissingsregels in een kennisbank vastgelegd. Subproblemen waarvoor algoritmen bestaan, zijn gemodelleerd met behulp van een 3-GL programmeertaal. De resterende delen dienen door de beslisser te worden uitgevoerd. De keuze voor een modulaire aanpak en activiteitafhankelijke oplossingswijze vereist een sterke samenhang tussen de verschillende delen. Bij de opzet van het systeem is nadrukkelijk rekening gehouden met de samenhang tussen de verschillende modulen. Het kennissysteem biedt een overkoepelende structuur waaruit, indien nodig, diverse andere modulen worden opgestart. Deze andere

10 Conclusies en evaluatie 205 modulen kunnen zowel andere kennisbanken als algoritmische programma s zijn. De uitwisseling van gegevens tussen deze modulen is zoveel mogelijk gerealiseerd door gebruik te maken van protocollen voor de uitwisseling van gegevens en indien dit niet mogelijk was door het gebruik van bestanden. Met het voorgaande wordt voorkomen dat de gebruiker meerdere malen dezelfde gegevens of feiten moet invoeren. De modulaire opzet maakt het in principe mogelijk bestaande programmatuur op te nemen. Hier is echter vanafgezien vanwege de gebrekkige samenhang die zou ontstaan 100. Verder was de eis van samenhang van invloed op de keuze van het Windows besturingssysteem. Windows biedt een zogenaamde multitasking omgeving waarin meerdere programma s tegelijkertijd actief kunnen zijn. Het vermijden van het meermalig invoeren van dezelfde gegevens wordt bewerkstelligd door diverse protocollen voor de overdracht van gegevens. De invloed van de gebruiker op het functioneren van het systeem is op verschillende manieren gerealiseerd. Deze invloed lijkt in eerste instantie misschien in strijd met het expliciteren van het beslissingsproces, maar er zijn altijd sistuaties denkbaar waarin de gebruiker de mogelijkheid moet hebben om af te wijken van de normale procedure. De invloed van de gebruiker komt naar voren in de mogelijkheid bepaalde adviezen van het systeem te overrulen. Bij een advies van het kennissysteem wordt dan nadrukkelijk gevraagd of de gebruiker dit advies op wil volgen. Verder heeft de gebruiker invloed vanwege het sterk interactieve karakter van het systeem. Bijvoorbeeld: ook al is er een lijst van activiteiten en de relaties tussen deze activiteiten geselecteerd, dan nog bestaat de mogelijkheid dit activiteitennetwerk aan te passen. Als voorwaarde voor de invloed van de gebruiker is de inzichtelijkheid en gebruiksvriendelijkheid van het systeem genoemd. De inzichtelijkheid is gerealiseerd aan de hand van de keuze van de programmatuur en het gebruik van een hypertekstsysteem. De grafische gebruikersinterface van Microsoft Windows biedt een gebruiksvriendelijke werkomgeving en heeft een uniforme menustructuur en bediening. Diverse achtergrondinformatie is vastgelegd in een hypertkekstsysteem. Deze informatie heeft zowel betrekking op het gebruik van de software als het gebruik van de planningmethoden. Op basis van het hypertekstsysteem krijgt de gebruiker informatie over de toepasbaarheid van de methoden en de manier waarop de methoden daadwerkelijk worden toegepast. Deze achtergrondinformatie is zoveel mogelijk op een context-gevoelige manier geïmplementeerd. Dit betekent dat de gebruiker alleen die informatie krijgt die relevant is voor de taak die op dat moment wordt uitgevoerd. Verder kan de inzichtelijkheid worden vergroot met de in hoofdstuk 5 beschreven mapping tussen termen zoals die binnen een organisatie worden gebruikt en de termen zoals die intern in het systeem worden toegepast. 100 Het opnemen van reeds bestaande programmatuur leidt tot veel extra handelingen om de interactie te bewerkstelligen. De data/gegevens/feiten moeten in het ene programma expliciet opgeslagen worden en in het andere programma ingelezen. De interactie wordt hierdoor zeer moeizaam.

11 206 Hoofdstuk 6 Het generieke systeem is afgestemd op functies op het tactische en operationele niveau. Vragen betreffende de zin van het project worden op die niveaus niet gesteld. Een uitzondering daarop vormt de uitkomst dat de inzet van de produktiefactoren niet groter mag zijn dan in het door het strategische management vastgestelde budget. Hoewel niet in dit onderzoek aangetoond, zijn wij van mening dat met behulp van een dergelijk systeem de effectiviteit van beslissingsprocessen ten behoeve van projecten kan worden verbeterd. Wij zijn van mening dat we hebben aangetoond dat vraag 5 van de probleemstelling in positieve zin kan worden beantwoord. Het ontwikkelde systeem draait stand alone op een PC waarop Windows 3.1 en Level5 Object voor Windows 3.0 draait. Deze keuze is in hoofdstuk 5 toegelicht. Het gebruik van Level5 Object voor Windows en Microsoft C biedt de mogelijkheid een directe koppeling en interactie tot stand te brengen. In de toekomst (ten dele al gerealiseerd) zal de integratie van bestaande programmatuur makkelijker worden door het gebruik van data uitwisselings-protocollen zoals DDE waarmee gegevens tussen verschillende programma s kunnen worden uitgewisseld en het beschikbaar zijn van System Development Kits voor specifieke programmatuur (zoals Excel) waarmee uitbreidingen op bestaande programma s kunnen worden ontwikkeld Mogelijke uitbreidingen Het beschreven systeem geeft een omschrijving van het beslissingsproces en de daarbij gebruikte methoden. De ondersteuning van het gebruik van de methoden kan verder worden verfijnd. In principe is het mogelijk voor elke methode een uitgebreid kennissysteem te ontwikkelen. Binnen het kader van deze studie is dit niet onderzocht. Elementen die in de huidige versie als informatie in het hypertekstsysteem is vastgelegd kan ten dele worden opgenomen in de kennisbank. Daarnaast kan worden getracht de vuistregels te achterhalen die in een eerder stadium van het project (voorafgaand aan de daadwerkelijke start) worden gebruikt. Deze regels zijn echter zeer specifiek. De praktijkvoorbeelden hebben bijvoorbeeld betrekking op kaas: Het aantal kilo's kaas is van invloed op het aantal uit te voeren ritten. Het aantal ritten is vervolgens van invloed op het aantal vrachtwagens dat nodig zal zijn. Het aantal auto's is van invloed op de complexiteit van een rittenplanningssysteem. De zaken die met vuistregels worden geschat zijn de projectduur en de projectkosten. De activiteitsduur kan worden vastgesteld door een specificatie van de uit te voeren werkzaamheden en normen voor het uitvoeren van die werkzaamheden. (zie case I&O adviseur) Verder kan een systeem worden toegespitst op de specifieke situatie van een organisatie. Door met dergelijke kennis rekening te houden zou men bijvoorbeeld kennis kunnen opnemen over welke personen en welke afdelingen geraadpleegd c.q. geconsulteerd moeten worden en welke personen hun goedkeuring moeten uitspreken.

12 Conclusies en evaluatie 207 Het element risico komt in de huidige versie in beperkte mate naar voren. Bij de vaststelling van de meest geschikte planningmethode wordt aandacht besteed aan risico. Risico kan ook een belangrijker plaats worden gegeven. In het voortraject van een project kan de risico-analyse worden ondersteund. Voor deze risico-analyse bestaan vragenlijsten. Een van de projectmanagers noemde een wens met betrekking tot een instrument dat in een zeer vroeg stadium van een project kan worden toegepast. Hij schetst een beeld van een hulpmiddel inclusief methoden en technieken die men zou kunnen gebruiken bij het eerste gesprek met de opdrachtgever over het project. Dit zou de vorm kunnen krijgen van een vraag- en antwoordspel teneinde een aantal omgevingsfactoren in beeld te brengen, die vervolgens worden gecombineerd met een risico-analyse. Op basis van een kennisbank zou dan direct een beeld verkregen kunnen worden van de doorlooptijd van een project, door heel gericht een aantal vragen te stellen aan de opdrachtgever. 6.4 Validatie en verificatie Een belangrijke fase in de ontwikkeling van een kennissysteem is, net zoals bij de ontwikkeling van informatiesystemen, het testen van het systeem. Het testen bestaat uit een aantal fasen. In veel gevallen wordt hierbij het onderscheid gemaakt tussen validatie en verificatie. De invulling van de validatie en verificatie staat onder invloed van het in paragraaf 6.2 gemaakte verschil tussen verklaren en toepassen (zie Bosman, 1996). Bij ontwerpen wordt het pragmatische aspect meer benadrukt. Botten et al. (1989) geven een duidelijke beschrijving van het verschil tussen verificatie en validatie: Verification stems from the Latin word veritas, truth, and means to establish the truth of correspondence between a software appliccations and its specifications, i.e. verification of the design. Validation on the other hand, stems from the latin word valere, to be worth, and means to establish the worth of a software application in terms of its operational mission. Verificatie heeft meer betrekking op de syntactische en semantische aspecten van een systeem en de validatie meer op de pragmatische aspecten. In de ontwikkeling van kennissystemen wordt vaak relatief meer nadruk gelegd op de validatie dan op de verificatie. Dit ligt, gegeven de nadruk op ontwerpen, voor de hand, omdat bij ontwerpen de toepasbaarheid en daarmee het pragmatische aspect centraal staat. In veel gevallen zal het echter goedkoper zijn meer aandacht te besteden aan de verificatie (Botten et al., 1989), omdat net als bij de traditionele systeemontwikkeling geldt, dat het verbeteren van fouten kostbaarder is naarmate deze later in het ontwikkelproces worden geconstateerd. Bij de verificatie van een kennissysteem zal de verificatie van de kennis in de vorm van de regels een belangrijk element vormen. Naast een eenvoudige syntaxcheck dienen de regels logisch te worden beoordeeld. De logische verificatie van de

13 208 Hoofdstuk 6 regels heeft met name betrekking op de consistentie en de volledigheid van de regels (Botten et al., 1989; Klein en Methlie, 1990; Preece en Shinghal, 1994): Consistentie Conflicterende regels: regels conflicteren indien deze op basis van dezelfde feiten kunnen vuren, maar in tegenstrijdige conclusies resulteren. Redundante regels: regels zijn redundant indien deze op hetzelfde moment kunnen vuren en ook dezelfde resultaten opleveren. Voor redundantie in kennisbanken geldt hetzelfde als voor redundantie van gegevens in databases. Redundantie is niet per definitie slecht. Redundantie kan efficiëntie voordelen opleveren maar resulteert in een verhoogde kans op inconsistentie bij het onderhoud van het systeem. Overlappende regels: regels overlappen indien regels dezelfde resultaten opleveren maar een van de regels extra condities bevat. Cyclische regels: regels zijn cyclisch indien de voorwaarde van de ene regel gelijk is aan de conclusie van de andere regel en vice versa. Cyclische regels kunnen tot gevolg hebben dat het inferentiemechanisme in een lus terechtkomt. Volledigheid Ontbrekende regels: er is sprake van een ontbrekende regel indien niet alle mogelijke combinaties van feiten worden afgedekt; Niet gerefereerde feiten: dead end conditions en unreachable conditions treden op indien het afleiden van deze feiten geen verdere acties tot gevolg hebben. De hier beschreven onvolkomenheden zijn geen fouten op zich, maar kunnen een indicatie zijn van mogelijke fouten (Preece en Shinghal, 1994). Met name de inconsistentie, de cyclische regels en de ontbrekende regels kunnen een negatief effect hebben op de werking van het systeem. De hiervoor beschreven kenmerken van de regels zijn onafhankelijk van de inhoud van de regels. Veel van deze testen kunnen dan ook automatisch worden uitgevoerd. Jafar en Bahill (1993) beschrijven een tool voor het vaststellen van de consistentie en de volledigheid van een kennisbank. Bench-Capon et al. (1993) en French en Hamilton (1994) benadrukken dat een goede methodologie voor het ontwikkelen van kennissystemen reeds een waarborg kan bieden voor de validatie en verificatie van het systeem. Voor de validatie van een kennissysteem zijn een aantal testen beschikbaar (verderop in deze paragraaf wordt aangegeven welke hiervan daadwerkelijk zijn uitgevoerd): Face validity De eerste vorm van validatie, de face validity, zal altijd, impliciet of expliciet, worden uitgevoerd. Deze vorm van validiteit heeft betrekking op de vraag of de structuur van het model en de uitkomsten van het model als geloofwaardig naar voren komen en niet strijdig zijn met theoretische verwachtingen en het gezonde verstand. Hierbij gaat het deels om de ervaring en intuïtie van de ontwikkelaar en deels om die van de expert. Daarnaast kan het model in sommige gevallen worden getoetst op basis van relaties die uit de theorie bekend zijn.

14 Conclusies en evaluatie 209 Validatie door voorspelling De uitkomsten van het kennissysteem kunnen worden vergeleken met de verwachtte uitkomsten. Hiertoe kunnen de uitkomsten van het systeem worden vergeleken met historische gevallen (replicative validaty (Finlay et al., 1988)) of met nog te behandelen gevallen (predictive validaty). Daarnaast kan gebruik worden gemaakt van speciaal geconstrueerde cases. Het voordeel van cases is dat deze meer extreme gevallen kunnen afdekken. Het succes van het systeem kan vervolgens worden uitgedrukt in het percentage van de gevallen waarin het systeem een juiste conclusie trekt. Voor de verificatie van kennisbanken zijn diverse tools ontwikkeld. Recentelijk zijn er ook pogingen ondernomen om tools voor de validatie van kennisbanken te ontwikkelen. Zlatareva en Preece (1994) en Zlatareva (1994) beschrijven een validatie-tool bestaande uit drie componenten. De eerste component verzorgt de dynamische validatie waarbij test-cases wordt doorlopen en waarbij vervolgens de resultaten worden vergeleken met de verwachte uitkomsten. De tweede component wordt gevormd door een refinement tool die op basis van de evaluatie van de test-cases voorstellen doet voor aanpassingen aan de kennisbank. De derde component genereert nieuwe test-cases (deze kunnen vervolgens weer worden gebruikt in de dynamische validatie). Een andere mogelijkheid om het systeem te valideren is de Turing Test. Chandrasekaran (in Agarwal et al., 1993) definieert de Turing Test als: the purpose of the turing test is to see if a neutral observer, given a set of performances on a task, some by a machine and others by humans, but unlabeled as to authorship, could identify, better than by chance, which were machine and which were human produced Bij deze test krijgt een expert zowel de uitkomsten van het systeem als de uitkomsten van een menselijke beslisser voorgelegd. Indien de expert geen onderscheid kan maken tussen beide uitkomsten kan geconcludeerd worden dat het systeem een goede beschrijving geeft van het probleemgebied (zie Agarwal et al. (1993) voor een toepassing van een variant van de Turing Test). Klein en Methlie (1990) wijzen op het feit dat in hybride systemen met zowel kennis als decision support achtige componenten, de verificatie en validatie anders verloopt. In geval van een integratie van kennissystemen en decision support systemen (door hen KB-DSS genoemd) is er niet een enkel criterium op basis waarvan het systeem kan worden geëvalueerd. In een KB-DSS omgeving worden problemen behandeld die niet een eenduidige juiste oplossing kennen. Daarentegen kent een systeem voor bijvoorbeeld het al dan niet toekennen van een sociale uitkering een eenduidig gedefinieerde juiste conclusie (Finlay et al., 1988). De evaluatie van het systeem kan in dergelijke gevallen worden gebaseerd op het percentage juiste conclusies. In een (KB-)DSS omgeving heeft de gebruiker een belangrijke rol. Het beoordelen van het systeem op basis van uitsluitend de conclusies is dan lastig omdat er meerdere,

15 210 Hoofdstuk 6 juiste, conlusies kunnen worden gedefinieerd. De algemene doelstelling, het verbeteren van het beslissingsproces, is moeilijk te operationaliseren. De beoordeling van het systeem moet dan plaatsvinden op basis van een meer algemene evaluatie van het functioneren van het systeem. Naar aanleiding van de voorgaande beschouwing over de verificatie en validatie van kennissystemen zijn de volgende testen uitgevoerd. De kennisbanken zijn gecontroleerd op feiten waaraan niet gerefereerd wordt. Level5 Object biedt de mogelijkheid op basis van een attribuut alle verwijzingen naar dat attribuut in de kennisbank te tonen. Niet gerefereerde woorden zijn verwijderd of de op die woorden betrekking hebbende produktieregels zijn toegevoegd De kennisbanken zijn gecontroleerd op loose ends. De controle op loose ends heeft plaatsgevonden door de kennisbank te controleren op woorden waarvan het vaststellen van een feit niet leidt tot een vervolgredenering (hierbij moet natuurlijk een uitzondering worden gemaakt voor de woorden die in de agenda zijn opgenomen). Naast de uitkomsten van het gebruik van de kennisbank is ook het redeneerproces geanalyseerd (als doel op zich, of teneinde de oorsprong van een fout te herleiden). Het redeneerproces wordt bestudeerd aan de hand van de door L5 geboden faciliteiten in de vorm van de history files en de value lists. De history files bieden een soort trace van de vast te stellen feiten, de geëvalueerde regels, methoden en demons, de getoonde informatie, de gestelde vragen etc. Aan de hand van deze trace kan het redeneerproces gedetailleerd worden geanalyseerd. Daarnaast kan met behulp van de value list op elk moment in de consultatie de waarden van woorden worden bekeken. Op deze manier kan worden gecontroleerd of feiten waarvan men verwacht dat ze in een consultatie gelden ook daadwerkelijk van toepassing zijn. De procedurele delen zijn volgens de normale stappen in de ontwikkeling van software getest. Het testen van programma s wordt opgedeeld in statische en dynamische testen (Van Vliet, 1988). Tijdens de statische analyses wordt in tegenstelling tot de dynamische analyses het programma niet uitgevoerd. Een groot deel van de statische analyses wordt uitgevoerd door de compiler. De compiler genereert een overzicht van fouten. Deze fouten hebben bijvoorbeeld betrekking op het niet declareren van variabelen of het onjuist aanroepen van procedures (bijvoorbeeld omdat een procedure wordt aangeroepen met een onjuist aantal parameters, parameters van een onjuist type etc.). Daarnaast is de code gecontroleerd door het zorgvuldig lezen van de code. In meer geformaliseerde situaties zou dit de naam code walkthrough of code inspection kunnen dragen. In de dynamische analyses wordt de programmatuur draaiend getest 101. Aan de hand van bepaalde testgevallen is de correctheid van de programmatuur gecontroleerd. Bij dit testen en fouten opsporen is gebruikgemaakt van de diverse door Visual C++ geboden debug faciliteiten. 101 Het draaiend testen vereist natuurlijk dat de programmatuur succesvol is gecompileerd en gelinked.

16 Conclusies en evaluatie 211 Na het verhelpen van deze fouten is de software op module niveau getest. Na de module test zijn de modulen samengevoegd en is de gehele software getest. In het testen van de software is gebruikgemaakt van bepaalde testgevallen. De uitkomsten van de software zijn vergeleken met de verwachtingen die handmatig waren opgesteld. Na de modulen afzonderlijk getest te hebben zijn deze onderling gekoppeld. Vervolgens is de gegevensoverdracht tussen deze verschillende modulen getest en is gekeken of het gehele systeem naar verwachting werkt. In dit onderzoek hebben wij laten zien dat een systeem op basis van integratie van kennissystemen en generieke DSS ter ondersteuning van de projectplanning, mogelijk en implementeerbaar is. Door deze integratie wordt een systeem geboden dat rijker is aan concepten. Methoden, algoritmen, formele en informele regels kunnen op een samenhangende wijze worden aangeboden. Conceptuele modellen, voor een klasse van problemen, worden vastgelegd in het generieke DSS. Kennis in de vorm van formele en informele regels met betrekking tot de selectie van het meest geschikte conceptuele model en de empirische invulling van dit model, wordt in het kennissysteem vastgelegd. De empirische validatie van dit systeem valt, door de grote tijdsinspanning die dit vergt, buiten de scope van dit onderzoek. Zoals in de vorige paragraaf is beschreven, is de validatie van een systeem moeilijker en arbeidsintensiever, indien er sprake is van integratie van kennissystemen en generieke DSS. In deze systemen is, in tegenstelling tot een kennissysteem, niet een enkel criterium beschikbaar op basis waarvan de correctheid van het systeem kan worden aangetoond. Zoals gesteld heeft de gebruiker een doorslaggevende rol in het functioneren van een KB-DSS omgeving. In een dergelijke situatie moet men andere criteria hanteren om het succes en de kwaliteit van het systeem te meten. Toch willen wij enkele opmerkingen maken met betrekking tot hoe een dergelijke validatie plaats kan vinden. De daadwerkelijke toetsing van het ontwerp in de praktijk zal de volgende stappen vergen. Ten eerste moeten organisaties bereid worden gevonden het prototype gedurende langere tijd te gaan gebruiken. Het gebruik van dit systeem vergt een zekere leertijd. Teneinde het effect betrouwbaar vast te stellen zou men enige tijd (bijvoorbeeld een jaar) met het systeem moeten werken. Vervolgens dient de oude met de nieuwe situatie te worden vergeleken. Het vergelijken van de kwaliteit van de projectplanning en de resulterende plannen met de plannen van voorgaande jaren en het succes van het systeem, dient nader te worden geoperationaliseerd. Voorbeelden om deze begrippen te operationaliseren zijn: de frequentie van gebruik van het systeem, het aantal methoden dat bij de projectplanning wordt gebruikt, de middelen die nodig zijn om een projectplan op te stellen, de tijd die nodig is voor het opstellen van het plan, het aantal alternatieven dat wordt beschouwd, de mate waarin plannen zonder bijstellingen kunnen worden uitgevoerd en de door de planner gepercipieerde kwaliteit van het proces en het plan (zie DeLone en McLean (1992) voor een opsomming van succesfactoren). Afhankelijk van de situatie en het doel waarvoor het systeem wordt gebruikt, dient een keuze voor één of meer van deze interpretaties te worden gemaakt. Een waarschuwing die hierbij in acht genomen dient te worden is dat de de immer

17 212 Hoofdstuk 6 veranderende omgeving kan leiden tot veranderingen in de onderliggende omstandigheden. Vergelijking van de resultaten wordt hierdoor bemoeilijkt. 6.5 Tot slot Centraal in dit proefschrift stonden de methoden en regels voor de projectplanning en de manier waarop dit beslissingsproces kan worden ondersteund. Hiertoe is een inventarisatie gemaakt van concepten die bij het doorlopen van beslissingsprocessen en het ondersteunen van deze processen een rol spelen. Beslissings- en planningsprocessen zijn gedefinieerd, diverse methoden voor het maken van modellen ter ondersteuning van de besluitvorming zijn besproken, en de mogelijkheden van informatietechnologie voor het ondersteunen van beslissingsprocessen zijn geïnventariseerd. Tevens zijn er cases bestudeerd om inzicht te krijgen in de manier waarop de projectplanning in de praktijk wordt uitgevoerd en de methoden en regels die hierbij een rol spelen. Dit alles heeft geleid tot het ontwerp en de ontwikkeling van een prototype van een ondersteunend systeem zoals besproken in hoofdstuk 5. Dit systeem is rijker aan concepten dan de traditionele aanpak. Zowel methoden en algoritmen als formele en informele regels zijn in dit raamwerk opgenomen. Aan het proces van ontwerpen van het systeem, zoals in het voorgaande hoofdstuk is beschreven, liggen diverse ontwerpbeslissingen ten grondslag. Voor deze beslissingen geldt dat niet kan worden aangetoond dat het een optimale beslissing is. Wel kan worden aangetoond dat het een werkbare oplossing is. In het voorgaande hoofdstuk hebben we laten zien dat een ontwerp op basis van integratie van kennissystemen en generieke DSS mogelijk is en dat deze implementeerbaar is. Conceptuele modellen die bij het oplossen van een klasse van problemen worden gebruikt, kunnen worden vastgelegd in het generieke DSS. Kennis in de vorm van formele en informele regels die nodig is voor de selectie van het meest geschikte conceptuele model en de empirische invulling van dit model, kan in een kennissysteem worden vastgelegd. Met het ontwerp en de ontwikkeling van het systeem en de eerste reeks van testen zoals die in de vorige paragraaf zijn beschreven, is de haalbaarheid van een dergelijk systeem aannemelijk gemaakt. Het proces van ontwerpen zoals gevolgd, heeft geresulteerd in diverse richtlijnen met betrekking tot het ontwerpen van systemen op basis van integratie van kennissystemen en GDSS. Uit de case-beschrijvingen blijkt dat de projectplanning op een informele en ongestructureerde wijze wordt ingevuld. Verder onderzoek dient gericht te zijn op de praktische waarde van ondersteuning door kennissystemen en decision support systemen, alsmede op het vaststellen van de meerwaarde van een geïntegreerd systeem zoals voorgesteld in dit onderzoek.