Dr. Erhard Becker,

EDV-Leiter, Kaiser Aluminium Europe, Werk Koblenz

Was unternimmt ein EDV-Leiter in folgender typischer Situation?

Neue Projekte sind zu realisieren, wobei die Manpower in Systemanalyse und Programmierung knapp ist und die tägliche Belegung seiner zentralen EDV-Anlage schön bei gut 16 Stunden liegt. Auch seine Konfiguration ist nicht untypisch: Zentraler Rechner mittlerer Größe und mittleren Alters, ein Datenerfassungspool mit Rechner auf Magnetband- und -Kassettenbasis.

Was unternimmt er also? Er holt Angebote von Softwareherstellern für einige seiner Neuprojekte herein und stellt die Belegungsschwierigkeiten zunächst hinten an.

Wenn er dann ein Angebot zum Beispiel für ein etwas aufwendigeres Auftragsabwicklungs- und Fakturiersystem für eines der von ihm zu betreuenden Profitcenter in Höhe eines MDT-Rechners plus Software bekommt, ist die Situation - so meine ich - immer noch typisch.

Die Preisgleichheit: Hier Software für den zentralen Rechner, dort MDT-Rechner plus vom Hersteller maßgeschneiderter Software läßt ihn nicht los und bringt ihn auf einige Gedanken: Wenn er diesem Profitcenter nun tatsächlich einen MDT-Rechner hinstellen wurde, so könnte er auf dem zentralen Rechner täglich bis zu einer Stunde sparen. Und er sieht nicht ein, daß für jede Eingabe, Änderung, jedes Drucken von Lieferschein oder Rechnung der zentrale Rechner mit seiner nicht gerade billigen Peripherie belastet werden soll. Denn ein erheblicher Teil der Rechnerbelastung resultiert bei diesem Projekt aus den I/O's im weitesten Sinne, davon ein Hauptteil die Datenerfassung.

Warum also nicht dafür einen MDT- oder Datenerfassungsrechner einsetzen? Selbst mit Magnetplatte (statt Floppy) liegt die Miete einer solchen MDT-Konfiguration nur wenig höher als Terminal und Arbeitsplatzdrucker vom Mainframer.

Es stehen also drei Konzepte zur Diskussion:

Erstens: Offline auf dem zentralen Rechner mit allen damit verbundenen Nachteilen.

Zweitens: Online auf dem zentralen Rechner mit Terminal und Drucker am Arbeitsplatz des Sachbearbeiters und

drittens: Online auf MDT- beziehungsweise DE-Rechner mit Datenaustausch zum zentralen Rechner.

Wie kann eine Datenübertragung zwischen MDT und zentralem Rechner aussehen?

Vom MDT-Rechner gegebenenfalls via Modem und Stand- oder Wählleitung zum Datenerfassungspool, dort auf Magnetband. Dieses Magnetband kann zu jedem beliebigen Zeitpunkt auf den zentralen Rechner eingelesen werden. Umgekehrt auf dem gleichen Weg. Mit einigem Softwareaufwand läßt sich auch eine Kopplung herstellen, aber das ist nicht einmal erforderlich.

Und wie sind die organisatorischen Fragen zu lösen?

Die drei Hauptdateien eines Auftrags- und Fakturiersystems (Kunden-, Artikel- und Auftragsstammdatei) sind in ein differenziertes Master-Slave-System zu bringen:

Die dezentrale Kundenstammdatei (Slave) wird - als Auszug aus der zentralen Gesamtkundenstammdatei (Master) - im regelmäßigen Turnus vom zentralen auf den dezentralen Rechner überspielt. Änderungen sind somit nur in der zentralen Kundenstammdatei möglich. So wird ein Auseinanderlaufen der beiden Dateien verhindert.

Die Artikelstammdatei ist eine reine dezentrale Datei, die dort auch upgedatet wird. Ein Führen der Artikelstammdatei im zentralen Rechner erübrigt sich meist.

Die dezentrale Auftragsstammdatei muß von der Natur der Sache her die Master-Datei sein. Auszüge werden in Form von Zugängen und Veränderungen für das zentrale Berichtswesen erfaßt. Spezifizierte vertreter- und bezirksbezogene Verkaufsanalysen werden auf dem dezentralen Rechner durchgeführt, summierte Auftrags- und Verkaufsanalysenberichte werden zentral durchgeführt. Dadurch besteht die Möglichkeit, daß zu jedem beliebigen Zeitpunkt spezifizierte Verkaufsstatistiken dezentral abgerufen werden können.

Das dezentrale System kann also voll Stand-alone arbeiten, daher auch bei Ausfall von Übertragungseinrichtung und zentralem Rechner. Es ist zwar nur eine Vermutung, aber ich glaube, man liegt mit folgender Aussage psychologisch richtig: Der Benutzer mit seinem

dezentralen Arbeitsplatzrechner toleriert einen Ausfall seines "Rechners" eher als einen Ausfall des zentralen Systems, wenn er nur Bildschirm und Drucker vor sich auf dem Schreibtisch stehen hat.

Wahrscheinlich erreicht man sogar eine Erhöhung der Ausfallsicherheit: Statt der Abhängigkeit von drei Komponenten (zentraler Rechner, Übertragungseinheit, Terminal + Drucker) bei der reinen Terminallösung ist man nur von einer Komponente, dem MDT-Rechner, abhängig.

Noch ein Wort zu den Softwarekosten. Dank der Marktsituation wird für Software und Beratungsleistung für einen Mainframe-Rechner wesentlich mehr verlangt als im MDT-Sektor, auch wenn man diese Leistung nicht vom Mainframer in Anspruch nimmt, sondern von einem Softwarehaus. Hier liegen erfahrungsgemäß durchaus Faktoren von 1/2, wenn nicht gar bis 1/4 vor.

Es muß einschränkend gesagt werden, daß diese Vorgehensweise besonders geeignet ist bei geringem Integrationsgrad der Dateien und der Programmsysteme untereinander. Falls mittlerer oder hoher Integrationsgrad vorliegt, muß diejenige Schnittstelle gefunden werden, wo durch differenziertes Master-Slave-System ein Auseinanderteilen möglich ist.

Natürlich ist dies kein Standardrezept bei jeglicher Art von Rechnerüberlastung. Weiterhin kann man dieses Konzept auch nicht auf eine beliebige Anzahl von "Vor-Rechnern" erweitern.

Aber es gibt durchaus Bereiche im termingebundenen I/O-intensiven Vorfeld der Datenverarbeitung, in denen ein solches Konzept neben handfesten Preisvorteilen Organisationsvorteile für die Fachabteilung bringt, zum Beispiel die Unabhängigkeit durch die Stand-alone-Funktion und für die zentrale EDV-Abteilung den Vorteil, daß Mehrbelastung verhindert wird.

Warum nicht auch im kleinen Rahmen Distributed Processing betreiben? Die Vorteile brauchen hier nicht auf Anwender von Groß-Systemen beschränkt zu sein.