Seite 1 von 18

Prozesshandbuch

Anforderungsmanagement

Stand: 26.06.2017

Version: 10

Freigabeversion

Seite 2 von 18

Änderungshistorie

Version Autor Datum Inhalt der Änderung 01 Heesmann 14.07.2016 Initialversion

02 Heesmann 26.08.2016

Rollendefinition präzisiert: LUIS-GL, LUIS-AL und LUIS-SV RACI-Matrix überarbeitet gemäß Review GVV, WMUE Rollen LUIS-GL, LUIS-AL und LUIS-SV neu definiert

03 Heesmann 21.09.2016

Nach LUIS-internem Review (GL und alle AL). Anpassungen: • CAB genauer definiert • RACI-Matrix überarbeitet gemäß Anmerkungen • Abgrenzung: Umfangreiche vs. Geringe

Anforderungen • IST eingeführt

04 Heesmann 22.09.2016 Nach internem Review mit W. Müller • LUIS-L standardmäßig im CAB • RACI-Matrix überarbeitet

05 Heesmann 26.10.2016

Nach LUIS-internem Review (GL und alle AL). Anpassungen: • Umfangreiche vs. Geringe Anforderungen

verdeutlicht • Kundenmanager: Einberufen des CAB. Alle anderen:

Teilnahme am CAB • BIT: Beratung des CIO (aber keine Entscheidung) • Benennung des Leiters des Design- und

Umsetzungsprojekts geändert: LUIS

06 Heesmann 25.11.2016

Änderungen nach Review mit CIO und CIO-Büro: • „geringe Erweiterung eines Service“ ergänzt • Abb.-Nummerierung korrigiert • Abb. 3: Hinweis ergänzt bezüglich Konsens und

Dissens im CAB • RACI-Matrix: Rolle des CAB eingeführt,

Entscheidung über Anforderung im CAB.

07 Heesmann 06.12.2016 Review LUIS-intern. Keine Änderungen. LUIS-interne Freigabe

08 Heesmann 18.01.2017

Änderungen nach Review CIO: • Präzisierung „geringfügige Änderung“ • Präzisierung bei der Wiedereröffnung eines RFC

unter geänderten Rahmenbedingungen • Ergänzung Rollen und Aufgaben:

Datenschutzbeauftragter (DSB). • Ergänzung Kap 6, RACI-Matrix um DSB Freigabeversion (LUIS, CIO)

Seite 3 von 18

Version Autor Datum Inhalt der Änderung

09 Heesmann 07.06.2017

• Präzisierung: Es werden nur externe, umfangreiche Anforderungen gemäß Prozess behandelt und dokumentiert

• Wenn Entscheidung negativ, dann Rückmeldung (Kap. 3)

• Abb. 1: Zustandsdiagramm einer Anforderung angepasst: Es müssen nicht immer alle Zustände durchlaufen werden (Approval BIT)

• Nicht nur „Umsetzungsprojekt“ sondern auch „Design-Projekt“

• Abb. 4, Ergänzung: Ggf. Präsidiumsbeschluss notwendig

• Weitere Erläuterung zu „großen“ und „kleinen“ Anforderungen

10 Heesmann 26.06.2017

• Abb. 1: Zustandsdiagramm korrigiert: gestrichelter Pfeil zu „Approval BIT“ war überflüssig

• Kap. 3.1: Nur externe Anforderungen werden betrachtet

Freigabeversion

Seite 4 von 18

Inhaltsverzeichnis

1 Einleitung 5

2 Prozessziel und –zweck 6

3 Prozess-Eckdaten 7

3.1 Auslöser und Eingangsdaten 7 3.2 Ergebnisse und Ausgangsdaten 7 3.3 Rollen und Aufgaben 7 3.4 Aktivitäten 8

4 Zustandsübergangsdiagramm Anforderungen 9

5 Prozessablauf 10

5.1 Erfassung und Einschätzung der Anforderung 10 5.2 CAB 11 5.3 BIT und Entscheidung 12

6 Zuständigkeitsmatrix (RACI) 13

7 Anhang A: Erläuterung der Anforderungstypen / Change-Typen 15

8 Abkürzungsverzeichnis 16

9 Glossar 17

10 Referenzen 18

Seite 5 von 18

1 Einleitung Dieses Handbuch beschreibt den Prozess zum Management von Anforderungen an IT-Services des LUIS. Dabei handelt es sich um Anforderungen, die seitens der Kundinnen und Kunden bzw. seitens der Anwenderinnen und Anwender sowohl hinsichtlich der Änderung, Erweiterung oder Einstellung von bestehenden Services als auch hinsichtlich der Einführung neuer IT-Services gestellt werden.

Der Anforderungsmanagementprozess behandelt solche Anforderungen, deren Umsetzung ein umfangreicheres Projekt zur Folge haben. Ein Beispiel für eine umfangreiche Anforderung ist derzeit die Einführung eines zentralen Bilddatenbank-Service.

Anforderungen, die nur eine geringe Änderung eines Service auslösen, werden eher informell behandelt, d.h. es sind nur die LUIS-Geschäftsleitung, der LUIS-Kundenmanager und der LUIS-Serviceverantwortliche involviert; ein Beispiel für eine solche geringe Anforderung ist die Erweiterung des Papier-Portfolios in der Druckausgabe. Eine Veränderung, die aus Kunden- oder Nutzersicht als spürbare Verschlechterung eines bestehenden Services wahrgenommen werden kann, ist keine nur geringfügige Änderung. In Anhang A ist eine Aufstellung über die unterschiedlichen Anforderungstypen zu finden.

Die Anforderungen sollen zentral durch den Kundenmanager dokumentiert werden. Er informiert die LUIS-GL und den CIO innerhalb von zwei Woche nach Eingang über die neue Anforderung und das weitere geplante Vorgehen. Bei umfangreicheren Anforderungen sind weitere Recherchen durch den Kundenmanager notwendig, um Details der Anforderung zu ermitteln. Bei Änderungen, die Auswirkungen auf die SLAs oder die Servicequalität haben, muss der CIO frühzeitig eingebunden werden.

Nachdem die LUIS-interne Einschätzung der (umfangreichen) Anforderung erfolgt ist, wird ein Gremium einberufen, das über die mögliche Umsetzung und den Randbedingungen, wie Kosten, Finanzierungsquellen und Ressourcen berät und entscheidet. Das Gremium wird CAB (Change Advisory Board) genannt.

Gemäß den Empfehlungen der ITIL handelt es sich beim Anforderungsmanagement um einen speziellen Change-Management-Prozess, für den ein „Change Advisory Board“ (CAB) eingerichtet wird, um über die weitere Behandlung des Changes zu entscheiden. Die Anforderung zur Änderung an bestehenden Services oder zur Einführung neuer Services wird in diesem Zusammenhang als „Request for Change“ (RFC) bezeichnet1.

Der Anforderungsmanagementprozess im engeren Sinne ist als Change-Vorbereitung zu betrachten, da das eigentliche Design und die eigentliche Umsetzung in einem getrennten Projekt stattfindet.

Das CAB für das Anforderungsmanagement wird standardmäßig mit folgenden Rollen besetzt:

• CIO • Geschäftsleitung LUIS • Kundenmanager LUIS

Optional können – ggf. in Folgesitzungen – folgende Personen zum CAB eingeladen werden

• Abteilungsleiter und/oder Gruppenleiter des LUIS • Service-Verantwortliche, Fachkundige des LUIS • Anfordernde • IT-Sicherheitsbeauftragter • Datenschutzbeauftragter • Personalrat

In diesem Handbuch werden die Rollen, Zuständigkeiten, Aktivitäten und Abläufe für das Anforderungsmanagement beschrieben.

1 Abgrenzung zu „Service Request“ und „Incident“: siehe Glossar

Seite 6 von 18

2 Prozessziel und –zweck Grundsätzlich dient das Anforderungsmanagement den folgenden Zwecken:

• Erfassen und Dokumentieren der Anforderungen • Ggf. weitere Details der Anforderungen mit den Anfordernden und/oder Kunden (FIOs, ZE-

Leiter u.a.) klären • Einschätzungen des LUIS zur Anforderung einholen und dokumentieren • Einschätzung des LUIS zu den Kosten und dem Ressourcenbedarf einholen und

dokumentieren • Entscheidung zwischen CIO und LUIS herbeiführen, ob eine Anforderung implementiert wird

oder nicht. Ggf. wird der BIT einbezogen. • Entscheidung der Kosten- und Ressourcenübernahme • FIOs und IOs über neue Anforderungen und Entscheidungen informieren und ggf.

anschließende Diskussion in den FIO-Runden.

Der Prozess hat folgendes Ziel bzw. Ergebnis

• Zwischen CIO und LUIS abgestimmte Entscheidung über das Design und die Umsetzung der Anforderung (ja/nein)

• Erstellte Dokumente o Anforderungsspezifikation o Kostenschätzung und Abschätzung des Ressourcenbedarfs.

• Übergabe der Anforderungsdokumente an die Leitung des Design- und Umsetzungsprojekts. • Bei einer Ablehnung wird die Entscheidung im Ticketsystem dokumentiert, um zukünftige

Redundanzen zu vermeiden. • Sollten sich die Rahmenbedingungen für eine Ablehnung ändern, kann der LUIS-

Kundenmanager das RFC-Ticket wieder eröffnen und nochmals dem Anforderungsmanagementprozess zuführen. Als Beispiel für die Änderung einer Rahmenbedingung kann eine Kostensenkung bei einer extern angebotenen Technologie genannt werden: Bei der ersten Ablehnung waren die Kosten in Bezug auf den Nutzen zu hoch. Eine Neubewertung unter den verringerten Kosten führt jedoch zu einer positiven Kosten-Nutzen-Einschätzung.

Seite 7 von 18

3 Prozess-Eckdaten

3.1 Auslöser und Eingangsdaten

• Anforderung von extern an Kundenmanager (via support@luis). • Eingangsdaten: Initiale Formulierung der Anforderung

3.2 Ergebnisse und Ausgangsdaten

• Entscheidung über Anforderung • Wenn Entscheidung positiv, dann

o Anforderungsspezifikation o Kostenschätzung und Abschätzung des Ressourcenbedarfs. o Ernennung eines Projektleiters für das Designprojekt und das Umsetzungsprojekt o Übergabe der Dokumente an die Lenkungsgruppe des Designprojekts und des

Umsetzungsprojektes gemäß Projektmanagementhandbuch der LUH. • Wenn Entscheidung negativ, dann

o Information an Anfordernde/n, FIOs und ggf. BIT.

3.3 Rollen und Aufgaben

Rolle Aufgaben

Anfordernde Erstellen einer qualifizierten Anforderung Entscheidungen zur Kenntnis nehmen Ggf. Teilnahme am CAB

LUIS-IT-SD Entgegennahme und Weiterleitung der Anforderung an Kundenmanager

Kundenmanager

Dokumentieren der Anforderung CIO über Anforderungen informieren LUIS-interne Einschätzung einholen CAB einberufen Anforderungen und deren Einschätzung (CIO, LUIS) in FIO-Runde und BIT-Sitzung präsentieren und diskutieren

CIO

Entscheidung über Design und Umsetzung gemeinsam mit der LUIS-Leitung Teilnahme an CAB Präsentation/Diskussion von Entscheidungen im BIT

LUIS-L Leitung des LUIS Teilnahme an CAB Entscheidung über Design und Umsetzung gemeinsam mit CIO

LUIS-AL Abteilungsleiter des LUIS Ggf. Teilnahme an CAB

LUIS-SV Service-Verantwortliche des LUIS Ggf. Teilnahme an CAB

FIO-Runde Stellungnahmen abgeben zu den präsentierten Anforderungen

BIT Stellungnahme abgeben zu den präsentierten Anforderungen Beratung des CIO

ITSec IT-Sicherheit bzw. IT-Sicherheitsbeauftragter

Seite 8 von 18

DSB Datenschutzbeauftragter

3.4 Aktivitäten

Der Prozess zum Anforderungsmanagement umfasst die folgenden Aktivitäten. Hinweis: Die Liste impliziert keine zeitliche Reihenfolge der Aktivitäten. Der zeitliche Ablauf ist dem Kapitel 5 „Prozessablauf“ zu entnehmen.

• Anforderung (RFC) aufnehmen. Dabei werden auch LUIS-intern initiierte, umfangreiche Changes als RFC erfasst (siehe auch Anhang A)

• Status der Anforderung verwalten, siehe auch Kap. 4

• Rückmeldungen an Anfordernde(n), LUIS-Leitung, LUIS-AL, ggf. LUIS-SV, und CIO

• Anforderungen dokumentieren und weiter spezifizieren

• Prüfen, ob Anforderung aufgrund von offensichtlichen Kriterien obsolet ist

• Anforderungen in FIO-Runden präsentieren

• Einschätzung LUIS vornehmen

• Abschätzen von Kosten und Ressourcen

• Ggf. prüfen: Möglichkeiten des Outsourcing

• Ggf. prüfen: Mögliche Kooperationspartner

• CAB einberufen - notwendige Klärungen:

• Passt die Anforderung zur IT-Strategie?

• Aufwand-Nutzen-Abschätzung

• Klären der Zuständigkeiten

• Einbindung Personalrat?

• Klärungen zum Datenschutz und zur Informationssicherheit

• Ressourcen-Aufwand LUIS?

• Budget?

• Outsourcing?

• Klärung / Festlegung der Fachverantwortung

• Ergebnisse des CAB präsentieren (Nutzen vs. Aufwand, Ressourcen, Budget, ...)

• BIT-Sitzungen

• FIO-Runden

• Empfehlung des CIO diskutieren

• Entscheidung durch CIO verabschieden und/oder ggfs. Präsidiumsbeschluss herbeiführen und Beauftragung der Umsetzung durch CIO

• Übergabe der Dokumentation (Anforderungsspezifikation, Kosten- und Ressourcenabschätzung

• Benennung des Leiters des Design-Projekts und des Umsetzungsprojekts. Durchführung des Projekts gemäß [2]

• RFC im Ticketsystem schließen

Seite 9 von 18

4 Zustandsübergangsdiagramm Anforderungen Alle Anforderungen durchlaufen bestimmte Zustände vom initialen RFC bis zur endgültigen Entscheidung. In der folgenden Abbildung ist das Zustandsdiagramm für Anforderungen dargestellt.

Abb. 1: Zustandsdiagramm einer Anforderung

Der jeweilige Zustand einer Anforderung wird im jeweiligen RFC-Ticket festgehalten. So ist eine nachvollziehbare Historie der Zustandsübergänge und der weiteren Aktivitäten hinsichtlich einer Anforderung lückenlos und revisionssicher dokumentiert.

Die Zustandsübergänge müssen nicht immer komplett durchlaufen werden. So kann beispielsweise in einer CAB-Sitzung festgestellt werden, dass eine Zustimmung des BIT nicht notwendig ist.

Im folgenden Kapitel „Prozessablauf“ wird dargestellt, wann welcher Zustand eingenommen wird.

Der Kundenmanager berichtet in den FIO-Runden und BIT-Sitzungen über die Zustandsübergänge der einzelnen Anforderungen.

Seite 10 von 18

5 Prozessablauf Alle Prozessschritte im Anforderungsmanagement werden im Ticketsystem dokumentiert. Die Tickets erhalten den Typ „RFC“. Der Kundenmanager weist dem RFC eine passende Service-Kategorie zu.

Der Kundenmanager berichtet bei den FIO-Runden und in den BIT-Sitzungen über jede Zustandsänderung der Anforderung gemäß Abb. 1.

Der Prozessablauf lässt sich in drei Phasen aufteilen:

• Erfassung und Einschätzung der Anforderung • Beratungen im CAB • BIT und Entscheidung

Die Aktivitäten in diesen Phasen sind in den folgenden Diagrammen beschrieben.

5.1 Erfassung und Einschätzung der Anforderung

Abb.2: Prozess Anforderungsmanagement – Phase „Erfassung und Einschätzung“

Seite 11 von 18

5.2 CAB

Abb. 3: Prozess Anforderungsmanagement – Phase „CAB“

Hinweis: Entscheidungen im CAB sollen immer im Konsens mit allen Beteiligten getroffen werden. Sollte keine Entscheidung im gegenseitigen Einvernehmen getroffen werden können, so gilt der Eskalationsprozess nach der IT-Organisationsordnung [3].

Seite 12 von 18

5.3 BIT und Entscheidung

Abb. 4: Prozess Anforderungsmanagement – Phase „BIT und Entscheidung“

Seite 13 von 18

6 Zuständigkeitsmatrix (RACI) Die RACI-Matrix ist eine Spezialform der Verantwortlichkeitsmatrix, bei der es vier Arten von Zuständigkeiten gibt2:

Responsible – verantwortlich (Durchführungsverantwortung), zuständig für die eigentliche Durchführung. Die Person, die die Initiative für die Durchführung (durch Andere) gibt oder die die Aktivität selbst durchführt. Wird auch als Verantwortung im disziplinarischen Sinne interpretiert.

Accountable – rechenschaftspflichtig (Kostenverantwortung), verantwortlich im Sinne von „genehmigen“, „billigen“ oder „unterschreiben“. Die Person, die im rechtlichen oder kaufmännischen Sinne die Verantwortung trägt. Wird auch als Verantwortung aus Kostenstellensicht interpretiert.

Consulted – konsultiert (Fachverantwortung). Eine Person, deren Rat eingeholt wird. Wird auch als Verantwortung aus fachlicher Sicht interpretiert.

Informed – zu informieren (Informationsrecht). Eine Person, die Informationen über den Verlauf bzw. das Ergebnis der Tätigkeit erhält, oder die Berechtigung besitzt, Auskunft zu erhalten.

Die aufgeführten Rollen sind diejenigen aus Kapitel 3.3. Je nach Inhalt der Anforderungen können weitere Rollen an der Entscheidungsfindung beteiligt werden. Beispielhaft seien hier der Personalrat und der Datenschutzbeauftragte genannt.

Aktivität ANF LUIS-SPOC

LUIS-KM CIO LUIS-L,

AL, SV BIT FIOs ITSec, DSB CAB

Anforderung erstellen A,R

Anforderung (RFC) aufnehmen R A I I I I I

Zustände der Anforderung verwalten, siehe Kap. 4

A,R

Anforderungen weiter spezifizieren R A,R R R I I

Prüfen, ob Anforderung obsolet

A,R I

Anforderungen in FIO-Runden präsentieren

A,R I I I I

Einschätzung LUIS R I A,R

CAB einberufen I A,R R R I C, I I I

Entscheidung über Anforderung I I R R I C, I C A,R

2 De f in i t ion en tnommen aus : h t tp : / /de .wik iped ia .org /w ik i /RACI

Seite 14 von 18

Aktivität ANF LUIS-SPOC

LUIS-KM CIO LUIS-L,

AL, SV BIT FIOs ITSec, DSB CAB

Ergebnisse des CAB präsentieren A,R I I I C, I C

Empfehlung aus CAB diskutieren R A,R R R R R

Übergabe der Dokumentation3 an das Konzeptions- und Umsetzungsprojekt

I A,R I

Benennung des Leiters des Designprojekts und des Umsetzungs-projekts. Durchführung des Projekts gemäß [2]

I I I A,R

RFC im Ticketsystem schließen

A,R I I

3 Anforderungsspezifikation, Kosten- und Ressourcenabschätzung, Finanzierungsquellen

Seite 15 von 18

7 Anhang A: Erläuterung der Anforderungstypen / Change-Typen In der folgenden Tabelle sind die unterschiedlichen Anforderungstypen und deren Behandlung

aufgeführt. Gemäß dieser Tabelle werden nur umfangreiche Changes gemäß

Anforderungsmanagementprozess behandelt.

Anforderungstypen / Changes Authorisierung Bericht/Antwort Beispiele

Interner Change LUIS-Fachteam nur LUIS-internUpgrade einer Plattformsoftware,Upgrade einer Applikation ohne Änderung der Nutzerwahrnehmung

Standard-Change (auch: Service-Request) LUIS-Fachteam an Anfordernde(n)

Netzdose schalten, Lizenz bestellen, Web-Auftritt beantragen,APC-Service bestellen

geringer Change LUIS-intern an Anfordernde(n), CIO, FIO-Runde

Anpassung von Info-Seiten,Kapazitätserweiterung im Backup-Service

umfangreicher Change (Anforderungsmanagement)

LUIS-Leitung, CIO, CAB

an Anfordernde(n), CIO, FIO-Runde, BIT Neuer Service Bilddatenbank

Tab. 1: Anforderungstypen und deren Behandlung

Seite 16 von 18

8 Abkürzungsverzeichnis

ANF Anfordernde(r)

BPMN Business Process Modeling Notation

CAB Change Advisory Board

CIO Chief Information Officer

DSB Datenschutzbeauftragter

FAQ Frequently Asked Questions

FIO Faculty Information Officer

LUIS-L Leitung der ZE LUIS

LUIS-AL Abteilungsleiter im LUIS

LUIS-SV Service-Verantwortliche(r) im LUIS

IM Incident-Manager/Management

ITIL IT Infrastructure Library

ITSec IT-Sicherheit

ITSM IT Service Management

KDB Knowledge Data Base

KM Kundenmanager

LUH Leibniz Universität Hannover

RFC Request for Change

SPOC Single-Point of Contact

SV Service-Verantwortliche(r)

ZE Zentrale Einrichtung

Seite 17 von 18

9 Glossar Grundsätzlich wird das ITIL-Glossar zugrunde gelegt und bei Bedarf erweitert bzw. angepasst. Die wichtigen Begriffe im Rahmen des Anforderungsmanagements sind an dieser Stelle definiert.

Begriff Definition

Anwender/Anwenderin (User)

Eine Person, die einen IT Service im Rahmen ihrer täglichen Aufgaben einsetzt. Anwender sind von Kunden zu unterscheiden, da manche Kunden die IT Services nicht unmittelbar nutzen. [1]

Change

Hinzufügen, Modifizieren oder Entfernen eines Elements, das Auswirkungen auf die IT Services haben könnte. Der Umfang eines Change sollte sämtliche IT Services, Configuration Items, Prozess, Dokumentationen etc. einschließen.

Change Advisory Board (CAB)

Eine Gruppe von Personen, die den Change Manager bei der Bewertung, Festlegung von Prioritäten und zeitlichen Planung in Bezug auf Changes beraten. Dieses Gremium setzt sich in der Regel aus Vertretern aller Bereiche des IT Service Providers, dem Business und den Drittparteien wie z.B. Suppliern zusammen.

Kunde/Kundin (Customer)

Person, die Waren oder Services erwirbt. Der Kunde eines IT Service Providers ist die Person oder Gruppe, mit der die Service Level Ziele definiert und vereinbart werden. Der Begriff „Kunde“ kann sich in einem informellen Kontext auch auf „Anwender“ beziehen, z. B.: „Das ist eine kundenorientierte Organisation“. An der LUH sind ausschließlich Präsidium / CIO, Dekane / FIOs und die Leitungen der zentralen Einrichtungen und der Verwaltung als Kunden benannt.

Request for Change (RFC)

Der formale Antrag zur Durchführung eines Change. Ein RFC beinhaltet Details zum beantragten Change und kann auf Papier oder elektronisch erfasst werden. Der Begriff „RFC“ wird häufig fälschlicherweise für einen Change Record oder den Change selbst verwendet.

Service Request

Eine Anfrage eines Anwenders nach Informationen, Beratung, einem Standard-Change oder nach Zugriff auf einen IT Service. Dabei könnte es sich beispielsweise um das Zurücksetzen eines Passworts oder die Bereitstellung standardmäßiger IT Services für einen neuen Anwender handeln. Service Requests werden in der Regel von einem Service Desk bearbeitet und erfordern üblicherweise nicht die Einreichung eines RFC.

Incident

Eine nicht geplante Unterbrechung eines IT Service oder eine Qualitätsminderung eines IT Service. Auch ein Ausfall eines Configuration Item ohne bisherige Auswirkungen auf einen Service ist ein Incident. Beispiel: Ein Ausfall einer oder mehrerer Festplatten in einer gespiegelten Partition.

Seite 18 von 18

10 Referenzen [1] itSMF, Arbeitskreis Publikation, ITIL® Version 3 Translation Project: ITIL V3 – Glossar (Englische

Basisversion: 3.1.24), Version: 31.08.2007

[2] Projektmanagement - Handbuch für Projekte der Leibniz Universität Hannover, Herausgeber: Der Präsident der Leibniz Universität Hannover, Stand: November 2009

[3] Ordnung zur IT-Organisationsstruktur für die Gottfried Wilhelm Leibniz Universität Hannover, Verkündungsblatt der Gottfried Wilhelm Leibniz Universität Hannover vom 23.10.2015, Nr. 21/2015