Erfahrungen bei der Einführung von PPS-Systemen in mittelständischen Unternehmen

Problemlösungen ohne Pannen existieren nicht

15.09.1989

PPS-Systeme greifen tief in das innere Gefüge eines Unternehmens ein. Bei ihrer Einführung sind Probleme, Pannen und Schwierigkeiten unausweichlich. Birgit Speer* zeigt, wie sie sich durch saübere und frühzeitige Planung auf ein Minimum reduzieren lassen.

Im Gegensatz zu den langjährigen und frühen DV-Anwendern in traditionellen kommerziellen Gebieten, wie Banken und Versicherungen, gibt es in der Bundesrepublik eine große Anzahl mittelständischer Industrieunternehmen der verschiedensten Branchen, die sich erst seit kurzer Zeit (seit etwa fünf Jahren) intensiv mit der Datenverarbeitung für kommerzielle und technische Anwendungsgebiete auseinandersetzen. Dabei werden die Unternehmen (anders als in den 60er und 70er Jahren) mit einer Fülle von Standardsoftware konfrontiert und vor allem technischen Möglichkeiten wie

- Netzwerken (Büro und Fertigung),

- Workstationkonzepten

- PC-Einsatz (Host-PC-Kopplungen),

- Gateways (Host-zu-Host-Kopplungen),

die alle in ihrer Effektivität beurteilt werden müssen.

Da in den Produktionsunternehmen im allgemeinen keine Spezialisten für eine derartige Kosten-/Nutzenanalyse und die notwendigen Konzepte und Planungen zur Verfügung stehen, sind sie gezwungen, sich entweder auf Hard- und Softwareanbieter zu verlassen oder externes Know-how auf verschiedenen Ebenen zu beschaffen.

Die Diskrepanz zwischen dem firmenspezifischen Erfahrungsschatz in bezug auf Organisation, Techniken, Produkten auf der einen Seite und den hard- und softwaregebundenen Funktionalitäten sowie deren Umsetzung, Schulung und Einführung auf der anderen, birgt reichlich Gefahren - nicht nur finanzieller Art.

Viele PPS-Einsteiger haben nach längerer Anwendungszeit viele bittere Erfahrungen gesammelt und sind mit den erreichten Ergebnissen aus Kosten- und Organisationsgesichtspunkten mehr als unzufrieden, enttäuscht und oft auch ziemlich ratlos.

Die Auslöser für die Entscheidung, ein PPS-System einzusetzen, sind äußerst vielschichtig und vielfältig. Meistens kommt eine ganze Reihe von Problemen oder Gründen zusammen, die Zeitpunkt, Umfang und Kategorie der Hard- und Software bestimmen. Sie reichen von der einsamen Entscheidung an der Spitze, bis zu langjährigen, aufwendigen innerbetrieblichen Analysen und Evaluationen:

Der Druck durch Auftraggeber wird immer wieder besonders in der Automobilindustrie und bei deren Zulieferern deutlich. Nicht nur Termine und exakte Qualitätsvorgaben sind gang und gäbe, auch die Überwachung und Kontrolle des Fertigungsablaufes und der Fertigungsplanung mit Vorgaben für Arbeitspläne, Zeichnungen und Dokumentation sind üblich geworden. Die Vorgaben und Unterlagen werden zunehmend nicht mehr in Papierform, sondern auf Datenträgern zur Verfügung gestellt. Der Zulieferbetrieb darf dann zusehen, wie er sich seine Werkstattpapiere erzeugt.

Leichter wird diese Abwicklung durch den Einsatz geeigneter CAD- und PPS-Systeme. Schon in der Akquisitionsphase von Aufträgen im harten Zuliefergeschäft, kann der Nachweis vorhandener DV-Systeme über den Zuschlag entscheiden.

Die schnelle und aktuelle Dokumentation von Produktionsvorschritten, Qualitätszeugnissen und ähnlichem, ist durch die neuen Produkthaftungsgesetze zusätzlich beeinflußt worden. Diese und andere Entwicklungen, wie der EG-Binnenmarkt 93, wirken als Katalysator für integrierte Informationssysteme quer durch alle Branchen und Firmengrößen.

Bei Unternehmen mit längerer Erfahrung im Umgang mit DV-gestützten Systemen und eigener DV-Abteilung gibt es oft ein böses Erwachen, wenn sich ein euphorisch begonnenes Entwicklungsprojekt "Eigenes PPS-System" nach vielen Monaten (oder Jahren!) und nach großem Aufwand an Personal, Investitionen und Nerven totgelaufen hat. In dieser Situation gibt es die zwei konträren Lager der hochzufriedenen Anwender (weil ihr Teilgebiet zufällig gut bedacht wurde) und der restlos frustrierten (weil die langjährigen Versprechungen nie gehalten wurden). Ein Neuanfang mit inzwischen reifen Standardsoftwarepaketen ist eine Lösung.

Die reichlich vorhandenen positiven und negativen Erfahrungen helfen bei der Umsetzung, wenn die anfänglichen Widerstände der "Väter der Eigenentwicklung" überwunden und der DV-Abteilung deutlich geworden ist, welch umfangreiche Aufgaben - trotz Standardsoftware noch zu bewältigen sind.

Neben diesen beiden Gründen für den Einsatz von PPS-Systemen sind auch Einflüsse von Hard- und Softwarelieferanten, Reorganisationsmaßnahmen und auch politische

Faktoren wie die großen Förderprogramme für Forschungs- und Entwicklungsprojekte auf europäischer und nationaler Ebene von Bedeutung.

Während beziehungsweise nach der Entscheidung für ein bestimmtes PPS-Produkt (Standardsoftware, extern programmierte Individualsoftware, eigenerstellte Lösung) beginnen zwei Projektebenen zu leben:

- die DV-technische und DV-organisatorische Ebene,

- die anwendungstechnische und ablauforganisatorische Ebene.

Selten befinden sich Unternehmen in der glücklichen Lage, für beide Ebenen einen geeigneten Projektleiter im Hause zu haben. Auf der Anbieterseite steht zwar hoffentlich das Produkt-Know-how für die eigenen Produkte zur Verfügung, die firmenspezifische Umsetzung der Anwenderanforderungen jedoch muß innerbetrieblich geplant und gelöst werden.

Die Komplexität eines PPS-Einführungsprojektes kann durch die Definition von geeigneten Pilotprojekten auf überschaubare Zusammenhänge reduziert werden. Mit Hilfe dieser abgrenzbaren Teilprojekte kann der Projektleiter sich selbst und dem Kernteam das notwendige Know-how auf anwendungstechnischer und ablauforganisatorischer Ebene verschaffen, und so Akzeptanz und Effizienz der Umsetzung absichern.

Gerade die eigenen Erfahrungen sind für eine schnelle Abwicklung bei der PPS-Einführung nützlich. Dazu gehört unbedingt ein ständiger Ansprechpartner für die Anwender, eine Form des Benutzerservices, die sich nicht nur auf Teilgebiete beschränkt. Es ist für die Benutzer nicht zumutbar, sich mit jeder technischen Einzelheit ihres Ein- oder Ausgabegerätes, mit den Folgen von Releasewechseln oder Anpassungen, mit Programmabstürzen und ähnlichem auseinanderzusetzen.

Die Vorbereitungsphase für den Einsatz hochintegrierter Software, wie es ein PPS-System ist, ist sowohl bei der Ablösung von DV-gestützten Altsystemen, als auch bei der Umstellung manueller Abläufe, besonders aufwendig. In beiden Fällen müssen Parallellaufzeiten von sechs bis zwölf Monaten von vornherein eingeplant werden. Auch in dieser Zeit ist das Kernteam schon zu rund 80 Prozent seiner Kapazität gefordert, um

- Schlüsselsysteme zu überprüfen,

- Abläufe zu reorganisieren,

- Datenbestände zu konsolidieren,

- Konzepte zu entwickeln (etwa für die Archivierung),

- Schnittstellen zu anderen Systemen festzulegen,

- Einführungs-, Umstellungs- und die Schulungsplanung zu entwerfen und abzustimmen,

- sich mit den neuen Techniken vertraut zu machen.

Es ist illusorisch, die Einführung eines PPS-Systems zu einem festgelegten Stichtag vollständig durchfuhren zu wollen. Wie bei einem Umzug spart eine gute, durchorganisierte Vorbereitung, einschließlich einer intensiven Entrümpelungsaktion, viel Zeit bei der Inbetriebnahme. Gerade bei zentralen, die Produktion bestimmenden Funktionen, beispielsweise dem Druck beziehungsweise der Bereitstellung von Werkstattpapieren, darf keine Gefährdung durch die Umstellungsmaßnahmen eintreten. Ähnlich kritisch sind alle Buchhaltungsfunktionen. Die frühzeitige Strukturierung der Verteilung der Benutzerberechtigungen erspart dabei viel Ärger. Parallel zu diesen organisatorischen Maßnahmen muß das technische System (Host, Terminals, Workstations, Netzwerk, Betriebszeiten und so weiter) konfiguriert werden.

In Zusammenarbeit mit den Anbieterfirmen sind die genauen Randbedingungen für Hardware und Betriebssystemsoftware, also

- Erstausstattung,

- Migrationsplanung,

- Wartungs- und Nutzungsverträge,

- Schulungen,

- Lieferfristen,

- Releasekonzepte,

- Übernahmeplanung

für das geplante PPS-Projekt abzustecken. Hierbei ist die Übernahme der Altdaten, egal ob sie maschinell verwertbar oder nur manuell geführt sind, mit besonderer Sorgfalt und Planung zu betreiben.

Der produktive Start in den Pilotbereichen sollte immer in Abstimmung mit den betroffenen Fachabteilungen erfolgen. Überforderungen zeitlicher, organisatorischer und personeller Art sind in jedem Fall zu vermeiden. Grundvoraussetzung für den Erfolg ist ein gutes Vertrauensverhältnis innerhalb des Kernteams und zu den Anwendern.

Die Einsatzschwerpunkte im Produktionsplanungs- und -steuerungssystem:

- Artikelstamm/Materialbeschreibungssätze,

- Stücklistenstammdaten,

- Arbeitsplanstammdaten,

- Schlüsseldaten für Kostenstellen, Kapazitätseinheiten, Mengeneinheiten, Transportzeiten und Kalender

sind auf ihre Verträglichkeit mit dem Altsystem zu überprüfen. Die integrierte Verarbeitung im PPS-System hat bei Fehlern in den Stammdaten viel weitreichendere Folgen als bei einer manuellen Abwicklung, da die Überprüfungsmechanismen nur Standardfunktionen abdecken können.

Die meisten Pannen bei der Inbetriebnahme des Systems entstehen durch eine unüberlegte beziehungsweise unsinnige Belegung von wichtigen Datenfeldern, von denen die Steuerung ganzer Ablaufketten abhängt.

Die Festlegung der wesentlichen Auftragsparameter, Auftragstermin, Auftragsumfang und Unterteilung in Unteraufträge muß nach der "Vertriebsarbeit" von den technischen Bereichen überarbeitet werden. Die Bestimmung der Ecktermine (Konstruktionsende, AV, Fertigungsstart, Montagebeginn, Versandtermine) sollte bereits in dieser frühen Phase erfolgen. Als sehr nützlich hat sich die Einführung von Standardparametern erwiesen, die bestimmte Abläufe auslösen - bis hin zur kompletten automatischen Stücklistenauflösung und Auftragsnetzbildung, die die Auftragsbearbeitung für alle Abteilungen vereinheitlicht. Viele Pannen entstehen durch eine unzureichende Strukturierung der Auftragsdaten, durch inkonsistente, der Auftragsbearbeitung nicht angepaßte Benutzerberechtigungen, oder die mangelnde Aktualisierung der Auftragsstammdaten.

Wenn eine Grobplanung eingesetzt wird, wie etwa im Anlagen- oder Schiffbau, muß das Auftragsnetz mit den Schnittstellen zur Feinplanung entsprechend sorgfältig aktualisiert werden. Ist die Feinplanung für einen Auftrag bereits vollständig aufgesetzt, dürfen Änderungen auf der Grobplanungsebene nur noch in Ausnahmefällen durchgeführt werden, da sich die Konsequenzen für die Feinplanung nur noch mit einem kaum zu rechtfertigendem Aufwand nachvollziehen lassen.

Inkonsistenzen in den Auftragsdaten durch organisatorisches Mißmanagement oder nicht ausreichend festgelegte Arbeitsabläufe treten leider viel zu häufig auf.

Die Auftragsterminierung (Grob- und Feinplanung) ist selten ausschließlich einer Auftragsleitstelle zugeordnet, so daß oft viel zu früh Material bestellt, aus dem Lager ausgefaßt, an Maschinen bereitgestellt oder Papiere gedruckt werden. Dafür bleiben dann die Arbeiten für Aufträge, die sich im richtigen Zeitraster befinden, so lange liegen, bis dieser Auftrag kritisch ist und die normalen Steuerungsparameter nicht mehr greifen können.

Einflußnahme schon durch den Konstrukteur

Schon der Konstrukteur kann auf die Beschaffungsart und -menge Einfluß nehmen. Bei reinen Auftragsfertigern, etwa Anlagenbauern, ist das sinnvoll und notwendig. Langlaufende Teile, Spezialmaterialien oder vom Kunden gewünschte Sonderausstattungen müssen sehr früh, oft schon in der Konstruktionsphase auftragsbezogen disponiert werden. Der Konstrukteur muß sich dieser Möglichkeiten und Konsequenzen bei der Stücklistenbearbeitung bewußt sein. Bei der Übernahme vorhandener Klassifikationen für die Dispositionsmerkmale muß die Übertragbarkeit und Einsatzfähigkeit mit der Konstruktion, der Normungsstelle, der Materialwirtschaft und der Arbeitsvorbereitung überprüft werden.

Die Möglichkeiten zur Materialklassifizierung sind in den Standardsoftwarepaketen ausreichend eingerichtet, so daß hier kaum Anpassungen nötig sind. Aufwendige Zusatzprogrammierung führt aufgrund der Systemzusammenhänge oft zu weiteren Anpassungen in anderen Modulen, die bei jedem Releasewechsel, Einsatz von weiteren Modulen oder Anbindung von anderen Paketen anfallen.

Dagegen ist Anpassungsprogrammierung bei Maskenlayouts, Druckbildern oder Barcode-Erfassung immer notwendig, um den firmenspezifischen Rahmenbedingungen gerecht zu werden. Ein gutes Standardsoftwarepaket zeichnet sich durch eine einfache Handhabung dieser Ausgabeschnittstellen aus.

Für die Produktstrukturierung (Baukästen, Wiederholteile, Ersatzteilpakete) sind Expertensysteme sinnvoll einsetzbar. Meist wird jedoch in traditioneller Weise die Struktur in den Stücklisten hinterlegt. Besser wäre es, diese Strukturen möglichst transparent und leicht abänderbar abzulegen, auch wenn dadurch mehr Datenvolumen und zum Teil auch Redundanzen entstehen. Eine hochkomplexe, rechenoptimale Stücklistenorganisation hat immer Nachteile für angrenzende Bereiche wie die Zeichnungserstellung oder CAD und Arbeitsplanwesen.

Es kann für eine termingerechte Auftragsabwicklung entscheidend sein, wann die Arbeitsvorbereitung erfährt, in welchem Umfang neue Arbeitspläne zu erstellen sind. Wenn CAM-Pakete eingebunden sind, die NC-Simulationen erfordern, ist die Schnelligkeit (Effektivität) des Informationsaustausches noch wichtiger. Je unübersichtlicher die Stücklistenstrukturen werden, desto schwieriger sind diejenigen Bauteile exakt zu extrahieren, die neue Arbeitspläne oder Zeichnungen beinhalten. Oft muß die Bearbeitung dann so lange warten, bis das Produkt bis zur letzten Schraube aufgelöst ist, weil erst dann die Neukonstruktionen oder Änderungen herausfallen. Bei späteren, nachträglichen Änderungen wird diese Prozedur noch aufwendiger.

Umfassende "Lösungen" sind häufig unhandlich

Für die Strukturierung der Arbeitspläne gilt ähnliches wie für die Stücklisten. Zu oft wird versucht, eine Standardisierung über die "Erfindung des Universalarbeitsplanes" zu erreichen. Diese "eierlegenden Wollmilchsäue" werden ganz schnell unhandlich und erschweren die Aktualisierung eher, als sie zu vereinfachen.

Effizienter sind Konzepte mit überschaubaren Bausteinen (Arbeitsfolgen) und gut strukturierten Katalogen für die Beschreibung von

- Standardarbeitsgängen,

- Standardkapazitätseinheiten,

- Vorrichtungen,

- Werkzeugen,

- Betriebsmitteln (Chemikalien, Zusatzeinrichtungen, Meßzeuge),

- NC-Programmen,

deren Zusammenbau dann den aktuellen Arbeitsplan für den bestimmten Auftrag ergibt.

Organisationsmängel, die sich aus nicht anwenderorientierten DV-Abläufen ergeben, sind für die Benutzer in den Fachabteilungen nur äußerst mühsam zu überwinden. Im allgemeinen hat die Fachabteilung keine Ausbildung auf DV-technischen Gebieten genossen und ist nicht in der Lage, effizient zu entscheiden, welche Funktionen

- Online oder im Batch ausgeführt werden sollten,

- die Belastung des Rechners erhöhen,

- Belastungen beim RZ-Personal entstehen lassen,

- Wartezeiten am Bildschirm erzeugen,

- andere Systemmodule belasten oder sogar sperren.

Wenn keine Unterstützung von der DV-Abteilung erfolgt, kommt es zu großen Pannen, die sich auf das Gesamtsystem auswirken. Funktionen, die eigentlich nur für Testzwecke in der Bearbeitung gedacht sind, wie etwa der Online-Ausdruck eines Arbeitsplanes, kann, wenn die nötige Information fehlt, auch für den Produktionsfall, das heißt den Ausdruck eines Tagesbedarfes an Werkstattpapieren, mißbraucht werden. In solch einer Situation schnelle die Rechnerbelastung in die Höhe, andere Funktionen können gar nicht mehr ausgeführt werden, in schwierigen Fällen steht das System.

Ähnlich beliebte Funktionen sind Unterdeckungsprüfungen über große Materialbestände, ohne vorher geeignete Selektionskriterien gewählt zu haben. In die gleiche Richtung gehen die Nutzung von statistischen Funktionen, die ohne sinnvolle Selektion viel Papier aber wenig Nutzen erzeugen.

Um solche Fehlbedienungen des Systems von vornherein zu verhindern beziehungsweise zu minimieren, ist für die Fachabteilungen eine ausreichende und geeignete Schulung vorzusehen. An Beispielen aus den täglichen Arbeitsabläufen sind die Systemfunktionen zu erläutern und die Vor- und Nachteile bestimmter Selektionsmaßnahmen, Ausführungsparameter und Arbeitsweisen darzustellen. Voraussetzung ist die sinnvolle Vergabe der Benutzerberechtigungen, wenn nötig bis auf Funktions- oder Feldebene. Auch regelmäßige Nachschulungen von neuen Mitarbeitern oder die spätere Überprüfung der Abläufe nach etwa einem Jahr Echtbetrieb sind vorzusehen. Die betrieblichen Schlüsseldaten werden bis auf grundlegende wie Betriebskalender, Mengeneinheiten, Arbeitszeiten, Maschinenstundensätze, am effizientesten sukzessive aufgebaut. Die Anlage einer Transportzeitmatrix beispielsweise und die Bestimmung von Übergangszeiten zwischen einzelnen Kapazitätseinheiten sollten nach und nach anhand von Erfahrungswerten geschehen. Vor allen Dingen aber müssen allen Fachabteilungen die Zusammenhänge zwischen den Schlüsseldaten, auch zu benachbarten Sachgebieten ausführlich erläutert werden.

Die Erwartungen werden zunehmend realistischer

Fazit: Die vielen schlechten Erfahrungen mit integrierter PPS-Software haben durchaus auch positive Effekte:

- die Anwender sind kritischer geworden gegenüber Hard- und Softwarelieferanten,

- die Vorbereitung auf den Einsatz derartiger Systeme ist intensiver,

- die Kalkulation von PPS-Einführungsprojekten ist realistischer,

- CIM ist und bleibt solange ein Schlagwort, wie es nicht über reale Anforderungen mit ganz konkretem, betrieblichen Leben gefüllt wird.

*Dipl.-Ing. Birgit Speer ist Bereichsleiterin Industrieautomation bei der IFA Beratungsgesellschaft für Automation mbH, Düsseldorf.

Aufgaben in der Planungs- und Einführungsphase von PPS

- Bestimmen eines Projektleiters mit ausreichender Kompetenz

- Überprüfung der Vollständigkeit der Anforderungskataloge beziehungsweise der Pflichtenhefte aus den Fachabteilungen

- Festlegen der detaillierten Projektplanung (Termine, Kapazitäten) einschließlich der Schulungsplanung gemeinsam mit den Fachverantwortlichen

- Abgrenzung des technischen und des ablauforganisatorischen Teilprojektes

- Delegation von Teilprojekten und Verantwortlichkeiten

- Festlegung der Pilotprojekte und des Kernteams

- Schulung der Mitarbeiter für die Durchführung der Pilotprojekte (Hard- und Software)

- Festlegung der Benutzerorganisation (Berechtigungen, Dokumentation, Anwenderservice)

- Raumplanung

- Datenübernahme- und Reorganisationskonzept