IT

Documentatie functioneel applicatiebeheer

Een informatiesysteem kent vele aspecten en vormt hierdoor een complex geheel. Deze mate van complexiteit betekent dat niemand dit geheel in zijn totaliteit nog kan overzien.

Framework

1. Inleiding

Een informatiesysteem kent vele aspecten en vormt hierdoor een complex geheel. Deze mate van complexiteit betekent dat niemand dit geheel in zijn totaliteit nog kan overzien. Meerdere mensen bezitten kennis van bepaalde onderdelen van een informatiesysteem, doordat zij betrokken waren bij het verstrekken van de opdracht die leidde tot de systeemontwikkeling. Anderen hebben deze kennis omdat zij betrokken zijn (geweest) bij de systeembouw, invoering en/of het gebruik en beheer van dit informatiesysteem. Bepaalde kennis over het informatiesysteem neemt af naarmate de tijd voortschrijdt. Ook gaat kennis over het informatiesysteem verloren omdat mensen de organisatie verlaten.
Teneinde een informatiesysteem optimaal te gebruiken en beheren is het noodzakelijk dit informatiesysteem van haver tot gort te kennen. Daarom moet dus vanaf het prille begin alle kennis gestructureerd worden vastgelegd, zodat deze niet verloren gaat. Het meest gebruikte hulpmiddel om deze kennis gestructureerd vast te leggen en gedoseerd te verspreiden is documentatie. (Zie ook ‘Operationele processen functioneel applicatiebeheer’.)
In dit artikel meer over het gestructureerd opzetten van de documentatie van een informatiesysteem. Wij trachten hierin volledig te zijn, zodat u alleen hoeft te schrappen. Uitgangspunt is het maatwerksysteem. Als het gaat om een standaardpakket, dan kunt u hierin fors schrappen.

1.1 De functie van documentatie

Documentatie is het informatiesysteem ten behoeve van de informatievoorziening. Zonder documentatie is een efficiënte en effectieve bedrijfsvoering niet realiseerbaar. Alleen een goede documentatie kan continuïteit en overdraagbaarheid inzake het informatiesysteem garanderen. Hierbij is het van belang onderscheid te maken naar documentatiesoorten. Het doel waarvoor de documentatie wordt aangewend (hardware onderhoud, softwareonderhoud) speelt hierbij een essentiële rol. Risico’s bij het documenteren zijn ongewenste overlap, verschillende documentatiestandaards en inconsistentie in de afzonderlijk documentatieonderdelen.
Fouten in de documentatie zijn destructief voor de bedrijfsvoering. Daarom moet ervoor gezorgd worden dat de documentatie aan bepaalde kwaliteitseisen voldoet, zowel ten aanzien van de structuur en als ten aanzien van de inhoud. Ten aanzien van de structuur kunnen de volgende eisen gesteld worden:

  • Toegankelijkheid
    De documentatie moet overzichtelijk en logisch zijn opgebouwd.
  • Lokaliseerbaarheid
    Het moet duidelijk zijn waar welk onderwerp te vinden is.
  • Consistentie
    De documentatie mag geen innerlijke tegenstrijdigheden bevatten.
  • Onderhoudbaarheid
    De documentatie moeten op economisch verantwoorde wijze te onderhouden zijn.

Ten aanzien van de inhoud gelden de volgende eisen:

  • Juistheid
    De documentatie moet correct zijn.
  • Actualiteit
    De status van de documentatie moet parallel lopen met de status van het informatiesysteem.
  • Volledigheid
    In de documentatie mogen geen `witte vlekken` aanwezig zijn.
  • Nauwkeurigheid
    De documentatie moet over een op het gebruiksdoel afgestemde nauwkeurigheid bezitten.
  • Controleerbaarheid
    De documentatie moet met gemak op juistheid en volledigheid te controleren zijn.

Om aan al deze kwaliteitseisen te kunnen voldoen, moet documentatie beheerd worden. Daarom valt documentatie als configuratie-item binnen het configuratiebeheer.
Het beheren van de documentatie als configuratie-item houdt een scala van activiteiten in, die er zorg voor dragen dat de kennis omtrent een informatiesysteem gestructureerd wordt vastgelegd en voor iedereen toegankelijk is.

2. Waarom documenteren?

Het op gestandaardiseerde wijze documenteren geschiedt om een aantal redenen, waarvan de voornaamste hier genoemd worden. De documentatie is:

  • een hulpmiddel bij het informeren van het management over de bedrijfsvoering;
  • een hulpmiddel ten behoeve van de communicatie; management, eigenaars, gebruikers, ontwikkelaars, accountants, beheerders enzovoort dienen elkaar geïnformeerd te houden.
  • een ondersteuning voor specialistische taken; bij het hier bedoelde type document gaat het om aspecten als:
    • beschrijving van het informatiesysteem;
    • beschrijving van de werking van het informatiesysteem;
    • beschrijving van de samenhang tussen de systemen en systeemonderdelen;
    • de specificaties van de kwaliteitsnormen;
    • beschrijving van de beveiliging;
    • beschrijving van de gebruikte handmatige routines.
  • een leermiddel bij het opleiden van eindgebruikers (gebruikershandleiding en/of bedieningshandleiding);
  • een hulpmiddel voor het afleggen van verantwoording (verificatie tegen de normen) en het meten van de voortgang (documentatie is meetbaar en controleerbaar).

Door de documentatie up-to-date te houden, wordt voorkomen dat een applicatie op de duur uitgroeit tot een onbeheersbaar en ongeleid projectiel voor de organisatie. (Zie ook ‘Organisatie en inrichting functioneel applicatiebeheer’.)

3. De organisatie van het beheren van documentatie

De organisatie rondom het deelgebied documentatie kan grofweg in twee vormen worden opgezet, te weten:

  • centraal,
  • decentraal.

Bij centralisatie worden alle activiteiten ten behoeve van het documenteren door één persoon (de documentalist) gecoördineerd.
Bij decentralisatie worden de activiteiten ten aanzien van documentatie ondergebracht bij diverse personen (met hun diverse taken) binnen de organisatie. Voor beide vormen geldt als eerste vereiste dat de eigenaars van de producten bekend moeten zijn. Dit is nodig in verband met het toewijzen van het wijzigingsrecht. Vervolgens moeten taken worden toegewezen, zoals wie controleert of wie verifieert. Ten behoeve van de documentatie moeten ook de communicatiestructuur en de rapportagelijnen vastgesteld worden. Bovendien moeten er procedures ontworpen worden ten behoeve van de updating en verstrekking van de documentatie.

3.1 Centraal georganiseerd documentatiebeheer

Deze organisatievorm verdient de voorkeur boven de decentrale vorm. Er is dan één instantie (één team of één persoon) die verantwoordelijk is voor alle documentatie van een (deel van een) informatiesysteem. Dit team of deze persoon vormt dan een stafafdeling of staffunctionaris die ten dienste staat van alle betrokkenen bij de informatievoorziening, zoals gebruikers, beheerders en managers.
De taken van deze stafafdeling of functionaris ressorteren onder het taakgebied configuratiebeheer. Deze centrale documentatiebeheerders dienen een bibliothecaire opleiding gevolgd te hebben met als specialisatie documentalist. Pas in tweede instantie is een automatiseringsopleiding gewenst. Door met deze specialisten te werken kan de kwaliteit van de documentatie, alsmede de kwaliteit van het beheren van de documentatie, beter gewaarborgd worden. Ten eerste omdat namelijk dan voor iedereen in de organisatie duidelijk is hoe men iets over documentatie te weten moet komen en bij welke contactfunctionaris men moet zijn om, met honderd procent zekerheid, de meest recentelijk bijgewerkte documentatie te verkrijgen. Ten tweede is het eenvoudiger in deze organisatiestructuur te controleren of de documentatie aan de gestelde normen en criteria voldoet. De documentalisten zijn uiteraard niet direct voor de inhoud van de documentatie verantwoordelijk. Deze verantwoordelijkheid blijft bij de deskundigen, die aan de bron van een (documentatie)product staan. Wel zal de documentalist periodiek opdrachten moeten verstrekken aan andere deskundigen dan de opsteller van een document om de inhoud te beoordelen.
De documentalisten werken aan de hand van het door het service management geformuleerde documentatiebeleid een documentatieplan uit. In dit documentatieplan staan onder andere de projectplannen van de projecten die noodzakelijk zijn om de documentatie toegankelijk, lokaliseerbaar, consistent, onderhoudbaar, juist, volledig, actueel, nauwkeurig en controleerbaar te houden of te krijgen.

3.2 Decentraal georganiseerd documentatiebeheer

Deze organisatievorm van het documentatiebeheer vinden we in de meeste organisaties terug. Althans bij onderzoek hiernaar geven de meeste organisaties op dat het beheer van documentatie op deze wijze georganiseerd is. In weinig gevallen echter bleek bij deze organisaties een concreet documentatieplan aanwezig, of documentatiebeleid geformuleerd te zijn. Wat we zien is dat sommige beheerders de beschikking hebben over, vaak verouderde, projectdocumentatie. De overige documentatie is vaak opgesteld door en ten dienste van een beheerder van een deelgebied van het informatiesysteem. Zo heeft een netwerkbeheerder vaak de situatie wel op papier staan, maar of dit toegankelijk is voor andere medewerkers in de organisatie is nog maar de vraag.
Hetzelfde geldt in het algemeen voor de onderhoudprogrammeurs, systeemprogrammeurs, functioneel applicatiebeheerders en vele andere functionarissen. De kennis zit voornamelijk in het hoofd met op papier wat reminders. Van een gestructureerd kennis/documentatiebeheer is slechts in weinig bedrijven sprake!

4. Documentatiebeleid

Documentatiebeleid dient, als integraal bestanddeel van het kwaliteitsbeleid, gebaseerd te zijn op de volgende uitgangspunten.Het moet:

  • kunnen resulteren in een gedetailleerd documentatieplan;
  • expliciete vermelding geven van de toe te passen documentatietechnieken en te gebruiken standaards;
  • aansluiten op de gestelde kwaliteitseisen.

De bovengenoemde criteria spreken voor zich. Documentatiekwaliteit kan immers alleen worden verkregen als de validiteit van de informatievoorziening te allen tijden kan worden gegarandeerd. Voor de vereiste kwaliteit van documentatie kunnen vier niveaus worden onderscheiden:

  • minimale documentatie (voor slechts een bepaald gebruiksdoel, met daarin een korte beschrijving van het systeem of programma, sourceprogrammalistings en  testgegevens);
  • interne documentatie (behalve voor een specifiek doel ook voor een specifieke gebruiker, zodat naast de inhoud van de minimale documentatie bij deze documentatie veel commentaar in de programmalistings is opgenomen, om de gebruiker behulpzaam te zijn bij de invoering en het gebruik van de programma’s);
  • werkdocument (te gebruiken door verschillende personen in dezelfde organisatie en tevens te gebruiken in andere organisaties);
  • formele publicatie (voor grote en complexe organisaties, die voor algemeen gebruik zijn bestemd en waaraan redactioneel dus hoge eisen worden gesteld vanwege de ‘status’)

Bij de implementatie van het documentatiebeleid worden ten aanzien van de kwaliteit standaardeisen gesteld, die in de vorm van voorschriften of richtlijnen moeten worden vastgelegd.

5. Het documentatieplan

Het documentatieplan stelt ons in staat de activiteiten ten behoeve van het documenteren planmatig uit te voeren. Hierdoor zal het documenteren efficiënter en effectiever verlopen. Het documentatieplan kan bestaan uit:

  • standaards en richtlijnen ten behoeve van het documenteren;
  • de kwaliteitseisen van de documenten;
  • de formele documentatieactiviteiten;
  • de beschikbare of benodigde middelen (budget, personeel en tijd);
  • een lijst met bestaande producten;
  • een lijst met eigenaars van producten;
  • een lijst met producten in ontwikkeling;
  • een lijst met aanvragen voor producten;
  • een lijst met verzoeken tot wijzigingen;
  • een verzendlijst per product;
  • een planning voor het vervaardigen en onderhouden van producten;
  • projectplannen ten behoeve van de documentatie.

5.1 Projecten ten behoeve van documentatiebeheer

Projecten die ten behoeve van het documentatiebeheer ingericht kunnen worden zijn projecten ter controle van de juistheid, volledigheid, actualiteit, nauwkeurigheid, controleerbaarheid, toegankelijkheid, consistentie, lokaliseerbaarheid en onderhoudbaarheid van de documentatie. Tenslotte bestaat ook de mogelijkheid projecten te organiseren ter wijziging en verspreiding van en ter informatie over documentatie.

5.2 Stappenplan ten behoeve van documentatie

Teneinde de documentatie te laten voldoen aan de kwaliteitseisen ten aanzien van de structuur en de inhoud is hier een stappenplan aan activiteiten opgesomd:

  • Stel een documentatieplan op.
  • Inventariseer welke producten beschikbaar zouden moeten zijn.
  • Inventariseer welke producten beschikbaar zijn.
  • Geef opdracht om de niet aanwezige benodigde documentatie te vervaardigen.
  • Controleer de documentatie op geformuleerde kwaliteitseisen.
  • Draag zorg voor het configuratiebeheer.
  • Verzamel en analyseer verzoeken tot wijziging.
  • Geef opdracht om de documentatie bij te werken (wijzigen).

6. Overzicht van te beheren documentatie

Om enig overzicht te verkrijgen over de te beheren documentatie en deze op een werkbare wijze te structureren, kan men gebruik maken van de indeling naar documentatiesoorten gecombineerd met een meersporenmodel voor het groeperen van activiteiten van systeemontwikkeling (figuur 1).
De motivatie voor het hanteren van een dergelijk model komt voort uit het feit dat de meeste documentatie ontstaat als product van systeemontwikkeling. De gehanteerde figuur kan opgevat worden als een ontwikkelmodel en dient per project nader verbijzonderd te worden, waarbij eventuele extra afhankelijkheden (zoals interacties tussen de sporen) worden aangebracht. De figuur laat zien dat informatiesystemen ontwikkeld behoren te worden vanuit een informatiebeleid. Op dit informatiebeleid wordt de informatieplanning gebaseerd. Deze informatieplanning houdt het opstellen van een aantal samenhangende plannen in (met verschillende horizonten) ten behoeve van de ontwikkeling van de informatievoorziening De feitelijke ontwikkeling van een informatiesysteem loopt van een definitiestudie tot en met de invoering. Na het basisontwerp worden verschillende werkzaamheden naast elkaar uitgevoerd. 

Deze kan eventueel per deelsysteem worden uitgevoerd. Dit spoor bestaat uit het detailontwerp van de applicatie, de bouw en de systeem(integratie)test. Indien een gegevensconversie moet worden uitgevoerd, dient de voorbereiding van de conversie vroegtijdig plaatst te vinden. Uiterst links staan de activiteiten die dienen te worden uitgevoerd door organisatiedeskundigen. Als eerste wordt hier de organisatorische inrichting uitgevoerd. Vervolgens worden de handmatige onderdelen van het informatiesysteem vastgelegd in handmatige procedures. Tevens wordt er voor gezorgd dat de programmatuur op de organisatie aansluit. Tenslotte volgt de voorbereiding op de invoering van het gehele (geautomatiseerde plus handmatige)informatiesysteem. Ten behoeve van de opleiding van toekomstig uitvoerend personeel en andere betrokkenen wordt een opleidingsplan opgesteld. Daarna worden cursussen gerealiseerd en worden de betrokkenen opgeleid.

Het middelste spoor geeft de voorbereiding van de acceptatietest aan. Deze activiteiten houden niet alleen het opzetten van de acceptatietest in, maar ook andere algemene zaken zoals voorlichting en overleg met de ondernemingsraad.
De parallel lopende sporen komen tenslotte weer samen voor de feitelijke invoering, die pas kan volgen na een proefconversie en acceptatie, en na de ‘echte’ conversie van de oude gegevens. Het meersporenmodel legt vervolgens de basis voor een indeling van de te beheren documentatie
Het beeld wordt volledig als de producten van projectdocumentatie en de beheerdocumentatie toegevoegd worden aan de groepen van producten van systeemontwikkeling. Nu er groeperingen van producten zijn ontstaan, kan bepaald worden uit welke concrete producten deze groepen bestaan.

6.1 Producten van projectdocumentatie

Plannen:

  • plan van aanpak basisontwerp;
  • bijgewerkt systeemontwikkelingsplan;
  • plan van aanpak detailontwerp;
  • testplannen;
  • plan voor realisatie en invoering;
  • plan van aanpak voor realisatie.

Rapporten:

  • rapport basisontwerp;
  • functioneel ontwerprapport;
  • technisch ontwerprapport;
  • rapport detailontwerp;
  • rapport over realisatie, conversie en invoering;
  • eindrapport invoering en overdracht.

6.2 Producten van bedrijfsanalyse en informatieanalyse

  • dossier informatiebeleid;
  • informatieplan;
  • rapport definitiestudie.

6.3 Producten van het ontwerp van informatiesystemen

Dossiers:

  • ontwerp van informatiefuncties;
  • functionele gegevensdefinities;
  • extern interface;
  • gebruikersinterface;
  • technisch applicatieontwerp;
  • technische gegevensdefinities;
  • implementatieanalyse;
  • technische infrastructuur.

6.4 Producten van het bouwen van applicaties

  • definitie van fysieke opslagstructuur;
  • definitie van fysieke schermafbeeldingen;
  • programmadossier;
  • dossier systeem(integratie)test;
  • testset systeem(integratie)test;
  • geteste programma’s;
  • verwerkingsgang voor productie.

6.5 Producten in verband met gegevensconversie

  • rapport gegevensconversie;
  • geconverteerde gegevens.

6.6 Producten in verband met organisatorische inrichting

  • dossier ontwerp van de organisatorische inrichting;
  • (re)organisatieplan;
  • dossier handmatige procedures.

6.7 Producten in verband met acceptatie

  • dossier acceptatietest gebruiksfunctie;
  • testset acceptatietest gebruiksfunctie;
  • rapport acceptatietest exploitatiefunctie;
  • rapport acceptatietest onderhoudsfunctie.

6.8 Producten in verband met opleiding

  • opleidingsplan;
  • cursussen;
  • dossier opgeleide medewerkers.

6.9 Producten in verband met invoering c.q. migratie

  • invoeringsplan of een migratieplan.

6.10 Producten in verband met bedrijfsvoering

  • handleidingen voor gebruikers;
  • handleiding voor het applicatieonderhoud;
  • gebruikersregistratie;
  • apparatuurregistratie;
  • documentatieregistratie;
  • storingsmeldingen;
  • probleemrapportendossier;
  • testresultaten;
  • analyse rapporten;
  • Handleiding voor productie;
  • onderhoudsplan;
  • gebruiksregistratie;
  • softwareregistratie;
  • gegevensregistratie;
  • wijzigingsdossier;
  • beheerprocedures;
  • evaluatierapporten;
  • logboeken;
  • financiële en urenregistratie.

 7. Nawoord

Het lijkt natuurlijk enorm veel, maar omdat de meeste software tegenwoordig hoofdzakelijk bestaat uit reeds bestaande software, ligt een groot deel van deze belasting bij de ICT-leverancier en zal dit via SLA’s geregeld moeten worden. (Zie ook ‘Service Level Management en Service Management functioneel beheer’.) Wel is het zaak om deze leveranciersdocumentatie ook daadwerkelijk te testen op gebruikswaarde en hiervoor normen af te spreken in het SLA.

Meer weten over IT security?

Actueel

Gerelateerd nieuws

OT-beveiliging: van moeten naar willen

Lees verder

Whitepaper: NIS2-richtlijn in Nederland

Lees verder

Vernieuwd: whitepaper: OT-Cybersecurity in de industrie

Lees verder