Für die Softwareentwicklung gilt: Je später ein Fehler entdeckt wird, desto teurer ist dessen Bereinigung. Diese Erkenntnis gehört nach Angaben von Andreas Dietrich, Chief Information Officer (CIO) und Senior Vice President bei der Thomas Cook AG, seit rund zehn Jahren zum "Allgemeinwissen" in der Informatik - häufig allerdings ohne konkrete Auswirkungen auf die Projektpraxis. "Hier verfährt die IT noch recht handwerklich", kritisiert der Konzern-CIO die in seinen Augen mitunter mangelhafte Professionalität der eigenen Zunft. Versäumnisse in Sachen Qualitätskontrolle mündeten in überteuerte Projekte, die sich erst mit großer Verzögerung zum Abschluss bringen ließen.
Kostspielige Fehler vermeiden
Der zweitgrößte Touristikkonzern Europas hat aus seinen Fehlern gelernt. Konkret hat er einen unternehmensweit standardisierten Prozess für den gesamten Projektverlauf - von der Begutachtung der Projektentwürfe über die Integrations- und Akzeptanzprüfung bis hin zur Rollout-Koordination - entwickelt. Mit Hilfe des neuen Qualitätssicherungsverfahrens namens "Q-Gates", das Thomas Cook mitterweile in jedem Projekt anwendet, hofft das Unternehmen, potenzielle Schwachstellen heute deutlich früher identifizieren und somit zeit- und kostenintensive Fehlentwicklungen in späteren Phasen vermeiden zu können.
Konkreten Handlungsbedarf sahen CIO Dietrich und sein für die Qualitätssicherung verantwortlicher Kollege Manfred Götz nach dem Abschluss eines sechs Millionen Euro teuren, hochkomplexen Mammutprojekts. Dieses wurde zwar schließlich zum Erfolg geführt, wies nach Angaben des IT-Chefs aber zwei schwerwiegende "Schönheitsfehler" auf: "Es hat viel zu viel gekostet und kam viel zu spät zum Abschluss." Das hätte sich vermeiden lassen. So sei zu Projektbeginn beispielsweise nicht sorgfältig genug geprüft worden, inwieweit vorhandene Systeme direkt oder über Schnittstellen von der Implementierung der neuen Software betroffen sein würden. Damit einhergehende Probleme machten sich dann erst im Verlauf der Umsetzung bemerkbar, was ein Nachsteuern erschwerte und die Gesamtkosten in die Höhe trieb. "Anfangs wurde das Ausmaß an Komplexität gar nicht umrissen", begründet Götz die Versäumnisse. Um unliebsamen Überraschungen und ihren kostspieligen Spätfolgen vorzubauen, müssten die großen Designentscheidungen künftig bereits im Vorfeld der Umsetzung gefällt und transparent gemacht werden, so der Quality-Assurance-(QA-)Spezialist des Konzerns.
Der Weg von der Grundidee, mehr Systematik in die Abwicklung von Großprojekten zu bringen, bis zur konzernweiten Einführung des Q-Gates-Prozesses nahm insgesamt fünf Monate in Anspruch. Das Qualitätssicherungsverfahren haben der CIO, der QA-Chef sowie Udo Bittner, Chief Architect des Unternehmens, gemeinsam entwickelt. "Ziel des Managements war es, innerhalb der IT Konsens über die Notwendigkeit des Prozesses zu schaffen", so der Chefarchitekt. Hierzu mussten laut Bittner zunächst alle Einzelabläufe und die dazu notwendigen Formulare nicht nur bis ins Detail festgelegt, sondern auch mit den Beteiligten abgestimmt werden.
Q-Gates umfasst sieben Qualitätssicherungsschritte. Demnach müssen heute alle Softwareentwicklungsprojekte bei Thomas Cook folgende Stufen durchlaufen:
- Q1: Im ersten Schritt wird die Projektidee vorgestellt und von einem internen Expertenteam kritisch betrachtet. Letzteres tagt einmal pro Woche und setzt sich unter anderem aus erfahrenen Projekt- und Qualitäts-Managern, Chief Architects sowie Integrations-, Controlling- und Einkaufsspezialisten zusammen. Nach einer ersten Einschätzung hinsichtlich Größe und Komplexität des Vorhabens wird das weitere Prozedere festgelegt.
- Q2: Etwa zwei Wochen später erfolgt die Prüfung des mittlerweile gereiften und deutlich detaillierteren Projektentwurfs durch das Expertenteam. Zu diesem Zweck hat der Projektinitiator im Vorfeld des Q2-Termins ein 20-seitiges "Project Initiation Document" (PID) auszufüllen, das die Angabe aller für die Projektplanung notwendigen Informationen verlangt. Nach deren Evaluierung werden die essentiellen Eckdaten - funktionale Anforderungen, integrative Aspekte, Zeitrahmen und Kosten sowie Risiko und Projektumfang - definiert, aber auch die jeweiligen Verantwortlichkeiten festgelegt. Im Idealfall erhält der Projektleiter daraufhin grünes Licht für sein Vorhaben, was zugleich das OK für die Beantragung des Budgets bedeutet.
- Q3: Auf dieser Stufe erfolgt das Fein-Tuning des Projektentwurfs. Die Qualitätssicherungseinheit überprüft in dieser Phase Projekt-, Organisations- und Testplan sowie Inspektions- und Audit-Termine. Daraufhin werden die diesbezüglichen Eckdaten festgelegt und gemeinsam mit dem Projektleiter verabschiedet.
- Q4: Es folgt die eigentliche Bauphase der Softwareentwicklung, in der die in Q3 festgelegten Check- und Inspektionstermine liegen. Darüber hinaus wird das Fachkonzept einer nochmaligen Prüfung unterzogen, um gegebenenfalls rechtzeitig korrigieren zu können. Parallel zur Produktentwicklung greift eine permanente Qualitätskontrolle, die - je nach gewähltem Vorgehensmodell ("Wasserfall", iterativ etc.) - unterschiedlich geprägt sein kann.
- Q5: Nun erfolgen die funktionale und die technische Integration sowie entsprechende "Akzeptanz"-Checks: In dieser Phase wird das Zusammenspiel aller Softwarekomponenten und Schnittstellen zu anderen Systemen getestet, um letztendlich den reibungslosen Gesamtbetrieb sicherzustellen.
- Q6: Die vorerst letzte Stufe dient zur Planung, Koordination und Ausführung des Rollouts. Hierzu werden alle Projektbeteiligten aus den Bereichen Infrastruktur, Softwareentwicklung und Qualitätssicherung noch einmal an einen Tisch gebeten, um ein Konzept zu erarbeiten, das die problemfreie Inbetriebnahme des neuen Produkts garantiert.
- Q7: Einige Wochen oder Monate nach Abschluss des Projekts greift dann die letzte Stufe des QA-Prozesses: Nun erfolgt die Bestandsaufnahme aller im Zuge der Projektabwickung gesammelten Erfahrungen. Zudem erklären alle Projektbeteiligten, inwieweit die einzelnen Ziele (Zeitplan, Kosten, Qualität etc.) auch tatsächlich eingehalten wurden. Dabei handelt es sich um einen für Thomas Cook wichtigen Regelkreis: Mit den daraus gewonnenen Erkenntnissen lässt sich das Expertenteam hinsichtlich der Beratung im Vorfeld künftiger Großprojekte entsprechend "updaten". Ferner können sich aus Q7 im Nachhinein notwendige Anpassungen an Architektur, Modellen, Templates oder Abläufen ergeben.
Die Konzeptionierung und Ausarbeitung des Vorgehensmodells Q-Gates hat Thomas Cook in Eigenregie vorgenommen. "Vier Monate lang waren im Schnitt etwa drei bis vier Mitarbeiter der Qualitätssicherung intensiv mit der Umsetzung des Projekts beschäftigt", blickt QA-Mitarbeiter Naby Diaw, der das Q-Gates-Projekt zusammen mit seinem Kollegen Tobias Grabo leitete, zurück. Den finanziellen Aufwand gibt der Konzern entsprechend mit insgesamt zwölf bis 16 Beschäftigungsmonaten an. "Damit lagen wir genau im Plan", so Grabo. Mit externer Unterstützung wären die Gesamtkosten nach Einschätzung von QA-Leiter Götz um den Faktor drei bis fünf höher ausgefallen.
Effizienz schwer messbar
Seit Anfang 2003 wird das Q-Gates-Modell angewendet. Laut CIO Dietrich haben mittlerweile rund 140 Projekte den Qualitätssicherungsprozess in irgendeiner Form durchlaufen. Wegen der kurzen Laufzeit haben aber erst wenige Vorhaben Q6 beziehungsweise das Rollout-Stadium erreicht. Entsprechend schwer zu ermitteln ist derzeit auch die über den neuen Standardprozess zu erzielende Effizienzsteigerung. "Die wahre Messgröße ist der reibungslose Betrieb", sagt Götz. Über einen angemessenen Zeitraum hinweg werde sich ermitteln lassen, wie viele nach dem Q-Gates-Regelwerk eingeführte Produkte störungsfrei vom Stapel liefen beziehungsweise in den ersten vier bis sechs Monaten ohne nennenswerte Unterbrechungen gearbeitet haben. "In zwei bis drei Jahren können wir dann angeben, um welchen Anteil die Störfälle im laufenden Betrieb seitdem zurückgegangen sind", blickt der Qualitätsexperte in die Zukunft.
Zu den Vorteilen zählt CIO Dietrich schon jetzt die höhere Qualität der Angebote von der IT an die Fachabteilungen. "Früher wurde vieles mit der heißen Nadel gestrickt, so dass man im Lauf eines Projekts immer mehr nachbessern musste", erinnert sich der CIO. Inzwischen sei nicht nur die Anzahl der Nachforderungen drastisch zurückgegangen, auch die Beantragung zunächst nicht in die Kalkulation einbezogener Extrabudgets sei mittlerweile Vergangenheit. Zudem würden die einmal für den Konzern festgelegten Architektur- und Sicherheitsstandards heute besser eingehalten - hierfür sorgen Chefarchitekt und Chief Information Security Manager, die ebenfalls im Q-Gates-Expertenteam sitzen. Darüber hinaus sei eine Reihe von Vorgängen - etwa der Prozess der Geldvergabe, der sonst häufig gesondert stattfinde und viel Zeit koste, - bereits in das Q-Gates-System eingeklinkt.
Problem Mensch
Auf reine Zustimmung ist das Q-Gates-Regelwerk allerdings nicht gestoßen: "Dem Projektleiter wurde damit ja zunächst ein Stück Freiheit geraubt", erklärt Dietrich die anfängliche Abwehrhaltung insbesondere von Seiten der "Stars" unter den Verantwortlichen. Laut Götz stellte auch das 20-seitige PID zu Beginn ein Problem dar. "Das auszufüllen ist schon ein administrativer Aufwand - und als solcher bei den meisten nicht gerade beliebt", so der QA-Chef. Sei dies jedoch erst einmal erfolgt, habe der Projektleiter in den Stufen Q1 und Q2 bereits sehr viel gedankliche Vorarbeit geleistet, was sich in den folgenden Phasen auszahle. Als gewöhnungsbedürftig habe sich auch erwiesen, die eigene Projektidee vor zehn bis 15 Experten vorzutragen und sich deren "Urteil" zu stellen. "Ein Qualitätssicherungsprozess darf keine Schiedsrichterfunktion im negativen Sinn haben, bei der rote und gelbe Karten verteilt werden, sondern muss das Spiel unterstützen", stellt Götz klar. Erfolgsentscheidend sei demnach, dass die Expertenrunde keinen Inquisitionscharakter annehme und sich deren Mitglieder partnerschaftlich verhielten. Auf diese Weise sei es dann auch gelungen, die Blockaden nach und nach abzubauen. "Mittlerweile wird das Prozedere weitgehend akzeptiert und als hilfreiches Gerüst empfunden", freut sich Götz.
Verstärkte Tool-Unterstützung geplant
Bei Q-Gates handelt es sich um einen Offline-Prozess: Zwar stehen die einzelnen Templates oder PID-Formulare, die sich zur Bearbeitung herunterladen lassen, und die Protokolle der wöchentlichen Projekt-Meetings im firmeneigenen Intranet zur Verfügung - eine durchgängig elektronische Projektabwicklung ist jedoch nicht möglich. Das könnte sich allerdings ändern: Nach einer gewissen Reifezeit und unter Einbeziehung der "Lessons Learned" will der Touristikkonzern die Weiterentwicklung des Prozesses in Angriff nehmen und den Gesamtablauf verstärkt durch Tools unterstützen. "Kommentar und Zustimmung aller Instanzen könnten beispielsweise auch im Umlaufverfahren - per Klick - erfolgen", so Götz. Auf diese Weise ließe sich auch die Budgetfreigabe automatisieren.
Momentan durchläuft das Projekt Q-Gates selbst die letzte Stufe (Q7) des Qualiätssicherungsprozesses. Zu den wichtigsten Erkenntnissen zählt Götz die notwendige aktive Einbindung aller Beteiligten in die Gestaltung der Abläufe, um deren Akzeptanz sicherzustellen. In jedem Fall sei ein Over-Engineering zu vermeiden: "So ein Prozess lässt sich nur verkaufen, wenn er einfach und geradlinig ist - ansonsten wird er nicht angewendet."
Thomas Cook AG
Unternehmen: Touristikkonzern.
Ziel: Ein einheitlicher und firmenweit verbindlicher Qualitätssicherungsprozess für die Abwicklung von Softwareentwicklungsprojekten.
Zeitrahmen: Mitte bis Ende 2002.
Stand heute: Wird seit Januar 2003 angewendet.
Ergebnis: Bessere Angebote von Seiten der IT an die Fachabteilungen; weniger Nachforderungen und kein nachträgliches Beantragen von Zusatzbudgets; genauere Einhaltung der Architektur- und Sicherheitsstandards; künftig weniger Störungen im Systembetrieb.
Realisierung: In Eigenregie.