C'è stato un pilota di successo. Il management vuole velocità. Si decide: estendere al resto dell'organizzazione, ad altri team, ad altri reparti. Ciò che funzionava in un angolo, ora deve funzionare ovunque.
Questo non va sempre bene. Non perché la tecnologia reagisca improvvisamente in modo diverso, ma perché l'ambiente in cui deve funzionare è organizzato diversamente ovunque. Il team in cui il pilota ha avuto successo aveva casualmente un'infrastruttura IT in grado di sostenere quanto richiesto, una gestione dei dati in ordine, e una struttura organizzativa in cui qualcuno si assumeva la responsabilità. In altre parti dell'organizzazione, una o più di queste condizioni sono diverse. Il risultato: lo stesso impegno produce qualcosa in un posto e nulla in un altro, o peggio, lavoro extra per correggere gli errori.
Scalare sembra il passo successivo perché il pilota ha dimostrato qualcosa. C'è un risultato, c'è entusiasmo, c'è pressione per aumentare il rendimento. Chi ha fatto funzionare qualcosa non vuole limitarlo a un solo team. Inoltre, scalare è visibile: più utenti, più team, più linee di processo che adottano il nuovo modo di lavorare. Questo sembra progresso, anche quando le dimensioni fondamentali — organizzazione, infrastruttura IT, gestione dei dati — non sono ancora ovunque al livello su cui la dimensione che ne dipende può effettivamente basarsi.
L'ordine in cui questo funziona non è opzionale. Se lo strato fondamentale non è a posto, lo strato dipendente non ha nulla su cui costruire. Non è una questione di preferenza o di prendersi più tempo; è il modo in cui le dimensioni si sostengono a vicenda. Scalare ignora questo ordine e presuppone che ripetere un modo di lavorare sia sufficiente, anche senza il terreno che, la prima volta, era presente per caso.
Ci sono alcuni segnali che si ripetono spesso. I team che adottano il nuovo modo di lavorare riportano risultati variabili, e nessuno riesce a spiegare bene perché funziona per un team e non per un altro. Si chiede più formazione o più comunicazione, mentre il problema sta altrove: in sistemi che non si collegano tra loro, in dati che non hanno la stessa qualità, in una struttura in cui nessuno è responsabile del risultato oltre i confini dei team.
Riconoscibile è anche la situazione in cui la tecnologia viene distribuita su una struttura che non è cambiata a sua volta: il nuovo modo di lavorare viene rese disponibile a livello tecnico, ma i ruoli, le responsabilità e le linee decisionali sono rimasti gli stessi di prima del pilota. Simile è lo schema in cui un pilota funziona bene nel proprio angolo ma non si collega al resto dell'organizzazione: l'espansione copia il modo di lavorare, non le condizioni in cui quel modo di lavorare è nato.
Un terzo segnale è meno visibile ma altrettanto determinante: due entusiasti tirano il carro e nessun altro si sente responsabile. Fino a quando l'iniziativa dipende da poche persone che sono casualmente motivate, non c'è una base organizzativa su cui scalare — c'è solo entusiasmo che non si moltiplica non appena il team diventa più grande.
Chi riconosce questi segnali farebbe bene a chiedersi se la dispersione tra i team sia il risultato dell'esecuzione, oppure di una differenza nella prontezza che era già presente ben prima che si iniziasse a scalare. Questa distinzione è esattamente ciò a cui guarda la misurazione della maturità di hybridresourcing: non un unico punteggio per l'intera organizzazione, ma cinque livelli su sette dimensioni, misurati facendo sì che più persone valutino separatamente e rendendo visibile la dispersione tra le loro risposte. Quella dispersione dice spesso più della media: se la valutazione del CEO differisce fondamentalmente da quella del CIO, lì si trova parte della spiegazione del perché scalare funziona in un posto e non in un altro. Ciò che un CEO in questa misurazione rivela sulla propria organizzazione e ciò che un COO riconosce in essa dalla prospettiva dell'esecuzione quotidiana raramente producono la stessa immagine, e questa differenza è esattamente ciò su cui è costruita la misurazione.
Questa pagina riguarda la domanda se l'organizzazione può sostenere l'AI: la struttura, l'infrastruttura, la gestione dei dati sono a un livello tale da rendere sensato scalare. Questa è una domanda diversa da quale parte del lavoro stesso sia adatta ad essere trasferita all'AI. Quest'ultima domanda trova risposta nella scansione del lavoro di FTE TO AI: essa calcola, per ogni attività, quale parte del lavoro può essere assunta dall'AI, indipendentemente dal fatto che l'organizzazione sia già pronta o no. Le due domande sono collegate, ma l'ordine non è arbitrario — sapere cosa è trasferibile ha poco valore fino a quando non è chiaro se le basi possano sostenere quel trasferimento.
La misurazione della maturità di hybridresourcing è ancora in fase di costruzione. Chi desidera utilizzare la misurazione non appena sarà disponibile può iscriversi alla lista d'attesa.
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.