La qualità di un fornitore si riconosce dalle domande che pone sul vostro processo, non dalle tecnologie che elenca.
È un criterio semplice e discrimina più di quanto sembri. Un interlocutore che dopo un’ora di incontro conosce l’architettura che propone ma non sa quante pratiche lavorate al mese, chi risponde di quel processo e in che stato sono i vostri documenti, non ha ancora capito che cosa vi serve.
Le quattro aree che seguono sono quelle su cui, nella nostra esperienza, si decide l’esito di un progetto.
1. Chiedere il metodo, non gli strumenti
Gli strumenti cambiano. Nel giro di diciotto mesi la scelta tecnologica corretta oggi può essere superata, e un fornitore vincolato a una piattaforma tenderà a proporre quella indipendentemente dal problema.
Il metodo è più stabile e più informativo.
Come si arriva alla definizione del perimetro. Un fornitore che accetta il perimetro proposto dal cliente senza discuterlo non sta aggiungendo competenza.
Che cosa viene verificato prima di progettare: qualità dei dati, accessibilità dei sistemi, chiarezza delle regole, esistenza di un titolare interno.
Come vengono affrontati i casi non previsti, dove il sistema si ferma, chi decide le soglie.
Come è organizzato il rilascio: in un’unica consegna o per fasi verificabili.
Una domanda che produce risposte rivelatrici: quali progetti avete sconsigliato, e perché. Un fornitore che non ha mai sconsigliato nulla ha una selezione dei casi diversa da quella che dichiara.
Vale anche la domanda inversa: che cosa del nostro processo vi convince meno. Se la risposta è che va tutto bene, l’analisi non è stata fatta.
2. Chiedere quali indicatori propone e come li misura
Un fornitore competente arriva con una proposta di indicatori, non aspetta che il cliente li chieda.
Le verifiche sono quattro.
Quali indicatori propone, e se riguardano il processo o l’uso dello strumento. Utenti attivi e numero di interrogazioni non misurano un ritorno.
Come intende rilevare lo stato di partenza, e quando. Deve essere prima dell’avvio dello sviluppo: dopo non è più possibile.
Come misura l’accuratezza del sistema: con quale insieme di casi, costruito da chi, includendo quali categorie. La risposta corretta include i casi difficili e le domande senza risposta in archivio.
Quale soglia propone per autorizzare la messa in esercizio, e come si comporta se non viene raggiunta.
Una richiesta concreta: chiedere di vedere il formato del rapporto di valutazione che verrà consegnato. Un fornitore che ne ha uno lo mostra in pochi minuti.
3. Chiedere che cosa succede al termine del contratto
È la parte meno discussa in fase di trattativa e la più costosa se trascurata.
Sei punti da definire per iscritto.
La titolarità del codice sviluppato su misura e il diritto d’uso in caso di cessazione del rapporto.
La titolarità e la restituzione dei dati, degli indici e delle configurazioni, con l’indicazione del formato. “Restituzione dei dati” senza specificare il formato può tradursi in un archivio non riutilizzabile.
La titolarità delle istruzioni e delle librerie sviluppate, che in questi sistemi rappresentano una parte rilevante del lavoro fatto.
La titolarità di eventuali modelli specializzati e dei set di esempi costruiti per l’addestramento.
La documentazione tecnica: che cosa viene consegnata, con quale livello di dettaglio, aggiornata a quale data.
Il supporto alla migrazione: durata, contenuto, condizioni economiche.
Va aggiunto il tema dei dati generati durante l’esercizio: registrazioni di scarto, correzioni degli operatori, insieme di prova arricchito. È materiale prodotto dalla vostra organizzazione e ha valore per un eventuale subentro.
4. Chiedere un riferimento verificabile
Non un elenco di loghi. Un progetto in esercizio, con la possibilità di parlare con chi lo utilizza.
Le domande da porre al referente sono cinque, e nessuna riguarda la tecnologia.
Il progetto è ancora in uso quotidiano, e da quanto tempo.
Quali indicatori sono stati misurati, e che cosa è cambiato rispetto alla situazione iniziale.
Che cosa non ha funzionato come previsto, e come è stato gestito. È la domanda più informativa: ogni progetto ha avuto difficoltà, e la risposta rivela il comportamento del fornitore quando le cose si complicano.
Quanto tempo interno ha richiesto il progetto, oltre al corrispettivo. È il costo che nelle valutazioni preliminari non compare quasi mai.
Rifareste la stessa scelta.
Se il fornitore non può fornire riferimenti per ragioni di riservatezza, è una circostanza legittima, frequente in ambito pubblico e finanziario. In tal caso è ragionevole chiedere una descrizione anonimizzata dettagliata, con numeri e difficoltà incontrate, e valutare la profondità della risposta.
Che cosa queste domande non garantiscono
Non garantiscono la riuscita del progetto. Una parte rilevante dell’esito dipende dall’organizzazione committente: disponibilità dei dati, presenza di un titolare interno, tempo delle persone operative.
Non sostituiscono la verifica sulla sicurezza, che richiede un insieme di domande proprio su localizzazione dei dati, permessi, log, cancellazione e responsabilità in caso di incidente.
Non compensano un perimetro definito male. Se il problema da risolvere non è chiaro, nessun fornitore lo chiarirà al posto vostro, anche se il buon fornitore lo segnalerà.
In chiusura
La selezione di un fornitore in questo ambito somiglia più alla scelta di un progettista che all’acquisto di una licenza. Ciò che si acquista è un metodo applicato al vostro processo, e la verifica va fatta sul metodo.
Il segnale più affidabile resta il primo: la qualità e la specificità delle domande che vi vengono poste sul vostro lavoro.
Se state valutando un progetto e volete un confronto tecnico preliminare sul vostro processo, senza impegno, siamo disponibili. Le prime domande le porremo noi.
