Risposta breve: Definisca prima la decisione che la direzione dovrà prendere; poi registri gli eventi da campo con identità univoca, momento e responsabile. Produca gli indicatori con granularità fissa, porta di qualità dei dati e approvazione umana.
Perché i dati da campo non sono direttamente un valore di indicatore?
Ogni riga di un modulo su tablet è un evento misurabile; ma da sola non è una risposta per la direzione. L'apertura dell'ordine di lavoro, l'inizio della visita sul campo, il completamento del punto di controllo, la conferma della non conformità e la pubblicazione del rapporto sono eventi operativi diversi. Riunirli in un unico campo «completato» confonde velocità e qualità, carico di lavoro ed esito.
La guida di Microsoft sullo schema star indica che le tabelle dei fatti conservano osservazioni o eventi, mentre le dimensioni forniscono filtraggio e raggruppamento. La stessa guida richiede esplicitamente che le tabelle dei fatti siano caricate con una granularità coerente. La conseguenza tecnica è netta: ordine di lavoro, visita, punto di controllo e rapporto non devono essere conteggiati come se fossero dello stesso tipo di riga.
Un buon indicatore dichiara prima quale decisione sostiene; poi quali eventi conteggia, in quale finestra temporale e con quale regola.
Primo passo: scegliere una sola domanda di gestione
La progettazione della dashboard non inizia con la scelta dei grafici. Prima si scrive la domanda decisionale: «In quale fase si accumulano i lavori in ritardo?», «Qual è la causa comune dei lavori che richiedono una nuova visita?» o «Perché la pubblicazione dei rapporti devia dalla data pianificata?». Ciascuna di queste domande richiede eventi, perimetro e responsabile diversi.
La sezione Measure 2.5 del NIST AI RMF Playbook affronta, nel contesto della validità di costrutto, la verifica che un indicatore misuri davvero il concetto che dichiara di misurare. La controposta nella progettazione Vizyon AI è non considerare vero di per sé l'esito prodotto dal modello o dalla regola. L'indicatore va presentato insieme ai record sorgente, alla regola di calcolo, al limite d'uso e alla revisione umana autorizzata.
Compili la scheda KPI prima di calcolarla
| Campo | Domanda da porre | Esempio |
|---|---|---|
| Decisione | Quale azione attiva questo indicatore? | Il responsabile della pianificazione modifica la distribuzione dei lavori. |
| Evento | Quale record si conta? | Visita sul campo chiusa da un utente autorizzato. |
| Granularità | Che cosa rappresenta una riga? | Una singola visita sul campo in un ordine di lavoro. |
| Tempo | Quale inizio, fine e fuso orario si usano? | Inizio pianificato e chiusura effettiva, ora di Istanbul. |
| Perimetro | Quali record sono inclusi o esclusi? | I lavori annullati sono riportati separatamente dal denominatore. |
| Proprietario | Chi approva definizione e soglia? | Responsabile operativo e titolare del dato. |
| Prova | A quali record si risale dal risultato? | Identificativi di ordine di lavoro, visita e storico delle operazioni. |
Costruisca il modello degli eventi su uno scheletro immutabile
Ogni evento da campo va conservato almeno con identità univoca dell'evento, identificativo dell'ordine di lavoro, tipo di evento, momento di verificarsi, momento di registrazione, ruolo responsabile, sorgente e storico degli stati. Se serve una correzione, invece di sovrascrivere silenziosamente l'evento precedente occorre creare un legame di nuova versione o correzione. Così si può spiegare perché un indicatore di gestione sia cambiato in seguito.
Il modello dati stabile delle metriche di OpenTelemetry tratta come concetti distinti l'evento al momento della registrazione, la serie temporale memorizzata e il flusso di metriche trasportato. Questa distinzione si applica anche alle operazioni sul campo: l'evento grezzo è la prova, la metrica è una vista calcolata con una finestra e un'unità definite, la dashboard è la presentazione per la decisione. Contatore, stato istantaneo e distribuzione delle durate non vanno usati come se fossero lo stesso numero.
Esegua la porta di qualità dei dati prima del calcolo dei KPI
Il dato mancante non è bassa performance; la sincronizzazione ritardata non è un ritardo operativo. ISO 8000-8:2015 definisce i concetti di qualità dell'informazione e dei dati e i prerequisiti per la misurazione nella gestione della qualità. La norma è stata pubblicata nel 2015 e la sua validità è stata confermata nel 2022. Questo riferimento sostiene l'istituzione, a monte di ogni indicatore, di una porta di qualità dei dati misurabile.
La documentazione di Microsoft Purview tratta la qualità dei dati in dimensioni distinte come accuratezza, completezza, conformità, coerenza, aggiornatezza e unicità. Invece di comprimere tutte queste dimensioni in un unico punteggio artificiale sullo schermo operativo, renda visibili quelle critiche per la decisione:
- Completezza: Presenza dei campi obbligatori da campo e dei legami probatori.
- Unicità: Che lo stesso evento non sia conteggiato due volte per sincronizzazione offline o nuovo tentativo.
- Coerenza: Che lo stato dell'ordine di lavoro non contraddica gli stati di visita e rapporto.
- Aggiornatezza: Il momento dell'ultimo flusso dati riuscito e la finestra di ritardo accettata.
Se la porta dati non è superata, Vizyon AI non deve presentare l'esito come un normale KPI; deve indicare il numero di record fuori perimetro, il momento dell'ultimo aggiornamento e l'esigenza di revisione. Così il dirigente può distinguere una cattiva operatività da una debole copertura dei dati.
Come va limitato il livello analitico Vizyon AI?
Vizyon AI può essere usato per individuare pattern sugli eventi operativi definiti, dare priorità alle eccezioni e ordinare le possibili cause per la revisione. Tuttavia la previsione o il suggerimento non sostituiscono la decisione di conformità né il rapporto pubblicato. In particolare, condizioni come campione ridotto, modulo da campo cambiato, nuova squadra o flusso dati ritardato vanno mostrate insieme all'esito.
Questo approccio è coerente con le funzioni di governance, mappatura, misurazione e gestione del NIST AI RMF 1.0. Nell'applicazione tecnica, per ogni output analitico si conserva questa traccia:
- La finestra dati e i filtri usati,
- La versione del dizionario degli indicatori,
- La versione del modello o della regola,
- Il momento di generazione del suggerimento,
- Il ruolo revisore e la decisione presa,
- La motivazione di una correzione successiva.
Per valutare ulteriormente i confini di compito tra intelligenza artificiale e approvazione umana, veda la guida su intelligenza artificiale e approvazione umana nei processi di ispezione Se occorre preservare le identità di integrazione, l'articolo sul trasferimento dati verso ERP e contabilità senza doppia registrazione completa lo scheletro tecnico.
Per la prima dashboard scelga un perimetro piccolo e verificabile
Nella prima versione, invece di trasferire l'intera operatività su un'unica schermata, scelga un ciclo di decisione. Ad esempio monitori insieme le visite pianificate e completate, le cause di attesa e la completezza dei dati. Verifichi che da ogni scheda si possa scendere all'ordine di lavoro sorgente e all'elenco degli eventi.
Checklist pre-pubblicazione
- Ogni KPI è collegato a una sola domanda di decisione?
- Numeratore, denominatore, finestra temporale, fuso orario ed esclusioni sono messi per iscritto?
- La granularità degli eventi è identica in tutti i periodi?
- Dati mancanti, duplicati e ritardati sono mostrati separatamente?
- L'utente può risalire dal totale al record sorgente?
- Il suggerimento AI è presentato con sorgente, limiti e avvertenze di affidabilità?
- L'approvazione tecnica e la decisione operativa restano a una persona autorizzata?
- Se definizione o modello cambiano, il risultato precedente è riproducibile?
Questo controllo trasforma la dashboard da report decorativo a strumento decisionale verificabile. Per valutare un modello dati e un flusso analitico su misura per il Suo ente, può esaminare le soluzioni di intelligenza artificiale VizyonTech oppure definire un perimetro pilota a partire dal Suo attuale processo sul campo.
Fonti
- NIST — Artificial Intelligence Risk Management Framework (AI RMF 1.0), 26 gennaio 2023.
- NIST AI Resource Center — AI RMF Playbook, versione completa 30 marzo 2023.
- ISO — ISO 8000-8:2015, Data quality — Concepts and measuring, novembre 2015; confermata nel 2022.
- OpenTelemetry — Metrics Data Model, documentazione aggiornata del modello stabile.
- Microsoft Learn — Understand star schema and the importance for Power BI, ultimo aggiornamento 30 dicembre 2024.
- Microsoft Learn — Data quality health report in Unified Catalog, documentazione aggiornata.