Wenn man sich kraft Amtes in einem Klein- oder Mittelbetrieb oder gar in einem Konzern mit Mikrocomputer-Software zu beschäftigen hat, kann man die letzten Illusionen über den eigenen Beruf des Informatikers verlieren. Doch die Dinger laufen und werden trotz vieler Vorbehalte täglich mehr. In Großbetrieben programmieren ganze Fachabteilungen um die Wette.
Argumente gegen den Mikro-Einsatz hält die zentrale EDV natürlich bereit: Mikrocomputer-
- Hardware ist zwar billig, aber die Summe aller Anlagen sei weit teurer als eine erneute Hochrüstung der Groß-EDV;
- Software sei zwar preiswert und in vielen Branchenvarianten verfügbar, aber Anpassung, Wartung und spätere Schnittstellen-Programmierung würden Folgekosten verursachen, die den Beteiligten den Kopf kosten könnten;
- Systeme seien zwar leicht zu handhaben, aber die fehlende Dokumentation und beschränkt verfügbares Operating-Personal schaffe neue, gefährliche Abhängigkeiten;
- Anwendungen seien letztlich Spielereien, denn wirkliche Aufgabenstellungen verlangen Datenbanksoftware und Jumbo-Rechner, wie sie nur die zentrale EDV bereithalten könne.
Die Argumente sind alle stichhaltig, nur ist die betriebliche Praxis auf sie nicht eingegangen. Renommierte EDV- und gut geführte Fachabteilungen setzen seit geraumer Zeit gezielt Mikrocomputer-Software für ihre Aufgabenstellungen ein. Wie soll sich ein EDV-Chef in dieser Situation verhalten?
Entwicklung verschlafen
Wenn ein Langfrist-Konzept vorliegt, ist die Anpassung an den technologischen Fortschritt darin auch vorgesehen und die erforderlichen Pilotprojekte zur Beherrschung der neuen Technologien laufen. Die Software-Standards sind schon auf die speziellen Anforderungen der Mikros angepaßt und erweitert worden. Nachwuchskräfte mit Erfahrungen im Mikrocomputereinsatz haben in der Organisation Fuß gefaßt, die passende Hard- und Software ist schon ausgewählt.
Langfrist-Konzepte gibt es zwar, aber zumeist ohne geplante Mikrocomputer-Anwendungen. Der Grund: Big Blue ist in diesem Bereich nicht präsent und hat die Entwicklung verschlafen. Und alle anderen sind halt doch bessere "Magnetkonten-Buchhalter".
Ein Fallbeispiel aus der Praxis illustriert die Problematik:
Im ABC-Konzern hat die zentrale EDV seit einigen Jahren keine neuen Systeme entwickelt, sondern sich mit Wartungs- und Umstellungsarbeiten beschäftigt. "The waves of constant changes" der großen Mutter haben die Budgets verschlungen und den Blick für das Machbare getrübt.
Ein deutscher Hersteller versucht penetrant, mit einem Paket für die Fertigungsplanung und -steuerung die Stagnation zu durchbrechen. Es muß also reagiert werden.
In einer Kurzanalyse werden die Karteikarten und Planungsunterlagen der Arbeitsvorbereitung gesichtet, und es wird entschieden, diese Informationen auf Floppy-Disk zu speichern. Der billigste Hardware-Lieferant macht das Rennen. Fortan wird der XYZ-Exote zur Lösung aller Adhoc-Probleme eingesetzt.
Da in der EDV-Abteilung keiner mit dem XYZ-Exoten umgehen kann, wird ein externer Programmierer mit der Programmierung beauftragt. Das Ergebnis kann vorausgeahnt werden.
Die fünf Kardinalfehler
Bis zu diesem Zeitpunkt hat der ABC-Konzern zwar nur wenige Mark investiert, aber es sind Fehlentscheidungen unterlaufen, die mehrstellige Folgeinvestitionen erfordern werden.
Fehler 1: Personal Computer zementieren die Ablauforganisation der 50er und 60 Jahre und automatisieren eine Arbeitsteilung, die mit der neuen Technologie völlig überholt ist. Zuerst hätte eine neue Ablauforganisation für die 80er Jahre konzipiert werden müssen.
Dabei wäre die klassische Arbeitsvorbereitung in einer modernen Logistik-Organisation aufgegangen, und die Listen und Karteikarten wären durch Systeme der Betriebsdatenerfassung (BDE) in den Werken abgelöst worden. Fertigungsleitstände mit umfangreicher Kommnunikations-Peripherie entstehen.
Datenverarbeitung, Textverarbeitung und Kommunikation werden integriert. Mikrocomputer hätten in dieser Ablauforganisation ihren Platz und ihren Stellenwert zum Andrucken oder Anzeigen von Arbeitsplänen und -papieren vor Ort.
Fehler 2: Die augenblickliche Problemstellung bestimmte die Hardware-Auswahl und nicht etwa ein Anforderungskatalog oder Pflichtenheft, vertikal und horizontal über die verschiedenen Funktionen gezogen. Der XYZ-Mikro verfügte beispielsweise nicht über ein Dateiverwaltungssystem oder Standard-Interfaces zum Mainframe von Big Blue.
Fehler 3: Fachabteilung und EDV-Abteilung verschenkten ihren letzten Trumpf, indem sie die Software-Entwicklung außer Haus gaben. Statt in einem Pilotprojekt schrittweise die neuen Technologien und das damit Machbare zu erkunden, übten sie Abstinenz.
Nach einem dreiviertel Jahr kam dann auch die Rechnung: Der Programmierer warf das Handtuch wegen angeblicher Undurchführbarkeit des Projektes. Die Hardware aber war gekauft. An dieser Stelle hätten die Verantwortlichen eine EDV-Revision durchführen müssen, statt weiterzumachen.
Fehler 4: Fehlschläge oder die Marktankündigung von neuen Technologien (Hardware, Betriebssysteme, Sprachen, Prozeduren) erfordern Plan-Revisionen. Lieber angefangene Fehlentwicklungen abschreiben und einstampfen als mit Nibelungentreue am XYZ-Exoten hängen. Eine Plan-Revision konnte aber nicht stattfinden, da es für
die den Mikrocomputer-Einsatz keinen Plan gab.
Fehler 5: Die Konzepte der 80er Jahre liegen eigentlich auf der Hand und werden von den Kostenrelationen im Bereich Hardware, Software und Personal diktiert. Die Umsetzung dieser Trends erfordert eine Abkehr von den klassischen Konzepten großer, zentraler und integrierter Datenbanksysteme. Damit ist das Todesurteil für so renommierte Softwarepakete wie SAP oder Copics gefällt, es sei denn, diese Pakete werden auf Mikros angepaßt.
Vierte Version akzeptabel
Mini-Copics ist das Gebot der Stunde. Der fünfte Kardinalfehler besteht darin, daß die neue Mikro-Hardware vor der Mikro-Software geplant und installiert wurde, ohne daß dezentrale dynamische Unternehmensmodelle mit klaren Schnittstellen für die autonomen Subsysteme vorliegen. Reaktion statt Aktion als Grundübel.
Insgesamt wurde das Paket für die Fertigungsplanung und -steuerung viermal begonnen, reorganisiert oder umprogrammiert. Die erste Version war ein Fehlschlag, da die Fachkenntnisse beim Programmierer fehlten. Die zweite Version war lauffähig mit rund 39 Stunden aber bei täglicher Fertigungsplanung völlig indiskutabel.
Die dritte Version mit dem Dateiverwaltungssystem und zahlreichen Optimierungs-Tricks, realisiert durch den leitenden Systemanalytiker, brachte eine akzeptable Laufzeit von 3,5 Stunden. Allerdings konnten Fehlerkonstellationen aufgrund der Datenstruktur entstehen, die einen Systemabsturz erzeugten.
Systematisches Testen ist bei Mikro-Software wegen der relativ simplen Betriebssysteme weit wichtiger als bei der Groß-EDV. Die vierte Version brachte eine elegante Menütechnik und wird mit Hilfe eines Basic-Compilers nochmals eine Laufzeitverbesserung mit dem Faktor 1: 10 bringen.
Für die Integration dieses Teilsystems mit der Gesamtorganisation zeichnen sich Folgeinvestitionen wie eine V.24-Schnittstelle mit entsprechender Treiberroutine ab, um über die SNA-Protokolle mit dem Mainframe oder einem 8100-System kommunizieren zu können. Mittelfristig muß auf Mehrplatzsysteme aufgestockt werden, da eine schlagkräftige Logistik-Organisation keine Einzelkämpfer kennt.
Die Textverarbeitung und die Kommunikation mit dem Vertrieb und der Außenlagerorganisation ist nicht integriert und schließlich werden Winchester-Plattenlaufwerke erforderlich werden, wenn erst einmal alle Produkte über das System geplant werden und Historie-Daten anfallen. Auch ist ein Spooling für die Druckausgaben erforderlich und selektive Auswertungen über Listengeneratoren: Alles gewohnter Komfort der Groß-EDV, der nun verlorengegangen ist.
Kaufmännisch sinnvoll wäre es, das gesamte System zugunsten eines neuen Konzeptes nach zwei Jahren abzuschreiben. Allein die schlecht lesbaren Basic-Programme und die knappe Dokumentation aufgrund fehlender Software-Tools für Mikros während der Programmentwicklung stellen ein Risiko dar, das kein externes Softwarehaus tragen würde.
* Götz Mosig, Geschäftsführer der Software Engineering, Dossenheim/Heidelberg