SLA Stappenplan

Na de realisatie van een website of webapplicatie moet het beheer van bijbehorende applicaties en infrastructuur worden opgezet. Hiervoor dient op basis van de specifieke eisen en wensen van de klant een formele overeenkomst (Service Level Agreement) ten aanzien van het beheer worden afgesloten met Drecomm.

Dit document beschrijft de benodigde stappen om te komen tot een SLA.

Voor het opzetten van een Service Level Agreement voor het beheer van de applicaties en infrastructuur zijn onderstaande onderdelen van belang:

• Service definitie:
  De service definitie beschrijft in algemene zin welke diensten de klant wenst uit te besteden. Dit is een functionele beschrijving van de service onafhankelijk van de technische implementatie.
  
• Business eisen/wensen:
  De eisen en wensen die de business van de klant stelt aan de service dienen in concrete meetbare (SMART) begrippen worden vastgelegd. Hierbij moet gedacht worden aan eisen ten aanzien van beschikbaarheid en onderhoudbaarheid van de service en vereist dus een vertaalslag van de business doelstellingen.
  
• Technische eisen/wensen:
  Tijdens het ontwerp en bouw van de website zijn keuzes gemaakt ten aanzien van de infrastructuur die gebruikt gaat worden voor de website. Deze keuzes stellen (technische) eisen aan de service. Bovendien kan het zijn dat de klant’s  eigen IT-afdeling specifieke eisen en wensen heeft ten aanzien van de service. Hierbij kan gedacht worden aan het voldoen aan technische standaarden en voorkeur voor hard- en softwareleveranciers i.v.m. bestaande licenties en contracten.
  
• Opstellen SLA:
  Het SLA bevat een beschrijving van de service en onder welke voorwaarden (inclusief kosten) deze service geleverd gaat worden.
  
• Transitieplan:
  Het transitieplan is gericht op de overdracht van de website van de projectorganisatie naar de lijnorganisatie en de door de klant geselecteerde partij die het beheer gaat uitvoeren. Onderdeel van deze transitie zijn enerzijds borging van procedures en verantwoordelijkheden in de lijnorganisatie van de klant en de leverancier. Anderzijds is het de technische overdracht van de applicaties en bijbehorende infrastructuur van de projectorganisatie naar de leverancier. Hierbij is nog het onderscheid te maken tussen een leverancier die de applicaties inclusief fysieke infrastructuur overneemt en een leverancier die de applicaties overzet naar zijn eigen infrastructuur.

De service definitie is een beschrijving van de beheertaken die voor de klant uitgevoerd moeten gaan worden. De service definitie zal moeten bestaan uit een afbakening van de service en een beschrijving van de diensten die onderdeel zijn van de service.

2.1    Afbakening
De afbakening van de service kan het best beschreven worden in termen van de applicaties en infrastructuur die binnen het beheer valt. De applicaties en infrastructuur kunnen verdeeld zijn over meerdere omgevingen, bijv. Ontwikkeling, Test, Acceptatie, Productie (OTAP). Per omgeving zal moeten worden gespecificeerd welke delen binnen het beheercontract moeten gaan vallen. Hierbij moet gedacht worden aan:

• Programmatuur en systeemconfiguraties
• Software/hardware licenties
• Computer systemen (bijv. PC’s, servers)
• Netwerkinfrastructuur
• Randapparatuur (bijv. printers)
• Technische documentatie

Hierbij is ook van belang om te specificeren waar de overdrachtspunten liggen tussen de infrastructuur die in beheer is bij de klant en de infrastructuur die uitbesteed gaat worden. Het is hierbij belangrijk om vast te stellen welke onderdelen van de website niet onder het beheercontract gaan vallen.

2.2    Omschrijving van diensten
De service die wordt uitbesteed kan worden onderverdeeld in diensten. Per dienst moet worden gespecificeerd wat verwacht wordt van de leverancier. Een mogelijke indeling van diensten, die bij het beheer van een IT infrastructuur hoort is:

• Preventief onderhoud
  Deze dienst is gericht op het voorkomen van problemen. Hierbij moet gedacht worden aan het tijdig installeren van nieuwe hardware/software, het bijhouden van systeem documentatie, het uitvoeren van backup procedures, etc.
  
  
• Correctief onderhoud
  Deze dienst is gericht op het oplossen van problemen die zijn ontstaan.
  
  
• Adaptief onderhoud
  Deze dienst is gericht op het uitvoeren van wijzigingen.
  
  
• Overleg en rapportage
  Deze dienst richt zich op de rapportages die worden verwacht als onderdeel van de service (bijv. rapportages over het gebruik van de website) en overleggen waaraan de leverancier deelneemt.
  
  
• Ondersteuning
  Deze dienst richt zich op de aanvullende ondersteuning die verwacht wordt. Hierbij kan gedacht worden aan een helpdeskfunctie.

Voorafgaand aan het definitief vaststellen van eisen en wensen zal de business zich goed bewust moeten zijn wat de website inhoudt en welke waarde wordt gehecht aan een goed functionerende website. Dit is van belang om per eis/wens een waardeoordeel te kunnen geven (bijvoorbeeld: gewenst/zeer gewenst/eis), zodat bij de leverancierskeuze en het opstellen van het SLA hiermee rekening kan worden gehouden.
Bovendien is het van belang om naast vertegenwoordigers uit de business ook technisch en/of inhoudelijk advies te betrekken. Dit is van belang om business vertegenwoordigers te wijzen op eventuele beperkingen/mogelijkheden vanuit technisch oogpunt en een indicatie van de impact op kosten die een eis/wens met zich mee brengt.
De eisen/wensen ten aanzien van service/diensten vanuit de business kunnen worden onderverdeeld in de volgende onderdelen:

1. Beschikbaarheid
2. Reactiesnelheden
3. Informatiebeveiliging
4. Aanpasbaarheid
5. Capaciteit
6. Rapportages

Deze zes onderdelen zijn slechts een deel van het geheel aan eisen dat in een SLA moet worden vastgelegd (Zie hoofdstuk 6). Deze zes onderdelen zijn echter het meest direct van specifieke business eisen/wensen af te leiden. In de volgende paragrafen wordt per onderdeel een toelichting gegeven.

3.1    Beschikbaarheid
De beschikbaarheid van een service is belangrijker naarmate de bedrijfsprocessen afhankelijker zijn van de service. Bepaald zal moeten worden wat de impact is van het niet beschikbaar zijn van de gehele service of onderdelen ervan.
Om de eisen en wensen t.a.v. beschikbaarheid vast te stellen moeten de volgende stappen worden doorlopen:

1. Bepaal op basis van de Service Definitie voor welke onderdelen een beschikbaarheids eis/wens van toepassing is.
2. Bepaal per onderdeel uit stap 1 welke business processen in welke mate afhankelijk zijn van de beschikbaarheid en wat de impact is indien het service onderdeel niet beschikbaar is.
3. Bepaal per onderdeel de gewenste beschikbaarheid aan de hand van de volgende criteria:
   
   • Wanneer moet de service beschikbaar zijn?
     Bijvoorbeeld: ma t/m vr tussen 9.00 en 17.00
   • Hoe vaak mag de service uitvallen gedurende een tijdsperiode?
     Bijvoorbeeld: maximaal 2 x per week
   • Hoe lang mag de service achtereen niet beschikbaar zijn?
     Bijvoorbeeld: maximaal 1 uur
   • Wat is het gewenste  beschikbaarheids percentage?
     Bijvoorbeeld: 95% (=38 uur in dit voorbeeld)
   • Hoeveel gegevens mogen verloren gaan in geval van een calamiteit?
     Bijvoorbeeld: Maximaal 1 uur aan gegevensverlies
4. Stel eventueel een financiële compensatie vast die benodigd is in het geval niet aan de gestelde beschikbaarheideisen wordt voldaan.

3.2    Prestaties
De prestaties van een IT service kunnen het best beoordeeld worden op reactiesnelheden. Reactiesnelheden kunnen hierbij verdeeld worden in de reactiesnelheden van diensten die onderdeel zijn van de service (bijv. een helpdesk) en reactiesnelheden van de IT systemen die onder de service vallen. Vooral de reactiesnelheid van IT systemen is van belang, omdat deze in grote mate bepaalt hoe goed gebruikers in staat zijn met het systeem hun dagelijks werk uit te voeren. Reactietraagheid wekt irritatie op en levert bovendien verlies van productietijd op.

Om de eisen en wensen t.a.v. reactiesnelheden vast te stellen moeten de volgende stappen worden doorlopen:

1. Bepaal een set typische systeeminteracties en specificeer een typische reactiesnelheid. Hierbij is het ook van belang om onderscheid te maken tussen groepen van gebruikers. Publicisten van content zullen namelijk op een andere wijze gebruik maken van de website en andere eisen stellen aan reactiesnelheden, dan bezoekers van de website.
   Voorbeelden van typische systeeminteracties zijn:
   
   • Navigeren binnen een website
   • Zoeken naar content binnen een website (uitvoeren van een query)
   • Downloaden van content
   • Uploaden van content
2. Bepaal een set typische servicedesk interacties en specificeer een typische reactiesnelheid. Voorbeelden van typische servicedesk interacties zijn:
   
   • Reactiesnelheid waarmee een vraag, klacht of probleem wordt afgehandeld
   • Reactiesnelheid op een verzoek om gegevens terug te zetten (recovery time)
   • Oplostijd van problemen/incidenten/wijzigingen per prioriteitsniveau
3. Bepaal per typische interactie uit stap 1 en 2 welke reactiesnelheid minimaal verwacht wordt. Afhankelijk van het type interactie moet de reactiesnelheid worden gespecificeerd (SMART).
   Bijvoorbeeld:
   
   • Navigeren binnen een website
     ->Bijvoorbeeld: maximale responsetijd 100  milliseconden
   • Zoeken naar contant binnen een website (uitvoeren van een query)
     -> Bijvoorbeeld: maximale responsetijd 1 seconde.
   • Downloaden van content
     -> Bijvoorbeeld: minimale downloadsnelheid 300Kb per seconde
   • Uploaden van content
     -> Bijvoorbeeld: minimale uploadsnelheid 300Kb per seconde
   • Reactiesnelheid van een helpdesk
     -> Bijvoorbeeld: Binnen 1 uur antwoord op een vraag.
4. Stel per gebruikersinteractie eventueel een financiële compensatie vast die benodigd is in het geval niet aan de gestelde reactiesnelheden wordt voldaan.
   Bij het uitvoeren van bovenstaand stappenplan gelden de volgende aanbevelingen:
   
   • Prestatiemeten van IT systemen is geen eenvoudige taak. Splits de prestatie-eisen op in verschillende lagen van de infrastructuur zoals netwerkprestatie, applicatieprestatie, presentatielaag prestatie. Meet op verschillende lagen om eventuele bottlenecks te bepalen en op welke prestaties de diensverlener aan te spreken is.
   • Het is van belang dat bottlenecks nooit gevormd worden door de klant eigen infrastructuur, waardoor een leverancier niet op zijn verantwoordelijkheid aangesproken zou kunnen worden.
   • Meet wat momenteel de prestaties van het systeem zijn en gebruik deze als handvatten.
   • Maak meetbare afspraken over de responstijd van service desks en wanneer aanvragen afgehandeld dienen te zijn.

3.3    Informatiebeveiliging
Dataverlies, ongewenste aanpassingen aan data en data die bekeken wordt door niet geautoriseerde personen zijn risico’s die met behulp van informatiebeveiliging afgedekt moeten worden. Per type informatie in de website zal moeten worden bepaald in hoeverre de informatie vrij toegankelijk en te wijzigen moet zijn, en wat de gevolgen van informatieverlies zijn.
De eisen en wensen t.a.v. informatiebeveiliging kunnen worden verdeeld in de volgende twee onderdelen:

1. Betrouwbaarheid
   De mate waarin de informatie op de website zonder fouten is (juist, volledig en tijdig). Voor dit onderdeel zullen de volgende eisen/wensen moeten worden bepaald:
   
   • Maximale tijdsperiode dat gegevens verloren kunnen gaan
     (dit is gelijk aan de maximale tijd tussen twee back-ups)
   • Archiveringstermijn van gegevens
     (bepaald hoe lang backups bewaard moeten worden)
2. Vertrouwelijkheid
   De mate waarin toegang tot informatie in de website vrij toegankelijk en muteerbaar is. Bepaald moet worden in hoeverre informatie in de website alleen bedoeld is voor een specifieke groep gebruikers (bijv. de de klant medewerkers) en in hoeverre publicisten van websites informatie uit de website vrij kunnen gebruiken en eventueel bewerken.

3.4    Aanpasbaarheid
Organisaties zijn over het algemeen dynamisch van aard en aanpassingen aan de IT dienen vaak op een korte termijn uitgevoerd te worden. De dienstverlener dient in staat te zijn om aan de vraag van de veranderende organisatie te voldoen.

Om de eisen/wensen t.a.v. aanpasbaarheid vast te stellen, zal bepaald moeten worden op welke termijn veranderingen verwacht worden en wat de impact hiervan is op de service:

1. Bepaal welke veranderingen de klant op de korte en lange termijn verwacht, die van invloed zouden kunnen zijn op de wensen/eisen ten aanzien van de website. Hierbij kan gedacht worden aan nieuwe partijen/samenwerkingsverbanden waarvoor aansluiting op de website benodigd is, nieuwe wet en regelgeving, nieuwe functionele wensen n.a.v. wijzigingen in de interne organisatie van de klant.
2. Bepaal per verwachte verandering uit stap 1 op welke termijn deze verandering verwacht kan worden, wat de kans is dat deze verandering plaats vindt en wat de impact is op:
   
   • Applicaties (Bijv. benodigd aantal licenties, nieuwe applicaties i.v.m. met nieuwe functionaliteit)
   • Infrastructuur (Bijv. opslagcapaciteit, systeemprestaties)
   • Service organisatie (Bijv. capaciteit helpdesk)

NB: Stap 2 zal in samenwerking met technisch inhoudelijk advies uitgevoerd moeten worden.

3.5    Capaciteit
Er zal een inschatting gemaakt moeten worden t.a.v. de maximale belasting van de service, die mogelijk moet zijn zonder de beschikbaarheid van de service en de prestaties in het geding komen. De capaciteitseis kan het best gespecificeerd worden door per type gebruiker (bezoeker, auteur, publicist) de volgende criteria vast te stellen:

• Systeem: Min. en max. aantal gebruikers dat tegelijk van het portaal gebruik maakt
• Systeem: Min. en max. belasting per gebruiker op basis van typische gebruikersinteracties met de website
• Systeem: Min. opslag capaciteit
• Helpdesk: Max. aantal vragen per uur of per dag
• Wijzigingen: Max. aantal wijzigingsverzoeken per periode

3.6    Rapportages
Vanuit de business gezien is het van belang om te kunnen bepalen in hoeverre doelstellingen gehaald worden en of bijsturing noodzakelijk is. Hiervoor zijn rapportages nodig over de kwaliteit van dienstverlening en rapportages over het gebruik van de website. De rapportage eisen/wensen kunnen als volgt bepaald worden: 

1. Bepaal de precieze business doelstellingen die de klant met de website voor oegen heeft
2. Bepaal d.m.v. welke rapportages het behalen van de doelstellingen uit stap 1, gemeten kan worden. Hierbij kan bijvoorbeeld gedacht worden aan de volgende rapportages:
   
   • Aantal bezoekers per dag per website;
   • Aantal bezoekers per dag per content type;
   • Aantal downloads/uploads per dag;
   • Klikpaden, oftewel hoe navigeert een gebruiker door de website;
   • Verblijftijden, oftewel hoe lang verblijft een gebruiker op webpagina’s die onderdeel zijn van de website;
   • Aantal nieuw toegevoegde content items per type per week;
   • Percentage content types dat gepubliceerd wordt op websites, oftewel het percentage content dat daadwerkelijk gebruikt wordt;
   • Percentage content dat gepubliceerd wordt op een website anders dan de website van de content aanleverende partij, oftwel het percentage content dat daadwerkelijk gedeeld wordt tussen websites;
   • Etc.

Naast eisen/wensen vanuit de business, zal de IT-afdeling van de klant technische eisen/wensen hebben. Deze eisen/wensen zullen enerzijds voortkomen uit de procedures en werkinstructies waarop de service moet aansluiten, anderzijds zal de infrastructuur die binnen de service valt aan moeten sluiten op de overige IT infrastructuur van de klant. Dit laatste punt speelt vooral als de website wordt gehost op locatie bij de klant.
Het bepalen van de technische eisen/wensen kunnen worden onderverdeeld in de volgende onderdelen:

1. Vaststellen wat de eisen zijn ten aanzien beheerprocedures en bijbehorende documentatie (incident management, change management, etc.).
2. Vaststellen van eisen vanuit het IT beleid dat binnen de klant wordt gehanteerd. Hierbij kan gedacht worden aan specifiek beleid op het gebied van beveiliging.
3. Vaststellen wat de eisen zijn ten aanzien van technische standaarden die binnen de klant gehanteerd worden.

Als aanvulling op het laatste punt is het van belang om na te gaan bij de leverancierskeuze of leveranciers gebruik maken van standaarden en producten die algemeen in de markt worden gebruikt. De praktijk leert dat makkelijker expertise voor een standaard product te vinden is. Bovendien verhogen standaarden het probleemloos samenwerken van producten.

In de volgende paragrafen wordt toegelicht uit welke onderdelen een Service Level Agreement kan  bestaan en hoe deze onderdelen ingevuld kunnen worden voor de website van de klant.

5.1    Beschrijving van de dienstverlening
Dit onderdeel van de SLA dient een functionele beschrijving van de te leveren service en de grenzen van deze service te bevatten. De Service Definitie uit hoofdstuk 2 kan als basis dienen voor deze beschrijving.

Naast de onderdelen uit de Service Definitie moeten concrete afspraken t.a.v. de volgende onderdelen in deze beschrijving terugkomen:

• Gebruikte applicaties t.b.v. de service
• Meest voorkomende gebruikersinteracties
• Overzicht van gebruikers en/of gebruikersgroepen, eventueel met  een verwijzing naar de betreffende bijlage
• Overige punten, welke van belang zijn voor het algemene begrip van de dienst en voor zover deze niet bij één van de andere bepalingen beschreven worden

5.2    Beschikbaarheid
Dit gedeelte kan gebaseerd worden op de specifieke eisen en wensen die vanuit de business zijn gesteld aan de beschikbaarheid (zie paragraaf 3.1) en de specifieke afspraken die worden gemaakt met de leverancier.

5.3    Performance/prestaties
Dit gedeelte kan gebaseerd worden op de specifieke eisen en wensen die vanuit de business zijn gesteld aan de prestaties (zie paragraaf 3.2) en de specifieke afspraken die worden gemaakt met de leverancier.

5.4    Informatiebeveiliging
Dit gedeelte kan gebaseerd worden op de specifieke eisen en wensen die vanuit de business zijn gesteld aan de informatiebeveiliging (zie paragraaf 3.3) en de specifieke afspraken die worden gemaakt met de leverancier.

5.5    Aanpasbaarheid
Dit gedeelte kan gebaseerd worden op de specifieke eisen en wensen die vanuit de business zijn gesteld aan de aanpasbaarheid (zie paragraaf 3.4) en de specifieke afspraken die worden gemaakt met de leverancier. Voor het maken van afspraken met de leverancier gelden de volgende aandachtspunten:

1. Maak afspraken over een basispakket van diensten die momenteel, en in de nabije toekomst nodig zijn.
2. Maak afspraken met de leverancier over additioneel af te nemen diensten en stem de financiën hierop af.
3. De leverancier dient gebruik te maken van een gestructureerd change management proces.
4. De dienstverlener dient de IT-infrastructuur te documenteren en dit over te dragen bij beëindiging van de overeenkomst.

5.6    Capaciteit
Dit gedeelte kan gebaseerd worden op de specifieke eisen en wensen die vanuit de business zijn gesteld aan de capaciteit (zie paragraaf 3.5) en de specifieke afspraken die worden gemaakt met de leverancier.

NB: De capaciteit bepaald enerzijds vermogens van de informatievoorziening waarop de afnemer kan rekenen en anderzijds de randvoorwaarden waarbinnen de SLA geldig is.

5.7    Gebruikersondersteuning en -opleiding
Om de mogelijkheden van een IT systeem optimaal te kunnen benutten, moeten afspraken gemaakt worden t.a.v. gebruikersondersteuning en –opleiding. Afspraken zullen moeten worden gemaakt over de volgende onderdelen:

• Helpdeskfunctie
  Hierbij moet gedacht worden aan afspraken over:
  
  • Bereikbaarheid helpdesk (bijv. via telefoon, webform, e-mail)
  • Reactietijd helpdesk
  • Procedures voor het doorgeven van problemen en verzoeken aan de helpdesk
  • Maximaal aantal vragen per tijdseenheid aan de helpdesk
• Beschikbaarheid en procedures voor het bijwerken van handleidingen
• Beschikbaarheid van opleidingen

5.8    Rapportages
Dit gedeelte kan gebaseerd worden op de specifieke eisen en wensen die vanuit de business zijn gesteld aan de rapportages (zie paragraaf 3.6) en aangevuld met de mate waarin gegevens betreffende het kwaliteits- en kwantiteitsniveau van de geleverde dienst gemeten, vastgelegd en verspreid moeten worden.

Afspraken dienen gemaakt te worden t.a.v. de volgende onderdelen:
Overige meetgegevens waarover gerapporteerd dient te worden in verband met de gestelde business eisen/wensen (zie paragraaf 3.6).

• Meetgegevens benodigd voor het meten van service level afspraken zoals gespecificeerd in de SLA.
• Meet- en berekeningsmethoden.
• Frequentie van rapportages en de periode waarop ze betrekking hebben.
• Maximale oplevertijd rapportage na het aflopen van de betreffende periode.
• Opsomming van personen waaraan rapportages verstrekt worden.
• Bewaartijd van de verschillende rapportages.
• Mogelijkheid tot ad-hoc rapportages

5.9    Onderhoud
Dit onderdeel bevat nadere afspraken over de wijze waarop correctief, preventief en adaptief onderhoud worden ingevuld. Hieronder volgt een opsomming van specifieke afspraken waaraan gedacht moet worden per type onderhoud:

Correctief onderhoud:

• Toewijzing urgentiecodes per type storing
• Toewijzing escalatieniveaus aan oplossende instanties, bijvoorbeeld:
  
  • Escalatieniveau 1: behandeling op “helpdesk”-niveau
  • Escalatieniveau 2: behandeling op “technisch/specialistisch”-niveau door activeren problem-management
  • Escalatieniveau 3: behandeling op “toeleveranciers”-niveau
• Maximale reactietijd na probleemmelding van de helpdesk per urgentiecode
• Maximale oplos-/storingstijd na probleemmelding per urgentiecode
• Escalatie procedure, indien maximale oplostijden worden overschreden
• Afspraken ten aanzien van release management (Ontwikkeling – Test – Acceptatie – Productie)
• Preventief onderhoud:
• Herziening documentatie als gevolg van preventief onderhoud
• Mate van overleg over het tijdstip waarop het onderhoud wordt uitgevoerd
• Frequentie voor het uitvoeren van onderhoud
• Voorkeurstijdstippen voor het uitvoeren van onderhoud
• Maximaal aantal voorkomens en maximale periode van onderhoud per voorkomen
• Afspraken ten aanzien van release management (Ontwikkeling – Test – Acceptatie – Productie)
• Adaptief  onderhoud:
• Maximale afhandelingstijd van een wijziging
• Mate van overleg over het tijdstip waarop het onderhoud wordt uitgevoerd
• Frequentie voor het uitvoeren van onderhoud
• Voorkeurstijdstippen voor het uitvoeren van onderhoud
• Wijzigingsprocedure, waaronder aanmeldingsperiode
• Maximaal aantal voorkomens en maximale periode van onderhoud per voorkomen
• Afspraken ten aanzien van release management (Ontwikkeling – Test – Acceptatie – Productie)

5.10    Financiën
Dit gedeelte van de SLA bevat een specificatie van vergoedingen voor het leveren van de service en dient de volgende onderdelen te bevatten:

• Tariferingmodel
• Tarieven bij verschillende opties
• Wijze van facturering
• Wijze van betaling
• Verwijzing naar het Dossier Financiële Afspraken (DFA)