Software di ottimizzazione della supply chain, febbraio 2025

Di Léon Levinas-Ménard

Ultima modifica: 2 febbraio 2025

Classifica dei fornitori e riassunto (Basato sulla rigore tecnico)

Lokad - Top Credibilità Tecnica. Lokad si distingue per la sua trasparenza e profondità tecnica. Ha introdotto la previsione probabilistica e ha dimostrato i suoi metodi in competizioni aperte (classificandosi al primo posto a livello di SKU e al sesto posto su un totale di 909 team nel contest di precisione delle previsioni M5 ¹ - l’unico team guidato da un fornitore nei primi posti). Lokad pubblica approfondimenti dettagliati sulla sua architettura (ad esempio un linguaggio specifico del dominio chiamato Envision, automazione basata su cloud) e sottolinea le decisioni ottimizzate finanziariamente rispetto a metriche semplicistiche. Il suo focus su una matematica rigorosa (previsioni quantili, ottimizzazione stocastica) e flussi di lavoro completamente scriptabili e automatizzati (tramite API e codifica) dimostra un design orientato all’ingegneria. Non vengono fatti grandi claim su AI/ML senza supporto - invece, Lokad fornisce white paper tecnici e persino strumenti open source per scalare i dati oltre i limiti della RAM ² ³. Questo livello di apertura e prestazioni dimostrate mette Lokad al top.
Anaplan - Piattaforma “Excel 2.0”. Anaplan è essenzialmente la versione SaaS enterprise di un foglio di calcolo, alimentata dal suo motore proprietario Hyperblock in memoria ⁴. 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 basato su cloud. Anaplan non è un ottimizzatore della supply chain specializzato di per sé (previsione e ottimizzazione algoritmica sono “cittadini di seconda classe” su questa piattaforma ⁵), ma la sua forza risiede nella sua solida architettura per la modellazione e la pianificazione degli scenari. Non vende alcuna AI mistica; invece offre un sandbox affidabile e ad alte prestazioni per la costruzione di logiche di pianificazione personalizzate. In breve, è un potente strumento generale di pianificazione con un approccio onesto - nessuna pretesa esagerata sulla magia della previsione, solo un sistema di fogli di calcolo ben progettato e scalabile. Questa proposta tecnica diretta guadagna ad Anaplan un alto grado di credibilità.
Kinaxis (RapidResponse) - Motore di simulazione in memoria. Kinaxis è noto per il suo motore di concorrenza unico che consente di ricalcolare i piani di approvvigionamento in tempo reale in un’azienda. Tecnicamente, Kinaxis ha costruito il proprio motore di database da zero per supportare questo ⁶ ⁷. Il risultato è una piattaforma ottimizzata per simulazioni “what-if” veloci: gli utenti possono creare scenari (come Git per i dati) e ottenere un feedback istantaneo sull’impatto dei cambiamenti ⁸. Il sistema mantiene tutti i dati della supply chain in memoria per la velocità, con gli algoritmi che hanno accesso diretto alla memoria per un throughput massimo ⁹. Questo design consente una vera pianificazione concorrente (ad esempio, piani di vendita, produzione e inventario aggiornati in tempo reale insieme). Da un punto di vista ingegneristico, costruire un archivio dati personalizzato in memoria e versionato è un’impresa impressionante che offre agilità. Il compromesso, tuttavia, è la elevata richiesta di hardware - un approccio completamente in memoria significa che scalare a dimensioni di dati massive può essere costoso (poiché i requisiti di RAM crescono) ¹⁰. Nel complesso, Kinaxis mostra un rigoroso rigore tecnico nell’architettura e nelle prestazioni, evitando pretese alla moda su AI. Eccelle nella pianificazione dell’approvvigionamento e nelle simulazioni S&OP, anche se fornisce meno funzionalità di previsione ML pronte all’uso rispetto ad alcuni concorrenti.
SAS - Potenza statistica. SAS è una società veterana di software di analisi (fondata nel 1976) e porta un motore di modellazione statistica formidabile ai problemi della supply chain. Il suo prodotto principale include un linguaggio specifico del dominio per le statistiche (il linguaggio SAS) risalente agli anni ‘70 ¹¹ - probabilmente la piattaforma originale di data science. La forza di SAS risiede nella profondità dei suoi algoritmi: una vasta libreria di modelli di previsione delle serie temporali, routine di ottimizzazione e tecniche di machine learning costruite nel corso di decenni. Impiega alcuni degli ingegneri e statistici più talentuosi del settore ¹¹, e ha introdotto previsioni avanzate molto tempo prima che “AI” diventasse un termine di moda. Nei contesti della supply chain, SAS viene spesso utilizzato per la previsione della domanda e l’analisi dell’inventario. Tecnicamente, è robusto e comprovato - ma anche pesante. Gli strumenti possono sembrare arcaici (il mondo si è in gran parte spostato verso linguaggi open-source come Python/R, e infatti i notebook Jupyter sono ora un’alternativa aperta superiore ¹²). SAS non rivendica rumorosamente un’intelligenza artificiale magica; si affida alla sua reputazione e alla sua tecnologia solida. Per le organizzazioni con l’esperienza necessaria per sfruttarlo, SAS offre una seria potenza analitica basata su algoritmi reali (ARIMA, ETS, ecc.) piuttosto che sull’hype. Il suo principale svantaggio è che è una piattaforma di analisi generale - estremamente potente sotto il cofano, ma richiede utenti esperti per essere applicata alla supply chain, e non è stata specificamente valutata in competizioni di previsione recenti (strumenti open-source spesso la rivalizzano ¹³).
Dassault Systèmes (Quintiq) - Specialista dell’ottimizzazione. Quintiq (acquisita da Dassault Systèmes nel 2014) è una piattaforma focalizzata sull’ottimizzazione e la pianificazione della supply chain complessa. Presenta un linguaggio specifico del dominio proprietario chiamato Quill per modellare vincoli aziendali ¹⁴. Questo DSL consente agli ingegneri di codificare soluzioni personalizzate (ad esempio, programmi di produzione personalizzati o piani di routing) e sfruttare risolutori matematici. L’esistenza stessa di un DSL nel prodotto è una prova di seria competenza tecnologica avanzata - progettare un linguaggio di programmazione per problemi di pianificazione non è banale ¹⁵. Quintiq eccelle in scenari come la pianificazione delle fabbriche, l’ottimizzazione della rete logistica 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 di supply chain. Tuttavia, il focus di Quintiq sull’ottimizzazione avviene a scapito di altre aree: ad esempio, ha capacità di previsione native relativamente limitate ¹⁶. Un’altra preoccupazione è che gli aggiornamenti tecnici pubblici su Quill sono scarsi, suggerendo che la tecnologia potrebbe essere obsoleta o comunque non evolversi rapidamente ¹⁷. Gli utenti spesso si affidano ai consulenti di Dassault per configurare soluzioni, e senza una chiara documentazione pubblica, è difficile valutare le innovazioni recenti. In sintesi, Quintiq è una scelta di alto livello per le esigenze di ottimizzazione complesse e dimostra una forte ingegneria attraverso il suo DSL - ma non è trasparente o aggiornato in aree come l’AI/previsione, 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 avvertenze. Il software di ToolsGroup (SO99+) si è da tempo specializzato nella previsione della domanda e nell’ottimizzazione dell’inventario, con un’enfasi sui modelli probabilistici. Offre un’ampia funzionalità della supply chain (pianificazione della domanda, rifornimento, ottimizzazione dell’inventario multi-echelon) ed è stato uno dei primi fornitori a vantare la previsione probabilistica “Potentemente Semplice”. Sulla carta, questo suona avanzato - ToolsGroup afferma di modellare l’incertezza della domanda e di “autoregolare” le previsioni, il che dovrebbe consentire di ottenere obiettivi di inventario più accurati. Tuttavia, un’analisi tecnica approfondita solleva preoccupazioni. I materiali pubblici di ToolsGroup suggeriscono ancora l’uso di modelli di previsione dell’era pre-2000 sotto la superficie ¹⁸ - hanno aggiunto un tocco di “AI” nel marketing, ma senza specifiche. In modo significativo, dal 2018 pubblicizzano previsioni probabilistiche mentre si vantano contemporaneamente di miglioramenti del MAPE ¹⁹. Questa è una contraddizione lampante: se le previsioni sono veramente distribuzioni probabilistiche, metriche come il MAPE (che misura l’accuratezza dei valori singoli) non si applicano più direttamente ¹⁹. Tali incongruenze suggeriscono che la parte “probabilistica” potrebbe essere superficiale o che si stiano rivolgendo a vecchie metriche nonostante i nuovi metodi. Inoltre, ToolsGroup ha utilizzato parole di moda come “AI per la percezione della domanda”, ma queste affermazioni sono sostenute dalla letteratura scientifica o da un qualsiasi benchmark conosciuto ²⁰. Nella pratica, molte implementazioni di ToolsGroup funzionano ancora come sistemi automatizzati basati su regole con avvisi di eccezione. In conclusione: ToolsGroup ha una vasta funzionalità ed è stato in anticipo nell’advocacy della modellazione dell’incertezza, ma la mancanza di trasparenza sugli algoritmi e il divario tra marketing e realtà sull’AI/ML ne limitano la credibilità tecnica solo in modo moderato. È un insieme di strumenti solido e focalizzato sul dominio, ma non chiaramente all’avanguardia secondo gli standard attuali.
Slimstock (Slim4) - Semplice e solido. Slimstock è un’eccezione rinfrescante che non segue le tendenze. Il software Slim4 si concentra su tecniche mainstream della supply chain - cose come calcoli classici di stock di sicurezza, punti di riordino, quantità economica di ordine (EOQ), ecc. ²¹. In altre parole, Slimstock si attiene a metodi ben consolidati e collaudati insegnati nei libri di testo. Sebbene ciò significhi nessuna sofisticata AI/ML o algoritmi all’avanguardia, significa anche che Slim4 è affidabile e facile da capire. Il fornitore evita esplicitamente affermazioni vaghe sull’AI e invece enfatizza funzionalità pratiche che si allineano con le esigenze 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 essere un limite - non otterrai previsioni di domanda probabilistiche o ottimizzatori avanzati da Slim4. Non è progettato per reti altamente complesse o volumi di dati massicci (e infatti la sua architettura tecnologica è probabilmente un database standard con memorizzazione nella cache in memoria, adatto per problemi di dimensioni medie). Ma per molte aziende, più semplice è meglio se significa che lo strumento funziona in modo coerente. Slimstock guadagna punti di credibilità per evitare il bingo di parole di moda; il suo approccio “diretto al punto” è elogiato dai colleghi come un contrasto alla postura sull’AI degli altri ²³. In sintesi, Slim4 non sta spingendo il limite tecnologicamente, ma è una scelta valida per la previsione fondamentale e la gestione dell’inventario con un minimo di enfasi e un’architettura chiara e a basso rischio.
o9 Solutions - Macchina dell’alta tecnologia. o9 si presenta come un “Cervello Digitale” per la catena di approvvigionamento aziendale, combinando previsioni della domanda, pianificazione degli approvvigionamenti, S&OP e persino gestione dei ricavi su una piattaforma. Tecnicamente, o9 ha inserito molti concetti tecnologici moderni nel suo prodotto: un modello di dati in memoria, un database a grafo chiamato “Enterprise Knowledge Graph (EKG)”, e vari componenti di intelligenza artificiale/apprendimento automatico. La massa tecnologica pura di o9 è fuori scala ²⁴ - secondo gli standard del software aziendale, è un’architettura molto ambiziosa che cerca di unificare tutti i dati e le analisi di pianificazione. Tuttavia, applicando scetticismo: gran parte di questo sembra essere tecnologia fine a se stessa, senza un chiaro ritorno economico. Il design in memoria di o9 garantisce costi hardware estremamente elevati su larga scala ²⁵, simili all’esecuzione continuativa di un gigantesco cubo BI. o9 pubblicizza il suo EKG (grafo della conoscenza) come abilitante previsioni superiori e intuizioni guidate dall’IA, ma non vengono fornite prove scientifiche o benchmark credibili ²⁵. Infatti, molte delle vistose affermazioni di o9 crollano sotto scrutinio: l’azienda parla di IA ovunque, ma frammenti del loro codice pubblicamente visibile su GitHub rivelano tecniche piuttosto banali ²⁶. Ad esempio, o9 ha pubblicizzato funzionalità come la previsione della domanda tramite apprendimento automatico e simulazioni “gemelle digitali”, ma non ha dimostrato queste in nessuna competizione pubblica o studio di caso sottoposto a revisione tra pari. Senza prove, dobbiamo trattare le sue affermazioni sull’IA come esagerazioni di marketing. Detto ciò, o9 non è privo di punti di forza - è una piattaforma unificata (sviluppata internamente, non un insieme di acquisizioni) e può gestire l’integrazione di dati su larga scala. Per un’azienda disposta a investire in hardware e affrontare una ripida curva di apprendimento, o9 offre flessibilità per costruire modelli di pianificazione complessi. Ma da un punto di vista ingegneristico, è una soluzione sovra-ingegnerizzata: molta complessità, ROI non chiaro sulla tecnologia di lusso 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 dei benchmark), la sua credibilità rimarrà dubbia.
SAP IBP (Integrated Business Planning) - Completo ma Complesso. La suite IBP di SAP è l’evoluzione del legacy APO di SAP, ora offerta come soluzione cloud sul database in memoria SAP HANA. SAP IBP mira a coprire l’intero spettro: previsioni della domanda, ottimizzazione degli inventari, pianificazione degli approvvigionamenti, pianificazione delle vendite e delle operazioni, e altro ancora - il tutto strettamente integrato con l’ERP di SAP. La forza di SAP IBP è la ampiezza: ha un modulo per quasi ogni aspetto della pianificazione, spesso con funzionalità molto ricche ereditate da decenni di esperienza SAP. Tuttavia, l’ampiezza è arrivata attraverso acquisizioni e sistemi legacy. SAP ha acquisito specialisti come SAF (previsioni della domanda), SmartOps (ottimizzazione degli inventari) e altri ²⁷ e li ha sovrapposti ai propri strumenti interni (come APO e HANA). Il risultato sotto il cofano è un patchwork di motori e approcci diversi ²⁷. Di conseguenza, l’architettura tecnica di IBP non è elegante - è una collezione di componenti che non si “mescolano” naturalmente, richiedendo un grande sforzo di integrazione. Anche la documentazione di SAP riconosce l’alta complessità e la necessità di integratori di sistema di alto livello (e tempo sostanziale) per far funzionare tutto senza intoppi ²⁸. Sul fronte tecnologico, IBP fa affidamento pesantemente su SAP HANA, un database colonna in memoria, per ottenere prestazioni in tempo reale. HANA è effettivamente veloce, ma è anche costoso - memorizzare grandi dati di pianificazione esclusivamente in RAM è intrinsecamente costoso (la RAM è circa 100 volte più costosa per TB rispetto allo storage su disco) ¹⁰. Ciò significa che scalare IBP a set di dati sulla catena di approvvigionamento molto grandi comporta significativi costi infrastrutturali, e se i dati superano la memoria, le prestazioni possono crollare. SAP ha iniziato ad aggiungere alcune funzionalità di apprendimento automatico (ad es. “Demand Driven MRP” e IBP for Demand ha alcune opzioni di previsione ML), ma queste sono principalmente add-on opzionali con trasparenza limitata. Non ci sono prove che l’IA di SAP sia superiore alle alternative; infatti, nessun algoritmo SAP ha fatto la sua comparsa in competizioni di previsione indipendenti. In sintesi, SAP IBP è ricco di funzionalità e testato in ambito aziendale - spunterà tutte le caselle sulla funzionalità - ma da un punto di vista di purezza tecnica, è un mix: velocità in memoria unita alla logica legacy, molta complessità da prodotti fusi, e nessuna chiara innovazione tecnica nella previsione o nell’ottimizzazione oltre ciò che già facevano i pezzi acquisiti. Le aziende spesso lo scelgono per l’integrazione con SAP ERP piuttosto che per l’eccellenza nell’ottimizzazione in sé.
Blue Yonder - Leader del passato trasformato in un insieme disomogeneo. Blue Yonder (ex JDA Software) offre una suite completa che include previsioni, pianificazione della fornitura, merchandising ed esecuzione. È il risultato di molti anni di fusioni e acquisizioni, tra cui l’acquisizione da parte di JDA di i2 Technologies (pianificazione della supply chain), Manugistics e la startup di intelligenza artificiale Blue Yonder (da cui ha preso il nome) tra gli altri ²⁹. Purtroppo, il software enterprise non è una semplice somma di parti: sotto il marchio unificato di Blue Yonder si nasconde un insieme di prodotti (molti dei quali piuttosto datati) collegati in modo approssimativo ²⁹. Dal punto di vista tecnico, le soluzioni di Blue Yonder vanno dai motori di previsione deterministici vecchio stile ai moduli di ottimizzazione dell’inventario che non sono fondamentalmente cambiati da oltre 15 anni. L’azienda promuove pesantemente le 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 accreditati al team di data science di Blue Yonder - suggeriscono che stiano utilizzando metodi piuttosto tradizionali (ad esempio, estrazione di caratteristiche di serie temporali, modelli ARMA e regressione lineare) ³⁰. Queste tecniche vanno bene, ma sono approcci vecchi di decenni che spesso vengono superati da metodi più recenti. Sembra che la tanto pubblicizzata AI di Blue Yonder potrebbe semplicemente essere una regressione euristicamente riproposta. Senza studi di casi trasparenti o documenti tecnici, bisogna presumere che le affermazioni di Blue Yonder riguardo alle “previsioni AI rivoluzionarie” siano solo chiacchiere di marketing. Inoltre, l’integrazione di tutti i componenti acquisiti è una sfida in corso - molti clienti segnalano difficoltà nel ottenere la promessa “end-to-end” perché i moduli (domanda, fornitura, soddisfazione, ecc.) non si collegano naturalmente senza una personalizzazione significativa. In-memory vs. on-disk? Blue Yonder non pubblicizza un’architettura completamente in-memory come fanno altri; parti del sistema probabilmente girano su database relazionali standard. Questo potrebbe effettivamente essere un punto a favore in termini di costi, ma significa anche che le prestazioni possono essere inferiori a meno che i dati non siano aggregati (ad esempio, i loro sistemi più vecchi spesso eseguivano pianificazioni batch). In sintesi, Blue Yonder è una storia di avvertimento: una volta leader del settore, ora offre una suite ampia ma tecnicamente inconsistente. I suoi punti di forza risiedono nell’esperienza di dominio e in un ampio set di funzionalità, ma i suoi punti deboli sono la tecnologia obsoleta sotto una vernice fresca e la mancanza di prove credibili delle sue nuove capacità “AI”.

(Nota: Altri fornitori come Infor (con componenti ereditati GT Nexus e Mercia), GAINS Systems (un altro specialista nell’ottimizzazione dell’inventario), John Galt Solutions (pianificazione della domanda per il mercato medio), Relex Solutions (previsioni per il settore del retail con un motore in-memory), ecc., esistono anche. Per motivi di focalizzazione, abbiamo classificato i più prominenti o istruttivi sopra. Gli stessi criteri scettici si applicano a quelli non classificati singolarmente: ad esempio, Relex utilizza un design in-memory di tipo 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 funzionalità di base solide ma poco documentate pubblicamente su eventuali tecniche innovative. Qualsiasi fornitore che non condivida apertamente dettagli tecnici o punti di prova sarebbe comunque classificato basso nella metodologia di questo studio.)*

Analisi Tecnica Approfondita

In questa sezione, approfondiamo specifici aspetti tecnici dei migliori software di ottimizzazione della supply chain, concentrandoci su quattro aree chiave: Previsioni e AI, Capacità di automazione, Architettura del sistema e Integrazione dei moduli. Tutta l’analisi è basata su informazioni tecniche pubblicate o prove concrete, evitando esplicitamente qualsiasi linguaggio di marketing.

Capacità di Previsione e AI

La pianificazione moderna della supply chain si basa sull’accuratezza delle previsioni di domanda, eppure le affermazioni di superiorità nelle previsioni sono diffuse e spesso infondate. La nostra indagine ha rilevato che le capacità di previsione della maggior parte dei fornitori non superano significativamente i metodi statistici standard - nonostante parole di moda come “AI” o “machine learning” nel loro marketing.

Performance Provata vs. Hype: Tra tutti i fornitori, Lokad è l’unico con un comprovato track record di previsioni di classe mondiale, grazie alla competizione M5 aperta. Lokad ha dimostrato la sua abilità di previsione probabilistica classificandosi al primo posto per l’accuratezza a livello di SKU ¹. Ciò conferisce credibilità alle affermazioni di Lokad riguardo a una migliore precisione delle previsioni. Al contrario, nessun altro fornitore ha pubblicato risultati comparabili su un benchmark indipendente. Ad esempio, alcuni fornitori pubblicizzano algoritmi proprietari (uno chiama il suo metodo “Procast”) affermando un’accuratezza superiore, ma questi metodi erano assenti dai primi posti della competizione M5 ³². In pratica, approcci accademici open-source (come i pacchetti di previsione R del Prof. Rob Hyndman) sono probabilmente altrettanto buoni o migliori della maggior parte dei motori proprietari chiusi ¹³. Pertanto, qualsiasi affermazione del fornitore riguardo a una “migliore precisione delle previsioni del settore” senza prove pubbliche dovrebbe essere considerata non supportata.
Affermazioni su AI e Machine Learning: Abbiamo applicato un estremo scetticismo alle affermazioni su AI/ML. Fornitori come o9 Solutions e Blue Yonder fanno largo uso di termini come “previsioni basate su AI/ML” nei loro opuscoli. Tuttavia, alla ricerca di sostanza, abbiamo trovato poco. Nel caso di o9, le loro affermazioni che il “Grafo della Conoscenza Aziendale” basato su grafi produce previsioni migliori sono discutibili senza alcun supporto scientifico ²⁵. Blue Yonder pubblicizza in modo simile l’AI ma non fornisce dettagli - l’unica occhiata alla loro tecnologia proviene da alcuni repository open-source che mostrano l’uso di tecniche di serie temporali piuttosto ordinarie (ARMA, regressione lineare, ingegneria delle caratteristiche) ³⁰. Non vi è alcuna evidenza di apprendimento profondo, metodi probabilistici avanzati o altre moderne tecnologie AI che giustificherebbero il loro marketing. ToolsGroup ha incorporato concetti di machine learning (parlano di “sensore di domanda” utilizzando il machine learning), ma ancora una volta nessuno studio revisionato dai pari o vittorie in competizioni per convalidarlo ²⁰. Infatti, l’accoppiamento di ToolsGroup delle “previsioni probabilistiche” con vecchie metriche come MAPE suggerisce che la loro AI sia più buzz che innovazione ¹⁹. Conclusione: Al di fuori di Lokad (e in parte SAS, che utilizza modelli statistici comprovati nel tempo), le previsioni nella maggior parte del software di supply chain rimangono basate su metodi noti (smoothing esponenziale, regressione, forse alcuni ML basati su alberi) e non su qualche geniale AI proprietaria. I fornitori che hanno algoritmi veramente innovativi li dimostrerebbero pubblicamente. La mancanza di convalida indipendente è significativa.
Approcci probabilistici vs deterministici: Un differenziatore tecnico notevole è se un fornitore adotta la previsione probabilistica (prevedere una distribuzione completa degli esiti della domanda) o si attiene alle previsioni a singolo punto. Lokad è stato un sostenitore vocale delle distribuzioni di probabilità complete dal 2012, e infatti ottimizza le decisioni (come i livelli di stock) direttamente dalle previsioni probabilistiche. Anche ToolsGroup afferma di produrre previsioni probabilistiche (probabilmente tramite simulazioni Monte Carlo della domanda). Tuttavia, abbiamo scoperto che molti che affermano di essere “probabilistici” ritornano comunque a metriche e processi deterministici internamente. Ad esempio, il marketing di ToolsGroup riguardo alla riduzione del MAPE utilizzando modelli probabilistici è incoerente, poiché il MAPE non può nemmeno essere calcolato su un’uscita di previsione probabilistica ¹⁹. Questo suggerisce che il loro processo alla fine ritorna a una previsione a punto (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 ha ora “insiemi statistici” e intervalli di confidenza), ma ancora le loro interfacce utente e i report spesso si basano su previsioni a singolo numero con metriche di errore tradizionali. Abbracciare una vera previsione probabilistica richiede di ripensare agli KPI (utilizzando Pinball loss, CRPS o raggiungimento del livello di servizio invece del MAPE). Non abbiamo trovato prove che nessun grande fornitore tranne Lokad sia arrivato a tanto nella pratica. In sintesi, la previsione probabilistica è un’area in cui il marketing è avanti rispetto alla realtà per la maggior parte dei fornitori: potrebbero generare alcune distribuzioni dietro le quinte, ma i pianificatori stanno ancora guardando numeri di previsione a punto e KPI classici, il che indica una limitata adozione del paradigma.
Metriche e valutazione delle previsioni: Un aspetto importante della rigore tecnico è come un fornitore valuta la qualità delle previsioni. Un campanello d’allarme è il continuo affidamento su metriche come MAPE, WAPE o bias come unici indicatori di successo, specialmente se il fornitore afferma di utilizzare metodi AI o probabilistici. Questo perché quelle metriche incoraggiano previsioni conservative e di media strada e possono essere manipolate (ad esempio, tagliando i massimi e minimi). Abbiamo osservato che i fornitori con previsioni veramente avanzate tendono a parlare di livelli di servizio o risultati aziendali (ad es. probabilità di esaurimento delle scorte, impatto sui costi) invece che solo di MAPE. Lokad, ad esempio, enfatizza la riduzione degli “errori in dollari” e l’allineamento delle previsioni con l’ottimizzazione delle decisioni ³³. Al contrario, ToolsGroup, Blue Yonder e molti altri ancora evidenziano errori percentuali nei loro casi di studio, mostrando una mentalità superata. Se la documentazione o la demo di un fornitore presenta fortemente dashboard MAPE/WAPE, è un segno che le loro previsioni sono probabilmente tradizionali. Infatti, l’incoerenza di ToolsGroup sul MAPE è stata già notata ¹⁹. In breve: previsioni veramente all’avanguardia nella supply chain sarebbero evidenziate da metriche probabilistiche e validazione nel mondo reale - attributi per lo più mancanti al di fuori di uno o due attori.

Automazione e capacità di flusso di lavoro

Ottenere l’ottimizzazione della supply chain non riguarda solo gli algoritmi; riguarda anche quanto automatizzato e “hands-free” il software può eseguire il processo di pianificazione. Abbiamo esaminato le affermazioni e la documentazione di ciascun fornitore per trovare prove di automazione, integrazione API e supporto alla presa di decisioni autonoma.

Lokad: L’automazione è uno dei punti di forza di Lokad. L’intera soluzione è costruita attorno a un linguaggio specifico del dominio (Envision) che consente ai pianificatori della supply chain di codificare la loro logica e decisioni in script, che poi vengono eseguiti automaticamente secondo un programma. Lokad documenta chiaramente i suoi pipelines di dati e il gestore del flusso di lavoro che aggiorna i dati e ricalcola le decisioni (previsioni, ordini di riassortimento, ecc.) senza intervento manuale ³⁴ ³⁵. Parlano persino di avere “configurazioni altamente automatizzate” per ~100 supply chain in produzione ³⁵, il che significa che il software sta estraendo dati, facendo previsioni e producendo decisioni (come proposte di ordini di acquisto) in modo automatico. Inoltre, Lokad fornisce API per il caricamento dei dati e il download dei risultati, e ha un concetto di “AI Pilot” per automatizzare compiti amministrativi ³⁶. Tutto questo indica un livello molto elevato di automazione reale - il ruolo dell’utente è principalmente monitorare e perfezionare il codice/i parametri, non premere manualmente i pulsanti per ogni piano. L’approccio di Lokad all’automazione è credibile e tecnicamente dettagliato (hanno persino tenuto conferenze su come passare da decisioni manuali ad automatizzate ³⁷ ³⁸).
Kinaxis: Kinaxis RapidResponse è progettato per l’analisi rapida degli scenari e la collaborazione piuttosto che per la pianificazione completamente automatizzata. Il concetto di “pianificazione concorrente” consiste nel fatto che tutti lavorano sullo stesso set di dati con aggiornamenti in tempo reale, ma coinvolge ancora tipicamente pianificatori umani per valutare gli scenari e prendere decisioni. Detto ciò, Kinaxis supporta l’automazione in determinati modi: può acquisire dati dai sistemi ERP quasi in tempo reale, eseguire continuamente gli algoritmi di corrispondenza tra domanda e offerta e attivare avvisi o messaggi di eccezione agli utenti quando le cose vanno oltre i limiti. Espone funzionalità tramite API e ha scripting (sotto forma di algoritmi configurabili e macro nel suo ambiente) per gli utenti esperti. Tuttavia, Kinaxis si posiziona generalmente come supporto decisionale, non come una scatola nera che rilascia automaticamente ordini. Il fornitore non afferma ad alta voce “catena di approvvigionamento autonoma”; invece, si concentra su rendere i pianificatori più efficienti. Questa è una posizione onesta. Significa che di default, RapidResponse si aspetta comunque l’intervento umano - il che può essere un limite se si cerca un sistema di catena di approvvigionamento “guidato automaticamente”. Tecnicamente, Kinaxis può essere integrato in profondità (ad esempio, spesso si integra con SAP ERP per eseguire piani approvati), ma l’operazione end-to-end non assistita richiederebbe molte configurazioni personalizzate. Non abbiamo trovato prove che Kinaxis fornisca raccomandazioni decisionali basate sull’IA (il loro punto di forza è più nella rapida elaborazione degli scenari definiti dagli utenti).
o9 Solutions: o9 promuove pesantemente concetti come un “gemello digitale” dell’organizzazione e l’IA che può fare raccomandazioni. Parlano di “Automazione” nel contesto dei loro assistenti digitali - presumibilmente bot che possono fornire informazioni o svolgere alcune attività. Tuttavia, in assenza di documentazione tecnica concreta, è difficile capire quanto sia reale. Non abbiamo trovato dettagli come “o9 può rilasciare automaticamente ordini di rifornimento tramite API in base ai suoi piani” o “o9 utilizza il reinforcement learning per regolare i parametri autonomamente”. La vaghezza della storia dell’automazione di o9 è preoccupante: molte discussioni di alto livello, pochi dettagli. Date le sue fondamenta in memoria EKG, sospettiamo che o9 sia in grado di aggiornamenti e ricalcoli dei dati in tempo reale, ma probabilmente si affida ancora agli 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 nei sistemi di esecuzione (è un software moderno, quindi l’integrazione API dovrebbe esistere), ma quanto la presa di decisioni è veramente automatizzata dall’IA in o9 non è chiaro. Le prove suggeriscono che l’attuale automazione di o9 riguarda più l’accelerazione dell’analisi (ad esempio, scenari what-if istantanei) che l’automazione delle decisioni.
Blue Yonder: Negli ultimi anni, Blue Yonder (specialmente dopo essere stata acquisita da Panasonic) ha spinto il termine “catena di approvvigionamento autonoma”, implicando un sistema che può funzionare con minima intervento umano. Hanno alcuni componenti, come Luminate Control Tower, che utilizzano l’IA per rilevare interruzioni e eventualmente attivare risposte. Tuttavia, data la base legacy di Blue Yonder, è probabile che qualsiasi autonomia sia raggiunta mediante sovrapposizione di RPA (Automazione dei Processi Robotici) o semplici agenti di IA sui moduli esistenti. Ad esempio, la pianificazione della domanda di Blue Yonder potrebbe produrre una previsione, e uno strato “IA” potrebbe regolarla automaticamente in base alle vendite in tempo reale (rilevamento della domanda) o inviare un avviso in caso di deviazione. Ma la pianificazione completamente automatizzata (come l’emissione automatica di ordini, l’aggiustamento automatico delle politiche di inventario) è probabilmente rara con le soluzioni BY - di solito i clienti hanno ancora pianificatori che controllano e approvano le azioni. La mancanza di 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 lavori in batch, aggiornamenti ai piani, forse integrazione a ciclo chiuso nei sistemi di esecuzione), ma non è dimostrabilmente in vantaggio in questo settore. Probabilmente utilizza una pianificazione basata su eccezioni simile ai sistemi più vecchi (solo con un nuovo rivestimento di IA sul sistema di avviso).
ToolsGroup: ToolsGroup storicamente si è vantato di “Automazione Potentemente Semplice”. Affermavano che il loro sistema potesse funzionare in modalità lights-out per periodi prolungati, richiamando i pianificatori solo per le eccezioni. Infatti, la filosofia di ToolsGroup era quella di permettere al sistema di ricalcolare e ripianificare automaticamente ogni giorno, adattandosi ai nuovi dati. A loro merito, molti clienti di ToolsGroup hanno riportato un carico di lavoro ridotto per i pianificatori perché il software auto-regola gli obiettivi di inventario e raccomanda gli ordini automaticamente. ToolsGroup ha anche un toolkit di integrazione per inviare gli ordini approvati ai sistemi ERP. Tuttavia, a causa delle contraddizioni precedentemente note, 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 programmate, quindi tecnicamente l’infrastruttura per l’automazione è presente. La domanda è sulla qualità delle decisioni automatizzate. Parlano molto di “auto-tuning” - implicando che il software regoli automaticamente i parametri del modello di previsione da solo man mano che arrivano nuovi dati ³⁹. Se è vero, questa è un’automazione utile (eliminando la necessità di costanti riconfigurazioni umane). Senza una valutazione indipendente, diciamo con cautela che ToolsGroup offre un’elevata automazione nelle attività di pianificazione di routine, ma la mancanza di trasparenza rende difficile giudicare quanto “intelligente” sia quell’automazione (ad esempio, impara e migliora genuinamente, 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 di pianificazione programmate e alcuni flussi di lavoro basati su eccezioni. Ad esempio, SAP IBP può essere impostato per eseguire automaticamente un lavoro di previsione ogni mese e popolare i risultati della pianificazione, ma tipicamente un pianificatore rivede l’output. Anaplan è meno focalizzato sull’automazione - è più una piattaforma di modellazione manuale, anche se è possibile utilizzare la sua API per spingere/tirare i dati e forse automatizzare determinati calcoli. Dassault/Quintiq può essere programmato per eseguire routine di ottimizzazione su un programma (e il DSL di Quintiq significa che è possibile programmare comportamenti automatici personalizzati), ma di nuovo, è autonomo quanto il programmatore lo configura. GAINS, Relex, Netstock e altri fornitori di nicchia pubblicizzano tutti “automazione end-to-end” nel rifornimento - di solito significa che possono generare automaticamente ordini di acquisto o raccomandazioni di trasferimento di magazzino. La differenza chiave sta in quanto controllo è necessario: un sistema di pianificazione veramente autonomo chiamerebbe gli umani solo per situazioni insolite e documenterebbe le sue decisioni con ragionamento. Non abbiamo trovato alcun fornitore che raggiunga appieno questo ideale ancora. Richiedono o che gli umani apportino modifiche e approvino (nella maggior parte dei casi), o automatizzano solo le decisioni più facili e lasciano il resto.

Sintesi sull’Automazione: Solo alcuni fornitori (notabilmente Lokad) dettagliano pubblicamente un framework di automazione che abilita cicli di pianificazione guidati da API non assistiti. Altri hanno i mezzi tecnici per l’automazione ma si affidano ancora agli umani per chiudere il cerchio. Notiamo anche che alcuni fornitori hanno spostato il focus negli ultimi decenni dall’automazione completa alla “gestione delle eccezioni” - che è essenzialmente un approccio semi-automatico in cui il software fa ciò che può e segnala il resto agli umani ³⁸. Questo approccio, sebbene pratico, può essere un sostegno per il software che non è abbastanza robusto da fidarsi pienamente. Il nostro atteggiamento 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 e Scalabilità

L’architettura sotto il cofano - in particolare l’uso di calcolo in memoria rispetto a su disco, e le scelte progettuali complessive - ha enormi implicazioni per la scalabilità, il costo e le prestazioni di un software di supply chain. Abbiamo esaminato lo stack tecnologico di base di ciascun fornitore con un focus su come gestiscono grandi dati e calcoli complessi.

Calcolo in Memoria - Pro e Contro: Molti dei principali fornitori si affidano a un’architettura in memoria, 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 risolvere scenari). Il vantaggio è la velocità: l’accesso alla RAM è di ordini di grandezza più veloce rispetto al disco. Ad esempio, il motore di Kinaxis mette tutti i dati in memoria per consentire il ricalcolo istantaneo degli scenari e operazioni algoritmiche dirette sul dataset ⁹. HANA di SAP è stato costruito sul presupposto che le analisi sui dati in tempo reale dovrebbero avvenire in memoria per risultati in tempo reale ⁴⁰ ⁴¹. Tuttavia, c’è un problema fondamentale con un design completamente in memoria: 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 ¹⁰. E le dimensioni della memoria sui server sono fisicamente limitate (i sistemi tipici potrebbero avere al massimo 0,5-2 TB di RAM, mentre dataset multi-terabyte o petabyte sono comuni nelle grandi supply chain). Negli ultimi anni, i previsti drastici cali dei costi della RAM non si sono materializzati - i prezzi e le capacità della RAM sono rimasti piuttosto stagnanti ⁴². Ciò significa che qualsiasi sistema che richieda tutti i dati in memoria affronterà costi infrastrutturali in aumento man mano che i dati crescono, o colpirà un soffitto rigido dove semplicemente non può adattare i dati. Etichettiamo un’elevata dipendenza dal design in memoria come un errore architettonico per le grandi supply chain, a meno che non venga mitigato.
Memoria vs. Disco: Pratiche Moderne: Interessante notare che il mondo della tecnologia più ampio ha realizzato che le soluzioni puramente in memoria non sono il futuro per i big data. Le architetture più recenti utilizzano un approccio a più livelli - mantenere i dati caldi in memoria e i dati freddi su SSD, ecc. ⁴³ ⁴⁴. Alcuni software di 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 di vendita al dettaglio di 10 miliardi di righe utilizzando circa 37 GB di RAM più un veloce SSD NVMe per spillare l’overflow ⁴⁵ ³. Ottengono prestazioni quasi alla RAM mappando i file in memoria e mantenendo solo i dati più caldi nella RAM, con lo scambio intelligente del software secondo necessità ⁴⁶ ⁴⁷. Questo approccio porta a enormi risparmi di costi - ad esempio, per il costo di 18 GB di RAM di alta qualità, si può acquistare 1 TB di SSD NVMe ³, quindi è 50 volte più economico per byte pur essendo solo ~6 volte più lento nell’accesso grezzo, un compromesso spesso conveniente. Nessuno dei fornitori centrati sull’in-memory (Kinaxis, SAP, o9, ecc.) ha descritto pubblicamente una gestione adattiva della memoria, suggerendo che le loro soluzioni potrebbero semplicemente richiedere molta RAM o richiedere l’aggregazione dei dati per adattarsi. Anaplan è noto per avere problemi con i limiti di dimensione del modello - alcuni clienti si scontrano con i limiti di memoria del suo Hyperblock e devono dividere i modelli. Kinaxis probabilmente ha bisogno anche di più server collegati in rete per dati molto grandi (hanno un concetto di distribuzione dei dati, ma all’interno di ciascun nodo è residente in memoria). SAP HANA può scaricare su disco (ha nodi di estensione), ma le prestazioni ne risentono. In conclusione: un design rigido in memoria è un campanello d’allarme per la scalabilità. Può funzionare brillantemente per dati di piccole e medie dimensioni, ma man mano che la supply chain cresce (pensate: pianificazione dettagliata a livello di SKU-store-day per un rivenditore globale), i costi e i rischi delle prestazioni aumentano. L’ingegneria moderna favorisce un mix di utilizzo della memoria e del disco per bilanciare velocità e costo, e i fornitori che non lo fanno sono indietro rispetto alla curva.
Tecnologia e Complessità: Oltre alla memoria, un altro elemento architetturale è l’intero stack tecnologico - 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) girano su stack più monolitici e legacy, mentre quelli più nuovi (o9, Anaplan) hanno costruito le proprie soluzioni da zero con tecnologie più recenti. Ad esempio, il core di SAP IBP include ancora motori degli anni 2000 (come l’ottimizzatore di APO) ora avvolti in uno strato HANA/cloud. Questo introduce complessità e potenziale inefficienza (diverse livelli di astrazione). Blue Yonder ha simili codici legacy dai tempi di i2 e JDA. Kinaxis è in qualche modo unico - è vecchio (è iniziato negli anni ‘90) ma si è continuamente rifattorizzato nel 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 caso d’uso specifico (Hyperblock), ed è ottimizzato per quel fine - ma non è aperto e devi convivere con i suoi vincoli (ad esempio, nessuna interrogazione SQL, complessità algoritmica limitata poiché si basa su calcoli a celle). La piattaforma di o9 include una miscela di tecnologie (probabilmente un database NoSQL/graph, forse Spark o simili per alcuni ML, ecc.), rendendola complessa ma teoricamente flessibile.
Hardware e Cloud: Una tendenza significativa è il design nativo del cloud. Molti fornitori offrono ora il loro software come SaaS o almeno ospitato su cloud, ma non tutti sono veramente nativi del cloud. Ad esempio, Anaplan e o9 sono SaaS multi-tenant (costruiti per il cloud fin dall’inizio). Lokad è nativamente cloud (funziona su Microsoft Azure e alloca dinamicamente risorse). SAP IBP è ospitato su cloud ma essenzialmente ogni cliente è un’istanza isolata su HANA (non multi-tenant nello stesso senso). ToolsGroup, Blue Yonder offrono servizi SaaS ma spesso si tratta solo del loro software on-prem gestito da loro nel cloud. Perché questo è importante dal punto di vista tecnico? Le architetture native del cloud sono tipicamente più elastiche - possono allocare risorse di calcolo quando necessario (per una grande pianificazione) e deallocarle dopo, controllando possibilmente i costi. I sistemi non cloud spesso richiedono l’acquisto di capacità di picco anche se utilizzati occasionalmente. Inoltre, i sistemi nativi del cloud potrebbero integrarsi meglio con altri servizi cloud (ad esempio, collegandosi a un servizio cloud ML o a un data lake). Da quanto abbiamo scoperto, le soluzioni più native del cloud e scalabili per design sembrano essere Lokad e o9 (e forse Anaplan), mentre gli altri stanno recuperando. Tuttavia, essere nativi del cloud da soli non equivale a una buona architettura - o9 è nativo del cloud ma abbiamo messo in discussione il suo approccio pesante in memoria; SAP IBP essendo su cloud non rimuove i suoi problemi di complessità.
Concorrenza e Necessità in Tempo Reale: Una considerazione architetturale è come il sistema gestisce utenti concorrenti e aggiornamenti in tempo reale. Kinaxis eccelle qui: è stato progettato per consentire a più pianificatori di fare pianificazioni di scenario contemporaneamente sullo stesso set di dati. Ciò richiede una logica di versionamento e blocco dei dati attenta - che Kinaxis ha ottenuto tramite il loro meccanismo di branch ⁸. La maggior parte degli altri strumenti tradizionalmente seguiva un paradigma batch (pianifica, pubblica, quindi collabora separatamente). Ora, molti stanno aggiungendo funzionalità di pianificazione concorrente. Anaplan consente a più persone di lavorare in diverse parti del modello contemporaneamente (poiché è essenzialmente basato su celle come Google Sheets). SAP IBP ha introdotto un’interfaccia utente “simile a Microsoft Excel” che può aggiornare i dati dal server su richiesta, ma la vera concorrenza (più utenti che modificano il piano contemporaneamente) è limitata. o9 probabilmente supporta un certo livello di concorrenza data la sua knowledge graph (più utenti possono regolare nodi diversi). Nell’valutare il merito tecnico, un sistema che può veramente operare in tempo reale con molti utenti indica un’architettura robusta. Kinaxis e Anaplan ottengono punti qui. Non è che gli altri non possano farlo, ma spesso le loro architetture più vecchie lo rendono difficile - risultando in prestazioni lente o forzando processi sequenziali.

Sommario per Architettura: Abbiamo identificato un modello: i design incentrati sulla memoria (Kinaxis, Anaplan, o9, Relex, SAP HANA) offrono velocità ma a costo della scalabilità e del denaro, mentre i design ibridi (come il spill-to-disk di Lokad, forse strumenti che utilizzano database moderni) sono più scalabili ed efficienti dal punto di vista dei costi. Un chiaro segnale di pericolo è rappresentato da qualsiasi fornitore che insiste sul fatto che tutto deve essere in RAM per funzionare - questo è considerato un approccio superato dati i progressi nella velocità degli SSD e nel calcolo distribuito ⁴³ ⁴⁴. Sottolineiamo inoltre che le architetture dei fornitori nate da molteplici acquisizioni (come SAP, Blue Yonder) tendono ad essere eccessivamente complesse e richiedono molte ottimizzazioni. Le architetture più semplici e interne (come il singolo codice di Kinaxis, il singolo motore di Anaplan, il singolo motore di Lokad) tendono ad essere più coerenti e quindi più facili da mantenere dal punto di vista tecnico. Nell’valutare un software di supply chain, bisogna chiedersi: Il fornitore ha pubblicato qualcosa su come è costruito il loro software (microservizi? DB personalizzato? uso di librerie di ML? ecc.). La mancanza di qualsiasi discussione ingegneristica potrebbe significare che l’architettura è solo una scatola nera - spesso indicando sia un’eredità che una mancanza di fiducia nella loro unicità.

Integrazione & Coerenza dei Moduli (Impatto delle M&A)

La pianificazione della supply chain di solito copre diversi domini (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 è integrato il set di soluzioni di ciascun fornitore e quali segnali di pericolo emergono dalla loro strategia di crescita.

Blue Yonder (JDA) è il modello di crescita per acquisizione. Come indicato, è una “raccolta caotica” di prodotti di epoche diverse ²⁹. JDA ha acquisito i2 (che a sua volta aveva diversi moduli), ha acquisito Manugistics in precedenza, poi RedPrairie (per la gestione del magazzino), quindi la startup Blue Yonder per l’IA. Ogni pezzo aveva il proprio schema di database, la propria logica. Il risultato: anche oggi, la pianificazione della domanda, la pianificazione della fornitura e l’ottimizzazione dell’inventario di Blue Yonder potrebbero non condividere un modello di dati unificato - l’integrazione si basa su interfacce. Questo è un segnale di pericolo perché significa che implementare l’intera suite equivale essenzialmente ad integrare diversi pacchetti software distinti. Quando i prodotti di un fornitore non sono veramente unificati, i clienti si trovano di fronte a problemi come ritardi di sincronizzazione dei dati, interfacce utente non coerenti e funzionalità duplicate. Nel caso di Blue Yonder: alcuni dei suoi moduli si sovrappongono francamente (dopo le acquisizioni, potresti avere due modi per pianificare l’inventario - uno dall’eredità di Manugistics e uno da i2). L’azienda ha fatto sforzi per razionalizzare questo, ma non è completamente risolto. In termini tecnici, il software enterprise non si “mescola” magicamente come i fluidi quando le aziende si fondono ²⁹ - ci vogliono anni di rielaborazione. Non abbiamo visto prove che Blue Yonder abbia completato tale rielaborazione. Quindi, la mancanza di coerenza è un grave punto debole tecnico.
SAP IBP ha combinato componenti acquisite in modo simile: l’acquisto da parte di SAP di SAF, SmartOps e altri ha portato strumenti separati che SAP ha poi integrato nell’ombrello di IBP ²⁷. Gli utenti hanno notato che IBP ha moduli diversi che sembrano app separate (ad esempio, IBP per la Domanda vs. IBP per l’Inventario). La logica di ottimizzazione del stock di sicurezza in IBP probabilmente proviene dall’acquisizione di SmartOps, mentre il sensing della domanda potrebbe provenire da SAF o da sviluppi interni. L’integrazione è migliore rispetto a quella di Blue Yonder (SAP ha almeno riscritto l’interfaccia utente e ha messo tutto sul database HANA), ma ancora, sotto il cofano IBP non è un singolo codice. SAP avverte esplicitamente che implementare IBP di solito richiede diversi anni e integratori esperti per far funzionare tutti i moduli insieme in modo ottimale ²⁸. Quella dichiarazione è un segnale di pericolo di per sé - implica un potenziale mismatch e complessità.
Infor (anche se non è tra i primi 10 sopra) ha anche fuso vari sistemi di pianificazione (avevano 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 concentrarsi sui sistemi di esecuzione. Quindi è un altro esempio in cui l’acquisizione non ha prodotto un ottimo prodotto di pianificazione integrato.
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 che Quintiq continuasse come offerta autonoma focalizzata sull’ottimizzazione della produzione/pianificazione. Quindi, la coerenza interna di Quintiq è buona (è stata sviluppata internamente e rimane tale), ma il lato negativo è che non copre tutte le aree (ad esempio, non c’è una previsione della domanda nativa, come indicato ¹⁶). Il portfolio di Dassault ha altri prodotti (come Apriso per MES, ecc.), ma non sono integrati con Quintiq in modo profondo. Quindi, in termini di integrazione, Quintiq è autoconsistente ma funzionalmente limitato. Dal punto di vista dell’utente, potresti doverlo integrare con un altro strumento di previsione, il che significa un lavoro aggiuntivo dal lato del cliente.
Kinaxis è cresciuta principalmente organicamente - ha acquisito una piccola azienda di intelligenza artificiale Rubikloud nel 2020 (per l’IA nel settore del retail) e uno strumento di progettazione della supply chain (Castle Logistics) nel 2022, ma questi sono relativamente recenti e rimane da vedere come si integreranno. Storicamente, RapidResponse era un unico prodotto che gestiva vari aspetti della pianificazione attraverso la configurazione. Questa coerenza è un vantaggio: tutti i moduli (domanda, offerta, inventario) condividono un database e un’interfaccia utente in Kinaxis. Allo stesso modo, Anaplan ha sviluppato diversi “app” di pianificazione su una piattaforma unica - i piani di vendita, finanza, supply chain risiedono tutti nello stesso ambiente Hyperblock, che è tecnicamente molto coerente (solo modelli di template diversi). o9 Solutions è anche una piattaforma singola sviluppata organicamente che copre molte aree (non è cresciuta acquisendo altri fornitori di pianificazione, almeno non importanti). Quindi questi tre - Kinaxis, Anaplan, o9 - hanno un vantaggio architettonico di unità. La cautela con loro non riguarda l’integrazione di moduli disparati, ma se la loro piattaforma unica può gestire veramente la profondità in ciascun dominio.
ToolsGroup & Slimstock: Questi fornitori sono rimasti concentrati sul loro settore (pianificazione della domanda e dell’inventario). Non hanno realmente acquisito altre aziende; invece, si associano o si integrano con sistemi di esecuzione secondo necessità. Ciò significa che il loro software è internamente coerente (una base di codice), il che è positivo, ma se un cliente ha bisogno di capacità più ampie (come la pianificazione della produzione), deve utilizzare un altro prodotto e integrarlo da solo. ToolsGroup negli ultimi anni ha iniziato ad aggiungere funzionalità S&OP e ha persino acquisito una startup di intelligenza artificiale (Eramos nel 2018) per il machine learning, ma anche in questo caso sono stati integrati nel prodotto principale piuttosto che venduti separatamente. Quindi l’integrazione non è un grosso problema per ToolsGroup o Slimstock - il compromesso è se il loro design a singolo focus copre abbastanza ambito per le esigenze dell’utente.

Sommario sull’Integrazione: Da un punto di vista scettico, diverse acquisizioni importanti nella storia di un fornitore sono un segno di avvertimento. Spesso porta a un prodotto jack-of-all-trades che è maestro di nessuno, con complessità nascosta. Blue Yonder e SAP ne sono un esempio - la loro complessità tecnica deriva in parte dal tentativo di incollare insieme molti pezzi ereditati. Al contrario, i fornitori con una piattaforma unificata singola (sviluppata organicamente) evitano questi problemi, anche se devono comunque dimostrare che una piattaforma può fare tutto bene. Quando si valuta un software, si dovrebbe chiedere l’origine di ciascun modulo: Se il modulo di pianificazione della domanda e il modulo di pianificazione dell’offerta provengono da diverse aziende originali, indagare su come condividono i dati e se l’integrazione è senza soluzione di continuità o tramite interfaccia. La storia ha dimostrato che a meno che la tecnologia acquisita non sia stata riscritta da zero in un’architettura unificata (cosa rara a causa dei costi e del tempo), il risultato è di solito un sistema Frankenstein. La nostra ricerca rafforza questo concetto - i fornitori con i voti più alti in eleganza tecnica (Lokad, Kinaxis, Anaplan) hanno sviluppato le loro soluzioni in modo olistico, mentre quelli con i voti più bassi (Blue Yonder, Infor) hanno accumulato tecnologie disparate senza unificarle completamente.

Punti Deboli Critici e Segnali d’Allarme

Nella nostra rigorosa revisione, abbiamo identificato diversi punti deboli ricorrenti e segnali d’allarme di cui i potenziali utenti dovrebbero essere consapevoli. Di seguito è riassunto i principali problemi, con esempi da fornitori specifici per illustrare ciascun punto:

Affermazioni non supportate su “AI/ML”: Siate estremamente scettici nei confronti di qualsiasi fornitore che proclami una superiorità nell’AI o nell’apprendimento automatico senza evidenze tecniche concrete. Ad esempio, Blue Yonder pubblicizza pesantemente l’AI ma fornisce solo affermazioni vaghe e prive di sostanza ³⁰ - ciò che possiamo vedere dei loro metodi indica che si basano su tecniche più datate, non sull’AI all’avanguardia. Allo stesso modo, o9 Solutions esalta la sua intelligenza basata sull’AI e sui grafi, ma l’analisi del loro codice pubblico e dei materiali mostra “un sacco di hype sull’AI” con solo analisi pedonali nella realtà ²⁶. Se un fornitore non può indicare studi revisionati da pari, brevetti, competizioni o documenti tecnici dettagliati a supporto delle loro affermazioni sull’AI, si presume che sia solo un’esca di marketing. I fornitori genuinamente avanzati saranno orgogliosi di dettagliare i loro algoritmi.
Assenza di Benchmarking Competitivo (Affermazioni di superiorità nella previsione): Molti fornitori affermano di avere “accuratezza di previsione di classe mondiale” ma nessuno, a parte Lokad, lo ha dimostrato in competizioni aperte o pubblicazioni. Trattiamo qualsiasi affermazione del genere come falsa a meno che non sia validata. Ad esempio, l’algoritmo proprietario di un fornitore vantato come “più preciso degli altri” era assente dai primi posti della competizione M5 ³², il che suggerisce fortemente che la loro affermazione è infondata. Infatti, nessun tradizionale fornitore di software per la supply chain (tranne Lokad) è apparso nei primi 100 di quella competizione globale di previsione. Questo è un segnale d’allarme importante: implica che questi fornitori o non hanno partecipato (forse per evitare imbarazzi pubblici) o hanno partecipato e hanno ottenuto scarsi risultati. Consiglio pratico: Esigere di vedere risultati di accuratezza obiettivi (ad esempio, come si è comportato il loro strumento su un benchmark standard come il dataset M5 o M4) - se non possono fornirne, non comprate l’hype.
Eccessiva Estensione dell’Architettura In-Memory: I fornitori che spingono per un design completamente in-memory dovrebbero essere interrogati sulla scalabilità e sui costi. Il calcolo in-memory offre velocità, ma la RAM è ~100 volte più costosa per GB rispetto al disco ¹⁰ e il suo rapporto prezzo/prestazioni è stagnante negli ultimi anni ⁴². Ciò rende le soluzioni puramente in-memory non scalabili e costose per volumi di dati elevati. SAP IBP (HANA) e o9 ne sono esempi: garantiscono alte prestazioni solo se si caricano enormi set di dati in memoria, il che garantisce bollette hardware (o cloud) elevate ²⁴ ³¹. È significativo che il design dei sistemi moderni si stia allontanando da questo approccio - come sottolinea un esperto, la mania iniziale di inserire tutto nella RAM ha incontrato limiti pratici, e i database stanno “ritrovando l’amore per il disco” per gestire efficientemente i dati freddi ⁴³ ⁴⁴. Se un fornitore è ancora bloccato su una mentalità solo in-memory, consideratelo un segnale d’allarme architetturale. I fornitori più scalabili parleranno di storage a più livelli, elasticità cloud o strategie simili per gestire dati su larga scala senza richiedere RAM infinita.
Scatola Nera da M&A (Disfunzione di Integrazione): Se il pacchetto di prodotti di un fornitore è il risultato di molti acquisiti, state attenti a lacune di integrazione e funzionalità sovrapposte. Come abbiamo visto, il pacchetto di Blue Yonder è un mix caotico di prodotti datati a causa di una lunga serie di fusioni ²⁹, e i moduli di SAP IBP provengono da diverse aziende acquisite ²⁷, con conseguente complessità e una “raccolta” di strumenti anziché un insieme omogeneo. Il software enterprise non è facilmente “miscibile” attraverso M&A ²⁹ - a meno che il fornitore non abbia fatto una ristrutturazione completa (cosa rara e che richiede tempo), il cliente finisce spesso per agire come integratore tra i moduli. Ciò può significare esperienze utente inconsistenti, inserimento duplicato dei dati e interfacce fragili. Sintomo di segnale d’allarme: L’implementazione del fornitore richiede un battaglione di consulenti per un anno o più per far comunicare i moduli tra loro - come riconosciuto anche nel caso di SAP ²⁸. Preferite fornitori con una piattaforma unificata o con sovrapposizioni minime nei componenti acquisiti.
Metriche Contraddittorie e Parole Chiave: Un segnale d’allarme sottile ma significativo è quando la storia tecnica di un fornitore contiene contraddizioni interne o pratiche obsolete mascherate con nuovi termini. Un esempio lampante è stato ToolsGroup che pubblicizza previsioni probabilistiche mentre fa riferimento contemporaneamente a miglioramenti MAPE ¹⁹ - un segno che stanno semplicemente spargendo nuovi termini su vecchie pratiche (poiché utilizzare MAPE per giudicare previsioni probabilistiche è concettualmente sbagliato). Un altro esempio sono i fornitori che affermano di utilizzare “AI avanzata” ma poi misurano il successo con vecchie metriche come MAPE o livelli di servizio tradizionali - indica che non hanno veramente adottato il nuovo paradigma. Allo stesso modo, fate attenzione alle metodologie di stock di sicurezza: un fornitore potrebbe affermare di ottimizzare l’inventario con l’AI, ma se scavate e scoprite che calcolano ancora lo stock di sicurezza con una formula degli anni ‘80 (ad es. assunzione di distribuzione normale con un fattore di sicurezza statico), questa è una contraddizione. Abbiamo infatti trovato casi in cui i fornitori parlano di inventario “probabilistico” o “ottimale”, ma la loro documentazione rivela calcoli standard di stock di sicurezza e l’uso di metriche obsolete come il tasso di riempimento. Conclusione: Le incongruenze tra ciò che pubblicizzano e ciò che misurano/consegnano sono un segnale d’allarme. Se un fornitore si vanta di essere moderno e guidato dall’AI, ma utilizza gli stessi KPI e metodi di decenni fa, la loro innovazione è probabilmente superficiale.
Algoritmi e Pratiche Obsoleti: La teoria della supply chain è avanzata (ad es. da modelli deterministici a modelli stocastici, da ottimizzazione a singolo livello a ottimizzazione a multi-livello), ma alcuni software non sono stati aggiornati. Fidarsi di pratiche vecchie di decenni è un punto debole, specialmente se i fornitori fingono il contrario. Ad esempio, uno strumento che utilizza ancora principalmente la logica di stock di sicurezza + punto di riordino con tempi di consegna fissi per l’inventario è obsoleto se non tiene conto dinamicamente della variabilità della domanda. Abbiamo notato che Slimstock si concentra esplicitamente su formule tradizionali (stock di sicurezza, EOQ) ²¹ - sono trasparenti al riguardo, 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 ma non lo ammette. Un altro esempio: i frammenti open-source di Blue Yonder indicavano modelli ARMA ⁴⁸, che sono tecniche di previsione degli anni ‘70, anche se il loro materiale di vendita parla di AI. Infor, Oracle, John Galt e altri nella fascia inferiore spesso si affidano a metodi di serie temporali ed euristiche che esistono da sempre (come il liscio esponenziale di Winters, semplici risolutori di ottimizzazione) - quelli funzionano, ma non c’è nulla di moderno in essi. Il segnale d’allarme non è utilizzare vecchi metodi di per sé (i vecchi metodi possono ancora essere i migliori in alcuni casi), è utilizzarli mentre si afferma di essere innovativi, o utilizzarli esclusivamente 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 a multi-livello o solo calcoli a nodo singolo?”). Risposte evasive o vaghe indicano che la metodologia potrebbe essere datata.
Mancanza di trasparenza tecnica: Infine, un segnale di avvertimento meta: se un fornitore non fornisce alcuna documentazione tecnica - nessun white paper, nessuna architettura di riferimento, nessuna spiegazione degli algoritmi - questo è di per sé un segnale di avvertimento. Nella nostra ricerca, i fornitori che hanno ottenuto un punteggio elevato dal punto di vista tecnico (Lokad, Kinaxis, SAS, ecc.) hanno tutti almeno qualche contenuto tecnico disponibile (siano essi blog, articoli accademici o note tecniche). I fornitori che hanno ottenuto un punteggio basso spesso non hanno nulla oltre ai depliant di marketing. Ad esempio, cercate di trovare un dettagliato white paper tecnico da o9 o Blue Yonder - è quasi impossibile, si ottengono principalmente depliant lucidi. Lokad, al contrario, ha pubblicato uno studio di mercato dettagliato di 18 pagine (che abbiamo citato ampiamente) confrontando gli approcci dei fornitori ⁴⁹ ²⁹ ²⁵, oltre a video su come funzionano i loro algoritmi. Quando un fornitore è segreto su come funziona la loro soluzione, bisogna chiedersi se è perché non è effettivamente speciale. La trasparenza è correlata alla credibilità. Un fornitore che si nasconde dietro a parole di moda e non divulga i propri metodi probabilmente ha “tecnologia ordinaria con un po’ di rossetto in più”.

In conclusione, l’applicazione di una lente altamente scettica, incentrata sull’ingegneria rivela che molti software di ottimizzazione della supply chain “leader” sono ricchi di promesse e carenti di innovazioni verificabili. Tagliando attraverso la retorica di marketing, ci siamo concentrati su ciò che è tangibile: strutture dati, algoritmi, prestazioni e prova di efficacia. Le migliori soluzioni si sono distinte offrendo sostanza tecnica - accuratezza dimostrata nella previsione, scelte architettoniche chiare e documentazione sincera - mentre quelle più deboli si sono rivelate attraverso contraddizioni, vaghezza e fondamenta obsolete. Questo studio serve come promemoria per qualsiasi professionista della supply chain: non prendere le affermazioni dei fornitori alla lettera. Richiedi prove, guarda sotto il cofano e ricorda che nella supply chain, come in tutta l’IT, i veri progressi all’avanguardia sono di solito supportati dalla scienza aperta e dall’ingegneria solida - non solo da affermazioni di marketing altezzose.