Come i consulenti AI definiscono lo scope di una sostituzione SaaS in-house

Qualsiasi consulente che valga la sua tariffa giornaliera definisce lo scope per sostituire un SaaS in-house nello stesso modo: divide ogni strumento tra le parti visibili e quelle che devono essere corrette ogni singola volta. Il SaaS (software che si noleggia su base mensile) è composto principalmente da schermate, workflow e report appoggiati su un nucleo più piccolo di gestione dei dati fondamentali (system of record). L'AI ha reso la prima metà economica da ricostruire. È nella seconda metà che i progetti di sostituzione falliscono, e uno scope ben fatto serve proprio a misurare quanta parte del canone di abbonamento risieda effettivamente lì.

Ecco come nasce, passo dopo passo, uno scope per la sostituzione in-house di un SaaS e qual è la domanda fondamentale da cui dipende gran parte del lavoro. (I nomi dei fornitori e i dati dei sondaggi riportati di seguito sono accurati al momento della pubblicazione; considerali come un'istantanea del settore.)

Che cosa contiene davvero uno scope per sostituire un SaaS?

Un inventario delle attività, non un elenco di funzionalità. Il consulente elenca ogni compito svolto dallo strumento, chi vi interagisce e cosa succede se l'output è errato. Catene di approvazione, dashboard e moduli vanno in una colonna. Movimenti monetari, conteggi delle scorte, tasse e dati dei dipendenti vanno nell'altra. Il deliverable consiste in questa mappa, un livello di rischio per ogni attività e un elenco di tutti i sistemi a cui lo strumento è silenziosamente collegato.

La domanda di valutazione determina l'intero processo: se questo output fosse sbagliato, come te ne accorgeresti e quanto ti costerebbe? Una dashboard non aggiornata si nota a colpo d'occhio e non costa nulla. Un totale errato per un pagamento si scopre in sede di dichiarazione dei redditi e costa soldi veri.

Perché dividere il prodotto in due livelli?

Perché l'AI ha azzerato il costo di un livello lasciando invariato l'altro. Il livello dell'interfaccia (moduli, dashboard, strumenti interni, workflow di approvazione) è ormai rapido da ricostruire; i modelli attuali generano web app funzionanti in poche ore, esattamente come abbiamo riscontrato chiedendoci se GPT-5.6 potesse creare un POS funzionante. Il livello dell'infrastruttura è diverso: elaborazione dei pagamenti, conformità PCI (le regole di sicurezza sui dati delle carte imposte dagli acquirer), gestione delle scorte in concorrenza (due casse che vendono contemporaneamente l'ultima unità disponibile) e report di riconciliazione (totali che corrispondono al deposito bancario). Quel livello non è complesso perché il codice sia lungo. È complesso perché un risultato «quasi corretto» non vale nulla, e dimostrare la correttezza costa più della generazione del codice stesso.

I modelli più avanzati non eliminano questo vincolo. Il collo di bottiglia risiede nella verifica e nella responsabilità, non nella generazione del codice, motivo per cui uno scope onesto dà un prezzo alla verifica. La generazione è la demo. La verifica è la fattura.

Che cosa ha davvero dimostrato la sostituzione del SaaS di Klarna?

La storia più roboante del tipo «abbiamo sostituito il nostro SaaS con l'AI» è in realtà una lezione di scoping. A fine 2024, l'A.D. di Klarna ha annunciato che l'azienda stava abbandonando Salesforce e Workday nell'ambito di un piano di riorganizzazione basato sull'AI, e i giornali hanno titolato che l'AI stava sostituendo del tutto i SaaS. Analisi successive hanno rivelato un quadro più circoscritto: Klarna ha trasferito l'HR a un altro fornitore e ha coperto le sue esigenze di CRM con una combinazione di strumenti alternativi e codice d'integrazione interno, integrando l'AI in cima¹. Una banca con regolare licenza che gestisce uno dei programmi di AI più aggressivi nel fintech ha comunque mantenuto i propri system of record (la versione ufficiale dei dati aziendali) su piattaforme collaudate, ricostruendo solo i contorni.

Non si è trattato di una mancanza di coraggio. È stata la dimostrazione che lo scope funziona.

Quali numeri giustificano un progetto di sostituzione?

Prima ridurre gli sprechi, poi sviluppare. Il SaaS Management Index 2026 di Zylo, basato su oltre 40 milioni di licenze gestite, individua la spesa media mediana per i SaaS in 9.455 $ per dipendente all'anno, rileva che in media il 36% delle licenze resta inutilizzato e mostra come le unità operative controllino l'81% della spesa SaaS mentre l'IT ne gestisce direttamente solo il 15%². Un consulente analizza il tuo stack rispetto a questi numeri prima di proporre qualsiasi cosa: cancella le licenze inutilizzate, consolida gli strumenti sovrapposti e solo allora seleziona i candidati da ricostruire.

Gli strumenti che rientrano nella lista condividono un profilo ben preciso: costi ricorrenti elevati, attività che risiedono principalmente nel livello dell'interfaccia e un raggio d'impatto limitato in caso di guasto. Il progetto viene approvato quando la spesa per gli abbonamenti cresce più velocemente dei costi di sviluppo e manutenzione, e ogni attività che richiede una correttezza assoluta può rimanere su un'infrastruttura gestita da terzi.

Dove si colloca un POS in questa analisi dello scope?

All'estremità più spietata dello spettro. Un POS sembra un progetto di interfaccia — una griglia di pulsanti e un carrello — e per questo i titolari di attività pensano che lo scope sia simile a quello di una dashboard. Il rapporto è capovolto. La schermata di checkout è una minima frazione del prodotto; il resto riguarda pagamenti, hardware certificato per transazioni fisiche, inventario che resiste a vendite simultanee su due casse, regole fiscali e report di chiusura giornaliera con riconciliazione. Quando un POS sbaglia, sbaglia sui soldi, ogni giorno.

I consulenti definiscono quindi lo scope di ricostruzione di un POS allo stesso modo in cui Klarna ha affrontato il suo registro contabile: interfaccia personalizzata, infrastruttura collaudata. In passato questo tipo di divisione richiedeva un team di sviluppatori. Oggi costituisce una categoria di prodotto a sé stante: Build di Final trasforma un prompt in linguaggio naturale in un checkout flow di cui puoi visualizzare l'anteprima e distribuire, e puoi collegare la tua AI via MCP per sviluppare sulla stessa infrastruttura di commerce. Pagamenti, inventario, reportistica e hardware rimangono sul livello già verificato.

Quindi, come si definisce lo scope per la sostituzione in-house di un SaaS?

Dividi ogni strumento nei suoi due livelli, valuta ogni attività in base al costo di un output errato non rilevato e calcola il prezzo della verifica anziché del codice. Ricostruisci liberamente interfacce e workflow; lascia i system of record su un'infrastruttura di cui qualcun altro garantisce la correttezza. Prima di ricostruire qualsiasi strumento in-house, chiediti: se il suo output fosse sbagliato, in quanto tempo me ne accorgerei? Se la risposta è «non subito», quell'attività deve rimanere su binari collaudati.

E se la parte del tuo stack dedicata al commerce è quella che desideri ricostruire, inizia analizzando con obiettività ciò che i modelli attuali possono e non possono creare autonomamente: Claude vs ChatGPT vs Gemini nella creazione di un POS reale, o i due percorsi no-code in come usare Gemini 3.6 Flash per creare un POS personalizzato.