Die lehrreiche Reaktion des IT-Teams
- Die Geschichte von „Bruce“, der im Internet-Infrastrukturteam einer australischen Bank arbeitete.
- In den Anfangszeiten des Online-Bankings wuchs das Team schnell, und auch die Arbeitslast nahm zu.
- Das Team erkannte, dass zusätzliche ISDN-Links beschafft werden mussten, bevor die Auslastung der ISDN-Links die Hälfte überschritt, und legte dem CIO einen Vorschlag vor.
Die Ablehnung durch das Management und die Reaktion des IT-Teams
- Der CIO leitete die Anfrage zum Kauf zusätzlicher ISDN-Links an das Management weiter, doch sie wurde abgelehnt, weil die aktuelle Link-Auslastung noch nicht einmal bei 50 % lag.
- Als die Auslastung der Links 50 % überschritt, stellte das IT-Team erneut einen Antrag, erhielt jedoch die Anweisung, zu warten, bis sie sich 100 % näherte.
Die strategische Maßnahme des IT-Teams
- Das IT-Team entschied sich, die Netzwerkverbindung des Managements zu drosseln, damit dieses das Problem selbst wahrnahm.
- In der ersten Woche wurde sie um 10 % reduziert, danach jede Woche um weitere 10 %.
- Einen Monat später wurde die Installation zusätzlicher ISDN-Links genehmigt, und das Management beglückwünschte sich selbst dazu, das „Internetproblem“ gelöst zu haben.
Meinung von GN⁺
Das Wichtigste an diesem Artikel ist die strategische Reaktion des IT-Teams, das die Entscheidung des Managements infrage stellte und durch reale Nutzererfahrung von der notwendigen Infrastrukturinvestition überzeugte. Das zeigt einen kreativen und effektiven Ansatz, um die Lücke zwischen technischen Problemen und geschäftlichen Entscheidungen zu schließen. Die Geschichte ist nicht nur für IT-Fachleute interessant, sondern enthält auch eine Lehre, die nichttechnischen Entscheidungsträgern helfen kann, die Bedeutung technischer Infrastruktur zu verstehen.
1 Kommentare
Hacker-News-Kommentare
Ich habe einmal eine miserable Drittanbieter-Software verwendet, die bei Kunden große Probleme verursachte.
Wir entwickelten zwar eine interne Ersatzlösung, aber einige wollten den Vertrag verlängern und weiterhin dieselbe fehlerverseuchte Software nutzen.
Wir sorgten dafür, dass alle von Kunden eröffneten Tickets bei den Befürwortern der alten Lösung landeten, und nachdem wir schließlich auf unser System umgestellt hatten, gab es fast keine Probleme mehr.
Die Leute an der Front fangen diesen Schmerz oft heldenhaft ab, damit er nicht nach oben dringt, und die Organisation wirft dann lieber Menschen wie Schmerzmittel auf das Problem, statt es zu beseitigen, bis sie von diesem Zustand abhängig wird.
Das Altsystem konnte ohne umfangreiche Neuverkabelung praktisch nichts außer dem, was es ohnehin schon tat, und das zuständige Team glaubte, der Arbeitsplatz sei auf Lebenszeit sicher, solange es sein Wissen nicht teilte.
Das Team des neuen Systems glaubte, man müsse bei Datenbanklatenz nur mehr CPU hinzufügen, statt die Queries zu reparieren.
Die beiden Teams saßen direkt nebeneinander, redeten aber nicht miteinander, und das Team des Altsystems meldete sogar ein Paket unter dem Schreibtisch des IT-Direktors als Bombe.
Das Team des neuen Systems rief am Ende Oracle, und Oracle schrieb die Queries neu.
Die Fähigkeit, Risiken klar zu erklären und darzulegen, welche geschäftlichen Auswirkungen technische Folgen haben, ist eine Kernkompetenz für IT-Fachleute.
Vielleicht war das Management dieser Bank wirklich außergewöhnlich begriffsstutzig, aber es ist auch möglich, dass das Technikteam es nicht gut genug erklärt hat.
Vielleicht, weil ich selbst in der IT bin, aber ich habe den Eindruck, dass wir ziemlich gut und präzise kommunizieren.
Das eigentliche Problem ist vielmehr, dass die Politik der mittleren Managementebene alles verwässert.
Im Team kann man sagen: „Ich habe es vermasselt, ich muss es beheben“, aber weiter oben sitzen Leute, die selbst bei eher unwichtigen Entscheidungen alle möglichen Ausreden finden, nur um sie nicht zurücknehmen zu müssen.
Vielleicht hat ja schon jemand seinem Chef verkauft, dass diese Hardware noch weitere zehn Jahre nutzbar ist.
Wenn ich mit Kollegen arbeite, sehe ich eher, wie viel Mühe sie sich geben, Dinge auf mehreren Ebenen und passend zum jeweiligen Gegenüber zu erklären.
Viel häufiger ist es so, dass die Geschäftsführung und die Manager darunter sich einfach nicht dafür interessieren.
Sie haben bereits einen „großen Plan“ im Kopf, und egal wie oft Entwickler sagen, dass diese Illusion nicht Realität werden kann, ändert sich nichts.
Meistens verstehen sie vollkommen, was wir sagen.
Wir werfen nicht mit obskurem Fachjargon um uns, den nur Nerds höherer Ränge kennen — es ist einfach so, dass es sie nicht interessiert.
Ich wünschte, es gäbe weniger Unternehmen, die von MBA-Typen ohne Kopf und Herz geführt werden, und mehr Organisationen, in denen Ingenieure mehr Verantwortung tragen, aber so ist das Leben nun einmal.
Die Unternehmens-IT ist aus der Unterstützung von Büroarbeit hervorgegangen, und als es im Wesentlichen nur darum ging, dass Faxgeräte oder PCs funktionieren, brauchte es dafür keine strategische Planung, deshalb galt die IT anfangs als unwichtige Abteilung.
Man geht leicht davon aus, dass die Leute in Anzügen geizig oder dumm sind oder Technik einfach nicht verstehen, aber tatsächlich liegt es oft auch an mangelnder Kommunikationsfähigkeit.
In meinem ersten Job lehnte der CFO die Anfrage nach einem ordentlichen Backup-System für das AS/400 immer wieder ab.
Auf diesem AS/400 liefen ERP, CRM, Buchhaltung und praktisch der gesamte Betrieb des Unternehmens, und die Arbeit von 300 Leuten auf 8-Zoll-Disketten zu sichern, war von vornherein unmöglich.
Eines Tages gab es einen großen Festplattenausfall, und das gesamte Unternehmen stand mehrere Wochen lang still; Auftragsbearbeitung, Supportanfragen, Vertriebsangebote sowie das Nachschlagen von Kundennummern und Adressen waren komplett blockiert.
Soweit ich mich erinnere, gingen einige Festplatten zu Kroll Ontrack.
Erst nach dieser Katastrophe wurde ordentliche Backup-Hardware angeschafft.
Einige Monate später führte ein studentischer Entwickler in der Produktion eine Delete-Query aus, bei der die
where-Klausel auskommentiert war, und eine ganze Tabelle wurde gelöscht.Es gab zwar Backups, aber ein Hintergrundjob erkannte das und generierte vier Jahre an Rechnungen neu, woraufhin E-Mails an alle früheren Kunden gingen, sie sollten noch einmal zahlen.
Eine Testumgebung wurde kurz darauf eingerichtet.
Ich arbeitete vor Kurzem an einem abgelegenen zweijährigen College, wo alle Daten auf einem alten AS/400 lagen, das alle paar Wochen für ein oder zwei Tage ausfiel.
Es gab keine Backups, das Bandlaufwerk war defekt, und selbst Teile wie eine 10-Mbps-NIC, die schon damals veraltet war, hatten keinen Ersatz mehr.
Ich forderte immer wieder, das System zu ersetzen oder auf einen Cloud-Server umzuziehen, aber die Antworten waren nur „nicht im Budget“ und „zu teuer“.
Nach der tatsächlichen Nutzung hätte das nur ein paar hundert Dollar im Monat gekostet, was im Vergleich zum Risiko, dass beim Ausfall des Systems das gesamte College kollabiert und vielleicht dauerhaft schließen muss, absurd war.
Schließlich trat eine Störung auf, und mehrere Tage lang war das System zwar über das Hauptterminal erreichbar, konnte aber überhaupt nicht mehr mit dem Netzwerk kommunizieren.
Die Leute begannen in Panik zu geraten, und es wurde sogar darüber gesprochen, einen AS/400-Reparaturspezialisten für mehr als 100 Dollar pro Stunde zu holen.
Als letzten Versuch bekam ich die NIC wieder zum Laufen und machte dabei zugleich unmissverständlich klar, dass dies der letzte Bootvorgang sein könnte und vorher unbedingt irgendwo ein Backup erstellt werden müsse.
Sechs Wochen später hatten wir ein glänzendes cloudbasiertes AS/400, und wir hielten eine kleine Beerdigung ab, als wir dieses alte, schwere Biest zum letzten Mal abschalteten.
Die endgültige Betriebszeit lag bei fast 25 Jahren.
Man könnte sagen, dass diese Geschichte unwahrscheinlich oder komplett erfunden ist, aber ich sehe das nicht so.
Um in einer großen Organisation etwas zu erreichen, muss das Management meinen Schmerz spüren.
Das ist kein Zynismus, so funktioniert die Welt nun mal.
Wer erwartet, dass die andere Seite alle gedanklichen Zwischenschritte zum Verständnis der Situation von selbst durchläuft, wird ein böses Erwachen erleben.
Selbst Anfang der 90er dürfte ISDN außerhalb von Außenstellenbüros nicht besonders verbreitet gewesen sein.
Und wenn dann noch von Traffic Shaping/QoS die Rede ist, wird es noch schwerer zu glauben.
Soweit ich weiß, unterstützten die damals fast überall eingesetzten Cisco-2500/2600-Router solche Funktionen erst viel später.
Vielleicht war eigentlich T1 gemeint; es hat stark etwas von r/thathappened.
Per Definition machen Manager andere Dinge als die Leute in der Umsetzung.
Wie soll man einen Manager zum Beispiel den Schmerz einer chaotischen Codebasis spüren lassen?
Bei der Arbeit haben wir versucht, Kosten zu sparen, indem wir einen Cisco 1604 ISDN-Router nicht dauerhaft verbunden ließen, sondern auf automatisches Einwählen stellten.
Dann stellten wir fest, dass ein IBM AIX mit installiertem Webbrowser-Paket stündlich einen periodischen Telemetrie-Anruf zu Big Blue absetzte, wodurch das Labornetz nie in den Leerlaufzustand herunterfahren konnte.
Ich habe auf dem Router eine Firewall-Regel hinzugefügt, um diese heimliche Aktion zu unterbinden.
Selbst Ende der 90er waren Microsoft, Sun und Novell bei Telemetrie nicht annähernd so dreist wie IBM.
Das eigentliche Problem hier ist, dass die IT ein gewisses Maß an Autonomie braucht, um Dinge, von denen sie weiß, dass sie richtig sind, einigermaßen unabhängig von der Business-Seite umzusetzen.
Am Ende entscheidet Vertrauen darüber, wie viel Kontrolle man in einer Organisation akzeptieren muss.
Wo ich bin, muss man nicht um Erlaubnis fragen, solange keine Kunden betroffen sind.
Wenn eine Maschine überlastet wirkt oder ein SaaS-Tarif an seine Grenze kommt, wird einfach upgegradet.
Gelegentlich fragt jemand nach einer neuen Rechnung oder nach gestiegenen Kosten, aber man muss nicht durch mehrere Verhöre, nur um die Arbeit erledigen zu können.
Leute im Anzug sollten mal über die Nachteile einer Umgebung nachdenken, in der man für jede kleine technische Aufgabe um Erlaubnis betteln muss.
Wie viel Innovation landet wohl direkt im brennenden Müllcontainer wegen komplexer Change-Richtlinien, die vor mehr als zehn Jahren irgendwo im Elfenbeinturm entstanden sind?
Könnte man die Organisation nicht neu denken, indem man das Business als Kunden des IT-Teams modelliert?
Wenn das Unternehmen scheitert, hat auch die IT-Organisation keinen Existenzgrund mehr, also erscheint mir das als deutlich einfacherer Denkansatz.
Dadurch verschiebt sich also das Kosten-Nutzen-Verhältnis, und deshalb braucht es Kommunikation.
Bei Reaktionen nach dem Muster „Deine Aufgabe ist es, die Entscheidungen der Hierarchie zu respektieren“ wird einem wieder bewusst, wie stark Unternehmensorganisationen noch immer in einem militärischen Denken verhaftet sind.
Im alten preußischen Heer wurden Aufträge zielorientiert vermittelt.
So nach dem Muster: „Ich will X erreichen, du übernimmst Y, andere Einheiten machen Z“, und die Ausführung wurde dem lokalen Offizier überlassen, der die Lage tatsächlich sah und auch das nötige Wissen hatte.
Außerdem konnten Offiziere oder Unteroffiziere, wenn sie mit einem Befehl ihres direkten Vorgesetzten nicht einverstanden waren, bei der nächsthöheren Ebene Einspruch einlegen.
Zusammen mit einem Generalstabssystem, in dem Stabsoffiziere im Rahmen ihrer Ausbildung ebenfalls Führungserfahrung sammeln mussten und Befehle eines Kommandeurs sogar aussetzen konnten, entstand so ein starkes und flexibles System zur Anpassung an veränderte Situationen.
Offiziere zögerten nicht, mit Vorgesetzten zu diskutieren, nach oben zu eskalieren oder, wenn sie es wirklich für nötig hielten, Befehle zu verweigern.
Denn so entstehen Zustimmung und Beteiligung auch in den unteren Dienstgraden.
Entscheidungen sollten möglichst auf der niedrigsten Ebene getroffen werden.
In der Moderne ist das etwas aus der Mode gekommen, aber soweit ich weiß, funktioniert keine Armee rein nach dem Prinzip „Deine Aufgabe ist es, Hierarchieentscheidungen zu befolgen“.
Zum Beispiel Bücher wie Extreme Ownership.
Vielleicht bin ich zu gehässig, aber bei so einer Führung würde ich mir einfach einen neuen Job suchen und das ganze Schiff untergehen lassen.
Aus Führungssicht vereinfacht: Angenommen, jedes Jahr kommen 100 ähnliche Vorschläge auf den Tisch, jeder kostet 1 Million Dollar.
Dann sind das selbst ohne Abschreibungen oder Steuerspielchen jedes Jahr reine Kosten von 100 Millionen Dollar.
Selbst für eine Bank ist das viel Geld, also sollte es strategisch eingesetzt und nicht verschwendet werden.
In diesem Bild ist es eine für Führung, IT und Geschäft durchaus gesunde Strategie, die Führung den Schmerz spüren zu lassen und intuitiv verstehen zu lassen, warum genau diese 1 Million Dollar diesmal gut angelegt ist.
Dazu kommt, dass Führungskräfte diejenigen sind, die die begrenzte Zeit, die Mitarbeitenden und die Kosten eines Unternehmens verwalten.
Natürlich sind sie darin meist nicht besonders gut, und aus Sicht des Unternehmens wäre die rein rationale Entscheidung wohl, sie ähnlich wenig luxuriös zu entlohnen wie normale Beschäftigte.
Aber nicht „das Unternehmen“ trifft Entscheidungen, sondern Menschen, und da spielen Politik, Anreize und Eigeninteressen hinein.
Führungskräfte kontrollieren den Fluss von Information, Entscheidungen, Ressourcen und Geld und verhalten sich daher wie Parasiten, die dem Wirtsunternehmen einen übergroßen Anteil absaugen.
Die Lösung dieses Problems bleibt als Übung dem Leser überlassen.
Wenn man nur hört: „Wir prognostizieren, dass die Leitung um Zeitpunkt X zu 50 % ausgelastet sein wird“, dann hat die IT es wirklich schlecht erklärt.
Wir wissen bei dieser Technik, dass 50 % Auslastung bereits Kundenverzögerungen oder Verbindungsfehler bedeuten.
Dann muss man sagen: „Wir erwarten, dass Kunden um Zeitpunkt X Verbindungsprobleme haben werden.“
Wenn man weiß, dass das 100-%-Limit nur ein theoretischer Wert ist, der nur unter Idealbedingungen erreichbar ist, dann muss man von der real nutzbaren Grenze ausgehen.
Wenn Menschen fundierte Entscheidungen treffen sollen, muss man ihnen die richtigen Informationen geben, und wenn die IT dafür bezahlt wird, diese Technik zu verstehen, dann gehört es auch zu ihrer Aufgabe, diese Eigenschaften so zu vermitteln, dass Leute im Anzug sie verstehen können.
Natürlich kann es sein, dass man sein Bestes getan hat, aber nur nach dem Text klingt es so, als wäre einfach ein Memo ohne diese Informationen verschickt worden.
Ich verstehe nicht ganz, warum die Formulierung „50% Auslastung“ so verwendet wird, als würde man einen Wasserhahn nur halb aufdrehen.
Wenn sich die Last auf einer einzelnen Leitung spitz konzentriert, kommt es doch ohnehin zu intermittierenden Leistungseinbrüchen, oder nicht?
Der Zeitanteil mit einer „schlechten Erfahrung“ dürfte je nach Verteilung sprunghaft ansteigen, sodass selbst 60% schon schwer erträglich wären.
Zum Vergleich: Eine Bar entscheidet anhand der durchschnittlichen Nachfrage, nur einen Kellner einzuplanen, und dann kommt der Freitagabend.
Genau das besagt die Kingman-Formel.
„Als die Auslastung über 50% stieg, schlug das IT-Team erneut vor, ISDN zu bestellen. Und erneut wurde der Vorschlag abgelehnt. Verbunden mit der Anweisung, erst wieder nachzufragen, wenn die Auslastung sich 100% nähert.“
Das ähnelt stark dem Umgang der Behörden mit Corona.
Es wirkt, als könnten Verantwortliche aus bestehenden Trends keinerlei Vorhersagen ableiten und würden erst reagieren, wenn die Katastrophe unmittelbar bevorsteht.