THEMENSCHWERPUNKT BPM Projektbeispiel Umsetzung der Bestellanforderung (BANF) gemäß IBPM-Vorgehensmodell

Größe: px
Ab Seite anzeigen:

Download "THEMENSCHWERPUNKT BPM Projektbeispiel Umsetzung der Bestellanforderung (BANF) gemäß IBPM-Vorgehensmodell"

Transkript

1 BPM Projektbeispiel Umsetzung der Bestellanforderung (BANF) gemäß IBPM-Vorgehensmodell 26. Mai 2011 Enterprise BPM Dirk Slama und Ralph Nelius

2 Inhalt Zusammenfassung... 4 Enterprise BPM Integrierte BPM-Projektmethodik (IBPM)... 5 IBPM-Framework... 6 IBPM-Vorgehensmodell IBPM-Patterns Firma Good Goods und die Bestellanforderung Planung des BANF-Projektes Prozessperspektive Serviceperspektive Projektplan Projektantrag Arbeitspaket PO-A A. Prozessmodell (PO-A) B. Prozessorganisation / Rollen (PO-A) C. User Task Management (PO-A) D. Geschäftsregeln, (PO-A) E. Prozessanalyse und Reporting (PO-A) Arbeitspaket SO-A F. SOA-Komponentisierung (SO-A) G. Frontends und UI-Design (SO-A) H. Prozesskomponenten (SO-A) I. Business-Objekte und Backend-Komponenten (SO-A) J. Technische Architektur und Infrastruktur (SO-A) Enterprise BPM Dirk Slama und Ralph Nelius 2

3 6 Arbeitspaket PO-D I A. Prozessmodell (PO-D I) B. Prozessorganisation und Prozessrollen (PO-D I) C. User Task Management (PO-D I) D. Geschäftsregeln (PO-D I) E. Prozessanalyse und Reporting (PO-D I) Arbeitspaket SO-D I F. SOA-Komponentisierung (SO-D I) G. Frontends und UI-Design (SO-D I) H. Prozesskomponenten (SO-D I) I. Business-Objekte und Backend-Komponenten (SO-D I) J. Technische Architektur und Infrastruktur (SO-D I) Arbeitspaket PO-D II A. Prozessmodell (PO-D II) B. Prozessorganisation und Prozessrollen (PO-D II) C. User Task Management (PO-D II) D. Geschäftsregeln (PO-D II) E. Prozessanalyse und Reporting (PO-D II) Arbeitspaket SO-D II F. SOA-Komponentisierung (SO-D II) G. Frontends und UI-Design (SO-D II) H. Prozesskomponenten (SO-D II) I. Business-Objekte und Backend-Komponenten (SO-D II) J. Technische Architektur und Infrastruktur (SO-D II) Konklusion Enterprise BPM Dirk Slama und Ralph Nelius 3

4 Zusammenfassung Praxisbeispiele sind einer der effizientesten Wege, um Projektmethodiken für die eigene Arbeit zu adaptieren und fruchtbar zu machen. Anhand des Fallbeispiels der Bestellanforderung (BANF) wird in diesem Themenschwerpunkt die Anwendung der Integrierten BPM- Projektmethodik (IBPM) aus dem Buch Enterprise BPM vorgestellt. Enterprise BPM Enterprise BPM bietet eine vollständige und in sich geschlossene Methodik zur Umsetzung von BPM auf Unternehmensebene. Es gibt dem Leser das notwendige Praxiswissen an die Hand, um einzelne BPM-Projekte effizient umzusetzen und strategische BPM-Initiativen zum Erfolg zu führen. Der Schwerpunkt des Buches liegt auf der Darstellung der»integrierten BPM-Projektmethodik«(IBPM). Mit IBPM können BPM-Projekte klar strukturiert und mit einheitlichem Vorgehen unter Anwendung von Best Practices durchgeführt werden. Weiter wird das»enterprise BPM-Framework«(EBPM) zur Einführung von BPM auf Unternehmensebene vorgestellt. Expertenmeinungen und Fallbeispiele von Firmen wie Credit Suisse, Degussa Bank, Deutsche Lufthansa AG, BAA Heathrow und Deutsche Post AG beleuchten die Umsetzung in der Praxis. Auf der Website des Buchs finden sich u.a. Dokumentvorlagen, die IBPM und EBPM unterstützen, der Pattern-Katalog sowie das BANF-Beispiel aus diesem Text in ausführlicher Form. Außerdem werden auf der Webseite regelmäßig BPM-Themenschwerpunkte wie dieser veröffentlicht (www.enterprise-bpm.org, Enterprise BPM Dirk Slama und Ralph Nelius 4

5 1 Integrierte BPM-Projektmethodik (IBPM) Viele fachliche Prozessoptimierungen (Stichwort: kontinuierlicher Verbesserungsprozess, KVP) setzen die Durchführung von BPM-Projekten voraus. Das heißt, die effiziente Durchführung von BPM-Projekten auf IT-Seite ist Grundlage des KVP auf der Business-Seite. Außerdem muss sichergestellt sein, dass jedes Projekt einen Beitrag zum Auf- und Ausbau von BPM und SOA leistet, damit der KVP unterstützt werden kann (als Beispiel sei hier die Trennung von Prozessfluss und Entscheidungslogik genannt, die ein wesentliches BPM/SOA-Konzept ist und maßgeblich dazu beiträgt, dass Prozesse ohne das Aufsetzen eines Projekts, nur durch Anpassung der Regeln optimiert werden können). Daher muss sichergestellt sein, dass die Lieferergebnisse der Projekte konform mit den Architekturanforderungen von BPM und SOA sind. Abb. 1 zeigt den typischen Ablauf eines einzelnen BPM-Projektes. Abbildung 1: Einordnung der Integrierten BPM-Projektmethodik (IBPM) in ein BPM-Gesamtprojekt Um diesen Anforderungen sowohl effiziente Durchführung als auch BPM/SOA-kompatible Projektergebnisse gerecht zu werden, fasst die Integrierte BPM-Projektmethodik (IBPM) alle wichtigen Aspekte von BPM in einen einheitlichen Methodikansatz zusammen. Dies ist insbesondere durch die 10 Säulen des IBPM-Frameworks sichergestellt, die eine integrierte Sicht auf das Zusammenspiel aller möglichen Aspekte eines BPM-Projekts geben. Wichtig ist uns an dieser Stelle, dass wir das Rad nicht neu erfinden. Es gibt heute bereits diverse Vorgehensmodelle für die Softwareentwicklung, vom V-Modell XT über den Rational Unified Process (RUP) bis hin zu agilen Methoden wie SCRUM. IBPM fokussiert daher auf die inhaltli- Enterprise BPM Dirk Slama und Ralph Nelius 5

6 chen Spezifika eines BPM-Projekts und kann mit jeder dieser mehr generischen IT-Projektmethodiken kombiniert werden. Um die inhaltlichen Spezifika eines BPM-Projekts erfassen und meistern zu können, sind drei Kernelemente wesentlich, die zusammen die IBPM-Methodik bilden: Das Framework definiert die Inhalte von BPM-Projekten Das Vorgehensmodell gibt die Grundstruktur der Phasen und Arbeitspakete vor Die Entwurfsmuster helfen bei der Bearbeitung der Arbeitspakete Bevor wir in das Projektbeispiel einsteigen, werfen wir zunächst einen kurzen Blick auf diese drei Kernelemente, damit Sie die zugrundeliegende Mechanik besser verstehen. Wir beginnen beim Framework. IBPM-Framework Wie in Abb 2 zu sehen ist, beschreibt das IBPM-Framework zunächst einmal das Zusammenspiel eines einzelnen Projekts mit der Unternehmensebene. Hierbei spielt die Einordnung des Projekts in den Enterprise-Kontext eine wichtige Rolle. Dies betrifft insbesondere die Einordnung in Organisationsstruktur, Prozesslandkarte und Domänenmodell des Unternehmens sowie die Abhängigkeiten zwischen dem Projekt und den unternehmensweiten Services und Anwendungen. Auch die Erfassung und Auswertung der Abhängigkeiten von Projekten untereinander ist erfolgskritisch. Abbildung 2: Übersicht über das IBPM-Framework Enterprise BPM Dirk Slama und Ralph Nelius 6

7 Innerhalb des Projekts wird der Schwerpunkt dann auf das Zusammenspiel zwischen prozessund serviceorientierten Methoden gelegt. Aus Sicht von Prozessorientierter Analyse und Design (POAD) sind die folgenden Elemente in IBPM wichtig: IBPM-Säule A: Prozessdokumentation und Prozessdesign IBPM-Säule B: Prozessorganisation und Prozessrollen IBPM-Säule C: User Task Management IBPM-Säule D: Geschäftsregeln IBPM-Säule E: Prozessanalyse und Reporting Aus Sicht von Serviceorientierter Analyse und Design (SOAD) sind die folgenden Elemente in IBPM wichtig: IBPM-Säule F: SOA-Komponentisierung IBPM-Säule G: User Interface Design IBPM-Säule H: Prozesskomponenten IBPM-Säule I: Business-Objekte und Backend-Komponenten IBPM-Säule J: Technische Architektur In einem BPM-Projekt, das einen nachhaltigen Beitrag für Geschäft und IT im Sinne einer Managed Evolution liefern soll, muss die Prozessperspektive gleichberechtigt neben der Serviceperspektive stehen. Die Säulen helfen, die Inhalte jeweils klar zu definieren und die Abhängigkeiten zwischen ihren Elementen in den Griff zu bekommen. Handhabbar wird das, wenn man schrittweise von der Übersicht zum fachlichen und weiter zum Umsetzungsmodell vorgeht Dann kann das Projekt auch in kurzer Zeit produktiv nutzbare Ergebnisse mit Geschäftswert liefern. Lassen sie uns kurz ansehen, wie das gemeint ist. Die ersten fünf Säulen beschreiben Aspekte der Prozessperspektive (siehe Abb. 3). Wir sagen bewusst nicht fachliche Perspektive, denn auch in der Prozessperspektive spielen technische Dinge wie das BPMS oder das BRM-System eine wichtige Rolle in den Modellen. Die Elemente, die in der Prozessperspektive erfasst werden, kommen aber allesamt aus der Geschäftsarchitekturebene einer Unternehmensarchitektur. Das Hauptartefakt, in dem die Fäden der Prozessperspektive zusammenlaufen, ist das Prozessmodell (Säule A). Das Prozessmodell beschreibt geschäftliche Abläufe durch Geschäftsvorfälle (Ereignisse), Aktivitäten, Prozessflüsse und Konnektoren. Diese müssen von der zu erstellenden BPM-Lösung teil- oder vollautomatisiert umgesetzt werden. Enterprise BPM Dirk Slama und Ralph Nelius 7

8 Abbildung 3: Prozessperspektive Die restlichen fünf Säulen beschreiben Aspekte der Serviceperspektive (siehe Abb. 4). Wir sagen bewusst nicht IT-Perspektive, denn auch hier werden fachliche Fragestellungen behandelt. Die Elemente, die in der Serviceperspektive erfasst werden, kommen aber vorwiegend aus der Servicearchitekturebene der Unternehmensarchitektur plus zusätzlich aus der Applikationsarchitekturebene. Das Hauptartefakt, in dem die Fäden der Serviceperspektive zusammenlaufen, ist die SOA Map (Säule F). Die SOA Map beschreibt die Lösungsarchitektur in Form von fachlichen Komponenten und Services, die miteinander gekoppelt sind und Daten austauschen. Sie stellt außerdem die Verknüpfung zur Anwendungsarchitektur her, da sie zusätzlich angibt welche Applikation als physischer Servicegeber für den Service selbst fungiert. Abbildung 4: Serviceperspektive Enterprise BPM Dirk Slama und Ralph Nelius 8

9 Die SOA Map verknüpft außerdem die vier weiteren Säulen der Serviceperspektive: UI Design (Säule G), Prozesskomponenten (Säule H), Business-Objekte und Backend-Komponenten (Säule I) sowie die technische Architektur (Säule J). Jede der 10 Säulen gehört entweder zur Prozess- oder zur Serviceperspektive. Beide werden in BPM-Projekten benötigt. Daher legen wir in IBPM Wert darauf, beide Perspektiven parallel zueinander zu entwickeln und konsistent zu halten. Um das für ein Projekt handhabbar zu machen, führen wir zusätzlich fünf Detaillierungsebenen ein, die gut zu den generischen Phasen eines Projektes passen: 1. Planung 2. Analyse 3. Fachliches Design 4. Umsetzungsdesign 5. Umsetzung Führen wir nun die 10 Säulen der Prozess- und der Serviceperspektive mit den 5 generischen Phasen eines Projekts zusammen, dann ergibt sich eine 5 10-Matrix: Abbildung 5: Zusammenführen der Prozess- und Serviceperspektive in einem Mehrebenenmodell Enterprise BPM Dirk Slama und Ralph Nelius 9

10 Die so entstandene 5 10-Matrix ist die Grundlage des IBPM-Frameworks. Für die einzelnen Felder der Matrix bzw. des IBPM-Frameworks werden durch POAD bzw. SOAD konkrete Methoden und Ergebnistypen definiert. In Abb. 6 ist die Matrix noch einmal im Detail dargestellt. Abbildung 6: Übersicht IBPM-Framework mit den 10 thematischen Säulen und Detaillierungsebenen IBPM-Vorgehensmodell Das IBPM-Vorgehensmodell greift die thematischen Säulen und Detaillierungsebenen aus dem IBPM-Framework auf und bringt sie in die Form handhabbarer Projektphasen und Arbeitspakete für ein BPM-Projekt gebracht (siehe Abb. 7). Darüber hinaus gibt es Hilfestellungen, wer in welcher Rolle wann welche IBPM-Artefakte erstellt. Enterprise BPM Dirk Slama und Ralph Nelius 10

11 Abbildung 7: Arbeitspakete im IBPM-Vorgehensmodell Eingebettet in Planung und Umsetzung werden sechs Arbeitspakete definiert: Prozessorientierte Analyse (PO-A) Serviceorientierte Analyse (SO-A) Prozessorientiertes fachliches Design (PO-D I) Serviceorientiertes fachliches Design (SO-D I) Prozessorientiertes Umsetzungsdesign (PO-D II) Serviceorientiertes Umsetzungsdesign (SO-D II) Damit können Sie in der Projektarbeit schrittweise vorgehen, um mithilfe von POAD und SOAD umsetzungsreife Spezifikationen zu erstellen. IBPM-Patterns Bei der Bearbeitung der einzelnen Arbeitspakete haben sich einige Lösungsmuster für häufig wiederkehrende Entwurfsprobleme bewährt. Wir haben diese Lösungsmuster in 7 Gruppen strukturiert (siehe Tab. 1). Enterprise BPM Dirk Slama und Ralph Nelius 11

12 Gruppe Beschreibung 1 Process Interaction Welche Interaktionsmuster kann ein Prozess unterstützen? 2 Process/BO Wie modelliert man das Zusammenspiel von Prozessen und Geschäftsobjekten in einer SOA? 3 Process Portlets Welche Portlets finden sich in einem Prozessportal? 4 UI/Process Modelling Wie modelliert man das Zusammenspiel zwischen UI und Prozess? 5 Process Portal Wie modelliert man Prozesse, die innerhalb eines Portals ablaufen? 6 Process Networks Wie modelliert man vernetzte Prozesse und Geschäftsobjekte? 7 General Patterns Wie modelliert man Eskalation, Change Management und Monitoring? Tabelle 1: Gruppen von IBPM-Patterns Die Patterns bauen aufeinander auf. Angefangen bei grundsätzlichen Fragen, wie eine BPM- Prozessinstanz mit ihrem Umfeld (Benutzer und IT-Systeme) interagieren kann, bis hin zu allgemeinen Fragen der Modellierung von Eskalationen oder geplanten Änderungen an der Geschäfts- und Servicearchitektur helfen diese Lösungsmuster bei vielen Fragen weiter, die nach unserer Erfahrung im Projektverlauf auftreten. 2 Firma Good Goods und die Bestellanforderung Als Beispiel für die Anwendung der Integrierten BPM-Projektmethodik dient uns die fiktive Firma Good Goods AG, ein internationaler Hersteller besonders guter Güter. Im Rahmen des BPM- Programms der Good Goods AG wurden mehrere Projektkandidaten identifiziert, darunter auch im Bereich Beschaffung. Der Chief Operation Officer (COO), dem die Beschaffung untersteht, sieht hier große Optimierungspotenziale durch BPM und beauftragt den IT-Koordinator des Fachbereichs mit einer Vorstudie. Mit Hilfe der Unterstützung des BPM Competence Centers der Good Goods AG nimmt ein Projektkandidat mit dem Arbeitstitel BANF-Projekt nach kurzer Zeit konkrete Züge an. Daraufhin wird ein Projektleiter ernannt, der das Projekt aufsetzen soll. Der Projektleiter führt das Projekt mit Hilfe der IBPM-Methodik durch. Enterprise BPM Dirk Slama und Ralph Nelius 12

13 3 Planung des BANF-Projektes Dem Projektleiter wird ein Prozessanalyst zur Seite gestellt, der sich im Umfeld der Beschaffungsprozesse gut auskennt. Im Folgenden sehen sich Projektleiter und Prozessanalyst die Prozess- und Serviceperspektive an, danach leitet der Projektleiter den Projektplan ab. Siehe auch IBPM-Vorgehen, Projektphasen, Rollen und Planung. Prozessperspektive Der Prozessanalyst verortet zunächst das BANF-Projekt in der Prozesslandkarte der Good Goods AG. Vom BPM-Koordinator erhält er dazu die entsprechende Übersicht. Das Projekt betrifft den Hauptprozess Materialbestellung (siehe Abb. 8). Abbildung 8: Verortung des Projektes in der Prozesslandschaft der Good Goods AG Damit ist auch der Prozesseigner eine Ebene unterhalb des COO identifiziert. Es handelt sich um den Leiter Beschaffung, der für diesen Hauptprozess zuständig ist. Enterprise BPM Dirk Slama und Ralph Nelius 13

14 Die genauere Betrachtung der beiden Teilprozesse Bestellanforderung und Bestellung ergibt, dass einige grundsätzliche Entscheidungen bezüglich des Prozess-Scopes getroffen werden müssen, da es enge Abhängigkeiten zwischen Prozessen und zu beschaffenden Produktgruppen gibt. So unterscheiden sich Prozessabläufe, involvierte Organisationseinheiten und eingesetzte IT-Systeme für Produktions- und Nichtproduktionsgüter stark voneinander. Erstere erfolgen überwiegend katalogbasiert, letztere nicht. Darüber hinaus führen bestimmte Warengruppen wie etwa Dienstleistungen später zu Prozessvarianten im Bereich Wareneingang/ Rechnungsprüfung. An dieser Stelle wird entschieden, dass in der ersten Projektstufe lediglich der Beschaffungsprozess (BANF) abgebildet werden soll und zwar mit Fokus auf Nichtproduktionsgüter und Dienstleistungen. Des Weiteren stimmen Prozessanalyst und Projektleiter weitere wichtige Aspekte für den Projektumfang mit dem IT-Koordinator und dem Leiter Beschaffung ab: Organisation und Prozessrollen: Die neue Lösung soll von allen Mitarbeitern der Good Goods AG an den Standorten im Euro-Raum genutzt werden können. Zum Anwenderkreis gehören alle Antragsteller, Fachexperten, Kostenstellenverantwortlichen und der Einkauf. Prozessziele: Grundsätzlich wünscht der Prozesseigner eine höhere Transparenz bezüglich der bestellten Güter. Als weiteres Projektziel gibt er außerdem vor, die durchschnittliche Bearbeitungszeit für einen BANF-Vorgang auf unter 10 Werktage zu senken. Da derzeit nur grobe Schätzungen über die tatsächlichen Bearbeitungsdauern vorliegen und die Durchlaufzeiten stark von den Produktgruppen abhängen, etwa mit/ohne Automatisierung bzw. manuelle Freigabe, muss diese Zielsetzung im weiteren Projektverlauf noch präzisiert werden. Serviceperspektive Die Serviceperspektive bearbeitet der Projektleiter selbst. Voraussetzung für die Verortung des Projektes in der Service- und Anwendungslandschaft zur Bestimmung des relevanten Scopes sind die fachlichen Vorgaben aus der Prozessperspektive. Zunächst bespricht er das Projekt mit einem Enterprise-Architekten. Beide werfen einen Blick auf das unternehmenseigene Domänenmodell (siehe Abb. 9). Der Schwerpunkt der für das Projekt benötigten Services liegt nach derzeitigem Kenntnisstand in der Domäne Einkauf. Eine Rückfrage beim SOA-Koordinator ergibt, dass in dieser Domäne leider noch keine Services existieren oder geplant sind, die wiederverwendet werden können. Darüber hinaus werden einige Services aus Querschnittsdomänen benötigt, bspw. aus der Domäne Finanzen Services für die Zuordnung von Kostenstellen sowie aus der Domäne Informationsmanagement Services für die Dokumentenablage. In letzterer Domäne existieren bereits Services, deren Wiederverwendung im Projekt geprüft werden soll. Enterprise BPM Dirk Slama und Ralph Nelius 14

15 Abbildung 9: Verortung des Projektes im Domänenmodell der Good Goods AG Im nächsten Schritt klärt der Projektleiter, welche Aufgaben im Bereich der technischen Architektur und Infrastruktur zu bewältigen sind. Dazu spricht er mit dem IT-Koordinator, dem BPM- Koordinator, dem für die Domäne Logistik und Planung zuständigen Enterprise Architekten sowie einem IT-Experten, der Anwendungsverantwortlicher für den betroffenen Ausschnitt der Anwendungslandschaft ist. Abb. 10 zeigt den Projektscope, der sich aus der Diskussion ergibt: Abbildung 10: Projektscope Im Rahmen des BANF-Prozesses für Nichtproduktionsgüter und Dienstleistungen wird derzeit das System GGS (Good Goods System für die Abwicklung der Bestellung von Nicht- Produktionsartikeln) zusammen mit einem ERP-System eingesetzt. Das GGS-System soll durch Enterprise BPM Dirk Slama und Ralph Nelius 15

16 das Projekt komplett abgelöst und durch eine portalbasierte BPMS-Lösung ersetzt werden. Die neue portalbasierte Lösung muss ins Unternehmensportal integriert werden. Die BPMS- Plattform ist bereits im Hause im Einsatz. Projektplan Der Projektleiter geht nun daran, den Projektplan zu erstellen. Wichtige Ansprechpartner für ihn sind dabei der IT-Koordinator, der Programmanager des BPM-Programms sowie der Leiter Beschaffung als eigentlicher Auftraggeber. Das IBPM-Vorgehensmodell liefert ihm die Grundstruktur für den Projektplan und die benötigten Rollen für die Aufgabenpakete. Basierend auf seinen Erfahrungen aus ähnlichen BPM-Projekten geht er zunächst davon aus, dass die benötigten Ressourcen in vollem Umfang zur Verfügung stehen und legt folgenden Projektplan fest: Abbildung 11: Projektplan Am Anfang des Projektplans steht die Planungsphase selbst, in der der Projektleiter bereits mit einem Prozessanalysten gearbeitet hat. Sie soll nach vier Wochen mit der internen Genehmigung für das Projekt abgeschlossen werden. Für Analyse und Design werden 9 Wochen benötigt, um eine umsetzungsreife Spezifikation zu erstellen. Die Bearbeitung erfolgt in den sechs POAD/SOAD-Arbeitspaketen. Für die darauffolgende Umsetzung werden 7, für den Rollout nochmals 4 Wochen veranschlagt. Der Zeitpuffer pro Phase beträgt jeweils ca. 1 Woche. Paral- Enterprise BPM Dirk Slama und Ralph Nelius 16

17 lel laufen die Querschnittsaktivitäten (Projektmanagement, Qualitätsmanagement, Infrastruktur, u.ä.). Daraus ergibt sich folgender Meilensteinplan: KW 9 KW 13 Fachliches Design Meilenstein Inhalt Beschreibung KW 4 Projektplan Projektplan für das aktuelle Release (Ziele, Scope, Ressourcen, etc.) KW 6 Analysemodell Grobes Prozessmodell und Anforderungen Überblick über relevante Anwendungslandschaft Umsetzungsdesign Fachlich detailliertes Prozessmodell und Geschäftsregeln Komponentenmodell, UI-Entwurf und Datenmodell Erweitertes Prozessmodell mit umsetzungsrelevanten Zusatzinformationen sowie Spezifikation der benötigten Services und Komponenten KW 20 Release Release/Produkt erstellt und getestet Organisatorische Vorbereitung für die Einführung der neuen Prozesse und Systeme durchgeführt KW24 Inbetriebnahme Geschäftlicher und technischer Betrieb aufgenommen Tabelle 2: Meilensteine Außerdem plant der Projektleiter Sitzungen des Steuerkreises am Ende jeder Projektphase ein. Zusätzlich legt er eine weitere Sitzung in KW 9 fest. Dies ist gute Praxis, da erfahrungsgemäß im ersten Prozessmodell aus der Analysephase ( Happy Path ) noch viele Unwägbarkeiten stecken können, die anfangs nicht erkannt werden und erst im detaillierten fachlichen Design zu Tage treten. Da bei BPM-Projekten die Gefahr besteht, dass mit dem groben Analysemodell zu hohe Erwartungen bei den Anwendern geweckt werden, die mit dem ursprünglich geplanten Budget und Zeitplan nicht erfüllt werden können, ist eine Steuerkreis-Sitzung zu diesem Zeitpunkt ratsam, um gegebenenfalls entweder ein Re-Scoping durchzuführen oder Anforderungen auf spätere Releases zu verschieben. Der gesamte Projektplan muss natürlich noch mehr umfassen, bspw. Projektorganisation und Ressourcenplan Kostenschätzung und Festlegungen zum Budget Betrachtung von Abhängigkeiten und Risiken Angaben zu Projektnutzen und ROI Projektantrag Zum Abschluss der Planungsphase fasst der Projektleiter alle wesentlichen Ergebnisse in einem Projektantrag zusammen, der einem Entscheidungsgremium zur Genehmigung vorgelegt wird. Die folgende Abbildung zeigt ein typisches Inhaltsverzeichnis für ein solches Dokument: Enterprise BPM Dirk Slama und Ralph Nelius 17

18 Abbildung 12: Projektantrag Da der Projektnutzen überzeugt, das Budget und die benötigten Ressourcen zur Verfügung stehen und durch die vorbildliche Planung (schrittweises Vorgehen, klare Meilensteine, keine wesentlichen organisatorischen oder technischen Hürden) kein besonderes Projektrisiko erkennbar ist, gibt das Entscheidergremium grünes Licht für das Projekt. Enterprise BPM Dirk Slama und Ralph Nelius 18

19 4 Arbeitspaket PO-A Verantwortlich für die Erstellung der Ergebnisse dieses Arbeitspakets ist der Prozessanalyst. Er ist angewiesen auf Zuarbeiten des Prozessmanagers und weiterer Mitarbeiter aus dem Prozess. Siehe auch IBPM-Vorgehen, PO-A Prozessorientierte Analyse. A. Prozessmodell (PO-A) Der Prozessanalyst modelliert gemeinsam mit dem Prozessmanager und Mitarbeitern aus dem Geschäftsprozess ein erstes Soll-Prozessmodell. Dabei verwendet er nur eine kleine Teilmenge des BPMN-Symbolsets, um die Grundstruktur in Form eines sog. Happy Path festzulegen. Zusatzinformationen hält er in Kommentaren fest Die folgende Abbildung zeigt dies anhand unseres BANF-Beispiels. Enterprise BPM Dirk Slama und Ralph Nelius 19

20 Abbildung 13: Prozessmodell Analyse (Happy Path) Der Prozess wird angestoßen durch einen Mitarbeiter (Anforderer), der aufgrund seines Bedarfes eine BANF erstellt. Diese wird anschließend in mehreren Schritten bearbeitet und freigegeben. Bei bestimmten Gütern und Dienstleistungen, bspw. Laptops, Handys oder juristischer Beratung, ist eine zusätzliche Prüfung durch die zuständige Fachabteilung (Fachexperte) erforderlich. Anschließend muss der Kostenstellenverantwortliche (Manager) den Vorgang kaufmännisch genehmigen. Schließlich bearbeitet ein Mitarbeiter aus dem Einkaufsbereich (Einkäufer) die BANF, bündelt diese ggf. und leitet den Bestellvorgang ein. Die Bestellung selbst ist ein Folgeprozess, der nicht mehr im Scope des Projektes liegt. Schon in diesem einfachen Ablauf stecken einige Besonderheiten und weiterführende Fragen, bspw. dass die kaufmännische Freigabe mehrstufig sein kann, dass aus einer BANF mehrere Bestellungen resultieren können oder die Frage, was geschieht, wenn die Freigabe nicht erteilt wird. Alle diese Fälle werden im fachlichen Design genauer zu betrachten sein. Siehe auch IBPM-Framework, Säule A. Prozessmodell. Enterprise BPM Dirk Slama und Ralph Nelius 20

21 B. Prozessorganisation / Rollen (PO-A) Zusammen mit der Erstellung des Prozessmodells müssen alle relevanten Prozessrollen identifiziert werden. Die operativ tätigen Rollen wurden bereits im Prozessmodell bestimmt, um die einzelnen Lanes zu beschriften. Dabei wurden identifiziert: Anforderer Fachexperten für fachliche Freigabe Kostenstellenverantwortliche für kaufmännische Freigabe Einkäufer Von besonderem Interesse sind hier in der Analysephase das damit verbundene Mengengerüst und der geografische Standort der Aufgabenträger. So geht es bei den Anforderern bspw. um mehrere hundert Mitarbeiter, verteilt auf verschiedene europäische Standorte. Daraus ergeben sich Anforderungen an technische Architektur (bspw. Anbindung) und Software (bspw. Mehrsprachigkeit). Darüber hinaus müssen alle weiteren relevanten Stakeholder identifiziert werden. Am wichtigsten sind dabei Prozesseigner: hier der Leiter Beschaffung Prozesscontroller: hier ein Mitarbeiter des Leiters Beschaffung Prozessmanager: hier der Teamleiter Einkauf Zentrale Falls zu diesem Zeitpunkt noch nicht klar sein sollte, wie die Rollen Prozesseigner und Prozessmanager besetzt sind, sollte der Prozessanalyst über den Projektleiter geeignete Maßnahmen anstoßen, um diese zu bestimmen. Anderenfalls fehlen ihm die Ansprechpartner für fachliche Anforderungen und Entscheidungen. Darüber hinaus muss der Prozessanalyst weitere Quellen erschließen und Informationen sammeln, die für den Bau einer BPM-Lösung vonnöten sind. Kernfragen sind: 1. Wo sind Informationen über die Organisation und Rollen zu finden? 2. Wo sind nutzerbezogene Informationen (Accounts u. IDs, Rollen u. Rechte) zu finden? Ansatzpunkte zu 1. sind Organigramm (Ansprechpartner HR) Verwaltung von Benutzerdaten (Ansprechpartner IT) Nachbarprojekte (Ansprechpartner Programmmanagement) Ansatzpunkte zu 2. sind Kandidaten wie ADS, LDAP, HR-System (SAP HR, Peoplesoft, etc.), Intranet / Portal Enterprise BPM Dirk Slama und Ralph Nelius 21

22 Gibt es überhaupt ein Repository mit allen Nutzern, die als Prozess-Stakeholder identifiziert wurden? Hat dieses Repository alle benötigten Zusatzinformationen? Gibt es evtl. schon Rollendefinitionen, die wiederverwendet werden können? Gibt es einen OnBoarding-Prozess und Administrationsmechanismen für die Rollen? Siehe auch IBPM-Framework, Säule B. Prozessorganisation & -rollen. C. User Task Management (PO-A) Im Themenfeld User Task Management diskutiert der Prozessanalyst einige grundsätzliche Fragen zur Arbeitsorganisation und zum Prozessablauf. Seine Gesprächspartner sind hier wieder der Prozessmanager und ausgewählte Prozessbeteiligte. Die wichtigsten Fragepunkte sind: Kanban-Potenzialanalyse: Kann der Prozess von einem Push-Modell auf ein Pull-Modell umgestellt werden? Task Pooling / personenbezogene Zuordnung: Wer soll mit dem Prozessportal arbeiten? Wie soll die Arbeitsorganisation aussehen? Müssen organisatorische Maßnahmen getroffen werden (bspw. Bildung neuer Teams)? Stellvertreterregelung: Wie ist die Stellvertreterregelung im Einkauf und den benötigten Fachabteilungen heute geregelt? Sind Änderungen nötig oder geplant? Eskalationen: gibt es besondere Vorgaben oder kritische Punkte im Prozessablauf (bspw. Kundenzusagen, SLAs), an denen geprüft werden muss, was geschehen soll, wenn bestimmte Parameter oder Zeiten überschritten werden? Mengengerüst: wie viele Vorgänge sind zu Produktionsbeginn und in den folgenden Jahren zu erwarten? Ist mit Spitzenbelastungen od. sehr hohen Datenvolumina zu rechnen? Siehe auch IBPM-Vorgehen, Säule C. User Task Management. D. Geschäftsregeln, (PO-A) Als nächstes versucht der Prozessanalyst herauszufinden, ob es bereits Unterlagen oder Systeme gibt, die Geschäftsregeln im Zusammenhang mit dem BANF-Prozess beschreiben. Hier stellt sich heraus, dass es im Einkauf ein Excel-Spreadsheet gibt, in dem definiert ist, nach welchen Regeln fachlich und kaufmännisch freigegeben werden muss. Diese Excel-Datei wird später im Design bei der Spezifikation der Geschäftsregeln genutzt werden. Darüber hinaus erfährt er, dass derzeit eine Controlling-Datenbank aufgebaut wird, in der Angestellte mit folgenden Informationen verwaltet werden: Enterprise BPM Dirk Slama und Ralph Nelius 22

23 Zugeordnete Managementhierarchieebene Verantwortete Cost Center Vorgesetztenverhältnisse Diese Datenbank enthält also wichtige Informationen zur Ausführung des Geschäftsprozesses und zur Anwendung der Geschäftsregeln. Der Prozessanalyst gibt diese Informationen an den Lösungsarchitekt und den Projektleiter weiter, da hier entschieden werden muss, ob diese Datenbank weitergebaut werden soll und wie die technische Architektur für die BANF und die darin enthalten Geschäftsregeln aussehen soll. Eine Entscheidung soll später im Umsetzungsdesign getroffen werden. Siehe auch IBPM-Vorgehen, Säule D. Geschäftsregeln. E. Prozessanalyse und Reporting (PO-A) Schließlich bespricht der Prozessanalyst mit Prozesseigner (Leiter Beschaffung), Prozesscontroller (Mitarbeiter Leiter Beschaffung) und Prozessmanager (Teamleiter Einkauf), welche Anforderungen hinsichtlich Prozessanalyse und Reporting bestehen. Da es sich hier um die Ersteinführung eines BPM-gestützten Prozesses im Einkaufsbereich handelt, wird zunächst lediglich eine einfache Prozesssteuerung angestrebt. Der Prozessmanager und sein Team benötigen außerdem Informationen darüber, ob die vorgegebene Projektzielsetzung erreicht wird. In späteren Ausbaustufen sollen dann weitere Auswertungsmöglichkeiten ergänzt werden. Deren Bestimmung wird eine Aufgabe des KVP-Prozesses werden. Für dieses Release werden daher folgende Auswertungsmöglichkeiten festgehalten: Monatliche Anzahl an BANF-Vorgängen Durchlaufzeit (max. 10 Tage) Welches Volumen (monetär) wurde je Produktkategorie genehmigt? Alle Informationen sollen für den Einkauf und den Leiter Beschaffung sichtbar sein. Der Leiter Beschaffung erwartet überdies einen monatlichen Bericht mit den wesentlichen Prozesskennzahlen. Diese sollen vom Prozesscontroller in das monatliche Gesamtreporting integriert werden. Der Prozessmanager soll den Bericht vor Abgabe einsehen und kommentieren können. Außerdem soll der Prozessmanager einen Prozessleitstand erhalten, mit dem er eine Übersicht über den aktuellen Prozessstatus erhält. Der Prozessleitstand soll auch vom Prozesscontroller und den Einkäufern eingesehen werden können. Siehe auch IBPM-Vorgehen, Säule E. Prozessanalyse und Reporting. Enterprise BPM Dirk Slama und Ralph Nelius 23

24 5 Arbeitspaket SO-A Verantwortlich für die Erstellung der Ergebnisse dieses Arbeitspakets ist der Lösungsarchitekt. Er arbeitet dazu eng mit dem Prozessanalyst zusammen und schaltet sich in die Workshops mit dem Fachbereich ein. Darüber hinaus konsultiert er bei Bedarf Ansprechpartner aus der IT. Siehe auch IBPM-Vorgehen, SO-A Serviceorientierte Analyse. F. SOA-Komponentisierung (SO-A) Der Lösungsarchitekt macht sich zum Beginn seiner Arbeiten mit dem Arbeitsstand des Prozessanalysten aus dem Arbeitspaket PO-A vertraut. Anschließend klinkt er sich in die Workshops mit den Fachbereichen ein, deren Agenda um für ihn relevante Fragestellungen erweitert werden. Als Einstieg in die serviceorientierte Perspektive hat es sich bewährt, mittels einer einfachen Tabelle eine Ist- und Soll-Darstellung der fachlichen Anwendungslandschaft zu erstellen (SOA Quick-Check). Die Informationen können sowohl von Mitarbeitern aus der IT als auch aus dem Fachbereich abgefragt werden. Hierzu werden fünf Fragen gestellt und gemeinsam die Antworten erarbeitet: 1. Welche Anwendungen spielen bei der Arbeit eine Rolle? 2. Je Anwendung: Welche Daten werden dort bearbeitet? 3. Je Anwendung: Wer arbeitet damit? 4. Je Anwendung: Mit welchem Frontend wird gearbeitet? 5. Je Anwendung: Welche Prozesse werden unterstützt? Außerdem werden bei Bedarf noch ein- oder mehrere Spalten für manuelle Tätigkeiten ergänzt (je eigenständigem Prozess oder größerer Nutzergruppe eine Spalte). Die folgende Abbildung 14 zeigt das Ergebnis im IST für das BANF-Projekt. Aus der Ergebnismatrix des SOA Quick- Checks geht hervor, dass der BANF-Prozess heute komplett manuell abgewickelt wird. Die Einkäufer arbeiten parallel mit dem GGS- und dem ERP-System. Enterprise BPM Dirk Slama und Ralph Nelius 24

25 Abbildung 14: SOA Quick Check IST Im nächsten Schritt wird das Verfahren angewendet, um die SOLL-Sicht zu entwerfen (siehe Abb. 15). Hier wird festgelegt, dass die GGS-Anwendung ersetzt wird (dafür wird ein neues Projekt gestartet) und der BANF-Prozess für Anforderer, Freigeber und Einkäufer komplett auf dem Prozessportal und dem BPMS durchgeführt werden soll. Einige Datenbestände liegen im LDAP und im ERP-System, die auch weitere Prozesse neben der BANF unterstützen. Zusätzlich soll ein existierendes DMS-System zur zentralen Dokumentenablage verwendet werden. Abbildung 15: SOA Quick Check SOLL Enterprise BPM Dirk Slama und Ralph Nelius 25

26 Siehe auch IBPM-Framework, Säule F. SOA-Komponentisierung. G. Frontends und UI-Design (SO-A) Im Themenbereich Frontends und UI-Design besteht in der Analysephase die Option, Use Cases zu erarbeiten, um eine zusätzliche Übersicht über die Erwartungen und Anforderungen der Anwender zu erhalten. Der Lösungsarchitekt für das BANF-Projekt beschreitet diesen Weg, und erarbeitet mit den Anwendern die erwarteten Use Cases. Abbildung 16: Use Cases Einige Aspekte des Use Case-Modells müssen im Design wieder aufgegriffen und gelöst werden. So soll bspw. eine BAnf als Entwurf erstellt, verworfen und wieder aufgerufen werden können. Der Anforderer kann in diesem Modell neue Lieferanten erfassen, die aber entsprechend der fachlichen Anwendungsübersicht im ERP-System angelegt werden müssen hier müssen Prozess und Systeme so gestaltet werden, dass eine funktionierende Lösung herauskommt. Siehe auch IBPM-Framework, Säule G. Frontends und UI-Design. H. Prozesskomponenten (SO-A) In der Säule für Prozesskomponenten legt der Lösungsarchitekt eine erste Version der relevanten Prozessstatus an. Dazu muss er den Standard-Prozessablauf (siehe Säule A. Prozessmodell, PO-A) und die relevanten Business-Objekte (siehe Säule I. Business-Objekte und Backend- Komponenten, SO-A) verstehen. Im vorliegenden Fall liegt der Prozessstatus im Business- Enterprise BPM Dirk Slama und Ralph Nelius 26

27 Objekt Bestellanforderung (BANF). Zur Darstellung genügt eine Tabelle, die die fachlich relevanten Zustände im Standard-Prozessablauf festhält. Typ Standardablauf Prozesstatus BANF Beantragt In fachlicher Prüfung In kaufmänn. Prüfung Bestellt Tabelle 3: Prozessstatus (Analysemodell) Wichtig ist an dieser Stelle auch zu überprüfen, ob die geforderten Analyse- und Reportingfähigkeiten damit abgedeckt werden können (siehe Säule E Prozessanalyse und Reporting, PO-A). Diese Liste wird im Projektverlauf weiter verfeinert werden. Siehe auch IBPM-Framework, Säule H. Prozesskomponenten. I. Business-Objekte und Backend-Komponenten (SO-A) Als nächstes untersucht der Lösungsarchitekt, welche Business-Objekte im Projekt eine Rolle spielen. Diese Information findet er heraus durch eine Analyse der verwendeten Formulare (Papier, Excel) einen Blick auf die Masken bestehender Systeme Gespräche mit Fachbereich und Anwendungsverantwortlichen Für das BANF-Projekt werden folgende sechs Business-Objekte identifiziert: Abbildung 17: Identifizierte Business-Objekte Enterprise BPM Dirk Slama und Ralph Nelius 27

28 Der SOA Quick-Check (siehe Säule F SOA-Komponentisierung, SO-A) gibt an, in welchen Systemen die identifizierten Business-Objekte leben. Im weiteren Projektverlauf werden diese Business-Objekte in ein Datenmodell einfließen. Siehe auch IBPM-Framework, Säule I. Business-Objekte und Backend-Komponenten. J. Technische Architektur und Infrastruktur (SO-A) Im Themenbereich Technische Architektur und Infrastruktur erweitert der Lösungsarchitekt die Vorgaben aus dem Projektantrag um neu gewonnene Erkenntnisse. Dies führt zur folgenden Darstellung: Abbildung 18: Technische Architektur (Analyse) Die Benutzerinformationen für Prozessportal und BPMS sollen einheitlich aus dem LDAP kommen. Darüber hinaus muss die Verwendung der im Aufbau befindlichen Controlling-DB geklärt werden. Zur Integration zwischen BPMS und Backendsystemen soll ein Enterprise Service Bus (ESB) verwendet werden, der ebenfalls bereits im Hause im Einsatz ist. Schließlich ist auch ein Dokumentenmanagementsystem (DMS) aufzubauen und anzubinden. Siehe auch IBPM-Framework, Säule J. Technische Architektur und Infrastruktur. Enterprise BPM Dirk Slama und Ralph Nelius 28

29 6 Arbeitspaket PO-D I Verantwortlich für die Erstellung der Ergebnisse dieses Arbeitspakets ist wiederum der Prozessanalyst, der auch für diesen Aufgabenblock weiterhin auf die tatkräftige Mitarbeit des Fachbereiches angewiesen bleibt und die Ergebnisse mit dem Lösungsarchitekten abstimmen muss. Siehe auch IBPM-Vorgehen, PO-D I Prozessorientiertes fachliches Design. A. Prozessmodell (PO-D I) Der Prozessanalyst verfeinert das Prozessmodell aus der Analysephase in zwei bis drei Workshops mit dem Fachbereich. Auf dieser Ebene verwendet er ein erweitertes Set von BPMN. Im Prozessmodell finden sich viele Aspekte wieder, die in den nachfolgenden Säulen des Arbeitspaketes bearbeitet werden, insbesondere die Prozessrollen (siehe B. Prozessorganisation und Prozessrollen) Entscheidungen zur Modellierung von Prozessen und Aufgaben, bspw. Push- vs. Pull- Design, Nutzung von Task-Listen (siehe C. User Task Management) die Bedarfe an Geschäftsregeln (siehe D. Geschäftsregeln) Die folgenden beiden Abbildungen zeigt das Ergebnis für den BANF-Prozess: Enterprise BPM Dirk Slama und Ralph Nelius 29

30 Abbildung 19: Prozessmodell fachliches Design (Teil 1) Enterprise BPM Dirk Slama und Ralph Nelius 30

31 Abbildung 20: Prozessmodell fachliches Design (Teil 2) Im Vergleich zum Analysemodell ist der Ablauf nun mit einem höheren Detailgrad beschrieben und die Prozessrollen sind weiter ausdifferenziert. Siehe auch IBPM-Framework, Säule A. Prozessmodell. B. Prozessorganisation und Prozessrollen (PO-D I) Hier geht es darum, die Prozessrollen und die Verantwortlichkeiten genauer festzulegen. Hierfür eignet sich eine tabellarische Beschreibung der einzelnen Prozessrollen, wie sie die folgende Abbildung exemplarisch zeigt. Im vorliegenden Projekt muss bspw. geklärt werden, welcher Personenkreis in welchen Ländergesellschaften und Standorten einbezogen werden muss. Enterprise BPM Dirk Slama und Ralph Nelius 31

32 Abbildung 21: Prozessrollen Gemäß Säule B. Prozessorganisation und Prozessrollen trennen wir zwischen Aufbauorganisation und Prozessrollen und innerhalb der Prozessrollen wiederum zwischen expliziter und impliziter Zuordnung. Abb. 22 zeigt die Festlegungen des BANF-Projektes exemplarisch für die Landesgesellschaft Deutschland. Ein Teil der Rollenzuordnungen wird explizit festgelegt. So sollen die Aufgaben der Fachexperten Legal von allen drei Mitarbeitern des Referats in der Zentrale wahrgenommen werden. Für die Bearbeitung der IT-relevanten Aspekte werden zwei Mitarbeiter aus dem IT-Bereich bestimmt. Die Einkäuferrolle übernimmt das dezentrale Beschaffungsteam. In den anderen Landesgesellschaften müssen ähnliche Zuordnungen vorgenommen werden. Die anderen beiden Rollen werden jeweils implizit über eine Regel festgelegt. Anforderer können alle regulären Mitarbeiter der Good Goods Landesgesellschaften sein. Und die Rolle des kaufmännischen Freigebers hängt ab von der Verantwortung für eine Kostenstelle. Enterprise BPM Dirk Slama und Ralph Nelius 32

33 Abbildung 22: Organigramm und Prozessrollen, Landesgesellschaft Deutschland Siehe auch IBPM-Framework, Säule B. Prozessorganisation & -rollen. Enterprise BPM Dirk Slama und Ralph Nelius 33

34 C. User Task Management (PO-D I) Im User Task Management trifft der Prozessanalyst zusammen mit den Prozessstakeholdern aus dem Fachbereich grundlegende Designentscheidungen zu Prozessen und Aufgaben. Relativ schnell wird klar, dass das Thema Kanban im vorliegenden Kontext keine Rolle spielt. Andere Themen werden aber sehr wohl heiß diskutiert. Dazu gehört etwa die Frage, ob die Bearbeitung von Bestellanforderungen durch den Einkauf ohne Tasks erfolgen soll. Das Prozessmodell geht davon aus, dass die BANF über verschiedene Tasks vom fachlichen Freigeber zum kaufmännischen Freigeber und schließlich zum Einkauf weitergeleitet wird. Insbesondere für die Freigeber scheint die Zuteilung der Aufgaben über Task-Listen sehr sinnvoll: Die Freigeber beschäftigen sich wahrscheinlich nur einen sehr kleinen Teil ihrer Arbeitszeit mit Freigaben, daher ist es sinnvoll, ihnen diesbezüglich jeweils explizit eine Aufgabe zuzuteilen, wenn eine Freigabe ansteht. Aus Sicht des Einkaufs sieht dies anders aus: Die Einkäufer beschäftigen sich den größten Teil ihrer Arbeitszeit mit der Bearbeitung von Beschaffungsanträgen. Für die Einkäufer erscheint es natürlicher, wenn sie eine zentrale Liste mit Beschaffungsanträgen zur Verfügung gestellt bekommen, die sie nach verschiedenen Kriterien filtern und sortieren können. Der Standardfilter soll immer die gerade aktuell zu bearbeitenden Beschaffungsanträge in der Liste oben anzeigen. Die Einkäufer bekommen also keine Tasks wie»beschaffungsantrag prüfen«,»beschaffung in Bestellung überführen«etc. in ihrer Task-Liste, sondern sollen sich stattdessen die relevanten Beschaffungsaufträge eigenständig heraussuchen und diese selbstständig bearbeiten. Daraus ergeben sich auch Vorgaben für das UI-Design (siehe G. Frontends und UI-Design). Siehe auch IBPM-Framework, Säule C. User Task Management. D. Geschäftsregeln (PO-D I) Im fachlichen Prozessmodell wurde an zwei Stellen ein Bedarf für Geschäftsregeln identifiziert. Dabei handelt es sich um die Steuerung der fachlichen und der kaufmännischen Freigabe. Die folgende Abb. 23 zeigt diese auf, Der Bedarf für fachliche Bearbeitung und Freigabe hängt ab von der Artikelart. Die kaufmännische Freigabe hängt ab von Artikelart, Bestellvolumen, Budgetplanung und der Position des Anforderers in der Kostenstellenhierarchie. Beides wird in tabellarischer Form spezifiziert. Darüber hinaus muss an dieser Stelle darüber nachgedacht werden, wer die Geschäftsregeln administriert und wie der Freigabeprozess aussieht. Die fachliche Verantwortung für beide Regeltabellen liegt im Finanzbereich beim CFO. Einer seiner Mitarbeiter ist zuständig für den Pflegeprozess. Die Werkzeugfrage wird der Prozessanalyst im Umsetzungsdesign bestimmen, da er hierfür zusammen mit dem Lösungsarchitekt bestimmen muss, wie die Geschäftsregeln technisch umgesetzt werden sollen. Enterprise BPM Dirk Slama und Ralph Nelius 34

35 Abbildung 23: Identifizierte Geschäftsregeln Siehe auch IBPM-Framework, Säule D. Geschäftsregeln. E. Prozessanalyse und Reporting (PO-D I) In der Säule Prozessanalyse und Reporting konkretisiert der Prozessanalyst zusammen mit Prozesseigner, Prozesscontroller und Prozessmanager die Anforderungen aus der Analysephase. Zunächst fragt der Prozessanalyst ab, welche Kennzahlen und Auswertungen für das Prozesscontrolling gebraucht werden. Es bleibt bei den drei Kennzahlen Durchlaufzeit, Anzahl bearbeiteter Vorgänge und Gesamtvolumen genehmigter Bestellanforderungen je Produktkategorie. Für alle Kennzahlen erwarten die Prozessverantwortlichen eine graphische Darstellung mit historisierten Daten. Die folgende Abbildung zeigt eine einfache Skizze, die der Prozessanalyst zusammen mit den Fachbereichsvertretern zur Veranschaulichung in Excel erstellt: Enterprise BPM Dirk Slama und Ralph Nelius 35

36 Abbildung 24: Kennzahlen und graphische Darstellung Ergänzend erstellt der Prozessanalyst ein einfaches analytisches Datenschema, in dem die Kennzahlen und die benötigten Auswertungsdimensionen festgehalten werden. Abbildung 25: Datenschema für Analyse und Reporting Für die Berechnung der Durchlaufzeit müssen weitere Details festgelegt werden, etwa Einschränkung auf landesspezifische Arbeitstage (keine Feiertage) und die Bestimmung von Beginn, Unterbrechung, Wiederaufnahme und Ende im Prozessablauf. Zur Visualisierung greift der Prozess Analyst auf die Process Monitoring-Patterns zurück. Die folgende Abbildung zeigt ein Beispiel. Enterprise BPM Dirk Slama und Ralph Nelius 36

37 Abbildung 26: Kennzahl Durchlaufzeit im Prozessmodell Mit dieser Grundlage können zwei Lösungen beschrieben werden: Analyse: Mit einem Auswertungswerkzeug sollen die Kennzahlen aus Abbildung 25 historisiert ausgewertet und im Stil von Abbildung 24 dargestellt werden können; ein Export nach Excel soll ebenfalls möglich sein; das vorgesehene BPMS verfügt über eine analytische Komponente mit einem Standardauswertungswerkzeug, das dies erlaubt. Reporting: Die Kennzahlen sollen in einen monatlichen Bericht des Prozesscontrollers an den Leiter Beschaffung einfließen. Da das Reporting in Excel erfolgt, sollen die Daten ebenfalls in Excel bereitgestellt werden; der Prozessanalyst fertigt hierfür ebenfalls eine Skizze in Excel an. Danach bespricht sich der Prozessanalyst mit dem Prozessmanager, welche Informationen im Prozessleitstand enthalten sein müssen. Die gemeinsam erarbeitete Lösung sieht eine tabellarische Darstellung vor, in der für die einzelnen Bearbeitungsschritte aggregierte Daten zu Workload, fertig gestellte Aufgaben und Bearbeitungsdauer bereitgestellt werden. Der Beobachtungszeitraum für den Leitstand ist der aktuelle Monat (Monatsbeginn bis zum aktuellen Tagesdatum). Enterprise BPM Dirk Slama und Ralph Nelius 37

38 Abbildung 27:Skizze Prozessleitstand Für die einzelnen Stationen im Prozessablauf werden vom Prozessmanager und den jeweiligen Teamleitern Richtwerte für die Bearbeitungsdauer vorgegeben: Fachliche Freigabe 3 Tage, Kaufmännische Freigabe 3 Tage, Bearbeitung Einkauf 4 Tage. Der Prozessleitstand filtert die laufenden Vorgänge entsprechend, so dass sichtbar wird, welche Anträge im Erwartungszeitraum liegen und welche länger benötigen. Darüber hinaus soll der Prozessleitstand weitere Analysemöglichkeiten bieten: einen Drill-Down hinunter auf Vorgangsebene Änderungen des Beobachtungszeitraums auf vergangene Monate Link zum Analysewerkzeug für erweiterte Such- und Filtermöglichkeiten Siehe auch IBPM-Framework, Säule E. Prozessmonitoring, -analyse und Reporting. Enterprise BPM Dirk Slama und Ralph Nelius 38

39 7 Arbeitspaket SO-D I Im vierten Arbeitspaket Serviceorientiertes Design I (SO-D I) legt der Lösungsarchitekt die Komponenten- und Servicearchitektur fest. Außerdem entwirft ein UI- Designer die benötigten Benutzeroberflächen. Alle Themen müssen eng mit den Arbeiten des Prozessanalysten abgestimmt werden. Siehe auch IBPM-Vorgehen, SO-D I Serviceorientiertes fachliches Design. F. SOA-Komponentisierung (SO-D I) Der Entwurf der Komponenten- und Servicearchitektur erfolgt mit Hilfe einer SOA Map, die den SOA Quick-Check aus der Analyse weiter konkretisiert. Voraussetzungen für die Erstellung der SOA Map sind das fachliche Prozessmodell (siehe A. Prozessmodell, PO-D I) der Bedarf an Geschäftsregeln (siehe D. Geschäftsregeln, PO-D I) die Zuordnung der Business-Objekte zu Backend-Komponenten (siehe I. Business- Objekte und Backenend-Komponenten, SO-D I) die Festlegung, welche Soll-Anwendungen eingesetzt werden (siehe J. Technische Architektur und Infrastruktur, SO-D I) Die Frontends und Komponenten, die in der SOA-Map beschrieben werden, müssen in der Lage sein, den fachlich vorgegebenen Prozessablauf adäquat, d.h. inklusive aller funktionalen und nichtfunktionalen Anforderungen, zu unterstützen. Darüber hinaus sollten die Komponenten den Vorgaben einer Zielarchitektur entsprechen, sofern diese für den zu bebauenden Ausschnitt der Anwendungslandschaft existiert. Da die Good Goods AG erst am Beginn ihrer BPM- und SOA- Strategie steht, steckt die Zielarchitektur für die meisten Domänen noch in ihren Anfängen. In Abstimmung mit dem SOA-Koordinator hält der Lösungsarchitekt folgende Vorgaben fest: Die Domäne Einkauf ist noch nicht beplant; das BANF-Projekt liefert hierfür erste Ergebnisse Enterprise BPM Dirk Slama und Ralph Nelius 39

40 Das ERP-System bleibt unverändert bestehen und ist via Service-Kapselung einzubinden Die Domäne Informationsmanagement ist bereits beplant, erste Komponenten und Services sind implementiert; hier muss die Komponente Dokumentenmanagement mit ihren Serviceoperationen wiederverwendet werden Ausgerüstet mit diesen Vorgaben entwickelt der Lösungsarchitekt für das BANF-Projekt die folgende SOA-Map: Abbildung 28:SOA Map BANF (Fachliches Design) In der SOA-Map sind folgende Design-Entscheidungen enthalten: Frontends: Alle Prozessbeteiligten arbeiten mit einem neuen Beschaffungsportal als Frontend. Die Portalseiten werden durch das BPMS bereitgestellt und in das Intranet- Portal der Good Goods AG integriert. Die Lieferantenpflege durch den Einkauf erfolgt weiterhin im bestehenden ERP Frontend. Prozesskomponenten: Für den BANF-Prozess wird eine neue Prozesskomponente BANF-Prozess erstellt, die die Prozesslogik für die Frontends bereitstellt. Die Imple- Enterprise BPM Dirk Slama und Ralph Nelius 40

41 mentierung erfolgt auf dem BPMS. In einer späteren Ausbauphase wird diese Prozesskomponente den Folgeprozess Bestellung anstoßen. Geschäftsregeln: Die Geschäftsregeln werden mit Hilfe einer neuen logischen Komponente Freigabeermittlung abgebildet. Diese greift auf zwei Basiskomponenten zurück, die die Freigabe- und Unterschriftenregelung kapseln. Letztere werden in der Controlling- DB abgelegt. Die Implementierung der Geschäftsregeln erfolgt mit den Bordmitteln des BPMS. Der Einsatz einer externen Rule Engine ist nicht vorgesehen. Weitere Backend-Komponenten: Für den BANF-Prozessablauf werden noch weitere Basiskomponenten benötigt, die Services bereitstellen. Deren Implementierung erfolgt auf unterschiedlichen Anwendungen: Eine neue Komponente BANF im BPMS, eine neue Komponente ERP Master Data, die einige Services des ERP-Systems kapselt, und die existierende Komponente Dokumentenmanagement auf dem zentralen DMS, die um einen neuen Service für den BANF-Prozess erweitert werden soll. Und schließlich muss für die Aufgabe der Bestellungen noch ein weiterer Service in einer gleichnamigen Komponente des ERP-Systems bereitgestellt werden. Die folgende Tabelle zeigt den Bebauungsbedarf für die einzelnen Komponenten auf: Komponente Typ Domäne Beschreibung Beschaffungsportal Frontend Einkauf Neu zu erstellen ERP Frontend Lieferantenpflege BANF-Prozess Prozess Einkauf Neu zu erstellen Frontend Lieferant vorhanden; kein Änderungsbedarf Freigabeermittluntion Orchestra- Einkauf Neu zu erstellen Unterschriftenregelung Beschaffung Basis Einkauf Neuer Service (=Schnittstelle); Datenablage in Controlling-DB Freigaberegeln Basis Einkauf Neu zu erstellen;: Datenablage in BPMS BANF (BPMS) Basis Einkauf Neu zu erstellen; Datenablage in BPMS Master Data ERP Basis Lieferant Finanzen Basis Dokumentenmanagement Beschaffung Informationsman agement Neue Services (=Schnittstellen); Datenablage in ERP-System Neuer Service (=Schnittstelle); Datenablage in DMS Bestellung Basis Einkauf Neuer Service (=Schnittstelle); Datenablage in ERP-System Tabelle 4: Übersicht Komponenten Enterprise BPM Dirk Slama und Ralph Nelius 41

42 Siehe auch IBPM-Framework, Säule F. SOA-Komponentisierung. G. Frontends und UI-Design (SO-D I) In dieser Säule geht es darum, die in der SOA-Map (siehe F. SOA-Komponentisierung, SO-D I) definierten Frontends graphisch zu entwerfen. In vielen Fällen hergeben sich hier auch Fragen, die im Rahmen des User Task Managements entschieden werden müssen (siehe C. User Task Management, PO-D I). Der UI-Designer setzt sich dazu mit den Vertretern aus dem Fachbereich (Prozessmanager, Prozessmitarbeiter) und dem Projektteam (Prozessanalyst, Lösungsarchitekt) zusammen. Zunächst klärt der UI-Designer, welche Prozessrollen als Prozessbeteiligte und welche als Prozessmitarbeiter einzustufen sind. Erstere müssen stärker durch den Prozess gesteuert werden. Im vorliegen Projekt sind dies die Prozessrollen Anforderer, fachlicher Freigaber und kaufmänn. Freigeber. Diese Gruppen sollen mit Task-Listen arbeiten. Der UI-Designer greift an dieser Stelle auf die BPM-Patterns für Process Portlets zurück. Für alle drei Prozessrollen wird ein Maskendesign Process/BO benötigt. Die kaufmännischen Freigeber sollen überdies mit einer Kompaktvariante arbeiten und bei Bedarf zur detaillierten Darstellung wechseln können. Für die Einkäufer als erfahrene Prozessmitarbeiter soll ein Prozesscockpit mit einem fachlichen Prozessmonitor bereitgestellt werden, das ihnen mehr Freiheiten bei der Bearbeitung gibt. Die folgende Abbildung zeigt die Ergebnisse dieser Überlegungen: Abbildung 29: Process/BO-Masken und Prozessmonitor im Prozessablauf Enterprise BPM Dirk Slama und Ralph Nelius 42

43 Der Entwurf der Maske erfolgt in drei Schritten: Handzeichnung in einem Workshop, Überarbeitung mit Visio, danach Validierung in einem zweiten Workshop. Die folgenden Abbildungen zeigen Ausschnitte der Ergebnisse. Abbildung 30: Process/BO-Maske Bestellanforderung Enterprise BPM Dirk Slama und Ralph Nelius 43

44 Abbildung 31: Process/BO-Maske Bestellanforderung kompakt Für die Bearbeiter im Einkauf wird als Teil des Prozesscockpits unter anderem ein fachlicher Prozessmonitor definiert, über man zu den einzelnen Bestellanforderungen navigieren kann: Abbildung 32: Entwurf für Prozesscockpit Siehe auch IBPM-Framework, Säule G. Frontends und UI-Design. H. Prozesskomponenten (SO-D I) In der Säule Prozesskomponente überarbeitet der Lösungsarchitekt die Prozessstatustabelle entsprechend der detaillierteren Erkenntnisse aus dem fachlichen Prozessmodell (siehe A. Prozessmodell, PO-D I). Das Ergebnis zeigt die folgende Tabelle: Typ Prozesstatus BANF Bestellposition Standardablauf In Bearbeitung Nicht in Bestellung überführt Beantragt In Bestellung überführt Enterprise BPM Dirk Slama und Ralph Nelius 44

45 Typ Prozesstatus BANF Bestellposition In fachlicher Prüfung In kaufmänn. Prüfung (1-3) In Bearbeitung durch Einkauf Tlw. bestellt Abgeschlossen Sonderfälle Verworfen Verworfen In Überarbeitung Abbildung 33: Prozessstatus (Fachliches Design) Wichtig ist an dieser Stelle auch zu überprüfen, ob die geforderten Analyse- und Reportingfähigkeiten (siehe E. Prozessanalyse und reporting, PO-D I) damit abgedeckt werden können. Siehe auch IBPM-Framework, Säule H. Prozesskomponenten. I. Business-Objekte und Backend-Komponenten (SO-D I) Ausgehend vom fachlichen Prozessmodell (siehe A. Prozessmodell, PO-D I) und den in der Analysephase identifizierten Business-Objekten (siehe I. Business-Objekte und Backend- Komponenten, SO-A) erstellt der Lösungsarchitekt ein Datenmodell für die BANF-Lösung. Dazu klinkt er sich wiederum die Workshops mit dem Fachbereich ein und zieht ggf. weitere IT- Experten für die betroffenen Anwendungssysteme zu Rate. Das Ergebnis zeigt die folgende Abbildung: Enterprise BPM Dirk Slama und Ralph Nelius 45

46 Abbildung 34: Datenmodell für die BANF-Lösung (Bestellung hier nur konzeptionell, nicht im Scope) Die Datenhoheit für Business-Objekte liegt bei logischen Komponenten, die den Zugriff durch ihre Serviceoperationen ermöglichen. Die Implementierung erfolgt durch Anwendungen, die dann als Servicegeber auftreten. Im nächsten Schritt bestimmt daher der Lösungsarchitekt, in welchen logischen Komponenten und Anwendungen die Business-Objekte geführt werden. Enterprise BPM Dirk Slama und Ralph Nelius 46

47 Abbildung 35: Zuordnung von Business-Objekten zu logischen Komponenten Für die Business-Objekte Bestellanforderung und Bestellposition ist die logische Komponente BANF zuständig, die bislang nicht existiert. Die Dokumentenablage erfolgt im Dokumentenmanagementsystem (DMS), für das in der Unternehmensarchitektur bereits eine gleichnamige Komponente vorhanden ist. Aufgrund der vorgegebenen Lösungsarchitektur werden einige weitere verwendete Business-Objekte im ERP-System residieren. Dazu werden die zwei logischen Komponenten Bestellung und ERP Master Data gebildet. ERP Master Data kapselt den Zugriff auf die Business-Objekte Kostenstelle, Artikeltyp, Mengeneinheit und Lieferant. Die Überlegungen aus dieser Säule sind in die SOA Map der Säule F. SOA-Komponentisierung eingeflossen. Siehe auch IBPM-Framework, Säule I. Business-Objekte und Backend-Komponenten. J. Technische Architektur und Infrastruktur (SO-D I) An dieser Stelle klärt der Lösungsarchitekt noch einige Detailfragen, die sich aus dem fachlichen Design ergeben. Die detaillierte Spezifikation erfolgt um Umsetzungsdesign. Siehe auch IBPM-Framework, Säule J. Technische Architektur und Infrastruktur. Enterprise BPM Dirk Slama und Ralph Nelius 47

Integrierte BPM- Projektmethodik (IBPM) Dirk Slama, inubit AG (dirk.slama@inubit.com) Ralph Nelius, Deutsche Post AG (ralph.nelius@deutschepost.

Integrierte BPM- Projektmethodik (IBPM) Dirk Slama, inubit AG (dirk.slama@inubit.com) Ralph Nelius, Deutsche Post AG (ralph.nelius@deutschepost. Integrierte BPM- Projektmethodik (IBPM) Dirk Slama, inubit AG (dirk.slama@inubit.com) Ralph Nelius, Deutsche Post AG (ralph.nelius@deutschepost.de) Vorstellung Dirk Slama inubit AG - integrating your business

Mehr

Inhalt. Teil I Grundlagen 1

Inhalt. Teil I Grundlagen 1 xiii Teil I Grundlagen 1 1 Einleitung 3 1.1 Aufbau des Buches........................................ 3 1.2 Der lange Weg von Six Sigma zu XPDL........................ 5 1.3 Werkzeuge des Business-BPM................................

Mehr

Prozessorientierte Applikationsund Datenintegration mit SOA

Prozessorientierte Applikationsund Datenintegration mit SOA Prozessorientierte Applikationsund Datenintegration mit SOA Forum Business Integration 2008, Wiesbaden Dr. Wolfgang Martin unabhängiger Analyst und ibond Partner Business Integration 1998 2008 Agenda Business

Mehr

Realisierung der Anbindung an den Handelsplatz Koeln.de Leitfaden zur Projektplanung bei Lieferanten

Realisierung der Anbindung an den Handelsplatz Koeln.de Leitfaden zur Projektplanung bei Lieferanten Handelsplatz Köln.de Leitfaden zur Projektplanung bei en Realisierung der Anbindung an den Handelsplatz Koeln.de Leitfaden zur Projektplanung bei en Autor: Christoph Winkelhage Status: Version 1.0 Datum:

Mehr

BPM im Kontext von Unternehmensarchitekturen. Konstantin Gress

BPM im Kontext von Unternehmensarchitekturen. Konstantin Gress BPM im Kontext von Unternehmensarchitekturen Konstantin Gress Agenda 1 Worum geht s BPM, EA und SOA im Überblick 2 Link zwischen EA und BPM 3 Link zwischen SOA und BPM 4 Wie spielt das zusammen? 5 Q&A

Mehr

Workflowmanagement. Business Process Management

Workflowmanagement. Business Process Management Workflowmanagement Business Process Management Workflowmanagement Workflowmanagement Steigern Sie die Effizienz und Sicherheit Ihrer betrieblichen Abläufe Unternehmen mit gezielter Optimierung ihrer Geschäftsaktivitäten

Mehr

Geschäftsprozessimplementierung mit BPMN, ADF und WebCenter

Geschäftsprozessimplementierung mit BPMN, ADF und WebCenter Geschäftsprozessimplementierung mit BPMN, ADF und WebCenter Johannes Michler PROMATIS software GmbH Ettlingen Schlüsselworte Geschäftsprozess, Horus, SOA, BPMN, ADF, WebCenter Einleitung Die Umsetzung

Mehr

Business Partner Profil

Business Partner Profil Business Partner Profil Christian Ketterer Merowingerstraße 28, 85609 Aschheim Email: C.Ketterer@yahoo.de Tel: +49 89 90 77 36 34 Mobil: +49 1522 95 99 259 Homepage: www.http://christianketterer.eu Tätigkeitsschwerpunkte

Mehr

Dipl. Inf. Ali M. Akbarian

Dipl. Inf. Ali M. Akbarian Dipl. Inf. Ali M. Akbarian 2012 Einführung Globalisierung, Innovation und Kundenzufriedenheit sind auch in Zukunft die wichtigsten Herausforderungen der Unternehmen. Diese Herausforderungen verlangen:

Mehr

Inhaltsverzeichnis. Jakob Freund, Bernd Rücker. Praxishandbuch BPMN 2.0 ISBN: 978-3-446-42986-4. Weitere Informationen oder Bestellungen unter

Inhaltsverzeichnis. Jakob Freund, Bernd Rücker. Praxishandbuch BPMN 2.0 ISBN: 978-3-446-42986-4. Weitere Informationen oder Bestellungen unter Jakob Freund, Bernd Rücker Praxishandbuch BPMN 2.0 ISBN: 978-3-446-42986-4 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-42986-4 sowie im Buchhandel. Carl Hanser Verlag,

Mehr

Supermann-Prinzip REConf Schweiz 2010

Supermann-Prinzip REConf Schweiz 2010 Supermann-Prinzip REConf Schweiz 2010 Thomas Kordt, CIGM Oktober 2010 Agenda Supermann-Prinzip MAN Nutzfahrzeuge - Kurzvorstellung Prozessübersicht Die Prozesse Beispiel: Demand Prozess Look & feel Rahmenbedingungen

Mehr

Prozess- und Service-Orientierung im Unternehmen mehr als Technologie

Prozess- und Service-Orientierung im Unternehmen mehr als Technologie Prozess- und Service-Orientierung im Unternehmen mehr als Technologie Presse Talk CeBIT 2007 Dr. Wolfgang Martin Analyst, ibond Partner, Ventana Research Advisor und Research Advisor am Institut für Business

Mehr

Praxishandbuch BPMN 2.0

Praxishandbuch BPMN 2.0 Jakob Freund Bernd Rücker Praxishandbuch BPMN 2.0 4., aktualisierte Auflage HANSER Inhaltsverzeichnis Vorwort XI 1 Einführung 1 1.1 Business Process Management 1 1.1.1 Definition 1 1.1.2 BPM in der Praxis

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

PROJEKTNAVIGATOR - effektives und effizientes Steuern von Projekten -

PROJEKTNAVIGATOR - effektives und effizientes Steuern von Projekten - PROJEKTNAVIGATOR - effektives und effizientes Steuern von Projekten - Stand: Mai 2013 KLAUS PETERSEN Was ist der Projektnavigator? Der Projektnavigator ist ein wikibasierter Leitfaden zur einheitlichen

Mehr

Praxisforum BPM und ERP. Integration BPM und ERP in der Praxis. Ein Reality Check!

Praxisforum BPM und ERP. Integration BPM und ERP in der Praxis. Ein Reality Check! Praxisforum BPM und ERP Integration BPM und ERP in der Praxis. Ein Reality Check! Prof. Dr. Ayelt Komus Prof. Dr. Andreas Gadatsch Koblenz, 29.11.2011 - Es gilt das gesprochene Wort - Fachhochschule Koblenz

Mehr

Inhaltsverzeichnis. Jakob Freund, Bernd Rücker. Praxisbuch BPMN 2.0 ISBN: 978-3-446-42455-5. Weitere Informationen oder Bestellungen unter

Inhaltsverzeichnis. Jakob Freund, Bernd Rücker. Praxisbuch BPMN 2.0 ISBN: 978-3-446-42455-5. Weitere Informationen oder Bestellungen unter Jakob Freund, Bernd Rücker Praxisbuch BPMN 2.0 ISBN: 978-3-446-42455-5 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-42455-5 sowie im Buchhandel. Carl Hanser Verlag, München

Mehr

Prozessmanagement: neue Perspektiven für Krankenkassen

Prozessmanagement: neue Perspektiven für Krankenkassen Prozessmanagement: neue Perspektiven für Krankenkassen Dr. Jens Hinkmann, Markus Jankowski Neuss, 5. November 2013 1 Unternehmen, Produkte, Dienstleistungen Das der Wertschöpfungskette ist die wesentliche

Mehr

Business Rules Ansatz It s a long way... 21. Januar 2008

Business Rules Ansatz It s a long way... 21. Januar 2008 Business Rules Ansatz It s a long way... 21. Januar 2008 Patrice Witschi SI-SE Fachtagung 2008 Business Rules Agenda Einleitung Geschichte Erste Schritte mit Business Rules Projekte mit der Business Rule

Mehr

Integration mit Service Repositories zur SOA Governance

Integration mit Service Repositories zur SOA Governance Integration mit Service Repositories zur SOA Governance Nürnberg, 10.11.2009 I N H A L T 1. SOA Governance 2. Service Repository 3. Modelle und Service Repository 4. Modell-Driven SOA I N H A L T 1. SOA

Mehr

Praxishandbuch BPMN 2.0

Praxishandbuch BPMN 2.0 Jakob Freund Bernd Rücker Praxishandbuch BPMN 2.0 2., aktualisierte Auflage HANSER Inhaltsverzeichnis 1 Einführung 1 1.1 Business Process Management 1 1.1.1 Definition 1 1.1.2 BPM in der Praxis 2 1.1.3

Mehr

Projektmanagement mit hyscore

Projektmanagement mit hyscore Projektmanagement mit hyscore Webbasiert Projekte und Massnahmen erfolgreich planen und durchführen Version 4.5 Ausgabe 1.3 März 2010 Seite 1 Inhalt Projektmanagement mit hyscore... 3 Direkter Zugriff

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

CWA Flow. Prozessmanagement und Workflow-Management. Workflow- und webbasierte Lösung. Per Browser einfach modellieren und automatisieren

CWA Flow. Prozessmanagement und Workflow-Management. Workflow- und webbasierte Lösung. Per Browser einfach modellieren und automatisieren CWA Flow Prozessmanagement und Workflow-Management Per Browser einfach modellieren und automatisieren Workflow- und webbasierte Lösung Workflow- und webbasierte Lösung Webbasierte Prozessmanagement und

Mehr

BPMN2.0 Geschäftsprozesse effizient gestalten. Ganz klar persönlich.

BPMN2.0 Geschäftsprozesse effizient gestalten. Ganz klar persönlich. BPMN2.0 Geschäftsprozesse effizient gestalten Ganz klar persönlich. Geschäftsprozesse im Wandel morgen gestern Dokumentverwaltung Vertragsablage Problemmanagement heute Sicherung der Compliance Qualitätsgesichertes

Mehr

Geschäftsprozesse und Entscheidungen automatisieren schnell, flexibel und transparent. Die BPM+ Edition im Überblick

Geschäftsprozesse und Entscheidungen automatisieren schnell, flexibel und transparent. Die BPM+ Edition im Überblick Geschäftsprozesse und Entscheidungen automatisieren schnell, flexibel und transparent. Die BPM+ Edition im Überblick Software Innovations BPM BRM Die Software-Suite von Bosch Alles drin für besseres Business!

Mehr

Claus Quast Business Productivity Specialist Microsoft GmbH. Christian Fillies Geschäftsführer Semtation GmbH

Claus Quast Business Productivity Specialist Microsoft GmbH. Christian Fillies Geschäftsführer Semtation GmbH Claus Quast Business Productivity Specialist Microsoft GmbH Christian Fillies Geschäftsführer Semtation GmbH Agenda Einführung Einstieg in das Thema Prozesse vs. Workflow Prozessportallösung Toolbestandteile

Mehr

Studie Serviceorientierte Architektur (SOA) in Deutschland - Branchen im Vergleich: Banken & Versicherungen,, Transport & Logistik Stellenwert der IT im Unternehmen Strategisch 21.4 27.6 35.6 64.0 W ertbeitrag

Mehr

1 Geschäftsprozessmodellierung in der Zollverwaltung

1 Geschäftsprozessmodellierung in der Zollverwaltung 1 Geschäftsprozessmodellierung in der Zollverwaltung 1.1 Ausgangslage Aufbau und Abläufe der Bundeszollverwaltung waren geprägt von einer stark grenzbezogenen Aufgabenstellung. Die gesellschaftlichen,

Mehr

Multiprojektmanagement an der TIB Ein Erfahrungsbericht. Dr. Debora D. Daberkow 104. Bibliothekartag in Nürnberg 27. Mai 2015

Multiprojektmanagement an der TIB Ein Erfahrungsbericht. Dr. Debora D. Daberkow 104. Bibliothekartag in Nürnberg 27. Mai 2015 Multiprojektmanagement an der TIB Ein Erfahrungsbericht Dr. Debora D. Daberkow 104. Bibliothekartag in Nürnberg 27. Mai 2015 Motivation Die Ausgangssituation Das Umfeld von Bibliotheken befindet sich im

Mehr

e-serve UP&SM Consult

e-serve UP&SM Consult , Stöckackerstrasse 30, CH-4142 Münchenstein Ph:++41 (0) 61 413 15 00, Fax:++41 (0) 61 413 15 01 http://www.e-serve.ch, crm@e-serve.ch e-serve UP&SM Consult UP&SM: UNIFIED PROCESS & SOFTWARE MANAGEMENT

Mehr

Klausur 1 Wirtschaftsinformatik LE 1 bis LE 6. 9. November 2012

Klausur 1 Wirtschaftsinformatik LE 1 bis LE 6. 9. November 2012 Klausur 1 Wirtschaftsinformatik LE 1 bis LE 6 9. November 2012 Allgemeines zur Klausur: Schreibmaterial: Verwenden Sie weder Bleistift noch rotes Schreibzeug. Hilfsmittel: Für Fremdsprachige ist ein Fremdwörterbuch

Mehr

Leitfaden zum Erstellen der Projektarbeit

Leitfaden zum Erstellen der Projektarbeit Leitfaden zum Erstellen der Projektarbeit an der Höheren H http://www.slideshare.net www.slideshare.net/rudolpdo/vorgehensweise vorgehensweise-projektarbeit Was ist gefordert? Projektmanagement Unterlagen

Mehr

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Andreas Ditze MID GmbH Kressengartenstraße 10 90402 Nürnberg a.ditze@mid.de Abstract: Data Lineage

Mehr

Projekt KPI System für die BS ENERGY. SAP Versorgertage Münster 12.11.2015 Bastian Schäfer & Florian Schlüfter

Projekt KPI System für die BS ENERGY. SAP Versorgertage Münster 12.11.2015 Bastian Schäfer & Florian Schlüfter Projekt KPI System für die BS ENERGY SAP Versorgertage Münster 12.11.2015 Bastian Schäfer & Florian Schlüfter Agenda Wozu ein KPI Dashboard? KPI Projekt bei BS ENERGY Projektziel Umsetzungsvorgehen Umsetzungsergebnisse

Mehr

Camunda BPM für den Kfz-Versichererwechsel

Camunda BPM für den Kfz-Versichererwechsel Camunda BPM für den Kfz-Versichererwechsel Ablösung eines Cobol Mainframe-Systems Verdopplung der bisherigen Automatisierungsquote www.camunda.com »Im Ergebnis wird eine höhere Prozesstransparenz und -standardisierung

Mehr

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung Kapitel B Vorgehensmodelle Inhaltsverzeichnis 1 B Vorgehensmodell... 3 1.1 Welche Vorgehensmodelle sind

Mehr

Smart Enterprise Solutions

Smart Enterprise Solutions 23.06.2015 Smart Enterprise Solutions Neue Möglichkeiten durch Kreativität und Technik Smart Enterprise Solutions GmbH Stuttgarter Straße 8 D -75179 Pforzheim T +49 7231 1454647-00 F +49 7231 1454647-99

Mehr

Praxishandbuch BPMN. Incl. BPMN 2.0. von Jakob Freund, Bernd Rücker, Thomas Henninger. 1. Auflage. Hanser München 2010

Praxishandbuch BPMN. Incl. BPMN 2.0. von Jakob Freund, Bernd Rücker, Thomas Henninger. 1. Auflage. Hanser München 2010 Praxishandbuch BPMN Incl. BPMN 2.0 von Jakob Freund, Bernd Rücker, Thomas Henninger 1. Auflage Hanser München 2010 Verlag C.H. Beck im Internet: www.beck.de ISBN 978 3 446 41768 7 Zu Leseprobe schnell

Mehr

BPMN2.0 Geschäftsprozesse effizient gestalten. Ganz klar persönlich.

BPMN2.0 Geschäftsprozesse effizient gestalten. Ganz klar persönlich. BPMN2.0 Geschäftsprozesse effizient gestalten Ganz klar persönlich. Theorie BPMN2.0 Business Prozess Model and Notation ist eine grafische Spezifikationssprache und stellt Symbole zur Verfügung, mit denen

Mehr

Die digitale Projektakte bei der Otto Group Solution Provider (OSP) Dresden GmbH

Die digitale Projektakte bei der Otto Group Solution Provider (OSP) Dresden GmbH Die digitale Projektakte bei der Otto Group Solution Provider (OSP) Dresden GmbH Michaela Witt Otto Group Solution Provider Dresden GmbH Fon: +49 (0)351 49723 0 Fax: +49 (0)351 49723 119 Web: www.ottogroup.com

Mehr

digital business solution SharePoint SAP Integration

digital business solution SharePoint SAP Integration digital business solution SharePoint SAP Integration 1 So geht s. SAP ist das bekannteste und verbreitetste ERP-System und Rückgrat für die Abwicklung Ihres täglichen Kerngeschäfts. Microsoft SharePoint

Mehr

aseaco Central Master Data Management Framework - Whitepaper -

aseaco Central Master Data Management Framework - Whitepaper - aseaco Central Master Data Management Framework - Whitepaper - Autor: Udo Zabel Das aseaco Central Master Data Management Framework (CMDMF) ermöglicht erfolgreiches kollaboratives Stammdatenmanagement

Mehr

Organisationsentwicklung. Organisationsentwicklung / J.Schoch

Organisationsentwicklung. Organisationsentwicklung / J.Schoch Organisationsentwicklung Projektmanagement Ist ein in sich geschlossener Aufgabenkomplex (zeitlich klar abgegrenzt) Umfasst alle willensbildenden und durchsetzenden Aktivitäten im Zusammenhang mit der

Mehr

Business Partner Profil

Business Partner Profil Business Partner Profil Christian Ketterer Merowingerstraße 28, 85609 Aschheim Email: C.Ketterer@yahoo.de Tel: +49 89 90 77 36 34 Mobil: +49 1522 95 99 259 Homepage: www.http://christianketterer.eu Tätigkeitsschwerpunkte

Mehr

Des Weiteren gibt es Anpassungsprogrammierer, die reine Projektanpassungen umsetzen, eventuell Mitarbeiter für Datenübernahmen oder Schulungen.

Des Weiteren gibt es Anpassungsprogrammierer, die reine Projektanpassungen umsetzen, eventuell Mitarbeiter für Datenübernahmen oder Schulungen. ERP Einführung 1. Vorgehen, Terminplan, Projektrealisierung 1.1 Kickoff Termin Bei diesem Termin wird das Projektmanagement definiert. Dies bedeutet, dass das Projektteam auf beiden Seiten skizziert wird.

Mehr

Toolgestützte Prozessdokumentation. Prozessorientiertes E-Government, 28.10.2005 Joel Meir, jmeir@csc.com, +41 31 998 46 46

Toolgestützte Prozessdokumentation. Prozessorientiertes E-Government, 28.10.2005 Joel Meir, jmeir@csc.com, +41 31 998 46 46 Toolgestützte Prozessdokumentation Prozessorientiertes E-Government, 28.10.2005 Joel Meir, jmeir@csc.com, +41 31 998 46 46 Wir bieten unseren Kunden End-to-End Lösungen an Consulting Systems Integration

Mehr

Jump Project. Softwarelösungen für professionelles Projektmanagement

Jump Project. Softwarelösungen für professionelles Projektmanagement Jump Project Softwarelösungen für professionelles Projektmanagement Jump Project Office Übersichtliche Dokumentenstruktur und schneller Zugriff auf alle wichtigen Funktionen. Steuern Sie Ihre Projekte

Mehr

Schnittstellen Zusammenspiel von PM, PDM, CRM und ERP sowie Best Practices. Marc Becker 3. IT-Expertenforum 30.6.2011

Schnittstellen Zusammenspiel von PM, PDM, CRM und ERP sowie Best Practices. Marc Becker 3. IT-Expertenforum 30.6.2011 Zusammenspiel von PM, PDM, CRM und ERP sowie Best Practices Marc Becker 3. IT-Expertenforum 30.6.2011 2011 2009 INNEO Solutions GmbH Marc Becker Zahlen und Fakten Birmingham Hannover Hamburg Berlin o o

Mehr

PMI Munich Chapter 21.04.2008

PMI Munich Chapter 21.04.2008 Projektmanagement im Rahmen einer IT-Infrastruktur- Standardisierung mit internationalen Teams Christoph Felix PMP, Principal Project Manager, Microsoft Deutschland PMI Munich Chapter 21.04.2008 Agenda

Mehr

MIS-Navigator Für die optimale Versorgung mit allen wichtigen Informationen.

MIS-Navigator Für die optimale Versorgung mit allen wichtigen Informationen. -Navigator Für die optimale Versorgung mit allen wichtigen Informationen. Projektmanagement Informations- Datenbank n n Kennzahlen Schulung NAVIGATOR Visualisierung/ Cockpits s Management Beratung Consulta

Mehr

Ansätze zur Synchronisation von Enterprise Architecture Management, Prozessmanagement und SAP. Ralf Ackermann Daimler AG, ITM MBC Powertrain

Ansätze zur Synchronisation von Enterprise Architecture Management, Prozessmanagement und SAP. Ralf Ackermann Daimler AG, ITM MBC Powertrain Ansätze zur Synchronisation von Enterprise Architecture Management, Prozessmanagement und SAP Ralf Ackermann Daimler AG, ITM MBC Powertrain Agenda Ausgangslage EAM Tool-Landschaft bei Daimler planningit

Mehr

Workflow Monitoring basierend auf den SemTalk Services. Semtation GmbH

Workflow Monitoring basierend auf den SemTalk Services. Semtation GmbH Workflow Monitoring basierend auf den SemTalk Services Semtation GmbH Inhalt Zielsetzung Seite 3 Visualisierung Seite 4 Technische Information Seite 5 Implementierung Überblick Seite 9 Hintergrund Seite

Mehr

2.1 Ist-Anwendungslandschaften... 65 2.2 Programme zur Gestaltung von Anwendungslandschaften

2.1 Ist-Anwendungslandschaften... 65 2.2 Programme zur Gestaltung von Anwendungslandschaften xiii Teil I Ein typisches Projekt 1 1 Mit Christoph Kolumbus reisen 3 1.1 Prolog........................................... 3 1.2 Episode 1 Zuhören............................... 4 1.3 Episode 2 Orientierung

Mehr

Verwertung und Wirtschaftlichkeit. Projektmanagement. Konzeptentwicklung. Technologische/Technische Klärung

Verwertung und Wirtschaftlichkeit. Projektmanagement. Konzeptentwicklung. Technologische/Technische Klärung Zielsetzung und Einsatz: Die Checkliste dient als Hilfsmittel für die Gestaltung und Umsetzung einer Voruntersuchung. Die hier vorliegende ist auf die Abwicklung vergleichsweise komplexer Voruntersuchungen

Mehr

Grundlagen für den erfolgreichen Einstieg in das Business Process Management SHD Professional Service

Grundlagen für den erfolgreichen Einstieg in das Business Process Management SHD Professional Service Grundlagen für den erfolgreichen Einstieg in das Business Process Management SHD Professional Service Der BPM-Regelkreis Im Mittelpunkt dieser Übersicht steht die konkrete Vorgehensweise bei der Einführung

Mehr

Die Entwicklung von KPI als ein zentrales Element der Gesamtbanksteuerung

Die Entwicklung von KPI als ein zentrales Element der Gesamtbanksteuerung Die Entwicklung von KPI als ein zentrales Element der Gesamtbanksteuerung Auf die richtigen Key Performance Indicators (KPI) kommt es an Seit dem spektakulären Zusammenbruch der US-Investmentbank Lehman

Mehr

Raber+Märcker Business Intelligence Lösungen und Leistungen

Raber+Märcker Business Intelligence Lösungen und Leistungen Business Intelligence Raber+Märcker Business Intelligence Lösungen und Leistungen www.raber-maercker.de 2 LEISTUNGEN Business Intelligence Beratungsleistung Die Raber+Märcker Business Intelligence Beratungsleistung

Mehr

Integriertes Dokumentenmanagement. www.pbu-cad.de info@pbu-cad.de

Integriertes Dokumentenmanagement. www.pbu-cad.de info@pbu-cad.de Integriertes Dokumentenmanagement Dokumente webbasiert und integriert verwalten RuleDesigner bietet eine modular aufgebaute, integrierte und bereichsübergreifende Umgebung für das Dokumentenmanagement

Mehr

Agenda. Vorstellung Business Process Management und IT Umsetzungsbeispiel

Agenda. Vorstellung Business Process Management und IT Umsetzungsbeispiel Vom Prozess zur IT Agenda Vorstellung Business Process Management und IT Umsetzungsbeispiel Das Unternehmen Seit etwa 30 Jahren Anbieter von Business Communication Lösungen Planung und Realisierung von

Mehr

Enterprise Architecture Management für Krankenhäuser. Transparenz über die Abhängigkeiten von Business und IT

Enterprise Architecture Management für Krankenhäuser. Transparenz über die Abhängigkeiten von Business und IT Enterprise Architecture Management für Krankenhäuser Transparenz über die Abhängigkeiten von Business und IT HERAUSFORDERUNG Gestiegener Wettbewerbsdruck, höhere Differenzierung im Markt, die konsequente

Mehr

Produkt und Methode. SIRIUSlogic 4.0 in der Praxis. SIRIUS Consulting & Training AG. www.sirius-consult.com. SIRIUS Consulting & Training AG

Produkt und Methode. SIRIUSlogic 4.0 in der Praxis. SIRIUS Consulting & Training AG. www.sirius-consult.com. SIRIUS Consulting & Training AG Produkt und Methode SIRIUSlogic 4.0 in der Praxis SIRIUS Consulting & Training AG www.sirius-consult.com SIRIUSlogic 4.0 Warum ein weiteres Prozessmanagement Werkzeug? Motivation Was muß das Tool leisten

Mehr

sycat IMS GmbH Business Process Management Fon (0511) 84 86 48 200 Fax (0511) 84 86 48 299 Mail info@sycat.com www.sycat.com

sycat IMS GmbH Business Process Management Fon (0511) 84 86 48 200 Fax (0511) 84 86 48 299 Mail info@sycat.com www.sycat.com sycat IMS GmbH Business Process Management Fon (0511) 84 86 48 200 Fax (0511) 84 86 48 299 Mail info@sycat.com www.sycat.com 1 QUALITÄT IM DIALOG Business Process Management Historie 1985 Dr. Binner Unternehmensberatung

Mehr

CrossmedialeProzesse zum erfolgreichen e-publishing. 4. Medienforum 20. September 2012 Heike Beyer-Wenzel

CrossmedialeProzesse zum erfolgreichen e-publishing. 4. Medienforum 20. September 2012 Heike Beyer-Wenzel CrossmedialeProzesse zum erfolgreichen e-publishing 4. Medienforum 20. September 2012 Heike Beyer-Wenzel Mediennutzung im Jahre 2012 Seite 2 Business Challenges Vor welchen Herausforderungen stehen Verlage?

Mehr

Requirements Management Wissensmanagement für und mit Anforderungen

Requirements Management Wissensmanagement für und mit Anforderungen Requirements Management Wissensmanagement für und mit Anforderungen Barbara Paech Forum ITK-Industrie Industrie trifft Forschung in ViSEK, 28.10.02 IESE Fraunhofer Institut Experimentelles Software Engineering

Mehr

2. BPM Symposium am 28. November 2013 in Iserlohn

2. BPM Symposium am 28. November 2013 in Iserlohn 2. BPM Symposium am 28. November 2013 in Iserlohn BPM für den Mittelstand IYOPRO Projekte, Erfahrungsberichte und Trends BPM & Projektmanagement Wie kann BPM in methodisch strukturierten Projekten erfolgreich

Mehr

3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process.

3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1996 Philippe Kruchten: Rational Unified Process Produkt der Firma Seit 2002 Teil des IBM Konzerns Objektorientiertes

Mehr

Systemintegration mit Service Orientierten Architekturen. Frank Zenker (fzenker@c-a-s.de)

Systemintegration mit Service Orientierten Architekturen. Frank Zenker (fzenker@c-a-s.de) Systemintegration mit Service Orientierten Architekturen Frank Zenker (fzenker@c-a-s.de) System Integration Level 0: No Integration Folie 2 System Integration Level 1 : Human Integration Folie 3 System

Mehr

Textbausteine und Vorlagen mit System

Textbausteine und Vorlagen mit System Betriebliche Praxis Textbausteine und Vorlagen mit System Word, Textbausteine, Dokumentvorlagen, Dokumentenmanagement-System (DMS), Freigabe-Workflow Die Erstellung von geschäftlichen Schriftstücken, die

Mehr

IT-Sicherheit: Und was sagen die Geschäftsprozesse dazu?

IT-Sicherheit: Und was sagen die Geschäftsprozesse dazu? IT-Sicherheit: Und was sagen die Geschäftsprozesse dazu? Risiken und Chancen moderner Geschäftsprozessarchitekturen Frank Hüther Bereichsleiter System Integration MT AG MT AG managing technology 1994:

Mehr

1. PMA Kongress 29.11.2012

1. PMA Kongress 29.11.2012 1. PMA Kongress 29.11.2012 «Prozess-Tools im Vergleich» Markus Fischer, Mitglied der GL Markus Fischer Mitglied der GL 46 Jahre Betriebsökonom HWV 3 Jahre Unternehmensberatung, Controlling 15 Jahre Business

Mehr

VCP Prozessberatung - sicher zum Ziel

VCP Prozessberatung - sicher zum Ziel VCP Prozessberatung - sicher zum Ziel Themen wie Category Management, Forecasting & Replenishment, Inventurdifferenzen am POS sowie neue leistungsfähige Technologien stellen Handelsunternehmen vor große

Mehr

Modellbasierte Business Intelligence in der Praxis. Nürnberg, 10.11.2009

Modellbasierte Business Intelligence in der Praxis. Nürnberg, 10.11.2009 Modellbasierte Business Intelligence in der Praxis Nürnberg, 10.11.2009 I N H A L T 1. Warum Modelle für Business Intelligence (BI)? 2. Inhalte von Datenmodellen für BI 3. Inhalte von Prozessmodellen 4.

Mehr

Zum Beispiel ein Test

Zum Beispiel ein Test Zum Beispiel ein Test Torsten Mandry OPITZ CONSULTING Deutschland GmbH Gummersbach Schlüsselworte Beispiele, Specification by Example, Akzeptanztest, Lebende Spezifikation, Java Einleitung Beispiele helfen

Mehr

Success Story. Einführung des SAP Berechtigungs konzeptes in ausgewählten Bereichen beim Photovoltaikunternehmen

Success Story. Einführung des SAP Berechtigungs konzeptes in ausgewählten Bereichen beim Photovoltaikunternehmen Success Story Einführung des SAP Berechtigungs konzeptes in ausgewählten Bereichen beim Photovoltaikunternehmen Q-Cells SE Q-Cells SE Q-Cells SE zählt zu den führenden Photovoltaikunternehmen weltweit.

Mehr

Übergreifendes Prozessmanagement für die Bundeswehr. Ltd RegDir Peter Scheid, BAIUDBw ZA I 6, RefLtr ÜPM Bw 25. Januar 2016

Übergreifendes Prozessmanagement für die Bundeswehr. Ltd RegDir Peter Scheid, BAIUDBw ZA I 6, RefLtr ÜPM Bw 25. Januar 2016 für die Ltd RegDir Peter Scheid,, RefLtr ÜPM Bw 25. Januar 2016 Dauerhafte Transparenz ist eine Grundvoraussetzung für die zukunftsorientierte Weiterentwicklung der Bw. Das Übergreifende Prozessmanagement

Mehr

OUTSOURCING ADVISOR. Analyse von SW-Anwendungen und IT-Dienstleistungen auf ihre Global Sourcing Eignung. Bewertung von Dienstleistern und Standorten

OUTSOURCING ADVISOR. Analyse von SW-Anwendungen und IT-Dienstleistungen auf ihre Global Sourcing Eignung. Bewertung von Dienstleistern und Standorten Outsourcing Advisor Bewerten Sie Ihre Unternehmensanwendungen auf Global Sourcing Eignung, Wirtschaftlichkeit und wählen Sie den idealen Dienstleister aus. OUTSOURCING ADVISOR Der Outsourcing Advisor ist

Mehr

Phase I: Angebotsvorbereitung

Phase I: Angebotsvorbereitung 1 Phase I: Angebotsvorbereitung Ziele der Phase I / Angebotsvorbereitung Kontakt herstellen erwartungen an das Angebot erteln Auftrag spezifizieren Rahmenbedingungen feststellen Beziehung aufbauen/vertrauensbasis

Mehr

DURCHGÄNGIGE SAP CHANGE- UND RELEASE-PROZESSE EINFACH UMSETZEN

DURCHGÄNGIGE SAP CHANGE- UND RELEASE-PROZESSE EINFACH UMSETZEN THEGUARD! SMARTCHANGE CHANGE PROCESS DURCHGÄNGIGE SAP CHANGE- UND RELEASE-PROZESSE EINFACH UMSETZEN DURCHGÄNGIGE SAP CHANGE- UND RELEASE-PROZESSE EINFACH UMSETZEN THEGUARD! SMARTCHANGE I CHANGE PROCESS

Mehr

1 Phase «Initialisierung»

1 Phase «Initialisierung» 1.1 Übersicht Projektanmeldung Projektportfolio Projektrandbedingungen Projekt vorbereiten Projektantrag Projekthandbuch Projektplan Zurückweisung Projektauftrag Projektportfolio Status Abbruch Phase Voranalyse

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

e-business im Rahmen des Supplier Relationship Management (SRM).

e-business im Rahmen des Supplier Relationship Management (SRM). e-business im Rahmen des Supplier Relationship Management (SRM). Inhalt. Informationen zu SRM bei TE. Überblick & Zusammenhänge. Die SRM-Anwendungen (e-applikationen) bei TE. Support für Sie. Ihr Weg ins

Mehr

20 Minutes to get in flow

20 Minutes to get in flow 20 Minutes to get in flow Dr. Carsten Ritterskamp, Sebastian Wiemer 16. CrossMediaForum München, 10. Juli 2014 28.07.2014 Effektive Publikationsprozesse benötigen IT-Systeme. 28.07.2014 2 16. CrossMediaForum:

Mehr

UNTERNEHMENSARCHITEKTUR

UNTERNEHMENSARCHITEKTUR UNTERNEHMENSARCHITEKTUR 21c ng und die nächste Generation des Prozessmanagements. 1 AGENDA icraft Effektive Unternehmensarchitektur 21c ng - der Enabler! Drei Partner - eine Lösung! 2 Die icraft GmbH ist

Mehr

E-MAIL-KONVERTIERUNG LEVIGO SOLUTIONS DAY 24.10.2013, 13:45 14:15 WAS PASSIERT MIT NICHT KONVERTIERBAREN ANHÄNGEN?

E-MAIL-KONVERTIERUNG LEVIGO SOLUTIONS DAY 24.10.2013, 13:45 14:15 WAS PASSIERT MIT NICHT KONVERTIERBAREN ANHÄNGEN? E-MAIL-KONVERTIERUNG WAS PASSIERT MIT NICHT KONVERTIERBAREN ANHÄNGEN? LEVIGO SOLUTIONS DAY 24.10.2013, 13:45 14:15 J. MÄSTLING LEVIGO SOLUTIONS GMBH J. CLARYSSE CENIT AG LEVIGO ANSATZ & LEITFAFDEN Präsentationsfolien

Mehr

Implementierung sicher und schnell

Implementierung sicher und schnell im Überblick SAP Services SAP Business One SAP Accelerated Implementation Program Herausforderungen Implementierung sicher und schnell Mit Methode sicher zum Ziel Mit Methode sicher zum Ziel Ihr Unternehmen

Mehr

Prozessoptimierung. und. Prozessmanagement

Prozessoptimierung. und. Prozessmanagement Prozessoptimierung und Prozessmanagement Prozessmanagement & Prozessoptimierung Die Prozesslandschaft eines Unternehmens orientiert sich genau wie die Aufbauorganisation an den vorhandenen Aufgaben. Mit

Mehr

Process Streamlining:

Process Streamlining: Process Streamlining: Geschäftsprozesse in globalen Business Software-Lösungen Dr. Frank Schönthaler Michael Mohl PROMATIS software GmbH Ettlingen/Baden Schlüsselworte Business Process Streamlining, Multinationaler

Mehr

Andrea Grass & Dr. Marcus Winteroll oose Innovative Informatik GmbH. Geschäftsprozessmanagement und Agilität geht das zusammen?

Andrea Grass & Dr. Marcus Winteroll oose Innovative Informatik GmbH. Geschäftsprozessmanagement und Agilität geht das zusammen? Andrea Grass & Dr. Marcus Winteroll oose GmbH Geschäftsprozessmanagement und Agilität geht das zusammen? Agenda I. Wozu eigentlich BPM? II. Vorgehen und Rollen im abpm III. Methoden und Techniken IV. Resümee

Mehr

Referenzprozessmodell zur erfolgreichen Durchführung von CRM - Projekten

Referenzprozessmodell zur erfolgreichen Durchführung von CRM - Projekten Referenzprozessmodell zur erfolgreichen Durchführung von CRM - Projekten Eine große Anzahl von CRM- Projekten scheitert oder erreicht die gesetzten Ziele nicht. Die Ursachen hierfür liegen oftmals in der

Mehr

ITS.Design&Management GmbH. Short Story. Project Primer Process. Nutzen und Ziele. Copyright its.d&m GmbH

ITS.Design&Management GmbH. Short Story. Project Primer Process. Nutzen und Ziele. Copyright its.d&m GmbH ITS.Design&Management GmbH Short Story Project Primer Process Copyright its.d&m GmbH Hinweis zu Nutzungsrechten ITS.Design&Management GmbH Alle Rechte an dieser Dokumentation, insbesondere das Recht der

Mehr

Leseprobe. Joachim Drees, Conny Lang, Marita Schöps. Praxisleitfaden Projektmanagement. Tipps, Tools und Tricks aus der Praxis für die Praxis

Leseprobe. Joachim Drees, Conny Lang, Marita Schöps. Praxisleitfaden Projektmanagement. Tipps, Tools und Tricks aus der Praxis für die Praxis Leseprobe Joachim Drees, Conny Lang, Marita Schöps Praxisleitfaden Projektmanagement Tipps, Tools und Tricks aus der Praxis für die Praxis ISBN: 978-3-446-42183-7 Weitere Informationen oder Bestellungen

Mehr

Prozessunterstützung durch BPR-, BPM- und Workflow-Systeme

Prozessunterstützung durch BPR-, BPM- und Workflow-Systeme Prozessunterstützung durch BPR-, BPM- und Workflow-Systeme 27. April 2004 München Brigitte Stuckenberger Business Process Management verbindet technische und fachliche Sicht auf Geschäftsprozesse Unternehmensberatungen,

Mehr

Product Lifecycle Management

Product Lifecycle Management Product Präsentation der Funktionen von PLM-Systemen Stud.-Ing. Ansprechpartner: Dr. -Ing. Harald Prior Fachhochschule Dortmund Sommersemester 2013 Inhaltsverzeichnis Seite 1 Seite 2 Seite 3 Seite 4 Seite

Mehr

CWA Flow. CWA Flow - 8D-Report. Die flexibel konfigurierbare Software. Freie Definition von Formularen und Prozessen

CWA Flow. CWA Flow - 8D-Report. Die flexibel konfigurierbare Software. Freie Definition von Formularen und Prozessen CWA Flow - 8D-Report Web- und workflowbasierte Software für Reklamationen, Probleme und 8D-Report CWA Flow Module für Qualitätsmanagement und Prozessmanagement Die flexibel konfigurierbare Software Freie

Mehr

gallestro BPM - weit mehr als malen...

gallestro BPM - weit mehr als malen... Ob gallestro das richtige Tool für Ihr Unternehmen ist, können wir ohne weitere rmationen nicht beurteilen und lassen hier die Frage offen. In dieser rmationsreihe möchten wir Ihre Entscheidungsfindung

Mehr

Abrechnung von Dienstleistungen und Fertigmeldungen

Abrechnung von Dienstleistungen und Fertigmeldungen Dieses Infoblatt beschreibt die von uns empfohlenen kaufmännischen Standardvorgänge für Softwarehersteller und Dienstleister im Bereich IT. Bestandteil sind unsere Module ERP, PROJEKT sowie als Erweiterung

Mehr

SERVICE SUCHE ZUR UNTERSTÜTZUNG

SERVICE SUCHE ZUR UNTERSTÜTZUNG SERVICE SUCHE ZUR UNTERSTÜTZUNG VON ANFORDERUNGSERMITTLUNG IM ERP BEREICH MARKUS NÖBAUER NORBERT SEYFF ERP SYSTEME Begriffsbestimmung: Enterprise Resource Planning / Business Management Solution Integrierte

Mehr

Fallstudie!I: Geschäftsprozessoptimierung (GPO), Controllingsystem und ERP-Softwareauswahl für ein Personennah- und Güterverkehrsunternehmen

Fallstudie!I: Geschäftsprozessoptimierung (GPO), Controllingsystem und ERP-Softwareauswahl für ein Personennah- und Güterverkehrsunternehmen Fallstudie!I: Geschäftsprozessoptimierung (GPO), Controllingsystem und ERP-Softwareauswahl für ein Personennah- und Güterverkehrsunternehmen Nürnberg, Hamburg im Juni 2011 Ausgangssituation und Aufgabenstellung

Mehr

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 348

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 348 DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN Nr. 348 Konzeption eines Projektvorgehensmodells für die Business-Intelligence-Strategieberatung

Mehr