Das Programmieren und seine finsteren Seiten

Donnerstag, 15.11.2018. Ich bin ein Frühchen. Mit 13 Jahren begann ich zu programmieren. Seitdem habe ich im Grunde nie damit aufgehört, denn warum sollte ich mit etwas aufhören, das mir Spaß macht. Daher kann ich mir ein Leben ohne Programmieren schwer vorstellen. Das Doofe ist nur, ich werde nicht jünger.

Ich werde also gegen meinen ausdrücklichen Willen älter. Älter zu werden bedeutet nicht nur, dass man nicht mehr ins Bild des jungen, hippen Entwicklers passt, sondern auch immer »teurer« wird.

Dann gibt es noch den Trend Nearshoring, wo u.a. Teile eines Projekts wie die Umsetzung (oder auch alles) an ostdeutsche Unternehmen ausgelagert werden.

Entgegen dieser Trends nimmt mein Programmierumfang wie so ein Bauch bei meinen Kunden zu. Eigentlich finde ich das nicht so schlimm, nur bin ich Berater für IT Prozesse, spezialisiert auf SAP CRM. Je mehr ich beim Kunden umsetze, desto häufiger werde ich vom Kunden für weitere Implementierungen angesprochen. Ich bin also Opfer meines Erfolgs!

Es gibt aber eine Schattenseite bei der Implementierung, über die niemand offen spricht. In diesem Schatten lauern nämlich Dokumentation, Entwicklertests und in der finstersten Ecke die Bearbeitung von Fehlern auf dem Produktivsystem.

Schade, dass ich diese drei finsteren Gestalten nicht einfach auslagern kann!

Aus der Not heraus versuche ich, während der Umsetzung bei schwer testbaren Lösungen, wie es in integrativen Prozessen häufig vorkommt, Tools für das Testen und Nachstellen von gemeldeten gleich mitumzusetzen. So kann ich sehr schnell und ohne viel Aufwand sofort sehen, ob wir einen Fehler haben und wo dieser Fehler liegt (liegt es beispielsweise wirklich im SAP oder woanders). Erstaunlich finde ich, dass sehr wenige sich solche Gedanken machen und noch weniger etwas in der Art umsetzen.

Heute sprach Kriss mich wegen eines Produktivfehlers dieser Kategorie an. Es gab ein Problem bei der Telefonie-Integration (CTI) über Genesys mit dem SAP CRM Interaction Center.

Bevor ich mich mit der Erweiterung der Telefonie-Integration befasste, bekam ich mit, wie nervenaufreibend das Nachstellen oder Testen der notwendigen Schritte in diesem Prozess waren (teilweise noch sind). Ich brauche nur ein einziges Wort in den Flur beim Kunden zu rufen, und jeder weiß sofort, worum und um wen es geht.

***

»English!«

Ich höre noch wie dieses Wort durch Wände der benachbarten Büros drang, wo es auf unsere Gesichter traf und uns unfreiwilligen Zuhörern ein verschmitztes Lächeln zauberte.

»English!«

Wir wussten sofort, dass unser Kollege Kriss einen Testanruf tätigte. Den immer freundlichen und kaum aus der Ruhe zu bringenden Kriss fast schon genervt schreien zu erleben, war so surreal wie der Testanruf selbst.

Hörer abnehmen. Nummer wählen. Am Hörer warten. Den Momenten abpassen, an der die freundliche Stimme vom Band sagte, man solle jetzt etwas sagen und dann eine Taste drücken. Um dann festzustellen, dass dieser Moment, der so lange auf sich warten ließ, ganz schnell vorbei war.

Auflegen. Nummer wählen. Warten und zuhören. Dann ein hastiges »English! English!« ins Telefon rufen als könnte man durch die Lautstärke den verlorenen Zeitpunkt wieder einzuholen. Doch das verflixte Ding wollte einfach nicht hören.

Also wieder auflegen. Dann die Nummer wählen und mit erzwungener Geduld warten, so als sei man ein realer Kunde, der gefangen in einer endlosen Warteschlange war (das ironische daran: Dieser Kunde hat einen sehr guten Service).

Dieser Vorhof zur Hölle war die Testumgebung – um genau zu sein: die Konfiguration der Anwendungen, die miteinander interagieren mussten. Sie entsprach der echten Umgebung, denn der Test musste realistisch sein. Vielleicht war er auch zu realistisch.

Für einfache Tests, bei denen einer von uns (in diesem Fall Kriss) den Kunden spielen musste, waren die einzelnen Schritte, die wir durchführen mussten, um zu dem entscheidenden Punkt zu gelangen, in Testumgebung leider zu opulent, fast schon quälend ausschweifend (fast wie dieser Satz).

Anhand Kriss Ton, der je nach Verzweiflungsgrad zwischen gereizt und entnervt schwankte, konnte ein wenig geschultes Ohr mit erstaunlicher Präzision die Anzahl seiner Fehlversuche erraten. Meistens lag sie bei viel zu hoch.

Was bei uns für ein wenig Erheiterung und Abwechslung sorgte, war für ihn einfach zum Abbrechen.

Als ich dann gefragt wurde, ob ich bei diesem Thema unterstützen und Funktionen anpassen könnte, da musste ich »Ja« sagen. Als Berater direkt beim Kunden konnte ich im Grunde keine Anfragen ablehnen.

Bei der Vorstellung, ebenso wie Kriss bei Tests oder Fehleranalysen zu verzweifeln, graute es mir. Ich bin eher der Typ, der nicht lange fackelt und gleich ausflippt. Als Profi sieht man mir das natürlich nicht an!

Deshalb nahm ich mir vor, etwas mit zu entwickeln, um nicht der nächste Brüller zu werden.

Aus der Not oder aus Angst – eigentlich als erfahrener Berater (und im Gegensatz zu reinen Entwicklern) –, entwickelte ich eine Testkonsole. Sie erlaubt dem Nutzer, das Ganze unnötige Drumherum mit dem Anrufen, Abwarten, Hineinsprechen und dem anschließenden Weiterleiten des Anrufs ins SAP CRM, komplett mit einem einzigen Klick auf der Testkonsole zu bewerkstelligen. Nebenbei bemerkt eine unglaubliche Steigerung der Produktivität, denn dieses so salopp von mir dahingeworfenes »Drumherum« dauerte ca. 40 Sekunden – der Klick auf meiner Testkonsole nur eine Sekunde.

(Nur eine Randnotiz: Bei der Bewertung, ob jemand oder etwas teurer ist, muss bei den Kosten die Produktivität berücksichtigt werden, sonst ist der Vergleich nicht korrekt.)

Die Konsole habe ich sehr einfach aufgebaut: Ein Feld für die Eingabe der Telefonnummer des Kunden aus dem SAP System und ein Button, um den Anruf auszulösen.

Ich benötigte für die Entwicklung der Konsole keine Stunde, weil ich mir schon vorab Gedanken gemacht hatte, wie ich die umzusetzenden Funktionen für Tests wiederverwenden kann. Die fertige Konsole ersparte mir mehrere Stunden beim Entwickeln, beim Testen und der Fehleranalyse. Ebenso meinem Kunden, in diesem Fall Kriss. Das geht weiter bis zum Application Support.

Diese eine Stunde klingt nicht nach viel Zeit. Aber ein anderer Kunde in einem anderen Projekt: keine Zeit, kein Budget, zu viel Druck, zu viele Aufgaben, wurde nicht gefordert, wurde nicht spezifiziert, euer Problem (das der externen Dienstleister, wenn Fehler auftreten).

In Projekten wird häufig nur eine bestimmte Funktion betrachtet, aber nicht das Drumherum. Nicht, wie diese Funktion in die Anwendung eingebettet werden sollte. Nicht, wie man an diese Funktion gelangt, um sie aufzurufen. Nicht, wie diese Funktion sich auf die verschiedenen Nutzergruppen auswirkt. Nicht, ob der Mitarbeiter genervt ist, weil so viele Klicks und Navigationen durch die Anwendung nötig sind, um etwas Einfaches hinzubekommen. Nicht, wie der Mitarbeiter den Fehlerfall nachstellen etc.

Probleme werden leider viel zu häufig nach »hinten«, also auf später, verlagert. Man erkauft sich wenig Zeit im Jetzt, um später viel mehr Zeit aufzubrauchen – ich habe noch nie erlebt, dass man nicht am Ende des Projekts mit dem Vielfachen der »gesparten« Zeit bestraft wurde. Aber das ist das Problem derjenigen, die sich dann damit befassen müssen. In den meisten Fällen bin ich das (du erinnerst dich: Opfer meines Erfolgs).

Daher denke ich, bevor und während der Implementierung der Kundenanforderung, immer wieder an die Anwender. Ich bin also altruistisch und egoistisch zugleich, denn ich gehöre auch zum Anwenderkreis.

Die Fragen, die ich dem Kunden und ebenso mir stelle, sind einfach und fast immer gleich: Wie wird der Mitarbeiter im Kunden Contact Center mit meiner Umsetzung arbeiten? Wie kann der Mitarbeiter im Fehlerfall das Problem einfach nachstellen und analysieren. Welche Tools kann ich ihr oder ihm zu Hand geben? Wie kann ich gewährleisten, dass andere meine Implementierung leicht und einfach erweitern können? Etc.

***

»Gut, dass du diese Konsole gebaut hast«, sagte mir heute Kriss, was mich wieder freute. Und da diese Lösung erst diese Woche in einem neuen Markt eingeführt wurde, werde ich mich in den nächsten Tagen vermutlich immer wieder freuen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.