Migliorare le prestazioni del motore di programmazione

Il motore di pianificazione delle risorse pianifica le route per gli ordini di produzione pianificati e rilasciati.

Il problema di pianificazione in officina è un problema combinatorio estremamente complesso in cui il tempo di soluzione cresce esponenzialmente con il numero di variabili decisionali. I clienti spesso configurano route di produzione e dati correlati in modi che creano problemi di pianificazione che non sono risolvibili in tempo ragionevole, anche su hardware moderno. Questo articolo illustra il motore di pianificazione e il modo in cui una configurazione specifica influisce sulle prestazioni.

Migliorare le prestazioni di pianificazione riducendo la complessità del problema risolto dal motore. Alcuni dei principali fattori che possono influire sulle prestazioni sono:

• Cicli di lavorazione con molte operazioni
• Cicli di lavorazione con operazioni parallele
• Operazioni con più di una risorsa
• Operazioni con molte risorse applicabili
• Uso di collegamenti rigidi
• Uso di una capacità limitata
• Numero di calendari diversi utilizzati
• Numero di fasce orarie lavorative al giorno nel calendario
• La durata totale del ciclo di lavorazione
• Esecuzione di più motori di pianificazione in parallelo

Panoramica del flusso di pianificazione di base

Per comprendere in che modo una determinata configurazione influisce sulle prestazioni, è necessario conoscere il flusso del processo all'interno del motore e nel codice X++ che lo circonda.

Il processo di base della pianificazione di un ordine comporta tre passaggi principali:

• Caricamento dei dati : i modelli di dati X++ si trasformano nel modello di dati interno del motore come processi e vincoli.
• Pianificazione: il motore elabora il modello e i vincoli specificati per generare un risultato. Richiede informazioni sul tempo di lavoro e prenotazioni di capacità esistenti da X++ in base alle esigenze.
• Salva dati – il codice X++ elabora il risultato del motore, sotto forma di slot di prenotazione di capacità lavorativa, per salvare le prenotazioni di capacità e aggiornare gli orari di inizio e fine dei processi, delle operazioni o dell'ordine.

Caricare i dati nel motore

Il motore di pianificazione usa un modello di dati più astratto rispetto al database Gestione Supply Chain perché si tratta di un motore generico che gestisce più origini dati. I concetti di percorso, operazioni secondarie e tempo di esecuzione vengono convertiti nel modello di lavoro e vincolo generico esposto dal motore. La logica per la compilazione del modello include una logica di business significativa e varia a seconda dei dati di origine. La classe X++ responsabile è WrkCtrScheduler, che include classi derivate per gli ordini di produzione pianificati, gli ordini di produzione rilasciati e le previsioni di progetto.

Si consideri, ad esempio, una route illustrata nella tabella e nell'immagine seguente, relativamente semplice.

Quando inviate questo percorso al motore, il percorso viene suddiviso in otto attività, come illustrato nella figura seguente (selezionare l'immagine per ingrandirla).

Il collegamento standard tra due processi è FinishStart, ovvero l'ora di fine di un processo deve verificarsi prima dell'ora di inizio di un altro. L'installazione deve essere eseguita dalla stessa risorsa che in un secondo momento gestisce il processo, quindi esistono OnSameResource vincoli tra di essi. Tra i compiti relativi all'operazione primaria e secondaria per 10, ci sono i collegamenti StartStart e FinishFinish, il che significa che i compiti devono essere avviati e terminare contemporaneamente. Inoltre, esistono NotOnSameResource vincoli che impediscono l'uso della stessa risorsa sia per le operazioni primarie che secondarie.

Per l'operazione 20, in cui la quantità di risorse è impostata su 3, il processo viene suddiviso in tre processi distinti in cui tutti i processi devono essere eseguiti contemporaneamente. In questo caso, il gruppo di route viene configurato in modo da non riservare capacità per la coda dopo gli orari, motivo per cui è presente un solo processo per la coda dopo.

Il motore di pianificazione comprende solo i concetti di attività e non riconosce le operazioni. Questa limitazione significa che durante la pianificazione delle operazioni, il sistema suddivide le operazioni in processi, anche se questi processi non sono persistenti nel database.

Per ogni processo, si definisce il requisito di capacità del processo (il numero di secondi necessari). A seconda del modo in cui vengono definiti i requisiti delle risorse, è anche possibile inviare, per ogni processo, un elenco di tutte le risorse potenziali applicabili su cui il processo potrebbe essere eseguito e il requisito di capacità per tale risorsa specifica. Anche se si invia l'elenco delle risorse applicabili durante la compilazione del modello, il motore garantisce che l'assegnazione di risorse rimanga valida per l'intera durata del processo.

Componenti interni del motore di pianificazione

Interfaccia del motore di pianificazione

Per comprendere il funzionamento interno del motore, esaminare le funzionalità esposte esternamente. In X++, l'interfaccia principale è WrkCtrSchedulerEngineInterface. Questa interfaccia comporta i metodi descritti nelle sottosezioni seguenti.

Motore generale

Singoli processi

Vincoli tra processi

Risolutore

Il motore è un risolutore di vincoli specializzato con euristica personalizzata. Il risolutore si basa su due elementi principali: variabili e vincoli.

Variable

Una variabile rappresenta un dominio di possibili valori. Il motore di pianificazione ha due tipi di variabili:

• Variabile DateTime : include un dominio di tutte le date e le ore. È possibile limitare il dominio spostando i limiti inferiori e superiori per il tempo della variabile più vicina l'uno all'altro.
• Variabile di risorsa : dispone di un dominio di risorse applicabili. È possibile limitare il dominio eliminando le risorse dall'elenco.

Constraint

Un vincolo agisce sulle variabili limitando i domini. Dipende anche dalle variabili, quindi viene attivato quando le variabili cambiano. Il processo di "propagazione del vincolo" avviene quando un vincolo svolge la sua funzione principale e, in caso di operazione riuscita, lo segnala alla logica principale.

Una variabile viene considerata associata quando non può essere ulteriormente limitata. Per una variabile DateTime, questa condizione indica che i limiti superiori e inferiori sono uguali. Per la variabile Resource significa che ha solo una singola risorsa applicabile. Quando tutte le variabili sono associate, viene trovata una soluzione.

Livelli di vincolo

Quando la pianificazione fa parte della fase di pianificazione dei requisiti materiali (MRP), il sistema pianifica gli ordini indietro rispetto alla data del requisito. Tuttavia, se il sistema non riesce a trovare una schedulazione che inizi oggi o successivamente e termini prima della data del requisito, modifica la direzione della schedulazione in avanti a partire da oggi.

Il sistema organizza i vincoli in livelli per gestire questa regola business principale. Se il sistema non trova una soluzione quando si usano i vincoli al livello più alto, elimina tutti i vincoli a tale livello e prova il livello inferiore. In pratica, questo processo significa che per la pianificazione all'indietro, il modello contiene un livello 1 con gli obiettivi di lavoro dell'ora di inizio più recente in base a un vincolo di ora di fine massimo (data di richiesta) e un livello 0 con obiettivi di fine più prossima e con il vincolo di ora di inizio minima fissato a oggi.

Algoritmo

I passaggi principali dell'algoritmo del motore sono:

1. Trovare sequenze (catene di processi) che possono essere risolte separatamente.
2. Provare a trovare una soluzione iniziale per la sequenza al livello di vincolo più alto.
   1. Ordinare i lavori nella sequenza in base agli obiettivi e alle priorità dei lavori, in modo che il sistema possa trovare il primo lavoro.
   2. Scorrere le attività nella sequenza seguente:
      1. Trovare tutti i vincoli che devono essere propagati ed eseguire la propagazione.
      2. Se tutte le variabili per il processo sono associate, viene trovata una soluzione per tale processo.
      3. Se una delle variabili non può essere associata senza violare i vincoli, eseguire il rollback dell'associazione di variabili, provare un valore diverso nel dominio (per la variabile di risorsa) ed eseguire di nuovo la propagazione del vincolo.
3. Se non viene trovata alcuna soluzione, rimuovere tutti i vincoli a livello di vincolo corrente, abbassare il livello di vincolo (se sono disponibili livelli inferiori) e ripetere la ricerca della soluzione con il nuovo set di vincoli.
4. Se viene trovata una soluzione fattibile, avviare la fase di ottimizzazione, che tenta di trovare una soluzione migliore fino a quando non viene raggiunto il timeout di ottimizzazione o che tutte le combinazioni di risorse vengono esaurite.

Il risolutore di vincoli non tiene conto delle specifiche dell'algoritmo di pianificazione. La "magia" si verifica nella definizione e nella combinazione dei vari vincoli.

Determinazione degli orari di lavoro

La maggior parte dei vincoli (interni) nel motore controlla l'orario di lavoro e la capacità di una risorsa. Essenzialmente, l'attività consiste nell'attraversare gli intervalli di tempo di lavoro per una risorsa, partendo da un determinato punto in una specifica direzione, e trovare un intervallo sufficientemente lungo nel quale si possa inserire la capacità richiesta (tempo) dell'attività.

A questo proposito, il motore deve conoscere gli orari di lavoro di una risorsa. A differenza dei dati del modello principale, i tempi di lavoro vengono caricati con lazy loading, il che significa che vengono caricati nel motore in base alle esigenze. Il motivo di questo approccio è che spesso, nel Gestione Supply Chain, ci sono orari di lavoro pianificati per lunghi periodi, e tipicamente esistono molti calendari, il che rende i dati piuttosto voluminosi da precaricare.

Il motore richiede informazioni sul calendario in blocchi richiamando il metodo WrkCtrSchedulingInteropDataProvider.getWorkingTimesdella classe X++. La richiesta riguarda è un ID calendario specifico in un intervallo di tempo specifico. A seconda dello stato della cache del server in Gestione Supply Chain, ognuna di queste richieste può finire in diverse chiamate di database, il che richiede molto tempo (rispetto al tempo di calcolo puro). Inoltre, se il calendario contiene definizioni di orario di lavoro molto elaborate con molti intervalli di tempo lavorativo al giorno, questa complessità aggiunge al tempo necessario per il caricamento.

Quando il motore di pianificazione carica i dati sul tempo di lavoro, conserva questi dati nella cache interna per il calendario specifico. Questa conservazione significa che, se altri processi o risorse usano lo stesso calendario, le ricerche successive possono essere eseguite rapidamente dalla memoria. Una causa comune di prestazioni non ottimali è l'uso di un ID calendario separato per ogni risorsa, perché i dati vengono quindi richiesti per ogni calendario, anche se il contenuto dei calendari potrebbe essere lo stesso.

Capacità limitata

Quando si usa la capacità limitata, il sistema divide e riduce gli intervalli di tempo lavorativi dal calendario in base alle prenotazioni di capacità esistenti. La stessa WrkCtrSchedulingInteropDataProvider classe recupera queste prenotazioni insieme ai calendari, ma usa il getCapacityReservations metodo . Durante la pianificazione principale, il sistema considera le prenotazioni per lo specifico piano master. Se si abilita l'impostazione nella pagina Parametri di pianificazione generale, il sistema include anche prenotazioni dagli ordini di produzione confermati. Analogamente, quando si pianifica un ordine di produzione, è possibile scegliere di includere riservazioni da ordini pianificati esistenti, anche se questa sequenza non è comune quanto viceversa.

La pianificazione richiede più tempo quando si usa la capacità limitata per diversi motivi:

• Il recupero delle informazioni sulla capacità dal database è un'operazione lenta. La memorizzazione nella cache lato server delle informazioni sulla capacità in genere non è ottimale per i tempi di lavoro perché non vengono condivisi tra risorse come i calendari.
• Il numero di fasce orarie di lavoro da attraversare aumenta a causa delle divisioni. Il sistema deve in genere analizzare gli slot per un periodo di tempo più lungo prima di trovare una soluzione.
• Al termine della pianificazione, il sistema deve verificare la presenza di prenotazioni in conflitto (vedere la sezione "Esecuzione di motori di pianificazione in parallelo" per informazioni dettagliate).

Esame delle combinazioni di risorse

Se la sequenza di processo contiene solo i collegamenti standard FinishStart , ovvero forma una catena semplice senza rami, il sistema può ottenere un risultato ottimale (visto dall'ordine singolo, non tra gli ordini) trovando la soluzione migliore per il primo processo e quindi passando a trovare la soluzione migliore per il processo successivo. La soluzione migliore per un lavoro consiste nel trovare la risorsa che può ottenere le date di inizio e fine del lavoro più vicino possibile all'obiettivo del lavoro (che nella pianificazione anticipata significa ottenere la data finale del lavoro il prima possibile), rispettando comunque i vincoli.

Quando sono presenti processi paralleli, la ricerca di una soluzione potrebbe comportare l'analisi di diverse combinazioni di risorse. Il numero di possibili combinazioni di risorse è il prodotto del numero di risorse applicabili per i lavori paralleli connessi. Soprattutto quando si pianifica un ordine a ritroso partendo da una data di consegna, la logica può impiegare parecchio tempo per capire che non esiste una soluzione al problema che faccia sì che i processi paralleli si adattino prima della data odierna. La logica deve controllare tutte le combinazioni perché potrebbero esserci alcune risorse con un'efficienza maggiore o un calendario diverso che potrebbe dare un risultato. Questa condizione significa che se non si imposta un limite di timeout, il processo viene eseguito per molto tempo prima di modificare la direzione in avanti.

Questa logica combinatoriale significa anche che l'aggiunta di altre risorse applicabili potrebbe rallentare l'esecuzione del motore. È possibile risolvere parzialmente i problemi di prestazioni che si verificano quando si hanno operazioni parallele e pianificazione con capacità infinita facendo in modo che il progettista di percorsi prenda una decisione su quale risorsa deve essere usata e poi assegni la risorsa direttamente nell'operazione (poiché il motore tende comunque a scegliere sempre la stessa risorsa, quindi il risultato finale è lo stesso).

Collegamenti reali

Quando si imposta come fisso il tipo di collegamento tra due processi, si garantisce che non vi sia un gap di tempo tra la fine di un processo e l'inizio di quello successivo. Questa condizione è utile negli scenari in cui il metallo viene riscaldato in un unico processo ed elaborato nel successivo e il raffreddamento tra i processi non è auspicabile.

Usando i collegamenti simbolici standard e la pianificazione anticipata, se la route costituisce una catena semplice senza rami, è possibile ottenere un risultato trovando una soluzione per il primo processo che soddisfa i propri vincoli, quindi procedendo lungo la catena propagando l'ora di fine dal processo precedente a quello successivo. Se il processo corrente non riesce a trovare alcuna capacità, il sistema sposta ulteriormente l'orario di inizio, senza alcuna conseguenza per i processi precedenti. Questa azione può potenzialmente creare lacune tra i compiti. Tuttavia, usando collegamenti rigidi (soprattutto in relazione alla capacità limitata) per lo stesso scenario, il fatto che un processo successivo nella catena non riesca a trovare capacità, significa che tutti i processi pianificati precedenti devono essere "trascinati" uno per uno e quindi riprogrammati più volte. In particolare negli scenari con carico elevato per più risorse, i collegamenti rigidi possono causare una reazione a catena in cui i processi influiscono l'uno sull'altro e diverse iterazioni devono essere eseguite prima che il risultato si stabilizza in una pianificazione fattibile.

Esecuzione di motori di pianificazione in parallelo

Quando si esegue la pianificazione come parte di un'esecuzione del ciclo di pianificazione master in cui si usano helper, ognuno dei thread helper di pianificazione master gestisce anche le attività di pianificazione degli ordini di produzione. Questo approccio significa che più motori di pianificazione possono essere eseguiti contemporaneamente. Anche se il multithreading offre un significativo vantaggio in termini di prestazioni, introduce anche alcuni svantaggi funzionali per la pianificazione.

In MRP, il sistema pianifica tutti gli ordini di produzione per un determinato livello di distinta base in ordine di data di esigenza. Questa sequenza indica che il sistema pianifica prima gli ordini con la data del requisito meno recente, quindi ha la più alta probabilità di ottenere la capacità di risorse disponibile. Tuttavia, quando più motori di calcolo selezionano dall'elenco di ordini non pianificati, la sequenza non viene garantita perché un motore di calcolo potrebbe completare più velocemente rispetto all'altro.

Quando si pianifica con capacità limitata e più istanze del motore, può verificarsi una race condition se si tenta di pianificare gli ordini che usano le stesse risorse contemporaneamente. Il campo Conflitti di pianificazione nella pagina della cronologia dei piani master registra il numero di condizioni di competizione. La logica di risoluzione dei conflitti segue questa procedura:

1. Pianificare un ordine (senza blocco) e ottenere prenotazioni della capacità.
2. Applicare il blocco.
3. Controllare se esistono prenotazioni di capacità più recenti per le risorse pianificate nell'intervallo di tempo.
   • Se non esistono, scrivere la capacità e rilasciare il blocco.
   • Se esistono, rilasciare il blocco e ripianificare l'ordine dall'inizio.

Durante la pianificazione con più istanze del motore, il risultato non è completamente deterministico perché dipende dalla tempistica esatta di ogni thread.

Prestazioni di pianificazione delle operazioni

La programmazione delle operazioni, nota anche come pianificazione approssimativa della capacità, può essere più complessa da gestire dal punto di vista dell'elaborazione interna se si utilizza la capacità finita, perché sono necessari più dati per determinare la fattibilità.

La capacità di un gruppo di risorse dipende da quali e quante risorse sono membri del gruppo di risorse. Un gruppo di risorse stesso non ha capacità, ma solo quando le risorse sono membri del gruppo hanno capacità. Poiché l'appartenenza al gruppo di risorse può variare nel tempo, la capacità deve essere valutata ogni giorno.

Nella pianificazione delle operazioni, il calendario del gruppo di risorse viene utilizzato per determinare l'ora di inizio e di fine di ciascuna operazione. Questo calendario prevede un limite per quanto tempo è possibile pianificare le operazioni per un'operazione un giorno in un gruppo di risorse. A differenza del calendario per risorse specifiche, i dati di efficienza del calendario del gruppo di risorse vengono ignorati perché indicano solo le ore di apertura, non la capacità effettiva.

Ad esempio, se l'orario di lavoro per un gruppo di risorse in una data specifica è compreso tra le 8.00 e le 16.00, un'operazione non può mettere più carico sul gruppo di risorse rispetto a quello che può rientrare in 8 ore, indipendentemente dalla capacità che il gruppo di risorse ha disponibile in totale in quel giorno. Tuttavia, la capacità disponibile può limitare ulteriormente il carico.

Il carico di pianificazione su tutte le risorse del gruppo di risorse per un determinato giorno è tenuto in considerazione nel calcolo della capacità disponibile per quel giorno. Per ogni data, il calcolo è:

Capacità disponibile del gruppo di risorse = Capacità per le risorse nel gruppo in base al loro calendario − Carico pianificato del lavoro sulle risorse nel gruppo − Carico pianificato delle operazioni sulle risorse nel gruppo − Carico pianificato delle operazioni sul gruppo di risorse

Nella scheda Requisiti risorsa dell'operazione di route è possibile specificare i requisiti delle risorse usando una risorsa specifica (nel qual caso l'operazione è pianificata usando tale risorsa), un gruppo di risorse, un tipo di risorsa o una o più funzionalità, competenze, corso o certificato. L'uso di tutte queste opzioni offre flessibilità nella progettazione delle route, ma complica la pianificazione per il motore perché la capacità deve essere considerata per "proprietà" (un nome astratto usato nel motore per funzionalità, competenze e così via).

La capacità del gruppo di risorse per una funzionalità è la somma della capacità per tutte le risorse nel gruppo di risorse che hanno la funzionalità in questione. Se una risorsa nel gruppo ha una funzionalità, il motore lo considera indipendentemente dal livello di capacità richiesto.

Nella pianificazione delle operazioni, la capacità disponibile per una determinata funzionalità per un gruppo di risorse viene ridotta quando viene caricata con un'operazione che richiede la funzionalità in questione. Se l'operazione richiede più funzionalità, la capacità viene ridotta per tutte le funzionalità necessarie.

Per ogni data, il calcolo necessario è:

Capacità disponibile per una funzionalità = Capacità per la funzionalità − Carico pianificato del processo sulle risorse con la funzionalità specifica, incluso nel gruppo di risorse − Caricamento pianificato delle operazioni sulle risorse con la funzionalità specifica, incluso nel gruppo di risorse − Carico pianificato sul gruppo di risorse stesso che richiede la funzionalità specifica

Se una risorsa specifica ha un carico, il motore lo considera quando si calcola la capacità disponibile del gruppo di risorse per ogni funzionalità perché il carico riduce il contributo alla capacità del gruppo, indipendentemente dal fatto che il carico sia per tale funzionalità specifica. Se il carico è a livello di gruppo di risorse, il motore lo considera nel calcolo della capacità disponibile del gruppo di risorse per funzionalità solo se il carico proviene da un'operazione che richiede la funzionalità specifica.

Questa logica si applica a ogni tipo di proprietà, quindi l'uso della pianificazione delle operazioni con capacità limitata richiede il caricamento di una quantità significativa di dati.

Migliorare le prestazioni MRP

Il video della conferenza tecnica seguente fornisce suggerimenti per migliorare le prestazioni della pianificazione principale quando si usa MRP con il motore di pianificazione principale deprecato: Aiuto! MRP è lento!

Visualizzazione di input e output del motore di pianificazione

Per ottenere dettagli specifici sull'input e l'output del processo di pianificazione, abilita la registrazione passando a Amministrazione organizzazione>Impostazione>Pianificazione>Tracciamento pianificazione.

In questa pagina selezionare Abilita registrazione nel riquadro azioni e quindi eseguire la pianificazione per l'ordine di produzione. Al termine, torna alla pagina Pannello di controllo tracciatura di programmazione e seleziona Disabilita registrazione nel riquadro azioni. Aggiornare la pagina e nella griglia viene visualizzata una nuova riga. Selezionare la nuova riga e quindi selezionare Scarica nel riquadro azioni. Questa azione fornisce una .zip cartella compressa contenente i file seguenti:

• Log.txt : questo file di log descrive i passaggi che il motore esegue. La configurazione è dettagliata e può essere travolgente, ma quando si sperimenta la configurazione del percorso per risolvere i problemi di prestazioni, osserva la differenza di tempo tra la prima e l'ultima riga. Questa differenza mostra l'ora esatta impiegata dal schedulatore.
• XmlModel.xml : questo file contiene il modello compilato in X++ e su cui opera il motore. Il JobId utilizzato nel file è correlato al RecId nella tabella di origine contenente i processi (ReqRouteJob oProdRouteJob). In questo file verificare che le date in ConstraintJobStartsAt e ConstraintJobEndsAt siano come previsto, che la JobGoal proprietà sia impostata correttamente e che i processi siano correlati tramite i JobLink vincoli.
• XmlSlots.xml : questo file contiene tutti i tempi di lavoro e le prenotazioni di capacità richieste dal motore. I tempi di lavoro e le prenotazioni del calendario vengono richiesti solo dal motore di pianificazione per i periodi di tempo in cui tenta di inserire le attività (e un buffer aggiuntivo), quindi se il file contiene tempi molto proiettati nel futuro, potrebbe essere un'indicazione di un problema con la configurazione. I ResourceProperty nodi visualizzano il gruppo di risorse e le funzionalità associate a ogni risorsa, insieme ai periodi di tempo pertinenti.
• Result.xml : questo file contiene il risultato dell'esecuzione della pianificazione.

La funzionalità di traccia comporta un sovraccarico significativo delle prestazioni, quindi usarlo solo per analizzare la pianificazione di ordini specifici in modo controllato. Se lo attivi durante un'esecuzione del piano principale, raggiunge rapidamente il limite di dimensioni e si arresta.

Risoluzione dei problemi relativi alle prestazioni

Come si può notare nelle sezioni precedenti, alcune insidie nella configurazione e nell'utilizzo del motore di pianificazione possono causare problemi di prestazioni. L'elenco di controllo seguente consente di risolvere questi problemi. Esaminare tutti i punti perché spesso è una combinazione di più fattori che portano a problemi.

Esecuzione della pianificazione come parte di MRP quando non è necessaria

Anche se i percorsi vengono usati per scopi di controllo della produzione, come il calcolo dei costi e la generazione di report, potrebbero non essere presi in considerazione durante il calcolo dell'MRP. In alcuni casi, per la pianificazione sarà sufficiente avere un lead time di produzione standard specificato per l'articolo. Impostare il limite di tempo di capacità su zero per disattivare la pianificazione delle route. Se è necessaria la pianificazione, impostare attentamente la finestra temporale di capacità perché i percorsi potrebbero non essere presi in considerazione per l'intera durata della finestra di copertura dell'MRP.

Se l'ordine non è programmato durante l'MRP, dovrà invece essere pianificato quando il piano di ordine viene confermato. Ciò significa che il processo di stabilizzazione richiederà più tempo, quindi a seconda di quanti degli ordini pianificati suggeriti vengono stabilizzati, il miglioramento delle prestazioni durante la pianificazione MRP potrebbe essere annullato durante la stabilizzazione.

Ciclo di lavorazione con operazioni non necessarie

Quando si progetta il percorso, evitate di replicare esattamente il mondo reale con tutti i passaggi che il processo di produzione attraversa. Anche se questo approccio può essere utile in alcuni casi, non è ottimale per le prestazioni perché il modello del motore aumenta di dimensioni maggiori (in termini di processi e vincoli) e vengono eseguite più istruzioni SQL per inserire e aggiornare processi e prenotazioni di capacità. Inoltre, c'è l'effetto downstream di dover infine segnalare lo stato di avanzamento dei lavori, che le registrazioni automatiche possono attenuare. Se i dati non vengono usati per nulla, crea un carico non necessario.

Creare solo le operazioni strettamente necessarie per la pianificazione (in genere le risorse colli di bottiglia) o per scopi di costificazione. Raggruppare invece molte operazioni distinte più piccole in un'operazione più grande che rappresenta una parte maggiore del processo.

Molte risorse applicabili per un'operazione

I requisiti delle risorse impostati sulla relazione operativa determinano il numero di risorse applicabili per un'operazione. Il requisito può essere per una risorsa specifica oppure può essere basato sull'appartenenza della risorsa a un gruppo di risorse o a una funzionalità.

Se non si usa la capacità limitata per la pianificazione e tutte le risorse applicabili hanno lo stesso calendario e la stessa efficienza, il motore di pianificazione seleziona sempre la stessa risorsa per un'operazione, ma solo dopo aver provato tutte le risorse applicabili per verificare se c'è uno migliore degli altri. In questo caso, è possibile ridurre notevolmente il carico della pianificazione assegnando sempre una risorsa specifica all'operazione in fase di progettazione della route.

Ciclo di lavorazione con operazioni parallele

Anche se le operazioni parallele (primaria/secondaria) sono uno strumento potente per modellare scenari come quando un computer e un operatore sono entrambi necessari per eseguire un'attività specifica, sono anche la fonte di molti problemi di prestazioni. Se si assegna un requisito per una singola risorsa specifica all'operazione primaria e secondaria, in genere non si tratta di un problema. Ma se ci sono molte risorse possibili per ciascuna delle operazioni, allora aggiunge una significativa complessità computazionale alla pianificazione.

Un'alternativa all'uso di operazioni parallele consiste nel modellare le coppie come risorse "virtuali" (che rappresentano quindi il team che lavora sempre insieme per l'operazione) o semplicemente omettendo una delle operazioni se questa non rappresenta un punto critico.

Instradare con quantità di risorse superiori a una

Se la quantità di risorse necessarie per un'operazione è maggiore di una, il risultato è in effetti uguale all'uso di operazioni primarie/secondarie perché più processi paralleli vengono inviati al motore. Tuttavia, per questo caso, non è possibile usare assegnazioni di risorse specifiche perché una quantità maggiore di una richiede che più di una risorsa sia applicabile per l'operazione.

Un'operazione secondaria con una quantità del carico di risorse superiore a uno significa che la quantità specificata delle risorse secondarie è necessaria per ogni risorsa dell'operazione primaria. Ad esempio, se la quantità di risorse di un'operazione primaria è impostata su due e la quantità di risorse della relativa operazione secondaria è impostata su tre, sono necessarie in totale sei risorse per l'operazione secondaria.

Uso eccessivo di una capacità finita

L'uso della capacità limitata richiede al motore di caricare le informazioni sulla capacità da un database, il che può aggiungere sovraccarico computazionale, soprattutto negli ambienti in cui le risorse vengono prenotate vicine alla capacità massima. Di conseguenza, è importante valutare attentamente se una risorsa deve effettivamente usare capacità limitata o se può essere sovrabookata. Poiché potrebbe esserci una differenza tra le risorse a capacità finita in termini della loro importanza per non sovraccaricare, utilizza l'opzione di strozzatura per una risorsa in combinazione con un valore separato nel piano in "Limite temporale per la capacità delle risorse di strozzatura". L'utilizzo del concetto di strozzatura può consentire di ridurre il limite generale della capacità finita.

Impostazione di collegamenti rigidi

Il tipo di collegamento standard del percorso è morbido, che consente un intervallo di tempo tra il termine di un'operazione e l'inizio di quella successiva. Se si consente questo divario, può causare l'inattività della produzione se i materiali o la capacità non sono disponibili per una delle operazioni. Questa situazione può portare ad un aumento del lavoro in corso. Questo problema non si verifica con collegamenti rigidi perché la fine e l'inizio devono essere allineati perfettamente. Tuttavia, l'impostazione di collegamenti rigidi rende il problema di pianificazione più difficile perché il sistema deve calcolare l'orario di lavoro e le intersezioni di capacità per le due risorse delle operazioni. Se la pianificazione prevede anche operazioni parallele, questo requisito aggiunge tempi di calcolo significativi. Se le risorse delle due operazioni hanno calendari diversi che non si sovrappongono affatto, il problema è irrisolvibile.

Usare i collegamenti rigidi solo quando strettamente necessario e valutare attentamente se è necessario per ogni operazione della route.

Per ridurre il lavoro in corso senza applicare collegamenti rigidi, pianificare l'ordine due volte, invertendo la direzione al secondo passaggio. Se la prima pianificazione è stata eseguita all'indietro rispetto alla data di consegna, la seconda pianificazione deve essere eseguita in avanti dalla data di inizio pianificata. Questo approccio comprime i processi il più possibile in modo che il lavoro in corso sia ridotto al minimo.

Calendario distinto per ogni risorsa

Una delle principali origini dati per il motore di pianificazione sono le informazioni del calendario, il cui caricamento dal database può risultare costoso. Poiché i calendari vengono generati in base ai modelli, potrebbe sembrare tentante generare un calendario per ogni risorsa e quindi modificare le informazioni in questo calendario quando la risorsa presenta tempi di inattività e altri problemi. Tuttavia, questo approccio limita gravemente la capacità del motore di memorizzare nella cache i dati del calendario perché deve richiedere nuovi dati per ogni risorsa. Questo approccio può causare problemi di prestazioni. Riutilizzare i calendari il più possibile tra le risorse e controllare le modifiche al tempo di inattività assegnando un ID calendario diverso per un periodo.

Numero elevato di fasce orarie di lavoro per giorno di calendario

Poiché il motore funziona esaminando gli intervalli di tempo uno alla volta per la capacità, è utile ridurre al minimo il numero di fasce orarie per giorno del calendario. Si consideri, ad esempio, se è importante che la pianificazione risultante rifletta che i lavoratori impiegano un intervallo di cinque minuti ogni ora.

Timeout di pianificazione importanti (o inesistenti)

È possibile ottimizzare le prestazioni del motore di pianificazione usando i parametri disponibili nella pagina Parametri di pianificazione . Impostare sempre le impostazioni Timeout pianificazione abilitate e Timeout di ottimizzazione della pianificazione su Sì. Se vengono impostati su No, la pianificazione può essere eseguita infinitamente se viene creata una route non verificabile con molte opzioni.

Il valore di Tempo di pianificazione per sequenza determina il numero massimo di secondi durante i quali viene eseguita la ricerca di una soluzione per una singola sequenza (nella maggior parte dei casi una sequenza corrisponde a un singolo ordine). Il valore da usare dipende in modo elevato dalla complessità della route e dalle impostazioni come la capacità limitata, ma un massimo di circa 30 secondi è un buon punto di partenza.

Il valore di Timeout tentativi ottimizzazione determina il numero massimo di secondi durante i quali viene eseguita la ricerca di una soluzione di quella trovata originariamente. Questo valore influenza solo le route che usano operazioni parallele perché queste operazioni rendono necessario testare combinazioni diverse.

Errori comuni di pianificazione dei processi

Nella tabella seguente sono elencati gli errori noti di pianificazione dei processi con collegamenti a informazioni che consentono di risolverli.

Informazioni pertinenti

• Calendari e pianificazione generale
• Calcolare le date di spedizione richieste per ordini fornitore
• Parametri di data e ora utilizzati da Ottimizzazione pianificazione
• Margini di sicurezza