Automatisering Gids

Drie beheermodellen naast elkaar zouden in de praktijk niet werken. Het zou tot tachtig processen leiden, wat effectieve inrichting en samenwerking onmogelijk maakt. In de discussie over de zin, onzin en praktische toepassing van drie aparte beheerframeworks, ITIL voor infrastructuurmanagement, ASL voor applicatiemanagement en BiSL voor businessinformatiemanagement, zijn al heel wat argumenten de revue gepasseerd. Graag wil ik, aan de hand van vijf stellingen, toch nog enkele essentiële punten belichten.

Stelling 1:Bij kleine aanbod­gestuurde organisaties werken dingen anders dan bij grotere vraag­gestuurde organisaties.Het pleidooi voor één model voor servicemanagent klopt redelijk als we het hebben over kleinere aanbodgedreven organisaties, zeg maar: het midden- en kleinbedrijf met een automatiseringsbudget van onder een ton, waar de leverancier bepaalt welke functionaliteit geboden wordt.

Je kunt dan centraal uniforme processen beschrijven en inrichten, die gebaseerd zijn op één beheerframework. Alle activiteiten zullen op elkaar afgestemd zijn, de lijnen kort, je kunt de administraties delen et cetera. Hoewel het bij gebruik van ASP al wat complexer wordt, omdat daar een veel grotere relatie ontstaat met de processen van de provider en je daar vraag en aanbod meer moet scheiden.

Bij grotere organisaties zoals banken, energiemaatschappijen en overheidsinstanties zul je vraag en aanbod meer scheiden en wordt de scheiding tussen applicatiemanagement en infrastructuurmanagement relevant. De macht in de organisatie ligt anders (meer diffuus), er zijn vaak meerdere locaties, meerdere beheerclubjes, meer leveranciers en de business bepaalt de benodigde functionaliteit. Daar kom je dus niet weg met één domeinoverschrijdend framework.

Stelling 2: Streven naar uniforme procesbeschrijvingen over domeinen heen is een nutteloze bezigheid.Het is een illusie om te denken dat het mogelijk is om over de drie beheerdomeinen uniforme processen te beschrijven. Dit zal zelfs niet eens lukken binnen één domein. Bij grotere organisaties bestaat doorgaans niet een 1:1:1-relatie tussen de beheerorganisaties. Functioneel beheer heeft meestal meerdere IT-leveranciers. Evenzo heeft applicatiemanagement doorgaans meerdere functioneel beheerders, maar ook toeleverende applicatiemanagementorganisaties en infrastructuurmanagementorganisaties waarmee het samenwerkt. En hetzelfde geldt voor technisch beheer dat met meerdere partijen zakendoet.

Elk van de partijen zal dus de processen anders willen en moeten inrichten, afgestemd op zijn specifieke business, klanten, leveranciers en situatie. Daarbij zullen de beheerorganisaties focussen op de externe interfaces: wat moet de ene beheerpartij aan de andere leveren en vice versa. Servicemanagers kunnen hun proces en hun templates niet opleggen aan al hun klanten noch aan al hun leveranciers.

Stelling 3: Tussen de beheer­organisaties zijn verschillende, doorgaans niet-lineaire, procesketens te onderkennen. De drie beheerdomeinen vormen niet één lineaire procesketen. Als voorbeeld kijken we naar onderhoud. Functioneel beheer stelt de behoefte vast (en dat is iets anders dan het reactief vastleggen van de vraag) en specificeert deze zo duidelijk en volledig mogelijk, zodat applicatiemanagement en infrastructuurmanagement op basis daarvan kunnen ontwerpen, realiseren en leveren.

Overigens: niet functioneel beheer is verantwoordelijk voor het opstellen of onderhouden van het functioneel ontwerp, maar applicatiebeheer (zie de ASL- en BiSL-modellen). Afhankelijk van het onderwerp en de constellatie zullen applicatiemanagement of infrastructuurmanagement de lead hebben en parallel of volgorderlijk aan het werk gaan om een en ander te leveren. Intussen zal businessinformatiemanagement (functioneel beheer) ook activiteiten uitvoeren zoals het aanpassen van de niet-geautomatiseerde informatievoorziening en het toetsen en testen van tussen- en eindproducten.

Transitie naar gebruik is voor businessinformatiemanagement een belangrijke activiteit, terwijl applicatiemanagement en infrastructuurmanagement zich met de (technische) implementatie bezighouden. Zo zie je dat alleen al binnen het onderhoud het proces zeker niet lineair is. Bij andere activiteiten zoals het afhandelen van verstoringen, vragen of serviceverzoeken zal dat doorgaans evenmin zo zijn. Dat maakt de noodzaak om één proces over de beheerdomeinen te definiëren ook erg klein. De processen lopen soms naast elkaar en soms in elkaars verlengde. Maar vaak ook vinden processen slechts in één of twee domeinen plaats en niet in alle drie.

Stelling 4: De beheermodellen kunnen goed naast elkaar werken. Het hanteren van drie beheermodellen zou niet werkbaar zijn en bovendien zou dat tot tachtig processen leiden, wat niet overzichtelijk meer is. De modellen zouden in de praktijk ook nog niet succesvol naast elkaar werken. Ik zie het anders. Elk beheerdomein heeft zijn eigen essentiële processen, die voor andere domeinen niet of minder relevant zijn. De rekensom van tachtig processen gaat dus niet op. In BiSL zitten rond de vijfentwintig processen, waarvan elf op het richtinggevend niveau (ook wel informatiemanagement genoemd) en ASL heeft er maar iets meer. Dat is dus redelijk overzichtelijk. Die aantallen hoeft men niet bij elkaar op te tellen.

Juist niet, want door zich als proceseigenaar en beheerder te houden bij de eigen leest hoeft men zich niet druk te maken over de processen van de ander. Waar elk der beheerpartijen zich wel druk over moet maken, is de uitwisseling en samenwerking op de interfaces. En daar zijn de beheermodellen ook erg geschikt voor. Samenwerken doet men niet door gezamenlijk in een keurslijf te gaan zitten, maar door afspraken te maken en consensus te hebben over wie wat doet en oplevert.

De ASL-BiSL Foundation reikt al jaren prijzen uit voor succesvolle implementaties van ASL en BiSL, en dat in organisaties waar het infrastructuurmanagement op basis van ITIL is ingericht. Maar wat ik bijvoorbeeld nooit zie, is dat functioneel beheer goed opereert op basis van een ITIL-implementatie.

Stelling 5: Beheerders zijn niet dom. Applicatiebeheerders kiezen niet voor ASL puur als vlucht vanwege de ITIL-terreur, maar vanwege de toegevoegde waarde van het framework. Functioneel beheerders zijn erg blij met BiSL omdat het aansluit bij hun praktijk. De ASL-BiSL Foundation heeft haar bestaansrecht allang bewezen, de aanmeldingen voor bijeenkomsten groeien nog steeds en de meeste beheerders zijn blij dat er eindelijk een model is specifiek voor hun beheerdomein. Niet als vlucht, maar om de inhoudelijke meerwaarde.

En daarbij weet de gemiddelde beheerder ook wel dat de interne procesinrichting niet het doel is maar een middel. Het echte doel is het komen tot goede en goedgeprijsde dienstverlening. Een beheerder zal zich dus ook niet druk maken over één of drie modellen. Als zijn model maar aansluit op zijn praktijk en als hij maar kan rekenen op de kwaliteit van de diensten en producten van de andere spelers: de resultaten van de processen van die spelers. En juist vanwege het belang van de business en de link met de praktijk kiezen de meeste applicatiebeheerders bewust voor ASL en functioneel beheerders en informatiemanagers voor BiSL.

René Sieders 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.

Slotwoord Hoving en Van Bon ‘Wij pleiten voor een zuivere indeling gebaseerd op procesdomeinen’ Ons artikel ‘Drie procesmodellen, zes denkfouten’ (Automatisering Gids van 6 maart 2009) heeft veel positieve reacties opgeleverd. Het is niet alleen theoretisch onderbouwd, we passen dit ook toe in de praktijk. Applicatie- en infrabeheer zijn onder één eenvoudig procesmodel goed aan te sturen. De fouten van ITIL, ASL en BiSL zijn vermijdbaar. Er waren ook kritische reacties; René Sieders vat deze kritiek goed samen en verdient dus een antwoord. Sieders stelt dat alleen kleine organisaties (budget 1 ton) met één structuur uit de voeten kunnen en dat dit voor grotere organisaties een illusie en nutteloze bezigheid is. De werkelijkheid is echter dat ook organisaties met meer dan 150 ICT’ers en budgetten van 10 miljoen onze ideeën toepassen. Waar gaat Sieders de fout in? Proces onafhankelijk van vakgebied Belangrijk is het verschil tussen vakgebieden (of beheerdomeinen) en procesdomeinen. Sieders stelt terecht dat de vakgebieden applicatie- en infrabeheer dezelfde doelen en activiteiten hebben (ontwerpen, realiseren en leveren). En daarmee ondermijnt hij meteen zijn eigen stelling dat voor verschillende vakgebieden verschillende processen nodig zijn. Een proces is immers uitsluitend ‘een doelgerichte ordening van activiteiten’, dus per definitie onafhankelijk van het vakgebied waarop dat wordt toegepast. Applicatie- en infrabeheer bevinden zich in de ICT-leveringsketen in dezelfde positie en passen daarom in dezelfde processtructuur. Informatiemanagement (functioneel beheer) heeft een eigen positie en daardoor zijn eigen processen. We bepleiten geen domeinoverschrijdende processen maar binnen de twee domeinen twee eenvoudige en uniforme procesmodellen die nauw op elkaar aansluiten. Functionaliteit en prestatie-eisen Dat het opstellen van het functioneel ontwerp een taak van applicatiebeheer is omdat ASL en BiSL dat zo beschrijven, is een cirkelredenering zoals de slogan ‘Wij van WC-eend adviseren WC-eend!’. Wij plaatsen het opstellen van het FO bewust in het procesdomein functioneel beheer. Functionaliteit en prestatie-eisen worden zowel door de applicatie als door de rest van het informatiesysteem bepaald. Denk maar aan de functionaliteit draadloos kunnen werken, in kleur kunnen printen, of aan prestatie-eisen zoals de beschikbaarheid, snelheid, of capaciteit van een dienst (zie figuur). FO’s die zich beperken tot applicatiefunctionaliteit veroorzaken veel ellende, zoals applicaties die niet goed aansluiten op technische systemen. Het FO is de opdracht van functioneel beheer aan applicatie- en infrabeheer en voor beide de basis voor het technisch ontwerp. Dit vergroot de kans op goede samenwerking tussen applicatie- en infrabeheer. Onvolledige implementatie Wij kennen de vele organisaties die terecht prijzen hebben ontvangen voor hun prestaties met op ITIL, ASL of BiSL gebaseerde implementaties. Geen van deze organisaties heeft echter ook maar een van deze modellen volledig geïmplementeerd, laat staan drie – en ze geven dat zelf ook aan. Toch zijn dit vaak (grote en kleine) organisaties die wél zelf het functioneel, applicatie- en infrabeheer uitvoeren, of slechts delen daarvan uitbesteden. Maar waarom dan tachtig processen beschrijven? Wij pleiten voor een zuivere indeling gebaseerd op procesdomeinen en een beperkt aantal primaire processen. Dat levert prima resultaten met een eenvoudig integreerbare processtructuur. ITIL, ASL en BiSL voorzien in een behoefte en zijn populair. Maar vooral binnen de eigen vakgebieden. De business is niet geïnteresseerd in dit verdeelde landschap en vraagt zich af waarom de dienstverlening zo moeizaam verloopt. Hoewel nog niet zo bekend leidt onze werkwijze voor een toenemend aantal kleine en grote organisaties tot de gewenste verbeterde dienstverlening. Door hergebruik van de waardevolle kennis en ervaring met ITIL, ASL en BiSL ontstaat één overkoepelende implementatiestructuur die eenvoudig, toepasbaar en aanzienlijk goedkoper is, en door zijn eenvoud de samenwerking tussen partijen sterk bevordert. Beheerders zijn niet dom en beseffen steeds vaker dat de klant, die uiteindelijk zijn salaris betaalt, niet zit te wachten op een verdeeld beheerderslandschap. Hopelijk is de huidige sectorale ordening slechts een (onvermijdelijke) tussenstap. Wij zien inmiddels vele ontwikkelingen naar één integrale structuur die steeds breder geaccepteerd wordt. Krijgt de klant alsnog zijn zin.