La follia di RFI, RFP e RFQ nella supply chain

Joannes Vermorel

Negli anni, Lokad ha acquisito una certa notorietà e abbiamo guadagnato il privilegio di far parte di un numero sempre crescente di RFI (richiesta di informazioni), RFP (richiesta di proposta) e RFQ (richiesta di preventivo) legati all’ottimizzazione della supply chain. Sebbene sia grato che Lokad sia considerata abbastanza importante da essere selezionata in queste iniziative - e selezionata regolarmente anche - non posso fare a meno di contemplare la follia pura che sottende a questi processi.

Sono da tempo perplesso per le pratiche bizzarre che sono diffuse nel campo del software aziendale ¹. Più recentemente, ho anche proposto un approccio che ritengo fortemente superiore in ogni dimensione rispetto a quelli tradizionali ². Tuttavia, oggi vorrei analizzare alcuni degli elementi francamente bizzarri (se non addirittura folli) delle RFP che ho osservato. In poche parole, le RFP ³ sono scientismo in azione. Una prospettiva, un atteggiamento e un processo che imitano, agli occhi di un pubblico generale, ciò che ci si aspetta da un’impresa “scientifica”. Tuttavia, nella pratica, le RFP sono tanto scientifiche o razionali quanto una seduta spiritica.

Per cominciare, le liste di domande raccolte all’interno delle RFP sono, senza eccezione, lunghe e prive di senso. Questi documenti sono invariabilmente il prodotto di un comitato che cerca di accontentare tutti elencando tutte le domande a cui tutti potrebbero pensare. Peggio ancora, ogni volta che vengono chiamati esperti - tipicamente consulenti - per rivedere o migliorare l’elenco, il catalogo delle domande viene gonfiato di un ordine di grandezza.

Mentre il detto non esistono domande stupide potrebbe essere un valido principio guida per una scuola primaria, è dannoso quando si tratta di una grande azienda e della sua supply chain. Francamente, nel mondo reale, le domande stupide possono comportare costi in termini di tempo sprecato, attenzione mal riposta e compromessi costosi fatti per risparmiare sentimenti. Ci sono diverse classi di tali domande ⁴, e di seguito identificherò sette delle più comuni e ne illustrerò i difetti.

• Domande pigre. Esempio: La soluzione segue le migliori pratiche di sicurezza? Queste domande semplicemente sprechiano il tempo di tutti. Nessun fornitore di software aziendale, in piena facoltà mentale, risponderà negativamente a una domanda del genere.
• Domande stupide. Esempio: La soluzione gestisce le MOQ (quantità minime d’ordine)? Queste domande creano confusione. Gestire le MOQ è banale; è fare qualsiasi tipo di ottimizzazione in presenza di MOQ che è difficile.
• Domande “intelligenti”. Esempio: Come la soluzione razionalizza le divergenze di previsione rispetto al piano originale in presenza di stockout? Presumo che queste domande (apparentemente precise, ma in realtà vaghe) siano intese a impressionare i colleghi, ma aggiungono solo un ulteriore livello di confusione, presto aggravato dalla risposta altrettanto fiorita del fornitore di software.
• Domande tendenziose. Esempio: La soluzione offre la possibilità di gestire e adattare i profili di stagionalità? Queste domande interferiscono con la neutralità del processo e sollevano ulteriori domande implicite. La domanda di esempio implica che la stagionalità dovrebbe essere affrontata attraverso “profilati” (perché?) e che gli utenti finali dovrebbero essere coinvolti (perché?).
• Domande ambigue. Esempio: La soluzione consente l’introduzione di KPI (indicatori chiave di prestazione)? Questa classe di domande accentua i malintesi. Ciò che costituisce un KPI (indicatore chiave di prestazione) è soggettivo; il fornitore e il cliente difficilmente condivideranno gli stessi sentimenti al riguardo.
• Domande tangenziali. Esempio: La soluzione può ricalcolare in tempo reale le sue suggerimenti di riapprovvigionamento? Queste domande servono a distogliere l’attenzione dai problemi principali. L’idea di “tempo reale”, nel contesto del software aziendale distribuito, comporta discussioni lunghe e troppo tecniche che sono in ultima analisi irrilevanti se i dati di riapprovvigionamento sono errati fin dall’inizio.
• Domande spaventose. Esempio: La soluzione è certificata ISO/IEC 27001? Queste domande danno potere alle parti sbagliate. Le certificazioni, nel software aziendale, danno potere agli enti certificatori e al loro ecosistema, senza apportare alcun valore effettivo per l’azienda cliente.

Aspettarsi che il fornitore giusto possa essere scelto facendo domande sbagliate ha tanto senso quanto aspettarsi che un calcolo sia corretto utilizzando cifre iniziali errate. Eppure, sembra essere l’approccio preferito dalla maggior parte delle grandi aziende quando si tratta di software aziendale.

Per rendere le cose ancora peggiori, molti RFP (Richiesta di Proposta) includono una colonna “Conformità” - o qualcosa del genere - accanto alla colonna “Risposta”, chiedendo al fornitore di autodiagnosticare il proprio grado di conformità 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 “conformità” ha un certo senso, sebbene in modo bizzarro e distorto.

Vorrei anche sottolineare che (quasi?) tutti i documenti RFP riflettono, nella loro presentazione, una mancanza di cura piuttosto brutale. Ogni paragrafo è pieno di errori di ortografia orribili. Ci sono domande duplicate e numeri di domande duplicati. La dimensione del carattere cambia in modo inelegante da 6 a 20 e ritorni di linea disordinati sporcano il documento. Per quanto riguarda le domande, è ancora peggio poiché gli RFP sono tipicamente formattati come fogli di calcolo di Microsoft Excel - distribuiti su più schede, per inciso, ognuna delle quali ha le proprie colonne “Domanda” e “Risposta”, più un paio di altre per buona misura (come l’esempio di “Conformità” elencato sopra). Il formato del 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 di più paragrafi 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, considera che gli strumenti di e-procurement, spesso utilizzati per condurre queste farse, sono stati forgiati nel nono cerchio dell’inferno. Questi strumenti rappresentano le peggiori incarnazioni del software aziendale, ognuno dei quali apre nuove strade per abbassare le aspettative: design poco reattivo, esperienza utente scadente e afflitto da backlog di bug non risolti lunghi come i libri di Tolkien. Attraverso l’uso di tali strumenti di e-procurement, la follia burocratica viene portata all’ennesima potenza.

È ingenuo pensare che la forma sia irrilevante finché c’è sostanza. La forma di un RFP, per quanto atroce, assicura che approfondire le domande, figuriamoci le risposte, richieda un enorme dispendio di tempo. Di conseguenza, le persone che dovrebbero guidare il processo di selezione - dirigenti come il direttore della supply chain - si tirano indietro e delegano a “esperti”, come i responsabili degli acquisti o terze parti. I responsabili degli acquisti di solito hanno poca conoscenza di ciò che costituisce una soluzione ragionevole per la propria azienda. Nel frattempo, le terze parti, introdotte come facilitatori dell’RFP, sono incentivati a rendere l’operazione il più labirintica possibile.

Alcuni potrebbero sostenere che un RFP è un male minore rispetto alla corruzione aperta che si verificherebbe in sua assenza. In altre parole, gli 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 è una dichiarazione piuttosto straordinaria e, quindi, richiede prove straordinarie. Infatti, solleva interrogativi riguardo al tipo di frode che gli RFP dovrebbero prevenire e, di conseguenza, quanto siano efficaci in questa missione. Onestamente, l’idea che canalizzare un grande processo di selezione attraverso un foglio di calcolo altrettanto grande e disordinato renda il processo “più onesto” sembra, a prima vista, un’idea molto discutibile. (Chiedo scusa per il mio scetticismo.)

Le mie osservazioni personali nel mondo del software aziendale indicano che molti grandi fornitori di software ricompensano generosamente le persone che in passato hanno avuto posizioni di influenza, in relazione agli RFP, assumendole un decennio dopo. L’antidoto a questa (mal)pratica è semplice: identificare i fornitori che giocano a questo gioco e vietarli completamente ⁵. Realisticamente, gli 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 di quanto sia strettamente necessario, rende a sua volta il processo più vulnerabile agli attori malevoli. Questa proposizione può essere riformulata da una prospettiva di sicurezza informatica: la burocrazia aumenta la superficie di attacco del processo di selezione del fornitore, poiché diffonde la fiducia (e quindi la vulnerabilità) su strati di persone che non hanno motivo di essere fidate per quanto riguarda questo processo.

Nonostante tutti questi problemi, gli RFP sono diffusi nel software aziendale. Eppure, privatamente, la maggior parte delle persone - almeno quelle che non vivono di RFP - ammette che il processo ha poco senso, il che rende ancora più sorprendente la diffusione degli RFP. La spiegazione più semplice che posso avanzare è che gli RFP sono una forma elaborata di segnalazione di virtù aziendale ⁶. Nell’era delle tecnologie dell’informazione, ammettere che una decisione importante possa essere presa basandosi su nient’altro che una supposizione educata non è accettabile ed è percepito come semplicistico, poco sofisticato e totalmente non scientifico. Il processo RFP potrebbe non portare nulla di valore per l’azienda, ma affronta completamente l’aspetto della segnalazione di virtù.