Verstehen, wie man Werte schafft – innerhalb von Zeit und Budget

Veröffentlicht am: 15 September 2020

Autor:

René Raaijmakers

Technischer Redakteur, Autor, Geschäftsführer

Lesen Sie mehr über René Raaijmakers

Experte:

Luud Engels

Trainer

Lesen Sie mehr über Luud Engels

Aktie

---

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.