Perché falliscono i progetti Salesforce AI

Il software viene consegnato. Funziona. E il progetto è comunque fallito. È lo scenario più comune, ed è quello che nessun analisi di un fallimento pubblica.

1. Governance: nessuno possiede la cosa

Un progetto AI attraversa funzioni: IT lo costruisce, il business lo usa, i dati appartengono a un terzo. Quando il fornitore se ne va, la manutenzione richiede decisioni che nessuna delle tre funzioni ha l'autorità di prendere da sola. Il sistema non si rompe: si irrigidisce. Smette di essere aggiornato, diverge dalla realtà del business, e a un certo punto le persone ricominciano a fare le cose come prima.

Antidoto: un proprietario nominato prima del kickoff, con autorità di decidere su dati e processo, non solo di segnalare.

2. Accessi: il modello di visibilità non regge un lettore trasversale

I modelli di sicurezza CRM sono costruiti attorno a un'assunzione implicita: un utente guarda i propri record. Un agente AI legge attraverso, per rispondere. La domanda "questo agente può vedere i margini del cliente quando risponde a un venditore?" non ha una risposta ovvia, e non è una domanda tecnica: è una domanda di policy.

Quando arriva tardi - tipicamente in fase di test - le opzioni sono due: restringere l'agente fino a renderlo inutile, oppure aprire e accorgersene dopo. Entrambe uccidono il progetto, la seconda più lentamente.

Antidoto: la matrice "chi può vedere cosa attraverso l'agente" va scritta durante l'analisi, con il legale e la security dentro la stanza, non dopo.

3. Valore prodotto: nessuno sa dire se è servito

È la causa più frequente e la meno riconosciuta, perché non produce un fallimento visibile: produce ambiguità. Dodici mesi dopo, qualcuno chiede se la spesa è stata giustificata e la risposta è un aneddoto. Senza un numero concordato prima, l'aneddoto è tutto quello che avrete - e alla richiesta di budget successiva pagherete quel vuoto.

Antidoto: una metrica, un valore di partenza misurato prima di iniziare, una data. Se la baseline non viene misurata all'inizio non è più ricostruibile dopo: è il singolo errore più costoso e più facile da evitare.

4. Il caso d'uso è stato scelto dal fornitore

Il fornitore propone il caso d'uso che sa fare bene, non quello che vi serve di più. Non è malafede: è competenza applicata al problema sbagliato. Il risultato è un sistema elegante su un processo che non era il vostro collo di bottiglia.

5. Nessun criterio di stop

I progetti che nascono senza una definizione di fallimento non falliscono mai: continuano. Assorbono budget per inerzia, perché fermarli richiede a qualcuno di dichiarare un errore, e nessuno ha ricevuto il mandato per farlo. Un criterio di stop scritto prima di partire non è pessimismo: è ciò che rende possibile provare qualcosa.

La cosa che accomuna tutte e cinque

Nessuna è un problema tecnico. Sono tutte decisioni organizzative che il fornitore non può prendere al posto vostro e che, non essendo di nessuno, vengono rimandate finché non è tardi. È anche il motivo per cui un parere esterno che non vende l'implementazione serve a qualcosa: le cinque domande sopra non sono nell'interesse di chi deve chiudere il contratto.

Domande frequenti

Come ci accorgiamo per tempo che stiamo andando in quella direzione?

Tre segnali precoci: nessuno sa dire chi possiede il dato su cui il sistema lavora; il criterio di successo non è ancora scritto a progetto avviato; le decisioni sugli accessi vengono rimandate perché "si vedranno in fase di test".

Il fornitore è responsabile di questi fallimenti?

Raramente in senso contrattuale: consegna quello che ha promesso. È esattamente il problema - si può fallire un progetto rispettando ogni clausola del contratto, perché il contratto copre la consegna, non il risultato.

Si può recuperare un progetto già partito male?

Spesso sì, e costa meno di quanto si teme, perché quasi sempre manca una decisione organizzativa e non del lavoro tecnico. Il costo vero è che quella decisione va presa da qualcuno che ha autorità, non dal team di progetto.