Was Wirtschaft und Wissenschaft voneinander lernen können

Nicht nur seitdem AutoLab ins EBS-Center gezogen ist und unsere Firmenaktivitäten direkt am Campus der TU Graz stattfinden, bewege ich mich aktiv zwischen Wirtschaft und Wissenschaft. Schon meine Abschlussarbeit führte gemeinsam mit der TU Graz zu einer Patentanmeldung für die automatisierte Behandlung von Schilddrüsenerkrankungen. Somit begleite ich seit Langem parallel unternehmerische Projekte und wissenschaftliche Forschung.
In meiner Rolle als Geschäftsführer von AutoLab stehe ich regelmäßig unter dem harten Zeit-, Kosten- und Innovationsdruck der produzierenden Industrie. Gleichzeitig habe ich tiefen Einblick in die methodische Forschungsarbeit einer anwendungsnahen Grundlagenforschung. Ein Blick auf beide Welten zeigt mir hautnah, wo jede Seite ihre Stärken und Schwächen hat – und was beide voneinander lernen können.

Was die Wirtschaft von der Forschung lernen kann

First-Principles-Thinking

Egal ob in Wirtschaft oder Forschung: Lösungen müssen immer auf einem logischen Fundament aufbauen. Leider stützen sich Unternehmen jedoch oft auf Dogmen – Regelungen, die einen unumstößlichen Wahrheitsanspruch erheben. Viel zu oft basieren Entscheidungen nicht auf Argumenten, sondern es gilt das Recht des Erfahrensten, und so wird schließlich entschieden, wie es „immer schon gemacht wurde“. Das tötet nicht nur die Innovationskraft, sondern führt auch zu grotesken Auswüchsen in der Praxis. So werden etwa Messebenen mit nur zwei Stützpunkten definiert, obwohl für die Definition einer Ebene mathematisch unumstößlich drei nötig sind. Unmögliches wird dann möglich, indem man Unterschiede mit dutzenden Offsets und zahlreichen Messberichten so lange anpasst, bis alle Seiten ‚das Gleiche‘ messen. Eine fundamentale Feststellung, dass eine Ebene eben 3 Messpunkte braucht kann hierbei hunderte Stunden Zeit und Geld einsparen. Die Zeit für First-Principle Thinking steht oftmals in keiner Relation dazu, da man wesentliche Logikfehler meist in wenigen Stunden feststellen kann.

Unvoreingenommene Herangehensweise

Problematisch wird es auch, wenn Prozesse und Tools so festgefahren sind, dass neue Methoden und Ansätze kein offenes Ohr mehr finden. Natürlich herrscht in der Wirtschaft ein stärkerer Kostendruck, und man kann nicht auf jede Neuheit sofort aufspringen. Trotzdem sollte man unvoreingenommen gegenüber Neuem bleiben. Oftmals kommen aber immer wieder dieselben Tools oder Frameworks zum Einsatz – bloß weil sie jemand schon kennt – anstatt zu hinterfragen, was wirklich am besten geeignet ist.
Aktuell stellen wir unsere Vision-App auf neue Beine. Dafür sind wir bewusst technologieoffen und prüfen, wie wir das neue Frontend gestalten. Unser Bildverarbeitungs-Leiter hat dazu sehr pointiert formuliert: „Wir sind für jedes Framework offen, aber nur, wenn dafür technische Argumente vorliegen. >Weil ich Erfahrung in XY habe< spielt dabei keine Rolle.“ Ein Team, das nur innerhalb seines eigenen Erfahrungshorizonts denkt und Tools stets nach Vertrautheit auswählt, wird irgendwann zwangsläufig überholt. Dem First-Principles-Thinking folgend ist das dann unausweichlich.

Entwicklerische Freiheiten

Ich habe mittlerweile schon einige Masterarbeiten betreut, und das Konstrukt bietet oft erhebliche individuelle Freiheiten. Ähnliches gilt auch für viele Doktorarbeiten: Man legt das Vorhaben auf einer Folie oder einer einzigen A4-Seite fest, und dann macht sich der Forschende für Monate oder Jahre auf die Suche nach Ergebnissen. Die Betreuung erfolgt meist durch eher loses Feedback – trotzdem entstehen dabei oft großartige Resultate.
Dass ein so lockerer Ansatz für die Wirtschaft mit ihren harten Deadlines nicht 1:1 taugt, liegt auf der Hand. Jedoch ist dort häufig das Gegenteil der Fall: engmaschiges Mikromanagement, das in vielen Firmen längst zum Standard geworden ist. Dabei halte ich es für extrem wichtig, seinen Entwicklern so sehr vertrauen zu können, dass man sie nicht mikromanagen muss, sondern ihnen viel Eigenverantwortung und schöpferische Freiheiten gewährt.
Allerdings bin ich auch überzeugt, dass man das nicht einfach erreicht, indem man einmal ein Scrum-Buch liest und dann ‚agile Entwicklung‘ einführt. Es steht und fällt damit, dass man die richtigen Entwickler ins Team holt. Ich bin auch davon überzeugt, dass der agile Ansatz für viele Persönlichkeiten einfach nicht funktionieren kann und wird. Ich selbst musste auf diesem Weg viel dazulernen und bin froh, dass wir bei AutoLab mittlerweile ein großartiges Team haben, in dem jeder jedem zu 100 % vertraut. So entstehen dann auch viele Freiräume für kreative Entwicklung und Innovation.

Was die Forschung von der Wirtschaft lernen kann

Effizienz und Skalierung

Es ist oft extrem beeindruckend, welche technischen Neuheiten und Ansätze schon in einer Masterarbeit entstehen. Leider sind diese aber meist kaum für andere nutzbar. Die großen Freiräume in der Umsetzung führen oft zu katastrophalen Codebasen – und mittlerweile bestehen fast alle technischen Arbeiten, nicht nur jene der Informatik, zu einem erheblichen Teil aus Software.
Das Resultat ist dann häufig eine unwartbare Codebasis mit kaum vorhandener oder schlechter Dokumentation und einem monolithischen Framework. Fast immer fehlen gängige Praktiken wie Unit-Testing, wodurch der Code noch voller kleinerer (und größerer) Bugs steckt. Sobald eine weitere Arbeit darauf aufbauen soll, muss sich der neue Mitarbeiter oder Forscher erst einmal wochen- oder sogar monatelang in das monolithische Framework einarbeiten. Meist wird dann vieles neu geschrieben.
Die Zeit, die dadurch verloren geht, ist enorm und könnte besser in eigentliche Forschung investiert werden. Die Voraussetzung für eine effizientere Zusammenarbeit ist allerdings das Bewusstsein für saubere Codequalität und gemeinschaftliches, agiles Arbeiten. Häufig entstehen jedoch Insellösungen, in denen sich am Ende nur ein einzelner PhD oder Masterstudierender zurechtfindet. Etwas strengere Vorgaben an die Umsetzung könnte dies meiner Meinung nach verhindern, ohne die forscherische Freiheit einzuschränken.

Projektmanagement

Agiles Projektmanagement, wie etwa Scrum, wäre meiner Meinung nach für viele Forschungstätigkeiten ideal geeignet. Tools wie JIRA oder Confluence könnten dabei helfen. Natürlich gibt es am Ende des Tages zahlreiche Paper und Arbeiten, die die genaue Methodik und Herleitungen beschreiben. Allerdings fehlt oft ein Knowledge-Wiki für die verwendeten Tools und entstandenen Frameworks. Die Beschreibung des ‚Klein-Kleins‘ – beispielsweise, wie man neu entwickelte Software-Libraries nutzt – geht häufig verloren. Damit geht wichtiges Wissen verloren und es wird unnötig viel Zeit verschwendet.
Bei offenen Forschungsfragen passiert es immer wieder, dass sich Personen in vielen Nebenschauplätzen verlieren. Die Definition von konkreten Aufgaben (Tasks) und Sprints könnte aus meiner Sicht den „Zug zum Tor“ und damit auch den wissenschaftlichen Output erheblich erhöhen. Da agile Frameworks ohnehin darauf ausgelegt sind, viel Freiraum zu lassen, würden sie auch nicht zu starr wirken, um neue Entdeckungen oder Erkenntnisse zu verhindern.

Ergebnisorientierung

Auch in meinem Bekanntenkreis habe ich schon oft erlebt, dass sich manche Personen beim Verfassen wissenschaftlicher Arbeiten in falschem Perfektionismus verlieren. Was genau ist eigentlich die Definition einer „perfekten Arbeit“? Nach welchen Kriterien würde man den Text messen? Natürlich muss eine wissenschaftliche Arbeit hohen Qualitätsstandards genügen, aber keine wird jemals vollständig perfekt sein.
In der Wirtschaft gibt es in der Regel immer eine Deadline oder irgendeine Form von Zeitdruck. Ich denke, jeder hat schon die Erfahrung gemacht: Egal, wohin man die Deadline legt – das Projekt wird ungefähr zu diesem Zeitpunkt fertig. Und mit jedem Tag, den die Abgabe näher kommt, steigt meist auch die eigene Produktivität rasant.
Ich bin überzeugt, dass Freiheit in der Forschung sehr wertvoll ist, aber klar definierte inhaltliche und zeitliche Ziele könnten den Prozess noch deutlich verbessern. Gerne dazu auch mal das Parkinsonsche Gesetz nachschlagen.