Un'applicazione AI che funziona all'interno di un solo team, raggiunge a un certo punto il confine di quel team. Un riepilogo creato dal marketing deve poter essere letto dalle vendite. Un segnale che nasce nel servizio clienti deve arrivare al prodotto. Non appena ciò accade, non è più una questione riguardante il modello o il prompt, ma riguarda il modo in cui i reparti interagiscono tra loro quando qualcosa che prima non esisteva si muove tra loro.
L'esperienza della finestra di chat dà l'impressione che l'AI sia qualcosa che una persona usa per svolgere un compito. Sotto quella finestra si trova una realtà diversa, soprattutto quando il lavoro si estende su più di un reparto. Chi imposta una catena in cui i passaggi si susseguono scopre che ogni passaggio di consegne tra reparti è un punto dove qualcosa può bloccarsi: un formato che non si adatta, una responsabilità che nessuno reclama, un sistema che un reparto ha e l'altro no.
Il coordinamento tra reparti richiede tre cose che non dipendono da quale modello viene utilizzato.
I reparti usano spesso le stesse parole per cose diverse. Un lead significa qualcosa di diverso per il marketing rispetto alle vendite. Un reclamo viene classificato diversamente dal servizio clienti rispetto al prodotto. Finché le applicazioni AI restano all'interno di un solo reparto, questa differenza non si nota. Non appena l'output di un reparto diventa input per un altro, la differenza diventa un guasto. Questo vale in particolare per il lavoro basato su testo e conversazione: chi legge e riassume documenti per un altro reparto, deve sapere quali termini hanno lì un significato diverso, e chi registra e segue le conversazioni deve sapere chi si occupa del seguito non appena la conversazione riguarda un altro reparto.
Un'applicazione che si ferma al confine di un team, resta all'interno del mandato di quel responsabile di team. Non appena l'applicazione attraversa più reparti, quel mandato non è più sufficiente. Deve esserci qualcuno che possa decidere al di sopra dei reparti: chi svolge quale passaggio, chi è responsabile se qualcosa va storto, chi decide se l'applicazione viene adattata. Senza questa persona, ogni reparto continua a indicare l'altro. Questo è uno dei motivi per cui una demo senza un responsabile non porta a nulla: una demo mostra che qualcosa può funzionare, ma non dice nulla su chi sorveglia la collaborazione tra reparti una volta che il lavoro reale inizia.
I reparti costruiscono di norma i propri sistemi, con proprie ipotesi su dove risiedono i dati e chi può accedervi. Il coordinamento tra reparti richiede che questi sistemi possano comunicare tra loro, o che ci sia uno strato intermedio in grado di farlo. Non è una questione di volontà; è una questione di ciò che già esiste. Un'organizzazione in cui ogni reparto ha costruito un proprio sistema separato ha un compito diverso rispetto a un'organizzazione con un unico fondamento condiviso. Questa differenza diventa visibile non appena il lavoro coinvolge agenti che eseguono effettivamente dei passaggi: cosa può fare con agenti che eseguono il lavoro dipende dal fatto che quell'agente abbia lo stesso accesso e le stesse regole nel reparto A come nel reparto B.
Un progetto pilota che opera nell'angolo di un solo team non mostra mai dove si blocca il coordinamento tra reparti, perché quel coordinamento non viene mai testato. Il pilota sembra riuscire, e la domanda su cosa succede quando viene collegato un secondo reparto resta senza risposta fino al momento in cui le cose vanno male. Chi vuole sapere se un pilota che funziona solo nel suo angolo porta a qualcosa, deve guardare proprio a quel passaggio di consegne: non a ciò che accade all'interno di un solo reparto, ma a ciò che accade nel momento in cui il lavoro lascia il reparto.
Il coordinamento tra reparti è uno strato dipendente. Funziona solo se le basi fondamentali sono a posto: un'organizzazione che sa chi è responsabile di cosa, un'infrastruttura IT in grado di collegare i reparti, e una gestione dei dati che garantisce che ciò che un reparto registra abbia significato per l'altro. Senza queste basi, ogni tentativo di coordinamento tra reparti è una riparazione a posteriori, e quella riparazione costa più tempo dell'applicazione stessa.
Se la sua organizzazione è pronta per il coordinamento tra reparti non è qualcosa che si può dedurre dall'applicazione stessa. Dipende da come è organizzata l'organizzazione, quali sistemi già comunicano tra loro, e se c'è qualcuno che può decidere oltre i confini di un reparto. La misurazione della maturità di hybridresourcing.com mette questo in evidenza: cinque livelli su sette dimensioni, con un ciclo di valutazione in cui più persone dell'organizzazione assegnano punteggi separatamente, in modo che la dispersione tra reparti diventi visibile prima che quella dispersione diventi un problema nella pratica. Lo strumento è in fase di sviluppo; chi desidera utilizzarlo può iscriversi alla lista d'attesa.
Questa pagina descrive cosa richiede il coordinamento tra reparti per poter essere sostenuto. Quale parte del lavoro stesso possa essere assunta dall'AI, per compito e per reparto, è una domanda diversa. Questo lo calcola la werkscan di FTE TO AI.
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.