Quasi ogni organizzazione vuole prendere decisioni in tempo reale. Sapere in questo momento quante unità sono in magazzino, quale linea di produzione sta rallentando, quale paziente sta peggiorando. Avere un cruscotto che si aggiorna mentre la realtà cambia, non il giorno dopo.
Il problema non è la volontà. È che i sistemi con cui quei dati vengono prodotti non erano stati progettati per produrli in tempo reale.
Il gap che nessuno nomina
La real-time analytics è tra le priorità dichiarate della maggior parte dei technology leader nel 2026. Ma c’è una differenza enorme tra volere dati in tempo reale e avere un’architettura in grado di produrli.
Un dato in tempo reale non nasce da un report. Nasce da un sistema progettato per catturare gli eventi nel momento in cui accadono, trasmetterli attraverso un’infrastruttura che li elabora senza latenza, e renderli disponibili nel formato giusto al sistema che li deve consumare.
Un ricovero registrato, una dimissione confermata, un ordine inserito o una macchina che segnala un’anomalia sono tutti eventi. In un’architettura real-time, questi eventi diventano immediatamente disponibili ai sistemi che ne hanno bisogno. Ogni passaggio di questa catena presuppone scelte architetturali precise — che la maggior parte delle organizzazioni non aveva motivo di fare quando quei sistemi sono stati progettati, perché all’epoca il batch era sufficiente.
Come funzionano davvero la maggior parte dei sistemi
Prendiamo un caso concreto. Un’azienda ospedaliera vuole sapere in tempo reale quanti posti letto sono disponibili per reparto, quanti pazienti sono in attesa al pronto soccorso e quali risorse sono già allocate. Informazioni critiche per chi gestisce l’operatività clinica.
Il problema è che queste informazioni risiedono in sistemi diversi — il gestionale delle ammissioni, il sistema di cartelle cliniche, il software di programmazione delle sale operatorie — che aggiornano i dati in modo asincrono, spesso con sincronizzazioni notturne o orarie. Un paziente dimesso alle 14:00 potrebbe non risultare tale nel sistema di gestione dei posti letto fino alle 18:00. Nel frattempo, decisioni operative vengono prese su dati che non rispecchiano la realtà.
Aggiungere una dashboard sopra questi sistemi non risolve nulla. Mostra dati aggiornati con ritardo in un formato più moderno. Il problema non è la visualizzazione. È l’architettura che produce i dati.
Cosa serve davvero
Un’architettura real-time richiede tre elementi che devono essere progettati insieme, non aggiunti in sequenza.
Event streaming. I sistemi che producono dati devono essere progettati per emettere eventi nel momento in cui accadono — non per aggiornare tabelle che qualcuno leggerà dopo. Questo cambia il modo in cui le applicazioni scrivono i dati, non solo il modo in cui li leggono.
Pipeline di elaborazione. Gli eventi devono essere elaborati, filtrati e arricchiti mentre transitano — non dopo che sono stati archiviati. Questo richiede un’infrastruttura di stream processing che non esiste nei sistemi tradizionali e non si installa sopra ad essi.
Integrazione tra sistemi. I dati in tempo reale spesso devono essere combinati da fonti diverse. Se questi sistemi non sono stati progettati per comunicare in modo sincrono, il real-time resta un’aspirazione, non una capacità operativa.
Nessuno di questi elementi è una feature da attivare. Sono scelte architetturali che determinano come il sistema è costruito dall’inizio.
Non è necessario ricominciare da zero
Questo non significa che ogni organizzazione debba sostituire tutti i sistemi esistenti. In molti casi è possibile introdurre gradualmente un’architettura event-driven attorno alle piattaforme già presenti, concentrandosi inizialmente sui processi che generano maggiore valore operativo.
L’approccio corretto non è scegliere tra “teniamo tutto” e “ricostruiamo tutto”. È identificare quali processi hanno bisogno di visibilità in tempo reale, capire dove si trovano i colli di bottiglia architetturali che lo impediscono, e intervenire in modo progressivo e controllato — senza interrompere l’operatività e senza accumulare nuovo debito tecnico.
Il costo di volerlo senza averlo progettato
Le organizzazioni che cercano di ottenere real-time analytics senza ripensare l’architettura quasi sempre finiscono nello stesso posto: uno strato di strumenti di visualizzazione sopra sistemi che continuano a produrre dati con ritardo. Il cruscotto è moderno. I dati che mostra hanno dodici ore.
Non è un problema di strumenti. È un problema di architettura. E come sempre, costa molto meno risolverlo prima che dopo.
Le organizzazioni non ottengono dati in tempo reale installando nuove dashboard. Li ottengono costruendo sistemi capaci di produrli.