Software su misura o standard? Guida alla decisione B2B

Prima distinzione: standard o il tuo vantaggio?

Contabilità, e-mail, buste paga — processi standard. Migliaia di aziende li eseguono allo stesso modo. I pacchetti standard (SAP, QuickBooks, Workday) sono maturi, sicuri, economici. Sviluppare software su misura qui di solito è uno spreco.

Ma il tuo "vantaggio competitivo" — un algoritmo di pricing proprietario, un'integrazione specifica con un cliente, un particolare flusso operativo — diventa generico nel momento in cui lo spingi in un pacchetto. Il 20 % dell'azienda che genera davvero valore scende a 0 %. Qui il software su misura è irrinunciabile: se usi gli stessi strumenti del tuo concorrente, produci lo stesso risultato.

Quattro domande pratiche

Prima di decidere, rispondi a queste quattro:

1) Il processo è standard del settore o specifico dell'azienda? 2) Il modello dati cambia con il mondo esterno (fatturazione, integrazioni)? Se sì, un software a pacchetto o SaaS con API aperte va bene. 3) Il tuo modello di business attorno a questo processo cambierà nei prossimi 24 mesi? Se sì, il tetto di configurazione di un pacchetto ti bloccherà. 4) Il vantaggio competitivo si nasconde nel processo? Se lo citi spiegando "perché i clienti ci scelgono", il software su misura è obbligatorio.

Due o più risposte "distintive" (unico, vantaggio competitivo nascosto) indicano sviluppo su misura. Altrimenti, parti con un pacchetto e migra al tetto — è la strategia più economica.

L'approccio ibrido: la scelta più pragmatica

Nella vita reale, la maggior parte delle decisioni B2B non è "tutto su misura" né "tutto pacchetto" — è la combinazione intelligente dei due. Lo schema: lo strato standard (contabilità, HR, scheletro CRM, email) gira sul miglior pacchetto sul mercato; lo strato differenziante (motore di pricing, portale cliente, flusso operativo, trasformazione dati) si sviluppa su misura e si integra ai pacchetti via API.

Questo fornisce tre cose: (1) sicurezza del vendor e basso TCO sullo strato commodity, (2) pieno controllo e iterazione rapida sul differenziatore, (3) ogni strato evolve al proprio ritmo. In pratica diventa "SaaS + API + sottile strato applicativo su misura". Con la crescita lo strato su misura si espande; gli strati a pacchetto restano stabili. In Setviva circa il 70 % dei clienti parte ibrido — chi chiede sviluppo interamente su misura, dopo la mappatura dei flussi, sceglie spesso di spostare anche i processi standard su strumenti a pacchetto.

Stimare correttamente il costo di migrazione

L'errore più frequente dei decisori B2B: confrontare solo la licenza o il prezzo del progetto. Il costo reale sta sotto la linea di galleggiamento. Passando al software a pacchetto aggiungi: migrazione e pulizia dei dati, formazione, perdita di produttività durante la transizione, sviluppo di integrazioni, personalizzazione della reportistica, ridisegno dei processi. Di solito somma 3–5 volte la licenza. Passando al su misura aggiungi: design e discovery, sviluppo, test, formazione, manutenzione e iterazione continua, infrastruttura (server, monitoring, backup), rischio di proprietà (chi lo gestisce se il team se ne va). Di solito somma 1,5–2 volte il prezzo di costruzione.

Per un confronto onesto, scrivi il costo totale di proprietà (TCO) a 24–36 mesi e metti le due opzioni sullo stesso piano. In ogni proposta Setviva presentiamo questa TCO voce-per-voce in apertura, così la decisione poggia su "effettivamente economico", non "sembra economico". Stimare bene il costo di migrazione può pesare più della scelta stessa.

Il rischio di lock-in: taglia in entrambe le direzioni

Ogni decisore chiede "quanto costa oggi", ma quasi nessuno chiede "chi avrà la leva su di me tra tre anni". Con il SaaS, la roadmap la scrive il fornitore, non voi. I contratti si rinnovano con aumenti di prezzo che possono diventare pesanti una volta che lo strumento è incastrato nelle vostre operazioni quotidiane; le funzionalità vengono deprecate o spostate in un piano superiore; il fornitore può essere acquisito e il prodotto dismesso secondo tempistiche che non avete scelto voi. Niente di tutto questo è ipotetico: è il normale ciclo di vita dei fornitori di software, e più uno strumento è radicato nelle vostre operazioni, più costoso diventa allontanarsene, anche se il prezzo triplica. Questo non è un motivo per evitare il SaaS — per i processi standard resta di norma la scelta giusta — ma significa che il confronto sul "canone mensile" nasconde la vera domanda: quanta leva state cedendo a una controparte i cui incentivi non coincidono con i vostri?

Il software custom rivolge il problema della leva verso l'interno. Il rischio non è più la roadmap di un fornitore; è il bus factor del vostro stesso team. Se gli sviluppatori che hanno costruito il sistema se ne vanno e le decisioni alla base non sono mai state documentate, il sistema diventa silenziosamente una scatola nera che nessuno vuole toccare. Se lasciato senza manutenzione, le dipendenze invecchiano, le patch di sicurezza smettono di arrivare e alla fine il "custom" si trasforma in esattamente ciò che volevate evitare costruendolo — un sistema fragile e legacy. Il lock-in qui non è una clausola contrattuale, è conoscenza concentrata, ma l'effetto è identico: non potete andarvene senza pagare un prezzo salato.

La soluzione è trattare il costo di uscita come criterio decisionale fin dal primo giorno, su entrambi i fronti. Per il SaaS, prima di firmare, verificate quali dati potete esportare e in che formato, se il contratto pone un tetto agli aumenti di prezzo e quanto sarebbe davvero doloroso andarsene nella pratica. Per il custom, pretendete che la proprietà del codice sorgente, l'accesso all'infrastruttura e una documentazione aggiornata siano deliverable contrattuali, non favori — e scegliete un partner che scrive codice pensando a chi erediterà il sistema in futuro, non solo alla demo. Qualunque strada scegliate, fate la domanda sull'uscita prima di quella sull'acquisto. L'opzione da cui potete allontanarvi vale più dell'opzione che oggi sembra la più economica.