Referenzprozessmodell für die Einführung eines Campus-Management-Systems

Transkript

1 Referenzprozessmodell für die Einführung eines Campus-Management-Systems Hannover Referenten: Jan Bührig (HIS)

2 Gliederung Motivation Von der Prozesslandkarte zur Softwarelösung. Ziel des Referenzprozessmodells. Bestandteile des HIS- Referenzprozessmodells Vorgehensmodell: OOGPM Notation: UML Konvention: HIS -Ebenenmodell Das HIS- Referenzprozessmodell im Einführungsprojekt Einführung mit dem HIS- Referenzprozessmodell Kommunikation in den GPM-Phasen Ausblick: Brückenschlag zu ITIL 2

3 Motivation Geschäftsprozesse der Hochschule HIS-GX/QIS Hochschul-IT relevante GP Hochschul-IT relevante GP HISinOne 3

4 Von der Prozesslandkarte zur Softwarelösung. 4

5 Ziel des Referenzprozessmodells 5

6 Geschäftsprozesse als Teil des HIS Referenzmodells Das HIS Referenzmodell wird u.a. folgende Elemente enthalten: Muster-Geschäftsprozesse für das Campus-, Forschungs- und Ressourcen-Management, IT-Systemprozesse (von HISinOne und ggf. ergänzenden Systemen), Standard-Abbildung der Muster- Geschäftsprozesse auf die IT-Systemprozesse. 6

8 Bestandteile des HIS Referenzmodells Notation: UML Vorgehensmodell: OOGPM Konvention: HIS - Ebenenmodell HIS Referenzprozessmodell 8

9 OOGPM als Vorgehensmodell zur GPM HIS-Vorgehensmodell wurde in Anlehnung an die OOGPM entwickelt (Oestereich et al.,2003). Reduzierung auf die nötigsten Arbeitsschritte und Beschreibungselemente. Das HIS-Vorgehensmodell hat das Ziel möglichst alle Anwendungsfälle (mit den möglichen Varianten) des Modellierungsfokus zu erfassen und zu beschreiben. 9

10 Modellelemente OOGPM-HIS Fachdesign Geschäftsprozesse Systemprozesse Geschäftsanwendungsfälle (Business Use Cases) Geschäftssystem IT- System Systemanwendungsfälle (System Use Cases) Aktionen u. (Business-)Objekte Aktionen u. Objekte 10

11 Vorgehensmodell OOGPM-HIS ======== WICHTIG: Glossar führen ======== Modellierungsfokus festlegen Organisationseinheiten modellieren Geschäftspartner identifizieren GAF aktiver Geschäftspartner identifizieren weitere unterstützende GAF identifizieren Geschäftsprozesse definieren Geschäftsprozess dokumentieren GAF beschreiben + GAF Abläufe modellieren SAF identifizieren Systemprozesse definieren Systemprozesse dokumentieren SAF beschreiben + SAF Abläufe modellieren Mapping GP/SP HIS und Hochschule Hochschule und HIS HIS 11

13 Auswahl der Modellierungssprache Anforderung OOGPM ARIS (EPK) Picture BPMN Anwendbar für Org. Typ HS Anwendbar Anwendbar Anwendbar Anwendbar Geeignet für alle HS Typen Alle Eher große Verwaltungs orientiert Ablauf orientiert Einsatz für OE Systemnah (ganzheitlich) GP Ablauf (ganzheitlich) Public Management Workflow orientiert GPM Integration Teilbereich System Gesamte Prozessicht Verwaltungs-sicht Teilbereich Workflows Aufbau Referenzmodell Sehr gut geeignet Gut geeignet Weniger geeignet Weniger geeignet 13

14 Diagrammtypen der UML 2.0 (nach Jeckel et al.,2004) 14

15 Notationsübersicht 15

17 Ebenen Referenzprozessmodell Ebene 1: Prozesslandkarte Modellierungsfokus Ziele benennen Prozesslandkarte Ebene 2: Geschäftsanwendungsfälle (GAF) eines Geschäftsprozesses Geschäftsanwendungsfälle und Systemanwendungsfälle darstellen Akteure und Rollen darstellen Nur GAF die in Ebene 3 verwendet werden und nur Association Beziehungen Ebene 3: Fachliche Abfolge GP/GAF GAF in eine fachliche Abfolgebeziehung überführen GP Frage: Was muss ich tun um das gesetzte Ziel zu erreichen? Keine Partitionen und nur call behaviours Ebene 4: Workflow GP Frage: Wie erreiche ich mein gesetztes Ziel? Ablauf in Partitionen und besteht möglichst nur aus Aktionen Ein Mapping auf die Systemprozesse durch <<trace>> (Systempartition unten) Ebene 5: Systemanwendungsfall Die direkte Interaktion zwischen dem Benutzer und dem System (Systempartition oben) Der SAF ist zeitlich kohärent und hat festgelegte ein- und Ausgangszustände 17

19 Prozessdesign mit dem HIS Referenzprozessmodell Ist- Aufnahme Soll-Design Soll- Konzept Realisierung 19

20 Kommunikation in den GPM-Phasen Planung GPM Schulung zum Vorgehensmodell, der Notation, HIS Konventionen, Tool und dem Referenzprozessmodell. Ist-Analyse Vorstellung der Referenzprozesse und Systemdemonstration als Hintergrundwissen für die Prozessaufnahme. Prozessdesign (Soll-Konzeption) Soll-Konzept Abstimmung Abgleich der Hochschulprozesse die systemseitig unterstützt werden sollen mit dem Referenzprozessmodell. HIS prüft Realisierbarkeit der Soll-Prozesse und die Hochschule stimmt die Soll-Prozesse ab. Implementierung Soll-Konzept Kontinuierliches Prozessmanagement Einführung der Software anhand des Hochschulspezifisch angepassten Referenzprozessmodells. Änderungen im Referenzprozessmodell werden publiziert (Good Practices, Weiterentwicklungen, neue Anforderungen, usw.). 20

21 Ausblick: Brückenschlag zu ITIL Geschäftsprozesse der Hochschule Hochschul-IT relevante GP ITIL Design Paradigmenwechsel: Funktionssicht zur Prozesssicht. Systemanwendungsfälle stellen Services dar. Rollen und Rechte werden festgelegt. HISinOne 21

22 Für Rückfragen Jan Bührig

23 Backup Folien 23

24 Grundsätze ordnungsmäßiger Modellierung Grundsatz der Richtigkeit Voraussetzung für ein qualitativ hochwertiges Modell ist, dass es den zu repräsentierenden Sachverhalt korrekt wiedergibt. Grundsatz der Relevanz Es sollen nur die Sachverhalte modelliert werden, die für den zu Grunde liegenden Modellierungszweck relevant sind. Grundsatz der Wirtschaftlichkeit Modellierungsaktivitäten stehen in einem angemessenen Kosten-Nutzen-Verhältnis. Grundsatz der Klarheit Abhängig vom Modellnutzer hat ein Modell einen adäquaten Grad an intuitiver Lesbarkeit aufzuweisen. Grundsatz der Vergleichbarkeit Mehrere Modelle die nebeneinander existieren, müssen vergleichbar sein. Grundsatz des systematischen Aufbaus Dieser Grundsatz hat seine Notwendigkeit in der Darstellung eines Sachverhalts aus unterschiedlichen Sichten, die zur Reduktion dessen Komplexität gebildet werden. 24

25 Nutzen des Referenzmodells Transparenzschaffung Hochschule: Kann anhand des Referenzprozessmodells zuordnen, welche Prozesse durch die Software unterstützt werden. HIS: Erkennt die Hochschulstruktur und die Anforderungen an die Software beim Übertrag der Hochschulprozesse in das Referenzmodell. Verbesserte Problem- und Potenzialidentifikation Hochschule: Bewusste Auseinandersetzung der Prozessverantwortlichen mit den Abläufen; wirkt wie ein Katalysator für Prozessverbesserungen. HIS: Probleme und Potentiale zeigen sich bereits im Prozessdesign und nicht erst in der Einführung oder im Betrieb. Kommunikationsmedium für "good practices". Aktzeptanzschaffung Hochschule und HIS: Prozessmodelle schaffen eine einheitliche Dikussionsgrundlage. Alle beteiligten Akteure werden in die Entwicklung einbezogen. Koplexitätsreduktion und -beherrschung Hochschule: Das RPM liefert einen Rahmen für die Prozessmodellierung in Hinblick auf die relevanten Prozesse, die Detailtiefe und den Modellierungsfokus. HIS: Es lassen sich die Prozesse abgrenzen, die für die Entwicklung, die Einführung und den laufenden Betrieb relevant sind. Vereinfachung der Kommunikation Hochschule und HIS: Die grafische Aufbereitung eines Problembereichs unter berücksichtigung klarer Regeln vereinfacht die Nutzbarkeit. Erhöhte Vergleichbarkeit von Ergebnissen Hochschule und HIS: Standardisierung von Modellierungstechniken und das Schaffen von Konventionen ermöglicht eine projektübergreifende Zusammenarbeit. 25

26 UML als Metamodell zur Geschäftsprozessmodellierung Die Unified Modeling Language (UML) ist eine grafische Modellierungsprache und Notation zur Spezifikation, Konstruktion, Visualisierung und Dokumentation von Modellen für Softwaresysteme. Bei der UML handelt es sich um eine Sprache und Notation zur Modellierung, sie ist keine Methode! UML2 Notation, Werkzeuge: Astah (kostenfreie Community Version, Professional kostenpflichtig). 26

27 Ebene 1: Prozesslandkarte Modellierungsfokus bestimmen Ziele definieren 27

28 Ebene 2: Geschäftsanwendungsfälle (GAF) eines Geschäftsprozesses Beziehung zwischen GAF und Akteuren eines GP darstellen. Diagrammtyp: Use Case Diagramm mit Paket, GAF und Akteuren. 28

29 Ebene 3: Fachliche Abfolge GP/GAF GP/ GAF in fachliche Abfolgebeziehung bringen. Was ist zur Zielerreichung zu tun? Diagrammtyp: Aktivitätsdiagramm ohne Partitionen, mit Call- Behaviours als Aktionen. 29

30 Ebene 4: Workflow Ablauf der einzelnen GAF und ggf. Mapping auf SAF. Wie wird das Ziel erreicht? Diagrammtyp: Aktivitätsdiagramm mit Partitionen, Aktionen und ggf. Call-Behaviours zur Darstellung von Systemanwendungsfällen. 30

31 Ebene 5. Systemanwendungsfall Direkte Interaktion zwischen dem Benutzer und dem System. SAF ist zeitlich kohärent und hat festgelegte Ein- und Ausgangszustände Diagrammtyp: Aktivitätsdiagramm mit Partitionen und Aktionen. 31

32 Ebene 6: System Konkrete Umsetzung des SAF im Programm mit Informationen zur Konfiguration. 32

33 Prozessdesign mit dem HIS Referenzprozessmodell Vorbereitung Design Phase: Analysephase ist abgeschlossen Ist-Zustand ist ausreichend dokumentiert Mind. HISinOne relevante Prozesse Möglichst in Anlehnung an das Referenzprozessmodell Systemlandschaft wurde berücksichtigt Klare Beschreibung der Ziele und des Gestaltungsbereichs Restriktionen und Rahmenbedingungen für das Design liegen vor (Restriktion HISinOne) Ist-Prozesse wurden erfasst, gewichtet und priorisiert Schwächen wurden ermittelt Welche Prozesse sollen neu gestaltet werden und in welcher Reihenfolge 33

34 Prozessdesign mit dem HIS Referenzprozessmodell Prozessdesign durchführen: Den neuen Prozess entwerfen Basierend auf Anforderungen der Hochschule Unter Berücksichtigung des Referenzprozessmodells Aufgaben im neuen Prozess festlegen IT Sicht: Rollen und Rechte OE Sicht an Hochschule Die Schnittstellen zwischen funktionalen Organisationseinheiten definieren Anhand von Ist-Soll Vergleichen Unterschiede zum bestehenden Prozess deutlich machen Sinnvolle Prozesskennzahlen einführen Die nötigen IT-Systeme planen (Mapping) Die Prozesseinführung planen 34

35 Prozessdesign mit dem HIS Referenzprozessmodell Abstimmung durchführen: Der Soll-Prozess muss auf mehreren Ebenen abgestimmt werden: Technische Realisierbarkeit seitens der HIS (Customizing oder auch Entwicklung). Zustimmung der Hochschule. 35

36 Mapping auf das System Hochschul- SOLL Referenzprozessmodell 36