ITIL versus ASL, een vergelijking van methodes (scriptie HEAO)

ITIL
Versus
ASL
Een vergelijking van methodes
Hogeschool Zuyd Faculteit HEAO, Bedrijfskundige Informatica
Naam: Claudia de Rooij
Studentnummer: 9902979
Datum: 27-06-2005
2
ITIL
Versus
ASL
Een vergelijking van methodes
Hogeschool Zuyd Faculteit HEAO, Bedrijfskundige Informatica
Naam: Claudia de Rooij
Studentnummer: 9902979
Datum: 27-06-2005
Scriptiebegeleider: dhr T.Dragstra
3
4
Inhoudsopgave
1.
Voorwoord ................................................................................ 7
2.
Samenvatting............................................................................ 8
3.
Inleiding ................................................................................... 9
4.
Wat is ITIL? ............................................................................. 10
4.1.
5.
Applicatiebeheer binnen ITIL ................................................... 12
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
6.
5.3.1.
Applications Cycle Management (ACM) ........................... 26
5.3.2.
Organisation Cycle Management (OCM) .......................... 28
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.
De scriptie begint met beschrijvingen van de theorie om de lezer een goed
beeld te geven over de stof. Als eerst met een globale omschrijving van ITIL
gevolgd door een uitvergroting op het stuk wat voor applicatiebeheer
belangrijk is, namelijk Release Management en de koppelingen naar
Configuratie Management en de andere processen. Hierna volgt de theorie
van ASL.
Dan volgt een vergelijking van deze theorieën. Hierbij heb ik zelf een aantal
knelpunten gesignaleerd, zoals de CMDB (kies je voor 1 database of 2?),
het verwerken van problemen (wordt door ASL anders opgelost dan bij
ITIL) en als je beide methoden gebruikt, houd je dan de beheerprocessen
gescheiden?
Deze vraagstukken zijn in de praktijk onderzocht bij de bedrijven Getronics,
Fortis, Heijmans en het ABP. De eerste drie hebben ASL en ITIL
geïmplementeerd, de laatste alleen ITIL. Bij deze bedrijven kwamen zaken
naar voren die vooraf goed waren ingeschat en een aantal voorspellingen
bleken niet goed te zijn.
Een aantal van mijn conclusies zijn dat het bijvoorbeeld niet zo heel veel
uitmaakt of je de beheerprocessen samenvoegt of niet, zo lang er maar
goede afspraken liggen. Het hebben van 2 CMDB’s is beter dan 1. SLA’s
maak je het liefst samen (ASL en ITIL gecombineerd) en je kunt beter 1
Service Team hebben in plaats van 2.
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.
Fig. 1 ITIL model (bron: 6)
De onderdelen van ITIL zijn:
-
Het zakelijke perspectief (The Business Perspective)
-
Levering en planning van IT-diensten (Service Delivery)
-
Ondersteuning van IT-diensten (Service Support)
-
Management van de infrastructuur (ICT Infrastructure Management)
-
Management van applicaties (Applications Management)
-
Beveiliging (Security Management)
-
Het toepassen van ITIL (Planning to Implement Service Management)
Service Support en Service Delivery zijn de meest gebruikte en daarom de
belangrijkste. Deze 2 samen worden ook wel Service Management
genoemd.
Het meest belangrijke aspect binnen ITIL is dat de hele methode in
processen is ingedeeld. Per proces is duidelijk gemaakt wat het doel is en
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
Fig. 2 Service Management model (bron: 6)
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
De Service Desk en IT Customer Relationship Management staan er als
losse processen naast, maar zijn wel een belangrijk deel van het totaal.
De Service Desk is de enige ingang voor gebruikers om incidenten te
melden. Hier start de gehele gebruikersondersteuning.
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.
4.1. Applicatiebeheer binnen ITIL
Het applicatiebeheer van ITIL vindt men hoofdzakelijk terug in Release
Management en de relaties die Release Management heeft met de rest van
de processen (als belangrijkste Configuration en Change Management).
Release Management voert het beheer en de distributie uit van software- en
hardwareversies die in gebruik zijn, om zo te kunnen voldoen aan de eisen
van de dienstverlening. Het proces Configuration Management speelt een
grote rol in Release Management vanwege de CMDB. Alles wat Release
Management uitvoert en verandert staat geregistreerd in de CMDB. En
hoewel Release Management ook bedoeld is voor hardware configuraties,
wordt het in de praktijk meestal alleen gebruikt voor software.
Releases worden samengesteld uit één of meerdere changes (Change
Management). Er zijn 3 niveaus van releases:
-
Major Release (belangrijke uitrol van nieuwe software met meestal
een aanzienlijke uitbreiding van functionaliteit en meestal een
oplossing voor enkele Known Errors. vb v1, v2)
-
Minor Release (kleinere verbeteringen en reparaties voor Known
Errors, vb v1.1, v1.2)
-
Emergency Fixes (bedoeld als snelle reparatie voor een problem of
Known Error.
Een normale levenscyclus van een versie ziet er zo uit:
Ontwikkelen – Testen – Exploiteren – Archiveren (Als de nieuwe versie
uitkomt)
Release Management bepaalt wat er in de release wordt uitgebracht, maar
Change Management bepaalt hoe deze wordt uitgebracht. Dat kan op 3
manieren:
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.
Naast de registratie in de CMDB heeft Release Management ook een eigen
registratie, namelijk de Definitive Software List, oftewel DSL. Elk
geautoriseerd software-item wordt hierin (fysiek) opgeslagen, inclusief alle
originele versies. Het is van groot belang dat de DSL en de CMDB tijdig
bijgewerkt worden en altijd up-to-date zijn. De CMDB heeft hierin voor
Release Management een ondersteunende functie, omdat deze informatie
behoort te bevatten over de geplande releases (o.a. Samenstelling, impact,
betrokken Configuratie Items).
Hieronder de beschrijving van de activiteiten van Release Management:
1. Releasebeleid en –planning:
Van tevoren wordt door de Release Manager een Release Policy,
oftewel het beleid, opgesteld. Hierin wordt bepaald hoe en wanneer
releases worden samengesteld.
Vervolgens wordt van de release een impactanalyse gemaakt, de
benodigde capaciteit wordt berekend, de moeilijkheidsgraad van
eventuele installaties bij gebruikers wordt bepaald en de mate van
afhankelijkheid van de rest van de soft- en hardware wordt bepaald.
Voordat de release ingepland wordt moet ook bekend zijn wat de
service levels zijn, wat de lifecycle is voor dit product, wat de inhoud
van de release is, de planning, de fasering, enz. Dit moet allemaal
bekend zijn voor het uitvoeren van de change.
2. Ontwerpen, bouwen en samenstellen:
Voor deze activiteit is het goed om standaardprocedures op te stellen
die vervolgens worden geregistreerd als Configuratie Item (CI) bij
Configuratie Management. Deze CI’s moeten dan worden genoemd in
de change van de release. Release Management zorgt ook voor een
testopstelling en werkinstructies hiervoor. Alles hoort vastgelegd te
worden zodat het altijd reproduceerbaar is.
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 backups 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 ITbeheer. 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.
Meer informatie is na te lezen in IT Service Management – ITSMF (bron: 2).
In de opsomming van de ITIL onderdelen staat ook een deel Applications
Management. Graag wil ik toelichten waarom ik deze niet betrek in mijn
scriptie. Dit deel van ITIL is in Nederland niet uitgebracht en in geen enkele
bibliotheek te vinden. Nog nooit heb ik een bedrijf horen vertellen over dit
deel, laat staan dat het ergens geïmplementeerd is. Uit deze feiten trek ik
de conclusie dat het niet voldoet aan de eisen van applicatiebeheer van
organisaties en dat het daarom nergens wordt gebruikt. Daarom heb ik mijn
zoeken gestaakt en dit boek niet bij mijn scriptie betrokken.
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.
Application Services Library, ASL, is een framework voor applicatiebeheer.
In een overzicht wordt ASL op deze manier weergegeven:
skills
Fig. 3 ASL model (bron: 5)
16
technology
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.
De structuur van het ASL framework:
Het applicatiebeheer heeft 2 hoofdkenmerken. Het ondersteunen van de
bedrijfsprocessen, het bekende beheer, dit gedeelte is ongeveer 10-20%
van het totale applicatiebeheer. En het onderhouden van de levensduur van
die bedrijfsprocessen, ze spelen in op toekomstige wensen en eisen.
Het applicatiebeheer kent verder 2 kanten. Het is servicegericht, het ter
beschikking stellen van de applicaties, en het is applicatiegericht, wat gaat
over de inhoud van de applicatie. De inhoud van applicaties kunnen worden
gestructureerd door methodes als DSDM, OOD, IAD en structured
programming. ASL laat de keuze van de methode vrij.
Verder zijn er nog de drie niveaus van processen: uitvoerend, sturend en
beleidsbepalend.
Hieronder volgt een beschrijving van alle ASL processen. Meer informatie is
na te lezen in bron 1.
17
5.1. De operationele processen
5.1.1.
Het beheer
Het beheer van ASL lijkt erg op dat van ITIL, maar, beschrijft ASL, het is
toch erg verschillend. ASL kent binnen beheer deze processen:
1. Incidentbeheer: Het houdt in principe hetzelfde in als bij ITIL, maar dan
gespecialiseerd op applicatiestoringen. Een typische melding zal gaan
over programmafouten, wijzigingsverzoeken of informatievragen.
Incidenten die escaleren tot probleem binnen incidentbeheer worden bij
kwaliteitsmanagement behandeld. Incidentafhandeling wordt bij ASL niet
beoordeeld op snelheid, omdat een verandering aan een applicatie soms
pas na een jaar met een release wordt meegenomen. Een ander
onderdeel van dit proces is proactieve communicatie, als er iets
verandert in de software dan wordt dat vooraf naar de gebruikers
gecommuniceerd.
Omdat technisch beheer meestal ook een helpdesk heeft (ITIL), is het
makkelijk om deze twee te combineren ook vanwege de afstemming van
de SLA’s.
2. Configuratiebeheer: Ook ASL werkt met een CMDB, de inhoud gaat
vooral om applicatieobjecten/configuraties en services waarvoor de
applicatiebeheerorganisatie verantwoordelijk is. De CMDB is geen
versiebeheersysteem, het houdt bij welke versies op welke platformen
draaien. Naamgevingsconventies worden afgesproken met technisch
beheer en ook programmabeheer en distributie wordt in samenwerking
met technisch beheer gedaan.
3. Beschikbaarheidsbeheer: Zorgt ervoor dat applicaties en diensten
beschikbaar (aanwezig) zijn zoals afgesproken en beschreven in het
beschikbaarheidsplan. Het proces meet, bewaakt, verbetert en
optimaliseert de beschikbaarheid in samenwerking met technisch beheer.
Betrouwbaarheid (juiste werking van bijvoorbeeld de applicatie of
dienstverlening) is hierbij een belangrijk onderwerp.
Er is veel gegevensuitwisseling met technisch beheer en impactanalyse
en het kan zijn dat het proces incidenten krijgt om op te lossen van
Incidentbeheer. Veel eisen en standaarden komen van Service Level
Management (SLM) en Kwaliteitsmanagement en hier moet het proces
zich aan houden.
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.
5.1.2.
Onderhoud en vernieuwing
De volgende 5 processen gaan over onderhoud en vernieuwing en hoewel
de processen hetzelfde zijn, zijn er toch een aantal verschillen tussen
onderhoud en vernieuwing:
-
Bij onderhoud is de uitgangspositie, in tegenstelling tot vernieuwing,
minder goed omdat je werkt met bestaande systeemstructuren en
programma´s. De ontwerper heeft hierdoor veel minder vrijheid.
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.
5.1.3.
De verbindende processen
Deze processen synchroniseren de beheerprocessen en de
onderhoudprocessen, zij vullen de logistiek in voor applicatiebeheer.
1. Wijzigingenbeheer: Dit proces zorgt ervoor dat wijzigingen (een
gewenste of noodzakelijke verandering) aan applicaties
gestandaardiseerd zijn/worden. Hier worden de gewenste wijzigingen
geclusterd en ingepland in releases (verzameling gegroepeerde
wijzigingen) of projecten. Een aanleiding voor een wijziging kan zijn een
incident of een aanvraag van functioneel beheer, kwaliteitsmanagement
of SLM. Een ingrijpende wijziging kan ook worden opgesplitst over
meerdere releases. Het kan soms lang duren voordat een wijziging wordt
doorgevoerd omdat minder belangrijke veranderingen later worden
opgepakt, snelheid is geen prestatie indicator bij ASL. De invulling van
een release dient als input voor impactanalyse en andere
vernieuwingsprocessen. Het proces implementatie geeft input over de
afronding van de release. Planning en control bekijken de inschattingen
van de release en stellen ze bij, ze houden ook de voortgang bij. Deze 2
zaken zijn ook weer input voor SLM. De relatie met programmabeheer
en distributie is sterk, dit is in feite de technische variant van
wijzigingenbeheer. Wat wijzigingenbeheer op papier doet, regelt
programmabeheer en distributie fysiek.
2. Programmabeheer en distributie: Zorgt voor beheersing en distributie
van de applicatieobjecten, hierbij hoort het ter beschikking stellen van
de juiste objecten aan de juiste processen op het juiste tijdstip. Hierdoor
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.
5.2. De sturende processen
Dit zijn de processen tussen het operationele en het beleidmakende niveau.
Er zijn vier onderwerpen van sturing: tijd, geld, kwaliteit en afspraken.
Deze onderwerpen zijn verdeeld over de verschillende processen en staan
vaak op gespannen voet met elkaar. De spil van de processen is planning
en control omdat hier de realisatie en inzet van middelen wordt gestuurd.
De sturende processen hebben twee aspecten:
- Ze zijn integraal, d.w.z. ze kijken naar boven en naar onder, naar de
operationele processen en de strategische, ze voeren beleid door maar zijn
ook input voor het beleid.
- De processen kijken terug, naar het nu en vooruit. Ze zijn dus evaluerend,
controlerend en plannend.
1. Planning en control: Het managen van tijd en capaciteit zodat de
afgesproken dienstverlening kan worden gehaald. Hieronder vallen zowel
de projectmatige (onderhoud/vernieuwing) als de continue (beheer)
activiteiten. De aansturing van beide wordt door hetzelfde proces
gedaan, ASL noemt dit de uitdaging van applicatiebeheer. Dit proces
wordt als meest belangrijke sturende proces gezien omdat deze de
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, uptime), 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?
De Service Levels worden onder andere getoetst bij de acceptatietest.
Ze moeten wel aan een aantal eisen voldoen: de afspraken mogen niet
ingaan op de interne werkwijze (gebruikte methodes/technieken), ze
moeten functioneel en resultaatgericht zijn en gericht op de
opdrachtgever. Verder moeten ze meetbaar en rapporteerbaar zijn
(aantoonbaar), ze moeten van belang zijn, ze moeten haalbaar zijn, er
moet rekening worden gehouden met eventuele afhankelijkheid van
derden (vb. leveranciers). En als na een tijd gestelde doelen behaald zijn
of eisen veranderen dan moeten de afspraken herzien worden. Er is een
nauwe relatie met de beheerprocessen omdat de meeste Service Levels
hierop betrekking hebben. De beheerprocessen leveren meetgegevens
en rapportages ter controle. SLM levert onder andere ook input voor
kwaliteitsmanagement, planning en control en OCM, SLM krijgt van deze
processen verbetervoorstellen en strategie terug. Als laatste brengt ACM
ook vernieuwingsplannen en het te voeren beleid in.
Ter verduidelijking: SLM maakt afspraken met de klant over zaken die bij
kwaliteitsmanagement nog niet zijn vastgelegd. Hierbij is
kwaliteitsmanagement intern en op de lange termijn gericht. SLM is dus
extern gericht.
25
5.3. De strategische processen
5.3.1.
Applications Cycle Management (ACM)
Deze cluster kijkt voor de komende drie tot vijf jaar naar de lifecycle van de
objecten van de informatievoorziening. Eerst op het niveau van de
applicatie, en dan naar het geheel van applicaties. Het is hierbij het beste
om van de oude situatie naar de nieuwe te groeien i.p.v. het hele systeem
te vervangen. Daarnaast is het beter om delen van de organisatie te
veranderen i.p.v. alles tegelijk. Het gaat bij ACM vooral om de vraag: Wat
wil de klant?
Het doel van ACM is vooral het krijgen van inzicht en het bepalen van de
strategie voor de applicaties d.m.v. onderstaande processen. De
uiteindelijke strategie wordt samen met technisch en functioneel beheer
bepaald.
1. ICT Development Strategy: Dit proces volgt en toetst de technologische
ontwikkelingen op de markt en kijkt wat nuttig zou zijn en wat de impact
zou zijn voor de applicatieportfolio. Deze ontwikkelingen kunnen grote
invloed hebben op de toekomst van de applicaties. Een aantal van deze
ontwikkelingen kunnen zijn: De plannen van de leverancier met het
product. Nieuwe releases of producten die extra functionaliteit kunnen
bieden. Ontwikkelingen bij andere afnemers/gebruikers. Bij weinig
gebruikers zou het kunnen zijn dat de ondersteuning voortijdig ophoudt.
Er zijn vier soorten technologieën die impact hebben op applicatie. Twee
van technisch beheer, namelijk ontwikkelingen in infrastructuur en
systeemprogrammatuur. Technisch beheer kan hierbij natuurlijk hulp
bieden. En twee van applicatie beheer, namelijk
systeemontwikkelinginfrastructuur (waar de applicaties mee gemaakt
worden) en de standaardprogrammatuur (ontwikkeld en onderhouden
door derden).
2. Customer Environment Strategy: Hier wordt de informatievoorziening en
de gegevensuitwisseling gevolgd tussen organisaties en worden eisen en
kansen gevormd voor de eigen organisatie. Dit gebeurt door het bekijken
van de stappen in de keten en hoe ze over de organisatie heen verband
houden, door het analyseren van de informatiestromen, welke
geautomatiseerde gegevens en/of functies worden gebruikt en wat voor
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.
1. Market Definition (in welke omgeving/markt): Het analyseren van de
markt en de klanten en de eigen positie op de markt. Bij het bepalen
van de plaats op de toekomstige markt kan het model van Porter
gebruikt worden dat vijf onderwerpen onderzoekt:
- Welke (vervangende) producten komen op de markt bij klanten?
- Welke mogelijke concurrenten zijn er en wat is de invloed op de eigen
positie?
- Welke positie en macht hebben de leveranciers en klanten en welke
dienstverlening kunnen zij overnemen?
- Welke kansen en bedreigingen zijn er m.b.t. mogelijke nieuwe
concurrenten of marktsegmenten?
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.
Tabel 1 Vergelijking van processen
Soort
Proces
Operationeel
Sturend
Strategisch
ITIL
ASL
Verschil/ Overeenkomst
Incident
Management
Incidentbeheer
Configuration
Management
Problem
Management
Change
Management
Release
Management
Release
Management
Release
Management
Release
Management
Release
Management
Release
Management
Availability
Management
Continuity
Management
Capacity
Management
Planning and
Control
Configuratiebeheer
Snelheid oplossen
incidenten bij ASL geen
speerpunt
1 of 2 CMDB’s?
-
Bij ASL niet aanwezig
Wijzigingenbeheer
Andere positie in model
Programmabeheer
en distributie
Impactanalyse
Apart verbindend proces in
ASL
Apart proces bij ASL
Onderhoud+Vernieuwing
Apart proces bij ASL
Onderhoud+Vernieuwing
Apart proces bij ASL
Onderhoud+Vernieuwing
Apart proces bij ASL
Onderhoud+Vernieuwing
Apart proces bij ASL
Onderhoud+Vernieuwing
Geen verschil
Financial
Management
Quality
Management
Kostenmanagement
Service Level
Management
-
Service Level
Management
OCM
ACM
Ontwerp
Realisatie
Testen
Implementatie
Beschikbaarheidsbeheer
Continuïteitsbeheer
Geen verschil
Capaciteitsbeheer
Geen verschil
Planning en control
Staat voor ITIL beschreven
in de Managers Set (apart
boek)
Geen verschil
Kwaliteitsmanagement
Staat voor ITIL beschreven
in de Managers Set (apart
boek)
Geen verschil
Gedeelten van de
processen zijn wel te
vinden in de andere
boeken van ITIL, maar
niet in de vorm waarin ASL
ze beschrijft.
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
32
1 proces heeft gezet. Het kan zijn dat ITIL het wat kort door de bocht heeft
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.
33
Technisch beheer
In het boek (bron:1) wordt veel gerefereerd aan technisch beheer. Veel
beslissingen worden gemaakt in samenwerking met technisch beheer en er
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.
Het opstellen van de SLA’s is erg moeilijk. Vaak worden ze onduidelijk en te
algemeen beschreven. Het is erg lastig om met alle partijen dezelfde
afspraak te maken. De geïnterviewde ziet de SLA’s als iets dat los staat van
ITIL of ASL, het zijn afspraken die met de klant gemaakt worden, of ASL
en/of ITIL geïmplementeerd worden of niet. Er werken dan ook op ieder
project minstens 2 man fulltime aan deze afspraken.
Een groot knelpunt in ASL is het testen, vertelt de geïnterviewde. Nieuwe/
verbeterde applicaties worden eerst door de ontwikkelaars getest en
moeten daarna door de klant getest worden. Omdat klanten vaak niet
precies weten wat ze allemaal moeten testen, worden er vaak dingen
vergeten. Het kan zijn dat de veranderde onderdelen in conflict komen met
andere applicaties. Als dat niet met testen ontdekt wordt dan zal de klant
een storing melden, terwijl het dus al eerder gecorrigeerd had kunnen
worden. Bij het implementeren van ASL is onder andere
Kwaliteitsmanagement een probleem omdat je hierbij afhankelijk bent van
de klant. Deze heeft in de meeste gevallen al een kwaliteitssysteem en
Getronics moet zich daar op aanpassen. Verder is de strategische laag erg
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 ITIL en ASL in 1 Service Desk kunnen is het antwoord nee.
De geïnterviewde is van mening dat een applicatiebeheer helpdesk beter
een skilled helpdesk kan zijn en een technisch beheer helpdesk kan
makkelijker unskilled zijn. Ze denkt dat het omschrijven van een software
probleem makkelijker gaat als de mensen van de helpdesk bekend zijn met
de applicaties. Ook vindt ze dat de classificatie erg moeilijk wordt als voor
beide hetzelfde pakket moet worden gebruikt voor de registratie. Aan de
andere kant ziet ze wel het voordeel dat er dan maar 1 aanspreekpunt is
voor de klant.
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.
Samenvattend is het in dit gesprek duidelijk geworden dat Getronics een
voorstander is van ASL, maar het niet tot de letter nauwkeurig opvolgt.
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.
De kwestie Problem Management is door Fortis opgelost door het Problem
Management van ITIL te verheffen tot overall proces en wordt nu dus voor
ITIL én ASL gebruikt.
Dit geldt nog niet voor Service Level Management. Het maken van SLA’s is
op dit moment niet helemaal duidelijk voor iedereen. Het is de bedoeling
daar 1 proces van te maken zodat ook hierin ASL en ITIL gelijk in komen te
staan. Aangezien Fortis ASL niet zelf heeft geïmplementeerd en de ervaring
nog maar kort is zijn er nog geen duidelijke knelpunten naar voren
gekomen.
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.
De organisatie heeft 1 centrale Service Desk. Alle incidenten kunnen hier
worden gemeld. Na de registratie bij de Service Desk wordt incidentbeheer
wel gesplitst, incidenten worden geleid richting ITIL processen of richting
38
ASL processen. En ook voor de applicatie-incidenten geldt dat ze zo snel
mogelijk opgelost moeten worden.
Op de vraag of ASL zonder ITIL kan bestaan kan de geïnterviewde geen
eenduidig antwoord geven. Hij is zelf van mening dat het wel kan, maar in
alle bij hem bekende informatie staat dat het niet kan. De meeste artikelen
melden dat ASL een verlengstuk is van ITIL.
ITIL alleen zou ook toereikend kunnen zijn. Er zijn dan wel andere tools
nodig (hij noemt CMMI) om gaten op te vullen. En als een organisatie zelf
geen software ontwikkelt en alleen inkoopt dan zou ITIL misschien wel
toereikend zijn.
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.
Alle beheerprocessen van ITIL en ASL zijn gescheiden. De enige echte
verbinding die ze hebben dat is de helpdesk, daarna wordt alles gescheiden.
Incidentbeheer is het enige proces dat strak is ingevoerd en in de gaten
wordt gehouden. De andere processen zijn wel ingevuld, maar niet zo
duidelijk als incidentbeheer. Zo zijn er meerdere werknemers die over
verschillende processen heen werken. Uiteraard wordt er wel informatie
uitgewisseld met de afdeling ICT (technisch beheer), er moeten wel
bepaalde zaken op elkaar zijn afgestemd.
De kwestie van Problem Management is bij Heijmans eigenlijk nog niet
opgelost. De huidige procedure is dat het incident open blijft staan tot er
een oplossing is. Bij een structureel probleem wordt er dus niet geëscaleerd
tot een probleem. Het nadeel hiervan is dat hierdoor de gemiddelde
oplostijden veel te hoog komen te liggen. Als een probleem geregistreerd
wordt, telt het niet meer mee met de oplostijd voor de incidenten. Je kunt
40
hierdoor nooit goede SLA’s afspreken en nakomen. De geïnterviewde erkent
dat dit een punt is waar nog over nagedacht kan worden.
De SLA’s worden samen met de afdeling ICT gemaakt. Als de afdeling
applicatiebeheer eigenaar is van de betreffende applicatie dan is de ICTafdeling in dit proces onderaannemer en zal deze erbij zijn als
informatieverschaffer en helpen met het formuleren van de afspraken. Na
het maken van de SLA’s is het essentieel dat er goede rapportages worden
gemaakt die vergeleken moeten worden met de originele afspraken. Het
maken van deze rapportages gaat steeds beter, ze hebben intussen
ongeveer een jaar ervaring. Men wordt alleen (nog) niet op de resultaten
afgerekend, dat kan wellicht in de toekomst veranderen.
Een groot knelpunt waar men tegenaan loopt is onduidelijkheid over de
strategie. De afdeling krijgt van het hogere management van de rest van de
organisatie regelmatig plannen waar ze hun strategie en richting uit moeten
halen. Vaak is het niet duidelijk hoe dit op hun afdeling zal weerspiegelen
en ze zijn daardoor niet in staat om plannen voor langer dan een jaar te
maken. De keuze voor ASL heeft de afdeling zelf gemaakt, het is niet door
het management gekozen. Het is nu de taak aan de afdeling om het
strategische niveau te laten zien dat ASL werkt en een aanwinst is voor de
organisatie. Als het management overtuigt is kunnen ze uitgebreidere
plannen maken en er ook budget voor krijgen. De geïnterviewde denkt dat
het goed is om het management bewuster te maken van wat er in de IT
gaande is zodat ze dat ook kunnen betrekken in hun strategieën.
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).
Applicatiebeheer met ITIL
Er wordt binnen AS volledig volgens de ITIL filosofie gewerkt. Bijna alle
processen zijn ingevuld en beschreven met als uitgangspunt
applicatiebeheer. In nauw overleg met technisch beheer zijn alle processen
goed op elkaar aangesloten. Er is 1 centrale helpdesk voor alle soorten
incidenten en aanvragen. De helpdesk leidt de incidenten na registratie door
naar de juiste oplosgroepen. Een groot pluspunt hierbij is dat het gebruikte
registratie programma, HP Open View Service Desk, perfect overal bij
aansluit. Dit programma wordt door de hele organisatie gebruikt voor het
registreren en oplossen van incidenten, problemen, klantaanvragen en
changes. Ook wordt de CMDB van technisch beheer hierin bijgehouden.
Er is geprobeerd om HP Open View ook voor de applicatie ontwikkeling te
gebruiken, maar dat heeft niet gewerkt. In plaats daarvan heeft de afdeling
nu een eigen systeem gemaakt waar de ontwikkeling van applicaties
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.
Ook Release Management wordt gebruikt op de afdeling, deze is sterk
gekoppeld aan Change Management. De release wordt samen met de klant
samengesteld. Het ITIL proces dat de release doorgaat is enigszins
aangepast aan het ABP. Ze hebben namelijk een eigen indeling van
processen gemaakt, ze hebben een proces Nieuwbouw, een proces
Onderhoud en een proces Exploitatie en Beheer.
Fig. 4 ABP model (bron: 7)
Exploitatie en Beheer vallen onder technisch beheer en Nieuwbouw en
Onderhoud onder applicatiebeheer. De releases worden gemaakt met
43
ondersteuning van Capability Maturity Model (CMM). Ook heeft Application
Services een eigen kwaliteitsmodel gemaakt, daarbij hebben ze ook CMM
gebruikt maar dan in combinatie met het beleid van ABP. Al deze processen
en procedures zijn het resultaat van jarenlange ervaring en aanpassingen.
ABP is dan ook al meer dan 10 jaar aan het werk met ITIL.
Zoals ik al eerder zei wordt de CMDB van technisch beheer bijgehouden in
HP Open View. Voor de software is er niet 1 grote database. In HP Open
View staan wel de informatie systemen genoemd die actief zijn, maar
zonder details. ABP heeft een softwaredistributie pakket dat Tivoli heet,
daarin staan alle strikt noodzakelijke gegevens die nodig zijn om de huidige
software te laten draaien. Voor versiebeheer zal men moeten kijken in de
ontwikkeltools en de documentatie van de software staat op het netwerk op
een afgeschermde plek. De informatie staat dus overal los van elkaar
opgeslagen. Ze vinden dit zelf niet handig, dus er loopt een onderzoek naar
een pakket waar dit allemaal in 1 keer kan worden opgeslagen.
Om al de gegevens toch goed bij te houden worden alle applicaties en hun
objecten ieder jaar gecontroleerd en bijgewerkt. Dit is onder andere de taak
van de afdeling Strategy en Control, waar de geïnterviewde voor werkt.
Incidenten die bij AS binnen komen zijn normaal gesproken eerst
gecontroleerd door een functioneel beheerder die op iedere afdeling zit.
Deze vertelt de gebruiker of het inderdaad een incident is. De gebruiker
meldt dit vervolgens bij de helpdesk. Als zij het niet kunnen oplossen en het
een applicatie-inhoudelijk incident is wordt de melding doorgestuurd naar
AS. Hier zitten aangewezen mensen om deze zaken op te pakken. Ook
problemen worden op die manier behandeld, alleen worden die pas
opgepakt als er genoeg tijd voor is. Al deze processen vinden plaats in HP
Open View en volgens de regels van ITIL.
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.
De laatste vraag was of ITIL onderdelen mist om applicaties te beheren. De
geïnterviewde vindt van niet. Tot nu toe is het met ITIL erg goed gegaan.
Het enige wat beter zou kunnen is de registratie van de software (aparte
CMDB), qua proces is er nooit een gemis geweest, vooral omdat ze ITIL zo
hebben gevormd door de jaren heen dat het precies in de organisatie past.
ASL zal voor het ABP dus geen noodzaak zijn, omdat de processen door
jarenlange ervaring goed lopen. Maar het is wel het overwegen waard.
45
7.5. Beoordeling ASL vs Release Management
Als laatste hebben alle geïnterviewden in onderstaande tabel hun voorkeur
kunnen uitspreken voor processen van ITIL of ASL vanuit het oogpunt van
applicatiebeheer, dit is het resultaat:
Tabel 2 Uitslag beoordeling
Proces (-cluster)/koppeling
Beheer (incidentbeheer/conf.beheer/etc)
Releaseplanning/Impactanalyse
Ontwerp
Bouw
Testen
Implementatie
Processen onderhoud+vernieuwing t.o.v. Release
management
Koppeling naar wijzigingenbeheer
Koppeling naar configuratiebeheer
Keuze bij gebruik third-party/ingekochte software (als
onderhoud+vernieuwing niet noodzakelijk is)
Algemene beoordeling
ITIL
**
*
*
**
*
ASL
***
****
****
****
****
***
****
***
**
***
****
* De sterretjes staan voor de keuze die de bedrijven hebben gemaakt (1
bedrijf had bij ‘beheer’ 2 sterretjes ingevuld)
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).
Kan ASL zonder ITIL?
Kan applicatiebeheer zonder technisch beheer? Dat antwoord is nee, daar
zal iedereen het mee eens zijn. Kan ASL zonder ITIL? Dit antwoord is
waarschijnlijk ook nee. De methode ASL is geschreven zodat het geen delen
ITIL nodig heeft, als theorie zal het overeind blijven staan. Maar omdat
applicatiebeheer technisch beheer nodig heeft om alles te laten draaien,
zullen ze niet zonder elkaar kunnen, dat vonden de geïnterviewden ook.
Kan ITIL zonder ASL?
Of ASL noodzakelijk is voor applicatiebeheer, dat is een andere vraag. Het is
uiteraard een zeer goede methode en aan te raden voor iedere organisatie
die nog op zoek is naar een oplossing voor applicatiebeheer. Maar voor een
organisatie zoals het ABP waar al zo lang met ITIL wordt gewerkt en waar
het zo precies in de organisaties past, lijkt het mij niet verstandig om voor
ASL een hele reorganisatie op poten te zetten. Ik vind dat het ABP heeft
bewezen dat applicatiebeheer ook goed in ITIL past. Hoewel aan de andere
kant het ABP wel extra eigen processen heeft samengesteld. Is dit gedaan
omdat daar in ITIL geen ruimte voor was? Omdat hier geen duidelijke
leidraad voor was? Dit zou kunnen betekenen dat ITIL toch iets mist, of in
elk geval niet duidelijk genoeg is. Hoe het ook zij, de geïnterviewde van het
ABP heeft intussen aanbevolen om het strategische niveau en de
communicatie niveaus van ASL nog verder te laten bestuderen. De optie
ASL is dus nog niet van tafel.
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.
Hier nog eens kort de conclusies op een rij:
-
De strategische laag wordt niet tot nauwelijks ingericht.
-
Het maakt niet uit of je de beheerprocessen van ASL en ITIL
samenvoegt of apart houdt.
-
De manier van ASL om problemen op te lossen is niet erg praktisch.
-
SLA’s kunnen het best samen gemaakt worden (ASL en ITIL tegelijk).
-
Er wordt 1 centrale Service Desk ingericht.
-
Er worden 2 aparte CMDB’s gebruikt.
-
ASL kan niet zonder ITIL.
-
ITIL kan wel zonder ASL.
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
Vragen voor bedrijven met ASL:
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:
1. In hoeverre wordt in uw organisatie met ITIL gewerkt?
2. Wordt hierin ook Release Management gebruikt (stuk
applicatiebeheer)?
3. Zo nee, hoe worden bij uw bedrijf applicaties beheerd?
4. Is er een CMDB of andere database?
5. Hoe worden incidenten en problemen afgehandeld?
6. Heeft u al eens gehoord van ASL?
7. Vindt u dit een goede methode om applicaties te beheren?
8. Zou u dit in uw bedrijf kunnen of willen gebruiken?
9. Wat denkt u van een gescheiden CMDB? Dus 1 voor technisch beheer
(ITIL) en 1 voor applicatiebeheer.
10.Mist ITIL onderdelen om applicaties te beheren?
53