Wenn man von Anwendungen auf Mikrocomputern oder innerhalb lokaler Netze spricht, denkt man meistens an Texteditoren, an Kalkulationsprogramme oder auch an integrierte Pakete. Die Wahrheit ist (leider), daß solche Standardsoftware allenfalls verschiedene Anwendungen unterstützt oder ermöglicht. Herbert Neumaier, Geschäftsführer von InterFace Concilium, München, geht in diesem Beitrag darauf ein, wie sich echte Anwendungen durch die überlegte Kombination von solch "anwendungsnaher" Software, aber auch von eher systemnah empfundenen Komponenten realisieren lassen.
Textbearbeitung oder Tabellenkalkulation sind keine Anwendungen, weder auf einem einzelnen Mikrocomputer noch in einem lokalen Netz. Anwendungen sind vielmehr zum Beispiel: Briefe entwerfen, formulieren, schreiben und geordnet verwalten; oder: die Abwesenheitsliste führen und aus ihr Auskünfte erhalten; oder: die Terminkalender für alle Mitarbeiter auf dem laufenden halten.
Alle diese wirklichen Anwendungen, wobei wir uns hier auf Anwendungen im Rahmen des Büros beschränken, setzen sich in der Regel aus dem Gebrauch einzelner Komponenten von anwendungsnahen Standardprogrammen, wie zum Beispiel dem Texteditor und von tieferliegenden Komponenten, wie einzelnen Betriebssystemfunktionen, zusammen. Erst die sinnvolle Festlegung der Kombination der Komponenten macht aus neutralen Programmstücken die Anwendung in der betrieblichen Wirklichkeit.
So gesehen, bedeutet Anwendung die Abbildung betrieblicher Aufbau- und Ablauforganisation auf die Menge der verfügbaren Programme innerhalb der Datenverarbeitung.
Auf Stand-alone-Mikros nicht möglich
Wer immer diese Abbildung für irgendeine betriebliche Funktion versucht, wird bald zu zwei Erkenntnissen gelangen:
Erstens: Es gibt kaum einen Ablauf im Unternehmen, der ohne Nachrichtenaustausch zwischen betrieblichen Instanzen auskommt.
Zweitens: Es gibt kaum einen Vorgang im Unternehmen, in dessen Verlauf nicht dieselben Daten von unterschiedlichen Organisationseinheiten benötigt werden.
Daraus folgt, daß sich echte betriebliche Anwendungen auf einige oder viele alleinstehende Mikrocomputer nicht vollständig abbildbar sind: Der Nachrichtenaustausch muß bei dieser Topologie notgedrungen auf die "altmodische" Weise erfolgen und der Zugriff auf gemeinsame Daten bedeutet Hin- und Herreichen von Floppy Disks.
Erst durch die Verbindung der Rechner zum Netz ist die lückenlose Realisierung von Anwendungen möglich.
Wir wollen uns hier besonders mit den Aspekten befassen, die netzspezifisch sind. Dabei werden wir sehen, daß dem Electronic Mail im lokalen Netz eine zentrale Rolle als Steuerungsbasis für das gesamte Unternehmen zuwächst: es treibt die betrieblichen Prozesse. So wie die betriebliche Dynamik erst Mail mögliche wird, so lebt die statische Ordnung von der grundsätzlichen Möglichkeit, auf alle Daten (logisch) zentral zugreifen zu können. Dabei können die Daten durchaus (physikalisch) dezentral gehalten werden.
Korrespondenz nicht gleich Textverarbeitung
Greifen wir uns zwei Anwendungen heraus, die typischerweise so nur in einem LAN realisierbar sind (und nicht mit stand alone PCs). Grundsätzlich können diese Dinge auch mit klassischer Mainframe-Topologie DV-gestützt ablaufen; aber üblich ist das bestimmt nicht.
Korrespondenz ist nicht gleich Textverarbeitung. Sie beginnt damit, daß ein Sachbearbeiter (in diesem Sinn kann auch ein Manager Sachbearbeiter sein), das Bedürfnis empfindet, einen Brief zu schreiben. Er tippt das Gerüst des Schreibens in seinen Arbeitsplatzrechner ein. Sodann stellt er diesen Roh-Brief in die gemeinsame Datenbasis ein und sendet seiner Sekretärin oder dem zentralen Schreibbüro ein Memo, daß das Gerüst existiert, und daß das Schreiben fertiggestellt werden soll. Vielleicht macht er auch noch auf Anlagen aufmerksam, die ebenfalls in der gemeinsamen Datenbasis zu finden sind.
Die Sekretärin wird durch ein optisches Signal darauf aufmerksam gemacht, daß ein Auftrag für sie eingetroffen ist. Sie überprüft Ihren Briefkasten. Anschließend bearbeitet sie den Brief. Dabei findet sie eine Formulierung, die ihr mißverständlich erscheint und klärt dies auf elektronischem Weg mit dem Sachbearbeiter ab. Sie formuliert den Brief aus und generiert einen Druckauftrag für ihn. Der Brief wird in die Warteschlange des passenden Druckers eingereiht, die Sekretärin kann sich jederzeit die Warteschlange anzeigen lassen und weiß so, wann sie mit dem Ausdruck rechnen kann. Ist der Ausdruck erfolgreich abgewickelt, so erscheint an ihrem Bildschirm wiederum ein optisches Signal. Sie trägt nun noch eine Zeile in das Briefe-Logbuch des Monats ein und übergibt den elektronischen Brief endgültig der Unternehmensdatenbasis, wo er noch für Monate und Jahre zur Verfügung steht. Durch den Eintrag ins Logbuch, kann er immer wieder schnell und sicher gefunden werden, zum Beispiel während eines Telefonats, das der Sachbearbeiter nach Monaten mit dem Adressaten führt. Muß noch erwähnt werden, daß die Adresse natürlich über ein Mail-Merge-Feature in den gedruckten Brief gelangte?
An dieser Anwendung waren beteiligt die Textverarbeitung, die elektronische Post, die Druckereiverwaltung, die Datenbank und das Mail-Merge-Paket. Die Anwendung ergab sich aus einer Kombination von Komponenten dieser Pakete.
Datensicherung als betriebliche Anwendung
Ich habe dieses Beispiel mit Absicht gewählt, weil ich den Einwand erwarte: "Datensicherung ist doch keine betriebliche Anwendung. Sie wird doch erst durch die Datenverarbeitung erforderlich!" So ist es nicht. Auch im reinen Papier-Büro muß ständig Datensicherung betrieben werden. Sehen Sie sich einmal die Ablage- und Archivorganisation in einem Großbetrieb an. Das ist Datensicherung in Reinkultur. (Dabei darf man Datensicherung nicht mit Datenschutz verwechseln. Erstere schafft die Sicherheit, kein Datum zu verlieren, beziehungsweise nach einem Verlust mit Sicherheit einen Backup aufzufinden. Letzterer verhindert den unbefugten Zugriff auf die Daten.)
Wer davon ausgeht, daß eine Unternehmung über lange Zeit alle Dokumente aufbewahrt und wiederauffindbar verwaltet, der muß eingestehen, daß Datensicherung eine Anwendung im oben definierten Sinn ist (und nicht eine DV-technische systemnahe Funktion).
Zentrale Instanz bleibt unverzichtbar
Alle Dokumente eines Tages werden in die Tagesablage aufgenommen, für die es ein nach Stichworten geordnetes Register gibt. Zusätzlich wandert eine Kopie in den kunden ??er lieferantenbezogenen Vorgang. Für empfindliche Daten werden in längeren Zeitabständen weitere Kopien gefertigt, die an einem sicheren Ort außerhalb der eigentlichen Betriebsstätte aufbewahrt werden.
Bei der Abbildung dieser Abläufe in die Umgebung des lokalen Netzes, werden fast ausschließlich betriebssystemnahe Funktionen verwendet, die man normalerweise nicht als Anwendungsprogramme bezeichnen würde. Und doch realisieren sie eine Anwendung. Ich denke an die Copy-Funktion, an die Ermittlung des Inhaltsverzeichnisses eines Volumes und an das Festhalten und Verwalten solcher Daten wie des Namens des Eigentümers oder des Tages der letzten Änderung.
Das erste Beispiel zeigt recht deutlich die Rolle des Electronic Mailing als Nachrichtensystem der Unternehmung. Das zweite erklärt, warum die Möglichkeit des Zugriffs auf alle Daten von einer Instanz aus unverzichtbar ist, wenn die Dokumente ordnungsgemäß gesichert und archiviert werden sollen. Beide Beispiele sind lückenlos nur im Netz realisierbar.
Betrachten wir noch eine weitere typische Büro-Anwendung: Die Verwaltung gemeinsamer Ressourcen, wie Besprechungsräume oder Overhead-Projektoren. Über das Electronic Mailing teilen die Mitarbeiter der Verwaltung den Bedarf mit, diese pflegt die gemeinsame Datenbasis, zu der alle Lesenden Zugriff haben. Die Wünsche werden ebenfalls über das Mailing-System bestätigt oder zurückgewiesen. Vielleicht fragen Sie, warum man nicht jeden Nachfrager direkt die Datenbasis updaten läßt. Nun die Folge wäre, daß der letzte Request gewinnt. Die Nachfrage nach einem knappen Gut, für das kein Markt existiert (und wo wird für einen Besprechungsraum schon etwas bezahlt), kann man nur durch eine zentrale Instanz regeln. Das ist keine DV-technische sondern eine organisatorische Erkenntnis. Darum braucht man hierfür sowohl Electronic Mail als auch die gemeinsame Datenbasis.
Überlegen Sie sich, wie ein Terminkalender geführt wird oder wie eine Betriebsbibliothek zu verwalten ist. Überall werden über Prozesse Statusänderungen abgewickelt und über Abfragen Statusauskünfte gewonnen.
Electronic Mailing und die gemeinsame Datenbasis machen die Abbildung betrieblicher Abläufe im Bürobereich in die Datenverarbeitung möglich. Die Abläufe komponieren sich aus Teilen verschiedener sogenannter Anwendungsprogramme und aus systemnahen Funktionen. Sowie es schwieriger ist, eine Symphonie zu schaffen als einzelne Noten zu schreiben, so liegt auch hier die Kunst im richtigen Arrangement der einzelnen Instrumente, die Editor, Kalkulationsprogramm oder auch file-concatenate heißen mögen.
Vorbedingung aber ist immer die Vernetzung. Ohne sie gäbe es weder Electronic Mail noch die gemeinsame Datenbasis. Die Komposition der Anwendung müßte Stückwerk bleiben.