Monat: September 2020

Obwohl die Sicherheitsforschung im Bereich des maschinellen Lernens noch in den Kinderschuhen steckt, ist es klar, dass barrierefreie Eingabemöglichkeiten die Bedrohungen erhöhen. Sie brauchen keine Tastatur mehr zu berühren, um ein maschinelles Lernsystem zu täuschen. Der Software-Sicherheitsexperte Balázs Kiss geht auf einige Punkte in diesem neuen Bereich ein und gibt Ratschläge zu den grundlegenden Schutzmaßnahmen.

Genau wie Software im Allgemeinen sind auch maschinelle Lernsysteme anfällig. „Einerseits sind sie wie neugeborene Babys, die sich ganz auf ihre Eltern verlassen, um zu lernen, wie die Welt funktioniert – einschließlich ‚Hintertüren‘ wie Märchen oder der Weihnachtsmann“, sagt Sicherheitsexperte Balázs Kiss von Cydrill, einem auf Softwaresicherheit spezialisierten Unternehmen. „Andererseits sind maschinelle Lernsysteme wie alte Katzen mit schlechtem Sehvermögen – wenn eine Maus lernt, wie die Katze jagt, kann sie leicht vermeiden, gesehen und gefangen zu werden.“

Es sieht nicht gut aus, meint Kiss. „Die Sicherheit beim maschinellen Lernen wird zu einem kritischen Thema.“ Er weist darauf hin, dass die meisten Softwareentwickler und Experten für maschinelles Lernen die Angriffstechniken nicht kennen. „Nicht einmal diejenigen, die der Software-Sicherheitsgemeinschaft schon lange bekannt sind. Auch die entsprechenden Best Practices sind ihnen nicht bekannt. Das sollte sich ändern.“

Der Sicherheitsexperte und erfahrene Softwaretrainer Balázs Kiss hat kürzlich einen neuen Kurs über die Sicherheit beim maschinellen Lernen entwickelt, der in Kürze vom High Tech Institute in den Niederlanden angeboten wird.

Lösungen für maschinelles Lernen (ML) sind – wie Softwaresysteme – auf verschiedene Weise angreifbar und erhöhen den Sicherheitsbedarf. Letztes Jahr wurde dies auf recht peinliche und einfache Weise von zwei Studenten aus Leuven aufgezeigt. Es gelang ihnen, Yolo (You Only Look Once), einen der beliebtesten Algorithmen zur Erkennung von Objekten und Personen, in die Irre zu führen. Indem sie ein Pappschild mit einem bunten Aufdruck von 40 mal 40 cm vor ihrem Körper trugen, machten sich Simen Thys und Wiebe Van Ranst als menschliche Personen unerkennbar. Ein weiteres Beispiel stammt von McAfee-Forschern, denen es gelang, den Tesla-Autopiloten zu täuschen, indem sie Geschwindigkeitsbegrenzungsschilder falsch einordneten und das Auto über 35 mph hinaus beschleunigen ließen.

Kennen Sie Ihren Feind

„Eine wesentliche Voraussetzung für die Cybersicherheit ist: Kenne deinen Feind“, sagt Kiss, der auch ein erfahrener Softwaretrainer ist und vor kurzem einen brandneuen Kurs über ML-Sicherheit entwickelt hat, der in Kürze vom High Tech Institute in den Niederlanden eingeführt wird. „Am wichtigsten ist, dass Sie mit dem Kopf eines Angreifers denken“, sagt er.

Werfen wir einen Blick darauf, was die Angreifer beim maschinellen Lernen ins Visier nehmen werden. Alles beginnt mit der Erforschung dessen, was Sicherheitsexperten als „Angriffsfläche“ bezeichnen: die Kombination aller verschiedenen Punkte in einer Softwareumgebung, an denen ein unbefugter Benutzer versuchen kann, Daten einzugeben oder zu extrahieren. Die Angriffsfläche so klein wie möglich zu halten, ist eine grundlegende Sicherheitsmaßnahme. Wie die Studenten aus Leuven bewiesen haben: Um ein ML-System zu täuschen, müssen Sie nicht einmal eine Tastatur anfassen.

Ein gängiges Sprichwort in der Welt des maschinellen Lernens lautet „Garbage in, garbage out“. Alle Algorithmen verwenden Trainingsdaten, um ihr Verhalten festzulegen und zu verfeinern. Schlechte Daten führen zu unerwartetem Verhalten. Das kann daran liegen, dass das Modell bei den Trainingsdaten gut funktioniert, aber die Ergebnisse nicht auf andere Beispiele verallgemeinern kann (Überanpassung), dass das Modell nicht in der Lage ist, die zugrundeliegenden Trends der Daten zu erfassen (Unteranpassung) oder dass es Probleme mit dem Datensatz gibt. Verzerrte, fehlerhafte oder mehrdeutige Trainingsdaten sind natürlich ein zufälliges Problem, und es gibt Möglichkeiten, damit umzugehen. Zum Beispiel durch die Verwendung geeigneter Test- und Validierungsdatensätze. Wenn jedoch ein Angreifer absichtlich schlechte Daten einspeist, ist das ein ganz anderes Szenario, für das wir ebenfalls spezielle Schutzmaßnahmen benötigen.

Angreifer sind schlau

Kiss: „Wir müssen einfach davon ausgehen, dass es böswillige Benutzer gibt. Diese Angreifer müssen nicht einmal besondere Privilegien innerhalb des Systems haben, aber sie können Roheingaben als Trainingsdaten bereitstellen und die Ausgabe des Systems sehen, typischerweise den Klassifizierungswert. Das bedeutet bereits, dass sie absichtlich schlechte oder bösartige Daten senden können, um unbeabsichtigte ML-Fehler auszulösen.“

„Aber das ist nur die Spitze des Eisbergs“, findet Kiss. „Denken Sie daran, dass Angreifer immer auf ein Ziel hinarbeiten. Sie werden bestimmte Aspekte der ML-Lösung ins Visier nehmen. Durch die Wahl der richtigen Eingaben können sie dem Modell, der generierten Vorhersage und sogar den verschiedenen Code-Bestandteilen, die diese Eingaben verarbeiten, großen Schaden zufügen. Angreifer sind schlau. Sie sind nicht darauf beschränkt, statische Eingaben zu senden – sie können lernen, wie das Modell funktioniert und ihre Eingaben verfeinern, um den Angriff anzupassen.“

Im Falle des überwachten Lernens umfasst es alle drei Hauptschritte des ML-Workflows. Für das Training kann ein Angreifer Eingabedaten zur Verfügung stellen. Für die Klassifizierung kann ein Angreifer Eingabedaten bereitstellen und das Klassifizierungsergebnis lesen. Wenn das ML-System über eine Feedback-Funktion verfügt, kann ein Angreifer auch falsche Rückmeldungen geben („falsch“ für eine gute Klassifizierung und „richtig“ für eine schlechte), um das System zu verwirren.

Handgefertigte Eingaben

Viele Angriffe nutzen sogenannte gegnerische Beispiele. Diese manipulierten Eingaben nutzen entweder das implizite Vertrauen aus, das ein ML-System in die vom Benutzer erhaltenen Trainingsdaten setzt, um seine Sicherheit zu beeinträchtigen (Poisoning) oder das System dazu zu bringen, seine Eingaben falsch zu kategorisieren (Evasion). Derzeit gibt es keine narrensichere Methode, mit der diese Beispiele automatisch erkannt und herausgefiltert werden können. Selbst die beste Lösung, bei der einem System beigebracht wird, negative Beispiele zu erkennen, ist in ihrer Reichweite begrenzt.

Indem sie ein Pappschild mit einem bunten Aufdruck von 40 x 40 cm vor ihrem Körper trugen, machten sich Simen Thys und Wiebe Van Ranst als menschliche Personen unerkennbar. Kredit: KU Leuven/Eavise

Natürlich gibt es Verteidigungsmaßnahmen zur Erkennung oder Abschwächung von Negativbeispielen. Ein intelligenter Angreifer kann jedoch Lösungen wie die Verschleierung umgehen, indem er auf adaptive Weise eine Reihe von Gegenbeispielen erzeugt. Kiss verweist auf einige exzellente Arbeiten, die dies hervorheben, wie die von Nicholas Carlini und seinen Kollegen bei Google Brain.

Alles in allem befindet sich die ML-Sicherheitsforschung noch in einem frühen Stadium. Die aktuellen Studien konzentrieren sich hauptsächlich auf die Bilderkennung. Allerdings sind einige Abwehrtechniken, die bei Bildern gut funktionieren, bei Text oder Audio möglicherweise nicht wirksam. „Dennoch gibt es eine Menge Dinge, die Sie tun können, um sich in der Praxis zu schützen“, verrät Kiss. „Leider schützt Sie keine dieser Maßnahmen vollständig vor bösartigen Aktivitäten. Alle diese Maßnahmen bieten jedoch zusätzlichen Schutz und erschweren die Ausführung von Angriffen.“

Das Wichtigste, so der Cydrill-Experte, ist, dass Sie mit dem Kopf eines Angreifers denken. „Sie müssen neuronale Netze mit gegnerischen Beispielen trainieren, damit sie diese Informationen ausdrücklich als falsch erkennen.“ Laut Kiss ist es eine gute Idee, gegnerische Muster aus allen derzeit bekannten Angriffstechniken zu erstellen und zu verwenden. Ein Test-Framework kann solche Muster generieren, um den Prozess zu vereinfachen. Es gibt bereits Sicherheitstest-Tools, die dabei helfen können – wie die ML-Fuzz-Tester Tensorfuzzs und Deeptest, die automatisch ungültige oder unerwartete Eingaben erzeugen.

Sanitätskontrollen

Die Begrenzung der Möglichkeiten des Angreifers, gegnerische Proben zu senden, ist immer eine gute Abschwächungstechnik. Dies lässt sich leicht erreichen, indem man einfach die Anzahl der von einem Benutzer akzeptierten Eingaben begrenzt. Natürlich ist es nicht einfach, zu erkennen, dass derselbe Benutzer hinter einer Reihe von Eingaben steckt. „Dies ist die gleiche Herausforderung wie bei verteilten Denial-of-Service-Angriffen, aber die gleichen Lösungen könnten auch funktionieren.“

Wie immer bei der Softwaresicherheit kann eine Eingabeüberprüfung helfen. Es mag nicht trivial sein, automatisch gute von schlechten Eingaben zu unterscheiden, aber es ist auf jeden Fall einen Versuch wert. Wir können auch das maschinelle Lernen selbst nutzen, um anomale Muster in den Eingaben zu erkennen. „Im einfachsten Fall, wenn die von einem nicht vertrauenswürdigen Benutzer erhaltenen Daten durchweg näher an der Klassifizierungsgrenze als am Durchschnitt liegen, können wir die Daten für eine manuelle Überprüfung markieren oder sie einfach auslassen.

Regelmäßige Überprüfungen mit Testdaten können ebenfalls hilfreich sein. Wenn Sie bei jedem neuen Trainingszyklus denselben Testdatensatz gegen das Modell laufen lassen, können Sie Vergiftungsversuche aufdecken. Kiss: „Ablehnen bei negativer Auswirkung, Roni, ist hier eine typische Verteidigung, um zu erkennen, ob sich die Fähigkeit des Systems, den Testdatensatz zu klassifizieren, nach der Umschulung verschlechtert.“

Die offensichtlichste Tatsache über die Sicherheit von ML wird oft übersehen, bemerkt Kiss. „Lösungen für maschinelles Lernen sind Softwaresysteme. Wir programmieren sie in Python – oder möglicherweise in C++ – und daher weisen sie potenziell alle gängigen Sicherheitslücken auf, die für diese Sprachen gelten.“ Der Cydrill-Trainer rät uns insbesondere, Punkt 9 der OWASP Top Ten zu beachten. Das Open Web Application Security Project ist ein Dokument, das die zehn kritischsten Sicherheitsprobleme in Webanwendungen zusammenfasst, um das Bewusstsein zu schärfen und das Risiko von Angriffen zu minimieren. Punkt 9 warnt Entwickler vor der Verwendung von Komponenten mit bekannten Sicherheitslücken. „Jede Schwachstelle in einem weit verbreiteten ML-Framework wie Tensorflow oder einer seiner vielen Abhängigkeiten kann weitreichende Folgen für alle Anwendungen haben, die es verwenden.“

Potenzielle Angriffsziele

Die Angreifer interagieren mit dem ML-System, indem sie Daten über die Angriffsfläche einspeisen. Versetzen Sie sich in den Kopf des Angreifers und stellen Sie Fragen. Wie verdaut die Anwendung die Informationen? Welche Art von Daten? Akzeptiert das System Bilder sowie Audio- und Videodateien? Oder gibt es Beschränkungen? Wenn ja, wie prüft es die Typen? Übernimmt das Programm das Parsing oder delegiert es dies vollständig an eine Open-Source- oder kommerziell erhältliche Medienbibliothek? Und hat das Programm nach der Vorverarbeitung der Daten irgendwelche Annahmen (leeres Feld, Anforderungen an Werte)? Sind die Daten in einer relationalen Datenbank oder in XML oder JSON gespeichert? Wenn ja, welche Operationen führt der Code mit diesen Daten durch, wenn sie verarbeitet werden? Wo werden die Hyperparameter gespeichert und können sie während der Laufzeit geändert werden? Verwendet die Anwendung Bibliotheken, Frameworks, Middleware oder Webservice-APIs von Drittanbietern als Teil des Workflows, der die Benutzereingaben verarbeitet? Wenn ja, welche?

Kiss: „Jede dieser Fragen kann auf potenzielle Angriffsziele hinweisen. Jede von ihnen kann Schwachstellen verbergen, die Angreifer ausnutzen können, um ihre ursprünglichen Ziele zu erreichen.“

Diese Schwachstellen haben weniger mit dem maschinellen Lernen zu tun als vielmehr mit den zugrundeliegenden Technologien: der Programmiersprache selbst (wahrscheinlich Python), der Einsatzumgebung (mobil, Desktop, Cloud) und dem Betriebssystem. Aber die Gefahren, die von ihnen ausgehen, sind genauso kritisch wie die gegnerischen Beispiele – eine erfolgreiche Ausnutzung kann zu einer vollständigen Kompromittierung des ML-Systems führen. Dies beschränkt sich nicht auf den Code der Anwendung selbst. Der Forscher Rock Stevens von der University of Maryland untersuchte Schwachstellen in häufig verwendeten Plattformen wie Tensorflow und Pytorch.

Echte Bedrohungen

Kiss‘ wichtigste Botschaft ist, dass ML-Sicherheit viele reale Bedrohungen abdeckt. Sie ist nicht nur eine Teilmenge der Cybersicherheit, sondern weist viele Merkmale der Softwaresicherheit im Allgemeinen auf. Wir sollten uns nicht nur um bösartige Samples und gegnerisches Lernen kümmern, sondern auch um alle üblichen Schwachstellen der Software-Sicherheit. Maschinelles Lernen ist nun einmal Software.

ML-Sicherheit ist eine neue Disziplin. Die Forschung hat gerade erst begonnen, wir fangen gerade erst an, die Bedrohungen, die möglichen Schwachstellen und die Anfälligkeiten zu verstehen. Dennoch können ML-Experten viel von der Software-Sicherheit lernen. Die letzten Jahrzehnte haben uns hier viele Lektionen erteilt.

Dieser Artikel wurde von René Raaijmakers geschrieben, dem technischen Redakteur von Bits&Chips.

Als Projektmanager, Systemarchitekt und Krisenmanager in der High-Tech-Branche ist Luud Engels dafür bekannt, dass er kein Blatt vor den Mund nimmt. Neben seiner Beratertätigkeit arbeitet er seit kurzem auch als Trainer für Systemarchitekten am High Tech Institute. „Klare Kommunikation ist in komplexen Entwicklungsumgebungen das A und O.“

Beginnen Sie nicht mit Luud Engels darüber, wie aufgeschlossen und kommunikativ wir als Systemarchitekten in der niederländischen High-Tech-Branche sind. Er wird energisch antworten und betonen, wie heuchlerisch es ist, das zu glauben. „Hier in der Region Brabant sind wir überhaupt nicht so offen. Stellen Sie sich einfach an eine Kaffeemaschine und hören Sie zu. Wir reden nicht mit Ihnen, wir reden über Sie.“

Wenn es um direkte Kommunikation – oder besser gesagt, Konfrontation – geht, hat Engels einen guten Ruf. Vor ein paar Monaten wurde er vor die Tür gesetzt, nachdem er – laut seinem Kunden – deutlich zum Ausdruck gebracht hatte, was in dem Unternehmen falsch lief. „Ich bin davon überzeugt, dass man zum richtigen Zeitpunkt jedem alles sagen kann – sei es in einer Teamsitzung oder in einem Gespräch zwischen zwei Personen. Natürlich tun das die meisten Niederländer nicht. Aber ich scheine darin auch nicht besonders gut zu sein, denn ich sage die Dinge manchmal so unverblümt, dass die Leute mir sagen, ich solle mich verziehen.“

Engels‘ Wertschätzung für sachliche und klare Kommunikation stammt aus seiner langjährigen Erfahrung als Projektmanager, Systemarchitekt, Krisenmanager und Mitglied des Managementteams beim Ingenieurbüro TMC. Sein Rat für Entwicklungsumgebungen: „Sagen Sie Ihre Meinung. Auch über persönliche Dinge. Es ist völlig in Ordnung, wenn Sie jemandem sagen, dass sein blaues Hemd Sie stört. Aber Aussagen wie ‚Microsoft ist scheiße und Apple ist gut‘ sind nicht hilfreich. Machen Sie es sachlich: Werden wir objektorientiert oder prozessorientiert arbeiten? Werden wir Glas oder Titan verwenden? Was sind die Vorteile? Was sind die Nachteile? Wenn ich über Glas spreche, muss ich nicht die ganze Geschichte der Glashütten kennen. Ich will die fünf wichtigsten Kriterien – in Zahlen, nicht in Positiven und Negativen. Wenn Sie die vorherrschenden Parameter kennen, wissen Sie auch, wie man sie messen kann und wir können uns auf die ersten Entwicklungsschritte einigen, um die Messungen zu ermöglichen.“

Engels betont, dass bei der Entwicklung von High-Tech-Systemen mehrere Wege nach Rom führen und dass es wichtig ist, bei der getroffenen Wahl zu bleiben. „Stellen Sie sicher, dass das gesamte Team zumindest auf demselben Weg ist, anstatt endlos nach der einzig richtigen Lösung zu suchen – die es per Definition nicht gibt.“

Aber manchmal können selbst die einfachsten Dinge schief gehen. „Einmal, nach einem positiven Gespräch mit einem Kunden, erhielt ich den Bericht in umgangssprachlichem Niederländisch. Ich fragte, ob die Vertreter des Kunden den Text genehmigt hätten. Natürlich hatten sie das nicht. Also bestand ich darauf, den Bericht auf Englisch abzufassen, ihn dem Kunden vorzulegen und ihn um seine Zustimmung zu bitten. Schließlich geht es hier oft um Entscheidungen mit weitreichenden Folgen. Dennoch erwies sich die Abstimmung mit dem Kunden als schwierige Aufgabe.“

Die Gesetze von Luud

• Wenn die Finanzleute die Führung übernehmen, wird das Interesse der Ingenieure zweitrangig; wenn die Ingenieure die Führung übernehmen, wird es finanziell kaputt gehen
  (Über das Gleichgewicht zwischen Technik und Geld in High-Tech-OEMs)
• Der Kunde, der darum bittet, dass eine Krise abgewendet wird, ist zur Hälfte der Verursacher oder Teil der betreffenden Krise (Über Krisenmanagement)
• Ich glaube fest an die Macht des Außenseiters (Über den Krisenmanager)
• Wir reden aneinander vorbei: der eine redet in Newton pro Quadratmeter, der andere in Bits pro Sekunde (Über Kommunikation und Zusammenarbeit in der High-Tech-Branche)
• Eine Krise verschwindet nicht, indem man die Leute loswird, die den Finger auf die wunden Punkte legen (Über gestrandete Entwicklungsprojekte)

Der Außenseiter

Engels‘ umfangreiche technische Laufbahn begann mit einem Studium der Elektrotechnik. Danach wechselte er zu Sattcontrol, einem schwedischen Spezialisten für industrielle Automatisierung. Er programmierte SPSen für Eier-Sortiermaschinen, Molkereien und automatisierte Lagerhäuser. Später wechselte er zu Fortran für PDP- und Vax-Minicomputer.

Nach fünf Jahren wechselte Engels zu Cap Volmac (später Cap Gemini), wo er Projekte bearbeitete. Während er hauptsächlich im technischen Bereich arbeitete, lag der Schwerpunkt von Cap auf der Geschäftsautomatisierung. „Ich habe viel über die Entwicklung von Computersystemen und Software nach den Regeln der Kunst gelernt.“

Engels begann für Cap bei ASML, dann arbeitete er bei der niederländischen Behörde für Wasserstraßen und öffentliche Arbeiten an der Signalisierung von Autobahnen und übernahm schließlich eine Führungsrolle. Später kamen Audits hinzu. Er schätzt, dass er etwa zwanzig Projekte geprüft hat. „Nach einem Tag Rundgang weiß man, was los ist und wo das Projekt schief gelaufen ist“, sagt er. Er lächelt: „Und das sicher nicht, weil ich so klug bin oder weil ich so viel gesehen habe, sondern vor allem, weil ich ein Außenseiter war.“

Engels glaubt fest an die Macht des Außenseiters. „Sie kommen in Unternehmen, in denen etwas völlig schief gelaufen ist, und dann dürfen Sie herumlaufen und mit 5-10 Leuten sprechen. Sie alle haben eine Meinung zu dem krisenhaften Projekt. Sie bekommen die ganze Geschichte zu hören. Die Leute wollen Ihnen ihr Herz ausschütten. Sie hören, was falsch ist und vor allem: was andere nicht sagen dürfen.“

Der eigensinnige Techniker

Techniker sind ein sturer, eigensinniger Typ – und Engels sollte es wissen, denn er passt genau in dieses Schema. „Wir sind Ingenieure, nicht wahr? Wir denken so: ‚Ich bin ein Elektroingenieur und nach meinen Berechnungen sind es 5 Volt. Wenn Sie es nicht verstehen, erkläre ich es Ihnen noch einmal, aber das Ergebnis bleibt 5 Volt. Sie sind verrückt, nicht ich.‘ Bei den Projekten geht es vor allem um eine effektive Zusammenarbeit. Das ist der schwierige Teil. Der eine spricht in Newton pro Quadratmeter, der andere in Bits pro Sekunde. Der eine spricht über das Ziel, der andere über die Lösung. Die Hochtechnologie ist ein einziger großer Turm zu Babel. Das fängt bei den Anforderungen an und setzt sich fort bis hin zu Design, Integration und Tests. Das ist auch gut so: Wenn ich ein Projekt selbst durchführe und ein Außenstehender dazukommt, wird er oder sie auch Löcher hineinschießen.“

Luud Engels wird die Mitte November stattfindende Schulung zum Systemarchitekten (Sysarch) in Leuven (Belgien) leiten.

Engels zieht es vor, dann einzugreifen, wenn die Krise am schlimmsten ist. Nehmen Sie das Projekt Fusion, das Ende der neunziger Jahre bei Philips lief. Sein ehrgeiziges Ziel war es, die mechanische, elektrische und softwaretechnische Konstruktion für medizinische Diagnosesysteme auf einer einzigen Plattform abzudecken. Die Idee war, dass Kosteneinsparungen durch Wiederverwendung den umfangreichen Betrieb rechtfertigen würden. „Der Direktor schilderte sein Problem folgendermaßen: Jeden Monat kamen dreißig neue Entwickler zu dem Projekt hinzu und jeden Monat teilten sie ihm mit, dass sich die Fertigstellung um weitere zwei Monate verzögert.“

Engels wandte wiederum die Macht des Außenseiters an. „Dem Außenseiter ist es erlaubt, sich zu äußern. Je tiefer die Krise, desto empfänglicher ist man für Botschaften von außen. In der Regel haben andere Leute bereits einen Blick darauf geworfen. Aber oft legten sie ihre Finger auf wunde Punkte, auf die sie nicht zeigen durften, und mussten schließlich gehen. Sie baten mich, den derzeitigen Projektleiter zu ersetzen, weil er die Verzögerung nicht aufholen konnte. Aber eine Krise verschwindet nicht, wenn man die Leute loswird, die den Finger auf die wunden Punkte gelegt haben. Stattdessen ging ich dem amtierenden Projektleiter zur Hand. Gemeinsam konnten wir die Krise eindämmen, indem wir den Umfang anpassten und mit frühen Rückmeldungen arbeiteten. Eines meiner Gesetze lautet: Der Kunde, der darum bittet, dass eine Krise abgewendet wird, ist zur Hälfte der Schuldige oder hat zumindest einen maßgeblichen Anteil daran.“

Ist es der Tunnelblick?

„Bitte beachten Sie: Sie sprechen über sehr kompetente Leute mit sehr relevanten Argumenten und Tonnen von Wissen. Aber nach und nach wurde die Lösung oder Arbeitsmethode in verschiedenen Silos untergebracht. Sehr fähige Leute nutzen Wege ab und schaffen Gräben, die so tief sind, dass man kaum noch über den Rand schauen kann. Jeder hat seinen Graben und verteidigt ihn hartnäckig. Sie hören die Leute Dinge sagen wie: ‚Das ist nicht verhandelbar!‘ Wenn Sie das hören, weist es Sie darauf hin, wo es schief gelaufen ist und wo ein möglicher Anfang der Lösung liegt.“

Wo beginnt die Lösung?

„Das erste Gesetz des Krisenmanagements ist die Eindämmung. Bei Fusion bedeutete das, dass sie keine dreißig neuen Mitarbeiter pro Monat einstellen durften. Stattdessen mussten sie zwanzig pro Monat streichen und den Umfang reduzieren. Die tiefere Ursache war – meiner Meinung nach – reine Selbstüberschätzung. Die Plattformidee für Software allein ist eine große Herausforderung. Aber wenn Sie anfangen, Mechanik und Elektronik für alle Diagnoseprodukte einzubeziehen, wird es zu viel auf einmal. Es ist schon schwierig genug, Elektronik, Software und Mechanik gemeinsam für ein einziges System zu entwickeln, aber zu versuchen, eine Plattform für verschiedene Produktlinien in einem Projekt zu entwickeln, ist gelinde gesagt naiv. Zu dieser Zeit mussten sie auch mit Entwicklern in Bangalore zusammenarbeiten und wollten gleichzeitig von CCM Level 2 auf Level 3 wechseln. Das musste sofort aufhören. In einer Krise muss man den Umfang eines Projekts begrenzen und langfristige Verbesserungsinitiativen aufschieben.“

„Oft wissen die Techniker bereits, was falsch läuft, und das Management weiß es auch. Beide haben Recht, aber sie kommen nicht gemeinsam zu einer Lösung. Viel später arbeitete ich bei Philips DPS, wo ich sah, dass Philips erhebliche Fortschritte gemacht hatte. Die Finger auf wunde Punkte zu legen, war aber leider immer noch nicht erlaubt.“

Wie kann man das richtig machen?

Fangen Sie klein an, sagt Engels. „Sie brauchen frühes Feedback, am besten von einem Erstkunden. Ich habe Martin van den Brink bei ASML oft sagen hören: Stellen Sie alles zusammen und zeigen Sie mir, dass es funktioniert. Dann fordert er die Leute heraus, indem er sagt: ‚Ihre Physik funktioniert nicht.‘ Das war in der frühen Integrationsphase sehr häufig der Fall. Erst viel später hat die Industrie dafür schöne Worte gefunden und es Scrum, Agile und Rapid Development genannt. Aber der Punkt ist, dass Sie Feedback brauchen, und es ist wichtig, dass Sie es schon in einem frühen Stadium bekommen. Das Ziel muss sein, alle sechs Wochen etwas zu liefern, das auch wirklich funktioniert. Wenn das nicht der Fall ist, haben Sie die Mittel, um herauszufinden, warum es nicht geklappt hat, warum die Physik nicht funktioniert hat. An diesem Punkt müssen Sie vielleicht akzeptieren, dass Sie Ihren Termin nicht einhalten werden. Was Sie auf keinen Fall tun sollten, ist, mehr Leute einzustellen.“

„Wenn Techniker Ihnen sagen, dass sie mehr Zeit brauchen, um etwas zu untersuchen, müssen Sie misstrauisch werden. Van den Brink ist auch ein Meister darin, das zu beurteilen oder in Frage zu stellen.“

Eine weitere Notwendigkeit: „Machen Sie die Menschen zu Eigentümern eines Problems. Vor allem in Umgebungen mit komplexen Entwicklungen, in denen es nicht einmal ansatzweise eine Lösung gibt und neue Erfindungen erforderlich sind, fühlt sich jeder als Herr seiner Idee, mit seinem persönlichen Einblick. Wir Niederländer sind auch sehr gut darin, jede Gelegenheit zu ergreifen, um in einem sehr weiten Sinne darüber zu sprechen. Aber Sie müssen einfach den nächsten Schritt tun. Das ist das Einzige, wovon ein Projekt profitiert. Wenn Sie also in einem Raum mit dreißig Leuten sitzen und Probleme auftauchen, muss der Projektmanager, der Krisenmanager oder der Systemarchitekt für jedes Problem einen Verantwortlichen bestimmen. Dazu gehören auch Fristen für Ergebnisse und Entscheidungen.“

Laut Engels gehört das definitiv zur Kultur von ASML, aber es gab einen Zeitpunkt, an dem das Ganze aus dem Ruder lief. „Sie ernannten einen Verantwortlichen für alles und nannten ihn Projektleiter. McKinsey hat einmal eine Analyse der Projektleiter und Projektgrößen bei ASML durchgeführt. Sie fanden heraus, dass im Durchschnitt 1,2 Personen an jedem Projekt beteiligt waren, einschließlich des Projektleiters! Dann besteht die Gefahr, dass diese Eigentümer, diese Projektleiter, anfangen, um die verfügbaren Ressourcen zu konkurrieren und das eigentliche Problem in den Hintergrund gerät.“

Engels verfügt über umfangreiche Erfahrungen als Projektmanager, Systemarchitekt und Krisenmanager in der High-Tech-Industrie.

Der Produktmanager definiert das Produkt, das auf dem Markt gut abschneiden wird. Er bestimmt das verfügbare Budget – oft zu wenig – und verhandelt mit dem Systemarchitekten darüber, ob es für dieses Geld hergestellt werden kann. Engels: „Es ist ein Balanceakt. Bei ausgereiften Produkten funktioniert das anders, aber bei einer Erstentwicklung wollen Sie so schnell wie möglich einen Proof of Concept. Oder zumindest eine Bestätigung, dass Ihre Ideen richtig sind und dass Sie auf dem richtigen Weg sind.“

Inwieweit sollte der Systemarchitekt, ähnlich wie der Produktmanager, direkt mit den Kunden sprechen?

„In der High-Tech-Branche ist das unumstritten. Hier kommen der Produktmanager und der Systemarchitekt zusammen. Das müssen sie auch. Ersterer ist mehr auf das Geschäft fokussiert, letzterer betrachtet die Technologie und ob sie machbar ist. Sie sind zwei Seiten derselben Medaille. Diese Zusammenarbeit zwischen dem Produktmanager und dem Systemarchitekten wird immer mehr zur Selbstverständlichkeit. Ich sehe jedoch immer noch Systemarchitekten, die die notwendige Abstimmung mit dem Projektmanager oder dem operativen Management herunterspielen. Sie laufen dann Gefahr, dass eine Lösung, die den Marktbedürfnissen perfekt entspricht, letztlich in der Realisierungsphase scheitert.“

Bei kleineren Entwicklungsprojekten mit zehn bis zwanzig Entwicklern kann eine Person sowohl die Rolle des Projektmanagers als auch die des Systemarchitekten übernehmen. Bei größeren Projekten mit Dutzenden oder Hunderten von Entwicklern und mehreren Dutzend Zulieferern ist es wichtig, sich aufzuteilen. Engels hat Erfahrung in beiden Rollen. „Der Projektmanager setzt harte Fristen, und ein Systemarchitekt muss mit ihnen arbeiten.

„Der Projektmanager muss festlegen, welche Probleme der Systemarchitekt noch zu lösen hat und mit wem. Gemeinsam besprechen Sie die Vor- und Nachteile, wägen die Vorteile und Bedenken ab, entscheiden über die wichtigsten Parameter und dann ruft der Projektmanager den Systemarchitekten an: Ende nächster Woche treffen wir eine Entscheidung! Es geht um die Richtung, darum, ein Format zu finden, das sachkundige Leute einbezieht, um zu quantifizierten Aussagen zu gelangen, mit denen Sie wirklich eine Bewertung vornehmen können.

Ein Systemarchitekt hat einen großen Einfluss auf die Produktentwicklung, spielt aber oft eine weniger sichtbare Rolle.

„Er ist ein erfahrener Techniker, aber sein Wert liegt vor allem in seinem Blick auf das Geschäft. In neunundneunzig von hundert Fällen kennt der Systemarchitekt den Markt, auf dem sein Produkt oder System landen wird. Das ist notwendig, um die Markt- und Produktanforderungen in die Systemanforderungen zu übersetzen und dann das Design zu skizzieren.“

Man braucht schon eine Menge Erfahrung, um dieses Niveau zu erreichen. Gleichzeitig stellt Engels fest, dass das Konzept des Systemarchitekten einer Inflation unterworfen ist. „Heutzutage gibt es überall Architekten. Ein Softwarearchitekt ist in der Regel ein leitender Softwareentwickler, ein Anforderungsingenieur oder jemand, der für die Technik zuständig ist. Ich würde nichts sagen, was gegen einen solchen leitenden Ingenieur spricht. Der Unterschied zum Systemarchitekten besteht jedoch darin, dass letzterer das Unternehmen kennen muss, verstehen muss, wie Werte geschaffen werden, und somit verstehen muss, warum dies innerhalb eines bestimmten Zeit- und Kostenrahmens geschehen muss.“

„Das ist auch beim Bauen der Fall. Ihr Architekt fragt Sie, was Sie mit Ihrem zukünftigen Haus vorhaben und passt seinen Entwurf entsprechend an. Werden Sie viel kochen, oder wollen Sie hauptsächlich Wein trinken? Das ist der Grund, warum Van den Brink bei ASML so gut arbeitet. Er geht zu den Kunden und erklärt ihnen, welche Art von Lithografiesystemen sie benötigen. Er kennt den Markt wie kein anderer. Mehr noch, er diktiert den Markt. Das bedeutet, dass er die Ziele und den Zeitplan der Chiphersteller wie kein anderer versteht, einschließlich der Frage, wie ihre Produktionsprozesse aussehen. Wenn sie über kritische Dimensionen und Overlay sprechen, kann er erklären, dass seine Maschine das kann und auch begründen, warum.“

Dieser Artikel wurde von René Raaijmakers geschrieben, dem technischen Redakteur von Bits&Chips.