Ganzheitliche Projektplanung: Wie sich durch geringen Mehraufwand vor dem Projektstart hohe Zusatzkosten und viel Ärger danach vermeiden lassen

In vielen Unternehmen scheitert die termingerechte Durchführung von komplexen Projekten immer noch an althergebrachten „Silostrukturen“. Anstatt erst einmal eine vollständige, bereichsübergreifende Sicht auf alle funktionalen Teilprojekte und Systemschnittstellen zu werfen, wird in Parallelwelten gedacht.

Oft fehlt eine zentrale Projektsteuerung, die dafür sorgt, dass allen Beteiligten die Auswirkungen der Umstellung auch auf andere Bereiche und vor allem die bestehenden Abhängigkeiten im System klar werden. Die Folgen davon, dass nur die jeweils eigenen, bereichsrelevanten Funktionalitäten in der neuen Prozesslandschaft beschrieben werden, sind oft verheerend und treten zudem spät im Projekt zutage. Das Ergebnis: Die Übergabe passt nicht, was der eine wollte, stört beim anderen – mitten in der Umsetzung fällt dann sukzessive auf, was alles vergessen oder ignoriert wurde. Dies führt zu Konflikten, Zeitverlust und im schlimmsten Fall zu Deadlocks und/oder einem kompletten Stillstand.

Ein gutes Praxisbeispiel für derartige schwierige Verläufe ist die Einführung oder Ergänzung neuer SAP-Module im bestehenden System. Auch hier ist es wichtig, vor dem operativen Start des Projekts Bewusstsein für das Zusammenspiel der verschiedenen Systemkomponenten zu schaffen.

„Das haben wir schon immer so gemacht“ ist keine ausreichende Begründung

Wichtig ist auch, die bestehende Gesamt-Architektur zu durchleuchten, bevor neue Systeme integriert werden. Gibt es Workarounds, die endlich aufgelöst werden können und sollten? Sind die aktuellen Funktionalitäten optimal oder können/sollten diese mit der neuen Systemkonstellation verändert und verbessert werden? Dabei gilt: „Weil wir das schon immer so gemacht haben“ ist kein hinreichendes Argument für eine zweitklassige Lösung!

Durch die Erfassung aller integrativen Themen in der Pre-Projektphase und deren frühzeitige Sichtung und Priorisierung, können viele spätere Probleme und teure „Zusatzschleifen“ vermieden werden. Eine umsichtige Planung im Vorfeld der Umsetzung schont Ressourcen und sorgt dafür, dass das Projektteam nicht durch Zielkonflikte und Doppelarbeit aufgerieben wird.

Die Qualität (oder der Mangel) in der Vorbereitung macht sich spätestens in der Testphase bemerkbar. Umfassende funktionale und integrative Tests sind schon deshalb essenziell, damit die oben bereits beschriebenen Fehlerquellen nicht bis zum Hochfahren des neuen Systems oder Moduls unerkannt bleiben und zu echten Showstoppern werden.

Die Relevanz der Testphase darf also keinesfalls unterschätzt werden. Ein angemessenes Zeitfenster und detailliertes Test-Setup gewährleisten, dass prozessuale Abhängigkeiten, Schnittstellenfehler und sonstige unentdeckte Störfaktoren noch rechtzeitig erkannt und behoben werden können. Je höher der Zeitdruck im Projekt ist und je weniger eine ganzheitliche Projektsteuerung erfolgt ist, umso mehr sollte die Projektleitung ein umfassendes Testen einplanen und nötigenfalls auch einfordern.    

Die Testphase ist unantastbar!

Denn sonst wird die Verkürzung der Testphase ggf. als vermeintlich einfache Lösung eines häufig entstehenden Problems genutzt: Die Workshop- und Implementierungsphase verzögert sich und anstatt den Go-Live zu verschieben, wird einfach die so wichtige Test- und Schulungsphase verkürzt.

Deshalb hier ein kurzer Leitfaden, damit die Einhaltung der Testphase zur Qualitätssicherung und Fehlervermeidung in Ihrem Projekt sichergestellt ist:

• Bereits zu Projektbeginn sollte eine Verkürzung der Testphase als absolutes „No-Go“ in der Planung verankert werden
• Integrative Aufgabenstellungen und auch Tests sollten frühzeitig begonnen werden – bei der Planung unbedingt darauf achten
• Vertrauen der Key-User in externe Systemberater ist zwar grds. gut, darf aber niemals zu blindem Vertrauen werden. Auch wenn unter Zeitdruck versprochen wird, alles werde problemlos funktionieren, darf die Testphase keinesfalls auf derartigen Aussagen basierend verkürzt werden!
• Sowohl für Berater als auch für Key-User muss immer die Worstcase-Annahme gelten: “Was nicht getestet ist, wird nicht funktionieren!”
• Die Abarbeitung der Testfälle sollte in klar aufgeschlüsselten Testplänen dokumentiert sein, mit Vermerken über alle durchgeführten Tests und Testergebnisse (erfolgreich; noch mit Fehlern, …)
• Im Fehlerfall ist nicht nur eine Behebung des Fehlers zu gewährleisten, sondern auch unbedingt ein Re-Testing durchzuführen
• Das Test-Setup sollte die Testfälle in der nötigen Tiefe und Ausführlichkeit abbilden, nicht als mehr oder weniger zufälliges „One-hit-wonder“.
• Es sollten nicht nur rein funktionale Test durchgeführt werden, sondern immer auch eine Betrachtung von übergreifenden Prozessen aus Businesssicht erfolgen.

Abschließend eine Übersicht über mögliche etablierte Testvarianten, die je nach Projektumfang und -art erforderlich sein können:

Performance-Tests

• Massentests – viele parallele Buchungen

Prozess-Tests

• End-to-end-Tests – Prozesstests von Anlage der Stammdaten bis Verschrottung
• Funktionale Tests – Jede einzelne zur Verfügung gestellte Funktionalität wird getestet
• Prozesstests – Einzelne Prozesse werden durchgetestet
• Integrationstests – Unterschiedliche Abteilungen und Bereiche testen gemeinsam, jeder mit Blick auf seine Funktionen

Safety-Tests

• Anlagentests – Wenn Hardware angebunden wird (z.B. Robotik, Automatikgewerke), wird mit dieser getestet
• Affentests – Testen der Anwendungen, als würde man keine Ahnung haben, um sicherzustellen, dass keine Abbrüche erzeugt werden
• Cut-Over/Migrationstests – Alle Schritte im Rahmen der Produktivsetzung sind zu testen
• Negative Tests – auch eigentlich nicht betroffene Bereiche sind zu überprüfen, um negative Auswirkungen auszuschließen

Usability-Tests

• User Acceptance Tests – Key User und idealerweise Enduser testen gemeinsam die Prozesse und haben die Anwendbarkeit im Blick

Zudem lohnt es sich, immer auch einen Blick auf die Schnittstellen zu werfen. Wenn man die Punkte in der folgenden Checkliste beachtet, sollte auch für diesen neuralgischen Teil der IT-Architektur ein sicherer Projektstart gewährleistet sein:

Anzahl und Art der Schnittstellen:

• Welche Schnittstellen gibt es? (im Bezug zu anderen Modulen und im Prozess?)

Datenaustausch über die Schnittstelle

• Werden alle Daten übertragen, die für den weiteren Prozess notwendig sind?

Prozessübergreifende Integration

• Jedes Modul hat unterschiedliche Schwerpunkte – passen die Prozesse auch übergeordnet zusammen?

Weitere Schnittstellen betrachten:

• Nicht die organisatorischen Schnittstellen vergessen – passen die systemischen Schnittstellen zu den organisatorischen?

Wichtig: Erst einmal sollte man alle Schnittstellen definieren und überprüfen, ob alle Daten übertragen werden und somit der übergreifende Prozess funktioniert. Die einzelnen Prozessschritte im jeweiligen Teilbereich kann dann jedes Modul einzeln definieren.

Verbindliche Definition von Zuständigkeit und Verantwortung

Die verschiedenen Testvarianten können üblicherweise unterschiedlichen Bereichen und Teams zugeordnet werden. Dies sollte bereits in der Planungsphase berücksichtigt werden, damit es von Anfang an klare Zuständigkeiten für die Vorbereitung, Durchführung und Dokumentation der verschiedenen Tests gibt. Denn eine transparente Festlegung von Verantwortlichkeiten und Methodik bei der Durchführung und Dokumentation der Testfälle ist ausschlaggebend für deren spätere Qualität und Aussagekraft.

Wir unterstützen Sie in der Projektvorbereitung und Umsetzung! Wir bieten Ihnen die notwendigen Konzepte, um Ihre Projektstruktur geeignet aufzubauen und Ihr Projekt im Unternehmen zu begleiten. Aus unserer langjährigen Projekterfahrung resultiert ein Maßnahmenbaukasten, mit dem wir auf die wesentlichen o.g. Problemfelder mit genau darauf abgestimmten Handlungsempfehlungen reagieren können. Im Bedarfsfall verfügen wir darüber hinaus über ein Netzwerk versierter Dienstleister, die mit Kapazitäten und spezialisiertem Know-how operativ unterstützen können.