Het aantal storingen neemt toe, wijzigingsverzoeken blijven langer liggen, de kwaliteit van de dienstverlening neemt af en nieuwe releases bevatten steeds minder functionaliteit. Komt dit bekend voor? Dan is ook in de organisatie sprake van de beheerparadox.
De beheerparadox geeft de situatie weer die ontstaat wanneer de hoeveelheid te beheren functionaliteit (geleidelijk aan) is gegroeid zonder dat daar een parallelle groei aan beheer fte's tegenover staat. De beheerders hebben al hun tijd nodig om de bestaande functionaliteit operationeel te houden en zien geen mogelijkheden meer om aan vragen om vernieuwing tegemoet te komen. Dit is een gevaar voor de organisatie. Die groeit niet meer mee met de markt.
Inleveren
De gevolgen van de beheerparadox zijn zeer divers omdat organisaties op verschillende manieren met dit verschijnsel omgaan. Allereerst wordt er ingeleverd op beheer. Hierdoor wordt de kwaliteit van de dienstverlening minder, maar is men toch in staat om nog iets aan innovatie te doen. Op de beheerafdeling is ruimte om wat extra functionaliteit in beheer te nemen of extra functionaliteit te realiseren. Dit scenario leidt tot ontevredenheid bij de gebruikersorganisatie, want het gevolg van inleveren op beheer is altijd dat de kwaliteit minder wordt dan men gewend is. Een voorbeeld hiervan is dat de beheerafdeling minder inspanning levert ten aanzien van testtrajecten: misschien is men geneigd om bij kleine aanpassingen af te zien van het uitvoeren van een regressietest. Dit type beheerafdeling zal vaak 'ja' zeggen op steekhoudende verzoeken uit de gebruikersorganisatie.
Ook wordt er ingeleverd op innovatie. Hierdoor blijft de kwaliteit van de informatievoorziening overeind. Echter, men kan niet profiteren van de inzet van nieuwe functionaliteit die de werkprocessen van de gebruikersorganisatie kan verbeteren of efficiënter (dus goedkoper) kan maken. In deze situatie zal vaak 'nee' verkocht worden, met als argument dat er geen capaciteit is om aan vernieuwing te doen. Alle beschikbare capaciteit wordt ingezet om de bestaande functionaliteit zo goed mogelijk te beheren. Ook dit scenario zal leiden tot ontevredenheid van de gebruikersorganisatie. Immers, de kwaliteit die de beheerafdeling levert voldoet weliswaar aan de gestelde normen, maar omdat er geen enkele ruimte is voor innovatie en vernieuwing zal de gebruikersorganisatie het gevoel hebben achter de feiten aan te lopen en de slag om klanten en nieuwe omzet te verliezen.
Beheer elders
Een ander verschijnsel binnen de beheerparadox is dat nieuwe functionaliteit elders in de organisatie beheerd wordt. Dit is een valkuil die vaak voorkomt bij pakketselectie projecten. Doordat het beheer niet van te voren geregeld is wordt overdracht naar de beheerorganisatie lastig en blijft een projectmedewerker dit vaak doen. Vaak is deze projectmedewerker geen lid van het applicatiebeheer team. Dit betekent dat op diverse plekken applicatiebeheer wordt uitgevoerd, met verschillende werkwijzen en deskundigheid, hetgeen de continuïteit en uniformiteit in gevaar brengt. Bovendien wordt op deze manier verhinderd dat er inzicht bestaat in de reële kosten voor beheer. Veel van die kosten zitten namelijk in afdelingen die formeel geen beheer doen, waardoor deze kosten verborgen blijven. Een alleszins onwenselijke situatie.
Verder wordt er vaak spontaan gewerkt aan alternatieven voor nieuwe of vervangende functionaliteit, bijvoorbeeld in de office applicaties (bijvoorbeeld Access of Excel) of met open source, of zelfs door een partij in te huren die vervolgens iets maakt. Er wordt dus om applicatiebeheer heen gewerkt. Dit zorgt ervoor dat beheer wordt uitgevoerd op verschillende plaatsen in de organisatie, en dat het totaalbeeld over aanwezige functionaliteit ontbreekt. De formele beheerafdeling beheert alleen de bestaande functionaliteit van enige tijd geleden, en komt ook niet in aanmerking voor uitbreiding van capaciteit omdat er formeel geen werk bijkomt. In werkelijkheid wordt beheer ook uitgevoerd door niet-beheerders elders in de organisatie en vaak dus ook over functionaliteit die niet officieel bestaat.
Een laatste uitweg denkt men dan te vinden in outsourcing. Ontevredenheid met het interne applicatiebeheer kan leiden tot de wens tot uitbesteden. Dit lijkt een aantrekkelijk alternatief, maar wanneer er intern niets verandert zal de beheerparadox nog steeds optreden. Niet in het begin, maar zeker op langere termijn. De situatie die dan optreedt is wel helder, omdat de externe partij gewoon een prijskaartje hangt aan de dienstverlening die men afneemt. Wanneer de samenwerkingspartner merkt dat het beheer toeneemt zal dit tot een aanpassing in tarieven leiden. De interne organisatie wordt dus veel harder met de neus op de feiten gedrukt. De externe partij baseert de prijs eenvoudig op hoeveelheid te beheren functionaliteit. Neem die toe, dan stijgt de prijs. Waar de interne beheerorganisatie er voordien niet in slaagde duidelijk te maken dat uitbreiding van capaciteit nodig was vanwege uitdijende functionaliteit die beheerd moet worden, berekent de externe partij gewoon een meerprijs voor toegenomen functionaliteit.
Professionaliseren
De beste oplossing om te beheerparadox het hoofd te bieden is nog altijd het professionaliseren van de beheerorganisatie. Hierin speelt een aantal elementen een rol.
De eerste stap is het meetbaar maken van de functionaliteit. Dit kan door de functionaliteit in omvang uit te drukken. Een bekend voorbeeld hiervan is de functionaliteit uit te drukken in functiepunten. Bijvoorbeeld 1duizend functiepunten kosten 300.000 euro. Aan functiepunten kleeft het nadeel dat daar extra expertise voor nodig is en het tellen van punten ook tijd kost. Daarom is dit beter geschikt voor grotere organisaties met een groot applicatieontwikkel- en beheerteam. Een andere methode is om beheertijd te registreren en uit te splitsen naar specifieke taken. Vervolgens kan hier een waarde/prijs aan worden toegekend, die ook doorberekend zal gaan worden naar vernieuwde of nieuwe functionaliteit.
Vervolgens moet je de business deelgenoot maken van de gemeten functionaliteit. Communiceer breed dat de meerwaarde voor de organisatie uitgezet kan worden tegen deze meetwaarde om optimale toegevoegde waarde te leveren. Hierdoor zal de business inzicht krijgen in en begrip kweken voor de veelomvattendheid van beheerwerkzaamheden. Beheer moet zichzelf nog altijd beter profileren binnen de organisatie en voorkomen dat de afdeling wordt beschouwd als het 'afvoerputje' waar teveel oneigenlijke werkzaamheden worden neergelegd. Geef inzicht in waar de tijd aan opgaat in de beheerafdeling. Maak ook zaken als tijd gestoken in incidentbeheer en doorvoeren van fixes of reparaties helder. Hiermee wordt een klimaat geschapen van openheid en wordt ook de weg geëffend voor het praten over toename in beheer.
Stel ook een ratio in op basis van metingen over wat gemiddeld de toename in beheer is bij toename van de functionaliteit. Ervaringscijfers leren dat dit tussen de 10 en 30 procent ligt. Maak ook helder wat er precies aan beheerwerkzaamheden toeneemt om een structurele verhoging van het beheerbudget te billijken. Maak aan de andere kant duidelijk dat de beheerwerkzaamheden aan bestaande functionaliteit naar rato afnemen. Hoe langer functionaliteit in gebruik is, hoe stabieler die wordt en dus hoe minder er sprake is van incidenten en andere verstoringen.
Duidelijk communiceren
Tenslotte moet je duidelijk communiceren wat er nog mogelijk is aan toename van hoeveelheid functionaliteit en een drempel instellen voor wanneer er maatregelen genomen moeten worden. Spreek de business aan op redelijkheid en waarschuw voor optreden van de beheerparadox. Vertel ook duidelijk wat de waarde voor de business is van de toegenomen functionaliteit. Stel de vraag of het dan ook niet redelijk is dat voor de continuïteit daarvan een klein deel kan worden betaald voor beheer.
Henk Dubbelman, manager applicatiebeheer bij ROC Eindhoven
Ton Steijger, senior beheerconsultant en dienstcoördinator beheer bij Squerist
Een zeer herkenbaar verhaal. In begin 2007 hebben we bij Robeco dit onderkent door ook bij de Infrastructuur en beheerafdeling ons bezig te houden met gestructureerd testen van changes, infra projecten etc en de beheerorganisatie meer bij de projecten te betrekken. Hierdoor is aangetoond dat er minder Top incidenten zijn ontstaan. Ikzelf heb mede met de kennis van Sogeti deze Infrastructuur Test afdeling opgezet. De opgebouwde kennis kan ook bij andere worden toegepast.
@Wim
Is daarom bij Robeco dan ook het laatste redmiddel gebruikt: Outsourcing?
Beheerparadox, in mijn ogen ontstaat door het “te groot groeien” van een organisatie.
Te veel management en tussenlagen en eindeloze vergaderingen.
Met het gevolg: te weinig beheer.
Deze situatie geeft duidelijk aan dat er te veel mensen op de verkeerde plek zitten.
Houd organisaties klein en overzichtelijk.
De lijnen kort en gebruik de juiste mensen.
Dit soort dure paradoxen worden hierdoor vermeden.
Heel herkenbaar stuk: In een grote organisatie wordt vaak door tientallen ontwikkelaars tegelijkertijd aan grote projecten gewerkt. Wanneer het project vervolgens gereed is, komt het (steeds weer) neer op een beheerteam van een paar man, die alle (extra) functionaliteit met dezelfde beheercapaciteit in de lucht moeten houden.
Elk jaar wordt er weer nieuwe functionaliteit toegevoegd, maar voor extra beheercapaciteit is vaak geen geld: men wil wel eenmalige investeringen doen (projecten), maar geen extra vaste lasten (voor het in de lucht houden na de project fase)
Zeker is de geschetste situatie herkenbaar en ik kan me voor een groot gedeelte vinden in het artikel.
Waar ik wel moeite mee heb is de stelling dat nieuwe functionaliteit elders in de organisatie beheerd wordt, een valkuil is.
Natuurlijk moet een project, wat verantwoordelijk is voor selectie en implementatie, zowel aan de technische kant als aan de applicatie kant zorgen dat het bij de juiste organisatieonderdelen landt. Voor technische beheer is dat de ICT beheerorganisatie en voor applicatiebeheer is dat afhankelijk van de eigenaar van de applicatie.
Dat kan de business zijn; voorbeeld: de afdeling Financi?n is eigenaar van het financi?le pakket. De applicatiebeheerder is dan iemand die organisatorisch bij de afdeling Financi?n hoort. Wat wel belangrijk is dat de processen die te maken hebben met applicatiebeheer in de gehele organisatie uniform zijn ingericht en dat er ??n Procesverantwoordelijke is en die rol wordt uitgevoerd door iemand van de beheerorganisatie.
In het geval van telefonie applicaties en KA applicaties zoals bijv. Acces of Excel ligt het niet anders behalve dan dat de eigenaar van de applicatie de beheerorganisatie is. Dus de functionaliteiten worden door die afdeling beheerd, maar ook daar is bovenstaande stelling op van toepassing.
Voorwaarde is dat de projectleider van zo’n vernieuwing in functionaliteit tijdig zowel de beheerorganisatie als de applicatiebeheerder (uiteindelijk de klant) betrekken in het project. Dus de valkuil is meer dat het “mee laten denken over de beheersaspecten” en “overdragen aan beheer” veel te laat in het project aandacht krijgen.
Als Reactie op Hans Jennekens. De valkuil van het beheer elders in de organisatie is met name dat daar niet vakmensen het beheer gaan doen en het werk dat eigenlijk wel hun vakdiscipline is dan ondersneeuwt. De beheerparadox is dan dubbel hard opgetreden. In mijn organisatie verdronk daardoor Informatiemanagement in oneigenlijk beheer waardoor ze hun IM positie in de organisatie ook zagen verdwijnen.
Ik ben bedenker van de Paradox en co-auteur van het stuk.
Herkenbaar verhaal, niet alleen voor ontwikkeling en uitrol van applicaties maar ook voor het beheer van processen, sturing, stuurinformatie etc.. In het algemeen geldt dat er meer aandacht is voor het project dan het na live gang levend krijgen en houden van de gewenste richting. Juist beheer en beheersing, in breed perspectief, is noodzakelijk om echt goed in te voeren maar met name ook om vervolgens stap voor stap te verbeteren en zo steeds beter te worden. Met name in onze dienstverlening naar onze klanten, daar gaat het toch om. Te vaak wordt dit onderschat en wordt niet het optimaal rendement van de verandering bereikt. Het inrichten van een goede beheerorganisatie rondom processen, sturing en applicaties kan dit voorkomen en continue verbeteren stimuleren.
Ik ben medebedenker en -eigenaar van de aanpak iPM (integraal Performance Management, gericht op het verbinden van strategie naar de werkvloer middels processen, sturing en applicaties.
Goed artikel zeg.
Ik denk dat het helaas in veel organisaties voorkomt.
Onderkenning ervan is vaak de eerste moeilijke stap.
Bedankt hiervoor!
Hoezo, elk nieuw project en software-pakket verhoogt toch de efficiëntie en verminderd de beheersinspanning? Deze marketingpraat, die vooral op het management is gericht, rechtvaardigt toch een reductie van het aantal FTE’s in beheer?
Uit het goede artikel en de reacties blijkt dat de ICT-manager niet alleen boekhouder/budgetbeheerder moet zijn, maar met vakkundig inzicht ook zijn human resources moet managen. Hij/zij moet een streep door projecten durven trekken voordat beheersbaarheid een probleem wordt en waakzaam zijn dat verder verminderde dienstverlening door overbelasting van het personeel wordt voorkomen.