In deze blog duiken we dieper in de wereld van niet-functionele eisen (non-functionals) voor Functioneel Beheer. In voorgaande delen hebben we al enkele van deze eisen besproken. Er is al aandacht besteed aan de niet functionele eisen / acceptatiecriteria (non-functionals) in algemene zin in relatie tot een aantal specifieke criteria. Nu gaan we ons specifiek richten op de criteria die Functioneel Beheer zelf stelt aan op te leveren producten. Wat zijn de randvoorwaarden om het vak op een professionele manier uit te voeren? Ontdek hoe je deze eisen en acceptatiecriteria vaststelt en implementeert voor een kwalitatief beheerproces.
Hier vind je de andere blogs:
Deel 1: Niet-functionele requirements, vergeet ze niet!
Deel 2: Non-functionele requirements voor een (blije) beheer organisatie...
De vergeten eisen van functioneel beheer
Als Functioneel Beheerder stellen we eisen aan de producten die we opleveren, maar dit wordt vaak over het hoofd gezien. We zijn geneigd om onszelf te veel op de achtergrond te houden en richten ons vooral op de wensen van anderen. Toch is het essentieel dat we onze eigen eisen duidelijk maken, zodat we ons werk professioneel kunnen uitvoeren. Dit voorkomt verrassingen op het laatste moment en voorkomt dat we als vertragend worden gezien.
Het stellen van eisen is een belangrijk onderdeel van ons vak. Wanneer we onze behoeften niet duidelijk communiceren, kunnen we niet verwachten dat anderen ons werk serieus nemen. Het is tijd om als Functioneel Beheerder onze eigen randvoorwaarden te formuleren en niet langer te wachten tot de oplevering om onze eisen naar voren te brengen. Dit zal niet alleen onze positie versterken, maar ook het proces als geheel verbeteren.
De essentie van duidelijke eisen
Een van de belangrijkste voorwaarden om acceptatiecriteria op te stellen, is een heldere en gedeelde visie op de rol en toegevoegde waarde van Functioneel Beheer binnen de organisatie. Wat is onze bijdrage aan de bedrijfsvoering en de dienstverlening van de business? Wanneer dit duidelijk is en gedragen wordt door alle betrokkenen, kunnen de noodzakelijke randvoorwaarden worden vastgesteld. Dit resulteert in een set acceptatiecriteria die samen met de gebruikersspecificaties aan de uitvoerder worden overgedragen, waarbij Functioneel Beheer de verantwoordelijkheid heeft om deze bij oplevering te testen en goed te keuren.
Vragen die hierbij zeker gesteld moeten worden zijn:
- Wat is nodig om een opgeleverd product te kunnen accepteren?
- Wat is nodig om een product op een goede manier in beheer te kunnen nemen? (overdracht, implementatie)
- Wat is nodig om het beheer van een product op een goede manier uit te kunnen voeren?
Doorgaans komt hier, zeker als je ermee begint, ook eerst een redelijk stuk ‘huiswerk’ bij kijken, omdat eisen zo expliciet mogelijk geformuleerd moeten worden.
Ter illustratie een voorbeeld van hoe het niet moet: ik heb een aantal jaren geleden een organisatie mogen helpen bij het inrichten van het beheer als onderdeel van een project van enige tientallen miljoenen euro’s. In het programma van eisen stond keurig dat er functionele documentatie moest worden opgeleverd, wat de leverancier ook had toegezegd. Op enig moment wilden we toch wel graag de functionele documentatie gaan reviewen en hebben dus de betrokken leverancier daarnaar gevraagd. Deze gaf aan dat wij de documentatie al hadden. Hij had immers de helpschermen voor de gebruikers allang opgeleverd!
Wij hadden toch een wat ander beeld van functionele documentatie, maar gezien de formulering in het programma van eisen hadden we geen poot om op te staan.
Het ‘huiswerk’ had in dit geval moeten bestaan uit het vaststellen wat we verstonden onder functionele documentatie en het opstellen van de bijbehorende documentsjablonen en invulinstructies. En in het programma van eisen had vervolgens de toevoeging gedaan moeten worden: ‘conform de bijgeleverde standaards van Functioneel Beheer’.
Naast het feit dat er dan producten zouden zijn opgeleverd met de juiste toegevoegde waarde heeft een dergelijke aanpak ook het voordeel dat je zelf als Functioneel Beheerder minder ‘handjes’ hoeft te leveren tijdens een ontwikkeltraject. Als de beschrijving goed is kan immers iemand anders het ‘inklopwerk’ doen en kun jij je bezighouden met kwaliteitsborging.
Non-functionals voor Functioneel Beheer
Non-functionals voor Functioneel Beheer kunnen zowel hele concrete zaken zijn als documentatie, maar ook ‘te regelen’ organisatorische zaken. Voorbeelden zijn:
- Een ingericht Functioneel Beheer organisatie (aangeven wanneer iets is ‘ingericht’, zowel kwalitatief als kwantitatief)
- Logisch datamodel
- Autorisatie matrices
- Opgeleide gebruikers / key users
- (Werk)afspraken met overige betrokken partijen
- Handleidingen voor Functioneel Beheer
- Werkinstructies voor Functioneel Beheer
- Proces- en procedurebeschrijvingen
- Ingericht communicatiestructuur
- Afspraken- en besluitenlijst uit het project / ontwikkeltraject (wat is er gebeurd en waarom?)
Denk vooral breed bij het vaststellen van dergelijke eisen. Het bovenstaande is absoluut verre van uitputtend. En uiteraard kan een specifieke situatie leiden tot aanvullende (eenmalige) eisen. Denk dus nooit dat je bent met een standaardset. Of dat de hele set altijd in zijn geheel relevant zal zijn. Maak ook hierin per situatie bewuste keuzes.
Maar zet vooral Functioneel Beheer op deze wijze op de kaart als een echt en serieus te nemen vakgebied, met een belangrijke toegevoegde waarde. Mits aan een aantal eisen wordt voldaan.
Gepubliceerd in
