RISICOBEHEERSING IN IT PROJECTEN

RISICOBEHEERSING IN IT PROJECTEN

De ontwikkeling van een risicobeheersingsmodel

voor Ahrend IT Services BV

Auteur:

Ernst Keyzer

Studentnummer:

1141856

E-mail:

e.j.keyzer@student.rug.nl

Bedrijf:

Ahrend IT Services B.V.

Begeleiders RuG:

Fred van Blommestein

Thomas de Boer

Begeleiders Ahrend:

Bas Schoones

Robbert Dootjes

Versie:

2.0 (definitief)

Datum:

14 april 2006

Plaats:

Amsterdam

De auteur is verantwoordelijk voor de inhoud van het afstudeerverslag; het auteursrecht van het afstudeerverslag berust bij de auteur

sççêïççêÇ

sççêïççêÇ

sççêïççêÇ

sççêïççêÇ====

Dit afstudeerverslag is geschreven in het kader van de opleiding Technische Bedrijfsweten-schappen aan de Rijksuniversiteit Groningen, richting Informatie Technologie. De mogelijk-heid tot het schrijven van dit verslag is mij geboden door Ahrend IT Services BV, onderdeel van Koninklijke Ahrend NV.

Ik wil via deze weg een aantal mensen bedanken. Ten eerste de medewerkers van Ahrend voor hun bijdrage aan dit verslag. Het uitvoeren van een risicoanalyse is het resultaat van goed teamwork, dat is gelukt. Binnen Ahrend bedank ik in het bijzonder mijn begeleiders Bas Schoones en Robbert Dootjes voor hun bijdrage aan het onderzoek. Met Bas heb ik zo goed als wekelijks naar uiteenlopende zaken van het model gekeken, waardoor de term voort-schrijdend inzicht voor mij een geheel nieuwe dimensie heeft gekregen.

Mijn afstudeerbegeleiders Fred van Blommestein en Thomas de Boer wil ik bedanken voor de heldere inzichten en adviezen op de verschillende concepten. De bijeenkomsten met Fred op het stageadres hebben mij tijdens het onderzoek telkens weer geïnspireerd.

Tot slot bedank ik mijn ouders voor de enorme support tijdens de afstudeerperiode en niet te vergeten voor de continue support gedurende mijn studententijd. Zij hebben mij werkelijk alles gegeven wat nodig was om zo van mijn fantastische studententijd te kunnen genieten.

Amsterdam, april 2006, Ernst Keyzer

fåÜçìÇ

fåÜçìÇ

fåÜçìÇ

fåÜçìÇ====

= sllotlloa sllotlloasllotlloa sllotlloa... 1 fkelra fkelrafkelra fkelra... 2 S_{^jbks^qqfkd^jbks^qqfkd^jbks^qqfkd^jbks^qqfkd... 4} N NN N fkibfafkdfkibfafkd ... 6fkibfafkdfkibfafkd O OO O lod^kfp^qfb=ljp`eofglod^kfp^qfb=ljp`eofgsfkdlod^kfp^qfb=ljp`eofglod^kfp^qfb=ljp`eofgsfkdsfkdsfkd ... 7

2.1 ALGEMEEN... 7

2.2 AHREND INRICHTEN BV ... 8

2.3 MARKT... 9

2.4 AHREND ITSERVICES BV... 9

2.5 PROJECTEN BIJ AHREND... 10

P PP P _bp`eofgsfkd=lccboqb_bp`eofgsfkd=lccboqb=loabo=`lkcfdro^qlo=_bp`eofgsfkd=lccboqb_bp`eofgsfkd=lccboqb=loabo=`lkcfdro^qlo==loabo=`lkcfdro^qlo==loabo=`lkcfdro^qlo=`^pb`^pb`^pb`^pb... 13

3.1 WERKWIJZE VERKOOPCENTRA... 13 3.2 VARIËTEIT IN PRODUCTEN... 14 3.3 GRAFISCH OFFREREN... 15 3.4 GEÏNTEGREERD OFFREREN... 16 Q QQ Q mol_ibbjabcfkfqfbmol_ibbjabcfkfqfb ... 17mol_ibbjabcfkfqfbmol_ibbjabcfkfqfb 4.1 AFSTUDEEROPDRACHT... 17

4.2 PROBLEEMSTELLING... 17

R RR R lkabowlbhplmwbqlkabowlbhplmwbq... 19lkabowlbhplmwbqlkabowlbhplmwbq 5.1 RISICO... 19

5.2 RISICOMANAGEMENT... 20

5.3 OP TE LEVEREN MODEL... 20

5.4 WIJZE VAN AANPAK... 22

5.5 VALIDATIE... 23

5.6 REFERENTIECASE... 25

5.7 BEPERKINGEN VAN HET MODEL... 26

S SS S jlabi=lkqtfhhbifkdjlabi=lkqtfhhbifkd... 28jlabi=lkqtfhhbifkdjlabi=lkqtfhhbifkd 6.1 THEORETISCHE ONDERBOUWING... 28 SKNKN `çåÅÉéíìÉÉä=ãçÇÉä... 28 SKNKO dÉÄáÉÇÉå... 30 SKNKP `~íÉÖçêáÉØå... 33 SKNKQ ^å~äóëÉ... 34 SKNKR ^ÇîáÉëW=j~~íêÉÖÉäÉå... 37 SKNKS mäÉâ=áå=ÇÉ=éêçàÉÅíÑ~ëÉêáåÖ... 38 SKNKT táÉ=ÇçÉí=ï~í... 39 6.2 METHODE... 40 SKOKN pí~ééÉåéä~å... 40 SKOKO pí~é=NW=_ÉëÅÜêáàîÉå=sÉê~åÇÉêáåÖ... 41 SKOKP pí~é=OW=fÇÉåíáÑáÅÉêÉå=oáëáÅç... 43 SKOKQ pí~é=PW=^å~äóëÉêÉå=oáëáÅç... 45 SKOKR pí~é=QW=sççêëíÉääÉå=j~~íêÉÖÉäÉå... 48 SKOKS jÉíÜçÇÉ=ëÅÜÉã~íáëÅÜ... 51

6.3 WIJZE VAN TOEPASSING... 52

SKPKN oçääÉå... 52

SKPKO ^ÅíáîáíÉáíÉå... 54

SKPKP qáàÇ... 59

6.4 VALIDATIE VERSLAG... 62

T TT T ^k^ivpb=`^pb^k^ivpb=`^pb ... 65^k^ivpb=`^pb^k^ivpb=`^pb 7.1 STAP 1: BESCHRIJVEN... 65 7.2 STAP 2: IDENTIFICEREN... 66 7.3 STAP 3: ANALYSEREN... 72 7.4 STAP 4: VOORSTELLEN... 73 U UU U `lk`irpfbp=bk=^^k_bs`lk`irpfbp=bk=^^k_bsbifkdbk`lk`irpfbp=bk=^^k_bs`lk`irpfbp=bk=^^k_bsbifkdbkbifkdbkbifkdbk ... 74

8.1 ALGEMEEN... 74

8.2 RISICOBEHEERSING VAN DE OOC CASE... 75

8.3 RISICOBEHEERSING BIJ AHREND... 75

V VV V ibbomrkqbk=^cpqrabobibbomrkqbk=^cpqrabobkibbomrkqbk=^cpqrabobibbomrkqbk=^cpqrabobkk... 77k ifqbo^qrroifgpq ifqbo^qrroifgpqifqbo^qrroifgpq ifqbo^qrroifgpq ... 78 _fgi^dbk _fgi^dbk_fgi^dbk _fgi^dbk ... 80 BIJLAGE I:TEMPLATE 1 ... 80

BIJLAGE II:TEMPLATE 2... 85

BIJLAGE III:TEMPLATE 3 ... 88

BIJLAGE IV:TEMPLATE 4 ... 89

BIJLAGE V:VOORBEELDEN CHECKLISTS... 90

BIJLAGE VI:STANDAARD KOPPELING ASPECTEN EN SUBCATEGORIEËN... 94

BIJLAGE VII:OOCANALYSE (STAP 1&2)... 95

BIJLAGE VIII:OOCANALYSE (STAP 3&4) ... 99

S

S

S

S~ãÉåî~ííáåÖ

~ãÉåî~ííáåÖ

~ãÉåî~ííáåÖ

~ãÉåî~ííáåÖ====

Voor praktisch iedere verandering in organisatieprocessen wordt tegenwoordig een IT oplos-sing gebruikt. IT projecten zijn aan de orde van de dag. Dergelijke projecten vragen veel van zowel de betrokken business als IT personen en brengen uiteenlopende risico’s met zich mee. Koninklijke Ahrend NV is leverancier van kantoorinrichtingen en producent van kantoor-meubelen. Binnen de verkooporganisatie van Ahrend is een project gestart dat de account-manager instaat stelt om de klant een offerte te doen zonder tussenkomst van de backoffice- en tekenafdeling. Dit project heeft de naam Offerte Order Configurator (OOC) meegekregen. Een dergelijk project brengt uiteenlopende risico’s met zich mee. In dit onderzoek worden de risico’s van het OOC project in kaart gebracht. Bovendien wordt er een model ontwikkeld aan de hand waarvan in de toekomst risicobeheersing op de IT projecten van Ahrend kan worden toegepast. In het kader van het onderzoek is de volgende doelstelling geformuleerd:

Het doel van dit onderzoek is tweeledig:

1) het ontwerpen van een risicobeheersingsmodel voor complexe IT projecten met een grote im-pact op de organisatie aan de hand van het OOC project

2) het bepalen van de risico’s en de risicobeheersingsmogelijkheden van het OOC project aan de hand van het risicobeheersingsmodel

Vanuit de doelstelling heeft het onderzoek plaatsgevonden aan de hand van de volgende vraagstelling:

Wat zijn de risico’s van het OOC project en op welke wijze moet de risicoanalyse uitgevoerd wor-den zodat deze in de toekomst voor andere cases gebruikt kan worwor-den?

Het risicobeheersingsmodel is tot stand gekomen parallel aan het bepalen van de risico’s van het OOC project. Op basis van praktijkervaring van de betrokken Ahrend-medewerkers en risicomanagement literatuur is een model ontwikkeld. Tijdens de ontwikkeling heeft het OOC project als uitgangspunt gediend. Vervolgens is het model getest op algemene toepas-baarheid door het te valideren op een tweede case binnen Ahrend. De validatie heeft geleid tot een aantal wijzigingen in het model. De risicoanalyse van het OOC project is bijgesteld op het uiteindelijke model.

Tijdens het onderzoek viel op dat in de bestaande methoden en modellen om risico’s te be-heersen met name rekening gehouden wordt met risico’s die mogelijk optreden tijdens een project. De scope van het ontwikkelde risicobeheersingsmodel is breder. Tot de scope van dit model behoren ook de risico’s die het resultaat van het project bedreigen in de situatie die beoogd wordt.

Het ontwikkelde risicobeheersingsmodel bestaat uit twee onderdelen: de methode en de wij-ze van toepassing van de methode. De methode bestaat uit een stappenplan waarmee de fei-telijke risicoanalyse kan worden uitgevoerd. De wijze van toepassing beschrijft hoe met de methode moet worden omgegaan om risico’s daadwerkelijk te kunnen beheersen.

In de methode moeten vier stappen doorlopen worden. Achtereenvolgens zijn dit: beschrij-ven, identificeren, analyseren en voorstellen. Stap 1, bbbeschrijvenbeschrijveneschrijven, houdt in het beschrijven eschrijven van de huidige situatie, de verandering en de beoogde situatie. Het beschrijven gebeurt aan de hand van de gebieden: Omgeving, Cultuur, Technologie, Structuur en Processen. In stap 2, identidentidenti-identi-i- i-ficeren

ficerenficeren

ficeren, worden in de beschrijving uit stap 1 alle mogelijke risico’s geïdentificeerd. Hierbij worden de volgende risicocategorieën gehanteerd: Algemeen, Strategisch, Economisch, Organisato-risch en Technisch. De geïdentificeerde risico’s uit stap 2 worden geanalyseerd in stap 3, analanalanalanaly-y-y- y-seren

serenseren

seren. De risico’s krijgen een prioriteit mee, er wordt onderscheid gemaakt in kleine, middel en grote risico’s. In stap 4, voorstellenvoorstellenvoorstellenvoorstellen, worden voor de grote risico’s vervolgens maatregelen voorgesteld.

De wijze van toepassing bestaat uit de onderdelen: rollen, activiteiten en tijd. In het model worden, naast de reeds in het projectmanagement bestaande rollen, twee nieuwe rollen rollen rollen rollen geïn-troduceerd voor het uitvoeren van het model: de risicomanager en de deelnemers aan de risico-analyse. Om risicobeheersing toe te passen zijn in het model vier aaaactiviteitenctiviteitenctiviteiten benoemd: het ctiviteiten voorbereiden van de risicoanalyses, het uitvoeren van de risicoanalyses, het monitoren van de risico’s en de maatregelen en het evalueren van de risicobeheersing van het project. In het onderdeel tijd tijd tijd staat beschreven op welke momenten tijdens een project de risicoanalyse uit-tijd gevoerd moet worden. Het uitvoeren van een risicoanalyse moet meerdere malen per project gebeuren en de eerste analyse moet vroeg in het traject plaatsvinden.

De methode is gevalideerd door deze toe te passen op een tweede case binnen Ahrend. Het model is wegens tijdgebrek niet in zijn geheel gevalideerd. De wijze van toepassing is gecon-troleerd door de betrokken Ahrend-medewerkers, maar niet gevalideerd door toe te passen op een project. Dit leidt tot de belangrijkste aanbeveling met betrekking tot het risicobeheer-singsmodel: Pas het risicobeheersingsmodel toe op een project van het begin tot het eind. In het OOC project is de eerste risicoanalyse gedaan en is dus een goede aanleiding om het mo-del hier verder op toe te passen.

N

N

N

N fåäÉáÇáåÖ

fåäÉáÇáåÖ

fåäÉáÇáåÖ

fåäÉáÇáåÖ====

Tegenwoordig betekent het invoeren van een nieuwe werkwijze automatisch vaak ook de invoering van een technologische oplossing die de gebruiker in staat stelt om de nieuwe werkwijze toe te passen. Wijzigingen in organisatieprocessen en technologie gaan hand in hand. In dergelijke veranderingen speelt de discussie tussen de belangen van de business en die van de IT afdeling, zo ook bij Ahrend. Gedurende het onderzoek is regelmatig de opmer-king gevallen dat de technologie de motor onder de motorkap is. De motor moet gewoon starten en werken. Voor het gemak wordt wel eens vergeten dat je wel een 500 pk motor in een auto kan bouwen, echter wanneer de auto niet de juiste afstelling, banden, remmen en vering heeft, rijdt de auto voor geen meter. Bovendien is het niet onhandig te weten wat de bestuurder kan zien en doen om de motor te bedienen. Een andere beslissing is of de be-stuurder met de hand schakelt of juist automatisch? Tot slot van deze vergelijking is het niet onbelangrijk om te weten wanneer de tank leeg is en of er vervolgens benzine of diesel ge-tankt moet worden.

Wanneer gekeken wordt naar de risico’s van IT projecten is één van de grootste risico’s, zo niet het grootste risico, de afstemming van de verwachtingen die de business en de IT afde-ling hebben van de technologie. Wat moet de technologie doen en hoe ziet de situatie eruit waarin de technologie operationeel wordt? Dit verslag is een weergave van het onderzoek dat is gedaan naar het ontwikkelen van een risicobeheersingsmodel voor IT projecten. Het model is ontwikkeld op basis van een IT project dat gedurende de stageperiode gestart is bij Ahrend.

Dit verslag bevat 9 hoofdstukken welke als volgt verdeeld zijn:

De hoofdstukken 2, 3 en 7 hebben betrekking op het project bij Ahrend. In hoofdstuk 2 wordt een beschrijving van de organisatie Ahrend gegeven om begrip te verschaffen over dat deel van de organisatie waarop het onderzoek van toepassing is. In hoofdstuk 3 wordt het project waarop de afstudeeropdracht is gebaseerd toegelicht. Hoofdstuk 7 geeft de uitkomst van de risicoanalyse van de case.

De hoofdstukken 4, 5 en 6 hebben betrekking op de ontwikkeling van het risicobeheersings-model. In hoofdstuk 4 wordt de probleemdefinitie geschetst en staat hoe van de afstudeerop-dracht tot dit onderzoek is gekomen. In hoofdstuk 5 volgt de onderzoeksopzet en staat be-schreven op welke manier het onderzoek is aangepakt. In hoofdstuk 6 staat de modelontwik-keling beschreven.

In de hoofdstukken 8 en 9 tenslotte volgen de conclusies en aanbevelingen en staan de be-langrijkste leerpunten van de afstudeerstage vermeld.

O

O

O

O lêÖ~åáë~íáÉ=çãëÅÜêáàîáåÖ

lêÖ~åáë~íáÉ=çãëÅÜêáàîáåÖ

lêÖ~åáë~íáÉ=çãëÅÜêáàîáåÖ

lêÖ~åáë~íáÉ=çãëÅÜêáàîáåÖ====

Om een beeld te vormen van de omgeving waarin de afstudeerstage heeft plaats gevonden, wordt in dit hoofdstuk een omschrijving van Ahrend gegeven. De nadruk ligt hierbij op het voor de stage relevante deel van de organisatie. Ook wordt nader ingegaan op de manier waarop Ahrend met projecten omgaat.

OKN OKNOKN

OKN ^äÖÉãÉÉå^äÖÉãÉÉå====^äÖÉãÉÉå^äÖÉãÉÉå

Koninklijke Ahrend NV is een expert op het gebied van flexibele kantooroplossingen en effi-ciënt ruimtegebruik. Ahrend zorgt ervoor dat medewerkers professioneel, plezierig en pro-ductief kunnen werken door mooie en aangename werkomgevingen te creëren. Ahrend is wereldwijd actief als projectinrichter, zowel met eigen vestigingen als door succesvolle sa-menwerking met leidende marktpartijen. Het assortiment van Ahrend als ontwerper en pro-ducent van herkenbaar, tijdloos ‘Dutch design’-meubilair, omvat Revolt, Mehes, Ahrend 500, Ahrend 350, Ahrend 1200 en andere bekroonde stoelen, tafel- en opbergsystemen. Ahrend heeft meer dan een eeuw ervaring met het inrichten van zakelijke omgevingen.

Ahrend heeft sinds oktober 2005 een belang van 75% in haar alliantiepartner Techo. Met meer dan 150 medewerkers is Techo ondermeer actief in Tsjechië, Roemenië, Hongarije, Slowakije en Groot-Brittannië.

Ahrend heeft meer dan honderd jaar zowel kantoorartikelen als kantoorinrichtingen aan haar klanten geleverd. Tijdens de stage periode heeft Koninklijke Ahrend NV de kantoorartikelen divisie verkocht aan het Franse Lyreco. Sindsdien richt Ahrend zich volledig op de productie en verkoop van kantoorinrichtingen en is Koninklijke Ahrend NV een pure furniture onderneming geworden.

Ahrend hanteert de volgende missie (deze is letterlijk overgenomen van de website van Ah-rend): Ahrend wil een internationale topspeler zijn voor de werkomgeving. Door goed te luis-teren naar onze klanten en door constant te leren, ontwikkelen we ons tot experts van de

werkomgeving. Zo weten we wat organisaties en medewerkers nodig hebben om succesvol te kunnen functioneren, voor nu en in de toekomst. We realiseren de gewenste werkomgeving met een doordacht aanbod van inrichtingsadvies en kantoormeubilair. Zo nemen we onze klanten uit het bedrijfsleven, het onderwijs, de zorgsector en de overheid alle zorgen uit handen met duurzame en doordachte oplossingen. Dat betekent dat wij de juiste balans vin-den tussen advies, full service en meubels die hoogwaardig en tijdloos design combineren met functionaliteit, ergonomie en kwaliteit.

OKO OKOOKO

OKO ^ÜêÉåÇ=fåêáÅÜíÉå=_s^ÜêÉåÇ=fåêáÅÜíÉå=_s====^ÜêÉåÇ=fåêáÅÜíÉå=_s^ÜêÉåÇ=fåêáÅÜíÉå=_s

Ahrend bestaat uit een productie- en een verkoopdivisie. De productiedivisie omvat een twee-tal fabrieken: één in Sint-Oedenrode waar voornamelijk kasten en bureaus worden geprodu-ceerd en één in Zwanenburg waar onder andere de bureaustoelen vandaan komen. De ver-koopdivisie verkoopt de door de fabrieken geproduceerde Ahrend producten via directe en indirecte kanalen. Indirecte kanalen zijn dealerorganisaties en allianties, in Duitsland wordt bijvoorbeeld via dealerorganisaties verkocht en in de Verenigde Staten heeft Ahrend een alli-antie met Allsteel. De verkoopcentra verkopen zowel Ahrend producten, als producten van derde leveranciers direct aan de eindgebruiker. De verkoopcentra bestellen rechtstreeks bij de fabrieken, bij indirecte verkoop wordt via Ahrend International of via landenorganisaties besteld.

De afstudeerstage heeft betrekking op een case die speelt bij de Nederlandse verkoopcentra. Deze zijn ondergebracht in Ahrend Inrichten BV, de Nederlandse verkoopmaatschappij. In-richten BV is onderverdeeld in de Sales en Sales-support. Sales bestaat uit de Buitendienst en Sales-support bestaat uit de Binnendienst en de Studio. Nederland is onderverdeeld in drie regio’s, in de regio’s bevinden zich drie tot zes verkoopcentra. Sales en Sales-support worden regionaal aangestuurd.

Ahrend Inrichten BV is totaalinrichter, dat wil zeggen dat de inrichting van gebouwen en/of ruimtes volledig door de klant aan Ahrend over gelaten kan worden. Ahrend levert naast de meubelen alles wat nodig is voor de inrichting. Scheidingswanden, verlichting, stoffering etcetera worden bij derde leveranciers ingekocht. Derde leveranciers waar Ahrend vaak zaken mee doet worden ook alliantie partners genoemd. Dit is een ander niveau van samenwerking dan de alliantie partners die in bovenstaande alinea worden bedoeld. Hier worden leveran-ciers bedoeld waarbij Ahrend op regelmatige basis producten bestelt die buiten het eigen assortiment vallen. Ahrend functioneert in dergelijke projecten als hoofdaannemer. Ahrend biedt niet alleen stoelen, bureaus en kasten, maar ook de bij de totale inrichting behorende diensten, inclusief interieuradvies

OKP OKPOKP

OKP j~êâíj~êâí====j~êâíj~êâí

Een bedrijf als Ahrend is erg afhankelijk van het economisch klimaat. Gaat het slecht met de economie, dan krijgt een investering in meubilair al snel een lagere prioriteit. Op dit moment lijkt er, nadat er enige jaren sprake van een dal was, sprake te zijn van een opkrabbelende economie hetgeen kansen biedt voor Ahrend. Een kans op snelheid in een aantrekkende markt is het feit dat door de recessie een groot aantal kantoorgebouwen is leeg komen te staan en dat wanneer deze weer verhuurd worden ze ook vaak snel weer kunnen worden ingericht, zonder dat er eerst opnieuw gebouwd moet worden.

In de markt voor kantoorinrichting speelt een aantal ontwikkelingen. Een daarvan is die van de flexibilisering. Steeds meer worden vaste werkplekken vervangen door flexibele, dyna-misch ingerichte werkplekken. Een andere ontwikkeling is de toenemende customisatie. De inrichting bepaalt deels de identiteit van de organisatie. De inrichting moet zich onderschei-den van die van de concurrent. Een volgende ontwikkeling is de wijziging van de schaal van opdrachten, aan de ene kant komen er steeds meer kleine opdrachten en aan de andere kant worden de grote opdrachten steeds groter. De laatste ontwikkeling die hier genoemd wordt is het feit dat in tijden waarin de grafische mogelijkheden oneindig lijken de klant ook hogere eisen aan het grafische aspect van de offerte en het advies stelt.

Ahrend benadert de markt in segmenten. Men maakt onder andere onderscheid in de seg-menten mkb, overheid, onderwijs en zorg & welzijn. In de sector onderwijs is Ahrend markt-leider en in zorg & welzijn sterk groeiende. In de traditionele kantoorinrichting heeft Ahrend eveneens een sterke positie. Naast een groot aantal kleine concurrenten zijn de belangrijkste concurrenten binnen de Benelux Gispen en Samas, beide ook Nederlandse bedrijven,

OKQ OKQOKQ

OKQ ^ÜêÉåÇ=fq=pÉêîáÅÉë=_s^ÜêÉåÇ=fq=pÉêîáÅÉë=_s====^ÜêÉåÇ=fq=pÉêîáÅÉë=_s^ÜêÉåÇ=fq=pÉêîáÅÉë=_s

Ahrend IT Services (ITS) is de centraal georganiseerde IT afdeling van de Koninklijke Ahrend NV en is verantwoordelijk voor een drietal gebieden: infrastructuur en werkplekken, business applicaties en CAD applicaties.

Wat betreft de infrastructuur is ITS belast met het beheer van de technische platformen waar de business units hun automatiseringssystemen op hebben ingericht. Daarnaast is ITS belast met het beheer van alle werkplekken ten behoeve van de kantoorautomatisering, inclusief netwerken, data opslag en telefonie.

De verantwoordelijkheid van het functionele beheer van de primaire applicaties ligt binnen ITS bij Business Application Management. Primaire applicaties zijn het ERP systeem van Ah-rend, zowel Sales als Productie, met al zijn randapplicaties. ERP staat voor Enterprise

Resour-ce Planning, dit is het computerprogramma dat helpt de administratieve zaken van een orga-nisatie te beheren. Het functionele beheer van de CAD applicaties gebeurt door een aparte CAD afdeling binnen ITS.

De primaire functie van ITS is het beheren van de hierboven beschreven gebieden en wan-neer er incidenten optreden deze op te lossen. ITS heeft ook een secundaire functie, deze bestaat uit het adviseren van de business bij ICT investeringen en het deelnemen aan IT gere-lateerde projecten. Is er in één van de onderdelen van Ahrend een IT investering nodig, dan brengt ITS, aan de hand van onder andere een door alle partijen goedgekeurde businesscase een advies uit over de beste oplossing.

OKR OKROKR

OKR mêçàÉÅíÉå=Äáà=^ÜêÉåÇmêçàÉÅíÉå=Äáà=^ÜêÉåÇ====mêçàÉÅíÉå=Äáà=^ÜêÉåÇmêçàÉÅíÉå=Äáà=^ÜêÉåÇ

In de voorgaande alinea is gesproken over de adviserende functie van ITS en over de moge-lijkheid van projectdeelname door ITS. In de aanloop van een project heeft ITS een adviseren-de rol en wanneer het een technologisch ingewikkeladviseren-de oplossing betreft wordt ITS lid van het projectteam.

Er bestaat een groot aantal definities van het begrip project. Een project wordt in de regel gedefinieerd als een, in de tijd begrensde, activiteit om iets te creëren. Om bij Ahrend een officieel project te starten wordt een Project Initiatie Document opgesteld. In de aanloop van een project wordt vaak een businesscase opgesteld welke uiteindelijk leidt tot het daadwerke-lijke project. De businesscase wordt dan vaak in de wandelgangen al project genoemd, terwijl het feitelijke project bijvoorbeeld de pilot of de uitrol van de oplossing is. Om verwarring te voorkomen wordt er in dit onderzoek over een project gesproken wanneer er bij Ahrend sprake is van een officieel project. Het traject voorafgaand aan een project wordt het voortra-ject genoemd. Voortravoortra-ject en provoortra-ject samen zijn de case.

Tijdens het voortraject worden belangrijke keuzes gemaakt met betrekking tot het project. Vragen als: hoe gaat de oplossing eruit zien en wie wordt de software leverancier van de op-lossing, worden hier beantwoord. Er is geen officiële fasering van het voortraject voorhanden, wel zijn bepaalde elementen bekend die bij projecten en tijdens het voortraject worden op-geleverd. Omdat in dit onderzoek dergelijke fasering wel noodzakelijk is wordt hier een in-terpretatie gegeven van de fasering van de projecten met het voortraject.

In de eerste fase vertaalt ITS een behoefte die vanuit de business ontstaat naar de IT invulling via bestaande oplossingen of met behulp van nieuwe oplossingen. Met andere woorden: ITS zoekt een IT oplossing voor de behoefte uit de business. Het vaststellen van de behoefte beurt tijdens het opstellen van een businesscase. In een voorstudie wordt een eerste stap ge-zet in het zoeken naar mogelijke oplossingen. Wanneer business en ITS gezamenlijk een

op-Figuur 2: Fasering van projecten bij Ahrend

Fase I initiatie & definitie Fase II inventarisatie & selectie Fase III realisatie

Project Initiation Document Closure Document Project Plan Progress Report Change Request Functionele Beschrijving Voorstudie Business Case

Request For Information

Request For Proposal

Leveranciers Selectie Investeringsaanvraag

Detail Ontwerp

Proof Of Concept

Fase I

Fase II

Fase III

Deliverable voortraject Projectmanagement deliverable

lossingsrichting hebben gevonden wordt eerst een beschrijving opgesteld van de functionele eisen die aan de oplossing gesteld worden. De eerste fase wordt in dit onderzoek initiatie en definitie fase genoemd.

In de tweede fase, inventarisatie en selectie, kan een aantal leveranciers gevraagd worden of men technisch in staat is de gewenste oplossing te leveren, dit gebeurt door het uitbrengen van een Request For Information (RFI). Het uitbrengen van een RFI gebeurt wanneer een op-lossing ingekocht moet worden. Op de RFI volgt de Request For Proposal (RFP), een selectie van de leveranciers die positief op de RFI heeft geantwoord wordt gevraagd een aanbod te doen aan de hand van de RFP. Op basis van deze voorstellen kan de uiteindelijke leveranciers-selectie plaatsvinden. Nadat de investeringsvraag is goedgekeurd kan de case officieel een project worden. Niet ITS, maar de business is opdrachtgever, doet zodoende de investerings-aanvraag en betaalt in die hoedanigheid voor de oplossing. In deze fase wordt de algemene definitie van het project opgesteld in een project voorstel, waarin de haalbaarheid wordt ver-antwoord. Dit gebeurt in het Project Initiation Document.

De derde fase die in dit onderzoek wordt onderscheiden is de realisatie fase. In deze fase wordt vanuit het functionele ontwerp een detail ontwerp gemaakt. De algemene specificatie van de vereisten, resources, planning en budgetten worden in het Projectplan vastgesteld. In deze fase kan de leverancier gevraagd worden om een Proof of Concept. Voordat er echt aan de oplossing gebouwd wordt laat de leverancier eerst zien dat de technologie ook in de Ah-rend situatie werkt. Indien er sprake is van een technologisch ingewikkelde en / of vernieu-wende oplossing kan de leverancier overigens ook in een eerdere fase gevraagd worden om

een Proof of Concept, meestal gebeurt dit dan in fase twee. De plek van de Proof of Concept in het traject hangt dus af van de technologie. In fase drie wordt ontwikkeld, gebouwd en uiteindelijk getest, alles wordt weer gerapporteerd in het Progress Report. Indien nodig kan via de Change Request een wijziging in het project worden aangevraagd. Tenslotte wordt het Closure Document opgesteld waarin nazorg wat betreft gebruik, beheer en onderhoud van de systemen wordt vastgelegd. Binnen deze fase zijn in het project zelf ook weer fasen te her-kennen, namelijk: initiatie, ontwerp, bouw en implementatie.

In Figuur 2 staat de fasering schematisch weergegeven. In de ovalen staan de deliverables uit het voortraject en in de rechthoeken de project deliverables weergegeven. In dit onderzoek wordt ervan uitgegaan dat iedere case deze drie fases doorloopt. In de praktijk worden niet alle elementen uit de fasering gebruikt en blijkt dat de werkwijze niet altijd in zijn volledig-heid wordt gehanteerd. Het komt voor dat bepaalde elementen met name in het voortraject worden overgeslagen of gecombineerd. Het gebruik maken van verschillende elementen ge-beurt naar behoefte. De toepassing van de verschillende elementen is afhankelijk van facto-ren als complexiteit, impact en grootte van de case.

P

P

P

P _ÉëÅÜêáàîáåÖ=lÑÑÉêíÉ=lêÇÉê=`ç

_ÉëÅÜêáàîáåÖ=lÑÑÉêíÉ=lêÇÉê=`ç

_ÉëÅÜêáàîáåÖ=lÑÑÉêíÉ=lêÇÉê=`ç

_ÉëÅÜêáàîáåÖ=lÑÑÉêíÉ=lêÇÉê=`çå

å

å

åÑáÖìê~íçê=Å~ëÉ

ÑáÖìê~íçê=Å~ëÉ

ÑáÖìê~íçê=Å~ëÉ

ÑáÖìê~íçê=Å~ëÉ====

De Offerte Order Configurator (OOC) businesscase is de aanleiding tot de afstudeeropdracht. Deze case betreft een op handen zijnde verandering bij Ahrend Inrichten BV. Dit hoofdstuk geeft een beschrijving van de OOC businesscase. De vertaling van de afstudeeropdracht naar de doelstelling van dit onderzoek omvat echter meer dan enkel de OOC case, hierover meer in hoofdstuk 4.

PKN PKNPKN

PKN tÉêâïáàòÉ=îÉêâççéÅÉåíê~tÉêâïáàòÉ=îÉêâççéÅÉåíê~====tÉêâïáàòÉ=îÉêâççéÅÉåíê~tÉêâïáàòÉ=îÉêâççéÅÉåíê~

De case heeft betrekking op het offerte proces van de verkoopcentra van Ahrend. In de huidi-ge werkwijze onderhoudt de medewerker Buitendienst (de accountmanahuidi-ger) het contact met de klant. Hij of zij verkoopt de producten en diensten van Ahrend aan de hand van de catalo-gi en eventueel een showroom bezoek. Buitendienst is onderdeel van Sales en Binnendienst en Studio horen bij Sales-support. Binnendienst beheert de klantgegevens, zorgt ervoor dat de bestelling bij de fabrieken terechtkomt en doet indien nodig de bestelling bij derde leveran-ciers. Naast de orderverwerking zijn medewerkers Binnendienst verantwoordelijk voor de administratieve projectondersteuning en de facturering. Bij grotere projecten, wordt de Stu-dio ingeschakeld. De StuStu-dio-medewerker maakt een ontwerp van de inrichting en toont dit aan de klant door middel van een plattegrond en 2d en 3d presentaties. In de Studio valt on-derscheid te maken tussen interieur architecten en tekenaars, de architecten adviseren over een inrichting en de tekenaars zetten door de Buitendienst gemaakte schetsen van inrichtin-gen om in een digitale tekening.

Een klant neemt op basis van de offerte een beslissing. Een dergelijk offerte is opgebouwd uit een aantal onderdelen. Een van die onderdelen is klantgegevens. Naast naam, adres, woon-plaats gegevens, contactpersonen en dergelijke behoren tot de klantgegevens ook afspraken over financiële zaken. Zaken als kredietwaardigheid en betalingstermijnen zijn per klant verschillend. In de branche is het vanzelfsprekend dat er met flinke kortingen op de offertes wordt gewerkt. De kortingspercentages kunnen ook per klant verschillen, bovendien kan bij een klant een afwijkend kortingspercentage gelden voor bijvoorbeeld een bepaalde product-lijn van Ahrend, deze percentages zijn ook onderdeel van de klantgegevens.

Een ander onderdeel van de offerte zijn de te leveren artikelen en diensten. Artikelen kunnen standaard items, maar ook klantspecifieke items zijn. De klantspecifieke items kunnen een variant op een bestaand product of een nieuw product zijn. Het kunnen artikelen uit de Ah-rend fabrieken zijn, maar ook artikelen van derde leveranciers. De diensten kunnen het ont-werpen van een klantspecifiek meubel (bijvoorbeeld een balie), het monteren, het aanleggen van kabels en dergelijke zijn. Van zowel de artikelen als de diensten staat een omschrijving, prijs en korting vermeld. Offertes van kleine projecten bestaan uit bovenstaande onderdelen.

Bij grote projecten worden de offertes vergezeld van een tekening en in sommige gevallen een presentatie van de inrichting.

Voordat een klant uiteindelijk een officiële offerte ontvangt wordt eerst een traject doorlo-pen. Een eerste uiting naar de klant is meestal een indicatie of begroting die de accountma-nager doet op basis van de standaard prijzen van het assortiment, hierbij wordt geen reke-ning gehouden met klantspecifieke kortingen en betalingstermijnen. Op deze manier hoeft niet geschakeld te worden met de Binnendienst om via het ERP systeem een officiële offerte te krijgen en kan de accountmanager sneller de klant een aanbieding doen. Echter beschikt de accountmanager, en daarmee de klant, vaak niet over correcte informatie. Wanneer voor een offerte van een inrichting ook een tekening nodig is duurt het proces nog langer, dan moet de Studio ingeschakeld worden. Het uitbrengen van een officiële offerte duurt nu onge-veer 8 tot 10 werkdagen. Wanneer een klant de offerte accepteert wordt deze door de Bin-nendienst omgezet in een order. Voordat de order is aangemaakt is de offerte vaak al een aantal keren gewijzigd.

PKO PKOPKO

PKO s~êáØíÉáí=áå=éêçÇìÅíÉås~êáØíÉáí=áå=éêçÇìÅíÉå====s~êáØíÉáí=áå=éêçÇìÅíÉås~êáØíÉáí=áå=éêçÇìÅíÉå

Kantoormeubilair wordt opgebouwd uit componenten, die binnen de diverse productlijnen zeer kunnen verschillen. Bij een stoel bijvoorbeeld kan binnen een modellijn de keuze ge-maakt worden voor verschillende soorten (materialen/kleuren) onderstellen, armleggers, be-kleding, etcetera. In een brochure of prijslijst kunnen natuurlijk moeilijk alle mogelijke combinaties staan afgebeeld. In andere branches waar dergelijke variëteit in producten voor-komt maakt men reeds gebruik van grafische samenstelingsprogramma’s. Neem bijvoorbeeld de auto-industrie: klanten kunnen op de website van de fabrikanten naar eigen wensen een auto virtueel samenstellen. Ook binnen Ahrend gaat men er van uit dat een grafisch pro-gramma effectiever is dan een statische brochure. Het is op die manier veel makkelijker om de verschillende mogelijkheden in te vullen. Gezien het grote aantal verschillende mogelijk-heden staan in een statische brochure slechts voorbeelden van producten afgebeeld. Het komt zelden voor dat een product precies volgens de voor de klant gewenste specificaties in de brochure staat afgebeeld. Het grafische proces wordt bij Ahrend nu ondersteund door middel van een tekenprogramma bij de Studio, hiervoor is bepaalde expertise en zijn speci-fieke vaardigheden vereist. Het maken van een tekening van de inrichting gebeurt echter alleen voor grote projecten. Voor ieder artikel moeten vervolgens de specificaties bij de fa-briek bekend zijn om uiteindelijk het juiste product te leveren. Hiervoor wordt het ERP sys-teem gebruikt waar door middel van een vraag-en-antwoord-procedure de specificaties wor-den vastgesteld.

Vanwege de vele schakels in het proces en de variëteit in producten is de kans op fouten groot. Een grafische weergave van hetgeen geleverd moet worden, in combinatie met een

geïntegreerd proces zou er aan bij kunnen dragen dat er in het traject minder fouten optre-den. Wanneer er altijd een grafische weergave is van hetgeen geleverd moet worden, en deze weergave bovendien gekoppeld is aan de juiste gegevens uit het ERP systeem kan er winst geboekt worden. Wanneer de keuzes eerder in het offertetraject juist worden gemaakt zijn minder wijzigingen nodig. Daarnaast gaat het bij een offerte om het binnenhalen van een order van een nieuwe of reeds bestaande klant. Door altijd een uitgebreide (grafische) offerte te bieden en het offerteproces snel en vlekkeloos te laten verlopen worden de kansen ver-groot om de klant over de streep te trekken om tot een order over te gaan.

PKP PKPPKP

PKP dê~ÑáëÅÜ=çÑÑdê~ÑáëÅÜ=çÑÑêêêêÉêÉå=dê~ÑáëÅÜ=çÑÑdê~ÑáëÅÜ=çÑÑÉêÉå=ÉêÉå=ÉêÉå=====

Door het doen van grafische offertes worden zowel intern als extern de kansen op fouten in de offerte verminderd. Voor zowel klanten als Sales en Sales-support geldt: what you see is what you get. Bovendien maakt de grafische component de offerte visueel aantrekkelijker voor de klant. Via de Duitse dealerorganisatie is Ahrend, min of meer bij toeval in aanraking gekomen met een bibliotheektaal die het grafisch offreren mogelijk maakt.

In Duitsland is in samenwerking met de kantoormeubelen branchevereniging een standaard-taal ontwikkeld waarin kantoormeubelen kunnen worden gespecificeerd en weergegeven. Deze taal wordt Office Furniture Modelling Language genoemd, kortweg OFML. Meubelen zijn grafisch opgemaakt en technisch gespecificeerd in dezelfde bibliotheekstandaard. Ahrend is gestart met het OFML programma door voor de Duitse dealerorganisatie het assortiment in OMFL bibliotheekformaat beschikbaar te stellen. Vanuit de branchevereniging VSM is, onder meer op initiatief van Ahrend, OFML als bibliotheekstandaard voor kantoormeubilair in Ne-derland geïntroduceerd. Ook concurrent Samas is bezig met de implementatie van OFML in haar offerteproces. Ahrend ziet OFML primair als een bibliotheektaal en een structuur om het assortiment in op te maken. Secundair spelen de mogelijkheden om de OFML toepassingsap-plicaties in te zetten.

De presentaties van Ahrend behoren, naar eigen zeggen, op dit moment tot de beste van de markt. Er worden offertes gedaan van hoogwaardige kwaliteit in zowel 2d, 3d, als video. Doordat dit een tijdrovend proces is, gebeurt dit enkel voor grote projecten; kleinere projec-ten, de inrichting van één kamer bijvoorbeeld, moeten het vaak doen met een handgemaakte schets door de accountmanager. Een dergelijke schets moet vervolgens voorzien worden van de juiste productgegevens. In de verkooporganisatie groeit de vraag naar visuele presentaties en visuele middelen om ook voor kleinere projecten de producten eenvoudig en snel aan de klant te kunnen presenteren. Met name het afbeelden van het te leveren product in de ge-wenste samenstelling in de offerte is gewenst.

PKQ PKQPKQ

PKQ dÉ≥åíÉÖêÉÉêÇ=çÑÑêÉêÉådÉ≥åíÉÖêÉÉêÇ=çÑÑêÉêÉå====dÉ≥åíÉÖêÉÉêÇ=çÑÑêÉêÉådÉ≥åíÉÖêÉÉêÇ=çÑÑêÉêÉå

In het kader van het integreren van het offerte proces is er voor gekozen om gebruik te ma-ken van de OFML applicaties. Deze applicaties bieden de mogelijkheid om aan de afbeeldin-gen van de producten de bijbehorende specificaties te koppelen en hier vervolafbeeldin-gens mee te combineren. Als een bepaalde stoel bijvoorbeeld niet met een chromen onderstel te leveren is, dan is dit in deze applicatie ook niet mogelijk. In de huidige situatie kan het gebeuren dat in de handgemaakte schets een stoel wordt getekend, waarbij de opmerking wordt geplaatst dat het onderstel chroom moet zijn, terwijl dit productietechnisch onmogelijk is. Er zijn in de applicatie enkel combinaties mogelijk die ook daadwerkelijk geleverd kunnen worden. Dit betekent overigens niet dat om OFML te gebruiken ook het gehele proces geïntegreerd dient te worden. OFML kan ook enkel als bibliotheekstandaard gebruikt worden om de uitwissel-baarheid van assortimentsbibliotheken, bijvoorbeeld op de dealermarkt, te bevorderen. OFML biedt dus per definitie wel mogelijkheden om verschillende afdelingen met dezelfde informa-tie te laten werken.

In de huidige situatie werken Binnen-, Buitendienst en Studio afzonderlijk met verschillende informatiebronnen. Voordat een offerte daadwerkelijk gedaan kan worden moeten de klant-gegevens uit het ERP systeem worden verkregen. Schetsen worden gemaakt door de Buiten-dienst, tekeningen van grotere projecten door de Studio en de Binnendienst moet daar steeds de juiste productgegevens aan koppelen.

Integratie van deze processen zou tot een aantal voordelen leiden:

- Het versnelt de processen, het stelt de accountmanager in staat eenvoudige (digi-tale) tekeningen te laten maken, welke zijn gekoppeld aan de juiste productgege-vens.

- De offerte wordt vanuit de tekening opgevoerd, wat leidt tot minder fouten, het product staat grafisch afgebeeld op het scherm en is direct gekoppeld aan de pro-ductspecificaties uit het ERP systeem.

- De afbeeldingen maken gebruik van stamgegevens, waardoor producten alleen zo te configureren en samen te stellen zijn zoals ze ook geleverd kunnen worden.

Q

Q

Q

Q mêçÄäÉÉãÇÉÑáåáíáÉ

mêçÄäÉÉãÇÉÑáåáíáÉ

mêçÄäÉÉãÇÉÑáåáíáÉ

mêçÄäÉÉãÇÉÑáåáíáÉ====

In hoofdstuk 4 wordt toegelicht hoe van de door Ahrend geformuleerde afstudeeropdracht tot een wetenschappelijk verantwoorde probleemstelling is gekomen.

QKN QKNQKN

QKN ^ÑëíìÇÉÉêçéÇê~ÅÜí^ÑëíìÇÉÉêçéÇê~ÅÜí====^ÑëíìÇÉÉêçéÇê~ÅÜí^ÑëíìÇÉÉêçéÇê~ÅÜí

Binnen Ahrend Inrichten BV staat men aan de start van een project dat de automatisering en integratie van het offerteproces realiseert en hierbij een technologie gebruikt die beschikt over voldoende grafische mogelijkheden. Met dit als doel is een businesscase opgesteld. Het betreft een omvangrijke verandering die diverse onderdelen van de organisatie raakt; een businesscase derhalve met uiteenlopende risico’s op verschillende gebieden. Allereerst moe-ten de risico’s zoveel mogelijk herkend worden om vervolgens zoveel mogelijk ingeperkt te kunnen worden.

In het kader van de risico’s van de veranderingen is door Ahrend ITS een afstudeeropdracht geformuleerd: “Voer een risicoanalyse uit ten aanzien van de verwachte veranderingen. Be-steed hierbij minimaal aandacht aan de factoren bedrijfszekerheid, -continuïteit en accepta-tie”. In het begin van de afstudeerperiode is daarnaast de wens ontstaan om een algemeen risicomodel te ontwikkelen. Het enkel uitvoeren van een case specifieke risicoanalyse is niet voldoende voor de wetenschappelijke aanpak die vereist is voor het afstuderen. Het ontwik-kelen van een algemeen risicomodel dat op meerdere cases toegepast kan worden is dat wel. De risicoanalyse dient dus op een dergelijke manier te worden uitgevoerd dat deze als voor-beeld kan dienen voor het bepalen van het risico van toekomstige IT projecten binnen Ah-rend.

QKO QKOQKO

QKO mêçÄäÉÉãëíÉääáåÖmêçÄäÉÉãëíÉääáåÖ====mêçÄäÉÉãëíÉääáåÖmêçÄäÉÉãëíÉääáåÖ

Volgens De Leeuw (2001) is de functie van een probleemstelling tweeledig: afstemming met de klant en de interne sturing van het onderzoek. Een probleemstelling bestaat volgens De Leeuw (2001) uit een drietal componenten. De doelstelling legt vast voor wie het onderzoek gedaan wordt, wat er voor hen uitkomt en waarom dat voor hen van belang is. De vraagstel-ling formuleert de hoofdvraag die bij de doelstelvraagstel-ling aansluit maar in voor onderzoek toegan-kelijke termen is geformuleerd. De randvoorwaarden tenslotte geven de beperkingen aan waaraan onderzoeksresultaten en methoden onderhevig zijn. Vanuit de afstudeeropdracht is de volgende probleemstelling geformuleerd:

Doelstelling:

Het doel van dit onderzoek is tweeledig:

1) het ontwerpen van een risicobeheersingsmodel voor complexe IT projecten met een grote impact op de organisatie aan de hand van het OOC project

2) het bepalen van de risico’s en de risicobeheersingsmogelijkheden van het OOC project aan de hand van het risicobeheersingsmodel

Vraagstelling:

Wat zijn de risico’s van het OOC project en op welke wijze moet een risicoanalyse uit-gevoerd worden zodat deze in de toekomst voor andere cases gebruikt kan worden?

Randvoorwaarden:

- Het onderzoek zal in een tijdsbestek van ongeveer 6 maanden worden uitgevoerd - Hoewel de oplossing theoretisch wordt onderbouwd, is deze vooral praktisch bruikbaar - Het eindproduct wordt gerapporteerd in de vorm van een scriptie

- Het model zal binnen het onderzoek getoetst worden aan de hand van de case uit de af-studeeropdracht en een relevante referentiecase

R

R

R

R låÇÉêòçÉâëçéòÉí

låÇÉêòçÉâëçéòÉí

låÇÉêòçÉâëçéòÉí

låÇÉêòçÉâëçéòÉí====

Dit hoofdstuk begint met het verklaren van een aantal begrippen. Vervolgens wordt de wijze van aanpak van het onderzoek uiteengezet. De wijze waarop validatie van de methode plaats heeft gevonden wordt uitgebreid besproken. Het hoofdstuk eindigt met het benoemen van een aantal beperkingen van het model.

RKN RKNRKN

RKN oáëáÅçoáëáÅç====oáëáÅçoáëáÅç

Wat is nu eigenlijk een risico en wat wordt er in dit onderzoek onder verstaan? De betekenis van het woord risico is volgens de Van Dale gevaar voor schade of verlies. In de wetenschap wordt risico vaak gedefinieerd als de kans dat een negatieve gebeurtenis optreedt vermenig-vuldigd met de impact van de gevolgen van deze gebeurtenis (risico = kans x impact). Wan-neer in projectmanagement wordt gesproken over risico betreft dit in de regel de risico’s die het project bedreigen. Risico’s die de business bedreigen blijven veelal onbesproken. De risi-co’s die kleven aan het doel van het project, het eindproduct, vallen meestal buiten de analy-se. Zo definiëren Gevers en Hendrickx (2001) een projectrisico als volgt: Het mogelijk optre-den van een ongewenste en ongeplande gebeurtenis in de toekomst, waarvan de gevolgen het bereiken van de projectresultaten en of doelstellingen geheel of gedeeltelijk kunnen bedrei-gen. Er wordt in dit onderzoek niet

alleen gekeken naar de risico’s die het bereiken van de projectresultaten bedreigen, maar ook worden de risi-co’s die de business na afronding van het project bedreigen in kaart ge-bracht.

In dit onderzoek wordt een

zoge-naamde ist-soll beschrijving gemaakt, de case wordt in de huidige situatie, de verandering en de beoogde situatie beschreven (zie Figuur 3). In de bestaande risicomethoden is de scope van de risicoanalyse de verandering. In de risicoanalyse uit dit onderzoek is de scope breder en wordt ook rekening gehouden met mogelijke risico’s in de beoogde situatie. In dit onderzoek worden twee soorten risico’s onderscheiden: Gebeurtenissen met een negatief effect in de beoogde situatie en gebeurtenissen tijdens de verandering die een negatief effect hebben op het resultaat van de case.

- Gebeurtenissen met een negatief effect in de beoogde situatie: In de vorige alinea staat al dat het doel van het project tot de analyse behoort, dit is in principe de beoogde situatie. Het gaat echter te ver om in de risicoanalyse de beoogde situatie als geheel mee te ne-men, dat zou meer gaan lijken op een beoordeling van de risico’s van de strategie van

Ah-Verandering Huidige

Situatie

Beoogde Situatie

Scope bestaande methoden

Scope risicobeheersingsmodel

rend. De basis van dit onderzoek is de verandering, in hoeverre verandert, of wil men dat de beoogde situatie verandert ten opzichte van de huidige situatie. Er moet gecontroleerd worden of het risico in de beoogde situatie niet ook al gold in de huidige situatie. Voor een deel zijn de risico’s in de huidige situatie de aanleiding tot het project, deze situatie wil je immers verbeteren.

- Gebeurtenissen tijdens de verandering die een negatief effect hebben op het resultaat van de case: Het project is onderdeel van de weg naar de beoogde situatie toe. De bedreigin-gen die op deze weg op kunnen treden moeten in de risicoanalyse meebedreigin-genomen worden mits de risico’s een effect hebben op het resultaat van het project in de beoogde situatie. Onder de risico’s die optreden tijdens de verandering vallen ook risico’s die de organisatie loopt omdat zij zich in een veranderingsproces bevindt, de kwetsbaarheid die ontstaat tijdens de verandering.

RKO RKORKO

RKO oáëáÅçã~å~ÖÉãÉåíoáëáÅçã~å~ÖÉãÉåí====oáëáÅçã~å~ÖÉãÉåíoáëáÅçã~å~ÖÉãÉåí

Risicomanagement wordt gezien als een integraal onderdeel van het projectmanagement. Gevers en Hendrickx (2001) hanteren een praktische definitie van risicomanagement: risico-management is het continu systematisch onderzoeken van een project op mogelijke onver-wachte gebeurtenissen en het nemen van maatregelen om de negatieve gevolgen ervan te voorkomen of te bestrijden en de positieve gevolgen ervan te benutten of versterken. Nega-tieve gevolgen worden hier risico’s genoemd, de posiNega-tieve gevolgen zijn kansen. De afstu-deeropdracht betrof vanaf het begin het uitvoeren van een risicoanalyse waar de negatieve gevolgen centraal staan. Er wordt in dit onderzoek geen rekening gehouden met de positieve gevolgen, de kansen van een project worden buiten beschouwing gelaten.

De context van dit onderzoek is breder dan het uitvoeren van één enkele risicoanalyse. De risicoanalyse moet ook een plaats krijgen in de organisatie van de projecten bij Ahrend. In het risicobeheersingsmodel moet dus een vorm van risicomanagement worden opgenomen. Risico’s moeten systematisch onderzocht worden en de risicoanalyse moet iteratief worden toegepast. Naast een methode, het stappenplan aan de hand waarvan de risicoanalyse uitge-voerd kan worden, moet aan het model een beschrijving van de wijze van toepassing worden toegevoegd.

RKP RKPRKP

RKP lé=íÉ=äÉîÉêÉå=ãçÇÉälé=íÉ=äÉîÉêÉå=ãçÇÉä====lé=íÉ=äÉîÉêÉå=ãçÇÉälé=íÉ=äÉîÉêÉå=ãçÇÉä

Van de in de literatuur voorkomende risicomodellen en risicoanalyses heeft het voornaamste deel betrekking op financiële zaken, dan wel implementaties van IT systemen als ERP. In projectmanagementtermen wordt over risico modellen gesproken in de vorm van

vragenlijs-ten, checklists en dergelijke. Deze hebben over het algemeen betrekking op de verandering zelf en liggen in het verlengde van veranderingsmanagement.

Bij Ahrend wordt in projecten nu ook al een risicoanalyse uit-gevoerd. Het uitvoe-ren van een risicoana-lyse is onderdeel van het opstellen van het projectplan. Er wordt, in het kort, gevraagd in een schema de risi-co’s te benoemen, deze een waarde te geven en een

passen-de maatregel ter voorkoming te plannen. Gezien het voortraject dat aan het opstellen van het projectplan vooraf gaat, wordt nu pas in een laat stadium van het ontwikkelen van de case met risico’s rekening gehouden. Bovendien worden alleen de risico’s die direct betrekking hebben op het project geïdentificeerd. Waar de risicoanalyse nu in het projectmanagement bij Ahrend pas bij uitvoering van het project ter sprake komt, zal in het op te leveren model de risicoanalyse onderdeel zijn van het voortraject én van het project. Hierbij wordt rekening gehouden met het resultaat van het project.

Tijdens de afstudeerperiode is gebleken dat Ahrend, in dit geval ITS, behoefte heeft aan een algemeen model waar het OOC project en in de toekomst nieuwe projecten op risico’s kun-nen worden getoetst. Het is de bedoeling om bij bepaalde risico’s passende maatregelen aan te geven. In tegenstelling tot de huidige werkwijze is het daarbij zaak de risicoanalyse een prominente plek in het voortraject van het project te geven en in te bedden in de projectfase-ring. De OOC case dient als voorbeeld voor de ontwikkeling van het model. Het model wordt gevalideerd en bijgesteld door het toe te passen op de OOC case en aan de hand van een case die in het verleden bij Ahrend is afgerond.

Het op te leveren model bestaat uit een tweetal onderdelen: de methode en de wijze van toe-passing. De methode is het stappenplan, waarin een beschrijving van het veranderingsproces en de beoogde situatie uiteindelijk leidt tot te nemen maatregelen. De wijze van toepassing is de manier waarop met de methode om moet worden gegaan. De wijze van toepassing heeft een rollen-, een activiteiten-, en een tijdcomponent:

Project Initiation Document Closure Document Project Plan Progress Report Change Request Functionele Beschrijving Voorstudie Business Case

Request For Information

Request For Proposal

Leveranciers Selectie Investeringsaanvraag Detail Ontwerp Proof Of Concept Fase I initiatie & definitie Fase II inventarisatie & selectie Fase III realisatie

Risico-analyse

analyse model

validatie

scriptie

1 2 3, 4, 5 6 7 8

- Rollen: wie doet wat en wie is waarvoor verantwoordelijk

- Activiteiten: wat moet er gebeuren om risicomanagement uit te voeren

- Tijd: op welke momenten in de projectfasering moet de risicoanalyse uitgevoerd worden

RKQ RKQRKQ

RKQ táàòÉ=î~å=~~åé~âtáàòÉ=î~å=~~åé~â====táàòÉ=î~å=~~åé~âtáàòÉ=î~å=~~åé~â

Om tot het risicobeheersingsmodel te komen zijn gedurende het onderzoek onderstaande deliverables opgeleverd.

1) Probleemstelling 2) Modelopzet

3) Te valideren model

4) Tussentijdse analyse van de case 5) Validatieplan

6) Gevalideerde model

7) Definitieve analyse van de case

8) Eindrapportage: scriptie / presentatie model & analyse

In het proces van het onderzoek ziet dit er als volgt uit:

Vanuit de probleemstelling is aan de hand van literatuur een opzet voor het model gemaakt. In combinatie met de OOC case is dit verder ontwikkeld tot een model dat specifiek toepas-baar is op deze case. Aan de hand van de validatie is gewaarborgd dat het model werkt en algemeen toepasbaar is binnen Ahrend. Uiteindelijk levert het onderzoek een risicobeheer-singsmodel en een risicoanalyse van de OOC case op.

In het afstudeerverslag zijn onderdelen uit deze deliverables opgenomen. De modelopzet heeft geleid tot de theoretische beschrijving van het model. Het gevalideerde model en het validatieverslag zijn de uitkomst van het te valideren model, het validatieplan en het gevali-deerde model. In het afstudeerverslag is een samenvatting te vinden van de resultaten van de risicoanalyse van de OOC case.

Bij het ontwikkelen gelden onderstaande criteria. Aan de hand van onder andere deze criteria wordt de validatie van het model uitgevoerd:

- Aansluiten op doelstelling, zoals deze gesteld is in de probleemstelling

- Overzichtelijk

- Eenvoudig te lezen schema’s - Begrijpelijke taal

- Praktisch bruikbaar

- Benodigde input informatie is door redelijke inspanning te verkrijgen - Output informatie is eenvoudig bruikbaar in de business

- Bruikbaar voor derden

- Ahrend-medewerkers die niet direct betrokken zijn bij het afstudeeronderzoek moe-ten met het model kunnen werken

- Het model moet toepasbaar zijn op andere projecten

De analyses zijn tussentijds getoetst door bij betrokkenen van Ahrend om te controleren of ze een reële weergave van de risico’s en maatregelen van de case geven.

RKR RKRRKR

RKR s~äáÇ~íáÉs~äáÇ~íáÉ====s~äáÇ~íáÉs~äáÇ~íáÉ

In de meest ideale situatie vindt de validatie plaats door het model op verschillende projecten en bijbehorende voortrajecten van het begin tot het eind toe te passen. In het model wordt in de wijze van toepassing aangegeven op welke momenten in het traject van de case de metho-de moet wormetho-den doorlopen. Op basis van ervaring van metho-de betrokken Ahrend-memetho-dewerkers worden deze momenten vastgesteld. Of deze momenten juist zijn gekozen wordt in dit on-derzoek niet gevalideerd. De risicoanalyse wordt uitgevoerd door een gebruiker van het mo-del. Om het model te valideren moeten ook de rollen in het model gevalideerd worden. In dit onderzoek wordt de rol van de begeleiding van het uitvoeren van de risicoanalyse ingevuld door de afstudeerder en daarmee door de ontwikkelaar van het model. Wegens tijdgebrek is het onmogelijk om gedurende de gehele doorlooptijd een project en voortraject te volgen, dergelijke cases hebben een doorlooptijd van vele maanden. Het complete model valideren, inclusief de plek in de projectfasering en de rol van de begeleiding van de risicoanalyse is in het tijdsbestek van de afstudeerstage niet mogelijk. Dergelijke zaken zijn wel in tussenrap-portages aan bod gekomen en daarmee getoetst aan praktijkervaring van de betrokken Ah-rend-medewerkers.

Een doel van de validatie is het aantonen waar het model en werkelijkheid overeenstemming vertonen. En waar dit niet het geval is het model aan te passen om deze overeenstemming te verkrijgen. In dit onderzoek wordt de validatie beperkt tot het valideren van de methode waar het model gebruik van maakt. De bruikbaarheid van de methode moet worden aange-toond. Volgens De Leeuw (2001) is de definitie van bruikbaarheid van een methode tweeledig, er wordt een onderscheid gemaakt tussen praktisch en inhoudelijke validatie.:

1) Praktisch: relevantie, kan je daadwerkelijk iets doen met de methode in het kader van het probleem waar je mee bezig bent

2) Inhoudelijk: deugdelijkheid, consistente en precieze definities

In dit onderzoek wordt er van uit gegaan dat er sprake is van een toegevoegde waarde als er uit een risicobeheersingsmodel antwoorden komen waaraan in eerste instantie niet is ge-dacht. Risico blijft een vaag begrip, achteraf is het lastig te bewijzen of risico’s wel of niet op zouden treden ondanks of dankzij de genomen maatregel. Tijdens de validatie wordt een poging gedaan om te controleren of de voorspellende waarde juist is. Met andere woorden: levert de theoretisch opgestelde methode in de praktijk die risico’s op waarvoor maatregelen getroffen moeten worden. In de validatie wordt op de volgende onderdelen getoetst:

• Terminologie: zijn de begrippen juist en eenduidig?

• Stappenplan: is de input te verkrijgen en is de output bruikbaar? • Schema’s: zijn de schema’s duidelijk en overzichtelijk?

• Praktisch: is de methode toe te passen op praktijk cases? • Bruikbaar: is de methode door derden toe te passen?

Het beantwoorden van de vragen is gebeurd tijdens het toepassen van de methode op twee cases. De uitkomsten van de risicoanalyses worden continue bij medewerkers van Ahrend gecontroleerd. Wanneer de validatievragen een negatief antwoord opleveren, wordt de me-thode hierop aangepast.

Door de methode toe te passen op verschillende cases kan worden getoetst of de uitkomst van de methode inderdaad relevant is: levert de methode risico’s op die ook in andere cases daadwerkelijk optreden en beheersmaatregelen die daadwerkelijk een oplossing bieden? Aangezien de methode is ontwikkeld op basis van de OOC case moet de methode minimaal op één andere case worden toegepast om aan te tonen dat het een algemene methode betreft. Keuzes die tijdens de ontwikkeling zijn gemaakt, zijn immers gebaseerd op de OOC case. De methode wordt daarnaast toegepast op een case uit het dagelijks leven: zeer toepasselijk de case “afstuderen” om te toetsen of de definities nauwkeurig zijn, of de leesbaarheid goed is en of het eenvoudig te begrijpen is. Dit is tevens een test of de methode voor derden buiten Ahrend eventueel ook bruikbaar is.

Om de keuze voor de validaticase te maken wordt een onderscheid gemaakt in de fase van de cases (zie Figuur 2). De methode toepassen op een case aan het begin van het voortraject, Fase I, levert gegarandeerd een aantal risico's op, maar of deze ook daadwerkelijk voor zullen ko-men blijft gissen. Wanneer een case zich verder in fase II of aan het begin van de realisatie fase, fase III, bevindt wordt het achteraf controleren van de gevonden risico’s al in beperkte mate mogelijk. Wanneer in een case al een project is afgerond wordt het achteraf controleren van de risico’s juist weer eenvoudig, echter zit hier de moeilijkheid in het terug redeneren naar welke risico’s vooraf opgemerkt zouden zijn. De invuller moet als het ware het geheu-gen uit kunnen schakelen en blanco terug kunnen gaan naar de start van de case. Om de re-sultaten van een risicoanalyse van een case te valideren is een case in aan de start van fase I minder geschikt. Cases waarvan de projecten zich in de begin- en eindfase bevinden hebben beide beperkingen, maar kunnen in dit geval gebruikt worden.

De inhoud van de voor de validatie te gebruiken cases is in zo verre niet van belang dat de enige eis die aan de inhoud van de referentiecase wordt gesteld is dat het omvangrijk moet zijn en een grote impact op de organisatie moet hebben.

RKS RKSRKS

RKS oÉÑoÉÑÉêÉåíáÉoÉÑoÉÑÉêÉåíáÉÉêÉåíáÉÉêÉåíáÉÅ~ëÉÅ~ëÉÅ~ëÉÅ~ëÉ====

De validatie vindt plaats door de methode op een referentiecase toe te passen. De methode uit dit onderzoek is op basis van de OOC case ontwikkeld. Het OOC pilot project staat in de start-blokken, dit is eind fase II. Om te bepalen of vooraf voorspelde risico’s achteraf zijn voorge-komen moet de referentiecase fase III hebben afgerond. De keuze voor de tweede referentie valt op case Digital Order File (DOF), hiervan is het project pilot DOF afgerond op 19 januari 2006. Het feit dat dit project is afgerond biedt de mogelijkheid om te controleren of de risico's die zich hebben voorgedaan ook door de methode zouden worden opgemerkt.

In de OOC case wordt zoals genoemd de methode uit het model toegepast. Onder begeleiding van een risicomanager, in dit onderzoek de afstudeerder, worden de stappen uit de methode met verschillende, bij het project betrokken managers en gebruikers, doorlopen. Later in dit document wordt de rol van risicomanager, net als de andere rollen in het risicobeheersings-model, nader toegelicht.

Aangezien de DOF case een onderdeel van de validatie is en niet aan de onderzoeksvraag is gerelateerd, volstaat een korte omschrijving van deze case (zie Bijlage IX) voor een uitgebrei-dere beschrijving). Het betreft de invoering van systeem waarin digitaal orderdocumenten opgeslagen en gerubriceerd kunnen worden. De doelgroep van deze case is de verkooporgani-satie, de case beïnvloedt de dagelijkse werkzaamheden van de betrokkenen in hoge mate: een verandering in de workflow van papier naar digitaal.

De OOC case bevindt zich gedurende dit onderzoek in Fase I en Fase II. Bij het afronden van dit onderzoek is het pilot project gestart. Een onderdeel van de doelstelling van deze scriptie is het opleveren van een risicoanalyse van het OOC project. Risico’s zijn hier nog niet voorkomen en de geldigheid van de uitkomst van de methode kan dus ook nog niet worden ge-controleerd. De tweede case daarentegen moet juist antwoorden opleveren of de risico’s die benoemd zouden zijn ook daadwerkelijk op zijn getreden.

Reeds genoemd is het probleem dat de deelnemer achteraf moet gaan zeggen wat vooraf als risico zou zijn benoemd. Een bijkomend probleem is het feit dat gebruikers in de DOF case niet geheel onbevooroordeeld zijn, er hebben zich complicaties voorgedaan door een falende technologie / leverancier. In de DOF case zijn geen personen te vinden die onbevooroordeeld de methode kunnen doorlopen. Het management is op korte termijn te druk bezet en de ge-bruikers zijn bovendien niet voldoende op de hoogte van het voortraject.

Er wordt voor een zelfde aanpak gekozen als bij de OOC case: interviews met betrokken ma-nagers. Omdat het hier een controle van de risico’s betreft, dat is immers mogelijk omdat het project zo goed als afgerond is, wordt na doorlopen van de methode de uitkomst hiervan ge-controleerd bij de gebruiker. Daarnaast kan gebruik worden gemaakt van de ingevulde risico-analyse uit het projectplan. Hier wordt echter geen rekening gehouden met risico’s die het eindproduct van het project bedreigen en enkel met risico’s die het project als proces bedrei-gen.

Het zou ideaal zijn om eerst een analyse op de OOC case uit te voeren en op die manier tot een te valideren methode te komen, vervolgens deze methode te valideren aan de hand van de DOF case en uiteindelijk met de gevalideerde methode de OOC analyse te voltooien. In verband met volle agenda’s en tijdsdruk kan het voorkomen dat de afspraken met de betrok-kenen van de twee projecten door elkaar lopen. Door zo dicht mogelijk bij het stappenplan te blijven en de stappen parallel aan elkaar uit te voeren is geprobeerd dit zo min mogelijk in-vloed te laten hebben op de ontwikkeling van het model. Na een stap gevalideerd te hebben is met deze stap de analyse uitgevoerd terwijl de volgende stap werd gevalideerd. Wanneer dit onmogelijk was is de risicoanalyse van de OOC case aangepast aan de resultaten die de validatie heeft opgeleverd. Door telefonisch te controleren bij de betrokkenen is een comple-te risicoanalyse opgeleverd overeenkomstig met het ontwikkelde model.

RKT RKTRKT

RKT _ÉéÉêâáåÖÉå=î~å=ÜÉí=ãçÇÉä_ÉéÉêâáåÖÉå=î~å=ÜÉí=ãçÇÉä====_ÉéÉêâáåÖÉå=î~å=ÜÉí=ãçÇÉä_ÉéÉêâáåÖÉå=î~å=ÜÉí=ãçÇÉä

In een risicoanalyse wordt geprobeerd risico’s in zowel de nabije als de verre toekomst te benoemen en hiervoor passende maatregelen te bieden. Aangezien een risico dus te maken

heeft met voorspellingen in de toekomst heb je te maken met onzekerheid, vandaar dat je vaak niet onder subjectieve informatie uitkomt.

Risico’s in de toekomst wordt vergeleken met risico’s in de huidige situatie. In de beoogde situatie worden de risico’s voorspeld, in de huidige situatie wordt een inschatting gemaakt van het risico. Risico’s kunnen verschillen afhankelijk van door wie en op welk moment de risico’s worden benoemd.

De validatie brengt ook beperkingen met zich mee. Er wordt niet een geheel project inclusief voortraject doorlopen, dus wordt alleen de methode van het model gevalideerd. Door hier-mee een risicoanalyse uit te voeren met alle beperkingen van dien. De wijze van toepassing van het model blijft in de validatie buiten beschouwing.

Organisatorisch Technisch Huidige Situatie Risico Analyse Advies Beoogde Situatie Verandering Analyse Economisch Omgeving Processen Cultuur Technologie Structuur Strategie Strategisch

S

S

S

S jçÇÉä=çåíïáââÉäáåÖ

jçÇÉä=çåíïáââÉäáåÖ

jçÇÉä=çåíïáââÉäáåÖ

jçÇÉä=çåíïáââÉäáåÖ====

Dit hoofdstuk start met de theoretische onderbouwing van de begrippen die in het model worden gehanteerd. Dan volgt de ontwikkeling van de methode: het stappenplan. Vervolgens wordt de wijze van toepassing beschreven, waarin de rollen en de activiteiten van het risico-beheersingsmodel worden toegelicht en de methode in het projectfasering bij Ahrend wordt geplaatst.

SKN SKNSKN

SKN qÜÉçêÉíáëÅÜÉ=çåÇÉêÄçìïáåÖqÜÉçêÉíáëÅÜÉ=çåÇÉêÄçìïáåÖ====qÜÉçêÉíáëÅÜÉ=çåÇÉêÄçìïáåÖqÜÉçêÉíáëÅÜÉ=çåÇÉêÄçìïáåÖ

SKNKN `çåÅÉéíìÉÉä=ãçÇÉä=

In Figuur 6 staat het conceptuele model van het onderzoek weergegeven. Een conceptueel model in een onderzoek geeft de globale kijk weer die aan het onderzoek ten grondslag ligt. Een conceptueel model is ook een krachtig hulpmiddel om de samenhangende resultaten van een onderzoek in een overzichtelijk patroon weer te geven (De Leeuw, 2001). In een concep-tueel model wordt grafisch weergegeven hoe de verschillende begrippen volgens de onder-zoeker onderling samenhangen (Baarda & De Goede, 1997). Hier wordt het model gebruikt als een kapstok om de verschillende begrippen aan op te hangen.

Vanuit de strategie om de concurrentiepositie te verbeteren wordt bij Ahrend het OOC pro-ject gestart. De strategie is een gegeven dat buiten het onderzoek valt, er gaat niet geanaly-seerd worden wat het risico van de keuze voor deze strategie is, vandaar dat strategie boven de stippellijn is geplaatst.

In de businesscase worden doelstellingen geformuleerd die de case beoogt in een nieuwe si-tuatie. Er kan een beeld gecreëerd worden van de beoogde situatie door deze af te leiden van de doelstellingen van de case. Een risicoanalyse moet risico’s opleveren die voor kunnen ko-men in de beoogde situatie en in de weg naar deze beoogde situatie: de verandering. Om de risico’s in de beoogde situatie goed in te kunnen schatten moeten ook de risico’s in de huidi-ge situatie mee huidi-genomen worden in de analyse. Is een risico in de beoogde situatie hetzelfde als in de huidige situatie dan is het de vraag of dit risico mee moet wegen in de beslissing om de case door te laten gaan, dan wel een maatregel binnen de case te treffen. Het gaat om een het krijgen van een breed beeld. Het model dwingt om de doelstellingen van de case te om-schrijven in bepaalde gebieden en aspecten. Het enkel kijken naar de doelstellingen en hier vervolgens risico’s uit destilleren kan leiden tot een incomplete risicoanalyse. Risico’s zijn nu eenmaal niet altijd rechtstreeks uit de doelstellingen op te maken. De case wordt als het ware door een zeef van gebieden en aspecten gehaald.

De huidige situatie, de beoogde situatie en de verandering worden in kaart gebracht op een aantal gebieden. Deze gebieden zijn gekozen aan de hand van de Structurele en Contextuele Dimensies van Daft (2001). Daft zijn boek “Organization, Theory and Design” wordt gezien als het internationale standaardwerk over organisatietheorie en is wereldwijd een van de meest gebruikte leerboeken op het gebied van onder andere “verandermanagement”. Volgens Daft bestaat een organisatiedimensie uit twee types: structureel en contextueel. De structurele dimensie geeft handvatten om een beschrijving van de interne karakteristieken van de orga-nisatie te maken. De contextuele dimensies karakteriseren de gehele orgaorga-nisatie, inclusief de grootte, cultuur, technologie, omgeving en doelen. Daft besteedt weinig aandacht aan proces-sen. Laudon en Laudon (2000) hanteren factoren die de relatie tussen organisatie en informa-tietechnologie weergeven. Deze factoren komen grotendeels overeen met de dimensies van Daft, echter benoemen ze ook de Business Processes. Uiteindelijk is gekomen tot de volgende gebieden: Omgeving, Technologie, Cultuur, Structuur en Processen. De lading van het om-schrijven van een verandering wordt hiermee gedekt. In paragraaf 6.1.2 wordt nadere invul-ling gegeven aan deze begrippen.

Het vergelijken van de huidige met de beoogde situatie levert een beeld op van de verande-ring, de weg van de huidige situatie naar de beoogde situatie. Bij de verandering en de beoog-de situatie hoort een aantal risico’s. Risico’s zijn onbeoog-der te verbeoog-delen in verschillenbeoog-de soorten. Ernst & Young onderscheidt in haar werkwijze vier categorieën: Financieel, Operationeel, Strategisch en Calamiteiten. Deze onderverdeling is gebaseerd op het Enterprise Risk Mana-gement – Integrated Framework (COSO, 2004). Calamiteiten zijn risico’s op een ander, hoger niveau en kunnen in het geval van een IT project bijvoorbeeld financieel of operationeel van aard zijn. Huat Lim (1997) benoemt met de Enterprise Integration Issues risico’s bij een IT integratie project (deze komen overeen met de vier eerder genoemde categorieën) en maakt bovendien een onderscheid in technisch en organisatorisch in de categorie operationeel. De