Audit software aziendale: cosa controllare

Un audit del software aziendale è un’analisi che fotografa lo stato di un programma: cosa fa, come è costruito, quali rischi comporta e quali interventi hanno più senso. Non serve a giudicare chi l’ha scritto. Serve a darti le informazioni per decidere se tenerlo, collegarlo, sostituirlo in parte o cambiarlo del tutto.

Attenzione a non confonderlo con altri due significati della stessa parola: l’audit delle licenze, che verifica se hai pagato i software che usi, e gli audit di certificazione. Qui parliamo di come capire se il tuo sistema è un rischio e cosa farne.

Perché farlo prima di chiedere un preventivo

Senza un’analisi, un fornitore può solo stimare al buio su una descrizione che, per forza di cose, è incompleta. Il risultato è uno di questi: un prezzo gonfiato per coprire gli imprevisti, oppure un prezzo basso che cresce strada facendo.

L’audit sposta le sorprese prima della firma, quando costano poco. Ed è anche il momento in cui può emergere che non serve rifare tutto.

Le 6 aree da controllare

1. Funzioni e uso reale

Il punto di partenza non è il codice, ma il lavoro delle persone.

Quali funzioni si usano ogni giorno, e quali non si aprono da anni?
Quali lavori si fanno fuori dal programma, su Excel o su carta?
Cosa rallenta di più chi lo usa?

Parlare con chi usa il programma è spesso la parte più istruttiva. È lì che emergono le regole mai scritte.

2. Codice e tecnologia

Il codice sorgente esiste, è completo e corrisponde a ciò che è installato?
Il linguaggio e i componenti sono ancora supportati?
Si riesce ancora a compilarlo, cioè a produrre una nuova versione? Sembra scontato, ma con vecchi strumenti non sempre lo è.
Dipende da componenti di terzi che non si trovano più?

3. Dati

Dove sono i dati: un database, file condivisi, più posti insieme?
Quanti duplicati ci sono, e quanti campi usati per scopi diversi da quelli previsti?
Esistono copie parallele su Excel? Quale versione è quella vera?
I dati sono accessibili e di tua proprietà, o il fornitore li controlla?

4. Sicurezza e backup

Sistema operativo e database ricevono ancora aggiornamenti?
Chi può accedere a cosa? Esistono utenze condivise?
Il backup viene fatto, è conservato altrove ed è stato provato davvero?
Quali dati personali vengono trattati? La valutazione va fatta anche rispetto all’articolo 32 del GDPR, che chiede misure adeguate al rischio.

Questa non è una prova di attacco informatico, che è un servizio diverso. Se tratti dati sensibili, può avere senso farla a parte.

5. Collegamenti

Con quali altri programmi scambia dati, e in che modo?
Quali passaggi avvengono a mano?
Si può leggere e scrivere nel sistema senza modificarlo? Da qui dipende se è possibile far crescere il nuovo accanto al vecchio.

6. Persone e fornitori

Chi conosce davvero il sistema? Se è una sola persona, quanto è disponibile?
Che contratti sono in corso con il fornitore, e cosa prevedono?
Chi, in azienda, potrà seguire il progetto e collaudare?

Una checklist da fare subito

Prima di coinvolgere chiunque, puoi rispondere a queste domande in un paio d’ore. Ti serviranno comunque.

Elenca i programmi usati in azienda, chi li usa e per cosa.
Segna quale, se si fermasse domani, bloccherebbe il lavoro.
Per ciascuno, scrivi chi interviene se c’è un problema.
Verifica se possiedi il codice sorgente e dove si trova.
Annota versione del sistema operativo e del database, poi controlla la data di fine supporto.
Chiedi quando è stato provato l’ultimo ripristino da backup.
Fai elencare a chi lavora i tre problemi che fanno perdere più tempo.

Se su qualche punto la risposta è “non lo so”, hai già scoperto qualcosa di utile. In cos’è il software legacy trovi anche i segnali per interpretare ciò che emerge.

Cosa deve esserci nel report finale

Un buon report può essere letto da un titolare, non solo da un tecnico. Pretendi almeno:

Un riassunto chiaro dello stato del sistema, in poche pagine.
I rischi in ordine di gravità, ognuno con le sue conseguenze per l’azienda, non solo con una descrizione tecnica.
Un elenco di priorità, che dica cosa fare prima e perché.
Un piano con tempi e costi, diviso in interventi separati.
Cosa non conviene fare. Se un report consiglia di rifare tutto senza eccezioni, chiedi come ci è arrivato.

Noi chiudiamo l’audit con un report di questo tipo: stato del sistema, rischi principali e un piano di migrazione per interventi, con tempi e costi. Su quella base il prezzo è fisso e non cambia.

Di cosa ha bisogno chi fa l’audit

Per lavorare bene servono di solito un accesso in sola lettura al sistema o a una sua copia, il codice sorgente se esiste, un po' di tempo con chi usa il programma e con chi lo mantiene. Non serve fermare il lavoro.

Prima di concedere gli accessi, chiedi di firmare un accordo di riservatezza e di chiarire come verranno trattati i dati. È una richiesta normale, e un fornitore serio non avrà problemi ad accettarla.

Come riconoscere un audit fatto male

Alcuni segnali meritano attenzione:

La conclusione era già scritta. Se il report arriva a raccomandare esattamente il prodotto venduto dall’autore, chiedi quali alternative sono state valutate.
Nessuno ha parlato con gli utenti. Un audit basato solo sul codice non vede la metà del problema.
Non hai ricevuto un documento. Se resta solo una presentazione commerciale, non puoi usare il risultato con nessun altro.
Non puoi portarlo altrove. Il report dovrebbe servirti anche se decidi di lavorare con un altro fornitore: è una delle cose da verificare quando scegli una software house.

Audit del software aziendale: cosa controllare prima di decidere