Die Dokumentation ab Version 39.5.17 von PLANTA project finden Sie in der neuen PLANTA Online-Hilfe.
Bitte beachten Sie
  • Nachfolgend finden Sie beispielgestütze Erläuterungen der Funktionsweise der Terminplanung und - rechnung in PLANTA project sowie Beschreibungen der häufigen Anwendungsfälle und des Verhaltens bei bestimmten Einstellungen. Die hier verwendeten Programmabbildungen basieren auf einem älteren Software-Stand und sollen rein funktional betrachtet werden.
  • Die detaillierte Informationen zu der Termin-, Ressourcen- und Kostenplanung in PLANTA project inklusive Berechnungswendungsmatrix finden Sie hier.

Termin/Ressourcenplanung und -rechnung

Anwendungsfälle

Anwendungsfälle für Planungsstrategien

Prämissen:
  • Aktive Heutelinie, Fixierung = 0, Planung früh, CAP (sofern nichts anderes genannt wird)
Beschreibung Termintreu Gesamtpuffertreu Kapazitätstreu
Zielsetzung Wie viel Überlast entsteht bei den Mitarbeitern, wenn die Termine gehalten werden sollen? Wie viel Puffer ist verfügbar? Wie viel Überlast entsteht bei den Mitarbeitern, wenn die Termine gehalten werden? Wie lange dauern die Vorgänge unter Berücksichtigung von Kapazität und Wunschterminen? Wie lange dauert ein Projekt bei vorgegebenem Aufwand und begrenzter Kapazität (keine Überlasten)?
Beschreibung der Planungsmethodik Vorgangsdauern und Termine werden gehalten. Sind die Vorgangsdauern länger als der verbleibende Zeithorizont, verschiebt sich der Endtermin.
Überlasten werden ausgewiesen
Dem Projekt wird ein Wunschendtermin gegeben.
Die Dauer-Rest des Vorgangs wird entsprechend des Ressourcenaufwands ausgerechnet. Puffer werden ausgenutzt. Es findet eine Glättung der Überlasten statt. Endtermine werden gehalten, sofern der verbleibende Zeit-Horizont für die Dauer-Soll des Vorgangs ausreicht.
Die Dauer eines Vorgangs wird ermittelt aus
  • Aufwand
  • verfügbarer Kapazität
  • Bel.-Kurve CAP
  • Option: Planung mit max.Bel/Tag
Planung Üblicherweise werden Dauer-Soll oder alternativ Wunsch-Anfang - Wunsch-Ende eingetragen (Wunsch-Anfang - Wunsch-Ende dominiert die Dauer-Soll).
Wenn keine Dauer-Soll eingegeben ist, wird diese durch Wunsch-Anfang - Wunsch-Ende berechnet.

Planung ohne Belastungskurven: Bei Eingabe der Dauer-Soll des Vorgangs wird der Aufwand Soll der Ressource auf die Dauer gleichmäßig verteilt.

Wenn KEINE Dauer-Soll des Vorgangs eingetragen ist, errechnet das System die Dauer-Rest des Vorgangs mittels des Aufwands der Ressource, CAP-Belastungskurve und Max. Bel./Tag.
Üblicherweise werden Dauer-Soll oder alternativ Wunsch-Anfang - Wunsch-Ende eingetragen.
Wenn keine Dauer-Soll eingegeben ist, wird diese mit Wunsch-Anfang - Wunsch-Ende berechnet.

Bei Eingabe der Dauer-Soll des Vorgangs wird der Aufwand-Soll der Ressource auf die Dauer gleichmäßig verteilt.

Wenn KEINE Dauer-Soll des Vorgangs eingetragen ist, errechnet das System die Dauer-Rest des Vorgangs mittels des Aufwands der Ressource, CAP-Belastungskurve und Max. Bel./Tag
Unabhängig davon, ob die Dauer-Soll eingetragen worden ist oder nicht, verlängert sich die Dauer-Rest , sofern der Aufwand-Soll nicht in der vorgegebenen Zeit möglich ist bzw. soweit Puffer vorhanden sind.
Der Wunschtermin wird unter Berücksichtigung der AOBs überschritten, wenn die Vorgänger in der Dauer zu lang sind.
Keine Eingabe von Vorgangsdauer oder VG Wunsch-Anfang/Wunsch-Ende notwendig. Lediglich Eingabe von Aufwand in h bei den zugeteilten Ressourcen, Parameter siehe oben.
Bei Vorgängen mit Ressourcenzuordnungen:.

Vorgänge verlängern, bevor MA rückgemeldet hat.
Um die Vorgangsdauer in Tagen zu verlängern, bevor rückgemeldet wurde, wird die Dauer-Soll des Vorgangs erhöht. Alternativ kann auch der Aufwand erhöht werden, wenn die Belastungskurve CAP ausgewählt wurde.

Um den Aufwand der Ressource vor der ersten Rückmeldung zu erhöhen, wird der Aufwand-Soll erhöht.
Erhöhung der Dauer-Soll, oder des Aufwand-Solls auf Ebene Mitarbeiter, sofern die Belastungskurve CAP ausgewählt wurde. Der Aufwand-Soll wird auf Ressourcenebene erhöht, sofern die Belastungskurve CAP ausgewählt wurde.
Bei Vorgängen ohne Ressourcenzuordnungen:

Verlängern von Vorgängen ohne Ist-Anfangstermin.
Dauer-Soll auf Vorgangsebene erhöhen. Dauer-Soll auf Vorgangsebene erhöhen. Dauer-Soll auf Vorgangsebene erhöhen.
Bei Vorgängen ohne Ressourcenzuordnungen:

Verlängern von Vorgängen mit Ist-Anfangstermin.
Dauer-Rest auf Vorgangsebene erhöhen oder Wunsch-Ende verlängern.
Neu: Dauer-Rest wird abhängig vom Ist-Termin berechnet.
Dauer-Rest = Dauer-SollDauer-Ist , wobei:
Dauer-Ist = Heute - Ist-Anfangstermin.

Offene Vorgänge bleiben wie bisher mit 1 Tag Rest zur Erinnerung stehen.
Dauer-Rest auf Vorgangsebene erhöhen oder Wunsch-Ende verlängern.
Neu: Dauer-Rest wird abhängig vom Ist-Termin berechnet.
Dauer-Rest = Dauer-SollDauer-Ist , wobei:
Dauer-Ist = Heute - Ist-Anfangstermin.

Offene Vorgänge bleiben wie bisher mit 1 Tag Rest zur Erinnerung stehen.
 

Anwendungsfälle der Terminplanung ohne Ressourcen

Ziel

  • Einplanung der Vorgänge in Abhängigkeit einer vorgegebenen Vorgangs-/ Arbeitspaketdauer
Übersicht 1: Dauer-Soll = 0
Anwendungsfall Ablauf Ergebnis
Vorgang ohne Termine planen
  • Projekt kalkulieren
Vorgang mit Wunsch-Anfang planen
Vorgang mit Wunsch-Ende planen
Vorgang von .... bis .... planen siehe Übersicht 2  

Übersicht 2: Dauer-Soll > 0

Anwendungsfall Ablauf Ergebnis
Der Vorgang hat eine Durchlaufzeit in Tagen.
  • Eingabe der Tage ins Feld Dauer-Soll
  • Projekt kalkulieren
Vorgang wird eingeplant mit:
Variante: Durchlaufzeit mit definiertem Anfangstermin Vorgang wird eingeplant mit:
Variante: Durchlaufzeit mit definiertem Endtermin Vorgang wird eingeplant mit:
Der Vorgang hat eine Durchlaufzeit von .... bis .... mit definierten Start- und Endtermin (Ecktermine) Vorgang wird eingeplant mit:
Der Vorgang soll verschoben werden, wenn ein Vorgänger sich verschiebt.
Durchlaufzeit entweder durch Ecktermine oder Vorgabe in Tagen, Fixierung = 0
  • Vorgang mit Anfangs- und / oder Endtermin einplanen und / oder Dauer-Soll eintragen
  • Vorgänger mit Vorgang verknüpfen
  • Projekt kalkulieren
Vorgang wird eingeplant mit:
  • Anfangs-/Endtermine und Dauer-Rest je nach Vorgabe
  • Verschiebung des Vorgängers bewirkt Verschiebung des Vorgangs.

Verhalten VG-Wunschtermine und VG Dauer-Rest bei gesetztem VG Ist-AT

Details Beispiel Terminplanung ohne Ressourcen
  • Ausgangssituation
GR01502897-DE.png

GR01502898-DE.png

GR01502902-DE.png

GR01502901-DE.png

Anwendungsfälle der Terminplanung mit Ressourcen

Zeitbezogene Planung mit vorgegebener Vorgangsdauer

Vorgaben
  • Dauer-Soll
  • keine Verwendung von Belastungskurven, d. h. die Belastung wird gleichmäßig ohne die Berücksichtigung von Überlasten auf den zur Verfügung stehenden Zeitraum verteilt.
  • An Nicht-Arbeitstagen (Feiertage, Urlaube, ...) werden Ressourcen nicht eingelastet.

Ergebnis

  • bei termintreuen Einplanung
    • Einplanung entlang der Dauer ohne Berücksichtigung von Überlasten.
    • Die Einplanung erfolgt nach Möglichkeit im Block, d. h. ohne Unterbrechung. Ausnahme Urlaub: Die Ressource wird im Urlaub nicht eingeplant.
  • bei gesamtpuffertreuen Einplanung
    • Die Einplanung erfolgt entlang der Dauer ohne Berücksichtigung von Überlasten, aber mit Ausnutzung Puffer pro Ressource die überlastet ist.
    • Sind noch Stunden einzuplanen, aber der Puffer ist aufgebraucht, erfolgt die Einplanung zum spätestmöglichen Zeitpunkt. Der Projekt-Wunschendetermin wird nicht überschritten.
  • bei kapazitätstreuen Einplanung
    • Standard: Die Einplanung erfolgt ohne Berücksichtigung von Wunschdauern und Projektwunschend-Terminen, keine Überlasten, keine Einplanung an nichtverfügbaren Tagen.
      • Ausnahme: Wird keine keine verfügbare Kapazität bis zum Ende der Planungsperiode der Ressource gefunden, dann wird zum frühestmöglichen Zeitpunkt auch mit Überlast eingelastet (wie termintreu).
Beispiel:
  • Überlast bei kapazitätstreuer Planung mit Endperiode früher als Dauer-Soll (Vorgaben: Dauer-Soll_ = 10 Tage, Aufwand-Soll_ = 100h, verfügbare Kapa. der Ressource pro Tag = 8h). Die Anforderung kann zu keinem Zeitpunkt erfüllt werden. Die Ressource wird gleichmäßig überlastet.

GR01502908-DE.png

Zeitbezogene Planung mit Wunschterminen der Ressource

Planung mit VGR Wunsch-Anfang
Information Beispiel
GR01501232-DE.png

Beispiel

GR01501233-DE.png

Information

Beispiel
  • Die Ressource R1 hat durch den VGR Wunsch-Anfang eine verkürzte Einplanungsdauer von 2 Tagen. Der Aufwand von 16 Stunden wird auf die beiden Tage verteilt und die Ressource überlastet. Bei Ressource R4 wird die Einplanung auf drei Tage ohne Überlast verteilt.
GR01501234-DE.png
  • Ist der Vorgang mit Plan. spät und termintreu geplant, wird der VG Wunsch-Anfang ignoriert.

Beispiel

  • Da der Vorgang Plan. spät und termintreu ist, wird der VGR Wunsch-Anfang ignoriert. Die Ressource wird an drei Tagen eingeplant.
GR01501235-DE.png
  • Ist der Vorgang gesamtpuffer- oder kapazitätstreu und Plan. spät, wird eine Ressource mit einem VGR Wunsch-Anfang nur bis zu diesem Termin abgeglichen; alle anderen werden wie bisher zum VG Frühester Anfang abgeglichen.

Beispiel

  • Obwohl die Ressource R1 überlastet ist, wird der Abgleich der Ressource nicht zum PR Wunsch-Anfang ausgeführt, sondern nur bis zum VGR Wunsch-Anfang.
GR01501236-DE.png
  • Hat ein Vorgang begonnen, beginnt die Ressource mit VGR Wunsch-Anfang an diesem Termin; alle anderen beginnen wie bisher. Bei Splittung gilt für den Frühester Anfang das Maximum aus VGR Wunsch-Anfang und AOB-Termin.

Beispiel

  • Die Ressource R1 hat einen VG Ist-Anfang am 16.10.08, startet aber mit der Rest-Einlastung erst zum VGR Wunsch-Anfang. Dies wird durch den Parameter DI 001112 Splitt. = J in Fenster 9 bestimmt. Dieser wirkt nur, wenn der Vorgang begonnen und noch nicht beendet wurde.
  • Die Ressource R8 startet wie bisher an der Heutelinie.
GR01502920-DE.png

Planung mit VGR Wunsch-Ende
Information
  • Ist nur eine Ressource zugeordnet, endet der Vorgang (VG Frühestes Ende) bei termintreuer Einplanung am VGR Wunsch-Ende, sofern keine Überlastung eintritt und die VGR-Termine innerhalb der VG-Termine liegen. Ansonsten ist die VG-Dauer = Aufwand-Soll / Max. Belastung/Tag. Z.B. bei kapazitätstreuer Einlastung wird der VG gegebenenfalls verlängert
  • Ist mehr als eine Ressource eingeplant, gilt die Dauer des Vorgangs; die Ressource mit einem VGR Wunsch-Ende erhält eine verkürzte Dauer aus VG Dauer-Rest – (VG Frühestes Ende – VGR Wunsch-Ende).
  • Hat eine Ressource ein VGR Wunsch-Ende, endet sie bei termintreuer Einplanung zu diesem Termin; alle anderen enden zum VG Frühestes Ende.
  • Ist der Vorgang Plan. spät, wird er automatisch termintreu, wenn ein VGR Wunsch-Ende zugeordnet ist.
  • Ist der Vorgang gesamtpuffer- oder kapazitätstreu und Planung früh, wird eine Ressource mit einem VGR Wunsch-Ende bis zu diesem Termin abgeglichen. Alle anderen werden zum VG Spätester Anfang + VG Dauer-Rest abgeglichen.

Planung mit VGR Wunsch-Anfang und VGR Wunsch-Ende
Information
  • Hat die Ressource einen VGR Wunsch-Anfang und ein VGR Wunsch-Ende und keine Max. Belastung/Tag, wird die Dauer bei termintreuer Einplanung aus den Wunschterminen ermittelt.
  • Bei kapazitätstreuer Einlastung wird der VG gegebenenfalls verlängert.
Hinweise
  • VGR-Wunschtermine werden nur innerhalb der VG-Wunschtermine durch die Terminrechnung beachtet. Liegt der VGR-Wunschtermin außerhalb der VG-Wunschtermine so wird er für die Terminrechnung nicht wirksam, da die Einplanung zu diesem Zeitpunkt nicht zielführend ist. Das gilt auch dann, wenn ein Vorgang, zum Beispiel durch eine AOB, so verschoben wird, dass nach der VG-Verschiebung die VGR-Wunschtermine innerhalb des VG Kalk. Anfang/VG Kalk. Ende liegen.
  • Sofern keine VG-Wunschtermine vorhanden sind, werden VGR-Wunschtermine nur innerhalb der VG Kalk. Anfang/VG Kalk. Ende beachtet.
Beispiel 1 Beispiel 2
  • Eine AOB verschiebt den oben genannten Vorgang wie folgt:
  • Ergebnis:
    • Die vorherige Planung der VGR-Wunschtermine wird ignoriert.
    • Die Einplanung der VGR muss nicht vom 10. – 15.09.08 erfolgen.

Übersicht Anwendungsfälle

Übersicht

  • Termintreue Planung mit linearer Belastungskurve
Anwendungsfall Ablauf Ergebnis
Ressource ohne Termine planen
  • Ressource zu Vorgang zuordnen
  • Aufwand eingeben
  • Projekt kalkulieren
Ressource mit Wunsch-Anfang planen
  • Ressource zu Vorgang zuordnen und Aufwand eingeben
  • Anfangstermin in Ressource (VGR Wunsch-Anfang) eintragen
  • Projekt kalkulieren
Hinweis
  • Die Einplanungszeit der Ressource ist ggf. kleiner als die Länge des Vorgangs.
Ressource mit Wunsch-Ende planen
  • Ressource zu Vorgang zuordnen und Aufwand eingeben
  • Endtermin in Ressourcen (VGR Wunsch-Ende) eintragen
  • Projekt kalkulieren
Hinweis
  • Die Einplanungszeit der Ressource ist ggf. kleiner als die Länge des Vorgangs.
Ressource mit VGR Wunsch-Ende planen
  • Ressource zu Vorgang zuordnen und Aufwand eingeben
  • Endtermin in Ressourcen (VGR Wunsch-Ende ) eintragen
  • Projekt kalkulieren
Hinweis
  • Die Einplanungszeit der Ressource ist ggf. kürzer als die Länge des Vorgangs.
Ressource von .... bis .... planen
  • Ressource zu Vorgang zuordnen und Aufwand eingeben
  • Anfangs- bzw. Endtermin in Ressourcen (VGR Wunsch-Anfang/Wunsch-Ende) eintragen
  • Grenzen der Vorgangstermine beachten
  • Projekt kalkulieren
Hinweis
  • Die Einplanungszeit der Ressource ist ggf. kürzer als die Länge des Vorgangs.

  • Gesamtpuffertreue Planung
Anwendungsfall Ablauf Ergebnis
Ressource ohne Termine planen
  • Ressource zu Vorgang zuordnen
  • Aufwand eingeben
  • Projekt kalkulieren
Ressource mit Wunsch-Anfang planen
  • Ressource zu Vorgang zuordnen und Aufwand eingeben
  • Anfangstermin in Ressourcen (VGR Wunsch-Anfang ) eintragen
  • Projekt kalkulieren
Hinweis
  • Die Einplanungszeit der Ressource ist ggf. kürzer als die Länge des Vorgangs.
  • Wird der Puffer benötigt, kann die Vorgangsdauer bzw. die Ressourcen-Einlastung nach hinten verlängert werden.
Ressource mit VGR Wunsch-Ende planen
  • Ressource zu Vorgang zuordnen und Aufwand eingeben
  • Endtermin in Ressourcen (VGR Wunsch-Ende) eintragen
  • Projekt kalkulieren
Hinweis
  • Die Einplanungszeit der Ressource ist ggf. kürzer als die Länge des Vorgangs.
  • Wird der Puffer benötigt, kann die Vorgangsdauer bzw. die Ressourcen-Einlastung nach vorne verlängert werden.
Ressource von .... bis .... planen
  • Ressource zu Vorgang zuordnen und Aufwand eingeben.
  • Anfangs- bzw. Endtermin des Vorgangs in Ressourcen (VGR Wunsch-Anfang/Wunsch-Ende) eintragen.
  • Grenzen der Vorgangstermine beachten
  • Projekt kalkulieren.
Hinweis
  • Die Einplanungszeit der Ressource ist ggf. kürzer als die Länge des Vorgangs.
  • keine Ausnutzung Puffer durch die Ressource innerhalb des Vorgangszeitraums.

  • Kapazitätstreue Planung
Anwendungsfall Ablauf Ergebnis
Ressource ohne Termine planen
  • Ressource zu Vorgang zuordnen
  • Aufwand eingeben
  • Projekt kalkulieren
Hinweis
  • Einplanungszeit der Ressource = Vorgangsdauer
  • Wird der Puffer benötigt, kann die Vorgangsdauer bzw. die Einplanungszeit der Ressource verlängert werden.
Ressource mit Wunsch-Anfang planen
  • Ressource zu Vorgang zuordnen und Aufwand eingeben
  • Anfangstermin in Ressourcen (VGR Wunsch-Anfang ) innerhalb der kalkulierten Anfangs- und Endtermine des Vorgangs eintragen.
  • Projekt kalkulieren
Hinweis
  • Die Einplanungszeit der Ressource ist ggf. kürzer als die Länge des Vorgangs.
  • Endtermine werden ggf. nicht berücksichtigt.
Ressource Wunsch-Ende planen
  • Ressource zu Vorgang zuordnen und Aufwand eingeben
  • Endtermin in Ressourcen (VGR Wunsch-Ende) innerhalb der kalkulierten Anfangs- und Endtermine des Vorgangs eintragen
  • Projekt kalkulieren
Hinweis
  • Einplanungszeit der Ressource ggf. kleiner Vorgangsdauer.
  • Anfangstermine werden nicht berücksichtigt.
Ressource von .... bis .... planen
  • Ressource zu Vorgang zuordnen und Aufwand eingeben
  • Anfangs- bzw. Endtermin in Ressourcen (VGR Wunsch-Anfang/Wunsch-Ende ) eintragen
  • Grenzen der Vorgangstermine beachten
  • Projekt kalkulieren
Hinweis
  • Einplanungszeit der Ressource ggf. kleiner Vorgangsdauer
  • Puffer wird wenn nötig verwendet. Keine Berücksichtigung des Endtermins.

Aufwandsorientierte Planung

Ziel
  • Einplanung der Mitarbeiter in Abhängigkeit des Aufwands
Voraussetzung:
  • Termintreue Planung:
    • Feld Bel.-Kurve = CAP
    • Feld max. Bel./TG gefüllt mit Wert > 0
    • Ressourcenzuordnung mit Stunden-Soll
  • Gesamtpuffer- und kapazitätstreue Planung:
    • Feld Bel.-Kurve = CAP
    • Ressourcenzuordnung mit Stunden-Soll
    • Optional: Feld gefüllt mit Wert > 0
Details
  • Die Dauer-Rest wird berechnet
  • Termintreue Planung:
    • Dauer-Rest = Stunden-Soll / max.Bel.
    • Der Aufwand (Stunden-Soll) wird auf die errechnete Dauer verteilt.
  • Gesamtpuffertreue Planung:
    • Die Dauer-Rest ist abhängig von der verfügbareren Kapazität der Basisperiode (Wert aus Ressourcendatenblatt) und dem vorhandenen Puffer der Zeitrechnung.
    • Der Aufwand (Stunden-Soll) wird auf die errechnete Dauer verteilt.
  • Kapazitätstreue Planung:
    • Die Dauer-Rest ist abhängig von der verfügbareren Kapazität der Basisperiode (Wert aus Ressourcendatenblatt). Die Einlastung erfolgt ohne Überlasten.
    • Der Aufwand (Stunden-Soll) wird auf die errechnete Dauer verteilt.
Hinweis
  • Optional kann auch bei der gesamtpuffer- und kapazitätstreuen Planung die Verwendung des Parameters Max. Belastung/Tag erfolgen. Die Berechnung der Dauer-Rest erfolgt dann wie bei der termintreuen Planung.
Beispiel: Termintreue Planung
  • Max. Belastung/Tag = 5,5 Stunden
  • Stunden-Soll = 60 Stunden
  • Dauer-Rest = 60 / 5,5 = 10,9 Tage, aufgerundet = 11 Tage, da in ganzen Tagen kalkuliert wird.
  • Verteilung der Stunden: 10 Tage à 5,5 Stunden, 1 Tag à 5 Stunden
Beispiel: Gesamtpuffertreue Planung
  • Max. Belastung/Tag = leer
  • Stunden-Soll = 60 Stunden
  • verfügbare Kapazität der Basisperiode = 8 Stunden – 10% Grundlast = 7,2 Stunden
  • Dauer-Rest = 60 / 7,2 = 8,3 Tage, aufgerundet = 9 Tage, da in ganzen Tagen kalkuliert wird. Bei Überlastung der Ressource wird die Dauer-Rest solange verlängert, bis keine Überlastung mehr auftritt.
  • Verteilung der Stunden:
  • ohne Überlast: 8 Tage à 7,2 Stunden, 1 Tag à 2,4 Stunden.
  • mit Überlast: abh. von der Dauer-Rest Wegen eventuellem Kapazitätsabgleich nicht vorbestimmbar.

Anwendungsbeispiele

Information
  • Zur Verdeutlichung der Zusammenhänge zwischen den verschiedenen Einflussfaktoren auf die Terminrechnung folgen einige Anwendungsbeispiele.
Hinweise
  • Sofern nichts anderes beschrieben ist, basieren die gezeigten Beispiele auf den Einstellungen der Standard-Installation und der linearen Belastungskurve. (= Das Datenfeld DI001452 Bel.-Kurve ist leer:)
  • Bei abweichenden Parametereinstellungen können die Ergebnisse entsprechend variieren.
Beispiele
  • Übersicht und Kurzbeschreibung der Anwendungsfälle:
Nr. Anwendungsfall Ergebnis
1 Termintreue Planung mit mehreren Ressourcen
  • Vorgang mit mehreren Vorgangsressourcen
  • Die Dauer-Soll des Vorgangs ist vorgegeben.
  • Einplanungsart = termintreu
  • Die Einplanung erfolgt durch die Terminrechnung entlang der Dauer des Vorgangs.
  • Eine Überlastung wird durch die Terminrechnung nicht vermieden.
  • Überlasten werden angezeigt.
2 Gesamtpuffertreue Planung mit mehreren Ressourcen
  • Vorgang mit mehreren Vorgangsressourcen
  • Die Dauer-Soll des Vorgangs ist vorgegeben.
  • Einplanungsart = gesamtpuffertreu
  • Die Einplanung erfolgt durch die Terminrechnung entlang der Dauer des Vorgangs.
  • Eine Überlastung wird durch die Terminrechnung nicht vermieden.
  • Der Puffer von überlasteten Ressourcen wird genutzt, um die evt. Überlasten zu vermeiden. Reicht der Puffer nicht aus, werden Ressourcen überlastet
  • Ressource 1 mit Überlast: Puffer wird genutzt
  • Ressource 2 ohne Überlast: Beginnt zum frühesten Anfangstermin.
3 Kapazitätstreue Einplanung
  • Vorgang mit mehreren Vorgangsressourcen
  • Die Dauer-Soll des Vorgangs ist vorgegeben.
  • Einplanungsart = kapazitätstreu
  • Die Einplanung des Vorgangs durch die Terminrechnung erfolgt ohne Berücksichtigung der Dauer-Soll des Vorgangs.
  • Ressourcen werden nicht überlastet.
  • Der Puffer von überlasteten Ressourcen wird ausgenutzt:
  • Ressourcen werden an arbeitsfreien Tagen nicht eingeplant.
4 Ressourcen mit Urlaub, termintreue Planung
  • Ressource mit Urlaub
  • Lineare Belastung
  • Die Urlaubsdauer ist kürzer als die Vorgangsdauer.
  • Einplanungsart = termintreu
  • Die Einplanung erfolgt durch die Terminrechnung im Block.
  • Die Ressource wird von der Terminrechnung im Urlaub nicht eingeplant.
  • An Arbeitstagen wird die Ressource ggf. mit Überlasten eingeplant.
5 Ressourcen mit Urlaub > Vorgangsdauer, termintreue Planung
  • Ressource mit Urlaub
  • Lineare Belastung
  • Die Urlaubsdauer ist länger als die Vorgangsdauer.
  • Einplanungsart = termintreu
  • Die Einplanung erfolgt durch die Terminrechnung vor bzw. spätestens zum Urlaubsbeginn.
  • Der Aufwand wird aufgrund der Nichtverfügbarkeit der Ressource im Urlaub als Überlast ausgewiesen.
  • Liegt der gesamte Vorgang im Urlaub, dann erfolgt die Einlastung zum kalkulierten Anfangstermin des Vorgangs.
6 Gesamtpuffertreue Einplanung mit Urlaub
  • Für eine Ressource wird Urlaub eingetragen
  • Lineare Belastungskurve
  • Die Urlaubsdauer ist kürzer als die Vorgangsdauer.
  • Einplanungsart = gesamtpuffertreu
  • Die Einplanung durch die Terminrechnung erfolgt außerhalb der Urlaubszeit im Block.
  • Vorhandener Puffer wird genutzt. Ist der Puffer aufgebraucht, wird die Ressource durch die Terminrechnung überlastet.
  • Die Ressource wird im Urlaub nicht eingeplant.
  • Die Einplanung wird nicht gesplittet.
7 Kapazitätstreue Einplanung mit Urlaub
  • Für eine Ressource wird Urlaub eingetragen
  • Lineare Belastungskurve
  • Die Urlaubsdauer ist kürzer als die Vorgangsdauer.
  • Einplanungsart = kapazitätstreu
  • Die Einplanung erfolgt durch die Terminrechnung außerhalb der Urlaubszeit im Block.
  • Die Ressource wird im Urlaub nicht eingeplant.
8 Gesamtpuffertreue Planung mit Wunsch-Ende und Fixierung = 0
  • Vorgang mit mehreren Vorgangsressourcen.
  • Die Dauer-Soll ist vorgeben.
  • Wunsch-Ende auf einen Vorgang
  • VG-Parameter Fixierung = 0
  • Der Urlaub einer Ressource ist kürzer als der Vorgang.
  • Einplanungsart = gesamtpuffertreu
  • Die Einplanung des Vorgangs erfolgt durch die Terminrechnung auf das Wunsch-Ende.
  • Durch die Einstellung Fixierung = 0 wird das Wunsch-Ende bei Bedarf überschritten.
  • Keine Berücksichtigung von Puffer und gegebenenfalls Überlast, da durch Eingabe eines Wunsch-Endes eine termintreue Einlastung erfolgt.
  • Es erfolgt keine Verschiebung des Vorgangs.
8.1 Gesamtpuffertreue Planung mit Wunsch-Ende und Fixierung = 1
  • Vorgang mit mehreren Vorgangsressourcen
  • Die Dauer-Soll ist vorgeben.
  • Wunsch-Ende auf Vorgang
  • VG-Parameter Fixierung = 1
  • Einplanungsart = gesamtpuffertreu
  • Die Einplanung des Vorgangs erfolgt durch die Terminrechnung auf das Wunsch-Ende.
  • Durch die Einstellung Fixierung = 1 wird das Wunsch-Ende gehalten und termintreu eingelastet.
  • Puffer und Überlasten werden nicht berücksichtigt.
  • Es erfolgt keine Verschiebung des Vorgangs.
8.2 Gesamtpuffertreue Planung mit VGR Wunsch-Anfang
Vorgang mit mehreren Vorgangsressourcen
  • Die Vorgangs-Einplanung erfolgt ab Projekt Wunsch-Anfang bzw. ab HEUTE.
  • Der letzte Vorgang wird spätestmöglich, also auf das Wunsch-Ende des Projekts eingeplant.
  • Der Wunsch-Anfang auf letztem Vorgang kann wegen Planung früh = N nicht gehalten werden.
9 Kapazitätstreue Planung mit Wunsch-Ende und Fixierung = 1
Vorgang mit mehreren Vorgangsressourcen
  • Durch den Parameter Fixierung = 1 wird der Vorgang termintreu eingelastet.
  • Der Vorgang wird nicht verlängert oder verschoben. Es treten ggf. Überlasten auf.
10 Termintreue Planung eines Vorgangs mit Vorgänger, Wunsch-Anfang und Fixierung = 0
  • Für eine Ressource wird Urlaub eingetragen
  • Lineare Belastungskurve
  • Die Urlaubsdauer ist kürzer als die Vorgangsdauer.
  • Vorgang mit Vorgänger und Wunsch-Anfang, Fixierung = 0 ein
  • Einplanungsart = termintreu
  • Der Vorgang beginnt nicht zum Wunsch-Anfang, sondern nachdem der Vorgänger beendet ist.
  • Der Urlaub der Ressource wird berücksichtigt.
  • >Dauer Rest= Dauer-Soll
11 Gesamtpuffertreue Planung mit Aufwand > Verfügbarkeit
  • Vorgang mit mehreren Vorgangsressourcen
  • Die Dauer-Soll ist vorgeben.
  • Die für die gewünschte Dauer erforderliche Kapazität übersteigt die verfügbare Kapazität
  • Einplanungsart = gesamtpuffertreu
  • Die Terminrechnung nutzt vorhandenen Puffer aus.
  • Ist kein Puffer mehr vorhanden, erfolgt die Einplanung am Block zum spätestmöglichen Zeitpunkt.
12 Kapazitätstreue Planung mit Aufwand > Verfügbarkeit
  • Vorgang mit mehreren Vorgangsressourcen
  • Die Dauer-Soll des Vorgangs ist vorgegeben.
  • Die für die gewünschte Dauer erforderliche Kapazität liegt über der verfügbaren Kapazität.
  • Einplanungsart = kapazitätstreu
  • Die Terminrechnung nutzt vorhandenen Puffer aus. Dabei wird die Einplanung solange verschoben, bis im Block eingelastet werden kann. Gegebenenfalls wird der Projektendtermin überschritten.
  • Die Ressource wird im Urlaub nicht eingeplant, der Vorgang wird nicht gesplittet
13 Gesamtpuffertreue Einplanung eines VG mit Vorgänger, Wunsch-Ende und Fixierung = 0
  • Für eine Ressource wird Urlaub eingetragen
  • Lineare Belastungskurve
  • Die Urlaubsdauer ist kürzer als die Vorgangsdauer.
  • Vorgang mit Vorgänger und Wunsch-Anfang
  • VG-Parameter Fixierung = 0 ein
  • Einplanungsart = gesamtpuffertreu
  • Der Vorgang beginnt nicht zum Wunsch-Anfang, sondern nachdem der Vorgänger beendet ist.
  • Der Urlaub der Ressource wird berücksichtigt.
  • Dauer-Rest = Dauer-Soll
  • Puffer wird nicht ausgenutzt, da ein Vorgang mit Termin automatisch immer termintreu eingelastet wird.
14 Kapazitätstreue Einplanung eines VG mit Vorgänger, Wunsch-Ende und Fixierung = 0
  • Für eine Ressource wird Urlaub eingetragen
  • Lineare Belastungskurve
  • Die Urlaubsdauer ist kürzer als die Vorgangsdauer.
  • Vorgang mit Vorgänger und Wunsch-Ende
  • VG-Parameter Fixierung = 0 ein
  • Einplanungsart = kapazitätstreu
  • Der Vorgang endet nicht automatisch zum Wunsch-Ende, sondern beginnt, nachdem der Vorgänger beendet ist.
  • Der Urlaub der Ressource wird berücksichtigt.
  • Dauer-Rest = Dauer-Soll
  • Puffer wird nicht ausgenutzt, da ein Vorgang mit Termin automatisch immer termintreu eingelastet wird.
15 Kalk. Anfang bei Rückmeldung mehrerer Vorgangsressourcen
  • Einplanung mehrerer Ressourcen auf einen Vorgang und Rückmeldung von Stunden:
  • wie geplant
  • früher als geplant
  • später als geplant
  • Die Ressourcen werden durch die Terminrechnung mit ihrem Restaufwand ab dem VGR Ist-Anfang eingeplant.
  • Ist der Tag nach dem Ist-Anfang kein Arbeitstag, wird die Ressource am nächsten Arbeitstag eingeplant.
  • Gegebenenfalls wird die Ressource überlastet.
16 Rückmeldung im Urlaub
  • Einem Vorgang sind mehrere Ressourcen zugeordnet.
  • Eine Ressource ist über die komplette Vorgangsdauer im Urlaub, meldet jedoch Ist-Stunden zurück.
  • Die Einplanung der Ressourcen ohne Urlaub erfolgt durch die Terminrechnung gemäß den Standardvorgaben.
  • Die Ressource, die während des Urlaubs zurückgemeldet hat, wird auf den ersten Arbeitstag nach der Rückmeldung eingeplant.
  • Gegebenenfalls wird die Ressource überlastet.

Information

  • Die oben aufgeführten Anwendungsfälle sind nachfolgend im Detail mit Beispielen dargestellt.

Termintreue Planung mit mehreren Ressourcen

Ziel
  • Auswirkung der termintreuen Planungsart mit mehreren Ressourcen auf die Zeitrechnung
Details
  • Ein Projekt wird mit mehreren Vorgängen und mehreren Vorgangs-Ressourcen erstellt.
  • Die Dauer-Soll der Vorgänge wird vorgegeben oder über Aufwand-Soll / max. Belastung/Tag errechnet.
  • Die Einplanungsart ist termintreu.
  • Die Ressourcen werden mit der Belastungskurve CAP geplant.
Informationen
  • Die Einplanung erfolgt durch die Terminrechnung entlang der Dauer des Vorgangs.
  • Überlasten werden ausgewiesen und nicht verteilt.
  • Die Ressourcen werden durch die Terminrechnung gemäß Projekt Wunsch-Anfang eingeplant.
Beispiel
  • Das Projekt beginnt am 31.10.08
  • Die Ressource R1 wird in VG 01 wegen nicht ausreichender Verfügbarkeit durch die Terminrechnung mit Überlast eingeplant:

GR01502800-DE.png

Hinweise

  • Damit die Terminrechnung die Ressourcen nicht überlastet, wird die Belastungskurve CAP benötigt. In diesem Fall kann
    • bei der gesamtpuffertreuen Planung der zur Verfügung stehende Puffer optimal genutzt werden
    • bei der kapazitätstreuen Planung das Projektende entsprechend der zur Verfügung stehenden Kapazität verschoben werden.

Gesamtpuffertreue Planung mit mehreren Ressourcen

Ziel
  • Auswirkung der gesamtpuffertreuen Planung mit mehreren Ressourcen auf die Zeitrechnung
Details
  • Ein Projekt wird mit mehreren Vorgängen und mehreren Vorgangsressourcen erstellt.
  • Die Dauer-Soll der Vorgänge wird vorgegeben.
  • Die Einplanungsart ist gesamtpuffertreu.
Informationen
  • Der vorhandene Puffer wird ressourcenbezogen durch die Terminrechnung genutzt, falls dies nötig ist.
  • Eine Ressource mit Überlast wird durch die Terminrechnung entsprechend des vorhandenen Puffers verschoben.
Beispiel
  • Ein Projekt beginnt wie geplant am 25.11.08
  • Die Ressource R1 hat in KW48 keine ausreichend freie Kapazität. Es tritt eine Überlast auf. Der vorhandene Puffer wird ausgenutzt und der Kalk. Anfang verschoben.
  • Die Einlastung der Ressource R2 ohne Überlast bleibt unverändert. Der Kalk. Anfang für die Ressource R2 beginnt zum frühesten Anfangstermin.
  • Die Dauer des Vorgangs VG 01 verlängert sich:

GR01502801-DE.png

Kapazitätstreue Planung mit mehreren Ressourcen

Ziel
  • Auswirkung der kapazitätstreuen Einplanung auf die Zeitrechnung
Details
  • Ein Projekt wird mit mehreren Vorgängen und mehreren Vorgangsressourcen erstellt.
  • Die Dauer-Soll der Vorgänge wird vorgeben.
  • Die Einplanungsart ist kapazitätstreu.
Informationen
  • Ressourcen werden durch die Terminrechnung ohne Überlastung eingeplant.
  • Bei Ressourcenengpass wird der Vorgang auch über den Projekt Wunsch-Ende hinaus verlängert.
Beispiel
  • Projekt Wunsch-Anfang: 31.10.08
  • Projekt Wunsch-Ende: 31.12.08
  • Die Einplanung erfolgt durch die Terminrechnung ohne Berücksichtigung der Vorgangsdauer.
  • Es entstehen keine Überlasten.
  • Es erfolgt keine Einplanung von Ressourcen an nichtverfügbaren Tagen:

GR01502802-DE.png

Beispiel

  • Der Projekt Wunsch-Ende des o.a. Projekts wird auf den 19.12.08 vorgezogen, um einen Ressourcenengpass zu simulieren.
  • Ressourcen werden durch die Terminrechnung wie gewünscht ohne Überlast eingeplant.
  • Der Projekt Wunsch-Ende wird um 6 Tage überschritten:

GR01502803-DE.png

Termintreue Planung mit Urlaub

Ziel
  • Auswirkung von Urlaub einer Ressource bei termintreuer Planung auf die Zeitrechnung
Details
  • Für eine Ressource wird Urlaub eingetragen.
  • Der geplante Bearbeitungszeitraum des Vorgangs liegt nicht vollständig im Urlaub der Ressource.
  • Es erfolgt eine termintreue Planung.
Informationen
  • Die Einplanung erfolgt entlang der Vorgangsdauer.
  • Urlaub wird berücksichtigt.
  • Gegebenenfalls erfolgt die Einplanung mit Überlasten.
Beispiel
  • Die Ressource R2 hat in der KW45 fünf Tage Urlaub:

GR01502804-DE.png

  • Die Ressource R2 wird durch die Terminrechnung im Urlaub nicht eingeplant. Die Belastung der Ressource R2 wird in der Urlaubswoche KW45 entsprechend verringert, die Aufwände in den anderen Wochen erhöhen sich.
  • Überlasten werden angezeigt:

GR01502805-DE.png

Urlaub länger als Vorgangsdauer

Ziel
  • Auswirkung von Urlaub, welcher länger als die Vorgangsdauer ist, auf die Zeitrechnung
Details
  • Der geplante Bearbeitungszeitraum des Vorgangs liegt vollständig im Urlaub der Ressource.
  • Die Einplanungsart ist termintreu mit linearer Belastungskurve.
Informationen
  • Die Einplanung erfolgt durch die Terminrechnung in der für den Vorgang zur Verfügung stehenden Zeit.
  • Die Einplanung erfolgt am ersten Tag des Urlaubs.
Beispiel
  • Der Urlaub der Ressource R2 beginnt vor dem Ende des Vorgangs VG 01 und erstreckt sich vollständig über die Dauer des Vorgangs VG 02.

GR01502806-DE.png

  • Die Einplanung der Ressource R2 für Vorgang VG 01 erfolgt bis zu Urlaubsbeginn.
  • Für Vorgang VG 02 erfolgt sie komplett zu Urlaubsbeginn, da der Vorgang vollständig in der Urlaubszeit liegt. Die Ressource wird überlastet:

GR01502807-DE.png

Gesamtpuffertreue Planung mit Urlaub

Ziel
  • Auswirkung der gesamtpuffertreuen Einplanung mit Urlaub einer Ressource auf die Zeitrechnung
Details 1
  • Für eine Ressource wird Urlaub eingetragen.
  • Der geplante Bearbeitungszeitraum des Vorgangs liegt nicht vollständig im Urlaub der Ressource.
  • Es erfolgt eine gesamtpuffertreue Planung mit linearer Belastungskurve.
Informationen
  • Die Einplanung erfolgt durch die Terminrechnung entlang der Vorgangsdauer mit Berücksichtigung von Urlaub und Puffer, sofern dieser vorhanden ist.
  • Ist der Puffer aufgebraucht, wird überlastet.
  • Ressourcen werden im Urlaub nicht eingeplant.
Beispiel
  • Die Ressource R2 hat in der KW 46 Urlaub und wird in dieser Zeit nicht eingeplant.
  • Da die verfügbare Kapazität trotz Ausnutzung des Puffers nicht ausreicht, wird die Ressource R2 überlastet:

GR01502809-DE.png

Kapazitätstreue Planung mit Urlaub

Ziel
  • Darstellung der Auswirkung der kapazitätstreuen Einplanung mit Urlaub einer Ressource auf die Zeitrechnung
Details
  • Für eine Ressource wird Urlaub eingetragen.
  • Der geplante Bearbeitungszeitraum des Vorgangs liegt nicht vollständig im Urlaub der Ressource.
  • Die verfügbare Kapazität der Ressource ist größer als die erforderliche Kapazität.
  • Die Dauer-Soll des Vorgangs wird vorgeben.
  • Es erfolgt eine kapazitätstreue Planung mit linearer Belastungskurve.
Informationen
  • Durch die Terminrechnung erfolgt eine kapazitätstreue Einplanung der Ressourcen.
  • Ressourcen werden überlastet, wenn durch die vorgegebene Dauer keine ausreichende verfügbare Kapazität vorhanden ist.
  • Ressourcen werden im Urlaub nicht eingeplant.
Beispiel
  • Die Einplanung erfolgt durch die Terminrechnung entlang der Vorgangsdauer mit Berücksichtigung von Urlaub.
  • Die Ressource R2 wird in ihrem Urlaub in KW 48 nicht eingeplant.
  • Die Einplanung von R2 erfolgt durch die Terminrechnung wegen der vorgegebenen Dauer mit Überlast:

GR01502810-DE.png

Gesamtpuffertreue Planung mit VG-Wunsch-ET und Fixierung = 0

Ziel
  • Darstellung der Auswirkung der Einplanung mit nicht fixiertes Wunsch-Ende auf die Zeitrechnung
Details
  • Die Dauer-Soll des Vorgangs wird vorgeben.
  • Der Vorgang hat ein Wunsch-Ende.
  • VG-Parameter DI009480 Fixierung = 0
  • Die Einplanungsart erfolgt gesamtpuffertreu und linearer Belastungskurve.
Informationen
  • Die ursprüngliche Vorgangsdauer bleibt erhalten.
  • Ressourcen werden im Urlaub nicht eingeplant, im unten angeführten Beispiel zu sehen bei R2 in KW 48.
  • Pufferzeiten werden nicht berücksichtigt, da durch den gesetzten Wunsch-Ende eine termintreue Einlastung erfolgt. Falls notwendig, wird mit Überlast eingeplant.
  • Das Kalk. Ende 11.12.08 liegt hinter dem Wunsch-Ende 05.12.08, wenn dies aufgrund der Vorgangsdauer nicht vermeidbar ist.
Beispiel
  • Aufgrund der vorgegebenen Vorgangsdauer liegt das Kalk. Ende hinter das Wunsch-Ende.
  • Die Abweichung zum Wunsch-Ende wird für Vorgang VG 01 angezeigt.
  • Die Ressource R2 wird überlastet.
  • Die Ressource R2 wird während ihres Urlaubs in KW 48 nicht eingeplant:

GR01502811-DE.png

Gesamtpuffertreue Planung mit VG-Wunsch-ET und Fixierung = 1

Ziel
  • Darstellung der Auswirkung der gesamtpuffertreuen Einplanung mit fixiertem Wunsch-Ende auf die Zeitrechnung
Details
  • Der Vorgang hat ein Wunsch-Ende.
  • VG-Parameter DI009480 Fixierung =1, der Vorgang wird somit auf Termin fixiert.
  • Die Einplanungsart ist gesamtpuffertreu.
Informationen
  • Der Wunsch-Ende wird nicht verschoben.
  • Ressourcen werden im Urlaub nicht eingeplant.
  • Bei Bedarf wird eine Überlast eingeplant.
  • Eine lange Dauer eines Vorgangs mit fixiertem Wunsch-Ende kann dazu führen, dass der Kalk. Anfang des Vorgangs vor dem bisherigen Kalk. Anfang des Projekts liegt. Der Kalk. Anfang des Projekts wird dadurch vorgezogen. Dies gilt nur bei nichtaktiver Heutelinie.
Beispiel
  • Der Kalk. Ende entspricht dem Wunsch-Ende.
  • Die Vorgangsdauer wird nicht verlängert.
  • Die Ressource wird überlastet.
  • Die Ressource R2 wird während ihres Urlaubs in KW 46 nicht eingeplant:

GR01502812-DE.png

Hinweis

  • Vorgangstermine mit dem Parameter Fixierung = 1 wirken ähnlich wie Ist-Termine, werden also bei eingetragenem Wunsch-Anfang oder Wunsch-Ende nicht durch die aktive Heutelinie verschoben.

Gesamtpuffertreue Planung mit VGR Wunsch-AT

Ziel
  • Darstellung der Auswirkung der gesamtpuffertreuen Einplanung von Vorgangsressourcen- Wunsch-Anfang auf die Zeitrechnung
Details
  • Einplanung mehrerer Vorgänge.
  • Einem Vorgang mit Wunsch-Anfang sind mehrere Ressourcen zugeordnet.
  • Die Vorgangsressourcen haben unterschiedliche VGR Wunsch-Anfang.
  • Die Einplanungsart ist gesamtpuffertreu.
Informationen
  • Die Ressourcen werden gegebenenfalls überlastet.
  • Ressourcen werden im Urlaub nicht eingeplant.
  • Die Einplanung der Ressourcen erfolgt an den VGR-Wunschterminen, sofern diese innerhalb des Zeitraums von Kalk. Anfang bis Kalk. Ende liegen.
Beispiel
  • Die Ressourcen werden durch die Terminrechnung auf die zur Verfügung stehende Zeit eingelastet.
  • Die Ressourcen R3 und R4 werden überlastet:

GR01502813-DE.png

Hinweise

  • Der VG Wunsch-Anfang mit Fixierung hat für die Terminrechnung eine höhere Priorität als der VGR Wunsch-Anfang.
  • Bei gesamtpuffertreuer Planung und Planung spät werden Wunsch-Anfang -Termine nicht berücksichtigt und Wunsch-Ende -Termine berücksichtigt.

Kapazitätstreue Planung mit Wunsch-ET und Fixierung = 1

Ziel
  • Darstellung der Auswirkung der kapazitätstreuen Einplanung mit Wunsch-Ende ohne Fixierung auf die Zeitrechnung
Details
  • Der Vorgang hat ein Wunsch-Ende.
  • VG-Parameter DI009480 Fixierung = 1
  • Die Einplanungsart ist kapazitätstreu.
Informationen
  • Der Wunsch-Ende wird durch die Terminrechnung nicht überschritten.
  • Puffer wird nicht berücksichtigt.
  • Falls notwendig, wird mit Überlast eingeplant.
  • Ressourcen werden in Ihrem Urlaub nicht eingeplant.
Beispiel
  • Puffer wird nicht berücksichtigt, da wegen Wunsch-Ende mit Parameter Fixierung = 1 eine termintreue Einlastung erfolgt.
  • Damit das Wunsch-Ende gehalten werden kann, wird mit Überlast eingeplant:

GR01502814-DE.png

Termintreue Einplanung eines VG mit Vorgänger, Wunsch-AT und Fixierung = 0

Ziel
  • Darstellung der Auswirkung der termintreuen Einplanung eines Vorgangs mit Vorgänger, Wunsch-Anfang sowie Parameter Fixierung = 0 auf die Zeitrechnung
Details
  • Einem Vorgang mit Vorgänger und nicht fixiertes Wunsch-Anfang sind mehrere Vorgangsressourcen zugeordnet.
  • Der geplante Bearbeitungszeitraum des Vorgangs liegt nicht vollständig im Urlaub der Ressource.
  • Die Bearbeitungsdauer des Vorgängers dauert länger als geplant.
  • Die Einplanungsart ist termintreu.
Informationen
  • Der Vorgang wird durch die Terminrechnung gegebenenfalls verschoben und die Ressourcen mit Überlast eingeplant.
  • Die Abweichung zum Wunsch-Anfang wird angezeigt.
  • Ressourcen werden im Urlaub nicht eingeplant.
Beispiel
  • Der Vorgänger dauert länger als geplant.
  • Der Nachfolger beginnt später, die Vorgangsdauer wird nicht verlängert. Der Vorgang wird mit Überlast eingeplant.
  • Die Abweichung zum Wunsch-Anfang wird bei Vorgang VG 02 durch den Abstand zwischen dem Dreieck und dem Beginn des Balkens angezeigt.
  • Die Ressource R2 wird in ihrem Urlaub in KW49 nicht eingeplant:

GR01502816-DE.png

Gesamtpuffertreue Einplanung eines VG mit Vorgänger, Wunsch-ET und Fixierung = 0

Ziel
  • Darstellung der Auswirkung der gesamtpuffertreuen Einplanung mit eines VG mit Vorgänger, Wunsch-Ende und Parameter Fixierung = 0 auf die Zeitrechnung
Details
  • Einem Vorgang mit Vorgänger und nicht fixiertes Wunsch-Ende sind mehrere Vorgangsressourcen zugeordnet.
  • Die Einplanungsart ist gesamtpuffertreu.
Informationen
  • Der Vorgang wird durch die Terminrechnung verschoben, wenn der Vorgänger länger dauert als geplant.
  • Die Abweichung zum Wunsch-Ende wird angezeigt.
  • Falls notwendig, wird die Ressource überlastet.
  • Ressourcen werden im Urlaub nicht eingeplant.
Beispiel
  • Der Vorgang 01 ist mit Vorgang 02 über eine EA-Beziehung verknüpft.
  • Durch den Verzug von Vorgang 01 wird der Vorgang 02 über seinen Wunsch-Ende hinaus verschoben. Eine Abweichung von 17 Tagen wird angezeigt.
  • Die Ressourcen werden mit Überlast eingeplant.
  • Die Ressource R2 wird in ihrem Urlaub in KW 48 nicht eingeplant:

GR01502820-DE.png

Kapazitätstreue Einplanung eines VG mit Vorgänger, Wunsch-ET , Fixierung = 0

Ziel
  • Darstellung der Auswirkung der kapazitätstreuen Einplanung eines VG mit Vorgänger, Wunsch-Ende und Parameter Fixierung = 0 auf die Zeitrechnung
Details
  • Einem Vorgang mit Vorgänger und nicht fixiertes Wunsch-Ende sind mehrere Vorgangsressourcen zugeordnet.
  • Die Einplanungsart erfolgt kapazitätstreu mit linearer Belastungskurve.
Informationen
  • Der Vorgang wird durch die Terminrechnung verschoben, wenn der Vorgänger länger als geplant dauert.
  • Die Abweichung zum Wunsch-Ende wird angezeigt.
  • Falls notwendig, wird die Ressource überlastet, da die Einplanung durch das Wunsch-Ende termintreu erfolgt.
  • Ressourcen werden im Urlaub nicht eingeplant.
Beispiel
  • Der Vorgang 01 ist mit Vorgang 02 über eine EA-Beziehung verknüpft.
  • Durch den Verzug von Vorgang 01 wird der Vorgang 02 über sein Wunsch-Ende hinaus verschoben. Eine Abweichung von 24 Tagen wird angezeigt.
  • Die Ressourcen werden mit Überlast eingeplant.
  • Die Ressource R2 wird in ihrem Urlaub in KW 48 nicht eingeplant:

GR01502821-DE.png

Gesamtpuffertreue Planung mit Aufwand über der Verfügbarkeit

Ziel
  • Darstellung der Auswirkung der gesamtpuffertreuen Einplanung mit Aufwand oberhalb der Verfügbarkeit auf die Zeitrechnung
Details
  • Die Dauer-Soll des Vorgangs wird vorgeben.
  • Der Aufwand ist höher als die Verfügbarkeit der Ressource im geplanten Bearbeitungszeitraum.
  • Die Einplanungsart erfolgt gesamtpuffertreu mit linearer Belastungskurve.
Informationen
  • Der Puffer der überlasteten Ressource wird ausgenutzt.
  • Die Einplanung durch die Terminrechnung erfolgt zum spätestmöglichen Zeitpunkt.
Beispiel
  • Der Aufwand-Soll von 150h innerhalb von 15 Tagen übersteigt die verfügbare Kapazität der Ressource. Der Vorgang 01 wird daher zum spätestmöglichen Zeitpunkt eingeplant:

GR01502817-DE.png

Kapazitätstreue Planung mit Aufwand über der Verfügbarkeit

Ziel
  • Darstellung der Auswirkung der kapazitätstreuen Einplanung mit Aufwand über der Verfügbarkeit auf die Zeitrechnung
Details
  • Die Dauer-Soll des Vorgangs wird vorgeben.
  • Der Aufwand ist höher als die Verfügbarkeit der Ressource im geplanten Bearbeitungszeitraum.
  • Die Einplanungsart erfolgt kapazitätstreu mit linearer Belastungskurve.
Informationen
  • Ressourcen werden im Urlaub nicht eingeplant.
  • Der Vorgang wird durch die Terminrechnung solange verschoben, bis er im Block eingeplant werden kann. Dadurch kann ggf. der Projektendtermin verschoben werden.
  • Der Aufwand wird durch die Terminrechnung innerhalb der Dauer-Soll gleichmäßig auf die Vorgangsdauer verteilt. Dabei wird die Ressource überlastet.
  • Puffer wird nicht berücksichtigt, die Vorgangsdauer nicht verlängert.
Beispiel
  • Der Vorgang wird solange verschoben, bis er im Block eingeplant werden kann.
  • Die Ressource R2 wird in ihrem Urlaub in KW 45 nicht eingeplant.
  • Die Ressource R2 wird überlastet.
  • Der Projekt Wunsch-Ende wird überschritten:

GR01502818-DE.png

Hinweis

  • Wird die Belastungskurve CAP verwendet, wird vorhandener Puffer berücksichtigt.

Rückmeldung mehrerer Vorgangsressourcen

Ziel
  • Darstellung der Auswirkung der Rückmeldung bei der termintreuen Einplanung ohne Wunschtermine mit mehreren Ressourcen
Details
  • Einem Vorgang sind mehrere Vorgangsressourcen mit der Belastungskurve CAP zugeordnet.
  • Es sind keine Wunsch-Anfang und Wunsch-Ende gesetzt.
  • Die Einplanungsart ist termintreu.
  • Parameter Splitting = J
Informationen
  • Der Kalk. Anfang des Vorgangs und aller Vorgangsressourcen verschiebt sich auf den nächsten Arbeitstag nach der spätesten Rückmeldung.
  • Eine späte Rückmeldung kann somit zu einer Verschiebung des Projekt Kalk. Ende führen.
Beispiel
  • Die Ressource R2 hat in KW 49 Urlaub.
  • Termine vor der Stundenrückmeldung:

GR01502822-DE.png

  • Nach der Rückmeldung auf den 10.11.08 durch R1 und Durchführung einer Terminrechnung verschiebt sich der Kalk. Anfang des Vorgangs 01 von 04.11.08 auf 10.11.08:

GR01502823-DE.png

Rückmeldung im Urlaub

Ziel
  • Darstellung der Auswirkung von im Urlaub zurückgemeldeten Stunden
Details
  • Einem Vorgang sind mehrere Vorgangsressourcen zugeordnet.
  • Eine Ressource ist während der gesamten Vorgangsdauer im Urlaub und meldet Ist-Stunden für die Urlaubzeit zurück.
  • Die Ressourcen werden mit einer linearen Belastungskurve eingeplant.
Informationen
  • Ressourcen werden im Urlaub nicht eingeplant.
  • Ressourcen, die für die Urlaubszeit zurückmelden, erhalten den Restaufwand auf den folgenden Arbeitstag nach der Rückmeldung. Dabei wird die Ressource ggf. überlastet.
  • Die Einplanung der Ressourcen ohne Urlaub erfolgt durch die Terminrechnung gemäß der normalen Planung.
Beispiel
  • Die Ressource R8 hat vom 05.11.08 bis 16.12.08 Urlaub. Der gesamte Aufwand für Vorgang 01 wird auf den ersten Urlaubstag eingeplant und die Ressource überlastet:

GR01502824-DE.png

  • Während der Urlaubszeit werden Stunden zurückgemeldet. Auf der Vorgangs- und Vorgangsressourcenebene reduziert die Terminrechnung den Restaufwand und die Überlast um die zurückgemeldeten Stunden.
  • Der Restaufwand wird auf den Tag nach der Rückmeldung eingeplant:

GR01502825-DE.png

Termintreue Planung mit CAP

Information Hinweis
  • Trotz termintreuer Planung findet innerhalb der VG Dauer-Rest eine Kapazitätsoptimierung statt. Erfahrungen aus der Praxis haben gezeigt, dass allein durch Setzen von CAP in Verbindung mit termintreuer Planung die Überlasten deutlich gesenkt werden können. Dieser positive Effekt tritt insbesondere bei der mitarbeiterbezogenen Planung auf.
Beispiel
TT_CAP1.png

  • Wird der VGR Aufwand-Rest zu hoch, wird die Ressource überlastet.
TT_CAP2.png

  • Wenn keine Dauer-Rest, keine Max. Belastung/Tag und keine VG Wunschtermine vorgegeben werden, wird die Gesamtlast auf einen Tag eingelastet. Die Ressource wird überlastet.
TT_CAP3.png

Hinweis

  • Sofern das PR beziehungsweise der VG Wunschendtermine haben oder der VG eine Dauer-Rest hat und sich die Ressource nicht innerhalb dieses Zeitraums einplanen lässt, wird die Überlast bei termintreuer Planung gleichmäßig über alle Belastungsdatensätze auf die Arbeitstage der Ressource innerhalb des vorgegebenen Zeitraums verteilt.

Gesamtpuffertreue Planung mit CAP

Ziel Details
  • Die VG Dauer-Rest berechnet sich wie bei der termintreuen Planung, jedoch kann sie sich wegen Kapazitätsmangel bis zum Ende der gesamten Pufferzeit oder bis zum Planungshorizont verlängern.
  • Der VG Kalk. Anfang wird auf den ersten Tag mit Rest-Kapazität verschoben, falls dieser noch vor dem VG spätester Anfang liegt. Sonst gilt VG Kalk. Anfang = VG spätester Anfang.
Beispiel
GPT_CAP1.png
GPT_CAP2.png

  • Ohne max. Belastung/Tag wird die Ressource mit der im Ressourcendatenblatt im DI 000804 Def. max. Bel. vorgegebenen Maximalbelastung pro Tag eingeplant.
GPT_CAP4.png

Hinweis

  • Sofern der Aufwand-Rest aufgrund eines zu geringen Puffers nicht innerhalb der Rest-Kapazität des Puffers eingeplant werden kann, werden die Überlasten gleichmäßig auf den Einlastungszeitraum verteilt.
GPT_CAP3.png

Kapazitätstreue Planung mit CAP

Information
  • Die Ressourcen werden voneinander unabhängig eingelastet sowie die errechneten Dauern und Termine auf den Vorgang verdichtet.
Hinweise
  • Sind einem Vorgang gleichzeitig Ressourcen mit und ohne CAP zugeordnet, sind die CAP-Ressourcenzuordnungen dominant, d.h. die VG-Dauer wird über die CAP-Ressourcenzuordnungen ermittelt. Die Nicht-CAP-Ressourcenzuordnungen werden mit der berechneten VG-Dauer eingeplant und nicht abgeglichen.
    • Ausnahmen:
      • Aufwand-Rest = 0 (CAP wird bei Berechnung der VG-Dauer nicht berücksichtigt)
      • Belastungskurve MAN (vgl. entsprechendes Kapitel).
  • Bei termin- und gesamtpuffertreuer Planung mit CAP werden Überlasten gleichmäßig über die Arbeitstage der Ressource auf alle Belastungsdatensätze verteilt.

Beispiel

KT_CAP1.png

KT_CAP2.png

Belastungskurve MAN

Information
  • Belastungsdatensätze von MAN-Ressourcen wirken ähnlich wie ein Ist-Termin. Die Planungsdaten sind fixiert und werden nicht durch die Terminrechnung verschoben.
  • Auch Ist-Termine verändern nicht die MAN – Einplanung.

Beispiel

  • Das Projekt MAN wird wie folgt eingeplant:
  • VG Wunsch-Anfang / Wunsch-Ende werden berücksichtigt, solange die MAN-Termine nicht verletzt werden. Sie können den Kalk. Anfang des Vorgangs im Vergleich zum MAN-Zeitraum nach vorne (= früher) und das Kalk. Ende nach hinten (= später) verschieben.
    • Werden keine VG Wunschtermine gesetzt, beginnt der Vorgang am heutigen Datum und endet mit der letzten MAN-Einplanung.
    • Bei einem Vorgang ohne Dauer-Rest, aber mit VG Wunsch-Anfang und VGR mit MAN Belastungsdatensatz vor dem Wunsch-Anfang wird der VG Wunsch-Anfang nicht berücksichtigt. Der Kalk. Anfang ist die früher liegende MAN-Einplanung.
MAN1.png

  • Bei einem Vorgang mit VG Wunsch-Anfang vor dem ersten MAN-Belastungssatz beginnt der Vorgang zum VG Wunsch-Anfang. Die Einplanung der Ressource erfolgt zum MAN-Termin.
MAN2.png

  • Der VG kann, z.B. durch Einplanung mit CAP-Ressourcen, verlängert werden. Die Dauer des Vorgangs wird nicht durch eine CAP-Planung verkürzt, das Minimum der Vorgangsdauer ist die Zeitspanne der MAN-Termine.
    • Bei der Planung mit MAN-Ressourcen übersteuern deren Termine die sonstigen Planungsvorgaben. Das gilt auch für Ecktermine des Projektes.
    • Sobald einem Vorgang eine MAN-Ressource zugewiesen ist, erfolgt die Einplanung der Ressourcen aufgrund des VG-Wunschtermins und nicht aufgrund des PR- Wunschtermins. Die Projektecktermine werden somit übersteuert.
    • Sofern kein VG Wunsch-Anfang gesetzt ist, startet der Vorgang am PR Wunsch-Anfang.
Nur CAP-Ressourcen CAP- & MAN-Ressourcen
  • Einplanung einer MAN-Ressource, Beibehaltung einer CAP-Ressource.
  • Der VG beginnt zum VG Wunsch-Anfang nicht zum PR Wunsch-Anfang.
  • Die Einplanung der CAP Ressource erfolgt zum VG Wunsch-Anfang CAP-Termin, der dem VG Wunsch-Anfang ist und nicht zum PR Wunsch-Anfang.
  • Die Einplanung der MAN Ressource erfolgt an den Terminen ihrer Belastungsdatensätze.
MAN3.png MAN4.png
  • Wunschtermine auf der Vorgangsressource werden bei MAN ignoriert.
    • Bei einem Vorgang mit VG Wunsch-Anfang vor dem ersten MAN-Belastungssatz und VGR Wunsch-Anfang auf der MAN-Ressource vor dem ersten Belastungsdatensatz, aber nach dem VG Wunsch-Anfang beginnt der Vorgang zum VG Wunsch-Anfang. Die Einplanung der Ressource erfolgt zum MAN-Termin. Der VGR Wunsch-Anfang wird nicht berücksichtigt.
MAN5.png

  • Der Vorgang ist aufgrund des oben gesagten nicht automatisch termintreu, sobald ihm eine MAN-Ressource zugeordnet wurde. Der VG ist verschiebbar bis er an MAN-Termine anstößt.
  • Die Aktive Heutelinie, durch den Administrator steuerbar über den Modellparameter DI000158 Aktive Heutelinie, verschiebt nicht MAN geplante Termine
  • AOBs: Diese wirken so lange, bis sie an MAN-Termine stoßen. (Z.B. bei mehrfacher Ressourceneinplanung mit MAN und CAP)
    • Die Auswirkungen, wenn auf Spannvorgang, Sammelvorgang oder BLD eine Ressource mit MAN und andere mit anderen Belastungskurven gesetzt werden, sind ähnlich wie im obigen Beispiel:
      • Die Termine der MAN geplanten Ressource werden nicht verschoben.
  • Dauer Spannvorgang oder Sammelvorgang Zeitraum MAN
  • Bei mehreren Ressourcen mit MAN wird der früheste und der späteste Termin aller MAN-Ressourcen für die Einplanung des VG verwendet.
  • Der Vorgang kann durch VG Wunsch-Anfang nur früher beginnen, als die früheste MAN-Einplanung.
  • Der Vorgang kann durch VG Wunsch-Ende nur später enden, als die späteste MAN-Einplanung.
  • Parameter Splitting = J: Der Parameter hat keine Auswirkung auf MAN-Ressourcen. Für nicht MAN geplante Ressourcen wirkt dieser Parameter wie bisher.
  • Belastungsdatensätze von MAN-Ressourcen können nur manuell gelöscht werden.
Details neues Verhalten bei Rückmeldung von Stunden
  • Planstunden der Belastungskurve MAN, welche vor der ersten Rückmeldung liegen, werden gelöscht und nicht auf die zukünftigen Einlastungen verteilt.
  • Stundenrückmeldungen in anderer Höhe als geplant, beeinflussen die weiteren Belastungsdatensätze nicht.
  • Rückmeldungen bewirken keine Änderung der eingeplanten Stunden.
  • Die Planstunden von Vorgangsressourcen mit der Belastungskurve MAN werden durch die Terminrechnung nicht verschoben.

Ziel

  • Belastungen pro Tag gezielt vorgeben
Vorgehensweise
  • Der Benutzer wählt für die Ressource die Belastungskurve MAN und trägt die gewünschten Belastungen im Feld Bel.-Rest in bestehende Belastungsdatensätze ein Dadurch erzeugt er die diskrete Belastungsverteilung. Es können auch neue Belastungsdatensätze angelegt werden.
  • Geeignete Modulkonstruktionen erlauben es, Belastungen im Balkenplan direkt unter dem Balken einzugeben. Ist die Belastung auf ein gröberes Zeitraster verdichtet dargestellt (z.B. pro Woche), wird sie nach der Eingabe automatisch auf die Tage verteilt.
Beispiel
  • Die Belastungen pro Woche unter dem Balken oder die Belastungen pro Tag unter der Ressourcenzuordnung können editiert werden.
GR0110SJ-DE.png

Typische Anwendung in der Praxis

  • Freie Verteilung der Kapazitätsbelastung über die Vorgangsdauer.
  • Manueller Kapazitätsabgleich durch Verteilung von Belastungen.
  • Projektmeetings zu fixen Terminen
Vorgehensweise
  • Die Belastungskurve MAN wird manuell bei der Ressource gesetzt.
  • Die Eintragung der Aufwände erfolgt im Feld Bel.-Rest im Belastungsdatensatz.
  • Der alte Wert in Bel.-Rest des Belastungsdatensatzes wird beibehalten und kann manuell abgeändert werden.
  • VGR Aufwand-Rest = Summe der Bel.-Rest aller zugehörigen Belastungsdatensätze, d.h. die Belastungen werden nach oben kumuliert.
  • Die VG Dauer-Rest = 0, wenn ein Ist-Ende Termin gesetzt ist.

  • Bei Ressourcenzuordnung mit der Belastungskurve MAN:
    • Wenn kein VG Ist-Anfang gesetzt ist:
      • Dauer vom ersten bis letzten Belastungsdatensatz
    • Wenn VG Ist-Anfang gesetzt ist:
      • Wenn kein VG Ist-Ende gesetzt ist:
        • Splitting = Nein
          • Dauer vom Rückmeldetermin bis zum letzten Belastungsdatensatz
        • Splitting = Ja
          • Dauer vom ersten bis letzten Belastungsdatensatz ohne BEL.-I ??
      • Wenn VG Ist-Ende gesetzt ist:
        • Dauer-R = 0
Hinweis
  • Eine Eingabe dominiert über die Berechnung (nicht bei Vorgängen mit Unterprojekten)

Hinweise

  • Terminverschiebungen können dazu führen, dass unter dem Balken andere Wochenbelastungen als zuvor stehen. Dies liegt daran, dass die Belastungen tagesgenau gespeichert, aber wochengenau dargestellt werden.
  • Für MAN-Ressourcenzuordnungen findet kein Kapazitätsabgleich statt. Sie werden termintreu eingelastet.
Ziel
  • Darstellung des Verhaltens manuell eingeplanter Termine bei Rückmeldung
Details
  • Planstunden der Belastungskurve MAN, die vor der ersten Rückmeldung liegen, werden gelöscht.
  • Stundenrückmeldungen in anderer Höhe als geplant, beeinflussen die weiteren Belastungsdatensätze nicht.
  • Planstunden, die früher als die letzte Rückmeldung liegen, werden nicht auf die zukünftigen Einlastungen verteilt.
  • Rückmeldungen bewirken keine Änderung der eingeplanten Stunden.
  • Die Planstunden von Vorgangsressourcen mit der Belastungskurve MAN werden durch die Terminrechnung nicht verschoben.
Hinweise zur Daueränderung
  • Die Änderung der VG Dauer-Soll bzw. VG Dauer-Rest hat keinen gegenseitigen Einfluss, wenn Ist-Termine existieren. Die VG Dauer-Soll bleibt stehen (Ausgangswert zum Vergleich) und die VG Dauer-Rest berechnet sich. Soll die Dauer des Vorgangs verändert werden, gibt es zwei Möglichkeiten:
    • Manuelle Erfassung von neuen Belastungssätzen hinter die bestehenden. Bei der nächsten Berechnung des Terminplans wird eine neue VG Dauer-Rest ermittelt.
    • Leeren des Datenfeldes Belastungskurve, Änderung der VG Dauer-Soll, KR. Danach Vorgabe der neuen Belastungen.
Hinweise zum Rückgängigmachen manueller Belastungsvorgaben

Belastungskurve BLD (Basic Load)

Information
  • Über die Belastungskurve Basic Load (BLD) können Belastungen linear über die gesamte Pufferzeit eines Vorgangs verteilt werden, wobei
  • Diese Belastungskurve wird für die Ressourceneinsatzplanung für begleitende Tätigkeiten verwendet. Z. B.
    • Grundlastvorgänge (z. B. 1h/Tag für Servicetätigkeiten) oder Grundlastprojekte
    • Projektleitung (z. B. 1h/Tag während der gesamten Projektlaufzeit oder 100h verteilt auf die gesamte Projektlaufzeit)

Besonderheiten der Belastungskurve BLD

  • Ist Vorgang-Dauer-Rest vorgegeben, wird diese berücksichtigt.
  • Wenn einem Vorgang die Belastungskurve BLD zugeordnet und keine VG Dauer-Rest vorgegeben ist, wird die Dauer-Rest des Vorgangs berechnet vom VG frühester Anfang (= VG Kalk. Anfang) bis zum VG spätesten Ende (= VG Kalk. Ende).
  • Ist im Feld max. Belastung/Tag ein Wert eingetragen, wird der Aufwand-Rest = max. Belastung/Tag x Dauer-Rest berechnet.
  • Ist im Feld max. Belastung/Tag kein Wert eingetragen, wird der Aufwand-Rest gleichmäßig über die Dauer-Rest verteilt ( Verhalten wie ohne Belastungskurve: lineare Belastungsverteilung).
  • Vorgänge mit BLD-Ressourcenzuordnungen werden immer termintreu eingeplant. Für sie findet also kein Kapazitätsabgleich statt.
  • Die Ressourcen werden in deren Urlaub nicht eingeplant.
  • Der Vorgang kann über die gesamte Projektdauer hinweg gespannt werden, wenn der Parameter Spannvorgang aktiviert wurde (z.B. für Projektleitung oder Grundlastprojekte).
    • Ein Spannvorgang kann mit Hilfe von AOBs über bestimmte Projektvorgänge hinweg gespannt werden. Beispielsweise kann der AOB-Vorgänger der Meilenstein Projekt Kick-Off und der Nachfolger der Meilenstein Projektende sein. Der Spannvorgang wird sich zwischen diesen beiden Vorgängen aufspannen, wenn er mit den beiden Vorgängen über AOBs verbunden ist.

Beispiel 1. Vorgang Projektleitung

  • Für Projektleitung wird 1h/Tag Belastung über die gesamte Projektlaufzeit eingeplant. Hierfür wird im Feld max. Belastung/Tag 1 Stunde eingetragen und die Checkbox Spannvorgang aktiviert.
Beispiel 2: Vorgang Projektleitung
  • Für Projektleitung werden 100h gleichmässig verteilt über die gesamte Projektlaufzeit eingeplant. Hierfür wird im Feld max. Belastung/Tag kein Eintrag gesetzt und im Feld Aufwand-Rest 100 Stunden eingetragen und die Checkbox Spannvorgang aktiviert.

Beispiel Konstruktionsplanung

  • Beim VG KON Tragkonstruktion sind 80h über 15 Tage Dauer-Rest hinweg eingeplant.
GR0110ST-DE.png

  • Wenn dieser VG die gesamte Pufferzeit nutzen soll, wird bei der Ressourcenzuordnung die Belastungskurve BLD ausgewählt und die Checkbox Spannvorgang aktiviert. Jetzt kann der Vorgang 38 Tage, anstelle von 15 Tagen dauern. Damit hat der Vorgang seinen Gesamtpuffer komplett genutzt. Die vorgegebene Dauer von 15 Tagen wird nicht mehr von der Terminrechnung beachtet.
GR0110SU-DE.png
  • Wenn sich die Vorgänger verzögern, wird die Dauer des Vorgangs 2110 entsprechend reduziert.

Beispiel PPMS-Standard:

GR01503559-DE.png

  • Das Projekt ist geplant mit PR Wunsch-Ende bis 31.05.09, kapazitätstreu
  • Der VG Meeting ist ein Spannvorgang, Ressourceneinplanung 0,6h/Tag, Bel.-Kurve BLD
Hinweise zur aufwandsorientierten Planung:
GR01503560-DE.png
  • Die Dauer-Berechnung bei aufwandsgesteuerten Vorgängen (hier VG 02, 03, 04) erfolgt mit Hilfe der Parameter
  • Existieren keine sonstigen Einschränkungen durch Termine, Nachfolger, etc., dann wird der Vorgang mit dem höchsten Aufwand zuerst berechnet, da dieser den geringsten Puffer hat.
  • Die VG-Dauer dient bei CAP nur der „Terminrahmen-Berechnung“. D.h. innerhalb der berechneten Dauer wird die Ressource dort eingeplant, wo Verfügbarkeit besteht. Wird bis zum Ende des Ressourcenkalenders keine Verfügbarkeit gefunden, erfolgt die Einplanung zum nächstmöglichen Termin nach Ende des Planungshorizonts. Im o.a. Beispiel also zum 01.06.09 (=1. Arbeitstag nach Ende des Projekts).

Gesamtpuffertreue Planung und AA-AOB

Ziel
  • Die Dauer eines Vorgangs wird wegen Überlast verlängert, sofern noch Pufferzeiten verfügbar sind
Details
  • Gesamtpuffertreue Planung.
  • Zwei Vorgänge sind über eine AA-Anordnungsbeziehung miteinander verknüpft.
  • Beide VG haben eine EA-Anordnungsbeziehung zum Meilenstein 1.
  • Ressourcen werden mit der Belastungskurve CAP beplant.
  • Beide Vorgänge werden geplant mit
    • Dauer-Rest = Berechnet durch Vorgabe des Aufwands / Verfügbare Kapazität pro Tag
Information
  • Die von der Terminrechnung ermittelten Puffer werden genutzt.
    • Die Dauer des Vorgangs wird automatisch maximal bis zum Ende des Pufferzeitraums erhöht, um diese Überlast zu vermeiden. In diesem Beispiel wird die Dauer des Vorgangs VG 01 bis zum Meilenstein MS 1 verlängert.
C01500373-DE-00024.gif
  • Verhalten der Terminrechnung
    • Die Zeitrechnung ermittelt die frühesten und spätesten Termine.
    • Der Puffer wird immer bestimmt durch die Differenz von frühesten und spätesten Anfangsterminen bzw. Endterminen.
    • Der späteste Anfangstermin von VG 01 wird durch den Meilenstein MS 1 und den Vorgang VG 02 bestimmt. Die Anordnungsbeziehungen werden eingehalten.
    • Wird das Wunsch-Ende und der Wunsch-Anfang von MS 1 entfernt (Anordnungsbeziehung zu VG 02 bleibt erhalten), dann wirkt das Wunsch-Ende des Projekts als Puffergrenze.

FAQs zur Terminrechnung

Arbeitszeiterfassung während des Urlaubs

FAQ - Frage/Antwort
  • Frage: Kann eine Ressource für einen Tag, an dem sie eigentlich im Urlaub ist, d.h. in der entsprechenden Periode Arbeit = N eingetragen ist, dennoch Arbeitszeit erfassen
  • Antwort: Ja. Dabei wird Arbeit = N ignoriert.

Auswirkung des Kapazitätsabgleichs auf andere Projekte

Information
  • Soll beim Kapazitätsabgleich die Auswirkung auf andere Projekte berücksichtigt werden, müssen alle betroffenen Projekte mit schlechterer Priorität berechnet werden. Die Neuplanung (Berechnung aller Planungsobjekte) führt dies automatisch durch.

Kapazitätsabgleich scheinbar nicht richtig

FAQ - Frage/Antwort
  • Wird bei einem Kapazitätsabgleich scheinbar nicht richtig abgeglichen bzw. liegen bei den Auslastungsdiagrammen noch Überlastungen vor, handelt es sich oftmals um ein Darstellungsproblem, da PLANTA project tagesgenau plant und die Auslastungsdiagramme oft nur wochengenau betrachtet werden.
    • Abhilfe: Auslastungsdiagramme tagesgenau betrachten.

Unerklärliche Überlastung bei kapazitätstreuer Planung

FAQ - Frage/Antwort
  • Eine Ressource zeigt hohe Überlastungen, obwohl sie kapazitätstreu geplant werden soll. Was ist zu überprüfen?
    • Ist für die Ressource der Kenner Abgleich nach Aufwand oder Abgleich nach Kosten auf J gesetzt? Steht Abgleich auf N, findet für diese Ressource kein Kapazitätsabgleich statt, sondern es wird termintreu eingeplant.
    • Haben alle Projekte, denen die Ressource zugeordnet ist, eine Priorität größer als der Wert GP-treu bis Prio. (siehe Modellparameter)? Projekte, für die das nicht zutrifft, werden termintreu oder gesamtpuffertreu gerechnet und können Überlastungen bei der Ressource hervorrufen.
    • Besitzen Vorgänge, denen die Ressource zugeordnet ist, Wunschtermine oder Ist-Termine? Diese können bei ihrer Berücksichtigung durch die Terminrechnung einen Kapazitätsabgleich verhindern.
    • Liegt der Vorgang hinter dem Planungshorizont der Ressource, wird von unendlicher Kapazität ausgegangen, jedoch die Einlastung als Überlast definiert.
  • Bestimmte Vorgänge verursachen immer noch Überlastung, obwohl alle oben genannten Punkte erfüllt sind. Was ist noch zu prüfen?
    • Evtl. liegen diese Vorgänge außerhalb des Planungshorizonts der Ressource. Es wird dann von unendlicher Kapazität ausgegangen, jedoch die Einlastung als Überlast definiert.
    • Die Belastung (pro Periode) kann bei einem Vorgang so groß sein, dass die verfügbare Kapazität in keiner Periode dafür ausreicht.
    • Sammelvorgänge und Spannvorgänge verursachen eine termintreue Einplanung der Ressourcen. Das gleiche gilt unter bestimmten Umständen für Strukturvorgänge. Weitere Erläuterungen hierzu werden im entsprechenden Kapitel gegeben.
Beispiel
  • Für einen Vorgang mit Dauer-Soll des Vorgangs = 10 Tage ist ein Aufwand von 100 h eingetragen. Das entspricht einer Belastung von 10 h/Tag. Für eine Mitarbeiter-Ressource beträgt die verfügbare Kapazität je Tag aber nur 7.75 h. Damit müsste die Vorgangsdauer auf 13 Tage gestreckt werden.
  • Abhilfe:
    • In der Ressourcenzuordnung zum Vorgang für die betreffenden Vorgänge die Belastungskurve CAP eintragen.
      • Bei gesamtpuffertreuer Planung wird der VG-Puffer ausgenutzt.
      • Setzen der Planungsart auf kapazitätstreu. Damit wird beim Einlasten soviel Kapazität verwendet, wie in einer Periode verfügbar ist und die Dauer wird beim Vorgang verlängert, bis der gesamte Aufwand eingelastet ist.
  • Eine Ressource wird kapazitätstreu eingelastet, aber dabei bleiben viele Lücken, in denen nichts eingelastet wird. Hier wird ebenfalls durch Eintrag der Belastungskurve CAP in Ressourcenzuordnung zum Vorgang Abhilfe geschaffen: CAP bei allen Ressourcenzuordnungen des Vorgangs eintragen. Damit erzielt man eine optimale Auslastung der Ressource. Zu beachten ist aber, dass sich die vorgegebenen Vorgangsdauern sich verlängern oder verkürzen können.

Überlastung bei kapazitätstreuer Planung und verschiedenen Belastungskurven

FAQ - Frage/Antwort
  • Ein Vorgang lastet Ressourcen unterschiedlich lange ein und überlastet eine Ressource scheinbar unnötig.
Details
  • Kapazitätstreue Planung
  • Dauer-Soll 10 Tage
  • Aufwand-Soll 100 Stunden
  • Keine Wunschtermine
  • Eine Ressource mit Belastungskurve CAP wird ohne Überlast und länger als 10 Tage eingelastet.
  • Eine Ressource mit linearer Belastungskurve, d.h. das Feld Belastungskurve ist leer, wird die vorgegeben 10 Tage eingelastet und überlastet.
  • Dieses Verhalten ist gewünscht:
    • Eine Ressource mit CAP wird optimiert und ohne Überlast eingeplant.
    • Eine Ressource mit linearer Belastung wird entsprechend den Vorgaben der Dauer-Soll auch mit Überlast eingeplant.
Beispiel
  • R1 wird ohne Überlast vom 25.11.-12.12.08 eingeplant.
  • R8 wird auf die vorgegebene Dauer von 10 Tagen eingeplant und überlastet.
GR01502868-DE.png

Kapazitätsabgleich und Vorgangs-Wunschtermine

FAQ - Frage/Antwort
  • Vorgänge werden durch Kapazitätsabgleich verschoben, obwohl auf Nachfolgevorgängen Vorgangs-Wunschtermine gesetzt sind.
  • Dies ist nur bei kapazitätstreuer Planung mit Parameter Fixierung = 0 der Fall.
Beispiele
  • VG 100 ist überlastet.
  • Termintreue Planung: VG Wunsch-Anfang wird berücksichtigt. Die Überlast von 42 Stunden wird ausgewiesen.
GR01500478-DE.png
  • Gesamtpuffertreue Planung: VG Wunsch-Anfang wird ebenfalls berücksichtigt.
GR01500478-DE.png
  • Kapazitätstreue Planung: Der Kapazitätsabgleich von VG 100 verschiebt den VG 200, obwohl dieser einen VG Wunsch-Anfang besitzt. Die Abweichung zum VG Wunsch-Ende des VG 100 wird als Terminverzug im Balken des VG 100 ausgewiesen.
GR01500479-DE.png
  • Wenn auf dem VG 200 ein VG Wunsch-Anfang mit dem Parameter Fixierung = 1 gesetzt wird, wird der Wunschtermin des VG 200 eingehalten. Die Abweichung zum VG Wunsch-Ende des VG 100 wird als Terminverzug im Balken des VG 100 ausgewiesen.
GR01500480-DE.png

Unerwartete Überlastung bei kapazitätstreuer Planung mit CAP

FAQ - Frage/Antwort
  • Es liegen trotz kapazitätstreuer Planung mit CAP noch Überlastungen vor.
  • Die folgenden Punkte sind in diesem Fall zu überprüfen.
    • Bei Verwendung der termintreuen und gesamtpuffertreuen Planungsart: Alle VG Wunsch-Anfang und VG Wunsch-Ende entfernen. Sonst werden diese Vorgänge termintreu gerechnet.
    • Ist-Termine vorhanden? Vorgänge mit VG Ist-Anfang werden termintreu eingelastet (das heißt, deren Restaufwand). Ggf. mit Splitting = J arbeiten, damit der Restaufwand einem Kapazitätsabgleich unterzogen werden kann.
    • Im Ressourcendatenblatt Abgleich = J für die betreffende Ressource setzen.
    • Planungshorizont prüfen. Sicherstellen, dass sich dort auch Ressourcenperioden befinden, wo ein Kapazitätsabgleich durchgeführt werden soll. Dies geschieht über das Modul 001343 Ressourcendatenblatt in den Feldern Startperiode und Endperiode. Für Zeiträume für welche keine Periodendatensätze mehr verfügbar sind (oder noch keine), gibt es keine Verfügbarkeitsdaten und damit keinen Abgleich. Aber: Planungshorizont nicht übertrieben lang machen (z.B. 4 Jahre). Das kostet unnötig Rechenzeit, ergibt zumeist jedoch keine praxisrelevanten Ergebnisse.
    • Verfügbare Kapazität überprüfen. Ggf. mit max. Belastung/Tag bei Ressourcenzuordnung zum Vorgang dafür sorgen, dass nicht ein Mammutvorgang über Wochen hinweg alle verfügbare Kapazität eines Mitarbeiters verschlingt, sondern z.B. nur mit max. 3 Stunden pro Tag eingelastet wird.
    • Bei Planung mit Projektstrukturen: Die Projektplanungsart muss auch für Unterprojekte so gesetzt sein, dass diese kapazitätstreu gerechnet werden.
    • Planung spät für kapazitätstreu zu rechnende Vorgänge kann zu anderen Ergebnissen bei der Berechnung des Terminplans führen, als der Standardparameter Planung früh und sollte vermieden werden.

Vorgangswunschtermine werden ignoriert

FAQ - Frage/Antwort
  • Vorgänge werden nicht zum VG Wunsch-Anfang eingeplant, welcher vor dem heutigen Datum liegt.
Details
  • Das Projekt hat keinen Wunsch-Anfang.
  • Der Vorgang hat einen Wunsch-Anfang, welcher vor dem heutigen Datum liegt.
  • Der Vorgang wird ab dem heutigen Datum und vor dem VG Wunsch-Anfang eingeplant.
  • Hintergrund: Die Terminrechnung startet die Berechnung ab dem PR Wunsch-Anfang und falls dieser nicht vorhanden, ist ab sonst frühest realistischen Datum, dem Heutedatum.
Beispiel GR01502869-DE.png

Hinweise

  • Über den Parameter Fixierung = 1 kann die Wirkung der Heutelinie ausgeschaltet werden, d.h. der Vorgang wird am Vorgangs-Wunschtermin in der Vergangenheit terminiert.

Einplanung der Ressource weit außerhalb der Wunschtermine

FAQ - Frage/Antwort
  • Eine Ressource mit Überlast wird bei kapazitätstreuer Planung weit außerhalb der Wunschtermine eingeplant.
Details
  • Darstellung eines Spezialfalls zur Mehrkalenderrechnung mit unterschiedlichen arbeitsfreien Tagen von Vorgang und Ressource.
  • Parameter:
    • Kapazitätstreue Planung
    • PR Wunsch-Anfang / Wunsch-Ende ist vorgegeben
    • VG Wunsch-Anfang / Wunsch-Ende und VG Dauer-Soll sind nicht vorgegeben
    • Eine Ressource mit linearer Belastungskurve ist dem Vorgang zugeordnet.
    • Der normale Firmenkalender hat den Zeitraum Karfreitag 10.04.09 bis einschließlich Ostermontag 13.04.09 als arbeitsfreie Tage definiert.
    • Die Ressource
      • hat in ihrem Ressourcenkalender nur den Zeitraum vom 11.04.09 bis einschließlich 13.04.09 als arbeitsfrei definiert.
      • wird mit einer Dauer-Soll von 10 h eingeplant.
      • ist im gesamten März bisher noch nicht eingeplant.
Beispiele
  • Der Vorgang hat keine Dauer-Soll vorgegeben, somit nimmt die Terminrechnung als Wert für Dauer-Soll und Dauer-Rest einen Tag an.
  • Die Ressource wird von der Terminrechnung an zwei Tagen außerhalb der Projektwunschtermine am 10.04.09 und 14.04.09 eingeplant, da der Vorgang keine Wunschtermine hat. Der Projektwunschtermin hat in diesem Fall nur informativen Charakter.
  • Die Terminrechnung übernimmt zur Berechnung der VG Dauer-Rest die Arbeitstage des Betriebskalenders an. Dieser weist für den genannten Zeitraum vom Karfreitag 10.04.09 bis einschließlich 13.04.09 nur einen Arbeitstag aus.
  • Die Ressource hat eine Dauer-Soll von 10 h vorgegeben. Diese Arbeitsleistung ist an einem Tag mit einer vorgegebenen täglichen Verfügbarkeit von 7,2 Stunden nicht zu leisten.
  • Die Ressource wird anhand des Ressourcenkalenders eingeplant und kann im genannten Zeitraum vom Karfreitag 10.04.09 bis einschließlich 14.04.09 zwei Tage arbeiten, während der vom Betriebskalender abhängige Vorgang nur die Dauer von einem Tag ausweist.
  • Somit sind die Restriktionen
    • Vorgangsdauer ein Arbeitstag nach Firmenkalender
    • Ressourceneinplanung ohne Überlastung
  • erfüllt.
  • Dieses Verhalten ist für die Mehrkalenderrechnung gewünscht: Unterschiedliche Ressourcen haben unterschiedliche Verfügbarkeiten und werden dementsprechend eingeplant.
GR01502867-DE.png

Hinweis

  • Ist dieses Verhalten nicht gewünscht, so kann auf den Vorgang ein Wunschtermin oder eine ausreichende Dauer-Soll gesetzt werden. In dem Fall orientiert sich die Zeitrechnung bei der Ressourceneinplanung an diesen Daten.

Kapazitätsabgleich und Maximalbeziehungen

FAQ - Frage/Antwort
  • Beim Kapazitätsabgleich kann es vorkommen, dass Maximalbeziehungen ignoriert werden.
  • Dies ist ein Themengebiet, das derzeit Gegenstand der aktuellen Forschung zur Definition der Ergebnisse an den Universitäten ist.

Unerklärbare Puffer bei Planung mit CAP

Problem
  • Nach einer Berechnung des Terminplans hat ein Projekt unerklärbare Puffer.
Details
  • Nach einer Terminrechnung liegen die spätesten Endtermine der Vorgänge später als der Wunschendtermin des Projekts.
  • Die Kapazitätstermine liegen aber früher als der PR Wunsch-Ende.
Ursache
  • Das Problem tritt nur bei der Planung mit der Belastungskurve CAP auf, wenn bereits durch die Zeitrechnung der PR Wunsch-Ende überschritten wird. Durch die Planung mit CAP können die VG-Dauern und damit das Projekt soweit verkürzt werden, dass der PR Wunsch-Ende aufgrund der verfügbaren Kapazität doch noch gehalten werden kann.
  • Macht man bei dem Projekt den Balken frühester Anfang / frühestes Ende aus Fenster Ausgeblendete sichtbar und führt man nur eine Zeitrechnung durch, so wird dieses Verhalten deutlich.
Hinweise
  • Die Kapazitätsrechnung verwendet die frühesten und spätesten Termine der Zeitrechnung als Ecktermine für den Kapazitätsabgleich. Durch den Kapazitätsabgleich werden die Dauern und Termine neu berechnet und können ggf. verkürzt werden, was dann zu nicht direkt erkennbaren Puffern führen kann.
Beispiel
  • Bei VG Dauer-Soll von 10 Tagen und Aufwand-Soll = 16h (mit CAP) geht die Zeitrechnung zunächst von 10 Tagen Durchlaufzeit aus. Wenn die 16h jedoch in 2 Tagen eingeplant werden können, reduziert sich die Dauer um 8 Tage und es würde ein weiterer Puffer von 8 Tagen ausgewiesen.
Abhilfe
  • Anstelle VG-Dauern und CAP besser nur CAP mit max. Belastung verwenden. Wenn wie im o.g. Beispiel 16h über 10 Tage verteilt werden sollen, so ist es zielführender Aufwand-Soll = 16 und max. Bel. =1,6 und Dauer-Soll = 0 zu setzen.

EE-Beziehungen und Kapazitätsabgleich

Problem
  • Werden 2 Vorgänge durch eine AOB EE 0 verknüpft, verhalten sie sich bei kapazitätstreuer Planung wie EA 0, wenn:
    • der Nachfolger eine Ressource mit Belastungskurve CAP hat.
    • der Nachfolger die Dauer-Soll = 0 hat.
Ursache
  • Verschiebung des Nachfolgers durch Kapazitätsabgleich
  • Die Belastungskurve CAP benötigt für Ihren Abgleich eine Ausgangsdauer. Diese Dauer ist normalerweise die VG Dauer-Soll.
  • Bei einer EE-Beziehung findet folgende Berechnung statt.
  • Der Kapazitätsabgleich mit der Belastungskurve CAP führt nun den Abgleich ausgehend von diesem FAT vorwärts durch.
Umgehungslösung Hinweise
  • Eine AOB EE steht im Widerspruch zur kapazitätstreuen Planung, weil ein kapazitätstreuer Vorgang bis zum Ende des Planungshorizontes geschoben bzw. gedehnt (CAP) werden darf und nicht wie angenommen an der AOB EE enden soll.
  • Für die oben genannte Voraussetzung sind nur die AOBs AA oder AE sinnvoll, die zu folgender Berechnung führen. Z.B AA:
  • Kapazitätsabgleich startet ab frühester Anfang und schiebt bzw. dehnt den Vorgang bis zum vollständigen Abgleich, unabhängig vom Endtermin des Vorgängers.

Abarbeitung normale Projekte / Grundlastprojekte

FAQ - Frage/Antwort
  • Wie ist es zu bewerkstelligen, dass
    • normale Projekte zeitnah abgearbeitet werden.
    • Grundlastprojekte nachrangig behandelt werden.
Details
  • Ausgangslage:
    • Die Vorgänge der Projekte werden zeitnah mit Planung früh eingeplant.
    • Grundlastprojekte
      • haben eine Laufzeit vom 01.01. bis 31.12. des jeweiligen Jahres
      • die Vorgänge werden kapazitätstreu mit Planung spät eingeplant
      • Die Ressourcen haben die Belastungskurve CAP.
    • Hierdurch werden Ressourcen am Ende des Jahres voll eingeplant und zwischen dem heute Datum und dem Jahresende werden Ressourcen nicht eingeplant.

Beispiel

GR01504212-DE.png

  • Gewünscht wird, dass die Grundlast nicht erst am Jahresende, sondern gleichmäßiger und ohne Überlast eingelastet wird.

Beispiel

GR01504213-DE.png

Informationen

  • Die Belastungskurve CAP in Verbindung mit der Planungsstrategie kapazitätstreue Planung ermöglicht die Einlastung der Ressourcen entsprechend ihrer Kapazität.
  • Hierbei orientiert sich PLANTA an der zur Verfügung stehenden Kapazität der Ressource.
  • Die Belastungskurve lineare Einlastung lastet die Ressourcen mit gleicher Stundenzahl pro Tag ein, wird jedoch nicht zum Lastausgleich verwendet. Aus diesem Grund ist sie für die Anforderung Einlastung ohne Überlast nicht geeignet.
Vorgehensweise
  • Eine Möglichkeit zur Lösung der oben genannte Anforderung ist folgende:
    • Die normalen Projekte werden geplant wie bisher.
    • Das / die Grundlastprojekte werden geplant mit:
      • Planung früh
      • Kapazitätstreue Einplanung
      • Geringerer Projektpriorität als die normalen Projekte in DI 001015 PR-Prio.
      • Die Vorgänge erhalten keine Dauer-Soll.
      • Die Ressourcen erhalten eine maximale Last pro Tag, z.B. 4 Stunden

GR01504214-DE.png

Beispiel

GR01504215-DE.png

  • Aufgrund der höheren Projektpriorität der normalen Projekte werden zuerst diese eingelastet. Das Grundlastprojekt und dessen Vorgänge werden erst später eingelastet.
    • Eventuell sind die Ressourcen am Jahresende nicht eingelastet.
    • Verschiebt / verlängert sich das/die normale/n Projekte, wird auch das Grundlast Projekt verschoben:

Beispiel

GR01504216-DE.png

  • Stehen noch Rest-Kapazitäten nach der Einplanung der normalen Projekte zur Verfügung, so werden diese durch das Grundlastprojekt bis zu der definierten maximalen Belastung pro Tag ausgenutzt.
  • Eine Überlastung wird durch die kapazitätstreue Planung vermieden. Ggf. wird der Wunschendtermin des Grundlastprojekts überschritten. Hierdurch wird die zu hohe Einplanung der Ressourcen sichtbar und es können entsprechende Maßnahmen abgeleitet werden, z.B. die maximale Arbeitszeit pro Tag an den Vorgängen des Grundlastprojekts zu erhöhen oder Aufgaben auf das Folgejahr verschieben.

Beispiel

GR01504217-DE.png

Verschobene Einlastungen

Problem
  • Zeiterfassungen werden bei den Perioden einer Ressourcenzuordnung zu einem falschen Zeitpunkt eingelastet.
Ursache
  • Der Systemkalender und die Ressourcen haben unterschiedliche Startperioden. Empfehlung: Der Systemkalender startet früher und endet später als der Ressourcenkalender. Der Systemkalender sollte spätestens ab dem Datum der ersten Buchung beginnen.
  • Durch die unterschiedliche Anzahl von Ressourcen- und Kalenderarbeitsperioden ist es vorgekommen, dass ein abweichender Termin für die Einlastung ermittelt wurde.
Umgehungslösung
  • Tritt das Problem auf, kann durch Setzen der Startperiode des Systemkalenders und der Startperiode der Ressourcen auf den gleichen Termin eine korrekte Einlastung erreicht werden.

Negative Belastung im Auslastungsdiagramm

Details
  • Für einzelne Ressourcen beginnt in Auslastungsmodulen das Auslastungsdiagramm unterhalb der Nulllinie.
  • Die negative Auslastung der Ressource oder einer Unterressource bei eingestelltem Ressourcenparameter Perioden verdichten = J bleibt erhalten, obwohl Belastungsdatensätze mit negativer Ist-Belastung gelöscht wurden.
Beispiel

GR01502171-DE.png

Ursache

  • Software
Vorgehensweise Umgehungslösung
  • Aufruf der Ressource im Modul Ressourcendatenblatt.
  • Umstellen des Parameters Perioden verdichten auf N.
  • Speichern.
  • Zurückstellen des Parameters Perioden verdichten auf J.
  • Speichern.
  • Neuplanung durchführen.
  • PPMS schließen und neu aufrufen.

Verhalten VG-Rückmeldetermin nach Löschen von VG Ist-ET

Details
  • Wird ein Ist-Ende wieder entfernt, initialisiert die Terminrechnung den Rückmeldetermin und berechnet ihn anschließend neu.
  • Der Rückmeldetermin wird aus dem Maximum von Ist-Anfang und den letzten Rückmeldungen der Ressourcenzuordnungen ermittelt.
Beispiel
  • Ausgangszustand
GR01501988-DE.png

  • Der Vorgang 1 erhält jetzt einen VG Ist-Anfang und ein VG Ist-Ende. Ergebnis nach der Terminrechnung

GR01501989-DE.png

  • Wird das VG Ist-Ende geleert, so ergibt sich nach der Terminrechnung:
    • Der Rückmeldetermin wird gelöscht und der Vorgang erhält entsprechend der Ist-Dauer eine Rest-Dauer von 7T.

GR01501991-DE.png

Einplanung von VG Kalk. AT nach Meilensteinen

Details
  • Nachfolger-Vorgänge beginnen am Tag Vorgänger-Kalk. ET, wenn für den Nachfolger -Vorgang gilt:
    • Dauer = 0
    • VG Wunsch-Ende nicht gesetzt
    • AOB-Zeitabstand = 0

GR01502028-DE.png

  • Nachfolger-Vorgänge beginnen am Tag Vorgänger-Kalk. ET + 1, wenn für den Nachfolger -Vorgang gilt:
    • Dauer = 0
    • VG Wunsch-Ende gesetzt
    • AOB-Zeitabstand = 0
    • oder
    • Dauer > 0
    • AOB-Zeitabstand = 0

GR01502029-DE.png

Falsche Berechnung des Feldes Ebene

Problem
  • Andere Berechnung des Feldes Ebene.
Details
  • Werden in einem Modul Projektstrukturen bearbeitet und anschließend in diesem Modul eine TR durchgeführt, werden die Ebenen unter Umständen nicht in der richtigen Reihenfolge errechnet.
Ursache
  • Für die Terminrechnung wird eine softwareseitige Zwangssortierung nach Ebene und PR Wunsch-Ende durchgeführt. Da bei den Unterprojekten weder Ebene noch ein PR Wunsch-Ende vorhanden ist, werden die Projekte zunächst potentiell nicht in der üblichen Reihenfolge sortiert und einzeln gerechnet. Dabei entsteht eine abweichende Ebenenermittlung.
Lösung
  • Nach der 2. Rechnung und jeder weiteren werden die Ebenen richtig berechnet.
  • Wird in einem Modul gerechnet, in dem nur das Hauptprojekt gerechnet wird, z.B. Projektdatenblatt, werden die Ebenen ebenfalls korrekt ermittelt.
  • Bei der Neuplanung werden ebenfalls alle Ebenen richtig ermittelt.
Hinweis
  • Dieses Verhalten kann abweichende Auswertungen zur Folge haben, wenn in Reports nach dem Feld Ebene ausgewählt oder sortiert wird.

Planung früh = N wirkt bei Vorgängen mit Unterprojekten nicht

Problem
  • Planung früh = N wirkt bei Vorgängen mit Unterprojekten nicht.
Ursache
  • Bei Vorgängen mit Unterprojekten wird die Dauer und Position des Vorgangs durch das Unterprojekt definiert. Hat ein Vorgang im Unterprojekt z.B. einen VG Wunsch-Anfang, so soll er diesen VG Wunsch-Anfang halten. Dies widerspricht aber der Idee Planung früh = N beim übergeordneten Vorgang. Daher wird ein übergeordneter Vorgang immer mit Planung früh = J eingeplant.
Umgehungslösung
  • Jeder Vorgang kann durch einen Vorgänger in die späte Position gezwungen werden, wenn der Vorgänger auf Planung früh = N steht. Hierzu kann z.B. ein Meilensteinvorgang mit Dauer-Soll = 0, Planung früh = N und einer AOB: EA Zeitabstand = 0 zum Vorgang, der spät geplant werden soll, erfasst werden.
  • Werden im Unterprojekt alle Vorgänge ohne Vorgänger auf Planung früh = N gesetzt, kann der gleiche Effekt erzielt werden.
Hinweise
  • Hat das Unterprojekt einmal begonnen (d.h. PR Ist-Anfang vorhanden), kann durch Splitten des Vorgangs der Zustand Planung früh = N weiterhin erzwungen werden.
  • Vorgangswunschtermine im Unterprojekt stören weiterhin eine Verschiebung des Projekts auf die spätesten Termine.

Setzen des Projektstatus 9 zur Archivierung

Ziel
  • Optimale Darstellung von Kosten und Aufwänden, wenn Projekte oder Teilprojekte den PR Status 9 zu archivierende Projekte erhalten
Hinweise
  • Alle abhängigen Projekte und Unterprojekte sind zu einem Zeitpunkt auf den Status 9 zu setzen.
  • Sofern dies nicht möglich ist, sollten nur Projekte auf Status 9 gesetzt werden, welche keine aktiven Unterprojekte haben.
  • Es wird in empfohlen, zuerst das Gesamtprojekt durchkalkulieren zu lassen, bevor man es oder seine Teilprojekte nach der Entlastung auf Status 9 setzt. Dies aktualisiert die Kosten- und Aufwandsdaten auf den aktuellen Stand.

Topic attachments
I Attachment History Size Date Comment
Jpgjpg C01500373-DE-00030.jpg r1 54.7 K 2014-08-28 - 09:31  
Pngpng GPT_CAP1.png r1 74.6 K 2019-12-18 - 09:45  
Pngpng GPT_CAP2.png r1 85.8 K 2019-12-18 - 09:46  
Pngpng GPT_CAP3.png r1 90.2 K 2019-12-18 - 09:46  
Pngpng GPT_CAP4.png r1 77.1 K 2019-12-18 - 09:46  
Pngpng GR0110S4-DE.png r1 17.0 K 2014-08-28 - 13:28  
Pngpng GR0110S5-DE.png r1 8.4 K 2014-08-28 - 13:28  
Pngpng GR0110S6-DE.png r1 8.3 K 2014-08-28 - 13:29  
Pngpng GR0110S7-DE.png r1 8.5 K 2014-08-28 - 13:29  
Pngpng GR0110S8-DE.png r1 36.5 K 2014-08-28 - 13:29  
Pngpng GR0110SA-DE.png r1 8.4 K 2014-08-28 - 13:30  
Pngpng GR0110SC-DE.png r1 10.2 K 2014-08-28 - 13:31  
Pngpng GR0110SD-DE.png r1 9.9 K 2014-08-28 - 13:31  
Pngpng GR0110SE-DE.png r1 11.9 K 2014-08-28 - 13:32  
Pngpng GR0110SF-DE.png r1 10.0 K 2014-08-28 - 13:33  
Pngpng GR0110SG-DE.png r1 11.6 K 2014-08-28 - 13:33  
Pngpng GR0110SH-DE.png r1 9.7 K 2014-08-28 - 13:33  
Pngpng GR0110SJ-DE.png r1 12.7 K 2014-08-28 - 13:35  
Pngpng GR0110SK-DE.png r1 6.4 K 2014-08-29 - 09:59  
Pngpng GR0110ST-DE.png r1 12.0 K 2014-08-28 - 13:37  
Pngpng GR0110SU-DE.png r1 12.1 K 2014-08-28 - 13:38  
Pngpng GR0110SY-DE.png r1 8.3 K 2014-08-29 - 10:33  
Pngpng GR0110SZ-DE.png r1 8.0 K 2014-08-29 - 10:33  
Pngpng GR0110T0-DE.png r1 9.1 K 2014-08-21 - 13:43  
Pngpng GR0110T1-DE.png r1 10.0 K 2014-08-29 - 10:44  
Pngpng GR0110T2-DE.png r1 4.2 K 2014-08-29 - 10:45  
Pngpng GR0110T5-DE.png r1 18.5 K 2014-08-28 - 13:40  
Pngpng GR0110TK-DE.png r1 2.4 K 2014-08-21 - 12:00  
Pngpng GR0110TL-DE.png r1 3.9 K 2014-08-21 - 12:14  
Pngpng GR0110TM-DE.png r1 12.4 K 2014-08-28 - 13:26  
Pngpng GR0110TN-DE.png r1 7.8 K 2014-08-28 - 13:27  
Pngpng GR0110TO-DE.png r1 6.8 K 2014-08-21 - 13:44  
Pngpng GR0110TQ-DE.png r1 16.1 K 2014-08-21 - 13:44  
Pngpng GR0110U2-DE.png r1 1.7 K 2014-08-26 - 12:07  
Pngpng GR0110U3-DE.png r1 1.9 K 2014-08-26 - 12:09  
Pngpng GR0110U4-DE.png r1 2.1 K 2014-08-26 - 12:10  
Pngpng GR0110U5-DE.png r1 8.8 K 2014-08-26 - 12:11  
Pngpng GR0110U6-DE.png r1 5.6 K 2014-08-26 - 12:11  
Pngpng GR0110U7-DE.png r1 22.6 K 2014-08-26 - 12:12  
Pngpng GR0110U9-DE.png r1 15.6 K 2014-08-26 - 12:25  
Pngpng GR0110UA-DE.png r1 12.3 K 2014-08-26 - 12:26  
Pngpng GR0110UB-DE.png r1 95.7 K 2014-08-26 - 12:38  
Pngpng GR0110UC-DE.png r1 10.6 K 2014-08-26 - 12:39  
Pngpng GR0110UD-DE.png r1 100.8 K 2014-08-26 - 13:07  
Pngpng GR0110UE-DE.png r1 10.0 K 2014-08-26 - 13:08  
Pngpng GR0110UK-DE.png r1 7.4 K 2014-08-27 - 09:23  
Pngpng GR0110UL-DE.png r1 15.0 K 2014-08-27 - 09:23  
Pngpng GR0110UM-DE.png r1 79.2 K 2014-08-27 - 09:33  
Pngpng GR0110UN-DE.png r1 12.5 K 2014-08-27 - 09:34  
Pngpng GR0110UQ-DE.png r1 12.0 K 2014-08-27 - 11:48  
Pngpng GR0110UT-DE.png r1 12.6 K 2014-08-27 - 11:51  
Pngpng GR0110UV-DE.png r1 16.7 K 2014-08-27 - 11:52  
Pngpng GR0110UW-DE.png r1 13.2 K 2014-08-27 - 12:37  
Pngpng GR0110UX-DE.png r1 14.1 K 2014-08-27 - 12:38  
Pngpng GR0110UY-DE.png r1 15.8 K 2014-08-27 - 12:59  
Pngpng GR0110UZ-DE.png r1 9.0 K 2014-08-28 - 08:43  
Pngpng GR0110V0-DE.png r1 10.5 K 2014-08-28 - 08:43  
Pngpng GR0110V1-DE.png r1 12.0 K 2014-08-28 - 09:30  
Pngpng GR0110V2-DE.png r1 16.2 K 2014-08-28 - 10:29  
Pngpng GR0110V3-DE.png r1 10.6 K 2014-08-28 - 10:30  
Pngpng GR0110V5-DE.png r1 5.7 K 2014-08-28 - 10:30  
Pngpng GR0110V9-DE.png r1 7.0 K 2014-08-28 - 13:14  
Pngpng GR0110VA-DE.png r1 12.0 K 2014-08-28 - 13:14  
Pngpng GR0110VB-DE.png r1 12.1 K 2014-08-28 - 13:15  
Pngpng GR0110VH-DE.png r1 19.1 K 2014-08-28 - 13:24  
Pngpng GR01500473-DE.png r1 15.0 K 2014-08-28 - 13:16  
Pngpng GR01500478-DE.png r1 6.2 K 2014-08-20 - 19:21  
Pngpng GR01500479-DE.png r1 6.4 K 2014-08-20 - 19:22  
Pngpng GR01500480-DE.png r1 6.4 K 2014-08-20 - 19:21  
Pngpng GR01500481-DE.png r1 3.9 K 2014-08-21 - 12:01  
Pngpng GR01500489-DE.png r1 10.9 K 2014-08-26 - 12:12  
Pngpng GR01500490-DE.png r1 95.6 K 2014-08-26 - 13:07  
Pngpng GR01500491-DE.png r1 10.1 K 2014-08-26 - 13:47  
Pngpng GR01500492-DE.png r1 13.6 K 2014-08-26 - 13:50  
Pngpng GR01500493-DE.png r1 11.4 K 2014-08-27 - 09:25  
Pngpng GR01500494-DE.png r1 21.8 K 2014-08-27 - 09:25  
Pngpng GR01500495-DE.png r1 17.1 K 2014-08-28 - 10:31  
Pngpng GR01500820-DE.png r1 8.8 K 2014-08-27 - 09:24  
Pngpng GR01501232-DE.png r1 9.5 K 2014-08-29 - 10:36  
Pngpng GR01501233-DE.png r1 8.3 K 2014-08-29 - 10:37  
Pngpng GR01501234-DE.png r1 12.3 K 2014-08-29 - 10:39  
Pngpng GR01501235-DE.png r1 12.7 K 2014-08-29 - 10:39  
Pngpng GR01501236-DE.png r1 10.1 K 2014-08-29 - 10:40  
Pngpng GR01501988-DE.png r1 11.5 K 2014-08-21 - 11:33  
Pngpng GR01501989-DE.png r1 11.5 K 2014-08-21 - 11:32  
Pngpng GR01501991-DE.png r1 11.4 K 2014-08-21 - 11:33  
Pngpng GR01502028-DE.png r1 11.9 K 2014-08-21 - 11:49  
Pngpng GR01502029-DE.png r1 10.9 K 2014-08-21 - 11:49  
Pngpng GR01502099-DE.png r1 9.4 K 2014-08-27 - 11:14  
Pngpng GR01502139-DE.png r1 13.1 K 2014-08-21 - 11:42  
Pngpng GR01502140-DE.png r1 13.0 K 2014-08-21 - 11:43  
Pngpng GR01502171-DE.png r1 2.2 K 2014-08-21 - 11:27  
Pngpng GR01502249-DE.png r1 6.7 K 2014-08-26 - 12:25  
Pngpng GR01502263-DE.png r1 67.2 K 2014-08-27 - 09:22  
Pngpng GR01502288-DE.png r1 18.4 K 2014-08-25 - 12:32  
Pngpng GR01502289-DE.png r1 7.0 K 2014-08-25 - 12:32  
Pngpng GR01502290-DE.png r1 19.1 K 2014-08-25 - 13:55  
Pngpng GR01502291-DE.png r1 19.8 K 2014-08-25 - 13:56  
Pngpng GR01502292-DE.png r1 12.6 K 2014-08-25 - 14:13  
Pngpng GR01502293-DE.png r1 12.7 K 2014-08-25 - 14:16  
Pngpng GR01502294-DE.png r1 12.7 K 2014-08-25 - 14:17  
Pngpng GR01502295-DE.png r1 14.9 K 2014-08-25 - 15:05  
Pngpng GR01502296-DE.png r1 15.0 K 2014-08-25 - 15:06  
Pngpng GR01502297-DE.png r1 9.4 K 2014-08-26 - 09:09  
Pngpng GR01502298-DE.png r1 9.7 K 2014-08-26 - 09:10  
Pngpng GR01502299-DE.png r1 10.1 K 2014-08-26 - 09:11  
Pngpng GR01502300-DE.png r1 10.0 K 2014-08-26 - 09:14  
Pngpng GR01502301-DE.png r1 10.0 K 2014-08-26 - 09:15  
Pngpng GR01502302-DE.png r1 15.7 K 2014-08-26 - 09:35  
Pngpng GR01502303-DE.png r1 12.8 K 2014-08-26 - 09:37  
Pngpng GR01502304-DE.png r1 13.8 K 2014-08-26 - 09:37  
Pngpng GR01502308-DE.png r1 12.5 K 2014-08-29 - 09:51  
Pngpng GR01502309-DE.png r1 12.7 K 2014-08-29 - 09:52  
Pngpng GR01502310-DE.png r1 12.8 K 2014-08-29 - 09:52  
Pngpng GR01502311-DE.png r1 12.8 K 2014-08-29 - 09:52  
Pngpng GR01502312-DE.png r1 12.8 K 2014-08-29 - 09:53  
Pngpng GR01502377-DE.png r1 3.6 K 2014-08-21 - 12:06  
Pngpng GR01502378-DE.png r1 4.0 K 2014-08-21 - 12:07  
Pngpng GR01502508-DE.png r1 10.8 K 2014-08-29 - 09:47  
Pngpng GR01502509-DE.png r1 11.9 K 2014-08-29 - 09:46  
Pngpng GR01502510-DE.png r1 11.4 K 2014-08-29 - 10:46  
Pngpng GR01502518-DE.png r1 9.1 K 2014-08-27 - 11:50  
Pngpng GR01502519-DE.png r1 9.4 K 2014-08-27 - 11:50  
Pngpng GR01502712-DE.png r1 12.0 K 2014-08-29 - 10:34  
Pngpng GR01502713-DE.png r1 11.8 K 2014-08-29 - 10:34  
Pngpng GR01502920-DE.png r1 14.3 K 2014-08-29 - 10:40  
Pngpng GR01502950-DE.png r1 11.0 K 2014-08-29 - 09:47  
Pngpng GR01502953-DE.png r1 12.0 K 2014-08-29 - 10:35  
Pngpng GR01502964-DE.png r1 17.6 K 2014-08-28 - 13:35  
Pngpng GR01502965-DE.png r1 9.4 K 2014-08-25 - 11:59  
Pngpng GR01502966-DE.png r1 9.3 K 2014-08-25 - 12:00  
Pngpng GR01503448-DE.png r1 89.4 K 2014-08-28 - 13:16  
Pngpng GR01503559-DE.png r1 10.4 K 2014-08-29 - 10:00  
Pngpng GR01503560-DE.png r1 17.1 K 2014-08-29 - 10:00  
Pngpng GR01503578-DE.png r1 2.7 K 2014-08-25 - 09:13  
Pngpng GR01503758-DE.png r1 10.2 K 2014-08-25 - 09:15  
Pngpng GR01503759-DE.png r1 14.9 K 2014-08-25 - 09:34  
Pngpng GR01503760-DE.png r1 10.2 K 2014-08-25 - 09:34  
Pngpng GR01504212-DE.png r1 1.9 K 2014-08-21 - 10:23  
Pngpng GR01504213-DE.png r1 1.5 K 2014-08-21 - 10:24  
Pngpng GR01504214-DE.png r1 5.2 K 2014-08-21 - 10:35  
Pngpng GR01504215-DE.png r1 1.4 K 2014-08-21 - 10:36  
Pngpng GR01504216-DE.png r1 1.6 K 2014-08-21 - 10:36  
Pngpng GR01504217-DE.png r1 1.6 K 2014-08-21 - 10:37  
Pngpng GR01504250-DE.png r1 7.9 K 2014-08-29 - 09:39  
Pngpng GR01504330-DE.png r1 14.7 K 2014-08-29 - 10:31  
Pngpng GR01504438-DE.png r1 14.8 K 2014-08-25 - 12:46  
Pngpng GR01504439-DE.png r1 14.8 K 2014-08-25 - 12:47  
Pngpng GR01504444-DE.png r1 7.3 K 2014-08-29 - 09:49  
Pngpng GR01504640-DE.png r1 11.7 K 2014-08-28 - 13:17  
Pngpng GR01504641-DE.png r1 32.7 K 2014-08-28 - 13:18  
Pngpng GR01504642-DE.png r1 33.4 K 2014-08-28 - 13:18  
Pngpng GR01504643-DE.png r1 34.6 K 2014-08-28 - 13:19  
Pngpng GR01504644-DE.png r1 34.5 K 2014-08-28 - 13:19  
Pngpng GR01504645-DE.png r1 34.9 K 2014-08-28 - 13:20  
Pngpng GR01504646-DE.png r1 34.6 K 2014-08-28 - 13:20  
Pngpng GR01504709-DE.png r1 13.9 K 2014-08-27 - 11:49  
Pngpng KT_CAP1.png r2 r1 66.0 K 2019-12-19 - 13:12  
Pngpng KT_CAP2.png r2 r1 75.7 K 2019-12-19 - 13:12  
Pngpng MAN1.png r1 59.2 K 2019-12-19 - 13:43  
Pngpng MAN2.png r1 59.6 K 2019-12-19 - 13:43  
Pngpng MAN3.png r1 63.6 K 2019-12-19 - 15:09  
Pngpng MAN4.png r1 63.8 K 2019-12-19 - 15:10  
Pngpng MAN5.png r1 51.2 K 2019-12-20 - 12:32  
Pngpng TT_CAP1.png r1 69.1 K 2019-12-18 - 09:09  
Pngpng TT_CAP2.png r1 71.2 K 2019-12-18 - 09:10  
Pngpng TT_CAP3.png r1 46.7 K 2019-12-18 - 09:10  

         PLANTA project









 
  • Suche in Topic-Namen

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