Progettare un progetto pilota di una piattaforma di negoziazione che produca prove attendibili

Un progetto pilota di una piattaforma di negoziazione dovrebbe rispondere a una domanda decisionale, non mettere in scena una dimostrazione: la piattaforma migliora i risultati commerciali attribuibili e le prestazioni operative senza creare rischi inaccettabili per fornitori, sicurezza, conformità o continuità? Per produrre prove attendibili, i team devono selezionare categorie verificabili, fissare una baseline normalizzata, creare un gruppo di controllo e concordare i criteri di uscita prima di esaminare i risultati.

Questo standard è importante perché una dimostrazione riuscita del flusso di lavoro non prova il valore. Un progetto pilota di negoziazione con IA può completare le interazioni con i fornitori e lasciare comunque gli addetti agli acquisti aziendali nell’impossibilità di distinguere l’impatto della piattaforma dai movimenti di mercato, dalla selezione degli acquirenti, dai cambiamenti della domanda o da condizioni non economiche meno favorevoli.

Risposta in breve

Selezionate categorie ripetibili, misurabili e a rischio relativamente basso, invece di scegliere semplicemente quelle con la spesa maggiore. Fissate una baseline storica normalizzata, quindi confrontate gli eventi supportati dalla piattaforma con controlli contemporanei randomizzati, ove possibile. Registrate in anticipo metriche, esclusioni, punti di approvazione umana e regole di sospensione. Estendete l’uso solo se superate tutte le soglie relative alla qualità delle prove, al valore commerciale, alle prestazioni operative e al rischio; altrimenti riprogettate, sospendete o interrompete.

Come si presenta una prova attendibile

Un proof of concept di una piattaforma di negoziazione è attendibile quando un revisore indipendente può ricostruire:

1. Quali eventi erano idonei e per quale motivo.
2. Come gli eventi sono stati assegnati al gruppo di trattamento o a quello di controllo.
3. Che cosa sarebbe probabilmente accaduto senza la piattaforma di negoziazione.
4. Quali misure di risultato ed esclusioni erano state definite in anticipo.
5. Che cosa ha fatto la piattaforma, quali modifiche hanno apportato le persone e chi ha approvato ogni eccezione.
6. Se i miglioramenti di prezzo sono stati compensati da cambiamenti nei pagamenti, nei tempi di consegna, nelle garanzie, nei servizi, nella qualità o nella partecipazione dei fornitori.
7. Quale regola predefinita ha determinato l’estensione, la riprogettazione, la sospensione o l’interruzione.

Questo approccio riflette l’enfasi del Government Accountability Office degli Stati Uniti su obiettivi misurabili, metodologia di valutazione, piano di analisi dei dati, scalabilità e coinvolgimento delle parti interessate nella progettazione dei progetti pilota (GAO). È inoltre in linea con le considerazioni su test, supervisione, monitoraggio, possibilità di intervento, risposta agli incidenti e dismissione contenute nel NIST AI Risk Management Framework Core.

Si tratta di principi di progettazione, non di prove che una determinata piattaforma funzionerà in uno specifico contesto di approvvigionamento.

Tenere distinti fatti, ipotesi, stime e raccomandazioni

Il team del progetto pilota dovrebbe mantenere un registro delle evidenze con quattro etichette:

• Fatto verificato: supportato da una registrazione di sistema o da una fonte esterna autorevole. Esempio: valore di una fattura, data e ora di un evento o indice delle materie prime pubblicato.
• Ipotesi: necessaria ma non verificata. Esempio: gli eventi di controllo rappresentano un controfattuale ragionevole per gli eventi di trattamento.
• Stima locale: calcolata per l’organizzazione. Esempio: valore finanziario attribuito a una modifica delle condizioni di pagamento.
• Raccomandazione: scelta progettuale proposta. Esempio: randomizzare gli eventi idonei prima di contattare i fornitori.

Non trasformate le ipotesi in fatti solo perché compaiono in una dashboard. Allo stesso modo, non importate da casi di studio dei fornitori dimensioni campionarie, aspettative di risparmio o tassi di incidenti accettabili. Questi valori dipendono dalla frequenza locale degli eventi, dalla qualità dei dati, dagli aspetti economici e dalla propensione al rischio.

Passaggio 1: selezionare categorie che possano produrre prove in sicurezza

La categoria con la spesa maggiore è spesso una scelta iniziale inadeguata. Una negoziazione unica e critica per la continuità operativa può riguardare una spesa considerevole, ma non avere eventi comparabili, un gruppo di controllo sicuro o conseguenze reversibili.

Utilizzate invece un filtro di idoneità.

L’analisi strutturata della spesa e dei requisiti può aiutare i team a organizzare le attività di acquisto candidate; le linee guida federali sulla gestione delle categorie offrono un esempio pubblico di questo approccio (Acquisition.gov). Non definiscono regole universali per la selezione delle categorie nelle aziende private.

Raccomandazione: testate due o tre categorie con variazioni controllate, invece di affidarvi a una sola. L’obiettivo non è massimizzare i risparmi apparenti, ma capire se i risultati si mantengono al variare del numero di fornitori, delle dimensioni negoziali e degli acquirenti.

Approvazione umana obbligatoria: il responsabile della categoria, il responsabile degli acquisti, il responsabile aziendale e i referenti competenti per aspetti legali, privacy, sicurezza delle informazioni e rischio fornitori devono approvare l’idoneità e le esclusioni. La negoziazione con IA non dovrebbe decidere se sia sicuro includere un fornitore critico.

Passaggio 2: fissare una baseline prima del lancio

Una baseline non è semplicemente il prezzo finale dell’anno scorso. A livello di singolo evento, conservate:

• Offerta iniziale del fornitore e pacchetto finale concordato
• Obiettivo dell’acquirente e soglia di riserva autorizzata
• Quantità, specifiche, area geografica e calendario delle consegne
• Identità del fornitore, stato di fornitore storico e cronologia delle prestazioni pertinente
• Indici valutari, di trasporto, delle materie prime o del costo del lavoro, ove rilevanti
• Condizioni di pagamento, garanzia, sconti, servizi, risoluzione e tempi di consegna
• Fornitori invitati, partecipanti, ritiratisi e arrivati al termine
• Ore di lavoro degli acquisti e durata del ciclo
• Valori di aggiudicazione, contratto, modifiche e fatture
• Escalation, interventi manuali, reclami ed eventi non riusciti

Ove possibile, utilizzate almeno un ciclo completo di acquisto precedente, ma non presumete che i dati storici, da soli, forniscano il controfattuale. Specifiche, domanda, concorrenza e mercati potrebbero essere cambiati.

Definite l’equazione del valore prima di rendere visibili i risultati:

Valore commerciale rettificato = costo controfattuale normalizzato − costo totale valutato finale

Il controfattuale potrebbe essere il risultato di un controllo contemporaneo, un risultato storico rettificato per il mercato o una stima indipendente del costo obiettivo. Registrate quale metodo si applica a ciascun evento.

Non definite il risparmio come differenza tra il prezzo iniziale e quello finale del fornitore. Le offerte iniziali possono essere strategiche e il comportamento dei fornitori può cambiare quando entra in gioco una piattaforma di negoziazione. I materiali del NIST AI RMF sottolineano l’importanza di documentare la progettazione dei test, i benchmark, il contesto, l’incertezza e i limiti del sistema (NIST AI RMF Core).

Approvazione umana obbligatoria: la funzione finanziaria o un responsabile indipendente della verifica del valore dovrebbe approvare la normalizzazione, le valutazioni delle condizioni non economiche, gli adeguamenti agli indici, le regole di attribuzione e il valore commerciale dichiarato.

Passaggio 3: creare un gruppo di controllo che regga a un esame rigoroso

Progettazione preferibile: controllo contemporaneo randomizzato

Prima di contattare i fornitori, assegnate casualmente gli eventi idonei a:

• Trattamento: processo di negoziazione degli acquisti supportato dalla piattaforma; oppure
• Controllo: processo esistente durante lo stesso periodo.

Stratificate l’assegnazione in base ai fattori che potrebbero influire sui risultati, come categoria, valore previsto, area geografica, stato di fornitore storico, numero di fornitori e condizioni di mercato rilevanti. Analizzate i risultati in base all’assegnazione originaria, quindi riportate separatamente l’uso effettivo, i passaggi da un gruppo all’altro e gli interventi manuali.

Questo riduce il rischio che gli acquirenti assegnino al trattamento le opportunità più semplici e al controllo gli eventi più difficili.

Alternativa: controlli contemporanei abbinati

La randomizzazione può essere incompatibile con le policy, i requisiti di trattamento dei fornitori, i vincoli operativi o il volume degli eventi. In tal caso, abbinate gli eventi in base a:

• Categoria e specifiche
• Valore e volume previsti
• Tempistiche e indice di mercato pertinente
• Numero di fornitori e stato di fornitore storico
• Acquirente o unità aziendale
• Complessità commerciale e percorso negoziale

L’abbinamento non può eliminare ogni differenza nascosta. Dichiarate l’incertezza residua. I materiali del GAO sulla valutazione considerano importante l’equivalenza iniziale e trattano l’abbinamento o la correzione statistica quando i gruppi di intervento e di confronto differiscono prima del trattamento (GAO).

Protezioni minime per il gruppo di controllo

• Fissate i criteri di idoneità prima dell’assegnazione.
• Applicate le stesse regole di qualificazione, approvazione e aggiudicazione.
• Registrate ritiri, passaggi tra gruppi, interventi manuali e messaggi inviati manualmente.
• Mantenete invariata la policy di negoziazione per gli eventi di trattamento comparabili.
• Registrate versione della piattaforma, configurazione, prompt e modifiche alle regole.
• Ove possibile, affidate l’analisi a persone indipendenti dalle definizioni di successo del fornitore.
• Richiedete a un analista esterno al fornitore della piattaforma di riprodurre i calcoli.

Se non è possibile realizzare controlli randomizzati o abbinati in modo difendibile, definite l’iniziativa come test di fattibilità operativa, non come prova del ROI.

La scheda riutilizzabile per la progettazione dell’esperimento pilota

Compilate questa scheda prima di attivare il primo evento. Le celle vuote indicano decisioni progettuali ancora da prendere, non pratiche da completare in un secondo momento.

Per una panoramica più ampia di come la tecnologia possa inserirsi in flussi di lavoro governati, consultate negoziazioni con IA. I team che confrontano requisiti di flusso di lavoro e di sistema possono inoltre consultare software per la negoziazione negli acquisti e la guida correlata alla preparazione dei dati.

Per esempio, in un flusso di lavoro concreto di Negotiations.AI, un team acquisti potrebbe usare la piattaforma negli eventi assegnati al trattamento ed esportare messaggi dei fornitori, approvazioni, concessioni, date e ore e registrazioni degli interventi manuali nel pacchetto probatorio. La pertinenza dipende dal flusso di lavoro configurato e dalle esportazioni disponibili: il progetto pilota deve verificarle, non presumerle.

Passaggio 4: registrare in anticipo una scorecard equilibrata

Scegliete un risultato primario per evitare la selezione opportunistica dei dati da riportare. Un candidato utile è il valore commerciale totale rettificato per evento idoneo, che include le condizioni non economiche solo se è stato approvato in anticipo un metodo di valutazione.

Le misure secondarie dovrebbero verificare se il valore apparente abbia trasferito costi o rischi altrove:

Aspetti commerciali

• Valore commerciale totale rettificato
• Scostamento tra contratto e fattura
• Variazioni di condizioni di pagamento, tempi di consegna, garanzie, sconti e servizi
• Costo totale del progetto pilota, inclusi integrazione, verifica, assistenza e gestione del cambiamento

Aspetti operativi

• Tasso di completamento
• Durata complessiva del ciclo
• Tempo di risposta dei fornitori
• Ore di lavoro degli acquisti
• Errori di integrazione e rilavorazioni manuali
• Fedeltà all’implementazione e passaggi tra gruppi di trattamento e controllo

Fornitori e rischio

• Tassi di partecipazione e ritiro
• Reclami e richieste di escalation
• Interventi manuali e violazioni dei limiti
• Incidenti di sicurezza, privacy, riservatezza o equità
• Risultati per segmenti di fornitori pertinenti, ove consentito dalla legge
• Prestazioni successive all’aggiudicazione in termini di qualità, consegna e servizio

Per ogni misura, specificate la fonte, la formula, il responsabile, la regola per i dati mancanti, la regola di esclusione e la frequenza di rendicontazione. Riportate dimensione del campione, dispersione, intervalli di incertezza ove opportuno, eccezioni, dati mancanti e risultati per categoria, non solo una media aggregata.

Ipotesi da verificare: i dati di contratti, fatture, fornitori e flussi di lavoro possono essere collegati tramite identificativi stabili. Se non è possibile, l’iniziativa è inizialmente un progetto pilota di preparazione dei dati, non una prova del ritorno.

Esempio ipotetico: rinnovi di imballaggi

Esempio ipotetico: non costituisce evidenza osservata né benchmark.

Un team acquisti aziendale gestisce rinnovi ricorrenti di imballaggi con specifiche stabili e diversi fornitori qualificati. Prima di contattare i fornitori, il team fissa l’elenco degli eventi idonei. Assegna gli eventi idonei tra un processo supportato dalla piattaforma e il normale processo guidato dall’acquirente, stratificando per tipo di imballaggio, volume previsto e stato di fornitore storico.

La funzione finanziaria approva un modello di valore che comprende prezzo unitario, trasporto, condizioni di pagamento e penali di servizio definite in anticipo. Gli acquisti registrano il tempo di lavoro, mentre la funzione operativa fornitori registra partecipazione, ritiri ed escalation. La piattaforma può negoziare entro i limiti approvati, ma un acquirente nominato deve approvare formulazioni non standard, modifiche oltre i limiti delegati, accomodamenti per i fornitori e tutte le aggiudicazioni.

Supponiamo che gli eventi di trattamento si concludano più rapidamente, ma comportino frequenti interventi umani e dati sul trasporto incoerenti. Il team non dovrebbe limitarsi a dichiarare un aumento dell’efficienza. In base a una regola registrata in anticipo, potrebbe classificare il risultato come «riprogettare e ripetere il test», perché la fedeltà all’implementazione e la qualità della baseline non sono sufficienti per attribuire il valore. La decisione appropriata dipende dalle soglie approvate localmente; non si intende suggerire alcuna soglia universale.

Passaggio 5: stabilire i criteri di uscita prima che emergano i risultati

Le soglie devono essere definite localmente. Le seguenti sono soglie decisionali raccomandate, non benchmark verificati esternamente.

Estendere solo se vengono superate tutte e quattro le soglie

1. Qualità delle prove: l’assegnazione è rimasta attendibile, i calcoli sono riproducibili e i dati mancanti o i passaggi tra gruppi sono rimasti entro i limiti approvati.
2. Valore: il risultato primario ha superato il minimo definito localmente e si è mantenuto nella stessa direzione nelle analisi di sensibilità.
3. Rischio: non rimangono problemi rilevanti irrisolti di sicurezza, natura legale, riservatezza, equità, trattamento dei fornitori o continuità.
4. Operatività: adozione, fedeltà, completamento, durata del ciclo, integrazione e requisiti di assistenza hanno superato le soglie previste.

Riprogettare e ripetere il test quando

• I risultati dipendono da una sola categoria, tipologia di fornitore o acquirente.
• Gli interventi manuali sono frequenti o concentrati attorno a una regola.
• La partecipazione dei fornitori diminuisce.
• Il prezzo migliora mentre peggiorano condizioni non economiche rilevanti.
• La qualità dei dati o la contaminazione del gruppo di controllo impediscono l’attribuzione.
• L’integrazione e il lavoro manuale compromettono il valore operativo.

Sospendere immediatamente gli eventi interessati quando

• Il sistema assume o comunica un impegno non autorizzato.
• Viene superata una soglia di riserva o un limite delegato.
• Informazioni riservate di un fornitore vengono divulgate o utilizzate impropriamente.
• Non è possibile convalidare un calcolo rilevante.
• Il trattamento dei fornitori diventa incoerente o potenzialmente discriminatorio.
• Si verifica un incidente di sicurezza o privacy.
• Non è possibile ricostruire la negoziazione dai registri.
• Un reclamo di un fornitore segnala un possibile danno legale, etico o reputazionale.

Interrompere quando

Dopo gli interventi correttivi, la piattaforma non è in grado di soddisfare i requisiti minimi di sicurezza, verificabilità, approvazione, reversibilità o produzione di prove, oppure quando i benefici convalidati in modo indipendente non giustificano i costi complessivi della piattaforma, dell’integrazione, della supervisione e della gestione del cambiamento.

Il NIST sottolinea l’importanza di meccanismi di intervento, ricorso, risposta agli incidenti, monitoraggio, ripristino e dismissione (NIST AI RMF Core). Anche le linee guida del governo britannico sugli acquisti di IA sottolineano la valutazione dei dati, la supervisione, la valutazione lungo il ciclo di vita, l’allocazione dei rischi e le decisioni go/no-go (GOV.UK).

Autorità umana non delegabile

Persone nominate dovrebbero restare responsabili di:

• Approvazione di categorie, fornitori e casi d’uso
• Obiettivi, soglie di riserva e limiti alle concessioni
• Comunicazioni rivolte ai fornitori e policy di negoziazione
• Risposte sensibili, ambigue, nuove o non standard
• Concessioni al di fuori dell’autorità delegata
• Aggiudicazioni, condizioni contrattuali e modifiche
• Ricorsi e accomodamenti per i fornitori
• Classificazione degli incidenti e decisioni di sospensione
• Attribuzione del valore e rendicontazione esterna
• Modifiche alla piattaforma, ai prompt, al modello o alla configurazione
• Decisione finale di estendere o interrompere

Anche l’accesso alle vere soglie di riserva richiede controlli deliberati. Limitate l’accesso, registratelo e verificate le protezioni contrattuali e tecniche. Non utilizzate le offerte riservate di un fornitore per addestrare o ottimizzare interazioni in modo da esporre o sfruttare tali informazioni nei confronti di un altro fornitore.

La responsabilità esecutiva non viene trasferita a un fornitore o a un sistema. Il NIST AI RMF è volontario, ma la sua struttura di governance offre un riferimento utile per mantenere la responsabilità in capo all’organizzazione.

Quando questa progettazione del progetto pilota non è applicabile

Non utilizzate questa progettazione senza modifiche quando:

• Le negoziazioni sono rare, uniche o troppo eterogenee per essere confrontate.
• L’assegnazione dei fornitori violerebbe policy, obblighi contrattuali o requisiti di equità nel trattamento.
• Un’interazione non riuscita potrebbe interrompere operazioni critiche o creare rischi per la sicurezza.
• L’organizzazione non può esportare registri completi e ricostruire le decisioni.
• Non è possibile misurare in modo coerente condizioni non economiche rilevanti.
• Gli shock di mercato rendono speculativo l’adeguamento della baseline.
• I fornitori necessitano di accomodamenti che il flusso di lavoro non è in grado di supportare in modo affidabile.
• La piattaforma cambia in modo sostanziale durante il test senza controllo delle versioni.

I risultati si applicano inoltre solo alle categorie, ai fornitori, agli utenti, alla configurazione, alla versione della piattaforma e alle condizioni di mercato testati. Non dimostrano automaticamente le prestazioni in tutti i casi d’uso di negoziazione aziendale. I materiali del NIST sottolineano esplicitamente il contesto di implementazione, l’incertezza, i limiti e il monitoraggio continuo, anziché presumere che i risultati dei test siano generalizzabili ovunque (NIST AI RMF Core).

Lista di controllo per il lancio del progetto pilota

Prima del primo contatto con un fornitore, verificate che:

• L’affermazione da verificare e la decisione siano state messe per iscritto.
• I criteri di idoneità e le esclusioni siano stati fissati.
• L’assegnazione ai gruppi di trattamento e controllo sia stata completata.
• I dati della baseline e i metodi di adeguamento siano stati bloccati.
• Il risultato primario e le metriche secondarie siano stati registrati in anticipo.
• Le soglie locali e i test di sensibilità siano stati approvati.
• Siano stati nominati i responsabili umani e i contatti per le escalation.
• Le soglie di riserva e i dati riservati siano protetti da controlli di accesso.
• Siano disponibili canali di escalation e accomodamento per i fornitori.
• Registri, trascrizioni, configurazioni e interventi manuali siano esportabili.
• Le procedure per incidenti, sospensione, ripristino e dismissione siano state testate.
• Un analista indipendente sia in grado di riprodurre l’analisi finale.

Il proof of concept più solido di una piattaforma di negoziazione non è quello con la dashboard più favorevole. È quello le cui prove restano utili anche quando il risultato è misto, scomodo o negativo.

Approfondimenti

• NIST AI Risk Management Framework
• NIST AI RMF Core
• Pratiche del GAO per la progettazione dei progetti pilota
• Linee guida del Regno Unito per gli acquisti di IA

Domande frequenti

Quanto dovrebbe durare un progetto pilota di negoziazione con IA?

Non esiste una durata universale. Proseguite abbastanza a lungo da includere un numero di eventi idonei comparabili giustificato localmente e condizioni di mercato pertinenti. Determinate le esigenze del campione in base al volume previsto degli eventi, alla variabilità dei risultati, all’effetto minimo significativo e all’analisi prevista. Se il volume degli eventi è troppo basso, considerate l’esercizio uno studio di fattibilità, non un test conclusivo del valore.

Le prestazioni storiche possono essere l’unico gruppo di controllo?

A volte, ma sono meno solide di un controllo contemporaneo quando cambiano mercati, domanda, partecipazione dei fornitori o specifiche. Se i dati storici sono l’unica opzione, normalizzate le differenze documentate, svolgete analisi di sensibilità e dichiarate chiaramente che l’attribuzione resta incerta.

Bisogna informare i fornitori che è coinvolta una negoziazione con IA?

La comunicazione dipende dalla legge applicabile, dalle policy, dal contratto, dalla progettazione delle comunicazioni e dal rischio. I responsabili legali e degli acquisti dovrebbero decidere prima del lancio. Indipendentemente dalla formulazione utilizzata, i fornitori devono disporre di un chiaro canale di escalation umana e il team dovrebbe misurare se il coinvolgimento della piattaforma modifica le offerte iniziali, la partecipazione o i ritiri.

Qual è la differenza tra un test del flusso di lavoro e un proof of concept di una piattaforma di negoziazione?

Un test del flusso di lavoro verifica se il processo funziona: i messaggi vengono inviati, le approvazioni seguono il percorso previsto e i registri vengono esportati. Un proof of concept attendibile verifica inoltre se la piattaforma ha causato risultati migliori rispetto a un controfattuale difendibile, a un costo totale e a un livello di rischio accettabili.

Chi dovrebbe prendere la decisione finale di estendere l’uso?

La decisione dovrebbe spettare a un gruppo di governance interfunzionale, sulla base delle soglie concordate in anticipo. Potrebbero essere coinvolti acquisti, finanza, responsabili aziendali, sicurezza, privacy, funzioni legali o di conformità, rischio fornitori e operazioni tecniche. Il fornitore della piattaforma non dovrebbe essere l’unico giudice del proprio successo.

Dichiarazione di non responsabilità: questo articolo fornisce informazioni operative generali e non costituisce consulenza legale, finanziaria, di sicurezza o in materia di acquisti.