VroniPlag Wiki

This Wiki is best viewed in Firefox with Adblock plus extension.

MEHR ERFAHREN

VroniPlag Wiki
Registrieren

Fragmente (Plagiat, gesichtet)

Kein Fragment



Fragmente (Plagiat, ungesichtet)

Kein Fragment



Fragmente (Verdächtig / Keine Wertung)

Kein Fragment



Fragmente (Kein Plagiat)

Kein Fragment



Fragmente (Verwaist)

15 Fragmente

[1.] Analyse:Wdi/Fragment 001 03 - Diskussion
Bearbeitet: 20. January 2020, 14:32 Klgn
Erstellt: 20. January 2020, 14:32 (Klgn)
Fragment, SMWFragment, Schutzlevel, Unfertig, Verschleierung, Wdi, Willfort 2001

Typus
Verschleierung
Bearbeiter
Klgn
Gesichtet
No
Untersuchte Arbeit:
Seite: 1, Zeilen: 3-16
Quelle: Willfort 2001
Seite(n): 44, Zeilen: 1 ff.
1 Einleitung

1.1 Ausgangssituation

Der Versuch der Differenzierung unterschiedlicher Arten von Wissen mündet bei vielen wissenschaftlichen Arbeiten zum Thema Wissensmanagement in originellen Begriffen, wie zum Beispiel individuelles Wissen, kollektives Wissen, implizites Wissen, explizites Wissen, um nur einige zu nennen.1

Auf der Ebene von Daten, wo Unterschiede wesentlich einfacher erfassbar wären, wird eine Differenzierung in Verbindung mit dem Fokus „Management von Wissen“ kaum durchgeführt. Dabei wäre gerade dieser Zugang aufgrund der zunehmenden Vielfalt an Daten ein erster Schritt in Richtung Wissensorientierung. Es ist auch anzunehmen, dass mitunter die zunehmende Anzahl verfügbarer und einem Unternehmen zugänglicher Daten und die daraus entstandene Komplexität von Geschäftsprozessen wesentlich zur Notwendigkeit des Wissensmanagements geführt hat. Wissensmanagement und Datenmanagement sollten daher gut aufeinander abgestimmt sein. Dabei geht es beim Datenmanagement vor allem darum, Daten zur Verfügung zu stellen und bei Bedarf zu speichern, die für die Unternehmung von besonderer Relevanz sind.


1 Vgl. SAMMER [1999], S. 47

[Seite 44]

Der Versuch der Differenzierung unterschiedlicher Arten von Wissen mündet bei vielen Arbeiten zum Thema Wissensmanagement in originellen Begriffen, wie z.B. individuelles Wissen, kollektives Wissen, organisationales Wissen, implizites Wissen, explizites Wissen, analoges Wissen, digitales Wissen, sequentielles Wissen, gleichzeitiges Wissen, um nur einige zu nennen.72 Auf der Ebene von Daten, wo Unterschiede wesentlich einfacher erfassbar wären, wird eine Differenzierung in Verbindung mit dem Fokus "Management von Wissen" kaum durchgeführt. Dabei wäre gerade dieser Zugang aufgrund der zunehmenden Vielfalt an Daten ein erster Schritt in Richtung Wissensorientierung.

Es ist auch anzunehmen, dass mitunter die zunehmende Anzahl verfügbarer und einer Unternehmung zugänglicher Daten und die daraus entstandene Komplexität von Geschäftsprozessen wesentlich zur Notwendigkeit des Wissensmanagements geführt hat. Wissensmanagement und (elektronische) Datenverarbeitung sollten daher gut aufeinander abgestimmt werden. Dabei geht es in der Datenverarbeitung vor allem darum, Daten zur Verfügung zu stellen und bei Bedarf zu speichern, die für die Unternehmung von besonderer Relevanz sind.


72 Vgl. Sammer, M.: Wissensinduktion in Organisationen, Dissertation, Montanuniversität Leoben 1999, S. 47

Anmerkungen

Kein Hinweis auf die eigentliche Quelle.

Sichter
(Klgn)

[2.] Analyse:Wdi/Fragment 016 34 - Diskussion
Bearbeitet: 20. January 2020, 10:45 Klgn
Erstellt: 20. January 2020, 10:28 (Klgn)
Fragment, SMWFragment, Scheer et al. 2006, Schutzlevel, Unfertig, Verschleierung, Wdi

Typus
Verschleierung
Bearbeiter
Klgn
Gesichtet
No
Untersuchte Arbeit:
Seite: 16, Zeilen: 34 ff.
Quelle: Scheer et al. 2006
Seite(n): 15, Zeilen: 2 ff.
Wie bereits erörtert, werden entlang eines Geschäftsprozesses Daten und Informationen erzeugt und benötigt. Die Abbildung dieser Prozesse mit allen Funktionen, Daten, Informationen und IT-Systemen bildet somit eine ideale Grundlage für EDM-Strategien und darüber hinaus eine ideale Plattform zur Pflege und Kontrolle implementierter EDM-Prozesse. Von dieser Vorgehensweise profitieren nicht nur Anwender der IT-Systeme, sondern es wird auch eine „schlanke“ IT-Infrastruktur möglich mit ebenfalls „schlanken“ Datenstrukturen.

Mit der generischer [sic] Darstellung der EDM-Prozesse kann ein Überblick über die EDM-Thematik in Wechselwirkung zu den Geschäftsprozessen gegeben werden, wobei der Prozesslandkarte eine besondere Bedeutung zukommt.

Mit Hilfe einer Prozesslandkarte lassen sich Geschäftsprozesse im Rahmen von EDM-Strategien visualisieren und nach Managementprozessen, Kern- und Supportprozessen gliedern. Durch Unterprozesse beliebiger Tiefe kann man in den Einzelsegmenten alle Prozesse erreichen, die den Product Lifecycle eines Produktes beschreiben, im Kontext EDM speziell die des Produktentwicklungsprozesses.

2.1 Geschäftsprozesse als Grundlage für PLM

Entlang der Geschäftsprozesse werden Daten und Informationen erzeugt und benötigt. Die Abbildung dieser Prozesse mit allen Funktionen, Daten, Informationen und IT-Systemen bildet somit eine ideale Grundlage für PLM-Strategien und darüber hinaus eine ideale Plattform zur Pflege und Kontrolle implementierter PLM-Prozesse. Von dieser Vorgehensweise profitieren nicht nur Anwender der IT-Systeme, sondern es wird auch eine „schlanke“ IT-Infrastruktur möglich mit ebenfalls „schlanken“ Datenstrukturen. [...] In den folgenden Kapiteln wird mit Hilfe der generischen Darstellung von PLM-Prozessen (siehe Abb. 5) ein Überblick über deren Bedeutung im PLM gegeben. Anhand der generischen Prozesse wird in diesem Kapitel ein kurzer Überblick der Thematik PLM gegeben, in den weiteren Kapiteln dieses Buches wird auf die einzelnen Aspekte detailliert eingegangen, wobei den „Prozesslandkarten“ eine besondere Bedeutung zukommt: Sie entstehen immer mit Branchenbezug.

Mit Hilfe einer Prozesslandkarte werden alle Geschäftsprozesse im Rahmen von PLM-Strategien visualisiert und nach Managementprozessen, Kern- und Unterstützungsprozessen gegliedert. Durch Unterprozesse beliebiger Tiefe erreicht man in den Einzelsegmenten alle Prozesse, die den Product Lifecycle eines Produktes beschreiben, hier am Beispiel des Produktentwicklungsprozesses, der wiederum eine eigene Prozesslandkarte für verschiedene Branchen enthält (Abb. 6).

Anmerkungen

Kein Hinweis auf die Quelle.

Sichter
(Klgn)

[3.] Analyse:Wdi/Fragment 017 07 - Diskussion
Bearbeitet: 20. January 2020, 11:05 Klgn
Erstellt: 20. January 2020, 11:00 (Klgn)
Fragment, SMWFragment, Scheer et al. 2006, Schutzlevel, Unfertig, Verschleierung, Wdi

Typus
Verschleierung
Bearbeiter
Klgn
Gesichtet
No
Untersuchte Arbeit:
Seite: 17, Zeilen: 7-20
Quelle: Scheer et al. 2006
Seite(n): 10, 11, Zeilen: 10: 7 ff.; 11: 1 ff.
Zentrale Business Process Engines (BPE) ermöglichen die Abbildung und Koordination der relevanten Wertschöpfungsaktivitäten im Sinne einer Orchestrierung. Im Zusammenspiel mit Workflow-Funktionalitäten dienen diese primär der operativen Prozesssteuerung, z.B. durch den Transport der in einem Geschäftsprozess zu bearbeitenden elektronischen Bearbeitungsmappen von einem Arbeitsplatz zum anderen.

Die Geschäftsprozessabbildung und -ausführung sind integrale Bestandteile der Business Process Engine. Die darauf aufbauenden Anwendungssysteme erhalten automatisch eine stärkere Geschäftsprozessorientierung. Die Kombination von Gestaltung, Ausführung und Überwachung der betrieblichen Wertschöpfungsaktivitäten macht eine Unterstützung des gesamten Prozesslebenszyklus möglich. Insbesondere ermöglichen sie eine applikationsübergreifende Produktdaten-Integration und stellen den konsistenten Zugriff in verteilten Umgebungen sicher. Die Steuerung des Entwicklungsprozesses kann durch die Workflow-Funktion der Prozess-Plattform bzw. durch Workflow-Management-System (WFMS) wahrgenommen werden.

[Seite 10]

Zentrale Business Process Engines ermöglichen die Abbildung und Koordination der relevanten Wertschöpfungsaktivitäten im Sinne einer Orchestrierung. Im Zusammenspiel mit Workflow-Funktionalitäten und Enterprise-Application-Integration (EAI) ermöglichen sie die Umsetzung der Prozesslogik. Die Workflow-Funktionalitäten dienen primär der Prozesssteuerung, z. B. durch den Transport der in einem Geschäftsprozess zu bearbeitenden elektronischen Bearbeitungsmappen von einem Arbeitsplatz zum anderen. [...] Die Geschäftsprozessabbildung und -ausführung sind integrale Bestandteile der Business Process Engine. Die darauf aufbauenden Anwendungssysteme erhalten automatisch eine stärkere Geschäftsprozessorientierung. Die Kombination von Gestaltung, Ausführung und Überwachung der betrieblichen Wertschöpfungsaktivitäten macht eine Unterstützung des gesamten Prozesslebenszyklus möglich.

[...] Insbesondere ermöglichen

[Seite 11]

[...]

sie eine applikationsübergreifende Produktdaten-Integration und stellen den konsistenten Zugriff in verteilten Umgebungen sicher. Die Steuerung des Entwicklungsprozesses kann durch die Workflow-Funktion der Prozess-Plattformen wahrgenommen werden.

Anmerkungen

Kein Hinweis auf die Quelle.

Sichter
(Klgn)

[4.] Analyse:Wdi/Fragment 019 32 - Diskussion
Bearbeitet: 20. January 2020, 11:52 Klgn
Erstellt: 20. January 2020, 11:49 (Klgn)
Fragment, SMWFragment, Scheer et al. 2006, Schutzlevel, Unfertig, Verschleierung, Wdi

Typus
Verschleierung
Bearbeiter
Klgn
Gesichtet
No
Untersuchte Arbeit:
Seite: 19, Zeilen: 32 ff.
Quelle: Scheer et al. 2006
Seite(n): 3, 4, 5, Zeilen: 3: 2 ff.; 4: achte Zeile von unten; 5: 1 f.
3.1.1 Das Y-CIM-Modell

Mit der Entwicklung des Computer Integrated Manufacturing (CIM) zu Beginn der 80er Jahre begann der Versuch, industrielle Geschäftsprozesse mittels Informationstechnologien integriert zu steuern. Insbesondere sollten logistische Teilfunktionen eines Unternehmens sowie Forschungs- und Entwicklungsaktivitäten ganzheitlich betrachtet und gesteuert werden. Die technische Prozesskette fokussiert den Entwicklungs- und Herstellungsprozess der tatsächlichen Produkte. Aufgabe hier ist die Planung und Realisierung des Produktportfolios. Dies beinhaltet auf Planungsebene die Konstruktion und Absicherung der Produkte. Darüber hinaus muss aber auch das Produktionsumfeld zur Fertigung der konstruierten Produkte geschaffen werden. Hierunter fällt insbesondere die Definition der Arbeitspläne für die Mitarbeiter sowie die Implementierung der Steuerprogramme für die Fertigungsmaschinen. Beides wird auf Fertigungsebene zur Herstellung umgesetzt, also die Arbeitspläne von Mitarbeitern sowie die Steuerprogramme von den Maschinen aufgeführt.

[Seite 3]

1 PLM im Wandel der Zeit

Mit der Entwicklung des Computer Integrated Manufacturing (CIM) zu Beginn der 1980er Jahre begann der Versuch, industrielle Geschäftsprozesse mittels Informationstechnologie integriert zu steuern. Insbesondere sollten logistische Teilfunktionen eines Unternehmens sowie Forschungs- und Entwicklungsaktivitäten ganzheitlich betrachtet und gesteuert werden.

[Seite 4]

1.2 Das Y-CIM-Modell

[...]

Die technische Prozesskette dagegen fokussiert den Entwicklungs- und -herstellungsprozess der tatsächlichen Produkte. Aufgabe hier ist die Planung und Realisierung des Produktportfolios. Dies beinhaltet auf Planungsebene die Konstruktion der Produkte. Darüber hinaus muss das Produktionsumfeld zur Fertigung der konstruierten Produkte geschaffen werden. Hierunter fällt insbesondere die Definition der Arbeitspläne für die Mitarbeiter sowie die Implementierung der Steuerprogramme für die Fertigungsmaschinen. Beides wird auf Fertigungsebene zur Herstellung umge-

[Seite 5]

setzt, also die Arbeitspläne von den Mitarbeitern sowie die Steuerprogramme von den Maschinen ausgeführt.

Anmerkungen

Kein Hinweis auf die Quelle.

Sichter
(Klgn)

[5.] Analyse:Wdi/Fragment 030 25 - Diskussion
Bearbeitet: 21. January 2020, 07:08 Klgn
Erstellt: 21. January 2020, 06:54 (Klgn)
Fragment, SMWFragment, Schutzlevel, Unfertig, Verschleierung, Wdi, Willfort 2001

Typus
Verschleierung
Bearbeiter
Klgn
Gesichtet
No
Untersuchte Arbeit:
Seite: 30, Zeilen: 25-34
Quelle: Willfort 2001
Seite(n): 44, 45, Zeilen: 44: letzter Absatz; 45: 2 ff.
Unternehmensspezifische Daten

Dies sind Daten, die für die Unternehmung und seine Leistungserstellung in Geschäftsprozessen von besonderer Bedeutung sind. Diese Daten werden aus der organisatorischen Wissensbasis abgeleitet und dokumentiert, um im Prozess der Information einen Wissenstransfer zu anderen Wissensträgen [sic] zu ermöglichen. Damit Daten als unternehmensspezifische Daten klassifiziert werden können, müssen diese innerhalb von Informationsprozessen von Systemelementen der organisatorischen Wissensbasis - den Mitarbeitern - auf diese Eigenschaft hin überprüft werden.

Durch die laufende Veränderung des unternehmerischen Umfeldes gilt es Überlegungen anzustellen, wie man die Aktualität der unternehmensrelevanten Daten sicherstellen kann.

[Seite 44]

Unternehmensspezifische Daten

Dies sind Daten, die für die Unternehmung und seine Leistungserstellung in Geschäftsprozessen von besonderer Bedeutung sind. [...]

[Seite 45]

Diese Daten werden aus der organisatorischen Wissensbasis abgeleitet und dokumentiert, um im Prozess der Information einen Wissenstransfer zu anderen Wissensträgern zu ermöglichen. Damit Daten als unternehmensspezifische Daten klassifiziert werden können, müssen diese innerhalb von Informationsprozessen von Systemelementen der organisatorischen Wissensbasis - den Mitarbeitern - auf diese Eigenschaft hin überprüft werden.

Aus der in Kapitel 1 angedeuteten Dynamik der Veränderung des unternehmerischen Umfelds ist es besonders wichtig Überlegungen anzustellen, wie man die Aktualität der unternehmensrelevanten Daten sicherstellen kann.

Anmerkungen

Kein Hinweis auf die Quelle.

Sichter
(Klgn)

[6.] Analyse:Wdi/Fragment 077 01 - Diskussion
Bearbeitet: 21. January 2020, 07:48 Klgn
Erstellt: 21. January 2020, 07:46 (Klgn)
Fragment, KomplettPlagiat, SMWFragment, Schutzlevel, Unfertig, Wdi, Willfort 2001

Typus
KomplettPlagiat
Bearbeiter
Klgn
Gesichtet
No
Untersuchte Arbeit:
Seite: 77, Zeilen: 1-17
Quelle: Willfort 2001
Seite(n): 94, Zeilen: 10 ff.
4.2.8.4 Gegenüberstellung des sozialen und des technischen Subsystems

Anhand der Detailbeschreibung des sozialen und des technischen Subsystems können einige Analogien zwischen der Datenübertragung im technischen Subsystem und dem Wissenstransfer im sozialen Subsystem gezogen werden. Hervorzuheben ist, dass bei beiden Subsystemen letztendlich die Kommunikation nur auf der Ebene von Signalen stattfindet. Diese Erkenntnis kann damit in der Systemgestaltung, insbesondere für die Vernetzung technischer und sozialer Systemelemente genutzt werden. Von besonderer Relevanz ist auch die Analogie der standardisierten Schichten, Dienste und Protokolle und im technischen Subsystem zum Kontextwissen im sozialen System.

Während aber auf der technischen Seite der Kontext durch die sieben Schichten klar definiert ist und bereits vor dem ersten Verbindungsaufbau gegeben sein muss, kann auf der sozialen Seite nahezu jede beliebige Ausprägung des Kontextwissens durch Lernprozesse während der Kommunikation aufgebaut werden. Trotz dieser Analogien, die vorrangig vom technischen in den sozialen Bereich übertragen wurden, um damit dort eine plausible Funktionsdarstellung aufzeigen zu können, treffen zwei völlig unterschiedlich funktionierende Systeme aufeinander.

4.3.2 Gegenüberstellung des sozialen und des technischen Subsystems

Anhand der Detailbeschreibung des sozialen und des technischen Subsystems können einige Analogien zwischen der Datenübertragung im technischen Subsystem und dem Wissenstransfer im sozialen Subsystem gezogen werden. Hervorzuheben ist, dass bei beiden Subsystemen letztendlich die Kommunikation nur auf der Ebene von Signalen stattfindet. Diese Erkenntnis kann damit in der Systemgestaltung, insbesondere für die Vernetzung technischer und sozialer Systemelemente genutzt werden. Von besonderer Relevanz ist auch die Analogie der standardisierten Schichten, Dienste und Protokolle und im technischen Subsystem zum Kontextwissen im sozialen System.

Während aber auf der technischen Seite der Kontext durch die sieben Schichten klar definiert ist und bereits vor dem ersten Verbindungsaufbau gegeben sein muss, kann auf der sozialen Seite nahezu jede beliebige Ausprägung des Kontextwissens durch Lernprozesse während der Kommunikation aufgebaut werden. Trotz diese [sic] Analogien, die vorrangig vom technischen in den sozialen Bereich übertragen wurden, um damit dort eine plausible Funktionsdarstellung aufzeigen zu können, treffen zwei völlig unterschiedlich funktionierende Systeme aufeinander.

Anmerkungen

Kein Hinweis auf die Quelle.

Sichter
(Klgn)

[7.] Analyse:Wdi/Fragment 101 01 - Diskussion
Bearbeitet: 21. January 2020, 09:15 Klgn
Erstellt: 21. January 2020, 09:15 (Klgn)
Fragment, Pischon Iwanowitsch 1998, SMWFragment, Schutzlevel, Unfertig, Verschleierung, Wdi

Typus
Verschleierung
Bearbeiter
Klgn
Gesichtet
No
Untersuchte Arbeit:
Seite: 101, Zeilen: 1-13
Quelle: Pischon Iwanowitsch 1998
Seite(n): 326, 327, Zeilen: 326: 16 ff.; 327: 7 ff.
Echte Integration der Spezialmanagementsysteme ist nur möglich, wenn die Integrationsbemühungen deutlich über einen rein verbalen Informationsaustausch zwischen den Fachbereichen hinausgehen. Die Etablierung überlappender Arbeitskreise ermöglicht im Gegensatz zur ersten Stufe einen frühzeitigen, umfassenden Erfahrungsaustausch, der in der Regel zu gemeinsamen Projekten führt. Die dritte Kategorie der integrierten Richtlinien, Verfahrens- und/oder Arbeitsanweisungen beruht auf einer Integration einzelner Prozesse sowie Abläufe und stellt somit eine Integration im engeren Sinne dar. Bei einer organisatorischen Verankerung des integrierten Managementsystems ist es vorstellbar, dass ein Managementvertreter ausgewählt wird, der eine gemeinsame Führungsverantwortung für die integrierten Teilbereiche trägt. Eine noch weitreichendere Integration stellt die Ernennung eines Systemverantwortlichen dar, welcher die operative Verantwortung für das gesamte integrierte Managementsystem trägt. Alle fünf Stufen schließen sich gegenseitig nicht aus und können im Laufe des Integrationsprozesses nacheinander durchschritten werden. [Seite 326]

Es handelt sich bei der Verbindung dieser Teilmanagementsysteme nur dann um eine echte Integration, wenn aus diesen Aktivitäten konkrete Verbesserungen zu den separaten Lösungen erzielt werden können. Dies ist nur möglich, wenn die Integrationsbemühungen deutlich über einen rein verbalen Informationsaustausch zwischen den Fachbereichen hinausgehen. Die Etablierung überlappender Arbeitskreise ermöglicht im Gegensatz zur ersten Stufe einen frühzeitigen, umfassenden Erfahrungsaustausch, der in der Regel zu gemeinsamen Projekten führt, in die wiederum gegenseitige Erfahrungen einfließen. Die dritte Kategorie der integrierten Richtlinien, Verfahrens- und/oder Arbeitsanweisungen beruht auf einer Integration einzelner Prozesse sowie Abläufe und stellt somit eine Integration im engeren Sinne dar.

[Seite 327]

Bei einer organisatorischen Verankerung des IMS ist es vorstellbar, daß ein Managementvertreter ausgewählt wird, der eine gemeinsame Führungsverantwortung für die integrierten Teilbereiche trägt. Eine noch weitreichendere Integration stellt die Ernennung eines Systemverantwortlichen dar, welcher die operative Verantwortung für das gesamte IMS trägt (Felix, R., Pischon, A., Riemenschneider, F. und Schwerdtle, H., 1997, S. 83). Alle fünf Stufen schließen sich gegenseitig nicht aus und können im Laufe des Integrationsprozesses nacheinander durchschritten werden.

Anmerkungen

Kein Hinweis auf die Quelle.

Sichter
(Klgn)

[8.] Analyse:Wdi/Fragment 132 01 - Diskussion
Bearbeitet: 22. January 2020, 13:50 Klgn
Erstellt: 22. January 2020, 13:50 (Klgn)
Fragment, Hartlieb 2002, SMWFragment, Schutzlevel, Unfertig, Verschleierung, Wdi

Typus
Verschleierung
Bearbeiter
Klgn
Gesichtet
No
Untersuchte Arbeit:
Seite: 132, Zeilen: 1 ff. (komplett)
Quelle: Hartlieb 2002
Seite(n): 156, 157, 158, Zeilen: 156: letzter Absatz; 157: Abbildung, 1 ff.; 158: 1 ff.
5.3.6.1 Abbildung der relevanten Transferbeziehungen

Ausgangspunkt für die Abbildung der Transferbeziehungen sind die Analyseergebnisse über das Wissens- und Daten-Angebot, abgebildet in der Datenbank der Wissensgebiete. Daraus kann man die Transferbeziehungen, definiert durch Sender und Empfänger, ableiten.

In Abbildung 5-18 sind die Transferbeziehungen, ausgehend von einem betrachteten Empfangsort, im Wissenssystem dargestellt.

[Abbildung]

Abbildung 5-18: Transferbeziehungen im Wissenssystem


Als Empfangsort (e1) ist hier ein Arbeitsplatz mit folgender Ausgangssituation beschrieben:

  • Mitarbeiter (M3) als Wissensempfänger,
  • Technisches Subsystem (T3) als Datenempfänger,
  • Engineering Aufgabenstellung,
  • Bedarf an Wissen und Daten.

Ausgehend von einem Empfangsort können nun die Transferbeziehungen abgebildet werden. Sehr oft ist ein Empfangsort nur durch einen Mitarbeiter als Wissens-Empfänger dargestellt. Hier soll der Sonderfall beschrieben werden, dass sich am Empfangsort ein Mitarbeiter und ein PC befinden. Am Sendeort (s1) befindet sich das relevante Wissens-Angebot (M2), z.B. ein Experte, der hier als Wissens-Sender auftritt. Am Sendeort (s2) befindet sich das relevante Daten-Angebot (T1), z.B. eine Datenbank, die hier als Daten-Sender auftritt.

Daraus lassen sich schon die Transferbeziehungen ableiten. Zwischen Wissensempfänger (M3, e1) und Wissens-Sender (M2, s1) finden Wissenstransfers statt. Zwischen Daten-Empfänger (T3, e1) und Daten-Sender (T1, s2) finden Datentransfers statt.

Handlungs-Transfers sollen hier nicht betrachtet werden. Dabei geht es im Wesentlichen um den vollständigen Ausgleich von Bedarf und Angebot unter Berücksichtigung des Qualifikationsprofils eines Mitarbeiters. Hier steht vor allem die Betrachtung der Transfers auf Wissens- und Daten-Ebene sowie das Mensch/Aufgabe/Technik-System im Mittelpunkt.

[Seite 156]

5.3.6.1 Abbildung der relevanten Transferbeziehungen

Ausgangspunkt für die Abbildung der Transferbeziehungen sind die Analyseergebnisse über das Wissens- und Daten-Angebot, abgebildet in der Datenbank der Wissensgebiete. Daraus kann man die Transferbeziehungen, definiert durch Sender und Empfänger, ableiten. In Abbildung 5.19 sind die Transferbeziehungen, ausgehend von einem betrachteten Empfangsort, im Wissenssystem dargestellt.

[Seite 157]

[Abbildung]

Abbildung 5.19: Transferbeziehungen im Wissenssystem

Als Empfangsort (e1) ist hier ein Arbeitsplatz mit folgender Ausgangssituation beschrieben:

  • Mitarbeiter (M3) als Wissensempfänger,
  • Technisches Subsystem (T3) als Datenempfänger,
  • Betriebliche Aufgabenstellung,
  • Bedarf an Wissen und Daten.

Ausgehend von einem Empfangsort können nun die Transferbeziehungen abgebildet werden. Sehr oft ist ein Empfangsort nur durch einen Mitarbeiter als Wissens-Empfänger dargestellt. Hier soll der Sonderfall beschrieben werden, dass sich am Empfangsort ein Mitarbeiter und ein PC befinden.

Am Sendeort (s1) befindet sich das relevante Wissens-Angebot (M2), z.B. ein Experte, der hier als Wissens-Sender auftritt. Am Sendeort (s2) befindet sich das relevante Daten-Angebot (T1), z.B. eine Datenbank, die hier als Daten-Sender auftritt. Daraus lassen sich schon die Transferbeziehungen ableiten. Zwischen Wissens-

[Seite 158]

empfänger (M3, e1) und Wissens-Sender (M2, s1) finden Wissenstransfers statt. Zwischen Daten-Empfänger (T3, e1) und Daten-Sender (T1, s2) finden Datentransfers statt.

Handlungs-Transfers sollen hier nicht betrachtet werden. Dabei geht es im Wesentlichen um den vollständigen Ausgleich von Bedarf und Angebot unter Berücksichtigung des Qualifikationsprofils eines Mitarbeiters. Hier steht vor allem die Betrachtung der Transfers auf Wissens- und Daten-Ebene sowie der Schnittstellenbeziehung zwischen Mensch und Maschine (z.B. Mensch und PC) im Mittelpunkt.

Anmerkungen

Kein Hinweis auf die Quelle.

Sichter
(Klgn)

[9.] Analyse:Wdi/Fragment 133 01 - Diskussion
Bearbeitet: 24. January 2020, 08:03 Klgn
Erstellt: 24. January 2020, 08:03 (Klgn)
Fragment, Hartlieb 2002, SMWFragment, Schutzlevel, Unfertig, Verschleierung, Wdi

Typus
Verschleierung
Bearbeiter
Klgn
Gesichtet
No
Untersuchte Arbeit:
Seite: 133, Zeilen: 1-20, 23-26
Quelle: Hartlieb 2002
Seite(n): 139, 140, 158, Zeilen: 139: 8 ff.; 140: 10 ff.; 158: 12 ff.
5.3.6.2 Analyse der Transferbeziehungen

Wie bereits an anderer Stelle ausführlich beschrieben, ist Wissen an Personen gebunden. Erst durch die Anwendung des Wissens durch eine Person kann ein Beobachter auf das Wissen dieser Person schließen. Daher ist es auch schwierig, Wissenstransfers zu analysieren.

Daraus folgt, dass die Wissenstransfers nur indirekt, über die Befragung von den Wissensträgern (Sender) und den Wissensnachfragern (Empfänger), analysiert werden können. Bei der Analyse der Datentransfers geht es im Wesentlichen um die Schnittstellen-Beziehungen zwischen zwei technischen Systemen.

Ein wesentlicher Untersuchungsbereich ist die Transferbeziehung zwischen Mensch und Maschine (z.B. M3 und T3), welche hier noch gesondert betrachtet werden soll. Hier findet eine Koppelung zwischen Wissens-Ebene und Daten-Ebene statt. In Anlehnung an die Ebenen-Betrachtung für Wissenssysteme wird diese Koppelung durch die Prozesse „Dokumentation“ und „Information“ beschrieben. Diese Betrachtung ist insofern wesentlich, da die meisten Arbeitsplätze eine Mensch/Aufgabe/Technik-System darstellen.

5.3.7 Anwendung des woEDM

Der Prozess der Anwendung, also das Ausführen einer Entwicklungsaufgabe, schließt den Kreislauf des operativen Engineering Data Managements. Vielfach wird auch von Wissensgebrauch gesprochen, da sich bekanntlich Wissen durch Anwendung nicht verbraucht.

Jede Anwendung liefert wiederum neue Erfahrungen, welche durch Beurteilung der Qualität und Verfügbarkeit der Daten als kontinuierliche Verbesserung an die EDM Entwicklung und Gestaltung zurückgeführt werden müssen.

Die Anwendung schließt den Kreislauf der operativen Dimension des EDM. Nach der Beschreibung der operativen EDM-Prozesse geht es im nächsten Schritt um Sicherstellung der effektiven und effizienten Durchführung dieser Prozesse. Dazu muss ein Instrumentarium zur Analyse der operativen EDM-Prozesse entwickelt werden.

[Seite 158]

5.3.6.2 Analyse der Transferbeziehungen

Wie bereits an anderer Stelle ausführlich beschrieben, ist Wissen an Personen gebunden. Erst durch die Anwendung des Wissens durch eine Person kann ein Beobachter auf das Wissen dieser Person schließen. Daher ist es auch schwierig Wissenstransfers zu analysieren.

Daraus folgt, dass die Analyse von Wissens-Transfers nur indirekt, über die Befragung von den Wissensträgern (Sender) und den Wissensnachfragern (Empfänger) analysiert werden können. [...]

Bei der Analyse der Datentransfers geht es im Wesentlichen um die Schnittstellen-Beziehungen zwischen zwei technischen Systemen. [...]

Ein wesentlicher Untersuchungsbereich ist die Transferbeziehung zwischen Mensch und Maschine (z.B. M3 und T3), welche hier noch gesondert betrachtet werden soll. Hier findet eine Koppelung zwischen Wissens-Ebene und Daten-Ebene statt. In Anlehnung an die Ebenen-Betrachtung für Wissenssysteme wird diese Koppelung durch die Prozesse „Dokumentation“ und „Information“ beschrieben. Diese Betrachtung ist insoferne wesentlich, als die meisten Arbeitsplätze eine Kombination von Mensch-Maschine (Mensch-PC) aufweisen.

[Seite 139]

5.3.4 Anwendung

Der Prozess der Anwendung, also das Ausführen einer betrieblichen Handlung, schließt den Kreislauf der operativen Wissenslogistik. Vielfach wird auch von Wissensgebrauch gesprochen, da sich bekanntlich Wissen durch Anwendung nicht verbraucht.

[Seite 140]

Jede Anwendung liefert wiederum neue Erfahrungen. D.h. die Durchführung einer Handlung verursacht wiederum einen Lernprozess. Die Erfahrung ist somit der beste Lehrmeister. Jeder ausgelöste Lernprozess verändert die organisatorische Wissensbasis, also das Wissens-Angebot.

Die Anwendung schließt den Kreislauf der operativen Dimension der Wissenslogistik. Nach der Beschreibung der operativen Wissenslogistik-Prozesse geht es im nächsten Schritt um Sicherstellung der effektiven und effizienten Durchführung dieser Prozesse. Dazu muss zum einen ein Instrumentarium zur Analyse der operativen Wissenslogistik-Prozesse entwickelt werden.

Anmerkungen

Kein Hinweis auf die Quelle.

Sichter
(Klgn)

[10.] Analyse:Wdi/Fragment 141 31 - Diskussion
Bearbeitet: 22. January 2020, 10:22 Klgn
Erstellt: 22. January 2020, 10:18 (Klgn)
Fragment, Hartlieb 2002, SMWFragment, Schutzlevel, Unfertig, Verschleierung, Wdi

Typus
Verschleierung
Bearbeiter
Klgn
Gesichtet
No
Untersuchte Arbeit:
Seite: 141, Zeilen: 31 ff.
Quelle: Hartlieb 2002
Seite(n): 141, Zeilen: 1 ff.
6.1.2 Analyse und Rekonstruktion des Wissens- und Datenangebots

Bei der Analyse des Wissens-Angebots geht es um die Analyse der organisatorischen Wissensbasis. Bei der Analyse des Daten-Angebots geht es um die Analyse der Datenbasis.

Durch eine strukturierte Erfassung und Abbildung können somit die Wissens- und Datenpotentiale rekonstruiert werden, um für den jeweiligen Untersuchungsbereich Transparenz über die Wissens- und Datenpotentiale zu schaffen. Eine solche Analyse muss zumindest einmal durchgeführt werden, darauf aufbauend müssen die Analysedaten laufend aktualisiert werden und in die Entwicklung von EDM eingebracht werden.

Den Ausgangspunkt für die Analyse der organisatorischen Wissens- und Datenbasis bilden die von einer Unternehmung durchzuführenden Aufgaben, um Kundenbedürfnisse zu befriedigen.

[Seite 141]

5.3.5 Analyse und Rekonstruktion des Wissens- und Datenangebots

Bei der Analyse des Wissens-Angebots geht es um die Analyse der organisatorischen Wissensbasis. Bei der Analyse des Daten-Angebots geht es um die Analyse der Datenbasis.

Durch eine strukturierte Erfassung und Abbildung können somit die Wissens- und Datenpotentiale rekonstruiert werden, um für den jeweiligen Untersuchungsbereich Transparenz über die Wissens- und Datenpotentiale zu schaffen. Eine solche Analyse muss zumindest einmal durchgeführt werden, darauf aufbauend müssen die Analysedaten laufend aktualisiert werden.

5.3.5.1 Vorgehen bei der Analyse des Wissens- und Daten-Angebots

Den Ausgangspunkt für die Analyse der organisatorischen Wissens- und Datenbasis bilden die von einer Unternehmung durchzuführenden Aufgaben, um Kundenbedürfnisse zu befriedigen.

Anmerkungen

Kein Hinweis auf die Quelle.

Sichter
(Klgn)

[11.] Analyse:Wdi/Fragment 142 01 - Diskussion
Bearbeitet: 22. January 2020, 08:44 Klgn
Erstellt: 22. January 2020, 08:44 (Klgn)
Fragment, Hartlieb 2002, SMWFragment, Schutzlevel, Unfertig, Verschleierung, Wdi

Typus
Verschleierung
Bearbeiter
Klgn
Gesichtet
No
Untersuchte Arbeit:
Seite: 142, Zeilen: 1-21
Quelle: Hartlieb 2002
Seite(n): 141, 146, 147, Zeilen: 141: 14 ff.; 146: 12 ff.; 147: 1 ff.
Dazu muss die vorerst beschriebene Prozessanalyse durchgeführt werden. Nun können einerseits die Analyse des Wissens-Bedarfs und -Angebots und andererseits die Analyse des Daten-Bedarfs und -Angebots erfolgen.

Für diese Analyse ist zunächst für jede Tätigkeit jenes Wissen zu ermitteln, das für die Durchführung erforderlich ist. Aufbauend auf den Wissensinhalten sind die Wissensträger, die über dieses Wissen verfügen, zu erfassen. Auch bei den Wissensträgern sollten die zugehörigen Abteilungen unbedingt miterfasst werden. Der verantwortliche Abteilungsleiter muss in ungeklärten Fällen die Funktion eines Wissensbrokers übernehmen und stellt damit das Bindeglied zu den Wissensträgern dar. Die erfassten Wissensinhalte sollten Kategorien bzw. Wissensgebieten zugewiesen werden, damit in weiterer Folge mit den gesammelten Daten eine Wissenskarte erstellt werden kann. Den Aufgabenträgern stehen nicht für alle Aufgaben Wissensträger für die Abdeckung ihres Wissensbedarfs zur Verfügung. Dies ist einerseits durch begrenzte Personalkosten bedingt, andererseits kann bei vorhandenem Kontextwissen das für die Aufgabenerfüllung erforderliche Wissen auch aus den relevanten Daten zum betreffenden Wissensgebiet generiert werden.

Für die Gestaltung von Wissenstransfers durch Wissensgenerierung aus Daten müssen die aufgabenspezifischen Daten, d.h. die organisatorische Datenbasis, ermittelt werden. Hierbei muss zuerst analysiert werden, welche Daten für die aufgabenspezifische Wissensgenerierung erforderlich sind. Des Weiteren muss untersucht werden, in welcher Form (Papier, EDV) die Daten vorliegen und auf welchen Datenträgern bzw. -systemen (Dokumentation, Datenbank, EDV-System,...) diese Daten gespeichert sind.

[Seite 141]

Somit muss zuerst eine Prozessanalyse durchgeführt werden. Im Anschluss daran kann einerseits die Analyse des Wissens-Bedarfs und -Angebots und andererseits die Analyse des Daten-Bedarfs und -Angebots erfolgen.

[Seite 146]

Analyse von Wissens-Bedarf und Wissens-Angebot

Für diese Analyse ist zunächst für jede Tätigkeit jenes Wissen zu ermitteln, das für die Durchführung erforderlich ist. Aufbauend auf den Wissensinhalten sind die Wissensträger, die über dieses Wissen verfügen, zu erfassen. Auch bei den Wissensträgern sollten die zugehörigen Abteilungen unbedingt miterfasst werden. Der verantwortliche Abteilungsleiter muss in ungeklärten Fällen die Funktion eines Wissensbrokers übernehmen und stellt damit das Bindeglied zu den Wissensträgern dar. [...]

Die erfassten Wissensinhalte sollten Kategorien bzw. Wissensgebieten zugewiesen werden, damit in weiterer Folge mit den gesammelten Daten eine Wissenskarte erstellt werden kann. [...]

Analyse des Daten-Bedarfs und -Angebots

Den Aufgabenträgern stehen nicht für alle Aufgaben Wissensträger für die Abdeckung ihres Wissensbedarfs zur Verfügung. Dies ist einerseits durch begrenzten [sic]

[Seite 147]

Personalkosten bedingt, andererseits kann bei vorhandenem Kontextwissen das für die Aufgabenerfüllung erforderliche Wissen auch aus den relevanten Daten zum betreffenden Wissensgebiet generiert werden. [...]

Für die Gestaltung von Wissenstransfers durch Wissensgenerierung aus Daten müssen die aufgabenspezifischen Daten, d.h. die organisatorische Datenbasis, ermittelt werden. Hierbei muss zuerst analysiert werden, welche Daten für die aufgabenspezifische Wissensgenerierung erforderlich sind.

Weiters muss untersucht werden, in welcher Form (Papier, EDV) die Daten vorliegen und auf welchen Datenträgern bzw. -Systemen (Dokumentation, Datenbank, EDV-System,...) diese Daten gespeichert sind.

Anmerkungen

Kein Hinweis auf die Quelle.

Sichter
(Klgn)

[12.] Analyse:Wdi/Fragment 173 09 - Diskussion
Bearbeitet: 19. January 2020, 11:33 Klgn
Erstellt: 19. January 2020, 11:24 (Klgn)
BauernOpfer, Fragment, SMWFragment, Scheer et al. 2006, Schutzlevel, Unfertig, Wdi

Typus
BauernOpfer
Bearbeiter
Klgn
Gesichtet
No
Untersuchte Arbeit:
Seite: 173, Zeilen: 9 ff.
Quelle: Scheer et al. 2006
Seite(n): 27, 28, Zeilen: 27: 1. u. 2 Absatz; 28: 1 ff.
6.4.1 Ansatz zur prozessorientierten Integration von EDM 189

EDM ist eine Strategie, die auf alle Prozesse und Daten rund um das Produkt fokussiert. Daher orientiert sie die Auswahl und Ausgestaltung der EDM-Bausteine an den im jeweiligen Betrachtungsbereich liegenden Prozessen. Um EDM effizient und zielgerichtet realisieren zu können, ist daher durchwegs ein prozessorientierter Ansatz zu empfehlen.

Eine an Funktionen orientierte Vorgehensweise, die in der Vergangenheit beispielsweise bei Einführung von CAD noch propagiert wurde, ist bei EDM nicht zielführend, da sie das Produkt selbst nicht in das Zentrum der Betrachtung setzt. Für EDM charakteristisch ist, dass einerseits das Produkt selbst mit Entwicklung, Produktion, Distribution und Service im Mittelpunkt steht und anderseits Ausgangspunkt und Ziel aller Prozesse auf oberster Ebene der Kunde ist. Das bedeutet dass der gesamte PEP den ein Produkt durchläuft mit EDM abgedeckt werden muss und dabei alle durchlaufenden Funktionen und Organisationsbereiche ebenso integriert werden wie die spezifischen IT-Systeme.

Zentraler Bestandteil eines prozessorientierten EDM-Ansatzes ist immer die Definition einer übergeordneten EDM-Strategie. Diese Strategie ist Dreh- und Angelpunkt für die spezifische Ausgestaltung eines EDM-Prozess-Regelkreises bestehend aus:

  • EDM-Strategie
  • EDM-Prozess-Design
  • EDM-Prozess-Implementierung
  • EDM-Prozess-Controlling

Eine definierte EDM-Strategie legt die Ziele und Randbedingungen für ein EDM-Prozess-Design fest. Des Weiteren werden in der Strategiephase Kenngrößen ermittelt oder vorgegeben, die in der darauf folgenden Design-Phase spezifiziert werden. Die EDM-Prozess-Implementierung bildet unter Berücksichtigung der festgelegten Strategie die in der Design-Phase definierten Ziel-Prozesse in einer zuvor ausgewählten IT-Systemlandschaft ab. Im EDM-Prozess-Controlling werden nun die in der Strategie festgelegten und in der Design-Phase ausspezifizierten Kenngrößen auf der Basis der Implementierung gemessen und gesteuert.

Die Ergebnisse sind wiederum Eingangswerte für eine Optimierungsschleife mit erneutem Start der Design-Phase. Die Ergebnisse aller Phasen finden ebenfalls eine Rückkopplung zur Strategie, um die Vorgaben zu verifizieren bzw. die Vorgaben der sich fortentwickelnden Randbedingungen eines Unternehmens und eines EDM-Projektes anzupassen.


189 Vgl. SCHEER u. a. [2005], S. 27ff

[Seite 27]

3 Bausteine und Prozesse im PLM

3.1 Ein prozessorientierter PLM-Ansatz

[...]

Produkt-Lebenszyklus-Management ist eine Strategie, die auf alle Prozesse rund um das Produkt fokussiert. Daher orientiert sich die Auswahl und Ausgestaltung der PLM-Bausteine an den im jeweiligen Betrachtungsbereich liegenden Prozessen; daher setzt sich eine PLM-Lösung eines entwicklungsorientierten Unternehmens aus anderen PLM-Bausteinen zusammen wie die eines Unternehmens mit Schwerpunkt im Service-Bereich. Um PLM effizient und zielgerichtet realisieren zu können, ist daher durchweg ein prozessorientierter Ansatz zu empfehlen.

Eine an Funktionen orientierte Vorgehensweise, die in der Vergangenheit beispielsweise bei der Einführung von CAD noch propagiert wurde, ist bei PLM nicht zielführend, da sie das Produkt selbst nicht in das Zentrum der Betrachtung setzt. Für PLM charakteristisch ist, dass einerseits das Produkt selbst mit Entwicklung, Produktion, Distribution und Service im Mittelpunkt steht und andererseits Ausgangspunkt und Ziel aller Prozesse auf oberster Ebene der Kunde ist. Das be-

[Seite 28]

deutet, dass die gesamte Prozesskette, die ein Produkt durchläuft, mit PLM abgedeckt werden muss, und dabei alle durchlaufenen Funktionen und Organisationsbereiche ebenso integriert werden wie die spezifischen IT-Systeme.

Zentraler Bestandteil eines prozessorientierten PLM-Ansatzes ist immer die Definition einer übergeordneten PLM-Strategie. Diese Strategie ist Dreh- und Angelpunkt für die spezifische Ausgestaltung eines PLM-Prozess-Regelkreises. Dieser Regelkreis ist in Abb. 14 dargestellt und besteht aus den 4 Bestandteilen:

  • PLM-Strategie
  • PLM-Prozess-Design
  • PLM-Prozess-Implementierung
  • PLM-Prozess-Controlling

Eine definierte PLM-Strategie legt die Zielsetzungen und Randbedingungen für ein PLM-Prozess-Design fest. Des Weiteren werden in der Strategiephase Kenngrößen ermittelt oder vorgegeben, die in der darauf folgenden Design-Phase spezifiziert und in eine Metrik transferiert werden, sofern die Kenngrößen quantifizierbar sind. Die PLM-Implementierung bildet unter Berücksichtigung der festgelegten Strategie die in der Design-Phase definierten Ziel-Prozesse in einer zuvor ausgewählten IT-Systemlandschaft ab. In der Controlling- oder Steuerungs-Phase werden nun die in der Strategie festgelegten und in der Design-Phase ausspezifizierten Kenngrößen auf der Basis der Implementierung gesteuert und gemessen. Die Ergebnisse sind wiederum Eingangswerte für eine Optimierungsschleife mit erneutem Start der Design-Phase. Die Ergebnisse aller Phasen finden ebenfalls eine Rückkopplung zur Strategie, um die Vorgaben zu verifizieren bzw. die Vorgaben den sich fortentwickelnden Randbedingungen eines Unternehmens und eines PLM-Projektes anzupassen.

Anmerkungen
Sichter
(Klgn)

[13.] Analyse:Wdi/Fragment 174 01 - Diskussion
Bearbeitet: 19. January 2020, 14:27 Klgn
Erstellt: 19. January 2020, 14:00 (Klgn)
BauernOpfer, Fragment, SMWFragment, Scheer et al. 2006, Schutzlevel, Unfertig, Wdi

Typus
BauernOpfer
Bearbeiter
Klgn
Gesichtet
No
Untersuchte Arbeit:
Seite: 174, Zeilen: 1 ff.
Quelle: Scheer et al. 2006
Seite(n): 28, 29, 30, 31, Zeilen: 28, 29, 30, 31
6.4.1.1 EDM-Strategie

Die Schwerpunkte der EDM-Strategie unterscheiden sich in der Regel nach den verschiedenen Branchen, nach der Quelle der Wertschöpfung eines Unternehmens, aber auch nach der aktuellen Situation, in der sich ein Unternehmen befindet, dem Entwicklungsstand seiner Prozesse sowie dem Integrationsgrad der unterstützenden IT-Systeme.

Exemplarisch seien hier einige EDM-Strategien angeführt:

  • Harmonisierung unternehmensweiter Produktentwicklungs-Prozesse infolge eines Zusammenschlusses von Unternehmen
  • Optimierung der produktzentrierten Prozesse aufgrund veränderter Randbedingungen, wie z.B. Einsatz neuer Technologien in den Produkten, neue oder geänderte Kunden- und Marktanforderungen, Weiterentwicklung des Unternehmens vom Teilezulieferer zum Systemlieferanten
  • RE-Strukturierung eines Unternehmens in eigenverantwortliche Geschäftsbereiche mit eigenen internen Prozessen und Systemen, aber definierten Standards und Prozess-Schnittstellen
  • Harmonisierung des unternehmensweiten Produktspektrums mit einhergehender Zentralisierung des Produktdatenmanagements
  • Strategische Ausrichtung des Unternehmens auf eine einheitliche IT-Infrastruktur mit entsprechenden Systemwechseln
  • Konzentration auf die Kernprozesse und Schlüsselprodukte des Unternehmens mit einhergehendem Outsourcing der nicht mehr im Fokus befindlichen Bereiche
  • Verstärkung der unternehmensübergreifenden Zusammenarbeit und engere Anbindung an Partner

Die EDM-Strategie prägt folglich die Schlüsselfaktoren für den gesamten Geschäftsprozess aus. Neben der eigentlichen Prozessdefinition ist die Definition von Messgrößen und deren Quantifizierung vorteilhaft, um den Projekterfolg zu messen und die Ziele auf ihren Erreichungsgrad hin zu verifizieren.

Typische EDM-Messgrößen sind zum Beispiel:

  • Kosten eines Prozessschrittes und in der Summation Kosten eines Prozesses (Änderung am Produkt, Prototypen, Simulation)
  • Zeit für die Vorbereitung, Durchführung und Nachbereitung einer Aktivität und eines Prozesses; dabei kann Vor- und Nachbereitung die Transformation von Daten oder Transportzeit bedeuten. Wichtig ist in diesem Zusammenhang auch die Aufnahme von Liege- und Wartezeiten (Detailkonstruktion, Datenkonvertierung, Datentransfer und Datenaufbereitung, Rechenzeit für Simulationen, Aufbereitung von VR-Studien).
  • Anzahl der zu durchlaufenden Schleifen und Wiederholungen
  • Anzahl der involvierten Personen und Organisationseinheiten
  • Anzahl der zu nutzenden Systeme, Informationsquellen oder Datenqualität sowie des damit verbundenen Aufwands
  • Anzahl der Input-/Output-Dokumente
  • Anzahl der Aktivitäten einer Person oder Stelle
  • Mengengerüste über Anzahl der Prozessdurchläufe und Anzahl der verschiedenen Produkte
[Seite 28]

3.1.1 PLM-Strategie

Die Schwerpunkte der PLM-Strategien unterscheiden sich in der Regel nach den verschiedenen Branchen, nach der Quelle der Wertschöpfung eines Unternehmens, aber auch nach der aktuellen Situation, in der sich ein Unternehmen befindet, dem Entwicklungsstand seiner Prozesse sowie dem Integrationsgrad der unterstützenden IT-Systeme. Exemplarisch seien hier einige PLM-Strategien angeführt:

  • Harmonisierung unternehmensweiter Produktentwicklungs-Prozesse infolge eines Zusammenschlusses von Unternehmen
  • Optimierung der produktzentrierten Prozesse aufgrund veränderter Randbedingungen, wie z. B. Einsatz neuer Technologien in den Produkten, neue oder geänderte Kunden- und Marktanforderungen, Weiterentwicklung des Unternehmens vom Teilezulieferer zum Systemlieferanten

[Seite 29]

  • Re-Strukturierung eines Unternehmens in eigenverantwortliche Geschäftsbereiche (je Geschäftsfeld oder Funktion) mit eigenen internen Prozessen und Systemen, aber definierten Standards an den Prozess-Schnittstellen
  • Harmonisierung des unternehmensweiten Produktspektrums mit einhergehender Zentralisierung des Stammdaten-Managements
  • Strategische Ausrichtung des Unternehmens auf eine einheitliche IT-Infrastruktur mit entsprechenden Systemwechseln
  • Konzentration auf die Kernprozesse und Schlüsselprodukte des Unternehmens mit einhergehendem Outsourcing der nicht mehr im Fokus befindlichen Bereiche
  • Verstärkung der unternehmensübergreifenden Zusammenarbeit und engere Anbindung der Partner (insbesondere im Rahmen von Globalisierung)

Die PLM-Strategie prägt folglich die Schlüsselfaktoren für den gesamten Geschäftsprozess-Lebenszyklus aus. [...]

Neben der eigentlichen Prozessdefinition ist die Definition von Kennzahlen und deren Quantifizierung unerlässlich, um den Projekterfolg zu messen und die Ziele auf ihren Erreichungsgrad hin zu verifizieren.

Typische PLM-Prozesskennzahlen sind beispielsweise:

  • Kosten eines Prozessschrittes und in der Summation Kosten eines Prozesses.
Beispiele:
- Kosten für eine Änderung am Produkt
- Kosten für ein Produkt über einen Zeitraum hinweg inkl. der Kosten aller bis dahin aufgelaufenen Änderungen
- Kosten für einen Prototypen
- Kosten für eine Simulation
- Kosten für eine Vorserienstudie
  • Zeit für die Vorbereitung, Durchführung und Nachbereitung einer Aktivität und eines Prozesses; dabei kann Vor- und Nachbereitung die Transformation von Daten oder Transportzeit bedeuten. Wichtig ist in diesem Zusammenhang auch die Aufnahme von Liege- und Wartezeiten.
Beispiel:
- Zeit für die Detailkonstruktion
- Zeit für Datenkonvertierung, Datentransfer und Datenaufbereitung

[Seite 30]

- Rechenzeit für Simulationen
- Zeit für die Aufbereitung von VR-Studien
  • Anzahl der zu durchlaufenden Schleifen (z. B. im Rahmen eines Prüfprozesses) und Wiederholungen.
Beispiele:
- Anzahl von Änderungsdurchläufen
- Anzahl von Rückweisungen bei einer Freigabe
- Anzahl von iterativen Berechnungen und Simulationen aufgrund von Design-Änderungen
  • Anzahl der involvierten Personen und Organisationseinheiten.
Beispiele:
- Einbindung externer Ressourcen für neue Fertigungstechnologien
- Organisation in virtuellen Design-Teams
- Einbindung von zentralem Einkauf, Qualitätsmanagement und Normung in Freigabeprozess für Produktänderungen
  • Anzahl der zu nutzenden Systeme, Informationsquellen oder Datenqualität etc. sowie des damit verbundenen Aufwands.
Beispiele:
- Einsatz verschiedener CAD-Systeme in Produkt- und Sondermaschinenkonstruktion verbunden mit der Notwendigkeit, Schnittstellenprogramme zu nutzen und Datenverlust während der Konvertierung in Kauf zu nehmen
- Nutzung unterschiedlicher Normteilkataloge an verschiedenen Standorten und in verschiedenen Ländern mit der Folge, dass ein zentraler Einkauf Anfragen nicht bündeln kann
- Hohe Stammdatenqualität für reibungslosen Übergang von Entwicklung zu Logistik
  • Anzahl und Umfang der Input-/Output-Dokumente, CAD-Modelle, Spezifikationen etc.
Beispiele:
- CAD-Modell mit angehängten Zeichnungen
- Vom CAD-Modell abgeleitete Neutralformate
  • Risikoquantifizierung eines Prozesses mit Unterteilung in rechtliche, kaufmännische, konstruktive, produktionstechnische, organisatorische und logistische Risiken.
Beispiele:
- Personalbesetzung eines Entwicklungsprojektes
- Projektklassifizierung in Neuentwicklung, Anpassungs-, Variantenkonstruktion

[Seite 31]

- Produktkonfiguration mit Entscheidung über den anzuwendenden Projektplan und Anzahl der zu durchlaufenden Quality Gates oder Meilensteine
- Risiko-Management innerhalb eines Projektes
  • Die Anzahl an Aktivitäten einer Person oder Stelle.
Beispiele:

[...]

  • Mengengerüste über Anzahl der Prozessdurchläufe und Anzahl der verschiedenen Produkte.
Anmerkungen

TO DO: kürzen

Sichter
(Klgn)

[14.] Analyse:Wdi/Fragment 175 01 - Diskussion
Bearbeitet: 19. January 2020, 14:44 Klgn
Erstellt: 19. January 2020, 14:34 (Klgn)
BauernOpfer, Fragment, SMWFragment, Scheer et al. 2006, Schutzlevel, Unfertig, Wdi

Typus
BauernOpfer
Bearbeiter
Klgn
Gesichtet
No
Untersuchte Arbeit:
Seite: 175, Zeilen: 1 ff. (?)
Quelle: Scheer et al. 2006
Seite(n): 31, 32, 33, Zeilen: 31, 32, 33
6.4.1.2 EDM-Prozess-Design

Die im Rahmen der EDM-Strategie festgelegten Prozess-Ziele fließen unmittelbar in die Soll-Prozess-Definition ein. Dabei ergeben sich die Potentiale sowohl aus den quantitativen messbaren Prozesskennzahlen als auch aus nicht-quantifizierbaren Faktoren, wie Möglichkeiten zur Produktverlagerung, Job-Rotation oder Innovationsfähigkeit.

Beim Prozess-Design werden in der Regel die Prozesse entsprechend ihrem Beitrag zur Wertschöpfung eines Unternehmens eingeteilt in:

  • Kernprozesse
  • Management-Prozesse
  • Support-Prozesse

Die Kernprozesse umfassen in dem hier beschriebenen Kontext die eigentlich wertschöpfenden Prozesse im Sinne von End-to-End-Prozessen, d.h. die Prozesse beginnen beim Kunden und enden wiederum dort. Der Produktlebenszyklus beginnt beispielsweise mit der Kundenanfrage, erstreckt sich über Spezifikation, Design, Konstruktion, Berechnung bis hin zur Arbeitsvorbereitung, Fertigung und Montage und endet nach der Qualitätsprüfung mit der Lieferung und der Abnahme beim Kunden.

Management-Prozesse steuern im Sinne der festgelegten EDM-Strategie diese EDM-Kernprozesse. So wird beispielsweise die Produktpalette mit Hilfe eines PortfolioManagements optimiert, so dass eine Unternehmensentwicklung vom Teilezulieferer zum Systemzulieferer erfolgen kann. Die Risikobetrachtung eines Projektes fließt in das Projektmanagement ein und das Innovationsmanagement beeinflusst im Wesentlichen die frühen Phasen der Produktentwicklung. Die Support-Prozesse unterstützen dabei die EDM Kernprozesse.

6.4.1.3 EDM-Prozess-Implementierung

Auf Basis einer Prozessdefinition kann dann eine Evaluierung in Frage kommender Systemlösungen durchgeführt werden. Während beispielsweise in der Vergangenheit bei der CAD-Systemauswahl funktionale Aspekte eine tragende Rolle spielten, tritt bei der EDM-Systemauswahl die durchgängige Unterstützung der definierten Soll-Prozesse in den Vordergrund. Dabei konzentriert sich die Prozessunterstützung auf die in den Prozessen festgehaltenen und mit Kennzahlen versehenen Anforderungen, die identifizierten Schlüsselfaktoren und die Behebung von erkannten Defiziten.

Die Komplexität der EDM-Prozess Implementierung ergibt sich dadurch, dass in den unterschiedlichen Phasen des Produkt-Lebenszyklus zur Lösung der spezifischen Aufgaben sehr unterschiedliche Softwaresysteme eingesetzt werden.

So werden beispielsweise mit Hilfe der CAD-Applikationen geometrisch orientierte Produktdatenmodelle erzeugt, die in Datenbanken verwaltet werden. Diese Datenmodelle sind um weitere Informationen von Kunden bzw. Lieferanten sowie aus dem Produkt-Entwicklungsprozess zu bereichern und zur Verifizierung und Optimierung an Berechnungs- und Simulationsprogramme zu übergeben.

Mit externen Entwicklungspartnern und Zulieferern werden zu den unterschiedlichen Phasen der Produktentwicklung unterschiedlich qualifizierte Datenmodelle ausgetauscht. Die Zeitpunkte für bidirektionalen Datenaustausch werden nach Projektanforderung vorteilhaft in so genannten „Daten-Synchro-Punkten“ definiert.

[Seite 31]

3.1.2 PLM-Prozess-Design

Die im Rahmen der PLM-Strategie festgelegten Prozess-Ziele fließen unmittelbar in die Soll-Prozess-Definition ein. Dabei ergeben sich die Potenziale sowohl aus den quantitativ messbaren Prozesskennzahlen als auch aus nicht-quantifizierbaren Faktoren, wie Möglichkeiten zur Produktverlagerung, Job-Rotation, Lösungs-Akzeptanz oder Innovationsfähigkeit.

Beim Prozess-Design werden in der Regel die Prozesse entsprechend ihrem Beitrag zur Wertschöpfung eines Unternehmens eingeteilt in:

  • Kernprozesse
  • Management-Prozesse
  • Support-Prozesse

Die Kernprozesse umfassen in dem hier beschriebenen Kontext die eigentlich wertschöpfenden Prozesse im Sinne von End-to-End-Prozessen, d. h. die Prozesse beginnen beim Kunden und enden wiederum dort. Der Produktlebenszyklus beginnt beispielsweise mit der Kundenanfrage, erstreckt sich über Spezifikation, Design, Konstruktion, Berechnung bis hin zur Arbeitsvorbereitung, Fertigung und Montage und endet nach der Qualitätsprüfung mit der Lieferung zum Kunden.

[Seite 32]

Managementprozesse steuern im Sinne der festgelegten PLM-Strategie diese PLM-Kernprozesse. So wird beispielsweise die Produktpalette mit Hilfe eines Portfoliomanagements optimiert, so dass eine Unternehmensentwicklung vom Teilezulieferer zum Systemzulieferer erfolgen kann. Die Risikobetrachtung eines Projektes fließt in das Projektmanagement ein und das Innovationsmanagement beeinflusst im Wesentlichen die frühen Phasen der Produktentwicklung.

Die Supportprozesse unterstützen die PLM-Kernprozesse. Exemplarisch seien an dieser Stelle Prozesse zur Personalentwicklung, zur Abrechnung oder Prozesse bzgl. der IT-Infrastruktur angeführt.

3.1.3 PLM-Prozess-Implementierung

Auf der Basis einer Prozessdefinition kann dann eine Evaluierung in Frage kommender Systemlösungen durchgeführt werden. Während beispielsweise in der Vergangenheit bei der CAD-Systemauswahl funktionale Aspekte eine tragende Rolle spielen, tritt bei der PLM-Systemauswahl die durchgängige Unterstützung der definierten Soll-Prozesse in den Vordergrund. Dabei konzentriert sich die Prozessunterstützung auf die in den Prozessen festgehaltenen und mit Kennzahlen versehenen Anforderungen, die identifizierten Schlüsselfaktoren und die Behebung von erkannten Defiziten.

Abb. 15 verdeutlicht – trotz der unvollständigen Abbildung der realen Verhältnisse – die Komplexität einer PLM-Prozess-Implementierung. In den unterschiedlichen Phasen des Produkt-Lebenszyklus werden sehr unterschiedliche Software-

[...]

[Seite 33]

systeme eingesetzt, um die spezifischen Aufgaben zu lösen. So werden beispielsweise mit Hilfe der CAD-Systeme geometrisch orientierte Produktdatenmodelle erzeugt, die mit Hilfe von Datenbanken verwaltet werden, Diese Datenmodelle werden um Informationen aus dem Internet angereichert, beispielsweise um Katalogdaten von Zulieferern. Zur Verifizierung und Optimierung werden diese Daten an Berechnungs- und Simulationsprogramme übergeben. Mit externen Entwicklungspartnern und Zulieferern werden zu den unterschiedlichsten Phasen unterschiedlich qualifizierte Datenmodell ausgetauscht. Letztendlich werden die Daten dann an ein ERP-System übergeben, um die logistischen Prozesse abzuwickeln.

Anmerkungen
Sichter
(Klgn)

[15.] Analyse:Wdi/Fragment 176 01 - Diskussion
Bearbeitet: 19. January 2020, 16:40 Klgn
Erstellt: 19. January 2020, 16:37 (Klgn)
BauernOpfer, Fragment, SMWFragment, Scheer et al. 2006, Schutzlevel, Unfertig, Wdi

Typus
BauernOpfer
Bearbeiter
Klgn
Gesichtet
No
Untersuchte Arbeit:
Seite: 176, Zeilen: 1-10, 12-15
Quelle: Scheer et al. 2006
Seite(n): 33, Zeilen: zweiter Absatz
6.4.1.4 EDM-Prozess-Controlling

Oft ignoriert oder gar vergessen wird die dritte Komponente des Prozess-Lebenszyklus, das Prozess-Controlling. Im Sinne eines integrierten Qualitätsmanagements und einer kontinuierlichen Verbesserung der Geschäftsprozesse ist es unerlässlich, die erreichten Ziele zu prüfen und weitere Optimierungspotentiale zu entdecken. Die Ergebnisse des Prozess-Controllings sind wiederum Input für ein anschließendes Re-Design der Prozesse, um die identifizierten Optimierungspotentiale zu erschließen und so den Regelkreis zielgerichtet zu steuern. Dadurch wird deutlich, dass Prozessmanagement kein einmaliger Prozess, sondern eine kontinuierliche Querschnittfunktion in einem sich permanent weiterentwickelnden Unternehmen ist. [Wichtig ist dabei auch darauf hinzuweisen, dass dafür auch die notwendigen Ressourcen zur Verfügung gestellt werden müssen.]

In gleichem Maße sollten auch die unterstützenden IT-Systeme in regelmäßigem Abstand kritisch auf ihren Erfüllungsgrad hin analysiert werden. Mit Hilfe des Prozess-Controllings können auch Benchmarks zwischen verschiedenen Unternehmensbereichen oder Wettbewerbern durchgeführt werden.

3.1.4 PLM-Prozess-Controlling

Oft ignoriert oder schlichtweg vergessen wird die dritte Komponente des Prozess-Lebenszyklus: das Prozess-Controlling. Im Sinne eines integrierten Qualitätsmanagements und einer kontinuierlichen Verbesserung der Geschäftsprozesse ist es unerlässlich, die erreichten Ziele zu überprüfen und weitere Optimierungspotenziale zu entdecken. Die Ergebnisse des Prozess-Controllings sind wiederum Input für ein anschließendes Re-Design der Prozesse, um die identifizierten Optimierungspotenziale zu erschließen und so den Regelkreis zielgerichtet zu steuern. Dadurch wird deutlich, dass Prozessmanagement kein einmaliger Prozess, sondern eine kontinuierliche Querschnittfunktion in einem sich permanent weiterentwickelnden Unternehmen ist.

[...]

In gleichem Maße sollten auch die unterstützenden IT-Systeme in regelmäßigem Abstand kritisch auf ihren Erfüllungsgrad hin analysiert werden. [...]

Abb. 16 verdeutlicht anhand eines Prozessbeispiels, welche Aussagen ein Prozess-Controlling liefern kann. [...] Hiermit können beispielsweise auch Benchmarks zwischen verschiedenen Unternehmensbereichen oder Werken durchgeführt werden.

Anmerkungen
Sichter
(Klgn)


Quellen

Quelle Autor Titel Verlag Jahr Lit.-V. FN
Wdi/Hartlieb 2002 Erich Hartlieb Wissenslogistik. Effektives und effizientes Management von Wissensressourcen Deutscher Universitäts-Verlag 2002 ja ja
Wdi/Pischon Iwanowitsch 1998 Alexander Pischon / Dirk Iwanowitsch Generische Managementsysteme als zukünftige Option Springer 1998 ja ja
Wdi/Scheer et al. 2006 August-Wilhelm Scheer / Manfred Boczanski / Michael Muth / Willi-Gerd Schmitz / Uwe Segelbacher Prozessorientiertes Product Lifecycle Management Springer 2006 ja ja
Wdi/Vorbach 2000 Stefan Vorbach Prozessorientiertes Umweltmanagement. Ein Modell zur Integration von Umweltschutz, Qualitätssicherung und Arbeitssicherheit Wiesbaden 2000 ja ja
Wdi/Willfort 2001 Reinhard Willfort Wissensmanagement mit Innovationsdienstleistungen. Externe Leistungspotenziale zur Stärkung der Wissensbasis Deutscher Universitäts-Verlag 2001 ja ja


Übersicht

Typus Gesichtet ZuSichten Unfertig Σ
KP 0 0 1 1
VS 0 0 10 10
ÜP 0 0 0 0
BO 0 0 4 4
KW 0 0 0 0
KeinP 0 0 0 0
Σ 0 0 15 15

Sitemap

Kategorie:Wdi




Wichtige Seiten

Befunde

Alle Fragmente

Unfragmentierte Fundstellen

Diskussionsmonitor