Drie beheermodellen in plaats van één

30 januari 2009
In de Automatisering Gids van 9 januari is een artikel opgenomen van Michiel Croon, Julius Duijts en Paul Leenards. Zij schrijven dat IT-organisaties door de traditionele positionering van frameworks als ITIL, ASL en BiSL volgens het model van Looijen, niet worden geholpen om verder te professionaliseren. Vervolgens pleiten ze ervoor om een aantal specifieke ideeën uit ASL over te nemen in ITIL, waardoor ASL overbodig wordt. Ik deel hun visie niet en licht dat toe aan de hand van vier stellingen.

Stelling 1 Applicatiemanagement (applicatiebeheer) is iets anders dan infrastructuurmanagement (technisch beheer).
Zonder compleet te willen zijn, noem ik enkele verschillen op het gebied van klanten, beheerobjecten, activiteiten en scope.
De klanten van applicatiebeheer zijn vooral functioneel beheer en, in mindere mate, technisch beheer. Functioneel beheer bepaalt hoe de functionaliteit eruit dient te zien, stelt functionele vragen en toetst en accepteert de producten van applicatiemanagement. Gebruikers hebben zelden rechtstreeks contact met applicatiebeheer. Als er een functionele productieverstoring is, dan wordt eerst functioneel beheer ingeschakeld. De klanten van technisch beheer zijn de eindgebruikers plus de andere beheerorganisaties. Als het bijvoorbeeld gaat over passwords, werkplekken, standaardsoftware en technische verstoringen, dan heeft de eindgebruiker rechtstreeks contact met technisch beheer.

Daarnaast geven de beide andere beheerorganisaties opdrachten en accepteren ze diensten en producten.
Applicatiebeheer gaat over het beheren en aanpassen van applicatieobjecten. Dat zijn naast de software ook de bijbehorende ontwerpen (functioneel, technisch) en datamodellen. Technisch beheer beheert de hardware (servers, netwerken, pc’s, randapparatuur) en de systeemsoftware en zorgt voor de operationalisering van de bedrijfssoftware (de exploitatie).
Natuurlijk is er een verschuiving gaande van maatwerk naar standaardapplicaties. Maar dat maakt applicatiebeheer niet overbodig:
  • Er is meer maatwerk dan men denkt.
  • Standaardpakketten, zoals ERP-systemen, moeten worden ingeregeld en worden meer ‘vermaatwerkt’ dan men vaak denkt. Daar-naast worden er vaak modules aangebouwd om aan te sluiten bij de specifieke klantsituatie en worden interfaces ontwikkeld.
  • Ook de softwareleverancier is een applicatiemanagementorganisatie. Deze zal zijn zaakjes goed voor elkaar moeten hebben, want de vele klanten zijn van zijn software afhankelijk.
  • Ten slotte zie je vaak dat leveranciers voor specifieke klantsituaties specifieke versies, ‘maatwerkpakketten’, of specifieke functionaliteit, ‘maatwerkmodulen’, uitleveren. Veel wordt ook bij een pakketimplementatieorganisatie belegd: de pakketleverancier levert een soort halffabricaat. De grens tussen maatwerk en pakket is veelal erg diffuus.

Overigens verschijnt er in april een nieuwe versie van ASL. Daarin zal meer aandacht worden geschonken aan de applicatiemanagementorganisatie als integrator, als schakel in een keten tussen leveranciers, tussenleveranciers en toeleveranciers.

Primaire taak van applicatiebeheer is het voortdurend aanpassen van de applicatie(objecten) aan de veranderende wensen, eisen en technische mogelijkheden. Technisch beheer past geen objecten aan, maar schaft ze aan en voegt ze in. In ASL zie je logischerwijs dus veel aandacht voor onderhoud van objecten: (functioneel) Ontwerp, Realisatie (technisch ontwerp, bouw, unittest) en Testen (technische en functionele systeem- of integratietest). Het beheren en onderhouden van software is anders dan het beheren en onderhouden van een technische infrastructuur.

Voor een organisatie technisch beheer geldt het principe ‘economy of scale’. Door grote volumes wordt het steeds goedkoper. Efficiency staat hoog in het vaandel. Bovendien luidt het adagium ‘rust in de tent’. Zodra er een verstoring is (een incident), dan moet die verholpen worden. Incidentmanagement, eventmanagement, helpdesk zijn belangrijke processen. Voor applicatiebeheer is efficiency wel relevant, maar niet het belangrijkst. Effectiviteit staat voorop: customer relationship, het reageren op wensen en eisen. Geen rust in de tent maar continue verandering. Tachtig procent van de energie zit in de onderhoudsprocessen.

Stelling 2 Businessinformatie­management (functioneel beheer) is iets anders dan IT-management (IT-beheer).
Functioneel beheer vertegenwoordigt de gebruikersorganisatie, is namens de gebruikersorganisatie opdrachtgever van IT en accepteert namens de business de producten en diensten van IT. Functioneel beheer ondersteunt de gebruikers bij het gebruik van de informatievoorziening (al of niet geautomatiseerd), specificeert de wensen en eisen en coördineert onder andere de acceptatietest. Logisch dat daar dus andere processen spelen, andere activiteiten plaatsvinden (zoals het aansturen van IT, het specificeren en het accepteren), andere objecten worden beheerd en een andere scope is. Eigenlijk geldt hetzelfde betoog als bij stelling 1. Ik zal dat hier dus niet herhalen.

Stelling 3 Het is logisch dat er drie beheermodellen zijn.
Croon, Duijts en Leenards pleiten voor het hebben van één model. Binnen een ander vakgebied heb je echter andere processen. Toeleveranciers als kabel- en telecombedrijven en computerbouwers zijn ook spelers in de keten. Geldt voor hen hetzelfde? Moeten zij ook in ITIL versie 4 passen? Z
ou men in de keten ‘graanteler, graanleverancier, meelfabriek, bakker, winkel, ontbijtservice’ ook behoefte hebben aan één overstijgend beheermodel? Waarschijnlijk niet. De banketbakkerij en de banketwinkel hebben een relatie: de een produceert het banket en de ander verkoopt het, maar een taart bakken is iets anders dan een taart verkopen. Als je de drie beheerdomeinen applicatiebeheer, technisch beheer en functioneel beheer in één model wilt stoppen, dan is slechts het gevolg dat de processen globaal worden beschreven.

Je ziet dat terug in ITIL. ITIL claimt de andere beheerdomeinen wel, maar mist de diepgang voor de specifieke applicatiebeheer- en functioneel beheerprocessen. In ITIL v3 zie je enerzijds een aanzienlijke uitbreiding van het aantal processen ten opzichte van ITIL v2, maar ITIL v3 mist nog steeds de diepgang ten aanzien van de richtinggevende processen uit het ASL-boek, en de onderhoudsprocessen, zoals realisatie en testen, worden nauwelijks uitgewerkt. Ik heb daar geen moeite mee. Laten we ITIL maar houden voor technisch beheer en ASL voor applicatiebeheer. In ITIL wordt geen duidelijk onderscheid gemaakt tussen de processen bij de opdrachtgever en de processen bij de IT-serviceprovider. Ik heb daar niet veel moeite mee. We hebben BiSL voor de vraagzijde, hoewel ik het jammer vind dat de rol van de opdrachtgever in ITIL v3 wordt onderschat.

Door aparte modellen te hanteren, kan men specifiek worden in de inhoud en wordt het makkelijker om best practices uit te wisselen. Het is dan ook niet verwonderlijk dat de ASL-BiSL Foundation leeft als nooit tevoren met leden als Getronics, Capgemini, Ordina, Atos Origin, Politie, Defensie, Achmea en Fortis. Het najaarscongres was drukker en werd positiever beoordeeld dan ooit. Per jaar doen zeker tweeduizend mensen het ASL-examen en een whitepaper over de vergelijking tussen ASL en ITIL v3 werd reeds meer dan dertigduizend maal gedownload. De meeste applicatiebeheerders en functioneel beheerders zijn blij met ASL en BiSL naast ITIL. Het zijn frameworks waarin men zich herkent. ‘Generiek’ leidt tot verlies van inhoud, ‘specifiek’ maakt verdieping mogelijk. Op de bijeenkomst van ISO in China, afgelopen november, werd veel interesse getoond in de NEN-norm 3434 voor applicatiemanagement, die is gebaseerd op ASL. Men erkende de toegevoegde waarde, juist op de specifieke inhoudelijke aspecten.

Stelling 4 De modellen sluiten op elkaar aan als je dat zelf wilt.
Croon, Duijts en Leenards schrijven “In plaats van te blijven zoeken hoe frameworks als ITIL en ASL op elkaar aansluiten, is het beter om vast te stellen hoe de business het best geholpen kan worden”. Ik deel die mening. Om die reden ook onderkennen ASL en BiSL een belangrijk concept: het serviceteam. In ASL is een pleidooi te vinden voor het op elkaar afgestemd houden van de dienstverlening van applicatiebeheer en technisch beheer. Daarvoor wordt het serviceteam beschreven. De auteurs schrijven dat “de business wil dat de leveranciers één loket en één aanspreekpunt bieden waar ze dag en, vaak ook, nacht naartoe kunnen”. Dat zal echter lang niet altijd zo zijn. Sterker nog, dat zal steeds minder zo zijn. De business kiest er bewust voor om bij veel verschillende leveranciers te ‘shoppen’: bij Microsoft, SAP, de CAP’s en Getronics’n en andere. Dat betekent dat de business zelf dat ene loket moet verzorgen. Oftewel: functioneel beheer inrichten. En dan nog is het vrijwel onmogelijk om alle leveranciers dag en nacht aan te spreken. Mag een informatie- of IT-manager Microsoft en SAP bellen of is hij een van de leden van een gebruikersgroep?

Voor het op elkaar afgestemd houden van de drie beheerdomeinen is het essentieel om te kijken naar de producten die uitgewisseld worden in plaats van te kijken hoe de processen zoveel mogelijk gelijkgetrokken kunnen worden. De beheerorganisaties leveren producten aan elkaar op en accepteren producten van elkaar. Aan die producten en aan die overdracht worden eisen gesteld. De interne processen moeten ervoor zorgen dat die producten effectief, efficiënt en correct tot stand komen en worden geleverd. Als iemand zijn auto in onderhoud heeft bij een garage (zeg maar: de functioneel beheerder, met het gezin als gebruiker), dan maakt het die persoon ook niet uit hoe de werkplaats (de serviceprovider) zijn processen heeft ingericht: als de auto maar hersteld is en op tijd en schoon wordt opgeleverd, conform de gemaakte afspraken, tegen een acceptabele prijs.

De serviceproviders technisch beheer en applicatiebeheer moeten zich dus druk maken over welke eisen, verwachtingen en behoeften de business, vertegenwoordigd door functioneel beheer, heeft en samen zorgen dat de dienstverlening optimaal is. Procesinrichting is daar een handig intern hulpmiddel bij, maar geen doel. Dat organisaties (en ook consultants en auditors!) de beheerframeworks een andere waarde toekennen, ligt niet aan die frameworks, maar aan degenen die ermee werken. Helaas ligt te vaak de nadruk op de procesinrichting. De scope is dus intern in plaats van op de klant gericht.

René Sieders (rene.sieders@thelifecyclecompany.nl) is principal consultant bij The Lifecycle Company. Hij is onder meer docent ASL en BiSL, lid van de werkgroep Standaardisatie van de ASL-BiSL Foundation en medeauteur van de NEN-norm 3434 voor applicatiemanagement.

 
Lees het hele artikel
Je kunt dit artikel lezen nadat je bent ingelogd. Ben je nieuw bij AG Connect, registreer je dan gratis!

Registreren

  • Direct toegang tot AGConnect.nl
  • Dagelijks een AGConnect nieuwsbrief
  • 30 dagen onbeperkte toegang tot AGConnect.nl

Ben je abonnee, maar heb je nog geen account? Laat de klantenservice je terugbellen!