Home

Enterprise Architecture, BPM und SOA für Business Analysten

1. Modul 2 F Systemstruktur Maskenfl sse Q Schnittstelle Stele 193 Beschreibung und Zuordnung Benutzerrollen Fachbegriffe Informationen Statische Komponenten Sonstige Fachkonzept Teile Fortlaufende berarbeitung Fachkonzept Abbildung 6 2 Vorgehen zur modellgest tzten Fachkonzeption 122 6 3 Die IT Sicht und ihr Zusammenhang mit der Fachsicht 6 3 1 Modellierung und Analyse der Ist Prozesse Das Erstellen eines Fachkonzepts beginnt also stets mit der Beschreibung der Fachprozes se Diese Beschreibung ist in eine Phase zur Beschreibung der Ist und eine Phase zur Be schreibung der Soll Prozesse unterteilt Grunds tzlich sind bei der Beschreibung von Fachprozessen folgende Fragestellungen zu beantworten E Welche Aktivit ten sind im Rahmen des Prozesses durchzuf hren E Wie ist der zeitlich logische Ablauf dieser Aktivit ten wann wird was gemacht Wer f hrt welche Aktivit ten aus E Welche fachlichen Informationen werden zur Du
2. r Wm gun Ace Diagrammtyp T Auntee en Matrixmodell Semen p Warmare z 1310 EPK Tabellendar Typ HW Komponente HW Komponententyp 1455 EPK Zeilendars Typ HWW Komponente i 1687 Funktionszuord Faan Typ HW Komponente 2777 Matrxmodell Typ Betriebssystem Diagrammtyp 2778 Matrixmodell Typ DEM IS ez an ih te 2878 Netzdiagramm 2894 Netztopolagie Tyi p Beiriebssystem Betriebssy rstemty p 2895 Netztopolagie Typ DBMS DBMS Typ 2896 Netztopolagie Typ HW Komponente H WW Komponententyp 3 BE Programmablaufdiagramm Typ Befriebssystem Betriebssystemtyp 3144 Programmablaufdiagramm Typ DBMS DBMS Typ 3 146 P rogrammablaufdiagramm Typ HW Komponente H WW Komponententyp 3354 Prozessterminplan ome HVW Komponententyp 3879 WKOD Typ HV 4020 VKD Materialfluss Typ HW cea Diag rammtyp 4214 Zugriffsciagramm Typ Betriebssystem 4215 ugriffsdiagramm Typ DBMS 4217 Zugriffscdiagramm Typ HW Komponente Programmablaufdiagramm ern Le u Be Diagrammtyp Zugriffsdiagramm Abbildung 4 11 Reduzierte Darstellung der Methodeninhalte in der Excel Analysedatei 70 4 5 Vorgehensweise zur Ermittlung Ihrer individuellen Oracle BPA Suite Methode Wenn mehr als ein Diagrammtyp alle erforderlichen Symboltypen enth lt w hlen Sie einen Diagrammtyp aus der semantisch die Intention der Modellierung am besten aus dr ckt Im vorliegenden Beispiel w hlen wir de
3. Auftrags abwicklung Fertigware E Rechnung Externe Prozesse ohne Kunden und ieferantenprozesse 5 Kennzahlen I Controlling Ma nahme Personal angebot amp Personal management B Bewertung Finanz und Rechnungswesen Abschluss Kunden Prozesse ergebnisse Marketing ergebnisse _ amp Personal ressourcen Sekund re Kernprozesse Externe Prozesse ohne Kundenprozesse Abbildung 9 16 Einbettung Kernprozess Controlling in die Prozess Landkarte Controlling Wertsch pfungskettendiagramm Controlling Process Monitoring Finanz controlling Process Benchmarking Process Mining 246 Abbildung 9 17 Modellierung der Prozesse zum Process Controlling 9 7 Modellierung des Prozess Controlling mit der Oracle BPA Suite tretend haben wir das Finanz Controlling aufgef hrt In Abbildung 9 17 wird das Control ling in einem Wertsch pfungskettendiagramm verfeinert Hierbei haben wir uns auf den Bereich des Process Controlling fokussiert und das Finanz Controlling als Platzhalter weiterer Controlling Prozesse Vertriebscontrolling Personalcontrolling etc modelliert Wir mochten uns nun auf das Process Controlling fur die Durchlaufzeit des WEK konzent rieren In Anlehnung an die drei Erfolgsfaktoren so
4. Aals03 BPMNO09 Carr03 Crum06 Davi0l Hans09 Kap197 Koch05 List00 Math07 Mele05 van der Aalst W M P et al Workflow Patterns http www workflowpatterns com documentation documents wfs pat 2002 pdf van der Aalst W A ter Hofstede M Weske Mining Most Specific Workflow Mod els from Event based In W van der Aalst A ter Hofstede and M Weske Business Process Management Proceedings of the International Conference BPM 2003 Eind hoven Lecture Notes in Computer Science Band 2678 Springer S 25 40 6 2003 Object Management Group BPMN Information Home http www bpmn org Carr N IT doesn t matter In Harvard Business Review Harvard Business School Publishing Boston 2003 Crump J Business Activity Monitoring BAM The new face of BPM June 2006 http www softwareag com Corporate Images WP The New Face of BPM _ tem 16 34226 pdf Davis R Business Process Modelling with ARIS 1 Auflage Springer Verlag Lon don 2001 Hanschke I Strategisches Management der IT Landschaft Ein praktischer Leitfaden fur das Enterprise Architecture Management 1 Auflage Hanser Miinchen 2009 Kaplan R S Norton D P Balanced Scorecard Strategien erfolgreich umsetzen Stuttgart 1997 Kochar Harpal Oracle Business Acitivity Monitoring White Paper http www oracle com technology products integration bam pdf bam_whitepaper pdf List B Schiefer J Tjoa A
5. Achtung Dies ist kein Modul Design bzw Modell zur Komponentenbildung im Rahmen des Software Designs f r die Realisierung Das Modell dient ausschlie lich der fachlichen Beschreibung und Zusammenfassung der fachlichen Anforderungen zu logischen IT Systemen Jedoch hat man im Sinne einer losen Kopplung die M glichkeit die tats chlichen implementierten IT Komponenten diesen logischen IT Systemen zuzuordnen 9 7 3 1 Modellierung der IT Systeme zum Process Monitoring Eine Ma nahme war Die Eskalation bei Problemen in einer Prozessinstanz soll schneller erkannt und behoben werden Diese Ma nahme l sst sich ber ein System f r das Process Monitoring umsetzen Das IT System besteht im Wesentlichen aus drei Komponenten wie auch in Abbildung 9 22 beschrieben l Der Import von Events und die Aufbereitung von Kennzahlen Obwohl es f r diese IT Komponente keinen human workflow gibt ist dies das Herz der IT L sung 2 Das System f r die Benachrichtigung Notifications ber unterschiedliche Kan le eines m glichen Problems bei einer Prozessinstanz 3 Eine Oberfl che zur Analyse einer Prozessinstanz und f r das Einleiten von Ma nah men Das bergreifende Blue Print haben wir bereits in Abschnitt 9 4 beschrieben und ein Muster definiert Somit k nnen wir nun gegen dieses Muster modellieren 9 7 Modellierung des Prozess Controlling mit der Oracle BPA Suite Process Monitoring Anwendungssy
6. ressourcen Sekund re Kemprozesse Abbildung 5 3 Exemplarische Darstellung einer Prozesslandkarte in der Oracle BPA Suite Wert sch pfungskettendiagramm Betrachtet man die in Abbildung 5 3 dargestellte Prozesslandkarte so erkennt man f r den Kernprozess Beschaffung die Geschaftsobjekte Lieferantenangebot und Materialbe stellung als Input und Lieferantenanfrage sowie Materialbestellung als Output Objek te Das Lieferantenangebot und die Materiallieferung ist ein Output eines externen Kundenprozesses Eine weitere Detaillierung des externen Prozesses ist f r die Erstellung des Gesamtmodells nicht erforderlich Die Schnittstellen zu externen Prozessen werden deshalb als Schnittstellen zu einem Blackbox Prozess betrachtet Das von einem externen Kundenprozess generierte Gesch ftsobjekt Lieferantenangebot und Materiallieferung wird an den Kernprozess Beschaffung bergeben Der Output des Beschaffungsprozes ses wird dann an nachfolgende interne oder externe Prozesse bergeben 88 5 2 Aufbau des Grundmodells Sekund re Kernprozesse stehen mit der Umwelt au erhalb der betrachteten Organisation deutlich seltener in Beziehung Zum Beispiel kann man f r den Marketingprozess nur sehr schwer eine feste Vorgabe machen wann und wie Marktanforderungen von externen Par teien zu erheben sind Ein weiteres Beispiel ist die Unternehmensentwicklung welche fast nicht mit einer proz
7. Die Definition ist in ihrer Ausrichtung offen Sie legt nicht fest f r welchen Zweck eine EA gestaltet werden sollte In der Praxis zeigt sich jedoch dass eine Enterprise Architectu re in der Regel zur Dokumentation und Planung der informationstechnologischen Unter st tzung einer Organisation eingesetzt wird Folgende Sichten sind wenn auch gelegentlich anders benannt in nahezu jedem EA Kon zept enthalten E Gesch fts Architektur E Daten Architektur E Anwendungs Architektur E Infrastruktur Architektur Danach wird eine EA zur transparenten fachlichen berblicksbeschreibung einer Organi sation und deren informationstechnologischen Unterst tzung eingesetzt Der Schwerpunkt liegt auf einer berblicksartigen Betrachtung die keine Details beleuchtet sondern das Wirken der Informationstechnologie im gesamten Unternehmen im Blick hat Die Geschafts Architektur Die Gesch fts Architektur beschreibt eine abstrakte Sicht auf die fachlichen betriebswirt schaftlichen Aktivit ten und Beziehungen innerhalb einer Organisation Es handelt sich dabei um eine berblicksartige Beschreibung der betriebswirtschaftlichen Sicht auf das Unternehmen Die Daten Architektur Die Daten Architektur beschreibt die im Rahmen der Gesch ftst tigkeit des Unternehmens anfallenden bzw beteiligten Gesch ftsobjekte Informationen und Daten In der gemein samen Betrachtung von Geschafts und Anwendungs Architektur ist sie die Schnittstelle zwische
8. berpr fen Sie ob die festgelegten Gesch ftsobjekte nur im zugeordneten Gesch fts prozess als zentrale Objekte Verwendung finden Sollte diese Eindeutigkeit nicht gege ben sein m ssen die Gesch ftsprozesse anders geschnitten werden 4 Wiederholen Sie die Schritte 1 bis 3 so oft bis alle Gesch ftsprozesse einer horizonta len Ebene ermittelt sind Die horizontale Grenze zwischen zwei Prozessen ist genau an der Stelle zu ziehen an der eine Ver nderung des oder der zentralen Prozessobjekte erfolgt 5 2 Aufbau des Grundmodells 5 2 2 Modellierung dynamischer Inhalte in der Oracle BPA Suite 5 2 2 1 Die 1 Instanzgranularit t Die Unternehmensinstanzebene Jedes hierarchisch aufgebaute Prozessmodell ben tigt einen Ausgangspunkt Dieser Aus gangspunkt ist die 1 Instanzgranular t t des dynamischen Teils Ihres Modells und wird meistens durch ein zentrales Diagramm als Wurzel der gesamten dynamischen Modellie rung ausgepr gt Bevor S e mit der Erstellung einer Prozesslandkarte f r Ihr Unternehmen beginnen sollten Sie die folgenden Fragen kl ren E Welche Kernprozesse besitzt Ihr Unternehmen E Welches sind die prim ren Gesch ftsobjekte die von diesen Kernprozessen bearbeitet werden Im Rahmen der Festlegung der Kernprozesse Ihres Unternehmens sollten Sie nicht mehr als 12 Prozesse definieren Diese Vorgabe gilt f r die Summe der prim ren und sekund ren Kernprozesse Es hat sich gezeigt dass auch in gr
9. 8 3 Modellierung SOA geeigneter Prozessmodelle genutzt Daher sollten sie so gestaltet sein dass sie die fachlichen Ablaufe korrekt und m glichst intuitiv verst ndlich abbilden 8 3 3 2 SOA Entwickler Die zweite Zielgruppe stellt der SOA Entwickler dar der den fachlichen Service technisch implementiert Die Anforderungen die dieser an das serviceorientierte Prozessmodell stellt sind st rker IT technisch orientiert Nicht alle Informationen die f r die Umset zung eines Service n der IT erforderlich sind lassen sich angemessen und sinnvoll n einem fachlichen IT Modell abbilden Wichtige jedoch technisch spezialisierte Aspekte wie beispielsweise Anforderungen an transaktionales Verhalten der Prozesse und Services oder die Performanz zur Laufzeit sind dem Zust ndigkeitsbereich des SOA Entwicklers bzw IT Architekten zuzuordnen Sie k nnen und sollen im fachlich orientierten Modell vom SOA Business Analysten nicht ber cksichtigt werden 8 3 4 Informationsbedarf der Zielgruppen ermitteln Die konkreten Informationen ber die Prozesse und Dienste im Unternehmen die im Rahmen der Modellierung erfasst werden m ssen verschiedene Anforderungen erf llen sie sollen korrekt vollst ndig aktuell und redundanzfrei sein Die Modellbildung und ins besondere das Erstellen eines Metamodells welches die zu ermittelnden Informationen und deren Darstellung in Modellen festlegt helfen diese Anforderungen zu erf llen Um den Au
10. 95 1 2 5 SOA und Services im Prozessmodell en 157 52 6 Devices mader BPA SUC rece ea serielle 162 RZ Der Nuizeneiner SON nes anal 167 Aufbauseines Serviceporllolosnr zeetenteseeetlaeeiseili 170 7 3 1 Aufgaben des Sermieeporllelios a uuueu e nR ea 171 7 3 2 Nutzen und Herausforderungen eines Serviceportfolios eeessssseeeeseeeeeeenn 173 7 3 3 Die BPA Suite als Serviceportfolio 22222020sssssssnsnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 174 DEVIC CISTI LIAL OT a ee le Eee 176 7 4 1 Verschiedene Wege der Serviceidentifikation 020222200sssssssnnsnnnennnnnnn 176 7 4 2 Serviceidentifikation ber den prozessorientierten Ansatz 177 Serviceklassifikation und Servicespezifikation uuueeseneeeneeneennnnennnnnnnennnnnnnnnnnnnnnn nn 181 7 5 1 Struktur durch die Dom nendekomposition eeeessssssssssssssnnnnnnnnnnnnnnnnnnnnnnnnnnnn 182 1 3 2 Arten der Serviccklassifikalion zeusesessensestnuenn seinen 183 7 5 3 Vervollst ndigen der Servicebeschreibung durch die Servicespezifikation 186 Das Wichl13ste 1 Kurze u RER Ener 189 Der prozessgetriebene SOA AnsatZ uussusnuennnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnen 191 Fragen die dieses Kap tel beantwortete each a 191 BPM SOA Teamwork in der Prozessautomatisierung eseeeeeeeeeeeessessseesseeneenneeeeeeeeeeeennn 191 8 2 1 Fachliche SOA Ans tze Autobahn oder Sackgasse neeeeeeeeeennenn
11. Bei der Modellierung nutzen wir nun die bereits bestehenden statischen Elemente So flie Ben die Kennzahlen pro Prozessinstanz ein und werden zu einer Kennzahl PDauer pro Prozessinstanz verdichtet Die Pr fung ob ein Schwellenwert berschritten wurde ber nimmt das IT System Monitoring System das im Folgenden noch betrachtet wird Wir haben mit XOR modelliert da im Falle der berschreitung eines Schwellenwertes der eigentliche Prozess zum Eskalationsmanagement angesto en wird Achtung Dieser Prozess l uft ohne Human Interaction ab Die Kennzahlen werden vom System erstellt und auch verteilt 247 9 Entwurf und Aufbau prozessgetriebener Kennzahlensysteme Process Monitoring Wertschopfungskettendiagramm Prozess Monitoring Problem Monitoring identifikation WEK Problemidentifikation Monitoring WEK EPK Daten zur ozessinstanz Problem erhalten identifikation Prozessinstanz Prgblemmeldukg System Revere Monitoring durch nachricht en System Beteiligten gesendet chwellenwen Prozess Derschrite Prozess OK verantwortlicher Prozessinstanz Eskalation Grafikdarstellung der Sean Systemnachricht PDauer pro onitoring daten WEK 2 analysieren rozessinstanz WEK amp Prozessinstanz System A System System nachricht Eskalation gesendet beheben Monitoring WEK Eskalation Abbild
12. EPK Top Management Aggregierte Prozessdaten WEK ef Darstellung der KPI amp PDauer gesamt fe Abbildung 9 20 Modellierung des Pro zesses zum Process Benchmarking 250 9 7 Modellierung des Prozess Controlling mit der Oracle BPA Suite Benchmark WEK Bei der Modellierung nutzen wir wiederum die bereits bestehenden statischen Elemente So flie en in diesem Falle zur Bildung der Kennzahl s mtliche Prozessdaten ein um die durchschnittliche PDauer ber alle abgelaufenen Prozessinstanzen eines Zeitintervalls bilden zu k nnen Abbildung 9 20 stellt den notwendigen Prozess f r das Process Benchmarking dar Das lop Management betrachtet diese Kennzahl und erh lt den momentanen Status der Prozesseffizienz des WEK In diesem Fall ist das Prozess Cockpit eine M glichkeit der Darstellung dieser Kennzahl Die Publizierung der Kennzahl sollte in einem Bereich des Unternehmensportals erfolgen F r die eigentliche Darstellung sollte man eine Ampel Funktion oder hnlich bersichtliche grafische Darstellungen w hlen Der Wert k nnte auch ber eine Benachrichtigung SMS E Mail etc bermittelt werden Tabelle 9 12 Benutzte Methodenobjekte der Oracle BPA Suite Modellname Process Benchmarking Benchmarking WEK Diagrammtyp Wertsch pfungskettendiagramm WKD EPK Symbole Ereignis Funktion Typ Anwendungssystem Fachbegriff Kennzahlinstanz Personentyp Prozessschnittstelle 9
13. Entwickler relevanten Informationen in Form eines Prozess Modells unbestritten einen zielfuhrenden und in der Praxis bew hrten Ansatz dar Die wichtigsten Informationen werden im fachlichen IT Modell f r Oracle BPEL wie folgt abgebildet Technische Prozessschritte Aktivit ten Auch in diesem Modell sind die technischen Prozessschritte Funktionen in der Oracle BPA Suite Mit Blick auf die Zielumgebung Oracle BPEL PM bietet die Oracle BPA Suite al lerdings die M glichkeit zwischen verschiedenen Auspr gungen einer Funktion zu unter scheiden Wie n Abbildung 8 15 zu erkennen werden durch unterschiedliche Symbole beispielsweise manuelle T tigkeiten Manuelle Aufgabe und vollst ndig automatisierte Prozessschritte Automatisierte Aufgabe voneinander abgegrenzt Warenhaus Dispositions beauftragter Liefermenge amp ist unterschritten Freier Lagerbestand Manuelle Aufgabe Nachlieferung initiieren Q Freier Erforderliche Menge Lagerbestand ist nicht verfuegbar ist verfuegbar ist nicht erforderlich Nachlieferung a ES Nachlieferung ist erforderlich ist initiiert A Nachlieferung ist Nachlieferung nicht erforderlich Lagerhaltungs system Artikelnummer Lagermenge si dgerme ge ermitteln Lag perviceTectfinisch AmiltleLagerbestand Verfuegbar Bestell system Artikelnu mer Reservierte Meng
14. m Rahmen dieses Buches die folgende BPM Definition Business Process Management umfasst alle Aktivit ten zur effektiven Organisations gestaltung und weiterentwicklung und zur Bearbeitung und Messung fachlicher Prozesse sowie die dazu eingesetzte informationstechnologische Unterst tzung Grunds tzlich unterscheiden wir die folgenden Sichten E Fachliches BPM E Technisches BPM Fachliches BPM Fachliches BPM befasst sich mit der betriebswirtschaftlichen Gestaltung von Gesch fts prozessen Ber cksichtigt werden fachliche Aspekte der Prozessstrategie der Prozessge staltung der Prozessimplementierung und der Prozess berwachung Die Prozessstrategie dient zur Bestimmung der strategischen Ausrichtung und Zielsetzung des Prozessmanagements Ziel ist es sicherzustellen dass im Rahmen der Prozessgestal tung ein an den fachlichen Bed rfnissen des Unternehmens ausgerichteter Prozessentwurf entsteht Die Prozessgestaltung dient der fachlich inhaltlichen Ausgestaltung einzelner Prozesse eines Unternehmens In diesem Bereich des fachlichen BPM werden mit Hilfe einer Ge sch ftsprozessanalyse die Abl ufe ermittelt bzw an fachlichen Bed rfnissen ausgerichtet entworfen und optimiert Die Prozessimplementierung befasst sich anschlie end mit der organisatorischen Imple mentierung der Prozesse sowie Governance und Qualit tssicherungsma nahmen zur Si cherstellung einer gleichbleibenden Prozessdurchf hrung 15 2 Integrierte Modell
15. tet frei gesprochen in den Naturwissenschaften Abbild der Natur Unter einem Modell verstehen wir also ein Abbild der realen Welt Dabei erzeugt man im Allgemeinen keine genaue Kopie des darzustellenden Gegenstandes sonst hatte man ihn ja nachgebaut sondern eine reduzierte Beschreibung Rob Davis definiert in Davi01 die Eigenschaften eines Modells Ein Modell ist demnach eine Repr sentation eines realen Objektes erstellt in einem bestimmten Ma stab erstellt bis zu einem bestimmten Detaillierungsniveau erstellt um einen bestimmten Gesichtspunkt darzustellen die Beschreibung eines Objektes der realen Welt zu einem bestimmten Zeitpunkt und erstellt um einem bestimmten Zweck zu erf llen Zur Diskussion der Architektur des K lner Doms k nnten wir ein Modell im Ma stab 1 400 erstellen Es w re dann rund 40 cm hoch und deutlich einfacher zu transportieren als das Original Zur Darstellung der grunds tzlichen Charakteristika gotischer Architektur w re es ausreichend Genauso verh lt es sich mit dem integrierten Enterprise Architecture Business Process Management und fachlichen serviceorientierten Architekturmodell das wir n diesem Buch behandeln Um ber existierende oder zuk nftige IT L sungen mit anderen Men schen sprechen zu k nnen ben tigen alle Beteiligten ein m glichst gleiches Vorwissen Auch in diesem Fall gilt dass man den realen Diskussionsgegenstand nicht zu jeder Zeit mit sich herumtrag
16. Abbildung 5 14 Aufbau der Gesch ftsobjektbibliothek im IT neutralen Modellteil 105 5 Das Grundmodell Haupt und Unterprozessen mit der auf den betrachteten Ebenen maximalen Anzahl an Geschaftsobjekten und anschlie ender Addition Auch wenn die Anzahl der Geschaftsob jekte pro Kern Haupt und Unterprozess gering erscheint die maximal m gliche Anzahl von mehr als 1400 Gesch ftsobjekten reicht in der Regel aus um eine IT neutrale fachli che Modellierung vollstandig aufzubauen Bei der Erstellung des Grundmodells legen Sie die Geschaftsobjekte bitte ohne Beziehung zueinander in der Oracle BPA Suite in einem Diagramm ab Eigentlich w re es ausreichend die Gesch ftsobjekte ausschlie lich im Reposi tory zu definieren ohne sie graphisch auf Diagrammen auszupr gen Bei der Durchf hrung einer Datenbankreorganisation innerhalb der Oracle BPA Suite w rden diese Objekte aber verloren gehen weshalb grunds tzlich eine graphi sche Auspr gung jedes Objektes sinnvoll ist Legen Sie aus diesem Grund im Rahmen der Erstellung des Grundmodells ein Container diagramm f r die Gesch ftsobjekte an Die Bezeichnung Containerdiagramm verwenden wir f r Diagramme die lediglich zur Sicherung der Objekte gegen Datenverlust bei einer Reorganisation ben tigt werden Es empfiehlt sich die Objekte zur besseren bersicht innerhalb dieses Diagramms alphabetisch zu sortieren Diese Funktion kann schnell mit Hilfe eines Reports automatisie
17. Aktuell erh lt die Modellierung einer Enterprise Architecture in Verbindung mit Business Process Management und SOA neue Bedeutung H ufig wird eine Enterprise Architecture dabei als Voraussetzung f r ein erfolgreiches Business Process Management und die SOA Einf hrung gesehen Leider hat sich bis heute kein allgemeing ltiges Verst ndnis entwi ckelt das verbindlich festlegt was eine Enterprise Architecture berhaupt ist Es existieren Definitionen unterschiedlicher Gremien wie zum Beispiel dem American National Stan dards Institute ANSI dem Institute of Electrical and Electronics Engineers IEEE dem Zachman Institute for Framwork Architecture oder der Open Group Die Liste lasst sich noch fortf hren was nochmals unterstreicht dass die Fachwelt zum Thema Enterprise Architecture keine einheitliche Meinung hat Entwurfsmuster f r Enterprise Architekturen werden h ufig als Frameworks bezeichnet Dabei handelt es sich um Rahmenwerke die eine systematische Sammlung von Strukturen und manchmal auch Methoden und Werkzeugen bereitstellen Die meisten EA Frameworks kann man nach einer prim r statischen oder dynamischen Ausrichtung unterscheiden Statische Frameworks definieren Artefakte und Strukturen zum Aufbau eines EA Modells Ein Beispiel f r ein statische EA Framework ist das bekannte Zachman Framework Es wurde 1987 entwickelt und war das erste EA Framework das in einem gr eren Ma stab publiziert und verbreitet wurde S e k
18. Dabei geht es besonders um den Einsatz von Werkzeugen zur Prozessautomatisierung und Prozessmessung 2 2 2 2 BPM im Kontext dieses Buches Technisches BPM baut immer auf einem fachlichen BPM auf und h ngt deshalb vom Vorhandensein eines fachlichen BPM ab Demgegen ber ist ein fachliches BPM auch ohne technisches BPM denk und umsetzbar Aus diesem Grund betrachten wir im Rahmen des Buches beide Spielarten des BPM tren nen sie aber klar in eine fachliche und technische Sicht Neben dieser Unterteilung be schr nken wir uns auf die Modellierungsaspekte des BPM die m Kontext mit einer EA und fachlichen SOA Modellierung relevant sind 2 2 3 Inhalte f r die fachliche SOA Modellierung Wenn S e versuchen eine fachliche SOA zu definieren so erhalten S e g nzlich unter schiedliche Ergebnisse je nachdem wen Sie befragen Die Einordnung reicht dabei von einem allgemeinen Management Konzept bis zur Reduzierung auf ein Konzept zur Integ ration von Anwendungssystemen Mittlerweile n mmt das Thema serviceorientierte Architekturen aber zunehmend Platz n vielen Unternehmen ein und gewinnt damit an Sichtbarkeit und Bedeutung Unternehmen 2 2 Management Fachbereiche und IT jeder ist anders implementieren die Konzepte serviceorientierter Architekturen sowohl fachlich als auch technisch und ziehen konkrete Vorteile und Nutzen aus dem Ansatz Wir mochten uns an dieser Stelle nicht an der Diskussion beteiligen was SOA denn nun wirkli
19. Daten Infrastruktur 12 Architektur Architektur Architektur Architektur Architektur Prozesse Unternehmen 12 Aktivit ten Standort Abteilung Anwendung Ge Daten Person 6 Datenbank Abbildung 3 6 Domain Level Matrix mit zugeordneten Objekt und Beziehungstypen Nachdem Sie die Domain Level Matrix um die Beziehungen zwischen den erforderlichen Objekttypen erg nzt haben ist es ratsam diese nochmals gesondert aufzulisten Tabelle 3 4 zeigt die in unserem Beispiel dargestellten Beziehungstypen 2 Diese Beschr nkung ist besonders f r die Modellierung innerhalb der Oracle BPA Suite wichtig weil das Werkzeug ber ein geschlossenes Metamodell verf gt Je weniger Sichten bergreifende Beziehun gen Sie definieren desto einfacher wird sp ter die Umsetzung im Werkzeug 3 2 Der werkzeugneutrale Modellentwurf Tabelle 3 4 Beziehungstypen der Domain Level Matrix raner irren estas Anwendung bearbeitet Daten bearbeitet 6 resents Anm tween Prozess ist zusammengesetzt aus Aktivit ten ist zusammengesetzt aus a Ten iii ae o TastetumgbehndetsichanStanden _____ beindetschan Es handelt sich bei den Beziehungstypen aber noch nicht um Beziehungen des Metamo dells Wir befinden uns immer noch in einer fachlich gepr gten Vorstufe die hilft das ge plante integrierte Modell m glichst einfach zu entwickeln Die Fokussierung auf relevante Grunds tze die Formulierung essenziel
20. Einlagerung des bestellten Gutes Juristisch verbindlicher Abschluss oder Beendi gung der Verkaufs verhandlungen Abschluss der Service leistung durch L sung des Kundenproblems Bereitstellung aller f r die Produktion erforderlichen Produktspezifikationen Versand des produzierten Gutes an den Kunden Platzierung der zum Vermarktungsauftrag geh renden Marketing leistungen au erhalb des Unternehmens Versand der Rechnung an den Kunden Einstellung eines neuen Mitarbeiters Vorlage einer Strategie planung zum betroffenen Planungszyklus Controlling F r das Controlling ist die Angabe einer sinnvollen Instanz auf der Ebene der Kernprozesse nahezu unm glich 87 5 Das Grundmodell Externe Prozesse Interne Prozesse i Externe Prozesse Externe Gesch ftsobjekte Interne Gesch ftsobjekte Prim re Komprozesse Externe Geschaftsobjekte Semice Senice anfrage ce l sung Kunden Lantra Kunden Kunden auftrag c fr ana i twicklungs Produkt epezfkationcs Vertrieb Lisferanter anfrage El Materiak 7 bestellung Bes mING Material J Rechnung o J A J Material nternehmens strategie Ei Gesch fts Unternehmens Finanz und chancen db entwicklung Rechnungswesen ergebnisse Markt Marketing forderu Marketing F ergebnisse g Externe Prozesse ohne Kunden ured eferantenprozesse Personal
21. Einsatz im Rahmen der Unterst tzung der Gesch ftsprozesse zu erreichen sind Geht man davon aus dass diese Feststellung zutrifft stellt sich die Frage warum bis heute bei einem 6 2 Die Bedeutung fachlicher Anforderungen Gro teil der IT Projekte die abgebrochen oder zumindest nur ber Zeit und Finanzbudget fertiggestellt werden die unklare Definition bzw das fehlende Verstandnis der Anforde rungen den Grund fur die unbefriedigende Qualitat darstellen Konkret bedeutet dies dass die fachlichen Anforderungen der sp teren Anwender des Systems nicht gr ndlich und umfassend genug erfasst und dokumentiert bzw nicht von den Entwicklern verstanden werden und die Entwicklung des Systems daraufhin in der Regel an den Anforderungen aus der Fachabteilung vorbeigeht Das Resultat sind fehlende Systemakzeptanz und eine ganze Reihe von Change Requests deren Umsetzung um ein Vielfaches teurer ist als die von bereits in der Konzeptionsphase identifizierten Anforderungen Die vollst ndige Erfassung sowie das umfassende Verst ndnis der Anforderun gen des Fachbereichs stellen die wichtigste Grundlage f r ein erfolgreiches IT Projekt dar Der Grund f r dieses Problem ist wieder einmal der sog Engineering Gap also die be reits beschriebene Sprachbarriere zwischen Fachabteilungen und IT Welt W hrend in der fachlichen Welt Fachprozesse und organisatorische Strukturen Gegenstand einer Unter nehmensbeschreibung sind z hlen in der IT Welt
22. Hardwareinfrastruktur z B Hardwareserver Storage L sungen Netzwerke etc bis zu den Betriebsmitteln Maschinen und Anlagen die man 1m Rahmen der wertsch pfenden T tigkeit des Unternehmens ben tigt Selbstverst ndlich k nnen Sie bas erend auf Ihrem individuellen Metamodell Entwurf viele dieser Strukturen erfassen und modellieren Wir betrachten bei unserem Vorschlag zur Strukturierung der Infrastrukturbibliothek exemplarisch nur die IT Infrastrukturinhalte Server Hardware und virtualisierte Server und E Datenbanken E Das geschlossene Metamodell der Oracle BPA Suite erm glicht nur eine eingeschr nk te Modellierung der IT Infrastruktur die f r die berblicksartige Darstellung innerhalb des integrierten EA BPM SOA Modells jedoch ausreichend ist Die Erstellung einer Infrastrukturbibliothek kann sehr umfangreich werden Wir beschr nken uns in unserem Ansatz auf die f r das integrierte EA BPM SOA Modell erforderliche minimale Struktur Selbstverst ndlich k nnen Sie die von uns vorgeschlagene Auswahl bei Bedarf erg nzen um einen breiteren Bereich der Infrastrukturbeschreibung abzudecken Server Hardware und virtualisierte Server Die Modellierung der Serverhardware und gegebenenfalls virtueller Server wird ben tigt um im integrierten Modell darzustellen welche Hardwareplattformen zum Betrieb der IT Anwendungen erforderlich ist Legen Sie die Objekte zur Beschreibung der Serverinfra struktur analog zur Mode
23. Ihrer individuellen Oracle BPA Suite Methode Die Excel Analysedateien zeigen den Zustand der Gesamtmethode innerhalb der Oracle BPA Suite Datenbank die individuell gepflegte Methodentabelle den davon genutzten Ausschnitt Selbstverst ndlich k nnen Sie nach erfolgter Filteranpassung Ihre individuelle Methode ebenfalls mit Hilfe des Filteranalysereports ausgeben lassen F r das Beispiel aus Kapitel 3 2 ergibt sich das in den Tabellen 4 1 und 4 2 dargestellte angepasste Oracle BPA Suite Metamodell Aus Gr nden der bersichtlichkeit haben wir auf die Darstellung der Attributtypen verzichtet Nutzen S e Tabelle 4 1 und 4 2 als Startpunkt f r die Ausgestaltung Ihrer individuellen EA BPM SOA Methode Tabelle 4 1 Darstellung der individuellen Oracle BPA Suite Methode direkte Beziehungstypen Entit t Beziehung Diagramm Quell_ Ziel Beziehung Semantische Entitat Gruppe typ symbol symbol Abdeckung Softwareressource Zugriffs Typ Typ HW Komponente kann laufen auf 50 nutzt Hardware diagramm Betriebssystem ee Zugriffs Typ Typ HW Komponente kann laufen auf diagramm DBMS Typ Anwendungssystem Zugriffs Typ HW Komponente kann laufen auf 100 lauft auf Hardware diagramm Anwendungs ressource system Anwendungssystem EPK Typ Funktion unterst tzt 100 unterst tzt Prozess Anwendungs system Prozess ist Vorg nger EPK Funktion Funktion ist Vorg nger 100 von Prozess von 74 8 Innerhalb der Oracle BPA Suite wird die ind
24. Instanzgranularitat Unterprozessinstanz O1 Instanzgranularit t Detailprozessinstanz optional 6 Instanzgranularit t IT Interaktionsinstanz Fachliche Detailmodelle N Instanzgranularitat l Prozessinstanz Fachliche IT Modelle Instanzgranularitat implementierte i T IT Prozessinstanz Ausf hrbare IT Modelle Abbildung 8 3 Horizontale und vertikale Prozessdekomposition N vertikale Dekomposition E Fachliches Detailmodell Beschreibt die betriebswirtschaftlichen Abl ufe im Unternehmen auf einer operati ven Ebene aus fachlicher Sicht Ist den Ebenen 4 und 5 Fachliche Detailmodelle der vertikalen Prozessdekompo sition s Abbildung 8 3 zuzuordnen Enth lt keine IT spezifischen Detailinformationen 2 Hypertext System in dem Benutzer Eintr ge lesen und online ndern k nnen 196 8 3 Modellierung SOA geeigneter Prozessmodelle Enth lt fachliche Services wenn Prozessschritte durch Dienste unterst tzt werden Wird idealerweise als EPK oder BPMN Modell modelliert zu den Notationen vgl Abschnitt 8 3 5 E Fachliches IT Modell Beschreibt aus fachlicher Sicht die im ausf hrbaren IT Modell zu automatisieren den Prozessschritte Ist den Ebenen 6 und 7 optional Fachliche IT Modelle der vertikalen Prozess dekomposition s Abbildung 8 3 zuzuordnen Idealerweise als EPK oder BPMN Modell abgebildet Enth lt Informationen ber die in den einzelnen Prozessschritten v
25. Wir verlassen an dieser Stelle die ber blicksartige Modellierung und wenden uns der Detailmodellierung zu Zur Orientierung k nnen Sie eine Trennung des berblicksartigen und detaillier ten dynamischen fachlichen Modellteils anhand der bearbeiteten Gesch ftsobjek te und der beteiligten Organisationseinheiten vornehmen Erfolgt zwischen den Kern Haupt und Unterprozessen der fachlichen bersichtsmodelle in der Regel eine nderung der beteiligten Organisationseinheiten und der bearbeiteten zent ralen Gesch ftsobjekte so bearbeiten die Prozessaktivit ten der Unterprozess und Detailprozessinstanz in der Regel dasselbe zentrale Gesch ftsobjekt und werden durch Mitglieder derselben Organisationseinheit ausgef hrt Wurde die Modellierung auf den Ebenen 1 bis 3 zur grunds tzlichen Strukturierung der dynamischen Inhalte Ihres Modells verwendet so dient die dynamische Modellierung auf den Ebenen 4 und 5 der fachlichen Detaillierung Abbildung 5 7 zeigt die Erweiterung des Modellteils um die Unterprozessinstanz und Detail prozessinstanz Ebene horizontale Dekomposition Hauptprozesse 5 6 Prozessaktivitaten 6 12 Kernprozesse 3 5 Unterprozesse 20 40 Prozessaktivitaten 1 Instanzgranularitat Unternehmensinstanz 2 Instanzgranularit t Kernprozessinstanz 3 Instanzgranularit t Fachliche Hauptprozessinstanz bersichtsmodelle 4 Instanzgranularit t Unterprozessinstanz Abbildung 5 7 Horizontale u
26. ist Input f r ist Input f r ist Input f r a ist Input f r ist Output von a ist Output von ist Output von ist Output von io ist Output von of ist Output von 5 Machlieferung initiieren Machlieferung initieren a ist Output von Select order EM a umfasst encompasses l ra Sun Abbildung 7 9 Beziehungen zu einem Gesch ftsobjekt Die in Beziehung stehenden Objekte k nnen auf Servicekandidaten hin betrachtet werden Im Beispiel sind die verbundenen Objekte berwiegend dem Thema Bestellung zuzuord nen Daraus k nnen wir einen Servicekandidaten Bestellung ableiten Serviceklassifikation und Servicespezifikation Die bisher identifizierten Services befinden sich noch unstrukturiert und ohne Dokumenta tion in unserem Serviceportfolio Durch die Serviceklassifikation und Servicespezifikation sollen die Services strukturiert und dokumentiert werden Erst n einer strukturierten Form kann das Serviceportfolio richtig genutzt werden Bei einer kleinen Serviceanzahl ist eine saubere Strukturierung noch nicht so wichtig Anders sieht es bei einem gewachsenen Ser viceportfolio aus Ohne weitere Strukturierung und Spezifikation k nnen Services ledig lich ber ihren Namen aufgefunden werden Ein Servicename ist jedoch nicht eindeutig genug Konsumenten k nnen Services ohne Detailinformationen nicht finden und wird der Service doch gefunden sind die Informationen zu d rftig u
27. ssen Sie in einem nachfolgenden Schritt daraufhin untersuchen ob sich unter ihnen Aktivit ten der gleichen Granularitat wie die bereits identifizierten Hauptprozesse befinden Ist dies der Fall so hat man weitere Hauptprozesse gefunden Dieser Prozess wird so lange wiederholt bis keine weiteren Hauptprozesse mehr identifiziert werden k nnen Betrachten wir zur Verdeutlichung die dem Kernprozess Beschaffung untergeordneten Prozesse Einer dieser untergeordneten Prozesse ist der Wareneingang Eine Instanz dieses Prozesses w re zum Beispiel die Bearbeitung einer Sendung eines Spediteurs Nach der Vorgabe dass alle Aktivit ten des Prozesses eine ann hernd gleiche Instanzgranularitat aufweisen sollen m ssen Sie in diesem Schritt untersuchen ob die im Rahmen der hori zontalen Strukturierung gefundenen Prozesse der gleichen Modellierungsebene dieser Vorgabe entsprechen Wenn wir uns die identifizierten Hauptprozesse der horizontalen Strukturierung des Be schaffungsprozesses anschauen so kommen wir zu dem in Tabelle 5 3 dargestellten Er gebnis Wenn man s ch die unterschiedlichen Granularit ten der einzelnen Aktivit ten des Be schaffungsprozesses ans eht erkennt man folgende Besonderheiten E Die Lieferantenauswahl passt nicht in die gew hlte Instanzgranularit t der anderen Aktivit ten Eine Lieferantenauswahl erfolgt in der Regel nur einmal wohingegen Lie 5 2 Aufbau des Grundmodells Tabelle 5 3 Ermittelte Hauptprozesse zum
28. system unterst tzt Service Daten Gesch fts objekte Datenbank Software ressourcen Server Hardware ressourcen ist verant wortlich f r E 49 3 Aufbau des Metamodells 50 Wir empfehlen Ihnen zus tzlich eine tabellarische Beschreibung der Beziehungen zwi schen den Entit ten des Metamodells anzulegen siehe Tabelle 3 6 Wir haben die Erfah rung gemacht dass die Zusammenh nge des Metamodells sich auf diesem Weg besser kommunizieren lassen 3 2 4 2 Festlegung der Attribute zu den Metamodell Entit ten Nachdem Sie die Beziehungen zwischen den Entit ten das EA Metamodell festgelegt ha ben fehlt noch die M glichkeit weiterf hrende Informationen zu den Instanzen einer Enti t t hinzuzuf gen Das vorliegende Metamodell stellt bisher nur Objekte und deren Bezie hung untereinander dar Wir haben noch nicht festgelegt welche weitergehenden Informa tionen hinterlegt werden k nnen Versehen Sie deshalb jede Entit t mit Attributen zur detaillierteren Beschreibung Ber ck sichtigen Sie dabei die essenziellen Fragestellungen und leiten Sie daraus die f r Ihr Me tamodell erforderlichen Detailinhalte zu jeder Entit t ab H ufig geben Ihnen diese bereits Hinweise auf erforderliche Attribute Die Attribute Name und Beschreibung werden f r jede Entitat erfasst Die weiteren Attri bute wechseln stark von Entitat zu Entit t Grunds tzlich lassen sich folgende Arten von Attributen unterscheiden m Textattr
29. t die Services besitzen sollen Von den extremen Varianten bei denen ein Service alles kann oder bei denen es Millionen feingranularer Services gibt st abzuraten Als grobe Empfehlung hat sich bew hrt dass ein Service nicht mehr als zehn F higkeiten bereitstellen soll Weil die Erfahrungswerte in der Servicegranularitat noch jung sind kann sich dies in Zukunft n dern Die Servicegranularit t hat Auswirkungen auf unser Serviceportfolio Je feingranularer ein Service modelliert wird umso h her ist die Wahrscheinlichkeit dass diese Leistung andere Konsumenten wieder verwenden Auch die Flexibilit t wird verbessert da Services schnell in einer anderen Reihenfolge verwendet werden k nnen Die Nachteile liegen in der h he ren Komplexit t und dem Pflegeaufwand Fachlich und technisch s nd Personen damit be sch ftigt den Service im Serviceportfolio zu pflegen siehe auch Abbildung 7 6 Werden viele feingranulare Services technisch verwendet senkt dies ebenfalls die Performance Mehr Serviceaufrufe bedeuten mehr Kommunikation und mehr Kommunikation bedeutet mehr technischen Aufwand Serviceidentifikation mit der BPA Suite Die beschriebenen Identifikationsmethoden lassen sich alle in der BPA Suite realisieren An dieser Stelle zeigen wir zwei exemplarisch Die Identifikation ber Namen erfolgt durch eine Suche im Repository Rechtsklick auf dem Modell gt Suchen In der Maske k nnen anschlie end die Suchwerte eingegeben w
30. ten eines einzelnen Wareneingangs Die gew hlte Benennung der Aktivit t deutet aber auf einen generelleren Prozess hin In diesem Fall sollte ber eine Umbenennung der Aktivit t nachgedacht werden Anschlie end bestimmen Sie zu jedem definierten Hauptprozess die zugeh rigen Ge sch ftsobjekte Dabei gelten die gleichen Kriterien wie bei Gesch ftsobjekten der Prozess landkarte Jedem Hauptprozess muss mindestens ein zentrales Gesch ftsobjekt zugeordnet werden Jeder Hauptprozess erzeugt wenigstens ein Gesch ftsobjekt als Ergebnis Alle Gesch ftsobjekte sollten dabei eine ann hernd gleiche Granularit t besitzen Abschlie end wird berpr ft ob alle wertsch pfenden Hauptprozesse wirklich zum ber geordneten Kernprozess geh ren und alle beteiligten Gesch ftsobjekte identifiziert worden sind Abbildung 5 4 zeigt exemplarisch die Kernprozessinstanzebene f r den Beschaffungspro zess Neben den Hauptprozessen und den bearbeiteten Gesch ftsobjekten sind weiterhin die Gesch ftsobjekte Rechnungsdaten und Material erkennbar die mit den anderen Kernprozessen Finanz und Rechnungswesen und Auftragsabwicklung korrespondieren Verwenden Sie bei der Modellierung der 2 Instanzgranularit t die Vorgaben aus Tabelle 5 4 91 5 Das Grundmodell Externe Prozesse 2 Instanzgranularit t Kernprozessebene Beschaffung nterne Prozesse Ebene 1 Lieferanten aufmahmeanfrags Lieferanten Lieferanten stammdaten c anfrage Finanz
31. tigen Sie im fachlichen IT Modell die Abgrenzung zwischen ausf hrungsverantwort lichen Rollen und IT Systemen darstellen m chten Sie die in der BPA Suite erfassten technischen Services mit dem Prozess im Modell verbinden wollen 8 4 2 2 Das fachliche IT Modell f r Oracle BPEL Der zweite Modellierungsansatz abstrahiert nicht mehr vollst ndig vom in der IT Imple mentierung genutzten Produkt Vielmehr nutzt er die von Oracle in der BPA Suite bereit gestellten Funktionalit ten zur Spezifikation eines Modells f r die Oracle Laufzeitumge bung Oracle BPEL Process Manager BPEL PM Der BPEL PM ist die Laufzeitkompo nente fur ausf hrbare BPEL Prozesse von Oracle und Bestandteil der Oracle SOA Suite Die nach diesem Ansatz in der BPA Suite modellierten Prozesse k nnen ber einen Gene rierungs und Importmechanismus in die Entwicklungsumgebung Oracle JDeveloper ber tragen und dort weiterbearbeitet werden Nach der Implementierung durch den SOA Entwickler kann der BPEL Prozess per Deployment in den BPEL PM bertragen und an schlie end dort ausgef hrt werden Dieser Modellierungsansatz erfasst verglichen mit der zuvor erl uterten Vorgehensweise deutlich mehr technische Details Das WIE der Umsetzung wird hierbei ausf hrlicher be trachtet und 1m Modell abgebildet Daher ben tigt der SOA Business Analyst einerseits f r die Erstellung dieser Form des fachlichen IT Modells deutlich mehr technisches Hin tergrundwissen Dies
32. und a Lieferanten Rechnungswesen Lieferanten 4Mlaterialbestellung auswahl angebot ey i Materiak y Material Lieferanten bestellung_ amp bestellung _ Rechnungsdaten prozesse l i Prochukt renbegleit Rechnungs entwicklung apiere g j pr fung i Materiak r A i Auftrags m 0 Abbildung 5 4 Exemplarische Darstellung einer Kernprozessinstanzebene Wertsch pfungsketten diagramm Tabelle 5 4 Inhalte und Abgrenzung der Kernprozessebene 2 Instanzgranularit t Benennung der Name des bergeordneten Kernprozesses Die Benennung sollte als substantiviertes Verb 2 Instanzgranularit t erfolgen Beschreibung der Hauptprozesse eines Kernprozesses Genutzte Objekttypen Prozess oder Aktivit tsobjekt Das Prozess oder Aktivit tsobjekt beschreibt dynamischen Vorg nge Gesch ftsobjekt Das Gesch ftsobjekt beschreibt die im Rahmen der Prozessdurchf hrung Dynamik bearbeiteten statischen Objekt Beziehungsobjekt zwischen Prozess Das Beziehungsobjekt beschreibt die Beziehung oder Aktivit tsobjekt und Gesch fts zwischen Prozess oder Aktivit tsobjekten und objekten Gesch ftsobjekten Die Beziehungen k nnen entweder Input oder Output Beziehungen sein Abgrenzung Granularit t Alle Hauptprozesse auf den erstellten Diagrammen m ssen zur Bearbeitung der der auf den Diagrammen Gesch ftsobjekte des bergeordneten Kernprozesses erforderlich sein ausgepr gten Objekte Unterein
33. wenn Services identifiziert und nutz bar gemacht werden sollen Der Aufwand diesen Service zu erstellen liegt beim Anbieter Die Frage Wer bezahlt die Implementierung wird meist mit Der Anbieter beantwor tet Aus Sicht eines potenziellen Anbieters besteht unter Umst nden kein Interesse seine Leistungen als Services anzubieten Er m sste Zeit und Geld investieren um Konsumenten eine Leistung anbieten zu k nnen An dieser Stelle ist Managementunterst tzung n tig um den unternehmensweiten Nutzen ber Verantwortungsgrenzen hinweg zu realisieren 7 2 Services und SOA Ein Service kapselt fachliche Funktionalitat Services besitzen ein fachliches Aufgabengebiet Ein Service kapselt die in diesem Auf gabengebiet erbrachten Leistungen und bietet sie Konsumenten an Ein Telefonbuch Service k nnte zum Beispiel die Leistung anbieten zu einem Namen die entsprechende Telefonnummer zu suchen Der gleiche Service kann auch die Leistung anbieten zu einer bestimmten Telefonnummer den Nummerninhaber zu suchen Beide Leistungen fallen fach lich n das gleiche Aufgabengebiet und sollten ber einen Service angeboten werden Services verf gen ber eine wohldefinierte Schnittstelle Wenn ein Service genutzt werden soll braucht er eine definierte Schnittstelle wie diese Leistung in Anspruch genommen werden kann In der Regel beinhaltet eine Schnittstellen beschreibung die Leistungen Nachrichtenbeschreibungen eingehende und au
34. 1 nun auch tageslicht tauglich Daher haben die Autoren diesen Bestseller in Sachen UML aktualisiert Dieses topaktuelle und n tzliche Nachschlagewerk enth lt zahlreiche Tipps und Tricks zum Einsatz der UML in der Praxis Die Autoren beschreiben alle Diagramme der UML und zeigen ihren Einsatz anhand eines durchg ngigen Praxisbeispiels Folgende Fragen werden u a beantwortet Welche Diagramme gibt es in der UML 2 Wof r werden diese Diagramme in Projekten verwendet Wie kann ich die UML an meine Projektbed rfnisse anpassen Was ben tige ich wirklich von der UML Mehr Informationen zu diesem Buch und zu unserem Programm unter www hanser de computer Lolo CEMEL Ea DONO www ciando corg n Klick entfernt Download beziehen telweise erh ltlich Volltextsuche Know How ist nur eine n Sie sofort per der kapi komfortable _ eBooks k nne _ eBooks sind ganz O eBooks bieten eine Gerhard Engelken 3D Konstruktion Sam gt un mit SolidWorks i mg F R SPIELE PROGRAMMIERER Mit einem Geleitwort von Volker Wertich Phenomic Game Development Brinkmann z 53 Osswald ga Schmachtenberg 3 KOCHBUCH I TYPO3 Saechtling TypoScript Kunststoff SPRING wa Taschenbuch HIBERNATE Bt LOSUNGEN FUR DIE TYPO3 PROGRAMMIERUNG m 30 Ausgabe EINE m PRAXISBEZOGENE PROG MIT TYPOSCRIPT UND PHP A EINFUHRUNG Der einzigartige Bestseller berarbeitet amp aktuali
35. 103 5 Das Grundmodell Abbildung 5 13 zeigt die Modellierung des Organigramms innerhalb der Oracle BPA Suite Wir empfehlen f r jede Hierarchieebene ein separates Diagramm zu erstellen Die horizontale Detaillierung der Stellen und ggf Personen erfolgt auf der letzten betrachteten Hierarchieebene Au erdem k nnen Sie erkennen dass geographische Informationen eben falls in den Organ grammen der Oracle BPA Suite enthalten sein k nnen befindet sich an Frankfurt wird gebildet durch Organigramm Muster AG 1 Instanzgranularit t Organigramm Beschaffung oa une 2 wird gebildet durch A ateriallogistik areneingang a aterial und Bestellverwaltung ist fachlich vorgesetzt Leiter besetzt 7 Wareneingang Peter Muller ird ildet h tzt LE Lagerist sia Michael Meier r Dieter Marx Organigramm Wareneingang ar Run Er ird gebildet durc j A 3 Instanzgranularit t er J rg Vogel Abbildung 5 13 Organisationsmodellierung in der Oracle BPA Suite Organigramm 5 2 5 2 Erstellung der Gesch ftsobjektbibliothek Unter einem Gesch ftsobjekt verstehen wir jede Form von Eingangs und Ausgangsobjek ten eines Prozessschritts Gesch ftsobjekte werden von wertsch pfenden Aktivit ten ver braucht bearbeitet oder erzeugt Ziel der Gesch ftsobjektbibliothek ist es alle Eingangs und Ausgangsobjekte im Bereich der IT n
36. 4 Zusammenfassung Die Struktur eines integrierten Enterprise Architecture BPM und fachlichen SOA Modells k nnen S e nach den folgenden Kriterien gliedern E ihrer semantischen Einordnung E ihrem dynamischen oder statischen Charakter E dem Artefakttyp dem sie zugeordnet sind E ihrer horizontalen und vertikalen Einordnung Jeder Inhalt des integrierten Modells kann nach diesen vier Kriterien eindeutig zugeordnet werden Bei der Erstellung der Struktur Ihres Modells m ssen Sie darauf achten dass Inhalte eindeutig und berschneidungsfrei 1m Modell abgelegt werden k nnen Um die 30 2 4 Zusammenfassung Uberschneidungsfreiheit sicherzustellen bauen Sie die Modellstruktur und die Regeln zur Ablage der Inhalte in folgenden Arbeitsschritten auf 1 Bilden Sie die semantische Struktur Ihres Modells Unterteilen Sie das integrierte Mo dell dabei zunachst nach einem Modellbereich f r fachlichen Inhalte einem Modellbereich f r fachliche IT Inhalte und einem Modellbereich f r IT technische Inhalte 2 Unterteilen Sie anschlie end jeden semantischen Modellbereich f r dynamische Modellinhalte und statische Modellinhalte 3 Legen S e danach fest welche Artefakttypen n den dynamischen und statischen Berei chen abgelegt werden sollen Beschreiben Sie genau die jeweils erforderlichen Arte fakttypen Die genaue Ermittlung der Artefakttypen besprechen wir m folgenden Kap tel 4 Legen Sie f
37. Anforderungen von Process Monitoring und Process Mining Tabelle 9 1 Process Monitoring und Mining im Vergleich Tabelle ist angelehnt an die Kriterien und Darstellung von zZM h00 Pr sentation aktive Benachrichtigung Ex post Analysen Behebung aktueller operativer Analyse von Optimierungspotenzial Schwachstellen Einzelsatz Prozessinstanz Aktivit t Mengen Prozesskette gruppen Prozessstatus laufende Prozesse abgelaufene Prozesse Datenmodell objektorientiert MOLAP Daten Scope aktuelle Prozessinstanz Prozess Business Objekte Zusammenfassend l sst sich das Process Monitoring als Echtzeit berwachung der aktuell ablaufenden Prozessinstanzen sehen Wesentliche Aufgabe ist es zeitnah auftretende bzw potenzielle Probleme und Engp sse proaktive Alerts zu erkennen Hier k nnen sodann Gegenma nahmen eingeleitet werden sofern das BAM System keine automatisierten Re geln etwa automatisierte Reallokation der Ressourcen vornimmt Im Gegensatz dazu werden im Process Mining vordefinierte Performance Indikatoren ge bildet und nach Zeitbezug und Dimensionen flexibel ausgewertet Ziel ist die Erkennung von Trends Wirkungsanalysen oder strukturellen Schwachstellen Diese Ergebnisse flie Ben im Rahmen der strategischen Aspekte der Prozessoptimierung im Rahmen des Regel kreises des Gesch ftsprozessmanagements GPM e n 9 4 9 4 Ziel des Process Controlling Ziel des Process Controlling Das strategische Ziel des Proc
38. BPA Suite Methode Informationen ausgeben w hlen Sie die Informationen die ausgegeben werden sollen Klicken Sie bitte auf OR um die Auswahl zu beenden Optionen F Erlaubte Modelitypen ausgeben Erlaubte Modellattrikute ausgeben Erlaubte Symboltypen ausgeben Erlaubte Objektattribute ausgeben Erlaubte Hinterlegungen ausgeben Erlaubte Beziehungstypen ausgeben Erlaubte Beziehungs attrikudtypen ausgeben Abbrechen Hilfe Abbildung 4 5 Auswahl der auszuwertenden Methodeninhalte Nachdem die Report Erstellung abgeschlossen ist ffnen Sie die erstellte Excel Datei Abbildung 4 6 Der Report hat jeweils eigene Arbeitsbl tter erzeugt f r E Modelltypen beschreiben die vorhandenen Diagrammtypen in der Oracle BPA Suite sowie die Sichten des zugrunde liegenden ARIS Konzepts Modellattributtypen beschreiben die Standardattribute zu jedem Diagrammtyp Symboltypen zeigen welche Symboltypen auf welchen Diagrammtypen verwendet werden k nnen sowie den zugeh rigen Objekttyp vgl Abbildung 4 1 Dieses Excel Arbeitsblatt st der Ausgangspunkt f r die Anpassung der Oracle BPA Suite Methode an Ihre individuellen Anforderungen Es beschreibt mit den Symboltypen einen we sentlichen Teil der semantischen Ausdruckm glichkeit des Werkzeugs Objektattributtypen beschreiben die Standardattribute zu jedem Objekttyp E Hinterlegungen geben an welche Diagrammtypen welchen Objekttypen hinterlegt werden k nnen E Bezieh
39. C Nachliet erung initieren F higkeit H Technische Operationen Ziele KPI Instan zen Implemertierungen F higkeiten LJ Nachheterung intieren F higkeit Gesch fsobjekte i Realisierungen 4 MNachlieferungsservice Anwendungssystentyp Abbildung 7 7 bersicht f r Gesch ftsservices und Softwareservices Einen Service findet man ber eine Textsuche in der Navigation Auch ber das Kontext men k nnen Services gesucht werden Auf einer Funktion kann v a Rechtsklick das Kon textmen ge ffnet werden und unter dem Punkt SOA gt Servicetypen suchen kann man eine Serviceauswahl einsehen Dabe handelt es sich um eine eingeschr nkte Ansicht auf die Service bersicht Zur Einschr nkung werden Modellinhalte an der Funktion genutzt Z B werden bei modellierten F higkeiten und Fachbegriffen nur jene Services angezeigt die die gleichen F higkeiten oder Fachbegriffe nutzen Wird ein Service n der Service bersicht neu angelegt wird man durch einen Wizzard ge f hrt und hat zum Beispiel die M glichkeit bestehende F higkeiten und Gesch ftsobjekte schrittweise hinzuzuf gen 175 7 Identifizierung und Modellierung fachlicher Services fur SOA 7 4 Serviceidentifikation 176 Bei der Serviceidentifikation m ssen die vorhandenen Informationen aus dem Prozessmo dell neu betrachtet Services abgeleitet und richtig gekapselt werden Um von einem Pro zessmodell zu Services zu kommen gibt es kein automat
40. Das Pull Verfahren ist der klassische Ansatz der Datenbewirtschaftung in einem Data Warehouse Hier werden die ben tigten Daten zeitversetzt aus den Quellsystemen ex portiert und in einem mengenorientierten Verfahren in das Data Warehouse eingespielt Dabei nutzt man in der Regel die Bulk Inserts der Datenbanksysteme Die Sonden bermitteln die Daten an einen Enterprise Service Bus ESB Hier erfolgen die notwendigen Transformationen und die Aufbereitung auf ein Schnittstellenformat das zum Aufbau eines Process Warehouse ben tigt wird Im Wesentlichen muss ein eindeuti ger Schl ssel gebildet werden der die Prozessinstanz beschreibt und den Prozessschritt festh lt Das System ermittelt ferner den Vorg nger dieser Prozessinstanz und speichert diese Information ab damit eine Serialisierung der Prozessschritte m glich ist In unserem Beispiel brauchen wir einen Datensatz fur jeden zu messenden Event 1m Pro zess der Wareneingangskontrolle WEK insbesondere den eindeutigen Startpunkt und das eindeutige Ende Hieraus k nnen wir die Kennzahl PDauer WEK Prozessdurchlaufzeit bei der WEK berechnen Diese Sonden ben tigen wir sp ter bei der Modellierung in Abschnitt 9 7 3 4 um einen Zusammenhang der IT Komponente mit den fachlichen Kennzahlen herzustellen 233 9 Entwurf und Aufbau prozessgetriebener Kennzahlensysteme 234 9 5 2 IT Systeme fur die Analyse Auf Grundlage der Extraktion und der Transformationen werden nun pro Pro
41. Frage bietet und tra gen Sie diese Beziehung in der Domain Level Matrix ein Typisieren Sie die Beziehung weiterhin hinsichtlich der Information die Sie ausdr cken m chten Achten Sie dabei dar auf dass alle Beziehungstypen als Verben ausgedr ckt werden 43 3 Aufbau des Metamodells Ad Im vorliegenden Fall m chten Sie zum Beispiel die Unterst tzung der fachlichen Aktivitat durch eine Applikation anzeigen Ein m glicher Beziehungstyp w re demnach unter st tzt Versuchen S e m glichst wenige Beziehungen ber Architektursichten hinweg zu erzeu gen Dadurch verringern Sie bereits an dieser Stelle die Komplexit t Ihres zuk nftigen Modells Dar ber hinaus m ssen Sie darauf achten dass Objekttypen die ber unterschiedliche Sichten hinweg verbunden werden von ihrer Granularit t her zueinander passen Welche Objekttypen S e verkn pfen h ngt von Ihrem individuellen Informationsbed rfnis und dem Aufwand den Sie zur Datenerfassung betreiben k nnen ab Grunds tzlich gilt die Regel dass die Komplexit t und damit der Erstellungs und Pflegeaufwand des Mo dells ansteigt je detaillierter die verkn pften Objekte sind Wiederholen Sie diesen Vorgang so lange bis Sie zu jeder essenziellen Fragestellung in nerhalb der Domain Level Matrix eine entsprechende Beziehung abgebildet haben Abbildung 3 6 zeigt die f r unser Beispiel vollst ndig ausgef llte Domain Level Matrix Prozess Organisations Anwendungs
42. Gehen wir einmal davon aus dass alle Beteiligten guten Willens sind ihr Fachgebiet be herrschen und konstruktiv an einem positiven Beitrag mitarbeiten Dennoch scheint man eine unterschiedliche Sprache zu sprechen E Das Management interessiert sich in der Regel nur f r die grunds tzlichen Fragen eines IT Problems H ufig beschr nkt auf Zeit und Kosten E Die IT Abteilung betrachtet gerne technische Detailprobleme und deren m glichst elegante L sung E Das Gebiet des Business Analysten ist irgendwo dazwischen angesiedelt H ufig kommt ihm die Aufgabe zu zwischen der globalen Sicht des Managements und der technischen Sicht der IT zu vermitteln An dieser Stelle werden einige Leser protestieren Uns ist bewusst dass die Darstellung einseitig und pointiert ist Aber Sie werden uns zustimmen dass irgendwo zwischen Ma nagement und den Niederungen der Informatik erhebliche Kommunikationsl cken beste hen deren Schlie ung man vom Business Analyst erwartet Gelingt hm das nicht u ert sich das im besten Fall in gestiegenen Projektkosten und im schlimmsten Fall in komplett fehlgeschlagenen Projekten Was kann man an dieser Stelle also tun um Risiken zu vermindern Die Antwort ist auf den ersten Blick ganz einfach Jeder muss den anderen besser verstehen Das ist n der Praxis aber gar nicht so leicht umzusetzen Schauen wir uns zun chst einmal an in wel chen Situationen eine Kommunikation zwischen Management Fachbereichen
43. IT Modell Das pragmatische fachliche IT Modell dient in erster Linie dazu dem SOA Entwickler die ben tigten Informationen f r die Umsetzung des abgebildeten Prozesses in der IT zur Ver f gung zu stellen Die n Abschnitt 8 3 4 2 allgemein vorgestellten relevanten Informatio nen sollen dabei so weit wie m glich in Prozess und Servicemodellen abgebildet werden Technische Prozessschritte Aktivit ten und technische Services Die Prozessschritte werden in BPMN als Task Objekte modelliert BPA Objekt Funk tion Der SOA Entwickler ben tigt f r die Implementierung des ausf hrbaren Modells die Information welche elementaren Services in den einzelnen technischen Prozessschritten aufzurufen sind Das fachliche IT Modell gibt die Anordnung Orchestrierung dieser technischen Services vor 8 4 SOA Prozessmodellierung in der Oracle BPA Suite Warenhaus Dispositions a or achli Freier der Nachlieferung el 3 Lagerbestand ermitteln It ni Nachlieferung t nicht Jeri Ba ist erforderlich beauftragter N Pruefauftrag i KY entgegennehmen Liefermenge Nachlieferung ist initiiert ist unterschritten Freier Lagerbestand Sen ist verfuegbar e X Bagerbestand en Nachlieferung ist nicht erforderlich Nachlieferung ist nicht erforderlich O N N Lagerhaltungs Artikelnummer Lagermenge agermenge erm ein LagerServiceTechhisch ermittleLagerbestand
44. IT Service Management mit ITIL in die Praxis planen und realisieren Sie erfahren wie Sie die Best Practices von ITIL Ihren Zielen entsprechend mit ISO 20000 IT Kennzahlen Balanced Scorecard CobIT und PRINCE2 richtig kombinieren und einsetzen Mehr Informationen zu diesem Buch und zu unserem Programm unter www hanser de computer Alles im Griff ernst TIEMEYER Hrsg HANDBUCH KONZEPTE METHODEN L SUNGEN UND ARBEITS HILFEN F R DIE PRAXIS HANSER HANSER Tiemeyer Hrsg Handbuch IT Management Konzepte Methoden L sungen und Arbeitshilfen f r die Praxis 3 berarbeitete und erweiterte Auflage 739 Seiten ISBN 978 3 446 41842 4 Informationstechnik IT hat inzwischen so gut wie alle Gesch ftsbereiche durchdrungen und kann ber Erfolg oder Misserfolg der Unternehmens t tigkeit entscheiden Deshalb nehmen IT Manager in Unternehmen eine ganz zentrale Rolle ein Damit IT Manager f r die Praxis ger stet sind stellt dieses Handbuch umfassendes aktuelles und in der Praxis unverzichtbares Wissen aus allen Bereichen des IT Managements zur Verf gung Die Autoren alle samt Experten auf ihrem Gebiet vermitteln die F higkeit zur Entwicklung von IT Strategien technisches Know How und fundiertes Wissen zu Managementthemen und F hrungsaufgaben Mehr Informationen zu diesem Buch und zu unserem Programm unter www hanser de computer Anforderung gut chris RUPP
45. Kernprozess Beschaffung bergeordneter Beschaffung Prozess Identifizierte Beschreibung der Prozessinstanz Abweichung der Prozesse Instanzgranularit ten voneinander Wareneingangs Eine Instanz beinhaltet einen kompletten Wareneingang oder eine Teil gering prozess lieferung unter einer Bestellnummer Materialbestellung Eine Instanz beinhaltet einen kompletten Bestellvorgang f r ein oder mehre gering re Artikel bei einem Lieferanten unter einer Bestellnummer Lieferantenauswahl Eine Instanz beinhaltet die Auswahl Bewertung und Anlage eines neuen hoch Lieferanten f r zuk nftige Bestellungen Rechnungspr fung Eine Instanz beinhaltet die Pr fung einer eingegangenen Rechnung mit gering einer Rechnungsnummer zu einem Bestellvorgang mit einer Bestellnummer Materiallogistik Eine Instanz beinhaltet die logistischen Aktivit ten zur Einlagerung bzw gering jedoch Benen Weiterverteilung eines Wareneingangs innerhalb des Unternehmens nung missverst ndlich ferungen eines Lieferanten die Aktivit ten Wareneingang oder Rechnungspr fung bei jeder Sendung durchlaufen Aus diesem Grund ist zu pr fen ob die Aktivit t Liefe rantenauswahl nicht grunds tzlich anders 1m Prozessmodell einzuordnen ist Bei der Aktivit t Materiallogistik ist mit Hilfe der Beschreibung erkennbar dass es sich um einen Vorgang handelt der zur gew hlten Instanzgranularit t passt Betrachtet wer den zum Beispiel immer die logistischen Aktivit
46. Modelle k nnen auch rein technische Services mo delliert werden Auf Ebene der ausf hrbaren IT Modelle sind sie teilweise zwingend not wendig In einem Prozessmodell steht jedoch der Prozess m Vordergrund und nicht die Service modellierung Prozessmodelle s nd unter dem Gesichtspunkt erstellt worden Abl ufe ab zubilden Um dieses Ziel zu erreichen wurde eine Prozesshierarchie etabliert und Prozes se werden entlang hres Ablaufes in detailliertere Prozesse heruntergebrochen Abbildung 7 2 zeigt die Ebenen eines Prozessmodells und die Ausrichtung entlang von Prozessen Services sind leistungsorientiert Sie stellen innerhalb eines fachlichen Themengebietes Leistungen bereit Diese Leistungen sollen prozess bergreifend konsumiert werden Beide Problemstellungen zu hohe Komplexit t in der Prozesswelt und zu hohe Komplexit t in der Servicewelt sollen mit der gleichen Methode gel st werden n mlich der Komplexi t tsreduktion durch Strukturierung Je tiefer die Hierarchieebene ist umso st rker wird eine andere Aussage verfolgt In der Prozesswelt ist es die Detaillierung eines Ablaufes in der Servicewelt die Detaillierung einer Leistung Die Hierarchisierung der Prozesse kann aus diesem Grunde nicht zur Strukturierung der Services genutzt werden vertikale Dekomposition 7 2 Services und SOA horizontale Dekomposition Kernprozesse 5 6 Hauptprozesse 3 5 Unterprozesse 20 40 Prozessaktivitaten optional 20 40 Pro
47. Output Verantwortliche KPI Instanzen Die Modellierung der Gesch ftsservices ihrer Operationen und Fahigkei ten aus einer statischen Sicht erl utert Kapitel 7 Die Modellierung der Services ber das Objekt Gesch ftsservice hat jedoch eine Schw che in Bezug auf das angestrebte Vorgehen in dem fachliche Services durch Prozessmo delle spezifiziert werden sollen dem Objekt Gesch ftsservice kann in der Oracle BPA Suite kein Prozessmodell hinterlegt werden Daher bedient sich die abgebildete Modellie rung eines zus tzlichen Objekts vom Typ Use Case das redundant zur Operation des Gesch ftsservices modelliert wird vgl Nachlieferung berpr fen n Abbildung 8 9 Weil das Use Case Objekt vom Typ Funktion ist k nnen Prozessmodelle sowohl als Ereignisgesteuerte Prozesskette EPK als auch als Business Process Diagram BPD der BPMN in der Oracle BPA Suite hinterlegt werden Mit diesem Modellierungsansatz l sst sich das hier geschilderte Vorgehen umsetzen Ein Service soll in der Regel nicht nur eine einzelne Funktionalit t anbieten sondern ber Operationen mehrere zusammengeh rige Dienstleistungen kapseln Diesen Zusammen hang zeigt das Servicezuordnungsdiagramm in Abbildung 8 10 Der Service Lieferungs kontrolle bietet die Operationen Nachlieferung berpr fen und Nachlieferung rekla mieren an Der Service Lieferungskontrolle k nnte dar ber hinaus weitere Operationen wie T
48. 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 grundle gend ndern m ssen Dies erh ht nicht gerade die Akzeptanz der neuen L sung Tats ch lich untersch tzen Unternehmen den enormen Aufwand einer solchen organisatorischen Ver nderung Organisatorische Ver nderungen stellen in sich eigene Change Manage ment Projekte dar deren Umsetzung ber die technischen Aspekte einer Systemeinf hrung weit hinausgeht Grundlegende Ver nderungen in den Arbeitsabl ufen sollten also genau estens auf hre Notwendigkeit gepr ft werden E n IT Projekt wird in den meisten F llen keine Verbesserung dadurch erzielen dass man den Mitarbeitern Experten auf ihrem Fachgebiet vorschreibt wie sie ab sofort ihre Arbeit zu erledigen haben Es muss viel mehr darum gehen zu definieren wie IT die Arbeit der Experten unterst tzen und somit verbessern kann In den allermeisten F llen kann man sagen Nicht die Gesch ftsprozesse m ssen der IT folgen sondern die IT folgt den Gesch ftsprozessen Die zugrunde liegende These hatte Nicholas Carr bereits im Mai 2003 im Harvard Busi ness Review Carr03 festgestellt als er erl uterte dass Wettbewerbsvorteile nicht mehr durch IT als solche IT besitzt heute jedes Unternehmen sondern durch deren optimalen
49. Prozessschrittes mit der aufzurufenden Software service Operation im Modell abgebildet werden Nun fehlt lediglich noch die Verkn pfung 213 8 Der prozessgetriebene SOA Ansatz Lager Softwareservice Service L P d Operationstyp Technisch ease ran i gt a Softwareservice reserviere Operationstyp Abbildung 8 13 Software Lagerbestand Modellierung eines techni schen Service mit Operatio aB nen im Zugriffsdiagramm servicetyp der Softwareservice Operation zu ihrem Softwareservice Dieser Zusammenhang kann in einem Zugriffsdiagramm vgl Abbildung 8 13 modelliert werden Hierin werden dem technischen Service Softwareservicetyp seine Operationen Softwareservice Operations typ zugeordnet was wiederum Bestandteil der statischen Servicemodellierung vgl Kapi tel 7 ist In diesem Diagramm wird dar ber hinaus ersichtlich welche Operationen der technische Service kapselt Der Modellierungsaufwand dieses Vorgehens ist relativ gro und ben tigt zudem Konven tionen und eine Qualit tssicherung um eine einheitliche Modellierung zu gew hrleisten Wird kein modellbasiertes Serviceportfolio in der BPA Suite gepflegt oder erscheint der Aufwand zu hoch kann alternativ ein pragmatischer Ansatz genutzt werden Bei automa tisiert ablaufenden Prozessschritten k nnen die Informationen zur technischen Schnittstel le in den Attributen der BPA Objekte erfasst werden In den Att
50. Regeln nutzen Durch die Ver kn pfung der prozessorientierten Events mit den relevanten Prozessschritten des WEK wissen wir an welchen IT Anwendungssystemen die Sonden ansetzen m ssen Tabelle 9 17 Benutzte Methodenobjekte der Oracle BPA Suite Modellname ETL Systeme Sonden Sonden im WEK Diagrammtyp Anwendungssystemdiagramm Zugriffsdiagramm EPK Symbol Typ Anwendung Typ Modul b Attribut ERM Ereignis Funktion Fazit 258 Die schrittweise Umstellung der bestehenden Softwarearchitektur auf serviceorientierte Architekturen mit wiederverwertbaren Anwendungskomponenten in Verbindung mit dem Einsatz von Systemen zum Business Process Management BPM wird die Implementie rung von Systemen zum Process Monitoring Mining unterst tzen Peis06 Systeme zur Messung der operativen Effizienz werden eine stetig steigende Bedeutung erhalten da die Kosten zur Implementierung in den n chsten Jahren best ndig sinken werden Im Markt etablieren sich bereits BAM L sungen f r das Process Monitoring und auch die Anbieter von L sungen rund um das Corporate Performance Management CPM entwickeln L sungen f r das Process Mining Aus unserer S cht liegt ein wesentlicher Erfolgsfaktor bei der Implementierung eines Pro cess Warehouse n der Modellierung der fachlichen Zusammenh nge und der Implemen tierung der Datenbewirtschaftung Die Anreicherung der Prozessmodelle mit Informati onen zu den ben tigten Kennzahlen bildet den e
51. Sicherstellung eines kontinuierlichen Gesch ftsbetriebs Erf llung und Einhaltung gesetzlicher Vorschriften Klare Zuweisung fachlicher Verantwortlichkeiten Klare Zuweisung technischer Verantwortlichkeiten bergreifende Nutzung von Anwendungssoftware in verschiedenen Unternehmensbereichen Sicherstellung technologischer Unabh ngigkeit Durchsetzung von Standardapplikationen Gew hrleistung einer guten Bedien und Anwendbarkeit Unternehmens bergreifende Nutzung von Informationen Sicherstellung des jederzeitigen Informationszugriffes Klare Zuordnung von Informationsverantwortlichen Etablierung von Standards im Informationsmanagement Sicherung der Informationen der Organisation gegen Verluste _ _ _ Steuerung verwendeter Technologien Sicherstellung von Interoperabilitat Sicherstellung eines kontinuierlichen Gesch ftsbetriebs 16 Erf llung und Einhaltung gesetzlicher Vorschriften Klare Zuweisung fachlicher Verantwortlichkeiten Klare Zuweisung technischer Verantwortlichkeiten bergreifende Nutzung von Anwendungssoftware in verschiedenen J Sicherstellung technologischer Unabh ngigkeit Sicherstellung von Interoperatibilit t Steuerung verwendeter Technologien Sicherung von Informationen der Organisation gegen Verluste Etablierung von Standards im 7 Informationsmanagement i Klare Zuordnung von Informationsverantwortlichen Sicherstellung des jederzeitigen Informationszugriff
52. Steuerungs modelle Benutzer schnittstellen Technologie modell System architektur Geschaftsregeln Sicherheits Ablauf architektur steuerung Netzwerk architektur Typisierte Auspragung Regel Datenmodelle spezifikation MEE INN Funktions eer ae Instanzen Ee instanzen Netzwerk Richtlinien MEIE ET Mitarbeiter Gesch ftsf lle Abbildung 2 1 Struktur und Inhalt des Zachman Frameworks existiert keine offizielle Methodik so dass der Anwender bei der Nutzung der jeweiligen Matrixfelder auf sich selbst gestellt ist Damit liefert das Zachman Framework eine Blaupause die als Ausgangspunkt f r den Strukturentwurf Ihres individuellen EA Metamodells verwendet werden kann Sie m ssen aber selber festlegen mit welchen Artefakten Sie Inhalte beschreiben m chten und in welcher Form diese miteinander in Beziehung stehen Eine zweite Gruppe sind die st rker dynamisch or entierten Frameworks Sie bieten Pha senmodelle und Arbeitsanweisungen zur Abwicklung eines EA Projektes Eines der be kanntesten Beispiele f r ein dynamisches Framework ist The Open Group Architecture Framework TOGAF Dabe handelt es sich um eine Sammlung von Vorgehensweise zur iterativen Entwicklung einer Enterprise Architecture anhand eines Phasenmodells mit genauen Angaben zu den Eingangsvoraussetzungen und Ergebnissen jeder Phase Eine genaue Darstellung der Vorgehensweise finden S e unter Toga09 Statisch
53. Teilnehmer zu vergebenden Punkte teilen Sie die Summe der Grund s tze durch 2 Haben Sie eine ungerade Zahl an Grunds tzen identifiziert so wird nur der ganze Anteil der oben genannten Division verwendet Es ist jedem Teilnehmer freigestellt die Punkte entweder gleichverteilt auf die Grunds tze zu vergeben alle Punkte einem Grundsatz zuzuordnen oder individuell zwischen verschiedenen Grunds tzen zu gewich ten Wichtig ist dass die Gesamtzahl m glicher Punkte nicht berschritten wird Zur Er fassung der Ergebnisse des Brainstormings k nnen S e eine Aufstellung siehe Tabelle 3 2 verwenden Im Anschluss an die Vergabe der Punkte tragen Sie die Ergebnisse innerhalb eines Kivi atgraphen auf Abbildung 3 1 zeigt das Ergebnis f r das obige Beispiel Sortieren Sie anschlie end die Grunds tze nach ihrer Bewertung in absteigender Reihen folge und gruppieren Sie diese anschlie end nach Schwerpunkten S e k nnen Modellie rungsgrunds tze mehreren Gruppen zuordnen wenn sie nicht eindeutig zu einer Gruppe geh ren In den meisten F llen ist es f r den Metamodell Entwurf ausreichend das obere Drittel der bewerteten Grunds tze weiterzuverfolgen 35 3 Aufbau des Metamodells Tabelle 3 2 Auswertung eines Brainstormings zur Ermittlung der Modellierungsgrunds tze Beispiel Brainstorming zur Erfassung der Modellierungsgrunds tze bei Teilnehmeranzahl N o1 max pro Teilnehmer zu vergebende Punkte erreichte Summe
54. Zum Beispiel f hrt die Beziehung l uft auf zwischen Server und Anwendung aus der Domain Level Matrix zu einer Beziehung l uft auf zwi schen den Entit ten Anwendungssystem und Hardwareressource Zentrale Objekttypen der Domain Level Matrix die in einer Entit t im Metamodell zusammengefasst werden f hren immer zu einer Selbstreferenz bei der betrof fenen Entit t Beziehungen zwischen nicht zusammengefassten Objekttypen der Domain Level Matrix werden im Metamodell als 1 n oder m n Beziehung abge bildet Abbildung 3 8 zeigt den Metamodellentwurf der auf Basis der Domain Level Matrix er stellt wurde Aus Gr nden der vereinfachten Darstellung empfehlen wir Ihnen nur die Ak tivbezeichnung zum Beispiel Anwendungssystem unterst tzt Prozess in das Metamodell aufzunehmen Die Leserichtung k nnen Sie durch einen Pfeil ber dem Beziehungstyp anzeigen Auf die Darstellung der Passivbezeichnungen zum Beispiel Prozess wird un terst tzt durch Anwendungssystem f r die Entit ten Prozess und Anwendungssystem wird aus Gr nden einer bersichtlichen Darstellung verzichtet Diejenigen unter Ihnen die sich auch mit klassischer Daten und ER Modellierung befas sen werden unseren Ansatz als stark vereinfacht empfinden Unser Ziel ist es aber nicht eine nach den Anforderungen der Datenmodellierung exakte Beschreibung zu erstellen Vielmehr m chten wir mit unserem Vorgehen dem Business Analysten ein einfaches Ver fahren
55. an die Hand geben um Metamodelle zu entwerfen Da es nicht Ziel ist das Metamodell automatisiert in ein Werkzeug zu berf hren ist der vereinfachte Ansatz an dieser Stelle zul ssig Dennoch weisen wir darauf hin dass zur Umsetzung eines Metamodells in einem Modellierungswerkzeug mit offenem Metamodell weitergehende Kenntnisse in der Datenmo dellierung durchaus hilfreich sind 3 2 Der werkzeugneutrale Modellentwurf lt lt ist Zusammengesetzt aus ist dnet Organisations befindet sich Ist zugeoranet zu eTinaet sicn an gt ist Vorg nger von ne gt ist verantwortlich fur greift zu auf bearbeitet unterst tzt Anwendungs bearbeitet Gesch fts Prozess gt gt E system objekt l uft auf p y ist zusammengesetzt aus s 1 n Beziehung zZ Software nutzt Hardware n m Beziehung ressource ressource Abbildung 3 8 Entit ten und Beziehungen zusammengefasst im Metamodell Beispiel Tabelle 3 6 Beziehungen der Entit ten im Metamodell Zentrale Entit t im EA Standort Organisations Objekttypen Metamodell i i Aktivit ten mengesetzt aus Gesch fts Software Hardware objekt ressource ressource greift zu bearbeitet bearbeitet E Standort Standort Unternehmen Organisa befindet list zusammen Abteilung tionseinheit sich an gesetzt aus Person ist zugeordnet zu
56. beteilig ten Personenkreis der in der Regel sehr heterogen zusammengesetzt ist zu Verwirrung f hrt Prozessurale und organisatorische Inhalte werden h ufig in engem Zusammenhang gesehen Im Gegensatz dazu k nnen anwendungs informations und infrastrukturbezoge ne Inhalte von den meisten Beteiligten bereits w hrend der ersten Entwurfsschritte gut un terschieden werden Die vorgenommene Trennung basiert demnach haupts chlich auf Erfahrungen die wir im Laufe der Jahre bei der Konzeption von Metamodellen gesammelt haben Tabelle 3 3 Zuordnung der gefundenen Objekttypen zu den Sichten Zentrale Objekttypen Sicht erweitert Prozesse Prozess Architektur Aktivit ten Standort Organisations Architektur Unternehmen Abteilung Person Anwendungen Anwendungs Architektur Applikationen Daten Daten Architektur Datenbank Infrastruktur Architektur Server 41 3 Aufbau des Metamodells 42 Anschlie end erstellen Sie die Domain Level Matrix Wir empfehlen dass Sie dazu eine Metaplan Tafel nutzen da ein Flip Chart f r diese Arbeit in der Regel zu klein ist Abbil dung 3 4 zeigt die Vorlage f r eine Domain Level Matrix die Sie direkt auf eine Meta plan Tafel berf hren k nnen Prozess Organisations Anwendungs Daten Infrastruktur Architektur Architektur Architektur Architektur Architektur TE Ta Ta PN i Le an Abbildung 3 4 Domain Level Matrix Ordnen Sie die identifizierten Objekttypen eindeut
57. cht W hrend in der Fachsicht jedoch die fachliche Aktivit t unabh ngig von ggf bestehender IT Unterst tzung beschrieben wird wird in der IT Sicht die Interaktion zwi schen dem Benutzer und dem System zur erfolgreichen Durchf hrung der fachlichen Ak tivitat dargestellt siehe Abbildung 6 3 In der IT Sicht sind durch die entsprechende Darstellung folgende Fragen zu beantworten E Welche Verarbeitungsschritte sind im Rahmen des Programmablaufs durchzuf hren E Wie ist der zeitlich logische Ablauf dieser Verarbeitungsschritte wann wird was ge macht E Wer darf welche Verarbeitungsschritte durchf hren bzw welche Verarbeitungsschritte fuhrt das System automatisch durch E Welche Daten werden f r die Verarbeitungsschritte ben tigt Input E Welche Daten werden in den Verarbeitungsschritten bearbeitet und neu erzeugt Out put E Wie sieht die Benutzerschnittstelle Bildschirmmaske f r die Verarbeitungsschritte aus E In welchen Verarbeitungsschritten werden Schnittstellen zu anderen IT Systemen ver wendet Der Detaillierungsgrad bei der Modellierung des Systemablaufs ist stark abh ngig vom je weiligen Projektkontext sowie von den Anforderungen der sp teren Systembenutzer aus der Fachabteilung F r den an dieser Stelle nicht betrachteten Fall dass ggf auch eine Stan dardl sung zur Unterst tzung des Fachprozesses beschafft werden soll ist es sicherlich ein leuchtend dass eine konkrete Beschreibung des Systemablau
58. dem Ware Service verbirgt nur dazu dient den Prozess Wareneingang zu unterst tzen Die Verbindung zwischen dem Kerngesch ftsprozess und dem Service ist vielmehr der Hinweis darauf dass hier eine oder mehrere Leistungen aus dem Ware Service verwendet werden vgl Abbildung 7 3 159 7 Identifizierung und Modellierung fachlicher Services fur SOA 160 Weil Verbindungen zwischen Service und Prozess auf oberster Ebene nicht viele Informationen fur den Modellbenutzer transportieren ist es empfehlenswert sie hier eher sparsam zu nutzen Services sollen prozessubergreifend genutzt wer den Wurde man alle Prozesse mit allen Services verbinden sobald sich eine Verbindung in einer der darunter liegenden Ebenen ergibt dann leidet darunter die Ubersichtlichkeit des Diagramms sehr Hat man sich entschieden zu einer Servicenutzung auch eine Servicehierarchie zu model lieren kann es durchaus sinnvoll sein eine andere Anzahl an Ebenen als im Prozessmo dell zu haben Deswegen gibt es auch keinen Zwang nur Service mit Prozessschritten auf gleicher Ebene zu verbinden Services besitzen in ihrer Schnittstellenbeschreibung Eingangs und Ausgangsnachrichten Damit wird beschrieben was der Service ben tigt um die angeforderte Leistung realisie ren zu k nnen Im Telefonbuch Service k nnte die Eingangsnachricht der Name sein nach dem wir suchen wollen Die Ausgangsnachricht beschreibt das Ergebnis das der Ser vice liefern
59. der Artefakttypen n die Modellbereiche EA BPM und SOA und deren Detaillierung 1m jeweiligen Modellbereich Sie dient Ihnen als Orientierungspunkt zur Strukturierung des sp teren Gesamtmodells und der Modellierungsmethodik Tabelle 2 2 Zuordnung und Detaillierung des Artefakttypen zu den Modellbereichen Funktionen detailliert fachlich detailliert technisch Organisationseinheiten Geographische Strukturen Geschaftsobjekte abstrakt Daten P detailliert detailliert Anwendungssysteme detailiet Fachliche Services Technische Services Cs hk Se detailliert Infrastrukturen detailiet f Wichtig ist zu beachten dass 1m integrierten Modell nicht alle Artefakttypen modelliert werden m ssen Ber cksichtigen Sie bei der Auswahl immer Ihre individuellen Gegeben heiten und Anforderungen Au erdem helfen Ihnen die in den nachfolgenden Kapiteln beschriebenen Heuristiken beim weiteren Aufbau Ihrer individuellen Modellierungsstruk tur 25 2 Integrierte Modellierung fur EA BPM und fachliche SOA 26 Jeder Artefakttyp der in mehr als einer Spalte in Tabelle 2 2 zugeordnet ist befindet sich in der Schnittmenge zweier Modellbereiche Fur diese Artefakttypen m ssen wir eine genaue Abgrenzung definieren in welchem inhaltlichen Kontext er in welchen Modell bereich geh rt Die Artefakttypen Funktionen Organisationseinheiten geographische Strukturen Daten und fachliche Services lassen sich je nach Grad der
60. der strukturierende Gesch ftsservice ein fachlicher Ser vice Er umfasst eine Menge an F higkeiten und Gesch ftsservices Ein Gesch ftsservice stellt eine Einzelleistung dar Somit sind sich Gesch ftsservice und F higkeit an dieser Stelle sehr hnlich Dieses Vorgehen scheint auf den ersten Blick berfl ssig Wir m chten an dieser Stelle jedoch nicht auf die F higkeiten und auch nicht auf die Gesch ftsservices verzichten Die F higkeiten stellen in der BPA Suite eine Art Kleber dar und sind aus diesem Grunde auf der Abbildung zwischen den fachlichen Detailmodellen und den fach lichen IT Modellen aufgef hrt Die BPA Suite nutzt unter anderem die F higkeiten Such ergebnisse sinnvoll einzuschr nken Eine F higkeit ist jedoch ein beschreibendes Merk 163 7 Identifizierung und Modellierung fachlicher Services fur SOA 164 mal Es kann vorkommen dass eine Fahigkeit von zwei strukturierenden Geschaftsservices bereitgestellt wird In einem solchen Fall ist die Verkn pfung zwischen Funktion und F higkeit nicht ausreichend da nicht eindeutig ist welcher strukturierende Gesch ftsservice die Leistung f r die Funktion bereitstellt Die Geschaftsservices werden ben tigt um eine eindeutige Serviceverwendung zu modellieren Ein Geschaftsservice ist mit mindestens einer F higkeit verbunden die der strukturierende Gesch ftsservice umfasst Soll eine Funktion im Prozess durch einen Service unterst tzt werden wird sie mit
61. die genau an der Schnittstelle zwischen fachlicher und IT Modellierung liegen Wesentliches Kriterium zur Einordnung in diesen Bereich ist dass die beschriebenen Inhalte bereits einen IT Bezug haben gleichzeitig aber immer noch relevant s nd f r die fachlichen Nutzer des Modells Beispielsweise stellt ein fachlicher IT Prozess bereits klar einen IT Bezug her ist gleich zeitig aber auch relevant f r einen fachlich orientierten Nutzer da dieser sp ter mit dem IT Prozess zum Beispiel einer Bedienungsanweisung f r ein IT System in Ber hrung kommt In diesem Modellbereich werden IT Anwendungsf lle IT Prozesse IT Gesch fts objekte IT Rollen IT Services Maskendefinitionen und Maskenfl sse abgelegt 5 2 Aufbau des Grundmodells Informationstechnische Inhalte Innerhalb dieses Modellbereiches werden alle Informationen abgelegt die eindeutig IT spezifisch und f r einen fachlich orientierten Nutzer des Modells in der Regel nicht rele vant sind Er enth lt generierte BPEL Diagramme die IT Architektur SOA und XSD Profile Dynamische und statische Unterteilung Anschlie end unterteilen S e jeden Hauptbereich in einen Modellteil f r dynamische und statische Inhalte Ersterer fasst alle Inhalte die das zeitlich logische Verhalten eines Pro zesses beschreiben zusammen Statische Inhalte beschreiben Ressourcen die in Prozessen erzeugt genutzt oder verbraucht werden Tabelle 5 9 zeigt den von uns empfohlenen Grundaufbau
62. eren Modellierungsprojekten eine Beschr nkung der Unternehmenskernprozesse zu einer deutlich besseren prozessorientier ten Darstellung des Unternehmens f hrt Um die Kernprozesses eines Unternehmens zu ermitteln ist es hilfreich sich von der her k mmlichen funktional orientierten Betrachtung eines Unternehmens zu l sen Moderne Organisationsstrukturen setzen nicht mehr auf funktionale Silos sondern betrachten Pro zesse durchgehend von einem Initiator bis zum Abnehmer der Leistung des Prozesses Dies gilt auch f r interne Prozesse die keinen direkten Bezug zum Endkunden eines Un ternehmens haben d h auch interne Stellen die an der gesamten Prozessleistung beteiligt sind sollten immer als Prozess Kunden betrachtet werden Schm07 Zur Orientierung welche Kernprozesse n Ihrem Unternehmen vorhanden sind bietet es sich an Referenzprozesse als Hilfestellung zu nutzen In der Regel beschreiben solche Sammlungen die Prozessstruktur jedoch nur sehr grob Detaillierte Inhalte bis hin zu einer Beschreibung der einzelnen Abl ufe und Aktivit ten werden Sie nur in wenigen Einzelfal len finden und m ssen meistens k uflich erworben werden Frei verf gbare Referenzmo delle sind meistens sehr generisch und werden in Ihrem speziellen Anwendungsfall n der Regel keine ausreichende Tiefe bieten Als Ausgangspunkt f r ein Brainstorming zu den Kernprozessen des Unternehmens s nd s e aber sehr zu empfehlen Aber auch mit Referenzmodellen w
63. f llung des Unternehmenszweckes beinhaltet beschreiben die durch Kernprozesse erstell ten bzw zwischen den Kernprozessen ausgetauschten und bearbeiteten Objekte die m Rahmen der wertsch pfenden T tigkeiten bearbeiteten Objekte der realen Welt Aus diesem Grund ist f r jeden identifizierten Kernprozess mindestens ein Gesch ftsobjekt zu bestimmen das durch den zugeh rigen Kernprozess komplett bearbeitet wird Mit Hilfe dieser Gesch ftsobjekte k nnen Sie beispielsweise die Prozessleistung der einzelnen Kerngesch ftsprozesse ermitteln 5 2 Aufbau des Grundmodells Zur Identifizierung der prim ren Geschaftsobjekte stellen Sie sich die folgenden Fragen E Welche Gesch ftsobjekte werden in den identifizierten Kernprozessen erstellt oder bearbeitet E Anhand welcher Kriterien kann die Leistung der identifizierten Kernprozesse gemessen werden E Mit welchen Gesch ftsobjekten stehen diese Kriterien in Beziehung Die Erstellung einer Prozesslandkarte kann einen nicht zu untersch tzenden Aufwand verursachen Auf den ersten Blick scheint es als sei diese Arbeit einfach und in kurzer Zeit zu erledigen Da es sich bei der Prozesslandkarte aber um die zentrale Stelle zur Navigati on innerhalb des gesamten dynamischen Teils des Modells handelt und durch die Untertei lung des Unternehmens in Prozessbereiche entscheidende Vorgaben f r die nachfolgende Modellierung gemacht werden sollte man an dieser Stelle nicht zu schnell eine endg l
64. guten Bedien und Anwendbarkeit 3 2 Der werkzeugneutrale Modellentwurf Modell Sicht Informations Architektur Unternehmensubergreifende Nutzung von Informationen Sicherstellung des jederzeitigen Informationszugriffs Klare Zuordnung von Informationsverantwortlichen Etablierung von Standards im Informationsmanagement Sicherung der Informationen der Organisation gegen Verluste Infrastruktur Architektur Steuerung verwendeter Technologien Sicherstellung von Interoperabilit t Es empfiehlt sich f r die Ermittlung der Grunds tze zun chst eine heterogene Teilneh mergruppe aus verschiedenen Bereichen Ihrer Organisation im Rahmen eines Brainstor mings zu befragen Die Gruppengr e sollte zwischen 10 und 20 Personen betragen Er stellen Sie zusammen mit der Gruppe eine m glichst vollst ndige Liste der Grunds tze f r jede Sicht Legen Sie die f r Ihre Organisation relevanten Grunds tze der Modellierung fest Formulieren Sie diese neutral ohne methodische technologische oder organisa torische Einschr nkungen Die Grunds tze beschreiben die Leitlinien des Modells f r Ihre Organisation Listen Sie die Grunds tze f r alle Teilnehmer sichtbar auf Nachdem Sie die relevanten Grunds tze ermittelt haben f hren Sie eine Bewertung der Ergebnisse durch Jeder Teilnehmer des Brainstormings vergibt f r jeden Grundsatz Punk te und dr ckt damit die Bedeutung aus die der Grundsatz fur ihn hat Zur Berechnung der max mal von jedem
65. haben eine eher strukturierende Aufgabe Die Fragestellung lau tet hier Welche Kernleistungen werden in dieser Dom ne angeboten Das Vorgehen wird ber mehrere Ebenen durchgef hrt Als grobe Richtlinie kann angenommen werden dass ein Unternehmen in drei bis vier Ebenen modelliert wird Weil wir unsere Services schon ber das Prozessmodell identifiziert haben k nnen wir die Dom nendekomposition verk rzen Wir m ssen nur die strukturierenden Teile identifizie ren und k nnen anschlie end unsere bereits gefundenen Services zuordnen Business Analysten denken bei einer Dom nendekomposition sehr schnell wieder an Prozesse Achten Sie jedoch darauf dass hier Leistungsbereiche bzw Services identifiziert werden sollen Vergleicht man die obersten Ebenen unserer Modelle die Kerngesch ftsprozesse und die Ebene 0 der Dom nendekomposition wird man viele hnlichkeiten feststellen Auf dieser Ebene k nnen jedoch nicht nur die Kerngesch ftsprozesse n hnlicher Form wiederer kannt werden sondern auch die globalen Objekte Z B kann es eine Dom ne Kunde ge ben in welcher alle Services rund um Kunden enthalten sind Mit den Dom nenmodellen haben wir jetzt eine prozessunabh ngige Strukturierung und Hierarchisierung der Services siehe auch Abbildung 7 3 ber diese Modelle k nnen Servicekonsumenten navigieren bis sie ihren gesuchten Service gefunden haben Aus Sicht der Serviceanbieter bieten sich die gleichen Vorteile die auch
66. l l 7 Kennzahlen Datenglossar I WEK Controlling u IT Rollen zz i Zee l Process I Ziele und Benchmarking l Rollen Erfolgs i l Faktoren I Controlling l Process I Mining l l I Process a Monitoring 240 Technische F Inhalte l 2 Dynamische Statische li Inhalte Inhalte l li i Er IT Architektur 7 lI l lI Anwendungs li systeme l T i a Systeme l l Controlling l lI l lI ETL System J li l l Mining System lI l l l Monitoring i p System li l l l Benchmark l System Abbildung 9 11 Organisatorischer Rahmen f r die Ablage der Modelle in der Oracle BPA Suite 9 7 Modellierung des Prozess Controlling mit der Oracle BPA Suite 9 7 1 Modellierung der statischen Inhalte In einem ersten Schritt erstellen wir die fachlichen bersichtsmodelle f r die statischen Inhalte Neben den grundlegenden Prozessen legen wir bei der Prozessmodellierung Wert auf die Beschreibung der statischen Elemente Als Orientierung halten wir uns an Abbil dung 9 10 die die ben tigten Dom nen zeigt Im Wesentlichen sind dies die Unterneh mensziele und Kennzahlen sowie die Fachbegriffe und der notwendige Ausschnitt aus dem Organigramm 9 7 1 1 Modellierung der Ziele Nun gehen wir auf die Modellierung der f r das Process Controlling relevanten Ziele und Sub Ziele ein Ohne die betriebswirtschaftlichen Grundlagen hinsichtlich der Festlegung betrieblicher Grundsatzentschei
67. modelliert werden ob diese gelesen geschrieben oder bearbeitet wer den BPMN bietet somit eine bessere Unterst tzung beim bergang vom fachlichen zum ausf hrbaren Modell 8 3 Modellierung SOA geeigneter Prozessmodelle EPK BPMN BPEL EK BPMN BPEL Multiple Instances Patterns Estee MI without synchronization ynchronization design time knowledge AA a imple Merge runtime knowledge SS SS Basic Control Patterns MI with no a priori known NJIA N 6 S E lt a D O o Advanced Branching and Synchronization Patterns w2time knowledge Multiple Choice A a EEE EN l e ynchronizing Merge Multiple Merge Peferred Choice gt Interleaved Parallel Routing EEE EEE ee EEE d tructural Patterns Cancellation Patterns Arbitrary Cycles STS ance Activity Abbildung 8 7 Gegenuberstellung der Umsetzbarkeit von Workflow Patterns in EPK und BPMN basiert auf Standard Evaluations auf der Website www workflowpatterns com Discriminator Loe pe N out of M Join Oos a Im weiteren Verlauf dieses Kapitels werden die beiden Notationen f r die SOA Prozess modellierung kombiniert eingesetzt die EPK auf der Ebene der fachlichen Detailmodelle und die BPMN f r die fachlichen IT Modelle Dieses Vorgehen wird von der Oracle BPA Suite unterst tzt und bietet die M glichkeit die St rken der Notationen ideal auszunutzen Zudem kann sich der Le
68. nnen es als Blaupause eines Modells zur Beschrei bung einer Organisation betrachten Abbildung 2 1 zeigt die Bestandteile und den Aufbau des Zachman Frameworks Das Zachman Framework betrachtet eine Organisation unter den sechs Perspektiven Da ten Funktionen Architektur Organisation Zeiten und Motivation Jede Perspektive ist unterteilt in sechs Ebenen mit unterschiedlicher Detaillierung der Inhalte Ausgehend von der globalen Beschreibung der Zielsetzung jeder Perspektive ber das betriebswirtschaft liche Modell die erforderliche IT Unterst tzung das zugeh rige Technologiemodell eine Beschreibung der daraus resultierenden typisierten Auspr gungen und der Auflistung der existierenden Instanzen F r die Verwendung und F llung des Frameworks mit Inhalten 11 2 Integrierte Modellierung fur EA BPM und fachliche SOA Motivation WARUM Funktionen WIE fee Kernprozesse Geografie Architektur Wi Organisation WER Gesch fts ereignisse G ter des Unternehmens Ziele Strategien Zielsetzung Bereich Orga struktur Betriebswirt Modell des Gesch fts Unternehmens plan Business Prozesse Ablaufsteuerung System architektur Daten architektur Systemdesign Logisitknetz OE RET III III Gesch fts objekte IT Ablauf steuerung Interaktions architektur Modell der IT Unterst tzung Aufgaben IT Objekte modelle IT Landschaft
69. seinem Interviewpartner aus dem Fachbereich die Prozesse erl utern und schreibt die Antworten entweder mit oder zeichnet s e auf Tonband auf Die Modellierung der Prozesse erfolgt sp ter durch den In terviewer Im Gegensatz zu Frageb gen haben Sie im Interview die M glichkeit bei Un klarheiten nachzufragen Workshops Nach unserer Meinung sollten Prozessaufnahmen idealerweise 1m Rahmen von Workshops erfolgen Workshops haben ein klares Arbeitsziel der Ablauf ist aber nicht fest vorgege ben und das Ergebnis wird 1m Rahmen der Veranstaltung von allen Teilnehmern gemein 123 6 Modellgest tzte fachliche Konzeption individueller IT Systeme 124 sam erarbeitet Prozessworkshops sollten Sie in Kleingruppen 2 bis 4 Personen aus der Fachabteilung durchf hren Je gr er die Anzahl der Teilnehmer desto mehr Diskussio nen m ssen Sie erwarten Diskussionen sind dabei nicht zwingend als destruktiv zu bewer ten da nur in den seltensten F llen ein Mitarbeiter einen gesamten Prozess bis ins kleinste Detail kennt Dennoch d rfen die Diskussionen ein notwendiges und produktives Ma nicht bersteigen so dass die Gruppe nicht beliebig gro werden sollte Zur Erfassung von Fachprozessen ist es sinnvoll mit Mitarbeitern verschiedener Hierarchieebenen zu spre chen da mit zunehmender Hierarchieh he zwar die Kenntnis und das Verst ndnis des Ge samtprozesses steigen Detailwissen ber kleine Arbeitsaktivit ten jedoch verloren geht An
70. sollen jedoch gleich bleiben Service Level Agreements SLA Die Verbesserung der Service Level Agreements kann einen Nutzen fur das Unterneh men darstellen Z B kann eine h here Verf gbarkeit gew hrleistet werden In diesem Beispiel besitzt es den geringsten Nutzen Gegen berstellungen Die klassifizierten Services k nnen jetzt leichter einander gegen bergestellt werden Wur den z B zu den Services schon erste Kostensch tzungen abgegeben lassen sich m helos Entscheidungsmatrizen erstellen Abbildung 7 11 zeigt ein Beispiel hohe Kosten Q2 Sektor C D Sektor B Sektor A Abbildung 7 11 geringer Nutzen hoher Nutzen Servicegegen berstellung Kosten Nutzen geringe Kosten Die Gegen berstellung kann z B die Entscheidungsfindung unterst tzen welcher Service zuerst implementiert werden soll In diesem Beispiel ist der Sektor A am interessantesten Die Services n diesem Sektor bieten einen hohen Nutzen und verursachen geringe Kosten Dabei liegt die individuelle Definition der Sektoren beim Unternehmen 185 7 Identifizierung und Modellierung fachlicher Services fur SOA 186 7 5 3 Vervollstandigen der Servicebeschreibung durch die Servicespezifikation In der Servicespezifikation werden die Services mit immer mehr Detailinformationen an gereichert Unter anderem werden auch mehr technische Informationen gepflegt Im Ge gensatz zur Serviceklassifikation sind diese Informationen schwe
71. st ndigkeiten und Aufgabengebiete voneinander abgegrenzt Welche Sachverhalte muss ein SOA Modell enthalten das die Zielsetzung verfolgt fachl che Services prozessbasiert zu implementieren und wie k nnen diese zielf hrend und wirtschaftlich in Modellen abgebildet werden Die Antwort auf diese Frage liefert die berlegung welche Zielgruppe mit dem Modell arbeiten wird und welche Inhalte diese Zielgruppe beim Einsatz des Modells erwartet und ben tigt F r ein Modell das bei der technischen Implementierung fachlicher Services eingesetzt werden soll besteht die Ziel gruppe aus zwei Anwenderkreisen SOA Business Analysten und SOA Entwickler 8 3 3 1 SOA Business Analyst Erstellt und gestaltet wird das Modell vom SOA Business Analysten einem fachlich ori entierten Modellierer Der SOA Business Analyst interessiert sich vorwiegend f r die fachliche Leistung des abzubildenden Prozesses und der unterst tzenden Dienste Bei den Diensten fachliche Services interessiert er sich also f r die Funktionalit t die diese sp ter einmal technisch implementierten Services zur Verf gung stellen Wichtig sind hier folglich fachliche Attribute wie die Beschreibung des Dienstes Leistung und Inhalt we sentliche In und Outputs in Form von Gesch ftsobjekten und die Verbindung der fach lichen Services zu den Gesch ftsprozessen im Unternehmen Die vom SOA Business Analysten erstellten Modelle werden in der Regel von Fachbereichen im Unternehmen
72. tern Reservierte Venge Bestell system T Reservierungen ueberpruefen Abbildung 8 11 Fachliches IT Modell in BPMN Notation in der Oracle BPA Suite Wie bereits bei den fachlichen Services in Abschnitt 8 4 1 gesehen gibt es auch hier wie der einen Bezug zur Modellierung des Serviceportfolios vgl Kapitel 7 Dort werden die in der IT umgesetzten technischen Services aus einer statischen S cht als Softwareservices mit Softwareservice Operationen im Modell abgebildet Softwareservice Operationstyp Funktion BPMN Task Verfuegbare ml Abbildung 8 12 Lagermenge sagen tang Verkn pfung technischer Prozessschritte mit ermitteln Serviceoperationen im Funktionszuordnungs diagramm Ziel ist nun die Prozessschritte im Business Process Diagram der BPMN vgl Abbildung 8 11 mit den aufzurufenden Softwareservice Operationen zu verbinden Diese Verkn p fung stellt im Modell die Information zur Verf gung welche Serviceoperation zur Auto matisierung des Prozessschrittes genutzt wird Da das Business Process Diagram BPMN in der Oracle BPA Suite keine entsprechenden Objekte vorsieht k nnen die Softwareser vice Operationen nicht direkt auf diesem Diagrammtyp modelliert werden Alternativ kann aber ein Funktionszuordnungsdiagramm als Hinterlegung am technischen Prozessschritt BPMN Task BPA Objekt Funktion erzeugt werden vgl Abbildung 8 12 In diesem Diagramm kann die Verbindung des
73. tzung zu jeder Entit t und Beziehung einzeln durch die Mit arbeiter in Ihrer Organisation durchf hren die auch f r die Bereitstellung der Inhalte verantwortlich sind So erhalten Sie f r jede Entit t und Beziehung m g lichst realistische Werte Diese Vorgehensweise zur Absch tzung des Modellumfangs ist unter folgenden Voraus setzungen zul ssig m Der betrachtete Modellteil beschr nkt sich auf abstrakte berblicksartige Beschreibun gen m Die ben tigten Informationen zu den Instanzen der Entit ten k nnen jeweils an einer zentralen Stelle beschafft werden m Um Unsicherheiten in der Sch tzung zu ber cksichtigen definieren Sie f r jede Entitat des Metamodells einen Faktor zwischen 1 und 3 m Wahlen Sie den Faktor 1 wenn beide oben aufgef hrten Punkte bei einer Entitat zu treffen m Wahlen Sie den Faktor 2 wenn einer der oben aufgef hrten Punkte bei der betrachteten Entit t nicht zutrifft m Wahlen Sie den Faktor 3 wenn beide oben aufgef hrten Punkte bei der betrachteten Entit t nicht zutreffen Berechnen Sie anschlie end den erforderlichen Erstellungsaufwand je Entit t und Bezie hung als Produkt aus Erstellungsaufwand je Entit t Anzahl x Aufwand zur Ermittlung je Entit t o Beziehung x Faktor Der initiale Erstellungsaufwand Ihres Modells ergibt sich dann als Summe aus Erstellungsaufwand Modell gt Erstellungsaufwand je Entitat 3 2 Der werkzeugneutrale Modellentwurf Tabelle 3 9 zeigt ei
74. und Mott08 9 7 1 3 Modellierung der Fachbegriffe Das Fachbegriffsmodell eignet sich zur verbindlichen Beschreibung der betriebswirtschaft lich relevanten Daten Jedes Gesch ftsobjekt wird durch ein plattformunabh ngiges Objekt vom Typ Fachbegriff dargestellt Aus Gr nden der bersichtlichkeit werden in Abbil dung 9 14 lediglich einige Gesch ftsobjekte aus dem Bereich des Process Controlling auf gef hrt F r den Grad der Detaillierung der Fachbegriffsmodelle kann keine allgemeing l tige Regel angegeben werden Er richtet sich nach der jeweiligen Dom ne und den Rah menbedingungen des Projektes Komplexe fachliche Aufgabenstellungen setzen dement sprechend detaillierte Modelle voraus Liegt hingegen die Schwierigkeit eher n der techni schen Realisierung als m fachlichen Umfeld so sind wenige einfache Fachbegriffsmodel le ausreichend Die Fachbegriffsmodelle sollten dabei immer klar strukturiert und leicht verst ndlich sein Schi09 S 94 Entscheidend ist somit die modell bergreifende Zusammenzufassung der genutzten Fach begriffe Insbesondere bei den Kennzahlen ergibt dies einen Sinn da in den Unternehmen oft Kennzahlen bereichs bergreifend unterschiedlich verstanden werden Datenglossar Fachbegriffsmodell Aggregierte Darstellung der KPI Grafikdarstellung der Prozessinstanz WEK amp Multidimensionale Analysen Es Prozessdaten WEK 5 daten WEK ea Systemnachricht 2 Abbildung 9 14 Modellierung der Fa
75. 06 Essentielle Fragestellung 37 Betriebsorganisation 39 Informationsmanagement 39 Standardisierung 39 Zerlegung und Bewertung 39 F Fachkonzept 137 Fachliche Anforderung 117 Fachliches BPM 15 Fachliches Detailmodell 196 Fachliches IT Modell 197 Fachlicher Service Business Service 197 Fachliche SOA 16 Fachliche Systemstruktur 133 Fachsicht 121 F higkeit 163 263 Register 264 Framework 11 Fusion Middleware Plattform 57 G Geschafts Architektur 13 Geschaftsobjekt 20 Geschaftsprozess 20 Gesch ftsservice 163 211 Grundmodell 79 Aufbau 79 Grunds tzliche Identifikationsmethode 178 H Hauptprozess 90 Horizontale Modellierung 29 Horizontale Segmentierung 82 Individualentwicklung 121 Infrastruktur 21 Infrastruktur Architektur 14 Instanzgranularit t 80 Detaillierung eines Prozess 96 Hauptprozessebene 93 Kernprozessebene 90 Unternehmensinstanzebene 83 Zusammenhang 95 Integriertes Modell 10 18 Anforderung 27 Artefakttyp 19 Erfolgsfaktor 18 Gliederung 18 Grundstruktur 111 Inhalt 22 Schnittmenge 25 Zielsetzung 21 IT Modell ausfuhrbar 163 fachlich 163 IT Projekt 117 IT Sicht 121 IT Unterst tzung 127 K Kantentyp 60 Kennzahl 222 235 siehe auch Prozesskennzahl Kennzahlenhierarchie 242 Kernprozess 83 prim r 84 sekund r 84 Kommunikationsl cke 8 M Management 8 Maske 130 Maskenfluss 133 Maskenlayout 130 Maskenstruktur 130 Meta Modell 33 Attribut 50 Erstellungsaufwand 53 geschlossen
76. 068 Zugrfisdiagramm Plegesoracher 15069 Augnfisdiagramm Erstellzeitpunkt 15070 ugnfisdiagramm Ersteller 15071 Zugriffsciagramm Tite 1 V a at arn erfugbare 15072 Augnffsdiagramm Verkn pfung 1 15073 Zugriffsdiagramm Parameter 1 Diag rammattribute 15074 Zugnfisciegr ENT area Er infin OO Zugrittsckege Arbeitsblatt ee 15076 Augnifsdiagr eter 2 15077 Zugnffsciagr Modellattributtype 15078 ugnifsdiagra f pfung 3 15079 Zugriffschagramm Parameter 3 15080 Zugriffschagramm Tied 15081 Zugrfisdiagramm Verkn pfung 4 150A Funrifterkanrar Parameter 4 F UHA Hi Madelippen Hodelabiribubiypen _ _Sybaimen _ _ Obiekiatiibutiper Hinteriequngen Bexetumestypen k 135 pn 15973 Datens tzen gefunden 753 Ol Te Im 71 i y Abbildung 4 14 Identifizierung passender Diagramm Attributtypen in der Excel Analysedatei 73 4 Die Umsetzung des Metamodells Dokumentation der individuellen Oracle BPA Suite Methode Wir empfehlen die ausgew hlten Methodeninhalte in Form einer Tabelle zu dokumentie ren Auf diese Weise stellen Sie alle wesentlichen methodischen Zusammenh nge Ihrer individuellen Oracle BPA Suite Anpassung zusammengefasst dar Verwenden Sie zur Dokumentation ein Tabellenkalkulationsprogramm wie zum Beispiel Microsoft Excel und schreiben Sie die individuell genutzte Methode innerhalb dieser Datei kontinuierlich fort Zusatzlich zu den bereits erwahnten Excel Analyse dateien verfugen Sie damit jederzeit uber eine aktuelle Darstellung
77. 10 F higkeiten Gesch ftsservices zum strukturierenden Gesch ftsservice modellieren 4 Gesch ftsservices mit F higkeiten verbinden 1 d R handelt es sich um eine Eins zu eins Verbindung aus der Menge der F higkeiten vom strukturierenden Gesch ftsservice Gesch ftsservices mit Input Output Fachbegriffen versehen 6 Softwareservice modellieren ggf durch Import einer technischen Servicebeschrei bung 7 Modellieren der F higkeiten des Softwareservice F higkeiten k nnen auch beim Im port einer technischen Servicebeschreibung angegeben werden Wird ein Softwareser vice mit einem strukturierenden Gesch ftsservice verbunden erbt dieser im Service Repository die F higkeiten des strukturierenden Gesch ftsservice Softwareservice Operationen zum Softwareservice modellieren 9 Wurde eine technische Servicebeschreibung importiert kann die technische Operation leicht mit dem Softwareservice Operationstyp verbunden werden Operationen zuord nen m Kontextmen eines Softwareservice 165 7 Identifizierung und Modellierung fachlicher Services fur SOA 166 10 Der strukturierende Geschaftsservice wird mit dem Softwareservice verbunden Die von der BPA Suite angebotene Suche nutzt auch die Fahigkeiten um die Servicezuord nung zu erleichtern 11 Modellieren der F higkeit an einer Funktion 12 Suchen und Modellieren des Gesch ftsservice an der Funktion Die von der BPA Suite angebotene Suche nutzt auc
78. 2 ROTA UNS 22 aa lashed bakeries e 228 Ziel des Process onfrolline u een Mosetdaitomeadde 229 94 1 Anforderungen and eIl Systeme ea 229 92 ROH een seen 230 9 4 3 IT Systeme f r das Process Controlling esssssssssssssssesnnnnnnnnnnn 232 PRTC IMLS KUM oiea E E 232 9 5 1 IT Systeme zur Extraktion und Transformation usssssssssssssnnnnnnnnnnnnnnnnnnnn 232 952 11 Sysieme ur dr Analyse eea A alas 234 Inhalt VII Inhalt VIII 9 6 Prozesske InZzahlen nase Sinsen E ER 233 9 6 1 Ermittlung von Prozesskennzahleni seirinin aiana E E 236 9 62 Prozessdurchlauizeit P Datei aanraai an ea 237 9 7 Modellierung des Prozess Controlling mit der Oracle BPA Suite een 237 9 7 1 Modellierung der statischen Inhalte 0eeeeeeeeeeeeneenennnennneeenneennnnnnn 241 9 1 2 Prozesse f r das Process Contollas sisirain sl eee le Rn 245 9 7 3 Modellierung der IT Systeme f r das Process Controlling 251 9 8 Bay ee ne ee te SD na nl a te at ee tela 258 BT 7 1 0511 GARDASEE ERDE a a AEE 261 REGISTER u eden ine ee a es aa ee eee ei a te 263 Vorwort Die erste Idee zu dem vorliegenden Buch entstand bereits vor rund drei Jahren Kurz nach dem die OEM Vereinbarung zwischen Oracle und IDS Scheer bekannt wurde dachten Rolf Scheuch und ich dar ber nach unsere Erfahrungen die wir in 10 Jahren gemeinsamer Nutzung der Werkzeuge von Oracle und IDS S
79. 45 offen 45 Semantische Abdeckung 76 Umfang 53 Umsetzung 57 Metamodell Entit t 45 Methode 58 Modellierungsgrundsatz 34 Modelltyp 59 siehe auch Diagrammtyp N Nicht funktionale Systemanforderung 138 O OASIS 17 Objekttyp 59 Oracle BPA Suite Methodische Einschrankungen 58 Modellierung dynamischer Inhalt 83 Ordnerstruktur 111 Oracle BPA Suite Methode Analyse 62 Dokumentation 74 Individuelle Anpassung 66 Zusammenhang 61 Oracle SOA Suite 216 Orchestrierung 212 Organisationstruktur 20 P PIM 163 Platform Independent Model 163 Platform Specific Model 163 Process Controlling 222 224 IT Systeme 232 Modellierung 239 245 Rollen 230 Ziel 229 Process Excellence 221 Process Mining 225 227 Process Monitoring 225 226 Modellierung 247 Process Warehouse 227 Architektur 232 IT Anforderung 229 Prozessarchitektur 80 Prozessautomatisierung 160 193 Prozessgranularitat 86 Prozesskennzahl 235 Ermittlung 236 PSM 163 siehe auch Platform Specific Model PULL Verfahren 232 PUSH Verfahren 232 S Schnittstelle 155 Semantische Zuordnung 26 Fachlicher Inhalt 26 Fachlicher IT Inhalt 26 Informationstechnischer Inhalt 26 Services 153 154 in der BPA Suite 162 Modellierungsphasen 166 im Prozessmodell 157 zusammengesetzt 160 Servicebeschreibung 186 Servicegranularit t 179 Register Serviceidentifikation 176 ber Gesch ftsobjekte 178 180 ber Namen 178 179 ber organisatorische Gruppen 179 ber Repository 178 b
80. 5 Kantentypen die jedoch teilweise re dundant sind Wie Objekttypen k nnen auch Kantentypen nur umbenannt werden Es be steht keine M glichkeit neue Kantentypen zu erzeugen oder von bestehenden als Kopie abzuleiten Wir raten von einer Ver nderung der Kantentypbezeichnungen ab da sich nderungen ebenfalls stark auf den methodischen Gesamtzusammenhang der Oracle BPA Suite aus wirken Attributtypen Attributtypen legen fest welche zus tzlichen Informationen zu Diagramm Objekt und Kantentypen hinzugef gt werden k nnen Das bestehende Metamodell der Oracle BPA Suite ordnet jedem Diagramm Objekt und Kantentyp bereits individuell Attribute zu Die Version 11g der Oracle BPA Suite verf gt im Standard ber 1268 Attributtypen Ahn lich wie die Kantentypen sind diese teilweise redundant und nicht jeder Attributtyp ist bei jedem Diagramm Objekt bzw Kantentyp verf gbar Attributtypen k nnen umbenannt werden Von der Nutzung dieser M glichkeit raten wir aber aus denselben Gr nden wie bei Kanten und Objekttypen ab 4 3 Methodische Einschrankungen der Oracle BPA Suite Im Unterschied zu Kanten und Objekttypen erm glicht die Oracle BPA Suite Methode die Erzeugung neuer Attributtypen An dieser Stelle finden Sie die einzige Funktionalitat zur Erweiterung des Metamodells die diesen Namen verdient Sie k nnen Attributtypen f r Mehrzeiler Text Bool Wahrheitswerte Werte Wertelisten Ganzahlen Flie kommazahlen Datum
81. 7 3 Modellierung der IT Systeme f r das Process Controlling Nachdem wir nun die die fachlichen Anforderungen an das Process Controlling modelliert haben wenden wir uns den notwendigen IT Systemen zu und beschreiben diese Systeme mit ihren Anforderungen aus der fachlichen Sicht heraus Ein kurzes Res mee Die Ziele wurden beschrieben und wir haben die notwendigen Pro zesse zur Erreichung der Ziele siehe Erfolgsfaktoren abgeleitet Es fehlen nun die IT Systeme und die eigentliche Beziehung der Kennzahlen zum Prozess WEK die Sonden welche die Daten zu den Events werfen und die Basis f r die Auspr gung der Kennzah len bilden Wir fassen s mtliche f r das Process Warehouse n tigen IT Komponenten in einem An wendungssystemtypdiagramm zusammen um eine Dekomposition der ben tigten IT Kom ponenten durchf hren zu k nnen Wie in Abbildung 9 21 beschrieben fassen wir die un terschiedlichen Sub Systeme selber wiederum als Module in der Anwendung Process Warehouse zusammen Tabelle 9 13 Benutzte Methodenobjekte der Oracle BPA Suite Modellname Process Warehouse Diagrammtyp Anwendungssystemdiagramm Symbole Typ Anwendung Typ Modul 251 9 Entwurf und Aufbau prozessgetriebener Kennzahlensysteme 252 Process Warehouse Anwendungssystemtypdiagramm Process Warehouse ETL Systeme Aa wy a idk Abbildung 9 21 Modellierung der Anwendungs systeme des Process Controlling
82. 9 113 5 Das Grundmodell Fachliche Statische IT Gesch ftsobjekte Ablage von detaillierten Beschreibungen zu IT Inhalte Inhalte Gesch ftsobjekten die in IT Systemen abge Forts bildet werden s Kapitel 6 7 8 u 9 IT Rollen der an IT Prozessen beteiligten Rollen s Kapitel 6 7 8 u 9 IT Services Ablage der fachlichen IT Services zur Verwen dung innerhalb einer SOA s Kapitel 7 u 8 Maskendefinitionen Ablage der in Mensch Maschine Interaktionsprozessen genutzten IT Masken s Kapitel 6 Maskenfl sse Ablage der Maskenfl sse analog zu den Mensch Maschine Interaktionsprozessen s Kapitel 6 Informations Dynamische Generierte BPEL Ablage der automatisch generierten BPEL technologi Inhalte Diagramme Prozesse als Containerbereich f r die Anbin sche Inhalte dung der Oracle SOA Suite Statische IT Architektur Anwendungs Ablage der Informationen zu verf gbaren Inhalte systeme a s Kapitel 6 Datenbanken Ablage der Informationen zu verfugbaren Datenbanken Server Hardware Ablage der Informationen zu verf gbaren und virtuelle Server Servern SOA Profile Ablage der automatisch erzeugten SOA Profile zur Anbindung der Oracle SOA Suite In der Oracle BPA Suite ergibt sich daraus die in Abbildung 5 20 dargestellte Ordnerstruk tur Betrachten Sie diese Ordnerstruktur nur als Ausgangspunkt f r Ihre eigenen berle gungen Je nach individueller Zielsetzung werden S e Erg nzungen und Detaillie
83. A Welche Aktivit ten sind betroffen wenn Bale Den ul eine Applikation nicht Abbildung 3 3 Zuordnung der Objekttypen der essenziellen Fragen zu den Modellsichten Bewerten Sie anschlie end das Ergebnis der Zuordnung unter Ber cksichtigung der Grund s tze Sie m ssen sicherstellen dass die Fragestellungen zu den festgelegten Grunds tzen passen Sollten Sie an dieser Stelle erhebliche Abweichungen zwischen den Schwerpunkten der Grunds tze und den den Sichten zugeordneten Fragestellungen feststellen so m ssen Sie dieses Ergebnis kritisch hinterfragen In diesem Fall haben noch nicht alle beteiligten Per sonen das gleich Bild von den Zielen und dem Nutzen des integrierten Modells f r Ihre Organisation Diskutieren Sie dann unbedingt nochmals die Grunds tze und die abgeleiteten Fragestel lungen mit den Teilnehmern und wiederholen Sie die vorhergehenden Arbeitsschritte so lange bis die ermittelten Fragestellungen zu den festgelegten Grunds tzen passen Ermitteln Sie welche Fragen das integrierte Modell in Ihrer Organisation beant worten muss Halten Sie diese Fragen schriftlich fest und richten Sie die Modell struktur daran aus 3 2 3 Entwurf einer Domain Level Matrix Nachdem Sie einen stabilen Stand hinsichtlich der Fragestellungen erreicht haben k nnen Sie mit dem Entwurf einer Domain Level Matrix beginnen Die Domain Level Matrix ist 3 2 Der werkzeugneutrale Modellentwurf die Vorstufe des Metam
84. Aus dem Systemablauf kann nur eine Benutzerrolle Mitarbeiter Warenannahme entnommen werden Auch hier gilt jedoch dass bei einem komplexeren System auch das ggf notwen 6 5 Erstellung eines Fachkonzepts mit der Oracle BPA Suite dige Rollenkonzept ber cksichtigt werden muss Es empfiehlt sich dabei die Zuordnung der notwendigen Benutzerrollen zu den entsprechenden Organisationseinheiten aus den Fachprozessen darzustellen und die Benutzerrollen kurz zu beschreiben siehe Abbildung 6 20 arenannahme Mitarbeiter arenannahme Abbildung 6 20 Organisatorische Zuordnung der Benutzerrolle Mitarbeiter Warenannahme Mitarbeiter Warenannahme Beschreibung Definition Die Benutzerrolle Mitarbeiter Warenannahme hat die Berechtigung im System vorhandene Bestellungen zu bearbeiten um die Bestelldaten mit den Daten die sich aus Wareneing ngen ergeben abzugleichen Die Rechte einer Benutzerrolle lassen sich bei korrekter Modellierung der Systemabl ufe direkt in Form einer Matrix aus der Oracle BPA Suite generieren indem die Beziehungen der einzelnen Rollen Objekte vom Typ Personentyp zu den einzelnen Funktionen aus den Systemabl ufen ausgegeben werden siehe Abbildung 6 21 Benutrerallen Funktionen Co Mitarbeiter WWarenannahme J Artikel als Teillieferung markieren k E LJ Artikelmenge als falsch markieren ur DJ Bestellung ausw hlen IR C
85. Bestelldatum Bemerkung Material offen 64321 123456 Musterfinn a 200 00 EUR 01 04 2009 bestellung amp 148 Abbildung 6 16 Maske Bestellung suchen Bestellung 6 5 Erstellung eines Fachkonzepts mit der Oracle BPA Suite Bestellung siehe Abbildung 6 17 Beschreibung Definition Auf dieser Maske wird eine bestimmte Bestellung angezeigt Das einzige Feld das der Benutzer verandern kann ist die gelieferte Menge zu jeder Artikelposition der Bestellung Dabei wird dieses Feld vor der Bestellungs bearbeitung mit der bestellten Menge gef llt die auch in der Spalte Be stellmenge angezeigt wird Der Benutzer muss also nur nderungen vor nehmen sofern es bei einem Artikel eine Abweichung zwischen bestellter und tats chlich gelieferter Menge gibt Dabei erlaubt das System nur den Fall Liefermenge lt Bestellmenge Wird eine Liefermenge gt Bestellmenge eingegeben ignoriert das System die Eingabe und f llt das Feld wieder mit dem vorher gespeicherten Wert vor der ersten Bearbeitung also die Bestellmenge Gibt der Benutzer eine Liefermenge lt Bestellmenge ein so ffnet sich automatisch eine neue Maske in der der Grund f r die Abweichung angegeben werden muss Dieser Grund wird f r die Artikel position gespeichert Uber das Feld Bemerkung kann der Benutzer im Freitext eine Bemerkung zur Bestellung erfassen Nach Beendigung der Bearbeitung kann der Benutzer seine Anderungen Uber die Schaltflache nderungen speiche
86. Christian Schm lling ist Berater und Trainer 1m Bereich SOA Er arbeitet akt v in IT Projek ten und verf gt dadurch ber eine hohe fachliche und technische Kom petenz n der Analyse Konzeption und Implementierung von service orientierten Architekturen und Individualsoftware Christian Schm lling hat das Kapitel 7 verfasst Daniel Somssich ist Berater bei der OPITZ CONSULTING GmbH Er verf gt ber mehr j hr ge Projekterfahrung in den Bereichen Gesch ftsprozessmanage ment und Business IT Alignment n deren Rahmen er Fachkonzepte f r individuelle IT Systeme nach modellbasierten Ans tzen entwirft Daniel Somssich hat das Kapitel 6 verfasst Xl 1 1 1 Einleitung Warum Modellierung Unsere Welt ist komplex Sie zu verstehen erfordert neben dem Vorhandensein eigenen Wissens auch die Abstimmung individueller Sichten der Wahrheit zwischen Menschen Zur sicheren Kommunikation dar ber ben tigen wir eine gemeinsame Grundlage Jeder von uns hat individuelle Vorstellungen von der Real t t Gelegentlich decken sich diese nicht mit den Meinungen anderer Welche individuelle Wahrheit richtig ist l sst sich nicht so einfach bestimmen Wir m chten an dieser Stelle keine philosophische Diskussion ber Wahrheit beginnen doch liefert deren Definition einen Hinweis darauf warum wir modellieren Unter dem Begriff Wahrheit versteht man die bereinstimmung einer Erkenntnis mit dem ihr zugrunde liegenden Gegen
87. Dashboard meist in einer visuell ansprechenden Form dargestellt Prozesskennzahlen Prozesskennzahlen dienen im Wesentlichen dazu die Effektivit t und Effizienz der opera tiven Geschaftsprozesse zu messen Hieraus lassen sich die Auswirkungen auf das wirt schaftliche Ergebnis ablesen Dar ber hinaus k nnen Messgr en der Prozessausf hrung auch zur Unterst tzung von F hrungsentscheidungen und zur kontinuierlichen Prozessver besserung herangezogen werden Nach Kaplan und Norton Kapl97 sollten prozessorien tierte Kennzahlen m glichst direkt mit bergeordneten strategischen Unternehmenszielen in Verbindung stehen Tabelle 9 3 listet die grundlegenden Prozesskennzahlen Schm03 S 153 ff f r die Bewertung eines Prozesses sowie deren fachliche Bedeutung auf Tabelle 9 3 Problemkreise und deren Kennzahltypen Kennzahltypisierung Problemkreis Fragestellung Kundenzufriedenheit Wie zufrieden sind die externen und oder internen Kunden mit dem Ergebnis des Prozesses Die von den Kunden geforderte Leistung bedingt die Termintreue Quali t t und Effizienz der Prozesse ber direkte oder auch indirekte Messun gen wird die Zufriedenheit gemessen und an den Prozessen berpr ft Prozessqualit t Wie effizient werden die Kundenanforderungen und erwartungen erf llt Die Messung der Prozessqualitat erfolgt durch die Ermittlung der Fehler raten und der hierdurch verursachten Mehrkosten Prozesskosten Welche Kosten bzw Ressour
88. Der Business Service be schreibt die fachliche Leistung die er erbringt und die zur Bearbeitung des fachlichen Pro zessschrittes erforderlich ist Hinter der symbolischen Darstellung des fachlichen Servi ces liegt in dem hier beschriebenen Vorgehen wieder ein Prozess der beschreibt wie die Leistung des Service konkret erbracht wird Er entspricht damit dem fachlichen IT Modell vgl Abbildung 8 3 Ein fachlicher Service stellt in der Regel mehrere zusammengeh rige Leistungen zur Verf gung Beispiel aus dem Anwendungsfall dieses Buches Der Service Wareneingang bietet die Operationen Lieferungsposition berpr fen und Warenein gang verbuchen an 8 3 Modellierung SOA geeigneter Prozessmodelle Ein sauberes fachliches SOA Modell sollte au erdem von den IT Systemen des Unter nehmens welche gewiss einen Teil der im Prozess ben tigten Funktionalit ten beinhalten abstrahieren Daher werden im fachlichen Detailmodell keine Anwendungssysteme model liert Das Modell abstrahiert an dieser Stelle bewusst im Sinne einer serviceorientierten Kapselung der Funktionalit t von den eingesetzten IT Systemen Hinweis Die in den IT Systemen implementierten Funktionalit ten werden sp ter aus dem implementierten fachlichen IT Modell ber technische Serviceschnittstellen aufgerufen Messpunkte Optional k nnen im fachlichen Detailmodell und sp ter auch im fachlichen IT Modell noch wesentliche Messpunkte als Basis f r die Be
89. Detaillierung in unter schiedlichen Modellbereichen zuordnen F r das integrierte Modell muss genau festgelegt werden bei welcher inhaltlichen Detaillierung die Artefakttypen in wel chen Modellbereich geh ren 2 3 3 Semantische Zuordnung verschiedener Inhaltstypen Grunds tzlich k nnen die Inhalte der EA BPM und fachlichen SOA Modellbereiche un terteilt werden E Fachliche Inhalte umfassen alle ausschlie lich betriebswirtschaftlichen Inhalte des Gesamtmodells Dies sind neben einer Beschreibung der fachlichen Prozesse h ufig In formationen ber die am Prozessablauf beteiligten Organisationseinheiten und Ge sch ftsobjekte Inhalte welche zus tzliche Informationen f r besondere betriebswirt schaftliche Fragestellungen enthalten zum Beispiel Compliance und Gesch ftsstrate gien werden ebenfalls hier zugeordnet Wesentliches Kriterium zur Identifizierung fach licher Inhalte ist deren Neutralit t gegen ber jeglichem informations technologischen Bezug Stellen Sie sich zur Identifizierung fachlicher Inhalte die Frage ob diese voll st ndig IT neutral beschrieben sind Beispielweise m ssen Prozessbeschreibungen die ses Inhaltstyps immer so formuliert sein dass ihnen nicht entnommen werden kann ob der Prozess manuell mit Papier und Bleistift oder mit einem Computer bearbeitet wird Fachliche IT Inhalte verbinden IT neutrale Inhalte mit technischen Beschreibungen von IT Systemen Man kann sie sich als eine Art Klebstoff zwis
90. Ein gangsobjektes zu einem Ausgangsobjekt gekennzeichnet Ausgangspunkt der Ermittlung gleichartig detaillierter Inhalte st immer der den betrachte ten Prozessen oder Aktivit ten bergeordnete Prozess 5 2 Aufbau des Grundmodells Die ersten drei Ebenen bilden die Ubersicht der dynamischen Modellierung Diese sind die 1 Unternehmensinstanz Ebene 2 Kernprozessinstanz Ebene 3 Hauptprozessinstanz Ebene Die ersten drei Ebenen werden erstellt um dem Nutzer eine einfache Navigation innerhalb des Modells zu erm glichen Ausgangspunkt ist die zentrale Unternehmensinstanz viel fach auch Prozesslandkarte genannt Auf ihr sind die Kernprozesse des Unternehmens modelliert und s mtliche Verzweigungen in detailliertere Modellierungsstrukturen neh men auf der Prozesslandkarte hren Anfang Daran schlie t sich die Kernprozessinstanz Ebene an Sie dient zur Detaillierung der ermit telten Kernprozesse der Prozesslandkarte Abschlie end z hlt man noch die Hauptprozess Ebene zur bersicht der dynamischen Modellierung Letztere dient zur Detaillierung der Hauptprozesse Darauf bas erend k nnen Richtgr en zur Strukturierung der dynamischen Modellstruktur angegeben werden E 1 Instanzgranularit t Unternehmensinstanz Prozesslandkarte 6 12 Kernprozesse E 2 Instanzgranularit t Kernprozessinstanz 5 6 Hauptprozesse E 3 Instanzgranularit t Hauptprozessinstanz 3 5 Unterprozesse horizontale Dekomposition Kernprozesse H
91. El dirk STAHLER ingo MEIER rolf SCHEUCH ORACLE BPA christian SCHMULLING SUITE 119 daniel SOMSSICH ARIS METHODE a ENTERPRISE ARCHITECTURE BPM UND SOA FUR BUSINESS ANALYSTEN HANSER St hler Meier Scheuch Schm lling Somssich u Enterprise Architecture BPM und SOA f r Business Analysten Bleiben Sie einfach auf dem Laufenden www hanser de newsletter Sofort anmelden und Monat f r Monat die neuesten Infos und Updates erhalten Dirk Stahler Ingo Meier Rolf Scheuch Christian Schmulling Daniel Somssich Enterprise Architecture BPM und SOA fur Business Analysten Leitfaden fur die Praxis HANSER Dirk St hler Gummersbach dirk staehler opitz consulting com Ingo Meier K ln ingo meier opitz consulting com Rolf Scheuch Bergisch Gladbach rolf scheuch opitz consulting com Christian Schm lling Overath christian schmuelling opitz consulting com Daniel Somssich K ln daniel somssich opitz consulting com Alle in diesem Buch enthaltenen Informationen Verfahren und Darstellungen wurden nach bestem Wissen zusammengestellt und mit Sorgfalt getestet Dennoch sind Fehler nicht ganz auszuschlie en Aus diesem Grund sind die im vorliegenden Buch enthaltenen Informationen mit keiner Verpflich tung oder Garantie irgendeiner Art verbunden Autoren und Verlag bernehmen infolgedessen keine juristische Verantwortung und werden keine daraus folgende oder sonstige Haftung bernehmen die auf irgendeine Art a
92. Erkenntnisse beim Lesen des Buches und freuen uns ber jede Form von R ckmeldungen Schreiben S e uns Ihre Ideen und Anmerkungen Gummersbach im August 2009 Dirk St hler dirk staehler opitz consulting com Die Autoren Die Autoren Dirk Stahler ist Direktor f r Strategie und Innovation bei dem Gummersbacher Bera tungshaus OPITZ CONSULTING GmbH Im Rahmen seiner Tatigkeit verantwortet er die strategische Entwicklung des Unternehmens in den Bereichen Enterprise Architecture BPM und fachliche SOA Er ist be kannt durch diverse Ver ffentlichungen und arbeitet in Projekten bei nationalen und internationalen Konzernen Dirk St hler hat die Kapitel 1 2 3 4 und 5 verfasst Ingo Meier ber t rund um das Thema Prozessmanagement Ein besonderer Schwer punkt liegt dabei auf der Prozessautomatisierung n der IT und der Ver bindung fachlicher Prozesse mit den methodischen Ans tzen service orientierter Architekturen Er verf gt ber mehrj hrige Praxiserfahrung in Prozessmanagement und SOA Projekten Ingo Meier hat das Kapitel 8 verfasst Rolf Scheuch ist einer der Gr nder und gesch ftsf hrender Gesellschafter der Opitz Consulting GmbH Er besch ftigt sich schwerpunktm ig mit den The men IT Strategiemanagement Prozess Controlling und steuerung Er hat langj hr ge Erfahrung in der Abwicklung komplexer IT Projekte und ber t IT F hrungskr fte namhafter deutscher Konzerne Rolf Scheuch hat das Kapitel 9 verfasst
93. Fachprozessen lassen sich die Anforderungen die sich daraus an die IT ergeben strukturiert und in einem Gesamtkontext erheben und die Wahrscheinlichkeit dass wichtige Anforderungen vergessen oder nicht ausreichend verstanden werden wird minimiert Auch in Bezug auf die be und verarbeiteten Informa tionen bringt die Orientierung an einem durchg ngigen Prozess Vorteile mit sich Anstatt nur die Daten zu beschreiben die ein System zur Verarbeitung ben tigt ist es sinnvoll nachzuvollziehen wo diese Daten herkommen Wenn Daten bereits in einem anderen Sys tem vorliegen ist die Realisierung einer Systemschnittstelle eine bessere Variante als eine Eingabemaske zur manuellen Erfassung die neben dem Risiko von Eingabefehlern auch dazu f hrt dass die gleichen Informationen in unterschiedlichen Systemen vorgehalten werden wodurch sich Inkonsistenzen im Datenbestand ergeben k nnen Es ist unbestritten dass bei einer prozessorientierten modellbasierten Vorgehensweise zur Erstellung von Fachkonzepten stets auch Informationen aufgenommen werden die f r die Konzeption eines IT Systems weniger relevant s nd Die Praxis zeigt jedoch dass der Mo dellierungsaufwand der zur vollst ndigen Identifikation der fachlichen Anforderungen betrieben wird n keinem Verh ltnis zum Aufwand steht der notwendig wird wenn An forderungen vergessen bzw missverstanden werden und aus diesem Grund nach der Sys temeinf hrung Anpassungen durchgef hrt werden m s
94. Gestaltung Ihres Modells herangezogen werden Die Grunds tze beschreiben berge ordnete Ziele deren Erreichung die Informationen aus dem Modell unterst tzen sollen Tabelle 3 1 zeigt eine Auswahl m glicher Grunds tze die mit Hilfe der Sichten verfolgt werden k nnen Die Tabelle erhebt keinen Anspruch auf Vollst ndigkeit Sie soll Ihnen vielmehr als Startpunkt f r Ihre eigenen berlegungen dienen Alle Grunds tze m ssen neutral formuliert sein und keine konkreten methodischen technologischen und organisa torischen Auspr gungen enthalten Zum Beispiel w re der Grundsatz Anwendungsent wicklung grunds tzlich mit JAVA nicht zul ssig Neutral formuliert m sste es hei en Die Anwendungsentwicklung soll technologische Unternehmensstandards einhalten Stellen Sie Ihrer Organisation die Frage welche Herausforderungen sie gerade hat und bei welchen aktuellen Themen mehr Transparenz ben tigt wird Tabelle 3 1 Beispiele von Modellierungsgrunds tzen Modell Sicht Grunds tze o Gesch fts Architektur Sicherstellung eines kontinuierlichen Gesch ftsbetriebs Erf llung und Einhaltung gesetzlicher Vorschriften Klare Zuweisung fachlicher Verantwortlichkeiten Klare Zuweisung technischer Verantwortlichkeiten bergreifende Nutzung von Anwendungssoftware in verschiedenen Unternehmensbereichen Anwendungs Architektur Sicherstellung technologischer Unabh ngigkeit Durchsetzung von Standardapplikationen Gew hrleistung einer
95. Hilfestellung zum Ab gleich der Prozesssprachen bieten die Workflow Patterns von van der Aalst et al vgl Kasten und Aals00 Im Vorfeld der Modellierung vereinbarte Modellierungskonventio nen helfen die Prozesse so zu gestalten dass eine bertragung in die IT m glich ist Datenfluss In Outputs Auch auf technischer Ebene kommen Datenfl sse zum Tragen als In Outputs sowohl f r den gesamten IT Prozess wie auch beim Aufruf der technischen Services aus dem IT Prozess heraus Das Modell soll hier eine m glichst gute Vorlage f r die technischen Da tenstrukturen liefern Bei Web Service basierten Implementierungen wie BPEL werden die Datenobjekte im XML Format abgebildet und basieren auf XML Schema Definitions XSD Ideal ist der Einsatz eines unternehmens oder projektweit g ltigen Datenmodells Business Object Model und ggf die Anlehnung an branchenspezifische standardisierte Datenmodelle Organisation Wird m fachlichen IT Modell zwischen automatisch ausgef hrten und manuellen Prozess schritten unterschieden empfiehlt sich die organisatorische Abbildung auf der Bas s von Rollen Den manuellen T tigkeiten werden 1m fachlichen IT Modell die ausf hrenden Rol len zugewiesen Diese Information kann vom Entwickler bei der Umsetzung der Human Workflow L sung genutzt werden Workflow Patterns Control Flow Patterns Entwickelt und ver ffentlicht von Prof v d Aalst et al Jedes Pattern beschreibt einen Kontrol
96. Informationen ber die Aufgabe die dieser Schritt erf llt E Globale Objekte und Gesch ftsobjekte Gesch ftsobjekte werden genutzt um Objekte zu beschreiben und um sie als Eingabe und Ausgabe von Prozessen und Funktionen nutzen zu k nnen E Gruppen Rollen Stellen oder Personen In einem organisatorischen Zweig eines Prozessmodells sind Prozesse oder einzelne Funktionen mit der Unternehmensorganisation verbunden E Methoden und Konventionen Ein Prozessmodell wurde unter einer bestimmten Methode mit Konventionen erstellt Herausforderungen Bestehende Prozessmodelle konzentrieren sich pr m r auf Prozesse Da wundert es nicht dass einige Herausforderungen berwunden werden m ssen wenn ber Prozessmodelle Services identifiziert werden sollen Eine Herausforderung ist der Detaillierungsgrad Das Prozessmodell wurde in verschiedene Hierarchieebenen unterteilt Je tiefer die Ebene um so detaillierter sind die dar n enthaltenen Informationen Aus Sicht der Serviceidentifikati on wird man sich h ufig genau eine Zwischenebene w nschen da die Informationen auf der h heren Ebene zu grob und die auf der tieferen Ebene zu fein sind Eine weitere Her ausforderung ist die Strukturierung in Prozesse Ein logischer Ablauf wurde als Prozess zusammengefasst Services sollen jedoch prozess bergreifend verwendet werden Ein Identifikationsweg der lediglich einzelne Prozesse betrachtet ist nicht empfehlenswert Diese Herausforderungen existi
97. M Quirchmayr G Multidimensional Business Process Analysis with the Process Warehouse In W Abramowicz and J Zurada Eds Knowledge Discovery for Business Information Systems Kluwer Academic Publish ers 2000 Mathas C SOA intern Praxiswissen zu serviceorientierten IT Systemen 1 Auflage Hanser M nchen 2007 Melenovsky M Sinur J Hill J McCoy D Business Process Management Pre paring for the Process Managed Organization 2005 261 Literatur Mott08 Performing Business Processes Knowledge Base Precedings University of Pavia Gianmario Motta Giovanni Pignatelli Manuela Florio 2008 Oasi06 OASIS Reference Model for Service Oriented Architecture 1 0 2006 Orac06 Oracle Corporation Oracle Business Activity Monitoring User s Guide 10g 10 1 3 1 October 2006 Peis06 Peisl R Gesch ftsprozessmanagement mit IBM WebSphere Publisher IBM Deutschland GmbH April 2005 Sche02 August Wilhelm Scheer Wolfram Jost ARIS in der Praxis Springer 2002 Sche04 Scheer A W und W Jost Hrsg ARIS in der Praxis Gestaltung Implementie rung und Optimierung von Gesch ftsprozessen Springer Saarbr cken 4 Auflage 2002 Sche05 Scheer A W Corporate Performance Management Aris in der Praxis Springer 2005 Schi09 Schmiedel D Vorgehensmodell f r Closed loop BPM mit Oracle Fusion Middle ware Masterarbeit an der HTWK Leipzig 2009 Schm03 Schmelzer H Sesselman W Gesch ft
98. ME 17 7 1 ur 14 A 12 7 je 17 INFRASTRUKTUR p Abbildung 8 1 Prozessautomatisierung vom Fachprozess zum prozessbasierten Anwendungs system Diesen Ansatz veranschaulicht Abbildung 8 1 grafisch Auf der obersten der drei darge stellten Ebenen werden fachliche Prozesse im Rahmen eines Business Process Manage ments analysiert modelliert gestaltet und ggf optimiert Die Zielsetzung besteht nun dar in diese Prozesse auf die mittlere Ebene der Anwendungssysteme zu bertragen und somit die optimale IT technische Unterst tzung der wertsch pfenden Abl ufe einer Unterneh mung zu gew hrleisten Im Sinne der Serviceorientierung bestehen die Anwendungssys teme aus Komponenten die als Bausteine zu Prozessen zusammengesetzt werden Jede Komponente erf llt eine definierte fachliche Funktionalit t und hat dar ber hinaus eine entsprechende Implementierung in der IT Hier kommen Begrifflichkeiten wie Prozessor chestrierung das Zusammensetzen einzelner fachlicher Dienste durch dar ber laufende 193 8 Der prozessgetriebene SOA Ansatz 194 Prozesse zu sinnvollen wertsch pfenden Abl ufen Workflow oder Integration in die Diskussion Auf der dritten und untersten Ebene ist die erforderliche Infrastruktur abgebil det die mit Application Server Datenbanken und anderen hnlichen Komponenten das R ckgrat dieser Anwendungslandschaft bildet Neben dem Weg top down von Prozes sen zu Anwendungssystemen kommt der R ckkop
99. Maskenfl sse jedoch auch notwendige R ckspr nge und Abbr che bei der Sys temnutzung abbilden Insbesondere in F llen in denen ein Maskenlayout modelliert worden ist und den Masken somit auch einzelne Schaltfl chen zugewiesen worden sind lassen sich die m glichen Maskenfl sse in einem Modell zeigen in dem alle Masken dargestellt und durch die jewei ligen Schaltfl chen verbunden werden Auf diese Weise lassen sich auch fehlende Schalt fl chen m Maskenlayout identifizieren Maskenfl sse kann man auch ohne Schaltfl chen modellieren indem man Masken direkt oder ber logische Regeln miteinander verbindet siehe Abbildung 6 8 133 6 Modellgest tzte fachliche Konzeption individueller IT Systeme 134 Maske 1 Maske 1 Zur ck OK Abbrechen L 4 Maske 2 Maske 3 Maske 2 Maske 3 Abbildung 6 8 Maskenfl sse ein Beispiel 6 3 4 4 Systemschnittstellen Die Beschreibung der Schnittstellen die ein neues System mit anderen Systemen verbin det ist ein wichtiger Teil eines Fachkonzepts Ob diese Schnittstellen modelliert werden sollten ist dabei abh ngig von den Rahmenbedingungen des Projekts Im Rahmen einer Enterprise Architecture sollten alle vorhandenen Systeme inkl ihrer Beziehungen zueinan der bereits Teil des Unternehmensmodells sein und auch das neue System wi
100. Methode an und speichern Sie dort alle Auswertungen zur Methode der Oracle BPA Suite Achten Sie darauf innerhalb des Dateina mens bei jeder Analyse einen Zeitstempel anzulegen Auf diese Wiese k nnen Sie nderungen der Methode jederzeit nachvollziehen Der Zeitstempel der Ex cel Datei ist daf r nicht ausreichend da er sich bei jedem ffnen der Datei leicht durch unbeabsichtigtes Speichern ver ndern kann Durch Dr cken von Fertig stellen starten Sie den Report W hrend des Reportablaufs werden Sie aufgefordert die auszugebenden Methodeninhalte genauer zu spezifizieren Sie k nnen die Ausgaben auf die Modelltypen Diagrammtypen Modellattribute Diagramm attribute Symboltypen Objektattribute Hinterlegungen Beziehungstypen und Bezie hungsattribute beschr nken Aktivieren Sie f r die Excel Methodenkonfigurationsdatei alle Optionen Abbildung 4 5 Sollte die Ausgabe der Gesamtmethode bei Ihnen mit einem Fehler abbrechen so deaktivieren Sie nacheinander die Optionen Beziehungsattribute und Beziehungstypen Objektattribute und zuletzt Modellattribute Gelegentlich kommt es aufgrund des gro en Methodenumfangs bei der Reportausf hrung zu einer Fehlermeldung Durch das schrittweise Deaktivieren der auszugebenden Methodeninhalte schr nken Sie den Umfang der Auswertung zunehmend ein bis S e sicher ein Ergebnis erhalten Je nach Rechenleistung Ihres Computers kann die Auswertung einige Zeit in Anspruch nehmen 4 4 Analyse der Oracle
101. O Liefermenge eingeben I Abbildung 6 21 Ss ss chor Rechtematrix fur die Benutzerrolle C Teillieferung identifizieren ur Mitarbeiter Warenannahme Wie bereits bei der Konzeption notwendiger Masken muss auch beim Rollenkonzept die Administration des Systems mit ber cksichtigt werden Verf gt ein System ber ein Rol lenkonzept so muss bspw eine Administratorrolle definiert werden die Benutzer einrich ten und diesen die entsprechende Rolle zuordnen kann Auch die Zuordnung bestimmter Rechte zu einer Rolle ist eine notwendige Administrationsfunktionalitat die auf einer ent sprechenden Maske ausgef hrt werden muss 151 7 1 7 Identifizierung und Modellierung fachlicher Services f r SOA Zentrale Fragen dieses Kapitels 7 2 E Was ist ein Service E Welchen Nutzen generiert die Verwendung von Services E Wie werden Services im Unternehmen nutzbar gemacht E Wie werden Services identifiziert und modelliert Services und SOA SOA hat den Sprung vom Hype in die Realit t geschafft Immer mehr Unternehmen haben damit begonnen SOA zu etablieren Insbesondere prozessorientierte Unternehmen erken nen dass sie ber eine gute Grundlage f r SOA verf gen und versprechen sich Vorteile von der Einf hrung einer SOA wie zum Beispiel flexiblere Gesch ftsprozesse oder eine erh hte Innovationsf higkeit leichter umsetzen zu k nnen Ein Grundgedanke von SOA ist es ausgehend von fachlichen Anforderungen
102. Programmabl ufe Maskendesigns und Datenmodelle Um den zugegebenerma en etwas hochtrabend ausgedr ckten bergang zwischen den Welten im Rahmen der Konzeption und Entwicklung eines IT Systems sau ber und flie end zu gew hrleisten wird ein ganzheitlicher Ansatz zu einer gesch ftspro zessorientierten integrierten Systementwicklung von der Erfassung der fachlichen Abl ufe ber die Detaillierung und Erweiterung dieser um IT relevante Inhalte bis hin zur berga be an entsprechende Realisierungstools ben tigt Die Grundlage stellt dabei die Erfassung und Dokumentation der fachlichen Prozesse dar Nur wenn die fachlichen Abl ufe in der Fachabteilung vollst ndig und korrekt beschrieben werden l sst sich auf Bas s dieser Be schreibung ein System konzipieren das diese Abl ufe optimal unterst tzen kann Wichtig ist dabei zun chst wiederum die Unterscheidung zwischen der fachlichen und der techni schen Sicht In der fachlichen Sicht werden die Fachprozesse unabh ngig von technischer Unterst tzung dargestellt Es ist sicherlich einleuchtend dass ein korrekt dokumentierter fachlicher Ablauf s ch nicht dadurch ver ndern sollte dass ein IT System ausgetauscht wird In der technischen Sicht wird dagegen dargestellt was 1m IT System passiert um die fachlichen Aufgaben zu unterst tzen Nachdem die beiden Sichten also gegeneinander ab gegrenzt sind besteht die Herausforderung darin diese beiden Sichten zu verbinden und damit den Engine
103. Prozess Benchmark Tabelle 9 16 Benutzte Methodenobjekte der Oracle BPA Suite Modellname Prozess Benchmark Diagrammtyp Anwendungssystemdiagramm Symbol Typ Anwendung Typ Modul Lieferung Bestel 9 7 Modellierung des Prozess Controlling mit der Oracle BPA Suite 9 7 3 4 Modellierung von ETL Systemen inklusive Sonden Das IT System f r die Aufbereitung der Rohdaten aus den unterschiedlichen Prozessin stanzen stellt die eigentliche Herausforderung bei der Implementierung und Wartung dar In Abschnitt 9 4 1 haben wir die Hintergr nde beschrieben Diese spezifischen Sonden der unterschiedlichen Anwendungssysteme bermitteln die Daten an ein zentrales System f r die Datenintegration Stichwort Enterprise Service Bus Hier erfolgen die notwendigen Transformationen und die Aufbereitung auf das ben tigte Schnittstellenformat welches zum Aufbau eines Process Warehouse ben tigt wird Im Wesentlichen wird ein Schl ssel gebildet der die Prozessinstanz eindeutig beschreibt und sp ter f r die Zuordnung der einzelnen Prozessinformationen dient Das System ermit telt ferner den Vorg nger dieser Prozessinstanz und speichert diese Information ab damit eine Serialisierung der Prozessschritte m glich ist In unserem speziellen Fall brauchen wir einen Datensatz f r jeden zu messenden Event hier eindeutiger Start und Endezeitpunkt im Prozess der Wareneingangskontrolle WEK Hieraus k nnen wir die Kennzahl PDauer WEK Proz
104. Prozess verwendet der Prozess nimmt die Rolle des Konsumenten ein Abbildung 7 2 zeigt eine grobe Skizze des Prozessmodell Aufbaus Auf jeder Ebene des Prozessmodells konnen Services modelliert werden hnlich der Prozessgranularit t auf den einzelnen Ebenen verh lt es sich mit der Servi cegranularitat Auf Ebene der Unternehmensinstanz k nnen die Kerngesch ftsprozesse mit Kerngesch fts Services verbunden sein Die Prozesse der obersten Ebenen haben eine eher strukturierende Aufgabe hnlich verh lt es sich mit den Services auf dieser Ebene Die Menge der Services in einem Unternehmen ist ohne Struktur nicht handhabbar Aus diesem Grunde werden auch Services strukturiert Im Modell ist ein Service auf Ebene der Unternehmensinstanz der zusammenfassende Service f r die Services der tieferen Ebenen Auf den oberen Ebenen des Prozessmodells sind ausschlie lich fachliche Services zu fin den Die Ebene der bersichtsmodelle ist f r eine Realisierung in der IT zu grob Auf den darunter liegenden Ebenen fachliche Detailmodelle fachliche IT Modelle und ausf hrba re IT Modelle sind in der IT realisierte Services zu finden Die Ebene der fachlichen De tailmodelle stellt in diesem Zusammenhang eine Besonderheit dar Services auf dieser E bene sind in der Regel nur dann in der IT realisiert wenn es sich um einen zusammenge setzten Service handelt Zusammengesetzte Services werden im folgenden Abschnitt be handelt Auf Ebene der fachlichen IT
105. Reserven ueberpruefen A Automatisierte Aufgabe Abbildung 8 15 Fachliches IT Modell f r Oracle BPEL in BPMN Notation in der Oracle BPA Suite 217 Eine als Manuelle Aufgabe modellierte Funktion wird in der Oracle BPEL Implemen tierung als Aufgabe abgebildet die in die Aufgabenliste Postkorb der definierten Rolle eingestellt wird Eine Automatisierte Aufgabe setzt BPEL als Aufruf eines Web Service um Hierzu kann bereits m fachlichen IT Modell die Web Service Schnittstelle WSDL mit der Funktion verkn pft werden Dar ber hinaus stehen weitere Implementierungsm g lichkeiten f r Funktionen zur Verf gung die im Rahmen dieses fachlich orientierten Vor gehens nicht n her betrachtet werden Weitere Informationen dazu enth lt die Hilfe der Oracle BPA Suite Technischer Kontrollfluss Die Modellierung des technischen Kontrollflusses entspricht der des pragmatischen fachlichen IT Modells vgl Abschnitt 8 4 2 1 Datenfluss In Outputs Die Modellierung der Datenfl sse entspricht der des pragmatischen fachlichen IT Mo dells vgl Abschnitt 8 4 2 1 Organisation Die organisatorischen Verantwortlichkeiten werden wie im pragmatischen Modell in Form von BPMN Pools und Lanes dargestellt Zusatzlich wird durch die zuvor erlauterte Symbolik der Funktionen in der Oracle BPA Suite ausgedr ckt ob es sich um Manuelle Aufgaben oder automatisierte Service Aufrufe ha
106. S e k nnen sich vorstellen dass je nach betrachtetem System die instanzbasierte Modellierung zu einer gro en Anzahl modellierter Artefakte f hren kann Dies ist unter anderem der Fall wenn Sie beispiels weise versuchen lokale Client Installationen von Anwendungssystemen auf Instanzbas s zu modellieren W gen Sie aus diesem Grund immer kritisch ab ob das angestrebte Mo dellierungsziel diese Detaillierung erfordert 2 Je nachdem mit wem Sie in einem Unternehmen sprechen werden zu den Anwendungssystemen auch Softwareprodukte gerechnet die nur indirekt an der betrieblichen Wertsch pfung beteiligt sind Dies sind zum Beispiel Datenbanken und Middleware die zwar zum Betrieb der mit wertsch pfenden Pro zessen des Unternehmens verbundenen Anwendungssysteme erforderlich sind aber keine direkte Ver bindung zu den fachlichen wertsch pfenden Prozessen haben Diese ordnen wir dem Bereich der Inf rastrukturbibliothek zu 107 5 Das Grundmodell Dar ber hinaus k nnen Sie die Modellierung um Inhalte zu Modulen Komponenten der Anwendungssysteme und Masken erweitern Beide Erweiterungen k nnen ebenfalls typi s ert oder als Instanz erfolgen Tabelle 5 3 Inhalt und Abgrenzung der Anwendungssystembibliothek Benennung der Name des Anwendungssystems im Unternehmen Anwendungssystem bibliothek Innerhalb der Anwendungssystembibliothek werden die relevanten Anwendungssysteme des betrachteten Unternehmens Unternehmensbereichs beschrieb
107. Schritt muss von einem Menschen manuell durchgef hrt werden Dennoch besitzt dieser Service eine definierte Schnittstelle mit Eingangs und Ausgangs nachrichten damit ihn der Konsument nutzen kann Ein Service dieser Art ist h ufig die erste Evolutionsstufe bevor er weiter automatisiert wird 7 2 Services und SOA Beispiel Die Spesenabrechnung wurde bisher in jeder Niederlassung direkt durchgefuhrt Jetzt wird der Service Spesenabrechnung von der Zentrale angeboten In der Schnittstellenbeschrei bung ist beschrieben dass ein Spesenformular an Frau Muller geschickt werden muss und diese eine Genehmigung oder Ablehnung zuruckschickt Der von Frau Muller durchgefuhrte manuelle Prozess bleibt fur die Konsumenten verborgen Ein teilautomatisierter Prozess nutzt IT bereits zur Erbringung der Leistung doch wird entweder nicht jeder Prozessschritt durch einen in der IT realisierten Service unterst tzt der Prozess ist nicht automatisiert ablauff hig oder es sind manuelle Entscheidungen im Prozessverlauf notwendig H ufig findet man unter den teilautomatisierten Prozessen fol gende evolution re Reihenfolge 1 Einzelne Schritte sind durch technische Services realisiert 2 Alle Schritte sind durch technische Services realisiert wenn keine manuellen Ent scheidungen n tig sind 3 Zus tzlich zu 2 Alle manuellen Entscheidungen werden durch Workflowsysteme reali siert Die Ablaufsteuerung ist in einem IT System realisie
108. Schritt ordnen Sie die statischen Inhalte den passenden Aktivit ten des Prozesses zu Wenn Sie sich diesen Ablauf ansehen und bereits Erfahrung mit der Modellierung von Prozessen haben werden Sie schnell erkennen dass dieses Vorgehen n der Realit t nur eingeschr nkt funktioniert Vielmehr ist es so dass alle drei genannten Schritte iterativ w hrend der Modellierung durchgef hrt werden Es ist nicht m glich alle statischen Ob jekte die an einem Prozess beteiligt sind vor der Modellierung der Aktivit ten und deren 2 3 Grundsatzliche Gliederung eines integrierten Modells zeitlichem Zusammenhang final zu kennen Dennoch sollten Sie versuchen sich dem oben genannten Ablauf so weit wie m glich anzun hern Er hilft Ihnen dabei Ihre Modellierung an einem roten Faden zu orientieren Durch die Trennung innerhalb Ihres Modells erreichen Sie eine Strukturierung mit der Sie auch bei iterativer Modellierung leichter den berblick behalten Doch damit nicht genug die Trennung der Bereiche hilft nicht nur bei der Erstellung des Modells sondern noch viel mehr bei der Weiterverwendung der Modellinhalte in sp teren Phasen Auswertungen und Analysen der Inhalte sind mit jedem Modellierungswerkzeug deutlich einfacher durch f hrbar wenn eine klare und eindeutige Trennung in statische und dynamische Inhalte vorliegt 2 3 5 Horizontale und vertikale Unterteilung Modelle egal ob fachlich oder technisch sind in der Regel hierarchisch strukt
109. Serviceanfrage lediglich auf einem anderen Weg In diesem Fall ber eine Worklist Das Serviceportfolio wird um die technischen Informationen angereichert 4 Der Service wird in der IT realisiert Die Schnittstelle nach au en kann beibehalten werden Jetzt wird jedoch kein Task in eine Worklist eingestellt sondern eine Anwen dung aufgerufen Es ist keine manuelle T tigkeit notwendig 5 Der Service wird erweitert und die neue Schnittstelle im Serviceportfolio hinterlegt 6 Der Service geht in den Ruhestand 7 3 1 Aufgaben des Serviceportfolios Als zentrale Sammelstelle f r alle Belange die sich um Services drehen hat das Service portfolio im Wesentlichen folgende Aufgaben E Informieren Unterst tzung bei servicebezogenen Entscheidungen E Unterst tzung in der Serviceerstellung Design Konzept Implementierung Unterst tzung in der Administration der Services Die verschiedenen Aufgabengebiete deuten schon darauf hin dass es verschiedene Grup pen im Unternehmen gibt die das Serviceportfolio benutzen Abbildung 7 6 k nnen die Gruppen entnommen werden Als Informationsquelle nutzen alle Gruppen aus Abbildung 7 6 das Serviceportfolio Der Manager nutzt das Serviceportfolio lediglich als Informationsquelle und f gt nur in Aus nahmef llen Informationen im Serviceportfolio ein Die anderen Gruppen nutzen das Port folio in den abgebildeten Phasen nicht nur lesend sondern auch schreibend Durch eine einheitliche Doku
110. Wareneingang vom Lieferanten auch den Lieferschein und die Warenbegleitpapiere Im ersten Schritt wird nun berpr ft ob die Informationen auf dem Lieferschein insbesondere die Artikelmengen mit dem tats chlich gelieferten Wareneingang bereinstimmen Sofern Differenzen zwi schen dem physischen Wareneingang und dem Lieferschein auftreten werden diese auf dem Lieferschein zur weiteren Bearbeitung vermerkt Dar ber hinaus w rd der Warenein gang mit der Bestellung abgeglichen Bei Abweichungen zwischen der Bestellung und der Lieferung wird eine Pr fung der einzelnen Lieferpositionen durchgef hrt Dieser Prozess ist in Abbildung 6 12 dargestellt Der erste Schritt wird manuell also ohne Systemunterst tzung durchgef hrt Dabei wird f r jeden abweichenden Artikel die Art der Abweichung zwischen Lieferung und Bestel lung gepr ft Drei verschiedene Abweichungen sind jeweils m gl ch E Die gelieferte Artikelmenge ist kleiner als die bestellte Menge E Die gelieferte Artikelmenge ist gr er als die bestellte Menge Der falsche Artikel ist geliefert worden 140 6 5 Erstellung eines Fachkonzepts mit der Oracle BPA Suite Teilieferune omsctMaschineinterahtlen more lachlieferung initieren Ce A Auf weitere Artikel pr fen Ale Artikel gepr ft Bestellung aktualisieren A Abbildung 6 12 Lieferung Fachprozess Lieferungspositionen SH pr fen 141 6 Modellgest tzte fachliche Kon
111. Zeit Zeitpunkt Zeitdauer und Links Verweise individuell ohne Beschr nkung erstellen Attributsymbole Attributsymboltypen Attr butsymboltypen zeigen graphisch Werte von Attributen auf Diagrammen an Die Version 11g der Oracle BPA Suite verf gt im Standard ber 80 Attributsymboltypen die Sie individuell Attributen zuordnen k nnen Wir empfehlen die Nutzung dieser Funktionalit t nur in begr ndeten Ausnahmef llen obwohl durch ihren Einsatz keine gravierende Beeinflussung der methodischen Zusam menh nge entsteht Abbildung 4 1 zeigt die Zusammenh nge der Oracle BPA Suite Methode ohne Attribut symboltypen und deren Verwendung in einer Modellinstanz Modell Oracle BPA Suite Datenbank Oracle BPA Suite Methode Diagrammtypen Diagramm Instanz ist Teil eines Modells Symboltyp ist erlaubt in Diagrammtyp fee Symboltypen Symbole Instanz werden dargestellt auf Diagramm Instanz Symbol 1 Instanz Attributtyp wird Objekttyp kann dargestellt verwendet werden mit Symboltyp bei Diagrammtyp Attribute werden inhaltlich gef llt bei Diagramm Instanz Attribute werden Inhaltlich gef llt bei Symbol Instanz Objekttypen Attributtyp wird verwendet bei Objekttyp Attribut typen Kantentyp definiert Attributtyp Beziehung zwischen wird verwendet Symboltypen bei Kantentyp Kantentypen Abbildung 4 1 Bestandteile und Zusammenh nge der Oracle BPA Suite Methode Attribu
112. _ _ _ Operative Enterprise Systeme 3 Model 3 Workflow Pentan l BPM Systeme Datenbank li li i Staging Area i Real Time lj Abbildung 9 7 gor ING f Ex post Informationssysteme Process I Process Mining f r die Ermittlung der i __ Monitoring li _ Prozesskennzahlen Im Gegensatz dazu k nnen und m ssen die Kenndaten zur Termintreue und Prozesszeit Durchlaufzeit zeitnah ermittelt werden Diese Kennzahlen werden zur berwachung der laufenden Prozessinstanzen im Rahmen des Process Monitoring ben tigt Die Berechnung und Ablage der Kennzahl erfolgt zur Laufzeit und mit der Beziehung zum identifizieren den Business Objekt Auftrag Wareneingang Bestellung etc um einen Verweis auf die reale Prozessinstanz zu haben 9 7 9 7 Modellierung des Prozess Controlling mit der Oracle BPA Suite Die Prozesskosten inkl der finanziellen Bewertung der ben tigten Ressourcen sind ent scheidende Kennzahlen da diese die Verbindung der operativen Gesch ftsprozesse mit dem Gesch ftsergebnis herstellen lassen sich aber nur ex post berechnen F r eine genaue re Beschreibung der Prozesskennzahlen und Methoden der Ermittlung sei auf Schm03 verwiesen 9 6 2 Prozessdurchlaufzeit PDauer Eine wesentliche Kennzahl f r das Process Monitoring ist die Durchlaufzeit Grundlegend lassen sich unterschiedliche Zeiten messen um hieraus je nach Anforderung unterschied liche Prozesslaufzeit
113. abbildbaren impliziten Beziehungstypen IBT semantisch passender HL X semantisch abbildbarer IBT ti A IM sli xk x 1002 San NG Alan gt semantisch erforderlicher HL Y semantisch erforderlicher IBT a Basierend auf der semantischen Abdeckung der graphisch ausgepr gten GA und implizit modellierten IM Entitat Beziehung Entitat Gruppen errechnet sich die gesamte seman tische Abdeckung GSA gt semantische Abdeckung GA X semantische Abdeckung IM j k GSA Eee Guia nn 2 EAI Anzahl der einzelnen semantischen Abdeckungen 76 4 6 Analyse und Bewertung der semantischen Abdeckung Im aufgef hrten Beispiel ergibt sich eine gesamte semantische Abdeckung von 90 Mit Hilfe der n Tabelle 4 3 dargestellten Bewertung k nnen S e einsch tzen wie gut das individuelle Metamodell in die Oracle BPA Suite umgesetzt wurde und welche Verwen dung die erreichte semantische Abdeckung erm glicht Tabelle 4 3 Bewertung der semantischen Qualit t des umgesetzten Metamodells Semantische Abdeckung 90 lt GSA lt 100 Bewertung 75 lt GSA lt 90 durchschnittlich 50 lt GSA lt 75 mangelhaft 0 lt GSA lt 50 m gliche Verwendung gut bis sehr gut Metamodell kann als Basis f r eine integrierte EA BPM SOA Modellierung verwendet werden Metamodell kann als Basis genutzt werden wenn nach einer ausf hrlichen Analyse der semantisch unzureichend abgedeckten Bereic
114. ablen Nutzenver h ltnis Kleinste technische nderungen w rden zu einer umfassenderen Aktualisierung in der BPA Suite f hren Kanten m ssen ggf neu modelliert alte Elemente ersetzt und nicht mehr ben tigte Elemente gel scht werden Um diesem Aufwand zu entgehen aber den noch die Informationen zur technischen Schnittstelle zu erhalten wird ein Attribut am Softwareservice gepflegt welches auf die technische Schnittstelle verweist Um den Pflegeaufwand geringer zu halten werden nicht alle m glichen Verbindungen modelliert Abbildung 7 5 zeigt noch mal eine Einschr nkung auf alle relevanten Verbin 7 2 Services und SOA dungen Die technischen Informationen der ausfthrbaren IT Modelle sind innerhalb der technischen Artefakte verkn pft In der BPA Suite ist lediglich ein Link auf diese Doku mente gepflegt bersichtsmodelle Fachliche Ausf hrbare Fachliche Detailmodelle IT Modelle IT Modelle PSM l CIM PIM i Gesch ftsservice Softwareservice struktu e O F higkeit u Ri Softwareservice Operationstyp Entitytyp Attribute Funktion Gesch ftsservice Web Service Operation Messages Fachbegriff XSD Abbildung 7 5 Reduzierte Modellierung von Services Die hier getroffene Auswahl mussen Sie in Ihrem SOA Vorhaben Ihren Zielen anpassen Soll das Modell sp ter Software generieren werden mehr Informatio nen Verkn pfungen ben tigt als in dieser Auswahl 7 2 7 Der Nutze
115. agestellungen Wiederholen Sie diesen Arbeitsschritt so lange bis Sie ca die dreifache Anzahl an Fragen gesammelt haben wie Teilnehmer in der Runde sind Aus Erfahrung k nnen wir sagen dass Sie dann in der Regel die m glichen essenziellen Fragestellungen dieser Gruppe iden tifiziert haben 3 2 Der werkzeugneutrale Modellentwurf Ordnen Sie anschlie end alle Fragen den ermittelten Grunds tzen zu In unserem Beispiel sind dies m Fragen zum Informationsmanagement Welche Daten werden von welchen Anwendungen verarbeitet In welchen Formaten liegen gleiche Daten in welcher Abteilung vor m Fragen zur Standardisierung Welche Datenbanken nutzen welche Server Welche Anwendung nutzt welchen Server Welche Applikationen unterst tzen gleiche fachliche Prozesse m Fragen zur Betriebsorganisation Welche Aktivit ten sind betroffen wenn eine Anwendung nicht mehr zur Verf gung steht Welche Personen sind f r welche Applikationen verantwortlich 3 2 2 2 Zerlegung und Bewertung der Fragestellungen Nachdem die essenziellen Fragestellungen erfasst wurden werden sie zerlegt und bewer tet Dabei geht es darum die gesammelten Fragen nach ihren Anteilen an den Sichten zu zerlegen zu ordnen und hinsichtlich der Bedeutung f r Ihr Modell zu bewerten Ziel ist es zu erkennen in welcher Sicht der Schwerpunkt Ihres Modells liegt Um die Fragen nach den zugeh rigen Sichten zu zerlegen empfehlen wir zun chst jede Sicht ein
116. al management ein Einstellungs vorgang Unternehmens entwicklung ein Strategie planungszyklus Beschaffungsvorgang f r ein konkretes Gut bzw zusam mengefasst mehrere G ter innerhalb einer Bestellung Vertriebsvorgang f r eine konkrete Kundenanfrage zu einer oder mehreren zusam mengefassten Leistungen des Unternehmens Erbringung einer konkreten Serviceleistung f r ein durch das Unternehmen hergestelltes Gut oder eine Gruppe von G tern innerhalb einer Service anfrage Durchf hrung einer konkreten Produktentwicklung f r ein Gut welches durch das Unterneh men hergestellt werden soll Durchf hrung eines konkreten Produktionsauftrages zu einer Bestellung Durchf hrung eines Marketing projektes f r eine klar abgrenz bare Werbeaktion Erstellung einer Rechnung zu einem Kundenauftrag Durchf hrung der Einstellung f r eine ben tigte Personal ressource Durchf hrung einer Strategie planung f r einen definierten Zeitraum Eingang einer Bestellanfrage Eingang der Kundenanfrage Eingang einer Serviceanfrage Eingang eines Produktentwicklungs auftrags Eingang eines Produktionsauftrages Erteilung eines internen Vermarktungsauftrages fur ein neues oder modifiziertes Produkt oder eine Dienstleistung Benachrichtigung Uber den Warenversand Rechnungsdaten Eingang einer Perso nalbedarfsanfrage Zeitlich oder ereignis induzierter Start eines Strategieplanungs zyklus
117. al verfei nert und enth lt den Service Nachlieferung Beim Einf gen eines neuen Service auf einem bestehenden wird eine Kante vom Typ umfasst modelliert Diese Kante ist wichtig damit unsere Service bersicht ebenfalls die neue Struktur enth lt In der Service bersicht kann jetzt ein Produktionsservice gefunden werden der einen Bestellservice umfasst 7 5 2 Arten der Serviceklassifikation Mit der Serviceklassifikation sollen den Services weitere beschreibende Informationen hinzugef gt werden Hierbei handelt es sich um strukturierte Informationen die man auch bei Auswertungen verwenden kann Aus S cht von Entscheidern wird das Serviceportfolio besser vergleichbar da alle Services in den gleichen Kategorien klassifiziert werden Die folgenden Klassifikationsarten sind Beispiele Welche Klassifikationen 1m Unternehmen sinnvoll sind muss individuell betrachtet werden Servicestatus Der Servicestatus beschreibt in welchem Lebensstatus sich der Service aktuell befindet Servicekandidat Bei der Serviceidentifikation wurde ein Service gefunden Es wurde jedoch noch nicht entschieden den Service auch als solchen bereitzustellen E Manueller Service Der Service wird von Menschen realisiert Es gibt keine technischen Schnittstellen E Technischer manueller Service Der Service besitzt technische Schnittstellen und kann in Anwendungssystemen ver wendet werden Die Leistung wird jedoch manuell erbracht Z B bearbeitet der Mitar beite
118. amp die SOPHISTen PROFESSIONELLE ITERATIVE ANFORDERUNGSANALYSE FUR DIE PRAXIS 5 Auflage HANSER HANSER alles gut Chris Rupp amp die SOPHISTen Requirements Engineering und Management Professionelle iterative Anforde rungsanalyse fur die Praxis 5 aktualisierte und erweiterte Auflage 569 Seiten Vierfarbig ISBN 978 3 446 41841 7 Softwareentwickler m ssen die Anforderungen Requirements an ein Software System kennen damit sie und auch die sp teren Anwender sicher sein k nnen dass das richtige System entwickelt wird Die Anforderungs analyse entscheidet ber den Erfolg von Projekten oder Produkten In ihrem Bestseller beschreiben die SOPHISTen ausgewiesene Require ments Experten den Prozess Anforderungen an Systeme zu erheben und ihre st ndige Ver nderung zu managen Sie liefern innovative und in der Praxis vielfach erprobte L sungen Zahlreiche Expertenboxen Beispiele Templates und Checklisten sichern den Know how Transfer in die Projekt arbeit Mehr Informationen zu diesem Buch und zu unserem Programm unter www hanser de computer HANSER Glasklar Das Standardwerk Java SPEKTRUM chris RUPP stefan QUEINS barbara ZENGLER UML 2 GLASKL AR Er PRAXISWISSEN F R DIE UML MODELLIERUNG Rupp Queins Zengler UML 2 glasklar 568 Seiten ISBN 978 3 446 41118 0 Standardwerk 3 Auflage Die UML 2 0 ist erwachsen und in der Version 2
119. ander tauschen sie Gesch ftsobjekte aus Ein Gesch ftsobjekt wird immer nur von einem Hauptprozess vollst ndig bearbeitet Die Gesch ftsobjekte die dem bergeordneten Kernprozess zugeordnet sind m ssen jeweils eindeutig als Input oder Output durch die Hauptprozesse an den Schnittstellen der Kernprozessebene erstellt bzw bearbeitet werden Maximal 4 Gesch ftsobjekte pro Hauptprozess 92 5 2 Aufbau des Grundmodells 5 2 2 3 Die 3 Instanzgranularitat Die Hauptprozessebene Die 3 Instanzgranularit t Hauptprozessinstanzebene detailliert die Hauptprozesse der Kernprozessebene Dabei werden zu jedem ermittelten Hauptprozess die zugeh rigen Unterprozesse dargestellt Zur Identifikation der Unterprozesse verfahren Sie genau wie bei den Kern und Hauptpro zessen Es sind alle Unterprozesse zu ermitteln die zur vollst ndigen Ausf hrung des betrachteten Hauptprozesses ben tigt werden Auch in diesem Schritt m ssen Sie wieder alle ermittelten Aktivit ten darauf hin untersu chen ob es sich tats chlich um Unterprozesse handelt oder ob bereits zu detaillierte Akti vitaten beschrieben wurden Starten Sie dazu ebenfalls wieder an den Schnittstellen des Hauptprozesses Sehen Sie sich zun chst die eingehenden und ausgehenden Gesch ftsobjekte an Auch in diesem Fall markieren die Gesch ftsobjekte die Unterprozesse an der Schnittstelle des zu detaillieren den Hauptprozesses Bestimmen Sie auf diese Weise die erforderliche Gr
120. ans bes Zsocberen Anforderung 3 Anforderungsbaum Strategig t Yon 25H A sprieten zie d Anforderungsbaum Tiel ach Farbe sorbere Fis 5 Anforderungszuordnungsdiagramm eo EEE _ Anforderung Nach Farbe filtern 6 Anforderungszuordnungsciagramm Anwendi rer Anwendungssyste z 7T Anferderungszuordnungscdiagramm Cluster Fr 4 Clusten Datenmod Textfilter 8 Anforderungszuordnungscdiagramm Compon T Component 9 Anforderungszuordnungsdiagramm Fachbec Fachbegriff Tyn Pebiehmilke En 10 Anforderungszuordnungsdsagramm Franktsor AT Funktion PEA 1 Anfordenungszvordnungsdiagramm F higkei T F higkeit Typ Betriebssysten 12 Anforderungszuordnungsdiagramm Gesch f Temal 3 5 5 Sennceiyp Tun DEME 13 Anforderungszuordnungsdiagramm Gruppe eae op Gruppe ae on _ 14 Anforderungszuordnungsdiagramm HW Kon _ Hardwarekompone P OY Tunkuan 15 Anforderungszuordnungsdiagramm Kennzah 77 Kennzahlinstanz 4 Tyo HW Komponente 16 Anforderungszuordnungsdiagramm Klasse Anwendungssystem unwendungssyste _ 7 Anforderungszuordnungsdiagramm Klasse HW Komponente N Kiogs YD Lagersinricnituing 18 Anforderungszuordnungsdiagramm Netz P i Typ Materia 19 Anforderungszuordnungsdiagramm Netzkante A NA ante aa 20 Anfordenngszuordnungsdiagramm NetzkAntenklasse yo MocL 21 An m Netzkaffentyp Typ Organisationseinneit 22 An Ausgew hlter Netzklas EEE m 23 An Netzknate 4 F 24 An Symboltyp f r die NetzknotenKasse 25 An ita NetzknatentyR
121. anularit t der Unterprozesse Wie bereits auf den bergeordneten Ebenen werden auch hier weitere Aktivit ten der Un terprozessebene ermittelt Diese m ssen Sie daraufhin untersuchen ob sich unter ihnen Aktivit ten der gleichen Granularitat wie die bereits identifizierten Unterprozesse an den Schnittstellen befinden Ist dies der Fall so hat man weitere Unterprozesse gefunden Wie derholen Sie diesen Vorgang so lange bis keine neuen Unterprozesse mehr ermittelt wer den k nnen F r den Wareneingangsprozess wurden beispielsweise 1m Rahmen eines Brainstormings die untergeordneten Aktivit ten Warenreklamation Wareneingangskontrolle und Waren verbuchung identifiziert Anschlie end bestimmen Sie zu jedem definierten Unterprozess die zugeh rigen Ge sch ftsobjekte Auch dabei gelten die gleichen Kriterien wie bei den vorhergehenden Schritten Jedem Unterprozess muss mindestens ein zentrales Gesch ftsobjekt zugeordnet werden Jeder Unterprozess erzeugt wenigstens ein Gesch ftsobjekt als Ergebnis Die Gesch ftsobjekte eines detaillierten Kernprozesses sollen dabei eine ann hernd gleiche Granularit t besitzen Abschlie end wird berpr ft ob alle wertsch pfenden Unterprozesse wirklich zum ber geordneten Hauptprozess geh ren und alle beteiligten Gesch ftsobjekte identifiziert wor den sind Abbildung 5 5 zeigt exemplarisch die Hauptprozessinstanzebene des Wareneingangspro zesses Neben den Unterprozessen und den bearbeitete
122. arbeitung komplexer Analysevorhaben im Vordergrund Diese Abfragen ben tigen meist gro e Datenmengen und komplexe relationale Opera tionen um die gew nschten Ergebnisse zu berechnen Durch eine flexible und multidimensionale Betrachtung der Daten sollen entscheidungsunterst tzende Analysen gewonnen werden Die diesem spezifischen Datenmodell zugrunde liegende Struktur ist ein OLAP Cube der aus der operationalen Datenbank erstellt wurde Dieser ist meist nach dem Sternschema aufgebaut mit einer Faktentabelle und den jeweiligen Dimen sionstabellen e Produkt e Produktgruppe Gruppen e Gesch ftsbereich Be Prozesstyp Am Business Objekt Prozessinstanz Kennzahlen Laufzeit Qualit t Termintreue Kundenzufrieden s heitsindex e Aktivit t Pravaceknctan eendet SnRrbei Prozessschritt e Unterbrochen e Fehlerfall e Abgebrochen Aktivitatstyp ats Organisation gt Business Objekt e Gruppen e Org einheit e Produkt e Bereich e Produktgruppe e Abteilung e Gesch ftsbereich Abbildung 9 24 Das Multidimensionale Informationsmodell f r das Process Mining 2 OLTP Online Transaction Processing 3 OLAP Online Analytical Processing 9 Entwurf und Aufbau prozessgetriebener Kennzahlensysteme 256 Sehen wir uns den Zusammenhang an dem allgemeingultigen Beispiel fur die Modellierung genauer an Es gibt im Wesentlichen zwei grundlegende Faktentabellen die Aktivit t bzw der Prozessschritt und die Proz
123. areservicetyp verbunden sind sind unsere in der IT realisierten fachlichen Services Nur mit einem Web Service verbundene Softwareservices stellen rein technische Services dar Ein Softwareservicetyp ist die Kapsel f r mehrere Operationen die der Service bereitstellt Operationen sind vom Typ Softwareservice Operationstyp und werden mit Softwareservi cetypen auf Anwendungssystemtypdiagrammen ber eine Kante vom Typ Umfasst model liert Wird ein Softwareservice mit einem strukturierenden Gesch ftsservice verkn pft erbt der Softwareservice n der Ansicht im Service Repository siehe auch Abbildung 7 7 die F higkeiten die der strukturierende Gesch ftsservice bereitstellt Ein Softwareservice muss mindestens die F higkeiten unterst tzen die der strukturierende Gesch ftsservice bereit stellt Weitere F higkeiten k nnen z B nicht funktionale F higkeiten beschreiben Ein Softwareservice Operationstyp wird mit einer F higkeit verbunden Es muss genau eine der geerbten F higkeiten des Softwareservice sein Die Verkn pfung Funktion F 7 2 Services und SOA higkeit und Softwareservice Operationstyp sollte relativ h ufig eindeutig sein Besitzt die F higkeit eine zweite Implementierung kann die Eindeutigkeit ber den Gesch ftsservice an der Funktion hergestellt werden Der Gesch ftsservice ist mit genau einem strukturie renden Gesch ftsservice und dieser mit dem Softwareservice der Operation verbunden Die In un
124. auptprozesse Unterprozesse 6 12 3 5 Q LO 1 Instanzgranularitat Jnternehmensinstanz 2 Instanzgranularitat Kernprozessinstanz 3 Instanzgranularitat Hauptprozessinstanz vertikale Dekomposition Fachliche Ubersichtsdiagramme Abbildung 5 1 Horizontale und vertikale Dekomposition der 1 bis 3 Instanzgranularitat Abbildung 5 1 zeigt die empfohlene Vorgabe zum Aufbau der dynamischen Struktur der Ebenen 1 bis 3 Auf der x Achse sehen Sie die empfohlene Aufteilung der horizontalen Struktur eines Prozessmodells angegeben ist die empfohlene Anzahl an Prozessen jeder Modellierungsebene Auf der y Achse sind die empfohlenen Modellierungsebenen dargestellt Auf jeder Model lierungsebene m ssen die Inhalte eine einheitliche Instanzgranularitat aufweisen Das hei t 81 5 Das Grundmodell 82 jeder Modellinhalt der auf einer dieser Ebenen erzeugt wird muss zu allen anderen Inhal ten auf derselben Ebene ein m glichst gleiches Instanzverhalten zeigen Innerhalb der bersichtsmodelle betrachten wir in der Prozessarchitektur Kern Haupt und Unterprozesse Bei allen drei Prozesstypen handelt es sich um rein fachliche Modellie rungen ohne IT Bezug 5 2 1 2 Gesch ftsobjektbasierte horizontale Segmentierung Zur Abgrenzung der horizontalen Modellinhalte eignen sich gesch ftsobjektbasierte An s tze Dazu werden die horizontalen Bereiche nach den von ihnen bearbeiteten zentralen Gesch ftsobjekten unterteilt F r j
125. aus der Prozessmodel lierung bekannt sind So kann zum Beispiel ein Service einer Person zugeordnet werden welche dann f r den Service bzw f r alle Subservices verantwortlich ist Dom nendekomposition in der BPA Suite Ein Dom nendekompositionsmodell l sst sich auch in der BPA Suite erstellen Auf einem Service Architekturdiagramm kann die Struktur mit den bekannten Gesch ftsservices ab gebildet werden 7 5 Serviceklassifikation und Servicespezifikation Service Repository ae Produktion Servicetyp Bestellung Servicetyp Machlieterung Servicetyp Produktion Entwicklung Finanzen fs Nachlieterung initieren Servicetyp 2 io io EF higkeiten Bestellung Service Y Oi io io io beC Nachlieferung intieren F higkeit Fl Geschattsobjekte ES Artikelliefermenge in Fachbegriff Ex Coa tWaterial bestellung in Fachbegriff ons Ca Material bestellung out Fachbegriff Nachlieferung i Nachlieferungsmenge out Fachbegriff initiieren PoP UE o Nachlieferung a Realisierungen a Verwrendungen Visualisierungen Eom nendekompostion Service 4rchitekturdiagrarnin Inundsciacramm Abbildung 7 10 Dom nendekomposition in der BPA Suite und ge nderte Service bersicht Im Beispiel aus Abbildung 7 10 wurden die Dom nen Produktion Entwicklung und Fi nanzen modelliert Die Dom ne Produktion haben wir exemplarisch durch zwei Services verfeinert Bestellung und Service Y Der Service Bestellung wird ein weiteres M
126. bersichts Methodik modelle verf gbar Uberblicksmodelle f r abstrakte Strukturierung der modellierten betriebswirtschaftliche Modellie Inhalte ber Swimlane Darstellung rung vorhanden WKD E T nahe Prozesssprache IT Modellierung vgl Workflow Offener Standard der Object Patterns Management Group OMG Propriet res Format ARIS Die aus der ARIS Methodik stammende EPK Notation bietet den Vorteil dass die Model lierung der fachlichen Detailmodelle mit den dar ber liegenden berblicksmodellen ver kn pft und somit ein sauberer Top down Ansatz in der Modellierung realisiert werden kann Zudem eignet sich die intuitiv verst ndliche Notation sehr gut zur Diskussion fachli cher Abl ufe mit den Vertretern der Fachbereiche Der im amerikanischen Raum weit verbreitete Modellierungsstandard BPMN setzt sich im Bereich der technisch orientierten Prozessmodellierung auch in Europa immer st rker durch Die BPMN ist f r die Modellierung der fachlichen IT Modelle interessant da sie mehr technisch relevante Prozessszenarien abbilden kann als die EPK Notation vgl Ab bildung 8 7 So bietet die BPMN beispielsweise standardm ig Symbole die die wieder holte Ausf hrung von Aktivit ten Loop ausdr cken Auch komplexe Entscheidungen lassen sich zus tzlich zu den standardm igen OR und XOR Entscheidungen im Prozess fluss abbilden es existieren viele verschiedene Arten von Ereignissen Events und bei Datenobjekten kann
127. bestimmten Ordnungskriterien In unserem Fall orientiert sie sich an der vorgege benen Prozessstruktur Stelle Eine Stelle ist die kleinste organi satorisch sinnvolle Einheit inner halb einer Organisation Personen Real existierende Mitarbeiter die einer Stelle zugeordnet sind Beziehung zwischen Organisations Eine Organisationseinheit wird einheit Stelle und Person durch die Zusammenfassung einer leitenden und einer variablen Anzahl ausf hrender Stellen gebil det Jede Stelle wird mit mindes tens einem Mitarbeiter besetzt Ordnen Sie jedem Kernprozess der Prozesslandkarte eine Organisati onseinheit zu Verfahren Sie analog mit den Hauptprozessen der 2 Instanzgranularit t und pr fen danach kritisch die entstehenden Organisationseinheiten Fassen Sie die entstandenen Organisationseinheiten wo sinnvoll zusammen Verfahren Sie analog mit den Unterprozessen der 3 Instanzgranularit t Pr fen Sie besonders ob die ermittelten Organisationseinheiten ben tigt werden Im Zweifel verzichten Sie komplett auf die Bildung von Organisa tionseinheiten in dieser Granularit t Ordnen Sie jeder Organisationseinheit eine leitende Stelle und ggf unter geordnete Stellen zu Wenn Sie keine Organisationseinheiten auf der 3 Instanzgranularit t erstellt haben k nnen die Unterprozesse dieser Ebene zur Identifizierung der erforderlichen Stellen dienen Ordnen Sie bei Bedarf jeder Stelle einen oder mehrere Personen zu
128. betrifft beispielsweise Kenntnisse des BPEL Standards und die Struktur von BPEL Insbesondere bei der automatisierten bertragung der Modelle von EPK oder BPMN nach BPEL in der Oracle BPA Suite d rfen Prozesse nur Konstrukte z B Kontrollfl sse enthalten die der BPEL Standard unterst tzt vgl hierzu die Aus f hrungen zu Workflow Patterns in Abschnitt 8 3 5 Andernfalls ist die Generierung eines BPEL Modells nicht m glich Der Modellierer sollte dar ber hinaus auch die Oracle 8 4 SOA Prozessmodellierung in der Oracle BPA Suite spezifischen Erweiterungen des BPEL Standards kennen Beispiel die Human Workflow Anwendung die Bestandteil des Oracle BPEL PM ist und die im fachlichen IT Modell als Manuelle Aufgabe modellierten Prozessschritte umsetzt Andererseits w chst bei diesem Ansatz der Pflegeaufwand da nderungen an den erfass ten technischen Details im Modell nachgezogen werden m ssen Die Stabilit t des Modells wird entsprechend geringer Ein automatischer Abgleich der nderungen im Modell des SOA Entwicklers BPEL m JDeveloper mit dem Modell des SOA Business Analysten BPMN oder EPK in der BPA Suite ist vom Werkzeughersteller Oracle vorgesehen Der Einsatz dieses Vorgehens sollte jedoch sorgf ltig berdacht werden Dies gilt beispielswei se f r die Fragestellung ob der SOA Entwickler Einfluss auf die Gestaltung des fachlichen Prozesses nehmen k nnen soll Grunds tzlich stellt die Spezifikation der f r den SOA
129. cenaufwand fallen f r die Erstellung der Leistung an Die Prozesskostenrechnung dient der kaufm nnischen Bewertung des Prozesses durch Verbindung von Leistung Ressourcen und wirtschaft lichem Ergebnis 9 Entwurf und Aufbau prozessgetriebener Kennzahlensysteme Kennzahltypisierung Problemkreis Fragestellung Termintreue Wie gut werden die vereinbarten Termine eingehalten Die Termintreue spiegelt eine mangelhafte Planung berlastung oder mangelnde Prozesseffizienz wider Die Kennzahl muss in Verbindung mit der Prozesszeit bewertet werden 236 Prozesszeit Wie hoch niedrig sind die Durchlaufzeiten des Prozesses Analyse und Optimierung der Prozesszeiten dienen der Verbesserung von Prozesseffektivit t und effizienz 9 6 1 Ermittlung von Prozesskennzahlen Die Kennzahlen Kundenzufriedenheit Prozesskosten und Prozessqualit t lassen s ch in der Regel weder aus einem einzigen operativen System noch zeitnah zur Prozesslaufzeit ermit teln F r die Ermittlung der meist komplexen Kennzahlen Kundenzufriedenheit und Pro zesskosten ben tigen wir Informationen aus weiteren operativen Systemen siehe Abbil dung 9 7 Die Berechnung dieser beiden Kennzahlen kann erst bei der bertragung in den Ex post Datenbestand des Enterprise Modells im Process Warehouse stattfinden Messung Kundenzufriedenheit Kunden zufriedenheit Rechnungs Prozesskosten wesen Termintreue Prozessqualit t j i Datenbank M Prozesszeiten _ _ _ _ _
130. cess Monitoring Beschaffung Aufbereitung Process Mining Analyse Abbildung 9 4 l Kernaufgaben und Bausteine des Process Controlling Process Warehouse Die Aufgabenbereiche Process Monitoring und Process Mining und deren IT L sungen m ssen aus IT technischer Sicht zusammengefasst werden Die Zusammenfassung aller IT Komponenten f r das Process Controlling soll als Process Warehouse verstanden werden Oft wird das Process Warehouse als die Ablage aller Prozess relevanten Infor mationen f r die Organisation betrachtet Diese Aufgabe bezieht sich eher auf die interne Prozessdokumentation und Publizierung der Prozessmodelle nebst den abgeleiteten Ar beitsanweisungen Eine weitere Definition bezieht das Process Warehouse nur auf das 227 9 Entwurf und Aufbau prozessgetriebener Kennzahlensysteme 228 zugrunde liegende Data Warehouse The Process Warehouse is a separate read only ana lytical database that is used as the foundation of a process oriented decision support sys tem which aims to analyze and improve business processes continuously List00 Wir fassen den Begriff des Process Warehouse deutlich weiter Definition Process Warehouse Beschaffung Aufbereitung und Speicherung von Daten in einem IT System die f r die Aufgaben des Prozess Controllings bestehend aus Process Monitoring und Process Mining ben tigt werden 9 3 2 Abgrenzung Tabelle 9 1 verdeutlicht die unterschiedlichen Ans tze und
131. ch ist und wie allgemeinverbindlich man eine SOA definieren kann Vielmehr geht es uns darum die Anforderungen einer fachlichen SOA Modellierung im Kontext der Modellbildung zusammen mit EA und BPM zu beschreiben Dennoch kommen wir um eine kurze Beschreibung von SOA aus unserer Sicht nicht herum In der Welt der Informatiker besteht weitgehend Einigkeit dar ber dass zur Einf hrung einer SOA Kenntnisse ber die Prozesse die sie unterst tzen soll vorhanden sein m ssen An dieser Stelle erkennen S e die Verbindung mit dem fachlichen und technischen BPM Diese Betrachtung ist aber noch nicht hinreichend Ein umfassender Blick auf SOA muss dar ber hinaus aber weitere Aspekte wie zum Bei spiel die SOA Strategie SOA Governance und Organisation Service Portfolio Manage ment SOA Technologien und Implementierung sowie SOA Infrastrukturen umfassen SOA ist demnach mehr als wir zwischen zwei Buchdeckeln beschreiben k nnen Um 1m vorliegenden Buch nicht die Orientierung zu verlieren m ssen wir unser SOA enger definieren SOA ohne Kenntnisse und Ber cksichtigung der Gesch ftsprozesse eines Unter nehmens f hrt nicht zu wirklich prozessorientierten L sungen Deshalb sollte bei der umfassenden Einf hrung einer SOA auch BPM ber cksichtigt werden SOA ohne BPM ist nur eine technische Integration die nicht die vollen Potenziale bei der Konzepte ausschoptft 2 2 3 1 Unsere Definition von SOA Die von uns verwendete Definition vo
132. chbegriffe Tabelle 9 7 Benutzte Methodenobjekte der Oracle BPA Suite Modellname Datenglossar Diagrammtyp Fachbegriffsmodell Symbol Fachbegriff 9 7 Modellierung des Prozess Controlling mit der Oracle BPA Suite 9 7 1 4 Modellierung der Rollen Zur organisatorischen Implementierung des Process Controlling ben tigen siehe Kapitel 9 7 2 wir eigene Prozesse Bei der Modellierung der erforderlichen Prozesse f r das Pro cess Controlling brauchen wir sp ter Auszuf hrende bzw Verantwortliche sowie die User der Systeme s ehe Abbildung 9 15 Rollen PC Organigramm Top Management Process Owner Prozess verantwortlicher Abbildung 9 15 Modellierung der Stellen und Rollen Die festgelegten Rollen 1m Modell Organ gramm bilden hierf r die Basis Ferner k nnen wir aus den beschriebenen Rollen die Zugriffsrechte der Benutzergruppen ableiten In der Praxis wird sich zeigen dass man die ben tigten Rollen teilweise bei der Prozess modellierung erkennt und diese dann im Organigramm nachtragen muss Tabelle 9 8 Benutzte Methodenobjekte der Oracle BPA Suite Modellname Rollen PC Symbol Stelle Praktische Tipps f r eine vertiefende und komplexere Modellierung der Organisation er h lt man bei Schi09 S 90ff 9 7 2 Prozesse f r das Process Controlling Im n chsten Schritt modellieren wir nun die ben tigten dynamischen Elemente die Prozesse f r das Process Controlling D
133. cheer gemacht haben einem breiteren Kreis zuganglich zu machen Also begannen wir Material zu sammeln und zu strukturieren wahrend die ersten Versio nen der Oracle BPA Suite auf den Markt kamen Im Verlauf unserer Orientierungsarbei ten zeigte sich immer mehr dass wir kein weiteres Benutzerhandbuch schreiben wollten sondern dass es uns vielmehr darum ging eine Methode zur Verbindung der klassischen eher betriebswirtschaftlichen Modellierungswelt der IDS Scheer und der eher technischen Welt von Oracle vorzustellen Mehr noch stellten wir fest dass auf dem deutschen Markt bisher kein Buch verf gbar war das eine einfache Methode zum Aufbau eines integrierten Modells und damit zur Verbindung beider Modellierungswelten beschrieb Kurz vor Beendigung der Arbeiten an diesem Buch erreichte uns die Nachricht dass die Software AG beabsichtigt die IDS Scheer AG zu bernehmen Wir haben uns nat rlich direkt gefragt welche Auswirkungen diese bernahme auf unser Buch haben w rde Nach Bewertung der ersten Reaktionen von Oracle und IDS Scheer k nnen wir sagen dass kurz und mittelfristig keine nderungen auf Seiten der Hersteller zu erwarten sind Oracle ver wendet die ARIS Produktlinie an verschiedenen zentralen Stellen des eigenen Produktport folios und plant nach aktuellen Aussagen daran nichts zu ndern Parallel zu unseren berlegungen und den Ereignissen rund um Oracle nahm das grund s tzliche Interesse an den Zusammenh ngen v
134. chen den beiden ande ren Inhaltstypen vorstellen Um fachliche IT Inhalte zu identifizieren stellen Sie sich die Frage ob diese direkt mit einem IT System in Verbindung stehen dabei aber einen fachlichen Charakter f r den Anwender des IT Systems haben Ein Beispiel ist die Be schreibung eines Maskenflusses zur Bedienung einer Anwendungssoftware Es liegt n diesem Fall eine direkte Beziehung der Inhalte zu einem IT System vor gleichzeitig beschreibt der Maskenfluss aber auch die Arbeitsschritte eines Anwenders zur Umset zung eines fachlichen Prozesses Informations Technische Inhalte beschreiben wie IT Systeme die zur Unterst t zung eines fachlichen Prozesses ben tigt werden intern arbeiten Bei der Identifizie rung dieser Inhalte m ssen Sie darauf achten dass es sich ausschlie lich um Inhalte ohne direkte Verbindung zum Anwender des beschriebenen IT Systems handelt Bei spielweise kann man die Beschreibung der modularen Architektur einer Anwendungs software nennen 2 3 Grundsatzliche Gliederung eines integrierten Modells Abbildung 2 4 zeigt den abgestuften Zusammenhang zwischen fachlichen fachlichen IT und informations technologischen Modellinhalten Es besteht keine direkte Verbindung zwischen den rein fachlich orientierten und den informations technologischen Inhalten Beziehungen zwischen diesen beiden werden immer ber dazwischen liegende fachliche IT Inhalte hergestellt Wenn Sie Ihr Gesamtmodell auf diesem Weg erst
135. chenden Bestellposition im Wareneingangsprotokoll im System gespeichert Mitarbeiter Warenannahme Personentyp Wareneingangsprotokoll Fachbegriff Ist die Liefermenge Kleiner als die Bestellmenge weil es sich um keine Teillieferung handelt sondern tats chlich um eine Falsch lieferung handelt so wird dieser Fall auf der Maske angew hlt und die Information zur entsprechenden Bestellposition im Waren eingangsprotokoll im System gespeichert keine Teillieferung 145 6 Modellgest tzte fachliche Konzeption individueller IT Systeme 146 steht unter DV Verantwortung Mitarbeiter Warenannahme Personentyp von wird repr sentiert durch Teillieferung hat Output Wareneingangsprotokoll Fachbegriff Das Beispiel zeigt dass bei einem gut modellierten Systemverhalten die relevanten Infor mationen f r das Fachkonzept komplett aus der BPA Suite generiert werden k nnen 6 5 3 Statische Systemkomponenten Nachdem wir nun den Systemablauf konstruiert haben der den Fachprozess unterst tzen soll fehlt noch die Beschreibung der statischen Systemkomponenten Hier beginnen wir bei der Betrachtung der verarbeiteten Daten 6 5 3 1 Datenbeschreibung W hrend die im Rahmen eines Prozesses verarbeiteten oder erzeugten Informationen n der Fachsicht in Form von Gesch ftsobjekten dargestellt werden m ssen wir in der IT Sicht einen Schritt weiter ins Detail gehen und die konkreten Daten beschreiben die das System zur Verarbei
136. chkeit durch die Erzeugung vollst ndig neuer Diagrammtypen ist nicht m glich auch wenn dies durch die Benennung der Funktionalit t im Werkzeug suggeriert wird Aus diesem Grund kann man bei der Oracle BPA Suite auch nicht ernsthaft von einer Erweiterbarkeit der Dia grammtypen oder gar der Methode sprechen Wir empfehlen grunds tzlich nur in begr ndeten Einzelf llen von der Standardmethode abgeleitete Modelltypen zu erzeugen Objekttypen Objekttypen legen fest welche Inhalte mit der Oracle BPA Suite modellierbar sind Sie s nd das Herz der Modellierungsmethodik und bestimmen die grunds tzliche Semantik die mit dem Werkzeug ausgedr ckt werden kann Objekttypen erscheinen auf keinem Dia gramm sondern werden in der Methode genutzt um Inhaltstypen zu definieren In der Version 11g der Oracle BPA Suite stehen 228 Objekttypen zur Verf gung z B Hardwarekomponente und Informationstr ger Es k nnen keine neuen Objekttypen er weiteren Verlauf bevorzugt den Begriff Diagrammtyp verwenden Ausnahmen ergeben sich jedoch im mer dort wo auf Bezeichnungen im Werkzeug Bezug genommen wird 3 Die angegebene Anzahl der Methodeninhalte orientiert sich an der Oracle BPA Suite Version 11g Es bestehen an dieser Stelle Abweichungen zum ARIS Business Architect der IDS Scheer AG Dies gilt analog f r die Bereiche Objekttypen Symbole Kantentypen Attributtypen und Attributsymbole 59 4 Die Umsetzung des Metamodells 60 zeugt sondern le
137. d Outputdaten k nnen auf dieser Ebene deutlich feiner ber Entit ten modelliert werden Entit ten sind vom Typ Entitytyp und lassen s ch auf Zugriffsdiagrammen mit Softwareservice Operationen verbinden In unserem Modell verzichten wir an dieser Stelle auf die Datenmodellierung da wir kein unternehmensweites Datenmodell erstellen und auch keine Serviceschnittstellen generieren wollen Existiert kein fachlicher Service und der technische Service soll verwendet werden kann man eine Funktion mit einer Softwareservice Operation verbinden Dies kann n einer EPK oder in einem Funktionszuordnungsdiagramm modelliert werden Ausf hrbare IT Modelle In ausf hrbaren IT Modellen werden immer technischere Informationen verwendet Dies sind n der Regel in die BPA Suite importierte technische Schnittstellenbeschreibungen Ziel dieser Ebene ist es meist einen fachlichen Prozess in Software zu generieren Dieses Ziel verfolgen wir mit unserem Modell nicht Dennoch ist das Modell so strukturiert dass ein Ausbau zu einem generierungsfahigen Modell immer noch m glich ist Schritte zur Servicemodellierung Wenn Sie die oben genannten Modellierungsschritte in der folgenden Reihenfolge ausf h ren gelangen Sie zu einem modellierten und verwendeten Service in der BPA Suite 1 Modellieren des strukturierenden Gesch ftsservice 2 Modellieren der F higkeiten des strukturierenden Gesch ftsservice 1 n F higkeiten Empfohlen werden nicht mehr als
138. d schnell von Seiten der IT angenommen dass der Fachbereich von Web Services spricht wenn sie ber Services sprechen Diese Interpretation gilt es zu vermeiden Ein fachlicher Service muss nicht zwangsl ufig in der IT realisiert werden Ein hnliches Missverst ndnis tritt auch andersherum auf Wenn der IT Bereich ber Web Services spricht m ssen diese nicht immer einen fachlichen Hintergrund haben Die Web Service Technologie ist insbesondere n Integrationsprojekten weit verbreitet und bietet der IT eine einfache Methode Systemgrenzen zu berwinden 155 7 Identifizierung und Modellierung fachlicher Services fur SOA 156 Ein Ziel von SOA ist es diesen Bereich in dem sich Fachwelt und IT Welt tiberschneiden zu vergroBern Es wird jedoch auch mit SOA noch rein fachliche und rein technische Ser vices geben Wenn Sie versuchen fachliche Services moglichst ahnlich in der IT abzubil den bringt das die Herausforderung mit sich die verschiedenen Servicearten auseinander zuhalten wenn Fachbereiche und IT Bereiche miteinander kommunizieren 7 2 3 Atomare und zusammengesetzte Services Eine wichtige Unterscheidung f r Serviceanbieter ist auch die Art wie der Service seine Leistung erbringt Aus Sicht des Konsumenten ist nicht ersichtlich und auch nicht wichtig ob es sich um einen atomaren oder zusammengesetzten Service handelt Von atomaren Services spricht man wenn der Service die Leistung alleine bereitstellt Von zusammenge se
139. dem Gesch ftsservice und der F higkeit verbunden Generell gilt Mehrere Funktionen k nnen sich auf die gleiche Kombination von F higkeit und Gesch ftsservice beziehen Die Funk tionen d rfen unterschiedlich hei en m ssen jedoch inhaltlich das Gleiche tun Die Ver bindung zwischen Funktion F higkeit und Gesch ftsservice kann direkt in der EPK oder in einem Funktionszuordnungsdiagramm modelliert werden Funktionen und Gesch ftsservices nutzen die gleichen Gesch ftsobjekte als In und Out put Die Zuordnung wird in einem Service Zuordnungsdiagramm modelliert Ein Prozess kann als Service gesehen und publiziert werden Die Verbindung Prozess strukturierender Gesch ftsservice kann nicht direkt modelliert werden Ein Prozess ist auf einer h heren Ebene im Prozessmodell meist durch eine Funktion realisiert An diese Funktion k nnen ebenfalls F higkeit und Gesch ftsservice modelliert werden Ein genaue res Modellierungsvorgehen stellt Kapitel 8 dar Fachliche IT Modelle Fachliche IT Modelle stellen die technische Verfeinerung von fachlichen Prozessen dar Sind alle Funktionen eines Prozesses mit technischen Services verbunden kann dieser auch automatisiert werden Auf dieser Ebene des Modells werden wir unsere technischen Services in Form von Softwareservicetypen modellieren Softwareservicetypen dienen uns als Verbindungsst ck zwischen fachlichen und technischen Services Strukturierende Ge sch ftsservices die mit einem Softw
140. den Schritten ber cksichtigt man auch in Europa die Automatisierung von Gesch ftsprozessen mit Hilfe der Informationstechnologie Diese Definition vergr ert den inhaltlichen Umfang des BPM betr chtlich In der europ ischen Sicht auf BPM stehen rein fachliche und technische Inhalte gleichgewichtet nebeneinander 2 2 Management Fachbereiche und IT jeder ist anders Die unterschiedliche Sicht auf BPM f hrt in Deutschland h ufig zu Verstandigungsschwie rigkeiten zwischen zumeist US amerikanischen Herstellern von Werkzeugen zur Prozess automatisierung und fachlich ausgerichteten Anwendern Aufgrund dieses unterschiedlichen Verst ndnisses hat sich in Europa eine eigene Industrie f r BPM Softwarel sungen entwickelt und im Markt etabliert Erst in j ngster Zeit nicht zuletzt forciert durch SOA zeigen sich Tendenzen die BPM L sungen US amerikani scher und europ ischer Hersteller miteinander zu verbinden Business Process Management wird in den USA und in Europa unterschiedlich definiert Die USA betrachten beim BPM im Wesentlichen die Automatisierung von Prozessen mit Hilfe der Informationstechnologie In Europa stehen fachlich organisatorische und technische Inhalte gleichgewichtet nebeneinander 2 2 2 1 Unsere Definition von BPM Eine Beschr nkung auf die Automatisierung von Gesch ftsprozessen ohne deren fachliche Dimension zu ber cksichtigen ist f r ein ganzheitliches BPM jedoch unzureichend Aus diesem Grund verwenden wir
141. den formellen Anforderungen an ein Fachkonzept Weil ein Fachkonzept bestimmte unternehmensspezifische Kriterien bzgl 137 6 Modellgest tzte fachliche Konzeption individueller IT Systeme 138 E Layout und E Schriftformaten erf llen muss sollten die entsprechenden Skripte die modellierten Inhalte m glichst mit den geforderten Formatierungen ausgeben um nachtr glichen Bearbeitungsaufwand bzgl Formatierungen zu vermeiden Eine weitere entscheidende formelle Anforderung an ein Fachkonzept ist die Notwendig keit einen durchgehenden Lesefluss im Sinne eines roten Fadens zu gew hrleisten Um einen solchen Lesefluss zu erreichen ist eine Gesamtbearbeitung 1m Ergebnisdokument notwendig was ebenfalls deutlich macht dass eine vollst ndige Modellierung aller Inhalte eines Fachkonzepts schon aus formellen Gr nden keinen Sinn ergibt 6 4 2 Nicht modellierte Bestandteile eines Fachkonzepts Im Folgenden besch ftigen wir uns mit den wichtigsten Teilen eines Fachkonzepts die aus den oben genannten Gr nden blicherweise nicht modelliert werden sollten Wie schon erw hnt muss ein Fachkonzept alle aus Sicht der Fachabteilung relevanten An forderungen an ein zu realisierendes System enthalten Ein modellbasierter Ansatz wie er in diesem Kapitel beschrieben wird unterst tzt dabei vor allem bei der Identifikation und Spezifikation der funktionalen Systemanforderungen indem ausgehend vom zu unterst t zenden Fachprozess die be
142. der Ordnerstruktur unterhalb der genannten Hauptbereiche Sie k nnen diese Struktur erg nzen je nachdem welche zus tz lichen Artefakte Sie in Ihrem Modell aufnehmen m chten Folgen Sie dabei aber immer der vorgestellten Grundgliederung Tabelle 5 9 Empfohlene Gliederung der Oracle BPA Suite Ordnerstruktur im integrierten Modell Fachliche Dynamische FE Ablage rein betriebswirtschaftlicher Prozess Inhalte Inhalte beschreibungen ohne IT Bezug Jeder Kern Beschaffungsprozesse prozess und alle untergeordneten Prozesse Controllingprozesse le erhalten jeweils einen eigenen Ordner Statische Geschaftsobjekte Ablage aller Geschaftsobjekte die auf den Inhalte Instanzgranularitatsebenen 1 bis 5 ermittelt und modelliert wurden Organigramme Ablage aller aufbauorganisatorischen Inhalte Prozesscontrolling Kennzahlen Ablage der betriebswirtschaftlichen Kennzahlen definitionen f r ein Business Activity Monitoring s Kapitel 9 Ziele und Erfolgs Ablage der Ziele und Erfolgsfaktoren zur Bewer faktoren tung der Prozessergebnisse und qualit t s Kapitel 9 Fachliche Dynamische IT Anwendungsf lle Ablage der IT Anwendungsfalle welche die IT IT Inhalte Inhalte technische Unterst tzung fachlicher Prozesse bereitstellt s Kapitel 6 7 u 8 IT Prozesse Ablage der Prozessbeschreibungen zu Mensch Maschine Interaktionen zwischen Anwender und IT Systemen sowie durch IT Systeme automati sierte Prozesse s Kapitel 6 7 8 u
143. deutig zu kennzeichnen Dies kann zum Beispiel ein graphisches Symbol oder eine Farbe f r jede Ebene sein In unserem Beispiel verwenden wir die folgenden Kenn zeichnungen f r m Objekttypen der Geschafts Architektur m Objekttypen der Daten Architektur m Objekttypen der Anwendungs Architektur m Objekttypen der Infrastruktur Architektur Markieren Sie in jeder Frage die zentralen Objekttypen einer Sicht mit der zugeordneten Kennzeichnung Beachten Sie dabei dass Sie nur Hauptworter Substantive markieren Betrachten wir zum Beispiel folgende Frage Welche Aktivit ten sind betroffen wenn eine Applikation nicht mehr zur Verf gung steht l Selbstverst ndlich k nnen Sie die Ebenen auch farblich kennzeichnen worauf wir im Buch aus druck technischen Gegebenheiten verzichtet haben 39 3 Aufbau des Metamodells 40 In dieser Frage sind die zwei Sichten Geschaftsarchitektur und Anwendungsarchitektur enthalten Wir markieren deshalb Aktivitaten und Applikationen steht Wiederholen Sie diesen Vorgang f r alle Fragen die im Rahmen des Brainstormings er mittelt wurden AnschlieBend ordnen Sie jede Frage der entsprechenden Sicht zu Fragen in denen mehrere Sichten adressiert werden wie in unserem Beispiel werden jeder betrof fenen Sicht zugeordnet Dies kann ebenfalls an einem Flip Chart durchgef hrt werden Abbildung 3 3 zeigt den Zusammenhang zwischen den Sichten und unserer Beispielfrage Gesch fts Architektur
144. die im System be stimmte Berechtigungen besitzen und von Abteilungen oder Stellen wahrgenommen wer den k nnen 6 3 4 Beschreibung statischer Systemkomponenten Nachdem das dynamische Systemverhalten beschrieben und modelliert worden ist m ssen die in den Ablaufbeschreibungen verwendeten statischen Systemkomponenten Bild schirmmasken Daten Benutzerrollen beschrieben werden 6 3 4 1 Maskenbeschreibung Bei der Beschreibung von Masken sind verschiedene Aspekte zu ber cksichtigen Die wichtigste Frage ist wie detailliert die Masken beschrieben werden sollten Die Antwort auf diese Frage ist nat rlich abh ngig vom jeweiligen Projektkontext genauer gesagt von den Anforderungen der Fachabteilung Diese k nnen in einem Spektrum variieren zwischen E keine konkreten Anforderungen an Masken E konkrete Anforderungen an die Maskenstruktur E konkrete Anforderungen an das Maskenlayout In den seltensten F llen werden wirklich gar keine Anforderungen an Masken bestehen Zumindest unkonkrete Anforderungen wie Microsoft orientierte Benutzeroberfl che werden meist vorliegen Konkrete Anforderungen an die Maskenstruktur liegen vor wenn die sp teren Systembe nutzer zumindest vorgeben welche Aktionen auf einer Maske ausgef hrt werden k nnen und welche Daten auf einer Maske angezeigt und bearbeitet werden Es wird also die Frage beantwortet WAS auf einer Maske dargestellt wird siehe Abbildung 6 5 6 3 Die IT Sicht und ihr Zusamme
145. dieser Stelle ist wiederum zu beachten dass bei Mitarbeitern auf niedrigen Hierarchie ebenen h ufig Hemmungen bez glich der Beschreibung hrer tats chlichen Arbeit beste hen wenn Vorgesetzte anwesend sind so dass die eigenen Prozesse in dieser Situation gerne besser dargestellt werden als sie es in Wirklichkeit sind Tats chlich ist es jedoch insbesondere bei der Aufnahme der Ist Prozesse absolut notwendig die Realitat mit all ihren Schwachstellen abzubilden da gerade diese f r die Konzeption einer neuen IT L sung interessant sind Schlie lich sollen die Prozesse durch die neue L sung verbessert werden Die Frage ob Sie d e beschriebenen Prozesse direkt w hrend eines Workshops modellie ren sollten l sst sich nicht allgemeing ltig beantworten Die beschriebenen Prozesse m s sen in jedem Fall f r alle am Workshop Beteiligten sichtbar abgebildet oder skizziert wer den so dass die Mitarbeiter noch einmal kontrollieren k nnen ob ihre Beschreibung einer seits korrekt und vollst ndig und andererseits auch richtig verstanden wurde Die direkte Modellierung in einem entsprechenden Tool n mmt zwar ein wenig mehr Zeit in Anspruch als eine Skizzierung auf einem Flipchart oder Smartboard hat jedoch den Vorteil dass das erarbeitete Ergebnis einerseits sofort weiterverwendet werden kann und die beteiligten Mitarbeiter aus der Fachabteilung andererseits die verwendete Modellierungsmethodik kennen lernen Die Mitarbeiter m ssen die fer
146. diglich bestehende umbenannt werden Wir raten von einer Umbenen nung der Objekttypen ab da sie sich stark auf den methodischen Gesamtzusammenhang in der Oracle BPA Suite auswirken Symbole Die Bezeichnung Symbole ist analog zu den Modelltypen vom Hersteller des Werkzeu ges nicht korrekt gew hlt Die richtige Bezeichnung f r diesen Bereich der Methode ware Symboltypen da es sich auch hier um typisierte Inhalte handelt Symboltypen repr sentie ren graphisch die Objekttypen der Methode Als Modellierer verwenden Sie Symbole um Inhalte auf Diagrammen darzustellen Die Version 11g der Oracle BPA Suite bietet 696 Symboltypen zur graphischen Darstel lung zum Beispiel Wertsch pfungskette und CD ROM Symboltypen k nnen hnlich wie Modelltypen kopiert werden Auf diese Weise lassen sich zus tzliche Symboltypen anlegen die aber wie Modelltypen die Eigenschaften des Ausgangssymbols erben So erstellte Symboltypen unterliegen denselben methodischen Bedingungen wie ihre Quell symboltypen Es ist lediglich m glich kopierten Symbolen eine eigene graphische Aus pr gung zu geben Auch hier kann man deshalb nicht von einer Erweiterung der Methode sprechen Wie bereits bei den Diagrammtypen empfehlen wir die Nutzung dieser Funktionalit t nur in begr ndeten Ausnahmef llen Kantentypen Kantentypen bestimmen welche Beziehungen zwischen Symboltypen auf Diagrammen modelliert werden k nnen Die Version 11g der Oracle BPA Suite bietet 46
147. dungen und deren Auspr gung in Unternehmenszielen und nat rlich Sub Zielen n her ausf hren zu wollen Schm03 k nnen wir festhalten dass wir uns in diesem Beispiel auf ein einziges Ziel 1m Bereich der Produktivit t be schr nken wollen Das Gesch ftsziel st die Senkung der Durchlaufzeiten f r den Wareneingangsprozess um 20 Der Vollst ndigkeit halber haben wir in Abbildung 9 12 die grundlegenden Leistungs parameter Schm03 S 153 ff f r die Bewertung eines Prozesses als Zieldiagramm auf genommen und die Reduktion der Durchlaufzeit verfeinert Im rechten Diagramm aus Abbildung 9 12 erkennt man die Bildung von Erfolgsfaktoren Diese Erfolgsfaktoren sind als geplante Initiativen zu verstehen die zur Erreichung des Ziels durchgef hrt werden sollen Diese Erfolgsfaktoren m ssen in der sp teren Modellie rung aufgegriffen werden und bilden die Basis f r die Implementierung organisatorischer Ma nahmen sowie die Grundlage der Konzeption und Implementierung von IT Systemen zur Bildung der relevanten Kennzahlen Alignment mit den Geschaftszielen In Tabelle 9 5 werden die ben tigten Oracle BPA Suite Methodenobjekte aufgef hrt In unserem speziellen Fall wiederum erkennt man bereits jetzt dass diese Erfolgsfaktoren sich auf die geschilderten drei unterschiedlichen Ans tze abbilden lassen s Tabelle 9 4 Tabelle 9 4 Zusammenhang zwischen den Erfolgsfaktoren und den ben tigten Anwendungssystemen Monitoring u
148. e Darstellung sehr gut als Aus gangspunkt f r die Gestaltung der Aufbauorganisation einer Organisation genutzt werden kann Voraussetzung ist aber immer dass die entstehende Organisationsstruktur kritisch hinterfragt und an praktischen Kriterien ausgerichtet wird Wie bei der Prozessstruktur existiert 1m Bereich der Organisationsmodellierung keine allgemeinverbindliche Vorgabe die jedes bestehende Modellierungsproblem eindeutig l st Die hier vorgestellte Vorgehensweise liefert eine einfache und praktische Vorgehens weise um individuelle Projekte zu strukturieren 5 2 Aufbau des Grundmodells Tabelle 5 7 Inhalt und Abgrenzung der Organisationsbibliothek Benennung der Organisations bibliothek Genutzte Objekttypen Abgrenzung Granula ritat der auf den Diagrammen ausge pragten Objekte Name des Unternehmens inklusive der Rechtsform Sollte ein Diagramm zur Abbildung der Organisationsbibliothek nicht ausreichen so werden die benotigten Unterdiagramme nach der Organisationseinheit benannt die als Ausgangspunkt des zus tzlichen Diagramms gew hlt wurde Beschreibung der Organisationsstruktur der betrachteten Organisation bzw eines ausgew hlten Teilbereiches Die Bibliothek dient als zentraler Platz zur Dokumentation aller organisatorischen Inhalte Organisationseinheit Innerhalb einer Organisationsein heit werden fachlich zusammen h ngende Stellen und Personen zusammengefasst Eine Organisa tionseinheit folgt dabei
149. e Ver nderung der Umwelt innerhalb eines Ablaufs darzustellen Stellen Sie sich beispielsweise den Ablauf des Wareneingangsprozesses vor Im Rahmen der dynamischen Modellierung wird dort beschrieben wie Waren angenom men verbucht und eingelagert werden Demgegen ber beschreibt die Statik Sachverhalte die ber einen l ngeren Zeitraum stabil bleiben In einem Organigramm ist zum Beispiel der organisatorische Aufbau der Abtei lung Wareneingang beschrieben Sicher auch statische Inhalte unterliegen einer zeitli chen Ver nderung sie ist in der Regel aber nur l ngerfristig zu erkennen und liegt nicht m Fokus der Darstellung Statische Inhalte beschreiben demnach Ressourcen die in Prozes sen erzeugt genutzt oder verbraucht werden Zwischen Dynamik und Statik besteht also ein Zusammenhang Bei der Abbildung inner halb eines Modells ist es dennoch empfehlenswert die Inhalte zu trennen Dies geschieht vor dem Hintergrund dass die Modellierung beider Bereiche theoretisch getrennt erfolgen sollte Idealtypisch w rden Sie bei der Modellierung folgenderma en vorgehen Beschreiben Sie zun chst alle statischen Inhalte komplett losgel st voneinander E Anschlie end modellieren Sie ausschlie lich die Aktivit ten zur Durchf hrung eines Prozesses wobei darauf zu achten ist dass keine statischen Informationen zum Beli spiel beteiligte Personen etc n die Formulierung der Aktivit ten einbezogen werden E Im abschlie enden
150. e befasst sich mit den informationstechnologischen Bestandteilen einer SOA Dies beinhaltet im Wesentlichen Fragen zur technischen Architektur von SOA L sungen zur eingesetzten Infrastruktur und nat rlich zur Entwicklung erforderlicher Software Eine SOA aus technischer Sicht betrachtet damit prim r die technische Umset zung 2 2 3 2 SOA im Kontext dieses Buches Im Rahmen des Buches beschranken wir uns auf die prozessbezogenen fachlichen Model lierungsinhalte einer SOA und wie diese mit einer EA und BPM Modellierung in Verbin dung stehen Nicht ber cksichtigt werden Service Level Management SOA Governance und alle weiteren Themen die sich mit der technischen Implementierung einer SOA befas sen Diese finden Sie in diversen Publikation zur Implementierung technischer SOA Losungen Grundsatzliche Gliederung eines integrierten Modells 18 Der zentrale Erfolgsfaktor eines Modells kann ganz einfach benannt werden Es muss in der Lage sein Antworten auf die Fragen zu liefern zu deren Beantwortung es erstellt wur de Wie sieht das aber bei einem integrierten Modell aus Auch dort ist der Erfolgsfaktor derselbe mit der Erganzung dass unterschiedliche Interessengruppen erwarten dass das Modell ihnen mitunter recht unterschiedliche Fragestellungen beantwortet Fur Sie als verantwortlichen Modelldesigner ergibt sich dadurch nat rlich eine besondere Herausfor derung Sie m ssen Ihr Modell bereits von Anfang an so strukturieren dass
151. e 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 ber zogen worden ist Auch die Realisierung eines Systems das sich anschlie end in der Pra xis 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 Ana lysten 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 117 6 Modellgest tzte fachliche Konzeption individueller IT Systeme 118 Nicht nur die Anzahl der Studien auch hr 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 unterschiedli chen Sichten die d
152. e und dynamische Frameworks k nnen in der Anwendung miteinander kombiniert werden Aus unserer Sicht haben die am Markt verf gbaren Standard EA Frameworks aber den Nachteil dass sie entweder nicht genug oder viel zu umfangreich ausgestaltet sind Da durch sind S e als Anwender von Standardframeworks entweder gezwungen ben tigte Erweiterungen ohne Unterst tzung selber zu entwickeln oder was aus unserer Sicht noch viel schlimmer ist aus einem berangebot an M glichkeiten die f r Sie richtigen zielsi cher auszuw hlen Das ist ohne intensive Beratungsunterst tzung nahezu unm glich Es muss also einen besseren Weg geben um schnell zu einer individuellen Enterprise Archi tecture zu gelangen Da Enterprise Architecture Frameworks h ufig zu oberfl chlich oder zu umfang reich gestaltet sind empfehlen wir den Entwurf Ihrer eigenen Vorgehensweise und Ihres eigenen Metamodells Orientieren Sie sich dabei zun chst nicht an Standardframeworks sondern nutzen Sie diese nur zur Verifikation Ihrer indivi duellen L sung und als Ideenquelle 12 2 2 Management Fachbereiche und IT jeder ist anders 2 2 1 1 Unsere Definition einer Enterprise Architecture Eine Enterprise Architecture ist ein konzeptioneller Entwurf welcher die Struktur und Arbeitsweise einer Organisation beschreibt Ziel einer Enterprise Architecture ist es zu ermitteln wie die betrachtete Organisation m glichst effektiv aktuelle und zuk nftige Ziele erreichen kann
153. eder liegt eine Spezifikation des Audit Trails des Workflow Systems vor WFMC95 damit ist das Monitoring von Workflows in einem Unternehmen unab h ngig von speziellen Implementationen des Workflowmanagementsystems m g lich In der Spezifikation werden die wesentlichen Statuswechsel Zeitstempel und involvierten Ressourcen festgehalten Wie sieht die Realit t aus Die Realit t sieht jedoch meist anders aus Der notwendige Grad an Prozessau tomatisierung f r die geschilderten generischen Ans tze ist bei vielen Unterneh men nicht gegeben da die genutzten Anwendungssysteme berwiegend noch funktional ausgerichtet und oft von Medien Br chen durch Systemwechsel ge pr gt sind Gleichwohl ist es zielf hrend auch in heterogenen Systemlandschaf ten mit vielen Systemwechseln und Medienbr chen ein Process Controlling fur ausgew hlte Kernprozesse die einen wesentlichen Beitrag zur Wertsch pfung leisten zu implementieren Die zentralen Begriffe Durch den Einsatz des Process Controlling soll die L cke im Regelkreis des Gesch ftspro zessmanagements GPM beim bergang von der Prozessimplementierung zur Prozessop timierung geschlossen werden Ziel des Process Controlling ist die kontinuierliche Verbes serung der Qualit t und Effizienz der ablaufenden Gesch ftsprozesse wie auch die Near Real Time Steuerung der aktuell laufenden Prozesse Im Rahmen des Process Controlling werden zwei unterschiedliche Aufgabenstellungen betracht
154. edes horizontale Segment identifizieren Sie maximal 3 oder 4 zentrale Gesch ftsobjekte je nach Ebene s Abschnitt 5 2 5 2 Bei einem zentralen Gesch ftsobjekt handelt es sich um ein Objekt der realen Welt welches f r die Durchf h rung des betrachteten Prozesses zwingend erforderlich ist In einem Wareneingangsprozess kann dies zum Beispiel die Materiallieferung sein Zentrale Gesch ftsobjekte werden durch folgende Kriterien eindeutig bestimmt E Wesentliche Bearbeitung des Gesch ftsobjektes durch den betrachteten Bereich Das Geschaftsobjekt kann in anderen Prozesssegmenten eine weitere Verwendung finden erf llt dort aber nicht die beiden folgenden Kriterien E Das Gesch ftsobjekt erm glicht die Messung der Leistung des betrachteten Bereiches Anhand der Anzahl der bearbeiteten Gesch ftsobjekte ist es m glich zu bestimmen wie effektiv und effizient das betrachtete Prozesssegment arbeitet Das zentrale Gesch ftsobjekt ist nicht das Prozessergebnis des betrachteten Prozess segmentes Geschaftsobjekte die durch Aktivit ten im betrachteten Segment entstehen k nnen nur in nachfolgenden Bereichen zentrale Prozessobjekte darstellen Gehen Sie zur horizontalen Segmentierung in den folgenden Schritten vor l Ermitteln Sie die Gesch ftsprozesse der betrachteten Modellierungsebene siehe auch vertikale Dekomposition 2 Ermitteln Sie f r jeden Gesch ftsprozess das die zentrale n Gesch ftsobjekt e ma ximal 4 3
155. ehebenden Schwach stellen 139 6 Modellgest tzte fachliche Konzeption individueller IT Systeme 3 Beschreibung der Soll Fachprozesse insbesondere Beschreibung der Stellen im Pro zess an denen das neue IT System unterst tzen soll Funktionale Systemanforderungen inkl Beschreibung des Systemablaufs Nicht funktionale Systemanforderungen Systemschnittstellen Schnittstellen zu anderen IT Systemen inkl Datenfl sse a sat dee Beschreibung statischer Systemkomponenten Benutzeroberflache Daten Rollenkon zept 8 Beschreibung sonstiger Anforderungen bspw Sicherheit Administration Testbetrieb Inbetriebnahme Abnahme Betrieb Abgesehen von den beschriebenen formellen Aspekten und der Anforderung eines durch gehenden Leseflusses wird auch durch diese Beispielgliederung noch einmal eines deut lich Es sollten niemals alle Teile eines Fachkonzepts unter Verwendung einer Model lierungsmethodik und eines entsprechenden Werkzeugs erstellt werden 6 5 Erstellung eines Fachkonzepts mit der Oracle BPA Suite Nach der theoretischen Darstellung der modellgest tzten Fachkonzeption folgt in diesem Abschnitt exemplarisch eine praktische Anwendung der Methodik Ausgangsbasis ist da bei der bereits vorgestellte Fachprozess der Wareneingangsbearbeitung 6 5 1 Fachprozess Grundlage unseres Fachkonzepts ist der Wareneingangsprozess Dabei wird Ware durch einen Lieferanten angeliefert Zur Lieferung erhalt der Mitarbeiter im
156. eiben und sich nicht durch vermutete Restriktionen beeinflussen zu lassen Selbst wenn man fest da von ausgeht dass eine ben tigte IT Unterst tzung nicht realisierbar ist sollte diese Unter st tzung formuliert werden Wenn sich diese Anforderung im Nachhinein tats chlich als nicht erf llbar herausstellt kann sie noch immer gestrichen werden Was Sie nicht als Anforderung formulieren das werden Sie auch nicht bekommen Die Detailtiefe bei der Modellierung der Soll Prozesse sollte der Detailtiefe der Ist Prozes se entsprechen und muss so gew hlt werden dass die Stellen an denen der fachliche Pro zess durch die neue IT L sung unterst tzt werden soll identifiziert und aufgezeigt werden k nnen Die IT Unterst tzung wird an diesen Stellen an den Fachprozess modelliert und als eine funktionale Anforderung an das neue System beschrieben Als Ergebnis der Phase Soll Prozessentwicklung liegt also eine m glichst optimale Vari ante der Arbeitsabl ufe n der Fachabteilung inkl Beschreibung der zu ihrer Unterst t zung erforderlichen Systemfunktionalit ten vor Obwohl die vorliegende Beschreibung ex plizit als Vorgehen f r Individualentwicklungen vorgestellt wird ist eine derartige prozess orientierte Erhebung von Anforderungen bei jeder Art von Softwareentwicklung und auch beschaffung sinnvoll Wie zu Beginn des Kapitels erw hnt kann je nach Aufgabenstel lung auch die Auswahl einer Marktl sung den richtigen Weg zur IT tech
157. eillieferung pr fen oder R cklieferung pr fen bereitstellen und w rde somit vielf ltige fachliche Funktionalit t zur Pr fung einer Lieferung kapseln Gesch ftsservice Service Gesch ftsservice Operation Lieferungs kontrolle Nachlieferung berpr fen Geschaftsservice Operation Nachlieferung reklamieren Abbildung 8 10 Gesch ftsservice mit Operationen im Servicezuordnungsdiagramm Damit ist die SOA Prozessmodellierung auf der Ebene des fachlichen Detailmodells abge schlossen Eine weitere Detaillierung der identifizierten fachlichen Services und deren Ope rationen ist vorbereitet Die modellierten Services und Operationen sollten dar ber hinaus in den Attributen der BPA Objekte fachlich detailliert in Textform beschrieben sein was wiederum den Ansatz eines fachlichen Serviceportfolios unterst tzt vgl Kapitel 7 211 8 Der prozessgetriebene SOA Ansatz 212 8 4 2 Vorstufe zum automatisierten Prozess Das fachliche IT Modell Die im fachlichen Modell identifizierten und grob beschriebenen fachlichen Services und deren Operationen sollen im nachsten Schritt weiter detailliert werden Dies erfolgt wieder in Form eines Prozessmodells und geschieht auf der sechsten Ebene der Prozessdekompo sition als so genanntes fachliches IT Modell vgl Abbildung 8 3 In unserem Vorgehen erzeugt das fachliche IT Modell einen neuen fachlichen Service durch die sinnvolle Verkn pfung Orchest
158. ein durch gangiges Konzept bis zur Implementierung in der IT bereitzustellen Oftmals wird dieser Ansatz durch eine allzu ambitionierte IT oder nicht gen gend Kapazit ten auf Seiten der Business Analysten torpediert und man besch ftigt sich in erster Linie mit reinen IT Themen einer SOA In der Praxis l sst sich beispielsweise oft beobachten dass die Infra struktur vor dem Beginn der Anforderungsanalyse gekauft wird Dieses Kapitel vermittelt wie fachliche Anforderungen an SOA in Form von Services er stellt und dokumentiert werden k nnen Au erdem wird in diesem Kapitel ein grundlegen des Verst ndnis f r SOA und Services geschaffen soweit es f r dieses Buch notwendig ist 153 7 Identifizierung und Modellierung fachlicher Services fur SOA 154 Die Begriffe Service und SOA wurden in den letzten Jahren h ufig sehr unterschied lich interpretiert und verwendet Die Ursachen sind vielf ltig Zum Teil liegt es am Marke ting der verschiedenen Beratungsdienstleister und Systemanbieter die den SOA Hype zur Verkaufsf rderung genutzt haben Dies ist ein noch nicht behobenes Manko Es gibt noch immer keine umfassende und all gemein anerkannte Definition von SOA Das Standardisierungsgremium OASIS hat einen ersten Schritt n diese Richtung unternommen und ein SOA Referenzmodell ver ffentlicht In diesem Modell wird prim r der Begriff Service beschrieben In dieser Form reicht es als ausschlie liche Definition f r eig
159. einheiten zu erkennen Schwieriger verh lt es sich bei den Organisationseinheiten Rechnungspr fung Materialbestellung und Liefe rantenauswahl Hier bietet es sich an diese drei Bereiche zusammenzufassen zu einer Organisationseinheit Material und Bestellverwaltung 5 2 Aufbau des Grundmodells Lieferanten Vertrieb Auswahl Produkt entwicklung Wareneingangs Materialbestellung kontrolle Beschaffung Wareneingang Warenverbuchung Auftrags abwicklung Rechnungs f Warenreklamation pr fung Service Muster AG Unternehmens entwicklung Materiallogistik Finanz und Rechnungswesen Marketing Personal management Abbildung 5 10 Organigramm abgeleitet aus Kern Haupt und Unterprozessen Controlling Weiterhin ist die Unterteilung der Organisationseinheit Wareneingang in Warenein gangskontrolle Warenverbuchung und Warenreklamation nicht sinnvoll da sie eine zu feine Strukturierung und unn tige Abteilungsbildung verursachen w rde Eine berarbeitung f hrt zu der in Abbildung 5 11 dargestellten angepassten Struktur der Organisationseinheiten unseres Musterunternehmens Vertrieb Produkt i Material und Bestellverwaltung entwicklung Beschaffung Materiallogistik Auftrags abwicklung Wareneingang Service Muster AG Unternehmens entwicklung Finanz und Rechnungswesen Marketing Personal management Abbildung 5 11 Angepasstes Organigramm Controlling abgelei
160. ellen erhalten Sie eine lose Kopplung Der besondere Vorteil dieser Struktur liegt in der klaren Trennung der Inhalte bei gleichzeitiger loser Verkn pfung Auf diese Weise erhalten Sie ein Gesamt modell das sehr flexibel auf verschiedene Fragestellungen regieren kann Ein Modell mit dieser Grundstruktur kann einfach analysiert werden ohne auf Informationen anderer Inhaltsbereiche R cksicht nehmen zu m ssen Beispielsweise lassen sich Informationen ber den fachlichen Prozessablauf unabh ngig von dessen technischer Realisierung in einer Anwendungssoftware gewinnen l Prozess bersicht Wareneingang Fachliche Inhalte und detaillierte Prozessbeschreibung des fachlichen Prozesses Beschreibung der Warenverbuchung Fachliche IT Inhalte durch den Mitarbeiter im Lagerverwaltungssystem Informationstechnische Beschreibung der internen Verarbeitung einer Warenverbuchung in einem Lagerverwaltungssystem Inhalte Abbildung 2 4 Semantische Zuordnung von Inhaltstypen Gleichzeitig kann ber die lose Kopplung zu jeder Zeit aber zus tzliche Information hin zugef gt werden ohne dabei die saubere Trennung aufzuheben W rde man dagegen die fachlichen fachlichen IT und informations technischen Inhalte miteinander vermischen so w re eine automatisierte Trennung zu einem sp teren Zeitpunkt nicht mehr m glich Sie w rden dann die F higkeit verlieren Ihr Modell nach verschiedenen fachlichen und tech nischen Perspektiven auszuw
161. eller decken mit den genannten Werkzeugen fur die Modellierung komplementare Bereiche ab Bisher haben wir den Metamodellentwurf komplett werkzeugneutral erstellt damit er m glichst genau die fachlichen Anforderungen Ihrer Organisation abdeckt Das zugeh rige Modell selber erstellen und pflegen Sie aber nicht mit Papier und Bleistift Auch wenn dies grunds tzlich m glich w re so werden Sie zustimmen dass eine effizien te und kosteng nstige Modellierung und Auswertung des Modells dann nur schwer zu realisieren ist Sp testens jetzt kommt in jedem Modellierungsprojekt die Frage nach einem Werkzeug auf Ein wesentliches Kriterium bei der Auswahl eines Werkzeugs ist die Manipulierbar keit des zugrundeliegenden Metamodells In Kapitel 3 2 4 1 haben wir die Vor und Nach teile von offenen und geschlossenen Metamodellen erl utert Das geschlossene Metamo dell der Oracle BPA Suite bringt methodische Einschr nkungen mit sich denen wir bei der Umsetzung des werkzeugneutralen Metamodells gerecht werden m ssen Methodische Einschr nkungen der Oracle BPA Suite 98 Eine Methode beschreibt eine Vorgehensweise zur L sung einer Fragestellung oder eines Problems Die BPA Suite Methode legt fest w e die Struktur eines Modells erstellt und mit Inhalt gef llt werden kann Vereinfacht gesagt handelt es sich bei der eingebauten Methode um graphische Beschreibungsartefakte inklusive einer Anleitung wie diese ein gesetzt werden um Teile de
162. elung entstehen unternehmens weit Bausteine die einzeln verwendet wiederverwendet oder in Prozessen zu h herwerti gen Services ausgebaut werden k nnen siehe auch Kapitel 8 Die erste Herausforderung besteht 1m Finden der bestehenden Services Durch eine Ser viceidentifikation auf Grundlage der bestehenden Prozessmodelle k nnen bestehende Ser vices gefunden und als solche gekapselt werden Die Grundlage um Services unternehmensweit nutzen zu k nnen ist das Serviceportfolio Es erm glicht Konsumenten ben tigte Bausteine zu finden Der Erfolg einer SOA h ngt davon ab ob Services gefunden werden Die Serviceklassifikation und die Servicespezifi kation stellen bei der Serviceportfolioerstellung wichtige Schritte dar um potenziellen Konsumenten ausreichend Informationen ber die Services bereitstellen zu k nnen Hat ein Konsument einen Service gefunden findet er alle n tigen Informationen zur Nut zung des Service m Serviceportfolio Alle wichtigen Informationen sind im Portfolio hin terlegt oder referenziert 189 8 Der prozessgetriebene SOA Ansatz 8 1 Fragen die dieses Kapitel beantwortet E Was ist ein prozessbasierter SOA Ansatz E Welchen Mehrwert bieten Prozessmodelle und ein methodisches Vorgehen fiir die Ge staltung serviceorientierter Architekturen und umgekehrt E Wie h ngen Prozesse und Services aus fachlicher und technischer Sicht zusammen E Wie sieht ein m gliches Vorgehen f r die Modellier
163. eme Innerhalb des EA Modellteils werden Anwendungssysteme berblicksartig beschrieben Unterschieden wird dabei zwischen unternehmensweiten Softwaresystemen z B ERP Systemen die in der Regel mit ihren teilweise komplexen Architekturen genauer und Einzelplatzanwendungen z B WORD die meistens nur typisiert f r einen Unterneh mensbereich erfasst werden Infrastrukturen S mtliche Infrastrukturobjekte werden n der integrierten Modellierung im EA Modell bereich erfasst Dies schlie t sowohl die IT Infrastruktur z B Server und Netzwerke wie auch die nicht IT bezogene Infrastruktur z B Maschinen ein 2 3 2 3 Detaillierung des BPM Modellbereichs Gesch ftsprozesse Im BPM Modellteil werden zus tzlich detailliertere Beschreibungen der jeweiligen Pro zesse bis hin zu den fachlichen Funktionen und Aktivit ten erfasst Sie stellen das Herz st ck eines BPM Modells dar In der Praxis ist es jedoch strittig ob neben den fachlichen auch technische Funktionen wie zum Beispiel ausschlie lich durch ein IT System ausge f hrte Arbeitsschritte modelliert werden sollen Wir legen f r unsere Modellierung fest dass eine Beschreibung des fachlichen Verhaltens eines IT Systems z B die Bedienrei henfolge einer Maske noch Bestandteil des BPM Modellbereichs ist 23 2 Integrierte Modellierung fur EA BPM und fachliche SOA 24 Organisationsstruktur Die Organisationsmodellierung wird im BPM Modellteil um ausf hrlichere Beschreib
164. en kann Insbesondere bei zuk nftigen noch nicht existierenden L sungen stellt dies ein Problem dar Ein Modell unterst tzt uns an dieser Stele optimal wenn die oben aufgef hrten Eigenschaften w hrend der Erstellung ber cksichtigt wurden 1 3 Warum Standards und Regeln Der Maschinenbau ist seit mehr als 100 Jahren Vorbild einer gelungenen Standardisierung Normen schaffen dort die Plattform zur Kommunikation und versetzen uns weltweit in die Lage Wissen zu kombinieren Kann man das erfolgreiche Konzept der Maschinenbauer auf die Schnittstelle zwischen betriebswirtschaftlicher und technischer Standardisierung in der Informatik bertragen und wenn ja welche Konsequenzen ergeben sich daraus Die 1 4 Was Sie in diesem Buch finden IT Branche neigt dazu schnell in technischen Kategorien zu denken Als Beispiel aus dem Standardisierungsbereich m chten wir an dieser Stelle die UML anf gen welche zun chst zur technischen Modellierung von IT Systemen gedacht war und erst im sp teren Entwick lungsverlauf n her an die fachliche Modellierung heranger ckt ist Einige Leser werden anmerken dass die UML doch bereits von Beginn an fachliche Modellierungsfunktionali t ten wie z B die Use Case Beschreibungen angeboten hat Genau hier entsteht immer noch eines der gr ten Missverst ndnisse zwischen betriebswirtschaftlich und technisch orientierten Modellierern Die Modellierungswelten von Betriebswirtschaftlern unterschei den sic
165. en Bei der Modellierung der Detailprozessinstanz Ebene verfahren Sie analog Achten Sie darauf diese Ebene nur optional zu verwenden wenn Sie feststellen dass Sie zur eindeuti gen Beschreibung der fachlichen Hintergr nde eine weitere Detaillierung ben tigen 97 5 Das Grundmodell Lieferung antspricht nic Bestellung ieferungspositipn berpr fen j iefermenge ieferpositio iefermenge zu hoch falsch Zu gering Lieferung prufen Lieferung Lieferung entspricht dntspricht nich ieferpositio ist Teillieferu Lieferung R cklieferung berpr ft lachlieferung initieren areneingang gebucht QS Pr fung durchf hren Ware kontroll Auf weitere areneingangskontrolle Artikel pr fen abgeschlosse Detailprozess Alle Artikel eitere Artikel Wareneingangskontrolle zu pr fen 4 Instanzgranularitat Detailprozess Lieferungsposition prufen 5 Instanzgranularitat berpr ft Abbildung 5 8 Ereignisgesteuerte Prozesskette der 4 und 5 Instanzgranularit t ereignisgesteuerte Prozesskette 98 5 2 Aufbau des Grundmodells Tabelle 5 6 Inhalt und Abgrenzung der Detailprozessebenen 4 und 5 Instanzgranularitat Benennung der Name des bergeordneten Unterprozesses Die Benennung sollte als substantiviertes 4 und 5 Instanzgranularit t Verb erfolgen Beschreibung der fachlichen Aktivit ten die innerhalb des Unterprozesses anfallen Genutzte Objekttypen Ak
166. en Dazu wird zu jedem Anwendungssystem eine eigene Unterbibliothek angelegt Genutzte Anwendungssystemtyp Ein Anwendungssystemtyp beschreibt ein abstraktes Anwendungs Objekttypen system das zur betrieblichen Wertsch pfung eingesetzt wird Anwendungssystem Ein Anwendungssystem ist eine konkrete Auspr gung eines Anwen optional dungssystemtyps In der Regel kann ein Anwendungssystem eindeutig zum Beispiel mit Hilfe einer Lizenznummer identifiziert werden Modultyp Ein Modultyp ist ein abstrakter Bestandteil eines Anwendungssystem typs Die Modellierung eines Modultyps erfordert immer das Vorhan densein eines bergeordneten Anwendungssystems und von mindes tens zwei voneinander unabh ngigen dem Anwendungssystemtyp untergeordneten Modultypen Modul optional Ein Modul ist die konkrete Auspr gung eines Modultyps In der Regel kann ein Modul eindeutig identifiziert werden Maskentyp Ein Maskentyp beschreibt eine abstrakte Maske eines Anwendungs system oder Modultyps Maske optional Eine Maske beschreibt die konkrete Auspr gung einer Maske eines Anwendungssystems oder Moduls Abgrenzung Granularit t Erzeugen Sie f r jedes Anwendungssystem ein eigenes Bibliotheksdiagramm der auf den Diagrammen ausgepr gten Objekte Legen Sie fest ob Sie die Anwendungssysteme auf Typ oder Instanzebene beschreiben wollen Die Typenebene empfiehlt sich immer dann wenn Sie viele gleichartige Anwendungssysteme betrachten Dadurch verrin
167. en Letztere zur Entwicklung prozessunterst tzender L sungen Gleichzeitig stehen beide Beschreibungen aber n einem sachlichen Zusammenhang Jede Seite ben tigt Informationen des anderen Modellierungsbereiches wenn auch die EDV Abteilung n der Regel mehr Informationen von den Fachbereichen ben tigt als umge kehrt H ufig erstellen Fach wie auch IT Abteilung jedoch eigene Modelle ohne diese mitein ander abzugleichen Nur in seltenen F llen werden sowohl fachliche als auch technische Inhalte in einem Modell zusammengefasst Die Argumente beider Seiten warum das nicht erfolgt klingen hnlich E Die Unterschiede in der Beschreibung sind zu gro E Das Modell wird von der anderen Partei nicht verstanden Es steht nicht gen gend Zeit zur Verf gung um beide Sichten zu verbinden All das ist nicht neu und wir sind sicher dass Sie von einem oder mehreren dieser Argu mente auch in Ihrem Unternehmen geh rt haben Ein integriertes Modell bringt aber nicht nur Vorteile Um die positiven und negativen Aspekte integrierter und nicht integrierter Modellen abw gen zu k nnen zeigt Tabelle 2 1 die Vor und Nachteile beider Ans tze Tabelle 2 1 Vor und Nachteile eines integrierten nicht integrierten Modells S a Integriertes Modell Nicht integrierte Modelle Synergien durch Wiederverwert barkeit der Modellinhalte mittel bis langfristig Einsparungen im Modellmanagement gute Ausgangsbasis f r zuk nftige Erweiter
168. en Sie das Attribut wie geplant an Erweitern Sie die Erzeugen Sie eine Beziehung zwischen den betroffenen Entit ten im Metamodell Attributierung der betroffenen Entit t um die zus Information Ausnahmefall Abbildung 3 9 Vorgehensweise zur Auswahl der Entitatsattributierung im Metamodell Im vorliegenden Beispiel k nnten Sie sich sowohl f r als auch gegen die Abbildung einer neuen Beziehung entscheiden Sie erkennen an diesem Beispiel dass Sie bei der Attribu tierung der Entitaten des Metamodells immer das gesamte Metamodell im Blick haben m ssen Die in Abbildung 3 9 aufgef hrten Fragen weisen Ihnen bei der Attributierung des Meta modells den Weg Tabelle 3 7 zeigt die Argumente f r oder gegen eine Modellierung mit tels eines neuen Beziehungs oder Attributtyps 91 3 Aufbau des Metamodells Tabelle 3 7 Bewertung Beziehungs oder Attributtypmodellierung Erstellung eines neuen Inhaltliche Redundanzen bei Die Modellierung erfordert meh Beziehungstyps Entitaten und Attributen werden rere zusatzliche Arbeitsschritte vermieden zur Verbindung der betroffenen Entitaten Anlage eines eigenen Einfach Pflege direkt bei der Die Informationen des betroffe Attributtyps betroffenen Entitat m glich nen Attributes m ssen ggf an wodurch die Modellierung ver mehreren Stellen redundant einfacht wird gepflegt werden Auswertungen die sich auf den Inhalt des betroffenen Attributes beziehen sind unter Umst nden
169. en rep r sentieren innerhalb von IT Systemen Gesch ftsobjekte und sind im Kontext eines integ rierten EA BPM und SOA Modells ausf hrlicher zu modellieren als Gesch ftsobjekte 2 3 1 4 Anwendungssysteme Anwendungssysteme beschreiben Softwareprogramme die in einer direkten Interaktion mit einem fachlichen Benutzer stehen oder eine Aufgabe in einem fachlichen Prozess er f llen Sie dienen immer der Unterst tzung bzw Ausf hrung des wertsch pfenden Ge sch ftsprozesses Durch das Konzept der serviceorientierten Architekturen wurden neben klassischen Anwendungssystemen zus tzlich fachliche Services aufgenommen Sie be schreiben keine ber ein bestimmtes Softwareprogramm identifizierbare Anwendung mehr sondern stellen nur virtuelle IT Leistungen dar die einen wertsch pfenden Ge schaftsprozess informationstechnisch unterst tzen k nnen Dabei ist es weder erforderlich noch gew nscht die dahinter stehenden Softwarel sungen genau zu kennen Vielmehr dient das Konzept der Verschleierung der eigentlichen IT L sung und fokussiert nur auf die fachliche Aufgabenerf llung Zus tzlich zu den fachlichen Services finden wir technische Services Sie unterscheiden sich von fachlichen Services dadurch dass sie in keiner direkten Beziehung zum Wertsch pfungsprozess stehen sondern von fachlichen Services als Hilfsservices in Anspruch genommen werden 2 3 1 5 Infrastrukturen Die Beschreibung der Infrastrukturen umfass
170. en zu ermitteln Abbildung 9 8 gibt dazu einen berblick Instanziierung der Aktivit t Beendigung der Aktivit t Durchlaufzeit Vorliegezeit Techn R stzeit Bearbeitungszeit User Suspendzeit Benutzer w hlt Benutzer Aktivit t ist bereit zur Aktivit t suspendiert Benutzer Ausf hrung Aktivit t Aktivit t beendet wird auf die Arbeitsliste Benutzer kann Aktivit t der Benutzer gestellt Aktivit t Benutzer setzt bearbeiten Aktivit t fort Quelle zur M hlen 2003 Abbildung 9 8 M gliche Zustands berg nge einer Aktivit t Diese einzelnen Zeitintervalle werden auf der Ebene einer zu messenden Aktivit t fest gehalten und bilden einzeln oder aggregiert die Basis der Kennzahl Prozessdauer Modellierung des Prozess Controlling mit der Oracle BPA Suite Bislang haben wir uns recht detailliert mit der Definition eines Process Warehouse mit dem Begriff des Prozess Controlling den unterschiedlichen Anforderungen der beteiligten Rollen und sinnvollen Kennzahlen Typen f r das Process Controlling besch ftigt Und pr sentierten einen Architektur Blue Print der IT Systeme f r das Process Controlling Im n chsten Schritt gilt es die folgenden Objekte in Modellen transparent und zusammen h ngend zu pflegen E die Gesch ftsziele und abgeleiteten Kennzahlen E die zu steuernden Prozesse inkl ihrer Prozessmodelle 237 9 Entwurf und Aufbau prozessgetriebener Kennzahlensysteme E die Regeln zur Ermittlung der spez
171. enchmark Fachbegriffe 6 3 4 Sonden und 6 1 4 Rollen und Stellen Datenbewirtschaftung Fachliche bersichtsmodelle Fachliche Detailmodelle Fachliche IT Modelle Abbildung 9 10 Vorgehensweise bei der Modellierung 239 9 Entwurf und Aufbau prozessgetriebener Kennzahlensysteme Im Folgenden werden wir die einzelnen Schritte erlautern und die Modellierung in der Oracle BPA Suite beschreiben Wir folgen dabei der bereits ausf hrlich erl uterten Vorge hensweise Modelle ber fachliche Ubersichtsmodelle zu fachlichen Detailmodellen zu verfeinern um anschlie end die IT Modelle aus der fachlichen Sichtweise zu modellieren Vorbereitung Einen organisatorischen Rahmen schaffen Als Vorbereitung empfehlen wir einen organisatorischen Rahmen f r die Modellierung zu schaffen Im Navigator der Oracle BPA Suite f gen wir daf r eigene Strukturknoten zur bersichtlichen Gliederung der Process Controlling Modelle hinzu Abbildung 9 11 be schreibt eine Gliederung die sich an den Strukturen der vorangegangenen Kapitel orien li Informations I 1 technische Inhalte tiert I i l Fachliche i Fachliche i Inhalte i IT Inhalte 1 PYPAMIE NE roe l Fachliche l Inhalte Inhalte i l IT Inhalte m L I Controlling Process Gesch fts l f 1 i prozesse Controlling objekte l Dynamische Statische l i l Inhalte Inhalte l Controlling Process i z
172. end diese Informationen sammeln und persistent ab legen Damit die entsprechenden Analyse und Berichtsysteme performant und f r den Anwender verst ndlich sind m ssen die Informationen f r die jeweilige Zielgruppe aufbe reitet werden Schaffung eines Zusammenhangs zwischen den aktuellen Prozessdaten und den angesprochenen Gesch ftsobjekten Die aktuelle Prozessinstanz kennt n der Regel nur das Ablaufregelwerk der einzelnen Pro zessschritte und den aktuellen Status des Prozesses F r Analysen bzgl des Status der Pro zesse mag diese Information kurzfristig ausreichen F r weiterf hrende Analysen der Kos ten eingesetzter Produktionsmittel Ressourcen und beteiligter Organisationseinheiten m ssen Informationen der im Prozess angesprochenen Business Objekte gesammelt wer den Diese Informationen ben tigt man auch f r die Bildung von Dimensionshierarchien 229 9 Entwurf und Aufbau prozessgetriebener Kennzahlensysteme 230 Transformation Berechnung und Aggregation der Prozessdaten zu Prozessindikatoren Bei der Sammlung und Aufbereitung der Prozessdaten muss das IT System parallel die geforderten Kennzahlen ermitteln Diese Kennzahlen haben eine unterschiedliche Kom plexitat hinsichtlich der Aufbereitung Fur Kennzahlen zu Prozesskosten werden weitere Systeme als Quelle herangezogen Fur Kundenzufriedenheits Indikatoren im Zusammen hang mit den Prozessdaten wird man die Kennzahlen erst mit einem erheblichen zeitlichen Versatz
173. end ihrer methodisch festgelegten Semantik Passen Sie nur in begr ndeten Einzelf llen die Methode der Oracle BPA Suite an Im Zweifelsfall verzichten Sie auf die Abbildung eines methodisch nicht abbildbaren Teils des Metamodells 4 5 Vorgehensweise zur Ermittlung Ihrer individuellen Oracle BPA Suite Methode Start t Auswahl gt Entit t Beziehung Entitat Gruppe Ermittlung semantisch passender Symboltypen Nur ein oder kein Symboltypen mit passender vergleichbarer Symboltyp identifiziert rn Semantik pr fen Y Zwei passende Symboltypen identifiziert Ermittlung enes Alternative n Symboltyp en m gt gemeinsamen Ju gefunden Diagrammtyps Keinen gemeinsamen Diagrammtyp gefunden Alternative 1 Keinen passenden Diagrammtyp zur gemeinsamen Y Beziehungstyp Auspr gung gefunden gefunden Ermittlung eines semantisch passenden Beziehungstyps Alternative 2 Keinen passenden Beziehungstyp gefunden V Beziehungstyp zum semantisch passenden Ausdruck der erforderlichen Beziehung gefunden Keine n alternative n Symboltyp en gefunden Pr fung vorhandener Objektattribute Vorhandene Festlegung Modellattribute individueller Weitere nicht ausreichend Objektattribute Entit t Beziehung Entitat Gruppe bearbeiten Vorhandene Modellattrib
174. ene SOA Vorhaben noch nicht aus So muss unterneh mensintern eine einheitliche Definition geschaffen werden Mindestens vor Beginn des ersten SOA Vorhabens m ssen die Begriffe Service und SOA einheitlich definiert werden Im Idealfall gibt es eine unternehmens weite Definition Diese Definition muss f r alle beteiligten Mitarbeiter gelten und im Projektverlauf eingehalten werden um Reibungsverluste in der Kommunika tion zu vermeiden Um n diesem Buch Methoden und Ziele rund um SOA richtig einordnen und verstehen zu k nnen definieren wir zun chst einige grundlegende SOA Elemente 7 2 1 Was ist ein Service Ein Service kann aus zwei Perspektiven betrachtet werden der fachlichen und der techni schen Je nach Blickwinkel werden einem Service unterschiedliche Eigenschaften zuge schrieben Die folgenden Eigenschaften gelten allgemein f r jeden Service E Ein Service bietet einem Konsumenten einen Nutzen E Ein Service kapselt fachliche Funktionalit t Ein Service besitzt wohldefinierte Schnittstellen E Ein Service ist unabh ngig von Kontext und Struktur anderer Services E Ein Service ist wiederverwendbar Ein Service bietet dem Konsumenten einen Nutzen Ein Service bietet eine Leistung an Die Leistung wird von einem Konsumenten in An spruch genommen Der Nutzen liegt also auf Seiten des Konsumenten und nicht pr m r auf Seiten des Service Anbieters Diese Eigenschaft sorgt f r eine der gr ten H rden
175. ennzahlen einen klassischen Top down Ansatz damit wir die notwendige Ausrichtung neudeutsch Alignment der IT Systeme an den Geschaftszielen erreichen k nnen Als Beispiel modellieren wir folgende Anforderung Die Gesch ftsleitung will die operative Excellence erh hen und setzt als Ziel den Durchsatz bei der Wareneingangskontrolle WEK um 20 zu erh hen Als Kennzahl soll die durchschnittliche Prozessdurchlaufzeit dienen Hieraus leiten sich einige Erfolgsfaktoren In tiativen und Ma nahmen zur Erreichung der Ziele ab l Probleme in einer Prozessinstanz sollen schneller erkannt und behoben werden Pro cess Monitoring 2 Es soll die M glichkeit der Analyse des WEK geschaffen werden um Optimierungspo tenzial zu erkennen Process Mining 3 ber ein Dashboard sollen die relevanten Kennzahlen dargestellt werden um ber ein Benchmark f r die Verbesserungen beim WEK zu verf gen Prozess Cockpit f r einen Benchmark Wir empfehlen die in Abbildung 9 10 dargestellte Vorgehensweise f r die Modellierung der relevanten Inhalte f r das Process Controlling 6 1 Ziele und 6 2 Prozesse f r das 6 3 IT Systeme f r das Kennzahlen Process Controlling Process Controlling 6 1 1 Modellierung der acne ee Ziele Erfolgsfaktoren 6 2 1 Process Monitoring 6 3 1 Process Monitoring Noga nating QET 6 2 2 Process Mining 6 3 2 Process Mining Kennzahlenhierarchie ols mee erung ger 6 2 3 Process Benchmark 6 3 3 Process B
176. eorientierung dar Generell erfolgt jeder Zugriff auf implementierte Funktionalit t ber Services weshalb auch die Abbildung von IT Systemen m fachlichen IT Modell nicht erforderlich ist da deren Funktionalit t in Services gekapselt wird So weit die Theorie In Praxisprojekten zeigt sich jedoch h ufig dass die Unterscheidung zwischen automati schen und manuell ausgef hrten Prozessschritten f r die sp tere Umsetzung in der IT pragmatisch und z elf hrend ist Auch das Erg nzen des Modells um die IT Systeme die ihre Funktionalit t in Form von Services bereitstellen kann sinnvoll sein um einen besse ren berblick zu gew hrleisten oder Zusammenh nge zu verdeutlichen Beide Ans tze unterst tzt die Oracle BPA Suite durch entsprechende Objekte in der Modellierung 4 Web Services Description Language Schnittstellenbeschreibung f r Web Services im XML Format 8 3 Modellierung SOA geeigneter Prozessmodelle Technischer Kontrollfluss Der Kontrollfluss legt die Abfolge der Aktivit ten fest und kann wie im fachlichen De tailmodell beispielsweise sequentielle parallele und alternative Pfade enthalten Bei der Abbildung der Kontrollfl sse gilt es nun aber die F higkeiten der Prozessimplementie rungssprachen bez glich bestimmter Kontrollfl sse zu beachten H ufig lassen sich nicht alle in fachlichen Modellen z B EPK BPMN m glichen und erlaubten Kontrollfl sse auf die Implementierung in der IT z B BPEL bertragen Eine
177. er Detaillierung voneinander unterscheiden Anders verh lt es sich bei den Objekten der statischen Architektursicht Diese unterschei den sich meistens deutlich voneinander Aus Erfahrung kann man sagen dass f r ca zwei Drittel der Objekte einer Domain Level Matrix eine eigene Entitat im Metamodell anzulegen ist Achten Sie dabei auf eine m g lichst allgemeine Beschreibung der Entit ten insbesondere dann wenn Sie mehrere Ob jekttypen zu einer Entit t zusammenfassen Abbildung 3 7 zeigt die Gruppierung der Ob jekttypen unseres Beispiels zur Ableitung der Entit ten des Metamodells 3 F r unser Buch hat dieses neutrale Vorgehen eine weitere Bedeutung Da wir im Folgenden die Bei spielumsetzung der EA BPM und fachlichen SOA Modellierung anhand der Oracle BPA Suite zeigen die ein geschlossenes Metamodell besitzt ist es wichtig zu zeigen wie Sie mit eventuell auftretenden Konflikten bei der berf hrung eines neutralen Metamodells in ein Werkzeug mit geschlossenem Me tamodell vorgehen k nnen 3 2 Der werkzeugneutrale Modellentwurf Organisationseinheit Anwendungs Architektur Prozess Architektur Organisation Architektur Geschaftsobjekt Prozesse Unternehmen Hardwareressource Datenbank Aktivitaten Anwendungssystem Softwareressource Abbildung 3 7 Identifizierte Entitaten auf Basis einer vorhandenen Domain Level Matrix Beispiel Die Objekttypen Prozesse u
178. er Inhaltstypen uuuueeeeeeeeeeeeeeeeeeeeeeenenn 26 2 3 4 Dynamische und statische Unterteilung uuuueseeeeeeeseeeeeesseesesseneeeeeeneeeeeeeeeeennn 28 2 3 5 Horizontale und vertikale Unterteilung 0u0000sseeeeeeeeeeeeeeeeneeneneeneneneeneeeeeeenn 29 2 4 Z USammenlassuns este ee nee eier isst 30 3 Aufbau des Metamodells as EEE 33 3 1 Fragen die dieses Kapitel be ntworleliz es a teenies tate 33 32 Der werkzeusneulrale Modellentwurt 2 ae ist hie a 33 3 2 1 Modellierungsgrundsatze und deren Bewertung nnnnesenenenn 34 3 2 2 Ermittlung und Bewertung essenzieller Fragestellungen 37 Inhalt VI 4 1 4 2 4 3 4 4 4 5 4 6 Sl 5S2 6 1 6 2 6 3 6 4 6 5 7 1 T2 3 2 3 Entwurf einer Domain Level Matrix usssssseseeeseesesnnsssseeennnnnnnesennnnnnnnnensnnneennnnn 40 324 Erstellune eines Melamodelils ranira E RER 45 3 2 5 Absch tzung des Modellumfangs und Erstellungsaufwands n 53 Die Umsetzung des Metamodells z zuu00020000 n00nnnnnn nn en nnn non nun nn nn nennen 57 Fragen die dieses Kapitel beantwortet au 2u2uc hen E AA EE AAE 37 Die Oracle BPA Suite als Modellierungswerkzeug cccccccccccccccccceeceeeeeeeeeeeeeeeeeeeeeeeeeeeees a7 Methodische Einschr nkungen der Oracle BPA Suite sssssssssssssssnnnnnnnnnnnnnnnnnnnnnnnnnn 58 Analyse der Oracle BPA S
179. er Systeme 178 Serviceklassifikation 181 Serviceportfolio 170 Servicespezifikation 181 Servicestatus 183 SOA 153 156 im Prozessmodell 157 Nutzen 167 SOA Business Analyst 200 SOA Entwickler 201 SOA Grundkonzept 156 Softwareservice 213 Softwareservice Operation 213 Softwareservice Operationstyp 164 Softwareservicetyp 164 Standard 9 Standardisierung 9 Standardsoftware 118 Statische Frameworks 11 siehe auch Framework Statische Modellierung 28 Statische Objektbibliothek 99 Anwendungssystembibliothek 106 Gesch ftsobjektbibliothek 104 Infrastrukturbibliothek 110 Organisationsbibliothek 99 Symbol 60 Systemschnittstelle 134 Systemverhalten 121 T Technisches BPM 16 Technische IT 9 Technischer Service 198 TOGAF 12 U bersichtsmodell 163 Unterprozess 93 265 Register V Vertikale Dekomposition 80 Vertikale Modellierung 29 W Web Service 155 Workflow Patterns 205 Z Zachman 11 266 HANSER Enterprise Architecture Management 1m Griff y Hanschke Strategisches Management der IT Landschaft 343 Seiten ISBN 978 3 446 41702 1 EIN PRAKTISCHER LEITFADEN FUR DAS ENTERPRISE ARCHITECTURE MANAGEMENT Die IT spielt fur den Erfolg eines Unternehmens eine ganz entscheidende Rolle Nur wenn die IT Landschaft an den Business Zielen ausgerichtet ist kann ein Unternehmen erfolgreich im Markt agieren und auf die gro en Herausforderungen wie Globalisierung Fusionen und immer k rzere Innova tio
180. er einer Bestellung meistens klar identifizierbar durch eine Bestell oder Liefernummer Die zur Bearbeitung einer solchen Prozessinstanz erforder lichen Aktivit ten Lieferung pr fen Lieferungspositionen pr fen Wareneingang buchen und QS Pr fung durchf hren wurden im Rahmen eines Brainstormings ermit telt Abbildung 5 8 zeigt den zeitlich logischen Zusammenhang der Aktivit ten der 4 und 5 Instanzgranularitat Wichtig ist darauf zu achten dass sich jede beschriebene Aktivit t immer auf die Instanz des bergeordneten Prozesses oder der bergeordneten Aktivit t bezieht im Fall unseres Beispiels der Wareneingangskontrolle an der eingegangenen Gesamtlieferung An dieser Stelle d rfen Sie keine Beschreibungen in den Prozessfluss aufnehmen die sich nur auf einzelne Bestandteile der bergeordneten Prozessinstanz beziehen Es w re dem nach falsch eine Aktivit t Lieferposition zur cksenden bei einer nicht der Bestellung entsprechenden Lieferung in den Prozessfluss der betrachteten Ebene 4 aufzunehmen da sich diese nur auf einen Teil der Wareneingangskontrolle einer Gesamtlieferung beziehen wurde Diese feine Unterscheidung mag auf den ersten Blick akademisch wirken Da bei der Mo dellierung von Prozessen aber die Semantik eines Ablaufes so genau wie m glich be schrieben werden muss sind Sie an dieser Stelle gefragt sehr prazise zu arbeiten und Ihre Modellierung immer wieder kritisch zu hinterfrag
181. er lassen sich dabei nicht alle geforderten Inhalte des individuel len Metamodells abbilden In unserem Beispiel w hlen wir die in Abbildung 4 10 markierten Symboltypen Typ Be triebssystem und Typ DBMS 69 4 Die Umsetzung des Metamodells A Von A bis Z sortieren Von Zbis A sortieren Nach Farbe sortieren gt Ausgew hlte anes eu l Symboltypen f r die a umzusetzende Typ Anwendungssystem Metamodell Entit t Typ Betrebsmit Softwareressource Ciao om m Abbrechen Ermittlung eines gemeinsamen Diagrammtyps Abbildung 4 10 Selektion passender Methoden inhalte im Excel Filter Nachdem Sie f r die Entitaten des Metamodells passende Symboltypen ausgew hlt haben schlie en Sie das Filterauswahlmen Sie erhalten dann eine selektierte Liste der Dia grammtypen auf denen S e die gew hlten Symboltypen graphisch auspr gen k nnen F r unsere Bewertung sind nur jene Diagrammtypen relevant die alle selektierten Symbolty pen gemeinsam enthalten Dies ist eine notwendige Bedingung damit Beziehungen zwi schen diesen Objekten hergestellt werden k nnen Hinreichend ist sie aber noch nicht weshalb zur Ermittlung eines passenden Beziehungstypen Kantentypen weitere Pr fun gen der Methode erforderlich sind In dem gew hlten Beispiel enthalten die Diagrammtypen Matrixmodell Netztopologie Programmablaufdiagramm und Zugriffsdiagramm alle Symboltypen gemeinsam die rest lichen nicht
182. erden Ein m gliches Vorgehen w re 179 7 Identifizierung und Modellierung fachlicher Services fur SOA 1 Wir suchen eine Funktion in einem Prozess aus die ggf ein Servicebestandteil werden kann z B Nachlieferung initiieren 2 Wir suchen nach dem Muster lieferung mit der Einschr nkung nur Funktionen fin den zu wollen 3 Das Ergebnis stellt einen kleinen Ausschnitt des Unternehmens dar in dem wir ent scheiden k nnen welche Funktionen wir ggf zu einem Servicekandidaten zusammen fassen iol x Standard Abfrage Suche in LOCAL 20090405_Opitz BPA Suite Demo Model_finaliHauptgruppe A Suche nach Objekten M Typ Funktion Standardsymbol jedes Standardsymbol Name lieferung Y Attributfitter Y Inklusive Untergruppen Letzte nderung Gro HKleinschreibung beachten Yi Mit Mustervergleich Y Trennzeichen ignorieren Ergebnis 5 Objekte Name Typ Standardsymbol Gruppe lidentifizierer D Lieferungsposition berpr fen Funktion Funktion HauptgruppeW1_ D Lieferungspositionen pr fen Funktion Funktion HauptgruppeW1_ DO Nachlieferung initieren Funktion Funktion Hauptgruppe W1_ Nachlieferung pr fen Funktion Funktion Hauptgruppe v1 _ R cklieferung Funktion Prozessschnittstelle Hauptgruppe _ D R cklieferung pr fen Funktion Funktion Hauptgruppe wi _ D Teillieferung pr fen Funkt
183. erden Sie nicht um die individuelle Identifizierung und Abstimmung der Kernprozesse in Ihrem Unternehmen herumkommen Die folgenden Fra gen sind bei der Ermittlung der Kernprozesse hilfreich E Welche externen Ber hrungspunkte hat das Unternehmen mit Lieferanten und Kunden Diese Frage liefert Antworten bez glich der Schnittstellen Ihres Unternehmens zu Marktpartnern E Welche Leistungen bietet das Unternehmen in den Bereichen Innovation Produktion und Kundenbeziehungsmanagement Diese Frage liefert Antworten welche Gesch ftsobjekte Ihr Unternehmen mit seinen Marktpartnern austauscht 83 5 Das Grundmodell 84 E Durch welche besonderen Leistungen grenzt sich das Unternehmen von seinen Wett bewerbern ab Diese Frage gibt Auskunft ber Alleinstellungsmerkmale Ihres Unternehmens und identifiziert besonders wichtige primare Prozesse Grunds tzlich k nnen Sie davon ausgehen dass die prim ren Kernprozesse Ihres Unter nehmens immer bei einem externen Kunden beginnen oder enden Nur in wenigen Aus nahmen treten Kernprozesse auf die in keiner direkten Beziehung zu einem externen Kun den stehen Sollte eine gr ere Anzahl vermeintlicher Kerngesch ftsprozesse Ihres Unter nehmens diese Regel nicht erf llen ist es sehr wahrscheinlich dass entweder eine funktio nale Gruppierung oder bereits eine zu feine Prozessdetaillierung vorliegt Demgegen ber sind die sekund ren Kernprozesse eines Unternehmens in der Regel nicht direkt mi
184. eren einfach Als Business Analyst muss man sich dessen bewusst sein Die nachfolgenden Methoden werden dabei unterst tzen diese Herausforde rungen zu meistern 177 7 Identifizierung und Modellierung fachlicher Services fur SOA 178 Grundsatzliches Vorgehen der Identifikationsmethoden Die nachfolgenden Methoden haben etwas miteinander gemeinsam Sie schranken die Ge samtmenge der Informationen auf einen Ausschnitt ein der klein genug ist um ihn als Mensch erfassen zu k nnen Wie er gew hlt wird h ngt von der speziellen Methode ab Wurde er gew hlt werden innerhalb dieses Ausschnittes Servicekandidaten identifiziert Dabei m ssen im Anschluss an eine Ausschnittbetrachtung die Ergebnisse in ein Gesamt ergebnis in diesem Fall unser Serviceportfolio berf hrt bzw zusammengef hrt werden Letztlich muss bei jeder Methode eine kreative Eigenleistung erbracht werden Ein voll st ndig automatisiertes Vorgehen zur Serviceidentifikation existiert nicht Identifikation ber Namen Bei der Identifikation ber Namen machen wir uns die Konventionen zu Nutze mit denen das Prozessmodell erstellt wurde H ufig kann f r Funktionen die Namenskonvention Substantiv Verb gefunden werden z B Bestellung reservieren Nach beiden Begriffen kann man im Prozessmodell suchen Das Suchergebnis muss nun auf Servicekandidaten untersucht werden Geh ren die gefundenen Funktionen fachlich zusammen kann dies ein Servicekandidat sein Z B wu
185. ering Gap zu berbr cken Sehen wir uns noch einmal die bereits bekannte Abbildung 6 1 der horizontalen und verti kalen Modelldekomposition an so l sst sich der bergang zwischen der fachlichen Sicht und der IT Sicht zwischen den Ebenen 5 und 6 einordnen W hrend wir auf Ebene 5 also fachliche Sachverhalte darstellen bilden wir auf Ebene 6 die technische Unterst tzung der fachlichen Aktivit ten als Interaktion eines Benutzers mit einem IT System ab 119 6 Modellgest tzte fachliche Konzeption individueller IT Systeme 120 vertikale Dekomposition horizontale Dekomposition Kernprozesse Hauptprozesse Unterprozesse Prozessaktivit ten Prozessaktivit ten IT Aktivit ten IT Automatisie rungsobjekte generiert IT Automatisie rungsobjekte implementiert 5 6 3 5 20 40 optional 20 40 5 40 1 Instanzgranularit t Unternehmensinstanz 2 Instanzgranularit t Kernprozessinstanz 3 Instanzgranularit t Fachliche Hauptprozessinstanz bersichtsmodelle 4 Instanzgranularit t Unterprozessinstanz 5 Instanzgranularit t Detailprozessinstanz optional Fachliche Detailmodelle 6 Instanzgranularit t IT Interaktionsinstanz 7 Instanzgranularit t IT Prozessinstanz Fachliche IT Modelle 7 Instanzgranularit t implementierte 7 IT Prozessinstanz Ausf hrbare IT Modelle Abbildung 6 1 Horizontale und vertikale Dekomposition Durch die Orientierung an den relevanten
186. ermitteln da erst die Kundendaten erhoben werden m ssen Bereitstellung von Werkzeugen zur flexiblen multidimensionalen Analyse und Navigation innerhalb des Process Warehouse Das IT System muss neben der Bereitstellung der konsistenten Daten auch die Werkzeuge zur Analyse bereitstellen Unterschiedliche Akteure werden unterschiedliche Auswertungs Tools nutzen Dies geht ber Monitoring und Alerting Cockpits f r eine Near Real Time berwachung bis hin zu Tools die die qualitativen Datenanalysen in Sinne des Data Mining unterst tzen um verborgene Wirkungsketten zu erkennen Verteilung Pr sentation und Verwertung der Analyseergebnisse Die Analyseergebnisse sind f r eine Vielzahl von Beteiligten in der Organisation relevant Die spezifische Pr sentation und Verteilung legt die Nutzung von Prozessportalen oder entsprechenden Portalen angereichert mit Prozessauswertungen nahe 9 4 2 Rollen Als N chstes betrachten wir die unterschiedlichen Rollen im Rahmen des Process Control ling Jede Rolle hat unterschiedliche Anforderungen an die Process Controlling Kompo nente des Process Warehouse Diese Rollen wollen wir n das Modell mit einbeziehen um organisatorische Zust ndigkei ten und auch notwendige System seitige Zugriffsbeschr nkungen zu implementieren Im Folgenden werden die wesentlichen drei Rollen mit ihren Anforderungen beschrieben E Top Management Senior Management bzw der C Level E Prozess Owner Abte
187. erten Kein Algorithmus der Welt k nnte diese Leistung heute erbringen Achten Sie bei dem Entwurf Ihres integrierten Modells unbedingt auf eine Trennung der fachlichen Inhalte fachlichen IT Inhalte und technischen Inhalte Daraus ergeben s ch einige Anforderungen an ein integriertes Modell E Die Modellstruktur f r alle drei Inhaltstypen muss eindeutig und redundanzfrei festge legt werden Damit kann jeder Inhalt eindeutig einem der Modellbereiche zugeordnet 27 2 Integrierte Modellierung fur EA BPM und fachliche SOA 28 werden Die doppelte Ablage gleicher Inhalte in mehr als einem Modellbereich ist nicht zul ssig E Die Schnittstellen zwischen den einzelnen Inhaltstypen sind klar zu definieren Es m ssen Regeln festgelegt werden die den bergang beschreiben und Vorgaben zur Abbildung enthalten Auf diese Weise wird sichergestellt dass die Verbindung zwi schen den einzelnen Inhalten im gesamten Modell immer auf die gleiche Art erfolgt Es ist klar festzulegen welche Inhalte die Modellstruktur aufnehmen kann Dadurch definiert man welche Inhalte im Modell abgebildet werden k nnen und welche nicht mehr Bestandteil des integrierten Modells sind 2 3 4 Dynamische und statische Unterteilung Die Unterscheidung zwischen Statik und Dynamik beruht auf einem unterschiedlichen zeitlichen Verhalten Dynamische Inhalte beschreiben das zeitlich logische Verhalten eines Prozesses Ziel einer dynamischen Modellierung ist es di
188. erungen damit verbun den sind geht zum Teil aus dem bisher Gesagten hervor Hier geben wir Ihnen noch ein mal einen berblick ber Nutzen und Herausforderungen 173 7 Identifizierung und Modellierung fachlicher Services fur SOA 174 Nutzen E Wiederverwendbarkeit wird erh ht Nur was gefunden werden kann l sst sich auch wieder verwenden Eine saubere Do kumentation aller Services im Serviceportfolio macht die Wiederverwendung m glich Reduzieren von Redundanzen Services werden nur neu implementiert wenn sie noch nicht existieren Auf diesem Wege wird auch verhindert dass eigentlich gleiche Leistungen unterschiedlich imple mentiert werden Dieses Ph nomen kann h ufig in gro en Unternehmen beobachtet werden in denen abteilungstibergreifende Absprachen schwerfallen z B die Berech nungen von Kennzahlen E Reduzieren des Engineering Gaps Fachliche und technische Services sind uber das Serviceportfolio verbunden Beide gro en Interessengebiete haben Zugriff auf die gleichen Informationen und beide pfle gen diese Informationen weiter E Das Portfolio kann bei der Entscheidungsfindung zu Services unterst tzen Durch die einheitliche Dokumentationsform und die Serviceklassifikation k nnen Ser vices miteinander verglichen werden Die Vergleichbarkeit erleichtert Managementent scheidungen zu Services Herausforderungen Mehr Beteiligte mehr Anforderungen mehr Aufwand an Service Wiederverwendbarkeit und Reduz
189. erungsrele vante Informationen in modellbasierter Form zur Verf gung zu stellen 8 3 Modellierung SOA geeigneter Prozessmodelle Vor dem Modell Konzeption und Planung Ein sinnvolles und zielf hrendes Vorgehen bei der Modellierung der serviceorientierten Prozesse erfordert eine strukturierte Vorbereitung Welche Aspekte dabei betrachtet wer den sollten wird zun chst allgemein erl utert und dann konkret mit Beispielen definiert Im Rahmen einer strukturierten Vorbereitung bei der Modellierung der serviceorientierten Prozesse sollten die in Abbildung 8 2 gezeigten Schritte beachtet werden Begrifflichkeiten definieren und klar o Zielgruppen ermitteln abgrenzen o Rollen und Glossar erstellen Zust ndigkeiten abgrenzen e Informationsbedarf der Zielgruppen ermitteln Begrifflich Informations oe Aa bedarf Meihocik und Vorgehen definieren abgrenzen festlegen ermitteln e Zielsetzung beschreiben und festlegen Methodik f r die SOA Modellierung __ Vorgehen erarbeiten definieren 0 Notation f r die SOA Modellierung ausw hlen Abbildung 8 2 Konzeption und Planung serviceorientierter Prozessmodellierung 8 3 1 Begrifflichkeiten definieren Was genau ist der Unterschied zwischen einem fachlichen und einem technischen Service Muss ein Service im Sinne einer SOA immer eine technische Implementierung in der IT haben Und was ist ein Servicekandidat Bei der Diskussion einer methodischen Vorge hensweise im Proje
190. erwendeten tech nischen Services Unterscheidet 1 d R zwischen vollautomatisch ablaufenden und manuellen Pro zessschritten Die detaillierte Prozessbeschreibung eines fachlichen Service wenn dieser IT tech nisch umgesetzt wird E Ausf hrbares IT Modell Ein von einer Process Engine ausf hrbares Prozessmodell Der Ebene 7 Ausf hrbare IT Modelle der vertikalen Prozessdekomposition s Abbildung 8 3 zuzuordnen In einer ausf hrbaren Prozesssprache modelliert bzw implementiert z B BPEL XPDL diverse propriet re Formate Verwendet z B orchestriert technische Services zur Erbringung seiner Leistung E Fachlicher Service Business Service Beschreibt eine Dienst Leistung im Unternehmen ber das Serviceportfolio vgl Kapitel 7 durch potenzielle Konsumenten auffind bar und nutzbar Kann IT technisch realisiert vgl Zielsetzung und Vorgehen dieses Kapitels oder rein fachlicher Natur sein also aktuell manuell erbracht werden Wird im Vorgehen dieses Kapitels als fachliches IT Modell spezifiziert und als aus f hrbares IT Modell umgesetzt Wird im fachlichen Prozess als Service auf Ebene 4 bzw 5 Fachliche Detailmo delle der vertikalen Prozessdekomposition s Abbildung 8 3 an die Prozessmo delle modelliert Kann mehrere F higkeiten bzw Operationen zu einem Fachgebiet bereitstellen 3 XML Process Definition Language der Workflow Management Coalition http www wfmc org 197 8 De
191. es Durchsetzung von Standardapplikationen Unternehmens bergreifende Nutzung ew hrleistung einer guten Bedien von Informationen und Anwendbarkeit Abbildung 3 1 Auswertungsvorschlag der Modellierungsgrunds tze Beispiel 36 3 2 Der werkzeugneutrale Modellentwurf In unserem Beispiel liegen die Schwerpunkte der Teilnehmer in den nachfolgenden Berei chen m Informationsmanagement Unternehmens bergreifende Nutzung von Informationen Etablierung von Standards im Informationsmanagement m Standardisierung Durchsetzung von Standardapplikationen Etablierung von Standards im Informationsmanagement m Betriebsorganisation Klare Zuweisung technischer Verantwortlichkeiten Sicherstellung eines kontinuierlichen Geschaftsbetriebs Auf den ersten Blick mag Ihnen die Auswertung trivial erscheinen Sie liefert aber einen nicht zu untersch tzenden Startpunkt f r die strukturelle und inhaltliche Ausrichtung Ihres integrierten Modells und hilft dieses zu fokussieren um zielgerichtet Auswertungen lie fern zu k nnen Im dargestellten Beispiel muss das integrierte Modell besonders auf die Bereiche Informa tionsmanagement Standardisierung und Betriebsorganisation ausgerichtet werden Das bedeutet dass im Rahmen der weiteren Detaillierung der Modellteilinhalte Informationen zu den oben genannten Schwerpunkten zwingend enthalten sein m ssen Au erdem gelingt es Ihnen mit dieser Fokussierung die am Entwurfsprozess beteiligte
192. es m glichst flexibel genutzt werden kann Grunds tzlich k nnen die Inhalte eines Modells nach E den Artefakttypen denen sie zugeordnet sind E der semantischen Zuordnung E ihrem dynamischen oder statischem Charakter sowie E der horizontalen und vertikalen Einordnung typisiert und unterschieden werden 2 3 Grundsatzliche Gliederung eines integrierten Modells 2 3 1 Artefakttypen der Modellierung Enterprise Architecture BPM und die fachliche SOA Modellierung befassen sich vielfach mit ahnlichen Informationsinhalten Zum Beispiel benotigt der Informatiker zur Umset zung eines IT Projekts Informationen ber die fachlichen Zusammenh nge f r die er eine passende L sung erstellen soll Der Business Analyst muss diese fachlichen und techni schen Informationen ermitteln und beschreiben und das Management muss n der Lage sein diese in die gesamte Unternehmensstrategie einzuordnen und zu bewerten Fachliche Informationen m ssen deshalb so dokumentiert werden dass sie kommuniziert und von den Beteiligten auf Management Fach und EDV Abteilungsseite verstanden werden Welche Informationstypen sind dabei besonders wichtig Als Erstes fallen Ihnen bestimmt Gesch ftsprozesse und Objekte der realen Welt ein Im Umfeld einer kombinierten EA BPM und SOA Modellierung sind dies Organisationsein heiten und Rollen Gesch ftsobjekte und Daten Anwendungssysteme sowie fachliche und technische Dienste und zuletzt Infrastrukturen Sowohl da
193. ess Controlling ist die Steigerung der Anpassungsfahigkeit des Unternehmens an Ver nderungen in der Um und Innenwelt Dieses bergeordnete Ziel wird im Folgenden nicht weiter vertieft Wir konzentrieren uns auf die wesentlichen operativen Ziele Das Process Controlling wird betrachtet E als wesentlicher Bestandteil des Prozessmanagements und E als Lieferung von Analysen und Daten zur Sicherstellung dass die Unternehmenspro zesse effizient ausgef hrt und die zur Verf gung stehenden Ressourcen effizient ge nutzt werden Im Folgenden leiten wir aus Aufgaben des Process Controlling die Anforderungen fur die unterst tzenden IT Systeme ab In Abschnitt 9 7 greifen wir diese Anforderungen im Rahmen der Modellierung auf 9 4 1 Anforderungen an die IT Systeme Die wesentlichen Anforderungen an ein Process Warehouse siehe auch Definition des Process Warehouse als die Beschaffung Aufbereitung und Speicherung von Daten in einem IT System die f r die Aufgaben des Process Controlling ben tigt werden lassen sich hieraus ableiten und decken sich mit den folgenden Funktionen Beschaffung Sammlung und Aufbereitung der aktuellen Prozessdaten Das IT System muss in der Lage sein die aktuellen Prozessinstanzen zu kennen Insbe sondere bedeutet dies dass die Informationen zum Prozess Status und den Daten zu den behandelten Business Objekten aus den Quellesystemen beschafft werden m ssen Die Datenbewirtschaftung muss anschlie
194. ess Service als Abfolge von Schritten n Form eines Prozesses darge stellt werden kann Dar ber hinaus besteht die ausdr ckliche Zielsetzung diesen Service technisch zu implementieren und als IT Komponente zur Verf gung zu stellen 8 3 2 2 Zusammenhang und Hierarchie der SOA Modelle Abbildung 8 4 verdeutlicht diese Zusammenh nge und stellt das methodische Vorgehen dieses Ansatzes grafisch dar Die einzelnen Schritte dieses Vorgehens die dabei genutzten Modelle und ihre Details werden n den n chsten Abschnitten vorgestellt Im fachlichen Detailmodell werden an diejenigen Prozessschritte die von Services unterst tzt sein sol len fachliche Services modelliert Diese fachlichen Services werden jeweils als Prozess spezifiziert und anschlie end n der IT in BPEL XPDL o umgesetzt Die ersten bei den Schritte dieses Vorgehens die Erstellung des fachlichen Detailmodells und des fachli chen IT Modells sind Fokus dieses Kapitels Zwischen diesen beiden Modellen verl uft dar ber hinaus auch die Grenze zwischen den Zust ndigkeiten der Rollen SOA Business Analyst und SOA Entwickler zum Rollenverst ndnis vgl Abschnitt 8 3 3 Fachliches Detailmodell Fachlicher Service Business Service Fachliches IT Modell Bu y Technischer Service WSDL Rolle Business Analyst Rolle SOA Entwickler Ausf hrbares IT Modell l BPEL XPDL I wird in diesem Buch nicht betrachtet l Abbildung 8 4 Methodisches Vo
195. essdurchlaufzeit bei der WEK berechnen Bei der Modellierung m ssen wir nun beginnend beim WEK Prozess dem ent sprechenden Ereignis einen Event Symbol b Attribut ERM zuweisen Dieses ist als der Ausl ser f r die Aktivierung der Sonde zu verstehen welche die ben tigten Daten ext rahiert Wir nutzen das Zugriffsdiagramm um die Sonde mit dem Event in Beziehung zu setzen Anschlie end weisen wir dem Anwendungssystem die benutzten Sonden zu Sonden im WEK Sonde X 16 15 ETL Systeme EPK Zugriffsdiagramm Anwendungssystemtypdiagramm areneingang Lieferung pr fen ur wesen Sonde X1 5 ETL Systeme Gi Lieferung So nd e n ntspricht nicl Bestellung Lieferungspositionen pr fen Sonde X1 5 Lieferung berpr ft amp nn Sonde X1 6 areneingan gebucht Sonde X1 6 QS Pr fung durchf hren ah in Wareyleingangskoktrolle abgeschlosse Abbildung 9 26 Modellierung der ETL Systeme und Sonden 257 9 Entwurf und Aufbau prozessgetriebener Kennzahlensysteme 9 8 Abbildung 9 26 beschreibt die Zusammenh nge der Sonden im WEK Prozess mit den IT Komponenten bei den ETL Systemen durch ein Zugriffsdiagramm welches die Start Ende Events des Prozesses den entsprechenden Sonden zuordnet Durch unsere Vorarbeit k nnen wir nun die Sonde mit der Kennzahl verkn pfen und damit die fachlichen Anforderungen f r die Implementierung der
196. essern a LE Optimierungspotenziale werden an das Prozessdesign bergeben Hier erfolgen Modellie rung bzw Reengineering des Prozesses anschlie end die Implementation des Prozesses in der Organisation Dies hat neben den organisatorischen Konsequenzen auch technische Implikationen hin sichtlich der unterst tzenden IT Systeme Das Process Controlling hat nun die Aufgabe Daten zu liefern die Entscheidungen zur Verbesserung von Gesch ftsprozessen unterst t zen Hiermit schlie t sich der Regelkreis des Geschaftsprozessmanagements Process Monitoring Das Process Monitoring und seine Umsetzung mittels IT L sungen h ufig auch Business Activity Montoring BAM genannt wird bewusst vom Process Mining abgegrenzt Das liegt zum einen daran dass das Process Monitoring die aktuelle Prozessinstanz betrachtet und das Process Mining eine Analyse der abgelaufenen Prozesse ist Der zeitliche Bezug der Nutzung ist hier ein wichtiges Kriterium f r den Aufbau der ben tigten IT Syste me und der Implementierung von unterst tzenden organisatorischen Strukturen und Prozessen Definition Process Monitoring Die Aufbereitung von Kennzahlen und Darstellung von Daten f r die Leistungs messung und die Beobachtung des zeitlich aktuellen Ablaufgeschehens von Prozessen Die technische Implementierung von IT L sungen zur Abbildung der Process Monitoring Funktionen wird blicherweise als Business Activity Monitoring BAM bezeichnet Somit ergib
197. essinstanz Aus den Anforderungen an das Process Controlling bzw den ben tigten Kennzahlen leiten sich die ben tigten Dimensio nen ab In Abbildung 9 24 sind einige typische Dimensionen z B Organisationseinheiten Rollen Zeit Produkt Artikelhierarchien Produktions Standorte und Klassifizie rung von Prozessen Aktivit ten zu Gruppen Typen aufgef hrt Weitere Dimensio nen lassen sich aus der Struktur der unterlagerten Business Objekte bei Bedarf bilden 9 7 3 3 Modellierung des IT Systems zum Process Benchmarking Eine weitere Ma nahme war ber ein Dashboard sollen die relevanten Kennzahlen darge stellt werden damit man ein Benchmark f r die Verbesserung hat Diese Ma nahme l sst sich ber ein Prozess Cockpit umsetzen das in der Regel eine Teilkomponente des beste henden Unternehmensportals ist In diesem Cockpit muss eine Teilkomponente Ampel Tacho existieren welche den Wert des KPI zum Status des WEK transparent darstellt Wie Abbildung 9 25 zeigt modellieren wir das IT System Prozess Cockpit WEK als einen Anwendungssystemtyp Durch diese Modellierung k nnen wir diese IT Komponente zur Darstellung der Kennzahl bei der fachlichen Modellierung an einer anderen Stelle wie derverwenden man k nnte dies auch als einen oberfl chenlastigen Service verstehen Process Benchmark Anwendungssystemtypdiagramm Process Benchmark Process Cockpit WEK Abbildung 9 25 Modellierung des IT Systems
198. essmodell m ssen S e ber die Form der Notation hinaus festlegen wie Sie Inhalte nach ihrer Semantik gegliedert ablegen Im Bereich der Prozessarchitektur m ssen f r die IT neutrale Modellierung beispielsweise Kernprozesse Hauptprozesse Unterprozesse und fachliche Detailprozesse als weitere Unterteilung der Entit t Prozess ber cksichtigt werden Gleiches gilt f r die anderen Architekturebenen und Entit ten des Meta Modells 79 5 Das Grundmodell 80 Diese Struktur aufzubauen ist vor Beginn der inhaltlichen Modellierung zwingend erfor derlich In Kapitel 2 wurden zur Strukturierung eines integrierten Modells die folgenden Kriterien definiert E die semantische Einordnung E die dynamische oder statische Einordnung E die Artefakttypen E die horizontale und vertikale Einordnung Wie in Kapitel 2 3 1 erl utert ist die eindeutige und semantisch berschneidungsfreie Zuordnung von Artefakttypen nur schwer m glich Um aber die Ordnung 1m Repository zu gew hrleisten m ssen Sie festlegen wo welche Inhalte abgelegt werden Wir ordnen deshalb jeden Artefakttyp des integrierten Modells als Vorschlag einem der drei Bereiche fachliche fachliche IT und informationstechnische Inhalte zu Es ist uns bewusst dass zu einigen Artefakttypen auch Argumente f r eine andere Zuordnung vorliegen Betrachten Sie unsere Einteilung deshalb als Vorschlag den Sie innerhalb Ihres Modells durchaus variieren k nnen 5 2 1 Ermittlung der bersich
199. essorientierten Beschreibung erfasst werden kann Ausnahmen bilden meistens nur kleine Bereiche der sekund ren Kernprozesse wie zum Beispiel detaillierte Bilanzierungsabl ufe in der Finanzbuchhaltung oder ITIL basierte Wartungsprozesse in Rechenzentren Genauso verh lt es sich mit Gesch ftsobjekten die durch sekund re Kern prozesse erstellt oder bearbeitet werden Ein Beispiel daf r sehen wir bei der Modellierung der Personalressourcen Selbstverst ndlich nehmen alle Kernprozesse des Unternehmens Personalressourcen ab Ob die Modellierung dieser Beziehung jedoch sinnvoll ist sei da hingestellt Sekundare Kernprozesse folgen nur zu einem kleinen Teil einer festen prozess orientierten Struktur Vielmehr handelt es sich bei ihnen h ufig um individuelle Abl ufe Welche Gesch ftsobjekte und Beziehungen Sie innerhalb Ihres Modells den sekund ren Kernprozessen zuordnen m ssen Sie individuell festlegen Beachten Sie dabei unbedingt den Modellierungskontext Ihres Gesamtmodells Im Zweifel gilt hier weniger ist mehr Bitte betrachten Sie die von uns vorgestellte Prozesslandkarte nur als Beispiel f r die Ge staltung in Ihrem Unternehmen Es gibt keine allgemein verbindliche Vorgabe die an die ser Stelle auf jedes Unternehmen passt Vielmehr ist es wichtig dass Sie bei der Erstellung Ihres Prozessmodells eine f r Ihre Fragestellung angemessene L sung finden Die in den Tabellen 5 2 5 4 und 5 5 genannten strukturellen Vorgaben sollten Sie so
200. est wie Sie die Inhalte horizontal und vertikal 1m betrachteten Modellbe reich einordnen Die Regeln zur horizontalen und vertikalen Einordnung erl utern wir in den folgenden Kapiteln n her 31 3 Aufbau des Metamodells 3 1 Fragen die dieses Kapitel beantwortet m Wie identifizieren Sie den individuellen Fokus Ihrer Modellierung m Wie stellen Sie die unterschiedlichen Anforderungen an ein integriertes Modell kom munizierbar dar m Welche typischen Fragestellungen soll Ihr integriertes Modell beantworten m Wie strukturieren Sie Ihre Fragestellungen f r den Metamodellentwurf m Welche Beziehungen bestehen zwischen verschiedenen Fragestellungen die Ihr Modell beantworten soll m Wie entwerfen Sie ein werkzeugneutrales Metamodell m Wie k nnen Sie den Modellierungsaufwand Ihres Modells grob absch tzen 3 2 Der werkzeugneutrale Modellentwurf Das Konzept einer Enterprise Architecture ist nicht neu Bereits in den achtziger Jahren wurden die grundlegenden Ideen zum Enterprise Architecture Management unter anderem von John Zachman beschrieben Heute erh lt das Konzept im Zusammenhang mit Busi ness Process Management und SOA neue Bedeutung Die Existenz einer Enterprise Archi tecture wird h ufig als Voraussetzung f r ein erfolgreiches Business Process Management und die SOA Einf hrung gesehen Egal ob Sie nur eine Enterprise Architecture erstellen oder diese mit einem BPM oder SOA Modellteil verbinden m c
201. estaltung einzelner Modellierungsaspekte k nnen Sie damit vor allem eine redundanzfreie Beschreibung verschiedener Modellierungsszenarien erreichen AUS DEM INHALT Integrierte Modellierung f r Enterprise Architecture BPM und fachliche SOA Aufbau des Metamodells Die Umsetzung des Metamodells Das Grundmodell Modellgest tzte fachliche Konzeption individueller IT Systeme Identifizierung und Modellierung fachlicher Services f r SOA Der prozessgetriebe ne SOA Ansatz Entwurf und Aufbau prozessgetriebener Kennzahlensysteme ist Direktor f r Strategie und Innovation und ist gesch ftsf hrender Gesellschafter bei der OPITZ CONSULTING GmbH l und sind Berater beim gleichen Unternehmen www hanser de computer ISBN 978 3 446 41735 9 783446417359 Business Analysten Unternehmensplaner IT Architekten Entwickler 9 Systemvoraussetzungen f r eBook inside Internet Verbindung Adobe Acrobat Reader Version 6 oder 7 kompatibel mit Windows ab Windows 2000 oder Mac OS X Ab Adobe Reader 8 muss zus tzlich der eBookreader Adobe Digital Editions installiert sein
202. et die nebeneinander existieren und unterschiedliche Zielsetzungen verfolgen 9 3 Die zentralen Begriffe E das Process Monitoring mit dem Ziel der operativen Steuerung der aktuell ablaufen den Gesch ftsprozesse und E das Process Mining mit dem Ziel der Ex post Analyse der abgelaufenen Gesch fts prozesse Diese Zusammenh nge werden in Abbildung 9 1 dargestellt Das Process Controlling mithilfe von IT Systemen ist eine neue Disziplin Dies erkennt man leider daran dass es n der Literatur keine allgemein g ltigen Begriffsdefinitionen gibt Im Folgenden definieren wir die zentralen Begriffe entsprechend ihrer Verwendung im vorliegenden Kapitel 9 3 1 Process Controlling Process Controlling Definition Process Controlling Beschaffung Aufbereitung und Analyse von Daten zur Vorbereitung zielsetzungs gerechter Entscheidungen zur Verbesserung von Gesch ftsprozessen Riep96 Im Folgenden sollen die Komponenten des Process Controlling kurz erl utert werden E Die Beschaffung besch ftigt sich mit der Erschlie ung Evaluation und Auswahl der ben tigten Datenquellen Hierbei stehen letztlich die Prozessmodelle und repositories die Datenquellen der operativen Anwendungssysteme sowie die Audit Trails Log Files der eingesetzten Workflow oder BPM Engines Oracle BPEL Process Manager IBM SAP Inubit etc im Mittelpunkt Die Aufbereitung erfolgt unter Einbeziehung der Metadaten aus den Prozessmodellen in Form eines
203. et Process Controlling und legt den Schwerpunkt auf die Modellierung der ben tigten Kennzahlen auch hinsichtlich der An forderungen f r eine Implementierung Unterwegs geben wir einige praktische Tipps und Best Practices um den Einstieg in die Modellierung zu vereinfachen Das genutzte Vorge hen bei der Modellierung lehnt sich an die in Abbildung 9 2 dargestellten unterschiedli chen Ebenen der Modellierung an Wir beschreiben das Vorgehen bei der Modellierung der Ziele Ma nahmen Kennzahlen und der Organisation Anschlie end verfeinern wir die Modelle f r die eigentlichen Prozesse zur Etablierung der organisatorischen Ma nahmen beim Process Controlling Abschlie end erfolgt die Modellierung der notwendigen IT Sys teme zur Unterst tzung der Prozesse des Process Controlling horizontale Dekomposition Kernprozesse Hauptprozesse Unterprozesse 20 40 Prozessaktivit ten optional 20 40 Prozessaktivit ten IT Aktivit ten IT Automatisie rungsobjekte generiert IT Automatisie rungsobjekte implementiert N wi 5 6 3 5 5 40 _ Instanzgranularit t Unternehmensinstanz 2 Instanzgranularit t Kernprozessinstanz 3 Instanzgranularit t Hauptprozessinstanz 4 Instanzgranularit t Unterprozessinstanz 5 Instanzgranularit t Detailprozessinstanz optional 6 Instanzgranularit t IT Interaktionsinstanz 7 Instanzgranularit t IT Prozessinstanz 7 Instanzgranularit t implementierte IT Proze
204. ethodik beachtet werden Individuelle Attributtypen las sen sich ohne jede Beeintr chtigung erg nzen Die semantische Qualit t der Umsetzung eines individuellen Metamodells in die Oracle BPA Suite kann man ausschlie lich durch die Abdeckung passender Symbol und Beziehungstypen bewerten Zur Beurteilung der Qualit t der semantischen berf hrung des Metamodells in die Oracle BPA Suite bewerten Sie jede abzubildende Entit t Beziehung Entit t Gruppe Ermitteln Sie den Abdeckungsgrad zwischen den tats chlich abbildbaren und den geplanten Informa tionstypen War zum Beispiel geplant innerhalb der Metamodell Entitat Softwareressource die fol genden Softwarekomponenten DBMS Betriebssystem Servicebus und Webserver zu be schreiben so erlaubt die ausgew hlte Oracle BPA Suite Methode nur die Modellierung der ersten beiden Softwareressourcen Der Beziehungstyp kann laufen auf entspricht vollst ndig der gew nschten Semantik nutzt Die semantische Abdeckung graphisch ausgepr gter GA Entit t Beziehung Entit t Gruppen berechnet sich dann aus den Symboltypen ST und den verf gbaren Beziehungs typen BT r echo Adak GA gt semantisch passende ST gt semantisch passende BT x 100 en in semantisch erforderliche ST semantisch erforderliche BT i Die semantische Abdeckung implizit modellierter IM Entit t Beziehung Entit t Gruppen berechnet sich aus den ermittelten Hinterlegungen HL und den
205. eutralen Modellierung zentral zu erfassen Dabei unterscheiden wir nicht zwischen physischen Objekten wie zum Beispiel Material oder nicht physischen Objekten w e zum Beispiel Informationen Im Rahmen der Modellierung der ersten drei Ebenen wurden zu den Kern Haupt und Unterprozessen die sie verbindenden Gesch ftsobjekte identifiziert Die Gesch ftsobjekte 104 Instanz granularitat 1 Instanz granularitat 2 Instanz granularitat 3 max 12 KP x max 6 HP x max 5 UP x 4 GO je UP 5 2 Aufbau des Grundmodells der ersten drei Modellierungsebenen m ssen dabei keine hierarchische Struktur bilden Vermeiden Sie die Gesch ftsobjekte auf den ersten drei Ebenen bereits nach hierarchi schen Kriterien oder ihrer physischen Auspr gung n der realen Welt auszurichten Es st durchaus erw nscht auf den ersten drei Modellierungsebenen eine Mischung aus Objekten zu haben die entweder physikalische Ressourcen oder Informations Ressourcen beschrei ben Die Ebenen 1 bis 3 dienen ausschlie lich der groben Strukturierung Ihres Modells Es w re falsch bereits an dieser Stelle zu versuchen eine genaue Trennung der statischen Inhalte herbeizuf hren Betrachten wir dazu nochmals das Beispiel der Wareneingangs kontrolle Diese erzeugt sowohl das Gesch ftsobjekt Wareneingangsprotokoll und bear beitet das Gesch ftsobjekt Material Wenn wir davon ausgehen dass das Warenein gangsprotokoll als physisches Objekt zum Bei
206. eziehungstypen enthalten sein so m ssen Sie in der Oracle BPA Suite Methode nach anderen Objekttypen mit vergleichbarer Semantik suchen und die Metho denanalyse wiederholen Alternative 2 in Abbildung 4 7 Pr fung vorhandener Objektattribute Abschlie end pr fen S e zu den gew hlten Symboltypen die m Standard vorhandenen Attributtypen Dazu nutzen Sie wieder die Excel Analysedatei Wie Sie in Abbildung 4 1 erkennen sind Attributtypen der Oracle BPA Suite nicht direkt den Symboltypen sondern den Objekttypen zugeordnet Aus diesem Grund m ssen Sie zun chst herausfinden wel che Objekttypen sich hinter den gew hlten Symboltypen verbergen Betrachten Sie dazu auf dem Arbeitsblatt Symboltypen der Excel Analysedatei die letzte Spalte vgl Abbildung 4 6 Dort wird Ihnen der zugeh rige Objekttyp zu jedem Symbol typ angezeigt Wahlen Sie anschlie end den Reiter Objektattributtypen und selektieren Sie die ermittel ten Objekttypen In unserem Beispiel k nnen die in Kapitel 3 2 4 2 f r die Metamodell Entit t Hardware ressource festgelegten Attribute Name Beschreibung und Hersteller direkt mit Standard attributen abgebildet werden Die Attribute Gew hrleistung bis Betriebsphase Start und Betriebsphase Ende mussen individuell erzeugt werden weshalb eine Erweiterung des Oracle BPA Suite Metamodells um diese Attribute vorzunehmen ist Abbildung 4 13 zeigt die Liste der verf gbaren Attributtypen zum Objekttyp Hardwarekompo
207. fenem Metamodell Offenes Anpassbar an die individuellen Erfordert mehr Know how bei der Metamodell Informationsbedurfnisse einer Einfuhrung Organisation Einf hrungsphase ist mit zusatz lichem Aufwand zur Metamodell anpassung verbunden Geschlossenes Schnelle Einsetzbarkeit Je nach Einsatzszenario ist mit Ein Metamodell schrankungen bei der Informations abbildung zu rechnen Ruckgriff auf Know how des Herstellers ohne zusatzliches Consulting Aufbau einer vollstandig eigenen Hersteller unabhangigen Modellie rungsmethodik nur sehr einge schrankt moglich Um zu verhindern dass Ihr Metamodellentwurf bereits durch die Einschrankungen eines Werkzeuges beeinflusst wird behalten wir die werkzeugneutrale Betrachtung zun chst bei So stellen Sie sicher dass Sie bei dem Entwurf Ihres Metamodells die bestm gliche Be antwortung Ihrer essenziellen Fragestellungen im Auge behalten Betrachten Sie zun chst die Domain Level Matrix und fassen Sie in jeder Architektursicht Objekttypen gleicher Gattung zu einer Entitat zusammen Objekttypen gleicher Gattung erkennen Sie daran dass unabhangig von ihrer jeweiligen Detaillierung alle zugehorigen Objekttypen mit Hilfe eines gemeinsamen Satzes an Attributen eindeutig beschrieben wer den k nnen Beispielsweise geh ren die Objekttypen der Prozessarchitektur h ufig zu derselben Gat tung Es handelt sich in der Regel um Beschreibungen von Arbeitsablaufen die sich ledig lich n hr
208. fs oder von Bildschirmmasken nicht sinnvoll ist Es ist auch durchaus denkbar dass der Fachbereich selbst bei der Konzep tion einer Individuall sung keine konkreten Anforderungen an eine bestimmte Verarbei tungsreihenfolge ein bestimmtes Maskenlayout oder eine konkrete Programmlogik hat In diesen F llen gen gt es den sp teren Anwendern wenn das System eine bestimmte Funktio 127 6 Modellgest tzte fachliche Konzeption individueller IT Systeme 128 Beschreibt die Benutzerrolle die den Verarbeitungsschritt durchf hren darf Beschreibt die Maske Benutzerschnittstelle auf der der Verarbeitungsschritt durchgef hrt wird Beschreibt die Maske Eingabedaten zu dem FunktiGN Verarbeitungsschritt Fachbegriff et Stellt einen Verarbeitungsschritt Beschreibt ein anderes im Systemablauf dar Anwendungssystem zu dem nz eine Schnittstelle besteht Funktion Dieser Verarbeitungsschritt die in diesem Verarbeitungs wird automatisch durch das schritt verwendet wird ber System durchgef h rt daher ist keine Benutzerrolle anmodelliert Typ Anwendungs Maske Funktion Fachbegriff Abbildung 6 3 Beispiel eines Systemablaufs nalitat zur Unterst tzung einer fachlichen Aktivit t bereitstellt Die muss nat rlich in je dem Fall ausreichend beschrieben sein Diese Situation kann insbesondere in F llen auftre ten in denen ein Fachbereich neue Prozesse durchf hren muss bei deren Durchf hrung er noch keine b
209. fwand der Modellierung berschaubar zu halten und eine wirtschaftliche Modellie rung durchzuf hren empfiehlt sich ein pragmatischer Ansatz Hinterfragen Sie immer wieder ob zur Modellierung vorgesehene Informationen wirklich ben tigt werden In der Praxis findet man h ufig Modellierungsans tze bei denen Informationen erfasst werden die im aktuellen Projektkontext gar nicht relevant sind Das erh ht den Aufwand ohne einen Mehrwehrt zu bieten 8 3 4 1 Informationsbedarf des SOA Business Analysten Die Aufgaben die der SOA Business Analyst im Rahmen SOA Modellierung wahrnimmt beginnen auf der vierten Ebene mit den fachlichen Detailmodellen vgl Abbildung 8 3 Die dar ber liegenden bersichtsmodelle sind grunds tzlich f r unsere Zielsetzung optio nal Dies bedeutet dass die SOA Modellierung durchaus mit den operativen Prozessketten begonnen werden kann Die Analyse der dar berliegenden Wertsch pfungsketten n die sich diese Prozesse einordnen empfiehlt sich dennoch Auf diesem Wege lassen sich die Modelle in den Unternehmenskontext einordnen sowie bereichs und dom nen bergrei fende Prozesse Services und deren Abh ngigkeiten darstellen Im g nstigsten Falle wer den diese Modelle bereits durch das integrierte Enterprise Architecture Vorgehen vgl Kapitel 2 vorgegeben Der SOA Business Analyst entwirft zun chst ein fachliches SOA Prozessmodell Dieses Vorgehen ist weitgehend identisch mit der Modellierung allgemeiner fachl
210. g von Benutzerrollen gilt es darauf zu achten dass Goaisaionsentet 1 Goaisaionsentet 2 Systemrolle 1 qrsisatonsite 3 Stelle Systemrolle 2 Abbildung 6 10 Rollenzuordnung ein Beispiel 135 6 Modellgest tzte fachliche Konzeption individueller IT Systeme 136 neben den an der fachlichen Systemfunktionalit t orientierten Rollen ggf auch Adminis tratorrollen ben tigt werden zu deren Aufgaben bspw Benutzerverwaltung oder Stamm datenpflege geh ren 6 3 4 6 Datenbeschreibung Wie bereits erw hnt werden bei der Modellierung des Systemablaufs f r jeden Verarbei tungsschritt auch die be und verarbeiteten Ein und Ausgabedaten dargestellt Diese Daten lassen sich nun aus fachlicher Sicht n her beschreiben Die Art der Beschreibung muss auch hier vom jeweils aktuellen Kontext und den aktuellen Anforderungen abh ngig ge macht werden und kann von einer kurzen fachlichen Beschreibung ber eine einfache Dar stellung der Zusammenh nge zwischen verschiedenen Daten siehe Abbildung 6 11 bis hin zu einem vollst ndigen Datenmodell z B ERM Entity Relationship Modell rei chen Wichtig sind Unterscheidungen zwischen Stammdaten die an zentraler Stelle ge pflegt und von dort in das System bernommen und im Systemablauf bearbeitet oder erst erstellt werden Angaben zum ben tigten Format und bestehenden Abh ngigkeiten zwi schen Daten s nd ebenfalls eine hilfreiche Information f r den Realisierer An dieser Ste
211. ganz neuen Prozessen verwendet werden Sind Services auch eigenst ndige Systeme kann z B eine Wartung oder Erweite rung aufgrund der geringeren Abh ngigkeiten schneller erfolgen E Reduktion von Medienbriichen Durch die weitestgehend standardisierten Protokolle in der IT k nnen Prozesse leichter miteinander verbunden werden Die Papierschnittstelle l sst sich einfacher abl sen Durch weit verbreitete Sicherheitsmechanismen ist es auch m glich ber Unternehmensgrenzen hinweg Prozesse zu verbinden oder Leistungen anderer Un ternehmen in eigenen Prozessen zu nutzen Die Reduktion von Medienbr chen ist eine Voraussetzung zur Prozessautomatisie rung Transparenter Prozessstatus auf Basis von BPEL Business Process Execution Langua ge Durch die deutlichen Ahnlichkeiten zwischen Fachprozess und IT Prozess wird der realisierte Prozess f r Fachbereiche transparenter Der Prozessfluss und der aktuelle Prozesszustand einer Prozessinstanz kann leichter eingesehen werden E Erleichterung von Prozesskostenrechnung controlling und Abrechnungsmodellen Es ist transparenter welcher Prozess welche Leistungen in Anspruch nimmt Die Verwendung eines Service kann ggf direkt einer Kostenstelle zugeordnet wer den Services k nnen als Einheiten hinsichtlich ihrer Kosten betrachtet werden Die Einzelkosten der Services k nnen zu einer Gesamtkostenrechnung des Prozes ses verwendet werden Kennzahlen f r das Controlling lassen
212. ge in einer Analyse freundlichen Datenstruktur siehe Einschub 9 4 Multidimensionale Datenmodelle f r das Process Warehouse 2 Das interaktive und oberflachenlastige System ftir das Ad hoc Reporting bzw die Ana lyse der Daten nach den unterschiedlichen Dimensionen Slice and dice bzw Pivo tierung der Daten zur Analyse nach unterschiedlichen Sichten Das bergreifende Blue Print haben wir bereits in Abschnitt 9 4 beschrieben und ein Muster definiert Somit k nnen wir nun gegen dieses Muster modellieren Process Mining Anwendungssystemtypdiagramm Process Mining Import und Transformation Star Schema Analyse System Abbildung 9 23 Modellierung eines IT Systems zum Process Mining Tabelle 9 15 Benutzte Methodenobjekte der Oracle BPA Suite Modellname Process Monitoring Diagrammtyp Anwendungssystemdiagramm Symbol Typ Anwendung Typ Modul F r eine eingehende Beschreibung und Vorgehensweise f r die Modellierung der fachli chen Anforderungen an ein IT System m chten wir auf das Kapitel 6 dieses Buches ver weisen Multidimensionale Datenmodelle fur das Process Warehouse Die Datenmodellierung fur das Enterprise Modell des Process Warehouse ent spricht im Wesentlichen den gangigen Modellierungskonventionen fur multidimen sionale Datenmodelle Star Snowflake Schemata in einem Data Warehouse oder Data Mart Anders als bei klassischen OLTPZ lastigen Anwendungssystemen steht hier die Ab
213. gert sich Ihr Modellierungsaufwand In den meisten F llen ist eine Modellierung auf Typenebene ausreichend Modellieren Sie entsprechend Ihrer Wahl die typisierten oder instanziierten Unterstrukturen Modultypen oder Module und Maskentypen oder Masken Die Modellierung der Anwendungssystemlandschaft innerhalb der Oracle BPA Suite er folgt im Grundmodell unter Verwendung der beiden Diagrammtypen Anwendungssystem typen und Zugriffsdiagramm Das Anwendungssystemtypendiagramm enth lt Informationen zu der ggf vorhandenen Modulstruktur und den verf gbaren Masken des betrachteten Systems Legen Sie f r jedes Anwendungssystem ein eigenes Diagramm an Abbildung 5 17 zeigt ein vereinfachtes Anwendungssystemtypendiagramm zur Beschreibung des Einkaufssystems Procurement XT 108 5 2 Aufbau des Grundmodells ocurement umfasst umfasst Bestellung Alareneingahlg suchen Bestellung P Teil lieferung umfasst A umfasst 1 ieferante I ie nagemen i umfasst eklamatian R Reklamation 2 umfasst hL Abbildung 5 17 Modellierung eines Anwendungssystems Anwendungssystem typendiagramm WW WWE Zus tzlich zur Modellierung der Module und Masken eines Anwendungssystems k nnen im Rahmen der Erstellung der Anwendungssystembibliothek noch die technischen Bezie hungen eines Anwendungssystems modelliert werden Die Oracle BPA Suite bietet auf grund des geschlossenen Metamodells keine M glichkeit u
214. gew nschten Report auszuw hlen Abbildung 4 3 Aktivieren Sie den Report Filterinformationen ausgeben und dr cken Sie Weiter 4 4 Analyse der Oracle BPA Suite Methode fe Oracle Business Process Architect 11gR1 l loj x Datei Bearbeiten Ansicht OA Auswerten Hilfe D G amp S ed EGS 8 EAT A Administration Navigation en Oracle BPA Suite Netzwerk om E vslwhol036 opitz consutting int 3 Auswahlen Konfiguration Gesamtmethode n El Konventionen a Filte Y SOA Filter iter enth lt alle Methodentilter Y Oracle BPA Filter Dies ist der offizielle Fil Methodenfitter f Gesamtmethade alle Methodeninhatte si Methodenfilter Y Business i L schen Entf Fiter enth t alle Methodenriter CA Umbenennen F2 u PA Abfragen E P Auswertungen JAusw hi n Duplizieren 8 Dokumert Manal Konventionen Filter Bearbeiten E ls Publizieren j Exportieren Matrizen H Integriertes EA BPM SOA Modell a Z_Sandkasten Auswerten Report starten Administration 1 Auswahlen des 4 Auswahlen a Moduls Administration Auswerten Report starten Skripte Q Simulation Abbildung 4 2 Erstellung einer Methodenanalysedatei in der Oracle BPA Suite x Schritte Hilfe 1 Report w hlen 1 Report w hlen Kategorie Alle Reporte gt Report Fitterinformationen ausgeben el Methodeninhalte des Process Generator aktualisieren 2 Ausgabeeinstell
215. gt ressource Abbildung 4 8 Individuelles Metamodell mit ausgew hlter Entit t Beziehung Entit t Gruppe Ermitteln Sie einen semantisch passenden Objekttypen mit Hilfe der erstellten Excel Analysedate Aktivieren Sie dazu das Tabellenblatt Symboltypen ffnen den Filter der Spalte Symboltyp und w hlen einen semantisch passenden Symboltyp f r die umzusetzen de Metamodell Entit t aus In unserem Beispiel w hlen wir Typ HW Komponente f r die Entit t Hardwareressource Abbildung 4 9 Anschlie end suchen Sie einen passenden Symboltyp f r die zweite Entitat der ausgewahl ten Entit t Beziehung Entit t Gruppe des Metamodells In unserem Fall st die Suche nach einer Softwareressource nicht erfolgreich Diesen Symboltyp stellt das Oracle BPA Suite Modell nicht zur Verf gung Deshalb m ssen wir pr fen ob ein Symboltyp mit vergleich barer Semantik 1m Oracle BPA Metamodell existiert Im vorliegenden Fall m chten wir mit 4 5 Vorgehensweise zur Ermittlung Ihrer individuellen Oracle BPA Suite Methode a Eai i Aa F In ttandard Fe E Ei ee E gt Y j A4 shin OF g EO A BESSERES a a ee ee A Yon bis Z sortieren B man tome 4 i Els 2 5 IE DE en P a Yon 2 bis A sortieren 1 Modelltyp Symboltyp ZBjekttyp Hach Farbe sortieren i 2 fi Anfondeg 2 V
216. h die F higkeiten und Fachbegriffe um die Servicezuord nung zu erleichtern Die aufgef hrten Schritte k nnen verschiedenen Phasen zugeordnet werden die wiederum von unterschiedlichen Rollen siehe auch Abbildung 7 6 durchgef hrt werden Teilweise kann auch parallel gearbeitet werden Beispiele daf r zeigt Tabelle 7 1 Tabelle 7 1 Phasen und Rollen in der Servicemodellierung Phase Ablauf T1 Ablauf T2 Ablauf T3 Ablauf T4 Servicemodellierung Schritte 1 2 Rolle Business Analyst Servicekonkretisierung Schritte 3 4 5 Rolle Business Analyst Softwareservicemodellierung Schritte 6 7 8 9 Rolle Architekt Fach IT Verkn pfung Schritt 10 Rolle Architekt Servicenutzung Schritte 11 12 Rollen Fachbereich Business Analyst Defizite in der BPA Suite Die BPA Suite bietet die M glichkeit alle relevanten Informationen zu modellieren Schw chen zeigt sie jedoch bei ihrer Verkn pfung Es gibt keine Diagramme die eine bersicht ber alle servicerelevanten Informationen bieten Sollen alle Informationen ver kn pft werden muss ber viele verschiedene Diagramme gesprungen werden Theoretisch ist eine Verkn pfung mit Objekten auf der Ebene der fachlichen IT Modelle mit Objekten der ausf hrbaren IT Modelle m glich Der Pflegeaufwand die detaillierten technischen Informationen mit anderen Modellinhalten zu verkn pfen ist sehr hoch und steht ohne das Ziel ausf hrbare Prozesse zu generieren in keinem akzept
217. h erheblich von denen der Informatiker Diese Unterschiede haben in der Vergangenheit zu interessanten Diskussionen und noch unterhaltsameren Meetings gef hrt in denen Fachbereich und IT vollst ndig aneinander vorbeiredeten Wir sind uns sicher dass jeder Leser eine Anekdote dazu beisteuern kann Konnte man sich bei der Entwicklung von Modellierungsstandards in der Vergangenheit noch relativ einfach von diesem Missverst ndnis l sen in der Regel am effizientesten realisiert durch Ignorieren der anderen Bereiche so ist dieser machiavellistische Ansatz auf beiden Seiten heute nicht mehr tragfahig Eigentlich ist er nie tragf h g gewesen zu nehmend erkennen aber beide Seiten dass es von Vorteil w re besser miteinander zu kommunizieren Die Verbesserung der Kommunikation ist das Ziel der Standards und Regeln zur Modellie rung innerhalb dieses Buches 1 4 Was Sie in diesem Buch finden Das vorliegende Buch stellt eine Methode zum Aufbau eines integrierten EA BPM und fachlichen SOA Modells vor Es betrachtet allgemeine Inhalte die unabh ngig von einem Modellierungswerkzeug eines bestimmten Herstellers verwendet werden k nnen um ein integriertes Modell zu erstellen und zeigt deren Umsetzung am Beispiel des Werkzeuges Oracle BPA Suite Weite Teile k nnen Sie analog mit dem ARIS Business Architect der IDS Scheer AG realisieren Lediglich die automatisierungsrelevante Modellierung ist auf die Oracle BPA Suite beschrankt Die
218. halb genau festlegen welche Inhalte zu welchem Modellbereich EA BPM und fachliches SOA geh ren Orientieren Sie sich bei der Zuordnung von Inhalten in Ihrem Gesamtmodell immer an den folgenden Kriterien E Der Enterprise Architecture Modellteil beinhaltet die abstrakte berblicksartige Be schreibung einer Organisation oder Unternehmung Es werden im Wesentlichen Zu sammenh nge und Abh ngigkeiten im groben berblick dargestellt Eine Detailmodel lierung einzelner Aspekte erfolgt nicht E Der BPM Modellteil fokussiert auf das Ablaufverhalten und die T tigkeiten der Wert sch pfung in der betrachteten Organisation oder Unternehmung Es wird im Einzelnen beschrieben wie eine T tigkeit durchgef hrt wird Dabei werden auch die beteiligten Ressourcen betrachtet Unterschieden werden Modelle mit ausschlie lich fachlichem und informationstechnischem Inhalt E Der SOA Modellteil dient zur Beschreibung der Inhalte die man zum Entwurf zur Implementierung und zum Betrieb einer SOA L sung ben tigt Er richtet sich grund s tzlich immer an den Dokumentations und Beschreibungsanforderungen einer SOA aus Abbildung 2 3 zeigt wie die drei Modellbereiche im integrierten Gesamtmodell aufeinan der aufbauen EA Modellteil fachliche Modellinhalte BPM Modellteil fachlicher SOA Modellteil Modellinhalte informations technologische Abbildung 2 3 Unterteilung des integrier Umfang des Modellbereichs ten M
219. he durch alle an den Ergebnissen der Modellierung interessierten Gruppen die Einschr nkungen akzeptiert werden Metamodell in der vorliegenden Form nicht nutz bar Eine berarbeitung kann ggf eine Verbesse rung bringen Metamodell grunds tzlich nicht nutzbar Die Oracle BPA Suite ist mit hoher Wahrschein lichkeit nicht geeignet die Modellierungsfrage stellungen abzubilden 77 5 Das Grundmodell 5 1 Fragen die dieses Kapitel beantwortet Welche Inhalte werden im Grundmodell erfasst Wie erfolgt die vertikale und horizontale Strukturierung im Modell Wie unterteilt man die fachliche Prozesshierarchie im Modell Wie gliedert man die Organisationsmodellierung Welche Struktur ist zur Modellierung von Gesch ftsobjekten sinnvoll Wie modelliert man die Basis zur Applikationsbeschreibung Welchen Umfang sollte eine Infrastrukturbeschreibung im integrierten Modell erhal ten Wie organisiert man die Ablage der Modellinhalte in der Oracle BPA Suite 5 2 Aufbau des Grundmodells Nachdem Sie das Metamodell erstellt den zu erwartenden Aufwand zu dessen Fullung bestimmt und Ihre Oracle BPA Suite Methodik eingerichtet haben beginnen Sie mit dem Aufbau der Grundmodellstruktur Beispielsweise haben wir zur Abbildung der Prozessar chitektur des Metamodells in der Oracle BPA Suite die Diagrammtypen Wertsch pfungs kette und Ereignisgesteuerte Prozesskette festgelegt siehe Tabelle 4 1 und 4 2 Fur ein integriertes Proz
220. hlinstanz M th d i h It Anforderungszuordnungsdiagramm Klasse Anwendungssy etnogeninnalte e Anforderungszuordnungsdiagramm Klasse HVV Komponente VV Komponentenkiasse Anfarderungszuordnungsdiagramm Netz Netzwerk Anforderungszuordnungsdiagramm Netzkante Netzkante 4 pere Seg er Netzkantenklasse r i 4 a Abbildung 4 6 Excel Analysedatei mit ausgewahlten Arbeitsblatt Symboltypen Mit Hilfe des Filteranalysereports k nnen Sie detaillierte Auswertungen der Oracle BPA Suite Methode und daraus abgeleiteter Teilmengen ausgeben Wir empfeh len die Darstellung als Excel Datei Das Excel Format erlaubt die individuelle Filte rung und Darstellung der Methodeninhalte Sie haben sich mit der durchgefuhrten Methodenanalyse ein einfaches aber wirkungsvolles Werkzeug erstellt das neben dem Metamodellentwurf auch fur weitere Fragestellungen im Umfeld des Einsatzes der Oracle BPA Suite verwendet werden kann Vorgehensweise zur Ermittlung Ihrer individuellen O racle BPA Suite Methode 66 Um ein individuell entworfenes Metamodell in die Oracle BPA Suite zu bertragen m s sen Sie m glichst genau die passenden Methodeninhalte ermitteln Wir empfehlen dass Sie die folgenden Kriterien zur Erstellung eines transparenten und leicht zu pflegenden Metamodells unbedingt beachten Verwenden Sie so wenig Diagrammtypen w e m glich Nutzen Sie die verf gbaren Diagrammtypen Symboltypen und Beziehungstypen so genau wie m glich entsprech
221. hnlich wie ein Telefonbuch hilft das Verzeichnis dabei den aktuellen Service unter der aktuellen Schnittstelle mit seinem aktuellen Funkti onsumfang zu finden Man betrachtet das Verzeichnis haufig als Teil eines Serviceportfo lios siehe auch Abschnitt 7 3 Im Verzeichnis k nnen rein fachliche Services in der IT realisierte fachliche Services und rein technische Services gefunden werden Das Service portfolio hat noch umfassendere Aufgaben die Abschnitt 7 3 1 beschreibt 7 2 6 Services in der BPA Suite In diesem Abschnitt stehen wir am Anfang der Modellierung von Services in der BPA Sui te Wir beginnen mit den grundlegenden Fragen zur Servicemodellierung E Wie wird ein Service in der BPA Suite modelliert E Welche Modelle und Objekte ben tigt man E Wie stehen Services mit Prozessen in Verbindung Eine Eigenschaft von Services besteht dar n fachliche Funktionalit t zu kapseln Ein Ser vice bietet somit verschiedene Leistungen an hnlich ist es mit vielen Technologien Weil sich Web Services als De facto Standard durchgesetzt haben wird in diesem Kapitel ein Web Service als technische Realisierung angenommen Ein Web Service kann mehrere Operationen besitzen Die Operationen stellen somit eine Leistung des Web Service dar Beide Informationen die fachlichen und technischen lassen sich im Modell abbilden und miteinander verkn pfen bersichtsmodelle Fachliche Ausf hrbare CIM PIM PSM i Fachliche De
222. hten Sie sollten Ihr Modell grunds tzlich zun chst werk zeugneutral entwerfen Ziel ist es den Informationsbedarf Ihrer Organisation zu ermitteln ohne sich bereits in dieser fr hen Phase durch die Restriktionen eines Werkzeuges einzu schr nken Auf diese Weise erhalten Sie ein Metamodell welches zun chst ausschlie lich den fachlichen Bedarf Ihrer Organisation an ein integriertes Modell darstellt Nat rlich ist 33 3 Aufbau des Metamodells 34 in einem spateren Arbeitsschritt das ideale Metamodell an die Moglichkeiten des einzuset zenden Werkzeuges anzupassen Dies geschieht dann in einem Prozess der vorhandene werkzeuginduzierte Einschrankungen klar aufzeigt Sollten Sie sich noch nicht auf ein Modellierungswerkzeug festgelegt haben k nnen Sie mit dem beschriebenen Vorgehen auch diese Auswahl gezielter angehen 3 2 1 Modellierungsgrunds tze und deren Bewertung Bevor S e mit der Erstellung des integrierten Modells beginnen m ssen S e sich einige grunds tzliche Gedanken ber Ihre Modellierung machen Es ist immer wieder erstaunlich wie viele Unternehmen eine Modellierung beginnen ohne ber die Ziele und Fragestellun gen des Modells nachzudenken Um diesen Fehler zu vermeiden m ssen Sie zun chst festlegen wo Ihnen das Modell hel fen soll Betrachten Sie die Sichten Business Application Information und Infrastructu re Achitecture als Ausgangspunkt Zu jeder dieser Sichten formulieren Sie Grunds tze die zur
223. ibute Freitext dienen zur freien Erfassung von Informationen und bieten Ihnen den gr ten Spielraum bei der Formulierung von Inhalten zu einem Objekt bei spielsweise zur ausf hrlichen Beschreibung eines Prozesses m Wertattribute Wertelisten um einem Attribut vordefinierte Werte zuzuweisen Da bei handelt es sich um Wertelisten aus denen ein einzelner Wert einem Attribut zuge ordnet werden kann Nummerische Attribute Ganzzahl und Flie kommazahl um zu einem Objekt quan titative Spezifikationen anzulegen beispielsweise zur Beschreibung der Speicherkapa zitat ener Hardwareressource E Wahrheitsattribute um richtige oder falsche Aussagen zu einem Objekt zu hinterle gen beispielsweise zur Beschreibung des Status aktiviert deaktiviert einer Hardware ressource m Datums und Zeitattribute um Informationen ber das zeitliche Verhalten eines Ob jektes zu hinterlegen beispielsweise das Aktivierungs und Deaktivierungsdatum einer Hardwareressource E Verweisattribute Links um Inhalte im integrierten Modell und dar ber hinaus mit einander zu verbinden Beispielsweise bilden Sie auf diese Weise einen Hyperlink ab Achten Sie bei der Attributierung darauf alle Attribute so zu w hlen dass diese sich ein deutig und ausschlie lich nur auf die betrachtete Entit t beziehen Sie m ssen vermeiden dass Attribute einer Entit t Ihres Metamodells zugeordnet werden die eigentlich zu einer anderen Entitat des Modells geh re
224. ices im Unternehmen zu finden und richtig zu kapseln In die sem Buch gehen wir auf die Serviceidentifikation ber Prozessmodelle ein siehe Ab schnitt 7 4 Andere Methoden starten h ufig auf der gr nen Wiese In diesem Buch ge hen wir davon aus dass entweder ein Prozessmodell zur Verf gung steht oder dass eines geplant ist Prozessmodelle enthalten viele detaillierte Informationen ber Unternehmen Diese Informationen kann man nutzen um Services zu identifizieren Ein Identifikations ansatz der bei null startet w rde mehr Aufwand bedeuten da Informationen doppelt er mittelt werden Serviceklassifikation Durch die Serviceklassifikation wird das Serviceportfolio strukturiert Ordnet man die Ser vices verschiedenen Klassen zu kann ber die Service navigiert werden Eine dieser Struk turierungen k nnen z B atomarer Service zusammengesetzter Service sein Auf die Serviceklassifikation gehen wir in Abschnitt 7 5 genauer ein Servicespezifikation und Implementierung Bei der Servicespezifikation werden die Services im Serviceportfolio mit immer mehr De tailinformationen angereichert Wurde ein Service z B in der IT realisiert dann wird in der Servicespezifikation die technische Schnittstelle dem Serviceportfolio hinzugef gt Auf die Servicespezifikation geht Abschnitt 7 5 genauer e n 7 3 2 Nutzen und Herausforderungen eines Serviceportfolios Welchen Nutzen ein Serviceportfolio bringt und welche Herausford
225. ichen Dienste vgl Kapi tel 7 E das Erkennen gleichartiger Dienste ber Dom nen Bereichs und Organisationsgren zen hinweg und somit einen Indikator f r m gliche Wiederverwendung vgl Kapitel 7 E den Aufbau eines dom nenbasierten Servicemodells und somit eine Grundlage f r Ta xonomie der Unternehmens und Servicelandschaft und die Formulierung realistischer Service Level Agreements SLA E die Sichtbarkeit der IT Prozesse in den teilweise heterogenen Anwendungslandschaf ten z B auf der Basis von Prozessautomatisierungssprachen wie BPEL E das systematische bertragen fachlicher Anforderungen in die IT Implementierung das eine Reduktion der Kluft zwischen fachlich geforderten und technisch realisierten Anforderungen Engineering Gap anstrebt l Business Process Execution Language Erl uterung siehe Kasten in Abschnitt 8 3 2 2 8 2 BPM SOA Teamwork in der Prozessautomatisierung 8 2 3 Serviceorientierte Prozessautomatisierung Dieses Kapitel befasst sich mit dem Thema Prozessautomatisierung deren Zielsetzung oder zumindest Vision die verlustfreie Abbildung der wertsch pfenden Prozesse des Un ternehmens in der Anwendungslandschaft ist Prozesse oder Prozessfragmente sollen nach dem Muster der fachlichen Vorlage in der IT implementiert und als dedizierte Prozess instanzen dort auch wieder erkennbar und auffindbar sein Be a a Ber eee u 2 A i oy n u I z JBE p x ff ANWENDUNGSSYSTE
226. icher Prozess 201 8 Der prozessgetriebene SOA Ansatz 202 modelle Unterschiede gibt es nicht weiter verwunderlich bei der Abbildung der Diens te die die fachlichen Prozessschritte als Services unterst tzen und umsetzen sollen Abbil dung 8 5 zeigt die Informationen die es auf dieser Ebene der Modellierung zu erfassen gilt Organisation Rollen In Outputs Gesch fts objekte Fachlicher Prozessfluss Abbildung 8 5 Schematische Darstellung des Informations Fachliche bedarfs f r das Services fachliche Detail modell Fachlicher Prozessfluss Im Kern besteht der fachliche SOA Prozess wie alle anderen Prozesse aus dem fachlichen Prozessfluss Dieser beinhaltet die fachlichen Prozessschritte die zur Abarbeitung des Vorgangs durchlaufen werden m ssen Beispiel Lieferungsposition berpr fen Hinzu kommt der so genannte Kontrollfluss des Prozesses der die Abfolge der fachlichen Pro zessschritte beipielsweise sequentiell parallel oder alternativ beschreibt Organisation Da ein fachliches SOA Prozessmodell in den seltensten F llen vollst ndig automatisiert abl uft sollen auch die organisatorischen Aspekte ber cksichtigt werden Dazu wird in Form von Rollen die organisatorische Zuordnung der Verantwortlichkeiten erfasst Fachlicher Service Die von einem Service im Sinne der SOA unterst tzten Prozessschritte erhalten im fachli chen Detailmodell eine Verbindung zu eben diesem Service
227. ie verschiedenen an einem IT Projekt beteiligten Personenkreise haben Das in diesem Kapitel vorgestellte Vorgehen sieht diese fachlichen Anforderungen als Ba sis 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 aus zurichten ist dagegen noch nicht sehr verbreitet Besonders in der Vergangenheit wurde h ufig der Fehler gemacht Systeme einzuf hren die bestimmte Arbeitsabl ufe Fachpro zesse 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 sinn voller kann die Einf hrung einer Standardsoftware sein F r Standardprozesse wie Rech nungspr 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 Entwicklungs aufwand einer neuen L sung Dennoch ist es wichtig zu wissen dass eine Softwareeinf h rung durch die neue Fachprozesse vorgegeben werden bestimmte Konsequenzen f r alle am
228. ieren von Redundanzen bedeuten auch dass die An forderungen weiterer Nutzer erf llt werden m ssen Ein Service muss ggf fters ange passt werden um die Anforderungen aller erf llen zu k nnen Es m ssen verschiedene Zielgruppen im Serviceportfolio unterst tzt werden Reduzieren des Engineering Gaps bedeutet auch dass das Serviceportfolio mit rein fachlichen und rein technischen Services umgehen k nnen muss Das Serviceportfolio soll nicht nur f r die Schnittmenge der Services gelten die fachlich modelliert und technisch realisiert wurden Die diversen Zielgruppen verwenden die gleiche Arbeits plattform Eine gute Strukturierung des Serviceportfolios ist n tig E Ein Serviceportfolio als zentrale Instanz bedeutet auch B rokratie Z B Wiederverwendung oder Erstimplementierung eines Service sind st rker regle mentiert Diese Entscheidungen kosten Zeit Zeit ist in Projekten oft Mangelware 7 3 3 Die BPA Suite als Serviceportfolio Wenn Sie die BPA Suite als Serviceportfolio nutzen ist der gr te Vorteil die Verknup fungsm glichkeit aller Informationen Aufbauend auf einem bestehenden Prozessmodell kann die BPA Suite die Schritte Serviceidentifikation Serviceklassifikation und Ser vicespezifikation unterst tzen und h lt dabei alle Informationen in einem Repository 7 3 Aufbau eines Serviceportfolios Services werden in der BPA Suite in zwei gro e Kategorien eingeteilt Geschaftsservices und Soft
229. ierter Normen Dennoch sind in den letzten Jahren erhebliche Fortschritte erzielt worden Dies zeigt sich vor allem in einer teilweise internationalen Definition von Standards zur Modellierung von IT Systemen Es liegt auf der Hand dass in einem IT Projekt unz hlige Informationen verwaltet werden m ssen Selbst wenn sich Ihr Projekt nur auf einen kleinen Unternehmensbereich be schr nkt werden S e dennoch schnell eine Vielzahl konzeptioneller Informationen erzeu gen Um diese Informationsvielfalt in den Griff zu bekommen bietet es sich an einzelne Aspekte zu modellieren Dabei h ngt die Form der Modellierung stark von den jeweiligen Einsatzgebieten des Modells ab Zum Beispiel finden Sie in der Praxis unterschiedliche Modellierungsstandards zur Abbildung fachlicher und zugeh riger technischer Sachverhal te Der Grund daf r ist dass fachliche und technische Modelle auf sehr unterschiedliche Weise genutzt werden Betriebswirtschaftler und Informatiker verfolgen bei der Modellie rung verschiedene Ziele 2 Integrierte Modellierung fur EA BPM und fachliche SOA 10 Stellen Sie sich einen Qualitatsmanagementprozess in einem produzierenden Unternehmen vor Die Beschreibung der Prozesse 1m Qualitatsmanagement Handbuch unterscheidet sich erheblich von der Modellierung die ein IT Analyst fur den Entwurf einer Software zur Unterst tzung des Qualit tsmanagementprozesses erstellt Erstere dient als Information f r die Prozessausf hrend
230. ierung der Kennzahlen und ihrer Hierarchien Die Kenn zahlen sollen sich aus den spezifischen Zielen des Process Controlling ableiten und dienen als Ma zahl f r die Erf llung eines Ziels In unserem Fall nutzen wir die zielunabhangige Meta Kennzahl Prozessdurchlaufzeit und wenden diese auf die Messung der Durchlaufzeit des Prozesses Wareneingangskon trolle an Dies ergibt die Kennzahl Prozessdurchlaufzeit der Wareneingangskontrolle die wir mit PDauer WEK definieren Die Kennzahlen sollte man so modellieren dass sie in einer Hierarchie strukturiert sind Abbildung 9 13 zeigt die Hierarchie f r unser Bei spiel Pdauer WEK wirkt auf die spezifischen Auspr gungen der Kennzahl bzgl der Verfeinerung auf unterschiedliche Sichten 242 9 7 Modellierung des Prozess Controlling mit der Oracle BPA Suite Kennzahlen PC Kennzahlenzuordnungsdiagramm Kennzahlenerfassung PDauer WEK Kennzahlenzuordnungsdiagramm Reduktion der Durchlaufzeit der PDauer WEK WEK um 20 3 f wird gemessen durch ist Input f r 5 PDauer WEK z MP WEK Start ist Input tur 5 MP WEK Ende wirkt aufl PDauer pro Prozessinstanz wirkt auf PDauer pro Region wirkt auf PDauer pro Produkttyp wirkt aufl PDauer pro Lieferant wirkt auf PDauer Abbildung 9 13 gesamt Modellierung der Kennzahlen und deren Zuordnungen Hierbei ist f r uns jede Auspr gung der Durchlaufzeit f r eine oder mehrere Dimensio
231. ierung fur EA BPM und fachliche SOA 16 Abschlie end werden im Rahmen des Prozesscontrollings Ma nahmen zur permanenten Beobachtung und Bewertung der Gesch ftsprozesse eingef hrt sowie Handlungsanwei sungen zur kontinuierlichen Leistungssteigerung festgelegt Allen vier Phasen ist 1m Rahmen des fachlichen BPM gemein dass eine informationstech nologische Unterst tzung nicht Bestandteil ist Technisches BPM Demgegen ber befasst sich das technische BPM mit der informationstechnologischen Unterst tzung der fachlichen Prozesse Betrachtet werden die IT Aspekte der Prozessstra tegie der Prozessgestaltung der Prozessimplementierung und der Prozesssteuerung auf bauend auf den Ergebnissen des fachlichen BPM Im Rahmen der Prozessstrategie wird die technologische Unterst tzung strategisch bewer tet und festgeschrieben Ziel ist es sicherzustellen dass im Rahmen der Prozessgestaltung implementierung und steuerung eine an den fachlichen Bed rfnissen des Unternehmens ausgerichtete Technologievorgabe vorliegt Der Prozessgestaltung kommt im technischen BPM eine st rker unterst tzende Bedeutung zu Im Wesentlichen geht es hier um den Einsatz der zur fachlich inhaltlichen Ausgestal tung der einzelnen Prozesse des Unternehmens genutzten Informationstechnologie Dies umfasst haupts chlich Prozessmodellierungswerkzeuge St rkere Bedeutung gewinnt das technische BPM wieder in der Phase der Prozessimple mentierung und berwachung
232. ies sind gem Abbildung 9 10 die Prozesse die wir zur Erreichung der Ziele durch die Erfolgsfaktoren Initiativen ben tigen Wir veran kern diese Initiativen in der Prozesslandkarte unter dem sekund ren Kernprozess Control ling siehe Abbildung 9 16 Hier flie en die Kennzahlen als Input ein und f hren zu einer Bewertung und oder zu ent sprechenden Ma nahmen zur Erreichung der definierten Gesch ftsziele Das Controlling in einem Unternehmen besteht nat rlich aus den unterschiedlichsten Aktivit ten Stellver 245 9 Entwurf und Aufbau prozessgetriebener Kennzahlensysteme Interne Prozesse Interne Geschaftsobjekte Externe Prozesse Externe Geschaftsobjekte Service Service Kunden auftra g Kunden Kunden I 9 Kunden auftrag amp rozesse anfrage 8 p g Produkt Kunden spezifikation amp angebot amp Prim re Kernprozesse Externe Prozesse Externe Gesch ftsobjekte Vertrieb Lieferanten anfrage amp af Lieferanten angebot amp Lieferanten prozesse Produkt entwicklung Material bestellung amp Beschaffung a i i Material lieferung amp nternehmens Material chnungsdaten strategie 5 Unternehmens entwicklung Gesch fts chancen amp
233. ifischen Kennzahlen und die Bedeutung der Kenn zahlen E die Sonden zur Ermittlung der Zustandsdaten der Prozessinstanzen E den Zusammenhang der Sonden mit den Gesch ftsobjekten und E die IT Systeme zur Beschaffung der Zustandsdaten Sonden Diese Modelle machen die Analyse der Auswirkungen und Abh ngigkeiten m glich Au Berdem werden die Modelle durch IT Objekte angereichert und dienen somit als Grund lage f r die eigentliche Implementierung Wir empfehlen diese Modellinformationen in einem Repository etwa dem Produkt Oracle Suite zentral abzulegen und somit konsistent zu halten Abbildung 9 9 stellt diese Zusammenh nge dar und soll uns als Leitfaden f r die Modellie rung in der Oracle BPA Suite dienen m ee re an m m ne ee a a me ee ee J I ii Implementierung Sonden f Li Controllin 5 i sskund r I Wareneingang I BE e Gekhsnkienkienhiunhiunihenh IT Systeme l Se Process li Controlling Sonde Start Pdauer WEP ETL Systeme Process Controlling Sonde Stop Pdauer WEP Process Monitoring Process Mining Process l l l l l l l l l l l l l l l l Cockpit e ee a eee het Fc VRR ee eet I EAE 2 Abbildung 9 9 Zusammenhange der unterschiedlichen Domanen bei der Modellierung 238 9 7 Modellierung des Prozess Controlling mit der Oracle BPA Suite Wir verfolgen bei der Modellierung der K
234. ig automatisierbar sein wobei manuelle T tigkeiten trotzdem vorkommen k nnen und dann beispielsweise von Human Workflow L sungen abgebildet werden 203 8 Der prozessgetriebene SOA Ansatz 204 Sik Y Y rH Abbildung 8 6 Datenobjekte Technischer Technische Schematische Darstellung des Informations In Output Prozessfluss Services bedarfs f r das fachliche IT Modell Technische Prozessschritte Aktivitaten und technische Services Die Prozessschritte des fachlichen IT Modells erbringen ebenso wie die des Fachprozesses eine Leistung im Sinne des Prozesses Sie sind dabei in der Regel durch die Aufrufe tech nischer Services z B ber WSDL Schnittstellen realisiert Als Spezifizierung dieser Service Aufrufe dienen dem Entwickler die Angabe der Lokation z B URI sowie der aufzurufenden Serviceoperation und die erwarteten In und Output Parameter des techni schen Service Diese Zusammenhange werden in Abschnitt 8 4 an einem konkreten Mo dellierungsbeispiel f r die Oracle BPA Suite vertieft Im idealtypischen SOA Modell sollte nicht unterschieden werden wie die Leistung des Service erbracht wird ob also beispielsweise ein vollautomatisierter Systemzugriff erfolgt oder hinter dem Service Aufruf eine manuelle T tigkeit liegt Eine manuelle T tigkeit k nnte dem Benutzer etwa ber eine Human Workflow Anwendung zugewiesen werden Dieses Abstrahieren vom WIE der Serviceumsetzung stellt ein wichtiges Paradigma der Servic
235. ig einer Sicht zu und sortieren Sie diese in jeder Sicht nach ihrer Detaillierung Das erfolgt innerhalb jeder Spalte der Domain Level Matrix nach zunehmender Detaillierung von oben nach unten Wiederholen Sie den Vorgang so lange bis alle innerhalb der essenziellen Fragestellungen ermittelten Objektty pen in der Domain Level Matrix eingeordnet sind Abbildung 3 5 zeigt das Ergebnis fur unser Beispiel Bei der Durchf hrung werden Sie merken dass sich die meisten Objekttypen leicht nach ihrer Granularitat sortieren lassen Gelegentlich werden Sie aber auf verschiedene Ansich ten zur richtigen Reihenfolge sto en Zum Beispiel kann man die Objekttypen Unterneh men und Standort je nach Sichtweise unterschiedlich zuordnen Nimmt man fur den Beg riff Standort eine allgemeine Sichtweise an so ist es m glich an einem Standort mehrere Unternehmen vorzufinden Bei dieser Definition ist der Standort dem Unternehmen ber geordnet Betrachtet man das Unternehmen aber als organisatorisches Ganzes das an meh reren Standorten pr sent ist so kehrt sich die Reihenfolge um Weiterhin ist es m glich dass in den essenziellen Fragen die gleichen Objekttypen mit verschiedenen Begriffen bezeichnet werden Nat rlich nehmen Sie nur einen dieser syn onymen Begriffe in die Domain Level Matrix auf 3 2 Der werkzeugneutrale Modellentwurf Sie mussen bei der Einordnung der Objekttypen in die Domain Level Matrix unterschiedliche Interpretationen der be
236. illierte Einf hrung in die Managementkonzepte Enter prise Architecture Business Process Management oder Service orientierte Architekturen Wir empfehlen zur Einarbeitung in die jeweiligen Gebiete die B cher Hans09 Schm07 und Math07 Wir erl utern einen pragmatischen Ansatz zur Erstellung eines integrierten EA BPM und fachlichen SOA Modells Dabei ist unser Ziel Ihnen die Vorgehensweise beim Aufbau integrierter Modelle n herzubringen Aufgrund vielf ltiger spezifischer Fragestellungen in Organisationen ist es aber nicht m glich einen f r alle Anwendungsf lle passenden gene rischen Ansatz zu beschreiben Auch haben wir kein technisches SOA Buch geschrieben Vielmehr betrachten wir die Modellierungsebenen vor der technischen SOA Modellierung Auf keinen Fall ersetzt das Buch die bestehenden Dokumentationen der Oracle BPA Suite oder der ARIS Process Plattform Betrachten S e es als Erg nzung zur Dokumentation der vorgestellten Werkzeuge Es enth lt keine Beschreibung der technischen BPEL Automa tisierungsmodellierung mit der Oracle BPA Suite und der Verbindung mit dem Oracle JDeveloper oder anderen Werkzeugen der Oracle Fusion Middleware 1 6 Welches Vorwissen sollten Sie besitzen Sie sollten als Leser Grundlagenwissen in der Erstellung von Enterprise Architekturen Business Process Management Modellen und Service orientierten Architekturen besitzen Dieses Wissen ist hilfreich um die Vereinigung der Inhalte der drei jewei
237. ilungs Bereichsleiter bzw Personen die f r den Prozess bergrei fend verantwortlich sind und E Prozessverantwortliche f r die aktuelle Prozessinstanz Verantwortliche Einen berblick ber Anforderungen der einzelnen Rollen an die Processcontrolling Kom ponente zeigt Tabelle 9 2 9 4 Ziel des Process Controlling Tabelle 9 2 Be aoe der unterschiedlichen Rollen Anforderung Top Top Management Top Management Prozess Owner Owner Prozess Verantwortliche _ Pr sentation Aggregierte Kennzahlen Berichte Analysen Alerts Monitoring berblick operativer Analyse von Optimie Behebung operativer Stand der Prozesse o Schwachstellen IT IT L sungen KPI KPI Cockpits Ad hoc Ad hoc Analysen BAM BAM Alerting TOP Management Das Top Management fordert einen berblick ber die operativen Prozesse in Form von aggregierten Kennzahlen Als IT Unterst tzung w hlt man in der Regel ein Prozess Cockpit in dem die wesentlichen Indikatoren ber Ampelfunktionen oder hnliche grafi sche Elemente dargestellt werden Diese IT Systeme lassen es in der Regel zu aus einer bersicht heraus die einzelnen grundlegenden Datens tze zu betrachten Hierdurch wird die Analyse durch Einbeziehung von Detailsichten verbessert Diese Anwendergruppe muss nicht die einzelne Prozessinstanz berpr fen k nnen In Einzelf llen wird sie den Bedarf haben Informationen ber Ad hoc Analysem glichkeiten zu hinterfragen und zu ana
238. in Lastenheft die vom Auftrag geber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrages Dies bedeutet dass ein Lastenheft f r eine Ausschreibung verwendet werden kann da alle f r den Auftragnehmer den System Real sierer relevanten Informationen darin enthalten sind Ein Fachkonzept beschreibt ganz all gemein ein Konzept auf einem bestimmten Fachgebiet Bezogen auf IT Systeme wird der Begriff meist zur Beschreibung der funktionalen Systemanforderungen sowie den Nutzen des Systems bezogen auf das entsprechende fachliche Anwendungsgebiet verwendet Da im Rahmen eines IT Projektabwicklungsprozesses meist nur die Begriffe Lastenheft und Pflichtenheft verwendet werden und es keine einheitliche Definition des Begriffs Fach konzept gibt bestehen auch keine konkreten formellen Anforderungen an ein Fachkon zept Nach den oben genannten Definitionen und Begriffseinordnungen k nnte man ein Fachkonzept jedoch als Teil eines Lastenheftes bzw ein Lastenheft als ein Fachkonzept verstehen das um notwendige Informationen f r eine Ausschreibung erg nzt ist Der Begriff Pflichtenheft ist ebenfalls in der DIN 69905 definiert und beschreibt die vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom Auf traggeber vorgegebenen Lastenhefts Dies zeigt bereits den blichen Projektabwicklungs prozess in dem der Auftraggeber ein Laste
239. in der Oracle BPA Suite 208 Nachdem in den vorigen Abschnitten der konzeptionelle Ansatz und das Vorgehen einer prozessgetriebenen SOA Modellierung allgemein und eher theoretisch erlautert wurden soll es nun konkreter werden Im Mittelpunkt steht fortan die Frage wie die Hierarchie der serviceorientierten Prozessmodelle und die relevanten Informationen in der Modellierung der SOA Prozesse mit dem Werkzeug Oracle BPA Suite abgebildet werden konnen Wah rend die Modellierung auf der Ebene der fachlichen Detailmodelle vgl Abbildung 8 4 nahezu immer einem einheitlichen Schema folgt bieten sich auf den darunter liegenden Ebenen der fachlichen IT Modelle alternative Ansatze der Modellierung an Dazu spater mehr 8 4 1 Stets zu Diensten Fachliche Services im Prozessablauf Die SOA Prozessmodellierung beginnt wie bereits zuvor erw hnt auf der vierten Ebe ne vgl Abbildung 8 4 mit dem so genannten fachlichen Detailmodell F r dieses Modell empfiehlt sich n der Oracle BPA Suite der Einsatz der Ereignisgesteuerten Prozesskette EPK als Notation vgl Abschnitt 8 3 5 Die einzelnen fachlichen Prozessschritte haben auf dieser Ebene der Modellierung noch einen recht groben Detaillierungsgrad Zus tzlich zu den in der Oracle BPA Suite als Funktionen modellierten Prozessschritten werden die in Abschnitt 8 3 4 1 genannten relevanten Informationen erfasst Der Fokus aus Sicht der SOA Prozessmodellierung liegt hierbei auf den fachlichen Ser
240. ion Funktion Hauptgruppe D1_ ID Zus tzliche Lieferung initieren Funktion Use Case Hauptgruppe W2 1 Schlie en Hilfe Abbildung 7 8 Serviceidentifikation ber die Namenssuche in der BPA Suite Im Suchergebnis finden wir verschiedene Funktionen die irgendwie mit dem Thema Lieferung zusammenh ngen In der Auswahl passen z B die Funktionen Teillieferung initiieren und Zus tzliche Lieferung initiieren zu einem Servicekandidaten Lieferung initiieren Die verschiedenen Varianten der Lieferungspr fungen ergeben einen Servi cekandidaten Lieferungspr fung Ob die Kandidaten auch zu einem Service werden muss anhand der Gesamtbetrachtung des Serviceportfolios erfolgen Die Identifikation ber Gesch ftsobjekte erfolgt nicht ber die Suche sondern ber die Eigenschaftenanzeige in der BPA Suite Ansicht gt Eigenschaften Wurde ein Objekt 1m Modell ausgew hlt werden auf verschiedenen Reitern Informationen zum Objekt ange zeigt Haben wir beispielsweise das Gesch ftsobjekt Materialbestellung markiert k nnen wir ber den Reiter Beziehungen alle Objekte sehen die eine Kante zwischen sich und der Materialbestellung besitzen 180 7 9 Attribute Hinterlegungen 7 5 Serviceklassifikation und Servicespezifikation Auspr gungen Beziehungen Beziehungstyp Objektname 7 ist Input f r ist Input f r ol ist Input f r a ist Input f r o ist Input f r off ist Input f r vel ist Input f r ol
241. ionsbeitrag einer SOA Modellierung im integrierten Modell Nach welchen Kriterien kann man ein integriertes Modell fur EA BPM und SOA unter teilen 2 2 Management Fachbereiche und IT jeder ist anders Jede Jeck ist anders Jet jeck simmer all lautet ein bekanntes Sprichwort in K ln Damit bringen unsere k lnischen Landsleute zum Ausdruck dass wir alle verschieden sind und jeder auf seine Weise etwas Besonderes F r d e des k lnischen Dialektes m chtigen Leser unter uns ist anzumerken dass es sich um eine recht freie und positive bersetzung han delt Sie dr ckt aber sehr gut aus worum es geht Je nachdem welche Rolle ein Mitarbei ter im Unternehmen einnimmt sei es Management Fachbereich oder technische IT immer hat er genaue Anforderungen w e bestimmte Fragestellungen oder Sachverhalte zu be schreiben s nd Problematisch ist h ufig dass die jeweils anderen Rollen von dieser Sichtweise mehr oder weniger stark abweichen Vielleicht kennen Sie die Situation Sie s tzen in einem Meeting mit Teilnehmern aus dem Management den Fachbereichen und der Informatik in dem der 2 Integrierte Modellierung fur EA BPM und fachliche SOA Nutzen die fachlichen Auswirkungen und die technische Umsetzung einer IT L sung besprochen werden soll Jede Seite tr gt ihre Sichtweise vor aber irgendwie haben Sie latent das Gef hl dass die anderen den Sachverhalt noch nicht so ganz verstanden haben Jedenfalls nicht so wie Sie
242. is wenig praktische Erfahrungen gemacht hat In der Regel wird eine Indivi dualentwicklung jedoch zur Unterst tzung von Fachprozessen durchgef hrt die auf fachli cher Seite bereits etabliert sind und praktiziert werden In solchen F llen wei ein Fachbe reichsmitarbeiter sehr genau wie und mit welchen Informationen er eine bestimmte fachli che Aktivit t durchf hrt Was bedeutet er kennt die Verarbeitungslogik selbst wenn er diese bislang manuell und ohne IT Unterst tzung durchgef hrt hat Er kann genau spezifi zieren welche Verarbeitungsschritte er in welcher Reihenfolge durchf hren muss welche Daten er wann ben tigt und wie die Verarbeitungsschritte und Daten voneinander abh n gen Er wei auch w e und aus welchen Daten er neue Daten erzeugt und welche Berech nungen und Pr fungen er w e und wann durchf hren muss Ausgehend von diesem Wissen kann man einen Systemablauf entwerfen der der fachlichen Verarbeitungslogik entspricht Es kann weiterhin spezifiziert werden welche Verarbeitungsschritte Berechnungen Pr fungen Abfragen das System automatisch durchf hren kann und welche Daten wo ben tigt bearbeitet und erzeugt werden Diese M glichkeiten zur Spezifikation des System ablaufs sollten unbedingt genutzt werden um sicherzustellen dass das System den Mitar beiter bei der Durchf hrung seiner fachlichen Aufgaben optimal unterst tzt und er seine Proanisatonseinnen Fachbegriff a 6 3 Die IT Sicht u
243. isiertes Verfahren Es gibt jedoch Methoden die die Serviceidentifikation erleichtern Auf eine dieser Methoden gehen wir in diesem Abschnitt genauer ein 7 4 1 Verschiedene Wege der Serviceidentifikation In der Serviceidentifikation k nnen verschiedene Ans tze unterschieden werden Top down Bottom up und Middle out Top down Die Top down Ans tze starten aus der Vogelperspektive eines Unternehmens Hierzu z h len die Serviceidentifikation ber Prozessmodelle und die Dom nendekomposition Beide Ans tze betrachten auf oberster Ebene das Kerngesch ft und brechen dieses immer detail lierter herunter In diesem Buch werden wir primar auf den Prozessmodellansatz eingehen Die Domanendekomposition setzen wir zus tzlich ein um die gefundenen Services zu hie rarchisieren siehe auch Abbildung 7 3 Bottom up Bottom up Ans tze starten am anderen Ende und haben zum Ziel viele Detailinformatio nen schrittweise zu aggregieren Oft starten diese Ansatze auf der Ebene von Datenbanken bzw Tabellen oder auf Systemebene In diesem Buch gehen wir nicht weiter auf den Bot tom up Ansatz ein Wird er im Anschluss an den Top down Ansatz durchgefuhrt kann er sehr gut als Gegenprobe verwendet werden Services die ber einen Bottom up Ansatz identifiziert wurden m ssen auch in einem Top down Vorgehen gefunden werden Middle out Als dritte Gruppe g bt es die Middle out Ans tze Hierzu z hlen w r z B das Business Process Tracing In die
244. itig auch die Detailgenauigkeit der Inhalte ab Wichtig ist dass Sie ein ausgewogenes Verh ltnis zwischen Detailtiefe und Modellierungsaufwand erzielen Entscheiden Sie sich im Zweifel immer f r die geringere Komplexit t 47 3 Aufbau des Metamodells 48 Sie erkennen dass es unm glich ist f r alle individuellen F lle eine allgemeine L sung zur Umsetzung der Domain Level Matrix in ein Metamodell vorzugeben Hier m ssen Sie als Business Analyst die vorliegenden Gegebenheiten bewerten Nachdem Sie die Entit ten definiert haben erstellen Sie das Metamodell inklusive Bezie hungen Dabei unterscheiden Sie Beziehungen zwischen zusammengefassten und nicht zusammengefassten Objekttypen m Beziehungen zwischen zusammengefassten Objekttypen f hren zu einer Selbstreferenz der betroffenen Entit t Zum Beispiel wird die Beziehung zwischen den Objekttypen Unternehmen und Abteilung der Domain Level Matrix in der Entitat Organisations einheit im Metamodell mit der Selbstreferenz des Typs ist zusammengesetzt aus dar gestellt In diesen F llen handelt es sich in der Regel um eine 1 n Beziehung Das be deutet es kann jeweils ein bergeordnetes Objekt mit mehreren untergeordneten Ob jekten verbunden werden um eine hierarchische Struktur auszudr cken m Beziehungen zwischen nicht zusammengefassten Objekttypen der Domain Level Ma trix werden in das Metamodell als 1 n oder m n Beziehung zwischen den betroffenen Entit ten bertragen
245. ividuell genutzte Methode in einem Methodenfilter einge stellt Die beschriebene Vorgehensweise der Filteranalyse kann nat rlich auch auf einen individuell er stellten Methodenfilter angewendet werden Weitergehende Informationen zur Erstellung individueller Methodenfilter finden Sie im Handbuch und der Online Hilfe zum Werkzeug 4 5 Vorgehensweise zur Ermittlung Ihrer individuellen Oracle BPA Suite Methode Entitat Beziehung Diagramm Quellsymbol Zielsymbol Beziehung Semantische Entitat Gruppe typ Abdeckung Anwendungssystem Zugriffs Typ Anwen Fachbegriff verwendet 100 bearbeitet Gesch fts diagramm dungssystem objekt Person ist verantwort Aufgaben Person Typ ist f r Entwicklung 100 lich f r Anwendungs zuordnungs intern Anwendungssystem verantwortlich f r system diagramm Person ist zugeordnet Organigramm Person Stelle besetzt 100 zu Organisationseinheit intern Organisationseinheit ist Organigramm Organisations Organisationseinheit ist bergeordnet 100 zusammengesetzt aus einheit nat Stelle wird gebildet durch einheit Organisationseinheit Organigramm Organisations Standort befindet sich an 100 befindet sich an Stand einheit ort Tabelle 4 2 Darstellung der individuellen Oracle BPA Suite Methode indirekte Beziehungstypen Entit t Beziehung Quellsymbol Hinterlegter Implizite Semantische Entit t Gruppe Diagrammtyp Beziehung Abdeckung Prozess ist zusammen Wertsch pfungskette desciztal
246. kann Um im Beispiel zu bleiben k nnte die Ausgangsnachricht hier die Tele fonnummer zum Namen sein Diese Informationen sollten zus tzlich mit in das Prozess modell aufgenommen werden Ein hnliches Vorgehen hat sich auch in der Prozessmodel lierung durchgesetzt Hier dienen Gesch ftsobjekte als Eingangs und Ausgangsnachricht f r Prozesse und Prozessschritte Zusammengesetzte Services im Prozessmodell Im vorigen Abschnitt wurden Services verwendet Das hei t ste wurden 1m Prozessmodell mit einem Prozessschritt verbunden und haben somit den Prozessschritt realisiert oder un terst tzt Der Prozess hat hier die Rolle des Servicekonsumenten eingenommen Umge kehrt k nnen wir genauso definieren dass wir unseren Prozess als Service sehen Bevor der Prozess als Service publiziert wird muss er jedoch mindestens die Anforderungen er f llen dass er einem Konsumenten einen Mehrwert bietet und eine wohldefinierte Schnitt stelle besitzt siehe auch Abschnitt 7 2 1 Nicht jeder Prozess sollte als Service publiziert werden Der Konsumentennutzen muss klar im Vordergrund stehen Soll ein Prozess auch als Service publiziert werden gib es drei Arten zu unterscheiden E Manueller Prozess E Teilautomatisierter Prozess E Vollautomatisierter Prozess Im Falle eines manuellen Prozesses befinden wir uns in einer rein fachlichen SOA ohne IT Unterst tzung In diesem Fall ist keiner der Prozessschritte mit technischen Services verbunden und jeder
247. klassischen ETL Prozesses Prozess der Datenbewirtschaftung eines Data Warehouse der aus den Phasen Extraktion Transformation Laden ETL besteht Der Schwerpunkt liegt hier in der Zusammenf hrung der Prozessdaten mit den Infor mationen zu den referenzierten Gesch ftsobjekten E Die Analyse beruht auf den Auswertungen zur Ermittlung von Schwachstellen Soll Ist Vergleichen Erkennung von Mustern und Wirkungsmechanismen Process Mining und Analyse von Key Performance Indikators KPI s In den obigen Aufgaben spiegeln sich bereits die wesentlichen Kernaufgaben des klassi schen Data Warehouse Projektes wider ein ETL Prozess und eine Oberfl che fur flexible Auswertungen Die grundlegende Architektur eines Data Warehouse wird in Abschnitt 9 5 aufgegriffen und hinsichtlich der Anforderungen des Process Controlling ausgestaltet Sche02 In Abbildung 9 3 erkennt man dass das Process Controlling Teil des Regelkreises des Ge schaftsprozessmanagements ist In der Regel setzt man mit der Prozessanalyse auf Die Prozessanalyse versucht durch Zerlegen einer Prozesskette in seine einzelnen Vorgange und Analyse dieses Prozesses Schwachstellen und Verbesserungspotenziale zu erkennen 225 9 Entwurf und Aufbau prozessgetriebener Kennzahlensysteme 226 Process Spillers Process Analyse Design 7 D D Q oO pe Q gt us1eNuswe dui Process Controlling Process Prozess Prozess Ausf hrung au Kae Abbildung 9 3 verb
248. kt werden Antworten auf derartige Fragestellungen und eine detaillierte Definition der Begriffe unweigerlich ben tigt Da sie bislang nirgends eindeutig definiert wurden ist es sinnvoll sie im Vorfeld der Diskussionen voneinander abzugrenzen 195 8 Der prozessgetriebene SOA Ansatz Nutzen Sie in Ihrem Projekt ein Wiki2 in dem die Projektbeteiligten gemeinsam die Definition der Begriffe erarbeiten diskutieren zentral ver ffentlichen und jeder zeit nachlesen k nnen Nachfolgend grenzen wir die Begriffe fachliches Detailmodell fachliches IT Modell aus f hrbares IT Modell fachlicher Service und technischer Service voneinander ab Dabei werden wesentliche Eigenschaften der Begriffe aufgelistet um hnliche Begriffe klarer voneinander zu unterscheiden Diese Definitionen dienen uns als Bas s f r die folgenden Abschnitte Die Abgrenzung der Begrifflichkeiten n mmt Bezug auf die in Abbildung 8 3 gezeigte Darstellung der Prozessdekomposition horizontale Dekomposition em Cc D D m p 1 1 o P p 2 7 N 7 gt gt C V O no oO D N N X x Cpa Se N O O 5 uy AT N 2 o 7 7 O 8 Q Q co 0 Z Ser Lo a 2 D og 590 x 53 2 0 5 7D NC 5 oD N OFN Og foc loa 6 oo oc o 2 noL Yi rco rece OX I mD N A ONA Io E FPO EJZ _ Instanzgranularit t Unternehmensinstanz 2 Instanzgranularit t Kernprozessinstanz oO Instanzgranularitat Fachliche Hauptprozessinstanz Ubersichtsmodelle 4
249. l sse werden als Gesch ftsobjekte modelliert BPA Objekt Fachbegriff Die Gesch ftsobjekte entsprechen h ufig real existierenden Objekten Sie sind auf dieser Ebene nur grob zu erfassen vgl Materialbestellung Bedarfsplanung Ggf k nnen noch die einzelnen Attribute der Gesch ftsobjekte aus einer rein fachlichen Sicht mit aufgef hrt werden Eine detaillierte Auflistung der Attribute Merkmale und Da tentypen erfolgt auf einer feineren Ebene der Modellierung wenn es an die Abbildung von IT Datenobjekten geht Zus tzlich zu den Gesch ftsobjekten kann die Erfassung wichtiger Dokumente als In oder Output der Funktionen erfolgen BPA Objekt Dokument H ufig werden in diesen Dokumenten die verwendeten Gesch ftsobjekte abgebildet Der Bestell schein ware ein konkretes Beispiel f r ein in unserem Prozess eingesetztes Dokument Im Dokument Bestellschein sind dann Gesch ftsobjekte wie Kunde Produkt usw aus Sicht der Bestellung abgebildet Die In und Outputs des fachlichen Prozessschrittes werden auch als Parameter f r den fachlichen Service und somit f r das dahinter liegende fachliche IT Modell genutzt Der als Prozess detaillierte fachliche Service erh lt als ein und ausgehende Parameter die Ge sch ftsobjekte des Prozessschrittes den er unterst tzt Fachliche Services Die aus Sicht der Serviceorientierung wichtigsten Informationen in diesem Modell sind nat rlich die Services Zur Erinnerung Die identifi
250. l sowie Prozess architektur und Ausreichende Prozess und IT ee Dokumentation Bedarfsorientierter Permanentes Echtzeit Monitoring und Reporting der Prozesse Einsatz von Kenn Prozesskennzahlen Zahlen und Mess sind aus strategi system schen Kennzahlen abgeleitet Klar definierte Rollen und Yerantwortlich keiten im Prozess controlling Methodik sind Unkontrollierter zu definiert Technische Implementierung des Messsystems falliger Ablauf von Gesch ftsprozessen Prozessziele sind definiert Definierte Mess punkte in Prozessen Kontinuierliche Optimierung der Prozesse in einem definierten KVP keine Ber hrungs punkte zum Thema Grundlegende Prozesscontrolling Prozess und IT Dokumentation Grundlegendes Operative Zielvor Reporting von gaben f r Kenn Prozessen zahlen Abbildung 9 1 Reifegradmodell des Process Controlling Die tats chliche Realisierung des Process Controlling beginnt in diesem Modell auf Stufe 3 Defined Im Folgenden werden die Stufen Defined und Managed und teilweise die Stufe Optimizing betrachtet Das Befinden auf Stufe 3 bedeu tet dass Kennzahlen strategischer und operativer Art im Unternehmen schon identifiziert wurden und dass auch bekannt ist an welchen Stellen der Prozesse die Kennzahlen ermittelt werden k nnen Schm03 S 194 ff 9 2 Die Herausforderung im Process Controlling Dieses Kapitel liefert einen Uberblick zum Themengebi
251. ler Frage stellungen und der Entwurf einer Domain Level Matrix sollten grunds tzlich werk zeugneutral erfolgen Konzentrieren Sie sich dabei ausschlie lich auf die fach lichen Fragestellungen Ihrer zuk nftigen Enterprise Architektur 3 2 4 Erstellung eines Metamodells 3 2 4 1 Ermittlung der Metamodell Entit ten Mit der Fertigstellung der Domain Level Matrix sind Sie Ihrem individuellen Metamodell bereits einen gro en Schritt n hergekommen Fachlich haben Sie nun einen guten ber blick welche Fragen Ihr Modell in Zukunft beantworten soll und welche Informationen dazu erforderlich sind Jetzt geht es darum die fachlichen Anforderungen in ein passendes Metamodell zu berf hren das innerhalb eines Werkzeugs abgebildet werden kann Zu n chst behalten wir die werkzeugneutrale Perspektive aber noch bei Der Grund daf r liegt in zwei grunds tzlich unterschiedlichen Metamodellkonzepten auf Seiten der Werkzeug hersteller Die eine Gruppe der Werkzeuge bietet ein offenes was bedeutet durch den Anwender vollst ndig frei konfigurier und ver nderbares Metamodell Die andere verf gt ber ein geschlossenes Metamodell das keine oder nur sehr geringe Anpassungen erlaubt 45 3 Aufbau des Metamodells 46 Generell kann man nicht sagen welches Konzept besser ist Beide haben fur den Anwen der Vor und Nachteile deren wichtigste wir in Tabelle 3 5 darstellen Tabelle 3 5 Vor und Nachteile von Werkzeugen mit geschlossenem und of
252. lfluss der in Prozessen vorkommen kann Patterns sind strukturiert von einfach bis komplex Patterns werden u a zur Bewertung der Kontrollflusseigenschaften von Pro zessnotationen eingesetzt Dokumentation und Beispiele unter http www workflowpatterns com 8 3 5 Methodik und Notation ausw hlen Wenn die zu erfassenden Informationen bekannt sind kann auf dieser Basis die Auswahl der geeigneten Modellierungsmethodik und notation erfolgen Die eingesetzte Modellie 205 rungsnotation muss die Abbildung der erforderlichen Informationen aus Sicht der jeweili gen Zielgruppe unterst tzen Im Falle der SOA Modellierung bedeutet dies dass in den relevanten Modellen alle m vorigen Abschnitt gelisteten Informationsanforderungen ab bildbar sein m ssen Die Oracle BPA Suite bietet zur Prozessmodellierung die Notationen Ereignisgesteuerte Prozesskette EPK und die Business Process Modeling Notation BPMN an Unterschiede sowie Vor und Nachteile dieser Notationen k nnen auszugs weise der folgenden Aufstellung entnommen werden Ereignisgesteuerte Prozesskette Business Process Modeling Notation Gut geeignet zur Darstellung und Gut geeignet zur Modellierung Diskussion fachlicher Abl ufe vielf ltiger auch technischer Einfache intuitiv verst ndliche Details Notation Detaillierte Modelle haben ggf Sichtenmodell zur Strukturierung h here Komplexit t der Informationen ARIS Keine abstrakten U
253. lgende Informationen zu einer ben tigten Schnittstelle ange geben werden E Welche Daten flie en ber die Schnittstelle E In welche Richtung flie en Daten ggf auch in beide E Von welchem System wird die Daten bertragung angesto en E Wie wird die Daten bertragung angesto en durch das System durch den Benutzer 6 3 4 5 Benutzerrollen Durch die Modellierung von Benutzerrollen lassen sich zwei Sachverhalte in der Darstel lung eines Systemablaufs sehr einfach und strukturiert darstellen E Durch die direkte Verkn pfung bestimmter Benutzerrollen mit Verarbeitungsschritten des Ablaufs l sst sich automatisch eine Rechtematrix erzeugen die die Zugriffsberech tigungen der einzelnen Benutzerrollen bezogen auf den Systemablauf darstellt E Vom System automatisch durchgef hrte Verarbeitungsschritte werden gekennzeichnet indem ihnen keine Benutzerrolle anmodelliert wird Die Beschreibung der verwendeten Benutzerrollen sollte verdeutlichen warum man die jeweilige Benutzerrolle ben tigt warum sie definiert wurde und wie sie sich von den ande ren Benutzerrollen abgrenzt Sofern m glich und sinnvoll l sst sich dar ber hinaus in der Beschreibung eine Verbindung zur fachlichen Organisationssicht herstellen indem man beschreibt welche Mitarbeiter Stellen oder Abteilungen etc die jeweilige Benutzerrolle wahrnehmen sollen Diese Zuordnung kann auch in einem Modell dargestellt werden wie Abbildung 6 10 zeigt Bei der Beschreibun
254. ligen Einzeldis ziplinen zu berblicken Diese Voraussetzung sollte Sie aber nicht abschrecken Wir haben das Buch so geschrieben dass auch Leser die in den oben genannten Gebieten nicht so versiert sind einen leichten Zugang finden werden 1 7 Das integrierte Beispiel 1 7 Das integrierte Beispiel Um Ihnen die angewendete Modellierungsmethodik vorzustellen haben wir ein durchge hendes Beispiel n das Buch aufgenommen Abgebildet wurde der Prozess der Warenein gangskontrolle in einem produzierenden Unternehmen Abbildung 1 1 zeigt die grunds tz lichen Zusammenh nge des Prozesses der Wareneingangskontrolle Materialeinkauf gt Wareneingang gt Kreditoren Buchhaltung y a Wareneingangskontrolle a if L ich Lieferung prufen gt Lieferpositionen gt Wareneingang gt QS Prufung allgemein prufen buchen durchfuhren Abbildung 1 1 Schematische Darstellung der Wareneingangskontrolle Diesen Beispielprozess werden wir im Verlauf des Buches immer wieder heranziehen um die erl uterten theoretischen Ans tze zu verdeutlichen 2 Integrierte Modellierung fur EA BPM und fachliche SOA 2 1 Fragen die dieses Kapitel beantwortet E Welchen Informationsbedarf muss ein integriertes Modell f r EA BPM und SOA abdecken Was ist der Informationsbeitrag der EA Modellierung im integrierten Modell Was ist der Informationsbeitrag einer BPM Modellierung im integrierten Modell Was ist der Informat
255. lle ist auch der Zusammenhang zwischen der Beschreibung der Daten und der Masken zu be achten da bei der Beschreibung der Masken spezifiziert werden kann welche Daten auf der Maske angezeigt und bearbeitet werden k nnen Ferner muss auch der Zusammenhang mit dem Fachprozess ber cksichtigt werden weil die fachlichen Informationen die man zur Durchf hrung einer fachlichen Aufgabe ben tigt die bei der IT technischen Unterst t zung der fachlichen Aufgabe verarbeiteten Daten enthalten m ssen 3 Name Adresse Stra e Ir Hausnummer PLZ n Ort Land g Abbildung 6 11 Status Datenbeschreibung ein Beispiel g 6 4 6 4 Vom Modell zum Fachkonzept Vom Modell zum Fachkonzept Der vorige Abschnitt hat gezeigt dass es vielfaltige Moglichkeiten gibt die Komponenten eines Systems als Modell darzustellen Nat rlich erzeugt Modellierung Aufwand so dass man sich grunds tzlich immer die Frage stellen muss ob durch die Modellierung eines Sachverhalts ein Mehrwert f r die Qualit t des Fachkonzepts entsteht Ist dies nicht der Fall sollte auf eine Modellierung verzichtet werden um unwirtschaftlichen Aufwand zu vermeiden 6 4 1 Anforderungen an ein Fachkonzept Denn fest steht dass das relevante Arbeitsergebnis letztlich keine Sammlung von Model len sondern ein Fachkonzept in Form eines geschriebenen Dokuments ist das dem Reali sierer des beschriebenen Systems ein m glichst gutes Bild von den Anforderunge
256. llen organisatorische Ma nahmen als Prozesse implementiert werden Im Folgenden werden wir diese im Wertsch pfungsket tendiagramm aufgef hrten Prozesse untersuchen Tabelle 9 9 Benutzte Methodenobjekte der Oracle BPA Suite Modellname Prozess Landkarte Controlling Diagrammtyp Wertsch pfungskettendiagramm WKD Symbol Wertsch pfungskette Eine praktische Anleitung der Modellierung der WKD findet man bei Schi09 S 109 9 7 2 1 Modellierung des Process Monitoring Das Monitoring der laufenden WEK Prozesse ben tigen wir um eine Eskalation rechtzei tig zu erkennen zu managen und kurzfristig eine Optimierung vornehmen zu k nnen Die ser eigenst ndige Prozess im Process Controlling muss modelliert werden Hierdurch un terst tzen wir die Initiative A Eskalation bei Problemen in einer Prozessinstanz sollen schneller erkannt und behoben werden Dies ist eine Aufgabe die von den Organisationseinheit en durchgef hrt wird und in der Prozess Landkarte erscheinen muss Ferner ben tigen wir den Prozess als einen Hook f r das IT System Process Monitoring in die Prozesswelt Dies erm glicht uns die lose Koppelung der Modelle der IT Komponenten mit den Prozessen Das Process Monitoring setzt sich aus zwei Schritten zusammen der Identifikation eines m glichen Problems und der Problemanalyse inkl Einleitung notwendiger Schritte zur kurzfristigen Verbesserung einer laufenden Prozessinstanz Problemidentifikation
257. llierung der Geschaftsobjekte in einem Containerdiagramm ver gleichbar der Abbildung 5 19 ab Zur eindeutigen Kennzeichnung der Serverhardware ist es alternativ zur Angabe der Ser vernamen in unserem Beispiel Rechner 1 n auch m glich deren IP Adressen anzu geben 5 2 Aufbau des Grundmodells Sun Blade Sun Blade Sun Blade Sun Blade 6000 Rechner 6043 Rechner 000 Rechner 2000 P 1 2 4 Rechner 3 Sun Blade Sun Blade Sun Blade Sun Blade T6250 T6300 T6320 T6340 Rechner 5 Rechner 6 Rechner 7 Rechner 8 Sun Blade Sun Blade Sun Blade Sun Blade KEN M6240 x6440 6450 Rechner 9 Rechner 10 Rechner 11 Rechner 12 Abbildung 5 19 Servermodellierung mit Hilfe eines Containerdiagramms Beispiel Datenbanken Datenbanken stellen im Kontext des integrierten Modells eine besondere Komponente dar S e dienen als Quellen und Senken f r digital verarbeitete Informationen Im Rahmen eines integrierten EA BPM SOA Modells sind Datenbanksysteme ein wichtiger Bestand teil Damit digitalisierte Prozesse tats chlich das von ihnen erwartete Ergebnis erzeugen ist die Verf gbarkeit Vollst ndigkeit und Richtigkeit der Daten von besonderer Bedeu tung Besonders m fachlichen SOA Teil des integrierten Gesamtmodells werden Informa tionen ber die von Services verarbeiteten Daten ben tigt Deren Quellen und Senken innerhalb der betrachteten Organisation zu kennen ist aus diesem Grund besonders rele vant Modellieren S e die verf gbaren Datenba
258. ls 102855 Wertsch pfungskette EPK ist prozessorientiert bergeordnet Tabelle 4 1 und 4 2 beschreiben die Ausgangsstruktur unseres integrierten EA BPM SOA Modells Damit k nnte bereits das individuelle Metamodell aus Kapitel 3 2 vollst ndig modelliert werden Ziel ist es aber ein integriertes EA BPM SOA Modell zu erstellen das weitere Modellierungsanforderungen ber cksichtigt Im weiteren Verlauf des Buches wird die vorliegende Ausgangsstruktur sukzessive er g nzt Sie k nnen nat rlich in Abh ngigkeit von Ihren individuellen Modellierungszielen eigene Erweiterungen mit der beschriebenen Systematik vornehmen Die Erweiterungen der von uns eingesetzten Oracle BPA Suite Methode erl utern wir in den folgenden Kapiteln 75 4 Die Umsetzung des Metamodells 4 6 Analyse und Bewertung der semantischen Abdeckung Aufgrund des geschlossenen Metamodells der Oracle BPA Suite werden Sie bei der Uber f hrung Ihres individuellen Metamodells meistens gezwungen sein Kompromisse in der semantischen Abbildung einzugehen Wie gro diese sind h ngt ausschlie lich davon ab wie genau Ihre individuellen Informationsanforderungen n Symbol und Beziehungstypen abgebildet werden k nnen Methodische Restriktionen durch vorgegebene Diagramm oder Attributtypen spielen bei der Bewertung der semantischen Abdeckung keine Rolle Diagrammtypen k nnen individuell erweitert werden wenn die Auswirkungen auf die ur spr ngliche Oracle BPA Suite M
259. lysieren Prozess Owner Prozessorientierte Organisationen verf gen ber die Rolle des Process Owner Er ist f r die Effektivit t und Effizienz eines gesamten Prozesses end to end verantwortlich auch wenn die Prozessabwicklung mehrere Abteilungen oder sogar externe Partner betrifft Die se verantwortlichen Personen m ssen nicht die aktuellen Prozesse berwachen wohl aber in der Lage sein ex post die Qualit t der operativen Prozesse messen bewerten und ver bessern zu k nnen Die Analyse von Optimierungspotenzial ist eine wesentliche Aufgabe Dies erfolgt ber Ad hoc Analysen und Data Mining Verfahren bez glich der konsolidier ten Prozessdaten Prozessverantwortliche Der f r bestimmte Prozessinstanzen verantwortliche Prozessbeteiligte ben tigt eine Near real time berwachung seiner Prozesse Hier sendet in der Regel das Process Monito ring System ber Alerts systemseitig generierte Nachrichten die kritischen Prozessda ten an den Anwender als SMS E Mail oder Voice Mail Diese Nachrichten machen den Prozessverantwortlichen auf m gliche Eskalationen aufmerksam Sodann erfolgt eine Ana lyse des Problems durch die Detailansicht der jeweiligen Prozessinstanz Die fachliche L sung nehmen dann basierend auf dem definierten Regelwerk die Prozessverantwortli chen vor 231 9 Entwurf und Aufbau prozessgetriebener Kennzahlensysteme 9 5 9 4 3 IT Systeme fur das Process Controlling Die Systeme zur Dar
260. m rein fachliche Services in der IT realisierte fachliche Services und rein technische Services enthalten sind In Diskussionen mit Fach und IT Bereichen muss darauf geachtet werden dass alle Beteiligten die drei Servicearten unterscheiden k nnen Bei einem gemischten Personenkreis f hren Diskussionen ber rein fachliche oder rein technische Services meist zu keinen Ergebnissen 7 2 5 SOA und Services im Prozessmodell In unserer Definition von Enterprise Architecture haben wir gesagt Eine Enterprise Ar chitecture ist ein konzeptioneller Entwurf welcher die Struktur und Arbeitsweise einer Organisation beschreibt siehe Kapitel 2 2 1 1 Hierzu geh ren nat rlich auch Services und ihre Verwendung Es sollte somit Ziel sein ein einheitliches Prozessmodell zu erstel len in dem alle unternehmensrelevanten Informationen verbunden sind In Unternehmen in denen Services nicht nur konsumiert sondern auch bereitgestellt wer den m ssen wir aus Sicht der Enterprise Architecture zwei Arten von Services im Modell unterscheiden 157 7 Identifizierung und Modellierung fachlicher Services fur SOA 158 1 Services die in unserem Prozessmodell verwendet werden 2 Services die wir in unserem Prozessmodell zusammensetzen Verwendung von Services Services sind im Prozessmodell mit Prozessschritten verbunden Diese Verbindung sagt aus dass dieser Schritt durch den Service realisiert wird In diesem Fall wird der Service vom
261. m ihn nutzen zu k nnen Ge nau dieser Zustand soll durch die weitere Anreicherung mit Informationen vermieden wer den Die Vorteile liegen nicht nur auf Konsumentenseite Aus Anbietersicht machen wir unsere Services immer besser vergleichbar was eine Entscheidungsfindung bei Service fragen deutlich erleichtert 181 7 Identifizierung und Modellierung fachlicher Services fur SOA 182 7 5 1 Struktur durch die Domanendekomposition Die Domanendekomposition ist urspr nglich eine eigenst ndige Methode zur Serviceiden tifikation Sie startet jedoch bei null und nutzt dementsprechend nicht die Informationen die bereits 1m Prozessmodell hinterlegt sind Ein Vorteil dieser Methode ist jedoch die gute Strukturierung der Services die wir uns jetzt zunutze machen wollen Da wir lediglich be absichtigen die Struktur zu bernehmen werden wir eine vereinfachte Form der Dom nendekomposition durchf hren Bei der Dom nendekomposition wird das Unternehmen aus der Vogelperspektive betrach tet Auf oberster Ebene werden die Kerngesch ftsservices modelliert Die Fragestellung lautet hier Was sind die Kernleistungen des Unternehmens Was ist zentraler Bestandteil des Unternehmens Durch diese Fragen werden die Dom nen gefunden in die sich das Unternehmen aufteilt Die Ebene der Dom nen wird auch Ebene 0 genannt Anschlie end werden die Services auf Ebene 1 identifiziert Jede Dom ne wird jetzt f r sich betrachtet Die Services auf Ebene 1
262. mationen erfasst und nicht ben tigte De tails ausblendet Dies erfordert die Kenntnis der Zielsetzung des Modellierungsansatzes Auch bei der Modellierung serviceorientierter Prozessmodelle gibt es Unterschiede in der konkreten Ausgestaltung der Modellierung Daher sollte zun chst gekl rt werden welche Zielsetzung die serviceorientierte Modellierung in dem vorliegenden Projekt verfolgt Un terschiedliche Zielsetzungen k nnen beispielsweise sein Einsatz der Prozesse zur Identifikation fachlicher Services vgl Kapitel 7 E Zusammenf hren der fachlichen und technischen Unternehmenssicht bzw modelle auf der Basis von Services Spezifikation technischer Services E Technische Implementierung fachlicher Services in der IT Dieses Kapitel verfolgt das Ziel fachliche Services auf der Basis prozessbasierter Spezifikationen technisch zu implementieren 8 3 Modellierung SOA geeigneter Prozessmodelle 8 3 2 1 Vorgehen zur prozessbasierten Implementierung fachlicher Services In dem hier dargestellten Vorgehen wird ein fachlicher Service analog zu der in Abschnitt 8 3 1 definierten Begrifflichkeit auch Business Service als Baustein verstanden der einen Schritt oder eine Funktion in einem fachlichen Gesch ftsprozess unterst tzt bzw IT tech nisch umsetzt In der Regel wird dieser fachliche Dienst selber aus mehreren zusammen geh rigen Einzelschritten bestehen Daher wird vorausgesetzt dass der Inhalt oder die Leistung des Busin
263. mentation der Services im Portfolio werden Services besser vergleichbar Diese Vergleichbarkeit kann sich die Managergruppe zu Nutze machen Z B kann ein Ma nager die Servicekandidaten vergleichen und entscheiden welcher als Erster in der IT rea lisiert werden soll 171 7 Identifizierung und Modellierung fachlicher Services fur SOA P nes pra 172 A Manager i Architekten C Fachbereich Portfolio j Q b Betrieb Implementierung Abbildung 7 6 Beteiligte Gruppen am Service AQ Administrator C Entwickler ai Bauplan eines Serviceportfolios Um ein Serviceportfolio zu erstellen und mit Leben zu f llen gilt es folgende Schritte durchzuf hren Grundlagen f r das Serviceportfolio schaffen Serviceidentifikation Serviceklassifikation Servicespezifikation und Implementierung Die Schritte Serviceidentifikation Serviceklassifikation und Servicespezifikation k n nen innerhalb der BPA Suite durchgef hrt und realisiert werden Grundlagen f r das Serviceportfolio schaffen Mit Grundlagen f r das Serviceportfolio s nd an dieser Stelle keine Systeme gemeint Eher ben tigt das Serviceportfolio Governance und Organisation Beides soll nicht Inhalt dieses Buches sein doch m chten wir hier ansprechen warum Governance und Organisation n tig sind Ist das Serviceportfolio noch klein und besch ftigen sich lediglich eine Handvoll Mitarbei ter damit sind relat v wenig Regeln n tig Alles kann miteinander abgesp
264. mfangreiche Erweiterungen hinsichtlich der Infrastrukturmodellierung vorzunehmen Abbildung 5 18 zeigt eine exem plarische Modellierung der Hardware Betriebssystem und Datenbankbasis des Anwen dungssystems Procurement XT Au erdem erm glicht diese Form der Modellierung die Verbindung mit Objekten der Organ sationsmodellierung so dass organisatorische Ver antwortlichkeiten f r System und Hardware ebenfalls dargestellt werden k nnen kann laufen auf WINDOWS Server 2003 RP ocurement i kann laufen auf Fire X4600 M 2 kann laufen auf Oracle 11g ist verantwortlich f r ist verantwortlich f r arkus Schmidt Heinz M ller ist verantwortlich f r Abbildung 5 18 Modellierung der Hardware Betriebssystem und Datenbankbasis Zugriffsdiagramm 109 5 Das Grundmodell 110 Beachten Sie dass die Objekte der Hardware Betriebssystem und Datenbankbasis inner halb der Infrastrukturbibliothek definiert und ebenfalls auf einem Containerdiagramm ausgepragt werden sollten 5 2 5 4 Erstellung der Infrastrukturbibliothek Die Beschreibung der theoretischen Moglichkeiten zur Modellierung der Infrastruktur k nnte ein ganzes Buch f llen Grund daf r ist die extreme Heterogenit t der unter dem Begriff Infrastruktur zusammengefassten Inhalte Diese reichen von IT Infrastruktur mit den Bestandteilen Software Infrastruktur z B Datenbanken Middleware Security etc
265. n Druckservice E Versorgungsservice Z B ein Enterprise Service Bus der technisch dazu verwendet wird alle Services lose miteinander zu verbinden E Oberfl chen Service Der Service kann in einem Anwendungssystem auf der Benutzeroberfl che angezeigt werden und Benutzerdaten entgegennehmen Laufzeit Die erwartete Servicelaufzeit kann klassifiziert werden Eine Einordnung in kurz mittel und lang sollte vermieden werden Besser geeignet sind Zeitangaben wie weniger als 10 Sekunden oder weniger als eine Woche Nutzenorientierte Klassifikation In einer vereinfachten nutzenorientierten Klassifikation werden die Klassen hoher Nutzen mittelm iger Nutzen und geringer Nutzen ausreichen Eine schwierigere aber zielgerich tetere Klassifikation f hrt ber die Erstellung von unternehmensspezifischen Nutzenklas 7 5 Serviceklassifikation und Servicespezifikation sen Diese Nutzenklassen werden in eine Reihenfolge gebracht und definieren somit wel che Klasse den h chsten und welche den geringsten Nutzen liefert Die folgenden Klassen stellen ein Beispiel dar E Wettbewerbsvorteil Sichern oder Erlangen eines Wettbewerbsvorteils stellt wahrscheinlich in vielen Unter nehmen die h chste Nutzenkategorie dar In diesem Beispiel besitzt es den h chsten Nutzen E Return on Investment ROT erh hen E Kosten Kosten senken ist eine der klassischen Nutzenkategorien Die Kosten sollen gesenkt werden Leistung und Qualit t
266. n Es w re zum Beispiel falsch die Entit t Anwen dungssystem mit einem Attribut Verantwortlicher Betreuer zu versehen da diese Infor 3 2 Der werkzeugneutrale Modellentwurf mation bereits uber die Entitat Person und die Beziehung ist verantwortlich f r zur Enti tat Anwendungssystem abgebildet ist Bei der berlegung wie Sie die Attributierung einer Entit t des Metamodells vornehmen k nnen unterst tzen Sie die in Abbildung 3 9 dargestellten Fragen Betrachten wir das Beispiel einer Attributierung der Entit t Hardwareressource hinsichtlich der f r die Instan zen der Hardwareressourcen verantwortlichen Personen Die Frage ob es sich bei dem Attribut um ein nur die betrachtete Entitat beschreibendes Attribut handelt dessen Information 1m Metamodell an keiner anderen Stelle vorkommt muss mit nein beantwortet werden Die Beschreibung einer Person ist im Metamodell be reits als eigene Entitat vorhanden Jetzt m ssen S e pr fen ob die geforderte Information mittels einer zus tzlichen Bezie hung im Metamodell zwischen den Entit ten Hardwareressource und Person erzeugt wer den kann oder erzeugt werden soll Handelt es sich bei dem Attribut um ein nur die betrachtete Entit t beschreibendes Attribut dessen Information im Metamodell an keiner anderen Stelle vorkommt Kann bzw soll die abzubildende Information ber eine Beziehung zu einer bereits bestehenden Entit t im Metamodell hergestellt werden Leg
267. n Personen auf die individuellen Fragestellungen 1m Unternehmen zu fokussieren 3 2 2 Ermittlung und Bewertung essenzieller Fragestellungen Nachdem die Modellierungsgrunds tze definiert sind ermitteln Sie die zugeh rigen essen ziellen Fragestellungen die das Modell beantworten muss Essenzielle Fragestellungen spezifizieren die Informationen die ein integriertes Modell Ihrem Unternehmen liefern soll Sie dr cken den Informationsbedarf der beteiligten Personen aus die in die Erstel lung Nutzung und Wartung des Modells eingebunden s nd Damit liefern sie das Funda ment f r den Entwurf des Metamodells Es empfiehlt sich die Ermittlung der essenziellen Fragestellungen in zwei Stufen vorzu nehmen m Brainstorming zur Identifizierung der Fragestellungen m Zerlegung Klassifizierung und Bewertung der Fragestellungen 3 2 2 1 Identifizierung der Fragestellungen Wir haben bereits darauf hingewiesen dass in Organisationen h ufig verschiedene Sicht weisen existieren welche Fragestellungen ein Modell beantworten soll Meistens liegt die Ursache darin dass im Vorfeld keine Einigkeit ber die grunds tzliche Ausrichtung erzielt wurde Genau um dieser Situation vorzubeugen haben wir m vorhergehenden Schritt 37 3 Aufbau des Metamodells 38 Grunds tze aufgestellt und bewertet Damit k nnen Sie bereits deutlich fokussierter in die Ermittlung der wichtigen Modellfragestellungen starten Richten Sie aus diesem Grund das Brainst
268. n tigten Systemabl ufe inkl der relevanten statischen System komponenten beschrieben werden 6 4 2 1 Nicht funktionale Systemanforderungen Neben diesen bestehen auch immer nicht funktionale Anforderungen an ein neues System die sich nicht zwingend aus dem Fachprozess ergeben und oft auch bergreifend f r das gesamte System g ltig sind Typische Arten nicht funktionaler Systemanforderungen sind Zuverl ssigkeit Systemreife Wiederherstellbarkeit Fehlertoleranz Aussehen und Handhabung Benutzbarkeit Verst ndlichkeit Erlernbarkeit Bedienbarkeit Leistung und Effizienz Antwortzeiten Ressourcenbedarf Wartbarkeit nderbarkeit Analysierbarkeit Stabilit t Pr fbarkeit Portierbarkeit bertragbarkeit Anpassbarkeit Installierbarkeit Konformit t Austausch barkeit E Sicherheitsanforderungen Vertraulichkeit Datenintegrit t Verf gbarkeit Funktionale und nicht funktionale Systemanforderungen sowie Systemschnittstellen sind die Kernbestandteile eines guten Fachkonzepts f r ein zu realisierendes IT System Funktionale und nicht funktionale Systemanforderungen sowie Systemschnittstel len sind die Kernbestandteile eines guten Fachkonzepts fur ein zu realisierendes IT System 6 4 Vom Modell zum Fachkonzept 6 4 2 2 Begriffsabgrenzung Lastenheft Pflichtenheft Fachkonzept Die Begriffe Fachkonzept und Lastenheft werden h ufig synonym verwendet Laut DIN 69905 Begriffe der Projektabwicklung beschreibt e
269. n Daten n UML und ein entsprechender Verweis auf diese Modelle beispielsweise in den Attributen der Objekte in der BPA Suite sinnvoll sein TIPP Nutzen Sie bei der Abbildung der Datenstrukturen ein einheitliches unter nehmens oder projektweit g ltiges Datenmodell Business Object Model H ufig k nnen diese Datenmodelle auf offiziell verf gbaren Branchenreferenzmodellen basiert werden Dies erh ht die Austauschbarkeit und das Potenzial bei der Integ ration fremder Services 215 8 Der prozessgetriebene SOA Ansatz 216 Organisation In BPMN werden Verantwortlichkeiten und Rollen ber die Konstrukte Pool und Lane abgebildet Dies ergibt das f r BPMN typische Swimlane Layout bei dem die Schwimm bahnen jeweils f r eine ausf hrungsverantwortliche Organisationseinheit bzw Rolle oder auch f r ein IT System stehen Das in Abbildung 8 11 dargestellte Prozessmodell enth lt eine BPMN Lane f r die Rolle des Dispositionsbeauftragten welcher f r die abgebildeten Prozessschritte ausf hrungs verantwortlich ist Andere Schritte in diesem Prozess werden von den IT Systemen Lager haltungssystem oder Bestellsystem ausgef hrt die ebenfalls in BPMN Lanes abgebildet sind Nutzen Sie diesen Modellierungsansatz wenn E Sie eine mit wesentlichen IT relevanten Details angereicherte Vorlage f r den SOA Entwickler erstellen wollen E Sie ein bezogen auf die IT Umsetzung plattformneutrales Modell ben
270. n Diagrammtyp Zugriffsdiagramm Abbil dung 4 11 zeigt die Selektion der Symboltypen innerhalb der Excel Analysedate Damit haben wir einen Kandidaten fur die Modellierung der ausgew hlten Entitat Bezie hung Entit t Gruppe festgelegt Ob er wirklich geeignet ist wird erst die Betrachtung der m glichen Beziehungstypen zeigen Ermittlung eines semantisch passenden Beziehungstyps Innerhalb der Oracle BPA Suite existieren zwei Arten von Beziehungen Je nach gew hlter Modellierungsvorgehensweise erstellen Sie im Werkzeug E direkte Beziehungen zwischen Objekten graphisch auf einem Diagramm oder E indirekte Beziehungen zwischen Objekten ber eine Hinterlegung eines anderen Dia gramms implizite Beziehung In der Regel verwenden Sie direkte Beziehungen durch graphische Verkn pfung von Ob jekten auf einem Diagramm Dazu m ssen auspr gbare Beziehungstypen vorhanden sein mit deren Hilfe Symboltypen graphisch auf dem gew hlten Diagrammtyp verbunden wer den k nnen Zur Ermittlung graphisch auspr gbarer Beziehungstypen wechseln Sie auf das Arbeitsblatt Beziehungstypen in der Excel Analysedatei Schr nken Sie dort die Inhalte mit der Filter funktion auf den gewahlten Modelltyp und die gewahlten Quell und Zielsymboltypen ein Mit Hilfe der Pfeile zur Symbolisierung der Leserichtung einer Beziehung innerhalb Ihres individuellen Metamodells k nnen Sie die Quell und Zielsymboltypen einfach ermitteln Nachdem Sie das Selektionsfens
271. n Geschaftsobjekten sind weiterhin die Gesch ftsobjekte Warenbegleitpapiere und Material erkennbar die mit anderen Hauptprozessen korrespondieren Rechnungspr fung und Materiallogistik Verwenden Sie bei der Modellierung der 3 Instanzgranularitat die Vorgaben aus Tabelle Sa 93 5 Das Grundmodell Externe Prozesse 3 Instanzgranularitat Hauptprozessebene VVareneingang Interne Prozesseben 2 Material z3 arenbegleit Rechnungs arenreklamation papiere pr fung Waren reklamation amp Lieferanten l E a ae rareneingangskontrollk Material gt Materiallogistik lieferung amp Abbildung 5 5 Exemplarische Darstellung einer Hauptprozessinstanzebene Wertsch pfungsketten diagramm Tabelle 5 5 Inhalt und Abgrenzung der Hauptprozessebene 3 Instanzgranularit t Benennung der Name des bergeordneten Hauptprozesses Die Benennung sollte als substantiviertes Verb 3 Instanzgranularit t erfolgen malt Beschreibung der Unterprozesse eine Hauptprozesses Genutzte Objekttypen Prozess oder Aktivit tsobjekt Das Prozess oder Aktivit tsobjekt beschreibt dynamische Vorg nge Gesch ftsobjekt Das Gesch ftsobjekt beschreibt die im Rahmen der Prozessdurchf hrung Dynamik bearbeiteten statischen Objekte Beziehungsobjekt zwischen Prozess Das Beziehungsobjekt beschreibt die Beziehung oder Aktivit tsobjekt und Gesch fts zwischen Prozess oder Aktivit tsobjekten und objekten Gesch ftsobjekten Die Be
272. n SOA stammt von OASIS Organization for the Advancement of Structured Information Standards Service Oriented Architecture SOA is a paradigm for organizing and utilizing dis tributed capabilities that may be under the control of different ownership domains Oasi06 Die OASIS Definition ist IT neutral Es gibt keinen Zwang Services mit IT zu realisieren Dementsprechend ist es auch m glich eine rein fachliche SOA zu erstellen In der Praxis haben wir diese Bestrebung jedoch noch nicht sehen k nnen Oft wird sogar nicht nur eine SOA angestrebt sondern direkt das aufbauende Konzept der Prozessautomatisierung ins Visier genommen Damit baut sie konzeptionell auf den zu unterst tzenden fachlichen Gesch ftsprozessen auf und unterst tzt diese durch automatisierte technische Gesch fts prozesse SOA aus fachlicher Sicht Unter SOA aus fachlicher Sicht verstehen wir zun chst die Zerlegung fachlicher Ge schaftsprozesse in Aktivit ten die servicebasiert unterst tzt werden k nnen In einer wei 17 2 Integrierte Modellierung fur EA BPM und fachliche SOA 2 3 ter gefassten Betrachtung werden dem Bereich der fachlichen SOA noch das Service Level Management und Governance Themen rund um die Verwaltung der eingesetzten Services zugeordnet Zu beachten ist dabei dass eine SOA aus fachlicher Sicht eine IT neutrale Beschreibung eines fachlichen Sachverhalts darstellt SOA aus technischer Sicht Die technische Perspektiv
273. n benutzerdefiniertes Attribut beachten sind auf dem Objekt Softwareservicetyp angelegt werden 188 7 6 Das Wichtigste in Kurze Allgemeine und technische Informationen zu Serviceoperationen Ein Service kann mehrere Operationen besitzen Diese Informationen werden je Operation gepflegt Information Beschreibung BPA Suite Operationsname Name der Operation Attribut Name auf dem Objekt Softwareservice Operationstyp Operations Beschreibung zur Attribut Beschreibung Definition auf dem beschreibung Operation Objekt Softwareservice Operationstyp Prozessaktivitat Funktion im Prozessmo Ist Uber die Verbindungen im Modell mit der dell welche durch diese Funktion verbunden Operation realisiert wird Input Output Technische Reprasentation Werden im Modell als Entitaten mit dem Datenobjekte der Input und Output Softwareservice Operationstyp verbunden Objekte Besser geeignet ist ein Link zu einem technischen Schnittstellendokument Vorbedingungen Voraussetzungen fur die Es muss ein benutzerdefiniertes Attribut auf Ausfuhrung der Operation dem Objekt Softwareservice Operationstyp angelegt werden Nachbedingungen Auswirkungen der Opera Es muss ein benutzerdefiniertes Attribut auf tion dem Objekt Softwareservice Operationstyp angelegt werden 7 6 Das Wichtigste in Kurze Services kapseln Leistungen und machen sie fur Konsumenten tber Abteilungs oder Unternehmensgrenzen hinweg nutzbar Durch die Kaps
274. n der sp teren Systembenutzer geben soll Dabei bestehen bestimmte Anforderungen an dieses Fachkonzept sowohl inhaltlicher als auch formeller Natur 6 4 1 1 Inhaltliche Anforderungen an ein Fachkonzept Die inhaltlichen Anforderungen sollten teilweise durch die Modellierung erf llt werden indem durch Vorgabe einer bestimmten Modellierungsmethodik E die Verst ndlichkeit bei allen Beteiligten E die Vollst ndigkeit E die Klarheit sowie E die Strukturiertheit bestimmter Anforderungen verbessert wird E Das Ganze jedoch wie erw hnt unter der Voraussetzung der Wirtschaftlichkeit Der letzte Satz macht deutlich dass es in einem Fachkonzept stets Inhalte gibt die sich entweder nicht sinnvoll modellieren lassen oder deren Modellierung zumindest nicht mehr wirtschaftlich ist 6 4 1 2 Formelle Anforderungen an ein Fachkonzept Ausgehend von der Feststellung dass ein Fachkonzept ein geschriebenes Dokument ist muss neben einer Modellierungsmethodik auch ein Vorgehen entwickelt und implemen tiert werden das festlegt w e die modellierten Inhalte in das Fachkonzept Dokument ber tragen werden Zu diesem Zweck wird das so genannte Reporting genutzt das jedes Mo dellierungswerkzeug zur Verf gung stellen muss Dabei wird in Skripten festgelegt wel che Inhalte aus der Modellierungsdatenbank abgefragt werden und wie diese Inhalte in einem bestimmten Ausgabeformat z B doc xls html etc dargestellt werden Hier ist die Verbindung zu
275. n einer SOA Eine SOA bringt vielf ltigen Nutzen H ufig ergibt sich der Nutzen einer SOA nicht direkt aus der SOA selbst sondern aus den auf ihr aufbauenden Konzepten Z B der Prozessau tomatisierung Diese Aspekte sind hier dennoch zusammengetragen da SOA die Grund lage daf r ist Nutzen f r die Fachabteilungen E Reduktion von Redundanzen Durch Publizieren der Services ist das Risiko geringer Services doppelt zu imple mentieren Einheitliche Services verhindern auch eine unterschiedliche Implementierung der gleichen Leistung z B Berechnung von Kennzahlen Die Kennzahlen sind so bes ser miteinander vergleichbar 167 7 Identifizierung und Modellierung fachlicher Services fur SOA 168 E Agilere und flexiblere Gesch ftsprozesse und dadurch erh hte Innovationsf higkeit Technologisch implementierte Prozesse 1m Sinne einer SOA sind einfach und flexibel umzustellen Dies ist wichtig fur die Innovationsf higkeit Z B m ssen Marketing Ideen schnell umsetzbar sein Die Produkteinf hrungszeit auch time to market genannt kann verk rzt werden Durch die Entkopplung der einzelnen Prozessschritte aus einem Anwendungssys tem k nnen diese auch in anderen Prozessen wiederverwendet werden Durch die Nutzung oder Wiederverwendung der Bausteine geht es weg von der blichen Anwendungsentwicklung hin zur Prozessimplementierung Die Bausteine k nnen schneller und leichter 1m Prozess neu positioniert oder in
276. n fachlichen Inhalten und der Informationstechnologie Die Anwendungssystem Architektur Die Anwendungs Architektur zeigt auf welche informationstechnologische Unterst tzung ben tigt wird um das betriebswirtschaftliche Ziel des Unternehmens zu erf llen Sie be schreibt auf hoher Ebene die in der betrachteten Organisation vorhandenen Softwarel sun gen und deren Beziehungen untereinander 13 2 Integrierte Modellierung fur EA BPM und fachliche SOA 14 Die Infrastruktur Architektur Die Infrastruktur Architektur beschreibt die erforderliche IT Infrastruktur zum Betrieb der Anwendungssystem Architektur und damit das IT technische Fundament einer Organisati on H ufig taucht in diesem Zusammenhang die Frage auf wie Anwendungssystem und Infrastruktur Architektur voneinander abgegrenzt werden k nnen Geh rt zum Beispiel eine Datenbanksoftware zur Anwendungs oder Infrastrukturarchitektur Wir ordnen aus diesem Grund alle Softwareprodukte die nicht direkt an der Wertsch pfung der Gesch fts architektur beteiligt sind der Infrastruktur Architektur zu 2 2 1 2 EA im Kontext dieses Buches S e erkennen an den verschiedenen Architekturebenen dass eine Enterprise Architecture einen breiten Bereich an Informationen rund um das betrachtete Unternehmen abbilden kann Um uns nicht n der Modellierung zu verlieren m ssen wir die Enterprise Architec ture m Einsatzbereich einer BPM und SOA Modellierung deutlich eingrenzen F r die E
277. n l sst sich der interne Aufbau eines Systems gut durch die Modellierung einer Systemarchitektur im Sinne einer fachlich sinnvollen Zu sammenfassung von Masken zu Modulen abbilden Module kapseln dabei bestimmte fach liche Funktionalit ten und k nnen so bspw unabh ngig von anderen Modulen implemen tiert und getestet werden Eine solche fachliche Zusammenfassung von Masken zu Modu len kann sp ter auch als sinnvolle Men baumstruktur verwendet werden Dar ber hinaus kann durch den Aufbau einer solchen Gesamtsystemstruktur die Gefahr verringert werden dass Masken vergessen werden die nicht direkt die aus dem Fachprozess abgeleiteten Funktionalit ten unterst tzen sondern bspw zur Systemadministration ben tigt werden Abbildung 6 7 zeigt ein Beispiel f r die Modellierung einer Systemstruktur Anwendungs Modul 1 Maske 1 system Maske 2 Maske 3 Modul 2 7 Maske 4 Abbildung 6 7 Systemstruktur ein Beispiel 6 3 4 3 Maskenfl sse Ein weiteres Beispiel f r eine Systemkomponente die sich zur Darstellung durch ein Mo dell eignet ist die bersicht der Maskenfl sse Diese stellen die m glichen Navigations pfade innerhalb des Systems dar Dabei sollten sich die Maskenfl sse bei der systemseiti gen Bearbeitung der Fachprozesse bereits aus dem Systemablauf ergeben Dar ber hinaus m ssen
278. nbelichtung Druck und Bindung K sel Krugzell Ausstattung patentrechtlich gesch tzt K sel FD 351 Patent Nr 0748702 Printed in Germany ISBN 978 3 446 41735 9 Inhalt VOFWOTL 2a nenne ee IX Die AUT a EEE ISA LEERE ee EEE XI 1 EINIEIEUNG riena a E 1 1 1 Warum Modellierung aes sone menace at ace tes aa een l 1 2 Was Ist Crocnblich ein Model au EE ieee A Meenas 2 1 3 Warum Standards und Reseln tz u eo ete te ees kee NIE 2 1 4 Was stein diesem Buch finden unseren 3 13 Wassie in diesem Buch nicht MMe nm euere nu 4 1 6 Welches Vorwissen sollten Sie besitzen a leisen ad a Ea 4 1 7 Dasanteonierte Beispielen unten ne nes N es aoe es 5 2 Integrierte Modellierung f r EA BPM und fachliche SOA uuuzruusn n0nnnnnnnenn 7 2 Fragen die dieses Kapitel beanlworkel 2 2 ans url 7 22 Management Fachbereiche und IT jeder ist anders uuuseeeeeeeeeeeeeeeeeeeeeeeeneeeeneneeneeeeeeneen 7 2 2 1 Inhalte f r die Enterprise Architecture Modellierung u nennen 11 22 2 nhale urde BPM Modellierung zu ine N E 14 2 2 3 Inhalte f r die fachliche SOA Modellierung uuuuusseeeeeseeeeeeeeeeeeeeeeneeeeeeeeenenn 16 23 Grunds tzliche Gliederung eines integrierten Modells een 18 25s Artelakttypen der M delheruns m senns une Bean 19 2 3 2 Schnittmengen und symmetrische Differenz der Modellierungsbereiche 21 2 3 3 Semantische Zuordnung verschieden
279. nd vertikale Dekomposi tion der 1 bis 5 Instanzgranularit t 5 Instanzgranularit t Detailprozessinstanz optional Fachliche Detailmodelle vertikale Dekomposition 5 2 Aufbau des Grundmodells Fur die fachlichen Detailmodelle beschreiben Sie die einzelnen Arbeitsschritte zur Bear beitung des bergeordneten Unterprozesses Dabei sollten Sie nicht mehr als 20 bis 40 Prozessaktivitaten verwenden Ermitteln Sie zur Identifizierung der relevanten Prozess aktivitaten zun chst alle Arbeitsschritte zur Durchf hrung des Unterprozesses Achten Sie dabei auf m glichst gleiche Granular t t und eine IT neutrale Beschreibung Es bietet sich an hierf r in einem Brainstorming zun chst die zum betrachteten Unterprozess zugeh rigen Aktivit ten zu identifizieren Sortieren Sie diese anschlie end nach ihrem zeitlich logischen Zusammenhang Bewerten Sie anschlie end f r jede ermittelte Aktivit t ob sie zu der zugeh rigen Prozessinstanz der Hauptprozessebene die passende Granularit t be s tzt Was bedeutet dass jede Aktivit t der beschriebenen Unterprozessinstanz direkt einen Teilarbeitsschritt zur Bearbeitung der bergeordneten Hauptprozessinstanz leistet Dar ber hinausgehende Detaillierungen der Aktivit ten sind nicht zul ssig Betrachten wir exemplarisch den in Abbildung 5 8 dargestellten Prozess Wareneingangs kontrolle Eine Instanz der Hauptprozessebene ist ein Wareneingang Das bedeutet die Anlieferung von Ware unt
280. nd Aktivitaten werden zu einer Entitat Prozess und die Ob jekttypen Unternehmen und Abteilung zu einer Entitat Organisationseinheit zusam mengefasst da sie Inhalte gleicher Gattung abbilden Die Objekttypen Anwendung Daten Server und Datenbank werden allgemeiner for muliert in jeweils eine eigene Entit t bertragen Durch die allgemeinere Form der Be schreibung dieser Entit ten w rd unser Metamodell flexibler Beispielsweise kann eine Entit t Hardwareressource ein breiteres Spektrum an Inhalten aufnehmen als eine En titat Server es k nnte m Die Objekttypen Person und Standort bernehmen wir unver ndert An dieser Stelle m ssen w r besonders darauf hinweisen dass die vorgenommene Umset zung der Objekttypen in Entit ten des Metamodells nur exemplarisch ist In Ihrer individu ellen Domain Level Matrix kann es durchaus erforderlich sein andere Entit ten zu bilden Beispielsweise k nnten Sie argumentieren dass die Entitat Hardwareressource die in un serem Fall neben Servern auch Inhalte zu Routern Massenspeichern und so weiter enth lt nicht ausreichend auf serverspezifische Inhalte eingehen kann ohne in Konflikt mit ande ren dort abgelegten Inhalten zu geraten Je allgemeiner Sie die Entit ten des Metamodells beschreiben bzw zusammen fassen desto allgemeiner werden zwangsl ufig auch die m glichen Attributierun gen der Entit ten Dadurch verringert sich die Komplexit t Ihres Metamodells doch nimmt gleichze
281. nd Alerting Process Monitoring Erfolgsfaktor Eskalation schneller beheben Ad hoc Analysen Process Mining Erfolgsfaktor Optimierungspotenzial aufdecken Dash Board Prozess Cockpits Erfolgsfaktor Benchmarking Tabelle 9 5 Benutzte Methodenobjekte der Oracle BPA Suite Modellname Gesch ftsziele PC Reduktion der Durchlaufzeit der WEK um 20 Diagrammtyp Zieldiagramm Symbol Ziel Erfolgsfaktor 241 9 Entwurf und Aufbau prozessgetriebener Kennzahlensysteme Reduktion der Durchlaufzeit WEK um 20 Zieldiagramm Geschaftsziele PC Zieldiagramm Verbesserung Reduktion der Prozesseffizienz Durchlaufzeit der WEK um 20 geh rt zu Verbesserung der Prozessqualit t ist Erfolgsfaktor f r Eskalation schneller beheben geh rt zu Erh hung der Kundenzufriedenheit ist Erfolgsfaktor f r Optimierungs potenzial aufdecken geh rt zu Termintreue ist Erfolgsfaktor f r 2 Benchmarking geh rt zu Senkung der Prozesskosten geh rt zu Reduktion der Durchlaufzeit Reduktion der geh rt zu Durchlaufzeit der WEK um 20 Abbildung 9 12 Modellierung der Ziele und Erfolgsfaktoren Fur eine Einarbeitung in die Methodik zur Bestimmung von Erfolgsfaktoren aus definier ten Unternehmenszielen empfehlen wir die Ausarbeitung in SER04 oder auch mit prakti schen Beispielen f r die Modellierung bei Schi09 S 89ff 9 7 1 2 Modellierung der Kennzahlenhierarchie Begleitend erfolgt nun die Modell
282. nd Benutzer darstellt hat sie nach der Funktionalit t den gr ten Einfluss auf die sp tere Akzeptanz des Systems denn sie stellt den Teil des Systems dar den der Benutzer direkt sieht und auf dem er seine Arbeit ausf hrt F r den System Realisierer stellt jede Beschreibung der Benutzerschnittstelle eine Hilfe bei der Realisierung dar Neben der Frage nach der Detaillierung der Maskenbeschreibung die vor allem aus Sicht des Fachbereichs relevant ist interessiert er sich jedoch auch f r die Frage bez glich der Umsetzung und des Werkzeugs zur Maskenbeschreibung Stan dardmodellierungsmethoden die f r die Prozessmodellierung eingesetzt werden bieten in der Regel Methoden zur Modellierung einer ganzen Unternehmensarchitektur so auch zur Modellierung von Masken bis hin zur Modellierung eines vollst ndigen Maskenlayouts Viele Softwareentwickler verwenden jedoch andere Tools zur grafischen Modellierung von Masken die h ufig den Vorteil haben dass sie das grafische Modell sofort n ein ent sprechendes Ger st aus Quellcode umwandeln k nnen Die Frage nach der Umsetzung der Maskenbeschreibung kann also abh ngig von den spezifischen Anforderungen beant wortet werden darf jedoch auf die wesentlich wichtigere Frage nach Art und Detaillierung der Maskenbeschreibung keinen einschr nkenden Einfluss nehmen 6 3 Die IT Sicht und ihr Zusammenhang mit der Fachsicht 6 3 4 2 Fachliche Systemarchitektur Neben der Beschreibung einzelner Maske
283. nd ihr Zusammenhang mit der Fachsicht bekannte und etablierte Arbeitsweise beibehalten kann Auf diese Weise wird sicherge stellt dass das System von der Fachabteilung nicht nur akzeptiert sondern gerne genutzt wird weil man eine direkte Arbeitserleichterung erreicht und die Fachabteilung das Gef hl hat an der Entwicklung der IT Losung direkt beteiligt gewesen zu sein Je enger Sie den Fachbereich in die Konzeption des Systems einbeziehen desto gr er wird die Akzeptanz der neuen IT L sung sein da die Mitarbeiter das Ge fuhl haben an der Entwicklung der Losung beteiligt Zu sein Auf Seiten der IT Abteilung bzw des IT Dienstleisters der das System sp ter realisieren soll liegt eine sehr gute weil genaue und vollstandige Implementierungsgrundlage vor uber die mit dem Fachbereich direkt gesprochen werden kann da sie von beiden Seiten verstanden wird Abbildung 6 4 zeigt den Zusammenhang zwischen der Fach und der IT Sicht Der Use Case stellt die Verbindung zwischen Fach und IT Prozess dar N 2 Maske Funktion Funktion Fachbegriff Fachbegriff Fachbegriff i Maske D Funktion Ereignis Fachbegriff Die Ein und Ausgabedaten aus dem Systemablauf m ssen den Typ Ein und Ausgabeinformationen Anwendungssy i Maske Funktion Fachbegriff des Fachprozesses entsprechen stem oder Detaillierungen dieser darstellen
284. ndelt Automatisierte Aufgabe Modellieren Sie im fachlichen IT Modell als Vorlage fur die Implementierung in Oracle BPEL fachlich abgegrenzte Prozessschritte Beispiel Reservierungen berpr fen in Abbildung 8 11 Die konkrete Implementierung dieses Prozess schrittes die unter Umst nden mehrere Web Service Aufrufe Datentransforma tionen usw beinhalten kann sollte dem SOA Entwickler berlassen werden Bei Einsatz des Generierungsmechanismus in der Oracle BPA Suite k nnen die fachlichen abgegrenzten Prozessschritte in BPEL Scope Aktivit ten bertragen werden Den Inhalt dieser Scope Aktivit ten kann der SOA Entwickler dann ent sprechend seinen technischen Anforderungen f llen ohne Einfluss auf das fach lich spezifizierte Modell zu nehmen Nutzen Sie diesen Modellierungsansatz wenn Sie ein Modell als Vorlage f r die IT technische Umsetzung im Oracle BPEL Process Manager erstellen m chten Sie implementierungsspezifische Details wie Web Service Schnittstellen oder Konfigurationen fur die Workflow Anwendung Human Task in der Oracle BPA Suite hinterlegen mochten Sie den Generierungsmechanismus BPMN zu BPEL oder alternativ EPK zu BPEL in der Oracle BPA Suite nutzen m chten 8 4 SOA Prozessmodellierung in der Oracle BPA Suite 8 4 3 berblick Objekttypen der SOA Prozessmodellierung Die folgende bersicht vgl Tabelle 8 1 listet abschlie end die im vorgestellten Vorge hen zur serviceorientie
285. ne m gliche Darstellungsform und Berechnung f r das exemplarische Metamodell Starten Sie beim Aufbau der Tabelle mit den Entit tstypen und erfassen Sie erst nach deren vollst ndiger Ermittlung die Beziehungen Tabelle 3 9 Sch tzung des Modellumfangs und Modellerstellungsberechnung Beispiel Entit t Beziehung Aufwand zur Faktor zur Erstellungs Ermittlung Ber cksichtigung aufwand je Entit t je Entit t der Ungenauigkeit oder Beziehung oder Beziehung Anwendungssystem Hardwareressource Gesch ftsobjekt Organisationseinheit Person Prozess meseme fa os I ES 0 2 unterst tzt Prozess Anwendungssystem 0 0 bearbeitet Gesch fts objekt Anwendungssystem lauft auf Hardware Organisationseinheit ist zusammengesetzt aus Organisations einheit Organisationseinheit 0 0 greift zu auf bearbeitet Geschaftsobjekt Organisationseinheit befindet sich an Standort Person ist zugeordnet Organisationseinheit Person ist verantwort 0 1 lich fur Anwendungs system 99 3 Aufbau des Metamodells 96 Entit t Beziehung Anzahl Aufwand zur Faktor zur Erstellungs Ermittlung Ber cksichtigung aufwand je Entit t je Entit t der Ungenauig oder Beziehung oder Beziehung Prozess ist zusam mengesetzt aus Prozess Prozess ist Vorg nger 400 3 von Prozess Softwareressource 50 0 1 1 5 nutzt Hardware ressource Gesch tzter zeitlicher Aufwand zur Erstellung des EA Modells Stunden 312 8 In unse
286. nem umfassenderen neuen Modell beschrieben werden Gesch ftsziel entwickelt Hier kann ein Hinweis Link zum Business Case hinzugef gt werden Organisatorische Informationen Information Beschreibung BPA Suite Service Verantwortliche Person oder Rolle Verbindung zwischen Gesch ftsservice besitzer und organisatorischem Objekt z B Stelle Die Verbindung ist vom Typ ist verantwortlich f r Service Business Analysten die den Es muss ein benutzerdefiniertes Attribut designer Service designt haben auf dem Objekt Gesch ftsservice ange legt werden Service Serviceentwickler Entwicklungs Es muss ein benutzerdefiniertes Attribut entwickler abteilung oder Dienstleister auf dem Objekt Softwareservicetyp an gelegt werden Service Liste mit Konsumenten Wenn die Verbindung zwischen Gesch ftsservice konsumenten Konsumenten bekannt sind ist und einem organisatorischen Objekt eine Liste mit den Konsumenten z B Stelle Die Verbindung ist vom zu empfehlen So k nnen nde Typ kann Anwender sein rungen am Service rechtzeitig kommuniziert werden Dom ne Dom ne in der sich der Service Wird durch die Dom nendekomposition befindet abgebildet Die Verbindung ist vom Typ umfasst 187 7 Identifizierung und Modellierung fachlicher Services fur SOA Information Beschreibung BPA Suite Domanen Verantwortliche Person oder Rolle Die Domane wird durch ein Objekt vom besitzer der Domane Typ Geschaftsservice reprasentie
287. nen eine unabh ngige Kennzahl Neben der Beschreibung der Kennzahlenhierarchien ver suchen wir bereits an dieser Stelle die Beziehungen Hooks zu den IT Systemen zu set zen Bei der Definition der PDauer WEK halten wir bei der Modellierung die Regeln zur Bildung der Kennzahl fest sowie in einem Kennzahlenzuordnungsdiagramm den ben tig ten Input zur Bildung der Kennzahl In diesem Fall sind es die Endpunkte des WEK Pro zesses Im ersten Schritt weisen wir der Kennzahl PDauer WEK den Erfolgsfaktor zu den sie messen soll Hierdurch ist das Alignment mit den Gesch ftszielen erreicht Im n chsten Schritt wird die Kennzahlenhierarchie erstellt Alle ben tigten Auspr gungen der Kenn zahl werden mit der Wirkt auf Kante in einer Hierarchie zusammengefasst Damit wir im Folgenden einen Verweis der Kennzahl auf den zu messenden Prozess haben weisen wir als ist Input zu das Objekt MP WEK Start und WEK End als ERM Objekt zu Tabelle 9 6 Benutzte Methodenobjekte der Oracle BPA Suite Modellname Kennzahlen PC Kennzahlenerfassung PDauer WEK Diagrammtyp Kennzahlenzuordnungsdiagramm Symbol Kennzahlinstanz Strategisches Ziel ERM Attribut 243 9 Entwurf und Aufbau prozessgetriebener Kennzahlensysteme 244 F r eine Einarbeitung in die Methodik empfehlen wir die Ausarbeitung in Sche04 und Sche05 sowie f r das Thema der Kennzahlenhierarchie und der Vererbung der Kennzah leneigenschaften Mele05
288. nennnenneenneneennen 123 6 3 2 Entwicklung und Modellierung der Soll Prozesse uuueeeeeeeseeeeeeeeeeeeeeeeeeeeeenen 125 6 3 3 Systemablauf Das fachliche Systemverhalten 000000000eneneennnneennnnn 127 6 3 4 Beschreibung statischer Systemkomponenten uuusseseessesenenennnnnnnnnnnnnnnnnnn nenn 130 Vom Modell zum Fachkonzent icici seen a a 137 6 4 1 Anforderungen an ein Fachkonzept uneenneseeenenenenennnnnnnnnnnn nenn 137 6 4 2 Nicht modellierte Bestandteile eines Fachkonzepts uunneeeeeeneenenenennnnnneennnnnn 138 6 4 3 Gliederungsvorschlag f r ein Fachkonzept uueeeeeeeeeeeeeeeeeeeeeeeeennenennenneeeneennennnn 139 Erstellung eines Fachkonzepts mit der Oracle BPA Suite ssssssssssssssnsnnnnnnnnnnnnn 140 631 Fachprozess ss 2 en are 140 0 32 Systemablauf arts ee eu 142 65 3 Slalische Systemk Omponenten cent 2sccte sc asce cts cache tesant a a tes 146 Identifizierung und Modellierung fachlicher Services f r SOA 0000 153 Zentrale Fragen dieses Kapitels aueh ee Ep al 153 SEIVIEES UNE DS OR nee een en een Tender ende een 153 1 2 1 Was Ist EIn SCIVICC ara Ben aa lines heiiensih 154 1 22 Missveist andnis SeN Ea maae A aa 155 7 2 3 Atomare und zusammengesetzte SerVices cseeeeenenennnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn na 156 124 W381sle me SUA eine nennen heran ee ee eenere een 156 7 3 7 4 RD 7 6 8 1 8 2 8 3 8 4 9 1 9 2 9 3 9 4
289. nente wel cher dem Symboltyp Typ Hardwareressource zugrunde liegt 6 Die zweite M glichkeit Beziehungen zwischen Objekten der Oracle BPA Suite aufzubauen basiert auf indirekten Verkn pfungen durch Hinterlegung eines Diagramms zu einem Objekttyp Dadurch wird immer eine Beziehung bergeordnete Objekte und bergeordnete Modelle im hinterlegten Diagramm erstellt Sie k nnen diese Beziehung im Eigenschaftsfenster der Oracle BPA Suite anzeigen Zus tzlich erstellt die Oracle BPA Suite bei einigen Objekt und Diagrammtypen automatisch eine typisierte Be ziehung zwischen dem Ausgangsobjekt und den im untergeordneten Diagramm ausgepr gten Objekten Beispielsweise erzeugt die Hinterlegung einer EPK zu einem Wertsch pfungskettenobjekt implizite Be ziehungen zwischen dem Wertsch pfungskettenobjekt und den Funktionen der EPK Dieses Verhalten ist aber nicht bei jeder Hinterlegung vorhanden sondern existiert nur bei einigen Hinterlegungen Wei tergehende Informationen zu automatisch angelegten impliziten Beziehungstypen finden Sie im Oracle BPA Suite Methodenhandbuch bzw der Online Hilfe Die zur Erzeugung individueller Attribute erforderlichen Schritte entnehmen Sie bitte dem Handbuch oder der Online Hilfe des Werkzeugs 4 5 Vorgehensweise zur Ermittlung Ihrer individuellen Oracle BPA Suite Methode x Cs a 4 i inl E reiugen kerlenl ycen Formeln Daten Ubeiprufen ar Friwithieleolt Anabel 7 X As Access ia 5 Verbindumge
290. nhang mit der Fachsicht Maske Eingabe 1 J Eingabeparameter Eingabe 2 A Eingabeparameter Auswahl 1 R Auswahlparameter ion 2 Maskentabelle Abbildung 6 5 Maskenstruktur ein Beispiel Liegen konkrete Anforderungen an das Maskenlayout vor so hat der Fachbereich nicht nur sehr genaue Vorstellungen was auf einer Maske angezeigt werden soll sondern auch wie die Darstellung zu erfolgen hat Bei der Beschreibung eines Maskenlayouts wird ein Bild der Maske erstellt in dem zu erkennen ist welche Daten Schaltfl chen Grafiken und sonstigen Objekte wo auf der Maske anzuordnen sind und wie diese Objekte dargestellt werden sollen Liegen konkrete Anforderungen in dieser Form vor so stellt ein Modell des Maskenlayouts eine gute Diskussionsgrundlage f r Gespr che mit dem Fachbereich dar n denen die Anforderungen direkt berpr ft und ggf noch einmal ge ndert oder erg nzt wer den k nnen siehe Abbildung 6 6 131 6 Modellgest tzte fachliche Konzeption individueller IT Systeme 132 _ Daten Layout Funktionen Eingabe 1 Fachbegriff O Eingabe 2 Fachbegriff e1 5 Auswahl 1 ka Fachbegriff ES Spalte 1 Spalte 2 Fachbegriff Abbrechen OK gt Funktion Abbildung 6 6 Maskenlayout ein Beispiel Weil die Benutzeroberfl che die Schnittstelle zwischen System u
291. nheft erstellt in dem er beschreibt was und wof r er etwas haben m chte Bas erend auf diesen Vorgaben erstellt der Auftragnehmer ein Pflichtenheft in dem er spezifiziert wie er die Anforderungen aus dem Lastenheft um zusetzen gedenkt Den Anforderungen aus dem Lastenheft stehen dabei jeweils Leistungen aus dem Pflichtenheft gegen ber Da wir ein Fachkonzept als eine vollst ndige Anforderungsbeschreibung f r ein IT System verstehen sollte es neben den funktionalen Systemanforderungen und Systemschnittstellen auch die bereits erl uterten nicht funktionalen Systemanforderungen umfassen Grunds tz lich sollten alle bestehenden und bekannten Anforderungen beschrieben werden Diese k nnen bspw auch spezielle Anforderungen an die Sicherheit z B Datenschutz Analyse von Risiken d e auf das System wirken an das Administrationskonzept an den Testbe trieb z B Bereitstellung von Testdaten an die Inbetriebnahme z B Erstellung von Do kumentationen Erstellung eines Schulungskonzepts und an den Betrieb des Systems um fassen 6 4 3 Gliederungsvorschlag f r ein Fachkonzept Nachdem nun die Bestandteile eines vollst ndigen Fachkonzepts beschrieben und erl utert worden sind schlagen wir folgende grobe Gliederung zur Orientierung vor 1 Allgemeine Rahmenbedingungen insbesondere Beschreibung der Ziele inhaltliche Abgrenzung Einordnung in den Gesamtprojektplan 2 Analyse der Ist Fachprozesse insbesondere Beschreibung der zu b
292. nicht direkt in die Oracle BPA Suite bertragen k nnen Aus Sicht eines integrierten EA BPM und fachlichen SOA Modells ist es erforderlich alle Inhalte in einem Repository abzubilden Es gilt also einen Kompromiss zwischen den werkzeugneutralen Anforderungen Ihres individuellen Metamodells und den vorhandenen F higkeiten des Metamodells der Oracle BPA Suite zu finden Damit S e das vorhandene werkzeugneutrale Metamodell mit den M glichkeiten der Ora cle BPA Suite Methode effizient abgleichen k nnen empfehlen wir die Nutzung einer Excel basierten Methodenanalyse Sie erm glicht Ihnen schnell und einfach passende Modellartefakte zu bestimmen alternative Modellierungsm glichkeiten zu finden und nicht l sbare Konflikte zu identifizieren Das erforderliche Excel Sheet erstellen Sie mit Hilfe der Oracle BPA Suite selbst F hren Sie dazu die folgenden Arbeitsschritte innerhalb der Oracle BPA Suite durch 1 Wechseln Sie zum Modul Administration 2 ffnen Sie den Bereich Konfiguration Konventionen und markieren dort den Unter ordner Filter 3 Markieren Sie m Reiter Inhalt die Gesamtmethode 4 ffnen Sie mit einem rechten Mausklick das zugeh rige Kontextmen und w hlen Sie Auswerten Report starten Abbildung 4 2 zeigt die entsprechenden Schritte zur Erzeugung des Excel Sheets innerhalb der Oracle BPA Suite Nachdem Sie Report starten aktiviert haben startet ein Assistent der Sie zunachst auf fordert den
293. nicht vollst ndig Es ist nicht m glich f r jede individuelle Modellierung allgemeing ltige Regeln zur Abbildung der Attributierung anzugeben Vielmehr m ssen Sie als Business Analyst von der Ermittlung der Prinzipien bis zur Attributierung des Metamodells jeden einzelnen Arbeitsschritt der Modellerstellung kritisch hinterfragen und ge gebenenfalls iterativ berarbeiten F r die Entit ten unseres Metamodellbeispiels legen wir die in Tabelle 3 8 aufgelisteten Attribute fest Sie k nnen diese als Startpunkt f r eigene Attributierungen eines EA Metamodells verwenden Bitte beachten Sie aber dass es sich um eine beispielhafte Defi nition von Attributen handelt die keinen Anspruch auf Vollst ndigkeit erhebt Tabelle 3 8 M gliche Attribute f r Metamodell Entit ten Bespiel 52 3 2 Der werkzeugneutrale Modellentwurf 3 2 5 Absch tzung des Modellumfangs und Erstellungsaufwands Nachdem das Metamodell inklusive der erforderlichen Attribute definiert ist stellt sich meistens die Frage welchen Aufwand die F llung des Modells mit Inhalten wohl erzeu gen wird Auch wenn meist eine genaue Aussage hinsichtlich der erforderlichen Personen tage f r die Erstellung des Modells nur mit gr erem Aufwand zu ermitteln ist so kann man dennoch mit Hilfe einer N herung gut absch tzen welche Gr enordnung zur initia len Erstellung voraussichtlich zu erwarten ist Dazu m ssen Sie zun chst bestimmen welches Volumen Ih
294. nichts ndert In diesem Fall stellt der fachliche Ist Prozess gleichzeitig bereits den fachlichen Soll Prozess dar und es kann so fort mit der Beschreibung der IT Sicht gestartet werden Durch die Trennung zwischen Fach und IT Sicht bei der Modellierung kann eine technische L sung unabh ngig von der Darstellung des betroffenen Fachprozesses entwickelt werden wobei dieser und insbeson 6 3 Die IT Sicht und ihr Zusammenhang mit der Fachsicht dere die Schwachstellen im oben genannten Beispiel der hohe manuelle Aufwand durch die Arbeit mit Papier und Bleistift nat rlich die Anforderungen an die IT Sicht vorgibt Ein fachlicher Soll Prozess ist nur in den F llen zu entwickeln in denen der Fach prozess sich durch die Einf hrung einer neuen IT L sung tats chlich ndert 6 3 3 Systemablauf das fachliche Systemverhalten Die Fachprozesse sind nun modelliert und die Stellen an denen Unterst tzung durch ein IT System ben tigt wird sind identifiziert und an den entsprechenden Stellen im Fach prozessmodell eingef gt Diese Stellen werden als direkte Verbindung der Fach mit der IT Sicht verwendet Die ben tigte IT Unterst tzung kann nun an den ben tigten Stellen m Fachprozess weiter detailliert und modelliert werden wobei diese Detaillierung nun die technische bzw IT Sicht darstellt In dieser IT Sicht wird das dynamische Systemverhal ten in Form eines Programmablaufs dargestellt analog zum Prozessablauf n der fach lichen S
295. niert als Zusammenfas sung verschiedener Stellen einer Organisation die alle die gleiche Eigenschaft aufweisen In dem Modellierungskontext des integrierten EA BPM und fachlichen SOA Modells ist diese Eigenschaft das Recht bestimmte Funktionalit ten eines Anwendungssystems oder eines Dienstes zu nutzen 2 3 1 3 Gesch ftsobjekte Der Begriff Gesch ftsobjekt stammt urspr nglich aus der objektorientierten Softwareent wicklung Unter einem Gesch ftsobjekt verstehen wir ein Objekt der realen Welt das durch einen Gesch ftsprozess oder eine Funktion erzeugt bearbeitet oder verbraucht wer den kann Im Wesentlichen handelt es sich dabei um Datenobjekte oder Roh Hilfs und Betriebsstoffe Gesch ftsobjekte erm glichen die allgemeine Beschreibung von Ressour cen im Modell die nicht zu den Gruppen Organisationsstruktur Anwendungssysteme oder IT Infrastrukturinhalten geh ren F r die st rker informationstechnologische Modellierung im fachlichen SOA Teil des Modells werden die Gesch ftsobjekte zur Abbildung in IT Systemen detaillierter als Daten beschrieben Daten stehen immer in einer Beziehung zu einem Gesch ftsobjekt wogegen Gesch ftsobjekte nicht zwingend ein zugeordnetes Datenobjekt besitzen m ssen Zum 2 3 Grundsatzliche Gliederung eines integrierten Modells Beispiel muss das fachliche Geschaftsobjekt Kundenauftrag in ein Datenobjekt Kun denauftrag detailliert werden um es in einem IT System abbilden zu k nnen Dat
296. nischen Unter st tzung eines Fachprozesses darstellen Doch auch in einem solchen Fall m ssen die gro ben Anforderungen an die L sung die sich aus den optimalen Prozessen in der Fachabtei lung ergeben bekannt sein um berhaupt entscheiden zu k nnen ob passende L sungen am Markt existieren Ohne eine derartige Analyse ist die Gefahr sehr gro dass die aus gew hlte L sung spezielle Anforderungen der Fachabteilung gar nicht abbilden kann oder zumindest entscheidend angepasst und erweitert werden muss Und auch in diesem Fall werden die Kosten f r nachtr gliches Customizing bzw nachtr gliche Erweiterungen h her sein als f r eine gr ndliche Anforderungsanalyse zu Beginn Da wir uns auch bei der Entwicklung der Soll Prozesse noch in der Fachsicht befinden sei an dieser Stelle angemerkt dass Sie einen solchen Soll Fachprozess nur in den Fallen ent wickeln m ssen in denen der Fachprozess sich durch die Einf hrung der neuen IT L sung tats chlich ndern soll In vielen F llen soll ein bestehender Fachprozess durch die Einf h rung einer IT Unterst tzung verbessert werden ohne dass sich der fachliche Ablauf ndert So kann es sein dass eine Fachabteilung bestimmte Arbeitsschritte Funktionen durchf h ren muss und dabei noch immer mit Papier und Bleistift vorgeht Nun soll ein IT System entwickelt werden das dieselben Funktionen unterst tzt und damit erleichtert oder be schleunigt am fachlichen Ablauf an sich jedoch gar
297. nken bei der Erstellung des Grundmodells ebenfalls in einem Containerdiagramm Auch die Datenbanken innerhalb Ihres integrierten Modells k nnen Sie selbstverst ndlich eindeutig mit ihrem Namen benennen und so klar identifizieren 5 2 6 Aufbau der Grundstruktur eines integrierten Modells in der Oracle BPA Suite Um die Inhalte des integrierten Modells in der Oracle BPA Suite geordnet abzulegen ben tigen Sie eine Ordnerstruktur M glich w re die Strukturierung der Inhalte nach der Prozess Organisations Daten Anwendungs und Infrastruktur Architektur oder nach den Hauptmodellbereichen EA BPM und SOA Beide Strukturierungen halten wir nicht fur empfehlenswert Die Strukturierungen nach den Architekturebenen w rden dazu f hren dass Inhalte unter schiedlicher Detaillierung innerhalb eines Modellbereiches abgebildet werden m ssten Zum Beispiel wurden im Bereich der Prozessarchitektur fachliche und automatisierungsre levante Inhalte zusammen erfasst werden Die Gruppierung nach den Hauptmodellbereichen EA BPM und SOA w rde dazu f hren dass eine Zuordnung von Artefakten zum EA BPM oder SOA Modellteil erforderlich 111 5 Das Grundmodell 112 w re Wie wir bereits erl utert haben ist diese aufgrund der hohen Uberdeckungen der Bereiche nicht leicht vorzunehmen wodurch ein gro er Interpretationsspielraum bei der Modellierung entstehen w rde Die Strukturierung des Modells nach dem Grad der Beziehung der Inhalte zur Info
298. nnnnnnnennnn 191 8 2 2 Gr nde f r das Team BPM und SOA ucunseennseennsennnsennnsnnnnennnnennnnnnnnennnne 192 8 2 3 Serviceorientierte Prozessautomatisierung uuuuceesessnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn nn 193 Modellierung SOA geeigneter Prozessmodelle uueueeseeeeeseeseeeeseeseesesssessseseeeneeeeeeeeeeeeenn 195 8 3 L Beerittlichkeiten definieren enieen ie A T R A 195 8 3 2 Zielsetzung kl ren und Testlegen ss ende 198 8 3 3 Zielgruppen und Zust ndigkeiten abgrenzen eneeesssssesnenennnnnnnnnnnnnnnnnnnn nenn 200 8 3 4 Informationsbedarf der Zielgruppen ermitteln 201 8 3 5 Methodik und Notation ausw hlen uu00000000nenenennennnnnnennnnnnnnnennnnnnnnnn 205 SOA Prozessmodellierung in der Oracle BPA Suite sseeeenennnnnnnnnnnnnnnnnnnnnnnnnnnnn 208 8 4 1 Stets zu Diensten Fachliche Services im Prozessablauf cccccceeeeeesseeeeeees 208 8 4 2 Vorstufe zum automatisierten Prozess Das fachliche IT Modell 212 8 4 3 berblick Objekttypen der SOA Prozessmodellierung ueneeeeene 219 Entwurf und Aufbau prozessgetriebener Kennzahlensysteme 221 Fragen die dieses Kapitel beantwortet saienisi ae 221 Die Herausforderung im Process Controlling ueeeeeeeeeeeeeeeeeseeeeseeseeeesneennnennnnnneneeeneeeeeenn 221 Die zentralen Bestie er E 224 9321 ProcessC ontolline n 2 nat Zen sie ss Sales 225 9 3
299. nszyklen rasch und flexibel genug reagieren In diesem Buch erfahren Sie wie Sie als IT Manager oder CIO Ihre IT System Landschaft am Business ausrichten und erfolgreich planen und steu ern Die relevanten Kernaufgaben dabei sind das IT Bebauungsmanagement und das technische Architekturmanagement Die praktischen Anleitungen und Best Practices versetzen Sie in die Lage Ihrem Unternehmen eine IT Unterst tzung f r das Business zu marktge rechten Preisen anzubieten die flexibel auf Ver nderungen reagieren kann Mehr Informationen zu diesem Buch und zu unserem Programm unter www hanser de computer HANSER Zielfindung mit ITIL 3 martin BEIMS IT SERVICE MANAGEMENT IN DER PRAXIS od EC eT KK RS Beims ZIELFINDUNG METHODEN REALISIERUNG IT Service Management in der Praxis mit ITIL 3 327 Seiten Flexcover ISBN 978 3 446 41320 7 HANSER Die IT hat sich zunehmend zu einem kritischen Erfolgsfaktor f r funktio nierende Gesch ftsprozesse in Unternehmen entwickelt Das stellt IT Orga nisationen vor die Herausforderung bei unver ndertem oder gar kleinerem Budget immer neue Anforderungen erf llen zu m ssen Als IT Verantwort licher k nnen Sie diese Herausforderung meistern wenn Sie auf ein struk turiertes IT Service Management setzen und damit die vorhandenen F hig keiten und Ressourcen zielgerichtet steuern und entwickeln Dieses Buch begleitet Sie auf diesem Weg Es zeigt wie Sie
300. nten Data Marts auf Das Enterprise Modell h lt Prozessinformationen mit der normalisierten und hinsichtlich der Zeitbez ge l Staging Area Dieser Begriff entstammt dem Umfeld von Business Intelligence Data Warehouse und bezeichnet einen Sammelplatz der extrahierten Daten in der feinsten Granularit t Die Daten werden meist gereinigt d h hinsichtlich der Datenqualit t untersucht und Korrekturen vorgenommen Von dieser Stelle aus erfolgt die Aggregation der Daten in die spezifischen Datenstrukturen f r meist mul tidimensionale Analysen 9 6 Prozesskennzahlen optimierten Datenablage fest Dieses Modell eignet sich ftir die klassischen Ad hoc Ana lysen oder einen eher explorativen Ansatz zur Datenanalyse Data Mining Bei Bedarf kann man Daten in einen themenspezifischen Data Mart meist mit einem ge eigneten multidimensionalen Datenmodell MOLAP Modell implementiert berf hren Dies ist immer dann sinnvoll wenn bestimmte Fragestellungen und fachliche Anforderun gen durch spezifische Systeme gut gel st werden k nnen aber das eher schwergewichti ge Datenmodell im Enterprise Modell diese Fragestellungen nicht oder nur unzureichend unterst tzt Das Prozess Cockpit ist meist Teil einer Unternehmensportall sung Die Darstellungs komponente f r das Prozess Cockpit berechnet aus dem Datenpool die relevante Kennzahl zur Prozessdurchlaufzeit der Wareneingangskontrolle Diese aggregierte Kennzahl wird sodann im
301. ntrale Objekt als den Ausgangspunkt Ihres gesamten Orga nigramms z B Ihr Unternehmen Auf der y Achse wird die vertikale Dekomposition der Organisationsstruktur ausgehend von dem zentralen Objekt abgebildet Sie orientiert sich an der bereits vorgestellten Auf teilung der ersten drei Instanzgranular t ten der Prozesssicht Dies bedeutet Zu jedem identifizierten Kernprozess bestimmen Sie eine Organisationseinheit Sie erhalten dadurch immer genauso viele Organisationseinheiten auf der 1 Instanzgranularitat wie Kernpro zesse identifiziert wurden Analog verfahren Sie mit den Hauptprozessen der 2 Instanz granularitat Die Ebene der 3 Instanzgranularitat wird bei der disziplinarischen Organisationsmodellie rung optional betrachtet Dies bedeutet dass eine Detaillierung der Organisationsstruktur in dieser Ebene nicht zwingend erforderlich ist Stellen Sie sich die Frage ob die weitere Unterteilung der Organisationsstruktur auf der Ebene der Unterprozesse fur Ihr Modellie rungsziel sinnvoll und notwendig ist 99 5 Das Grundmodell 100 Organisationseinheiten Stellen Personen horizontale horizontale Dekomposition Detaillierung 1 leitende Stelle 1 15 Personen Unter nehmen Geschafts bereich Orga eht 5 1 Instanzgranularitat ee Unternehmensinstanz Orga eht O a individuell lt 2 Instanzgranularitat ae angepasste a Kernprozessinstanz Orga eht o 3 Instanzgranularita
302. nzen der Prozesslandkarte in einem ausgewogenen Verh ltnis zueinander stehen Die betrachteten Gesch ftsprozesse Ihrer Prozesslandkarte sollten E sich auf eine abgegrenzte fachliche Dom ne beziehen E in ihrer Gr e und Komplexit t ausgewogen zueinander sein E die Bereiche der prim ren und sekund ren Leistungserbringung des Unternehmens ab decken Es hat sich als hilfreich herausgestellt zum Vergleich der Granular t t der Prozesse und Aktivit ten einer Ebene aus der Menge der identifizierten Prozesse einen Referenzprozess zu bestimmen der als Bewertungsgrundlage f r alle anderen Prozesse der betrachteten Ebene herangezogen wird Wir empfehlen f r die zu modellierenden Prozessebene 1 bis 3 eine Auflistung analog der Tabelle 5 1 zu erstellen Beschreiben Sie darin klar jeden Prozess und wie Sie die zugeh rigen Prozessinstanzen definieren Wichtig ist dass Sie eindeutig festlegen wann eine Instanz beginnt und endet Sie erkennen dass es schwerer ist eindeutige Prozessinstanzen f r sekund re als f r pri mare Kernprozesse zu definieren Das liegt in der Natur der Sache da es sich bei sekunda ren Kernprozessen in der Regel um kreative oder nur eingeschr nkt formalisierte Prozesse handelt vom Finanz und Rechnungswesen einmal abgesehen Besonders deutlich wird dieser Effekt beim Kernprozess Unternehmensentwicklung und Controlling Au erdem k nnen zu einem Kernprozess auch mehrere unterschiedliche Prozessinstanzty
303. odellierten IT Systeme h u fig schon dem Servicegedanken Wenn z B die Schritte Versandinformationen ermitteln Versandinformationen an Spediteur bermitteln und Versandinformationen an Ausgangs 7 4 Serviceidentifikation logistik bermitteln mit dem System Versandplanung verbunden sind sollte auch ber einen Service Versandplanung nachgedacht werden Ein Vorteil dieser Methode ist dass sich eine Wiederverwendungsm glichkeit direkt erkennen l sst Der Service existiert be reits doch wurde er noch nicht als Service publiziert Ein Business Analyst k nnte den Eindruck gewinnen dass mit dieser Methode auch ein Bottom up Identifikationsvorgehen durchgef hrt werden kann Ein Bottom up Ansatz startet jedoch in einer noch tieferen Detailebene und kann nicht ausschlie lich ber die modellierten Systeme erfolgen Das Modell l sst sich jedoch als zus tzliche Informations quelle bei einem Bottom up Vorgehen verwenden Identifikation ber organisatorische Gruppen H ufig werden an Funktionen auch organisatorische Informationen modelliert z B die Stelle oder Rolle die diese Funktion durchf hrt hnlich den Gesch ftsobjekten kann man hier ber das Repository erkennen welche Funktionen ebenfalls ber diese Stelle oder Rolle realisiert werden Die gefundenen Funktionen lassen sich wieder auf ihre Service tauglichkeit hin betrachten Servicegranularit t Bei der Serviceidentifikation tr tt immer die Frage auf welche Granularit
304. odells Sie hilft Ihnen die erforderlichen Entit ten des Metamo dells zu ermitteln deren Granularitat zu bestimmen und diese in Beziehung zu setzen Gruppieren Sie zun chst die ermittelten Objekttypen nach den Sichten Zum Beispiel wer den Anwendungen und Applikationen der Sicht Anwendungs Architektur zugeordnet Tabelle 3 3 enth lt die Zuordnung f r unsere Beispielfragen Wenn S e die Tabelle genau betrachten wird Ihnen auffallen dass nur drei der bisher bekannten Sichten enthalten und zwei neue Sichten hinzugekommen sind Dies ist darauf zur ckzuf hren dass wir jetzt die Sicht Geschaftsarchitektur in einen dy namischen und einen statischen Teil aufspalten die Sicht Organisationsarchitektur die alle Inhalte rund um aufbauorganisatorische Beschreibungen enth lt und die Sicht Pro zessarchitektur in der die dynamischen Inhalte beschrieben werden Es stellt sich nat rlich die Frage warum wir diese Trennung nicht bereits am Anfang vor genommen haben Das liegt zum einen daran dass die Unterteilung der Sichten Geschafts Anwendungs Informations und Infrastrukturarchitektur sehr verbreitet ist unter ande rem in der Enterprise Architecture Modellierung Das m chten wir bei den initialen Ent wurfsschritten nicht ver ndern Wichtiger ist aber unserer Erfahrung nach dass die Trennung der Sichten Prozess und Organisationsarchitektur in einer fr hen Phase des Entwurfsprozesses bei dem
305. odells in Bereiche f r eee EA BPM und fachliches SOA Welche Inhalte im integrierten Modell den Bereichen EA BPM und fachliche SOA zuge ordnet werden wird im Folgenden definiert Au erdem legen wir fest welche Strukturen zu deren Beschreibung sinnvoll anzulegen sind und wie detailliert die Inhalte zu den Arte fakttypen erfolgt 2 3 Grundsatzliche Gliederung eines integrierten Modells 2 3 2 2 Detaillierung des EA Modellbereichs Geschaftsprozesse Innerhalb des EA Modellteils werden Prozesse meistens nur sehr grob beschrieben Eine EA nutzt Prozessmodelle zur Darstellung grundsatzlicher Zusammenhange meistens in einem unternehmensweiten oder sogar unternehmensubergreifenden Kontext Detailinfor mationen ber die genaue Ausf hrung einzelner Prozesse spielt im Rahmen der EA Mo dellierung in der Regel keine Rolle Organisationsstruktur Im Rahmen des EA Modellteils werden aufgrund der st rker berblicksartigen Modellie rung nur bergeordnete organisatorische Strukturen beschrieben Wie schon bei den Pro zessen erfolgt in der EA Modellierung die Erfassung von Detailinformationen zur organi satorischen Struktur in der Regel nicht Geschaftsobjekte Innerhalb des EA Modellteils ber cksichtigen wir aufgrund der st rker berblicksartigen Darstellung der EA nur allgemein beschreibende Gesch ftsobjekte Detailliertere Datenbe schreibungen sind im integrierten Modell im EA Modellbereich nicht vorgesehen Anwendungssyst
306. on Enterprise Architecture Business Process Management und SOA in den Jahren 2007 und 2008 st ndig zu Deshalb haben wir uns entschieden diese Aspekte bei der Verbindung der Modellierungswelten in den Mittel punkt zu stellen Genau an der Schnittstelle dieser Modellierungswelten arbeitet heute zu nehmend der Business Analyst Er muss die Verbindung zwischen ihnen herstellen und zwischen den jeweiligen Sichten vermitteln Vorwort Entstanden ist ein Buch welches sowohl ein werkzeugneutrales Vorgehen f r den Model lierungsteil der Arbeit des Business Analysten aufzeigt und gleichzeitig dem Praktiker konkrete Beispiel einer Modellierung innerhalb eines Werkzeuges n herbringt Wir m chten uns besonders f r die Unterst tzung der Oracle Corp Bedanken insbesonde re bei Meera Srinivasan und Wolfgang M cke die uns jederzeit mit Rat zur Seite gestan den haben Auch danken wir den Kollegen bei OPITZ CONSULTING die durch Anregungen und Verbesserungsvorschl ge ebenfalls ma geblich zum Gelingen dieses Buches beigetragen haben Besonders erw hnen m chten wir an dieser Stelle Danilo Schmiedel der uns mit seinen kritischen aber immer konstruktiven Anmerkungen unterst tzt hat Weiterhin gilt unser Dank dem Hanser Verlag f r die hervorragende Unterst tzung bei der Erstellung des Buches Besonders danken wir Margarete Metzger und Irene Weilhart f r die redaktionelle und technische Unterst tzung Wir w nschen Ihnen viel Spa und neue
307. on den passen und ggf gesucht F higkeiten abgedeckt Sollten mehr Schlagworte werden k nnten n tig sein k nnen neue Attribute auf dem Objekt Gesch ftsservice angelegt werden Dokumentation Hinweis Link zu einer Service Attribut Quelle auf dem Objekt Geschaftsservice dokumentation Projekt Hinweis auf das Projekt Es muss ein benutzerdefiniertes Attribut auf dem das den Service entwickelt Objekt Gesch ftsservice angelegt werden Nutzungs Wo darf der Service genutzt Es muss ein benutzerdefiniertes Attribut auf dem freigabe werden Objekt Gesch ftsservice angelegt werden Intern extern Attribute Extern und Intern auf dem Objekt Softwareservicetyp 7 5 Serviceklassifikation und Servicespezifikation Kaufmannische Informationen Information Beschreibung BPA Suite Nutzungsgeb hr Informationen zur internen oder Es muss ein benutzerdefiniertes Attribut externen Kostenrechnung auf dem Objekt Gesch ftsservice ange legt werden Nutzungs Einschr nkung wie h ufig der Es muss ein benutzerdefiniertes Attribut h ufigkeit Service genutzt werden darf auf dem Objekt Gesch ftsservice ange legt werden Attribut Ausf hrungsh ufigkeit auf dem Objekt Softwareservicetyp Entwicklungs Sch tzung Dokumentation der Attribut Entwicklungsaufwand und kosten Entwicklungskosten Entwicklungskosten auf dem Objekt Softwareservicetyp Business Case Meist werden Services in Verbin Der Business Case kann in einem dung mit ei
308. orming zur Identifizierung der individuellen Fragestellungen an den f r Ihre Orga nisation wichtigen Modellgrunds tzen aus Bringen Sie alle Personen die zuk nftig n irgendeiner Form mit dem Modell oder den Daten aus dem Modell arbeiten zusammen Bitten Sie alle Beteiligten hre Fragen an das zuk nftige Modell im Rahmen der ermittelten Schwerpunkte zu erfassen Dazu bieten sich verschiedene Kreativtechniken an z B 6 3 5 Methode freies Brainstorming etc Welche Technik Sie in Ihrem Unternehmen anwenden sollten Sie individuell abw gen Es kommt in dieser Phase zun chst darauf an m glichst viele Fragen zu identifizieren Eine Bewer tung der einzelnen Fragen erfolgt in diesem Schritt noch nicht Wir f hren die Ermittlung essenzieller Fragestellungen gerne in einem offenen Brainstor ming durch und dokumentieren die Ergebnisse direkt auf einem Flip Chart Diese Art der Erfassung hat den Vorteil dass die Teilnehmer st ndig in den Prozess der Fragensamm lung eingebunden und die Ergebnisse allen Teilnehmern jederzeit transparent sind Sinn voll ist ein offenes Brainstorming bis zu einer Gruppengr e von max 10 Personen Gr Bere Gruppen sollten Sie entweder aufteilen oder auf Kreativit tstechniken ausweichen die gr ere Gruppen effizient moderieren Abbildung 3 2 zeigt das Teilergebnis eines solchen Brainstormings dokumentiert mit Hilfe eines Flip Charts Abbildung 3 2 Flip Chart Beispiel der Ermittlung essenzieller Fr
309. pen vorhanden sein W hlen S e n einem solchen Fall immer den Prozessinstanztyp mit der gr ten H ufigkeit Bewerten S e anschlie end die ermittelten Kernprozesse hinsichtlich hrer Instanzgranula ritat Stellen Sie dabei die folgenden Fragen E Haben alle ermittelten Prozesse einen ann hernd gleichen Umfang E Sind alle relevanten Bereiche der Leistungserbringung in Ihrem Unternehmen ber ck sichtigt Liegt eine durchg ngige und l ckenlose Dokumentation der Leistungserbringung in Ihrem Unternehmen vor E Bestehen zwischen den beschriebenen Bereichen der Leistungserbringung keine ber deckungen E Haben Sie alle sekund ren Kernprozesse die zur Leistungserbringung in Ihrem Unter nehmen erforderlich sind beschrieben Wenn Sie alle Fragen f r die ermittelte Prozesslandkarte mit ja beantworten k nnen Sie davon ausgehen einen tragfahigen Entwurf erstellt zu haben 5 2 Aufbau des Grundmodells Tabelle 5 1 Tabelle zur Ermittlung und Strukturierung von Prozessinstanzen Beispiel 1 Instanzgranularit t Prozess Aktivit t Prozessinstanz Beschreibung der Beginn Prozessinstanz ein Beschaffungs vorgang Beschaffung ein Vertriebs vorgang Vertrieb eine Service anfrage Service Produkt entwicklung eine Produkt entwicklung Auftrags abwicklung ein Auftrags abwicklungs vorgang Marketing ein Marketing projekt Finanz und Rechnungswesen eine Rechnungs erstellung Person
310. plementierung der SOA erforderlichen Artefakte Besonders wichtig st die Beschrei bung aller beteiligten Rollen innerhalb des zu automatisierenden Prozesses Gesch ftsobjekte Weiterhin erfolgt im SOA Modellteil eine Verfeinerung der fachlichen Datenobjekte zu technischen Datenobjekten Sie werden um technische Inhalte angereichert die f r die Bearbeitung in IT Systemen erforderlich sind Anwendungssysteme Innerhalb des fachlichen SOA Modellteils werden nur solche Services modelliert die der direkten Unterst tzung fachlicher Funktionen dienen 2 3 Grundsatzliche Gliederung eines integrierten Modells Infrastrukturen Auch der fachliche SOA Modellteil enth lt keine Inhalte zu Infrastrukturen 2 3 2 5 Schnittmenge des integrierten Modells Im vorhergehenden Abschnitt haben wir gesehen welche Artefakttypen in einer integrier ten EA BPM und SOA Modellierung vorkommen Dabei konnten Sie erkennen dass einige davon in unterschiedlicher Detaillierung in mehreren Modellbereichen beschrieben werden Zum Beispiel finden S e Gesch ftsprozesse im EA dem BPM und im fachlichen SOA Modellteil Um zu verhindern dass Redundanzen im Gesamtmodell entstehen m ssen Sie f r Ihr Modell festlegen welche Inhalte wo beschrieben werden Es muss vermieden werden dass Modellinhalte mit gleicher Bedeutung n mehr als einem Modellbereich des integrierten Modells abgelegt werden Tabelle 2 2 zeigt eine Empfehlung zur grunds tzlichen Einteilung
311. plung von Informationen eine hohe Be deutung zu Die implementierten Komponenten und Prozesse der Anwendungsebene lie fern Messwerte die die Bas s f r die Ermittlung fachlicher Kennzahlen darstellen und auf der obersten Ebene der fachlichen Prozessgestaltung wertvollen Input f r das Prozesscont rolling und die Prozessoptimierung bieten 8 2 3 1 Gr nde f r Serviceorientierung in der Prozessautomatisierung Wenngleich sich Prozesse auch ohne Serviceorientierung auf IT Systeme bertragen las sen weisen die modularen dienstebasierten Artefakte einer SOA hohes Potenzial auf die fachlichen Anforderungen besser zu strukturieren Dar ber hinaus wird auch die sp tere Umsetzung der Servicelandschaft n der IT konsequent vorbereitet Architekturparadigmen wie lose Kopplung und Virtualisierung aber auch die vielbeschworene und sicherlich teil weise berbewertete Wiederverwendung werden konsequent von fachlicher Seite vorberei tet und unterst tzt Der in diesem Kapitel aufgezeigte Ansatz verfolgt speziell das Ziel prozessbasierte SOA L sungen zu schaffen Andere Teilgebiete des umfassenden Themas SOA wie beispielsweise servicebasierte Enterprise Application Integration Ansatze En terprise Service Bus Konzepte oder die Spezifikation und Entwicklung elementarer Basis services z B in Java NET usw werden nicht behandelt 8 2 3 2 Anspruch und Wirklichkeit Werkzeugunterst tzung Den Reiz der Idee einer prozessmodellbasierten Soft
312. pts mit der Oracle BPA Suite Geschaftsobjekte IT Gesch ftsobjekte Material lieferung amp Artikelliefermen JE bestellung amp Artikelnummer D a T He M I m Art I D N a D Lieferschein a M e 5 T 5 TE 2 i T M 1 o D N O 5 E oo Menge i arenbegleit papiere amp Anmerkung E D D z Mh areneingangs protokoll amp Abbildung 6 15 Zusammenhang zwischen fachlichen und IT Gesch ftsobjekten 147 6 Modellgestutzte fachliche Konzeption individueller IT Systeme 6 5 3 2 Maskenbeschreibung Nachdem die von unserem System be und verarbeiteten sowie neu erstellten Daten nun beschrieben sind konzipieren wir die Bildschirmdialoge die das System zur Interaktion mit dem Benutzer verwendet Bei der Spezifikation eines Maskenentwurfs sollten Sie sich immer im Klaren dar ber sein dass die einzelnen Masken der f r die sp teren Systembe nutzer sichtbare Teil des Systems sind Daher sollten Anforderungen der spateren Benutzer sofern sie bestehen auch in die Konzeption mit einbezogen werden um die sp tere Akzeptanz des Systems zu erh hen Wie bereits in Abschnitt 6 3 4 1 erl utert kann der Detaillierungsgrad einer Maskenbeschreibung zwischen einer rein textlichen Beschreibung der dargestellten Informationen und m glichen Benutzeraktionen ber ein Maskendia gramm das die Struktur einer Maske dars
313. r und Unterordnung sowie E synonyme Begriffe unterscheiden Diskutieren Sie in diesen F llen die unterschiedlichen Standpunkte und definieren Sie w hrend der Anordnung die Bedeutung jedes Objektes verbindlich Damit ergibt sich f r unser Beispiel die in Abbildung 3 5 dargestellte Domain Level Matrix Wir sehen den Objekttyp Unternehmen als dem Objekttyp Standort berge ordnet an und die Objekttypen Applikation und Anwendung als synonym Prozess Organisations Anwendungs Daten Infrastruktur Architektur Architektur Architektur Architektur Architektur Prozesse y Unternehmen T T a Abteilung l aa Daten Server Person Abbildung 3 5 Domain Level Matrix mit zugeordneten Objekttypen Beispiel Aktivit ten Standort Veit Vie na Nachdem S e die Objekte zu jeder Architektursicht zugeordnet und nach Granularit t sor tiert haben tragen Sie die Beziehungen zwischen den Objekten n die Domain Level Matrix ein Diese haben Sie bereits mit den essenziellen Fragestellungen ermittelt Betrachten wir beispielhaft die Frage Welche Aktivit ten sind betroffen wenn eine An wendung nicht mehr zur Verf gung steht Sie erkennen dass eine Beziehung zwischen dem Objekt Aktivit t und Anwendung erforderlich ist um aus dem Modell heraus die Frage zu beantworten Definieren S e deshalb eine Beziehung zwischen den Objekten der jewei ligen Sicht die eine ausreichende Granularitat zur Beantwortung der
314. r 54 mr A Losenen J s Sa Osten berpr fgng gt Gruppieen x a aan m B J 4 iE fi I m EE p konpai Deuppitung auleeben Suk arin W i alle 4 fen fittir T Egal in DOuplikal Ti p E tent Cherllen Wprbindumarn aan af kranker Saalten erlie 22 Marw nwenm nahee af j airginn t l t iger F a Diede urg ie Objekte Di y 1 Objekttyp Ej Objekttyp attri 5375 Hardwarekomponente 5377 Hardwarekomponente 5378 Hardwarekomponente 5423 Hardwarekomponente 12841 burtyp a Abbildung 4 13 Identifizierung passender Objekt Attributtypen mit der Excel Analysedatei Wiederholen Sie diesen Vorgang so lange bis alle m glichen Entitat Beziehung Entitat Gruppen des Metamodells bearbeitet wurden Festlegung erforderlicher Diagrammattribute Im letzten Schritt legen Sie zu jedem gew hlten Diagrammtyp die ben tigten Attribute fest Dazu w hlen Sie den Reiter Modellattributtypen der Excel Analysedate und selektie ren mit der Filterfunktion die ausgew hlten Diagrammtypen S e erhalten alle verf gbaren Attribute zu den ausgew hlten Diagrammtypen angezeigt vgl Abbildung 4 14 Cc 9 a gt ss eg Sa Ausgewahlter ne Diagrammtyp E c D 1 ia 15062 Zugnffsciagramm 15063 Zugriffisciagramm Ideniifizierer 15064 Zugriffsciegramm Beschreibung Definitio 15065 Zugrifisciegramm Synonyme 15066 Zugnfisdiagramm Langbezeichnung 15067 Zugrfisdiagramm BemerkunglBeisoie 15
315. r Modell annehmen wird Er mitteln Sie dazu f r jede Entit t und jede Beziehung zwischen den Entit ten die Anzahl der zu modellierenden Instanzen Daf r sch tzen Sie beispielsweise f r die Entitat Soft 53 3 Aufbau des Metamodells 54 wareressource ab wie viele Instanzen Sie in Ihrer Organisation erfassen m ssen und wie viele Beziehungen diese zu Instanzen der Entit t Hardwareressourcen besitzen Anschlie end legen Sie fest welcher durchschnittliche Aufwand zur Ermittlung der Inhal te je Entit t bzw Beziehung erforderlich ist In der Regel ist bei den meisten Instanzen einer Entit t mit einem ann hernd gleichen Ermittlungs und Pflegeaufwand zu rechnen weshalb von einer kleinen Varianz bei den Zeiten zur Informationsbeschaffung ausgegan gen werden kann Geben Sie den Aufwand zur Ermittlung der Inhalte zu einer Instanz in Stunden an Dabei ist es wichtig zu beachten dass die angegebenen Stunden den Aufwand zur Ermittlung und Abstimmung der Inhalte in Ihrer Organisation einschlie en Dies um fasst unter anderem erforderliche Recherchen und Abstimmungsarbeiten zur Verifizierung und Validierung der Inhalte die sich im Rahmen des Aufbaus eines Modells als sehr um fangreiche T tigkeiten herausgestellt haben Die Praxis zeigt dass die Abbildung im Werk zeug gegen ber der Suche nach den richtigen Informationen im Unternehmen verschwin dend gering ist und deshalb nicht zwingend ber cksichtigt werden muss Lassen Sie die Sch
316. r Tasks aus seiner Worklist die ber die Serviceschnittstelle eingestellt wurden 183 7 Identifizierung und Modellierung fachlicher Services fur SOA 184 Automatisierter Service Der Service wird vollstandig in der IT realisiert Funktional orientierte Klassifikation Funktional kann man verschiedene Klassen unterscheiden Im Prozessmodell k nnen fach lich folgende Klassen interessant sein Daten Service Services die Daten zur Verf gung stellen Es ist keine besondere Gesch ftslogik hinter dem Service verborgen E Gesch ftslogik Service Der Service lagert eine Gesch ftslogik aus Der Service verf gt ber keine eigene Da tenbas s und kennt nur seine Eingabeinformationen E Prozesskontroll Service Z B ein Genehmigungsprozess E Informationssystem Service Meistens eine Mischung aus Daten Service Gesch ftslogik Service und Prozesskon trollfunktionalit ten z B eine gekapselte Funktionalit t eines ERP Systems Rein technische Services k nnen ebenfalls klassifiziert werden Aus Sicht des Business Analysten erscheinen diese Services vielleicht im ersten Augenblick berfl ssig Im Sinne einer Enterprise Architecture sind technische Services aber sehr interessant So kann er kannt werden welche Prozesse betroffen sind wenn dieser technische Service ausf llt Technische Klassifikationen k nnen sein E Infrastruktur Service Services die durch Netzwerk und EDV Infrastruktur bereitgestellt werden z B ei
317. r prozessgetriebene SOA Ansatz 198 Technischer Service Eine als IT Komponente realisierte Funktionalit t die als Service z B Web Servi ce bereitgestellt wird Leistet elementare Dienste die f r sich alleine keinen fachlichen Service im Sinne der von einer Dom ne nach au en zur Verf gung gestellten Dienste darstellt ent h lt keine betriebswirtschaftliche Logik Kann mehrere Operationen haben Bildet beim ausf hrbaren IT Modell im Zusammenspiel mit anderen technischen Services die Leistung des fachlichen Dienstes ab Wird in einer f r die gew hlte Programmiersprache geeigneten Notation spezifiziert z B UML f r objektorientierte Entwicklung Konkret ein in Java NET o a implementierter Web Service 8 3 2 Zielsetzung kl ren und festlegen Bei einer fachlichen Prozessmodellierung hat die mit dem Modellierungsprojekt und den dabei erstellten Modellen verfolgte Zielsetzung Einfluss auf verschiedene Parameter der Projekte Dies betrifft beispielsweise die Gestaltung der Modellierung den Grad der De taillierung oder eingesetzte Methoden und Modelle So wird die Modellierung f r eine fachlich organisatorische Prozessdokumentation anders ausgestaltet sein als eine Modellie rung mit der Zielsetzung der Prozessoptimierung oder eben der Prozessautomatisierung Wichtig f r die Wirtschaftlichkeit und bersichtlichkeit eines Projektes ist letztlich ein pragmatisches Vorgehen das die relevanten Infor
318. r realen Welt im Modell zu beschreiben Der vorgegebene Methodeninhalt der Oracle BPA Suite ist sehr umfangreich weshalb genau festgelegt werden muss wie Sie Ihr individuelles integriertes EA BPM und SOA Modell erstellen wollen Ihnen stehen die folgenden Beschreibungsartefakte zur Verf gung E Modelltypen Zur Abbildung unseres Beispiels nutzen wir die Oracle BPA Suite Diese ist bis auf wenige methodische Unterschiede identisch mit dem IDS Scheer ARIS Business Architect der im Rahmen einer OEM Vereinbarung als Grundlage f r das Oracle Produkt dient Beide Werkzeuge verf gen ber ein geschlos senes Metamodell Oracle hat bei der Anpassung der BPA Suite methodische Ver nderungen im Ver gleich zum Standard ARIS Business Architect vorgenommen Auf Seiten der implementierten ARIS Methodik wurden von Oracle die im IDS Scheer Produkt vorhandenen SAP Inhalte weitgehend entfernt und durch spezifische Oracle Methodeninhalte erg nzt 2 Der Begriff Modelltyp ist von der IDS Scheer AG falsch gew hlt hat sich aber im Verlauf der Zeit etabliert Korrekt w re die Bezeichnung Diagrammtyp Bei einem Diagramm handelt es sich um die graphische Darstellung eines Sachverhaltes oder einer Information Je nach Zielsetzung nutzt ein Dia gramm unterschiedliche graphische Darstellungen Ein Modell ist hingegen eine abstrakte Repr sentati on von Struktur Funktion oder Verhalten eines Systems Im vorliegenden Fall der Modellierung mit der Oracle BPA Suite i
319. r sehen wir uns im Folgenden n her an und legen dabei den Schwerpunkt auf das Process Ware house 9 5 1 IT Systeme zur Extraktion und Transformation Be der Extraktion der Zustandsdaten der Prozesse benutzt man so genannte Sonden Diese Sonden sind spezifische IT Komponenten die zu wohldefinierten Zeitpunkten Daten ber den Zustand eines Prozesses extrahieren und an nachfolgende Systeme weiterleiten Die Sonden werden in den IT Systemen Datenquellen implementiert welche die Zu standsdaten zu den Prozessen liefern m ssen Die Extraktion der Daten kann entweder durch ein PULL oder ein PUSH Verfahren erfolgen 9 5 Architektur Enterprise Service Bus ESB ME as l Elias Transformation Transformation Laden der Daten Process Monitoring Anwendungs Transformation auf BAM Model Business Rule Engine Komponente Datenbank Process ee Mining POM XML ProcessObjectModel Process Cockpit ee SAP Log File Analyser Abbildung 9 5 Architekturmodell des Process Warehouse 1 Extraktion Transformation E Beim PUSH Verfahren werden Informationen aus einzelnen Transaktionen von den operativen Systemen an das Process Warehouse gemeldet Dies ist sinnvoll wenn ein Echtzeit orientiertes Monitoring erw nscht ist Das Datenvolumen pro Transformation ist erheblich geringer als beim Pull Verfahren weil nur die Daten der Transaktion ber tragen werden die Frequenz ist aber deutlich h her E
320. rch das Use Case Objekt Auf Teillieferung pr fen dargestellt das direkt an die fachliche Funktion Teillieferung pr fen modelliert wird die IT tech nisch unterst tzt werden soll Dieses Use Case Objekt stellt eine Systemfunktionalit t also eine funktionale Systemanforderung an das neue System dar und bildet die Schnitt stelle zur IT Sicht indem es nun mit einem IT Prozess hinterlegt wird der den Systemab lauf abbildet 6 5 2 Systemablauf Der Systemablauf stellt das dynamische Systemverhalten der Funktionalit t Auf Teilliefe rung pr fen in Form einer EPK dar siehe Abbildung 6 14 Der Systemablauf besteht aus verschiedenen Verarbeitungsschritten die jeweils entweder durch einen Benutzer oder automatisch vom System durchgef hrt werden Ferner wird jeder Verarbeitungsschritt auf einer bestimmten Maske abgebildet ben tigt Ein und oder erzeugt Ausgabedaten 6 5 Erstellung eines Fachkonzepts mit der Oracle BPA Suite Mitarbeiter Material bestellung amp Mitarbeiter Varenannahme Teil lieferung Teillieferung Artikel als Mitarbeiter Mitarbeiter arenannahme arenannahme rtikelmenge Teillieferung als falsch markieren markieren areneingangs protokoll Abbildung 6 14 Systemablauf Teillieferung pr fen 143 6 Modellgest tzte fachliche Konzeption individueller IT Systeme Die Verarbeitungsschritte vom Objekttyp Funktion
321. rchf hrung der Aktivit ten ben tigt Input E Welche fachlichen Informationen werden bei der Durchf hrung der Aktivit ten bear beitet und neu erzeugt Output E Welche Aktivit ten werden mit IT Unterst tzung durchgef hrt S e werden nun zu Recht anmerken dass insbesondere der letzte Punkt nicht ganz dem in den vorangegangenen Kapiteln beschriebenen Vorgehen entspricht in dem die Fachsicht unabh ngig von IT Unterstiitzung modelliert werden sollte Dies ist nat rlich weiterhin g ltig Dennoch ist es im Rahmen einer Fachkonzeption wichtig zu wissen welche Pro zessschritte bereits m Ist Zustand durch IT unterst tzt werden um notwendige System schnittstellen f r die neue L sung rechtzeitig zu erkennen Nehmen Sie die Ist Prozesse gemeinsam mit der Fachabteilung auf Sie beschreiben die aktuellen Abl ufe wie sie in der Fachabteilung t gl ch gelebt werden Sie k nnen diese in Interviews und Workshops ber Frageb gen oder unter Zuhilfenahme bereits existierender Dokumentationen aufnehmen Interviews und Frageb gen Interviews haben den Charakter eines Frage und Antwortspiels n dessen Rahmen Sie durch Ihre Fragen den Ablauf entscheidend vorgeben Interviews sollten im Idealfall mit nur einer Person auf einmal durchgef hrt werden da der Frage und Antwort Charakter keine langen Diskussionen vorsieht Die Qualit t der Fragen ist dabei ausschlaggebend f r die Qualit t des Ergebnisses Der Interviewer l sst sich von
322. rd sp testens nach der Realisierung Teil des Unternehmensmodells so dass in diesem Fall sowohl die Notwendigkeit zur Schnittstellenmodellierung vorliegt als auch eine entsprechende Me thodik und Notation definiert ist Dies sollten Sie im Rahmen einer Fachkonzepterstellung ausnutzen Je nachdem wie detailliert die ben tigten Schnittstellen beschrieben werden sollen kann eine Modellierung auch in F llen sinnvoll sein in denen kein gr erer Model lierungsrahmen im Sinne einer EA vorliegt Abbildung 6 9 zeigt ein Beispiel f r die Mo dellierung von Systemschnittstellen Neben der reinen Aufz hlung und einfachen Darstel lung von Schnittstellen kann diese Darstellung weiter detailliert werden um nicht nur das Vorhandensein einer Schnittstelle zu zeigen sondern auch die konkreten Daten die ber die Externes lt O Externes System 1 System 2 Schnittstelle Schnittstelle Anwendungs system Externes x System 3 Schnittstelle Abbildung 6 9 Systemschnittstellen ein Beispiel 6 3 Die IT Sicht und ihr Zusammenhang mit der Fachsicht se Schnittstelle flie en Auf dieser Ebene kann also eine Verbindung zur Beschreibung der Daten hergestellt werden die bereits zur Darstellung des Systemablaufs verwendet worden sind Unabh ngig davon wie die Beschreibung von Schnittstellen f r ein Fachkonzept letztlich geartet st sollten fo
323. rden bei einer Suche nach Bestellung die Funktionen Bestel lung reservieren Bestellung verschicken und Bestellung stornieren gefunden Ein erster Servicekandidat ist hier ein Bestellservice der die gefundenen Prozessschritte als Leistun gen kapselt und anbietet Identifikation ber ein Repository Viele Prozessmodelle verwenden ein Repository in dem alle Elemente eines Modells hin terlegt sind Ziel ist es alle Elemente nur einmalig zu erstellen um sie dann mehrfach in Diagrammen verwenden zu k nnen Schaut man sich eine Funktion in einem Diagramm an dann kann exakt die gleiche Funktion auch in anderen Diagrammen vorkommen Wird eine Funktion in mehreren Diagrammen verwendet ist dies f r uns ein Hinweis auf einen Servicekandidaten Identifikation ber Gesch ftsobjekte Funktionen besitzen Eingabe und Ausgabeobjekte ber den Repository Ansatz k nnen auch die Funktionen gefunden werden die auf anderen Diagrammen mit dem Objekt ver bunden sind Auf diesem Wege erh lt man eine bersichtliche Anzahl an Funktionen die man ebenfalls auf hre Servicetauglichkeit hin betrachten kann Diese Methode eignet sich besonders um prozess bergreifende Services zu identifizieren Identifikation ber Systeme In Prozessmodellen werden ebenfalls IT Systeme modelliert Die Aussage einer Verbin dung zwischen Funktion und IT System besteht meist darin dass die Funktion durch das IT System unterst tzt oder realisiert wird Dabei folgen die m
324. rechnung von KPIs modelliert werden vgl Kapitel 9 8 3 4 2 Informationsbedarf des SOA Entwicklers Im n chsten Schritt gilt es die fachlichen Services die im fachlichen Detailmodell einzel ne Prozessschritte unterst tzen modellbasiert mit weiteren technischen Details zu spezifi z eren vgl Abbildung 8 4 Diese technischen Prozessmodelle sind die Basis auf der der SOA Entwickler die IT seitige Implementierung der fachlichen Services vornimmt Die hier erstellten Modelle werden den Ebenen 6 und optional 6 Fachliche IT Modelle vgl Abbildung 8 3 zugeordnet Grunds tzlich ist die Gestaltung dieser Modelle Aufgabe des SOA Business Analysten weil die Prozesse fachliche Abl ufe darstellen und eine fachliche Leistung zur Unterst tzung der Prozesse erbringen F r die Definition der fachlichen IT Modelle ist Grundlagenwissen ber techni sche Aspekte einer SOA wie beispielsweise Kenntnisse ber Web Services BPEL ESB von Vorteil da die im Modell zu erfassenden Informationen die Arbeit des SOA Entwicklers m glichst weitreichend vorbereiten sollen Wegen der Verkn pfung fachlicher und technischer Kenntnisse f llt die Gestal tung dieser Modelle f r den Service ggf einer neu zu definierenden Rolle zu situiert zwischen der des klassischen Business Analysten und der des Entwick lers Abbildung 8 6 zeigt die in fachlichen IT Modellen zu erfassenden Informationen Grund s tzlich muss ein solches IT Modell vollst nd
325. reich sein wenn es darum geht im n chsten Schritt einen sinnvollen Soll Prozess zu definieren in dem die Information dann beispielsweise n digitaler Form direkt aus dem System geholt wird in dem sie urspr nglich erzeugt oder erfasst wird Dem Fachbereich bereits bekannte Schwachstellen k nnen auch sofort bei der Ist Aufnahme f r einzelne Aktivit ten oder ganze Prozesse erfasst werden Wenn Sie als Business Analyst den Auftrag erhalten haben ein Fachkonzept f r ein IT System zu erstellen ist ein Teil dieser Ist Analyse nat rlich bereits abgeschlossen und hat zu dem Ergebnis gef hrt dass ein bestimmter Prozess berhaupt erst durch Einf hrung einer neuen technischen L sung verbessert werden soll Die Prozessanalyse und optimie rung ist fester Bestandteil eines funktionierenden BPM 6 3 2 Entwicklung und Modellierung der Soll Prozesse An die Analyse der Ist Prozesse schlie t sich die Erarbeitung der Soll Prozesse an Ziel dieser Phase ist die Erarbeitung der optimalen Arbeitsabl ufe mit speziellem Fokus in Be zug auf die zur Erreichung dieses optimalen Zustands ben tigte IT Unterst tzung Zur Er arbeitung der optimalen Soll Situation sollte auf den 1m Rahmen der Ist Analyse identifi 125 6 Modellgest tzte fachliche Konzeption individueller IT Systeme 126 zierten Schwachstellen aufgesetzt und erarbeitet werden wie diese Schwachstellen zu be seitigen sind Dabe ist es wichtig einen optimalen Wunschzustand zu beschr
326. relevanten statischen Fachprozess Komponenten l 2 3 4 Modellierung des gew nschten Systemverhaltens Systemablauf 5 Modellierung der statischen Systemkomponenten 6 Automatisierte berf hrung der Modellinhalte in das Fachkonzept 7 Bearbeitung nicht modellierter Fachkonzeptteile Nat rlich unterliegt sowohl die Modellierung wie in Kapitel 2 erl utert als auch die Be arbeitung eines Fachkonzepts fortlaufender Uberarbeitung so dass Sie die einzelnen Schritte in der Praxis nicht vollst ndig voneinander getrennt und streng in der oben be schriebenen Reihenfolge bearbeiten werden Dennoch unterliegt zumindest die Untertei lung in die folgenden Arbeitspakete einer entscheidenden Logik Bearbeitung der Fachsicht E Verkn pfung mit und Bearbeitung der IT Sicht E berf hrung ins und Bearbeitung des Fachkonzepts Grundlage eines Fachkonzepts ist die Fachsicht da sich aus ihr die Anforderun gen ergeben die in der IT Sicht abgebildet werden m ssen 121 6 Modellgestutzte fachliche Konzeption individueller IT Systeme FACHSICHT 2 Systemablauf Fachprozess Soll Fachprozess Ist 6 Statische Systemkomponenten Maske1 Zur ck OK Abbrechen L L Maske 2 Maske 3
327. rem Beispiel ergibt die Sch tzung zum Aufbau und zur inhaltlichen F llung des vorliegenden Metamodells einen gesch tzten Umfang von ca 40 Personentagen 312 8 h 8h pro Tag 39 1 Tage Verwenden S e diese Berechnung nur als N herung Sie kann eine detaillierte Aufwands sch tzung zum Beispiel f r vertragliche Zwecke nicht ersetzen bietet aber eine gute Ba sis zur Absch tzung was bei Ihrem Modellierungsprojekt auf Sie zukommt S e k nnen mit diesem Vorgehen sehr schnell und einfach den voraussichtlichen Aufwand zur initialen Erstellung eines Modells ermitteln Beachten Sie dass Sie mit der Ermittlung der oben genannten Inhalte die Struk tur f r Ihr gesamtes Modell festlegen Dies bedeutet Sie betrachten bei dem Metamodellentwurf bereits alle relevanten Ebenen der Modellierung Prozess Organisations Daten Anwendungs und Infrastruktur Architektur Damit legen Sie das Fundament f r die weitere Konkretisierung des Modells in den Bereichen EA BPM und fachliche SOA Insbesondere die zeitlich umfangreiche Modellierung von Inhalten zu Prozessen und Gesch ftsobjekten liefert f r die Modellierung der Gesch ftsprozesse und der fachlichen SOA Teilmodelle wesentliche Ausgangsdaten 4 1 4 2 4 Die Umsetzung des Metamodells Fragen die dieses Kapitel beantwortet E Wie bilden Sie ein werkzeugneutrales Metamodell in der Oracle BPA Suite ab E Welche methodischen Einschr nkungen liegen bei der Oracle BPA Sui
328. rer Bedeu tung da sie wesentlich h here Anforderung stellt als die vertikale Gliederung berpr fen Sie dies einmal selbst Es f llt Ihnen sicher deutlich leichter die genannten horizontalen Prozesse zu detaillieren als klare Regeln f r deren Abgrenzung untereinander aufzustellen Kreditoren Materialeinkauf buchhaltung Wareneingang horizontale Segmentierung Abbildung 2 6 Beispiel einer horizontalen Segmentierung Die vertikale Detaillierung beschreibt die Vertiefung eines einzelnen Inhaltsbereiches wogegen s ch die horizontale Segmentierung mit der inhaltlichen Abgrenzung verschiede ner Bereiche zueinander befasst Um in einem Modellierungsprojekt sicherzustellen dass das Gesamtmodell konsistent aufgebaut und die horizontale Unterteilung und vertikale Detaillierung einheitlich sind m ssen vor Beginn der Modellierung eindeutige Kriterien zur Unterscheidung definiert werden Bei der Strukturierung ist es wichtig dass die Unterteilungskriterien einerseits eine eindeu tige und klare Abgrenzung erlauben andererseits aber m glichst einfach sind um den Aufwand zur Abgrenzung in vertretbaren Grenzen zu halten Ausgangspunkt f r die Unter teilung sollte immer die horizontale Segmentierung vor der vertikalen Detaillierung sein Leider wird in vielen Projekten zu schnell mit einer vertikalen Detaillierung begonnen was im weiteren Projektverlauf in der Regel zu erheblichen Anpassungs und Nacharbeiten f hrt 2
329. rer Uber Reports oder andere Automatismen auszuwerten da die Informationen teilweise unstrukturiert z B in Freitext vorliegen Ziel der Servicespezifikation ist es die Services im Serviceportfolio nutzbar zu machen Servicekonsumenten sollen alle notigen Informationen vorfinden um den Service nutzen zu k nnen Alle Beteiligen siehe auch Abbildung 7 6 nutzen und pflegen die Informatio nen der Servicespezifikation Welche Informationen spezifiziert werden ist f r jedes Unternehmen individuell zu ent scheiden Beispiele k nnen sein Allgemeine Informationen zum Service Information Beschreibung BPA Suite Atribut Name auf dem Objekt Gesch flsservice Servicetyp z B die funktionale Es muss ein benutzerdefiniertes Attribut auf dem Klassifikation Objekt Gesch ftsservice angelegt werden Attribut Service Kategorie auf dem Objekt Softwareservicetyp Serviceanbieter Informationen zum Service Verbindung zwischen Gesch ftsservice und anbieter Dabei kann es sich einem organisatorischen Objekt z B Stelle um einen internen oder einen Die Verbindung ist vom Typ stellt bereit externen Anbieter handeln Beschreibung Beschreibung zum Attribut Beschreibung Definition auf dem Objekt Service Gesch ftsservice Servicestatus z B Servicestatus Es muss ein benutzerdefiniertes Attribut auf dem Klassifikation Objekt Gesch ftsservice angelegt werden Schlagworte Stichworte die zum Service Die Schlagworte werden zum Gro teil v
330. reren Ereignissen ausgel ste zeit lich logische Abfolge von T tigkeiten Funktionen mit dem Ziel ein bestimmtes Ergebnis zu erzielen Sowohl in der EA der BPM und der fachlichen SOA Modellierung spielen Gesch ftsprozesse und Funktionen eine zentrale Rolle wenn auch mit jeweils unterschied licher Detaillierung Betrachtet man bei der EA Modellierung prim r die Gesch ftsprozes se und ihre Beziehungen zueinander so wird bei der BPM Modellierung zus tzlich Wert auf die detaillierte fachliche Beschreibung der einzelnen Funktionen gelegt aus denen sich ein Gesch ftsprozess zusammensetzt Die fachliche SOA Modellierung legt ihren Schwer punkt dagegen auf die Gesch ftsprozesse und Funktionen aus technischer Sicht d h aus gerichtet auf die Anforderungen einer Automatisierung 2 3 1 2 Organisationsstruktur Auch die Modellierung der Organisationsstruktur wird unterteilt in fachliche und techni sche Inhalte Die Modellierung der fachlichen Organisationsstruktur betrachtet alle Inhalte die zur Beschreibung organisatorischer Zusammenh nge 1m Rahmen der EA und des BPM erforderlich sind Diese ber cksichtigen im Wesentlichen die Beschreibung von Organisa tionseinheiten Stellen und geographischen Strukturen wie zum Beispiel Regionen L nder Geb ude etc sowie deren Beziehungen untereinander Neben einer rein organisatorischen Betrachtung werden 1m Zusammenhang mit der fachli chen SOA Modellierung auch Rollen betrachtet Rollen sind defi
331. reservice Operationstyp 219 9 Entwurf und Aufbau prozess getriebener Kennzahlensysteme 9 1 Fragen die dieses Kapitel beantwortet Was ist Process Controlling berhaupt Aus welchen Komponenten bestehen die IT Systeme ftir das Process Controlling Wie sieht die Systemarchitektur aus Welche Schritte m ssen Sie f r eine erfolgreiche Modellierung durchf hren Wie erfolgt eigentlich die Modellierung Was s nd typische Lessons Learned aus Projektbeispielen 9 2 Die Herausforderung im Process Controlling In der Fachpresse tauchen h ufig Begriffe wie Corporate Performance Management Enterprise Performance Management oder Process Excellence auf Sie beziehen sich auf einen bislang vernachl ssigten Bereich der operativen Exzellenz des Unternehmens die Gesch ftsprozesse Gesch ftsprozessmanagement wurde in den letzten Jahren von den Unternehmen als Chance erkannt um ihre Effektivit t und Effizienz der wertsch pfenden Prozesse zu stei gern Dies best tigt Rolf Schumann Director Customer Advisory Office SAP AG Das Problem der Unternehmen heute besteht oftmals darin dass sie in ihrer IT gefangen sind Die Flexibilit t die n tig ist um beispielsweise auf u ere Einfl sse rasch reagieren und Prozesse anpassen zu k nnen ist gr tenteils nicht gegeben Prozessanpassungen sind viel zu aufw ndig Die Organisationsstrukturen wurden h ufig auch auf eine Prozessorganisa tion ausge
332. rgehen des prozessbasierten SOA Ansatzes 199 8 Der prozessgetriebene SOA Ansatz 200 Da grunds tzlich verschiedene Prozessausf hrungssprachen zur Verf gung stehen z B BPEL oder XPDL und diese im Detail unterschiedliche Implementierungsansatze verfol gen sei darauf verwiesen dass dieses Kapitel eine Implementierung in BPEL vgl Kasten verfolgt Die Unterscheidung zwischen verschiedenen technischen Zielsprachen wird al lerdings nur bei der absolut implementierungsnahen Modellierung auf unterster Ebene re levant Die brigen vorgestellten Modellierungsans tze abstrahieren von der konkreten Ausf hrungssprache was auch als klare Empfehlung f r die Modellierung gelten kann Exkurs Business Process Execution Language BPEL Spezifikation einer Sprache zur Definition ausf hrbarer Prozesse im XML Format E Web Service WS Standard standardisiert bei OASIS Nutzt Web Service Aufrufe zum Zugriff auf implementierte Funktionalit ten Ausfuhrungskomponenten Process Engines f r BPEL von verschiedenen Softwareanbietern verf gbar Spezifikation und weitere Informationen unter http www oasis open org 8 3 3 Zielgruppen und Zust ndigkeiten abgrenzen Nun gilt es die relevanten Informationen zur Erreichung der Zielsetzung zu ermitteln die se anschlie end zu sammeln und in Form von Modellen zielgruppengerecht aufzubereiten Im ersten Schritt werden dazu die relevanten Zielgruppen benannt und bez glich ihrer Zu
333. ributen des BPA Objekts fe Objekteigenschaften Yerfuegbare Lagermenge ermitteln l E xj Attribute n Attribute verfuegbare Lagermenge ermitteln Deutsch Auspr gungen Beziehungen E Format Objektelarstellung i Attributplatzierung Objekte Hinterlegurigen i Information varianten ame iamen Mame Lagermenge ermitteln Serviceoperation Weitere Attribute Abbildung 8 14 Pflege von Service und Serviceoperation in den Attributen einer Funktion 214 8 4 SOA Prozessmodellierung in der Oracle BPA Suite Funktion lassen sich der zu nutzende Service und die zugeh rige Operation hinterlegen vgl Abbildung 8 14 Diese Informationen k nnen in der BPA Suite auch auf dem Dia gramm angezeigt vgl Verfuegbare Lagermenge ermitteln in Abbildung 8 11 oder in Form eines Reports zusammen mit der Grafik des Prozessmodells als Dokument ausgege ben werden Technischer Kontrollfluss Der technische Kontrollfluss wird hnlich wie bei der EPK ber die Verbindungen zwi schen den Prozessschritten Tasks abgebildet In BPMN wird der Hauptprozessfluss als Sequence Flow bezeichnet Zus tzlich stehen auch hier Konnektoren zur Abbildung des Kontrollflusses zur Verf gung In BPMN werden die Konnektoren Gateway genannt neben paralleler AND und alternativer OR XOR Verarbeitung erlaubt die BPMN auch so genannte Complex Gateways denen wie der Name schon sagt komplexe Bedin gungen zugeordne
334. richtet um die notwendige Agilitat zu erreichen aber die Ermittlung von Daten 221 9 Entwurf und Aufbau prozessgetriebener Kennzahlensysteme 222 und Kennzahlen zu den Prozessablaufen und das auch noch in Echtzeit wurde haufig vernachlassigt Eine besondere Bedeutung in diesem Zusammenhang wird dem Process Controlling zuteil Im Rahmen der organisatorischen Implementierung des Process Controlling werden mit Hilfe von IT Systemen Kennzahlen f r die Prozesse ermittelt um die Prozesse transparen ter und steuerbarer zu machen Je nach Grad der Realisierung des Process Controlling k nnen sogar Kennzahlen in Echtzeit f r die operativen Prozesse ermittelt und somit der Ansatz des Real Time Enterprise unterst tzt werden Die Herausforderung liegt in der technischen Implementierung der Messung der ben tigten Prozesskennzahlen und somit in einem Aufbau einer konsolidierten Datenbasis f r die Real Time Steuerung IT System Process Monitoring und der Prozessanalyse IT Sys tem Process Mining Reifegradmodell f r das Process Controlling Das Process Controlling kann in unterschiedlichen Unternehmen verschiedene Reifegrade haben Stufe 5 Optimizing Fr hzeitiges aktives und pr ventives Management von Prozessen Kon trolle und Steuerung Stufe 4 Managed Stufe 3 u u Defined Reaktives Manage ment des Prozess Stufe 2 portfolios Kontrolle Repeatable Stufe 1 Prozesslandkarte Initia
335. rierung mehrerer elementarer Funktionalit ten technische Services Die technischen Services unterst tzen mit ihren Operationen die einzelnen Prozessschritte im fachlichen IT Modell Die fachlichen IT Modelle k nnen in der BPA Suite grunds tzlich wieder als Ereignisge steuerte Prozesskette EPK oder als Business Process Diagram BPD in BPMN model liert werden Wegen der in Abschnitt 8 3 5 diskutierten St rken der BPMN bei der Abbil dung technisch orientierter Prozessmodelle wird in dem nachfolgend vorgestellten Ansatz die BPMN eingesetzt Zur Automatisierung der fachlichen Services lassen sich in der Oracle BPA Suite unter schiedlich detaillierte Modellierungsans tze realisieren Die Entscheidung wie das fachli che IT Modell ausgestaltet wird obliegt dabei dem jeweiligen Projekt und wird sich ent sprechend der gew hlten Zielsetzung voneinander unterscheiden Im Wesentlichen h ngt die Unterscheidung davon ab wie stark sich die Modellierung an der sp ter in der IT Implementierung genutzten Produktplattform und deren Eigenschaften orientiert Dieses Kapitel konzentriert sich auf einen Modellierungsansatz in der Oracle BPA Suite der von der IT Produktplattform abstrahiert Die BPA Suite bietet ber diesen Ansatz hinaus zu s tzliche Funktionalit ten die eine Modellgestaltung f r die bertragung in die Oracle SOA Suite erm glichen Auf diese M glichkeiten wird abschlie end kurz eingegangen 8 4 2 1 Das pragmatische fachliche
336. ringer als Bestellmenge Bitte ausw hlen Taillieferung Si 2 Abbildung 6 18 ee Peer Maske Teillieferung 6 5 3 3 Maskenfl sse Nachdem die Masken f r unser System beschrieben sind kann die Navigation zwischen diesen in einem Extra Modell dargestellt werden um sicherzustellen dass keine notwen digen Navigationspfade vergessen werden Bereits die Darstellung des Systemablaufmo dells zeigt dass der Benutzer von der Maske Bestellung suchen auf die Maske Bestel lung und m Falle einer zu geringen Liefermenge auf die Maske Teillieferung gelangen muss Um weitere Artikel zu bearbeiten ist also auch ein R cksprung auf die Maske Be stellung notwendig In unserem sehr berschaubaren Beispiel in dem nur ein Ausschnitt eines Systems betrachtet wird bringt die Maskennavigation aufgrund der sehr geringen Komplexit t des Systems m glicherweise wenig Mehrwert Stellen Sie sich nun jedoch ein System vor das zahlreiche Funktionalit ten mit hinterlegten Systemabl ufen auf mehreren Masken beinhaltet siehe Abbildung 6 19 In diesem Fall stellt eine Darstellung des Zu sammenhangs und der Navigation zwischen den verschiedenen Masken eine gro e Hilfe dar sowohl f r den Ersteller des Fachkonzepts als auch f r den Realisierer Bestellung Bestellung suchen L u Sand Abbildung 6 19 df Maskenfl sse 6 5 3 4 Benutzerrollen Das dargestellte Beispiel macht sicherlich kein komplexes Rollenkonzept notwendig
337. rmationstechnologie f hrt zu den besten Modellierungsergebnissen Wir empfehlen aus diesem Grund die Unterteilung des Repositorys in die Haupt bereiche Fachliche Inhalte Fachliche IT Inhalte und Informationstechnische Inhalte Ein weiterer Grund f r die Wahl dieser Gliederung ist das Rechtekonzept der Oracle BPA Suite Durch die Unterteilung n Fachliche Fachliche IT und Informationstechnische Inhalte kann der Zugriff auf die jeweiligen Inhalte genau mit Berechtigungen belegt wer den Beispielsweise k nnen Prozessmodellierer durch diese Teilung lesend auf Objekte der Anwendungs und Infrastrukturmodellierung zugreifen diese jedoch nicht ver ndern Neben der erforderlichen aufger umten Ablage Ihrer Modellinhalte ergeben sich erste Governance Strukturen Ihrer Modellierung Wir erstellen zun chst die Ordnerstruktur wobei bereits jetzt einige Ordner angelegt wer den die erst 1m weiteren Verlauf der Modellierung ben tigt werden Bisher nicht beschrie bene Inhalte werden w r im weiteren Verlauf des Buches erl utern siehe die jeweilige Kapitelangabe in Tabelle 5 9 Fachliche Inhalte Innerhalb dieses Modellbereiches werden alle betriebswirtschaftlichen Modellierungsin halte zusammengefasst Dies umfasst die IT neutrale Modellierung der Prozesse der Ge sch ftsobjekte der Organisationsstruktur und der Prozesscontrollinginhalte Fachliche IT Inhalte Innerhalb dieses Modellbereiches werden alle Informationen abgelegt
338. rn sichern und ber die Schaltfl che Warenein gangsprotokoll drucken ein Protokoll ausdrucken das die angezeigten Informationen inkl der bei abweichenden Liefermengen angegebenen Gr nde enth lt Dabei muss das System den Benutzer darauf hinweisen dass nur gespeicherte nderungen ausgedruckt werden so dass der Benutzer nderungen erst speichern muss bevor er das Wareneingangs protokoll ausdruckt nn te ikon O a aio offen Musterfirma nase Pat E Bestellnumm er z Menge mae sae Pos Arkarummer Bezaen Enzeprai Betamerge Gesomipres Uefemenge M os I nal m mo Pe a ao oe oo am SS Wareneingangsprotokoll nderungen speichem cken Abbildung 6 17 Maske Bestellung 149 6 Modellgest tzte fachliche Konzeption individueller IT Systeme 150 Teillieferung siehe Abbildung 6 18 Beschreibung Definition Gibt der Benutzer zu einer Artikelposition einer Bestellung eine kleinere Liefermenge als die bestellte Menge ein muss er auf dieser Maske den Grund f r die Abweichung angeben Es kann sich bei der gelieferten Menge entweder um eine Teillieferung handeln so dass die Differenz zur bestellten Menge in einer weiteren Lieferung nachkommen wird oder die gelieferte Menge ist tats chlich falsch Der gew hlte Grund wird zur Arti kelposition gespeichert und die Maske wird geschlossen so dass der Benutzer wieder auf die Bestellungsmaske gelangt Liefenmenge 1 ge
339. rochen werden und alle haben einen ausreichenden berblick ber die Services im Portfolio Je gr er die Zahl der Services und der beteiligten Personen desto schwerer fallen aber Absprachen Auswirkungen k nnen sein dass Services doppelt oder ahnlich ins Portfolio eingef gt und implementiert werden dass die Dokumentationspflicht nur mangelhaft erf llt wird oder dass keine Anpassungen an bestehenden Services durchgef hrt werden Tendenziell wird der Weg des geringsten Widerstandes gew hlt ohne auf den Wert eines sauberen Service portfolios zu achten Um solche Probleme zu vermeiden m ssen Regeln entworfen und die Einhaltung der Re geln berwacht werden Meist bernimmt das der so genannte Serviceportfolio Manager 7 3 Aufbau eines Serviceportfolios Eine Beispielregel k nnte sein Wann wird ein Service neu implementiert E Gibt es einen hnlichen Service gt Dann wird dieser verwendet oder um die neuen Anforderungen erweitert E Gibt es keinen eigenen Service aber k nnte er eingekauft werden gt Management Entscheidung Kaufen vs Selberbauen Gibt es einen vergleichbaren Service gt Entwicklungsauftrag einreichen Je gr er Ihre SOA wird umso st rker m ssen Sie sich um die Governance Themen k mmern Vermeiden Sie unbedingt Wildwuchs in Ihrem Serviceport folio Serviceidentifikation Die Serviceidentifikation ist einer der wichtigsten Punkte beim Aufbau eines Serviceport folios Hier gilt es die Serv
340. rozesse bereitstellt gibt es jedoch nach wie vor hohen Informations und Strukturierungsbedarf 8 2 2 Gr nde f r das Team BPM und SOA Die Frage ab wann ein Unternehmen wirklich eine serviceorientierte Architektur hat bereits mit den ersten als Web Services implementierten Softwarekomponenten oder erst mit einem unternehmensweit dokumentierten Serviceportfolio und m glichst hohem Grad an Wiederverwendung soll hier nicht vertiefend diskutiert werden Die praktischen Er fahrungen aus realen Projekten zeigen jedoch mittlerweile dass serviceorientierte Ans tze die im Unternehmen wirklichen Nutzen bringen sollen ohne methodisches Vorgehen und strukturiertes Aufarbeiten der Informationen wenig Erfolg versprechend sind In diesem Umfeld gilt es insbesondere den Fokus auf die fachlichen Aspekte einer SOA zu lenken und die technische Implementierung in der IT bewusst auf diese fachlichen Anforderungen hin auszurichten Einen vielversprechenden und mittlerweile praxiserprobten Ansatz stellt dabei die Kombi nation der Serviceorientierung mit einem fachlichen Business Process Management BPM dar Die systematische Analyse und Modellierung der fachlichen Prozesse m Unterneh men liefert vielf ltige Informationen und methodische Ans tze f r E das bertragen der wertsch pfenden Aktivit ten eines Unternehmens auf die IT Sys teme in Form implementierter Prozesse E das Identifizieren und Dokumentieren der erforderlichen fachl
341. rstellung eines integrierten Modells sind insbesondere die Teile einer Enterprise Archi tecture von Bedeutung die wesentliche Informationen f r die nachfolgende Modellierung von BPM und SOA Inhalten liefern Bei der Auswahl der EA Modellinhalte beschr nken wir uns auf diesen Anwendungsfall 2 2 2 Inhalte f r die BPM Modellierung Auch Business Process Management BPM hat sich in den letzten Jahren zu einem Thema mit vielen Facetten entwickelt Je nachdem wen man befragt erh lt man zu BPM sehr unterschiedliche Definitionen F r BPM existiert in den USA eine andere Definition als in Europa In den USA wird unter BPM m Wesentlichen die Automatisierung von Prozessen mit Hilfe der Informati onstechnologie verstanden Rein fachliche Betrachtungen ohne informationstechnologi schen Inhalt werden in der Regel nicht dem BPM zugeordnet sondern st rker im Bereich Business Process Reengineering BPR gesehen Damit erh lt BPM in den USA seine Bedeutung haupts chlich durch die Digitalisierung und Automatisierung von Prozessen Anders als in dieser stark technologischen Sichtweise wird BPM in Europa zun chst mit der fachlichen betriebswirtschaftlichen Gestaltung von Geschaftsprozessen in Verbindung gebracht Dabei handelt es sich um eine neutrale von technischen Inhalten weitgehend befreite Sicht Diese umfasst neben der Analyse von Gesch ftsprozessen auch deren fach liche Optimierung Dokumentation und Kommunikation Erst in nachfolgen
342. rsten Schritt f r die Definition klarer Transformationsregeln Diese Regeln garantieren erst die Umwandlung von Informationen aus den operativen Systemen in serialisierte Prozessinformationen Die durch PUSH Konzepte implementierte Datenbewirtschaftung transformiert und l dt die ben tigten Da ta Warehouse Tabellen im Rahmen des Process Warehouse Die Modellierungskonventionen der Oracle BPA Suite unterst tzen die vorgestellte Me thode Die Modelle lassen sich in einem gemeinsamen Repository ablegen und erzeugen die ben tigte Transparenz der komplexen Zusammenh nge Wichtig ist uns hier die lose Kopplung der Objekte innerhalb der Modelle Dies erm glicht die Innovation und Ver n derung einzelner Prozesse oder IT Systeme ohne die komplette Modellierung umschrei ben zu m ssen Au erdem sorgt es daf r dass fachliche Beschreibung und Implementie rung sauber voneinander getrennt bleiben Durch das Process Controlling mit einem Process Warehouse schlie t sich der oft theore tisch beschriebene Regelkreis des Geschaftsprozessmanagements Das Process Warehouse liefert nun systemseitig valide Kennzahlen f r Prozessanalysen und die begleitende Pro zessoptimierung Der Druck vieler Unternehmen ihre Geschaftsprozesse flexibel auf neue Gesch ftsmodelle umzustellen wird dazu f hren dass sich die geschilderten Ans tze eines Process Monitoring und Process Mining mittelfristig durchsetzen werden 9 8 Fazit 259 Literatur Aals00
343. rt Verbindung zwischen Geschaftsservice und einem organisatorischen Objekt z B Stelle Die Verbindung ist vom Typ ist verantwortlich fur Ansprechpartner Person Rolle oder fur betriebsre Es muss ein benutzerdefiniertes Attribut Betrieb levante Dinge zustandige Abteilung auf dem Objekt Softwareservicetyp angelegt werden Input Output Geschaftsobjekte die als Input und Werden im Modell als Geschaftsobjekte Geschafts als Output verwendet werden mit dem Geschaftsservice verbunden objekte Technologische Informationen Information _ Beschreibung BPA Suite Service ID Technische ID des Service mit der Attribut dentifizierer auf dem Objekt der Service auch in einem techni Softwareservicetyp schen Service Repository gefun den werden kann URI Aufrufadresse des Service Attribut Quelle auf dem Objekt Soft besser geeignet ist ein Link zu wareservicetyp einem technischen Schnittstellen dokument Anwendungs Das Anwendungssystem welches Wird im Modell durch eine Verbindung system den Service realisiert mit einem Anwendungssystem darge stellt Plattform Auf welcher Plattform ist der Servi Es muss ein benutzerdefiniertes Attribut ce realisiert auf dem Objekt Softwareservicetyp angelegt werden Technologie In welcher Technologie ist der Es muss ein benutzerdefiniertes Attribut Service realisiert auf dem Objekt Softwareservicetyp angelegt werden Einschr nkungen Ggf Einschr nkungen die zu Es muss ei
344. rt Wird ein Prozess schrittweise in einen IT gestiitzten Service berf hrt dann wird letztlich auch die Prozessschnittstelle in der IT realisiert Beispiel Die Spesenabrechnung wurde nahezu komplett automatisiert Frau M ller bekommt die Spesenformulare nicht mehr per Post geschickt sondern diese werden direkt elektronisch in den Prozess berf hrt Nach einer technischen Validierung muss Frau M ller die Spesen freigeben um den Prozess weiterlaufen zu lassen Die vollautomatisierten Prozesse laufen ohne Benutzerinteraktion Sie sind von der IT komplett realisiert Eingriffe in den Prozessablauf sind lediglich administrativer Natur Beispiel Die Spesenabrechnung wurde komplett automatisiert Alle Regeln zur Genehmigung oder Ablehnung eines Spesenantrages wurden in der IT implementiert Den bergang von einem fachlichen Prozess zu einem teilautomatisierten oder vollauto matisierten Prozess beschreiben wir n Kapitel 8 Achtung E Nicht jeder Prozess im Prozessmodell ist auch ein Service Es muss immer gepr ft werden ob der Prozess die Eigenschaften eines Service erf llt Nicht jeder Service ist ein Prozess Atomare oder eingekaufte Services wer den nicht detaillierter im Prozessmodell modelliert 161 7 Identifizierung und Modellierung fachlicher Services fur SOA 162 Verzeichnis Ein wesentlicher Teil von SOA ist das Service Verzeichnis Hier werden alle Services publiziert damit sie auffindbar sind A
345. rt werden Abbildung 5 15 zeigt ein solches Containerdia gramm f r Gesch ftsobjekte A C In G M O U Buchungs eklamations Wareneingangs Material OPL Bukchungsanzei Bestand J ale A agesjournal Fertigware otokoll 3 Material Zahlungs ed Wa klamati P Kunder ntwieklungs i oer ren ma ionsmel ung a A araon ii Wareneingangsbuch lieferung ch ausgang mi iLleferant g l TAT Material sarbeitungs Kurden Waren z Liefe gerungs ng a mg auftrag reklamation 3 bestellung d m Kunden E Materalstichpr Rechnung nine ch Lieferschein Artikelliefernen ul edarfeplanun Eig nzter E n Abbildung 5 15 Gesch ftsobjektmodellierung mit Hilfe eines Containerdiagramms Fachbegriffsdia gramm 5 2 5 3 Erstellung der Anwendungssystembibliothek Die Modellierung der Anwendungssystembibliothek erfolgt je nach dem Informationsbe d rfnis im Unternehmen heterogen Sie kann ausgehend von der reinen Beschreibung vorhandener Anwendungssystemtypen bis hin zu einer detaillierten Aufgliederung der 106 5 2 Aufbau des Grundmodells Systemmodule und Masken erfolgen Grundsatzlich empfehlen wir in diesem Modellbe reich nur Anwendungssysteme und deren Bestandteile aufzunehmen die in einem direkten Zusammenhang mit dem Endbenutzer stehen Dies bedeutet es sollten hier nur f r die betriebliche Wertsch pfung oder deren Unterst tzung relevante Anwendungssysteme a
346. rten Prozessmodellierung in der Oracle BPA Suite genutzten Objek te auf Die Tabelle gibt auch Auskunft ber die eingesetzten Diagrammtypen und die Ver bindungen Kanten die Objekte miteinander verbinden Grundsatzlich ist der Einsatz an derer Objekte und Kanten m glich was je nach Zielsetzung der Modellierung angebracht und erforderlich se n kann Tabelle 8 1 Diagramm und Objekttypen der SOA Prozessmodellierung Diagrammtyp Quellsymbol Zielsymbol Fachliches Detailmodell Funktionszuordnungsdiagramm Fachbegriff ist Input f r Funktionszuordnungsdiagramm Personentyp Funktion Funktionszuordnungsdiagramm Personentyp ist fachlich Funktion verantwortlich f r Funktionszuordnungsdiagramm Personentyp wirkt beratend mit Funktion Funktionszuordnungsdiagramm Personentyp muss informiert Funktion werden ber Funktionszuordnungsdiagramm Gesch ftsservice unterst tzt Funktion Operation Funktionszuordnungsdiagramm Use Case unterst tzt Gesch ftsservice Operation Operation Fachliches IT Modell Business Process Diagram Data Object liefert Input f r Funktion BPMN Typ Informations tr ger Business Process Diagram Funktion erzeugt Output Data Object BPMN auf Typ Informations tr ger Business Process Diagram Diverse weitere laut BPMN Spezifikation und BPA Suite zugelassene Verbindungen Funktionszuordnungsdiagramm Softwareservice unterst tzt Funktion Operationstyp Zugriffsdiagramm Softwareservicetyp ruft auf Softwa
347. rungen vornehmen m ssen 114 5 2 Aufbau des Grundmodells A Hauptgruppe 3 01 _Fachliche Inhalte I Dynamische Inhalte L I Beschaffungsprozesse E Controlingprozesse Statische Inhalte e Gesch ftsobjekte 4 Organigramme A Frozesscontrollng ual Kennzahlen Br Ziele und Erfolgsfaktoren 13 02_Fachliche IT Inhalte on Dynamische Inhalte ee IT Anwendungsf lle P IT Prozesse Statische Inhalte IT Geschattsobiekte ST Rolen al IT Services al Maskendetinitionen P Maskentlisse A O03 _Informationztechnische Inhalte A Dynamische Inhalte 4 Ceneriete BPEL Diagramme Statische Inhalte ET Architektur E Anwendungssysteme Be Datenbanken 4 server Hardware und virtuelle Server O 504 Profile Abbildung 5 20 Grundstruktur zur Ablage der Modellinhalte in der Oracle BPA Suite 115 6 Modellgestutzte fachliche Konzeption individueller IT Systeme 6 1 Fragen die dieses Kapitel beantwortet E Warum sollte die IT in der Regel den Gesch ftsprozessen folgen und nicht umgekehrt E Welche Vorteile bringt eine strukturierte Anforderungserhebung auf Basis eines durch g ngigen Fachprozesses E Wie nehme ich am besten Fachprozesse im Rahmen einer Fachkonzepterstellung auf E Wie stelle ich Fachprozesse Systemverhalten und statische Systemkomponenten im Modell dar E Welche Teile eines Fachkonzepts sollte ich im Modell darstellen und welche nicht E Wi
348. rvicelebenszyklus gespeichert Die BPA Suite kann als fachliches Serviceverzeichnis und als Serviceportfolio verwendet werden Aus technischer Sicht st eine Zusammenlegung noch nicht sinnvoll Die BPA Suite unterst tzt nicht die Anforderungen an ein technisches Serviceverzeichnis Es k n nen zum Beispiel keine Services automatisiert aufgefunden werden Ferner ist es nur schwer m glich die technischen Schnittstellendokumente aus der BPA Suite abzurufen Deshalb ist eine Trennung von Serviceverzeichnis und Serviceportfolio in ein technisches Serviceverzeichnis z B eine UDDI Registry und die BPA Suite als Serviceportfolio sinnvoll 7 3 Aufbau eines Serviceportfolios Ein Servicelebenszyklus im Portfolio kann folgenderma en aussehen 1 Es wurde ein Servicekandidat gefunden und in das Portfolio aufgenommen 2 Der Servicekandidat wird als manueller Service aufgenommen und die Schnittstelle wird publiziert In dieser Phase wird die Leistung noch komplett durch einen Mitarbei ter erbracht Die Schnittstellenbeschreibung darf aus diesem Grunde noch gewisse Un genauigkeiten aufweisen 3 Der Service soll langfristig als IT Service angeboten werden Im ersten Schritt be kommt der Service eine technische Schnittstelle die jedoch noch auf ein Workflow system verweist Die technische Schnittstelle kann bereits in anderen Prozessen und Systemen verwendet werden Die Leistung wird jedoch immer noch manuell erbracht Der Mitarbeiter erh lt die
349. s IT Projekte gibt wird versucht ein gemeinsames Verst ndnis aller Beteiligten zu erreichen Die Kommunikation in IT Projekten zwischen allen Beteiligten zu verbessern ist deshalb auch keine neue Herausforderung Der Maschinen und Anlagenbau hat dar n beispielhafte Perfektion und Qualit t erreicht Dort existiert ein etabliertes System an Me thoden Standards und Normen welche weltweit G ltigkeit haben und zu einem allgemei nen Verst ndnis ber Unternehmens und Fachgebietsgrenzen hinweg beitr gt Wenn Sie eine Maschine bauen ist es unerheblich ob eine daf r ben tigte Schraube in Deutschland oder den USA hergestellt wurde Entspricht sie den allgemein anerkannten Normen passt s e berall Die Informatik ist bei weitem noch nicht so weit trotz erheblicher Fortschritte in der Stan dardisierung und Normierung Denken Sie nur einmal an die Probleme vieler Unternehmen mit Off Shore Dienstleistungen Dort h ngt der Erfolg besonders von einer guten Kom munikation und einem gemeinsamen Verst ndnis der Projektinhalte ab Wenn das gemein same Verst ndnis aber bereits auf Unternehmensniveau nicht vorhanden ist wie soll es dann erst in einem globalen Ma stab funktionieren Zur Verteidigung muss man allerdings auch ber cksichtigen dass die Informatik als Quer schnitttechnologie nahezu alle Bereiche moderner Unternehmen durchdrungen hat und somit enorm komplexe Zusammenh nge entstanden sind Das erschwert den Aufbau all gemein akzept
350. s Management Fach wie auch EDV Abteilungen haben eigene Vorstellungen wie diese zu beschreiben sind Grundsatz lich gilt jedoch dass alle drei Gruppen mehr oder weniger auf die Informationen der je weils anderen Bereiche angewiesen sind Damit existieren Schnittmengen des Informati onsbedarfs welche s ch lediglich n der jeweiligen Detailtiefe der Modellierung unter scheiden Abbildung 2 2 zeigt beispielhaft welche Artefakttypen in der Schnittmenge eines integrierten Modells ber cksichtigt werden m ssen EA Geschaftsprozesse Infrastrukturen Organisationsstrukturen Geschaftsobjekte Anwendungssysteme Abbildung 2 2 Artefakttypen der Schnittmenge eines integrierten EA BPM und SOA Modells Die Schnittmenge des Informationsbedaprfs so zu gestalten dass sie alle drei Gruppen zufriedenstellend bedienen ist die Herausforderung bei der Erstellung eines integrierten Modells Um die unterschiedlichen Zielsetzungen von Management Fach und EDV Abteilung bei der Modellbildung zu verbinden m ssen die Schnittmengen des Informati onsbedarfs bekannt und zwischen den beteiligten Personengruppen abgestimmt werden 19 2 Integrierte Modellierung fur EA BPM und fachliche SOA 20 Die 1m Folgenden vorgestellte Einteilung hilft Ihnen die Artefakttypen der Schnittstellen zu erkennen und eine Struktur f r ein integriertes Modell zu entwerfen 2 3 1 1 Gesch ftsprozesse Unter Prozessen versteht man eine von einem oder meh
351. s betrifft insbesondere Kapitel 7 und Kapitel 8 Das Buch bietet Ihnen einen berblick ber den grunds tzlichen Aufbau eines integrierten EA BPM und fachlichen SOA Modells Es zeigt Ihnen E welche EA BPM und fachlichen SOA Inhalte in einem Modell vereint werden m s sen wie ein werkzeugneutrales Meta Modell entworfen und bewertet werden kann wie ein individuelles Meta Modell in der Oracle BPA Suite umgesetzt wird wie ein Grundmodell als Basis f r die Modellierung erstellt wird mit welchem Ansatz ein modellgest tzter fachlicher Entwurf von IT Systemen aufge baut werden kann 1 Einleitung E wie fachliche Services fiir eine SOA Modellierung identifiziert werden k nnen E einen Vorschlag zur Erstellung eines fachlichen SOA Modells mit der Oracle BPA Suite und E wie sich die fachliche Konzeption eines Prozesscontrollings im Modell integrieren l sst Viele Wege f hren nach Rom Nutzen Sie das vorliegende Buch als Anregung f r Ihre individuelle Gestaltung Auch wir mussten Kompromisse bei der Ausgestaltung des integ rierten Modells machen Unser Ansatz wird mit Sicherheit nicht jede individuelle Frage stellung abdecken Wenn Sie ihn dabei als Ausgangspunkt f r Ihre individuelle Modell struktur verwenden wird er wertvolle Dienste leisten Erg nzen Sie ihn dort wo erforder lich und reduzieren Sie ihn wo immer es sinnvoll erscheint 1 5 Was Sie in diesem Buch nicht finden Das vorliegende Buch ist keine deta
352. satz zum oftmals bestehenden Mono lithen lassen sich hier Auswirkungen von Anpassungen leichter einsch tzen Verbesserte Interoperabilit t ERP Integration B2B Fusionen und Aufk ufe Erh hte Integrationsf higkeit z B von Alt Systemen bzw Zusammenspiel von In dividual und Standardsoftware Die Interoperabilit t von Business zu Business wird vereinfacht Die eigene IT Architektur kann Aufk ufe von Fremdunternehmen leichter aufneh men Systeme k nnen verbunden oder je nach Leistungsf higkeit auch ersetzt wer den E Bestandschutz von Alt Systemen Integration vs Neuentwicklung Alte Systeme m ssen nicht zwangsweise neu implementiert werden Sie k nnen u U mit Service Wrappern versehen werden So bieten diese Alt Systeme hre Leistung ber eine Serviceschnittstelle an Diese kann man in Prozessen verwen den E Die Anbindung externer Dienstleistungen oder Outsourcing wird vereinfacht Funktionalit ten k nnen ggf g nstiger eingekauft und in die eigene Systemland schaft integriert werden 169 7 Identifizierung und Modellierung fachlicher Services fur SOA 7 3 In B2B Szenarien m ssen eventuell fremde Services genutzt bzw eigene angeboten werden Sauber beschriebene eigene Services k nnen leichter durch Outsourcing ersetzt werden Servicegrenzen sind gleichzeitig die Verantwortungsgrenzen E Dokumentierte IT Dienstleistungen unternehmensweites Service Portfolio siehe auch Abschnitt 7 3 Die IT
353. sch iefermenge Zu hoch Teillieferung pr fen ieferpositio ieferpositio ist keine ist Teillieferung Teillieferung achlieferung pr fen ieferpositio ieferpositio annehmen nicht annehmen vanati Nachlieferund Y erforderlich lamele achlieferung e A Abbildung 8 8 Fachliches Detailmodell als EPK in der Oracle BPA Suite Organisation Verantwortlichkeiten werden als Rollen 1m Modell erfasst BPA Objekt Personentyp Dabei kann im fachlichen Modell die Unterscheidung zwischen verschiedenen Formen der Verantwortlichkeit wie etwa ausf hrende Verantwortung oder Ergebnisverantwortung interessant sein Dies l sst sich ber unterschiedliche Kantentypen f hrt aus ist fach lich verantwortlich wirkt mit bei muss informiert werden ber im Sinne einer RA CI Darstellung abbilden Wird der Prozessschritt durch einen Service unterst tzt und dementsprechend in einem fachlichen IT Modell als Prozess detailliert wird in diesem Modell auch die Detaillierung der Rollen und Verantwortlichkeiten abgebildet Die Model lierung der organisatorischen Verantwortung auf dieser Ebene ist trotzdem empfehlens wert um einen schnellen berblick ber organisatorische Aspekte aus fachlicher Sicht zu gew hrleisten gt Vorgehen zur Darstellung von Verantwortlichkeiten Responsible Accountable Consulted Informed 209 8 Der prozessgetriebene SOA Ansatz 210 Datenfluss In Outputs Informations bzw Datenf
354. se des ber geordneten Prozessmodells als initiierende und nachfolgende Prozesse bernommen Gesch ftsobjekte werden bei der Modellierung der fachlichen bersichtsmodelle nicht hierarchisch gegliedert Sie k nnen auf jeder Ebene in Prozessmodellen verwendet werden Achten Sie dabei auf eine zu den Prozessen und Aktivit ten passende Granula rit t Achten Sie darauf die Gesch ftsobjekte an den Schnittstellen einzelner Aktivit ten so zu w hlen dass die untergeordneten Prozesse zu diesen Aktivit ten eine abgegrenzte Dom ne zur Beschreibung darstellt Die Beziehungen zwischen einzelnen Prozessen werden immer ber ein Gesch ftsob jekt hergestellt 1 Instanzgranularitat Unternehmensebene Abbildung 5 6 Schematische Darstellung der Zusammenh nge Fachliche bersichtsmodelle 95 5 Das Grundmodell 96 6 Sekund re Kernprozesse haben in der Regel keinen direkten Bezug zu einem externen Kunden des Wertsch pfungsprozesses Unabh ngig davon k nnen sie jedoch Ge sch ftsobjekte mit pr m ren Gesch ftsobjekten austauschen 5 2 4 IT neutrale Detaillierung der Prozesse und ihrer Aktivit ten Nachdem Sie die bersichtmodelle der ersten drei Instanzgranularit ten modelliert haben folgt mit den Ebenen der Instanzgranularit ten 4 und 5 die IT neutrale Detaillierung der Prozesse und ihrer Aktivit ten Ziel dieses Modellbereiches ist es die fachlichen Arbeits abl ufe der ermittelten Unterprozesse darzustellen
355. sem Ansatz werden lediglich Prozesse und keine Prozessmodelle beleuchtet Man startet also nicht aus der Vogelperspektive doch auch nicht auf einer so detaillierten Ebene wie beim Bottom up Ansatz Hier werden die Ereignisse n der Ge sch ftsumgebung gesammelt und aggregiert ber die Aggregate k nnen Servicekandida ten abgeleitet werden Da wir in diesem Buch von einem Prozessmodell ausgehen be schreiben wir diesen Ansatz nicht genauer Wir w rden sonst auf die Informationen die in einem Prozessmodell zus tzlich hinterlegt sind verzichten 7 4 Serviceidentifikation 7 4 2 Serviceidentifikation uber den prozessorientierten Ansatz Bei der Serviceidentifikation ber den prozessorientierten Ansatz gehen wir von einem vorhandenen Prozessmodell aus Damit stehen bereits viele Informationen in strukturierter Form zur Verf gung Folgende Informationen sind besonders interessant E Prozesshierarchie Durch Prozesshierarchien ist die Komplexit t des Unternehmens besser handhabbar E Informationen ber Prozesse Ein Prozess existiert nicht zum Spa Er erf llt eine Aufgabe und soll dem Unter nehmen einen Nutzen bringen Die Aufgabe des Prozesses ist ebenfalls im Modell be schrieben E Prozesse Prozesse enthalten detaillierte Informationen ber die Abl ufe und Zusammenh nge im Unternehmen Ein Prozess kapselt eine Menge an Einzelaufgaben E Funktionen Funktionen sind einzelne Prozessschritte Sie enthalten sehr detaillierte
356. sen Kommen wir noch einmal zur ck auf die Frage warum man nicht grunds tzlich Standard software einf hren und die Fachprozesse vorgeben lassen sollte An dieser Stelle sei ge 6 3 Die IT Sicht und ihr Zusammenhang mit der Fachsicht sagt dass auch fur die Auswahl einer Marktlosung die Anforderungen aus dem Fachbe reich die sich aus den Arbeitsablaufen ergeben zumindest grob identifiziert werden m s sen Andernfalls ist die Frage ob am Markt berhaupt passende L sungen existieren nicht zuverl ssig zu beantworten Zumindest besteht die Gefahr dass eine ausgew hlte Stan dardl sung notwendige Spezialprozesse der Fachabteilung gar nicht abbilden kann F r die systematische und strukturierte Identifikation der Anforderungen an ein IT System egal ob Individualentwicklung oder Standardsoftware ist es in jedem Fall notwendig die betroffenen Fachprozesse zu analysieren Abbildung 6 2 n chste Seite zeigt das in diesem Kapitel vorgestellte Vorgehen bei der modellgest tzten Fachkonzepterstellung Die einzelnen dargestellten Arbeitsschritte wer den im Folgenden erl utert 6 3 Die IT Sicht und ihr Zusammenhang mit der Fachsicht Abbildung 6 2 zeigt das in diesem Kapitel vorgestellte Vorgehen zur modellgest tzten Fachkonzeption Es umfasst die folgenden Schritte Aufnahme und Analyse der aktuellen Fachprozesse Ist Prozesse Entwicklung der idealen Fachprozesse Soll Prozesse Identifikation und Beschreibung der
357. ser selber ein Bild von der Arbeit mit den beiden unterschiedlichen Notationen machen Dies soll bei der Bewertung und Auswahl f r eigene Projekte helfen Gegen den kombinierten Einsatz unterschiedlicher Modelle und Notationen l sst s ch ein wenden dass hierdurch kein durchg ngiges Modell von der fachlichen Modellierung bis zur Umsetzung in der IT zur Verf gung steht Ein in diesem Sinne durchg ngiges Modell w rde nderungen am fachlichen Modell direkt auf das IT Modell bertragen und umge kehrt Diese Kritik ist durchaus berechtigt l sst sich aber bezogen auf das hier dargestellte Vorgehen entkr ften Zum einen stellt die Methodik jeder Zielgruppe das f r sie passende Modell in einer optimalen Form und Notation zur Verf gung Zum anderen entkoppelt die in Abbildung 8 4 dargestellte Hierarchiebildung ber das Konstrukt der fachlichen Servi ces die fachlichen und IT technischen Anforderungen voneinander Die Anforderungen an die Umsetzung in der IT werden in den fachlichen Services gekapselt und als separates Prozessmodell detailliert Daher wirken sich nderungen am fachlichen IT Modell nicht auf das fachliche Detailmodell aus und umgekehrt Letztlich obliegt die Entscheidung f r die Notation en Ihrem Projektvorhaben Dabei ist es nat rlich auch m glich beide Ebenen fachliches Detailmodell und fachliches IT Modell in nur einer Notation zu modellieren 207 8 Der prozessgetriebene SOA Ansatz 8 4 SOA Prozessmodellierung
358. sgehende Nachrichten und den Kommunikationskanal Diese Schnittstelle ist aus Sicht des Konsu menten das Einzige was er kennen muss um den Service zu nutzen Die eigentliche Real sierung der Leistung ist hinter der Schnittstelle verborgen Services sind unabh ngig Aus Sicht eines Konsumenten sind Services immer unabh ngig Ein Konsument muss nur genau den Service anfragen dessen Leistung er nutzen m chte Zur Erlangung dieser Leis tung ist kein weiterer Service notwendig Jeder Service besitzt seine eigene Schnittstellen beschreibung und dementsprechend auch eine eigene Nachrichtenstruktur n dieser Schnitt stelle Auch wenn der Konsument aus der Komposition mehrerer Services einen h herwer tigen Service erstellt sind die verwendeten Services immer noch unabh ngig Services sind wiederverwendbar Die vom Service bereitgestellte Leistung soll sich in verschiedenen Anwendungsf llen nutzen lassen Der Service stellt in der Regel keine Leistungen bereit die so speziell sind dass s e lediglich n einem Anwendungsfall verwendet werden k nnen 7 2 2 Missverst ndnis Service Werden Services n der IT realisiert spricht man auch hier von einem Service Wenn Services implementiert werden sollen werden sie h ufig als Web Services implementiert Die hnlichkeit der Namen f hrt oft zu einer falschen Gleichsetzung Mit Web Services ist eine Technologie gemeint Insbesondere wenn IT und Fachbereich miteinander sprechen wir
359. sich leicht aus den Prozessen extrahieren Andere Systeme k nnen diese Kennzahlen in Echtzeit auswerten z B BAM Busi ness Activity Monitoring 7 2 Services und SOA E SOA und BPM Risikominimierung durch Erf llung gesetzlicher Vorgaben Basel II SOX Compliance Themen wie Basel II oder SOX m ssen nach Vorgabe des Gesetzge bers vom Unternehmen umgesetzt werden Durch die vollst ndige Dokumentation aller Prozesse bis hin zu den beteiligten Services kann dies in einer SOA vereinfacht werden Prozessautomation l sst sich zur Risikosteuerung nutzen z B Implementierung von Eskalationsmechanismen oder B2B mit Rating Agenturen E Prozessdokumentation Ein Prozess ist vollst ndig dokumentiert und sein Ablauf kann von jedem Beteilig ten nachgelesen werden Die vollst ndige Dokumentation erm glicht die Durchgangigkeit bis zur IT in dem die Prozessdokumentation mit den IT relevanten Dienstleistungen des Prozesses angereichert wird Prozessdokumentationen k nnen f r Einarbeitung Schulung etc genutzt werden Nutzen f r die IT Abteilung E Wiederverwendung von Funktionalit t Wiederverwendung f hrt zu schnellerer und einfacherer Entwicklung und beschleunig tem time to market z B bei Anforderungen der Fachabteilungen E Kapselung von Komplexit t und erh hte Abstraktion Durch die Kapselung der Services wird die Komplexit t handhabbarer Im besten Fall ist ein Service ein Anwendungssystem Im Gegen
360. siert HANSER NEU Mit eBook zum Download und Glossary in 6 Sprachen auf CD eBooks Erlautert wie ein integriertes Gesamtmodell fur Enterprise Architecture Business Process Management und SOA erstellt wird Beschreibt den Weg vom Meta Modellentwurf bis zur Werkzeugumsetzung mit ausfuhrlichen Anleitungen und zahlreichen Praxistipps Anleitung zur praktischen Umsetzung am Beispiel der Oracle BPA Suite und der ARIS Methode d th wou s L9 sr eoe 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 n nen 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 G
361. spiel als Papierausdruck vorliegt k nnte man es sowohl der Kategorie physikalische Ressource bei ausschlie licher Betrachtung des Informationsinhaltes aber auch in die Kategorie informationstechnologische Ressour ce einordnen Im Gegensatz dazu werden Sie sicher das Gesch ftsobjekt Material ein deutig dem Bereich physikalische Ressource zuordnen Abbildung 5 14 zeigt den Gliederungsvorschlag zur Strukturierung von Informationsobjek ten innerhalb des IT neutralen Teils des integrierten Modells Ausgehend von der empfoh lenen Anzahl an Gesch ftsobjekten je Kern Haupt und Unterprozess ergibt s ch die theo retische Anzahl von 1476 Gesch ftsobjekten innerhalb der IT neutralen Modellierung Diese Zahl basiert auf der Multiplikation der empfohlenen maximalen Anzahl an Kern Haupt max Anzahl Gesch ftsobjekte 1 Instanzgranularit t max 12 KPx 3 GO je KP gt 12x3 36 GO max Anzahl Gesch ftsobjekte 2 Instanzgranularit t max 12 KP x max 6 HPx 4 GO je HP gt 12x6x4 36 max 252 GO max Anzahl Gesch ftsobjekte 3 Instanzgranularit t gt 12x6x5x4 252 1188 GO max ergeben sich 1476 GO Instanz granularit t Ausschlie liche Verwendung der max 1476 GO innerhalb des IT neutralen Modellbereichs A und 5 Jedes dieser GO muss in sich abgeschlossen und von anderen GO klar abgrenzbar sein Legende GO Gesch ftsobjekt e KP Kernprozess e HP Hauptprozess e UP Unterprozess e
362. sprozessmanagement in der Praxis 3 Auf lage Hanser 2003 Schm07 Schmelzer J Sesselmann W Geschaftsprozessmanagement in der Praxis 6 Auf lage Hanser M nchen 2007 Toga09 The Open Group Architecture Framnework TOGAF http www opengroup org Zach09 Zachman J Zachman International Enterprise Architecture http zachmaninternational com zM h00 zur M hlen M Workflow based Process Controlling Or What You Can Measure You Can Control In Fischer Layna 2000 Workflow Handbook 2001 Lighthouse Point FL 2000 S 61 77 262 Register A Anwendungssystem 21 Anwendungssystem Architektur 13 ARIS 57 Attributsymboltyp 61 Attributtyp 60 Ausf hrbares IT Modell 197 Auswahl Modellierungswerkzeug 58 B Benutzerrolle 135 BPM 14 Business Activity Montoring 226 Business Analyst 8 Business Object Model 215 Business Process Execution Language BPEL 200 Business Process Management 7 193 Business Process Modeling Notation 206 C CIM 163 Computation Independent Model 163 Corporate Performance Management 221 D Data Warehouse 225 Daten Architektur 13 Datenbeschreibung 136 Detailmodell fachlich 163 Diagrammtyp 59 Domain Level Matrix 40 Beziehung 43 Einordnung der Objekttypen 43 Dom nendekomposition 182 Dynamische Frameworks 12 siehe auch Framework Dynamische Modellierung 28 E Enterprise Architecture 7 11 Enterprise Performance Management 221 Ereignisgesteuerte Prozesskette 2
363. ssinstanz vertikale Dekomposition Abbildung 9 2 bersicht der unterschiedlichen Detail Stufen bei der Modellierung Ferner zeigen wir die Methoden und Vorgehensweisen am Beispiel des Prozesses der Wa reneingangskontrolle WEK auf In Abschnitt 9 6 gehen wir intensiv auf die Modellierung ein und nutzen hierf r den geschilderten WEK Prozess siehe Kapitel 1 223 9 3 Vision und Realitat Wie konnte die Zukunft aussehen Unternehmen implementieren in Zukunft verstarkt die Prozessablaufe flexibel in ihren IT Systemen Die fachlichen Prozessmodelle werden schrittweise um die IT spezifischen Inhalte zur Steuerung der Prozesse durch IT Systeme verfeinert Diese Prozessmodelle werden mit einer Workflow Prozess Engine implementiert und die IT Komponenten aus dem gef hrten Prozess heraus automatisch ange sprochen Der wesentliche Vorteil liegt hierbei in den generischen Sonden Adap tern innerhalb der Workflow Prozess Engine die die Prozesskennzahlen und Fakten unabh ngig von einem Eingriff in die untergelagerten operativen Systeme liefern k nnen Die ben tigten Informationen Fakten liegen bei den Workflow Systemen und Systemen zur Prozessautomatisierung im so genannten Payload bereits vor Daten die von einem Prozessschritt zum n chsten bermittelt und aktualisiert werden In der Spezifikation Audit und Monitoring INTERFACES5 des Referenzmodells der Workflow Management Coalition WfMC seit 1993 220 Mitgli
364. st demnach eine gesamte BPA Datenbank als Modell zu betrachten Wir werden im 4 3 Methodische Einschrankungen der Oracle BPA Suite Objekttypen E Symbole E Kantentypen Attributtypen E Attributsymbole Modelltypen Diagrammtypen Modelltypen besser Diagrammtypen definieren das Fundament der Modellierung Sie werden genutzt um Aspekte des Gesamtmodells innerhalb der Oracle BPA Suite zu be schreiben Die Methode legt fest welche Artefakte Symbol und Beziehungstypen auf einem Diagrammtyp angezeigt werden k nnen Stellen Sie sich einen Diagrammtyp ver einfacht als ein Blatt Papier vor auf dem Sie fest vorgegebene Symbol und Beziehungs typen darstellen und miteinander verbinden k nnen Beispielsweise k nnen S e auf einem Diagrammtyp Netzwerkstrukturen abbilden und auf einem anderen Prozessabl ufe Die freie Kombination von Inhalten ist wegen des ge schlossenen Metamodells nicht m glich Als Anwender m ssen S e mit den Darstellungs m glichkeiten der Methode leben so wie sie vom Hersteller festgelegt wurden Die Oracle BPA Suite bietet in der Version 11g 117 Diagrammtypen z B ereignisgesteu erte Prozesskette EPK und Business Process Diagram BPMN Sie k nnen bestehende Diagrammtypen duplizieren diesen eigene Namen geben und die auspr gbaren Symbol und Beziehungstypen des neuen Diagrammtyps basierend auf den vom Ursprungsmo delltyp maximal erlaubten einschr nken Eine individuelle Erweiterungsm gli
365. stand Da es sich dabei um einen eindeutig bestimmbaren Gegenstand handeln muss kann die existierende bereinstimmung immer nur durch den direkten Vergleich und nicht nach einer allgemeinen Regel erfolgen Etwas kann niemals alleine per Definition wahr sein Leider k nnen wir nicht alle Gegenst nde der realen Welt zu jeder Zeit mit uns herum tragen um sie gemeinsam mit anderen auf bereinstimmung mit unseren Erkenntnissen zu berpr fen Jederzeit den K lner Dom mit sich zu tragen um ber bestimmte Ausf hrun gen seiner Architektur mit anderen zu diskutieren gestaltet sich n der Praxis als schwie rig Welche Basis zur Kommunikation w hlt man aber wenn es nicht m glich ist einen betref fenden realen Gegenstand zur Erkenntnis berpr fung permanent im Zugriff zu haben Wie erm glicht man den Vergleich komplexer Objekte Seit Jahrtausenden nutzen Menschen die Technik der Modellierung um dieses Problem zu l sen Darunter verstehen wir die Erstellung eines Abbildes der realen Welt welches fest gelegten und bekannten Regeln folgt so dass das Ergebnis verbindlichen und kommuni 1 Einleitung zierbaren Strukturen entspricht Wir modellieren also um eine komplexe Welt in handhab und kommunizierbare Teile zu zerlegen und damit beschreibbar zu machen Das Ergebnis dieser Tatigkeit ist ein Modell 1 2 Was ist eigentlich ein Modell Der Ursprung des Begriffes Modell liegt im italienischen Begriff modello und bedeu
366. stellung und Analyse der Prozessinformationen lassen sich hinsicht lich der Anwendergruppen und ihrer Aufgaben in drei Gruppen unterteilen E Monitoring und Alerting Process Monitoring Aufgabe Anforderung Client orientierte Implementierungen von Systemen die operative Daten im Rahmen des Process Monitoring Near Real Time in Form eines Prozessleitstandes anzeigen und Nachrichten bei Eskalationen an die Verant wortlichen bermitteln Anwenderkreis Operative Prozessverantwortliche E Ad hoc Analysen Process Mining Aufgabe Anforderung schwergewichtige meist clientseitige Implementation von Ad hoc Analyse Tools teilweise Nutzung von statistischen Methoden zur explora tiven Datenanalyse komplexe leistungsf hige Systeme f r Spezialisten Anwenderkreis Process Owner Prozessanalytiker E Berichte und Dash Boards Prozess Cockpits Aufgabe Anforderung meist Web basierende Prozessportale zur Anzeige gezielter Kennzahlen meist entsprechend grafisch aufbereitet einfache Bedienung aber ein geschr nkte Flexibilit t bei der Anzeige und Auswahl der Daten M glichkeit eines Benchmarks ber die interne Verbesserung Anwenderkreis Management Architektur 232 Der Architekturentwurf f r ein Process Warehouse entspricht im Wesentlichen den klass schen Architekturmodellen 1m Business Intelligence Umfeld In den Abbildungen 9 5 und 9 6 wird die Systemarchitektur dargestellt Die einzelnen Bereiche der Architektu
367. stemtypdiagramm Process Monitoring Import und Aufbereitung Kennzahl Notification Analyse Prozessinstanz Abbildung 9 22 Modellierung der IT Systems Process Monitoring In der Regel wird man an dieser Stelle Standardprodukte f r das Business Activity Moni toring BAM einsetzen Diese Systeme haben bereits wohldefinierte meist XML basie rende Schnittstellen f r den Import der Daten Die Kennzahlen k nnen meist deklarativ beschrieben und somit ohne Programmierung instanziiert werden Ein Beispiel f r ein BAM System ist das Produkt Oracle Business Activity Monitoring BAM Orac06 Tabelle 9 14 Benutzte Methodenobjekte der Oracle BPA Suite Modellname Process Monitoring Diagrammtyp Anwendungssystemdiagramm Symbol Typ Anwendung Mehr Informationen zur Modellierung der fachlichen Anforderungen an ein IT System finden Sie in Kapitel 6 9 7 3 2 Modellierung der IT Systeme zum Process Mining Eine weitere Ma nahme war Es soll die M glichkeit der Analyse der Wareneingangskon trolle geschaffen werden damit man Optimierungspotenzial erkennen kann Das lasst sich ber ein System f r das Process Mining umsetzen Wie aus Abbildung 9 23 ersichtlich ist besteht das IT System 1m Wesentlichen aus zwei Komponenten eigentlich in Analogie mit klassischen Datawarehouse L sungen 253 9 Entwurf und Aufbau prozessgetriebener Kennzahlensysteme 254 1 Der Import von Daten die Transformation der Daten und Abla
368. t See F Hauptprozessinstanz prozess eine gt Abbildung 5 9 Horizontale und vertikale Gliederung eines Organisationsmodells Auf der x Achse haben wir korrespondierend zu der empfohlenen Anzahl von Kern Haupt und Unterprozessen die m gliche Anzahl an Organisationseinheiten angegeben die auf jeder Ebene definiert werden sollten Die Empfehlung zur Anzahl der Organisationseinheiten wird erg nzt durch einen Vor schlag zu den maximal zuzuordnenden Stellen und Personen je Organisationseinheit Er fahrungen haben gezeigt dass pro Organisationseinheit 1 bis 5 Stellen zugeordnet werden sollten die jeweils mit maximal 15 Personen besetzt werden k nnen Organisationsmodel le die diesem Mengenger st folgen haben sich als sehr stabil erwiesen Betrachten wir zur Verdeutlichung unser Beispielunternehmen zu dem bereits die Kern Haupt und Unterprozesse definiert wurden Abbildung 5 10 zeigt die direkte bertragung der Prozessstruktur auf die Organisationseinheiten der 1 bis 3 Instanzgranularitat am Beispiel des Wareneingangsprozesses Zu jedem Kern Haupt und Unterprozess wurde eine Organisationseinheit mit gleichem Namen definiert F r die 1 Instanzgranularit t entsteht auf diesem Weg eine sinnvolle und stimmige Struktur Bei der zweiten Instanzgranularitat der Detaillierung der Organisati onseinheit Beschaffung ist das Bild weniger einheitlich Die Bereiche Materiallogistik und Wareneingang sind direkt als Organisations
369. t den Kundenprozessen verbunden Sie dienen vielmehr zur internen Steuerung des Unternehmens oder zur Bereitstellung von Leistungen die nicht direkt im wertsch p fenden Ablauf des Unternehmens ben tigt werden dessen Funktionsf higkeit aber sicher stellen Ob Sie Ihre Prozesslandkarte hinsichtlich der prim ren und sekund ren Kernpro zesse ausgewogen erstellt haben k nnen S e mit folgendem Verh ltnis bewerten Prim re Kernprozesse 4 1 Kernprozesse mit direktem Bezug zum externen Kunden zu Kernprozessen ohne direkten Bezug zum externen Kunden Sekund re Kernprozesse 1 4 Kernprozesse mit direktem Bezug zum externen Kunden zu Kernprozessen ohne direkten Bezug zum externen Kunden Neben den Kernprozessen sind zur vollst ndigen Erstellung einer Prozesslandkarte noch die Gesch ftsobjekte zu identifizieren die zwischen den Kernprozessen ausgetauscht wer den Jeder Gesch ftsprozess erstellt bearbeitet oder ver ndert Gesch ftsobjekte Der Begriff Objekt ist im Rahmen der Modellierung der Ebenen 1 bis 3 sehr weit zu fassen d h nicht nur auf Daten die zwischen den Kernprozessen ausgetauscht werden zu beschr n ken Es handelt sich also um alle Objekte die in einem Prozess erzeugt genutzt bearbei tet und verbraucht werden oder anderweitig beteiligt sind um eine bestimmte Zielsetzung zu erreichen oder eine Leistung zu erstellen Unter der Annahme dass die Prozesslandkarte die erforderlichen Kernaktivit ten zur Er
370. t es an Besch ftigt man sich mit den Definitionen und Beschreibungen zu SOA st t man immer wieder auf ein Grundkonzept Es gibt einen Service den ein Anbieter bereitstellt E Es gibt einen Konsumenten der diesen Service nutzt Es gibt ein Verzeichnis ber welches der Service gefunden werden kann 7 2 Services und SOA Service Verzeichnis Zo OSX Service p Service Anbieter 4 Konsument Abbildung 7 1 Architektur der SOA Das Zusammenspiel der einzelnen Komponenten ist in Abbildung 7 1 dargestellt und wird im Folgenden erlautert 1 Der Serviceanbieter publiziert seinen Service die Schnittstellenbeschreibung in einem Serviceverzeichnis 2 Konsumenten k nnen das Verzeichnis durchsuchen 3 Konsumenten holen sich aus dem Verzeichnis die ben tigten Informationen zur Nut zung des Service 4 Der Konsument stellt an den Anbieter eine Serviceanfrage 5 Der Anbieter liefert eine Serviceantwort Auch hier l sst sich erkennen dass diese Architektur absolut IT neutral ist Es ist durchaus m glich eine rein fachliche SOA mit einem Serviceverzeichnis aus rein fachlichen Servi ces zu realisieren In der IT kann man diese Architektur exakt genau so realisieren und alle Schritte aus der Grafik automatisiert durchf hren Das Verst ndnis von Fach und IT Bereichen ist an dieser Stelle fast deckungs gleich Ziel einer SOA ist es genau ein Serviceverzeichnis zu erstellen in de
371. t im Rahmen der EA BPM und SOA Mo dellbildung alle physischen Objekte der Informationstechnologie die zur Abwicklung der Gesch ftsprozesse erforderlich sind sowie nicht direkt an der fachlichen Wertsch pfung beteiligte Software Dies sind zum Beispiel die physisch vorhandenen Objekte Server und Netzwerke und im Bereich der Software Datenbanken Virenscanner etc 2 3 2 Schnittmengen und symmetrische Differenz der Modellierungsbereiche 2 3 2 1 Erstellung eines hierarchisch gegliederten integrierten Modells Mit der Erstellung eines integrierten Modells verfolgen wir das Ziel eine EA BPM und fachliche SOA Modellierung in einem einzigen Modell zusammenzufassen Es ist nicht einfach die Inhalte einer integrierten Modellierung voneinander abzugrenzen Abbildung 2 2 zeigt dass zwischen den Modellen inhaltliche Schnittmengen bestehen Betrachten wir aber zun chst die EA BPM und SOA Modellierung unabh ngig voneinander W rden Sie nur ein EA Modell erstellen so w ren in ihm Inhalte modelliert die auch in einem BPM und SOA Modell enthalten sein m ssten Gleiches gilt f r ein einzelnes BPM oder fachliches SOA Modell nat rlich f r unterschiedliche Inhalte Da wir Redundanzen vermeiden wollen m ssen wir bei dem Zuschnitt des integrierten Modells diesen Sachver 21 2 Integrierte Modellierung fur EA BPM und fachliche SOA 22 halt besonders ber cksichtigen Bei der Erstellung der Struktur eines integrierten Modells m ssen Sie des
372. t sich folgende Definition Definition Business Activity Monitoring BAM Beschaffung Aufbereitung und Speicherung von Daten in Echtzeit um notwen dige Kennzahlen und Indikatoren f r das Process Monitoring zu erhalten 9 3 Die zentralen Begriffe In der Definition wurde bewusst auf eine implizite technologische Empfehlung verzichtet weil die BAM Implementationen im Markt recht unterschiedlich sind Die Datenhaltung reicht von XML Datenbanken ber Ablagen in RDBMS bis zu In Memory Datenhaltung um dem Anspruch auf Echtzeit mit dem notwendigen Datendurchsatz gerecht zu werden Crum06 Koch05 Process Mining Der Begriff Process Mining wird n der Literatur in unterschiedlichen Bedeutungen ge nutzt Das Process Mining soll hier analog zum Data Mining als Methode zur Gewinnung von Einsicht ber die verf gbaren Prozessdaten verstanden werden Somit werden beim Process Mining vordefinierte Performance Indikatoren gebildet und nach Zeitbezug und Dimensionen flexibel analysiert Ziel ist die Erkennung von Trends Wirkungsanalysen oder strukturellen Schwachstellen Diese Ergebnisse flie en als strategische Aspekte der Prozessoptimierung in die Gesch ftsprozessmodellierung ein Aals03 Definition Process Mining Aufbereitung von Performance Indikatoren und Analyse von Prozessdaten nach Zeitbezug und Dimensionen zur Analyse der abgelaufenen Gesch ftsprozesse Process Controlling o Kernaufgaben Process Warehouse Pro
373. t werden k nnen Au erdem existieren spezielle BPMN Symbole die beispielsweise eine wiederholte Verarbeitung Loop oder das Erzeugen einer erst zur Laufzeit definierten Anzahl von Instanzen eines Tasks erlauben Multiple Instances De taillierte Informationen ber Elemente und Notation der BPMN finden sich in BPMNO9 Bei der Gestaltung des Kontrollflusses im BPMN Modell kann die Unterstutzung des Kontrollflusses in der gewahlten technischen Zielumgebung wichtig sein Fur den Abgleich der in BPMN moglichen Kontrollflusse mit den Fahigkeiten aus fuhrbarer Prozesssprachen wie BPEL empfiehlt sich der Einsatz der in Abschnitt 8 3 5 erw hnten Workflow Patterns Datenfluss In Outputs Be der Bearbeitung der technischen Prozessschritte werden Daten ben tigt Die Daten fl sse k nnen in BPMN mit dem Objekt Data Object abgebildet werden vgl Abbildung 8 11 Die Pfeilrichtung der Kanten die die Datenobjekte mit den Prozessschritten verbin den sagt aus ob das Datenobjekt gelesen geschrieben oder bearbeitet wird Aus techni scher Sicht w re auf dieser Ebene eine detaillierte Abbildung der Datenobjekte w n schenswert so dass der SOA Entwickler sein technisches Datenmodell daraus ableiten kann z B als XML Schema Definition Allerdings bieten sowohl die BPMN Notation als auch das Werkzeug Oracle BPA Suite aktuell nur eingeschr nkte M glichkeiten zur Abbildung technischer Datenmodelle Hier kann die Pflege der technische
374. tailmodelle IT Modelle l IT Modelle l Geschaftsservice Prozess Softwareservice strukturierend F higkeit E Gesch ft lt om Operationstyp Web Service Operation Messages Fachbegriff Abbildung 7 4 BPA Sichten auf Services 7 2 Services und SOA Die Sichten aus Abbildung 7 4 Ubersichtsmodelle fachliche Detailmodelle fachliche IT Modelle und ausfuhrbare IT Modelle kann man in unsere Ebenen eines Prozessmodells einordnen siehe auch Abbildung 7 2 Die verschiedenen Sichten werden in der Hilfe der BPA Suite entsprechend der bekannten Modellierungsebenen der Model Driven Architec ture benannt MDA Die fachliche Sicht wird Computation Independent Model CIM genannt und ist eine reine Beschreibungsebene ohne technischen Fokus Die technische Sicht in der BPA Suite entspricht dem Platform Independent Model PIM Hier wird mit einer technischen Ausrichtung modelliert ohne sich auf eine konkrete Technologie festzu legen Es werden nur Konstrukte verwendet die in vielen Technologien umsetzbar sind Als weitere Verfeinerung gibt es das Platform Specific Model PSM welches sich auf eine konkrete Technologie bezieht In der BPA Suite sind dies in der Regel Modelle von Web Service Schnittstellenbeschreibungen Die Abbildung zeigt alle Verbindungen die in der BPA Suite modelliert werden k nnen Je nach Zielrichtung unseres Modells k nnen wir auf einige Objekte und Verkn pfungen
375. te vor E Wie identifizieren Sie die methodischen Einschr nkungen und passen Ihr individuelles Metamodell an E Wie werten Sie die Modellierungsmethode der Oracle BPA Suite aus E Wie bewerten Sie den Abdeckungsgrad der Metamodellumsetzung innerhalb der Oracle BPA Suite Die Oracle BPA Suite als Modellierungswerkzeug In der ersten Augustwoche des Jahres 2006 gab die Oracle Corporation bekannt die Fusi on Middleware Plattform um das Prozessmanagementwerkzeug ARIS zu erweitern Oracle beabsichtigte damit die bis zu diesem Zeitpunkt bestehende L cke m Portfolio fachlicher Modellierungswerkzeuge zu schlie en Gartner positioniert die ARIS Process Platform seit vielen Jahren regelm ig m Leaders Quadrant als ein f hrendes Werkzeug zur Modellierung und Verwaltung von Prozess modellen Der Schwerpunkt liegt auf der betriebswirtschaftlichen Modellierung auch wenn der Name ARIS der f r Architektur integrierter Informationssysteme steht einen starken IT Bezug vermuten l sst Oracle verf gt mit der Fusion Middleware insbesondere mit dem integrierten BPEL Pro cess Manager ber leistungsf hige Werkzeuge zur Orchestrierung und Ausf hrung von Web Services und automatisierten Prozessen im SOA Umfeld 97 4 Die Umsetzung des Metamodells 4 3 Die ARIS Werkzeuge sind primar im fachlichen Business Process Management angesiedelt die BPM Werkzeuge der Oracle Fusion Middleware primar im tech nischen BPM Beide Herst
376. tellt bis hin zu einem Maskendesign variieren abh ngig von den konkreten Anforderungen der sp teren Systembenutzer aus dem Fach bereich In unserem Beispiel haben diese eine sehr genaue Vorstellung des Maskenlayouts so dass wir uns f r den Modelltyp Maskendesign entschieden haben Der Zusammenhang zu den in der Maske dargestellten und bearbeiteten Daten wird im Maskendesign ebenfalls klar Im Attribut Beschreibung Definition haben wir dabei beschrieben welche Aktio nen der Benutzer auf der Maske ausf hren kann Bestellung suchen siehe Abbildung 6 16 Beschreibung Definition Die Maske dient der Suche nach im System vorhandenen Bestellungen anhand definierter Suchkriterien Lieferantennummer Bestellnummer Bestelldatum Bruttobetrag Dabei kann eine beliebige Zahl an Feldern ausgefullt werden Alle Bestel lungen die allen ausgefullten Suchkriterien entsprechen werden nach Betatigung der Schaltflache Bestellungen anzeigen angezeigt Wenn kein einziges Suchkriterium angegeben wird werden alle Bestellungen im System angezeigt Durch Betatigung der hinter jeder gefundenen Bestel lung angezeigten Schaltfl che Bestellung anzeigen wird die entsprechen de Bestellung in einer neuen Maske ge ffnet Lieferantennum mer Bestellnumm a Bestellnummer 54321 er E Bestetan mums Bruttob etra g Sn Status Bestellnummer Lieferantennummer Lieferanten Name oa W hrung
377. ter geschlossen haben zeigt Ihnen Excel eine Liste m gl cher Beziehungstypen zwischen den gew hlten Symboltypen an Abbildung 4 12 zeigt die zugeh rigen Beziehungstypen der selektierten Diagramm und Symboltypen der gew hlten Beispielkombination Zugriffsdiagramm Typ Betriebssystem Typ DBMS Typ HW Komponente Untersuchen Sie anschlie end ob die verf gbaren Beziehungstypen die gew nschte Se mantik der Beziehung aus dem Metamodell ausdr cken Im vorliegenden Beispiel muss die Beziehung Softwareressource nutzt Hardwareressource abgebildet werden Die Oracle F r die gew hlte Kombination aus Modelltyp und Symboltyp zul ssiger Beziehungstyp ar Ui 2n TE ay aT yo er D aaya eT a ee ur ar ord ee Typ Cees Tyn Hr m ee ake at 4138 Abbildung 4 12 Identifizierung passender Beziehungstypen in der Excel Analysedatei 71 4 Die Umsetzung des Metamodells 72 BPA Suite erm glicht f r die gew hlte Diagrammtyp Symboltyp Kombination die Bezie hung Typ DBMS kann laufen auf Typ Hardwarekomponente bzw Typ Betriebssystem kann laufen auf Typ Hardwarekomponente Beide entsprechen semantisch der gew nsch ten Aussage und k nnen verwendet werden Sollten Sie keinen passenden Beziehungstyp finden so untersuchen Sie zun chst die ande ren Diagrammtypen in denen die betrachten Symboltypen gemeinsam auftreten auf se mantisch passende Beziehungstypen Alternative 1 in Abbildung 4 7 Sollten auch dort keine passenden B
378. tet aus Kern und Hauptprozessen 101 5 Das Grundmodell 102 Nachdem Sie die Organisationseinheiten bestimmt haben ist die Dekomposition der Orga nisationsbibliothek abgeschlossen Sie k nnen jetzt eine Erg nzung um Stellen und Perso nen hinzuf gen die jedoch keine weitere Dekomposition sondern lediglich eine Detaillie rung darstellt Ordnen Sie jeder Organisationseinheit eine leitende Stelle zu Die Anzahl ausf hrender Stellen je Organisationseinheit kann wie in Abbildung 5 9 gezeigt zwischen 1 und 5 vari ieren Jeder Stelle k nnen Personen zugeordnet werden welche diese besetzten Dieser letzte Schritt st nicht immer m glich da es ggf rechtliche Einschr nkungen bei der Mo dellierung personenbezogener Daten innerhalb eines integrierten Gesamtmodells geben kann Beachten Sie an diesem Punkt bitte die individuelle Situation in Ihrem Unternehmen Abbildung 5 12 zeigt f r unser Beispiel Wareneingang ein erstelltes Organigramm Vertrieb Produkt entwicklung Material und Bestellverwaltung Leiter Wareneingang Peter M ller Beschaffung Materiallogistik Michael Meier Auftrags abwicklung Dieter Marx Service Muster AG Wareneingangskontrolleur J rg Vogel Unternehmens entwicklung Finanz und Rechnungswesen Marketing Personal management Controlling Abbildung 5 12 Angepasstes Organigramm inklusive Stellen und Personen S e erkennen an diesem Beispiel dass eine prozessorientiert
379. ti ge Version verabschieden Aufgrund von Erfahrungen empfehlen wir den Wert einer guten und stabilen Prozesslandkarte nicht zu untersch tzen S e ist Ausgangspunkt diverser Detaillierungen des Modells insbesondere f r die Prozessautomatisierung oder IT System konzeption Mit Hilfe einer gut durchdachten und stabilisierten Prozesslandkarte werden bereits in dieser fr hen Phase viele Probleme der Modellierung in sp teren Phasen vermie den oder bei schlechter Umsetzung erst geschaffen Abbildung 5 2 zeigt eine vereinfachte Prozesslandkarte die mit Hilfe dieses Vorgehens er stellt wurde inklusive der Unterteilung in prim re und sekund re Gesch ftsprozesse l Produkt Auftrags entwicklung abwicklung Beschaffung entwicklung management Rechnungswesen Marketing Controlling Abbildung 5 2 Abbildung einer exemplarischen Prozesslandkarte prim re Gesch ftsprozesse sekund re Gesch ftsprozesse l Prim re Gesch ftsprozesse dienen der origin ren Wertsch pfung im Unternehmen Sekund re Ge sch ftsprozesse stellen Unterst tzungsleistungen f r prim re Gesch ftsprozesse bereit und sind damit nur indirekt an der Wertsch pfung beteiligt 85 5 Das Grundmodell 86 Wichtig ist dass Sie bereits auf der Prozesslandkarte auf eine moglichst gleiche Granularitat der beschriebenen Prozesse achten Bestimmen Sie fur jeden Pro zess der Prozesslandkarte die zugeh rige Instanz und berpr fen Sie ob alle ermittelten Insta
380. tigen Prozessmodelle ohnehin verstehen da die Prozessbeteiligten die Inhalte nach der Modellierung als fachlich korrekt freigeben m ssen Prozesse sollten Sie im Rahmen von Prozessworkshops in Kleingruppen von 2 bis 4 Personen aus unterschiedlichen Hierarchieebenen der Fachabteilung auf nehmen Existierende Prozessdokumentationen Mit bereits existierenden Prozessdokumentationen sind in diesem Fall nat rlich keine Pro zessmodelle in der Form gemeint wie sie gerade aufgenommen werden sollen sondern bestehende Prozessaufzeichnungen die in beliebiger Form zu beliebigen Zwecken zu ei nem fr heren Zeitpunkt einmal erstellt wurden In aller Regel wird das urspr ngliche Ziel nicht darin bestanden haben die Grundlage einer Fachkonzeption darzustellen Daher wird die dargestellte S cht und die dar n abgebildeten Informationen von dem was Sie nun dar stellen m chten abweichen Dar ber hinaus k nnen s ch Prozesse ber die Zeit ver ndern 6 3 Die IT Sicht und ihr Zusammenhang mit der Fachsicht so dass Sie abh ngig vom Alter der Dokumentationen und der Art ihrer Pflege ber die Zeit davon ausgehen m ssen dass die dargestellten Prozesse ggf nicht mehr aktuell sind Solche Dokumentationen lassen sich zwar f r den ersten Entwurf eines Prozessmodells verwenden werden in der Regel aber immer Fragen an die Fachabteilung offen lassen so dass s ch ein entsprechender erster Entwurf als Diskussionsgrundlage f r einen Prozess workshop
381. tivit tsobjekt Das Aktivit tsobjekt beschreibt dynamische Vorg nge im Detail Beziehungsobjekt zwischen Das Beziehungsobjekt beschreibt die Beziehung den Aktivit tsobjekten zwischen den Aktivit tsobjekten Die Beziehungen stellen eine Vorg nger Nachfolger Beziehung dar Abgrenzung Granularit t Alle Aktivit ten auf den erstellten Diagrammen m ssen zur vollst ndigen Bearbeitung der auf den Diagrammen des bergeordneten Unterprozesses erforderlich sein ausgepr gten Objekte Die modellierten Aktivit ten beziehen sich direkt auf die ihnen bergeordnete Prozess instanz Maximal 20 40 Aktivit ten pro Unterprozess 5 2 5 Die statischen Objektbibliotheken des Grundmodells 5 2 5 1 Erstellung der Organisationsbibliothek Ziel der Organisationsbibliothek ist es alle f r die Modellerstellung relevanten organisato rischen Objekte in strukturierter Form zu erfassen Wir verstehen darunter das hierarchi sche Ger st einer Organisation Es beschreibt im Wesentlichen die ber und Unterstel lungsstrukturen innerhalb der betrachteten Organisation Abbildung 5 9 zeigt die empfoh lene Struktur zum Aufbau des Organisationsmodellbereichs Ausgangspunkt zur Modellierung der Aufbauorganisation ist ein zentrales Objekt welches die betrachtete Organisation als Ganzes darstellt In Abbildung 5 9 finden Sie diesen Aus gangspunkt in der linken oberen Matrixecke bezeichnet als Unternehmen Geschaftsbe reich Betrachten Sie dieses ze
382. tsartefakte der Prozessarchitektur 5 2 1 1 Die Instanzgranularit t als Kriterium zur vertikalen Dekomposition Haben Sie schon einmal versucht Prozessinhalte hierarchisch zu strukturieren Wenn ja ist Ihnen sicher aufgefallen dass es sich dabei um keine leichte Aufgabe handelt Grund daf r st dass die Prozessbeschreibung stark von der Semantik abh ngt und daher ver schiedene Personen Prozessgranularit t schnell unterschiedlich interpretieren Um die eindeutige und weitgehend unmissverst ndliche Zuordnung von Prozessen und Aktivit ten in einer hierarchischen Struktur zu erm glichen ben tigen wir ein Unterscheidungsmerk mal welches neben der ber und Unterordnung die Identifizierung gleichartig detaillier ter Inhalte erm glicht Dabei sollen so weit wie m glich individuelle Interpretationen aus geschlossen werden Dieses Unterscheidungsmerkmal ist die Instanzgranular t t Unter der Instanzgranularitat verstehen wir ein Ma f r den Detaillierungsgrad eines Prozesses oder einer Aktivit t Es handelt sich dabei aber nicht um eine eindeutig quantifizierbare Messgr e sondern um ein qualitatives Ma zur Orientierung Die Prozessinstanz betrachtet den eindeutig durch einen Start und Endpunkt gekennzeichneten Durchlauf eines Prozesses Dabei umfasst sie alle Aktivit ten die zur vollst ndigen Bearbeitung einer Instanz des Prozesses erforderlich sind Eine Prozessinstanz ist in der Regel eindeutig durch die Bearbeitung eines
383. tsymbol typ kann verwendet werden bei Attributtyp Symbol 2 Instanz gt Kanten verbinden Symbole Instanz auf Diagrammen Instanz Attributsymboltypen 4 Die individuelle Erweiterung der Attributtypen existiert erst ab der Oracle BPA Suite Version 11g bzw ARIS 7 1 Fr here Versionen der Werkzeuge waren noch auf fest vorgegebene Freie Attribute be schr nkt und konnten nicht in der beschriebenen Form erweitert werden 61 4 Die Umsetzung des Metamodells 4 4 Innerhalb der Oracle BPA Suite ist die Modellierungsmethode in einem geschlos senen Metamodell abgebildet Als Benutzer des Werkzeugs k nnen Sie nur sehr eingeschr nkte individuelle Erweiterungen vornehmen Die zur Verf gung gestell ten Anpassungsm glichkeiten stellen keine Erweiterung im eigentlichen Sinn dar sondern sind bis auf die Erweiterung von Attributtypen ausschlie lich Kopien be stehender Methodeninhalte Diese Kopien erben alle Restriktionen der Quellen und k nnen in ihrer Nutzung im Modell eingeschr nkt aber nicht erweitert werden Aus diesem Grund empfehlen wir Anpassungen nur in begrenztem Umfang und nach genauer Pr fung der methodischen Auswirkungen vorzunehmen Analyse der Oracle BPA Suite Methode 62 W hrend des Entwurfs des werkzeugneutralen Metamodells wurden die methodischen Beschr nkungen von uns bewusst nicht ber cksichtigt In den meisten F llen ist davon auszugehen dass Sie Ihr individuelles Metamodell
384. tung Mitarbeiter Warenannahme Personentyp wird repr sentiert durch Bestellung Make hat Input Menge Fachbegriff Artikelnummer Fachbegriff 144 Teillieferung identifizieren Beschreibung Definition folgt auf f hrt zu steht unter DV Verantwortung von wird repr sentiert durch hat Input hat Output 6 5 Erstellung eines Fachkonzepts mit der Oracle BPA Suite Wird zu einem Artikel eine kleinere Liefermenge eingegeben als die Bestellmenge ffnet sich eine neue Maske auf der der Grund f r die Abweichung angegeben werden muss Dabei muss der Benutzer diesen Grund den Warenbegleitpapieren entnehmen auf denen der Lieferant weitere Informationen zu Lieferung und Liefer schein angeben kann Auf Basis dieser Informationen muss der Benutzer entscheiden ob es sich um eine Teillieferung handelt oder ob tats chlich eine falsche Menge geliefert worden ist Liefermenge eingeben Mitarbeiter Warenannahme Personentyp Anmerkung zur Lieferung Fachbegriff Artikel als Teillieferung markieren Beschreibung Definition wird aktiviert durch f hrt zu steht unter DV Verantwortung von wird repr sentiert durch hat Input hat Output Artikel als falsch markieren Beschreibung Definition wird aktiviert durch f hrt zu Ist die Liefermenge Kleiner als die Bestellmenge da es sich bei der Lieferung nur um eine Teillieferung handelt so wird dieser Fall auf der Maske angew hlt und die Information zur entspre
385. tung ben tigt und erzeugt Im ersten Schritt stellen w r den Zusam menhang zwischen den Gesch ftsobjekten und den Daten her die in den Gesch ftsobjek ten enthalten sind Dazu erstellen wir mit der Oracle BPA Suite ein Fachbegriffsmodell in dem wir auf der linken Seite die Gesch ftsobjekte der Fachsicht anordnen und auf der rechten die Daten der IT Sicht ber die Kante umfasst wird deutlich gemacht welche Daten n welchen Gesch ftsobjekten enthalten sind Die Gesch ftsobjekte und Daten wer den ferner im Attribut Beschreibung Definition kurz beschrieben Eine bersicht ber die im Modell dargestellten Objekte und deren Beschreibung l sst sich so automatisch aus der Oracle BPA Suite generieren Vom Objekttyp her sind alle Gesch ftsobjekte n unse rem Beispiel Fachbegriffe was sinnvoll ist weil die IT Gesch ftsobjekte normalerweise in den fachlichen Gesch ftsobjekten enthalten sind und lediglich eine Detaillierung darstel len So stellt das IT Gesch ftsobjekt Artikelnummer grunds tzlich auch eine fachliche Information dar die einer Material Bestellung oder einem Lieferschein auch ohne IT Unter st tzung entnommen werden kann Lediglich der Detaillierungsgrad erlaubt eine direkte Abbildung als ein Datum in einem System Zur Unterscheidung zwischen fachlichen und IT Gesch ftsobjekten im Modell aus Abbildung 6 15 sind die fachlichen Gesch ftsobjekte als wei e K stchen dargestellt 6 5 Erstellung eines Fachkonze
386. tzten Services spricht man wenn der Service zur Erstellung seiner Leistung andere Ser vices verwendet Diese Unterscheidung ist f r einen Serviceanbieter deswegen wichtig weil der zusammengesetzte Service von den genutzten Services abh ngig ist Eine nde rung an den verwendeten Services wirkt s ch also d rekt auf den zusammengesetzten Ser vice aus 7 2 4 Was ist eine SOA Services bieten dem Konsumenten einen Nutzen In diesem Abschnitt wird beschrieben wie Services nutzbar gemacht werden Dies verbirgt sich hinter den drei prominenten Buchstaben SOA Die unserer Ansicht nach beste Definition von SOA stammt von OASIS Organization for the Advancement of Structured Information Standards welche es sich unter anderem zur Aufgabe gemacht hat die Begriffswelt rund um SOA zu standardisieren Service Oriented Architecture SOA is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains Oasi06 Die OASIS Definition ist frei von IT Es gibt keinen Zwang Services in der IT realisieren zu m ssen Dementsprechend ist es auch m glich eine rein fachliche SOA zu erstellen In der Praxis haben wir diese Bestrebung jedoch noch nicht sehen k nnen Oft wird sogar nicht nur eine SOA angestrebt sondern direkt das aufbauende Konzept der Prozessautoma tisierung ins Visier genommen An die Frage Was ist SOA schlie t sich meist direkt die Frage Wie funktionier
387. ufgef hrt werden Hierzu z hlen wir unter anderem PPS und Buchhaltungssysteme Abbildung 5 16 zeigt eine m gliche Unterteilung Ihrer Anwendungssystemlandschaft Anwendungssysteme Administrative und Management Systeme Operative Systeme Querschnitts Domainspezifische Zwischen F hrungs Planungs systeme Systeme betriebliche Informations systeme Systeme Systeme Anwendungs Anw Anwendungs Anw Anwendungs Anw Anwendungs Anw Anwendungs Anw system Typ System system Typ System system Typ System system Typ System system Typ System Abbildung 5 16 Vorschlag zur Unterteilung der Anwendungssystemlandschaft Wir unterscheiden dabei zun chst administrative und operative Systeme von den Manage ment Systemen Stehen die Ersteren in einer direkten Beziehung zu den wertsch pfenden Prozessen und den zur Aufrechterhaltung des operativen Betriebs erforderlichen sekund ren Prozessen so dienen die Management Systeme der Planung und Fuhrungsinformation Die Beschreibung eines Systems innerhalb Ihres Modells kann dar ber hinaus entweder typisiert oder als Instanz erfolgen Typisiert bedeutet dass Sie nur die abstrakten Einheiten eines Systems beschreiben Zum Beispiel das Vorhandensein von Oracle Applications als ERP System ohne auf eventuell vorhandene Mandanten des Systems einzugehen Die Instanzmodellierung geht ber die abstrakte Beschreibung hinaus und identifiziert jedes vorhandene Oracle Applications System mit Lizenznummer
388. uite Meth de satin en acl E Macuiaiaieitias 62 Vorgehensweise zur Ermittlung Ihrer individuellen Oracle BPA Suite Methode 66 Analyse und Bewertung der semantischen Abdeckung uessssssssssssnnnnnnnnnnnnnn 76 Das Grundmodell n ie 79 Fragen die dieses Kapitel beantwortet 2 22 22 lie E 79 Aufbau des Grundmodels ze 2223245 432 02 B 0 Me else 79 5 2 1 Ermittlung der bersichtsartefakte der Prozessarchitektur ueeeeeenn 80 5 2 2 Modellierung dynamischer Inhalte in der Oracle BPA Suite eeen 83 5 2 3 Die Instanzgranularitaten 1 bis 3 im Zusammenhang eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeennn 95 5 2 4 IT neutrale Detaillierung der Prozesse und ihrer Aktivit ten ueennneneen 96 5 2 5 Die statischen Objektbibliotheken des Grundmodells 99 5 2 6 Aufbau der Grundstruktur eines integrierten Modells in der Oracle BPA Suite 111 Modellgest tzte fachliche Konzeption individueller IT Systeme 117 Fragen die dieses Kapitel beantwortet eesssssssssssssnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 117 Die Bedeutung fachlicher Anforderungen uusssssssssssssnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 117 Die IT Sicht und ihr Zusammenhang mit der Fachsicht sssssssssssssesennennnnnnn 121 6 3 1 Modellierung und Analyse der Ist Prozesse uueeeeeeeeeeeeeeeeseeneeesenene
389. umzusetzende Metamodell Entitat e OK Ahbrerfiee 27 An Hardwareressource 28 Ante Organisabonseint __ 29 Anfonderungszuordnungsdiagramm Person exten Person 30 Anforderungszuordnungsdiagramm Person mtem Person 31 Anforderungszuordnungsdiagramm Risko Risk 32 Anfordenmaszuordnunasd aaramm Risk Risk F Hoa di goenean CSRS TUT eee Sym Oey pan Uiecia th Curae Hmenagyngen Berehumet pen b Abbildung 4 9 Einschr nkung der angezeigten Methodeninhalte mittels Excel Filer der Entit t Softwareressource prim r Software beschreiben die nicht direkt an der operati ven Prozessausf hrung beteiligt ist sondern unterst tzend im Hintergrund genutzt wird Dies k nnen zum Beispiel Betriebssysteme Datenbanken Servicebus und Webserver sein F r die Betriebssysteme und Datenbanken DBMS finden wir in der Methode passende Symboltypen Servicebus und Webserver k nnen nicht mit bestehenden Symboltypen ab gebildet werden Welche Auswirkungen sich dadurch ergeben sehen wir bei der Bewer tung der methodischen Abdeckung Sie erkennen an diesem Beispiel aber bereits sehr gut dass Sie bei der Umsetzung eines individuellen Metamodells in die Oracle BPA Suite Kompromisse bzgl der eingesetzten Symboltypen eingehen m ssen Die Oracle BPA Suite Methode erm glich in der Regel keine Eins zu eins Um setzung eines individuellen Metamodells Durch das geschlossene Metamodell der Oracle BPA Suite m ssen Sie Kompromisse in der Abbildung von Inhalten eingehen Mitunt
390. un gen der jeweiligen Organisationseinheiten und Stellen erganzt Geschaftsobjekte Der BPM Modellteil enthalt zusatzlich fachliche Datenbeschreibungen welche die ermit telten Geschaftsobjekte aus Sicht der Informationstechnologie konkretisieren Fachliche Datenobjekte beschreiben damit Geschaftsobjekte die zukunftig von IT Systemen verar beitet werden sollen genauer Anwendungssysteme und Infrastrukturen Der BPM Modellteil enth lt keine Inhalte zu Anwendungssystemen fachlichen oder tech nischen Services oder Infrastrukturen 2 3 2 4 Detaillierung des SOA Modellbereichs Gesch ftsprozesse Die Prozessmodellierung im SOA Modellteil befasst sich haupts chlich mit automatisier ten Prozessen und den darin enthaltenen technischen Funktionen Wie beim BPM ist auch im SOA Umfeld strittig bis zu welchem fachlichen Niveau ein Prozess und dessen Funk tionen beschrieben werden m ssen Dabe n hert man sich dieser Frage im Vergleich zum BPM aus der entgegengesetzten Richtung Wie weit die Modellierung auch fachliche Pro zesse beinhaltet hat sich in der Praxis noch nicht allgemeinverbindlich etabliert Allge mein anerkannt ist dass technische Prozesse Bestandteil des SOA Modellteils sein m s sen Wir beschr nken uns beim fachlichen SOA Modellbereich auf die Modellierung tech nischer Prozesse zur Automatisierung Organisationsstrukturen Die Modellierung organisatorischer Inhalte im SOA Modellteil beschr nkt sich auf die zur Im
391. und IT Abteilungen in Projekten erforderlich ist E Management Kommunikation der aus der Unternehmensstrategie abgeleiteten IT Strategie Bewerten und Priorisieren von IT Projekten Abnahme und Freigabe der Projektauftr ge inkl Projektbudget und Zeitplan berwachung der Projekte und Eingriff bei Unklarheiten im Rahmen eines Len kungsausschusses Abschlie ende Bewertung der Projekte f r die Unternehmung und Entlastung des Projektteams Business Analyst Ermittlung und Detaillierung der fachlichen Anforderungen eines Projektes Analyse der Auswirkungen des Projektes auf die IT Strategie Definition der zu realisierenden IT Unterst tzung aus fachlicher Sicht Fachkon zept Test und Abnahme der entwickelten L sung ggf auch Teill sungen hinsichtlich fachlicher Vollst ndig und Richtigkeit 2 2 Management Fachbereiche und IT jeder ist anders E Technische IT berf hrung der fachlichen Anforderungen in eine technische Konzeption DV Konzept Verifizierung der technischen Umsetzbarkeit und ggf Kommunikation m glicher Risiken Selbstverst ndlich sind diese Rollen 1m Unternehmen noch f r eine Vielzahl anderer Auf gaben zust ndig die genannten Aktivit ten beschreiben aber die wesentlichen T tigkeiten die eine Kommunikation mit den anderen Rollen erfordern Dabei kommt es auch heute immer noch zu Problemen Ausl ser sind verschiedene Sichtweisen und Sprachen der beteiligten Personen Seit e
392. ung 9 18 Modellierung des Prozesses zum Process Monitoring Monitoring WEK Bei der Analyse und Behebung der Eskalation bernimmt das IT System eine unterst t zende Funktion Die wesentliche Leistung erfolgt durch den Prozessverantwortlichen f r die Instanz Wir beschreiben das eigentliche Eskalationsmanagement bewusst nicht aus f hrlicher da es sehr komplex ist und individuell deutlich unterschiedliche Auspr gungen im Detail besitzt Tabelle 9 10 Benutzte Methodenobjekte der Oracle BPA Suite Modellname Process Monitoring Problemidentifikation Monitoring Diagrammtyp Wertsch pfungskettendiagramm WKD EPK Symbole Ereignis Funktion Typ Anwendungssystem Fachbegriff Kennzahlinstanz Personentyp Prozessschnittstelle 248 9 7 Modellierung des Prozess Controlling mit der Oracle BPA Suite 9 7 2 2 Modellierung des Process Mining Losgel st von dem eher operativen Prozess des Monitorings der laufenden Prozessinstan zen des WEK ben tigen wir nun den Prozess Process Mining mit dem Arbeitsauftrag Analyse des WEK Hierdurch unterst tzen wir die geschilderte Initiative B Analyse des WEK zur Erkennung von Optimierungspotenzial Process Mining Wertsch pfungskettendiagramm Process Mining Analyse WEK Analyse WEK EPK Analyse WE notwendig Prozessdaten WEK potenzial nen identifizieren nalysen PDauer pro Lieferant PDauer pro Produkttyp PDauer gesamt Abbild
393. ung 9 19 Modellierung des Prozesses zum Process Mining Analyse WEK Bei der Modellierung nutzen wir nun die bereits bestehenden statischen Elemente So flie Ben in diesem Falle die unterschiedlichen Daten Abh ngig von den zu betrachtenden D1 mensionen ein Dies erkennt man in der Abbildung 9 19 wo ein Input in den Prozess flie t und der Output die multidimensionalen Analysen als eigentliche Leistung des Pro zesses festgehalten wird Die Kennzahlen sind nun ex post nach Beendigung der einzel nen Prozessinstanzen und dienen zur Analyse und Aufdeckung eines m glichen Verbesse rungspotenzials 249 9 Entwurf und Aufbau prozessgetriebener Kennzahlensysteme Tabelle 9 11 Benutzte Methodenobjekte der Oracle BPA Suite Modellname Process Mining Analyse WEK Diagrammtyp Wertschopfungskettendiagramm WKD EPK Symbole Ereignis Funktion Typ Anwendungssystem Fachbegriff Kennzahlinstanz Personentyp Prozessschnittstelle 9 7 2 3 Modellierung des Process Benchmarking Losgel st vom operativen Prozess des Process Monitoring und der analytischen Arbeit beim Process Mining benotigen wir einen Prozess fur den Benchmark des Status des WEK hinsichtlich der gesamten durchschnittlichen Durchlaufzeit Dieser Prozess unterst tzt den Erfolgsfaktor C Dashboard f r einen Benchmark f r die Verbesserung beim WEK Process Benchmarking Wertsch pfungskettendiagramm Process Benchmarking Benchmark WEK it Benchmark WEK
394. ung und IT Spezifikation service orientierter Prozesse aus E Welche Zielgruppen welchen Informationsbedarf und welche Ebenen hat eine prozess basierte SOA Modellierung E Wie kann die serviceorientierte Prozessmodellierung in der Oracle BPA Suite umge setzt werden 8 2 BPM SOA Teamwork in der Prozessautomatisierung 8 2 1 Fachliche SOA Ansatze Autobahn oder Sackgasse Das Thema serviceorientierte Architekturen SOA ist seit einigen Jahren allgegenwartig Viel diskutiert entwickelte es sich zun chst zu einem regelrechten Hype bevor dann eine gewisse Ern chterung aufkam Anwender und SOA willige Unternehmen mussten feststellen dass es alles andere als trivial ist eine serviceorientierte Architektur zielf hrend aufzubauen Au erdem waren die Versprechungen vieler Softwarehersteller die mit hren SOA Infrastruktur L sungen um die Gunst der Kunden werben oftmals nicht einzuhalten oder aber nur mit hohem Zusatzaufwand umzusetzen Die bestehenden und auf dem Markt erh ltlichen Infrastrukturl sungen decken mittlerweile die Anforderungen an eine techni 191 8 Der prozessgetriebene SOA Ansatz 192 sche Implementierung einer SOA beispielsweise auf der Basis von Web Services WS Standards recht umfangreich ab Bei methodischen Vorgehensweisen wie beispielswei se der Frage worin die wirklichen fachlichen Dienste im Unternehmen bestehen oder wie man anwendbare Konzepte fur die Implementierung fachlicher P
395. ungen umfassendere Informationsbasis f r Auswertungen kurzfristiger Zeitvorteil bei der initialen Erstellung keine Notwendigkeit methodische Kompromisse in der Modellstruk tur einzugehen Initial erh hter Strukturierungs und Erstellungsaufwand Abstimmung zwischen allen beteilig ten Organisationsbereichen w hrend der Modellerstellung erforderlich Einschr nkungen beim abbildbaren Inhalt im integrierten Modell nicht vollst ndig vermeidbar langfristig erh hter Pflegeaufwand durch redundante Modellinhalte unzureichende Wiederverwertbarkeit durch fehlende Integration der Inhal te bergreifende Analysen und Weiter verwendung nahezu unm glich 2 2 Management Fachbereiche und IT jeder ist anders Zum erfolgreichen Aufbau eines integrierten Modells m ssen Sie demnach WE einen f r alle Beteiligten tragbaren Kompromiss bei den abbildbaren Inhalten erreichen WE den initialen Strukturierungs und Erstellungsaufwand minimieren Bei beiden Punkten hilft Ihnen das vorliegende Buch Wir zeigen Ihnen wie Sie schnell und einfach den Einstieg in ein integriertes EA BPM und fachliches SOA Modell finden 2 2 1 Inhalte f r die Enterprise Architecture Modellierung Das Konzept eine Organisation mit Hilfe einer Enterprise Architecture zu beschreiben ist nicht neu Bereits in den achtziger Jahren wurden die grundlegenden Konzepte eines En terprise Architecture Management unter anderem von John Zachman definiert
396. ungen w hlen Beschreibung Gibt optional folgende Informationen aus el Modelitypen Modellattributtypen Symboltypen Objektattributtypen Hinterlegungen Kantentypen Kantenattributtypen Die Ausgabe erfolgt als Tabelle El Weiter Abbrechen Hilfe Abbildung 4 3 Auswahl des Reports Filterinformationen ausgeben Der n chste Bildschirm des Assistenten fordert Sie unter anderem auf das gew nschte Ausgabeformat anzugeben Abbildung 4 4 Als Ausgabeformat f r den Report w hlen Sie 63 4 Die Umsetzung des Metamodells 64 fe Report Assistent i Schritte Hilfe 2 Ausgabeeinstellungen w hlen 1 Report w hlen Sprache Deutsch Deutschland 2 Ausgabeeinstellungen w hlen Auswertungsfilter Kein Auswertungsfilter Ausgabeformat Microsoft Excel XLS Ausgabe speichern unter ienidstiDesktop OCracle BPA Suite Gesamtmethode 119 090227 xls Y Ergebnis anzeigen Zur ck Eertig stellen Abbrechen l Hilfe Abbildung 4 4 Auswahl des Auswertungsformats Speicherpfads und Dateinamens Microsoft Excel XLS Damit erzeugen Sie eine Excel Datei die eine schnelle und komfortable Analyse der Inhalte erm glicht Des Weiteren m ssen Sie einen Ablageort f r die zu erstellende Excel Datei angeben Alle anderen Einstellungen lassen Sie unver ndert Legen Sie einen separaten Ordner ausschlie lich f r die Konfiguration und Ana lyse der Oracle BPA Suite
397. ungstypen legen fest welche Beziehungen zwischen Symboltypen auf welchen Diagrammtypen zul ssig sind E Beziehungsattributtypen beschreiben welche Standardattribute zu Beziehungstypen vorhanden sind Diese Excel Liste dient als Ausgangspunkt f r den Entwurf Ihrer individuellen Oracle BPA Suite Methodik innerhalb eines integrierten Modells Aktivieren S e zur einfachen Ver 5 Weiterf hrende Informationen ber die Sichten des ARIS Konzepts finden Sie im Methodenhandbuch der Oracle BPA Suite 65 4 Die Umsetzung des Metamodells 4 5 Joch on ww oo a 5 i i i i ee ee ee ee ee nli ie a l j h tn d Go hs P m A D Modelltyp Symboltyp Anforderungsbaum Anforderung Anforderungsbaum Strategisches Zie Anforderungsbaum Ziel Anfarderungszuordnungsdiagramm Anforderung meere Anforderungszuordnungsdiagramm Anwendungssystem Anwendungssystem Anforderungszuordnungsdiagramm Cluster Cluster Datenmode Anforderungszuordnungsdiagramm Componen Component Anforderungszuordnungsdiagramm Fachbegriff Fachbegriff Anfarderungszuordnungsdiagramm Funktion Funktion Anforderungszuordnungsdiagramm Fahiakeit Fahiakeit Anforderungszuordnungsdiagramm Geschattsservice Servicetyp Anforderungszuordnungsdiagramm Gruppe a Ant mr mr j rs IN men on u Pi Anforderungszuordnungsdiagramm H V Komponente Arbeitsbl tter f r die Anforderungszuordnungsdiagramm Kennza
398. uriert d h sie werden ausgehend von einer abstrakten Beschreibung zunehmend detaillierter Dies gilt f r alle oben genannten Artefakttypen wird hier aber besonders am Beispiel von Prozess modellen erl utert Stellen Sie sich dazu nochmals den oben erw hnten Wareneingangs prozess vor Eine vertikale Detaillierung dieses Prozesses f hrt zum Beispiel zur weiteren Unterteilung des Prozesses Wareneingang in die Unterprozesse Wareneingangskontrol le Warenverbuchung und Wareneinlagerung Abbildung 2 5 zeigt die Zusammen h nge Wareneingang vertikale Detaillierung Waren einlagerung Wareneingangs kontrolle Warenbuchung Abbildung 2 5 Beispiel einer vertikalen Detaillierung des Prozesses Wareneingang Neben dieser in die Tiefe gerichteten Strukturierung werden Prozessmodelle weiterhin horizontal unterteilt Dabei handelt es sich um eine Abgrenzung der beschriebenen Inhalte gegeneinander Meistens erfolgt die Trennung der Inhalte anhand besonderer Gruppie rungskriterien wie zum Beispiel nach fachlich unterschiedlichen Bereichen Um bei dem Beispiel zu bleiben so kann der Wareneingangsprozess von anderen horizontalen Pro zessen wie Materialeinkauf oder Kreditorenbuchhaltung horizontal abgegrenzt werden s Abbildung 2 6 29 2 Integrierte Modellierung fur EA BPM und fachliche SOA Die horizontale Abgrenzung der Inhalte im integrierten Modell ist von besonde
399. us der Benutzung dieser Informationen oder Teilen davon entsteht Ebenso bernehmen Autoren und Verlag keine Gew hr daf r dass beschriebene Verfahren usw frei von Schutzrechten Dritter sind Die Wiedergabe von Gebrauchsnamen Handelsnamen Warenbe zeichnungen usw in diesem Buch berechtigt deshalb auch ohne besondere Kennzeichnung nicht zu der Annahme dass solche Namen im Sinne der Warenzeichen und Markenschutz Gesetzgebung als frei zu betrachten w ren und daher von jedermann benutzt werden d rften Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie detaillierte bibliografische Daten sind im Internet ber http dnb d nb de abrufbar Dieses Werk ist urheberrechtlich gesch tzt Alle Rechte auch die der bersetzung des Nachdruckes und der Vervielf ltigung des Buches oder Teilen daraus vorbehalten Kein Teil des Werkes darf ohne schriftliche Genehmigung des Verlages in irgendeiner Form Fotokopie Mikrofilm oder ein anderes Verfahren auch nicht f r Zwecke der Unterrichtsgestaltung reproduziert oder unter Verwendung elektronischer Systeme verarbeitet ver vielfaltigt oder verbreitet werden 2009 Carl Hanser Verlag M nchen www hanser de Lektorat Margarete Metzger Herstellung Irene Weilhart Umschlagdesign Marc M ller Bremer www rebranding de M nchen Umschlagrealisation Stephan R nigk Date
400. ute ausreichend Keine weiteren Entit t Beziehung Entit t Gruppen vorhanden y Festlegung Individuelle Abbildung ber Methoden erforderlicher anpassung pr fen Diagrammattribute nur wenn unbedingt erforderlich Abbildung 4 7 Vorgehensweise zur Durchf hrung einer BPA Suite Methoden anpassung Ende 67 4 Die Umsetzung des Metamodells 68 Der in Abbildung 4 7 dargestellte Ablauf hat sich als pragmatisches Vorgehen fur den Ab gleich zwischen einem individuellen und dem geschlossenen Metamodell der Oracle BPA Suite bewahrt Auswahl der Entitat Beziehung Entitat Gruppe Zun chst legen Sie einen Ausgangspunkt innerhalb Ihres individuellen Metamodells fest Dazu w hlen Sie die umzusetzende Entit t Beziehung Entit t Gruppe Abbildung 4 8 zeigt das erstellte individuelle Metamodell und die exemplarisch ausgew hlte Gruppe Softwareressource nutzt Hardwareressource ist zusammengesetzt aus 7 gt befindet sich an Standort ist zugeordnet zu Organisations Person d S einheit gt ist Vorganger von gt nip ist verantwortlich fur greift zu auf bearbeitet unterst tzt Anwendungs bearbeitet Gesch fts Prozess gt e gt lt system objekt l uft auf Ausgew hlte Entit t Beziehung Entit t Gruppe ist zusammengesetzt aus Software nutzt Hardware ressource
401. verwenden l sst um die Arbeit ein wenig zu steuern und insofern zu beschleu nigen An dieser Stelle sei angemerkt dass eine Aufnahme der Ist Prozesse nat rlich nur dann erfolgen muss wenn noch kein aktuelles Modell der relevanten Prozesse vorliegt Wenn Sie also bereits im Rahmen des BPM ein solches Modell erstellt haben k nnen Sie sofort mit dessen Analyse beginnen Analyse der Ist Prozesse Nach der Dokumentation der Ist Prozesse folgt deren Analyse Dabei m ssen Sie gemein sam mit der Fachabteilung die Schwachstellen in den aktuellen Abl ufen herausarbeiten Die Analyse kann teilweise bereits w hrend der Dokumentation erfolgen zumal die De tailtiefe in der Fachprozesse dokumentiert werden zumindest ausreichen muss um die Schwachstellen zu verdeutlichen Schwachstellen k nnen dabei zum Beispiel hoher manu eller Aufwand Medienbr che redundante Arbeiten oder Ineffizienz bspw Bedingt durch schlechte Aufgabenverteilung sein Zur Identifikation solcher Schwachstellen m ssen neben der Beschreibung des Prozessablaufs ggf auch relevante Informationen zu den ver schiedenen am Ablauf beteiligten Objekten Aktivit ten Organisationseinheiten Informa tionen IT Systeme erfasst werden So kann es bei den Informationen die in Prozess schritten Aktivit ten verarbeitet werden sinnvoll sein zu beschreiben wo sie herkommen bspw wo sie erstellt werden oder von welcher Abteilung sie stammen Solche Informa tionen k nnen hilf
402. verzichten Wir verfolgen an dieser Stelle das Ziel Services aus der fachlichen Perspektive in unseren fachlichen Modellen zu nutzen Ein Generierungsansatz wird nicht verfolgt Insbesondere die Ebene der ausf hrbaren IT Modelle wird in diesem Kapitel nicht behan delt Somit beschr nken wir uns auf die grau hinterlegten Objekte Bei einigen Modellierungsschritten wird von der BPA Suite eine besondere Toolunterst t zung angeboten Diese Unterst tzung setzt jedoch h ufig voraus dass das Modell in einem bestimmten Format aufgebaut ist Wir wollen in unserem Modell die besondere Toolunter st tzung weitestgehend erhalten und m ssen uns dementsprechend an einigen Stellen an ein vorgegebenes Format halten bersichtsmodelle und fachliche Detailmodelle Die fachliche Sicht von Abbildung 7 4 zeigt was fachlich im Modell abgebildet werden kann Wir wollen auf dieser Ebene eine Servicenutzung modellieren Es soll eine Verbin dung zwischen der Funktion und einem Service hergestellt werden Fachliche Services werden in der BPA Suite mit dem Objekt Gesch ftsservice modelliert Geschaftsservices kapseln eine Menge an F higkeiten Damit lehnen sich die Namen an das SOA Referenz modell von OASIS an Diese F higkeiten entsprechen den fachlichen Funktionalit ten die wir n einem Service kapseln wollen Der Zusammenhang zwischen Gesch ftsservice und F higkeiten wird in einem Service Zuordnungsdiagramm modelliert In unserem Serviceverst ndnis ist
403. vices Die zus tzlichen In formationen k nnen direkt im EPK Prozessmodell erg nzt werden Alternativ k nnen sie wie hier dargestellt auf einer Zwischenstufe in einem Funktionszuordnungsdiagramm vgl Abbildung 8 9 modelliert werden Dies bietet den Vorteil dass das EPK Modell nicht mit den zus tzlich modellierten Informationen berfrachtet und dadurch un bersicht lich wird Au erdem lassen sich bei der automatisierten Auswertung des integrierten EA und SOA Modells die unterschiedlichen Ebenen der Modellierung sauber voneinander trennen Fachlicher Prozessfluss Abbildung 8 8 zeigt den rein fachlichen Prozessfluss der Lieferungspositionspr fung aus unserem Beispiel der Wareneingangsprozesse Dar n erfasst ist neben den Prozessschritten BPA Objekt Funktion auch der fachliche Kontrollfluss Dieser wird n der EPK darge stellt durch die Verbindungen Kanten zwischen den Funktionen und Ereignissen und die so genannten Konnektoren AND OR XOR die ber parallelen oder alternativen Ablauf der Prozessschritte entscheiden Wie bereits erw hnt werden die weiteren relevanten In formationen in einem gesonderten Modell Funktionszuordnungsdiagramm vgl Abbil dung 8 9 erfasst Am Beispiel der Funktion Nachlieferung pr fen ist dies f r Organisa tion In Outputs und fachliche Services gezeigt 8 4 SOA Prozessmodellierung in der Oracle BPA Suite Qo iefermenge zu gering ieferpos itio fal
404. wareservices Zu beiden Kategorien existieren bersichtsb ume Gefunden wer den k nnen die bersichten bei eingeschalteter Navigation Ansicht gt Navigation auf den Reitern Servicetypen und Softwareservices Wurden alle Elemente im Modell wie n Ab bildung 7 4 verkn pft so erh lt man die umfangreichste Ansicht der Service bersichten Ein einfaches Beispiel f r die reduzierten Serviceansichten zeigt Abbildung 7 7 Service Repository EI Produktion Servicetyp ES Bestellung Servicetyp T EJ Nachlieferung Servicetyp 3 B Nachlieferung initieren Servicetyp Service Repository Ld Nachlieferungsservice Anwendungssystemtyp F higkeiten CJ Nachlieferung initieren implizit F higkeit Logische Datenobjekte Servicetyp LJ Nachlieferung Servicetyp Yerwendungen F higkeiten LJ Nachlieferung initieren F higkeit Gesch ftsobjekte Cod Artikelliefermenge in Fachbegriff C Material bestellung in Fachbegriff C4 Material bestelluna out Fachbegriff C4 Nachlieferungsmenge out Fachbegriff Visualizierungen a Nachlieterungsservice Zugriftsdiagramm Es Nachleterungsservice Anwendungssystentypdiagramm verantwortliche Realisierungen Yerwendungen Ysualisierungen B Domanendekomposttion Service Architekturdiagr amm es Nachlieferung initieren Service Zuordnungsciagramm Yerantwo rtliche Ziele Sottwareservice Operationen Load Initiiere MNachlieferung D Y Funktionstyp F higkeiten
405. warespezifikation haben auch viele Softwarehersteller erkannt und Softwareprodukte auf den Markt gebracht die durchg ngi ge BPM L sungen meist auf der Basis serviceorientierter Ans tze versprechen Wenn gleich die aktuelle Produktlandschaft von dieser Vision der Implementierung ohne Pro grammierung noch ein gutes St ck entfernt ist bieten Prozessmodell basierte Ans tze dennoch einen erheblichen Mehrwert F r die systematische Analyse und Modellierung fachlicher Prozesse auch in Verbindung mit technischen Artefakten existiert bereits eine beachtliche Zahl ausgereifter und praxistauglicher Werkzeuge mitsamt der erforder lichen Notationsstandards und Modellierungsmethoden 8 2 3 3 Inhaltliche Abgrenzung dieses Kapitels Im Folgenden wird gezeigt wie ein methodisches Vorgehen zur Weiterverwendung eines fachlichen Business Process Managements bei der Implementierung prozessbasierter An wendungssysteme ausgestaltet werden kann Es wird dargestellt wie die fachlichen Pro zessinformationen in serviceorientierte Anwendungsbausteine berf hrt werden k nnen Dabei gilt es korrekte und relevante Informationen zu erfassen und diese redundanzfrei in geeigneten Modellen aufzubereiten Dies bildet die Basis f r die Entwicklung technischer 8 3 Modellierung SOA geeigneter Prozessmodelle Prozessanwendungen in der Unternehmens IT und erhebt den Anspruch dem SOA Ent wickler zum Rollenverst ndnis vgl Abschnitt 8 3 3 wesentliche implementi
406. wei exakt welche Leistungen sie im Unternehmen anbietet Vor einer Neuimplementierung von Funktionalit t kann der Bestand auf bestehende Funktionalit ten durchsucht werden Bei der nderung von Funktionalit ten lassen sich die Auswirkungen auf abh ngi ge Services oder Prozesse ermitteln Reduzierte Wartungskosten Eine SOA kann die eigentlichen Wartungskosten der Software Systeme reduzieren da mehr Services und weniger monolithische Anwendungsbl cke gepflegt werden k nnen Durch die dokumentierten Schnittstellen l sst sich die Konzeptphase von Wartungsprojekten verk rzen Schnittstellen k nnen im Gegensatz zu Monolithen leichter getestet werden E Zukunftssichere Architekturen Durch die durchg ngige Verwendung von Standards reduziert sich die Abh ngigkeit von propriet ren Herstellerl sungen Beispiele BPMN BPEL Web Services WSDL SCA SDO JCA Aufbau eines Serviceportfolios 170 Das Serviceportfolio ist die zentrale Sammelstelle an der alle Informationen zu den Servi ces hinterlegt werden Das Portfolio umfasst alle Services des eigenen Unternehmens und die Services auf die es zugreifen kann z B eingekaufte Services Zus tzlich zu den m Serviceverzeichnis aufgef hrten Services rein fachliche Services n der IT realisierte fachliche Services und technische Services enth lt ein Serviceportfolio Servicekandidaten Anders als 1m Serviceverzeichnis werden hier auch Informationen ber den Se
407. weit wie m g lich einhalten Tabelle 5 2 Inhalt und Abgrenzung der Unternehmensinstanzebene 1 Instanzgranularit t Benennung der In der Regel erh lt die Unternehmensinstanz Ebene als Bezeichnung die Unternehmens oder 1 Instanzgranularit t Unternehmensbereichsbezeichnung Zentrales Diagramm zur Beschreibung der dynamischen Inhalte des Modells Genutzte Prozess oder Aktivit ts Das Prozess oder Aktivit tsobjekt beschreibt dynamische Objekttypen objekt Vorg nge Gesch ftsobjekt Das Gesch ftsobjekt beschreibt die im Rahmen der Prozess durchfuhrung Dynamik bearbeiteten statischen Objekte Beziehungsobjekt Das Beziehungsobjekt beschreibt die Beziehung zwischen Prozess oder Aktivit tsobjekten und Gesch ftsobjekten Die Beziehungen k nnen entweder Input oder Output Beziehungen sein Abgrenzung Granularit t Jeder einzelne Kernprozess bearbeitet vollst ndig ein Geschaftsobjekt der auf den Diagrammen ausgepr gten Objekte Die Gesch ftsobjekte werden zwischen den einzelnen Kernprozessen ausgetauscht Die Kernprozesse gliedern ein Unternehmen in Prozessdom nen Maximal 4 Gesch ftsobjekte pro Kernprozess 89 5 Das Grundmodell 90 5 2 2 2 Die 2 Instanzgranularitat Die Kernprozessebene Die 2 Instanzgranularitat Kernprozessebene detailliert die Kernprozesse der Prozess landkarte Auf ihr werden zu jedem ermittelten Kernprozess die untergeordneten Haupt prozesse dargestellt Welche Kernpro
408. werden im Attribut Beschreibung Definition kurz beschrieben und k nnen so direkt aus der Oracle BPA Suite ausgewertet werden Bestellung ausw hlen Beschreibung Definition Auf Basis von Bestellnummer Lieferantennummer Bestelldatum Bruttobetrag jeweils und oder k nnen passende Rechnungen aus dem System aufgerufen werden Die Rechnung zum aktuell zu bearbeitenden Lieferschein kann in einer neuen Maske vollst ndig angezeigt und bearbeitet werden wird aktiviert durch Auf Teillieferung pr fen START ist Vorg nger von Liefermenge eingeben steht unter DV Verantwortung Mitarbeiter Warenannahme Personentyp von wird repr sentiert durch Bestellung suchen hat Input Bestellnummer Fachbegriff hat Output Materialbestellung Fachbegriff Liefermenge eingeben Beschreibung Definition Zu jeder Position der Bestellung wird die tats chliche Liefermenge eingegeben Dabei werden die Felder zun chst mit der Bestell menge gef llt so dass eine nderung nur f r die Artikel durchge f hrt werden muss bei denen die tats chlich gelieferte Menge von der Bestellmenge abweicht Dabei kann eine Abweichung nur darin bestehen dass die Liefermenge kleiner als die Bestellmenge ist Den Fall Liefermenge gt Bestellmenge muss das System nicht ab decken da dieser Fall auf andere Weise bearbeitet wird siehe Fachprozess folgt auf Bestellung ausw hlen ist Vorg nger von Teillieferung identifizieren Funktion 0 steht unter DV Verantwor
409. x Ereignis Abbildung 6 4 Zusammenhang zwischen Fach und IT Sicht 129 6 Modellgest tzte fachliche Konzeption individueller IT Systeme 130 Durch das beschriebene Vorgehen entsteht ein Gesamtmodell das den Anforderungen so wohl der Fach als auch der IT Abteilung gerecht w rd und somit als gemeinsame und f r beiden Seiten verst ndliche Diskussionsgrundlage verwendet werden kann In diesem Ge samtmodell finden sich die Fachprozesse mit den dazugeh rigen relevanten Informationen ebenso wieder wie die Systemabl ufe mit den f r eine Realisierung des Systems ben tig ten Informationen Die Systemabl ufe sind dar ber hinaus genau an den Stellen mit dem Fachprozess verkn pft an denen sie eine bestimmte fachliche Aktivit t unterst tzen Die Verkn pfung der beiden Sichten l sst sich auch unterhalb der Ablaufebene an den darge stellten Objekten weiter verdeutlichen Eine fachliche Aktivit t wird durch eine bis mehre re Verarbeitungsschritte eines Systemablaufs abgebildet Die f r die Durchf hrung einer fachlichen Aktivit t ben tigten bzw bei der Durchf hrung erzeugten Informationen wer den in der IT Sicht durch konkrete Daten detailliert die in den fachlichen Informationen enthalten sind und in der IT Sicht einzeln angezeigt und bearbeitet werden k nnen Ferner wird eine organisatorische Einheit z B Abteilung oder Stelle die eine fachliche Aktivit t ausf hrt in der IT Sicht durch bestimmte Benutzerrollen dargestellt
410. zeption individueller IT Systeme 142 F r unser Fachkonzept ist der erste Fall also die Mindermenge interessant Es ist m glich dass mehr als eine Lieferung zu einer Bestellung geh rt dass also nicht alle bestellten Artikel in einer einzigen Lieferung sondern in mehreren Teillieferungen enthalten sind Diese M glichkeit muss m Fall einer Mindermenge gepr ft und das Ergebnis der Pr fung im System erfasst werden Dieser Arbeitsschritt Teillieferung pr fen wird durch den Wareneingangsmitarbeiter in einer Interaktion mit dem System durchgef hrt siehe Abbil dung 6 13 Auf Teillieferung pr fen areneingangs protokoll amp Lieferschein Abbildung 6 13 Fachliche Aktivitat Teillieferung pr fen Teillieferung pr fen Wir gehen f r unser Beispiel davon aus dass der Fachprozess vorgegeben ist es sich also arenbegleit papiere amp entweder bereits um einen entwickelten Soll Fachprozess oder einen Ist Fachprozess der nicht ver ndert sondern lediglich IT technisch unterst tzt werden soll handelt Zur Durchf hrung der Aktivit t Teillieferung pr fen werden die Informationen auf dem Lie ferschein sowie die Warenbegleitpapiere ben tigt Das Ergebnis der Pr fung wird im Sys tem erfasst und kann in Form eines Wareneingangsprotokolls ausgegeben werden Die Abteilung Warenannahme ist f r die Durchf hrung der fachlichen Aktivit t zust ndig Die IT Unterst tzung wird du
411. zessaktivitaten 5 40 IT Aktivit ten IT Automatisie rungsobjekte generiert IT Automatisie rungsobjekte implementiert 1 Instanzgranularit t Unternehmensinstanz 2 Instanzgranularit t Kernprozessinstanz 3 Instanzgranularit t Fachliche Hauptprozessinstanz bersichtsmodelle 4 Instanzgranularit t Unterprozessinstanz 5 Instanzgranularit t Detailprozessinstanz optional 6 Instanzgranularit t IT Interaktionsinstanz Fachliche Detailmodelle 7 Instanzgranularit t IT Prozessinstanz Fachliche IT Modelle Instanzgranularit t implementierte if IT Prozessinstanz Ausf hrbare IT Modelle N Abbildung 7 2 Ebenen eines Prozessmodells Prozesse Services bersichts PD nter __ gt Te Fachliche en realisiert Detailmodelle O O O z gt Y gt _ a Fachliche realisiert m VOOO Abbildung 7 3 gt _ 2 7 ww E g a Ausf hrbare E Kain enn en zz O O O O O O Hierarchien M chte man Services strukturieren wird man die bestehenden Prozessdiagramme nicht wieder verwenden k nnen und muss neue Ordnungskriterien und Diagramme erstellen Werden Prozessschritte mit Services verbunden bedeutet dies auf oberster Hierarchieebe ne eher eine Unterst tzung Z B K nnte ein Kerngesch ftsprozess Wareneingang durch einen Kerngesch fts Service Ware unterst tzt werden Das bedeutet jedoch nicht dass alles was sich hinter
412. zesse weiter detailliert werden hangt immer von der individuellen Frage stellung ab die Ihr Modell beantworten soll Es gibt keine Vorgaben die festlegen welche Kernprozesse der Prozesslandkarte zwingend weiter zu beschreiben sind Sollten Sie im vorliegenden Beispiel detailliertere Informationen ber alle prim ren Kernprozesse ben ti gen so entstehen 10 Diagramme auf der Kernprozessebene die zu jedem Kernprozess die jeweils untergeordneten Hauptprozesse beschreiben Welche weitergehende Detaillierung Sie f r Ihr Projekt ben tigen k nnen Sie also frei fest legen Zur Identifikation der Hauptprozesse ermitteln Sie f r jeden Kernprozess die Aktivit ten die erforderlich sind um den Prozess vollst ndig auszuf hren Diese Verfeinerung f hrt n der Regel zu dem Ergebnis dass viele einzelne Aktivit ten beschrieben werden die nicht alle derselben Granularitat entsprechen Deshalb sollten Sie in einem weiteren Schritt die ermittelten Aktivit ten hierarchisch gliedern Ziel ist es abzugrenzen welche der ermittel ten Aktivit ten sinnvoll die Hauptprozesse unterhalb des Kernprozesses bilden Bei der Durchf hrung der Abgrenzung kann man zun chst von den Gesch ftsobjekten des bergeordneten Kernprozesses ausgehen Diese markieren als Input und Output des Kern prozesses die an der Schnittstelle des zu detaillierenden Kernprozesses liegenden Haupt prozesse Im Regelfall sind zus tzlich noch weitere Aktivit ten bekannt Diese m
413. zessinstanz die Messwerte in die Datenbank f r das near realtime Process Monitoring gespielt Das Echtzeit Process Monitoring also die Situationsanalyse der in Abarbeitung befind lichen Gesch ftsprozesse wird ber BAM Ans tze verfolgt Die Daten werden kurzzeitig meist nur bis zum Ende des Prozesses vorgehalten und dienen der berwachung der ab laufenden Prozesse Enterprise Service Bus ESB AZ Transformation i Transformation Laden ber Laden ber Anzeige KPI spezielle ber spezielle auf BAM Model BAM System Routinen Ro tin n Caa a Datenbank Datenbank Staging Area Enterprise Model Extraktion Process Process Process Transformation Monitoring Mining Cockpit Abbildung 9 6 Architekturmodell des Process Warehouse 2 Anwendungssysteme Die Daten flie en anders als bei den klassischen eher mengenorientierten ETL Pro zessen transaktionsbezogen in Echtzeit in das System f r das Process Monitoring in der Praxis meist BAM Systeme Es erscheint sinnvoll die Datenablage des Process Moni toring Systems als spezifische Staging Area f r das eigentliche Process Warehouse zu betrachten STA07 Hierf r werden in letzter Zeit verst rkt In Memory Datenbanken ge nutzt um den geforderten Durchsatz hinsichtlich der Transaktionsdaten zu gew hrleisten Das Ex post Process Mining setzt auf dem Enterprise Modell oder auf entsprechenden subjektbezogenen Datensammlungen so genan
414. ziehungen k nnen entweder Input oder Output Beziehungen sein Abgrenzung Granularit t Alle Unterprozesse auf den erstellten Diagrammen m ssen zur Bearbeitung der der auf den Diagrammen Gesch ftsobjekte Input und Output des bergeordneten Hauptprozesses erforderlich ausgepr gten Objekte sein Untereinander tauschen sie Gesch ftsobjekte aus Ein Gesch ftsobjekt wird immer nur von einem Unterprozess vollst ndig bearbeitet Die dem bergeordneten Hauptprozess zugeordneten Gesch ftsobjekte m ssen als Input oder Output durch die Unterprozesse an der Schnittstelle der Hauptprozessinstanz Ebene erstellt bzw bearbeitet werden Maximal 4 Gesch ftsobjekte pro Unterprozess 94 5 2 Aufbau des Grundmodells 5 2 3 Die Instanzgranularitaten 1 bis 3 im Zusammenhang Alle Objekte der fachlichen Uberblicksmodelle stehen in engem Zusammenhang Abbil dung 5 6 zeigt welche Beziehungen zwischen den ersten drei Ebenen des dynamischen Teils bestehen Bei der Erstellung dieses Modellteils sollten Sie die folgenden Punkte be rucksichtigen l Externe Prozesse EP werden als Black Box betrachtet Eine Detaillierung unterhalb der Prozesslandkarte erfolgt nicht Sie werden lediglich als Kernprozesse KP einer externen Organisation als Objekt in der Prozesslandkarte aufgenommen um zu zeigen welche Gesch ftsobjekte GO mit externen Parteien ausgetauscht werden Bei der Detaillierung eines Prozesses werden die Vor und Nachfolgeprozes
415. zierten fachlichen Services sollen als Prozess fachliches IT Modell spezifiziert und anschlie end in der IT implementiert wer den _Dispostion _ ist fachlich verantwortlich f r __ Disposition sich sss bestellung f hrt dus _ beauftragter Operation Er achlieferun achlieferung Use Case Operation Zedarfsplanung Nachlieferung__ berpr fen En Abbildung 8 9 Detaillierung des fachlichen Detailmodells im Funktionszuordnungsdiagramm Der SOA Business Analyst erfasst im Modell fachliche Services welche die Prozess schritte durch Leistungen ihrer Operationen unterst tzen vgl Abschnitt 8 3 4 1 Dazu greift er idealerweise auf das fachliche Serviceportfolio zur ck und verwendet die dort aus einer statischen Sicht modellierten Services Abbildung 8 9 zeigt in Form eines Funktions zuordnungsdiagramms die Modellierung der fachlichen Detailinformationen zum Prozess schritt Nachlieferung pr fen BPA Objekt Funktion F r die Abbildung der fachlichen 8 4 SOA Prozessmodellierung in der Oracle BPA Suite Serviceunterst tzung wird das Gesch ftsservice Objekt Nachlieferung berpr fen mit dem Prozessschritt Nachlieferung pr fen verbunden Nachlieferung berpr fen st eine Operation des Gesch ftsservice Lieferungskontrolle vgl Abbildung 8 10 Dem Gesch ftsservice k nnen in der BPA Suite in Form von Attributen verschiedene Ei genschaften zugeordnet werden Typ Beschreibung Daten In

Enterprise Architecture, BPM und SOA für Business Analysten

Contents

Download Pdf Manuals

Related Search

Related Contents

Enterprise Architecture, BPM und SOA f&uuml;r Business Analysten

Contents

Download Pdf Manuals

Related Search

Related Contents

Enterprise Architecture, BPM und SOA für Business Analysten