Professional Documents
Culture Documents
Versus
ASL
3
4
Inhoudsopgave
1. Voorwoord.....................................................................................7
2. Samenvatting.................................................................................8
3. Inleiding........................................................................................9
4. Wat is ITIL?..................................................................................10
4.1. Applicatiebeheer binnen ITIL.....................................................12
5. Wat is ASL?..................................................................................16
5.1. De operationele processen........................................................18
5.1.1. Het beheer....................................................................18
5.1.2. Onderhoud en vernieuwing..............................................19
5.1.3. De verbindende processen...............................................22
5.2. De sturende processen.............................................................23
5.3. De strategische processen.........................................................26
5.3.1. Applications Cycle Management (ACM)..............................26
5.3.2. Organisation Cycle Management (OCM).............................28
6. Overeenkomsten en verschillen.......................................................31
6.1. Procesmatig............................................................................32
6.2. Organisatorisch.......................................................................33
7. De praktijk...................................................................................35
7.1. Getronics................................................................................35
7.2. Fortis.....................................................................................37
7.3. Heijmans................................................................................39
7.4. ABP........................................................................................42
7.5. Beoordeling ASL vs Release Management....................................46
8. Conclusies....................................................................................47
9. Literatuurlijst................................................................................51
Bijlage 1.........................................................................................52
Bijlage 2.........................................................................................53
5
6
1. Voorwoord
Deze scriptie is geschreven door Claudia de Rooij in opdracht van de
Hogeschool Zuyd, faculteit HEAO-ICT richting Bedrijfskundige Informatica te
Sittard. Ik heb deze studie in duale vorm gevolgd.
Als eerste wil ik graag zeggen dat ik het bestudeerde onderwerp nog steeds
erg interessant vind. Ik vond het leerzaam om bij bedrijven te gaan kijken
naar hoe het een en ander in de praktijk werkt. Het geeft veel inzicht in hoe
bedrijven organiseren.
Er zijn een aantal mensen die ik wil bedanken voor hun medewerking.
Als eerste wil ik Gert van Heun bedanken van de ASL Foundation, hij heeft
mij in contact gebracht met de ASL-bedrijven en heeft al mijn vragen en
verzoeken vriendelijk en geduldig beantwoord.
Als tweede wil ik de mensen bedanken die mij te woord hebben gestaan
voor de interviews. Dit zijn Monique van den Anker van Heijmans, Elzie van
Rijn van Getronics, Raoul Gisbers bij Fortis (zelf werkzaam bij Sogeti) en
Huib Hermans van het ABP. Ook zij hebben heel wat vragen voor hun
kiezen gehad en hebben mij allemaal goed ontvangen en zijn erg
behulpzaam geweest.
Als laatste wil ik mijn scriptiebegeleider Tijme Dragstra bedanken voor alle
hulp. Als corrector en stimulans was hij meermaals mijn ‘duwtje in de rug’.
Claudia de Rooij
Maastricht, 2005
7
2. Samenvatting
Deze scriptie is een vergelijking van de methoden ITIL (Information
Technology Infrastructure Library) en ASL (Application Services Library)
voor applicatiebeheer. De keuze voor dit onderwerp lag gedeeltelijk voor de
hand. Ik heb als gedetacheerde al meerdere organisaties gezien. Veel
bedrijven gebruiken ITIL als kapstok voor hun IT-afdelingen. Ik heb de
methode altijd interessant gevonden en heb gezien dat het in de praktijk
echt goed kan werken. Toen ik hoorde van ASL was ik meteen
geïnteresseerd en ik ben blij dat ik dit onderwerp gekozen heb.
8
3. Inleiding
De technische ontwikkeling in de ICT is de laatste jaren een beetje tot rust
gekomen. We zullen altijd blijven streven naar de snelste en beste
producten en de technische infrastructuur zal steeds blijven veranderen.
Intussen is bijna alles geautomatiseerd en zijn we gewend aan de
veranderingen. Er is wat meer tijd en ruimte om ons te richten op andere
zaken. Zaken als het organiseren van de IT-afdeling zijn de laatste jaren
erg in ontwikkeling. De meeste bedrijven zien het nut hiervan in en zoeken
dan ook naar een manier of methode van inrichten die het beste bij hun
bedrijf past. ITIL (Information Technology Infrastructure Library) heeft
hierin voorzien door een kant-en-klaar pakket van processen aan te bieden.
Bedrijven kunnen ITIL geheel of gedeeltelijk gebruiken. Ze kunnen het
smeden en bewerken totdat ze precies dat hebben wat in hun bedrijf past.
De makers van ASL (Application Services Library) willen hierin nog een
stapje verder gaan. Zij hebben gezien dat ITIL een succes is geworden en
hebben een nieuw pakket processen gemaakt. Hoewel zij zich richten op
applicatiebeheer heeft het toch veel weg van het ITIL concept. En ook ITIL
heeft een gedeelte applicatiebeheer in zijn portefeuille.
In hoeverre is ASL gebaseerd op ITIL? En is het gemaakt ter vervanging
van ITIL of als aanvulling? Of heeft het helemaal geen connectie? ASL
noemt 3 soorten beheer: Functioneel beheer, applicatiebeheer (ASL) en
technisch beheer (ITIL). Zij vinden dan ook dat ASL een standaard is náást
ITIL, maar is dat zo? Zijn deze gescheiden te houden of overlappen ze
elkaar?
In de uitleg over ITIL zal ik er vanuit gaan dat u, de lezer, al enige kennis
heeft van dit onderwerp. Ik zal de opzet van ITIL uitleggen en dieper ingaan
op het onderwerp waar ook ASL zich op richt. Na de theorie zullen
bovenstaande vragen in de praktijk onderzocht worden, waardoor aan het
eind de juiste conclusies getrokken kunnen worden.
9
4. Wat is ITIL?
Het ontstaan van ITIL vindt plaats in de jaren tachtig. De kwaliteit van de
IT-dienstverlening is van een dusdanig niveau dat de Britse overheid
opdracht geeft om een aanpak te ontwikkelen die in iedere IT-organisatie te
gebruiken is. Deze opdracht wordt aanvaard door de CCTA (Central
Computer and Telecommunication Agency, tegenwoordig OGC). Het
resultaat is een verzameling best practices uit verschillende onderzochte
methoden beschreven in de Information Technology Infrastructure Library,
oftewel ITIL.
10
wat de relaties zijn met de andere processen. Om de kwaliteit van de
processen te waarborgen heeft ieder proces een proceseigenaar die
verantwoordelijk is voor het resultaat.
IT Customer
Relationship
Management
Service Support en Service Delivery bestaan beide uit 5 processen die nauw
met elkaar samenwerken.
Service Support:
- Incident Management
- Problem Management
- Change Management
- Configuration Management
- Release Management
Service Delivery:
- Service Level Management
- Availability Management
- Capacity Management
- IT Service Continuity Management
- Financial Management for IT Services
11
IT Customer Relationship Management is de enige ingang voor externe
klanten. Dit proces onderhoudt de klantrelaties in alle lagen van de
organisatie.
Het gaat te ver om op alle processen in te gaan, ik ga ervan uit dat u als
lezer globale kennis heeft van de processen. Ik zal alleen de processen
bespreken die te maken hebben met het hoofdonderwerp applicatiebeheer.
12
- Delta Release: Alleen het verschil tussen de nieuwe en de oude
distribueren.
- Full Release: Het gehele programma opnieuw distribueren
- Package Release: Het bundelen van releases, zoals het uitbrengen
van een upgrade en het oplossen van foutjes, kunnen in één keer
worden gedistribueerd.
13
Back-out planning: Change Management is verantwoordelijk voor het
maken van een fall-back planning, Release Management beoordeelt
of het uitvoerbaar is. Het plan hoort een onderdeel te zijn van de
risicoanalyse van de change en moet door de gebruikers acceptabel
gevonden worden. Het plan bevat onder andere het maken van back-
ups en het klaarzetten van een reserve server.
3. Testen en release-acceptatie:
Het testen is essentieel bij het uitbrengen van een nieuwe release. De
meeste problemen na een release komen voort uit het niet of niet
goed genoeg testen van de nieuwe situatie. De release dient
functioneel getest te worden door gebruikers en operationeel door IT-
beheer. Ook de installatiescripts en de back-up plannen dienen getest
te worden.
De release-acceptatie kan alleen plaatsvinden in een gecontroleerde
testomgeving die is opgebouwd uit basisconfiguraties. Deze
configuraties zullen dan ook weer geregistreerd moeten worden in de
CMDB.
Wordt een release niet geaccepteerd, dan wordt terugverwezen naar
Change Management.
4. Implementatieplanning:
Het releaseplan dat in de vorige stappen is ontstaan wordt nu
aangevuld met een implementatietraject. De roll-out planning bevat
onder andere: een exact tijdschema en de benodigde capaciteit, een
lijst van de te installeren CI’s en de uit te faseren CI’s, communicatie
naar de belanghebbenden, plannen van de aanschaf van hard- en
software en registratie van alle nieuwe CI’s in de CMDB.
5. Communicatie, voorbereiding en training:
Deze activiteit geldt voor alle betrokken personen. Dat zijn onder
andere de medewerkers die klantcontacten onderhouden (Service
Desk en Customer Relations), operationeel beheerders en
vertegenwoordigers van de gebruikers. Het verdient aanbeveling om
deze personen samen trainingen te laten volgen en ze vooral te
wijzen op de verantwoordelijkheden die ze nu hebben.
6. Releasedistributie- en installatie:
Release Management waakt ook over het gehele logistieke proces en
14
de gehele installatie van hard- en software. Ze leveren zo een grote
bijdrage aan de CMDB.
15
5. Wat is ASL?
ASL vindt zijn ontstaan onder andere in opdracht van Pink Roccade. Dit
bedrijf had opdracht gegeven aan David Hinley, die aan wieg van ITIL heeft
gestaan, om te onderzoeken of er een soortgelijk model bestond voor
applicatiebeheer. Er bestonden wel al wat ideeën hier en daar, maar een
samenhang was ver te zoeken. Zo begon ASL vorm te krijgen bij het
voormalige overheidsrekencentrum (RCC). Hieruit is de ASL Foundation
ontstaan die het hele systeem beheert en verder ontwikkelt.
skills technology
16
In het kort betekent dit overzicht van clusters:
- Het beheer (maintenance) zorgt voor de optimale inzet van de
bestaande applicaties ter ondersteuning van het bedrijfsproces.
- Het cluster onderhoud en vernieuwing (enhancement and renovation)
zorgt ervoor dat de applicaties aangepast worden aan de
veranderende wensen en eisen, zodat de applicaties ook in de nabije
toekomst het bedrijfsproces optimaal blijven ondersteunen.
- De verbindende processen wijzigingenbeheer en programmabeheer
en distributie betekenen dat de bovengenoemde processen niet los
van elkaar staan, ze werken nauw samen. Deze twee processen
zorgen onder andere voor een goede afstemming tussen het beheer
en onderhoud en vernieuwing.
- De sturende processen (management processes) gaan over alle
clusters heen. De doelstelling is het bewaken van het voldoen aan
doelstellingen, afspraken en gekozen strategie.
- ACM, applications cycle management, zorgt voor het vormgeven van
de langetermijnstrategie, rekening houdend met het
langetermijnbeleid van de organisatie.
- OCM, organisation cycle management, heeft als doelstelling invulling
te geven aan het beleid en de toekomst van de serviceorganisatie.
17
5.1. De operationele processen
18
4. Capaciteitsbeheer: Zorgt voor de optimale inzet van middelen (geen
menskrachten). Alles op de juiste plek, het juiste moment, de juiste
hoeveelheid en de laagste kosten. Voor deze capaciteitsplanning is het
nodig de vraag (de benodigde capaciteit) te bepalen door te kijken naar
welke ontwikkelingen en welke druk de applicatie gaat krijgen de
komende periode. Met deze informatie wordt een analyse gemaakt
waarna de capaciteitsrealisatie plaats vindt waarin eventuele
aanpassingen worden gedaan aan de werklast of inzet van middelen. In
dit proces worden 3 zaken bewaakt: werklastbeheer (zichtbaar maken
van tendensen, veranderingen in aantallen gegevens/gebruikers),
resourcebeheer (m.b.v. Configuratiebeheer inzicht krijgen in de
benodigde capaciteit aan middelen voor applicaties en infrastructuur) en
prestatiebeheer (volgt de resultaten van de applicaties, signaleert trends
en doet aanbevelingen). Als prestatiebeheer goed wordt uitgevoerd kan
er pro-actief gereageerd worden.
Veel input voor dit proces komt van impactanalyse en functioneel
beheer, verder is ook veel communicatie met technisch beheer (zij
zorgen ook voor veranderingen aan de capaciteit).
5. Continuïteitsbeheer: Voorziet de continuïteit van het bedrijfsproces,
d.w.z. een informatiesysteem zolang mogelijk ongestoord of met
aanvaardbaar risico laten functioneren. Het proces lokaliseert risico´s
(van binnenuit en buitenaf) en neemt maatregelen hiertegen. Veel van
deze maatregelen worden door technisch beheer genomen. Een
hulpmiddel hierbij is het uitvoeren van een afhankelijkheidsanalyse en
een kwetsbaarheidonderzoek i.s.m. technisch en functioneel beheer.
Eisen en randvoorwaarden komen van SLM en kwaliteitsmanagement.
Het proces is verder input voor impactanalyse en het kan incidenten
krijgen om op te lossen van incidentbeheer.
19
- Bij onderhoud zijn de eisen hoger, een nieuwe release heeft meestal
een harde deadline en moet meteen goed functioneren.
- De terugkoppeling is bij onderhoud korter dan bij vernieuwing; iedere
niet-optimale oplossing komt snel weer bij de ontwerper terug.
- Mogelijkheden tot verbetering zijn lager bij onderhoud door de
achterstand van de beginsituatie, beperkte financiën enz.
Het gaat er bij onderhoud dus om een zo goed mogelijke release/
verbetering te maken met zo min mogelijk geld en middelen.
1. Impactanalyse: Het op effectieve wijze in kaart brengen van de
consequenties van wijzigingen en hiermee de beste oplossingsrichting
kiezen. Hierbij wordt nauw samengewerkt met wijzigingenbeheer. Er
wordt niet alleen gekeken naar de applicatie, maar ook naar de impact
op gebruikers (i.s.m. functioneel beheer) en infrastructuur (i.s.m.
technisch beheer). In de applicaties wordt gekeken naar welke objecten
mogelijk zullen veranderen (i.s.m. programmabeheer en distributie), dit
wordt de change set genoemd. Functioneel beheer levert meer
inhoudelijke informatie over de wijziging en verifieert achteraf de
impactanalyse. Wijzigingenbeheer geeft aan welke release wordt
uitgevoerd, maar met de informatie die impactanalyse aanlevert kan
deze nog veranderd worden. Verder is de impactanalyse input voor
ontwerp en planning en control.
2. Ontwerp: Het vastleggen van specificaties of wijzigingen van het
informatiesysteem. De methode die hiervoor wordt gebruikt wordt
gekozen door kwaliteitsmanagement en worden bij ASL niet besproken.
De methode voor onderhoud van een applicatie moet natuurlijk dezelfde
zijn als waarmee deze origineel is gemaakt. Hierdoor heeft men bij
onderhoud dus minder ontwerpvrijheid dan bij vernieuwing. Een ontwerp
is volledig als de gegevens, de functies en de samenhang en volgorde
hiervan beschreven zijn. Daarnaast kunnen ook korte omschrijvingen of
een functioneel of technisch ontwerp bij de specificaties zitten. De
informatie hiervoor komt van functioneel beheer en deze keurt ze na
afloop. Bijbehorende documentatie wordt beheerd door
programmabeheer en distributie. Het ontwerp is vooral input voor
realisatie en het testen.
3. Realisatie (oftewel bouw): Het doel is het opgeleverde ontwerp om te
zetten naar daadwerkelijke wijzigingen in het geautomatiseerde
20
systeem. De fasering ziet er zo uit: vraagstelling bepalen -> hoofdlijnen
uitdenken (technisch ontwerp) -> uitwerken -> valideren en dan weer
opnieuw vraagstellingen bepalen. De eerste stap bij realisatie is het
opnieuw bekijken van de change set. Na de realisatie wordt dit de
change package genoemd, dit zijn alle objecten die daadwerkelijk
veranderd zijn. Deze change package is input voor het testen en wordt
daarna door programmabeheer en distributie naar de productieomgeving
gebracht. Er is ook een nauwe relatie met technisch beheer, deze moet
immers de applicatie laten draaien.
4. Testen: Nagaan of de gewenste wijziging heeft plaatsgevonden en of de
applicatie correct werkt. Ook voor het testen zijn vele methodes
beschikbaar en ook deze vallen niet binnen ASL. De ideale situatie is als
dit proces met de rest van de processen meekijkt en in ieder stadium
een test doet. Dit zijn de soorten testen:
- Unittest: wordt gedaan bij realisatie, hier worden de programma-eisen
getest.
- Technische systeemtest: test of het geheel voldoet aan de specificaties
en de kwaliteitscriteria, of het onderhoudbaar is en of het gewijzigde
werkt in het geheel.
- Functionele systeemtest: test of de wijzigingen correct zijn
aangebracht, of het systeem aan de afgesproken functionaliteit voldoet
en of de documenten voldoen aan de kwaliteitscriteria.
- Productietest/exploitatietest: test of het systeem aan de primaire
criteria (doorlooptijden, transactietijden evt. gezet door SLM) en de
secundaire criteria (documentatie, bijsturingmogelijkheden) voldoet.
- Acceptatietest: wordt gedaan bij implementatie door de opdrachtgever
of door functioneel beheer, test of de afspraken gerealiseerd zijn en of
het bruikbaar is voor de gebruikersorganisatie.
Fouten of onduidelijkheden moeten worden opgelost bij ontwerp of
realisatie. De te testen versies worden door programmabeheer en
distributie beschikbaar gesteld.
5. Implementatie: Het invullen van de noodzakelijke randvoorwaarden voor
een foutloos gebruik van de nieuwe versie en de afwerking van het
onderhoudproces. Voor de afronding van de wijziging levert dit proces
ondersteuning voor ingebruikname in de gebruikersorganisatie, het
levert ondersteuning voor de inproductiename door technisch beheer en
21
zorgt voor het veiligstellen van de applicatie onderwerpen. De laatste
stap is de acceptatietest zoals hierboven beschreven. Deze voert
functioneel beheer uit, geeft de akkoordverklaring en de
opdrachtdecharge. De testervaringen gaan als informatie naar het proces
testen en de beheerprocessen. Statusmeldingen van de release worden
steeds naar wijzigingenbeheer gecommuniceerd.
In alle processen waar een planning vereist is, wordt dit door het sturende
proces planning en control gemaakt en bijgehouden. Ook SLM heeft op bijna
alle processen invloed vanwege vooraf gemaakte afspraken met de klant
waar men zich aan moet houden.
22
worden risico’s van ongeautoriseerd gebruik of wijziging of vernietiging
beperkt. De objecten zijn nodig om de change set te kunnen bepalen van
een release. De change package zijn de objecten die daadwerkelijk zijn
gewijzigd en naar de productieomgeving gaan. Dezelfde objecten kunnen
bij verschillende releases veranderd worden, daarom moeten de
wijzigingen gesynchroniseerd worden. Het kan voorkomen dat
verschillende versies op verschillende omgevingen gebruikt worden, het
is de taak van configuratiebeheer om dat te registreren en bij te houden.
ASL raadt af om dit te verwerken in de CMDB van technisch beheer. In
de ideale situatie vind je in de ASL-CMDB altijd terug welke
programmatuur waar gebruikt wordt en hoe deze is opgebouwd.
Programmabeheer zorgt voor de logistiek van de objecten, als alle
processen goed zijn ingericht dan komen de nieuwe objecten van de
vernieuwingsprocessen steeds naar programmabeheer voor opslag. De
voortgang van de release wordt via wijzigingenbeheer doorgegeven aan
SLM.
23
menscapaciteit inplant en dat is voor alle processen even belangrijk.
Planning en control heeft relaties met veel processen, het krijgt
informatie van impactanalyse en wijzigingenbeheer, het levert informatie
aan kostenmanagement, ACM en OCM. Het houdt van alle processen de
planning en voortgang bij, plus de rapportages van die processen.
2. Kostenmanagement: Regelt het beheersen en doorbelasten van de
kosten van IT-dienstverlening. Het levert hierbij ook bedrijfseconomische
gegevens, maakt kosten inzichtelijk etc. Een externe dienstverlener zal
een financiële afdeling hebben voor facturaties. Voor een interne
dienstverlener worden meestal geen facturen gestuurd, het belangrijkste
hier is dat er vaste afspraken zijn. Dat er een relatie ligt met de
financiële afdeling zal duidelijk zijn. Kostenmanagement levert informatie
aan ACM en krijgt informatie van de andere sturende processen, van
OCM (beleid), van impactanalyse etc.
3. Kwaliteitsmanagement: Zorgt voor de interne kwaliteit van processen en
producten. Kwaliteitsmanagement kent vier onderwerpen: kwaliteit van
het product (applicaties en documentatie), van het voortbrengingsproces
(inrichting van de processen/rollen/verantwoordelijkheden), van het
kwaliteitssysteem (van gebruikte tools, methodes en hulpmiddelen) en
kwaliteit van de organisatie (mensen, expertises, plaats in de
organisatie).
Het proces is verantwoordelijk voor de ondersteuning en inrichting van
de beheerprocessen d.m.v. het kwaliteitssysteem, evaluaties en
problemen die hierop terugkomen zijn input voor kwaliteitsmanagement.
Verbeteringen worden beschreven in een kwaliteitsplan dat weer input
vormt voor planning en control. SLM is een proces dat om verbeteringen
kan vragen. Veel input komt van het proces skills definition in de cluster
OCM, hierin wordt de toekomst van de dienstverlening beschreven.
Informatie over status en kwaliteit van applicaties gaat naar de cluster
ACM.
4. Service Level Management (SLM): Gaat over het bewaken en verbeteren
van de klanttevredenheid en de dienstverlening. Hoofdzaak is het maken
van Service Levels, dit zijn afspraken over de dienstverlening in voor de
klant begrijpelijke termen. Het geheel aan Service Levels wordt de
Service Level Agreement (SLA) genoemd, hierin staat het gewenste
niveau van dienstverlening en de sancties op het niet halen hiervan. De
24
afspraken in de Service Levels gaan vooral hierover:
- Het functioneren van de applicatie (performance, transactietijden, up-
time), dit is het meest voor de hand liggende onderwerp omdat dit vaak
al door ITIL is vastgelegd.
- De functionaliteit van de applicatie: wat de applicatie moet kunnen nu
en in de toekomst.
- Het proces van de dienstverlening: afspraken over oplostijden van
verstoringen, snelheid van beantwoorden van vragen, maximaal aantal
fouten in een applicatie.
- Aard van de dienstverlening van de applicatiebeheerorganisatie,
oftewel de servicecatalogus: welke diensten levert de organisatie?
25
5.3. De strategische processen
26
een infrastructuur hiervoor nodig is. Deze informatie wordt ingewonnen
bij functioneel beheer en bij andere organisaties in de keten.
3. Customer Organisation Strategy: Het volgen van de ontwikkelingen in de
eigen gebruikersorganisatie en het bepalen van de impact hiervan op de
applicatieportfolio. Dit proces is er alleen om inzicht te krijgen, niet om
acties uit te voeren. De onderwerpen die worden bekeken zijn onder
andere de bedrijfsprocessen, de klanten van de klant, leveranciers,
organisatie-inrichting, etc. Deze informatie komt natuurlijk van de
gebruikersorganisatie zelf en functioneel beheer. Dit proces en de twee
bovengenoemde processen zijn allemaal input voor Life Cycle
Management en ICT Portfolio Management, dit zijn degenen die de acties
uitvoeren.
4. Life Cycle Management: Het maken van een strategie voor een applicatie
uitgewerkt in acties zodat de applicatie het bedrijfsproces kan blijven
ondersteunen. Om die strategie van 1 applicatie te bepalen wordt
gekeken naar de huidige kwaliteit van de applicatie, de gewenste
veranderingen, technologische ontwikkelingen en mogelijke
vernieuwingsscenario’s. Alle voorgaande ACM processen zijn input
hiervoor (zie schema begin hoofdstuk). Ook de sturende processen
planning en control en kwaliteitsmanagement leveren informatie, vooral
karakteristieken van de applicatie. Functioneel beheer levert nog input
over het gebruik van de applicatie en de bedrijfsprocessen, zij beslissen
over de uiteindelijke strategie.
5. ICT Portfolio Management: Dit proces coördineert de grotere
investeringen en de veranderingen in de objecten van de
informatievoorziening. Het maakt een strategie voor het geheel aan
applicaties. Het belangrijkste hierbij is de samenhang van het geheel en
het afstemmen van de verschillende acties op de verschillende objecten.
Onderzoek hiervoor wordt gedaan in samenwerking met functioneel en
technisch beheer, waarbij ASL zich richt op het managen van de
applicatieportfolio. Verdere input komt ook van de eerste drie ACM
processen, de sturende processen en functioneel beheer. Life Cycle
Management zal zijn strategie zo moeten maken dat het past binnen de
portfolio.
27
5.3.2. Organisation Cycle Management (OCM)
Deze cluster vormt de toekomst van de dienstverlening en de inrichting van
de applicatiebeheerorganisatie. Het gaat hier vooral om de vraag: Wat wil ik
als serviceorganisatie? Er zijn een aantal redenen waarom deze cluster
bestaat. Gebruikersorganisatie, applicaties en applicatiebeheer zijn niet
meer onlosmakelijk met elkaar verbonden. Outsourcing en verzelfstandiging
zorgen ervoor dat applicatiebeheer steeds meer een eigen organisatie wordt
en aan interne leveranciers worden dezelfde eisen gesteld als aan externe.
Interne leveranciers zijn daarbij vaak conservatief en niet innovatief
genoeg. Want ook innovatie van de dienstverlening is noodzakelijk. Als
beheerorganisatie moet je beslissen welke diensten je zelf aanbiedt en
welke je inhuurt, je vraagt je dus af wat je serviceportfolio wordt en hoe je
daar komt. Om dit te bepalen zijn er vier onderwerpen interessant: de
markt, het account (de klanten), de technology, en de skills/expertise. Eerst
wordt van de verschillende gebieden een inventarisatie en een SWOT
analyse gemaakt. Deze gaan dan naar het centrale proces Service Delivery
Definition die alles afstemt en de ambitieniveaus bepaalt. Die resultaten
worden dan weer teruggekoppeld naar de processen en daar verder
uitgewerkt tot een strategie.
OCM richt zich niet alleen op externe dienstverleners, juist ook interne
dienstverleners moeten zich aan de resultaten houden. ACM en OCM
kunnen en mogen verschillen, er is geen officiële gegevensuitwisseling.
Het beleid voor de komende 2 tot 3 jaar wordt gevormd door onderstaande
processen.
28
Omdat niet alle technologieën kunnen worden ondersteund zal er soms
een partner moeten worden gekozen om de expertise naar binnen te
halen. Die keuze wordt in dit proces gemaakt.
2. Account Definition (aan wie): Het vormgeven en uitwerken van de relatie
met de gebruikersorganisatie. De onderzochte onderwerpen hierbij zijn:
- Imago: Hoe zien klanten de beheerorganisatie en de diensten?
- Relaties: Contactpersonen en –mogelijkheden in de
gebruikersorganisatie.
- Accountapparaat: Mensen die namens de beheerorganisatie spreken
over de te leveren diensten.
- Producten/dienstencatalogus: Geleverde of mogelijke services en de
performance van de beheerorganisatie.
Van deze onderwerpen worden SWOT analyses gemaakt en vergeleken
met de resultaten van Market Definition.
3. Skills Definition: Het in kaart brengen van de eisen voor skills en
expertises voor de toekomst. Bij Market en Account Definition zijn
behoeften en mogelijkheden in kaart gebracht, nu worden er skills
bijgezet ter invulling. Behandelde onderwerpen zijn hier welke middelen
nog nodig zijn voor de gewenste dienstverlening en wat dat vraagt aan
de huidige situatie. Het kwaliteitssysteem wordt bekeken; hoe worden
de middelen ondersteund? Er wordt bekeken hoeveel ervaring men in
huis heeft en hoeveel diepgang die heeft (Experts en hun terreinen). En
het kennismanagement-systeem wordt onderzocht (Hoe worden ervaring
en expertise verbreed in de organisatie?). Ook van deze onderwerpen
wordt een SWOT analyse gemaakt. In dit proces wordt bepaald welke
technologie gebruikt gaat worden en hoe deze in het kwaliteitsysteem
komt.
4. Technology Definition: Hier worden de middelen gekozen om de
dienstverlening in de toekomst te realiseren. Er wordt een SWOT analyse
gemaakt voor de bestaande en nieuwe technologie en dienstverlening.
5. Service Delivery Definition: Hier wordt de gewenste dienstverlening over
de komende 2 á 3 jaar vormgegeven d.m.v. een strategie gevormd door
de vergelijking van vraag- en aanbodkant. Alle bovenstaande processen
zijn input voor dit proces. Het verzamelt de inventarisaties en de SWOT
analyses (bottom-up) en ontwikkelt hiermee een visie. Deze visie gaat
over het geheel van markt, klanten, skills en technologie en wordt dan
29
top-down uitgewerkt. Een methode hiervoor zou zijn: formuleren missie
-> formuleren doelstellingen -> definiëren strategie -> benoemen
kritische succesfactoren -> inschatting en allocatie middelen ->
inplannen realisaties.
De strategieën die gevormd zijn worden door ieder proces binnen OCM zelf
verder uitgewerkt. De uitgewerkte strategieën zijn op hun beurt weer input
voor de sturende processen, vooral kwaliteitmanagement en planning en
control. De sturende processen leveren dan weer input die de ACM
processen gebruiken voor nieuwe inventarisaties en analyses. Ook onderling
wordt in de processen veel informatie uitgewisseld.
Het beleid en de doelstellingen die Service Delivery Definition produceert
zijn richtinggevend voor de sturende processen.
30
6. Overeenkomsten en verschillen
In onderstaande tabel staat aangegeven waar de processen van ASL en ITIL
verschillen, de grootste verschillen en enkele knelpunten zijn daaronder
beschreven.
31
6.1. Procesmatig
Het beheer
Als eerste valt op dat de beheerprocessen heel erg op elkaar lijken.
Incidentbeheer, Configuratiebeheer, Beschikbaarheidsbeheer,
Capaciteitsbeheer en Continuïteitsbeheer zijn processen die ITIL ook heeft.
Het verschil bij Incidentbeheer is dat bij ASL de snelheid van oplossen geen
speerpunt is. Het kan soms gebeuren dat de oplossing van een incident pas
na een jaar wordt meegenomen in een release. De andere beheerprocessen
lijken erg hetzelfde alleen toegespitst op een ander onderwerp. Nu rijst de
vraag of het beter is om deze processen te scheiden (ITIL-ASL) of samen te
voegen. Het zou best kunnen zijn dat bijvoorbeeld Beschikbaarheidsbeheer
geen fulltime functie is binnen een organisatie, maar misschien wel als het
ASL en ITIL gecombineerd behandelt. Dit is een van de vragen die in het
volgende hoofdstuk worden onderzocht.
Problem Management
Een verschil met ITIL is dat ASL geen Problem Management kent.
Incidenten kunnen escaleren tot problemen die dan doorgespeeld en
opgelost worden door Kwaliteitsmanagement. Zij verwerken de oplossingen
en verbetervoorstellen in hun kwaliteitsplan. De vraag of dit in de praktijk
goed werkt, is meegenomen in het onderzoek.
SLA
Ook ASL werkt met Service Level Agreements. Hierin worden alle afspraken
vastgelegd die niet bij het interne proces behoren, deze worden met de
klant gemaakt. Als applicatie- en technisch beheer dit beide doen lijkt het
naar mijn mening gemakkelijk om dat samen te doen. Zo hoeven ook
leveranciers en derde partijen maar 1 keer met het betreffende bedrijf om
de tafel te zitten en kan er 1 set afspraken gemaakt worden. De theorie van
ASL beschrijft dit punt niet.
Release Management
Ook wil ik ITIL’s Release Management nogmaals noemen. Het hele blok
onderhoud en vernieuwing plus het proces programmabeheer en distributie
van ASL zijn eigenlijk een uitgebreide omschrijving van wat ITIL allemaal in
1 proces heeft gezet. Het kan zijn dat ITIL het wat kort door de bocht heeft
32
genomen en er wat te weinig aandacht aan heeft besteed, maar ik denk dat
het voor een kleine organisatie best genoeg zou kunnen zijn. Ook deze
vraag zal ik bij de te bezoeken bedrijven voorleggen.
6.2. Organisatorisch
Service Team
ASL werkt met wat ze noemen een Service Team voor de registratie en
stellen voor om dit te combineren met de Service Desk van ITIL. Dit lijkt mij
een goede manier om de 2 samen te brengen en de organisatie op 1 lijn te
houden. Dit is voor de klant het gemakkelijkst, deze hoeft dan maar 1
nummer te onthouden voor zijn ondersteuning en de verdeling vindt daarna
bij de ontvangende afdeling plaats. En het is voor de achterliggende
afdelingen goed omdat ook zij maar 1 aanspreekpunt hebben en incidenten
gemakkelijk kunnen overdragen naar andere afdelingen. Ook dit is een
situatie die zal worden bekeken bij bedrijven die ITIL en ASL
geïmplementeerd hebben.
CMDB
De CMDB is hetzelfde en toch anders. ASL geeft aan dat de technische
CMDB niet toereikend zal zijn omdat vaak applicaties over meerdere
platformen heen functioneren en er meerdere versies van een applicatie
actief kunnen zijn. De vraag is of het ook te verwerken zou kunnen zijn in 1
CMDB. Het enige probleem hierbij is dat je een softwarepakket moet vinden
dat alle aspecten ondersteund. Dat dus alle hardware en configuraties met
alle objecten erin kunnen én alle applicaties met al hun objecten. ITIL heeft
hier ook een ander idee over, zij houden namelijk een aparte lijst bij met
software, de Definitive Software List (DSL). Dus ook ITIL pleit voor twee
verschillende databases. Maar welke methode kun je nou het beste volgen?
Het hebben van verschillende CMDB’s zou verwarrend kunnen werken met
opzoeken. Dit onderwerp lijkt mij het grootste discussiepunt wat betreft de
implementatie van beide methodes.
Technisch beheer
In het boek (bron:1) wordt veel gerefereerd aan technisch beheer. Veel
beslissingen worden gemaakt in samenwerking met technisch beheer en er
33
wordt veel informatie uitgewisseld. Vaak wordt in het boek beschreven dat
bepaalde zaken al door technisch beheer wordt ondervangen en dat ASL
daar niet naar om hoeft te kijken. Het lijkt erop dat ASL erg op pilaren van
ITIL leunt en misschien zelfs niet zonder kan. Een voorbeeld hiervan is de
waarborging van de continuïteit waarbij bepaalde maatregelen bedreigingen
moeten voorkomen. Er wordt als maatregel beschreven dat de systemen
beveiligd moeten worden met o.a. wachtwoorden, firewalls en fysieke
beveiliging. Dit zijn maatregelen die door technisch beheer worden
genomen.
34
7. De praktijk
In boeken worden mooie theorieën uitgeschreven over hoe het zou moeten,
maar hoe werkt het nou in de praktijk? De verschillen en overeenkomsten
van het vorige hoofdstuk zijn meegenomen in het onderzoek dat nu volgt.
Ik ben bij vier bedrijven langs geweest met een vragenlijst om een
interview af te nemen met een betrokkene bij dit onderwerp. De eerste drie
bezochte bedrijven zijn organisaties waarbij ITIL en ASL samen wordt
gebruikt, als laatste een bedrijf dat alleen met ITIL werkt om te zien of ITIL
misschien te kort schiet (of dat ASL misschien helemaal niet nodig is). De
gebruikte vragenlijst voor de bedrijven met ASL (Getronics, Fortis en
Heijmans) is toegevoegd als bijlage 1, de vragenlijst voor het ABP is
toegevoegd als bijlage 2.
7.1. Getronics
Het eerste bezochte bedrijf was Getronics in Nieuwegein. Getronics verzorgt
implementaties van (o.a.) ITIL en ASL voor andere organisaties en gebruikt
ze zelf ook. Als we het hebben over outsourcing van beheer (wat steeds
meer voorkomt), dan is dit het bedrijf dat die opdrachten aanneemt. Ze
hebben dus erg veel ervaring met implementeren en het gesprek was
daarom erg interessant. Ik heb gesproken met een van de service
coördinatoren.
Procesmatig
Als we kijken naar hoe ver ASL geïmplementeerd wordt bij de klanten van
Getronics dan zijn het vooral de onderste 2 lagen van het model. De
operationele en de sturende laag zijn het beste ontwikkeld en ook het beste
implementeerbaar, vinden zij. Het implementeren van de strategische laag
is een stuk moeilijker omdat bedrijven natuurlijk hun eigen richting en
strategie bepalen, het gaat hier om de vraag: wat wil het betreffende bedrijf
in de toekomst? Dat kan Getronics niet voor de organisaties bepalen. Bij
Getronics zelf zijn ook de onderste 2 lagen het beste geïmplementeerd, de
onderwerpen in de strategische laag worden bij het management wel
besproken maar niet helemaal in vorm zoals ASL die beschrijft.
35
Over beheer vertelt de geïnterviewde dat Incidentbeheer,
Wijzigingenbeheer en Programmabeheer en distributie erg belangrijke
processen zijn en dus uitgebreid worden geïmplementeerd.
Capaciteitsbeheer valt volgens hen meer onder technisch beheer, waardoor
het niet door ASL wordt beheerd. Wel is er altijd iemand op de afdeling die
hierover nadenkt. Beschikbaarheidsbeheer en Continuïteitsbeheer zijn
meestal goed geregeld en zijn afhankelijk van de afspraken die met de klant
gemaakt worden. De klant moet namelijk aangeven waar de prioriteiten
komen te liggen. Getronics geeft het bedrijf een eerste beveiliging mee
(wachtwoorden, rechten, back-ups, enz), wat de organisatie er daarna mee
doet is hun eigen verantwoordelijkheid. Zo kunnen ze zelf bepalen hoe goed
ze voorbereid zijn op calamiteiten.
Het niet aanwezig zijn van Problem Management wordt in ieder bedrijf
anders opgelost. Bij Getronics kunnen applicatie incidenten escaleren tot
problemen, alleen worden deze bij Incidentbeheer opgelost en niet bij
Kwaliteitsmanagement.
36
moeilijk te implementeren (zie het begin van deze paragraaf) en het
configuratiebeheer.
Organisatorisch
Het volgende vraagstuk gaat over de CMDB. De opvatting van ASL om een
tweede CMDB aan te houden daar ziet de geïnterviewde het nut niet van in.
De CMDB is gemaakt voor ITIL, voor hardware, daarnaast worden
applicaties bijgehouden door de ontwikkeltools. Deze tools worden gebruikt
om applicaties te maken en te verbeteren en zijn bij Getronics automatisch
hierdoor een versiebeheersysteem waarin alle versies staan opgeslagen.
Hierdoor is wel de functionaliteit aanwezig die ASL wil, alleen in een andere
vorm.
Op de vraag of ASL kan bestaan zonder ITIL is het antwoord een duidelijke
nee. Omdat technisch, applicatie en functioneel beheer bij elkaar horen. Als
de geïnterviewde zou moeten kiezen dan zou ze eerder ASL doorvoeren dan
ITIL. Ook voor kleinere organisaties zou ASL goed te gebruiken zijn als het
niet al te diepgaand wordt gebruikt.
7.2. Fortis
De situatie bij Fortis is helemaal anders. Het applicatiebeheer van Fortis was
tot voor kort in handen van Pink Roccade en is nu teruggekocht. Pink
Roccade is, zoals u hebt kunnen lezen, de hoofdbedenker van ASL en had
37
dit uiteraard ook toegepast op het applicatiebeheer van Fortis. Op deze
manier heeft Fortis ASL binnengehaald. Fortis werkt ook al een aantal jaren
met de processen van ITIL. Nu is het de bedoeling om de processen met
elkaar te gaan afstemmen. Ze gaan ASL en ITIL integreren en willen het
niet apart houden. Op papier is dit al beschreven, de praktijk moet nu gaan
volgen. Ik sprak met een ingehuurde specialist van Sogeti die deze
uitdagende taak op zich heeft genomen.
Procesmatig
In tegenstelling tot ITIL is ASL niet volledig ingevoerd, slechts een selectie
van de processen is ingericht. Vooral de uitvoerende processen zijn
ingevuld, de sturende processen een stuk minder en op strategisch niveau
zeer weinig. Veel van de gebruikte processen zijn door Fortis zelf benoemd
en hebben dus een andere benaming als bij ASL.
Organisatorisch
De CMDB is wel samengevoegd tot 1 zelfgemaakte database. Hierin staat
alle hardware, software en versiebeheer voor de software. De registratie
van incidenten en incidentbeheer worden gedaan in een ander pakket. Er
kunnen dus geen CI’s (Configuratie Items) aan de incidenten gekoppeld
worden, wat als erg onhandig wordt ervaren. Hoe dat in de toekomst eruit
gaat zien is nog niet duidelijk.
38
ASL processen. En ook voor de applicatie-incidenten geldt dat ze zo snel
mogelijk opgelost moeten worden.
Als laatste vraag ik naar BiSL, waar Fortis ook mee bezig is. BiSL is een
methode met processen dat erg lijkt op ASL maar dan voor functioneel
beheer bedoeld is. Het staat alleen nog zo ver in de kinderschoenen bij
Fortis, dat er nog bijna niets van duidelijk is. De processen zijn wel al naast
de bestaande gelegd om vergelijkingen te kunnen maken, in de toekomst
zullen alle 3 methodes op elkaar afgestemd moeten zijn, maar zo ver is het
nog lang niet.
7.3. Heijmans
Het derde gesprek is bij bouwbedrijf Heijmans. IT is voor Heijmans geen
core-business, de hele IT afdeling (technisch en applicatiebeheer) bestaat
dan ook maar uit zo’n 70 man (voor een bedrijf van bijna 10 duizend
medewerkers). ASL is ongeveer 1,5 jaar geleden geïntroduceerd en
sindsdien zijn ze er erg in gegroeid, ze hebben vorig jaar zelfs de eerste
ASL trofee gewonnen van de ASL Foundation. Dit is een aanmoedigingsprijs
voor bedrijven die het ASL gedachtegoed toepassen. Ik spreek met het
hoofd van de afdeling applicatiebeheer van Heijmans.
Procesmatig
De methode wordt bij Heijmans niet in zijn geheel gebruikt en wordt niet tot
de letter nageleefd. Ze kijken naar de theorie en bedenken dan wat ze
zouden kunnen gebruiken. ASL is dan ook niet ineens geïmplementeerd.
Een aantal jaar geleden had iedere afdeling zijn eigen applicatiebeheerders.
Op 1 januari 2002 zijn deze bij elkaar gevoegd op 1 centraal punt. Een van
39
de medewerkers is toen op zoek gegaan naar een houvast voor de
beheerders, gelijkwaardig aan wat ITIL voor technisch beheer betekent. Zij
is toen op ASL gestuit. Met behulp van workshops en hulp van Pink Roccade
en andere specialisten is ASL langzaam binnengekomen. Dat heeft de
afdeling applicatiebeheer zelf gedaan. Nu is het de bedoeling om ook het
management te overtuigen van de meerwaarde van ASL zodat er ook
budget voor vrijgemaakt wordt.
Als we naar de processen kijken dan zijn het ook hier de operationele
processen die het beste zijn ingevoerd. Daarbij worden de processen van
onderhoud en vernieuwing vaak niet helemaal gebruikt omdat ze veel
gebruik maken van ingekochte software. Deze derde partijen ontwikkelen
en bouwen de nieuwe software, Heijmans koopt deze dan in gaat het testen
op hun eigen omgeving. Ze komen dan dus pas om de hoek kijken bij het
proces testen. De sturende processen zijn verspreid, kwaliteitsmanagement
bijvoorbeeld is ingericht bij technisch beheer. Het gedeelte OCM van de
strategische processen ligt gedeeltelijk bij de geïnterviewde en gedeeltelijk
bij de directeur IT, ACM ligt bij de organisatie (buiten de IT-afdeling). Over
technische ontwikkelingen wordt wel nagedacht, maar er worden op hun
afdeling geen uitgebreide plannen gemaakt.
40
hierdoor nooit goede SLA’s afspreken en nakomen. De geïnterviewde erkent
dat dit een punt is waar nog over nagedacht kan worden.
Organisatorisch
De registratie is opgedeeld door enkele software pakketten.
Incidentenregistratie en de CMDB zitten in hetzelfde pakket (aangekocht:
HEAT). De software registratie zit in een andere database, een aparte CMDB
dus. Nog een ander, zelfgemaakt, programma verwerkt de changes (dit is
gedaan vanwege de workflow die bij changes komt kijken).
Er is 1 gezamenlijke helpdesk die onder de leiding staat van ICT. Deze lost
simpele software problemen op via een kennisbank die door
41
applicatiebeheer gevuld wordt. De incidenten die de helpdesk niet (of niet
snel genoeg) kan oplossen, worden doorgeleid naar applicatiebeheer.
Op de vraag of ASL zonder ITIL kan bestaan is het antwoord nee, bij
Heijmans niet. De taakverdeling is duidelijk gescheiden, maar volgen elkaar
wel op. De een heeft de ander duidelijk nodig.
Ook denkt de geïnterviewde dat ITIL niet genoeg zal zijn voor
applicatiebeheer.
Als laatste wil ik nog noemen dat ook Heijmans al bezig is met een
oriëntatie naar BiSL. Het lijkt een logische volgende stap na ASL.
7.4. ABP
Het laatste bezochte bedrijf is ABP in Heerlen. Ik ben via mijn werkgever al
een aantal keer gedetacheerd geweest bij ABP en ken daardoor de
organisatie redelijk goed. ABP is het pensioenbedrijf voor de ambtenaren
van Nederland. Hieraan gekoppeld zijn ook Obvion, Loyalis, een gedeelte
UWV en het vermogensbeheer van ABP. Al deze geledingen worden door 1
ICT-afdeling ondersteund. Ik spreek met een medewerker van de afdeling
Strategy and Control die een controlerende functie heeft op de afdeling
Application Services (AS).
42
worden bijgehouden (dus de voortgang, bevindingen van testen, zelf
geconstateerde incidenten, enz).
Hier volgt een voorbeeld van de goede afstemming van applicatie en
technisch beheer. Als een klant een verzoek heeft om iets te laten
veranderen of een nieuw systeem te laten maken dan wordt er eerst een
offerte gemaakt voor de kosten. Als die wordt goed gekeurd wordt er een
change aangemaakt (door technisch beheer) in HP Open View en worden
verschillende werkopdrachten uitgezet voor verschillende specialisten. Om
alle aspecten te bekijken en risico’s te vermijden worden ook bij technisch
beheer specialisten ingeschakeld. Zo komen de afdelingen samen tot een
goede analyse en kan de verandering goed voorbereid worden. Ook de klant
wordt in dit proces betrokken, zodat die al zijn zorgen kwijt kan en zich
goed kan voorbereiden op de komst van het nieuwe systeem.
Samenvattend kan gezegd worden dat de afdeling AS ITIL zoveel mogelijk
heeft gebruikt daar waar het meerwaarde heeft.
ABP en ASL?
De geïnterviewde is door de organisatie gevraagd om de bruikbaarheid van
ASL te onderzoeken. Niet omdat er een behoefte bestaat voor een nieuwe
methode, maar puur om te bekijken of ASL meerwaarde zou hebben. Het
kan immers altijd beter. Na zijn onderzoek zal hij een advies uitbrengen aan
de organisatie.
44
Hij herkent veel in de methode. Een groot deel van de processen zijn
hetzelfde als bij ITIL en zijn daarom al ingericht. Het model zal de
communicatie tussen de afdeling verder verbeteren. Qua methode zou de
stap niet groot zijn naar ASL.
De geïnterviewde ziet wel een aantal knelpunten. Hij is van mening dat het
zal moeten beginnen op strategisch niveau. Zij zullen moeten inzien dat het
meerwaarde heeft, dat het zal lonen om er tijd en geld in te steken. Dat
niveau ligt alleen grotendeels buiten de afdeling AS en is dus moeilijk te
beïnvloeden. Ook vindt hij het verschil in verantwoordelijkheid tussen de
uitvoerende taken en de sturende taken niet helemaal duidelijk. Nog een
knelpunt is dat het ABP op dit moment ook commerciële contracten heeft
waar ze rekening mee moet houden, bijvoorbeeld met het UWV. Als er
grote veranderingen plaatsvinden, zullen zij ook akkoord moeten gaan. Als
laatste en misschien wel grootste probleem denkt hij dat de methode
misschien niet in de organisatie zal passen. De communicatie niveaus liggen
nu heel anders dan in ASL wordt voorgeschreven. Er zal een reorganisatie
aan vooraf moeten gaan om alles volgens ASL in te richten.
De geïnterviewde zou ASL graag willen gebruiken, maar de vraag is of het
wel kan.
Op de vraag of hij gescheiden CMDB’s zou aanhouden was het antwoord ja.
Eén grote CMDB zou veel te groot worden en de meeste gebruikers zouden
de helft van de informatie toch niet nodig hebben. Een beter idee zou zijn
om 2 databases aan te houden met een goede interface, zodat iedereen wel
zaken op zou kunnen zoeken in beide bestanden.
45
7.5. Beoordeling ASL vs Release Management
46
8. Conclusies
Na het bestuderen van de theorie en het onderzoeken van de praktijk zijn
een aantal zaken duidelijk geworden. De bedrijven zijn het niet over alles
eens, maar er zijn wel een aantal duidelijke overeenkomsten.
De processen algemeen
Als we als eerste kijken naar de ingevoerde processen dan blijkt dat de
operationele processen overal wel zijn ingevuld. Dit is ook logisch omdat
hier het uitvoerende werk wordt gedaan. De sturende processen zijn een
stuk minder ingevuld, maar meestal wel in een bepaalde vorm aanwezig. De
strategische processen zijn, in de vorm waarin ASL ze beschrijft, bijna niet
ingevuld. Natuurlijk is er altijd hoger management aanwezig en die zullen
ook beslissingen maken op IT gebied, maar ze zijn niet ingericht zoals ASL
het voorstelt. Ze zullen minder onderzoek doen naar ICT trends en
technologieën dan wenselijk zou zijn. Dit strategische niveau blijkt een erg
groot knelpunt te zijn. Je hebt de goedkeuring en de steun van dit niveau
nodig om een methode goed te kunnen doorvoeren, maar meestal weten ze
te weinig van de IT afdelingen om een dergelijke beslissing te kunnen
maken.
Het beheer
De meningen over het scheiden of samenvoegen van de beheerprocessen
van ITIL en ASL zijn verschillend. De een wil ze samenvoegen, de ander
houdt ze strikt gescheiden. Ik kan geen conclusie trekken over wat beter is.
Dit is een gedeelte van de processen wat organisaties zelf kunnen invullen
en waar het naar mijn mening niet zoveel uit maakt hoe het wordt
ingericht. Zolang er maar goede afspraken gemaakt worden tussen
technisch en applicatiebeheer.
Problem Management
De afwezigheid van Problem Management wordt heel verschillend
opgevangen door de organisaties. Wat opvalt, is dat niet één organisatie de
manier van ASL heeft gekozen. Dat is voor mij een bevestiging van wat ik al
dacht, de manier van ASL is geen handige manier om problemen op te
lossen. Wat dan wel een handige oplossing is, ligt aan de situatie. Fortis wil
47
bijvoorbeeld alle processen integreren. Zij hebben Problem Management
van ITIL gebruikt om ook applicatie problemen op te lossen. Dat is voor hen
een goede oplossing, omdat ze alle processen willen integreren. Voor een
organisatie die de processen apart wilt houden is dit geen goede oplossing.
Ik denk dat er veel manieren te bedenken zijn, het belangrijkste is dat er
wel iets wordt vastgelegd om problemen op te lossen (de manier van
Heijmans, problemen als incidenten laten openstaan, lijkt mij in deze géén
oplossing).
SLA’s
Over SLA’s bestaat veel onduidelijkheid. De meeste vinden het moeilijk om
goede afspraken te maken. Vaak worden ze te algemeen opgesteld en kan
het op meerdere manieren worden uitgelegd waardoor je er dus niets aan
hebt. De SLA’s van technisch en applicatiebeheer worden wel veel tegelijk
gemaakt, Heijmans heeft hier heel duidelijke afspraken over en bij
Getronics wordt bij uitbesteding altijd alle afspraken samen gemaakt. Mijn
conclusie is dan ook dat het het beste samen gedaan kan worden en dat er
veel aandacht naar uit moet gaan.
Release Management
In tabel 2 is te zien dat de meeste bedrijven kiezen voor de processen van
Onderhoud en Vernieuwing van ASL en niet voor Release management van
ITIL. De grootste reden hiervoor is, denk ik, dat het bij ASL meer aandacht
krijgt. Het is beter uitgeschreven en heeft een heel eigen procescluster. Bij
Release Management zitten in principe precies dezelfde processen, alleen is
het wat kleiner ingeschaald (zo ziet het er in het model tenminste uit).
Service Team
Ook hiervan denk ik dat de gedachte vooraf aan het onderzoek al juist was.
Mijn conclusie is dat er het beste 1 Service Team/Desk gemaakt kan
worden. Het argument van Getronics dat voor applicaties er beter een
skilled helpdesk kan zitten kan op een ander manier opgevangen worden.
De manier van Heijmans en van het ABP is namelijk dat de Service Desk
gebruikt maakt van een kennisdatabank. Zolang deze wordt bijgehouden
kunnen de meest voorkomende problemen worden opgelost zonder
tussenkomst van applicatiebeheer.
48
CMDB
Over de CMDB zeggen de meeste dat het beter is om 2 aparte databases
aan te houden. Ik was zelf pas hiervan overtuigd nadat ik het argument van
het ABP gehoord had. Als alles in 1 database wordt opgeslagen, wordt deze
erg groot. Technisch gezien kan dat problemen opleveren voor de snelheid
van de database. Maar stel dat dat geen problemen zou geven, dan is er
nog de vraag of er wel behoefte is aan zo’n alles bevattende database. De
doorsnee gebruiker zal de helft van wat erin staat nooit gebruiken. De
ontwikkeltaal en codes zijn alleen van belang voor de applicatie beheerders
en ontwikkelaars. Het lijkt me daarom het beste om 2 databases te maken
met een goede koppeling daartussen (misschien in de vorm van een CMDB
en een A(pplication)MDB).
49
Nog een reden om ASL niet te gebruiken zou zijn als het bedrijf alleen
ingekochte software gebruikt. Bij ingekochte software hoeft namelijk het
traject van ontwikkelen niet doorlopen te worden en heeft ASL niet genoeg
meerwaarde naar mijn mening.
Samenvattende conclusie
Samenvattend kan ik zeggen dat alle geïnterviewden me een positief beeld
hebben laten zien van ASL. Ze waren allen zeker voorstander van de
methode. Ik was zelf ook erg enthousiast toen ik de theorie doornam. Het
lijkt erg op ITIL, dat is zeker. Maar het heeft eigen kracht gekregen door
het splitsen en beschrijven van het sturende en strategische niveau. Dit
beschrijft de basis van ITIL niet. ASL heeft de beslissers, strategiemakers,
budgethouders en verantwoordelijken erbij betrokken. Daardoor ziet ASL er
meer volwassen uit dan het stukje Release Management van ITIL, waar
meestal toch een hele afdeling applicatiebeheer aan vast hangt.
Ik kan constateren dat ASL een standaard is naast ITIL. Ze zijn apart, maar
toch verbonden. Voor applicatiebeheer is het een heel goede methode,
hoewel ik weet niet of het net een zodanig succes zal worden als ITIL. De
basis ligt er zeker en na een aantal succesverhalen zal de mond-op-mond
reclame snel op gang komen. Maar zoals ik al eerder zei: applicatiebeheer
kan niet zonder technisch beheer, dus kan ASL niet geheel zonder ITIL. Met
de juiste afspraken en veel communicatie kunnen deze methodes leiden tot
een mooi partnerschap.
50
9. Literatuurlijst
1. ASL, een framework voor applicatiebeheer – R. van der Pols, 2001
ISBN 90-4400-266-X
2. IT service management, een introductie – ITSMF, 2002
ISBN 908067132-0
3. ITbeheer 3 - april 2004, artikel Jobshop-beheer: een nieuw
beheerconcept
4. ITbeheer 4 - mei 2004, artikel ASL maakt vaart
5. http://www.aslfoundation.org
6. http://nl.itsmportal.net/
7. Intranet ABP
51
Bijlage 1
Procesmatig
1. Hebben jullie ASL in zijn geheel geïmplementeerd of slechts een
gedeelte?
2. Hoe is het beheer van de applicaties geregeld (bvb
Beschikbaarheidsbeheer, Continuïteitsbeheer)? Is dit geïntegreerd
met de ITIL processen of wordt het apart gehouden?
3. Levert de afwezigheid van Problem Management problemen op?
4. Worden SLA’s collectief gemaakt (er zal contact zijn met dezelfde
bedrijven?) of apart?
5. Wat vonden jullie het grootste knelpunt bij de implementatie? En zijn
er nu nog knelpunten? (M.b.t. ITIL of in het algemeen?)
Organisatorisch
6. De CMDB, wordt er 1 grote database gebruikt of 2 aparte?
7. Wat voor een softwarepakket gebruiken jullie voor de registratie? Is
deze ook toereikend voor de CMDB en alle beheerprocessen?
8. Hoe ziet jullie Service Desk/ Helpdesk eruit? Is het een
gecombineerde afdeling (ITIL+ASL), of hebben jullie hiervoor aparte
ingangen?
9. Kan ASL bestaan zonder ITIL?
10. Zou ITIL toereikend kunnen zijn in een kleinere organisatie? Zo
nee, wat mist ITIL dan vooral naar uw mening?
52
Bijlage 2
Vragenlijst ABP:
53