Il monitoraggio e la segnalazione sono la promessa che un sistema osservi e segnali in tempo: una fattura anomala, un cliente che rischia di andarsene, un processo che si blocca. Sotto la finestra di chat o la dashboard in cui appare quel segnale, c'è una catena di scelte che l'organizzazione stessa deve fare. Quella catena determina se la segnalazione produce qualcosa oppure aggiunge soprattutto rumore.
Un segnale è una deviazione da un pattern. Per riconoscere un pattern, deve prima esistere una linea di base: dati su come vanno le cose normalmente, raccolti in modo confrontabile nel tempo. Questo richiede dati inseriti in modo coerente, negli stessi campi, con le stesse definizioni. Un'organizzazione in cui tre reparti hanno tre modi diversi di registrare un reclamo non ha ancora una linea di base — ne ha tre che non si collegano tra loro.
A questo si aggiunge: chi è responsabile della qualità di quei dati. Una segnalazione che si basa su dati che nessuno controlla, a un certo punto segnalerà qualcosa che non è corretto, e allora la domanda è chi lo nota e lo corregge. Senza responsabilità sulla fonte dei dati, un segnale è una scommessa con un timestamp.
Ogni sistema di segnalazione funziona con soglie: a partire da quale deviazione qualcosa diventa una segnalazione. Quella soglia non è un dettaglio tecnico ma una scelta di merito. Impostata troppo bassa, e tutti ricevono continuamente segnalazioni che non significano nulla, dopo di che nessuno le legge più. Impostata troppo alta, e il sistema rimane silenzioso mentre qualcosa sta già andando storto.
Impostare quella soglia richiede qualcuno che conosca il processo sottostante — non un'impostazione generica identica per ogni team. Una soglia per la segnalazione delle scorte in un magazzino è una questione diversa da una soglia per la segnalazione del turnover del personale. Questa è una delle dimensioni fondamentali: senza un'organizzazione che renda queste scelte esplicite e le documenti, è la tecnologia a impostare la soglia per voi, di solito con un valore standard che non si adatta bene a nessuno.
Un segnale che non arriva da nessuna parte non è un segnale. Questo richiede un percorso definito: chi riceve la segnalazione, entro quanto tempo viene esaminata e qual è il passo successivo se la segnalazione è corretta. Senza questo percorso, la segnalazione finisce in una casella di posta che nessuno considera come priorità, e il vantaggio della segnalazione precoce si perde nel ritardo del seguito.
Questo riguarda anche il modo in cui i reparti lavorano tra loro: un segnale su un cliente nasce spesso in un team e deve essere seguito da un altro. Il modo in cui il coordinamento tra i reparti si svolge nella vostra organizzazione determina se quel passaggio avviene senza intoppi o si blocca al confine tra due team che non sono abituati a condividere le stesse informazioni.
La segnalazione spesso non funziona su un unico flusso di dati strutturati, ma su una combinazione: numeri provenienti da un sistema, e testo proveniente da e-mail, verbali o report. Un sistema che deve segnalare sulla base di lettere di reclamo o verbali di riunione deve prima essere in grado di leggere e interpretare quei documenti. Il modo in cui la vostra organizzazione gestisce la lettura e la sintesi dei documenti determina quindi in parte se la segnalazione basata su fonti testuali è realizzabile, oppure richiede prima ancora lavoro a livello di gestione documentale.
Lo stesso vale per le conversazioni. Un segnale che nasce da qualcosa detto in una conversazione con un cliente esiste solo se quella conversazione è stata registrata in un modo che un sistema può consultare. Senza una struttura per registrare e seguire le conversazioni, quell'informazione resta nella testa di chi ha condotto la conversazione, e lì nessun sistema può segnalare nulla.
La segnalazione non è un'azione. Il sistema segnala che c'è qualcosa in corso; non interviene esso stesso. Chi si aspetta che un segnale porti automaticamente a una soluzione confonde la segnalazione con un altro tipo di lavoro: lavoro che viene assunto e svolto. Ciò che è possibile in questo ambito è descritto in agenti che svolgono lavoro — un livello diverso da quello di cui si parla qui.
Il monitoraggio viene spesso provato per primo, proprio perché sembra piccolo e circoscritto: una dashboard, un team, un processo. Questo carattere circoscritto è anche la trappola. Un sistema di segnalazione che funziona in un solo punto, ma non è collegato al resto dell'organizzazione, resta una curiosità invece di uno strumento. Il motivo per cui un pilota che funziona solo nel suo angolo non produce nulla è direttamente legato a questo schema: un segnale senza collegamento a un processo che ne fa qualcosa resta una demo. E una demo senza qualcuno che consideri il seguito come compito proprio scompare da sé; è anche il motivo per cui una demo senza un responsabile non produce nulla.
Se la vostra organizzazione è pronta per il monitoraggio e la segnalazione non dipende dalla tecnologia disponibile, ma dal fatto che la linea di base, le soglie, il percorso di follow-up e la responsabilità esistano già. È esattamente ciò che osserva la misurazione della maturità di hybridresourcing: non se è possibile, ma cosa deve esistere prima.
Il monitoraggio e la segnalazione vi dicono che c'è qualcosa in corso. Non vi dicono quale parte del lavoro sottostante — la valutazione, la rendicontazione, il follow-up — possa effettivamente essere assunta dall'AI. Quella domanda spetta alla scansione del lavoro di FTE TO AI, che calcola per ogni compito quale parte del lavoro è idonea a questo scopo, indipendentemente dal fatto che l'organizzazione sia già pronta o no.
Vraag maar wat er moet staan voordat AI in uw organisatie kan landen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.