Il settore ICT è composto da lavoro che si presta facilmente a essere suddiviso in passaggi ripetibili e da lavoro che invece non si presta a questo. Scrivere codice, testare, documentare, gestire i ticket, valutare il monitoraggio, distribuire configurazioni: molti di questi compiti hanno una struttura fissa e un criterio di valutazione chiaro. Oltre a questo, c'è lavoro che riguarda scelte architetturali, contesto del cliente, valutazioni di sicurezza e la decisione su quando un sistema può o non può andare in produzione. Questa distinzione determina dove l'AI oggi già assume compiti, dove resta necessario il controllo, e dove il lavoro umano rimane il nucleo della questione.
Le circostanze che determinano il risultato non sono uniformi. Un team che lavora con una codebase ben documentata e standard di test chiari può trasferire compiti più facilmente di un team che si basa su conoscenza tribale e accordi verbali. Un'organizzazione con una struttura di revisione stabile può integrare il controllo sull'output dell'AI in un processo esistente; un'organizzazione senza questa struttura deve prima costruirla prima che il trasferimento sia responsabile.
In parti del settore il cambiamento è già visibile. I suggerimenti di codice, la generazione di test e gli aggiornamenti della documentazione vengono in alcuni team prodotti in gran parte dall'AI, con uno sviluppatore che approva o rifiuta in base a funzionalità e leggibilità. In altri team esattamente lo stesso lavoro avviene ancora completamente a mano, non perché lì la situazione sia diversa in linea di principio, ma perché mancano le condizioni: nessun accesso agli strumenti giusti, nessun criterio di qualità definito, nessun tempo riservato per ristrutturare il processo.
Questa differenza tra aziende raramente riguarda la tecnologia in sé. Riguarda la prontezza: l'organizzazione ha dati e documentazione in ordine, è stato assegnato un diritto decisionale su chi valuta l'output dell'AI, è stata liberata capacità per impostare il nuovo processo prima di smantellare il vecchio. Dove queste condizioni mancano, un'ambizione resta sulla carta, anche se la tecnologia è già disponibile.
Un'ambizione come "l'AI supporta i nostri sviluppatori" suona univoca, ma richiede nella pratica una serie di capability che non sono presenti automaticamente: un ambiente di test in grado di validare codice generato dall'AI, un processo di revisione che non subisca ritardi per il volume aggiuntivo, e valutatori che sappiano su quale base rifiutare una proposta dell'AI. Senza queste capability, l'ambizione resta un'intenzione senza esecuzione.
È esattamente per questo che le stesse parole possono significare cose diverse in un team dirigenziale. Il CTO pensa a pipeline automatizzate, il direttore operativo a meno ore liberate per il supporto, il responsabile HR a una diversa composizione dei ruoli. Nessuna di queste interpretazioni è errata, ma senza una verifica condivisa l'ambizione resta vaga. Come si traduce una visione in qualcosa di misurabile, e non in tre ipotesi separate, è descritto in come si rende misurabile una visione.
Il settore ICT non è unico nel confrontarsi con questo cambiamento, anche se i punti critici differiscono. Nel settore dei servizi finanziari la domanda si pone diversamente, perché lì controllo e responsabilità hanno un ruolo maggiore; ciò che vi accade è descritto in quali ambizioni AI emergono nel settore dei servizi finanziari. Nel settore delle costruzioni, il lavoro fisico è un fattore fisso che limita l'adozione dell'AI in modo diverso rispetto all'ICT, come si legge in quali ambizioni AI emergono nel settore delle costruzioni. E nel settore delle pulizie si tratta soprattutto di pianificazione e controllo qualità invece che di produzione di codice, approfondito in quali ambizioni AI emergono nel settore delle pulizie. Il modello è sempre lo stesso: l'ambizione diventa concreta solo quando è chiaro quali capability mancano.
Un team dirigenziale che decide che l'AI deve assumere "la maggior parte del ciclo di revisione" formula così un'ambizione che non è realizzabile in un trimestre. Questo non è un'obiezione contro l'ambizione in sé, ma un segnale per suddividerla in fasi: quale capability deve essere prima in atto, quale dopo, e in quale punto l'organizzazione è per la prima volta in grado di valutare se funziona. Come può presentarsi questa suddivisione in fasi è descritto in come si suddivide in fasi un'ambizione troppo grande per un anno.
Sulle decisioni relative al personale che possono derivare da una tale suddivisione in fasi non ci esprimiamo: quale lavoro un datore di lavoro elimina o ridistribuisce rientra nei propri requisiti legali e nella propria valutazione. Ciò che descriviamo è quale lavoro si può trasferire, in parte o del tutto, e a quali condizioni.
La domanda di fondo non è se le ambizioni AI nel settore ICT siano realistiche, ma se questa specifica azienda, con questa codebase, questo team e questi processi, sia pronta a realizzarle. A quale lavoro in questa azienda l'AI possa effettivamente subentrare, compito per compito, si risponde con la scansione del lavoro di FTE TO AI.
Chi desidera prima farsi un'idea, senza impegno, può eseguire il test di prontezza gratuito: otto brevi domande, una per dimensione, con un quadro di dove l'organizzazione è più avanti e dove lo è meno. Il test completo dell'ambizione, con tutti i quattro livelli e i cinque confidence gate, è in fase di sviluppo.
Vertel wat u wilt bereiken, dan kijken we samen wat daarvoor moet staan.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.