Il collaudo è andato bene, il programma è in produzione, le persone hanno imparato a usarlo. L’ultima fattura è pagata e il progetto si chiude con una stretta di mano. È il momento in cui nessuno ha voglia di parlare di contratti, ed è esattamente il momento in cui conviene averlo già fatto.
Il software non si consegna una volta sola. Cambiano le regole della fatturazione, il browser si aggiorna e rompe una schermata, il fornitore della posta cambia un protocollo con un avviso che nessuno ha letto, un utente trova il modo di inserire una data che non esiste. Niente di tutto questo è un difetto del programma, e tutto richiede che qualcuno ci metta le mani.
Le tre domande qui sotto vanno fatte prima della firma, quando avete ancora qualcosa da scambiare. Dopo la consegna si chiamano richieste, e costano di più.
1. Chi risponde, e su quale canale
La risposta che non basta è «ci scrivete e ci pensiamo noi». Quello che serve sapere è dove finisce la segnalazione e chi la legge: un indirizzo che riceve più di una persona, un sistema di ticket, un numero per le urgenze. Un cellulare privato non è un canale: funziona benissimo finché quella persona è in azienda, e smette quando è in ferie o al telefono con un altro cliente.
Chiedete anche chi c’è di riserva. Se chi vi segue di solito non è disponibile, chi lo sostituisce, e quella persona conosce il vostro sistema o lo apre per la prima volta il giorno del problema? Una società di due persone e un professionista da solo possono essere ottimi entrambi, ma la continuità va scritta invece che sperata.
Terza cosa, gli orari. «Rispondiamo subito» detto a voce è diverso da «lunedì-venerdì, nove-diciotto» scritto nel contratto. Se lavorate il sabato, o se la campagna del vostro settore è a Ferragosto, quello è il momento in cui l’assistenza serve davvero, ed è il momento in cui gli orari standard non ci sono.
2. Entro quanto, e per che cosa
Qui nasce quasi tutto il malinteso. Per voi «urgente» vuol dire che il magazzino è fermo; per il fornitore vuol dire che è arrivata una mail con scritto urgente. La differenza si chiude in tre righe, scrivendo le classi di problema e il tempo di risposta di ciascuna.
Una scala che funziona nelle aziende piccole è questa: il programma non si apre e nessuno lavora; il programma funziona ma una parte importante no, e c’è un modo scomodo per andare avanti; una cosa è sbagliata o fastidiosa e può aspettare. Tre righe, tre tempi. Non servono sigle né tabelle a colori.
Attenzione alla differenza fra tempo di risposta e tempo di soluzione. La prima è quando qualcuno vi dice «lo stiamo guardando» ed è facile da promettere; la seconda è quando il problema non c’è più, e onestamente nessuno può garantirla per ogni caso. Un fornitore serio promette la prima, dà una stima sulla seconda e vi tiene aggiornati mentre lavora. Chi promette la soluzione in due ore per qualunque guasto, o non ha letto il contratto o non pensa di doverlo rispettare.
Fatevi dire, per finire, che cosa non è compreso. Di solito non lo sono il recupero dei dati dopo un errore dell’utente e la formazione delle persone nuove. Sapere che sono fuori va benissimo; scoprirlo il giorno in cui servono, molto meno.
3. Di chi è il codice, e di chi sono le chiavi
È la domanda che decide se fra tre anni siete liberi.
Il codice sorgente: il contratto dice che è vostro, che è in licenza d’uso, o non lo dice affatto? Sono tre situazioni molto diverse e nessuna delle tre è sbagliata in sé — quello che è sbagliato è non saperlo. Se il codice resta del fornitore, chiedete a quali condizioni potreste averlo, e mettetelo per iscritto ora.
Il posto dove il codice vive: un archivio su un servizio come GitHub o GitLab, di cui qualcuno in azienda deve avere accesso da amministratore. Non per leggerlo — per esserci, il giorno in cui serve darlo a qualcun altro.
Le chiavi: il dominio, il servizio dove gira il programma, la casella di posta di sistema, il certificato, il database, il servizio che manda le fatture elettroniche. Quegli account devono essere intestati alla vostra azienda, con la vostra carta e la vostra mail di recupero, e il fornitore deve essere un utente invitato. Non è un segno di sfiducia: è la differenza fra cambiare fornitore e rifare tutto da capo.
Un’impresa immaginaria del Brindisino — mettiamo un’azienda di infissi con un gestionale su misura — si accorge di questa differenza il giorno in cui il fornitore chiude l’attività. Se il dominio e il server sono intestati a lei, cambia manutentore e va avanti. Se sono intestati a chi ha chiuso, il programma continua a funzionare finché qualcuno paga un rinnovo che nessuno sa più dove si paghi.
Manutenzione non è sviluppo: la riga che evita le liti
Un contratto di manutenzione copre quello che c’è: correzioni, aggiornamenti di sicurezza, adeguamenti a norme che cambiano, piccole cose. Non copre una funzione nuova, perché una funzione nuova è un progetto, con un’analisi e un preventivo.
Il confine va scritto con un esempio per parte, non con una definizione: «il calcolo dell’IVA che cambia è manutenzione, il nuovo modulo per la vendita online è sviluppo». Due esempi in fondo al contratto risparmiano due anni di discussioni su cosa fosse compreso.
Cosa succede se vi lasciate
Chiedete che cosa consegna il fornitore quando il rapporto finisce: il codice aggiornato, un’esportazione completa dei dati in un formato che si riapre altrove, la documentazione di come si installa, la lista degli account. E chiedete quanto dura il preavviso, da una parte e dall’altra.
È una conversazione che sembra ostile da fare al primo incontro. Non lo è: un fornitore che risponde volentieri sta dicendo che non ha bisogno di trattenervi per contratto. Gli altri si riconoscono proprio dalla faccia che fanno a questa domanda.
Da dove cominciare
Dal contratto che avete già. Prendete quello del programma che usate tutti i giorni e cercate tre cose: un tempo di risposta scritto in ore o in giorni, l’intestatario del dominio, e chi ha l’accesso da amministratore all’archivio del codice. Se le trovate tutte e tre in dieci minuti, siete a posto. Se non trovate il contratto, quella è già la risposta.
Come mettiamo in sicurezza noi quello che è in produzione — il solo programma, oppure programma più macchina, con backup provati e monitoraggio — è nella parte Sicurezza e infrastruttura della scheda Consulenza Imprese, con quello che comprende. Se invece il programma ve lo state facendo fare adesso, Digitalizzazione Imprese dice che quello che segue il rilascio — le correzioni, le modifiche, la documentazione e il manuale d’uso tenuti aggiornati — si scrive nel preventivo, prima di cominciare.
Il servizio collegato a questo articolo: Consulenza Imprese