Basiskennis informatica/Automatiseringsproces

Een automatiseringsproces is een proces of traject dat er op gericht is om software aan te schaffen, te ontwikkelen of te verbeteren. Ook worden de termen Software engineering en softwareontwikkeling wel gebruikt, maar die dekken niet de aanschaf van kant-en-klare softwarepakketten.

Voorbeelden:

een bedrijfsproces automatiseren, dat wil zeggen: een grotendeels handmatig werkproces omzetten in een informatiesysteem; denk bij een informatiesysteem bijvoorbeeld aan een interne bedrijfsapplicatie, zoals orderverwerking, inkoopproces of facturering;
een (deel van een) bestaand computersysteem verbeteren of vervangen;
een app voor een smartphone of een game voor de markt maken of verbeteren;
een website of een webwinkel maken of verbeteren.

NB In dit hoofdstuk beperken we ons tot informatiesystemen en laten fysieke componenten buiten beschouwing. Voor de automatisering van fysieke processen, zoals logistieke en fabricageprocessen (denk aan robotisering en orderpicking), gelden overigens soortgelijke methoden.

Zo'n proces bestaat uit meerdere stappen, die mede afhankelijk zijn van de gekozen softwareontwikkelmethode. Een automatiseringsproces kan kort of lang zijn, afhankelijk van de omvang van het project en de gekozen ontwikkelmethode. Een nieuw informatiesysteem ontwikkelen duurt vaak maanden en soms jaren.

De volgende onderdelen zullen in de regel op de één-of-andere manier deel uitmaken van een automatiseringstraject. Afhankelijk van de grootte en de verwachte duur van een traject, zullen de stappen uitgebreider dan wel in een bekorte versie doorlopen worden en zal de project-organisatie groter of kleiner zijn.

I: Start en organisatie
II: Haalbaarheidsstudie & Programma van eisen en wensen
III: Systeemontwerp
IV: Realisatie
V: Testen
VI: Invoering (implementatie)
VII: Systeembeheer
VIII: Evaluatie.

Fase I: Start en organisatie

Een automatiseringsproces start met een impuls vanuit de organisatie. Het management wil bijvoorbeeld een bedrijfsproces efficiënter maken met een nieuw informatiesysteem, of een bestaand informatiesysteem verbeteren. Deze wens zal als voorlopige doelstelling worden geformuleerd. Hij moet in ieder geval passen in het actuele informatieplan (over de inrichting van de informatiehuishouding in een organisatie), automatiseringsplan en/of het informatiebeleid van de organisatie. Een automatiseringsproces is in de regel een langer lopend, groot en duur proces. Daarom is uiteindelijk goedkeuring vereist vanuit de directie, of, bij grote organisaties, een groep of functionaris aan wie dit gedelegeeerd is.

Een automatiseringsproces wordt in de regel gerealiseerd via een projectorganisatie, een tijdelijk samenwerkingsverband van specialisten uit diverse vakgebieden, en uit verschillende afdelingen en andere organisatie-onderdelen, die elk hun eigen taak in de realisatie van het proces hebben. Gebruikelijk is om direct na de goedkeuring te beginnen met het optuigen van de projectorganisatie: het instellen van een stuurgroep, één of meer projectgroepen, en een groep gebruikers die meedenken.

Stuurgroep: coördinerend orgaan dat bij een project de verschillende werk- en projectgroepen en hun taken op elkaar afstemt, belangrijke beslissingen neemt en de eindverantwoordelijkheid draagt. Hij is in de regel samengesteld uit de hoogste leidinggevenden uit de bedrijfsonderdelen die bij het project betrokken zijn.
Projectgroep: groep medewerkers (eigen en/of externen) die het project uitvoeren. Hij bestaat in de regel uit een mix van medewerkers, die bijeen zijn gebracht op basis van hun (verschillende) bekwaamheden, vakkennis en karakters. In de loop van de tijd kan de projectgroep variëren: eerst ligt de nadruk op informatie-analyse, later worden systeemontwerpers en programmeurs toegevoegd en komt systeembeheer in beeld. De projectgroep staat buiten de lijnhiërarchie. De projectleider is verantwoordelijk voor de planning, uitvoering en voortgang en legt daarover verantwoording af aan de stuurgroep.
Klankbordgroep of gebruikersgroep: een selectie van gebruikers die met het systeem zullen gaan werken en die meedenken over de eisen aan en wensen voor het systeem. De groep is bij voorkeur samengesteld uit functionarissen met verschillende achtergronden, en zowel met eindgebruikers als met ten minste één lijnmanager. Zij zijn vertegenwoordigers van hun collega's en genieten hun vertrouwen. Deze groep wordt op verschillende tijdstippen ingeschakeld: om de functionaliteit te bepalen en uiteindelijk om de gebruikerstest of acceptatietest uit te voeren. Zij hebben in de regel contact met een informatie-analist (schakel tussen IT'ers en de business) uit de projectgroep, die ook deelneemt aan vergadering van de gebruikersgroep. Deze informatie-analist brengt vragen en voorstellen in en neemt uitkomsten mee naar de projectgroep. NB Voor het bouwen van websites, apps en games is het in de regel niet mogelijk om een gebruikersgroep samen te stellen. Men zal dan op andere manieren gebruikerswensen moeten leren kennen.

De sturing van projecten verloopt in de regel via het Linking pin model. Zo is de projectleider lid van de stuurgroep: hij/zij legt verantwoordig af aan de stuurgroep en behartigt daar ook de belangen van de projectgroep. Omgekeerd koppelt hij/zij uitkomsten en opdrachten uit stuurgroepvergaderingen terug naar de projectgroep. Leden van de klankbord- of gebruikersgroep brengen wensen van hun afdeling in bij deze groep en koppelen de uitkomsten van een vergadering terug naar de afdeling.

Vervolgens komen de gebruikelijke onderdelen van de start van een project aan bod, zoals de doelstelling aanscherpen (afgeleid van en/of refererend aan de bedrijfsdoelstellingen en bij voorkeur volgens het SMART-principe), het project in stappen indelen, taken verdelen, planning opstellen en voortgang bewaken.

In deze fase vindt ook de keuze plaats voor de te volgen softwareontwikkelmethode.

Fase II: Haalbaarheidsstudie & Programma van eisen en wensen

In deze fase wordt een advies opgesteld op basis waarvan het management kan beoordelen of de automatiseringswens haalbaar is.

Businesscase

Vaak zal als eerste stap een haalbaarheidsstudie of businesscase worden uitgevoerd. In een businesscase worden alle uitgangspunten beschreven: doel, de op te leveren producten (of de eisen waaraan de producten moeten voldoen), randvoorwaarden en relaties met andere projecten. Vervolgens wordt onderzoek gedaan naar de kosten, baten en de risico's van het project. In dit stadium is het slechts mogelijk om hiervan globale inschattingen te maken. Op basis van de businesscase wordt besloten of het zinvol is om verder te gaan met het project. In de loop van het project kan de businesscase worden bijgesteld.

Vooronderzoek

Een uitvoeriger onderzoek naar de haalbaarheid van een project is het vooronderzoek. Dit kan als vervolg op een businesscase, met alleen de aanvullende onderdelen uit een vooronderzoek. Of het kan in plaats van de businesscase.

Tijdens een vooronderzoek wordt onderzoek gedaan naar verwachtingen en behoeften van gebruikers, naar de huidige bedrijfsprocessen en hun knelpunten, bedrijfsvoering, IT-kaders, omgevingsfactoren en de strategie van de organisatie. Ook een analyse van de inrichting van de organisatie komt aan bod: naast de strategie, ook structuur, cultuur, managementstijl, de gebruikers en de bestaande systemen.

Belangrijk onderdeel is een analyse van de huidige en van de gewenste situatie, eventueel aangevuld met een sterkte-zwakteanalyse. Uitdagingen daarbij zijn: problemen helder krijgen en eisen en wensen voor het systeem boven tafel krijgen. Voor welk probleem zal het systeem een oplossing moeten zijn? Hoe flexibel moet het systeem zijn? Wie gaan ermee werken? Wat zijn hun verwachtingen? Om welke aantallen gaat het? En vervolgens zullen de uitkomsten worden vertaald naar een programma van eisen en wensen.

Tijdens een vooronderzoek kan gebruik worden gemaakt van informatie-analyse.

Informatie-analyse

Informatie-analyse omvat:

het in kaart brengen en analyseren van de bedrijfsprocessen, informatiestromen en informatieprocessen in een organisatie(onderdeel),
het onderzoeken van de knelpunten daarin, en
het adviseren over verbetermogelijkheden.

De basis voor informatie-analyse wordt gevormd door:

interviews met relevante functionarissen binnen de organisatie, van de directeur en afdelingshoofden tot beoogde eindgebruikers; de verslagen ervan zijn gecorrigeerd en gefiatteerd door de geïnterviewden;
relevante handleidingen en werkinstructies, interne rapporten, nota's en memo's;
vakliteratuur.

Het advies bevat in ieder geval:

Een gedetailleerde probleemstelling of probleemdefinitie, met de uitgewerkte doelstelling en randvoorwaarden.
Het programma van eisen, met afbakening: wat valt wel en wat niet binnen het project?
Toepasbaarheidsonderzoek: in welke mate kan automatisering de doelstellingen ondersteunen? Kan een (aangepast of nieuw) systeem de oplossing voor het probleem zijn?
Alternatieve oplossingen, waarin in ieder geval zijn opgenomen:
1. het bestaande systeem houden en op enkele punten aanpassen
2. (onderzoek naar) een kant-en-klaar systeem, dat, wellicht met enkele kleine aanpassingen, geschikt kan zijn en tegen aanvaardbare kosten kan worden aangeschaft; (als zoiets inderdaad bestaat en wordt aangeschaft, kunnen enkele kostbare stappen worden overgeslagen en naar de Implementatie-fase worden gesprongen)
3. zelf een geheel nieuw systeem bouwen.
Een gedetailleerde kosten-baten schatting per alternatief.
Mogelijke organisatorische gevolgen.
Aanbevelingen.

De stuurgroep neemt op basis van dit advies een besluit en bepaalt het vervolgtraject: stoppen, uitstellen of direct doorgaan, al of niet in gewijzigde opzet. En als er wordt doorgegaan: welke alternatieve oplossing wordt gekozen?

Als wordt gekozen voor de aanschaf van een kant-en-klaar softwarepakket, is het programma van eisen meestal voldoende om aan de slag te gaan. Wel kan aan de projectgroep een inkoper worden toegevoegd. Zie het hoofdstuk Aanschaf softwarepakket voor de details. Zeer kort door de bocht komt het er op neer, dat de fases III en IV worden vervangen door het aankoopproces. Men gaat daarna verder met fase V, het testen (men moet immers zeker weten dat het beoogde systeem aan de vereisten voldoet).

Als gekozen is voor zelf bouwen of aanpassen, is de eerste vervolgstap gedetailleerd bepalen wat het systeem of de aanpassing moet kunnen.

Fase III: Systeemontwerp

De term 'Systeemontwerp' wordt zowel gebruikt voor het proces als voor de uitkomst.

Doel van deze fase is te komen tot een ontwerp voor het te bouwen of aan te passen informatiesysteem of onderdeel daarvan. Dit ontwerp moet zodanig zijn opgesteld dat zowel IT'ers als gebruikers het kunnen begrijpen.

Input voor dit proces: de beslissing van de stuurgroep en het advies uit de vorige fase. En meestal zijn er voor details aanvullende interviews nodig met eindgebruikers of antwoorden op vragenlijsten van de gebruikersgroep. Het is bovendien essentieel om definities en andere voorstellen vooraf voor te leggen aan de gebruikersgroep en te vragen om verbeteringen.

Een informatiesysteem bestaat uit twee belangrijke delen:

Functies, vastgelegd in een functioneel ontwerp, dat later kan uitmonden in programma's. Een functie is een activiteit of taak van een of meer eindgebruikers die ertoe leidt dat onderdelen uit de database worden geraadpleegd, gemuteerd, toegevoegd of verwijderd. Een functie wordt in gang gezet door een event, gebeurtenis of actie. Voorbeelden zijn: inkooporders verwerken, verkoop van eindproducten, facturatie of klachtenbehandeling, maar ook het beheer van klantgegevens of voorraadbeheer. Functies worden onderzocht in de functie-analyse.
Gegevens, vastgelegd in een gegevensmodel of datamodel, waarmee later een database kan worden gebouwd. Gegevens worden onderzocht in de gegevensanalyse.

In deze fase komen beide aan bod. De analyses kunnen ook tegelijkertijd worden uitgevoerd. Wel belangrijk is dat er overleg en uitwisselingen van ideeën en ontwerpen plaats vinden tussen de ontwerpers van het functioneel ontwerp en die van het gegevensmodel, zodat beide onderdelen op elkaar aansluiten. De functies worden beschreven, de gegevens worden benoemd en gestructureerd.

Functie-analyse

Het doel van functie-analyse is te komen tot een overzicht van alle functies die het informatiesysteem gaat uitvoeren, vastgelegd in een functioneel ontwerp. Alle benodigde functies worden geïnventariseerd, gedetailleerd beschreven en onderling gestructureerd. Voor een visueel overzicht kunnen schema's worden toegevoegd, zoals een functiemodel (bijvoorbeeld een data flow diagram) en/of stroomschema's. De uitkomst is een functioneel ontwerp. Aan de hand hiervan kan een programmeur aan de slag om de functies om te zetten in programma's.

Gegevensanalyse

Het doel van gegevensanalyse of data-analyse is het structureren van de gegevens die in het systeem opgenomen worden, vastgelegd in een gegevensmodel. Aan de hand hiervan kan een programmeur de database inrichten.

Onderdelen van gegevensanalyse zijn:

Bepalen welke gegevens in het systeem worden opgenomen. Welke informatie is nodig om de gewenste functies te kunnen uitvoeren? Voor Orders zijn bijvoorbeeld klantgegevens (zoals naam, adres, e-mail), bestelde producten (met productnaam, prijs en hoeveelheden) en orderdatum nodig.
Beschrijven van de gegevens. Er zijn voor alle gegevens definities nodig, die eenduidig zijn en door alle betrokkenen worden begrepen en onderschreven.
Bepalen van de samenhang tussen de gegevens, groeperen van gegevens (in vakjargon databasenormalisatie genoemd), en ervoor zorgen dat elk soort gegeven een eigen unieke sleutel of code krijgt, waarmee gegevens door het hele systeem herkenbaar zijn. Voorbeeld: er zijn vele mannen die Jan de Vries heten. Om een persoon toch eenduidig en uniek te kunnen benoemen, is er dan een identificatiecode nodig, bijvoorbeeld een burgerservicenummer (BSN), een personeelsnummer of een klantnummer.
Leggen van koppelingen of relaties tussen gegevens, waardoor een Entity-relationshipmodel ontstaat.
Bepalen welke gebruikers de gegevens mogen:
1. invoeren, raadplegen, muteren en verwijderen (in de regel door eindgebruikers)
2. definiëren, herdefinieëren en vernietigen (in de regel door gegevensbeheer).

De uitkomst is een gegevensmodel of datamodel, met beschrijvingen van gegevens en hun onderlinge relaties. Vaak wordt een gegevensmodel met al zijn onderdelen vastgelegd in een speciaal systeem en kunnen de onderlinge relaties visueel worden gepresenteerd, bijvoorbeeld in een data structure diagram (DSD).

Samenhang tussen functies en gegevens

De samenhang tussen functies en gegevens kan bijvoorbeeld worden getoond via een data flow diagram: een grafische weergave van de gegevensstromen in een informatiesysteem, waarbij zowel de functies of processen als de gegevens zijn opgenomen.

Uitkomsten

De uitkomst van deze analyses is het systeemontwerp. Dat bestaat uit:

Functioneel ontwerp, ook wel logisch ontwerp genoemd, met beschrijvingen van en samenhang tussen de gevraagde functies.
Gegevensmodel, met beschrijvingen en schema's van gegevens en hun onderlinge samenhang.
De samenhang tussen functies en gegevens.

Tezamen worden zij het Systeemontwerp genoemd.

Als een systeemontwerp is gefiatteerd (bijvoorbeeld door gebruikers en/of de leidinggevenden), kan het overhandigd worden aan de technisch ontwerper(s) of programmeur(s), die ermee aan de slag gaan om het gewenste systeem te realiseren.

Fase IV: Realisatie

In deze fase gaat het om het programmeren, om de voorbereiding daarop en het programmeren zelf. Tot nu toe ging het over WAT: wat willen we, wat zijn de eisen en wensen, wat zijn de functionele specificaties? In deze fase gaat het over HOE: hoe worden de functionele specificaties omgezet naar een goed werkend systeem met goed werkende programma's?

De eerste stap in deze fase is de overdracht van het systeemontwerp aan de technisch ontwerper(s) en/of programmeurs, met een uitgebreide toelichting. In deze fase wordt de projectorganisatie uitgebreid met technisch ontwerpers en/of programmeurs.

Technisch ontwerp

Bij grote projecten wordt eerst een technisch ontwerp gemaakt. Een technisch ontwerp is een tussenfase tussen het systeemontwerp en het programmeren. Het beschrijft hoe de software technisch gerealiseerd moet worden. Ook een technisch ontwerp bestaat uit twee delen, die corresponderen met de onderdelen uit het systeemontwerp:

Over de programma's: Hoe gaan de functies uit het functioneel ontwerp gerealiseerd worden? Hoe worden de applicaties aangeboden? Het maakt bijvoorbeeld nogal verschil of programma's alleen op een mainframe met daaraan gekoppelde pc's of laptops moeten draaien, of op losse apparaten die verbonden zijn met het internet, waaronder smartphones. Nu vindt ook een onderverdeling plaats in technische eenheden zoals programma's, modules en functies. Soms wordt ook besloten in welke programmeertaal wordt geprogrammeerd, maar meestal zal dat al eerder zijn vastgelegd.
Over de database: welk soort database wordt gebruikt, hoe wordt het gegevensmodel geïmplementeerd?

Grafisch ontwerp

Vrijwel altijd bevat een informatiesysteem diverse schermen waarop informatie wordt gepresenteerd en/of waarop gegevens worden ingevoerd/gemuteerd/verwijderd. Concreet gaat het om het ontwerpen van de schermen en navigatiemogelijkheden op elk scherm en tussen schermen. Hiervoor is grafische vormgeving nodig. Het doel is dat eindgebruikers gemakkelijk en prettig met het systeem kunnen werken en grafische vormgeving kan daarbij helpen.

Programmeren

Het technisch ontwerp wordt vervolgens omgezet naar:

programma's: de broncode wordt geschreven, zie Programmeren (computer); en
een database, die meestal bestaat uit tabellen die onderling samenhangen.

Dit gebeurt door programmeurs. Dezelfde programmeurs testen vervolgens als eerste of hun eigen programma's naar behoren werken.

Fase V: Testen

Het testen van software is het vaststellen in hoeverre de software aan de eisen voldoet. Als basis voor het testen dienen alle documenten met de eisen waaraan het systeem moet voldoen. Meestal wordt het systeemontwerp daarvoor gebruikt.

In de meest uitgebreide situatie wordt getest door:

De programmeur: doet elk programma wat het moet doen?
Informatie-analist/systeemontwerper: Zijn alle functies uit het systeemontwerp correct vertaald naar programma's? Doen de programma's wat in het systeemontwerp staat? Hoe is de gebruikersvriendelijkheid, waaronder de snelheid van het systeem?
Een selectie van eindgebruikers, zij voeren de acceptatietest uit. De gebruikers kunnen dezelfde zijn als eerder in de gebruikers- of klankbordgroep. Vaak wordt de acceptatietest begeleid door een of meer informatie-analisten. De gebruikers testen of het systeem voldoet aan hun eisen en wensen zoals die eerder zijn vastgelegd.

Testplan en testverslag

Bij het testen gaat het erom alle situaties uit te proberen. Voorbeelden zijn: reageert een programma volgens verwachting, worden gemuteerde gegevens correct opgeslagen, verschijnen er alleen foutboodschappen als een ongeoorloofde handeling wordt verricht?

Hiertoe wordt een testplan opgesteld waarin alle te testen situaties worden opgesomd, tezamen met de verwachte uitkomsten. De restultaten worden vastgelegd in het testverslag. Bij negatieve uitkomsten worden fouten door de programmeur opgelost en wordt er daarna opnieuw getest.

Een minder vergaande methode is, om alleen een steekproef uit te voeren en bij gebleken vertrouwen, de rest van de test niet uit te voeren.

Na fiattering van het systeem(deel) door de gebruikers wordt het opgeleverde systeem(deel) in productie genomen en geïmplementeerd.

Fase VI: Invoering

Zie Implementeren van informatiesystemen voor het Wikibook over dit onderwerp.

Nadat een informatiesysteem door de gebruikers is goedgekeurd, kan het systeem worden ingevoerd, vaak "implementatie" genoemd. Hierbij wordt het systeem ingericht, worden gegevens geconverteerd, gebruikers en systeembeheerders opgeleid en de organisatie zo nodig aangepast. Er zijn vele aspecten om in de planning op te nemen:

Technische aspecten

Hardware installeren (indien nodig), in de computerruimte en/of bij de gebruikers.
Nieuwe software installeren.
Systeemdocumentatie overdragen aan systeembeheerder(s), eventueel handleidingen maken voor systeembeheer.
Systeembeheerders opleiden.
Conversie: Vaak zijn er gegevens die naar het nieuwe systeem moeten worden overgezet. Het kan zijn dat er een oud systeem is, dat wordt vervangen door het nieuwe. Of dat er nog een handmatige administratie is die moet worden ingevoerd. Of er is sprake van een fusie waarbij de éne partij overschakelt op het systeem van de ander. In alle gevallen zullen er lijsten moeten komen met namen van velden in het nieuwe systeem in de éne kolom en de corresponderende veldnamen van het oude systeem in een tweede kolom. In het geval van de overgang van een oud naar een nieuw systeem, kan de conversie zelf vervolgens meestal wel geautomatiseerd worden. Met een beetje geluk kunnen handmatige administraties gescand worden en dan automatisch ingevoerd worden, maar meestal zal het om handmatig invoeren gaan. In alle gevallen is het belangrijk dat de oude gegevens eerst geschoond worden (ontdaan van foute, overbodige en verouderde gegevens), voordat ze worden overgezet.

Aspecten gericht op gebruikers

Inrichten van het systeem: Vaak zijn er keuzemogelijkheden (met behulp van parameters) om een systeem te gebruiken. Bijvoorbeeld: De één wil lijsten met lay-out A en een ander met lay-out B. Samen met gebruikers worden de keuzemogelijkheden stuk-voor-stuk ingesteld.
Handleidingen en instructies maken voor gebruikers. Als het goed is, is in een eerder stadium al nagedacht in welke vorm dergelijke hulp wordt geboden: komt er bij elk scherm een Help-scherm, komt er één document waar "alles" in staat, komt er een wiki waarin ook eindgebruikers tips en/of vragen kwijt kunnen, een tussenvorm of combinatie? In deze fase wordt de gekozen vorm ingericht, (initieel) gevuld en gepubliceerd. Handleidingen kunnen onderdeel zijn van de acceptatietest.
Gebruikers opleiden, hen leren werken met het systeem.
Organisatie aanpassen? Het kan nodig zijn om de organisatie/afdeling anders in te richten. Bijvoorbeeld: als er een website is gemaakt waarop klanten voortaan zelf hun aanvragen kunnen invoeren: dan zal er minder administratief personeel nodig zijn dat voorheen de aanvragen invoerde, en juist meer telefonische/webgerelateerde ondersteuning van klanten.

Projectdocumentatie

Projectdocumentatie bestaat uit alle documenten die in de loop van het project zijn verschenen, zoals voorstellen, verslagen van vergaderingen, eindrapporten, besluiten, het systeemontwerp en testverslagen. Deze documenten worden gearchiveerd conform de voorschriften van de organisatie en zodanig dat ze door belanghebbenden gemakkelijk zijn terug te vinden.

Einde van het project

Nadat alle actiepunten voor de implementatie zijn afgerond, wordt het project ontbonden. Vaak wordt dit feestelijk gevierd met alle deelenemers aan het project. Als er nu nog vragen, klachten of wensen zijn, legt men die voor aan systeembeheer.

Fase VII: Systeembeheer

Nadat een informatiesysteem is ingevoerd, neemt systeembeheer de zorg voor het systeem over. Er kunnen bijvoorbeeld nog kinderziekten zijn, die opgelost moeten worden. Of wensen die men wil realiseren. Echte fouten zullen moeten worden opgelost; als het goed is, is daar budget voor gereserveerd.

Systeembeheer bestaat in de regel uit twee soorten functies:

Technisch systeembeheer zorgt ervoor dat het systeem goed werkt. Hij lost haperingen op en andere klachten over de programmatuur. Ook realiseert hij wensen.
Functioneel systeembeheer beheert de functionele en gebruikersdocumentatie, behandelt vragen van gebruikers en inventariseert wensen voor wijzigingen. Gefiatteerde wensen worden doorgegeven aan technisch systeembeheer en na realisatie getest en geïmplementeerd.

Voor nieuwe wensen kan er een gebruikersgroep komen, waarvan ook de functioneel beheerder lid is. Deze groep inventariseert, prioriseert en fiatteert de wensen.

Goed beheer van documentatie houdt in deze fase in:

Een klachtenadministratie en een wensenadministratie, inclusief de stand van zaken en de manier van afhandeling.
Elke wijziging in het systeem moet worden opgenomen in de documentatie. Anders weet na verloop van tijd niemand meer hoe het precies zit en kost het later zeer veel tijd om uit te zoeken hoe nieuwe wensen inpasbaar zijn of hoe een klacht kan worden opgelost. Dat kan betekenen dat het gegevensmodel, functioneel ontwerp, de gebruikershandleiding en/of de technische documentatie moeten worden aangepast. Goed versiebeheer van de documentatie kan ervoor zorgen dat men gemakkelijk kan nakijken welke wijzigingen zijn doorgevoerd.

Fase VIII: Evaluatie

Als het informatiesysteem enkele maanden in gebruik is, is er een evaluatie. Deze stap wordt vaak vergeten, maar is wel essentieel. In hoofdzaak gaat het om de vragen: Wat ging er goed en wat moet een volgende keer anders? Bij een evaluatie zijn alle betrokkenen aanwezig. Geëvalueerd worden:

Het proces: zijn de juiste stappen genomen, zijn de juiste functionarissen erbij betrokken, waren de omgangsvormen naar wens, etc. Wat moet in de procedure worden aangepast voor volgende trajecten? Is het project binnen het budget en binnen de gestelde termijn opgeleverd? Wat zat er tegen? Zijn er stappen in het traject overgeslagen, zo ja: hoe heeft dat uitgepakt?
Het informatiesysteem: werkt het naar behoren, is dit wat ons voor ogen stond, hoe vaak zijn er klachten, welk soort klachten zijn er, etc.?

Na afloop verschijnt er een verslag. De uitkomsten zijn input voor volgende informatietrajecten en/of voor systeembeheer.

Externe links

Laat je voor de evaluatie inspireren door How projects really work (met waarschijnlijk copyright, dus niet geschikt voor Wikimedia Commons en daardoor ook niet voor Wikibooks)

Totstandkoming

Dit hoofdstuk is een samenvatting van de eigen kennis van de schrijvers, gebaseerd op eigen ervaringen, werkwijzen en aantekeningen van cursussen, aangevuld met informatie uit Wikipedia. Er is naar gestreefd om alles duidelijk uit te leggen. Als iets toch niet duidelijk is, kan dat op de overlegpagina aangegeven worden. Als u nog iets mist: Voeg het onderwerp op de juiste plek toe en maak zelf zo mogelijk een beschrijving, of vermeld het op de overlegpagina.