Document toolboxDocument toolbox

Change- en releasemanagement

Het change- en releasemanagementproces zorgt voor een verantwoordelijke en gecontroleerde manier van het aanvragen, uitvoeren en evalueren van wijzigingen in de bestaande Mitz-voorziening en dienstverlening.

Het Mitz-productmanagement is het centrale punt waarbij de wijzigingsverzoeken vanuit alle betrokken partijen in de keten binnenkomen. De wijzigingsverzoeken worden verzameld en geregistreerd in de backlog. De analyse van de backlog leidt tot een releasekalender waarin gekeken wordt naar de businessprioriteit (hoog, midden, laag) en de businessimpact (major, minor, fix). De releasekalender wordt in samenspraak met de deelnemers opgesteld waarbij ruimte wordt geboden voor feedback van de deelnemers op inhoud en doorlooptijd.

Hieronder wordt de change- en releasemanagementprocessen nader toegelicht. Evenals de procedure voor het communiceren van voorgenomen wijzigingen voor de MC-leverancier en zorgaanbieder(systemen).

Changemanagement

Een wijziging betekent een toevoeging, aanpassing of verwijdering in de operationele dienstverlening en kan een lokale of ketenbrede impact hebben.

Het changemanagementproces voor wijzigingen omvat de volgende stappen:

  1. aanvragen wijziging

  2. bepalen impact

  3. besluiten over wijziging door het Change Advisory Board (CAB)

  4. wijziging opnemen op de releasekalender

  5. uitvoeren wijziging

  6. evalueren

De stappen staan hieronder nader omschreven.

#

Stap

Omschrijving stap

#

Stap

Omschrijving stap

1

Aanvragen wijziging

Een voorstel tot wijziging kan via de volgende routes kenbaar worden gemaakt:

  • een zorgaanbieder kan wijzigingsverzoeken indienen bij het Mitz-productmanagement.

  • een MC-leverancier kan wijzigingsverzoeken indienen bij het Mitz-productmanagement.

  • burgers kunnen wijzigingsverzoeken aandragen bij de infolijn Mitz. Relevante verbeteringen en voorstellen worden doorgezet naar Mitz. Daarnaast kan de infolijn Mitz op basis van de klantcontacten wijzigingen voorstellen.

2

Bepalen impact

Mitz zorgt voor nadere specificatie van de wijzigingsverzoeken en legt ze vast in een Request for Change (RFC). Ook definieert Mitz een oplossing en brengt de impact in kaart. 

3

Besluit wijziging door CAB

Vervolgens brengt het Mitz-productmanagement het wijzigingsvoorstel in een CAB in. Deze bestaat uit de Mitz-productmanager, de manager Operations en de Mitz-bedrijfsarchitect. Het CAB maakt de afweging of de wijziging wenselijk en verantwoord is.

4

Wijziging opnemen op releasekalender

RFC's worden - afhankelijk van de impact - uitgevoerd als fix of opgenomen in de releasekalender als onderdeel van een minor of major release. Deelnemers worden op tijd geïnformeerd en om feedback gevraagd over de changes in de volgende release en de impact op het gehele systeem.

5

Uitvoeren wijziging

Minor en major releases volgen een vast patroon conform de afgesproken releasekalender. Alle geïmplementeerde wijzigingen worden conform het testtraject van Mitz op de testomgeving getest, op de acceptatieomgeving geaccepteerd en bij goedkeuring van het CAB doorgevoerd op de productieomgeving.

Een MC-leverancier heeft de verplichting om relevante wijzigingen te testen op hun testomgeving en te accepteren op de acceptatieomgeving. En om te participeren in de benodigde testen. Dit betreft een fix die de MC-leverancier raakt, een minor die de Mitz Connector raakt en alle major releases.

De coördinatie van het doorvoeren van wijzigingen ligt bij de Servicedesk Mitz (zie https://vzvz.atlassian.net/wiki/spaces/MA11/pages/127535340).

Zorgaanbieders zijn zelf verantwoordelijk voor de coördinatie en communicatie van wijzigingen met hun leveranciers (zoals US en XIS), het testen, accepteren en uitvoeren.

Wijzigingen en releases worden bij niet-succesvolle testen, acceptaties en inproductienames niet doorgevoerd maar opnieuw ingepland.

6

Evalueren wijziging

Na het invoeren of uitstellen van een wijziging volgt een evaluatie. Hierbij wordt de wijziging geëvalueerd op alle aspecten zoals de impact, de coördinatie, het testen en de communicatie. En wordt input verzameld voor het eventueel bijstellen van de releasekalender.

Releasemanagement

Wijzigingen in Mitz worden uitgerold in releases. Het change- en releasemanagementproces onderscheidt drie type wijzigingen, die in onderstaande tabel zijn weergegeven. 

Categorie

Major change

Minor change

Fix

Categorie

Major change

Minor change

Fix

Omschrijving

De verandering vereist een actie of aanpassing voor een groot deel van de MC-leveranciers, zorgaanbieders en/of burgers

De koppelvlakken met Mitz moeten aangepast worden

De verandering vereist een actie of aanpassing voor een klein deel van de MC-leveranciers, zorgaanbieders en/of burgers

Aanpassingen aan het toestemmingsregister en/of de toestemmingsapplicatie die geen impact hebben op de functionaliteit

Overige aanpassingen

Releasenummering

Releaseverhoging

Voorbeeld: release 3.x.x naar 4.0.0

Versieverhoging

Voorbeeld: versie 3.4.1 naar 3.5.0

Subversieverhoging

Voorbeeld: versie 3.4.1 naar 3.4.2

Mitz heeft compatibiliteit met de huidige en de vorige major release. Per jaar worden maximaal twee major releases uitgebracht.

Voor de correcte werking van de Mitz-functionaliteiten, koppelvlakken en snelkoppelingen is het dus van belang dat een MC-leverancier en alle partijen die een Mitz-functionaliteit gebruiken (bijvoorbeeld het XIS van een zorgaanbieder) maximaal één major release achterloopt.

Wijziging Mitz Connector of zorgaanbieder(systemen)

De MC-leveranciers en leveranciers van zorgaanbiedersystemen zijn belangrijke spelers in het changemanagementproces. Zij hebben immers het best zicht op wijzigingen die zij doorvoeren voor hun klanten. 

Mitz Connector

Een MC-leverancier communiceert tijdig voorgenomen wijzigingen die impact kunnen hebben op de toestemmingsketen, inclusief de impact op de gehele keten en de planning. De communicatie verloopt via de servicedesk Mitz (zie https://vzvz.atlassian.net/wiki/spaces/MA11/pages/127535340).

De MC-leverancier stemt de voorgenomen wijziging goed met Mitz af om te voorkomen dat er problemen in de keten ontstaan. Op basis van de wijziging en de impact ervan bepaalt Mitz wat de stappen zijn die de MC-leverancier moet doorlopen.

Bij grote wijzigingen met grote impact en/of wijzigingen die de koppelvlakken en berichten raken, moet de MC-leverancier altijd een testtraject en heracceptatie uitvoeren. Zie https://vzvz.atlassian.net/wiki/spaces/MA11/pages/127535108.

Zorgaanbieder(systemen)

De zorgaanbieder is verantwoordelijk voor de eigen systemen (zoals US en XIS).

De zorgaanbieder communiceert via de servicedesk van zijn MC-leverancier (zie ) de voorgenomen wijzigingen die impact kunnen hebben op Mitz. Hierbij geeft de zorgaanbieder aan wat de impact van de voorgenomen wijziging op de gehele keten is. De zorgaanbieder is verantwoordelijk voor de coördinatie, de planning en het testen van wijzigingen van eigen aangesloten systemen.