Ich habe ein 2-Milliarden-Dollar-Krankenhaus mit 249 Modellen koordiniert. So lief es ab.

Als ich Ja sagte zur Koordination des UCSF Helen Diller Hospital Tower, gab ich mir drei Regeln. Es einfach machen. Es dauerhaft machen. Es zum Spaß machen.

Alles, was danach kam — die 249 Modelle, die 1,6 Terabyte an Daten, die 130 aktiven Modellierer, der 9-monatige Koordinationsplan mit drei parallel laufenden Stockwerken — wurde um diese drei Prinzipien herum aufgebaut. Sie klingen einfach, aber daran festzuhalten war es nicht.

Die vier Monate, die niemand sieht

Es gibt eine Version dieser Geschichte, die mit Kollisionstests und Automatisierungsregeln und beeindruckenden Zahlen beginnt. Aber der Teil, der das Ganze wirklich zum Funktionieren gebracht hat, ereignete sich noch vor all dem — in einer Reihe von Gesprächen, die ich mit jedem einzelnen Gewerk des Projekts geführt habe.

Ich fragte nicht nur nach Kollisionstoleranzen. Ich fragte nach Baulogik:

• Welche Abstände wirklich nicht verhandelbar waren. Die Toleranzen, über die nach Baubeginn nicht mehr diskutiert wird.
• Welche Elemente bereits als Vorfertigung freigegeben worden waren. Komponenten, die festgelegt waren und sich nicht mehr verschieben ließen — egal, was das Modell anzeigte.
• Welche Kollisionen echte Koordinationsprobleme darstellten und welche nur Modellrauschen waren. Der Unterschied zwischen Aufgaben, die die Zeit eines Koordinators wert sind, und solchen, die alle nur aufhalten würden.

Eines dieser Gespräche veränderte die gesamte Konfiguration grundlegend. Das Trockenbau-Gewerk teilte mir mit, dass es kein Problem damit hatte, wenn Leitungen oder Rohre durch den Steg einer Stahlschiene verliefen — was sie interessierte, war der Flansch. Also entfernte ich den Steg von jedem Ober- und Untergurt im Modell. Von diesem Moment an war jede Kollision, die diese Elemente betraf, bedeutsam. Keine Fehlalarme. Keine Koordinatorzeit, die damit verschwendet wurde, Aufgaben zu triagieren, die auf der Baustelle nie zu echten Problemen werden würden.

Das sagt einem keine Software. Es kommt daher, dass man versteht, wie die Arbeit tatsächlich gebaut wird — und bereit ist, die Zeit vor Projektbeginn zu investieren, um das herauszufinden.

Einen Prozess aufbauen, der zwölf Monate halten würde

Eine Koordinationskonfiguration, die in der ersten Woche brillant funktioniert und im dritten Monat zusammenbricht, ist kein Erfolg. Ich brauchte einen Prozess, der für die gesamte Projektlaufzeit zuverlässig läuft — ohne ständige Eingriffe oder Neuaufbau.

Das bedeutete, die Entwurfsphase wie ein Ingenieursproblem zu behandeln. Ich begann mit 150 Kollisionstests, iterierte auf 108 und landete schließlich bei 96 Tests pro Team, die jeden Dienstag- und Donnerstagabend ausgeführt wurden. Über diese Tests hinweg baute ich 1 422 bedingte Regeln auf — eine Logik, die die Routing- und Zuweisungsentscheidungen automatisiert, die sich sonst in der Warteschlange eines Koordinators anhäufen würden.

Das Ergebnis: 61 % der Stempel gingen ohne jegliche Koordinatorprüfung direkt an die Gewerke. Das ist keine Effizienzmetrik. Es ist der Unterschied zwischen einer Kollisionserkennungskonfiguration und einer echten Koordinations-Engine. Die Funktionen der Kollaborativen Kollisionsautomatisierung in Revizto ermöglichten dieses Niveau an bedingter Logik — aber die Logik selbst musste entworfen, getestet und verfeinert werden, bevor ein einziges Live-Modell einging.

Die Entscheidung, die auf Widerstand stieß

Ich teilte meine Kollisionstests auf drei separate Team-Sets auf, anstatt ein einheitliches System zu betreiben. Das war nicht die naheliegende Wahl, und sie fand nicht überall Zustimmung.

Die Begründung war einfach: Ein einzelnes System ist ein einzelner Ausfallpunkt. Wenn ein Kollisionstest abbricht, stoppt die Koordination auf jedem Stockwerk. Drei unabhängige Sets bedeuten, dass ein Ausfall in einem die beiden anderen nicht anhält. Bei einem Projekt, das mehrere Stockwerke parallel mit einem engen Zeitplan betreibt, ist diese Redundanz kein Nice-to-have — sie ist unverzichtbar.

Wir staffelten auch, welche Systeme wir auf jeder Stufe freigaben. Wir ließen auf einem neuen Level nicht sofort Schwerkraftaufhängungen laufen — wir begannen mit der Hauptverteilung und gaben die Schwerkraftaufhängungen erst einige Wochen später frei. Wir nutzten Tagging, um das Tempo zu steuern, was bedeutete, dass die Gewerke stets ein überschaubares und logisches Arbeitsvolumen vor sich hatten, statt eines überwältigenden Rückstands.

Automatisierung in großem Maßstab dreht sich nicht nur darum, wie schnell das System läuft. Es geht darum, was passiert, wenn etwas schiefläuft. Resilienz muss von Anfang an eingebaut werden — nicht nach dem ersten Ausfall nachgerüstet.

Was der Prozess hervorgebracht hat und wie Revizto dabei half

120 000 identifizierte Stempel. 107 000 gelöste. 93 000 über Erweiterte Automatisierungen ermittelte. Mehr als 500 täglich geschlossene Stempel. Geschätzte 500 000 US-Dollar eingespart gegenüber einem manuellen Workflow.

Diese Zahlen sind das Ergebnis von vier Monaten Planung, akribischem Vortesten und einer Konfiguration, die so ausgelegt war, dass sie ohne ständige Aufsicht läuft. Die Technologie hat es ermöglicht — die Workflows des Integrierten Aufgabenmanagements in Revizto waren entscheidend dafür, wie wir Aufgaben in diesem Volumen verfolgt, geroutet und geschlossen haben — aber die Technologie allein hätte diese Ergebnisse ohne den dahinterstehenden Prozess nicht geliefert.

Das Prinzip, das alles zusammenhielt, war einfach: Automatisiere die Entscheidungen, die kein menschliches Urteilsvermögen erfordern, damit sich die Menschen im Projekt auf die konzentrieren können, bei denen es nötig ist. Dieses Prinzip skaliert. Es funktioniert bei einem 2-Milliarden-Dollar-Krankenhaus. Es funktioniert bei jedem Projekt, bei dem die Koordinationskomplexität die Kapazität des Teams übersteigt, sie manuell zu bewältigen.

Wenn Sie sehen möchten, wie sich dieser Prozess auf Ihre eigenen Projekte übertragen lässt, nehmen Sie noch heute Kontakt mit dem Revizto-Team auf.