Blogs over functioneel beheer


Non-functionals? Ook gij Functioneel Beheerder! (Deel 3)


In vorige blogs is aandacht besteed aan de niet functionele eisen / acceptatiecriteria (non-functionals) in algemene zin in relatie tot een aantal specifieke criteria.
Deel 1: Niet-functionele requirements, vergeet ze niet!
Deel 2: Non-functional requirements voor een (blije) beheer organisatie...

Maar daarmee zijn we er zeker nog niet.

Hoe zit het namelijk met onze eigen eisen? Eisen en acceptatiecriteria (in principe allemaal non-functionals) die wij als Functioneel Beheer stellen aan op te leveren producten. Met als doel ons vak, want dat is het, op een professionele manier uit te kunnen voeren.

Als je het zo stelt lijkt het vanzelfsprekend dat je als vakman/-vrouw dit soort eisen paraat hebt. Maar in de ruim 30 jaar waarin ik bij een groot aantal organisaties in de Functioneel Beheer keuken mocht kijken, is gebleken dat dat zeker niet altijd het geval is.Non-functionals blog serie

 

Als typische dienstverlener zijn wij er vooral op gefocust om voor anderen te zorgen. En vooral anderen niet lastig te vallen met onze sores en behoeften. (Ook een beetje ons eer te na lijkt het.) Dus de gebruikers specificaties worden bij wijze van spreken tot op bit niveau uitgewerkt. Maar als ik, b.v. in het kader van een nulmeting, Functioneel Beheerders vraag naar hun set van eisen, word ik doorgaans glazig aangekeken. Hoe bedoel je? Wij eisen stellen? Hoe dan?

Wat zie je wel vaak gebeuren? Dat Functioneel Beheer vlak voor oplevering nog met allerlei zaken op de proppen komt. En het dan ook nog raar vindt dat ze als lastig en vertragend worden ervaren. Heel gek.

 

Ook hoor ik regelmatig dat ‘anderen’ Functioneel Beheer niet serieus nemen. Maar hoe serieus nemen we onszelf dan als we niet kenbaar maken waar we van zijn en wat daarvoor nodig is? Ook van anderen.

 

Hiermee komen we wel bij de belangrijkste randvoorwaarde om dergelijke criteria op te kunnen stellen: een heldere en gemeenschappelijke visie op de (gewenste) rol en toegevoegde waarde van het Functioneel Beheer. Waar zijn wij van en wat moet onze bijdrage aan (de bedrijfsvoering van en dienstverlening door) onze organisatie (de ‘business’) zijn?

Als dit helder is, en ook wordt gedragen door de ‘anderen’, dan kan worden bepaald welke zaken nodig zijn om als professioneel Functioneel Beheer hieraan te kunnen voldoen. Dit resulteert dan in een (standaard)set acceptatiecriteria die vooraf, samen met de gebruikers specificaties, aan de uitvoerder (projectleider, leverancier) worden opgeleverd. En uiteraard heeft Functioneel Beheer de verplichting deze ‘FB-delverables’ bij oplevering te testen en al dan niet te accepteren.

 

Vragen die hierbij zeker gesteld moeten worden zijn:

  1. wat is nodig om een opgeleverd product te kunnen accepteren?
  2. wat is nodig om een product op een goede manier in beheer te kunnen nemen (overdracht, implementatie)?
  3. wat is nodig om het beheer van een product op een goede manier te kunnen uitvoeren?

 

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 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.


Deze blog is geplaatst door Bert Franken en gepubliceerd op 11-07-19 08:45.

U kunt Bert Franken vinden op:


Onderwerpen: Functioneel beheer, blog, niet-functionele requirements, requirements, serie

Nieuwe blogs in uw mailbox?

Populairste items