Für viele Unternehmen hat die Integration ihrer Datenverarbeitung mit Systemen zur Produktionssteuerung (PPS) begonnen. Doch inzwischen hinkt dieser zentrale CIM-Baustein häufig den Möglichkeiten der anderen Module hinterher. Eine Studie der Technischen Hochschule Zürich zeigt die Probleme beim Umstieg auf ein neues PPS-System. Francois Bolay und Norbert Buchmeier fassen die Ergebnisse zusammen.
Die ERFA-Gruppe "Informatik in der Industrie" des Betriebswissenschaftlichen Institutes der Eidgenössischen Technischen Hochschule Zürich hat im Herbst 1987 auf Anregung ihrer Programmkommission eine Umfrage bei Mitgliedsfirmen zum Thema "Ablösung bestehender PPS-Systeme" durchgeführt. Das überraschend große Interesse an diesem Thema führte zur Bildung von zwei Arbeitsgruppen.
Die erste Arbeitsgruppe bearbeitete die Problematik einer Ablösung eines eingeführten PPS-Systems durch eine Standardsoftware.
Die zweite Arbeitsgruppe formulierte aufgrund heutiger Computertechniken und Produktionsphilosophien Anforderungen an ein zukünftiges PPS-System. Die Ergebnisse dieser Arbeitsgruppen liegen nun als Erfahrungsbericht vor. BeteiIigt waren acht Mittel- bis Großbetriebe der deutschschweizerischen Industrieregion.
Neue PPS-Systeme für neue DV-Anforderungen
Wann und weshalb ist überhaupt ein Systemwechsel notwendig? Geht man davon aus, daß die meisten Industriebetriebe bereits über realisierte EDV-Systeme in der PPS verfügen und diese in der Regel seit einigen Jahren produktiv im Einsatz haben, ist angesichts der rasanten Entwicklung der Computertechnologie und neuer Wege in der Produktionsphilosophie meistens der Zustand nicht mehr ausbaufähiger und integrierbarer Systeme erreicht. Eine Überalterung der Systeme gemessen an den heutigen Anforderungen ist die Folge. Aber auch andere Umwelteinflüsse können einen Entscheid für den Ablösungsschritt herbeiführen:
- Änderungen in der Produktionsphilosophie (zum Beispiel Just-in-time-Fertigung),
- organisatorische Umstrukturierung des Unternehmens (Zusammenschluß, Entflechtung),
- Sortimentsänderung und damit erweiterte oder geänderte Anforderungen an das PPS-System,
- der Anwender kennt die Möglichkeiten des Systems nicht mehr (fehlende Dokumentation, Know-how-Verlust durch Personalfluktuation),
- das System erfüllt die wesentlichen Anforderungen eines modernen PPS-Systems nicht mehr (Batch-System, lange Verarbeitungszeiten),
- einzelne Funktionen oder Module können nicht oder nur mit erheblichem Aufwand integriert werden,
- Hardware- oder Softwarewechsel aufgrund übergeordneter Entscheide (Standardisierungsbestrebungen in den HW/ SW-Plattformen).
Die Benutzeranforderungen lassen sich in drei Gruppen einteilen: organisatorische, funktionelle und finanzielle Anforderungen. Zudem ist zu berücksichtigen, daß verschiedene Branchen und unterschiedliche Produktionstypen, individuell ausgeprägte PPS-Funktionen benötigen. Es können jedoch an ein modernes, zukünftiges PPS-System folgende Schwerpunktanforderungen gestellt werden:
- Organisatorische Anforderungen: offene Systeme gegenüber Veränderungen in der Aufbau- und Ablauforganisation. Diese Veränderungen sind meist durch neue Produktionsphilosophien (Trends) oder Unternehmungsentscheide bedingt. Die Möglichkeit, durch das Unternehmen bestimmte Organisationsänderungen richtig abbilden zu können, wird oft auch als Flexibilität eines Systems verstanden .
- Funktionale Anforderungen aus Anwendersicht: Der Funktionsumfang ist hinsichtlich Planungshorizont und zu planenden Ressourcen wesentlich zu erweitern. Die Planungs-, Steuerungs- und Kontrollfunktionen müssen durchgängig und in die logistische Kette integrierbar sein.
Neue Funktionen, wie Aufarbeitung von Erfahrungswerten (Expertensysteme), Simulationsmöglichkeiten und Simultanplanung verschiedener Ressourcen müssen ermöglicht werden. Auch sollen bereits bekannte Produktionsphilosophien wie etwa "just in time" unterstützt werden.
- Funktionale Anforderungen aus technischer Sicht: Das System soll in kleine, selbständig funktionsfähige Module gegliedert sein. Der Einsatz einzelner Transaktionen mit freistehenden, branchenspezifischen
Funktionen soll gefördert werden. Der Benutzer des PPS-Systems soll durch den Einsatz einer Datenbank, mit Data Dictionary, Listengenerator, Maskengenerator und speziellen Abfragesprachen unterstützt werden können. Offenen Datenzugriff bei Schnittstellen zwischen PPS-Modulen von verschiedenen
Herstellern sowie funktionsfremden Systemen wie CAX, IC/IDV, PC-Applikationen ist höchste Aufmerksamkeit zu schenken.
- Finanzielle Anforderungen: Die Ablösung eines PPS-Systems ist oft ein übergeordneter Entscheid und kann meist nur teil weise im PPS-Bereich finanziell ausgewiesen werden. Auch ist der nicht quantifizierbare Nutzen bedeutend, womit herkömmliche Wirtschaftlichkeitsrechnungen wie Kosten/Nutzen-Übersicht versagen oder nur ungenügend den Sachverhalt darstellen.
Es empfïehlt sich deshalb, auf Geschäftsleitungsebene einen Kostenrahmen für die Einführung des neuen PPS-Systems vorzugeben .
Einhellig wurde in den Arbeitsgruppen vertreten, daß für Industriebetriebe heute wirtschaftlich nicht mehr tragbar ist. Software selber zu entwikkeln, wo für entsprechende Funktionen Standardsoftware
angeboten wird. Durch die permanente Weiterentwicklung der Standardsoftware durch die Lieferanten und die internationalen Standardisierungsbestrebungen wird Standardsoftware mehr und mehr die Benutzeranforderungen decken (vergleiche Abbildung 1). Es sind dabei jedoch folgende Punkte zu beachten:
- Durch den Einsatz von Standardsoftware wird die Veränderungsbereitschaft des Benutzers stark gefordert. Die Bereitschaft sich auszubilden, neue Aufbau- und Ablauforganisationen zu akzeptieren, wird durch die Übernahme der Projektverantwortung durch den Benutzer wesentlich erleichtert.
Dies muß jedoch schon bei Beginn der Vorstudie geschehen, damit auch bei der Erstellung der Anforderungen und der Auswahl des Systems der Benutzer genügend mit einbezogen wird. Von der EDV evaluierte Systeme haben wenig Chancen, vom Benutzer angenommen zu werden.
Weniger die Wahl des Phasenkonzepts, als vielmehr die Bestimmung der Projektmitglieder beeinflussen Projektfortschritt und das Resultat der Ergebnisse. Projektmitarbeiter müssen zu 100 Prozent freigestellt werden. Es sind vor allem Anwender zu bestimmen, die Aufbau- und Ablauforganisation des Unternehmens sehr gut kennen. EDV-seitig sind erfahrene Analytiker und Datenbankadministratoren gefragt (vergleiche Abbildung 2).
Für die Ausbildung des Projektteams und den Funktionstest der Standardsoftware ist ein Pilotsystem zu installieren. Dieses Pilotsystem wird als "Spielwiese" mit Unternehmensdaten, als Stand-alone-Applikation ohne Integration (Schnittstellen) zu laufenden Systemen und nur mit Standardfunktionsumfang betrieben.
Auf diese Weise kann das Projektteam auch wichtige Geshäftsvorfälle durchexerzieren. Die intensive Ausbildung aller Mitarbeiter am Bildschirm nützt nur wenig. Es ist ausgesprochen wichtig, den Anwender über Veränderungen rechtzeitig zu informieren, bei ihm das Verständnis für neue Abläufe frühzeitig zu wecken und bei der Einführung des Systems die volle Unterstützung durch die Mitglieder des Projektteams zu sichern.
Über die Frage eines Parallelbetriebes kann nur firmenindividuell entschieden werden. Unzweckmäßig ist ein Parallelbetrieb gleicher Funktionen in gleichen Bereichen oder gar ausgeschlossen dann, wenn auf dei gleichen Ressourcen zugegriffen wird. Es ist jedoch so oder so auf eine modulare Einführung des neuen Systems zu achten. Bei einer vertikalen Trennung nach Produkten und Produktlinien können alle Funktionen eines bestimmten Bereiches eingeführt werden, was das Projekt wesentlich vereinfacht. Bei einer funktionsweisen Trennung sind die Abgrenzungen so zu legen, daß vernünftige Module mit entsprechend einfachen Schnittstellen gebildet werden.
Trotz aller Anstrengungen, keine Modifikationen von Standardsoftware vorzunehmen, gibt es zwingende Gründe, bestimmte Modifikationen zuzulassen. Diese sollten aber wenn möglich nicht innerhalb der Standardsoftware, sondern als Systemzusätze außerhalb des Standards realisiert werden. Bei Modifikationen innerhalb der Standardsoftware ist zu beachten, daß bei einem Releasewechsel alle Modifikationen überprüft und wieder eingebaut werden müssen (Aufwand!). Dies bedingt eine saubere und nachgeführte Dokumentation aller Modifikationen.
Obwohl alle in den Arbeitsgruppen vertretenen Betriebe verschiedene Ausgangslagen (Produktsortiment, Zielsetzungen, Aufgaben, Hard- und Software-Konfigurationen) im PPS-Bereich haben und alle kurz nach oder vor einem Systemwechsel stehen, zeigt sich, daß die wesentlichen Probleme in der Aufbau- und Ablauforganisation liegen und nicht in der Informatik als solche. Die Ablösung eines PPS-Systems ist deshalb vor allem ein Organisationsprojekt und nicht ein EDV-Projekt. - Eine Herausforderung für Manager, weniger für Techniker.