Fattura elettronica con un pizzico di problemi in più

Posted on June 14, 2008 by claudio

Cominciano ad arrivare. Ho prenotato un volo per Budapest (per un meeting del gruppo di lavoro di ENISA sulle microimprese), e mi è arrivata dalla una fattura elettronica. Non una fattura in PDF da stampare, ma una vera fattura elettronica. Vale la pena di citare buona parte della mail che mi è arrivata:

Gentile Cliente,
La ringraziamo per aver scelto ….

Allegato alla presente e-mail troverà una fattura elettronica emessa dalla …. in base alla Sua prenotazione, conformemente alla legge ungherese.

La fattura originale si trova nel file con estensione .mssign. Se desidera verificare l’autenticità della fattura può farlo utilizzando il programma MultiSigno Verify che può essere scaricato gratuitamente da qui …

Informazioni sulla tecnologia e disposizioni di legge ungheresi inerenti alla fatturazione in formato elettronico

* Il file con estensione .mssign allegato all’e-mail è la fattura elettronica emessa da …. Hungary secondo le disposizioni di legge ungheresi rilevanti (Legge sulla fatturazione in formato elettronico 2001./XXXV.; Legge sulla contabilità del 2004; Decreto del Ministero delle Finanze 20/2004.)

* La fattura elettronica allegata è un file di formato speciale che contiene:

– la grafica delle fatture tradizionali emesse dalla …. Hungary in formato pdf, conformemente ai requisiti ungheresi di formato delle fatture previsti dalla legge 1992/LXXIV
– la firma della fattura creata con tecnologia PKI (Public Key Infrastructure) conformemente alle sopra citate leggi ungheresi.

* La firma è effettuata per conto della …. Hungary con il “certificato di legittimazione” della persona a cui sono stati conferiti i poteri di firma dalla …. Hungary. Il file della fattura elettronica contiene anche la “traccia di certificazione completa” del certificato usato per la firma e delle liste di certificazioni revocate (LCR) rilevanti.

* Ulteriori informazioni sulla procedura di firma e sul file della fattura firmata sono disponibili sul sito web della … da qui: Pratiche di firma <http://…/downloads/Signature_Policy_IT.pdf>

* Se la fattura deve essere utilizzata a fini contabili, il destinatario è vincolato a conservare la fattura elettronica nello stesso modo in cui conserverebbe una fattura cartacea.

Qui si pongono due diversi problemi. Il primo è ovviamente di validità generale del documento: la normativa italiana mi consente di accettare una fattura elettronica emessa in conformità alla normativa ungherese? Il problema naturalmente mi interessa come impresa ma meno come informatico, e lo passerò pari pari al mio commercialista, che ne sarà certamente felice… 😉

Io mi interesso della parte informatica, ed in particolare della validità della firma. Si tratta infatti di stabilire se una firma elettronica apposta ad una fattura in Ungheria sia valida e verificabile in Italia, tenendo conto del fatto che la Certification Authority è appunto ungherese. Si presentano due ordini di problemi. Il primo è di nuovo legale: la CA ungherese soddisfa i requisiti posti dalla legge italiana, che fanno sì che io poi possa accettare la firma su un documento in Italia? Secondo la normativa italiana, per quanto ho capito, la risposta è certamente sì se la fattura è stata sottoscritta con firma elettronica qualificata.

Si pongono quindi diversi problemi: il primo è capire se il certificatore emette certificati qualificati. Esaminando a mano il file si dovrebbe trattare della Magyar Telekom, chedal sito di FESA risulta effettivamente emettere certificati qualificati, ma naturalmente il sito di FESA, per quanto autorevole, non ha l’ufficialità necessaria per dare garanzie dal punto di vista legale. Esistono dei campi all’interno del certificato che lo dichiarano qualificato, ma naturalmente questi campi sono affidabili solo se il certificatore è già stato accettato come qualificato, quindi fino a quel punto non fanno testo. Quindi il problema di assicurarsi che il certificatore sia accettabile rimane.

Il secondo problema è ottenere il certificato della CA (e quindi la sua chiave pubblica) con cui verificare i certificati emessi. Anche qui, non basta andare sul sito suo o di qualcun’altro, perché non è un canale affidabile a meno di avere a priori una qualche chiave con cui verificare l’informazione fornita… per intenderci, in Italia sarebbe la chiave con cui il CNIPA firma l’elenco dei certificatori accreditati, pubblicata in Gazzetta Ufficiale. Tutti questi meccanismi di trust infatti si basano su una chiave iniziale scambiata attraverso canali “affidabili” (nel caso del CNIPA, la Gazzetta Ufficiale) e su una catena initerrotta di garanzie, in questo caso costituita dalla firma dei certificati. Per poter seguire la catena e quindi verificare il documento, bisogna avere la chiave iniziale.

Quindi abbiamo diversi problemi: capire se la Certification authority è accettabile secondo la nostra normativa, ottenere il certificato della CA attraverso un canale affidabile, e infine gestire il formato del documento e del certificato, che possono non essere quelli abituali per l’Italia, per quanto anche qui ci siano dei limiti di accettabilità posti dalla normativa.

Per primi consideriamo i problemi tecnici: senza risolvere questi non si accede alle informazioni e quindi non si possono affrontare gli altri. La fattura che mi è arrivata è in formato XAdES, e io non ho nessun tool per trattare questo formato. Non solo, ma contrariamente alle mie aspettative non sono riuscito a trovare niente di facilmente scaricabile che fosse adatto. Questo è il problema di avere tanto a che fare con i contesti più avanzati, che uno finisce per convincersi che determinati strumenti siano comuni solo perché ne sente parlare da anni; il meglio che ho trovato sono delle librerie, ma di scrivermi del codice per leggere una fattura al momento non ho proprio tempo.

La mail che ho ricevuto mi propone una soluzione a questo problema: mi propone infatti di scaricare un programma per la verifica dal loro sito, un programma dal nome MultiSignoVerifySetup_EN.exe Naturalmente inorridisco all’idea di scaricare un eseguibile che mi viene indicato in una mail e installarlo, e figuriamoci cosa succederebbe se una pratica di questo tipo diventasse prassi… ma il problema principale è naturalmente che eseguire un programma ottenuto in questo modo, che mi risponda “va tutto bene”, non costituisce certamente una verifica affidabile del certificato, dato che: non so da dove viene il programma (di fatto viene da chi mi potrebbe potenzialmente fornire un certificato non valido), non so sulla base di quali parametri/normativa/altro il programma svolge la sua attività, e come al solito non so come è stato ottenuto il certificato della CA.

Su questo genere di problemi sto lavorando, guarda caso, con Infocert nel progetto europeo R4eGov. In particolare in questa fase ci stiamo occupando di uno strumento pensato proprio per affrontare questi problemi, ovvero le Trust-service Status List, definite nello standard ETSI TS 102 231. Si tratta essenzialmente di una versione evoluta dell’elenco dei certificatori prodotto da organismi quale il CNIPA, pensato per essere prodotto ad esempio proprio da organismi di questo tipo. Si tratta quindi sempre di un elenco non solo di certificatori, ma più genericamente di “trust services”, che possono essere servizi di timestamping ecc. Per ogni servizio sono elencate le informazioni che permettono di valutare se in un determinato contesto può essere considerato trusted. Nel caso della CA ad esempio, si può sapere se effettivamente produce certificati qualificati (potrebbe avere un’altra entry nella lista in cui è descritto un suo diverso servizio di emissione di certificati non qualificati), se è accreditata ecc. Una entry naturalmente permette di accedere al suo certificato. La Trust-service Status List (TSL) permette quindi di ottenere attraverso un “canale sicuro” (la TSL è naturalmente firmata) il certificato delle CA che si considerano trusted o conformi ad una normativa. In più, la TSL può sostanzialmente “linkare” altre TSL, per cui un’agenzia di un paese potrebbe potenzialmente linkare le TSL di altri paesi (ma naturalmente, questa non sarebbe solo una scelta tecnica, dato che al centro del meccanismo ci sono principi di fiducia e di delega). Infine, la TSL è strutturata (XML, tanto per cambiare) e quindi può essere gestita con strumenti standard e uniformi nei diversi paesi. Il meccanismo permetterebbe quindi di superare molti dei problemi di interoperabilità fra paesi diversi.

Intanto io però ho per le mani la mia fattura elettronica, e per leggerci qualcosa mi sono scaricato il programma che mi hanno suggerito… che ho installato in una macchina virtuale usa-e-getta, si intende 😉 Il simpatico programmino mi informa così che il certificato non è qualificato, precludendomi la via facile per accettare la fattura. Mi tocca così avventurarmi nella normativa sulla fatturazione elettronica, e in particolare (spero) nel D. L. 20 febbraio 2004 n. 52 – Attuazione della direttiva 2001/115/CE che semplifica ed armonizza le modalità di fatturazione in materia di IVA. Il quale all’art. 3 dice:

La trasmissione per via elettronica della fattura, non contenente macroistruzioni ne’ codice eseguibile, e’ consentita previo accordo con il destinatario. L’attestazione della data, l’autenticità dell’origine e l’integrità del contenuto della fattura elettronica sono rispettivamente garantite mediante l’apposizione su ciascuna fattura o sul lotto di fatture del riferimento temporale e della firma elettronica qualificata dell’emittente o mediante sistemi EDI di trasmissione elettronica dei dati che garantiscano i predetti requisiti di autenticità e integrità. Le fatture in lingua straniera devono essere tradotte in lingua nazionale a richiesta dell’amministrazione finanziaria e gli importi possono essere espressi in
qualsiasi valuta purché’ l’imposta sia indicata in euro.


Ne deduco quindi che io potrei secondo la normativa italiana rifiutare la fattura elettronica, ma non chiarisce ovviamente, a me non giurista, se chi la emette che opera secondo la normativa ungherese può invece insistere per inviarmela.

Dice però che la fattura, anche in assenza di firma qualificata, potrebbe essere accettata se è stata trasmessa mediante sistemi EDI di trasmissione elettronica dei dati che garantiscano i predetti requisiti di autenticità e integrità. E chi lo decide se i requisiti sono garantiti (che poi si direbbe soddisfatti, penso)? L’Agenzia delle Entrate quando mi contesta la fattura, ad esempio? Mah… mi dovrò informare.

C’è però un altro punto interessante. Il programmino mi dice che il “Root Certificate” non è stato accettato, e anzi me lo segnala in rosso, il che è giusto. Visto che sto sperimentando, provo ad accettarlo. Il programmino si connette ad Internet (e se fosse un trojan sarebbe felice di avere questa scusa per farsi abilitare sul personal firewall) e scarica il certificato… ma a questo punto, sorpresa: mi compare la finestra del sottosistema di Windows che gestisce le CA, che mi conferma che è un certificato che non ho accettato come affidabile: a quanto pare il programmino si appoggia a quel sottosistema per decidere se la CA è stata accettata, non usa un proprio database. A questo punto, incuriosito, esporto il certificato e lo importo in Windows, e come mi aspettavo… adesso il programmino considera valida la CA (che sto usando per validare una fattura elettronica, non per navigare in Internet). Quindi considererebbe valida una fattura firmata con un certificato di Verisign, di quelli che ti danno sulla base di un indirizzo di posta elettronica? O una CA qualsiasi che io ho accettato per motivi miei? E comunque, alla fine la scelta di accettare la CA l’ho fatta io a mano, niente canali sicuri né garanzie sulle caratteristiche di conformità della CA. Mah… Chiaramente è una questione che dipende dalla normativa ungherese,il programma verificherà in base a quella, magari nel documento ci sono delle macro che lo invaliderebbero secondo la normativa italiana, e magari a lui invece la cosa non interessa minimamente. O magari è un difetto del programmino (la cui licenza peraltro fa riferimento a Kopint Datorg), ma penso comunque che quando le fatture elettroniche si diffonderanno ci saranno cose interessanti. Sarebbe meglio essere preparati.

Posted in ict, Sicurezza | Tagged , , , | 1 Comment

Attaccanti e difensori, competenze diverse

Posted on June 2, 2008 by claudio

Prendo spunto da questo post, nel quale leggo alcuni commenti a un face-off fra Schneier e Ranum. Essenzialmente, Schneier è favorevole alla “vulnerability research”, nella logica aperta tipica della ricerca seria sulla crittografia, dichiaratamente contraria alla “security through obscurity”. Ranum invece sostiene sostanzialmente la posizione per cui l’attenzione al cercare vulnerabilità non posta a miglioramenti significativi nella qualità dei sistemi. Sono assolutamente d’accordo con il poster, entrambi esprimono dei punti validi ma fra le due posizioni quella di Ranum è più solida. Si vede chiaramente che Schneier viene dalla crittografia, mentre Ranum viene dalla sicurezza delle reti. Non ripeto le considerazioni dell’articolo o del post, ma ne vorrei aggiungere qualcuna.

Una funzione fondamentale della ricerca e pubblicazione di vulnerabilità, che Schneier si è dimenticato di citare, è quella di fare da “cane da guardia” rispetto alle aziende che producono software. Queste non hanno in generale interesse a investire nella sicurezza dei loro prodotti, che è un costo che non da funzionalità “visibili”, e anzi tendono per ovvie ragioni di marketing a sminuire i problemi. Quello che porta veramente l’attenzione sul problema non è l’esistenza degli attacchi ma la pubblicazione degli errori, specialmente se grossolani. La “full disclosure” non è sempre esistita: è nata nella prima metà degli anni ’90 come risposta ad un’industria che metodicamente trascurava la sicurezza, sminuiva i problemi con assurdi “fattori mitiganti” e non forniva informazioni se non come forma di marketing. E parlando di “fattori mitiganti” non mi riferisco a Microsoft, che pure fa un uso abbondante di questo concetto: Microsoft all’inizio degli anni ’90 non aveva un ruolo di rilievo nello sviluppo di Internet. Mi riferisco invece soprattutto ai grossi produttori di sistemi Unix e Unix-like, nonché a molti progetti di software “indipendenti” tipo sendmail. Credo di aver avuto già occasione di dire che la mailing list Bugtraq è nata proprio in conseguenza di uno di questi episodi. Vado a memoria: un baco di sendmail particolarmente critico era in una parte del codice che molti vendor avevano modificato nelle versioni per i propri sistemi. Dopo infinite discussioni e informazioni parziali o fuorvianti, qualcuno (non ricordo chi) ha pubblicato se ben ricordo su “firewalls” un proof-of-concept che finalmente ha permesso di capire quali versioni fossero le versioni vulnerabili. Sulla mailing list ci sono state però proteste per la pubblicazione e quindi è nata Bugtraq proprio per poter pubblicare queste informazioni. Non c’è da dubitare che in assenza della continua pressione causata dalla pubblicazione delle vulnerabilità, si tornerebbe alla situazione di disinteresse da parte dei vendor e di informazioni fuorvianti dei primi anni ’90.

Tuttavia, ha certamente ragione Ranum: l’attenzione alla “vulnerabilità”, che spesso si riduce oltretutto al baco software, è eccessiva ed ha portato a questa continua corsa alla patch come strumento principale per correggere i problemi di sicurezza, anziché a ragionare sul progetto. E forse, la cosa va letta tenendo presente quanto detto sopra: sui bachi i produttori vengono messi pubblicamente sotto pressione, sulla progettazione no. Microsoft può essere la controprova di questo concetto, perché è l’unica che è stata messa sotto pressione realmente e pubblicamente (ovvero, in un modo comprensibile al grande pubblico) per cattiva progettazione dal punto di vista della sicurezza, e mi sembra che sia l’unica che ha di conseguenza reso pubblici (ovvero, di nuovo, quasi comprensibili al grande pubblico) i propri sforzi in senso progettuale, in particolare con Vista, e che si è quindi esposta anche a critiche e discussioni pubbliche sulla qualità del progetto. Forse la strada per migliorare realmente la sicurezza dei sistemi è proprio questa, riuscire a rendere “pubblica” la discussione sui difetti delle architetture e non solo sulle vulnerabilità.

Ma non era questo il tema che volevo inizialmente affrontare, bensì quello della capacità della ricerca di vulnerabilità di fornire indicazioni su come realizzare sistemi migliori. Sono d’accordo con Ranum sul fatto che questa capacità è minima, ma non solo per le questioni principalmente “di mercato” di cui parla Ranum.

Il problema è che disegnare un sistema sicuro e trovarne le vulnerabilità in un sistema in esercizio sono due competenze diverse. Entrambe le attività richiedono la “mentalità della sicurezza”, che come dice giustamente Schneier è innaturale per chi è abituato a cercare di far funzionare le cose. È il tipo di mentalità che porta a cercare di capire come possono “non funzionare” le cose, come trovare difetti. Dice Schneier: This mindset is difficult to teach, and may be something you’re born with or not. But in order to train people possessing the mindset, they need to search for and find security vulnerabilities–again and again and again. Una mentalità che è difficile da insegnare o da imparare senza la ricerca attiva di vulnerabilità. Security engineers see the world differently than other engineers. Instead of focusing on how systems work, they focus on how systems fail, how they can be made to fail, and how to prevent–or protect against–those failures. Disegnare sistemi senza tenere conto di questo approccio vuole dire concentrarsi su come far funzionare le cose, impostazione che aiuta poco dal punto di vista della sicurezza. Il risultato sono sistemi che sembrano perfetti se si segue la logica (e le spiegazioni) di chi li ha disegnati, e che poi rivelano i loro limiti ad un’analisi nell’ottica del “come non farli funzionare” . Ed è per questo che si dice sempre che la sicurezza va messa dall’inizio, perché questa logica deve essere parte della progettazione. La sicurezza non può essere né una collezione di “funzionalità di sicurezza” né una serie di toppe a posteriori. Ma attenzione, ricerca di vulnerabilità e “bucare i sistemi” sono due cose diverse. Good cryptographers discover vulnerabilities in others’ algorithms and protocols. Good software security experts find vulnerabilities in others’ code. Good airport security designers figure out new ways to subvert airport security. And so on. È chiaro che scaricare un tool da Internet e usarlo per bucare un sistema non insegna niente, mentre invece non è necessario attaccare i sistemi degli altri per acquisire questa mentalità.

Tuttavia, al di là della “mentalità della sicurezza”, attaccare i sistemi e progettarli sono due attività molto diverse, e richiedono competenze diverse, non basta la mentalità della sicurezza. Io tendo a fare il paragone con le casseforti. Allo scassinatore non basta sapere che se la cassaforte ha un certo meccanismo allora basta fare un buco in un certo punto per aprirla: deve conoscere i singoli modelli e sapere in pratica esattamente dove va fatto il buco. E se con un’altra serve invece sentire determinati rumori, deve avere la pratica per sentirli. E deve sapere anche che in alcuni casi basta una mazza molto pesante. Insomma, serve appunto la pratica. Per quanto riguarda i sistemi, deve saper utilizzare le tecniche (che non sono semplicemente i tool) e tenersi aggiornato costantemente su versioni, vulnerabilità e trucchi. Questo non farà però di lui una persona capace di progettare casseforti sicure, al più potrà dare indicazioni su errori da evitare. Allo stesso modo, la mentalità della ricerca di vulnerabilità porterà a dare indicazioni del tipo “fate la validazione dell’input”, una logica di rattoppo che non entra nel merito del progetto. Disegnare un sistema sicuro è tutt’altra cosa. Il progettista di casseforti non necessariamente ha la mano di velluto, e magari una mazza da cinque chili non la alza neppure, ma oltre ad avere la mentalità giusta deve sapere cosa serve per disegnare una cassaforte. Nel caso del software ad esempio, deve sapere che gli errori nel software ci sono sempre e deve sapere come minimizzare gli effetti di un errore di validazione dell’input. Della differenza fra “scrivere codice senza errori” e “disegnare software sicuro” ho già parlato qui, prenendo postfix come esempio, ma lo stesso discorso vale per i sistemi e le procedure, non solo per il software. Insomma, disegnare sistemi sicuri richiede di saper disfare ma anche di saper costruire in sicurezza, e questo  è uno dei motivi principali per cui è così difficile trovare sistemi e prodotti sicuri, ed è anche il motivo per cui saper bucare sistemi non basta. In effetti, sistemi mal disegnati e poco attenti alla sicurezza sembrano essere in grado di produrre una quantità praticamente illimitata di vulnerabilità, tanto che trovarne una e correggerla sembra avere un impatto trascurabile sulla sicurezza complessiva.

Nello stesso tempo, la verifica autorizzata e pianificata delle vulnerabilità serve comunque, perché fra un buon progetto e una buona realizzazione c’è comunque molta strada; ma le toppe servono se il progetto è buono.

Posted in Sicurezza | Tagged , , | Comments Off on Attaccanti e difensori, competenze diverse

Informatici in azienda

Posted on May 26, 2008 by claudio

Negli ultimi tempi ci sono molte discussioni sul ruolo dell’informatica e degli informatici in azienda. Lo testimoniano, fra l’altro, la frequenza degli interventi di Cubasia su Punto Informatico, o meno italianamente post come questo di Cringely, ma anche in fondo l’attenzione (fra noi informatici) all’IT Governance. È proprio l’articolo di Cringely che mi ha spinto a queste riflessioni sulla questione, che una volta sfrondata di tanti giri di parole si può riassumere in due domande: “Perché, se l’IT è diventata così importante per il funzionamento dell’azienda, questa sua importanza non le viene riconosciuta, ad esempio con un ruolo meno subordinato del CIO?” e “Perché se l’informatica è così importante l’informatico è sottostimato e spesso sottopagato (particolarmente in Italia, a quanto pare)?”.

Si tratta di una questione complessa, almeno per me che sono appunto un informatico e di gestione aziendale ne so poco. Mi limito appunto a qualche riflessione. L’articolo di Cringely sul CIO che non fa carriera mi ha riportato in mente un articolo su una vecchia rivista che, dopo una faticosa ricerca, ho ritrovato. Faticosa per via del peso dello scatolone che ho tirato giù da un armadio. Si tratta infatti del n. 2 della rivista ZeroUno, datato marzo 1982, e il titolo è “Perché il manager EDP non fa carriera”. No, non è che mi ricordi tutte le riviste che ho letto negli ultimi venticinque anni, è che per qualche motivo già allora quell’articolo mi aveva colpito e mi è rimasto impresso, e dato che è in uno dei primi numeri della rivista è fra quelli che ho conservato. L’articolo è firmato da una certa Janet Crane ed è probabilmente la traduzione di un articolo scritto negli USA dal titolo:”MIS: a starring role at last?”. Dice sostanzialmente che il personale EDP (sì, c’è qualche trermine un po’ desueto) è felice di starsene chiuso nel datacenter, ben pagato “perché avere a che fare con le macchine è più facile”, senza aspirare ad incarichi di dirigenza, ed è bloccato dalla sua immagine di tecnico con una conoscenza limitata dei problemi aziendali. Anzi, sono i dirigenti provenienti da altre funzioni aziendali che arrivano ad assumere la dirigenza dell’elaborazione dati. E il ruolo dei dirigenti EDP in azienda? Cito:”L’informatica è una delle basi della gestione aziendale del futuro, afferma un dirigente, ma noi non siamo tra i membri della direzione“. Ci sono altri punti che meriterebbero di essere citati, come l’inefficienza del datacenter “nascosta” dalla rapida evoluzione delle tecnologie, portata anche a scusante del fatto che i problemi vengono affrontati principalmente comprando le ultime novità del mercato (tema che si ritrova nel precedente articolo di Cringely). Oppure frasi come “Ci siamo nascosti dietro l’alta tecnologia e il cambiamento tecnologico. Invece dovremmo uscire allo scoperto e cercare di controllarlo: dopotutto siamo pagati per questo, per la gestione del cambiamento. La programmazione e le tecniche di programmazione devono focalizzarsi su quello che sarà il sistema aziendale da qui a qualche anno, su come creare una tecnologia e un ambiente umano adatti a quel futuro. Le esigenze del sistema aziendale sono la forza motrice: il cambiamento della tecnologia e dei comportamenti è la risposta del manager a queste esigenze“. IT Governance?

Insomma, a parte i termini sembra di sentire i discorsi di oggi. Con una differenza. Se è ancora vero che l’informatico ritiene il proprio lavoro in qualche modo unico (termini dell’articolo di ZeroUno, ma dice anche Cringely: Since the early mainframe days there has been a priesthood of sorts in corporate computing), adesso in più IT organizations often disrespect users and users often disrespect IT. In più, il professionista IT non è più strapagato come una volta. E questo ultimo punto, alla fine, è quello che fa nascere le discussioni.

La mia (personalissima) opinione ha appunto una prospettiva storica, che però ha come base questa continua tendenza e tentazione dell’informatico di sentirsi in qualche modo diverso e unico, e di usare la tecnologia per giustificarsi da una parte, e per promuovesi dall’altra.

Ai tempi dell’articolo di ZeroUno, l’IT era felice di starsene chiusa nei datacenter, e la cosa non le creava problemi, perché i professionisti erano ancora rari e ben pagati; e qui i professionisti dell’IT hanno perso la loro prima occasione. Con gli anni novanta è arrivato il vero cambiamento: l’informatica è (ri)esplosa, ha invaso ogni aspetto e processo dell’azienda. Nel periodo della bolla della new economy, sembrava che il mercato sarebbe riuscito ad assorbire un numero illimitato di professionisti anche con competenze infime a costi astronomici. La nascita delle società più assurde, strapagate, gli investimenti in qualsiasi cosa che sapesse di informatica hanno consolidato la sensazione degli informatici di essere “diversi”. Non interessavano i contratti o le tutele sindacali, quelle erano cose per gli altri, i “deboli”. Il professionista dell’IT si faceva ricompensare in stock options, perché il suo interesse era quello dell’azienda, e la crescita aziendale era una cosa alla quale lui avrebbe partecipato in modo determinante. E qui ha perso la sua seconda occasione, perché poi la bolla è scoppiata, lasciando sul terreno la maggior parte di quelle aziende assurde, e riportando bruscamente il professionista IT con i piedi per terra. Molto bruscamente, perché il “risveglio” per le aziende ha voluto dire una reazione a base di tagli fortissimi agli investimenti in IT, fallimenti di aziende dell’IT anche buone e non certo sopravvivenza delle migliori; molti di quei professionisti si sono trovati come Lucignolo nel paese dei balocchi: da un mondo di luci e di giochi a somaro che tira la carretta, magari con paghe e trattamenti da operatore di call center. Si sono spesso addirittura trovati peggio degli “altri” lavoratori, perché l’egocentrismo stimolato dalla bolla della new economy ha impedito non solo la formazione di una vera categoria professionale, ma anche la semplice integrazione con quelle esistenti. In fondo, buona parte dei problemi di cui parla Cubasia si possono ricondurre a questo impegno profuso negli anni dall’informatico nell’isolarsi dal resto dell’azienda. Ma non è certo servito a far imparare qualcosa all’informatico tipo: continua a chiamare utonti gli utenti, continua a ritenersi diverso (questa posizione si riconosce quando si vedono commenti sul tono: “Ma quali problemi, basta essere bravi informatici e i problemi si risolvono, senza tante storie sui contratti e simili.”). E soprattutto, continua a credere che le aziende caschino ancora nel giochino della tecnologia. “Se l’informatica si fermasse, si fermerebbe l’azienda. Perché non lo capiscono e non danno all’IT il ruolo che le spetta?”. E qui il professionista dell’IT sta perdendo la sua terza occasione. Perché prima di tutto in azienda il ruolo e i soldi vengono dati a chi se li conquista attraverso il suo potere contrattuale, ad esempio perché porta i soldi (il marketing). E soprattutto, la tecnologia non ha nessuna importanza. L’azienda si fermerebbe se si fermasse l’informatica? Bene, si fermerebbe anche se se ne andasse l’elettricità, ma non per questo gli elettricisti vengono fatti dirigenti. L’informatica non è come l’impianto elettrico? Certo, è più complicata, ma è comunque vista come un’utility, che al più quando non funziona causa problemi. Ricordo una recente chiacchierata con un luminare (economista) della gestione dei sistemi informativi, e quello che ha risposto alla mia domanda su quanto si sente dire ogni tanto a proposito del’IT Governance, che l’IT dovrebbe essere più propositiva riguardo ai processi di business aziendali. La risposta è stata sostanzialmente che quella è una cosa che si racconta all’IT per farla contenta, ma che se l’IT riuscisse semplicemente a stare dietro ai cambiamenti aziendali senza creare problemi sarebbe una bella cosa. Non che io sia completamente d’accordo con questa posizione, ma certamente rende bene l’idea del ruolo attuale dell’IT. Bene, se c’è qualcosa di diverso sta all’informatico dimostrarlo, non all’azienda capirlo; e perché l’IT sia altro che un’utility, l’informatico deve capire realmente l’azienda, interagire con l’azienda a tutti i livelli. Ho letto in questi giorni che poche aziende hanno un CIO, in realtà la maggior parte ha un IT Manager, sottolineando con questo la differenza fra chi si è realmente integrato nella gestione dell’azienda e chi è semplicemente un “sistemista evoluto”. Mi sembra molto vero: se l’informatico vuole avere un ruolo diverso deve diventare realmente parte dell’azienda. E prima di tutto, l’informatico deve imparare a parlare con il personale dell’azienda: con i dirigenti ma anche con i colleghi. Colleghi, non utonti.

Posted in ict | Tagged , , | Comments Off on Informatici in azienda