RFI, RFP e RFQ: la follia nella supply chain

Joannes Vermorel

Nel corso degli anni, Lokad ha guadagnato una certa notorietà, e abbiamo avuto il privilegio di far parte di un numero sempre crescente di RFI (richiesta di informazioni), RFP (richiesta di proposta) e RFQ (richiesta di quotazione) relative all’supply chain optimization. Pur essendo grato che Lokad sia considerata abbastanza notevole da essere inserita tra i candidati in tali iniziative - e regolarmente selezionata anche - non posso fare a meno di riflettere sulla pura follia che sta alla base di tali processi.

Da tempo rimango perplesso di fronte alle pratiche bizzarre che prevalgono nel mondo del enterprise software ¹. Più recentemente, ho anche proposto un approccio che credo fermamente essere superiore in ogni dimensione a quelli mainstream ². Tuttavia, oggi, vorrei analizzare alcuni degli elementi francamente bizzarri (se non addirittura insensati) degli RFP che ho osservato. In poche parole, gli RFP ³ sono scientismo in azione. Una prospettiva, un atteggiamento e un processo che imitano, agli occhi del grande pubblico, ciò che ci si aspetta da un’impresa “scientifica”. Tuttavia, nella pratica, gli RFP sono tanto scientifici o razionali quanto una seduta spiritica.

Per cominciare, le liste di domande raccolte all’interno degli RFP sono, senza eccezione, sia lunghe che insensate. Questi documenti sono invariabilmente il prodotto di un comitato che cerca di accontentare tutti elencando tutte le domande che a qualcuno possa venire in mente. Peggio ancora, ogni volta che vengono coinvolti esperti – tipicamente consulenti – per rivedere o migliorare l’elenco, il catalogo delle domande viene ingrandito di un ordine di grandezza.

Se da un lato il detto non esistono domande stupide potrebbe essere un valido principio guida per una scuola elementare, dall’altro risulta decisamente dannoso quando si tratta di una grande azienda e della sua supply chain. In sostanza, nel mondo reale, le cattive domande possono comportare costi in termini di tempo sprecato, attenzione mal impiegata e compromessi costosi fatti per salvaguardare i sentimenti. Esistono diverse categorie di tali domande ⁴, e in seguito identificherò sette delle più comuni evidenziandone le carenze.

• Domande pigre. Esempio: La soluzione segue le best practice di sicurezza? Queste domande fanno semplicemente perdere tempo a tutti. Nessun fornitore di enterprise software, nel giusto senno di causa, fornirà mai una risposta negativa a tale domanda.
• Domande stupide. Esempio: La soluzione gestisce MOQ (quantitativi minimi d’ordine)? Queste domande aggiungono confusione. Gestire gli MOQ è semplice; è compiere qualsiasi tipo di ottimizzazione in presenza di MOQ a risultare difficile.
• Domande “smart”. Esempio: Come fa la soluzione a razionalizzare le divergenze delle previsioni rispetto al piano originale in presenza di esaurimenti di stock? Presumo che queste domande (apparentemente precise, ma in realtà vaghe) siano intese a impressionare i colleghi, ma aggiungono semplicemente un ulteriore strato di confusione, che verrà presto aggravato dalla risposta altrettanto fiorita del fornitore del software.
• Domande insidiose. Esempio: La soluzione offre la possibilità di gestire e regolare i profili di stagionalità ? Queste domande interferiscono con la neutralità del processo e sollevano ulteriori interrogativi impliciti. L’esempio implica che la stagionalità debba essere affrontata tramite “profili” (perché?) e che gli utenti finali debbano essere coinvolti (perché?).
• Domande ambigue. Esempio: La soluzione consente l’introduzione di KPI? Questa tipologia di domande aggrava i malintesi. Ciò che costituisce un KPI (indicatore chiave di prestazione) è soggettivo; è improbabile che il fornitore e il cliente condividano le stesse opinioni a riguardo.
• Domande tangenziali. Esempio: La soluzione può ricalcolare in tempo reale le sue proposte di riapprovvigionamento ? Queste domande servono a distogliere l’attenzione dalle problematiche principali. Il concetto di “tempo reale”, nel contesto del software aziendale distribuito, comporta discussioni lunghe e eccessivamente tecniche che alla fine risultano irrilevanti se i dati di riapprovvigionamento sono, sin dall’inizio, scadenti.
• Domande spaventose. Esempio: La soluzione è certificata secondo ISO/IEC 27001? Tali domande danno potere alle parti sbagliate. Le certificazioni, nel software aziendale, attribuiscono potere agli organismi di certificazione e al loro ecosistema, mentre non apportano assolutamente nulla di valore per l’azienda cliente.

Pensare che si possa scegliere il fornitore giusto ponendo le domande sbagliate ha tanto senso quanto aspettarsi che un calcolo sia corretto utilizzando dati iniziali errati. Eppure, questo sembra essere l’approccio comune adottato dalla maggior parte delle grandi aziende quando si tratta di enterprise software.

Per peggiorare le cose, molti RFP includono una colonna “Compliance” - o qualcosa di simile - accanto alla colonna “Answer”, chiedendo al fornitore di auto-diagnosticare il proprio grado di conformità rispetto alla domanda. L’idea che un prodotto software possa essere conforme a una domanda è sconcertante. Tuttavia, nella pratica, le domande degli RFP sono così piene di pregiudizi che la colonna “Compliance” ha in effetti un certo senso, seppur in modo bizzarro e contorto.

Devo anche sottolineare che (quasi?) tutti i documenti RFP riflettono, nella loro presentazione, una mancanza di cura piuttosto brutale. Ogni paragrafo è costellato di orribili errori di ortografia. Ci sono domande duplicate e numeri di domanda ripetuti. La dimensione del font passa in maniera inelegante da 6 a 20 e ritorni a capo casuali inondano il documento. Per quanto riguarda le domande, la situazione è ancor peggiore, poiché gli RFP sono solitamente formattati come fogli di calcolo Microsoft Excel - distribuiti su diverse schede, ciascuna delle quali possiede le proprie colonne “Question” e “Answer”, più qualche altra per buon conto (come l’esempio della “Compliance” sopra menzionato). Il formato a foglio di calcolo non ha alcun senso nel contesto di un RFP. L’esperienza utente – sia che si tratti di scrivere o leggere un contenuto multi-paragrafo all’interno di una cella di un foglio di calcolo – è miserabile; ancor di più quando ci sono centinaia di domande, come di solito accade.

Come se non bastasse, consideri che gli strumenti di e-procurement, frequentemente utilizzati per condurre queste farsa, sono stati forgiati nel nono cerchio dell’inferno. Questi strumenti rappresentano le peggiori incarnazioni del software aziendale, ognuno dei quali introduce modi per abbassare le aspettative: design non responsivo, disordinato, un’esperienza utente insensata, e gravati da arretrati di bug non risolti lunghi come i racconti di Tolkien. Attraverso l’uso di tali strumenti di e-procurement, la follia burocratica viene innalzata all’undici ⁵.

È ingenuo pensare che la forma sia irrilevante fintanto che c’è sostanza. La forma di un RFP, per quanto atroce, garantisce che approfondire le domande, per non parlare delle risposte, rappresenti una perdita di tempo enorme. Di conseguenza, le persone che dovrebbero guidare il processo di selezione – dirigenti come il supply chain director – si ritirano e delegano agli “esperti”, come i responsabili degli acquisti o terze parti. I responsabili degli acquisti di solito hanno poca comprensione di ciò che costituisce una soluzione ragionevole per la loro azienda. Nel frattempo, le terze parti, coinvolte come facilitatori del RFP, sono incentivate a rendere l’impresa il più labirintica possibile.

Alcuni potrebbero sostenere che un RFP sia un male minore rispetto al corruttismo palese che si verificherebbe in sua assenza. In altre parole, i RFP, per quanto difettosi possano essere, rimangono l’opzione più sicura per preservare l’integrità dell’azienda e del suo processo di selezione. Tuttavia, questa è un’affermazione piuttosto straordinaria e, dunque, richiede prove altrettanto straordinarie. In effetti, solleva interrogativi sul tipo di frode che i RFP dovrebbero prevenire e, di conseguenza, su quanto siano efficaci in questa missione. Francamente, l’idea che indirizzare un ampio processo di selezione attraverso un foglio di calcolo altrettanto grande e casuale renda il processo “più onesto” sembra, a prima vista, un’esagerazione. (Scusate il mio scetticismo.)

Le mie osservazioni aneddotiche sul mondo del software aziendale indicano che molti grandi fornitori di software ricompensano generosamente le persone che un tempo occupavano posizioni di influenza in materia di RFP, assumendole un decennio dopo. L’antidoto a questa (mal)pratica è semplice: identificare i fornitori che giocano questo gioco e vietarli subito ⁶. Realisticamente, i RFP non fanno nulla contro il tipo di corruzione lungimirante che esiste nel mondo del software aziendale.

Pertanto, la mia analisi è la seguente: tutto ciò che rende il processo di selezione del fornitore più burocratico del necessario, allo stesso tempo lo rende più vulnerabile ad attori malintenzionati. Questa affermazione può essere riformulata da una prospettiva di sicurezza informatica: la burocrazia aumenta la superficie d’attacco del processo di selezione, poiché distribuisce la fiducia (e quindi la vulnerabilità) su strati di persone che non hanno motivo di essere ritenute affidabili in questo contesto.

Nonostante tutti questi problemi, i RFP sono diffusi nel mondo del software aziendale. Tuttavia, privatamente, la maggior parte delle persone - almeno quelle che non vivono degli RFP - ammette che il processo ha poco senso, il che rende ancor più sorprendente la diffusione degli RFP. La spiegazione più semplice che posso avanzare è che i RFP sono una forma elaborata di virtue signaling aziendale ⁷. Nell’era delle tecnologie dell’informazione, ammettere che una decisione importante possa essere presa sulla base di niente più che un’ipotesi informata non è accettabile, ed è percepito come semplicistico, poco sofisticato e decisamente poco scientifico. Il processo RFP potrebbe non portare nulla di valore per l’azienda ma affronta in modo approfondito l’angolo del virtue signaling.