Projektgeschäft: Einführung eines konzernweiten Projekt-Dashboards – Risiken frühzeitig erkennen, handlungsfähig bleiben und aktiv gegensteuern

I. Ausgangssituation
Im Projektgeschäft besteht die Herausforderung in der Unternehmenssteuerung regelmäßig darin, die aufgrund der Vielzahl individueller Projekte immanente Komplexität zu beherrschen, spezifische Risiken zu erkennen und die richtigen Maßnahmen frühzeitig einzuleiten. Die Steuerung der Liquiditätsflüsse auf Projektebene und ein professionalisiertes Claim-Management nehmen dabei eine zentrale Rolle ein.

In der Praxis lässt sich regelmäßig beobachten, dass in den Unternehmen zur fundierten Entscheidungsunterstützung häufig nur eine ineffektive Infrastruktur bereitsteht. Das bedeutet im Einzelnen: Verwendete Daten speisen sich aus inhomogenen Datenquellen (u.a. aufgrund anorganischen Wachstums und manueller Datenerhebung), sind dadurch häufig inkonsistent, nicht auf dem aktuellen Stand (keine automatisierte „Echtzeit-Synchronisation“) und erlauben keine konsolidierte Portfoliosicht. Strukturen interner Reporting-Prozesse weisen Defizite auf (u.a. Redundanzen von Reportings, Meetings und fehlende Kommunikation zwischen einzelnen Fachbereichen). Vorhandene Instrumente sind ungeeignet, bieten nicht die notwendigen Funktionalitäten (u.a. individuelle Auswertung nach unterschiedlichen Dimensionen, intelligente Priorisierung und „Drilldown“), verfügen über eine unzureichende Bedienbarkeit oder sind nicht vollständig implementiert (u.a. Schulung der Nutzer).

Herausforderungen in der Unternehmensführung

Symptome dieser Ausgangslage spiegeln sich im Unternehmen in der Regel in fehlender Verantwortungsübernahme der Mitarbeiter und Fachabteilungen, ausgeprägtem „Silodenken“ und Überlastung bzw. Überforderung der Mitarbeiter wider. Diese Fehlstände führen zu Unglaubwürdigkeit vorhandener Analysen und Reportings, somit zur Intransparenz über die aktuelle Projektsituation und einer erhöhten Reaktionszeit des Projektleiters. Durch mangelnde Transparenz wird die Liquiditätsentwicklung des einzelnen Projekts nur reaktiv betrachtet, Avalinanspruchnahmen werden nicht effizient gesteuert und der Zeitrahmen, um den Claims der Kunden zu begegnen, verkürzt sich deutlich.

In dieser Situation hat sich ein iterativer Ansatz bewährt, der mit wenigen Schritten auskommt, um die Geschäftsführung, das Controlling und den Projektleiter wieder in eine handlungsfähige, aktive Rolle zu versetzen und die Organisation gleichzeitig nicht zu überfordern.

Ein funktionierendes Entscheidungsunterstützungssystem (EUS) wird im Unternehmen dann erfolgreich implementiert, wenn einerseits technisch eine verlässliche, bedienbare Infrastruktur aufgebaut wurde und andererseits die internen Prozesse überdacht und Verantwortlichkeiten klar zugewiesen wurden.

II. Aufbau der technischen Infrastruktur
Beim Aufbau eines EUS sollten im Hinblick auf die Entwicklung einer technischen Infrastruktur die individuellen, auch vom Geschäftsmodell abhängigen Erfordernisse des Unternehmens betrachtet werden, um die Entscheider optimal zu unterstützen. Unter der Abwägung von Kosten und Nutzen sind vorhandene, unternehmensspezifische Infrastrukturen und Datenquellen zu berücksichtigen. Die Entwicklung der technischen Infrastruktur gliedert sich dabei in zwei systemische Ebenen, die zum Teil parallel entwickelt werden können.

Backend
Hier erfolgt die zentrale, strukturierte Datenablage, der aus einzelnen Fachbereichen zugelieferten, individuellen und nicht aggregierten Datenquellen. Zunächst bleibt der Prozess der Rohdatenerhebung damit erhalten und die Mitarbeiter sind optimal eingebunden. Zudem können als Datenquelle neben dem ERP-System (Enterprise Resource Planning) und manuell erhobenen Datenquellen (wie bspw. Microsoft Excel) auch externe Datenquellen (bspw. Aktienkurse, Wetterdaten, Wechselkurse) erhoben werden. Mittels des ETL-Prozesses (Extract, Transform, Load) werden die inhomogenen Datenquellen in einer Datenbank zusammengeführt (sog. „Single Point of Truth“). Die Synchronisation der Daten erfolgt automatisiert und der Detailgrad der Daten bleibt dabei erhalten. Um eine Zeitreihenanalyse zu ermöglichen, werden die Daten historisiert und mit Zeitstempeln versehen.

Frontend
Für das Frontend bieten sich unterschiedliche Business Intelligence-Tools (u.a. Tableau, Power BI) an, die dem Nutzer einen Zugriff auf verschiedene Visualisierungen bieten, verbunden mit der Möglichkeit, individuelle Analysen durchzuführen. Mit dieser Self-Service BI-Lösung erhält der Projektleiter auch vor Ort auf der Baustelle einen „live“-Zugriff (bspw. per Tablet oder Smartphone) auf alle relevanten Projektdaten.

Datenfluss

In beiden Ebenen hat sich die Methodik des „Rapid Prototyping“ bewährt. Hierbei wird auf eine umfangreiche Konzeptionsphase verzichtet, um frühzeitig mit der Entwicklung des Produkts zu beginnen.

Die frühe und regelmäßige Einbindung relevanter Mitarbeiter und zukünftiger Nutzer – unabhängig von der Hierarchie und über alle Fachbereiche – stellt sicher, dass frühzeitig Optimierungspotentiale identifiziert und Prioritäten richtig gesetzt werden. Die direkte Einbindung in den Entwicklungsprozess erhöht die Akzeptanz der erarbeiteten Lösung in der Belegschaft. In gemeinsamen Jour-Fixes (bspw. zweiwöchentlich) werden die Entwicklungsschritte in digitalen Kanban-Tafeln im Teilnehmerkreis zwischen Nutzern und Entwicklern diskutiert. Der Arbeitsstand des Prototyps wird für die zukünftigen Nutzer früh greif- und anwendbar, zudem können Vorschläge laufend eingebracht und berücksichtigt werden. Gemeinsam werden in diesen Terminen abschließend die Ziele für den nächsten Release definiert und priorisiert. Bewusst wird zu Beginn der Entwicklungsphase auf die vollständige Abbildung aller Projekte (Tiefe der Datenbasis) und eine umfassende Integration aller Themenbereiche (Breite der Datenbasis) verzichtet. Durch diese zyklische Arbeitsweise können Entwicklungsschritte mit suboptimaler Zielsetzung frühzeitig korrigiert werden (das Risiko, dass die Implementierung scheitert, wird drastisch reduziert).

Im Sinne eines „Minimal Viable Product“-Ansatzes werden iterativ Funktionalitäten ergänzt, Visualisierungen optimiert und zusätzliche Datenquellen schrittweise angebunden. Der Nutzerkreis wird anfangs auf „Key User“ begrenzt und schrittweise erweitert. Dadurch werden die Anforderungen der künftigen User kontinuierlich in das Produkt eingebaut. Zudem kann bereits nach kurzer Entwicklungsdauer ein Produkt mit einigen Funktionalitäten präsentiert werden. Ein „Abschalten“ der etablierten Prozesse ist nicht notwendig. Der Übergang zur neuen Lösung erfolgt fließend.

Zur optimalen Entscheidungsunterstützung bieten sich in der Gestaltung des Frontends adressatengerechte Varianten an. Dadurch wird die Geschäftsführung bspw. in die Lage versetzt, sich kurzfristig einen Überblick über das Projektportfolio zu verschaffen und kritische Projekte zu identifizieren. Der Projektleiter erhält dagegen ausschließlich Zugriff auf die von ihm gesteuerten Projekte und kann detaillierte Analysen durchführen.

Der visuelle Aufbau im Frontend erfolgt pyramidal und besteht aus drei Ebenen: Portfoliosicht, Einzelprojektsicht sowie Detailansichten je Thema und Projekt.

Pyramidaler Aufbau des Projekt-Dashboards

Die Portfoliosicht bietet eine übergeordnete und konsolidierte Betrachtung über alle Projekte und ggf. Einzelgesellschaften hinweg. In verschiedenen Visualisierungen werden die Projekte durch Vergleiche und Rankings basierend auf auswählbaren Parametern zueinander in Beziehung gesetzt. Von der Portfoliosicht ausgehend kann ein relevantes Projekt ausgewählt werden, um auf die projektspezifische Übersicht zu gelangen. Auf dieser Übersicht werden in verschiedenen Kacheln vordefinierte Themengebiete zu dem ausgewählten Projekt aufgezeigt, z.B. Projektstammdaten, die Ertrags- und Liquiditätsentwicklung oder die Fertigungsplanung.

Erkennt der Nutzer in dieser Übersicht Problemfelder in den jeweiligen Themenkacheln, so kann von hieraus in eine themenspezifische Detailsicht gewechselt werden, welche tiefergreifende Analysen ermöglicht. Dieser Aufbau bietet somit die Möglichkeit des Drilldowns von der übergeordneten Portfoliosicht bis auf die Detailebene einzelner Projekte.

Inhaltlich liegen die Informationen bereits teilweise im Unternehmen vor. Der Mehrwert eines Tools erscheint im Verhältnis zu den Kosten zunächst begrenzt. Der Vorteil liegt hier klar auf der automatisierten Bereitstellung eines Single Point of Truth, der für alle Adressaten als zentrale Anlaufstelle im Unternehmen gilt. Unterschiedliche Hierarchieebenen werden so in die Lage versetzt, auf Grundlage derselben Datenbasis zu diskutieren und Entscheidungen zu treffen.

III. Reorganisation interner Prozesse und Verantwortlichkeiten
Neben der Schaffung technischer Voraussetzungen ist in jedem Fall – das zeigt die Praxis – die interne Organisation auf Optimierungspotentiale zu untersuchen. Fehlt die Synchronisation der internen Prozesse mit der technischen Infrastruktur, sinkt die Akzeptanz des neuen Tools und gewohnte Routinen werden beibehalten.

Durch die schrittweise Umstellung der internen Prozesse im Rahmen der Entwicklung des Tools wird den Mitarbeitern kurzfristig der Nutzen der neuen Lösung sichtbar gemacht. Das schafft Vertrauen. Wesentliche Meilensteine betreffen:

  • die klare und eindeutige Zuweisung von Verantwortlichkeiten zu einzelnen Datenpaketen bzw. Prozessen
  • den Abbau redundanter Reportings (u.a. durch fachbereichs- und konzernübergreifende Katalogisierung vorhandener Berichte)
  • die Etablierung einer „Fehlerkultur“ (u.a. das Ableiten von Lessons Learned und die fachbereichs- und konzernübergreifende Dokumentation von Fehlerquellen)
  • die Definition von Routinen eines Eskalationsmanagements
  • das regelmäßige Nachhalten von nächsten
  • Schritten und dem Maßnahmenfortschritt auf Projektebene
  • die Incentivierung des fachbereichsübergreifenden Projektteams bei Projekterfolgen

Change-Management

Die oben genannten Punkte bilden den Rahmen für einen Change-Management-Prozess, um die internen Prozesse neu zu gestalten.

Dabei durchlaufen die Beteiligten in der Regel oben genannte Schritte (siehe Schaubild).

IV. Zusammenfassung
Im Ergebnis zeigt sich, dass auf Grundlage eines Projekt-Dash-boards, das als Single Point of Truth fungiert, eine zielgerichtete und adressatengerechte Kommunikation im Unternehmen erreicht wird. Projektleiter, Finanzer und Geschäftsführung können strukturierte und fundierte Entscheidungen treffen. Den Adressaten steht ein zuverlässiges Tool zur Verfügung, das entsprechend ihrer Informationsbedürfnisse entwickelt wurde und bekannte Datenquellen integriert. Der pyramidale Aufbau des Tools verhindert die Überlastung der Adressaten durch vielschichtige Informationen. Der integrative Entwicklungsansatz bindet die Mitarbeiter ein und erhöht die Motivation. Barrieren zwischen Fachabteilungen werden durch die klare Abgrenzung von Verantwortlichkeiten abgebaut und der Fortschritt von Maßnahmen ist nachvollziehbar und kontrollierbar. Redundante Tätigkeiten können im Unternehmen abgebaut werden und Meetings werden vorbereitet und strukturiert geführt.

Die Geschäftsführung wird nun optimal unterstützt, kann Risiken im Projektportfolio frühzeitig erkennen und das Unternehmen aktiv steuern.