Leitfaden als PDF

Leitfaden Leistungssteigerung der Produktentwicklung durch den Einsatz von Virtual Prototyping & Simulation

VPS-Benchmark

HEINZ NIXDORF INSTITUT Universität Paderborn

Inhaltsverzeichnis Seite 1

© 2012, Heinz Nixdorf Institut, Paderborn

Inhaltsverzeichnis Seite

1 Vorwort ........................................................................................................... 2

2 VPS-Benchmark – Ihre Produktentwicklung auf dem Prüfstand! ................... 4

2.1 Organisation ........................................................................................... 5

2.2 Reifegradermittlung ................................................................................ 5

2.3 Leistungssteigerung ............................................................................... 6

3 VPS-Prozessanalyse ..................................................................................... 8

3.1 Prozessaufnahme ................................................................................... 8

3.2 Potentialidentifikation ............................................................................ 10

3.2.1 Leitfragen Entwicklungsmanagement ........................................ 11

3.2.2 Leitfragen Konstruktion .............................................................. 12

3.2.3 Leitfragen Datenmanagement ................................................... 13

3.2.4 Leitfragen Weiterverwendung .................................................... 14

3.2.5 Leitfragen Produktanalysen ....................................................... 15

4 VPS-Leistungssteigerungsstrategie ............................................................. 17

4.1 Formulierung der Entwicklungsziele ..................................................... 17

4.2 Priorisierung der Maßnahmen .............................................................. 19

4.3 Roadmap zur Maßnahmenumsetzung ................................................. 21

Anhang

A1 Einführung von IT-Systemen ................................................................ 24

A2 Die Methode OMEGA ........................................................................... 27

Kapitel 1: Vorwort Seite 2


1 Vorwort

Die Fähigkeit, hochkomplexe Produkte zu entwickeln, herzustellen und zu betreiben, ist

Markenzeichen und Erfolgsfaktor deutscher Unternehmen. Im Maschinen- und Anla-

genbau sowie verwandten Branchen wird dieser Erfolg wesentlich durch Effektivität

und Effizienz in den notwendigen Geschäftsprozessen erzielt. Der Produktentwick-

lungsprozess ist dabei besonders bedeutend, da in ihm alle wesentlichen Merkmale des

künftigen Produkts und ca. 80 % der Kosten festgelegt werden.

Die Methoden und Werkzeuge des Virtual Prototyping und Simulation (VPS) tragen

maßgeblich zu einer Beschleunigung des Produktentwicklungsprozesses und zur Erhö-

hung der Entwicklungsqualität bei. Virtual Prototyping heißt, Rechnermodelle von in

Entwicklung befindlichen Produkten zu bilden und zu analysieren. Hierfür werden mit

verschiedensten Softwarewerkzeugen rechnerinterne Modelle generiert, die das Produkt

in allen Facetten beschreiben. Sie bilden die Ausgangsbasis für die Berechnung von

Funktion, Gestalt und Verhalten der Produkte. Diese Daten müssen sicher verwaltet,

benutzergerecht aufbereitet und vielfältig verknüpft werden. In der Vergangenheit hat

sich hier ein Kanon von domänenspezifischen VPS-Methoden und -Werkzeugen (z.B.

M-CAD-/E-CAD-, MKS-, FEM- Systeme) etabliert. Die Integration der Systeme in die

bestehende PDM/PLM Infrastruktur (PDM: Produktdatenmanagement, PLM: Product

Lifecycle Management) des Unternehmens ist dabei ein wesentlicher Erfolgsfaktor.

Der Übergang von einer traditionellen Produktentwicklung, die größtenteils auf physi-

kalischen Prototypen basiert, hin zur VPS getriebenen Entwicklung mit Hilfe von virtu-

ellen Prototypen ist aufwändig und oftmals von kostspieligen Misserfolgen geprägt. Es

reicht nicht aus, ein entsprechendes Werkzeug quasi aus dem Regal zu kaufen und zu

installieren, mit der Erwartung, damit sei der Einstieg in die digitale Produktentwick-

lung geschafft. Ohne eine Integration der Systeme in die Prozesse des Unternehmens

wird nur ein Bruchteil des Potenzials erschlossen, welches diese Lösungskonzepte ei-

gentlich bieten. Denn neben den erforderlichen Investitionen in Hard- und Software ist

vor allem fehlendes Know-how in den Unternehmen beziehungsweise bei den Mitarbei-

tern der wesentliche Grund, dass die vorhandenen Potentiale nicht genutzt werden. Vie-

le Unternehmen haben das sehr hohe Nutzenpotenzial dieser Technologien erkannt.

Große Unternehmen realisieren entsprechende Konzepte seit Jahren mit Erfolg. Kleine-

re Unternehmen stehen jedoch häufig noch am Anfang und laufen Gefahr, den An-

schluss zu verpassen.

Vor diesem Hintergrund hat das Heinz Nixdorf Institut ein Instrumentarium zur Analyse

und Optimierung des Einsatzes von Virtual Prototyping & Simulation im Produktent-

stehungsprozess entwickelt. Im Fokus stehen kleine und mittlere Unternehmen des Ma-

schinen- und Anlagenbaus sowie verwandten Branchen, deren Kerngeschäft die Ent-

wicklung intelligenter technischer Systeme ist. Das Instrumentarium ermöglicht es die

eigene VPS Entwicklungsstand schnell und einfach zu analysieren und Verbesserungs-

Kapitel 1: Vorwort Seite 3


potentiale zu identifizieren. Darüber hinaus werden Unternehmen in die Lage versetzt,

den Einsatz von Virtual Prototyping & Simulation langfristig zu planen und strukturiert

auszubauen. Zusätzlich ermöglichen sogenannte „VPS-Reifegrade“ einen unterneh-

mensübergreifenden Vergleich des VPS-Entwicklungsstands.

Dieser Leitfaden gibt in drei Kapiteln einen detaillierten Überblick über die Bestandteile

des Instrumentariums. In Kapitel 2 wird zunächst der VPS-Benchmark erläutert. Der

VPS-Benchmark dient einer initialen Selbstbewertung des heutigen VPS-

Leistungstands. Darauf aufbauend werden erste Handlungsempfehlungen zur Verbesse-

rung gegeben. Diese werden durch die VPS-Prozessanalyse, beschrieben in Kapitel 3,

aufgegriffen und vertieft. Aufbauend auf einem Prozessmodell der Produktentwicklung

werden die durch den VPS-Benchmark identifizierten Handlungsbedarfe entlang des

Prozesses verortet und weitere Verbesserungsmaßnahmen identifiziert. Alle identifizier-

ten Maßnahmen müssen zu einer konsistenten VPS-Leistungssteigerungsstrategie

zusammengeführt werden. Mittels des in Kapitel 4 beschriebenen Vorgehens werden

die Maßnahmen dazu priorisiert und in eine zeitliche Umsetzungsreihenfolge gebracht.

Kapitel 2: VPS-Benchmark – Ihre Produktentwicklung auf dem Prüfstand! Seite 4


2 VPS-Benchmark – Ihre Produktentwicklung auf dem Prüf-

stand!

Der VPS-Benchmark dient der initialen Selbstbewertung des VPS-Leistungsstands Ihrer

Produktentwicklung. Sie finden heraus, wie zukunftssicher Ihre Produktentwicklung

aufgestellt ist! Zusätzlich zur derzeitigen Leistungsfähigkeit werden anonymisierte Ver-

gleichsmöglichkeiten zu Unternehmen, die vor ähnlichen Herausforderungen stehen,

bereitgestellt. Neben einem unternehmensindividuellen VPS-Leistungsstand werden

konkrete Maßnahmen empfohlen, wie Sie diesen erreichen können. Die Selbstbewer-

tung ist speziell auf die Anforderungen des Mittelstands zugeschnitten. Die Durchfüh-

rung geht schnell, einfach und bedarf keiner langwierigen Einarbeitung. Sie kann neben

dem normalen Tagesgeschäft durchgeführt werden, ohne dass Externe in Ihr Unterneh-

men kommen müssen. Die gesamte Analyse ist online unter www.viprosim.de verfüg-

bar.

Bild 1: Vorgehen des VPS-Benchmarks im Überblick

Der VPS-Benchmark führt durch einen Fragenkatalog zu folgenden Themengebieten:

Entwicklungsmanagement

Wie managen Sie Ihren Entwicklungsprozess?

Konstruktion Welche Voraussetzungen bieten Sie Ihren Entwicklern zur produktiven Arbeit?

Datenmanagement Wie verwalten Sie Daten, die während der Entwicklung benötigt werden und

entstehen?

Weiterverwendung Wie nutzen Sie bestehende Konstruktionsdaten in weiteren Bereichen Ihres Un-

ternehmens?

Produktanalysen Wie arbeitet Ihr Unternehmen mit dem virtuellen Prototypen?

http://www.viprosim.de/



Jedes dieser Themengebiete besteht aus 20 bis 50 Fragen. Sie entscheiden selbst, wel-

che Themengebiete behandelt werden.

2.1 Organisation

Wir empfehlen, den VPS-Benchmark als Workshop durchzuführen. Für den Workshop

sollte ein Moderator ernannt werden, der die Befragung organisiert und moderiert. Er

liest die Fragen und Antworten vor und führt durch die Diskussion. Der Moderator soll-

te vor dem Workshop ein Themengebiet (bspw. Entwicklungsmanagement) aus dem

VPS-Benchmark durcharbeiten. So wird er mit der intuitiven Arbeitsweise und Ergeb-

nisdarstellung des VPS-Benchmarks vertraut.

Um einen möglichst hohen Nutzen aus der Selbstbewertung zu ziehen, empfiehlt es

sich, dass sowohl Personen mit Führungsaufgaben als auch Entwickler und Konstruk-

teure selbst an dem Workshop teilnehmen. Hierdurch werden Diskrepanzen in den ver-

schiedenen Vorstellungen der Leistungsfähigkeit Ihrer Produktentwicklung frühzeitig

erkannt und diskutiert. Die Fragestellungen des VPS-Benchmark führen durch eine Dis-

kussion, die umso lebhafter ist, je mehr Bereiche hier eingebunden sind. Folgende Per-

sonenkreise kommen für den Workshop in Frage: Entwicklungsleiter, Entwickler, Kon-

strukteure, IT und Mitglieder der Geschäftsführung. Für das Themengebiet „Weiterver-

wendung“ sollten zusätzlich Vertreter von Dokumentation, Marketing und Vertrieb in-

volviert werden. Eine gute Gruppengröße liegt bei vier bis sieben Personen.

Sollten Sie mehrere Entwicklungsbereiche oder -abteilungen haben, empfehlen wir, die

Befragung zunächst in einem abteilungsübergreifenden Kreis durchzuführen und später

die abteilungsspezifischen Fragestellungen in den Abteilungen erneut zu diskutieren.

2.2 Reifegradermittlung

Zu Beginn der Befragung können die Themengebiete gewählt werden. Abhängig von

der Anzahl der Themengebiete und der Intensität der Diskussion dauert die Befragung

zwischen 30 Minuten und fünf Stunden. Auch während der Befragung haben Sie die

Möglichkeit, die Themengebiete zu ändern. Sie können jederzeit den derzeitigen Status

der Befragung speichern und zu beliebiger Zeit fortsetzen.

Die Reifegradermittlung gliedert sich in die Phasen „Klassifikation“ und „Leistungsbe-

wertung“. In der „Klassifikation“ beantworten Sie Fragen zu Ihrem Unternehmen, Pro-

dukt und Umfeld. Auf Basis dieser Angaben wird ein für Sie individuell geeigneter

SOLL-Zustand ermittelt, der sogenannte Ziel-Reifegrad. Zusätzlich dienen diese Anga-

ben einem anonymen Vergleich mit anderen Unternehmen.

In der „Leistungsbewertung“ beantworten Sie allgemeine und detaillierte Fragen zu den

gewählten Themengebieten. Sollten Sie sich bei einer Frage nicht einigen können, wäh-

len Sie bitte die obere der in Frage kommenden Ausprägungen. Sie können Fragen auch



zurückstellen und zu einem späteren Zeitpunkt beantworten. Mit Hilfe einer Fragenliste

haben Sie die Möglichkeit beliebig im Fragenverlauf zu springen.

Bild 2: Ausschnitt aus dem Fragenkatalog

2.3 Leistungssteigerung

Sobald alle Fragen beantwortet sind, stehen die Ergebnisse zur Verfügung. Hierfür wer-

den Sie durch die Phasen „Erkennen“, „Verstehen“ und „Erschließen“ geführt.

Erkennen

Je Themengebiet wird Ihre derzeitige Leistungsfähigkeit in Form eines IST-Reifegrades

ausgegeben. Auf einen Blick sehen Sie, wie sich dieser zu Ihrem unternehmensindivi-

duellen Ziel-Reifegrad verhält. Zusätzlich können Sie Ihren IST-Reifegrad mit dem

ähnlicher Unternehmen vergleichen.

Bild 3: Phase „Erkennen“

Verstehen

In dieser Darstellung werden Ihnen nochmals alle Fragen angezeigt. Zusätzlich zu Ihren

gegebenen Antworten sehen Sie, welche Antworten Ihnen durch den Ziel-Reifegrad

empfohlen werden. Sollten diese beiden Antworten nicht identisch sein, wird die Frage

rot markiert. Ausprägungen mit gelbem Ausrufezeichen sind von besonderer Bedeutung

für Ihren IST-Reifegrad. Die Zahlen geben an, wie viel Prozent der anderen Unterneh-

men welche Antworten angekreuzt haben.



Bild 4: Phase „Verstehen“

Erschließen

Es werden konkrete Maßnahmen empfohlen, wie sie Ihren individuellen Ziel-Reifegrad

erreichen können. Zur Auswahl werden die Maßnahmen mittels eines Aufwand-Nutzen-

Portfolios priorisiert. Bei einer Vielzahl von Maßnahmen haben Sie die Möglichkeit

diese nach den Themengebieten zu filtern. Diskutieren Sie die Maßnahmen im Team

und entscheiden Sie, welchen Sie sich in Zukunft widmen möchten. In Maßnahmen-

steckbriefen werden weitergehende Informationen gegeben. Informationen zur Maß-

nahmenauswahl und zur darauf basierenden Strategieentwicklung finden Sie in Kapitel

4.

Bild 5: Phase „Erschließen“

Kapitel 3: VPS-Prozessanalyse Seite 8


3 VPS-Prozessanalyse

Der VPS-Benchmark liefert einen umfangreichen Überblick über die Leistungsfähigkeit

Ihrer Produktentwicklung und schlägt erste Verbesserungsmaßnahmen vor. Ziel der

VPS-Prozessanalyse ist es, diese Ergebnisse weiter zu detaillieren und um unterneh-

mensspezifische Erkenntnisse zu erweitern. Grundlage hierfür ist die Analyse Ihres

Entwicklungsprozesses auf Basis eines Prozessmodells. Dieses ermöglicht – im Gegen-

satz zur systemneutralen Analyse durch den VPS-Benchmark – eine Analyse der unter-

nehmensspezifischen Systemlandschaft. Dies bringt Transparenz in Ihren Entwick-

lungsprozess und dient als Diskussionsgrundlage für die Erarbeitung Ihrer VPS-

Leistungssteigerungsstrategie. Die VPS-Prozessanalyse gliedert sich in zwei Schritte:

die Prozessaufnahme sowie die anschließende Potentialidentifikation. Im Folgenden

werden beide Schritte erläutert.

3.1 Prozessaufnahme

Zur Erarbeitung Ihrer Leistungssteigerungsstrategie ist ein umfassendes und teamüber-

greifendes Verständnis der Entwicklungsprozesse erforderlich. Hierfür empfehlen wir

Ihnen eine Prozessmodellierung mit der Methode OMEGA.

Die Methode OMEGA (Objektorientierte Methode zur Geschäftsprozessmodellierung

und -analyse) entstand am Heinz Nixdorf Institut und wurde zusammen mit der UNITY

AG weiterentwickelt. Die Methode ermöglicht die vollständige Modellierung einer Ab-

lauforganisation in nur einem Modell und eignet sich mittels einfacher und prägnanter

Visualisierung als Instrument zur anschaulichen Analyse und Planung von Leistungser-

stellungsprozessen.

Die Erfahrung zeigt, dass mit der Methode OMEGA modellierte Geschäftsprozessmo-

delle intuitiv verständlich sind. Durch die Beschränkung auf die wesentlichen Objekte

eines Geschäftsprozesses ist die Methode über alle Unternehmensebenen hinweg ein-

setzbar. Die Modelle zeichnen sich durch eine hohe Flexibilität bei der Darstellung pro-

jekt- und unternehmensspezifischer Inhalte aus. Darüber hinaus lassen sich aus diesen

Modellen die formalen Prozessspezifikationen für Produktdatenmanagementsysteme

(z.B. Konstruktionsfreigabeprozess) und für Workflowmanagementsysteme ableiten.

Eine detaillierte Beschreibung der Methode OMEGA finden Sie in Kapitel A2. Bild 6

zeigt beispielhaft einen mit OMEGA modellierten Entwicklungsprozess.



Bild 6: Der Ausschnitt des OMEGA-Prozessmodells verdeutlicht die direkte Zuordnung

der identifizierten Potentiale zu den einzelnen Prozessschritten

Sollten Sie Ihre Entwicklungsprozesse bereits mit einer anderen Prozessmodellierungs-

sprache modelliert haben, können Sie auf Basis dieser Modelle weiterarbeiten. Im Vor-

feld sollten Sie Ihre Prozessbeschreibungen jedoch nochmals auf Aktualität prüfen. Im

Falle einer Modellierung mit OMEGA folgen Sie vier Schritten:

1. Definition des Untersuchungsgegenstands

2. Interviews und Workshops zur Prozessaufnahme

3. Prozessmodellierung

4. Review

Im ersten Schritt gilt es den Untersuchungsgegenstand zu definieren. Hierbei stellt sich

die Frage, welche Schnittstellen zu anderen Abteilungen existieren und wie intensiv

diese in der Analyse berücksichtigt werden sollen. Im Kontext der VPS-Prozessanalyse

empfehlen wir, die Schnittstellen zu „Dokumentation“, „Marketing“, „Vertrieb“, „Ein-

kauf“ und „Fertigung“ in die Analyse einzubeziehen. Hierbei sollten insbesondere die

Datendurchgängigkeit sowie die Kommunikation zwischen den Unternehmensbereichen

untersucht werden. Sollten Sie mehrere Entwicklungsbereiche oder -abteilungen haben,

sollten alle in der Analyse berücksichtigt werden.

Der zweite Schritt – die Aufnahme des Entwicklungsprozesses – ist die Kernaufgabe

und erfolgt in Workshops und Interviews. Zur Durchführung der Workshops und Inter-

views finden Sie Hinweise in Kapitel A2.3. Um einen möglichst hohen Nutzen aus der

Prozessanalyse zu ziehen, sollten die Workshop-Teilnehmer und Interviewpartner aus

unterschiedlichen Unternehmensbereichen und Funktionen kommen. Wir empfehlen,



wie auch schon für den VPS-Benchmark, dass sowohl Personen mit Führungsaufgaben

als auch Entwickler und Konstrukteure selbst an dem Workshop teilnehmen. Unter-

schiedliche Vorstellungen der Teilnehmer über der Leistungsfähigkeit Ihrer Produkt-

entwicklung werden so frühzeitig erkannt und diskutiert. Folgende Personenkreise

kommen für Workshops und Interviews in Frage: Entwicklungsleiter, Entwickler, Kon-

strukteure, IT und Mitglieder der Geschäftsführung. Für die Schnittstellen müssen ent-

sprechende Vertreter involviert werden.

Wir empfehlen, zunächst die Prozesse innerhalb der Entwicklungsabteilungen bzw.

-bereiche aufzunehmen. So wird die Arbeitsgruppe nicht zu groß und der Workshop

kann effizient durchgeführt werden. Sobald die Prozesse abteilungsintern modelliert

sind, können die Schnittstellen mit den betroffen Bereichen detailliert werden.

Bei der Durchführung der Workshops und Interviews zur Prozessaufnahme sollten fol-

gende Aspekte beachtet werden:

• Informieren Sie alle Beteiligten über Grund und Zielsetzung des Workshops bzw.

Interviews.

• Begrenzen Sie die Dauer und die Anzahl der Fragen. Formulieren Sie darüber hinaus

die Fragen verständlich und knapp, um die Zeit möglichst effizient zu nutzen.

• Schätzen Sie die Antwortmöglichkeiten schon im Voraus ab, um zu verhindern, dass

zu viel Nebensächliches dargestellt wird. Das gleiche gilt für die Antwortzeit. Die

Fragen sollten nur eindeutige Aussagen zulassen.

• Fassen Sie die Ergebnisse der Fragestellungen eines Interviews bzw. Workshops

z.B. durch einige wenige Thesen und Grundsätze zusammen. Dokumentieren Sie

darüber hinaus jedes Gespräch und machen Sie die Ergebnisse den jeweiligen Teil-

nehmern zugänglich.

Schritt drei und vier – Prozessmodellierung und Review – schließen sich der Prozess-

aufnahme zeitlich direkt an. Ziel ist die umfassende modellbasierte Dokumentation der

Ablauforganisation sowie deren Verifikation. Viele der Beteiligten empfinden die Auf-

nahme dessen, was in vielen Jahren gewachsen ist, als strammes Programm. Es ist daher

vernünftig, allen die Gelegenheit zu geben, über die dokumentierte Ist-Situation noch

einmal nachzudenken und die Sache mit anderen zu reflektieren. Das Review ist dann

eine gute Gelegenheit, weitere Erkenntnisse einzubringen. Gegenstand des Reviews

sind das Modell der Ablauforganisation und die damit verbundene Dokumentation. Am

Ende sollte das Projektteam Konsens über den modellierten Entwicklungsprozess erzie-

len.

3.2 Potentialidentifikation

Die Diskussion der aufgenommenen Prozesse offenbart in der Regel bereits erste

Schwachstellen und Verbesserungspotentiale. Diese sind zu dokumentieren und den



einzelnen Entwicklungsprozessen direkt zu zuordnen. Darüber hinaus wurden Ihnen in

der Phase „Verstehen“ des VPS-Benchmarks konkrete SOLL-Ausprägungen empfoh-

len. Ausprägungen, die so von Ihnen nicht erreicht werden, sollten direkt in das OME-

GA-Prozessbild als VPS-Potentiale eingetragen werden. Gleiches gilt für die vom VPS-

Benchmark empfohlenen Maßnahmen. Es wird anschaulich und auf einen Blick er-

kennbar, in welchen Bereichen Sie noch Entwicklungsmöglichkeiten haben.

Neben den bereits identifizierten Schwachstellen und Verbesserungspotentialen bietet

sich das aufgenommene Prozessmodell für eine vertiefte Potentialanalyse an. Hierzu

sollten weitere Workshops initiiert werden, die sich an einer Reihe von Leitfragen für

die Themengebiete „Entwicklungsmanagement“, „Konstruktion“, „Datenmanagement“,

„Weiterverwendung“ und „Produktanalysen“ orientieren. Für jedes dieser Themenge-

biete finden Sie im Folgenden einen Fragenkatalog, der Ihnen die Moderation des

Workshops vereinfacht. Die Fragen eignen sich ausschließlich für eine Potentialanalyse

im Anschluss an eine zuvor erfolgte Prozessaufnahme.

3.2.1 Leitfragen Entwicklungsmanagement

Entwicklungsmanagement spricht wichtige Fragen der Leitung und Gestaltung von Pro-

zessen und Abteilungen/Bereichen der Produktentwicklung an. Der Fokus liegt weniger

auf harten Prozessthemen, sondern eher auf weichen Faktoren, die die Kultur der Pro-

duktentwicklung prägen. Die Fragen zum Entwicklungsmanagement sollten während

der Analyse über alle Themengebiete im Hinterkopf behalten werden.

Wie planen Sie den Ausbau der Entwicklungsorganisation und -werkzeuge? Ha-

ben Sie eine Strategie?

Verfolgen Sie die aktuellen Entwicklungen am Markt für Methoden und Werk-

zeuge des Virtual Prototyping & Simulation?

Wie erfolgt die Einführung neuer Methoden und Werkzeuge?

Was ist die Kernaufgabe der Abteilung/des Teams; was ist von der Abteilung

herzustellen, durchzuführen bzw. zu prüfen/testen?

Kennen Sie Ihre Ansprechpartner in den anderen Abteilungen? Wie fließen In-

formationen zwischen diesen Abteilungen (Vertrieb, mechanische Konstruktion,

elektrische Konstruktion, Arbeitsvorbereitung, Produktion, Inbetriebnahme)?

Wie erfolgt die Zusammenarbeit über die verschiedenen Disziplinen (Mechanik,

Elektronik, Software etc.)? Wer ist der wichtigste Kunde für Ihre Arbeitsergeb-

nisse?

Wie sind Ihre Mitarbeiter in der Entwicklung gegenüber Veränderungen in den

Bereichen „Methoden“, „Werkzeuge“ und „Organisation“ eingestellt?

Werden definierte Geschäftsprozesse und Richtlinien eingehalten?



Wie ist die Einstellung Ihrer Entwickler und der Führungsebenen zum Thema

Simulation?

In welcher Form bieten Sie Ihren Entwickler Weiterbildungs- und Schulungs-

möglichkeiten?

Tauschen Sie sich mit Entwicklern anderer Unternehmen aus, die vor ähnlichen

Herausforderungen stehen? Streben Sie Kooperationen an?

Wie beurteilen Sie die Effizienz Ihrer Entwicklungsprozesse?

Wie erfolgt die Messung des Projektfortschritts? Arbeiten Sie mit Meilenstei-

nen, Quality Gates o.Ä.?

Wie aktuell sind Soft- und Hardware?

Sind Ihnen die unterschiedlichen Lizenzmodelle Ihrer IT-Systemanbieter be-

kannt?

3.2.2 Leitfragen Konstruktion

Diese Fragen fokussieren speziell den Konstruktionsprozess. Zentrale Fragestellungen

sind: Welche Voraussetzungen bieten Sie Ihren Entwicklern zur produktiven Arbeit und

wie gewährleisten Sie die Qualität der Konstruktion?

Wie entstehen Ihre Produktentwürfe? Gibt es eine ausgeprägte Konzipierungs-

phase? Wie erarbeiten Sie Ihre Produktstruktur?

Arbeiten Sie mit 2D- oder 3D-CAD-Systemen?

Wie viele verschiedene CAD-Systeme setzen Sie in der Produktentwicklung

ein? Warum setzen Sie verschiedene Systeme ein?

Stellen Sie Ihren Entwicklern Hilfsmittel für die Arbeit im CAD-System zur

Verfügung?

Ist das Vorgehen bei der Arbeit mit dem CAD-System vorgegeben und regle-

mentiert? In welcher Form haben die Entwickler Zugang zu diesen Vorgaben?

Werden die Vorgaben erweitert und aktualisiert? Wie werden die Anwender im

Umgang mit den Vorgaben vertraut gemacht und wie wird die Einhaltung ge-

prüft?

Geben Sie vor wie CAD-Modelle aufgebaut werden müssen? Bieten Sie Refe-

renzmodelle an?

Verwenden Sie Vorgehen zur einheitlichen Benennung von Bauteilen, um das

Wiederfinden zu vereinfachen?



Wie bringen Sie die Daten aus der Elektrokonstruktion mit den Daten aus der

mechanischen Konstruktion in Verbindung?

Zu welchem Zeitpunkt wird die Elektrokonstruktion in das Entwicklungsprojekt

eingebunden?

Verwenden Sie die 3D-Produktdaten Ihrer Kunden und Zulieferer in Ihrer Kon-

struktion?

3.2.3 Leitfragen Datenmanagement

Diese Fragen behandeln die Verwaltung der Daten, die während der Konstruktion ent-

stehen oder benötigt werden. Wie erreichen Sie eine möglichst hohe Datendurchgängig-

keit und reibungslose Kommunikation zwischen den Mitarbeitern?

Existiert im Unternehmen ein ausformuliertes, mit dem Management abge-

stimmtes Konzept zum Datenmanagement? Welche Unternehmensbereiche sind

Teil dieses Konzepts?

Haben Sie Richtlinien für die Verwaltung Ihrer Daten?

Mit welchen Systemen verwalten Sie Ihre CAD-Modelle?

Mit welchen Systemen verwalten Sie Ihre allgemeinen entwicklungsbezogenen

Dokumente wie bspw. Protokolle, Skizzen, Präsentationen, Studien etc.? Ist es

das gleiche System wie für die CAD-Daten?

Wie werden die Simulationsdaten verwaltet?

Haben Sie vorgegebene Ordnerstrukturen, damit sich die Mitarbeiter in ver-

schiedenen Projekten zurechtfinden?

Haben Sie ein abgestimmtes Verfahren zur Versionierung Ihrer Daten in den

Ordnerstrukturen?

Wie erfolgt die Einführung von Mitarbeitern in das Datenmanagement?

Wie erfolgt das Datenmanagement über die verschiedenen Disziplinen (Mecha-

nik, Elektronik, Software etc.) hinweg?

Haben Sie Zugriff auf Ihre Altdaten aus vorherigen Systemen (bspw. das früher

eingesetzte 2D-CAD-System) oder Papierzeichnungen? In welchem Format ste-

hen Ihnen die Altdaten zur Verfügung? Ist der Zugriff auf die Altdaten einfach

oder kompliziert?

Ist das Wiederfinden von Produktdaten einfach oder kompliziert?

Greifen Sie bei Neukonstruktionen auf bestehende Modelle zurück? Ist eine

Strategie zur Wiederverwendung von Konstruktionsdaten vorhanden?



Arbeiten Sie mit internen Bauteilstandards? Wie erfolgt die interne Bauteilstan-

dardisierung?

Arbeiten Sie mit digitalen Teilebibliotheken und welche Teilearten werden in

diesen Bibliotheken zur Verfügung gestellt?

Wie klassifizieren Sie Ihre Bauteile? Wie wurde die Klassifikationssystematik

erarbeitet und wie wird sie gepflegt? Wird Ihre Klassifikationssystematik durch

Ihr Datenmanagement-System unterstützt?

Verfolgen Sie den Gedanken der Modularisierung? Nutzen Sie den modularen

Aufbau der Systeme aus der Konstruktion auch in weiteren Bereichen (Beispie-

le: Module für Dokumentation, Angebotskonfiguration, Fertigungszeichnun-

gen)?

Wie arbeiten Sie bei der Erstellung von Konfigurationen oder Varianten? Arbei-

ten Sie nach etablierten Methoden? Setzen Sie Produktkonfiguratoren ein?

Wie erfolgen technische Änderungen (Zeichnungsänderungen und Stücklisten-

änderungen)? Wer entscheidet über die Freigabe von Änderungen? Wie werden

Mitarbeiter über Änderungen informiert? Gibt es eine formalisierte Analyse der

technischen und wirtschaftlichen Änderungsauswirkungen? Wird das Ände-

rungsverfahren durch IT-Systeme unterstützt?

Wie etabliert ist Ihr Freigabeverfahren? Ist definiert wer, wann, was, nach wel-

chen Vorschriften und zu welchem Zweck freigeben kann? Welche Dokumente

müssen wann vorliegen? Wird Ihr Freigabemanagement durch ein IT-System

unterstützt?

Haben Sie Sicherheitsrichtlinien zum Datenaustausch mit Externen definiert?

Erstellen Sie eine Historie über den Verlauf von Austauschvorgängen mit Exter-

nen? Nutzen Sie die Möglichkeit, den Detaillierungsgrad der Konstruktionsdaten

zu verringern, wenn Ihre Daten an Externe gegeben werden?

Arbeiten die räumlich verteilten Abteilungen/Gruppen Ihres Unternehmens auf

dem gleichen Datenbestand?

Setzen Sie ein ERP-System ein?

In welchen Systemen verwalten Sie Ihre Stücklisten? Wie werden die Stücklis-

ten zwischen dem PDM- und ERP-System synchronisiert?

3.2.4 Leitfragen Weiterverwendung

Diese Fragen behandeln die Weiterverwendung Ihrer Konstruktionsdaten in weiteren

Unternehmensbereichen wie Dokumentation, Marketing, Vertrieb oder Fertigung. Wie

organisieren und unterstützen Sie eine möglichst hohe Weiterverwendung?



Welchen Stellenwert hat die Dokumentation innerhalb Ihres Unternehmens?

Wird die Dokumentation als Marketinginstrument und zur Unterstützung der

Kommunikation (bspw. abteilungsübergreifend oder mit Kunden und Zuliefe-

rern) genutzt?

Wird die Dokumentation von technischen Redakteuren erstellt? Wie ist die Do-

kumentationstätigkeit organisiert?

Ist Ihre Dokumentation standardisiert?

Verfolgen Sie in Ihrer Dokumentation den Gedanken der Modularisierung?

Ist Ihr Dokumentationsprozess etabliert? Werden die Prozesse für die Dokumen-

tation eingehalten? Wird Ihr Dokumentationsprozess durch Vorlagen oder IT-

Systeme unterstützt?

Wann startet Ihr Dokumentationsprozess? Wird die Dokumentation bereits in

frühen Phasen der Entwicklung (Produktplanung) berücksichtigt?

Wie beschreiben Sie die Beziehung zwischen Dokumentation und Konstruktion

beim Auftreten von Änderungen?

Welche IT-Systeme nutzen Sie für die Erstellung der Dokumentation?

Werten Sie Ihre Dokumentation durch Grafiken auf? Werten Sie Ihre Unterlagen

für Marketing bzw. Vertrieb durch 3D-Grafiken auf?

Nutzen Sie für die Erstellung der Grafiken die 3D-Daten aus Ihrer Konstruktion?

Wie werden die 3D-Daten zwischen den Abteilungen ausgetauscht?

Arbeiten Sie bei der Aufbereitung von 3D-Daten für Dokumentation, Marketing

bzw. Vertrieb mit externen Dienstleistern zusammen?

Wie bereiten Sie Ihre Schulungsunterlagen auf?

In welchen Formen nutzen Sie 3D-Daten für Marketing und Vertrieb?

Nutzen Sie 3D-Daten aus der Konstruktion zur Aufwertung Ihrer Fertigungsun-

terlagen?

In welcher Form wird die Elektrokonstruktion in die Montage/Fertigung weiter-

gegeben?

Nutzen Sie CAD/CAM-Kopplungen?

3.2.5 Leitfragen Produktanalysen

Diese Fragen behandeln den Einsatz von Berechnungen und Simulationen im Produkt-

entwicklungsprozess. Nutzen Sie bereits das volle Potential des virtuellen Prototyps?



Führen Sie Einbau- bzw. Kollisionsuntersuchungen auf Basis Ihrer 3D-Modelle

durch?

Setzen Sie Virtual Reality in Ihrem Unternehmen ein? Welche Art von Projekti-

onssystemen setzen Sie ein? Welche Unternehmensbereiche sind bei Virtual Re-

ality Anwendungen involviert?

Welche Simulationen setzen Sie ein? In welchem Umfang setzen Sie diese Si-

mulationen ein?

Arbeiten Sie mit externen Dienstleisten für Produktanalysen zusammen? Wie

wird die Zusammenarbeit mit Dienstleistern koordiniert?

Wie viele Personen beschäftigen sich mit Simulation? Wie sind Ihre Simulati-

onstätigkeiten strukturiert? Zu welcher Organisationseinheit gehören die Simu-

lierer? Findet eine Kommunikation zwischen den Personen statt, die mit Simula-

tionsaufgaben betraut sind?

Wie qualifiziert sind Ihre Mitarbeiter für die Durchführung von Simulationen?

Existiert im Unternehmen eine ausformulierte, mit dem Management abge-

stimmte Strategie zum Ausbau der Simulationsaktivitäten?

Werden Simulationen bereits in frühen Phasen des Produktentwicklungsprozes-

ses durchgeführt? Wie wird die Simulation im Produktentwicklungsprozess be-

rücksichtigt?

Wie intensiv sind Ihre Entwickler über die verfügbaren Simulationsmöglichkei-

ten in Ihrem Hause informiert? Priorisieren Sie die Simulationsaufgaben?

Arbeiten Sie bei Ihren Simulationen nach definierten Arbeitsanweisungen?

Wie validieren Sie Ihre Simulationsmodelle? Welchen Einfluss haben die Simu-

lationsexperten auf das Labor?

Verwenden Sie Ihre CAD-Daten für die Simulation? Werden Ihre CAD-Daten

entsprechend der Simulationsaufgabe "vereinfacht" (bspw. entfernen nicht rele-

vanter Bohrungen)?

Wann testen Sie die Steuerung Ihrer Produkte? Führen Sie virtuelle Inbetrieb-

nahmen durch?

Kapitel 4: VPS-Leistungssteigerungsstrategie Seite 17


4 VPS-Leistungssteigerungsstrategie

Ziel dieses Abschnitts ist die Entwicklung einer Leistungssteigerungsstrategie für Ihre

Produktentwicklung mit dem speziellen Fokus auf Virtual Prototyping & Simulation.

Im Allgemeinen bildet eine Strategie für ein Unternehmen eine Art Rahmengerüst. Sie

beschäftigt sich mit der Entwicklung, Planung und Umsetzung inhaltlicher Ziele und

Ausrichtungen einer Organisation. SIMON fasst den Begriff der Strategie wie folgt zu-

sammen:

„Strategie ist die Kunst und die Wissenschaft, alle Kräfte eines Unter-

nehmens so zu entwickeln und einzusetzen, dass ein möglichst profi-

tables, langfristiges Überleben gesichert wird.“

Die Strategie muss unter Berücksichtigung der vorhandenen Stärken und Schwächen

und zukünftiger Erfolgspotentiale erarbeitet werden. Dazu müssen zunächst nötige Pro-

gramme und Maßnahmen definiert und strukturiert werden.

Durch den VPS-Benchmark und die VPS-Prozessanalyse sind Ihnen die Stärken und

Schwächen Ihrer Produktentwicklung bekannt. Es liegt eine Vielzahl von Maßnahmen

zur Verbesserung unterschiedlichster Unternehmensbereiche vor. Darüber hinaus bringt

das Prozessmodel zusätzliche Transparenz in die Produktentwicklung und schafft eine

gemeinsame Diskussionsgrundlage. Aufbauend auf diesen Ergebnissen kann die Leis-

tungssteigerungsstrategie entwickelt werden. Dazu werden die zuvor identifizierten

Maßnahmen anhand der Entwicklungsziele priorisiert und darauf aufbauend in einen

zeitlichen Kontext gebracht. Das Vorgehen hierzu gliedert sich in drei Phasen: „Formu-

lierung der Entwicklungsziele“, „Priorisierung der Maßnahmen“ und „Entwicklung der

Roadmap zur Umsetzung der Strategie“. Jede dieser Phasen wird im Folgenden detail-

liert.

4.1 Formulierung der Entwicklungsziele

Grundlage der Leistungssteigerungsstrategie sind die Entwicklungsziele, die Sie für die

Weiterentwicklung Ihrer Produktentwicklung anstreben. Diese gilt es zunächst zu for-

mulieren und zu priorisieren. Um das Selbstverständnis aller Prozessbeteiligten in die

Formulierung der Entwicklungsziele einfließen zu lassen, sollten diese in Form eines

Workshops ermittelt werden. Dabei wird von den Teilnehmern des Workshops in der

Regel eine Vielzahl von Entwicklungszielen diskutiert.

Bei der Formulierung hilft der in Bild 7 dargestellte Katalog. Dieser dient als Arbeits-

und Diskussionsgrundlage. Die enthaltenen Ziele sind in Leistungs-, Organisations-,

Sozial-, Kosten- und Zeitziele gegliedert. Der Katalog erhebt keinen Anspruch auf Voll-

ständigkeit.



1. Leistungs-, Organisations- und Sozialziele

1.1 Produkt- und Prozessqualität steigern

1.2 Wettbewerbsfähige und kostengünstige Produkte entwickeln

1.3 Teile wiederverwenden

1.4 Systemlösungen entwickeln

1.5 Forschungsaktivitäten und Inventionen unterstützen und steigern

1.6 Systematisierung der Abläufe steigern

1.7 Integrierte Produktentwicklung praktizieren

1.8 Arbeitsproduktivität steigern

1.9 Weiterbildung der Mitarbeiter steigern und optimieren

1.10 Innerbetriebliche Kooperation und Kommunikation optimieren

1.11 Kundeneinbindung und -zufriedenheit steigern

1.12 Zusammenarbeit mit Lieferanten optimieren

2. Kostenziele

2.1 Wirtschaftlichkeit erhöhen

2.2 Entwicklungskosten senken

2.3 Änderungskosten senken

3. Zeitziele

3.1 Entwicklungszeiten verkürzen

3.2 Änderungszeiten verkürzen

3.2 Time to Market (Markteintrittszeitpunkt) einhalten und verkürzen

Bild 7: Katalog unterschiedlicher Entwicklungsziele

Die diskutieren Ziele sind zu priorisieren. Dafür bieten sich zwei Verfahren an: der

paarweise Vergleich und die Abstimmung. Beim paarweisen Vergleich werden die

Entwicklungsziele jeweils paarweise in einer Matrix gegenübergestellt. Im Schnittpunkt

von zwei Zielen ist zu vermerken, welchem der beiden Ziele im direkten Vergleich die

höhere Priorität zugeordnet wird. Durch die Auswertung der absoluten Zahlen der Nen-

nungen ergibt sich die Rangfolge. Da die Änderungen einzelner Bewertungen nur ge-

ringen Einfluss auf das Ergebnis haben, kann mit Hilfe dieser Methode weitgehend ob-

jektiv die Priorität der Entwicklungsziele untereinander ermittelt werden.

Die zweite Möglichkeit zur Priorisierung der Ziele ist die Abstimmung mittels Klebe-

punkten. Jeder Workshop-Teilnehmer erhält mehrere Klebepunkte (in Abhängigkeit von

der Anzahl der herausgearbeiteten Entwicklungsziele) und ist aufgefordert, diese Punkte

auf die Ziele zu verteilen. Aus Gründen einer guten Handhabbarkeit sollten nicht mehr

als zehn Entwicklungsziele für die nächsten Schritte ausgewählt werden.



4.2 Priorisierung der Maßnahmen

Die Durchführung des VPS-Benchmarks sowie der VPS-Prozessanalyse liefert je nach

Ausgangssituation bis zu 100 Maßnahmen. Eine gleichzeitige Umsetzung all dieser

Maßnahmen ist nicht sinnvoll und auch nicht möglich. Eine Priorisierung der Maßnah-

men ist erforderlich. Hierzu liefert das Aufwand-Nutzen-Portfolio des VPS-Benchmarks

erste Hinweise. Zusätzlich sollte jedoch eine weitere Priorisierung der Maßnahmen an-

hand des Beitrags zu den Entwicklungszielen erfolgen.

Aufwand-Nutzen-Portfolio

Alle durch den VPS-Benchmark identifizierten Maßnahmen werden automatisch in ei-

nem Aufwand-Nutzen-Portfolio priorisiert. Ein solches Portfolio ist beispielhaft in Bild

8 dargestellt.

Bild 8: Maßnahmenportfolio

Für die Anordnung im Portfolio wurde jede Maßnahme nach Aufwand und Nutzen be-

wertet. Für den Aufwand wurden die Investitionskosten und Personalaufwände zur Um-

setzung der Maßnahme betrachtet. Der Nutzen wurde durch eine Bewertung der Zeit-

und Kosteneinsparung sowie der Qualitätssteigerung ermittelt. Da die exakten Kosten

und Nutzenwerte unternehmensindividuell sind, wurde die Bewertung mit Hilfe einer

Skala von null bis fünf durchgeführt. Die konkreten Bewertungen je Maßnahme finden

Sie in den Maßnahmensteckbriefen des VPS-Benchmarks. Je weiter rechts eine Maß-

nahme platziert ist, desto höher ist ihr Nutzen. Je höher die Maßnahme platziert ist, des-

to höher ist der Aufwand zur Umsetzung. Maßnahmen, die unten rechts liegen, sind für

eine baldige Umsetzung sehr interessant, da sie einen hohen Nutzen bei geringem Auf-

wand versprechen. Maßnahmen, die oben links liegen, versprechen trotz eines hohen

Aufwands nur einen geringen Nutzen. Eine Umsetzung dieser Maßnahmen sollte inten-

siv geprüft werden.



Bewertung anhand des Beitrags zu den Entwicklungszielen

Zusätzlich zur Priorisierung durch das Aufwand-Nutzen-Verhältnis sollten die Maß-

nahmen unternehmensindividuell anhand der zuvor ermittelten Entwicklungsziele prio-

risiert werden. Hierzu dient die in Bild 9 dargestellte Zielbeitragsmatrix.

Bild 9: Beispiel einer Zielbeitragsmatrix

In der Zielbeitragsmatrix werden in die Zeilenköpfe zunächst die Maßnahmen, geordnet

nach den jeweiligen Handlungsfeldern, eingetragen. In den Spaltenköpfen werden die

zuvor ermittelten Entwicklungsziele gelistet. Die Bewertung in der Matrix wird anhand

der Fragestellung vollzogen: Wie stark tragen die Maßnahmen zu den Entwicklungszie-

len bei? Es wird folgender vierstufiger Bewertungsmaßstab verwendet:

0 = kein Beitrag zum Entwicklungsziel

1 = schwacher oder zeitlich verzögerter Beitrag zum Entwicklungsziel

2 = mittlerer Beitrag zum Entwicklungsziel

3 = starker oder unmittelbarer Beitrag zum Entwicklungsziel

Aus der vollständig ausgefüllten Zielbeitragsmatrix kann anschließend ein Kennwert für

die Bedeutung jeder einzelnen Maßnahme abgeleitet werden. Dazu wird für jede Maß-

nahme die Zeilensumme gebildet. Sie zeigt die Stärke an, mit der die Maßnahme auf die

Gesamtheit der Entwicklungsziele wirkt. Je höher die Zeilensumme, desto wichtiger ist

die Umsetzung der Maßnahme. Aus dem Beispiel in Bild 9 geht hervor, dass die Maß-

nahmen „Entwicklungsprozess systematisieren“ und „Konstruktionsrichtlinie einfüh-

ren“ von besonderer Bedeutung sind. Aus der Zeilensumme aller Maßnahmen kann nun

eine unternehmensindividuelle Rangfolge zur Erreichung der Entwicklungsziele abge-

leitet werden.

En

twic

klu

ng

szie

l

Teile

wie

derv

erw

enden

Weiterb

ildung d

er

Mitarb

eiter

Änderu

ngskoste

n

senken

… Zie

lbeit

rag

Handlungsfeld Maßnahme Nr. A B C … ∑

Arbeitsgruppe Prozessverbesserung gründen 1 2 0 3 10 15

Entwicklungsprozess systematisieren 2 1 0 3 15 19

Schulungsprogramm erarbeiten 3 0 3 0 5 8

… … 0

3D-CAD-Einsatz ausbauen 16 2 0 2 10 14

Konstruktionsrichtlinie einführen 17 3 0 1 15 19

… … 0


Konstruktionswerkzeuge

Zielreifegradmatrix

Fragestellung: "Wie stark tragen die Maßnahmen zu den

Entwicklungszielen bei?"

0 = kein Beitrag zum Entwicklungsziel

1 = schwacher oder zeitlich verzögerter Beitrag zum Entwicklungsziel

2 = mittlerer Beitrag zum Entwicklungsziel

3 = starker oder unmittelbarer Beitrag zum Entwicklungsziel



4.3 Roadmap zur Maßnahmenumsetzung

Basierend auf der Priorisierung der Maßnahmen kann in einem nächsten Schritt deren

Umsetzungsreihenfolge geplant werden. Bei der Planung der Umsetzungsreihenfolge ist

zu beachten, dass die Maßnahmen Abhängigkeiten untereinander haben. So kann es

sein, dass einige Maßnahmen erst angegangen werden können, wenn andere bereits um-

gesetzt wurden. Bei einigen empfiehlt sich auch eine gleichzeitige Umsetzung. Das

Aufwand-Nutzen-Portfolio sowie die Priorisierung nach den Entwicklungszielen bilden

diese Abhängigkeiten der Maßnahmen nicht ab. Um dieses bei der Planung zu berück-

sichtigen, bietet es sich an, eine externe Beratung hinzuzuziehen.

Eine zwingende Umsetzungsreihenfolge muss berücksichtigt werden, wenn die Mög-

lichkeit der Umsetzung einer Maßnahme nicht gegeben ist, ohne dass eine andere Maß-

nahme zuvor umgesetzt wurde. So ist bspw. die Maßnahme „3D-CAD-System einfüh-

ren“ für die Umsetzung der Maßnahme „3D-CAD-Einsatz ausbauen“ notwendig. Prüfen

Sie, welche Abhängigkeiten es bei den Maßnahmen gibt. Maßnahmen, die viele Vo-

raussetzungen brauchen, sollten im ersten Schritt vernachlässigt werden. Maßnahmen,

die viele weitere Maßnahmen ermöglichen, sind für eine schnelle Umsetzung interes-

sant.

Bei einigen Maßnahmen ist eine unabhängige Durchführung zwar möglich, dennoch

kann eine gleichzeitige Umsetzung zu Synergieeffekten führen. Bspw. muss die Maß-

nahme „PDM-System einführen“ vor der Maßnahme „Workflows durch IT-System un-

terstützen“ durchgeführt werden. Die Workflowintegration könnte zu einer beliebigen

Zeit nach der PDM-Einführung stattfinden. Jedoch empfiehlt es sich, die Workflows

gemeinsam mit der PDM-Einführung zu etablieren. Bei der Einführung werden die Un-

ternehmensprozesse ohnehin analysiert und das System auf das Unternehmen angepasst.

Der Aufwand, diese Maßnahmen gleichzeitig durchzuführen, ist so deutlich geringer,

als wenn jede Maßnahme für sich durchgeführt werden würde. Prüfen Sie, welche Sy-

nergieeffekte es bei den Maßnahmen gibt. Maßnahmenkombinationen, die hohe Syner-

gieeffekte aufweisen, sollten nach Möglichkeit gemeinsam umgesetzt werden.

Eine Möglichkeit, die Planung der Maßnahmenumsetzung zu visualisieren, ist die Ent-

wicklung einer Roadmap bzw. eines Maßnahmenkalenders. Gemeint ist damit ein Plan,

aus dem hervorgeht, wann welche Maßnahme für welches Entwicklungsziel umzusetzen

ist. Bild 10 zeigt in stark vereinfachter Form eine solche Roadmap.



Bild 10: Beispiel einer Roadmap zur zeitlichen Planung der Maßnahmenumsetzung

In der Waagerechten sind zunächst die für das Unternehmen relevanten Entwicklungs-

ziele aufgeführt. Darunter werden die Maßnahmen zu den jeweiligen Handlungsfeldern

aufgeführt. Durch die Positionierung der Maßnahmen auf der Zeitachse wird angege-

ben, in welchem Zeitraum die jeweilige Maßnahme umgesetzt wird. Der Beitrag der

Maßnahme zur Erreichung der Entwicklungsziele wird über eine senkrechte Verbin-

dung mit den Entwicklungszielen dargestellt. In der Regel wirkt eine Maßnahme dabei

auf mehrere Entwicklungsziele.


2013 20142012 2015 2016

1. Teile wiederverwenden

Entwicklungsziele

2. Weiterbildung der Mitarbeiter

3. Änderungskosten senken

4. …

Konstruktionswerkzeuge

3D-CAD-Einsatz

ausbauen

Arbeitsgruppe Prozess-

verbesserung

Schulungsprogramm

erarbeiten

Konstruktionsrichtlinie einführen

Entwicklungsprozess

systematisieren

A Inhaltverzeichnis Seite 23


Anhang

Inhaltsverzeichnis Seite

A1 Einführung von IT-Systemen ................................................................ 24

A2 Die Methode OMEGA ........................................................................... 27

A2.1 Konstrukte ............................................................................................ 27

A2.1.1 Externe Objekte ......................................................................... 29

A2.1.2 Bearbeitungsobjekte .................................................................. 29

A2.1.3 Technische Ressourcen ............................................................ 30

A2.1.4 Kopplung von Geschäftsprozessen ........................................... 32

A2.1.5 Entscheidungen ......................................................................... 33

A2.1.6 Konnektoren .............................................................................. 34

A2.1.7 Abgrenzungen (Splitting- und Synchronisationslinien) .............. 36

A2.2 Modellierung ......................................................................................... 37

A2.2.1 Modellierungsrichtlinien ............................................................. 37

A2.2.2 Anordnung der Konstrukte bezogen auf einen

Geschäftsprozess ...................................................................... 37

A2.2.3 Detaillierungsgrad, Hierarchisierung und Aggregation von

Geschäftsprozessmodellen ....................................................... 37

A2.3 Aufnahme ............................................................................................. 41

A2.3.1 Moderationstechniken ............................................................... 41

A2.3.2 Fazit ........................................................................................... 45

A1 Einführung von IT-Systemen Seite 24


A1 Einführung von IT-Systemen

Die Einführung eines umfassenden IT-Systems stellt einen wesentlichen Meilenstein in

der Entwicklung eines Unternehmens dar. Grundlagen dafür sind wohlstrukturierte Ge-

schäftsprozesse und eine stimmige IT Strategie. Die IT-Einführung hat nicht nur zum

Ziel, alte Anwendungen gegen neue auszutauschen; in der Hauptsache geht es um die

Effizienzsteigerung der Geschäftsprozesse.

Zwei Aspekte sind für die erfolgreiche IT-Einführung von besonderer Bedeutung: das

so genannte Business IT Alignment und Projektmanagement.

Unter Business IT Alignment wird die Ausrichtung der IT an den Geschäftsaktivitäten

und -zielen verstanden. Der Einsatz von IT darf keinen Selbstzweck darstellen, sondern

soll in hohem Maße das Geschäftsergebnis positiv beeinflussen. Business IT Alignment

schafft die Grundlage, dass einerseits Geschäftsabläufe wirkungsvoll und effizient durch

IT-Systeme unterstützt werden und andererseits wohlstrukturierte Geschäftsabläufe den

wirtschaftlichen Betrieb von IT-Systemen ermöglichen. Wie in Bild 1 dargestellt, sind

Aufbauorganisation, Geschäftsprozesse und Ressourcen auf der Seite des operativen

Geschäfts mit der IT-Architektur, der IT-Infrastruktur, der IT-Prozesse und der IT-

Ressourcen auf der Seite der operativen IT abzustimmen.

Business IT Alignment ist keine einmalige Aktion, sondern als permanenter Prozess zu

verstehen und im Unternehmen ganzheitlich zu leben. Auf der Basis dieses Grundver-

ständnisses wird sichergestellt, dass es zu gut begründeten ausgewogenen Investitions-

entscheidungen kommt und die Informationstechnik den maximal möglichen Nutzen

entfaltet.

Projektmanagement ist der zweite wichtige Aspekt bei der Einführung von IT-

Systemen. Neben den klassischen Projektmanagementaufgaben Planung, Kontrolle und

Steuerung sind sozialkommunikative Faktoren für den Projekterfolg entscheidend. Eine

hohe Integration und Partizipation der späteren Anwender aus den Fachabteilungen ver-

bunden mit einem ganzheitlichen methodischen Vorgehen verstärkt die Bindung zwi-

schen dem operativen Geschäft und der IT-Organisation. Ein wirkungsvolles Manage-

ment von IT-Einführungsprojekten erfordert ein Vorgehensmodell. Das von uns emp-

fohlene Vorgehensmodell ist in Bild 2 dargestellt. Es weist vier Phasen auf.



Bild 11: Business IT Alignment verknüpft operatives Geschäft und operative IT

1. Aufgaben- und Anforderungsanalyse: Ausgehend von den Soll-

Geschäftsprozessen sind im Wesentlichen die Funktionalität des geplanten Systems

sowie die Informationen und Informationsstrukturen zu definieren. Ergebnis ist das

Lastenheft

2. Systemauswahl: Hier werden mit Hilfe von Marktanalysen und Systempräsentati-

onen geeignete Systeme verglichen. Der Kosten- und Nutzenvergleich sowie die

Wirtschaftlichkeitsanalyse bestimmen die Entscheidung für einen Anbieter. Als fi-

nale Ergebnisse liegen ein Pflichtenheft und ein IT-Vertrag vor.

3. Systemeinführung: Die dritte Phase beinhaltet die Aktionen in Hinblick auf die

Inbetriebnahme des neuen IT-Systems. Wesentliche Aufgaben sind das Projektma-

nagement, das Customizing, die Vorbereitung der Datenmigration, das Testen und

die Schulung der Anwender. Am Ende ist das IT-System betriebsbereit.

4. Roll-out: Darunter ist im Allgemeinen die eigentliche Einführung des betriebsbe-

reiten IT-Systems zu verstehen. Ein wesentlicher Meilenstein ist die Abnahme des

Systems.

Bild 12: Vorgehen bei der IT-Einführung



In der Praxis zeigt sich, dass Unternehmen bei der Einführung neuer Systeme überwie-

gend auf Standardsoftware zurückgreifen und Individuallösungen oftmals abgelöst wer-

den. Dafür gibt es oft gute Gründe: Die Erstellung, ständige Erweiterung und Pflege der

Individualsoftware hat sich vielerorts als Fass ohne Boden erwiesen; trotz hoher Auf-

wendungen konnte mit dem Stand der Technik nicht mitgehalten werden; die Know-

how-Träger werden rar.

Herausforderung IT-Einführung

Sich für das richtige IT-System und den passenden Anbieter zu entscheiden, ist bei ei-

ner derart komplexen Investitionsentscheidung nicht einfach. Im Bereich der ERP-

Lösungen sind zum Beispiel aktuell in Deutschland ca. 500 Systeme von mehr als 1.000

Anbietern am Markt verfügbar. Demzufolge gestaltet sich die Auswahl schwierig, zu-

mal auch die Möglichkeit zur Realisierung einer Individuallösung besteht.

Die Einführung des Systems ist dann besonders heikel, wenn die eigenen Mitarbeiter

nur unzureichende Erfahrung im Management von IT-Projekten haben. Häufig fehlt

auch schlicht die Personalkapazität. Somit stellt sich die Frage, wie ein derartiges Pro-

jekt mit einem hohen Anspruch an Investitionssicherheit erfolgreich abgewickelt wer-

den kann.

Vor dem Hintergrund, dass ein Unternehmen im Schnitt alle sieben Jahre ein solches

Projekt angeht, empfiehlt sich der Einsatz externer Fachleute. Externe Unterstützung ist

dann zu empfehlen, wenn

• das erforderliche Wissen für ein spezialisiertes Projektmanagement nicht vorhanden

ist,

• kaum Erfahrungen mit Projekten zur IT-Auswahl und IT-Einführung vorliegen,

• Wissen aus vergleichbaren Projekten Mehrwerte liefern kann und

• eine neutrale Instanz gefragt ist, weil die erforderliche Sachentscheidung durch Be-

reichspolitik, Gewohnheiten etc. überlagert wird.

Ausprägungen externer Beratung in IT-Einführungsprojekten reichen heute vom Pro-

jekt-Coaching mit der Vermittlung von Methoden über die Begleitung als Fachmodera-

tor und Vermittler der Auftraggeberinteressen gegenüber dem Softwareanbieter bis zum

Generalunternehmer.

A2 Die Methode OMEGA Seite 27


A2 Die Methode OMEGA

Die Methode OMEGA (Objektorientierte Methode zur Geschäftsprozessmodellierung

und -analyse) entstand am Heinz Nixdorf Institut und wurde zusammen mit der UNITY

AG weiterentwickelt. Ziel war eine Methode, welche einerseits die vollständige Model-

lierung einer Ablauforganisation in einem Modell ermöglicht und die sich andererseits

mittels einfacher und prägnanter Visualisierung als Instrument zur anschaulichen Ana-

lyse und Planung von Leistungserstellungsprozessen eignet.

Die vollständige Modellierung einer Ablauforganisation bedeutet, sowohl die Objekte

der Aufbau- als auch die Objekte der Prozessorganisation des Unternehmens in einer

Graphik abzubilden. Dies geschieht durch Zuordnen von Organisationseinheiten zu Ge-

schäftsprozessen.

Die Erfahrung zeigt, dass mit der Methode OMEGA modellierte Geschäftsprozessmo-

delle intuitiv verständlich sind. Durch die Beschränkung auf die wesentlichen Objekte

eines Geschäftsprozesses ist die Methode über alle Unternehmensebenen hinweg ein-

setzbar. Die Modelle zeichnen sich durch eine hohe Flexibilität bei der Darstellung pro-

jekt- und unternehmensspezifischer Inhalte aus. Darüber hinaus lassen sich aus diesen

Modellen die formalen Prozessspezifikationen für Produktdatenmanagementsysteme

(z.B. Konstruktionsfreigabeprozess) und für Workflowmanagementsysteme ableiten.

A2.1 Konstrukte

Die Methode OMEGA stellt eine graphische Notation zur Verfügung, die alle wesentli-

chen Sachverhalte anschaulich verdeutlicht, und den Modellierer bei der Modell- Ent-

wicklung weitestgehend von textuellen Angaben befreit. OMEGA bildet Prozessketten,

die Informations- und Materialflüsse sowie die Parallelität von Prozessen graphisch ab.

Die Modell-Analyse besteht aus einer Auswertung der in der Modell-Entwicklung er-

fassten Sachverhalte und liefert Hinweise auf mögliche Schwachstellen. Für die Model-

lierung der Ablauforganisation stellt OMEGA die folgenden Konstrukte bereit:

• Geschäftsprozesse und Aktivitäten,

• Organisationseinheiten,

• Externe Objekte,

• Bearbeitungsobjekte,

• Technische Ressourcen,

• Kommunikationsbeziehungen.

Bild 1 gibt einen Überblick über die Konstrukte der Methode OMEGA. Die Bedeutung

und die Notation der einzelnen Elemente werden in den nachfolgenden Abschnitten

detailliert erläutert.



Bild 1: Überblick über die Konstrukte der Methode OMEGA

Geschäftsprozesse

Ein Geschäftsprozess ist eine Folge logisch zusammenhängender Ak-

tivitäten zur Erbringung eines Ergebnisses oder zur Veränderung eines

Objekts (Transformation). Er besitzt einen definierten Anfang (Auslö-

ser oder Input) und ein definiertes Ende (Ergebnis oder Output). Ein

Geschäftsprozess wird durch die Kombination seines Namens, der aus

einem Substantiv und einem Verb besteht (z.B. Bestelldaten erfassen),

mit der Zuordnung zu einem Hauptgeschäftsprozess eindeutig be-

schrieben.

Geschäftsprozesse können – unter Verwendung des gleichen Symbols

– beliebig in Teilprozesse zerlegt oder zu Hauptgeschäftsprozessen

aggregiert werden. Mit Hilfe dieser Hierarchisierung lassen sich Pro-

zessmodelle mit beliebigem Detaillierungsgrad erstellen.

Beispiele: Bestelldaten erfassen, Entwicklung durchführen, Angebot

erstellen

Organisationseinheiten

Eine Organisationseinheit repräsentiert eine Stelle der Aufbauorgani-

sation (Abteilung, Team, Arbeitsplatz etc.), die den Geschäftsprozess

ausführt bzw. verantwortet. Eine Organisationseinheit kann mehrfach

in einem Prozessmodell verwendet werden.

Die für die Ausführung verantwortliche Organisationseinheit wird

durch einen Rahmen dargestellt, der den Geschäftsprozess umschließt.

Wird ein Geschäftsprozess von einer IT-Applikation automatisch aus-

geführt, d.h. es ist keine Organisationseinheit daran beteiligt, so wird

dies dargestellt, indem kein Name in den Kasten eingetragen wird.

Beispiele: Entwicklung/Konstruktion, Einkauf, Verwaltungsleitung



A2.1.1 Externe Objekte

Externe Objekte sind Einheiten der Systemumwelt, sie stellen somit die Schnittstellen

eines Prozesses zu seiner Umwelt dar. Externe Objekte repräsentieren Personen, Perso-

nengruppen, Institutionen, Firmen etc. außerhalb des betrachteten Systems. Sie senden

und empfangen Bearbeitungsobjekte. Externe Objekte werden eindeutig durch ihren

Namen beschrieben und können mehrfach in einem Prozessmodell verwendet werden.

OMEGA unterscheidet zwischen:

Externen Objekten außerhalb der Organisation

Beispiel: Zulieferer, Auftraggeber

Externen Objekten außerhalb des Untersuchungsbereiches, die

jedoch grundsätzlich zur Organisation des betrachteten Sys-

tems gehören

Beispiel: unternehmensinterner Kunde, Vertriebsniederlassung

A2.1.2 Bearbeitungsobjekte

Bearbeitungsobjekte sind Ein- und Ausgangsgrößen von Geschäftsprozessen. In der

Regel ist ein Bearbeitungsobjekt, das von einem Prozess erzeugt bzw. transformiert

wird, ein Inputobjekt für einen nachfolgenden Prozess. Wird ein eingehendes Bearbei-

tungsobjekt geändert oder erweitert, so ist dies bei der Modellierung mit einem Status

zu vermerken, der sich im Namen wiederfinden kann. Alle Objekte sind eindeutig zu

benennen. OMEGA unterscheidet folgende Bearbeitungsobjekte:

• IT-Objekt,

• Papierobjekt,

• mündliche Information,

• Materialobjekt,

• Informationsgruppe.

Neben den Geschäftsprozessen liefern und empfangen die externen Objekte und die

technischen Ressourcen Bearbeitungsobjekte.

IT-Objekt

Ein IT-Objekt stellt ein Bearbeitungsobjekt eines Geschäftsprozesses

in einer durch ein IT-System verarbeitbaren digitalen Form dar. Ein

IT-Objekt entsteht, wenn ein Geschäftsprozess bei der Erzeugung ei-

nes Output-Objektes durch eine IT-Applikation (z.B. ERP-System)

unterstützt wird.

Beispiele: E-Mail, 3D-CAD-Modell (Datei)

Papierobjekt



Ein Papierinformationsobjekt stellt ein Bearbeitungsobjekt auf dem

Medium Papier dar.

Beispiele: Formular, Checkliste, Zeichnung

Mündliches Informationsobjekt

Ein mündliches Informationsobjekt ist ein Bearbeitungsobjekt für ei-

nen Geschäftsprozess in mündlicher Form. Dabei handelt es sich um

eine Information, die weder formal fixiert noch reproduzierbar ist. Ein

mündliches Informationsobjekt kann durch den Inhalt der Nachricht

spezifiziert werden.

Beispiele: persönliches Gespräch, Telefonanruf (telefonische Über-

mittlung eines Auftrags)

Materialobjekt

Ein Materialobjekt ist ein Bearbeitungsobjekt in Form von Material.

Damit kann der Material-/Produktfluss innerhalb eines Unternehmens

abgebildet werden.

Beispiele: Halbzeug, Fertigprodukt

Informationsgruppe

Eine Informationsgruppe besteht aus mehreren Informationsobjekten.

Dabei handelt es sich um eine beliebige Kombination aus IT-

Objekten, Papierobjekten, mündlichen Informationsobjekten und Ma-

terialobjekten. Das Konstrukt kombiniert die Konstrukte aller mögli-

chen Bestandteile der Informationsgruppe.

Beispiele: Software-Paket inkl. Datenträger und Versanddokumente

A2.1.3 Technische Ressourcen

Technische Ressourcen unterstützen die Durchführung von Geschäftsprozessen. Alle

Ressourcen sind eindeutig zu benennen. OMEGA unterscheidet vier Arten von techni-

schen Ressourcen, die im Folgenden näher erläutert werden:

• IT-Applikation bzw. Speicher,

• Betriebsmittel,

• Papierspeicher,

• Materialspeicher.

IT-Applikation bzw. Speicher

IT-Applikationen unterstützen die Ausführung von Geschäftsprozes-

sen. Sie speichern Informationen, verarbeiten diese und stellen sie zur

Verfügung. Eine IT-Applikation kann mehrfach in einem Geschäfts-

prozessmodell vorhanden sein und wird durch einen Computer sym-

bolisiert.



Beispiele: Textverarbeitungsprogramm, Desktop-CADSystem, ERP-

System

Betriebsmittel

Ein Betriebsmittel unterstützt die Geschäftsprozesse, indem es Materi-

al transformiert oder transportiert. Das Betriebsmittel selbst kann kein

Material speichern. Es kann jedoch Informationsobjekte (z.B. NC-

Programme, Betriebsdaten) empfangen, speichern oder zur Verfügung

stellen. Betriebsmittel können durch ihren Standort spezifiziert wer-

den.

Beispiele: Bearbeitungszentrum, Portalroboter

Papierspeicher

Ein Papierspeicher speichert Papierobjekte oder stellt diese zur Verfü-

gung. Er kann durch die Angabe seines räumlichen Standortes und

seiner Art (z.B. Ablage/Vertrieb) spezifiziert werden.

Beispiele: Ablageordner, Archiv, Lieferantenregister

Materialspeicher

Materialspeicher speichern Materialobjekte oder stellen diese zur Ver-

fügung. Es ist zwischen Lagern und Puffern zu unterscheiden.

Lager: Ein Materialspeicher ist immer dann ein Lager, wenn er mit ei-

nem bestandsführenden Geschäftsprozess in Verbindung steht.

Beispiele: Rohteile-, Zukaufteile- und Fertigteilelager

Puffer: Wird Material in einem Materialspeicher gepuffert, existiert

kein bestandsführender Geschäftsprozess, d.h. die Bestände in diesem

Puffer werden nicht erfasst.

Beispiele: Arbeitsplatzpuffer, in dem das Material vor einem Arbeits-

platz auf seine Bearbeitung wartet

Materialspeicher können durch ihren Standort spezifiziert werden.

Kommunikationsbeziehungen

Kommunikationsbeziehungen verketten Geschäftsprozesse, externe

Objekte und technische Ressourcen. Eine Kommunikationsbeziehung

hat immer genau einen Sender und einen Empfänger und legt so die

Kommunikationsrichtung fest. Durch Platzieren der Bearbeitungsob-

jekte auf den Kommunikationsbeziehungen werden die Informations-

und Materialflüsse im Prozessmodell sichtbar. Kommunikationsbezie-

hungen übermitteln Bearbeitungsobjekte

• zwischen Geschäftsprozessen untereinander,

• zwischen Geschäftsprozessen und externen Objekten sowie

• zwischen Geschäftsprozessen und technischen Ressourcen.



Eine Kommunikationsbeziehung wird als Pfeil dargestellt. Es wird

immer mindestens ein Bearbeitungsobjekt übertragen, welches auf

dem Pfeil zu platzieren ist.

Beispiel: Übertragung eines Fertigungsauftrags von der Arbeitsvorbe-

reitung an die Fertigung

A2.1.4 Kopplung von Geschäftsprozessen

Geschäftsprozesse können auf verschiedene Arten mit Kommunikationsbeziehungen

gekoppelt werden. Diese sind in Bild 2 dargestellt.

• Direkte Kopplung: Eine direkte Kopplung zwischen Geschäftsprozessen liegt

vor, wenn ein Geschäftsprozess einem anderen Geschäftsprozess ein Bearbei-

tungsobjekt direkt und unmittelbar übermittelt. Bei einer direkten Kopplung

wird der Empfänger vom Sender zur Ausführung seiner Aktivität angestoßen.

Beispiel: Fertigungsauftrag wird an Fertigung gesandt und löst Produktion aus

• Indirekte Kopplung (Speicherkopplung): Bei der Speicherkopplung besteht

keine direkte logische und zeitliche Verknüpfung zwischen dem erzeugenden

Geschäftsprozess und dem weiterverwendenden Geschäftsprozess. Sie sind indi-

rekt über eine technische Ressource gekoppelt: Der erzeugende Geschäftspro-

zess speichert das Bearbeitungsobjekt in einer technischen Ressource (IT-

Applikation, Materialspeicher etc.). Der weiterverwendende Geschäftsprozess

entnimmt es aus dieser, ohne dass die Prozesse direkt miteinander kommunizie-

ren.

Beispiel: Auftrag wird erfasst und im ERP-System abgelegt; zu einem späteren Zeit-

punkt wird der Auftrag bearbeitet und eine Bestätigung versandt

Kommunikationsbeziehungen zwischen Geschäftsprozessen und externen Objekten

bzw. technischen Ressourcen erfolgen in der Regel über eine direkte Kopplung. Die

indirekte Kopplung tritt vermehrt bei IT-unterstützten Arbeitsabläufen im Unternehmen

auf. Kommunikationsbeziehungen, die kein Bearbeitungsobjekt übertragen, treten in

den Geschäftsmodellen bei korrekter Anwendung der Methode OMEGA nicht auf.



Bild 2: Direkte und indirekte Kopplung von Geschäftsprozessen

A2.1.5 Entscheidungen

Durch die Modellierung von Entscheidungen lassen sich logische Abhängigkeiten zwi-

schen Geschäftsprozessen darstellen. OMEGA unterscheidet folgende Entscheidungen:

• UND-Entscheidungen,

• ODER-Entscheidungen,

• EXKLUSIV-ODER-Entscheidungen.

Entscheidungen können sowohl einen Prozess in mehrere Abschnitte verzweigen als

auch mehrere Teilprozesse zusammenführen. Die Kriterien für EXKLUSIV-ODER-

Entscheidungen sind neben den zugehörigen Kommunikationsbeziehungen anzugeben

(vgl. Bild 3).

Der überwiegende Teil von Entscheidungen, die in Geschäftsprozessmodellen verwen-

det werden, sind UND-Entscheidungen. Werden in einem Geschäftsprozessmodell aus-

schließlich UND-Entscheidungen verwendet, ist die Benutzung des Konstrukts wahl-

frei. Wird das Konstrukt nicht modelliert, steht die Verzweigung bzw. die Verknüpfung

zweier Kommunikationsbeziehungen für eine UND-Entscheidung. Werden in einem

Geschäftsprozessmodell ODER- bzw. EXKLUSIV –ODER-Entscheidungen verwendet,

sind die Konstrukte zwingend zu verwenden. In diesem Fall gilt das auch für das Kon-

strukt der UND-Entscheidung.



Bild 3: Modellierungsbeispiel logischer Entscheidungen

UND-Entscheidung: Die UND-Entscheidung löst alle nachfolgenden

Prozesse aus, sobald das Bearbeitungsobjekt vorliegt bzw. gibt den

nächsten Prozessschritt erst dann frei, wenn die Bearbeitungsobjekte

der vorhergehenden Prozesse vorliegen.

ODER-Entscheidung: Die ODER-Entscheidung löst einen oder meh-

rere der nachfolgenden Prozessschritte aus, sobald das Bearbeitungs-

objekt vorliegt bzw. gibt den nächsten Prozessschritt frei, sobald eines

oder mehrere der Bearbeitungsobjekte der vorhergehenden Prozess-

schritte vorliegen.

EXKLUSIV-ODER-Entscheidungen: Die EXKLUSIV-ODER-

Entscheidung löst genau einen der nachfolgenden Prozessschritte aus,

sobald das Bearbeitungsobjekt vorliegt. Die Kriterien für die Ent-

scheidung sind auf den zugehörigen Kommunikationsbeziehungen an-

zugeben. Die Verknüpfung zweier Kommunikationsbeziehungen mit

einer EXKLUSIV-ODER-Entscheidung tritt nicht auf.

A2.1.6 Konnektoren

Durch das Modellieren von Kommunikationsbeziehungen zwischen Geschäftsprozes-

sen, die auf der Darstellungsebene weit entfernt sind, wird das Modell leicht unüber-

sichtlich. Um die Übersichtlichkeit des Prozessmodells zu wahren, können solche



Kommunikationsbeziehungen mit Hilfe von Konnektoren unterbrochen werden. Die

Konnektoren dienen dabei als Verweis zwischen den gekoppelten Geschäftsprozessen

(Bild 4).

Potentiale

Das Symbol wird verwendet, um in einem Prozess eine Schwachstelle

bzw. ein Verbesserungspotential im Ablauf zu kennzeichnen.

Beispiele: Mangelnde Anzahl schlüssiger Ideen/Konzepte, Meilen-

steine werden häufig nicht erreicht, hohe Durchlaufzeiten, Aufgabe/

Kompetenz/Verantwortung nicht geklärt bzw. festgelegt

Fähigkeiten

Das Symbol wird verwendet, um in einem Prozess eine besondere Fä-

higkeit zu kennzeichnen, die bereits vorhanden bzw. erforderlich ist,

um den Prozess durchzuführen.

Beispiele: Projektmanagement, Analyse dynamisches Verhalten von

Mehrkörpersystemen

Methoden

Eine Methode ist eine bewährte Abfolge von Arbeitsschritten, um ein

bestimmtes Ergebnis zu erzielen. Methoden unterstützen die Durch-

führung von Geschäftsprozessen. Sie sind eindeutig zu benennen und

können in einem oder mehreren Geschäftsprozessen verwendet wer-

den. Das Symbol wird auf der linken oberen Ecke des Symbols einer

Organisationseinheit (Rahmen) platziert (vgl. Bild 1).

Beispiele: Morphologischer Kasten, Quality Function Deployment,

Methode 635

Kennzahlen

Kennzahlen dienen dem Controlling und der Steuerung von Ge-

schäftsprozessen. Das Symbol gibt den Hinweis auf eine im Prozess

genutzte Kennzahl zur Messung der Leistungsfähigkeit bzw. der Er-

gebnisse eines Prozesses. Kennzahlen sind eindeutig mit einem Na-

men oder einer Formel zu kennzeichnen. Das Symbol wird auf der

rechten oberen Ecke des Symbols einer Organisationseinheit (Rah-

men) platziert (vgl. Bild 1).

Beispiele: Reifegrad des in Entwicklung befindlichen Produktes, An-

zahl erteilter Patente



Bild 4: Kommunikationsbeziehung mit Konnektoren

Meilensteine

Meilensteine kennzeichnen Zwischenergebnisse und Entscheidungs-

punkte im Prozess- bzw. Projektablauf. Um einen Meilenstein festzu-

stellen und die nachfolgenden Prozessschritte freizugeben, müssen de-

finierte Ergebnisse vorliegen bzw. Ziele erreicht sein. Meilensteine

werden in der Regel als Messpunkte zur Erreichung von Gesamtpro-

zesszielen genutzt. Meilensteine erhalten einen Identifikator. An ei-

nem Meilenstein sind die Personen anzugeben, die an der Abnahme-

bzw. Freigabeentscheidung beteiligt sind (kleines Quadrat). Der Ent-

scheider ist hervorzuheben (kleines dunkles Quadrat).

Beispiele: Festlegung Lastenheft, Freigabe Serienentwicklung

A2.1.7 Abgrenzungen (Splitting- und Synchronisationslinien)

Insbesondere die Produktentstehung ist durch eine starke Vernetzung der einzelnen Pro-

zesse gekennzeichnet. Das gilt besonders für mechatronische Erzeugnisse. Beispiels-

weise sind hier Produktkonzipierung und Fertigungsplanung in engem Wechselspiel

voranzutreiben. Die Darstellung aller Kommunikationsbeziehungen führt oft dazu, dass

das Modell der Ablauforganisation unübersichtlich und schwer lesbar wird. Abgrenzun-

gen dienen dazu, die Modellierung von vernetzter Zusammenarbeit zwischen verschie-

denen Domänen oder Organisationseinheiten zu vereinfachen.

Bei der Darstellung vernetzter Zusammenarbeit mit Splitting und Synchronisation müs-

sen nicht mehr alle Kommunikationsbeziehungen modelliert werden, sondern nur dieje-

nigen zwischen den Prozessen der einzelnen Domänen. Abgrenzungen implizieren,

dass innerhalb der Splitting- und Synchronisationslinien sämtliche Geschäftsprozesse

untereinander verkettet sind. Die Notation von Abgrenzungen ist in Bild 5 abgebildet –

im oberen Teil ohne, im unteren Teil mit Nutzung von Abgrenzungen. Abgrenzungen

können durch einen Namen gekennzeichnet werden.



A2.2 Modellierung

A2.2.1 Modellierungsrichtlinien

Die Anwendung der vorgestellten Konstrukte zur Geschäftsprozessmodellierung unter-

liegt einigen einfachen Modellierungsrichtlinien, die im Folgenden erläutert werden.

Diese erleichtern die Modellierung und sorgen für die Verständlichkeit und Übersicht-

lichkeit der Geschäftsprozessmodelle.

A2.2.2 Anordnung der Konstrukte bezogen auf einen Geschäftsprozess

Zunächst soll die Anordnung und Verknüpfung der Konstrukte erläutert werden (Bild

6). Der Geschäftsprozess wird in der oberen Hälfte seiner ausführenden Organisations-

einheit platziert. Dem Geschäftsprozess kann in Ergänzung zu seiner Bezeichnung ein

Identifikator zugeordnet werden. Dieser wird oberhalb des Geschäftsprozesses notiert.

Der Name der Organisationseinheit steht innerhalb des Rahmens unten links. Die tech-

nischen Ressourcen (Betriebsmittel, IT-Applikation, Papierspeicher, Materialspeicher)

sind entlang des unteren Randes der Organisationseinheit zu platzieren. Der Raum un-

terhalb der Organisationseinheit kann für ergänzende Definitionen, Kommentare, Erläu-

terungen und Beschreibungen genutzt werden.

Die Verknüpfung zwischen Geschäftsprozessen, externen Objekten und technischen

Ressourcen erfolgt durch die direkten und indirekten Kommunikationsbeziehungen, die

als Pfeile dargestellt werden. Auf den Kommunikationsbeziehungen werden die Bear-

beitungsobjekte (mündliche Information, IT-Objekt, Papierobjekt, Materialobjekt, In-

formationsgruppe) angeordnet, die im Geschäftsprozess bearbeitet werden (Input-

Objekte) bzw. aus ihm als Ergebnis hervorgehen (Output-Objekte). Bearbeitungsobjekte

durchlaufen einen Geschäftsprozess immer von links nach rechts – entsprechend gelan-

gen Input-Objekte von links in den Geschäftsprozess und Output-Objekte verlassen ihn

rechts.

A2.2.3 Detaillierungsgrad, Hierarchisierung und Aggregation von Ge-

schäftsprozessmodellen

Für die Erstellung von Geschäftsprozessmodellen ist ein der Problemstellung angemes-

sener Detaillierungsgrad (Modellierungstiefe) zu wählen. Unterschiede in der Modellie-

rungstiefe innerhalb eines Modells (eines Prozessplots) sollten unbedingt vermieden

werden. Die Wahl des Detaillierungsgrads hängt von der Komplexität des jeweiligen

Untersuchungsbereichs und der Zielsetzung des Projekts ab. Der Detaillierungsgrad

eines Geschäftsprozessmodells kann variiert werden, indem – ausgehend von einer bis-

herigen Modellierungsebene – die Modell - Elemente aggregiert oder detailliert werden.

Aggregierte Geschäftsprozessmodelle bieten den Vorteil einer geringeren Komplexität

und geben, zum Beispiel in der Startphase eines Projekts, einen schnellen Überblick

über die Ablauforganisation. Detaillierte Geschäftsprozessmodelle hingegen ermögli-

chen, Kernpunkte der Ablauforganisation näher zu betrachten.

Die Aggregations- und Dekompositionsmöglichkeiten der Methode OMEGA sollen

ausschnittweise anhand einer Aggregation von Geschäftsprozessen auf Abteilungsebene

zu einem Hauptgeschäftsprozess auf Hauptabteilungsebene verdeutlicht werden (Bild



7). Folgende Regeln sind bei der Dekomposition eines übergeordneten Modells zu be-

achten. Die Organisationseinheiten der Geschäftsprozesse und des zugehörigen Haupt-

geschäftsprozesses werden in einer einheitlichen Farbe modelliert. Die Input- und Out-

put-Objekte des Grobmodells müssen Input- und Output-Objekte der detaillierten Pro-

zesskette sein. Sind also „Fertigungsunterlagen“ das Ergebnis des Geschäftsprozesses

„Entwicklung durchführen“, müssen die „Fertigungsunterlagen“ auch aus den detaillier-

ten Prozessen als Output-Objekt modelliert werden. Im Rückschluss sind durch die Ag-

gregation die Kommunikationsbeziehungen zwischen den einzelnen Teilen der Prozess-

kette eines Hauptgeschäftsprozesses nicht mehr ersichtlich. So wird z.B. die Weiterlei-

tung des Papierobjektes „Projektplan“ von „Entwicklung planen“ zu „Entwicklung

durchführen“ in dem Hauptgeschäftsprozess nicht modelliert. Bearbeitungsobjekte, die

die detaillierte Prozesskette verlassen, müssen auch im aggregierten Modell dargestellt

werden.

Als Input- bzw. Output-Objekte für einen Hauptgeschäftsprozess werden die Bearbei-

tungsobjekte des ersten bzw. letzten Geschäftsprozesses aggregiert. Alle weiteren In-

formationsobjekte, die innerhalb des Modells auf unteren Ebenen vorhanden sind, treten

auf Hauptabteilungsebenen nicht mehr auf. Für die Aggregation der Bearbeitungsobjek-

te gelten die Regeln, dass gleichartige Objekte aggregiert werden können (bspw. mehre-

re Papierobjekte zu einem Papierobjekt) und ungleichartige nicht aggregiert werden

können (bspw. Informationsobjekt zu einem Materialobjekt). Darüber hinaus ist die

Aggregation von ungleichartigen Objekten zu einer Informationsgruppe möglich. Auch

gleichartige Ressourcen werden sinnvoll zusammengefasst. Die IT-Applikationen

„CAD“ und „NC“ lassen sich beispielsweise zur IT Applikation „CAE“ aggregieren.

Papierspeicher lassen sich ebenfalls

hierarchisch gliedern. So kann ein Archiv in detaillierte Ebenen, in Regale, Fächer etc.

spezifiziert werden. Die Aggregation unterschiedlicher Arten von technischen Ressour-

cen (bspw. Papierspeicher und IT-Applikation) ist unzulässig.



Bild 5: Nutzung von Abgrenzungen zur Verbesserung der Übersichtlichkeit und Lesbar-

keit von Prozessen (oben: Modellierung ohne Abgrenzungen, unten: Modellierung des-

selben Prozesses mit Abgrenzungen)



Bild 6: Anordnung und Verknüpfung der Konstrukte der Methode OMEGA be-

zogen auf einen einzelnen Prozess

Bild 7: Aggregation mehrerer Geschäftsprozesse zu einem Hauptgeschäftsprozess



A2.3 Aufnahme

A2.3.1 Moderationstechniken

Geschäftsprozessmodelle werden in der Regel im Rahmen von Workshops mit Vertre-

tern aus den involvierten Bereichen erarbeitet. In Einzelfällen können auch Interviews

genutzt werden. Diese dienen vor allem der Verifizierung von Unstimmigkeiten und

zum nachfolgenden Review. Zur Unterstützung der Moderation der Workshops und

Interviews zur Prozessaufnahme sind auf der Basis unserer langjährigen Erfahrung drei

Varianten von Hilfsmitteln entstanden:

OMEGAworkshopSet

OMEGAkombiCard

OMEGAkomPakt

Diese genügen bestimmten Workshop- bzw. Interviewkonstellationen und bieten spezi-

fische Vor- und Nachteile. Dabei spielen auch persönliche Vorlieben der Moderatoren

eine Rolle. Im Folgenden werden daher die drei Varianten vorgestellt und Hinweise für

die Verwendung bei der Moderation gegeben. Letztendlich führt jede Variante zu einem

in Microsoft Visio visualisierten Geschäftsprozessmodell.

OMEGAworkshopSet

Das OMEGAworkshopSet besteht im Prinzip aus größeren Papierkarten der vorgestell-

ten Konstrukte von OMEGA. Mit diesen Karten wird der Prozessablauf auf Wandtape-

ten („Brown-Paper“) Schritt für Schritt modelliert. Diese Variante ist besonders für

Workshops mit großer Teilnehmerzahl geeignet. Die Modellierung sollte wenn möglich

von den Teilnehmern des Workshops selbst vorgenommen werden. Ein Moderator ko-

ordiniert und moderiert die Teilnehmer und kontrolliert gleichzeitig die inhaltliche Kon-

sistenz der modellierten Schritte. Ein Assistent digitalisiert die Ergebnisse parallel in

Microsoft Visio und klärt dabei Verständnisfragen direkt vor Ort. So werden Unge-

reimtheiten bei der späteren Visualisierung vermieden. Optional arbeitet ein zusätzlicher

externer Fachexperte inhaltlich mit und entlastet so den Moderator bei der Kontrolle der

inhaltlichen Konsistenz. Bild 4-13 zeigt eine mit OMEGAworkshopSet modellierte

„Prozess-Tapete“ sowie einen Ausschnitt des daraus resultierenden Prozessmodells

nach der Visualisierung in Microsoft Visio.



Bild 4-13: Mit OMEGAworkshopSet modellierte „Prozess-Tapete“ und Ausschnitt

des daraus resultierenden Prozessmodells nach der Visualisierung in Microsoft Visio

In der Regel hat die Verwendung des OMEGAworkshopSet eine stimulierende Wirkung

auf die Teilnehmer des Workshops, vor allem wenn es sich um eine große Runde han-

delt. In Diskussionen wird ein einheitliches Verständnis der bestehenden Prozesse er-

zeugt und dokumentiert. Dabei wird auch die Identifikation bestehender Schwachstellen

gefördert; diese lassen sich dann häufig einzelnen Prozessschritten zuordnen. Die starke

Interaktion der Teilnehmer sowie die daraus resultierende Integration der Teilnehmer in

den Modellierungsprozess erhöhen die Akzeptanz der Ergebnisse und die Chancen der

späteren Umsetzung von Prozessverbesserungen erheblich.

Diese Variante der Modellierung mit OMEGA erfordert jedoch ein eingespieltes Bera-

terteam mit besonderer Kompetenz im Bereich der Moderation. Besonders für den Mo-

derator selbst ist ein ständiger Spagat zwischen den Rollen „Moderator“ und „Fachex-

perte“ notwendig, der sich auch durch die Unterstützung mit einem zusätzlichen Fach-

experten nur teilweise aufheben lässt.

Bei der Verwendung des OMEGAworkshopSet sind wichtige Informationen immer prä-

sent, der Gesamtprozess lässt sich schnell und schwerpunktmäßig erfassen. Dafür sind

selbstverständlich große freie Wandflächen im Raum notwendig. Ein Sprung zu frühe-

ren Prozessschritten ist jederzeit leicht möglich und sehr gut von allen Workshop-

Teilnehmern nachvollziehbar. Darüber hinaus lässt sich die erarbeitete „Prozess-

Tapete“ komplett archivieren und für die Klärung späterer Rückfragen wieder hervorho-

len.

Grob- konzept Produkt-

ion


ion


ion


ion


ion

Ver- und Entsorgung 4

Anhand der groben Flächenstrategie- planung werden die GMK der Umstell- ungen geschätzt. Ggf. werden auch pauschal prozentuale Zuschläge veranschlagt.

Fabrikplanung Center 3

GMK der Umstellungen schätzen

Micro- station FAPLIS

.xls .ppt

.mdb Abteilungs

koor- dination

Flächen strategi eplan

Materialflußplanung Center 3

Mittelbedarfe schätzen

Mittelbedarfe für Fördertechnik ab- schätzen.

Mittel- bedarfs- schätz-

ung

.xls .ppt

.mdb

ergänzt!!


ung

.xls .ppt

.mdb

ergänzt!!

vollst. Mittel-

bedarfs- schätz.

ASI und GMK für Kühlschmierstoffe, Späne, Druckluft, Strom etc. schätzen in Zusammenarbeit mit Gebäude und technischer Infrastruktur sowie Prozess- und Umwelttechnik .

Mittelbedarfe schätzen

Abteilungs koor-

dination


ung

.xls .ppt

.mdb


ung

.xls .ppt

.mdb

ergänzt!!

PLZ-Controlling 5

Stückkostenrechnung durchführen

vollst. Mittel-

bedarfs- schätz. Stück- kosten- rech.

Leitung Prod.-

Planung

. xls

.xls .ppt

.mdb .xls .ppt

.mdb

vollst. Mittel-

bedarfs- schätz. Stück- kosten- rech.

. xls

.xls .ppt

.mdb

Strat.-PL Prod.-PL

Center- leitung


ion


ung

.xls .ppt

.mdb


ion


ung

.xls .ppt

.mdb Grob-

konzept Produkt-

ion


ion

strat. Prod.

Planung

Lasten- heft

Aggre- gate

Achtung: GSP nimmt an dieser Stelle eine Sonderrolle ein, da Sie intern Angebote abgibt.

Absprache Anweisung

Gehe zu Grobplanung

1



OMEGAkombiCard

Die OMEGAkombiCard ist eine Prozesskarte in der Größe herkömmlicher Moderati-

onskarten (Bild 4-14). Diese enthalten in sechs Feldern alle wesentlichen Konstrukte der

Methode OMEGA. Für jeden Prozessschritt wird genau eine OMEGAkombiCard ver-

wendet. Alle zusätzlich benötigten Informationen zu dem jeweiligen Prozessschritt wer-

den direkt auf der Karte festgehalten. Die Karten werden vom Moderator oder von den

interviewten Personen selbst ausgefüllt und entsprechend ihrer Sequenz und Parallelität

an einer Pinnwand fixiert.

Bild 4-14: Die OMEGAkombiCard

Die OMEGAkombiCard eignet sich besonders gut für Interviews oder Workshops mit

nur sehr wenigen Personen. Geführte Einzelinterviews, die mit der OMEGAkombiCard

dokumentiert werden, können anschließend leicht zu einem Gesamtprozess konsolidiert

werden. Dabei besteht allerdings die Gefahr, die Teilnehmer zu verlieren, da sie nicht

aktiv in diesen Konsolidierungsprozess eingebunden sind.

Für die Durchführung der Prozessaufnahme sind lediglich die Karten selbst sowie eine

Pinnwand nötig. Ein Moderator kann diese Variante gut alleine anwenden, ein Assistent

wird nicht zwingend benötigt. Die OMEGAkombiCard ist somit eine schnelle und

schlanke Variante der Modellierung mit OMEGA. Sie lässt sich insbesondere für erste

Modellierungsschritte im Sinne eines Top-Down-Vorgehens einsetzen, da nur eine be-

grenzte Detaillierung möglich ist. Der Spielraum für zusätzliche Informationen auf der

Karte ist begrenzt und einzelne Informationen können nur geändert werden indem die

gesamte Karte neu ausgefüllt wird.

Inhaltlich sind durch die Verwendung einer Pinnwand auch bei dieser Variante wichtige

Informationen immer präsent und der Gesamtprozess lässt sich schnell und schwer-

punktmäßig erfassen. Auch Rücksprünge lassen sich wieder leicht nachvollziehen.



Schwachstellen können einfach identifiziert und gezielt einzelnen Prozessschritten zu-

geordnet werden.

OMEGAkomPakt

Die Variante OMEGAkomPakt besteht aus Prozesskärtchen in der Größe von Visiten-

karten (Bild 4-15). Die Karten werden vom Moderator oder den Interviewten selbst

ausgefüllt und entsprechend ihrer Sequenz und Parallelität auf einem Tisch positioniert.

Als Unterlage dient „Brownpaper“ oder Flipchart-Papier. Die Karten werden zunächst

frei gelegt und erst dann auf der Unterlage fixiert, wenn alles modelliert ist – es ist also

jederzeit möglich, ähnlich einem Puzzle, die Karten zu verschieben.

Bild 4-15: Einzelkarten der Variante OMEGAkomPakt

OMEGAkomPakt ist am besten für Workshops mit wenigen Personen geeignet. Maxi-

mal fünf Personen können sinnvoll gleichzeitig an einem Prozessmodell arbeiten. Grö-

ßere Workshops können selbstredend in mehrere parallel arbeitende Teams aufgeteilt

werden. Dabei arbeiten die Teilnehmer eigenständig und werden so gut in die Modellie-

rung integriert. Der Workshopleiter füllt ausschließlich die Rolle des Moderators aus.

Das Review der Prozessmodelle erfolgt parallel zur Modellierung selbst durch Diskus-

sionen der Teilnehmer und entsprechende Neupositionierung oder Ergänzung der Kar-

ten vor der Fixierung. Gleichzeitig fördert diese Variante das Prozessverständnis der

einzelnen Teilnehmer und die Teamentwicklung.

Auch bei Verwendung von OMEGAkomPakt sind wichtige Informationen immer prä-

sent sowie schnell und schwerpunktmäßig zu erfassen. Auch Rückschritte sind jederzeit

einfach möglich und sogar explizit gewünscht. Die Zuordnung von Schwachstellen zu

den Prozessschritten ist auch hier eindeutig möglich. Allerdings ist die Variante durch

die geringe Kartengröße nicht für die Verwendung auf Pinnwänden geeignet. Bei An-

forderungen an einen unterschiedlichen Detaillierungsgrad kann OMEGAkomPakt je-

doch gut mit der Variante OMEGAkombiCard kombiniert angewendet werden.



A2.3.2 Fazit

Es ist je nach Anwendungsfall zu entscheiden, welches Hilfsmittel am besten geeignet

ist. Grundsätzlich ist das OMEGAworkshopSet für Workshops mit größeren Gruppen zu

empfehlen. Die besondere Stärke liegt in der stringenten Darstellung des Prozesses, die

schon stark der finalen Darstellung in Microsoft Visio ähnelt. Dabei ist zu bedenken,

dass genügend Fläche für die „Prozess-Tapeten“ vorhanden sein muss und ein Work-

shop-Team von mindestens zwei, besser drei Personen notwendig ist. OMEGAkombi-

Card ist besonders gut für Einzelinterviews und kleine moderierte Workshops geeignet.

Die Karten können problemlos in der Jackett-Tasche mitgeführt und bei Bedarf zu Hilfe

genommen werden. Die Informationsmenge, die auf den Karten untergebracht werden

kann, ist jedoch begrenzt. Die Variante OMEGAkomPakt schließlich spielt ihre Stärken

vor allem dann aus, wenn es darum geht, sich in kleinen Teams über Prozessabläufe klar

zu werden, dabei die Prozessmodelle zu erstellen und diese gleichzeitig auch zu reflek-

tieren. Der Team-bildende Charakter ist bei dieser Variante besonders stark ausgeprägt.

Die einfache Kombination von OMEGAkomPakt mit OMEGAkombiCard eröffnet wei-

tere Möglichkeiten, vor allem wenn es um die Modellierung unterschiedlicher Detaillie-

rungsgrade geht.

Documents

Leitfaden als PDF