Gebruikers schromen niet exotische eisen te stellen
De ICT-branche beschikt over diverse methoden voor het verzamelen en opstellen van (gebruikers)-eisen en wensen. Hierin zijn veelal de volgende drie deelprocessen te onderkennen, zoals beschreven door Van Vliet en Brinkkemper (Bedrijfskunde, nr.1, 2002): • Elicitatie: het begrijpen van het probleem waarvoor een (geautomatiseerde) oplossing wordt gezocht. • Specificatie: het beschrijven van het probleem. • Validatie: het onderling eens worden over het probleem. Voor de specificatie van eisen en wensen zijn verschillende methoden en technieken beschikbaar, variërend van beschrijvend in natuurlijke taal tot aan het wiskundig vastleggen. Een methode om tot het vastleggen van gebruikerseisen en -wensen te komen, staat beschreven in het artikel van Hoekstra en Kamphuis (Automatisering Gids, 28 maart 2002). Deze methodische benadering is in de praktijk niet altijd toereikend, zoals blijkt uit de reactie van Coesmans en Heijna (Automatisering Gids, 5 april 2002). Met name de veranderlijke wereld waarbinnen een project moet worden gerealiseerd blijkt een (negatieve) invloed te hebben op het tot stand komen van heldere, ondubbelzinnige eisen en wensen die weergeven wat de gebruiker echt wil. Met behulp van een iteratieve, incrementele aanpak wordt getracht deze veranderlijke wereld bij te blijven. De genoemde artikelen benaderen het probleem vanuit de projectinhoud. Maar een project staat niet op zichzelf, het moet middels een business-case bijdragen aan de bedrijfsdoelstellingen. Door een duidelijk (bedrijfskundig) kader te scheppen waarbinnen alle specificatiemethoden en -technieken kunnen worden toegepast, kan een betere, passende oplossing worden gerealiseerd. Dit kader zorgt ervoor dat de oplossing die wordt beschreven, in de vorm van eisen en wensen, in relatie staat tot de bedrijfsdoelstellingen en de daaruit voortgekomen business-case. Zowel ontwikkelaars als gebruikers hanteren meestal de mogelijkheden die de ICT biedt als referentie, zonder de gekozen oplossing direct in relatie te brengen met de business-case. Het feit dat het project voor, en soms ook door, de organisatie wordt uitgevoerd lijkt als voldoende garantie te worden ervaren voor de toegevoegde waarde aan de bedrijfsdoelstellingen. Wanneer bijvoorbeeld een internetapplicatie wordt ontwikkeld met als doel om als eerste een nieuwe markt te betreden, is de vormgeving en de totale functionaliteit in eerste instantie van ondergeschikt belang. Wanneer dit niet duidelijk is, is de kans groot dat er (te) veel tijd wordt besteed aan het realiseren van alle gewenste functionaliteiten in een moderne, interactieve internetpagina. Op deze manier schiet men zijn doel voorbij. Grote lijnen Voor het vaststellen van de geldende eisen en wensen wordt terecht een beroep gedaan op de (toekomstige) gebruikers van het beoogde projectresultaat. Opdrachtgevers blijken in de praktijk meestal minder bekend te zijn met de daarvoor noodzakelijke details. Zij houden zich bezig met de grote lijnen, zoals de business-case. Voor het expliciet maken van de eisen en wensen wordt dan ook al snel verwezen naar de (eind)gebruikers. Een voordeel van het betrekken van de gebruikersgroep is dat hun praktijkervaring onderdeel wordt van de gevraagde oplossing. Hiermee zijn de gebruikers van tevoren al gecommitteerd aan het projectresultaat. Zij helpen immers zelf het resultaat te definiëren. Toch schuilt hierin een groot risico, waardoor de inspanning om gezamenlijk tot de geldende eisen en wensen te komen niet het resultaat oplevert wat men ervan verwacht. Gebruikers schromen niet de meest exotische eisen en wensen in te dienen, vaak omkleed met praktijkvoorbeelden van situaties waaruit de noodzaak blijkt. Of het hier gaat om een uitzonderlijke situatie of een functionaliteit die dagelijks vele malen wordt gebruikt is meestal niet duidelijk. Uitzonderlijke situaties kunnen zo verworden tot de kern van de oplossing. Hierdoor is menig projectresultaat uitgegroeid van een eenvoudige softwareapplicatie ter ondersteuning van een administratief proces, tot een poging de gehele administratie te automatiseren. Dat een dergelijk project dan niet meer op tijd en binnen het beschikbare budget wordt geleverd, is een logisch gevolg. Moet de gebruiker er dan maar niet meer bij worden betrokken? Hoewel hiermee het bovenstaande probleem wordt voorkomen, is deze oplossing de bron van een ander serieus probleem. Wat voor soort product ontstaat er wanneer het zonder de inbreng van gebruikers wordt gerealiseerd? De kans is groot dat het een prima (theoretische) invulling is van de projectdoelstelling. Of het ook gaat beantwoorden aan de business-case is maar zeer de vraag. Om de baten te realiseren is het immers noodzakelijk dat het product ook daadwerkelijk bijdraagt aan de dagelijkse bedrijfsvoering. Daar wringt de schoen. Omdat de dagelijkse praktijk van de gebruiker niet bekend is, past de oplossing niet naadloos in de bestaande wereld. Het aanpassen van de werkelijkheid, of het alsnog bouwen van een oplossing die beantwoordt aan de dagelijkse praktijk, zorgt wederom voor een overschrijding van de gewenste doorlooptijd en het beschikbare budget. Denk in dit verband aan standaardsoftware, ontwikkeld vanuit een algemeen begrip van de beoogde doelgroep, maar bijna nooit volledig passend binnen een specifieke (gebruikers)organisatie. In veel situaties moeten bestaande processen worden aangepast of moeten extra maatwerkoplossingen aan het standaardpakket worden toegevoegd. Met name voor grote bedrijfsspecifieke toepassingen loopt de situatie al snel uit de hand. Hoe kan een project zich positioneren tussen het honoreren van alle exotische gebruikerseisen en wensen en een geïsoleerde (theoretische) oplossing? Het is duidelijk dat in veel gevallen de gebruikers betrokken moeten worden bij het definiëren van de eisen en wensen. Hierbij kunnen de bestaande methoden en technieken worden ingezet. Voordat gebruikers echter hun eisen en wensen kenbaar maken, is het van belang de referentiekaders van de gebruikers en de business op elkaar af te stemmen. Een belangrijke stap is het informeren van de gebruikers over de doelstelling van het project en de toegevoegde waarde voor de business. Door vooraf duidelijk te maken wat het doel van het project is en welke randvoorwaarden hierbij gelden, wordt het project duidelijk binnen (bedrijfskundige) kaders geplaatst. Hiermee wordt voorkomen dat de opgestelde eisen en wensen het beoogde doel voorbijschieten. Stel vooraf bijvoorbeeld de volgende vragen om de positie van de gebruiker te leren kennen: Welk referentiekader heeft een gebruiker? Hoe past zijn referentiekader op de doelstelling van het project? De antwoorden helpen de gebruiker op één lijn te brengen met de business-case. Als de gebruikersgroep bekend is met het referentiekader blijken de wensen en eisen die worden ingediend beter binnen de doelstelling van het project te passen. In die gevallen dat buiten de kaders wordt getreden, stuurt de gebruikersgroep zichzelf bij of kan worden aangegeven dat de toegevoegde waarde onvoldoende is in het kader van de doelstelling. Op deze manier wordt een oplossing gedefinieerd die de doelstelling ondersteunt. Afhankelijk van de dynamiek van de omgeving en de doorlooptijd van het project is het verstandig de gewenste oplossing in delen te realiseren. Deze iteratieve aanpak stelt men in staat om telkens opnieuw te toetsen of hetgeen opgeleverd moet worden voldoet aan wat de gebruikersorganisatie wil. Maar niet alleen de inhoud kan zo actueel worden gehouden, ook de bedrijfskundige kaders kunnen per increment worden getoetst aan de actualiteit. Met name deze kaders zorgen ervoor dat het projectresultaat blijft voldoen aan de veranderlijke behoefte van de gebruikers en de business. Soms kunnen de veranderde omstandigheden een bijstelling van de business-case of de projectdoelstelling vereisen. Door de toetsing aan de actualiteit tussen de verschillende incrementele opleveringen uit te voeren, wordt voorkomen dat er onnodige verstoringen tijdens de projectuitvoering plaatsvinden met alle kwalitatieve gevolgen van dien. Opgelegde kaders Is er verschil in de manier waarop de eisen en wensen binnen kaders geplaatst moeten worden als het gaat om pakketsoftware in plaats van maatwerksoftware? Bij maatwerk liggen alle mogelijkheden open. Dit wil zeggen dat er geen andere kaders zijn dan de kaders die de opdrachtgever zichzelf oplegt. Bij het tot stand komen van de eisen en wensen in een dergelijk traject is het duidelijk dat de doelstelling heel nauwgezet in het oog moet worden gehouden. De ogenschijnlijk ongekende mogelijkheden van de (informatie)technologie verleiden gebruikers en ontwikkelaars tot het ontwerpen van de meest mooie oplossingen. Of deze oplossingen ook altijd de juiste kosten/baten-verhouding hebben is maar zeer de vraag. Stel dat vanuit het perspectief van beheerkosten een mainframe- applicatie vervangen moet worden door een client/server-applicatie. Het integreren van grafische representaties die een pc-platform biedt, denk aan de dynamische webinterfaces, zijn weliswaar mogelijk maar passen niet binnen de doelstelling waarmee het project van start is gegaan. Dergelijke uitbundige applicaties kunnen de legacy-systemen in beheerkosten wel eens overstijgen. Pakketsoftware lijkt in staat het probleem, met exotische eisen en wensen van de gebruiker, te omzeilen. Hier worden immers door het pakket kaders opgelegd aan de opdrachtgever. In de praktijk blijkt dit echter geen garantie voor het binnen de kaders blijven van de eisen en wensen aan de pakketsoftware. Doordat pakketsoftware met behulp van vele parameters en instellingen aangepast kan worden, is ook hier de verleiding groot meer te automatiseren dan vanuit de doelstelling wenselijk is. Zelfs het uitbreiden van pakketsoftware met maatwerkoplossingen om sommige exotische (gebruikers)-eisen en wensen te realiseren, is hier geen uitzondering. Stel dat het management van een internationale organisatie besluit tot de invoering van een standaardpakket voor alle lokale kantoren. De organisatie heeft voor de langere termijn voor ogen dat een standaardpakket voor de gehele organisatie voordelen biedt op het gebied van managementinformatie en de implementatie van nieuwe kantoren. Omdat deze doelstelling niet bekend is bij de gebruikersgroep die de eisen en wensen voor het pakket moet opstellen, worden de eisen en wensen bepaald door de bestaande situatie waarin wordt gewerkt met maatwerkoplossingen. Het gevolg? Er worden veel aanpassingen gevraagd voor de specifieke eigen organisatie die niet in lijn liggen met de doelstelling van het management. Kortom, de ongekende mogelijkheden van de ICT brengen gebruikers en ontwikkelaars in de verleiding nieuwe en uitdagende oplossingen voor automatiseringsvraagstukken te bedenken. Zij worden verleid tot het opstellen en realiseren van eisen en wensen die weinig tot niets bijdragen aan de beoogde business-case. Naast het hanteren van een methodische aanpak voor het opstellen en bewaken van de eisen en wensen helpt het bespreken van duidelijke bedrijfsdoelstellingen (de business-case) om binnen de kaders te blijven. Op deze manier kunnen oplossingen worden gerealiseerd die optimaal bijdragen aan deze doelstellingen. Ing. J. J. Bergsma is als quality consultant werkzaam bij KZA BV, een toonaangevende organisatie gespecialiseerd in het toepassen van kwaliteitszorg binnen de ICT-sector.Een project en zijn omgeving