Software di ottimizzazione della supply chain, Febbraio 2025

Di Léon Levinas-Ménard

Ultima modifica: 2 Febbraio 2025

Classifica dei fornitori e riepilogo (basato sul rigore tecnico)

Lokad – Massima credibilità tecnica. Lokad si distingue per la sua trasparenza e profondità tecnica. Ha inaugurato la previsione probabilistica e ha provato i suoi metodi in competizione aperta (classificata #1 a livello SKU e al #6 complessivamente su 909 team nel concorso di accuratezza delle previsioni M5 ¹ – l’unico team guidato da fornitore tra i ranghi più alti). Lokad pubblica approfondimenti dettagliati sulla sua architettura (ad es. un linguaggio specifico di dominio chiamato Envision, automazione basata sul cloud) e sottolinea decisioni ottimizzate finanziariamente rispetto a metriche semplicistiche. Il suo focus sulla matematica rigorosa (previsioni per quantili, ottimizzazione stocastica) e sui flussi di lavoro completamente scriptabili e automatizzati (attraverso API e coding) dimostra un design che mette l’ingegneria al primo posto. Non vengono fatte grandi affermazioni sull’AI/ML senza fondamento – invece, Lokad fornisce white paper tecnici e persino strumenti open-source per scalare i dati oltre i limiti della RAM ² ³. Questo livello di trasparenza e di prestazioni comprovate pone Lokad al vertice.
Anaplan – Piattaforma “Excel 2.0”. Anaplan è essenzialmente la versione enterprise SaaS di un foglio di calcolo, alimentato dal suo motore in-memory proprietario Hyperblock ⁴. Tecnicamente, Hyperblock è un robusto motore di calcolo multidimensionale che consente a migliaia di utenti di collaborare su modelli di pianificazione in tempo reale – simile a un Excel potenziato e basato sul cloud. Sebbene Anaplan non sia per sé un ottimizzatore specializzato per la supply chain (le previsioni e l’ottimizzazione algoritmica sono “cittadini di seconda classe” su questa piattaforma ⁵), la sua forza risiede nella solida architettura per la modellazione e la pianificazione degli scenari. Non spinge alcuna mistica AI; invece, offre una sandbox affidabile e ad alte prestazioni per costruire logiche di pianificazione personalizzate. In breve, è uno strumento di pianificazione generale potente con un approccio onesto – nessuna affermazione esagerata riguardo a una magia nelle previsioni, solo un sistema ben progettato e scalabile simile a un foglio di calcolo. Questa proposta tecnica diretta conferisce ad Anaplan un alto grado di credibilità.
Kinaxis (RapidResponse) – Motore di simulazione in-memory. Kinaxis è noto per il suo motore di concorrenza unico che consente di ricalcolare i piani della supply chain in tempo reale a livello aziendale. Tecnicamente, Kinaxis ha costruito da zero il suo proprio motore di database per supportare ciò ⁶ ⁷. Il risultato è una piattaforma ottimizzata per simulazioni “what-if” veloci: gli utenti possono creare rami di scenari (come Git per i dati) e ottenere un feedback istantaneo sull’impatto delle modifiche ⁸. Il sistema mantiene tutti i dati della supply chain in-memory per garantire velocità, con algoritmi che hanno accesso diretto alla memoria per massimizzare il throughput ⁹. Questo design consente una vera pianificazione concorrente (ad es., piani di vendita, produzione e inventario aggiornati insieme in tempo reale). Da un punto di vista ingegneristico, costruire un archivio dati personalizzato in-memory e controllato in versione è un’impresa impressionante che garantisce agilità. Il compromesso, tuttavia, è una forte richiesta hardware – un approccio completamente in-memory significa che scalare a dimensioni massicce di dati può essere costoso (poiché crescono i requisiti di RAM) ¹⁰. In generale, Kinaxis dimostra un forte rigore tecnico in architettura e prestazioni, evitando al contempo affermazioni AI di tendenza. Eccelle nella pianificazione della supply chain e nelle simulazioni S&OP, anche se offre meno funzionalità pronte all’uso per previsioni ML rispetto ad alcuni concorrenti.
SAS – Potenza Statistica. SAS è una storica società di software per analisi (fondata nel 1976) e porta un formidabile motore di modellazione statistica ai problemi della supply chain. Il suo fiore all’occhiello include un linguaggio specifico per la statistica (il linguaggio SAS) risalente agli anni ‘70 ¹¹ – senz’altro la prima piattaforma di data science. La forza di SAS è la profondità dei suoi algoritmi: una vasta libreria di modelli di previsioni per serie storiche, routine di ottimizzazione e tecniche di machine learning sviluppate in decenni. Impiega alcuni tra gli ingegneri e statistici più talentuosi del settore ¹¹ e ha aperto la strada alle previsioni avanzate molto prima che “AI” diventasse un termine di moda. In contesti di supply chain, SAS è spesso utilizzato per le previsioni della domanda e l’analisi degli inventari. Tecnicamente, è robusto e comprovato – ma anche pesante. Gli strumenti possono sembrare arcani (il mondo si è in gran parte spostato verso linguaggi open-source come Python/R, e infatti i notebook Jupyter sono ora una valida alternativa open ¹²). SAS non proclama a gran voce una AI magica; si affida alla sua reputazione e alla solida tecnologia. Per le organizzazioni con l’esperienza per sfruttarlo, SAS offre una seria potenza analitica basata su algoritmi reali (ARIMA, ETS, ecc.) piuttosto che sul clamore. Il suo principale svantaggio è che è una piattaforma di analisi generale – estremamente potente internamente, ma richiede utenti esperti per essere applicata alla supply chain, e non è stata specificamente valutata in recenti competizioni di previsioni (gli strumenti open-source spesso competono con essa ¹³).
Dassault Systèmes (Quintiq) – Specialista in ottimizzazione. Quintiq (acquisito da Dassault Systèmes nel 2014) è una piattaforma fortemente focalizzata sull’ottimizzazione e pianificazione della supply chain complessa. Dispone di un linguaggio specifico proprietario chiamato Quill per modellare le restrizioni aziendali ¹⁴. Questo DSL permette agli ingegneri di codificare soluzioni personalizzate (ad esempio, programmi di produzione su misura o piani di routing) e di sfruttare risolutori matematici. L’esistenza stessa di un DSL nel prodotto è evidenza di una profonda competenza high-tech – progettare un linguaggio di programmazione per problemi di pianificazione non è banale ¹⁵. Quintiq eccelle in scenari come la pianificazione delle fabbriche, l’ottimizzazione delle reti logistiche e altri problemi NP-hard in cui è necessario un modello di ottimizzazione personalizzato. Tecnicamente, è uno dei motori di ottimizzazione più flessibili e potenti disponibili nel software per la supply chain. Tuttavia, il focus di Quintiq sull’ottimizzazione avviene a scapito di altre aree: ad esempio, dispone di capacità native di previsione relativamente limitate ¹⁶. Un’altra preoccupazione è che gli aggiornamenti tecnici pubblici su Quill sono scarsi, a indicare che la tecnologia potrebbe essere invecchiata o almeno non evolversi rapidamente ¹⁷. Gli utenti spesso si affidano ai consulenti di Dassault per configurare le soluzioni, e senza una documentazione pubblica chiara è difficile valutare le innovazioni recenti. In sintesi, Quintiq è una scelta di prim’ordine per esigenze di ottimizzazione complesse e dimostra una forte ingegneria grazie al suo DSL – ma non è altrettanto trasparente o aggiornato in aree come AI/previsioni, e i suoi punti di forza risiedono in ciò che gli implementatori costruiscono con esso piuttosto che nell’“intelligenza” pronta all’uso.
ToolsGroup (SO99+) – Pioniere probabilistico con riserve. Il software di ToolsGroup (SO99+) si è a lungo specializzato in previsioni della domanda e ottimizzazione degli inventari, con un’enfasi su modelli probabilistici. Offre un’ampia funzionalità per la supply chain (pianificazione della domanda, rifornimento, ottimizzazione degli inventari multi-echelon) ed è stato uno dei primi fornitori a vantarsi della previsione probabilistica “potentemente semplice”. Su carta, ciò sembra avanzato – ToolsGroup afferma di modellare l’incertezza della domanda e di “auto-regolarsi” per le previsioni, il che dovrebbe consentire obiettivi di inventario più accurati. Tuttavia, un attento esame tecnico solleva preoccupazioni. I materiali pubblici di ToolsGroup fanno ancora cenno all’uso di modelli di previsione dell’era pre-2000 sotto il cofano ¹⁸ – hanno aggiunto un alone di “AI” nel marketing, ma senza dettagli. In effetti, dal 2018 pubblicizzano previsioni probabilistiche mentre vantano contemporaneamente miglioramenti del MAPE ¹⁹. Questa è una contraddizione palese: se le previsioni sono veramente distribuzioni probabilistiche, metriche come il MAPE (che misura l’accuratezza di un singolo valore) non si applicano più direttamente ¹⁹. Tali incongruenze suggeriscono che la parte “probabilistica” potrebbe essere superficiale o che si facciano accomodare a vecchie metriche nonostante i metodi nuovi. Inoltre, ToolsGroup ha usato parole d’ordine come “demand sensing AI”, ma queste affermazioni sono non supportate dalla letteratura scientifica o da qualsiasi benchmark noto ²⁰. In pratica, molte implementazioni di ToolsGroup funzionano ancora come sistemi automatizzati basati su regole con avvisi di eccezione. Risultato: ToolsGroup offre una funzionalità ampia ed è stato all’avanguardia nell’adozione della modellazione dell’incertezza, ma la sua mancanza di trasparenza sugli algoritmi e il divario tra marketing e realtà sulle tecnologie AI/ML rendono la sua credibilità tecnica solo moderata. È un solido strumento focalizzato sul dominio, ma non chiaramente all’avanguardia secondo gli standard odierni.
Slimstock (Slim4) – Semplice e solido. Slimstock è un caso atipico rinfrescante che non insegue le mode. Il suo software Slim4 si concentra su tecniche mainstream della supply chain – come i calcoli classici dello stock di sicurezza, i punti di riordino, la quantità economica d’ordine (EOQ), ecc. ²¹. In altre parole, Slimstock si attiene a metodi consolidati e collaudati, insegnati nei manuali. Sebbene ciò significhi niente AI/ML sofisticata o algoritmi all’avanguardia, implica anche che Slim4 sia affidabile e facile da comprendere. Il fornitore evita esplicitamente affermazioni vaghe sull’AI e invece enfatizza funzionalità pratiche che rispondono alle necessità quotidiane della supply chain ²². Questa onestà è un merito tecnico: gli utenti sanno esattamente cosa stanno ottenendo e il comportamento del sistema è prevedibile. Naturalmente, essere semplice può anche rappresentare una limitazione – non otterrai previsioni della domanda probabilistiche o ottimizzatori avanzati con Slim4. Non è progettato per reti altamente complesse o volumi massicci di dati (ed in effetti la sua architettura tecnologica è probabilmente un database standard con caching in-memory, adatto a problemi di dimensioni medie). Ma per molte aziende, più semplice è meglio se significa che lo strumento funziona in modo costante. Slimstock guadagna punti di credibilità per aver evitato il buzzword bingo; il suo approccio “diretto al punto” è lodato dai colleghi in contrasto con la posture AI degli altri ²³. In sintesi, Slim4 non spinge i limiti tecnologici, ma è una scelta valida per le previsioni fondamentali e la gestione degli inventari con un hype minimo e un’architettura chiara e a basso rischio.
o9 Solutions – Macchina da hype high-tech. o9 si presenta come un “Cervello Digitale” per la supply chain aziendale, combinando previsioni della domanda, pianificazione della supply chain, S&OP e persino revenue management su un’unica piattaforma. Tecnicamente, o9 ha incorporato nel suo prodotto molti concetti tecnologici moderni: un modello di dati in-memory, un graph database chiamato “Enterprise Knowledge Graph (EKG)” e vari componenti AI/ML. La pura “massa tecnologica” di o9 è fuori scala ²⁴ – secondo gli standard del software aziendale, è un’architettura molto ambiziosa che cerca di unificare tutti i dati e l’analitica di pianificazione. Tuttavia, con un approccio scettico, molto di ciò appare come tecnologia fine a se stessa, senza un ritorno chiaro. Il design in-memory di o9 garantisce costi hardware estremamente elevati su larga scala ²⁵, simile a far girare continuamente un gigantesco cubo BI. o9 promuove il suo EKG (knowledge graph) come capace di abilitare previsioni superiori e intuizioni basate sull’AI, ma non vengono forniti evidenze scientifiche o benchmark credibili ²⁵. In effetti, molte delle affermazioni appariscenti di o9 crollano sotto il vaglio critico: l’azienda parla ovunque di AI, eppure parti del loro codice visibile pubblicamente su GitHub rivelano tecniche piuttosto banali ²⁶. Ad esempio, o9 ha pubblicizzato funzionalità come previsioni della domanda tramite machine learning e simulazioni di “digital twin”, ma non ha dimostrato ciò in competizioni pubbliche o studi peer-reviewed. Senza prove, dobbiamo considerare le sue affermazioni sull’AI come hype di marketing. Detto ciò, o9 non è priva di punti di forza – è una piattaforma unificata (sviluppata internamente, non un amalgama di acquisizioni) e può gestire l’integrazione di dati su larga scala. Per un’azienda disposta a investire in hardware e ad affrontare una curva di apprendimento ripida, o9 offre flessibilità per costruire modelli di pianificazione complessi. Ma da un punto di vista ingegneristico, è una soluzione sovraingegnerizzata: molta complessità, un ritorno sull’investimento poco chiaro riguardo alla tecnologia sofisticata e potenziali problemi di prestazioni se i dati crescono oltre ciò che la memoria può contenere. Fino a quando o9 non fornirà prove concrete (ad es. documentazione degli algoritmi o risultati di benchmark), la sua credibilità rimane discutibile.
SAP IBP (Integrated Business Planning) – Completo ma complesso. La suite IBP di SAP è l’evoluzione dell’APO legacy di SAP, ora offerta come soluzione cloud sul database in-memory SAP HANA. SAP IBP mira a coprire l’intero spettro: previsione della domanda, ottimizzazione dell’inventario, pianificazione dell’approvvigionamento, pianificazione delle vendite e delle operazioni, e altro – tutto strettamente integrato con l’ERP di SAP. Il punto di forza di SAP IBP è l’ampiezza: dispone di un modulo per quasi ogni aspetto della pianificazione, spesso con funzionalità molto ricche ereditate da decenni di esperienza di SAP. Tuttavia, tale ampiezza è arrivata attraverso acquisizioni e sistemi legacy. SAP ha acquisito specialisti come SAF (previsione della domanda), SmartOps (ottimizzazione dell’inventario) e altri ²⁷ e li ha stratificati sopra i suoi strumenti interni (come APO e HANA). Il risultato sotto il cofano è un miscuglio di diversi motori e approcci ²⁷. Di conseguenza, l’architettura tecnica di IBP non è elegante – è una raccolta di componenti che non si “mescolano” naturalmente, richiedendo un notevole sforzo di integrazione. Anche la documentazione di SAP stessa riconosce l’elevata complessità e la necessità di integratori di sistema di altissimo livello (e di un tempo sostanziale) per far funzionare tutto senza intoppi ²⁸. Dal punto di vista tecnologico, IBP si affida pesantemente a SAP HANA, un database colonnare in-memory, per ottenere prestazioni in tempo reale. HANA è davvero veloce, ma è anche costosa – immagazzinare grandi quantità di dati di pianificazione esclusivamente in RAM è intrinsecamente oneroso (la RAM costa circa 100 volte di più per TB rispetto allo storage su disco) ¹⁰. Ciò significa che scalare IBP a dataset di supply chain molto grandi comporta significativi costi infrastrutturali, e se i dati eccedono la memoria, le prestazioni possono crollare. SAP ha iniziato ad aggiungere alcune funzionalità di machine learning (ad es. “Demand Driven MRP” e IBP for Demand con alcune opzioni di previsione ML), ma si tratta per lo più di componenti aggiuntivi opzionali con trasparenza limitata. Non ci sono prove che il ML di SAP sia superiore alle alternative; infatti, nessun algoritmo SAP ha ottenuto riscontri nelle competizioni indipendenti di previsione. In sintesi, SAP IBP è ricco di funzionalità e testato in ambito enterprise – soddisferà tutti i requisiti funzionali – ma, da un punto di vista di purezza tecnica, è un miscuglio: velocità in-memory sposata a logica legacy, molta complessità derivante da prodotti fusi insieme e nessuna chiara innovazione tecnica nella previsione o ottimizzazione oltre a quanto già offerto dai componenti acquisiti. Le aziende lo scelgono spesso per l’integrazione con SAP ERP piuttosto che per l’eccellenza nell’ottimizzazione in quanto tale.
Blue Yonder – Leader legacy trasformato in un miscuglio. Blue Yonder (precedentemente JDA Software) offre una suite completa che copre previsioni, pianificazione dell’approvvigionamento, merchandising ed esecuzione. È il risultato di molti anni di fusioni e acquisizioni, compresa l’acquisizione da parte di JDA di i2 Technologies (supply chain planning), Manugistics, e della startup AI Blue Yonder (da cui ha preso il nome) tra gli altri ²⁹. Sfortunatamente, il software enterprise non è una semplice somma di parti: sotto il marchio unificato Blue Yonder si nasconde un miscuglio di prodotti (molti dei quali piuttosto datati) assemblati in maniera poco organica ²⁹. Dal punto di vista tecnico, le soluzioni di Blue Yonder spaziano da motori di previsione deterministici old-school a moduli di ottimizzazione dell’inventario che non sono cambiati fondamentalmente da oltre 15 anni. L’azienda promuove pesantemente capacità di “AI” e “ML” nella sua piattaforma Luminate, ma i dettagli sono scarsi. Infatti, i pochi artefatti pubblici che possiamo trovare – come progetti open source e brevetti attribuiti al team di data science di Blue Yonder – suggeriscono che utilizza metodi abbastanza tradizionali (ad es. estrazione di feature da serie temporali, modelli ARMA e di regressione lineare) ³⁰. Queste tecniche vanno bene, ma sono approcci di decenni ormai spesso superati da metodi più recenti. Sembra che la tanto proclamata AI di Blue Yonder possa semplicemente essere una regressione e delle euristiche riproposte. Senza case study trasparenti o articoli tecnici, si deve presumere che le affermazioni di Blue Yonder su una “rivoluzionaria previsione AI” siano solo un inganno pubblicitario. Inoltre, l’integrazione di tutti i suoi componenti acquisiti è una sfida in corso – molti clienti segnalano difficoltà nel realizzare la promessa “end-to-end” perché i moduli (domanda, approvvigionamento, realizzazione, ecc.) non si collegano naturalmente senza una personalizzazione significativa. In-memory vs. on-disk? Blue Yonder non pubblicizza un’architettura completamente in-memory come alcuni altri; parti del sistema probabilmente girano su database relazionali standard. Questo potrebbe in realtà rivelarsi un vantaggio in termini di costo, ma significa anche che le prestazioni possono risentirne a meno che i dati non vengano aggregati (ad es. i loro sistemi più vecchi utilizzavano spesso esecuzioni batch di pianificazione). In sintesi, Blue Yonder è un monito: un tempo leader del settore, ora offre una suite ampia ma tecnicamente incoerente. I suoi punti di forza risiedono nell’esperienza di settore e in un ampio set di funzionalità, mentre i suoi punti deboli sono una tecnologia obsoleta ricoperta da una vernice fresca e la mancanza di prove credibili per le sue nuove capacità di “AI”.

(Nota: Esistono anche altri fornitori come Infor (con componenti legacy GT Nexus e Mercia), GAINS Systems (un altro specialista in ottimizzazione dell’inventario), John Galt Solutions (previsione della domanda per il mercato medio), Relex Solutions (previsione retail con un motore in-memory), ecc. Per concentrarci, abbiamo classificato sopra gli esempi più importanti o istruttivi. Gli stessi criteri scettici si applicano a quelli non classificati individualmente: per esempio, Relex utilizza un design in-memory in stile OLAP-cube – ottimo per la velocità, ma garantisce costi hardware elevati per i grandi rivenditori ³¹; Infor è cresciuta tramite acquisizioni che hanno portato a problemi di integrazione simili a SAP/Blue Yonder; GAINS e John Galt offrono una solida funzionalità di base, ma poche tecniche innovative documentate pubblicamente. Qualsiasi fornitore che non condivida apertamente dettagli tecnici o prove concrete verrebbe comunque classificato in basso secondo la metodologia di questo studio.)*

Analisi Tecnica Approfondita

In questa sezione, approfondiamo gli aspetti tecnici specifici dei migliori software di ottimizzazione della supply chain, concentrandoci su quattro aree chiave: Previsione & AI, capacità di automazione, architettura del sistema e integrazione dei moduli. Tutte le analisi si basano su informazioni tecniche pubblicate o prove concrete, evitando esplicitamente qualsiasi linguaggio di marketing.

Capacità di Previsione & AI

La pianificazione moderna della supply chain dipende dall’accuratezza nella previsione della domanda, tuttavia le affermazioni di superiorità previsionale sono dilaganti e spesso infondate. La nostra indagine ha rilevato che le capacità previsionali della maggior parte dei fornitori non superano in modo significativo i metodi statistici standard – nonostante parole d’ordine come “AI” o “machine learning” nel loro marketing.

Prestazioni Dimostrate vs. Hype: Tra tutti i fornitori, Lokad è l’unico con un comprovato record di previsioni a livello mondiale, grazie alla competizione aperta M5. Lokad ha dimostrato la sua abilità nella previsione probabilistica classificandosi al vertice per l’accuratezza a livello SKU ¹. Ciò conferisce credibilità alle affermazioni di Lokad su una migliore accuratezza previsionale. In netto contrasto, nessun altro fornitore ha pubblicato risultati comparabili su un benchmark indipendente. Ad esempio, alcuni fornitori pubblicizzano algoritmi proprietari (uno li chiama “Procast”) affermando un’accuratezza superiore, eppure questi metodi sono stati assenti dalle posizioni di vertice della competizione M5 ³². In pratica, gli approcci accademici open source (come i pacchetti di previsione in R del Prof. Rob Hyndman) sono probabilmente altrettanto buoni o migliori della maggior parte dei motori proprietari chiusi ¹³. Pertanto, ogni affermazione di un fornitore su “accuratezza previsionale migliore del settore” senza prova pubblica va considerata non supportata.
Affermazioni su AI e Machine Learning: Abbiamo applicato uno scetticismo estremo rispetto al clamore su AI/ML. Fornitori come o9 Solutions e Blue Yonder fanno ampio uso di termini come “previsione guidata da AI/ML” nei loro opuscoli. Tuttavia, cercando sostanza, abbiamo trovato ben poco. Nel caso di o9, le loro affermazioni secondo cui il “Enterprise Knowledge Graph” basato su grafi fornisce previsioni migliori sono dubbie e prive di fondamento scientifico ²⁵. Blue Yonder, similmente, promuove l’AI senza fornire dettagli – l’unico scorcio della loro tecnologia proviene da alcuni repository open source che mostrano l’uso di tecniche di serie temporali abbastanza ordinarie (ARMA, regressione lineare, feature engineering) ³⁰. Non ci sono prove di deep learning, metodi probabilistici avanzati o altra AI moderna che giustificherebbe il loro marketing. ToolsGroup ha incorporato concetti di machine learning (parlano di “demand sensing” mediante machine learning), ma ancora nessuno studio peer-reviewed o vittorie in competizioni a convalidarlo ²⁰. Infatti, l’accostamento da parte di ToolsGroup di “previsione probabilistica” con vecchi parametri come il MAPE suggerisce che il loro AI sia più clamore che innovazione ¹⁹. Conclusione: Al di fuori di Lokad (e, in una certa misura, della SAS, che utilizza modelli statistici collaudati), la previsione nella maggior parte dei software per supply chain rimane basata su metodi noti (livellamento esponenziale, regressione, forse qualche ML basato su alberi) e non su un genio AI proprietario. I fornitori che possiedono algoritmi veramente innovativi li dimostrerebbero pubblicamente. La mancanza di una validazione indipendente è significativa.
Approcci Probabilistici vs. Deterministici: Un notevole elemento distintivo tecnico è se un fornitore adotta la previsione probabilistica (che prevede una distribuzione completa degli esiti della domanda) oppure si limita a previsioni ad un singolo punto. Lokad è stato un convinto sostenitore delle distribuzioni di probabilità complete sin dal 2012, e in effetti ottimizza le decisioni (come i livelli di stock) direttamente partendo dalle previsioni probabilistiche. Anche ToolsGroup afferma di produrre previsioni probabilistiche (probabilmente tramite simulazioni Monte Carlo della domanda). Tuttavia, abbiamo riscontrato che molti di coloro che dichiarano “probabilistico” ritornano internamente a metriche e processi deterministici. Ad esempio, il marketing di ToolsGroup sul ridurre il MAPE usando modelli probabilistici è incoerente, poiché il MAPE non può nemmeno essere calcolato su un output di previsione probabilistica ¹⁹. Ciò suggerisce che il loro processo, alla fine, collassa in una previsione puntuale (media o mediana) per la valutazione, minando il beneficio probabilistico. Altri fornitori come SAP, Oracle, Blue Yonder hanno iniziato a menzionare termini probabilistici (SAP IBP ora comprende “ensemble statistici” e intervalli di confidenza), ma le loro interfacce utente e i report spesso si limitano a previsioni univoche con metriche d’errore tradizionali. Adottare una vera previsione probabilistica richiede di ripensare gli indicatori chiave di performance (usando Pinball loss, CRPS o il raggiungimento del livello di servizio anziché il MAPE). Non abbiamo trovato prove che alcun grande fornitore, eccetto Lokad, sia andato così oltre nella pratica. In sintesi, la previsione probabilistica è un’area in cui il marketing è avanti rispetto alla realtà per la maggior parte dei fornitori – possono generare alcune distribuzioni dietro le quinte, ma i pianificatori continuano a guardare ai numeri di previsioni puntuali e ai KPI classici, il che indica una adozione limitata del paradigma.
Metriche di Previsione e Valutazione: Un aspetto importante del rigore tecnico è come il fornitore valuta la qualità delle previsioni. Un segnale d’allarme è la continua dipendenza da metriche come MAPE, WAPE o bias come uniche misure di successo, specialmente se il fornitore sostiene di utilizzare metodi AI o probabilistici. Ciò perché tali metriche incoraggiano previsioni conservative e mediocri e possono essere manipolate (ad esempio, eliminando i picchi e le cadute). Abbiamo osservato che i fornitori con previsioni veramente avanzate tendono a parlare di livelli di servizio o risultati aziendali (ad es. probabilità di stock-out, impatto sui costi) anziché limitarsi al MAPE. Lokad, per esempio, enfatizza la riduzione dei “dollari di errore” e l’allineamento delle previsioni con l’ottimizzazione delle decisioni ³³. Al contrario, ToolsGroup, Blue Yonder e molti altri evidenziano ancora gli errori percentuali nei loro case study, mostrando una mentalità obsoleta. Se la documentazione o la demo di un fornitore presenta pesantemente dashboard MAPE/WAPE, è un segnale che le loro previsioni sono probabilmente tradizionali. Infatti, l’incoerenza di ToolsGroup riguardo al MAPE era già stata osservata ¹⁹. In breve: una previsione veramente all’avanguardia per la supply chain sarebbe evidenziata da metriche probabilistiche e validazione nel mondo reale – attributi per lo più assenti ad eccezione di uno o due casi.

Capacità di Automazione & Workflow

Raggiungere l’ottimizzazione della supply chain non riguarda solo gli algoritmi; conta anche quanto il software riesca a gestire il processo di pianificazione in modo automatizzato e “hands-free”. Abbiamo esaminato le affermazioni e la documentazione di ciascun fornitore per cercare evidenze di automazione, integrazione API e supporto per decisioni autonome.

Lokad: L’automazione è uno degli elementi distintivi di Lokad. L’intera soluzione è costruita attorno a un linguaggio specifico di dominio (Envision) che consente ai pianificatori della supply chain di codificare la loro logica e le loro decisioni in script, che vengono poi eseguiti automaticamente secondo una pianificazione. Lokad documenta chiaramente le sue pipeline di dati e il gestore del workflow che aggiorna i dati e ricalcola le decisioni (previsioni, ordini di rifornimento, ecc.) senza intervento manuale ³⁴ ³⁵. Discutono addirittura di avere setup “altamente automatizzati” per circa 100 supply chain in produzione ³⁵, il che significa che il software preleva dati, elabora previsioni ed emette decisioni (come proposte di ordini di acquisto) in completa autonomia. Inoltre, Lokad fornisce API per il caricamento dei dati e il download dei risultati, e ha ideato il concetto “AI Pilot” per automatizzare le attività amministrative ³⁶. Tutto ciò indica un livello molto elevato di vera automazione – il ruolo dell’utente consiste principalmente nel monitorare e affinare il codice e i parametri, non nel premere manualmente pulsanti per ogni piano. L’approccio di Lokad all’automazione è credibile e tecnicamente dettagliato (hanno persino tenuto lezioni su come passare da decisioni manuali ad automatizzate ³⁷ ³⁸).
Kinaxis: Kinaxis RapidResponse è progettato per un’analisi rapida degli scenari e per la collaborazione piuttosto che per una pianificazione completamente automatizzata. Il concetto di “pianificazione concorrente” riguarda tutti che lavorano sullo stesso set di dati con aggiornamenti in tempo reale, ma solitamente coinvolge ancora pianificatori umani per valutare gli scenari e prendere decisioni. Detto questo, Kinaxis supporta l’automazione in certi modi: può acquisire dati dai sistemi ERP quasi in tempo reale, eseguire continuamente i suoi algoritmi di abbinamento domanda/offerta e inviare avvisi o messaggi di eccezione agli utenti quando le cose escono dai limiti. Espone funzionalità tramite API e dispone di scripting (sotto forma di algoritmi configurabili e macro nel suo ambiente) per utenti avanzati. Tuttavia, Kinaxis si posiziona generalmente come supporto decisionale, non come una scatola nera che rilascia automaticamente gli ordini. Il fornitore non proclama rumorosamente una “supply chain autonoma”; invece, si concentra nel rendere i pianificatori più efficienti. Questa è una posizione onesta. Significa che out-of-the-box, RapidResponse si aspetta ancora la presenza di umani nel processo – il che può essere una limitazione se si cerca un sistema di supply chain “auto-guida”. Tecnicamente, Kinaxis può essere integrato in profondità (ad esempio, spesso si integra con SAP ERP per eseguire piani approvati), ma un’operazione end-to-end non sorvegliata richiederebbe molta configurazione personalizzata. Non abbiamo trovato evidenze che Kinaxis fornisca raccomandazioni decisionali guidate da AI (la loro forza risiede più nella rapida elaborazione degli scenari definiti dagli utenti).
o9 Solutions: o9 promuove pesantemente concetti come un “gemello digitale” dell’organizzazione e un’AI in grado di fare raccomandazioni. Parlano di “Automazione” nel contesto dei loro assistenti digitali – presumibilmente bot che possono fornire approfondimenti o svolgere alcune attività. Tuttavia, in assenza di documentazione tecnica concreta, è difficile capire quanto ci sia di reale. Non siamo riusciti a trovare dettagli specifici come “o9 può rilasciare automaticamente ordini di reintegro tramite API basandosi sui suoi piani” o “o9 utilizza il reinforcement learning per regolare autonomamente i parametri.” La vaghezza della storia sull’automazione di o9 è motivo di preoccupazione: molte discussioni ad alto livello, pochi dettagli. Dato il suo fondamento EKG in-memory, sospettiamo che o9 sia in grado di aggiornare i dati in tempo reale e di effettuare ricalcoli, ma probabilmente fa ancora affidamento sugli utenti per configurare cosa fare con tali informazioni. Senza riferimenti credibili, trattiamo le affermazioni di “autonomia” di o9 come non verificate. È possibile integrare o9 tramite API in sistemi di esecuzione (è un software moderno, quindi l’integrazione API dovrebbe esistere), ma quanto il processo decisionale sia veramente automatizzato dall’AI in o9 resta poco chiaro. Le evidenze suggeriscono che l’automazione attuale di o9 riguarda più l’accelerazione dell’analitica (ad es. scenari what-if istantanei) che l’automatizzazione dei risultati decisionali.
Blue Yonder: Negli ultimi anni, Blue Yonder (soprattutto da quando è stata acquisita da Panasonic) ha spinto il termine “supply chain autonoma”, implicando un sistema che può funzionare con un intervento umano minimo. Dispongono di alcuni componenti, come Luminate Control Tower, che utilizzano l’AI per rilevare interruzioni e possibilmente innescare risposte. Tuttavia, dato il nucleo legacy di Blue Yonder, è probabile che qualsiasi autonomia venga raggiunta sovrapponendo RPA (Robotic Process Automation) o semplici agenti AI su moduli esistenti. Ad esempio, la pianificazione della domanda di Blue Yonder potrebbe produrre una previsione, e un livello “AI” potrebbe regolarla automaticamente basandosi sulle vendite in tempo reale (demand sensing) o inviare un avviso se essa devia. Ma la pianificazione completamente automatizzata (come il rilascio automatico degli ordini, l’aggiustamento automatico delle politiche di inventario) è probabilmente rara nelle soluzioni BY – i clienti di solito hanno ancora pianificatori che verificano e approvano le azioni. La mancanza di una letteratura tecnica dettagliata su come Blue Yonder automatizza le decisioni è significativa. Se avessero un pianificatore veramente autonomo, pubblicherebbero storie di successo o blog tecnici a riguardo. Invece, pubblicano principalmente webinar di marketing. Quindi, deduciamo che Blue Yonder abilita un certo grado di automazione (come job batch, aggiornamenti dei piani, forse integrazione closed-loop con sistemi di esecuzione), ma non è dimostrabilmente all’avanguardia in quest’area. Probabilmente utilizza una pianificazione basata su eccezioni simile a quella dei sistemi più vecchi (solo con una nuova patina AI sul sistema di allerta).
ToolsGroup: Storicamente, ToolsGroup si è fregiato di una “Automazione Potentemente Semplice.” Affermavano che il loro sistema poteva operare in modalità senza supervisione per periodi prolungati, facendo intervenire i pianificatori solo in caso di eccezioni. Infatti, la filosofia di ToolsGroup era di lasciare che il sistema ricalcolasse e riprogrammasse automaticamente quotidianamente, adattandosi ai nuovi dati. A loro credito, molti clienti di ToolsGroup hanno segnalato una riduzione del carico di lavoro dei pianificatori poiché il software si adatta automaticamente agli obiettivi di inventario e raccomanda ordini in modo automatico. ToolsGroup dispone anche di un toolkit di integrazione per trasferire gli ordini approvati ai sistemi ERP. Tuttavia, a causa delle contraddizioni precedentemente notate, abbiamo dei dubbi sull’intelligenza di questa automazione. Potrebbe semplicemente applicare la stessa formula ogni giorno e segnalare quando qualcosa non va (gestione delle eccezioni). ToolsGroup fornisce un’API e supporta esecuzioni pianificate, quindi tecnicamente l’infrastruttura per l’automazione è presente. La questione è la qualità delle decisioni automatizzate. Menzionano molto il “self-tuning” – implicando che il software regola autonomamente i parametri del modello di previsione man mano che arrivano nuovi dati ³⁹. Se ciò fosse vero, si tratterebbe di un’automazione utile (eliminando la necessità di una costante riconfigurazione umana). Senza una valutazione indipendente, diciamo con cautela che ToolsGroup offre una elevata automazione nelle attività di pianificazione di routine, ma la mancanza di trasparenza rende difficile giudicare quanto sia “intelligente” quell’automazione (ad es., impara e migliora davvero o segue solo regole preimpostate?).
Altri Fornitori: La maggior parte degli altri attori supporta capacità di automazione standard: integrazione dei dati tramite API o batch di file, esecuzioni pianificate e alcuni flussi di lavoro basati su eccezioni. Ad esempio, SAP IBP può essere configurato per eseguire automaticamente un job di previsione ogni mese e popolare i risultati della pianificazione, ma solitamente un pianificatore verifica l’output. Anaplan è meno focalizzato sull’automazione – è più una piattaforma di modellazione manuale, sebbene sia possibile utilizzare la sua API per inviare/ricevere dati e forse automatizzare alcuni calcoli. Dassault/Quintiq può essere programmato per eseguire routine di ottimizzazione a intervalli regolari (e il DSL di Quintiq significa che puoi programmare comportamenti automatici personalizzati), ma ancora, è tanto autonomo quanto lo programmino l’implementatore. GAINS, Relex, Netstock e altri fornitori di nicchia pubblicizzano tutti “automazione end to end” nel reintegro – solitamente nel senso che possono generare automaticamente ordini di acquisto o raccomandazioni per il trasferimento in negozio. La differenza chiave risiede in quanta supervisione sia necessaria: un vero sistema di pianificazione autonomo richiederebbe l’intervento umano solo per situazioni atipiche e documenterebbe le sue decisioni con relative motivazioni. Non abbiamo trovato alcun fornitore che raggiunga pienamente questo ideale finora. O richiedono che gli umani apportino modifiche e approvino (nella maggior parte dei casi), oppure automatizzano solo le decisioni più semplici e lasciano il resto.

Riepilogo per l’Automazione: Solo pochi fornitori (in particolare Lokad) descrivono pubblicamente in dettaglio un framework di automazione che consente cicli di pianificazione non sorvegliati e guidati da API. Altri dispongono dei mezzi tecnici per l’automazione ma si affidano ancora agli esseri umani per completare il ciclo. Notiamo anche che alcuni fornitori hanno spostato l’attenzione, nei decenni passati, dall’automazione completa alla “gestione delle eccezioni” – che è essenzialmente un approccio semi-automatizzato in cui il software fa ciò che può e segnala il resto agli umani ³⁸. Questo approccio, pur essendo pratico, può essere una stampella per software che non è abbastanza robusto da poter essere completamente affidato. Il nostro approccio scettico è: se un fornitore non può spiegare come automatizza le decisioni (quali algoritmi, quali trigger, quali chiamate API), allora la sua “automazione” è probabilmente solo un discorso di marketing.

Architettura di Sistema & Scalabilità

La struttura interna – in particolare l’uso del computing in-memory rispetto a quello su disco, e le scelte progettuali complessive – ha enormi implicazioni per la scalabilità, il costo e le prestazioni del software per la supply chain. Abbiamo esaminato lo stack tecnologico di base di ciascun fornitore con un focus su come gestiscono grandi quantità di dati e calcoli complessi.

Computing In-Memory – Pro e Contro: Diversi dei fornitori leader si basano su un’architettura in-memory, il che significa che il software carica la maggior parte o tutti i dati rilevanti nella RAM per un accesso rapido durante i calcoli. Questo include Kinaxis, Anaplan, o9, SAP HANA (IBP), Relex e possibilmente Quintiq (per la risoluzione di scenari). Il vantaggio è la velocità: l’accesso alla RAM è di ordini di magnitudine più rapido rispetto al disco. Per esempio, il motore di Kinaxis carica tutti i dati in memoria per permettere il ricalcolo istantaneo degli scenari e operazioni algoritmiche dirette sul dataset ⁹. SAP HANA è stato costruito sul presupposto che le analisi su dati live debbano avvenire in-memory per ottenere risultati in tempo reale ⁴⁰ ⁴¹. Tuttavia, esiste un problema fondamentale con un design completamente in-memory: costo e scalabilità. La memoria (RAM) è estremamente costosa rispetto allo storage. 1 TB di RAM può costare 100 volte di più rispetto a 1 TB di disco ¹⁰. Inoltre, la dimensione della memoria sui server è fisicamente limitata (i sistemi tipici potrebbero avere al massimo 0,5–2 TB di RAM, mentre dataset di più terabyte o petabyte sono comuni nelle grandi supply chain). Negli ultimi anni, le previste drastiche riduzioni del costo della RAM non si sono materializzate – i prezzi e le capacità della RAM sono rimasti piuttosto stagnanti ⁴². Ciò significa che qualsiasi sistema che richiede tutti i dati in memoria dovrà affrontare costi infrastrutturali alle stelle con la crescita dei dati, o incontrerà un limite invalicabile in cui i dati semplicemente non possono essere contenuti. Etichettiamo il forte affidamento su un design in-memory come un errore architetturale per le grandi supply chain, a meno che non venga mitigato.
Memoria vs. Disco: Pratiche Moderne: È interessante notare che il mondo tecnologico in generale ha compreso che le soluzioni puramente in-memory non sono il futuro per i big data. Le architetture più recenti utilizzano un approccio a livelli – mantenere i dati “caldi” in memoria e quelli “freddi” su SSD, ecc. ⁴³ ⁴⁴. Alcuni software per la supply chain hanno iniziato ad adottare questo approccio. Ad esempio, Lokad utilizza esplicitamente tecniche di “spill to disk” nella sua infrastruttura cloud. Il loro CTO ha descritto come gestiscono un dataset retail di 10 miliardi di righe utilizzando circa 37 GB di RAM più un NVMe SSD veloce per lo spill-over ⁴⁵ ³. Raggiungono prestazioni vicine a quelle della RAM mappando i file in memoria e mantenendo in RAM solo i dati più critici, con il software che effettua in modo intelligente lo swapping quando necessario ⁴⁶ ⁴⁷. Questo approccio consente enormi risparmi sui costi – ad esempio, con il costo di 18 GB di RAM di fascia alta, si può acquistare 1 TB di NVMe SSD ³, dunque è 50 volte più economico per byte, pur essendo solo circa 6 volte più lento nell’accesso grezzo, un compromesso spesso vantaggioso. Nessuno dei fornitori incentrati esclusivamente sull’in-memory (Kinaxis, SAP, o9, ecc.) ha descritto pubblicamente una gestione adattiva della memoria come questa, suggerendo che le loro soluzioni potrebbero semplicemente richiedere molta RAM o necessitare di aggregazione dei dati per farli entrare. Anaplan è noto per avere difficoltà con i limiti di dimensione dei modelli – alcuni clienti si scontrano con i limiti di memoria del suo Hyperblock e devono dividere i modelli. Kinaxis probabilmente necessita anch’esso di più server interconnessi per gestire dati molto grandi (hanno un concetto di distribuzione dei dati, ma all’interno di ogni nodo questi restano residenti in memoria). SAP HANA può scaricare su disco (dispone di nodi di estensione), ma le prestazioni ne risentono. In sintesi: un design rigido in-memory è un segnale d’allarme per la scalabilità. Può funzionare brillantemente per dati piccoli o medi, ma man mano che la supply chain cresce (pensate a una pianificazione dettagliata a livello SKU-negozio-giorno per un rivenditore globale), i costi e i rischi in termini di prestazioni aumentano notevolmente. L’ingegneria moderna favorisce un mix di uso della memoria e del disco per bilanciare velocità e costo, e i fornitori che non lo fanno sono in ritardo.
Tech Stack e Complessità: Oltre alla memoria, un altro elemento architetturale è l’intero tech stack – monolitico vs. microservizi, uso di linguaggi di programmazione moderni, ecc. Senza approfondire troppo, abbiamo osservato che i fornitori più vecchi (SAP APO/IBP, Blue Yonder) operano su stack legacy più monolitici, mentre quelli più recenti (o9, Anaplan) hanno costruito la loro soluzione da zero con tecnologie più moderne. Ad esempio, il nucleo di SAP IBP include ancora motori degli anni 2000 (come l’ottimizzatore di APO) ora avvolti in uno strato HANA/cloud. Ciò introduce complessità e potenziale inefficienza (molteplici livelli di astrazione). Blue Yonder possiede, in maniera simile, molto codice legacy dai tempi di i2 e JDA. Kinaxis è in qualche modo unico – è vecchio (iniziato negli anni ‘90) ma si è continuamente rifattorizzato in un proprio kernel di database; tuttavia, è uno stack proprietario che solo loro utilizzano. Anaplan ha costruito un motore di calcolo molto efficiente (in Java) per il suo specifico caso d’uso (Hyperblock), ed è abbastanza ottimizzato per tale scopo – ma non è open, e bisogna convivere con i suoi vincoli (ad es., nessuna interrogazione SQL, complessità algoritmica limitata poiché si basa più su calcoli a celle). La piattaforma di o9 include un mix di tecnologie (probabilmente un database NoSQL/grafico, forse Spark o simili per qualche ML, ecc.), rendendola complessa ma teoricamente flessibile.
Hardware e Cloud: Una tendenza notevole è il design cloud-native. Molti fornitori ora offrono il loro software come SaaS o almeno ospitato nel cloud, ma non tutti sono veramente cloud-native. Ad esempio, Anaplan e o9 sono SaaS multi-tenant (costruiti per il cloud sin dall’inizio). Lokad è nativamente cloud (funziona su Microsoft Azure e alloca risorse in modo dinamico). SAP IBP è ospitato nel cloud, ma essenzialmente ogni cliente è un’istanza isolata su HANA (non multi-tenant nel senso stretto). ToolsGroup, Blue Yonder offrono soluzioni SaaS, ma spesso si tratta semplicemente del loro software on-premise gestito da loro nel cloud. Perché ciò è rilevante in termini tecnici? Le architetture cloud-native sono tipicamente più elastiche – possono attivare capacità di calcolo quando necessario (per una grande esecuzione di pianificazione) e disattivarle in seguito, controllando così i costi. I sistemi non cloud spesso richiedono l’acquisto per la capacità di picco, anche se utilizzati solo occasionalmente. Inoltre, i sistemi cloud-native potrebbero integrarsi meglio con altri servizi cloud (ad esempio, collegandosi a un servizio ML cloud o a un data lake). Dai nostri riscontri, le soluzioni più cloud-native e progettate per la scalabilità sembrano essere Lokad e o9 (e forse Anaplan), mentre gli altri stanno recuperando terreno. Tuttavia, il solo fatto di essere cloud-native non equivale a una buona architettura – o9 è cloud-native, ma abbiamo messo in dubbio il suo approccio fortemente in-memory; il fatto che SAP IBP sia sul cloud non elimina i suoi problemi di complessità.
Concorrenza e necessità in tempo reale: Una considerazione architettonica è come il sistema gestisce utenti concorrenti e aggiornamenti in tempo reale. Kinaxis eccelle in questo: è stato realizzato per permettere a più pianificatori di effettuare la pianificazione degli scenari simultaneamente sullo stesso dataset. Ciò richiede una gestione attenta del versionamento dei dati e una logica di blocco – che Kinaxis ha ottenuto tramite il suo meccanismo di branching ⁸. La maggior parte degli altri strumenti seguiva tradizionalmente un paradigma batch (pianificare, pubblicare, poi collaborare separatamente). Ora, molti stanno aggiungendo funzionalità di pianificazione concorrente. Anaplan consente a più persone di lavorare contemporaneamente su parti differenti del modello (poiché è sostanzialmente basato su celle come Google Sheets). SAP IBP ha introdotto un’interfaccia utente “simile a Microsoft Excel” che può aggiornare i dati dal server on demand, ma la vera concorrenza (più utenti che modificano lo stesso piano simultaneamente) è limitata. o9 probabilmente supporta un certo livello di concorrenza grazie al suo knowledge graph (più utenti possono modificare nodi differenti). Nella valutazione del merito tecnico, un sistema che può operare veramente in tempo reale con molti utenti indica un’architettura robusta. Kinaxis e Anaplan ottengono punti in questo. Non è che gli altri non possano farlo, ma spesso le loro architetture più vecchie lo rendono difficile – con il risultato di prestazioni lente o di processi costretti a essere sequenziali.

Riepilogo per l’Architettura: Abbiamo identificato un pattern: i design incentrati sulla memoria (Kinaxis, Anaplan, o9, Relex, SAP HANA) offrono velocità, ma a scapito della scalabilità e dei costi, mentre i design ibridi (lo spill-to-disk di Lokad, forse strumenti che usano database moderni) sono più scalabili ed efficienti in termini di costi. Un chiaro segnale d’allarme è rappresentato da qualsiasi fornitore che insiste che tutto debba essere in RAM per funzionare – un approccio ora considerato obsoleto, viste le recenti innovazioni nella velocità degli SSD e nel computing distribuito ⁴³ ⁴⁴. Evidenziamo inoltre che un’architettura di fornitore nata da molteplici acquisizioni (come SAP, Blue Yonder) tende a essere eccessivamente complessa e richiede molti aggiustamenti. Le architetture più semplici, sviluppate internamente (il codebase unico di Kinaxis, il motore unico di Anaplan, il motore unico di Lokad) tendono a essere più coerenti e quindi più facili da mantenere tecnicamente. Nella valutazione di un software per la supply chain, ci si dovrebbe chiedere: Il fornitore ha pubblicato qualcosa su come è costruito il suo software (microservizi? database personalizzato? uso di librerie ML? ecc.). L’assenza di una discussione ingegneristica potrebbe significare che l’architettura è semplicemente una scatola nera – spesso indicativa di un sistema legacy o della mancanza di fiducia nella sua unicità.

Integrazione e Coerenza dei Moduli (Impatto delle Fusioni e Acquisizioni)

La pianificazione della supply chain tipicamente copre diversi ambiti (previsione della domanda, ottimizzazione dell’inventario, pianificazione della produzione, ecc.). Alcuni fornitori offrono una suite integrata costruita organicamente, mentre altri sono cresciuti tramite acquisizioni, aggiungendo nuovi moduli. Abbiamo esaminato come il set di soluzioni di ciascun fornitore sia integrato e quali segnali d’allarme emergano dalla loro strategia di crescita.

Blue Yonder (JDA) è l’esempio paradigmatico di crescita tramite acquisizione. Come già notato, è una “collezione casuale” di prodotti di epoche differenti ²⁹. JDA ha acquisito i2 (che di per sé conteneva molteplici moduli), poi ha acquisito Manugistics, successivamente RedPrairie (per la gestione dei magazzini) e infine la startup Blue Yonder per l’AI. Ogni componente aveva il proprio schema di database e la propria logica. Il risultato: ancora oggi, la pianificazione della domanda, la pianificazione dell’offerta e l’ottimizzazione dell’inventario di Blue Yonder potrebbero non condividere un modello di dati unificato – l’integrazione si basa sulle interfacce. Questo è un segnale d’allarme perché significa che implementare l’intera suite equivale sostanzialmente a integrare diversi pacchetti software distinti. Quando i prodotti di un fornitore non sono veramente unificati, i clienti si trovano ad affrontare problemi come ritardi nella sincronizzazione dei dati, interfacce utente incoerenti e funzionalità duplicate. Nel caso di Blue Yonder: alcuni moduli si sovrappongono nettamente (dopo le acquisizioni, potresti avere due modi per fare la pianificazione dell’inventario – uno derivante dal legacy di Manugistics e uno da i2). L’azienda ha dedicato sforzi per razionalizzare questa situazione, ma il problema non è stato completamente risolto. In termini tecnici, il software aziendale non si “miscela” magicamente come fluidi quando le aziende si fondono ²⁹ – servono anni di re-ingegnerizzazione. Non abbiamo visto prove che Blue Yonder abbia completato tale re-ingegnerizzazione. Quindi, la mancanza di coerenza rappresenta una grave debolezza tecnica.
SAP IBP ha combinato in modo simile componenti acquisite: l’acquisto da parte di SAP di SAF, SmartOps e altri ha portato strumenti separati che SAP ha poi integrato sotto l’ombrello IBP ²⁷. Gli utenti hanno notato che IBP presenta moduli differenti che sembrano app separate (per esempio, IBP per la Domanda rispetto a IBP per l’Inventario). La logica di ottimizzazione del safety stock in IBP proviene probabilmente dall’acquisizione di SmartOps, mentre il demand sensing potrebbe derivare da SAF o da sviluppi interni. L’integrazione è migliore rispetto a quella di Blue Yonder (SAP ha almeno riscritto l’interfaccia utente e ha posizionato tutto sul database HANA), ma comunque, sotto il cofano, IBP non è un unico codebase. SAP avverte esplicitamente che l’implementazione di IBP di solito richiede diversi anni e integratori esperti per far lavorare insieme in modo ottimale tutti i moduli ²⁸. Questa affermazione è di per sé un segnale d’allarme – implica discrepanze potenziali e complessità.
Infor (pur non rientrando nella top 10 sopra menzionata) ha anche fuso vari sistemi di pianificazione (aveva acquisito la pianificazione della supply chain di Mercia e GT Nexus, ecc.). Il risultato non è mai stato una piattaforma di pianificazione veramente unificata; Infor tende a focalizzarsi sui sistemi di esecuzione. Quindi, è un altro esempio in cui l’acquisizione non ha prodotto un eccellente prodotto integrato per la pianificazione.
Dassault (Quintiq): In questo caso, l’acquisizione (da parte di Dassault) non ha comportato la fusione di Quintiq con un altro strumento di pianificazione – Dassault ha più o meno lasciato Quintiq come offerta autonoma, focalizzata sull’ottimizzazione della produzione e della programmazione. Di conseguenza, la coerenza interna di Quintiq è buona (era sviluppato internamente e lo rimane tale), ma lo svantaggio è che non copre tutte le aree (ad es., non ha previsioni della domanda native, come notato ¹⁶). Il portafoglio di Dassault include altri prodotti (come Apriso per MES, ecc.), ma non sono integrati in modo approfondito con Quintiq. Quindi, in termini di integrazione, Quintiq è autoconsistente ma funzionalmente limitato. Dal punto di vista dell’utente, potrebbe essere necessario integrarlo con un altro strumento di previsione, comportando ulteriore lavoro sul lato cliente.
Kinaxis è cresciuta principalmente in modo organico – ha acquisito una piccola azienda di AI, Rubikloud, nel 2020 (per l’AI nel retail) e uno strumento di design per la supply chain (Castle Logistics) nel 2022, ma questi sono relativamente recenti e resta da vedere come verranno integrati. Storicamente, RapidResponse era un unico prodotto che gestiva vari aspetti della pianificazione tramite configurazione. Questa coerenza è un punto a favore: tutti i moduli (domanda, offerta, inventario) condividono un unico database e un’interfaccia utente in Kinaxis. Allo stesso modo, Anaplan ha sviluppato diverse “app” di pianificazione su un’unica piattaforma – le previsioni per vendite, finanza e supply chain risiedono tutte nello stesso ambiente Hyperblock, che è tecnicamente molto coerente (solo template di modelli differenti). o9 Solutions è inoltre una piattaforma unica sviluppata organicamente che copre molti ambiti (non è cresciuta acquisendo altri fornitori di pianificazione, almeno non quelli principali). Quindi, questi tre – Kinaxis, Anaplan, o9 – possiedono un vantaggio architettonico in termini di unità. La cautela nei loro confronti non riguarda l’integrazione di moduli disparati, ma se la loro unica piattaforma sia in grado di gestire in modo approfondito ciascun ambito.
ToolsGroup & Slimstock: Questi fornitori si sono concentrati sul loro settore di nicchia (pianificazione della domanda e dell’inventario). Non hanno davvero acquisito altre aziende; piuttosto, collaborano o si integrano con sistemi di esecuzione secondo necessità. Ciò significa che il loro software è internamente coerente (un unico codebase), il che è positivo, ma se un cliente necessita di capacità più ampie (come la programmazione della produzione), dovrà utilizzare un altro prodotto e integrarlo autonomamente. Negli ultimi anni, ToolsGroup ha iniziato ad aggiungere funzionalità S&OP e ha persino acquisito una startup di AI (Eramos nel 2018) per il machine learning, ma anche in questo caso sono stati integrati nel prodotto principale anziché venduti separatamente. Quindi, l’integrazione non rappresenta un grande problema per ToolsGroup o Slimstock – la questione è se il loro design a focus singolo copra un ambito sufficiente per le esigenze dell’utente.

Riepilogo per l’Integrazione: Da un punto di vista scettico, numerose acquisizioni importanti nella storia di un fornitore sono un segno d’allarme. Spesso portano a un prodotto che, pur cercando di fare tutto, non eccelle in nulla e presenta una complessità nascosta. Blue Yonder e SAP ne sono un esempio – la loro complessità tecnica deriva in parte dal tentativo di incollare insieme molte componenti ereditate. Al contrario, i fornitori con una piattaforma unificata (sviluppata organicamente) evitano questi problemi, anche se devono comunque dimostrare che una singola piattaforma può fare tutto bene. Nella valutazione del software, ci si dovrebbe chiedere l’origine di ciascun modulo: se il modulo di pianificazione della domanda e quello di pianificazione dell’offerta provengono da aziende originali differenti, bisogna verificare come condividono i dati e se l’integrazione è fluida o avviene tramite interfacce. La storia ha dimostrato che, a meno che la tecnologia acquisita non sia stata riscritta da zero in un’architettura unificata (cosa rara per via dei costi e del tempo), il risultato è solitamente un sistema Frankenstein. La nostra ricerca lo conferma – i fornitori con i punteggi più alti in eleganza tecnica (Lokad, Kinaxis, Anaplan) hanno costruito le loro soluzioni in modo olistico, mentre quelli con i punteggi più bassi (Blue Yonder, Infor) hanno accumulato tecnologie disparate senza unirle completamente.

Debolezze Critiche e Segnali d’Allarme

Nel nostro rigoroso esame, abbiamo identificato diverse debolezze ricorrenti e segnali d’allarme di cui gli utenti potenziali dovrebbero essere consapevoli. Di seguito, un riepilogo delle questioni chiave, con esempi di fornitori specifici per illustrare ogni punto:

Affermazioni non supportate su “AI/ML”: Siate estremamente scettici nei confronti di qualsiasi fornitore che proclama un’AI o un machine learning superiore senza prove tecniche solide. Ad esempio, Blue Yonder pubblicizza ampiamente l’AI ma fornisce solo affermazioni vaghe senza sostanza ³⁰ – quel poco che riusciamo a vedere dei loro metodi indica che fanno affidamento su tecniche più vecchie, non su un’AI all’avanguardia. Allo stesso modo, o9 Solutions promuove la sua AI e intelligenza basata su grafi, eppure l’analisi del loro codice e dei materiali pubblici mostra “tanta retorica sull’AI” con analisi veramente ordinarie ²⁶. Se un fornitore non riesce a presentare studi peer-reviewed, brevetti, competizioni o documenti tecnici dettagliati a sostegno delle sue affermazioni sull’AI, assumete che si tratti soltanto di retorica di marketing.
Nessun benchmarking competitivo (affermazioni di superiorità nelle previsioni): Molti fornitori sostengono “un’accuratezza previsionale best-in-class” ma nessuno, a parte Lokad, l’ha dimostrata in competizioni aperte o pubblicazioni. Trattiamo tali affermazioni come fittizie a meno che non siano validate. Ad esempio, l’algoritmo proprietario di un fornitore, vantato come “più accurato degli altri”, è assente dalle posizioni di vertice della competizione M5 ³², il che suggerisce fortemente che l’affermazione non abbia fondamento. Infatti, nessun tradizionale fornitore di software per la supply chain (eccetto Lokad) è apparso nella top 100 di quel concorso globale di previsione. Questo è un grave segnale d’allarme: implica che questi fornitori o non hanno partecipato (forse per evitare imbarazzo pubblico) oppure hanno partecipato ottenendo risultati scadenti. Consiglio pratico: Richiedete di vedere risultati oggettivi di accuratezza (per esempio, come ha performato il loro strumento su un benchmark standard come il dataset M5 o M4) – se non riescono a fornirli, non lasciatevi abbindolare dal clamore.
Eccesso dell’architettura in-memory: I fornitori che spingono per un design tutto in-memory dovrebbero essere interrogati sulla scalabilità e sui costi. Il computing in-memory offre velocità, ma la RAM è ~100 volte più costosa per GB rispetto al disco ¹⁰ e il suo rapporto prezzo/performance è stagnante da anni ⁴². Questo rende le soluzioni puramente in-memory non scalabili e costose per grandi volumi di dati. SAP IBP (HANA) e o9 sono esempi: garantiscono alte prestazioni solo se vengono caricati enormi dataset in memoria, il che garantisce bollette hardware (o cloud) elevate ²⁴ ³¹. È significativo che il design dei sistemi moderni si stia allontanando da questo approccio – come osserva un esperto, l’entusiasmo iniziale di mettere tutto in RAM ha incontrato limiti pratici, e i database stanno “ritrovando il loro amore per il disco” per gestire in modo efficiente i dati freddi ⁴³ ⁴⁴. Se un fornitore è ancora ancorato a una mentalità esclusivamente in-memory, consideratelo un segnale d’allarme architettonico. I fornitori più scalabili parleranno di storage a livelli, elasticità del cloud o strategie simili per gestire dati su larga scala senza richiedere RAM infinita.
Black-Box da M&A (Disfunzione dell’Integrazione): Se la suite di prodotti di un fornitore è il risultato di numerose acquisizioni, fate attenzione alle lacune nell’integrazione e alle funzionalità sovrapposte. Come abbiamo visto, la suite di Blue Yonder è un miscuglio casuale di prodotti datati a seguito di una lunga serie di fusioni ²⁹, e i moduli di SAP IBP provengono da differenti aziende acquisite ²⁷, con il risultato di una complessità e di una “collezione” di strumenti anziché di un insieme omogeneo. Il software aziendale non si “miscela” facilmente tramite M&A ²⁹ – a meno che il fornitore non abbia effettuato una completa re-ingegnerizzazione (cosa rara e dispendiosa in termini di tempo), il cliente spesso finisce per dover agire da integratore tra i moduli. Ciò può comportare esperienze utente incoerenti, inserimento dati duplicato e interfacce fragili. Segnale d’allarme: L’implementazione da parte del fornitore richiede un vero e proprio battaglione di consulenti per un anno o più per far comunicare tra loro i moduli – come ammesso anche nel caso di SAP. Meglio preferire fornitori con una piattaforma unificata o con una minima sovrapposizione dei componenti acquisiti.
Metriche Contraddittorie e Buzzword: Un segnale sottile ma rivelatore è quando la narrazione tecnica di un fornitore contiene contraddizioni interne o pratiche obsolete mascherate da nuova terminologia. Un esempio lampante è stato ToolsGroup che pubblicizzava previsioni probabilistiche mentre contemporaneamente faceva riferimento a miglioramenti del MAPE ¹⁹ – un segno che stanno semplicemente cospargendo vecchie pratiche con nuova terminologia (dato che usare il MAPE per valutare previsioni probabilistiche è concettualmente errato). Un altro esempio è quello dei fornitori che sostengono di utilizzare “advanced AI” ma poi misurano il successo con vecchie metriche come il MAPE o livelli di servizio tradizionali – ciò indica che non hanno veramente adottato il nuovo paradigma. Allo stesso modo, fate attenzione alle metodologie di safety stock: un fornitore potrebbe sostenere di ottimizzare l’inventario con l’AI, ma se approfondite e scoprite che calcolano ancora lo safety stock con una formula degli anni ‘80 (ad es. l’assunzione della distribuzione normale con un fattore di sicurezza statico), si tratta di una contraddizione. Abbiamo effettivamente riscontrato casi in cui i fornitori parlano di inventario “probabilistico” o “ottimale”, eppure la loro documentazione rivela calcoli standard per lo safety stock e l’uso di metriche obsolete come il fill rate. Conclusione: Le incongruenze tra ciò che promuovono e ciò che misurano/consegnano sono un segnale d’allarme. Se un fornitore si vanta di essere moderno e guidato dall’AI, eppure utilizza gli stessi KPI e metodi di decenni fa, la sua innovazione è probabilmente superficiale.
Algoritmi e Pratiche Obsoleti: La teoria della supply chain si è evoluta (ad es. dai modelli deterministici a quelli stocastici, dall’ottimizzazione a singolo echelone a quella multi-echelon), ma alcuni software non hanno tenuto il passo. Fare affidamento su pratiche vecchie di decenni è una debolezza, soprattutto se i fornitori fingono il contrario. Per esempio, uno strumento che utilizza ancora principalmente la logica safety stock + punto di riordino con tempi di consegna fissi per l’inventario è indietro se non tiene conto dinamicamente della variabilità della domanda. Abbiamo notato che Slimstock si concentra esplicitamente su formule tradizionali (safety stock, EOQ) ²¹ – sono trasparenti in merito, il che va bene per una soluzione di base, ma chiaramente non all’avanguardia. Se un fornitore presumibilmente avanzato non è trasparente, potrebbe fare la stessa cosa senza ammetterlo. Un altro esempio: gli snippet open-source di Blue Yonder indicavano modelli ARMA ⁴⁸, che sono tecniche di previsione degli anni ‘70, anche se la loro presentazione commerciale parla di AI. Infor, Oracle, John Galt e altri di fascia inferiore spesso si affidano a metodi di serie temporali ed euristiche che esistono da sempre (come la smussatura esponenziale di Winters, semplici solutori di ottimizzazione) – funzionano, ma non hanno nulla di moderno. Il segnale d’allarme non sta nell’utilizzo di metodi vecchi in sé (i metodi vecchi possono ancora essere i migliori in alcuni casi), bensì nel usarli mentre si pretende di essere innovativi, o nell’impiegarli in esclusiva quando esistono metodi migliori per il problema. Indagate sempre su quali algoritmi vengono effettivamente utilizzati (ad es., “La vostra ottimizzazione dell’inventario considera l’intera distribuzione della domanda o solo un singolo fattore di servizio? Utilizzate l’ottimizzazione multi-echelon o solo calcoli a nodo singolo?”). Risposte evasive o vaghe indicano che la metodologia potrebbe essere obsoleta.
Mancanza di Trasparenza Tecnica: Infine, un segnale meta d’allarme: se un fornitore non fornisce nessuna documentazione tecnica – né white paper, né architettura di riferimento, né spiegazioni degli algoritmi – questo di per sé è un segnale d’allarme. Nella nostra ricerca, i fornitori che hanno ottenuto buoni punteggi tecnici (Lokad, Kinaxis, SAS, ecc.) hanno tutti almeno un po’ di contenuto tecnico disponibile (sia esso blog, articoli accademici o note tecniche). I fornitori che hanno ottenuto punteggi scarsi spesso non offrono altro oltre a brochure di marketing. Per esempio, provate a cercare un white paper tecnico dettagliato da o9 o Blue Yonder – è quasi impossibile, ottenete principalmente brochure lucide. Lokad, al contrario, ha pubblicato uno studio di mercato dettagliato di 18 pagine (che abbiamo citato abbondantemente) confrontando gli approcci dei fornitori ⁴⁹ ²⁹ ²⁵, oltre a video su come funzionano i loro algoritmi. Quando un fornitore è riservato su come funziona la sua soluzione, ci si deve chiedere se sia perché in realtà non è nulla di speciale. La trasparenza si correla con la credibilità. Un fornitore che si nasconde dietro buzzword e non rivela i propri metodi probabilmente utilizza “tecnologia ordinaria con un extra di vernice.”

In conclusione, applicare una lente altamente scettica, con priorità all’ingegneria rivela che molti software di ottimizzazione della supply chain “leader” sono ricchi di promesse e privi di innovazione verificabile. Tagliando attraverso il palliativo del marketing, ci siamo concentrati su ciò che è tangibile: strutture dati, algoritmi, prestazioni e prova dell’efficacia. Le soluzioni migliori si sono distinte per aver offerto sostanza tecnica – accuratezza dimostrata nelle previsioni, scelte architetturali chiare e documentazione sincera – mentre quelle più deboli si sono rivelate attraverso contraddizioni, vaghezza e basi obsolete. Questo studio serve da promemoria per ogni operatore della supply chain: non credete ciecamente alle affermazioni dei fornitori. Richiedete prove, guardate sotto il cofano, e ricordate che nella supply chain, come in tutta l’IT, i veri avanzamenti allo stato dell’arte sono solitamente supportati da scienza aperta e ingegneria solida – non solo da altisonanti affermazioni di marketing.