Das allgemeine Problem, ein Produktionsplanungs- und -steuerungssystem den Gegebenheiten des individuellen Produktionsablaufs respektive der entsprechenden Organisation vom Auftragseingang bis zur Auslieferung anzupassen, findet in neuerer Software eine wirtschaftlich vertretbare Lösung Tiber hochstehende, nicht-prozedurale Planungssprachen der vierten Generation. Wie weit sich daraus Änderungen für die Projektrealisierung ergeben, soll hier an einer Projektablaufübersicht dargestellt werden.

Die ersten Projektphasen der Grobanalyse und die der Entscheidung für ein Softwaresystem mit den sich daraus ergebenden Konsequenzen für benötigte Hardware sollen hier nicht beschrieben werden, da diese sich nicht wesentlich von den normalen Abläufen unterscheidet.

Selbstverständlich ergeben sich aus den nachfolgend dargestellten Möglichkeiten, die verschiedene Softwaretools für die einzelnen Projektabschnitte bieten, auch Auswirkungen auf die Auswahlkriterien, die Prozedur selbst bleibt jedoch gleich.

Bei der zur Zeit angebotenen PPS-Software unterscheidet man im wesentlichen zwischen zwei Kategorien:

- Paketsoftware, geschrieben in bekannten Sprachen wie Cobol, PL/1,

Assembler etc., meistens auf bekannten hierarchischen Datenbanken basierend.

- Prozedurfreie Planungssprachen der vierten Generation, in der Regel kombiniert mit integrierten Netz- oder relationalen Datenbanken.

Die Vor- und Nachteile des ersten Typus sind hinlänglich bekannt, wie Schnelligkeit und Zuverlässigkeit unverändert übernehmbarer Programmodule; nachteilig sind jedoch zeit- und damit kostenintensive Neu- oder Umprogrammierung derjenigen Module, die ohne empfindliche Umorganisation des Betriebes sonst nicht ihren vorgedachten Zweck erfüllen würden.

Erfahrungsgemäß werden zwar im Zuge der Einführung eines neuen Systems auch die mit der Zeit eingeschlichenen organisatorischen Ungereimtheiten beseitigt, jedoch ist ein Anpassen der Organisation beziehungsweise des Produktionsablaufes an das "neue" Paket normalerweise wirtschaftlich nicht vertretbar.

Hier setzt nun, bei entsprechender Abweichung vom Standard, das heißt bei erhöhtem Änderungsbedarf, der Vorteil einer frei programmierbaren Hochsprache ein, die es ermöglicht, für das benötigte System die entsprechende Datenbank mit Zugriffspfaden (Relationen) und Schlüsselwerten zu definieren und dazu in einem problemorientierten Sprachteil die notwendigen Transaktionen einschließlich des gewünschten Bildschirmmaskenaufbaus festzulegen. Über eigene DBMS (Datenbank-Management-Systeme) und Interpreter können diese eigentlich nur das gewünschte Ergebnis spezifizierenden Programme dann direkt in lauffähige Codes interpretiert werden.

Das Programm kann direkt ausgeführt und damit kontrolliert werden. Fehlerhafte oder nicht der gewünschten Form entsprechende Programme können so sofort korrigiert werden.

Da der Bildschirmaufbau im Programm integriert ist, läßt sich beispielsweise mit dem Anwender "online" in Minutenschnelle der Bildschirm dessen Vorstellungen anpassen. Auf diese Weise direkt an "seinem" Programm beteiligt, steigert dies die Akzeptanz des Anwenders erheblich.

Traditionelle Softwarewerkzeuge setzen für die Transaktionsprogrammierung eine detaillierte Spezifikation sowohl der Verarbeitung selbst als auch des Bildschirmaufbaus und aller Prüfroutinen voraus, weil alle Komponenten wie Verarbeitung, IO-Steuerung, Maskendefinition und TP-Routinen zusammen kompiliert werden. Änderungen werden damit entsprechend komplex, so daß von vornherein alles bis auf das letzte Bit festgelegt werden muß und erst anschließend die Gesamtprogrammierung erfolgt.

Layout im Direktgang

Da die neuen Instrumente jedoch eine schnelle Anpassung online erlauben, ergibt sich damit die Möglichkeit, nur die Verarbeitung selbst, die benötigten Datenfelder und die anzuzeigenden Informationen zu spezifizieren. Das "Wie" der Verarbeitung und das Layout der Liste oder des Bildschirms kann nach Erstellung eines Programmprototyps dann direkt mit dem Anwender am Screen online festgelegt werden.

Das erlaubt, in der Analyse von der Methodik her, erst alles zu definieren, um Relevanzen innerhalb der Verarbeitung komplett berücksichtigen zu können, und damit zu dem Verfahren zu kommen. Teilsysteme zu analysieren und anschließend direkt zu programmieren, so daß sich die Analysephase und die Realisierung überlappen (siehe Bild).

In Verbindung dieser Case-Methodik und des unten beschriebenen Prototyping läßt sich nicht nur eine erhebliche Einsparung an Projektzeit insgesamt (in Verbindung mit hochstehenden Softwaresystemen) erreichen, sondern auch der produktive Einsatz der ersten Teilsysteme (und damit das Return-of-Investment) kann viel früher erfolgen.

Dictionaries unterstützen

Als zusätzliches Entwicklungswerkzeug werden in der Analyse bereits Data-Dictionaries eingesetzt, seit diese in der Lage sind, nach erfolgter Definition der Dateien, Datenfelder und deren Relationen untereinander, die entsprechende Datenbank zu generieren. Im weiteren Projektfortschritt werden dann auch direkt die Relationen zu den diese Daten benutzenden Transaktionen und deren Beschreibung in den Dictionaries erfaßt.

Entscheidend für die einwandfreie Analyse sind mehrere Faktoren:

- das absolute Commitment der Unternehmensleitung für das Projekt;

- ein mit den notwendigen Kompetenzen ausgestattetes Projektteam, in das nicht die Leute gehören, die man sonst gerade nicht braucht;

- ein Entscheidungsgremium, in dem alle betroffenen Fachbereiche vertreten sind;

- Einbeziehung der Fachabteilung nicht nur in die Ist-Aufnahme, sondern auch in das Soll-Konzept.

Sinnvoll ist zudem der Einsatz einer betriebsneutralen, jedoch sachkundigen Person (i. a. ext. Berater), um betriebsblindes Umsetzen (alt = neu) zu verhindern.

Eine starke Einbindung der Fachabteilung wird in vielen Firmen mit dem Hinweis verhindert: "Deren Horizont geht doch nur bis zur Abteilungstür, und haben wollen die grundsätzlich alles." Diese Abteilungen wissen jedoch genau, welche Informationen notwendig, welche wünschenswert und welche "Schrankware" sind. Gleichzeitig bietet die Mitarbeit der Fachabteilung dem Projektteam auch die Möglichkeit eine unpopuläre Maßnahme zu verkaufen und diese nicht erst bei der Projekteinführung auf den Tisch zu legen.

Die Umsetzung der Ist-Aufnahme in ein Soll-Konzept beinhaltet auch die Berücksichtigung der langfristigen Unternehmensziele, das heißt, auch die Unternehmensleitung muß hierzu gehört werden. Das ist zum Beispiel der Fall, wenn das Unternehmen langfristig von anonymer Lagerfertigung zu auftragsspezifischer Fertigung (oder umgekehrt) übergehen will.

Der notwendige Zeitaufwand für die Analyse wird im allgemeinen viel zu gering eingeschätzt. Versäumnisse wirken sich hier jedoch auf das Gesamtkonzept aus und können dazu führen, daß der nachträgliche Einbau der vorher nicht berücksichtigten Elemente zu erheblichem Zusatzaufwand führt und daß zum Beispiel das gesamte Konzept der Performance revidiert werden muß.

Durch die neuen Sprachen ergibt sich jedoch ein Vorteil für die Analyse: Während es bei herkömmlichen Methoden üblich war, für jede Transaktion den Bildschirmaufbau (oder das List-Bild) bis auf das letzte Bit für die Codierung festzulegen, wird hier nur die notwendige Informationsverarbeitung spezifiziert, wobei die anzuzeigenden Felder lediglich benannt werden.

Die obige Spezifikation wird dann in ein lauffähiges Programm, welches alle Verarbeitungen, jedoch noch nicht alle Plausibilitätsprüfungen enthält, umgesetzt und mit einem Screen-Aufbau versehen, der weitestgehend nach der Standardausgabe der jeweiligen Sprache (oder List- beziehungsweise Screen-Generator) entspricht. Diese Transaktion wird dann dem Anwender vorgestellt, mit ihm durchdiskutiert und in seinem Beisein online auf den Stand gebracht, der seinen Vorstellungen des Bildschirmaufbaus entspricht. Dies wird einerseits durch die neuen Sprachen, andererseits durch die "Rohfassung" der Verarbeitung erleichtert, so daß diese Anpassung in Minutenschnelle erfolgen kann. Da der Anwender direkt an seiner Verarbeitung mitgewirkt hat, ist die Identifikation als "seine" Anwendung und damit die Akzeptanz wesentlich höher.

Updates vorher festgelegt

Diese im Prototyping erstellte Grundverarbeitung wird nun noch um die notwendigen Erweiterungen versehen (wie gleichzeitiges Updating der Journaldatei und entsprechende Plausibilitätsprüfungen), welche sich aus der Beschreibung im Data-Dictionary ergeben und in diesem natürlich auch direkt die entsprechenden Verarbeitungen und neu aufgetretene Felder dokumentiert.

Bei Einsatz komfortabler Dictionaries läßt sich aus diesen, wenn sie schon in der Analyse als Entwicklungsinstrument eingesetzt werden, direkt die Datenbank und auch die, Verarbeitungsdokumentation erzeugen. Ferner sollten hier nicht nur die Programme der zugehörigen Datenbank, sondern auch die jeweils betroffenen Schnittstellen erfaßt und den entsprechenden Datenfeldern zugeordnet werden. Dies vermeidet, daß bei komplexeren Änderungen zwar alle anschließenden Tests innerhalb der Datenbank einwandfreie Ergebnisse liefern, es bei der nächsten Batch-Datenübergabe jedoch zu den abstrusesten Fehlern kommt.

Durch die Sprachen der vierten Generation werden einige nicht zu vernachlässigende zusätzliche Vorteile erzielt:

- Der Pflege-/Wartungsaufwand des Systems wird im gleichen Maße wie die Programmerstellung reduziert, so daß die EDV schneller als bisher auf Veränderungen reagieren kann.

- Ad-hoc-Abfragen können schnell und einfach von ausgebildeten Mitarbeitern durchgeführt werden. Es dauert nur unwesentlich länger, eine Ad-hoc-Liste zu programmieren, als den Programmierantrag (der entfallen kann) zu stellen.

Zu letzterem Punkt hat sich die Schaffung eines "EDV-Kundendienst" - Institution bewährt, das heißt eines Mitarbeiters, der sowohl EDV-Kenntnisse als auch mindestens ein Grundwissen der fachabteilungsspezifischen Anforderungen hat, um daraus in Kommunikation mit dem Anwender Ad-hoc-Abfragen ohne Umwege über Projektanträge zu programmieren und auszufahren.

Weniger Zeitaufwand

Zusammenfassend kann man sagen, daß die neue Softwaretechnologie Möglichkeiten bietet, neue Anwendungen, Änderungen und auch kurzfristige Anforderungen in einem bisher nicht gekannten kurzem Zeitrahmen zu erfüllen. Natürlich setzt dies größere Hardwareressourcen voraus, denn irgendwoher muß die "Power" für diese Leistung ja kommen. Das läßt sich in fast allen Fällen rechtfertigen, da die Hardware gegenüber den Softwarekosten (Manpower) zunehmend den kleineren Kostenanteil darstellt.

Auf eine Gefahr sei jedoch hingewiesen: Da diese Systeme viele Möglichkeiten innerhalb kurzer Zeit bieten, wächst damit auch die Gefahr, daß die organisatorischen Voraussetzungen nicht in der Schnelligkeit geschaffen werden können, in der die EDV bereits die Programme erstellt hat. Wenn dann einfach nach Plan eingeführt wird, ist das Desaster unvermeidlich.

*Georg Weber ist Produktmanager und zuständig für PPS-Systeme der General Electric Informations-Service, Hürth bei Köln.