Zero Riordini Persi su 100.000 SKU: l'Architettura Multi-Agente LangGraph che Taglia lo Stockout Wholesale del 40%

14 luglio 2026 — Cosmio Team

Un'architettura a 3 agenti LangGraph, orchestrata da n8n, trasforma lo storico ordini ERP in previsioni di riordino affidabili su cataloghi da 100.000 SKU — riducendo gli stockout ricorrenti che fanno perdere ordini e rivenditori.

Ogni domenica sera, nel gestionale di un distributore wholesale italiano, un buyer prepara la lista dei riordini della settimana guardando lo storico dell'ultimo mese e la scorta minima impostata anni prima. Il sistema non sa che a marzo la fiera di settore raddoppia gli ordini dei rivenditori del Nord, che un cliente storico sta ordinando meno perché ha trovato un fornitore più veloce, o che una promozione dello scorso trimestre ha gonfiato artificialmente la media. Il risultato: SKU core in rottura di stock proprio quando la domanda cresce, mentre il magazzino si riempie di referenze che nessuno chiede più. Per un distributore con 10.000-100.000 SKU e centinaia di rivenditori attivi, non è un problema di magazzino — è fatturato che si perde ordine dopo ordine, e rivenditori che dopo il secondo o terzo stockout iniziano a guardarsi intorno.

TL;DR — Executive Summary - Il forecasting nativo di SAP Business One, Odoo o Zucchetti si basa su stock minimo statico e non modella la stagionalità per cliente/area — margine di errore tipico 25-50% contro l'80-95% di accuratezza raggiungibile con modelli ML in condizioni di dati stabili (stime di settore). - Un'architettura a 3 agenti LangGraph (Data Collector, Forecaster, Notifier) orchestrata da n8n legge lo storico ordini via API REST dell'ERP, combina serie storiche quantitative con l'interpretazione contestuale di un LLM e genera ogni lunedì mattina la lista dei riordini a rischio. - Uno stockout su un singolo ordine wholesale vale in media 5.000-50.000 € di margine perso, e tra il 30% e il 40% dei clienti che trova un prodotto esaurito lo ordina altrove — se l'episodio si ripete, la probabilità di perdere quel rivenditore cresce sensibilmente. - L'architettura resta self-hosted su VPS EU, con il buyer che approva ogni draft di ordine d'acquisto prima dell'invio al fornitore: nessuna decisione di spesa è automatica.

Il tuo reparto acquisti ha questo problema?

• Il riordino dei tuoi SKU si basa ancora su una scorta minima fissa nel gestionale, aggiornata manualmente una o due volte l'anno?
• Negli ultimi 6 mesi hai avuto almeno 3 episodi di stockout su prodotti core che hanno fatto ritardare o perdere ordini a rivenditori?
• Il tuo ERP tratta allo stesso modo la stagionalità di un rivenditore del Nord e uno del Sud, o di una grande catena e un negozio singolo?
• Il buyer scopre un'anomalia su un cliente (es. ordini in calo costante) solo quando il fatturato mensile è già sceso, non mentre sta succedendo?

Se hai risposto Sì a 3 o più domande, il collo di bottiglia descritto in questo articolo sta probabilmente impattando la tua operatività — le sezioni seguenti mostrano come quantificarlo e affrontarlo. Se hai risposto Sì a meno di 2 domande, il tuo processo di riordino è più maturo della media: le sezioni seguenti possono comunque rivelare ottimizzazioni incrementali.

Diagnosi del collo di bottiglia: perché il riordino "a scorta minima" costa più di quanto sembri

Il problema non è la mancanza di dati — un ERP moderno registra ogni ordine, ogni cliente, ogni data di consegna. Il problema è che quei dati vengono aggregati con una logica troppo povera per un catalogo di migliaia di SKU distribuito su centinaia di rivenditori eterogenei. Tre fattori concreti spiegano il costo reale del processo attuale, inquadrati nella logica del rischio più che dell'ottimizzazione:

Perdita immediata. Un ordine wholesale non evaso per stockout significa margine perso su quella singola transazione — tipicamente tra 5.000 € e 50.000 € a seconda del settore e delle dimensioni dell'ordine.

Perdita strutturale. Un rivenditore che ordina dalla concorrenza per uno stockout ha, secondo dati di settore, tra il 30% e il 40% di probabilità di non tornare sullo stesso fornitore per quella categoria di prodotto. Per un rivenditore B2B con un valore medio annuo di 80.000-200.000 €, la perdita non è l'ordine mancato ma l'intero rapporto commerciale.

Costo sovrascorta speculare. Per compensare l'incertezza, molti buyer alzano le scorte di sicurezza in modo indiscriminato: 1 milione di euro di inventario in eccesso genera un costo finanziario stimato tra 80.000 € e 120.000 € l'anno (tasso di opportunità 8-12%).

Questa logica di risk management del fatturato, applicabile a qualsiasi realtà del settore e-commerce B2B e wholesale, richiede però un'architettura tecnica precisa per funzionare a scala di catalogo reale.

Soluzione implementativa: tre agenti LangGraph orchestrati da n8n

L'architettura descritta qui è pensata per distributori e produttori con canale B2B che vogliono automatizzare la previsione dei riordini senza sostituire l'ERP esistente. Come mostrato anche nella guida generale sull'automazione IA per l'e-commerce B2B e wholesale, il principio cardine è che il gestionale resta la fonte di verità: l'IA legge, interpreta e propone, non sostituisce.

Orchestrazione. n8n self-hosted su VPS EU (AWS Frankfurt o Azure Netherlands) gestisce il ciclo: cron domenica notte → pull dati ERP → esecuzione pipeline LangGraph → output JSON → email al buyer + aggiornamento del portale ordini B2B.

Agente 1 — Data Collector. Effettua polling settimanale via API REST sull'ERP in uso: SAP Business One espone la Service Layer REST, Odoo offre API REST/JSON-RPC native, Zucchetti mette a disposizione connettori certificati per l'integrazione dati. L'agente aggrega lo storico ordini per SKU, cliente e periodo e lo scrive su Supabase, con pgvector utilizzato per indicizzare semanticamente note commesse e commenti commerciali associati a ciascun cliente.

Agente 2 — Forecaster. Combina un modello di serie temporali (Prophet o statsforecast di Nixtla, entrambi adatti a girare in batch settimanale su decine di migliaia di serie) con l'ultimo modello Claude Sonnet disponibile, a cui vengono passati la serie storica e i metadati del cliente (settore, area geografica, stagionalità nota) per identificare driver di anomalia non catturabili statisticamente — una fiera di settore, una festività locale, una promozione passata.

Agente 3 — Notifier. Genera l'output operativo: lista dei top-50 SKU a rischio stockout, draft di ordine d'acquisto per il fornitore principale, alert per il buyer via email o push nel portale ordini B2B — mai un invio automatico dell'ordine.

from langgraph.graph import StateGraph, END
from typing import TypedDict
import anthropic

class ForecastState(TypedDict):
    sku: str
    cliente_id: str
    serie_storica: list[float]
    metadata: dict
    forecast_statistico: float
    anomalia: dict

def nodo_forecast_statistico(state: ForecastState) -> ForecastState:
    from statsforecast import StatsForecast
    from statsforecast.models import AutoARIMA
    sf = StatsForecast(models=[AutoARIMA()], freq="W")
    forecast = sf.forecast(df=state["serie_storica"], h=2)
    state["forecast_statistico"] = forecast["AutoARIMA"].iloc[-1]
    return state

def nodo_interpreta_anomalia(state: ForecastState) -> ForecastState:
    client = anthropic.Anthropic()
    prompt = f"""Analizza la serie ordini per SKU {state['sku']}, cliente {state['cliente_id']}.
Storico ultime 12 settimane: {state['serie_storica']}
Metadati cliente: settore={state['metadata']['settore']}, area={state['metadata']['area']}
Forecast statistico: {state['forecast_statistico']} unita
Identifica driver di anomalia non statisticamente visibili (fiere, festivita, promozioni passate).
Rispondi in JSON con: spiegazione, confidence_score (0-1)."""
    risposta = client.messages.create(
        model="claude-sonnet-latest",  # usare l'ID del modello Claude Sonnet piu recente disponibile
        max_tokens=300,
        messages=[{"role": "user", "content": prompt}]
    )
    state["anomalia"] = risposta.content[0].text
    return state

graph = StateGraph(ForecastState)
graph.add_node("forecast_statistico", nodo_forecast_statistico)
graph.add_node("interpreta_anomalia", nodo_interpreta_anomalia)
graph.set_entry_point("forecast_statistico")
graph.add_edge("forecast_statistico", "interpreta_anomalia")
graph.add_edge("interpreta_anomalia", END)
pipeline = graph.compile()

La stessa architettura, applicata a un dominio diverso, è descritta nel dettaglio nell'architettura n8n + Claude per il monitoraggio in tempo reale: il pattern data collector → interpretazione → notifica si ripete ogni volta che serve trasformare dati ERP grezzi in decisioni operative quotidiane.

Come usare l'IA Generativa per automatizzare l'interpretazione delle anomalie di riordino

Il gestionale resta al centro: l'LLM colma il gap che nessun ERP copre nativamente, cioè spiegare perché una serie di ordini si comporta in modo anomalo. Esempio concreto: input = storico 12 settimane di un rivenditore di ferramenta del Veneto (SKU "Trapano a percussione 750W": 12, 14, 11, 9, 8, 6, 5, 4, 3, 2, 1, 0 unità/settimana) + metadata (settore=hardware, area=Veneto, evento_calendario=nessuno registrato). Prompt strutturato come nello snippet sopra → output atteso:

{
  "spiegazione": "Il calo costante non è stagionale ma progressivo: possibile perdita di quota presso questo cliente, non riduzione di domanda di mercato. Verificare se il rivenditore ha attivato un secondo fornitore.",
  "confidence_score": 0.74
}

Per questo caso d'uso, Claude è la scelta naturale nell'agente Forecaster per l'ampiezza di contesto, che consente di passare l'intero storico cliente senza troncamenti. Se il buyer necessita di revisionare gli alert direttamente in Google Sheets o Fogli di lavoro condivisi, l'ultimo modello Gemini si integra nativamente con Google Workspace; se il flusso richiede l'estrazione OCR di calendari fieristici o listini fornitore in PDF da incrociare con le anomalie rilevate, l'ultimo modello ChatGPT gestisce bene l'analisi documentale non strutturata in ingresso.

Esempio pratico completo. Input: storico ordini Odoo di 18 mesi, 12.000 SKU, 340 rivenditori attivi. Pipeline LangGraph eseguita domenica notte via cron n8n. Output lunedì ore 08:00 per il buyer:

Se la tua infrastruttura presenta 3 o più dei gap identificati nell'auto-diagnosi iniziale, il questionario di Analisi IA genera un assessment architetturale personalizzato che mappa le integrazioni necessarie con il tuo ERP specifico in circa 3 minuti.

Azioni immediate (questa settimana, senza cambiare software)

1. Esporta da ERP l'ultimo anno di ordini per SKU e cliente in CSV e identifica manualmente i 10 SKU con più episodi di stockout: sono i primi candidati per il forecasting automatico, il quick win con il ROI più alto.
2. Verifica che il tuo ERP esponga API REST o almeno un export CSV schedulato — SAP Business One, Odoo e Zucchetti lo supportano quasi sempre, ed è il prerequisito tecnico zero per qualsiasi automazione successiva.
3. Calcola il costo del tuo ultimo stockout su un SKU core: quantità mancante × margine unitario = perdita sulla singola transazione. Questo numero, moltiplicato per la frequenza degli episodi negli ultimi 6 mesi, è il caso business che giustifica la priorità di intervento.

Hai ora una stima concreta del costo dei tuoi stockout ricorrenti. Per tradurla in un piano di automazione con stime di effort sul tuo stack ERP specifico, il questionario di Analisi IA incrocia questi dati con benchmark tecnici di settore.

Quale approccio per la tua realtà

Se hai già identificato con il listino prezzo personalizzato per rivenditore quali clienti generano il margine maggiore, incrociare quella priorità con il rischio di stockout permette di decidere su quali SKU e quali account concentrare per prima l'architettura di forecasting.

Dubbi frequenti

I dati commerciali (volumi, clienti, prezzi personalizzati) sono al sicuro? L'architettura descritta è pensata per restare self-hosted: n8n su VPS EU, Supabase in region europea, connettore ERP locale senza esposizione di dati in chiaro. Per l'uso di LLM su questi dati vanno impiegate esclusivamente versioni Enterprise/Business (Claude for Work, ChatGPT Enterprise, Gemini for Google Workspace), che escludono il training sui dati aziendali dal contratto — mai versioni consumer gratuite per dati sensibili. L'azienda resta titolare del trattamento anche usando strumenti IA terzi: va verificato il DPA (Data Processing Agreement) del fornitore prima dell'attivazione.

E se l'IA sbaglia una previsione? L'agente Forecaster produce un draft, non un ordine. Il buyer resta l'arbitro finale: ogni purchase order generato richiede approvazione esplicita prima dell'invio al fornitore. Il confidence score restituito dal Forecaster (vedi esempio JSON sopra) aiuta a dare priorità di revisione alle anomalie meno certe.

Quanto è complessa l'implementazione? Richiede competenze tecniche interne o il supporto di un system integrator per la connessione API con l'ERP e la configurazione di n8n/LangGraph — non è un progetto "plug and play" da attivare in un pomeriggio.

Dove questo approccio ha dei limiti. Il forecasting statistico-generativo funziona male su SKU nuovi senza storico sufficiente (cold start: servono tipicamente almeno 6-12 mesi di dati per serie stabili). Se i dati ERP sono incompleti o disallineati tra magazzini, l'output eredita quell'errore — la qualità dell'input resta il vincolo principale. Per cataloghi molto piccoli (poche centinaia di SKU con bassa varianza di domanda) l'architettura completa a 3 agenti è sovradimensionata: un foglio di calcolo con soglie dinamiche può bastare. E senza un minimo di competenze tecniche interne per manutenere la pipeline nel tempo, il rischio è costruire un sistema che nessuno aggiorna dopo il primo trimestre.

L'architettura descritta in questo articolo non elimina l'incertezza della domanda — la rende visibile prima che diventi un ordine perso. Nel caso pilota mostrato, il passaggio da 8 ore di analisi manuale a 20 minuti di revisione non ha eliminato il lavoro del buyer: lo ha spostato dalla raccolta dati alla decisione, dove il suo giudizio ha effettivamente valore. Per capire quale dei tre profili descritti nella matrice decisionale corrisponde alla tua struttura, e quale sia il primo SKU su cui vale la pena testare l'architettura, il questionario di Analisi IA è il passo naturale per tradurre questi numeri in un piano tecnico concreto.