Projektpannen am laufenden Band

  • Fehlerhafte Hartz IV-Software (2004): Zum Start der Arbeitsmarktreform Hartz IV streikte die Software, die das Arbeitslosengeld für Langzeitarbeitslose berechnete. Die von T-Systems entwickelte Anwendung „A2LL“ lief nicht stabil und löste Rechnerabstürze aus. Zudem wurden Zuschläge falsch berechnet, Datenfelder fehlten oder waren für die Erfassung gesperrt. Außerdem kam es bei der Berechnung der Krankenversicherungsbeiträge zu Rundungsfehler. Später wurde bekannt, dass eine nachgelagerte Software kurze Kontennummern falsch auffüllte. Statt Nullen voranzustellen, wurden sie hinten angehängt. Dadurch waren Konten nicht zuzuordnen.
  • Hartz-IV-Softwarepanne, die Zweite (2006):Im Dezember 2006 streikte die Software erneut, eine Bearbeitung von Erst- und Fortzahlungsanträgen für das Arbeitslosengeld 2 (ALG2) war nicht mehr möglich. Die Probleme tauchten auf, nachdem ein Update eingespielt wurde, hieß es zunächst. T-Systems wehrte sich allerdings gegen den Vorwurf, eine fehlerhaft implementierte Dialog-Software sei der Grund für die Pannenserie. Vielmehr sei das Problem durch ein Datenbank-Update hervorgerufen worden, betonte die Telekom-Tochter. Probleme mit Hartz-IV-Software
  • EDS und die britische Kindergeld-Behörde (2004): Der US-amerikanische IT-Dienstleister scheiterte 2004 spektakulär in Großbritannien und bescherte dem Steuerzahler einen Verlust von etwa einer Milliarde Pfund. EDS war beauftragt worden, für die britische Behörde Child Support Agency (CSA), die das Kindergeld auszahlt, ein neues IT-System zu entwickeln, das das Verfahren beschleunigt. Die implementierte Lösung CS2 überwies etwa 1,9 Millionen Berechtigten zu viel Geld, rund 700 000 bekamen allerdings zu wenig. Grund dafür war nicht allein die Software, denn zeitgleich hatte die britische Regierung die CSA reformiert. Update zwang die Software in die Knie.
  • Die Explosion der Ariane 5 (1996):Innerhalb von Sekunden zerbarst im 1996 Europas ehrgeizige Ariane-5-Mission. Die unbemannte Rakete explodierte 30 Sekunden nach dem Start vom Weltraumbahnhof Kourou in Französisch-Guayana, nachdem sie zuvor von ihrem Kurs abgekommen war. An Bord waren vier Satelliten im Wert von 500 Millionen Dollar. Später veröffentlichte die New York Times den Grund für die Panne. Die Ariane 5 nutzte die gleiche und bewährte Software wie ihr Vorgängermodell, die Ariane 4. Die neue Trägerrakete war jedoch schneller und konnte eine größere Nutzlast transportieren, dadurch fielen deutlich mehr und höhere Flugdaten an, die verarbeitet werden mussten. Letzten Endes löste die Umwandlung von Gleitkommazahlen in ganzzahlige Werte einen Overflow aus und setzte damit eine Fehlerkette in Gang. Das redundante System der Ariane 5 konnte die Katastrophe nicht verhindern. Es nutzte die gleiche Software.
  • Panne in der Entwicklung des Airbus A380 (2006): Die verteilte Fertigung bei Airbus brachte es mit sich, dass in verschiedenen Werken unterschiedliche Software verwendet wurde. Peinlich wurde dies, als die Werke unterschiedliche Versionen der CAD-Software Catia verwendeten. In Hamburg arbeiteten die Ingenieure mit einer älteren Version, im französischen Toulouse kam die aktuellste Ausführung zum Einsatz, die allerdings nicht abwärtskompatibel war. Als die an den jeweiligen Standorten entwickelten und gefertigten Teile zusammengeführt werden sollten, passten die Verkabelungsbäume nicht zueinander. Die Auslieferung des Airbus verzögerte sich um acht Monate.
  • Das Jahr-2000-Problem (1999/2000): Für die IT-Industrie wurde der Jahrtausendwechsel zum großen Fest. Sie verdiente prächtig an einem Fehler (beziehungsweise einer Unzulänglichkeit), den sie selbst mitverursacht hatte. Weil in den frühen Jahren der IT Speicherplatz teuer war, wurden Jahreszahlen nur zweistellig dargestellt. Die Zahlenkombination „00“ bezeichnete also sowohl das Jahr 1900 als auch das Jahr 2000. Zum Teil wurden auch ungültige Datensätze mit der Doppelnull gefüllt. Viele Anwenderunternehmen fürchteten finanziellen Schaden aufgrund falscher Berechnungen. Zudem drohten Computerabstürze und Sicherheitslecks in Anwendungen von Banken, Industrieanlagen und Kernkraftwerken.
  • Millionengrab Fiscus (1993 bis 2005): Zum Fass ohne Boden entwickelte sich das Föderale Integrierte Standardisierte Computer-Unterstütztes Steuersystem (Fiscus). Mehr als zwölf Jahre strebten die deutschen Bundesländer an, eine einheitliche Steuersoftware für rund 650 Finanzämter einzuführen. Dafür verbrauchten sie geschätzte 900 Millionen Euro. Ein brauchbares Ergebnis kam nicht dabei heraus. Die Anfänge nahm Fiscus im Jahr 1993. Die Bundesländer wollten die parallele Entwicklung mehrerer Lösungen zentralisieren, um Kosten zu sparen. Zudem sollten die ausufernden Altsysteme durch eine neue, moderne Applikation ersetzt werden. Während der Entwicklungsarbeiten wurden mehrfach die technischen Zielrichtungen verändert (etwa von der strukturierten zur objektorientierten Entwicklung). Schwierigkeiten bereitete zudem das Kompetenzgerangel zwischen den Bundesländern. 2005 wurde die eigens für das Projekt gegründete Fiscus GmbH liquidiert und das neue Projekt „Konsens“ gestartet.
  • Fiasko mit Personalausweisen in Großbritannien (1999): Im Juli 1999, ausgerechnet während der Ferienzeit, konnte die britische Passport Agency keine Reisepässe ausstellen. Statt der üblichen 50.000 warten damals 500.000 Ausweisanträge auf ihre Bearbeitung. Mehrere hundert Urlauber mussten ihre Reise stornieren, der finanzielle Schaden für die Behöre belief sich auf mehr als zwölf Millionen Pfund. Grund war die von Siemens entwickelt Software „Pass“. Siemens pochte darauf, man habe eine Anwendung nach den vereinbarten Vorgabe geliefert. Später räumte die Behörde Mängel im Test und in den Schulungen ein. Parallel zur Softwareeinführung führte die britische Regierung die Ausweispflicht für Kinder bei Auslandsreisen ein. Keine Pässe für britische Bürger
  • Hessens Desaster mit der Schulsoftware (2007): Das Bundesland Hessen erlebte mit der Einführung der neuen Schulverwaltungssoftware LUSD (Lehrer- und Schülerdatenbank) ein Desaster. Ziel der Software war eine zentrale Verwaltung aller Schüler und Lehrerdaten. Mit der Implementierung in den Schulen startete der beauftragte IT-Dienstleister CSC im Oktober 2006. Zur Eskalation kam es im Herbst 2007, als die betroffenen Schulsekretariate sich über anhaltende Performance-Probleme beschwerten und sich die Mängel zum Politikum entwickelten. Ursache der Leistungsprobleme war offenbar eine nicht sauber implementierte 3-Tier-Architektur aus Web-Client, Application- und Datenbank-Server. Im Laufe des Entwicklungsprojekts wurde Prozess- beziehungsweise Business-Logik auf dem Datenbank-Server statt auf dem Application-Server abgebildet.
  • Bremen ringt mit der SAP-Einführung (2003): Am 6. Januar 2003 teilte die Hansestadt Bremen offiziell mit, dass man als erstes Bundesland flächendeckend Geschäftsprozesse mit SAP R/3 abbilden will. Mit einem Etat von 13 Millionen Euro hatte die Stadt SAP-Module etwa für das Controlling, Finanzwesen, die Buchhaltung und die Materialwirtschaft eingeführt. Die Rechnungsprüfer warnten mehrfach vor einer vorschnellen Implementierung und wurden offenbar nicht erhört. Im Betrieb gab es dann Probleme mit den Schnittstellen, mit denen die Fachverfahren der Ressorts an das SAP-System angebunden wurden. Noch im März berichteten betroffene Mitarbeiter, dass kaum ein Fachverfahren reibungslos funktioniere.
  • Die Münchner Stadtwerke scheitern am SAP-Umstieg (2002): Von August 2001 bis März 2002 konnten die Münchner Stadtwerke keine Rechnungen verschicken. Das Unternehmen hatte im Herbst 2001 zwei neue Applikationen eingeführt, unter anderem eine Lösung für Energieversorger von der SAP, die offenbar noch nicht ausgereift war. Zudem habe die schlechte Qualität der Altdaten enorme Probleme bereitet, hieß es damals. Unterm Strich kam die Einführung zu früh. Die Verantwortlichen hatten auf eine schnelle Implementierung gedrängt, weil sie das seit 1979 genutzte R/2-System von SAP nicht mehr von D-Mark auf Euro umstellen wollten.

Hervorragende Skills des Trainers, fundierte Beantwortung aller Fragen rund ums Projektbusiness machen Fachmethoden und Praxiskenntnisse des Trainers deutlich. Meine Erwartungen wurden übererfüllt!

Markus Fäth, Deutsche Telekom