Ciao a tutti, mi chiamo Christopher Pillsbury e sono davvero felice di essere qui con voi oggi. Vi racconterò come abbiamo creato un framework che aiuta i team di ricerca e sviluppo a passare dalle idee alla realizzazione di insight concreti, unendo AWS, Snowflake e JMP.
In questa sessione, illustreremo come i dati sperimentali vengono raccolti e analizzati in tempo reale e come questa architettura consenta agli scienziati di prendere decisioni più rapide e affidabili. Qualunque sia il tuo ruolo in R&S, data science o operations, il mio obiettivo è mostrarti il percorso dai dati grezzi alle informazioni e come l'analisi scalabile possa rimodellare il modo in cui i team innovano e collaborano.
Per l'agenda di oggi, inizierò illustrandovi le principali tappe del percorso di implementazione della nostra istanza JMP Live, esploreremo il percorso dei dati, dall'esperimento grezzo alle decisioni attuabili, e discuteremo l'impatto della scalabilità della generazione di dati. Descriverò il processo di architettura di IDEXX Data Solutions, mostrando come l'acquisizione, l'organizzazione dei dati e l'analisi lavorino insieme per potenziare gli utenti di R&S. Esamineremo esempi concreti di dashboard e report in azione e l'impatto misurabile che hanno avuto sul processo decisionale e sull'efficienza.
Infine, concluderò con i punti chiave e le lezioni apprese dalla creazione di un sistema di analisi in tempo reale scalabile in ambito R&S. Ma prima, lasciatemi spiegare brevemente in cosa consiste il mio ruolo.
Un Data Solutions Architect non è un ruolo unico. È un mix di diverse discipline che si uniscono per rendere i dati utilizzabili, affidabili e di impatto. Tra queste, Governance e Sicurezza, che garantiscono conformità, privacy e controlli di accesso affinché i dati rimangano affidabili e sicuri. Il Data Engineer, che assicura che i dati fluiscano dove necessario, creando pipeline, integrazioni e trasformazioni affinché i dati grezzi diventino utilizzabili.
DevOps, gestione dell'infrastruttura, piattaforme cloud, automazione e mantenimento di sicurezza e resilienza. Architettura dei dati, progettazione di modelli, definizione di strutture, garanzia della scalabilità delle fondamenta. Analista dati, traduzione dei dati in insight, dashboard, visualizzazioni e storie che guidano le decisioni. Analista aziendale, collegamento tra l'aspetto tecnico e il problema aziendale, raccolta dei requisiti, comprensione del contesto e garanzia di risoluzione dei problemi corretti.
Infine, l'Amministratore di Database, con particolare attenzione a prestazioni, ottimizzazione, affidabilità e, nel mondo odierno, costi. Insieme, queste prospettive costituiscono il ruolo di un Architetto di Soluzioni Dati. Il mio compito è quello di ricoprire ogni ruolo, unirli e fornire soluzioni che colleghino persone e team per creare pipeline di dati che portino a insight aziendali.
Ora che sapete qualcosa su di me e sul mio ruolo, parliamo un po' del nostro percorso con JMP Live finora. Come ogni buon progetto dovrebbe fare, abbiamo iniziato con dialoghi con il reparto IT aziendale, dove abbiamo delineato un percorso di distribuzione cloud-first e i passaggi per realizzarlo. La loro guida ci ha aiutato a configurare un server Azure e gli account di servizio necessari, creando le basi sicure di cui avevamo bisogno per l'automazione.
Il 31 luglio 2024, Alex mi ha aiutato a installare e rendere operativo JMP Live. Poco più di una settimana dopo, il 9 agosto, abbiamo pubblicato il nostro primo report completamente automatizzato da una vista Snowflake. Nel corso del primo anno del nostro progetto pilota, abbiamo spinto al limite la nostra istanza JMP Live testando il carico di grafici SPC automatizzati con 7 milioni di record e oltre 20 colonne, con aggiornamenti ogni 5 minuti. Abbiamo implementato dashboard per supportare diverse esigenze aziendali e abbiamo verificato che questa architettura potesse scalare fornendo al contempo informazioni in tempo reale ai team che vi fanno affidamento ogni giorno.
Sulla carta, la nostra implementazione è molto semplice. Tuttavia, il percorso complessivo dall'idea alla decisione e il percorso verso i dati non lo sono. Chiunque abbia lavorato con esperimenti, dati e reporting sa che ci sono molti passaggi nascosti lungo il percorso. Ecco perché, prima di addentrarci nella scalabilità e nei sistemi, voglio radicarci nel processo che tutti condividiamo. Che si lavori in ambito di ricerca e sviluppo, data science o operations, il percorso da un'idea a una decisione attuabile segue uno schema simile.
Il percorso verso un'intuizione è un modo semplice ma efficace per descrivere il passaggio dalla curiosità alle decisioni. Tutto inizia con una domanda o un'ipotesi. Forse sei un ricercatore e sviluppatore che testa un nuovo concetto di prodotto, o forse stai estraendo e analizzando un ampio set di dati. A un certo punto, ti viene in mente un'idea che vale la pena testare. Da lì, si conducono esperimenti, si producono grandi quantità di dati o si sviluppa persino il codice.
È qui che il lavoro vero e proprio inizia a prendere forma. I dati di output degli strumenti, la registrazione manuale dei dati o i set di dati generati da codice vengono archiviati, a volte localmente, a volte nel cloud, ma in questa fase sono ancora grezzi. Ora arriva la parte critica: la strutturazione, la pulizia e l'analisi dei dati. È qui che applichiamo metodi statistici, testiamo le nostre ipotesi e iniziamo a scoprire i pattern nascosti nei risultati.
Infine, le intuizioni vengono comunicate. Ciò potrebbe significare condividere una presentazione, scrivere i risultati in ELN o condividere un'importante tappa di sviluppo. Spesso queste intuizioni innescano la serie successiva di domande e il ciclo ricomincia.
A un livello più alto, hai fatto il lavoro. Hai condotto l'esperimento, hai raccolto i dati, li hai elaborati, hai eseguito l'analisi e, congratulazioni, hai raggiunto un'intuizione. Ora, naturalmente, vuoi condividere ciò che hai scoperto. Qual è il passo successivo? Prendi il tuo fidato PowerPoint, copi i grafici, magari aggiungi una o due caselle di testo e poi presenti il tutto in una riunione. In quel momento, hai raggiunto il tuo obiettivo. Hai generato dati che supportano una decisione.
Ma ecco la domanda su cui dovremmo soffermarci. A quale costo? Quanto tempo ci è voluto per mettere in forma i dati? Quanti passaggi manuali sono stati necessari? Quante volte avete dovuto riesportare, riformattare o aggiornare quando qualcosa cambiava? Questo è ciò che chiamo la tassa nascosta sulla comprensione. Il sovraccarico del passaggio dai dati grezzi alla decisione.
Perché in realtà, i dati generati non confluiscono in modo ordinato in JMP o in qualsiasi altro sistema. Il più delle volte sono grezzi, frammentati e incoerenti. Ciò significa che tu o il tuo team finite per passare ore a individuare, pulire, strutturare e manipolare manualmente quei dati prima ancora di poter iniziare ad analizzarli.
Una volta ottenuta una tabella utilizzabile, cosa succede dopo? Forse è necessario aggiungere calcoli. Forse si creano alcune colonne derivate. JMP è ottimo per questo. Ma a volte si ricorre a Excel perché sembra più semplice. Questo richiede un notevole investimento di tempo, soprattutto nei casi in cui l'analisi viene creata da zero, anche per esperimenti che producono lo stesso risultato.
Ma ecco la trappola. Anche con processi standardizzati, tutto è statico. È congelato. Hai fatto il lavoro, ma all'esperimento successivo devi ricominciare tutto da capo. Questo è il peso. Intuizioni raggiunte una volta, ma con un grande sforzo manuale e senza un modo semplice per aggiornarle o riutilizzarle.
Cosa succede quando si cerca di crescere? Pensatela in questo modo. Non ci aspettiamo che gli ingegneri dei dati comprendano la scienza per gestire i dati. È logico che non dovremmo aspettarci che gli scienziati diventino ingegneri dei dati per gestire la scienza. La loro competenza risiede nella sperimentazione, nella scoperta e nell'interpretazione. È lì che il loro tempo è più prezioso. Più tempo passano a pulire fogli di calcolo o a lottare con i formati, meno tempo dedicano alla scienza vera e propria. La scalabilità riguarda i sistemi che crescono senza cedere sotto il peso di più persone, più dati o più complessità.
Prendiamo il percorso di un'intuizione e applichiamolo a un team che genera dati. Nel momento in cui si aggiungono più persone al processo, si introduce una sfida completamente nuova: la variabilità. Persone diverse hanno diversi livelli di competenza nell'elaborazione dei dati, diverse abitudini e diversi modi di formattare o strutturare i risultati. Più ci si avvicina ai dati grezzi, maggiore è la variabilità.
E non finisce qui. Questa variazione si estende fino all'analisi e alla reportistica. Il risultato è che la condivisione dei dati non è immediata e le analisi non sempre sono coerenti. E le presentazioni? Beh, possono trasformarsi in un'avventura del tipo: "Cosa significa quel grafico?". "Oh, quello? Mi piace il formato di questo o quello, quindi ho copiato il suo stile".
Cosa succede? I team dedicano enormi quantità di tempo, inosservate, solo ad allineare le posizioni di archiviazione, le definizioni delle colonne, a ripulire, formattare e garantire la continuità. Questo sforzo nascosto continua a moltiplicarsi con la quantità di dati generati. Se questo è il quadro generale di un singolo team, immagina di estenderlo a un intero reparto.
Ci sono numerosi team che generano dati, ognuno con il proprio approccio. Improvvisamente, si sprecano innumerevoli ore solo a manipolare quei dati, cercando di dar loro forma. Ma il problema più grande è ancora la variabilità. Diverse interpretazioni, diverse analisi, diverse matematiche, diversi formati di output. Tutte queste differenze intaccano l'efficienza.
E su larga scala? Questo non solo rallenta i singoli progetti, ma può anche bloccare il progresso complessivo. Questo è il vero peso organizzativo. Quando ogni team reinventa la ruota, le intuizioni diventano incoerenti, l'allineamento richiede più tempo e lo slancio si perde. La sfida e l'opportunità sono costruire sistemi che consentano a ciascun gruppo di concentrarsi su ciò che sa fare meglio, continuando a lavorare insieme in modo fluido.
In IDEXX abbiamo riconosciuto questa sfida e stiamo lavorando per ricostruire il rapporto che le nostre persone hanno con i dati. Abbiamo riorganizzato i nostri sistemi, i nostri team e i nostri processi, in modo che, invece di lottare con i dati, le persone possano concentrarsi sul loro utilizzo. Ciò significa definire chiaramente il lavoro, creare automazioni utili e creare un accesso "no code" o "low code" ai sistemi big data che stiamo implementando. Perché diventare un'organizzazione basata sui dati non è solo una questione di tecnologia. Si tratta di capire dove risiedono realmente i problemi e gli sprechi. Si tratta di sapere cosa si può realisticamente insegnare alle persone e cosa è meglio risolvere con la tecnologia.
Combinando i punti di forza del nostro personale con quelli degli strumenti giusti, AWS, Snowflake e JMP, stiamo rimuovendo gli ostacoli alla comprensione e consentendo ai team di procedere più rapidamente, con coerenza e sicurezza.
Ecco il punto. Nell'attuale panorama della ricerca e sviluppo, i sistemi scalabili non sono più un optional. Il ritmo della scienza è più veloce che mai. Il volume di dati che generiamo continua a crescere. Se i nostri sistemi non sono scalabili, non riescono a tenere il passo. Ci ritroviamo con colli di bottiglia, incoerenze e spreco di energie. La scalabilità è ciò che ci permette di trasformare la scienza in soluzioni in tempi rapidi. È la differenza tra passare settimane a gestire i dati ed essere in grado di prendere decisioni in tempo reale. Ecco perché ripensare il nostro approccio ai dati è così fondamentale. Perché velocità, coerenza e fiducia nelle nostre intuizioni si traducono direttamente in progresso nella ricerca e sviluppo.
Nei prossimi minuti esploreremo i dettagli di alto livello del processo di architettura delle soluzioni dati, che si basa su due categorie principali. La prima categoria è Data Routing e Ingestion, dove i dati grezzi vengono raccolti, migrati e gestiti. La seconda categoria è Data Lakehouse e Analytics, dove risiede la nostra architettura dati e analitica.
Nel nostro ambiente di ricerca e sviluppo, i dati possono provenire da più fonti. Alcuni vengono raccolti manualmente dagli scienziati, mentre altri vengono generati automaticamente da strumenti e macchine durante gli esperimenti. Una volta che i dati sono disponibili, interviene il nostro servizio di migrazione cloud. Controlla costantemente le directory designate per individuare nuovi file e, quando li rileva, sposta automaticamente i dati nello storage AWS. Questo garantisce che tutti i dati in arrivo vengano acquisiti in un luogo centralizzato e sicuro, pronti per l'elaborazione e l'analisi a valle.
Una volta migrati su AWS, i dati entrano nel livello di Architettura Dati. Qui, tutti i file vengono raccolti e archiviati in modo sicuro, offrendoci un archivio di dati grezzi scalabile e affidabile. Da lì, i dati vengono acquisiti in Snowflake tramite notifiche SNS e Snowpipes, consentendo il trasferimento in tempo reale da AWS alla nostra piattaforma dati.
All'interno di Snowflake, i processi ETL automatizzati puliscono, normalizzano e trasformano i dati grezzi in modelli standardizzati, rendendoli pronti per l'analisi. Sfruttiamo anche le funzionalità avanzate di Snowflake, come viste e tabelle dinamiche, che consentono ad analisti e scienziati di interrogare e combinare più fonti dati in modo fluido, fornendo una base coerente ed efficiente per l'analisi a valle in JMP Live.
Infine, raggiungiamo il livello di Architettura Analitica. È qui che i modelli di dati standardizzati di Snowflake vengono trasformati in viste di dati fruibili, progettate per supportare specifici casi d'uso aziendali e scientifici. Forniamo punti di accesso curati, personalizzati in base alle esigenze dei diversi stakeholder e ai loro flussi di lavoro analitici, in modo che gli utenti possano concentrarsi sulle informazioni piuttosto che sulla gestione dei dati.
In sostanza, questo livello colma il divario tra dati grezzi e processo decisionale, allineando le strutture dei dati con la reportistica, la visualizzazione e gli obiettivi aziendali generali. È il passaggio che trasforma i dati strutturati in informazioni significative in tempo reale in JMP Live.
Ad alto livello, tutto inizia con la generazione dei dati e la creazione di un pacchetto dati. Una volta creati i dati, il nostro servizio di migrazione cloud monitora costantemente le directory pertinenti e sposta i nuovi file nello storage AWS. Successivamente, entra in gioco il livello di architettura dei dati. Da qui, i dati vengono acquisiti da AWS a Snowflake tramite notifiche SNS e Snowpipe.
Nel livello di architettura analitica, trasformiamo i dati grezzi in modelli standardizzati e quindi in visualizzazioni di dati fruibili che supportano specifici casi d'uso scientifici.
Infine, la pubblicazione di report e dati su JMP Live consente l'automazione self-service. In breve, questo flusso dalla generazione dei dati all'architettura fino all'analisi trasforma i dati sperimentali grezzi in informazioni utili per le decisioni.
Ora vorrei fermarmi un attimo. Tutti i diagrammi di architettura e i diagrammi di flusso che abbiamo visto sono importanti. Dimostrano che il sistema funziona. Non dimostrano di per sé il suo valore. Il vero valore si ottiene quando le persone che utilizzano il sistema, i nostri scienziati, possono immediatamente vedere le informazioni di cui hanno bisogno per prendere decisioni.
Quando uno scienziato dice: "È esattamente ciò di cui ho bisogno", è il momento in cui il sistema ha prodotto un impatto reale. Ed è proprio questo che esploreremo in seguito. I casi d'uso tangibili e gli impatti misurabili che mostrano come questa architettura si traduca in risultati per la ricerca e sviluppo.
Per preparare il terreno, disponiamo di un lettore di micropiastre che produce un file di registro con due varianti, come potete vedere qui. Durante un ciclo di calibrazione e controllo, gli strumenti generano questi file di registro. Questi contengono importanti risultati di calibrazione e controllo, integrati in tabelle direttamente all'interno del file.
Un team del Dipartimento di Ingegneria Civile (MPD) si interessò molto a questi dati e creò un processo di reportistica che monitorava lo stato di salute delle apparecchiature in base ai risultati di queste analisi. Come per la maggior parte delle cose, non si limitarono a raccoglierli dai laboratori di ricerca e sviluppo, ma iniziarono anche a estrarli direttamente dal campo. Ecco il problema. Tutto questo veniva fatto manualmente. Quella che era iniziata come una semplice curiosità si trasformò gradualmente in un processo ripetitivo e dispendioso in termini di tempo.
Ogni mese, i team raccoglievano centinaia di file di registro, copiando e incollando manualmente i dati in tabelle inutili e generando report. Era uno sforzo enorme, ripetuto mese dopo mese. Un perfetto esempio di come un'attività di alto valore venga appesantita dal lavoro manuale.
Lavorando a stretto contatto con questo team, abbiamo creato una pipeline di dati DSA per automatizzare l'intero processo. Invece di raccogliere manualmente i file, abbiamo iniziato ad acquisirli a livello di codice non appena venivano creati e li abbiamo distribuiti nello storage AWS. Una volta in Snowflake, i dati sono stati ulteriormente elaborati, ripuliti e standardizzati. Da lì, abbiamo creato viste che fungevano da punti di accesso per i report JMP Live, come mostrato nello screenshot. Il risultato è una tabella centralizzata ben organizzata che trasforma quelli che un tempo erano dati manuali disordinati in una risorsa strutturata e affidabile che gli scienziati possono utilizzare immediatamente per l'analisi e il processo decisionale.
Ora, il report in JMP Live si aggiorna automaticamente ogni volta che viene completata una nuova calibrazione o un nuovo controllo. Gli strumenti sono raggruppati per ID e posizione e ogni evento di calibrazione o controllo è chiaramente tracciato per data. Questo fornisce visibilità in tempo reale sullo stato del sistema, aiutando le operazioni di R&S e i laboratori di riferimento a individuare potenziali problemi di manutenzione prima che diventino problemi. In altre parole, non solo abbiamo eliminato il lavoro manuale ripetitivo, ma abbiamo anche creato un report interdipartimentale. Un unico punto di riferimento su cui tutti fanno affidamento per dati accurati e aggiornati.
Un tempo un processo manuale dispendioso in termini di tempo, ora è completamente automatizzato. Ogni fase del flusso di lavoro, dalla generazione dei dati all'aggiornamento dei report, viene completata entro circa 20 minuti dalla fine dell'evento. Questa rapidità di esecuzione garantisce al team una visibilità in tempo reale dei dati, consentendo un processo decisionale più rapido e una gestione più proattiva degli esperimenti e dello stato di salute degli strumenti.
Ma il sistema non è prezioso solo perché esiste, è prezioso perché cambia il modo in cui gli scienziati interagiscono con i dati. Quando smettono di chiedersi come siano arrivati questi dati e iniziano a chiedersi cosa significano? Questa è la prova che abbiamo prodotto un valore reale e fruibile. In diverse aree, abbiamo trasformato processi manuali che richiedevano molto tempo in flussi di lavoro automatizzati in tempo reale.
Nel monitoraggio sul campo della calibrazione e del controllo, un tempo un singolo scienziato raccoglieva dati da centinaia di strumenti. Ora, la raccolta automatizzata a livello di rete offre visibilità in tempo reale sullo stato di salute del sistema. Per l'accesso ai dati sul mercato e la piattaforma NPD, il personale di R&S in precedenza elaborava manualmente i dati dei test su micropiastra. L'automazione ora fornisce set di dati pronti per l'analisi entro pochi minuti dalla lettura della piastra, accelerando il processo decisionale.
Nello sviluppo di nuovi strumenti e materiali di consumo, eliminiamo la necessità della prevista raccolta manuale dei dati mediante l'implementazione di un'acquisizione automatizzata, che consente ai team di accedere ai risultati quasi istantaneamente dopo l'esecuzione.
Infine, nella produzione di dati SPC, le analisi lente e ripetitive sono state sostituite da grafici SPC in tempo reale accessibili 24 ore su 24, 7 giorni su 7 tramite i dashboard JMP Live, consentendo decisioni più rapide basate sui dati tra i team.
Quali sono i principali vantaggi? I dati grezzi degli strumenti vengono automaticamente acquisiti dai laboratori in AWS e Snowflake. Questo riduce i ritardi e garantisce che gli scienziati lavorino con set di dati completi e accurati fin dall'inizio. Snowflake fornisce un'unica piattaforma sicura per archiviare e strutturare tutti i dati sperimentali. Niente più silos o fogli di calcolo frammentati, solo dati puliti e pronti per le query, accessibili a tutti i team. Con JMP e JMP Live, gli scienziati possono creare dashboard e analisi riutilizzabili che si aggiornano automaticamente con nuovi dati, risparmiando ore di lavoro manuale e supportando un monitoraggio continuo.
Le dashboard si aggiornano man mano che gli esperimenti vengono completati, fornendo ai decisori informazioni in tempo reale su progressi, risultati e tendenze emergenti. Niente più attese per report statici.
I risultati possono essere condivisi facilmente tra le attività di R&S, il controllo qualità, la produzione e la dirigenza, contribuendo ad allineare le priorità e ad accelerare lo sviluppo dei prodotti. Nel complesso, questo sistema trasforma il modo in cui i team accedono, analizzano e agiscono sui dati, trasformando i risultati sperimentali grezzi in informazioni tempestive e fruibili che guidano l'innovazione.
Come abbiamo visto oggi, il passaggio dai dati sperimentali grezzi alle informazioni fruibili non deve essere lento o manuale. Combinando AWS, Snowflake e JMP Live, abbiamo creato un sistema che acquisisce, struttura e analizza i dati automaticamente, trasformando quello che un tempo era un lavoro noioso in informazioni affidabili in tempo reale.
Abbiamo dimostrato diversi impatti chiave. Accesso più rapido a dati di alta qualità, un'architettura scalabile e centralizzata, analisi ripetibili e automatizzate, supporto decisionale in tempo reale e visibilità interfunzionale che favorisce la collaborazione. La vera misura del successo è l'esperienza utente. Gli scienziati non si chiedono più come i dati siano arrivati lì, ma cosa significhino.
Questo passaggio da una domanda di processo a domande di insight è la prova definitiva che il sistema genera valore. In prospettiva, questo approccio fornisce le basi per un'innovazione continua. I team possono dedicare meno tempo alla gestione dei dati e più tempo a utilizzarli per risolvere problemi, prendere decisioni e accelerare lo sviluppo dei prodotti.
Grazie per il tempo che mi hai dedicato oggi. Spero che questo ti abbia fornito un quadro chiaro di come l'analisi automatizzata e scalabile possa trasformare un'organizzazione.
