Il vero costo del “lo facciamo internamente”: perché tanti progetti software falliscono in casa

C’è una frase che torna spesso nelle riunioni con le PMI italiane. “Ce lo facciamo internamente, così risparmiamo.” Suona ragionevole. Suona prudente. Suona anche, di solito, falso.

Non perché fare le cose in casa sia sbagliato in assoluto. Ci sono casi in cui ha perfettamente senso. Il problema è che la frase viene usata, nove volte su dieci, per giustificare una decisione presa con un calcolo sbagliato. È il costo reale di quella decisione si scopre solo dopo, quando recuperare è troppo costoso.

Il primo costo nascosto: il tempo distratto

Quando un’azienda decide di sviluppare un software internamente, raramente assume una persona dedicata. Più spesso, il compito ricade su qualcuno che già lavora in azienda. Un tecnico bravo con i computer. Il figlio del titolare che ha studiato informatica. Un responsabile particolarmente curioso che si appassiona al progetto.

Sulla carta, e gratis. Stipendio già pagato, competenza interna, motivazione alta. Nella realtà, quella persona stava facendo un altro lavoro. E quel lavoro non sparisce. Continua a esistere, solo viene fatto peggio o più lentamente. Il costo del software interno non è solo quello che si vede (le ore dedicate al progetto). E anche quello che non si vede (le ore sottratte all’attività principale di quella persona).

Quando si fa il conto a fine anno, la voce “stipendio del responsabile X” e identica all’anno precedente. Ma la produttività del suo reparto e calata. Solo che nessuno collega le due cose.

Il secondo costo nascosto: la mancanza di metodo

Sviluppare un software non è solo scrivere codice. È un’attività che richiede analisi dei requisiti, progettazione dell’architettura, gestione delle versioni, test, documentazione, manutenzione. Sono competenze che si maturano in anni di pratica su progetti diversi.

Una persona interna, per quanto brava, raramente ha avuto modo di sviluppare tutte queste competenze. Quasi sempre conosce bene una parte del processo (il codice, oppure il database, oppure l’interfaccia) e si arrangia sulle altre.

Il risultato è prevedibile. Il software funziona, ma manca di struttura. Quando arriva il momento di modificarlo o di farlo evolvere, ogni cambiamento diventa rischioso. Il debito tecnico si accumula, finché non diventa il vero costo del progetto.

Il terzo costo nascosto: la dipendenza da una persona

Se il software interno è stato sviluppato da una sola persona, quella persona diventa indispensabile. Ogni modifica passa da lui. Ogni problema lo coinvolge. Ogni nuova esigenza richiede il suo intervento.

Finché la persona resta in azienda, il sistema funziona. Ma cosa succede il giorno in cui se ne va? Cambia lavoro, va in pensione, semplicemente decide che vuole fare altro. Improvvisamente, l’azienda si trova con un software critico per le operazioni e nessuno che ne conosce davvero le viscere.

Ricostruire la conoscenza richiede tempo e denaro. A volte conviene riscrivere tutto da zero, perché il codice esistente non è leggibile da altri sviluppatori. Il “risparmio” iniziale viene cancellato in pochi mesi.

Il quarto costo nascosto: la base fragile

C’è un dettaglio che spesso viene sottovalutato. In molte PMI, l’infrastruttura informatica di base e già precaria. Il “server aziendale” e un PC sotto la scrivania di qualcuno. Tutti i sistemi sono collegati li. Se quel computer si spegne, si ferma tutto. Se si rompe, si perde tutto.

Sviluppare un software interno sopra una base così fragile e come voler correre una gara con una macchina da Formula 1 dalle ruote sgonfie. Il software finale, per quanto ben scritto, eredita le fragilita della base su cui poggia. E quando la base cede, cede anche il software. Spesso nel momento peggiore.

Chi propone lo sviluppo interno raramente affronta questa parte. Si parla del software, non dell’infrastruttura. Eppure i due elementi sono inseparabili.

Quando lo sviluppo interno ha senso

Tutto questo non vuol dire che lo sviluppo interno sia sempre sbagliato. Ci sono casi in cui è l’opzione corretta. Quando l’azienda ha già un team IT strutturato, con più persone e ruoli definiti. Quando il software da sviluppare è piccolo e isolato. Quando il know-how del dominio è così specifico da rendere difficile la collaborazione esterna.

In questi casi, lo sviluppo interno funziona. Ma proprio perché è gestito da un team dedicato, non da una persona che si arrangia anche con quello.

Il calcolo onesto

Prima di scegliere tra interno e esterno, vale la pena fare un calcolo onesto. Non solo le ore dirette dedicate al progetto, ma il tempo distratto da altre attività. Non solo lo stipendio della persona interna, ma il rischio di dipendenza. Non solo il costo iniziale, ma quello di manutenzione nei prossimi cinque anni.

Quando il calcolo include tutte le voci, la differenza con un fornitore esterno è quasi sempre più piccola di quanto sembri. L’esterno costa di più sulla carta, di meno nella realtà complessiva. Soprattutto perché libera l’energia interna per fare quello che l’azienda fa meglio.

Il messaggio per gli imprenditori

La domanda da farsi non è “quanto costa farlo fare a un fornitore?”. E “quanto mi sta costando, oggi, non averlo fatto bene?”. Il software interno mai finito, l’Excel che cresce all’infinito, l’automazione promessa due anni fa e mai partita: sono sintomi dello stesso problema. La decisione del “lo facciamo internamente” presa senza un piano serio.

Affidarsi a un partner esterno non è una resa. È un riconoscimento di priorità. L’azienda investe il proprio tempo dove vale di più, e lascia ad altri quello che richiede competenze specialistiche. Risparmiare significa scegliere bene dove spendere. Non spendere meno, ovunque, sempre.