Bedieningsprocedure

Richt je op de belangrijke zaken

Wij zien een bedieningsprocedure niet als een groot pakket documenten die alle hoekjes en gaatjes van een systeem in kaart brengt voor gebruikers en beheerders van elk niveau. Een meer praktische opvatting is dat je een aantal belangrijke kenmerken van een systeem vastlegt voor de doelgroep 'experts'. Het uitgangspunt zou moeten zijn dat als er sterkhouders uit je organisatie verdwijnen, je hun kennis hebt geborgd in bedieningsprocedures en dat een (externe) expert dit kan oppakken.

Visualiseer jezelf als die expert die naar binnen loopt en het volgende zou willen weten:

Algemeen

Hier zou een korte beschrijving van het systeem moeten staan, inclusief waar deze te vinden is in de test- en productieomgeving(en) in de vorm van een URL, executable of iets dergelijks. Ook zouden hier bijzonderheden gemeld kunnen worden.

Contacten

De belangrijke mensen die je als eerste gaat raadplegen:

• De interne contactpersonen voor het systeem, op technisch, functioneel en administratief gebied. Wie is de eindverantwoordelijke? Wie zijn de key users?
• De externe contacten. Hoe kunnen we deze bereiken? Hoe kunnen we support bereiken? Zijn er openingstijden waar we rekening mee moeten houden? Is de toegang tot de externe contacten beperkt (alleen administrators o.i.d)?

Installatie

Steeds meer organisatie nemen hun informatiesystemen en applicaties in de vorm van Software as a Service (SaaS) af. Dit hoeft dan niet meer geïnstalleerd te worden, alleen geconfigureerd. Maar mocht de organisatie aan zelfbouw doen, of nog traditioneel on premise software gebruiken, dan dient beschreven te zijn hoe dit geïnstalleerd moet worden. Of er dient verwezen te worden naar een beschrijving hiervan, want deze documentatie is vaak al gemaakt, met name door leveranciers. Mocht dit te generiek zijn, dan zou de bedieningsprocedure moeten aangeven welke keuzes de organisatie gemaakt heeft in de installatie.

Configuratie

Informatiesystemen en applicaties zijn vaak modulair opgezet en op vele manieren te gebruiken. Waar de ene organisatie fanatiek gebruik maakt van module X of optie Y, heeft de andere organisatie daar al een andere oplossing voor en gebruiken zij module Z juist veel meer. Het is voor een expert zeer belangrijk te weten hoe een organisatie een systeem gebruikt en hoe deze geconfigureerd is. Dit dient dan ook goed en gedetailleerd vastgelegd te worden in de bedieningsprocedure, bijvoorbeeld:

• Welke modules worden er gebruikt? Hoe? Wat wordt er niet gebruikt?
• Hoe ziet de rechtenstructuur eruit? Wie mag wat? Hoe log je in?
• Hoe lopen de workflows?
• Hoe wordt het systeem beheerd?
• Zit er maatwerk in het systeem, hoe ziet dit eruit?
• Wat zijn andere uitzonderingen?

Dit hoeft niet in extreem detail te zijn vastgelegd. In de ideale situatie beschrijft de bedieningsprocedure globaal de configuratie en wordt er verwezen naar documentatie waar deze in meer detail is beschreven.

Koppelingen en afhankelijkheden

Een systeem staat vrijwel nooit helemaal op zichzelf. Vaak komen er ergens gegevens in, worden deze verwerkt en komen er ergens weer gegevens uit. Het is belangrijk om de weten hoe het systeem gepositioneerd is in de totale omgeving.

Het handigste en mooiste is om dit grafisch in beeld te brengen. Een bedieningsprocedure zou daarom een plaat moeten bevatten waarin te zien is waar het systeem afhankelijk van is.

In de beschrijving van de plaat zou dan het volgende opgenomen moeten zijn (voorbeelden):

Alle koppelingen van/naar het systeem en de eigenaar hiervan

IN: Ophalen/importeren gegevens

BINNEN: Verwerken gegevens

UIT: Versturen/exporteren gegevens

Back-up en recovery

Zoals ISO27001 eist, zullen de back-up en restoreprocedures is orde moeten zijn. In deze paragraaf moet staan beschreven hoe dit voor dit systeem specifiek is ingeregeld, zoals:

• Wanneer vinden de back-ups plaats?
• Hoe vaak?
• Volledig/Incrementeel?
• Onder wiens verantwoordelijkheid?
• Hoe lang worden de back-ups bewaard?
• Wat is het maximale dataverlies?

Als er een generiek back-upbeleid is, kan hiernaar worden verwezen. Eventueel op onderdelen.

Als het systeem als SaaS draait, is het zaak dat het back-upbeleid van de leverancier wordt opgevraagd. Vaak staat deze in een Service Level Agreement, hier kan naar verwezen worden. Eventuele voorwaarden voor een restore moeten ook zijn beschreven, bijvoorbeeld hoe je deze bij de leverancier kan worden aangevraagd, door wie (intern) en bij wie (extern)?

Planning

In het onderdeel Planning kan een veelheid aan informatie staan. Bij on premise systemen of zelfbouw zou minstens de road map en releasekalender vermeld moeten zijn. Ook zou de bedieningsprocedure het reguliere onderhoudsschema met eventuele bijpassende down time moeten bevatten.

Bij SaaS-systemen is het belangrijk om te weten wanneer er onderhoud plaatsvindt en wat de eventuele impact daarvan is op de beschikbaarheid van een systeem. Vaak zie je dat er met een vaste frequentie kleine updates worden uitgebracht zonder down time en grotere updates met een iets mindere frequentie die wel een downtime met zich mee kunnen brengen.

In Planning kun je ook andere onderwerpen tegenkomen:

• Wanneer vinden imports en exports plaats? Dit kan ook staan in het stuk koppelingen en afhankelijkheden
• Wat zijn de verwachte piektijden?
• Planning van scripts

Foutafhandeling

Maak hier een onderscheid tussen fouten/situaties die al bekend zijn en fouten/situaties die nieuw zijn.

Bij bekende fouten, vaak geaccepteerde excepties, beschrijf je per fout hoe hier mee omgegaan wordt. Een beschrijving van de workaround dus. Als hierbij specifieke personen, functies of afdelingen bij betrokken zijn, neem dat dan mee in de beschrijving. Hetzelfde geldt voor zaken als specifieke systemen of specifieke scripts die de workaround ondersteunen.

Bij nieuwe fouten beschrijf je hoe deze beschreven, geprioriteerd en gemeld moeten worden en wie daar verantwoordelijk voor is. Als je daar een systeem voor hebt, bijvoorbeeld een service management systeem als Topdesk, dan verwijs je daar naar.

Bij on premise en SaaS-oplossingen liggen de afspraken rondom de melding en afhandeling van fouten vaak vast in een SLA, zie hiervoor de paragraaf 'SLA-afspraken'

SLA-afspraken

Het is niet de bedoeling om de copy- en pasteversie van de SLA terug te zien in de bedieningsprocedure. Daar kan naar verwezen worden. Maar in dit onderdeel zou je minstens het volgende wel moeten kunnen terugvinden:

• Gegarandeerde uptime
• Hoe kunnen storingen door worden gegeven?
• Wat dient een storingsmelding te bevatten?
• Hoe worden de ernst en prioriteit van een storing bepaald?
• Wat zijn de gerelateerde reactie- en oplostijden?

Het kan zo zijn dat je geen SLA-afspraken met een leverancier hebt of hebt kunnen maken. Vraag in dat geval de leverancier uit op bovengenoemde onderwerpen en noteer de antwoorden in de bedieningsprocedure.

Escalaties

Op het moment dat een bedrijfskritisch systeem logisch en/of technisch niet meer functioneert voor een grotere groep gebruikers en het issue wordt niet binnen de afgesproken SLA-termijn opgelost, dient de escalatieprocedure te worden gevolgd. Deze ligt vast in de bedieningsprocedure of er kan verwezen worden naar een generieke escalatieprocedure.

Het escalatiepad dient ook vastgesteld te zijn voor het systeem wat in de bedieningsprocedure wordt beschreven, bijvoorbeeld gebruiker > product owner > management > directie.

Logging en monitoring

Ook hier is er wel een onderscheid te onderkennen tussen SaaS-oplossingen en on premise systemen.

SaaS

Bij SaaS ligt de verantwoordelijkheid voor loggen en monitoren meestal bij de leverancier en kan er weinig invloed uitgeoefend worden op de manier waarop deze het implementeert. Het is vaak roeien met de riemen die je hebt. Overigens is dit wellicht wel een selectiecriterium bij het selecteren van leveranciers en hun systemen, maar dat is een ander onderwerp.

In de bedieningsprocedure zouden alle beschikbare loggingsmogelijkheden beschreven moeten zijn, inclusief de mogelijke controles daarop en de procedures daaromheen.

Qua monitoring komt het meestal neer op het reactief signaleren van issues in performance, data-integriteit of andere belangrijke verstoringen. De bedieningsprocedure zou moeten beschrijven hoe deze meldingen verzameld en beoordeeld kunnen worden en hoe ze zo snel en efficiënt mogelijk bij de leverancier terecht kunnen komen.

On premise en zelfbouw

De verantwoordelijkheid voor loggen en monitoren ligt nu direct bij jezelf. Waarschijnlijk heb je dit al op orde doordat je moet voldoen aan A.12 - Beveiliging operatie en dan met name A.12.1.3 Capaciteitsbeheer en de artikelen die bij A.12.4.x horen. Neem de belangrijkste elementen op in de bedieningsprocedure en verwijs verder naar de documentatie die je hebt opgesteld naar aanleiding van A.12.1.3 en A.12.4.x.

Vorm van de bedieningsprocedure

Het is je wellicht opgevallen dat er in een bedieningsprocedure vaak kan worden verwezen naar andere documenten. Dat heeft invloed op de vorm waarin je een bedieningsprocedure zou willen hebben.

Heb je een redelijk op zichzelf staand document zonder al te veel verwijzingen, die ook nog 'ns statisch zijn, dan kun je prima een 'klassiek' document maken en onderhouden. Merk je echter dat de informatie en/of de verwijzingen niet zo statisch zijn, overweeg dan eens modernere vormen als een wiki, een contentmanagementsysteem of een kwaliteitsmanagementsysteem als Normity. Vaak is hierin de onderlinge samenhang tussen onderwerpen en documenten makkelijker te beheren en te onderhouden.

Tenslotte

Zoals je in dit stuk kunt lezen, kan de bedieningsprocedure bij iedere organisatie er verschillend uit zien. Er zijn behoorlijk wat variabelen die de inhoud van de procedure kunnen beïnvloeden. Het meest praktische is het om de onderwerpen op het niveau van een expert te beschrijven en zoveel mogelijk te verwijzen naar bestaand materiaal. Op die manier wordt een bedieningsprocedure behapbaar voor iedere organisatie.