Come lavoro

In sintesi

Uso tre metodi, nell'ordine in cui servono. Value Intelligence decide se un'iniziativa AI vale la spesa, contando le ore restituite e le richieste di aiuto invece delle funzionalità consegnate. Safe-to-Learn prova l'idea in un ambiente separato prima di chiedere budget. Portable Operational Memory tiene il contesto dell'azienda separato dal modello del momento, così cambiare tecnologia non vuol dire ricominciare.

Quasi sempre il problema dichiarato non è il problema. Il lavoro comincia lì.

Un'azienda dice: ci serve un agente AI sul servizio clienti. Può essere vero. Ma la stessa frase può voler dire che le risposte stanno in quattro sistemi diversi, che nessuno sa quale sia quello giusto, e che un agente costruito su quei dati darebbe risposte sbagliate più in fretta.

Da questa distanza fra quello che si chiede e quello che serve sono usciti tre metodi. Ognuno risponde a una domanda diversa:

L'ordine conta. Un prototipo perfetto su un problema che non valeva niente resta un prototipo che non vale niente.

Value Intelligence

Le iniziative AI si giustificano quasi sempre contando le funzionalità consegnate. È la misura sbagliata.

Una funzionalità che nessuno usa costa quanto una che usano tutti.

Value Intelligence sposta la decisione di investimento sul valore ottenuto, misurato su riduzione dei costi ed efficienza di processo, e lo fa prima che il budget sia impegnato. Nel mio ruolo l'ho progettato io e oggi è il modo in cui si decide sulle iniziative Salesforce e Agentforce.

Dove guardo per primo

Un processo è lento quanto il suo passaggio più stretto. Migliorare qualunque altro punto non cambia il risultato, sposta solo l'accumulo da un'altra parte.

Succede spesso con l'automazione commerciale. Si automatizza la qualificazione dei lead, le richieste in entrata raddoppiano, e le offerte chiuse restano quelle di prima, perché il collo di bottiglia non era la qualificazione: era l'ufficio tecnico che prepara i preventivi.

Un investimento fatto bene su un punto che non era il vincolo produce zero.

Quindi la prima domanda non è quale tecnologia. È: quale ostacolo, se sparisse, cambierebbe davvero il risultato?

Come lo cerco

Non chiedendo se l'idea piace. Chiedendo cosa è già successo.

«Vi servirebbe un agente AI?» produce risposte cortesi. «Qual è stata l'ultima volta che un commerciale ha perso mezza giornata a recuperare informazioni, e quanto è costata?» produce fatti. Un budget già speso per provare a risolvere un problema dice più di qualunque previsione, perché è una decisione già presa con soldi veri.

Cosa misuro

Un caso d'uso solo, con il numero deciso prima di partire e un criterio scritto per fermarsi. I numeri che uso sono due:

Un comitato li accetta perché si contano. Sulla knowledge base resa interrogabile in SharePoint e Teams il numero era il secondo: ticket di supporto interni scesi di oltre il 30%, su circa 2.000 utenti, nei due mesi dopo il lancio.

Il criterio per fermarsi è la parte che si salta più spesso, ed è quella che conta di più.

I programmi grandi raramente falliscono. Continuano, e assorbono budget perché fermarli richiede a qualcuno di ammettere un errore.

Safe-to-Learn

Value Intelligence dice cosa conviene provare. Safe-to-Learn dice come provarlo senza toccare i sistemi dell'azienda.

In un'azienda quotata non colleghi un tool AI ai sistemi di produzione per vedere che succede, e c'è un buon motivo. Ma se valutare un'ipotesi richiede due mesi, a fine valutazione il modello è cambiato, la feature è nuova, a volte è cambiato il prodotto.

La tecnologia cambia più in fretta di quanto un'organizzazione riesca ad assorbirla.

Per capire se un'idea può funzionare, però, non servono necessariamente i dati di produzione. Salesforce mette a disposizione ambienti demo gratuiti, separati dalla org aziendale: lì esploro una capability, costruisco un prototipo funzionante su sample record, e raccolgo prove prima di chiedere all'azienda una valutazione più ampia.

Io lo chiamo Safe-to-Learn. Non separa un prima e un dopo la governance, separa due domande che vengono sempre confuse:

  1. 01 Discover Questa idea può funzionare? Demo org vergine, documentazione ufficiale e Trailhead MCP. Nessun collegamento alla org aziendale. Indizio che l'idea sta in piedi · Fattibilità tecnica
  2. 02 Prototype Riesco a dimostrarlo? Stessa demo org, sample record. Con la Salesforce CLI riporto la struttura dei campi di uno o più oggetti, così l'ambiente somiglia alla sandbox collegata ai dati dell'azienda. Prova tecnica funzionante · Fattibilità tecnica
  3. 03 Pilot Funziona per questa azienda? Prima la sandbox collegata ai dati veri, poi un pilot in produzione: perimetro ristretto, utenti selezionati, revisioni proporzionate al rischio. Validazione enterprise · Idoneità enterprise
  4. 04 Production Possiamo scalarlo in sicurezza? Scaling in produzione: autorizzazione, sicurezza, controllo degli accessi, monitoraggio, proprietà, audit e ciclo di vita. Pronto a essere operato · Idoneità enterprise

I requisiti di sicurezza e autorizzazione valgono a ogni fase. Cambia la profondità dei controlli, che segue il rischio e le conseguenze.

Prima del pilot servono tre nomi su un foglio: chi risponde della sicurezza, chi della conformità, chi ha l'ultima parola. Se non li scegli all'inizio li scopri a metà progetto, quando dicono di no e tutto si ferma.

Le sandbox esistono da sempre, quindi la novità non è tecnica: è chi le usa e perché. Un developer apre una sandbox per provare una funzionalità, mentre qui un ambiente isolato serve a chi deve decidere, per testare un'ipotesi di business prima di impegnare risorse serie.

Il mio obiettivo non è portare un'idea al team di architettura. È portare un'idea sostenuta da una prova tecnica funzionante.

In una grande azienda ogni idea costa prima ancora di essere approvata: persone, analisi, architettura, riunioni, business case. Un prototipo che costa giorni fa scartare presto le idee deboli e mostra le dipendenze vere, così architettura e governance lavorano solo su quello che ha già una prova dietro.

L'obiettivo non è produrre più pilot AI. È decidere meglio quali pilot meritano di esistere.

Portable Operational Memory

Safe-to-Learn riguarda come si sperimenta, e la domanda che viene dopo è cosa resta. Modelli, agenti e interfacce cambiano frequentemente, e questo ha un impatto reale sui costi e su cosa resta tecnicamente disponibile: se costruiamo ogni processo attorno all'agente del momento, quel processo lo rifacciamo a ogni cambio di tecnologia.

Me la immagino come una memoria esterna piena di porte USB. L'azienda ci collega il modello che vuole, quando vuole, e la memoria resta sua.

Dentro non ci sono soltanto i dati:

Non è per forza un database nuovo, è un livello logico e governato sopra i sistemi che l'azienda ha già.

Architettura concettuale: è la mia proposta, non un'architettura già realizzata su tutti questi livelli.

Portabile non vuol dire spostare dati sensibili fra fornitori. Vuol dire progettare interfacce, contratti semantici, autorizzazioni e capability in modo che strumenti diversi possano riusarli, sempre sotto le policy dell'azienda.

Modelli e interfacce devono essere sostituibili. La memoria operativa di un'azienda no.

L'autonomia, allora, non è una proprietà dell'agente ma della singola capability. Un agente che riassume documentazione pubblica e un agente che può modificare l'opportunity di un cliente non sono lo stesso problema di governance: se li facciamo passare dallo stesso processo creiamo attrito inutile sul primo, e se diamo al secondo la libertà del primo creiamo un rischio che non è accettabile.

Quando la risposta è no

A volte la risposta giusta è che il progetto non serve, o non adesso. Anche quella è una risposta, e di solito è la più economica.

Nella vostra azienda, l'ultima iniziativa AI approvata aveva un numero deciso prima di partire?