Proces afspraken na implementatie WaaS
versie:
1.0
datum:
April 2013
auteur: Beheer en Implementatie BNL
Versiebeheer Versie
Datum
Status
Auteurs
1.0
18-4-2013
Definitief
Pascal Navarro en Dennis Biesma
Nazorg en procesafspraken bij overdracht aan beheer
Opmerkingen
2
1.
Inleiding
Dit document is geschreven voor bibliotheken die geen onderdeel zijn van de G4. Het beschrijft de processen die van toepassing zijn vanaf het moment dat de bibliotheek is aangesloten op de WaaS. In grote lijnen geeft dit document informatie over hoe er omgegaan kan worden met wensen voor nieuwe functionaliteit, de aansluiting op de beheerorganisatie en de service die hieraan gekoppeld is. Verder bevat het document enkele handvaten die gebruikt kunnen worden om kennis te borgen en de veiligheid te verhogen.
Nazorg en procesafspraken bij overdracht aan beheer
3
2.
Inhoudsopgave
Inhoud Versiebeheer
2
1.
Inleiding
3
2.
Inhoudsopgave
4
3.
Vragen na de GoLive
5
Proces wensen voor nieuwe, of aangepaste functionaliteit
5
Kunnen bibliotheken ook RFC’s indienen? En wie draagt dan de kosten?
5
Incidenten, problems en service requests
5
3.1
3.1.1 3.2
3.2.1
Definities
5
3.2.2
Hoe verloopt het incidentproces?
5
3.2.3
Krijg ik informatie over incidenten die door anderen worden gemeld en
3.2.4 3.3
die ook van toepassing zijn op mijn functionaliteit/bibliotheek?
6
Een service request
6
De SLA
6
3.3.1
Inleiding
6
3.3.2
Krijg ik inzage in rapportages of de SLA wel wordt gehaald?
7
3.3.3
Wie neemt actie als de SLA niet wordt gehaald?
7
3.3.4
Hoe moet ik omgaan met een situatie waarin ik niet tevreden ben
3.4
3.4.1
met het naleven van de SLA?
7
PIM
7
Inleiding
7
3.5
Kennisborging
7
3.6
Training
7
3.7
Veiligheid
8
3.7.1
Gebruikersbeheer
8
3.7.2
Veiligheid van de software
8
3.7.3
Veiligheidsrisico’s melden
8
Releasemanagement
8
3.8
Nazorg en procesafspraken bij overdracht aan beheer
4
3.
Vragen na de GoLive
Nadat een Bibliotheek ‘live’ is in de WaaS is er een aantal onderwerpen waarmee een bibliotheek geconfronteerd kan worden. Hieronder een opsomming van enkele (mogelijk niet alle) vragen die kunnen voorkomen.
3.1
Proces wensen voor nieuwe, of aangepaste functionaliteit
Met enige regelmaat wordt er nieuwe functionaliteit toegevoegd aan de systemen waarmee je als bibliotheek aan de website werkt, of worden bestaande functionaliteiten aangepast. Dit zijn grotendeels wijzigingen naar aanleiding van wensen in de branche. Elke wens voor nieuwe, of aangepaste functionaliteit noemen wij een RFC, een Request for Change.
3.1.1
Kunnen bibliotheken ook RFC’s indienen? En wie draagt dan de kosten?
Ja, het is mogelijk om als bibliotheek RFC’s in te dienen. Dit kan via de servicedesk van de provinciale serviceorganisatie, waarbij je als bibliotheek bent aangesloten. Ingediende RFC’s van bibliotheken worden door het eerstelijns beheer in een systeem geplaatst dat Topdesk heet. Vanuit hier wordt de ingediende RFC door het tweedelijns beheer en de change coördinator voor de WaaS bij BNL verder opgepakt. De RFC wordt door hen omgezet in een wijzigingsaanvraag. De prioriteit hiervan wordt door het tweedelijnsbeheer afgestemd met het eerstelijnsbeheer. Het eerstelijnsbeheer kan de status van de wijzigingsaanvraag volgen in Topdesk. Ook zal de change coördinator terugkoppeling geven over de voortgang aan het eerstelijns beheer. Het eerstelijns beheer zorgt dan weer voor terugkoppeling aan de bibliotheek die de RFC heeft ingediend. Als het RFC’s zijn waar meer bibliotheken profijt van zullen hebben en die tevens passen binnen de opdrachtomschrijving van BNL, dan draagt BNL hiervan de kosten. Ook het ontwikkel- en testtraject zal onder leiding van BNL worden uitgevoerd. Ook is het mogelijk dat een bibliotheek een wens heeft die in strijd is met de opdrachtomschrijving van BNL. Een voorbeeld hiervan zou kunnen zijn: kunnen jullie een tijdschrijfsysteem ontwikkelen waarin wij de uren van onze interne medewerkers kunnen bijhouden? Hier kan BNL niet aan meewerken.
3.2
Incidenten, problems en service requests
3.2.1
Definities
Definitie conform ITIL1: • •
3.2.2
Een incident is een constatering van een niet of niet volledig werkende functionaliteit. Een service request is een verzoek tot ondersteuning, veelal doordat de gevraagde actie door beperkte rechten of onvoldoende kennis niet door de gebruiker zelf uitgevoerd kan worden.
Hoe verloopt het incidentproces?
Nadat je als bibliotheek bent aangesloten, is de servicedesk van de PSO hiervoor het eerste aanspreekpunt. Zie voor de contactgegevens het document PIM (Procedure Incident Management). Dit 1
http://nl.wikipedia.org/wiki/Information_Technology_Infrastructure_Library
Nazorg en procesafspraken bij overdracht aan beheer
5
document kunt u vinden op de website van BNL www.stichting.bibliotheek.nl, bij documenten, onder implementatie en beheer. Geef bij het melden van een incident zo duidelijk mogelijk aan: • • •
wat er fout gaat; hoe je tot de fout gekomen bent (belangrijk voor het kunnen reproduceren van het incident); wat de impact is van het incident: raakt het 1 persoon, meer personen of misschien zelfs de hele organisatie.
De servicedesk van de PSO is verantwoordelijk voor het in behandeling nemen van het incident en zal in eerste instantie proberen het incident zelf te verhelpen. Mocht dit niet lukken, dan is er een 2de en 3de-lijns beheerorganisatie die het incident in behandeling kan nemen, deze staan onder verantwoordelijkheid van BNL. De terugkoppeling over de verwachte doorlooptijd is de verantwoordelijkheid van de servicedesk van de PSO. De streef doorlooptijden staan vermeldt in de PIM. Zodra het incident verholpen is, neemt de servicedesk van de PSO contact op met de bibliotheek.
3.2.3
Krijg ik informatie over incidenten die door anderen worden gemeld en die ook van toepassing zijn op mijn functionaliteit/bibliotheek?
Ja, dergelijke verstoringen, die ook andere bibliotheken of alle bibliotheken treft, worden vermeld op het BNL Beheerportaal. Deze is toegankelijk voor alle 1e lijns servicedesks van de PSO’s, aldus (pro-) actief. Iedereen kan zich via een RSS-Feed abonneren op deze informatie: http://bnlbeheer.nl/home
3.2.4
Een service request
Een service request kan, net als een incident, worden ingeschoten bij de servicedesk van de PSO. Enkele voorbeelden van een service request: Voorbeeld 1: • •
Bibliotheek Valkenzande wil een G!DS openingstijden widget plaatsen, maar weet niet hoe dit moet. De Servicedesk verwijst naar de WIKI en spreekt indien nodig de hierin beschreven stappen door met de bibliotheek zodat zij dit zelf kunnen doen.
Voorbeeld 2: • •
Bibliotheek Valkenzande wil een nieuwe redacteur toegang geven tot de DCR. De collega die hiervoor de rechten heeft, is op vakantie en dus lukt dit hun niet zelf. De servicedesk zorgt voor het aanmaken van een account en geeft hierover terugkoppeling aan de bibliotheek.
3.3
De SLA
3.3.1
Inleiding
Een SLA (service level agreement) is een overeenkomst waarin afspraken staan tussen aanbieder en afnemer van een dienst of product. In de SLA is opgenomen wat voor ondersteuning je als bibliotheek mag verwachten.
Nazorg en procesafspraken bij overdracht aan beheer
6
De SLA geldt voor bibliotheken die zijn aangesloten op de infrastructuur van BNL en ook deze is te vinden op de website van BNL, onder documenten.
3.3.2
Krijg ik inzage in rapportages of de SLA wel wordt gehaald?
Ja, per kwartaal wordt de rapportage gepubliceerd op de website van BNL.
3.3.3
Wie neemt actie als de SLA niet wordt gehaald?
De verantwoordelijkheid voor het naleven van de in de SLA gemaakte afspraken ligt bij BNL. Mocht het voorkomen dat het toch niet mogelijk is geweest om te voldoen aan deze afspraken, dan zal BNL actie ondernemen en verbeteringen doorvoeren.
3.3.4
Hoe moet ik omgaan met een situatie waarin ik niet tevreden ben met het naleven van de SLA?
Hiervoor kan je contact opnemen met de Accountmanager van BNL.
3.4
PIM
3.4.1
Inleiding
De PIM (Procedure Incident Management) beschrijft wat een bibliotheek kan doen bij een storing of incident. De servicedesk neemt de melding aan en zorgt voor de verdere afhandeling. De PIM is te vinden op de website van BNL onder documenten.
3.5
Kennisborging
De bibliotheek is zelf verantwoordelijk voor het opbouwen en het overdragen van de kennis, die tijdens de implementatie van de WaaS is opgedaan. Als voorbeeld, er moet voorkomen worden dat er kennis verloren gaat bij een uitdiensttreding of langdurige ziekte. Dit gaat verder dan alleen de kennis van hoe het CMS gebruikt moet worden om de website te voorzien van nieuwe informatie. Denk bijvoorbeeld ook aan: waar leg je vast welke afdelingen verantwoordelijk zijn voor de afhandeling van formulieren op de website? Of waar kan een collega de openstaande wensen en/of incidenten terugvinden? Ook binnen BNL werken wij aan kwaliteitsborging, zowel tijdens het ontwerp-, ontwikkel-, bouw- en testtraject. Bij nieuwe of aangepaste functionaliteit streven wij ernaar om de gebruikersdocumentatie zo snel mogelijk bij te werken in de WIKI op www.bnlbeheer.nl/wiki. Hoewel de WIKI vooral ingaat op de WaaS (DCR, Drupal, Widgetstore), is het belangrijk om kennisborging op alle BNL-producten toe te passen.
3.6
Training
Voor bibliotheken die aansluiten op de WaaS is er een training beschikbaar. Deze training is eenmalig en is bedoeld om de bibliotheek van voldoende kennis te voorzien om de website zelfstandig op te kunnen bouwen. Voor een situatie waarin er nieuwe medewerkers komen binnen een bibliotheek ligt de verantwoordelijkheid voor het trainen bij de bibliotheek zelf.
Nazorg en procesafspraken bij overdracht aan beheer
7
3.7
Veiligheid
3.7.1
Gebruikersbeheer
Elke bibliotheek krijgt voor de website toegang tot de DCR, Drupal en de Widgetstore. Vanuit het implementatietraject worden de eerste gebruikers aangemaakt, vaak zijn dit ook de personen die betrokken zijn bij de training en de realisatie van de nieuwe website. Vanaf het moment dat een bibliotheek live gaat met een nieuwe website, is de bibliotheek zelf verantwoordelijk voor het beheer van deze gebruikers. Het is raadzaam om gebruikers te verwijderen die van functie veranderen of die uit dienst gaan. Enkele tips: • • •
• •
•
3.7.2
Controleer regelmatig wie er binnen de bibliotheek toegang heeft en of de toegang terecht is. Verwijder gebruikers die een andere rol krijgen of die uit dienst treden. Gebruik geen wachtwoorden die gemakkelijk te raden zijn en vermijd zoveel mogelijk woorden die in het woordenboek staan. Lange wachtwoorden en wachtwoorden waarin combinaties van hoofdletters, kleine letters en cijfers staan, zijn moeilijker te raden. Gebruik zakelijk niet dezelfde wachtwoorden als privé. Werk je op een publieke computer, vergeet niet uit te loggen en maak geen gebruik van een functie waarmee het wachtwoord kan worden onthouden. Een kwaadwillende gebruiker kan hiermee de hele website ontregelen. Maak geen gebruik van onbeveiligde publieke WIFI verbindingen. Het risico bestaat dat gebruikersnamen en wachtwoorden worden onderschept.
Veiligheid van de software
BNL doet haar uiterste best om veilige software op te leveren. Periodiek laten wij het systeem testen door een zeer ervaren beveiligingsbedrijf.
3.7.3
Veiligheidsrisico’s melden
Constateer je als bibliotheek een risico met betrekking tot de veiligheid, of signaleer je verdacht gedrag, dan kan dit via de servicedesk van de PSO worden doorgegeven. De Security Officer bij BNL zal deze melding in behandeling nemen.
3.8
Releasemanagement
Jaarlijks zijn er diverse releasemomenten. Tussen deze releases door wordt er adaptief onderhoud gepleegd. Met behulp van een release wordt er nieuwe functionaliteit beschikbaar of wordt bestaande functionaliteit aangepast. Wij streven ernaar om bibliotheken voorafgaande aan een release zo goed mogelijk te informeren over de geplande wijzigingen.
Nazorg en procesafspraken bij overdracht aan beheer
8
