Über die Grossrechner des Eisernen Zeitalters – 60 Jahre digitale Transformation, Teil 2

Im 2. Teil der Miniserie schildern Chuck und Ken, ein Vater-Sohn-Gespann von IT-Experten, wie die Datenmengen aus den Lochkarten in verwertbare Informationen umgewandelt wurden und welche Rolle die ersten Grossrechner spielten. Ihre Anekdoten vervollständigen das Bild, wie diese ersten digitalen Transformationen vonstatten gingen.

Digitale Transformationen geschehen nicht einfach spontan; sehr oft werden sie verkauft. Neue Daten bedeuten neue Prozesse; neue Prozesse bedeuten neue Technologie; und neue Technologie bedeutet Verkäufer, die sie verkaufen. Heutzutage ist jeder auf der Käuferseite digital sensibilisiert, daher müssen Verkäufer heute über mehr technisches Wissen verfügen als ihre Kunden. Schauen Sie sich ihren Hintergrund an, und Sie werden immer häufiger IT-Fachleute mit Hochschulabschluss in den höchsten technischen Verkaufsfunktionen finden. Dies war nicht immer der Fall. Je weiter wir in die Vergangenheit zurückblicken, desto weniger technisch geschult waren die Hauptakteure. Der Verkaufsprozess erforderte nicht viel digitales Fachwissen, und die ersten Vertriebsmitarbeiter*innen hatten sicherlich keine Ahnung von Dingen wie Programmierung.

«Die 1960er Jahre waren das «eiserne Zeitalter», wenn es um Computer ging, und die Giganten – IBM, Univac, Honeywell – «trieben das Eisen an». Sie verkauften Computer an Unternehmen, stellten Programmierschulen für die Programmierer der Unternehmen zur Verfügung und – na ja, das war’s dann auch schon. Jedes Unternehmen musste sie programmieren, integrieren und testen, um sicherzustellen, dass sie funktionierten.

Beim Verkaufsprozess ging es noch nicht um Ingenieure, die Dialoge auf hoher Ebene führten – es war der gleiche «Taschenspielertrick» wie im Automobilgeschäft. Das Ziel war ein für die IT zuständiger Vizepräsident, selten ein Ingenieur oder Programmierer, sondern die Leiter der Finanz- oder Buchhaltungsabteilungen, denn dort befanden sich die Rechner. Die Verkaufsdemonstrationen sollten beeindruckend sein.

Als ich für einen grossen Anbieter arbeitete, konkurrierten wir mit der 1400er-Serie von IBM, dem Bestseller der Branche. Aber die Schwäche von IBM war, dass sie nur eine Sache auf einmal machen konnte. Unser Modell hatte «Background-Foreground», kein Multitasking, wie wir es heute kennen, sondern mindestens zwei Hauptfunktionen gleichzeitig. In unserem gut einstudierten Verkaufsgespräch rief mich der Verkäufer also zur Vorführung, und der Kunde gähnte, als ich eine 4-Band-Sortierung startete – jeder wusste, dass dies laaaange dauerte, und jeder hasste es, Zeit zu verschwenden. Dann liess ich unsere Maschine parallel einen komplexen Druckauftrag starten. Zwei grosse Aufgaben zur gleichen Zeit – da sagten sie: «Magie! Wo sollen wir unterschreiben?» (Chuck Ritley)

Funktionen brauchen geschulte Leute

Vor allem bei produktorientierten Unternehmen ist die Auswahl neuer Funktionen heute oft recht anspruchsvoll. Die Komplexität kann groß sein, und eine gute Abstimmung zwischen den Produktteams kann von entscheidender Bedeutung sein, z. B. bei der PI-Planung. Darüber hinaus können quantitative industrielle Ansätze wie Weighted Shortest Job First (oder WSJF) bei der Entscheidungsfindung hilfreich sein. Beide erfordern jedoch geschulte Experten, die sowohl die technischen Details als auch das Gesamtbild verstehen. Eine kürzlich durchgeführte Studie hat in überwältigender Weise gezeigt, dass «Investitionen in die Fähigkeiten der Mitarbeiter» für erfolgreiche digitale Transformationsprojekte heute von zentraler Bedeutung sind. Aber war dies schon immer der Fall?

«Es hat folgendermaßen funktioniert. Einen Grossrechner einzurichten war nicht einfach. Es erforderte einen enormen Aufwand an Arbeitsstunden. Damals gab es noch keine Standardsysteme, so dass jedes Programm für die Bedürfnisse des Unternehmens massgeschneidert wurde. Dies erforderte zwei wichtige Entscheidungen im Vorfeld: Was sollte zuerst automatisiert werden, und wer sollte es tun? Das «Was» konnte bis zur Ebene des Geschäftsführers gehen, zumindest für einen Segen. Spätere Warensysteme, z. B. MRP oder DRP, zwangen dazu, zuerst die Bestände einzurichten. Aber im Eisernen Zeitalter war das nicht der Fall. Wenn der CEO einer Vertriebsorganisation über eine starke und zuverlässige Lieferkette verfügte, konnte die Entscheidung lauten, zuerst die Umsatzberichterstattung zu automatisieren. In meiner Zeit bei einem großen Anbieter war der Vertrieb oft die allererste Aufgabe. Aber wenn der Vertrieb an erster Stelle steht, was kommt dann als nächstes? Und der Schritt danach, und so weiter. Jemand musste einen Systemplan aufstellen, aus dem hervorging, wie alle Daten miteinander verknüpft und zu verwertbaren Informationen werden sollten. Wer im Unternehmen kann Prioritäten für den Fortschritt setzen? Zumindest meiner Erfahrung nach war Fortbildung nicht üblich; die Mitarbeiter in den Unternehmen waren mit ihrer eigenen Arbeit beschäftigt, so dass es sinnvoll war, neue Datenverarbeitungsmitarbeiter von aussen zu holen. Heute gibt es keinen Mangel an Produktverantwortlichen oder Unternehmensarchitekten, aber damals halfen die Aussendienstmitarbeitenden des Herstellers im Rahmen eines Pauschalangebots. Als Programmierer/Analytiker arbeitete ich zum Beispiel eng mit den neuen Mitarbeitern des Unternehmens zusammen und schulte sie oft. Im Idealfall begann dieser Prozess mindestens 3 bis 6 Monate vor allen anderen Umstellungsarbeiten. Und da die Hierarchie noch nicht flach war, bedeutete dies oft einen langen Aufenthalt im Werk des Herstellers, um Zugang zu den Schulungsmaschinen zu erhalten. Unter der Leitung des Vertreters des Herstellers (also mir) entwickelten wir gemeinsam den Systemfahrplan und den Informationsfluss und legten ihn der Geschäftsleitung zur Genehmigung vor. IBM ging mit seinem Value Added Reseller (VAR)-Programm noch einen Schritt weiter: Jeder VAR war der Branchenexperte für eine bestimmte Geschäftsart und ein bestimmtes geografisches Gebiet. Sie übernahmen den Verkauf und die Installation; IBM lieferte die Hardware. Bei der digitalen Transformation im Eisernen Zeitalter ging es also darum, das Unternehmen ein System nach dem anderen zu transformieren. Um dies zu erreichen, mussten wir die neuen digitalen Mitarbeitenden einzeln umwandeln – und zwar im wahrsten Sinne des Wortes, indem wir sie gründlich in einer proprietären Technologie schulten. Das konnte fast ein Jahr dauern.» (Chuck Ritley)

Das Paralleluniversum und Big Bangs

Das Testen von Software ist heute eine gut etablierte technische Disziplin mit Ansätzen (Whitebox, Blackbox usw.), Techniken (Testautomatisierung usw.), Anforderungen (Nachvollziehbarkeit, Abdeckung usw.) und Tools. In einigen Märkten, z. B. in Indien, bilden die Ingenieurschulen Tausende von Software-Testingenieuren aus, die in Unternehmen arbeiten, die oft einen Fabrikansatz für das Testen verfolgen. Dies wird vor allem durch eine niedrige Hürde für die Zusammenstellung der benötigten Testdaten und eine hohe Durchsatzrate begünstigt. Der entscheidende Punkt ist jedoch, dass schnelle und gründliche Tests Big Bang-Rollouts ermöglichen, eines der klassischen Kennzeichen heutiger digitaler Transformationsprojekte. Bestehende Geschäftsprozesse und die sie unterstützenden Anwendungen werden herausgerissen und – in einem so genannten Big Bang – durch neue Prozesse und Systeme ersetzt. Wie wurden also die ersten Programme getestet? Und wie sahen die Einführungen aus?

«Im eisernen Zeitalter hatten wir diese Hilfsmittel nicht. Aber an Gründen für das Testen mangelte es nicht. Ein manueller Geschäftsprozess konnte digital transformiert werden. Oder später, als die Mainframes selbst durch neuere Mainframes ersetzt wurden, war es notwendig, die Programme in die neue Sprache umzucodieren – wir nannten dies Übersetzung. Stellen Sie sich vor: Eine einzige Programmausführung kann leicht zehntausend Lochkarten umfassen und viele Stunden in Anspruch nehmen. Wir verfügten zwar über einige grundlegende Hilfsmittel – insbesondere für die Übersetzung -, aber die wichtigste Technik, die wir für die Qualitätskontrolle einsetzten, hieß Parallellauf. Beim Parallelbetrieb wurde der neue Grossrechner eingerichtet, und zu Beginn eines Abrechnungszeitraums wurden die gleichen Daten in ihn eingespeist wie in das ursprüngliche System oder den Grossrechner, den wir ersetzten.

Am Ende des Monats wurden sie miteinander verglichen. Wenn alles funktionierte, waren alle Zahlen identisch. Aber je nach Art der Daten tauchte ein Fehler manchmal erst nach vielen Wochen in einem Datensatz auf. Für die Vertreter der Hersteller wie mich bedeutete ein fehlerfreier Lauf, dass das Monatsende ein Grund zum Feiern war. Was sich nicht geändert hat, ist der Artikel, den ich in den 1970er Jahren geschrieben habe: Für erfolgreiche Systeme muss man zuerst das Problem der Menschen beheben. Die Einführung eines neuen Systems bringt eine ganze Reihe neuer Probleme mit sich – die Probleme der Menschen. Es geht nicht darum, wie sich ihre Aufgaben ändern werden, sondern um ihre Rolle in der neuen Welt, wo und wie viel Wert sie liefern werden, und um ihre Ängste und Sorgen über die Zukunft.» (Chuck Ritley)

Miniserie zur digitalen Transformation

Dieser Artikel ist der zweite Teil einer vierteiligen Miniserie über die digitale Transformation. Teil 3 wird nächste Woche veröffentlicht.

Danksagung

Wir bedanken uns bei Maria Kreimer und Nikola Gaydarov für ausführliche Diskussionen, die wesentlich zu diesem Manuskript beigetragen haben.