Computable meldt dat de fout, voor zover bij CZ bekend, niet bij de leverancier van de software lag maar bij CZ zelf:
Volgens een woordvoerder van CZ heeft de leverancier van de software hier echter geen schuld aan, voor zover nu bekend is. ‘De blaam treft ons zelf,’ zegt hij...
Volgens een woordvoerder is het destijds misgegaan bij de implementatie van nieuwe software. Voor zover nu valt na te gaan betreft dit niet de software zoals de leverancier die leverde. ‘Er komt van alles bij kijken,’ verduidelijkt hij.
https://www.computable.nl/2024/02/06/softwarefout-geeft-cz-kiespijn/Het lijkt erop dat men een pakket heeft aangeschaft waarin men de eigen verwerkingen en regels heeft moeten configureren.
Vroeger, als ontwikkelaar werkend in een mainframe-omgeving voordat we Windows of Internet hadden, waar we nog volledig onze eigen software ontwikkelden, wisten we dat informatiesystemen onvermijdelijk verouderden en vervuilden, dat het ontwerp op een gegeven moment niet meer bij de huidige eisen paste. Om legacy-problemen te voorkomen was, waar ik werkte, het uitgangspunt dat een systeem een bruikbare levensduur van 10-15 jaar heeft en dan door nieuwbouw vervangen moet worden. Om het soort problemen dat CZ nu heeft te voorkomen werd bij zo'n grote vervanging schaduwgedraaid: het nieuwe systeem draaide in een acceptatieomgeving en kreeg daar dezelfde data te verwerken die het oude systeem in productie verwerkte, de uitkomsten werden vergeleken, verschillen onderzocht en als het geen geplande wijzigingen waren maar fouten werden die fouten hersteld in het nieuwe systeem. Voor die schaduwtest alleen al konden meerdere maanden uitgetrokken worden, als ik me goed herinner. Dan nog konden extreem zeldzaam optredende fouten erdoorheen glippen, maar zeker geen fouten die tienduizenden keren optraden.
Ik heb in die tijd een keer een presentatie bijgewoond van een buitenlandse (ik dacht Canadese) verzekeringsmaatschappij die voor toen een erg degelijke testmethodiek had. Een belangrijk onderdeel daarvan was een acceptatietestomgeving waarin elke maand een qua volume gereduceerde maar qua situaties (na een opbouwperiode) zeer complete jaarverwerking draaide. Elke change die niet diende om een storing te verhelpen mocht niet in productie zonder een volle maand foutloos in die omgeving gedraaid te hebben.
Dat soort werkwijzen hadden deze fout bij CZ aan het licht gebracht voordat die in productie ging. Wie weet heeft men daar, door de traditionele automatisering de deur uit te doen, ook het besef de deur uitgegooid dat je bij zo'n ingrijpende wijziging ook nauwgezet moet controleren of alles wel naar behoren werkt, inclusief wat voor zo'n controle nodig is.
In dat licht zouden ze het onterecht uitgekeerde geld niet terug moeten vorderen maar het als de prijs van hun eigen geblunder moeten accepteren.
Ik heb natuurlijk de gedachte daarbij gehad dat de kosten daarvan niet ten nadele van de verzekerden maar van de aandeelhouders moeten komen. Ik zie alleen dat CZ een niet op winst gerichte onderlinge waarborgmaatschappij is waar de verzekerden de leden van zijn. Deze gedachte over aandeelhouders gaat dus niet op, want die zijn er niet.