De cost of not implementing: wat kost het je als je niet beslist?

ROI versus CONI: 

Bij elke investeringsbeslissing rekenen organisaties netjes de ROI uit, return on investment. Hoeveel geld ga ik verdienen, en waar ligt het omslagpunt? Soms keurig op basis van de cijfers, soms doorspekt met emoties, maar in elk geval: het wordt berekend.

Wat zelden gebeurt, is de tegenovergestelde berekening. Guus heeft daar zelfs een term voor bedacht: CONI, Cost Of Not Implementing. De keerzijde van de munt. Want als je weegt wat een investering oplevert, moet je net zo goed wegen wat het kost om het niet te doen. En in de praktijk is die tweede vraag vrijwel altijd onderbelicht.

Waarom uitstel zo aantrekkelijk is

Voor Dirko begint het gesprek met een eerlijke bekentenis. Na twintig jaar ERP-implementaties weet hij hoe lastig het is om een ROI sluitend te krijgen. Tijdwinst op handmatige Excel-werkzaamheden, dat lukt nog wel. Maar veel waarde zit in cultuur, in nieuwe werkwijzes, in dingen die zich niet in een rekenmodel laten dwingen. Laat staan dat je de CONI ervan kunt becijferen.

Guus erkent dat ruiterlijk. Maar het uitgangspunt is wel duidelijk: "As a human species, we don't like change." Vergelijk het met stoppen met roken. Je hebt geen stuurgroep nodig, geen IT-plan, geen budget, je kunt het in je eentje beslissen. En tóch is het ontzettend moeilijk. Hoe veel moeilijker is het dan om een werkwijze, een bedrijfscultuur en het softwaregebruik van een hele organisatie te veranderen?

Het gevolg is dat veel organisaties keurig de selectie doorlopen, maar dat de meest gekozen "oplossing" uiteindelijk geen oplossing is. De populairste keuze is geen keuze. "Komt u over twee jaar maar terug, Blisss."

Wie krijgt de schuld? 

Wat zit er dan onder die uitstelreflex? Vaak gewoon menselijke emoties en organisatorische dynamiek. Wie krijgt de schuld voor een vroegtijdige vervanging? Guus ziet bedrijven die zeggen: "Eigenlijk weten we wel dat het hard nodig is, maar over twee jaar gaat onze CFO met pensioen, dan hebben we de handen vrij."

Of een andere klassieker: de investering is nog niet afgeschreven. "Met alle respect voor boekhouders," zegt Guus, "maar dan zijn de boekhouders de baas. We hebben afgesproken dat we het in vijf of acht jaar afschrijven, en het is nog niet afgeschreven. Intussen klopt je administratie niet, verlies je klanten, kloppen je leveringen niet, lopen je medewerkers gillend weg." Hij vat het scherp samen: hoe stom zou het zijn om te zeggen dat je dak lekt, maar dat je pas verhuist als de investering in dit huis is afgeschreven?

De opbrengsten van uitstel: bestaan ze echt?

Pak een willekeurige periode van twaalf jaar. Er zijn organisaties die in die periode twee keer een herimplementatie doen, met hun bestaande pakket en met een nieuw pakket. Er zijn er ook die al twaalf jaar met hetzelfde systeem werken. De laatste besparen zich een implementatie, en wellicht licentiekosten (al ziet dat er in de wereld van SaaS heel anders uit dan vroeger).

Maar daar staat tegenover wat in IT-jargon technical debt heet: je achterstand op wat technologisch mogelijk is, wordt steeds groter. Dat helpt je concurrentiepositie niet. En het maakt de migratie die er ooit toch komt niet makkelijker, integendeel. Bedrijven die nog werken met traditionele on-premise software vol maatwerk, hebben daarmee de complexiteit verlengd. Medewerkers zijn er niet blij mee, klanten zijn er niet blij mee. De echte vraag is dus: wat is de opbrengst van uitstellen écht, behalve het korte termijn fijne gevoel?

Waarom je de consequentie pas ziet als het bijna te laat is

Guus deelt een voorbeeld dat exact laat zien waarom KONI zo lastig is: je merkt het pas als het bijna te laat is. Een meubelproducent, toeleverancier van een grote handelsketen voor tuinmeubels, kreeg op een dag een brief. De grote klant, goed voor 40 procent van de omzet, was overgestapt op een nieuw systeem en wilde voortaan via EDI samenwerken met haar toeleveranciers. Of ze maatregelen wilden treffen.

Het systeem van de meubelproducent was zó oud dat er, in Guus' woorden, "nog geen flessenpost in zat, eerder een postduif." EDI was niet beschikbaar, niet snel te realiseren, gewoon niet aanwezig. Plotseling lag de vraag van de markt niet meer bij de IT-afdeling achter in de gang, laatste deur links, maar op tafel bij de directie. Want kunnen ze niet leveren wat de klant vroeg, dan zouden ze die klant kwijtraken.

En op zo'n moment beginnen met voorbereiden? Dan ben je te laat.

De moeilijkheid van uitstel is dus dat de consequenties pas zichtbaar worden als het waarschijnlijk al te laat is. De wereld om je heen verandert: je partners, je klanten, je medewerkers. Hoe lang kun jij ongestraft op een eiland blijven zitten?

Dirko trekt de parallel met afvallen. Eén dag een Mars eten is geen probleem. Twee dagen ook niet, drie dagen ook niet. Maar als je dat vijftig dagen consequent doet, zie je het wél op de weegschaal. Zo zit het hier ook: elke dag op zichzelf is geen reden, maar het kantelpunt komt onverbiddelijk. De vraag is alleen: wanneer voel je dat?

Wanneer is acht jaar oud te oud?

Guus pakt een concreet voorbeeld voor de Microsoft-gebruikers. Stel: een bedrijf dat in 2018 met Dynamics NAV is gaan werken. We schrijven nu 2026, dus acht jaar onderweg. Lang of kort? Daar is geen objectief antwoord op, dat mag iedereen zelf bepalen. Als alles nog goed functioneert, hoeft het niet per se in de software te zitten.

Maar er is wél een fundamenteler punt. Het systeem dat je vandaag gebruikt, is geïmplementeerd in een wereld voor COVID. En sindsdien is er nogal wat veranderd. We zijn ineens digitaal gaan communiceren met klanten. De customer journey, de klantreis, is enorm veranderd. De klant heeft een korter lontje. Die wil snelheid, transparantie, dat het in één keer goed gaat. Die haat complexiteit.

En dan kijk je naar je systeem uit 2018, toen de zon nog scheen. Dát is volgens Guus de allergrootste drijfveer waarom organisaties zouden moeten moderniseren.

Het gaat niet om je software, het gaat om je processen

"Moet ik dan per se nieuwe software kopen?" vraagt Dirko.

Nee, zegt Guus, dat zou niet de eerste insteek moeten zijn. De juiste vraag is een andere: als wij vandaag opnieuw zouden implementeren, zouden we dan weer kiezen voor de manier waarop we het nu doen? Een gemiddelde levertijd van 48 of 72 uur, terwijl de concurrent het in 24 uur doet. De huidige manier van factureren, urenboeken, alle processen zoals ze nu lopen.

Als het antwoord op die vraag "nee" is, dan ligt er een serieus thema op tafel. Niet je verouderde software, maar je verouderde processen. En vanuit dat punt kun je vervolgens kijken: lukt het om in mijn bestaande systeem die processen te veranderen? Zo ja: ga lekker verder met die software. Maar als de software toch al acht jaar oud en on-premise is, dan is het waarschijnlijk een kortere klap om de hele transformatie ineens te doen.

Een ERP-vervanging is dus geen IT-discussie. Het is een strategische keuze. En de IT komt pas in tweede instantie aan bod.

Zou je zelf klant willen zijn van je eigen bedrijf?

Guus geeft een hulpvraag mee die hij regelmatig stelt aan directies: als jij niet de baas was van dit bedrijf, maar je zou in de doelmarkt zitten van jouw huidige bedrijf, zou je dan klant willen zijn? Met alles wat je weet over wat er goed en slecht gaat. Behandelt je bedrijf zijn klanten anders dan jij persoonlijk behandeld zou willen worden?

Het is een ongemakkelijke vraag, en juist daarom een goede.

Begin niet bij IT, begin bij je klanten en je medewerkers.

Hoe kom je er als directie achter waar het knelt? Guus geeft een paar concrete plekken om te kijken:

Kijk in je debiteurenadministratie. Bel klanten die hun facturen niet betalen, en vraag waarom. Tien van de tien keer heeft het te maken met jouw processen, jouw beloftes, hoe accuraat je bent. Kijk naar je churn. Naar je rechtszaken, als je die hebt (hopelijk niet). Daar vind je een fantastische bron van inspiratie over waar je processen kapot zijn.

En kijk vooral ook naar je medewerkers. Want die werken thuis op de modernste IT, hebben AI tot hun beschikking (en nemen dat soms gewoon mee naar kantoor, hallo schaduw-IT en schaduw-AI), gebruiken de modernste telefoons. En komen vervolgens op kantoor in een user interface uit 2018 of nog ouder. Onderzoeken laten zien dat jonge mensen, generatie Y en Z, op het laatste moment kunnen afhaken bij een sollicitatie als ze horen welk systeem ze moeten gebruiken. Of ze beginnen, en zijn binnen een maand weer weg.

Het is dus geen IT-project. Het is een strategische keuze met directe impact op klantbehoud en personeelsbehoud.

Waarom snelheid en transformatie niet samengaan

Hoe begin je dan? Iedereen is druk. 328.000 vacatures in Nederland. Niemand heeft tijd voor zo'n traject.

Guus pakt een metafoor die in Nederland sinds Max Verstappen iedereen begrijpt: een ERP-implementatie is een pitstop in de Formule 1. Max rijdt voorop, en wat doet hij? Hij parkeert zijn auto in de pits. Zo kort mogelijk, want intussen vliegen nummer twee en drie voorbij. Waarom in godsnaam? Omdat hij even tijd investeert om daarna onder betere condities, met betere banden, een sprong vooruit te maken.

De fout die in veel organisaties wordt gemaakt: men zet voor het komende jaar een omzetbudget van plus 20 procent neer, én verwacht tegelijk dat de auto wordt opgeknapt. Die twee dingen gaan moeilijk samen. Je krijgt te weinig tijd, de verkeerde key users (of de juiste key users met te weinig tijd), en je bereikt je doel niet. Het resultaat: je vervangt je on-premise software door een cloudversie, maar onder de motorkap zitten dezelfde verouderde processen, dezelfde slechte data, dezelfde oude rapportages, dezelfde mindset van vroeger. Je bent dan op een moderne manier bezig om klanten te verliezen en slechte leveringen te doen.

Dirko herkent het en suggereert een concrete denkrichting voor CFO's: plan een jaar in waarin je niet 10 procent meer omzet wilt maar bewust 3 of 5 procent accepteert, omdat je een transformatie doet. Geef je organisatie de ruimte van een echte pitstop.

Guus herinnert eraan dat er in coronatijd twee soorten reacties waren. De ene groep sneed alle kosten weg en bleef met de oude spullen door. De andere zei: "Het waait wel weer over, en als het overwaait willen we klaarstaan." Die laatste groep nam de tijd voor een pitstop. De vraag is: ben je bang voor oude ideeën, of ben je bang voor nieuwe ideeën?

Fase 0: waar het succes of falen al beslist wordt

In de masterclasses die Guus al twintig jaar door heel Europa geeft, ziet hij dezelfde patronen terugkomen. De meeste deelnemers uit het MKB zijn in hun hele leven één, hooguit twee keer verantwoordelijk voor zo'n implementatie. Het zijn juniors. Het besef dát te zijn, is al een belangrijke eerste stap.

Wat Guus consequent ziet: negen van de tien keer wordt succes of falen niet bepaald door de softwarekeuze, en zelfs niet door de keuze van implementatiepartner. Het wordt bepaald in fase 0. De fase voordat je überhaupt met leveranciers gaat praten, voor je naar demo's gaat kijken. Dat is de fase waarin je in je eigen organisatie nadenkt over hoe het beter kan.

Is het strategisch of niet? Welk maatwerk wel of niet? Gaan we onze processen moderniseren of niet? Wie is verantwoordelijk? Hebben we een sponsor? Een hele serie vragen die in fase 0 thuishoren. Wie die overslaat en gewoon naar de winkel gaat om software te kopen, krijgt keer op keer een lastige implementatie.

Hoe krijg je mensen mee?

Dirko stelt de vraag die in de praktijk vaak speelt. Hoe krijg je de organisatie zo ver dat ze niet alleen de directie volgt, maar zelf ook gaat zien wat er moet veranderen?

Guus heeft een uitgesproken positief mensbeeld. In de meeste organisaties weten mensen op de werkvloer en in het middenmanagement al lang dat het beter kan en beter moet. De uitstelbeslissing wordt zelden daar genomen. Die wordt in de directiekamer genomen. En in diezelfde directiekamers hoor je vaak het tegenovergestelde verhaal: "Onze mensen willen niet veranderen, ze zijn te star." Guus gelooft daar niet in. Mensen zijn prima bereid te veranderen, maar dan moeten er wel een paar dingen kloppen: betrokkenheid, informatie, tijd om na te denken, ruimte voor suggesties.

Hij ziet directies die werken met een codewoord voor hun ERP-vervanging, om te voorkomen dat medewerkers er "te vroeg lucht van krijgen en nerveus worden." Dat is precies wat je niet moet doen, vindt Guus. Want dan komt het ineens van bovenaf als voldongen feit. Begin er juist vroeg over. Vraag mensen waar het beter kan. Wat zou er anders moeten in proces ABC, in rapportage XYZ?

Dat input verzamelen kan op verschillende manieren: een prijsvraag per afdeling, een vast agendapunt in afdelingsoverleggen, of zelfs een zaterdag waarop iedereen die wil welkom is om mee te denken. "Je zou verbaasd staan hoeveel mensen bereid zijn." En nee, niet elk idee wordt automatisch gehonoreerd. Maar het feit dat er geluisterd wordt, dat er doorgevraagd wordt, helpt al enorm om mensen betrokken te maken.

Het smeltende ijs van legacy-kennis

Een ander punt waar de CONI hard aanwezig is: de beschikbaarheid van kennis bij je implementatiepartner. In de Microsoft-wereld zijn er nog volop Navision on-premise klanten in Nederland. Maar Guus stelt een eerlijke vraag: als je nieuwe mensen aanneemt die van de universiteit komen, train je die nog in Navision? Het antwoord is overal hetzelfde: nee. En van de Navision-experts die er nu zijn, gaat een deel met pensioen, een deel vertrekt. De kennisbasis is een ijsschots die smelt.

Hij geeft een voorbeeld van een bedrijf in midden Nederland dat met een Amerikaanse applicatie werkte (in Nederland niet erg succesvol) en al tien jaar leunde op één financieel consultant uit de UK. Die man had aangekondigd over drie maanden met pensioen te gaan. "Drie jaar geleden wist hij dit toch ook al?" vraagt Dirko. Maar mensen blijven graag in hun comfortzone.

De vraag die Navision-klanten zich zouden moeten stellen: hoe lang is mijn implementatiepartner nog in staat én bereid om volledige support te leveren? Microsoft heeft voor Navision nog geen harde end-of-life-datum gezet (voor Great Plains wel, en SAP doet het volop). Maar elke leverancier denkt op dit moment na over hoe lang ze nog support willen en kunnen leveren.

Guus' praktische advies: stuur een mail of brief naar je leverancier en vraag zwart-op-wit aan tot welke datum, met welke mensen, ze nog support kunnen leveren. Dan weet je waar je staat in je cyclus. En vergeet niet: hackers richten zich juist graag op de "weeskinderen", systemen die minder gebruikt worden en minder support hebben. Een on-premise systeem dat aan zijn eind loopt is daarvoor extra vatbaar.

Vraag dan eens een gedegen externe partij of een paar leveranciers om in te schatten hoe lang jouw implementatie zou duren. Verdubbel die inschatting, doe het nog een keer keer twee, en tel zo terug vanaf je end-of-support datum. Dan weet je of je vandaag op tijd bent, of dat je vorige week al had moeten beginnen.

De externe duw: wat je niet kon voorzien

Niet alle CONI is zelf veroorzaakt. Soms duwt de wereld om je heen je naar een beslissing toe. Dirko geeft een actueel voorbeeld: Trump gooit er nieuwe importtarieven in, en plots is er 10 procent extra opslag waar je razendsnel op moet kunnen sturen. Hoe veranderen mijn kostprijzen? Hoe pak ik dit anders aan? Een klant van Blisss die de transformatie al doorlopen had, kon binnen een dag of twee schakelen. Dat hadden ze nooit kunnen voorzien, en het stond in geen enkel KONI-rekenmodel. Maar net als het EDI-voorbeeld van Guus: er gebeuren dingen om je heen die je zelf niet in de hand hebt. Het verschil tussen "klaar zijn" en "te laat zijn" is dan dagen, geen jaren.

De conclusie: vandaag is de op één na beste dag om te beginnen

Wat is dan de boodschap voor iemand die dit gesprek heeft gevolgd?

Guus formuleert het scherp. Vorige week beginnen kan niet meer. De op één na beste keuze is vandaag, niet morgen. Vandaag beginnen met nadenken. Niet meteen software kopen, niet meteen leveranciers bellen. Maar nadenken in fase 0: wat zijn onze processen, wat moet anders, wat verlangt onze klant, wat verlangen onze medewerkers, hoe lang kan onze huidige situatie nog?

Het draait niet om IT, het draait om strategie. En het is geen verantwoordelijkheid die je kunt delegeren naar de IT-afdeling achter in de gang. Als het misgaat, na al die jaren ervaring van Guus, is er één groep aanspreekbaar: de directie.

Iedereen is druk. Dat snapt Guus. Maar dit is urgent. En als je de urgentie niet inziet, dan wordt het vanzelf urgent op het moment dat je echt te laat bent. En dat gun je niemand.

Benieuwd hoe Blisss Software je begeleidt bij die strategische overstap? Neem gerust contact met ons op. En luister of bekijk de volledige aflevering van Digital Leaders Talk voor het hele gesprek met Guus Krabbenborg.