Nach wie vor geht der Einsatz von Fremdsoftware beim Anwender nicht ohne Schwierigkeiten über die Bühne. Eine sorgfältige Planung hilft jedoch, unliebsamen Überraschungen vorzubeugen. Peter Horn* zeigt im Detail die Einführungsgeschichte in seinem Unternehmen auf und verschweigt auch nicht die Probleme, die bei einem solchen Vorhaben auftreten.

Bereits 1980 erkannte die Fachabteilung, daß zur effizienten Auftragsabwicklung und Disposition ein integriertes PPS-System erworben werden müßte. Wichtige Grunde waren zum einen, die Lagerbestände zu reduzieren, den Entnahmeschutz bei reservierten Teilen zu gewährleisten sowie organisatorische Verbesserungen im Materialwirtschaftsbereich zu erzielen. Weiterhin galt es, eine höhere Transparenz der Fertigungsaufträge zu erzielen und qualitativ bessere Informationen zu erhalten.

Von Anfang an wurde auf ein integriertes System Wert gelegt, das auf einer IBM/4341 unter DOS/VSE läuft.

Die interne Software im Materialwirtschaftsbereich bestand aus einer eigenentwickelten Sachstamm- und Stücklistenverwaltung, einem stark adaptierten Einkaufssystem (IBM-Copics) und einer Batch-Applikation im Bereich Lagerbuchhaltung.

Zu Anfang der 80er Jahre gab es noch nicht so viele Anbieter von PPS-Systemen für DOS/VSE- und CICS/DL1-Umgebungen wie heute. Es wurde eine unternehmensinterne Studie in den USA durchgeführt, die als Grundlage für einen umfassenden Anforderungskatalog diente. An dieser Untersuchung waren sowohl die Fachabteilung als auch die Datenverarbeitung beteiligt. Im Herbst 1981 kristallisierte sich das Copics-System von MTU heraus. Die ersten Gespräche ergaben bereits Übereinstimmung im Blick auf die wesentlichen K.o.-Kriterien des internen Anforderungskatalogs.

Weitere betrachtete Systeme waren "IBM-Copics" und "Mac-Pac" von Arthur Anderson, die jedoch wesentliche Kriterien wie auftragsbezogene Einzel- und Kleinserienfertigung von der Disposition über die Auftragsverfolgung bis zur Auslieferung sowie umfangreiche Zolldatenverwaltung ebenso nicht erfüllten wie stamm- und stücklistenbezogene Alternativteile oder ein hoher Integrationsgrad.

Im Januar 1982 wurde ein Projektteam gebildet, das sich aus einer Person der Fachabteilung (Stabsstelle beim technischen Betriebsleiter) und drei Personen aus der Datenverarbeitung zusammensetzt. Alle Personen standen der Projektarbeit nominell zu 100 Prozent zur Verfügung. Die Mitarbeiter der DV waren auch für Maintenance zuständig. Mit Hilfe des Projektmitglieds aus der Fachabteilung ließ sich die Wartung auf zirka zehn Prozent reduzieren.

Im März 1982 konnte mit dem Test via Standleitung zwischen Litef und MTU begonnen werden. Ein Testkonzept bestimmte ein relevantes Gerät aus der Produktpalette von Litef mit allen nötigen Sachstamm-, Stücklisten- und Auftragsdaten von den entsprechenden Fachabteilungen. Das Ziel war, mehrere Litef-Geschäftsfälle über das System abzuwickeln und dabei die Kriterien des Anforderungskataloges zu erfüllen. Parallel wurden bestehende Programme, die durch MTU-Copics möglicherweise abgelöst werden sollten von den Projektmitgliedern der DV analysiert und manuell auf Formblättern nachdokumentiert.

Die Erarbeitung des Testkonzeptes erfolgte in enger Zusammenarbeit mit MTU-Friedrichshafen. Über die Standleitung wurden die Stamm- und Bewegungsdaten online eingegeben, bei MTU die Batch-Materialplanungsabläufe durchgeführt. Für die eigene Wartung des Copics-Systems wurde das Data Dictionary "lsidor" der MTU ausgewählt, im Juli 1982 dem Projektteam die Freigabe zur Erarbeitung einer Einführungsstrategie gegeben und im Oktober die Standleitung abgemietet.

Die Einführungsstrategie wurde zwischen Juli und Oktober 82 entwickelt und mit MTU auf ihre Durchführbarkeit abgestimmt. Das grundsätzliche Ziel war es, den Nutzen für die Fachabteilung so früh wie möglich zu erbringen und die Projektdauer so kurz wie möglich zu halten. Daraus ergab sich eine Bottom Up-Einführungsstrategie. Zuerst mußten dabei alle Basisdatenverwaltungen wie Sachstamm-, Arbeitsplan-, Arbeitsplatz- und Betriebsmittelverwaltung eingeführt werden. Erst danach wurde mit der Einführung von weiteren Teilsystemen begonnen, die auf diesen Basisdaten aufbauen.

Anfang November 1982 erfolgte der Vertragsabschluß. Bestandteile des Vertrages waren der Einführungsplan, der Zahlungsplan, Testfälle sowie Sinderungsgruppen. Der Zahlungsplan war abhängig vom Einführungsplan. Es wurde vereinbart, daß Teilsysteme nach der produktiven Einführung bezahlt werden.

Die Änderungsgruppen spezifizierten Arten von Änderungen, zum Beispiel Masken der Datenbankänderungen und dafür vorgesehene Preise. Nach dem Vertragsabschluß konnte mit der Anpassungsanalyse begonnen werden.

Ab diesem Zeitpunkt erfolgte zwischen den DV-Projektmitarbeitern eine Aufgabentrennung. Für die einzuführenden Teilsysteme wurden die Verantwortlichen bestimmt. Die Tätigkeiten während der Anpassungsanalyse für jedes Teilsystem waren:

* Litef-intern

- Job-Control, Job-Abläufe im RZ

- Programme/Abteilungen zuordnen

- Dateien dokumentieren

- Online-Funktionen

- DB-Segmente dokumentieren

- Benutzerberechtigungen (Abteilung)

- Felder dokumentieren

* MTU-Copics bezogen

- Datenbankbeschreibung

- Feldverwendungsnachweis

* Zuordnung Litef - "MTU-Copics"

- Felder

- Dateien

- Programme

- Funktionen

- kritische Daten mit Fachabteilung sondieren

* Bridge-Konzept

- Erarbeiten

- Verabschieden

* Organisatorische Abläufe in Fachabteilung festlegen.

Bei allen Teilsystemen wurden jeweils zirka drei Mannmonate benötigt. In dieser Projektphase ist größte Sorgfalt notwendig, so etwa bei der Analyse bestehender Online-Funktionen und damit verbundenen Tätigkeiten oder die für Informationsqualität in der Fachabteilung. Alle Tätigkeiten wurden von den Teilsystem-Verantwortlichen selbständig ausgeführt, um die Litef-Abläufe kennenzulernen und sich mit den internen DB-Strukturen, Funktionen und Masken von "MTU-Copics" vertraut zu machen. Während dieser Phase wurde mit MTU beispielsweise die Zuordnung der Felder abgestimmt und Programm- oder Maskenmodifikationen definiert.

Von Bedeutung ist hier eine "gemeinsame Sprache". Wichtige firmeninterne Begriffe müssen in Form einer schriftlichen Definition der MTU mitgeteilt werden. Zum Beispiel wird der Begriff Struktur-Alternativteil in beiden Unternehmen verwendet, hat jedoch eine völlig unterschiedliche Bedeutung. Zwischen Litef und MTU führte dies zu einem Problem, das zwar gelöst werden konnte, jedoch vermeidbar gewesen wäre.

Die erforderlichen Modifikationen wurden von Litef in schriftlicher Form (Entscheidungstabellen) mit Termin an MTU geschickt. MTU erstellte ein Festpreisangebot; dieses wurde dann von Litef akzeptiert. Diese Projektphase erfordert sehr viel Klein- und Detailarbeit, was der Fachabteilung verständlich gemacht werden muß, da sie keinen unmittelbaren Nutzen daraus ziehen kann, beziehungsweise den Projektfortschritt nicht unbedingt sieht.

Die Anpassungsanalyse dauerte für jedes Teilsystem rund drei Mannmonate. Dabei entstanden für die Teilsysteme zusätzliche Kosten, die sich aus Programm- und Datenbankmodifikationen oder Programmierleistungen wie die externe Erstellung von Bridge-Programmen zusammensetzen.

Zweigleisiges Konzept hat sich bewährt

Die Phase der Realisierung unterteilte sich in die Umsetzung bei MTU. - dort wurden die Programm- und Maskenmodifikationen realisiert - und bei Litef, wo die Bridge-Programme beziehungsweise die Software zum erstmaligen Laden bestimmter Datenbanken erstellt wurden. Dabei galt folgendes Konzept: Bei den Bridge- wie auch den Ladeprogrammen wurden immer Schnittstellen in Form von temporären Zwischendateien vereinbart, die entweder von MTU oder Litef erstellt oder verarbeitet wurden. Dieses Konzept hatte drei Gründe. Zum einen die Personalkapazität bei Litef, die mit den Programmen, die auf eigene Bestände zugriffen, ausgelastet war. Zum anderen erforderten die Programme, die auf MTU-Copics Datenbanken zugreifen, ein sehr gutes DL/ 1-Know-how - dies war zum damaligen Zeitpunkt noch nicht vorhanden. Und drittens lag die Gewähr, daß die MTU-Copics Datenbanken richtig geladen beziehungsweise formatisiert waren, bei MTU.

Dieses Konzept bewährte sich. Es traten, was Datenkonvertierungen angeht, keine Schwierigkeiten beim erstmaligen Laden oder beim Bridge auf. Seit Dezember 1983 besteht eine Wählleitung in das Litef-Testsystem bei MTU für eine effiziente Testabwicklung. Damit wurden sowohl bei MTU als auch bei Litef Aufwände und somit Kosten minimiert.

Mit den Auslieferungen wurde im März 1983 begonnen. Bis November gab es hierbei eine Reihe von Problemen. Zum einen wurden die Programme für Litef in München von IMS-DB/DC auf CICS/DL 1 umgestellt und dort nicht vollständig ausgetestet.

Zudem war in München keine Litef-eigene Source- und Core-Image-Bibliothek vorhanden. Die Folge war, daß teilweise falsche Programmversionen geschickt wurden.

Die Namenskonvention für Datenbankbeschreibung (DBDs) war darüber hinaus noch nicht einheitlich, so daß oft die Standardlabels bei Litef geändert werden mußten.

Vorwegzunehmen ist: Diese Probleme existieren heute nicht mehr. Von MTU wurden technische und organisatorische Maßnahmen ergriffen, die zu einer reibungslosen Auslieferungsabwicklung führten.

Litef-intern bedeutete das Einspielen dieser Lieferung, vor allem anfangs, einen erheblichen Zeitaufwand, da zunächst die Datenbanken definiert und initialisiert werden mußten. Der Datenbankadministrator hatte für diese Tätigkeit über den Zeitraum eines halben Jahres etwa 50 Prozent seiner Kapazität aufzuwenden. Bei Litef wurden hierfür Copies-eigene Programmbibliotheken angelegt. Außerdem war es unbedingt erforderlich, eine eigene "Testmaschine" zu haben, wo alle MTU-Copics-Funktionen zuerst eingespielt und DV-intern getestet wurden.

Fachliche Tests erst nach DV-Internem Check

Im Test bei Litef wurden die Batch- und Online-Programme zuerst auf ihre Lauffähigkeit hin DV-intern geprüft. Verlief dieser Test positiv, so wurde für die einzelnen Teilsysteme immer eine Person aus der betroffenen Fachabteilung hinzugezogen, mit der dann die anwenderbezogenen fachlichen Tests durchgeführt wurden. Dieser Mitarbeiter war später innerhalb der Fachabteilung der Ansprechpartner, der auftretende Probleme oder Sachfragen zur DV kanalisierte.

Traten während der einzelnen Testphasen Fehler auf, so wurden diese über eine Woche gesammelt, dann telefonisch mit MTU besprochen, dort innerhalb von zwei bis drei Tagen kostenfrei behoben und eine erneute Anlieferung durchgeführt. Als alles in Ordnung war, wurde von dieser Arbeitsgruppe die Freigabe zur produktiven Einführung gegeben. Erst danach begann die Schulung der Fachabteilung.

Schulungen erfolgten für alle Teilsysteme unmittelbar vor der Einführung. Der Zeitraum zwischen Schulung und Einführung sollte nicht größer als eine Woche sein.

Geschult wurde im Testsystem mit "Original-Testdaten", für die Schulung und auch zum späteren Nachschlagen wurden jeweils Anwendungshandbücher von den DV-Teilsystemverantwortlichen - erstellt. Diese Handbücher sollten nur die notwendigsten Informationen erhalten. Damit wurde der Zeitaufwand für ihre Erstellung klein gehalten.

An der Schulung nahm immer die Person aus der Fachabteilung teil, die in der vorhergehenden Testphase mitwirkte.

Rückgriffe auf alte Systeme war möglich

Die Teile der Einführung wurden vorher schriftlich festgelegt und in eine zeitliche Reihenfolge gebracht. Die wichtigsten Aktivitäten waren das Überspielen der Tests in die Produktions-Programmbibliotheken sowie das Definieren und Initialisieren der Datenbanken. Außerdem mußten die entsprechenden Bildschirmberechtigungen in die entsprechende Tabellen-DB eingetragen werden. Dann konnte das erstmalige Laden beginnen, sofern eigene Litef-Datenbestände vorhanden waren. Diese Aktivitäten beschränkten sich auf die Wochenenden.

Bei allen Teilsystemen wurde kein Parallellauf durchgeführt, es bestand jedoch immer die Möglichkeit, wieder mit dem alten Litef-System zu arbeiten. Diese Möglichkeit mußte allerdings nie in Anspruch genommen wurden. Es wurde deswegen kein Parallellauf durchgeführt, da der damit verbundene Abstimm- und Kontrollaufwand zu groß gewesen wäre und die Fachabteilung deswegen ihr Tagesgeschäft nicht mehr hätte vollständig abwickeln können.

Einer solchen Vorgehensweise lag ein umfangreicher Test zugrunde, in den die Fachabteilung miteinbezogen wurde. Während des Tests erkannte sie, daß das neue System fehlerfrei funktioniert.

Der Einführung folgte eine zweiwöchige direkte Unterstützung von dem DV-Teilsystemverantwortlichen in der Fachabteilung. Außerdem wurden teilweise Auswertungsprogramme geschrieben. Dies erhöhte das DL1-Know-how beziehungsweise das Kennenlernen der MTU-Copics-Datenbanken.

Eine Verfeinerung der Anwendungs- und Nutzungsmöglichkeiten innerhalb der Fachabteilung wird von DV-Seite im Augenblick nicht forciert, jeder Projektmitarbeiter ist mit der Einführung von weiteren Teilsystemen beschäftigt.

Erst wenn das gesamte MTU-Copics-System komplett eingeführt ist, werden die einzelnen Teilsysteme unter dem Aspekt der Optimierung und Verbesserung nochmals bearbeitet.

* Peter Horn, beschäftigt bei Litef in der Abteilung Informationsverarbeitung als Projekt- und Gruppenleiter.

Das Unternehmen

Die Litton Technische Werke (Litef) der Hellige GmbH wurden 1961 in Freiburg gegründet. Damals stand die Fertigung von feinmechanischen Instrumenten für das von Litton gefertigte Trägheitsnavigationssystem für den Starfighter im Mittelpunkt der Geschäftsaktivitäten. Heute entwickelt und produziert Litef mit 900 Mitarbeitern im Auftrag der Bundeswehr und seit einiger Zeit für die zivile Luftfahrt. Litef's Aktivitäten konzentrieren sich auf Produkte für die Luft-, Land- und Seefahrt, darunter Marine-Navigationssysteme, Kursund Lagereferenz-Plattformen, digitale Ein- und Ausgabegeräte (LED-Anzeigenelemente), Prüfgeräte und Sonderentwicklungen von elektronischen Geräten und Systemen sind Beispiele der Produktpalette.

Die Datenverarbeitung bei Litef ist mit zwei IBM-Systemen 4341-M02 ausgestattet. Ein System 4341 wird unter VM/SP und DOS/VSE für Batch-Läufe, das andere als TP-Rechner eingesetzt. Zur Zeit wird mit 125 Terminals an diesem Rechner gearbeitet: an der anderen Anlage sind weitere 15 Terminals angeschlossen.

Entwicklungsgang im Überblick

* Nach dreijähriger Projektarbeit und unmittelbar nach der Einführung der Materialplanung Stufe 1 werden die eingeführten Teilsysteme bei Litef durchweg positiv beurteilt.

* Nach Überwindung der anfänglichen Schwierigkeiten bei der Auslieferung konnten die einzelnen Teilsysteme kontinuierlich bearbeitet und eingeführt werden. Dabei hat sich die Einführungsstrategie wie auch das jeweilige Bridge-Konzept bewährt.

* Der große Nutzen aus der Materialplanung Stufe 1 war möglich weil vorher die entsprechende Datenbasis (Sachstamm, Stückliste, Arbeitsplan Hausaufträge Lagerbestandsführung) geschaffen wurde.

* Um einen vollständigen Integrationseffekt zu erzielen wurde nachträglich das MTU-Copics-Einkaufssystem in den Einführungsplan aufgenommen.

* Auftretende Sachfragen oder nachträgliche Programmänderungen wurden mit kurzen Reaktionszeiten vorgenommen.

* Um eine effizientere Auslieferung und kürzere Reaktionszeiten zu erhalten sollte die Auslieferung über eine Wählleitung (File-Transfer) erfolgen.

* Die Zusammenarbeit mit den Fachabteilungen wurde verbessert: ein Abteilungsleiter ist Ansprechpartner für das Projektteam. Diese Person koordiniert zwischen den Fachabteilungen und hat auch Weisungsbefugnis.

* Die Projektsteuerung und -kontrolle erfolgt mit Hilfe eines DV-gestützten Netzplan-Rechensystems. Es wurden alle Aktivitäten für jeden Projektmitarbeiter mit Termin und Abhängigkeit eingegeben. Engpässe und mögliche Terminverschiebungen konnten so erkannt und entsprechende Maßnahmen ergriffen werden.

* Alle Batch-Läufe im Rahmen von Copics (Sachstamm-Bridge als Mapla) benötigen einschließlich Sicherungen zirka fünf Stunden. Für den Mapla-Lauf wird eine Partition mit zirka 3000k benötigt. Im TP-Bereich werden im Augenblick täglich zirka 7000 Transaktionen von 50 Bildschirmen ausgeführt.