Best Practice: Konzeptfindung Wartungskalender

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Best Practice: Konzeptfindung Wartungskalender

    Hi,

    Wir sind gerade dabei unsere Wartungsplanungs Software zu erweitern, dass Sie auch Mittagspausen und Übernachtungen korrekt mit plant und grafisch darstellt. Bisher werden Übernachtungen einfach durch entsprechendes verlängern des eigentlichen Jobs über Nacht erreicht, was aber nicht sicher nicht optimal ist.

    Bisher gibt es eine Klasse Job welche im wesentlichen folgende Attribute besitz:

    Jobnummer
    Techniker
    System (aus diesem wiederum bekommt man die Site und den zugrundeliegenden Vertrag für die Wartung und die Spezifikationen für das System)
    JobType
    JobSubtype
    JobScheduleType (aus diesen drei Werten ist ersichtlich was zu tun ist und welchen Skill und Trainings der Techniker braucht)
    Duration (in minuten)
    TraveltimeTo
    TraveltimeFrom
    StartDateTime
    EndDateTime

    Letzterer Wert berechnet sich nun aus recht komplizierten frei konfigurierbaren Werten. Im einfachsten Fall ist das halt
    StartDateTime + TraveltimeTo + Duration + TraveltimeFrom. Spricht Techniker fährt morgens von zu Hause zur Site, macht die Wartung und fährt wieder nach Hause. Das alles innerhalb von maximal 10 Stunden die er an einem Tag laut Gesetz arbeiten darf.

    Nun werden aber sehr oft mehrere Jobs an einem Gerät und/oder einer Site kombiniert. Hier wird dann u.U. Eben auch eine Übernachtung eingeplant und das Ergebnis wäre eine Kette von sagen wir drei Jobs.
    Ein Beispiel: Sagen wir die Fahrzeit wäre 1h und die Jobs würde 6, 4 und 2 Stunden dauern. Dan würde der Kollege morgens um 8uhr losfahren, um 9 anfangen den ersten Jobs zu machen. Um 12 würde er 45min Mittag machen und Hätte dann um 15:45 den ersten Job fertig und bis dahin 7h gearbeitet. Er würde also vom zweiten Job noch eine Stunde machen und dann wäre Feierabend. Er übernachtet vor Ort und fängt am nächsten morgen um 8 wieder an. Dann macht er die letzten 3 Stunden von Job 2, die erste Stunde von Job drei und dann wieder 45min Mittag. Danach macht er die letzte Stunde von Job drei und danach fährt er 1 Stunde nach Hause.

    Weiterhin gibt es auch Einzelne Jobs die 14, 16 oder sogar bis zu 40 Stunden(also eine komplette Woche) dauern können. Dann gibt es noch jede Menge Sonderregelungen wie z.b. Wenn der Job innerhalb von 10h inklusive An- und Abfahrt gemacht werden kann. Dann wird nicht übernachtet sondern die Überstunden geplant. Und noch einiges mehr. Das ist hier aber jetzt nicht so relevant.

    Mir geht es mehr um die Strukturierung der Jobklasse um sie flexibler zu machen.

    Ich dachte, dass ich das Gnze dreiteile. Oberste Schicht wäre eine Klasse MultiJobGroup. Diese beinhaltet alle Jobs die hintereinander gemacht werden. Also die eigentlich Kette. Diese besteht aus einer Liste von MultiJobs. Diese Klasse ist alles was unter einer Jobnummer läuft. Also quasi ein abgeschlossener Job. Sie beinhaltet eine Liste von Samples die im Prinzip eine Liste von verschiedene Activities beinhaltet die da wären TravelTimeSample, RestSample, OvernightSample und JobSample

    Die Große Herausforderung ist dann, das Echtzeit Drag & Drop im Editor. Wenn ich da einen Job aufgreife und verschiebe, dann müssen sich die Sample alle in Echtzeit an die neue Startzeit und den neuen Techniker (der ja eine andere Fahrzeit hat als der alte) anpassen. Das bedeutet in dem Fall eine ziemliche Änderung dieser Struktur bei jedem Pixel Bewegung. Hier stellt sich die Frage wie performant das wird. Es ist ja z.B. Auch ein normaler use case, dass man dabei eine Kette von Jobs aufbricht oder zu einer Kette eine andere hinzufügt.

    Weiterhinfrage ich mich wie ich das ganze am besten persistiere. Im Moment ist ein Job halt eine Zeile in einer SQL Datenbank. Soll ich meine Samples dann in eigene Tabellen packen und mit ganz vielen Joins arbeiten? Wird bestimmt nicht besonders performant. Ich könnte auch jeder Kette eine eigenen UniqueId verpassen und dann die Jobs und Samples durch ihre Jobnummer erkennen und beim SELECT einfach nach UniqueId Jobnummer und StartDateTime sortieren. Dann bekomme ich meine einzelnen Samples in der richtigen Reihenfolge geliefert und kann sie zusammenbauen ohne das ich joins brauche. Dürfte um einiges schneller sein aber vielleicht rächt sich das später?
    Wir reden hier übrigens von einer Größenordnung von ca. 10000 Jobs. Also jetzt keine Mammut Zahl.

    Was meint ihr? Vielleicht kommen ja auch noch ganz andere gute Ansätze die man verfolgen kann?

    Gruß

    Claus

    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Wenn die Anfahrt/Rückfahrt nur eine Stunde beträgt, so fährt man doch nach Hause (vor allem als Familienvater - naja, oder eben genau dann nicht ;-)).
    Die Grenze solcher Zeiten sollte doch auch noch für jeden Mitarbeiter anders sein oder nicht?
    Und dann sollte die SW doch auch Folgeaufträge an Sites in de Nähe des letzten Auftrages mit berechnen (vor allem wenn die Anfahrt länger dauert)...?
  • gritsch schrieb:

    Wenn die Anfahrt/Rückfahrt nur eine Stunde beträgt, so fährt man doch nach Hause (vor allem als Familienvater - naja, oder eben genau dann nicht ;-)).
    Die Grenze solcher Zeiten sollte doch auch noch für jeden Mitarbeiter anders sein oder nicht?
    Und dann sollte die SW doch auch Folgeaufträge an Sites in de Nähe des letzten Auftrages mit berechnen (vor allem wenn die Anfahrt länger dauert)...?
    Naja es bleibt dem Techniker dann ja selbst überlassen nach Hause zu fahren aber das ist dann arbeitsrechtlich nicht abgesichert und wird auch nicht bezahlt. Zwei Techniker Überstunden sind halt u.U. teurer als eine Übernachtung .
    Aber wie gesagt es gibt da jede Menge weitere Regeln die ich nicht alle im einzelnen anführen möchte. Das ändert ja auch nichts daran wie es intern aussehen muss
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)