Nei progetti di consulenza, i dati ESG sono spesso dispersi tra report aziendali, questionari e provider esterni. Senza un data layer coerente, gli indicatori diventano incomparabili e le analisi fragili. La differenza tra un cruscotto convincente e un lavoro contestabile risiede nella capacità di modellare le fonti, standardizzare le definizioni e garantire qualità e tracciabilità end-to-end.
Questo percorso tecnico mostra come costruire una data platform ESG pronta per la consulenza: dal catalogo delle fonti alle tassonomiefino a pipeline verificabili e controlli di coerenza ripetibili. L’obiettivo è produrre dataset affidabili, auditabili e riusabili in analisi, benchmark e rendicontazioni multi-standard, riducendo tempi di progetto e rischi di contestazione.
Fonti prioritarie e criteri di ingestione
Il primo passo è mappare le fonti ESGdistinguendo tra disclosure aziendale e dati di provider. Nel perimetro europeo contano CSRD ed ESRS per la rendicontazione obbligatoria, la EU Taxonomy per l’allineamento delle attività, SFDR per gli investitori e tassonomie come GRI o TCFD per comparabilità storica. Per ogni fonte si definiscono: frequenza, copertura, granularità, formato, licenza e regole di data provenance. Le disclosure vanno acquisite in versione integrale (PDF/HTML) e machine-readable (XBRL/CSV) per preservare il contesto; i feed dei provider richiedono mapping dei campi e note metodologiche versionate.
Le logiche di ingestione prevedono una zona raw a sola append, con hashing del file e firma temporale, e una zona staged con normalizzazione minima (encoding, unità, date). Ogni record riceve source_idextraction_ts e license_tag. Gli allegati (assurance, metodologie, boundary note) sono collegati come metadati per supportare revisioni e audit.
Tassonomie, ontologie e modello dati ESG
Un data layer utile nasce da un vocabolario controllato. Si definisce una ontologia che descrive entità (azienda, impianto, prodotto), misure (KPI), dimensioni (periodo, perimetro, unità), metodi di calcolo e relazioni tra standard. Nella pratica: un data model a stella con fact table degli indicatori e dimensioni per entità, standard, metrica, metodo, valuta/unità e scenario. La dimensione metric include ID univoco, definizione, formula, fonte normativa e mapping verso ESRS/GRI/TCFD.
La gestione delle unità richiede un dizionario con conversioni certificate (es. tCO2e, MWh, m3) e regole di rounding. Il perimetro va codificato: azienda, gruppo, sito, Scope 1/2/3 per emissioni, inclusi boundary geografici e temporali. Per conciliare standard diversi, si applica un livello di harmonization che mantiene sia la misura originale sia quella derivata, con trace della trasformazione e qualità associata (confidence score, coverage, estimation flag).
Pipeline dati: dallo scraping alle API analitiche
Una pipeline ESG efficace segue step ripetibili e osservabili. Esempio end-to-end: (1) Acquisizione da portali e API (scraping con parser semantico per tabelle e note); (2) Validazione sintattica (schema JSON/CSV, codifiche, caratteri); (3) Normalizzazione di unità e date; (4) Entity resolution su anagrafiche aziendali (LEI, VAT, ISIN) con punteggio di match; (5) Calcolo di indicatori derivati e tag di standard; (6) Data quality e coerenza; (7) Publishing su data warehouse/lakehouse; (8) esposizione tramite API versionate e semantic layer.
Strutturare le tabelle: raw_documents (blob, hash, fonte), stg_metrics (valore originale, unità, contesto), ref_entities (anagrafiche, alias), dim_metric (definizioni), fact_esg (valori armonizzati, attributi metodo), dq_issues (violazioni) e lineage_runs (passaggi, input/output). Le API espongono endpoint per entità, metriche e periodi con filtri su perimetro e standard, mentre il semantic layer fornisce misure dichiarative coerenti tra BI e notebook.
Data quality e controlli di coerenza
I controlli devono essere automatizzati e spiegabili. Quattro famiglie: (a) completezza (copertura per periodo/perimetro, campi obbligatori); (b) validità (domini ammessi, unità corrette, formati); (c) accuratezza stimata (range fisici/plausibili, confronti con baseline settoriali); (d) consistenza temporale e tra metriche. Esempi: emissioni Scope 1 + 2 non possono essere inferiori allo zero; intensità per fatturato deve scalare coerentemente con variazioni di ricavi; energia rinnovabile ≤ consumo totale; somma degli scope uguale o superiore alle emissioni complessive dichiarate.
Implementare regole come constraint nel warehouse e test di data unit nel CI. Ogni violazione genera record in dq_issues con severità, suggerimento di remediation e collegamento al lineage. Per stime o gap, si usa un flag estimated con metodo (es. fattori di emissione medi, proxy di settore) e intervallo di confidenza; i valori stimati non sostituiscono gli originali e sono separati da un attributo di provenienza.
Tracciabilità, audit e versioning
La tracciabilità è centrale. Ogni passaggio della pipeline produce metadatiparametri, commit del codice, versione del mapping, timestamp e input esatti. Il data lineage consente di risalire da un KPI al documento sorgente e alla formula applicata. Per garantire integrità, i file originali sono immutabili (append-only) con hash conservati; le trasformazioni salvano sia il plan sia gli output. Le dimensioni di standard e metriche sono versionate con valid_from/valid_tocosì report e benchmark restano riproducibili nel tempo.
La gestione delle identità aziendali richiede entity history per fusioni, spin-off e cambi di denominazione: gli ID storici sono mantenuti e collegati a un surrogate key. Per gli audit, un pannello di evidence raccoglie documenti, citazioni di pagine, estratti OCR, con evidenza di chi ha validato cosa e quando. Questo set di prove riduce drasticamente il rischio di contestazioni in sede di due diligence o assurance.
Governance operativa e product readiness
Un data layer affidabile vive di ruolipolicy e SLO. La data stewardship assegna responsabilità per domini (clima, risorse idriche, diritti umani), con workflow di approvazione e commenti. I data contracts con team analitici definiscono stabilità degli schemi e gestione del deprecato. In produzione, monitoraggio di latenza, freschezza, error budget di qualità e alert sugli scostamenti chiave. L’accesso è regolato per sensibilità (es. dati di supply chain) con mascheramento e policy di minimizzazione.
Per l’adozione in consulenza, predisporre semantic views orientate ai casi d’uso: doppia materialità, piani di decarbonizzazione, benchmark settoriali, scenari fisici e transizionali. Ogni vista include metriche certificatefiltri preimpostati e descrizioni operative. Documentazione e catalogo dati, integrati con esempi di query e notebook, accelerano l’onboarding di analisti e partner, mantenendo coerenza metodologica tra progetti e clienti.
