Tijdens onze meest recente pizzasessie 'Functioneel Beheer: regie in de keten' brak er een interessante discussie los over het als functioneel beheerder al dan niet loslaten van de inhoud ten faveure van de regie. Zou een organisatie gebaat zijn bij een pure regierol van de functioneel beheerder of kan deze niet zonder de inhoud? Ik kom steeds meer tot de conclusie dat het scheiden van de regie en de inhoud zeker geen slechte zet hoeft te zijn.
Maar wat is dan precies de inhoud waar je als functioneel beheerder mee te maken krijgt? Vaak hoor en lees je dat een functioneel beheerder zo’n beetje het schaap met de niet 5 maar 25 poten dient te zijn. Naast een flinke lijst met softskills (communicatief vaardig, organisatiesensitief, analytisch sterk) moet men bekend zijn met de branche, de diverse processen en de daarbij veelgebruikte applicaties. En niet zelden vraagt men ook een brede kennis van de ict-sector en -oplossingen in zijn algemeenheid. Voor veel bedrijven blijkt het lastig om deze profielen in te vullen, veel schaapachtige functioneel beheerders met 25 poten zijn er helaas niet…
Regie
Wat behelst dan de regie? Hierbij gaat het om het organiseren, het regelen. Denk hierbij aan het organiseren van gebruikersoverleggen, het deelnemen aan of voorzitten van een CAB (Change Advisory Board), het adviseren van het management, het aansturen van de ict-leveranciers, enzovoorts. Hierbij is de inhoud van minder belang maar ligt de focus veel meer op het beheersen en faciliteren van de processen zelf. De benodigde kennis van de inhoud ligt bij de inhoudelijk specialisten, de functioneel beheerder is de regisseur en het verbind element tussen de stakeholders.
Ik zie en hoor bijna dagelijks dat de functioneel beheerder te vaak voor zowel de inhoud als de regie verantwoordelijk is. Regie is in veel gevallen zelfs ondergeschikt aan de inhoud. Men is vaker bezig met incidenten oplossen dan met het regisseren van deictT-keten. Ik zie veel te vaak dat functioneel beheer ook blijft "hangen" op de operationele laag van het BiSL-model. Gebruikersondersteuning en specificeren is over het algemeen redelijk tot goed ingeregeld, maar goed contractmanagement, behoeftemanagement en ketenpartnersmanagement vanuit functioneel beheer zie ik zelden.
Scheiden dan maar?
Om te komen tot een goede afdekking van zowel de operationele, tactische als strategische laag van het BiSL-model kan het goed werken om de regierol en de inhoudelijke rol te scheiden. Maar hiervoor bestaan randvoorwaarden die moeten worden ingevuld: zonder een bepaalde volwassenheid van zowel de functioneel beheer organisatie als het (ict-) management en de (ict-)leveranciers is het lastig de regierol goed in te vullen. Men is namelijk sterk afhankelijk van het verkregen mandaat en de aanwezige acceptatiegraad. Zijn de randvoorwaarden goed ingevuld dan is men wel in staat deze scheiding aan te brengen en zal men zien dat de gehele organisatie zal profiteren van een beter opererende ict-keten. Daarnaast wordt het ineens ook een stuk makkelijker om nieuwe functioneel beheerders te vinden….
Interessant verhaal! Ook ik merk dat regievoering binnen het IT landschap steeds belangrijker gaat worden. Ook binnen mijn vakgebied, software testen, is te zien dat het onderwerp kwaliteitsregie vorm krijgt en is te merken dat vergelijkbare discussies ontstaan! Ten aanzien van testen is hier recentelijk een whitepaper over geschreven. Is iets dergelijks ook vanuit Functioneel Beheer beschikbaar? Zeker gezien de raakvlakken tussen de twee vakgebieden kan kruisbestuiving interessant zijn!
Soms lijkt het of Functioneel Beheer tussen wal en schip valt in plaats van dat zij de broodnodige brug slaat tussen business en ICT. Met name in organisaties waar Functioneel Beheer onder de verantwoordelijkheid van de ICT (!) Manager (die dan opeens Manager Informatievoorziening en ICT heet, maar nog steeds een ICT pet op heeft) is geplaatst gaat het vaak mis. In die gevallen dient de gebruikersorganisatie haar wensen (als besluiten) in bij ICT en niet bij FB. FB is dan slechts een oplosgroep bij applicatieproblemen en krijgt dan nauwelijks de kans de vraag in kaart te brengen, een analyse te verzorgen, aan goed requirements management te doen en een fatsoenlijk voorstel en FO te realiseren. Laat staan dat er goede testcases gebouwd kunnen worden.
De complexiteit van een referentiemodel als BiSL zorgt er al snel voor dat beperkte keuzes worden gemaakt en de praktische scope van Functioneel Beheer niet ten volle in beeld komt. Men concentreert zich op gebruikersondersteuning en belegt bijvoorbeeld requirements en projectmanagement bij ICT beheer.
Functioneel Beheer is inhoud en regie. Dit dient dan wel georganiseerd te zijn via (een beperkt aantal) heldere processen die een duidelijke onderlinge relatie hebben, die goed beschreven zijn en welke de afdeling in staat stellen om enerzijds de gebruikersorganisatie te ondersteunen en haar te helpen bij het bepalen van de juiste gewenste functionaliteit en anderzijds de ICT organisatie aan te sturen zodanig dat deze in staat is de juiste oplossing te ontwikkelen of in te kopen en deze adequaat te leveren en te beheren.
Een methode die hier pragmatisch mee omgaat is FSM dat is gebaseerd op en analoog aan BiSL en andere bruikbare best practices. FSM kent 6 processen die zich laten kenmerken door de begrippen afspreken (contract management), leveren (support management), herstellen (error management), wijzigen (requirements management), voorkomen (demand management) en informeren (registration management).