Unternehmensmodellierung im WS 2012

Nachlese des Kurses in Form von Tafelbildern und Kommentaren. Ich bitte alle Studierenden und Besucher, hier Kommentare, Hinweise u. dgl. zu hinterlassen. Siehe auch die Master-Seite des Kurses und (nur mit Account) den Moodle-Kursus. Sie müssen nicht registriert sein, um einen Kommentar zu hinterlassen! (Obwohl es beim Dialog hilft.)--msb (Diskussion) 14:05, 9. Okt. 2012 (CEST)

Einführung — 4.10.2012

4.10.2012:Check in Übung im „passiven“ Plenum
4.10.2012:Aufwärmen im aktiven Plenum: EPK Aufgabe (Systematisierung)
4.10.2012:Aufwärmen im aktiven Plenum: EPK Aufgabe (Modell)

Schon mit der ersten Übung im Plenum waren wir mitten beim Modellieren: die Tafel zeigt Erwartungen der Studierenden an den Kurs; mit EPKs befassen wir uns in diesem Kurs nicht: außer einer kurzen Einführung in UML, bei der wir nur Klassendiagramme und Use cases besprechen und üben, beschränken wir uns auf Theorie und Praxis von BPMN. Als Editor zur Erstellung der Prozessmodelle verwenden wir den Signavio Editor, bei dem sie sich für meinen Workspace anmelden müssen. Im Bild wird auch ARIS erwähnt: ARIS steht sowohl für eine BPM Software als auch (vielleicht erinnern Sie sich an den Kursus Betriebliche Informationssysteme?) für ein Modell der verschiedenen Sichten auf ein Unternehmen (Organisationssicht, Datensicht, Prozesssicht und Funktionssicht). Der Begriff „Taxonomie“ steht für eine Katalogisierung der Prozesse, wie sie in vielen Unternehmen üblich war bzw. ist. In diesem Kurs verfolgen wir einen dynamischen Ansatz zur Prozessmodellierung: Modelle sollen die Wirklichkeit zwar abbilden und beschreiben, aber vor allem auch als Grundlage für Dialog und Veränderungsmaßnahmen dienen (wodurch sie sich zwangsläufig kontinuierlich verändern).

Die Aufgabe der Gruppe, die im Modus „aktives Plenum“ ausgeführt wurde, bestand in der Modellierung des aktiven Plenums (auch „flipped classroom“ genannt) als EPK. Die Gruppe löste beide Aufgaben — die Arbeit im aktiven Plenum, als auch die Modellierungsaufgabe — sehr beeindruckend: Sie begannen mit einer Systematisierung (erste Abbildung, linke Seite der Tafel), in der sie bereits auf das „(Swim)Lane" Konzept stießen, das für die BPMN zentral ist. Sie hätten hier auch das Modell gleich als Vorgangskettendiagramm in die Tabelle eintragen können. Die Gruppe konnte zwar in den gesetzten 30 Minuten das Modell nicht abschließen, aber der Sinn der Übung war unter anderem für mich (und die Gruppe) zu sehen, wie viel Modellierungswissen bereits (oder noch) vorhanden war. Und andere Aspekte jeder Modellierung (zum Beispiel was relevant ist, welche Entscheidungen bei Erstellung eines Modells getroffen werden müssen, für wen das Modell gedacht ist usw.) wurden hier bereits deutlich und diskutiert.

(Dank an Z.B. für das Fotografieren der Tafelbilder!)--msb (Diskussion) 22:01, 4. Okt. 2012 (CEST)

SCRUM Flow — 04.10.2012

Nach den Erfahrungen des letzten Semesters verwenden wir in diesem Semester eine so genannte "agile" Methode, um die Projekte zu managen. In den ersten beiden Wochen des Semesters werden wir Scrum-Teams zusammenstellen, und am 18. Oktober in einem Workshop mit 'Process Owners' (Prozesseignern) mit der Teamarbeit selbst beginnen. Das Diagramm zeigt den Projektablauf, der um drei so genannte "Sprints" von je drei Wochen länger herum strukturiert ist. Zwischen den Sprints gibt es Review Meetings und während des Sprints gibt es wöchentliche Meetings mit dem Prozesseigner (i.d.R. mit mir als Stellvertreter) und im Team. Für die Projekte gelten die folgenden Regeln:

Bis zum 17. Oktober müssen die Teams stehen. Jedes Team ist ein "interdisziplinäres" Team aus 4 Mitgliedern (z.B. 1 Techie, 1 Prozessexp., 1 Fachexp. & 1 Kommunikator)
Jedes Team entwickelt ein eigenes Produkt = realer HWR Prozess. Ein realer HWR-Kunde dient als PO=Process Owner (Vertretung=MSB)
Am 17. Oktober werden alle bekannten Produkt Anforderungen festgehalten (=Product Backlog). Im Anschluss entwickelt jedes Team einen priorisierten Meilenstein Plan f.d. Sprints
Im PO Meeting wird kurz besprochen, wie das Projekt sich entwickelt. Zunächst mit dem PO (15 Min), dann das Team unter sich.
Die Anwesenheit der PO während der Sprint-Reviews ist optional. Ausnahme ist das letzte Treffen zum Projekt am 31. Januar, wenn die Ergebnisse den Kunden übergeben werden.
Der abgeschätzte Projektaufwand entspricht dem erwarteten Aufwand für einen 5 Credits Kurs.
Die Ergebnisse der Projektarbeit (Gesamt Zensur je Team) können Ihre Klausur Note verbessern (33 % zu 66 % Split).
Kurzüberblick für Scrum (DasScrumTeam) — Mehr Tools zu Scrum (Boris Gloger)
Denken Sie sich selber Alternativen zum täglichen Scrum Meeting ('Daily Scrum') aus—z.B. Check-In via Facebook Gruppe od. dgl.
PO Meetings (15 Min) finden zu den angezeigten Terminen zwischen 12:15 Uhr und 13:45 Uhr in Raum B 5. 18 statt und müssen von allen Teammitgliedern besucht werden.
Die Tasklisten (Aufgaben) für jedes Teammitglied müssen Im Anschluss an die Aktualisierung sichtbar gemacht werden (auf dieser Seite).

--msb (Diskussion) 22:06, 4. Okt. 2012 (CEST)

BPMN Basics — 11.10.12

UMO-WS12 BPMN Basics-1
UMO-WS12 BPMN Basics-2
UMO-WS12 BPMN Basics-3

In dieser Sitzung haben wir uns erstmals auf die Modellierungssprache BPMN eingelassen. Die erste Tafel zeigt ausgewählte Kernelemente. Die waren auch deshalb für Sie wichtig, weil wir in der Klausur nur Kernelemente verwenden wollen, während wir für das Praxisprojekt den erweiterten Satz von Symbolen verwenden (siehe bitte die HWR Modellierungsrichtlinien, die sie in Moodle einsehen können). Erwähnenswert, weil häufig vergessen, ist das Symbol ganz unten rechts: dort laufen zwei Sequenz Flüsse in eine Aktivität hinein. Das ist ein syntaktischer Fehler: immer wenn zwei oder mehr Linien zusammenkommen, müssen sie durch einen Operator verbunden werden. Der Begriff „Happy Path“ bezieht sich auf « den Prozesspfad, den wir uns bei der Ausführung wünschen und für den der Prozess ursprünglich definiert wurde.» ( Zitiert nach: Freund und Rücker, Praxishandbuch BPMN 2.0, Hanser 2012, S. 131).

Die zweite Tafel betrifft unsere anfangs Übung, die wir im Modus „flipped classroom" durchgeführt haben (d.h. sie haben alle Arbeit selber gemacht). Aufgabe war, das für und Wider von Unternehmensmodellierung darzustellen. Das interessante Hauptergebnis neben verschiedenen Einzelaspekten war, dass (fast) jeder Vorteil von UMO auch als Nachteil gesehen werden kann. Ein Beispiel ist die Standardisierung, die Klarheit durch Normierung schafft, Kostensenkung ermöglicht, usw. Gleichzeitig bedeutet diese Normierung aber, dass Individualität verschwindet: auf dieses wegnehmen von individueller Freiheit reagieren Mitarbeiter beispielsweise durch Widerstand.

Wir beendeten unsere Einführung mit einer Beispielübung, die sie bitte für unsere zweite BPMN Sitzung am 25. Oktober für sich selbst beenden bzw. verbessern und revidieren sollen, damit wir die Lösung im Plenum besprechen können. Es ging hierbei um die Modellierung eines Bewerbungsprozesses. Zwei Pools sollten erstellt werden. Der erste Pool gehört dem Bewerber (Kandidaten) und stellt den Prozess aus seiner Sicht dar. Der zweite Pool stellt denselben Prozess (parallel) aus der Sicht der Personalabteilung dar. Zwischen beiden Pools darf es, das ist eine harte Regel, nur Nachrichtenflüsse geben. Die Tafel zeigt den Lösungsansatz aus dem Plenum. Bei ihrer Lösung denken Sie bitte daran, dass Happy Path Konzept zu verwenden, d.h. beginne sie immer mit dem Modell des Wegs mit dem geringsten Widerstand Und arbeiten Sie dann Entscheidungspunkte (Gateways) und andere Aspekte ein.

Praxisprojekte — 11.10.12

Bibliothek/HWR FB 1

Ticketsystem ("Issue-Tracking System"): ...
Log-Seite(n) Team "Bibliothek": die Log-Seite enthält einen Fortschrittsüberblick des Entwicklungsteams, z.B. in Form eines Task Boards; als Minimum muss das Entwicklerteam wöchentlich die aktualisierte Taskliste veröffentlichen. In diesem Projekt ist die Seite öffentlich, so dass Kunden dort (auf der "Diskussion"-Seite) Kommentare hinterlassen können. Zwischenergebnisse (Modelle) lieber über Signavio miteinander teilen.

Qualitätsmanagement/IMB

Akkreditierung: Der Prozess der Studiengangsakkreditierung am IMB (Vorbereitung des Verfahrens, Koordination der Selbstdokumentation, Vorbereitung des Vor-Ort-Besuchs, Koordination der Vor-Ort-Begutachtung durch die Agentur, Gutachten und Akkreditierungsentscheidung, bis zur Eintragung des akkreditierten Studiengangs in den einschlägigen Internet-Portalen).
- Log-Seite(n) Team "Akkreditierung": die Log-Seite enthält einen Fortschrittsüberblick des Entwicklungsteams, z.B. in Form eines Task Boards; als Minimum muss das Entwicklerteam wöchentlich die aktualisierte Taskliste veröffentlichen. In diesem Projekt ist die Seite öffentlich, so dass Kunden dort (auf der "Diskussion"-Seite) Kommentare hinterlassen können. Zwischenergebnisse (Modelle) lieber über Signavio miteinander teilen.

Evaluation: Der Prozess der Kursevaluation am IMB (Vorbereitung und Durchführung der online-Evaluation, Kommunikation der Ergebnisse, Beratung der Lehrenden, Maßnahmen durch Lehrende und Studiengangsmanagement)
- Log-Seite(n) Team "Evaluation": die Log-Seite enthält einen Fortschrittsüberblick des Entwicklungsteams, z.B. in Form eines Task Boards; als Minimum muss das Entwicklerteam wöchentlich die aktualisierte Taskliste veröffentlichen. In diesem Projekt ist die Seite öffentlich, so dass Kunden dort (auf der "Diskussion"-Seite) Kommentare hinterlassen können. Zwischenergebnisse (Modelle) lieber über Signavio miteinander teilen.

Forschungsmanagement 2 (ehem. Rechenzentrum)

Prozesse des Forschungsmanagements zur besseren Abwicklung eines geplanten Forschungs- oder Entwicklungsprojektes gemäß §7 Drittmittelanzeige der HWR.
- Log-Seite(n) Team "Forschungsmanagement 2 (ehem. RZ)": die Log-Seite enthält einen Fortschrittsüberblick des Entwicklungsteams, z.B. in Form eines Task Boards; als Minimum muss das Entwicklerteam wöchentlich die aktualisierte Taskliste veröffentlichen. In diesem Projekt ist die Seite öffentlich, so dass Kunden (auf der "Diskussion"-Seite) dort Kommentare hinterlassen können. Zwischenergebnisse (Modelle) lieber über Signavio miteinander teilen.

Forschungsmanagement 1

Interne Forschungsförderung: Prozess der Antragstellung – Gewährung – Dokumentation auf eine Ermäßigung der Lehrverpflichtung, ein Forschungs- oder Praxissemester für Forschungszwecke: Prüfung der Anträge nach den formalen Vorgaben gemäß Forschungsförderungssatzung der HWR, Entscheidungsfindung und Kommunikation der Ergebnisse der Forschungskommissionen der jeweiligen Fachbereiche, Dokumentation der gewährten Ermäßigung und der Ergebnisse des Forschungsvorhabens

Log-Seite(n) Team "Forschungsmanagement": die Log-Seite enthält einen Fortschrittsüberblick des Entwicklungsteams, z.B. in Form eines Task Boards; als Minimum muss das Entwicklerteam wöchentlich die aktualisierte Taskliste veröffentlichen. In diesem Projekt ist die Seite öffentlich, so dass Kunden dort (auf der "Diskussion"-Seite) Kommentare hinterlassen können. Zwischenergebnisse (Modelle) lieber über Signavio miteinander teilen.

Kickoff Workshop — 18.10.12

Die erste Etappe unseres Unternehmensmodellierungs-Projekts beginnt am Donnerstag dieser Woche. Bitte finden Sie sich um 8:30 Uhr ein, damit wir das Vorgehen kurz besprechen können, bevor die Kunden um 9:00 Uhr kommen.

Der Ablauf wird in etwa wie folgt sein:

08:30 Uhr: Kursbesprechung (ohne Kunden) zur Vorbereitung.
09:00 Uhr: Kunden stellen sich selber und ihre Beispiel Prozesse kurz vor.
09:30 Uhr: Kunden arbeiten mit den ihnen zugeordneten Teams. Hauptziel dieser Etappe ist die Erstellung eines 'Product Backlog', einer Liste von Anforderungen in Form von (kurzen) User Storys. Außerdem muss jedes Team mit seinem Kunden verabreden (und fixieren), wie die Zusammenarbeit bis zum nächsten Sprint Review (22. Nov.) verlaufen soll.
11:00 Uhr: Kursbesprechung (ohne Kunden) zur Nachbereitung. Jedes Team erstellt ein 'Sprint Backlog', eine Liste von Aufgaben, die während des Sprints erledigt werden sollen. Dokumentation (Minimum): Tasklisten auf der Wiki-Seite für jedes Team (s.o.) — wöchentlicher Update!

Informationen zu Scrum, User Storys usw. finden Sie online auf dem Moodle Server. Wir werden das Instrument "Scrum" an unsere Bedürfnisse anpassen (und nicht umgekehrt), d.h. es gibt viel Agilität im Prozess. Bitte gucken Sie sich aber bis zum Donnerstagmorgen unbedingt kurz die Doku zu User Storys, sowie die Prozessdokumentation an, die ich (falls vorhanden) separat im Anschluss an diese E-Mail an die betreffenden Team Mitglieder schicken werde.

Am 15.11. fällt die Lehrveranstaltung aus und Sie können diesen Vormittag evtl. benutzen, um Kontakt mit den Kunden aufzunehmen und sich zu treffen (in der Woche vor dem 1. Sprint-Review).--msb (Diskussion) 10:14, 18. Okt. 2012 (CEST)

UMO-WS12 Kickoff Workshop 2
UMO-WS12 Kickoff Workshop 1

PO Meetings im 1. Sprint — ab 25.10.12

Hier finden Sie die Zeiten für die "Process Owner (PO) Meetings"; im üblichen Scrum-Prozess sind dies Treffen mit den kundenseitigen Prozesseignern (solche Treffen bzw. Kontakt während des 1. Sprints sollten Sie mit den Kunden direkt während oder unmittelbar nach dem Kick-off Workshop vereinbart haben); der Scrum Master ist aber auch eine Art PO für das Team und agiert als eine Art Protektor/Coach, d.h. ohne Autorität:

A ScrumMaster can say to a team, “Look, we’re supposed to deliver potentially shippable software at the end of each sprint. We didn’t do that this time. What can we do to make sure we do better the next sprint?”

(Aus: Learning Scrum)

Alle PO Meetings finden im Anschluss an die Morgenveranstaltung in meinem Büro Geb. B, Raum 5.18 statt. Dem Meeting sollte eine Aktualisierung des Projektstatus vorausgehen. Speziell für dieses Projekt besteht das "Produkt" in einem oder mehreren Prozessmodellen. Übergeordnetes Ziel für alle Teams ist die Erstellung des strategischen („Happy Path“) Modells oder des IST-Zustands.

Sie können gerne selbstständig mit anderen Teams tauschen und die Tabelle entsprechend ändern bitte. Achtung: ab 08.11. rotieren die Teams automatisch jeweils um einen Slot! --msb (Diskussion) 13:47, 1. Nov. 2012 (CET)

Team	25.10.	01.11.	08.11.
12:15-12:30	Bibliothek	Bibliothek	Forschungsmgmt 2 (war: RZ)
12:35-12:50	Forschungsmgmt 1	Forschungsmgmt 1	Bibliothek
12:55-13:10	Akkreditierung	Akkreditierung	Forschungsmgmt 1
13:15-13:30	Evaluation	Evaluation	Akkreditierung
13:35-13:50	Forschungsmgmt 2 (war: RZ)	Forschungsmgmt 2 (war: RZ)	Evaluation

Zusammenfassung nach den ersten PO Meetings

Ziel des ersten Sprints ist eine Erstellung des Modells auf der Übersichtsebene und zwar des IST-Zustands. Nachlesen, wie sich die HWR das vorstellt können Sie auf dem HWR Modellierungs-Blog.
Sie sollen kleine Ergebnisse erzielen und sie mit dem Kunden verhandeln, damit Sie sich nie zu weit von den Wirklichen Anforderungen des Kunden entfernen und sich nicht verrennen.
Es ist aus meiner Erfahrung von großer Wichtigkeit, dass sie gleich am Anfang neben dem persönlichen Rapport eine gute Beziehung mit dem Kunden etablieren. Dazu gehört vor allem professionelle, regelmäßige Kommunikation wie mit dem Kunden vereinbart. Wenn Sie Ergebnisse zeigen oder Kommentare wünschen, sollten Sie immer klare, kurze Fragen stellen. Ich werde die Kunden in dieser Woche noch einmal an die Existenz dieses Wiki (und ihrer Log Dateien) erinnern und sie zu Signavio einladen, wo im Bereich "Projekte" für jedes ihrer Projekte ein eigener Ergebnisordner eingerichtet ist (dort erwarten die Kunden Ergebnisse, die sie dann auch direkt im Diagramm kommentieren können, wenn sie wollen).
Bitte setzen Sie mich wenigstens 1 x pro Woche in Kenntnis, was Sie in dieser Woche gemacht haben, z.B. Tasklisten abgearbeitet oder verändert, Diagramme erstellt usw. (und nicht erst 5 Min. vor dem PO Treffen). Machen Sie das über die Diskussionsseite der Logseite Ihres Projekts.
Das Projekt ist keine Beschäftigungstherapie, d.h. wenn Sie fertig sind, weil der Kunde sagt, Sie haben geliefert und ihn zufriedengetellt, dann sind Sie fertig. Sie müssen aber wenigstens noch beim Sprint-Review berichten.
Product Backlog heisst User Storys. Sprint Backlog heisst Tasklisten für den Sprint, wenigstens von Woche zu Woche.
Ansonsten sind alle Teams (bis auf eines, das Pech hatte) gut im Rennen! Weiter so!

Unified Modeling Language - Woche vom 01.11.2012

Aggregation, Komposition und Generalisierung, Spezialisierung ("Vererbung") im Klassendiagramm

Sie finden mehrere Übungsaufgaben (zu Klassendiagrammen) und Material zu UML in Moodle.

PO Meetings

Bitte denken Sie daran, falls Es der Komplexität Ihrer Prozesse angemessen ist, die User Storys dahingehend zu vervollständigen, dass Sie eine Priorität (Wichtigkeit für den Kunden) und eine Aufwandsabschätzung (10: leicht...40: schwer und aufwändig, am Besten noch mit Zeitaufwand) vornehmen. Das können Sie nur in Absprache mit dem Kunden tun. Sinn dieser Maßnahme in einem Softwareentwicklungsprojekt ist, zu jedem Zeitpunkt Zwischen-Ergebnisse zu haben, die der Vom Kunden erwarteten Wichtigkeit entsprechen.
Sprint Review Kriterien: Sie erhalten von mir rechtzeitig einen Katalog von Kriterien, an dem Sie sich für die Präsentation beim Sprint Review orientieren können. Nachdem ich die Gruppen eingeteilt habe, kriegen die Kunden von mir Nachricht, wann ihr jeweiliges Team seine Zwischenergebnisse vorträgt.

Pyramiden-Prinzip - Woche vom 05.11.2012

(1) Studenten-Ergebnis Übungsaufgabe Bibliothek Klassendiagramm
(2) Übungsaufgabe zum Pyramidenprinzip (SKFA Methode)
(3) Studenten Ergebnisse der Übung

(1) Im Klassendiagramm haben Sie alle wesentlichen Relationen abgebildet, bis auf den Ausleihvorgang, der als Klasse anstelle der Relation "leiht aus" eingefügt und dort mit der Operation "ÜberprüfenAusleihe()" überladen werden kann.

Unser Thema ist das Pyramidenprinzip (PP) nach Minto. In der Veranstaltung werden wir das PP verwenden, um einen Kriterienkatalog für den Sprint-Review abzuleiten und anschließend als Hausaufgabe (zum Einreichen) wenden Sie das Prinzip auf Ihr eigenes Projekt an. (Siehe auch hier ein weiteres Beispiel).

(2) Übungsaufgabe zum Pyramiden-Prinzip: Sie sollten Ihr eigenes Projekt für den 1. Sprint Review am 22.11. mit Hilfe der SKFA Methode modellieren.
(3) Das oben abgebildete Foto aus unserer Sitzung ist leider schwer lesbar. Aber vielleicht dient es Ihnen als Anker, um sich an die wesentlichen Resultate unserer Diskussion zu erinnern; im Folgenden versuche ich aus Ihren vorläufigen Ergebnissen eine Pyramide für unseren 1. Sprint Review abzuleiten:
- der Hauptgegenstand beim Sprint-Review ist die Darstellung ihres Projekt-Fortschritts. Ab hier ist es in der Realität bereits wichtig, welche Zielgruppe Sie vor sich haben: mit dem PP möchte man ja logisch argumentieren, um den größtmöglichen Informations-Transfer und Rapport beim Zuhörer zu erreichen. Außerdem sind die Erwartungen wichtig, mit denen die Zuhörer zur Präsentation kommen: in diesem Fall hatten wir vereinbart, dass zum ersten Sprint Review die Modelle auf der strategischen Ebene, also im "Happy Path" Format, fertig sein sollen.
- Als erste Frage formulieren wir F1: Wie ist der Status des Projekts?
- Die Antwort auf die erste Frage lautet: A1: Happy Path Modell für strategische Ebene (wie vereinbart) — Es macht jetzt, bei der Formulierung der Situation, Sinn, sich über eventuelle Nebenbedingungen Gedanken zu machen, zum Beispiel: sind Kunden vor Ort? Ist irgendetwas besonderes an diesem Prozess? Oder am Zeitpunkt der Präsentation?
- Situation: Teams haben vier Wochen lang seit dem Kick-off gearbeitet. In diesem Zeitraum Kunden Kommunikation wie vereinbart. BPMN Basistraining abgeschlossen.
- Komplikation: keiner der Beteiligten hat jemals an einem agilen Projekt Prozess wie diesem teilgenommen. Es ist unklar, wie es jetzt weitergehen soll, um ein gutes Ziel für die Kunden zu erreichen. Gleichzeitig war das Ergebnis selbst (Happy Path) konzeptuell nicht so schwer. — ...Wenn Sie jetzt S/K mit F1/A1 vergleichen, stellen sie fest, dass A1 keine Antwort auf die Komplikation darstellt...Wir haben jetzt zwei Möglichkeiten: Anpassung von F1/A1 oder Änderung der Komplikation. Anpassung von F1/A1 ist deshalb methodisch vorzuziehen, weil wir annehmen, dass die Komplikation der (aktuelle) Grund oder Trigger für diese Präsentation ist!
- F2: können wir aus dem 1. Sprint irgendetwas lernen? - A2: Ja! Und zwar... — ... die eigentliche Antwort auf die modifizierte Frage ist bereits die erste Ebene der Pyramide: Lernerfahrungen zu BPMN, Teamarbeit, Werkzeugen und Kunden-Kommunikation. Sie sehen auch hier wieder, wie die wesentlichen Aspekte von Situation und Komplikation erneut aufgegriffen werden. Der Rest der Pyramide ergibt sich aus diesen ersten Blöcken. Bis zu welcher Tiefe sie dabei vorgehen, hängt von Ihnen ab. Für den Zuhörer ist es i.d.R. wichtig, dass die Pyramide gleichmäßig bestückt ist. (Es sei denn – und das gilt immer – es gibt Gegengründe).

Hausaufgabe zum 18.11.

Vervollständigen Sie die Pyramide ausgehend von der oben per SKFA erarbeiteten Einführung für Ihr eigenes Projekt. Im Klartext: auf weiteren Ebenen der Pyramide halten sie stichwortartig Lernerfahrungen zu BPMN, Teamarbeit, den von Ihnen verwendeten Werkzeugen (Wiki, Signavio usw...) und zur Kundenkommunikation fest und organisieren Sie entsprechend dem Pyramidenschema, d.h. deduktiv von oben nach unten fortschreitend, wobei sie von jeder Ebene auf die nächste kommen, indem sie eine Frage wie: warum? Wie? Womit? usw. stellen und beantworten. Dieser Text wird auch in Moodle hinterlegt werden: bitte laden Sie dort Ihre in Signavio erstellte Pyramide (gleichzeitig Ihre Vorbereitung auf den Sprint Review) bis zum Sonntag d. 18.11.2012 (23:55 Uhr) hoch. Tipp: eine gute Pyramide können Sie unmittelbar in Foliensätze übersetzen wenn Sie möchten. Natürlich müssen Sie nur 1 Datei je Team hochladen! — Ach ja, und um die Pflicht, nämlich die Präsentation des Modells selbst kommen Sie ebenfalls nicht herum. Die Pyramide ist die Kür!

1. Sprint Review - 22. November

Vorbereitung

Zu beachten:

Verwenden Sie zur Vorbereitung das mithilfe der SKFA-Methode abgeleiteten Schema (s. Illustration oben), den Sie auch bis zum 18. November in Moodle hochgeladen haben.
Sie haben zur Darstellung ihrer Ergebnisse maximal 30 Minuten Zeit gefolgt von 15 Minuten Aussprache.
Ihre Ergebnisse werden im aktiven Plenum nicht von mir, sondern von den anderen Teams bewertet und diskutiert. Als Grundlage der Bewertung dienen einige offensichtliche Kriterien, die wir in Notepads (ein Pad pro Team, s.u.) kommentieren.
Ihre Ergebnisse werden nicht summativ im Sinne einer Note bewertet, sondern nur formativ, d.h. um Ihnen zu helfen, ihre Performance im nächstens Sprint noch zu verbessern.
Ich weise die Kunden nochmal auf diesen Termin hin, allerdings ist er für die Kunden nicht verpflichtend — für Sie hingegen schon!

Vorläufiger Ablaufplan:

Zeit	Team
08:40-09:15	Forschungsmanagement 2: externe Förderung (Westerfeld)
09:20-09:55	Qualitätsmanagement 2: Evaluation (Dr. Schmalz)
10:00-10:35	Forschungsmanagement 1: interne Förderung (Wurbs)
10:40-11:15	Qualitätsmanagement 1: Akkreditierung (Dr. Schmalz)
11:20-11:55	Bibliothek: Ticketsystem? (Skerka/Rupp)
12:00-12:30	Abschlussbesprechung: Änderungen für 2. Sprint?

Nachlese

Screenshots vom Meeting (da wir die Notepads weiterverwenden bzw. überschreiben wollen):

Forschungsmanagement 2
Evaluation
Forschungsmanagement 1
Akkreditierung
Bibliothek

Mir haben die Präsentationen alle sehr gut gefallen: besonders gut fand ich, dass alle das Pyramidenprinzip (SKFA) sichtbar angewendet haben, so dass der logische Ablauf klar nachvollziehbar war. Sie haben glaube ich auch an den positiven Reaktionen der anwesenden Kunden festgestellt, dass Ihre Rezepte aufgegangen sind. Alle Teams haben mithin das gesetzte Ziel des ersten Sprints (Modell auf der strategischen Ebene, "Happy Path") erreicht— ein Team mit Einschränkungen aufgrund des mangelnden Kundenkontakts. Mit kleinen Ausnahmen wollen alle die Prozesse des ersten Sprints im zweiten Sprint weiterfahren. Die Auslese von ersten Reaktionen über Online Pads hat auch ziemlich gut geklappt— nächstes Mal kommen vielleicht noch mehr Kommentare. Aber die Spärlichkeit des Online-Protokolls wurde mehr als wettgemacht durch die guten Diskussionen im Anschluss an jeden Vortrag.
Im 2. Sprint haben wir die Möglichkeit durch die UMO Themen "Storytelling", "Change Management" und "Szenarienbildung" auch einige der weichen Aspekte eines Modellierungsprojekts (in Richtung auf Implementierung, Intervention, Change usw.) zu besprechen. Das wird mithin ein Schwerpunkt des 2. Sprint Review sein. Möglicherweise sind einige von Ihnen dann ja auch schon fertig! Ich werde auch in den nächsten Wochen (gemeinsam mit den Kunden) verstärkt die Gelegenheit wahrnehmen, direkt Kommentare in ihren Modellen in Signavio zu hinterlassen.

Bitte stellen Sie bis spätestens zum Mittwoch 27.11. eine kurze Reflexion ihrer eigenen Präsentation auf der Diskussionsseite zu Ihrem Projekt-Log (im Wiki) ein, die ich dann kurz kommentieren werde. --msb (Diskussion) 22:35, 22. Nov. 2012 (CET)

PO Meetings im 2. Sprint — ab 29.11.12

Hier finden Sie die Zeiten für die "Process Owner (PO) Meetings" im 2. Sprint.

Alle PO Meetings finden im Anschluss an die Morgenveranstaltung in meinem Büro Geb. B, Raum 5.18 statt. Dem Meeting sollte eine Aktualisierung des Projektstatus vorausgehen. Speziell für dieses Projekt besteht das "Produkt" in einem oder mehreren Prozessmodellen. Übergeordnetes Ziel für alle Teams in diesem 2. Sprint ist die Überführung des strategischen („Happy Path“) Modells in den detaillierten SOLL-Zustand bzw. eine detaillierte Ausführung des IST-Zustands (im Unterschied zum Modell auf der strategischen Ebene).

Sie können gerne selbstständig mit anderen Teams tauschen und die Tabelle entsprechend ändern bitte.

Team	29.11.	06.12.	13.12.
12:15-12:30	Evaluation	--	Akkreditierung
12:35-12:50	Forschungsmgmt 2	--	Evaluation
12:55-13:10	Bibliothek	--	Forschungsmgmt 2
13:15-13:30	Forschungsmgmt 1	--	Bibliothek
13:35-13:50	Akkreditierung	--	Forschungsmgmt 1

Anmerkung: Am 6. Dezember fanden keine PO Meetings statt, weil m.E. keine Fortschritte in den Teams zu verzeichnen waren. Vor dem 2. Sprint Review müssen Sie sich noch einige neue User Storys überlegen, bei denen es diesmal nicht um den Prozess selber geht und seine Teilnehmer, sondern um die Verwendung des Prozessmodells. Mit dem neuen, „weichen“ Werkzeugen, die sie im Verlauf dieses Sprints kennen lernen, sollte es ihnen einfacher fallen, solche Storys zu formulieren.

Storytelling - 29.11.12

Eigenschaften von Storys (allgemein)
Dennings Eigenschaften guter Geschichten für Organisatorischen Wandel

Im Unterricht haben Sie bereits begonnen, Ihr (detailliertes) Prozessmodell (nicht den Happy Path) als Story (im Sinne von Denning/Duarte) zu formulieren. Bitte stellen Sie diese Geschichte in kurzer Form als schriftliche Ausarbeitung ins Wiki (auf Ihre Projektseite) und vermerken Sie das entsprechend auf der Diskussionsseite. Denken Sie dabei an die Eigenschaften: authentisch, positiv, minimal und vorher/nachher. Schützen Sie evtl. namentlich bekannte Prozessteilnehmer durch Anonymisierung bzw. indem Sie sie zu Archetypen machen. Denken Sie an eine Zielgruppe und an eine Botschaft, die Sie im Hinblick auf den zu modellierenden Prozess mit der Geschichte transportieren möchten.

In dieser und den nächsten 2 Wochen widmen wir uns einigen wichtigen "weichen" Methoden, die genau das Gegenteil des standardisierten Vorgehens zur Modellierung (zB mit BPMN oder UML) sind, mit denen aber die "Grautöne", die Komplexität eines Vorgangs besser eingefangen werden können. Zur Implementierung braucht man immer beides!

--msb (Diskussion) 13:26, 29. Nov. 2012 (CET)

Szenarientechnik - 06.12.12

Abb.1: UMO Szenarienplanung Beispiele
Abb.2: UMO Szenarienplanung Prozess
Abb.3: 4 Wildcard-Szenarios
Abb.4: Spontanszenario Technik vs. Mobilität
Abb 5: Szenarios "Sammler" vs. "Cyber-Robin-Hoods"

Im Unterricht haben Sie (siehe Abb. 3-5) einige "abstrakte" Szenarien erstellt, d.h. ohne Anbindung an eine Branche (wie die Ölindustrie im Falle der Shell-Szenarios) oder an ein Unternehmen (Shell), das sich dafür interessiert, auf verschiedene mögliche "Zukünfte" vorbereitet zu sein und dafür planen zu können.

Als Hausaufgabe wenden Sie bitte den Prozess (Abb.2, Schritte 1-3) der Szenarientechnik auf Ihr eigenes Projekt an; Beispiel im Unterricht diskutiert: für das Projekt "Akkreditierung" könnten die Dimensionen 'Akkreditierung' (A) und 'Zertifizierung' (Z) relevant sein. A+ hieße z.B. dass Akkreditierung immer wichtiger wird (und z.B. Hauptgrundlage der Bewertung von Hochschulen wird, wichtiger noch als Uni oder FH Status), A- hieße, dass Akkreditierung jeglichen Wert verliert. Z+ würde bedeuten, dass nur Diplome, gestempelte Studienabschlüsse Bedeutung haben, während Z- bedeuten würde, dass Skills zählen, Abschlüsse aber nicht: z.B. stellt die Industrie aufgrund von Fähigkeiten (für die man vielleicht nur Zertifikate braucht) ein, während Abschlüsse ihr egal sind...usw.

Bitte laden Sie eine graphische Darstellung Ihrer Szenarios mit Stichpunkten und Titeln usw. bis zur nächsten Sitzung auf ihrer Wiki-Seite hoch und tragen Sie Ihr Ergebnis kurz am Anfang der Sitzung vor!

2. Sprint Review - 20.12.2012

Vorbereitung

Das übergeordnete Ziel jedes Sprint Reviews ist, die Tasklisten (=Aufgaben für das Team) zu aktualisieren. Wie auch in den vorherigen Sprints geht das nicht, oder dass sie mit den Kunden Kontakt aufnehmen. hierbei müssen Sie eventuell Erwartungen der Kunden managen: beispielsweise wie lange noch weitere Ideen in die Modelle Einfluss finden oder nicht.
Nachdem wir in diesem Abschnitt der Veranstaltung viel über "weiche" Methoden des Challenge Managements gehört haben, sind Sie in einer besseren Position, um den Kunden im Hinblick auf Pflege, potentielle Erweiterung und Implementierung der modellierten Prozesse zu begleiten. Widmen Sie diesem Aspekt in ihrer Darstellung unbedingt einigen Raum.
Räumen Sie unbedingt den Folder mit den Ergebnismodellen in Signavio auf und füllen Sie das Beschreibungsfeld für die Modelle aus, damit man nicht jedes Diagramm extra öffnen muss. Die Kunden haben mittlerweile alle Zugang: wenn sie von ihnen Kommentare haben möchten (wäre gut!) dann versichern Sie sich noch einmal, dass der Kunde weiß was er wo wie machen soll— idealerweise laden Sie nur mit spezifischen Fragen zum Kommentieren ein.

Zu beachten:

Verwenden Sie zur Vorbereitung ein Pyramiden-Schema nach der SKFA Methode. Laden Sie das Schema auf Ihrer Wiki Seite hoch.
Sie haben zur Darstellung ihrer Ergebnisse max. 20 Minuten Zeit gefolgt von max. 10 Minuten Aussprache.
Ihre Ergebnisse werden im aktiven Plenum nicht von mir, sondern von den anderen Teams bewertet und diskutiert. Als Grundlage der Bewertung werde ich Mini-Umfragen einrichten, die in Adobe Connect bereitstehen (Auswertung ist unmittelbar)
Ich weise die Kunden nochmal auf diesen Termin hin, allerdings ist er für die Kunden nicht verpflichtend — für Sie hingegen schon!
Bitte schicken Sie mir unbedingt bis zum Mittwoch Mittag (18. Dezember) ihre Präsentation, damit ich sie bereits hochladen kann. Sie können am Dienstag oder Mittwoch auch gerne das Präsentieren in Adobe Connect üben: hierzu müssen Sie mir Bescheid geben (E-Mail) damit ich Sie dort treffen und Sie zu Moderatoren machen kann.

Vorläufiger Ablaufplan:

Zeit	Team
08:30-09:00	Vorbereitungszeit — Klassenraum ist schon offen
09:00-09:30	Forschungsmanagement 1: interne Förderung (Wurbs)
09:30-10:00	Forschungsmanagement 2: externe Förderung (Westerfeld)
10:00-10:30	Bibliothek: Ticketsystem (Skerka/Rupp)
10:30-11:00	Qualitätsmanagement 1: Akkreditierung (Dr. Schmalz)
11:00-11:30	Qualitätsmanagement 2: Evaluation (Dr. Schmalz)
11:30-12:00	Abschlussbesprechung: Änderungen für 3. Sprint?

Zugang zum Klassenraum: siehe Moodle am Ende des Abschnitts "Agiles Projektmanagement mit Scrum". Gastzugang (Sie tragen selber Ihren Namen ein) mit Link, kein Zugangsschlüssel nötig.

Nachlese

Bewertung 2. Sprint Review FM-1 (interne Förderung)
Bewertung 2. Sprint Review FM-2 (externe Förderung)
Bewertung 2. Sprint Review Bibliothek
Bewertung 2. Sprint Review QM-1 (Akkreditierung)
Bewertung 2. Sprint Review QM-2 (Evaluation)

Auch mit dem zweiten Sprint Review bin ich sehr zufrieden, insbesondere wegen der besonderen Umstände der Online Umgebung: alle Teams haben sich, mit unterschiedlichen Mitteln, sehr gut geschlagen. Wie ein Beobachter bemerkt hat, gibt es natürlich auch Verluste beim Verwenden von Adobe Connect: beispielsweise ist es einfach schwieriger, sich über Details eines Prozessmodells auszutauschen. Deshalb war es umso wichtiger, dass die meisten Teams die Erfahrungen des ersten Reviews und meine Anregungen zur Vorarbeit ernst genommen haben: das merkte man beispielsweise in der klugen Auswahl von Themen und in dem logischen Fluss ihrer Vorträge. Die einzelnen Abschlussbewertungen (Screenshots aus Adobe Connect) sehen Sie oben: Schlussfolgerungen müssen Sie selber ziehen (im Vergleich zu ihren Absichten). Separate Kundenkommentare erlaubt diese Art der Umfrage leider nicht – obwohl eine Kundin (Fr. Wurbs) anwesend war und sicherlich von ihrer Vorstellung auch angetan war.--msb (Diskussion) 14:21, 20. Dez. 2012 (CET)

Beeindruckend fand ich wieder einmal das breite Spektrum an Möglichkeiten, so einen zweiten Arbeitsabschnitt zu dokumentieren und zu referieren. Zu den einzelnen Aspekten, die ich mir gemerkt habe, gehörten: Einbau von Szenarios (auch für den Dialog mit dem Kunden und zur Bereicherung des eigenen Prozessmodells); für den Kunden Probleme identifizieren und so bereits Einfluss auf die Prozesse nehmen (statt nur Prozesse abzubilden); Darstellung von Prozessen mithilfe eines Vorher-Nachher-Bildes; Verwendung von Prezi, um den Blick auf Einzelheiten zu lenken (sonst geht, bei der durchschnittlichen Größe der Detailmodelle, die Übersicht leicht verloren); separate Darstellung der Aufgaben und Möglichkeiten des Kunden, mit diesem Modell zu arbeiten. Und wenn wir schon bei „beeindruckend“ sind: sehr schön fand ich ebenfalls die Tatsache, dass alle Teams nicht nur bei der BPMN-Methode hängen geblieben sind, sondern mittlerweile (sehr) verschiedene Methoden auf natürliche Weise miteinander verbinden. Das hat gelegentlich schon einen Anflug von "hoher Schule"! --msb (Diskussion) 14:21, 20. Dez. 2012 (CET)

Noch in aller Kürze zu den nächsten Schritten:

im Anschluss an die Weihnachtspause beginnen wir mit einer kurzen angewandten Wiederholung des letzten Blocks mit Change Management Methoden (siehe Ihre Hausaufgabe).
Wir besprechen die Ergebnisse des 2. Sprint Reviews wie gehabt in den Team-Coachings am 10. und 17.1. (Termine finden Sie unten).
Am 24. Januar sind Sie herzlich zu einem Highlight der gesamten Veranstaltung eingeladen: wir führen gemeinsam mit Kollegen aus der Produktion des Cornelsen-Verlags einen Workshop durch, bei dem ihr gesamtes Anwenderwissen als Experten für Unternehmensbetreuung gefragt ist. Ich bitte um Ihre aktive, kreative Mitarbeit!
Die Abschlusspräsentation (der letzte Sprint Review) unter Anwesenheit aller Klienten und von Herrn Sost findet am 31. Januar statt.
Neue klausurrelevante Inhalte wird es nicht geben: stattdessen werden wir am 17. Januar noch einmal vor im Hinblick auf die Klausur üben. Allerdings ist der Workshop mit Cornelsen genau von der Art des Anwendungsbeispiels, das auch die Grundlage von ca. 50% der Klausuraufgaben bilden wird, dürfe also auch bei engem "Klausur-Fokus" für Sie interessant sein.--msb (Diskussion) 14:27, 20. Dez. 2012 (CET)

Übrigens können Sie sich eine (gestreamte) Aufzeichnung der gesamten Veranstaltung ansehen: den Link veröffentliche ich in Moodle. Die Teams beginnen jeweils nach ca. 00:00 (FM-1), 00:50 (FM-2), 01:20 (Bib), 01:50 (QM-1), 02:10 (QM-2). Das erste Team hat etwas länger gebraucht, um in Schwung zu kommen, das ist aber bei Online Veranstaltungen dieser Art, an die die Studierenden nicht gewöhnt sind, zu erwarten gewesen—die folgenden Teams profitieren von der Eingewöhnungsphase von ca. 30 Min.--msb (Diskussion) 14:54, 20. Dez. 2012 (CET)

PO Meetings im 3. Sprint — ab 10.1.13

Hier finden Sie die Zeiten für die "Process Owner (PO) Meetings" im 3. Sprint.

Alle PO Meetings finden im Anschluss an die Morgenveranstaltung in meinem Büro Geb. B, Raum 5.18 statt. Dem Meeting sollte eine Aktualisierung des Projektstatus vorausgehen. Übergeordnetes Ziel für alle Teams in diesem 3. Sprint ist der Abschluss ihrer Arbeit, die Diskussion ihres zweiten Sprint Reviews und die Präsentation der Ergebnisse vor den Kunden.

Am 10.1. besprechen wir Ihre Erfahrungen und Ergebnisse des 2. Sprint-Reviews
Am 17.1. besprechen wir Ihre Endergebnisse und den 3. Sprint-Review (Abschluss-Präsentation)
Der Termin am 24.1. muss ausfallen, weil ich an dem Nachmittag zu einer E-Learning Veranstaltung an den Fachbereich 2 muss.

Sie können gerne selbstständig mit anderen Teams tauschen und die Tabelle entsprechend ändern bitte.

Team	10.1.	17.1.	24.1.
12:15-12:30	Forschungsmgmt 1	Bibliothek	--
12:35-12:50	Forschungsmgmt 2	Forschungsmgmt 1	--
12:55-13:10	Akkreditierung	Forschungsmgmt 2	--
13:15-13:30	Evaluation	Akkreditierung	--
13:35-13:50	Bibliothek	Evaluation	--

Systemische Methoden / Klausurvorbereitung / Sprint Review - 10.01.2013

Plan für Januar

Kurze Besprechung des Plans für die verbleibenden Monate des Semesters: im Januar werden wir vor allem üben und wiederholen, d.h. ich präsentiere keine neuen Inhalte mehr, die auch für das Bestehen der Klausur relevant sind.

Systemische Sichtweise

Das Thema „systemische Sichtweisen“ ist übergreifend für alle Modellierungsmethoden, sowohl für die „harten“ (wie BPMN und das Pyramidenprinzip), als auch für die „weichen“ Werkzeuge (zum Beispiel Storytelling und Changemanagement) wichtig. Ich habe mich entschieden, diese Vorlesung diesmal ans Ende zu stellen, weil sie erst jetzt die bereits gelernten Werkzeuge einordnen können. Einige in der Präsentation erwähnten Methoden, wie zirkuläres Fragen oder paradoxe Interventionen oder spiegeln, sind zwar in der Praxis wichtig und nützlich, erfordern aber deutlich mehr Training wofür uns die Zeit fehlt. Lediglich im Workshop Ende Januar werden Sie in Form der Organisationsaufstellung noch ein mächtiges, komplexes neues Werkzeug kennen lernen.
Illustrativ für die Bedeutung systemischer Konzepte ist die Übertragbarkeit von Werten und Prinzipien der Familiensysteme, die wir alle quasi von innen heraus kennen, auf Organisationen und Unternehmen, die nämlich aufgrund ähnlicher Werte strukturiert sind und gemanaged werden.

Klausurvorbereitung

Klausurübung Unternehmensbeispiel
Klausurübung Unternehmensbeispiel Ergebnis 1
Klausurübung Unternehmensbeispiel Ergebnis 2
Klausurübung Unternehmensbeispiel Ergebnis 3
Klausurübung Unternehmensbeispiel Ergebnis 4

Die Aufgabenstellung der Klausur Übung sieht fast genauso aus wie in der Klausur selbst. In der Klausur erhalten Sie lediglich noch weitere Erläuterungen. Wichtig ist bei dieser Fragestellung, dass sie ihre Überlegungen und ihre Gedankengänge, mit denen sie zu einer Antwort gelangt sind, ebenfalls dokumentieren, damit ich zuversichtlich sein kann, dass sie die Konzepte verstanden haben. Darüber hinaus sollten Sie ebenfalls skizzieren, falls relevant, was die wesentlichen Prozessschritte sind, damit man das jeweilige Werkzeug überhaupt einsetzen kann.

Der Link zu einem ca. 40-minütiger Video der Übungssequenz ist in Moodle hinterlegt.

Post-Mortem des 2. Sprint Reviews

Sie sollten jetzt in der Lage sein, nachdem sie dank ihrer Kommilitonen viele verschiedene Möglichkeiten kennen gelernt haben, die Unternehmensmodelle zu präsentieren, die für ihr Modell und ihren Kunden beste Methode zu identifizieren: diese sollten Sie beim Abschlussvortrag am 31. Januar verwenden. Denn bei diesem letzten Review geht es nicht mehr um die Erstellung von Tasklisten, sondern um ihr Endergebnis sowie das Schicksal bzw. die weitere Verwendung ihres Endergebnisses.
Im Vorlauf des drittens Sprint Reviews sollten Sie, wie auch beim letzten Mal, noch einmal den Kundenkontakt suchen und in wesentlichen ihr Ergebnis abzeichnen lassen, bzw. letzte Hinweise entgegennehmen und berücksichtigen. Sie sollten sich in der Rückschau auf die vergangenen zwei Interviews überlegen, was gut gelaufen ist und was nicht gut gelaufen ist und den Review entsprechend planen. Bei allen Vorträgen im zweitens Sprint Review fand ich die Vorbereitung bzw. Durchführung der Fragen und Antworten während oder am Ende des Vortrags mangelhaft: fast ohne Ausnahme hatten sie keine Fragen vorbereitet bzw. hat sich kein Team besonders um diesen wichtigen Feedback-Aspekt bemüht— das sollte also in jedem Fall beim Abschluss Review anders werden!
Sie sollten mir Ihren Plan für den Abschlussvortrag in unserem Coaching am 17. Januar vorstellen!

Zum Abschlussvortrag / 3. Sprint Review am 31.01.2013

Der Vortrag ist insbesondere für die Kunden gedacht, d.h. den Kunden sollen Sie das bestmögliche Ergebns präsentieren. Dazu gehört aber auch ein Überblick in Form einer Selbstreflexion (der Kunde fragt sich, ob der Aufwand gerechtfertigt war, vielleicht will er einen ähnlichen Auftrag jemand anderem geben usw.) und weiterführende Gedanken und Ideen soweit erwünscht bzw. sinnvoll. In jedem Fall vor dem Vortrag den Kunden nochmal um Input für den Vortrag bitten. Die Kunden werden von mir auch um eine (qualitative) Bewertung bzw. Reihenfolge gebeten (einschließlich Herrn Sost und Herrn Schild). Ansonsen sind die meisten der im letzten Sprint für die anonyme Umfrage gestellten Fragen noch relevant:
Prozessverständnis geliefert
Prozessmodelle fehlerfrei
HWR Modellierungsrichtlinien respektiert (bzw. wo verletzt, argumentiert)
Change Management: Gedanken über die Verwendung/Pflege des Prozesses nach dem Projekt
Logischer Aufbau (z.B. durch Verwendung von SKFA, wobei Sie die Methode, wie sie den Vortrag gestaltet haben, nicht explizit präsentieren sollen)
Abschlussvortrag (wirkt) geübt
Feedback vom 2. Sprint berücksichtigt
Kundenkontakt im 3. Sprint gehabt
Selbstreflexion über Projektverlauf bzw. -Probleme (für den Kunden)
Q&A/Diskussion vorbereitet und geleitet

Voraussichtlicher Ablaufplan (kleine Verschiebungen wegen Pausen möglich):

Zeit	Team
08:30-09:00	Vorbereitungszeit — Klassenraum ist schon offen
09:00-09:30	Forschungsmanagement 2: externe Förderung (Westerfeld)
09:30-10:00	Forschungsmanagement 1: interne Förderung (Wurbs)
10:00-10:30	Bibliothek: Ticketsystem (Skerka/Rupp)
10:30-11:00	Qualitätsmanagement 1: Akkreditierung (Dr. Schmalz)
11:00-11:30	Qualitätsmanagement 2: Evaluation (Dr. Schmalz)
11:30-12:00	Abschlussbesprechung (MSB mit Kunden)