Jason Wojahn, CEO di KMS Technology – Interviste

Jason Wojahn è CEO di KMS Technology e vanta circa tre decenni di esperienza nella creazione e nella crescita di aziende di servizi tecnologici per le imprese. Ha cofondato e diretto Thirdera prima della sua acquisizione da parte di Cognizant, in precedenza ha guidato l’attività globale di ServiceNow di Accenture e ha ricoperto ruoli dirigenziali presso Cloud Sherpas e IBM Global Services. Il suo lavoro si concentra sulla trasformazione delle imprese, sui modelli operativi e sulla conversione dei progressi nell’IA in risultati aziendali misurabili.

KMS Technology è un’azienda di ingegneria digitale, dati e IA che aiuta le organizzazioni a sviluppare software, modernizzare applicazioni, rafforzare le basi dei dati e portare l’IA in produzione. I suoi servizi comprendono consulenza tecnica, ingegneria del prodotto, ingegneria dei dati e automazione intelligente dei flussi di lavoro. In questa intervista, Wojahn parla di «economia dell’esecuzione», del divario tra progetti pilota di IA e produzione, dell’autorità decisionale degli agenti e di come le aziende possano misurare i progressi attraverso risultati end-to-end.

Hai trascorso tre decenni a creare e far crescere organizzazioni tecnologiche per le imprese, dalla crescita di Navigis e dalla guida dell’attività globale di ServiceNow di Accenture alla creazione di Thirdera e al tuo attuale ruolo di CEO di KMS Technology. In che modo queste esperienze hanno plasmato il tuo punto di vista sulla trasformazione delle imprese e cosa ti ha attratto della sfida di aiutare le organizzazioni a diventare native dell’IA?

Ho iniziato in IBM Global Services, gestendo la fornitura dei servizi per grandi clienti aziendali. Poi sono arrivati Navigis, Cloud Sherpas, Accenture, Thirdera e Cognizant: quasi tutta la mia carriera si è svolta nell’ecosistema ServiceNow.

Ecco lo schema che ho continuato a osservare. Ogni nuova ondata di piattaforme prometteva una trasformazione, ma raramente era la tecnologia a determinare chi avrebbe prevalso. A vincere erano le aziende che cambiavano il modo in cui il lavoro circolava davvero nell’organizzazione.

Gli anni in ServiceNow mi hanno insegnato che il valore risiede nei flussi di lavoro, non nelle dashboard. Per trent’anni, il software aziendale è diventato molto bravo a dirci cosa stava succedendo. È stato molto meno efficace nel fare qualcosa al riguardo. A colmare il divario erano le persone. Sono diventate il team di integrazione non retribuito, trasferendo il lavoro da un sistema all’altro.

L’IA cambia le cose. L’intelligenza sta diventando abbondante. Oggi ciò che scarseggia è la capacità di trasformarla in azioni coordinate. È questo che mi ha portato in KMS: la profonda competenza ingegneristica necessaria per creare sistemi che svolgano il lavoro, anziché limitarsi a monitorarlo, e l’opportunità di diventare nativi dell’IA, anziché semplicemente potenziati dall’IA.

Molte imprese hanno dimostrato con successo il potenziale dell’IA attraverso progetti pilota, ma faticano a trasformare questi primi risultati in valore su scala produttiva. Quali sono gli ostacoli più comuni che le organizzazioni incontrano quando passano dalla sperimentazione alle fasi successive e perché spesso queste difficoltà emergono solo dopo che la tecnologia ha dato prova della propria efficacia?

Un progetto pilota dimostra che il modello funziona. La produzione dimostra che funziona l’organizzazione.

Sono prove molto diverse. Un progetto pilota si basa su dati puliti e selezionati, uno sponsor motivato e un piccolo team che trova soluzioni per aggirare ogni lacuna. È progettato per evitare gli aspetti più difficili.

In produzione non si possono evitare. A quel punto, l’agente deve accedere a cinque sistemi anziché a uno. Qualcuno deve assumersi la responsabilità del risultato quando l’agente sbaglia, decidere cosa gli è consentito approvare e sostenere i costi per farlo funzionare ogni giorno.

Ecco perché queste difficoltà emergono dopo che la tecnologia ha dato prova della propria efficacia. Non sono mai stati problemi tecnologici. Sono problemi di dati, integrazione, titolarità e autorità, e il progetto pilota era stato concepito per aggirarli tutti.

La soluzione è smettere di considerare i progetti pilota come dimostrazioni. Bisogna trattarli come la prima fase della produzione. Scegliere un flusso di lavoro importante, collegarlo ai sistemi reali, designare un responsabile e definire cosa può decidere l’agente fin dal primo giorno. L’avvio è più lento, ma la crescita su larga scala è molto più rapida.

Hai descritto il passaggio verso un’«economia dell’esecuzione», in cui il vantaggio competitivo dipende sempre più dalla capacità di un’organizzazione di trasformare l’intelligenza in azioni coordinate. Cosa significa in pratica questo concetto e in che modo cambia l’approccio che le imprese dovrebbero adottare per gli investimenti nell’IA?

Ogni attività segue la stessa catena: Informazione, Approfondimento, Decisione ed Esecuzione.

Per decenni il software aziendale si è concentrato sui primi due passaggi, mentre l’IA sta migliorando rapidamente i primi tre. L’esecuzione è il passaggio in cui la maggior parte delle organizzazioni è ancora bloccata ed è lì che si sta spostando il vantaggio competitivo.

In pratica, nell’economia dell’esecuzione l’intelligenza non è più la risorsa scarsa. Lo è la capacità di portare a termine le attività. Due aziende possono disporre degli stessi modelli, degli stessi dati e degli stessi approfondimenti. A prevalere è quella che trasforma tali approfondimenti in azioni coordinate, con autorità ben definite e una traccia di controllo.

Questo cambia il modo di investire. Oggi la maggior parte dei budget per l’IA viene destinata agli strumenti: copiloti, assistenti e strumenti di ricerca migliori. Rendono più veloci i singoli individui. Ma una proposta redatta dall’IA in dieci minuti può comunque restare in attesa di approvazione per tre giorni. Attività più rapide non significano risultati più rapidi.

Quindi, bisogna finanziare i flussi di lavoro, non gli strumenti, e partire da una domanda diversa. Non «Come possiamo rendere questo dipendente più produttivo del 20%?», ma «Quali attività non dovrebbero più richiedere il coordinamento umano?»

Man mano che l’IA passa dall’assistere i dipendenti nello svolgimento di singole attività all’eseguire autonomamente interi flussi di lavoro, in che modo le organizzazioni devono ripensare i processi esistenti, le strutture decisionali e i modelli di responsabilità?

La maggior parte dei processi aziendali è stata concepita tenendo conto dei limiti umani. Le informazioni circolavano lentamente, così abbiamo introdotto le riunioni. Le decisioni richiedevano supervisione, così abbiamo creato catene di approvazione. Gran parte di ciò che chiamiamo processo consiste in realtà in passaggi di consegne tra persone.

Automatizzare i processi così come sono significa automatizzare l’organigramma. Si ottengono passaggi di consegne più rapidi, non meno numerosi.

Il ripensamento parte dalle decisioni, non dalle attività. Per ogni flusso di lavoro, occorre mappare le decisioni che contiene. Quali decisioni può raccomandare un agente? Quali può prendere? Quali può eseguire autonomamente? Quando è necessario l’intervento di una persona?

L’autorità riguarda le decisioni, non interi flussi di lavoro. Ci si può fidare pienamente di un agente per la riconciliazione di una fattura, ma può comunque essere necessaria l’approvazione di una persona per qualsiasi pagamento superiore a una soglia prestabilita.

La responsabilità non scompare. Diventa più chiara. Esseri umani e agenti condividono la responsabilità dell’esecuzione: gli agenti svolgono il lavoro, mentre le persone definiscono i limiti dell’autorità, gestiscono le eccezioni e si assumono la responsabilità del risultato. Ogni agente deve avere un responsabile nominativo e ogni azione deve essere tracciabile e, ove possibile, reversibile.

La leadership passa dal coordinamento del lavoro alla progettazione dei sistemi che lo eseguono.

In KMS Technology, vi state concentrando sulla trasformazione dell’ingegneria digitale tradizionale in un modello di esecuzione aziendale nativo dell’IA. Come si concretizza questa trasformazione all’interno dell’azienda e in che modo KMS affronta l’integrazione di IA, piattaforme dati e orchestrazione intelligente dei flussi di lavoro per ottenere risultati aziendali misurabili?

Per prima cosa, applichiamo a noi stessi lo stesso approccio. KMS è nata come azienda di ingegneria digitale. La nostra prossima fase è l’esecuzione aziendale nativa dell’IA: sviluppare, modernizzare e gestire, con esseri umani e agenti che condividono la responsabilità dell’esecuzione. I risultati si misurano in termini di tempo e impegno:

Sviluppare. Evergreen Telehealth voleva una piattaforma di telemedicina basata sull’IA agentica e sullo standard FHIR per i dati sanitari, ma sul mercato non esisteva nulla di simile. Adottando un approccio nativo dell’IA e integrando Claude in tutte le fasi, dalla definizione dei requisiti alla progettazione, allo sviluppo e ai test, il nostro team e gli ingegneri di Evergreen hanno portato la piattaforma principale dall’ideazione alla produzione in 75 giorni lavorativi. Il progetto comprendeva tre app (web, iOS e Android), quattro integrazioni operative (cartelle cliniche elettroniche, verifica dell’identità, pagamenti e farmacia) e due agenti in produzione. Il modello era guidato dalle persone e accelerato dall’IA. Gli agenti redigevano le storie utente, generavano codice ed eseguivano test. Gli ingegneri erano responsabili dell’architettura, della mappatura dei dati clinici e di ogni decisione importante.

Modernizzare. Un altro esempio: un’azienda di software marittimo doveva sostituire una piattaforma che utilizzava in locale da oltre 20 anni. Non poteva giustificare una lunga ricostruzione tradizionale prima che gli investitori vedessero dei progressi, quindi abbiamo avviato un progetto di sviluppo agentico della durata prestabilita di sei settimane. I requisiti del cliente sono stati caricati come contesto, così gli agenti hanno sviluppato il prodotto sulla base delle specifiche, invece di limitarsi a generare codice. Il team ha completato dal 35 al 45 per cento dell’ambito dell’MVP in circa 800 ore di lavoro del team, a fronte di una stima iniziale compresa tra 6.000 e 8.000. Gli agenti hanno scritto il codice e oltre 5.000 test unitari. Gli ingegneri hanno definito i limiti operativi e valutato la qualità.

Gestire. Da allora Evergreen ha esteso l’architettura dei suoi agenti a tutta l’azienda, con agenti supervisori che monitorano il sistema e persone coinvolte nel processo per valutarlo e correggerlo.

Non ci limitiamo a scrivere codice più velocemente. Stiamo cambiando la quantità di lavoro che un team può portare a termine.

In tutti e tre i casi, esseri umani e agenti condividono la responsabilità dell’esecuzione. Gli agenti si occupano delle attività ripetitive. I nostri ingegneri e i team dei nostri clienti sono responsabili delle decisioni, delle eccezioni e dei risultati.

Questo stesso cambiamento ci permette di aumentare la capacità di consegna. È questa la differenza tra un processo di delivery nativo dell’IA e uno potenziato dall’IA.

I sistemi aziendali basati sull’IA dipendono sempre più dall’accesso a informazioni distribuite tra applicazioni legacy frammentate, piattaforme cloud e ambienti dati. Quanto è complesso collegare questi sistemi e quali basi architetturali dovrebbero predisporre le organizzazioni prima di tentare di implementare flussi di lavoro basati sull’IA su larga scala?

È la sfida principale. La maggior parte delle aziende non ha un problema di IA: ha un problema di frammentazione che l’IA ha reso impossibile ignorare.

Basta osservare come si svolge il lavoro oggi. Qualcuno cerca informazioni in un’applicazione, sollecita un’approvazione in un’altra e copia il risultato in una terza. Sono le persone a fungere da livello d’integrazione. Un agente non può svolgere quel lavoro se non è in grado di raggiungere quei sistemi, comprenderne il contesto e agire con le autorizzazioni corrette.

Perciò, le basi contano più del modello. I primi quattro elementi sono:

• un’architettura dati moderna che fornisca agli agenti un contesto affidabile
• un livello d’integrazione che consenta agli agenti di agire su più sistemi, non solo di leggerne i dati
• identità e autorizzazioni progettate per gli agenti, non soltanto per le persone
• monitoraggio, per poter vedere cosa ha fatto ogni agente e perché

Anche lo stack si sta semplificando. Le piattaforme dati stanno diventando operative, le piattaforme per i flussi di lavoro stanno diventando intelligenti e le applicazioni stanno diventando headless. Se un flusso di lavoro può attraversare tutto lo stack, perché dovrebbe farlo l’utente?

Non aspettare di avere un’architettura perfetta. Scegli un flusso di lavoro importante e modernizza tutto ciò che coinvolge. Poi passa al successivo.

Quando gli agenti di IA iniziano a prendere decisioni e a eseguire azioni in tutte le attività aziendali, le questioni relative alla governance, alla responsabilità e alla supervisione umana diventano sempre più importanti. Come dovrebbero stabilire le imprese quali decisioni possono delegare all’IA e quali devono restare sotto il controllo umano?

Comincerei riformulando la domanda. Non «L’IA può farlo?». Sempre più spesso, la risposta è sì. La domanda migliore è: «Chi le ha dato il permesso di agire?»

Capacità e accesso non equivalgono ad autorità. Se un agente può approvare un rimborso, modificare un programma di produzione o impegnare una spesa, qualcuno deve stabilire i limiti.

Un criterio pratico è valutare il costo e la reversibilità. Una decisione frequente, basata su regole e facile da annullare è una buona candidata alla delega. Una decisione ad alto impatto, irreversibile o che definisce il rapporto con un cliente dovrebbe restare nelle mani di una persona.

La delega va anche conquistata. Si può iniziare con gli agenti che formulano raccomandazioni e una persona che le approva. Man mano che si accumulano prove, si può passare dall’approvazione di ogni singola azione alla supervisione del sistema e alla gestione delle eccezioni.

L’obiettivo non è avere una persona coinvolta in ogni ciclo, ma nei cicli giusti. I dati forniscono il contesto. I modelli ragionano. Gli agenti eseguono. Le persone definiscono l’autorità e si assumono le conseguenze.

Hai guidato importanti attività legate alle piattaforme aziendali in Accenture e Cognizant, dove ampliare le operazioni richiedeva di coordinare tecnologia, persone e processi in organizzazioni globali. Quali insegnamenti tratti da queste esperienze si applicano alle iniziative di trasformazione dell’IA di oggi, soprattutto quando la resistenza organizzativa o modelli operativi obsoleti diventano ostacoli più grandi della tecnologia stessa?

L’integrazione mi ha insegnato più di ogni altra cosa. In Cloud Sherpas, poi in Accenture e in seguito in Cognizant, ho passato anni a unire organizzazioni. Culture, modelli di erogazione, incentivi e aree geografiche diversi dovevano tutti funzionare come un’unica attività basata su una piattaforma.

La tecnologia raramente era il vincolo. Lo era il modello operativo.

Tre insegnamenti si applicano direttamente alla trasformazione dell’IA.

Primo, la resistenza è di solito razionale. Le persone tutelano ciò in base a cui vengono valutate. Se introduci gli agenti continuando a valutare i team in base alle ore, al numero di dipendenti e alle attività svolte, otterrai conformità, non cambiamento. Cambia i criteri di valutazione e i comportamenti seguiranno.

Secondo, i diritti decisionali devono essere espliciti. In ogni integrazione, le conversazioni più difficili riguardavano chi dovesse decidere cosa. Con l’IA, questa domanda diventa inevitabile, perché alcuni decisori non sono più persone.

Terzo, bisogna chiarire cosa resterà invariato. Le persone affrontano meglio il cambiamento quando ne capiscono il motivo e sanno che cosa non cambierà.

La trasformazione dell’IA è un cambiamento del modello operativo che coinvolge anche la tecnologia. I leader che la trattano come un’implementazione software resteranno delusi.

Le metriche tradizionali del successo dell’IA spesso si concentrano sui tassi di adozione, sui miglioramenti della produttività e sul tempo risparmiato. Quali metriche dovrebbero considerare prioritarie i dirigenti per stabilire se l’IA sta davvero migliorando l’esecuzione delle attività aziendali, e come possono le organizzazioni distinguere i guadagni incrementali di efficienza da una trasformazione operativa sostanziale?

L’adozione e il tempo risparmiato sono metriche di input. Dicono che le persone usano lo strumento, non che l’azienda stia procedendo più rapidamente.

Se un ingegnere risparmia due ore ma il rilascio deve comunque aspettare una settimana per la revisione, per il cliente non è cambiato nulla. Svolgere più rapidamente le singole attività non significa ottenere risultati più rapidamente.

Darei la priorità a tre tipi di metriche:

• Tempo che intercorre tra l’esigenza e il risultato: quanto tempo occorre, dall’inizio alla fine, perché una richiesta si traduca in un risultato.
• Dove il lavoro si blocca: quanto tempo richiedono le decisioni, i passaggi di consegne e le code tra i team.
• Lavoro svolto senza coordinamento: quanta parte di un flusso di lavoro procede senza coordinamento umano, mentre le persone si concentrano sulle valutazioni e sulle eccezioni.

Poi collega queste metriche ai risultati aziendali: costo del servizio, qualità e ricavi.

Il criterio per valutare la trasformazione è semplice: l’attività è diventata più rapida o è cambiata la struttura del flusso di lavoro? I miglioramenti incrementali velocizzano lo stesso processo. La trasformazione elimina le fasi, i passaggi di consegne e le approvazioni che non sono più necessari.

Misura il tempo che intercorre tra l’esigenza e il risultato. Individua dove il lavoro si blocca. Cambia ciò che lo trattiene.

Guardando ai prossimi tre-cinque anni, come pensi che evolverà il rapporto tra IA, software aziendale e lavoratori? Immagini un futuro in cui i sistemi nativi dell’IA sostituiranno radicalmente i flussi di lavoro aziendali tradizionali, e cosa dovrebbero fare oggi i leader aziendali per prepararsi a questa transizione?

Per trent’anni, il software aziendale ci ha detto cosa stava succedendo. Nei prossimi tre-cinque anni, farà sempre più il lavoro al posto nostro.

Ciò che l’IA sostituirà è il coordinamento: rincorrere le persone, copiare, passare il lavoro ad altri e sollecitare risposte, attività che occupano gran parte della giornata della maggior parte delle persone. Le persone si dedicheranno di più al giudizio, alla gestione delle eccezioni, alle relazioni e alla responsabilità dei risultati. È un modo migliore di valorizzare le competenze umane, ma richiede nuove capacità, che i leader devono sviluppare con intenzione.

Cosa dovrebbero fare oggi i leader? Scegliere un flusso di lavoro importante e mappare le decisioni che comporta. Sistemare i dati su cui si basa. Definire quali decisioni l’agente è autorizzato a prendere e indicare chi è responsabile del risultato. Poi passare al flusso di lavoro successivo.

Le aziende che considerano l’IA uno strumento otterranno maggiore efficienza. Quelle che si riorganizzeranno attorno a essa ne ricaveranno un vantaggio strategico. L’IA non è la strategia. Lo è l’esecuzione.

Grazie per la splendida intervista. I lettori che desiderano approfondire l’esecuzione aziendale nativa per l’IA, i flussi di lavoro intelligenti e il passaggio dai progetti pilota di IA alla produzione possono visitare KMS Technology.