Ressourcenmigration: Kapazitätsplanung aus Microsoft Project

Der Wert von Project Server liegt für PMOs, die es gut betreiben, selten in den Projektplänen selbst. Er lag in der operativen Schicht darunter: ein einziger unternehmensweiter Ressourcenpool, aus dem jedes Projekt schöpfte, kostenbewertete Zeiterfassung, die Abrechnung und Umsatzrealisierung speiste, Kalenderausnahmen, die sich automatisch verbreiteten, und projektübergreifende Ansichten, mit denen Ressourcenmanager jede Woche Besetzungsentscheidungen auf echten Auslastungsdaten trafen. Diese operative Schicht steht auf dem Spiel. Die Pläne werden migriert. Die operative Schicht oft nicht.

Drei Fehlerbilder treten immer wieder auf, wenn PMOs das unterschätzen:

• Die Falle „Ressourcen fügen wir später hinzu“. Ein Team migriert die Projektpläne sauber und will den Ressourcenpool im folgenden Sprint nachtragen. Bis es so weit ist, haben einzelne Projektverantwortliche bereits doppelte Ressourcen in ihren Projekten angelegt, und der Ressourcenmanager hat die eine verlässliche Quelle verloren, auf der die projektübergreifenden Kapazitätsansichten beruhten.
• Die Falle „Kostensätze sind für den Start nicht kritisch“. Standardsätze werden auf eine Bereinigung in Phase 2 verschoben. Zwei Monate später stellt die Finanzabteilung fest, dass ihr Monatsabschluss kostenbewertete Zeiterfassungsdaten braucht, die es in der neuen Plattform nicht mehr gibt, weil die Sätze zum Zeitpunkt der Erfassung nicht geladen waren. Die Daten lassen sich nicht nachträglich rekonstruieren; die Umsatzrealisierung stockt.
• Die Falle „Planner Premium wird reichen“. Ein PMO nimmt an, dass das Cloud-Produkt von Microsoft dieselben Anwendungsfälle abdeckt. Für die Ressourcenmodellierung tut es das nicht. Planner Premium bringt keinen unternehmensweiten Ressourcenpool, keine kostenbewertete Zeiterfassung und keine projektübergreifende Ressourcenansicht mit. Nach der Migration ist es zu spät, das zu entdecken.

Der strukturelle Grund für alle drei: Das Ressourcenmodell ist der Teil von Project Server, der in beiläufigen Produktdemos am wenigsten sichtbar ist und in Vergleichschecklisten von Anbietern am wenigsten vorkommt. Projektpläne, Gantt-Diagramme und Dashboards lassen sich gut vorführen. Unternehmensweite Ressourcenpools nicht. Deshalb gewichten Käufer die Abdeckung des Ressourcenmodells bei der Auswahl zu gering und entdecken die Lücke im Betrieb. Dieser Leitfaden stellt das Modell deshalb an den Anfang, vor die Taktik der Migration, in der Annahme, dass die größte Entscheidung die Wahl der Zielplattform ist.

Bevor Sie entscheiden, was migriert wird, erfassen Sie, was Sie haben. Das Ressourcenmodell von Project Server hat sechs Schichten, und jede wird anders migriert:

Nicht jedes PMO nutzt jede Schicht. Die richtige Frage für die Bestandsaufnahme lautet: „Auf welche davon verlässt sich unser Team tatsächlich bei Entscheidungen?“ Wenn Sie keine kostenbewertete Zeiterfassung betreiben, ist die Schicht der Satztabellen Dekoration; Sie können sie folgenlos weglassen. Wenn Sie generische Ressourcen nicht für die Bedarfsplanung nutzen, können Sie sie zusammenlegen. Wenn Sie sie dafür nutzen, ist diese Fähigkeit in der Zielplattform nicht verhandelbar.

Machen Sie die Bestandsaufnahme, bevor Sie Plattformen vergleichen. Ihr Ergebnis ist eine Liste der Fähigkeiten, die die Zielplattform haben muss, und diese Liste prägt den Rest der Migration. Der nächste Abschnitt setzt voraus, dass Sie diese Liste in der Hand haben.

Plattformvergleiche werden enger, wenn Sie nach der Abdeckung des Ressourcenmodells filtern. Hier das ehrliche Bild, geordnet nach den sechs Schichten oben. Ja, teilweise oder nein für jede:

Das Cloud-Produkt von Microsoft (Planner Premium / Project for the Web, dasselbe Produkt unter verschiedenen SKU-Bezeichnungen) lässt den größten Teil des Ressourcenmodells weg. Das ist eine bewusste Positionierung: Es ist ein Werkzeug für Teamaufgaben mit einer Projektschicht, keine PMO-Plattform. PMOs, die das Ressourcenmodell von Project Server ernsthaft nutzen, können es nicht durch Planner Premium ersetzen, ohne erhebliche Fähigkeiten zu verlieren.

Das Modul Resource Management von Smartsheet und Workfront behalten beide das Konzept des unternehmensweiten Pools. Sie unterscheiden sich im Detail: Smartsheet RM ist eine separate SKU und kostet pro Platz spürbar mehr; der Pool von Workfront ist stark, aber der Preis pro Platz ist der höchste der vier. Onplana hat keinen eigenen Ressourcenpool: Jede Person ist ein Mitglied der Organisation, und das Ressourcenmodell ist die wöchentliche Kapazität dieser Person über alle Projekte (ab dem Tarif Professional), Kostensätze auf drei Ebenen (Person, Rolle, Standard der Organisation) und Arbeitskalender mit benannten Ausnahmen, ohne kostenpflichtiges Zusatzmodul. Es gibt keine generischen Ressourcen, keine Kalender pro Person und keinen formalen RBS. Die Preise beginnen bei 12 US-Dollar pro Platz und Monat (Professional). Der ehrliche Vergleich mit Planner Premium steht auf unserer Vergleichsseite zu Planner.

Eine weitere Dimension passt schlecht in eine Tabelle: Die Qualität der projektübergreifenden Kapazitätsansicht unterscheidet sich stark zwischen Plattformen, selbst wenn die Grundfunktion vorhanden ist. Manche zeigen nur direkte Vorgangszuweisungen; manche schließen Rollups aus Teilprojekten ein; manche auch Platzhalter für generische Auslastung. Wenn Ihr Ressourcenmanager jede Woche anhand dieser Ansicht über die Besetzung entscheidet, vergleichen Sie während der Bewertung die 25 Ressourcen mit den meisten zugewiesenen Stunden nebeneinander.

Bevor Sie etwas exportieren, erstellen Sie eine vollständige Bestandsaufnahme des Ressourcenmodells. Das ist eine andere Bestandsaufnahme als die der Projektliste: Jene erfasst Projekte, diese die Ressourcenschicht darunter. Das Ergebnis ist ein Bericht zur Migrationsbereitschaft der Ressourcen, der jedes Ressourcenelement auflistet, wo es heute liegt, wohin es geht und wer den Umzug verantwortet.

1. Ressourcenliste mit Attributen. Exportieren Sie den vollständigen unternehmensweiten Ressourcenpool mit Name, Typ (namentlich/generisch/Kosten), E-Mail (bei namentlichen), maximalen Einheiten, Standardsatz, Rolle/Titel und RBS-Pfad. Der OData-Endpunkt /Resources ist die maßgebliche Quelle; die Reporting Database hat mehr abgeleitete Felder, aber nur bei Project Server vor Ort.
2. Kostensatztabellen. Microsoft Project unterstützt bis zu 5 Kostensätze pro Ressource (Satz A bis Satz E) mit Gültigkeitszeiträumen. Exportieren Sie jede Stufe und jede Zeile mit Gültigkeitsdatum. Wenn Ihr PMO nur Satz A nutzt, können Sie B–E ignorieren, aber prüfen Sie das, bevor Sie es annehmen.
3. Kalenderausnahmen. Exportieren Sie für jede Ressource die Liste der Kalenderausnahmen mit Name, Zeitraum und abweichender Arbeitszeit. Wenn Ihre Zielplattform benannte Ausnahmen nicht erhält, halten Sie die Namen in einer begleitenden CSV-Datei fest, damit die Begründung („Konferenzwoche“, „Betriebsferien“) erhalten bleibt.
4. RBS-Hierarchie. Exportieren Sie den Ressourcenstrukturplan: jeden Knoten, die Eltern-Kind-Verknüpfungen und die jedem Knoten zugeordneten Ressourcen. Erst die Hierarchie erlaubt Ressourcenmanagern, Kapazitätsansichten nach ihrer Berichtslinie zu filtern.
5. Aktive Zuweisungen. Halten Sie jede aktive Vorgangszuweisung in jedem aktiven Projekt fest: welche Ressource, welches Projekt, welcher Vorgang, zugewiesene Stunden, tatsächliche Stunden, geplanter Anfang und geplantes Ende. Das ist die Basis der Prüfung; nach der Migration vergleichen Sie die Auslastung in Quelle und Ziel.
6. Benutzerdefinierte Ressourcenfelder. Wenn Ihr PMO Enterprise Custom Fields für Ressourcen angelegt hat (Sicherheitsfreigabe, Abrechenbarkeit, Vertragsart), exportieren Sie sie mit der Ressourcenliste. Manche Zielplattformen bilden sie als eingebaute Felder ab, andere als benutzerdefinierte Felder, andere gar nicht; das bestimmt später die Entscheidung über die Feldzuordnung.

Der fertige Bereitschaftsbericht ist die Grundlage für den Rest der Migration. Um die Qualität des Exports vor der Festlegung zu prüfen, schicken Sie einen Musterpool durch das Werkzeug Migrationsvorschau: Laden Sie einen repräsentativen Ausschnitt des Ressourcenpools hoch und sehen Sie genau, welche Felder, Sätze und Ausnahmen sauber übertragen werden.

Fünf Phasen, jede mit einem Ergebnis und einer Go/No-Go-Schwelle. Die Gesamtdauer liegt typischerweise bei 3–5 Wochen für einen Pool mit 100–250 Ressourcen, länger bei stark angepassten Kostensatztabellen oder einem großen RBS.

Phase 1: Bestandsaufnahme und Entscheidungen (1 Woche)

Schließen Sie die Bestandsaufnahme oben ab und entscheiden Sie dann über die Plattform danach, welche Schichten des Ressourcenmodells für Ihr Team nicht verhandelbar sind. Dokumentieren Sie die Entscheidung mit Begründung; diesen Abschnitt lesen Sie später wieder, wenn jemand fragt, warum die gewählte Plattform Funktion X nicht hat.

• Die Bestandsaufnahme am laufenden Mandanten durchführen
• Jede Zielplattform an Ihrer Liste der Pflichtschichten bewerten
• Das Ziel wählen und die Begründung dokumentieren
• Die Freigabe der PMO-Leitung für die Plattformwahl einholen

Schwelle: Bereitschaftsbericht unterzeichnet; Zielplattform gewählt.

Phase 2: Den Pool exportieren (2–3 Tage)

Exportieren Sie aus Project Server, solange es noch läuft, und prüfen Sie dann, ob der Export jede der folgenden Schichten enthält. Verlassen Sie sich für den Ressourcenpool nicht auf .mpp-Exporte; sie enthalten nur projektlokale Ressourcenzuweisungen, nicht den unternehmensweiten Pool mit Sätzen, Kalendern und RBS.

• Die Ressourcenliste, aus /Resources
• Kalenderausnahmen, aus /Resources/Calendars
• Kostensatztabellen (oder die Reporting DB, vor Ort)
• Den RBS, aus den SOAP-API-Endpunkten, für die es keine OData-Entsprechung gibt
• Aktive Zuweisungen, aus /Assignments
• Anzahlen, die zum Bereitschaftsbericht passen

Schwelle: Die Anzahl im Export entspricht für jede Schicht der Anzahl im Bereitschaftsbericht.

Phase 3: Im Ziel neu modellieren (3–7 Tage)

Importieren Sie den Pool in die Zielplattform und schließen Sie dann Schicht für Schicht die Lücken, die der Plattformvergleich gezeigt hat. Generische Ressourcen, die sich nicht übertragen lassen, werden als namentliche Platzhalter neu modelliert. Namen von Kalenderausnahmen, die sich nicht übertragen lassen, werden archiviert. Benutzerdefinierte Ressourcenfelder werden eingebauten Feldern oder Definitionen benutzerdefinierter Felder im Ziel zugeordnet.

• Die Ressourcenliste importieren (Massenimport oder API des Ziels)
• Die RBS-Hierarchie neu anlegen und die Ressourcen den Knoten zuordnen
• Standardsätze und Kostensatztabellen laden, bevor Zuweisungsdaten geladen werden
• Kalenderausnahmen pro Ressource anwenden
• Generische Ressourcen nach dem Modell der Plattform übertragen
• Benutzerdefinierte Ressourcenfelder zuordnen

Schwelle: Anzahl im Ressourcenpool, RBS-Hierarchie und Anzahl der Satztabellen stimmen mit der Quelle überein.

Phase 4: Zuweisen und prüfen (1 Woche)

Migrieren Sie die Vorgangszuweisungen Projekt für Projekt, in Wellen nach verantwortlichem Team. Nach jeder Welle prüft das übernehmende Team innerhalb von 48 Stunden die Auslastung im Ziel gegen die Quelle für seine Projekte. Gehen Sie erst weiter, wenn die Welle sauber geprüft ist; aufgelaufene Abweichungen in der Auslastung über viele Projekte zu verfolgen ist viel schwerer, als sie Projekt für Projekt zu beheben.

• Zuweisungen in Wellen von 10–25 Projekten migrieren
• Abweichung der Auslastung pro Ressource und Projekt: Quelle gegen Ziel
• Jede Abweichung > 5% untersuchen
• Die Berechnungen der kostenbewerteten Zeiterfassung an einer Stichprobe vergangener Zeitnachweise abgleichen

Schwelle: Abweichung der Auslastung pro Ressource < 5% in allen Projekten.

Phase 5: Kapazitätsansichten und Abgleich (1 Woche)

Bauen Sie die Kapazitätsansichten nach, die Ressourcenmanager tatsächlich nutzen, und lassen Sie sie mindestens 5 Arbeitstage parallel zu Project Server laufen. Tägliche Abweichungsberichte zeigen jede Stelle, an der die Kapazitätsberechnung der neuen Plattform von der alten abweicht. Untersuchen Sie jede Abweichung. Dokumentieren Sie echte Unterschiede als bekannte Einschränkungen.

• Die 5 wichtigsten Kapazitätsansichten im Ziel nachbauen
• Tägliche Abweichungsberichte für die 25 Ressourcen mit den meisten zugewiesenen Stunden erstellen
• Abweichungen > 5% untersuchen; echte Plattformunterschiede dokumentieren
• Ressourcenmanager in der neuen Oberfläche der Kapazitätsansichten schulen
• Umstellen: Das Ziel wird zur verlässlichen Quelle, Project Server nur noch lesbar

Schwelle: 5 aufeinanderfolgende Arbeitstage mit sauberen täglichen Abweichungsberichten; Ressourcenmanager haben die neue Oberfläche der Kapazitätsansichten freigegeben.

Die fünf Fehlerbilder im Ressourcenmodell, die am häufigsten auftreten, mit der Vorbeugung für jedes:

Das Muster hinter allen fünf: Jede ist eine Entscheidung nach dem Motto „das klären wir später“, die im Moment billig und im Betrieb teuer ist. Die Abgleicharbeit gehört zu den Kosten, die in ersten Budgets am häufigsten unterschätzt werden; im Migrationskostenrechner fällt sie unter Parallelbetrieb.

Die Prüfphase hat drei Kontrollen, und jede liefert einen Nachweis. Legen Sie sie zum Bereitschaftsbericht; zusammen bilden sie den Prüfpfad der Migration.

1. Abgleich der Auslastung pro Ressource. Vergleichen Sie für die 25 Ressourcen mit den meisten zugewiesenen Stunden in den nächsten 90 Tagen die Auslastung in Quelle und Ziel. Toleranz: ±5%. Eine größere Abweichung bedeutet, dass entweder die Migration der Zuweisungen Daten verloren hat oder die Kapazitätsberechnung des Ziels sich grundsätzlich von der in Project Server unterscheidet. Beides muss untersucht werden. Nachweis: ein Abweichungsbericht pro Ressource.
2. Abgleich einer Stichprobe kostenbewerteter Zeitnachweise. Wählen Sie die letzten 10 abgeschlossenen Zeitnachweise von 5 verschiedenen Ressourcen. Berechnen Sie die Kosten im Ziel mit denselben Zeiteinträgen neu. Toleranz: ±1% (es geht um Geld; die Toleranz ist enger als bei der Auslastung). Eine Abweichung > 1% weist auf einen falschen Satz, eine verlorene Kalenderausnahme oder beides hin. Nachweis: Kostenberechnungen nebeneinander.
3. Gleichwertigkeit der projektübergreifenden Kapazitätsansichten. Bauen Sie die 3 Kapazitätsansichten nach, die Ressourcenmanager am häufigsten nutzen. Vergleichen Sie sie mit dem letzten Lauf von Project Server für denselben Zeitraum. Unterschiede darin, wie die beiden Ansichten die Auslastung einordnen (direkt oder aus Teilprojekten, namentlich oder generisch), sind zu erwarten. Dokumentieren Sie sie als bekannte Plattformunterschiede im Betriebshandbuch nach der Migration. Nachweis: Bildschirmfotos nebeneinander mit dokumentierten Unterschieden.

Das Ergebnis der Prüfphase ist ein Bericht zum Migrationsergebnis: was migriert wurde, was nicht und was offen ist. Zusammen mit dem Bereitschaftsbericht aus Phase 1 dokumentieren die beiden den vollständigen Prüfpfad.

Das PMO verantwortet das Migrationshandbuch, aber das Ressourcenmodell hat Folgen, die Finanzteams nach der Umstellung entdecken, wenn niemand sie vorher anspricht. Drei Muster tauchen in jeder Migration mit kostenbewerteten Ressourcen auf, und jedes trifft anders als Probleme auf der Seite des PMO.

Drei Satzbegriffe, die verwechselt werden

Project Server führt drei verschiedene Sätze pro Ressource, die ähnlich klingen und NICHT austauschbar sind: den Standardsatz (die Kosten einer internen Stunde für die Auslastungsplanung, oft voll belastete Personalkosten), den Kostensatz (der Satz, mit dem die buchhalterischen Kosten eines Zeitnachweises berechnet werden, manchmal aufgeteilt in die Satztabellen A bis E für verschiedene Tätigkeitsarten) und den Verrechnungssatz (der Satz, der einem Kunden für abrechenbare Stunden in Aufträgen berechnet wird). Manche PMOs nutzen einen Satz für alle drei Begriffe; manche getrennte Sätze pro Begriff; manche Stufen von Satztabellen innerhalb der Begriffe.

Fragen Sie vor dem Export die Finanzabteilung, welche Satzbegriffe sie tatsächlich nutzt, welche Stufen der Satztabellen zu welchen Tätigkeiten gehören und welche Felder der Zielplattform jeder Satz füllt. Der Export ist eine Zeile pro Satz und Ressource; der Import ist eine Zuordnungsentscheidung, die bestimmt, ob die Berichte zur Umsatzrealisierung im nächsten Quartal aufgehen. Ein häufiger und behebbarer Fehler ist, Verrechnungssätze in das Feld für Kostensätze zu laden. Die kostenbewertete Zeiterfassung rechnet dann mit dem Verrechnungssatz, GuV-Berichte zeigen überhöhte Kosten, und die Lösung ist ein erneuter Export und ein erneutes Laden. Ein schlimmerer und schwerer zu behebender Fehler ist, Kostensätze in das Feld für Verrechnungssätze zu laden. Rechnungen mit dem falschen Satz müssen neu ausgestellt werden, und das Gespräch zur Korrektur mit dem Kunden ist nicht umsonst.

Aktivierungsregeln ziehen nicht von selbst mit

PMOs in regulierten oder investitionsstarken Organisationen haben oft Regeln zur Aktivierung von Personalkosten, etwa: „Ingenieurstunden in aktivierungsfähigen Projekten fließen in einen Vermögenswert der Bilanz statt in den Aufwand.“ In Project Server liegen diese Regeln meist als Ansichten oder Berichte auf dem OData-Feed, manchmal mit einem Kennzeichen pro Projekt und einem pro Vorgang. Nichts davon wird automatisch migriert. Die Kennzeichen werden exportiert (Werte benutzerdefinierter Felder), die Ansichten und Berichte nicht. Die Finanzabteilung muss die Berichte zur Aktivierung auf der neuen Plattform von Grund auf neu bauen, auf denselben gekennzeichneten Daten.

Das Risiko ist ein stilles Quartal, in dem die Berichte zur Aktivierung nicht neu gebaut wurden, Stunden, die hätten aktiviert werden müssen, als Aufwand gebucht wurden und die Periode mit falschen Zahlen abschließt. Wesentliche Fehler sind hier eine Feststellung der internen Kontrolle. Lassen Sie die Finanzabteilung den Neubau der Aktivierungsberichte als parallelen Arbeitsstrang zur Migration planen, nicht als Nacharbeit, und knüpfen Sie die Umstellung an mindestens eine abgeschlossene Periode mit aufgehenden Aktivierungsberichten nebeneinander.

Berichte zur abrechenbaren Auslastung brauchen eine ausdrückliche Einrichtung

PMOs im Dienstleistungsgeschäft leben von der abrechenbaren Auslastung (abrechenbare Stunden geteilt durch bezahlte Stunden, pro Ressource und zusammengefasst). Project Server erzeugt sie aus den Zeiterfassungsdaten zusammen mit einem Kennzeichen „abrechenbar“ auf Ebene der Zuweisung oder des Vorgangs. Das Kennzeichen wird sauber exportiert; der Bericht nicht. Wie die Vergleichsmatrix oben zeigt, ist die Unterstützung für eingebaute Berichte zur abrechenbaren Auslastung je nach Zielplattform verschieden. Onplana, Smartsheet RM und Workfront liefern den Bericht als vollwertiges Element; Planner Premium von Microsoft kennt das Konzept der Abrechenbarkeit gar nicht.

Für PMOs, die auf eine Plattform mit abrechenbarer Auslastung wechseln, knüpfen Sie die Umstellung an einen Bericht nebeneinander für die letzten 4 Wochen, der innerhalb von ±2% aufgeht. Jede größere Abweichung deutet auf einen Fehler in der Satzzuordnung, ein fehlendes Kennzeichen „abrechenbar“ oder eine nicht migrierte Zuweisung hin. Für PMOs, deren Zielplattform die abrechenbare Auslastung nicht von Haus aus unterstützt, planen Sie, den OData-Schnappschuss in ein nachgelagertes BI-Werkzeug (Power BI, Looker, Sigma) zu speisen und den Bericht dort neu zu bauen. In beiden Fällen sollte die Finanzabteilung die Richtigkeit des Berichts freigeben, bevor die alte Plattform abgeschaltet wird. Sonst zeigt sich die Lücke beim ersten Monatsabschluss auf der neuen Plattform, und das ist der schlechteste Zeitpunkt.

Warum die Finanzabteilung vor der Umstellung mit am Tisch sitzen muss

In jeder Migration, in die die Finanzabteilung spät eingebunden wurde, wiederholen sich dieselben drei Probleme: Satzzuordnungen müssen neu gemacht werden, weil die Finanzabteilung die Lesart des PMO, welcher Satz welcher ist, nicht teilt; die Aktivierungsberichte wurden nicht neu gebaut, und der erste Quartalsabschluss auf der neuen Plattform wies die aktivierten Personalkosten falsch aus; die Abweichung der abrechenbaren Auslastung war größer als die Toleranz des PMO, weil die Finanzabteilung andere Regeln anwendet. Keines davon ist ein Plattformproblem; alle sind Abstimmungslücken. Die Lösung ist billig: Nehmen Sie die Finanzabteilung als benannte Freigabestelle in Phase 1 (Bestandsaufnahme) und Phase 4 (Zuweisen und prüfen) auf. Ihre Freigabe schließt den Kreis bei der Satzzuordnung, den Aktivierungsberichten und der Toleranz der abrechenbaren Auslastung. Ohne sie liefert das PMO die Migration aus, und die Finanzabteilung entdeckt die Kosten Wochen später, fast immer beim Monatsabschluss und fast nie zu einem Zeitpunkt, der eine geordnete Korrektur erlaubt.

Die Migration ist der Auslöser; die langfristige Frage ist, ob die Kapazitätsplanung Ihres PMO auf der neuen Plattform noch funktioniert. Vier Gewohnheiten unterscheiden Teams, die die Sorgfalt halten, von Teams, die abdriften:

• Eine verlässliche Quelle, durchgesetzt. Der unternehmensweite Ressourcenpool ist maßgeblich; projektlokal angelegte Ressourcen sind ein Frühindikator für Abdrift. Manche Plattformen können das Recht zum Anlegen pro Projekt sperren. Nutzen Sie das, wenn es verfügbar ist; wenn nicht, prüfen Sie jede Woche die Ressourcenlisten der Projekte gegen den unternehmensweiten Pool.
• Vierteljährliche Prüfung der Sätze. Standardsätze, die 12+ Monate nicht geprüft werden, entfernen sich von den tatsächlichen voll belasteten Personalkosten. Die kostenbewertete Zeiterfassung entfernt sich dann von der Wirklichkeit der Finanzen. Legen Sie einen vierteljährlichen Rhythmus fest, um die Satztabellen zu prüfen und neu festzulegen.
• Disziplin bei benannten Ausnahmen. Kalenderausnahmen sammeln sich still an. Eine Ressource mit 30 benannten Ausnahmen über 3 Jahre ist normal; ohne regelmäßige Prüfung versteinern die Ausnahmen. Prüfen Sie jährlich die Anzahl der Ausnahmen pro Ressource und entfernen Sie alles, was älter ist als die Aufbewahrungsfrist der Richtlinie.
• Weiterentwicklung des RBS. Die Berichtshierarchie, die zum Zeitpunkt der Migration richtig war, veraltet nach und nach, wenn sich die Organisation umbaut. Planen Sie alle 6 Monate eine Prüfung des RBS als Teil der allgemeinen Prüfung des Organisationsdesigns, damit der Zuschnitt der Kapazitätsansichten aussagekräftig bleibt.

Die Fragen, die PMOs zur Migration des Ressourcenmodells am häufigsten stellen. Das vollständige FAQPage-Schema steckt in den strukturierten Daten dieses Artikels, damit diese Fragen in der Funktion „Ähnliche Fragen“ von Google erscheinen.

Expand