Van ad hoc functioneel beheer naar proactief beheer en regie

Waar functioneel beheer nog niet optimaal georganiseerd is, merk je vaak dat er veel ad hoc gewerkt wordt. Gebruikers die aan het bureau komen en gelijk geholpen worden. Vragen via de mail, die direct opgepakt worden. En nieuwe tickets die gelijk afgehandeld worden. Oftewel: reactief functioneel beheer. 

Door altijd te reageren op wat er op je af komt, lukt het vaak niet om zaken structureel te verbeteren of op te lossen. Je blijft in dienst staan van de gebruiker, in plaats van de organisatie. Je blijft ‘brandjes blussen’, ad hoc werken en er verandert niks.

Soms komt het ook voor dat functioneel beheerders zich bezig met de inhoud. Declaraties die niet kloppen en door functioneel beheer aangepast of uitgezocht worden. Data die niet klopt en door functioneel beheer aangepast wordt. Of zelfs fouten die een gebruiker heeft ingevoerd, verbeteren. Het sluipt er vaak in. Maar daarmee houd je je bezig met het werk van een ander en is er minder tijd voor écht functioneel beheer.

“Ja, maar bij ons is het anders” “ja, maar we doen het altijd al zo” of “ja, maar bij ons moet het wel zo omdat…” Er zijn altijd redenen te verzinnen waarom je zo door moet blijven gaan. Misschien ken je als team (nog) geen andere manier. Weet je niet hoe je een nieuwe werkwijze moet adopteren. Of misschien verwacht de gebruiker van je dat je altijd voor ze klaar staat. Deze redenen komen altijd vanuit de beste bedoelingen: de gebruiker tot dienst zijn.

Als je als team reactief blijft werken, kom je niet verder. Of er komt zelfs een moment dat het niet meer voldoende is. Stel dat wet- en regelgeving wordt aangepast, en je moet als functioneel beheerteam aanpassingen doorvoeren om hieraan te voldoen. Daarvoor moeten processen onder de loep genomen worden, er moet met stakeholders gesproken worden en de processen moeten gewijzigd worden (of misschien moeten de processen eerst nog wel in kaart gebracht worden). En de applicatie moet weer aansluiten op de proceswijzigingen. Maar ondertussen, staan ook de gebruikers nog aan je bureau en verwachten ze direct geholpen te worden. Je komt tijd te kort: of je laat gebruikers opgeholpen achter, of je kan niet op tijd voldoen aan de wet- en regelgeving. Zo zijn er meer voorbeelden te bedenken waarin je in de knel komt wanneer je reactief beheer voert.

Kortom: je hebt geen regie over functioneel beheer. En dat is zonde, want functioneel beheer kan zo veel meer waarde toevoegen in de organisatie.

Van brandjes blussen naar structurele oplossing

Als gebruikers problemen ervaren en je lost het direct voor je op voor de specifieke situatie waarin ze zich bevinden, mis je vaak het onderliggende probleem. De gebruikersvraag blijft regelmatig terugkeren. En inmiddels weet je goed hoe je kan je helpen, dus weten ze jou ook te vinden. Maar in dit soort situaties is het belangrijk om het onderliggende probleem te ontdekken. Anders blijft de gebruiker aan je bureau komen. Ga eens in gesprek met de gebruiker. Wees nieuwsgierig, stel je onwetend op en achterhaal het onderliggende probleem. Stel open vragen over het proces wat doorlopen wordt, waarom het zo gedaan wordt en wat de wens van de gebruiker is. Zo kun je het onderliggende probleem structureel oplossen. 

Alle informatie verzamelen voor optimale afhandeling en prioritering

Het functioneel beheerteam bepaalt de prioriteit van een wijzigingsverzoek. Niet de gebruiker. Als functioneel beheerderteam heb je zelf het meeste inzicht in wat er allemaal speelt, en wat cruciaal is voor de continuïteit van het proces. En je kan dan ook het beste zelf bepalen welke prioriteit je aan een wijzing geeft en wanneer deze wordt opgepakt. De meeste gebruikers vinden hun eigen probleem of verzoek urgent. En natuurlijk kan het voorkomen dat er zich issues voordoen die direct opgelost moeten worden. Maar ook bij “anders kan ik mijn werk niet doen”, is het belangrijk om door te vragen naar het onderliggende probleem. Misschien legt dat een andere of mindere mate van urgentie bloot. 

Om de prioriteit goed te bepalen, is het belangrijk om goed vast te leggen wat er aan de hand is en waar een oplossing aan moet voldoen. Daarvoor kan een user story uitkomst bieden: als [rol van de gebruiker], wil ik [gebruikerswens], zodat [reden waarom de wijziging nodig is]. Vul deze aan met acceptatiecriteria. Zo heb je een volledig beeld van de wens en waar de oplossing aan moet voldoen. Belangrijk is wel, dat je dit voor elke wijziging op een uniforme manier doet. Maak hier dus afspraken over binnen je team.

Prioriteren

Verzamel deze user stories op één plek. Een scrumbord, binnen topdesk, Microsoft planner – zo lang er maar overzicht is en ruimte om alle relevantie informatie in te voeren. Het prioriteren van een wijzigingsverzoek kan op meerdere manieren gebeuren. Bijvoorbeeld door een Product Owner, met hulp van een teamleider of een per één of twee weken gezamenlijk met het team. Dan is het wel belangrijk dat het team het eens is over het antwoord op de vraag: waar is functioneel beheer van? (En waar niet). Sowieso is dat een onmisbare gezamenlijke visie om als functioneel beheerteam de regie te pakken.

Onze inspiratiesessie zorgt voor een gezamenlijke visie op het vak >

Als je wijzigingen gaat prioriteren kan je criteria hanteren die je houvast geven. Een impactanalyse: wat is de impact van deze wijziging. Zo prioriteer je niet op gevoel, maar met de juiste afwegingen. Voorbeelden van onderdelen in een eenvoudige impactanalyse:

• Impact op de business: kan één iemand zijn werk niet doen, ligt een proces stil of krijgt de organisatie een boete? Hoe meer impact, hoe meer prio de wijziging heeft.
• Tijdsdruk: Is er een wettelijke deadline, of start er over 2 weken een project wat niet zonder deze wijziging kan? Als er geen tijd is om te wachten, kan de wijziging voorrang krijgen.
• Aantal getroffen gebruikers: één medewerker, een hele afdeling, de hele organisatie? Hoe meer mensen er last van hebben, hoe hoger de prioriteit.
• Risico’s als je wacht: bijvoorbeeld financiële schade, datarisico, imago schade, fouten die groter worden als je niks doet. Hoe hoger het risico, hoe eerder je moet handelen.
• Complexiteit vs. effort: Soms zijn wijzigingen klein en kosten ze weinig tijd en moeite om op te lossen. Dan kan het slim zijn om dit eerst op te pakken, ook al is de impact lager. Quick wins kunnen zo een plek krijgen in de prioritering.
• Wettelijke of beleidsmatige verplichtingen: moet het volgens de wet? Dan moet het voor de ingangsdatum van de wet geregeld zijn. Op basis daarvan kan je bepalen of het nu moet, of nog even kan wachten.

De Doelenpijl is een voorbeeld van een tool om wijzigingsverzoeken in te delen in planbare en niet planbare wijzigingen. Ook geeft deze een mate van urgentie aan. Als je de Doelenpijl combineert met een impactanalyse kan je de prioritering beter bepalen. 

Naar de doelenpijl >

Gebruikers opvoeden en communicatie

Om echt de regie te pakken of proactief te werken, is het noodzakelijk om je gebruikers op te voeden. Zeker als ze nu al gewend zijn om gelijk geholpen te worden. 

Als je als team je werkwijze wijzigt, is het belangrijk om je gebruikers hiervan op de hoogte te stellen, en uit te leggen waarom jullie anders gaan werken. Dan kan in meetings of bijvoorbeeld een algemeen bericht. Vertel ze waarom het nodig is, en ook (voor de gebruiker zelf belangrijk) hoe zij als gebruiker profiteren van deze nieuwe werkwijze – de bekende 'what's in it for you'.

Je moet gebruikers vervolgens leren hoe ze op een goede manier een melding doen of een wijzigingsverzoek moeten indienen, wat moeten ze aanleveren en waar ze deze moeten indienen. Is een melding of verzoek niet compleet genoeg? Dan is het aan jou als functioneel beheerder om de benodigde informatie bij de gebruiker op te halen.

 Als je gebruikers gewend zijn om aan je bureau te komen is het belangrijk dat je je grens bewaakt. Je kan hen bijvoorbeeld verzoeken om een ticket in te dienen – zoals je (als het goed is) eerder hebt gecommuniceerd. Want alles wat je direct aan het bureau oppakt, saboteert je eigen prioritering. 

Je zal ongetwijfeld te maken krijgen met weerstand of onbegrip. Probeer daarin ook begrip te tonen voor de gebruiker en tegelijkertijd ook aan te geven waarom het van belang is (en wat het jullie als team én de gebruiker uiteindelijk oplevert). Je moet tenslotte ergens beginnen. Uiteindelijk zullen gebruikers ervaren dat dit ook voor hen werkt.

Tip: laat je niet verleiden door toch een wijzigingsverzoek aan je bureau op te pakken – tenzij de hele organisatie anders instort. Ze weten je in het vervolg te vinden en je creëert ook een verwachting: de volgende keer kan het ook vast even tussendoor.

Wijzigt er niet alleen iets in hoe jullie het werk doen, maar ook in wat jullie doen? Dan is het belangrijk om aan te geven waarom je bepaalde werkzaamheden niet meer uitvoert. Omdat het bijvoorbeeld geen functioneel beheertaak is, of omdat jullie als team niet verantwoordelijk zijn voor de uitvoering. Ook dit zal wat weerstand opleveren. Laat gebruikers niet zomaar aan hun lot over, maar leg ze ook uit hoe ze dit zelf kunnen doen. Of ga met ze in gesprek over een oplossing die de taak structureel makkelijker maakt.

Tip: het is belangrijk om goed contact te onderhouden met je stakeholders en gebruikers. Maar het kan in de ‘opvoedfase’ misschien ook zinvol zijn om eens in een andere ruimte of thuis te werken. Gebruikers moeten dan een melding maken of een wijzigingsverzoek indienen en kunnen niet aan je bureau komen.