Als de datum verandert van 31 december 1999 in 1 januari 2000, zullen veel berekeningen mislukken en zelfs hele systemen uit de lucht gaan. Toch doen maar weinig organisaties actief iets aan dit probleem. Specialist in het management van technologische veranderingen Peter de Jager geeft zijn visie op het ‘2000
-probleem’.
Ik ben een idealist. Dat is zowel een zwak als een sterk punt. Ik houd van precisie – geen optimale precisie, maar een dodelijke accuratesse. Ik houd niet van dubbelzinnigheid, en ook niet van onnodige risico’s – vooral niet van gevaren met onbekende en overwegend negatieve gevolgen. Is het gek dat ik geobsedeerd ben door het 2000-probleem?
Even recapituleren: de meeste applicaties slaan jaartallen op in de vorm van twee cijfers. Onze systemen gaan ervan uit dat deze twee cijfers (zeg 3 en 4) voorafgegaan worden door de cijfers 1 en 9 (dus 1934). Als het jaartal in 2000 op 00 springt, zullen de meeste applicaties denken dat 1900 bedoeld wordt. Storingen en verkeerde rapporten zullen het resultaat zijn.
Op basis van gesprekken met honderden bedrijven, consultants en leveranciers ben ik tot de conclusie gekomen dat wereldwijd minder dan 20 procent van alle ondernemingen zich actief met dit probleem bezighoudt. Bovendien bevinden de meeste daarvan zich pas in de eerste planningsfase.
Voor een beetje programmeur is het triviaal om het 2000-probleem op te lossen: breidt het jaartal uit met twee cijfers of het datum-veld met een eeuw-bitje, of maak gebruik van datum-routines. Programmeurs moeten er ook rekening mee houden dat 2000 een schrikkeljaar is. Anders weten de applicaties na 28 februari 2000 niet meer welke dag van de week het is.
‘Digitale Cassandra’
Veel bedrijven hebben echter meer dan vijftig miljoen regels code waar het datum-probleem in kan zitten, en het aantal dagen tot de keiharde deadline neemt gestaag af. Stel dat het één seconde duurt om een verandering in een regel code aan te brengen, te testen en in te voeren, en neem aan dat u acht uur per dag, vijf dagen per week en vijftig weken per jaar bezig bent; dan komt u met vijftig miljoen regels code uit op ongeveer zeven jaar werk. (Toegegeven, dit is een wat vreemde manier om de omvang van een project te schatten, maar het vormt tenminste een begin.)
Wat doet u eerst? Welke systeemafhankelijkheden zijn er? Wanneer is de software van de leverancier klaar om met uw gemodificeerde systemen te werken? Hoe veranderen de leveranciers hun software? Kunt u al beginnen voor zij klaar zijn? Op het gebied van projectmanagement is dit de grootste uitdaging aller tijden, en u moet het strakker in de hand houden dan ooit, want de deadline valt niet op te schuiven.
Mijn obsessie heeft me al verschillende bijnamen opgeleverd, onder andere ‘digitale Cassandra’, ‘millennium-mopperaar’ en ‘doemdenker’. Sommige mensen vermoorden de boodschapper; zo is het leven.
Het probleem is evenwel échter dan écht. Kathy Benson, projectmanager bij IBM, zegt het simpel: "Het is essentieel dat klanten al hun software, besturingssystemen en applicaties opwaarderen tot de meest recente versie. Zo niet, dan kunnen ze na 1 januari 2000 grote problemen ondervinden."
Het datum-probleem treft niet alleen mainframes. Probeer het volgende maar eens op uw PC. Stap 1: zet de datum en tijd op 31 december 1999, 23:57. Stap 2: zet de PC uit. Stap 3: wacht vijf minuten. Stap 4: zet de PC weer aan. Stap 5: controleer de datum. Is het 4 januari 1980? Tien tegen één dat het niet 1 januari 2000 is.
Tenzij u het probleem oplost, zal uw PC op 1 januari 2000 zo goed als onbruikbaar zijn. Hetzelfde geldt voor alle applicaties: op 1 januari 2000 zijn ze zo goed als onbruikbaar – tenzij u iets aan het probleem doet.
Bedrijfsrisico’s
Het probleem met de meeste systemen is dat we niet weten hoe, wanneer en of ze in 2000 defect raken. U kunt het zich echter niet veroorloven om het niet te weten. Is het risico dat u niet meer kunt factureren voor u aanvaardbaar?
Twee ontbrekende cijfers hebben gevolgen die verder strekken dan de techniek. Ondanks het feit dat dit probleem zijn oorsprong vindt in de bits en de bytes van organisaties, is en blijft het een bedrijfsrisico. De programmeur weet dat de code kan falen. De analist weet dat de programma’s kunnen falen. De manager weet dat de toepassingen kunnen falen, en wat dat voor de organisatie betekent. Wel weten, maar niet handelen – dat staat gelijk aan grove nalatigheid.
Als automatiseringsprofessional heeft u meer dan de gewone verantwoordelijkheid om het management in te lichten. Als automatiseringsprofessional heeft u de morele plicht om het management van de ernst van het probleem te overtuigen, zodat het er iets aan kan doen.
Bedrijfsrisico’s wortelen in de technische fundamenten van de organisatie. U, automatiseerder, heeft die fundamenten gebouwd. U begrijpt hoe complexe systemen kunnen falen door ontbrekende of defecte componenten. U begrijpt de waarheid achter de gedachte dat het koninkrijk verloren ging omdat het paard een hoefijzer verloor.
Eerste plan van aanpak
De organisaties die zich bezighouden met het 2000-probleem, wereldwijd 20 procent van alle ondernemingen, hebben ook nog geen oplossing voor alle problemen die zouden kunnen optreden. De meeste van deze pioniers bevinden zich pas in het vroegste planningsstadium. Ze maken hun medewerkers bewust van het probleem, onderzoeken welke systemen erdoor getroffen worden en stellen een eerste plan van aanpak op. Slechts weinig organisaties sleutelen al daadwerkelijk aan hun code.
Eén van die pioniers is de Amerikaanse belastingdienst (Internal Revenue Service, IRS). "Dit probleem kunnen we niet oplossen door te vertrouwen op bovenmenselijke krachten. Het is te groot. Planning is nodig", zegt Julia McCreary, re-engineering manager bij de IRS te Washington. De belastingdienst hikt aan tegen 6500 applicaties die in verband met het datumprobleem moeten worden aangepast. Wat gebeurt er als de IRS het probleem niet oplost? McCreary’s antwoord is vastbesloten: "Wij tellen elke cent aan inkomsten in de Verenigde Staten, dus we kunnen het ons niet veroorloven om het probleem niet op te lossen."
De Amerikaanse Sociale Dienst (Social Security Administration, SSA) te Washington heeft dezelfde houding – niet oplossen kan niet. "We begonnen met het project in het kader van onze reguliere onderhoudsactiviteiten in 1989, toen we een datum-gerelateerde fout in onze debiteurenadministratie vonden", vertelt Judy Draper, hoofd softwaretechnologie en projectmanager voor het jaar 2000. "Deze software keek tien jaar vooruit, en liep mis toen de datum op 1999 sprong. Of liever gezegd: op 99." Sinds die tijd zijn datumveranderingen onderdeel van het reguliere onderhoudswerk, aldus Draper.
Als haar wordt gevraagd wat de mogelijke risico’s zijn, komt ze met de volgende cijfers: "De SSA drukt per maand ongeveer 45 miljoen cheques af. Er stroomt jaarlijks dus zo’n 300 tot 400 miljard dollar in de economie. Niet oplossen kan niet."
De urgentie van het probleem wordt versterkt doordat de SSA niet geïsoleerd werkt. "Onze gegevens gaan overal naar toe", zegt Chris Murphy, computerspecialist bij SSA. "Zelfs als al onze programma’s gerepareerd worden, krijgen we gegevens van andere diensten, zoals de Veterans Administration en het Treasury Department. Onze systemen zijn pas ‘gerepareerd’ als ze werken, en ze doen het niet voordat alle koppelingen werken."
Complete code-conversie
GTE in Rockville is ook bezig met het 2000-probleem. De IT-managers Joel Cohen en Gerry Roth dragen samen de verantwoordelijkheid voor het project ‘Millennium date conversion’ bij GTE. "We schieten flink op met Millennium 2000; we werken systematisch en met een consistente methodologie om wijzigingen door te voeren en te testen, en om te controleren of binnen het hele bedrijf aan de eeuw-norm wordt voldaan", zegt Roth.
Ze geloven dat ondersteuning en planning vanuit het management voorwaarden zijn om de risico’s tot nul te beperken. Daarom publiceerde GTE op 16 augustus vorig jaar een beleidsplan waarin stond dat alle GTE-locaties op 1 april 1996 een goed gedefinieerd conversieplan in werking moeten hebben. Volgens dat plan moeten alle programmatuur en operationele wijzigingen voor 31 december 1998 gereed zijn.
Roth vertelt dat GTE zich eind 1993 zorgen over het probleem begon te maken. In dat jaar brachten technische medewerkers enkele datum-gerelateerde problemen onder hun aandacht. In 1994 stuurden ze een brandbrief rond met details over de aard, de reikwijdte, de mogelijke impact en de oplossingen voor het probleem. "Dit was het begin van een bedrijfsbreed bewustzijns-programma", aldus Roth. "We erkennen dat het risico bestaat. We gaan er iets aan doen, door beleid te definiëren en de kwestie aan te pakken voordat het echt zover is", aldus Cohen.
Toen Stuart Guthrie, 2000-manager bij Northern Telecom, vijftien interne systemen, bestaande uit miljoenen regels code, onderzocht, vond hij in elk systeem een 2000-probleem. Ook deze onderneming onderkent de risico’s van de datumverandering in het jaar 2000. Het team van Guthrie is van plan om in september 1998 een complete code-conversie te voltooien. "Met een goede planning en strak management kunnen we de conversiekosten met 75 procent terugdringen", verwacht hij.
Alternatieve onderzoeken
Texaco is zich in maart 1995 met de 2000-problematiek gaan bezighouden. "We vonden het tijd worden om onze systemen te onderzoeken, zodat we zicht zouden krijgen op de risico’s", zegt Carl Roecker, senior technoloog bij het in Houston gevestigde bedrijf. Texaco startte een onderzoek, en de resultaten waren opzienbarend: 65 procent van alle software – driehonderd applicaties – bleek gevoelig te zijn voor de datumverandering in 2000.
"Het management wil weten hoe groot de klus is. Ze willen weten hoeveel het gaat kosten om het probleem op te lossen – en ze verwachten dat het opgelost wordt", vertelt Roecker.
Shell pakt het 2000-probleem systematisch aan. Het bedrijf heeft naar schatting 70.000 programma’s en meer dan 100 miljoen regels code, aldus Ron Quiggins, manager bij Shell Services te Houston. Zijn strategie bestaat uit het onderzoeken van alternatieven. "We hebben een flinke representatieve applicatie gekozen, waar we drie pilots mee gaan uitvoeren", zegt Quiggins. Hij is van plan om eerst ervaringen met produkten en leveranciers op te doen, en dan een keuze te maken.
John Burns, vice president en 2000-manager bij de Canadian Imperial Bank of Commerce (Cibc) te Toronto, had gehoord dat de software van automatische bankkluizen niet tegen de datumovergang zou kunnen. "Ik heb geverifieerd dat onze kluizen geen probleem met het jaar 2000 hebben. Ze werken op uur- en niet op kalenderbasis", aldus Burns.
Op de vraag of dreigen met defecte kluisdeuren niet als paniekzaaien wordt gezien, antwoordt hij: "Integendeel. In het kader van mijn ‘bewustzijnslezingen’ vraag ik mijn publiek of de kluizen ook het slachtoffer van de datumovergang zullen zijn. Meestal weten ze het niet. Mijn antwoord op hun stilzwijgen is: ‘nu ik de vraag gesteld heb, kunnen we het ons niet veroorloven om er niet naar te kijken’. Als we ernaar gekeken hebben en het antwoord weten, kunnen we een plan van aanpak maken."
Gebrek aan automatiseerders
De bankkluizen mogen dan geen last van het jaar 2000 hebben, dat geldt niet voor de andere programma’s. Carolyn Swadron, hoofd van het 2000-project bij Cibc, ziet zich geconfronteerd met de vragen ‘hoe groot’ en ‘hoeveel’. Ze schat dat Cibc meer dan tweehonderd applicaties heeft, die meer dan 50 miljoen regels code bevatten. "Het is een grove schatting, gebaseerd op de belangrijkste systemen", geeft ze toe. Het bedrijf werkt aan een impact-analyse, om alle systemen af te dekken.
Geen van de organisaties in dit artikel beweert dat de getallen die ze noemen om de omvang van het conversieproject aan te geven meer zijn dan ruwe schattingen, ‘guesstimates’. Dat is een deel van het probleem. Swadron: "We moeten weten wat de omvang is, welke stukjes samen gerepareerd moeten worden, omdat je een systeem nu eenmaal niet voor de helft kunt herstellen."
De definitie van ‘een systeem’ is moeilijk op te stellen, omdat er veel interne en externe koppelingen zijn. "We zijn gekoppeld aan alle financiële netwerken", aldus Burns. "Onze systemen moeten samenwerken met andere financiële instellingen en industriële organisaties – zowel nationaal als internationaal."
Een andere bron van zorgen voor Cibc is het vinden van personeel om alle reparaties af te handelen. "In 1997 en 1998 zullen de meeste automatiseringsafdelingen zich opeens realiseren dat ze hun personeelsformatie twee jaar lang met zo’n 30 procent moeten uitbreiden om het 2000-project te voltooien", meent Burns. "Zelfs als we maar 10 of 15 procent meer specialisten nodig hebben, zal de vraag naar personeel het aanbod overstijgen." Burns voorziet een gebrek aan automatiseerders, en heeft het motiveren van zijn huidige personeel – om nog lang bij Cibc in dienst te blijven – dan ook in zijn projectplan opgenomen.
Peter de Jager is gespecialiseerd in het management van technologische veranderingen (e-mail: pdejager@hookup.net).
EEN DURE GRAP
De wereldwijde kosten die gemoeid zijn met de datumovergang in het jaar 2000 bedragen naar verwachting 300 tot 600 miljard dollar. Dit bedrag is inclusief het opsporen, repareren en testen van datumvelden, en exclusief het aanpassen van formulieren zodat het extra datumveld erop past.
De reparatiekosten per regel code bedragen naar schatting 1 dollar. Dit bedrag is exclusief documentatie, opleiding en integratietest.
Bron: Gartner Group.
SIMPEL PROBLEEM, LELIJKE OPLOSSING
Het datumprobleem valt "eenvoudig te begrijpen, maar de oplossing is lelijk", stelt John Phelps, onderzoeksleider bij de Data Center Strategies service van Gartner Group te Atlanta. Zelfs met alle beschikbare tools, zo zegt hij, zullen organisaties nog een heleboel handwerk moeten verrichten.
Programma’s zonder broncode of met hard-gecodeerde datumovergangen zijn bijzonder moeilijk aan te pakken, zo vertelt Bill Goodwin, redacteur en uitgever van de nieuwsbrief ‘Tick tick tick’, die uitsluitend aan het 2000-probleem gewijd is.
Phelps, die vaak een paniekzaaier wordt genoemd, omschrijft het 2000-probleem om drie redenen als een crisis zonder weerga in de IT-industrie. Allereerst is er voor de eerste keer iets dat moet gebeuren, in tegenstelling tot dingen waarvoor men kiest, zoals overgaan op client/server. Ten tweede staat de deadline onverbiddelijk vast. Dit project kan niet zonder ernstige gevolgen zes maanden te laat afgerond worden. Ten derde is er voor het eerst geen zakelijk motief om actie te ondernemen, anders dan overleven.
Organisaties zijn niet erg open over hun 2000-projecten – of het ontbreken daarvan, aldus Phelps. Ze zijn bang dat hun klanten zullen denken dat dit een specifiek probleem in plaats van een algemeen, wat het vertrouwen zou kunnen schaden. "Ik zie het tijdig oplossen van het 2000-probleem en de bijbehorende publiciteit juist als een concurrentievoordeel", zegt hij.
2000-CONVERSIE IN 10 STAPPEN
1. Overtuig uzelf ervan dat al uw SOFTWARELEVERANCIERS het 2000-probleem aanpakken.
2. Definieer een WIJZIGINGSPROCEDURE, zodat u zeker weet dat elke verandering geldig is.
3. Maak een INVENTARISATIE van alle interne programma’s en bestanden.
4. RUIM OP, dat wil zeggen: gooi overbodige en verouderde programma’s eruit.
5. Voer een IMPACTANALYSE uit: onderzoek welke programma’s kritische datumproblemen hebben, zoals degene waarbij het datum-veld voor vergelijkingen of berekeningen wordt gebruikt. Niet-kritische datumproblemen, zoals de datum die op een rapport staat vermeld, zijn misschien kosmetisch op te lossen. Tel alle aan te passen programma’s en referenties op om de omvang van het project te kunnen schatten, zodat u weet hoeveel mensen hoe lang nodig zijn om het uit te voeren.
6. Definieer projectfasen en PRIORITEITEN.
7. IDENTIFICEER velden en bestanden die gewijzigd moeten worden.
8. WIJZIG de in stap zeven geïdentificeerde velden en bestanden.
9. Voer TESTEN uit; dit is waarschijnlijk de omvangrijkste en meest tijdrovende fase van het project.
10. Laat niet de kans voorbij gaan om alles wat u doet te DOCUMENTEREN. Deze informatie is een waardevolle bron voor het nemen van beslissingen, bijvoorbeeld als u ooit moet downsizen.
Bron: Bill Goodwin, redacteur en uitgever van de jaar-2000 nieuwsbrief ‘Tick tick tick’.
MEER INFORMATIE
ONLINE
The Year 2000 homepage op Internet (http://www.year-2000.com/)
Deze site bevat artikelen, verwijzingen naar andere bronnen, speciale serviceproviders, frequent gestelde vragen, hulpmiddelen om het bewustzijn in de organisatie te verhogen en zelfs een beetje humor.
The Year 2000 mailing list
Deze discussielijst behandelt alle aspecten van het 2000-probleem, van voorbeelden in C++ tot management-kwesties. Hij bevat tevens informatie over conferenties en seminars. Stuur "subscribe year2000" naar listmanager@hookup.net.
IN DRUK
‘Tick tick tick’ nieuwsbrief
Verkrijgbaar via:
2000AD Inc.
PO Box 020538
Brooklyn, NY
11202-0012
(800) 643-8425
