Workflows im Bauzeitenplan |
|
Workflows im Bauzeitenplan |
|
1.1 Masterbauzeitenplan
Ein Master-Bauzeitenplan ist quasi eine Kopiervorlage für die Bauzeitenpläne in den Projekten. Ein Master-Bauzeitenplan umfasst dabei die Gesamtheit aller Vorgänge, die in einem Bauprojekt vorkommen können. Diese Vorgänge innerhalb eines Projekt-Bauzeitenplanes werden dann konfiguriert, entweder über Planzeiten aus der Kalkulation (-> Länge der Vorgänge, auch Länge=0) oder durch Workflows im Bauzeitenplan.
Durch die Konfiguration der Bauzeitenpläne kann die Anzahl der notwendigen Bauzeitenpläne minimiert werden.
Ein Beispiel: für Haus mit Keller bzw. Haus auf Bodenplatte ist nur ein Bauzeitenplan erforderlich, da sowohl die Länge der einzelnen notwendigen Vorgänge wie auch deren Anzahl (Planzeit=0) je nach Ausführung mit Keller oder Bodenplatte dynamisch gestaltet werden kann.
Ob auch ein Objektbau im Vergleich zum Hausbau über einen konfigurierbaren Master-Bauzeitenplan abgebildet werden kann, hängt von der Unterschiedlichkeit der Prozesse zur Abwicklung solcher Projekte ab. Wenn der Unterschied nur im Bereich Schall- und Brandschutz liegt, rechtfertigt das noch keine unterschiedlichen Bauzeitenpläne. Irgendwann übersteigt die Komplexität der Prozessdifferenzierung dann aber eine Grenze, wo man dann mit zwei spezifischen Bauzeitenplänen besser beraten ist.
1.2 Workflows in Bauzeitenplänen
Workflows in Bauzeitenplänen dienen nicht nur der Konfiguration, sondern auch der Prozessteuerung und – Überwachung.
Beispiele für mögliche Workflows finden Sie z.B. hier:
Die Einrichtung eines vollständig Workflow-orientierten Bauzeitenplanes kann sehr umfangreich sein. Es besteht – wie die Erfahrung zeigt – durchaus ein gewisses Potential, sich zu verirren und den Durchblick zu verlieren. Daher bietet sich ein systematisches Aufbauen der Workflows in mehreren Stufen an.
Es wird empfohlen, den Master-Bauzeitenplan im ersten Schritt nur mit den sichtbaren Obervorgängen zu versehen und die in den Obervorgängen enthaltenen Untervorgänge erst in einem zweiten Schritt anzulegen.
Es gelten dabei folgende Festlegungen:
•Nur Obervorgänge sind in der Plantafel sichtbar
•Nur Obervorgänge können in grafischen Bauzeitenplanausdrucken verwendet werden
•Nur Obervorgänge können in Multiprojektübersichten verwendet werden
•In allen anderen Aspekten wie Rückmeldung, Verwendung in Worklflows und Listen sind Ober- und Untervorgänge gleichgestellt.
1.2.1 Obervorgänge
Folgende Stufen sollten aufeinanderfolgend abgearbeitet werden:
1.Start-Workflows
Welche Voraussetzungen müssen gegeben sein, um einen Vorgang (= Prozess) zu starten
2.Start-Verarbeitungs-Workflow
Was muss passieren, wenn ein Vorgang gestartet wurde
3.Ende-Workflows
Welche Voraussetzungen müssen gegeben sein, um einen Vorgang fertig zu melden (die Mehrzahl der Vorgänge wird wohl manuell Ende-gemeldet werden)
4.Ende-Verarbeitungs-Workflow
Was muss passieren, wenn ein Vorgang beendet wurde
5.Rollen-Workflows
Hinweisworkflows zur Belegung von Rollen z.B. Festlegung des Projektleiters, des Bauantragsplaners, des Werkplaners, des Elementierers, des Bauleiters etc. zum notwendigen Zeitpunkt
6.Status-Workflows
Unter welchen Bedingungen wird ein Projektstatus gesetzt
7.„Spezial“-Workflows
Prozessgebundene Workflows wie das Setzen des Beginns der Gewährleistung oder Workflows zur automatischen bauzeitenplan-Terminierung bei großen Abweichungen zu den Planterminen
8.Verzug-Überwachungsworkflows
Alle folgenden Beispiele kommen aus dem Muster-Bauzeitenplan für Auslieferungsdatenbanken (Stand 2024).
1.2.1.1 Start-Workflows
Die Start-Workflows dienen dazu, in den Vorgängen des Master-Bauzeitenplans Ist-Start-Termine zu setzen.
Es bietet sich an, hier immer wieder die gleiche Bezeichnung für den Workflow zu verwenden: Ist-Start – Setzen. In diesem Workflow wird ausschließlich das Start-Termin-Setzen abgebildet, keine Verarbeitung! Start-Termine können auch manuell gesetzt werden. Dann würden die Workflows zum Ist-Start – Setzen nicht mehr zur Ausführung kommen und damit auch die Verarbeitungen nicht ausgeführt.
Bedingungen für diese Start-Workflows sind in der Regel Termin-Bedingungen oder Termin-Meldebedingungen. Die zu verwendende Aktion ist das Setze Start-Termin des Vorgangs.
Bsp.: Ist-Start-Setzen Vertragseingang/Auftragsbestätigung
Bsp.: Ist-Start-Setzen Freigabe zur Bemusterung (für das Beispiel der Genehmigung im Genehmigungsverfahren)
Sinngemäß werden damit Vorgänge gestartet, wenn ein oder mehrere andere Vorgänge beendet sind:
Wenn A fertig, dann starte B; wenn B fertig, dann starte C usw.
Diese Workflow-Kette kann durch den ganzen Master-Bauzeitenplan durchgezogen werden.
1.2.1.2 Start-Verarbeitungs-Workflows
Die Start-Verarbeitungs-Workflows dienen dazu, nach dem Setzen eines Ist-Start-Termins die zugehörigen Verarbeitungen anzustoßen.
Es bietet sich an, hier immer wieder die gleiche Bezeichnung für den Workflow zu verwenden: Ist-Start - Verarbeitung. In diesem Workflow können alle Arten von Aktionen ausgeführt werden. Es ist wichtig, diesen Verarbeitungs-Workflow vom Start-Setzen-Workflow zu trennen, weil dieser Verarbeitungsworkflow nur darauf reagiert, dass ein Ist-Start-Datum in einem Vorgang gesetzt wurde. Und dabei ist es dann egal, ob das Ist-Start-Datum manuell oder per Workflow gesetzt wurde.
Bedingung für diese Ist-Start-Verarbeitungs-Workflows ist in der Regel die Termin-Meldebedingung.
Bsp.: Ist-Start-Verarbeitung Vertragseingang/Auftragsbestätigung
Sinngemäß wird damit der Start eines Vorganges verarbeitet, d.h. es werden Aktionen ausgeführt, wenn der Vorgang gestartet wurde:
Wenn A gestartet wurde, dann tue a, b, c, d und e
Diese Workflow-Kette kann durch den ganzen Master-Bauzeitenplan durchgezogen werden.
1.2.1.3 Ende-Workflows
Ende-Workflows werden nur in speziellen Fällen benötigt, meistens im Zusammenhang mit Untervorgängen (siehe dort).
1.2.1.4 Ende-Verarbeitungsworkflows
Die Ende-Verarbeitungs-Workflows dienen dazu, nach dem Setzen eines Ist-Ende-Termins die zugehörigen Verarbeitungen anzustoßen.
Es bietet sich an, hier immer wieder die gleiche Bezeichnung für den Workflow zu verwenden: Ist-Ende - Verarbeitung. In diesem Workflow können alle Arten von Aktionen ausgeführt werden. Es ist wichtig, diesen Verarbeitungs-Workflow vom Ende-Setzen-Workflow zu trennen, weil dieser Verarbeitungsworkflow nur darauf reagiert, dass ein Ist-Ende-Datum in einem Vorgang gesetzt wurde. Und dabei ist es dann egal, ob das Ist-Ende-Datum manuell oder per Workflow gesetzt wurde.
Bedingung für diese Ist-Ende-Verarbeitungs-Workflows ist in der Regel die Termin-Meldebedingung.
Bsp.: Ist-Ende-Verarbeitung Freigabe zur Bemusterung
1.2.1.5 Rollen-Workflows
1.2.1.6 Status-Workflows
1.2.1.7 „Spezial“-Workflows
1.2.1.8.Verzug-Überwachungsworkflows
1.2.2 Untervorgänge
1.2.2.1 Änderungen an den Meldepflichten durch Untervorgänge – Ist-Ende
Untervorgänge haben in einem Punkt i.d.R. Einfluss auf die Obervorgänge und zwar im Bereich der Meldepflichten: Betrachtet man nur die Obervorgänge, so haben diese in der Regel eine direkte Meldepflicht für das Vorgangsende.
Obervorgangs-Ebene:
Wenn A fertig, dann starte B
Die Meldepflicht liegt beim Obervorgang A.
Erhält der Obervorgang A jetzt Untervorgänge A1, A2, …, so ist es in vielen Fällen so, dass die Ende-Meldepflichten auf den Untervorgängen liegen und das Vorliegen der Ende-Meldungen in den Untervorgängen dann die Ende-Meldung für den Obervorgang auslöst.
Untervorgänge im Obervorgang sähen dann z.B. so aus:
Untervorgangs-Ebene:
Wenn A1 fertig und wenn A2 fertig, dann A fertig.
Damit muss in der Strukturierung der Obervorgänge die direkte Meldepflicht auf dem Obervorgang A ausgeschaltet und durch einen Ist-Ende-Setzen-Workflow ersetzt werden.
Das sieht dann konkret z.B. so aus:
Ansonsten gelten für die Untervorgänge alle zuvor getätigten Aussagen zu den Prozessworkflows.
1.2.2.2 Sonderfälle bei Untervorgängen – Ist-Start
Untervorgänge benötigen in der Regel auch einen Ist-Start-Termin über einen Workflow, wenn nicht ein manuelles Melden erwünscht ist. Das manuelle Melden muss durch eine entsprechende Meldepflicht im Untervorgang eingestellt werden. Ein automatisches Ist-Start-Setzen erfolgt durch Workflows.
Die terminliche Verbindung zwischen den Untervorgängen und Ihrem Obervorgang erfolgt durch die Objektbeziehungen – die Verbindungen – zwischen Unter- und Obervorgängen. Jeder Untervorgang hat eine solche Verbindung, die es erlaubt, die Plantermine der Untervorgänge an den jeweiligen Obervorgang zu knüpfen.
Dabei gibt es verschiedene Beziehungsarten:
-AA: Der Anfangstermin des Vorgängers (Obervorgang) bestimmt den Anfang des Nachfolgers (Untervorgang)
-EE: Der Endetermin des Vorgängers (Obervorgang) bestimmt den Anfang des Nachfolgers (Untervorgang)
Die vorgenannten beiden sind die üblichen, also ein Bezug des Untervorganges auf den Anfang oder das Ende des Obervorganges. Zusätzlich können durch den Zeitabstand noch Verschiebungen der Untervorgänge im Bezug auf die Obervorgänge eingestellt werden. Dabei sind auch negative Zeitabstände zulässig.
Das würde dann z.B. so aussehen:
Für jeden Untervorgang kann jetzt – analog zu den Obervorgängen - ein Ist-Start-Workflow aufgebaut werden. Und dieser Workflow ist jetzt frei konfigurierbar.
Bedingungen für diese Start-Workflows sind in der Regel Termin-Bedingungen oder Termin-Meldebedingungen. Dabei kann beliebig auf Ober- und Untervorgänge zugegriffen werden. Die zu verwendende Aktion ist das Setze Start-Termin des Vorgangs.
Bsp.: Ist-Start-Setzen eines Untervorganges mit AA-Verknüpfung und ohne Zeitabstand zum Obervorgang
Zeitgleich mit dem Start des Obervorganges wird auch der Untervorgang gestartet.
Bsp.: Ist-Start-Setzen eines Untervorganges mit AA-Verknüpfung und mit Zeitabstand zum Obervorgang
Zeitgleich mit dem Ende des vorherigen Untervorganges wird auch der Untervorgang gestartet.
So kann jetzt natürlich beliebig weitergearbeitet werden:
A1 (Untervorgang) fertig -> A2 (Untervorgang) starten etc.