Veel IT-projecten mislukken volgens het ‘car crash in slow motion’-scenario: een langzame, voorspelbare mislukking die in ruwweg zes stappen verloopt: van de selectie van softwarepakketten, de contractfase, de fases van analyse en design, configuratie en bouw, test en acceptatie tot de escalatiefase. Meestal volgt hierna een dure, complexe aanpassing waarbij vooral naar de pijpen van key users en IT-managers wordt gedanst.

De zes fasen van het ‘car crash in slow motion’-scenario:

1. Voorbereiding pakketselectie

Het projectteam, bestaande uit de key-users en de applicatie-experts van IT, start met de procesbeschrijvingen (huidige processen + knelpunten, verbeterpunten) en de beschrijving van het huidige applicatielandschap inclusief de interfaces. Ook stellen zij een vaak zeer gedetailleerde lijst met eisen en wensen op.

Requests for information (RFI’s) worden verstuurd naar alle potentiële kandidaten. Via een longlist/shortlist-procedure wordt een lijst met circa de vier beste pakketten opgesteld. Met deze vier pakketten wordt het selectietraject intensief voortgezet (request for quotations, referentiebezoeken, demo’s) en vaak wordt van het beste pakket een proof of concept (PoC) gevraagd. Na de PoC wordt aan de leverancier een request for proposal gevraagd.

Stap 1 duurt vaak vier tot zes maanden en wordt geleid door de IT-manager/CIO, vaak in samenwerking met de CFO.

2. Contractfase

De onderhandelingen worden gestart. De CEO wordt er nu bij betrokken, en ‘na enig stevig heen en weer onderhandelen’ over met name de prijs wordt het contract getekend.

3. De analyse- en designfase

De eerste twee fases van de implementatie vormen de analyse- en designfase: de consultants verdiepen zich in het bedrijf, analyseren de workflows en de processen met de key-users en maken de eerste ontwerpen voor hoe de huidige processen in de software ingericht zullen worden. Na de inhoudelijke goedkeuring, vaak door de key-users, wordt deze fase afgesloten. In veel gevallen overigens zijn in deze fases zowel alle licenties als de benodigde hardware en infrastructuur al gekocht en ingericht.

4. De configuratie- en bouwfase

Hierna start de leverancier met de configuratie en bouw van de software en de interfaces. De key-users beginnen vaak al met het schrijven van de testscripts, en ook wordt de eerste aanzet tot dataconversie gestart, et cetera.

5. De test- en acceptatiefase

De key-users krijgen nu voor het eerst een goed beeld van de totale softwareoplossing. En dat valt niet zelden heel erg tegen: ‘Zo werken we hier niet.’ ‘Hier valt niet mee te werken.’ ‘Dit is niet wat we bedoelden.’ Uiteraard zitten er dan ook nog fouten in de software… De verwachtingen van de key-users zijn altijd hooggespannen en dan valt het altijd tegen.
Nu begint het getouwtrek. De leverancier stelt zich op het standpunt dat, afgezien van wat bouwfoutjes, dit toch echt afgesproken is. Maar de key-users kunnen gefundeerd aangeven dat dit allemaal niet gaat werken; beide partijen staan lijnrecht tegenover elkaar.

6. De escalatiefase

Het escaleert tot op stuurgroepniveau, de CEO wordt er opnieuw bij betrokken en partijen gaan aan tafel. De CEO heeft nu op hoofdlijnen drie opties:

  1. Hij kiest de kant van de leverancier, stelt dat alle bouwfouten et cetera uiteraard opgelost moeten worden, maar als de functionaliteit inderdaad is zoals afgesproken, dan ‘is dit het en gaan we hiermee live’.
  2. Hij kiest de kant van de key-users en laat de leverancier het pakket aanpassen volgens de wensen van de key-users.
  3. Hij constateert dat dit niet meer goed komt en beëindigt het project.
  4. Bijna altijd wordt voor optie 2 gekozen, de software wordt aangepast, uiteraard tegen een meerprijs. Echter, het gaat altijd om serieuze aanpassingen; voor kleine aanpassingen laat een leverancier het niet tot een escalatie komen. Enerzijds betekent dit extra werk, dus extra kosten en extra doorlooptijd. Anderzijds betekent het een ingreep in de logica van het pakket; key-users willen dat het ‘anders’ gaat werken. En dat laatste heeft altijd tot gevolg dat een substantieel deel van de software aangepast moet worden. Vaak moet extra maatwerk ontwikkeld worden. Met als gevolg dat veel tests opnieuw uitgevoerd moeten worden, maar nu met aangepaste software – waar altijd coderingsfouten in zitten.

    Door dit alles komt het project steeds meer onder druk te staan, budgetten worden overschreden, planningen niet gehaald. Voor hardnekkige issues worden work-arounds gemaakt; alle projectleden raken aan het eind van hun Latijn. Het eind van de test- en acceptatiefase wordt gemarkeerd door de go/no go-meeting waarin moet worden bepaald of het voldoende verantwoord is om de ‘go live’-fase in te gaan.

    Nieuwe software is feitelijk nieuwe kennis: de ‘latest best practices’

    In circa de helft van de projecten wordt in de go/no go-meeting met betrekking tot de live-gang besloten dat het risico te groot is. De software is onvoldoende stabiel, de geboden functionaliteit is onvoldoende, er zijn te veel workarounds nodig, er zijn nog te veel open issues, en de leverancier durft geen garantie te geven dat dit binnen afzienbare tijd nog op te lossen is. En alsnog wordt er besloten te stoppen.

    In de andere gevallen wordt besloten dat de ‘go live’-fase toch gestart kan worden en dat de resterende issues in de nazorgfase worden opgelost. De voorbereidingen worden getroffen, de software gaat krakend en knarsend live en er volgen drie tot zes maanden met verhoogde dijkbewaking voordat alles eindelijk redelijk werkt. Maar ondertussen heb je als opdrachtgever een stevige vendor lock-in, want de leverancier is de enige die het maatwerk kan onderhouden en bij toekomstige upgrades en nieuwe releases kan aanpassen. Dus bij elke nieuwe release betaal je weer de hoofdprijs: het maatwerk moet weer aangepast worden.

    De basis is fout

    Hoe kan het zo misgaan? Wie nieuwe software koopt, koopt eigenlijk geen software maar kennis. Kennis van de vele implementaties van deze software die voorgegaan zijn. Eigenlijk gaat het om een hele verzameling ‘best practices’ van de processen die nodig zijn en die je met behulp van deze software in je organisatie wil implementeren.

    Echter, de organisatie beschikt over verouderde software die vaak al jaren gebruikt wordt. En waar de organisatie aan gewend is geraakt. Niet zelden is de organisatie om de oude software heen gevormd en zijn organisatie en software met elkaar vergroeid. Er is dus niet alleen sprake van verouderde software, maar ook een ‘ouderwets denkende’ organisatie. Van eindgebruikers tot MT-leden; ze willen wel nieuwe software, maar de rest moet uiteraard wel ‘hetzelfde blijven’. En dat staat haaks op wat nodig is om nieuwe software, nieuwe technologie succesvol te kunnen implementeren.

    Processen aanpassen

    Want, zoals gezegd, is nieuwe software feitelijk nieuwe kennis: de ‘latest best practices’ op het gebied van procesinrichting. Dat betekent dat de processen moeten worden aangepast aan de mogelijkheden van de software. En niet andersom!

    Om die nieuwe kennis in de nieuwe software te kunnen ontsluiten om daarmee de processen optimaal te kunnen inrichten, is er kennis van die nieuwe software, die nieuwe technologie nodig. Externe experts die de mogelijkheden van de nieuwe software volledig kennen en de manier waarop andere bedrijven dit uitgenut hebben. Dat zijn dus niet de key-users of de IT-experts; zij kennen alleen de huidige processen en de oude software, al weten ze uiteraard wat ze anders zouden willen.

    Stoppen doet niemand, driekwart van het geld is al uitgegeven

    Kort samengevat: als je nieuwe software en/of nieuwe technologie succesvol wil implementeren, dan is ouderwets denken in de organisatie het grootste probleem. Niet de nieuwe technologie, noch de nieuwe kennis. Vanuit die context bezien, rijst de vraag waar de valkuilen in de implementatie zitten waardoor het ‘car crash in slow motion’- scenario ontstaat.

    1. De start is verkeerd

    Vaak wordt gestart met het in detail beschrijven van de huidige bedrijfsprocessen door de key-users. Dat lijkt logisch, maar is om twee redenen verkeerd:

    1. Het vertrekpunt is de actuele situatie op operationeel niveau en niet wat de organisatie met nieuwe technologie/software wil bereiken.
    2. Het vertrekpunt is de actuele situatie beschreven door het ouderwetse denken, zonder kennis van de nieuwe mogelijkheden die de moderne software kan bieden.

    Ook tijdens de selectie wordt dit laatste nauwelijks serieus getoetst; leveranciers tonen graag wat hun software allemaal kan, maar key-users kijken vooral in hoeverre dat past bij hoe zij nu werken. Leidend in het selectieproces is: in hoeverre heeft de software voldoende functionaliteit om ons de huidige werkwijze te kunnen bieden? De technologie-/softwarekeuze wordt feitelijk gemaakt op basis van het oude denken van de key-users, en niet op basis van wat de organisatie ermee wil bereiken. Terwijl dat toch de echte reden was om de verouderde software te vervangen.

    2. Je ziet pas op het eind wat je werkelijk krijgt

    De echt serieuze confrontatie tussen het oude denken en de nieuwe softwareoplossing (omtrent procesinrichting, werkwijze, technologie, et cetera) vindt pas plaats in de testfase. Dit is op circa twee derde van het project, gerekend vanaf het tekenen van het contract en circa anderhalf tot twee jaar nadat is besloten om de verouderde software daadwerkelijk te gaan vervangen.

    3. En dan sta je schaakmat…

    Op het moment dat de werkelijke confrontatie plaatsvindt tussen de ouderwets denkende key-users en de nieuwe software, sta je feitelijk al schaakmat:

    • De organisatie gaat niet om, de key-users zijn ervan overtuigd dat zij juist handelen: ‘Met deze software gaan we er sterk op achteruit, dit gaat hier niet werken.’
    • De leverancier claimt, juridisch vaak uiterst correct, dat de software is ingericht volgens afspraak. Uitzonderingen daargelaten, gaat geen enkele leverancier willens en wetens iets anders opleveren dan wat afgesproken en vaak contractueel bepaald is.
    • Op dit punt in het project is circa 75 procent van de out-of-pocketkosten al gemaakt en betaald (consultancy, hardware, infrastructuur, licenties).
    • Nu stoppen en het verlies voor lief nemen doet niemand; driekwart van het geld is al uitgegeven. De organisatie dwingen de opgeleverde software te accepteren is nagenoeg onmogelijk; die confrontatie gaan slechts weinigen aan.

      Als enige oplossing blijft dus over het door de leverancier ‘ombouwen’ van de software naar de door de key-users gewenste werkwijze. Met als resultaat dat de organisatie krijgt wat zij had, weliswaar in nieuwe techniek maar zonder nieuwe kennis. En met een serieuze hoeveelheid maatwerk waardoor in de toekomst nieuwe releases niet passen. Tegelijkertijd ontstaat een vendor lock-in: alleen de huidige leverancier kan en wil het maatwerk in beheer nemen. Organisatie en leverancier zijn minimaal de eerstkomende vijf jaar tot elkaar veroordeeld. Inclusief hoge kosten.

      Conclusie

      Wie verouderde software/technologie wil vervangen, moet als vertrekpunt nemen wat ze met die nieuwe software willen bereiken. Concreet, helder gedefinieerd. Dat is het vertrekpunt in de selectie van de nieuwe software/technologie.

      Als eenmaal de juiste oplossing is gekozen, worden de mogelijkheden die de nieuwe oplossing biedt leidend. Leidend in hoe de processen ingericht moeten gaan worden, leidend in de implementatie-uitvoering, de projectorganisatie, de besturing. Leidend is niet hoe de key-users en/of IT-experts het willen, leidend is wat de organisatie met de vervanging wil bereiken.


      Dit artikel is een bewerking van een van de hoofdstukken uit Komt een CEO bij de dokter. Hoe IT-projecten mislukken door oud denken, en wat u daaraan kunt doen, Wolter Toet, 2018, Uitgeverij Dialoog. EAN: 9789461262875.

Wolter Toet heeft meer dan 25 jaar ervaring met implementaties bij toonaangevende bedrijven. De valkuilen en vooral hoe deze voorkomen kunnen worden, heeft hij in zijn boek 'Komt een CEO bij de dokter' beschreven.

LAAT EEN REACTIE ACHTER

Laat alsjeblieft een reactie achter!
Laat hier je naam achter