Coverage group e metodi di copertura

Master planning fa una cosa sola: confronta la domanda (sales order, fabbisogni derivati dalla BOM, forecast, safety stock) con l’offerta già presente o già ordinata (on-hand, purchase order, production order e transfer order aperti) e traduce la differenza in planned order. Il coverage group è l’oggetto che decide come quella differenza viene calcolata e raggruppata, e il coverage code ne è il cuore:

  • Requirement: un planned order per ogni singolo fabbisogno, con pegging uno-a-uno fra domanda e fornitura. Massima tracciabilità, ordini frammentati; tipico di articoli di alto valore o gestiti su commessa.
  • Period: i fabbisogni che cadono nello stesso numero di giorni di copertura vengono aggregati in un unico ordine proposto. È il compromesso classico fra costo d’ordine e giacenza media.
  • Min/Max: la pianificazione non guarda il singolo fabbisogno ma la giacenza proiettata; quando scende sotto il minimo, propone di risalire fino al massimo. Adatto a materiale di consumo e domanda continua.
  • Manual: nessuna proposta automatica, decide il pianificatore.

Sul coverage group risiedono anche i time fence (coverage, action message, delay, freeze) e i parametri di tolleranza come positive days e negative days, che stabiliscono quanto la pianificazione si fida delle forniture già esistenti prima di crearne di nuove.

Il coverage group si assegna al released product, ma la granularità vera è l’item coverage: lì si definiscono impostazioni specifiche per combinazione di articolo, site, warehouse ed eventuali dimensioni, sovrascrivendo il default. È anche il punto in cui si dichiara il main warehouse: se un magazzino periferico deve essere rifornito da un deposito centrale invece che dal fornitore, la pianificazione genera planned transfer order al posto di planned purchase order. Stessa domanda, stesso coverage code, esito completamente diverso.

Master plan, forecast plan e previsione della domanda

Il master plan lavora sul netto: parte dalla domanda reale, sottrae giacenze e forniture in corso e propone il residuo. Il forecast plan lavora invece sulla previsione, per orizzonti lunghi e per capire il carico atteso su fornitori e capacità, senza pretendere di essere un piano esecutivo. Nei parametri di master planning si indicano quali piani sono correnti; il motore integrato distingueva inoltre un piano statico da uno dinamico, distinzione che con Planning Optimization perde rilevanza.

La previsione entra nel master plan attraverso un forecast model e un principio di riduzione: man mano che arrivano ordini reali, la domanda prevista viene consumata, altrimenti si pianifica due volte la stessa quantità. Demand forecasting genera la previsione a partire dallo storico e la espone come baseline da rivedere prima dell’autorizzazione.

Planned order: conferma, action message e delay

Il planned order è una proposta: esiste solo finché non viene rigenerato. Con la conferma (firming) diventa un ordine reale — purchase order, production order, transfer order o kanban — e da quel momento è un impegno. Un planned order può essere approvato per proteggerlo dalle riesecuzioni, oppure modificato in quantità e data prima della conferma.

Se sul coverage group sono abilitati i calcoli relativi, la pianificazione produce action message su ordini già esistenti (anticipa, posticipa, aumenta, riduci, annulla) e segnala i delay, cioè i fabbisogni che non possono essere soddisfatti entro la data richiesta. Sono suggerimenti: nessuno modifica automaticamente gli ordini già confermati.

Planning Optimization, il motore attuale

Planning Optimization è un servizio esterno che esegue il calcolo fuori dal database applicativo. Il vantaggio è operativo: run molto più rapidi, possibilità di ripianificare più volte al giorno e niente lock prolungati sulle tabelle. Il prezzo è che non tutte le funzionalità storiche sono supportate allo stesso modo; per questo esiste un’analisi di compatibilità (fit analysis) da eseguire prima dello switch, e la documentazione ufficiale resta l’unica fonte affidabile sull’elenco corrente delle funzionalità coperte.

Trappole tipiche d’esame

  • Domanda frequente e si vogliono meno ordini d’acquisto → coverage code Period: Requirement genera un ordine per ogni fabbisogno; solo il periodo di copertura aggrega più righe in un’unica fornitura.
  • Scorta da mantenere fra due soglie → Min/Max, non Requirement con quantità minima: la minimum quantity agisce come safety stock in qualunque coverage code, ma solo Min/Max riordina fino al livello massimo.
  • Magazzino rifornito dal deposito centrale → main warehouse nell’item coverage: senza quell’impostazione la pianificazione propone acquisti al fornitore invece dei planned transfer order attesi.
  • Il pianificatore non vede suggerimenti di anticipo o posticipo → action message da abilitare sul coverage group: non sono un output automatico e rispettano il proprio time fence.
  • Simulazione di scenario senza impatti sull’operatività → piano separato o forecast plan: eseguire il calcolo sul piano corrente sovrascrive le proposte su cui gli acquisti stanno già lavorando.
  • Le proposte spariscono alla riesecuzione → approvare o confermare il planned order: finché resta non approvato è materiale volatile, ricalcolato da zero a ogni run.