I dati in azienda aumentano sia a causa del passare del tempo, creando un’importante base storica, sia perché aumentano i sistemi che consentono la gestione e l’archiviazione di nuovi dati. L’automazione è elevatissima, ciascuno dei nuovi i sistemi ha scopi diversi e, a complicare il tutto, le tipologie di dato sono tra le più disparate. In più, bisogna sempre considerare la distribuzione geografica dei dati, on-premise e in cloud.
In una Data Driven Company, sapendo di avere tutti questi dati in azienda, nasce l’esigenza, oltre che di archiviarli, anche di consultarli e quindi, per poterne ottenere il massimo valore possibile, diventa importantissimo avere una visione d’insieme di tali informazioni e il fatto che siano confinati in silos diventa controproducente.
Inoltre, i metodi “di una volta” come stampare tabulati o utilizzare fogli di calcolo alimentati a mano sono assolutamente inadatti a quelle che sono le esigenze di un’azienda di medie/grandi dimensioni che voglia sfruttare al massimo queste informazioni.
Figure aziendali diverse hanno bisogno di accedere e visualizzare i dati in modo diverso. Al marketing manager interessano informazioni diverse rispetto, ad esempio, al data analyst ma entrambi hanno bisogno di confrontare informazioni spesso provenienti da i sistemi più disparati. Da qui la necessità di avere un repository centrale in cui archiviare tutte queste informazioni: il Data Warehouse.
Se lo analizziamo dal punto di vista architetturale, per la realizzazione di un Data Warehouse abbiamo bisogno
All’interno del database vengono poi create tre aree logiche per la gestione del ciclo di vita del dato: Staging Area, Data Warehouse e Data Mart (che contengono dati già fruibili tramite strumenti di Business Intelligence).
Ma il Data Warehouse è sufficiente a soddisfare tutte le esigenze di strutturazione e razionalizzazione dei report, dei dati e delle informazioni che vengono distribuite in azienda?
Il Data Warehouse porta con sé delle criticità relative alla comprensione, alla qualità, alla correlazione e alla conversione del dato. Il fatto di avere tutti i dati nello stesso posto non significa che siano comprensibili o visualizzabili da chiunque. Partiamo dal presupposto che il Data Warehouse è un’implementazione meramente tecnologica di una necessità di business, non è un sistema nato per il business, nasce pressoché esclusivamente per mettere tutti i dati nello stesso posto.
Uno dei presupposti da tenere in considerazione è che in un’azienda le sorgenti dati, oltre a essere differenti, non vengono concepite per condividere le proprie informazioni. I sistemi di contabilità, ad esempio, nascono per tenere la contabilità, non hanno la velleità di distribuire quelle informazioni in altri contesti, quindi contengono anche dati sporchi, incongruenti, magari anagrafiche incomplete ecc. Semplicemente “accumulare” tutto in un unico punto non risolve il problema, anzi potenzialmente lo complica. La qualità delle informazioni che vengono travasate nel Data Warehouse diventa fondamentale.
Quando abbiamo raccolto tutti i dati in un unico punto dobbiamo trovare il modo di farli “parlare tra di loro”. Pensiamo ad un ERP, ad un CRM, ad un sito di e-commerce con tutto il suo ecosistema: ci sono modi diversi di identificare le stesse informazioni. Quindi diventa fondamentale avere un sistema per mappare queste informazioni, correlarle fra di loro. Aggiungiamoci anche la complessità tecnologica: quanti database diversi – e ci riferiamo solo alla tecnologia – possiamo avere all’interno di un’azienda? Diventa necessario trovare un’omogeneità per quel che riguarda i formati utilizzati dalle diverse tecnologie.
In definitiva, il classico Data Warehouse prevede una struttura delle informazioni predefinita, rigida, decisa a priori e che come tale deve essere fruita. Inoltre, le informazioni che entrano nel Data Warehouse devono essere certificate: i proprietari del dato, cioè i sistemi sorgenti, devono verificare che il dato importato sia coerente e sono gli unici a poter garantire la bontà di questo processo. Questo tipo di lavorazione è molto articolata e dispendiosa, di conseguenza riesce a fornire solo dati consolidati riferiti al passato. Ovviamente non sempre questo è sufficiente per le esigenze aziendali attuali. Lo step evolutivo successivo nella gestione dei dati, che nasce proprio per ovviare a questo tipo di limitazioni, è la Data Integration.
Per capire in cosa consista la Data Integration facciamo un paragone con il classico Data Warehouse.
La principale differenza è che a livello architetturale si introduce semplificazione, non c’è più lo strato intermedio - cioé il Data Warehouse vero e proprio, incluso l’ETL - all’interno dell’architettura di un’azienda. Infatti gli strumenti che interrogano i dati accedono direttamente alle basi dati delle applicazioni, questo consente di avere a disposizione i dati del momento presente oltre al fatto che i dati non vengono esportati e duplicati in altri sistemi restando nell’applicazione sorgente.
Esattamente come il Data Warehouse anche la Data Integration non è immune da criticità. Come i problemi di semantica, ad esempio: l’identificazione dello stesso prodotto all’interno di diversi sistemi è specificato allo stesso modo? Chi si occupa di tradurre queste diverse codifiche visto che non c’è più il Data Warehouse a fare da strato intermedio?
Alcuni sistemi sono aggiornati istantaneamente in real-time (le informazioni inserite all’interno del CRM sono subito disponibili), altri sistemi invece hanno dei batch che consolidano i dati ad una data ben precisa, in un momento ben preciso (come accade per la contabilità). Ovvia conseguenza è che ci possono essere disallineamenti, cioè manca coerenza all’interno della visione d’insieme delle informazioni disponibili in un preciso istante.
Quindi torna la necessità di avere un set di dati separato da quello delle sorgenti dati delle applicazioni che abbiamo in azienda, che però dev’essere il più possibile attinente ad una visione del presente, altrimenti si incorrerebbe negli stessi problemi del Data Warehouse.
Le soluzioni tecnologiche fin qui descritte non necessariamente soddisfano le necessità di ogni tipo di azienda, proprio perché queste tecnologie non coprono completamente le esigenze emerse da problematiche più “moderne e attuali”. C’è stata quindi una graduale evoluzione degli approcci mirati al raggiungimento dell’obiettivo di diventare una Data Driven Company: si è passati concettualmente da Data Warehouse a Data Integration fino a Data Fusion.
Il concetto di Data Fusion potremmo sintetizzarlo in questo modo: attraverso la correlazione dei dati si ottiene un unico “oggetto” consultabile, che non salva semplicemente i dati ma li rende fruibili attraverso uno strumento, il Data Hub, che diventa un provider di informazioni e non un mero archivio.
La Data Fusion è oggi possibile perché i costi delle risorse computazionali e dello storage necessario a mantenere enormi moli di dati sono drasticamente calati negli ultimi anni, il che ha consentito anche di ottenere livelli di performance decisamente più elevati.
L’obiettivo, come dicevamo, deve essere quello di fornire dati a chi ne ha bisogno conformemente alle sue necessità. E qui entrano in gioco il Data Hub e la "Cegeka way": dare ciò che serve, a chi serve e quando serve. Il 2022 è stato un anno di svolta per il data management: ci si è resi conto che non serve più soltanto accumulare dati, ma bisogna usarli per risolvere reali problemi di business. Una rivalutazione, in altri termini, del data management, visto sempre più come un cammino in continua evoluzione.
La stragrande maggioranza delle aziende non è in grado di organizzare e interrogare i propri dati per ottenere le informazioni rilevanti ai fini decisionali. Architetture migliori, più intelligenti, più economiche e più veloci possono dare alle aziende l’opportunità di prendere decisioni, comunicare con gli stakeholder e anticipare i trend più velocemente che mai.
Scopri come la tua azienda può diventare davvero data-driven 👇 o mettiti direttamente in contatto con un esperto Cegeka.