PRE409 / PRE410
Zusammenfassung
Was ist ein Geschäftsprozess?
Eine Folge von zusammenhängenden Aktivitäten mit betriebswirtschaftlichem Ziel. Hat einen definierten Start (auslösendes Ereignis) und ein definiertes Ende (Ergebniszustand). Verwendet Ressourcen: Personal, Maschinen, Informationen.
Warum Prozessmodellierung?
- Dokumentation existierender Prozesse (z.B. für ISO-Zertifizierungen, Schulungen)
- Analyse und Optimierung – Engpässe finden, Redundanzen eliminieren
- Neugestaltung – Business Process Reengineering
- Simulation – z.B. Personalbedarfsplanung
- Vorbereitung der Automatisierung – ERP-Einführung, RPA
Was man wissen will – 5 Fragen
- Was wird gemacht? (Aktivitäten)
- Wer ist verantwortlich? (Organisationseinheit)
- Welche Entscheidungen werden getroffen? (Verzweigungen)
- Wie lange dauert ein Prozessdurchlauf? (Durchlaufzeit)
- Wer ist von einer Änderung betroffen? (Change Impact)
Prozessarchitektur – 3 Ebenen
| Ebene | Granularität | Zweck |
|---|---|---|
| Prozesslandschaft | Grobsicht | Überblick aller Hauptprozesse (Vogelperspektive) |
| Prozessmodell (EPK) | Mittlere Detailtiefe | Abläufe eines Prozesses darstellen |
| Arbeitsanweisung / Use Case | Feinstgranular | Einzelne Schritte für Ausführende |
BPM-Lifecycle (Prozesslebenszyklus)
Kontinuierlicher Kreislauf – ähnlich einer Autowartung:
Warum braucht es eine Aktivität VOR XOR / ODER?
In der Funktion vor dem Konnektor wird festgelegt, welche Wege gegangen werden. Nur eine Funktion kann entscheiden – ein Ereignis ist passiv und kann nicht entscheiden.
Beim UND-Konnektor gehen immer alle Wege → keine Entscheidung nötig → keine Aktivität zwingend davor erforderlich.
Mehrere Endereignisse
| Situation | Konnektor am Ende |
|---|---|
| BEIDE Endereignisse treten ein | UND-Konnektor |
| NUR EINES der Endereignisse tritt ein | XOR-Konnektor |
Die erweiterte EPK ergänzt die Symbole um Organisationseinheiten, Informationsobjekte und IT-Systeme. Diese werden ausschließlich bei Aktivitäten/Funktionen angehängt – niemals bei Ereignissen oder Konnektoren!
Vor der Modellierung muss ein Prozess identifiziert und abgegrenzt werden. Dabei klärt man:
- Prozessname – eindeutige Bezeichnung
- Startereignis – was löst den Prozess aus?
- Endereignis – wann ist der Prozess abgeschlossen?
- Prozesskunde – intern oder extern?
- Output – was ist das Ergebnis des Prozesses?
- Schnittstellen – zu welchen anderen Prozessen gibt es Verbindungen?
- Prozessverantwortlicher (Process Owner) – wer ist zuständig?
Das Agile Manifest beschreibt 4 Werte. Die linke Seite wird höher geschätzt, die rechte Seite ist auch wichtig:
| Höher geschätzt (links) | Auch wichtig (rechts) |
|---|---|
| Individuen und Interaktionen | Prozesse und Werkzeuge |
| Funktionierende Software | Umfassende Dokumentation |
| Zusammenarbeit mit dem Kunden | Vertragsverhandlung |
| Reagieren auf Veränderung | Befolgen eines Plans |
Scrum ist das am weitesten verbreitete agile Framework. Es basiert auf iterativer Entwicklung in Sprints und definiert klare Rollen, Artefakte und Events.
Product Backlog
Liste aller Anforderungen (User Stories / Tasks) mit Prioritäten. Hohe Priorität erhalten Elemente, die am wichtigsten sind und hohe Kundenzufriedenheit sicherstellen. Wird kontinuierlich aktualisiert.
Im adaptierten SPG: Tasks statt User Stories. Ein Task muss innerhalb eines Sprints erledigt werden.
Sprint Backlog
Die im Sprint Planning ausgewählten Tasks für den aktuellen Sprint. Enthält das Sprint-Ziel und die Aufgabenverteilung im Team. Zeigt was zu tun ist und wie es erledigt wird.
User Stories
Anforderungen aus Nutzerperspektive, formuliert als: „Als [Rolle] möchte ich [Funktion], um [Nutzen]."
- „Als Arzt möchte ich die Anamnese speichern können, um bei zukünftigen Behandlungen diese einzusehen."
- „Als Anästhesist möchte ich Reanimationsdaten per WEB Interface nachbearbeiten können, um nicht zeitkritische Daten hinzuzufügen."
Task Board
Visuelle Übersicht aller Tasks – für alle Teammitglieder sichtbar. Typische Spalten: Product Backlog | Sprint Backlog | In Progress | Done. Macht den Projektstand transparent und steuerbar.
Burn Down Chart
Diagramm, das den verbleibenden Aufwand über die Zeit zeigt. Zeigt ob das Sprint-Ziel noch erreichbar ist. (Thema der 5. Klasse)
Sprint
Fest vorgegebene Zeitdauer (Time Box) von maximal einem Monat, in der definierte Tasks abgearbeitet werden. Agiles Projektmanagement mit Scrum ist ein iterativer Prozess aus mehreren Sprints bis das Produkt fertiggestellt ist.
Daily Scrum
Tägliches, maximal 15-minütiges Standup-Meeting. Jeder beantwortet:
- Was habe ich seit dem letzten Daily Scrum gemacht?
- Was mache ich bis zum nächsten Daily Scrum tun?
- Was behindert mich bei meiner Arbeit?
Der Scrum Master greift Hindernisse auf und hilft sie zu beseitigen. Alle haben das Sprint-Ziel im Blick.
Sprint Review
Meeting am Ende jedes Sprints. Das Team stellt Ergebnisse (Teil-Produkt) dem Product Owner und Stakeholdern vor. Es wird geprüft ob Tasks auf DONE stehen → Abnahme der Sprint-Ergebnisse. Product Backlog wird aktualisiert/angepasst.
Sprint Retrospektive
Findet zwischen Sprint Review und nächstem Sprint Planning statt. Reflexion über Zusammenarbeit, Prozesse, Kommunikation und Werkzeuge. Was soll im nächsten Sprint verbessert werden? Unterstützt einen Lernprozess.
Sprint Planning
Planung vor Beginn eines Sprints: Welche Tasks werden erledigt? Von wem? Sprint-Ziel definieren. Tasks im Taskboard verschieben und bei Bedarf genauer spezifizieren. Klärt: Was wird entwickelt? Wie wird es erledigt?
| Element | Scrum (original) | SPG adaptiert |
|---|---|---|
| Backlog-Einträge | User Stories | Tasks |
| Sprint-Dauer | Max. 1 Monat | 3 Schulwochen |
| Daily Scrum | Täglich, 15 Min. | 1x/Woche, erste 15–20 Min. PRE-Unterricht |
| Protokoll | Optional | Pflicht, Abgabe in Moodle mit Taskboard-Screenshot |
| Sprint Review | Intern | Präsentation im Klassenverband (Beamer), keine umfangreichen Präsentationen |
| Retrospektive | Nach Sprint Review | Nach allen Präsentationen, Protokoll + Diskussion mit Lehrer |
Adaptiertes Controlling
- Ressourcen: Soll/Ist-Stunden pro Sprint und Person (Zeiterfassung)
- Leistungen: Definierte Ergebnisse am Ende des Sprints (im Board)
- Termine: Ende jedes Sprints = Meilenstein → Überprüfung der Tasks
- PMA-Vorlage verwenden. Labels für Phasen (PM, Analyse, Design, …)
IT-Governance
Besteht aus Führung, Organisationsstrukturen und Prozessen, die sicherstellen, dass die IT die Unternehmensstrategie und -ziele unterstützt.
Kein einheitliches Off-the-shelf-Framework vorhanden! Die zwei anerkanntesten Frameworks sind ITIL und COBIT.
Gute Governance erzeugt gute Prozesse → gute Entscheidungen → gute IT-Systeme.
IT-Compliance
Sicherstellen, dass alle für die Unternehmens-IT relevanten Rechtsnormen (Gesetze, Verordnungen, Regelungswerke von Behörden) nachweislich eingehalten werden. Ergänzend auch Richtlinien und Selbstverpflichtungen.
IT-Compliance ist Teil der IT-Governance und steht in enger Beziehung zum IT-Risikomanagement.
Beispiel: DSGVO (Datenschutz-Grundverordnung)
Eine Sammlung von Best Practice Publikationen für IT-Servicemanagement. Ca. 5 Bücher mit ~1800 Seiten plus Zusatzartikel. Fokus auf interne IT-Prozesse, Service Lifecycle und Kunden.
ITIL Life Cycle – 5 Phasen
Prozessbeschreibung in ITIL
Ausführlich (10–30 Seiten, viele Grafiken) mit: Überblick, Ziele/Aufgaben/Nutzen, Begriffe und Grundlagen, Prozesse, Aktivitäten, Rollen, Key-Performance-Indikatoren (KPIs), Herausforderungen.
International anerkanntes, prozessorientiertes, geschäftsziel-fokussiertes Framework für die Evaluation der IT-Funktionen einer Organisation.
- Besitzer: ISACA (www.isaca.org)
- Zertifizierung / Audit: Reifegradmessungen durch zertifizierte Auditoren
- Basis für Audits und Compliance-Prüfungen
Der COBIT-Würfel
„IT-Ressourcen werden von IT-Prozessen gemanaged, um IT-Zielsetzungen zu erreichen, die den Geschäftsanforderungen entsprechen."
Drei Dimensionen: IT-Ressourcen → IT-Prozesse → IT-Ziele / Geschäftsanforderungen
Trennung Governance vs. Management in COBIT
| Governance | Management |
|---|---|
| Legt Ziele fest, bewertet und überwacht (EDM: Evaluate, Direct, Monitor) | Plant, baut, betreibt und überwacht die Aktivitäten zur Zielerreichung |
Prozessbeschreibung in COBIT 5
Einheitlich für alle Prozesse (3–5 Seiten) mit: Beschreibung und Zweck, IT- und prozessbezogene Ziele mit Metriken, RACI-Charts für Subprozesse, Inputs/Outputs, Verweise auf andere Best Practices.
Bereich DSS (Deliver, Service and Support): DSS01–DSS06 – beschäftigt sich mit Betrieb und Unterstützung von IT-Services.
International anerkannter Standard für Service-Management-Systeme (SMS). Formaler und strukturierter Rahmen mit spezifischen Anforderungen, die Organisationen einhalten müssen, um eine Zertifizierung zu erhalten.
Hat im Gegensatz zu ITIL sehr spezifische und relativ rigide Anforderungen, während ITIL einen „Best Practice"-Ansatz umsetzt.
Implementierung nach dem PDCA-Zyklus (Plan-Do-Check-Act).
| Kriterium | ITIL | COBIT | ISO 20000 |
|---|---|---|---|
| Was ist es? | Best-Practice-Publikationen für IT-SM | Framework für Governance & Management | Internationaler Standard für IT-SM-Anforderungen |
| Umfang | ~1800 Seiten (5 Bücher) | 95 Seiten Basis + 230 Seiten Ergänzung | 36 Seiten zum Thema |
| Marktwahrnehmung | Fokus auf IT-Prozesse, Service Lifecycle, Kunden | Basis für Audits & Compliance | Grundlage für Zertifizierung |
| Von wem genutzt? | Unternehmen mit internen/externen IT-Services | Interne IT-Abteilungen großer Unternehmen | Unternehmen die Standarderfüllung nachweisen wollen |
| Wofür genutzt? | Definition operativer IT-SM-Prozesse | Audit- und Compliance-Anforderungen für IT | Nachweis dass IT anerkannten Standards folgt |
Weitere verbreitete Standards
IMS – Integriertes Management System
Zusammenfassung mehrerer Managementsysteme in einem einheitlichen System:
- Qualitätsmanagement
- Umweltmanagement
- Informationssicherheitsmanagement
- Arbeitssicherheit
- Energiemanagement
- Supply-Chain-Sicherheitsmanagement