Anforderungen an die Kapazitätsplanung

Warum ist Kapazitätsplanung in der TGA so kompliziert?

Roman: Moin und herzlich willkommen zum einzigen Podcast von der TGA-Bar. Ich sitze wieder mit Lars Schumacher da. Sören hat noch einmal ausgesetzt, ist beim nächsten Mal wieder dabei.

Lars: Hallo Roman, ich freue mich, dass ich dabei sein darf.

Roman: Wir haben heute ein Thema, das auch in der Happy Hour immer wieder als wichtig bewertet wurde: Kapazitätsplanung. Und Kapazitätsplanung ist kompliziert.

Lars: Unglaublich kompliziert und unglaublich wichtig — und jeder möchte gern die perfekte Lösung haben.

Roman: Wir versuchen uns wieder HOAI-mäßig daranzutasten, die Probleme und die Aufgabenstellung zu verstehen. Einfach gesagt: Wir haben einen Haufen Leute, die ein Projekt machen müssen, und einen Bauherrn beziehungsweise ein Projektteam, das zu einem bestimmten Zeitpunkt die Leistung haben möchte. Jetzt geht es darum, ob das Team zur Verfügung steht, um diese Leistung zu erbringen.

Lars: Man könnte das Problem auch umgekehrt beschreiben: Man hat keinen Haufen Leute, sondern einen Haufen Projekte und muss klug Kapazitäten planen, sodass der Haufen Projekte abgearbeitet wird und alles gut wird. Das sind Herausforderungen, die wir tagtäglich in allen Unternehmen sehen.

Roman: Und das eigentliche Problem ist die ständige Veränderung. Ein Projekt verschiebt sich, jemand hat nicht pünktlich abgegeben, meine Vorleistung ist nicht da, Leute sind krank oder spontan im Urlaub.

Lars: Das ist ein ständiges agiles Miteinander, um zu reagieren. Jede Kapazitätsplanung hält wahrscheinlich nur genau einen Tag, bis wieder etwas Neues passiert, auf das man reagieren muss.

Welche drei Stakeholder-Ebenen hat die Kapazitätsplanung?

Roman: Wir versuchen in dieser Folge, unsere Ansprüche und Wünsche an eine gute Kapazitätsplanung zu formulieren — wir sind also in der Grundlagenermittlung. Wir glauben, dass das Thema Visualisierung das Wesentliche ist. Datenerfassung, Daten verknüpfen, analysieren und auswerten haben die meisten Büros halbwegs im Griff. Wenn du eine Software hast, hast du normalerweise auch eine Zeiterfassung, und es wird erfasst, wann die Leute im Urlaub sind.

Lars: Das statische Aufnehmen der Daten ist auch kein Problem, da gibt es von Excel bis zum Controlling-Tool ziemlich viele Lösungen. Aber das einfache Visualisieren, Erkennen — vielleicht auch eine Software, die sagt: Achtung, heute ist gerade A passiert, darum schlage ich B vor — das vermissen wir alle.

Roman: Zur Basis, Richtung Konzept: Was mache ich in der Kapazitätsplanung? Zuerst die Dateneingabe. Die fängt beim Projekt mit der Honorarermittlung an: Ich habe die Anlagengruppen, ich habe die Honorarermittlung, und daraus kann ich mir Zeitbudgets bauen. Auch bei einem freigeschriebenen Angebot habe ich meist Pauschalpakete, aus denen ich Stunden ableite; und bei einem Stundenangebot schätze ich die Stunden ab. So bekomme ich für das Projekt ein Stundengebirge, das abzuarbeiten ist.

Die zweite Eingabe sind die Leute, die am Projekt arbeiten — und vorher die Termine. Ich lege das Team und dessen Kapazitäten fest: In der Software ist hinterlegt, ob jemand Urlaub hat, ob er 32 Stunden oder mehr pro Woche arbeitet. Die dritte Eingabe ist die Frage, wann dieses Stundengebirge in welchem Zeitraum bearbeitet werden muss. Hier wird es bei den meisten Programmen unschön: Es gelingt kaum, visuell ansprechend zu zeigen, wann Leistungsphase 2, 3, 4, 5, 6 erbracht wird. Als Geschäftsleitung möchte ich mich aber zum Beispiel alle zwei Wochen mit den Projektleitern hinsetzen und übersichtlich sehen, in welchem Status meine Projekte gerade sind.

Lars: Man hat verschiedene Perspektiven auf die Kapazitätsplanung. Ein Fachplaner möchte wissen, was genau seine drei Projekte dieser Woche sind und in welchen Tätigkeiten. Ein Projektleiter möchte wissen, ob er genug Ressourcen für sein Projekt hat. Und das Unternehmen möchte die Kapazitätsprognose kennen: Wo habe ich noch Lücken für ein neues Angebot, lohnt sich eine Bewerbung, oder habe ich Überhänge und muss mich um Freelancer oder Kooperationen bemühen? Diese drei Ebenen müssen verschiedenartig genau sein. Die Unternehmensebene muss nicht wissen, ob in der Vorplanung zwei Stunden an einer Schnittstellenliste gearbeitet wird, sondern nur, ob entwurflich alles in Ordnung ist.

Roman: Drei Stakeholder also: die Geschäftsleitung, die projektübergreifend sehen will, was los ist; die Projektleitung, die die Pakete im Projekt im Griff behalten will; und die Fachplanenden und Systemplanenden, die im Wochenrhythmus Aufgaben ableiten und ihre eigene Kapazität zuordnen wollen.

Lars: Wer eine funktionierende Kapazitäts- und Ressourcenplanung machen möchte, muss genau diese drei Ebenen mit ihren jeweiligen Anforderungen bespielen. Wenn man das gut macht, haben alle Stakeholder ein befriedigendes Ergebnis und können in die Zukunft planen.

Warum ist die Entwurfsphase (LP3) der zentrale Engpass?

Roman: Ein wichtiges Ziel habe ich aus dem agilen Projektmanagement mitgenommen: die Visualisierung von Problemen. Ich will sehen, wo es knallt, und dort rechtzeitig Entscheidungen treffen, damit es nicht knallt. Auf Ebene 1, der Geschäftsleitungsebene, geht es um zwei Ziele: möglichst konstante Auslastung und möglichst konstanter Cashflow, damit man nicht dauernd externe Leute einstellen oder beauftragen muss.

Wir haben an der Bar festgestellt, dass die Leistungsphase 3 ein zentraler Punkt ist, weil dort ein sehr hoher Stundenaufwand steckt — das ganze System planen, auslegen, festlegen, berechnen. Die HOAI gibt das so nicht wieder, sie hat dafür nur rund 9 bis 10 Leistungspunkte. Bei der Projekteingabe müsste man die Realität abbilden und sagen: Das sind nicht 9 Prozent, sondern eher 25 Prozent unserer Leistung ist der Entwurf. Dieses Viertel aller Stunden versuche ich dann über alle Projekte möglichst hintereinander zu setzen, sodass nicht zwei Projekte gleichzeitig im Entwurf sind. Denn die meisten Büros haben pro Gewerk nur ein Team — bei manchen nur eine Person, die zeichnet und auslegt, bei anderen fünf. Sobald die zwei oder drei Entwürfe gleichzeitig machen müssen, drehen sie am Rad.

Lars: Das funktioniert nicht. Die Qualitätsthemen in der TGA resultieren nicht daraus, dass wir nicht wissen, was wir tun sollen, sondern aus diesen Kapazitätsthemen — dass wir etwas parallelisieren, was nicht zu parallelisieren ist. Die spannendste Priorität ist die LP3, weil dort alle wesentlichen Systeme ausgelegt werden. Wenn ich da etwas parallelisiere oder nicht mache, hole ich es im Zweifel nie wieder auf. Selbst durch erhöhten Einsatz in der LP5 ist das Kind dann schon in den Brunnen gefallen, weil wesentliche Dinge zu spät kommuniziert werden.

Roman: Aus eigener Erfahrung als Fachplaner: Den Entwurf finde ich stressig, ich muss mich festlegen und ins Detail planen, und habe das Gefühl, das wird nicht fertig. Dann kommt der Punkt, an dem ich es in die 5 schiebe — und damit haben wir meist schon ein Problem, weil wichtige Festlegungen fehlen. Was ich gut hinbekomme: in einem Projekt den Entwurf machen und parallel für ein anderes Projekt einen Vorentwurf. Ein System zu skizzieren kostet mich ein, zwei Stunden, dann habe ich eine Grundlage und vielleicht eine grobe Kostenschätzung. Aber zwei Entwürfe gleichzeitig machen mich verrückt.

Erstes Ziel für Geschäftsleitung und Projektleitung: die Entwürfe bitte nicht überlagern, die Teams nicht gleichzeitig mehrere Entwürfe machen lassen. Das müsste man mit dicken, fetten Balken visualisieren. Und dann muss ich Entscheidungen treffen. Ich bekomme nicht einfach von außen gesagt, dass wir den Entwurf vier Monate später machen — das ist eine harte Verhandlung. Ich muss sagen: Ich habe ein Projekt, das gerade den Entwurf fertig macht, in zwei Monaten zu Ende, und kann erst dann den nächsten machen.

Lars: Wenige probieren das überhaupt ernsthaft. Dabei ist es ein gutes Argument, wenn ich proaktiv sage: Wir haben uns die Ressourcen angeschaut, das andere Projekt war schon weiter, und du, lieber Auftraggeber, bekommst in zwei Monaten einen tollen Entwurf. Er wird nicht jubeln, aber erkennen, dass wir uns ernsthaft mit Qualität beschäftigen. Das stößt nicht immer auf Ablehnung — es zeigt eine große Professionalität der Bearbeitung im Büro.

Roman: Dann merken auch die anderen Planer, dass sie eigentlich auch Kapazitätsplanung machen müssten. Der Architekt sieht den Entwurf oft nicht so zentral wie wir als TGA-Fachplaner, sondern die Ausführungsplanung. Das ist auch ein HOAI-Widerspruch.

Lars: Durch eine BIM-Methodik wird sich diese Priorisierung verändern. Aber heute gibt es bei wesentlichen Projektbeteiligten eine andere Priorisierung, und wir müssen das Bewusstsein schaffen, dass wir alle die Leistungsphase 3, den Entwurf, als zentrale Phase sehen — dort werden alle Dinge festgelegt. Die LP5, die Ausführungsplanung, soll dann nur noch detaillieren, nicht mehr Dinge in Frage stellen oder erst funktionierend machen. Funktionieren müssen sie schon in der Entwurfsplanung.

Roman: Genau, denn wenn es nur noch um Detaillieren und Rundmachen des Gebäudemodells geht, kann ich einen Fachplanungskoordinator daransetzen — bei BIM heißt das BIM-Fachkoordinator. Diese eine Person trifft sich regelmäßig mit Architekt und Objektplanung, verfeinert das Modell und bekommt Unterstützung vom Projektleiter und Fachplaner. Es ist dann nicht mehr dieses Stundengebirge.

Wir müssen also versuchen, den Entwurf auf der Geschäftsebene möglichst zu entzerren. Wenn drei Projekte gleichzeitig in den Entwurf gehen, können sich Geschäftsführung und Projektleitung gemeinsam zum Kunden bewegen und sagen: Wir möchten einen sehr guten Entwurf machen, und dafür haben wir Bedingungen. Dafür brauchen wir eine Visualisierung, die alle Projekte und alle Entwürfe zeigt.

Lars: Wenn man in heutige Systeme schaut — jedes Büro hat etwas andere Systeme zur Ressourcendarstellung — vermissen wir beide diese dynamische Verkettung zwischen den Projekten, damit man Abhängigkeiten sieht: Wenn sich Projekt A verschiebt, was passiert mit B, C und D? Da wäre bei Softwarelösungen noch Luft nach oben.

Wie hilft Taktplanung auf der Projektebene (Ebene 2)?

Roman: Die Verkettung kann eine gewisse Grenze haben. In den meisten Büros gibt es ein festes Sanitärteam, nicht vier. Dann ist nicht so wichtig, dass im letzten Detailgrad alle Kollegen berücksichtigt sind, sondern erst mal, dass die Entwürfe hintereinander liegen.

Gehen wir auf Ebene 2, die Projektleitung: Sie fragt sich, welche Arbeitspakete jetzt im Projekt zu erledigen sind. Ich klappe den Entwurf auf und möchte Arbeitspakete sehen. Wir haben an der Bar festgestellt: Wir wünschen uns eine Taktplanung. Das ist im Lean Construction der Hotshit — eigentlich uralt. Die meisten Fachplanenden haben festgestellt, dass sie die Gewerke am besten rollierend hintereinander bearbeiten und dann wieder zusammenführen. Ein Gewerk braucht viel Volumen, meist die Lüftung; ein anderes hat viele Restriktionen, etwa Schmutzwasser im Keller oder in der Tiefgarage mit Gefälle — die müssen zuerst dran und ihre Platzbedarfe und Trassen festlegen. Die Elektrogewerke kommen meist als Letztes, sie sind flexibler. Und dann gibt es das dicke Paket Technikzentrale, wo das gesamte Team agil gleichzeitig reinarbeiten muss. Das sind Arbeitspakete, die ich mit Personen verknüpfen und als Projektleiter im Entwurf sehen und besprechen kann.

Lars: Ich muss zugeben, vor ein paar Jahren dachte ich, dass dieses Agile aus der Softwareentwicklung — Sprints, zwei Wochen — überhaupt nichts für die TGA ist. Da muss ich mich korrigieren. Gerade das Runterbrechen auf Taktung und Sprints hilft, die Arbeit für den Projektleiter und jeden Bearbeiter besser zu visualisieren. Wenn nächste Woche jemand krank ist, wäre es ein Traum, in einem agilen Kanban-Board zu wissen, was er gemacht haben muss und ob es überhaupt schlimm ist — oder ob die anderen ungestört arbeiten können. Der wöchentliche Daily Stand und das Wissen, welche kleinen Tätigkeiten diese Woche zu machen sind, machen Ergebnis und Kapazitätsplanung deutlich besser, und der Projektleiter spürt den Fortschritt und kann ihn nach außen kommunizieren.

Roman: Das Grundprinzip agil ist: Wir fixieren den Rhythmus, wir haben einen Takt, nach dem alle arbeiten. In diesem Takt schauen wir, welche Arbeitspakete wann zu erledigen sind. Und der Takt ist zugleich ein Wasserfall: Erst fängt der Lüftungsplaner an, dann der Schmutzwasserplaner, am Schluss kommt Elektro und schaut, wo es sich noch reinquetschen kann. Am Ende kommt eine Integrationsplanung, in der ein Fachplanungskoordinator aushandelt, wo was hinkommt. Dann kommt wieder das Agile: die Technikzentralen, die gemeinsam bearbeitet werden müssen — dort bringen sich alle in kurzen, festen Rhythmen gleichzeitig ein, mit besonderen Rollen, die dafür nötig sind.

Lars: Ich höre heraus, dass du dir wünschst, dass die Ressourcen- und Kapazitätsplanungssoftware so weit runterzubrechen ist, dass man sogar die Aktivitäten für diese Sprints ableiten kann.

Roman: Du gehst schon zur dritten Ebene, ich versuche uns bei der zweiten zu halten. Wenn ich den Entwurf aufklappe, sehe ich die Taktplanung — welche Gewerke wann was machen, wann integriert wird, wann die Technikzentralen gemeinsam kommen. Und jetzt wünsche ich mir: Wenn jemand ausfällt oder ich ein Problem sehe, wird das sofort visualisiert. Ein Blitz erscheint, und ich sehe, wir haben drei Monate, aber die Taktplanung sagt vier. Das müsste wiederum auf Ebene 1 sichtbar sein, sodass Geschäftsleitung und Projektleitung diskutieren müssen: Wollen wir den Takt ändern, müssen wir mit dem Projektteam entscheiden, welche Takte wir herausnehmen oder parallel bearbeiten.

Lars: Die Komplexität steigt, weil wir technischen Planer nicht allein sind, sondern in Interaktion mit den anderen Fachbeteiligten. Wenn wir aus dem Takt geraten und ein Ausrufezeichen kommt, muss gesagt sein: Lieber Projektbeteiligter, du kannst etwas nicht bekommen, weil wir aus dem Takt sind. Das ist eine wichtige Information auf Ebene 2.

Roman: Jetzt klappen wir den Entwurf zu und gehen auf den Vorentwurf — da sind wir wesentlich abhängiger von extern. Hier wäre interessant, externe Vorleistungen zu sehen und wann sie gekommen sind oder fehlen: Da fehlt noch etwas vom Energieberater, vom Tragwerksplaner, das Brandschutzkonzept, und ich weiß noch nicht, welche Technik ich einplanen soll. Wenn das visualisiert würde, wäre das eine großartige Hilfe. Die LP2 hat vielleicht eine andere Visualisierung als die LP3.

Lars: Absolut, weil auch die Anzahl der Kapazitäten eine andere ist. In der LP2 kann man mit wenigen schon die Vorplanung machen, interagiert aber viel mehr mit externen. In der LP3 muss man sich intern sehr gut organisieren, in kleine Pakete unterteilen und die Abhängigkeiten kennen — wenn ein Paket wegen Krankheit verändert wird, was passiert dann?

Was wünschen sich die Fachplanenden auf Ebene 3?

Roman: Ich will nicht, dass die Software mir das Problem löst — das kann sie nicht. Sie kann mir nur zeigen, dass es ein Problem gibt. Und ehrlich gesagt, so wie wir es beschreiben, habe ich das noch nie gesehen. Wir schicken diesen Podcast allen Herstellern von ERP-Systemen und Kapazitätsplanungs-Software. Jetzt kommen wir auf die dritte Ebene, die Ebene der Kolleginnen, die im Wochenrhythmus in diesem Takt arbeiten. Was wünschen wir uns da?

Lars: Der Best Case ist, dass für die Pakete — nehmen wir wieder das Paket Sanitär — klar und übersichtlich ist, welche Teilpakete abzuarbeiten sind. Das hat nicht nur den Vorteil, dass Bearbeiter und Projektplanungsebene den Fortschritt sehen, sondern auch eine Qualität: Von zehn Aufgaben ist vielleicht eine, bei der ich sage, ach ja, die muss ich auch noch machen — die hätte ich sonst übersehen. Wenn visuell dargestellt ist, dass zu einer Vorplanung im Gewerk zehn Teilschritte gehören, ist das sehr gut.

Roman: Was ich bei einem unserer Barmitglieder gesehen habe, der TMM Group, die OpenProject benutzen: Sie haben die Aufgaben in der Datenbank, und zu jeder standardisierten Aufgabe sind viele Informationen hinterlegt — wo kommt die Aufgabe her, wo steht sie in der HOAI, welche Dokumente sind nach VDI 6026 zu berücksichtigen, welcher Kollege hat sie zuletzt bearbeitet, welche Vorlagen und Musterschemata gibt es. Aus einer Aufgabe wird ein Datenbankeintrag mit wahnsinnig vielen Informationen. Diese Aufgabe kann ich mir dann in mein persönliches Kanban ziehen und habe so viele Informationen, dass ich es eigentlich nur richtig machen kann.

Lars: Wenn man ehrlich ist, merkt man: Kapazitätsplanung hat sehr viel mit terminlichen Abhängigkeiten zu tun. Die heutige Softwarewelt ist eher aus dem Controlling-Bereich kommend etwas statisch unterwegs. Man muss mehr in andere Branchen reingucken, was es dort an Angeboten gibt, und das so ertüchtigen, dass man eine Kapazitätsplanung machen kann.

Roman: Viele haben schon Software für Controlling und ERP ausgewählt. Wir wissen alle: Es ist teuer, es dauert lange, es bedeutet viel Arbeit an den eigenen Prozessen und mit den Kollegen.

Lars: Und wahnsinnig viel Kompromisse.

Roman: Und am Ende die Begrifflichkeiten — wir wollten den Begriff Ressourcen heraushaben, wir verstehen uns nicht als Ressourcen, sondern als Kapazitäten. Du bekommst viele Versprechungen, weißt aber, dass mindestens die Hälfte deiner Wünsche nicht erfüllt wird. Du gibst trotzdem viel Geld aus, hast Schulungsaufwand und Stress, weil die Kollegen keine Lust haben, es zu nutzen. Diese Realität können wir hier nicht lösen.

Welche Appelle gibt die tgabar an die Softwarehersteller?

Lars: Gelöst bekommen wir es nicht so schnell, aber man kann Anstöße geben und Wünsche äußern. Auch wenn nicht Weihnachten ist, ist es legitim, mal über die ideale Kapazitätenplanung nachzudenken.

Roman: Was wäre ideal? Die Verknüpfung der drei Ebenen ist eine sehr interessante Sache. Zusätzlich könnte eine halbwegs automatische Rückbetrachtung erfolgen: Die Aufgaben sind auf Ebene 3 sehr genau definiert, auf Ebene 2 zur Taktplanung aggregiert, auf Ebene 1 auf Projektebene sichtbar. Wenn ich die Zeiterfassung auf diese Aufgaben habe, kann ich hinterher auf allen drei Ebenen zurückblicken und erkennen: In diesem Projekt haben in Leistungsphase 3 die Leistungspunkte nicht ausgereicht, davon allein ein erheblicher Teil für die Darstellung des Entwurfs. Das nutze ich bewusst für die nächste Angebotserstellung.

Lars: Das ist sehr aufwendig. Die Datenbestände sind da, aber wir haben Potenzial, viel datenbasierter nach vorne zu schauen — unter anderem mit Kapazitätsdaten, die ja vorliegen. Man könnte genauere Abschätzungen vornehmen, es wird aber wenig gemacht, weil die Daten nicht smart genug vorliegen, dass man genau sagen kann, wie viel man für die nächste Heizungsplanung braucht.

Roman: Ein Appell an die Softwarehersteller: Kümmert euch bitte mehr um die Visualisierung und die Vernetzung dieser drei Informationsebenen. Diese Datenwüsten helfen uns nicht weiter. Es muss beweglich sein, und ich muss Entscheidungen treffen können. Ich benutze diese Software, weil ich gute Entscheidungen frühzeitig gemeinsam treffen möchte.

Lars: Diesen Appell verknüpfen wir damit, dass wir uns gern beratend zur Verfügung stellen. Ich bin hoch interessiert an so einem Dialog, damit wir alle bessere Produkte bekommen.

Roman: Am 23.09. an der TGA-Bar, der Happy Hour, reißen wir das Thema an und fragen, wer Interesse hat, sich als TGA-Fachplanungsbüro beratend für die Softwarehersteller zur Verfügung zu stellen. Lars, vielen Dank, das war wieder toll mit dir an der Bar.

Lars: Vielen Dank, wir sehen uns bald wieder.