Deze blog is geschreven door Bert Franken van BBusi. Bert is bereikbaar via Linkedin en e-mail.
In mijn vorige blog heb ik het gehad over het vaststellen en afstemmen van het 'wat hoort bij wie' van Functioneel-, Applicatie- en Technisch Beheer als basis voor inrichtingstrajecten. Waarbij ik onder 'inrichting' zowel een eerste opzet van een beheerorganisatie versta als het aanpassen van een bestaande beheerorganisatie. In deze blog wil ik het hebben over het 'waarvoor'. Hoewel deze vraag uiteraard ook relevant is voor Applicatie- en Technisch Beheer, wil ik me nu uitsluitend richten op Functioneel Beheer. Met 'waarvoor' bedoel ik: voor welke objecten wordt het beheer uitgevoerd? Oftewel: wat beheer ik als Functioneel Beheerder?
Hoewel het zo vanzelfsprekend lijkt, is het van groot belang om de vraag zo expliciet mogelijk te beantwoorden. Zeker voor Functioneel Beheer omdat de beheerde objecten niet altijd even 'tastbaar' zijn als b.v. een server of een laptop. Ik zeg ook zeer bewust 'lijkt' omdat, als ik daarnaar vraag bij de organisaties waar ik kom, bijna geen enkele Functioneel Beheerder over een overzicht beschikt van de concrete objecten waar hij / zij voor verantwoordelijk is. Als ik de vraag stel wordt deze doorgaans beantwoord met: 'Ik ben verantwoordelijk voor systeem X'. Nou is volgens mij het kenmerk van een systeem dat deze bestaat uit een aantal verschillende, aan elkaar gerelateerde, componenten. Uiteraard is het afhankelijk van de gehanteerde definitie (standaarddefinities zijn dus ook handig!), maar er zitten altijd ook technische (ICT) componenten in. Hiervoor ben je als Functioneel Beheerder niet verantwoordelijk. We zijn het er dan ook doorgaans snel over eens dat 'systeem' misschien niet zo'n handig 'kapstok' is. Nee, dan maar 'applicatie'. Dit is wel de meest voorkomende 'koppeling' met Functioneel Beheerder. Zowel in functiebenamingen als vacatures. 'Ik ben / wij zoeken een Functioneel (Applicatie)Beheerder applicatie Y'. Dus je beheert en bent verantwoordelijk voor de applicatie.
Maar is dat wel zo? Een applicatie is immers software. En volgens mij beheert Functioneel Beheer geen software (al ben ik Functioneel Beheerders tegengekomen die sourcecode doorpluizen). Dat is toch echt het terrein van Applicatiebeheer. De koppeling met een applicatie is wel begrijpelijk omdat dat ook voor gebruikers herkenbaar is. De applicatie is immers het hulpmiddel waarmee ze hun werk doen. Dus als er iets is met de applicatie, dan zoek je de bijbehorende Functioneel Beheerder op. Het probleem kan echter zijn dat er, zeker bij de business, een verkeerd verwachtingspatroon ontstaat (b.v. qua 'aansprakelijkheid') als niet duidelijk wordt gemaakt wat wel en wat niet m.b.t. de applicatie daadwerkelijk bij Functioneel Beheer ligt en wat bij Applicatie- en Technisch Beheer. Oftewel wat de rol van de verschillende partijen hierin is en de onderlinge afhankelijkheden. Zie hier ook de relatie met mijn vorige blog. Ook helpt het niet voor de beeldvorming van Functioneel Beheer als een businessgerelateerd vakgebied. Je beheert immers een 'ICT component', dus hoor je bij ICT.
Maar wat beheer je dan?
In grote lijnen is Functioneel Beheer verantwoordelijk voor het verzorgen van bij de bedrijfsprocessen aansluitende informatievoorziening. Cruciale vragen daarbij zijn dan: 'Wat kan de business met een bepaald IV hulpmiddel (b.v. een applicatie)?' En 'Welke toegevoegde waarde biedt het hulpmiddel voor het betrokken bedrijfsproces?'. Oftewel: 'Welke functionaliteit wordt met welke kwaliteit geboden en sluit dit aan bij wat de business nodig heeft?'. ’Functionaliteit' is dus het object waar het om gaat. In relatie tot een applicatie beheer je dus als Functioneel Beheerder de geboden functionaliteit en het aansluiten daarvan bij de behoeften vanuit het ondersteunde bedrijfsproces. Om dit goed te kunnen, moet je een goede samenwerking realiseren met degenen die de andere aspecten van de applicatie (software, databases, benodigde infrastructuur) beheren.
Dit is ook de reden dat ik eerder heb gesproken over minder 'tastbare' beheer objecten. Dit geldt dus zeker voor Functioneel Beheer. Bij anderen, maar ook binnen Functioneel Beheer, kan dit leiden tot nogal wat verschillende percepties m.b.t. 'Functioneel Beheer objecten'. Met alle gevolgen van dien. Duidelijkheid en afstemming is dus nodig. Ondanks het feit dat dergelijke objecten lastiger te concretiseren zijn en meer uitleg bij de 'omgeving' behoeven, is het cruciaal dat deze expliciet worden gemaakt. Zeker ook in het kader van het eerder genoemde verwachtingspatroon. Als het lukt de bovenstaande verantwoordelijkheid (uitgangspunt is bedrijfsproces en niet ICT) tussen de oren te krijgen, dan worden de verwachtingen reëler en is de kans een stuk kleiner dat Functioneel Beheer wordt gezien als een verlengstuk van ICT.
Naast 'functionaliteit' is ook het object 'data' vaak bron voor verwarring. Daar waar het gaat om operationele data in de bedrijfsprocessen (zoals NAW gegevens, voorraadgegevens, personeelsgegevens, financiële gegevens etc.) berust de inhoudelijke verantwoordelijkheid bij de business. M.a.w.: dit soort data mag nooit door Functioneel Beheer gemanipuleerd (opgevoerd, gewijzigd, verwijderd) worden. Dit gebeurt in de praktijk helaas maar al te vaak, al dan niet in opdracht van de business. Het beheer bestaat uit het monitoren, het constateren van zaken als vervuiling en redundantie, het informeren en adviseren van de gegevenseigenaar n.a.v. geconstateerde afwijkingen en het (laten) verzorgen van corrigerende maatregelen (b.v. opschonen). Dat laatste alleen na expliciete opdracht en onder verantwoordelijkheid van de gegevenseigenaar.
Daar waar het parameterisering betreft kunnen de rollen anders liggen. Hierover moeten dan goede afspraken gemaakt worden. Nog voor de volledigheid (en misschien ter geruststelling): uiteraard beheert Functioneel Beheer ook de nodige zeer tastbare objecten. Denk b.v. aan allerlei vormen van beheer-, gebruikers-, en testdocumentatie. In alle gevallen is het belangrijk, zowel voor jezelf als voor (afspraken met) de overige betrokkenen dat de beheerde (deel)objecten en de daarvoor verantwoordelijke partijen zo expliciet mogelijk worden vastgesteld. Denk daarbij overigens ook aan de rol van 'eigenaar' (Is de systeemeigenaar ook altijd de eigenaar van de data? En wie is eigenaar van de bijbehorende ICT componenten?).
Ik zou zeggen: als je die nog niet hebt, begin met het opstellen van een eigen lijstje en ga daarmee ter afstemming op pad. Te starten bij je eigen leidinggevende. Het zou zomaar kunnen dat dat tot de nodige verrassingen leidt. Zowel bij anderen als bij jezelf. Het kan in ieder geval een eerste aanzet zijn tot (meer) duidelijkheid.
Gepubliceerd in
