Holimization: Perché l'ottimizzazione non basta
Per la maggior parte della mia carriera, mi è stato detto che “optimization” è la risposta. Se solo potessimo formulare il modello giusto, alimentarlo con abbastanza dati e dare libero corso a un solver potente, la macchina produrrebbe tranquillamente le migliori decisioni possibili.
Eppure, nelle real supply chains, questa promessa raramente si concretizza. Le aziende implementano software sofisticati, regolano innumerevoli parametri e si ritrovano comunque a dover fronteggiare esaurimenti di scorte, eccessi di inventario e planner nervosi che non si fidano più del sistema. La matematica all’interno della scatola nera può essere bella; le decisioni sul piano del magazzino spesso non lo sono.
In Introduction to Supply Chain, in particolare nei capitoli dedicati alle decisioni e alle ricette numeriche, ho sostenuto che il vero collo di bottiglia non è la mancanza di solver, ma la mancanza di un quadro adeguato attorno all’ottimizzazione stessa. In questo saggio voglio portare questa idea un passo oltre e darle un nome: holimization, e il suo verbo, to holimize, formato dalla contrazione di “holistic optimization”.
Quando l’ottimizzazione è inquadrata attorno alla domanda sbagliata
L’ottimizzazione classica, nella sua forma più semplice, parte da una postura molto allettante:
“Dimmi cosa vuoi massimizzare o minimizzare, elenca i vincoli, e io troverò la decisione migliore possibile.”
Su una lavagna questo suona perfettamente ragionevole. In una supply chain, però, nasconde quasi tutto ciò che conta veramente.
Cosa stiamo esattamente “massimizzando”? Il profitto di questo mese? Di un anno? La crescita su diversi anni? La soddisfazione del cliente in un senso non del tutto misurabile? La resilienza alle interruzioni? Una combinazione di tutto quanto sopra?
Quali sono esattamente i vincoli? Quelli formali, come capacità e lead time, o anche quelli non documentati, come “questa squadra di magazzino non può realisticamente gestire più di 5,000 inbound cartons a day” o “questa macchina non può essere resettata due volte nella stessa settimana”?
E come dovremmo misurare il danno? Un esaurimento di scorte è peggiore di una svendita? Di quanto, in termini monetari, e per quali prodotti?
Quando implementiamo un motore di ottimizzazione classica all’interno di una supply chain, siamo costretti a rispondere a queste domande codificandole — esplicitamente o implicitamente — in una funzione obiettivo e in una raccolta di vincoli. Una volta fatto ciò, il solver troverà effettivamente decisioni “ottimali” relative a quella codifica. Sfortunatamente, se la codifica non è nemmeno leggermente allineata con la realtà, otteniamo semplicemente le decisioni sbagliate, e più velocemente.
Ho visto molte variazioni della stessa storia. Un rivenditore lancia un nuovo sistema di rifornimento che massimizza con orgoglio il “service level” soggetto ai costi di inventario e logistica. Gli esaurimenti di scorte diminuiscono sulla carta, ma i negozi ora hanno troppe taglie e colori a lento movimento che i clienti non desiderano. Un produttore installa un sistema di pianificazione avanzato che ottimizza i programmi di produzione su un modello semplificato di capacità; il piano risultante appare elegante nell’interfaccia, ma lo stabilimento trascorre il suo tempo a improvvisare soluzioni perché il modello non ha mai catturato i colli di bottiglia critici sul piano di produzione.
In ciascuno di questi casi, l’ottimizzazione in sé funziona. Il computer fa esattamente ciò che gli abbiamo chiesto. Il problema è che abbiamo posto la domanda sbagliata.
Dare un nome alla disciplina mancante
Il concetto che voglio introdurre è questo:
Holimization (n.) – La disciplina della ottimizzazione olistica per sistemi complessi ed in evoluzione, dove l’oggetto primario di progettazione è il quadro dell’ottimizzazione stesso: obiettivi, vincoli, semantica dei dati e grammatica decisionale. Holimization considera l’ottimizzazione come un processo iterativo e sperimentale in cui la funzione obiettivo, il modello e la strumentazione co-evolvono in base al feedback del mondo reale.
To holimize (v.) – Orchestrare un processo del genere: inquadrare, strumentare, ottimizzare e rifattorizzare ripetutamente il sistema decisionale in modo che rimanga allineato con la realtà economica e l’intento organizzativo.
L’ottimizzazione, in senso stretto, si concentra sul ciclo interno: dato un obiettivo fisso e una rappresentazione fissa del mondo, trovare decisioni che estremizzino tale obiettivo. Holimization si concentra sul ciclo esterno: come progettiamo quell’obiettivo, come rappresentiamo il mondo, come strumentiamo il sistema e come tutto ciò cambia nel tempo.
In altre parole, l’ottimizzazione risponde: “Qual è il migliore, supponendo che il mondo sia così?” Holimization chiede: “Stiamo guardando il mondo in un modo che permetta al concetto di ‘migliore’ di avere senso?”
Questo non è un punto filosofico astratto. In un ambiente caotico e in evoluzione come una supply chain, la domanda su cui ottimizziamo continua a cambiare sotto i nostri piedi. I mercati si spostano, gli assortimenti cambiano, i canali appaiono e scompaiono, le normative evolvono e le priorità interne si muovono. Se il nostro quadro di ottimizzazione rimane fisso mentre il mondo intorno a esso cambia, la divergenza tra ciò che è “ottimale” sullo schermo e ciò che è sensato nella realtà cresce costantemente nel tempo.
Holimization è il nome che propongo per la disciplina che tratta il quadro stesso come un oggetto di lavoro di prim’ordine.
Cosa significa holimizzare una supply chain
Permettetemi di rendere questo concetto concreto con esempi di supply chain, poiché è qui che ho trascorso la maggior parte del mio tempo.
Immaginate un rivenditore di moda che vuole “migliorare il service” nei negozi. Se adottiamo l’approccio dell’ottimizzazione in senso stretto, potremmo iniziare definendo il service come la probabilità di non trovarsi con esaurimenti di scorte quando un cliente entra, e potremmo fissare un obiettivo come “95% service level”. Codificheremmo quindi gli esaurimenti di scorte come un costo, gli eccessi di inventario come un altro costo, e lasceremmo che un motore di ottimizzazione bilanciasse i due.
Ciò porta a decisioni che sono numericamente ordinate ma esteticamente strane. I negozi finiscono per avere un numero tecnicamente sufficiente di unità, ma la maggior parte di esse è nelle taglie sbagliate o tutte negli stessi colori sicuri. Dal punto di vista del modello, tutto è a posto: l’obiettivo di service è raggiunto e i costi sono contenuti. Dal punto di vista del cliente che entra nel negozio, la collezione appare priva di vita.
Se invece holimizziamo, accettiamo che il “service” non sia ancora formulato correttamente. Trasformiamo l’implementazione del sistema decisionale in un esperimento sulle nostre stesse ipotesi.
Iniziamo implementando una vera ricetta decisionale, alimentata da dati e ottimizzazione, ma la circondiamo con strumenti di monitoraggio progettati per evidenziare decisioni “insane”: assortimenti che qualsiasi buyer umano giudicherebbe immediatamente come dannosi, anche se il sistema non è ancora in grado di spiegare il perché. Monitoriamo i negozi in cui il modello insiste nell’inviare un mix implausibile di taglie e pietre preziose di articoli in svendita. Ascoltiamo attentamente i planner che si lamentano del fatto che il sistema continua a privare alcuni negozi di varietà.
Ogni volta che incontriamo tale assurdità, la tracciamo indietro. Forse la nostra funzione obiettivo non ha modo di premiare la diversità dell’assortimento, ma solo la disponibilità delle unità. Forse non abbiamo mai individuato il limite pratico di quante volte un negozio può essere resettato. Forse i nostri dati storici celano effetti di sostituzione che rendono alcuni esaurimenti di scorte molto meno dannosi di altri.
Poi cambiamo il quadro. Introduciamo una nozione quantificata di diversità nell’obiettivo, con un valore finanziario ad essa associato. Sostituiamo un vincolo rigido con un costo, o viceversa. Aggiungiamo una nuova classe di decisioni alla ricetta, come ad esempio quando rinnovare un display o come dilazionare le consegne per i negozi fragili. Estendiamo gli strumenti di monitoraggio per visualizzare questi nuovi aspetti in modo che, se dovesse verificarsi un nuovo caso di assurdità, sia più facile diagnosticarlo.
Abbiamo holimizzato la situazione: invece di incolpare il solver o ignorare il sistema, abbiamo utilizzato i fallimenti delle decisioni stesse come segnali che il nostro quadro era incompleto e doveva evolvere.
Una storia simile si verifica nelle operazioni di manutenzione e riparazione. Supponete di gestire ricambi per motori di aeromobili. L’approccio ingenuo dell’ottimizzazione consiste nel trattare ogni parte in modo indipendente: stimare quanto frequentemente verrà necessaria, assegnare un costo agli esaurimenti di scorte e un costo per il mantenimento dell’inventario, e lasciare che la macchina trovi il miglior punto di riordino.
Nella pratica, non è così che vengono riparati i motori. Il danno reale si verifica quando una riparazione viene ritardata perché manca una parte critica, anche se si è sommersi da un inventario di decine di altre parti. Il costo non è un esaurimento di scorte su una riga di un foglio di calcolo; sono giorni di fermo per un aeromobile.
Holimization ci costringe a riformulare l’obiettivo attorno a qualcosa di più vicino alla realtà: ad esempio, la riduzione dei giorni di ritardo attesi per motore per unità di budget. Ci spinge a strumentare il processo con viste che rendono ovvio quali parti sono ripetutamente responsabili del blocco delle riparazioni. Quando il sistema suggerisce di accumulare una grande quantità di una parte che in realtà non blocca mai le riparazioni, questo è un segnale di assurdità. Quando invece ne priva una che ritarda ripetutamente i motori, è un altro segnale.
Non trattiamo questi fallimenti come errori imbarazzanti da nascondere. Li consideriamo la nostra migliore fonte di informazioni su dove il nostro quadro è errato. Poi, aggiustiamo il modo in cui misuriamo il danno, i collegamenti tra eventi e costi, e il modo in cui strutturiamo le decisioni affinché le ottimizzazioni future siano condotte in uno spazio più aderente alla realtà.
Holimization, dunque, non riguarda l’eliminazione dell’ottimizzazione. Si tratta di circondare l’ottimizzazione con una pratica disciplinata di apprendimento dai suoi errori.
Il lavoro nascosto attorno al motore di ottimizzazione
Se entri in una grande azienda che “fa optimization”, la maggior parte degli sforzi che vedrai non riguarda la progettazione di algoritmi. Si tratta di dare senso ai dati, gestire le eccezioni e conciliare ciò che il sistema dice con ciò che la realtà permette.
Holimization rende esplicito e strutturato quel lavoro nascosto.
Una gran parte della difficoltà risiede nella semantica dei dati. I sistemi operativi contengono un numero impressionante di campi, codici e stranezze storiche. Quando un motore decisionale prende questi dati per oro colato, inevitabilmente ne interpreta alcuni in modo errato. Un limite che una volta era significativo potrebbe essere diventato obsoleto. Un campo che sembra rappresentare il “lead time” può in effetti essere una combinazione di ritardi di transito e amministrativi. Un flag che sembra indicare che un prodotto sia “on promotion” potrebbe essere usato in modo incoerente tra le regioni.
Senza una mentalità holimization, queste problematiche vengono scoperte per caso, spesso dopo che il danno è stato fatto. Con holimization, assumiamo fin dall’inizio che la nostra interpretazione dei dati sia provvisoria. Costruiamo test, confronti e controlli di coerenza che tentano di falsificare la nostra lettura dei dati. Quando il sistema propone una decisione che sovraccaricherebbe un molo, non la imputiamo alla “sfortuna”; la consideriamo come prova che un vincolo manca nella nostra visione del mondo.
Un altro componente importante è la strumentazione. Un motore di ottimizzazione da solo è cieco: riceve dati, emette decisioni e non ha alcun giudizio su quanto queste decisioni siano sensate. Holimization richiede uno strato di visibilità progettato non solo per monitorare gli indicatori chiave di prestazione, ma anche per evidenziare dove il sistema si comporta in modi che gli umani trovano assurdi.
Questo può assumere molte forme: viste a time-travel che ci permettono di riprodurre decisioni basate su dati passati; microscopi su un singolo prodotto o sito, che mostrano come la decisione si è evoluta nel tempo; dashboard che evidenziano gli outlier invece delle medie. L’obiettivo è sempre lo stesso: trasformare le variabili “insane” in un canale di feedback strutturato, e non in una fonte di frustrazione.
Infine, c’è la rapidità e la sicurezza dell’iterazione. Holimization è per natura sperimentale. Abbiamo bisogno di provare nuovi quadri e obiettivi rivisti senza mettere a rischio l’intera azienda ogni volta. Ciò implica capacità tecniche — versioning delle ricette decisionali, rollout controllati, shadow modes — ma anche capacità organizzative: responsabilità chiare, una cultura che accetta gli esperimenti come necessari e una direzione che comprenda la differenza tra una regola di produzione stabile e un test esplorativo.
Tutto questo è lavoro. È, tuttavia, un lavoro che già stiamo svolgendo informalmente ogni volta che ci lamentiamo del fatto che “il sistema non lo capisce.” Holimization è un tentativo di dare a questo lavoro un nome adeguato e un metodo appropriato.
Perché una nuova parola è importante
Potresti ragionevolmente chiederti: perché coniare un nuovo termine? Perché non parlare semplicemente di “buone pratiche di ottimizzazione” o “modellazione sperimentale”?
La mia esperienza è che senza un nome distinto, il ciclo esterno viene assorbito da quello interno. Una volta che la parola “ottimizzazione” è in tavola, l’attenzione si concentra su algoritmi, solver e benchmark di prestazioni. La conversazione si sposta sul fatto che un metodo particolare converga più velocemente o scala meglio, invece che sulla domanda più scomoda se stiamo ottimizzando la cosa giusta fin dall’inizio.
Al contrario, “holimization” porta, nella sua stessa costruzione, il promemoria che l’ottimizzazione è solo uno degli ingredienti in una disciplina più ampia. Dice che ci interessa l’intero arco dalla realtà ai dati, dalla decisione e infine di nuovo alla realtà. Suggerisce che il nostro artefatto primario non è il solver, ma il quadro in evoluzione in cui opera il solver.
Per la mia azienda, Lokad, questa denominazione chiarisce anche ciò che stiamo cercando di costruire. Non siamo, in sostanza, un fornitore di un altro motore di ottimizzazione. Stiamo cercando di fornire una piattaforma dove le aziende possano holimizzare le loro supply chains: un luogo dove i dati possono essere rimodellati, dove gli obiettivi possono essere espressi in termini finanziari, dove le decisioni possono essere automatizzate rimanendo comprensibili, e dove ogni fallimento del sistema è trattato come un prezioso spunto di apprendimento su come il quadro dovrebbe evolversi.
La parola è nuova, ma il bisogno che esprime non lo è. Le supply chains, e molti altri sistemi complessi, si sono quietamente holimizzati per anni attraverso tentativi ed errori, soluzioni con fogli di calcolo e riunioni infinite. La mia speranza è che, dando a questo processo un nome e una forma più chiara, possiamo renderlo più deliberato, più rigoroso e, in ultima analisi, più efficace.
L’ottimizzazione, come la matematica, non sparirà; se non altro, continuerà a migliorare. Holimization è l’invito a salire di un livello, a trattare i nostri modelli, obiettivi e vincoli non come sacri, ma come ipotesi da verificare nel mondo. Solo allora “ottimale” smetterà di essere un’etichetta formale in un rapporto e inizierà ad assomigliare alle decisioni che veramente desideriamo sul campo.
