INHOUDSOPGAVE

INHOUDSOPGAVE................................................................................................................................................1 Inleiding....................................................................................................................................................................2 SIM-gebied 1: Implementatie als project.................................................................................................................6 Valkuil 3 de overbelaste projectleider..................................................................................................................11 Valkuil 5 betrokkenheid gebruikers...................................................................................................................12 SIM-gebied 2: Realisering kwaliteit.......................................................................................................................13 SIM-gebied 3: Bevordering acceptatie...................................................................................................................16 SIM-gebied 4: O&I ONTWERP............................................................................................................................19 SIM-gebied 5: Voorbereiding van invoering en integratie....................................................................................24 SIM-gebied 6: Invoering........................................................................................................................................29 SIM-gebied 7: Nazorg............................................................................................................................................32 Tenslotte.................................................................................................................................................................35

1

INLEIDINGOrganisaties maken in toenemende mate gebruik van geautomatiseerde informatiesystemen. De ontwikkelingen in de informatietechnologie brengen vele nieuwe mogelijkheden met zich mee. Er komen completere informatiesystemen en netwerken binnen en ook buiten de eigen organisatie. Het strategisch belang voor organisaties en de hoogte van de investeringen groeit nog steeds. De ontwikkeling en invoering van informatiesystemen is echter nog steeds niet van risico's ontbloot. Voor de mislukte en minder geslaagde automatiseringsprojecten zijn vele faalfactoren aan te wijzen. En van de belangrijkste factoren is onvoldoende afstemming van het informatiesysteem op de organisatie en de mensen die daar werken. De oorzaak hiervoor kan gezocht worden in gebrek aan aandacht voor organisatorische aspecten tijdens het ontwikkelingsproces. Bij automatiseringsprojecten zijn het ontwikkelen van een informatiesysteem en het veranderen van de organisatie niet los van elkaar te zien. Deze gedachte, die kan worden samengevat met de woorden: "automatiseren is reorganiseren", is voor veel managers vanzelfsprekend geworden. Het praktisch invullen van deze gedachte is echter niet eenvoudig. En van de sleutels voor een geslaagde aanpak is de zorgvuldige uitvoering van de implementatie van een informatiesysteem. Immers met de implementatie wordt het ontwikkelde informatiesysteem ingebed in de organisatie. Op dat punt ontmoeten systeem en organisatie elkaar 'in levende lijve'. Het is de fase waarin zal blijken of de organisatie kan werken met het informatiesysteem en of de verbeteringsdoelen zijn gehaald. Wil de manager zelf greep houden op het succesvolle invoeren en inpassen van een geautomatiseerd informatiesysteem, dan zal hij een aantal zaken goed in de gaten moeten houden. Hij dient vooraf duidelijk bepaald te hebben welke veranderingen in zijn organisatie moeten worden gerealiseerd. En vooral ook: op welke wijze dat moet gebeuren. Er moet voorkomen worden dat op het laatste moment nog allerlei discussies moeten worden gevoerd. De manager zal de automatisering daarbij nadrukkelijk moeten zien als een weg tot verbetering van n aspect van zijn organisatie. Wanneer hij dit doet, zal hij het grotere verband niet uit het oog verliezen en ook andere aspecten (technische, sociale, financile, organisatorische) bij de verbetering betrekken. Tenslotte dient hij zich ervan bewust te zijn dat een informatiesysteem mr is dan een verzameling apparatuur en programmatuur. Een informatiesysteem omvat ook gegevensverzamelingen en het gebruik daarvan, procedures, taken, mensen en organisatiestructuren. De Systeem Implementatie Methode (SIM) biedt een leidraad om dit te kunnen realiseren: Een systematische voorbereiding en uitvoering van de implementatie van een informatiesysteem Implementatie van een informatiesysteem begint al bij het initiatief tot automatiseren. Het eindigt met de uiteindelijke integratie van het systeem in de 'routine' van de organisatie.

2

Het heeft zowel te maken met specificeren van informatiebehoeften, met ontwerpen, als met voorbereiding van de invoering en de inpassing van een informatiesysteem in de organisatieroutine. Dat is dus aanmerkelijk meer dan alleen de invoering van een systeem!

3

SIM kent zeven activiteitsgebieden. Om de zeven gebieden en hun onderlinge verhouding goed in beeld te brengen hanteren we voor SIM het volgende model:

1 IMPLEMENTATIE ALS PROJECT

2 REALISERIN G KWALITEIT

4 O&I-ONTWERP

3 BEVORDERI NG ACCEPTATIE

5 VOORBEREIDING INVOERING EN INTEGRATIE 6 INVOERING

7 NAZORG

Elk gebied belicht vanuit een bepaalde invalshoek de problematiek van de implementatie. Een aantal gebieden staan weliswaar in een zekere tijdsvolgorde tot elkaar. Het eerste aandachtsgebied, Implementatie als project, houdt in het inrichten van het project vanuit de ideen en aanpak van SIM, toegesneden op de specifieke vraagstelling en problematiek. Het verzorgen van dit aandachtsgebied en het eventueel bijstellen van de gang van zaken loopt door gedurende het gehele project. De aandachtsgebieden Realiseren kwaliteit en Bevorderen acceptatie zijn gebaseerd op de gedachte: Effectiviteit = Kwaliteit x Acceptatie. Deze aandachtsgebieden spelen gedurende het gehele project een rol. Het aandachtsgebied O&I-ontwerp is de kern van de op implementatie gerichte werkwijze bij het tot stand brengen van het ontwerp voor de werkprocessen in de organisatie in samenhang met het ontwerp voor het informatiesysteem. Dit aandachtsgebied speelt een hoofdrol in de voorbereiding en ontwerpfase, maar blijft ook bij beslissingen in het vervolgtraject meespelen. De drie overige aandachtsgebieden Voorbereiding invoering en integratie, Invoering en Nazorg zijn bij elkaar behorende gebieden die in een tijdsvolgorde zijn te plaatsen. In het overzicht op de volgende pagina wordt aangegeven wat de kern van elk gebied is, en wat het verwachte product is.

4

SIM gebied Inhoud Product -----------------------------------------------------------------------------------------------------------------------------------------------------------------1. Implementatie als project Inrichting van een project voor de im- - projectplan plementatie van een informatiesysteem - risico-analyse

2. Realisering Opzetten kwaliteitsbeheer en vaststellen van systeem voor kwaliteitsbeheer kwaliteit kwaliteitsnormen - kwaliteitsnormen implementatie 3. Bevordering acceptatie verVoorwaarden scheppen voor gemotiveerde acceptstrategie gebruikers en management - aanwijzingen aanpak van andering - doel, aard en verloop veranderingsproces - schattingen en afwegingen consequenties 4. O&I-ontwerp Beschrijving van bestaande organisatie- - beschrijvingen structuur, administratieve organisatie, ar- analyses chitectuur van de informatievoorziening; - ontwerpen veranderingsanalyse; ontwerp van nieuwe organisatiestructuur, administratieve organisatie en architectuur van de informatievoorziening Voorbereiding van: - plan invoering en integratie - procedures - parametrisering en basisbestanden - beheer informatiesystemen - taakontwerp - opleidingen en gebruikersdocumentatie - gebruikerstest en overdracht - conversie Invoering van het informatiesysteem - procedures checklist nazorg

5. Voorbereiding invoering en integratie

6. Invoering 7. Nazorg

Uitvoeren integratieproces en evaluatie -

- taaktoewijzing - evaluatierapport -----------------------------------------------------------------------------------------------------------------------------------------------------------------In de volgende hoofdstukken worden de SIM-gebieden nader uitgewerkt.

5

SIM-GEBIED 1: IMPLEMENTATIE

ALS PROJECT

De implementatie van een informatiesysteem moeten we zien als een project. Meestal is de implementatie van een informatiesysteem een bijzondere aangelegenheid. Vaak nmalig en voor een beperkte tijd moeten verschillende disciplines ingeschakeld worden (informatica, automatisering, bedrijfskunde, administratieve organisatie, personeelswerk). Afhankelijk van de situatie spelen hardware-leveranciers, software-ontwikkelaars en adviseurs ook een rol in het project. In vruchtbare samenwerking moet een succesvolle implementatie tot stand worden gebracht. Een duidelijke projectstructuur met een goede taak- en rolverdeling is dan beslist noodzakelijk. Projectdoelstelling Het behalen van een projectdoelstelling wordt nogal eens als een triviale bezigheid beschouwd. De formuleringen - hoe zorgvuldig ook gekozen - zijn meestal tamelijk obligaat en wat men precies bedoeld heeft, is vaak niet geheel duidelijk. Toch is het aan te bevelen de projectdoelstelling op een duidelijke, voor de projectorganisatie herkenbare wijze vast te stellen. Het gaat daarbij niet alleen om de formulering van de doelstelling maar vooral ook om de wijze waarop die tot stand komt. Wat is de reden hiervoor? Het formuleren van een doelstelling moet de eerste brug slaan tussen de initiatiefnemers van het project, degenen die verantwoordelijkheid dragen, de verschillende disciplines die bij de uitvoering worden betrokken en de eindgebruikers. Bij de besprekingen over de doelstelling worden de diverse verwachtingen op elkaar afgestemd en moet overeenstemming worden bereikt over de te volgen tactiek. Bovendien is een goed geformuleerde doelstelling als het ware een 'logo' voor het project, met als effect dat iedereen met enige regelmaat wordt herinnerd aan het doel waarom het project ooit is begonnen. Bij een te vrijblijvende formulering van de projectdoelstelling zal iedereen dit doel op zijn eigen manier invullen. Het project loopt dan het risico te gaan 'zwabberen': het project op de rails houden vergt in zo'n geval enorm veel energie en tijd van het projectmanagement. De doelstelling en de daarmee samenhangende voorstellingen over het te bereiken resultaat zullen tijdens het project met alle betrokkenen regelmatig moeten worden afgestemd en indien nodig bijgesteld. Als dit niet expliciet gebeurt, is het risico groot dat het verantwoordelijke management de greep op het project verliest en onvoldoende kan sturen naar een succesvol resultaat. Inrichting van het project Bij 1. 2. 3. 4. 5. 6. 7. de inrichting van een implementatieproject worden zeven aspecten onderscheiden: projectaanpak projectfasering projectorganisatie projectbemanning projectfaciliteiten projectbudget projectplanning.

Elk aspect wordt hierna toegelicht. 1. Projectaanpak SIM pleit voor het maken van een bewuste keuze van de te volgen projectaanpak. Hierdoor worden de verwachtingen van betrokkenen in een vroeg stadium op elkaar 6

afgestemd. Dit kan veel onduidelijkheden en vertragende discussies tijdens het project voorkomen. Twee factoren spelen een rol bij keuze van de projectaanpak: de mate van gestructureerdheid van het project: dat wil zeggen de mate waarin de onderdelen van het project van tevoren zijn afgebakend het tempo van het project: hierbij gaat het om de tijd die men heeft om het project uit te voeren en het effect van tijdsdruk op de planning. We komen daarmee op vier typen van projectaanpak. Figuur 1.1 sterk voorgestructureerd snelheid primair 1 procedureaanpak weinig voorgestructureerd 2 spoedaanpa k

3 snelheid secundair stap-voorstapaanpak

4 procesaanp ak

De procedureaanpak wordt gekozen als er behoefte is aan een goed voorgestructureerd project en spoed geboden is met de uitvoering van het project. Centraal in de procedureaanpak staat een uitgewerkt projectplan. De spoedaanpak heeft geen uitgebreid projectplan, maar is grotendeels afhankelijk van improvisatie. Bij automatiseringsprojecten moet slechts in uitzonderingsgevallen gebruik worden gemaakt van deze aanpak. Indien er sprake is van een sterk voorgestructureerd project, maar het tempo van uitvoering is van secundair belang, wordt veelal gekozen voor de stap-voor-stapaanpak. Hier wordt per fase een gedetailleerd projectplan opgesteld. Wanneer zowel de gestructureerdheid als het spoedeisende karakter van het project gering zijn, wordt gekozen voor een procesaanpak. Veelal vindt men deze aanpak in complexe automatiseringsprojecten. 2. Projectfasering De projectfasering heeft als belangrijkste doel het project in overzienbare delen te splitsen. De fasen hebben ieder een eigen karakter en een duidelijk begin- en eindpunt. In een implementatieproject worden de volgende fasen onderscheiden: fase 1 Voorbereiding project: - globale beschrijving project - risicoanalyse - inrichten project - opzetten projectbeheerssysteem - maken projectplan - vaststellen projectplan fase 2 Voorbereiding effectiviteitsmaatregelen: 7

- opzetten kwaliteitssysteem - vaststellen acceptatiestrategie - maken voorlichtingsplan fase 3 O&I-ontwerp: - voorbereiding O&I-ontwerp - beschrijving bestaande situatie - veranderingsanalyse - ontwerp nieuwe situatie fase 4 Voorbereiding invoering en integratie: - voorbereiding procedures - voorbereiding parametrisering en basisbestanden - opzet beheer informatiesysteem - taakontwerp - voorbereiding opleidingen en gebruikersdocumentatie - voorbereiding gebruikerstest en overdracht - voorbereiding conversie - maken invoerings- en integratieplan fase 5 Uitvoering invoerings- en integratieplan: - beschrijven procedures - parametrisering en vullen basisbestanden - inrichting beheer informatiesysteem - verdeling taken - uitvoering opleidings- en documentatieplan - uitvoeren gebruikerstest en overdracht - conversie - rapportage uitvoering implementatieplan fase 6 Nazorg: - planning nazorg - uitvoering plan nazorg - rapportage nazorg fase 7 Evaluatie en afsluiting: - evaluatie - afsluiting implementatieproject Wanneer gekozen is voor de proces- of de stap-voor-stap-aanpak zullen de fasen tevoren slechts globaal worden ingepland. De activiteiten van een bepaalde fase worden voor die projecten tijdens de voorafgaande fase nader uitgewerkt. Bij de procedure- en spoedaanpak vindt een gedetailleerde beschrijving van de fasen vooraf plaats. 3. De projectorganisatie De organisatie van automatiseringsprojecten heeft vaak de volgende structuur: stuurgroep, projectgroep(en), werkgroepen, sub-werkgroepen. Afhankelijk van de omvang en complexiteit kan de organisatie van een implementatieproject in een zelfde vorm worden gegoten. De rol van de opdrachtgever is cruciaal in projecten. Hoe complexer en hoe ingrijpender voor de organisatie een project is, hoe belangrijker voldoende betrokkenheid van het verantwoordelijk lijnmanagement is. Deze betrokkenheid zal zichtbaar moeten zijn in de organisatie en werkwijze van stuurgroep, projectleiding en projectgroep(en). Een directe rol in de projectleiding en projectgroep van de opdrachtgever is de beste mogelijkheid om voorwaarden hiervoor te creren. Vaak is het moeilijk management/opdrachtgever te 8

overtuigen van het belang van de bijbehorende tijdsinvestering. Aan de andere kant wordt steeds duidelijker dat de verantwoordelijkheid van de opdrachtgever alleen ingevuld kan worden door actief te sturen naar duidelijk omschreven doelstellingen en resultaten. 4. De projectbemanning Voor de uitvoering van het implementatieproject moet personeelscapaciteit worden vrijgemaakt of ingehuurd. Het op tijd kunnen beschikken over de juiste mensen is een van de belangrijkste vormen voor een succesvol projectverloop. Bij het kiezen van de projecten zijn zowel de vakinhoudelijke als de vaardigheden voor communiceren en samenwerken van belang. Voor specialisten die in teams gaan samenwerken met nietspecialisten moet de eis gesteld worden dat ze de dingen in gewone taal moeten kunnen uitleggen. Waar mogelijk worden interne mensen ingezet. Als dit goed wordt voorbereid en begeleid ontstaat hierdoor draagvlak voor de veranderingen, blijft kennis behouden voor de organisatie en kan optimaal op de organisatie worden ingespeeld. Een capaciteitsplanning over de inzet van het personeel wordt in een vroeg stadium gemaakt. En daarover worden met het verantwoordelijke management duidelijke, schriftelijke afspraken gemaakt. 5. De projectfaciliteiten Voor de uitvoering van een automatiseringsproject zijn allerlei hulpmiddelen nodig, zoals ruimtes, diverse apparatuur, diverse programmatuur en secretarile ondersteuning. In een zo vroeg mogelijk stadium dient te worden vastgesteld welke faciliteiten noodzakelijk zijn, mede om te komen tot een taakstellend projectbudget. 6. Het projectbudget Een deel van het projectbudget is voor implementatieprojecten in de regel goed in te schatten. Hierbij is het een kwestie van het zorgvuldig in kaart brengen van kosten. Dit geldt voor de "harde" kosten van apparatuur, standaard software, ruimtes en dergelijke. Andere kosten worden meestal pas in de loop van het project duidelijk. Dit zijn onder meer kosten van externe adviseurs en systeemontwikkelaars, kosten van interne projectmedewerkers, opleidingskosten, kosten conversie enz. Het is aan te raden hiervoor wel op basis van ervaringscijfers zo goed mogelijk prognoses te maken en deze bij de faseovergangen van het project nader in te vullen. In het projectbeheerssysteem moet een budgetbewaking worden opgenomen, met duidelijke budget- of kostenrapportages. 7. Projectplanning Basis voor de planning is de beschrijving van de activiteiten en de personele capaciteit die vrijgemaakt kan worden. Meestal wordt de planning in wederzijdse afstemming daarmee opgemaakt. Naast de inhoudelijke activiteiten dienen ook de rapportage- en besluitvormingsmomenten ingepland te worden. Vaak is daar een tegenvallende hoeveelheid (doorloop)tijd voor nodig. Valkuilen Valkuil 1 projectdoelstelling

De eerste valkuil is de projectdoelstelling. Wanneer die niet of onvoldoende is geformuleerd, loopt men grote kans dat het project een gemeenschappelijk eindpunt 9

mist. Het gevolg is dat door onduidelijkheid verschillende kanten op gewerkt wordt, of dat door gebrek aan een richtpunt helemaal niets wordt gedaan.

10

Valkuil 2

personele invulling

De tweede valkuil is de personele invulling van het project. Een te krappe capaciteit kan spanningen veroorzaken in het implementatieteam en in de relatie met de gebruikersorganisatie. Het "implementatiemanagement" dient voldoende tijd vrij te kunnen maken voor het project. Een voldoende kwalitatief niveau is net zo belangrijk. De kwalificaties van een implementatieteam in grotere projecten moeten een multidisciplinair karakter hebben. Er moet structureel of op ad hoc basis organisatie- of bedrijfskundige expertise aanwezig zijn evenals deskundigheid op informaticagebied. Het allerbelangrijkste is echter te kunnen beschikken over voldoende materiedeskundigheid. Onvoldoende kennis van en ervaring met de bij implementatie betrokken bedrijfsprocessen is een aanzienlijke handicap. Voor de wat kleinere projecten moet zoveel mogelijk kwaliteit worden verenigd in werkgroepen, waarin de materiedeskundigheid eveneens goed is vertegenwoordigd. Het samenstellen van de projectgroepen moet op zakelijk-inhoudelijke gronden gebeuren. Een politieke' benoeming houdt bijna altijd risico in voor het welslagen van het project. Valkuil 3 de overbelaste projectleider

In veel projecten is de projectleider de enige die fulltime vrijgemaakt wordt voor het project. Dit lijkt ten opzichte van de andere projectgroepleden een zekere 'luxe', die ook niet voor andere onopgemerkt blijft. Van de weeromstuit neemt de projectleider veel te veel uitvoerend werk op zich. In de loop van het project, als blijkt dat zijn fulltime beschikbaarheid hard nodig is om het project op de rails te houden, is de projectleider te druk met het bereiken van zijn eigen resultaten (hij moet namelijk ook nog eens het goede voorbeeld geven). Een gouden regel: geen uitvoerend werk voor de projectleider.

Valkuil 4

financile en materile middelen

Naast de personele middelen vormen de financile en materile middelen ook een valkuil. Een slecht onderbouwde schatting van de financile behoeften brengt het project bijna altijd in de problemen. Geen enkele manager neemt graag beslissingen over onverwachte uitgaven of investeringen. Als de projectfaciliteiten niet goed geregeld zijn, levert dat vaak niet-begrote kosten op, maar - en dit is misschien wel belangrijker - ook irritatie en vermindering van vertrouwen in het project en in de projectleiding.

11

Valkuil 5

betrokkenheid gebruikers

De laatste valkuil in dit SIM-gebied waarvoor wij willen waarschuwen is die van de te geringe betrokkenheid van de gebruikersorganisatie. Een implementatie zonder gebruikersorganisatie is onmogelijk. Helaas zijn automatiseerders, maar ook managers van gebruikersorganisaties, zich dat niet altijd ten volle bewust. Wanneer de betrokkenheid bij het informatietechnische traject te wensen overlaat, is het heel belangrijk bij het uitvoeren van het implementatieproject als het ware de 'schade' in te halen. De beste manier om voor betrokkenheid te zorgen is het 'implementatiemanagement' te laten vervullen door een manager van de gebruikersorganisatie en een goede vertegenwoordiging van gebruikers in het implementatieteam. Dat is echter niet altijd mogelijk. In die gevallen zal er tenminste op het planniveau voldoende medewerking moeten worden gezocht.

12

SIM-GEBIED 2: REALISERING

KWALITEIT

Het onderwerp kwaliteit met betrekking tot informatiesystemen staat in de afgelopen jaren in toenemende mate in de belangstelling. Redenen hiervoor zijn onder meer: steeds complexer wordende automatiseringssystemen, toenemende integratie, groter wordende afhankelijkheid van informatiesystemen voor organisaties en het eisen van meer waarborgen door de afnemers ten aanzien van opgeleverde producten en diensten bij automatisering. Kwaliteit van informatiesystemen wordt in SIM als een integrale opgave beschouwd. Als een zaak die vanuit meer gezichtspunten bekeken moet worden. Beheersing van kwaliteit is van toepassing op alle in SIM voorkomende (implementatie)werkzaamheden en de daaruit voortvloeiende resultaten. Bij SIM is kwaliteit primair een verantwoordelijkheid van het management, dat hiervoor bij een project aangesproken kan worden op de volgende taken: 1. 2. 3. 4. 5. 6. 7. het formuleren van een visie ten aanzien van kwaliteit: wat is belangrijk voor het welslagen van het project, welk doel wil het management bereiken?; het beschikbaar stellen van personeel en hulpmiddelen waarmee het beheersen van kwaliteit gerealiseerd kan worden; zorgen dat eisen van mensen geformuleerd worden waaraan de producten van elke (deel)fase moeten voldoen; het boven tafel krijgen van de verwachting die de afnemers van het informatiesysteem hebben over de wijze waarop het systeem ontwikkeld en ingevoerd gaat worden; de opzet van een effectieve systematiek voor controle en rapportage; het beslissen en initiren van acties naar aanleiding van de uitgebrachte rapportages; welke vertragingen zijn verantwoord en wat zijn onverantwoorde risico's?; voorwaarden scheppen voor het op peil houden van de kwaliteit van het informatiesysteem.

Deze taken zijn niet eenvoudig voor het verantwoordelijk management. Hiervoor moeten voortdurend vele aspecten en belangen worden afgewogen. Voorbeelden hiervan zijn: welke functionaliteit nemen we wel en welke functionaliteit nemen we niet op in het informatiesysteem (wat is de grens tussen luxe en noodzakelijke functionaliteit?); hoe lang moeten we doorgaan met de voorbereidings- en ontwerpfase; wat zijn de criteria om met de uitvoering te kunnen beginnen. Het management stuurt daarbij in het krachtenspel tussen de eigen rol als opdrachtgever en de andere betrokkenen partijen zoals leveranciers, specialisten, afnemers (gebruikers) en automatiseerders. Het opzetten van een goede systematiek voor kwaliteitsbeheersing en het scheppen van voorwaarden daarvoor is een zaak die de hele projectorganisatie aangaat. Bijzondere aandacht moet het management daarbij geven aan een duidelijke profilering van wat men op de korte en de langere termijn verwacht van de invoering van een informatiesysteem of nieuwe informatietechnologie. Een belangrijk aspect van het kwaliteitsvraagstuk is het verdelen van de aandacht voor de kwaliteit van de afzonderlijke delen van het ontwikkeltraject en het informatiesysteem en de kwaliteit van het gehele product. Automatiseerders hebben vanuit hun (natuurlijke) analytische houding de neiging om zich vooral in kwaliteitssystemen te richten op de kwaliteit van afzonderlijke stappen van het ontwikkelproces en op de onderdelen van informatiesystemen. Dit blijkt ook uit de kwaliteitssystemen zoals die in de afgelopen jaren door veel systeemhuizen zijn ontwikkeld. De aandacht daarin voor afzonderlijke aspecten en voor details is daarbij groot. De focus ligt daarbij vooral op het proces van de systeemontwikkeling, wat ook een belangrijke 13

verantwoordelijkheid is van systeemhuizen. Op deze punten moet ook veel gebeuren, maar een goede situationele invulling is essentieel. Activiteiten op deelgebieden dienen hun plaats te krijgen vanuit de sturing op de kwaliteit van het product als geheel. De zorg voor de kwaliteit van het product zelf en de prioriteiten over de verschillende onderdelen daarbij is primair de verantwoordelijkheid van het management. Bij product wordt hier niet alleen het systeem bedoeld maar ook verleende diensten en (organisatie)veranderingen. Voor een goed evenwicht tussen het sturen op de kwaliteit van de deelaspecten en de kwaliteit van het gehele product wordt door SIM een aantal hulpmiddelen en denkkaders geboden voor het management. In de methode is de realisering van de kwaliteit een aandachtsgebied dat in nauwe samenhang met de andere aandachtsgebieden wordt aangestuurd. Door het uiteindelijke resultaat van de implementatie van begin af aan in een project een centrale plaats te geven wordt sturen op de kwaliteit van het product als geheel mogelijk. Voor de verschillende aspecten van het realiseren van kwaliteit in een project is een aanpak voorhanden met stappen die situationeel in iedere fase van het project ingevuld kunnen worden. Ter ondersteuning zijn checklists beschikbaar. Kwaliteitsbeheersing zelf, kwaliteit van het ontwikkel- en implementatieproces en de kwaliteit van het product moeten voortdurend op elkaar afgestemd worden. De basisfilosofie hierbij staat in figuur 2.1 weergegeven: Figuur 2.1 KWALITEITSBEHEERSING

IMPLEMENTATIE (DEEL)PROCES(TUSSEN)PRODUCT

VOLGENDE IMPLEMENTATIE (DEEL)PROCES

Valkuilen Valkuil 1 onvoldoende duidelijkheid

Een faalfactor van formaat is dat het management onvoldoende duidelijkheid kan geven over het doel en de wijze van uitvoering van kwaliteitsbeheer. Met name in de voorbereidende fasen van het project is het aan het management om aan te geven: - wat in hun ogen de toegevoegde waarde van het informatiesysteem is - wat het onder een geslaagde implementatie verstaat - welke consequentie daaruit getrokken kan worden.

14

Valkuil 2

door anderen uitgewerkte normen

Het werken met door anderen uitgewerkte normen brengt een aantal risico's met zich mee: - Alle daarin genoemde normen worden gewoonweg overgenomen, zonder dat men zich afvraagt wat belangrijk is. - Er worden te veel zaken onnodig gecontroleerd, ook zaken die voor het vervolg van het project minder grote consequenties hebben als de kwaliteit iets lager is. - Elke bedrijfs- en projectsituatie is weer anders. Worden normen zonder meer overgenomen dan zijn die niet toegesneden op het eigen implementatieproject.

Valkuil 3

uitsluitend 'harde' kwaliteitsnormen

Neem niet uitsluitend kwaliteitseisen op indien ze alleen met 'harde' cijfers zijn te omschrijven. Het kwaliteitsrapport geeft dan slechts cijfermateriaal weer en verdoezelt minder hard meetbare, maar misschien net zo essentile zaken. Voorbeeld: aan het eind van de selectiefase wordt uitgebreid gerapporteerd over de performance en andere technische kwaliteiten van een logistiek pakket. Bij de daarop volgende invoeringsfase ontstaan grote problemen in de acceptatie van het pakket, omdat men niet had onderkend dat het nieuwe systeem nogal veel eisen stelde aan het aanpassingsvermogen van de gebruikers. Nog te vaak wordt alle aandacht gericht op het formuleren van kwaliteitseisen van factoren die de doelmatigheid en doeltreffendheid van het informatiesysteem verhogen. Overwogen moet worden ook elementen van het informatiesysteem te bezien die een specifieke toegevoegde waarde voor de organisatie hebben of een innovatieve bijdrage leveren.

Valkuil 4

aparte kwaliteitsfunctionaris

Aan het voor de duur van het project toewijzen van alle beheerstaken aan een aparte functionaris of projectgroep kleven een aantal risico's. Het belangrijkste gevaar is dat betrokkenen zich een gesoleerde status aanmeten of krijgen opgedrongen en vanuit die positie zelfstandig bepalen aan welke kwaliteitseisen de producten moeten voldoen. Kwaliteitscontrole wordt in zo'n geval eerder een blok aan het been van het project dan dat het een nuttige bijdrage kan leveren.

Valkuil 5

verslappen van de aandacht

Alle betrokkenen, ook projectmedewerkers waaraan geen specifieke kwaliteitstaken zijn toebedeeld, moeten tijdens het gehele project alert worden gehouden. Ook na de invoering, van het systeem moet vanuit het management voldoende aandacht blijven bestaan voor kwaliteitsaspecten als: onderhoud: nieuwe releases beoordelen, testen, accepteren en invoeren, tuning van performance, enzovoort; ondersteuning: helpdesk, training nieuwe gebruikers, documentatie, service door leverancier, enzovoort; toetsing: voldoet het systeem nog steeds, ook bij veranderde omstandigheden of beleid? 15

SIM-GEBIED 3: BEVORDERING

ACCEPTATIE

In de implementatie staat de effectiviteit van de organisatie voorop; met het te implementeren informatiesysteem moet de organisatie in staat zijn doeltreffender te opereren. Dat kan door een goede integratie van informatiesysteem en organisatie. De effectiviteit wordt, zoals de bekende formule Effectiviteit = Kwaliteit x Acceptatie zegt, bepaald door de kwaliteit van het informatiesysteem n de acceptatie ervan in de organisatie (of zelfs daarbuiten, denk bijvoorbeeld aan een project als dat van de studiefinanciering). De vraag die het management zich daarbij kan stellen is de volgende: Welke acceptatievariabelen van mijn organisatie moet ik - met de kenmerkende eigenschappen van project en organisatie in het achterhoofd - benvloeden c.q. bevorderen om tot een goede acceptatie(strategie) van het informatiesysteem te komen? Als we een goede strategie voor de acceptatie willen uitstippelen, dienen we eerst een goed beeld te hebben van de organisatie en de mensen die daarin werkzaam zijn. Naast deze organisatiefactoren wordt ook vanuit het implementatieproject zelf invloed uitgeoefend op de acceptatie. Enerzijds hangt dat samen met het informatiesysteem, anderzijds met de wijze waarop die benvloeding vanuit het project plaatsvindt. Wanneer de organisatie- en projectfactoren zijn verkend, hebben we ons een beeld gevormd over de mate van acceptatie die we mogen verwachten. We hebben als het ware een krachtenveldanalyse gemaakt op basis waarvan we beter keuzes kunnen maken inzake de acceptatiestrategie. Op welke punten kan het management nu keuzes maken en hoe geeft het inhoud en vorm aan de acceptatiestrategie? Ten behoeve van deze keuzes worden zeven acceptatievariabelen onderscheiden: 1. Onzekerheid. De mate van onzekerheid over organisatie en project die het management wil laten bestaan. 2. Medezeggenschap. De mate van medezeggenschap over de besluiten die in het kader van het project genomen moeten worden, die het management wil toestaan en bevorderen. 3. Gebruikersparticipatie. De mate van participatie van gebruikers die het management wil toestaan en bevorderen. 4. Promotie. De mate van bekendheid die het management aan het project wil geven en het beeld dat daarvan gegeven moet worden in en buiten de organisatie. 5. Weerstand. De wijze waarop het management om wil gaan met weerstand. 6. Bijsturing. De mate waarin het management besturing tijdens en na het implementatieproject wil toestaan en bevorderen. 7. Effecten. De mate waarin het management als nadelig beschouwde effecten wil vermijden of compenseren. 16

De onderscheiden acceptatievariabelen moeten beschouwd worden als aandachtspunten voor een acceptatiestrategie en als hulpmiddelen om de overwegingen die er aan ten grondslag liggen bespreekbaar te maken. Figuur 3.1 verkenning omgevingsfactor en verkenning projectfactoren

acceptatievariabelen

acceptatiestrategie

ACCEPTATIE

17

Valkuilen Valkuil 1 acceptatie niet erkend als succesfactor

De eerste valkuil die wij zichtbaar willen maken, is het niet erkennen van acceptatie als een succesfactor. In nogal wat organisaties is automatisering tegenwoordig een soort vervolgautomatisering. Wanneer de medewerkers en het middenkader gewend zijn aan veranderingen die automatisering nu eenmaal met zich meebrengt, lijkt er niet veel reden te zijn om zorgen te hebben over de acceptatie. Toch kan de schijn hier bedriegen. Zolang het om kleine aanpassingen gaat, zal men op dit vlak wellicht geen problemen ontmoeten. Maar iedere grote verandering of een cumulatie van kleine veranderingen kan wel degelijk onzekerheid veroorzaken en daarmee een acceptatieprobleem.

Valkuil 2

te grof geschut

Ook het tegenovergestelde van valkuil 1 kan een valkuil zijn. Het management maakt zich veel zorgen over de acceptatie dat er te veel energie in gestoken wordt. Op zichzelf is dat niet zo erg, maar van de weer-omstuit kan er wel verwarring en dus een acceptatieprobleem ontstaan. Een verandering die de medewerkers geneigd zijn te aanvaarden, kan er heel anders uit gaan zien als daar bijvoorbeeld veel besprekingen over zijn, als het management met alle macht probeert te overtuigen daar waar het eigenlijk niet nodig is of als de 'oorlogtrommels' te snel worden geroerd.

Valkuil 3

een slagveld bieden

Juist rond veranderingen in organisaties willen partijen die elkaar niet zo liggen nog wel eens een onderlinge strijd aangaan. Wanneer in de zorg die gegeven wordt aan het bereiken van acceptatie geen rekening wordt gehouden met strijd die eigenlijk buiten het project ligt, kan het, tot verbazing van de goedwillende projectleider, gebeuren dat de gewenste overeenstemming wordt geblokkeerd door de elkaar bestrijdende partijen. Men moet ervoor zorgen deze partijen geen ruimte te bieden voor een slagveld. Zorg er bijvoorbeeld voor dat verantwoordelijke managers voldoende in het project zijn betrokken. Zij kunnen een dergelijke strijd vaak niet lang volhouden; bovendien zijn zij dikwijls meer bedreven in het op tijd ontwijken van al te openlijke 'vijandigheden'.

18

SIM-GEBIED 4: O&I ONTWERPBij implementaties kunnen we te maken hebben met situaties waarbij of de programmatuur (bijvoorbeeld een softwarepakket), de organisatie of beiden in aanmerkelijke zin aangepast moeten worden. In die gevallen is het nodig dat eerst wordt onderzocht op welke punten aanpassingen in de organisatie of informatievoorziening gewenst of nodig is, hoe die aangebracht moeten worden en wat eventuele consequenties zijn. Voor een goed begrip van het ontwerp van O&I wordt dit gebied vanuit twee invalshoeken benaderd: ADe activiteiten die ontplooid moeten worden: we onderscheiden hierbij 3 hoofdactiviteiten, te weten beschrijving van de bestaande O&I, de veranderingsanalyse en het ontwerpen van Organisatie & Informatievoorziening. BDe verschillende aspecten van het ontwerp: organisatiestructuur, administratieve organisatie en informatiearchitectuur. Het uiteindelijke resultaat is een operationeel ontwerp van O&I in de vorm van taakbeschrijvingen, taakverdelingen, functiebeschrijvingen, proces- en procedurebeschrijvingen, programmas, gegevensmodellen, beschrijvingen van de technische infrastructuur, etc. De samenhang tussen de verschillende invalshoeken is in figuur 4.1 weergegeven. Figuur 4.1 organisatiestructuur beschrijving administratieve informatieorganisatie architectuur

beschrijving bestaande organisatiestructuur administratieve organisatie en informatiearchitectuur

veranderingsanalyse

analyse veranderingsbehoeften en -mogelijkheden

conceptueel ontwerp

ontwerp organisati e-

raamwerk administrati eve

functioneel en technisch

operationeel ontwerp en beschrijvingen

programmas, taakbeschrijproceduregegevensbestanden vingen en beschrijvingen -verdeling technische infrastructuur 19

Bij het beschrijven van de bestaande situatie gaat het om het zo goed mogelijk in kaart brengen van organisatiestructuur, het raamwerk van de administratieve organisatie en de informatiearchitectuur. Hierbij wordt zoveel mogelijk gebruikt gemaakt van bestaande beschrijvingen. Dit inzicht in de bestaande situatie is noodzakelijk voor: - een goede verankering van deze situatie: zo ziet het er op dit moment uit; - het beter, op concrete gronden bespreekbaar maken van veranderingen en ontwerp van de nieuwe situatie. Resultaten van deze eerste hoofdactiviteit zijn bijvoorbeeld organogrammen, beschrijvingen van processen en administratieve procedures, ISAC A-schemas, interne controlemaatregelen, gegevensklassen. De veranderingsanalyse is een onontbeerlijke (tussen)stap om tot een goed ontwerp te komen: het vaststellen van de wijze van veranderen dient richting en houvast te geven aan degenen die het uiteindelijke ontwerp O&I moeten maken. Nagegaan wordt wat de wensen en behoeften ten aanzien van de informatievoorziening zijn, en afgewogen worden de (on)mogelijkheden van verandering. Vragen die hierbij aan de orde zijn: 'Wat mag wel en niet aangepast worden? Welke gevolgen zijn aanvaardbaar en haalbaar? Mogen er gedwongen ontslagen vallen?'. Vanuit de inventarisatie van behoeften en mogelijkheden worden veranderingsmaatregelen en het uiteindelijke doel (bijvoorbeeld 'afhandeling schadeclaim binnen 3 dagen) vastgesteld. Het ontwerpen van de organisatie en de informatievoorziening is een creatief proces, waarbij de betrokken organisatie actief ingezet moet worden. Voor een goede uitkomst is een goede sturing en directe begeleiding van het betreffende management beslist noodzakelijk. Ten aanzien van de organisatiestructuur moeten bewuste keuzes worden gemaakt ten aanzien van de samenstelling van taken en functies en de vorming van groepen/afdelingen; het verdient aanbeveling dit in een aantal stappen te doen, van grof naar fijn. De administratieve organisatie vormt de brug tussen het ontwerp van de organisatiestructuur en het functioneel technische ontwerp. Het gaat om het ontwerpen van logische en controleerbare informatieprocessen in een organisatie en de juiste toekenning van bevoegdheden en autorisatie. De veranderingsanalyse en het ontwerpen van een nieuwe situatie, van de organisatie en informatievoorziening zal in de praktijk meestal voor een deel parallel verlopen. Na de eerste analyse is het aan te raden vooral bij complexe situaties in een aantal stappen afwisselend een ontwerpfase en een analysefase uit te voeren. Het ontwerp van een nieuwe situatie is nodig voor nadere uitwerking van, onder meer een taakontwerp, een ontwerp van procedures en een technisch systeemontwerp. Die ontwerpen leiden tot de uiteindelijk gewenste producten als taakbeschrijving en verdeling, procedures en programma's. In het proces van O&I ontwerp zijn een aantal stappen te onderkennen: deze zijn in de hiernavolgende figuur op een rij gezet. De benodigde hoeveelheid aandacht en tijd voor elke stap is afhankelijk van de mate waarin programmatuur of organisatie aangepast moet worden. stap 1 begrens en bepaal diepgang analyse en ontwerp stap 2 verzamel gedocumenteerde gegevens 20

stap 3 verzamel nietgedocumenteerde gegevens

stap 4 beschrijf de bestaande situatie stap 5 analyseer veranderingsbehoeften en -mogelijkheden stap 6 ontwerp een nieuwe structuur stap 7 valideer en rapporteer

21

De stappen veranderingsanalyse en ontwerpen van de nieuwe situatie worden in de praktijk voor een deel parallel uitgevoerd. Met name bij complexe ontwerpen is het aan te raden na de eerste (globale) analyse in een aantal stappen afwisselend de ontwerpen analysefasen te doorlopen. Voor de beschrijving, de analyse en het ontwerp van een organisatiestructuur zijn vele aan de organisatiekunde ontleende hulpmiddelen beschikbaar. Dat kunnen eenvoudige inzichtgevende modellen zijn, maar ook geautomatiseerde hulpmiddelen voor het in schema brengen van de organisatiestructuur. Valkuilen Valkuil 1 de overschakeling werkt niet

De activiteitenbeschrijving, analyse en ontwerp hebben een nauwe relatie: een ontwerp kan niet zonder een analyse en een analyse kan niet zonder beschrijving. Daarnaast hebben de 'objecten' ook een onlosmakelijke onderlinge band, althans dat zouden ze moeten hebben: organisatiestructuur, administratieve organisatie en architectuur van de informatievoorziening zijn elkaar aanvullende beschouwingswijzen van n en hetzelfde, de organisatie die zich wil verbeteren. Nu blijkt in de praktijk niets desastreuzer te zijn voor genoemde relaties dan verschillende 'beschrijvers', 'analisten' en ontwerpers', die als het erop aankomt, vinden dat zij elkaar niet nodig hebben. Wat de ontwerper wil hebben van de analist vraagt hij niet; wat de analist vraagt aan de beschrijver krijgt hij niet. Met andere woorden de overschakeling van het ene stadium van het O&I-ontwerp naar het andere verloopt problematisch. Een oplossing kan gevonden worden in een stevige cordinatie van bijvoorbeeld een projectleider of een speciaal voor het O&I-ontwerp aangestelde cordinator. Een andere mogelijkheid is het formeren van een team met beschrijvers, analisten en ontwerpers die als team de verantwoordelijkheid voor het totaal kunnen dragen. In ieder geval is het zaak om de opdrachten aan de verschillende disciplines goed te specificeren. Als de omvang van het ontwerp, de doorlooptijd en capaciteit het toelaat is n oplossing meestal afdoende: beschrijving, analyse en ontwerp worden in handen van n persoon gelegd (als die tussentijds maar niet vertrekt). Valkuil 2 de uitschakeling werkt wel

Door op deze valkuil te wijzen, willen we waarschuwen voor het verschijnsel dat deskundige analisten en ontwerpers de gebruikers 'uitschakelen'. In de meeste gevallen is dat niet omdat zij dat zo graag willen, maar zijn het de omstandigheden die dit veroorzaken. Gebruikers die in staat zijn om mee te denken over een O&I-ontwerp hebben namelijk n ding gemeen: ze hebben het te druk. Het zijn vaak de medewerkers die vanuit een stevige basis van materiekennis in allerlei ontwikkelingen worden betrokken en allerlei deskundigen moeten vertellen hoe het nu eigenlijk allemaal moet. De hulpvaardige 'deskundige' wil dan nog wel eens de veelgevraagde 'gebruiker' uit de wind houden en zelf zoveel mogelijk invullen. Wanneer het gaat om uitwerkingen is dat niet erg. Erger is als de deskundige gaat bepalen wat nu eigenlijk de grenzen zijn van het te onderzoeken object, wat de veranderingsbehoeften zijn en wat de uitgangspunten van het ontwerp. Een goede, of liever een 'echte' deskundige waakt daarvoor en schakelt de gebruiker op dit soort essentile punten altijd in, ook als het betekent dat hij even moet wachten.

22

Valkuil 3

het 'oog' van de specialist

Specialisten, hetzij op het gebied van de ontwikkeling van een informatiesysteem, hetzij op het terrein van de organisatie waar geautomatiseerd gaat worden, zijn onmisbaar voor het O&I-ontwerp. Zij zorgen ervoor dat er reIe doelen worden gesteld en planningen worden gemaakt, dat de juiste hulpmiddelen worden gebruikt, dat de juiste procedures worden afgelopen, dat gerichte informatie op tafel komt en wordt verwerkt, enzovoort. Toch moet de manager ook een beetje voorzichtig zijn met de specialisten. Het zal niet de eerste keer zijn dat ze er 'met de organisatie vandoor gaan'. Dat wil zeggen dat ze hun eigen interpretatie en oplossingen doordouwen en de manager en gebruikers achterlaten met wat werkelijk het probleem is. Specialisten - en we kunnen allemaal bij tijd en wijle in die rol verzeild raken - hebben namelijk nogal eens de neiging 'hun' soort probleem als extra groot te zien en 'hun' soort oplossing als feitelijk de enige. Bovendien zijn zeer goed ingevoerde specialisten vreemd genoeg uitstekend in staat om zich bezig te houden met een veelheid aan symptomen, maar de oorzaken niet meer te zien. Als laatste waarschuwing geldt dat specialisten vaak een 'hoger' historisch besef hebben dan managers. Daarmee wordt bedoeld dat zij van bepaalde problematieken veel van de historie weten en deze ook in hun beschouwing mee laten spelen. Op zich is dat goed. De manager is veel meer met het 'hier en nu' en 'daar en straks' bezig", wat er soms toe leidt dat hij recente gebeurtenissen buiten hun proporties plaatst. De historisch bewuste specialist daarentegen kan juist de aansluiting met de actualiteit missen. Ook hier geldt: manager en specialist vullen elkaar aan. Valkuil 4 onuitvoerbare oplossingen

Het wil nogal eens voorkomen dat, met name in groepen, zoals bij een brainstorming, oplossingen of veranderingsmaatregelen worden bedacht die onuitvoerbaar zijn. In de euforie van de groep heeft men daar niet naar gekeken of niet te zwaar aan getild. Daarom is het goed de voorgestelde maatregelen expliciet op hun uitvoerbaarbeid te toetsen, het liefst door iemand die niet direct bij de groep betrokken is. Bekende redenen van onuitvoerbaarheid, waar men nogal eens te gemakkelijk overheen stapt zijn: te duur, tegen het algemene beleid, geen acceptatie te verwachten.

23

SIM-GEBIED 5: VOORBEREIDING

VAN INVOERING EN INTEGRATIE

Dit gebied omvat alle activiteiten voorbereidende activiteiten gericht op het: daadwerkelijk invoeren, en integreren van technische en organisatorische aspecten van het informatiesysteem in een organisatie. Bij deze voorbereiding onderscheiden we 7 modules: in iedere module zijn de voorbereiding van de invoering en integratiebenodigde activiteiten op zodanige wijze gebundeld dat daarvoor een zelfde soort kennis en ervaring benodigd is. De verschillende modules zijn in onderstaande figuur weergegeven. Figuur 5.1

2 parametrisering en basisbestanden

3 beheer informatiesystemen

4

taakontwerp 1 procedures

7 conversie

5

opleiding en gebruikershandleiding 6 gebruikerstest

5

24

Een aantal modules hebben een overwegend informatie technisch karakter: parametrisering en basisbestanden, beheer van het informatiesysteem, conversie en gebruikerstest. De overige modules dekken met name de organistorische aspecten van de voorbereiding af: procedures, taakontwerp, opleiding en gebruikershandleiding. Plannen zijn een belangrijk resultaat van de voorbereiding: plannen voor elke module, maar ook een plan waaruit de samenhang van alle modules tot uiting komt. De voorbereiding is voornamelijk gericht op het voorbereiden en in beweging zetten van de organisatie teneinde de invoering en integratie mogelijk te maken. Dit is alleen mogelijk indien alle direct betrokkenen ingeschakeld worden en bij de voorbereiding rekening wordt gehouden met de uitkomsten uit vorige SIM-gebieden (kwaliteit, acceptatie, projectaspecten, risicos en bedreigingen). Het management heeft bij de voorbereiding een belangrijke taak: - ter beschikking stellen van voldoende tijd van medewerkers; - initiren en toezien op het: opstellen van het voorbereidingsplan, vertalen van relevante bevindingen uit andere SIM-gebieden; - voorwaarden scheppen voor het verwezenlijken van de voorbereiding (voorlichting, public relations, laten zien dat het management het belangrijk vindt en erachter staat). In het hiernavolgende is een beknopte beschrijving van de verschillende modules opgenomen. Module procedures Bij de opzet van de planning van de invoering van de administratieve organisatie moet, naast de uitkomsten van het ontwerp O&I, rekening gehouden worden met de volgende aspecten. Gericht op de systeemontwikkeling: 1. Waarborgen dat de administratieve organisatie voldoende wordt meegenomen in het ontwerp. 2. Waarborgen dat de administratieve organisatie van het automatiseringsproject op voldoende peil is. Gericht op de invoering van het systeem in de organisatie: 3. Zorgen voor goed leesbare, voor iedere betrokkene toegankelijke invoeringsprocedures. Gericht op systeemgebruik en -beheer: 4. Zorgen voor een adequaat beheer van de administratieve organisatie in de nieuwe of aangepaste gebruikersorganisatie. 5. Zorgen voor heldere, toegankelijke en adequate procedures voor de invoering en verwerking van gegevens. 6. Zorgen voor heldere, toegankelijke en adequate procedures voor de uitvoer en distributie van gegevens. 7. Zorgen voor een adequaat beheer van de administratieve organisatie in de nieuwe of aangepaste automatiseringsorganisatie. Module paramatrisering De programmatuur die is ontwikkeld of is gekocht dient vaak nog aangepast te worden aan de specifieke bedrijfssituatie. Dat wil zeggen dat bepaalde variabelen die de werking van het progamma regelen nader moeten worden ingesteld. Dit wordt 'parametriseren' genoemd. 25

Op basis van onderzoek en analyse in een eerder stadium van het project is vastgesteld welke informatiebehoeften vervuld moeten worden door het informatiesysteem en welke eisen er aan de programmatuur gesteld dienen te worden. Deze eisen worden nu in de programmatuur ingevuld. Van belang is dat nagegaan wordt of voorkomende wijzigingen in administratieve procedures (zie vorige module) consequenties kunnen hebben voor de parametrisering.

Module beheer systemen De exploitatie van geautomatiseerde informatiesystemen begint formeel na de overdracht. De wijze waarop dat gebeurt, wordt aangeduid met systeembeheer'. De uitvoering van dit systeembeheer is een directe verantwoordelijkheid van het management wat eigenaar is van het systeem. Om tot een goed inzicht in het systeembeheerproces te komen, worden in deze module de volgende zeven te beheersen aspecten onderscheiden: 1. 2. 3. 4. 5. 6. 7. (applicatie)programmatuur: wijzigingen, onderhoud, documentering; gegevens: wijze van beheer van gegevens en vastlegging van metagegevens; technische infrastructuur: garanderen van beschikbaarheid en prestaties; organisatie: wijze van invulling, van functionele en technische beheerstaken; contracten: beheer van afspraken (met name extern) ten aanzien van levering, ontwikkeling, installatie en onderhoud van (applicatie)programmatuur en technische infrastructuur; procedures: afspraken over wijze van afhandelen van wijzigingen, inkoop, overdracht, onderhoud, etcetera; beveiliging: maatregelen voor het waarborgen van voldoende betrouwbaarheid, continuteit en exclusiviteit.

De eerste drie aspecten vormen daarbij de kern van het (geautomatiseerde) informatiesysteem: zij zijn van directe invloed op het functioneren van het systeem. De daaropvolgende vier aspecten ondersteunen deze kern: zij hebben geen directe invloed op het functioneren van het informatiesysteem. Module taakontwerp In deze voorbereidingsmodule moet gezorgd worden voor een goede opbouw van taken en functies, rekening houdend met de in het gebied Ontwerp O&I aangegeven raamwerk. Bij het taakontwerp moet gestreefd worden naar een evenwichtige balans tussen: de organisatorische aspecten: opbouw van taken, afstemming mens-machine, samenstelling van werkeenheden, etc. sociale factoren: werkomstandigheden, ontplooiingsmogelijkheden en behoeften van individuele medewerkers, etc. De uitkomst van deze module is een plan voor de realisatie van de voorgenomen organisatorische veranderingen. In de planning van de implementatie moeten de volgende zaken worden afgedekt: 1. 2. 3. 4. Waarborgen dat er een taak- en functieontwerp wordt gemaakt. Zorgen voor duidelijke taak- en functiebeschrijvingen voor de nieuwe situatie. Zorgen voor een organisatie-ontwerp van de toekomstige situatie. Waarborgen dat de noodzakelijke organisatorische veranderingen gerealiseerd worden.

Module opleiding en gebruikershandleidingen

26

Veranderingen vereisen opleiding en training. De veranderingen zijn uitgewerkt in het gebied Ontwerp O&I. Het doel van opleiding en gebruikershandleidingen is de gebruiker in staat te stellen met het systeem te werken, de beheerders in staat te stellen om het systeem te beheren en het management de handvatten te bieden om over het systeem te kunnen beslissen. Ten aanzien van de gebruikershandleidingen is de voorbereiding gericht op: het vaststellen van de benodigde documentatie voor opleiding en naslag; bepalen van zaken als opzet, lay-out, indeling; het opstellen van een planning, wie wat gaat maken, wat de benodigde hulpmiddelen zijn.

27

Module gebruikerstest en overdracht De gebruikerstest is meer dan alleen een laatste formele controle voordat het systeem ingevoerd gaat worden. Een dergelijke test moet (ook) gezien worden als een test die gericht is op het overdragen en in gebruik nemen van het informatiesysteem. Bij een gebruikerstest dient, naast de zuiver functionele test, ook nagegaan te worden of de gebruikers vertrouwen hebben in het systeem en bereid zijn het te gaan gebruiken. De verantwoordelijkheid van de manager en de projectleider zit net als bij de andere modulen in de besturing en bewaking van het proces. Dat betekent aansturing op hoofdpunten met een plan, informatie verzamelen over het verloop, eventueel bijsturen, evalueren en afsluiten. Daarnaast is het management verantwoordelijk voor het aangeven van de belangrijkste toetsingscriteria: wat is de essentie van het informatiesysteem, welke onderdelen moeten vlekkeloos functioneren. Module conversie Bij de invoering van systemen krijgt de (automatiserings)manager zeker te maken met conversie. Bij nieuwbouw en de aanschaf van een pakket moeten nieuwe bestanden worden gevuld; wordt besloten bestaande systemen te renoveren of op een nieuwe technische infrastructuur over te gaan, dan moeten hele applicaties worden aangepast. Het management heeft als taak erop toe te zien dat een conversie zorgvuldig wordt voorbereid en in een zo vroeg mogelijk stadium wordt aangepakt. Voorkomen moet worden dat men op het laatste moment voor de invoering van een nieuw informatiesysteem geconfronteerd wordt met de onhaalbaarheid van een eenmalige conversie. Het op dat moment gehaast in elkaar knutselen van een gefaseerde invoering is een riskante onderneming. Bij het plannen moet er dus op gelet worden dat in een vroeg stadium tijd ingeruimd wordt voor onderzoek naar de (on)mogelijkheden van een conversie in n stap.

28

SIM-GEBIED 6: INVOERINGDe voorgaande stappen van SIM zijn allen gericht op een goede voorbereiding van de invoering en de integratie van organisatie en systeem. Er zijn schattingen gemaakt van risico's en effecten, er is een acceptatiestrategie uitgewerkt en er is gewerkt aan kwaliteitsborging en organisatieverandering. In dit SIM-gebied gaat het erom de invoering (het moment van omschakeling) goed in te zetten en soepel te laten verlopen: de werkzaamheden die zijn voorbereid in de vorige fasen worden uitgevoerd. De invoering van een informatiesysteem is een fase in het project die de directe aandacht vraagt van de manager. Zijn of haar afdeling moet overschakelen; taken, bevoegdheden en verantwoordelijkheden veranderen, het nieuwe informatiesysteem moet opgenomen en gentegreerd worden in de organisatie. De verantwoordelijke lijnmanager(s) moet(en) derhalve een centrale rol spelen in de invoering, hetgeen vereist dat hij/zij voldoende tijd vrijmaakt om dit veranderingsproject te kunnen realiseren. Daarnaast spelen ook de beheerders van het informatiesysteem een belangrijke rol bij de invoering: zij hebben daarin de taak van intermediair tussen ontwikkeling/onderhoud van het systeem en het gebruik ervan. De gebruikers van het nieuwe informatiesysteem zijn potentile slachtoffers. Al het werk dat aan de invoering vastzit, de planning en voorbereiding daarvan, al het overleg tussen managers, beheerders en ontwikkelaars, dat alles wil er nog wel eens de oorzaak van zijn dat de gebruikers (te lang) buiten beeld blijven. Goede voorlichting t.a.v. de invoering en opleiding/training is noodzakelijk, met name voor diegenen die intensief met het nieuwe systeem (gaan) werken. Kenmerkend voor de invoering is dat in een korte periode veel geregeld moet worden: dit vereist een projectbesturing waarin snel en effectief gehandeld kan worden. Het management moet zich afvragen of de bestaande projectorganisatie daarvoor geschikt is of dat er een apart invoeringsteam ingesteld dient te worden. Een dergelijk invoeringsteam, die voor de duur van de overgang de dagelijkse zaken behartigd, bestaat meestal uit een projectleider, n of meer kerngebruikers, n of meer beheerders en een ontwikkelaar. De invoering van een informatiesysteem heeft een grote kans van slagen indien aan de volgende basisvoorwaarden is voldaan: - de uitslag van systeem- en gebruikerstest is positief; - gebruikers en management zijn voldoende gemotiveerd en bereid om de noodzakelijke veranderingen door te voeren; - de nieuwe organisatiestructuur en de administratieve organisatie zijn geschikt en gereed; - de invoeringschecklist is nagelopen en alle punten zijn afgehandeld. Het invoeren van een informatiesysteem kan op een aantal wijzen aangepakt worden. Grofweg zijn er 3 hoofdalternatieven te onderscheiden (SDM II): 1. 2. 3. Het gehele systeem ineens invoeren (de 'grote sprong voorwaarts'); Het systeem in fasen invoeren ('in stappen vooruit'); Het systeem invoeren na parallelverwerking van oud en nieuw systeem ('schaduwdraaien'). De keuze van wijze van invoering is evenals zoveel andere keuzes binnen SIM 'contingent'. Dat wil zeggen dat het management de consequenties van elk alternatief in ogenschouw moet nemen en naar bevinding van zaken een passende keuze moet maken. De afweging van een gefaseerde overgang dient in een zo vroeg mogelijk stadium plaats te vinden: bij nieuwbouw van complexe, omvangrijke systemen eigenlijk al in de (globale) ontwerpfase.

29

De overdracht van het nieuwe informatiesysteem van ontwikkelaars naar gebruikers/beheerders markeert de feitelijke invoering van het systeem. Het houdt tevens in dat de verantwoordelijkheden over het systeem en de daarbij behorende bevoegdheden bij het operationele management komen te liggen. Bij de overdracht worden de leveranciers/ontwikkelaars ontslagen van hun verplichtingen, en worden nieuwe verplichtingen aangegaan met degenen die het systeem gaan gebruiken en beheren. De overdracht is een dermate belangrijke mijlpaal dat wij ervoor pleiten een soort van protocol op te stellen waarin wordt geregeld wie wat accepteert, op grond van welke condities en hoe eventueel 'achterstallig onderhoud' wordt afgewikkeld. In de invoering komt veel van wat is voorbereid samen in een relatief korte tijd. De proef van alle inspanningen zit in feite in de invoering. De integratie van informatiesysteem en organisatie begint dan pas echt gestalte te krijgen. De periode na de invoering is eveneens belangrijk voor de integratie, maar toch heeft de invoering voor de organisatie als het ware de betekenis van een eerste beslissende indruk of het wel wat wordt met het nieuwe systeem. In dat licht gezien is een vlekkeloos verloop van de invoering een geweldige steun in de rug voor het management en de betrokken organisatie. Door de complexiteit en de snelheid blijken in de praktijk altijd onverwachte gebeurtenissen op te treden: een 100% probleemloze invoering is een zeldzaamheid. Teneinde het aantal problemen te reduceren is het aan te bevelen om voor de invoering een gedetailleerde planning te maken, een 'invoeringsdraaiboek', waarin alle invoeringsactiviteiten zijn aangegeven.

30

Valkuilen Valkuil 1 de 'geruisloze' invoering

Het wil nogal eens voorkomen dat een projectleider droomt van een invoering die zo verloopt dat eigenlijk niemand het merkt. Dat wil zeggen, als het allemaal gelukt is, zal de gebruiker op een goede dag tot zijn verassing merken dat hij plotseling probleemloos in een nieuw systeem werkt. En als het allemaal niet lukt, ploegt de gebruiker gewoon door op het vertrouwde akkertje zonder zich zenuwachtig te maken over het uitblijven van het nieuwe' systeem. Deze droom wordt nooit werkelijkheid. Ook niet als de invoering geleidelijk, gefaseerd, in stappen, of noem maar op, plaatsvindt. Er is altijd commotie, er is altijd beweging, er is altijd onzekerheid. Beter is om daar maar op in te spelen. Door bijvoorbeeld van de invoering een 'happening' te maken, met bijeenkomsten, toespraken en bloemen. Of snelle evaluaties-enqutes. Kortom, het is de kunst om zelf als eerste kabaal te maken dat nu eenmaal onvermijdelijk is en daarbij de positieve toon te zetten.

Valkuil 2 het invoeringsteam ziet het zelf niet zitten Van een droom naar een nachtmerrie. De titel van deze valkuil spreekt eigenlijk voor zich. Er zijn globaal vier niveaus waarop een invoeringsteam het niet ziet zitten. het team acht succesvolle invoering (nog) niet haalbaar; het team of leden daarvan hebben bezwaren tegen het nieuwe systeem en de veranderingen die daarmee samenhangen; het team heeft eigenlijk geen idee van het 'eindproduct': hoe zien de nieuwe procedures en programmas er uit, hoe werkt de apparatuur en programmatuur, wie krijgt welke taken, en meer van dat soort vragen; leden van het team kunnen niet of moeilijk samenwerken. De vraag is hier niet of dit erg is voor de invoering, maar veeleer of er iets erger te bedenken is. Een negatief ingesteld of niet voor zijn taak berekend invoeringsteam is een absolute faalfactor voor de implementatie. Het recept is eenvoudig. Kies de leden van het team met zorg uit, laat ze zelf over hun invoeringstaak meebeslissen en zorg dat ze goed ingevoerd zijn in het nieuwe systeem.

Valkuil 3

overdracht aan de verkeerde

Het klinkt misschien vreemd maar overdracht aan de verkeerde functionaris komt veelvuldig voor. Het systeem wordt in die gevallen namelijk overgedragen aan de technisch systeembeheerder, de chef rekencentrum, het hoofd van de automatiseringsafdeling of aan de informatiemanager. Het aantrekkelijke van deze mensen is dat ze overdrachten al eerder hebben meegemaakt, meestal goed (denken te) weten waar het over gaat en meer in het algemeen een redelijk prettige gesprekspartner zijn voor de ontwikkelaars en de leveranciers. Toch zijn het helaas de verkeerde mensen, en dat om maar n reden: zij zijn niet de gebruiker van het systeem. Ze kunnen weliswaar de gebruikers vertegenwoordigen, maar ze zijn het niet zelf. En voor de formele overdracht mag geen genoegen genomen worden met een vertegenwoordiger van de gebruikers, maar moet het management

31

van de gebruikers zelf het systeem aanvaarden. Anders is er grote kans dat er rond het informatiesysteem een 'verantwoordelijkheidsvacum' ontstaat. De manager kan zich bij de beantwoording van de vraag "wat ga ik nu eigenlijk precies aanvaarden en is dat wel verantwoord?" natuurlijk laten bijstaan door de eerder genoemde 'verkeerde' functionarissen. Bovendien zal nadat de formele overdracht is gepasseerd het feitelijke gebruik en beheer worden gedelegeerd aan gebruikers en beheerders.

SIM-GEBIED 7: NAZORGNazorg is in termen van SIM het vervolg op de invoering, de afronding van de integratie van het systeem in de organisatie. Tijdens de nazorg worden knelpunten opgespoord in de integratie van het informatiesysteem en de organisatie en worden oplossingen hiervoor gezocht. Daarbij wordt goed gelet op de faalfactoren die nog roet in het eten kunnen gooien. Te denken valt aan bijvoorbeeld: - niet op tijd opgeleide eindgebruikers; - alsnog optredende weerstand, omdat eventuele 'gevaren' nu pas reel worden; - niet (goed) werkende hardware; - naleveringsafspraken van hard- en software worden niet nagekomen; - 'afwerkpunten' worden niet tijdig opgelost; - documentatie is niet orde. Welke zaken moeten worden nagegaan om tot een goede inrichting van de nazorg te komen? Uit de andere gebieden van SIM is daarvoor informatie te vergaren betreffende: - de implementatiestrategie; - de kwaliteitszorg; - de project- en systeemrisico's; - de te vermijden effecten en consequenties (voor de nazorg zijn deze wezenlijke meetpunten); - de administratieve organisatie; - de procedures; - de opzet van het systeembeheer en de beveiliging; - het taak-, functie en organisatie-ontwerp; - het conversieplan; - de gebruikersdocumentatie en de handboeken; - de afwerkpunten uit de acceptatietest; - het voorlichtingsplan; - het opleidingsplan. De nazorg is een wezenlijk onderdeel van het implementatieproject. Hoewel de verleiding groot zal zijn, mag de projectorganisatie nog niet ontbonden worden voordat deze fase is doorlopen. Ontbinding betekent immers dat verantwoordelijkheden en bevoegdheden die nodig zijn om de integratie te laten slagen niet meer in projectverband worden ingevuld. Wel kan overwogen worden om de projectorganisatie indien nodig op een aantal plaatsen bij te stellen. De nazorg kan als afgesloten worden beschouwd indien het systeem naar behoren in de organisatie is gentegreerd: - er wordt gewerkt volgens de nieuwe werkwijzen, procedures en programma's; - de medewerkers werken voldoende zelfstandig met het nieuwe systeem; - het product van de betreffende afdelingen/groepen voldoet aan de verwachtingen. Het verdient aanbeveling de nazorg af te sluiten met een evaluatie, die tot doel heeft: een goed beeld te krijgen van de werking en mate van integratie van het nieuwe systeem: welke laatste punten moeten nog afgewerkt worden?

32

de ervaringen boven tafel te krijgen ten aanzien implementatieproces: wat hebben we ervan geleerd?

van

het

afgelopen

33

Bij de uitvoering van de nazorg onderkennen we de volgende stappen: stap 1 stap 2 stap 3 stap 4 stap 5 stap 6 stap 7 verzamel 'nazorg'gegevens organiseer de nazorg werk de 'nazorg'checklist af sluit de nazorg af evalueer product en proces rapporteer over nazorg en evaluatie sluit het implementatieproject af

Valkuil

wordt uitgevoerd. We hebben reeds gewezen op het gevaar van een te vroege ontbinding van het projectteam. Maar ook als dat niet gebeurt, dan nog is succes niet verzekerd. In dit stadium van het project hangt alles af van het verantwoordelijke lijnmanagement. Zelfs zo sterk dat we in navolging van de MANS-filosofie willen stellen dat onvoldoende nazorg en dus onvoldoende integratie voor 80% geweten mag worden aan het lijnmanagement. Bij de opleiding en training van dat management dient derhalve primair aandacht te worden gegeven aan het integratie-aspect van de automatisering. Het topmanagement van de organisatie zal het lijnmanagement op dit punt in het bijzonder moeten aanspreken. Daarmee kan een directeur zijn belangstelling voor het project en de waarde die hij eraan hecht beter tonen dan met af en toe kennis te nemen van de projectverslagen of iets dergelijks.

34

TENSLOTTEDe hantering van SIM kan managers, projectleiders en hun adviseurs helpen om de implementatie goed voor te bereiden en uit te voeren. Daarmee kunnen de vele valkuilen op de weg van de integratie van een nieuw informatiesysteem met organisatie worden vermeden. Het doel waarom het allemaal was begonnen - de verbetering van prestaties van de organisatie - komt daarmee zeker dichterbij. Niet alle organisaties hebben de mogelijkheden en de expertise om implementaties goed op te zetten en uit voeren. Het inhuren van ervaren implementatiedeskundigen kan dan uitkomst bieden. Vrisou van Eck & Associates en Steenwinkel, Kruithof en Associates zijn n van de weinige adviesbureaus in Nederland die deze deskundigheid in huis hebben. In de afgelopen jaren zijn veel implementatieprojecten met succes afgesloten onder leiding van n van de adviseurs van het bureau. Daarbij waren projecten binnen de overheid (onder andere het subsidie informatiesysteem van de Ziekenfondsraad), binnen nutsbedrijven (financile informatiesystemen, geautomatiseerde projectenadministraties en geografische informatiesystemen) en voor het bedrijfsleven (onder meer logistieke informatiesystemen).

35