IT leert niet van haar fouten (Martin Healey)

Begin augustus trok een artikel op de voorpagina van een Engelse krant mijn aandacht. 'Computerproblemen kosten mogelijk levens tijdens zonsverduistering', luidde het bericht. Was dit weer zo'n onzinverhaal dat onze elektronische apparatuur wordt aangevallen door onzichtbare straling? In de ruimte misschien, maar niet tijdens een eclips. Maar nee, het was een serieus rapport, tenminste, voor de IT-industrie.

Het probleem had betrekking op een nieuw systeem voor de Engelse reddingsbrigade, dat niet goed werkte. Persmuskieten hadden de hand weten te leggen op een brief van een manager, waarin hij klaagde over de vele storingen. De relatie met de eclips en de fatale gevolgen daarvan was ingegeven door het feit dat de zonsverduistering in Engeland alleen aan de zuidwestkust volledig te zien zou zijn. Cornwall was al maanden volgeboekt. De kustwacht verwachtte die week een groot aantal kleine schepen, en daarmee een grote kans op ongelukken. De reddingsbrigade was al overwerkt, en het laatste waar ze op zaten te wachten was een defect systeem.
Het is enorm belangrijk dat klachten over slecht functionerende systemen openbaar worden gemaakt. IT-systemen vormen daarop geen uitzondering. Maar in de IT worden problemen zelden op de goede manier openbaar gemaakt, en dat is een groot gemis. Managers houden informatie liever onder de pet, wat ertoe leidt dat andere organisaties weer dezelfde fouten maken. Het is zelfs nog erger, omdat het verbergen van problemen ertoe leidt dat slechte systemen voor een buitenstaander goed lijken te werken, waardoor de ontwikkeling van andere slechte systemen juist wordt aangemoedigd.
In het geval van de reddingsbrigade werden er al snel maatregelen getroffen die de schade moesten beperken. Iets verder in het artikel werd namelijk de opsteller van de gewraakte notitie geciteerd, die verklaarde dat er de laatste drie weken al heel veel aan het systeem verbeterd was. Ik vraag het me af. Of eigenlijk vraag ik het me helemaal niet af - ik weet wel zeker dat er weinig tot niets verbeterd was, maar dat de manager onder druk was gezet om wat positieve uitspraken te doen.
Dit soort onzin is aan de orde van de dag. Ik zie regelmatig afschrikwekkende voorbeelden van totaal onaanvaardbare praktijken, waarover toch maar heel sporadisch wordt gerapporteerd. Zo was er een Nederlands bedrijf, dat tien miljoen gulden uitgaf aan een gerenommeerd adviesbureau om ze te helpen bij de invoering van een werkelijk rampzalig systeem. In een persoonlijk gesprek zei een van de betrokkenen dat ze voor dat geld alleen een kopie van de documentatie van de leverancier hadden gekregen.
Een ander bedrijf installeerde een client/server-pakket voor de boekhouding. Het systeem crashte voortdurend. (Dit is een algemeen verschijnsel, dat voor een tekstverwerker misschien nog net te accepteren is, maar zeker niet voor een zakelijke applicatie.) Toen de leverancier met het probleem werd geconfronteerd, erkenden ze dat er een probleem in de software zat; het had iets te maken met de C++-klassen. Waarom verkochten ze een product waarvan ze wisten dat het niet goed werkte?
In een derde geval werd de grafische versie van een bekend hrm-pakket op het lokale netwerk geïnstalleerd, redelijk tot genoegen. Toen het pakket echter op grotere schaal werd ingezet, bleek het volkomen onbruikbaar te zijn. Nader onderzoek wees uit dat het verkeer tussen de client en de server afgrijselijk traag was. Waarom was dit probleem niet door de leverancier ontdekt en opgelost? Ik begrijp niet dat grote software-huizen rad-tools gebruiken. Ze leiden tot een hogere productiviteit, maar dat gaat ten koste van de betrouwbaarheid. Rad-tools zijn goed voor intern ontwikkelwerk, maar niet voor het bouwen van serieuze applicaties.
Een grote Engelse bank verving een mainframe van 3 miljoen pond door een netwerk met NT-systemen. Het gerucht gaat dat deze vervanging maar liefst 25 miljoen gulden kostte en maanden lang niet gewerkt heeft. Het omzetverlies was dramatisch.
Helaas kan ik nog wel even doorgaan, maar het argument is duidelijk. Er zijn maar weinig van dergelijke catastrofes waar openhartig over wordt gerapporteerd. Niemand houdt ervan fouten toe te geven, maar als we het wel deden, hoefde niet iedereen steeds dezelfde fouten te maken.
Er zijn twee barrières die zelfhulp in de IT in de weg staan. Aan de ene kant willen managers absoluut geen negatieve publiciteit en hebben zij de autoriteit om informatie uit de openbaarheid te houden. Aan de andere kant is er geen toonaangevend IT-tijdschrift; er zijn wel weekbladen en gratis tijdschriften, maar die krijgen hun geld van de adverteerders, en die zitten niet te wachten op negatieve publiciteit.

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Lees verder


Stuur dit artikel door

Uw naam ontbreekt
Uw e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
article 1999-09-24T00:00:00.000Z Martin Healey
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.