Business Intelligence per i Beni Culturali: flusso di lavoro ed elaborazione dati

Alla base di qualunque Sistema Informativo, stanno la scomposizione e la codifica degli elementi tecnologici identificabili nel manufatto (Germanà, cit., p. 64); i dati raccolti nell’ambito dei progetti di restauro, dalla scala architettonica fino a quella urbana, sono tipicamente caratterizzati da origini e contenuti eterogenei: è dunque importante riuscire ad estrarre da questa ingente mole di dati informazioni utili e operativamente spendibili per le finalità di analisi e monitoraggio e per efficientare i processi decisionali; tali informazioni devono inoltre essere facilmente gestibili dalle risorse umane coinvolte a diversi livelli gerarchici. Infatti, non è sufficiente che i dati siano semplicemente raccolti e conservati in modo strutturato perché ciò li renda utilizzabili nei processi decisionali: occorre una metodologia analitica basata su strumenti che trasformino i dati in informazioni e le informazioni in conoscenze in grado di dare informazioni immediate sull’andamento dei fenomeni monitorati. La BI può fornire dunque, anche nel settore dei Beni Culturali, una soluzione efficace a queste problematiche. Un altro aspetto cruciale che interessa la gestione dei dati afferenti al patrimonio architettonico è garantire l’interoperabilità tra dati prodotti e i tradizionali SIT (“Sistemi Informativi Territoriali”) in uso presso gli enti pubblici. La tecnologia su cui si basa la BI completa ed integra quanto fino ad ora realizzato su tecnologie Geografiche anche dette GIS – Geographic Information Systems realizzando analisi molto complesse ed estremamente efficaci nella rappresentazione. Il valore aggiunto della BI infine, sta proprio nella possibilità che tale tecnologia offre di approfondire le analisi, individuare le cause di determinati fenomeni, ipotizzare scenari previsionali, monitorare e controllare in continuo il proprio patrimonio di informazioni (Rezzani, cit.). Per tale motivo questo insieme di tecnologie risultano vantaggiose in applicazione ad un ambito, quello del restauro architettonico, che richiede comprensione dei dati (da quelli storici a quelli sugli interventi), documentazione della ‘filiera’ che li ha prodotti, semplificazione nell’analisi delle informazioni orientata alla corretta pianificazione degli interventi, monitoraggio.

Business Intelligence per i Beni Culturali: flusso di lavoro ed elaborazione dati

Il concetto di Business Intelligence applicato al mondo dei Beni Culturali può sembrare un ossimoro eppure il periodo storico che stiamo attraversando è legato a doppio filo a processi di trasformazione digitale – si parla di ‘economia 4.0’, ‘digital trasformation’, ecc. – che interessano i settori più disparati, dall’ingegneria biomedica all’agricoltura; quindi perché non dovrebbe interessare anche il settore del nostro patrimonio architettonico? Nel provare a dare una risposta a tale quesito, occorre partire dalle problematiche. Un sistema di gestione dati nel mondo aziendale ha spesso un’architettura complessa, personalizzata (o customizzata) per specifiche esigenze aziendali ed in grado di regolare non solo i dati, ma l’intera vita lavorativa di tutti i dipendenti e i collaboratori dell’azienda stessa. In ambito aziendale tale infrastruttura è possibile poiché basa i propri principi di funzionamento su standard di riferimento – software gestionali per l’amministrazione, la gestione del personale, la fatturazione, ecc. – già presenti sul mercato, per poi rigenerare

e, appunto, customizzare alcune parti dell’intera architettura per adattarla alle dinamiche e alle esigenze di ogni singola azienda; quest’approccio è tuttavia impossibile da mettere in atto nell’ambito dei Beni Culturali proprio perché non esistono standard di riferimento paragonabili a quelli sopra descritti e risulterebbe quindi antieconomico costruirne uno – meglio dire molti – per specifiche esigenze in un mercato così ristretto e afferente principalmente al settore pubblico, spesso purtroppo afflitto da problemi di efficienza, economicità, tempi di risposta. Questo scoglio apparentemente insuperabile può viceversa rappresentare una buona base di appoggio per chi vuole cimentarsi nell’impresa di applicare la BI al settore culturale. Essendo un ambito pressoché privo di qualunque sistema di gestione dati3 è possibile creare da zero l’intera architettura basandola sulle più moderne tecnologie e flussi di lavoro (workflows), liberi dai vincoli o da schemi preesistenti, tema questo che rappresenta il più grosso problema di trasformazione nell’ambito aziendale. Partire da una pagina bianca ci consente di introdurre strumenti ed implementare tecniche di analisi create ‘dal basso’ con meccanismi di bottom-up, che consentono elevate adattabilità e scalabilità. Come in ogni sistema di Business Intelligence è necessario dividere l’architettura che deve ospitare il flusso di lavoro in tre macro-ambiti: 1.Dati Iniziali/Fonti alimentanti. 2.Data warehouse4 . 3.Analisi. Il primo problema che deve essere superato riguarda le fonti alimentanti (quindi, da dove provengono i dati e chi li popola) e la base dati esistente. I più diffusi sono datasets geografici contenenti gli identificativi catastali degli immobili (es: ACI – “Anagrafe Comunale degli Immobili”) che vengono alimentati e pubblicati annualmente dai Comuni secondo le disposizioni della L. 132/2016. Questi vengono generalmente pubblicati sui siti istituzionali sottoforma di banche dati geografiche, shapefile o xml. Questa prima fonte dati consente di avere non solo i codici ID univoci e identificativi di tutti gli edifici ma anche i metadati di geolocalizzazione estremamente preziosi quando si parla di interoperabilità o transcodifica tra database, oltre ad essere assai efficaci in fase di analisi per la rappresentazione delle informazioni nello spazio geografico. Oltre a questi dati ‘istituzionali’ che rappresentano nella maggioranza dei casi gli unici in grado di rispondere ai requisiti tecnici minimi di uniformazione e formattazione (L. 132/2016), il resto delle informazioni disponibili nell’ambito del patrimonio architettonico è generalmente rappresentato da fogli di calcolo o progetti GIS più o meno aggiornati che però giacciono inutilizzati in qualche cartella di rete o unità di archiviazione in locale (hard-disk esterni, unità USB, CD, ecc.), privi di qualsiasi

3 Esistono alcuni esempi di gestionali per i dati catastali o il registro degli interventi, ma si tratta di soluzioni applicate sporadicamente e realizzate comunque da terze parti. Oppure di strumenti progettati a livello centralizzato (es. in uso a Ministeri e Soprintendenze) che mal di adattano a problematiche specifiche. 4 Un data warehouse, ‘magazzino’ di dati, è una collezione di dati strutturati ed elaborati tramite operazioni di ETL, preparati per le successive analisi e interrogazioni (queries).

standard di sicurezza. Per valorizzare e rendere fruibili tutti questi dati, che spesso sono il risultato di anni di studi, ricerche e investimenti, è necessario eseguire un lavoro certosino di ETL (Extract, Trasform and Load) ovvero una serie di operazioni di pulitura, normalizzazione e trasferimento delle informazioni all’interno del data warehouse creato per accogliere e centralizzare l’intero sistema di dati. Il secondo aspetto che deve esser curato è proprio il data warehouse: generalmente per i tradizionali sistemi è comodo ricorrere a database SQL (Structured Query Language) di tipo relazionale5. Il sistema relazionale, accanto a indubbi vantaggi, è caratterizzato da una certa rigidità che nel caso delle informazioni sui Beni Monumentali costituisce la peggiore condizione di lavoro, proprio a causa dell’estrema varietà delle informazioni, delle lacune e della mancanza di normalizzazione dei dati. Diventa dunque necessario strutturare il data warehouse in modo che le tabelle non abbiano necessariamente vincoli relazionali ma siano piuttosto ridondanti di ID6 a seconda del tipo di informazioni che deve raccogliere la tabella (anagrafica degli immobili, interventi eseguiti, anagrafica della facciata, elementi studiati o analisi effettuate su un singolo elemento di quell’immobile, ecc.) e del ruolo che quella tabella deve svolgere all’interno del processo di BI (tabelle dei fatti, tabelle delle dimensioni, tabelle di supporto ecc.). Evitare l’uso di relazioni fisiche nel database però, da una parte consente una forte implementazione di nuovi campi, nuove tabelle e quindi nuove informazioni all’interno del data warehouse, dall’altra determina la creazione di applicativi con logiche più complesse in grado di svolgere tutti quei processi di normalizzazione ed uniformazione delle informazioni che altrimenti porterebbero inevitabilmente alla generazione degli errori. Infine, l’ultimo e non meno importante ambito all’interno del processo di BI è l’analisi dati. Quest’ultimo aspetto rappresenta l’elemento ‘visibile’ di tutta l’architettura appena descritta e per tale motivo quello forse più delicato. L’analisi e la conseguente reportistica che viene generata devono tenere conto di due aspetti fondamentali che scaturiscono dall’esplorazione e dall’esposizione dei dati: uno è la complessità dell’analisi in relazione alla semplicità di lettura dei dati; l’altro è l’efficacia espositiva dell’analisi in funzione del target di fruizione del report. Per quanto riguarda il primo punto è opportuno definire cosa si intende per ‘complessità’ nel mondo della BI, il cui ‘ciclo vitale’ è rappresentato efficacemente in Fig. 4.1. Fino a qualche tempo fa l’estrazione bidimensionale, per la rappresentazione su assi cartesiani, di più record appartenenti a due datasets differenti era un’operazione assai complessa poiché consisteva nello scrivere queries (in stringa di codice) molto lunghe e ricorsive in cui l’errore era frequente. Al termine del processo, inoltre, il risultato ottenuto e visibile era piuttosto scarso perché il grafico generato si limitava alla rappresentazione del

5 RDBMS: Relational Database Managment System, le tabelle all’interno del database sono legate tra loro da legami fisici che garantiscono la consistenza dei dati. 6 Più precisamente le tabelle della prima forma normale che rappresentano i fatti (analisi, interventi, ecc.) presentano all’interno numerosi ID che rimandano alle altrettanto numerose tabelle costruite nella seconda e terza forma normale, all’interno dello stesso data warehouse.