Groups | Search | Server Info | Keyboard shortcuts | Login | Register

Groups > de.comp.lang.javascript > #4747

Re: Rechenweg gesucht

Show all headers | View raw

Am 14.02.2016 um 21:47 schrieb Peter J. Holzer:
> On 2016-02-14 16:41, Maik Koenig <usenetspam@maikkoenig.de> wrote:
>> Am 14.02.2016 um 15:36 schrieb Peter J. Holzer:
>>
>>>> Es muss nur soweit sinken das Math.round(c) um 1 kleiner wird. Also
>>>> wäre c=3,6 zu c=3,4 ein gewünschtes Ergebnis.
>>> 
>>> Ist dieses gerundete c ein Wert, der an die Buchhaltung zwecks
>>> Lohnberechnung gemeldet wird? Dann macht es natürlich für den Arbeiter
>>> Sinn, das (auf Kosten des Arbeitgebers) zu optimieren.
>>
>> Lach. Nein, ist es nicht. Die Lohnbuchhaltung bekommt c nie zu Gesicht.
> 
> Naja, nicht direkt, aber so wie Du das schilderst

Auch dann nicht unbedingt, denn:

>> Aus der Luft gegriffenes Beispiel, die echten Zahlen sind andere:
>>
>> c = 3.6 ist gerundet 4 und das bedeutet man hat pro Teil 1,90 Minuten.
>> c = 3.4 ist gerundet 3 und das bedeutet man hat pro Teil 2,22 Minuten.
> 
> indirekt: Es wird der gerundete (und nicht der exakte) Wert verwendet,
> um die Vorgabezeit zu berechnen.

Ja, aber dummer Weise ist der Akkord der Maschine noch deutlich
komplizierter, da auch noch ein Unterschied gemacht wird ob 1 oder 2
Mitarbeiter an der Maschine stehen. Die Arbeitszeit des zweiten fliesst
in den Akkord ein. Und wichtiger: Während zwei Mitarbeiter an der
Maschine stehen, gibt es andere Zeiten pro Teil um der Tatsache gerecht
zu werden, dass man zu zweit ca 20% mehr Teile schafft (weniger Leerlauf
der Maschine: Einer kann das Teil wegbringen während der nächste einen
weiteren Streifen einlegt etc).

Der zweite Mitarbeiter steht aber nicht unbedingt permanent mit an der
Maschine weil er manchmal noch andere Aufgaben erfüllen soll. Also muss
man beim Aufschreiben streng aufpassen was jetzt zu zweit und was
alleine geschnitten wurde, denn auch wenn c für die ganze Schicht gilt,
die aus c hergeleiteten Zeitfaktoren für zwei Mann und für einen gelten
auch nur für die jeweils zu zweit bzw alleine geschnittenen Teile.

Hinzu kommen diverse Vorgabezeiten für verschiedene Tätigkeiten. So hat
man zum Beispiel rechnerisch 1,5 Minuten um einen vollen Teilestapel
abzufahren und einen neuen leeren vorzubereiten. Was eine ziemlich
knappe Geschichte ist um ehrlich zu sein.

Wie gesagt, es ist zum Feierabend eine fürchterliche Rechnerei bei der
mir irgendwann der Kragen platzte und ich es mir vereinfacht habe. Heute
muss ich nur noch eine Tabelle ausfüllen und das Script gibt mir alle
Daten die ich brauche.

Hinzu kommen noch einige Felder für zusätzliche Aufgaben die zum
Arbeitsplatz dazu gehören und feste Zeitvorgaben haben und ich habe per
Ausdruck alles was man für den Lohnbeleg benötigt.

Glücklicher Weise haben meine Vorgesetzten kein Problem damit, dass ich
sowas bastel solange die Arbeit nicht darunter leidet.

> Am Ende der Schicht kommt also sowas raus wie 
> Arbeiter A hat 270 Stück produziert (à 1.9 Min = 513 Min = 107 %)
> Arbeiter B hat 238 Stück produziert (à 2.22 Min = 528 Min = 110 %)
> ...
> 
> Im schlimmsten Fall entscheidet dann ein Stück mehr oder weniger, ob man
> für die ganze Schicht 1.9 Min oder 2.22 Min pro Stück bezahlt bekommt.

Genau. Das ist ja die eigentliche Begründung für mein Ansinnen.

> Aber ich stelle fest, dass erstens die Formel offenbar nicht
> proportional ist (2.22 ist deutlich weniger als 1.9 * 4/3) 

Die Zeiten sind ursprünglich aus einer Formel entstanden in der feste
Werte wie das Heranführen der Platte und vieles andere eingeflossen
sind. So braucht die Maschine z.B., wenn die nächste Platte herangeführt
wird, grundsätzlich eine feste Zeit bis zum ersten Schnitt. Das ist auch
nicht vom Bediener zu beeinflussen.

> und Du weiter
> unten von Werten zwischen 10 und 20 sprichst. Die Sprünge, die durch das
> Runden entstehen, sind also deutlich kleiner.

Ja, sind sie. Die Rundungsverluste sind abhängig von der eigentlichen
Größe von c und damit dem Zeitfaktor. Je größer c wird desto kleiner
werden die Zeitfaktoren. Ein durchschnittliches c liegt zwischen 15 und
18 aber ich hatte auch schon Tage mit deutlich mehr und weniger.

> Wenn ich das also richtig verstehe, ist die Aufgabe, herauszufinden,
> wieviele Stück man bis zum Ende der Schicht aus wievielen Platten
> schneiden muss, um sein Akkordziel zu erreichen. Möglichst so, dass der
> Arbeitsaufwand dabei minimal wird.

Treffer. Es macht nur wenig Sinn bei knappen Akkord eine Platte mit 2
Teilen aufzuschneiden da das rechnerisch nur selten reicht um c zu
senken und damit den Zeitfaktor hoch genug zu treiben um sein Ziel zu
schaffen. Aber es kann durchaus sein dass es Sinn macht 4 Platten mit
insgesammt 13 Teilen zu schneiden oder 1 Platte mit 20.

Der Rechner zeigt bereits an, wieviele Teile man bei gleichbleibendem c
noch schneiden müsste und erlügt sich daraus auch die Anzahl der
Platten. "Erlügt" weil c ja nicht gleichbleiben muss sondern sich
durchaus noch ändern kann.

> Ich glaube, Deine ursprüngliche Gleichung leistet das nicht. Nicht nur
> wegen dem -1, das das Rundungskriterium nicht richtig abbildet, sondern
> vor allem, weil sie die Vorgabe, ein gewisses Produkt aus Stückzahl und
> Stücklohn zu erreichen, nicht abbildet.
> 
> Ich würde da einen anderen Ansatz verfolgen:
> 
> Gegeben sind: 
> 
>  * Die bereits erzeugten Teile
>  * Die bereits verbrauchten Platten
>  * Das Akkordziel (also z.B. 110% = 528 Minuten)
>  * Den Zeitwert für jedes Verhältnis Teile/Platten (vielleicht als
>    Formel, vielleicht als Array)

Das ist ein bereits existierendes Array.

> Dann erhöhst Du in einer Schleife die Anzahl Platten ab 1 und
> berechnest, wieviele Teile Du aus diesen schneiden müsstest, um Dein
> Ziel zu erreichen:
> (...)

Das wäre das was ich vorhatte, ja. Ich hatte wie geschrieben gehofft,
dass man das mit einer Formel vereinfachen könnte ;(.

Greetz,
MK
-- 
Kopp-Verlag-Gläubige, Religionsdeppen, rechte Vollidioten
 und ähnlicher Bio-Abfall werden ohne Hinweis ignoriert!

Back to de.comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Rechenweg gesucht Maik Koenig <usenetspam@maikkoenig.de> - 2016-02-13 04:13 +0100
  Re: Rechenweg gesucht Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2016-02-13 11:18 +0100
    Re: Rechenweg gesucht Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2016-02-13 11:41 +0100
      Re: Rechenweg gesucht Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2016-02-13 11:51 +0100
        Re: Rechenweg gesucht Maik Koenig <usenetspam@maikkoenig.de> - 2016-02-13 18:47 +0100
    Re: Rechenweg gesucht Maik Koenig <usenetspam@maikkoenig.de> - 2016-02-13 16:27 +0100
      Re: Rechenweg gesucht "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2016-02-13 17:58 +0100
        Re: Rechenweg gesucht Maik Koenig <usenetspam@maikkoenig.de> - 2016-02-13 18:59 +0100
          Re: Rechenweg gesucht "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2016-02-14 15:36 +0100
            Re: Rechenweg gesucht Maik Koenig <usenetspam@maikkoenig.de> - 2016-02-14 17:41 +0100
              Re: Rechenweg gesucht "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2016-02-14 21:47 +0100
                Re: Rechenweg gesucht Maik Koenig <usenetspam@maikkoenig.de> - 2016-02-15 02:27 +0100
                Re: Rechenweg gesucht Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-15 20:02 +0100
      Re: Rechenweg gesucht Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2016-02-13 18:17 +0100
        Re: Rechenweg gesucht Maik Koenig <usenetspam@maikkoenig.de> - 2016-02-13 19:00 +0100
  Re: Rechenweg gesucht Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-13 19:23 +0100
  Re: Rechenweg gesucht Robin Koch <robin.koch@t-online.de> - 2016-02-17 13:46 +0100

csiph-web