MTO vs ETO in D365 F&SCM: come scegliere il principio di produzione

Il sintomo: date promesse su cicli che non esistono

Il segnale classico è questo: il commerciale conferma una data di consegna calcolata dal sistema, poi la fase di ingegnerizzazione sposta tutto di settimane. Il cliente chiama, la produzione si giustifica, e la colpa finisce sul sistema. Ma il sistema non ha sbagliato niente: ha calcolato una data partendo dai dati che gli hai dato, cioè una distinta base e un ciclo dichiarati come definitivi quando definitivi non erano.

Ogni promessa di consegna in D365 poggia su dati di ciclo e distinta. Se quei dati sono provvisori, o peggio non esistono ancora, la data che ne esce è una finzione con i decimali. La scelta tra MTO ed ETO non è un dettaglio di configurazione: decide quali dati esistono nel momento in cui la promessa viene fatta.

MTO in D365: la vendita innesca la produzione, non la progettazione

Nel make-to-order la distinta base e il ciclo esistono già, approvati e rilasciati, prima che l'ordine arrivi. L'ordine di vendita genera il fabbisogno, la pianificazione crea l'ordine di produzione, e il prodotto viene fabbricato sulla base di dati tecnici stabili. È il flusso che Microsoft descrive tra i manufacturing principles di D365: la vendita innesca la produzione, non la progettazione.

D365 supporta questo flusso anche in forma automatizzata: la make-to-order supply automation crea e collega gli ordini di produzione pianificati direttamente dalle righe di vendita. Funziona bene per prodotti standard con varianti limitate, quando il lead time che il cliente accetta copre produzione e approvvigionamento. Non copre lo sviluppo, perché di sviluppo non ce n'è.

ETO in D365: prima il progetto, poi la produzione

L'engineer-to-order segue la logica opposta. Si parte da un progetto, non da un articolo a catalogo. La distinta base e il ciclo nascono durante la fase di ingegnerizzazione, e solo quando quella fase produce dati tecnici rilasciati si può parlare di ordini di produzione. Il glossario dei processi di business di Microsoft è esplicito su questa sequenza: nell'ETO la progettazione fa parte dell'evasione dell'ordine.

Le conseguenze operative sono concrete: gestione a commessa, versioni di distinta che evolvono durante il lavoro, costi tracciati sul progetto, e date di consegna difendibili solo dopo che l'ingegnerizzazione ha consolidato distinta e ciclo. Trattare un prodotto ETO con logica MTO significa saltare questa fase sulla carta, mai nella realtà: il tempo di progettazione non sparisce, semplicemente non è più visibile al sistema.

Il framework: quattro domande prima di configurare

Il criterio che conta non è la complessità del prodotto. Un prodotto complicatissimo può essere MTO se la sua distinta è nota e stabile; un prodotto semplice può essere ETO se ogni commessa la ridisegna. Prima di scegliere il principio di produzione in D365, rispondo a quattro domande:

• Quanta parte della distinta base conosci prima che l'ordine arrivi? Se la risposta è "quasi tutta", sei in territorio MTO. Se è "dipende dal progetto", no.
• Il lead time che il cliente accetta copre solo produzione e approvvigionamento, o deve coprire anche la progettazione? Se l'ingegnerizzazione consuma il lead time, sei in ETO.
• Il ciclo di produzione esiste già nel momento in cui il commerciale promette la data? Se la data viene promessa prima del ciclo, il sistema non può difenderla.
• La risposta alle tre domande precedenti cambia da un ordine all'altro? Se sì, non stai scegliendo un'impostazione: hai due modelli di business nello stesso catalogo.

Quando MTO va benissimo, e quando il problema non è il sistema

Non tutto ciò che sembra su misura è ETO. Se le varianti del prodotto sono combinazioni note di opzioni predefinite, il territorio è quello del configure-to-order: la distinta si genera da regole di configurazione, non da una fase di ingegnerizzazione. In questi casi impostare un flusso ETO aggiunge burocrazia di progetto senza aggiungere controllo.

Vale anche il contrario onesto: l'ETO ha un costo. Richiede disciplina di progetto, gestione delle versioni di distinta, integrazione tra ingegneria e produzione. Se le commesse veramente progettate sono poche l'anno, spesso conviene gestirle come eccezioni controllate invece di ribaltare il modello operativo di tutto il catalogo.

E c'è un limite che nessuna configurazione supera: se il processo commerciale promette date prima che l'ingegnerizzazione sia finita, nessun principio di produzione in D365 rende quelle date affidabili. Il sistema riflette il modello di business; non lo corregge.

Da dove partire

Il punto di partenza non è la configurazione, è il catalogo. Per ogni famiglia di articoli, misura quanta parte della distinta è nota prima dell'ordine e confronta il tempo di ingegnerizzazione reale con il lead time che i clienti accettano. Da lì la classificazione emerge da sola: MTO vero, ETO vero, e la fascia ibrida che è quella dove si nascondono i problemi.

Per gli ibridi la decisione va presa caso per caso, ma va presa: un articolo venduto come MTO che si comporta come ETO produrrà date non mantenute finché qualcuno non decide quale dei due è. Solo dopo questa classificazione ha senso aprire D365 e configurare i principi di produzione. Farlo prima significa scegliere l'impostazione più familiare, non quella giusta.