Probleme der fortschreitenden Integration konzentrieren sich häufig an den Stellen, wo verschiedenartige Systeme aufeinandertreffen: den Schnittstellen. Häufig aber werden gerade die Schnittstellenprobleme heruntergespielt oder verniedlicht. Dabei lassen sie sich oft nur mit hohem Aufwand lösen. Horst Kern* zeigt die Details auf, in denen meist der Teufel (= Kosten) steckt.
Anhand eines praktischen Beispieles soll die Problematik von Schnittstellen zwischen zwei getrennt entwickelten Programmkreisen in einem Industriebetrieb aufgezeigt werden. Der Istzustand: In diesem Unternehmen der Textilindustrie sind über Jahre hin die Entwicklungen im EDV/Org.-Bereich nach Vertrieb und Technik getrennt bearbeitet worden.
Der Vertriebsbereich umfaßte die Auftragsbearbeitung, Zuteilung von Fertigwaren vom Lager, Faktura und sonstige Statistiken und Auswertungen. Zur technischen Seite gehörten Produktionsplanung, Fertigungspapierschreibung, Betriebsdatenerfassung, Auswertungen etc.
Die Zielsetzung: Die zentrale Disposition, die Verbindungsstelle zwischen Vertrieb und Technik, sollte in die Lage versetzt werden, mit Hilfe der EDV ihre Aufgabe besser zu erfüllen. Diese bestand darin, Kundenaufträge aller Art so einzuplanen daß bei hoher Kapazitätsauslastung die Bestände in Lagern und Produktion so gering wie möglich gehalten werden und trotzdem eine schnelle Lieferfähigkeit garantiert ist.
Diese miteinander konkurrierenden Bedingungen,
- hohe Lieferfähigkeit, das heißt kurze Liefertermine bei hoher Warenverfügbarkeit,
- geringstmögliche Mengen an Rohwarenlagern und in der Produktion sowie
- hohe Auslastung der Produktion, wollte das Unternehmen mit Hilfe der Deckungsrechnung-Disposition (DRD) in den Griff bekommen. Dazu war es erforderlich, die Schnittstellen zwischen der neu zu erarbeitenden DRD auf der einen Seite und den laufenden Systemen Vertrieb und Technik auf der anderen Seite zu definieren.
Genaue Kenntnis der Daten spielt eine große Rolle
Aus der Vielzahl von möglichen Schnittstellen - auch hardwareorientierten - sei hier nur die Problematik einer bestimmten Schnittstelle herausgegriffen, um dem Leser am praktischen Beispiel die Erarbeitung und Behandlung einer Schnittstelle zu zeigen. Beim Kommunizieren zwischen verschiedenartigen Anwender-Systemen wie Insellösungen ist die genaue Kenntnis der einzelnen Daten (die Felder in den Dateien) mit ihrer inhaltlichen Bedeutung und deren Abgrenzung von großer Bedeutung. Im vorliegenden Fall bestand von der DRD aus die Anforderung an das Vertriebssystem (VS), die noch offenen Kundenaufträge dekadenweise (AE zwischen Auftragseingang und Rechnungsausgang anhand von Lieferterminen) zur Verfügung zu stellen. Die Dekaden sollten einen Zeitraum von zwei Jahren umfassen, und es sollten Dekaden in der Vergangenheit mitgeführt werden. Kundenaufträge, die außerhalb dieses Zeitraumes lagen, das heißt vor den sechs Vergangenheits-Dekaden oder später, sollten in zwei Summenfelder zusammengefaßt werden.
Parallel-Speicherung kam nicht in Frage
Diese Anforderung war vom VS nicht ohne größere Änderungen zu erfüllen. Im VS waren diese Mengen zwar gespeichert, aber es bestand eine andere zeitliche Abgrenzung. Die offenen Auftragsmengen waren aufgesplittet in geplante Mengen nach Dekaden (was der Anforderung entsprach) und in zugeteilte Mengen, die nur summarisch geführt waren, obwohl die Zuteilung von Ware an Kundenaufträge schon maximal fünf Dekaden im voraus erfolgen konnte. Dies war notwendig, um sicherzustellen, daß für Kundenaufträge mit späteren Lieferterminen die Ware auch sicher reserviert und nicht durch Lagerverkäufe diesen Kundenaufträgen weggenommen wurde.
Es war notwendig, die zugeteilten Mengen im VS auch nach Dekaden aufzuspalten beziehungsweise diese zugeteilten Mengen im DRD parallel zu speichern. Eine Parallel-Speicherung wurde aus prinzipiellen Gründen verworfen, so daß nur eine Aufsplittung der Mengenfelder in Dekaden im VS in Frage kam.
Neue Programmierer waren gegen größere Änderungen
Wie groß wäre der Aufwand der Änderung im VS? Wie bei vielen anderen Anwendern war von den Programmierern dieses VS niemand mehr im Unternehmen. Neue Programmierer hatten sich bei notwendigen Änderungen in der Vergangenheit widerwillig eingearbeitet und lehnten größere Änderungen rundweg ab. Die häufigsten Begründungen waren:
- Programme haben die Obergrenze der Hauptspeichergröße erreicht,
- Die Programme sind unübersichtlich programmiert und bergen bei Änderungen die Gefahr in sich, an anderer Stelle unerwünschte Folgen zu erzeugen. Dies kann besonders bei Mengenfeldern, die von verschiedenen Programmen verändert werden, katastrophale Folgen haben.
- Eine brauchbare Dokumentation steht nicht zur Verfügung.
Die Forderung nach einer Neukonzeptionierung und -programmierung stand im Raume, bevor die für das Unternehmen so eminent wichtige DRD zur Realisierung kommen konnte. Denn es stand natürlich nicht genügend Personal zur Verfügung, um beide Projekte parallel zu realisieren. Das Unternehmen konnte auch nicht seine ganzen Investitions-Potentiale nur an den Ausbau der EDV-Systeme binden. Außerdem hätte die Entwicklung eines neuen VS sicher zwei Jahre gebraucht, so daß an eine Einführung der DRD nicht vor drei Jahren zu denken war.
Eindeutige inhaltliche Abgrenzung nötig
Ein Kompromiß führte schließlich zu einer zeitlich und kostenmäßig annehmbaren Lösung, wobei zwar die zugeteilten Mengen im VS in Dekaden aufgesplittet wurden, auf Vergangenheits-Dekaden aber verzichtet werden mußte. Das hieß, daß bereits das noch nicht eingeführte neue DRD mit Mängeln behaftet war, die in einer späteren Phase zur Überarbeitung anstehen.
Das Hauptproblem bei diesem Beispiel waren die nicht klar durchdachten Feldstrukturen. Besonders bei Verschlüsselungs-Systemen , sowie bei Mengenfeldern etc. werden immer wieder die Bedeutung der Daten und deren inhaltliche Abgrenzungen nicht klar und eindeutig vorgenommen. Dies führt dann besonders bei Vernetzung verschiedener Anwender-Systeme dazu, nachträglich und mit erheblich größerem Aufwand diese Datenstrukturen genau zu definieren.
Diese Art von Schnittstellen-Problematik wird in Zukunft auf viele Unternehmen zukommen.
Horst Kern ist Unternehmensberater in Bernbeuren