Het jaar 2000-probleem is vrij ongecompliceerd, hoewel de grootte van het onderwerp de overzichtelijkheid van de gevolgen belemmert.
De perikelen zijn veroorzaakt door programmeurs die de afgelopen vijftig jaar twee, in plaats van vier posities hebben gebruikt om een jaar te definiëren (97 in plaats van 1997). Het resultaat is dat de programmatuur niet of niet goed meer zal werken op 1 januari 2000. Maar dat betekent niet dat het jaar 2000 louter een programmeursprobleem is!
Toch lijkt dat er veel op, als we zien dat momenteel slechts een zeer klein gedeelte van de Nederlandse ondernemingen – en ook de overheid – zich bezighouden met het jaar 2000-probleem. Dit is alarmerend, omdat de oplossing ervan arbeidsintensief is en het management daarvoor veel middelen moet vrijmaken.
Als we ervan uitgaan dat een project bestaat uit een inventarisatie, analyse, conversie, testen en migreren, dan is het jaar 2000-probleem voor bijna dertig procent op te lossen met behulp van ‘bug fix tools’. De resterende ruim zeventig procent zullen via grote investeringen en met inschakeling van menskracht moeten worden opgelost. Deze percentages zijn weliswaar relatief, maar alles wordt een stuk concreter voor het management als we beseffen dat het voor een middelgroot bedrijf om een gemiddelde investering gaat van acht miljoen gulden en dat ‘human resources’ in de IT schaars zijn.
Een datum is zeer belangrijk voor computers. De meeste data in computers zijn gebaseerd op een veld bestaande uit twee posities. De redenen voor het gebruik van twee posities in plaats van vier is terug te voeren op de hoge kosten van opslag en de technische limieten in de vroege dagen van automatisering.
Het spreekt voor zich dat een fout in een computersysteem tot allerlei ongemakken kan leiden. Ervan uitgaande dat een computersysteem het primaire proces van een onderneming ‘minimaal’ ondersteunt en bij grotere organisaties bestuurt, maakt het noodzakelijk om problemen vóór te zijn om de continuïteit van deze organisaties te waarborgen.
Drie mogelijkheden
Bij het jaar 2000-probleem gaat het onder meer om betalingsproblemen bij salaris en sociale uitkeringen; personeels- , voorraad- en studiebestanden die niet meer functioneren; financiële en bancaire zaken die in het honderd lopen; wapensystemen en gerechtelijke procedures die niet meer deugen en rekeningen die niet meer worden betaald.
Deze ‘bug’ heeft onder andere effecten op het berekenen van leeftijd, sorteren op datum en het vergelijken van data. De Gartner Groep heeft berekend dat het oplossen van de drie voorgaande problemen ongeveer vijfhonderd dollar kost per computerprogramma. Voor een middelgroot bedrijf komt dat neer op drieënhalf tot ruim vier miljoen voor een software conversie.
Anderson Consulting denkt dat een middelgroot bedrijf twaalfduizend werkdagen nodig zal hebben om de problemen op te lossen, Yellow Corporation is met tienduizend werkdagen wat optimistischer.
De ‘bug’ kan worden gevonden in mainframe, midrange en PC- omgevingen, de twee positie datavelden in microcode, operating systems, software compilers, applicaties, queries, procedures, schermen, data bases en data.
Het management kan op grond van dit alles uit drie mogelijkheden kiezen. Het kan het probleem negeren en hopen dat het vanzelf overgaat. Een actievere variant is de veranderingen tot de laatste minuut uitstellen en ten slotte kan het er ook de voorkeur aan geven om nu actie te ondernemen.
Stappenplan
Valt de keuze op laatstgenoemde mogelijkheid, dan ligt een stappenplan voor de hand. Dit omvat de volgende onderdelen: inventariseren; project definiëren; analyseren; examineren; selecteren; modificeren en documenteren.
Een inventarisatie van alle computersystemen uitvoeren omvat de ontwikkeltalen, de verspreiding van de applicaties over de business functies en de technische omgeving.
De project-definitie die het jaar 2000-probleem moet helpen oplossen dient de volgende prioriteiten te bevatten: business doelen; kritische systemen en een tijdpad voor conversie per item.
Vervolgens dient een analyse plaats te vinden van de ‘data flow’ in een programma en tussen de programma’s aan de hand van de inventarisatie met als doel operaties als edit, create, read, update, delete per data-element te verduidelijken.
Aan de hand van de drie voorgaande stappen dient een examinering te geschieden van de verschillende opties om de jaar 2000-bug op te lossen. Hieronder vallen ‘bug fix software’, dataveld uitbreiding,modernisering van applicaties en vervanging van het systeem.
Vervolgens moet het selecteren van oplossingen per systeem plaatsvinden, gevolgd door modificering. Dit laatste heeft betrekking op nieuwe gemodificeerde applicatie/systemen; een nieuwe integratie tussen de applicaties/systemen en de acceptatie uitvoeren van de testen.
Het laatste onderdeel van het stappenplan, het documenteren, omvat de aanpassing van de documentatie en van de ‘fall back procedures’.
Gregoriaanse tijdrekening
Ten slotte nog dit. Is 2000 nu een schrikkeljaar of niet? Vele betrokkenen bij de problematiek hebben zich hier het hoofd over gebroken. Op het eerste gezicht is het antwoord voor de hand liggend: 2000 is deelbaar door vier, dus een schrikkeljaar. Maar dat was paus Gregorius XIII in zijn regelgeving uit 1582 wat te simpel. Zijn tweede stelregel luidt: er is geen sprake van een schrikkeljaar, wanneer het jaar deelbaar is door honderd. Dat verandert de zaak: geen 29ste februari in het jaar 2000. Maar nu speelt Gregorius zijn laatste troef uit: er is wel weer sprake van een schrikkeljaar, wanneer het jaar deelbaar is door vierhonderd.
Dus 1900 was geen schrikkeljaar, 2000 wordt een schrikkeljaar en 2100 weer niet.
Omdat er zoveel verwarring is rond de schrikkeljaren gebruiken testprogramma’s de jaarlijkse testwaarden 88, 92 en 96, maar vermijden ze 00. Tevens is het niet verrassend dat sommige programma’s februari 2000 kenmerken als een speciale maand in een schrikkeljaar met 30 dagen in plaats van 29. De consequenties van al deze regels zullen niet te overzien zijn.
Erwin K. Jesterhoudt, Den Haag