Von Raimund Vollmer
Das Prinzip Misstrauen
Natürlich war Taurus ein gefährliches Unterfangen. Aber das Risiko lag dabei nicht in einem Zuviel an Vertrauen, sondern in zu viel Misstrauen. Noch im Januar 1993 hatte John Watson, der 1989 von Coopers & Lybrand ausgeliehene Projektmanager des Systems, gegenüber der Presse geschwärmt: »Wir implementieren nicht einfach nur ein System in einer Organisation«, sondern es sollte sich über rund 280 Mitgliederfirmen erstrecken. Was Taurus dabei allein technisch so ungemein komplex machte, war der Anspruch, dass darüber »viele mit vielen« (Watson) kommunizieren können und das bei strengsten Sicherheitsanforderungen. Diese hatte in der Endphase das britische Wirtschaftsministerium aufgestellt und dabei die von IBM für das Pentagon entwickelten Verfahren empfohlen.
Hinzu kam, dass das Ministerium erst im Dezember 1991 seine Arbeiten an den Börsenvorschriften für Taurus beendet hatte. Dabei sollten sie bereits im November 1991 im Parlament verhandelt werden. Erst am Dienstag, 11. Februar, 1992, wurden sie dann in einer Nachtsitzung vom britischen Unterhaus genehmigt. Zu viele Einflüsse, geboren aus Misstrauen, strömten auf das Projekt in seiner Endphase ein. Damit war es überfordert. Politische und wirtschaftliche Märkte kollidierten und Taurus geriet genau dazwischen.
Die Schuld daran trugen hier wie in vielen andern Projekten die involvierten Bürokratien, die unentwegt von anderen Änderungen verlangen, damit sie sich selbst nicht ändern müssen. Der Software Guru Caspar Jones ermittelte damals, dass diese Nachforderungen in 80 Prozent der von ihm untersuchten Projekt-Fälle der Risikofaktor waren.
Einmal mehr zeigte sich beim Taurus Projekt: Für die Entwickler lag der Konflikt darin, dass die Ansprüche immer in der Gestalt technischer Komplexität daherkamen und nicht in ihrer ursprünglichen Form: als Probleme der Büro¬kra¬tie. Darauf ließen sich letztlich alle Verspätungen des Tau¬rus Projektes zurückführen. Unfähig selbst Risi¬ko zu übernehmen, verlagern Bürokratien stets die Verantwortung auf das Projektteam. Dies kann sich nicht wehren, weil dieser Transfer immer in technische Herausforderungen umschlägt, also eine Kategorie an¬nimmt, für die in der Tat dann das Team die Verantwortung trägt. Aber in Wirklichkeit ist die Komplexität am wenigsten technisch begründet, sondern politisch.
Für Sicherheitsstrategien bleibt dabei weder Platz noch Zeit ein Grund vielleicht, warum deutsche Computerexperten mehrheitlich glauben, dass IS Manager in den letzten zehn Jahren eher risikofreudig waren.
Paradoxon. Zuletzt hatte im Januar 1993 Rawlin erklären müssen, dass sich die Einführung des Systems aus technischen Gründen um min¬de-stens weitere sechs Monate verspäten würde. Der wichtigste Grund: die Komplexität bei der Verbindung
- von verteilten und unabhängigen Datenbanken, wie sie die Börsianer gefordert hatten,
- in jenes Hochsicherheitsnetzwerk, auf dem das Wirtschaftsministerium so energisch bestanden hatte.
Auf dieses Konzept hatte man sich 1989 nach jahrelangem Ringen und einem gnadenlosen Hickhack geeinigt. Taurus sollte gleichzeitig so sicher sein wie die Netze des Pentagons und so offen wie ein Scheunentor. Das war ein unlösbares Paradoxon und einer der Gründe, warum man seit den achtziger Jahren kaum noch Superprojekte angegangen wurden. Eines der beiden Parameter brauchte den Primat über den anderen: entweder Offenheit über Sicherheit oder umgekehrt. Das ist aber eine politische Entscheidung und keine technische. Irgendjemand musste dies entscheiden mit natürlicher Autorität und auf der Basis eines definierten und nach Inhalten, nicht nach Technik ausgerichteten Wert¬esystems. Doch dies konnte sich im Wechselspiel diverser formal bürokratischer Autoritäten überhaupt nicht ent¬wickeln. Technisch sollte geklärt werden, was inhaltlich vorher nicht fest¬gelegt worden war. So driftete das Projekt in eine unlösbare Pattsituation, die schließlich zu seinem Ende führte.
Man hatte versucht, mit Taurus ein Projekt zu realisieren, das die beiden kritischsten Punkte der Datenverarbeitung gleichzeitig und gleichwertig adressiert: in einer heterogenen Umgebung Vernetzung & verteilte Datenbanken. Das musste schief gehen. Doch es kamen noch eine Menge weiterer Faktoren hinzu, die Taurus das Leben geraubt hatten.
Schandfleck. 1981 erstmals angedacht, war dieses Projekt spätestens ab 1989 zu einem Schandfleck der City verkommen. Bis dahin gab es noch nicht einmal einen speziell verantwortlichen Manager, der die Gesamtaufsicht für dieses Branchen Projekt hatte. Das heißt: die Chance, dass sich eine natürliche Autorität bilden und mit der Aufgabe entwickeln konnte, wurde gar nicht gegeben. Zu spät dachten die Bürokraten daran, dieses Vakuum zu füllen. Der Job war 1989 dann John Watson übertragen worden, der Partner bei Coopers & Lybrand war und bereits das Vorgänger Projekt Talisman beim LSE in den siebziger Jahren geleitet hatte.
Watson hatte sich in den frühen achtziger Jahren um den Job des Börsengeschäftsführers beworben, war aber Rawlins Vorgänger, Jefferey Knight, unterlegen gewesen. Computerleute galten halt zu dieser Zeit als Spezialisten. Gut für Projekte, schlecht als unternehmerisch denkende Geschäftsleute, die zudem eine kataly¬sierende Wirkung für eine ganze Branche entwickeln. Doch für Superprojekte muss man beide Eigenschaften in sich vereinigen: man muss Techniker & Branchenkenner sein. Es wundert wohl damals wie heute niemanden, dass Bürokraten solche Leute nicht unter sich und schon gar nicht über sich haben wollen. Denn diese hybriden Managertypen bringen ihr ganzes selbstbezügliches System durcheinander. Watson konnte sich in diesem Geflecht nicht als natürliche Autorität etablieren, weshalb auch der britische Softwareexperte Fergus O'Connel bei seinem Rating des Taurus Projektes der Kategorie "Projektführer" null Punkte vergab.
Vielleicht hätte der Chief Executive des LSE, Rawlin, die Eigenschaften als Techniker und Branchenkenner in sich vereinigen müssen. Aber ihm gelang das ebenso wenig wie Hugh Smith. Vielleicht wäre das Projekt dennoch geglückt, wenn sie ein virtuelles Team gebildet hätten der eine mit dem Schwerpunkt auf der Technik, der andere auf die Politik.
Ein Dilemma wurde offenkundig, das sich in den achtziger Jahren entwickelte und in den neunziger Jahren das größte Managementgap erzeugen sollte: »Es gibt sehr wenige hybride Leute, deren Kenntnisse über die Technologie ebenso tief und breit sind wie im Bankengeschäft, um die derzeitigen Probleme lösen zu können«, stöhnte 1987 Michael Roden, Manager bei der Londoner Midland Bank. Und dieses Profil wird umso wichtiger, je mehr sich die Aufgaben in Richtung Strukturfragen verschieben. Solche Leute werden zum Beispiel gebraucht, wenn es etwa um ein Abrechnungssystem beim Zahlungsverkehr zwischen Banken geht.
TEIL I // TEIL II // TEIL III // TEIL IV // TEIL V // TEIL VI // TEIL VII //
Keine Kommentare:
Kommentar veröffentlichen