Advertisement

Folgerungen aus der Vorgehenskonzeption für die Gestalt der Standard-Software zur PPS

  • Torsten Stein
Chapter
  • 66 Downloads

Zusammenfassung

An einzelnen Stellen der in Kapitel 6 dargestellten Vorgehenskonzeption haben sich Dissonanzen zwischen den Anforderungen an PPS-Systeme und deren Eigenschaften gezeigt. Der segmentspezifischen, einfachen Ablaufkonzeption nach Abschn. 6.3.1 „Errichten der Konzeption für eine prozeß- und objektorientierte Organisationsstruktur“stehen meist umfangreiche PPS-Systeme gegenüber, die in Funktionsmodule unterteilt sind. Darüber hinaus wurden die hohen Ansprüche deutlich, die insbesondere nach der Inbetriebnahme an die Anpassungsfähigkeit der Software gestellt werden müssen. Für die Wirtschaftlichkeit des PPS-Systems und die Effizienz des Auftragsabwicklungsprozesses ist es unabdingbar, daß die dynamische Entwicklung der intern und extern begründeten Anforderungen an die Systemunterstützung das PPS-System nicht vorschnell veralten lassen. Der in Abschn. 6.4 „Konzeptionsrealisierung, PPS-Systemimplementierung und Systemanwendung“erläuterte gleitende Übergang von der organisatorischen Umstrukturierimg zu kontinuierlichen Ablaufverbesserungen muß durch ein flexibles EDV-System mitgetragen werden. Dagegen setzt die PPS-Software im allgemeinen bestimmte Arbeitsabläufe voraus, womit die organisatorischen Gestaltungsspielräume für die Auftragsabwicklung eingeschränkt sind. In Abb. 51 wird der Strukturunterschied zwischen der funktional gegliederten PPS-Software und den prozeßund objektorientierten Unternehmungssegmenten skizziert.

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

Literature

  1. 1.
    Vgl. Scheer (1991a), S. 9 und derselbe (1991b), S. 15.Google Scholar
  2. 1a.
    Die Gliederung der Funktionsmodule entspricht der Anordnung im rechten Teil von Abb. 2 in Abschn. 2.1.1 „Begriffsbestimmungen“. Zugunsten der Übersichtlichkeit sind hier weitgehend autonome Produktsparten skizziert. Daher werden keine EDV-gestützten Querschnittsfunktionen im Sinne der in Abschn. 5.4.2 „Objektorientierte Aufbauorganisation“, S. 138 ausgeführten Optionen dargestellt.Google Scholar
  3. 2.
    Eine Übersicht zu den Konfigurationsmöglichkeiten für Standard-Software gibt Tab. 25 in Abschn. 6.4.Google Scholar
  4. 3.
    Vgl. die primär auf den Produktionsbereich und die Fertigungssteuerung bezogenen Aussagen von Hamacher/Pape bzw. Fandel/François/Gubitz und Kurbel in Abschn. 6.3.2 „Vorauswahl des PPS-Systems“, wonach ein einheitliches PPS-System nur einen Teilbereich der heterogenen Organisationsstrukturen befriedigend abdeckt. Weitere Beispiele für unterschiedliche Auftragsabwicklungsprozesse in ein und derselben Unternehmung werden von Schomburg (1994), o. S. in Form von Auftragsklassen skizziert, die jeweils andersartige Laufwege haben.Google Scholar
  5. 4.
    Vgl. Stein (1993), S. 50 sowie die Ausführungen in Abschn. 2.5 „Verdichten der Erkenntnisse zu einem Anforderungsrahmen für die Auswahl und Einführung von PPS-Systemen“, S. 65f.Google Scholar
  6. 5.
    Zur Differenzierung zwischen Konfigurationsmaßnahmen im Rahmen der vorhandenen Anpassungshilfsmittel und Software-Anpassungen vgl. Abschn. 2.3.1 „Implementierungsaufgaben und -probleme“, S. 4fff.Google Scholar
  7. 6.
    Vgl. sinngemäß auch Haaks (1992), S. 63, demzufolge Anpassungen der Benutzeroberfläche nicht den Anpassungsbedarf bei der Arbeitsteilung zwischen Mensch und Maschine berücksichtigen.Google Scholar
  8. 7.
    Vgl. sinngemäß auch Mertens/Helmer/Rose/Wedel (1989), S. 22 und die dort genannte Literatur. Darüber hinaus zeigen die Autoren am Beispiel eines bestimmten PPS-Systems einige Programmstellen „… mit quasi verstecktem parametrischen Einfluß, bei denen durch Variation logisch voneinander abhängiger Datenfelder beabsichtigte oder unbeabsichtigte Auswirkungen auf Planungsergebnisse entstehen“, ebd. S. 23f.Google Scholar
  9. 8.
    Erste CIM-bezogene Erwartungen in diese Richtung bringen Köhl/Esser/Kemmner (1989), S. 15 zum Ausdruck. Konkret auf das jeweils angebotene PPS-System bezieht sich die entsprechende Aussage von Sengen (1993), S. 5 sowie die von Möckesch (1993), o. S. skizzierte Differenzierungsstrategie eines Software-Herstellers mit vergleichsweise großem Marktanteil.Google Scholar
  10. 9.
    Somit kann der Auffassung von Mattheis (1993), S. 169 nicht gefolgt werden, wonach die mangelnde Anpaßbarkeit von Standard-Software durch den Branchenbezug und die Parametrisierung wettgemacht wird.Google Scholar
  11. 10.
    Vgl. Scheer (1994), S. 632.Google Scholar
  12. 11.
    Vgl. Schomburg (1991), S. 53ff. Kemmner (1991a), S. 17 bezeichnet diesen Ansatz als multiplikative Dezentralisierung.Google Scholar
  13. 12.
    Vgl. Schomburg (1991), S. 58.Google Scholar
  14. 13.
    Vgl. Scheer (1991b), S. 19. Eine typische Basisfunktion ist die Grunddatenverwaltung.Google Scholar
  15. 14.
    Vgl. Kemmner (1991), S. 17 und S. 22, der in diesem Zusammenhang von einer segmentiven Dezentralisierung spricht. Allerdings zeigt das Fallbeispiel des Autors, daß dieser nicht von Segmenten mit unterschiedlichen Funktionen ausgeht. Stattdessen werden jeweils aufeinander aufbauende Funktionen aus dem zentralen System herausgenommen und auf verschiedene Subsysteme ausgelagert. Damit liegt nach wie vor eine funktionale Gliederung der Software-Struktur vor, ebd. S. 155f.Google Scholar
  16. 15.
    Vgl. Grünewald/Schotten (1993), S. 1 ebenso wie Schotten/Vogeler (1994), S. 52f. Unter der Bezeichnung ‚Enabler‘wurde von der Fa. IBM bereits Ende der 80er Jahre ein entsprechendes Konzept für Anwendungs-Software im Bereich der Fertigungssteuerung entwickelt, vgl. Scheer (1990), S. 142f.Google Scholar
  17. 16.
    Dabei wurden 129 Systemanbieter befragt, vgl. Chen/Geitner (1993), S. 52 und S. 58.Google Scholar
  18. 17.
    Vgl. Doumeingts/Chen (1992), S. 37 ebenso wie Heß (1993), S. 28.Google Scholar
  19. 18.
    Vgl. Meyer (1990), S. 65 und S. 249.Google Scholar
  20. 19.
    Vgl. Schäfer (1994), S. 11.Google Scholar
  21. 20.
    Vgl. Schäfer (1994), S. 5f. Meyer (1990), S. 54 skizziert den generellen Unterschied zur Funktionsmodellierung durch den Merksatz, daß bei der objektorientierten Software-Entwicklung erst ‚woran‘und dann ‚was‘gefragt wird.Google Scholar
  22. 21.
    Vgl. Meyer (1990), S. 56ff. ebenso wie Scheer (1994), S. 55 und die dort angegebene Literatur. Dabei wird im Rahmen des objektorientierten Ansatzes oft von Methoden anstelle von Funktionen gesprochen, vgl. Scheer (1994), S. 56.Google Scholar
  23. 22.
    Vgl. Schäfer (1994), S. 13 ebenso wie Heß (1993), S. 27, der aus diesem Grund die objektorientierte Entwicklung als methodische Gestaltungs- und Vorgehensgrundlage für die Wiederverwendung von Software heranzieht.Google Scholar
  24. 23.
    Vgl. Heß (1993), S. 33 ebenso wie Meyer (1990), S. 67. Google Scholar
  25. 24.
    Vgl. Schäfer (1994), S. 13Google Scholar
  26. 25.
    Vgl. Heß (1993), S. 30. Eine Nachricht enthält neben dem Parameter als eigentliche Information auch Angaben zum absendenden und empfangenden Objekt sowie zur auslösenden und angesteuerten Funktion, vgl. Scheer (1992a), S. 125.Google Scholar
  27. 26.
    Vgl. Abb. 51 in Abschn. 7.1 „Struktur- und Profildifferenzen“.Google Scholar
  28. 27.
    Haaks (1992), S. 147 spricht von einem objektorientierten Anwendungs-Rahmensystem, das auch direkt, d. h. ohne spezifische Erweiterungen einsetzbar ist.Google Scholar
  29. 28.
    Vgl. Haaks (1992), S. 105.Google Scholar
  30. 29.
    Vgl. Heß (1993), S. 41 und die dort genannte Literatur.Google Scholar
  31. 29a.
    Die Konturen für ein Objekt lehnen sich an die Darstellungsweise von Heß (1993), S. 31 an.Google Scholar
  32. 30.
    Vgl. Kurbel (1993), S. 274f. sowie sinngemäß auch Stopp (1993), o. S. und Haaks (1992), S. 141.Google Scholar
  33. 31.
    Vgl. mit Bezug auf objektorientierte Kernsysteme Kurbel (1993), S. 331f.Google Scholar
  34. 32.
    Beim Vergleich mit dem in Abschn. 2.3.2 „Implementierungsdauer“, S. 47 zitierten Begriffsverständnis für Module zeigt sich, daß weder die funktionsorientierte Erklärung noch die Umschreibung aus der Informatik das Wesen dieser Bausteine treffen, so daß ein neuer Modulbegriff geboten ist. Mit Blick auf die Zielsetzung der vorliegenden Untersuchung bleibt diese Aufgabe weiterführenden Abhandlungen vorbehalten.Google Scholar
  35. 33.
    Kurbel/Nietsch/Rautenstrauch (1992), S. 288ff. beschreiben ein Projekt zur Individualisierung von Fertigungsleitstandssystemen auf der Basis objektorientierter Software-Technologie. Haaks (1992), S. 157 weist auf Beispielsysteme zur Bildverarbeitung hin.Google Scholar
  36. 34.
    Vgl. Bohlig (1994), o. S. Die Entwicklung dieses PPS-Systems wurde aufgrund des erheblichen Innovationsgehaltes vom Bundesminister für Forschung und Technologie (BMFT) gefördert, ebd. o. S.Google Scholar
  37. 35.
    Vgl. die in Abschn. 1.1 „Problemstellung“, Abb. 1 gezeigte Differenzierung der CIM-Bausteine sowie das Y-Modell von Scheer (1990), S. 2.Google Scholar
  38. 36.
    Steffen (1990), S. 199f. schlägt im Zusammenhang mit der betriebswirtschaftlichen Erweiterung der CIM-Konzeption die Kennzeichnung als “computergestützte Bewältigung der Abwicklung zusammengehörender Unternehmensprozesse“vor.Google Scholar

Copyright information

© Springer-Verlag Berlin Heidelberg 1996

Authors and Affiliations

  • Torsten Stein
    • 1
  1. 1.Industrieplanung und Organisation (i+o) GmbHHeidelbergDeutschland

Personalised recommendations