[Algorithm] Supply-chain-management

[Verwijderd]

Ik moet voor school een programma schrijven dat een supply-chain kan optimaliseren. Een supply-chain is een keten zoals bijv. Fabrikant-Importeur-Groothandel-Winkelier. De bedoeling is dat de voorraadkosten zo laag mogelijk blijven. Te weinig voorraad is echter nog slechter, want dat kost veel geld. Het doel is dus de kosten zo laag mogelijk te houden. De vraag van de consument aan de winkelier is random.

Is er iemand die ervaring met zoiets heeft of hier meer van weet? Op internet is wel veel over supply-chain-management te vinden, maar al die sites zijn van commerciele bedrijfjes die hun source dus niet ebschikbaar stellen. Vandaar dat ik hier maar eens post of iemand ervaring met zoiets heeft?

[Soultaker]

Er zijn hier zat mensen (inclusief ikzelf) die zich graag in een leuk algoritmisch vraagstuk verdiepen. Als je wat meer concrete informatie hebt, kunnen we je vast wel een suggestie doen.

edit:
Beetje verduidelijken: het gaat er dus vooral om hoe je model in elkaar zit, eventueel met wat waarden zoals de voorraadkosten en de variatie van de vraag.

[bigtree]

Da's toevallig; ik zat net een tentamen Operations Management te leren. Gaat over optimale bestelgrootte Q* waarbij de voorraad- en bestelkosten geminimaliseerd worden:

code:

Q* = optimale bestelgrootte (grootte van de order)
H = voorraadkosten per stuk per jaar
D = jaarlijkse benodigde hoeveelheid
S = setup of bestelkosten per order

Q* = wortel((2*D*S) / H)

[bigtree]

Als je ook nog rekening wilt houden met een minimumvoorraad, moet je de standaarddeviatie van de vraag meenemen.

[Verwijderd]

Ok, ik zal proberen iets uitgebreider te zijn:

- De chain bestaat uit vier elementen: Winkelier --> Groothandel --> Importeur --> Fabriek
- Binnen de chain is geen communicatie mogelijk, d.w.z. de groothandel weet bijv. niets over de voorraad of de binnengekomen orders van de winkelier.
- Het proces verloopt in stappen, die bijv. een week representeren.
- Iedere stap ontvangt ieder element een order, en er wordt geprobeerd deze uit de vooraad van het element te halen en klaar te leggen om geleverd te worden.
Iedere stap schrijft ieder element dus ook een order uit, behalve de fabriek, die bepaalt gewoon hoeveel hij de volgende stap wil produceren.
- Iedere stap levert ieder element ook de klaargelegde order van de vorige keer. Ieder element krijgt dus ook iedere keer een order binnen, deze wordt bij de voorraad gevoegd (bij de fabriek bestaat deze order uit de klaargelegde productie van de vorige keer).
- De order die de winkelier binnenkrijgt is de consumentenvraag, deze is een willekeurig geheel getal tussen 1 en 10.
- Iedere keer na het klaarleggen van de order die de volgende stap geleverd gaat worden, wordt de grootte van de voorraad genoteerd. Als een element 7 in voorraad heeft dan zijn de kosten 7. Het kan echter ook zijn dat een element niet kan leveren uit voorraad, en dus een soort negatieve voorraad heeft. Dit heet backlog. Een backlog van 3 leidt tot kosten 6 (dus keer 2). Als er te weinig geleverd is, dan moet dit wel de volgende stap(pen) alsnog geleverd worden, de backlog moet dus weggewerkt worden.

De bedoeling van het geheel is dus om dit een aantal stappen te gaan herhalen (50 stappen) en de totale kosten van de elementen bij te houden. Het gaat er nu om dat de kosten die de gehele keten (dus alle elementen) gedurende deze tijd maken, zo laag mogelijk blijven.

Ik hoop dat jullie het snappen en er misschien een idee over hebben wat een goede strategie zou kunnen zijn.

[F_J_K]

Op donderdag 28 februari 2002 13:28 schreef bigtree het volgende:
Da's toevallig; ik zat net een tentamen Operations Management te leren. Gaat over optimale bestelgrootte Q* waarbij de voorraad- en bestelkosten geminimaliseerd worden:

code:

Q* = optimale bestelgrootte (grootte van de order)
H = voorraadkosten per stuk per jaar
D = jaarlijkse benodigde hoeveelheid
S = setup of bestelkosten per order

Q* = wortel((2*D*S) / H)

De formule van Camp gaat uit van een constante vraag, en houdt geen rekening met kosten nee-verkoop of met de overige delen van de keten. Dus dat zal niet lukken jammergenoeg.

[F_J_K]

Begin bij de winkelier en bereken voor 'alle' mogelijkheden de kosten, gegeven de vraag. Dus voorraad 1 + kosten overige elementen, 2 + Koverig, etc. Idem bij importeur etc.

Bedenk dat 'alle' niet perse max. 10 betekend, omdat door de backlog de week erop 10 + 10 = 20 gevraagd zouden kunnen worden van de importeur.

[Verwijderd]

Dat is idd iets waar ik ook aan zat te denken, en het is iig een goed begin. Ik denk alleen dat je deze manier van werken zult moeten uitbreiden met een heuristiek, bijv. de kans dat een bepaalde order binnen gaat komen.
De vraag is alleen hoe je deze kans bepaalt

[F_J_K]

Bij de eerste is het simpel: 1-10 elk met een kans 0.1

Door eerste zal maximaal 10 + de neeverkoop van de vorige ronde worden besteld, dus als er op tijdstip t n stuks liggen bij de eerste zal de tweede max. 10 + (10 - n) moeten kunnen leveren. In principe is hier de kans weer 1 / (20 - n) denk ik.

Etc.

Maar neem 't allemaal maar met een korrel zout.

[curry684]

Ik zal even illustreren hoe Albert Heijn winkel->distributiecentrum (DC) werkte toen ik daar een jaar of 3 terug werkte.

In de winkel stel je voor ieder product een Basis-schapVoorraad (BV) in op basis van wat het product minimaal op voorraad moet hebben (3 facings = BV 3 bijvoorbeeld). Hiermee reken je ook piekverkopen mee. De computer weet het gemiddelde van 1 of meerdere jaren aan per/dag verkopen en kan hierop gebaseerd een voorspelling doen. Bijvoorbeeld het is morgen maandag 4 maart, en vorig jaar op deze dag verkochten we 4 pakken appelsap. Het gemiddelde van de afgelopen 4 maandagen was 6 pakken appelsap. Verwachte verkoop morgen (VV1) is dan bijvoorbeeld (4+6)/2 = 5 pakken appelsap. Verwachte verkoop overmorgen (VV2) is bijvoorbeeld op dezelfde manier 6 pakken. Huidige voorraad (HV) is bekend door scanbeheer.

Dagelijks gaat er dan het volgende sommetje aan de gang: bestel automatisch hoeveel je tekort gaat komen op basis van hoever je onder de BV gaat komen, naar boven afgerond.

Bijvoorbeeld als we nu 10 pakken appelsap hebben staan in een vak van 6 facings groot (BV 6) hebben we volgens de verwachting morgenavond 5 pakken appelsap, en overmorgen nog maar -1 pak appelsap. Er zitten 6 pakken appelsap in een tray (theoretisch ). Daarom bestellen we voor morgen 2 trays (om ervoor te zorgen dat we dinsdag nog boven de BV zitten).

Dit is de link winkel->DC, waarbij je natuurlijk voor DC->Leverancier hetzelfde kunt toepassen, en voor Leverancier->Producent evenzo, maar daar ga je op pallets afronden ipv trays.

Snappu?

[wallyberk]

de basisschapvoorraad hoeft niet gelijk te zijn aan het aantal facings. Het aantal facings is het aantal producten wat naast elkaar op de eerste rij kan staan.

Tevens wordt er in de opdracht niks gezegt over de besteleenheid (daarom is de formule van camp ook onzin omdat die de optimale besteleenheid!!!! berekent). Het lijkt me zinvol om van een besteleenheid uit te gaan van 1. Dit zorgt namelijk voor de laagst voorraadkosten.

Voor de oplossing van het probleem lijkt me het handigst om dit oplossen met de simplexmethode (lineaire programmering) als je dit iets zegt te minsten.

Anders gewoon brute force het volgende bereken voor elke optie doorbereken:

besteling stap = ijzeren voorraad (=basisschapvoorraad) van het element - (vorige voorraad + bestelling vorige keer van het element of productie van de fabriek - vraag/bestelling van het vorige element)

kosten van de stap = (vorige voorraad + bestelling vorige keer van het element of productie van de fabriek - vraag/bestelling van het vorige element) * 1 als positief of * -2 als negatief

De verschillende variablen zijn de begin voorraden van de verschillende elementen en ijzeren voorraden van de verschillende elementen (eigenlijk heb je 10^8 mogelijkheden hoewel je een paar mogelijkheden al kan afschrijven zoals een ijzeren voorraad van 0).

(PS ga er even vanuit dat consumentenvraag 5 is om je model te testen. De enige reden namelijk waarom er een wilekeurige consumentenvraag in staat is dat je niet vooraf de vraag kan bepalen en dus steeds geen voorraad overhoud en geen backlog hebt, je bestel immers dan steeds voldoende. het maakt voor het model niet uit of je echt een willekeurig getal neemt (test heel moeilijk ) of het gemiddelde neemt (test heel makkelijk ))

[curry684]

Op zondag 03 maart 2002 23:29 schreef wallyberk het volgende:
de basisschapvoorraad hoeft niet gelijk te zijn aan het aantal facings.

In 99% van de gevallen is het echter wel zo

Alleen echte hardlopers (fris, appelsap, bier, suiker etc.) krijgen 'custom' BV's in de praktijk om schommelingen af te vangen. De meeste produkten hebben echter maar een dagelijkse verkoop van 0 tot 2 eenheden.

[F_J_K]

Op zondag 03 maart 2002 23:29 schreef wallyberk het volgende:
(PS ga er even vanuit dat consumentenvraag 5 is om je model te testen. De enige reden namelijk waarom er een wilekeurige consumentenvraag in staat is dat je niet vooraf de vraag kan bepalen en dus steeds geen voorraad overhoud en geen backlog hebt, je bestel immers dan steeds voldoende. het maakt voor het model niet uit of je echt een willekeurig getal neemt (test heel moeilijk ) of het gemiddelde neemt (test heel makkelijk ))

Een vorm van LP is idd zeker een manier om het te doen, maar het is denk ik een beetje kort door de bocht om altijd 5 te nemen voor de vraag, niet alleen kan je bij een 100% voorspelbare vraag een echte optimale oplossing bedenken, maar ook schopt de stochastiek de boel behoorlijk in de war - als in het extreme geval steeds om de beurt 1 en dan 10 als vraag hebt zal je veel te veel neeverkoop kunnen krijgen.

[Verwijderd]

Hmmm.. Volgens mij gaat dit toch niet echt werken, omdat in de praktijk de consumentenvraag natuurlijk volgens een normale verdeling verloopt, terwijl in dit project de consumentenvraag volgens een uniforme verdeling verloopt. De vraag is immers willekeurig. Zo'n vraag van 5 aannemen om te testen lijkt me dus ook niet echt een oplossing, omdat de kans dat de consumentenvraag ook daadwerkelijk 5 is, slechts 10% is...

Ik denk iig dat ik een meer modelmatige benadering nodig heb, de brute-force-methode die in dit topic al voorgesteld is, lijkt me heel redelijk. Zaak is het alleen om daar een goede heuristiek voor te vinden...