Quanto costa davvero un software aziendale? Valutare progetto e gestione nel tempo

«Quanto costa un software gestionale» è una domanda che riceve una risposta inutile: dipende. La domanda utile è un’altra: quali voci di costo comparirebbero nei prossimi tre anni, quali di queste esistono già oggi sotto un altro nome, e che cosa dovrebbe cambiare nel lavoro quotidiano perché l’investimento si giustifichi. Questa guida serve a costruire quel conto con ipotesi scritte, in modo che chiunque in azienda le possa contestare.

Non troverete cifre. Un prezzo di mercato scritto qui sarebbe superato fra un mese e comunque falso per il vostro caso. Troverete l’elenco delle voci e il modo di riempirlo con i vostri numeri.

Le voci del progetto, separate

Il preventivo unico è comodo per firmare e inutile per decidere. Chiedete che sia diviso, perché ogni voce ha un rischio diverso e una persona diversa che lo può ridurre.

• Analisi: capire il processo, le eccezioni e i casi limite. È la voce che si taglia per prima ed è quella che genera le varianti in corso d’opera. Ciò che non si capisce prima si paga dopo.
• Sviluppo: di solito la voce più grande. Va letta insieme al perimetro, perché uno sviluppo economico su un perimetro vago non è un risparmio.
• Migrazione dei dati: portare dentro anagrafiche e storico, ripulirli, decidere che cosa non portare. Viene sottovalutata quasi sempre, perché il lavoro vero non è tecnico ma decisionale: stabilire quale versione di un dato è quella giusta.
• Formazione e affiancamento: non il corso di due ore, ma il tempo delle vostre persone nelle prime settimane, quando lavorano in due modi contemporaneamente.

Le ultime due voci si pagano in buona parte in ore interne. Se non le mettete nel conto, il progetto sembrerà costare meno di quanto costa e i vostri reparti sembreranno improvvisamente lenti senza una ragione scritta da nessuna parte.

Le voci che tornano ogni anno

Il costo ricorrente decide se il progetto è sostenibile. Un investimento iniziale si assorbe; una spesa annuale stimata male pesa finché il sistema esiste. La tabella elenca le voci e il momento in cui compaiono.

Due domande da fare prima della firma: che cosa è compreso nella manutenzione e che cosa no, e con quale criterio si stabilisce se un intervento è una correzione o una richiesta nuova. È il confine su cui nascono quasi tutte le discussioni del secondo anno.

Il beneficio va contato una volta sola

Il beneficio più citato è il tempo risparmiato, ed è anche il più facile da gonfiare. Tre cautele lo rendono difendibile.

• Il tempo risparmiato diventa un risparmio solo se si trasforma in qualcosa: più lavoro svolto con le stesse persone, una scadenza rispettata, una sostituzione non necessaria. Se le ore liberate si distribuiscono su compiti indefiniti il beneficio è reale, ma va scritto in un’altra colonna.
• Non contate due volte lo stesso effetto. Se attribuite un risparmio alla riduzione degli errori, non contate anche le ore risparmiate nel correggerli: è lo stesso beneficio guardato da due lati.
• I benefici incerti vanno dichiarati incerti. «Più ordini gestibili» dipende dal mercato prima che dal software: sta in un conto separato, con la sua ipotesi accanto.

La misura di partenza va presa prima, non ricostruita a memoria dopo. Serve poco e si ottiene in una settimana: quante volte al mese si esegue l’operazione, quanto dura, quante persone la toccano, quanti errori si correggono.

Confrontare scenari, non giustificare quello scelto

Un conto costruito su una sola ipotesi serve a convincere, non a decidere. Gli scenari da mettere accanto sono almeno tre, e uno è sempre lo stesso.

1. Non fare niente. Ha un costo, ed è il costo attuale del problema: ore, errori, ritardi, occasioni perse. Se non lo si scrive, ogni altro scenario sembra solo una spesa in più.
2. Adottare qualcosa di pronto e adattare il modo di lavorare. Costo iniziale minore, canone prevedibile, vincolo su ciò che non si potrà cambiare.
3. Far sviluppare ciò che serve, per intero o solo per la parte che vi distingue. Costo iniziale maggiore, maggiore aderenza, e la responsabilità della manutenzione nel tempo.

Esiste un quarto scenario che spesso vale più degli altri: fare solo il pezzo che fa più male e rimandare il resto. Costa meno, dà una risposta vera in pochi mesi e permette di correggere le ipotesi con dei fatti invece che con delle stime.

Verificare dopo l’avvio

È la parte che quasi nessuno fa, ed è quella che rende utile tutto il resto. A sei e a dodici mesi si riprendono le stesse misure di partenza e si guarda che cosa è successo davvero.

• Le stesse grandezze, misurate allo stesso modo. Cambiare metodo fra prima e dopo è il modo più semplice per dimostrare qualunque cosa.
• Anche gli effetti negativi: passaggi diventati più lenti, lavoro spostato da un reparto a un altro, doppie registrazioni rimaste in piedi.
• Le voci di costo che non erano previste. Servono più al progetto successivo che a questo, ed è il motivo per cui vanno annotate mentre accadono.

Quando i conti dicono di non farlo

Quello che questa guida non copre

Qui si valuta l’investimento in un software aziendale nel suo complesso: voci, benefici, scenari e verifica. I sistemi basati su modelli di intelligenza artificiale hanno voci proprie — consumi legati all’uso, aggiornamento dei modelli, revisione umana delle risposte — che si comportano in modo diverso e sono trattate altrove. Anche la scelta fra gestionale standard e sviluppo su misura, qui ridotta a due scenari, merita un confronto più esteso.