Ed Kruithof Margareth Jonker

Samenvatting SIM3
fasen
voorbereiden ontwerpen inrichten invoeren integreren

fasen
besturing ontwikkelen voorbereide ontwerpen inrichten managementinformatie; n opzetten en inrichten beheer informatiesysteem business process re-engineering organisatieverandering; mentale implementatie; VOTW informatieanalyse, gegevensmodellering en conversie aanschaf, bouw, aanpassing, test en installatie kennismanagement verandermanagement kwaliteitsmanagement technische middelen contractmanagement projectorganisatie invoeren integreren

bedrijfsprocessen

mensen

informatie

objecten van verandering

project

Samenvatting

Systeem implementatie methode3

Betreft samenvatting van: Ed Kruithof en Margareth Jonker, 'Systeem Implementatie Methode 3' Uitgever Academic Service (2000), ISBN 90 395 1574 3 en 90 395 1575 1 Steenwinkel Kruithof Associates b.v. 30 juli 2002

Inhoudsopgave

Inleiding SIM3 ........................................................................................3 Implementeren ......................................................................................4 Typen implementaties .............................................................................6 Implementatieproces ..............................................................................11 Objecten van verandering........................................................................13 Managementaspecten implementatieproject...............................................23 SIM3 ....................................................................................................29

Inleiding SIM
Het SIM3-boek (Systeem Implementatie Methode 3) is de opvolger van het boek 'SIM' en bestaat uit een theorie- en een praktijkdeel. SIM werd begin jaren negentig geschreven en heeft furore gemaakt in zowel het bedrijfsleven als in het onderwijs. Door de grote veranderingen op het gebied van ICT in de jaren negentig ontstond echter de noodzaak de methode grondig te actualiseren. De toegevoegde '3' staat voor de nieuwe driedimensionaliteit van de methode. SIM3 is ontwikkeld door Ed Kruithof en Margareth Jonker, beide werkzaam bij Steenwinkel Kruithof Associates. De eerste als directeur, de tweede als management- en informatieconsultant. De toepassing van de in het boek beschreven methode kunt u terugvinden in het werk van Odinfo. Deze samenvatting is voor een ieder die kennis wil nemen van de SIM3-methode zonder daarvoor de gehele achterliggende theorie tot zich te nemen. Dit kunnen managers zijn die voor de implementatie van een informatiesysteem staan, studenten die dit een verrijking achten van hun kennis of een ander persoon die gewoon genteresseerd is in deze stof. Wij wensen u veel plezier met het lezen van de samenvatting!

IMPLEMENTEREN
Het begrip implementeren betekent in algemene zin: het uitvoeren, vervullen, verwezenlijken, effectueren, in praktijk brengen van een overeenkomst, verdrag of plan. In de informatica heeft implementeren een meer specifieke betekenis: het realiseren van een ontwerp van een deel van de informatievoorziening van een organisatie. Dit kan dus bijvoorbeeld de invoering van het softwarepakket SAP R/3 zijn om de voorraadsystemen van verschillende magazijnen van n bedrijf te integreren, of het implementeren van een Customer Relationship Managementsysteem (CRM) om beter in te kunnen spelen op de specifieke wensen van klanten.

Opvattingen over wat implementeren is in de informatica

Om een beter beeld te krijgen van alle aspecten die komen kijken bij de implementatie van een informatiesysteem, zullen we de verschillende opvattingen binnen de informatica, over wat een implementatie is, even langslopen: 1. implementatie als de overdracht van het ontwikkelde informatiesysteem aan de gebruikersorganisatie; 2. implementatie als een planningsactiviteit; 3. implementatie als sociale verandering; 4. implementatie als politiek spel; 5. implementatie als marketingactiviteit. In onze ogen geven deze visies in onderlinge samenhang een compleet beeld van alle aspecten die komen kijken bij de implementatie van een informatiesysteem.

Het verloop van het implementatieproces

Naast alle aspecten (zeg maar: aandachtsgebieden) waar we mee te maken hebben bij een implementatie, hebben we ook te maken met de manier waarop het proces van implementeren verloopt. In het denken hierover heeft de laatste twee decennia een verschuiving plaatsgevonden. Waar men vroeger een sequentieel of lineair proces voorstond, gaan er tegenwoordig steeds meer stemmen op voor een iteratief en incrementeel verloop van het proces. Sequentieel of lineair wil zeggen: een 'stap-voor-stap' aanpak. Hierbij gaat men ervan uit dat de hele implementatie van tevoren goed te plannen is. Iteratief of incrementeel wil zeggen: een zichzelf steeds herhalend groeiproces. Hierbij verloopt een implementatie dus niet in een rechte lijn. Er worden afgeronde werkpakketten onderscheiden, zoals: een procesbeschrijving, de technische installatie, contracting en de gegevensconversie. De uitvoering van de werkpakketten vindt - als dat kan - parallel plaats. Bovendien kan in de eerste fase naar een bepaald kwaliteitsniveau worden toegewerkt. In latere fasen van de implementatie wordt dat kwaliteitsniveau dan successievelijk verhoogd.

Implementatie als technische en sociale transformatie

Het ontwikkelen van een informatiesysteem is te beschouwen als een proces van organisatieverbetering specifiek gericht op de informatievoorziening en communicatie. Het bijzondere van automatisering als verbeteringsproces is het samenspel tussen informatietechnische transformatie en sociaalorganisatorische transformatie. Deze laatste is helaas altijd onderbelicht gebleven wat in nogal wat gevallen geleid heeft tot het falen van de automatisering. Twee aspecten zijn te onderscheiden bij organisatieverbetering: het ontwerp en de verandering. Ontwerpen is het in detail uitwerken van een concept, waarbij beslissingen worden genomen over de functie, vorm en constructie van een structuur. Verandering is de feitelijke transformatie van de oude naar de nieuwe structuur. Juist bij het implementeren van informatiesystemen is een permanente afstemming van technisch en organisatorisch ontwerpen en veranderen binnen de kaders van de 'business' van groot belang.

figuur <implementatie als transformatieproces>

TYPEN IMPLEMENTATIES
Hoewel implementaties nooit hetzelfde zijn, kunnen er toch enkele typen onderscheiden worden. Deze typologie is opgebouwd uit drie aspecten: categorie, scenario en strategie.

Categorie
Implementaties zijn er in veel soorten en maten. Allereerst onderscheiden we de 'scope' van de implementatie. Als slechts n of enkele bedrijfsprocessen worden ondersteund door de nieuwe ICT, spreken we van een smalle scope. De scope wordt breder naarmate er meer bedrijfsprocessen worden ondersteund. Het tweede onderscheid maken we op het punt van de impact die de implementatie zal hebben. De impact is klein als er geen ingrijpende veranderingen zijn in het werk. Andersom, als de veranderingen groot zijn is de impact groot. Hierbij valt te denken aan het verdwijnen van oude functies en/of het creren van nieuwe functies. Vervolgens is er nog een derde aspect op grond waarvan er een onderscheid gemaakt kan worden. Dit is de schaal of 'scale'. Hier gaat het om het aantal keren dat een implementatie uitgevoerd moet worden. Denk bijvoorbeeld aan een centraal geleide implementatie van een financile applicatie bij een grote bank. Als ieder filiaal gebruik moet gaan maken van deze applicatie, moet de implementatie honderden keren uitgevoerd worden. Van uit dit onderscheid zijn er vier categorien te construeren. 1e categorie is: kleine impact, smalle scope. Deze implementatie is in de regel eenvoudig. 2e categorie is: kleine impact, brede scope. Dit kost veel tijd, maar is relatief simpel. 3e categorie is: grote impact, smalle scope. Op zich is dit complex; de duur zal afhangen van hoeveel mensen gebruik gaan maken van het nieuwe informatiesysteem. 4e categorie is: grote impact, brede scope. Hier hebben we te maken met grote en complexe implementaties. Voor de implementaties van de 3e en 4e categorie is in ieder geval n zaak helder: het niet aanpassen van de werkprocessen, is onmogelijk. Dit alleen al omdat de implementatie van informatiesystemen er juist op gericht is werk dat eerst niet, handmatig, of met andere programmatuur werd gedaan, te verbeteren en dus te veranderen.

figuur <soorten implementaties>

Scenario
Naast de verschillende categorien zijn er vier scenario's denkbaar voor de implementatie van een standaard applicatie. In een scenario gaat het om de mate waarin procesverbetering of - vernieuwing - deel uit maakt van de implementatie. In scenario 1, 'proces/applicatie-afstemming en -stroomlijning (business process streamlining)', worden het applicatiepakket en de bestaande werkprocessen op elkaar afgestemd. Dit betekent dat de werkprocessen tot in detail beschreven dienen te worden. Daar waar nodig worden de werkprocessen na de implementatie verder gestroomlijnd. Dit wordt de '1 op 1' implementatie genoemd. In de praktijk zien we dat er in de periode na de implementatie vaak alsnog besloten wordt allerlei organisatorische - of erger nog softwareaanpassingen te doen. Niet zelden komt het topmanagement dan voor niet te omzeilen onverwachte investeringen te staan. Scenario 2, 'procesverbetering met het pakket als bron van verbeteringsmogelijkheden', houdt in dat de werkprocessen worden aangepast op punten waar men voordeel denkt te behalen. Ook hier zijn dus de bestaande werkprocessen uitgangspunt en is een beschrijving van die werkprocessen tot in groot detail vaak vereist. Echter wordt hier het zoeken naar verbeteringen bewust en expliciet in het implementatieproject opgenomen. Er wordt als het ware een proeftuin gecreerd. In scenario 3, 'procesontwerp op basis van de industriestandaard', is het grondplan van het standaard applicatiepakket leidend. Omdat standaard applicaties gebaseerd zijn op 'best practice'- processtructuren uit een bepaalde industrie, hoeven de werkprocessen niet tot in grote gedetailleerdheid beschreven te worden. Dit kan later gebeuren als men de applicatie wederom in een 'proeftuin' met de werkprocessen vergelijkt. Scenario 4, 'procesinnovatie los van het pakket', is een 'revolutionaire' aanpak. Hier worden de werkprocessen geheel opnieuw ontworpen, om ze efficinter en effectiever te maken, en wordt gekeken op welke punten de organisatiestructuur zal veranderen. Vervolgens wordt hier dan de best passende applicatie bij gezocht.

figuur <vier scenario's voor het aanpassen van processen in het kader van een 3e of 4e categorie-implementatie van een informatiesysteem>

Strategie
Implementatie strategien betreffen de aanpak van het sociaalorganisatorische veranderingsproces. We onderkennen vier implementatiestrategien, zoals hieronder aangegeven.

figuur <implementatiestrategien>

De dwangstrategie wordt - bewust of onbewust - nogal eens toegepast als het om een implementatie gaat met een 'revolutionair' karakter. Dit kan het geval zijn als de organisatie zelf in een dwangpositie verkeert. Denk bijvoorbeeld aan een overheidsorganisatie die een systeem, dat de uitvoering van een nieuwe wet ondersteunt, voor een bepaalde datum ingevoerd moet hebben. Deze strategie kan op een menswaardige manier worden uitgevoerd als men de werknemers met respect blijft behandelen en voldoende en kwalitatief goed communiceert. Er kleeft echter een groot nadeel aan de dwangstrategie en dat is dat de veranderingen onvoldoende verankerd worden in de organisatie en daarom niet echt beklijven. De facilitaire strategie is gericht op het ondersteunen van veranderingen 'bottom-up'. Dat wil zeggen dat de top van de organisatie algemene doelen stelt en dat units en teams hun eigen veranderingsproces organiseren en uitvoeren. Daarbij krijgen ze de middelen om hun eigen ondersteuning te regelen. Deze strategie is in feite de 'veranderingsstrategie van de toekomst' omdat het een organisatie veronderstelt die niet hirarchisch is en een organisatiecultuur die ondernemend en taakgericht is en waar groepsprestaties voorop staan. Veel organisaties beantwoorden nog niet aan dit beeld. Nu blijven de expertstrategie en de verankeringstrategie over, welke beiden geschikt zijn voor het soort implementatieproject waarover wij het hebben. Bij de expertstrategie speelt de implementator de rol van expert die zegt wat er moet gebeuren en hoe. De aandacht en ruimte voor mentale veranderingsprocessen is hier niet al te groot en dus moet er van tevoren voldoende draagvlak zijn. Cultuurveranderingen als gevolg van het implementatieproject mogen bij deze strategie dan ook niet verwacht worden.
8

In de verankeringstrategie heeft de veranderaar de rol van procesbegeleider. De 'inhoud' komt op vanuit de organisatie; de veranderaar leidt het veranderproces in goede banen. Alle belanghebbenden moeten hun invloed kunnen uitoefenen. Problemen moeten helder geformuleerd worden en er moet voldoende ruimte zijn voor beeldvorming. Deze strategie past goed bij veranderingen waar de tijdsdruk niet te hoog is en waar er naast structuurveranderingen ook een cultuurverandering gewenst is. In het soort implementatieprojecten waar het ons om te doen is, zullen we vooral te maken hebben met de expert- en verankeringstrategie. Beide strategien kunnen lineair of incrementeel worden ingevoerd. De lineaire variant houdt in dat eerst alle ontwerpen voor de hele 'scope' van het informatiesysteem worden gemaakt. Daarna worden de ontworpen componenten ingericht en gerealiseerd. Vervolgens worden ze ingevoerd in de organisatie en tenslotte worden ze gentegreerd met de dagelijkse gang van zaken. De incrementele variant houdt in dat er gewerkt wordt met een bepaald aantal 'incrementen' van de implementatie. Dat wil zeggen dat delen van het informatiesysteem worden gemplementeerd van ontwerp tot en met integratie, dus van A tot Z. De incrementen kunnen bestaan uit modules van het informatiesysteem. In deze benadering worden er een soort plateaus gecreerd, waarop de organisatie, na de implementatie van een increment, even tot rust kan komen en de gang van zaken tot dan toe kan evalueren. Ook biedt het plateau de mogelijkheid het project, om wat voor reden dan ook (tijdelijk) stil te zetten, zonder dat het werken met de verschillende modules moet worden stopgezet. Het voordeel van de lineaire variant is dat de fysieke kant van het implementatieproces goed te beheersen is. Het nadeel is dat als er zich op het mentale vlak problemen voordoen, dat het project dan volkomen kan mislukken. Het voordeel van de incrementele variant is dat de organisatie na implementatie van een increment even tot rust kan komen en kan evalueren. Hier gaan de fysieke en mentale implementatie dus hand in hand. Het nadeel is dat de kosten en doorlooptijd moeilijker zijn in te schatten.

De som
Er zijn dus vier implementatiecategorien, vier implementatiescenario's en vier implementatiestrategien. Voor implementaties van complexe informatiesystemen met een standaard applicatiepakket geldt meestal de volgende combinatie: 4e categorie, scenario 2 of 3 en de expert- of de verankeringstrategie.

impact klein

impact groot

scope breed

2e categorie

4e categorie

scope smal

1e categorie

3e categorie

hoog

scenario 4 facilitaire strategie

mate waarin procesen veranderen

scenario 3 scenario 2

scenario 1
laag laag

verankeringsstrategie
potentiele opbrengst
hoog

expertstrategie

dwangstrategie

figuur <typologien van implementaties>

10

HET IMPLEMENTATIEPROCES
Hoe we implementeren ook definiren, we komen er altijd op uit dat implementeren een proces is. Zoals in alle andere processen, kan ook het implementatieproces opgedeeld worden in een aantal verschillende fasen. In het 'praktijk'-boek werken we iedere fase in detail uit. In deze paragraaf zetten we alleen de hoofdlijnen neer. Op basis van de typen implementaties (die al behandeld zijn in het vorige hoofdstuk) en de ervaring die we hebben opgedaan in de jaren die achter ons liggen met SIM, onderkennen we de volgende uit te voeren fasen:

figuur <fasering van de implementatie>

De fases houden kort gezegd het volgende in: 1. Voorbereiden; De voorbereiding moet dusdanig zijn, dat op basis hiervan het informatiesysteem succesvol gemplementeerd kan worden. Dit houdt in dat de context, doelen en randvoorwaarden gedefinieerd moeten worden, de risico's genventariseerd, het project gepland, het project ingericht, en het projectplan vastgesteld moet worden. 2. Ontwerpen; In deze fase wordt het pakket op papier aangepast aan de organisatie en vice versa. Hiervoor moeten detailprocesbeschrijvingen, een detailprocesanalyse, een uitwerking van het procesontwerp, een detailontwerp van de organisatorische componenten, een parameterontwerp en conversieplan gemaakt worden en moet het detailontwerp van het informatiesysteem vastgesteld worden. 3. Inrichten; De kern van het inrichten van een informatiesysteem wordt gevormd door het omzetten van het ontwerp in een ingericht en getest informatiesysteem. Hiervoor moet de apparatuur en programmatuur genstalleerd worden, de parameterinstellingen en basistabellen ingevoerd en getest, een proefconversie uitgevoerd, de organisatorische componenten ontwikkeld en getest, en de optimale integratie getest worden.

11

4.

5.

Invoeren; Deze fase is het spannendst: het informatiesysteem gaat 'live', en dat betekent dat de knop wordt ingedrukt en het informatiesysteem 'ter wereld komt'. Hiertoe moeten de gebruikers opgeleid en getraind worden, de beheerorganisatie doorgevoerd, het 'go-live'-plan uitgewerkt tot in detail, de gegevensconversie uitgevoerd, het informatiesysteem aan een laatste controle onderworpen, het informatiesysteem in gebruik genomen worden, en worden overgedragen aan de beheerders. Integreren; Dit is de fase na ingebruikname, waarbij we de implementatie niet loslaten, maar de touwtjes nog even vasthouden zodat het systeem een stevige inbedding krijgt in de organisatie. Om dit te bewerkstelligen moeten we audits en checks uitvoeren, werkplekondersteuning geven, incidenten beoordelen en registeren, problemen oplossen, wijzigingsvoorstellen van het informatiesysteem behandelen en specificeren, en het informatiesysteem overdragen aan de eigenaar.

12

OBJECTEN VAN VERANDERING

Als we over implementaties van de 3e of 4e categorie spreken, dan kunnen we stellen dat we eigenlijk spreken over organisatieverandering. Om op een systematische manier na te kunnen denken over de veranderingen die de implementatie van een informatiesysteem met zich meebrengt, onderscheiden wij verschillende objecten die hierbij aan verandering onderhevig zijn. De objecten die wij onderscheiden zijn: besturing, bedrijfsprocessen, mensen, informatie en technische middelen. Omdat het object 'technische middelen' voor zich spreekt, gaan we daar verder niet op in.

Besturing
Als we het hebben over besturen, dan hebben we het over alle vormen van gerichte benvloeding van het gedrag van een systeem. In dit geval kan het systeem een persoon zijn, een afdeling, een divisie, de samenleving, etc. Het gaat dus om de gerichte benvloeding van een bepaalde entiteit. Wil het besturend orgaan - degene die het gedrag van een systeem probeert te benvloeden - instaat zijn om effectief te besturen, dan moet er aan een aantal voorwaarden voldaan worden: 1 Er moet een doel zijn (een beoogd resultaat, omdat er anders geen sprake van gerichte benvloeding kan zijn); 2 Er moet een model van het bestuurde systeem zijn (er moet een voorstelling te maken zijn van het bestuurd systeem, anders zouden de effecten van genomen maatregelen niet te voorspellen zijn); 3 Er moet informatie over de omgeving en de toestand van het systeem zijn (op basis hiervan zijn voorspellingen te doen over hoe het systeem zich gaat ontwikkelen in de toekomst); 4 Er moeten voldoende stuurmaatregelen zijn (voor het optimaal effectief besturen is het dus vereist evenveel stuurmaatregelen te hebben als het mogelijke aantal omstandigheden die zich in het systeem voor kunnen doen); 5 Er moet voldoende capaciteit van informatieverwerking zijn (d.w.z. het besturend orgaan moet voldoende capaciteit hebben om de informatie te verwerken wil het zich een goed beeld kunnen vormen van de toestand van het bestuurd systeem) Er moet aan nogal wat voorwaarden voldaan zijn, wil men 100% effectief kunnen besturen. Het is dan ook niet zo vreemd dat de besturing als een object van verandering beschouwd wordt. Er kan immers heel wat veranderen binnen het bestuurd systeem, of binnen de voorwaarden voor effectieve besturing. De relatie tussen een informatiesysteem en de besturing van een organisatie, zit in het gegeven dat er een besturingsfunctie opgesloten ligt in een informatiesysteem. Een informatie systemen kan een aantal voorwaarden vervullen voor effectieve besturing, zeg maar. Zo kan een informatiesysteem informatie verschaffen over de omgeving en de toestand van een systeem. Dit is cruciaal voor besturing; er kan immers niet gericht benvloedt worden als men hier geen beeld van heeft. Er kunnen vier typen besturing onderscheiden worden, die alle vier een bepaalde informatiebehoefte met zich meebrengen. Deze typen besturing en de daaruit afgeleidde informatiebehoefte hebben te maken met een leercurve die we allemaal door maken als we een bestuurd systeem, zoals een bedrijfsproces, proberen te leren kennen. De typen besturing zijn dus in feite fasen die we doorlopen als we een bestuurd systeem proberen te leren kennen.

13

De fasen zien er als volgt uit:

figuur <verschillende typen besturing>

In de ludieke fase van besturing maken we spelenderwijs kennis met het nieuwe systeem. We proberen ons een beeld te vormen van het systeem en zijn grenzen te verkennen. Als we eenmaal weten wat het is gaan we naar de verkennende fase. In deze fase proberen we de betekenis van het systeem voor onszelf te ontdekken. Als dat duidelijk is komen we in de fase van exploratieve besturing, die is gericht op het formuleren en vergelijken van alternatieve methoden om de gestelde doelen met het nieuwe systeem te bereiken. Hier worden de normen aangelegd waaraan het bestuurd systeem zal moeten voldoen. We geven dus aan hoe activiteiten uitgevoerd moeten worden door het bestuurd systeem. Nu gaan we over naar de fase van operationele besturing, waarin we constant aan het bijsturen zijn omdat het systeem bijna nooit 100% voldoet aan de normen die we hebben gesteld. In iedere fase van besturing spelen informatiesystemen een andere rol. Zo kent de ludieke fase van besturing geen of weinig systematiek. Formele informatiesystemen komen hierin dan ook niet voor. Hooguit wordt ICT als ondersteunend zoeklicht gebruikt, bijvoorbeeld bij een tastende internetsearch. In de verkennende fase is de informatievoorziening ook nog niet echt systematisch, maar er worden wel enkele contouren zichtbaar van het informatiesysteem. Toch blijft wanorde, chaos, de hoofdmodus. ICT kan bijvoorbeeld alleen gebruikt worden om grote hoeveelheden gegevens te rangschikken, maar daar blijft het dan ook bij. De conclusie moet de bestuurder zelf trekken, de beslissing zelf nemen. In de exploratieve fase van besturing zijn we op zoek naar alternatieve methoden, gericht op innovatie. De bestuurders hebben in deze fase gegevens nodig over hoe het gaat of over hoe het zal gaan. Die informatie moet leiden tot het inzicht tot verbetering. In deze fase wordt veelal gebruik gemaakt van rapporten over de huidige prestaties van het bestuurde systeem, beschrijvingen van alternatieve methoden, en prognoses over de prestaties van de alternatieve methoden. Echter, zal de conclusie door de bestuurder zelf getrokken moet worden en de beslissing genomen. In de operationele fase van besturing weten we wat we willen, hoe we willen dat het zal verlopen, en wat we willen weten. Pas vanaf dit moment kan een informatiesysteem goed geformaliseerd worden. ERP- en CRM-systemen zijn hier op hun plaats.
14

Bij de implementatie van informatiesystemen moet wat betreft de besturing rekening gehouden worden met de volgende aspecten:

Tijdens de voorbereiding van de implementatie:

1. 2. 3. 4. 5. inzicht krijgen in missie visie en doelen van de organisatie; inzicht krijgen in de kenmerken van organisatiestructuur; inzicht krijgen in de structuur en de werking van het besturingssysteem van de organisatie; in kaart brengen van de doelstellingen in het informatiegebied waarin de implementatie zich gaat afspelen; in kaart brengen van de typen besturing die het te implementeren informatiesysteem moet ondersteunen. afstemmen van het ontwerp en de inrichting van het informatiesysteem met de besturing van de organisatie.

Tijdens ontwerp en inrichting van het informatiesysteem:

6.

Tijdens de invoering van het informatiesysteem en de integratie van informatiesysteem en organisatie:

7. 8. 9. testen input van het management; testen output van het management; controleren of de managementinformatie voldoet en gebruikt wordt zoals bedoeld.

Bedrijfsprocessen
Bij de implementatie van een complex informatiesysteem zijn ook de bedrijfsprocessen aan verandering onderhevig. Een nieuw informatiesysteem biedt immers mogelijkheden die er daarvoor nog niet waren. Er veranderen drie dingen aan het bedrijfsproces: de activiteiten, de structuur en de afstemming tussen de bedrijfsprocessen en de functionaliteit van de nieuwe ICT. Wij definiren bedrijfsproces als volgt: Een verzameling van activiteiten - met de (chrono)logische volgorde van de waardetoevoeging als ordeningscriterium - die een vooraf gedefinieerd resultaat oplevert voor een interne of externe klant. Bedrijfsprocessen zijn het eerste structuurelement dat we zien als we naar een bedrijfsorganisatie kijken. De activiteiten worden bepaald aan de hand van het te leveren eindproduct. De vraag is dus: 'wat moeten wij doen om dit specifieke product, of deze specifieke dienst, te leveren?' Naast bedrijfsprocessen onderscheiden we ook bedrijfsfuncties. Deze twee worden nogal eens met elkaar verward. Daarom geven we hier onze definitie van bedrijfsfunctie: Een verzameling van bedrijfsactiviteiten - met specialisatie als ordeningscriterium - die aangeeft wat er moet gebeuren om het doel van een organisatie te realiseren.

15

Een aantal belangrijke verschillen tussen het bedrijfsproces en de bedrijfsfunctie staat in de tabel hieronder.

figuur < Verschillen tussen bedrijfsfunctie en bedrijfsobject>

Bij het ontwerpen van een informatiesysteem hebben we een beschrijving van bedrijfsfuncties nodig om: 1 Een vergelijking te maken tussen de activiteiten van de organisatie en de functionaliteit van een standaard applicatiepakket, in de selectiefase (dat is dus voor de implementatie) Procesbeschrijvingen hebben we nodig om: 2 Een zelfde vergelijking te maken om te bepalen wat er in de implementatie gedaan moet worden, bijvoorbeeld m.b.t. maatwerk, interfaces, etc. 3 Een detailverschillenanalyse uit te voeren om te specificeren welke aanpassingen in het proces gedaan moeten worden, en het detailontwerp van het informatiesysteem te maken. 4 De inhoud en volgorde van de schermen, formulieren en lijsten te bepalen. 5 Testcases en scripts te definiren. 6 Procedures, werkinstructies, taak- en functieomschrijvingen te definiren en uit te werken. 7 De opzet van het functioneel, applicatie- en technisch beheer, inclusief de helpdesk functie te ondersteunen als referentie. 8 Gebruikersdocumentatie, opleidingen en trainingen te definiren uit te werken en te geven.

16

Mensen
Het belangrijkste dat er verandert bij mensen tijdens een implementatie, is dat mensen nieuwe dingen leren. Er verandert dus iets in de kennis, en soms ook de vaardigheden, van mensen. Maar, veelal verandert er ook iets in de manier waarop mensen samenwerken. Dit komt bijvoorbeeld doordat de organisatiestructuur verandert als gevolg van een implementatie. Kennis en vaardigheden Wat betreft kennis en vaardigheden hebben we bij implementaties vaak te maken met de volgende aspecten die bij mensen veranderen. Mensen krijgen: 1. inzicht in en leren werken met de nieuwe applicaties en apparatuur; 2. inzicht in en leren werken met nieuwe bedrijfsconcepten, zoals een kwaliteitsbeheerssysteem, klantgericht werken, projectverband en veranderingsprocessen; 3. inzicht in en leren werken met nieuwe werkprocessen; 4. nieuwe vakkennis voor nieuwe functies, zoals beheerfuncties; 5. te maken met het conserveren van relevante 'oude' kennis en vaardigheden. Veranderingsproces In implementatieprojecten krijgen we op twee punten te maken met organisatiestructuren. In de eerste plaats als we de context van de implementatie in kaart brengen. In de tweede plaats kunnen we ermee te maken krijgen wanneer, als gevolg van de implementatie, bijvoorbeeld van een ERP-systeem, de organisatiestructuur geheel of gedeeltelijk gewijzigd gaat worden. Dit kan consequenties hebben voor de functies, opgebouwd uit de verantwoordelijkheden taken en bevoegdheden, die mensen binnen een organisatie vervullen. Kenmerk van veranderingen binnen organisaties, is dat mensen de neiging hebben weerstand te bieden tegen veranderingen. Mensen willen niet per definitie veranderen. Dit komt bijvoorbeeld doordat ze onzeker zijn over het resultaat dat de verandering oplevert of onzeker zijn over hun toekomstige functie (heeft die wel evenveel status als hun huidige). Maar, er zijn legio redenen om weerstand te bieden tegen een verandering. De oorzaken van weerstand worden voornamelijk gevoed doordat er belangen van mensen op het spel staan. Met het erkennen van die belangen wordt een goede stap in de richting gezet om de verandering soepel(er) te laten verlopen. Een vijftal belangen is er te onderscheiden: 1 Ten eerste de materile belangen, bijvoorbeeld geld. 2 Ten tweede de immaterile belangen. Hier gaat het o.a. om de status die aan een functie gekoppeld is. 3 Ten derde het belang van de kennis en de inzichten die ze hebben ten aanzien van het werk in de oude en nieuwe situatie. Mensen zien zichzelf als de experts op het gebied van de uit te voeren werkzaamheden. 4 Ten vierde het belang van het doormaken van een leerproces, plotselinge veranderingen worden over het algemeen als onaangenaam ervaren. 5 En, ten vijfde, het belang van het doormaken van een gevoelsproces, mensen moeten naar een nieuwe situatie toe groeien.

17

Managers en projectleiders spelen een belangrijke rol en zijn zelf vaak debet aan de weerstand. Het komt bijvoorbeeld nogal eens voor dat een relatief stilzwijgen van de medewerkers, in het begin van het project, vaak ten onrechte wordt genterpreteerd als een soort instemming. Het blijkt echter in veel gevallen onzekerheid te zijn, die hier de aanleiding voor is. Mensen moeten wennen aan het idee, en groeien naar, een verandering. Een mentaal veranderingsproces heeft doorgaans het volgende verloop.

figuur <gevoelsproces bij individuen in veranderingssituaties>

Informatie
Bij de implementatie van een standaard applicatie veranderen vooral de informatievoorziening, de gegevens en de gegevensbestanden. Informatievoorziening en bedrijfsobjecten Informatie is de grondstof voor kennis, op basis waarvan beslissingen worden genomen en afspraken worden gemaakt. We willen in het algemeen beslissingen zo goed mogelijk maken. Daarom gaan we op zoek naar informatie die ons iets meer inzicht kan geven in de specifieke situatie. Informatie wordt dus gebruikt om onzekerheid, die aan een specifieke situatie gekoppeld is, te verkleinen. Eigenlijk hebben we altijd te weinig informatie, het is immers onmogelijk een situatie voor de volle 100% te kennen. Gegevens zijn de grondstof voor informatie, hieraan is geen tekort. Vanuit dit vertrekpunt is het goed om de behoefte aan informatie in kaart te brengen. Dit doen we aan de hand van de bedrijfsobjecten. Bedrijfsobjecten zijn: Beschrijvingen van concrete of abstracte onderwerpen waarover een bedrijf informatie wil registreren Over deze zaken proberen we meer te weten te komen. Een bedrijfsobject wordt dan ook wel een gegevensgroep of gegevensklasse genoemd.

18

We selecteren de bedrijfsobjecten die van belang zijn voor het informatiesysteem dat moet worden gemplementeerd. Deze koppelen we aan de daarvoor belangrijke bedrijfsfuncties, bedrijfsprocessen en systeemfuncties.

b e d r ij f s f u n c t i e

b e d r ij f s p r o c e s

b e d r ij f s o b j e c t
aanvraag

O ffreren
b e h a n d e li n g aanvraag s e le c t ie p r o d u c t / d ie n s t o p s t e l lin g o f f e r t e

b e h a n d e le n aanvraag s e le c t e r e n product / d ie n s t

product

d ie n s t

offreren

offerte

figuur <relatie bedrijfsfunctie, bedrijfsproces en bedrijfsobject >

b e d r ij f s p r o c e s

b e d r ij f s o b j e c t
aanvraag

s y s t e e m f u n c t ie s
k la n t product
r e g is t r e e r aanvraag s e le c t e e r product

b e h a n d e le n aanvraag s e le c t e r e n prod uct / d ie n s t

product

d ie n s t aanvraag

offreren

offerte k la n t

m aak offerte

figuur <bedrijfsproces, bedrijfsobject en systeemfuncties>

19

Gegevens
Voor de implementatie van een informatiesysteem moeten de databases, en de tabellen daarin, worden gedefinieerd. Hiervoor is het nodig de bedrijfsobjecten verder te detailleren. Dat doen we door entiteiten te benoemen binnen van het bedrijfsobject. Dit zijn bepaalde groepen kenmerken van het bedrijfsobject. Per entiteit wordt vervolgens bepaald welke gegevens daarover moeten worden vastgelegd, de zogenaamde attributen.

figuur < decompositie van bedrijfsobject> Bovenstaand voorbeeld maakt duidelijk dat er een database zal zijn met daarin gegevens over het bedrijfsobject product en dat in die database gegevens worden vastgelegd van productprogramma, producttype, enzovoort. Tevens worden in ons voorbeeld van de entiteit producttype de attributen producttypenummer, producttypenaam, etc. vastgelegd. De attributen worden in de database de veldnamen in de tabel van de entiteit. Om werkelijk een goed informatiesysteem op te zetten hebben we dus eigenlijk gegevens over gegevens nodig, om: 1. een vergelijking te maken tussen de informatiebehoeften van de organisatie en de gegevens die in een standaard applicatiepakket kunnen worden gelegd; 2. een zelfde vergelijking te maken om te bepalen wat er in de implementatie gedaan moet worden, bijvoorbeeld ten aanzien van maatwerk, interfaces, conversieprogrammatuur, aanpassingen in processen, uitwerken van procedures en werkinstructies; 3. een detailverschillenanalyse uit te voeren om te specificeren welke aanpassingen in het proces gedaan moeten worden en het detailontwerp van het informatiesysteem te maken, inclusief definities van parameterinstellingen en basistabellen, specificaties voor maatwerk, interfaces en conversieprogrammatuur; 4. de inhoud van schermen, formulieren en lijsten te bepalen; 5. conversieprogrammatuur te definiren en te (laten) maken; 6. testcases en -scripts te definiren; 7. de opzet van het functioneel, applicatie- en technische beheer, inclusief de helpdeskfunctie te ondersteunen als referentie; 8. gebruikersdocumentatie, opleidingen en trainingen te definiren, uit te werken, en te geven.

20

Er is een vijftal kernproblemen, met betrekking tot de gegevens, waar we in de regel vaak mee te maken krijgen als we het oude systeem omzetten naar het nieuwe systeem. Hieruit volgen logischerwijs een aantal te treffen voorbereidingen: 1. de 'oude' gegevens zijn vervuild => opschonen oude gegevens; 2. de 'oude' gegevens passen qua formaat niet in de nieuwe database => aanpassen formaat oude gegevens; 3. 'oude' gegevens die wel bewaard moeten worden, komen niet in de nieuwe database => oplossingen vinden voor het bewaren van oude gegevens die wel bewaard moeten worden, maar niet in de nieuwe database komen; 4. in de nieuwe database moeten gegevens komen, die niet eerder zijn vastgelegd => gegevens verzamelen en invoeren die niet eerder werden vastgelegd, maar wel nodig zijn in de nieuwe database; 5. er is geen programmatuur om de gegevens uit de 'oude' database te halen en/of die programmatuur kan niet samenwerken met de programmatuur die de gegevens in de nieuwe database moet inlezen => 'ontlaad'-programmatuur en 'tussen'-database ontwikkeling;

Technische middelen
De technische middelen zijn het laatste object van verandering dat we onderscheidden. Ontwikkelingen in de techniek gaan razendsnel; dit geldt zowel voor de hardware als voor de software kant van de techniek. Omdat de specifieke veranderingen op technisch gebied buiten de scope van dit boek vallen wordt er hier alleen aandacht besteed aan het sizen van de componenten van de technische infrastructuur, in het kader van de implementatie. Onder sizen verstaan we: Het inschatten van de behoefte aan hardwarecapaciteit voor de implementatie van een informatiesysteem. Juist het inschatten van de behoefte aan hardwarecapaciteit is voor het welslagen van de implementatie van belang. Omdat het informatiesysteem in het bereik komt van de gebruikers middels de technische infrastructuur, de hardware, is een goed werkende technische infrastructuur van wezenlijk belang. De ervaring met het werken van het systeem zal namelijk van grote invloed zijn op het oordeel dat de gebruikers hebben over het systeem. Voldoende hardwarecapaciteit is hiervoor noodzakelijk, vandaar het belang van sizen. Het sizen gebeurt voornamelijk in de ontwerpfase van de implementatie. Hoewel er in de voorbereidingsfase al een globale inschatting is gemaakt, kan deze inschatting pas goed worden gemaakt als we precies weten hoe het systeem er uit komt te zien. Daarnaast beperkt het sizen zich niet slechts tot het moment van ingebruikname, maar moet er ook een inschatting worden gemaakt van de toekomstige behoefte aan hardwarecapaciteit. In onze analyse van de te verwachtten behoefte aan hardwarecapaciteit, wordt aan vijf punten specifiek aandacht besteed (voor een uitgebreide beschrijving, zie: SIM3 in theorie, pp. 127 - 132): 1 Het aantal gebruikers 2 De intensiteit van het gebruik, en de omvang van de gegevensopslag 3 De interfaces 4 De beveiliging van het informatiesysteem 5 De beveiliging van de ICT-infrastructuur

21

De ervaring leert dat iedere soort van voorziening in de regel zijn eigen leverancier heeft. Dat maakt het verzamelen van informatie over capaciteit en dergelijke, en het inschakelen van de juiste expertise en communicatie niet gemakkelijk. De implementatiemanager dient bij de aansturing van de aanschaf en installatie zorg te dragen voor realistische planningen en toe te zien op de uitvoering daarvan.

22

MANAGEMENTASPECTEN IMPLEMENTATIEPROJECT
We hebben het al eerder gehad over de verschillende fasen dat een implementatieproject doorloopt. Natuurlijk moet ook iedere fase gemanaged, of bestuurd, worden. Daarom onderscheiden wij een vijftal managementaspecten die in iedere fase terug komen. In de zorg voor kwaliteit en het beheer van contracten zitten een aantal elementen die specifiek zijn voor implementaties. Vandaar dat we kwaliteitsmanagement en contractmanagement naast verandermanagement en kennismanagement als aparte aandachtsgebieden behandelen. Maar eerst het management van een implementatieproject in het algemeen.

Projectmanagement
Onze definitie van een project is: Een nmalige, specifieke, in tijd begrensde reeks van activiteiten gericht op het realiseren van een welomschreven doel, die in de regel worden uitgevoerd door een groep mensen met verschillende disciplines. Het is nodig een project altijd in zijn context te beschouwen en te beseffen dat projectbelangen nogal eens conflicteren met andere belangen binnen de organisatie. Net als andere projecten moet ook een implementatieproject gemanaged worden. Binnen het projectmanagement zijn er vijf inrichtingsaspecten die gericht zijn op de inrichting van de besturing van het project: 1. projectbesturing; dit gebeurt door de implementatiemanager. Daarnaast is het zaak dat de opdrachtgever van het begin tot het eind betrokken is bij het project en zich er emotioneel mee verbonden voelt. Dit zodat deze bereid is de condities te scheppen die nodig zijn voor de uitvoering van het project. De doelstelling van het implementatieproject beschrijft wat er klaar is als het klaar is; aan deze doelstelling worden de SMART-eisen gesteld (de doelstelling moet Specifiek, Meetbaar, Acceptabel, Realiseerbaar en Tijdgebonden zijn). De projectbesturing richt zich vooral op: a. resultaten; dit zijn alle producten die in het project worden voortgebracht; b. resources; dit zijn alle mensen, informatie en middelen die het project nodig heeft voor de invoering van de activiteiten; c. risico's; het gaat hier om de kans dat ongewenste ontwikkelingen zich voordoen en het effect dat ze hebben. Een risico wordt bepaald door succes- en faalfactoren van het project. Succesfactoren dienen te worden versterkt en faalfactoren dienen te worden gecompenseerd of overwonnen (voor een lijst van succes- en faalfactoren zie 'theorie'-boek hst. 4). projectactiviteiten; hiervoor kunnen mijlpaalproducten worden gedefinieerd. Dit zijn: Producten van een project waaraan formele uitgangspunten, plannen en/of beslissingen ten grondslag liggen, die op een tevoren vastgesteld tijdstip opgeleverd moeten worden, om onder andere de voortgang van het project te meten. Van deze mijlpaalproducten kan een hirarchische verdeling worden gemaakt ten aanzien van taken, subtaken en werkpakketten. Dit wordt een workbreakdownstructuur genoemd. Verder moet niet vergeten worden extra aandacht te geven aan de afronding van een project. Dit heeft een emotionele waarde; mensen hebben sterker het gevoel dat ze een nieuwe fase ingaan.
23

2.

3.

projectmedewerkers; bij het opdelen van het werk zien we bij implementatieprojecten drie hoofdrollen: a. de projectleiding; deze is bij grotere projecten vaak meerkoppig, hierbij is er dan n algemene leidinggevende en verder zijn er deelprojectleidinggevenden; b. de materiedeskundigen; dit zijn de managers en gebruikers die vanwege hun kennis van de bedrijfsprocessen en de organisatie van het werk bij het project worden ingeschakeld; c. de specialisten; dit zijn projectmedewerkers die de componenten van het informatiesysteem maken (voor de verschillende structuren voor de organisatie van een implementatieproject en voor een uitgebreide verhandeling van teammanagement/ building, conflicthantering en motivering zie hoofdstuk 4 'denk'-boek). projectinformatie; het leiden en uitvoeren van een implementatie is bovenal een kwestie van communiceren. Een belangrijk deel van de communicatie betreft de gang van zaken in het project zelf. Het gaat daarbij om beslisdocumenten, projectrapportages, notulen van vergaderingen, contracten, projectdocumentatie, etc. projectmiddelen; dit zijn de faciliteiten die het projectteam ter beschikking moeten staan zoals: ruimten, meubilair, beamers, flip- overboarden, geautomatiseerde ontwikkel- en testomgevingen, ontwerptools etc.

4.

5.

Verandermanagement
Onder verandermanagement verstaan wij: Het zich bewust zijn van wat er in en tussen mensen in mentale zin verandert en zou moeten veranderen om een informatiesysteem geaccepteerd en gentegreerd te krijgen en het plannen, uitvoeren en besturen van maatregelen om het veranderingsproces positief te benvloeden. Het gaat in deze paragraaf over de mentale aspecten van het veranderen. De vraag die hier ter beantwoording ligt is 'kunnen wij mensen wel mentaal veranderen? Het antwoord is 'nee'. Het zijn de mensen zelf die dat doen bij zichzelf. Er invloed op uitoefenen is wel mogelijk, al is dit moeilijk. Het effectief benvloeden van mentale veranderingsprocessen vraagt in de eerste plaats zelfkennis en het vermogen te reflecteren op het eigen gedrag en dat bij te sturen. Onderzoek en praktijkervaring leren ons dat mensen over het algemeen goed in staat zijn om mee te gaan met organisatieveranderingen. Het ervaren van erkenning en respect is daarin een sleutelfactor. Daarnaast is ook het vertrouwen in het management en de veranderaars van wezenlijk belang, evenals eerdere ervaringen met veranderingen. Hoewel wij ervan overtuigd zijn dat de aanpak van organisatieveranderingen zich de komende jaren in de richting zal gaan van een focus op de mens en een mentale verandering, is er nog te weinig bekend om hier volop rekening mee te houden bij de aanpak van veranderingen in het kader van de implementatie van een informatiesysteem.

24

Daarom maken we gebruik van het implementatiemodel van Wissema dat enigszins traditioneel is, maar waar we goede ervaringen mee hebben.

figuur <model van veranderingsproces> In dit model wordt ervan uitgegaan dat: er een gewenste eindsituatie te definiren is vanuit de beginsituatie (en dit gaat zeker op voor implementaties); de omgeving invloed heeft op de beginsituatie; vaak de interactie met die omgeving aanleiding geeft tot veranderen; aanleiding, uitgangssituatie en omgevingsfactoren bepalend zijn voor het type verandering. Bij het typeren van veranderingen maken we een onderscheid tussen mentale veranderingsprocessen die f gericht zijn op het verbeteren van het bedrijfsproces, f op het herontwerpen van het bedrijfsproces. Voorts maken we nog onderscheid in tijdsdruk: is deze groot dan is vooral snelheid geboden, is deze klein dan is vooral zorgvuldigheid geboden. Zo komen we uit op vier veranderingstypen:

figuur <typen 'mentale' veranderingsprocessen>

25

De kenmerken van de verschillende typen verandering zijn: 1. adaptieve verandering - de tijdsdruk is hoog; - er moet vooral aangepakt worden; - omdat het om kleine veranderingen gaat zal aan de meeste mensen gevraagd worden zich aan te passen en deze zullen dat ook doen; - als er weinig spanningen zijn in een organisatie en er voldoende draagvlak is voor het doel van de verandering is een participatieve aanpak vaak goed mogelijk. 2. evolutionaire verandering - tijd voor overleg; - bewaakt moet worden dat het veranderingsproces niet onnodig lang duurt of mogelijk onzichtbaar geblokkeerd wordt; - participatieve aanpak is hier goed mogelijk. 3. revolutionaire verandering - doet zich voor in een crisis- of bijna-crisissituatie of bij grote druk van buitenaf; - alle hens aan dek; wie niet meewerkt, gaat maar wat anders doen; - minder geschikt voor participatieve aanpak; eigenlijk alleen maar in organisaties met een taakcultuur die dit soort veranderingen gewend zijn. 4. transformatieve verandering - komt het meest voor bij het soort implementaties waarover wij het in het 'theorie'-boek hebben; - kan zowel met als zonder de participatie van gebruikers; - voor mentale verandering is participatie wel aan te bevelen. Bij het managen van een veranderingsproces moeten we vijf dingen doen: 1. plannen interventies veranderingsproces; 2. inzetten veranderingsproces; 3. begeleiden veranderingsproces; 4. afsluiten veranderingsproces; 5. evalueren veranderingsproces en nieuwe doelen stellen.

26

Kennismanagement
Kennismanagement in implementatieprojecten van informatiesystemen is gericht op het in kaart brengen van: de kennis die nodig is om het informatiesysteem te gebruiken en te beheren; de kennis die nodig is om de implementatie uit te voeren; de aanwezige kennis; voorlichting, opleiding, training en persoonlijke ondersteuning en de opslag van gexpliceerde kennis. Een deel van de kennis is verborgen, dat wil zeggen: het zit alleen in de hoofden van de mensen. Een ander deel is expliciet te maken en is vast te leggen op kennisdragers. Er zijn drie functies van kennismanagement: kennisontsluiting, relevante kennis over alle componenten van het informatiesysteem moet beschikbaar en toegankelijk worden; kennisvastlegging, kennis over alle componenten, inclusief testgegevens en 'historische' gegevens over oude versies van ontwerpen en dergelijke moeten worden vastgelegd; kennisontwikkeling, het opbouwen van nieuwe kennis binnen de organisatie over alle componenten van het informatiesysteem. Onder leren verstaan wij in navolging van Van Parreren: een proces, met min of meer duurzame resultaten, waardoor nieuwe gedragspotenties van de persoon ontstaan of reeds aanwezige zich wijzigen. In implementatieprojecten leert men via vier manieren: 1. automatisch leren (vanuit en door jezelf en onbewust); 2. ervaringsleren (vanuit en door jezelf en bewust); 3. voorlichting, opleiding en training (vanuit de door anderen en bewust); 4. persoonlijke ondersteuning (vanuit en door anderen en onbewust). Een opleidingsprogramma in een implementatieproject is gebaseerd op het model van de leercyclus in implementatieprojecten. Hierbij nemen we allereerst de huidige en toekomstige werksituatie onder de loep en kijken naar de kennis- en vaardigheidsaspecten. De leerbehoeften zijn als het ware de uitkomst van hetgeen men moet weten en kunnen, minus wat men al weet en kan. Vervolgens worden de leerdoelen geformuleerd in termen van gedrag. Dat wil zeggen dat we kijken of de werknemer in staat is de geleerde taak uit te voeren.

Kwaliteitsmanagement
Binnen implementatieprojecten is het waarborgen van kwaliteit van wezenlijk belang. Niemand is gebaat bij half werk. Onze definitie van kwaliteit is: Het geheel van eigenschappen en kenmerken van een product dat van belang is voor het voldoen aan vastgelegde of vanzelfsprekende behoeften. In een implementatieproject dient de kwaliteitszorg gericht te zijn op de realisering van kwaliteit van: 1. de informatie; 2. de informatievoorziening; 3. het informatiesysteem; 4. de ontwikkeling van het informatiesysteem.

27

Onderdeel van kwaliteitsmanagement is het testen van de apparatuur en programmatuur. Hierbij moeten we ons realiseren dat het nooit mogelijk is alle fouten uit een informatiesysteem te halen. Het gaat erom het aantal fouten tot een aanvaardbaar minimum terug te brengen. De kwaliteitsprocedures om de doelstellingen van het kwaliteitsbeheer te realiseren zijn opvolgend: 1. geven en opvolgen van projectopdracht; 2. formuleren kwaliteitseisen implementatieproducten; 3. opleveren, accepteren en overdragen implementatieproducten; 4. melden incidenten en oplossen problemen tijdens de implementatie; 5. wijzigen implementatieproducten. (De procedures 1, 3, 4 en 5 zijn uitgewerkt in het 'praktijk'-boek).

Contractmanagement
Het vijfde en laatste managementaspect is het contractmanagement. Iedere projectmanager heeft daar in meer of mindere mate mee te maken. Bij elke fase van het implementatieproject horen verschillende aandachtspunten. Het begint in de fase die vooraf gaat aan het implementatieproject: de selectie fase. Hier wordt eerst een selectie gemaakt van een tien tot twaalf pakketten. Deze selectie wordt ingeperkt tot de selectie van drie tot vijf pakketten en aan iedere leverancier wordt een offerte gevraagd. Daarna begint het onderhandelen met de verschillende leveranciers. Als er in deze fase een contract gesloten wordt, gaat het vooral om raamcontracten en basiscontracten voor apparatuur, programmatuur en diensten. De volgende fase is de fase van voorbereiding. Hoewel het in de praktijk vaak voorkomt dat het implementatieproject al begonnen is voordat de basiscontracten gesloten zijn, is dit beslist niet goed. Gebeurt dit wel, dan is het vaak de projectmanager die hier verantwoordelijk voor is. In deze fase sluit men ook de meeste dienstverleningsovereenkomsten. De ontwerpfase kent eigenlijk geen selectie meer. Men werkt met de al bestaande partijen en de afspraken zijn vastgelegd in al bestaande raamovereenkomsten. De laatste fase is de inrichtingsfase. Hierbij gaat het vooral om het beheer en het onderhoud, een calamiteitenregeling, verzekeringen, onderhoudscontracten (preventief, correctief, adaptief en perfectief onderhoud), etc. Gedurende het hele project dienen de contracten beheerd te worden en moeten deze ook continu beschikbaar zijn. Bij iedere geleverde dienst is het raadzaam na te gaan of de contractuele bepalingen worden nageleefd. Onze ervaring is dat het goed is de leverancier te laten merken dat het contract serieus genomen wordt en dat ze verantwoording verschuldigd zijn als aan de gemaakte afspraken niet voldaan wordt. Ook een contract tussen de projectmanager en de opdrachtgever is geen overbodige luxe. Vooral als het gaat om complexe implementaties. Dit kan zowel een resultaatverplichting, als een inspanningsverplichting zijn. Het verschil hiertussen is dat de projectmanager in het eerste geval de hoofdaannemer is en hij de dienstverleners en dergelijke namens de organisatie kiest. In de tweede situatie is het de organisatie zelf die hiervoor verantwoordelijk is. Maar niet alleen de verplichtingen van de andere partij zijn belangrijk. Het gaat ook om de eigen verplichtingen die bewaakt moeten worden. Daarom zien wij een contract ook als een primair managementinstrument.

28

SIM3
Tot nu toe hebben we de 'fasering van een project', de verschillende 'objecten van verandering' en de verschillende 'managementaspecten' beschreven. Hiertussen kan nu een relatie gelegd worden. Deze relatie wordt weergegeven in de SIM3-kubus:

Figuur <SIM3 kubus>

Ieder blokje uit de kubus vormt een combinatie van een fase in het implementatieproject + een object van verandering + een managementaspect. Op deze manier heeft iedere combinatie een set van activiteiten, die bij elkaar genomen het gehele implementatieproject uitmaken. Het praktijkboek beschrijft het proces in chronologische volgorde.

29