Per parlare di System Integration, proviamo intanto a darne una definizione che delimiti il campo di applicazione. Chiamiamo System Integration quell’attività che consiste nel progettare e realizzare un sistema informatico a partire da componenti già esistenti. Il concetto di “componente” è peraltro molto generico: può essere un prodotto già esistente, un sottosistema già completo, una libreria già scritta.

Chiamiamo dunque sistema informatico integrato un sistema in cui i diversi componenti dialogano tra loro e che visto dall’esterno viene percepito come unitario.

Non ci sarebbe neppure bisogno di esplicitare il concetto di System Integration se si trattasse di ingegneria meccanica anziché di ingegneria del software. Nessuno immagina di progettare un’automobile senza conoscere prima i componenti già disponibili e senza utilizzare poi quelli più adeguati agli obiettivi del progetto. Nell’industria automobilistica e nell’uso corrente si parla proprio di “componentistica”.

Nell’industria del software le cose si complicano, intanto proprio perché non c’è la consapevolezza di considerare il software (anche) industria. Prevale il mito del garage, del programmatore geniale e solitario, dell’applicazione dirompente.

Eppure quando si elabora un progetto ci si pongono (e ci si debbono porre) sempre le stesse domande: per caso quello che occorre

1. già esiste? E quanto costa?
2. può essere adattato da qualcosa che già esiste? E quando costa questo adattamento?
3. può essere ottenuto mettendo insieme pezzi che già esistono? E quanto costa questa integrazione?
4. può essere ottenuto mettendo insieme pezzi che già esistono e pezzi realizzati “ad hoc”? E quanto costa questa diversa integrazione?
5. deve essere realizzato integralmente? E quanto costa questa realizzazione?

Nell’informatica attuale l’ultimo caso (con gran dispiacere del mito) è molto raro. Ma ciò che si deve intendere per “progettare” è proprio scegliere tra le molte soluzioni possibili quella che meglio risponde ai vincoli funzionali, di risorse, di costi e di tempi.

Ma quando si lavora ad un progetto informatico non c’è solo la materia prima, più o meno elaborata, non c’è solo il software; ci sono soprattutto committenti, fornitori, collaboratori, utenti, tutte persone con una loro prospettiva e con un ruolo fondamentale nella realizzazione e nel successo del progetto. Avere la responsabilità di un progetto (essere un “project manager”) significa (oltre gli obiettivi, i costi, le scadenze) porsi in ascolto ed in dialogo con tutti, fare sistema con tutti.

Allora occorre forse modificare la definizione di System Integration per allargarne il campo di applicazione. Chiamiamo (System) Integration quell’attività che consiste nel realizzare una comunità d’intenti tra i diversi attori del progetto per ottenere un sistema informatico che sia soddisfacente per tutti.

Oggi ogni idea, proposito, piano è nel linguaggio corrente un progetto. Ogni insieme di attività è nel linguaggio amministrativo un progetto. Vorremmo qui riportare il progetto nel campo dell’ingegneria e dell’architettura, al quale è stato preso in prestito, nel migliore dei casi.

Perché un progetto implica un rigore, un disegno e dei vincoli di risorse, di tempi, di normative. A tanto apparente determinismo si oppone però sempre l’intrinseca incertezza dei risultati. Non a caso la parola “progetto” deriva dal latino “proiectus”, participio passato di “proicĕre” «gettare avanti». Il punto fermo è dunque solo quello di partenza, poi c’è il lancio, che è anche lo slancio di chi al progetto lavora.

Per trasformare lancio e slancio in volo e non in caduta ogni progetto deve essere gestito, da “gerĕre” «condurre, amministrare». Ma l’accento va posto non tanto sull’amministrazione, quanto sulla conduzione, sul camminare a fianco. Anche l’inglese “management” viene da “manu agĕre” «condurre per mano» e tutto torna.

Gli scaffali sono pieni di libri e di manuali sulla gestione di progetto, sul “project management”. Numerose normative, con annesse certificazioni, tentano di codificare, di fissare, le regole ed i comportamenti per una corretta gestione di progetto. Tutti sono, nessuno in modo esclusivo, buoni strumenti. Ma più importante è cogliere lo spirito che deve animare una buona gestione di progetto.

La prima parola chiave è “relazione”. Tra tutti coloro che sono da prospettive diverse coinvolti dal progetto: committente, utenti, gruppo di lavoro.

Un buon “project manager”, oltre a conoscere le regole e gli strumenti, sa infatti che il successo di un progetto non coincide con il suo successo tecnico e che un progetto fallisce se non coinvolge attivamente tutte le persone del committente nella sua realizzazione (e a maggior ragione inevitabilmente fallisce, aggiungiamo, se il committente è conflittuale al suo interno).

Un buon “project manager” è al servizio del suo gruppo di lavoro e ha come obiettivo di consentire ad ognuno di lavorare nelle migliori condizioni. Ogni persona che lavora deve essere consapevole e sentirsi partecipe dell’insieme del progetto e del suo successo, indipendentemente dal suo ruolo e dalla porzione di progetto assegnata. Non sono gli incentivi a motivare, ma il lavoro ben fatto ed il premio non atteso.

Certo anche il più scrupoloso e attento “project manager” non dispone di tutte le leve di regolazione e di controllo ed è saggezza essere preparato al prevedibile imprevisto. Sarà la “virtù relazionale” ad incanalare la “fortuna” inevitabilmente ondivaga del progetto verso il successo, come era del Principe di Machiavelli.

E l’altra parola chiave è “fiducia”. Che non è il risultato di un contratto, ma di una condivisione di obiettivi, perché scommettere sul successo comune è la migliore garanzia di successo.

Nella sua “Classificazione delle attività economiche Ateco 2007”, il normatore ambiguamente classifica le attività dell’informatica (distribuite tra i codici 62 “Produzione di software, consulenza informatica e attività connesse” e 63.1 “Elaborazione dei dati, hosting e attività connesse; portali Web”), indistinguibili nella realtà operativa delle imprese, ora come Industria, ora come Artigianato, ora come Terziario. Il normatore rende così inconsapevole testimonianza che il mestiere dell’informatico è al tempo stesso Industria, Artigianato e Servizio.

Certamente la produzione di software è un’industria. Lo testimoniano l’evidenza della delicata complessità dei sistemi informatici e i dati: il settore ICT in Italia comprende più di 75.400 imprese e più di 456 mila addetti, per un mercato digitale di 64.234 milioni di euro (fonte: “Rapporto Assinform 2015”). In quanto produzione industriale il software richiede standard, metodi, rigore.

Certamente la produzione di software è un’arte. Lo confermano l’autonomia degli informatici nell’impegno quotidiano davanti allo schermo vuoto, la dimensione ridotta dei gruppi di lavoro, anche quando impegnati in grandi progetti. In quanto produzione artigianale il software richiede invenzione, creatività, plasticità.

Il modello ideale dell’azienda di informatica è la bottega rinascimentale: luogo di incontro di organizzazione, competenza tecnica ed invenzione.

Nella bottega collaborano le diverse specializzazioni: chi impasta i colori, chi dipinge i festoni di fiori e frutta, chi scrive requisiti, chi scrive codice, chi installa macchine, chi verifica i sistemi. Tante specializzazioni quanti e diversi sono i mestieri dell’informatica.

Nella bottega collaborano le diverse esperienze, dal giovane garzone al maestro. Il maestro è riconosciuto per competenza, la presunzione è inconcludente e risibile. Il giovane informatico cresce se ha la fortuna di avere a fianco qualcuno che gli insegna il mestiere, che è diverso da quello che si impara sui libri.

L’eccellenza è il risultato dell’equilibrio tra organizzazione e invenzione, tra metodo e creazione: ingegneria del software che costruisce software bello, perché “il software brutto non funziona”.

Big Data
Nel 2015, qualsiasi entità che afferisca al dominio concettuale dell’analisi dei dati. Novelli Dulcamara, i Big Data risolveranno i problemi del traffico, della sanità, dell’ambiente. Per adesso, certamente, permettono a pochi di controllare molti sul Web. Tutti quelli che ieri non sapevano bene cosa fosse la Business Intelligence, oggi non sanno bene cosa siano i Big Data, però è di tendenza parlarne. In realtà, insieme di tecniche e di tecnologie (per lo più in divenire) non relazionali (noSQL) per gestire l’estrema numerosità e/o variabilità e/o varietà delle informazioni a disposizione.

Business Intelligence (BI)
In italiano: comprensione della realtà. Al di là della moltitudine di nomi e di sigle, di prodotti e di slogan, la Business Intelligence è quell’insieme di tecniche e di tecnologie che consente di rendere disponibile il patrimonio di conoscenza contenuto nei dati e che permette conseguentemente di prendere delle decisioni consapevoli. Per quanto il termine Business faccia pensare agli affari dell’economia e alla finanza, occorre riferirlo più ampiamente ai fatti della realtà delle persone.

Data Cleaning
In italiano: pulizia dei dati. Attività umile, paziente, lunga, complessa che consiste nel trasformare un ammasso di dati sporchi, lacunosi, errati, in un insieme di dati utilizzabili per la Business Intelligence senza viziarne i risultati: è noto che da premesse errate discendono conseguenze errate. I dati sono sempre in partenza sporchi, lacunosi, errati, anche se non esiste cliente che non dichiari che i suoi dati sono puliti, completi, corretti.

ETL (Extraction, Transformation, Loading)
In italiano: estrazione, trasformazione, caricamento. Fatto 100 un progetto di Business Intelligence, 25 sono le attività di progettazione, 10 sono le attività di realizzazione delle interfacce, tutto il resto è pulizia, estrazione, trasformazione, caricamento dei dati in strutture ben progettate. Ma è difficile spiegarlo: quanti in un’ora di leggiadro balletto, vedono i mesi di prove e di fatica?

Cubo
Struttura logica e fisica che all’interno di un data warehouse corrisponde ad un fenomeno (o fatto) oggetto di analisi: il cubo contiene i valori numerici delle metriche che misurano il fenomeno. Tali valori delle metriche (variabili dipendenti) sono visualizzabili in funzione dei valori delle dimensioni di analisi (variabili indipendenti) del fenomeno. Non bisogna confondere un cubo con un datamart, come avviene nelle conversazioni da “Bar BI” (anche se ad un cubo può corrispondere un datamart)

Datamart
In italiano: il mercato dei dati. Un datamart (o data mart) è un sottoinsieme dei dati presenti in un data warehouse, caratterizzati da una qualche qualità aggregante (ad esempio appartengono tutti ad una specifica area, funzionale o organizzativa, di un’azienda). La presenza fisica (e non solo logica) di datamart non è necessaria in un data warehouse, ma può essere utile per inserire un livello di semplificazione oppure per permettere una lavorazione incrementale del data warehouse. Non bisogna confondere un datamart con un cubo, come avviene nelle conversazioni da “Bar BI” (anche se ad un datamart possono corrispondere uno o più cubi).

Data Mining
In italiano: scavo nei dati, indagine sui dati. Scopo del Data Mining è quello di ricercare, in uno specifico insieme di dati, anche molto numeroso, particolari regolarità, granularità, relazioni, che con la loro presenza rivelino caratteristiche non altrimenti percepibili del fenomeno al quale i dati appartengono. Gli strumenti teorici e tecnici per il Data Mining sono per lo più metodi statistici e numerici. Business Intelligence e Data Mining afferiscono quindi allo stesso dominio dell’analisi dei dati, ma sono poi molto diverse per finalità e tecniche e non debbono essere confuse.

Data Warehouse (DWH)
In italiano: magazzino di dati. Base di dati, disegnata e realizzata in base alle specifiche esigenze di ogni progetto, che contiene i dati acquisiti e resi disponibili da un sistema di Business Intelligence. Semplificando al massimo, un sistema di Business Intelligence, nel suo complesso, carica il data warehouse con i dati presi (e puliti e trasformati) dal mondo oggetto di indagine e rende i dati contenuti nel data warehouse disponibili agli utenti del sistema, secondo modalità ed in formati utili. Un data warehouse è quindi una parte (essenziale) di un sistema di Business Intelligence, anche se spesso, per sineddoche, con la parte si indica il tutto.

DSS (Decision Support System)
In italiano: sistema di supporto alla decisione. Espressione ormai arcaica con cui un tempo si designavano i sistemi di Business Intelligence. Espressione però da non dimenticare per non perdere di vista l’obiettivo reale di un sistema di analisi dei dati: quello di fornire misure ed informazioni esatte per prendere decisioni che poi spettano alle persone.

Interfaccia
Porzione di software che permette il collegamento tra sistemi o sottosistemi differenti. Nel caso uno dei sistemi collegati sia un essere umano più o meno esperto, per interfaccia si intende ciò che l’essere umano, l’utente, vede e quindi percepisce del sistema complessivo. Nel caso di un sistema di Business Intelligence possono essere tabelle, diagrammi, oggetti grafici più o meno leggibili ed accattivanti. Una delle difficoltà principali del progettista di un sistema di Business Intelligence è quella di spiegare all’utente che l’interfaccia sta al sistema complessivo più o meno come la carrozzeria sta all’automobile.

VVV (Volume, Velocity, Variety)
In italiano: quantità, velocità [di produzione], varietà [di tipi e formati][dei dati]. Se preceduti dall’aggettivo “grande” sono i tre sostantivi che definiscono le qualità dei dati potenzialmente gestibili come “Big Data”. Non è necessario che i dati siano “grandi” per ognuna delle tre qualità, anche una sola grandezza può motivare il ricorso a tecniche e tecnologie “non relazionali” (noSQL).

La prima edizione del libro “The Data Warehouse Lifecycle Toolkit” di R. Kimball è stata pubblicata nel 1998. La prima edizione del libro “Data warehouse: teoria e pratica della progettazione” di M. Golfarelli e S. Rizzi è stata pubblicata nel 2002. Sono dunque molti anni (moltissimi, per i tempi compressi dell’informatica) che la teoria della progettazione di data warehouse è stata fondata su solide basi.

Eppure, se è lecito un riassunto “in timelapse” degli ultimi quindici anni visti da una prospettiva operativa, l’adozione di sistemi di Business Intelligence basati su data warehouse da parte delle aziende è avvenuta e avviene con grande ritardo.

Dapprima i data warehouse parevano essere nel sentire comune appannaggio di aziende iperuraniche o comunque lontane o comunque libresche.

Solo molto lentamente, ed in Italia da non più di una decina d’anni, le proposte di data warehouse hanno trovato ascolto nelle aziende e sono arrivate le prime applicazioni, anche se molto spesso si è trattato di “data warehouse” di nome, ma non di sostanza tecnica, complice una certa confusione sulla sostanza.

È così arrivato il tempo dei grandi prodotti “di Business Intelligence”, legati a grandi produttori ed a grandi costi di licenze. Le aziende e i loro decisori hanno comprato i grandi prodotti con la sicurezza di “avere scelto il meglio”, ponendo così le loro scelte al riparo da critiche.

Purtroppo, o fortunatamente, comprare gli strumenti migliori non è garanzia di ottenere un buon progetto, così come comprare i pennelli ed i colori più pregiati non garantisce un bel quadro. A maggior ragione se si confondono gli strumenti con i risultati. Il progettista doveva, come deve, spiegare, e giustificare, che un progetto parte dagli strumenti, ma non si esaurisce con essi.

Ora sono molte le aziende che si sono dotate di sistemi di Business Intelligence, anche se la maggior parte delle applicazioni aziendali si limita all’analisi dei fenomeni economico-contabili e commerciali, e poche o pochissime sono realizzate “a regola d’arte”.

Oggi poi, paradossalmente, poiché anche l’informatica vive di marketing e di moda, non si parla neanche più di Business Intelligence: qualsiasi attività o sistema che abbia a che fare con l’analisi dei dati viene etichettata come “Big Data”.

Molto lavoro resta dunque da realizzare:

• aumentare la qualità della progettazione dei sistemi di Business Intelligence
• estendere il dominio applicativo della Business Intelligence oltre i ristretti confini dell’analisi economica, perché un’azienda è molto più del suo bilancio e molti indicatori concorrono a misurarne lo stato (così come forse lo stato di un Paese non si misura solo dal suo PIL)
• diffondere una “cultura del dato”, antidoto all’approssimazione
• parlare con onestà di Big Data.

Per ragionarne e per lavorare assieme occorre condividere almeno il “vocabolario minimo”, altrimenti troppe riunioni sull’analisi dei dati aziendali sembrano il consesso dei dottori al capezzale di Pinocchio.

A cimentarsi con questo vocabolario sarà la prossima parte di questa pagina di diario.

La disponibilità dei fondi europei di Horizon 2020, insieme all’attivazione in molte regioni italiane dei bandi POR-FESR, suggerisce una riflessione sulle opportunità di finanziamento.

Nella complessità della gestione operativa, commerciale, economica e finanziaria, la navigazione delle imprese appare piuttosto determinata dai rischi e dalle prospettive imminenti, quand’anche fosse orientata da una visione strategica di obiettivi lontani.

In tale complessità la partecipazione ad un bando pubblico di finanziamento alle imprese può apparire come una divagazione dagli impegni immediati, una sottrazione di energie altrimenti utili alla navigazione.

Molti elementi, non tutti soggettivi, possono concorrere a rafforzare tale sentimento:

• la difficoltà di accedere alle informazioni
• la laboriosità della presentazione della domanda
• l’eventuale sfiducia circa i criteri di attribuzione
• l’incertezza dei tempi di attuazione e di finanziamento.

Il risultato è che spesso le imprese, soprattutto le piccole e medie, desistono dall’intraprendere un percorso incerto. Così, paradossalmente, l’Italia ridistribuisce solo una porzione dei finanziamenti europei che le sono destinati. Si può dibattere se ciò sia dovuto ad un difetto della domanda o ad un difetto dell’offerta; di certo però in tutti i bandi emessi il valore delle richieste delle imprese supera di gran lunga quello delle risorse economiche messe a disposizione, segno che l’attenzione può e deve crescere con l’offerta.

Comunque sia, a caratterizzare l’offerta attuale è l’estrema varietà: i bandi differendo naturalmente per la natura dell’ente banditore ed erogatore, per le finalità del finanziamento e per le modalità di gestione. L’ente può avere una copertura locale (più spesso regionale), nazionale o europea. Il finanziamento può essere destinato a potenziare le infrastrutture, promuovere la formazione e l’aggiornamento, incentivare l’occupazione, ridefinire ed ottimizzare i processi aziendali, concepire e realizzare progetti di Ricerca e Sviluppo; può assumere la forma di prestito a tasso agevolato o di contributo alla spesa. Tale estrema varietà, cui corrisponde il più delle volte analoga varietà formale dei bandi, nasconde però una sostanziale omogeneità: in tutti i casi ci sono obiettivi da dichiarare, costi da prevedere per raggiungere gli obiettivi, rendicontazioni da fornire per dimostrare i costi.

L’accento va posto sugli obiettivi. Sono gli obiettivi quelli che devono determinare la partecipazione di un’impresa ad un bando di finanziamento, non quelli tattici della navigazione a vista, ma quelli strategici del porto da raggiungere: obiettivi che possono giustificare l’impegno ed i tempi di una partecipazione dall’esito incerto. Vale la pena postulare un finanziamento per un’iniziativa, un’attività, un progetto che comunque l’impresa realizzerebbe o vorrebbe realizzare per il proprio sviluppo. La partecipazione di un’impresa che abbia come sola finalità la ricerca di fondi, a prescindere dagli obiettivi aziendali, sarebbe sterile, sarebbe grano sparso sui sassi e non produrrebbe nessuno sviluppo: sarebbe, in ultima analisi, sperpero di denaro pubblico, fosse pure lecitamente acquisito.

Un finanziamento che consenta o amplifichi una specifica possibilità di sviluppo è una vera opportunità per l’impresa, che deve essere tentata. Un finanziamento a pioggia può dilavare il terreno, un finanziamento mirato può irrigare un campo.

Certo, resta la questione della difficoltà informativa e della complessità procedurale, fino al paradosso dei bandi che sembrano concepiti per rendere più arduo l’accesso ai fondi disponibili. Per questo ci si può anche affidare ai servizi di specialisti, istituzionali o privati, che possano assistere le imprese. Ciò che conta non è solo che l’esperto risolva le complessità formali, ma che assecondi ed accompagni anche gli obiettivi di sviluppo dell’azienda, senza sostituirsi ad essa.