Hallo,
bin auf der Suche nach Informationen, wie man die Optimale Bevorratung darstellen kann. Bereich: Reparaturen.
Welche Daten werden alle benötigt?
Zum einen schätze ich mal den Lagerbestand, Bestellungen.
Ziel soll eine grafische Darstellung ähnlich wie beim Break-even-Punkt sein.
Diese Darstellung und Auswertung soll vorallem auch zur Steuerung genommen werden.
Habe sonst leider noch keine Idee, wie man sowas macht.
Danke für Infos und Tipps.
Gruß
Markus
Forum
Optimale Bevorratung darstellen
Gesperrt
Seite: 1
Autor | Beitrag |
---|---|
#1 25.06.2009 16:10 Uhr
|
|
Mitglied
Registriert: Apr 2008
Beiträge: 9
|
|
#2 25.06.2009 16:18 Uhr
|
|
Mitglied
Registriert: Apr 2004
Beiträge: 7407
Ort: Erfurt
|
Bitte erstmal in http://www.bwl-bote.de/20090512.htm gucken. Ich kenne Deine Probkematik nicht im einzelnen, aber das könnte helfen?
|
#3 25.06.2009 16:22 Uhr
|
|
Mitglied
Registriert: Apr 2008
Beiträge: 9
|
Hallo,
danke. Hmm, wieder erwischt, Lagerkosten ist nach wie vor ein relativ unbeantwortetes Thema. Aber der Link sieht interessant aus. Dank. Gruß Markus |
#4 25.06.2009 16:24 Uhr
|
|
Mitglied
Registriert: Apr 2004
Beiträge: 7407
Ort: Erfurt
|
Die Gemeinkosten im Lager müssen auf jeden Fall bekannt sein, wenn man eine optimale Bestellmenge berechnen will. Ein ordentlicher BAB ist also die Grundvoraussetzung, ohne die sich in der Richtung nix bewegt.
Bei vielen Kleinteilen oder Schnelldrehern kann man auch per Normalverteilugn rechnen; das ist rein sicherheitsorientiert und hat keine Kostenkomponente. Daher ist es aber auch oft unwirtschaftlich. |
#5 25.06.2009 16:39 Uhr
|
|
Mitglied
Registriert: Apr 2008
Beiträge: 9
|
Hallo,
die nächste Schwierigkeit sehe ich in der Problematik, das Geräte ja von Zeit zu Zeit auslaufen und die Ersatzteile nicht mehr so stark bzw. gar nicht mehr bevorratet werden müssen. Leider gibt es aber keinen genauen Endzeitpunkt. Wie kann man so eine Problematik abfangen? Gruß Markus |
#6 25.06.2009 16:47 Uhr
|
|
Mitglied
Registriert: Apr 2004
Beiträge: 7407
Ort: Erfurt
|
Wenn man die Groff-Methode verwenden kann, was ich im konkreten Fall natürlich nicht wissen kann, dann würde der Bedarf sinken und die Zahl der Bestellvorgänge kleiner werden. Das führt zu einem langsamen Rückgang der Bestellmengen. Gegen ein plötzliches Ende der Nachfrage gibt es aber keine Methoden. Die Groff-Methode kann sich nur einer Bedarfsschwankung anpassen und die Anzahl der u.U. noch auf Lager befindlichen, aber nicht mehr gebrauchten Gegenstände verringern.
|
#7 25.06.2009 17:03 Uhr
|
|
Mitglied
Registriert: Apr 2008
Beiträge: 9
|
Hallo,
ein plötzliches Ende habe ich bisher noch nicht gehabt. Es läuft halt "irgendwie" aus. Was bei sporadischem bzw. stark schwankenden Verlauf sehr schwierig zu berechnen ist. Muss mal schauen, wie ich das umsetzte. Habe bisher eher als "Baukasten" modelliert. Gruß Markus |
#8 25.06.2009 17:05 Uhr
|
|
Mitglied
Registriert: Apr 2004
Beiträge: 7407
Ort: Erfurt
|
Ja, dann müßten die Bedarfszahlen langsam zurückgehen und die Zeithorizonte länger werden. Groff sollte das im Prinzip berücksichtigen...
|
#9 25.06.2009 17:17 Uhr
|
|
Mitglied
Registriert: Apr 2004
Beiträge: 7407
Ort: Erfurt
|
Noch ein Tip: Du kannst ja mal eine Groff-Rechnung machen, und irgendeinen GK-Zuschlag annehmen. Die Ergebnisse, die Du dann kriegst, sind vielleicht zahlenmäßig nicht richtig, aber Du lernst doch die Denk- und Funktionsweise des Verfahrens kennen. Das wäre ein Anfang. Vor einem realen Einsatz mit Echtdaten muß aber der GK-Zuschlag ermittelt werden...
|
#10 26.06.2009 10:22 Uhr
|
|
Mitglied
Registriert: Apr 2008
Beiträge: 9
|
Hallo,
danke, werde mehr mal damit simulieren. Auch habe ich ein Problem beim Eisernen Bestand EB, den haben wir nicht und wollen ihn auch nicht. Na, vielleicht kann man das irgendwie ummünzen. Gruß Markus |
flying Horst
|
#11 26.06.2009 13:41 Uhr
|
Gast |
Groff funzt mit und ohne eisernen Bestand
|
#12 26.06.2009 13:59 Uhr
|
|
Mitglied
Registriert: Apr 2008
Beiträge: 9
|
Hallo,
stimmt, habs auch in der Beschreibung dazu gelesen. Gruß Markus |
Gesperrt
Seite: 1
Parse-Zeit: 0.0306 s · Memory usage: 1.48 MB · Serverauslastung: 1.37 · Vorlagenbereich: 2 · SQL-Abfragen: 8