Prima il risultato, poi il prezzo
Non sarebbe serio pubblicare un prezzo valido per qualsiasi prodotto desktop. Una stima utile separa il lavoro per arrivare al primo risultato dai costi per mantenerlo nel tempo. Prima si definisce un percorso verificabile, poi si attribuiscono importi alle attività e alle incognite.
Le guide di Microsoft sull'assessment e di AWS sul business case partono dall'inventario e distinguono il quadro iniziale dalla stima dettagliata. Lo stesso principio vale per il gestionale di una software house: senza conoscere installazioni, dati, dipendenze e risultato richiesto si può dare solo una cifra apparentemente precisa.
Fonti: Microsoft Learn — assessment di modernizzazione · AWS — directional business case
Quattro risultati diversi da mettere a preventivo
Accesso online al prodotto attuale. In alcuni sistemi è possibile rendere utilizzabile via web gran parte del software così com'è, ospitandolo in un ambiente adatto e controllando identità, sessioni, prestazioni e periferiche. In altri, vincoli di architettura o di licenza richiedono adattamenti più importanti. Questo approccio non equivale a riscrivere tutte le schermate.
Nuovi flussi web collegati al core. Un portale clienti, una funzione per gli agenti commerciali o un'integrazione con un e-commerce può usare dati e operazioni già presenti. Il lavoro si concentra sul punto di accesso al core, sul contratto delle operazioni, sulle autorizzazioni e sulla nuova esperienza d'uso. È uno dei possibili interventi di Web Bridge.
Sostituzione di moduli. Se un componente non regge le richieste future, si può spostarne la responsabilità per fasi. Al preventivo entrano la convivenza con il vecchio modulo, i dati condivisi, le verifiche e il piano di ritorno. La strategia va scelta per componente, tenendo conto del valore e della complessità di ogni fase.
Servizio SaaS. Se la software house ospita, aggiorna e assiste centralmente il prodotto per i clienti, assume responsabilità operative nuove. A questo punto il costo di sviluppo non racconta l'intera storia: contano distribuzione, backup, monitoraggio, supporto, isolamento dei dati e costo per cliente. Il passaggio a SaaS è una scelta di modello di servizio, non una conseguenza automatica dell'accesso via browser.
Fonti: Microsoft Learn — pianificare la modernizzazione per fasi
Che cosa fa variare davvero il preventivo
Il primo fattore è l'accessibilità della logica esistente. Il prodotto espone già funzioni richiamabili? Le regole sono concentrate in procedure e librerie oppure mescolate alle schermate? Esistono batch affidabili? Un'integrazione in sola lettura ha un rischio diverso da una che conferma ordini o modifica pagamenti.
Il secondo è la varietà delle installazioni. Un'unica versione gestita centralmente è diversa da molte installazioni personalizzate, con database, plugin e tempi di aggiornamento propri. Occorre capire quanti comportamenti siano davvero comuni e quali clienti dipendano da eccezioni.
Poi ci sono dati e sicurezza: qualità dei dati, autorizzazioni attuali, identità degli utenti, tracciamento delle operazioni, backup e recupero. Portare fuori dalla rete aziendale una funzione richiede di controllare come verrà esposta e chi potrà usarla. Non basta verificare che la schermata si apra.
Infine, il software può dipendere da stampe, lettori, scanner, sistemi di firma o file locali. Questi aspetti non rendono impossibile l'accesso web, ma possono determinare il percorso tecnico. Le licenze del sistema operativo, del database o di componenti di terze parti possono incidere sia sulla realizzazione sia sul costo ricorrente.
Modello di stima: una tantum e ricorrente
L'analisi del prodotto ricostruisce componenti, installazioni, flussi e dipendenze. L'accesso al core richiede interfacce affidabili, API, adapter o batch, e può generare manutenzione successiva. L'esperienza web comprende le schermate da esporre o le funzioni nuove da costruire. Identità e permessi richiedono progettazione e gestione nel tempo.
Test, rilascio e piano di ritorno si ripresentano a ogni cambiamento importante. Licenze e infrastruttura possono avere costi iniziali e ricorrenti; backup, monitoraggio, aggiornamenti e assistenza sono attività operative continuative. Il prezzo finale dipende dal prodotto, dal livello di servizio richiesto e da chi si assume ciascuna attività. Un costo operativo già sostenuto dal cliente potrebbe spostarsi alla software house: va confrontato insieme ai nuovi costi, non nascosto.
- Analisi del prodotto: componenti, installazioni, flussi e dipendenze — costo iniziale; incertezza maggiore se manca documentazione.
- Accesso al core: API, adapter, batch o altre interfacce affidabili — costo iniziale e manutenzione; da provare su un flusso reale.
- Esperienza web: schermate esposte o nuove funzioni — costo iniziale variabile con il perimetro.
- Identità e permessi: utenti, ruoli, accessi da remoto, audit — progettazione iniziale e gestione.
- Test e rilascio: baseline, regressione, ambienti e ritorno — lavoro iniziale e per ogni rilascio.
- Licenze, infrastruttura e operazioni: server, backup, monitoraggio, aggiornamenti e assistenza — costi iniziali e ricorrenti.
Un esempio illustrativo di preventivi non confrontabili
Immaginiamo una software house che chiede a due fornitori «quanto costa mettere online il gestionale?». Il primo stima accesso remoto al prodotto esistente per venti utenti. Il secondo stima un nuovo portale web per consultare ordini e inviare richieste. Entrambi rispondono alla stessa frase, ma consegnano prodotti differenti. Un terzo potrebbe includere hosting e supporto annuale, mentre gli altri lo lasciano al cliente.
È un esempio inventato. Serve a mostrare perché, prima di confrontare cifre, bisogna confrontare risultato, perimetro e responsabilità. La domanda utile è: quali clienti potranno fare cosa al termine della prima fase, attraverso quale canale, e chi gestirà il servizio?
Come chiedere una stima confrontabile
Prepara una descrizione di una pagina con versione e numero di installazioni, funzioni richieste online, utenti previsti, integrazioni indispensabili, dati trattati, personalizzazioni, dispositivi locali e modalità di assistenza attuale. Chiedi che la proposta separi primo esperimento, estensioni successive e gestione ricorrente; che dichiari le ipotesi non verificate; e che spieghi come si misura il successo della prima fase.
Se l'incognita maggiore è interna al prodotto, ha senso finanziare prima un'analisi circoscritta invece di chiedere un prezzo definitivo basato su supposizioni. Il Legacy Assessment di MadeInCode serve a ricostruire opzioni e vincoli e a individuare il primo risultato stimabile.