“Peter, kannst Du mal bitte ein Java-Programm schreiben, das Folgendes macht.” So oder ähnlich fingen schon einige meiner Projekte an. Inzwischen heißt es zwar zumeist nicht mehr Java, aber das Problem bleibt: Es ist ein suboptimaler Anfang.
Den Fehler, nun auftragsgemäß eine IDE zu öffnen und drauf los zu programmieren, hatte ich mir zum Glück relativ früh abgewöhnt. Denn natürlich ist es dem Business-Problem a priori vollkommen egal, mit welcher Technologie es gelöst wird. Mehr noch: auch dem Auftraggeber ist es normalerweise schnuppe, wie man sein Problem löst. Er assoziiert eben den Mitarbeiter mit einem technischen Werkzeug und wünscht sich eine zufrieden stellende Lösung.
Es gibt ja Patienten, die zum Arzt kommen und sagen: “Verschreibe mir folgendes Medikament.” Die Expertise des Arztes besteht darin, das genaue Problem zu ergründen und anhand dessen zu bestimmen, wie man am besten vorgeht. Und schließlich womöglich ein Medikament zu verschreiben, oder auch etwas ganz anderes. Das wird er sich nicht nehmen lassen, und vernünftigerweise gesteht man ihm zu, dass er es wohl am besten beurteilen kann.
Denn eigentlich lautet jeder Auftrag: bitte löse mir mein Problem.
Dem Quant, dem Data Scientist, oder wie man den Problemlöser am Computer diese Saison auch gerade nennt, sollte man die gleiche Expertise zugestehen wie dem Arzt: die Wahl der richtigen Mittel.
Diese benötigt zunächst etwas Zeit. Zeit, um sich die Konsequenzen jeder denkbaren Umsetzungsvariante vor Augen zu führen. Zeit, um sich den Kontext zu vergegenwärtigen, in dem die Lösung zukünftig eingesetzt werden soll. Zeit, um sich zu fragen, wer diese Lösung in Zukunft bedienen wird und ob diese Personen eigentlich existieren. Zeit, um über künftig notwendige Pflege-, Dokumentations- und Anpassungsvorgänge nachzudenken.
Denn Expertise heißt in diesem Fall nicht nur, die heißesten Tools zu kennen und einzusetzen (es mag Sonderfälle geben, aber im allgemeinen ist das nicht so). Expertise heißt auch, die Organisation im Blick zu haben, die Konsequenzen zu kennen, verantwortlich zu handeln.
Im anfangs erwähnten Beispiel wäre eine Java-Umsetzung vollkommen kontraproduktiv gewesen. Wie sich herausstellte, handelte es sich bei den Ausgangsdaten um semi-standardisierte Excel-Dateien. Sowohl deren Inhalte, als auch ihre Struktur waren veränderlich, und dass sich das so bald ändern würde, war nicht abzusehen.
Nun gibt es Technologien, die weitaus besser geeignet sind als Java, um Excel-Daten zu extrahieren. Aber weit gravierender als das: es hätte diverser zusätzlicher Personen bedurft, die diese Extraktionen immer wieder von neuem vornehmen. Das am Ende mit den so gewonnenen Daten gefütterte Modell hingegen wäre gegenüber diesem Aufwand vollkommen nebensächlich gewesen.
Das besser Vorgehen im oben erwähnten Fall: übergangsweise die erwünschen Funktionalitäten innerhalb Excel zu implementieren, und gleichzeitig einen Prozess zu etablieren, der die Eingangsdaten radikal standardisiert. So wird in einem späteren Schritt eine technische Weiterverarbeitung ohne oder fast ohne manuelles Zutun ermöglicht.
Und das ist der wirklich aufwändige Teil. Erfordert er es doch, eine Arbeitskultur dort in Frage zu stellen, wo die Eingangsdaten erzeugt werden und die Vorteile einer strengen Standardisierung nicht sofort auf der Hand liegen.
Ich fürchte, dass es den Einsteigern heute in der Beziehung nicht leichter gemacht wird. Denn natürlich lautet der Auftrag heute nicht mehr “schreib mal ein Java-Programm”, sondern “mach mal was mit KI”. Und wer kann sich dem schon entziehen, wenn alle darin eine Art universellen Heilsbringer sehen.
Slow down. Take a deep breath. Wähle die richtigen Mittel. Und vielleicht tut es ja diesmal ein Java-Programm. Wer weiß das schon vorher.