Sikkerhedsmargener

Denne artikel beskriver, hvordan sikkerhedsmargener fungerer under varedisponering.

Oversigt over sikkerhedsmargener

Sikkerhedsmargener giver buffertid ud over den normale gennemløbstid. Det kan f.eks. være nødvendigt at pakke ud eller undersøge materiale, når det er modtaget fra leverandøren. Du kan ikke bare føje den ekstra tid til leveringstiden for køb, fordi denne fremgangsmåde giver leverandøren ekstra buffertid. Brug i stedet kvitteringsmargenen til at sikre, at leverandøren leverer tidligere. Modtagelsesmargenen giver buffertid, så du kan håndtere varerne internt.

Der findes tre typer sikkerhedsmargener:

• Bestillingsmargen – Buffertiden for afgivelse af forsyningsordren
• Modtagelsesmargen – Buffertiden for håndtering af indgående forsyning
• Afgangsmargen – Buffertiden for ekspedition af forsendelser

I følgende illustration vises, hvordan disse sikkerhedsmargener anvendes over tid.

Alle margener defineres i dage. Standardværdieb på 0 (nul) angiver, at ingen standardmargen bruges. Hvis du konfigurerer flere margener, vil de alle blive føjet til den samlede tid fra forsyningens ordredato til behovsdatoen. En opsætning har f.eks. ikke en leveringstid, og alle tre margentyper er angivet til én dag. I dette tilfælde findes der tre dage mellem leveringsdatoen og behovsbehovsdatoen, så hvis ordredatoen er den 1. juli, er behovsdatoen den 4. juli.

Modtagelsesmargen

Modtagelsesmargenen er sandsynligvis den mest anvendte af de tre sikkerhedsmargener. Systemet anvender den på leveringsdatoen og beregner bagud fra behovsdatoen. Med andre ord skal du modtage produkterne det angivne antal dage med kvitteringsmargen, før du har brug for dem.

I følgende illustration fremhæves modtagelsesmargenen.

Modtagelsesmargenen fungerer typisk som en buffer for at sikre tid til lagerregistrering eller andre tidskrævende processer, som systemet ikke registrerer som en del af den generelle gennemløbstid. Ved køb er en fordel, at leveringsdatoen for indkøbsordren flyttes tilsvarende. Hvis du øger leveringstiden i stedet for at bruge en sikkerhedsmargen, skal leverandøren stadig levere i sidste minut.

Modtagelsesmargenen ændrer ikke leveringens behovsdato . Derfor kan du ikke direkte se modtagelsesmargenen, når du sammenligner behovsdatoer for behov og forsyning (f.eks. på siden Net requirements ). Lad os f.eks. sige, at modtagelsesmargenen er fire dage, og at der er planlagt en indkøbsordrelinje til modtagelse den 15. i måneden. Masterplanlægning beregner den justerede modtagelsesdato som den 19. i måneden.

Der anvendes ikke en tilgangsmargen, når disponibel lagerbeholdning bruges som forsyning. Alt disponibelt lager antages at være tilgængeligt med det samme, uanset hvornår du rent faktisk har modtaget det.

Bestillingsmargen

I følgende illustration fremhæves bestillingsmargen.

Ombestillingsmargenen tilføjer tid før leverancetiden for alle ordreforslag under hovedplanlægning. Derfor sikrer det ekstra tid til at placere en forsyningsordre. Denne margen fungerer typisk som en buffer for at sikre tid til godkendelsesprocesser eller andre interne processer, der kræves under oprettelsen af forsyningsordrer. Genbestillingsmargenen går mellem leveringsordredatoen og startdatoen.

Afgangsmargen

I følgende illustration fremhæves afgangsmargen.

Under overordnet planlægning trækker systemet afgangsmargenen fra behovsdatoen. Dette fradrag hjælper med at sikre, at du har tid til at reagere på og sende indgående behovsordrer. Denne margen fungerer som en buffer for at sikre tid til forsendelse og relaterede udgående lagerprocesser.

Når du anvender en problemmargen, stemmer de relaterede datoer for behovs- og udbudskrav ikke overens. De afviger i stedet med afgangsmargenen, fordi afgangsmargenen tilføjes mellem forsyningens behovsdato og efterspørgslens behovsdato.

Angive sikkerhedsmargener

Definere sikkerhedsmargener

Angiv sikkerhedsmargener for både dækningsgruppen og hovedplanen. Systemet lægger disse margener sammen. Hvis du f.eks. angiver en modtagelsesmargen på to dage for disponeringsgruppen og tre dage i behovsplanen, er den effektive modtagelsesmargen fem dage.

Angiv margenen i masterplanen, når du vil simulere længere gennemløbstider eller usikkerhed for en bestemt plan, men uden at påvirke den daglige planlægning.

Sikkerhedsmargener for disponeringsgruppe

Hvis du vil anvende en sikkerhedsmargen på en dækningsgruppe, skal du følge disse trin:

1. Gå til varedisponering>Opsætning>Disponeringsgrupper.

2. Vælg dækningsgruppen i listeruden.

3. I sektionen Sikkerhedsmargener i dage i oversigtspanel Andet skal du bruge følgende felter til at angive de nødvendige sikkerhedsmargener (i dage):

   • Modtagelsesmargen lagt til behovsdato
   • Afgangsmargen trukket fra behovsdato
   • Bestillingsmargen tilføjet til varens leveringstid

Sikkerhedsmargener for behovsplan

Hvis du vil anvende en sikkerhedsmargen på en masterplan, skal du følge disse trin:

1. Gå til Varedisponering>Opsætning>Planer>Behovsplaner.

2. Vælg hovedplanen i listeruden.

3. I oversigtspanelet Sikkerhedsmargener i dage skal du bruge følgende felter til at angive de nødvendige sikkerhedsmargener (i dage):

   • Modtagelsesmargen lagt til behovsdato
   • Afgangsmargen trukket fra behovsdato
   • Bestillingsmargen tilføjet til varens leveringstid

Definer, om beregninger er baseret på kalenderdage eller arbejdsdage

Angiv alle sikkerhedsmargener for at beregne baseret på enten kalenderdage eller arbejdsdage.

1. Gå til Varedisponering>Konfiguration>Varedisponeringsparametre.
2. Under fanen Generelt skal du i afsnittet Sikkerhedsmargener i dage angive indstillingen Arbejdsdage til Ja for at beregne margener baseret på arbejdsdage. Angiv indstillingen til Nej for at beregne margener baseret på kalenderdage.

En kalender kan f.eks. være åben fra mandag til fredag og være lukket lørdag og søndag. Hvis der er en modtagelsesmargen på én dag, opretter en kravsdato på en mandag en leveringsdato den forrige fredag, fordi lørdag og søndag ikke er arbejdsdage.

Den kalender, der bestemmer arbejdsdagene, afhænger af konfigurationen og leveringstypen. Kalenderne for disponeringsgruppen, lageret og kreditoren styrer, hvilke dage der tæller som arbejdsdage.

Systemet kan håndtere en opsætning, hvor der er defineret en eller flere kalendere. I følgende underafsnit beskrives de mulige kombinationer, du kan bruge til at styre resultatet.

Kalender, der bruges til varigheden

De definerede kalendere styrer den faktiske samlede leveringstid i kalenderdage fra forsyningsordredatoen til behovsdatoen. Systemet bruger følgende kalenderprioritering:

• Leveringstid for indkøb – Det er kun disponeringsgruppekalenderen, der tages i betragtning.
• Kvitteringsmargen – hvis der er defineret en dækningsgruppekalender, bruger systemet den. Ellers bruger systemet lagerkalenderen.
• Problemmargen – hvis der er defineret en dækningsgruppekalender, bruger systemet den. Ellers bruger systemet lagerkalenderen.
• Ordremargen – Det er kun disponeringsgruppekalenderen, der tages i betragtning.

Kalender, der bruges til slutdatoen

Følgende regler bestemmer, om planlægningsprogrammet kan bruge en given dato for en given datotype:

• Købskvitteringsdato – hvis der er defineret en leverandørkalender, bruger systemet den. Ellers bruger systemet denne kalender, hvis der er defineret en dækningsgruppekalender. Hvis ingen af kalenderen er defineret, bruger systemet lagerkalenderen.
• Overførselsmodtagelsesdato – hvis der er defineret en disponeringsgruppekalender, bruger systemet den. Ellers bruger systemet lagerkalenderen.
• Produktionsmodtagelsesdato – hvis der er defineret en disponeringsgruppekalender, bruger systemet den. Ellers bruger systemet lagerkalenderen.
• Åbent hus for behovsudstedelse – hvis der er defineret en lagerkalender, vil systemet bruge den. Ellers bruger systemet dækningsgruppekalenderen.
• Ordreåbningsdag – Systemet bruger en kombination (skæringspunkt) af dækningsgruppekalenderen og kreditorkalenderen. Begge kalendere skal være åbne for at kunne bruge datoen. Hvis der kun er defineret én kalender, bruger systemet denne kalender alene.

Oversigtsmatrix for kalenderopsætning

I følgende illustration vises en matrix, der opsummerer, hvilke kalendere der anvendes, når der beregnes sikkerhedsmargener. Vælg billedet for at åbne en version med høj opløsning af det. Følgende forkortelser og farver angiver, hvor hver type kalender er angivet:

• Disponeringsgruppe (CG): grøn
• Lagersted (WH): gul
• Leverandør (V): blå

Beregning af forsinkelser

Systemet indeholder alle tre typer sikkerhedsmargener, når det bestemmer, om en ordre er forsinket.

En vare har f.eks. en gennemløbstid på én dag og en modtagelsesmargen på tre dage. En salgsordre for denne vare angives som påkrævet i dag. I dette tilfælde beregnes forsinkelsen som leveringstid + modtagelsesmargen = fire dage. Hvis dags dato f.eks. er 14. august, skaber de fire dages forsinkelse en levering den 18. august. Følgende illustration viser dette eksempel.

Afgangsmargen og beholdning

Nogle gange anvender systemet ikke problemmargenen på en ordre, når der findes disponible leveringer for en vare. Årsagen til denne funktionsmåde er, at den disponible forsyning ikke har en dato, så systemet kan ikke anvende problemmargenen.

Denne situation opstår normalt, når du sælger en vare, der har en afgangsmargen fra et lager, f.eks. WH11. En overflytningsordre fra et andet lager, såsom WH13, opfylder det salgsrettede lager. I dette tilfælde kan en af følgende situationer være gældende:

• Hvis den disponible forsyning findes i WH13 – på WH11, anvender systemet avancen mellem salgsordredatoen og modtagelsesdatoen for overflytningsordren. På WH13 er datoen for overflytningsordreleverancen dog den samme som modtagelsesdatoen, fordi der er beholdningsforsyning, så systemet anvender ikke nogen afgangsmargen.

• Hvis den disponible forsyning ikke findes i WH13 – hvis der ikke er nogen disponible levering, og WH13 skal genbestilles på anden måde (f.eks. en indkøbsordre), anvender systemet afgangsmargenen mellem modtagelsesdatoen for overflytningsordren og modtagelsesdatoen for indkøbsordren.

Blød margenkonflikt (forhåndsvisning)

[Dette afsnit er foreløbig dokumentation og kan ændres.]

Blød problemmargen medfører, at systemet behandler problemmargenen som en foretrukken buffer i stedet for et hårdt krav. I stedet for altid at anvende den fulde problemmargen kan systemet med en blød margen reducere den efter behov for at undgå at skubbe kravdatoen ind i fremtiden. Uden blød buffer anvender systemet altid den fulde margen, også selvom det forsinker en efterspørgselsordre.

Den bløde problemmargen fungerer på følgende måde:

• Hvis den fulde problemmargen kan anvendes uden at forårsage en forsinkelse – systemet anvender den fulde problemmargen på samme måde som med standardfunktionsmåden. Der sker ingen ændring.
• Hvis den fulde problemmargen vil medføre en forsinkelse – reducerer systemet problemmargenen til den største værdi, der ikke skubber den planlagte behovsdato efter behovskravsdatoen. Margenen kan reduceres til en hvilken som helst værdi mellem nul dage og den fulde konfigurerede værdi minus én dag.
• Hvis ordren allerede er forsinket (behovskravsdatoen er tidligere) – systemet ignorerer problemmargenen fuldstændigt. Problemmargenen er ikke inkluderet i beregningen af forsinkelsen. I stedet vises forskellen mellem behovsbehovsdatoen og ordreforslagsdatoen for at angive, at ordren ikke kan opfyldes til tiden.

Denne funktionsmåde gælder uafhængigt på hvert niveau i forsyningskæden. Hvis en styklistestruktur omfatter både en færdig vare og en råvare, evalueres og justeres afgangsmargenen separat for hvert niveau.

Forudsætninger for blød problemmargen

Hvis du vil bruge en blød problemmargen, skal systemet opfylde følgende krav:

• Du skal køre Microsoft Dynamics 365 Supply Chain Management version 10.0.48 build 10.39.1837 eller nyere.
• Funktionen med navnet Bløde problemmargener med Planlægningsoptimering skal være aktiveret i funktionsstyring.

Aktivér blød problemgrænse for en dækningsgruppe

Du aktiverer den fleksible margen for problemer på dækningsgruppeniveau. Hvis du vil aktivere den bløde problemmargen for en dækningsgruppe, skal du følge disse trin:

1. Gå til varedisponering>Opsætning>Disponeringsgrupper.
2. Vælg disponeringsgruppen.
3. På Andet hurtigfanebladet skal du sætte indstillingen Blød problemmargen til Ja.

Eksempel 1: Problemmarginen reduceres for at undgå forsinkelse

Følgende betingelser gælder i dette eksempel:

• Udleveringsmarginalen er 10 dage for alle varer.
• Blød problemmargen er aktiveret.
• Dags dato er den 1. oktober.
• Indstillingen Føj den beregnede forsinkelse til behovsdatoen for produktionsordrer er deaktiveret.

Datoen for behovskrav er 7. oktober. Uden blød udstedelsesmargen anvender systemet den fulde 10-dages udstedelsesmargen på både det færdige gode niveau og råmaterialeniveauet. Da der kun er seks dage til rådighed mellem dags dato og behovsdatoen, medfører den fulde margen en forsinkelse på begge niveauer.

Når den bløde problemmargen er aktiveret, reducerer systemet problemmargenen på begge niveauer til de største værdier, der ikke skubber de planlagte datoer forbi kravsdatoen. Ordrerne er planlagt uden forsinkelse.

Eksempel 2: Ordre, der allerede er forsinket, og problemmarginen ignoreres

De samme betingelser gælder som i det forrige eksempel.

Datoen for behovskrav er den 24. september. Uden den bløde udstedelsesmargen anvender systemet den fulde 10-dages udstedelsesmargen på både det færdige gode niveau og råmaterialeniveauet, hvilket yderligere øger forsinkelsen.

Når blød problemmargen er aktiveret, ignorerer systemet problemmargenen helt på begge niveauer, fordi datoen for behovskrav allerede er overskredet. Forsinkelsen vises som forskellen mellem behovskravsdatoen (24. september) og den tidligst mulige ordreforslagsdato (1. oktober). Problemmargen bidrager ikke til forsinkelsen.

Grådig applikation på tværs af forsyningskæder i flere niveauer

Den bløde udstedelsesmargen anvendes grådigt langs forsyningskæden, startende fra efterspørgselssiden. Det første niveau i kæden (tættest på det oprindelige behov) forbruger så meget af den tilgængelige emnemargen som muligt. Efterfølgende niveauer (længere væk fra efterspørgslen, tættere på forsyningskilden) modtager den margen, der er tilbage.

Du kan f.eks. overveje en forsyningskæde, hvor lageret WH12 opfylder en salgsordre på lageret WH11 via en overførsel, og en indkøbsordre genbestiller WH12. Hvis du konfigurerer den bløde afgangsmargen for varen på begge lagre, allokerer systemet først så meget afgangsmargen som muligt til problemet fra WH11, som er det lager, der er tættest på kundebehovet. Problemet fra WH12, som er længere opstrøms i forsyningskæden, modtager derefter den tilgængelige avance uden at forårsage en forsinkelse.

Grådige allokering betyder, at downstream-operationer (tættere på kunden) prioriteres for margin, mens upstream-handlinger absorberer reduktionen.

Kendte begrænsninger for blød vævmargen

Den grådige anvendelse af bløde problemmargener kan føre til situationer, hvor de kravdatoer, der er angivet af motoren, er for optimistiske. Når programmet anvender datoen for soft issue margin, kender det endnu ikke til potentielle forsinkelser, der kan opstå længere oppe i forsyningskæden. Når systemet støder på upstreamforsinkelser og tager højde for dem i planen, opdateres kravdatoer ikke for at tage højde for forsinkelser, der komprimerer en blød problemgrænse.

Grådig anvendelse af tolerance margener kan føre til situationer, hvor kravdatoen for en planlagt levering er angivet for tidligt. Når systemet tager højde for forsinkelser, viser det forsinkelsesperioder, selvom det kun var den bløde bufferperiode, der blev reduceret i stedet for at forsinke efterspørgslen.

Eksempel på kendt begrænsning

Følgende betingelser gælder i dette eksempel:

• Dags dato er den 18. maj.
• Der findes en vare P1 , der genbestilles af produktionsordrer.
• Hvis du vil producere vare P1, kræves der en råmateriale R1 , som genopfyldes af indkøbsordrer med en leveringstid på tre dage.
• Den bløde tidsramme er angivet til to dage på P1 og R1.

En salgsordre for vare P1 har en kravdato den 22. maj. Der er konfigureret en blød problemmargen på to dage på P1. Systemet anvender grådigt den fulde afgangsmargen og planlægger en produktionsordre med en behovsdato den 20. maj. Produktionsordren kræver råmateriale R1, som også har en to-dages afgangsmargen og er planlagt med en behovsdato den 18. maj.

Indkøbsordren for R1 har dog en købstid på tre dage. Denne gennemløbstid medfører en tre-dages forsinkelse på indkøbsordren, som justerer den planlagte dato til den 21. maj. Forsinkelsen overføres til produktionsordren, som også justeres til den 21. maj. Da fleksibel margenhåndtering er aktiveret, komprimeres margenhåndteringen på produktionsniveau og tilføjer ikke ekstra forsinkelse. Forsinkelsen overføres også til salgsordreniveauet. Systemet komprimerer dog den bløde problemmargen fra to dage til én dag, så salgsordren ikke forsinkes efter den 22. maj.

Når forsinkelserne er løst, er der en uoverensstemmelse mellem kravdatoerne og de planlagte datoer. De kravdatoer, der blev angivet, før forsinkelserne blev kendt, er nu for optimistiske. Systemet justerer ikke disse kravdatoer med tilbagevirkende kraft, hvilket kan resultere i, at der vises forsinkelsesdage, selvom leveringen ikke forsinkes i henhold til den bløde problemmargen. Denne funktionsmåde er tilsigtet og en kendt begrænsning i funktionen soft issue margin.

Virkningen af kendt begrænsning

Hvis der opstår forsinkelser, og systemet ikke opdaterer kravsdatoerne, kan flere andre funktioner, der er afhængige af kravdatoer og forsinkelser, også blive påvirket. Eksempel:

1. Forsinkelsesdage
2. Handlinger
3. Valg af stykliste/rute
4. Samhandelsaftaler

Sørg for at teste denne funktion grundigt for at sikre, at din tilsigtede brug af bløde problemmargener ikke påvirkes af de kendte begrænsninger.

Relaterede oplysninger

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