IT-Chef Banque LBLux: "Die IT-Industrie ist unreif"

Herr Roeltgen, sicher kennen Sie das: Sie wollen ein Computerprogramm aufrufen, und auf dem Bildschirm erscheint eine Fehlermeldung. Geben Sie in solchen Momenten dem Hersteller des Programms die Schuld? Oder suchen Sie den Fehler bei sich selbst?

Ich habe täglich mit solchen Programmen zu tun. Deshalb suche ich den Fehler nicht bei mir. Ich denke vielmehr an Bill Gates und Konsorten und daran, dass irgendwo in deren Konzern etwas schiefgelaufen ist.

Allerdings wird jemand, der beruflich nichts mit IT zu tun hat, als Erstes denken: "Welches Knöpfchen habe ich falsch gedrückt? Was habe ich falsch gemacht?"

Sollte der Nutzer den Fehler bei sich suchen?

Roeltgen: Nein. Eine Software muss so programmiert sein, dass sie nicht abstürzt. Aber das ist die Schwäche vieler Programme: Sie werden nicht ausreichend getestet. Die Hersteller gehen einfach davon aus, dass der Nutzer das Programm oder sogar den Rechner nochmal startet und darauf hofft, dass es beim nächsten Mal besser läuft. Und tatsächlich hilft das ja auch meistens.

Kann der Hersteller diesen Frust vermeiden?

Ja, aber genau das ist das Problem. Die IT-Industrie ist unreif. Das Thema Qualität spielt bei der Softwareentwicklung eine untergeordnete Rolle. Es geht in erster Linie darum, neue Funktionalitäten schnell auf den Markt zu bringen, um sie schnell zu verkaufen. Wenn dann Fehler auftauchen, profitieren die Hersteller ja nur davon: Sie kassieren von den Kunden obendrein 20 Prozent Wartungsgebühren - für die Fehler, die sie selbst erzeugt haben.

Was Privatanwender betrifft, gehen die Hersteller davon aus, dass die Kunden immer jemanden finden, der ihnen helfen kann. Und so ist es ja meist auch. Deshalb fehlt der Industrie der Druck, mehr auf die Qualität zu achten. Das wird sich meiner Meinung nach in den nächsten Jahren auch leider nicht ändern. Wir nehmen das ja auch alle so hin, denn wir sind quasi süchtig nach neuen Anwendungen - ob privat oder im Beruf. Durch diesen Drang nach Neuem nehmen wir in Kauf, dass die Produkte unausgereift sind.

Sind die nicht ausgereiften Programme auch der Grund dafür, warum IT-Projekte oftmals länger dauern und um einiges teurer werden, als geplant?

Das ist ein wichtiger Grund, ja. Dazu muss man wissen: Software zu programmieren, ist Bastelarbeit. Die Anwendungen werden nicht industriell hergestellt, sondern zu einem gewissen Grad wird das Rad immer wieder neu erfunden.

Gibt es weitere Gründe, warum sich IT-Projekte oft verzögern oder sogar scheitern?

Das nenne ich das IT-Biotop: Unternehmen haben so unterschiedliche und spezielle Anforderungen an die IT, dass eine Vielzahl von unterschiedlichen Systemen im Einsatz ist. Die Softwareanbieter interessieren sich aber nicht für das Biotop, in das sie hineinkommen. Sie entwickeln ein Produkt, das in sich geschlossen gut funktioniert. Aber sobald es in einem anderen Biotop eingesetzt wird, gibt es Situationen, für das es nicht getestet wurde - und das Programm funktioniert nicht.

Sobald man ein Schräubchen an dem Programm verstellt, bricht alles zusammen. Das führt bei IT-Projekten oft zu enormen Verzögerungen oder sogar zum Scheitern. Ein einfaches Beispiel dafür ist, dass Software aus Amerika auf europäischen Rechnern erstmal nicht läuft, weil etwa Umlaute nicht berücksichtigt wurden.

Das löst auf beiden Seiten Frust aus: bei Herstellern und Nutzern. Was können diese dagegen tun?

Die Anwender müssen bereit sein, auch einmal länger auf eine Lösung zu warten. Wir wollen den Herstellern ja gar nicht die Zeit geben, die sie zum Testen bräuchten. Wir wollen lieber innerhalb von drei Wochen eine Lösung, die die Welt verändert. Da muss man aber realistisch sein und sehen, dass das so nicht funktionieren kann.

Und wer Software kauft, muss sich bewusst sein, dass ein IT-Projekt kein Autokauf ist: Dass man nicht etwas auswählen kann, das dann geliefert wird und sofort funktioniert. Ein IT-Projekt ist vielmehr wie ein Hausbau.

Inwiefern kann man IT-Projekte mit dem Bau eines Hauses vergleichen?

Beim Hausbau muss man die Statik berechnen und dafür sorgen, dass die Anschlüsse gelegt werden. Und dann tauchen immer wieder neue Probleme auf, die man aber irgendwie lösen kann. Am Anfang hat man zwar das Ziel vor Augen, aber den Weg dahin kennt man nicht so genau. Das ist bei einer Systemeinführung das Gleiche, wenn auch um einiges komplexer. Denn in der IT ist noch viel weniger standardisiert.

Zum Teil sind allerdings natürlich auch die Hersteller schuld, die einfach nicht genügend auf die Qualität ihrer Produkte achten. Als IT-Kunde ist man gegenüber dem Hersteller fast immer in einer schwächeren Position, aber CIOs sollten trotzdem versuchen, Garantieansprüche vertraglich festzuhalten. Auch sollten sie nicht immer die üblichen 20 Prozent Wartungsgebühren akzeptieren, aber das ist fast schon eine utopische Forderung.

Nach Ihrer Schilderung kann ein IT-Projekt niemals nach Plan verlaufen. Sollten Unternehmen bei der Planung von solchen Projekten also von vornherein pauschal Kostenaufschläge einplanen?

Das wäre sicherlich eine Maßnahme. Auf die Anschaffungskosten sollte man je nach Komplexität des Projekts das Zwei-, Fünf- oder Zehnfache draufschlagen. Was ebenfalls bedacht werden muss: Auch im laufenden Betrieb entstehen nach Einführung des Systems immense Kosten durch Wartung, neue Versionen und so weiter.

Sie haben über Ihre Erfahrungen in der IT-Branche ein Buch geschrieben mit dem Titel "Eine Million oder ein Jahr". Wie kommt es zu diesem Titel?

Das ist eine Phrase, die ich in meinem Berufsalltag oft höre. Wenn IT-Projekte entwickelt werden, setzen sich anfangs die Mitarbeiter aus den Fachbereichen zusammen und entwickeln eine Idee. Wenn sie diese der IT-Abteilung vorstellen, ist die erste Reaktion meistens: "Das wird aber eine Million kosten." Oder auch zwei oder drei. Da gibt es schon die ersten enttäuschten Gesichter. Was den zeitlichen Horizont betrifft, sieht es nicht viel anders aus: "Dafür müssen wir mindestens ein Jahr veranschlagen", heißt es dann.

Das ist immer wieder das gleiche Szenario: In den Fachbereichen ist der Optimismus groß, wenn man ein IT-Projekt anstoßen will - und die Enttäuschung auch, wenn man erklärt bekommt, was wirklich an Zeit und Geld eingeplant werden muss.

Sie plädieren also dafür, dass Firmen pessimistischer an IT-Projekte herangehen sollten?

Ich bin für mehr Realismus. Viele Probleme in unserer Branche entstehen dadurch, dass wir anfangs zu optimistisch sind. Aber dass Schwierigkeiten auftreten werden, ist so sicher wie das Amen in der Kirche. Und wenn man das, was man versprochen hat, nicht halten kann, ist das für alle hochgradig frustrierend.

In der IT-Branche wird derzeit intensiv über IT-Sicherheit diskutiert. Spektakulär war der Fall Société Générale , bei dem ein Händler durch unautorisierte Geschäfte mehrere Millionen Euro Schaden anrichtete. Ein Versagen der IT-Sicherheit?

Ja, eindeutig. Wenn man sich den Fall genauer anschaut, wird es einem schwindelig: Der Händler hat die Abteilung gewechselt. Dabei wurde schlicht und einfach vergessen, ihm die Zugriffsrechte für das IT-System zu sperren. Also eine regelrechte Bagatelle - die aber wahnsinnige Konsequenzen hatte.

Solche Beispiele gibt es viele, jeden Tag. Die meisten haben weniger heftige Auswirkungen und kommen deshalb nicht in die Medien wie bei der Société Générale. Aber wenn man sich als IT-Sicherheitsbeauftragter bewusst macht, welch kleinen Details für ein Unternehmen existenzbedrohend werden können, kann einem das wirklich den Schlaf rauben. Ein Höllenjob.

Hätte der IT-Verantwortliche der Bank den Schaden Ihrer Meinung nach abwenden können?

Irgendjemand hat versäumt, dem Händler die Zugriffsrechte zu sperren. Also ein Fall von menschlichem Versagen. Da können Sie die besten IT-Prozesse der Welt haben - wenn sich ein Mitarbeiter nicht daran hält oder schlichtweg etwas vergisst, können Sie nichts dagegen tun.

Das ist wie beim Autofahren: Eigentlich wissen Sie, dass Sie am Stoppschild halten müssen. Aber in tausend Fällen passiert es Ihnen aus Unachtsamkeit doch einmal, dass Sie nicht stehen bleiben. Hundertprozentige Sicherheit hat man nirgends - auch nicht in der IT.