Logik vs. Daten // SAP vs. SimDia² // Programmierer vs. Anwender

Posted on by Enno Wulff

Related Post

Ich bin Programmierer aus Leidenschaft. Ich liebe es, Daten so zu malträtieren, umzuformen und anzureichern, dass eine für den Menschen sinnvolle Darstellung dabei herauskommt. Ebenso liebe ich es, Anforderungen so umzusetzen, dass am Ende ein paar zufriedene Anwender vor dem PC und wohlgeformte Daten auf der Datenbank sind. Zudem bin ich bestrebt, die Programmierungen so universell und wiederverwendbar wie möglich zu gestalten.

Voraussetzung dafür ist, dass der Anwender oder Kunde sich exzellent ausdrücken kann und sehr genau weiß, was er möchte und seine Prozesse und Daten selbst gut kennt. Dabei ist nicht nur der aktuelle Zustand wichtig, sondern auch, wie es mit den Daten weiter gehen soll. Wie müssen sie weiter verarbeitet werden? Inwieweit müssen sie wie lange änderbar sein? Häufig müssen im Nachhinein wilde Verrenkungen gemacht werden, um Dinge zu prüfen oder sicherzustellen, die bei sorgfältiger Planung – ich glaube so etwas nennt man 360°-Sicht – nicht nötig gewesen wäre.

Zugegebener Maßen ist das nicht immer möglich, denn sehr oft entwickeln sich Dinge einfach. Aus einem ehemals kleinen Auswertungsreport entsteht nach und nach die Schaltzentrale für eine ganze Abteilung.

Daten

Die Daten sind tatsächlich der wichtigste Bestandteil bei der Programmierung in einem ERP-System. Dadurch, dass die Daten in Strukturen abgelegt und organisiert werden, ist es recht einfach, zusammengehörende Daten zu ermitteln. Es ist allerdings sehr schwer, diese Strukturen erst einmal zu erkennen und dann zu erzeugen. Zudem ist es schwer, wenn nicht gar unmöglich, anhand der Daten die Zugehörigkeit zu Prozessen zu ermitteln. Um die zu einem Prozess notwendigen Daten zu wissen, müsste ein detailliertes Datenflussdiagramm erstellt werden. Das wird jedoch kaum gemacht, denn es ist unendlich viel Arbeit und starken Änderungen unterworfen.

Logik

Für einen Programmierer ist es sehr wichtig zu wissen, wo welche Daten stehen und wie sie verarbeitet werden müssen. Der Programmierer muss die Daten so verarbeiten, dass am Ende das gewünschte Ergebnis heraus kommt. Dafür ist es notwendig, dass er bestimmte Logiken anwendet. Einige Logiken ergeben sich aus den Einstellungen im Customizing, andere Logiken müssen vom Fachbereich bzw. dem Kunden vorgegeben werden. Sofern es genug “Beweismaterial” gibt, können aus speziellen Anforderungen allgemein gültige Logiken abgeleitet werden. Diese wiederum können im Kundeneigenen Customizing abgebildet werden. Dies hat den Vorteil, dass die Lösung flexibel und vom Kunden steuerbar ist.

Programmierer

Ja, es mag ein Klischee sein, aber Programmierer sind ein wundersames Völkchen. Ich spreche aus eigener Erfahrung… 😉  Programmierer sind in der Regel sehr Technik-affin und sind mehr daran interessiert, eine möglichst figgelinsche Lösung zu präsentieren oder eine besonders komplexe Aufgabenstellung zu meistern. In der Regel haben Programmierer wenig Sinn für Design und Layout. Ja, es gibt Ausnahmen…! Aber meistens bilden Programmierer genau das ab, was in der Vorgabe steht – egal wie es aussieht und ob es den SAP-Design-Vorgaben gleich in mehreren Ebenen widerspricht. Der einfachste Weg, einen Programmierer zur Arbeit zu bewegen ist, ihm zu sagen: “Das geht nicht. Haben schon andere versucht”.

Anwender

Auch Anwender sind häufig speziell. Sie müssen mit ihrer Arbeit fertig werden und sie wollen ihre Arbeit in der Regel gut machen. Anwender verstehen ihre Daten und ihre Prozesse. Aber sie können häufig nicht einschätzen welche Auswirkungen Änderungen in ihrem Bereich auf andere Teile der Firma haben. Zudem schätzen sie häufig die Komplexität von Programmieraufgaben falsch ein. Dinge, die einfach zu programmieren sind, weil bereits ähnliche Programmierungen vorhanden sind oder es eine SAP-Funktion dafür gibt, werden eventuell als zu komplex abgetan. Andererseits werden Dinge, die sich verbal einfach ausdrücken lassen und offensichtlich sind, als einfach eingeschätzt. Dabei sind gerade diese Dinge schwer und aufwändig zu programmieren.

Programmierer vs. Anwender

Im allgemeinen mehr oder weniger chaotischen Durcheinander, was in einigen Firmen Alltag genannt wird, müssen Programmierer und Anwender (Fachbereiche) miteinander auskommen und sich gegenseitig soweit verstehen, dass eindeutige Ergebnisse erzielt werden. Ein guter Programmierer wird versuchen, ein Schema, eine Logik, eine allgemein gültige Regel zu finden oder scheinbar allgemein gültige Regeln zu hinterfragen. Ein guter Anwender kennt seine Daten und Prozesse und erkennt Daten, die “nicht passen” oder “unsinnig” sind. Dahingehend unterscheiden sich in der Regel Programmierer und Anwender. Denn genau das, was der eine kann, kann der andere mit ziemlicher Sicherheit nicht. Ein Programmierer kann nicht erkennen, ob Daten unsinnig sind und ein Anwender erkennt selten die technische Logik hinter bestimmten Prozessen oder Funktionen.

Logik vs. Daten

Für einen Anwender ist es eventuell einfacher “seine” Daten so zu ordnen, wie sie für ihn aktuell sinnvoll und wichtig sind. Um Daten aus einem Fremdsystem oder manuell erarbeiteten Prozessen in ein SAP-System zu übernehmen gibt es im Grunde zwei maschinelle Möglichkeiten

  1. Anwender und Programmierer setzen sich zusammen und definieren eine Datenstruktur. Sie besprechen, welche Daten wann unter welchen Bedingungen wo hin müssen. Der Programmierer arbeitet in der Regel mit einer (je nach Anforderung natürlich auch mit mehreren) allgemeinen Datenstruktur. Felder, die für einen Datensatz nicht relevant sind, bleiben leer. Der Programmierer erstellt dann ein Programm mit den entsprechenden Regeln, um die Daten ins SAP-System zu schreiben.
  2. Der Anwender baut sich seine Daten in Gruppen so zusammen, wie sie für ihn logisch sind. Dabei ist es egal, dass er 12 Excel-Blätter hat, die alle zu 90% die gleiche Struktur haben. Für ihn ist wichtig, dass er die komplexen Daten möglichst einfach gruppieren und verwalten kann. Der Anwender kann dann einen einfachen Prozess starten, um die Daten zu übernehmen (zum Beispiel mit SimDia²).

Die erste Lösung würde ich als Programmierer natürlich immer bevorzugen. Immerhin verdiene ich damit mein Geld. Es ist jedoch nicht von der Hand zu weisen, dass eine Programmierung fast immer recht kompliziert ist. Es sind Absprachen mit dem Auftraggeber notwendig, es muss getestet werden, es müssen Programme transportiert werden usw. Zudem erfordert die Arbeit in der Ausführung häufig zwei Leute: Einen aus der IT (Programmierer), der Daten in ein Verzeichnis schiebt, Daten hochlädt, Daten konvertiert und so weiter. Der Anwender ist hilflos, wenn etwas nicht so funktioniert, wie er es erwartet.

Die zweite Lösung mag auf den ersten Blick nicht professionell erscheinen. Im Hinblick darauf, dass Daten meistens regelmäßig und von beliebigen Personen übernommen werden sollen, wird eine “Frickellösung” häufig nicht in Betracht gezogen.

Dass der Anwender meistens gar nichts machen kann, liegt häufig an diesen zwei Umständen:

  1. Es gibt häufig keine guten Möglichkeiten für einen Anwender, Daten massenhaft in ein SAP-System zu importieren.
  2. Die IT-Abteilung hat für kleinere Aufgaben häufig keine Zeit und keine Kapazitäten.

Die cleverste Möglichkeit, von der ich gehört habe ist die folgende: Ein Poweruser (also ein Benutzer mit hinreichend guten Berechtigungen zum Ausführen von Programmen) hat sich die Batchinputstruktur zu einem SAP-Standard-Übernahmeprogramm genommen, diese in Word bearbeitet und mit Hilfe der Serienbrieffunktion eine Batchinputdatei für seine Daten generiert. Die so erzeugten Batchinputmappen hat der Anwender dann eingespielt. Ich weiß leider nicht mehr genau, um welche Daten es sich handelte.

Diese Lösung erfordert jedoch umfangreiche Berechtigungen, sehr gutes Word- und Excelwissen sowie natürlich ein vorhandenes SAP-Übernahmeprogramm.

Alternative SimDia²

Das Addon SimDia² von Ersasoft ist eine – gemessen am Nutzen – kostengünstige Alternative für den Fachbereich um alltäglich wiederkehrende Datenübernahmen einfach und effizient zu erledigen. Der Anwender hat zumeist hinreichende Excel-Kenntnisse und er kennt seine SAP-Anwendungen. Die Bedienung von SimDia² ist sehr leicht und darauf ausgelegt, wiederkehrende Datenimporte von Excel nach SAP auszuführen.

Beispiele für die Anwendung sind:

  1. Übernahme von Vertriebsstücklisten
  2. Ausführung von Buchungen
  3. Anlage von Fertigungsaufträgen
  4. Gezieltes Ändern von Materialstämmen

SimDia² kann sogar dazu genutzt werden, um Daten aus einem SAP-System für Auswertungszwecke zu sammeln, da SimDia² Felder einer SAP-Transaktion auslesen kann. Ein Anwender kann sich so also gezielt selber Listen erstellen, ohne dass er die entsprechenden SAP-Tabellen kennen muss. Besonders gut funktioniert das bei Daten, die für einen Programmierer nur sehr umständlich zu ermitteln sind, da die Daten auf viele untereinander verknüpfte Tabellen verteilt sind.

Enno Wulff
Letzte Artikel von Enno Wulff (Alle anzeigen)