Il software che nessuno sa più manutenere: partiamo dall'inventario

Contesto

Il software continua a fare il suo lavoro. Gestisce passaggi da cui dipende l'attività dell'azienda e che nessun altro strumento copre. Poi arriva una richiesta, magari aggiornare un collegamento con un altro sistema. Chi lo ha scritto non c'è più e nessuno sa da dove cominciare, né quali conseguenze potrebbe avere la modifica.

Se ti trovi in questa situazione, anche una richiesta ordinaria può restare ferma. Per decidere come gestirla ti servono informazioni che oggi sono sparse, incomplete o affidate alla memoria di qualcuno. Puoi cominciare a recuperarle senza aver già deciso di sostituire il software.

Questo è uno scenario rappresentativo, costruito sulle nostre esperienze di presa in carico. Riunisce problemi che incontriamo nelle aziende manifatturiere e di servizi; non racconta il progetto di un singolo cliente.

La sfida

1. La documentazione non basta a mantenere il sistema. In una discussione su r/ItalyInformatica si legge: «la comunicazione scritta (email, specifiche, documentazione) è carente, scritta male, se non del tutto assente» (13 giugno 2024). Nel caso che descriviamo, puoi avere un buon manuale utente e nessuna indicazione su come funziona il codice o sul perché di certe scelte.

2. Il sapere è concentrato in chi sta per andare via. Nelle migrazioni descritte da synsphere.it (13 maggio 2026), la conoscenza del sistema si concentra spesso in una o due persone, quasi sempre prossime a un cambio di ruolo o alla pensione. Se ogni eccezione passa da loro, il passaggio di consegne richiede di recuperare anche le regole che nessuno ha mai scritto.

3. La ricostruzione non è mai stata provata. Il sistema è in funzione, ma questo non dimostra che tu possa rimetterlo in piedi altrove. Potresti avere una copia del codice senza gli strumenti per compilarlo, oppure un backup mai ripristinato. Finché manca una prova, resta da capire che cosa puoi recuperare e quanto lavoro richiede.

4. Manca un controllo affidabile sulle modifiche. Senza test sui comportamenti attuali, la verifica dipende da chi ricorda che cosa provare. Una correzione può avere effetti che emergono solo durante il lavoro. Le richieste restano quindi in attesa e chi usa il sistema trova rimedi manuali, con un impegno che raramente viene registrato.

I numeri da guardare

Puoi partire da queste domande usando le informazioni che hai. Dove non trovi una risposta, annota che cosa manca: serve anche a delimitare il lavoro dell'inventario.

• Quante persone sanno far funzionare questo sistema? Conta chi saprebbe intervenire su un guasto.
• Quante richieste, nell'ultimo anno, hanno richiesto l'intervento del vecchio fornitore o della persona che conosce il sistema?
• Quanti giorni servono per capire una modifica prima di poterla stimare e realizzare?
• Per quante funzioni critiche manca un referente? Verifica se sai chi coinvolgere per capire un'anomalia e controllarne la correzione.
• Hai accesso al codice sorgente completo in un archivio controllato dall'azienda? Una copia del server, da sola, non risponde alla domanda.
• Una persona diversa da chi lo mantiene oggi riesce a ricostruirlo su una macchina nuova seguendo istruzioni scritte?
• Quando è stato eseguito l'ultimo ripristino di prova, con quale esito e in quanto tempo?

L'approccio

1. Prima l'inventario. Partiamo dal codice e dagli accessi disponibili. Censiamo gli ambienti, le dipendenze esterne e le licenze. Esaminiamo anche la base dati, i sistemi che la leggono e le attività pianificate: un'elaborazione notturna può essere essenziale senza comparire nel manuale. Per ogni elemento annotiamo dove si trova e chi lo controlla. Le informazioni mancanti restano visibili nell'inventario, con le verifiche necessarie per recuperarle.

2. Ricostruiamo la documentazione con chi ci lavora. Leggiamo il codice e chiediamo alle persone di mostrarci come gestiscono il lavoro quotidiano, comprese le eccezioni. Una regola che sembra un errore può rispondere a un'esigenza ancora valida. Ti chiediamo di coinvolgere chi la conosce e concordiamo il tempo necessario. Scriviamo istruzioni che qualcuno possa seguire, poi le proviamo con una persona che non le ha redatte.

3. Scriviamo i test prima di modificare il codice. Partiamo dalle operazioni da cui dipende il lavoro dell'azienda. I test registrano che cosa fa oggi il software, compresi i comportamenti insoliti, così possiamo confrontare ciò che accade dopo una modifica. Riprodurre un comportamento in un test non significa considerarlo corretto: un eventuale errore va discusso prima di cambiarlo. Documentiamo anche le funzioni ancora prive di test, dove servirà una verifica manuale.

4. Confrontiamo le opzioni, compresa quella di tenerlo così. Solo a questo punto valutiamo se mantenerlo, rifarne una parte o sostituirlo con uno strumento standard. Per ogni opzione indichiamo i costi stimabili e gli ostacoli ancora da chiarire. «Tenerlo così ancora due anni» è un esito legittimo dell'analisi. Quando è la scelta sensata, lo scriviamo insieme alla manutenzione necessaria e alle condizioni che richiederebbero di rivederla. Conservare il sistema comporta comunque un impegno: va reso visibile, come quello di cambiarlo.

Che cosa cambia

Il risultato atteso è una base consultabile per decidere. Sai dove cercare il codice e quali accessi mancano. Se il ripristino è stato provato, hai un esito documentato e un tempo misurato; se non è riuscito, sai quali ostacoli abbiamo trovato.

Davanti a una richiesta di modifica puoi chiedere una stima fondata sulle parti coinvolte, con le incertezze esplicite. Puoi preparare un passaggio di consegne sapendo quali conoscenze devono ancora essere recuperate.

Anche la domanda «conviene ancora tenerlo?» diventa affrontabile. Hai elementi per confrontare il costo della manutenzione con quello della sostituzione, compreso il lavoro che ricadrebbe sulle persone della tua azienda.

Che cosa temono, e che cosa rispondiamo

«L'inventario farà crescere il lavoro e la spesa.» Può succedere. Un componente non più supportato o un servizio esterno dimenticato possono richiedere verifiche e interventi aggiuntivi. Concordiamo all'inizio il perimetro dell'analisi; se emerge un approfondimento che lo supera, ti spieghiamo che cosa manca e quale lavoro richiede prima di procedere. Se un problema va risolto, il costo si aggiunge a quello dell'analisi. Ti aiutiamo a distinguere ciò che puoi rimandare da ciò che condiziona il prossimo intervento.

«Se il software non si ricompila, l'analisi sarà stata una spesa inutile.» La ricostruzione può fallire, e il tempo speso per provarla resta un costo. Per questo la verifichiamo presto, in un ambiente separato da quello in uso. Se manca un componente irrecuperabile, documentiamo il blocco e ti diciamo che cosa possiamo ancora fare: osservare il comportamento del sistema, verificare il recupero dei dati o valutare una sostituzione. Sono attività con un proprio costo, da concordare prima di proseguire. L'analisi può concludersi senza rendere il software modificabile.

«La dipendenza dal vecchio fornitore diventerà una dipendenza da voi.» Il rischio esiste se il sapere resta soltanto nostro. Preparare una consegna utilizzabile richiede tempo a noi e a chi dovrà riceverla: è un costo da includere nell'incarico. Concordiamo per iscritto gli accessi e i materiali che resteranno sotto il tuo controllo, nel rispetto dei diritti sul codice esistente. Ti consegniamo la documentazione insieme ai test e alle procedure disponibili, indicando ciò che resta irrisolto. Verifichiamo con chi subentra che le istruzioni permettano di svolgere le attività concordate. Devi poter affidare la manutenzione ad altri senza ricominciare l'indagine.

Come lo affrontiamo oggi

Prendiamo in carico software scritto da altri partendo dalle informazioni disponibili e dal lavoro che deve continuare a svolgere. Il primo confronto serve a capire che cosa hai già e a definire un inventario con un perimetro chiaro. La decisione sulle modifiche viene dopo.

• Software su misura, presa in carico e manutenzione
• Il nostro percorso Odoo Partner, quando conviene passare a uno strumento standard
• Gestione documentale in un gestionale integrato

Hai un software che nessuno sa più toccare? Parliamone — 30 minuti, senza impegno.