Traditionelle Methoden der Software-Pflege und Informationszersplitterung ließ die Corning Keramik GmbH, Kaiserslautern, zur Produktivitätserhöhung auf die Suche nach einer Programmierumgebung (4GL) gehen. Den Auswahlprozeß sowie die Erfahrungen bei der Erstellung von zwei Applikationen beschreibt Walter Haberland, FUNKTION.
Die Softwarelandschaft sah vor dem Einsatz des ausgewählten 4GL-Produkts konventionell und erschreckend normal aus: Als Layered Products waren CDD, Datatrieve, FMS und als Programmiersprachen Fortran Lind Cobol installiert.
Die Applikationen waren entweder auf dem Markt gekaufte Pakete oder von der Muttergesellschaft standardmäßig eingesetzte Applikationen.
So wurde die Prozeß-DV mit drei völlig unterschiedlichen Paketen mehr oder weniger gut abgedeckt. Es gab drei Laborsysteme unterschiedlicher Machart. Für die Prozeßanalyse (in der Regel auf dem IBM-PC) gab es keine Möglichkeiten zur Datenextraktion aus der VAX.
Ein Corning-Paket deckte die Werksinstandhaltung leidlich aber in der Fertigung (Lagerhaltung, Planung, Produktionsberichte) wollte man sich nur auf den IBM-PC verlassen. Der Einkauf arbeitete mit einem Spezialsystem in dbase III +. Die Finanzbuchhaltung und Kostenrechnung liefen zwar mit VAX-Profi, aber das Reporting war ohne Einsatz von IBM-PC undenkbar.
Im Fazit läßt sich diese Situation als Hawaii-EDV bezeichnen: Jeder saß auf seiner kleinen, durchaus nicht immer unattraktiven Insel. Die Interfaces zwischen den verschiedenen Systemen bestanden in der Regel aus Papier.
Angesichts dieser Situation stellte man sich die Frage, wo man anfangen soll, das EDV-Gebäude zu sanieren. Wir entschieden uns, an der Basis, nämlich bei der Prozeß-DV zu beginnen. Nachdem hier die Produktauswahl abgeschlossen war, wurde in den mehr datenorientierten Anwendungsgebieten Bilanz gezogen. Unser Ziel war es, die Produktivität der EDV-Mannschaft so stark anzuheben, daß man wieder allen Ernstes daran denken konnte, Applikationen zu entwickeln. Weiterhin sollte ein höherer Grad der Integration zwischen den Applikationen erreicht werden sowie eine größere Akzeptanz der Systeme bei den Anwendern. Wir haben etwa Anfang 1987 damit begonnen, uns nach einem Produktivitäts-Tool umzusehen.
Die Bewertung der verschiedenen auf dem Markt befindlichen Produkte lief nach einem relativ festen Schema ab. Zunächst haben wir uns Informationen über die Systeme aus Büchern, Publikationen oder Workshops geholt. Danach haben wir uns die interessanten Produkte vom Hersteller präsentieren lassen.
Ein weiterer äußerst wichtiger Schritt war das Prototyping: Wir haben dem Hersteller die Aufgabe gestellt, daß wir unter Anleitung eines erfahrenen Mitarbeiters selbst ein kleines Lagersystem mit Bestandsführung, Zu- und Abgängen und einer Bestandsliste als Dialogsystem innerhalb von vier Stunden erstellen. Hierbei konnten die ersten Hands-on-Erfahrungen gesammelt werden.
Parallel dazu wurde ein Referenzkunde besucht, der uns dann Fragen aus der Praxis beantworten konnte, und bei dem wir in der Regel die codierten Programme begutachtet haben. Die Erkenntnisse dieser Aktivitäten haben wir in Form einer punktemäßigen Bewertung zusammengefaßt. Auf diese Weise wurde der Entscheidungsweg für Dritte etwas transparenter. Danach war die Entscheidung zu 90 Prozent gefällt.
Tests in der Praxis geben den Ausschlag
Die Testinstallation von 30 Tagen diente dann dazu, diese Entscheidung zu untermauern und zwar durch eigene Praxis. Während dieser Phase wurde nicht ein bißchen herumgespielt, sondern es wurden echte Applikationen entwickelt, die nicht zu schwierig aber trotzdem wichtig waren: ein System, um Qualitätsdokumente für Kunden zu erstellen und ein Einkaufssystem.
Als Vorbereitung für die Testinstallation haben wir die normale Schulung (eine Woche) durchlaufen. Hier haben wir eine Vorinvestition geleistet, die sich sehr stark bezahlt gemacht hat.
Ein sehr wichtiger Umstand sollte noch erwähnt werden: Bei dem Auswahlprozeß war der EDV-Leiter nicht die Hauptperson, sondern die Leute, die am meisten mit dem System arbeiten würden. Dadurch gab es auch bei eingefleischten Cobol-Freaks keine Akzeptanzprobleme.
Bei der Bewertung der 4GL-Produkte wurden folgende Kriterien herangezogen:
- Welche Qualität haben die Generatoren für Bildschirmmasken, Reports und Grafik?
- Welche Leistungsfähigkeit besitzt die Hochsprache?
- Welchen Komfort bietet das Data Dictionary?
- Welche Hilfen gibt es zur Dokumentation der erstellten
Anwendungssysteme?
Zusätzlich sollte man sich um das Umfeld bei der Einführung einer 4GL. kümmern:
- Wie umfangreich ist das Schulungsangebot?
- Stimmt das Preis/Leistungs-Verhältnis?
- Wie ist die Performance bei der Entwicklung und zur Laufzeit?
- Ist das System benutzerfreundlich?
Aufgrund der besonderen Situation in unserem Werk haben wir zusätzliche Anforderungen aufgestellt:
- Wie eingangs ausgeführt, sind alle vorhandenen VAX-Applikationen auf Basis des RMS-File-Systems erstellt. Neue Applikationen müssen hierauf lesend und auch schreibend zugreifen können.
- Da wir ein VAX-Cluster betreiben, muß das Produkt clusterfähig sein.
- Die vorhandenen Personal Computer müssen datenmäßig in die VAX-Welt integriert werden können; das ist mehr als Terminalemulation und File-Transfer.
Zum 4GL-Tool gehört oft ein relationales DBMS
Der ursprüngliche Ansatz zur Produktauswahl bestand darin, ein Werkzeug für die Produktivitätserhöhung zu finden und einzuführen. Erst im Laufe der Auswahlphase wurde uns klar, daß wir uns eigentlich auch mit relationalen Datenbanken beschäftigen müssen, da viele Tools auf einer Datenbank basieren.
Nun benötigt man zur Beurteilung der Datenbankmaschine spezielle Kenntnisse und Erfahrungen, die in unserem Werk nicht zur Verfügung standen. Außerdem wird der Aufwand für die Untersuchung dadurch noch größer. Wir haben daher diesen Aspekt vernachlässigt und uns darauf verlassen, daß im Falle von Ingres unsere amerikanischen Kollegen dieses System positiv gegenüber Oracle beurteilt hatten.
Schwachpunkte der beurteilten Systeme lagen im Bereich der Grafik, da viele Anwender Business-Grafik auf dem IBM-PC erstellen. Das Schulungsangebot war damals nicht als hervorragend einzustufen; hier hat sich einiges zum Besseren gewendet.
Es macht Sinn, während der Auswahlphase auch mal mit dem Trainer zu sprechen, um sich einen persönlichen Eindruck zu verschaffen.
Das Preis/Leistungs-Verhältnis konnte uns ebenfalls nicht begeistern. Unsere vorhandene Konfiguration (VAX 11 /750) ist im Softwarebereich preislich zu hoch angesiedelt. Für die Unterstützung bei der Dokumentation der Systeme haben wir ebenfalls nichts Brauchbares gefunden. Wir haben aufgrund der Bewertung im Juli 1987 die Entscheidung gefällt, Ingres testweise zu installieren.
Das Einkaufssystem deckt im Schritt 1 alle Ersatzteilbestellungen ab. Es ist mit dem vorhandenen System für die Werksinstandhaltung (MMS) integriert. Insbesondere wird die Bestandsführung weiterhin im MMS abgewickelt.
Der Erstellungsaufwand für dieses System betrug sechs Zeitwochen für einen Mann. Die Ingres-Installation wurde im Oktober 1987 vorgenommen, im Dezember lief der Ersatzteil-Einkauf über dieses System.
In der zweiten Phase sind noch die Einzelbestellungen dazugekommen, wobei dieses System Stammdatenprüfungen aus der vorhandenen Kostenrechnung vornimmt.
Der Datenumfang dieser Applikation ist sehr moderat: Es werden etwa 50 Bestellungen/Woche abgewickelt.
Die Idee zu der Anwendung Prozeß- und Qualitätsdaten entstand aus der Notwendigkeit, den Produktionsprozeß im Werk selbst näher zu untersuchen. Bei der Fertigung der Keramikträger werden Naturstoffe verwendet, die nicht in gleichbleibender Qualität angeliefert werden und daher Prozeßstörungen verursachen. Die Werkzeuge, um solche Untersuchungen zu machen, sind SAS auf der VAX und LOTUS-1.2.3 auf IBM-PC (ins Wesentlichen wegen der Grafik). Die Daten mußten natürlich bei dem Stand der Datenzersplitterung in unserem Werk mühsam zusammengesucht und von Hand eingegeben werden.
Das Ziel anwenderseitig bestand darin, Daten verschiedenster Quellen leicht zusammenführen zu können. Für die Aufgabe der Datenhaltung und -kombination (nicht der Analyse) haben wir dann Ingres vorgeschlagen, wobei wir EDV-seitig das Ziel verfolgt haben, simple Datenstrukturen anzubieten, die jeder Prozeß-Ingenieur verstehen kann. Wir wollten insbesondere die Daten leicht zum IBM-PC bringen. Dabei wollten wir am liebsten nichts programmieren müssen, sondern dem Endanwender für die Daten-Extraktion ausschließlich Ingres-Tools an die Hand geben.
Zu Beginn des Projekts wurde zusammen mit dem Werksstatistiker eine Datenanalyse durchgeführt, die zwar nicht vollständig war, aber das Ziel aufgezeigt hat, das wir anpeilen. Hier liegt die eigentliche Arbeit bei diesem System: Die Datenarchitektur so aufzubauen, daß man allein mit den Ingres-Join-Mechanismen zu sinnvollen Ergebnissen kommt. Die Daten werden zum Teil periodisch von den Prozeßsystemen übernommen, zum Teil per Bildschirm eingegeben. Die Datenextraktion erfolgt per PC/Link zum IBM-PC oder über ein selbst erstelltes simples SAS-Interface.
Es zeigte sich, daß alte Datenbestände leicht zu übernehmen sind (per Ingres copy). PC/Link wird als Werkzeug sofort angenommen und von einigen Leuten lieber benutzt, als ein Routine-Report.
Die Übernahme von Altdaten ist eine wichtige Service-Leistung, weil in den Altdaten ja sehr viel Know-how und Arbeit steckt. Vom Datenvolumen her ist diese Applikation unsere größte. Wir haben alle Tabellen auf btree unique strukturiert. Die Performance ist bei dieser Speicherform außerordentlich gut.
Die erhoffte Produktivitätssteigerung durch den Einsatz von Ingres ist voll durchgeschlagen. Wir haben den Eindruck, jetzt endlich schnell Lösungen für betriebliche Probleme anbieten zu können.
Dabei hat sich die Integration zu den alten Systemen als problemlos erwiesen, die Integration zum IBM-PC als hervorragend. Eine hohe Datensicherheit haben wir aufgrund des Transaktionskonzepts erreicht. Auch der Datenkbankmaschine (dem sogenannten Backend) können wir eine sehr gute Performance bescheinigen.
Probleme sehen wir in der CPU-Intensität der Frontend-Prozesse, wobei die Programmentwicklung unter OSL außerordentlich viel CPU verbraucht (VAX-C ist da besser). Etwas lahm ist derzeit noch das Anstarten von Applikationen. Hier erhoffen wir uns wesentliche Verbesserungen durch die Version 6.0 von Ingres.
Zukünftige Entwicklungen liegen auf dem Gebiet der verteilten Datenbanken, im Bereich Lagerwirtschaft, Rechnungsprüfung, Business-Reporting, Produktionsplanung und -steuerung.
Als weiteren Schritt werden wir in nächster Zeit Daten von Ingres-Applikationen realtime an die Prozeßsysteme übergeben.