Vaak krijgen we de vraag – wie maakt het functioneel ontwerp? Een veelgehoord antwoord is functioneel beheer. Het heet tenslotte ‘functioneel’ ontwerp? Na wat doorvragen blijkt vaak dat de vraag – wie maakt het functioneel ontwerp? – te herleiden is tot onduidelijkheid over de term ‘functioneel ontwerp’.
Want wat is dat eigenlijk, een functioneel ontwerp?
In de literatuur en op internet kom je definities tegen van de strekking “een beschrijving van de functies die een product dan wel dienst voor de gebruiker moet vervullen”.
De IT-professional ziet het functioneel ontwerp als een beschrijving op basis waarvan hij de software kan ontwikkelen. Een document met data flow diagrammen (DFD’s) of wireframes, zaken die voor functioneel beheer vaak te technisch zijn.
Zo’n functioneel ontwerp beschrijft vooral HOE het nieuwe of aan te passen systeem moet werken en daarmee wordt eigenlijk al duidelijk dat een functioneel ontwerp vooral iets voor de leverancier is. Want die gaat over het HOE.
Functioneel beheer houdt zich bezig met het WAT. Dat omschrijven we met ‘specificaties’ of ‘requirements’. Maar wat blijkt? In sommige organisaties noemen we nu juist die beschrijving ‘functioneel ontwerp’.
En zo is de spraakverwarring compleet.
Daarom gooi ik het graag over een andere boeg – vergeet de term ‘functioneel ontwerp’. Concentreer je op de inhoud van het document. Op de vraag wie het WAT en wie het HOE kan beschrijven. Het WAT is verantwoordelijkheid van de vraagorganisatie. De aanbodorganisatie is verantwoordelijk voor het HOE. De gebruikersorganisatie formuleert de vraag en functioneel beheer beschrijft dat zodanig dat de leverancier kan bedenken HOE dat te bouwen. En beschrijft dat zodanig dat functioneel beheer kan beoordelen of het is wat ze bedoelen.
De twee documenten die zo ontstaan vormen de kern van de afspraken tussen gebruikersorganisatie en de leverancier. Noem die documenten hoe je wil. Ik voel me, waarschijnlijk omdat ik ooit IT’er was, comfortabel bij ‘specificaties’ of ‘requirements’ voor het WAT en ‘functioneel ontwerp’ voor het HOE.
Maar welke benamingen je ook kiest, spreek goed af welk document welke naam krijgt. En leg de verantwoordelijkheid voor het maken en onderhouden van elk document waar het hoort.
Wil je weten hoe je tot een gedeelde terminologie kunt komen, zowel binnen je eigen organisatie als in het gesprek met je leverancier? Of ben je benieuwd naar onze aanpak om taken, rollen en verantwoordelijkheden op een eenduidige manier te beleggen? Neem dan contact met ons op en maak een afspraak voor een vrijblijvend gesprek.
