Onderzoek ITIL versus ASL

Onderzoek ITIL versus ASL Datum: 6 april 2011 Status: definitief Opgesteld door: SYSQA B.V.

Organisatie SYSQA B.V. Pagina 1 van 20 Inhoudsopgave. 1. samenvatting.... 2 2. Inleiding.... 3 3. Wat is ASL?... 4 3.1. Introductie.... 4 3.2. Het framework.... 4 4. Wat is ITIL?... 8 4.1. Introductie.... 8 4.2. De opbouw.... 8 5. ITIL versus ASL.... 10 5.1. Algemeen.... 10 5.2. Nadere uitwerking.... 11 5.3. Positie van ASL ten opzichte van ITIL.... 13 6. Conclusie... 15 Literatuurlijst.... 16 Bijlage 1: Het R2C proces model.... 17 Bijlage 2: Het nieuwe Functioneel Beheer Model.... 18 Bijlage 3: Verschillen per managementniveau.... 19 Versiebeheer. Versie Datum Opmerkingen Uitvoering 1.0 18-06-2003 Concept voorgelegd SYSQA 1.1 10-07-2003 Commentaar verwerkt. SYSQA 1.2 21-07-2003 Commentaar verwerkt. SYSQA 1.3 06-04-2011 Aanpassen opmaak SYSQA

Organisatie SYSQA B.V. Pagina 2 van 20 1. samenvatting. Dit document is het resultaat van onderzoek naar de verschillen tussen ITIL (Information Technology Infrastructure Library) en ASL (Application Services Library). Tijdens dit onderzoek is duidelijk geworden dat er een verschil is in focus: ITIL richt zich op tactisch en operationeel niveau vooral op (het beheer van) de infrastructuur, terwijl ASL, op deze niveaus een kopie van het R2C procesmodel, een framework voor applicatiebeheerprocessen is. Op strategisch niveau besteden beide methodieken, ITIL uitgebreider dan ASL, aandacht aan beleidsmatige zaken. In de beheerprocessen van ASL komen van ITIL afgeleide procesnamen voor. De tussen deze gelijknamige processen bestaande overeenkomsten en verschillen zijn in onderstaande tabel te zien: Overeenkomsten o Procesnamen komen overeen; o Procesdoelstellingen komen overeen; o Procesinrichting komt op hoofdlijnen overeen. Verschillen o Invulling processen (procedures, activiteiten) verschilt; o Key Performance Indicators verschillen; o Andere betrokken functionarissen; o Vaak andere externe leveranciers met andere werkwijzen. Daarnaast is opgevallen dat er verschillen zijn bij de positionering van (delen van) enkele gelijknamige processen op tactisch en operationeel niveau. Zo zijn de processen Capaciteits-, Beschikbaarheidsen Continuïteitsbeheer operationele ASL-processen, terwijl ze binnen ITIL op het tactisch niveau zijn ondergebracht. De onderhouds- en vernieuwingsprocessen zijn in ITIL opgenomen als activiteiten van de processen Change en Release. Concluderend kan worden gesteld dat de processen in de beheerbol van ASL overeen komen met die van ITIL en Change de brug is tussen de ITIL- en ASL-wereld. Tevens is gebleken dat de echte meerwaarde van de ASL-beheerprocessen, hoewel ze een duidelijk andere focus hebben dan de gelijknamige ITIL-processen, zit in de verschillen tussen deze processen. Praktisch gezien wordt dan ook aanbevolen de ITIL en ASL-beheerprocesbeschrijvingen te combineren, te bezien waar de specifieke bedrijfsbehoefte ligt en dan over te gaan tot implementatie van de relevante delen. Verder kan worden geconcludeerd dat: o ASL een welkome aanvulling van ITIL is. In het ITIL proces Release wordt wel rekening gehouden met software-onderhoud en het beheer van de daardoor ontstane verschillende versies, maar is er een grote afstand tussen technisch beheer en de voor het onderhoud verantwoordelijke instantie. Dankzij ASL wordt deze afstand verkleind, waardoor technisch beheer in een vroeg stadium betrokken wordt bij het onderhoudsproces. o Het ITIL proces Release gericht is op beheer van versies van Commercial Off the shelf (COTS) software, terwijl ASL vooral uitgaat van het gebruik van zelf (al dan niet in eigen beheer) ontwikkelde software. o Zowel ITIL als ASL zich beperken tot het geven van richtlijnen voor de inrichting van de processen. ITIL geeft wel voorbeelden van technieken of hulpmiddelen die kunnen worden gebruikt ter ondersteuning van de processen. ASL laat zich daar niet over uit. o ITIL aangeeft met welke procesrollen rekening moet worden gehouden, terwijl ASL daar géén aandacht aan besteedt. o De organisatiekundige aspecten in ASL niet als zodanig aan de orde worden gesteld. ITIL besteedt daar wel aandacht aan. o De Configuration Database (CMDB) van ASL geen één-op-één relatie heeft met de ITIL CMDB, hetgeen betekent dat gebruik van de ITIL CMDB in ASL niet mogelijk is. Mijnsinziens is het wel degelijk mogelijk de voor ASL belangrijke objecten in de ITIL CMDB vast te leggen en daarover te rapporteren. De mate waarin dat mogelijk is, is afhankelijk van de gekozen detaillering en diepgang van de ITIL CMDB. Of ITIL Applications gevolgen heeft voor ASL is nog niet duidelijk, omdat een vergelijking van de in het boek over dit onderwerp behandelde theorie met de theorie van ASL tijdens dit onderzoek niet mogelijk was.

Organisatie SYSQA B.V. Pagina 3 van 20 2. Inleiding. Wanneer we praten over beheer van ICT-voorzieningen, dan moet onderscheid worden gemaakt tussen: Applicatiebeheer; Technisch beheer; Functioneel beheer. Applicatiebeheer is verantwoordelijk voor de instandhouding van de applicatieprogrammatuur en de gegevensbanken. Het is dus de partij die het informatiesysteem (de applicatie) beheert en onderhoudt. Technisch beheer is verantwoordelijk voor de instandhouding van de operationalisering van het informatiesysteem, dat bestaat uit apparatuur, programmatuur en gegevensverzamelingen. Kortweg is dit de organisatie die de informatiesystemen draait en zorgt dat de infrastructuur in orde blijft. Functioneel beheer is namens de gebruikersorganisatie verantwoordelijk voor het instandhouden van de functionaliteit van een ICT-voorziening. Het functioneel beheer fungeert dus eigenlijk als eigenaar en opdrachtgever voor het informatiesysteem. In onderstaande figuur zijn enkele verschillen tussen deze drie beheerdomeinen opgenomen. figuur 1. Vormen van beheer. Voor het invullen van de beheerdomeinen Applicatiebeheer en Technisch beheer zijn methodieken bedacht. Zo is ITIL de methodiek die een steeds groter aandeel krijgt bij de invulling van Technisch beheer. Voor Applicatiebeheer is ASL, Application Services Library, ook wel ITIL voor applicatiebeheer genoemd, een methodiek die steeds populairder wordt. In dit document wordt getracht de verschillen tussen ITIL en ASL op een rij te zetten. Een model voor de invulling van Functioneel beheer is het Functioneel Beheer Model (FBM). Dit van het R2C proces model (zie bijlage 1) afgeleid model is grafisch weergegeven in bijlage 2. Aangezien de focus in dit document gericht is op applicatiebeheer en technisch beheer, wordt verder geen aandacht besteed aan het onderwerp functioneel beheer.

Organisatie SYSQA B.V. Pagina 4 van 20 3. Wat is ASL? 3.1. Introductie. Op basis van kennis en ervaring met andere beheermodellen en een onderzoek is een nieuw framework voor applicatiebeheer ontstaan, waarin met name de ervaringen met R2C zijn meegenomen. Het R2C model is enkele jaren geleden ontwikkeld en in een groot aantal organisaties geïmplementeerd en in praktijk gebracht. Er is dus de nodige praktijkervaring mee opgedaan. ASL, Application Services Library, biedt een framework voor applicatiebeheer dat gestoeld is op de best practices van professionals met jarenlange ervaring. Het model is zodanig ontwikkeld dat het de optimale ICT-ondersteuning van bedrijfsprocessen garandeert. Zo kan men zich concentreren op de core-business. ASL beperkt zich tot het geven van richtlijnen voor het inrichten van processen en laat de inrichting van de beheerorganisatie geheel vrij. Hierdoor is het framework algemeen toepasbaar binnen de ICT-dienstverlening, onafhankelijk van de maat van de organisatie. ASL speelt in op de volgende, deels uit het Extended ISO-model afkomstige, eisen aan applicatiebeheer: Inzichtelijkheid. Organisaties hebben een grote behoefte aan inzichtelijkheid in de dienstverlening op het terrein van applicatiebeheer en de daarmee samenhangende kosten. De kosten zijn eenvoudigweg te hoog om niet marktconform te mogen zijn; Stuurbaarheid van kosten, applicaties en dienstverlening. Inzichtelijkheid heeft geen zin, indien er niet gestuurd kan worden. Het belang van applicaties raakt in vele organisaties het directe bedrijfsproces. Dit eist een verantwoorde afweging, een valide onderbouwing en vergelijking van alle alternatieven (de geroemde business case); Overdraagbaarheid en vergelijkbaarheid van mensen en applicatiebeheerorganisatie. Informatievoorziening is voor veel bedrijven uitermate essentieel: zonder werkende informatiesystemen is er geen organisatie meer. Daarmee is de continuïteit van informatiesystemen een noodzakelijke voorwaarde geworden voor de continuïteit van de organisatie. Afhankelijk zijn van enkele personen (ontwerpers/programmeurs) past daar niet meer in; Flexibiliteit van applicaties en een actieve blik op de toekomst. Informatiesystemen zijn dusdanig omvangrijk geworden, dat vervanging in vele gevallen een aantal jaren duurt. Applicaties gaan structureel langer mee dan gedacht. Ruwweg 80% van de bestaande applicaties bestaan over vijf jaar nog. Omdat applicaties in het hart van de organisatie zitten, bepalen deze ook de concurrentiepositie van een bedrijf en dus ook over vijf jaar. Het wordt daarom eens tijd voor een meer vooruitziende blik ten aanzien van deze informatiesystemen; Betrouwbaarheid: het niet adequaat opereren van een informatiesysteem levert directe en ingrijpende continuïteitsrisico s op voor een informatie-intensieve organisatie; Uniformiteit van applicatiebeheer en onderlinge aansluitbaarheid van applicaties vormen steeds meer een kritieke succesfactor door de explosief groeiende connectiviteit tussen organisaties. Om invulling te geven aan bovengenoemde eisen kent ASL een viertal belangrijke concepten: 1. De serviceteamgedachte: het inrichten van een centraal aanspreekpunt, dat verantwoordelijkheid neemt over de volledige dienstverlening op het terrein van ICT, zodat er eenduidigheid ontstaat naar de gebruikersorganisatie; 2. stuurbare dienstverlening door servicegerichte afspraken en inzichtelijkheid in kosten; 3. pro-actieve innovatie van applicaties en dienstverlening; 4. integraal management over beheer en onderhoud/vernieuwing heen. 3.2. Het framework. In het ASL framework worden 6 procesclusters onderscheiden: - de beheerprocessen die er voor zorgen dat de applicaties dagelijks dat doen wat ze moeten doen; - de onderhouds/vernieuwingsprocessen, waar de applicaties worden aangepast naar aanleiding van verstoringen en op basis van nieuwe eisen en wensen;

Organisatie SYSQA B.V. Pagina 5 van 20 - de verbindende processen die o.a. de overdracht van dagelijks beheer naar onderhoud en vice versa regelen; - de sturende (management-) processen; - de twee richtinggevende (strategische) procesclusters waarin enerzijds de strategie ten aanzien van de ondersteuning van de bedrijfsprocessen door ICT wordt bepaald (Applications Cycle ) en anderzijds de toekomstvisie van de ICT service-organisatie zelf (Organization Cycle ). figuur 2. ASL onderkent twee clusteringscriteria voor de applicatiebeheerprocessen: 1. een onderscheid tussen dienstverleningsprocessen (service) en de invalshoek applicaties. Die laatste invalshoek is onderscheidend van andere vormen van beheer, zoals technisch beheer; 2. een onderscheid tussen richtinggevende (beleidsbepalende), sturende en uitvoerende (operationele) processen. Servicegericht versus applicatiegericht Applicatiebeheer richt zich op het ondersteunen van de bedrijfsprocessen door informatiesystemen voor de levensduur van deze bedrijfsprocessen. In deze definitie zijn twee gezichtspunten te onderkennen. Het eerste is het perspectief van 'het ondersteunen van de bedrijfsprocessen door informatiesystemen'. Dit betekent het in de lucht houden van de applicaties, en zorgen dat deze de dagelijkse werkzaamheden van een organisatie ondersteunen. Dus continue dienstverlening op basis van goede afspraken over het service level, een zo spoedig mogelijk herstel van het afgesproken service level bij de constatering van een afwijking, het voorkómen van verstoringen en het mogelijk maken van nieuwe diensten door hier als ICTdienstverlener tijdig op in te spelen. De focus is dus dienstverlening, de service die geleverd wordt en die (samen met infrastructuur management) het gebruik van applicaties mogelijk maakt. In de omvang van dienstverlening praat men in de regel over een percentage van 10 à 20% van het totale applicatiebeheer. Het tweede gezichtspunt betreft 'de levensduur van de bedrijfsprocessen'. Organisaties evolueren, omgeving en markt veranderen. Om optimaal te kunnen blijven functioneren moeten de ondersteunende informatiesystemen dus meegroeien. Dit behelst een aanpassing van de applicaties aan huidige en toekomstige technische en functionele wensen. De applicatiegerichte processen vormen in de regel het overgrote deel van de kosten voor applicatiebeheer.

Organisatie SYSQA B.V. Pagina 6 van 20 Service-invalshoek Applicatie-invalshoek Doelstelling Leveren van optimale services aan gebruikers Leveren van optimale applicatie Focus Gebruikersorganisatie Bedrijfsproces van gebruikersorganisatie Belangrijkste kennis Kennis van de gebruikers en hun organisatie Kennis van de markt en het proces van de gebruikersorganisatie Belangrijke woorden Service, up time, dienstverlening, Entiteiten uit de markt/applicatie als verzekeringsproduct, factuur Vernieuwing Waar gaat de klant heen, wat zijn de mondiale ontwikkelingen, welke diensten kiest de ICT leverancier op basis hiervan. Waar gaat de markt van de klant heen, wat betekent dat voor zijn bedrijfsproces en de ondersteunende applicaties Richtinggevend, sturend, uitvoerend In het ASL framework is, naast de meer gebruikelijke uitvoerende en sturende processen, een expliciete laag opgenomen ten behoeve van de richtinggevende processen. Het richtinggevende niveau onderscheidt ook twee clusters van processen, gebaseerd op de onderverdeling in 'serviceinvalshoek' en 'applicatie-invalshoek'. Een huidige service provider (zowel op het terrein van het leveren van operationele services als het servicegericht leveren van applicatie-onderhoud) is in deze tijd van flexibilisering van diensten en leveranciers niet noodzakelijkerwijze degene die het onderhoud en/of beheer van de betreffende applicaties voor altijd doet. Om talloze redenen zou een andere dienstverlener deze taak ook kunnen uitvoeren. De concurrentie tussen dienstverleners over de te leveren diensten neemt toe. Het losknippen van beide invalshoeken maakt een eigen keuze mogelijk voor elk terrein. Binnen de clusters worden onderstaande processen onderscheiden: Beheer Incident Mngt, Configuration Mngt, Availability Mngt, Capacity Mngt, Continuity Mngt Verbindende processen Change Mngt Software Control & Distribution Onderhoud/ vernieuwing Impact Analysis Design Realization Testing Implementation Sturende management processen Planning & Control, Cost Mngt Quality Mngt, Service Level Mngt Applications Cycle Customer Environment Strategy, Customer Organization Strategy, ICT-developments Strategy, Life Cycle Mngt ICT-Portfolio Mngt Organization Cycle Account Definition, Market Definition, Skills Definition, Technology Definition, Service Delivery Definition Grafisch ziet het gedetailleerd framework er uit zoals in onderstaande figuur is aangegeven.

Organisatie SYSQA B.V. Pagina 7 van 20 Services Applicatie OCM Account definition Demand Market definition ACM Customer Organization Strategy Richtinggevend Skills definition Service Delivery definition Delivery Technology definition Supply ICT- Developments Strategy ICT-portfolio management Life cycle management Customer Environment Strategy Sturend Planning and Control Cost Quality Service Level Incident Change Design Uitvoerend Continuity Capacity Beheer Availability Configuration figuur 3. Implementation Software Control & distribution Verbindende processen Impact analysis Testing Realization Onderhoud/vernieuwing

Organisatie SYSQA B.V. Pagina 8 van 20 4. Wat is ITIL? 4.1. Introductie. ITIL, Information Technology Infrastructure Library, heeft als hoofddoel het faciliteren van verbeteringen van efficiëntie en effectiviteit in het leveren van kwalitatief hoogstaande ITdienstverlening en het managen van de IT-infrastructuur binnen een organisatie. Deze op Best practices gebaseerde methode bestaat uit 6 hoofdelementen, namelijk: 1. Het zakelijk perspectief (Business perspective). 2. Levering en planning van IT-diensten (Service Delivery). 3. Ondersteuning van IT-diensten (Service Support). 4. van de infrastructuur (ICT Infrastructure ). 5. van applicaties (Applications ). 6. Managers Set. Deze elementen worden in de volgende paragraaf kort beschreven. 4.2. De opbouw. De boeken over de in 4.1 genoemde sets beschrijven de volgende onderwerpen: 1. De Business Perspective Set beschrijft een groot aantal onderwerpen die te maken hebben met het begrijpen en het verbeteren van de IT-dienstverlening als een integraal onderdeel van het besturen van de onderneming (business management). Onderwerpen uit deze set zijn: Business Continuity. Partnerships en outsourcing. Het overleven van veranderingen. Het aanpassen van de onderneming bij radicale veranderingen. Daarnaast worden de volgende onderwerpen in aparte boeken behandeld: Managing Facilities (Uitbesteding van IT-diensten). Managing Supplier Relationships (Relatiebeheer leveranciers). 2. De Service Delivery set beschrijft de diensten die de business van de klant nodig heeft en wat er nodig is om deze diensten te kunnen leveren. Daarbij komen de volgende onderwerpen aan de orde: Customer Relationship. Service Level. Financial for IT Services. Capacity. Availability. Security. IT Service Continuity. 3. De Service Support set beschrijft hoe de klant toegang kan krijgen tot de juiste dienstverlening om zijn onderneming te ondersteunen. In dit boek komen de volgende onderwerpen aan de orde: Service Desk. Incident. Problem. Configuration. Change. Release.

Organisatie SYSQA B.V. Pagina 9 van 20 4. Het ICT Infrastructure boek omvat: Network Service. Operations. of Local Processors. Computer Installation and Acceptance. Systems. 5. Het onlangs uitgebracht boek over Applications (Applicatiebeheer) gaat over de relatie van beheer met de levenscyclus van de software (Ontwerp tot en met buitengebruikstelling). Dit omvat onder meer Software Lifecycle Support en Testing of IT Services (testen van ITdiensten). Applications heeft de belangrijke opgave om op een goede manier om te gaan met de veranderingen in de business, waarbij het helder definiëren van de eisen en het implementeren van een oplossing die aan de behoeften van de klantorganisatie voldoet, vooraan staan. Software Lifecycle Support heeft tot doel om, samen met de verantwoordelijken voor de ontwikkeling van programmatuur, een aanpak te bepalen voor de ondersteuning van de gehele levenscyclus van de programmatuur. Het doel van Testing of IT Services is ervoor te zorgen dat getest wordt of nieuwe of aangepaste IT-diensten goed functioneren voordat ze operationeel worden. Met een systeemtest, een installatietest en een acceptatietest wordt nagegaan of de ontwikkelde aanpassing werkt, goed is geïnstalleerd, aansluit bij de rest van de IT-infrastructuur en of het de gebruikers de functionaliteit biedt die met de opdrachtgever is overeengekomen. 6. In de Managers Set wordt aandacht besteed aan de volgende onderwerpen: Quality for IT Services. IT Services Organisation. Planning and Control for IT Services.

Organisatie SYSQA B.V. Pagina 10 van 20 5. ITIL versus ASL. 5.1. Algemeen. Na de korte omschrijving van ASL en ITIL wordt in dit hoofdstuk aandacht besteed aan de verschillen tussen deze beheermethodieken. Daarbij wordt uitgegaan van de ITIL-processen. Allereerst is er een verschil in focus: ITIL (Information Technology Infrastructure Library) richt zich vooral op (het beheer van) de infrastructuur. ASL (Application Services Library) is een framework voor applicatiebeheerprocessen. In de beheerprocessen van ASL komen we bekende procesnamen tegen. Deze zijn inderdaad afgeleid van ITIL en hebben tal van overeenkomsten: Namen komen overeen; Doelstellingen komen overeen; Procesinrichting komt op hoofdlijnen overeen. Maar er zijn uiteraard ook verschillen: Invulling processen (procedures, activiteiten) verschilt; Key Performance Indicators verschillen; Andere betrokken medewerkers; Vaak andere externe leveranciers met andere werkwijzen. Daarnaast is opgevallen dat er verschillen zijn bij de positionering van (delen van) enkele gelijknamige processen op strategisch, tactisch en operationeel niveau. Zo zijn de processen Capaciteits-, Beschikbaarheids- en Continuïteitsbeheer operationele ASL-processen, terwijl ze binnen ITIL op het tactisch niveau zijn ondergebracht. Tenslotte zijn de onderhouds- en vernieuwingsprocessen in ITIL opgenomen als activiteiten van de processen Change en Release. Onderstaande tabel geeft een beeld van de mate waarin op tactisch en operationeel niveau sprake is van gelijknamige processen. In deze tabel wordt een proces weergegeven door de letter P, terwijl de A op een activiteit duidt. In geval van de N is er geen sprake van een proces of een activiteit. Grafisch ziet het er als volgt uit: Proces / Activiteit ITIL ASL Incidentbeheer P P Wijzigingsbeheer P P Capaciteitsbeheer P P Beschikbaarheidsbeheer P P Continuïteitsbeheer P P Configuratiebeheer P P Release P P Kostenmanagement P P Service Level P P Probleembeheer P A Beveiligingsbeheer P N Impactanalyse A P Ontwerp A P Realisatie A P Testen A P Implementatie A P Planning en control A P Kwaliteitsmanagement A P

Organisatie SYSQA B.V. Pagina 11 van 20 Verder besteden zowel ITIL als ASL aandacht aan de meer op het strategisch niveau zittende onderwerpen, zoals Business Continuity, Supplier Relationship, Kwaliteitsbeheer en Customer Relationship (zie bijlage 3). Wel is het zo dat in ITIL aan al deze onderwerpen aparte boeken zijn gewijd, terwijl in ASL wordt volstaan met een beschrijving van de processen Organization Cycle (OCM) en Applications Cycle (ACM). Ook aan het beheer van (de levenscyclus van) applicaties is sinds kort een boek gewijd. De ASL-processen Ontwerp, Realisatie, Testen en Implementatie doen het vermoeden betssan dat elementen van SDM-II in ASL zijn opgenomen. Vanwege de scope van dit document is daar niet verder naar gekeken. In de volgende paragraaf worden de verschillen tussen de gelijknamige processen nader uitgewerkt. 5.2. Nadere uitwerking. De verschillen tussen de beheersprocessen van ITIL en die van ASL zijn onderstaand aangegeven. 1 Incidentbeheer. Incidentbeheer heeft zowel in ITIL als ASL als doel zorg te dragen voor een zo spoedig mogelijk herstel van het afgesproken service level door verstoringen zo spoedig mogelijk op te lossen. Het oplossen van applicatieverstoringen vergt doorgaans inzet van software-specialisten, die ofwel op andere afdelingen werken ofwel bij een externe leverancier werkzaam zijn. Doordat ook nog eens vaak releasematig wordt gewerkt, is de doorlooptijd van kleinere incidenten vaak lang. Reden dat er vaker dan bij infrastructuurproblemen wordt gezocht naar een workaround. Die vervolgens langere tijd wordt gebruikt. Een goede administratie van incidenten en bijbehorende workarounds is binnen ASL- Incidentbeheer kortom een zeer zinvolle activiteit. Configuratiebeheer. De doelstellingen en activiteiten van configuratiebeheer in ASL en ITIL vertonen een grote overlap. In de praktijk is dit proces eenvoudig integraal uit te voeren voor zowel technisch als applicatiebeheer. Wel is er de kwestie of er 1 CMDB (Configuration Database) of meerdere zouden moeten worden ingericht. In het boek ASL-een framework voor applicatiebeheer van R. van der Pols wordt gesteld dat het bijhouden van (versies) van applicaties beter in een aparte CMDB, naast de 1 www.asl-at-work.nl

Organisatie SYSQA B.V. Pagina 12 van 20 CMDB van technisch beheer, kan worden gedaan. Redenen zijn dat diverse versies van applicaties over meerdere platformen en technisch beheerorganisaties heen kunnen opereren. Het is in de praktijk natuurlijk maar de vraag of deze n-op-m relatie het best kan worden geïmplementeerd door middel van meerdere CMDB's. ASL biedt in ieder geval een helderder perspectief op welke informatie betreffende applicaties in een CMDB moet worden opgeslagen. Een toevoeging in ASL die wellicht nut kan hebben is het concreet opslaan van zogenaamde dienstverleningsobjecten. In SLA's wordt een bepaald dienstverleningsniveau afgesproken, en conform ASL wordt dit vertaald in service-items die worden opgeslagen in een SDDB (Service Delivery Database). Beschikbaarheidsbeheer. Ook het proces beschikbaarheidsbeheer kent grote overeenkomsten tussen ITIL en ASL. De positionering in ASL is echter operationeel. Een groot deel van de activiteiten is echter toch strategisch/tactisch van aard. Een operationele activiteit die ASL wel en ITIL niet kent is het opstellen van een verwerkingsplanning. Onderdelen daarvan zijn de applicatieproductieplanning, afwijkende verwerkingen en aanvullende/veranderende verwerkingen. Capaciteitsbeheer. Capaciteitsbeheer wordt net als beschikbaarheidsbeheer in ASL op operationeel niveau gepositioneerd. De activiteiten bevinden zich echter grotendeels op tactisch niveau. Inhoudelijk wijkt het proces duidelijk af van het gelijknamige ITIL-proces. Binnen technisch beheer is vrij duidelijk hoe capaciteit kan worden afgestemd op de vraag. Maar de capaciteit van een applicatie is veelal 'oneindig' schaalbaar zonder inspanningen of kosten. Immers, of een applicatie door 1 of door 3000 gebruikers wordt gebruikt, voor de applicatie maakt dat niet uit (maar wel voor de technische infrastructuur ITIL). De activiteiten van ASL-capaciteitsbeheer betreffen dan ook: 1. werklastbeheersing: het aanpassen / verplaatsen van de vraag door bijvoorbeeld verschuiven of opdelen van verwerkingen 2. middelen: verdelen over meer servers, waardoor ook applicaties moeten worden aangepast 3. optimalisatie van prestaties: 'zuinig' programmeren, denormalisatie bestanden, schoning bestanden, etc. Continuïteitsbeheer. Tot slot is ook continuïteitsbeheer binnen ASL op operationeel niveau gedefinieerd. Er zijn ook hier veel activiteiten op tactisch/strategisch niveau te onderkennen. De focus binnen ASL ligt uiteraard op continuïteit van applicaties. Aldus komen hier andere aspecten aan bod dan binnen ITIL. Continuïteit binnen ASL betekent aandacht voor: 1. Beveiliging: tegen oneigenlijk gebruik van applicaties en databanken, ongeautoriseerde wijziging (hackers!) 2. Beveiliging-2: inzet van applicaties die zorg moeten dragen voor beveiliging (firewall etc) 3. Zorg om sources: bij uitwijk zijn niet alleen de executables van belang, maar ook de sources, documentatie en procedures. 4. Zorg om externe leveranciers: hoe groot is de afhankelijkheid van 1 leverancier (maatwerksoftware), hoe is daar de continuïteit geregeld? Onderstaande tabel laat vanuit een andere invalshoek per (gelijknamig) tactisch of operationeel proces de verschillen tussen ITIL en ASL zien. Proces ITIL ASL Incident- De nadruk ligt op het lokaliseren van de De nadruk ligt op het verzamelen van beheer oorzaak van het incident (is het de hardware, informatie, zodat het incident kan worden Probleembeheer Wijzigingsbeheer Capaciteitsbeheer software of een combinatie?). Diepere problemen bijvoorbeeld herhaling van een incident zijn ondergebracht in Problem. Is controle gericht en heeft v.w.b. soft- en hardwareversies het proces Release als uitvoerend proces. Een tactisch proces. herhaald. Diepere problemen vallen onder Kwaliteit. Er is geen apart proces voor Probleembeheer. De voortgang van een release wordt bewaakt binnen het proces Planning & Control. Heeft als technische variant het proces Programmabeheer & Distributie. Een operationeel proces.

Organisatie SYSQA B.V. Pagina 13 van 20 Proces ITIL ASL Beschikbaarheidsbeheer Continuïteitsbeheer Configuratiebeheer Release Een tactisch proces. Aandacht voor herstelbaarheid, beveiliging en onderhoud (geplande down time). Een tactisch proces. De CMDB wordt gebruikt voor het registreren van alle IT-productiemiddelen en de relaties daartussen. Voert het beheer en de distributie uit van software- en hardwareversies die in gebruik zijn en die door de IT-afdeling worden ondersteund, teneinde te voldoen aan het vereiste niveau van dienstverlening. Een operationeel proces. Geen aandacht voor herstelbaarheid, beveiliging en onderhoud (geplande down time). Een operationeel proces. De CMDB wordt gebruikt voor het registreren en bijhouden van informatie over het gebruik van de (versies van) objecten, behorend bij een informatiesysteem/applicatie. Deze term wordt niet gebruikt. De activiteiten in het kader van Release management zijn ondergebracht bij de onderhouds/ vernieuwingsprocessen en het verbindend proces Programmabeheer & Distributie. De Release-administratie is bij Change ondergebracht. Het overhevelen van gewijzigde versies wordt uitgevoerd door het proces Programmabeheer & Distributie. De opzet en werking van het programmabeheersysteem valt onder kwaliteitsmanagement. Proces binnen Onderhoud/Vernieuwing. Impactanalyse Geen apart proces. Een activiteit binnen het proces Change. Ontwerp Activiteit binnen Release. Proces binnen Onderhoud/Vernieuwing. Realisatie Activiteit binnen Release. Proces binnen Onderhoud/Vernieuwing. Testen Activiteit binnen Release. Onder Proces binnen Onderhoud/Vernieuwing. verantwoordelijkheid van Change. Implementatie Activiteit binnen Release. Proces binnen Onderhoud/Vernieuwing. Planning en control Kostenmanagement Kwaliteitsmanagement Service Level Wordt binnen de verschillende processen ingevuld. Daarnaast vindt de beleidsmatige invulling op strategisch niveau in de Managers Set plaats. Ingevuld door het proces Financial for IT Services. Gebruik van kpi s door de processen. Sturing op kwaliteit is dus in deze processen ondergebracht. Daarnaast vindt de beleidsmatige invulling op strategisch niveau in de Managers Set plaats. Dit proces is als brug tussen de leverancier van de IT-diensten en de afnemer van de diensten, de klant, verantwoordelijk voor: De integratie tussen de afzonderlijke elementen waaruit de dienstverlening bestaat; Het documenteren van de dienstverlening; Het aanbieden van de diensten. Verantwoordelijk voor inzet, planning en voortgangsbewaking van alle operationele processen. Deze processen en de overige sturende processen rapporteren over voortgang en uitputtingen. Verantwoordelijk voor een adequate ondersteuning en inrichting van de applicatiebeheerprocessen d.m.v. het kwaliteitssysteem. Alles wat niet afgesproken is met de klant, maar toch belangrijk is voor de toekomst of dienstverlening valt onder kwaliteit en wordt dus ondergebracht bij het proces Kwaliteitsmanagement. Kwaliteitsmanagement heeft dus als invalshoek fatsoenlijk/professioneel applicatie-beheer en kijkt meer naar de langere termijn. Alles wat afgesproken is met de klant/ opdrachtgeversorganisatie, ook wat niet valt onder fatsoenlijk applicatiebeheer, behoort tot Service Level. Service Level heeft dus een externe invalshoek. 5.3. Positie van ASL ten opzichte van ITIL. In IT beheer van februari 2003 de positie van ASL ten opzichte van ITIL in onderstaande figuur weergegeven. Daarbij is aangegeven dat vooral de processen in de beheerbol van ASL overeen komen met die van ITIL en Change de brug is tussen de ITIL- en ASL-wereld.

Organisatie SYSQA B.V. Pagina 14 van 20 De ASL-beheerprocessen hebben een duidelijk andere focus dan de gelijknamige ITIL-processen. De echte meerwaarde zit dan ook in de in 5.2 beschreven verschillen. Praktisch gezien is het aan te bevelen de ITIL en ASL-beheerproces-beschrijvingen te combineren, te bezien waar de specifieke bedrijfsbehoefte ligt en dan over te gaan tot implementatie van de relevante delen.

Organisatie SYSQA B.V. Pagina 15 van 20 6. Conclusie. Tijdens het onderzoek naar de verschillen tussen ITIL en ASL is opgevallen dat ASL op operationeel en tactisch niveau eigenlijk een kopie is van het R2C proces model. Niet zo verwonderlijk, omdat ASL afgeleid is van het R2C model. Het enige verschil is dat lifecycle management in ASL een strategisch proces is. Verder kan worden geconcludeerd dat: o ASL een welkome aanvulling van ITIL is. In het ITIL proces Release wordt wel rekening gehouden met software-onderhoud en het beheer van de daardoor ontstane verschillende versies, maar is er een grote afstand tussen technisch beheer en de voor het onderhoud verantwoordelijke instantie. Dankzij ASL wordt deze afstand verkleind, waardoor technisch beheer in een vroeg stadium betrokken wordt bij het onderhoudsproces. o Het ITIL proces Release gericht is op beheer van versies van Commercial Off the shelf (COTS) software, terwijl ASL vooral uitgaat van het gebruik van zelf (al dan niet in eigen beheer) ontwikkelde software. o Zowel ITIL als ASL zich beperken tot het geven van richtlijnen voor de inrichting van de processen. ITIL geeft wel voorbeelden van technieken of hulpmiddelen die kunnen worden gebruikt ter ondersteuning van de processen. ASL laat zich daar niet over uit. o ITIL aangeeft met welke procesrollen rekening moet worden gehouden, terwijl ASL daar gaan aandacht aan besteedt. o De organisatiekundige aspecten in ASL niet als zodanig aan de orde worden gesteld. ITIL besteedt daar wel aandacht aan. o In de literatuur is aangegeven dat de Configuration Database (CMDB) van ASL geen één-op-één relatie heeft met de ITIL CMDB, hetgeen betekent dat gebruik van de ITIL CMDB in ASL niet mogelijk is. Mijnsinziens is het wel degelijk mogelijk de voor ASL belangrijke objecten in de ITIL CMDB vast te leggen en daarover te rapporteren. De mate waarin dat mogelijk is, is afhankelijk van de gekozen detaillering en diepgang van de ITIL CMDB. Onlangs is het ITIL boek over Applicatiebeheer uitgebracht. Een vergelijking van de in dit boek behandelde theorie met de theorie van ASL was tijdens dit onderzoek dus niet mogelijk. Het is dus nog niet duidelijk wat de gevolgen zullen zijn voor ASL.

Organisatie SYSQA B.V. Pagina 16 van 20 Literatuurlijst. ASL Foundation: www.aslfoundation.org. Pols, Remko van der, ASL: een framework voor applicatiebeheer ; ten Hagen & Stam, Den Haag 2001. Pols, Remko van der, en Meijer-Veldman, Machteld E.E., ASL, de volgende generatie applicatiebeheer; IT Beheer Jaarboek 2001, ten Hagen & Stam, Den Haag 2001. De verschillen tussen ASL en ITIL in de beheerprocessen; www.asl-at-work.nl. Costeris, Dick, en Huijzer, Norbert, Hoe sluit ASL aan op ITIL? De kloof en de brug; IT beheer februari 2003.

Organisatie SYSQA B.V. Pagina 17 van 20 Bijlage 1: Het R2C proces model. Service Level Life Cycle Cost Mngt Config Mngt Capacity Mngt Incident / Problem Mngt Maintenance Conting. planning Avail. Mngt Change Mngt SC&D Impact analysis Construction Implementation Release planning Renewal Testing Design Quality Mngt Planning & Control

Organisatie SYSQA B.V. Pagina 18 van 20 Bijlage 2: Het nieuwe Functioneel Beheer Model. Leveranciers Ontwikkelingen Omgeving Ontwikkelingen Technologie Gebruikers- - organisatie Ontwikkelingen Organisatie v/d Informatievoorziening mation matie Coor- Coördination Infordinatie Lifecycle Portfolio Keten Inrichting Organisatie Informatievoorziening Ontwikkelingen Organisatie Inhoudelijke Toekomst Informatievoorziening Planning en control Kosten management Kwaliteits management Service level management Gebruikersondersteuning Beheer Bedrijfs- gegevens Wijzigingen beheer Specificeren Toetsen en Testen Beheer bedrijfs- zekerheid Gebruiksbeheer Release Overdracht Implemen- Onderhoud teren Procedures Functionaliteitenbeheer

Strategisch niveau Tactisch niveau Operationeel niveau Organisatie SYSQA B.V. Pagina 19 van 20 Bijlage 3: Verschillen per managementniveau. Onderstaande tabel geeft van beide methodieken per managementniveau de gedefinieerde processen aan. ITIL Service Support Set bestaande uit: De functie of organisatorische eenheid Service Desk; Incident ; Problem ; Change ; Configuration ; Release. IT Infrastructure : Network Service. Operations. of Local Processors. Computer Installation and Acceptance. Systems. Applications : Software Lifecycle Support Testing of IT Services. Service Delivery Set bestaande uit: Service Level ; Financial for IT Services; Capacity ; Availability ; Security ; IT Service Continuity. ASL Uitvoerende processen: Beheer: o Incident ; o Configuration ; o Capacity ; o Availability ; o Continuity. Onderhoud/vernieuwing: o Impactanalyse; o Ontwerp; o Realisatie; o Testen; o Implementatie. Verbindende processen: o Change ; o Software Control & Distribution. Sturende processen: Planning & Control; Cost ; Quality ; Service Level. IT Customer Relationship. Applications : Software Lifecycle Support; Testing of IT Services. Business Perspective Set: Business Continuity ; partnerships and outsourcing; surviving change; transformation of business practice through radical change. Managing Facilities. Managing Supplier Relationships. Managers Set: Quality for IT Services; IT Services Organisation; Planning and Control for IT Services. Beleidsbepalende/richtinggevende processen: Applications Cycle : o Account definition; o Market definition; o Service Delivery definition; o Skills definition; o Technology definition. Organization Cycle : o Customer organization strategy; o ICT development strategy; o Customer environment strategy; o ICT portfolio management; o Lifecycle management.