ICT-lessen van OAD

Datum: 07-05-2014

ICT-lessen van OAD

Gisterenavond las ik de novelle ‘Enkele reis Holten’ van Job Woudt, die op 26 april jl. was toegevoegd aan het FD. Het boekje leest als een thriller met fatale afloop. De hoofdlijn is de teloorgang van een familiebedrijf, waarvan de tweede generatie (Joop ter Haar) het bedrijf groot maakt en niet kan loslaten, terwijl de derde generatie niet goed genoeg is om het bedrijf voort te zetten en buitenstaanders niet getolereerd worden. Uit krantenberichten had ik de indruk dat een gezond bedrijf door eisen van de bank om zeep was geholpen, maar deze novelle geeft een beeld van een bedrijf dat al tien jaar in glijvlucht naar beneden is en waar nieuwe ontwikkelingen zoals het boeken van reizen via internet, te laat onderkend zijn. De governance is heel slecht op orde en vertoont alle kenmerken van het familiebedrijf en het pioniersbedrijf waar leiden van het bedrijf, eigendom en (gebrek aan onafhankelijk) toezicht door elkaar lopen. Daar wil ik het nu niet over hebben.

Op het gebied van ICT zijn er uit de OAD-casus lessen te trekken, die ook in de gezondheidszorg te gebruiken zijn. De mislukking van het grote ICT project bij OAD, vertoont allerlei overeenkomsten met moeizaam verlopende of mislukte ICT projecten, die ik in de zorg van een afstand of retrospectief heb mogen beschouwen.

OAD is gegroeid door overname en ontwikkeling van allerlei bedrijven, die verschillende handmatige administraties hebben. Dat moet veranderen, dus wordt ‘Progress Software’ (Pro) gekocht om die administratieve processen te stroomlijnen, efficiencyvoordelen te bereiken en OAD de toegang tot internet te verschaffen. Hier hebben we les 1 Het ICT project krijgt te veel verschillende en onderling onverenigbare doelen.

Op het moment dat OAD Pro in 2005 koopt, werkt 40% van de reisbranche met deze software. De verantwoordelijke man binnen OAD werkt al 17 jaar met deze software. Dat is het standaard programma, maar OAD wil meer en anders. Dus gaat er op basis van de standaard software iets speciaal voor OAD gebouwd worden. Dat gaat uiteraard mis. De eisen waaraan voldaan moet worden zijn niet duidelijk en veranderen tijdens de rit. De medewerkers van OAD vragen van alles en de software leveranciers beloven dat ze alles kunnen maken. Ze zeggen er niet bij tegen welke prijs en in hoeveel tijd. Daardoor loopt het project fors uit de hand. In de zorg zijn veel ICT-projecten om dezelfde reden mislukt, vooral in ziekenhuizen, waar de professionals van alles wilden en het softwarebedrijf maar bleef beloven dat dit zou lukken.

Les 2 is dat je in ICT aan het begin een ‘buy or make’ beslissing moet nemen en daaraan vasthouden. Kies je ervoor een standaard pakket op de markt te kopen, dan is dat wat je gaat gebruiken en wordt je werkwijze daaraan aangepast. Iedereen accepteert de kronkelwegen van Microsoft (druk op start als je wilt stoppen) of de niet minder dwingende formats van Apple en niemand gaat proberen dat programma op maat te maken. Als er software wordt aangeschaft voor een specifieke branche, dan is er wel de neiging om te denken dat ieder programma aan de individuele wensen kan worden aangepast. Dat is een illusie. Als je maatwerk wilt, moet je een eigen programma laten bouwen en niet laten sleutelen aan een bestaand programma. Bij veel ICT-projecten -ook bij OAD- zie je de meest ongunstige combinatie: We kopen een confectiepak dat niet goed zit en laten het aan alle kanten vermaken. Het pak ziet er niet meer goed uit, zit ongemakkelijk en de structuur is weg. In de herenmodezaak hang je zo’n pak terug en pas je iets anders. In de ICT-zaak gaan zowel jij als de ICT-verkoper geloven (en beloven) dat je van een confectiepak op maat gemaakte haute couture kunt maken.

Aan het begin van het Pro project bij OAD is duidelijk dat er gestandaardiseerd moet worden, dat er minder producten aangeboden moeten worden en dat de administratieve processen gestroomlijnd moeten worden. Gaandeweg raken die uitgangspunten uit het zicht en moet Pro zich aanpassen aan de bestaande praktijk i.p.v. omgekeerd. Ook dat zie ik in veel ICT-projecten in de zorg. Op die manier baseer je je ICT-programma voor overmorgen op de werkwijzen van eergisteren. Les 3 is dat je moet vasthouden aan je uitgangspunten en niet je ICT moet aanpassen aan verouderde en niet doorgelichte werkprocessen.

Daarnaast is het telkens weer een probleem dat processen gemoderniseerd moeten worden tegelijk met het bouwen van de software. Dat zou eerst moeten gebeuren met behulp van specialisten in de logistieke en inhoudelijke processen, waarna de ICT-specialisten de daartoe nodige software leveren of (liever niet) bouwen. Nu zijn het vaak de ICT’ers die de werkvloer moeten bewegen om hun processen aan te passen. En er is altijd haast. Les 4 is dat je eerst je processen moet herontwerpen en dan de bijbehorende ICT moet kopen en dat niet de ICT je moet dwingen tot overhaaste en onvolledige aanpassing van de werkprocessen.

Het was binnen OAD niet duidelijk wie verantwoordelijk was voor Pro. Het begon bij de directie, maar later werd een projectleider verantwoordelijk. Die had niet de macht en middelen om veranderingen af te dwingen, wat zeker bijdroeg aan het loslaten van de uitgangspunten. Les 5 een groot ICT-project is van strategisch belang en heeft consequenties tot in alle haarvaten van de organisatie. Het moet geleid worden door iemand die knopen kan doorhakken en het hele bedrijf overziet. Zo’n ICT-project moet daarom direct door de RvB aangestuurd worden. In 2011 besluit de top van OAD om te stoppen met Pro en de totale investering van € 21 miljoen in een keer af te boeken. Er wordt een nieuw, simpel standaardprogramma gekocht dat blijkt te werken in de inmiddels op internet gerichte omgeving. Maar dan is het al te laat, de afboeking draagt bij aan verdere verslechtering van de financiële positie, die uiteindelijk leidt tot het faillissement.

Ik heb inhoudelijk geen verstand van ICT. Maar ik heb wel als manager of bestuurder een paar keer mislukte ICT-projecten op tafel gehad en moeten beslissen om te stoppen of door te gaan. Het werd steeds het eerste, waarna het nog een hele klus wordt om met minimale schade van het project en van de leverancier af te komen. Ook heb ik mogen onderzoeken, waarom een project was misgelopen en wat daaruit de lessen waren. Toen ik het OAD-boekje las, herkende ik veel van die ervaringen en zag ik daarin een aantal algemene lessen, die in deze blog staan.