Gabriele Giulimondi

Introduzione¹

La misura del tempo è sempre stato per l’umanità un problema complesso. Il tempo di rivoluzione della terra intorno al sole non corrisponde ad un numero esatto di giorni, i cicli mensili della luna e il ciclo annuale del sole non sono esattamente uguali e coincidono solo ogni 19 anni, pertanto i calendari hanno bisogno di periodici aggiustamenti per essere sincronizzati con l’anno solare.

L’orologio atomico² ed il sistema di coordinazione universale del tempo (UTC Coordinated Universal Time)³ mantenuto dall’International Time Bureau⁴ hanno reso il sistema di misurazione del tempo il più accurato di tutti i sistemi di misurazione conosciuti dalla specie umana (un secondo ogni milione di anni) ma i calcoli relativi alle date continuano ad essere problematici anche per i sistemi elettronici.

Con l’avvento dei computer i problemi di data e di calendario hanno improvvisamente assunto nuova rilevanza per le numerose ed importanti attività umane svolte con computer: errori di data possono causare gravi danni e conseguenze incalcolabili.

Sfortunatamente le potenzialità di velocità e prestazioni dei computer e del software non furono pienamente sviluppate fin dalle origini dell’era informatica e per motivi di risparmio, quali gli elevati costi delle memorie⁵ venne riservato uno spazio insufficiente per la completa identificazione della data. I due metodi impiegati: il formato convenzionale di rappresentazione delle date (del tipo giorno-mese-anno) e l’accumulo progressivo del numero di secondi da un punto iniziale arbitrario sono stati adeguati sino ad oggi, ma non lo sono più per il prossimo futuro. Per la ridotta disponibilità di memoria, il campo a quattro cifre degli anni fu ridotto a due e l’accumulazione dei secondi limitata a quattro byte così il primo sistema entrerà in crisi entro la fine del corrente anno 1999, il secondo entro il 18 gennaio del 2038⁶.

Una ulteriore complicazione è dovuta al modo di rappresentazione a stampa delle date che è diverso da paese a paese: negli USA il formato è mese-giorno-anno, mentre in Europa è giorno-mese-anno, sempre con l’anno a due cifre.

Per facilitare gli scambi l’International Organization of Standard⁷ ha fissato uno formato, sostenuto dall’ANSI (American National Standard Institute)⁸ e dal NIST (National Institute of Standard e Technology)⁹ del tipo anno-mese-giorno con l’anno a quattro cifre. È il ben noto ISO standard 8601:1988¹⁰ che tuttavia non è ancora il formato più comunemente usato¹¹ e anch’esso risente di una comune debolezza dettata dallo sforzo inconscio di risparmio.

1. Il problema dell’anno 2000

Chi lavora quotidianamente con il progetto, la costruzione e il funzionamento dei computer è abituato continuamente a dover risolvere problemi nuovi e inattesi. Il problema nel cosiddetto Millennium Bug è così semplice da apparire talmente banale che chiunque è in grado di comprenderne la natura ed escogitare metodi per risoluzione¹². Ancora più semplice è predisporre delle verifiche: basta spostare in avanti le date, inserire dei dati e vedere i risultati.

Eppure oltre l’80% dei responsabili Edp delle aziende dichiara che il problema non solo non è risolto, ma che in oltre il 50% dei casi non si arriverà in tempo nonostante la disponibilità di strumenti tecnici specifici per analizzare e risolvere il problema e di consulenti esperti. Tutto ciò non basta, non c’è abbastanza tempo. Infatti non basta scovare tutte le date e convertirle, occorre modificare le maschere di immissione dati, le colonne di output a video e a stampa e quanto a ciò correlato.

Il Millennium Bug, o Problema dell’Anno 2000 come è conosciuto, si riferisce all’incapacità di taluni sistemi elettronici di lavorare e gestire correttamente date posteriori all’anno 2000, ma molti dei problemi connessi al cambio di data verranno alla luce (ed alcuni hanno già fatto la loro apparizione) molto prima dell’inizio del nuovo millennio¹³.

La serietà del problema non riguarda tanto il settore dell Information Technology ma piuttosto quello dell’industria, del commercio, dei servizi sociali e delle istituzioni, persino - paradossalmente - di chi non usa il computer. Un’organizzazione incapace di gestire efficacemente la produzione, gli ordini, le consegne, i pagamenti e i propri servizi nei tempi e nei modi necessari, subisce un grave danno, non solo economico, che poi ricade sulla società civile. Il cambio di millennio è un fatto tecnico con risvolti operativi che comportano un rischio per il business.

Il problema dell’Anno 2000 affonda le sue radici negli anni ‘60 quando i computer erano poco diffusi, le memorie erano assai limitate e costose e i programmatori dovevano confrontarsi con le ridotte risorse disponibili. La soluzione più ovvia per rappresentare la data (che nell’elaborazione dati aveva minore rilevanza che non oggi) fu, appunto, quella di usare solo due cifre per l’anno anziché quattro¹⁴. Ne segue che al cambio di secolo, i computer così programmati potranno non essere in grado di interpretare correttamente l’anno 2000¹⁵;

Il problema è grave specialmente per quelle applicazioni strettamente connesse con la precisione della data; il problema è globale perché riguarda potenzialmente ogni sistema basato su computer di ogni paese, cioè interessa tutta l’informatica e tutta l’azienda; infine esso è privo di una soluzione universale.

Il motivo di fondo, tanto elementare quanto incompreso fino ad ora, è che la data è presente nei processi di elaborazione dei sistemi informatici come una classe di informazioni molto più diffusa di quanto non si possa immaginare e che essa viene trattata alla stessa stregua di tutti gli altri tipi di informazione: le date si confrontano, si ordinano, sono operandi aritmetici, sono comunemente presenti nei codici identificativi dei prodotti, sono parametri di input/output. Pertanto la rappresentazione abbreviata dell’anno con le sole ultime due cifre non consente di eseguire correttamente operazioni di ordinamento, confronto e calcolo di intervalli temporali.

La risoluzione di questo problema è poi complicata da una serie di circostanze: la mancanza di conoscenza esatta dei punti di intervento per le intricate interazioni logiche tra dati e istruzioni, l’eterogeneità dei sistemi, la quantità ingente di interventi, la necessità, dopo gli interventi, di sottoporre l’intero sistema a vari livelli di test, le diverse implicazioni organizzative ed economiche connesse a tali operazioni.

Inoltre nel problema dell’anno 2000 sono coinvolti diversi livelli tecnologici, quali i sistemi informativi tradizionali basati su mainframe e terminali, tutti i personal computer così eterogenei per l’hardware, il software di base e applicativo, per le diverse finalità di utilizzo, l’elevato numero, la varia collocazione fisica e configurazione. Ad essi vanno aggiunti i cosiddetti sistemi embedded¹⁶ (o embedded technology) cioè quella sterminata quantità di microprocessori presenti nella strumentazione tecnica, nell’elettronica di consumo ed in ogni apparecchio civile o industriale (elettromedicali, sistemi di controllo di processo e di produzione, robot, elettrodomestici, automobili, ascensori, distributori automatici, satelliti, centralini telefonici, fax, impianti antifurto e così via). Anch’essi sono dei veri e propri computer che eseguono specifici programmi dei quali, in molti casi, è praticamente impossibile sapere se e come facciano uso di parametri, collegati alla data, che possano risentire in maniera anomala, nello svolgimento dei loro processi, del cambio di secolo¹⁷.

Stime effettuate dagli analisti individuano una quantità di tali sistemi compresa tra 25 e 40 miliardi, i laboratori di PcWeek hanno riscontrato errori sul 5% dei casi, ma i sistemi embedded sono nella quasi totalità dei casi hard-coded¹⁸, precludendo la possibilità di un intervento diretto.

Un aspetto non molto evidenziato, ma di importanza strategica, è che nella società odierna sempre più coinvolta nel processo di globalizzazione, il problema anno 2000 non riguarda isolatamente chi utilizza sistemi informativi. L’interconnessione tra aziende esige un continuo e reciproco scambio di dati (effettuato per via telematica, o con mezzi più tradizionali come dischi, nastri) che richiede una comune modalità di gestione delle date e una coerente risoluzione del problema. Il problema anno 2000 è sistemico: un computer che diffonde dati errati o non coerenti può indurre anomalie in altri computer, seppur correttamente configurati, ad esso connessi con effetto "domino" a meno di isolare ogni computer "non 2000 compatibile", il che non è possibile. Il problema ha grande rilevanza a livello economico e sociale prima ancora di essere un problema tecnico, perché nessuno vive isolato dal resto del mondo e tutti noi abbiamo a che fare continuamente con strutture fortemente dipendenti dai computer. Paradossalmente, anche chi non utilizza direttamente i computer potrebbe essere coinvolto pesantemente in questo problema.

Il problema dell’Anno 2000 non è solo una questione tecnica, ma un problema economico di rilevanza internazionale e di potenziale gravissimo impatto a livello mondiale. Il cambio di data all’anno 2000 presenta un concreto rischio di recessione economica di proporzioni pericolose, per le potenziali anomalie o interruzioni nei sistemi di pagamento, di capitalizzazione, di calcolo finanziario, insomma il tessuto sociale ed economico a livello mondiale è ormai tutto computer-dipendente.

2. Sistemi Critici

I malfunzionamenti dei sistemi informativi relativi all’anno 2000 possono provocare disservizi nei cosiddetti sistemi critici che regolano la società civile. Essi sono: il sistema bancario e finanziario, le assicurazioni, i trasporti, l’energia, i servizi postali, i servizi di telecomunicazioni, la diffusione dell’informazione radio e televisiva, la sanità, la distribuzione delle merci, i sistemi automatici di produzione, i sistemi di controllo, la pubblica amministrazione. Secondo uno studio del governo inglese, i sistemi critici che regolano il funzionamento di un paese industrializzato, sono a loro volta costituiti da circa 60 processi di lavoro critici singoli tra loro interconnessi: tra questi alcuni sono essenziali perché condizionano tutti gli altri e ad essi va dedicato il massimo sforzo di adeguamento. Essi sono: l’approvvigionamento, la fornitura e distribuzione dell’elettricità (condizionano altri 56 processi), le telecomunicazioni (condizionano altri 48 processi), l’approvvigionamento e distribuzione di carburanti (condizionano altri 45 processi critici), la fornitura dei servizi e delle infrastrutture autostradali (condiziona 43 ulteriori processi critici), il sistema dei pagamenti e i mercati finanziari (condizionano 31 ulteriori processi critici), la fornitura di acqua potabile o per uso industriale (condiziona altri 26 processi critici).

Le aziende devono anche predisporre un piano di emergenza (contingency plain) teso ad assicurare comunque (in caso non si riesca a conseguire le necessarie conformità nei tempi stabiliti) la continuità di esercizio, cioè delle operazioni fondamentali alla sopravvivenza e allo sviluppo. Tale piano di emergenza si compone di più fasi: elaborazione del progetto teso ad assicurare la continuità delle operazioni (fase di inizializzazione); analisi dell’impatto sul servizio e sul business dei malfunzionamenti o del blocco totale dei sistemi critici relativi ai processi fondamentali, con analisi del rischio; pianificazione delle procedure di emergenza con i modi di sviluppo concreto, con le responsabilità di attivazione; verifiche e collaudi della strategia definita nella prima fase, sviluppo delle procedure di emergenza e dei piani di ripristino che si devono attuare in caso di disastro.

3. Implicazioni di Ordine Legale

Un problema tecnico come quello dell’anno 2000 presenta anche notevoli implicazioni di ordine legale non appena danneggia l’interesse degli azionisti di una società o mette a repentaglio la sicurezza delle persone. Potranno insorgere cause per danni intentate dalle aziende contro i propri dirigenti, che non hanno saputo affrontare (e risolvere) tempestivamente il problema; basti pensare al software di controllo della produzione, al software di controllo dei processi che possono essere interrotti aumentando i costi e riducendo i profitti; ai sistemi di pagamento e fatturazione che danneggiano i clienti e bloccano il flusso di cassa¹⁹ (cash flow); ai sistemi controllo delle strumentazioni mediche²⁰, degli aerei, a servizi essenziali come centrali elettriche e sistemi telefonici con potenziali a persone. Dato che tutta l’attività economica dipende dall’elettricità e dal telefono questa è chiaramente tra le più importanti aree a rischio La probabilità stimata che ciò accada è ben del 50%, mentre c’è una probabilità dell’85% che applicazioni non trattate possano causare abbastanza danni da provocare cause legali²¹.

4. Le Indagini di Settore

Le recenti indagini e rilevazioni effettuate da università e società di ricerche di mercato evidenziano una situazione piuttosto seria. Secondo tali statistiche²²(http://www.mediamente.rai.it/home/tv2/mm9899/settimanale/990115/s1_15.htm), un terzo delle aziende mondiali non ha neppure iniziato a prendere in considerazione il problema del Millennium Bug ed il nostro paese, al confronto dei partner europei risulta tra i più arretrati. La maggior parte delle aziende italiane sono a rischio, anche se utilizzano applicativi acquistati da terzi. Una attenta valutazione del rischio e degli interventi da effettuare non è affatto un esercizio facile e sono molto scarse e quindi costose le risorse tecniche capaci di intervenire. Per il ritardo accumulato, tutto ciò è inevitabilmente destinato a peggiorare fortemente nel tempo; occorrerebbe intervenire pesantemente, con priorità assoluta, e con notevole dispendio di mezzi: tutti aspetti questi che, purtroppo, sono tuttora sottovalutati e disattesi.

Secondo Meta Group il costo dell’anno 2000 per il settore pubblico e privato ammonta per l’Italia a 34 miliardi di dollari (cioè 58.000 miliardi di lire); una considerazione abbastanza diffusa e deleteria per non intraprendere nessuna seria azione sull’anno 2000 consiste nel fatto che molti dirigenti pensano che i costi di adeguamento all’anno 2000 saranno maggiori rispetto ai danni potenziali che il problema causerà alle loro aziende.

5. L’itinerario di Conversione e i metodi di Soluzione

L’attività di conversione al 2000 presuppone un processo di lavoro ben strutturato e controllato; ogni organizzazione deve intraprendere una serie di fasi: 1) inventory assessment, cioè la creazione della consapevolezza e l’inventario di tutti gli elaboratori, di tutto il software, di tutti i dispositivi con microprocessori incorporati: questa fase occupa circa il 10% del tempo e il 5% dei costi, può essere automatizzata solo per l’8%²³. 2) Valutazione economica, tecnica e di rischio, scelte fondamentali e creazione dell’ambiente di conversione: revisione di tutti i computer e dei sistemi di rete per verificarne la conformità ed effettuare tutte le sostituzioni necessarie, verifica di tutti i sistemi operativi, dei linguaggi di programmazione, dei database, del software di comunicazione e delle utilities, consultando i relativi fornitori ed effettuando tutti i necessari aggiornamenti²⁴. Questa fase richiede circa il 36% del tempo e il 30% dei costi, gode di un livello massimo di automazione del 60%. 3) Sviluppo del piano di intervento ed implementazione, che deve interessare anche Pc, sistemi embedded e supply chain, cioè la rete di approvvigionamento dove informazioni, ordini, fatture viaggiano sempre più spesso su supporti informatici o reti telematiche. Per tutti i programmi applicativi facenti riferimento ad una gestione non corretta della data, occorre risalire se possibile al fornitore²⁵ o al programmatore che ne ha curato lo sviluppo. Nella impossibilità a ciò si può ricorrere a strumenti software di valutazione e di conversione che possano automatizzare in parte il lavoro, per i quali è comunque richiesto il supporto di personale tecnico specializzato con spese non indifferenti o alla soluzione estrema di sostituire i prodotti con altri alternativi valutando attentamente i tempi²⁶ necessari per la riconversione e per la formazione del personale. Questa fase occupa il 10% del tempo il 30% dei costi e può godere al massimo di un livello di automazione del 50%. 4) Testing, cioè verifica con test singoli e globali della convalida delle applicazioni rese conformi all’anno 2000. Richiede circa il 39% del tempo, il 30% dei costi e può godere di un livello massimo di automazione del 40%. 5) Istallazione e messa in esercizio del sistema informativo così reso 2000 compatibile. Occupa circa il 5% del tempo, il 5% dei costi e può godere di un livello massimo di automazione del 20%.

Lo stesso discorso vale per i rapporti con clienti e distribuzione. Perché il business di un’azienda non subisca pesanti contraccolpi dopo il 31 dicembre 1999, insomma, non basta che il proprio sistema informatico sia Y2K compliant, occorre che lo siano anche quelli dei partner, dei fornitori di servizi, della pubblica amministrazione e di tutti quegli altri enti con cui si ha a che fare.

Non esiste poi solo un problema di Y2K compliance, ma esso genera anche un problema di standard, perché esistono diverse metodologie di conversione all’anno 2000²⁷. È chiaro che tutto ciò coinvolge due aspetti ostili, il tempo ed il costo.

6. La Fase di Testing

Superate queste difficoltà, occorre poi procedere, come si è detto, alla pianificazione delle attività di test²⁸ che vanno a coesistere con le attività informatiche correnti e possono richiedere esigenze di capacità elaborativa aggiuntiva. Questi test vanno articolati in maniera assai attenta, perché la correzione del codice in chiave anno 2000 introdurrà errori in altre parti delle applicazioni²⁹.

Pertanto occorre un test di regressione per verificare che il sistema informatico così aggiornato abbia almeno lo stesso livello³⁰ di funzionalità preesistente (il che si ottiene posizionando la data del sistema al valore attuale con transazioni con date normali). Il test successivo si effettua ancora con data al valore attuale ma con transazioni oltre il 1-1-2000, quindi si passa al test della transizione 1999-2000, test particolarmente delicato perché il cambiamento della data di un sistema informativo centrale può avere conseguenze disastrose se effettuato in modo errato; quindi backup di tutti i dati, conoscenza approfondita del sistema operativo e delle applicazioni. Poi il test di operazioni con data nel 2000 e transazioni antecedenti e successive. Ogni test va effettuato per operazioni giornaliere, chiusure mensili, trimestrali etc. Infine occorre il test dell’anno 2000 come bisestile.

Come è evidente, sono test che richiedono molto tempo e la disponibilità degli apparati normalmente usati per le operazioni correnti, quindi sono da compiersi per lo più fuori del comune orario di lavoro; in molti casi richiedono la presenza degli utenti finali, i soli a conoscere bene come funzionano le procedure e in grado di giudicare e definire eventuali errori e modifiche da apportare.

Nel caso dei Personal Computer, la enorme eterogeneità dei sistemi rende più confusa la situazione. Il primo test da effettuarsi riguarda la funzionalità del BIOS e dell’RTC, (vedi app. A) poi si deve passare al test del sistema operativo e soprattutto delle applicazioni. Nel caso del sistema operativo più diffuso, Windows 95 (o 98). la stessa Microsoft riferisce di piccole imperfezioni³¹ che difficilmente possono rappresentare un problema funzionale per gli utenti e che sono in via di risoluzione con apposite patch software; ma la messa a punto della suite Office richiede l’istallazione di patch per Word, Excel e Access, con circa un’ora di lavoro che moltiplicata, ad esempio, per 10.000 PC richiede circa 6 anni-uomo. Quindi la verifica sia degli applicativi di Office sia di Windows 98³² sta rappresentando per diverse aziende un costo crescente finora sottovalutato, mentre emergono nuovi problemi potenzialmente dannosi anche nei controlli di compatibilità su Windows NT 4.0³³.

Certamente il settore "embedded" è quello più enigmatico, tanto da poter essere estremamente grave per alcune organizzazioni e del tutto trascurabile per altre. Nel 1997 sono stati venduti oltre 12 miliardi di microprocessori (più del doppio dell’anno precedente) utilizzati praticamente ovunque: dagli orologi ai sistemi di controllo dei processi ad alta tecnologia. Qualsiasi componente di un dispositivo che ha a che fare con la data (cioè mantiene una data o dipende dalla data per compiere delle operazioni) è soggetto al rischio dell’anno 2000. Tuttavia se la programmazione del microprocessore è stata eseguita correttamente il problema non sussiste, ed è qui l’aspetto più inquietante: non si sa. L’utilizzatore, e spesso anche il produttore che ha assemblato l’apparecchio, non sa niente di ciò: la programmazione è completamente invisibile all’utilizzatore. Per avere informazioni al riguardo non resta che risalire al fornitore originario, operazione assai difficile, oppure eseguire dei complessi test, lavoro altrettanto complesso e costoso.

Come si è esposto, il problema dell’anno 2000 è di natura pervasiva; esso influenza la maggior parte delle organizzazioni che sono obbligate ad effettuare modifiche ai loro sistemi o ai loro processi; queste modifiche, a loro volta, potranno influenzare i partner commerciali, come i clienti e i fornitori e così via. Quindi un aspetto che va curato con particolare attenzione è quello relativo allo scambio di dati che, effettuato attraverso le reti telematiche o con il trasporto fisico di supporti comporta la convergenza di diversi algoritmi (una comune definizione del formato delle date rese conformi all’anno 2000, l’utilizzo di un comune sistema di codifica e conversione, la sincronizzazione temporale del passaggio ai nuovi standard, la verifica della funzionalità delle nuove modalità operative). Occorre così verificare con i partner commerciali il grado di compatibilità all’anno 2000 e la coerenza della transizione verso la conformità dei sistemi per consentire uno scambio di dati senza interruzioni, perché anche utilizzando computer e programmi anno 2000 compatibili è possibile introdurre errori con un trattamento³⁴ non coerente delle date come numeri, in tal caso ogni documento prodotto (fogli di calcolo, database contenenti date etc.) deve essere verificato.

IL NETWORK YEAR 2000

La maggior parte delle preoccupazioni sugli effetti del cambio di millennio sono concentrate sull’invecchiamento delle applicazioni (scritte principalmente in Cobol) mentre si è prestata poca attenzione ai problemi delle reti.

Il N2K (Network Year 2000) riguarda tutti i dispositivi di rete, quali hub, switch, router, server e Pc che interpretano codici correlati a informazioni sulla data. Questi utilizzano normalmente le informazioni sulla data contenuti negli agenti di gestione e monitoraggio istallati al loro interno. Le applicazioni di gestione utilizzano le stesse informazioni per effettuare le analisi delle prestazioni delle reti e stabilire le correlazioni tra gli eventi. Attraverso hub e router queste informazioni vengono elaborate e registrate in centinaia di dispositivi interconnessi. Tutti i dispositivi possono essere interessati dal N2K, dai desktop alle dorsali di rete. Router e switch sono dipendenti dai sistemi operativi, come i Pc e i Server i cui Bios possono presentare problemi di compatibilità. Secondo Bell Atlantic Network Integration, uno dei maggiori system integrator mondiali, più di 800 tipi di dispositivi di rete sono vulnerabili e presenteranno problemi di performance o errori dovuti al millennium bug (da test effettuati i bridge token-ring cessavano completamente di inoltrare il traffico). Un’indagine effettuata da Cap Gemini America nell’aprile 1998 su 128 società Usa rivelava che le aziende le cui reti presentavano problemi relativi all’anno 2000 erano cresciute dal 7% (dic-97) al 37% (marzo 98) mentre Gartner Group fornisce una percentuale tra il 40 e il 50% a livello mondiale.

Lo scenario previsto dagli analisti non è quello di un completo shutdown delle reti ma piuttosto una serie di inconvenienti che causeranno comunque dei fermi delle reti: firewall negheranno l’accesso, sistemi di management forniranno dati errati, sistemi di posta elettronica subiranno inconvenienti³⁵.

I problemi maggiori nelle reti sono dovuti alla loro complessità, essendo molti network costituiti da dispositivi e piattaforme misti.

ALCUNI CONTRIBUTI SULL’ARGOMENTO

PETER DE JAGER

Consulente informatico canadese, fu il primo, nel 1993 a suonare l’allarme sul problema anno 2000. L’Ufficio americano del bilancio ha previsto per la revisione generale dei computer oltre 2.300 milioni di dollari, la Gartner Group, il più importante consulente al mondo per l’informatica ha stimato la spesa complessiva tra 1000 e 2000 miliardi di dollari, la banca americana Morgan, abbassa la cifra a "soli" 200 miliardi di dollari e altri la alzano a 1000 miliardi per le cause legali e i contenziosi giudiziari. In Europa alcune stime sono di 300.000 miliardi di lire di cui 30.000 in l’Italia per la revisione dei programmi delle aziende italiane.

INDAGINE ELEUSI-HAL - Marzo 1998

Un’indagine³⁶ sul Millennium Bomb condotta nel marzo 1998 dal Centro Eleusi (il centro ricerche dell’Università Bocconi di Milano) per conto della software house milanese HAL³⁷, su un campione di 350 medie imprese italiane (99-499 addetti), rappresentativo di un universo di oltre 7300 realtà private emerse che quasi tutte (94,3%) conoscevano il problema anche se tardavano ad affrontarlo, ma un restante 5% (cioè ben 400 imprese) dichiarava di non saperne nulla. Inoltre, il 60% di queste aziende si dichiarava ottimista e fiducioso nel fatto che, o con l’intervento dei fornitori o con un intervento governativo (rottamazione del software non 2000 compatibile in cambio di software 2000 ready), la situazione si sarebbe risolta senza sforzi, mentre il restante 40% non aveva ancora pensato a nulla..

INCONTRO ANNO 2000 ED EURO

- MARZO 1998

In un incontro su "Il conflitto tra l’Anno 2000 ed euro"³⁸ ebbe come partecipante Capers Jones³⁹ cui si debbono i più avanzati studi sulle metriche del software. Lo studioso nordamericano dichiarò che oltre il 55% delle applicazioni in produzione sarebbero state coinvolte nel problema Anno 2000 ed oltre il 15% dalla conversione all’Euro e che il 70% dei softwaristi si sarebbe trovato a dover lavorare u uno di tali problemi.

Egli usò termini come corsa al disastro e definì una delle più imprudenti e rischiose decisioni della Comunità Europea quella di pianificare il completamento della conversione delle monete nazionali in un’unica moneta europea senza riguardo al fatto che i problemi della conversione in euro e quelli relativi all’anno 2000 sarebbero stati in diretta competizione tra loro, data la limitata disponibilità di risorse da dedicare allo sviluppo del software. Una politica molto più accorta sarebbe stata quella di rimandare la conversione della moneta unica al termine del lavoro per l’anno 2000, pianificandola almeno per il 2003.

Il risultato più probabile di tale sovrapposizione (tra conversione in euro e soluzione del problema anno 2000), disse Capers Jones, che sarebbe stato che nel 1998 i Paesi dell’Europa occidentale avrebbero dedicato tutto il loro impegno al problema Euro e solo nel 1999 avrebbero cominciato a presagire il reale rischio legato all’anno 2000 varando in tutta fretta a piani di emergenza⁴⁰. Ma non essendoci in Europa le sufficienti risorse per risolvere contemporaneamente i due problemi, egli previde che il 65% delle applicazioni informatiche non avrebbero raggiunto in tempo la conformità anno 2000.

Certamente mancare gli obiettivi di conversione all’Euro avrebbe creato notevoli problemi al mondo politico e finanziario, ma comunque sarebbero stati problemi minori rispetto a quelli che potrebbe causare l’Anno 2000 nei sistemi informativi europei.

La conversione all’Euro si può considerare un tipo di manutenzione evolutiva, quella all’anno 2000 una manutenzione correttiva. L’Euro è un problema di business con implicazioni tecniche, l’anno 2000 è un problema tecnico con risvolti di business.

Una valutazione dell’ordine di grandezza dei tempi e dei costi necessari per gli interventi anno 2000, ad esempio, usando il metodo dell’espansione del campo data, si può ottenere elevando alla potenza dello 0.3 il portfolio in function point⁴¹ (100.000 function point danno circa 32 mesi). In Italia il software istallato ha una dimensione di circa 290 milioni di function point (circa un sesto del totale dei 15 paesi dell’unione europea)⁴².

Considerando un costo orario del personale di 50 dollari, il costo per function point per le applicazioni scritte in Cobol è di 28 dollari per il Visual Basic 30 dollari, C, Pascal, Fortran etc, 35-40 dollari, assembler 80 dollari.

Per una piccola azienda con un staff dedicato al software di 5 persone e un portfolio di 6.000 function point occorre prevedere un impegno di 23 mesi con un costo totale di circa 200.000 dollari (oltre 3 miliardi di lire), ossia circa 33 dollari per function point. Questo rapporto rimane valido anche per le aziende con uno staff di 50 persone ed un portfolio di 50.000 function point. Il costo aumenta a 37 dollari per function point già per le aziende con 100 persone occupate nel software e un portfolio di 95.000 function point. Per le grandi aziende che hanno da 3 a 15 sedi, da 1000 a 20000 persone che si occupano del software ed un portfolio in function point da 900.000 a 18.000.000 il costo sale a 40 dollari per function point.

INDAGINE ELEUSI-HAL - Novembre 1998

Nel novembre 1998 un secondo studio "Osservatorio 2000" condotto dal centro Eleusi dell’Università Bocconi e dalla software house HAL sullo stato di salute delle medie imprese italiane rispetto al Millennium Bug riferisce che sulle 7300 aziende (tutta la media impresa, escluso il settore caccia e pesca e quello dell’industria estrattiva) che hanno tra 99 e 499 addetti il 18,7% saranno "2000 non compliant" allo scoccare del nuovo millennio.

Da marzo a novembre dunque le aziende che hanno affrontato il problema sono passate dall’80 al 96,4%; di esse il 44,1% dichiara di essere a posto, mentre ben 262 aziende non hanno ancora affrontato il problema e di queste l’11,3% (cioè 30 aziende) ha dichiarato che non intende occuparsene.

Per quanto riguarda i tempi, l’82% delle aziende ha un ritardo di 6 mesi, il 16,5% di 12 mesi e la maggior parte delle aziende ritiene che entro il marzo del 1999 dovrà già inserire nei propri computer date successive al 31 dicembre 1999.

LE INIZIATIVE GOVERNATIVE ESTERE

Il senato americano ha istituito da tempo un apposito comitato, il Primo Ministro olandese Wim Kok invitò il cancelliere tedesco Helmut Kohl a prendere concrete iniziative per evitare il deflagrare della bomba software. Il governo olandese con quello svedese e inglese sono stati i più attivi nel sostenere iniziative pubbliche e private per affrontare il problema anno 2000⁴³. Il Primo Ministro inglese Tony Blair è stato uno dei più sensibili al problema anno 2000; egli aveva reclutato oltre 20.000 tecnici (millenniun bug busters) stanziando l’equivalente di oltre 200 miliardi di lire. Lo stesso Primo Ministro britannico il 15 maggio 1998 a Birminghan ha voluto un summit del G-7 (Giappone, Stati Uniti, Canada, Gran Bretagna, Germania, Francia, Italia cui si è aggiunta la Russia) per definire un approccio globale al problema⁴⁴. La società di trasporti DHL Worldwide Express ha investito (già ai primi del 1998) 25 milioni di dollari per adeguare i suoi sistemi informativi alla scadenza dell’anno 2000 (oltre 20 milioni di linee di codice, 1000 server e 25.000 utenti collegati alla rete)⁴⁵.

Il presidente Clinton il 4 febbraio 1999 ha firmato un ordine esecutivo rivolto alle agenzie Federali, al Consiglio sulla conversione all’anno 2000 (Year 2000 Conversion Council) ai capi agenzia e a tutti i responsabili di settore, in cui si legge che il controllo del problema Y2K richiede un forte sforzo tecnologico e manageriale e pertanto ognuno ha la responsabilità nel proprio ambito che il problema Y2K abbia la massima priorità e che sia condotto alla risoluzione con rendiconti almeno trimestrali direttamente al presidente.

LE INIZIATIVE GOVERNATIVE ITALIANE

Il gruppo di lavoro 2000 la cui presidenza è affidata all’Aipa (che sottopose dal 1996 all’attenzione delle amministrazioni la problematica connessa all’anno 2000) ha calcolato in circa 108 miliardi la somma che lo Stato avrebbe dovuto sostenere per la revisione dei programmi di 21 amministrazioni centrali per un totale di 205 milioni di LOC (linee di codice) pari al 75% del patrimonio della Pubblica Amministrazione stimato in circa 273 milioni di LOC, ( consuntivo 1996).

La commissione governativa istituita il 6 agosto 1998 da Romano Prodi non è mai entrata in azione e si è riunita solo una volta nel settembre successivo poi è stata travolta dalla crisi di governo.

Il 14 gennaio 1999 il sottosegretario alla Presidenza del Consiglio Franco Bassanini ha presentato il "Comitato anno 2000" presso palazzo Chigi (e presieduto dall'ex sottosegretario alla Funzione Pubblica nel governo Prodi, Ernesto Bettinelli), ammettendo che "l'Italia è in grave ritardo ed è necessario accelerare i tempi" ed ha annunciato una conferenza nazionale per maggio⁴⁶. Tra i compiti del Comitato si legge: "valutare gli effetti connessi al mancato adeguatamente dei sistemi informatici e delle apparecchiature... monitorare le realizzazioni e delle soluzioni tecniche disponibili... prevenire gli effetti negativi sull'Italia e delle possibili ripercussioni nei rapporti con gli altri Stati... evitare gli eccessivi aggravi finanziari sulle amministrazioni pubbliche e sulle imprese". Valutare, monitorare, prevenire, evitare, ma non decidere, ordinare o risolvere: purtroppo il Comitato non sembra essere una task force o un'unità di crisi, come in altri Paesi e, al momento, dispone di soli 5 miliardi stanziati dalla Finanziaria con i quali si deve costruire tutto. Pochi giorni dopo, lo stesso Bettinelli lancia un grido di allarme: "Io ho accettato di dirigere questo Comitato per pura responsabilità politica. Ma il Governo non si rende conto del problema... Non abbiamo nulla, ci mancano gli strumenti, i poteri... non ho nemmeno uno straccio di segreteria organizzativa... e il tempo sta passando"⁴⁷http://www.repubblica.it/quotidiano/newspdocs/19990206/basi.html.

Per altri riferimenti si può fare una ricerca su Repubblica on-line (http://www.repubblica.it) con chiave "millennium"

ALCUNE ALTRE INIZIATIVE IN ITALIA - CENNI

L’Autorità per l’Informatica nella Pubblica Amministrazione (AIPA) ha diffuso alcuni documenti sull’adeguamento dei sistemi informativi automatizzati all’anno 2000 fin dal 1996⁴⁸. Essi riguardano varie "Indicazioni" sul problema dell’Anno 2000"⁴⁹.

L’Associazione nazionale produttori tecnologie e servizi per l’informazione e la comunicazione (Assinform) ha sviluppato un’azione di sensibilizzazione sul tema orientata alle associazioni industriali e alle piccole e medie imprese con incontri in varie città italiane⁵⁰.

La IBM Italia ha elaborato un documento molto dettagliato: "La piccola e media industria e il problema dell'Anno 2000⁵¹ disponibile gratuitamente, che è stata ripresa quasi integralmente dall’Assinform. Iniziative simili sono state intraprese da pressoché tutte le maggiori società di informatica.

CONCLUSIONE

Per il Millennium Bug non mancano le soluzioni tecniche, quello che sembra mancare è la volontà di affrontare con serietà un problema conosciuto nei più piccoli particolari, forse sottovalutato perché scomodo o, peggio, deriso come trucco di industrie informatiche.

A differenza dell’Euro che nel corso del 1998 le banche e le altre strutture finanziarie avevano improntato simulazioni e si applicavano all’esercizio della nuova valuta per collaudare una transizione che si voleva fosse il più possibile indolore, il problema dell’anno 2000 rischia di venire affrontato solo a emergenza in atto con il tentativo disperato di gestirla; come sperimentare una nuova arma il primo giorno di guerra senza sapere se sarà in grado di sparare nella direzione voluta o se invece esploderà in mano a chi avrà la sfortuna di usarla.

L’insegnamento che ne viene è che, nell’era dei computer, le decisioni politiche determinanti massicci aggiornamenti di software non possono essere pianificate usando arbitrarie scadenze determinate solo da processi politici, trattati internazionali o decreti governativi, ma devono derivare primariamente dalla capacità di compiere tali aggiornamenti sul software e sui data base. La politica non ha più il controllo su molti eventi.