6. Der ahnungslose Kunde
Zugegeben, für ahnungslose Kunden können die Hersteller oft nichts. Wenn Anwender zu viel Vertrauen in die Unternehmen stecken und zu wenig ihren eigenen Verstand bemühen, kommen viele IT-Projekte zu Fall. "Die Kunden gehen mit unklaren Zielen in die Verkaufsgespräche. Nach der ersten Produktpräsentation wollen sie dann alles, was möglich ist - und das möglichst günstig. Wenn Sie dann mit ihnen sprechen, wird klar, dass die IT-Abteilung keine Ahnung hat, was die Sales-Abteilung und die Finanzbuchhaltung wollen", sagt Asuret-Berater Krigsman. "Sales versteht von der Technologie überhaupt nichts verantwortet dennoch in letzter Instanz die Kaufentscheidung." Jeder sei ein Stück weit verantwortlich, wenn es schiefläuft: Anwender, Dienstleister und Hersteller, so Forrester-Analystin Petouhoff. "Jeder Entscheidungsträger in den Anwenderunternehmen sollte vorher einmal für einen Software-Anbieter oder IT-Dienstleister tätig gewesen sein. So verstehen Sie die Eigenarten beider Welten können die richtigen Anforderungen formulieren und gute Verhandlungen führen."
Einige Probleme lösen sich von selbst: Je mehr Anbieter ihre Software als Service (SaaS) anbieten, desto einfacher wird es für die Kunden, von Verträgen zurückzutreten und ihre Investitionen zu kontrollieren. Ein gesunder Rest Misstrauen seitens der Anwender ist aber weiterhin angebracht. GoToBilling-Geschäftsführer Roderick bringt es auf den Punkt: "Viele Anwender lesen leider ihre Verträge nicht gründlich genug. Dann werfen Sie schnell alle Bedenken über Bord, und stimmen Bedingungen zu, die sich nach menschlichem Ermessen und marktüblichen Regeln zu gut anhören, um wahr sein zu können."
Leserkommentare erwünscht: Welche schlechten Erfahrungen mit Herstellern und Dienstleistern haben Sie gemacht? Nutzen Sie unsere Kommentarfunktion am Ende des Artikels und diskutieren Sie mit!
- Fehlerhafte Hartz IV Software (2004)
Zum Start der Arbeitsmarktreform Hartz IV streikte die Software, die die das Arbeitslosengeld für Langzeitarbeitslose berechnete. Die von T-Systems entwickelter Anwendung "A2LL" lief nicht stabil und löste Rechnerabstürze aus. <br /><br />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 Rundungsfehlern. <br /><br />Später wurde bekannt, dass eine nach gelagerte Software kurze Kontennummern falsch auffüllte. Statt Nullen voranzustellen, wurden sie hinten angehängt. Dadurch waren Konten nicht zuzuordnen. <br /><br /><a href="http://www.computerwoche.de/nachrichtenarchiv/549354/" target="_blank">Fehlerhafte Software bedroht Hartz-IV-Start</a> - 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. <br /><br />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. <br /><br /><a href="http://www.computerwoche.de/nachrichtenarchiv/585325/" target="_blank">Probleme mit Hartz-IV-Software</a> - EDS und die britische Kindergeld-Behörde (2004)
Der US-amerikanische IT-Dienstleister scheitert 2004 spektakulär in Großbritannien und bescherte dem Steuerzahler einen Verlust von etwa einer Milliarde Pfund. <br /><br />EDS war beauftragt worden, für die britische Behörde Child Support Agency (CSA), die das Kindergeld auszahlt, ein neues IT-System zu entwickeln, dass das Verfahren beschleunigt. <br /><br />Die implementierte Lösung CS2 überwies etwa 1,9 Millionen Berechtigten zuviel 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. <br /><br />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. <br /><br />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. <br /><br />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. <br /><br />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. <br /><br />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 wurde auch ungültige Datensätze mit der Doppelnull gefüllt. <br /><br />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ützte 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. <br /><br />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. <br /><br />Während der Entwicklungsarbeiten wurden mehrfach die technischen Zielrichtungen verändert (etwa von der strukturierten zur objektorientierten Entwicklung). <br /><br />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. <br /><br /><a href=" http://www.computerwoche.de/it_strategien/it_management/599350/index2.html" target="_blank"> Von Fiscus zu Konsens: Ein langer Weg geht zu Ende </a> - Hessens Desaster mit der Schulsoftware (2007)
Das Bundesland Hessen erlebte mit der Einführung der neuen Schulverwaltungssoftware LUSD (Lehrer- und Schülerdatenbank) ein Desaster. <br /><br />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 anhalten Performance-Probleme beschwerten und sich die Mängel zum Politikum entwickelten. <br /><br />Ursache der Leistungsprobleme war offenbar eine nicht sauber implementierte 3-Tier-Architektur aus Web-Client, Application- und Datenbank-Server. Im Lauf des Entwicklungsprojekts wurde Prozess- beziehungsweise Business-Logik auf dem Datenbank-Server statt auf dem Application-Server abgebildet. - Fehlerhafte Hartz IV Software (2004)
Zum Start der Arbeitsmarktreform Hartz IV streikte die Software, die die das Arbeitslosengeld für Langzeitarbeitslose berechnete. Die von T-Systems entwickelter Anwendung "A2LL" lief nicht stabil und löste Rechnerabstürze aus. <br /><br />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 Rundungsfehlern. <br /><br />Später wurde bekannt, dass eine nach gelagerte Software kurze Kontennummern falsch auffüllte. Statt Nullen voranzustellen, wurden sie hinten angehängt. Dadurch waren Konten nicht zuzuordnen. <br /><br /><a href="http://www.computerwoche.de/nachrichtenarchiv/549354/" target="_blank">Fehlerhafte Software bedroht Hartz-IV-Start</a> - 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. <br /><br />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. <br /><br /><a href="http://www.computerwoche.de/nachrichtenarchiv/585325/" target="_blank">Probleme mit Hartz-IV-Software</a> - EDS und die britische Kindergeld-Behörde (2004)
Der US-amerikanische IT-Dienstleister scheitert 2004 spektakulär in Großbritannien und bescherte dem Steuerzahler einen Verlust von etwa einer Milliarde Pfund. <br /><br />EDS war beauftragt worden, für die britische Behörde Child Support Agency (CSA), die das Kindergeld auszahlt, ein neues IT-System zu entwickeln, dass das Verfahren beschleunigt. <br /><br />Die implementierte Lösung CS2 überwies etwa 1,9 Millionen Berechtigten zuviel 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. <br /><br />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. <br /><br />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. <br /><br />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. <br /><br />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. <br /><br />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 wurde auch ungültige Datensätze mit der Doppelnull gefüllt. <br /><br />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ützte 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. <br /><br />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. <br /><br />Während der Entwicklungsarbeiten wurden mehrfach die technischen Zielrichtungen verändert (etwa von der strukturierten zur objektorientierten Entwicklung). <br /><br />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. <br /><br /><a href=" http://www.computerwoche.de/it_strategien/it_management/599350/index2.html" target="_blank"> Von Fiscus zu Konsens: Ein langer Weg geht zu Ende </a> - Hessens Desaster mit der Schulsoftware (2007)
Das Bundesland Hessen erlebte mit der Einführung der neuen Schulverwaltungssoftware LUSD (Lehrer- und Schülerdatenbank) ein Desaster. <br /><br />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 anhalten Performance-Probleme beschwerten und sich die Mängel zum Politikum entwickelten. <br /><br />Ursache der Leistungsprobleme war offenbar eine nicht sauber implementierte 3-Tier-Architektur aus Web-Client, Application- und Datenbank-Server. Im Lauf des Entwicklungsprojekts wurde Prozess- beziehungsweise Business-Logik auf dem Datenbank-Server statt auf dem Application-Server abgebildet.
Dieser Artikel von Dan Tynan erschien bei der CW-Schwesterpublikation InfoWorld und wurde aus dem Englischen übersetzt. (sh)