Die Dokumentation ab Version 39.5.17 von PLANTA project finden Sie in der neuen PLANTA Online-Hilfe.

Beispiel für die Berechnung von Rest-Aufwand und Überlast

Informationen

  • Anhand des nachfolgenden Beispiels wird erklärt, warum die Projekteinzelrechnung und die Neuplanung (Berechnung aller Projekte) im Hinblick auf Rest-Aufwand und Überlast zu unterschiedlichen Ergebnissen kommen.

Ausgangslage

  • Es gibt zwei einfache Projekte (beide termintreu), die beide dieselbe Ressource zur selben Zeit belasten, und zwar jeweils mit 18 Stunden.
  • Einziger Unterschied: Ein Projekt hat eine höhere Priorität (sehen Sie dazu bitte den Namen der Projekte).

Projekt_hoehere_Prio.png

Projekt_niedrigere_Prio.png

  • Die Ressource verwendet die Belastungskurve CAP bei einer maximalen Belastung von 7,2 Stunden pro Tag und wird von keinem anderen Projekt verwendet.

Neuplanung

  • Zunächst wird berechnet, wie viele Tage für diese Projekte benötigt werden.
    • In beiden Projekten wären das bei einer Gesamtdauer von 18 Stunden und 7,2 Stunden Maximalbelastung 18 / 7.2, also aufgerundet 3 Tage.
  • In dem höher priorisierten Projekt werden nun die 18 Stunden auf diese drei Tage verteilt, bis alle Kapazitäten zu 100% ausgelastet ist bzw. alle Stunden verplant sind:

Planung_hoehere_Prioritaet.png

  • Ebenso im niedriger priorisierten Projekt.
  • Da jetzt aber nur noch am dritten Tag Kapazität frei ist, werden zuerst auch nur dort 3,6 Stunden verplant.
    • Das führt zu dem folgenden „unsichtbaren“ Zwischenstand in der Terminrechnung, zu dem alle Kapazitäten voll ausgelastet sind:

Zwischenstand_niedrigere_Prioritaet.png

  • Jetzt sind noch 18 Stunden – 3,6 Stunden = 14,4 Stunden Rest-Aufwand übrig, für den keine Kapazität mehr zur Verfügung steht.
    • Dieser Rest-Aufwand (14,4 Stunden / 3 Tage = 4,8 Stunden je Tag) wird auf alle Tage addiert, wodurch eine gleichmässige Überlast von 4,8 Stunden pro Tag entsteht.
  • Das Endergebnis nach der Neuplanung sieht also so aus:

Endergebnis_niedrige_Prioritaet.png

Einzelplanung des höher priorisierten Projekts

  • Hier nochmal der Zustand des höher priorisierten Projekts nach der Neuplanung:

Planung_hoehere_Prioritaet.png

  • In der Terminrechnung wird das Projekt intern zunächst komplett entlastet.
  • Dann werden wiederum alle vorhandenen Tage so weit ausgelastet, bis entweder der gesamte Rest-Aufwand verplant ist oder alle Kapazitäten zu 100% belegt sind.
    • Da durch das andere Projekt die ersten zwei Tage bereits mit 4,8 Stunden belegt sind, können dort jeweils noch 2,4 Stunden eingelastet werden.
    • Am dritten Tag ist die Ressource durch das andere Projekt bereits mit über 100% überlastet, also keine Kapazität mehr vorhanden.
  • Somit ergibt sich bei der Terminrechnung folgender „unsichtbarer“ Zwischenstand, zu dem alle Kapazitäten voll ausgelastet sind:

Neuplanung_hoehere_Prio.png

  • Jetzt sind noch 18 Stunden – 2,4 Stunden – 2,4 Stunden = 13,2 Stunden Rest-Aufwand übrig, für den keine Kapazität mehr zur Verfügung steht.
  • Dieser Rest-Aufwand (13,2 Stunden / 3 Tage = 4,4 Stunden je Tag) wird auf alle Tage addiert, wodurch eine gleichmässige Überlast von 4,4 Stunden pro Tag entsteht.
  • Das Endergebnis nach der Einzelrechnung sieht also so aus:

Einzelrechnung_hoehere_Prio.png

Schlussfolgerung

  • Wie aus diesem Beispiel zu erkennen ist, kann sich bei der Einzelrechnung eines Projekts sowohl der Rest-Aufwand als auch die Überlast ändern, selbst, wenn es sonst keinerlei Änderung der Daten im System gegeben hat.
    • Es wird in diesem Fall eine allgemein zu hohe Überlast, über beide Projekte verteilt, ausgewiesen.
      • Das liegt daran, dass die Terminrechnung bei der Einzelberechnung eines Projekts zwar ermitteln kann, wann die Ressourcen belegt sind, aber nicht, von welchen anderen Projekten.
      • Da die Priorität der vorhandenen Belastung daher nicht bekannt ist (und da die Überlast der anderen Projekte nicht neu berechnet werden kann), wird immer davon ausgegangen, dass bereits vorhandene Belastungen höher priorisiert sind und neue Belastungen darauf hinzugefügt werden – was wiederum zu den oben beschriebenen Effekten führt.
Topic attachments
I Attachment History SizeSorted descending Date Comment
Pngpng Projektdaten_Terminplan.png r1 39.5 K 2019-03-18 - 10:52  
Pngpng Einzelrechnung_hoehere_Prio.png r1 18.0 K 2019-03-18 - 11:11  
Pngpng Endergebnis_niedrige_Prioritaet.png r1 17.7 K 2019-03-18 - 11:04  
Pngpng Neuplanung_hoehere_Prio.png r1 17.7 K 2019-03-18 - 11:09  
Pngpng Planung_hoehere_Prioritaet.png r1 17.6 K 2019-03-18 - 10:58  
Pngpng Zwischenstand_niedrigere_Prioritaet.png r1 17.1 K 2019-03-18 - 10:59  
Pngpng Projekt_niedrigere_Prio.png r1 12.3 K 2019-03-18 - 12:15  
Pngpng Projekt_hoehere_Prio.png r1 12.2 K 2019-03-18 - 12:15  

         PLANTA project









 
  • Suche in Topic-Namen

  • Suche in Topic-Inhalten
This site is powered by the TWiki collaboration platform Powered by Perl