Informationen zum ILTIS-Change-Management
Ab 1. März 2011 wird im ILTIS-Katalogsystem ein neues Verfahren für die Planung, Bearbeitung und Durchführung von Anforderungen an das ILTIS-Katalogsystem eingeführt.
Zielsetzungen
- der Aufwandes für ChangeRequests, die als Jira-Tickets gemeldet werden, soll durch Bündelung der Anforderungen reduziert werden
- die MitarbeiterInnen der IT sollen sich stärker auf zeitkritische (Projekt-)Aufgaben konzentrieren können
- die Information der Fachabteilungen über die Anforderungsplanung soll transparenter und zuverlässiger werden
- die Bearbeitung von Anforderungen, die als Jira-Tickets gemeldet wurden, soll kontrollierter und zeitnaher erfolgen
- auch innerhalb der IT soll eine klare Regelung helfen Transparenz und Zuverlässigkeit zu erzeugen
Abgrenzungen
Folgende Anforderungen, Meldungen werden nicht in diesem Verfahren behandelt:
- akute Fehlermeldungen, die zu einer Störung in ILTIS führen, werden sofort bearbeitet
- Anforderungen, die sich aufgrund Einführung und Test eines neuen Verfahrens, Geschäftgangs, etc. ergeben, werden nach wie vor zeitnah bearbeitet
Realisierung
Je nach Art der Anforderung (siehe Tabelle) werden bestimmte Stichtage festgelegt,
- zu denen die Anforderung in IT eingegangen sein muss
- zu denen die Realisierung der Anforderung nach erfolgreichem Test produktiv gesetzt wird.
Anforderungen, die für einen bestimmten Termin produktiv gesetzt werden sollen, müssen zum Stichtag des Anforderungseingangs in IT als Jira-Ticket vorliegen. Die Fachabteilungen sollten nun jedoch nicht alle Anforderungen erst zum Stichtag schicken, sondern diese bereits vor dem Stichtag an die IT schicken. Es gilt weiterhin die generelle Regel, dass die Anforderungen nach Eingang bearbeitet werden. Die Anforderungen werden von IT in Jira der entsprechenden Release-Version zugeordnet.
Anforderungen werden von der IT analysiert, bevor sie zur weiteren Bearbeitung freigegeben werden. Aufgrund dieser Analyse kann es zu einer Verschiebung bei der Realisierung kommen. Je exakter und vollständiger eine Anforderung gestellt wird (Detailangaben, Beispiele, Kommandos) desto schneller kann die Bearbeitung durch die IT erfolgen!
Sollte eine Realisierung aller von den Fachabteilungen übermittelten Anforderungen nicht möglich sein, so behält sich die IT vor, die Bearbeitung einzelner Anforderungen zu verschieben.
Auch eine Verschiebung aufgrund von Ressourcenengpässen in der IT, die sich geplant (hoch priorisierte Projekte, Dienstreisen, Urlaub, etc.) und ungeplant (Krankheit) ergeben können, ist - wie bisher - möglich.
Arbeitsbereich |
Anforderungseingang
Frequenz, Stichtag, Beginn |
Produktivsetzung
Frequenz, Stichtag, Beginn |
Name der Releaseversion in Jira |
Anpassungen des Datenformates, der Validation, der Expansion und der Indexierung |
monatlich zum 15.
(also ca. 2 Wochen vor der Produktivsetzung)
1. Stichtag: 15.03.2011
|
monatlich am 1.
(also ca. 2 Wochen nach dem Anforderungseingang)
1. Stichtag: 01.04.2011
|
CBS-Konfigurations-Release MM/JJ
z.B. CBS-Konfigurations-Release 04/11
(ACHTUNG: DNB-interner Link!)
|
Anpassungen der Importkonversionen (MARC21, ONIX, XMetaDiss, Formulardaten)
|
jeden 2. Monat zum 15.
(also ca. 2 Wochen vor der Produktivsetzung)
1. Stichtag: 15.04.2011
|
jeden 2. Monat am 1.
(also ca. 2 Wochen nach dem Anforderungseingang)
1. Stichtag: 01.05.2011
|
Importformate-Release MM/JJ,
z.B.
Importformate-Release 05/11
(ACHTUNG: DNB-interner Link!)
|
Anpassungen der Exportkonversionen (MARC21, MAB)
|
MAB: halbjährlich (1.12./1.6.)
MARC21: vierteljährlich (1.12/1.3./1.6./1.10.)
(also jeweils ca. 4 Wochen vor der Produktivsetzung)
|
MAB: halbjährlich (1.1./1.7.)
MARC21: vierteljährlich (1.1/1.4./1.7./1.11.)
(also jeweils ca. 4 Wochen nach dem Anforderungseingang)
|
Exportformate-Release MM/JJ
|
Beispiele für das Zusammenspiel von Anforderungseingang und Produktivsetzung:
- Eine Anforderung an die Validation im Katalogsystem muss bis zum 15.03.2011 in IT vorliegen, damit sie am 01.04.2011 produktiv gesetzt werden kann.
- Eine Anforderung an den Import von MARC21 muss bis zum 15.04.2011 in IT vorliegen, damit sie am 01.05.2011 produktiv gesetzt werden kann.
Zeitplanung
- Beginn des Verfahrens
Das Verfahren beginnt ab 01.03.2011, d.h. dass alle Anforderungen, die ab diesem Stichtag eingehen, nach dem neuen Verfahren bearbeitet werden.Ggf. werden jedoch bereits bestehende Anforderungen in die Releaseplanungen integriert.
- Review des Verfahrens
Im Juli 2011 wird ein Review dieses Verfahrens erfolgen, bei dem entschieden wird, ob es weitergeführt, angepasst oder wieder abgeschafft wird.