Bei der Realisierung integrierter Großprojekte ist die Produktionsplanung und -steuerung oft ein zentraler Faktor. Ein nicht zu unterschätzendes Hilfsmittel sind in diesem Bereich moderne Methoden der Softwaretechnik. Worauf es beim Einsatz der entsprechenden Tools und Verfahren ankommt, beschreibt Wolfgang Theihsen*.
Bei der zur Zeit im Markt verfügbaren PPS-Software wird im wesentlichen zwischen zwei Kategorien unterschieden: Zum einen die Paketsoftware, geschrieben in bekannten Sprachen wie Cobol, PL/1, Assembler, meistens auf bekannten hierarchischen Datenbanken basierend; und zum anderen prozedurfreie Sprachen der vierten Generation, normalerweise kombiniert mit integrierten Netz- oder relationalen Datenbanken.
Die Vor- und Nachteile des ersten Typus, wie Schnelligkeit und Zuverlässigkeit unverändert übernehmbarer Programm-Module, sind hinlänglich bekannt; nachteilig fällt jedoch die zeit- und damit kostenintensive Neu- oder Umprogrammierung derjenigen Module ins Gewicht, die ohne empfindliche Umorganisation des Betriebes ihren vorgedachten Zweck nicht erfüllen würden.
Organisation nicht der neuen Software anpassen
Erfahrungsgemäß werden zwar im Zuge der Einführung eines neuen Systems auch die sich mit der Zeit einschleichenden organisatorischen Ungereimtheiten beseitigt; jedoch ist ein Anpassen der Organisation und 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. Sie ermöglicht es, 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 Bildschirm-Maskenaufbaus festzulegen. Über eigene Datenbank-Management-Systeme und Interpreter können diese (eigentlich nur das gewünschte Ergebnis spezifizierenden) Programme dann direkt in lauffähige Codes übertragen werden.
Das Programm läßt sich direkt ausführen und kontrollieren. Fehlerhafte oder nicht der gewünschten Form entsprechende Programme können sofort korrigiert werden.
Traditionelle Softwarewerkzeuge setzen für die Transaktionsprogrammierung eine detaillierte Spezifikation sowohl der Verarbeitung selbst als auch des Bildschirmaufbaus und aller Prüfroutinen voraus; denn alle Komponenten, wie Verarbeitung, I/O-Steuerung, Maskendefinition und TP-Routinen, werden zusammen kompiliert. Änderungen fallen dementsprechend komplex aus, so daß von vornherein alles bis auf das letzte Bit festgelegt werden muß und erst anschließend die Gesamtprogrammierung erfolgt.
Da die neuen Instrumente jedoch eine schnelle Anpassung im Online-Modus 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 können nach Erstellung eines Programm-Prototyps dann direkt mit dem Anwender am Screen online festgelegt werden.
Von der Methodik her erlaubt dies, erst alles zu definieren, um Relevanzen innerhalb der Verarbeitung komplett berücksichtigen zu können. Damit wird es möglich, zu dem Verfahren zu kommen, Teilsysteme zu analysieren und anschließend direkt zu programmieren, so daß sich die Analysephase und die Realisierung überlappen.
In Verbindung dieser CASE-Methodik und des Prototyping läßt sich nicht nur eine erhebliche Einsparung an Projektzeit insgesamt erreichen; auch der produktive Einsatz der ersten Teilsysteme und damit das Return-of-Investment kann viel früher erfolgen.
Data-Dictionary dient als Entwicklungstool
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 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, um betriebsblindes Umsetzen nach dem Motto "Aus alt wird neu" zu verhindern. Eine starke Einbindung der Fachabteilung wird in vielen Firmen mit dem Hinweis unterbunden: "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 bedeutet 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 Lagertfertigung zu auftragsspezifischer Fertigung schwerpunktmäßig ü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.
Prototyping bleibt ein unentbehrliches Hilfsmittel
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.
Einen nächsten Schritt stellt das Prototyping dar. Die Spezifikation ist in ein lauffähiges Programm umzusetzen, welches alle Verarbeitungen, jedoch noch nicht alle Plausibilitätsprüfungen enthält. Hinzu kommt die Forderung nach einen Screen-Aufbau, der weitestgehend noch der Standardausgabe der jeweilig verwendeten Sprache 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 Minuten erfolgen kann. Da der Anwender direkt an der Verarbeitung mitgewirkt hat, ist die Identifikation mit der Applikation als "seine" Anwendung und damit die Akzeptanz wesentlich höher.
Die im Prototyping erstellte Grundverarbeitung läßt sich nun noch mit den notwendigen Erweiterungen versehen, beispielsweise gleichzeitiges Updating der Journaldatei und entsprechende Plausibilitätsprüfungen. Diese Zusatzforderungen ergeben sich aus der Beschreibung im Data-Dictionary. Hier sind natürlich auch direkt die entsprechenden Verarbeitungen und neu aufgetretene Felder dokumentiert.
Bei Einsatz komfortabler Dictionaries läßt sich, 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 hilft zu vermeiden, daß bei komplexeren Änderungen zwar alle anschließenden Tests innerhalb der Datenbank einwandfreie Ergebnisse liefern, es bei der nächsten Datenübergabe jedoch zu Fehlern kommt.
DV-Koordinator hält den Draht zum Anwender
Durch die Sprachen der vierten Generation werden einige entscheidende Zusatzvorteile erzielt:
- Der Pflege-/Wartungsaufwand des Systems wird im gleichen Maße wie die Programmerstellung reduziert, so daß die DV schneller als bisher auf Veränderungen reagieren kann.
- Ad-hoc-Abfragen lassen sich schnell und einfach von ausgebildeten Mitarbeitern durchführen. Es dauert nur unwesentlich länger, eine Ad-hoc-Liste zu programmieren, als den Programmantrag zu stellen.
In diesem Zusammenhang hat es sich bewährt, die Position eines "DV-Koordinators" einzurichten. Dabei muß es sich um einen Mitarbeiter handeln, der sowohl über DV-Kenntnisse als auch mindestens über ein Grundwissen der fachabteilungsspezifischen Anforderungen verfügt. Seine Aufgabe ist es, in Kommunikation mit dem Anwender Ad-hoc-Abfragen sofort und ohne Umweg über Projektanträge zu programmieren und auszuführen.
Der nächste logische Schritt ist die Realisierung von Softwarepaketen, die in einer Sprache der vierten Generation geschrieben sind. Diese Systeme, zusammen mit einem fortschrittlichen SW-Tool, vereinigen alle Vorteile einer Paketlösung mit den beschriebenen Eigenschaften eines 4GL-Produkts. Für die Projektrealisierung wirkt sich eine solche Vorgehensweise positiv aus.
PPS-Anwendungen sind der Kern bei Großprojekten
Die neue Softwaretechnologie bietet also Möglichkeiten, neue Anwendungen, Änderungen und auch kurzfristige Anforderungen in einem bisher nicht gekannten kurzen Zeitrahmen zu erfüllen. Dieser Lösungsansatz beeinflußt weiterhin die Realisierung von integrierten Großprojekten. PPS-Anwendungen dieser Art können als Nukleus dieser Großprojekte angesehen werden. Insbesondere unterliegen sie einer ständigen Änderung und Anpassung, da auch Schnittstellen erst in einer späteren Projektrealisierungsstufe definiert werden können.
*Wolfgang Theihsen ist Gesellschafter und Vertriebsleiter der Teamco Software Innovation GmbH, Hürth-Efferen.