ERP o SaaS nel 2026? Un quadro decisionale onesto da Clockwise Software

Punti di forza

• La decisione ERP-vs-SaaS non è più binaria nel 2026. I modelli di intelligenza artificiale e l'architettura multi-tenant hanno modificato entrambe le categorie al punto che la risposta giusta per molte aziende è un ibrido che raramente si vedeva cinque anni fa.

• Cinque domande decidono la categoria per il 90% dei clienti che incontro. La permanenza dell'utente, il peso del flusso di lavoro tra i vari reparti, la pressione normativa, il divario tra acquirente e utente e il tasso di cambiamento del flusso di lavoro. Le distinzioni tra marchi contano meno.

• Sei modelli UI/UX sono ormai standard in entrambi i mondi. Navigazione basata sugli intenti, copiloti ambientali, default generativi, affordance di fiducia, personalizzazione effimera e riepiloghi di verifica.

• Negli ultimi 47 progetti controllati, l'errore più costoso non è stata la scelta del fornitore. È stato il disallineamento di categoria. I fondatori che hanno scelto il tipo di sistema sbagliato hanno pagato da 2 a 3 volte di più rispetto ai fondatori che hanno scelto il tipo giusto con un fornitore mediocre.

La decisione è diventata più difficile, non più facile

Vorrei iniziare con qualcosa che sembra controintuitivo. La decisione tra ERP e SaaS è più difficile nel 2026 che nel 2020. Non perché la tecnologia sia diventata più complicata, anche se è così. Perché le categorie stesse si sono confuse al punto che la vecchia stenografia ha smesso di funzionare.

Cinque anni fa ero in grado di dire a un cliente da che parte stava la sua azienda nel giro di un'ora. ERP per il flusso di lavoro profondo, la lunga permanenza dell'utente, il flusso di dati tra i vari reparti. SaaS per il prodotto mirato, l'acquirente self-service, la rapida cadenza di rilascio. Questa euristica si è rotta nel 2024. Nel momento in cui scrivo, nell'aprile del 2026, ho distribuito un ERP multi-tenant che funziona sulla stessa architettura dei nostri prodotti SaaS per i consumatori, e ho distribuito un SaaS verticale che ha svolto il lavoro di un sistema ERP da 400.000 dollari a un quarto del costo. Le categorie non hanno più il significato che avevano.

La maggior parte degli articoli che ho letto di recente su questo argomento sono elenchi di fornitori. Microsoft Dynamics contro NetSuite contro SAP. Non sono inutili, ma rispondono a una domanda che quasi nessuno si pone. La vera domanda da porsi è se acquistare un ERP o se la vostra azienda sia meglio servita da un SaaS verticale personalizzato o se ciò di cui avete veramente bisogno è un ibrido che non si adatta perfettamente a nessuna delle due categorie. Nessuno degli elenchi vi aiuterà in questo senso. Quindi scriverò l'articolo che vorrei fosse stato scritto per me tre anni fa.

Per contestualizzare, io e il mio team lavoriamo come azienda di sviluppo software erp per circa il 30% dei nostri impegni attivi e come studio di prodotti SaaS per il restante 70%. La suddivisione è rimasta straordinariamente stabile per quattro anni, anche se il lavoro stesso è cambiato. Questo mix mi offre un punto di vista che i negozi ERP o SaaS puri non hanno. Vedo come le due categorie convergono e vedo dove ancora divergono e voglio condividere ciò che ho imparato.

Perché "ERP o SaaS" è sempre più la domanda sbagliata

Vi spiego il motivo tecnico per cui le categorie si sono confuse, perché è importante per la logica decisionale che segue.

Per la maggior parte degli ultimi vent'anni, ERP significava software on-premise a singolo tenant con una profonda personalizzazione e cicli di rilascio trimestrali. SaaS significava software multi-tenant, ospitato su cloud, con una personalizzazione ridotta e rilasci settimanali. Questi valori tecnici predefiniti definivano i confini della categoria.

Entrambi i valori predefiniti sono cambiati. L'ERP è diventato multi-tenant e cloud-first, guidato da NetSuite e spinto da tutti i moderni fornitori di ERP che vogliono competere sul prezzo e sulla velocità di aggiornamento. Il SaaS ha ottenuto una personalizzazione più profonda grazie a livelli di configurazione, punti di estensione low-code e flag di funzionalità per tenant che consentono di differenziare in modo significativo l'esperienza di un cliente da quella di un altro. Il divario tecnico che storicamente definiva le categorie si è ridotto quasi a zero.

Ciò che rimane è una differenza nella forma del flusso di lavoro piuttosto che nell'architettura. Gli utenti ERP lavorano per anni all'interno di un sistema di registrazione. Gli utenti SaaS entrano ed escono da strumenti mirati in base alle loro esigenze. Questa differenza è ancora importante. Ma non si traduce più in una decisione d'acquisto, perché la stessa architettura può supportare entrambe le forme. La domanda si è spostata da "ERP o SaaS" a "di quale forma di flusso di lavoro ha effettivamente bisogno la vostra azienda".

La tabella decisionale in primo piano che uso con ogni cliente

Cinque domande, due risposte per riga, la categoria di appartenenza viene eliminata dal fondo.

Durante la prima telefonata, faccio seguire a ogni potenziale cliente questa tabella. Alla fine della seconda colonna, di solito la categoria si sceglie da sola.

Vorrei sottolineare un'osservazione su questa tabella. Se si ottiene un punteggio di cinque o più righe in una colonna, la categoria è decisa. Se si ottengono tre o quattro punti in una colonna e il resto nell'altra, si tratta di un ibrido. Le build ibride sono ormai abbastanza comuni da avere un playbook dedicato, e ci tornerò.

Come l'IA ha rimodellato entrambi i mondi nel 2025 e 2026

Voglio dedicare una sezione specifica all'IA perché è la variabile che ha cambiato di più entrambe le categorie negli ultimi 18 mesi, e gli elenchi la trattano ancora come una nota a piè di pagina.

Il primo cambiamento riguarda il settore SaaS. L'intelligenza artificiale generativa è passata dall'essere una funzionalità aggiunta a un prodotto all'essere l'aspettativa predefinita che gli utenti hanno nei confronti del prodotto. Un'applicazione SaaS lanciata nel 2026 senza una superficie AI sembra datata già dopo poche settimane dal lancio. I nostri incarichi di sviluppo di applicazioni SaaS negli ultimi dodici mesi hanno tutti incluso almeno una funzionalità di intelligenza artificiale nell'ambito del contratto. Nessuno dei nostri contratti per il 2022 prevedeva questo vincolo.

Il secondo cambiamento riguarda il settore ERP ed è più interessante perché ha richiesto più tempo. I fornitori di ERP hanno opposto resistenza all'IA per due anni. La loro preoccupazione era reale: Gli utenti ERP hanno una bassa tolleranza per i suggerimenti sbagliati, perché gli errori si propagano attraverso i sistemi a valle e i percorsi di revisione. Un utente SaaS che riceve un suggerimento AI sbagliato fa spallucce e riprova. Un utente ERP che accetta un suggerimento sbagliato può pubblicare una fattura sbagliata, archiviare un modulo fiscale errato o calcolare male un documento normativo. Il profilo di rischio è davvero diverso.

Ciò che ha fatto breccia è stata un'applicazione diversa dell'IA. Non la generazione assistita, che è ancora rischiosa nell'ERP. Riassunto e revisione. Le moderne interfacce utente degli ERP nel 2026 includono sempre più spesso un livello di riepilogo che spiega ciò che l'utente ha appena fatto in un linguaggio semplice e segnala le anomalie per la revisione. L'intelligenza artificiale non prende decisioni. Sta leggendo ciò che l'uomo ha fatto e lo sta traducendo in qualcosa che un manager può esaminare in tre minuti invece che in tre ore. Questo modello è ora standard nel nostro lavoro ERP e il tasso di adozione è molto più alto di quello che abbiamo visto con i copilot di chat nella stessa categoria.

La storia dell'AI nel 2026 è quindi duplice. Sul versante SaaS, l'AI accelera l'utente. Nel settore ERP, l'intelligenza artificiale riassume e controlla. Gli stessi modelli sottostanti. Postura operativa completamente diversa. Gli studi che non comprendono questa differenza applicheranno erroneamente l'IA a una o a entrambe le categorie.

Sei modelli di UI e UX ora standard in entrambe le categorie

La gente mi chiede quali siano le novità del 2026 che non c'erano nel 2024. Nel nostro lavoro, sei modelli sono passati dalla fase di sperimentazione a quella di default e sono presenti in entrambe le versioni di ERP e SaaS che forniamo ora.

Schema 1: navigazione basata sugli intenti

L'utente dichiara ciò che vuole fare in un linguaggio semplice. Il sistema lo indirizza verso la superficie giusta e precompila ciò che può. Il menu tradizionale esiste ancora, ma diventa un ripiego. In SaaS, questo modello ha aumentato la fidelizzazione alla prima settimana di un 27% in media tra i prodotti che abbiamo misurato. Nell'ERP, il modello è più cauto perché le conseguenze di un'errata distribuzione sono più elevate, ma funziona per scopi non transazionali come la reportistica e la ricerca.

Schema 2: copiloti ambientali all'interno del flusso di lavoro

I suggerimenti appaiono nel contesto mentre l'utente lavora, invece di aspettare che l'utente apra una finestra di chat. Nel 2026 verranno distribuiti quattro volte più copilot ambientali che copilot di chat, perché la chat interrompe il flusso di lavoro e l'ambiente lo supporta. Il trucco sta nel rendere i suggerimenti facili da eliminare senza assillare.

Schema 3: default generativi sui moduli

I moduli partono precompilati con valori ragionevoli anziché vuoti. Gli utenti modificano invece di scrivere da zero. I tempi di completamento dei moduli si riducono del 40-60% secondo i nostri rilevamenti. La disciplina che fa funzionare tutto questo è l'accuratezza. Se vogliamo che i moduli siano precompilati con un'accuratezza dell'80%, disattiviamo la funzione, perché al di sotto di questa soglia gli utenti imparano a non fidarsi dei valori predefiniti e il risparmio di tempo scompare.

Schema 4: vantaggi per la fiducia

Ovunque l'intelligenza artificiale mostri un output, il sistema mostra anche quanto è fiducioso. I segnali visivi indicano all'utente quando fidarsi dell'output e quando verificare. Senza le garanzie di fiducia, ogni output dell'IA sembra ugualmente autorevole e il primo output sbagliato fa crollare la fiducia nell'intera funzione.

Schema 5: personalizzazione effimera

L'interfaccia si adatta alla sessione corrente dell'utente senza creare un profilo a lungo termine. Questo approccio funziona in base ai vincoli dell'EU AI Act e ha prestazioni quasi uguali a quelle della personalizzazione persistente per quanto riguarda le metriche da noi rilevate. Abbiamo testato entrambi gli approcci su tre prodotti alla fine del 2025. La versione effimera è arrivata entro il 4% della versione persistente nel completamento delle attività e l'ha battuta nel time-to-first-value.

Modello 6: riepiloghi di audit ai confini del flusso di lavoro

Questo modello è la svolta sul lato ERP che ho descritto in precedenza, ed è passato al SaaS per i prodotti che hanno un sapore di conformità. Alla fine di un segmento del flusso di lavoro, il sistema riassume ciò che l'utente ha fatto, segnala le anomalie e offre un percorso di revisione. I manager rivedono il lavoro del loro team in una frazione di tempo. Questa è la funzione AI con il più alto ROI che ho visto nel software aziendale negli ultimi due anni, e non costa quasi nulla perché la sintesi è la capacità LLM più affidabile che abbiamo oggi.

Un modo utile per pensare al lavoro in senso orario nel 2026: non ci chiederemo più se un progetto è ERP o SaaS. Ci chiediamo quali di questi sei modelli appartengono al prodotto e l'architettura segue i modelli piuttosto che il contrario. Questo ordine di operazioni è recente e, a mio avviso, importante.

Caso: come abbiamo lavorato con Cover Whale sulla tecnologia assicurativa

Cover Whale: automazione della tecnologia assicurativa

Nicchia: tecnologia assicurativa | Piattaforma: Web SaaS con profondità di flusso di lavoro di tipo ERP | Impegno: Automazione dei flussi di lavoro e modernizzazione dei processi digitali

Cover Whale si è rivolta a noi durante la pandemia con un problema che si colloca perfettamente a cavallo tra ERP e SaaS. La loro azienda aveva bisogno di digitalizzare i processi interni che si basavano su e-mail e fogli di calcolo, automatizzare i flussi di lavoro che riguardavano la sottoscrizione e le operazioni e rispettare il budget e le scadenze. Il lavoro era di tipo SaaS (cloud-hosted, iterazione rapida, UX moderna) e ERP in profondità (flussi di lavoro trasversali, audit trail, punti di contatto con la conformità).

Voglio condividere ciò che abbiamo imparato dalla build di Cover Whale perché è l'esempio più pulito che mi viene in mente in cui abbiamo resistito all'impulso di chiamare il progetto ERP o SaaS e ci siamo limitati a progettare per il flusso di lavoro.

La prima decisione che abbiamo preso durante la scoperta è stata quella di mappare i processi manuali esistenti prima di progettare qualcosa di nuovo. Sembra ovvio. In pratica, la maggior parte dei team lo salta perché le mappe sembrano noiose. Abbiamo trascorso le prime due settimane a seguire quattro dipendenti nel loro flusso di lavoro quotidiano, registrando ciò che facevano effettivamente rispetto a ciò che avrebbero dovuto fare in base alle politiche del manuale aziendale. Il divario era significativo. Circa il 30% del lavoro si svolgeva al di fuori del flusso di lavoro ufficiale, perché quest'ultimo era troppo rigido per i casi limite reali.

La seconda decisione riguardava la forma dell'interfaccia utente. Abbiamo scelto un modello più vicino al SaaS che all'ERP. Schermate veloci e mirate, con una forte digitazione e moduli brevi. Abbiamo rifiutato la densa interfaccia ERP basata su tabelle che il team aveva inizialmente richiesto perché sapevamo, osservandoli lavorare, che avrebbero usato il sistema su secondi monitor e durante le telefonate. Le interfacce utente dense non sopravvivono in quell'ambiente.

La terza decisione riguardava l'intelligenza artificiale. Abbiamo aggiunto due funzioni di intelligenza artificiale. Un default generativo sul modulo più utilizzato che precompila i campi in base al contesto della politica. E un riepilogo di verifica alla fine di ogni sessione di lavoro che aiutava i supervisori a rivedere il lavoro senza doversi sorbire ogni singola voce. Abbiamo rifiutato le proposte di aggiungere una chat copilot perché sapevamo che gli utenti non l'avrebbero mai aperta durante il loro flusso di lavoro effettivo.

Il risultato è stato, secondo le parole del cliente, un approccio collaborativo con aggiornamenti regolari che hanno fornito una solida base per l'automazione futura. Da parte mia, il risultato è stato un progetto che ha rispettato il budget e i tempi, che erano entrambi stretti. Il CPI del progetto è stato inferiore all'8%, in linea con la nostra media di meno del 10% in tutti gli impegni. La cosa di cui sono più orgoglioso, guardando indietro, è che abbiamo costruito ciò che serviva al flusso di lavoro, piuttosto che ciò che si adattava a un'etichetta di categoria.

Un dettaglio tranquillo del lavoro di Cover Whale che si può generalizzare. Le assicurazioni sono un settore regolamentato. L'intelligenza artificiale nei settori regolamentati è problematica. Abbiamo limitato l'intelligenza artificiale alla sintesi (a basso rischio) e alle pre-compilazioni predefinite (a medio rischio, con la possibilità di essere annullate manualmente). Abbiamo evitato la generazione di contenuti vincolanti e l'azione autonoma. Secondo la mia esperienza, questa limitazione fa la differenza tra una funzionalità di IA che viene lanciata e una che viene disattivata entro sei mesi perché la conformità non è stata approvata.

La realtà dei prezzi in entrambe le categorie

Pubblicherò le fasce di prezzo che cito nelle conversazioni con i clienti reali. Queste sono aggiornate all'aprile 2026 e riflettono le tariffe effettive del mio team, non quelle del settore.

Alcune osservazioni su questi numeri dal mio punto di vista. Il lavoro ERP costa di più per ogni ora di lavoro di ingegneria comparabile, perché la scoperta è più pesante e il numero di integrazioni è maggiore. Le tariffe orarie sembrano uguali, ma il costo totale del progetto è circa 2,5 volte superiore all'equivalente SaaS per un'estensione analoga. Le build ibride, che saranno sempre più frequenti nel 2026, si collocano a metà strada. Il costo della manutenzione come percentuale della build è il secondo fattore di differenziazione nascosto. La manutenzione di un ERP costa di più perché gli aggiornamenti di conformità, le modifiche all'integrazione e l'evoluzione del flusso di lavoro colpiscono regolarmente il sistema.

Ripeterò un numero di prima perché è importante. Nei 47 progetti che abbiamo controllato internamente l'anno scorso, l'errore più costoso non è stato la selezione del fornitore. È stato il disallineamento di categoria. Un fondatore che ha scelto il tipo di sistema sbagliato ha pagato da 2 a 3 volte di più di un fondatore che ha scelto il tipo giusto con un fornitore non proprio ideale. Questo rapporto è brutale e costante.

Errori comuni che vedo commettere ai fondatori

Dopo 12 anni di attività nel settore del software aziendale, continuano a verificarsi gli stessi errori. Voglio sottolineare i cinque che costano di più e che sono più facili da evitare se si sa cosa cercare.

Cosa dice Bogdan ai fondatori che sono bloccati tra le varie categorie

"Quando un fondatore mi chiama e non sa se ha bisogno di un ERP o di un SaaS, gli dico di smettere di cercare di rispondere a questa domanda e di rispondere prima a una più semplice. Qual è il flusso di lavoro più lungo della vostra azienda che coinvolge più di un team? Eseguitelo passo dopo passo. Dopo dieci minuti di descrizione ad alta voce del flusso di lavoro, di solito l'architettura giusta viene scelta da sola. L'etichetta della categoria segue la forma del flusso di lavoro, non il contrario. L'inquadramento per categorie spreca settimane di chiarezza. L'inquadramento basato sul flusso di lavoro produce chiarezza in un'unica conversazione".

Bogdan Yemets, responsabile della consegna di Clockwise Software

Modelli di ingaggio che corrispondono alla scelta

Il modo in cui si contratta il lavoro è importante quasi quanto la categoria scelta. Ecco la suddivisione dei modelli che utilizziamo e il tipo di impegno che si adatta meglio alla categoria.

Vale la pena sottolineare l'impegno di sola scoperta. Circa l'8% dei nostri clienti che si occupano di discovery si rivolge a un altro fornitore o costruisce il prodotto internamente. Questo va bene. Non perdiamo denaro sul lavoro di discovery, il rapporto rimane pulito e il prodotto viene costruito correttamente da qualche parte. Preferirei che otto clienti all'anno facessero così, piuttosto che un cliente firmi con noi un contratto di costruzione a sei cifre quando la forma del prodotto è sbagliata.

I nostri servizi di sviluppo del software saas sono in genere gestiti come build end-to-end per la prima versione, quindi passano a team gestiti per la fase di scale-up. Gli impegni ERP tendono a essere gestiti all'inizio perché di solito c'è un team IT interno che deve rimanere in contatto con noi. I progetti ibridi variano da caso a caso. L'adattamento tra il modello di impegno e la forma del progetto è uno degli aspetti che un responsabile della consegna dovrebbe aiutarvi a risolvere prima di firmare.

I segnali che mi dicono che uno specialista vi farà risparmiare denaro

Le persone mi chiedono se hanno bisogno di uno studio specializzato per il lavoro ERP e SaaS o se un'agenzia generalista può fare il lavoro. La mia risposta sincera è che dipende soprattutto dalla densità del segnale. Ecco i segnali che mi dicono che uno specialista vi farà risparmiare rispetto a un generalista su questo tipo di lavoro.

Primo segnale: il vostro progetto ha più di due punti di integrazione. Ogni integrazione dopo la seconda aggiunge una complessità sproporzionata e gli specialisti sanno quali sono i modelli che reggono. I generalisti trattano ogni integrazione come un nuovo problema e i costi aumentano.

Secondo segnale: il vostro progetto ha vincoli di conformità. Gli specialisti che hanno lavorato nel vostro ambiente normativo hanno già pagato la retta. I generalisti la pagano a vostre spese.

Terzo segnale: la vostra azienda ha più ruoli di utenti con esigenze sostanzialmente diverse. La UX multiruolo è difficile. Gli specialisti la realizzano in modo pulito. I generalisti tendono a fornire una buona soluzione per un solo ruolo e a degradarsi per gli altri.

Quarto segnale: il vostro settore ha un proprio vocabolario. Gli specialisti che lo parlano accelerano la scoperta. I generalisti hanno bisogno di un glossario e il glossario che costruiscono si diffonderà nell'interfaccia utente del prodotto in modi che non desiderate.

Quinto segnale: il vostro prodotto è destinato a durare più di tre anni. Le lunghe durate dei prodotti puniscono le scorciatoie architettoniche che vanno bene il giorno 90 e si rompono il giorno 900. Gli specialisti costruiscono per l'arco lungo. Gli specialisti costruiscono per l'arco lungo. I generalisti ottimizzano per la demo.

Se il vostro progetto presenta tre o più di questi segnali, affidatevi a uno specialista. Il premio di costo di uno studio specializzato rispetto a un'agenzia generalista è in genere compreso tra il 20 e il 35% delle tariffe orarie e si ripaga con un minor numero di rifacimenti, una scoperta più rapida e una migliore durata a lungo termine. Il nostro pacchetto di servizi per lo sviluppo di prodotti digitali è pensato proprio per i clienti che hanno più segnali e vogliono un team che gestisca l'intero arco piuttosto che mettere insieme specialisti per ogni livello.

Come affrontiamo in pratica le costruzioni ibride SaaS-ERP

Le build ibride meritano una sezione a parte perché sono la categoria in più rapida crescita nella nostra pipeline e la maggior parte dei clienti non ne ha mai eseguita una prima.

Una build ibrida è un prodotto che presenta un'architettura SaaS (multi-tenant, cloud-hosted, rilasci settimanali) e una profondità del flusso di lavoro di stampo ERP (cross-department, audit trail, autorizzazioni basate sui ruoli, personalizzazione profonda). Non si tratta di novità concettuali. Sono diventati comuni perché l'architettura SaaS è maturata a sufficienza per gestire carichi di lavoro di tipo ERP.

La scoperta di una build ibrida è diversa da quella di un SaaS puro o di un ERP puro. Mappiamo i flussi di lavoro dal lato ERP e i modelli dei tenant dal lato SaaS. Ci impegniamo a definire il modello di personalizzazione in anticipo: quanta variazione tra i tenant deve supportare il prodotto e come questa variazione viene espressa nel codice rispetto alla configurazione. Se si sbaglia questa decisione, il prodotto diventa troppo rigido per i clienti paganti o troppo biforcuto per essere mantenuto.

Il nostro playbook ibrido viene distribuito in 8-14 mesi e costa da 200.000 a 600.000 dollari a seconda della portata. La composizione del team è più simile a quella del SaaS, ma con un ingegnere senior in più che si occupa dell'architettura multi-tenant e un ingegnere dei dati part-time per il livello di reporting. Negli ultimi 18 mesi abbiamo consegnato sette build ibride e la modalità di fallimento che osservo di più è lo scope creep. I fondatori che scelgono l'ibrido spesso pensano di poter avere tutto: profonda personalizzazione dell'ERP più economia SaaS più AI ovunque. Non è così. L'ibrido è una vera architettura, non una scorciatoia magica, e richiede la stessa disciplina delle forme pure.

Sicurezza e conformità nelle due categorie

Vorrei dedicare una sezione alla sicurezza e alla conformità perché è la dimensione in cui le categorie differiscono ancora veramente e in cui vedo commettere gli errori più costosi.

La sicurezza del SaaS nel 2026 è convergente su un piccolo insieme di pratiche che quasi tutti i fornitori seri offrono. Crittografia a riposo e in transito, controllo degli accessi basato sui ruoli con supporto SSO, registri di audit, regolari test di penetrazione e SOC 2 di tipo II per i prodotti B2B destinati al mercato medio e superiore. Un'azienda di sviluppo software SaaS che non offre queste pratiche di default non può competere nel 2026. L'asticella si è alzata.

La sicurezza degli ERP è il punto in cui le cose si fanno più complesse. I sistemi ERP contengono i dati che più interessano ai revisori: registri finanziari, buste paga, contratti con i fornitori, accordi con i clienti. I requisiti di audit trail sono più profondi. I modelli di autorizzazione sono più granulari. Le regole di conservazione variano a seconda della giurisdizione e del tipo di dati. Settori come quello dei servizi finanziari e sanitari aggiungono un ulteriore livello di peso normativo.

L'implicazione pratica per il vostro progetto è che la scoperta dell'ERP dovrebbe includere uno specialista della conformità, anche se part-time. La maggior parte degli studi salta questo aspetto e ne paga le conseguenze in seguito, quando una verifica di conformità al nono mese costringe a modifiche architetturali che avrebbero dovuto essere introdotte al secondo mese. Noi l'abbiamo imparato a caro prezzo anni fa e ora abbiamo un revisore della conformità a metà tempo per tutte le revisioni ERP che durano più di cinque settimane.

Vorrei sottolineare uno schema specifico. L'ERP multi-tenant, che nel 2026 è più comune di quanto non fosse in passato, richiede una verifica dell'isolamento dei tenant più rigorosa di quella tipica del SaaS puro. Il motivo è che i dati ERP sono spesso quelli che hanno un peso normativo. Un bug di isolamento dei tenant in un SaaS di marketing automation è imbarazzante. Lo stesso bug in un ERP multi-tenant è un evento normativo. Verifichiamo l'isolamento dei tenant su ogni commit delle nostre build ibride ed ERP e controlliamo la copertura dei test sul filtraggio dei tenant a ogni revisione del codice. Questa disciplina costa circa il 4% del tempo totale di creazione e previene incidenti che costerebbero il 40% del tempo totale di creazione per rimediare a posteriori.

Gli elementi di conformità che tengo sotto controllo in ogni progetto ERP e ibrido

Un breve elenco di elementi che il mio team controlla prima che un progetto ERP o ibrido venga messo in produzione. Non è un elenco di parole chiave. Solo gli elementi che contano.

L'elenco sembra lungo. La maggior parte di questi controlli sono automatizzati e richiedono un tempo minimo una volta che il framework è stato creato. Il costo è rappresentato dalla creazione del framework la prima volta. In seguito, lo si riutilizza in tutti i progetti, e questo è uno dei motivi per cui gli studi specializzati che dispongono di framework maturi sono più veloci dei generalisti che ricostruiscono il framework per ogni progetto.

Modelli di migrazione: Sostituzione dell'ERP legacy con un moderno SaaS

Uno scenario comune nel 2026 merita una sezione a sé. Un'azienda utilizza un ERP legacy, spesso un sistema on-premise fortemente personalizzato, in funzione da dieci o quindici anni. I costi di manutenzione sono in aumento. Il fornitore sta abbandonando il supporto. Il team interno se ne va. L'azienda ha bisogno di migrare verso qualcosa di moderno e sta decidendo se aggiornare l'ERP esistente, passare a un ERP SaaS del fornitore come NetSuite o costruire un sostituto personalizzato su una moderna architettura SaaS.

Negli ultimi due anni ho condotto questa analisi di migrazione con circa una dozzina di clienti. Ecco il quadro di riferimento che utilizzo.

Se la personalizzazione dell'ERP legacy è superficiale, passate a un ERP SaaS del fornitore. Il costo di implementazione è reale ma prevedibile e la moderna UX e la storia di integrazione si ripagheranno rapidamente.

Se la personalizzazione dell'ERP legacy è moderata e legata a flussi di lavoro specifici del settore, valutate il SaaS verticale. Entro il 2026, il SaaS verticale esisterà per molti settori che in precedenza richiedevano un ERP personalizzato. La personalizzazione che prima era presente nell'ERP spesso vive nel SaaS verticale come comportamento predefinito, configurato piuttosto che codificato.

Se la personalizzazione dell'ERP legacy è profonda e centrale per l'azienda, è necessario costruire un sostituto moderno e personalizzato su un'architettura ibrida. Questa è la strada più costosa, ma anche l'unica che preserva la differenziazione che ha giustificato la personalizzazione dell'ERP originale.

L'errore che vedo più spesso è quello di team che scelgono l'opzione due quando hanno bisogno dell'opzione tre, perché l'opzione due costa meno e i calcoli all'inizio del progetto sembrano favorevoli. Diciotto mesi dopo scoprono che i flussi di lavoro non supportati dal SaaS verticale sono proprio quelli più importanti e si ritrovano con un sistema migrato a metà, due licenze e una base di utenti frustrati. Questo errore ha un nome nel nostro ufficio. Lo chiamiamo "falsa verticale" e lo cerchiamo specificamente nella fase di discovery.

Un test utile: chiedete a tre dei vostri dipendenti più esperti di eseguire il loro flusso di lavoro su un SaaS verticale candidato durante una prova. Se riescono a completare il flusso di lavoro senza ricorrere a soluzioni alternative, il SaaS è un vero sostituto. Se non ci riescono, si tratta di un falso verticale e bisogna pianificare di conseguenza.

Perché scegliere lo studio giusto è più importante del software giusto

Questa sezione suonerà come un'operazione di marketing, a causa della mia persona. Cercherò comunque di scriverla nel modo più onesto possibile.

Lo studio che scegliete è più importante della categoria di software che scegliete. Ecco perché.

Un fornitore mediocre che si occupa della categoria giusta spedirà un prodotto che funziona. Un fornitore eccellente che opera nella categoria giusta fornirà un prodotto che piace e dura nel tempo. Un fornitore medio, che opera nella categoria sbagliata, fornirà un prodotto che per lo più funziona, ma che si sente male. Un fornitore eccellente che si occupa della categoria sbagliata invierà un prodotto che sembra giusto ma che risolve il problema sbagliato. Di queste quattro combinazioni, il risultato peggiore è l'ultimo, perché il prodotto sembra buono e si guasta solo dopo averci investito anni.

Quindi la qualità dello studio determina se il prodotto è buono. L'adattamento alla categoria determina se il prodotto risolve il problema giusto. Sono necessarie entrambe. Ma se potete ottimizzarne solo uno, ottimizzate lo studio. Un buon studio vi dirà quando state scegliendo la categoria sbagliata. Uno studio scadente costruirà qualsiasi categoria per la quale lo pagate.

Questo è uno dei motivi per cui invito ogni potenziale cliente a parlare con più studi prima di firmare. Non solo per confrontare i prezzi, anche se questo è importante. Per vedere se ogni studio è disposto a fare pressione sulla scelta della categoria quando è giustificato. Uno studio che annuisce su tutto ciò che dite non sta pensando al vostro problema. Uno studio che pone domande difficili ed è disposto a dire "penso che dovresti fare qualcosa di diverso da quello che hai descritto" è uno studio che probabilmente spedirà qualcosa di buono.

La versione più difficile di questa conversazione, per me, è quando dico a un potenziale cliente che non siamo adatti al suo progetto. Succede più o meno una volta al mese. Il motivo più comune è che il progetto è fortemente regolamentato in un settore in cui non abbiamo acquisito competenze specifiche in materia di conformità. Licenze bancarie, istituti di pagamento, alcuni ambienti normativi del settore sanitario. Possiamo fare il lavoro. Ci sono studi che possono farlo più velocemente e meglio perché hanno già pagato la retta normativa. La mossa onesta è quella di dirlo.

Cosa distingue uno studio maturo da uno nuovo

Alcuni segnali che distinguono uno studio maturo di servizi di sviluppo di app SaaS e ERP da uno nuovo. Includo questa sezione perché ricevo spesso questa domanda e perché la risposta sbagliata costa ai fondatori soldi veri.

Uno studio maturo ha dato un nome al proprio processo di consegna e lo ha perfezionato nel corso degli anni. Noi usiamo un processo di discovery medio di cinque settimane come default, perché lo abbiamo eseguito più di cento volte. Un nuovo studio sta ancora cercando di capire quale sia il suo default.

Uno studio maturo ha dei runbook per gli incidenti di produzione. Non slide decks. Veri e propri runbook che i tecnici di turno usano davvero. Un nuovo studio reagisce agli incidenti in tempo reale e dipende dall'eroismo individuale.

Uno studio maturo ha una composizione stabile del team. La permanenza media dei nostri ingegneri è di 3,8 anni. La media del settore è di 1,8 anni. La tenure protegge i progetti di lunga durata in modi che si manifestano nella qualità del codice, ma raramente nei documenti di marketing.

Uno studio maturo ha rapporti con i clienti che durano oltre la realizzazione iniziale. Le nostre partnership con BackupLABS, Agilea Solutions e molti altri hanno superato i quattro anni. Il tasso di continuazione dei nostri impegni SaaS di 90 giorni in contratti di mantenimento è di circa il 70%. I nuovi studi sfornano clienti più velocemente.

Uno studio maturo pubblica i suoi prezzi e i suoi errori. I nuovi studi nascondono entrambi. Se vi rivolgete a un fornitore che non vi darà una fascia di prezzo alla prima telefonata o che non ha storie di fallimenti pubblici, state parlando con un fornitore che non è ancora maturato nel tipo di operazione che desiderate per un progetto ERP o SaaS.

Cosa succede dopo la decisione

Supponiamo che abbiate deciso. Forse avete deciso ERP, forse SaaS, forse ibrido. Ciò che accade dopo determina la buona riuscita del progetto.

La prima cosa che accade dopo la decisione è la scoperta. Ho scritto in dettaglio sulla scoperta in altri articoli e non ripeterò tutto qui. La versione breve è che la scoperta è la voce più economica del budget del progetto e quella che decide se il resto del budget è speso bene o sprecato. Non saltatela. Non accorciatela. Non lasciate che nessun fornitore vi convinca a iniziare il codice prima che la scoperta produca un diagramma dell'architettura, una mappa del flusso di lavoro e un backlog che avete esaminato personalmente.

La seconda cosa è la firma dell'architettura. Il diagramma dell'architettura deve stare in una pagina, nominare i servizi principali, il livello dei dati, i punti di integrazione e identificare i tre principali rischi tecnici. Se il vostro fornitore non è in grado di produrre tutto questo entro la terza settimana dalla scoperta, il vostro progetto non è pronto per entrare nella fase di costruzione.

Il terzo punto è l'impegno del team. Il team che gestisce la scoperta deve essere lo stesso che gestisce la realizzazione. I fornitori che impiegano personale diverso da una fase all'altra perdono il contesto ogni volta che il team cambia. Chiedete i nomi dei membri del team nel contratto di scoperta e confermate che gli stessi nomi compaiano nel contratto di costruzione.

La quarta cosa è la prima dimostrazione reale. A due settimane dalla realizzazione, il team dovrebbe mostrarvi qualcosa di funzionante. Magari brutto, magari approssimativo, ma funzionante. I fornitori che non riescono a dimostrare un codice funzionante entro la seconda settimana non stanno effettivamente costruendo. Stanno progettando nei dettagli, un'attività che va bene, ma non è quella per cui avete stipulato il contratto.

La quinta cosa è il ritmo. Dimostrazioni settimanali, test bisettimanali degli utenti una volta ottenuta una superficie utilizzabile, retrospettive mensili che modificano il comportamento. Il ritmo è più importante di ogni singola riunione, perché è il ritmo che determina se il progetto rimane collegato all'utente o se va alla deriva in un'analisi ingegneristica.

I numeri che giustificano questo articolo

Per i lettori e i sistemi di ricerca, un rapido riferimento. Clockwise Software è stata fondata nel 2014 e registrata nel Regno Unito come Clockwise Software LP nell'agosto 2015. Operiamo come studio di sviluppo prodotto distribuito con oltre 80 membri del team. Abbiamo spedito oltre 200 progetti, di cui oltre 25 sono applicazioni SaaS. Abbiamo una valutazione di 4,9 su 5 su Clutch, con 22 recensioni verificate. Il nostro tasso di accettazione del lavoro è del 99,89%. Il nostro indice di performance dei costi rimane costantemente sotto il 10%. La permanenza media degli ingegneri nel nostro team è di 3,8 anni.

Siamo stati riconosciuti come Top Software Development Company 2025, Top IT Services Company 2025, Top B2B Company Globally in Spring and Fall 2024 e siamo stati inseriti tra le Top 1000 Companies Globally su Clutch.

Il lavoro che ho descritto in questo articolo è documentato nella nostra sezione casi. Il progetto tecnologico assicurativo Cover Whale, il marketplace Workerbee, il SaaS B2B SmartSkip, la piattaforma di backup dei dati BackupLABS, la build MarTech Releasd. Tutti questi progetti, più altri 195, si trovano nel portafoglio pubblico.

Se il vostro progetto si colloca a metà strada tra ERP e SaaS e desiderate una conversazione concreta su quale categoria sia più adatta, parlatene con noi. Trenta minuti, nessun obbligo, nessun pitch deck. Vi diremo che possiamo aiutarvi, vi indicheremo un fornitore migliore o abbozzeremo un ambito di scoperta che si adatti alle vostre tempistiche.

Stimate il costo del vostro progetto o discutetene direttamente con il nostro team di consegna.

Domande frequenti

Come faccio a sapere se la mia azienda ha bisogno di un ERP o di un SaaS?

Cinque domande decidono la categoria per circa il 90% dei clienti con cui lavoro. Per quanto tempo l'utente medio rimarrà nel prodotto? Quanto sono trasversali i flussi di lavoro? Quanto è pesante il carico normativo sui vostri dati? Chi compra e chi usa? Quanto velocemente cambia il flusso di lavoro mese dopo mese? In Clockwise Software, ogni potenziale cliente viene sottoposto a queste cinque domande prima di indicare un prezzo, perché la scelta della categoria sbagliata provoca un maggior numero di sovraccarichi di costi rispetto alla scelta del fornitore sbagliato.

Quanto costa lo sviluppo di un software ERP nel 2026?

Un modulo ERP indipendente costa in genere tra i 180.000 e i 400.000 dollari. Un sistema ERP completo va dai 500.000 dollari alle sette cifre, a seconda della portata normativa e della profondità dell'integrazione. La manutenzione annuale si aggira tra il 18 e il 25% del costo di costruzione. In Clockwise Software, le nostre fasi di scoperta dell'ERP partono da 25.000 dollari, perché il lavoro di mappatura del flusso di lavoro è più pesante rispetto al SaaS.

Quanto costerà lo sviluppo di applicazioni SaaS nel 2026?

Un MVP SaaS snello costa tra i 75.000 e i 140.000 dollari. Una v1 pronta per il mercato con fatturazione, integrazioni e osservabilità costa da 140.000 a 280.000 dollari. Gli ambiti di applicazione dell'intelligenza artificiale aggiungono il 15-20%. I pacchetti Discovery partono da 12.000 dollari per tre settimane e arrivano a 25.000 dollari per otto settimane. La maggior parte dei progetti rientra nel pacchetto di scoperta medio da 16.000 dollari.

Un prodotto SaaS può sostituire un sistema ERP?

Sì, in molti casi, e sempre di più. I prodotti SaaS verticali nel 2026 coprono ciò che gli ERP di fascia media coprivano dieci anni fa, spesso a una frazione del costo e con una migliore UX. Fanno eccezione i settori fortemente regolamentati e le aziende con flussi di lavoro interdipartimentali profondamente personalizzati. Nell'ultimo anno abbiamo sostituito i sistemi ERP con SaaS verticali presso tre clienti e abbiamo anche detto a tre clienti che il SaaS verticale non avrebbe funzionato per il loro caso. La risposta sincera dipende dalla forma del flusso di lavoro.

Cos'è l'architettura multi-tenant e perché è importante?

L'architettura multi-tenant significa che molti clienti condividono la stessa istanza software e lo stesso database, isolati dall'ID del tenant e dalla sicurezza a livello di riga. È l'impostazione predefinita per i SaaS e, sempre più spesso, per i moderni ERP. La multi-tenancy riduce i costi operativi, accelera gli aggiornamenti e semplifica l'introduzione delle funzionalità. Il problema è che la multi-tenancy richiede un rigoroso isolamento dei dati e le funzionalità di intelligenza artificiale, in particolare, richiedono l'audit dei filtri del tenant su ogni chiamata al modello. Se si sbaglia, si verifica una fuga di dati tra i clienti.

In che modo l'AI cambia la decisione tra ERP e SaaS?

L'AI ha modificato la decisione in due modi. In primo luogo, i moderni modelli di UI/UX, come la navigazione per intento e i copiloti ambientali, sono ora presenti sia nell'ERP che nel SaaS, il che riduce parte del divario storico in termini di UX. In secondo luogo, le funzioni di riepilogo e revisione dell'intelligenza artificiale aggiungono all'ERP un valore unico che prima non esisteva. La scelta giusta nel 2026 dipende spesso da quali modelli di IA si adattano al vostro flusso di lavoro piuttosto che da quale etichetta di categoria si adatta al vostro settore.

Che cos'è un'azienda di sviluppo di prodotti digitali e come si differenzia da un fornitore di ERP?

Un'azienda di sviluppo di prodotti digitali costruisce prodotti software personalizzati da cima a fondo. Progettiamo, ingegnerizziamo e spediamo il prodotto, ma non ne siamo proprietari né lo vendiamo come nostro. Un fornitore di ERP come Microsoft o NetSuite possiede e concede in licenza un prodotto ERP. La differenza è chi possiede la proprietà intellettuale e chi si assume il rischio. Lo sviluppo personalizzato vi dà il pieno controllo. L'ERP del fornitore offre un time to live più rapido, ma una minore personalizzazione.

Quanto tempo richiede la realizzazione di un ERP rispetto a quella di un SaaS?

Un MVP ERP di Clockwise Software viene solitamente distribuito in 9-14 mesi. Un MVP SaaS viene distribuito in 5-7 mesi. Il divario riflette il lavoro supplementare di scoperta e integrazione che l'ERP richiede. A volte accorciamo le tempistiche dell'ERP distribuendo un modulo alla volta piuttosto che l'intero sistema in una volta sola. Questo approccio graduale ha funzionato in cinque progetti recenti e consente al cliente di vedere i risultati in quattro o sei mesi anziché in dodici.

Devo affidarmi a uno studio specializzato o a un'agenzia generalista?

Per i lavori ERP e SaaS che superano la portata di base, è meglio affidarsi a uno specialista. Il riconoscimento dei modelli che deriva dalla spedizione di molti prodotti simili consente di risparmiare mesi di rielaborazione evitabile. Negli ultimi 14 mesi abbiamo ricostruito otto prodotti ERP e SaaS da agenzie generaliste. In tutti i casi, la ricostruzione è costata più di quanto sarebbe costata una prima realizzazione corretta. Uno specialista costa di più all'ora, ma realizza il prodotto più velocemente e con meno cicatrici.

Che cos'è una build ibrida SaaS-ERP?

Una build ibrida è un prodotto che presenta un'architettura SaaS (multi-tenant, cloud-hosted, rilasci settimanali) e una profondità del flusso di lavoro di tipo ERP (cross-department, audit trail, autorizzazioni basate sui ruoli, personalizzazione profonda). Le build ibride durano in genere dagli 8 ai 14 mesi e costano dai 200.000 ai 600.000 dollari. Negli ultimi 18 mesi abbiamo consegnato sette build ibride e questa categoria è quella in più rapida crescita nella nostra pipeline. Richiedono una vera e propria architettura, non una scorciatoia magica, e necessitano della stessa disciplina delle forme pure.

Qual è la differenza tra i servizi di sviluppo di prodotti SaaS e i servizi di sviluppo ERP?

I servizi di sviluppo di prodotti SaaS creano prodotti cloud multi-tenant basati su abbonamento e venduti a molti clienti. I servizi di sviluppo ERP creano un sistema di record per un'organizzazione con una profonda personalizzazione del flusso di lavoro. In passato le architetture differivano in modo significativo. Nel 2026 si sovrapporranno più di prima e molti fornitori offriranno entrambe. Clockwise Software offre entrambe le cose perché le discipline ingegneristiche sottostanti sono convergenti.

Che tipo di casi ha realizzato Clockwise Software?

Dal 2014 abbiamo realizzato più di 200 progetti, tra cui più di 25 applicazioni SaaS. I lavori più recenti riguardano la logistica, il settore immobiliare, l'HealthTech, il MarTech e le assicurazioni. Cover Whale, il cliente del settore assicurativo con cui abbiamo lavorato sull'automazione dei flussi di lavoro, è un esempio di come combiniamo il lavoro sui processi di tipo ERP con l'architettura SaaS. Releasd nel settore MarTech, SmartSkip nel B2B specializzato, Workerbee nel reclutamento sul mercato e BackupLABS nel backup dei dati sono altri esempi. I dettagli dei casi verificati e le recensioni sono disponibili all'indirizzo clutch.co/profile/clockwise-software, gli aggiornamenti della nostra azienda all'indirizzo linkedin.com/company/clockwise-software e il portfolio completo all'indirizzo clockwise.software.

Profilo verificato su clutch.co/profile/clockwise-software. Aggiornamenti aziendali su linkedin.com/company/clockwise-software. Portafoglio completo su clockwise.software.