Bouwen van bruggen en ERP – Waarom mislukken er zoveel IT-projecten?

Laten we er geen doekjes om winden, IT-projecten mislukken op grote schaal. Dat blijkt uit zowel uit signalen van mensen uit de praktijk (o.m. Standish Group) als uit onderzoek van academici. Er wordt geschat dat 25% van de opgestarte IT-project worden gestopt en afgevoerd, daarnaast gaan ongeveer 50% van de IT-projecten over tijd en ruim over budget. Wanneer het budget of de timing toch wordt gehaald dan is dat meestal met inboeten aan functionaliteit. Deze projecten leiden vaak een eigen  leven, niet echt succesvol, maar te veel geld en middelen zijn geïnvesteerd om het project af te voeren. Uiteindelijk blijken dus slechts 25% van de project echt succesvol te zijn. Elk project zal wel ergens zijn specifieke redenen hebben waarom het is gefaald is, maar de globale economische en sociale schade is wel aanzienlijk. Het ergste is dat IT-mislukkingen zich maar blijven voortdoen en dat nu reeds vanaf het moment dat computers in organisaties werden ingevoerd. Het lijkt er op dat organisaties maar niet leren om te gaan met het probleem en integendeel immuun zijn voor veranderingen. Wellicht zal dit voor velen geen geheim zijn. Toch zijn deze cijfers indrukwekkend. Wat kunnen hierop zeggen? Vooreerst moeten we kritisch blijven en het hoofd koel houden. Een nuchtere analyse kan ons veel meer helpen.

En er is best al heel wat onderzoek gedaan op het fenomeen van IT-mislukkingen. Volgens prof. R. Ackoff streven informatiesystemen een verkeerd doel na. Ze mikken op het beheren van gegevens of  informatie en in het beste geval op kennis, maar nooit op wijsheid. Bovendien leveren ze te veel overbodige informatie en te weinig relevante informatie. Als voorbeeld kunnen we de ERP-systemen nemen. Die zijn al zo complex en toch is er nog een extra laag aan ‘business intelligence’ nodig om managers de noodzakelijk informatie te kunnen bieden. Andere onderzoekers maken de bedenking dat de complexe natuur van menselijke samenwerkingsverbanden zoals IT-projecten, niet louter kunnen verklaard worden door toepassing van de natuurwetenschappen. Uit de talrijke onderzoeken blijkt daarentegen dat de oorzaken amper te vinden zijn in de technologie zelf. Toch blijft een eenzijdige regeltechnische aanpak overheersen. Een mens laat zich niet leiden door de wetten van de fysica, maar kan daarentegen de eigen wil laten domineren en dus bepaalde keuzes maken die door anderen als zijnde irrationeel kunnen worden beschouwd. Bovendien kan een situatie waar een IT-project wordt uitgevoerd niet gesimuleerd of nagespeeld worden in een labo. Elke methode die zich tot doel stelt een IT-project te willen beheersen zal dus moeten rekening houden met contingenties. Dit is meteen al een ernstige tekortkoming aan de meeste methodes. Er wordt te veel uitgegaan van een ideale situatie die via bijsturing moet kunnen worden bereikt. Een ideale situatie bestaat meestal niet. Waarom er dan naar toe streven? Zo is geweten dat de impact van een informatiesysteem op de efficiëntie en effectiviteit van een organisatie zeer moeilijk te bepalen is. Waarom wordt er dan gedaan alsof dit een probleem is van het vinden van de juiste parameters? Als je maar aan de juiste knopen draait dan komt het wel in orde! Het probleem wordt dus herleidt tot het vinden van de juiste regelaars.

De bouwers van informatiesystemen vertrekken bovendien steeds vanuit de veronderstelling dat ze weten wat ze bouwen. Zoals een ingenieur die een brug bouwt. Een bouwkundig ingenieur kan zich echt voor 100% focusseren op de bouw van een brug. De functie van een brug is immers zeer eenvoudig en vooral zeer duidelijk te beschrijven en te meten. Niet dat de bouw van een brug eenvoudig is, maar een brug blijft een eenvoudig artefact. Het bouwen van een informatiesysteem zoals een ERP-systeem bijvoorbeeld is wel van een andere orde. Opnieuw een voorbeeld uit de ERP-systemen. Een ERP-systeem wordt door sommige organisaties gebruikt als een geïntegreerd systeem om de volledige administratieve afhandeling te automatiseren, terwijl andere bedrijven er amper in slagen behoorlijk correcte verkoopfacturen te produceren en dat met eenzelfde ERP-systeem.

In tegenstelling tot de bouw van een brug, is het doel van een informatiesysteem dus helemaal niet duidelijk. Dat is meteen de kern van het probleem. Hoe goed de methodes voor systeem- en softwareontwikkeling ook bedoeld zijn, amper wordt er uitgegaan van een informatiesysteem als een sociaal systeem. Wanneer we de factor mens wegdenken, dan blijft inderdaad slechts het bouwen een brug over en dan kunnen we het gehele arsenaal aan beschikbare inzichten uit de wetenschappen en toegepaste wetenschappen bovenhalen.

Het onderwijs speelt dan ook een zeer belangrijke rol in deze problematiek. Nog steeds worden er ingenieurs opgeleid die informatiesystemen bouwen als bruggen. Hun streven is de bouw van de brug efficiënter en effectiever te maken, maar bijzonder weinig aandacht gaat daarbij naar de functie en ‘sensemaking’ van informatiesystemen. Het cruciale probleem is natuurlijk de sociale dimensie van informatiesystemen, de gebruikers dus.  Meestal wordt de gebruiker herleid in een eenvoudig model dat meegenomen kan worden in het bouwproces. De curriculum van de opleidingen die streven naar het afleveren van mensen die informatiesystemen kunnen (of willen) bouwen moet mijns inziens dringend herzien worden en veel meer multidisciplinair worden. De eenzijdige technisch aanpak heeft hier duidelijk gefaald.

jan devos

Advertisements

About jangdevos
I'm an IT/IS professor, a late Baby Boomer, married with Ann and father of Hélène and Willem, a Stones fan and interested in almost everything. I work at the UGent (campus Kortrijk), Belgium. My research domain are: IT Governance in SMEs, IT/IS Security, IT Management, IT Project Management, IT Trends and IT/IS failures.

5 Responses to Bouwen van bruggen en ERP – Waarom mislukken er zoveel IT-projecten?

  1. Een van de problemen is dat wij het bouwen van software zijn gaan enten op het projectmatige model waarmee we andere zaken aanpakken (zoals bouwkunde en bandwerk/massaproductie). Vandaar ook de naam ‘software engineering’. Maar de kost van massaproductie in software is zowaar bijna onbestaande (ik heb het over kopiëren van bits en compileren van code). Software gaat in feite om het prototype (waarvan je er maar één nodig hebt). Je moet dus, denk ik, de vergelijking maken met het plan en de maquette van de brug eerder dan met de brug zelf. Maar de ganse agile beweging lijkt dat te hebben gesnapt. Vandaar ook het toenemende belang van emerging design. Software moet niet perfect zijn maar vooral buigzaam (aanpasbaar). Om nog even de vergelijking door te trekken. We gaan een brug niet verplaatsen. Ze zal zich nooit moeten aanpassen aan een andere bestemming. Ze zal niet langer of korter moeten worden. In dat opzicht is een brug maken makkelijker.

    ‎”Deze projecten leiden vaak een eigen leven, niet echt succesvol, maar te veel geld en middelen zijn geïnvesteerd om het project af te voeren.” Dit is natuurlijk eerder een ego/management probleem dan een probleem van softwarebouwers. In de psychologie bestempelen ze dat als ‘verzonken kosten’ (sunk costs effect).
    3 minuten geleden · Vind ik leuk

    In bovenstaand verband is zeker het boek van Neal Ford interessant (The Productive Programmer). Althans toch de helft ervan 🙂

  2. jangdevos says:

    Akkoord met je opmerkingen Dirk, behalve bij het sunk costs verhaal. Dit is uiteraard een management/ego probleem, maar het heeft zijn wortels in het falen van het project. Dit wijst ook op een nog steeds grote kloof tussen management en IT. Management commitment naar IT- projecten is heel vaak zoek.

    • Dat klopt natuurlijk. De beslissing om goed geld achter slecht te gooien is echter hoe dan ook een afwikkeling daarvan. Of nog, zonder faling van het project zou er geen ‘slecht’ geld zijn. Maar dan de beslissing at-hand kan/moet dan wel genomen worden met die nieuwe informatie. Ik bedoel maar: het sunk costs effect zou zonder de faling niet kunnen optreden, maar het verschijnen ervan hoeft niet noodzakelijk een oorzaak te zijn van die faling. Tenslotte kan het falen van een project en de beslissing om daar verder geld in te steken vaak worden genomen zonder IT-kennis en grotendeels op basis van burn-rate en outcome.

  3. ik bedoel natuurlijk ‘de beslissing om daar verder GEEN geld in te steken’

  4. De implementatie van een ERP is een complex gegeven en wordt bijna altijd onderschat. Het vergt kennis van de business (wat willen we en kunnen we ermee bereiken), bedrijfsprocessen (administratief, logistiek,… best practices, optimalisatie,…), de mogelijkheden van een ERP (wat kan, wat kan niet,…), technische inzichten en motivatie van mensen, om maar enkele facetten te noemen….
    Het multi disciplinair karakter zoals vermeld in de tekst.

    Veel aanbieders proberen het nochthans als eenvoudig voor te stellen (vb. cloud: voor sommigen kan ERP als een commodity beschouwd worden en tappen we dit gewoon in de gewenste hoeveelheid af van het net,…) en veel klanten geloven dit maar al te graag, of missen de nodige kennis om als volwaardige sparring partner met hun ERP-leverancier te kunnen onderhandelen.

    Resultaat is onderschatting en het idee dat software + wat parameters zetten voldoende is. Dat men dan nog dikwijls verwondert opkijkt als de meerwaarde niet gerealiseerd wordt vind ik altijd verrassend.

    Ik kan quasi volledig akkoord gaan met de tekst maar blijf toch met de vraag zitten hoe dit omgekeerd kan worden. Onderwijs is 1 element, het bewust maken van bedrijven omtrent de complexiteit is een ander. Zeker met leveranciers die constant proberen om alles zo eenvoudig mogelijk voor te stellen, gehuld in een waas van voor de klant ondoorzichtige terminologie.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: