Sessieronde 3

1. Grip op wijzigingen in mijn SIS
18-6-2015
Thomas Dessing (t.dessing@dsz.ru.nl)
Luuk Geurts (l.geurts@dsz.ru.nl)

2. Inhoud
• Waarom gestructureerd wijzigingsbeheer
• Kader (BiSL)
• Hoe gaat het wijzigingsbeheer van OSIRIS bij de RU met TopDesk
• DEMO
• samenvatting

3. Waarom?
• Grip krijgen en houden op wijzigingsverzoeken
• Grip krijgen op de implementatie van de wijzigingen
- Planning
- Testen (ook in keten)
- Accepteren
• Grip op incidentmanagement
• Verantwoording (naast autorisatie ook inzicht in het proces van
gecontroleerde wijzigingen)
LET OP: Radboud Universiteit doet hosting in house!!!

4. BiSL

5. Versies
Wijzigingen beheer proces OSIRIS
wens incident
Functionele Wijziging
Wijzigingen Lokale CAO voorbereiding
Geprioriteerde wijzigingen
CAO (CAO nummer)
Goedgekeurde CAO wijzigingen
Transitie Wijziging
Functioneel FW Transitie TW
Activiteit 1 Releasenotes maken
Activiteit 2 Testen Inschrijf
Productie
Activiteit 3Testen Volg
Activiteit 4Testen Aanmeld
Activiteit 5 Ketentest
Goedkeuring
Applicatie AW
Impact analyse
Applicatie wijziging
Activiteit 6 etc.

6. Wijzigingen eenvoudig en uitgebreid
FW
TW - AW

7. Functionele wijziging (FW)
• Wens komt binnen als “Voorlopig wijigingsverzoek”:
- Status = ingediend
- Behandelaar = Functioneel beheerder
- Prio = leeg
• Na behandeling in de RU gebruikersgroep als “Wijzigingsverzoek”
- Status = ingediend óf wacht / gesloten
- Behandelaar = CAO óf Functioneel beheerder
- Prio = P1 óf P2
• Na behandeling in CAO
- Status = In behandeling
- Behandelaar = CAO óf Functioneel beheerder

8. Transitie wijziging (TW)
• Status = ingediend
• Prio = nvt
• Behandelaar = Functioneel beheerder
• Sjabloon = Transitie wijziging (met diverse activiteiten)
• Activiteiten:
- Testen
- Releasenotes maken
- Inrichten tabellen
- Etc.

9. Applicatie wijziging (AW)
• Interne communicatie binnen ISC
• Waarborgen veiligheid en integriteit van het systeemlandschap
• CAB kalender

10. Wijzigingen op basis van sjablonen
• Elke wijzigingssoort (FW, TW en AW) heeft een sjabloon waarin de
activiteiten die wezenlijk zijn voor de wijziging zijn voorgedefinieerd,
bijvoorbeeld:
- Incident wordt wijziging, mbv functionaliteit van TopDesk, en obv FW
sjabloon
- Patch wordt uitgebracht. Obv TW sjabloon worden de benodigde
activiteiten vastgelegd
- Release’s worden gepland. Obv sjabloon worden uitgebreide activiteiten
sets gedefinieerd. Release TW’s worden ver in het vooruit vastgelegd,
zodat je daarop kunt plannen.
- Bij een geplande AW, wordt o.b.v. een sjabloon alle betrokken partijen
binnen het ISC goedkeuring gevraagd obv de onderliggende activiteiten
- Communicatie naar key-users gebeurt obv groepen en mailsjablonen.
Hiervan maken alle wijzigingssoorten gebruik

11. DEMO
Generieke inrichting
• Inrichting van vergaderingen (wensen en status) 6.16.1
• Inrichting van Versies (met wijzigingen) 6.15.1
• Inrichting van wijziging (afgeronde TW, planning, activiteiten, gantt chart)
6.15.1
• Inrichting van sjablonen
Usecase: “Cariere van een incident” Osiris release 6.16.2
• Incident wordt wens o.b.v. sjabloon
• Wordt gekoppeld aan vergadering (vergaderlijst)
• Wordt geprioriteerd en goedgekeurd lokaal (statussen, CACI nummer)
• Geselecteerd in CAO (statussen, koppelen aan versie, testvoorbereiding)
• Implementatie (statussen vanuit versie)

12. Samenvatting
• Snelheid vergaderlijsten CAO
• Snelheid van incident naar wens
• Grip op planning
- Uitrol patches etc
- Verschillende omgevingen
• Transparante communicatie naar key-users en applicatie beheer
• Governance op wijzigingen beheer (IAD)
• Still improving (evaluatie)