stop 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 allgemeinen Informationen zu der Termin, Ressourcen und Kostenplanung in PLANTA Project sowie eine Verwendungsmatrix finden Sie hier.

Termin/Ressourcenplanung und -rechnung

Von der Terminrechnung betroffene Datentabellen (Auszug)

C01500373-DE-00013.gif

Visualisierung von Terminverschiebungen

note Details

  • Folgende Einstellungen sind vor der Visualisierung vorzunehmen.
    • Das Modul Modell und Modellparameter über PM-Administration --> Sonderfunktionen aufrufen.
    • Parameter Heute berücksichtigen aktivieren.
    • Heutefixierug auf den heutigen Tag setzen

info Information

  • Nachfolgend sind die Möglichkeiten der Verschiebung beschrieben. Die Ursachen der Verschiebung sind immer in der genannten Reihenfolge:
    • 1: Projekttermine (Ist-Anfang oder neue Projektwunschtermine)
    • 2: Heutelinie
    • 3: VG Wunsch-Anfang / Wunsch-Ende (neuer Wunsch-Anfang des Verursachers)
    • 4: Dauer ZR (Verlängerung oder Verkürzung der VG Dauer-Soll)
    • 5: Kapazität (Verschiebung aufgrund von mangelnder Kapazität)
    • 6: Dauer KR (Veränderung der Dauer durch die KR)
    • 7: Ist-Termine (Früheres/späteres Starten oder früheres/späteres Beenden durch Ist-Termine)
  • Die möglichen Ursachen werden bei der Terminrechnung ermittelt und in der Verursacherstabelle gespeichert.

note Details

  • Sonderfall weiche AOB
    • Sind Vorgänge durch eine weiche AOB miteinander verbunden, so wird ermittelt, wie sich eine Verschiebung auswirken könnte.
      • Die Ermittlung erfolgt nur auf Basis der Zeitrechnung, d.h. ohne Berücksichtigung der Kapazitätsrechnung.
application Beispiel
Nr. Verschiebung Prüfung Beschreibung Ursache
1 Anfangstermin später als geplant (Verschiebung in die Zukunft)
Verschiebung ohne Vorgänger
Plan-AT versch. Wunsch-Anfang versch.
< (früher) frühester Anfang versch. oder
Kalk. Anfang versch.
Plananfangstermin / Wunsch-Anfang des verschobenen Vorgangs liegt früher als der früheste Anfang / Kalk. Anfang des verschobenen Vorgangs 1: Projekttermine
2: Heutelinie
3: Wunsch-Anfang / Wunsch-Ende des Vorgangs
5: Kapazität
2 Anfangstermin später als geplant (Verschiebung in die Zukunft)
Verschiebung mit Vorgänger
Plan-AT versch. oder
Wunsch-Anfang versch.

< (früher)
frühester Anfang versch. oder
Kalk. Anfang versch.
Plananfangstermin / Wunsch-Anfang des verschobenen Vorgangs liegt früher als der früheste Anfang / Kalk. Anfang des verschobenen Vorgangs 1: Projekttermine
2: Heutelinie
3: Wunsch-Anfang / Wunsch-Ende des Vorgangs
4: Dauer ZR
5: Kapazität
3 Endtermin später als geplant (Endtermin in der Zukunft)
Verschiebung ohne Vorgänger
Plan-ET versch. oder Wunsch-Ende versch.
< (früher) frühestes Ende versch. oder
Kalk. Ende versch.
Planendtermin / Wunsch-Ende des verschobenen Vorgangs liegt früher als das früheste Ende / Kalk. Ende des verschobenen Vorgangs Verursacher: VG1
Ursache:
4: Dauer
5: Kapazität
5 Anfangstermin früher als geplant (Anfangstermin in der Vergangenheit)
Verschiebung ohne Vorgänger
Plan-AT versch. oder
Wunsch-Anfang versch.
(später)
frühester Anfang versch. oder
Kalk. Anfang versch.
Plananfangstermin / Wunsch-Anfang des verschobenen Vorgangs liegt später als der früheste Anfang / Kalk. Anfang des verschobenen Vorgangs Verursacher: VG1
Ursache:
5: Kapazität
7: Ist-Termine
6 Anfangstermin früher als geplant (Anfangstermin in der Vergangenheit)
Verschiebung mit Vorgänger
Plan-AT versch. oder
Wunsch-Anfang versch.
(später)
frühester Anfang versch. oder
Kalk. Anfang versch.
Plananfangstermin / Wunsch-Anfang des verschobenen Vorgangs liegt später als der früheste Anfang / Kalk. Anfang des verschobenen Vorgangs Verursacher: VG1
Ursache:
5: Kapazität
7: Ist-Termine
7 Endtermin früher als geplant (Endtermin in der Vergangenheit)
Verschiebung ohne Vorgänger
Plan-ET versch. oder
Wunsch-Ende versch.
(später)
frühestes Endeversch. oder
Kalk. Ende versch.
Planendtermin / Wunsch-Ende des verschobenen Vorgangs liegt später als das früheste Ende / Kalk. Ende des verschobenen Vorgangs Verursacher: VG1
Ursache:
4: Dauer
5: Kapazität
8 Endtermin früher als geplant (Endtermin in der Vergangenheit)
Verschiebung mit Vorgänger
Plan-ET versch. oder
Wunsch-Ende versch.
(später)
frühestes Ende versch. oder
Kalk. Ende versch.
Plananfangstermin / Wunsch-Anfang des verschobenen Vorgangs liegt später als das früheste Ende / Kalk. Ende des verschobenen Vorgangs Verursacher: VG1
Ursache:
4: Dauer
5: Kapazität
9 VG besitzt mehrere Vorgänger, Verschiebung durch Vorgänger 1 Plan-AT versch.
Wunsch-Anfang versch.
< (früher)
frühester Anfang versch. oder
Kalk. Anfang versch.
Der jeweilige Hauptverursacher bei mehreren Vorgängern wird angezeigt. 1: späterer Projektstart (Ist-AT oder neue Projektwunschtermine)
2: aktive Heutelinie
3: neuer Wunsch-Anfang des Verursachers
4: Dauer Verursacher-Vorgang (= VG1, kann aber auch Teil-PR oder Sammel-VG sein)
5:Kapazität (Verlängerung bzw. Verschiebung)
  • Planung spät
  • Abgleich nach Puffer
  • VGR mit CAP
  • VGR mit MAN
  • VGR mit WAT
  • 10 VG besitzt mehrere Vorgänger, Verschiebung durch Vorgänger 1 wird abgelöst durch stärkere Verschiebung durch Vorgänger 2 Plan-AT versch.
    Wunsch-Anfang versch.
    < (früher)
    frühester Anfang versch. oder
    Kalk. Anfang versch.
      1: späterer Projektstart (Ist-AT oder neue Projektwunschtermine)
    2: aktive Heutelinie
    3: neuer Wunsch-Anfang des Verursachers
    4: Dauer Verursacher-Vorgang (= VG1, kann aber auch Teil-PR oder Sammel-VG sein)
    5:Kapazität (Verlängerung bzw. Verschiebung)
  • Planung spät
  • Abgleich nach Puffer
  • VGR mit CAP
  • VGR mit MAN
  • VGR mit WAT
  • Berücksichtigung von Belastungskurven

    Berechnungsverfahren von echten Belastungskurven

    info Information
    • Belastungskurven werden in 5%-Schritten definiert. Bei der Berechnung der Belastungen durch die KR wird die VG Dauer-Rest durch 20 geteilt und pro Intervall wird der Aufwand-Rest mit der Differenz der Belastungsprozentsätze multipliziert. Daraus ergibt sich die Belastungsverteilung.
    • Generell gilt: Dauer bzw. Aufwand werden vorgegeben, die Belastung wird berechnet.
    warning Hinweis
    • Durch die Division mit 20 kann es z.B. bei den Belastungskurven E und S dazu kommen, dass die Belastung auf mehr als einen Tag verteilt wird. Ist die VG Dauer-Rest z.B. 60 werden 60 / 20 = 3 Belastungsdatensätze erzeugt.
    application Beispiel Auslastungsdiagramme:
    • 3/3
    GR0110S5-DE.png

    • 5025
    GR0110S6-DE.png

    • 5075
    GR0110S7-DE.png

    • GSS
    GR0110SA-DE.png

    info Berücksichtigung von Ist-Daten bei echten Belastungskurven

    • Weicht die Summe der Ist-Belastungen von den geplanten Belastungen ab, gleicht die TR die Rest-Belastungen wieder an die Belastungskurve an.
    application Beispiel
    • Ausgangssituation, ohne Rückmeldung
    GR01119I-DE.png
    • Es wird weniger Aufwand-Ist rückgemeldet als ursprünglich geplant. Die gesamte Differenz wird am ersten Tag nach dem Rückmeldedatum zusätzlich eingelastet
    GR01119K-DE.png
    • Es wird mehr Aufwand-Ist rückgemeldet als ursprünglich geplant. Es wird solange nicht belastet, bis die ursprüngliche Kurve wieder erreicht ist.
    GR01119L-DE.png

    Belastungskurve CAP

    target-blue Ziele
    • Optimierung der Kapazitätseinplanung
    • Berechnung der Belastungen pro Tag
    • Berechnung der Dauern bei der Einlastung
    info Information
    • Die Belastungskurve CAP steht für kapazitätsorientierte Einlastung.
    • PPMS kann die Belastungen pro Tag und die Vorgangsdauer berechnen, wenn der Aufwand vorgegeben wird. Hierbei wird berücksichtigt, wie viel Rest-Kapazität der Ressource noch zur Verfügung steht.
    • Folgende Problematik lässt sich damit lösen:
      • Der Aufwand eines Vorgangs ist bekannt, und die Dauer des Vorgangs soll berechnet werden. Bestehende Belastungen bereits eingelasteter Vorgänge (auch aus anderen Projekten) und die verfügbare Kapazität der Ressource sollen berücksichtigt werden.
      • Die Belastungen pro Tag sollen entsprechend der Verfügbarkeit erfolgen. Dies kann auch dazu führen, dass Vorgänge durch wichtigere Vorgänge unterbrochen werden oder dass Vorgänge verkürzt werden, wenn genügend freie Kapazität vorhanden ist.
    note Typische Anwendung in der Praxis
    • Personenbezogene Planung
    info Information
    • Parameter der Ressourcenzuordnung, die Planung steuern:
      • Eintrag von CAP im Feld Belastungskurve
      • Datenfeld max. Belastung/Tag (optional). Es wird pro Tag höchstens die vorgegebene Belastung eingeplant. Der Wert dient als Ausgangswert zur Berechnung der Dauer-Rest (= Aufwand-Rest / max. Belastung/Tag). Ist nichts eingetragen, wird die gesamte Rest-Kapazität verplant. Es ist auch möglich eine höhere Belastung einzutragen, als im Ressourcendatenblatt vorgesehen. Dann wird dieser Wert zur Planung herangezogen.
      • Datenfeld min. Belastung/Tag (optional). Es wird pro Tag mindestens die vorgegebene Belastung eingeplant. Die Ressource wird nur dann auf einen Tag eingeplant, wenn für diesen mindestens die vorgegebene Belastung zur Verfügung steht, oder wenn überlastet werden muss.
    • Die Planung mit CAP ist nur wirksam, wenn die Ressource Abgleich nach Aufwand oder Abgleich nach Kosten = J besitzt. Sonst ignoriert die KR die CAP-Eintragung.
    application Beispiel
    • Die Ressource KON-M hat 40h verfügbare Kapazität pro Tag (= 8h/Tag x 5 Mitarbeiter). Ein Vorgang mit dem Aufwand von 80h dauert bei Planung mit CAP mindestens

    Termintreue Planung mit CAP

    info Information warning 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.
    application Beispiel
    GR0110SC-DE.png
    • Das Auslastungsdiagramm hierzu:
    GR0110SD-DE.png
    GR01117G-DE.png
    • Das Auslastungsdiagramm hierzu:
    GR01117H-DE.png
    warning Hinweis
    • Sofern das PR beziehungsweise der VG Wunschendtermine haben oder der VG eine Dauer-Soll 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

    target-blue Ziel note 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.
    application Beispiel
    • Das Projekt Gesamtpuffertreu+CAP wird wie folgt eingeplant:
    • Der Vorgang wird maximal bis zum Ende des Puffers verlängert.
    GR0110SE-DE.png

    • Das Auslastungsdiagramm hierzu:
    GR0110SF-DE.png

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

    • Das Auslastungsdiagramm hierzu:
    GR0110SH-DE.png

    warning Hinweis

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

    Kapazitätstreue Planung mit CAP

    info Information
    • Die Ressourcen werden voneinander unabhängig eingelastet sowie die errechneten Dauern und Termine auf den Vorgang verdichtet.
    warning 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.

    Belastungskurve MAN

    target-blue Ziel
    • Darstellung des neuen Verhaltens der Belastungskurve MAN
    note Details neues Verhalten
    • Belastungsdatensätze von MAN-Ressourcen wirken ähnlich wie ein Ist-Termin. Die Planungsdaten sind fixiert und werden nicht durch die TR verschoben.
    • Auch Ist-Termine verändern nicht die MAN – Einplanung.
    • Die Belastungskurve MAN wird nur per Hand und nicht durch die TR gesetzt.
    • Einlastungsreihenfolge in der Terminrechnung: Ist-Termin, MAN, CAP, VGR Wunsch-Anfang / Wunsch-Ende, alle anderen Belastungskurven.
    • 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.
    • Die Länge des Vorgangsbalkens reicht bei reiner Beplanung mit MAN von der ersten bis zur letzten Einplanung, auch wenn mehrere Ressourcen dem VG zugeordnet sind.
    • 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.
    • VGR Wunsch-Anfang / Wunsch-Ende: Diese werden bei MAN ignoriert.
    • VG Parameter Fixierung = 1 und abweichende MAN-Zeitspanne:
    • 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 Heute berücksichtigen, 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.
    note 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.
    application Beispiel Vorgangsdauer
    Beschreibung Ergebnis
    Anlegen von VG mit Dauer-Soll =0 und Ress. mit MAN Belastungsdatensatz. VG wird von erster MAN-Einplanung bis zur letzten MAN-Einplanung aufgespannt.

    GR01502955-DE.png

    application Beispiel VG Wunsch-Anfang wird nicht berücksichtigt

    Beschreibung Ergebnis
    • Anlegen von VG 02 mit Dauer-Soll >0 und Ress. mit MAN Belastungsdatensatz.
    • Setzen eines VG Wunsch-Anfangs nach dem ersten MAN-Belastungssatz.

    GR01502956-DE.png

    application Beispiel VG beginnt zum VG Wunsch-Anfang

    Beschreibung Ergebnis
    • Anlegen von VG mit Dauer-Soll >0 und Ress. mit MAN Belastungsdatensatz.
    • Setzen eines VG Wunsch-Anfangs vor dem ersten MAN-Belastungssatz.
    • VG beginnt zum VG Wunsch-Anfang.
    • Die Einplanung der Ressource erfolgt zum MAN-Termin.

    GR01502957-DE.png

    application Beispiel Verhalten bei CAP und MAN Einplanung, Teil 1

    Beschreibung Ergebnis

    GR01502961-DE.png

    application Beispiel Verhalten bei CAP und MAN Einplanung, Teil 2

    Beschreibung Ergebnis
    • Umsetzen einiger Ressourcen aus dem obigen Beispiel auf MAN, Beibehaltung einer CAP-Ressource.
    • TR

    GR01502962-DE.png

    warning Hinweis

    application Beispiel VGR Wunsch-Anfang wird nicht berücksichtigt
    Beschreibung Ergebnis
    • Anlegen von VG mit Dauer-Soll >0 und Ress. mit MAN-Belastungsdatensätze.
    • Setzen eines VG Wunsch-Anfang vor dem ersten MAN-Belastungssatz.
    • Setzen eines VGR Wunsch-Anfang auf der MAN-Ressource vor dem ersten Belastungsdatensatz, aber nach dem VG Wunsch-Anfang.
    • VG beginnt zum VG Wunsch-Anfang.
    • Die Einplanung der Ressource erfolgt zum MAN-Termin.
    • VGR Wunsch-Anfang wird nicht berücksichtigt.

    GR01502964-DE.png

    warning Hinweis

    • 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.
    target-blue Ziel
    • Belastungen pro Tag gezielt vorgeben
    more 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.
    application Beispiel
    • Die Belastungen pro Woche unter dem Balken oder die Belastungen pro Tag unter der Ressourcenzuordnung können editiert werden.
    GR0110SJ-DE.png

    note Typische Anwendung in der Praxis

    • Freie Verteilung der Kapazitätsbelastung über die Vorgangsdauer.
    • Manueller Kapazitätsabgleich durch Verteilung von Belastungen.
    • Projektmeetings zu fixen Terminen
    more 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. Der Wert VGR Aufwand-Soll bleibt zum Vergleich erhalten.
    • Die VG Dauer-Rest = 0, wenn ein Ist-Ende Termin gesetzt ist.
    GR0110SK-DE.png

    warning 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.
    target-blue Ziel
    • Darstellung des Verhaltens manuell eingeplanter Termine bei Rückmeldung
    note 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.
    warning 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. Die nächste Kapazitätsrechnung berechnet eine neue VG Dauer-Rest .
      • Leeren des Datenfeldes Belastungskurve, Änderung der VG Dauer-Soll, KR. Danach Vorgabe der neuen Belastungen.
    warning Hinweise zum Rückgängigmachen manueller Belastungsvorgaben

    Belastungskurve BLD (Basic Load)

    target-blue Ziel
    • Ressourceneinsatzplanung für begleitende Tätigkeiten (Grundlast, Projektleitung etc.)
    info Information
    • Über die Belastungskurve Basic Load (BLD) können Belastungen linear über die gesamte Pufferzeit eines Vorgangs verteilt werden, wobei
    note Typische Anwedungen in der Praxis
    • Grundlastprojekte (z.B. 1h/Tag für Servicetätigkeiten)
    • Projektleitung (z.B. 1h/Tag während der gesamten Projektlaufzeit oder 100h verteilt auf die gesamte Projektlaufzeit)
    warning Besonderheiten
    • Wenn einem Vorgang die Belastungskurve BLD zugeordnet und keine VG Dauer-Soll vorhanden 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).
    • Eine VG Dauer-Soll oder VG Dauer-Rest wird berücksichtigt.
    • Ist im Feld max. Belastung/Tag ein Wert eingetragen, wird der Aufwand-Rest = max. Belastung/Tag * Dauer-Rest berechnet.
    • Ist im Feld max. Belastung/Tag kein Wert eingetragen, wird der Aufwand-Rest gleichmäßig über die Dauer-Rest verteilt.
    • 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 das DI 001488 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.
    • Die Dauer des Vorgangs und damit die Einplanung BLD-Ressourcenzuordnungen werden bei Strukturvorgängen möglicherweise auf die Dauer des Unterprojektes gesetzt. Dies ist abhängig von den Einstellungen in den Modellparametern. Je nach Wert des Eintrags in das Feld Systemparameter DI000095 STRU-Rechn. m. Abgl. kann sich die Dauer des Vorgangs aus dem Unterprojekt ergeben. Weitere Informationen hierzu stehen im Kapitel über die Planung mit Projektstrukturen.
    application Beispiel Projektleitung
    • Für Projektleitung wird 1h/Tag Belastung über die gesamte Projektlaufzeit eingeplant. Hierfür wird im Feld DI001467 max. Belastung/Tag 1 Stunde eingetragen und das DI 001488 Spannvorgang auf J gesetzt.

    GR01502886-DE.png

    • Für Projektleitung werden 100h gleichmässig verteilt über die gesamte Projektlaufzeit eingeplant. Hierfür wird im Feld DI001467 max. Belastung/Tag kein Eintrag gesetzt und im Feld DI 001410 Aufwand-Soll 100 Stunden eingetragen und das DI 001488 Spannvorgang auf J gesetzt.
    GR01502887-DE.png

    application Beispiel Konstruktionsplanung

    • Beim VG 2110 Kon Tragkonstruktion sind 80h über 15 Tage (Dauer-S) hinweg eingeplant.
    GR0110ST-DE.png

    • Wenn dieser VG die gesamte Pufferzeit nutzen soll, wird bei der Ressourcenzuordnung BLD und das DI 001488 Spannvorgang auf J gesetzt. Jetzt kann er 38 Tage, anstelle von 10 Tagen dauern. Damit hat der Vorgang seinen Gesamtpuffer komplett genutzt. Die Dauer-Soll von 10 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.
    application Beispiel mit geringer Belastung
    • Projekt VGCH, Vorgang (Task) MEETING
    • Ein Vorgang hat mehrere Ressourcen, die zusammen 250 h Sollbelastung haben.
    • Der Vorgang wird immer auf nur eine Woche (05.10.08-09.10.08) eingelastet.
    • Zwei weitere Vorgänge (MGT, DAE), die einen ähnlichen Aufbau zeigen, werden erwartungsgemäß über einen langen Zeitraum eingelastet.
    • Geprüft:
    target-blue Ziel
    • Taskeinplanung für jede Ressource mit vorgegebenem Planungswert pro Tag
    more Vorgehensweise Lösung (vorgesehener Ansatz für diesen Anwendungsfall)
    • Einplanung der Task mit dem Parameter Spann = J (Stretch-Task = Y)
    • Einplanung der Ressourcen mit Belastungskurve = BLD
    application 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
    warning 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).

    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

    target-blue Ziel

    • Einplanung der Vorgänge in Abhängigkeit einer vorgegebenen Vorgangs-/ Arbeitspaketdauer
    info Ü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  

    info Ü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.

    Terminplanung ohne Ressourcenzuordnung bei gesetztem Ist-AT ohne Ist-ET

    target-blue Ziel
    • Planungsmodell ohne Ressourcenzuordnung verwenden.
    note Details application Beispiel
    • Ausgangssituation. Es wurde noch kein Ist-Anfang des Vorgangs gesetzt:
    GR01502308-DE.png

    GR01502309-DE.png

    GR01502310-DE.png

    GR01502311-DE.png

    GR01502312-DE.png

    warning Hinweise

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

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

    GR01502898-DE.png

    GR01502902-DE.png

    GR01502901-DE.png

    Anwendungsfälle der Ressourcenplanung

    Lineare Planung mit Dauer-Soll und Ressourcen

    info Prinzip lineare Planung
    • Vorgabe 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.
    • Einplanung von Ressourcen erfolgt nach Möglichkeit im Block (am Stück).
    note Übersicht
    Anwendungsfall Ablauf Ergebnis
    • Die Dauer-Soll ist vorgeben
    • Planung mit Ressourcen
    • Lineare Planung ohne Belastungskurven
    • Einplanungsart: Termintreu
    • Projekt/VG mit mehreren VGR anlegen
    • Einplanungsart = 0 (Termintreu)
    • Einplanung entlang der Dauer ohne Berücks. Überlasten.
    • Die Einplanung erfolgt nach Möglichkeit im Block, d.h. ohne Unterbrechung. Ausnahme Urlaub:
    • Die Ressource wird im Urlaub nicht eingeplant.
    wie oben, aber Einplanungsart: Gesamtpuffertreu, d.h. so früh wie möglich, aber Ausnutzung von Pufferzeiten zur Reduzierung von Überlastungen
    • Projekt/VG mit mehreren VGR anlegen
    • Einplanungsart = 1 (Gesamtpuffertreu)
    • 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.
    wie oben, aber Einplanungsart: Kapazitätstreu
    • Projekt/VG mit mehreren VGR anlegen
    • Einplanungsart = 2 (Kapazitätstreu)
    • ggf. Eintrag in Belastungskurve entfernen
    • Standard: Die Einplanung erfolgt ohne Berücksichtigung von Wunschdauern und Projektwunschend-Terminen, keine Überlasten, keine Einplanung an nichtverfügbaren Tagen.
    • Ausnahme: Findet Planta Project keine verfügbare Kapazität bis zum Ende der Planungsperiode der Ressource, dann wird zum frühestmöglichen Zeitpunkt auch mit Überlast eingelastet (wie termintreu).

    warning Hinweis:

    • Überlast und Verfügbarkeit bei kapazitätstreuer Planung:
      • Findet Planta Project keine verfügbare Kapazität bis zum Ende der Planungsperiode der Ressource, dann wird auch mit Überlast frühestmöglich eingelastet.
    • Ressource hat während der gesamten Vorgangsdauer Urlaub:
      • Die Einplanung erfolgt mit entsprechender Überlast am ersten Urlaubstag, wenn der gesamte Vorgang im Urlaubszeitraum der Ressource liegt.
    application Beispiel: Überlast bei kapazitätstreuer Planung ohne Urlaub der Ressource
    • Dauer-Soll = 10 Tage
    • Aufwand-Soll = 100h
    • verfügbare Kap. der Ressource pro Tag = 8h
    • die Anforderung kann zu keinem Zeitpunkt erfüllt werden. Die Ressource wird gleichmäßig überlastet
    GR01502908-DE.png

    Planen mit Wunschterminen der Ressource

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

    application Beispiel

    GR01501233-DE.png

    info Information

    application 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.

    application 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.

    application 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.

    application 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
    info 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
    info 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.
    warning 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.
    application Beispiel 1 application 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

    note Ü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
    warning 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
    warning 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
    warning 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
    warning 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
    warning 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
    warning 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.
    warning 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
    warning 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
    warning 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
    warning 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
    warning Hinweis
    • Einplanungszeit der Ressource ggf. kleiner Vorgangsdauer
    • Puffer wird wenn nötig verwendet. Keine Berücksichtigung des Endtermins.

    Aufwandsorientierte Planung

    target-blue Ziel
    • Einplanung der Mitarbeiter in Abhängigkeit des Aufwands
    more 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
    note 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.
    warning 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.
    application 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
    application 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.

    FAQs zur Terminrechnung

    Arbeitszeiterfassung während des Urlaubs

    question 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

    info 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

    question 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.

    Änderungen im Ressourcendatenblatt

    question FAQ - Frage/Antwort
    • Änderungen im Ressourcendatenblatt haben keine Auswirkungen auf die Arbeitsperioden, sind z.B. in Auslastungsdiagrammen nicht sichtbar.
    • Nach Änderung des Planungshorizonts stimmt die Urlaubsplanung nicht mehr.
    info Informationen
    • Werden Daten im
      • Ressourcendatenblatt bzw. im
      • Basiskalender der Ressource geändert, so gelten diese Änderungen nur für Perioden, die danach neu angelegt werden. Alle bereits bestehenden Perioden bleiben unverändert.
    • Werden im Ressourcendatenblatt die Termine in Start - und Endperiode gelöscht, dann gespeichert, so werden alle Arbeitsperioden gelöscht. Individuelle Änderungen, wie z.B. die Urlaubsplanung, gehen dadurch verloren.
    more Vorgehensweise
    • Soll die verfügbare Kapazität innerhalb des bestehenden Planungshorizontes unter Beibehaltung der Urlaubs- und Abwesenheitsplanung verändert werden, muss dies mit dem Modul Ressourcenverfügbarkeit in den einzelnen Perioden geschehen.
    • Sollen Änderungen einer Ressource in allen Perioden unter Verlust der Urlaubs- und Abwesenheitsplanung wirksam werden, muss man
    warning Hinweise
    • Werden die Datenfelder Startperiode und Endperiode verändert, bewirkt dies, dass Perioden in der Datentabelle 468 angelegt oder gelöscht werden. Beim Anlegen werden diese Perioden mit den Werten des Ressourcendatenblatts automatisch vorbelegt. Bestehende Perioden innerhalb des Planungshorizontes werden nicht verändert.
    • Einträge von Urlaub und Abwesenheit sind individuelle Änderungen bestehender Arbeitsperioden. Diese Änderungen weichen normalerweise von den Werten des Basiskalenders der Ressource ab.
    • Nach Änderungen von Periodendatensätzen muss eine Neuplanung durchgeführt werden.

    Unerklärliche Überlastung bei kapazitätstreuer Planung

    question 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.
    application 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

    question FAQ - Frage/Antwort
    • Ein Vorgang lastet Ressourcen unterschiedlich lange ein und überlastet eine Ressource scheinbar unnötig.
    note 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.
    application 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

    question 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.
    application 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

    question 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 in der Kapazitätsrechnung führen, als der Standardparameter Planung früh und sollte vermieden werden.

    Vorgangswunschtermine werden ignoriert

    question FAQ - Frage/Antwort note 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.
    application Beispiel GR01502869-DE.png

    warning Hinweise

    Einplanung der Ressource weit außerhalb der Wunschtermine

    question FAQ - Frage/Antwort
    • Eine Ressource mit Überlast wird bei kapazitätstreuer Planung weit außerhalb der Wunschtermine eingeplant.
    note 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.
    application 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

    warning 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

    question 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

    question Problem
    • Nach einer Kapazitätsrechnung hat ein Projekt unerklärbare Puffer.
    note 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.
    info 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.
    warning 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.
    application 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.
    tip Abhilfe
    • Anstelle VG-Dauern undCAP 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

    question 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.
    info 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.
    tip Umgehungslösung warning 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

    question FAQ - Frage/Antwort
    • Wie ist es zu bewerkstelligen, dass
      • normale Projekte zeitnah abgearbeitet werden.
      • Grundlastprojekte nachrangig behandelt werden.
    note 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.

    application Beispiel

    GR01504212-DE.png

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

    application Beispiel

    GR01504213-DE.png

    info 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 PPMS 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.
    more 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

    application 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:

    application 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.

    application Beispiel

    GR01504217-DE.png

    Verschobene Einlastungen

    question Problem
    • Zeiterfassungen werden bei den Perioden einer Ressourcenzuordnung zu einem falschen Zeitpunkt eingelastet.
    info 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.
    tip 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

    note 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.
    application Beispiel

    GR01502171-DE.png

    info Ursache

    • Software
    tip 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

    note 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.
    application 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

    note 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

    Beim Anstoßen einer Terminrechnung wird die Dialogmeldung Terminrechnung ist gerade aktiv ausgegeben.

    GR01502377-DE.png

    info Ursachen

    • Möglichkeit 1: Es läuft tatsächlich aktuell eine Neuplanung, welche von einem anderen Projektleiter angestoßen wurde.
    • Möglichkeit 2: Eine zuvor gestartete Neuplanung wurde durch Beenden des Programms abgebrochen.
    • In beiden Fällen wird der Statuskenner KR momentan aktiv gesetzt.

    more Vorgehensweise

    • Nach angemessener Zeit (normale Dauer einer TR) prüfen, ob im Datenfeld KR momentan aktiv der Kenner auf Null (kein Eintrag) steht. In diesem Fall kann eine Neuplanung gestartet werden.
    • Ist dies nicht der Fall, muss der Kenner manuell von –1 auf Null zurückgesetzt und gespeichert werden.
    • P49 --> PM-Administration --> Sonderfunktionen --> Status der Terminrechnung bearbeiten.

    GR01502378-DE.png

    Vorgehensweise nach fehlerhaftem Abbruch einer Kapazitätsrechnung

    more Vorgehensweise
    • Aufrufen des Moduls Status der Terminrechnung bearbeiten

    GR0110TL-DE.png

    • Datenfeld KR momentan aktiv auf 0 zurücksetzen
    • Datenfeld KR aktiv bei jeder Ressource auf N zurücksetzen
    warning Hinweise
    • Im Modul Status der Terminrechnung bearbeiten ist die Drag&Drop-Option --> Kopieren Feld in Spalte voreingestellt, damit die Datenfelder KR aktiv schnell auf N geändert werden können.
    • Wird eine KR (z.B. Neuplanung) durch ALT-F4 (= Programm beenden) verlassen, läuft die KR auf dem PPMS-Server weiter. Der Serverprozess erlischt erst, wenn das Ergebnis an den Client gemeldet werden soll und festgestellt wird, dass der Clientprozess nicht mehr existiert.
    • Wenn vor dem Beenden des Serverprozesses die o.g. TR-Parameter wieder zurückgesetzt werden, kann das dazu führen, dass mehrere KR gleichzeitig laufen. Diese können sich gegenseitig behindern, was zu einer Endlosschleife (Deadlock) oder zu völlig unsinnigen Ergebnissen führen kann. Stellen Sie die TR-Parameter erst zurück, wenn Sie sicher sind, dass kein Serverprozess mit einer KR läuft.

    Anwendungsbeispiele

    info Information
    • Zur Verdeutlichung der Zusammenhänge zwischen den verschiedenen Einflussfaktoren auf die Terminrechnung folgen einige Anwendungsbeispiele.
    warning Hinweis
    • 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:)

    GR01502799-DE.png

    • Bei abweichenden Parametereinstellungen können die Ergebnisse entsprechend variieren.
    application 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 vorgeben.
    • 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 vorgeben.
    • 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 ausgenutzt:
    • 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 vorgeben.
    • 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 vorgeben.
    • 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.
    17 Termintreue Planung mit verschiedenen Belastungskurven
    • Einplanung mehrerer Ressourcen mit unterschiedlichen Belastungskurven. Die Dauer-Soll ist vorgegeben.
    • Belastungskurven:
    • Linear
    • BLD
    • WEEK
    • CAP
    • Einplanungsart = termintreu
    • Die Ressourcen werden durch die Terminrechnung gemäß ihres Aufwands und der vorgegebenen Vorgangsdauer eingeplant.
    • Urlaub wird berücksichtigt, die Dauer eingehalten.
    • Bei der Ressource mit der Belastungskurve CAP erfolgt gegebenenfalls eine Optimierung.
    18 Gesamtpuffertreue Planung mit verschiedenen Belastungskurven
    • Einplanung mehrerer Ressourcen mit unterschiedlichen Belastungskurven. Die Dauer-Soll ist vorgegeben.
    • Belastungskurven:
    • Linear
    • BLD
    • WEEK
    • CAP
    • Einplanungsart = gesamtpuffertreu
    • Die Ressourcen werden durch die Terminrechnung gemäß ihres Aufwands und der vorgegebenen Vorgangsdauer eingeplant.
    • Puffer wird bei Bedarf ausgenutzt.
    • Urlaub wird berücksichtigt.
    • Die Dauer wird eingehalten, wenn Puffer nicht benötigt wird.
    • Die Dauer verlängert sich bis zum spätesten Endtermin des Vorgangs, wenn der Puffer benötigt wird.

    info Information

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

    Termintreue Planung mit mehreren Ressourcen

    target-blue Ziel
    • Auswirkung der termintreuen Planungsart mit mehreren Ressourcen auf die Zeitrechnung
    note Details
    • Ein Projekt wird mit mehreren Vorgängen und mehreren Vorgangs-Ressourcen erstellt.
    • Die Dauer-Soll der Vorgänge wird vorgeben oder über Aufwand-Soll / max. Belastung/Tag errechnet.
    • Die Einplanungsart ist termintreu.
    • Die Ressourcen werden mit der Belastungskurve CAP geplant.
    info 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.
    application 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

    warning 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.

    Terminrechnung mit AA-AOB und gesamtpuffertreuer Planung

    target-blue Ziel
    • Die Dauer eines Vorgangs wird wegen Überlast verlängert, sofern noch Pufferzeiten verfügbar sind
    note 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
    info 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 Zeitrechnung
      • Der Vorgang VG 01 besitzt keine Dauer-Soll.
      • 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.
    warning Hinweis
    • Puffer sind Terminpuffer und werden in PLANTA von der Zeitrechnung berechnet. Das bedeutet:
      • Vor jeder Kapazitätsrechnung läuft eine Zeitrechnung. Die dabei ermittelten Termine werden für die Kapazitätsrechnung verwendet.
      • Bei termintreuer Planung werden keine Puffer genutzt.
      • Bei gesamtpuffertreuer Planung werden vorhandene Puffer bei Bedarf genutzt.
      • Bei kapazitätstreuer Planung werden Puffer und der Projektendtermin nicht berücksichtigt.
      • Das beschriebene Verhalten gilt nur für gesamtpuffertreue und kapazitätstreue Planung mit durch die Zeitrechnung optimierbarer Belastungskurve, z.B. CAP.

    Gesamtpuffertreue Planung mit mehreren Ressourcen

    target-blue Ziel
    • Auswirkung der gesamtpuffertreuen Planung mit mehreren Ressourcen auf die Zeitrechnung
    note Details
    • Ein Projekt wird mit mehreren Vorgängen und mehreren Vorgangsressourcen erstellt.
    • Die Dauer-Soll der Vorgänge wird vorgegeben.
    • Die Einplanungsart ist gesamtpuffertreu.
    info 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.
    application 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

    target-blue Ziel
    • Auswirkung der kapazitätstreuen Einplanung auf die Zeitrechnung
    note 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.
    info Informationen
    • Ressourcen werden durch die Terminrechnung ohne Überlastung eingeplant.
    • Bei Ressourcenengpass wird der Vorgang auch über den Projekt Wunsch-Ende hinaus verlängert.
    application 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

    application 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

    Ressourcen mit Urlaub, termintreue Planung

    target-blue Ziel
    • Auswirkung von Urlaub einer Ressource bei termintreuer Planung auf die Zeitrechnung
    note 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.
    info Informationen
    • Die Einplanung erfolgt entlang der Vorgangsdauer.
    • Urlaub wird berücksichtigt.
    • Gegebenenfalls erfolgt die Einplanung mit Überlasten.
    application 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, termintreue Planung

    target-blue Ziel
    • Auswirkung von Urlaub, welcher länger als die Vorgangsdauer ist, auf die Zeitrechnung
    note Details
    • Der geplante Bearbeitungszeitraum des Vorgangs liegt vollständig im Urlaub der Ressource.
    • Die Einplanungsart ist termintreu mit linearer Belastungskurve.
    info 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.
    application 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

    target-blue Ziel
    • Auswirkung der gesamtpuffertreuen Einplanung mit Urlaub einer Ressource auf die Zeitrechnung
    note 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.
    info 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.
    application 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

    target-blue Ziel
    • Darstellung der Auswirkung der kapazitätstreuen Einplanung mit Urlaub einer Ressource auf die Zeitrechnung
    note 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.
    info 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.
    application 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 Wunsch-ET und Fix = 0

    target-blue Ziel
    • Darstellung der Auswirkung der Einplanung mit nicht fixiertes Wunsch-Ende auf die Zeitrechnung
    note 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.
    info 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.
    application 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 Wunsch-ET und Fix = 1

    target-blue Ziel
    • Darstellung der Auswirkung der gesamtpuffertreuen Einplanung mit nicht fixiertes Wunsch-Ende auf die Zeitrechnung
    note Details
    • Der Vorgang hat ein Wunsch-Ende.
    • VG-Parameter DI009480 Fixierung, der Vorgang wird somit auf Termin fixiert.
    • Die Einplanungsart ist gesamtpuffertreu.
    info 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 fixiertes 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.
    application 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

    warning 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

    target-blue Ziel
    • Darstellung der Auswirkung der gesamtpuffertreuen Einplanung von Vorgangsressourcen- Wunsch-Anfang auf die Zeitrechnung
    note 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.
    info 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.
    application 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

    warning 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 Fix = 1

    target-blue Ziel
    • Darstellung der Auswirkung der kapazitätstreuen Einplanung mit Wunsch-Ende ohne Fixierung auf die Zeitrechnung
    note Details
    • Der Vorgang hat ein Wunsch-Ende.
    • VG-Parameter DI009480 Fixierung = 1
    • Die Einplanungsart ist kapazitätstreu.
    info 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.
    application 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 Fix = 0

    target-blue Ziel
    • Darstellung der Auswirkung der termintreuen Einplanung eines Vorgangs mit Vorgänger, Wunsch-Anfang sowie Parameter Fixierung = 0 auf die Zeitrechnung
    note 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.
    info 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.
    application 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:

    GR01502815-DE.png

    GR01502816-DE.png

    Gesamtpuffertreue Planung mit Aufwand über der Verfügbarkeit

    target-blue Ziel
    • Darstellung der Auswirkung der gesamtpuffertreuen Einplanung mit Aufwand oberhalb der Verfügbarkeit auf die Zeitrechnung
    note 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.
    info Informationen
    • Der Puffer der überlasteten Ressource wird ausgenutzt.
    • Die Einplanung durch die Terminrechnung erfolgt zum spätestmöglichen Zeitpunkt.
    application 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

    target-blue Ziel
    • Darstellung der Auswirkung der kapazitätstreuen Einplanung mit Aufwand über der Verfügbarkeit auf die Zeitrechnung
    note 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.
    info 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.
    application 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

    warning Hinweis

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

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

    target-blue Ziel
    • Darstellung der Auswirkung der gesamtpuffertreuen Einplanung mit eines VG mit Vorgänger, Wunsch-Ende und Parameter Fixierung = 0 auf die Zeitrechnung
    note Details
    • Einem Vorgang mit Vorgänger und nicht fixiertes Wunsch-Ende sind mehrere Vorgangsressourcen zugeordnet.
    • Die Einplanungsart ist gesamtpuffertreu.
    info 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.
    application 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 , Fix = 0

    target-blue Ziel
    • Darstellung der Auswirkung der kapazitätstreuen Einplanung eines VG mit Vorgänger, Wunsch-Ende und Parameter Fixierung = 0 auf die Zeitrechnung
    note Details
    • Einem Vorgang mit Vorgänger und nicht fixiertes Wunsch-Ende sind mehrere Vorgangsressourcen zugeordnet.
    • Die Einplanungsart erfolgt kapazitätstreu mit linearer Belastungskurve.
    info 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.
    application 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

    Kalk. AT bei Rückmeldung mehrerer Vorgangsressourcen

    target-blue Ziel
    • Darstellung der Auswirkung der Rückmeldung bei der termintreuen Einplanung ohne Wunschtermine mit mehreren Ressourcen auf die Zeitrechnung
    note 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
    info 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.
    application 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

    target-blue Ziel
    • Darstellung der Auswirkung von im Urlaub zurückgemeldeten Stunden auf die Zeitrechnung
    note 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.
    info 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.
    application 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 verschiedenen Belastungskurven

    target-blue Ziel
    • Darstellung der Auswirkung von termintreuer Planung mit verschiedenen Belastungskurven auf die Terminrechnung
    note Details
    • Einem Vorgang werden Ressourcen mit unterschiedlichen Belastungskurven zugeordnet.
    • Die Einplanungsart erfolgt termintreu.
    • VG 02 ist Plan. spät eingeplant.
    info Informationen
    • Die Ressourcen werden durch die Terminrechnung gemäß ihres Aufwands entlang der vorgegebenen Dauer des Vorgangs eingeplant.
    • Die Vorgangsdauer wird eingehalten, ggf. erfolgt eine Überlastung der Ressourcen.
    • Die Ressourcen werden im Urlaub nicht eingeplant.
    • Bei einer Ressource mit Belastungskurve CAP erfolgt durch die Terminrechnung gegebenenfalls eine Optimierung der Auslastung.
    application Beispiel
    • Die Ressourcen werden nicht im Urlaub eingeplant und ggf. überlastet:

    GR01502826-DE.png

    warning Hinweise

    • Bei der Belastungskurve WEEKist Berechnung der Überlast abhängig von Aufwand, Dauer und verfügbarer Kapazität der einzuplanenden Ressource im gesamten Zeitraum. Die Auslastung am einzuplanenden Tag ist nicht relevant.
    • Nach Einplanung von Urlaub oder sonstiger Nichtverfügbarkeiten von Ressourcen mit der Belastungskurve WEEK wird eine Neuplanung empfohlen.

    Gesamtpuffertreue Planung mit verschiedenen Belastungskurven

    target-blue Ziel
    • Darstellung der Auswirkung von gesamtpuffertreuer Planung mit verschiedenen Belastungskurven auf die Terminrechnung
    note Details
    • Einem Vorgang werden Ressourcen mit unterschiedlichen Belastungskurven zugeordnet.
    • Die Einplanungsart ist gesamtpuffertreu.
    info Informationen
    • Die Ressourcen werden durch die Terminrechnung gemäß ihrem Aufwand entlang der vorgegebenen Dauer des Vorgangs eingeplant.
    • Die Vorgangsdauer wird bis zum Ende des Puffers verlängert.
    • Die Ressourcen werden im Urlaub nicht eingeplant.
    • Bei einer Ressource mit Belastungskurve CAP erfolgt durch die Terminrechnung gegebenenfalls eine Optimierung der Auslastung.
    application Beispiel

    GR01502827-DE.png

    warning Hinweise

    • Bei der Belastungskurve WEEK ist Berechnung der Überlast abhängig von Aufwand, Dauer und verfügbarer Kapazität der einzuplanenden Ressource im gesamten Zeitraum. Die Auslastung am einzuplanenden Tag ist nicht relevant.
    • Nach Einplanung von Urlaub oder sonstiger Nichtverfügbarkeiten von Ressourcen mit der Belastungskurve WEEK wird eine Neuplanung empfohlen.

    Planung mit Projektstrukturen

    info Überblick
    • Dieses Kapitel zeigt die Möglichkeiten der Terminierung von Projektstrukturen. Es erläutert das Verhalten der Terminrechnung von der einfachen Planung mit Projektstrukturen, bis hin zu unterschiedlichen Möglichkeiten des Datenaustauschs zwischen den Projektebenen.

    Einfache Planung mit Projektstrukturen

    target-blue Ziel
    • Gliederung des Projektes in Unterprojekte und Austausch von Termin-, Aufwands- und Kosteninformationen zwischen den Projektebenen
    info Informationen
    • PLANTA Project führt immer die Terminrechnung über das aktuell ausgewählte Projekt und dessen Unterprojekte durch. Das ist unabhängig davon, ob die Unterprojekte ausgewählt und angezeigt werden.
      • Wird das oberste Projekt ausgewählt, terminiert PLANTA Project die gesamte Projektstruktur.
      • Wird ein Unterprojekt ausgewählt, terminiert PLANTA Project dieses und dessen Unterprojekte.
    • Die Berechnung über Projektstrukturen ist als Zeitrechnung oder als Kapazitätsrechnung möglich.
    info Grundsätze
    • Ecktermine werden abhängig von den Modellparametern zwischen dem Hauptprojekt und den Unterprojekten abgeglichen.
    • Dauer und Aufwände werden vom Unterprojekt auf den Strukturvorgang des übergeordneten Projekts verdichtet.

    Erweiterte Planung mit Projektstrukturen

    info Information
    • Bei der Planung mit Projektstrukturen wird der Datenaustausch zwischen den Projektebenen über das Modul Modell und Modellparameter durch den Administrator gesteuert.

    Parameter zur Terminrechnung von Projektstrukturen

    target-blue Ziel
    • Steuerung des Datenaustauschs zwischen Hauptprojekt und Teilprojekt
    info Information

    warning Hinweise

    AE- und EE-Anordnungsbeziehungen bei Strukturvorgängen

    target-blue Ziel
    • Wirkung von AE- und EE- Anordnungsbeziehungen bei Strukturvorgängen
    info Informationen
    • Bei der Berechnung von Projektstrukturen werden die Ecktermine des übergeordneten Vorgangs (z.B. VG frühester Anfang und VG spätestes Ende, abhängig von Modellparametern) an das Unterprojekt als PR- Wunsch-Anfang und PR- Wunsch-Ende übertragen, damit das Unterprojekt innerhalb dieser Ecktermine ablaufen kann.
    • Bei AE- und EE-Beziehungen von Strukturvorgängen ergeben sich deren VG frühester Anfang aber erst nach der Berechnung des Unterprojekts, weshalb diese Termine nicht zuvor nach unten übergeben werden können. Es handelt sich dabei also um ein Huhn-Ei-Problem, was einige andere Projektmanagementsysteme veranlasst, diese Beziehungen erst gar nicht zuzulassen. Bei PPMS sind AE- und EE-Beziehungen von Strukturvorgängen möglich und sie werden wie folgt berücksichtigt:
      • Der PR Wunsch-Anfang des Unterprojekts, dessen übergeordneter Vorgang ein Nachfolger einer AE- oder EE-Beziehung ist, ergibt sich aus:
        • Projekt-Anfangstermin des übergeordneten Projekts, falls keine weitere AA- oder EA-Beziehung auf diesen Vorgang zeigt.
        • VG frühester Anfang des übergeordneten Vorgangs, falls dieser Nachfolger einer EA- oder AA-Beziehung ist.
      • Alle Vorgänge ohne Nachfolger werden soweit verschoben, dass die AE- oder EE-Beziehung eingehalten wird.

    Berücksichtigung der projektübergreifenden AOBs bei der Terminrechnung

    info Information
    • Durch die Verbindung von Projekten über projektübergreifende AOBs entsteht während der Berechnung ein Gesamt-Netzplan aller beteiligten Projekte. Projekte, die mit dem ausgewählten Projekt über PÜ-AOBs verbunden sind, werden automatisch mitberechnet. Dabei werden die eigenen Projekttermine (PR Wunsch-Anfang /Wunsch-Ende, PR Ist-Anfang/Ist-Ende) und Projektprioritäten berücksichtigt.

    warning Berechnungsreihenfolge der Projekte

    • Bei der Neuplanung dominiert bei der Berechnungsreihenfolge die projektübergreifende AOB über die Sortierung bei der Auswahl. Es kann dabei vorkommen, dass ein Projekt mit schlechter PR-Priorität wegen existierenden PÜ-AOBs früher berechnet wird, als dies laut Sortierreihenfolge vorgesehen wäre.

    Rangermittlung mit projektübergreifenden AOBs

    info Information
    • Der Rang eines Vorgangs mit einem PÜ-Vorgänger ermittelt sich als Maximum aus dem Rang innerhalb des eigenen Projekts und dem Rang seines PÜ-Vorgängers.
    application Beispiel
    • Projekt A mit Vorgängen A1, A2, A3 ,A4 und Projekt B mit Vorgängen B1, B2, B3

    GR0110U2-DE.png

    • Vorgang (B2) hat innerhalb seines Projekts den Rang 2. Sein PÜ-Vorgänger (A3) innerhalb dessen Projekts den Rang 3. Damit erhält Vorgang (B2) im Gesamt-Netzplan den Rang 4. Sein Nachfolger den Rang 5.

    GR0110U3-DE.png

    application Beispiel

    • Wenn Projekt B eine schlechtere PR-Prio hat, erhält Vorgang B1 den Rang 3

    GR0110U4-DE.png

    • Einlastungsreihenfolge unter Berücksichtigung der Projektprio ist: A1, A2, A3, B1, A4, B2, B3.

    application Beispiel

    • PÜ-AOBs zwischen unterschiedlichen Hauptprojekten
      • Von Vorgang 03 in Projekt 2511 gibt es eine PÜ-AOB zu Vorgang 01 in Projekt 2512.

    GR0110U5-DE.png

    • Ergebnis der Terminrechnung
      • VG 01 in Projekt 2512 kann erst nach Ende von VG 03 in Projekt 2511 stattfinden. Bei der Berechnung von Projekt 2512 wird Projekt 2511 automatisch mitberechnet. Obwohl das Projekt 2511 eine schlechtere Projektpriorität hat, werden dessen Vorgänge 01 bis 03 vor Vorgang 01 aus Projekt 2512 eingelastet.

    GR01500489-DE.png

    FAQs zur Planung mit Projektstrukturen

    Falsche Berechnung des Feldes Ebene

    question Problem
    • Andere Berechnung des Feldes Ebene.
    note 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.
    info 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.
    tip 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.
    warning 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

    question Problem
    • Planung früh = N wirkt bei Vorgängen mit Unterprojekten nicht.
    info 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.
    tip 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.
    warning 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

    target-blue Ziel
    • Optimale Darstellung von Kosten und Aufwänden, wenn Projekte oder Teilprojekte den PR Status 9 zu archivierende Projekte erhalten
    warning 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.

    Planung mit Ressourcenstrukturen

    info Überblick
    • Dieses Kapitel zeigt die Möglichkeiten der Planung mit Ressourcenstrukturen. Die möglichen Planungs- und Rückmeldestrategien werden behandelt.
    • In PLANTA Project lassen sich beliebig tiefe Ressourcenstrukturen definieren. Ressourcen auf einer höheren Struktur (= Hauptressourcen) können sowohl zur Verdichtung von Auslastungsdiagrammen als auch zur Planung verwendet werden. Auslastungsübersichten für Haupt- und Unterressourcen sind damit möglich.
    application Beispiel einer Ressourcenstruktur

    Verdichtung der Ressourcen

    info Information
    • Die verfügbare Kapazität und die Kapazitätsbelastungen werden entlang der Ressourcenstruktur nach oben verdichtet, wenn im Ressourcendatenblatt bei der Hauptressource Perioden verdichten die Checkbox aktiviert ist.
    application Beispiel

    GR0110U9-DE.png

    note Details

    • Verdichtung der verfügbaren Kapazität
      • Wird die Ressourcenverfügbarkeit verändert, erfolgt beim Speichern die Verdichtung der verfügbaren Kapazität pro Periode entlang der Ressourcenstruktur nach oben. Diese wird im Feld verd. verf. Kap. auf jeder Periode der Hauptressource gespeichert.
    • Verdichtung der Kapazitätsbelastungen
      • Die Kapazitätsbelastungen der Unterressourcen werden durch die TR auf die Hauptressourcen verdichtet und im Feld Verdichtete Auslastung gespeichert.
    application Beispiel

    GR0110UA-DE.png

    • Auslastungsdiagramme, die verdichtete Werte darstellen (z.B. Modul Ressourcenauslastung nach PR-Code), sind auf jeder Ressourcenstrukturebene mit sehr kurzer Laufzeit abrufbar.
    warning Hinweise
    • Sollte es vorkommen, dass die verd. verf. Kap nicht richtig berechnet wurde, kann wie folgt vorgegangen werden:
      • Bei der Hauptressource die Checkbox Perioden verdichten deaktivieren. Speichern. Jetzt wird die Ressourcenstrukturverdichtung aufgehoben.
      • Bei der Hauptressource die Checkbox Perioden verdichten aktivieren. Speichern. Jetzt wird die Ressourcenstrukturverdichtung wieder durchgeführt.
    • Am schnellsten lassen sich solche Korrekturen im Modul Ressourcenübersicht durchführen. Ggf. ist das Datenfeld Perioden verdichten in Fenster 1 oder 2 einzublenden.

    Planung nur auf unterster Ressourcenebene

    info Information
    • Der einfachste Fall ist, auf den untersten Ressourcen zu planen und Auslastungsdiagramme für Hauptressourcen anzuzeigen. Die Hauptressourcen sollten wie im folgenden Beispiel definiert sein.
    application Beispiel

    GR0110UB-DE.png

    • Die Hauptressource hat:
      • keine eigene Verfügbarkeit (Einh./Tag und Faktormenge sind leer)
      • Perioden (Startperiode und Endperiode sind gefüllt). Grund: Auf den Perioden müssen die verdichteten Daten gespeichert werden.
      • die Checkbox Ress. wird beplant ist deaktiviert. Dies verhindert, dass diese Ressource beplant werden kann.
    warning Hinweis
    • Die Checkbox kann nur dann deaktiviert werden, wenn die Ressource in keinem Vorgang eingeplant ist.
    application Beispiel für ein verdichtetes Auslastungsdiagramm

    GR0110UC-DE.png

    Planung nur auf Hauptressourcen

    info Informationen
    • Ein häufiger Planungsfall ist, nur auf Hauptressourcen (z.B. Abteilungen) zu planen. Schwierig ist es dabei, die verfügbare Kapazität (Urlaub, Abwesenheit etc.) auf den Hauptressourcen zu ermitteln und zu pflegen.
    • Hier schafft PPMS eine einfache Lösung: Die Unterressourcen werden zur Urlaubs- und Abwesenheitsplanung angelegt. Diese verdichten ihre verfügbare Kapazität auf die Hauptressourcen, auf denen geplant wird. Dadurch ist die verfügbare Kapazität der Hauptressourcen immer aktuell.
    warning Hinweise
    • Auch für Hauptressourcen ist ein Kapazitätsabgleich möglich.
    • Haupt- und Unterressourcen sollten wie in folgenden Beispielen definiert sein.
    application Beispiel für eine Hauptressource

    GR0110UD-DE.png

    • Die Hauptressource hat:
      • keine eigene Verfügbarkeit (Einh./Tag und Faktormenge sind leer)
      • Perioden (Startperiode und Endperiode sind gefüllt). Grund: Auf den Perioden müssen die verdichteten Daten der Unterressourcen gespeichert werden.
      • Die Checkbox Ress. wird beplant ist aktiviert. Das ermöglicht, dass diese Ressource beplant werden kann.
    application Beispiel für eine zugehörige Unterressource

    GR01500490-DE.png

    • Die Unterressource hat:
      • Perioden (Startperiode und Endperiode) sind gefüllt. Grund: Auf den Perioden werden die Urlaubs- und Abwesenheitszeiten gespeichert.
      • Die Checkbox Ress. wird beplant ist deaktiviert. Das verhindert, dass diese Ressource beplant werden kann. Die TR berücksichtigt die Perioden dieser Ressource nicht, was dazu führt, dass eine Vielzahl solcher Ressourcen keine Laufzeitverschlechterung der TR zur Folge hat.
      • Die Checkbox Perioden verdichten ist aktiviert.
    application Beispiel für ein verdichtetes Auslastungsdiagramm

    GR0110UE-DE.png

    • Nur auf den Hauptressourcen sind Belastungen vorhanden. Auf den Unterressourcen gibt es nur die verfügbare Kapazität.

    Planung auf Haupt- und Unterressourcen

    info Information
    • Haupt- und Unterressourcen können zur Planung verwendet werden.
    note Anwendung in der Praxis 1
    • Die Abteilung will mitarbeitergenau planen. Dem Projektleiter ist bei der Einplanung noch unklar, welcher Mitarbeiter die Arbeiten ausführen wird. Insofern plant er nur die Hauptressource (= Abteilung) ein. Die Feinplanung der Mitarbeiter wird erst später, z.B. vom Abteilungsleiter durchgeführt.
    warning Hinweise
    • Auch für Hauptressourcen ist ein Kapazitätsabgleich möglich.
    • Die Summe der Auslastungen der Unterressourcen muss nicht mit der Auslastung der Hauptressource übereinstimmen. Es kann zusätzliche Belastungen auf der Hauptressource geben, die ggf. später auf die Unterressourcen zu verteilen sind.
    • Es wird empfohlen, in einem Zeitraum entweder nur die Abteilung oder nur die Mitarbeiter zu beplanen.
    application Beispiel 1
    • Verdichtetes Auslastungsdiagramm Ressourcenauslastung nach PR-Code vor Kapazitätsabgleich

    GR01500491-DE.png

    • Verdichtetes Auslastungsdiagramm Verursacher anzeigen nach Kapazitätsabgleich

    GR01500492-DE.png

    info Information

    • Erfolgt eine Einplanung für Mitarbeiter und Abteilung in einem Zeitraum gleichzeitig so kann dies zu Überlastungen führen.
    note Details
    • Die Verdichtung von Ressourcenbelastungen wird durch die Neuplanung neu berechnet.
    • Die Kapazität der einzeln zu beplanenden Ressourcen wird getrennt eingelastet und nach Abschluss der Terminrechnung neu verdichtet.
    • Hierdurch kann die Verdichtung Überlastungen ausweisen.
    application Beispiel, Teil 1
    • Kapazitätstreue Planung
    • Ausgangssituation: Die Abteilung A und deren 3 Mitarbeiter sind noch nicht eingeplant und haben somit jeweils 100 % verfügbare Kapazität.
    • Die Abteilung bezieht ihre verdichtete freie Kapazität aus den freien Kapazitäten ihrer Mitarbeiter.
    • Projekt A
      • Einplanung Abteilung A bei VG 1 zu 50% am 18.10. diesen Jahres.
      • Im Vorgang 2 werden die 3 Mitarbeiter der Abteilung A am 18.10. wie folgt eingeplant:
        • 1 zu 100%
        • 2 zu 50%
        • 3 zu 0%.
      • Somit hat die Abteilung noch eine Restverfügbarkeit von 50 % und die einzelnen Mitarbeiter entsprechend Ihrer jeweiligen Einzeleinplanung auch, da die Verfügbarkeiten noch nicht wieder neu verdichtet wurden.
      • Es ergeben sich folgende Restverfügbarkeiten wenn die Einzelressourcen getrennt voneinander und unverdichtet vor der erneuten Durchführung der Terminrechnung betrachtet:

    Ressource Restverfügbarkeit Rechnerische Restverfügbarkeit auf Abteilungsebene (unverdichtet)
    Abteilung A 50% 50%
    Mitarb. 1 0% 0%
    Mitarb. 2 50% 0,5*1/3 d. Abt. Kapazität => 16,67%
    Mitarb. 3 100% 1/3 d. Abt. Kapazität=> 33,33%

    • Im niedriger priorisierten Projekt B
      • wird bei Vorgang 1 die Abteilung A zu weiteren 25% am gleichen Tag eingeplant.
      • Da die Auslastung der Abteilung noch nicht verdichtet wurde, stellt die Terminrechnung fest, dass die Abteilung A noch 50% verfügbare Kapazität hat und lastet diese mit 25 % ein.
    • Nach der Verdichtung der Einplanung ist das Ergebnis, dass die Abteilung A am 18.10.2008 insgesamt eine Auslastung von 125% hat:

    Ressource Belastung Belastung bezogen auf Abteilung
    Abteilung A 50% aus A und 25 % aus B = 75% 75%
    Mitarb. 1 100% aus A 1/3 d. Abt. Kapazität=> 33,33%
    Mitarb. 2 50% aus A 0,5*1/3 d. Abt. Kapazität => 16,67%
    Mitarb. 3 0% 0%
    Gesamt   125%

    application Beispiel, Teil 2

    • Das Projekt B aus dem obigen Beispiel Teil 1 wird entlastet.
    • Demzufolge ist die verplante verdichtete Kapazität der Abteilung A nur die 100% aus Projekt A.
    • Es wird eine Kapazitätsrechnung nur für Projekt B angestoßen.
    • Diese stellt aufgrund der neuen Verdichtung fest, dass die Abteilung A in Projekt A zu 100% ausgelastet ist und lastet die Abteilung im Anschluss an Projekt A am 19.10.2008 ein.
    • Die Auslastung der Abteilung beträgt nun am 18.10. 100% von Projekt A und am 19.10. 25% von Projekt B.
    warning Hinweise
    • Die Terminrechnung kann bei der Planung mit Abteilungen nicht beurteilen, welcher Mitarbeiter der Abteilung für einen Vorgang vorgesehen ist.
      • Im obigen ersten Beispiel kann bei Projekt B nicht durch einen Automatismus in der Terminrechnung gesagt werden, ob z.B. Mitarbeiter 3 die 25 % der Abteilungseinplanung voll leisten wird oder ob die Aktivitäten in irgendeinem Verhältnis zwischen Mitarbeiter 2 und 3 aufgeteilt werden.
      • Somit ist eine Planung auf Abteilungs- und auf Mitarbeiterebene zu einem Zeitpunkt bzw. innerhalb eines Zeitraums nicht sinnvoll und wird nicht empfohlen.
    • Wenn das oben genannte Verhalten nicht gewünscht ist, wird empfohlen Abteilungen und Mitarbeiter nicht zu einem Zeitpunkt zu verplanen.
    • Grundsätzlich ist es möglich, eine Abteilung abteilungsgenau und eine andere Abteilung im gleichen Zeitraum mitarbeitergenau zu planen.

    Laufzeitaspekte bei der Gestaltung der Ressourcenstruktur

    target-blue Ziel
    • Optimierung des Laufzeitverhaltens bei Durchführung der Terminrechnung
    info Informationen
    • Die Anzahl der Planungsperioden ist bei der Terminrechnung wesentlich bestimmend für den benötigten Hauptspeicher und für die benötigte Rechenzeit.
    • Der Anteil der Ressourcen ohne Planungsperioden sollte möglichst hoch sein, dies können sein:
      • Ressourcen, für die keine Kapazitätsplanung erfolgt, die jedoch (z.B. aus Gründen der Auswertung) den Vorgängen zugeordnet werden (z.B. Ressource Einkauf).
      • Ressourcen im oberen Teil der Hierarchie, für die aber keine Kapazitätsauslastung gemacht werden soll (z.B. Ressource Gesamtbetrieb).
      • Ressourcen, die Mitarbeiter darstellen und nur zur Stundenrückmeldung, aber nicht zur Planung benötigt werden.
    • Ressourcen mit Planungsperioden sind daher nur diejenigen, für die
      • tatsächlich eine Kapazitätsplanung durchgeführt wird.
      • Auslastungsdiagramme erstellt werden sollen.
      • eine Verfügbarkeitsplanung (z.B. Urlaub) personenbezogen erfolgen soll (Mitarbeiter).
    • Ausnahme: Mitarbeiterressourcen mit Ress. wird beplant = N. Diese haben keinen negativen Einfluss auf die Laufzeit und den Hauptspeicherverbrauch der Terminrechnung.
    • Die Festlegung eines realistischen, aber knappen Planungshorizonts ist wesentlich: Jede Ressource benötigt pro Tag einen Periodendatensatz in der Datenbank. Falls für die verfügbare Kapazität genaue Informationen z.B. für ein Jahr vorliegen, wird der Planungshorizont z.B. jedes Quartal rollierend verschoben.
    • Die Gesamtanzahl der Planungsperioden errechnet sich aus:
      • Anzahl der Ressourcen mit Kapazitätsplanung * Planungshorizont
    • Der benötigte Speicherplatz hierfür errechnet sich dann ungefähr aus:
      • Gesamtanzahl der Perioden * 0,2 KB.
    • Bei knappem Hardware-Ausbau wird empfohlen, zu Beginn auf die Mitarbeiter-Verfügbarkeitsplanung zu verzichten und abteilungsbezogen zu planen.

    Mittel- und langfristige Ressourcenplanung

    target-blue Ziel
    • Optimierung des Laufzeitverhaltens der Terminrechnung durch Reduzierung der Planungsperioden
    info Informationen
    • Wenn eine langfristige Ressourcenplanung (z.B. über die nächsten 5 Jahre) erfolgen soll, empfiehlt es sich, diese nur für Hauptressourcen durchzuführen.
    • Folgende Planungshorizonte werden dann empfohlen:
      • Mitarbeiterressource z.B. 1 Jahr (= Kurz- und Mittelfristplanung)
      • Abteilungsressource z.B. 5 Jahre (= Langfristplanung).
    • Die Ressourcen sind dann wie im folgenden Beispiel zu definieren.
    application Beispiel
    • Mitarbeiterressource:
      • Startperiode: 01.01.08
      • Endperiode: 31.12.08
    • Abteilungsressource:
      • Startperiode: 01.01.08
      • Endperiode: 31.12.08
      • keine eigene Verfügbarkeit
    • Abteilungsressource:
      • Startperiode: 01.01.06
      • Endperiode: 31.12.09
      • Verfügbarkeit: 2 Mitarbeiter
    • Hierfür sind diese Eingaben im jeweiligen Ressourcendatenblatt zu erstellen und abzuspeichern. Beim Speichern werden die entsprechenden Datensätze für die angegebene Periode generiert.
    • Die Datensätze werden additiv angelegt.
    application Beispiel
    • Eine Ressource hat vom 1.1.08 –30.6.08 eine Verfügbarkeit von 4h pro Tag.
      • Einh./Tag = 4
      • Startperiode = 1.1.08
      • Endperiode = 30.6.08
    • Diese Ressource arbeitet vom 01.07.08 bis 31.12.08 8h pro Tag
      • Einh./Tag = 8
      • Startperiode = 1.1.08
      • Endperiode = 31.12.08
      • Speichern.
    • Hierdurch sind die Verfügbarkeiten wie oben angegeben generiert worden.
    warning Hinweis
    • Für diesen speziellen Fall darf der Eintrag im Feld Startperiode nicht verändert werden, sondern nur der Eintrag im Feld Endperiode. Ansonsten werden die bestehenden Daten gelöscht und nur der gesamte neu definierte Zeitraum mit den neuen Daten gefüllt.

    Ressourcenplanung mit Skills

    info Überblick
    • Skills können Ressourcen zugeordnet werden um zu erkennen, welche Mitarbeiter für eine bestimmte Qualifikation (=Skill) zur Verfügung stehen. Über diese Skills lässt sich auch eine Kapazitätsplanung durchführen.
    • Hierzu ist folgendes erforderlich:
      • Ein Skill ist zusätzlich auch als Ressource (= Skill-Ressource) anzulegen.
      • Die Skill-Ressource ist dem Skill ebenfalls zuzuordnen.

    GR01502263-DE.png

    • Im Modul Skills werden die Skills definiert.

    • Der Skill Customizer ist angelegt und es sind bereits Ressourcen zugeordnet.

    GR0110UK-DE.png

    • Es wird zusätzlich eine gleichlautende Skill-Ressource erfasst, die keine eigene Verfügbarkeit hat, jedoch Perioden besitzt, damit darauf eingelastet werden kann.

    GR0110UL-DE.png

    • Die Skill-Ressource wird ebenfalls dem Skill zugeordnet.

    GR01500820-DE.png

    • Die Skill-Ressource kann Vorgängen zugeordnet werden.

    GR01500493-DE.png

    • Das Auslastungsdiagramm des Skills liefert die Summe aus verplantem Skill und Auslastung der Mitarbeiter, denen dieses Skill zugeordnet ist.

    GR01500494-DE.png

    info Möglichkeiten der Skill-Planung

    • Skills können komfortabel geplant werden.
    • Eine Gegenüberstellung des Skill-Bedarfs und der Skill-Verfügbarkeit ist im Auslastungsdiagramm gegeben.
    • Der Aufruf von Auslastungsdiagrammen über Skills dauert ggf. länger, da die Daten immer zur Laufzeit verdichtet werden.
    • Es kann wird kein Kapazitätsabgleich über Skill-Ressourcen vorgenommen, da diese keine eigene verfügbare Kapazität haben. Bei der Ressourcenzuordnung wird daher immer Überlastung ausgewiesen.

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








     
    • Suche in Topic-Namen

    • Suche in Topic-Inhalten