Wir befinden uns mitten in einem Umbruch, unser Leben digitalisiert sich. Berater heben hervor, dass digitale Werkzeuge die Produktivität steigern, aber auch Risiken haben - und sie haben Recht. Wenn ich nur den Output vergrößere, ohne den Inhalt der Arbeit zu ändern, dann droht Burnout und der Wegfall von Arbeitsplätzen. In Forschungs- und Entwicklungsabteilungen finde ich zwei Arten von Menschen: Der Getriebene spürt, dass sich der Markt verändert, dass es irgendwie schneller gehen muss und gleichzeitig besser. Seine Reaktion darauf: schneller rennen. Mehr Stunden mit den etablierten Methoden. Veränderungen fürchtet er, denn eine Methodik, die erheblich Aufwand einspart, könnte schließlich seinen Arbeitsplatz kosten. Der Macher sieht die Chance, den Kunden mit innovativen, besseren und zeitnahen Produkten einen Mehrwert zu bieten - und damit auch seinem Unternehmen und sich selbst. Er probiert aus und prüft Veränderungen kritisch auf ihren Nutzen. Neue Methoden, die Aufwand einsparen, begrüßt er, da er dann Zeit für neue Aufgaben mit größerem Mehrwert hat. Was heißt das konkret? Entwickler von mechatronischen Systemen sehen, dass die Kunden mehr Funktionalität in den Produkten goutieren. Kauft die Führungskraft also fertige Funktionalität ein oder baut sie die Funktionsentwicklung als künftige Kernkompetenz selbst auf? Kämpft der Mitarbeiter gegen die neue Technologie an oder nimmt er die Herausforderung an, sein Aufgabenfeld zu ändern? Das geht nicht, weil ganz andere Fähigkeiten nötig sind? Blödsinn! Ein hervorragender Entwickler jeglichen Alters wird es begrüßen, wenn Maschinen mit Funktionen, die Kunden wirklich brauchen, sich besser realisieren lassen. Der Funktionsentwickler fühlt sich vielleicht durch automatische Codegenerierung bedroht, weil er beispielsweise Algorithmen für Regelungssysteme in den Programmiersprachen C/C++ schreibt, etwa für die Abstandskontrolle im Auto, den Greifer eines Roboters, die Infusionspumpe oder Codec im Handy. Ich spreche hier nicht von der Generierung von Funktionsrahmen über UML-Werkzeuge, sondern von der automatischen Generierung des algorithmischen C/C++/HDL/PLC-Code aus Simulink heraus, die das händische Programmieren eines Großteils des Systems tatsächlich überflüssig macht. Stellen Sie sich vor, Sie wären dieser Entwickler. Reagieren Sie als Getriebener oder Macher? Finden Sie den Sinn Ihrer Tätigkeit darin C/C++-Code zu schreiben? Dann ist diese in der Tat bedroht und Sie wollen höchstens im händischen Programmieren noch schneller und fehlerfreier werden. Sehen Sie es aber als Ihre Aufgabe an, die Funktion eines Systems zu entwickeln, dann werden Sie die Technologie willkommen heißen. Denn sie nimmt Ihnen das Programmieren, das Ausformulieren in C/C++ und das Umrechnen von mathematischen Festkommawerten ab und gibt Ihnen mehr Zeit für den eigentlichen Algorithmus und die Funktionsweise. Lieben Sie das Entwickeln oder das Programmieren? Dasselbe gilt für die Führungskraft: Ist ihre Abteilung zum Programmieren da oder schafft sie innovative Funktionalität in hoher Qualität? Werkzeuge der Digitalisierung können dazu dienen, die Arbeit lediglich zu verdichten. Oder sie ändern den Inhalt der Arbeit durch Abstraktion. Solche Werkzeuge können helfen, den eigentlichen Sinn der Arbeit anders zu erreichen. Das erlaubt es, mit der Veränderung der Märkte nicht nur Schritt zu halten, sondern den Schritt mitzubestimmen. Als Macher, nicht als Getriebener.
Software & Security Macher oder Getriebener?
Halten Sie nicht nur mit der Veränderung der Märkte Schritt, sondern bestimmen Sie den Schritt mit!
Firmen zu diesem Artikel
-
MathWorks GmbH
Aachen, Deutschland