Deze blog is geschreven door Bert Franken.
In de pakweg 25 jaar waarin ik met het inrichten / professionaliseren van ons mooie vakgebied bezig ben, ben ik in de gelukkige omstandigheden geweest dit bij een aantal zeer uiteenlopende en boeiende organisaties te mogen doen. Ook heb ik nogal wat veranderingen in Informatievoorzieningsland voorbij zien komen. Zelf ben ik ooit met beheer begonnen bij een voormalig overheids rekencentrum, volgepakt met mainframes en net het ponskaarten tijdperk ontstegen. Het client-server concept was toen 'hot'. Wat is er een hoop gebeurd tussen toen en zaken als Cloud, SAAS, Agile etc. die nu de uitdagingen voor beheer vormen.
Wat in al die tijd echter niet erg is veranderd, is de 'overflow' aan jargon, afkortingen en begrippen die ons vakgebied kenmerkt. Het is eerder steeds erger geworden. Je zou dus denken dat bij activiteiten m.b.t. beheer (b.v. het inrichten van beheerprocessen en -organisaties) het creëren van duidelijkheid over deze 'overflow' hoog op de agenda zou staan. In de praktijk merk ik daar echter weinig van. Je hoort heel vaak het argument: 'Maar dat weet iedereen toch? Iedereen weet toch wat Functioneel Beheer is?'.
Het is al zeer de vraag of dat waar is. Maar ook al zeggen mensen dat ze weten wat het is, is dat hun eigen perceptie. Vaak gebaseerd op de manier waarop het binnen hun organisatie / afdeling wordt uitgevoerd, in de persoon van b.v. de Functioneel Beheerder. De kans is echter klein dat deze perceptie geheel overeenkomt met die van b.v. een collega van een andere afdeling. Je merkt het ook aan discussies over het vakgebied op platforms als LinkedIn, waarbij het vanuit deze verschillende percepties meer gaat over de invulling van de functie dan van het vakgebied. De vraag 'Wat is Functioneel Beheer?' wordt al snel beantwoord met 'De Functioneel Beheerder doet ...'.
Als proef op de som daag ik de lezer bij deze uit: vraag een aantal (collega) beheerders om onafhankelijk van elkaar een korte definitie van het werkwoord 'beheren' op te schrijven. Voor mensen die hier de hele dag mee bezig zijn zou dit toch appeltje-eitje moeten zijn nietwaar? Leg de resultaten vervolgens naast elkaar. De kans is erg groot dat de verschillende definities onderling sterk zullen verschillen. Ongetwijfeld zullen ze allemaal een aspect van 'beheren' betreffen, maar om vervolgens met droge ogen te kunnen zeggen dat verdere afstemming en consensus niet handig zou zijn voor een dergelijk cruciaal begrip...
Het bovenstaande klinkt misschien een beetje flauw, maar ik merk in mijn praktijk helaas maar al te vaak dat er veel problemen, misverstanden, miscommunicatie etc. ontstaan omdat men niet vooraf dit soort duidelijkheid heeft geschapen. Ook sneuvelen met veel enthousiasme opgezette inrichtings- en verbetertrajecten hier op. Dat is erg jammer, en volgens mij grotendeels onnodig. Men neemt helaas doorgaans niet de moeite om eerst vragen te beantwoorden als: wat verstaan we binnen onze organisatie onder Functioneel- , Applicatie- en Technisch Beheer? Welke activiteiten vallen bij ons binnen de verschillende vakgebieden? In beide gevallen: zowel nu (IST) als gewenst (SOLL).
Het resultaat moet een gemeenschappelijk referentie- en begrippenkader zijn, waarover consensus bestaat tussen de betrokken belanghebbenden. Een dergelijk gemeenschappelijk kader vormt immers de basis voor zaken als proces- en organisatie-inrichting, communicatiestructuren en onderlinge afspraken. Zaken die qua invulling in de praktijk nogal eens te wensen overlaten.
Het is belangrijk om dit kader voorafgaande aan een inrichtings- of verbetertraject met alle relevante stakeholders af te stemmen. Dit vereist wel een investering aan de 'voorkant'. Dat dat vaak niet strookt met de wil (of opdracht!) om snel 'meters te maken' besef ik, maar deze investering verdien je tijdens de uitvoering meer dan terug. Het alternatief is dat deze discussie met een beetje pech opnieuw moet worden gevoerd bij iedere 'inrichtingsvraagstuk' (Wie doet wat? Wie vult welke rol in? Wie is waar verantwoordelijk voor? Wat betekent dat voor de concrete invulling?). En dat kost een veelvoud aan tijd, nog afgezien van de risico's voor zaken als een eenduidige structuur en standaardisatie binnen beheer.
Je kunt pas een goed gebouw neerzetten als de fundering goed is. Dat geldt dus ook voor het 'beheer gebouw', zeker gezien het grote aantal belanghebbenden die ieder hun eigen kijk op de materie hebben. Een gemeenschappelijk referentie- en begrippenkader is daarbij essentieel. Modellen als BiSL, ASL en ITIL kunnen hier zeker bij helpen. Daarbij moet de focus wel liggen op de verschillende vakgebieden en niet de (potentiële) onderliggende functies. Dus niet: wat doet de Functioneel Beheerder? Maar: waaruit bestaat het vakgebied Functioneel Beheer? Denk daarbij in termen als rollen, taken, verantwoordelijkheden en bevoegdheden. En hoe verhoudt zich dat tot de overige stakeholders zoals de Business, Applicatiebeheer en Technisch Beheer in de keten van de Informatievoorziening? Wat betekent dat voor de samenwerking en communicatie tussen de verschillende partijen?
Pas als daar consensus over is, kun je kijken naar de voor jouw organisatie beste invulling in functies, processen, communicatie, et cetera. En hoe ontwikkelingen als DevOps, Cloud etc. in te passen. Wees daarbij ook niet bang om de bestaande situatie te 'herijken' o.b.v. deze, mogelijk nieuwe, inzichten. Zeker als de vraag 'Waarom doen we het nu eigenlijk zo?' wordt beantwoord met 'Omdat we het al .. jaar zo doen'.