In een vorige bijdrage is gepleit voor het opsplitsen van het management van ICT-projecten in afzonderlijke projecten, te weten: analyse, ontwikkeling en implementatie. De doelstellingen, deelnemers en werkwijzen, en daarmee de risico’s en doorlooptijden van deze activiteiten, kunnen namelijk nogal uiteenlopen. In dat geval is het beter ze onder te brengen in afzonderlijke projecten. Zelfs als een kort-cyclische iteratieve methodiek wordt gevolgd. In deze bijdrage staat het management van de implementatie-activiteiten centraal.
De invoering van ICT gaat altijd gepaard met wijzigingen. Voor het merendeel zal het hierbij gaan om geplande wijzigingen (met soms onverwachte gevolgen). Het moment van overgaan is kritiek. Wanneer is het projectresultaat klaar voor implementatie. Hoe omvangrijk / ingrijpend is de verandering? Wie wordt of worden geraakt door de invoering? Wat verandert er?
Uitgangspunt bij implementatie is dat de ontwikkeling van de software is afgesloten. Vaak is dat niet het geval, bijvoorbeeld als gekozen is voor een iteratieve ontwikkelbenadering met de gebruiker “in the loop”. Eigenlijk is ontwikkeling nooit klaar zoals ook een bedrijf nooit af is. Het is in ieder geval niet verstandig het ontwikkelteam na oplevering van het projectresultaat helemaal op te heffen. Het is aan te raden een zekere ontwikkelcapaciteit achter de hand te houden.
Zeker als je open wilt blijven tijdens verbouwing kan het voorkomen dat de bestaande en de nieuwe ICT een tijd lang samen worden gebruikt; de bestaande ICT kan bijvoorbeeld als terugval-optie in stand worden gehouden. Het zal duidelijk zijn dat dergelijke situaties specifieke maatregelen vereisen. Aan het in de lucht houden van de bestaande software kleeft trouwens wel een risico: gebruikers gaan de nieuwe software / werkwijze mogelijk vergelijken met de bestaande en die vergelijking valt vaak uit ten gunste van de meest vertrouwde, d.w.z. de bestaande.
Het tempo en de volgorde van implementatie is afhankelijk van het bedrijfsbelang (en dus niet een keuze tussen een zgn. “big bang” of een meer geleidelijke aanpak). Het is van belang je niet uitsluitend te laten leiden door wat vanuit ICT-perspectief belangrijk is maar ook door wat bedrijfsmatig belangrijk is.
Iedere implementatie vergt zowel technische als organisatorische aanpassingen. Soms gaat het om wijzigingen “onder de motorkap”. Meestal zijn dit puur technische wijzigingen die weinig of geen gevolgen hebben voor de medewerkers / gebruikers die betrokken zijn bij de primaire bedrijfsprocessen (zie Het management van ICT-projecten: analyse); maar wel voor bijvoorbeeld medewerkers / gebruikers die betrokken zijn bij het beheer en onderhoud van de ICT. Veel wijzigingen hebben echter, direct dan wel indirect, meer gevolgen, niet alleen technisch maar ook organisatorisch dan wel rechtspositioneel.
Geen enkele applicatie is vrij van fouten. Hoeveel er ook is geanalyseerd en getest. De impact van fouten en storingen in een bedrijfsomgeving (productie) kan veel groter zijn dan in een relatief veilige testomgeving. Ook als aan alle eisen wordt voldaan is het mogelijk dat er aanpassingen nodig zijn. Afgezien van onvoorziene afwijkingen in het gebruik, kunnen ook opschalingsproblemen op de loer liggen, bijvoorbeeld vanwege een veel groter aantal gelijktijdige gebruikers.
Vaak moeten er als onderdeel van de implementatie ook gegevens worden overgezet. Dit vereist een aanpak die zorgvuldig moet worden voorbereid. Gegevens zijn immers vaak het kapitaal van een bedrijf. Dit is niet altijd eenvoudig. Ook hier moet een keuze worden gemaakt tussen een zgn. “big bang” of een meer incrementele, fasegewijze aanpak. In veel gevallen wordt de migratie van gegevens gecoördineerd met de implementatie van de overige ICT.
Implementatie vereist aandacht voor de gebruiker. “De” gebruiker bestaat niet, iedere gebruiker is uniek en meestal zullen meerdere gebruikers betrokken zijn, mogelijk met verschillende rollen. Gebruikers zijn niet altijd betrokken geweest bij de ontwikkeling. Wijzigingen van de rol dan wel de rolverdeling kunnen ingrijpend zijn. Het is belangrijk hier alert op te zijn. Het is niet altijd te voorzien hoe medewerkers reageren / omgaan met veranderingen. Soms bestaat de neiging om de bestaande situatie als uitgangspunt te nemen. Vaak geldt dan: je weet wat je hebt maar je weet niet wat je krijgt. Niet altijd is duidelijk welke veranderingen er (nodig) zijn. Dit geeft veel onzekerheid.
Het is mogelijk dat benutting van de software een andere werkwijze vereist. Het kan moeite en tijd kosten om deze eigen te maken. Het is daarom van belang niet te laat te beginnen met scholing maar ook niet te vroeg. Kennis en vaardigheden zijn anders al weer vergeten tegen de tijd dat ze nodig zijn.
Hoe dan ook, een goede ondersteuning van gebruikers is essentieel. Niet alleen bij de voorbereiding maar ook tijdens de invoering en bij het gebruik. Beheer en onderhoud moeten goed ingeregeld en toegankelijk zijn.
Implementatie kan lang duren en de kans is daarom groot dat er, tijdens de implementatie, substantiële wijzigingen plaatsvinden. De wereld staat niet stil: het bedrijf verandert, technologie wordt verder ontwikkeld, wet- en regelgeving veranderen, er zijn “updates” of “upgrades”, et cetera. Veel van deze wijzigingen zijn niet te voorzien maar kunnen een behoorlijke invloed hebben.
Documentatie en onderhoud zijn vaak niet, of slecht, geregeld. Veel wijzigingen gaan ook sluipend. Medewerkers passen hun werkwijze aan aan de ICT want het kost doorgaans meer moeite / tijd om ICT aan te passen. Dit kan dan leiden tot “work arounds”. Ook worden veel wijzigingen van de ICT niet of niet goed gedocumenteerd (met name het waarom wordt vaak niet vastgelegd. Veel kleine aanpassingen kunnen tot behoorlijke veranderingen leiden. Deze worden pas opgemerkt als er aanpassingen noodzakelijk zijn of als er problemen (dreigen te) ontstaan. Het is dan ook raadzaam om de afstemming tussen medewerkers en de software die ze gebruiken boven tafel te houden: bijvoorbeeld door het op te nemen als agendapunt in het werkoverleg. Het is zaak dit overleg op gebruikersniveau te houden. Het is belangrijk om bedrijfsfocus te houden. Dit sluit beter aan bij de beleving. Technologie verandert snel. De kans is groot dat de technologie sneller verandert dan de bedrijfsvoering. Het documenteren van bedrijfsprocessen is daarom vaak relevanter dan het documenteren van de technologie.
Evaluatie is niet populair (gedane zaken nemen geen keer en de kosten zijn al gemaakt) maar wel leerzaam (wat kan beter). Het nalopen van het traject (hoe is het gegaan) en het tegen het licht houden van het resultaat (wat heeft het opgeleverd) kunnen erg nuttig zijn.
Uiteraard is er tijd nodig om veranderingen te laten indalen. Dit kan lang duren en vaak zijn er dusdanig veel veranderingen dat een nieuw evenwicht niet wordt bereikt.