[{"content":"Die Elektrokonstruktion ist seit Wochen überzeichnet. Das weiß jeder im Haus — was niemand sagen kann, ist, woran es liegt: an dem einen großen Auftrag, an der Summe aller Projekte, oder am Tagesgeschäft, das nebenher weiterläuft. Solange diese Frage offen ist, endet jede Besprechung bei „wir brauchen mehr Leute\u0026quot;, und jede Vorlage an die Geschäftsführung enthält eine Behauptung statt eines Nachweises.\nGenau daran ist dieses Paket gebaut. 11 Elektrokonstrukteure werden gebraucht, 7 sind da — an 30 Tagen. Daneben steht, woher der Bedarf kommt: Die Grundlast „Service und Kleinaufträge\u0026quot; bindet 19 der 60 Personen, bevor das erste Projekt beginnt. Und über allem liegt das ausführlichste Netz des Bestandes — 42 Vorgänge, sieben Meilensteine, 71 Verknüpfungen ohne ein einziges loses Ende.\nWas der Plan leistet — und was nicht # Er zerlegt den Bedarf. Projektbedarf und Grundlast stehen getrennt, statt sich zu einer Zahl zu addieren, die niemand aufschlüsseln kann. Damit ist benennbar, welcher Teil der Spitze überhaupt verhandelbar ist — ein Kleinauftrag lässt sich verschieben, eine Montagephase mit Werksabnahme nicht. Das lückenlose Netz gibt die zweite Auskunft dazu: welche 19 der 42 Vorgänge den Endtermin halten und welche 23 Luft haben.\nEr beschafft keine Konstrukteure. Die vier fehlenden bleiben vier. Umterminieren verschiebt den Überzug an eine andere Stelle im Kalender, es beseitigt ihn nicht — und ob am Ende verschoben, eingekauft oder eine Zusage zurückgenommen wird, entscheidet die Projektleitung. Der Unterschied ist, dass sie diese Entscheidung an einer Rolle, einem Zeitraum und einer Zahl trifft statt an einem Eindruck.\nDas Paket dahinter # Von der Auftragsklärung über parallele Mechanik-, Elektrik- und Automatisierungsentwicklung bis zu Werksabnahme und Inbetriebnahme beim Kunden — das ausführlichste Beispielprojekt des Bestandes.\nKennzahl Wert Beispielprojekte 5 Ressourcenpool 60 Personen in 7 Teams Leitprojekt Montagelinie MX-200 (13.10.2026 – 14.04.2027) Umfang des Leitprojekts 42 Vorgänge, 7 Meilensteine, 71 Verknüpfungen Grundlast Service und Kleinaufträge bindet 19 Personen Engpass Elektrokonstrukteur/in: 11 gegen 7 an 30 Tagen Die Elektrokonstruktion liegt an 30 Tagen über ihrer Kapazität (11 gegen 7); in der Montagephase treffen Montagebedarf und Grundlast zusätzlich auf Industriemechanik und Mechatronik.\nGeplant sind alle Beispiele dieser Branche mit Rillsoft Project; die Produktseite zur Kapazitätsplanung in der Rillsoft Cloud zeigt die Funktion außerhalb des Beispiels.\nEin Leseweg durch die sechs Seiten # Die Seiten bauen aufeinander auf wie die Planung selbst. Am Anfang steht das Gerüst: Der Projektstrukturplan zeigt, wie 77 Elemente so gegliedert werden, dass man den Stand später ablesen kann — und der kritische Weg, was das lückenlose Netz dafür zurückgibt: die Auskunft, welche 19 der 42 Vorgänge den Endtermin halten.\nDann die Vorentscheidung, die vor jeder Umplanung fällt: Die Vorgangsart legt fest, ob bei der nächsten Änderung die Arbeit stehen bleibt oder die Kalenderspanne — im Leitprojekt MX-200 tragen alle 49 Vorgangszeilen festen Aufwand. Was passiert, wenn die Kapazität dann wirklich nicht reicht, benennt Unterdeckung sichtbar machen — eine Rolle, drei Tage, Bedarf 4 gegen 2 — und die gemeinsamen Montagefelder, an denen ein falsch modelliertes Betriebsmittel einen Engpass erfindet, den es nicht gibt. Am Ende steht das Gedächtnis des Projekts: Soll-Ist am Leitprojekt zeigt, woran man einen Nachtrag Monate später noch von einer Verschiebung unterscheidet.\n","date":"8. September 2026","externalUrl":null,"permalink":"/maschinenbau/","section":"Maschinen- und Anlagenbau","summary":"","title":"Maschinen- und Anlagenbau","type":"maschinenbau"},{"content":"Wer ein Planungswerkzeug beurteilt, will zuerst wissen, was es überhaupt abdeckt — und zwar bevor er sich durch neun Branchen liest. Diese Seite ist die Antwort darauf: neunzehn Funktionen, jede mit einem Satz dazu, was sie leistet, und jede mit mindestens einem Beispielprojekt, an dem sie zu sehen ist.\nWas hier steht, ist keine Funktionsliste des Produkts. Es ist die Liste dessen, was der Beispielbestand dieser Website belegt — mit Screenshots aus einer laufenden Planung und mit Zahlen, die aus dem gebauten Bestand kommen und nicht aus einer Broschüre. Der Unterschied ist wichtig: Eine Funktion steht hier erst, wenn sie an einem konkreten Projekt vorgeführt wird.\nDie Übersicht entsteht aus derselben Datei, aus der die Bildkataloge und die Prüfläufe dieser Website gespeist werden. Sie kann deshalb nicht veralten, ohne dass es auffällt.\nWie derselbe Funktionsumfang außerhalb der Beispiele aussieht, steht auf der Produktseite zum Projektmanagement in der Rillsoft Cloud.\n","date":"7. September 2026","externalUrl":null,"permalink":"/funktionen/","section":"Projektplan-Beispiele – Projektplanung an Branchenbeispielen","summary":"","title":"Was diese Beispiele zeigen","type":"page"},{"content":"Ein Balkenplan färbt Vorgänge rot, und man weiß: Da darf nichts passieren. Was man damit noch nicht weiß, ist die Gegenfrage — wie viel darf denn anderswo passieren? Die Farbe kennt darauf keine Antwort; sie ist ein Ja oder Nein. Die Antwort steht in einer Spalte, und sie ist eine Zahl.\nBeides zeigt sich am selben Plan, und dafür reichen vier Vorgänge. Es geht um eine Rechenweise, nicht um ein Branchenthema: An zweiundvierzig Vorgängen sieht man dieselbe Sache, aber man findet die Stelle nicht mehr.\nDas eigens für die Aufnahme gebaute Kleinprojekt verbindet „Konzept erstellen“ über zwei parallele Zweige mit „Freigabe erteilen“. Einer dauert fünf Tage, der andere zwei. Der Vergleich zeigt nur die Terminlogik eines früh terminierten Netzes; Ressourcen, Fortschritt und reale Störungen bleiben bewusst außen vor.\nDer kritische Weg ist eine Antwort auf „welche\u0026quot; # Bild 1 von 2 — Vier Vorgänge, zwei Wege durch den Plan: Über „Entwurf prüfen\u0026quot; dauert es fünf Tage, über „Unterlagen zusammenstellen\u0026quot; nur zwei. Der längere Weg bestimmt den Endtermin, und genau ihn färbt Rillsoft Project rot. Der blaue Vorgang ist nicht unwichtig — er ist nur nicht knapp.\nDie Spalte Vorgänger macht das Netz nachlesbar, statt es zu behaupten. In Zeile 3 steht „2, 4\u0026quot;: Die Freigabe wartet auf beide Zweige. Beide beginnen bei „Konzept erstellen\u0026quot;, beide enden bei der Freigabe — nur dauert der eine fünf Tage und der andere zwei. Diese Differenz ist der ganze Unterschied zwischen Rot und Blau.\nDer kritische Weg beantwortet damit genau eine Frage: welche Vorgänge den Endtermin halten. Verschiebt sich einer von ihnen um einen Tag, verschiebt sich der Endtermin um einen Tag. Das ist eine harte Aussage — und eine unvollständige, denn sie sagt nichts über den blauen Balken.\nDie Reserve ist eine Antwort auf „wie viel\u0026quot; # Bild 2 von 2 — Dieselbe Ansicht, zwei Spalten mehr — und aus der Farbe wird eine Zahl. Die Anfangsreserve ist durchgehend 0, weil früh wie möglich terminiert wird. Die Aussage trägt die Endreserve: Sie steht bei den drei roten Vorgängen auf 0 und nennt allein beim blauen einen Wert — drei Tage.\nZwischen den beiden Bildern hat sich am Plan nichts geändert. Dieselben Termine, dieselben Balken, dieselbe Färbung; getauscht wurden nur die eingeblendeten Spalten. Was vorher eine Farbe war, ist jetzt eine Zahl: „Unterlagen zusammenstellen\u0026quot; endet am 13. Oktober und dürfte bis zum 16. Oktober laufen, ohne dass die Freigabe später käme.\nDie beiden Spalten meinen dabei Verschiedenes:\nDie Anfangsreserve sagt, wie weit ein Vorgang nach vorn könnte. Sie steht hier überall auf 0 — nicht weil kein Puffer da wäre, sondern weil früh terminiert wird: Jeder Vorgang liegt bereits an seinem frühestmöglichen Anfang und kann nicht weiter nach vorn. Die Endreserve sagt, wie weit er nach hinten darf, ohne einen Nachfolger anzustoßen. Das ist die Zahl, an der man plant. Wer die Aussage nachrechnen will: Die 3 ist keine Eigenschaft des Vorgangs, sondern seines Zweigs. „Unterlagen zusammenstellen\u0026quot; braucht zwei Tage, hat aber bis zum Beginn der Freigabe fünf Tage Platz — weil der Nachbarzweig länger dauert. Der Puffer ist die Differenz zwischen den beiden Wegen, nicht etwas, das dem Vorgang gehört.\nWas das für die Planung heißt # Rot und Null bedeuten dasselbe, aus zwei Richtungen gelesen: Ein Vorgang mit Endreserve 0 ist kritisch, ein kritischer Vorgang hat Endreserve 0. Die Farbe findet die Stelle schneller, die Zahl sagt, was man dort tun darf.\nPraktisch heißt das dreierlei:\nVerschieben fängt beim blauen Balken an. Wer Platz braucht, sucht ihn dort, wo eine Zahl größer null steht — nicht auf dem roten Weg. Puffer ist verbrauchbar. Schiebt man den blauen Vorgang um drei Tage, steht danach dort auch 0, und aus vier kritischen Vorgängen wird ein Plan ohne jede Luft. Anfangsreserve 0 ist kein Alarm. In einem früh terminierten Plan ist sie der Normalfall und sagt nur, dass nichts unnötig spät liegt. Wie das an einem echten Bestand aussieht — neunzehn von zweiundvierzig Vorgängen rot, in einem Netz aus einundsiebzig Verknüpfungen — zeigt der kritische Weg am Beispiel Maschinenbau.\nWas Rillsoft Project sonst noch aus dem Netz rechnet, steht auf der Produktseite zum Projektmanagement in der Rillsoft Cloud.\n","date":"6. September 2026","externalUrl":null,"permalink":"/grundlagen/reservezeit-und-kritischer-pfad/","section":"Grundlagen der Ressourcenplanung","summary":"","title":"Reservezeit und kritischer Pfad","type":"grundlagen"},{"content":"Die meisten Bauunternehmen planen ihre Projekte und wundern sich, warum die Kolonnen trotzdem nie reichen. Der Grund steht selten im Plan: das Tagesgeschäft. Laufende Baustellen, Kleinaufträge, Gewährleistung — Arbeit ohne Projektnummer, die jeden Tag dieselben Leute bindet.\nDas Beispiel ist ein Bauunternehmen mit 120 Personen in sieben Kolonnen. Neben vier Projekten läuft ein fünftes Vorhaben, das keines ist: „Laufende Baustellen\u0026quot; — Mauer-, Beton- und Putzarbeiten als Daueraufträge.\nDie Grundlast allein # Bild 1 von 2 — Das Tagesgeschäft eines Bauunternehmens ist kein Projekt mit Anfang und Ende, sondern eine Grundlast: Daueraufträge, die jeden Tag Kolonnen binden — 912 Personentage in einem Vierteljahr. Aufgeklappt steht darunter, woraus sie besteht, und darunter die Maurer mit ihren Urlaubstagen. Die Spalte Unterdeckung bleibt leer, und genau das ist die Aussage: Der Normalbetrieb geht auf. Aber er bindet 16 der rund 29 Maurer an jedem Arbeitstag — und was übrig bleibt, ist der ganze Raum, in den jedes Projekt hineinmuss.\n16 Maurer gebunden, +13 frei. Das ist keine Spitze, sondern der Normalzustand: An jedem Arbeitstag des Quartals steht dieselbe Zahl. Nichts davon fehlt — aber mehr als die Hälfte der Kolonne ist vergeben, bevor auch nur ein Projekt begonnen hat.\nUnd mit allen Projekten # Bild 2 von 2 — Dieselbe Qualifikation, derselbe Zeitraum — jetzt mit allen fünf Vorhaben des Unternehmens. Dazugekommen sind zwei Vorgänge der Schwimmhallen-Modernisierung, zusammen 54 Personentage. Das ist die eigentliche Nachricht des Bildpaars: Die Projekte machen den kleineren Teil aus, die Grundlast den größeren. Wer nur Projekte plant, plant an neun Zehnteln der Arbeit vorbei.\nnur Grundlast alle fünf Vorhaben Aufwand Maurer 912 PT 966 PT gebunden je Tag 16 19 freie Reserve je Tag +13 +10 Anteil der Projekte — 54 PT, knapp 6 % Die unbequeme Zahl # Die Projekte, über die in den Besprechungen geredet wird, machen knapp sechs Prozent des Maurerbedarfs aus. Der Rest ist Tagesgeschäft. Wer eine Auftragsannahme gegen die freie Kapazität rechnet, ohne die Grundlast im Bestand zu führen, rechnet gegen 29 Maurer statt gegen die 13, die wirklich übrig sind — und wundert sich später, warum die Kolonne fehlt.\nDie Konsequenz ist nicht mehr Planungsaufwand, sondern eine einmalige Ehrlichkeit: Das Tagesgeschäft gehört als Vorhaben in den Bestand, mit realistischem Umfang. Danach rechnet der Kapazitätsabgleich, was tatsächlich übrig ist.\nWie derselbe Gedanke in einer Fertigung aussieht, steht auf Grundlast und Restkapazität. Wie Rillsoft Project Kapazitäten rechnet, steht auf der Produktseite zur Kapazitätsplanung in der Rillsoft Cloud. Zurück zur Übersicht Bauwesen.\n","date":"25. August 2026","externalUrl":null,"permalink":"/bauwesen/laufende-baustellen/","section":"Bauwesen / Modernisierung","summary":"","title":"Laufende Baustellen als Grundlast","type":"bauwesen"},{"content":"Die unangenehmste Sorte Terminkonflikt gehört keinem Projekt. Sie entsteht zwischen ihnen — dann, wenn zwei Vorhaben unabhängig voneinander dieselbe Woche derselben Qualifikation verplanen. Ein Einzelplan kann das nicht sehen.\nDas Beispiel ist ein mittelständisches Werk mit fünf gleichzeitigen Vorhaben auf einem Stamm von 120 Personen in sieben Teams: eine Produktvariante, eine Kundenanlage, eine ERP-Lagerintegration, ein Standortumbau und das laufende Tagesgeschäft.\nFünf Projekte, eine Achse # Bild 1 von 3 — Ein Portfolio ist keine Zusammenfassung, sondern eine gemeinsame Rechnung: Fünf Vorhaben, die sonst jedes für sich geplant würden, liegen hier auf einer Achse und greifen auf denselben Stamm von 120 Personen zu. Erst dadurch kann die Software überhaupt bemerken, dass zwei Projekte dieselbe Woche derselben Qualifikation verplanen.\nDas Einzelprojekt: unauffällig # Bild 2 von 3 — So sieht ein Projekt aus, das für sich genommen machbar ist. Die Kundenanlage bindet die Montage mit zwei Vorgängen und 81 Personentagen; in den Tageszellen steht daneben das Übrige als Plus — +10 bis +13. Die Spalte Unterdeckung bleibt leer, und im Diagramm unten liegen die blauen Bedarfsbalken unter der grünen Kapazitätslinie. Wer nur dieses Projekt plant, hat keinen Grund zur Sorge — und übersieht genau deshalb den Konflikt.\nDieselbe Zeit im Portfolio # Bild 3 von 3 — Dieselben zwei Monate, dieselbe Qualifikation — nur eben über alle fünf Projekte gerechnet. Aus zwei Vorgängen sind fünf geworden, aus 81 Personentagen 526, und jetzt steht in der Spalte Unterdeckung eine Zahl: −45, das sind 9 % des Bedarfs. In den rosa Tageszellen ist zu sehen, woraus sie entsteht — am 5. November 12 gegen −1, Anfang Dezember 15 gegen −3. Das Diagramm darunter zeichnet dasselbe: blau der Bedarf, grün die Arbeitskapazität, orange die Lücke. Kein Projekt hat den Fehler gemacht; sie haben ihn gemeinsam.\nDieselbe Qualifikation, dasselbe Fenster, dieselbe Kapazität — und jetzt eine Zahl, die niemand ignorieren kann. Der Unterschied liegt nicht in den Daten, sondern darin, wie weit man schaut.\nKundenanlage allein alle fünf Projekte Vorgänge der Montage 2 5 Aufwand Montage 81 PT 526 PT Bedarf je Tag unter der Kapazität 12 bis 15 Unterdeckung — −45 (9 %) Was daraus folgt # Der Abgleich sagt nicht, was zu tun ist — er sagt, dass etwas zu tun ist, und wie viel. 45 Personentage sind keine Feinjustierung: Entweder verschiebt sich ein Vorhaben, oder es kommen Leute dazu, oder ein Teil wird vergeben. Diese Entscheidung trifft ein Mensch. Aber sie fällt jetzt im November und nicht im Februar, wenn die ersten Termine reißen.\nDeshalb ist das Portfolio kein Berichtswerkzeug, sondern ein Planungswerkzeug: Es rechnet dieselbe Kapazitätsfrage wie ein Einzelprojekt, nur über den gesamten Bestand — und findet damit genau die Konflikte, die im Einzelplan unsichtbar bleiben. Wie man dieselbe Lage aus verschiedenen Blickwinkeln betrachtet, steht auf Kapazitätsansichten steuern. Was ein Portfolio ist und warum die Reihenfolge der Gliederung — Rolle vor Projekt oder Projekt vor Rolle — an derselben Ansicht eine andere Frage beantwortet, steht ohne Branche und an drei kleinen Projekten unter Ressourcenmanagement im Portfolio.\nWie Rillsoft Project Multiprojektplanung rechnet, steht auf der Produktseite zum Multiprojektmanagement in der Rillsoft Cloud. Zurück zur Übersicht Mittelstand.\n","date":"25. August 2026","externalUrl":null,"permalink":"/mittelstand/multiprojekt-kapazitaetsabgleich/","section":"Mittelstand / Multiprojekt","summary":"","title":"Multiprojekt-Kapazitätsabgleich","type":"mittelstand"},{"content":"In einem Softwareprojekt ist die Besetzungsfrage selten am Anfang zu beantworten. Der Sprint braucht drei Backend-Entwickler; wer es sein wird, entscheidet sich Wochen später. Ein Plan, der bis dahin nichts sagen kann, ist in genau der Phase nutzlos, in der man ihn braucht.\nDas Beispiel sind zwei Vorhaben desselben Dienstleisters: die ERP-Einführung mit namentlicher Besetzung und das Kundenportal ohne.\nMit Namen # Bild 1 von 2 — Auch in einem Softwareprojekt gilt die Trennung: Die Spalte Rollen sagt, welche Qualifikation ein Vorgang braucht, die Spalte Personal, wer sie übernimmt. Sprints werden mit drei Backend-Entwicklern geplant, lange bevor feststeht, welche drei es sind.\nOhne Namen # Bild 2 von 2 — Dasselbe Werkzeug, dieselben Spalten, ein anderes Vorhaben — und keine einzige namentliche Besetzung. Das Kundenportal ist vollständig über Qualifikationen geplant, und es rechnet im selben Kapazitätsabgleich mit wie das namentlich besetzte ERP-Projekt. Genau das ist gemeint, wenn es heißt: Der Abgleich zählt die Rolle.\nZwei Pläne, dieselben Spalten, ein Unterschied: Rechts steht einmal ein Name und einmal nichts. Beide sind vollständig — der eine ist feiner geplant, nicht besser.\nWas das für den Abgleich heißt # ERP-Einführung Kundenportal Qualifikation am Vorgang ja ja Person am Vorgang ja nein Zählt im Kapazitätsabgleich ja ja Erscheint im Engpass ja ja Die letzte Zeile ist die wichtigste: Der Abgleich zählt die Qualifikation, nicht die namentlich Besetzten. Beide Projekte tauchen im Backend-Engpass auf — das eine mit 133 Personentagen, das andere mit 20. Für die Kapazitätsrechnung ist es gleichgültig, ob ein Name danebensteht.\nDeshalb gilt: Man verliert nichts, wenn man früh plant, und gewinnt Genauigkeit, sobald man Namen einträgt. Wer dagegen erst mit Namen anfangen darf, plant entweder zu spät oder mit Platzhaltern, die niemand pflegt.\nWie die Namen an den Vorgang kommen, steht auf Kandidatenermittlung; wie derselbe Gedanke in einem Ingenieurbüro aussieht, auf Rolle oder Person.\nWie Rillsoft Project Personaleinsatz plant, steht auf der Produktseite zur Personaleinsatzplanung in der Rillsoft Cloud. Zurück zur Übersicht IT-Dienstleister.\n","date":"25. August 2026","externalUrl":null,"permalink":"/it-dienstleister/personenscharfe-planung/","section":"IT-Dienstleister","summary":"","title":"Personenscharfe Planung im ERP-Projekt","type":"it-dienstleister"},{"content":"Der Kapazitätsabgleich über mehrere Projekte ist im Mittelstand eine Fingerübung: fünf Vorhaben, ein Pool, eine Ansicht. Die Frage ist, ob dasselbe Verfahren trägt, wenn aus fünf Projekten zwölf werden und aus ein paar hundert Vorgängen mehr als viertausend.\nDas Beispiel ist ein Anlagenbauer mit zwölf Kundenprojekten in einem Portfolio — 6.134 Elemente, 4.263 Vorgänge, fünfzehn Qualifikationen.\nEin Projekt # Bild 1 von 3 — Der Maßstabsvergleich beginnt hier: ein Kundenprojekt mit 650 Elementen, eine Zeile je Qualifikation — und die Spalte Unterdeckung bleibt an jeder leer. Für sich genommen ist die Prozessanlage machbar; im Diagramm bleibt der Bedarf unter der Kapazitätslinie von 8. Das Bild danach zeigt dieselbe Ansicht für zwölf solcher Projekte.\nZwölf Projekte # Bild 2 von 3 — Zwölf Großprojekte auf einem Stamm — und die Rechnung läuft in derselben Ansicht wie bei fünf Projekten eines Mittelständlers: eine Zeile je Qualifikation, Auslastung, Aufwand, Unterdeckung. Was hier zu sehen ist, ist bewusst kein machbarer Plan; der Beispielbestand ist gestaucht, damit er handlich bleibt, und deshalb steht in jeder der fünfzehn Zeilen eine Unterdeckung — von −8,75 bei der Dokumentation bis −325,5 in der Apparatekonstruktion. Die Aussage des Bildes ist die Größenordnung: 4.263 Vorgänge, und die Ansicht rechnet sie in derselben Zeit wie ein Projekt mit dreißig.\nWer den Überzug trägt # Bild 3 von 3 — Eine Ebene tiefer steht, wer den Überzug verursacht — und die Antwort ist dieselbe wie in jedem Portfolio: nicht einer allein. Die Montage der Rohrleitungen fordert 636,88 Personentage und meldet −148,88 (23 Prozent); darunter teilen sich sechs Projekte diese Summe. Das größte ist die Prozessanlage PPA-400 mit 135 — gut ein Fünftel —, das kleinste die Stoffaufbereitung Papierfabrik Ostwald mit 62. Wer eines davon streicht, hat den Überzug nicht behoben.\nDas ist der Grund, warum die Frage nicht im Projekt zu beantworten ist. Kein einzelnes Vorhaben ist zu groß; erst ihre Summe übersteigt, was die Rohrleitungsmontage hergibt. Eine Kürzung müsste deshalb über alle sechs verhandelt werden — oder die Kapazität muss steigen.\nRohrleitungsplanung ein Projekt zwölf Projekte Aufwand 139,88 PT 724,38 PT Unterdeckung — −290 (40 %) Zeilen in der Ansicht 15 15 Bedienung dieselbe dieselbe Was gleich bleibt und was nicht # Gleich bleibt das Verfahren. Es gibt keine gesonderte „Großkundenansicht\u0026quot;: Struktur, Spalten und Kennzahlen sind dieselben wie im Beispiel Mittelstand. Wer das eine bedienen kann, kann auch das andere.\nNicht gleich bleibt die Antwortzeit. Ein Portfolio dieser Größe braucht zum Öffnen deutlich länger als ein Einzelprojekt — im Beispiel gut eine halbe Minute. Das ist der ehrliche Preis der Größe, und er fällt einmal an, nicht bei jedem Klick.\nEin Wort zur Ehrlichkeit dieses Beispiels # Der gezeigte Bestand ist kein machbarer Plan. Die Projekte sind gegenüber ihren Vorlagen zeitlich gestaucht, damit das Paket handlich bleibt; deshalb steht im Portfoliobild in jeder Qualifikationszeile eine Unterdeckung. Das Einzelprojekt darüber zeigt, dass das nicht an der Planung liegt: Für sich genommen passt es. Wer wissen will, wie ein Engpass aussieht, den man auflösen kann, sieht ihn im Mittelstandsbeispiel oder beim IT-Dienstleister.\nWie sich dieselben zwölf Projekte im Balkenplan darstellen, steht auf Portfolio im Großkundenmaßstab. Wie Rillsoft Project Sammelprojekte und Portfolios führt, steht auf der Produktseite zum Multiprojektmanagement in der Rillsoft Cloud. Zurück zur Übersicht Anlagenbau.\n","date":"25. August 2026","externalUrl":null,"permalink":"/anlagenbau/portfolio-grossprojekte/","section":"Anlagenbau / Großprojekte","summary":"","title":"Portfolio mit zwölf Großprojekten","type":"anlagenbau"},{"content":"Das Ressourcenangebot ist eine Eigenschaft des Unternehmens, nicht des Projekts. Genau deshalb steht es in Rillsoft Project auch nicht im Projekt, sondern in einem Pool, auf den alle Vorhaben zugreifen — und nur deshalb kann überhaupt jemand ausrechnen, ob vier Projekte gleichzeitig hineinpassen.\nDas Beispielbüro führt 30 Personen in fünf Teams und acht Qualifikationen und plant damit vier Projekte.\nDer Bestand # Bild 1 von 3 — Das ist der Pool, aus dem alle vier Projekte des Büros planen: 30 Personen in fünf Teams, ein einziger Stamm. Unter jeder Person stehen die Vorgänge, die sie bindet — und zwar quer über die Projekte hinweg, denn die Ansicht liest das Portfolio. Das Ressourcenangebot ist eine Eigenschaft des Unternehmens, nicht des Projekts; nur deshalb kann überhaupt jemand ausrechnen, ob vier Vorhaben gleichzeitig hineinpassen.\nDieselben Leute nach Qualifikation # Bild 2 von 3 — Derselbe Pool, andere Ordnung — und eine Zahl, die überrascht: Acht Qualifikationen, 30 Personen, aber 34 Zeilen. Im Bild ist es an „Reed, Heinzpeter\u0026quot; zu sehen, der unter Projektleitung und unter Objektplanung steht: Vier Leute des Büros bringen eine zweite Qualifikation mit. Arbeiten können sie trotzdem nur einmal — genau das ist der Unterschied zwischen Kopfzahl und Kapazität.\n30 Personen, aber 34 Qualifikationszeilen. Vier Leute bringen eine zweite Qualifikation mit — im Bild ist es an „Reed, Heinzpeter\u0026quot; zu sehen, der unter Projektleitung und unter Objektplanung steht. Für die Besetzung ist das ein Gewinn: Er kommt in zwei Kandidatenlisten vor. Für die Kapazität ist es keiner, denn arbeiten kann er nur einmal.\nUnd was davon wirklich zur Verfügung steht # Bild 3 von 3 — Ein Pool ist keine Zahl, sondern ein Kalender. Wer Urlaub hat, steht an diesen Tagen nicht zur Verfügung; die graue Zelle mit dem U nimmt ihn aus dem Angebot. Deshalb rücken namentlich besetzte Vorgänge bei der Terminierung nach hinten — und deshalb ist die verfügbare Kapazität eines Tages fast nie die Kopfzahl des Teams.\nEin Pool ist kein Personalstand, sondern ein Kalender. Urlaub, Feiertage und Arbeitszeitmodelle bestimmen, wie viel von den 30 Personen an einem konkreten Dienstag übrig bleibt. Das ist der Grund, warum namentlich besetzte Vorgänge bei der Terminierung nach hinten rücken — und warum die verfügbare Kapazität eines Tages fast nie die Kopfzahl des Teams ist.\nWas man zählt Wert im Beispielbüro Personen 30 Teams 5 Qualifikationen 8 Qualifikationszeilen 34 Projekte auf diesem Pool 4 Wozu der Aufwand # Ein Pool kostet einmal Pflege und spart danach jede Doppelbuchung. Er ist die Voraussetzung für alles, was projektübergreifend rechnet: für den Kapazitätsabgleich im Portfolio, für die Kandidatenliste am Vorgang und für jede Aussage darüber, ob ein zusätzlicher Auftrag noch hineinpasst.\nWie Rillsoft Project Ressourcen verwaltet, steht auf der Produktseite zur Ressourcenplanung in der Rillsoft Cloud. Zurück zur Übersicht Ingenieurbüro.\n","date":"25. August 2026","externalUrl":null,"permalink":"/ingenieurbuero/ressourcenpool-aufbauen/","section":"Ingenieurbüro / Planung","summary":"","title":"Ressourcenpool im Ingenieurbüro aufbauen","type":"ingenieurbuero"},{"content":"Eine Schule wird saniert, während sie in Betrieb ist. Der Plan hat deshalb Randbedingungen, die kein Planer verhandeln kann: Beschlusstermine des Bauausschusses, Vergabefristen nach VOB — und vor allem die Ferien, in denen gearbeitet werden darf.\nDas Beispiel ist die Sanierung der Grundschule Lindenhof eines städtischen Hochbauamts, 6. Oktober 2026 bis 27. April 2027, 34 Vorgänge in drei Phasen.\nDer Rahmen, der von außen kommt # Bild 1 von 2 — Ein kommunales Vorhaben plant nicht frei. Beschlusstermine, Vergabefristen und vor allem die Schulferien stehen fest, bevor der erste Vorgang gezeichnet ist. Im Plan sind das vier fixierte Meilensteine, und die Arbeiten dazwischen tragen ihr Fenster schon im Namen — „Fenstertausch in den Winterferien überwachen\u0026quot;, „Mängelbeseitigung in den Osterferien nachverfolgen\u0026quot;. Die Phase dazwischen heißt nicht zufällig „Ausführung im Ferienfenster\u0026quot;.\nVier Elemente dieses Plans sind fixiert — alle vier sind Meilensteine:\nZwangstermin Datum Maßnahmenkonzept freigegeben 24.11.2026 Vergabe erteilt 22.01.2027 Ausführung abgeschlossen 09.04.2027 Sanierung abgenommen und Schule übergeben 27.04.2027 Fixiert heißt: Sie bleiben stehen, wenn davor etwas verrutscht. Eine Neuterminierung schiebt sie nicht mit — sie meldet stattdessen den Konflikt. Das ist der Unterschied zwischen einem Termin, den man sich vornimmt, und einem, den man einhalten muss. Was die Fixierung an einem Meilenstein und an einem Teilprojekt jeweils tut — der eine lehnt den Griff ab, das andere hält den Rahmen und zeigt die Überschreitung —, steht für sich unter Teilprojekt und Meilenstein: fixiert oder unfixiert.\nUnd der Rahmen, der aus dem Kalender kommt # Bild 2 von 2 — Feiertage rechnet Rillsoft Project selbst ein. „Malerarbeiten überwachen\u0026quot; hat 10 Tage Dauer und läuft trotzdem vom 22. März bis zum 6. April; „Bodenbeläge erneuern lassen\u0026quot; hat 5 und braucht vom 25. März bis zum 2. April. Dazwischen liegen Wochenenden, die Ostertage und die Abwesenheiten der Beteiligten — im Bild die grauen Zellen mit U. Niemand muss das von Hand nachhalten, und niemand kann es vergessen.\nWarum das mehr ist als Kosmetik # Wer arbeitsfreie Zeiten nicht im Plan führt, rechnet in Kalendertagen und verspricht Termine, die niemand halten kann. Der Unterschied ist im Beispiel mit bloßem Auge zu sehen: Zehn Tage Malerarbeiten belegen sechzehn Kalendertage. Über ein halbes Jahr summiert sich das zu Wochen.\nZusammen ergeben die beiden Mechanismen genau das, was ein kommunaler Plan braucht: Fixierte Elemente halten die Termine, die von außen gesetzt sind, und der Kalender rechnet die Zeit dazwischen richtig. Was übrig bleibt, ist die Frage, ob es reicht — und die beantwortet der Plan, bevor der erste Bagger kommt.\nWie Rillsoft Project Termine und Kalender führt, steht auf der Produktseite zum Projektmanagement in der Rillsoft Cloud. Zurück zur Übersicht Öffentliche Verwaltung.\n","date":"25. August 2026","externalUrl":null,"permalink":"/oeffentliche-verwaltung/zwangstermine-und-ferienfenster/","section":"Öffentliche Verwaltung / Hochbauamt","summary":"","title":"Zwangstermine und Ferienfenster","type":"oeffentliche-verwaltung"},{"content":"Projekte scheitern selten am Projekt. Sie scheitern an dem, was daneben weiterläuft: der Serienfertigung, der Instandhaltung, dem Tagesgeschäft. Diese Arbeit steht in keinem Projektplan und bindet trotzdem Menschen — und wer sie nicht mitplant, rechnet mit einer Kapazität, die es nicht gibt.\nIm Produktionspaket steht dieses Tagesgeschäft als eigenes Grundlastprojekt: „Linienbetrieb und Tagesgeschäft\u0026quot; bindet 76 der 120 Personen je Quartal, davon allein 52 in der Maschinenbedienung. Der Serienanlauf daneben plant mit dem Rest.\nWas der Linienbetrieb bindet # Bild 1 von 2 — Das Tagesgeschäft ist kein Projekt und bindet trotzdem Kapazität. Diese Ansicht zeigt je Qualifikation, wie viel davon im laufenden Linienbetrieb gebunden ist — bevor ein einziges Projekt geplant wurde. Das Diagramm darunter zeichnet ohne markierte Zeile die Summe aller sieben: die Gesamtbindung des Tagesgeschäfts. Wer diese Zeilen nicht kennt, plant mit einer Kapazität, die es nicht gibt.\nDieselbe Bindung in Prozent # Bild 2 von 2 — Dieselbe Bindung, andere Darstellung. In Prozent liest sich die Frage „was bleibt für den Serienanlauf\u0026quot; unmittelbar: Eine Zeile bei 100 Prozent hat nichts mehr abzugeben, eine bei 40 Prozent schon. Die absolute Ansicht darüber sagt, wie viel Arbeit dahintersteht; diese sagt, wie eng es ist.\nEin Hinweis zum Bild # Die Grundlastvorgänge sind bewusst unverknüpft — sie bilden Dauerleistungen ab, keine Kette. Bei der frühestmöglichen Terminierung fallen sie deshalb alle auf den Projektanfang: Die Q4- und die Q1-Vorgänge starten beide am 1. Oktober 2026. Im gebauten Beispielbestand liegen damit beide Quartale übereinander, also 152 statt 76 Personen gleichzeitig gebunden, und in der Maschinenbedienung 104 statt 52.\nDas ist kein Fehler der Rechnung, sondern die Folge einer bewussten Modellierung — und es zeigt nebenbei, was passiert, wenn Dauerleistungen ohne Kalenderanker in einen Terminplan geraten. Wer die Zahlen je Quartal sehen will, legt den Zeitfilter auf ein Quartal.\nWas das für die Planung heißt # Grundlast gehört in dieselbe Rechnung wie das Projekt, nicht in eine Fußnote. Erst dann beantwortet der Plan die Frage, die vor jedem Anlauf steht: Wie viel Kapazität ist überhaupt noch frei — und in welcher Qualifikation?\nWelche Qualifikation daran zuerst zerbricht, zeigt Engpass je Qualifikation. Wie Rillsoft Project Kapazitäten über Projekte hinweg rechnet, steht auf der Produktseite zur Kapazitätsplanung in der Rillsoft Cloud. Zurück zur Übersicht Produktion.\n","date":"24. August 2026","externalUrl":null,"permalink":"/produktion/grundlast-und-restkapazitaet/","section":"Produktion / Fertigung","summary":"","title":"Grundlast und Restkapazität","type":"produktion"},{"content":"Ein Projektstrukturplan ist keine Gliederungsübung. Er entscheidet Monate im Voraus, ob sich ablesen lassen wird, wo ein Projekt steht — und dafür kommt es weniger auf die Zahl der Ebenen an als auf eine unscheinbare Frage: Wie endet eine Phase? Dieses Beispiel zeigt an einem gebauten Maschinenbauprojekt, wie man einen Projektstrukturplan erstellt, der diese Frage beantwortet.\nDas Leitprojekt des Maschinenbau-Pakets, die Montagelinie MX-200, führt 77 Elemente: 42 Vorgänge, 7 Meilensteine und 71 Verknüpfungen, verteilt auf sechs Hauptphasen von der Auftragsklärung bis zur Inbetriebnahme beim Kunden. Gebaute Laufzeit: 13.10.2026 bis 14.04.2027.\nSechs Hauptphasen, vier Ebenen # Bild 1 von 2 — Die Tabelle links trägt den Projektstrukturplan über vier Ebenen: sechs Hauptphasen, darunter Teilprojekte bis zur einzelnen Baugruppe. Am Ende jeder Hauptphase steht ein Meilenstein als letztes direktes Kind — an den Rautensymbolen lässt sich der Phasenübergang ablesen, ohne die Balken zu lesen. 77 Elemente, davon 42 Vorgänge und 7 Meilensteine.\nDie Ebenen entstehen nicht aus Ordnungsliebe, sondern aus der Arbeit: Unter der Hauptphase liegt das Teilprojekt, darunter die Baugruppe, darunter der einzelne Vorgang. Wer nur die oberste Ebene aufklappt, sieht den Projektverlauf; wer tiefer geht, sieht, woraus er besteht.\nWarum der Meilenstein ganz unten steht # Am Ende jeder Hauptphase steht ein Meilenstein — und zwar als letztes direktes Kind der Phase, nicht als Nachbar daneben. Das ist der Unterschied zwischen einem Strukturplan, den man lesen kann, und einer Liste: Die Raute markiert den Phasenübergang genau dort, wo die Phase in der Gliederung endet.\nDazu kommen drei Regeln, nach denen der gesamte Beispielbestand gebaut ist:\ngenau ein Startvorgang ohne Vorgänger, genau ein Endelement ohne Nachfolger, jeder andere Vorgang beidseitig eingebunden. Erst dadurch rechnet Rillsoft Project einen durchgehenden kritischen Weg statt isolierter Balken. Ein Strukturplan ohne diese Netzstruktur sieht auf dem Papier gleich aus und trägt trotzdem keine Terminaussage.\nDerselbe Plan von der Ressourcenseite # Bild 2 von 2 — Dieselbe Planung von der Ressourcenseite: je Zeile eine Person, je Spalte ein Kalendertag, in der Zelle ihr Einsatz; die Summenzeile oben addiert den Tagesbedarf des ganzen Projekts. Aufgeklappt ist die eine Zeile, die etwas zu sagen hat — 121.01 Fuchs, Miroslaw. Vom 2. bis 5. November steht dort farbig hinterlegt eine 2, und die Kindzeilen sagen auch, woher sie kommt: „Hauptstromlauf und Verteilung planen\u0026quot; (9 Tage) und „Softwarearchitektur und Standards festlegen\u0026quot; (4 Tage) laufen in derselben Woche über denselben Mann, während „Kabellisten und Feldverdrahtung planen\u0026quot; (10 Tage) erst im Dezember folgt. Zusammen sind das die 23 Tage der Spalte Aufwand. Wer den Strukturplan als Aufwand lesen will, findet ihn hier — dieselben Vorgänge, andere Achse.\nDer Strukturplan beantwortet die Frage „was gehört wozu\u0026quot;. Die Ressourcensicht beantwortet „wer tut es wann\u0026quot; — dieselben Vorgänge, andere Achse. Zwischen beiden liegt keine zweite Planung, sondern nur ein Ansichtswechsel.\nWas das für die Planung heißt # Wer den Strukturplan sauber baut, bekommt zwei Dinge geschenkt: einen kritischen Weg, der wirklich durchläuft, und Phasenübergänge, die man an sieben Rauten abliest statt an 42 Balkenenden. Beides kostet beim Aufbau ein paar Minuten — und zahlt sie in jeder Statusbesprechung zurück, in der niemand fragen muss, welche Phase eigentlich gerade läuft.\nAlle 49 Vorgangszeilen dieses Plans tragen dabei dieselbe Vorgangsart — festen Aufwand. Was diese Wahl bei der nächsten Änderung bedeutet, steht unter Vorgangsart: Aufwand oder Dauer.\nWie Rillsoft Project Strukturpläne und Termine rechnet, steht auf der Produktseite zum Projektmanagement in der Rillsoft Cloud. Weiter in dieser Branche: Unterdeckung sichtbar machen zeigt, was mit diesem Plan passiert, wenn die Kapazität nicht reicht — oder zurück zur Übersicht Maschinenbau.\n","date":"24. August 2026","externalUrl":null,"permalink":"/maschinenbau/projektstrukturplan-maschinenbau/","section":"Maschinen- und Anlagenbau","summary":"","title":"Projektstrukturplan-Beispiel Maschinenbau","type":"maschinenbau"},{"content":"Auf der Baustelle wird nicht nur die Kolonne knapp. Vier Vorgänge wollen denselben Mobilkran, und die Terminliste behauptet trotzdem, es passe — oder sie behauptet das Gegenteil und meldet eine Unterdeckung, die es gar nicht gibt. Beides ist gleich schlecht: Einmal steht das Gerät am Stichtag woanders, einmal wird ein Termin verschoben, für den es nie einen Grund gab.\nDieses Paket ist das einzige des Bestandes, in dem Menschen, Maschinen und Material gleichzeitig im Plan stehen — zwölf Maschinen in sieben Arten vom Turmkran bis zur Autobetonpumpe, zehn Materialpositionen in vier Gruppen über 199.000 an Wert, dazu 120 Personen in sieben Kolonnen. Und es trägt die unbequemste Zahl der Sammlung: Die Grundlast der laufenden Baustellen bindet 64 der 120 Personen, bevor die Modernisierung der Schwimmhalle auch nur eine Kolonne anfordert.\nWas der Plan leistet — und was nicht # Er unterscheidet nacheinander von gleichzeitig. Solange die gemeinsame Nutzung nicht gesetzt ist, rechnet der Plan vier überlappende Vorgänge am Mobilkran als vier gleichzeitig gebrauchte Geräte: 4 gegen 1 an 63 Tagen. Mit gemeinsamer Nutzung steht dort 1 gegen 1 — dieselbe Baustelle, zwei Ergebnisse. Material läuft im selben Plan als Wert mit, ohne je als Engpass zu erscheinen — die einzige Ressourcenart ohne Angebot: eine Kostenzeile, kein Konflikt.\nEr macht aus einem Kran keine zwei. Welcher der vier Vorgänge zuerst drankommt, bleibt eine Entscheidung des Bauleiters — der Plan sagt nur, dass sie fällig ist, und was sie am Endtermin kostet. Und die Maurerkolonnen liegen weiterhin an 57 Tagen über ihrer Kapazität, 35 gegen 30 — die Folge der 64 gebundenen Personen. Wer sie freibekommen will, muss laufende Baustellen verschieben, nicht den Plan.\nDas Paket dahinter # Modernisierung im Bestand mit Kolonnenplanung, Winterfenster für die Innenarbeiten und rund 93.600 an Materialwert im Rohbau.\nKennzahl Wert Beispielprojekte 5 Ressourcenpool 120 Personen in 7 Teams Leitprojekt Modernisierung Schwimmhalle (01.10.2026 – 27.04.2027) Umfang des Leitprojekts 31 Vorgänge, 6 Meilensteine, 46 Verknüpfungen Grundlast Laufende Baustellen bindet 64 Personen Engpass Maurer/in: 35 gegen 30 an 57 Tagen Die Maurerkolonnen liegen an 57 Tagen über ihrer Kapazität (35 gegen 30), weil die Grundlast der laufenden Baustellen 64 Personen bindet; Turmkran, Mobilkran, Kettenbagger und Autobetonpumpe stehen mit je einem Exemplar im Park.\nGeplant sind alle Beispiele dieser Branche mit Rillsoft Project; die Produktseite zur Ressourcenplanung in der Rillsoft Cloud zeigt die Funktion außerhalb des Beispiels.\nEin Leseweg durch die fünf Seiten # Wer die Branche kennt, beginnt bei der Zahl, die alle anderen erklärt: Laufende Baustellen als Grundlast — 912 Personentage Tagesgeschäft gegen 54 aus Projekten. Erst danach lohnt der Blick auf das Leitprojekt selbst: Die Winterbaustelle zeigt, wie ein geöffnetes Hallendach, ein Ferienstillstand und zwölf fixierte Elemente zusammen einen Plan ergeben, der auch im Januar noch stimmt.\nZwei weitere Seiten gehören den Ressourcen, die keine Menschen sind: die gemeinsame Maschinennutzung am Mobilkran — vier überlappende Vorgänge, ein Gerät, und der Unterschied zwischen „1 gegen 1\u0026quot; und einem erfundenen Engpass von „4 gegen 1\u0026quot; — und Material und Kosten, die einzige Ressourcenart ohne Angebot: kein Engpass, nur Geld.\nDie fünfte gehört wieder den Menschen, und sie beantwortet die Frage, die in jedem Bauprojekt irgendwann kommt: Eine Krankmeldung, zwei Antworten. Am Montag steht der Plan, am Mittwoch fällt der Bauleiter aus — und die Einstellung Termintreue oder Kapazitätstreue entscheidet, ob der Termin stehen bleibt und die Lücke zur Zahl wird oder ob der Plan nachgibt. Sechs Bilder, derselbe Ausfall, zwei Antworten.\n","date":"8. September 2026","externalUrl":null,"permalink":"/bauwesen/","section":"Bauwesen / Modernisierung","summary":"","title":"Bauwesen / Modernisierung","type":"bauwesen"},{"content":"„Wer kann das machen?\u0026quot; ist eine Frage mit drei Bedingungen: die richtige Qualifikation, Zeit im fraglichen Zeitraum, und ein Kostensatz, den das Budget trägt. Alle drei stehen im Ressourcenpool — man muss sie nur an der richtigen Stelle zusammenführen.\nDas Beispiel ist die Besetzung von Sprint 2 des ERP-Projekts: 45 Personentage auf 15 Arbeitstage, also drei Entwickler gleichzeitig.\nVorher: der Sprint ist besetzt # Bild 1 von 4 — Der Anfang der Geschichte, und die Lage, in der ein Projekt sein soll. „Sprint 2 Nebenbücher und Zahlläufe\u0026quot; läuft vom 1. bis 21. Dezember, und in der Spalte Personal stehen drei Namen: Keating, Raimund; McCarthy, Gernhard; VandeGraaff, Clemens. Von hier aus wird gleich einer der drei fehlen.\nDie Lage: eine Stelle ist offen # Bild 2 von 4 — Der Ausgangspunkt jeder Besetzungsfrage: eine offene Stelle. Der Sprint ist mit drei Backend-Entwicklern geplant und hat zwei — die Bilanz links sagt −15, und das sind keine Prozente, sondern Personentage: genau die 15, die der dritte beitragen sollte. Genau in dieser Lage wird die Kandidatenliste gebraucht, und nicht vorher.\nDie Entscheidung: einer aus neun # Bild 3 von 4 — Und so wird die Lücke geschlossen. Der Filter meldet neun Kandidaten der Qualifikation Backend; ausgewählt ist „Donnelly, Gandolf\u0026quot; — womit die Bilanz wieder auf 0 steht und der Aufwand auf 45 Personentagen. Was die Auswahl trägt, steht in den Spalten: „Andich, Radulf\u0026quot; wäre auch qualifiziert, steht aber auf 53 statt 100, weil er in diesen drei Wochen Urlaub hat. Und Donnelly kostet 80 Euro je Stunde, vier mehr als Keating. Die Liste entscheidet nicht — sie legt offen, was die Entscheidung kostet.\nNachher: der Termin steht # Bild 4 von 4 — Dieselbe Ansicht wie am Anfang, dieselben Spalten, dasselbe Fenster — und der Beleg dafür, dass die Geschichte gut ausging. In der Spalte Personal stehen wieder drei Namen; wo eben McCarthy, Gernhard stand, steht jetzt Donnelly, Gandolf. Die Termine sind dieselben: 1. bis 21. Dezember. Der Ausfall hat den Termin nicht gekostet.\nDas ist der ganze Bogen in vier Bildern: Ereignis, Diagnose, Entscheidung, Beleg. Die beiden äußeren zeigen dieselbe Ansicht, damit man sie übereinanderlegen kann; die beiden inneren zeigen den Dialog, in dem entschieden wird.\nWas in der Liste steht — und warum # Spalte Was sie sagt Im Beispiel Bilanz wie viel der Qualifikation fehlt −15 Personentage, danach 0 Bereitschaft was die Person im Zeitraum einbringen kann Andich: 53 statt 100 (Urlaub) Verfügbarkeit was von ihrem Limit noch frei ist 100 bei allen Kandidaten Kostensatz was ihre Stunde kostet 76 bis 80 Euro Die Liste führt nicht alle 30 Personen des Pools auf, sondern die neun mit der Qualifikation Backend. Wer im Zeitraum Urlaub hat, verschwindet nicht — er steht mit einer kleineren Bereitschaft da. Das ist der Unterschied zwischen „nicht verfügbar\u0026quot; und „teilweise verfügbar\u0026quot;, und er entscheidet, ob man jemanden einplant oder nicht.\nWas die Liste nicht tut # Sie entscheidet nicht. Unter neun gleich qualifizierten Entwicklern die Wahl zu treffen — nach Erfahrung, nach Einarbeitung, nach Kosten — bleibt eine Führungsaufgabe. Was die Liste leistet, ist die Vorarbeit: Sie kann niemanden vorschlagen, der die Qualifikation nicht hat, und sie zeigt den Urlaub, bevor er zum Problem wird.\nWie derselbe Dialog aussieht, wenn ein Standort die Auswahl einschränkt, steht auf Bevorzugtes Team am Beispiel Baukonzern.\nWie Rillsoft Project Ressourcen verwaltet, steht auf der Produktseite zur Ressourcenplanung in der Rillsoft Cloud. Zurück zur Übersicht IT-Dienstleister.\n","date":"25. August 2026","externalUrl":null,"permalink":"/it-dienstleister/kandidatenermittlung/","section":"IT-Dienstleister","summary":"","title":"Kandidatenermittlung für den Sprint","type":"it-dienstleister"},{"content":"„Wo ist der Engpass?\u0026quot;, „wer verursacht ihn?\u0026quot; und „was kostet er an Arbeitsvermögen?\u0026quot; sind drei Fragen an dieselben Daten. Man beantwortet sie nicht mit drei Auswertungen, sondern mit drei Reglern an einer Ansicht: Struktur, Ansicht und Kennzahl.\nVorgeführt am Portfolio „Musterwerk 2027\u0026quot; — fünf Projekte, 120 Personen, das Fenster November und Dezember 2026. Ausgangspunkt ist die Engpassfrage aus dem Kapazitätsabgleich: Montage, −45 Personentage.\nRegler 1: eine Ebene tiefer # Bild 1 von 5 — Eine Ebene mehr, und aus der Feststellung wird eine Adresse. Die Struktur „Rolle, dann Projekt\u0026quot; behält den Engpass als Überschrift — die Zeile darüber meldet unverändert −45 — und zeigt darunter, welches Vorhaben wie viel davon bindet: Produktvariante C zehn Personentage und keine Lücke, die Kundenanlage K-450 dagegen 81 Personentage und −15. Das ist dasselbe Projekt, das im Kapazitätsabgleich allein betrachtet KEINE Unterdeckung hatte. Es ist nicht schuld — es ist nur der Ort, an dem der gemeinsame Engpass zuerst weh tut. Das ist die Ansicht für die Frage, die auf den Engpass folgt: Wer gibt nach?\nRegler 2: eine andere Ansicht # Bild 2 von 5 — Dieselbe Zeit, andere Frage — und deshalb auch eine andere Ansicht. Die Kapazitätsansicht fragt, ob das Angebot reicht; die Auslastungsansicht fragt, wer wie ausgelastet ist. Nach Team und Projekt gegliedert steht nicht die Qualifikation im Vordergrund, sondern die Organisationseinheit — die Ebene, auf der jemand tatsächlich entscheidet, wer woran arbeitet. Sichtbar wird dabei noch etwas: Teams sind im Musterwerk nur an der Produktvariante C vergeben, deshalb steht unter jedem Team genau dieses Projekt. Die Spalten wechseln mit — Auslastung und Aufwand statt Unterdeckung, denn die rechnet allein die Kapazitätsansicht.\nRegler 3: eine andere Kennzahl # Bild 3 von 5 — Die dritte Stellschraube ist die Kennzahl. Dieselbe Struktur, dieselbe Zeit, dieselben Daten — aber statt eines Kopfes steht in jeder Personenzeile jetzt 1,4: das Vollzeitäquivalent, das diese Person im Zeitraum einbringt. Auch das Diagramm wechselt die Einheit. Das ist die Zahl, die in Budgetgespräche gehört: Sie sagt nicht „wie viele Leute\u0026quot;, sondern „wie viel Arbeitsvermögen\u0026quot;.\nRegler 4: eine andere Frage # Die drei Regler oben drehen alle an derselben Frage: Reicht das Angebot? Es gibt aber eine zweite, die keine Rollenansicht beantwortet — hat dieser Mensch zu viel auf dem Tisch? Dafür gibt es die Personalansicht, und sie zeigt Dinge, die in der Rollensicht unsichtbar bleiben.\nBild 4 von 5 — Acht Namen, ein Projekt, der Oktober 2026. In sieben Zeilen stehen ordentliche Achterwerte. In der markierten achten steht am 1. Oktober eine 8 — und am 2., 5., 6. und 7. Oktober je eine 16. Die Spalte rechts nennt den Befund beim Namen: Überlastung +32 (167 %). Sechzehn Stunden an einem Tag hat niemand; die Zahl sagt, dass hier zweimal derselbe Mensch verplant ist.\nDer Grund steht nicht im Bild, ist aber schnell erzählt: Diese Person führt zwei Qualifikationen — sie ist als Leitung und als Konstruktion buchbar. Zwei Vorgänge haben sie über die eine und über die andere Rolle angefordert, in derselben Woche. Jede der beiden Buchungen ist für sich korrekt; erst der Mensch dahinter ist doppelt vergeben.\nRegler 5: dieselbe Woche, nach Rollen gefragt # Bild 5 von 5 — Dieselben Tage, dieselben Daten, eine andere Frage — und ein unauffälliges Bild. Neun Rollen, und die Spalte Unterdeckung bleibt in jeder Zeile leer. Die markierte Rolle „Leitung – Abteilungsleiter/in\u0026quot; steht bei 100 Prozent Auslastung. Nach Rollen gefragt ist an dieser Woche nichts zu beanstanden: Jede Qualifikation hat genug Köpfe im Angebot.\nBeide Bilder sind richtig, und sie widersprechen sich nicht. Die Rollenansicht fragt nach der Qualifikation — davon gibt es genug. Die Personalansicht fragt nach dem Menschen — und der kann nur einmal irgendwo sein. Wer nur die eine Ansicht kennt, übersieht die Hälfte der Konflikte.\nDas ist auch die Antwort auf die Frage, mit der viele in ein Kapazitätsgespräch gehen: „Unterdeckung oder Überlastung?\u0026quot; Es sind zwei Größen und zwei Ansichten. Unterdeckung ist eine Aussage über eine Rolle — zu wenige Köpfe für die geforderte Menge. Überlastung ist eine Aussage über eine Person — zu viel für die eine, die es trifft.\nDie drei Regler nebeneinander # Regler Werte Beantwortet Ansicht Rollen, Team, Personal, Material, Maschinen, Kapazität Worüber wird geredet? Struktur z. B. [Rolle], [Rolle, Projekt], [Team, Projekt] Wer trägt bei? Darstellung absolut, relativ, Prozent, Maximum, Durchschnitt, FTE In welcher Einheit? Und quer dazu die Frage aus Bild 4 und 5: Rolle oder Mensch — das ist keine Einstellung an derselben Ansicht, sondern eine andere Ansicht.\nDie zulässigen Kombinationen sind nicht beliebig: Die Kapazitätsansicht kennt neun Strukturen, alle beginnen bei der Rolle oder einer Projekteigenschaft; die Teamansicht kennt ihre eigenen neun. Rillsoft Project lehnt eine unzulässige Kombination ab, statt eine irreführende Auswertung zu zeigen.\nUnd noch ein Unterschied, den man leicht übersieht: Unterdeckung rechnet nur die Kapazitätsansicht. Die Auslastungsansichten zeigen Auslastung und Aufwand — sie beantworten, wie voll jemand ist, nicht, ob das Angebot reicht. Wer die falsche Ansicht wählt, bekommt eine richtige Antwort auf die falsche Frage.\nDass eine Person überlastet sein kann, während ihre Rolle unauffällig bleibt, hat einen Grund, der älter ist als jede Ansicht: Rolle und Person sind zwei Angaben. Was das heißt und warum es zwei Spalten braucht, steht branchenneutral unter Rolle oder Person.\nWas die beiden Prozentdarstellungen genau gegeneinander rechnen — 100 gegen 33 bei derselben Belegung —, ist an zwei Rollen leichter zu sehen als an sieben: Prozentanteil je Rolle.\nWie Rillsoft Project Ressourcen auswertet, steht auf der Produktseite zur Kapazitätsplanung in der Rillsoft Cloud. Zurück zur Übersicht Mittelstand.\n","date":"25. August 2026","externalUrl":null,"permalink":"/mittelstand/kapazitaetsansichten-steuern/","section":"Mittelstand / Multiprojekt","summary":"","title":"Kapazitätsansichten steuern","type":"mittelstand"},{"content":"Die Frage, die bei jeder Einführung kommt: „Und wenn es größer wird?\u0026quot; Sie verdient eine Antwort mit Zahlen, nicht mit Zusicherungen.\nDas Beispielpaket führt zwölf Anlagenbauprojekte in einem Portfolio — zusammen 6.134 Elemente, 4.263 Vorgänge und 72 Meilensteine über fünf Ebenen.\nZwölf Projekte, eine Datei # Bild 1 von 2 — Zwölf Kundenprojekte in einer Datei, zusammen 6.134 Elemente und 4.263 Vorgänge über fünf Ebenen. Die Portfoliosicht behandelt sie wie Teilprojekte eines einzigen Vorhabens — dieselben Werkzeuge, dieselben Ansichten, nur eine andere Größenordnung. Die Projekte starten versetzt; im Bild ergibt das die Treppe von der Prozessanlage im Oktober 2026 bis zur Dampfnetz-Erneuerung, die im Mai 2027 beginnt.\nWo die Vorgänge herkommen # Bild 2 von 2 — Das größte Einzelprojekt des Pakets trägt 650 Elemente und 462 Vorgänge. Die Vorgangszahl entsteht nicht durch Vervielfachen, sondern fachlich: sieben bis neun Anlagenteile, jeder mit eigenem Arbeitspaket in Detail Engineering, Vorfertigung, Montage und Inbetriebnahme.\nDas ist der Punkt, den man an der Zahl allein nicht sieht: Die Vorgangszahl entsteht fachlich und nicht durch Vervielfachen. Eine Prozessanlage besteht aus sieben bis neun Anlagenteilen — Rohstoffannahme, Dosierung, Reaktion, Destillation, Abfüllung und so weiter. Jeder davon bekommt ein eigenes Arbeitspaket in Detail Engineering, Vorfertigung, Montage und Inbetriebnahme. So kommen 650 Elemente in einem einzigen Projekt zusammen, ohne dass eine einzige Zeile künstlich wäre.\nGrößtes Einzelprojekt Portfolio Elemente 650 6.134 Vorgänge 462 4.263 Meilensteine 6 72 Sammelvorgänge 182 1.799 Ebenen 4 5 Anordnungsbeziehungen 637 — Was das für die Bedienung heißt # Nichts. Genau das ist die Aussage: Es sind dieselben Ansichten, dieselben Spalten und dieselbe Gliederung wie in einem Projekt mit dreißig Vorgängen. Ein Portfolio ist keine andere Software, sondern dieselbe mit mehr Zeilen.\nEin Hinweis zur Ehrlichkeit: Dieses Paket ist kein machbarer Plan. Die Projekte sind bewusst gestaucht, und die Qualifikationen liegen im Überzug — das Paket zeigt Größenordnung und Struktur, nicht Auslastung. Wie ein Kapazitätsabgleich über mehrere Projekte aussieht, steht am Beispiel Mittelstand.\nWie Rillsoft Project Multiprojektplanung rechnet, steht auf der Produktseite zum Multiprojektmanagement in der Rillsoft Cloud. Zurück zur Übersicht Anlagenbau.\n","date":"25. August 2026","externalUrl":null,"permalink":"/anlagenbau/portfolio-skalierung/","section":"Anlagenbau / Großprojekte","summary":"","title":"Portfolio im Großkundenmaßstab","type":"anlagenbau"},{"content":"„Planen wir mit Rollen oder mit Namen?\u0026quot; ist eine Frage, die sich in der Praxis nicht entscheiden lässt — weil beides gebraucht wird. Am Anfang steht die Qualifikation, später der Mensch. Ein Planungswerkzeug muss deshalb beides gleichzeitig führen können.\nDas Beispiel ist ein Ingenieurbüro mit 30 Personen in fünf Teams und acht Qualifikationen. Vier Projekte laufen parallel; namentlich besetzt ist nur eines — der Neubau eines Verwaltungsgebäudes über die Leistungsphasen, 35 Vorgänge, davon 29 mit Qualifikation und 45 Personenzuweisungen. Die anderen drei tragen ausschließlich Rollen.\nZwei Spalten, ein Plan # Bild 1 von 2 — Derselbe Plan trägt beides. In der Spalte Rollen steht, welche Qualifikation der Vorgang braucht — in der Spalte Personal, wer sie übernimmt. Die Grobplanung entsteht links, die Feinplanung rechts, und keine der beiden muss auf die andere warten.\nLinks steht, was gebraucht wird: „2 Objektplanung – Architekt/in\u0026quot;. Rechts, wer es macht: „Baldwin, Morgan; Heil, Meinold\u0026quot;. Die Rolle ist die Aussage des Vorgangs, der Name die Entscheidung des Planers — und die kann später fallen, ohne dass der Plan davor unvollständig wäre.\nWie der Name an den Vorgang kommt # Bild 2 von 2 — So kommt der Name an den Vorgang. Der Kopf der Maske nennt die Eckdaten — 30 Personentage Aufwand, 15 Arbeitstage Dauer, feste Größe ist der Aufwand. Links steht die geforderte Qualifikation mit ihrer Bilanz, und die Liste daneben führt nicht den ganzen Pool auf, sondern die sechs Kandidaten, die diese Qualifikation tragen — mit Bereitschaft, Verfügbarkeit und Kostensatz. Zwei davon sind zugeordnet: Heil und Baldwin, je 15 Personentage.\nWas das für den Kapazitätsabgleich heißt # Die wichtigste Eigenschaft dieser Trennung merkt man erst beim Rechnen: Der Auslastungsabgleich zählt weiterhin die Rollen. Der Bedarf entsteht aus der Qualifikation, die der Vorgang anmeldet — ob jemand namentlich zugeordnet ist oder nicht, ändert daran nichts. Deshalb bleibt eine Kapazitätsaussage auch dann gültig, wenn die Hälfte der Vorgänge noch keine Namen trägt.\nGrobplanung Feinplanung Zuweisung Qualifikation Person Wann ab dem ersten Entwurf wenn der Einsatz feststeht Kapazitätsabgleich rechnet rechnet unverändert weiter Im Beispielbüro alle vier Projekte nur der Neubau Praktisch heißt das: Man verliert nichts, wenn man früh plant, und man gewinnt Genauigkeit, sobald man Namen einträgt. Wer dagegen erst mit Namen anfangen darf, plant entweder zu spät oder mit Platzhaltern, die niemand pflegt.\nWarum die Trennung überhaupt zwei Spalten braucht — und was verloren geht, wenn man beides in ein Feld zwängt —, steht branchenneutral unter Rolle oder Person: an drei Vorgängen statt an einem Verwaltungsneubau. Diese Seite hier zeigt, was die Trennung im Ernstfall einbringt.\nWoher die Kandidaten kommen und was ein Pool sonst noch trägt, steht auf Ressourcenpool aufbauen. Wie Rillsoft Project Personaleinsatz plant, steht auf der Produktseite zur Personaleinsatzplanung in der Rillsoft Cloud. Zurück zur Übersicht Ingenieurbüro.\n","date":"25. August 2026","externalUrl":null,"permalink":"/ingenieurbuero/rolle-oder-person/","section":"Ingenieurbüro / Planung","summary":"","title":"Rolle oder Person im Ingenieurbüro","type":"ingenieurbuero"},{"content":"Eine Dachsanierung im Winter ist eine Terminfrage mit Nebenbedingungen: Die Halle muss ab Januar wieder nutzbar sein, das Dach darf nicht offen stehen, wenn es schneit — und zwischen Weihnachten und Neujahr arbeitet niemand.\nDas Beispiel ist die Sanierung eines Sporthallendachs, 1. Oktober 2026 bis 14. Januar 2027, 26 Vorgänge und zwölf fixierte Elemente — vom Planungsbeschluss bis zur Übergabe.\nDer Ablauf, den das Wetter vorgibt # Bild 1 von 2 — Ein geöffnetes Hallendach im November ist kein Terminproblem, sondern ein Wetterproblem. Der Plan bildet das ab: Erst steht das fahrbare Wetterschutzdach, dann wird die alte Dachhaut zurückgebaut — und die Reihenfolge ist keine Empfehlung, sondern eine Verknüpfung.\nDie Reihenfolge ist der eigentliche Inhalt dieses Plans: Erst steht das fahrbare Wetterschutzdach, dann wird die alte Dachhaut zurückgebaut. Im Plan ist das keine Absichtserklärung, sondern eine Verknüpfung — wer den Rückbau vorzieht, bekommt es angezeigt.\nWas der Kalender daraus macht # Bild 2 von 2 — Die Abnahme beginnt am 24. Dezember — und dauert bis Mitte Januar. Nicht, weil jemand langsam arbeitet, sondern weil dazwischen Weihnachten, Neujahr und zwei Wochenenden liegen. Der Kalender rechnet das von selbst; im Bild sind es die grauen Spalten, über die die Balken hinweggehen.\nDie Abnahme beginnt am 24. Dezember und endet am 14. Januar: 14 Arbeitstage über drei Wochen. Dazwischen liegen die Feiertage und drei Wochenenden, und kein Mensch muss sie abziehen — der Kalender tut es.\nVorgang Dauer Zeitraum Abnahme vorbereiten 3 Tage 24. – 29.12. Abnahme mit dem Bauherrn 2 Tage 30. – 31.12. Mängel abarbeiten 6 Tage 04. – 11.01. Schlussrechnung stellen 3 Tage 12. – 14.01. Warum das zusammengehört # Zwangstermine und Kalender sind zwei Seiten derselben Sache: Der eine hält fest, was von außen gesetzt ist, der andere rechnet die Zeit dazwischen richtig. Fehlt eines von beidem, entsteht ein Plan, der auf dem Papier aufgeht und auf der Baustelle nicht.\nWie derselbe Mechanismus eine Schulsanierung an die Ferien bindet, steht auf Zwangstermine und Ferienfenster. Wie Rillsoft Project Termine und Kalender führt, steht auf der Produktseite zum Projektmanagement in der Rillsoft Cloud. Zurück zur Übersicht Bauwesen.\n","date":"25. August 2026","externalUrl":null,"permalink":"/bauwesen/winterbaustelle/","section":"Bauwesen / Modernisierung","summary":"","title":"Winterbaustelle am Beispiel Dachsanierung","type":"bauwesen"},{"content":"„Wir haben zu wenig Leute\u0026quot; ist keine Aussage, mit der sich planen lässt. Die Aussage, die trägt, lautet: diese Qualifikation, an diesen Tagen, um so viel zu knapp. Genau in dieser Auflösung muss ein Engpass auf dem Bildschirm stehen — sonst lässt er sich nicht auflösen.\nIm Produktionspaket ist es die Qualitätssicherung: vier Prüfer für ein ganzes Werk. Im Portfolio aller fünf Vorhaben reichen sie an 38 Tagen zwischen dem 12. Oktober und dem 23. März nicht. Der Linienbetrieb allein bleibt dabei im Rahmen — erst wo die Projekte auf ihn treffen, kippt es.\nDie eine Zeile, die zählt # Bild 1 von 3 — Der Engpass ist nie „das Projekt\u0026quot;, sondern eine Qualifikation an bestimmten Tagen. Aufgeklappt zeigt die Zeile, woraus die Bindung besteht — und das ist die eigentliche Nachricht: Zwei der fünf Vorgänge kommen aus dem Tagesgeschäft (serienbegleitende Prüfungen, 114 Personentage; Reklamationsbearbeitung, 57), drei aus laufenden Projekten. Jeder für sich ist harmlos. Erst zusammen reichen die vier Prüfer an einzelnen Tagen nicht: In den rosa Zellen des 12. und 13. Oktober stehen 3 gegen −1, und die Spalte Unterdeckung fasst das Jahr zu −18 (10 %) zusammen.\nKein Vorhaben hat den Fehler gemacht. Die drei Projektvorgänge binden zusammen zwölf Personentage, die beiden Daueraufträge 171 — jeder Beitrag ist für sich unauffällig. Die Lücke entsteht an den zwei Tagen, an denen zwei der vier Prüfer gleichzeitig im Urlaub sind; die U-Markierungen in den Personenzeilen darunter sind genau das. Deshalb liegt die grüne Kapazitätslinie an diesen Tagen unter dem blauen Bedarf.\nAn welchen Tagen # Bild 2 von 3 — Derselbe Engpass, enger ausgewertet — und die beiden Zahlen laufen auseinander. Das Bild darüber rechnet über das ganze Bindungsfenster und kommt auf −18, das sind 10 % des Bedarfs. Hier zählen nur die vier Wochen vom 23. November bis 24. Dezember: absolut bleiben −15 übrig, aber das sind 21 %. Die Tageszellen daneben zeigen weiterhin den Projektanfang — die Auswertung lässt sich einschränken, der Ausschnitt der Zeitachse folgt ihr in dieser Ansicht nicht.\nDer Engpass ist kein Mittelwertartefakt — im Gegenteil. Wer nur die Jahreszahl liest, hält 10 % für verkraftbar. In den vier Wochen vor Weihnachten fehlt jeder fünfte Prüftag.\nDer dritte Weg: mehr Kapazität # Aus einem Engpass führen drei Wege: verschieben, streichen — oder die Kapazität erhöhen. Die ersten beiden verhandeln über den Plan; der dritte verhandelt über den Kalender.\nBild 3 von 3 — Dasselbe Fenster, dieselbe Zeile, dieselben Spalten wie in Bild 1 — geändert ist nur der Kalender: Der Samstag ist ein Arbeitstag geworden. Man sieht es an den Spalten, die vorher leer waren: Am 10., 17., 24. und 31. Oktober stehen jetzt Werte, und im Diagramm darunter sind aus fünf Balken je Woche sechs geworden. Der Aufwand bleibt bei 183 — es kommt keine Arbeit dazu, nur Zeit, sie zu tun —, und die Unterdeckung fällt von −18 (10 %) auf −14 (8 %). Der 3. Oktober bleibt leer — er ist ein Feiertag.\nZwei Prozentpunkte für einen Samstag — das ist die ehrliche Bilanz, und sie ist kleiner, als man hofft. Der Grund steht im selben Bild: Der Aufwand bleibt bei 183 und verteilt sich nur auf sechs statt fünf Tage je Woche, also sinkt der Tagesbedarf ein wenig. An den Tagen, an denen die Lücke wirklich entsteht — dem 12. und 13. Oktober, als zwei von vier Prüfern im Urlaub waren —, hilft ein zusätzlicher Samstag gar nichts. Sie sind in Bild 3 immer noch rosa. Wer die Lücke wirklich schließen will, braucht mehr als einen sechsten Arbeitstag.\nUnd noch etwas zeigt das Bild: Der Pool des Werks führt einen Kalender. Ihn zu öffnen betrifft alle — vom Maschinenführer bis zur Arbeitsvorbereitung. Eine Zusatzschicht nur für die Engpassqualifikation wäre ein eigener Kalender und ein Umhängen der betroffenen Personen; das ist Stammdatenarbeit, keine Planungsentscheidung.\nWarum die Auflösung entscheidet # Ein Engpass, der als Monatszahl auftritt, lässt sich nur mit Einstellungen oder Verschieben des ganzen Projekts beantworten. Ein Engpass, der als Tagesreihe dasteht, lässt sich verhandeln: Ein Vorgang wandert um drei Tage, ein anderer teilt sich, eine Schicht wird getauscht.\nUnd der Engpass steht selten allein. Dasselbe Bild zeigt drei weitere Zeilen mit einer Lücke: Instandhaltung −27 (6 %), Prozessoptimierung −9 (15 %), Schichtleitung −3 (1 %). Keine davon ist dramatisch, und genau deshalb sind sie gefährlich — wer nur die schlimmste Zeile löst, indem er von den anderen borgt, verschiebt das Problem eine Zeile tiefer.\nWas das für die Planung heißt # Die Zahlen zählen Qualifikationskapazität, nicht Köpfe: Eine Person mit zwei Qualifikationen erscheint in beiden Zeilen und kann trotzdem nur einmal arbeiten. Deshalb ist die Kapazitätsansicht der Anfang der Analyse, nicht ihr Ende — sie zeigt, wo man hinschauen muss.\nWoher die Bindung kommt, zeigt Grundlast und Restkapazität. Dass die Samstagsschicht am Kalender der Person hängt und nicht am Projekt — und dass eine Person mitten im Projekt in eine andere Schicht wechseln darf —, steht unter Schichtkalender.\nWie Rillsoft Project Engpässe sichtbar macht, steht auf der Produktseite zur Kapazitätsplanung in der Rillsoft Cloud. Zurück zur Übersicht Produktion.\n","date":"24. August 2026","externalUrl":null,"permalink":"/produktion/engpass-je-qualifikation/","section":"Produktion / Fertigung","summary":"","title":"Engpass je Qualifikation","type":"produktion"},{"content":"Der kritische Weg sagt, welche Vorgänge den Endtermin halten. Er ist aber keine Eigenschaft einzelner Balken, sondern das Ergebnis des Netzes, in dem sie hängen — und ein Netz mit losen Enden liefert eine Antwort, die nur so lange stimmt, bis sich etwas ändert.\nDie Montagelinie MX-200 führt 71 Verknüpfungen bei genau einem Startvorgang ohne Vorgänger und einem Endelement ohne Nachfolger. Daraus rechnet Rillsoft Project einen durchgehenden Pfad: 19 der 42 Vorgänge liegen darauf.\nEin Netz ohne lose Enden # Das Bild — Rot sind die 19 der 42 Vorgänge, die auf dem kritischen Weg liegen: Jede Verzögerung an ihnen verschiebt den Endtermin. Möglich wird die Rechnung erst durch das lückenlose Netz — 71 Verknüpfungen, genau ein Vorgang ohne Vorgänger und ein Element ohne Nachfolger. Isolierte Balken erzeugen dagegen einen Plan, der auf jede Änderung falsch reagiert.\nDer Unterschied zeigt sich erst bei der ersten Änderung. Hängt ein Vorgang an nichts, verschiebt ihn keine Rechnung mit — er bleibt liegen, wo er ist, und der Plan behauptet einen Termin, den niemand mehr hält. Im geschlossenen Netz wandert die Verzögerung durch die Kette bis zum Endelement, und man sieht sofort, was sie kostet.\nWo noch Luft ist # Die Farbe beantwortet eine Frage — welche Vorgänge den Endtermin halten. Die Gegenfrage beantwortet sie nicht: wie viel Luft die anderen haben. Dafür blendet man in derselben Ansicht die Reservespalten ein, und aus der Markierung wird eine Zahl. Im Elektrik-Zweig dieses Plans steht dort etwas zu holen: „Hauptstromlauf und Verteilung planen\u0026quot; trägt sieben Tage Endreserve, „Sensorik und Aktorik projektieren\u0026quot; acht — während die 19 roten Vorgänge daneben durchgehend 0 tragen.\nDiese sieben, acht Tage sind keine Fußnote, sondern Handlungsspielraum: Genau solche Vorgänge nimmt man, wenn ein Kapazitätskonflikt eine Verschiebung verlangt — sie können ausweichen, ohne dass der Endtermin es merkt. Der kritische Weg sagt, wo man nicht anfassen darf; die Endreserve sagt, wo man darf und wie weit.\nWichtig dabei: Die rote Färbung ist eine Markierung, keine Zahl. Wer wissen will, wie viel Spielraum ein Vorgang wirklich hat, liest die Reservespalte — nicht die Farbe. Was Anfangs- und Endreserve genau meinen und warum die eine in einem früh terminierten Plan überall auf 0 steht, ist an vier Vorgängen leichter zu sehen als an zweiundvierzig: Reservezeit und kritischer Pfad.\nWas das für die Planung heißt # Ein sauberes Netz kostet beim Aufbau Disziplin: jeder Vorgang beidseitig eingebunden, ein Anfang, ein Ende. Dafür beantwortet der Plan danach die einzige Frage, die im Projekt wirklich zählt — wenn dieser Vorgang zwei Tage später fertig wird, verschiebt sich dann der Endtermin oder nicht.\nWie Rillsoft Project Termine und Abhängigkeiten rechnet, steht auf der Produktseite zum Projektmanagement in der Rillsoft Cloud. Davor lohnt der Projektstrukturplan, der das Netz überhaupt erst aufspannt — oder zurück zur Übersicht Maschinenbau.\n","date":"24. August 2026","externalUrl":null,"permalink":"/maschinenbau/kritischer-weg-maschinenbau/","section":"Maschinen- und Anlagenbau","summary":"","title":"Kritischer Weg am Beispiel Maschinenbau","type":"maschinenbau"},{"content":"„Die Linien sind frei.\u0026quot; Der Satz fällt in fast jedem Gespräch über einen Serienanlauf, und er ist selten böswillig — er stimmt nur für das, was im Projektplan steht. Im Werk sieht es anders aus: 76 der 120 Personen hängen im laufenden Linienbetrieb, allein 52 an den Maschinen, und zwei der drei Montagelinien laufen dauerhaft für die Serie.\nDer Serienanlauf der Produktvariante B muss mit dem auskommen, was übrig bleibt. Das ist keine Ausnahme, sondern die Regel: In der Produktion ist das Projekt der Gast, nicht der Hausherr. Wer das Tagesgeschäft nicht als Vorhaben in den Bestand nimmt, plant mit einer Kapazität, die es nicht gibt — und bekommt einen Plan, der auf dem Papier aufgeht und in der Halle nicht.\nDass die Maschinen- und Anlagenführung dabei an 57 Tagen auf 111 gegen 77 läuft, ist der Normalfall eines ausgelasteten Werks. Es ist kein Planungsfehler, sondern das Ergebnis davon, dass zum ersten Mal beides in derselben Rechnung steht.\nWas der Plan leistet — und was nicht # Er rechnet den laufenden Betrieb mit. Die Grundlast steht als eigenes Vorhaben im Bestand, nicht als Abschlag im Kopf des Planers. Damit ist die Restkapazität eine Zahl und keine Schätzung: 76 Personen gebunden, 44 übrig, und von den Gebundenen allein 52 an den Maschinen. Der Engpass wird dadurch benennbar — nicht „zu wenig Leute\u0026quot;, sondern die Maschinen- und Anlagenführung, an 57 datierten Tagen, um bis zu 34 Köpfe zu knapp.\nEr beseitigt den Überzug nicht. 111 gegen 77 bleiben 111 gegen 77. Ob die Linie langsamer läuft, eine Schicht dazukommt, der Anlauf später beginnt oder ein Teil fremdvergeben wird, entscheidet die Werkleitung — nicht die Software. Ob eine Zusatzschicht mehr Zeit je Person oder mehr Leute bedeutet, klärt der Schichtkalender. Was sich ändert, ist die Grundlage dieser Entscheidung: Sie fällt an Zahlen statt an Zurufen, und sie ist hinterher nachvollziehbar.\nDas Paket dahinter # Von der Anlaufplanung über Produktions- und Anlagenvorbereitung sowie Vorserie und Hochlauf bis zur Serienfreigabe — geplant mit der Restkapazität eines ausgelasteten Werks.\nKennzahl Wert Beispielprojekte 5 Ressourcenpool 120 Personen in 8 Teams Leitprojekt Serienanlauf Produktvariante B (01.10.2026 – 07.04.2027) Umfang des Leitprojekts 29 Vorgänge, 6 Meilensteine, 42 Verknüpfungen Grundlast Linienbetrieb und Tagesgeschäft bindet 76 Personen Engpass Maschinen- und Anlagenführer/in: 111 gegen 77 an 57 Tagen Die Grundlast bindet 76 der 120 Personen im laufenden Linienbetrieb, davon allein 52 in der Maschinenbedienung — die Maschinen- und Anlagenführung liegt dadurch an 57 Tagen über Kapazität (111 gegen 77).\nGeplant sind alle Beispiele dieser Branche mit Rillsoft Project; die Produktseite zur Kapazitätsplanung in der Rillsoft Cloud zeigt die Funktion außerhalb des Beispiels.\nEin Leseweg durch die drei Seiten # Die drei Seiten sind eine einzige Beweiskette. Grundlast und Restkapazität legt das Fundament: Wer das Tagesgeschäft nicht als Vorhaben in den Bestand nimmt, rechnet mit einer Kapazität, die es nicht gibt. Engpass je Qualifikation zieht daraus die planbare Aussage — nicht „zu wenig Leute\u0026quot;, sondern diese Qualifikation, an diesen Tagen, um so viel zu knapp. Und die Linienkonkurrenz überträgt dasselbe Denken auf die Ressource, die sich nicht umverteilen lässt: Fünf Vorhaben wollen dieselbe Montagelinie, über das Portfolio fehlen 86 Linientage — und kein Einzelplan hat davon etwas gewusst.\n","date":"8. September 2026","externalUrl":null,"permalink":"/produktion/","section":"Produktion / Fertigung","summary":"","title":"Produktion / Fertigung","type":"produktion"},{"content":"Ein Kran, den vier Vorgänge gleichzeitig benutzen, ist ein Kran. Steht das nicht in der Planung, rechnet jede Software vier daraus und meldet einen Engpass, den es nicht gibt — und der Bauleiter sucht nach einem Gerät, das längst auf dem Hof steht.\nIm Bauwesen-Paket lässt sich das an einem Fall zeigen, den der Bestand mitbringt: Im Grundlastprojekt „Laufende Baustellen\u0026quot; brauchen vier Vorgänge denselben Mobilkran 30 t, über 61 Arbeitstage hinweg gleichzeitig. Das Gerät gibt es einmal.\nVier Vorgänge, dieselben Wochen # Bild 1 von 3 — Woher die vier Ansprüche kommen, zeigt der Balkenplan. Das Grundlastprojekt bildet keine Kette ab, sondern Dauerleistungen: Alle 22 Vorgänge laufen über dieselben 61 Arbeitstage. Vier davon — Mauerarbeiten, Betonarbeiten, Baustellenunterstützung und Baustellenführung — brauchen den Mobilkran, und zwar durchgehend gleichzeitig. Diese vollständige Überlappung ist der Grund für die Frage: ein Kran oder vier.\nEin Kran, richtig gerechnet # Bild 2 von 3 — Die Zeile 11.002-1 Krane und Hebezeuge – Mobilkran 30 t ist markiert und aufgeklappt; darunter stehen die vier Vorgänge, die den Kran brauchen. Jeder von ihnen ist zu 36,3 Prozent auf ihn angewiesen, zusammen ergibt das die 100 Prozent der Rollenzeile — und in der Tageszelle eine 1. Die Spalte Unterdeckung bleibt leer: Rillsoft Project rechnet ein Exemplar, weil ihm gesagt wurde, dass es dasselbe ist.\nDerselbe Plan ohne die Angabe # Bild 3 von 3 — Das Gegenbild, erzeugt durch das Herauslösen der vier Vorgänge aus der gemeinsamen Nutzung. Jeder hält den Mobilkran jetzt für sich: Ihre Auslastung springt von 36,3 auf 100 Prozent, die Tageszelle der Rolle zeigt 4 gegen ein Angebot von 1, und die Unterdeckung steht bei −126 (75 %). Das Diagramm darunter macht denselben Unterschied sichtbar: orange der Fehlbetrag, grün die eine vorhandene Maschine. Genau diese Zahlen entstehen in jeder Planung, der niemand gesagt hat, dass es derselbe Kran ist.\nDer Unterschied ist keine Feinheit der Darstellung, sondern eine andere Aussage über dieselbe Baustelle:\nmit gemeinsamer Nutzung ohne Bedarf je Tag 1 4 Angebot 1 1 Unterdeckung keine −126 (75 %) Auslastung der vier Vorgänge je 36,3 % je 100 % Was das für die Planung heißt # Betriebsmittel werden im Bau selten exklusiv gebraucht. Ein Kran hebt für die Maurer, gleich danach für die Betonbauer, dazwischen für die Zuarbeit — und in der Planung steht er trotzdem oft viermal, weil jeder Vorgang ihn einzeln anfordert. Wer die gemeinsame Nutzung setzt, sagt der Rechnung, was auf der Baustelle selbstverständlich ist.\nUnd die Grenze gehört dazu: Eine gemeinsame Nutzung gilt innerhalb eines Projekts. Im Portfolio bleiben zwei Projekte, die dasselbe Gerät teilen, zwei Ansprüche — dort hilft nur der Kapazitätsabgleich über die Projekte hinweg.\nWie Rillsoft Project Betriebsmittel und Kapazitäten rechnet, steht auf der Produktseite zur Ressourcenplanung in der Rillsoft Cloud. Zurück zur Übersicht Bauwesen.\n","date":"24. August 2026","externalUrl":null,"permalink":"/bauwesen/gemeinsame-maschinennutzung/","section":"Bauwesen / Modernisierung","summary":"","title":"Gemeinsame Maschinennutzung im Bauwesen","type":"bauwesen"},{"content":"Der Plan sieht machbar aus. Sechs der acht Qualifikationen bleiben an jedem Tag innerhalb der Kapazität, die Auslastungsansicht ist grün, und niemand hat einen Grund, sie zweimal am Tag zu öffnen. Genau dann fällt nicht auf, dass sich der Plan längst verschoben hat: Ein Vorgang rutscht sieben Tage nach hinten, der Endtermin bleibt stehen, und weil kein Engpass aufleuchtet, merkt es niemand.\nDas ist die Lage bei Dienstleistern — und dieses Paket ist eigens dafür gebaut: 30 Personen in fünf Teams, vier Projekte, keine Grundlast. Es ist das einzige des Bestandes, das als machbarer Plan angelegt ist. Damit ist hier nicht der Engpass die Frage, sondern das, was ohne festgehaltenen Stand unsichtbar bleibt — und das eine Fenster, an dem es doch eng wird: Zum Jahreswechsel fallen Migration und Portalentwicklung zusammen, die Backend-Entwicklung liegt an zehn Tagen bei 12 gegen 9, mit der Spitze am 24. Dezember.\nWas der Plan leistet — und was nicht # Er gibt dem Projekt ein Gedächtnis. Der Basisplan hält den Stand fest, mit dem alle einverstanden waren; danach ist jede Abweichung eine Aussage statt einer Erinnerungsfrage. Sieben Tage Verschiebung bei gleichem Endtermin sind entweder eine gewollte Umplanung oder aufgebrauchte Reserve — der Vergleich sagt, welches von beidem. Und bei dreißig Leuten wird personenscharf geplant: Aus einer offenen Stelle wird eine Kandidatenliste mit Qualifikation, Urlaub und Kostensatz.\nEr verhindert keinen Verzug, er datiert ihn. Ein Basisplan macht nichts schneller; er macht sichtbar, wann etwas langsamer wurde. Die zehn Tage um den Jahreswechsel bleiben eng, und wer im Team über Weihnachten die Migration fährt, ist keine Frage der Software. Was sie beiträgt: Die Entscheidung fällt im Oktober an einer Zahl statt im Dezember unter Druck.\nDas Paket dahinter # Sieben Phasen von Projektstart und Fachkonzept über Datenmigration bis zu Einführung mit Cutover und Hypercare — sieben Meilensteine markieren die Phasenübergänge.\nKennzahl Wert Beispielprojekte 4 Ressourcenpool 30 Personen in 5 Teams Leitprojekt ERP-Modul Rechnungswesen (01.10.2026 – 21.04.2027) Umfang des Leitprojekts 26 Vorgänge, 7 Meilensteine, 40 Verknüpfungen Engpass Backend-Entwickler/in: 12 gegen 9 an 10 Tagen Zum Jahreswechsel fallen Migrationsarbeiten im Leitprojekt und die Portal-Entwicklung zusammen: Die Backend-Entwicklung liegt an 10 Tagen über ihrer Kapazität (12 gegen 9), mit der Spitze am 24.12.2026. Sechs der acht Qualifikationen bleiben an jedem Tag innerhalb der Kapazität.\nGeplant sind alle Beispiele dieser Branche mit Rillsoft Project; die Produktseite zur Personaleinsatzplanung in der Rillsoft Cloud zeigt die Funktion außerhalb des Beispiels.\nEin Leseweg durch die fünf Seiten # Der Bogen beginnt bei der Besetzung. Personenscharfe Planung zeigt, dass ein Projekt mit Namen und eines ohne im selben Abgleich rechnen — man darf grob anfangen und genau werden. Die Kandidatenermittlung füllt dann die offene Stelle: neun Kandidaten, Urlaub und Kostensatz offen auf dem Tisch, entscheiden muss ein Mensch.\nDann kippt die Lage: Der Backend-Engpass führt vor, wie vier Vorhaben einzeln gesund aussehen und zusammen 15 Personentage fehlen. Die Antwort darauf — eine Verschiebung, die den Konflikt wirklich auflöst, und das Gedächtnis, das sie festhält — steht auf Basisplan und Soll-Ist-Vergleich. Und wenn das Projekt läuft, übernimmt Fortschritt und Stichtag: nicht Prozente eintippen, sondern rechnen lassen — und sehen, wohin der Verzug geht.\n","date":"8. September 2026","externalUrl":null,"permalink":"/it-dienstleister/","section":"IT-Dienstleister","summary":"","title":"IT-Dienstleister","type":"it-dienstleister"},{"content":"„Wer macht das?\u0026quot; ist im Projekt zwei Fragen, und sie werden zu verschiedenen Zeitpunkten beantwortet. Beim Aufstellen des Plans weiß man, welche Qualifikation ein Vorgang verlangt. Wer sie im Oktober mitbringt, weiß man oft erst Wochen später. Ein Plan, der beides in ein Feld zwängt, zwingt zu einer Antwort, die es noch nicht gibt.\nRillsoft Project trennt die beiden Angaben in zwei Spalten. Gezeigt wird das hier an einem Projekt aus drei Vorgängen — die Trennung ist eine Rechenweise und kein Branchenthema; an dreiundvierzig Vorgängen geht sie in der Menge unter.\nDas Kleinprojekt läuft vom 5. bis 20. Oktober; seine Vorgänge tragen 40, 40 und 16 Stunden Aufwand. Zum Pool gehören Anna Muster und Bernd Beispiel als Bearbeiter sowie Clara Probe als Prüferin. Diese eigens gebaute Besetzung zeigt nur die Trennung von Qualifikation und Name, keinen echten Kundenfall.\nDer Plan, um den es geht # Bild 1 von 3 — Drei Vorgänge in einer Kette, 40, 40 und 16 Stunden, vom 5. bis zum 20. Oktober. Unten steht der erste davon in seiner Eigenschaftsmaske — und dort ist schon zu sehen, wovon diese Seite handelt: Das Register Rollen trägt ein Häkchen, das Register Personal nicht.\nDer Vorgang weiß also, welche Qualifikation er braucht, und noch nicht, wer sie mitbringt. Die beiden nächsten Bilder rechnen denselben Plan einmal so und einmal so zusammen.\nEin Plan ohne einen einzigen Namen # Bild 2 von 3 — Der Plan aus der Sicht der Qualifikation. Eine einzige Zeile steht oben — 11.001 Bearbeitung – Bearbeiter/in —, und darunter hängen alle drei Vorgänge: 40, 40 und 16 Stunden. Zusammen 96, Auslastung 100 Prozent. Mehr braucht ein Plan auf dieser Stufe nicht — ohne dass ein einziger Name gefallen wäre.\nDas leere Register ist kein Mangel. Ein Plan auf dieser Stufe trägt bereits eine vollständige Kapazitätsrechnung — gegen die Rolle: Er weiß, dass er in diesen drei Wochen einen Bearbeiter braucht, und kann das gegen den Pool halten. Was er nicht weiß, ist, ob Anna oder Bernd übernimmt. Diese Frage verträgt es, offen zu bleiben.\nDieselbe Tabelle, ein Schritt weiter # Bild 3 von 3 — Dieselbe Arbeit, eine Gruppierung weiter: Aus einer Zeile werden zwei. Anna Muster hält „Konzept erstellen\u0026quot; und „Freigabe erteilen\u0026quot;, zusammen 56 Stunden; Bernd Beispiel hält „Entwurf prüfen\u0026quot; mit 40. Die Summe ist unverändert — dieselben 96 Stunden, nur anders aufgeteilt.\nLegen Sie die beiden Bilder nebeneinander. In der Reiterleiste tragen jetzt beide Register ein Häkchen: Die Rolle ist geblieben, die Person ist dazugekommen. Und in der Tabelle oben stehen dieselben Anfangstermine, die Balken liegen an derselben Stelle. Das Einsetzen eines Namens terminiert nicht neu — es beantwortet nur die zweite Frage.\nDie Liste in der Mitte ist der eigentliche Gewinn — und man kann sie nachzählen: Der Pool dieses Beispiels führt drei Personen, die Liste zeigt zwei. Clara Probe ist Prüferin, der Vorgang verlangt einen Bearbeiter, also steht sie nicht zur Auswahl. Bei drei Personen wirkt das wie eine Kleinigkeit; bei dreihundert entscheidet es darüber, ob die Frage „wer kann das?\u0026quot; beantwortbar bleibt oder in einer Namensliste untergeht.\nWarum zwei Spalten und nicht eine? # Der Gewinn zeigt sich erst, wenn etwas schiefgeht. Fällt Anna aus, lautet die Frage nicht „wer war das nochmal?\u0026quot;, sondern „wer sonst noch kann das?\u0026quot; — und die ist nur beantwortbar, wenn am Vorgang noch steht, welche Qualifikation er verlangt. Genau daraus baut Rillsoft Project die Kandidatenliste: nicht aus dem ganzen Pool, sondern aus denen, die die geforderte Rolle tragen.\nWer Rolle und Person in ein Feld zwängt, verliert diese Frage. Der Plan weiß dann noch, wer eingetragen war, aber nicht mehr, wonach gesucht werden muss.\nDrei Dinge folgen daraus für die Praxis:\nGrobplanung braucht keine Namen. Ein Plan nur mit Rollen ist kein halber Plan, sondern der richtige Stand für den Zeitpunkt. Kapazität lässt sich vorher rechnen. Die Frage „reicht die Qualifikation\u0026quot; steht schon offen, bevor jemand benannt ist. Der Ausfall bleibt beantwortbar. Die Rolle am Vorgang ist das, was die Suche nach Ersatz überhaupt möglich macht. Wie das im Ernstfall aussieht, zeigen zwei Branchenbeispiele: die Kandidatenermittlung am Ingenieurbüro — dort steht die kurze Liste derer, die tatsächlich in Frage kommen — und die Kapazitätsansichten im Mittelstand, wo dieselbe Trennung erklärt, warum eine Person überlastet sein kann, während ihre Rolle unauffällig bleibt.\nWie Rillsoft Project Qualifikationen und Personen führt, steht auf der Produktseite zur Personaleinsatzplanung in der Rillsoft Cloud.\n","date":"6. September 2026","externalUrl":null,"permalink":"/grundlagen/rolle-oder-person/","section":"Grundlagen der Ressourcenplanung","summary":"","title":"Rolle oder Person","type":"grundlagen"},{"content":"Vier Projektleiter, vier Pläne, vier grüne Ampeln — und im November steht die Montage still. Jedes Vorhaben für sich ist machbar; zusammen kippt es, und in der Runde danach kann niemand sagen, welches nachgeben soll. Wer die Frage stellt, bekommt vier Antworten, die alle stimmen: Jeder hat ja gerechnet.\nGenau diese Lage ist hier gebaut. Produktentwicklung, Kundenanlage, ERP-Einführung und Standortumbau laufen auf demselben Stamm von 120 Personen, von denen die Serienfertigung als Grundlast schon 60 bindet. Es ist das heterogenste Portfolio des Bestandes — und sein Engpass existiert in keinem der vier Einzelpläne: Die Zerspanungsmechanik liegt an 57 Tagen bei 65 gegen 43, aber erst, wenn man alle Vorhaben zusammen rechnet.\nDer Grund dafür ist banal und deshalb so hartnäckig: Vier ungleiche Vorhaben werden von vier Leuten geplant, die jeweils ihren eigenen Ausschnitt sehen. Eine Produktentwicklung mit langen Entwurfsphasen, eine Kundenanlage mit festem Liefertermin, eine ERP-Einführung mit Cutover-Wochenende und ein Standortumbau, der sich nach der Bauzeit richtet — sie teilen so gut wie nichts miteinander außer den Menschen, die sie am Ende ausführen. Und genau die stehen in keinem der vier Pläne vollständig.\nWas der Plan leistet — und was nicht # Er macht den Konflikt überhaupt sichtbar. Ein Multiprojektkonflikt ist nicht schwer zu lösen, er ist schwer zu finden: Solange jeder auf seinen eigenen Plan schaut, gibt es ihn nicht. Über das Portfolio gerechnet fehlen der Montage 45 Personentage — dieselben Daten, ein anderes Ergebnis. Und dieselbe Zahl lässt sich in zwei Ansichten zeigen, was in einem Termin zählt, in dem jemand sie anzweifelt.\nEr priorisiert nicht. Welches der vier Vorhaben nachgibt, ob der Standortumbau in den Sommer rutscht oder die Kundenanlage ihren Zusagetermin verliert, entscheidet die Geschäftsführung — mit allem, was nicht im Plan steht: Kundenbeziehung, Vertragsstrafe, strategisches Gewicht. Der Plan liefert die Grundlage dieser Abwägung und nicht ihr Ergebnis.\nDas Paket dahinter # Produktentwicklung neben Kundenanlage, ERP-Projekt und Standortumbau — vier völlig verschiedene Vorhaben auf demselben Ressourcenstamm.\nKennzahl Wert Beispielprojekte 5 Ressourcenpool 120 Personen in 7 Teams Leitprojekt Produktvariante C (01.10.2026 – 21.05.2027) Umfang des Leitprojekts 28 Vorgänge, 2 Meilensteine, 36 Verknüpfungen Grundlast Serienfertigung und Tagesgeschäft bindet 60 Personen Engpass Zerspanungsmechaniker/in: 65 gegen 43 an 57 Tagen Die Zerspanungsmechanik liegt an 57 Tagen über ihrer Kapazität (65 gegen 43); der Konflikt entsteht erst projektübergreifend, weil Serienfertigung, Kundenanlage und Standortumbau denselben Stamm nutzen.\nGeplant sind alle Beispiele dieser Branche mit Rillsoft Project; die Produktseite zum Multiprojektmanagement in der Rillsoft Cloud zeigt die Funktion außerhalb des Beispiels.\nEin Leseweg durch die zwei Seiten # Die beiden Seiten sind Frage und Werkzeug. Der Multiprojekt-Kapazitätsabgleich stellt die Frage, die kein Einzelplan beantworten kann: Jedes Projekt für sich machbar — und zusammen fehlen der Montage 45 Personentage. Wie man dieselbe Lage dann aus jedem nötigen Blickwinkel betrachtet, zeigt Kapazitätsansichten steuern: Struktur, Ansicht und Kennzahl sind drei Regler an denselben Daten — wer den falschen wählt, bekommt eine richtige Antwort auf die falsche Frage. Prozentanteil je Rolle beantwortet dabei die Frage, worauf sich die Prozentzahl bezieht.\nWer dasselbe Portfolio-Denken an anderer Stelle sehen will: Im IT-Paket entsteht der Konflikt zwischen vier Softwareprojekten, in der Produktion zwischen Projekten und Linienbetrieb — die Rechnung ist immer dieselbe, nur der Stamm ein anderer. Und wer wissen will, wie viel Portfolio ein Werkzeug überhaupt trägt, findet im Anlagenbau die Gegenprobe über Größe: zwölf Projekte mit 6.134 Elementen in einem einzigen Portfolio. Die Ansichten, die hier an vier Vorhaben eine Fingerübung sind, tragen dort unverändert.\n","date":"8. September 2026","externalUrl":null,"permalink":"/mittelstand/","section":"Mittelstand / Multiprojekt","summary":"","title":"Mittelstand / Multiprojekt","type":"mittelstand"},{"content":"Ein Vorgang trägt drei Größen, und sie hängen zusammen: Aufwand = Dauer × Auslastung. Ändert man eine davon, muss von den beiden anderen eine nachgeben. Welche — das ist die Vorgangsart. Sie ist keine Beschreibung des Ist-Standes, sondern eine Regel für den nächsten Eingriff.\nGenau deshalb ist sie so leicht zu übersehen: Solange nichts passiert, sieht man sie nicht. Zwei Vorgänge machen das nachprüfbar.\nFür die Gegenprobe stehen zwei sonst gleiche Vorgänge nebeneinander. Beide laufen mit 40 Stunden Aufwand vom 5. bis 9. Oktober; Anna Muster übernimmt den ersten, Bernd Beispiel den zweiten. Das eigens gebaute Projekt hält Kalender, Branche und Kundenauftrag aus dem Vergleich heraus. Nur die Vorgangsart ist verschieden: einmal fester Aufwand, einmal feste Dauer.\nAm ruhenden Plan ist nichts zu sehen # Bild 1 von 4 — Zwei Vorgänge, zwei Vorgangsarten — und keine einzige Zahl in der Tabelle, die sie unterscheidet: Beide dauern fünf Tage, beide kosten 40 Stunden, beide laufen vom 5. bis zum 9. Oktober. Der Unterschied steht unten in der Maske, im Feld Feste, und dort steht Aufwand.\nDie beiden Zeilen sind absichtlich bis auf den Namen identisch. Der obere Vorgang hat den festen Aufwand, der untere die feste Dauer — und man könnte lange auf die Tabelle schauen, ohne es zu merken. Der Balkenplan hat für die Vorgangsart nicht einmal eine Spalte; sie steht in der Eigenschaftsmaske des Vorgangs, im Feld Feste.\nBild 2 von 4 — Dieselbe Maske, eine Zeile tiefer. Der einzige Unterschied im ganzen Bild ist das Feld Feste: Es steht jetzt auf Dauer. Aufwand und Dauer daneben sind unverändert 40 und 5.\nDamit liegt die Einstellung, um die es geht, sichtbar auf dem Tisch — und sie hat noch nichts getan. Wer hier stehenbleibt, hält die Vorgangsart für Formsache. Das ist sie genau so lange, wie niemand etwas ändert.\nDieselbe Eingabe, zwei Ergebnisse # Bild 3 von 4 — Dieselbe Eingabe an beiden Zeilen — die Dauer von fünf auf zehn Tage —, und erst jetzt trennen sich die Wege: In der Spalte Dauer steht bei beiden dieselbe 10, in der Spalte Aufwand stehen 40 und 80. Die Maske darunter sagt, wo das ankommt: Auslastung 50, Aufwand 40 — dieselbe Arbeit auf der doppelten Zeit.\nBeide Vorgänge haben dieselbe Behandlung bekommen — die Dauer wurde verdoppelt. Danach steht in der Spalte Dauer bei beiden dieselbe 10, in der Spalte Aufwand aber stehen zwei verschiedene Zahlen:\nFester Aufwand: 40 bleiben 40. Dieselbe Arbeit verteilt sich auf die doppelte Zeit. Die Person ist nur noch zur Hälfte gebunden — im Balken sichtbar als die dünnere Schraffur. Feste Dauer: aus 40 werden 80. Die Person bleibt voll gebunden, also wächst die Arbeit mit der Zeit mit. Keines der beiden Ergebnisse ist falsch. Sie beantworten verschiedene Fragen: Das eine sagt „diese Arbeit ist zu tun, sie darf sich strecken\u0026quot;, das andere „diese Zeit ist zu füllen\u0026quot;.\nWo das bei der Person ankommt # Bild 4 von 4 — Dieselbe Stelle am zweiten Vorgang, und sie liest sich anders: Auslastung 100, Aufwand 80. Bernd Beispiel bleibt voll gebunden, jetzt doppelt so lange.\nDie halbe Bindung ist damit keine Behauptung mehr, sondern eine Zahl: Auslastung 50 gegen 100, bei gleicher Dauer. Wer wissen will, was eine Vorgangsart für die Menschen im Plan bedeutet, findet es hier — im Register Personal der Vorgangsmaske, nicht in der Tabelle.\nWann nimmt man welche Vorgangsart? # Die Wahl fällt danach, welche der beiden Größen aus der Sache heraus feststeht:\nFester Aufwand, wenn die Arbeit die harte Größe ist: eine Zeichnung, ein Bericht, eine Prüfung. Die Menge ändert sich nicht dadurch, dass man mehr Zeit einräumt. Feste Dauer, wenn die Zeitspanne die harte Größe ist: eine Baustellenbetreuung, eine Bereitschaft, eine begleitende Rolle. Läuft der Zeitraum länger, ist auch länger jemand gebunden. Beides fest gibt es ebenfalls — dann gibt bei einer Änderung die Auslastung nach, und der Plan meldet eine Überlast, statt sie wegzurechnen. Praktisch heißt das: Die Vorgangsart wird beim Anlegen entschieden, nicht in der Umplanung. Wer sie erst umstellt, während er schon verschiebt, bekommt ein Ergebnis, das von der Reihenfolge der Klicks abhängt. Und wer sie nie setzt, plant mit der Voreinstellung — was gutgeht, solange niemand einen Balken zieht.\nDie Vorgangsart legt fest, ob der Gesamtaufwand bei einer Änderung stehen bleibt. Wie dieser feste Aufwand anschließend zwischen mehreren Personen wandern kann, erklärt die dynamische Aufwandsverteilung.\nWie das an einem echten Bestand aussieht, zeigt der Projektstrukturplan im Maschinenbau: Dort tragen alle 49 Vorgangszeilen des Leitprojekts festen Aufwand, weil das Projekt über seine Arbeit beschrieben ist und nicht über eine Kalenderspanne.\nWas Rillsoft Project sonst noch aus Aufwand und Dauer rechnet, steht auf der Produktseite zum Projektmanagement in der Rillsoft Cloud.\n","date":"6. September 2026","externalUrl":null,"permalink":"/grundlagen/vorgangsart-aufwand-oder-dauer/","section":"Grundlagen der Ressourcenplanung","summary":"","title":"Vorgangsart: Aufwand oder Dauer","type":"grundlagen"},{"content":"Fachlich könnte jeder Maurer überall arbeiten. Praktisch plant man mit der Kolonne vor Ort — und genau diese Selbstverständlichkeit muss in der Planung stehen, sonst schlägt die Software Leute vor, die 300 Kilometer entfernt sind.\nDie „Bauwerk Union\u0026quot; führt 150 Personen in 17 Kolonnen an drei Niederlassungen (NORD 52, SUED 52, WEST 35) plus Konzernebene. Die Qualifikationen sind überall dieselben. Was sie unterscheidet, ist das bevorzugte Team — und das steht nicht am Vorgang, sondern am Teilprojekt.\nWo die Standortentscheidung sitzt # Bild 1 von 4 — Hier sitzt die Standortentscheidung — nicht am Vorgang, sondern am Teilprojekt. „Rohbau Halle\u0026quot; führt die beiden Rohbaukolonnen der Niederlassung Nord als bevorzugtes Team. Von hier vererbt sich der Vorzug nach unten und belegt den Kandidatenfilter jedes Vorgangs vor.\nDer Filter, den sie auslöst # Bild 2 von 4 — Derselbe Vorzug, eine Ebene tiefer: Weil das Teilprojekt die Nord-Kolonnen führt, zeigt die Kandidatenliste dieses Vorgangs nur Personen von dort. Der Vorgang braucht 6 Maurer und hat 3 — und die Liste sagt, dass der Standort nichts mehr hergibt.\nDer Vorgang „Brandwaende und Trennwaende\u0026quot; braucht 6 Maurer und hat 3 besetzt; die Bilanz links steht auf −30. Rechts neben dem Filter steht die Zahl, um die es geht: 11 — so viele Kandidaten kennt die Liste, alle aus den Nord-Kolonnen. Parallel läuft „Hallenwaende mauern\u0026quot; mit 8 Maurern derselben Kolonnen. Der Standort ist ausgereizt.\nDerselbe Vorgang ohne Vorzug # Bild 3 von 4 — Das Gegenbild. Genommen wird der Vorzug am Teilprojekt, nicht am Vorgang — genau dort, wo er gesetzt wurde. Sofort stehen die Kolonnen der anderen Niederlassungen in der Liste. Fachlich konnten sie das immer; sichtbar werden sie erst, wenn man den Standort bewusst verlässt.\nDie ersten Zeilen der Liste sehen aus wie vorher — der Unterschied steht im Zähler: 28 statt 11. Das Häkchen „Bevorzugte Teams\u0026quot; ist aus, und damit stehen die Kolonnen aus Süd und West zur Wahl. Fachlich konnten sie das immer; sichtbar werden sie erst, wenn man den Standort bewusst verlässt.\nmit Teamvorzug ohne Kandidaten 11 28 Herkunft nur NORD NORD, SUED, WEST Bilanz am Vorgang −30 −30 Die Bilanz ändert sich nicht — der Filter besetzt niemanden. Er entscheidet nur, wen die Liste überhaupt anbietet.\nDie Gegenprobe # Bild 4 von 4 — Die Gegenprobe zur Kandidatenliste. Statt zu fragen, wer noch frei ist, zeigt diese Ansicht, was die Kolonne insgesamt trägt: In den zwei Wochen um den Mauerbeginn ist NORD - Rohbau-1 ausgelastet. Genau deshalb liefert der gefilterte Kandidatensatz keine freien Leute mehr — der Standort ist ausgereizt, nicht die Qualifikation.\nWas das für die Planung heißt # Das bevorzugte Team ist eine Vorzugsmarke, keine Zuweisung. Im ganzen Paket trägt kein einziger Vorgang eine Teamzuweisung; die 17 Kolonnen stehen an 15 Teilprojekten als Vorzug. Dadurch bleibt die Planung standorttreu, ohne dass jemand Namen einträgt — und wenn es eng wird, ist der Weg nach draußen ein bewusster Schritt und kein Versehen.\nDie Reihenfolge, die sich daraus ergibt: erst die eigene Kolonne, dann die Nachbarniederlassung, und erst danach Nachunternehmer. Genau so, wie es ein Bauleiter ohnehin macht.\nWer die Rechenweise dahinter sehen will — ohne Branche, an drei Personen und zwei Standorten statt an 150 —, findet sie unter Standortbezogene Planung: Dort passt derselbe Plan nach Rolle und nach Person und erst nach Standort nicht mehr. Diese Seite hier zeigt, was das im Ernstfall bedeutet.\nWie Rillsoft Project Personaleinsatz über Standorte hinweg plant, steht auf der Produktseite zur Personaleinsatzplanung in der Rillsoft Cloud. Zurück zur Übersicht Baukonzern.\n","date":"25. August 2026","externalUrl":null,"permalink":"/baukonzern/bevorzugtes-team-standortplanung/","section":"Bau- und Infrastrukturkonzern","summary":"","title":"Bevorzugtes Team am Beispiel Baukonzern","type":"baukonzern"},{"content":"Dreißig Leute, vier Vorhaben, acht Qualifikationen. In einem Büro dieser Größe lautet die Frage nie, ob die Kapazität reicht — irgendwie reicht sie immer. Sie lautet: wann genau wird es eng, und welche Leistungsphase wartet dann? Das ist keine akademische Unterscheidung. Wer im Oktober weiß, dass Mitte März drei Tage klemmen, verschiebt eine Begehung. Wer es Mitte März merkt, ruft einen Bauherrn an.\nDieses Paket ist auf genau diese Feinheit gebaut. Der Engpass ist der kleinste des ganzen Bestandes: drei Tage Mitte März, an denen Bauausführung im Neubau und Sanierungsüberwachung zusammentreffen und die Bauüberwachung bei 6 gegen 5 steht. Dazu eine zweite Stelle Anfang Dezember, an der Objektplanung und TGA-Fachplanung gleichzeitig voll ausgelastet sind. Kein Dauerzustand, sondern zwei Datumsangaben — und ein enger Pool ohne Grundlast, an dem nichts den Blick darauf verstellt.\nWas der Plan leistet — und was nicht # Er macht aus einem Gefühl zwei Termine. „Im Frühjahr wird es eng\u0026quot; ist keine Grundlage für ein Gespräch mit dem Bauherrn; „am 16., 17. und 18. März fehlt uns ein Bauleiter in der Überwachung\u0026quot; ist eine. Dazu kommt die Unterscheidung, die in einem personenscharf arbeitenden Büro die eigentliche Arbeit spart: Die Rolle sagt, welche Qualifikation ein Vorgang braucht, die Person, wer sie mitbringt. Erst dadurch wird die Kandidatenliste kurz genug, um eine Entscheidung zu tragen.\nDie zweite Stelle Anfang Dezember ist dabei die lehrreichere: Objektplanung und TGA-Fachplanung sind dort gleichzeitig voll ausgelastet, aber nicht darüber. Das ist kein Konflikt, sondern eine Warnung — jede Zusage, die in diesen Zeitraum fällt, geht auf Kosten einer anderen.\nEr macht drei Tage nicht zu null. Die Überschneidung bleibt; sie verschiebt sich höchstens dorthin, wo sie weniger kostet. Und vor der ersten Auswertung steht die eigentliche Hürde jeder Einführung: der Aufbau des Pools. Dass 30 Köpfe nicht 30 Kapazitäten sind, sondern acht Qualifikationen in 34 Zeilen, ist der Teil, an dem die meisten Einführungen hängen bleiben — nicht die Auswertung danach. Dieses Paket führt ihn deshalb Schritt für Schritt vor, an einem Bestand ohne Grundlast: ohne den Ballast, der den Einstieg unnötig schwer machen würde.\nDas Paket dahinter # Leistungsphasen von der Bedarfsplanung bis zur Übergabe, mit einer zweiten Teilprojektebene in der Entwurfsphase.\nKennzahl Wert Beispielprojekte 4 Ressourcenpool 30 Personen in 5 Teams Leitprojekt Neubau Verwaltungsgebäude (01.10.2026 – 01.04.2027) Umfang des Leitprojekts 29 Vorgänge, 6 Meilensteine, 43 Verknüpfungen Engpass Bauleiter/in Bauüberwachung: 6 gegen 5 an 3 Tagen Mitte März treffen Bauausführung im Leitprojekt und Sanierungsüberwachung zusammen: Die Bauüberwachung liegt an 3 Tagen über Kapazität (6 gegen 5). Anfang Dezember sind Objektplanung und TGA-Fachplanung voll ausgelastet.\nGeplant sind alle Beispiele dieser Branche mit Rillsoft Project; die Produktseite zur Ressourcenplanung in der Rillsoft Cloud zeigt die Funktion außerhalb des Beispiels.\nEin Leseweg durch die zwei Seiten # Am Anfang steht die Frage, die vor jedem Plan kommt: Ressourcenpool aufbauen zeigt, warum die Kopfzahl eines Büros nicht seine Kapazität ist — 30 Personen, acht Qualifikationen, 34 Zeilen. Darauf setzt Rolle oder Person die eigentliche Arbeitsweise: Grobplanung nach Qualifikation, Feinplanung mit Namen, und derselbe Plan trägt beides — weil im Abgleich nicht zählt, ob eine Zeile einen Namen hat, sondern ob die Qualifikation reicht.\nWie dieselbe personenscharfe Arbeitsweise in einem Softwarehaus aussieht — mit Kandidatenliste, Urlaub und Kostensatz —, zeigt das IT-Paket am Beispiel einer Sprintbesetzung. Und warum die Trennung von Rolle und Person keine Formsache ist, steht branchenneutral unter Rolle oder Person.\n","date":"8. September 2026","externalUrl":null,"permalink":"/ingenieurbuero/","section":"Ingenieurbüro / Planung","summary":"","title":"Ingenieurbüro / Planung","type":"ingenieurbuero"},{"content":"Im Amt ist der Regelfall nicht der Konflikt, sondern der Nachweis. Die Sanierung muss in die Ferien passen, weil in der Schule sonst niemand arbeiten darf. Die Vergabe hängt am Beschluss des Bauausschusses. Und in der Vorlage muss stehen, dass das Amt die Maßnahme mit eigenem Personal trägt — vor der Vergabe, nicht hinterher. Eine Demo überzeugt hier niemanden; gebraucht wird eine Zahl, die in eine Vorlage passt und die ein Gremium nachvollziehen kann.\nDieses Paket ist deshalb das einzige des Bestandes ohne Kapazitätsengpass, und das ist seine Aussage, nicht sein Mangel. Ein Hochbauamt mit 30 Personen führt vier Maßnahmen; selbst Ende Januar, wenn alle vier gleichzeitig laufen, bleibt die Bauüberwachung mit 3 gegen 9 komfortabel im Rahmen. Die Schwierigkeit kommunalen Bauens liegt woanders: in Randbedingungen, die niemand verhandeln kann.\nWas der Plan leistet — und was nicht # Er macht aus dem Nachweis eine Zahl. Vier Maßnahmen gleichzeitig, höchster Bedarf Ende Januar bei 3 gegen 9 Verfügbare, an keinem Tag über Kapazität — das ist eine Aussage, die eine Beschlussvorlage trägt, weil sie aus dem Plan folgt und nicht aus einer Schätzung. Dazu kommt die Disziplin bei den Terminen: Ferienfenster, Vergabefristen und Beschlusstermine stehen als fixierte Elemente im Plan statt im Kopf des Planers. Passt etwas nicht mehr, bricht die Terminierung an ihnen ab, statt sie stillschweigend zu verschieben — der Unterschied zwischen einem Plan, der widerspricht, und einem, der nachgibt.\nUnd der Ablauf selbst ist geplant, nicht vorausgesetzt: Bestandsaufnahme, Fördermittelantrag, Beschlussvorlage, VOB-Vergabe und förmliche Abnahme stehen als Vorgänge im Plan und nicht als Fußnote daneben. Wer wissen will, wann eine Vorlage in den Ausschuss muss, damit die Ferien noch erreichbar sind, liest es ab, statt es zurückzurechnen.\nEr verschiebt keine Ferien. Ein Beschluss wird nicht schneller, eine Förderfrist nicht länger, und das Vergaberecht kennt keine Umplanung. Der Plan sagt, ob es passt, und wo es nicht passt — die Konsequenz daraus ziehen Amt und Gremium.\nDas Paket dahinter # Kommunaler Ablauf mit Bestandsaufnahme, Fördermitteln und Beschlussvorlagen, VOB-Vergabe und förmlicher Abnahme — an die Ferienfenster gebunden und dadurch mit Zwangsterminen geplant.\nKennzahl Wert Beispielprojekte 4 Ressourcenpool 30 Personen in 5 Teams Leitprojekt Sanierung Grundschule Lindenhof (06.10.2026 – 27.04.2027) Umfang des Leitprojekts 34 Vorgänge, 4 Meilensteine, 46 Verknüpfungen Engpass Bauleiter/in Bauüberwachung: 3 gegen 9 an 0 Tagen Die höchste Auslastung trägt die Bauüberwachung Ende Januar, wenn alle vier Maßnahmen gleichzeitig laufen — mit 3 gegen 9 Verfügbare bleibt der Amtspool an jedem Tag innerhalb seiner Kapazität.\nGeplant sind alle Beispiele dieser Branche mit Rillsoft Project; die Produktseite zur souveränen Alternative zu Microsoft Project zeigt die Funktion außerhalb des Beispiels.\nDer eine Leitfall # Dieser Branche genügt eine Seite, und sie handelt nicht von Konfliktlösung, sondern von Disziplin: Zwangstermine und Ferienfenster zeigt, wie von außen gesetzte Termine als fixierte Elemente in den Plan gehören statt in den Kopf des Planers — an einer Sanierung, die neben drei weiteren Maßnahmen auf demselben Amtspool läuft.\nWas ein von außen gesetzter Termin im Störfall bedeutet, hängt an der Planungsart: termintreu bleibt der Termin stehen und die Lücke wird zur Zahl, kapazitätstreu wandert der Plan. Wie derselbe Fall an einer kommunalen Baustelle aussieht, zeigt Eine Krankmeldung, zwei Antworten.\nDas Gegenstück mit denselben Mitteln und umgekehrtem Befund ist die Winterbaustelle im Bauwesen: dort halten Zwangstermine und Kalenderfenster einen Plan zusammen, der ohne sie tatsächlich kippen würde.\n","date":"8. September 2026","externalUrl":null,"permalink":"/oeffentliche-verwaltung/","section":"Öffentliche Verwaltung / Hochbauamt","summary":"","title":"Öffentliche Verwaltung / Hochbauamt","type":"oeffentliche-verwaltung"},{"content":"Jede Werkzeugeinführung stolpert irgendwann über denselben Satz: „Und wenn es größer wird?\u0026quot; Die Frage ist berechtigt und wird fast nie beantwortet, weil Vorführungen mit fünfzig Vorgängen arbeiten. Über ein Portfolio mit 4.263 Vorgängen sagt so eine Vorführung nichts — außer, dass sie klein war.\nDieses Paket ist die Antwort in Zahlen statt in Zusicherungen: zwölf Großprojekte in einem Portfolio, 6.134 Elemente, 4.263 Vorgänge, 1.787 Sammelvorgänge und 72 Meilensteine über vier Strukturebenen — Hauptphase, Teilprojekt, Arbeitspaket, Vorgang. Allein das Leitprojekt, die Prozessanlage PPA-400, führt 650 Elemente. Der Pool umfasst 90 Personen mit 97 Qualifikationszeilen.\nWas der Plan leistet — und was nicht # Er beantwortet die Größenfrage, bevor jemand testet. Die Ansichten, die im Mittelstandspaket an vier Vorhaben eine Fingerübung sind, tragen hier unverändert. Vier Ebenen bleiben bedienbar, wenn man weiß, was man zuklappt — und genau das ist die praktische Erkenntnis: Nicht die Datenmenge entscheidet über die Übersicht, sondern die Gliederung und die Frage, auf welcher Ebene man sie stellt.\nDas lässt sich an diesem Bestand nachvollziehen. Zwischen den 4.263 Vorgängen liegen 1.787 Sammelvorgänge — Hauptphasen, Teilprojekte, Arbeitspakete —, und 72 Meilensteine markieren die Übergänge. Wer alles aufklappt, sieht nichts; wer auf Arbeitspaketebene zuklappt, sieht zwölf Projekte nebeneinander mit ihren Phasen. Die Übersicht ist damit keine Eigenschaft des Werkzeugs, sondern eine Einstellung, die man kennen muss.\nEr ist kein machbarer Plan und will keiner sein. Alle dreizehn belegten Qualifikationen liegen im Dauerüberzug, die Rohrleitungsmontage bei 44 gegen 11 an 70 Tagen. Wer aus diesem Paket eine Terminaussage ableiten will, liest das falsche — dafür sind die anderen acht da. Diese Offenheit ist Absicht: In einem Auswahlgespräch ist ein Paket, das seine eigene Grenze benennt, mehr wert als eine geschönte Zahl.\nDer Überzug ist dabei kein Modellierungsfehler, sondern die Folge der gebauten Größe: Zwölf Großprojekte gleichzeitig auf einen Pool von 90 Personen mit 97 Qualifikationszeilen zu legen, ergibt zwangsläufig einen Bestand, den niemand so terminieren würde. Genau das macht ihn als Lastprobe brauchbar.\nDas Paket dahinter # Sechs Hauptphasen über vier Strukturebenen — Hauptphase, Teilprojekt, Arbeitspaket, Vorgang —, je Anlagenteil ein eigenes Arbeitspaket in Detail Engineering, Vorfertigung, Montage und Inbetriebnahme.\nKennzahl Wert Beispielprojekte 12 Ressourcenpool 90 Personen in 10 Teams Leitprojekt Prozessanlage PPA-400 Nordchemie (01.10.2026 – 06.01.2027) Umfang des Leitprojekts 462 Vorgänge, 0 Meilensteine, 618 Verknüpfungen Engpass Rohrleitungsmonteur/in: 44 gegen 11 an 70 Tagen Im gebauten Bestand liegen alle dreizehn belegten Qualifikationen im Dauerüberzug, die Rohrleitungsmontage bei 44 gegen 11 an 70 Tagen — das Paket ist ein Nachweis über Größe, kein machbarer Plan.\nGeplant sind alle Beispiele dieser Branche mit Rillsoft Project; die Produktseite zum Multiprojektmanagement in der Rillsoft Cloud zeigt die Funktion außerhalb des Beispiels.\nEin Leseweg durch die zwei Seiten # Portfolio mit zwölf Großprojekten zeigt den fachlichen Kern: Ein Anlagenprojekt für sich passt, zwölf zusammen nicht — derselbe Kapazitätsabgleich, dieselbe Ansicht, nur mit 4.263 Vorgängen darunter. Die Portfolio-Skalierung führt denselben Bestand als technischen Beleg: 6.134 Elemente in einer Datei, und die Ansichten, die im Mittelstandspaket eine Fingerübung waren, tragen unverändert.\nWer den Vergleich sucht: Dieselbe Rechnung an fünf statt zwölf Projekten steht im Multiprojekt-Kapazitätsabgleich des Mittelstands, und wie man die Ansichten dafür einstellt, zeigen die Kapazitätsansichten. Die Rechenweise hinter der Auslastungszahl steht branchenneutral unter Prozentanteil je Rolle — bei 97 Qualifikationszeilen ist die Frage, worauf sich eine Prozentzahl bezieht, keine akademische mehr.\n","date":"8. September 2026","externalUrl":null,"permalink":"/anlagenbau/","section":"Anlagenbau / Großprojekte","summary":"","title":"Anlagenbau / Großprojekte","type":"anlagenbau"},{"content":"Ein Arbeitstag hat acht Stunden — das ist die häufigste stille Fehlannahme in Plänen. Wer rund um die Uhr arbeiten lässt, plant nicht einen längeren Tag, sondern drei Schichten: drei Kalender, drei Menschen, ein Vorgang.\nIn Rillsoft Project hängt die Arbeitszeit an der Person, nicht am Projekt. Vier Bilder zeigen den Weg: was der Vorgang verlangt, wer ihn übernimmt, und wie sich der Tag danach zwischen den dreien aufteilt. Zwei weitere zeigen den Schichtkalender selbst — fest zugeordnet und rotierend.\nDas eigens gebaute Beispiel enthält nur den Vorgang „Anlage in Betrieb nehmen“. Er steht auf fester Dauer, trägt zunächst 240 Stunden und rechnet auf einem Hauptkalender mit 24 Stunden pro Tag. Anna Muster arbeitet früh, Bernd Beispiel spät und Dieter Test nachts. Branche, Auftrag und weitere Engpässe sind bewusst nicht Teil dieses Kalendervergleichs.\nErst die Anforderung, noch keine Namen # Bild 1 von 6 — Der Vorgang verlangt eine Bearbeiterkraft, und mehr steht noch nicht fest. Im Kopf der Maske steht „Dauer 10 AT (24 Std.)\u0026quot; — der Hauptkalender dieses Projekts läuft rund um die Uhr, ein Arbeitstag ist hier also 24 Stunden lang.\nZwei Einstellungen tragen die ganze Seite, und beide stehen schon in diesem Bild:\nDer Hauptkalender läuft 24 Stunden. Er ist die äußere Schranke. Stünde er auf 8 bis 17 Uhr, wären Spät- und Nachtschicht abgeschnitten, und die drei Kalender darunter blieben wirkungslos. Der Vorgang steht auf fester Dauer. Er läuft 240 Stunden — auf dem Hauptkalender sind das zehn Arbeitstage, vom 5. bis zum 17. Oktober. Geplant wird zunächst über die Rolle: eine Bearbeiterkraft, noch kein Name. Drei Namen, drei Kalender # Bild 2 von 6 — Aus der Anforderung sind drei Namen geworden: Anna Muster in der Frühschicht, Bernd Beispiel in der Spätschicht, Dieter Test in der Nachtschicht. Jede steht bei 100 Prozent — und das Ende wandert vom 17. Oktober auf den 14. November.\nZwei Zahlen ändern sich, und beide sagen etwas. Weil der Vorgang auf fester Dauer steht, arbeitet jede der drei mit voller Auslastung; der Aufwand wächst dadurch von 240 auf 720 Stunden. Und das Ende wandert: Die Rollenzeile hatte auf dem Hauptkalender rund um die Uhr gerechnet, die drei Namen arbeiten in Schichten von je acht Stunden. Drei Schichten machen den Tag lückenlos, nicht den Vorgang dreimal so schnell. Wer Schichten plant, plant deshalb nicht „mehr Leute\u0026quot;, sondern andere Zeiten — und muss beides auseinanderhalten.\nDie Rolle: rund um die Uhr belegt # Bild 3 von 6 — Dieselbe Planung nach Rolle gruppiert, Stunde für Stunde. In jeder Spalte steht eine ganze Kraft — von Mitternacht bis Mitternacht. Die Lücke, die eine einzelne Schicht ließe, füllt die nächste.\nAuf der Tagesskala stünde hier eine einzige Summe, und man sähe nichts. Erst die Stundenskala zeigt, was drei Schichten aus einem Tag machen: keine Stunde ohne Bedarf, keine Nachtstunde ausgespart.\nDie Personen: drei Bänder, die sich nicht überschneiden # Bild 4 von 6 — Dieselbe Planung nach Person gruppiert — und jetzt zerfällt der Tag in seine drei Schichten: Anna Muster von 6 bis 14 Uhr, Bernd Beispiel von 14 bis 22, Dieter Test von 22 bis 6.\nLegen Sie Bild 3 und Bild 4 nebeneinander: Oben eine durchgehende Reihe, unten drei Bänder, die sich nicht überschneiden und zusammen keine Stunde auslassen. Das ist ein Schichtkalender — kein Merkmal des Vorgangs, sondern eines der Person. Der Vorgang weiß nichts von Schichten; er bekommt seine Stunden von denen, die gerade da sind.\nDer Schichtkalender selbst: dauerhaft festgelegt # Bild 5 von 6 — Dieselben drei Menschen, eine Ebene höher: Woche für Woche statt Stunde für Stunde, dafür mit dem Schichtkalender im Bild. Jede Zeile behält ihre Farbe — Anna Muster gelb, Bernd Beispiel orange, Dieter Test blau — von Anfang Oktober bis Silvester.\nBis hierher ging es darum, was drei Schichten mit einem Vorgang machen. Diese beiden Bilder zeigen den Schichtkalender als Einstellung: eine Zeile je Person, eine Spalte je Woche, und die Farbe sagt, in welcher Schicht dieser Mensch gerade arbeitet. Das ist die einfachste Form eines Schichtbetriebs, die dauerhaft festgelegte Schicht — leicht zu planen und leicht zu lesen. Sie hat nur einen Preis: Dieselbe Person trägt jede Nacht.\nUnd derselbe Plan mit Rotation # Bild 6 von 6 — Dasselbe Bild, ein Schichtplan weiter: Jetzt rotieren die drei. Anna Muster geht von der Früh- in die Spät- und dann in die Nachtschicht, Bernd Beispiel und Dieter Test jeweils eine Schicht versetzt — Woche für Woche bis zum Jahresende.\nLegen Sie beide nebeneinander: Gleiche Zeilen, gleiche Auslastung, gleiche Stunden — nur die Farben wandern. Für die Planung ändert die Rotation nichts; in jeder einzelnen Woche ist jede Schicht genau einmal besetzt. Für die drei Menschen ändert sie alles.\nDrei Personen reichen dafür genau — und sind zugleich das Minimum. Drei Schichten müssen gleichzeitig besetzt sein, also braucht es drei Köpfe; mit genau dreien geht der Ringtausch ohne Rest auf. Mehr Köpfe braucht erst, wer auch am Wochenende durchfährt.\nWas man dabei falsch machen kann # Den Hauptkalender vergessen. Er ist die äußere Schranke. Läuft er nur von 8 bis 17 Uhr, sind Spät- und Nachtschicht abgeschnitten — die Kalender der Personen sind gesetzt, und trotzdem ändert sich nichts. Termintreue Planung. Sie rechnet ohne die Kalender der Ressourcen; die Schichten wären folgenlos. Wer Schichten plant, braucht kapazitätstreue Planung. Die Vorgangsart nicht bedenken. Bei fester Dauer arbeitet jede zugewiesene Person voll, und der Aufwand wächst mit — hier von 240 auf 720 Stunden. Bei festem Aufwand bleiben es 240, und die drei teilen sich eine Vollkraft mit je 33,3 Prozent. Beides ist richtig; es sind zwei verschiedene Fragen. Von drei Schichten auf ein Drittel der Zeit schließen. Der Balken wird nicht kürzer, weil rund um die Uhr gearbeitet wird — er wird länger, weil jede Person nur acht Stunden am Tag da ist. Wie Kalender und Qualifikationen in einem Produktionsfall zusammenwirken, zeigt der Engpass je Qualifikation.\nWie Rillsoft Project Kalender und Schichten führt, steht auf der Produktseite zur Personaleinsatzplanung in der Rillsoft Cloud.\n","date":"6. September 2026","externalUrl":null,"permalink":"/grundlagen/schichtkalender/","section":"Grundlagen der Ressourcenplanung","summary":"","title":"Schichtkalender","type":"grundlagen"},{"content":"Die Kolonne vor Ort hat 11 Maurer, gebraucht werden 14 — und in der Nachbarniederlassung sitzen welche, die gerade nichts zu tun haben. Das ist der teuerste Satz in einem Mehrstandort-Unternehmen, weil er in beide Richtungen falsch beantwortet wird: Entweder man plant streng nach Standort und übersieht freie Leute, oder man rechnet konzernweit und verspricht Kolonnen, die am Stichtag 200 Kilometer entfernt sind.\nDieses Paket ist das einzige des Bestandes mit Standorten: drei Niederlassungen, 150 Personen in 17 Kolonnen, 15 Qualifikationen. Fachlich könnte jeder Maurer überall arbeiten — die Qualifikationen sind an allen drei Standorten dieselben. Geplant wird trotzdem mit der Kolonne vor Ort, und genau diese Selbstverständlichkeit ist hier modelliert: Alle 17 Teamzeilen stehen als bevorzugtes Team an den Sammelvorgängen. Der Engpass steckt deshalb nicht in der Qualifikation, sondern im Team.\nWas der Plan leistet — und was nicht # Er macht den Nutzen der Zentralisierung zu einer Zahl. Derselbe Vorgang, zweimal ausgewertet: Mit bevorzugtem Team zeigt die Kandidatenliste 11 Personen aus NORD — ehrlich, aber zu wenige. Ohne Teamfilter werden es 28 aus allen Standorten, 17 davon frei, SÜD 11 und WEST 6. Und das Fenster ist datiert, vom 13. bis 27. Januar 2027. Damit ist die Frage „bringt eine zentrale Personalplanung überhaupt etwas\u0026quot; beantwortet, ohne dass jemand sie glauben muss. Das ist zugleich die einzige Unterdeckung des Bestandes, die sich durch eine Entscheidung auflösen lässt statt nur verschieben.\nEr schickt niemanden auf die Autobahn. Ob ein Maurer aus SÜD nach NORD fährt, wer die Kolonne dort ersetzt, was die Anfahrt kostet und welche Zusage am eigenen Standort dafür fällt — davon steht nichts im Plan und soll auch nichts darin stehen. Was er beiträgt: Die Alternative ist beziffert, bevor jemand entscheidet.\nDas Paket dahinter # Je Niederlassung ein Leitprojekt am eigenen Standort; das vierte Projekt ist die Großbaustelle Logistikzentrum Ostkamp der Niederlassung Nord, deren Rohbau-Spitze die Nord-Kolonnen überzieht.\nKennzahl Wert Beispielprojekte 5 Ressourcenpool 150 Personen in 17 Teams Leitprojekt Hafenquartier Nordmole (01.10.2026 – 08.03.2027) Umfang des Leitprojekts 16 Vorgänge, 5 Meilensteine, 20 Verknüpfungen Grundlast Laufende Baustellen bindet 0 Personen Engpass Maurer/in: 36 gegen 28 an 7 Tagen Der eigentliche Engpass steckt nicht in der Qualifikation, sondern im Team: Zwei parallele Mauerarbeiten der Großbaustelle verlangen 14 Maurer, die beiden Nord-Kolonnen haben 11. Mit dem bevorzugten Team zeigt die Kandidatenliste 11 Personen aus NORD, ohne Teamfilter 28 aus allen Standorten — 17 davon frei (SUED 11, WEST 6).\nGeplant sind alle Beispiele dieser Branche mit Rillsoft Project; die Produktseite zur Personaleinsatzplanung in der Rillsoft Cloud zeigt die Funktion außerhalb des Beispiels.\nDer eine Leitfall # Bevorzugtes Team führt die ganze Mechanik an diesem Fall vor: Mit Teamvorzug zeigt die Kandidatenliste die elf Personen aus Nord — ehrlich, aber zu wenige. Ohne den Filter werden es 28 aus allen Standorten, 17 davon frei. Der Plan macht aus der Standortfrage damit eine Entscheidung mit Zahlen: Kolonne ausleihen, Termin schieben oder Nachunternehmer — aber nicht mehr aus dem Bauchgefühl.\nDass ein Bauunternehmen seine Kolonnen nicht nur an Projekte verliert, sondern zuerst an das Tagesgeschäft, zeigt die Grundlast der laufenden Baustellen im Bauwesen. Wie aus einer offenen Stelle eine Kandidatenliste wird, steht am IT-Beispiel unter Kandidatenermittlung — und warum am Vorgang die Qualifikation stehen bleiben muss, damit das überhaupt geht, unter Rolle oder Person.\n","date":"8. September 2026","externalUrl":null,"permalink":"/baukonzern/","section":"Bau- und Infrastrukturkonzern","summary":"","title":"Bau- und Infrastrukturkonzern","type":"baukonzern"},{"content":"„Die Rolle ist voll ausgelastet\u0026quot; klingt nach Alarm. „Sie bindet ein Drittel unserer Leute\u0026quot; klingt nach Normalbetrieb. Beides kann derselbe Sachverhalt sein — es kommt darauf an, wogegen gerechnet wird.\nRillsoft Project bietet dafür zwei Darstellungen derselben Kapazitätsansicht. Sie beantworten verschiedene Fragen, nicht verschieden genau dieselbe.\nDas eigens gebaute Kleinprojekt führt zwei Rollen. Zur Bearbeitung gehören Anna Muster und Bernd Beispiel, zur Prüfung nur Clara Probe. In der ersten Woche arbeitet Anna, in der zweiten Clara; damit ist je Rolle genau eine Person belegt. Branche, Kunde und weitere Projekte bleiben aus dem Vergleich heraus.\nWie eng ist diese Rolle? # Bild 1 von 2 — Zwei Rollen, je eine belegte Person — und trotzdem zwei sehr verschiedene Zahlen. Die Darstellung Prozent je Rolle misst gegen die Kapazität DIESER Rolle: Bei der Prüfung gibt es nur eine Person, also steht sie bei 100 Prozent. Bei der Bearbeitung gibt es zwei, also steht sie bei 50.\nDer Nenner steht im Bild direkt darunter: Unter Bearbeitung hängen zwei Personen, unter Prüfung eine. In beiden Rollen arbeitet zum jeweiligen Zeitpunkt genau ein Mensch — Anna Muster in der ersten Woche, Clara Probe in der zweiten.\nDaraus werden 50 Prozent bei der Bearbeitung und 100 Prozent bei der Prüfung. Nicht weil Clara mehr arbeitet, sondern weil hinter ihr niemand mehr steht.\nDas ist die Zahl für die Frage „wo wird es eng\u0026quot;. Fällt Anna aus, kann Bernd übernehmen; fällt Clara aus, steht die Prüfung. Genau das sagen die beiden Zahlen, und zwar bevor jemand ausfällt.\nWie viel des Ganzen bindet sie? # Bild 2 von 2 — Dieselben Daten, dieselbe Belegung, ein anderer Nenner — und aus 100 gegen 50 wird zweimal 33 Prozent. Die Darstellung Prozent von allen misst gegen den GESAMTEN Pool: Drei Personen gibt es, eine je Rolle ist belegt.\nZwischen den Bildern hat sich am Plan nichts geändert. Dieselben Vorgänge, dieselben Personen, dieselben Termine — getauscht wurde nur, wogegen gerechnet wird. Und plötzlich stehen beide Rollen bei 33 Prozent, weil eine von drei Personen im Pool beschäftigt ist.\nDer Unterschied aus dem ersten Bild ist damit verschwunden. Das ist kein Fehler, sondern die Antwort auf eine andere Frage: „wie viel unseres Hauses steckt in diesem Projekt\u0026quot;. Für die Auslastungsplanung über mehrere Projekte ist das die richtige Zahl — für die Suche nach dem Engpass die falsche.\nWelche Darstellung wann? # Frage Darstellung Nenner Wo wird es eng? Wer hat keinen Ersatz? Prozent je Rolle die Kapazität dieser Rolle Wie viel unserer Leute bindet das Projekt? Prozent von allen der ganze Pool Zwei Fallen sind dabei häufig:\nProzent je Rolle über alle Rollen summieren. Das ergibt keine sinnvolle Zahl — jede Zeile hat einen anderen Nenner. Wer eine Gesamtzahl braucht, nimmt Prozent von allen. Prozent von allen für die Engpasssuche nehmen. Eine Rolle mit einer einzigen Person verschwindet dort in der Menge. Je größer der Pool, desto unauffälliger wird genau die Rolle, die als erste kippt. Eine dritte Darstellung, absolut, nennt direkt die Stunden oder Köpfe. Sie ist die ehrlichste, wenn der Nenner strittig ist — und die unhandlichste, wenn man vergleichen will.\nWie man zwischen diesen Ansichten im Alltag umschaltet und was sie an einem größeren Pool zeigen, steht unter Kapazitätsansichten steuern.\nWie Rillsoft Project Kapazitäten rechnet, steht auf der Produktseite zur Ressourcenplanung in der Rillsoft Cloud.\n","date":"6. September 2026","externalUrl":null,"permalink":"/grundlagen/prozentanteil-je-rolle/","section":"Grundlagen der Ressourcenplanung","summary":"","title":"Prozentanteil je Rolle","type":"grundlagen"},{"content":"Wer an zwei Standorten dieselben Qualifikationen vorhält, hat ein Problem, das kleinere Firmen nicht kennen: Fachlich könnte jeder überall arbeiten. Praktisch plant niemand so. Die Arbeit läuft mit der Mannschaft vor Ort, und erst wenn die nicht reicht, holt man jemanden von auswärts dazu.\nDiese Selbstverständlichkeit muss in der Planung stehen. Sonst rechnet die Software Leute als Angebot, die 300 Kilometer entfernt sitzen — mit demselben Recht wie die Kollegen im Nachbarbüro, weil sie die Qualifikation ja tatsächlich tragen. Und der Plan sieht machbar aus, obwohl er es vor Ort nicht ist.\nRillsoft Project löst das mit dem bevorzugten Team: einer Marke am Teilprojekt, die festlegt, wessen Kapazität darunter zählt. Gezeigt wird das hier an drei Personen an zwei Standorten. In der Praxis sind es einige hundert an einem halben Dutzend Niederlassungen — dort sieht man das Ergebnis, aber nicht mehr den Mechanismus.\nDer Bestand, um den es geht # Drei Personen, zwei Standorte, zwei Qualifikationen:\nStandort Nord Standort Süd Bearbeiter/in Anna Muster Bernd Beispiel Prüfer/in Clara Probe — Anna und Bernd tragen dieselbe Qualifikation, je einer je Standort. Genau das ist die Ausgangslage: Nichts an der Qualifikation unterscheidet die beiden. Der Unterschied ist der Ort.\nDer Plan dazu ist klein: zwei Teilprojekte mit zusammen vier Vorgängen und 144 Stunden. Jeder Vorgang verlangt eine Bearbeiterin oder einen Bearbeiter, acht Stunden am Tag — und keiner trägt einen Namen.\nTeilprojekt Vorgang Zeitraum Aufwand Auftrag Nord Vorarbeit Nord Mo 5. – Fr 9. Oktober 40 h Auftrag Nord Ausbau A Mo 12. – Do 15. Oktober 32 h Auftrag Nord Ausbau B Di 13. – Fr 16. Oktober 32 h Auftrag Süd Vorarbeit Süd Mo 5. – Fr 9. Oktober 40 h Zwei Dinge an diesem Plan sind Absicht. Erstens überlappen sich Ausbau A und Ausbau B drei Tage lang, am 13., 14. und 15. Oktober — nicht durch eine Verknüpfung, sondern allein durch ihre Anfangsdaten. An diesen drei Tagen braucht „Auftrag Nord\u0026quot; zwei Bearbeiter gleichzeitig. Zweitens ist niemand zugewiesen. Das ist die Bedingung, unter der diese Seite überhaupt etwas beweist: Was gleich an einer Person steht, ist vorgesehen, nicht zugewiesen — und vorgesehen wird sie allein über das bevorzugte Team ihres Teilprojekts.\nWo die Standortentscheidung sitzt # Bild 1 von 6 — Hier sitzt die Standortentscheidung — am Teilprojekt, nicht am Projekt und nicht am Vorgang. „Auftrag Nord\u0026quot; führt Standort Nord als bevorzugtes Team, und von hier vererbt sich der Vorzug auf alles, was darunter hängt: die Vorarbeit und die beiden Ausbauvorgänge. Oben steht derselbe Plan, um den es auf dieser ganzen Seite geht — vier Vorgänge, keiner davon mit einem Namen besetzt.\nDie Maske unten ist die des Teilprojekts — im Kopf steht „Auftrag Nord\u0026quot;, nicht der Name eines Vorgangs. Links führt sie alle Teams des Pools, beide mit der Arbeitsgruppe „Standort\u0026quot;: Nord und Süd. Rechts unter „Zugeordnete Teams\u0026quot; steht genau eines, 11.001 Standort Nord. Mehr ist die ganze Einstellung nicht: kein Häkchen an einem Vorgang, keine Menge, keine Auslastung.\nDie Marke steht damit über den Vorgängen, nicht in ihnen. Sie ist eine Aussage über das Vorhaben: Dieser Auftrag läuft im Norden. Unter „Auftrag Nord\u0026quot; hängen drei Vorgänge — die Vorarbeit in der ersten Oktoberwoche und die beiden Ausbauvorgänge in der zweiten —, und alle drei erben den Vorzug, ohne dass an ihnen etwas eingetragen wäre. Oben in der Tabelle sieht man das Gegenstück: Die Spalte „Aufwand\u0026quot; trägt 40, 32, 32 und 40 Stunden, und nirgends steht ein Name.\nBild 2 von 6 — Dasselbe Bild, das andere Teilprojekt — und genau darin liegt die Aussage. „Auftrag Süd\u0026quot; führt Standort Süd, während der Nachbar darüber Nord führt. Die Marke gehört dem Teilprojekt und nicht dem Projekt; deshalb kann ein Vorhaben an mehreren Standorten laufen, ohne dass jemand an jeder Zeile nachhelfen müsste.\nDasselbe Fenster, dieselbe Skala, derselbe Plan — gewechselt hat allein die Maske: jetzt „Auftrag Süd\u0026quot;, und rechts steht 11.002 Standort Süd. Legt man die beiden Bilder nebeneinander, ist der Unterschied genau eine Zeile in der rechten Liste. Das ist der Grund, warum die Marke am Teilprojekt sitzt und nicht am Projekt: Säße sie oben, könnten Nord und Süd keine verschiedenen Standorte führen.\n„Auftrag Süd\u0026quot; trägt nur die Vorarbeit in der ersten Woche. In der zweiten Woche steht dort nichts — und das ist keine Lücke im Beispiel, sondern seine Pointe: Bernd Beispiel, der einzige Bearbeiter im Süden, ist ab dem 12. Oktober frei.\nNach Rolle gerechnet: Es passt # Bild 3 von 6 — Dieselben vier Vorgänge, nach Qualifikation gerechnet — und diese Rechnung gibt Entwarnung. Der Pool führt zwei Bearbeiter/innen, und mehr als zwei werden nie gleichzeitig gebraucht: In der ersten Woche laufen die beiden Vorarbeiten nebeneinander, in der zweiten die beiden Ausbauvorgänge an drei Tagen. Die Auslastung erreicht 100 und nie mehr. Wer hier aufhört zu schauen, hält den Plan für machbar.\nSo liest man die Ansicht: Eine Zeile je Rolle, darunter die Vorgänge, die diese Rolle verlangen, als Balken. In der Rollenzeile steht je Tag der Bedarf in Stunden. Man kann jede Zahl nachrechnen:\n5. bis 9. Oktober: 16. Vorarbeit Nord und Vorarbeit Süd laufen nebeneinander, je 8 Stunden — zwei Bearbeiter gleichzeitig. 12. Oktober: 8. Nur Ausbau A hat begonnen. 13., 14. und 15. Oktober: 16. Ausbau A und Ausbau B überlappen sich — wieder zwei Bearbeiter gleichzeitig. 16. Oktober: 8. Ausbau B läuft allein aus. Die Spalte „Aufwand\u0026quot; summiert 40 + 32 + 32 + 40 = 144 Stunden. Die Spalte „Auslastung\u0026quot; setzt den höchsten Tagesbedarf ins Verhältnis zum Pool: 16 Stunden gegen zwei Bearbeiter/innen mit je 8 Stunden sind 100 Prozent — und nie mehr. Keine rote Zelle, kein Fehlbetrag. Die Rolle weiß nicht, wo ihre Träger sitzen; sie zählt Köpfe, nicht Orte.\nDie zweite Qualifikation des Pools, Prüfer/in, erscheint hier gar nicht: Kein Vorgang fordert sie, also gibt es für sie keine Zeile.\nNach Person gerechnet: Es passt immer noch # Bild 4 von 6 — Dieselben Daten, personenscharf — und immer noch Entwarnung. Ohne Gliederung nach Projekt rechnet die Ansicht gegen den ganzen Pool: Am 13., 14. und 15. Oktober stehen 16 geforderten Stunden 16 verfügbare gegenüber, je 8 bei Anna Muster und Bernd Beispiel. Darunter dieselben vier Vorgangsbalken wie in Bild 3; die Personenzeilen tragen ihre Verfügbarkeit, keine Last, denn zugewiesen ist niemand. Was diese Sicht nicht sieht, ist der Standort — und genau der entscheidet.\nDiese Ansicht hat drei Arten von Zeilen, und man muss sie auseinanderhalten:\nDie Rollenzeile oben trägt je Tag den Bedarf und daneben die Bilanz gegen das Angebot: „8 +8\u0026quot; am 12. Oktober heißt 8 Stunden gebraucht, 8 Stunden übrig; „16\u0026quot; am 13., 14. und 15. heißt 16 gebraucht, 16 vorhanden, nichts übrig; „+16\u0026quot; ab dem 19. heißt nichts gebraucht, 16 Stunden frei. Die Vorgangsbalken darunter sind dieselben vier wie in Bild 3. Die Personenzeilen am Ende, Anna Muster und Bernd Beispiel, zeigen ihre Verfügbarkeit: 8 Stunden an jedem Arbeitstag, aus ihrem Kalender. Sie zeigen keine Last, denn ihnen ist nichts zugewiesen. Das Angebot in der Bilanz ist die Summe dieser Personenzeilen: 8 + 8 = 16. Und genau da liegt der Punkt, an dem man sich täuschen kann. Die Personalkapazität kennt Anna und Bernd — und sagt trotzdem, alles sei in Ordnung. Solange die Ansicht nicht nach Projekt teilt, zählt jeder Bearbeiter für jeden Vorgang als Angebot, gleich an welchem Standort er sitzt. Acht plus acht ist sechzehn, und sechzehn werden gebraucht. Dass die eine Acht im Norden steht und die andere im Süden, kommt in dieser Rechnung nicht vor.\nNach Standort gerechnet: Es passt nicht # Bild 5 von 6 — Dasselbe noch einmal, nur nach Projekt und Rolle gegliedert — und die Entwarnung ist weg. Weil „Auftrag Nord\u0026quot; den Standort Nord bevorzugt, zählt unter ihm nur Anna Muster als Angebot: 8 Stunden gegen 16 geforderte am 13., 14. und 15. Oktober, Fehlbetrag −8, rot — über den drei Vorgangsbalken, die es verursachen. Unter „Auftrag Süd\u0026quot; steht Bernd Beispiel ab dem 12. Oktober mit +8 frei — dieselbe Qualifikation, der andere Standort. Zugewiesen ist weiterhin niemand.\nDie Gliederung teilt die Tabelle in zwei Blöcke, einen je Teilprojekt, und in jedem Block steht dieselbe Rolle noch einmal — jetzt aber nur mit dem Angebot des bevorzugten Teams. Unter „Auftrag Nord\u0026quot; ist das allein Anna Muster, unter „Auftrag Süd\u0026quot; allein Bernd Beispiel. Die Rollenzeilen liest man wie in Bild 4, nur mit diesem kleineren Angebot:\nUnter Nord, 5. bis 9. Oktober: 8. Die Vorarbeit Nord braucht 8, Anna hat 8 — gedeckt. Unter Nord, 13., 14. und 15. Oktober: 16 −8, rot. Beide Ausbauvorgänge brauchen zusammen 16, Anna hat 8. Es fehlen 8 Stunden am Tag, drei Tage lang — die Zelle ist als Unterdeckung markiert. Unter Nord, ab dem 19. Oktober: +8. Nichts mehr zu tun, Anna ist frei. Unter Süd, 5. bis 9. Oktober: 8. Die Vorarbeit Süd, gedeckt durch Bernd. Unter Süd, ab dem 12. Oktober: +8. Kein Vorgang mehr — Bernd steht mit 8 Stunden am Tag frei, auch an den drei Tagen, an denen im Norden 8 fehlen. Die drei Vorgangsbalken unter Nord und der eine unter Süd sind dieselben wie in Bild 3 und 4. Die Stundenwerte sind dieselben. Die Personen sind dieselben. Verschieden ist allein, ob der Standort mitgerechnet wird — und sobald er es wird, ist aus „passt\u0026quot; ein Fehlbetrag geworden, dem im Nachbarblock ein gleich großer Überschuss gegenübersteht.\nnach Rolle (Bild 3) nach Person (Bild 4) nach Standort (Bild 5) Bedarf am 13.–15.10. 16 h 16 h 16 h unter Nord Angebot 2 Köpfe Anna 8 h + Bernd 8 h nur Anna, 8 h Ergebnis 100 %, unauffällig 16 = 16, passt −8 h, daneben +8 h unter Süd Alle drei Spalten rechnen mit denselben vier Vorgängen und denselben drei Personen. Nur die dritte weiß, dass Anna im Norden sitzt und Bernd im Süden.\nDieselbe Rechnung, von der Rolle her gelesen # Bild 6 von 6 — Dieselbe Unterdeckung, von der anderen Seite betrachtet. Bild 5 fragte „was trägt dieser Standort\u0026quot;, dieses hier fragt „wo geht diese Qualifikation hin\u0026quot;: Oben eine einzige Rollenzeile für alle 144 Stunden, darunter je Teilprojekt eine Zeile. Der Fehlbetrag von −8 an den drei Oktobertagen hängt an „Auftrag Nord\u0026quot;, während „Auftrag Süd\u0026quot; ab dem 12. Oktober +8 frei meldet. Wer wissen will, welche Qualifikation knapp ist und an welchem Ort, liest diese Reihenfolge; wer wissen will, was ein Standort noch trägt, die aus Bild 5.\nDie Gliederung ist umgedreht: erst die Rolle, dann das Projekt. Oben steht 11.001 Bearbeitung – Bearbeiter/in ein einziges Mal, mit dem ganzen Aufwand von 144 Stunden; darunter „Auftrag Nord\u0026quot; mit 104 und „Auftrag Süd\u0026quot; mit 40. Die Zahlen in den Tageszellen sind dieselben wie in Bild 5 — 16 −8 unter Nord am 13., 14. und 15. Oktober, +8 unter Süd ab dem 12. Oktober —, nur dass sie jetzt unter einer gemeinsamen Rollenzeile stehen statt in zwei getrennten Blöcken.\nDer Unterschied ist die Frage, mit der man an die Tabelle geht:\nProjekt vor Rolle (Bild 5) beantwortet „was trägt dieser Standort?\u0026quot; — man geht die Blöcke durch und sieht je Teilprojekt, welche Qualifikationen dort knapp sind. Rolle vor Projekt (Bild 6) beantwortet „wo geht diese Qualifikation hin?\u0026quot; — man nimmt eine Rolle und sieht, an welchem Standort sie fehlt und an welchem sie frei ist. Für eine Rolle, die an mehreren Standorten gebraucht wird, ist das die kürzere Lesart: Fehlbetrag und Überschuss stehen untereinander. Beide Reihenfolgen rechnen gleich; weicht ein Wert ab, stimmt etwas am Plan und nicht an der Ansicht.\nWas das für die Planung heißt # Drei Dinge folgen daraus:\nDie Marke steht oben, nicht unten. Einmal am Teilprojekt gesetzt, wirkt sie auf jeden Vorgang darunter. Wer sie an jeder Zeile pflegen müsste, würde sie nicht pflegen. Weder Rolle noch Person sehen den Standort. Beide Ansichten rechnen gegen den ganzen Pool und geben eine Entwarnung, die vor Ort nicht gilt. Erst die nach Projekt geteilte Kapazitätssicht zählt, was der Standort wirklich trägt. Standorttreu ohne Namen. Der Plan bleibt am richtigen Ort, auch wenn noch niemand eingetragen ist — und der Engpass ist sichtbar, bevor ein Name fällt. Wie Qualifikation und Name zusammenspielen, steht unter Rolle oder Person. Die Reihenfolge, die sich daraus ergibt, ist die, die ein Bauleiter ohnehin im Kopf hat: erst die eigene Mannschaft, dann der Nachbarstandort, und erst danach von außen.\nWie das mit 150 Personen an drei Niederlassungen aussieht — 11 Kandidaten gegen 28, und ein Standort, der wirklich ausgereizt ist —, zeigt das Branchenbeispiel Bevorzugtes Team am Beispiel Baukonzern.\nWie Rillsoft Project Personaleinsatz über Standorte hinweg plant, steht auf der Produktseite zur Personaleinsatzplanung in der Rillsoft Cloud.\n","date":"10. September 2026","externalUrl":null,"permalink":"/grundlagen/standortbezogene-planung/","section":"Grundlagen der Ressourcenplanung","summary":"","title":"Standortbezogene Planung","type":"grundlagen"},{"content":" Ein Teilprojekt und ein Meilenstein haben eines gemeinsam: Beide können in Rillsoft Project festgemacht werden. Was das bedeutet, sieht man nicht am Häkchen, sondern erst, wenn sich etwas ändert. Deshalb macht diese Seite dreimal denselben Griff — einmal ohne Fixierung, einmal mit fixiertem Teilprojekt, einmal mit fixiertem Meilenstein — und zeigt, was er jedes Mal auslöst.\nDie Antwort vorweg: Unfixiert folgt alles den Vorgängen. Der Meilenstein wandert mit, das Teilprojekt wächst mit. Das fixierte Teilprojekt hält seinen Rahmen, und die Kinder ragen darüber hinaus. Der fixierte Meilenstein lässt den Griff gar nicht zu — Rillsoft Project lehnt ihn mit einer Meldung ab.\nDer Bestand, um den es geht # Ein Teilprojekt mit zwei Vorgängen und einem Meilenstein am Ende:\nElement Aufwand Termin Teilprojekt „Entwurfsphase\u0026quot; — Mo 5. – Fr 9. Oktober Konzept erstellen (Anna Muster) 32 h Mo 5. – Do 8. Oktober Entwurf prüfen (Bernd Beispiel) 32 h Di 6. – Fr 9. Oktober Meilenstein „Entwurf freigegeben\u0026quot; — Fr 9. Oktober Zwei Dinge daran sind Absicht. Erstens sind die beiden Vorgänge nicht miteinander verknüpft: Sie liegen um einen Tag versetzt nebeneinander, weil jeder seinen eigenen Anfang hat. Nur der Meilenstein hängt an „Entwurf prüfen\u0026quot; und steht deshalb an dessen Ende. Zweitens hat das Teilprojekt keinen eigenen Termin: Sein Balken vom 5. bis 9. Oktober ist die Hülle seiner drei Kinder, fünf Arbeitstage lang.\nDer Griff, der dreimal gemacht wird, ist immer derselbe: „Entwurf prüfen\u0026quot; wird an „Konzept erstellen\u0026quot; gehängt. Damit kann Vorgang 2 erst beginnen, wenn Vorgang 1 endet — er müsste vom 9. auf den 14. Oktober rücken, der Meilenstein mit ihm, und das Teilprojekt von fünf auf acht Arbeitstage wachsen. Ob das passiert, entscheidet allein, was fixiert ist.\nNichts fixiert: alles wandert mit # Bild 1 von 6 — Die Ausgangslage, und in ihr ist nichts festgemacht. „Konzept erstellen\u0026quot; läuft vom 5. bis 8., „Entwurf prüfen\u0026quot; vom 6. bis 9. Oktober, um einen Tag versetzt und ohne Verknüpfung zwischen beiden. Nur der Meilenstein hängt an Vorgang 2 und steht deshalb am 9. Oktober. Das Teilprojekt „Entwurfsphase\u0026quot; hat keinen eigenen Termin: Sein Balken ist die Hülle seiner drei Kinder, vom 5. bis 9. Oktober, fünf Arbeitstage. Die Maske darunter zeigt es — Anfang und Ende stehen da, aber das Häkchen Festlegen ist leer. Alles, was hier steht, steht dort, weil es aus den Vorgängen folgt.\nDem Balkenplan allein sieht man nicht an, dass nichts fixiert ist. Deshalb steht die Maske des Teilprojekts dabei: Anfang 5. Oktober, Ende 9. Oktober — und das Häkchen Festlegen darunter ist leer. Die beiden Termine sind also abgelesen, nicht gesetzt. Ob sie so bleiben, entscheidet sich erst beim nächsten Griff. Dieselbe Maske mit gesetztem Häkchen zeigt Bild 3.\nBild 2 von 6 — Dieselbe Ansicht, nachdem Vorgang 2 an Vorgang 1 gehängt wurde — ein einziger Pfeil mehr, und drei Dinge haben sich bewegt. „Entwurf prüfen\u0026quot; beginnt jetzt, wenn „Konzept erstellen\u0026quot; endet, und läuft vom 9. bis 14. Oktober. Der Meilenstein hängt an Vorgang 2 und ist mitgewandert: vom 9. auf den 14. Oktober. Und das Teilprojekt, das keinen eigenen Termin hat, ist mitgewachsen: vom 5. bis 14. Oktober, acht statt fünf Arbeitstage. Nichts hat dagegengehalten, weil nichts fixiert war.\nDas ist das Normalverhalten, und es ist meistens das gewünschte: Der Plan rechnet nach, und die Termine, die aus der Arbeit folgen, folgen der Arbeit. Der Meilenstein sagt jetzt „14. Oktober\u0026quot;, weil die Freigabe eben erst dann möglich ist. Die Frage ist nur, ob man das wollte — oder ob der 9. Oktober jemandem zugesagt war.\nTeilprojekt fixiert: der Rahmen bleibt # Bild 3 von 6 — Dieselbe Ausgangslage wie in Bild 1, mit einem Unterschied, den man nur in der Maske sieht: Das Teilprojekt ist fixiert. Die Maske darunter ist die des Teilprojekts — im Kopf steht „Entwurfsphase\u0026quot; —, und dort sitzt die Einstellung: Anfang 5. Oktober, Ende 9. Oktober und das Häkchen Festlegen, das in Bild 1 leer war. Der Balkenplan darüber ist derselbe. Damit hat das Teilprojekt zum ersten Mal einen eigenen Termin. Bis hierhin war sein Balken die Hülle seiner Kinder; von jetzt an ist er ihr Rahmen.\nDie Fixierung verschiebt nichts. Die Balken liegen auf denselben Tagen wie in Bild 1, und das Teilprojekt steht auf denselben fünf Tagen. Geändert hat sich, woher diese fünf Tage kommen: nicht mehr aus den Kindern, sondern aus der Maske. Sichtbar ist das nur an einer Stelle, am Häkchen Festlegen unter Anfang und Ende. Der Balkenplan selbst zeichnet ein festgemachtes Teilprojekt nicht anders als ein bewegliches — legt man Bild 1 und Bild 3 nebeneinander, ist der Unterschied allein das Häkchen.\nBild 4 von 6 — Derselbe Griff wie in Bild 2, mit fixiertem Teilprojekt — und diesmal hält etwas dagegen. Vorgang 2 rückt wie zuvor auf den 9. bis 14. Oktober, der Meilenstein wandert auf den 14. mit. Das Teilprojekt aber bleibt bei 5. bis 9. Oktober: In der Spalte Ende steht weiterhin der 9., der Balken ist keinen Tag länger geworden. Stattdessen zieht Rillsoft Project in der Teilprojektzeile eine rote Linie vom fixierten Ende bis zum 14. Oktober — so weit ragen die Kinder über den Rahmen hinaus. Das ist der Unterschied zwischen Hülle und Rahmen: Die Hülle folgt den Kindern, der Rahmen nicht.\nEin fixiertes Teilprojekt verbietet den Griff nicht. Es hält fest, was vereinbart war, und macht sichtbar, dass die Planung darüber hinausgeht: Die rote Linie beginnt am 9. Oktober, wo der Rahmen endet, und reicht bis zum 14., wo die Kinder wirklich enden. Wer die Entwurfsphase bis zum 9. Oktober zugesagt hat, sieht hier auf einen Blick, dass die Zusage mit dieser Verknüpfung nicht mehr hält — ohne dass der Plan sie stillschweigend aufgegeben hätte. Die Spalte Aufwand steht unverändert auf 64 Stunden; verschoben wurde, nicht verlängert.\nMeilenstein fixiert: der Griff wird abgelehnt # Bild 5 von 6 — Noch einmal die Ausgangslage aus Bild 1, diesmal mit fixiertem Meilenstein. Die Maske ist die des Meilensteins — im Kopf steht „Entwurf freigegeben\u0026quot; —, und dort steht der Termin, 9. Oktober 17:00, mit dem Häkchen Fixieren, gleich neben „Als Meilenstein markieren\u0026quot;. Das Teilprojekt ist nicht fixiert; es bleibt die Hülle seiner Kinder. Der Unterschied zu Bild 3 ist die Stelle, an der festgemacht wird: dort der Rahmen um alles, hier ein einzelner Termin am Ende der Kette.\nEin Meilenstein hat keine Dauer, also nur einen Termin — und den hält das Häkchen fest. Dass es an einem Meilenstein von Haus aus gesetzt ist, sieht man dieser Maske nicht an; für Bild 1 wurde es ausdrücklich gelöst, damit die Raute der Kette folgen konnte.\nBild 6 von 6 — Derselbe Griff wie in Bild 2 und 4 — und diesmal kommt er nicht durch. „Entwurf prüfen\u0026quot; müsste hinter „Konzept erstellen\u0026quot; rücken und bis zum 14. Oktober laufen; der Meilenstein dahinter ist aber am 9. Oktober festgemacht und lässt sich nicht schieben. Rillsoft Project hält den Befehl an und fragt: Der letzte Befehl führt zum Verschieben des fixierten Vorgangs „1.3 Entwurf freigegeben\u0026quot; vom 9. auf den 14. Oktober — soll er ausgeführt werden? Mit „Nein\u0026quot; bleibt alles, wie es war: kein Pfeil zwischen Vorgang 1 und 2, Vorgang 2 weiter vom 6. bis 9., die Raute am 9. Mit „Ja\u0026quot; wanderte der Meilenstein mit. Genau das ist die Aussage: Ein fixierter Termin ist kein Hinweis, sondern eine Grenze, die nur der Planer selbst aufhebt.\nDie Meldung sagt genau, woran es liegt. Sie nennt das Element, das sich bewegen müsste, die beiden Termine und stellt die Frage, die nur ein Mensch beantworten kann:\nDer letzte Befehl führt zum Verschieben der fixierten Vorgänge. Vorgang: 1.3 Entwurf freigegeben, von: 09.10.26 17:00, auf: 14.10.26 17:00. Wollen Sie den Befehl ausführen?\nMit „Nein\u0026quot; wird der Befehl zurückgerollt: Nicht nur die Verknüpfung fehlt, auch alles, was sie nach sich gezogen hätte, ist nicht passiert. Der Plan ist in dem Zustand, in dem er vor dem Griff war — der hinter dem Kasten. Mit „Ja\u0026quot; gäbe der Planer die Fixierung für diesen einen Befehl auf, und der Meilenstein wanderte wie in Bild 2 auf den 14. Oktober.\nDas ist der eigentliche Unterschied zwischen den beiden Fixierungen. Das fixierte Teilprojekt lässt den Griff zu und zeigt die Folge. Der fixierte Meilenstein lässt ihn nicht zu: Die Verknüpfung würde ihn verschieben müssen, und ein fixierter Termin wird nicht verschoben. Wer sie trotzdem will, muss zuerst entscheiden, was gelten soll — der Termin oder die Reihenfolge — und eines von beiden ändern.\nnichts fixiert (Bild 2) Teilprojekt fixiert (Bild 4) Meilenstein fixiert (Bild 6) Vorgang 2 9. – 14. Oktober 9. – 14. Oktober bleibt 6. – 9. Oktober Meilenstein 14. Oktober 14. Oktober bleibt 9. Oktober Teilprojekt 5. – 14. Oktober, 8 Tage bleibt 5. – 9. Oktober, rote Linie bis zum 14. bleibt 5. – 9. Oktober Der Griff angenommen angenommen abgelehnt, zurückgerollt Was das für die Planung heißt # Fixieren heißt entscheiden, was gelten soll. Ein Termin, der von außen kommt, gehört fixiert — ein Abgabetermin, ein Ferienfenster, eine Zusage. Ein Termin, der aus der Arbeit folgen soll, gehört nicht fixiert, sonst meldet der Plan bei jeder Änderung einen Konflikt statt eines Ergebnisses. Teilprojekt und Meilenstein fixieren verschieden hart. Das Teilprojekt ist ein Rahmen: Es lässt die Überschreitung zu und zeigt sie. Der Meilenstein ist eine Grenze: Er lässt sie nicht zu. Neu angelegt ist fixiert. Rillsoft Project legt Teilprojekte und Meilensteine festgemacht an. Wer die Hülle und den mitwandernden Meilenstein aus Bild 1 und 2 will, löst die Fixierung ausdrücklich. Wie Fixierung im Zusammenspiel mit Kalender und Ferienfenstern aussieht, zeigt das Branchenbeispiel Zwangstermine und Ferienfenster in der öffentlichen Verwaltung. Was Reserve und kritischer Pfad an derselben Kette anzeigen, steht unter Reservezeit und kritischer Pfad.\nWie sich derselbe Funktionsumfang außerhalb der Beispiele darstellt, steht auf der Produktseite zum Projektmanagement in der Rillsoft Cloud.\n","date":"11. September 2026","externalUrl":null,"permalink":"/grundlagen/teilprojekt-meilenstein-fixierung/","section":"Grundlagen der Ressourcenplanung","summary":"","title":"Teilprojekt und Meilenstein fixieren","type":"grundlagen"},{"content":" Elf Themen dieses Bereichs rechnen in einem Projekt. Dieses hier rechnet in dreien — und zeigt, was sich ändert, wenn dieselben drei Vorgänge nicht in einer Datei stehen, sondern in drei, und diese drei auf denselben Pool zugreifen. Das ist ein Portfolio: keine neue Planung, sondern die gemeinsame Rechnung mehrerer Vorhaben.\nDie Antwort vorweg: Für sich genommen ist jedes der drei Projekte unauffällig. Jedes braucht eine Bearbeiterin und eine Prüferin, jedes hat sie. Erst das Portfolio zeigt, dass die eine Prüferin im Pool drei Wochen lang ohne Lücke gefordert ist — und je nachdem, ob man die Ansicht nach Rolle oder nach Projekt gliedert, beantwortet sie eine andere Frage.\nDer Bestand, um den es geht # Drei Projekte, jedes die bekannte Kette aus drei Vorgängen, um je eine Woche versetzt. Jeder Vorgang trägt seine Rolle; in Alpha und Beta stehen zusätzlich Personen, in Gamma nicht. Am Ende jedes Projekts steht ein fixierter Meilenstein.\nProjekt Anfang Konzept erstellen (40 h, Bearbeiter/in) Entwurf prüfen (40 h, Prüfer/in) Freigabe erteilen (16 h, Bearbeiter/in) Meilenstein Projekt Alpha Mo 5. Oktober 5.–9.10., Anna Muster 12.–16.10., Clara Probe 19.–20.10., Anna Muster 20. Oktober Projekt Beta Mo 12. Oktober 12.–16.10., Bernd Beispiel 19.–23.10., Clara Probe 26.–27.10., Bernd Beispiel 27. Oktober Projekt Gamma Mo 19. Oktober 19.–23.10., nur Rolle 26.–30.10., nur Rolle 2.–3.11., nur Rolle 3. November Jedes Projekt trägt außerdem einen Kunden und eine Kategorie aus dem Pool: Alpha und Gamma gehören der Musterkunde AG, Beta der Beispielkunde GmbH; Alpha und Beta sind Entwicklung, Gamma ist Wartung. Beides steht in der Projektmaske (Bild 1 bis 3) und ist die Grundlage dafür, ein Portfolio später nach Kunde oder Kategorie zu gliedern.\nDer Pool ist derselbe wie auf allen Grundlagenseiten: Anna Muster und Bernd Beispiel als Bearbeiter/in, Clara Probe als einzige Prüfer/in. Das ist die Zahl, auf die es ankommt — eine Prüferin, drei Projekte, die je eine Woche lang prüfen lassen.\nDrei Projekte, drei Dateien # Bild 1 von 20 — Das erste der drei Projekte, für sich allein. „Konzept erstellen\u0026quot; läuft vom 5. bis 9. Oktober bei Anna Muster, „Entwurf prüfen\u0026quot; vom 12. bis 16. bei Clara Probe, „Freigabe erteilen\u0026quot; am 19. und 20. wieder bei Anna; jeder Vorgang trägt seine Rolle, und am 20. Oktober steht der fixierte Meilenstein „Alpha freigegeben\u0026quot;. Die Maske darunter ist die des Projekts — im Kopf steht „Projekt Alpha\u0026quot;, Anfang 5. Oktober, Kategorie Entwicklung, Kunde Musterkunde AG. Was hier fehlt, ist nicht zu sehen: dass in zwei Wochen ein zweites und ein drittes Projekt dieselben Leute brauchen.\nBild 2 von 20 — Das zweite Projekt — eine andere Datei, nicht eine Änderung an Alpha. Dieselbe Kette, dieselben Stunden, um eine Woche versetzt: „Konzept erstellen\u0026quot; vom 12. bis 16. Oktober bei Bernd Beispiel, „Entwurf prüfen\u0026quot; vom 19. bis 23. wieder bei Clara Probe, „Freigabe erteilen\u0026quot; am 26. und 27. bei Bernd, die fixierte Raute am 27. Oktober. Im Kopf der Maske steht „Projekt Beta\u0026quot;, darunter Kategorie Entwicklung und ein anderer Kunde: Beispielkunde GmbH. Wer beide Bilder nebeneinanderlegt, sieht schon, was keines von beiden zeigt: Clara Probe prüft in Alpha bis zum 16. und in Beta ab dem 19. Oktober — in zwei Dateien, die voneinander nichts wissen.\nBild 3 von 20 — Das dritte Projekt, wieder eine andere Datei, und wieder eine Woche später: „Konzept erstellen\u0026quot; vom 19. bis 23. Oktober, „Entwurf prüfen\u0026quot; vom 26. bis 30., „Freigabe erteilen\u0026quot; am 2. und 3. November, die fixierte Raute am 3. November. Die Maske sagt Kategorie Wartung und Kunde Musterkunde AG — derselbe Kunde wie Alpha, eine andere Projektart. Der Unterschied zu den beiden anderen steht in der Spalte Personal: Sie ist leer. Gamma sagt nur, was gebraucht wird — eine Bearbeiterin oder ein Bearbeiter, eine Prüferin —, nicht wer. Das ist der Normalfall in einer frühen Planung, und im Portfolio wird daraus eine Frage: Ist im Pool noch jemand frei, wenn Gamma anfängt?\nDrei Dateien, drei Balkenpläne, und in keinem steht etwas Beunruhigendes. Jedes Projekt fordert je Woche eine Person einer Qualifikation, und der Pool hat von jeder Qualifikation mindestens eine. Der Planer von Alpha sieht Alpha, der von Gamma sieht Gamma. Dass Clara Probe in Alpha bis zum 16., in Beta ab dem 19. und in Gamma ab dem 26. Oktober prüfen soll, steht in keiner der drei Dateien — es steht in allen dreien zusammen.\nDas Portfolio: eine Achse für alle drei # Bild 4 von 20 — Dieselben drei Projekte, jetzt in einer Datei: dem Portfolio. Das ist keine vierte Planung, sondern eine Liste der drei — und trotzdem ändert sich mit ihr alles, was zu sehen ist. Drei Zeilen, drei Balken, um je eine Woche versetzt: Alpha vom 5. bis 20. Oktober, Beta vom 12. bis 27., Gamma vom 19. Oktober bis 3. November. Zum ersten Mal steht auf einer Achse, dass sich die drei überlappen — in der Woche vom 19. Oktober laufen alle drei zugleich. Zugeklappt sieht man das Wann; das Wer kommt in den nächsten Bildern.\nEin Portfolio ist in Rillsoft Project wörtlich eine Liste: eine Datei, die die drei Projektdateien nennt. Die Projekte bleiben, was sie sind — eigene Dateien mit eigenen Terminen und eigenen Meilensteinen. Neu ist, dass sie gemeinsam geöffnet und gemeinsam gerechnet werden. Zugeklappt zeigt der Balkenplan das Wesentliche der Zeitachse: Die drei Vorhaben überlappen sich zwei Wochen lang.\nBild 5 von 20 — Dasselbe Bild wie zuvor, mit einer einzigen Darstellungsoption mehr: „Meilensteine in Teilprojekt darstellen\u0026quot;. Jeder Projektbalken trägt jetzt an seinem Ende die Raute seines fixierten Meilensteins — Alpha am 20. Oktober, Beta am 27. Oktober, Gamma am 3. November —, obwohl die Meilensteinzeilen selbst in den zugeklappten Projekten verborgen bleiben. Der Balken sagt, wie lange gearbeitet wird; die Raute sagt, was am Ende zugesagt ist. Drei Balken, drei Rauten, drei Zusagen — und noch ohne die Linien, die zeigen, wen jede Zusage schneidet.\nDie Raute gehört zum Projekt, nicht zur Zeile: Sie steht am Balken, weil das Projekt einen fixierten Endtermin hat — ganz gleich, ob seine Zeilen auf- oder zugeklappt sind. Wer nur die drei Zusagen sehen will, braucht die Vorgänge dafür nicht.\nBild 6 von 20 — Dasselbe Bild wie zuvor, mit einer weiteren Darstellungsoption: „Meilensteine in Kalenderleiste anzeigen\u0026quot; hebt die drei Termine von den Balkenenden — 20. Oktober, 27. Oktober, 3. November — zusätzlich als Rauten oben in die Zeitleiste, von jeder eine senkrechte Linie durch die drei Projektzeilen, obwohl die Meilensteine selbst in den zugeklappten Projekten verborgen sind. Drei Zeilen, drei Balken, drei Zusagen: Das ist das Portfolio auf einen Blick — und jede Linie schneidet die Balken der anderen Projekte.\nDie zweite Option holt die Zusagen in die Leiste, ohne die Projekte aufzuklappen: Drei Rauten oben, drei Linien durch drei Balken. Wer wissen will, wann was fertig sein muss und wer dann noch mitten in der Arbeit ist, braucht keine weitere Zeile.\nBild 7 von 20 — Dieselbe Datei, aufgeklappt — und jetzt stehen die neun Vorgänge untereinander, die vorher in drei Dateien lagen. Jede Kette hat dieselbe Form, nur um eine Woche verschoben, und die Spalte Personal zeigt den Unterschied zwischen den Projekten: Alpha und Beta tragen Namen, Gamma nur Rollen. Die Kalenderleiste trägt weiter die drei Rauten, und ihre senkrechten Linien laufen jetzt durch alle zwölf Zeilen: An der Linie vom 20. Oktober ist zu sehen, dass Betas Prüfung und Gammas Konzept mitten in der Arbeit sind, wenn Alpha abgenommen wird. Wer hier die Zeilen mit „Clara Probe\u0026quot; sucht, findet zwei, die sich nicht überschneiden — bis 16. Oktober in Alpha, ab 19. Oktober in Beta. Was der Balkenplan nicht zeigt: dass Gamma ab dem 26. Oktober ebenfalls eine Prüferin braucht, und dass es im Pool nur eine gibt.\nAufgeklappt ist das Portfolio ein Balkenplan mit zwölf Zeilen, und die Frage nach der Prüferin lässt sich darin schon stellen, aber schlecht beantworten: Man müsste die drei Zeilen „Entwurf prüfen\u0026quot; suchen, ihre Wochen vergleichen und wissen, dass Gamma dieselbe Rolle meint wie Alpha und Beta. Der Balkenplan sortiert nach Projekt. Für die Frage nach der Qualifikation braucht es eine Ansicht, die nach Qualifikation sortiert.\nDie Rollenauslastung: nach Qualifikation statt nach Projekt # Bild 8 von 20 — Dieselben neun Vorgänge, jetzt nach Qualifikation sortiert statt nach Projekt. Die Ansicht wechselt vom Balkenplan in die Rollenauslastung: Oben die Bearbeiter/innen mit sechs Vorgangsbalken darunter, dann die Prüfer/in mit dreien. In den Zellen steht je Tag, wie viele Stunden die Rolle gefordert ist — bei den Bearbeitern am 19. und 20. Oktober 16, weil Alphas Freigabe und Gammas Konzept zusammentreffen, sonst 8; bei der Prüferin vom 12. bis 30. Oktober jeden Tag 8, drei Wochen ohne Lücke. Die Rolle weiß nicht, aus welchem Projekt ein Vorgang kommt — und genau das ist hier die Stärke: Der Bedarf zählt über alle drei.\nZwei Zeilen statt zwölf, und die Frage ist beantwortet. Die Rolle Prüfer/in ist vom 12. bis 30. Oktober an jedem Arbeitstag mit 8 Stunden gefordert — drei Wochen, aus drei Projekten, ohne einen Tag dazwischen. Der Pool hat für diese Rolle eine Person. Das geht auf, aber nur, wenn nichts dazwischenkommt: kein Urlaubstag, keine Verschiebung in Alpha, die „Entwurf prüfen\u0026quot; in die Woche von Beta drückt. Bei den Bearbeitern stehen am 19. und 20. Oktober 16 Stunden, weil Alphas Freigabe und Gammas Konzept zusammentreffen — zwei Köpfe im Pool, zwei gefordert, ebenfalls ohne Luft.\nDass Gamma nur Rollen trägt, spielt für diese Rechnung keine Rolle: Die Rollenauslastung fragt, was gebraucht wird, nicht, wer eingetragen ist. Gammas Bedarf steht in derselben Zeile wie der von Alpha und Beta.\nDieselbe Ansicht, zwei Reihenfolgen # Bild 9 von 20 — Eine Gliederungsebene mehr, und die Rolle bekommt eine Adresse. Unter jeder der beiden Rollenzeilen stehen jetzt die drei Projekte, und unter jedem Projekt seine Vorgänge: Bei den Bearbeitern zwei je Projekt, bei der Prüferin einer je Projekt. Die Summenzeile der Rolle ist dieselbe wie in Bild 8 — die 16 am 19. und 20. Oktober steht weiter oben —, aber darunter ist zu lesen, wer sie verursacht: Alpha mit der Freigabe, Gamma mit dem Konzept. Das ist die Reihenfolge für die Frage „wohin geht diese Qualifikation, und welches Projekt müsste nachgeben\u0026quot;.\nBild 10 von 20 — Die Gliederung umgedreht — erst das Projekt, dann die Rolle —, und die Ansicht beantwortet die andere Frage: nicht „wohin geht die Qualifikation\u0026quot;, sondern „was braucht dieses Projekt\u0026quot;. Unter jedem der drei Projekte stehen seine beiden Rollen mit ihren Vorgängen, und die Zahlen je Projekt sind die aus dem Einzelprojekt: 8 je Tag, nie mehr. Was hier verloren geht, ist die Summe über die Projekte — die 16 am 19. und 20. Oktober gibt es in dieser Reihenfolge nicht mehr, weil sie zwei Projekten gehört. Deshalb braucht ein Portfolio beide Reihenfolgen: Rolle zuerst für den Engpass, Projekt zuerst für den Bedarf.\nDie beiden Bilder tragen dieselben Zahlen; verschieden ist nur, welche Zeile oben steht. Rolle vor Projekt hält den Bedarf der Qualifikation als Überschrift und zeigt darunter, welches Vorhaben wie viel davon bindet — das ist die Ansicht, wenn eine Rolle knapp ist und jemand entscheiden muss, welches Projekt nachgibt. Projekt vor Rolle hält das Vorhaben als Überschrift und zeigt darunter, welche Qualifikationen es braucht — das ist die Ansicht, wenn ein Projekt beginnt und jemand wissen will, wen es fordert. In der zweiten Reihenfolge gibt es die 16 vom 19. Oktober nicht mehr: Sie gehört zwei Projekten und steht deshalb unter keinem.\nFrage Gliederung Bild Wann laufen die Projekte, und wo überlappen sie sich? Balkenplan des Portfolios 4 und 7 Bis wann — wo liegen die fixierten Endtermine? Balkenplan, Meilensteine am Balkenende und in der Kalenderleiste 5 bis 7 Wie viel wird von einer Qualifikation gefordert, über alle Projekte? Rolle, flach 8 Welches Projekt bindet die knappe Qualifikation? Rolle → Projekt 9 Welche Qualifikationen braucht dieses Projekt? Projekt → Rolle 10 Was bindet ein Kunde insgesamt, je Qualifikation? Kunde → Rolle 11 Welche Projekte hat ein Kunde, und was brauchen sie? Kunde → Projekt → Rolle 12 Welche Projekte dieses Kunden fordern die knappe Qualifikation? Kunde → Rolle → Projekt 13 Wie viel Arbeit steckt in einer Kategorie, je Qualifikation? Kategorie → Rolle 14 Welche Projekte gehören zu einer Kategorie, und was brauchen sie? Kategorie → Projekt → Rolle 15 Wer ist wann eingeplant — und wo ist noch niemand? Person, flach 16 Für welche Projekte arbeitet diese Person? Person → Projekt 17 Wer arbeitet an diesem Projekt? Projekt → Person 18 Welche Menschen arbeiten für diesen Kunden — und welches seiner Projekte ist unbesetzt? Kunde → Projekt → Person 19 Welche Menschen stecken in einer Kategorie? Kategorie → Projekt → Person 20 Eine Ebene darüber: Kunde und Kategorie # Bild 11 von 20 — Der Kunde als oberste Ebene, direkt darunter die Rolle — ohne den Umweg über das Projekt. Die Musterkunde AG bindet 192 Stunden, aus Alpha und Gamma zusammengezählt, je Qualifikation in einer Zeile; die Beispielkunde GmbH 96. Das ist die Antwort auf die Frage, was ein Kunde bindet, wenn es nicht darauf ankommt, in welchem seiner Vorhaben. Unter den Bearbeiter/innen der Musterkunde AG stehen sechs Vorgänge: drei aus Alpha, drei aus Gamma.\nWas ein Kunde bindet, ohne den Umweg über das Projekt: Die zweistufige Gliederung fasst je Kunde alles zusammen, was seine Vorhaben an einer Qualifikation fordern. Erst die dritte Ebene sagt, in welchem Projekt es steckt.\nBild 12 von 20 — Der Kunde als oberste Ebene, darunter das Projekt, darunter die Rolle. Die Musterkunde AG zeigt ihre beiden Vorhaben nacheinander — Alpha und Gamma, zusammen 192 Stunden —, jedes mit seinen zwei Qualifikationen und 8 Stunden je Tag; die Beispielkunde GmbH ihr eines mit 96. Das ist die Ansicht für die Frage, was ein Kunde bindet — und in welchem Projekt: dieselben 192 und 96 Stunden wie im Bild davor, jetzt je Vorhaben aufgeteilt.\nDie Stammdaten aus dem Pool — Kunde und Kategorie am Projektkopf — sind im Portfolio Gliederungsebenen. Sie ändern keine Zahl: Die 192 Stunden der Musterkunde AG sind Alphas 96 plus Gammas 96, und die Bearbeiter/innen des Portfolios bleiben bei 168. Sie ändern, wie die Zeilen zusammenfinden — und damit, welche Frage sich in einer Zeile beantworten lässt.\nBild 13 von 20 — Der Kunde oben, darunter die Rolle, darunter das Projekt — die dritte Reihenfolge beim Kunden. Die Musterkunde AG bindet 112 Stunden Bearbeiter/in und 80 Stunden Prüfer/in, und unter jeder Rolle steht, welches ihrer Vorhaben wie viel davon fordert: Alpha und Gamma je 56 bei den Bearbeitern, je 40 bei der Prüferin. Das ist die Frage „welche Projekte dieses Kunden brauchen diese Qualifikation\u0026quot; — gestellt, wenn die Rolle knapp ist und beim Kunden entschieden werden muss, welches seiner Vorhaben nachgibt.\nDrei Reihenfolgen für denselben Kunden: Kunde → Rolle sagt, wie viel er insgesamt bindet; Kunde → Projekt → Rolle, welches seiner Vorhaben was braucht; Kunde → Rolle → Projekt, welche seiner Vorhaben sich eine knappe Qualifikation teilen. Die Zahlen sind in allen dreien dieselben — 192 Stunden, davon 112 Bearbeitung und 80 Prüfung.\nBild 14 von 20 — Die Kategorie als oberste Ebene, direkt darunter die Rolle. Entwicklung bindet 192 Stunden — Alpha und Beta in einer Zeile je Qualifikation —, Wartung 96. Wer wissen will, wie viel Arbeit in Entwicklung steckt und wie viel in Wartung, ohne nach Projekten zu unterscheiden, liest diese zwei Ebenen.\nBild 15 von 20 — Statt des Kunden die Kategorie als oberste Ebene, darunter das Projekt, darunter die Rolle. Entwicklung fasst Alpha und Beta zusammen — 192 Stunden —, Wartung ist allein Gamma mit 96. Dieselben neun Vorgänge, ein anderer Schnitt: Wer wissen will, wie viel Arbeit in Entwicklung steckt und wie viel in Wartung, liest diese Reihenfolge. Keiner der beiden Schnitte ändert eine Zahl; sie ändern, was man auf einen Blick liest.\nDieselben Fragen an die Personen # Bild 16 von 20 — Dieselben Daten, jetzt nach Person sortiert. Anna Muster trägt Alphas Konzept und Freigabe, Bernd Beispiel dasselbe für Beta, Clara Probe prüft in Alpha und in Beta — vom 12. bis 23. Oktober jeden Tag 8 Stunden, zwei Wochen ohne Lücke. Was fehlt, ist die Aussage: Gamma kommt in dieser Ansicht nicht vor, weil dort niemand zugewiesen ist. Die Rollenauslastung in Bild 8 sah Gammas Bedarf, die Personalsicht sieht nur, wer eingetragen ist — und genau deshalb braucht ein Portfolio beide.\nDie Personalauslastung ist die Rollenauslastung von der anderen Seite: Sie fragt nicht, was gebraucht wird, sondern wer eingetragen ist. Für Alpha und Beta ist das dieselbe Information — nur dass jetzt Namen statt Qualifikationen in den Zeilen stehen und Clara Probes zwei Wochen ohne Lücke in einer einzigen Zeile liegen. Für Gamma ist es keine Information: Das Projekt hat Rollen, aber keine Menschen, und eine Ansicht, die nach Menschen sortiert, hat dafür keine Zeile.\nBild 17 von 20 — Eine Ebene mehr, und jede Person bekommt ihre Projekte als Adresse. Anna Muster arbeitet nur für Alpha, Bernd Beispiel nur für Beta — und Clara Probe für beide, hintereinander: Alpha bis zum 16., Beta ab dem 19. Oktober. Das ist die Reihenfolge für die Frage „wo steckt dieser Mensch, und welches Projekt müsste ihn abgeben\u0026quot;. Gamma steht unter niemandem.\nBild 18 von 20 — Die Gliederung umgedreht — erst das Projekt, dann die Person —, und die Ansicht beantwortet die Frage „wer arbeitet an diesem Projekt\u0026quot;. Unter Alpha stehen Anna Muster und Clara Probe, unter Beta Bernd Beispiel und Clara Probe. Clara erscheint zweimal, weil sie zwei Projekten gehört; die Summe ihrer 80 Stunden gibt es in dieser Reihenfolge nicht mehr. Und Gamma hat hier niemanden — die Zeile bleibt leer oder fehlt ganz. Das ist die Lücke, die vor dem 19. Oktober zu schließen ist.\nDie beiden Gliederungen der Personalsicht stellen dieselben Fragen wie die der Rollensicht, nur an Namen: Person vor Projekt zeigt, wo ein Mensch gebunden ist und was ihn freigäbe; Projekt vor Person zeigt, wer an einem Vorhaben arbeitet — und wo noch niemand. Für Gamma ist die zweite Ansicht die Aufgabenliste: zwei Rollen gefordert, keine Person eingetragen, Anfang am 19. Oktober.\nBild 19 von 20 — Der Kunde als oberste Ebene der Personalsicht. Unter der Musterkunde AG steht nur Alpha mit Anna Muster und Clara Probe — Gamma gehört demselben Kunden, hat aber niemanden und erscheint deshalb auch hier nicht; unter der Beispielkunde GmbH steht Beta mit Bernd Beispiel und Clara Probe. Wer für einen Kunden wissen will, welche Menschen an seinen Projekten arbeiten, liest diese Reihenfolge — und sieht an der Musterkunde AG zugleich, dass ihr zweites Projekt noch unbesetzt ist.\nBild 20 von 20 — Die Kategorie als oberste Ebene der Personalsicht. Entwicklung fasst Alpha und Beta mit ihren Menschen zusammen — Anna und Clara, Bernd und Clara —; Wartung hat mit Gamma nur ein Projekt, und das hat niemanden, also fehlt die ganze Kategorie. Das ist die letzte der Gliederungen dieser Seite, und sie sagt dasselbe wie die erste Personalsicht, nur eine Ebene höher: Was nicht besetzt ist, ist in der Personalsicht nicht da.\nKunde und Kategorie über der Personalsicht zeigen dieselbe Lücke wie die flache Personalsicht, nur adressiert: Nicht „irgendwo fehlt jemand\u0026quot;, sondern „bei der Musterkunde AG fehlt jemand, und zwar in der Wartung\u0026quot;. Das ist die Form, in der eine Lücke jemanden findet, der sie schließt.\nWas das für die Planung heißt # Der Engpass ist eine Eigenschaft des Portfolios, nicht eines Projekts. Keines der drei Projekte hat einen Fehler gemacht; die drei Wochen Prüfung ohne Lücke entstehen erst aus ihrer Summe. Wer nur sein Projekt plant, kann sie nicht sehen. Rollen zuweisen, auch wenn Personen feststehen. Die Rollenauslastung rechnet über die Rollen, und nur so zählt ein Projekt mit, in dem noch niemand eingetragen ist. Gamma steht in Bild 8 in derselben Zeile wie Alpha und Beta — weil es dieselbe Rolle fordert. Die Gliederung ist eine Frage, keine Einstellung. Rolle zuerst für „wer ist knapp\u0026quot;, Projekt zuerst für „was braucht dieses Vorhaben\u0026quot;. Beide Reihenfolgen gehören zum Portfolio; keine ersetzt die andere. Wie ein Portfolio im Branchenbestand aussieht — fünf Vorhaben auf 120 Personen, mit einer Unterdeckung, die kein Einzelprojekt zeigt —, steht im Beispiel Multiprojekt-Kapazitätsabgleich im Mittelstand. Was die drei Gliederungen an derselben Kapazitätsansicht bewirken, zeigt Kapazitätsansichten steuern. Warum eine Rolle etwas anderes ist als eine Person, steht unter Rolle oder Person; was der fixierte Meilenstein am Ende jedes Projekts festhält, unter Teilprojekt und Meilenstein fixieren.\nWie sich derselbe Funktionsumfang außerhalb der Beispiele darstellt, steht auf der Produktseite zum Multiprojektmanagement in der Rillsoft Cloud.\n","date":"11. September 2026","externalUrl":null,"permalink":"/grundlagen/ressourcen-im-portfolio/","section":"Grundlagen der Ressourcenplanung","summary":"","title":"Ressourcenmanagement im Portfolio","type":"grundlagen"},{"content":" Diese Grundlagen gelten in jeder Branche. Die ersten Seiten erklären Reservezeit und kritischen Pfad, Termin- und Kapazitätsplanung, Rollen, Personen und Vorgangsarten. Danach folgen dynamische Aufwandsverteilung, Basisplan, Schichtkalender, Prozentanteile, Standorte und die Fixierung von Teilprojekt und Meilenstein. Alles wird ohne Branche gezeigt. Dafür dient ein kleines Projekt mit drei bis sechs Vorgängen.\nWarum ein kleines Projekt und nicht der Beispielbestand # An dreiundvierzig Vorgängen sieht man das Ergebnis, aber nicht den Mechanismus. Wenn ein Bauprojekt nach einer Krankmeldung anders aussieht, haben sich zwanzig Zeilen bewegt: Eine davon hat die Planungsart erzwungen, die anderen neunzehn sind mitgewandert, weil sie an der ersten hängen. Welche welche ist, lässt sich im Bild nicht mehr trennen.\nAn drei Vorgängen ist es eine einzige Zeile, und daneben steht die Zahl, die sich geändert hat. Deshalb entstehen die Aufnahmen dieses Bereichs an einem eigens gebauten Kleinprojekt — mit synthetischen Namen, ohne Bezug zu den neun Branchenpaketen. Keine Aufnahme unter /grundlagen/ öffnet eine Datei des Beispielbestandes.\nWas hier steht und was auf den Branchenseiten # Die Trennung ist einfach: Hier steht, wie es rechnet. Dort steht, was es kostet.\nDieselbe Krankmeldung erscheint auf der Grundlagenseite als drei Vorgänge mit zwei möglichen Antworten — der Termin hält und die Lücke wird zur Zahl, oder der Vorgang wird länger und der Nachfolger wandert mit. Im Bauwesen erscheint sie als Bauprojekt mit Ausschreibungsphase, Urlauben und Nachfolgern, und dort entscheidet sich, ob drei Tage Lücke eine Frist reißen oder nur den Puffer aufbrauchen.\nWer eine Entscheidung vorbereitet, braucht meist beides: erst den Mechanismus, dann den Preis. Deshalb führt jede Seite hier am Fuß in alle neun Branchen zurück, und jeder Branchen-Hub führt alle Grundlagen auf.\nWie man den Bereich benutzt # Nicht von vorn nach hinten. Die neun Seiten bauen nicht aufeinander auf; jede beantwortet eine Frage, die beim Planen auftaucht — warum ein Vorgang rot ist, warum der Endtermin wandert, worauf sich eine Prozentzahl bezieht. Man kommt aus einer Branchenseite hierher, schlägt den Begriff nach und geht zurück.\nDie Karten haben eine klare Reihenfolge. Sie beginnt bei dem, was ein Plan von sich aus zeigt: Reservezeit und kritischer Pfad. Danach folgt, was man einstellt oder abliest: Planungsart, Vorgangsart, Kalender, Basisplan und Auslastung. Zwei Grenzfragen schließen die Reihe ab: Welches Team zählt vor Ort, und welcher Termin steht fest?\nWie sich derselbe Funktionsumfang außerhalb der Beispiele darstellt, steht auf der Produktseite zum Projektmanagement in der Rillsoft Cloud.\n","date":"8. September 2026","externalUrl":null,"permalink":"/grundlagen/","section":"Grundlagen der Ressourcenplanung","summary":"","title":"Grundlagen der Ressourcenplanung","type":"grundlagen"},{"content":"Wir freuen uns über Ihr Interesse an projektbeispiele.de. Nachfolgend informieren wir Sie über die Verarbeitung personenbezogener Daten beim Besuch dieser Website sowie über Ihre Rechte nach der Datenschutz-Grundverordnung (DSGVO).\nprojektbeispiele.de ist ein redaktioneller Praxis-Hub der Rillsoft GmbH, der Projektplanung, Ressourcen- und Kapazitätsplanung an Beispielprojekten zeigt. Die Website bietet keine Konten, keine Bestell- oder Cloud-Funktionen, kein Kontaktformular und keinen Upload-Workflow. Eine Nutzung ist grundsätzlich ohne aktive Angabe personenbezogener Daten möglich; technisch notwendige Daten (z. B. die IP-Adresse in Server-Logfiles) werden jedoch bei jedem Aufruf verarbeitet.\nVerantwortlicher # Verantwortlicher im Sinne der DSGVO und sonstiger datenschutzrechtlicher Bestimmungen ist:\nAnschrift:Rillsoft GmbH Mollenbachstr. 14 71229 Leonberg, Deutschland Vertreten durch:Dimitri Sapunou (Geschäftsführer) Tel.:+49 7152 30725570 E-Mail:info@rillsoft.de Website:www.rillsoft.de Weitere Anbieterangaben finden Sie im Impressum.\nBeispieldaten auf dieser Website # Die gezeigten Projekte, Ressourcenpools und Auslastungswerte sind synthetische Beispieldaten ohne Bezug zu realen Personen oder Kunden. Die darin enthaltenen Namen, Qualifikationen und Teams sind frei erfunden; eine Verarbeitung personenbezogener Daten Dritter findet dadurch nicht statt. Näheres im Impressum.\nServer-Logfiles # Beim Aufruf der Website werden durch den Hosting-Anbieter automatisch Daten erfasst und in Server-Logfiles gespeichert. Erfasst werden können insbesondere:\nverwendeter Browsertyp nebst Version verwendetes Betriebssystem die zuvor besuchte Internetseite (Referrer) Name der abgerufenen Seite und übertragene Datenmenge Datum und Uhrzeit des Zugriffs die IP-Adresse des zugreifenden Systems der Internet-Service-Provider des zugreifenden Systems Diese Daten dienen ausschließlich dem technisch fehlerfreien Betrieb, der Sicherheit und der Auslieferung der Website. Eine Zusammenführung mit anderen Datenquellen oder eine personenbezogene Auswertung findet nicht statt. Rechtsgrundlage ist Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse am sicheren und stabilen Betrieb der Website). Die Logfiles werden nur so lange gespeichert, wie dies für diese Zwecke erforderlich ist; eine längere Speicherung erfolgt nur bei konkreten Anhaltspunkten für eine rechtswidrige Nutzung.\nHosting # Die Website wird bei der Host Europe GmbH, Hansestraße 111, 51149 Köln, Deutschland, gehostet; die Server befinden sich in Deutschland. Der Anbieter verarbeitet die oben genannten Server-Logfiles in unserem Auftrag auf Grundlage eines Auftragsverarbeitungsvertrags gemäß Art. 28 DSGVO. Weitere Informationen zum Datenschutz beim Hosting-Anbieter finden Sie unter https://www.hosteurope.de/AGB/Datenschutzerklaerung/.\nCookies und lokale Speicherung # Diese Website setzt nur technisch notwendige Mittel ein. Für die Darstellung (z. B. die gewählte Hell-/Dunkel-Ansicht) und die seiteninterne Suche werden Einstellungen im lokalen Speicher Ihres Browsers (Local Storage) abgelegt. Diese Daten verbleiben in Ihrem Browser und werden nicht an uns übertragen.\nEine Webanalyse oder ein Tracking zu Marketing- oder Statistikzwecken (z. B. Google Analytics, Google Ads) findet derzeit nicht statt. Sollten künftig optionale Cookies oder vergleichbare Technologien zu Analyse- oder Marketingzwecken eingesetzt werden, geschieht dies nur nach Ihrer vorherigen Einwilligung (Art. 6 Abs. 1 lit. a DSGVO), die Sie jederzeit mit Wirkung für die Zukunft widerrufen können.\nDie meisten Browser sind so eingestellt, dass sie Cookies und lokalen Speicher akzeptieren. Sie können diese in den Browser-Einstellungen einschränken oder löschen; hierdurch kann der Funktionsumfang der Website eingeschränkt werden.\nKontaktaufnahme per E-Mail # Wenn Sie uns per E-Mail kontaktieren, werden die von Ihnen übermittelten Daten (z. B. Name und E-Mail-Adresse) zum Zweck der Bearbeitung Ihrer Anfrage gespeichert. Eine Weitergabe zu Werbezwecken erfolgt nicht. Rechtsgrundlage ist Art. 6 Abs. 1 lit. b DSGVO (vorvertragliche Maßnahmen bzw. Vertragserfüllung), im Übrigen Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an der Bearbeitung von Anfragen). Die Daten werden gelöscht, sobald sie für die Bearbeitung nicht mehr erforderlich sind und keine gesetzlichen Aufbewahrungspflichten entgegenstehen.\nVerlinkung auf Rillsoft-Domains # Inhalte auf projektbeispiele.de verweisen redaktionell auf https://www.rillsoft.de und bei Bedarf auf https://www.rillsoft.cloud sowie auf die Schwesterdomain https://balkenplan.de. Alle Domains werden ebenfalls von der Rillsoft GmbH betrieben; eine Übermittlung personenbezogener Daten von projektbeispiele.de zu diesen Domains findet beim Aufruf der Seiten von projektbeispiele.de selbst nicht statt. Erst wenn Sie einem Link folgen, gelten die Datenschutzhinweise der jeweiligen Zielwebsite.\nDatenübermittlung an Dritte # Eine Übermittlung Ihrer personenbezogenen Daten an Dritte erfolgt nur, wenn hierfür eine datenschutzrechtliche Grundlage besteht, insbesondere wenn\nSie nach Art. 6 Abs. 1 lit. a DSGVO ausdrücklich eingewilligt haben, dies nach Art. 6 Abs. 1 lit. b DSGVO zur Bearbeitung Ihrer Anfrage erforderlich ist, nach Art. 6 Abs. 1 lit. c DSGVO eine gesetzliche Verpflichtung besteht, die Weitergabe nach Art. 6 Abs. 1 lit. f DSGVO zur Geltendmachung, Ausübung oder Verteidigung von Rechtsansprüchen erforderlich ist, oder wir Dienstleister als Auftragsverarbeiter gemäß Art. 28 DSGVO einsetzen (z. B. Hosting-Anbieter). Speicherdauer # Wir verarbeiten und speichern personenbezogene Daten nur für den Zeitraum, der zur Erreichung des jeweiligen Zwecks erforderlich ist oder durch gesetzliche Aufbewahrungspflichten vorgegeben wird. Nach Wegfall des Zwecks oder Ablauf der Fristen werden die Daten routinemäßig gelöscht.\nDatensicherheit # Wir treffen angemessene technische und organisatorische Maßnahmen, um Ihre Daten vor Verlust, Missbrauch und unbefugtem Zugriff zu schützen, und verbessern diese entsprechend der technologischen Entwicklung fortlaufend. Bei der Auslieferung der Website kommt eine TLS-Verschlüsselung zum Einsatz. Internetbasierte Datenübertragungen können jedoch grundsätzlich Sicherheitslücken aufweisen; ein absoluter Schutz vor dem Zugriff durch Dritte ist nicht möglich.\nIhre Rechte als betroffene Person # Nach der DSGVO stehen Ihnen folgende Rechte zu:\nRecht auf Auskunft (Art. 15 DSGVO) Recht auf Berichtigung (Art. 16 DSGVO) Recht auf Löschung (Art. 17 DSGVO) Recht auf Einschränkung der Verarbeitung (Art. 18 DSGVO) Recht auf Datenübertragbarkeit (Art. 20 DSGVO) Recht auf Widerspruch gegen die Verarbeitung (Art. 21 DSGVO) Recht auf jederzeitigen Widerruf einer erteilten Einwilligung mit Wirkung für die Zukunft (Art. 7 Abs. 3 DSGVO) Zur Ausübung Ihrer Rechte oder bei Fragen zur Verarbeitung Ihrer Daten können Sie sich jederzeit an info@rillsoft.de wenden.\nBeschwerderecht bei einer Aufsichtsbehörde # Unbeschadet anderweitiger Rechtsbehelfe steht Ihnen nach Art. 77 DSGVO ein Beschwerderecht bei einer Datenschutz-Aufsichtsbehörde zu, wenn Sie der Ansicht sind, dass die Verarbeitung Ihrer personenbezogenen Daten gegen datenschutzrechtliche Bestimmungen verstößt.\nÄnderungen dieser Datenschutzerklärung # Wir passen diese Datenschutzerklärung an, wenn sich die Rechtslage oder die tatsächliche Datenverarbeitung ändert. Es gilt jeweils die hier veröffentlichte aktuelle Fassung.\nStand: 14. August 2026\n","date":"14. August 2026","externalUrl":null,"permalink":"/datenschutz/","section":"Projektplan-Beispiele – Projektplanung an Branchenbeispielen","summary":"","title":"Datenschutz","type":"page"},{"content":"projektbeispiele.de ist ein redaktioneller Praxis-Hub zu Projektplanung, Ressourcen- und Kapazitätsplanung an konkreten Beispielprojekten. Herausgeberin und inhaltlich Verantwortliche ist die Rillsoft GmbH.\nAngaben gemäß § 5 DDG # Anbieter:Rillsoft GmbH Mollenbachstr. 14 71229 Leonberg, Deutschland Vertreten durch:Dimitri Sapunou (Geschäftsführer) Tel.:+49 7152 30725570 E-Mail:info@rillsoft.de Website:www.rillsoft.de Handelsregister:Amtsgericht Leonberg, HRB 3053 Umsatzsteuer-IdNr.:DE222015909 Verantwortlich für den Inhalt nach § 18 Abs. 2 MStV # Dimitri Sapunou, Rillsoft GmbH, Mollenbachstr. 14, 71229 Leonberg, Deutschland.\nHinweis zu den Beispielprojekten # Sämtliche auf dieser Website gezeigten Projekte, Ressourcenpools, Qualifikationen, Auslastungswerte und Kostenangaben sind synthetische Beispieldaten. Sie wurden für Demonstrations- und Schulungszwecke erzeugt und bilden keine realen Kundenprojekte ab. Personen-, Firmen- und Standortnamen in den Beispielen sind frei erfunden; Ähnlichkeiten mit tatsächlichen Vorhaben sind nicht beabsichtigt. Verwendete Domainnamen in Beispieldaten stammen aus dem für Dokumentationszwecke reservierten Bereich (.example).\nHaftung für Inhalte # Diese Website wurde mit größtmöglicher Sorgfalt erstellt. Für die Richtigkeit, Vollständigkeit und Aktualität der Inhalte können wir jedoch keine Gewähr übernehmen. Als Diensteanbieter sind wir gemäß § 7 Abs. 1 DDG für eigene Inhalte auf diesen Seiten nach den allgemeinen Gesetzen verantwortlich. Nach §§ 8 bis 10 DDG sind wir als Diensteanbieter jedoch nicht verpflichtet, übermittelte oder gespeicherte fremde Informationen zu überwachen oder nach Umständen zu forschen, die auf eine rechtswidrige Tätigkeit hinweisen.\nDie fachlichen Inhalte auf projektbeispiele.de dienen der allgemeinen Information zu Methoden und Werkzeugen der Projekt-, Ressourcen- und Kapazitätsplanung. Die gezeigten Beispiele veranschaulichen Planungsverfahren und ersetzen keine projektbezogene, rechtliche oder steuerliche Beratung. Eine Eignung für einen konkreten Anwendungsfall ist im Einzelfall zu prüfen; insbesondere lassen sich aus den Beispielen keine Zusagen zu Terminen, Kapazitäten oder Kosten eines realen Vorhabens ableiten.\nHaftung für Links # Unser Angebot enthält Links zu externen Websites Dritter, insbesondere zu weiteren Angeboten der Rillsoft GmbH (z. B. https://www.rillsoft.de), sowie ggf. zu Quellen des Projektmanagements, auf deren Inhalte wir keinen Einfluss haben. Deshalb können wir für diese fremden Inhalte auch keine Gewähr übernehmen. Für die Inhalte der verlinkten Seiten ist stets der jeweilige Anbieter oder Betreiber verantwortlich. Bei Bekanntwerden von Rechtsverletzungen entfernen wir derartige Links umgehend.\nUrheberrecht # Die durch die Betreiberin erstellten Inhalte und Werke auf diesen Seiten unterliegen dem deutschen Urheberrecht. Das gilt auch für die abgebildeten Bildschirmdarstellungen aus Rillsoft Project. Vervielfältigung, Bearbeitung, Verbreitung und jede Art der Verwertung außerhalb der Grenzen des Urheberrechts bedürfen der schriftlichen Zustimmung der Rillsoft GmbH.\nMarkenhinweis # Rillsoft und Rillsoft Project sind Kennzeichen der Rillsoft GmbH. In den fachlichen Inhalten genannte Produktnamen Dritter sind Marken oder eingetragene Marken der jeweiligen Inhaber. Die Nennung dient ausschließlich der fachlichen Einordnung und begründet keine Verbindung zu oder Anerkennung durch die Markeninhaber.\nVerbraucherstreitbeilegung # Wir sind nicht bereit und nicht verpflichtet, an Streitbeilegungsverfahren vor einer Verbraucherschlichtungsstelle teilzunehmen.\n","date":"14. August 2026","externalUrl":null,"permalink":"/impressum/","section":"Projektplan-Beispiele – Projektplanung an Branchenbeispielen","summary":"","title":"Impressum","type":"page"},{"content":"","date":"27. Mai 2026","externalUrl":null,"permalink":"/","section":"Projektplan-Beispiele – Projektplanung an Branchenbeispielen","summary":"","title":"Projektplan-Beispiele – Projektplanung an Branchenbeispielen","type":"page"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":"","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"}]