Der eingefleischte technische Experte sollte vor allem kein Systemarchitekt werden

Veröffentlicht am: 09 Mai 2018

Autor:

René Raaijmakers

Technischer Redakteur, Autor, Geschäftsführer

Lesen Sie mehr über René Raaijmakers

Experte:

Ger Schoeber

Content partner, course leader, trainer

Lesen Sie mehr über Ger Schoeber

Aktie

---

Ger Schoeber gibt am High Tech Institute einen der beliebtesten Schulungskurse in Systemarchitektur. Er tut dies zusätzlich zu seinem Vollzeitjob als Gruppenleiter und Domänenexperte für Systemtechnik bei Lightyear. Schoeber über die Rolle, den Nutzen und die Fallstricke für den Systemarchitekten.

Ger Schoeber nahm im Jahr 2002 an einem Treffen der System Architecture Study Group von Gerrit Muller teil. Muller hatte auf der Grundlage seiner Erfahrungen bei ASML und Philips einen neuen Schulungskurs ins Leben gerufen: Sysarch, kurz für ‚Systemarchitektur‘. Dieser fünftägige Kurs lief bereits seit einigen Jahren und war inzwischen so beliebt, dass Muller während des Treffens fragte, wer Interesse hätte, bei ihm als Lehrer mitzumachen.

Die Frage machte Schoeber neugierig. Er hatte umfangreiche Erfahrungen in der Systementwicklung bei High Tech Automation und Ordina gesammelt und war noch nicht so lange als Selbständiger tätig. Ich war es nicht gewohnt, auf einem Podium zu stehen, und das gab mir eine großartige Gelegenheit, meine Komfortzone zu erweitern. Als ich im September 2002 meine Feuertaufe erhielt, hatte ich den absoluten Eindruck, dass diese sechzehn Teilnehmer eigentlich viel mehr Erfahrung in der Systemarchitektur hatten als ich‘, lacht Schoeber.

Gerrit Muller promovierte in diesen Jahren über Systemarchitektur, ein Thema, das in der akademischen Welt nicht sehr ernst genommen wurde. Seine Erkenntnisse wurden oft sofort in Themen für die Ausbildung umgesetzt. Nach Mullers Promotion im Jahr 2004 übernahm Schoeber seine Methode CAFCR (Customer Objectives, Application, Functional, Conceptual, Realization, sprich: kafkar). Dieser Rahmen entwickelte sich in den folgenden Jahren zum Kernstück der Systemarchitektenausbildung. Ich selbst habe die CAFCR-Methode als Systemarchitekt 2005 zum ersten Mal in der Praxis angewendet. Das hat mir viele Einsichten, Werte und Erfahrungen gebracht‘, sagt Schoeber.

Vor allem praktische Erfahrungen sind wertvoll, und diese teilt Schoeber mit den Teilnehmern seiner Kurse, von denen es über tausend gibt. Er ist seit fast drei Jahrzehnten an kleinen und größeren multidisziplinären Projekten bei OEMs beteiligt. Seit 2011 ist er bei Hotraco, einem Agrarunternehmen, beschäftigt, wo er die Rolle des Innovations- und Technologiemanagers innehat. In den letzten Jahren habe ich die Sysarch-Theorie in der Praxis anwenden können. Das hat meinen eigenen Projekten viel Wert verliehen und mir direkte Erfahrungen mit der Anwendung des Materials vermittelt, die ich wiederum als Beispiele in den Trainingskursen verwenden konnte.

Sich in den Kunden hineinzuversetzen scheint selbstverständlich, ist aber das Schwierigste von allem, sagt Ger Schoeber.

Unternehmerisch denken

Der Systemarchitekt ist für die technische Realisierung eines Produkts oder Teilsystems verantwortlich. Systemarchitekten verfügen immer über viele Jahre Entwicklungserfahrung. Sowohl dieser Hintergrund als auch das technische Rüstzeug sind unverzichtbar. Aber Systemarchitekten müssen auch über soziale Fähigkeiten verfügen, um ihre Rolle ausfüllen zu können, denn sie stehen in Kontakt mit allen Beteiligten. Nicht nur mit den Mitarbeitern des Entwicklungsteams und den Lieferanten, sondern auch mit dem Managementteam, den Investoren, den Kunden und den Endbenutzern.

Schoeber sieht sporadisch unmotivierte Kursteilnehmer. Dabei handelt es sich oft um Techniker, die von ihrem Chef zu dem Kurs geschickt wurden. Schoeber hält sie für eine Rolle als Systemarchitekt für ungeeignet. ‚Systemarchitekten sind proaktiv und müssen die Führung bei der technischen Entwicklung übernehmen. Sie sind per Definition motiviert, wollen an der Spitze stehen. Außerdem haben sie eine Vision: darum geht es. Sie müssen auch ihren Glauben und ihr Vertrauen darin ausstrahlen.‘

Das hat Konsequenzen für die Art und Weise, wie Systemarchitekten in einem Unternehmen arbeiten. Sie müssen stark und selbstbewusst sein und sich trauen, Nein zu sagen. Wenn sie nicht genug Vertrauen in den erfolgreichen Abschluss eines Projekts haben, sollten sie den Auftrag nicht annehmen. Eigentlich sollten sie sofort sagen: Ich werde das nicht tun. Denn wenn Systemarchitekten kein Vertrauen haben, bekommen die Leute in ihrem Team das sofort mit. Sie strahlen das aus, und zwar nonverbal.‘

Zu den Aufgaben eines Systemarchitekten gehört es, zu beurteilen, ob ein Projekt erfolgreich sein kann oder nicht, ob etwas technisch machbar ist und zu einem wirtschaftlichen Erfolg führen kann oder nicht. Schoeber: ‚Die Herausforderung liegt oft in Letzterem. Technisch kann etwas Spaß machen, aber hat es auch einen Wert für den Kunden und für das Unternehmen? Wir betonen auch die letzten beiden Schritte in der Schulung. Systemarchitekten müssen nicht nur an den fantastischen technischen Aspekt denken. Es muss auch für den Kunden richtig sein. Das bedeutet, dass sie in der Lage sein müssen, vom Standpunkt des Kunden aus zu denken.‘

Neben dem Einfühlungsvermögen sollten Systemarchitekten auch den Wert des Projekts für das Unternehmen nicht aus den Augen verlieren. Sie können etwas fantastisch machen und den Kunden sehr glücklich machen, indem Sie es umsonst anbieten, aber dann hat es keinen geschäftlichen Wert. Es ist also auch für den Systemarchitekten wichtig, geschäftlich zu denken. ‚

Was sind die größten Fallstricke für Systemarchitekten?

Dass sie nicht genug für ihr Team einstehen und sagen: Ich bin zuversichtlich, dass das klappen wird. Denn wenn Sie selbst dieses Gefühl nicht haben, dann wird es nicht funktionieren. Eine noch größere Herausforderung ist es, vom Standpunkt des Kunden aus zu denken. Ich sage oft, dass Sie nicht nur das herstellen müssen, was der Kunde verlangt, sondern das, was der Kunde braucht. Ich stelle die Frage: Versuchen Sie, sich auf die andere Seite zu stellen. Wechseln Sie den Platz. Welches Endergebnis wünschen Sie sich als Kunde? Wofür brauchen Sie Hilfe? Wenn Sie ein Teilsystem erstellen müssen, das in ein größeres Ganzes integriert werden soll, dann stellen Sie sich vor, Sie wären derjenige, der dieses Teil integrieren muss. Womit brauchen Sie dann Hilfe? Gibt es etwas Zusätzliches, das die Integration oder Überprüfung erleichtert? Wenn Sie anfangen, von dieser Position aus zu denken, entdecken Sie, dass Sie mehr tun müssen, als nur das auszuführen, was in den Anforderungen steht.

Warum ist es so schwierig, sich in die Lage eines anderen zu versetzen? Es klingt so einfach?

„Das ist das Schwierigste. Nicht jeder hat eine ausreichende Empathiefähigkeit. Für Männer ist Empathie vielleicht noch schwieriger. Frauen können Gefühle besser nachempfinden und sich in die Lage eines anderen hineinversetzen. Dafür müssen Sie sich auch trauen, verletzlich zu sein. Männer sind eher Machos: Schau, was ich gemacht habe. Es wäre schön, wenn mehr Frauen die Rolle des Systemarchitekten übernehmen würden.

Es ist also nichts für den eingefleischten Techniker, der technisch hervorragend sein will?

Nein, Techniker sollten niemals Systemarchitekten werden wollen. Sie sollten vor allem weiterhin das tun, was sie gerne tun: mit ihrer Technik aktiv sein und ein Spezialist dafür sein. Techniker können sehr gut darin sein, sich Lösungen auszudenken, aber um ein kommerziell erfolgreiches Produkt herzustellen, müssen Sie auch fragen, was das Problem ist. Das heißt, Sie müssen in der Lage sein zu fragen: Warum wollen Sie das wirklich? Damit dringen Sie tiefer in das wirkliche Bedürfnis ein. Denn ein Kunde, der auch einer der Beteiligten ist, denkt oft an die Lösung, anstatt zu versuchen zu erklären, was sein Problem ist. ‚

In Zusammenarbeit mit Incose-NL (International Council on Systems Engineering) und den High-Tech-Magazinen Bits & Chips und Mechatronica & Machinebouw organisierte das High Tech Institute kürzlich die niederländische Konferenz System Architecting. Schoeber war Vorsitzender.

Ist das der Fallstrick des Kunden?

Der Kunde hat sich oft selbst eine Lösungsrichtung ausgedacht. Für den Systemarchitekten ist es verlockend, seinem Beispiel zu folgen: Oh ja, das müssen wir machen! Stattdessen müssen Sie dem entgegenwirken und sagen: Warum wollen Sie das und warum wollen Sie es auf diese Weise lösen? Genau dabei hilft das von Gerrit Muller entwickelte CAFCR-Modell.

Was bedeutet CAFCR?

Es geht darum, sich in die Lage des Kunden zu versetzen. Dabei betrachten Sie die Systemarchitektur aus fünf Blickwinkeln. Nur bei zwei davon geht es um die Technologie, um die Lösung. Das C der ‚konzeptionellen Sicht‘ sagt zum Beispiel: Ich möchte drahtlos kommunizieren. Das ist allgemeiner als das R der ‚Realisierungssicht‘, bei dem es um die Technologie geht, die benötigt wird, um die Lösung zu erreichen, zum Beispiel Bluetooth, WiFi oder Zigbee. ‚

Bei den anderen drei geht es um die Perspektive des Kunden. Darin liegt meiner Meinung nach der größte Wert des CAFCR-Rahmens. Beim F der funktionalen Sicht geht es um die Spezifikation, die Anforderungen: Was erwartet der Kunde von dem Produkt oder was erwarten die Beteiligten an Funktionalität, Qualität und Leistung? Das A der ‚Anwendungssicht‘ erfordert, dass Sie den breiteren Kontext betrachten. In welcher Umgebung kommt das Teilsystem oder System zum Einsatz? Wie wird es angewendet? Wenn Sie eine gute Vorstellung davon haben, dann verstehen Sie auch, was nützlich ist oder nicht. Das ermöglicht es Ihnen, die Anforderungen zu verbessern. ‚

Beim ‚ersten C der Kundenziele‘ dreht sich alles um den Kunden: Was genau ist sein Geschäft? Wie verdienen sie ihr Geld? Wie sieht das Lebensumfeld des Kunden oder des Kollegen aus, der mein Teilsystem installieren soll? Wenn Sie das besser verstehen, können Sie besser erkennen, was der Kunde braucht, um bessere Geschäfte zu machen. CAFCR zwingt mich, nicht nur die Technologie zu betrachten, sondern auch die Spezifikation und die Gründe für die Anforderungen. So kann ich Lösungen entwickeln, die den Kunden noch mehr helfen.‘

Als Beispiel verweist Schoeber auf Gerrit Muller, der die Entwicklung einer neuen Generation von radiologischen Geräten bei Philips Medical in den späten neunziger Jahren miterlebte. Zu dieser Zeit befand sich die medizinische Welt mitten im Übergang von der analogen zur digitalen Technik. Bei Philips hatte man ein wunderschönes System entwickelt, mit dem Radiologen und andere Spezialisten alles auf hochauflösenden Bildschirmen beurteilen konnten. Die Philips-Techniker entdeckten erst spät, dass dies nicht der Praxis entsprach. Die Radiologen hängten die Fotos in einen Leuchtkasten und wenn sie zwischendurch etwas Zeit hatten, schnappten sie sich ihr Diktiergerät und besprachen im Gehen die Diagnose und die Behandlung.

Schoeber: ‚Muller hat gezeigt, dass es nützlich ist, mit einem Radiologen spazieren zu gehen, um zu sehen, wie er seinen Tag verbringt. Diese Druckfunktion war nicht Teil des ursprünglichen Entwurfs, sie wurde später hinzugefügt. Die Lehre daraus ist, dass man sich schon in einem frühen Stadium in die Erfahrungen des Kunden einfühlen muss.

Schoeber rät Systemarchitekten daher, einen Tag mit Kunden zu verbringen, um herauszufinden, was sie wirklich brauchen. Océ macht das auch. Sie schicken ihre Techniker mit dem Fallschirm in ein Kundenumfeld, um zu erfahren, wie sie mit Kopierern und Druckern arbeiten. Sie nehmen dieses Wissen mit zurück in das Unternehmen.

Ich zwinge mich auch, regelmäßig in einem Hühner- oder Schweinestall zu sein oder mit dem Installateur unserer Geräte zusammenzuarbeiten. Das bringt mich auf viele Ideen für praktische Anpassungen oder bessere Arbeitsmethoden. In den neunziger Jahren, während eines Projekts für Patientenüberwachungssysteme, habe ich einmal eine grüne Jacke mit einer grünen Mütze angezogen und bei vier Operationen in einem Krankenhaus zugesehen. Ich sah, was ein Anästhesist mit einem Patientenmonitor in einer Umgebung mit Blut und Stress machte. Erst da habe ich gesehen, was bei einer Operation wirklich gebraucht wird und welche Funktionen erforderlich sind. Das hätte ich mir hinter einem Schreibtisch nicht vorstellen können. Man versteht die Prioritäten erst, wenn man mit dem Kunden geht und einen Tag mit ihm verbringt.‘

Muss der Produktmanager das auch wissen?

„Ja, das sollten sie wissen. Der Systemarchitekt erfährt vom Produktmanager, was benötigt wird, und muss dies in eine Spezifikation übersetzen, die dann von einem multidisziplinären Ingenieurteam unter seiner Leitung umgesetzt werden kann. Aber wenn ein Architekt das nur hört, aber nie erlebt, dann fehlt ihm das Gefühl. Außerdem ist der Produktmanager oft außerhalb des Unternehmens und nicht im eigenen Haus. Der Systemarchitekt muss also hin und wieder zum Kunden gehen.‘

Ist das nicht Zeitverschwendung?

Die Zeit wird sofort zurückgewonnen. Ich hatte einmal die Gelegenheit, einen Architekten bei Vanderlande zu beaufsichtigen. Er begann, sich mit der Inbetriebnahme einer Gepäckförderanlage zu beschäftigen. Dort arbeiten so genannte Inbetriebnahme-Ingenieure. Er sah, dass diese Installateure einen Ausweg gefunden hatten. Sie schlängelten sich um die Ecken, erkannten es aber nicht mehr als Problem, weil sie es gewohnt waren. „Oh, kann es auch anders sein?“ Sie reagierten verblüfft, als sie vom Architekten hörten, dass er eine Funktion in das System einbauen konnte, die ihnen die Arbeit ersparen würde. Sie könnten eine Umfrage an all diese Ingenieure schicken, aber Sie würden wahrscheinlich viel mehr nützliche Informationen erhalten, wenn Sie nur einen Tag mit ihnen verbringen würden.‘

Es ist auch eine Fähigkeit, das Wissen an das Team weiterzugeben. Als Schoeber bei Philips an einer High-End-Fernbedienung arbeitete, beauftragte er ein Teammitglied, alle Infrarotprotokolle zu lernen. Der Techniker kam stolz mit dem Ergebnis zurück: Sein Prototyp konnte neben den Signalen für Videorecorder und Fernseher auch das Infrarot von Leuchtstoffröhren und der Sonne imitieren. Mein Kollege hatte mich also wörtlich genommen, denn die Fernbedienung musste die Infrarotsignale im Umgebungslicht herausfiltern.

Wie lernen Sie, das Wissen gut zu vermitteln?

Es geht nicht darum, die Spezifikationen so gut wie möglich aufzuschreiben und sie an Ihr Ingenieurteam zu schicken. Sie müssen sie immer wieder erklären und wiederholen. Das menschliche Gehirn funktioniert einfach nicht wie ein Computerspeicher. Systemarchitekten können sich nicht hinter einer Aussage verstecken wie: „Aber habe ich das nicht sowieso gesagt?“ Sie müssen dieselbe Sache immer und immer wieder erklären, sie immer wiederholen, sonst wird sie nicht registriert.‘

Es geht nicht nur um technische Details, sondern auch um die Strategie und die Vision des Projekts. Was ist das Ziel, das wir erreichen wollen? Was ist der Endpunkt? Das muss klar sein. Der Endpunkt ist etwas, das wie angegeben funktioniert und zuverlässig ist, aber es gibt auch eine Frist. Wenn Sie ein Produkt auf einer Marktveranstaltung einführen wollen, dann ist das die strikte Deadline. Dann müssen Sie manchmal eine Abkürzung nehmen, um es zu schaffen.“

Letztlich ist Ausgewogenheit das große Zauberwort für den Architekten, sagt Schoeber. Sie können sich die beste Architektur ausdenken, die beste Technologie anwenden, aber wenn die Entwicklung zu lange dauert, haben Sie kein Geschäft und die Gehälter können nicht bezahlt werden. Der Architekt befindet sich mitten in diesem Spiel. Ihre eigenen Ingenieure wollen das beste Produkt herstellen, aber es sollte nicht vergoldet werden. Der Kunde muss schließlich einen Gegenwert für sein Geld bekommen. Er zahlt. Der Architekt muss auch dafür sorgen, dass es ein dauerhaftes Geschäft ist. Denken Sie an die Produktion, die einfache Wartung und künftige Generationen. Unter Berücksichtigung all dieser Interessen und Akteure muss etwas geschaffen werden.‘

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