ITIL ASL

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. 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. 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 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. 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 ondersteuning van Capability Maturity Model (CMM). Ook heeft Application 43

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