Checklist RFP per fornitori software: come valutare

Un RFP per un progetto software dovrebbe enunciare il problema, i requisiti funzionali e non funzionali, i bisogni di sicurezza e dati, le condizioni commerciali e il metodo di punteggio prima che qualcuno dei fornitori risponda. Punteggiate i criteri pesati anziché discuterne dopo, verificate i riferimenti anziché credere alle storie di caso e fate un breve pilota a pagamento prima di firmare qualsiasi cosa impegni un budget.

Cosa deve contenere una checklist RFP?

Il documento serve a rendere confrontabili le risposte. Un fornitore può rispondere solo a ciò che è scritto; un RFP che descrive una visione e chiede un prezzo produce proposte che suonano tutte eccellenti e nessuna delle quali è valutabile rispetto alle altre. Il contenuto funzionale, i vincoli e la regola di punteggio vanno fissati prima che arrivi la prima risposta, altrimenti la valutazione diventa una negoziazione sui criteri.

C'è anche un punto di sequenza che fa risparmiare mesi: l'RFP non è il posto dove scoprite di cosa avete bisogno. I requisiti nascono dal lavoro interno — i responsabili dei processi che descrivono come gira davvero l'attività, la finanza che enuncia cosa deve riconciliarsi, le persone che useranno il sistema ogni giorno che dicono dove il lavoro fatica oggi. Quel lavoro è lento e politico, e avviene prima che qualcuno dei fornitori sia coinvolto. I team che lo delegano al primo fornitore che arriva finiscono con requisiti scritti nel linguaggio del prodotto di quel fornitore, il che fa apparire ogni altra proposta come un cattivo adattamento — non perché lo sia, ma perché il metro è stato scritto attorno a uno dei concorrenti.

Un'altra distinzione da mantenere, tra tre documenti spesso confusi. Un RFI chiede al mercato cosa esiste; è breve, precede i requisiti e non impegna nessuno. Un RFP chiede una proposta contro requisiti definiti e un metodo di valutazione dichiarato. Un RFQ chiede un prezzo contro un ambito definito. Fare un RFQ prima che l'ambito esista è il modo più comune per confrontare tre numeri che significano tre cose diverse.

Cinco cose che un RFP completo fa e quello incompleto non fa:

• Definisce il problema, non la soluzione. «Ridurre il tempo di compilazione del report consolidato mensile da giorni a un numero definito di ore» è un'affermazione di problema; «costruitemi un archivio dati» è un'ipotesi di soluzione che potrebbe non risolverlo.


• Separa i requisiti dalle preferenze. Quelli indispensabili che decidono il superamento, quelli importanti che decidono la classifica e quelli gradibili che non decidono nulla. I fornitori rispondono seriamente solo quando quella distinzione è visibile.


• Nomina i vincoli. Sistemi esistenti da integrare, dati da migrare, obblighi di audit e conservazione, finestra di avvio, chi dà l'approvazione.


• Dichiara in anticipo il metodo di valutazione. Criteri pesati, chi valuta, quali evidenze servono e quando i fornitori non selezionati ricevono il riepilogo dei loro punteggi.


• Fissa le date del processo. Scadenza domande, finestra di chiarimento, scadenza d'invio, periodo di valutazione, data della decisione. Un processo senza date attira fornitori che sono già impegnati.

Struttura della checklist RFP

Requisiti funzionali e non funzionali

I requisiti funzionali descrivono cosa fa il sistema: quali processi, per quali ruoli, con quali output. I requisiti non funzionali descrivono quanto bene li fa, e sono proprio quelli che mancano più spesso — poi vengono fatti rispettare dopo, a caro prezzo, o non vengono affatto.

Da dichiarare esplicitamente nella maggior parte dei progetti B2B:

• Prestazioni. Tempi di risposta sotto un carico dichiarato, per le operazioni che contano — inserimento ordini, generazione di report, chiusura di mese.


• Disponibilità. Quale continuità serve all'attività, finestre di manutenzione e cosa succede quando il sistema è fuori servizio — un obiettivo senza una descrizione dell'interruzione accettabile non è un requisito.


• Ripristino. RTO e RPO in parole piane: quanto rapidamente riprendono le operazioni dopo un incidente e quanto lavoro si può perdere. Entrambe le cifre appartengono alla valutazione, non solo al contratto.


• Traccia di audit. Chi ha modificato cosa e quando, conservato per quanto tempo, recuperabile da chi — soprattutto dove si muovono denaro, scorte o dati personali.


• Accessibilità e usabilità. Chi usa il sistema, su quali dispositivi, in quali lingue; un sistema che il magazzino non sa usare non è implementato, per quanto bene prenda punti.


• Integrazione e dati. Quali sistemi si collegano, in che direzione scorrono i dati e chi possiede il record anagrafico di ogni entità.

Domande di sicurezza e conformità

La sicurezza è meglio posta come domande con evidenze obbligatorie anziché come una riga di sì/no. Quelle da includere:

• ISO/IEC 27001 — il fornitore lo possiede e cosa copre l'ambito certificato? Un certificato che copre l'organizzazione vendite ma non i team di consegna dice qualcosa di preciso.


• Sviluppo sicuro — dove sta la sicurezza nella progettazione, nella revisione del codice e nei test; se la gestione di dipendenze e vulnerabilità è di routine.


• OWASP Top 10 — se fa parte della revisione del fornitore per i componenti esposti in rete; una domanda concreta e rispondibile.


• Controllo degli accessi — chi può raggiungere i vostri ambienti e i dati, come l'accesso viene concesso e revocato, quali log esistono.


• Doveri di protezione dei dati — KVKK e GDPR dove si applicano; chi è titolare, chi responsabile, cosa dice l'accordo di trattamento dati su responsabili delegati e notifica delle violazioni.

Condizioni commerciali e SLA

Chiedete i prezzi in una struttura che si possa confrontare: cosa è incluso, cosa è fatturato a parte e come vengono prezzate le modifiche. Un singolo numero senza ambito dietro non si può confrontare con un altro singolo numero; la pagina di costi e modelli di prezzo spiega le strutture comuni e le domande che ciascuna solleva.

Gli SLA meritano la stessa precisione dei requisiti. Una percentuale di disponibilità ha senso solo con il suo metodo di misura, le esclusioni e il rimedio; un tempo di risposta ha senso solo con le definizioni di gravità e l'orario di servizio. Chiedete a ogni fornitore di definire i termini dentro lo SLA anziché accettare una pagina di percentuali senza definizioni.

Matrice di punteggio della valutazione

Un modello copiabile. I pesi sotto sono un esempio — impostate i vostri sulle vostre priorità e tenete il totale a 100. Definite cosa significano 1, 3 e 5 prima che qualcuno assegni punti, non dopo che iniziano le discussioni.

Due discipline rendono il tutto funzionante. Punteggiate indipendentemente prima di discutere, così la prima voce sicura di sé non detta il tono della sala. E registrate una riga di motivazione per ogni punteggio — i fornitori che ricevono un riepilogo dei punteggi con le motivazioni accettano l'esito molto più volentieri, e il vostro stesso team può difenderlo sei mesi dopo.

Una terza disciplina riguarda chi assegna i punti. Il pannello dovrebbe includere le persone che vivranno con il risultato — il responsabile del processo, la persona responsabile dei dati, qualcuno della sicurezza o della finanza dove queste funzioni esistono — non solo l'ufficio acquisti. Le valutazioni falliscono in silenzio quando il pannello assegna punti a ciò che sa giudicare (la struttura della proposta, la preparazione del team commerciale) e rimanda ciò che non sa giudicare (se l'approccio di integrazione si adatta davvero ai sistemi attuali). Una persona tecnica con l'autorità di dire «questo non funziona con quello che noi gestiamo» previene più costi di qualsiasi sconto.

I pesi meritano anch'essi un avvertimento: sono una dichiarazione di priorità che diventa visibile ai fornitori. Se la sicurezza è pesata al 5% e il prezzo al 30%, i fornitori seri attenti alla sicurezza se ne accorgeranno, e anche il vostro team quando il contratto sarà firmato. Un'impostazione dei pesi fatta in fretta, per riempire la tabella, viene letta come la verità da tutti quelli fuori dalla sala; fissatela una volta, con i decisori presenti, e cambiatela solo con la stessa formalità con cui l'avete fissata.

Verifica dei riferimenti e pilota

Le storie di caso sono marketing; le verifiche dei riferimenti sono evidenze. La chiamata che funziona è breve e chiede cosa è successo, non cosa è stato consegnato: il progetto è finito, cosa è cambiato nell'ambito, chi c'era davvero nel team, cosa farebbero diversamente e se inizierebbero di nuovo il progetto con questo fornitore. Risposte al passato e specifiche sono il segnale.

Chiedete un riferimento da un progetto che somiglia al vostro per dimensione e complessità, non l'opera più orgogliosa del fornitore — un'implementazione di bandiera due volte il vostro budget non vi insegna quasi nulla su come si comporta il team alla vostra scala. E verificate voi stessi il riferimento: un contatto che il fornitore prepara in anticipo è una testimonianza, non un riferimento; la chiamata utile è quella in cui il cliente impara in diretta cosa state chiedendo.

Un breve pilota a pagamento testa poi la parte che nessun riferimento può testare: come questo team lavora con le vostre persone quando i requisiti sono incompleti. Le regole di progetto sono le stesse che vale la pena fissare per qualsiasi pilota — lavoro reale, criteri di accettazione scritti, una modifica a metà strada e una regola decisionale concordata in anticipo. La pagina sull'outsourcing IT tratta la progettazione del pilota nel dettaglio.

Clausole contrattuali da controllare

• Assegnazione della proprietà intellettuale — diritti su codice, documentazione e derivati che vi passano, dalla creazione, non solo al pagamento finale.
• Proprietà dei dati — i vostri dati restano vostri; i diritti del fornitore sono limitati a ciò che serve per consegnare.
• Accettazione — cosa significa accettazione, chi la dichiara e il processo quando qualcosa non la supera.
• Controllo delle modifiche — come si richiedono, si prezzano e si approvano le modifiche d'ambito; senza, ogni modifica diventa una disputa.
• Uscita e transizione — codice sorgente, accessi, documentazione e assistenza alla fine; come si trasferisce la conoscenza se il fornitore cambia.
• Deposito presso terzi (escrow) — dove la continuità aziendale dipende da componenti detenuti dal fornitore, cosa succede se il fornitore non può continuare.
• Responsabilità — tetti, esclusioni e ciò che è assicurato; leggetelo con la stessa attenzione del prezzo.
• Risoluzione — preavvisi, obblighi dopo la risoluzione e il processo di restituzione o eliminazione dei dati.

Domande frequenti

Dobbiamo inviare prima un RFI o un RFP?

Un RFI quando il mercato o il problema non sono chiari — chiedete cosa esiste e quanto costa. Un RFP quando i requisiti e il metodo di valutazione sono definiti; inviarlo prima sposta semplicemente il lavoro sui requisiti dentro la proposta di ogni fornitore, con le loro parole e le loro priorità.

Quanti fornitori invitare?

Pochi abbastanza da poter leggere ogni proposta per bene e chiamare ogni riferimento. Le valutazioni perdono qualità oltre una manciata; una selezione ristretta costruita da un RFI, una chiamata di preselezione e un progetto di riferimento simile è di solito più utile di una lunga lista di nomi famosi.

Come si impostano i pesi?

Dalle vostre priorità, prima di vedere qualsiasi proposta, e concordati tra le persone che vivranno con il risultato. Un errore comune è pesi uguali su tutto, che è un modo di dire che nulla conta più di nulla; se per voi il prezzo o il rischio dominano, i pesi dovrebbero dirlo.

Il prezzo va punteggiato?

Sì, ma come un criterio pesato con l'ambito fissato, non come l'intera valutazione. Un prezzo punteggiato senza ambito dietro premia il fornitore che ha supposto meno lavoro; prezzate prima i vostri requisiti, poi confrontate i totali per la stessa cosa.

Come punteggio le risposte sulla sicurezza?

Sulle evidenze, non sul tono. Tre livelli funzionano: nessuna posizione (1), politiche descritte (3), ambito del certificato verificato più sviluppo sicuro descritto ed evidenze fornite (5). Dove il fornitore non possiede alcun certificato, chiedete quali controlli equivalenti esistono per iscritto — un «no» onesto con controlli documentati prende più punti di un «sì» non verificabile.

Possiamo cambiare i requisiti dopo l'RFP?

Prima degli invii, sì — con la modifica annunciata a tutti. Dopo gli invii, solo attraverso un chiarimento formale che tutti i concorrenti ricevono; cambiare in silenzio i requisiti per un solo fornitore uccide la confrontabilità su cui tutto il processo era costruito. Dopo il contratto, è a quello che serve il controllo delle modifiche.

Fonti e norme

• ISO — editore di ISO/IEC 27001 (gestione della sicurezza delle informazioni); confermate l'edizione corrente e l'ambito di un certificato prima di fidarvi.
• OWASP — editore dell'elenco dei Top 10 rischi di sicurezza delle applicazioni web citato in questa pagina.
• I principi della matrice di punteggio seguono la pratica pubblicata dei modelli di RFP; i pesi mostrati sono un esempio da modificare, non una raccomandazione. Questa pagina è orientamento all'acquisto, non consulenza legale, e per WorldwideTradeX non vengono rivendicate certificazioni o audit.

Pagine correlate

Sviluppo software · Outsourcing IT dalla Turchia · Costi e modelli di prezzo · Audit e consulenza IT · Richiedi un preventivo