Kennisbank

Monitoraggio e segnalazione: cosa succede sotto la finestra di chat

Monitoraggio e segnalazione suona come un cruscotto. In genere è qualcosa di diverso: un sistema che riceve continuamente dati, li confronta con un'aspettativa o un valore soglia, ed emette un segnale non appena qualcosa si discosta. Può trattarsi di una macchina che vibra diversamente dal normale, di una scorta che si esaurisce più rapidamente del previsto, di una rete in cui passa traffico inusuale, o di un processo con il cliente il cui tempo di attraversamento si allunga. La componente AI sta nel riconoscere schemi che con regole fisse non si riescono a catturare — non nel sostituire la persona che reagisce al segnale.

Cosa comporta concretamente

Un sistema di monitoraggio fornisce tre cose: una misurazione continua, una norma con cui questa misurazione viene confrontata, e un segnale quando la deviazione supera un certo limite. Cosa succede dopo dipende dall'impostazione. Nella forma più semplice, viene inviata una notifica a una persona, che valuta e agisce. In una forma più avanzata, il segnale avvia automaticamente un passo successivo — una notifica a un fornitore, un adeguamento in una pianificazione, il blocco di una transazione. Questa seconda forma tocca il territorio delle catene in cui i passaggi si susseguono: il monitoraggio diventa allora il punto di partenza di un processo che prosegue senza intervento, e questo richiede un tipo di fiducia diverso rispetto a una notifica che qualcuno può ancora ignorare.

La differenza tra queste due forme non è trascurabile. Un segnale che va a una persona può essere sbagliato senza causare subito danni — la persona filtra. Un segnale che innesca un'azione deve essere corretto, oppure l'organizzazione deve avere un modo per annullare l'azione. Molte organizzazioni iniziano quindi con la prima forma e passano alla seconda solo quando il segnale ha dimostrato la propria validità.

Cosa richiede questo all'organizzazione

Il monitoraggio e la segnalazione richiedono innanzitutto dati continui e affidabili. Un sistema che riceve ogni settimana un'esportazione da un altro sistema non può dare un segnale — può solo riportare a posteriori. Deve esserci un flusso: sensori, log, transazioni, eventi, che arrivano in continuazione e la cui qualità non varia in base a chi effettua l'inserimento.

Inoltre, richiede una norma. Una deviazione è una deviazione solo rispetto a qualcosa. Nelle macchine si tratta spesso di una specifica tecnica; nei processi si tratta più spesso di una media storica o di un valore obiettivo che qualcuno ha stabilito. Dove questa norma manca o è instabile — un processo in continuo cambiamento, un mercato che oscilla — il sistema emette troppi segnali oppure troppo pochi. Entrambe le situazioni minano la fiducia nel sistema.

In terzo luogo, richiede un percorso definito per ciò che accade con un segnale. Chi riceve la notifica, entro quale tempo viene valutata, qual è l'escalation se non si risponde. Senza questo percorso, un segnale finisce in una casella di posta che nessuno legge, e il sistema perde la sua funzione. Questo tocca la stessa questione riguardante le conversazioni che vengono registrate e seguite: registrare senza seguito produce solo un archivio, non un miglioramento.

Dove le cose vanno male

Il problema più comune è un sistema di monitoraggio che emette troppi segnali. Se ogni piccola deviazione genera una notifica, le persone imparano a ignorarla — l'effetto opposto a quello per cui il sistema è pensato. Impostare il valore soglia è quindi una valutazione continua tra troppo rumore e un allarme troppo tardivo, e questa valutazione cambia con l'arrivo di più dati.

Un secondo problema è che il segnale parte, ma nessuno è responsabile del seguito. Questo accade spesso quando il monitoraggio viene organizzato come un progetto IT senza coinvolgere il reparto che deve lavorare con i segnali. La tecnica funziona, l'organizzazione no.

Un terzo problema nasce quando il segnale richiede una decisione che in realtà è lavoro umano — questa deviazione è accettabile, bisogna chiamare il cliente, questo rischio vale l'interruzione. Dove questa valutazione diventa più complessa di quanto una regola fissa possa gestire, il monitoraggio si sposta verso il supporto decisionale, e si applicano altri requisiti di motivazione e spiegabilità rispetto a un semplice segnale soglia.

Dove questo si blocca

La maggior parte dei progetti di monitoraggio che non decollano si arena sul flusso di dati, non sul modello. Sensori che si guastano, log incoerenti, sistemi che non comunicano tra loro — non sono problemi di AI, sono problemi infrastrutturali che devono essere risolti prima. Anche il coordinamento gioca un ruolo: un segnale che nasce in un reparto deve spesso arrivare in un altro reparto per avere significato, e questo tocca la questione di come è organizzato il coordinamento tra reparti.

La domanda successiva

Questa pagina descrive cosa può offrire il monitoraggio e la segnalazione, e cosa deve avere in ordine l'organizzazione prima che funzioni. Un'altra domanda è quale parte del lavoro attorno a questi segnali — la valutazione, il seguito, l'escalation — possa effettivamente essere ripresa dall'AI. Questa è una domanda a livello di compito, e a questa risponde la scansione del lavoro di FTE TO AI: essa calcola per ogni compito quale parte del lavoro può essere ripresa, invece di farlo a livello di un intero processo o di un'intera funzione.