Klausur im zweiten Semester Mathematik. Lineare Algebra ist angesagt, es geht um einen Schein, der notwendige Voraussetzung für die Zulassung zum Vordiplom ist. Bei der großen Masse an Studenten lässt es sich nicht vermeiden, dass sich mehr als einer (das sind mindestens zwei) zwischendurch in den sanitären Anlagen des Hörsaalgebäudes zusammentreffen. Beim Händewaschen fragt der eine den anderen: „Was hast du bei Aufgabe 2 heraus?“ (das war eine wahrlich knifflige Rechenorgie!). Antwort: „Ein Viertel.“ Große Erleichterung auf beiden Seiten, da die jeweiligen Lösungen übereinstimmen. Die Überprüfung der Lösung durch Einsetzen in die Ausgangsgleichung kann man sich jetzt möglicherweise sparen. Die Lösung ist das Ziel.

Nein, da ist etwas falsch verstanden worden. Was wir mit Befriedigung verglichen haben, war nicht die Lösung, sondern das Ergebnis. Hier fand eine Verwechslung von Weg und Ziel statt. Eine Standortbestimmung, aber keine Überprüfung des steinigen Weges. Es gibt immer verschiedene Wege, die nach Rom führen…

Da fällt mir unsere Reise nach Rom ein. Da unsere Maschine ab Hamburg wegen Bodennebel in London nicht verfügbar war, wurden wir umgebucht und kamen entsprechend verspätet am Flughafen Rom an. Um von dort unser Hotel zu erreichen, hatten wir den kostenpflichtigen Shuttle Service des Hauses gebucht. Leider war auf dem Infoblatt des Reisebüros ein Zahlendreher in der Nummer des Hotels, der Shuttle kam vergeblich und wir mussten zahlen. Zum Hotel kamen wir dann mit einem der vielen Standby Busse, der uns auch vor der Tür absetzte und für dieses Gelegenheitsgeschäft nur einen Bruchteil des Hotel Shuttles berechnete. Das Ergebnis war das gewünschte, die Lösung allerdings nicht, weil wir über den optimalen Lösungsweg nicht informiert waren.

Mein zweites Jahr als SAP-Entwickler. Eine meiner regelmäßigen Aufgaben ist das Monitoring der Systemperformance. Wöchentlich sichte ich die schlimmsten Langläufer. Diese sind wahre Ressourcenschlucker. SAP übernimmt keine Verantwortung für Standardprogramme, die einfach in den Z-Namensraum kopiert und darauf basierend angepasst wurden. Gigantische Tabellen werden täglich sequentiell in voller Länge abgesucht, um die Handvoll Anlagenbuchungen als Tagesjournal zu erhalten. Eine Strategie zur Performanceoptimierung habe ich bald entdeckt, als angestellter Entwickler beim Endanwender habe ich eine gewisse Narrenfreiheit, also wird gemacht. Am nächsten Tag gehe ich zum Anwender, und informiere ihn über den ewigen Langläufer. Natürlich nervt es auch ihn, immer wieder zu warten, bis er seine Liste generiert hat und ist happy, dass er dank meiner Lösungsidee jetzt schnellere Antwortzeiten hat.

War das lösungsorientiert? Jein, würde ich sagen. Natürlich gab es ein Problem, dass sich durch eine technische Maßnahme lösen ließ. Andererseits lieferte ich in diesem Fall die Lösung für ein Problem, dessen sich der Anwender noch gar nicht bewusst war. Zwar störte ihn die Langsamkeit des Programms, aber er war noch so in der alten Batchwelt verhaftet, dass ihm gar nicht die Idee kam, dass SAP R/3 als Echtzeitsystem verstanden werden konnte. Eine allgemeinere Betrachtung dieser Voraussetzungen hätte möglicherweise eine umfassendere Prozessoptimierung als nur die schnellere Antwort eines einzigen Programms gebracht. Kann man überhaupt von Lösungsorientierung ohne Problemanalyse sprechen? Ich freue mich auf Ihre Diskussionsbeiträge.