Hoofdstuk 5 Implementatie van een beslissingsondersteunend systeem 5.1 Inleiding

Hoofdstuk 5 Implementatie van een beslissingsondersteunend systeem 5.1 Inleiding In hoofdstuk 1 zijn beslissen en planning binnen organisaties beschreven. Hierbij is planning gedefinieerd als een geëxpliciteerde en geformaliseerde vorm van beslissen. In beslissingsprocessen worden modellen gebruikt om problemen te beschrijven, alternatieven te genereren en keuzes te maken. De verschillende methoden om deze modellen te construeren zijn beschreven in hoofdstuk 2. In hoofdstuk 3 is vervolgens aangegeven op welke manier geautomatiseerde systemen kunnen worden gebruikt bij het nemen van beslissingen. Met name DSS en kennissystemen zijn gericht op het nemen van beslissingen. Het belangrijke onderscheid tussen beide systemen is dat een kennissysteem een advies kan geven en een DSS niet. In hoofdstuk 4 staat het probleemdomein centraal. Projectplanning en de daarbij gebruikte planningmethoden zijn beschreven. De voorgaande hoofdstukken leggen de basis voor het doel van dit onderzoek, nl. het ontwerp van een beslissingsondersteunend systeem. Het begrip beslissingsondersteunend systeem wordt hierbij in een iets bredere betekenis gebruikt dan decision support systemen zoals beschreven in hoofdstuk 3. Bij het gebruik van de term beslissingsondersteunend systeem staat het ondersteunen van het nemen van een beslissing centraal, ongeacht of dit met kennissystemen of decision support systemen gebeurt. Het beslissingsondersteunend systeem wordt in dit hoofdstuk besproken. Hierbij is gekozen voor een ontwerp dat aansluit bij de in paragraaf 3.7.2 beschreven integratie van kennissystemen en generieke DSS. Een generieke DSS is gericht op een klasse van problemen, waarbij conceptuele modellen van de probleemsituatie in het generieke DSS zijn ondergebracht. De kennis, die nodig is om de juiste methode te selecteren en het conceptuele model empirisch te maken, wordt hierbij ondergebracht in het kennissysteem (deze keuze zal nader worden uiteengezet in paragraaf 5.4). In paragraaf 5.2 worden enkele rollen van kennissystemen beschreven en wordt aangegeven welke van de genoemde mogelijkheden in het in dit hoofdstuk beschreven systeem zijn opgenomen. In paragraaf 5.3 komen de bestudeerde cases aan de orde. Deze cases beschrijven de projectplanning in een aantal verschillende

138 Hoofdstuk 5 organisaties. Het doel van deze cases is inzicht te krijgen in de mate waarin organisaties een planningproces doorlopen en zo ja, welke methoden hierbij worden gebruikt en op welke manier deze methoden worden toegepast. Daarnaast zijn de behoeftes ten aanzien van de ondersteuning van de projectplanning in kaart gebracht. Vervolgens wordt in paragraaf 5.4 een globale beschrijving gegeven van de opbouw van het systeem. Het ontwerp van de diverse modulen die in dit systeem worden onderscheiden, worden in de daaropvolgende paragrafen nader toegelicht. 5.2 Mogelijke rollen van een kennissysteem Een kennissysteem kan in verschillende fasen van het beslissingsproces worden ingezet. Daarnaast kan een kennissysteem verschillende rollen vervullen. De fasen zullen worden besproken in paragraaf 5.4. De verschillende rollen die een kennissysteem kan vervullen zullen in deze paragraaf worden toegelicht. Dewhurst en Gwinnet (1990) beschrijven twee rollen: The first is as part of the user interface, making the system accessible to any type of user, including those who have little or no modelling experience. The second is as one of the tools available for use on a particular problem. In the first case, where an expert system is used as a front-end to the model-building process, the expert system element of the user interface will be fully defined, specifically geared to the purpose of problem definition, and where possible the interpretation of results. Dewhurst en Gwinnet (1990) stellen dat beslissingssituaties onderling sterk verschillen en daarom elk hun eigen combinatie van methoden vergen. Hiertoe ontwerpen zij het Artificial Decision-Analysis Support System (ADASS) als een algemeen systeem voor probleemoplossen waarbinnen de beslisser methoden kan kiezen al naar gelang de probleemsituatie. Hierbij kan gebruik worden gemaakt van expert system shells, OR-methoden, statistische analyses en simulatie. Naar onze mening is het bijzonder moeilijk een dergelijk veelomvattend systeem te implementeren. Daarnaast zijn er ook problemen met betrekking tot de toepasbaarheid van de methoden. Het gebruik van een expertsysteem in het ADASS impliceert het specificeren van de kennis en dus het modelleren van het probleemdomein in een specifieke probleemsituatie. Het ontwikkelen van een kennissysteem voor een eenmalige beslissingssituatie is echter weinig efficiënt (zie hoofdstuk 3). Turban en Trippi (1989) onderscheiden eveneens twee mogelijke rollen van kennissystemen. Het gebruik van een kennissysteem als een stand alone tool en een kennissysteem geïntegreerd met andere computertoepassingen (bijvoorbeeld een DSS) (zie Figuur 5-1). Een kennissysteem als afzonderlijk systeem kan de volgende doelstellingen hebben: Een kennissysteem als kennisbron. Kennis en informatie omtrent een bepaald probleemgebied kan toegankelijk worden gemaakt. De presentatie van en navigatie door de beschikbare informatie kan bijvoorbeeld in de vorm van een hypertekstsysteem (pijl 1 in Figuur 5-1)

Beslissingsondersteunend systeem 139 Daarnaast kan een kennissysteem als leermiddel worden ingezet. Gebruikers kunnen door gebruik te maken van het systeem de nodige ervaring opdoen met het systeem en de methoden. Door het werken met het systeem wordt inzicht verkregen in bepaalde strategieën voor het oplossen van problemen (pijl 1 en pijl 2 in Figuur 5-1). Oz et al. (1993) tonen aan in een experiment dat het probleemoplossend vermogen van gebruikers van een kennissysteem sterker toeneemt dan van beslissers die het systeem niet gebruiken. Het kennissysteem kan echter ook meer inhoudelijk in het beslissingsproces worden ingezet door de structuur van het beslissingsproces, oftewel de diverse stappen die in het beslissingsproces moeten worden doorlopen, te beschrijven (zie paragraaf 5.4 voor een beschrijving van de verschillende fasen). Het systeem stelt de aard van het probleem vast, begeleidt het bouwen van een model, draagt alternatieve oplossingsrichtingen aan, maakt een keuze tussen de verschillende oplossingsrichtingen en interpreteert tenslotte de resultaten (alle pijlen in Figuur 5-1). User Computer 1 2 Knowledge based system (selection, application, interpretation) 3 Planning techniques (Pert, CPM, Cocomo, FPA etc.) Figuur 5-1: Interactie tussen de gebruiker, het kennissysteem en de planningmethoden. Aan de interactie tussen de drie componenten wordt op verschillende manieren inhoud gegeven. Voor zover het gaat om het gebruik van het kennissysteem als kennisbron, werkt de gebruiker afzonderlijk met het kennissysteem (pijl 1) en de planningmethoden (pijl 2). De gebruiker past de planningmethode toe en bij eventuele problemen en onduidelijkheden raadpleegt de gebruiker het kennissysteem. Dit kennissysteem adviseert de gebruiker en stelt achtergrondkennis ter beschikking. De kennis die de gebruiker uit het kennissysteem haalt past hij vervolgens toe bij het gebruik van de methode. Wanneer het kennissysteem als modelleringsondersteuning wordt gebruikt zal het kennissysteem een actievere rol vervullen. Het systeem geeft niet alleen adviezen en achtergrondkennis maar stuurt het beslissingsproces en het gebruik van de methoden. In deze laatste situatie is een

140 Hoofdstuk 5 directe koppeling tussen het kennissysteem en de planningmethoden wenselijk, zodat de adviezen direct op de planningmethode kunnen worden toegepast (pijl 3). In het ontwerp van het systeem, dat in de volgende paragrafen zal worden beschreven, zal een combinatie van de hiervoor genoemde toepassingsmogelijkheden worden bewerkstelligd. Het kennissysteem biedt achtergrondkennis over de toepasbaarheid en de manier van toepassen van de planningmethoden. Deze kennis kan door de gebruiker worden toegepast bij het gebruik van de planningmethoden. Daarnaast vervult het kennissysteem een actieve rol in het doorlopen van het beslissingsproces. Het kennissysteem adviseert bij de keuze van de planningmethode voorafgaand aan de projectplanning, bij de toepassing van deze methode en bij de interpretatie van de uitkomsten van het gebruik. Deze drie fasen zullen in paragraaf 5.4 worden besproken. Voorafgaand hieraan zal aandacht worden besteed aan een aantal case-beschrijvingen teneinde inzicht te krijgen in de manier waarop de projectplanning in de praktijk wordt ingevuld. 5.3 Projectplanning in de praktijk Een systeem ter ondersteuning van de projectplanning moet kennis bevatten omtrent de fasen die in dit beslissingsproces worden doorlopen. Zowel kennis die betrekking heeft op een enkele activiteit in dit proces (bijvoorbeeld de toepassing van een methode), als kennis die de structuur (samenhang fasen) van dit proces beschrijft, moeten worden gemodelleerd. Ter verkrijging van deze kennis zijn praktijk cases bestudeerd. Bij het bestuderen van deze cases moet kennis worden verzameld over de organisatie, de projectplanning, de invulling van deze planning en de wensen ten aanzien van de ondersteuning. Voorafgaand aan het inwinnen van specifieke kennis, die betrekking heeft op de projectplanning, is het zinvol eerst algemene informatie te verzamelen om een beeld te krijgen omtrent de organisatie, de softwareprojecten binnen die organisatie en de manier van projectplanning. Tevens is deze stap nuttig bij het verkrijgen van inzicht in het specifieke begrippenkader zoals dat in een organisatie wordt gehanteerd. Zaken die hierbij aan de orde komen zijn het type en de omvang van de organisatie. Het beslissingsproces ten aanzien van de projecten zal plaatsvinden aan de hand van formele en/of informele regels. Het aanwezig zijn van formele richtlijnen voor het doorlopen van het planningproces en voorschriften ten aanzien van het gebruik van specifieke methoden binnen dit proces vormt het uitgangspunt voor het structureren van de kennis omtrent deze planning. Naast formele regels zullen op tal van plaatsen in het proces informele regels worden gehanteerd. Zoals in Hoofdstuk 2 is beschreven zijn de informele regels niet expliciet in de organisatie vastgelegd en geautoriseerd. Een deel van de informele regels zal expliciet moeten worden gemaakt om een kennissysteem te ontwikkelen dat een ondersteunende rol bij de projectplanning vervult. Vervolgens is geïnventariseerd hoe de projectplanning wordt ingevuld. Welke methoden worden gebruikt en welke beslissingsregels worden gehanteerd. Tevens

Beslissingsondersteunend systeem 141 wordt gekeken of het gebruik van bepaalde methoden een bewuste keuze is en welke formele of informele beslissingsregels aan deze keuze ten grondslag liggen. Voor een aantal veel gebruikte methoden is eveneens gekeken op welke wijze de methode wordt toegepast binnen het beslissingsproces en wat voor beslissingsregels hierbij worden toegepast. Met het oog op de ontwikkeling van een beslissingsondersteunend systeem zijn de wensen ten aanzien van de mogelijke ondersteuning geïnventariseerd. Hierbij is gekeken welke wensen bestaan ten aanzien van de ondersteuning van het beslissingsproces als geheel en ten aanzien van afzonderlijke fasen en methoden. In appendix A is een uitvoerige beschrijving van de cases opgenomen. In deze paragraaf zullen we enkele algemene bevindingen naar aanleiding van deze cases beschrijven. De bestudeerde organisaties zijn niet representatief voor alle organisaties die zich met systeemontwikkeling inlaten. Softwarehuizen en bancaire instelling zijn oververtegenwoordigd. Dit is echter geen bezwaar omdat een representatieve weergave niet de doelstelling van dit onderzoek is. Bij de beknopte bespreking van de cases wordt dezelfde indeling gevolgd als bij de bespreking van de cases in Appendix A. Organisatie De organisaties die zijn bestudeerd hebben een uiteenlopende achtergrond. Bij enkele van de bestudeerde organisaties gaat het om het leveren van diensten aan andere afdelingen in de eigen organisaties. Het primaire proces (zie paragraaf 1.2) van de organisatie als geheel bestaat niet uit het leveren van software. De leverende afdeling heeft een ondersteunende rol. Het betreft hier zowel bancaire instellingen als produktiebedrijven. De mate van concurrerend werken verschilt. Dit geldt zowel voor de mate waarin de klanten in de eigen organisatie een externe organisatie kunnen inhuren als voor de mate waarin de afdeling diensten aan derden mag aanbieden. Voor een ander deel bestaat de verzameling bestudeerde organisaties uit softwarehuizen die zijn gericht op de ontwikkeling van software ten behoeve van derden. Het primaire proces van deze bedrijven is gericht op het leveren van software en aanverwante diensten. Tenslotte is de werkwijze van een zelfstandige informatie- en organisatie-adviseur ten aanzien van de projectplanning bestudeerd. Informatieplanning In alle organisaties houdt men zich bezig met één of andere vorm van informatieplanning. Ten dele is deze informatieplanning gericht op de eigen organisatie. In de andere gevallen ondersteunt of verzorgt men het formuleren van een informatieplan voor een klant. Bij de invulling van het informatieplanningproces wordt weinig gebruikgemaakt van de hiervoor beschikbare informatieplanningmethoden (zie paragraaf 4.2). De methoden die wel worden gebruikt zijn INFORMATION ENGINEERING en NAVIGATOR 75, daarnaast worden door de organisatie ontwikkelde methoden gehanteerd. De invulling van het 75 Information Engineering van James Martin & Co. en Navigator van Moret Ernst & Young

142 Hoofdstuk 5 informatieplanningproces vindt voor een groot deel op een informele wijze plaats. Groepsdiscussies van de betrokken partijen spelen een belangrijke rol. Planning van softwareprojecten Alle organisaties stellen voorafgaand aan het uitvoeren van een project een plan op. Een uitzondering op deze regel wordt gevormd door projecten met een zeer kleine omvang. Indien een project klein is, wordt geen plan opgesteld. In één organisatie wordt het al dan niet opstellen van een plan volledig overgelaten aan de betrokken projectleider. Het plan wordt in alle gevallen opgesteld door de projectleider al dan niet in samenspraak met de andere betrokken partijen. In enkele organisaties vervult de informatie-analist de rol van projectleider. Andere organisaties houden daarentegen een strikte scheiding aan, tussen deze twee functies omdat deze twee functies een geheel ander profiel vergen. Planningmethoden Ondanks dat in alle organisaties wordt beweerd dat men voorafgaand aan het uitvoeren van een project een projectplan opstelt, staat de invulling van de projectplanning in een aantal organisaties volledig open 76. De manager van de automatiseringsafdeling van een bank verwoordt dit met: Van belang is dat ze aan het plannen zijn. De uitwerking hangt sterk af van de persoonlijke voorkeur. Het enige wat vastligt is dat er gepland moet worden. (zie case bankbedrijf 1). Het al dan niet gebruiken van de planningmethoden die zijn beschreven in paragraaf 4.6 staat daarmee ook vrij. In één organisatie wordt het gebruik van methoden zelfs afgeraden. Het gebruik van methoden wordt niet formeel voorgeschreven. Soms wordt wel het gebruik van bepaalde methoden afgeraden. Keep it simple dan is het al moeilijk genoeg. (case produktiebedrijf). De planningmethoden die worden gebruikt bestaan met name uit een simpele vorm van de netwerkplanningmethode (zie paragraaf 4.6.1) en - een variant van - functiepuntanalyse (zie paragraaf 4.6.6). De mate waarin het gebruik van deze methoden is voorgeschreven varieert sterk. In bepaalde organisaties is het gebruik van één of meerdere methoden voorgeschreven. In andere organisaties is het gebruik volledig vrijgelaten. Voor de invulling van de projectplanning met behulp van de genoemde methoden bestaan over het algemeen weinig richtlijnen. De keuze van een planningmethode is ondermeer afhankelijk van de fase van het project. Naarmate het project concreter wordt zal de onzekerheid afnemen. Een medewerker verwoordt dit op de volgende wijze: De eerste fasen zijn te vergelijken met peuren en de latere fasen met metselen. (zie case bankbedrijf 2). 76 De door ons gehanteerde definitie van het planningproces stelt strenge eisen aan de invulling van dit proces. In de casebeschrijving in appendix A is de beschrijving afgestemd op de definitie van planning zoals die door de projectmanager wordt gehanteerd.

Beslissingsondersteunend systeem 143 Daarnaast is de keuze sterk afhankelijk van de voorkeur van de planner. Alle geïnterviewden stellen dat er sprake is van een planningproces. Gezien de invulling van het planningproces en de door ons gehanteerde definitie van een planningproces (zie paragraaf 1.6) moet geconcludeerd worden dat er in veel gevallen sprake is van het op een informele wijze nemen van beslissingen ten aanzien van het project, zonder richtlijnen met betrekking tot de invulling van dit beslissingsproces. In de door ons gehanteerde definitie is in dergelijke gevallen geen sprake van het doorlopen van een planningproces. De organisaties staan open voor nieuwe ontwikkelingen. Echter, het investeren van tijd in het bestuderen van nieuwe methoden is met name een persoonlijke zaak. Men moet over tijd beschikken om nieuwe ontwikkelingen te volgen. Enkele bedrijven hebben een opleidingsinstituut dat de ontwikkelingen volgt en daarbij een keuze maakt welke methoden interessant genoeg zijn om nader te bekijken. Begrotingsmodellen Het meest en - in de bestudeerde cases enige - gebruikte begrotingsmodel is functiepuntanalyse. Dit komt overeen met het onderzoek van Heemstra et al. (zie paragraaf 4.6.6) waaruit blijkt dat functiepuntanalyse het meest gebruikte begrotingsmodel is. Ondanks adviezen van diverse zijden dat de gegevens moeten worden gekalibreerd naar de specifieke organisatie wordt de methode vooral in de oorspronkelijke vorm toegepast. Functiepuntanalyse wordt toegepast naast één of meer andere methoden. Functiepuntanalyse wordt door de projectleider of door een specialist toegepast. In de organisatie waarin men nog geen gebruikt maakt van functiepuntanalyse wil men deze methode wel gaan toepassen in de toekomst. De reden dat men functiepuntanalyse wil gaan toepassen is dat men een zekere mate van objectiviteit in de projectplanning wil brengen. Vuistregels Bij de projectplanning worden allerlei vuistregels gebruikt. Deze vuistregels zijn in veel gevallen zeer specifiek en afhankelijk van de situatie. Vuistregels worden op alle gebieden toegepast. Voorbeelden van deze beslissingen zijn: keuze voor het al dan niet opstellen van een plan keuze welke methode te gebruiken hoe een dergelijke methode toe te passen op welk detailniveau een plan op te stellen het inschatten van de omvang van een taak het toewijzen van middelen aan activiteiten het oplossen van conflicten Met vuistregels wordt met name de duur van een activiteit geschat. Op dit detailniveau is sprake van een persoon die een taak moet uitvoeren. Op een hoger niveau wordt uitgegaan van de mogelijkheden die een methode als functiepunt analyse aanreikt. Voorbeelden van vuistregels die worden gebruikt zijn zeer

144 Hoofdstuk 5 specifiek en moeilijk te generaliseren. Een voorbeeld van een dergelijke zeer specifieke regel is: 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 rittenplanningsysteem. 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) Gegevens over de omgeving van het systeem worden hierbij van belang geacht voor de omvang van het systeem. De omgeving waarin het systeem moet gaan functioneren wordt hierbij indirect bepalend geacht voor de schatting van de duur en kosten van het project. Vuistregels worden ook toegepast op basis van algemene kenmerken van projecten. Een voorbeeld van een dergelijke vuistregel is: Op basis van het aantal functiepunten kan vervolgens het aantal uren worden vastgesteld dat het technisch detail ontwerp en de bouw zal gaan duren, b.v. 4000 uur. Uitgaande van het verhoudingscijfer dat het technisch detailontwerp en de bouw 40% van de totale duur vergt, kan worden vastgesteld dat het gehele project 10.000 uur zal duren. Met verhoudingscijfers kan vervolgens de duur per fase worden berekend. Idee + plan 5%, definitiestudie 8%, basisontwerp 12%, functioneel detailontwerp 20%, tdo bouw 40% en invoering 15%. (zie case bankbedrijf 2) Met behulp van deze categorie van vuistregels, die met name zijn gebaseerd op verhoudingscijfers, kan men bepaalde schattingen van activiteiten extrapoleren naar de andere fasen. Door enkele projectplanners wordt naar voren gebracht dat functiepuntanalyse ook kan worden gerekend tot de vuistregels. Dit sluit aan bij de in paragraaf 4.6.6 beschreven constatering dat de in FPA gehanteerde omrekenfactoren niet zijn gebaseerd op statistische analyses maar op discussion and trial. Netwerkplanningmethoden Alle organisaties maken gebruik van een vorm van netwerkplanningmethoden. De wijze van gebruik loopt echter sterk uiteen. Het varieert van het opsommen en rangschikken van de uit te voeren activiteiten tot een volledige specificatie en analyse van het activiteitennetwerk (zie paragraaf 4.6.1). Bij het specificeren van de activiteiten in een activiteitennetwerk wordt gebruikgemaakt van computerprogrammatuur. Met name Project Manager Workbench wordt hierbij toegepast. Daarnaast wordt gebruikgemaakt van Microsoft PROJECT en CA SUPERPROJECT. PERT PERT (zie paragraaf 4.6.2) wordt door geen enkele organisatie gebruikt. Ten dele komt dit door de onbekendheid met het bestaan van de methode. Voor een ander deel heeft men geen vertrouwen in de methode. De methode zou een schijnonzekerheid introduceren die nergens op is gebaseerd. Tevens voert men aan dat de methode niet door gebruikte programmatuur wordt ondersteund. Het uitvoeren

Beslissingsondersteunend systeem 145 van een dergelijke analyse zou daardoor veel extra inspanning vergen. Deze inspanning omvat het opnieuw invoeren van dezelfde gegevens in een ander programma dat de gevraagde analyses wel kan uitvoeren. Voor zover men wel op de hoogte is van de methode heeft men bezwaren tegen de complexiteit van de methode: Plannen is een noodzakelijk kwaad, zo wordt het althans ervaren. PERT is nog complexer, daardoor zijn er weinig mogelijkheden dit van de grond te krijgen. (zie case produktiebedrijf) Men ziet weinig mogelijkheden om deze methode te gaan gebruiken. Op een multiproject-niveau wordt door een enkeling wel mogelijkheden gezien om met behulp van PERT de consequenties van een onzekere projectduur op de realisatie van andere projecten vast te stellen. Capaciteitsallocatie Na het specificeren van de activiteiten en de middelenbehoefte vindt een vergelijking plaats van de beschikbare en de gevraagde middelen. De middelen die hierbij aan de orde komen hebben in eerste instantie betrekking op het personeel. Daarnaast kan het ontbreken van de juiste computerapparatuur een probleem veroorzaken. Eventuele conflicten worden hierbij opgelost. Dit oplossen gaat op een betrekkelijk ongestructureerde wijze. De in de literatuur beschreven scheduling algoritmen worden nauwelijks toegepast (zie paragraaf 4.6.3). De speling van een activiteit wordt in enkele gevallen nog wel gebruikt. De reden waarom geen gebruik wordt gemaakt van dergelijke algoritmen is met name gebaseerd op het onvoldoende inzicht hebben in de werking van dergelijke algoritmen. Het aanpassen van het netwerk vindt met name plaats door het handmatig verschuiven van activiteiten in de tijd. Mogelijke ondersteuning De gewenste ondersteuning wordt ten dele bepaald door de huidige invulling van de projectplanning. Met name het verstrekken van achtergrond informatie over de toepasbaarheid van de methode en de manier van toepassen van de methode wordt wenselijk geacht, indien de organisatie nog niet over een voorgeschreven invulling van de projectplanning beschikt en indien het gebruik van methoden zich in een pril stadium bevindt. Het belang van het (her)gebruik van kennis wordt (h)erkend. Dit blijkt ondermeer uit het volgende citaat: Ondanks het belang dat wordt gehecht aan hergebruik van ervaringen vindt geen overleg plaats omtrent vuistregels die worden gebruikt bij het plannen van projecten. Er vindt geen afstemming plaats tussen de verschillende personen. Er zijn tot nu toe geen pogingen gedaan om de informele regels te formaliseren. Het uitwisselen van ervaringen en vuistregels wordt echter wel als zinvol ervaren. (zie case softwarehuis 1)

146 Hoofdstuk 5 Bij het ondersteunen van de projectplanning moeten niet alleen de bekende en gebruikte methoden aan bod komen. Het gebruik van nieuwe methoden kan nieuwe mogelijkheden bieden: 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) De gevraagde ondersteuning bestaat ten dele uit de traditionele ondersteuning in de vorm van het vastleggen en verwerken van gegevens over het project en de daarbij behorende activiteiten. Het voldoen aan deze behoeften vereist geen gebruik van kennistechnologie. Daarnaast wordt ondersteuning gevraagd bij de keuze van methoden en het gebruik van deze methoden. Aan deze beslissingen liggen beslissingsregels ten grondslag. Samenvatting en conclusies Uit de voorgaande paragrafen blijkt dat ondanks dat de projectplanners/managers stellen een planningproces te doorlopen (op een enkele uitzondering na) dit in vele gevallen beperkt blijft tot het op basis van informele regels nemen van beslissingen ten aanzien van de uitvoering van het project. Informele regels worden gehanteerd bij de meeste beslissingen die moeten worden genomen, zoals het al dan niet doorlopen van het planningproces, de selectie van een methode, de invulling van de methode, de mate van detaillering en de interpretatie van de resultaten. De ondersteuning kan worden gerealiseerd met behulp van kennistechnologie, omdat deze technologie de mogelijkheid biedt de in de projectplanning gebruikte beslissingsregels te modelleren en in een kennisbank vast te leggen (zie paragraaf 3.5.1). De hier beschreven wensen leiden tot een ontwerp dat kennistechnologie, in de vorm van kennissystemen, combineert met traditionele IT, waarin de diverse algoritmen voor de data-vastlegging, -verwerking en -analyse zijn opgenomen. Er kan derhalve worden gesproken van een generieke DSS in combinatie met een kennissysteem (zie paragraaf 3.7.1). 5.4 Globaal ontwerp van het systeem Zoals in hoofdstuk 3 is beschreven is het ontwikkelen van een kennissysteem voor een eenmalige beslissing weinig efficient. Het in dit onderzoek beschouwde probleem van de projectplanning is echter geen eenmalig probleem, maar doet zich regelmatig voor. Het ondersteunen van beslissingen die herhaalde malen voorkomen sluit aan het op het gebruik van een generieke DSS. Een dergelijke generieke DSS is gericht op een klasse van problemen. De methoden (zie hoofdstuk 4) die bij het oplossen van deze problemen worden gebruikt, worden hierbij in de vorm van een conceptueel model in het generieke DSS ondergebracht. De keuze van de meest geschikte methode en het construeren van het empirische model op basis van het beschikbare conceptuele model vereist de beschikbaarheid van kennis.

Beslissingsondersteunend systeem 147 Domeinkennis kan worden gemodelleerd in een kennissysteem. Gegeven deze redenering ontstaat een ontwerp van een beslissingsondersteunend systeem dat aansluit bij de in paragraaf 3.7.2 beschreven integratie van een generieke DSS en een kennissysteem. Het generieke DSS biedt de mogelijkheid tot het gebruik van methoden en het kennissysteem bevat een beschrijving van de formele en informele beslissingsregels die bij de selectie en het gebruik van de methoden een rol spelen. Zoals in paragraaf 5.2 is beschreven vervult een kennissysteem één of meerdere rollen. Het systeem wordt ingezet in één of meerdere fasen van het beslissingsproces. In hoofdstuk 1 is beschreven dat het nemen van een beslissing of het maken van een plan niet een gebeurtenis is op één moment in de tijd, maar dat hier een proces aan ten grondslag ligt. De ondersteuning van de projectplanning met behulp van een kennissysteem is dan ook gericht op één of meerdere van deze fasen. In deze paragraaf worden de fasen nader toegelicht. Bij het ontwerp en de ontwikkeling van het beslissingsondersteunende systeem is uitgegaan van het globaal ontwerp zoals weergegeven in Figuur 5-2. Planning probleem Selectie meest geschikte planningmethode Uitvoeren planning met de geselecteerde methode Interpreteren van de uitkomsten Plan Figuur 5-2: Fasen toepassen kennissysteem De ondersteuning van het beslissingsproces met behulp van een computersysteem wordt hierbij in drie fasen opgedeeld: 1. advisering gedurende de selectie van de juiste methoden voorafgaand aan de projectplanning, 2. advisering bij het toepassen van de methoden, 3. interpretatie van de uitkomsten

148 Hoofdstuk 5 ad. 1: ad. 2 : ad. 3 : Bij de projectplanning kan gebruik worden gemaakt van een groot aantal methoden. Deze methoden hebben alle sterke en zwakke punten en zullen dus in bepaalde situaties kunnen worden ingezet (zie bijvoorbeeld Heemstra, 1990; Haas en Wubbels, 1990). Het kennissysteem zal bij deze keuze van de methoden adviseren. Op basis van bepaalde karakteristieken van het project en de omgeving, en met name de onzekerheid en de doelstellingen van een planningsessie, zijn bepaalde methoden beter toepasbaar dan andere. Bij de selectie en keuze van geschikte methoden (deze keuze is een beslissingsproces op zich) worden beslissingsregels gehanteerd. Door het modelleren van deze regels, wordt het systeem gebruikt bij de advisering omtrent de keuze van de methoden. Wanneer in de eerste stap een methode is geselecteerd, moet vervolgens de projectplanning met deze methode worden uitgevoerd. Bij het uitvoeren is bepaalde kennis nodig omtrent projectplanning in het algemeen en de te gebruiken methoden in het bijzonder. Met andere woorden er is kennis nodig omtrent de planningstrategie. De planningstrategie 77 wordt hierbij gedefinieerd als de formele beschrijving van de beslissingen die moeten worden genomen en de activiteiten die moeten worden uitgevoerd om het beslissingsproces te doorlopen. In de kennisbank moet de planningstrategie worden beschreven. Dit wil nog niet zeggen dat deze strategie bij voorbaat vaststaat. In de strategie kunnen voorwaarden worden opgenomen, zodat gedurende de consultatie wordt besloten welke takken van de boom worden doorlopen. In deze fase wordt de kennis aangeboden die nodig is om het beslissingsproces gegeven de geselecteerde methode te doorlopen. Voor een deel vindt dit plaats in de vorm van produktieregels die de beslissingsregels van de expert beschrijven. Voor een ander deel in de vorm van achtergrondinformatie, bijvoorbeeld met behulp van een hypertekstsysteem. Het ondersteunen van de uitvoering van het beslissingsproces met behulp van de geselecteerde methoden omvat ook de interpretatie van de uitkomsten van de projectplanning. De uitkomsten kunnen aanleiding zijn tot het uitvoeren van vervolg-planningactiviteiten. Zo kan bijvoorbeeld na opbouw van een activiteitennetwerk in sommige gevallen worden geconcludeerd dat de vereiste middelen de beschikbare middelen overtreffen. Deze uitkomst kan dan aanleiding zijn tot het verschuiven van de activiteiten en het veranderen van de toewijzing van middelen aan activiteiten zodat de gevraagde middelen de beschikbare middelen niet overtreffen. 77 Dit naar analogie van Hand (1986, pag. 356) die een statistical strategy definieert: A statistical strategy has been defined as a formal description of the choices, actions, and decisions to be made while using statistical methods in the course of a study.

Beslissingsondersteunend systeem 149 Fase 1 is ingevuld met behulp van een module die in elke consultatie wordt gestart. Deze module adviseert welke planningmethode toe te passen en bepaalt daarmee welke modulen in fase 2 en fase 3 aan bod zullen komen. Voor fase 2 en fase 3 zijn een aantal alternatieve modulen ontwikkeld. Of een module in een specifieke consultatie aan bod komt is grotendeels afhankelijk van de keuzes in fase 1. Modulen die hierbij zijn te onderscheiden zijn: selectie planningmethode, functiepuntanalyse, analyse aantal functiepunten, netwerkplanning, specificatie en analyse activiteitennetwerk, PERT-analyse en analyse van conflicten. Tussen deze modulen bestaat een logische samenhang. Enkele modulen bieden alternatieve methoden, andere modulen kunnen achtereenvolgens worden doorlopen. De samenhang tussen de modulen is weergegeven in Figuur 5-3: Globaal ontwerp van het systeem. Regels selectie methode Fase 1 Globale vuistregels FPA regels Regels opbouw netwerk Fase 2 Analyse Netwerk Analyse Conflict Scheduling regels Pert Analyse Interpretatie uitkomst Fase 3 Figuur 5-3: Globaal ontwerp van het systeem De kenniscomponenten in de vorm van produktieregels die beslissingsregels beschrijven, worden aangevuld met hypertekst-achtige toepassingen. De in de hypertekst opgenomen achtergrondinformatie kan een achterliggende theorie beschrijven of een verwijzing naar de bron van specifieke kennis bevatten. In Figuur 5-3: Globaal ontwerp van het systeem, zijn zowel componenten opgenomen die kenniscomponenten weergeven als componenten die bestaan uit analytische algoritmen. Hoewel de meeste problemen met behulp van

150 Hoofdstuk 5 produktieregels kunnen worden gemodelleerd is het niet zinvol problemen waarvoor algoritmen bestaan op een dergelijke wijze op te lossen. Het berekenen van de speling van een activiteit kan bijvoorbeeld uitstekend met een algoritme worden gedaan. Veel van dergelijke procedures voor de projectplanning zijn in algoritmen vastgelegd. Het kennissysteem fungeert als overkoepelend systeem. De kenniscomponenten zijn met behulp van de expert system shell Level5 Object voor Windows geïmplementeerd. Vanuit deze shell worden andere programma's aangeroepen. Deze expert system shell zal in de volgende paragraaf nader worden toegelicht. 5.5 Selectie Expert System Shell De keuze van een expert system shell kan worden gedefinieerd als een beslissingsprobleem. Dat betekent dat voorafgaand aan de keuze van een expert system shell een aantal alternatieven zijn bekeken 78. Uiteindelijk is de keuze gevallen op Level5 Object voor Windows (Information Builders, 1993). Deze keuze kwam met name tot stand op basis van de goede integratiemogelijkheden, de eenvoudige syntax en een redelijke prijs. De eerste twee aspecten komen hieronder nader aan de orde. Level5 Object voor Windows is een door Information Builders op de markt gebrachte expert system shell 79. Voor een uitgebreide beschrijving van Level5 zie Mockler en Dologite (1992), Vrolijk (1992) en Zahedi (1993). Level5 Object biedt een ontwikkelomgeving die een hybride representatie van kennis toestaat. Naast de produktieregels wordt een soort frame gebruikt. Diverse aspecten van kennissystemen (zoals het definiëren van produktieregels en het redeneren met deze regels) worden gecombineerd met kenmerken van frames (in de vorm van het definiëren van klassen en het overerven van attributen binnen dergelijke klassen). Level5 Object is één van de beschikbare expert system shells die in de grafische werkomgeving van Windows werkt. Level5 Object bestaat, vanuit het gezichtspunt van de ontwikkelaar, uit een verzameling van editors voor het ontwikkelen van een kennissysteem. Met de editors worden de verschillende aspecten van een kennissysteem ontwikkeld. Level5 Object onderscheidt de volgende editors: 1. Agenda editor In de agenda editor kan de zogenaamde agenda van een toepassing worden ontwikkeld. De agenda bepaalt in welke volgorde het inferentiemechanisme waarden voor attributen probeert vast te stellen. 2. Object editor In hoofdstuk 3 is de frame representatie beschreven. Level5 Object spreekt echter over objecten. Het definiëren van objectklassen en de bijbehorende 78 Alternatieven die zijn bekeken, zijn onder andere NExpert Object van Neuron Data, Kappa-PC van Intellicorp (Helton, 1991), Goldworks II van Goldhill, Aion Development System van Trinzic en Guru van Micro Data Base Systems (Tello, 1986). 79 Zie hoofdstuk 3 voor een algemene beschrijving van expert systems shells.

Beslissingsondersteunend systeem 151 attributen vindt plaats in de object editor. Binnen deze editor worden ook de overervingsrelaties gedefinieerd. 3. Regel editor Level5 Object onderscheidt regels voor achterwaarts en voorwaarts redeneren 80. De regels voor achterwaarts redeneren worden rules genoemd en die voor voorwaarts redeneren demons. Met de regel editor kunnen beide categorieën van regels worden gedefinieerd en aangepast. Bij het definiëren van een nieuwe regel levert Level5 Object een sjabloon voor een nieuwe regel. Dit verkleint de kans op fouten. In de regel editor worden eveneens de methods gedefinieerd. 'When changed methods' beschrijven procedures die worden geëvalueerd als de waarde van het bijbehorende attribuut verandert. Een dergelijke procedure kan bijvoorbeeld worden gebruikt om de redelijkheid van de door de gebruiker ingevoerde gegevens te toetsen 81. 'When needed methods' beschrijven procedures die worden uitgevoerd wanneer het inferentiemechanisme een waarde voor het bijbehorende attribuut moet vaststellen. 4. Display editor. De display editor vormt een grafische omgeving waarbinnen dialoog- en weergaveschermen kunnen worden ontworpen. Deze schermen worden gebruikt voor het weergeven van conclusies of voor het stellen van een vraag aan de gebruiker. De velden die in een dialoogvenster worden gedefinieerd zijn gekoppeld aan bepaalde attributen. Met de display editor wordt inhoud gegeven aan de gebruikersinterface zoals die te zien zal zijn tijdens de consultatie van het systeem. In het gebruik van een kennissysteem probeert het inferentiemechanisme feiten af te leiden (zie paragraaf 3.5.1). De mogelijkheden hiertoe zijn niet beperkt tot voorwaarts en achterwaarts redeneren. In Level5 Object zijn er diverse manieren waarop de waarde van een attribuut kan worden vastgesteld. (1) Context: de waarde van het attribuut is al eerder in dezelfde consultatie vastgesteld. De waarde is dus al bekend en hoeft geen tweede keer te worden vastgesteld. (2) When Needed: Er kan ook een procedure zijn gedefinieerd om een waarde vast te stellen, een dergelijke procedure wordt beschreven in een 'when needed method'. (3) Rules: In de kennisbank kunnen regels zijn gedefinieerd die het attribuut in hun conclusie hebben. (4) Querie: Wanneer het systeem geen waarde vast kan stellen, kan de gebruiker worden gevraagd een waarde in te voeren. Bij deze vragen wordt in eerste instantie uitgegaan van 80 Dit onderscheid leidt tot de beperking dat dezelfde regel niet in zowel voorwaarts als achterwaartsredeneren kan worden gebruikt. 81 Indien nodig kan vervolgens een foutmelding worden gegeven of om een bevestiging worden gevraagd.

152 Hoofdstuk 5 voorgedefinieerde standaard formuleringen, deze formuleringen en de bijbehorende vensters kunnen later naar eigen wens worden aangepast. (5) Default: Tenslotte kan er een default-waarde zijn gedefinieerd. Indien het inferentiemechanisme geen waarde kan vaststellen via één van de andere manieren, dan wordt de default-waarde gebruikt. Het inferentiemechanisme probeert deze mogelijkheden in de genoemde volgorde. Deze volgorde kan worden veranderd indien men bijvoorbeeld wil dat eerst de gebruiker wordt gevraagd. Als de gebruiker het niet weet kunnen alsnog regels en methoden worden geëvalueerd. Een belangrijke functionaliteit van een expert system shell is de interface naar andere bestanden teneinde gegevens uit die bestanden te benaderen en te gebruiken. Level5 biedt de mogelijkheid database- en tekstbestanden te gebruiken. Daarnaast kunnen de ODBC drivers 82 worden gebruikt om diverse databases te benaderen. Met deze drivers kan middels een SQL-opdracht worden gezocht naar records in de database die aan bepaalde zoekcriteria voldoen (SQL staat voor Standard Query Language, zie bijvoorbeeld De Rooy, 1987; Vasta,1985). Naast het uitlezen van gegevens uit (data-)bestanden kan een extern programma worden aangeroepen. Tevens kunnen gegevens worden uitgewisseld tussen Level5 Object en in Microsoft C ontwikkelde programmatuur. Vanuit de actieve kennisbank kan een andere kennisbank worden opgestart. Dit commando maakt het mogelijk de kennisbank op te delen in subsystemen (zie paragraaf 3.5). Een subsysteem handelt een deelprobleem af en vervolgens wordt het volgende subsysteem opgestart, waarbij feiten worden overgedragen. Naast het bestandsformaat (*.KNB) waarin Level5 Object de kennisbanken automatisch opslaat, is het ook mogelijk de inhoud weg te schrijven naar een ASCIIbestand. De inhoud van de kennisbank wordt dan in het PRL-formaat (Production Rule Language) weggeschreven. Dit ASCII-bestand kan worden veranderd met een andere editor en vervolgens weer worden ingelezen in Level5 Object. Dit heeft als voordeel dat veranderingen kunnen worden aangebracht zonder dat op elk moment de interne consistentie van de kennisbank wordt getoetst. Het bestand dat later weer wordt geïmporteerd moet uiteraard wel consistent zijn. De PRL-syntax biedt een zeer heldere structuur. De bovenstaande voordelen hebben geleid tot de keuze van Level5 Object voor Windows. Level5 biedt een goede omgeving voor het ontwikkelen van expertsystemen. Level5 Object integreert de mogelijkheden van object georiënteerd ontwikkelen en expertsystemen. De regels en methoden kunnen op een prettige manier in een heldere syntax worden ingevoerd in de regel editor. Level5 Object biedt de voordelen van het werken onder Windows zoals een consistente interface, het schakelen tussen meerdere toepassingen en het uitwisselen van gegevens. In de 82 Een ODBC driver is een dynamic link library (DLL) die door een windows programma gebruikt kan worden om toegang te krijgen tot bepaalde gegevens. Elk database management systeem vereist een eigen ODBC driver.

Beslissingsondersteunend systeem 153 volgende paragrafen wordt het ontwerp van de verschillende modulen beschreven en wordt aangegeven hoe deze in het prototype zijn gerealiseerd. 5.6 Module ter selectie van de planningmethode Bij de projectplanning kan gebruik worden gemaakt van verschillende methoden (zie hoofdstuk 4 en de beschrijving van de cases). Deze methoden hebben alle bepaalde sterke en zwakke punten. Hiermee zijn de methoden in bepaalde situaties beter toepasbaar dan in andere (Heemstra, 1990; Haas en Wubbels, 1990). Het kennissysteem adviseert bij de evaluatie van de geschiktheid en de keuze van de methode. Op basis van bepaalde karakteristieken van het project en de omgeving, en met name de onzekerheid en de doelstellingen van een planningsessie, is de ene methode beter toepasbaar dan de andere. De module ter selectie van de meest geschikte planningmethode is een overkoepelende module die aan het begin van een consultatie vaststelt welke planningmethode in die specifieke situatie dient te worden toegepast. De module is overkoepelend in de zin dat de overige modulen vanuit deze module worden geactiveerd. De module bevat regels ter selectie van de meest geschikte planningmethode voorafgaand aan het uitvoeren van het planningproces. Het doel van deze module is dan ook het geven van adviezen aan de gebruiker welke planningmethode moet worden gehanteerd. Bij de keuze van de planningmethode kan het terminologieprobleem een rol gaan spelen. Verschillende gebruikers kunnen een ander idee hebben bij één en dezelfde term. Als er onduidelijkheden bestaan over de gehanteerde termen moeten meer gedetailleerde vragen worden gesteld die intern worden 'gemapped' op meer omvattende termen. Intern wordt dan met deze omvattende termen geredeneerd terwijl extern, oftewel naar de gebruiker toe, met de waarneembare c.q. vraagbare termen wordt gewerkt. Het redeneren door het inferentiemechanisme staat niet onder invloed van deze problematiek. Het probleem wordt pas duidelijk als het inferentiemechanisme vragen gaat stellen aan de gebruiker teneinde feiten vast te stellen. Een voorbeeld hiervan is de situatie waarin de gebruiker wordt gevraagd in welke fase het project zich bevindt. Bij een dergelijke vraag speelt de terminologie van de specifieke systeemontwikkelingsmethode een rol. RULE termvergelijking IF NOT SDM 2 AND altprojectfase IS technisch ontwerp THEN projectfase IS detailontwerp Kader 5-1: Vergelijken van termen. Als voorbeeld is in Kader 5-1 de vergelijking tussen termen van SDM 1 en SDM 2 weergegeven. De termen van deze twee methoden worden hierbij op elkaar herleid. De fase technisch ontwerp van de oude SDM specificaties wordt bijvoorbeeld herleid tot de fase van detailontwerp van SDM 2.

154 Hoofdstuk 5 ATTRIBUTE altprojectfase COMPOUND analyse, functioneel ontwerp, technisch ontwerp, ontwikkelen en testen, invoering TEXT In welke van de hier genoemde fasen bevindt het project zich? SEARCH ORDER CONTEXT QUERY ATTRIBUTE projectfase COMPOUND definitiestudie, basisontwerp, detailontwerp, realisatie, invoering TEXT In welke van de hier genoemde fasen bevindt het project zich? SEARCH ORDER CONTEXT RULES QUERY Kader 5-2: Alternatieve termen. Hierbij wordt de gebruiker twee alternatieve benamingen aangeboden (zie Kader 5-2) waarbij die set wordt gekozen die het dichtst bij het dagelijks taalgebruik ligt. Bij de selectie van de meest geschikte methode spelen een aantal factoren een rol. Deze factoren hebben onder andere betrekking op: de omvang van het project, de fase van het project, het doel van de planning, het al dan niet beschikbaar zijn van een systeemontwikkelingsmethode, het type project, de onzekerheid die met het project gepaard gaat. De onzekerheid wordt op haar beurt weer bepaald door een aantal factoren. De hiervoor genoemde factoren worden achtereenvolgens behandeld. De omvang van het project. Indien het project een geringe omvang heeft, wordt in de praktijk geen gedetailleerd plan opgesteld (in het systeem wordt een grens van enkele mensmaanden gehanteerd). In een dergelijke situatie wordt een grove schatting gemaakt, zonder de in het vorig hoofdstuk beschreven planningmethoden toe te passen (zie Kader 5-3).

Beslissingsondersteunend systeem 155 RULE kleine projecten IF omvang IS klein THEN NOT planningprobleem ELSE planningprobleem Kader 5-3: Omvang project De fase waarin het project zich bevindt. Bij de uitvoering van een project worden een aantal projectfasen onderscheiden. Bij het toepassen van SDM worden achtereenvolgens de volgende fasen doorlopen: definitiestudie, basisontwerp, detailontwerp, realisatie en invoering. De fase waarin het project zich bevindt is op een aantal manieren van invloed op de projectplanning. Ten eerste geldt dat de reeds doorlopen fasen niet meer in de projectplanning opgenomen hoeven te worden. Indien het project zich reeds in de realisatiefase bevindt dienen alleen de bouw, het testen en de implementatie in de planning opgenomen te worden. Daarnaast is de fase van invloed op de detaillering van de planning. Indien het project zich in de offertefase bevindt zal een globale schatting worden gemaakt van de diverse fasen (zie Kader 5-4). Daarentegen wordt in de realisatiefase een gedetailleerd plan opgesteld. Tenslotte kan de fase van het project van invloed zijn op de toepasbaarheid van de methode. Zo kan een gedetailleerde FPA-begroting bijvoorbeeld niet worden opgesteld voordat er een functioneel ontwerp is gemaakt. RULE offertefaseregel IF fase IS offerte THEN doel IS globaal AND planningmethode is globale regels Kader 5-4: Projectfase Doel van de projectplanning Indien het doel van de projectplanning is het opstellen van een gedetailleerd plan en schedule dan worden andere methoden gebruikt dan wanneer een globale schatting van de kosten en doorlooptijd wordt gevraagd. Voor een globale begroting wordt gebruikgemaakt van een begrotingsmethode. Voor een gedetailleerd plan wordt gebruikgemaakt van netwerkplanningmethoden. De netwerkplanningmethoden kunnen hierbij ook in meer of mindere mate gedetailleerd worden ingevuld (zie paragraaf 5.9 voor een verdere invulling hiervan). Het al dan niet beschikbaar zijn van een systeemontwikkelingsmethodiek. Een systeemontwikkelingsmethodiek beschrijft de fasen en activiteiten die binnen het systeemontwikkelingstraject moeten worden doorlopen (zie paragraaf 4.5). Deze beschrijving dient als uitgangspunt bij de specificatie van een activiteitennetwerk bij het toepassen van een netwerkplanningmethode (zie paragraaf 5.9 voor een verdere invulling hiervan).

156 Hoofdstuk 5 Het type project. Bij een opdracht waar al enigszins duidelijk is wat voor soort systeem moet worden gerealiseerd, kan een systeemontwikkelingsmethode worden toegepast waarbij de fasen en activiteiten van tevoren redelijk goed zijn te specificeren. Indien de opdracht meer onderzoeksachtige kenmerken omvat dan is van tevoren niet goed aan te geven welke fasen en activiteiten moeten worden doorlopen. In een dergelijke situatie wordt het voortraject als een afzonderlijk project gedefinieerd (Keen, 1987). Dit betekent dat de latere fasen van een systeemontwikkelingsmethode nog niet worden gepland (zie paragraaf 5.9). RULE onderzoeksproject IF projectfase IS definitiestudie AND type_opdracht IS onderzoeksopdracht THEN deelplanning := TRUE ELSE deelplanning := FALSE Kader 5-5: Type project Onzekerheid De onzekerheid is van invloed op de toepasbaarheid van de methoden. Met name PERT is gerelateerd aan de onzekerheid van activiteiten. Heemstra (1990) onderscheidt drie categorieën van onzekerheid: de proces-, de produkt- en de middelenonzekerheid. De produktonzekerheid is afhankelijk van de mate waarin er duidelijke en volledige informatiebehoeften bestaan en de mate waarin deze stabiel zijn. De procesonzekerheid is afhankelijk van de mate waarin het mogelijk is het proces bij te sturen en de mate waarin men inzicht heeft in het proces. De middelenonzekerheid wordt bepaald door de waarde en de beschikbaarheid van de benodigde middelen. Op basis van deze criteria stelt het inferentiemechanisme de meest geëigende planningmethode vast. Hierbij wordt de gebruiker om feiten gevraagd die relevant zijn voor de classificatie van het probleem (zie Figuur 5-4). Figuur 5-4: Een voorbeeldvraag