und wie das SQL Cockpit uns das Leben vereinfachen kann

Wer kennt das nicht. Die Systeme sind aufgesetzt und eingestellt, die Erweiterungen programmiert und die Schnittstellen laufen. Die Tests waren erfolgreich und das SAP System wurde produktiv gesetzt. Dennoch kommen immer wieder Supportanfragen herein. 

Das kann natürlich verschiedenste Gründe haben. Nehmen wir mal an, dass die Entwicklungen sehr sauber waren, das System gründlich getestet wurde und wenig es kaum neue Anforderungen gibt, die umgesetzt werden, gibt. Unrealistisch? Wahrscheinlich! Aber das es in einem agilen Umfeld mit laufenden Erweiterungen an den Systemen zu Fehlern kommt, ist irgendwie nachvollziehbar. Da ist ja immer alles in Bewegung. 

Aber was sind die häufigsten Gründe für Fehlertickets abseits vom typischen Projektgeschäft? Mir fallen da spontan 2 Gründe ein. 

1. Verständnisfragen. Gerade, wenn User Transaktionen selten aufrufen, kann es zu Fragen wie „Was muss ich hier eingeben? Warum bekomme ich da einen Fehler?“ . Das kann man meist mit guten Schulungsunterlagen in den Griff bekommen.
2. seltene Datenkonstellationen. Da kommt auf einmal ein Kunde vom Typ X, aus dem Land Y und der VKORG Z daher. Und da funktioniert dann die Partnerfindung im Beleg plötzlich nicht. Der Grund kann sein, dass diese seltene Kombination beim Test nie abgefragt wurde. Solche Datenkonstellationen können entweder durch Benutzer eingegeben worden sein, aber auch durch Programme verursacht worden sein (zB durch eine Migration oder Schnittstelle)

Wie löst man nun diese Fälle von Datenproblemen?

Im ersten Schritt schaut man sich wohl den Beleg, die Stammdaten des Partners und dann vielleicht auch das Customizing an. Über die regulären Transaktionen im SAP System. Wann man dann gleich draufkommt, super! Fall gelöst.

Aber meistens kommt man da nicht weiter. Vor allem im Second und Third Level Support ist man eher im Programm Code und auf der Datenbank unterwegs um Fehler zu finden und auch um abzuprüfen, ob es auch mehrere ähnlich gelagerte Fälle gibt. Und genau da lässt einen das SAP System meist ordentlich im Stich.

Der übliche Weg führt einen dann in die SE16 (wer den Transaktionscode nicht kennt: da geht es zur Einzeltabellenansicht). Dort sucht man dann nach dem entsprechenden Datensatz und hantelt sich dann langsam von Tabelle zu Tabelle. Mit dem Umweg über das Notepad oder Excel, in dem man die Daten copy&paste zwischen lagert. Das ist mühsam und aufwendig. Aber noch schlimmer: ich muss beim nächsten Mal die gleichen Schritte nochmal machen. Und ganz ehrlich, bei SAP geht es um Daten. Daten, die in einer Datenbank abgelegt sind. Und seit Anbeginn (das sind auf R/2 bezogen 42 und auf R/3 gerechnet 30 Jahre) gibt es keine vernünftige Lösung, damit diese Daten schnell, flexibel und vA auch sicher durchforstet werden können.

Ein klassisches Beispiel sind wohl Inkonsistenzen bei Adressen. Wohl auch, weil die meisten SAP Berater und Kollegen den Teil der SAP Welt auch gut kennen. Geschäftspartner werden fast überall verwendet. Um Adressen zu Geschäftspartnern zu analysieren muss man zuerst vom BP Stamm (BUT000) über den Adresslink (BUT020) zu den Adressen (ADRC) springen.

Also Tabelle – Excel – Selektionsschirm – Tabelle – Excel – Selektionsschirm – Tabelle. Schon ist man am Ziel. Aber dann kommt man drauf, dass es um Personen geht und dort auch das Feld PERSNR mitspielt. Also wieder alles von vorne…

Und jetzt kommt das SQL Cockpit ins Spiel. Hier kann ich mir die Tabellen alle gleichzeitig anschauen und verknüpfen. Da sehe ich das Problem dann auch einen Blick. Und was noch besser ist, einmal ausgeführt, bleibt die Abfrage in meiner Historie bestehen und ich kann sie jederzeit wieder ausführen. Beim ersten Problem bin ich mit dem SQL Cockpit vielleicht nur geringfügig schneller als „von Hand“, aber beim zweiten Mal spar ich schon 90% der Zeit. Und wenn es dann doch öfters auftritt, dann speichere ich diese Abfragen zusätzlich ab und stelle sie sogar meinen Kollegen zur Verfügung.

Am nächsten Tag einfach das Statement von gestern genommen:

und irgendwann nach dem 3,4 Mal (ok, bei mir wahrscheinlich nach dem 20. Mal – ich bewundere die Kollegen die so strukturiert sind) wird das ganze abgespeichert damit es auch die Kollegen nutzen können:

Ich nutze das SQL Cockpit seit 10 Jahren bei meinen Kunden. Und es ist aus meiner täglichen Arbeit nicht mehr weg zu denken. Manche Kunden nutzen es noch nicht, da muss ich dann auch immer über die SE16 arbeiten 🙁

Zählt doch mal, wie oft ihr täglich die SE16 nutzt. Wenn ihr in eurem Unternehmen auf weniger als 10 Abfragen pro Tag kommt (wohlgemerkt im gesamten Unternehmen, nicht pro User!), dann ist das SQL Cockpit für euch wahrscheinlich nicht geeignet. Sobald ihr mehr Abfragen macht, dann wird es sehr nützlich sein!.