Forbedring af planlægningsprogrammets ydeevne

Ressourceplanlægningsprogrammet planlægger ruter for planlagte og frigivne produktionsordrer.

Problemet med jobbet til produktionsplanlægning er et særdeles komplekst kombinationsproblem, hvor løsningstiden vokser eksponentielt med antallet af beslutningsvariabler. Kunder konfigurerer ofte produktionsruter og relaterede data på måder, der skaber planlægningsproblemer, der ikke kan løses i rimelig tid, selv på moderne hardware. I denne artikel forklares planlægningsprogrammet, og hvordan en bestemt konfiguration påvirker ydeevnen.

Gør planlægningsydeevnen bedre ved at reducere kompleksiteten af det problem, som programmet løser. Nogle af de vigtigste faktorer, der kan påvirke ydeevnen, omfatter:

• Ruter med mange handlinger
• Ruter med parallelle handlinger
• Handlinger med mere end én ressource
• Operationer med mange relevante ressourcer
• Brug af hårde links
• Brug af kapacitetsbegrænsning
• Antal forskellige kalendere, der bruges
• Antal arbejdstider pr. dag i kalenderen
• Rutens samlede varighed
• Kørsel af flere planlægningsprogrammer parallelt

Oversigt over grundlæggende planlægningsflow

For at forstå, hvordan en given konfiguration påvirker ydeevnen, skal du vide, hvordan processen flyder i programmet og i den X++-kode, der omgiver den.

Den grundlæggende proces til planlægning af en ordre består af tre hovedtrin:

• Indlæsning af data – X++-datamodeller transformeres til programmets interne datamodel som job og begrænsninger.
• Planlægning – programmet behandler den givne model og de angivne begrænsninger for at generere et resultat. Den anmoder om oplysninger om arbejdstid og eksisterende kapacitetsreservationer fra X++ efter behov.
• Gem data – X++-kode behandler motorresultatet i form af slots til jobkapacitetsreservation for at gemme kapacitetsreservationer og opdatere start- og sluttidspunkterne for job, handling eller ordre.

Indlæse data i programmet

Planlægningsprogrammet bruger en mere abstrakt datamodel end den supply chain management database, fordi det er et generisk program, der håndterer flere datakilder. Begreberne rute, sekundære handlinger og kørselstid oversættes til den generiske job- og begrænsningsmodel, som programmet fremviser. Logikken til oprettelse af modellen omfatter betydelig forretningslogik og varierer afhængigt af kildedataene. Den ansvarlige X++-klasse er WrkCtrScheduler, som omfatter afledte klasser for produktionsordreforslag, frigivne produktionsordrer og projektprognoser.

Overvej f.eks. en rute, der vises i følgende tabel og billede, hvilket er relativt enkelt.

Når du sender denne rute til motoren, opdeles ruten i otte job, som vist i følgende illustration (vælg billedet for at forstørre den).

Standardforbindelsen mellem to job er FinishStart, hvilket betyder, at sluttidspunktet for ét job skal forekomme før starttidspunktet for et andet job. Konfigurationen skal udføres af den samme ressource, der senere håndterer processen, så der er OnSameResource begrænsninger mellem dem. Mellem opgaverne for den primære og sekundære operation for 10 er StartStart og FinishFinish links, hvilket betyder, at opgaverne både skal starte og slutte på samme tid. Derudover er NotOnSameResource der begrænsninger, som forhindrer den samme ressource i at blive brugt til både primære og sekundære handlinger.

For operation 20, hvor antallet af ressourcer er angivet til 3, opdeles procesjobbet i tre særskilte job, hvor alle job skal køre på præcis samme tid. I dette tilfælde er rutegruppen konfigureret til ikke at reservere kapacitet til efterkø, hvilket er grunden til, at der kun er et enkelt job for køen bagefter.

Planlægningsprogrammet forstår kun begreberne job og genkender ikke handlinger. Denne begrænsning betyder, at systemet opdeler handlinger i job under planlægning af handlinger, selvom disse job ikke bevares i databasen.

For hvert job definerer du, hvad jobkapacitetskravet er (det antal sekunder, der kræves). Afhængigt af hvordan ressourcekravene er defineret, kan du også for hvert job sende en liste over alle de potentielle relevante ressourcer, som jobbet kan køre på, og hvad kapacitetskravet er for den pågældende ressource. Selvom du sender listen over relevante ressourcer, når du bygger modellen, sikrer programmet, at ressourcetildelingen forbliver gyldig i hele jobvarigheden.

Planlægning af programmets indre

Planlægning af programmets grænseflade

Hvis du vil forstå, hvordan programmet fungerer internt, skal du gennemse den funktionalitet, der vises eksternt. I X++ er hovedgrænsefladen WrkCtrSchedulerEngineInterface. Den indeholder de metoder, der er beskrevet i følgende underafsnit.

Generisk program

Individuelle job

Begrænsninger mellem job

Problemløser

Motoren er en specialiseret begrænsningsløser med brugerdefinerede heuristik. Problemløseren er baseret på to hovedelementer: variabler og begrænsninger.

Variabel

En variabel repræsenterer et domæne af mulige værdier. Planlægningsprogrammet har to typer variabler:

• DateTime-variabel – Har et domæne med alle datoer og klokkeslæt. Du kan begrænse domænet ved at flytte de nedre og øvre grænser for tidspunktet for variablen tættere på hinanden.
• Ressourcevariabel – Har et domæne med relevante ressourcer. Du kan begrænse domænet ved at fjerne ressourcer fra listen.

Begrænsning

En begrænsning fungerer på variabler ved at begrænse deres domæner. Det afhænger også af variabler, så det aktiveres, når variabler ændres. Processen med "begrænsningsudbredelse" er, når en begrænsning udfører sin hovedfunktion og rapporterer tilbage til hovedlogikken, hvis den lykkes.

En variabel anses for at være bundet, når den ikke kan begrænses yderligere. For en DateTime-variabel betyder denne betingelse, at de øvre og nedre grænser er de samme. For variablen Ressource betyder det, at den kun har en enkelt relevant ressource. Når alle variabler er bundet, findes der en løsning.

Begrænsningsniveauer

Når planlægning er en del af MRP-dækningsfasen (Material Requirements Planning), planlægger systemet ordrer bagud fra behovsdatoen. Men hvis systemet ikke kan finde en tidsplan, der starter i dag eller nyere og slutter før kravsdatoen, ændres planlægningsretningen til fremad fra i dag.

Systemet organiserer begrænsningerne på niveauer for at håndtere denne hovedforretningsregel. Hvis systemet ikke finder en løsning, når du bruger begrænsningerne på det højeste niveau, falder alle begrænsningerne på det pågældende niveau og forsøger det lavere niveau. I praksis betyder denne proces, at modellen for bagudrettet planlægning indeholder et niveau 1 med jobmål for det seneste starttidspunkt med en maksimal begrænsning for sluttid (kravsdatoen) og et niveau 0 med jobmål for det tidligste sluttidspunkt og givet en minimumstarttidsbegrænsning for dags dato.

Algoritme

Hovedtrin i programalgoritmen er:

1. Find sekvenser (jobkæder), der kan løses separat.
2. Prøv at finde en indledende løsning for sekvensen på det højeste begrænsningsniveau.
   1. Sortér job i rækkefølgen baseret på jobmål og prioriteter, så systemet kan finde et startjob.
   2. Gentag jobbene i følgende rækkefølge:
      1. Find alle de begrænsninger, der skal udbredes, og kør udbredelse.
      2. Hvis alle variabler for jobbet er bundet, findes der en løsning for jobbet.
      3. Hvis en af variablerne ikke kan bindes uden at overtræde begrænsningerne, skal du annullere variabelbindingen, prøve en anden værdi i domænet (for ressourcevariablen) og køre begrænsningsoverførslen igen.
3. Hvis der ikke findes nogen løsning, skal du fjerne alle begrænsninger på det aktuelle begrænsningsniveau, sænke begrænsningsniveauet (hvis der er lavere niveauer tilgængelige) og forsøge at søge efter løsningen igen med det nye sæt begrænsning.
4. Hvis der findes en mulig løsning, skal du starte optimeringsfasen, som forsøger at finde en bedre løsning, indtil optimeringstimeouten er nået, eller alle ressourcekombinationer er opbrugt.

Begrænsningsløseren tager ikke højde for specifikationerne for planlægningsalgoritmen. Den "magiske" sker i definitionen og kombinationen af de forskellige begrænsninger.

Fastlægge arbejdstider

En stor del af begrænsningerne (interne) i programmet styrer en ressources arbejdstid og kapacitet. I bund og grund er opgaven at gennemgå arbejdstidsintervallerne for en ressource fra et givet punkt i en given retning og finde et langt nok interval, hvor jobbets krævede kapacitet (tid) kan passe.

Hvis du vil gøre det, skal programmet kende en ressources arbejdstider. I modsætning til de vigtigste modeldata indlæses arbejdstiderne ved behov (lazy loaded) i programmet, hvilket betyder, at de indlæses i motoren efter behov. Årsagen til denne fremgangsmåde er, at der ofte er arbejdstider i supply chain management for en kalender i en meget lang periode, og at der typisk findes mange kalendere, så dataene vil være ret store at forudindlæse.

Programmet anmoder om kalenderoplysninger i afsnit ved at aktivere X++-klassemetoden WrkCtrSchedulingInteropDataProvider.getWorkingTimes. Anmodningen gælder for et bestemt kalender-id i et bestemt tidsinterval. Afhængigt af servercachens tilstand i supply chain management kan hver enkelt af disse anmodninger ende med flere databasekald, hvilket tager lang tid (i forhold til den rene beregningstid). Hvis kalenderen indeholder meget detaljerede definitioner af arbejdstid med mange arbejdstidsintervaller pr. dag, øger denne kompleksitet også den tid, indlæsningen tager.

Når planlægningsprogrammet indlæser arbejdstidsdataene, bevarer det disse data i den interne cache for den specifikke kalender. Denne opbevaring betyder, at hvis andre job eller ressourcer bruger den samme kalender, kan de næste opslag udføres hurtigt fra hukommelsen. En almindelig årsag til dårlig ydeevne er, hvis der bruges et separat kalender-id for hver ressource, fordi der derefter anmodes om data for hver kalender, selvom indholdet af kalenderne kan være det samme.

Kapacitetsbegrænsning

Når du bruger begrænset kapacitet, opdeler systemet og reducerer arbejdstidsslots fra kalenderen baseret på de eksisterende kapacitetsreservationer. Den samme WrkCtrSchedulingInteropDataProvider klasse henter disse reservationer sammen med kalenderne, men den bruger getCapacityReservations metoden . Når der planlægges under behovsplanlægningen, tager systemet reservationerne for den specifikke behovsplan i betragtning. Hvis du aktiverer indstillingen på siden Med parametre for varedisponering , inkluderer systemet også reservationer fra fast produktionsordre. På samme måde kan du, når du planlægger en produktionsordre, vælge at medtage reservationer fra eksisterende ordreforslag, selvom denne sekvens ikke er så almindelig som omvendt.

Planlægning tager længere tid, når du bruger begrænset kapacitet af flere årsager:

• Det er en langsom handling at hente kapacitetsoplysningerne fra databasen. Cachelagring af kapacitetsoplysninger på serversiden er typisk ikke så god som for arbejdstider, fordi de ikke deles mellem ressourcer, f.eks. kalendere.
• Antallet af arbejdstider, der skal gennemgås, stiger på grund af opdelingerne. Systemet skal typisk undersøge slots i en længere periode, før det kan finde en løsning.
• Når planlægningen er fuldført, skal systemet kontrollere, om der er modstridende reservationer (se afsnittet "Kører planlægningsprogrammer parallelt" for at få flere oplysninger).

Undersøgelse af ressourcekombinationerne

Hvis jobsekvensen kun indeholder standardlinks FinishStart , hvilket betyder, at den udgør en enkel kæde uden forgreninger, kan systemet opnå et optimalt resultat (set fra den enkelte ordre, ikke på tværs af ordrer) ved at finde den bedste løsning til det første job og derefter gå videre for at finde den bedste løsning til det næste job. Den bedste løsning for et job er at finde den ressource, der kan få jobbet fra og til dato tættest på jobmålet (ved fremadrettet planlægning betyder det, at slutdatoen for jobbet skal hentes så tidligt som muligt), samtidig med at begrænsningerne respekteres.

Når der er parallelle job, kan en løsning omfatte undersøgelse af forskellige kombinationer af ressourcer. Antallet af mulige ressourcekombinationer er produktet af antallet af relevante ressourcer for de forbundne parallelle job. Især når du planlægger en ordre bagud fra en kravsdato, kan det tage et stykke tid, før logikken indser, at der ikke er nogen løsning på problemet, der får de parallelle job til at passe før dags dato. Logikken skal kontrollere alle kombinationer, fordi der kan være nogle ressourcer, der har en højere effektivitet eller en anden kalender, der kan give et resultat. Denne betingelse betyder, at hvis du ikke angiver en timeoutgrænse, kører processen i lang tid, før du ændrer retningen til fremad.

Denne kombinatoriske logik betyder også, at tilføjelse af mere relevante ressourcer kan gøre programmet langsommere. Hvis der opstår problemer med ydeevnen, når du har parallelle handlinger og planlægning med uendelig kapacitet, kan du delvist løse problemet ved at få rutedesigneren til at beslutte, hvilken ressource der skal bruges, og derefter tildele ressourcen direkte til handlingen (fordi programmet i de fleste tilfælde altid ender med at hente den samme ressource, så slutresultatet er det samme).

Hårde links

Når du angiver linktypen mellem to job til hård, sikrer du, at der ikke er et mellemrum mellem afslutningen af ét job og starten af det næste. Denne betingelse er nyttig i scenarier, hvor metal opvarmes i ét job og behandles i det næste, og køling mellem job er ikke ønskeligt.

Hvis ruten danner en enkel kæde uden forgreninger, kan du ved hjælp af bløde standardlinks og fremadrettet planlægning opnå et resultat ved at finde en løsning for det første job, der opfylder sine egne begrænsninger, og derefter gå videre gennem kæden, der overfører sluttidspunktet fra det forrige job til det næste job. Hvis det aktuelle job ikke kan finde nogen kapacitet, flytter systemet starttidspunktet yderligere uden nogen konsekvens for de tidligere job. Denne handling kan skabe huller mellem jobbene. Men ved at bruge faste links (især i forbindelse med begrænset kapacitet) til det samme scenarie betyder det faktum, at ét job senere i kæden ikke kan finde kapacitet, at alle tidligere planlagte job skal "trækkes" ad en efter en og dermed omlægges flere gange. Især i scenarier med høj belastning for flere ressourcer kan de hårde links forårsage en kædereaktion, hvor jobbene påvirker hinanden, og der skal udføres flere gentagelser, før resultatet stabiliseres til en gennemførlig tidsplan.

Kørsel af planlægningsprogrammer parallelt

Når du udfører planlægning som en del af en varedisponeringskørsel, hvor du bruger hjælpere, kan hver af hjælpetrådene til varedisponering også hente planlægningsopgaver for produktionsordrer. Denne fremgangsmåde betyder, at flere planlægningsprogrammer kan køre på samme tid. Selvom multitreading giver en betydelig ydeevnefordel, introducerer den også nogle funktionelle ulemper ved planlægning.

I MRP planlægger systemet alle produktionsordrer for et bestemt styklisteniveau i behovsdatosekvensen. Denne sekvens betyder, at systemet planlægger disse ordrer med den tidligste behovsdato først, så de har den højeste chance for at hente den tilgængelige ressourcekapacitet. Men når flere motorer vælger fra listen over ikke-planlagte ordrer, er sekvensen ikke sikret, fordi det ene program muligvis fuldføres hurtigere end det andet.

Når du planlægger med begrænset kapacitet og flere motorforekomster, kan der opstå en racebetingelse, hvis du forsøger at planlægge ordrer, der bruger de samme ressourcer på samme tid. I feltet Planlægningskonflikter på oversigtssiden for masterplaner registreres antallet af racebetingelser. Konfliktløsningslogikken følger disse trin:

1. Planlæg en ordre (låsefri), og få kapacitetsreservationer.
2. Tag låsen.
3. Kontrollér, om der findes nyere kapacitetsreservationer for de planlagte ressourcer i det tidsrum.
   • Hvis ikke, skal du skrive kapaciteten og frigive låsen.
   • Hvis ja, skal du frigive låsen og genplanlægge ordren fra begyndelsen.

Når du planlægger med flere programforekomster, er resultatet ikke helt deterministisk, fordi det afhænger af den nøjagtige timing af hver tråd.

Ydeevne af grovplanlægning

Operation planlægning, også kendt som grov kapacitetsplanlægning, kan være sværere at løse set fra et programs perspektiv, hvis endelig kapacitet bruges, fordi flere data er nødvendige for at fastslå gennemførligheden.

Kapaciteten for en ressourcegruppe afhænger af, hvilke og hvor mange ressourcer der er medlemmer af ressourcegruppen. En ressourcegruppe i sig selv har ingen kapacitet – kun når ressourcer er medlemmer af gruppen, har den kapacitet. Da medlemskabet af ressourcegruppen kan variere over tid, skal kapacitet evalueres pr. dag.

Ved grovplanlægning bruges ressourcegruppens kalender til at bestemme start- og sluttidspunkter for hver operation. Denne kalender sætter en grænse for, hvor meget tid du kan planlægge handlinger for én handling på én dag i én ressourcegruppe. I modsætning til kalenderen for bestemte ressourcer ignoreres effektivitetsdataene for ressourcegruppens kalender, fordi den kun angiver åbningstider og ikke faktisk kapacitet.

Hvis arbejdstiden for en ressourcegruppe på en bestemt dato f.eks. er fra 8:00 til 16:00, kan én handling ikke belaste ressourcegruppen mere, end hvad der kan være i 8 timer, uanset hvor meget kapacitet ressourcegruppen har tilgængelig i alt på den pågældende dag. Den tilgængelige kapacitet kan dog begrænse belastningen yderligere.

Belastning fra jobplanlægning på alle ressourcer i ressourcegruppen for en given dag tages i betragtning ved beregning af den tilgængelige kapacitet for den dag. For hver dato er beregningen:

Tilgængelig ressourcegruppekapacitet = Kapacitet for ressourcer i gruppen baseret på deres kalender − Jobplanlagt belastning af ressourcerne i gruppen − Planlagt operationsbelastning af ressourcerne i gruppen − Planlagt handlingsbelastning af ressourcegruppen

Under fanen Ressourcekrav under rutehandlingen kan du angive ressourcekravene ved hjælp af enten en bestemt ressource (i hvilket tilfælde handlingen er planlagt ved hjælp af den pågældende ressource), en ressourcegruppe, en ressourcetype eller en eller flere egenskaber, færdigheder, kursus eller certifikat. Brug af alle disse indstillinger giver fleksibilitet i rutedesignet, men komplicerer planlægningen af programmet, fordi der skal tages højde for kapaciteten pr. 'egenskab' (et abstrakt navn, der bruges i programmet til egenskaber, færdigheder osv.).

Ressourcegruppens kapacitet for en egenskab er summen af kapaciteten for alle ressourcer i den ressourcegruppe, der har den pågældende egenskab. Hvis en ressource i gruppen har en egenskab, tager programmet den i betragtning, uanset hvilket niveau af kapaciteten der kræves.

I grovplanlægning reduceres den tilgængelige kapacitet for en bestemt egenskab for en ressourcegruppe, når den indlæses med en handling, der kræver den pågældende egenskab. Hvis handlingen kræver mere end én funktion, reduceres kapaciteten for alle påkrævede funktioner.

For hver dato er den påkrævede beregning:

Tilgængelig kapacitet for en egenskab = Kapacitet for egenskaben − Planlagt jobbelastning af ressourcerne med den specifikke egenskab, der er inkluderet i ressourcegruppen − Planlagt belastning af ressourcer med den specifikke egenskab, der er inkluderet i ressourcegruppen – Planlagt handlingsbelastning af selve ressourcegruppen, der kræver den specifikke egenskab

Hvis en bestemt ressource har en belastning, tager programmet det i betragtning ved beregning af ressourcegruppens tilgængelige kapacitet pr. egenskab, fordi belastningen reducerer dens bidrag til gruppens kapacitet, uanset om belastningen er for den pågældende egenskab. Hvis der er belastning på ressourcegruppeniveau, tager programmet det kun i betragtning ved beregningen af ressourcegruppens tilgængelige kapacitet pr. egenskab, hvis belastningen er fra en handling, der kræver den specifikke egenskab.

Denne logik gælder for hver egenskabstype, så brug af handlingsplanlægning med begrænset kapacitet kræver indlæsning af en betydelig mængde data.

Forbedring af MRP-ydeevne

Følgende video om teknisk konference indeholder tip til at forbedre ydeevnen i forbindelse med masterplanlægning, når du bruger MRP med det frarådede masterplanlægningsprogram: Hjælp! MRP er langsom!

Visning af input og output for planlægningsprogrammet

Hvis du vil have specifikke oplysninger om input og output for planlægningsprocessen, skal du aktivere logføring ved at gå til Konfiguration af organisationsadministration>Planlægningssporingscockpit>>.

På denne side skal du vælge Aktivér logføring i handlingsruden og derefter køre planlægningen for produktionsordren. Når den er færdig, skal du vende tilbage til siden Planlægning af sporing af cockpit og vælge Deaktiver logføring i handlingsruden. Opdater siden, og der vises en ny linje i gitteret. Vælg den nye linje, og vælg derefter Download i handlingsruden. Denne handling giver dig en .zip komprimeret mappe, der indeholder følgende filer:

• Log.txt – denne logfil beskriver de trin, programmet gennemgår. Den er detaljeret og kan være overvældende, men når du eksperimenterer med rutekonfigurationen for at løse problemer med ydeevnen, skal du kigge efter tidsforskellen mellem den første og sidste linje. Denne forskel viser den nøjagtige tid, som planlæggeren har brugt.
• XmlModel.xml – Denne fil indeholder den model, der er indbygget i X++, og som programmet arbejder på. Det JobId, der bruges i filen, svarer til RecId fra den kildetabel, der indeholder jobbene (ReqRouteJob eller ProdRouteJob). I denne fil skal du kontrollere, at datoerne i ConstraintJobStartsAt og ConstraintJobEndsAt er som forventet, at egenskaben JobGoal er angivet korrekt, og at jobbene er relateret via begrænsningerne JobLink .
• XmlSlots.xml – Denne fil indeholder alle de arbejdstider og kapacitetsreservationer, som programmet anmoder om. Kalenderens arbejdstider og reservationer anmodes kun af programmet for de tidsperioder, hvor det forsøger at placere job (og en ekstra buffer), så hvis filen indeholder tidspunkter meget langt i fremtiden, kan det være en indikation af et problem med konfigurationen. Noderne ResourceProperty viser den ressourcegruppe og de funktioner, der er knyttet til hver ressource, sammen med de relevante tidsperioder.
• Result.xml – Denne fil indeholder resultatet af planlægningskørslen.

Sporingsfunktionen tilføjer betydelige ydeevneomkostninger, så brug den kun til at undersøge planlægning af bestemte ordrer på en kontrolleret måde. Hvis du tænder den under en hovedplanlægning, når den hurtigt sin størrelsesgrænse og stopper.

Fejlfinding af ydeevne

Som du kan se fra de forrige afsnit, kan nogle faldgruber i konfiguration og brug af planlægningsprogrammet medføre problemer med ydeevnen. Følgende tjekliste kan hjælpe dig med at foretage fejlfinding af disse problemer. Se på alle punkter, da det ofte er en kombination af flere faktorer, der fører til problemer.

Udfører planlægning som en del af MRP, når det ikke er nødvendigt

Selvom ruter bruges til produktionsstyring, f.eks. omkostningsberegning og rapportering, behøver de muligvis ikke at blive taget i betragtning under MRP. I nogle tilfælde vil en standardproduktionsgennemløbstid for varen være tilstrækkelig til planlægningen. Angiv kapacitetstidshorisonten til nul for at slå ruteplanlægning fra. Hvis der er behov for planlægning, skal du nøje angive kapacitetstidshorisonten, da ruter muligvis ikke behøver at blive taget i betragtning i fuldt omfang af MRP'ens dækningstidshorisont.

Hvis ordren ikke er planlagt under MRP, skal den i stedet planlægges, når ordreforslaget er forankret. Det betyder, at autorisationsprocessen tager længere tid, så afhængigt af, hvor mange af de foreslåede ordreforslag der får den autoriserede ydeevnegevinst i MRP, kan den gå tabt ved autorisation.

Rute med unødvendige handlinger

Når du designer ruten, skal du undgå at forsøge at modellere den virkelige verden nøjagtigt med alle de trin, produktionsprocessen gennemgår. Selvom denne fremgangsmåde kan være nyttig i nogle tilfælde, er den ikke god til ydeevnen, fordi programmets model bliver større (med hensyn til job og begrænsninger), og der udføres flere SQL-sætninger for at indsætte og opdatere job og kapacitetsreservationer. Der er også den efterfølgende effekt af at skulle rapportere status for jobbene, hvilket automatiske bogføringer kan afhjælpe. Hvis dataene ikke bruges til noget, medfører det unødvendig belastning.

Opret kun de handlinger, der er strengt nødvendige til planlægning (typisk flaskehalsressourcer) eller omkostningsformål. Gruppér i stedet mange mindre særskilte handlinger i én større handling, der repræsenterer en større del af processen.

Operation med mange relevante ressourcer

De ressourcekrav, der er angivet for handlingsrelationen, bestemmer antallet af relevante ressourcer for en handling. Kravet kan enten være for en bestemt ressource, eller det kan være baseret på ressourcens medlemskab i en ressourcegruppe eller -egenskab.

Hvis du ikke bruger begrænset kapacitet til planlægning, og alle de relevante ressourcer har samme kalender og effektivitet, vælger planlægningsprogrammet altid den samme ressource til en handling, men først efter den forsøger alle de relevante ressourcer at kontrollere, om der er en, der er bedre end de andre. I dette tilfælde kan du reducere belastningen af planlægningen betydeligt ved altid at tildele en bestemt ressource til handlingen på rutedesigntidspunktet.

Rute med parallelle handlinger

Mens parallelle handlinger (primær/sekundær) er et effektivt værktøj til modelscenarier, f.eks. når en maskine og en operator begge er nødvendige for at udføre en bestemt opgave, er de også kilden til mange problemer med ydeevnen. Hvis du tildeler et krav til en bestemt individuel ressource til både den primære og sekundære handling, er det normalt ikke et problem. Men hvis der er mange mulige ressourcer for hver af operationerne, føjer den betydelig beregningskompleksitet til planlægningen.

Et alternativ til at bruge parallelle handlinger er enten at modellere parrene som "virtuelle" ressourcer (som derefter repræsenterer det team, der altid går sammen for handlingen) eller simpelthen ikke modellere en af handlingerne, hvis det ikke repræsenterer en flaskehals.

Rute med et antal ressourcer, der er højere end én

Hvis det antal ressourcer, der skal bruges til en handling, er større end én, er resultatet reelt det samme som at bruge primære/sekundære handlinger, fordi der sendes flere parallelle job til programmet. I dette tilfælde kan du dog ikke bruge bestemte ressourcetildelinger, fordi et antal, der er højere end ét, kræver, at der gælder mere end én ressource for handlingen.

En sekundær operation, der har en ressourcebelastningsmængde, der er større end én, betyder, at det angivne antal sekundære ressourcer er påkrævet for hver ressource i den primære operation. Hvis f.eks. den primære operation har antallet af ressourcer angivet til to, og dens sekundære operation har ressourceantallet angivet til tre, skal der bruges i alt seks ressourcer til den sekundære operation.

Overdreven brug af kapacitetsbegrænsning

Brug af begrænset kapacitet kræver, at programmet indlæser kapacitetsoplysninger fra en database, hvilket kan tilføje beregningsspild, især i miljøer, hvor ressourcer reserveres tæt på maksimal kapacitet. Det er derfor vigtigt at evaluere nøje, om en ressource virkelig har brug for at bruge begrænset kapacitet, eller om de kan overbookes. Da der kan være en forskel mellem begrænsede kapacitetsressourcer i, hvor vigtige de er for ikke at overbooke, skal du bruge flaskehalsindstillingen på en ressource sammen med en separat værdi i planen i "Kapacitetshorisont for flaskehalsressourcer". Hvis du bruger flaskehalskonceptet, kan det gøre det muligt at sænke den generelle tidshorisont for begrænset kapacitet.

Indstilling af hårde links

Rutens standardforbindelsestype er blød, hvilket giver mulighed for et tidsinterval mellem sluttidspunktet for én operation og starten af den næste. Hvis du tillader dette hul, kan det medføre, at produktionen er inaktiv, hvis materialer eller kapacitet ikke er tilgængelige for en af handlingerne. Denne situation kan føre til en stigning i det igangværende arbejde. Dette problem opstår ikke med hårde links, fordi afslutning og start skal justeres perfekt. Hvis du angiver faste links, bliver planlægningsproblemet dog vanskeligere, fordi systemet skal beregne arbejdstid og kapacitetsskæringspunkter for de to ressourcer i handlingerne. Hvis tidsplanen også omfatter parallelle handlinger, tilføjer dette krav betydelig beregningstid. Hvis ressourcerne i de to operationer har forskellige kalendere, der slet ikke overlapper, er problemet uløseligt.

Brug kun faste links, når det er strengt nødvendigt, og overvej nøje, om det er nødvendigt for hver handling af ruten.

Hvis du vil reducere igangværende arbejde uden at anvende hårde links, skal du planlægge rækkefølgen to gange og ændre til den modsatte retning under det andet gennemløb. Hvis den første tidsplan blev udført bagud fra leveringsdatoen, skal den anden tidsplan udføres fremad fra den planlagte startdato. Denne fremgangsmåde komprimerer jobbene så meget som muligt, så det igangværende arbejde minimeres.

Separat kalender for hver ressource

En af de vigtigste datakilder for planlægningsprogrammet er kalenderoplysninger, som kan være kostbare at indlæse fra databasen. Da kalendere genereres på baggrund af skabeloner, kan det virke fristende at oprette en kalender for hver ressource og derefter justere oplysningerne i denne kalender, når ressourcen har nedetid og andre problemer. Denne fremgangsmåde begrænser dog alvorligt programmets mulighed for at cachelagre kalenderdataene, fordi det skal anmode om nye data for hver ressource. Denne fremgangsmåde kan medføre problemer med ydeevnen. Genbrug kalendere så meget som muligt mellem ressourcer, og styr ændringer af nedetid ved at tildele et andet kalender-id for en periode.

Højt antal arbejdstidsrubrikker pr. dag i kalenderen

Da programmet fungerer ved at undersøge tidsintervaller en efter en for kapacitet, er det en fordel at minimere antallet af tidsintervaller pr. kalenderdag. Overvej f.eks., om det er vigtigt for den resulterende tidsplan at afspejle, at arbejdere tager en pause på fem minutter hver time.

Store (eller ingen) planlægningstimeout

Du kan optimere ydeevnen for planlægningsprogrammet ved hjælp af parametre, der findes på siden Planlægningsparametre . Angiv altid indstillingerne Planlægningstimeout aktiveret og Timeout for planlægningsoptimering aktiveret til Ja. Hvis du angiver dem til Nej, kan planlægning potentielt køre uendeligt, hvis der oprettes en ubrugelig rute med mange indstillinger.

Værdien for Maksimal planlægningstid pr. sekvens styrer, hvor mange sekunder der højst må bruges på at forsøge at finde en løsning for en enkelt sekvens (i de fleste tilfælde svarer en sekvens til en enkelt ordre). Den værdi, der skal bruges her, afhænger i høj grad af kompleksiteten af ruten og indstillingerne, f.eks. begrænset kapacitet, men maksimalt ca. 30 sekunder er et godt udgangspunkt.

Værdien for Timeout for optimeringsforsøg styrer, hvor mange sekunder der højst må bruges på at finde en bedre løsning end den, der oprindeligt blev fundet. Denne værdi påvirker kun ruter, der bruger parallelle handlinger, da disse handlinger gør det nødvendigt at teste forskellige kombinationer.

Almindelige fejl i jobplanlægning

I følgende tabel vises kendte fejl i jobplanlægningen med links til oplysninger, der kan hjælpe dig med at løse dem.

Relaterede oplysninger

• Kalendere og varedisponering
• Beregne ønskede afsendelsesdatoer for indkøbsordrer
• Dato- og klokkeslætsparametre, der bruges af planlægningsoptimering
• Sikkerhedsmargener