Dashboard e analisi di localizzazione: KPI operativi dai dati di posizione, nello strumento BI che già usiHai i dati di posizione, ma nessun KPI su cui qualcuno agisce?
I sistemi di localizzazione producono un flusso continuo di eventi di posizione. Il valore sta in un piccolo insieme di KPI operativi che le persone consultano e su cui agiscono. Definiamo questi KPI insieme a te, normalizziamo i dati degli eventi della tua piattaforma RTLS, RFID o IoT e li portiamo nello strumento BI che la tua azienda già usa. Consulenza indipendente. Nessuna vendita di hardware, nessuna commissione dai fornitori.
Cosa dovrebbe mostrare una dashboard di localizzazione
Le poche misure che cambiano una decisione in reparto, in corsia o sul piazzale, non un puntino che si muove su una mappa. Quali contino dipende dall'attività, ma la maggior parte dei programmi attinge alle stesse sei famiglie:
| KPI | La domanda a cui risponde | Basato su |
|---|---|---|
| Utilizzo | Per quanto tempo asset, veicoli, locali o postazioni sono effettivamente in uso, e dove si nasconde la capacità inutilizzata? | Presenza nelle zone e stati di movimento o di utilizzo, confrontati con turni e calendari |
| Tempo di permanenza | Quanto tempo attendono articoli, ordini, pazienti o rimorchi in ciascuna zona o fase del processo e dove si accumula l'attesa? | Eventi di ingresso e uscita dalle zone, collegati ai record di ordini, lavorazioni o visite |
| Flusso e colli di bottiglia | Quali percorsi, transizioni e passaggi di consegne rallentano il processo e quando? | Passaggi da zona a zona, conteggi dei percorsi e lunghezza delle code nel tempo |
| Tempo di ricerca | Quanto tempo passano le persone a cercare utensili, carrelli, attrezzature o scorte che il sistema potrebbe localizzare? | Ultima posizione nota e richieste di ricerca, confrontate con una situazione di partenza misurata prima del go-live |
| Eventi di sicurezza e geofence | Dove e quando persone e veicoli entrano nelle zone riservate, e cosa è successo dopo? | Violazioni dei geofence, eventi di prossimità e conferme degli allarmi |
| Catena del freddo e condizioni | Le merci sensibili alla temperatura sono rimaste entro i limiti in ogni zona e per quanto tempo sono state esposte? | Letture dei sensori collegate a posizione e custodia, con il tempo di escursione per zona |
Ogni KPI dovrebbe avere un responsabile designato e una decisione esplicita che supporta. Se nessuno sa dire cosa farebbe di diverso quando un valore cambia, quel KPI non va nella dashboard.
Dagli eventi di posizione al tuo strumento BI
I dati di posizione grezzi sono rumorosi, specifici del fornitore e troppo granulari per il reporting. È nel lavoro tra il sistema radio e il report che la maggior parte dei progetti di dashboard riesce o fallisce.
- Acquisizione: estrarre gli eventi dalla piattaforma di localizzazione tramite l'API del fornitore, un flusso di messaggi o webhook, oppure tramite un middleware o una piattaforma IoT che già aggrega più sistemi.
- Normalizzazione: mappare ogni sorgente in un unico schema di eventi (cosa, dove, quando, con quale affidabilità), tradurre i nomi delle zone del fornitore nella gerarchia del tuo sito, eliminare duplicati e jitter e allineare gli orologi con i tuoi sistemi aziendali.
- Derivazione: trasformare le posizioni in business event come ingresso e uscita dalle zone, permanenza, passaggi e stati di utilizzo, poi collegarli a ordini, lavorazioni, ordini di lavoro o visite dei pazienti provenienti da WMS, MES, ERP o EMR.
- Consegna: inviare gli eventi in streaming per avvisi e viste in tempo reale, oppure caricarli in modo pianificato nel tuo data warehouse o lakehouse per il reporting. Molti siti hanno bisogno di entrambi, alimentati dallo stesso modello.
Per i sistemi dall'altra parte dell'integrazione, consulta la pagina sulle integrazioni. Per la progettazione e lo sviluppo della pipeline di dati, vedi sviluppo e integrazione.
Perché contano le dashboard indipendenti
La tecnologia di localizzazione cambia più in fretta del reporting. Un sito può partire con portali RFID, aggiungere UWB per i veicoli e BLE per le persone, poi sostituirne uno dopo qualche anno. Se ogni report è costruito sulle strutture dati di un solo fornitore, ciascuno di questi cambiamenti significa rifare i report e perdere uno storico confrontabile.
- Cambia il livello radio, tieni i report: un nuovo sistema richiede un nuovo connettore verso il modello dati, non un nuovo set di dashboard.
- Più tecnologie, un'unica vista: letture RFID, posizioni RTLS e letture dei sensori confluiscono nello stesso schema, quindi un KPI può attingere a tutte.
- Le tue definizioni, non quelle del fornitore: utilizzo e permanenza vengono calcolati come li definisce la tua organizzazione, e la logica è documentata.
- I tuoi dati, il tuo storico: lo storico degli eventi risiede nella tua piattaforma e resta utilizzabile anche dopo la fine di un contratto.
Cosa consegniamo
| Deliverable | Che cosa ottieni | Perché è importante |
|---|---|---|
| 1 · Workshop sulla definizione dei KPI | Un elenco breve e condiviso di KPI, ciascuno con definizione scritta, responsabile, destinatari, frequenza di aggiornamento e decisione che supporta | Evita che il progetto si trasformi in un muro di grafici su cui nessuno agisce |
| 2 · Modello dati | Uno schema di eventi e una gerarchia del sito indipendenti (sito, edificio, zona, tipo di asset), tabelle derivate per permanenza, passaggi e utilizzo e regole di qualità dei dati | Il livello che resiste a un cambio di fornitore radio o di strumento BI |
| 3 · Sviluppo o specifica delle dashboard | Dashboard sviluppate nel tuo strumento BI, oppure una specifica dettagliata con mock-up e logica delle metriche che il tuo team BI potrà sviluppare | Si adatta alle tue licenze, al tuo modello di sicurezza e alle competenze interne |
| 4 · Passaggio di consegne | Documentazione di sorgenti, trasformazioni e logica delle metriche, una sessione guidata per i responsabili dei report e un elenco dei limiti noti di qualità dei dati | Il tuo team può gestire, modificare e fidarsi dei numeri senza di noi |
Lavoriamo insieme ai tuoi team BI, dati e OT, non scavalcandoli. Se il tuo team preferisce sviluppare in autonomia, ci fermiamo al modello dati e alla specifica e verifichiamo il risultato.
Piattaforme BI in cui i nostri consulenti hanno realizzato dashboard di localizzazione
I nostri consulenti hanno realizzato dashboard di localizzazione in ciascuna delle piattaforme seguenti, anche in ruoli precedenti. Si tratta di esperienza personale di realizzazione. Non è un elenco di progetti di clienti TRACIO, e TRACIO non è partner né rivenditore di nessuno di questi fornitori.
- Microsoft Power BI
- Tableau
- Grafana
- Qlik
- Looker / Looker Studio
- Reporting in Excel / SharePoint
Se la tua organizzazione usa un altro strumento di reporting, l'approccio è lo stesso: il modello dati e le definizioni dei KPI restano validi e lo sviluppo segue le convenzioni della tua piattaforma.
Che cosa non facciamo
- Non vendiamo hardware, quindi la nostra consulenza resta indipendente.
- Non vincoliamo le dashboard a un ambiente ospitato da TRACIO. Vengono sviluppate nel tuo tenant oppure specificate perché le sviluppi il tuo team.
- Non pubblichiamo valori dei KPI prima di averli verificati sui tuoi dati. Quando la qualità dei dati di posizione non è sufficiente per il reporting, lo diciamo e risolviamo prima quel problema.
Incarico e compensi
Il lavoro sulle dashboard viene definito e prezzato in anticipo, come servizio a sé o all'interno di un programma più ampio. Consulta Come lavoriamo e compensi per le modalità di incarico, oppure prenota una call conoscitiva gratuita per parlare delle tue sorgenti dati e del tuo stack di reporting.
Domande frequenti
In quale strumento BI conviene sviluppare le nostre dashboard di localizzazione?
Di solito in quello che la tua azienda già usa per il reporting, così i KPI di localizzazione stanno accanto ai numeri di produzione, magazzino o clinici di cui le persone già si fidano. I nostri consulenti hanno realizzato personalmente dashboard di localizzazione in Microsoft Power BI, Tableau, Grafana, Qlik, Looker / Looker Studio e reporting in Excel / SharePoint, anche in ruoli precedenti. Se non hai ancora uno standard, confrontiamo le opzioni in base ai tuoi utenti, alla piattaforma dati e alle licenze prima di sviluppare qualsiasi cosa.
Perché non usare semplicemente la dashboard del fornitore RTLS?
La console del fornitore è il posto giusto per monitorare il sistema di localizzazione in sé: tag, anchor, batterie e copertura. È meno adatta ai KPI di business. Mostra i dati di un solo fornitore, definisce le metriche a modo suo e raramente si collega in modo pulito ai record di WMS, MES, ERP o EMR. Di solito teniamo la console del fornitore per lo stato del sistema e sviluppiamo i KPI di business nel tuo strumento BI.
I dati di posizione dovrebbero arrivare al nostro strumento BI in streaming o in batch?
Dipende da quanto rapidamente qualcuno deve intervenire. Gli avvisi di geofence e sicurezza e le viste in tempo reale dell'area operativa richiedono lo streaming. Utilizzo, andamento della permanenza e revisioni settimanali delle operations funzionano bene con caricamenti batch pianificati nel tuo data warehouse. Molti siti usano entrambi: un percorso in streaming per gli avvisi e uno batch per il reporting, alimentati dallo stesso modello di eventi normalizzato.
Cosa succede alle nostre dashboard se cambiamo fornitore RTLS o RFID?
Se le dashboard sono costruite su un modello dati indipendente, sostituisci il connettore che mappa gli eventi del nuovo sistema in quel modello, poi riconvalidi i numeri. Definizioni dei KPI, report e storico restano. È il motivo principale per cui separiamo il livello radio dal livello di reporting.
Vendete licenze BI o una piattaforma di analisi TRACIO?
No. Dashboard e modelli dati vengono sviluppati nel tuo ambiente, oppure specificati perché li sviluppi il tuo team, e al passaggio di consegne sono tuoi.
Ultimo aggiornamento: