Deze blog is geschreven door Bert Franken van BBusi. Bert is bereikbaar via Linkedin en e-mail.
Bij deze mijn laatste blog van een drieluik over een aantal belangrijke aspecten die de basis vormen voor een geslaagde inrichting van (Functioneel) beheer. In de eerste blog ging het over het vaststellen en afstemmen van het 'wat hoort bij wie' van Functioneel-, Applicatie- en Technisch Beheer (en overige rollen): welke rol doet wat? In de tweede blog heb ik aandacht gevraagd voor het expliciet benoemen van de objecten waarvoor je als beheerder verantwoordelijk bent: wat beheer je? In deze blog wil ik het hebben over het 'met wie?’. Oftewel: met welke andere partijen heb je te maken als het gaat om het beheer van 'jouw' objecten?
Al eerder heb ik het gehad over de 'beheerketen' waar je als Functioneel Beheer deel van uit maakt. In zijn meest simpele vorm bestaat de keten uit: Business - Functioneel Beheer - ICT (Applicatie- en Technisch Beheer). Het hoeft denk ik geen betoog dat dit een wel erg simpele voorstelling van zaken is, dus moeten we hier zeker grondiger naar kijken. Ook omdat, naar mijn ervaring, veel zo niet de meeste 'problemen' i.r.t. het beheer niet vanuit de techniek ontstaan, maar vanuit de organisatie daaromheen. Dus onduidelijkheid m.b.t. zaken als taken, verantwoordelijkheden en bevoegdheden. Maar ook m.b.t. hoe de onderlinge samenwerking plaats dient te vinden. En onder welke voorwaarden. Hier is een sterke relatie met mijn eerste blog, waar het gaat over duidelijkheid m.b.t. de verschillende rollen. Je bent er echter niet met het benoemen van iemand in een rol. Ook al geef je daar een keurige rol- en functiebeschrijving bij. Zeker niet in een dergelijk complex vakgebied als beheer. Sterker nog: het is mede de veelheid aan betrokken partijen en de onderlinge 'dwarsverbanden' die het beheer zo complex maken. En dus duidelijkheid noodzakelijk maken. De 'implementatie' van deze rollen in de staande organisatie verdient dus meer aandacht en zorgvuldigheid dan het nu vaak krijgt.
Hoewel het zo vanzelfsprekend lijkt, komt het nog vaak voor dat beheerders dit soort zaken niet goed in beeld heeft. Laat staan op een goede (goed te communiceren en over te dragen) wijze hebben vastgelegd. Het blijft vaak bij algemeenheden ('iemand bij die afdeling / leverancier'), aannames ('Volgens mij doen zij .....') en iedere keer weer improviseren. Hier kun je gelukkig als individuele beheerder zelf het nodige aan doen, door jouw eigen beheeromgeving in kaart te brengen. En als alle collega's dat doen, die van de hele afdeling. Een buitengewoon simpele hulpmiddel die je daarvoor kunt hanteren is het onderstaande 'spin in het web plaatje'.
Het plaatje benoemt verschillende 'categorieën' van personen (of rollen) waar je als Functioneel Beheerder mee te maken hebt / kunt hebben. Uiteraard pretendeert dit plaatje niet volledig te zijn. Vandaar ook de 'puntjes' rechtsonder. Bij het zelf invullen kun je het schema natuurlijk aanpassen op jouw specifieke situatie. De bedoeling is simpel: vul jezelf in het middelste vakje in en ga de relevante categorieën zo concreet mogelijk maken. B.v.: bij de categorie 'Collega FB'er' gaat het m.n. om de beheerders van systemen die interfacen met de jouwe. Benoem deze dus met naam en toenaam, en het betrokken beheerobject. En zo vul je de voor jou relevante partijen in vanuit hun rol t.a.v. de door jou beheerde objecten. Bij het invullen zul je al snel te maken krijgen met een belangrijke complicerende factor: het betreft zelden een 1 op 1 situatie, maar doorgaans een 1 op n.
Afhankelijk van het aantal en soort objecten die je beheert, zul je met meerdere partijen te maken hebben die dezelfde rol uitvoeren. Maar dan voor verschillende objecten. Als je b.v. meerdere applicaties beheert zul je al gauw met verschillende gebruikers(groepen) en ook Applicatie- en Technisch beheerders te maken hebben. Inzicht en duidelijkheid is dus ook hier van groot belang. Hiervoor zijn vaak meerdere plaatjes (b.v. per applicatie) nodig. Iedere pijl die je in het schema trekt geeft een relatie aan. Elke relatie dient, samen met de betrokken partij, te worden afgestemd (Wat houdt de relatie in? Wat verwachten we van elkaar? Hoe communiceren we en waarover? Etc.). Relevante zaken moeten worden vastgelegd en de relatie moet worden beheerd. Dus ook 'relatie' is een beheerobject. En zeker voor Functioneel Beheer niet de minst belangrijke.
Een aantal categorieën uit het plaatje heeft denk ik een korte toelichting nodig: 'Applicatiebeheer' en 'Technisch Beheer' kunnen beide zowel een interne partij betreffen als een externe. Dus kan doorgaans de categorie 'Leverancier' hierin worden ondergebracht. Het betreft dus de rol die deze leverancier vervult. Hetzelfde geldt in principe voor de rol 'Ontwikkelaar', die ook zowel intern als door een externe leverancier ingevuld kan worden. Het expliciet benoemen van 'Opdrachtgever' is helaas nog in vele organisaties nogal een uitdaging. Het betreft die business manager, doorgaans de eigenaar van het ondersteunde bedrijfsproces, die de eisen bepaalt aan zowel de ondersteunende IV als aan het beheer daarvan. De feitelijke 'klant' van de beheerorganisatie. Deze rol is lang niet altijd expliciet belegd, en waar belegd niet altijd echt ingevuld. Gezien hier de belangrijkste kaders en richtlijnen voor de dienstverlening door Functioneel Beheer vandaan moeten komen, is het van groot belang dat deze rol wel goed wordt vormgegeven.Veel organisaties hebben met 'Controleurs' te maken die ook een beroep doen op de informatievoorziening. Te denken valt aan partijen als accountants, juristen, wetgevende instanties etc. Deze worden door de beheerorganisatie vaak als erg lastig ervaren omdat ze ad-hoc komen met vragen om informatie / rapportages die niet zo 1,2,3 te genereren is / zijn. Maar er wel doorgaans 'gisteren' moet zijn. Kortom: veel extra werk en irritatie.
Als je echter beter kijkt, blijkt dat deze partijen niet vaak ad-hoc maar doorgaans periodiek, en dus planbaar, deze informatie nodig hebben (b.v. maand- en jaarwerk). En vaak ook dezelfde informatie omdat moet worden vergeleken met vorige periodes. Er is alleen bij het inrichten van de systemen daar geen rekening mee gehouden. En dat maakt het dus lastig. Deze partijen moeten dus worden beschouwd als een aparte categorie gebruikers, met hun eigen wensen en eisen. Als hun 'specs' gewoon worden meegenomen, dan wordt de overlast een stuk minder. Moeten ze wel eerst in kaart zijn gebracht en de relatie ingericht. Hetzelfde geldt voor de categorie 'Lijn Management'. Dit kan zowel je eigen leidinggevende zijn als anderen die vooral stuurinformatie nodig hebben. Neem deze mee bij het opstellen van specificaties etc. en je zult relatief eenvoudig aan de meeste vragen kunnen voldoen. Al zal ad-hoc nooit helemaal uit te sluiten zijn, maar dat is dan meer uitzondering dan regel.
Nog een tip bij het invullen: streef geen perfectie na voordat je er mee naar anderen gaat. De ervaring leert dat het een goed bruikbaar 'praatplaatje' oplevert om met de verschillende relaties het gesprek aan te laten. Hierbij kan het zelfs handig zijn om een incompleet plaatje te hebben, omdat de ander dan zijn / haar inbreng kan hebben en het echt een gezamenlijke actie wordt om het goed geregeld te krijgen. Ook maakt het plaatje de complexiteit van dit onderdeel van het beheervak inzichtelijk door alle relaties expliciet te maken. Vaak is dit voor anderen (inclusief je eigen leidinggevende) een eye opener. Daarnaast levert het de nog aanwezige 'gaten' op (rollen die niet of slechts gedeeltelijk zijn ingevuld). Met dat resultaat kan dan actie worden ondernomen om de gaten te dichten.
Resumerend: na de verschillende rollen te hebben vastgesteld en de generiek daarbij behorende taken, verantwoordelijkheden en bevoegdheden (blog deel 1), de beheerde objecten expliciet te hebben benoemd (blog deel 2) en de concrete koppeling tussen object en ingevulde rol te hebben gemaakt (blog deel 3) is onze basis gelegd. Met deze basis als gemeenschappelijk referentiekader en ijkpunt kunnen we vervolgens gaan bouwen aan processen, afspraken, communicatiestructuren etc. En deze vervolgens beheren en verder uitbouwen.Door de duidelijkheid die is gecreëerd tijdens het leggen van de basis zal het bouwen, hoewel hier ook niet te licht over gedacht mag worden, veel minder discussie opleveren, een kortere doorlooptijd kennen en een grotere kans op succes hebben dan zonder deze basis.
Het is niet anders dan in de bouw: een investering in een goede fundering betaalt zich tijdens de bouw en bewoning meer dan terug.