ebook ebooks e-book e-books downloaden bei MyEbooks.ch downloaden

Enterprise Architecture, BPM und SOA für Business-Analysten Leitfaden für die Praxis

:	Dirk Stähler, Ingo Meier, Rolf Scheuch, Christian Schmülling, Daniel Somssich
:	Enterprise Architecture, BPM und SOA für Business-Analysten Leitfaden für die Praxis
:	Carl Hanser Fachbuchverlag
:	9783446421431
:	1
:	CHF 29.50
:

:	Informatik
:	German

:	280
:	Wasserzeichen/DRM
:	PC/MAC/eReader/Tablet
:	PDF

PRAXISLEITFAD N FÜR BUSINESS-ANALYSTEN

- Erläutert, wie ein integriertes Gesamtmodell für Enterprise Architecture, Business Process Management und SOA erstellt wird
- Beschreibt den Weg vom Meta-Modellentwurf bis zur Werkzeugumsetzung mit ausführlichen Anleitungen und zahlreichen Praxistipps
- Anleitung zur praktischen Umsetzung am Beispiel der Oracle BPA Suite und der ARIS-Methode

In einer idealen Welt sind die Inhalte der Enterprise Architecture, der Geschäftsprozesse, des IT-Fachkonzepts und der Service-orientierten Architektur in einem einzigen Modell integriert. Doch die Realität sieht leider anders aus. Modelle entstehen in Unternehmen immer noch auf verschiedenen Ebenen, weisen Redundanzen und Widersprüche auf und können meist nur mühsam miteinander in Einklang gebracht werden.
In diesem Buch finden Sie ein integriertes Konzept zur betriebswirtschaftlichen und fachlichen IT-Modellbildung in Industrie- und Dienstleistungsunternehmen. Sie erfahren, wie Sie die Basis für ein zentrales Unternehmensmodell entwickeln und dafür einsetzen, um die Herausforderungen bei der Einführung und Verwaltung von IT-Lösungen zu bewältigen.
Die Autoren bieten Ihnen einen Leitfaden mit Arbeitshilfen und Praxistipps zum Aufbau eines eigenen integrierten Fach- und IT-Modells. Die Umsetzung zeigen sie konkret am Beispiel der Oracle BPA Suite. Neben der effizienten Gestaltung einzelner Modellierungsaspekte können Sie damit vor allem eine redundanzfreie Beschreibung verschiedener Modellierungsszenarien erreichen.

6 Modellgestützte fachliche Konzeption individueller IT-Systeme (S. 117-118)

6.1 Fragen, die dieses Kapitel beantwortet

- Warum sollte die IT in der Regel den Geschäftsprozessen folgen und nicht umgekehrt?
- Welche Vorteile bringt eine strukturierte Anforderungserhebung auf Basis eines durchgängigen Fachprozesses?
- Wie nehme ich am besten Fachprozesse im Rahmen einer Fachkonzepterstellung auf?
- Wie stelle ich Fachprozesse, Systemverhalten und statische Systemkomponenten im Modell dar?
- Welche Teile eines Fachkonzepts sollte ich im Modell darstellen und welche nicht?
- Wie funktioniert eine modellgestützte Fachkonzeption mit der Oracle BPA Suite?

6.2 Die Bedeutung fachlicher Anforderungen

Es existieren zahlreiche Studien zu den Gründen des Scheiterns von IT-Projekten. Dabei kann mit dem Begriff „Scheitern“ sowohl gemeint sein, dass ein IT-Projekt abgebrochen wird, als auch, dass der Projektzeitplan nicht eingehalten oder das finanzielle Budget überzogen worden ist. Auch die Realisierung eines Systems, das sich anschließend in der Praxis als untauglich herausstellt, muss als gescheitertes IT-Projekt angesehen werden. Die große Anzahl solcher Studien lässt bereits vermuten, dass das Scheitern von IT-Projekten ein häufiges Problem in Unternehmen darstellt. Dies wiederum ist für den Business-Analysten eine große Chance, Unternehmen einen Mehrwert anzubieten, indem ein Vorgehen entwickelt wird, das dem Scheitern von IT-Projekten entgegenwirkt.

Ein solches Vorgehen zur fachlichen Konzeption individueller IT-Systeme wird in diesem Kapitel vorgestellt. Nicht nur die Anzahl der Studien, auch ihr Inhalt bietet eine interessante Erkenntnis: Als wichtigster Grund für das Scheitern von IT-Projekten wird fast durchgehend die unklare Definition bzw. das unzureichende Verständnis der fachlichen Anforderungen identifiziert. Dies wiederum resultiert aus der in Kapitel 2 beschriebenen Problematik der unterschiedlichen Sichten, die die verschiedenen an einem IT-Projekt beteiligten Personenkreise haben. Das in diesem Kapitel vorgestellte Vorgehen sieht diese fachlichen Anforderungen als Basis für die Konzeption eines IT-Systems und hilft bei deren Identifikation, Beschreibung und Kommunikation zwischen allen an einem IT-Projekt Beteiligten.

Unternehmen haben über die letzten Jahre hinweg gelernt, dass ihre Geschäftsprozesse und deren Qualität entscheidenden Einfluss auf den Unternehmenserfolg haben. Die eigentlich logische Konsequenz aus dieser Erkenntnis, auch die IT nach den Geschäftsprozessen auszurichten, ist dagegen noch nicht sehr verbreitet. Besonders in der Vergangenheit wurde häufig der Fehler gemacht, Systeme einzuführen, die bestimmte Arbeitsabläufe (Fachprozesse) vorgeben. An dieser Stelle sei zunächst gesagt, dass ein solches Vorgehen nicht immer falsch sein muss. Je standardisierter die Prozesse sind, um die es geht, desto sinnvoller kann die Einführung einer Standardsoftware sein. Für Standardprozesse wie Rechnungsprüfung oder Finanzbuchhaltung wird es in den wenigsten Fällen sinnvoll sein, eine vollständige Individuallösung zu entwickeln. In solchen Fällen ist der Aufwand, der bei der Einführung einer Standardsoftware anfällt, sicherlich geringer als der Entwicklungsaufwand einer neuen Lösung.

Dennoch ist es wichtig zu wissen, dass eine Softwareeinführung, durch die neue Fachprozesse vorgegeben werden, bestimmte Konsequenzen für alle am Projekt Beteiligten und darüber hinaus mit sich bringt: Ein solches Vorgehen hat zur Folge, dass die Mitarbeiter in der Fachabteilung ihre ggf. seit Jahren praktizierten und bis ins kleinste Detail beherrschten Abläufe aufgrund einer neuen Standardsoftware grundlegend ändern müssen. Dies erhöht nicht gerade die Akzeptanz der neuen Lösung. Tatsächlich unterschätzen Unternehmen den enormen Aufwand einer solchen organisatorischen Veränderung. Organisatorische Veränderungen stellen in sich eigene Change-Management- Projekte dar, deren Umsetzung über die technischen Aspekte einer Systemeinführung weit hinausgeht.

	Inhalt	6
	Vorwort	10
	Die Autoren	12
	1 Einleitung	14
	1.1 Warum Modellierung?	14
	1.2 Was ist eigentlich ein Modell?	15
	1.3 Warum Standards und Regeln?	15
	1.4 Was Sie in diesem Buch finden	16
	1.5 Was Sie in diesem Buch nicht finden	17
	1.6 Welches Vorwissen sollten Sie besitzen?	17
	1.7 Das integrierte Beispiel	18
	2 Integrierte Modellierung für EA, BPM und fachliche SOA	20
	2.1 Fragen, die dieses Kapitel beantwortet	20
	2.2 Management, Fachbereiche und IT – jeder ist anders	20
	2.2.1 Inhalte für die Enterprise-Architecture-Modellierung	24
	2.2.2 Inhalte für die BPM-Modellierung	27
	2.2.3 Inhalte für die fachliche SOA-Modellierung	29
	2.3 Grundsätzliche Gliederung eines integrierten Modells	31
	2.3.1 Artefakttypen der Modellierung	32
	2.3.2 Schnittmengen und symmetrische Differenz der Modellierungsbereiche	34
	2.3.3 Semantische Zuordnung verschiedener Inhaltstypen	39
	2.3.4 Dynamische und statische Unterteilung	41
	2.3.5 Horizontale und vertikale Unterteilung	42
	2.4 Zusammenfassung	43
	3 Aufbau des Metamodells	46
	3.1 Fragen, die dieses Kapitel beantwortet	46
	3.2 Der werkzeugneutrale Modellentwurf	46
	3.2.1 Modellierungsgrundsätze und deren Bewertung	47
	3.2.2 Ermittlung und Bewertung essenzieller Fragestellungen	50
	3.2.3 Entwurf einer Domain-Level-Matrix	53
	3.2.4 Erstellung eines Metamodells	58
	3.2.5 Abschätzung des Modellumfangs und Erstellungsaufwands	66
	4 Die Umsetzung des Metamodells	70
	4.1 Fragen, die dieses Kapitel beantwortet	70
	4.2 Die Oracle BPA Suite als Modellierungswerkzeug	70
	4.3 Methodische Einschränkungen der Oracle BPA Suite	71
	4.4 Analyse der Oracle BPA Suite Methode	75
	4.5 Vorgehensweise zur Ermittlung Ihrer individuellen Oracle BPA Suite-Methode	79
	4.6 Analyse und Bewertung der semantischen Abdeckung	89
	5 Das Grundmodell	92
	5.1 Fragen, die dieses Kapitel beantwortet	92
	5.2 Aufbau des Grundmodells	92
	5.2.1 Ermittlung der Übersichtsartefakte der Prozessarchitektur	93
	5.2.2 Modellierung dynamischer Inhalte in der Oracle BPA Suite	96
	5.2.3 Die Instanzgranularitäten 1 bis 3 im Zusammenhang	108
	5.2.4 IT-neutrale Detaillierung der Prozesse und ihrer Aktivitäten	109
	5.2.5 Die statischen Objektbibliotheken des Grundmodells	112
	5.2.6 Aufbau der Grundstruktur eines integrierten Modells in der Oracle BPA Suite	124
	6 Modellgestützte fachliche Konzeption individueller IT-Systeme	130
	6.1 Fragen, die dieses Kapitel beantwortet	130
	6.2 Die Bedeutung fachlicher Anforderungen	130
	6.3 Die IT-Sicht und ihr Zusammenhang mit der Fachsicht	134
	6.3.1 Modellierung und Analyse der Ist-Prozesse	136
	6.3.2 Entwicklung und Modellierung der Soll-Prozesse	138
	6.3.3 Systemablauf – das fachliche Systemverhalten	140
	6.3.4 Beschreibung statischer Systemkomponenten	143
	6.4 Vom Modell zum Fachkonzept	150
	6.4.1 Anforderungen an ein Fachkonzept	150
	6.4.2 Nicht modellierte Bestandteile eines Fachkonzepts	151
	6.4.3 Gliederungsvorschlag für ein Fachkonzept	152
	6.5 Erstellung eines Fachkonzepts mit der Oracle BPA Suite	153
	6.5.1 Fachprozess	153
	6.5.2 Systemablauf	155
	6.5.3 Statische Systemkomponenten	159
	7 Identifizierung und Modellierung fachlicher Services für SOA	166
	7.1 Zentrale Fragen dieses Kapitels	166
	7.2 Services und SOA	166
	7.2.1 Was ist ein Service?	167
	7.2.2 Missverständnis Service	168
	7.2.3 Atomare und zusammengesetzte Services	169
	7.2.4 Was ist eine SOA?	169
	7.2.5 SOA und Services im Prozessmodell	170
	7.2.6 Services in der BPA Suite