Quality Assurance - Proceskaart - Beheren 3.0.0

1 Procesdoel

Het doel van dit proces is:

• Het volgens de afspraken met de houder doorvoeren van wijzigingen op een bestaande usecase/informatiestandaard.

1.1 Proceseigenaar

Onno Gieling

2 Proces

2.1 Procesdiagram



2.2 Procesactiviteiten

Nr.	Verantwoordelijk	Activiteiten	Hulpmiddelen
1.	Indiener	Wijzigingsverzoek in BITS Op het moment dat een externe partij of een interne medewerker een probleem constateert in een informatiestandaard of ander relevant product, wordt hiervoor een wijzigingsverzoek aangemaakt via het Servicemanagementloket. Als een medewerker via een ander kanaal (bijv. telefoon, e-mail) een melding ontvangt over een geconstateerd probleem, wordt de externe partij doorverwezen naar dit loket of maakt de medewerker zelf een ticket aan. “Wijzigingsverzoek” moet in de breedste zin van het woord geïnterpreteerd worden. Het kan een heel concreet verzoek tot wijziging zijn, maar ook de constatering dat er iets mis is, dat verder onderzocht moet worden (in dit geval log je een 'bevinding').	BITS, Servicemanagementloket
2.	Servicemanagement	Intake wijzigingsverzoek Servicemanagementloket De intake door het servicemanagementloket is bedoeld om te controleren of het wijzigingsverzoek de relevante informatie bevat om inhoudelijk te kunnen behandelen. De intake is in principe geen inhoudelijke beoordeling.
3.	Servicemanagement	Voldoet aan de eisen? Het servicemanagementloket controleert of de volgende zaken duidelijk zijn: Gaat het om een wijzigingsverzoek of een bevinding van een probleem? Of is het eerder een vraag of klacht? Is het probleem duidelijk (genoeg) omschreven? Is het duidelijk waar het probleem over gaat? Dus welke informatiestandaard, profiel, zib, etc. en welke versie daarvan? Is de urgentie duidelijk? NB. er hoeft nog geen voorstel voor een oplossing te zijn. Bij ontbrekende of onvolledige informatie wordt de Indiener om aanvullende informatie gevraagd. Wanneer het wijzigingsverzoek van voldoende kwaliteit is, zet het servicemanagementloket het door naar het juiste team.	BITS
4.	Indiener	Indiener vult wijzigingsverzoek aan. Desgevraagd vult de indiener op verzoek van het servicemanagementloket het wijzigingsverzoek aan zodat dit door het juiste team kan worden verwerkt.	BITS
5.	IA/SGU	Analyse wijzigingsverzoek: De Informatieanalist en/of Specialist Gegevensuitwisseling voert een inhoudelijke analyse uit, zo nodig in afstemming met externe stakeholders, de productmanager, een adviseur, kwalificatiespecialist en andere Nictiz-specialisten. Tijdens de analyse moeten in ieder geval de volgende vragen beantwoord worden: (Is het issue bij het juiste team terechtgekomen? Zo niet, dan wordt het doorgezet of terugverwezen naar het servicemanagementloket). Bestaat het geconstateerde probleem daadwerkelijk? Doet het probleem zich ook voor in andere (versies van) informatiestandaarden? Is het direct duidelijk wat er gedaan moet worden om het probleem op te lossen, of is hier significant uitzoekwerk voor nodig? Indien direct duidelijk is wat er gedaan moet worden, wat is dan: De impact volgens SemVer? De tijdsinvestering? Bij de analyse kan de checklist ‘Analyse wijzigingsverzoek’ gebruikt worden. De IA/SGU legt de analyse en communicatie met de Indiener vast in BITS.	BITS, Checklist analyse wijzigingsverzoek [Download]
6.	PO	Bestaande UC? Als uit de analyse blijkt dat het om een nog niet bestaande usecase gaat, spreken we niet over wijzigingsbeheer maar over een nieuwe ontwikkeling. Dit begint bij het proces “Verkennen”. Het BITS-issue wordt gemigreerd naar type “Verzoek”. De bevindingen van de verkenning en mogelijke doorontwikkeling worden hierin geregistreerd.	BITS
7.	PO	Gedelegeerde verantwoordelijkheid beheer? De beslissingsverantwoordelijkheid over een wijziging ligt bij de autorisator. Voor de beoordeling door de autoristor gelden geen andere eisen dan bij een nieuwe ontwikkeling. Het wijzigingsverzoek volgt daarom in principe (een deel van) het proces Verkennen (waarna het eventueel door kan gaan naar Ontwikkelen & Testen en daarna Publiceren). Veel wijzigingsverzoeken zijn echter zo triviaal, klein, en/of specialistisch van aard dat de route van een nieuwe Verkenning, met autorisatie, een te grote overhead met zich meebrengt. Om dit te voorkomen, wordt in het beheerdocument afgesproken dat de autorisator de verantwoordelijkheid voor dit soort triviale wijzigingen aan Nictiz overlaat. Bij het inrichten van het beheer zijn afspraken met de autorisator gemaakt over de grenzen van deze “gedelegeerde verantwoordelijkheid”. Indien direct duidelijk is wat er gedaan moet worden om het probleem op te lossen, en indien de tijdsinvestering gering is en indien er voldoende noodzaak is, maakt het team dus zelf de afweging om het wijzigingsverzoek op te pakken.	BITS
8.	PO	Classificatie is Patch? Als de oplossing een classificatie krijgt van “patch” volgens de SemVer-methodiek – er is geen impact op de compatibiliteit en er wordt geen nieuwe functionaliteit toegevoegd – Mag deze wijziging zonder tussenkomst van een autorisator worden doorgevoerd. Gebruiker moet expliciet geïnformeerd worden? Een kernwaarde van het wijzigingsbeheer is om transparant te zijn naar de buitenwereld over wat er gaat gebeuren en over wat er gebeurd is. Dit is nodig zodat gebruikers en eindgebruikers kunnen goed geïnformeerd zijn over wijzigingen. Soms is de wijziging echter zo triviaal dat de (eind)gebruikers er niet expliciet over geïnformeerd hoeven te worden. In dat geval hoeft er ook geen uitgebreide administratie gevoerd te worden, zoals het invullen van een oplossingsvoorstel of release notes. Dit gaat over overduidelijke spelfouten, het herstellen van doodlopende links, of een refactoring-slag waarmee het resultaat voor de gebruiker hetzelfde blijft. De wijziging wordt wél gelogd in BITS en bij de wijziging zelf is er wél een verwijzing naar het BITS-issue. Bij het inrichten van het beheer is hiervoor een werkwijze afgesproken. Bij twijfel over de vraag of de gebruiker expliciet geïnformeerd moet worden, moet altijd gekozen worden voor wél expliciet informeren. Als het wijzigingsverzoek bijvoorbeeld gaat over het verduidelijken van een verwarrende tekst, moet het via de normale procedure worden afgehandeld.
9.	IA/SGU	Wijzigingsvoorstel: De IA/SGU formuleert in samenspraak met de relevante betrokkenen een concreet oplossingsvoorstel. Hiervoor zijn de volgende mogelijkheden: Voorstel tot realisatie. Voorstel tot afwijzing. Voorstel tot uitstel naar de toekomst, bv. Omdat de releasekalender het niet op korte termijn toelaat om een wijziging met deze impact door te voeren. In dit geval kan het nodig zijn om een tweede wijzigingsverzoek te maken waarin het probleem alleen wordt gedocumenteerd voor de gebruiker, of waarin een workaround wordt doorgevoerd die wel compatibel is. Daarnaast worden bepaald: De impact van de wijziging volgens SemVer-methodiek. De release waarin de wijziging wordt doorgevoerd. Vervolgens wordt het wijzigingsvoorstel opgenomen in het projectplan voor de ontwikkeling van een nieuwe versie van de standaard (Ontwikkelen & Testen)
10.	IA/SGU	Uitwerken oplossing: De IA/SGU voert de wijziging door. De acties en de voorgestelde uitwerking worden vastgelegd in het BITS-issue, zodat stakeholders inzicht krijgen in de daadwerkelijke aanpassing.
11	Andere Nictiz medewerker met zelfde specialisatie. (vakgroepgenoot)	Interne kwaliteitscontrole: Vóór publicatie wordt de wijziging beoordeeld volgens de afgesproken interne kwaliteitscontroles. In ieder geval geldt altijd het vierogen-principe. Daarnaast kunnen er per product en per onderdeel aanvullende controles worden afgesproken. Dit is aan de teams om hier een zinvolle invulling aan te geven. Als de uitwerking is goedgekeurd, wordt deze via het proces Publiceren naar productie gebracht.	BITS

3 Context

Het wijzigingsbeheer van informatiestandaarden en generieke standaarden bij Nictiz is gebaseerd op de NEN 7522. Via het Duurzaam Releasebeleid van Nictiz wordt deze NEN-norm verder ingevuld een aangevuld met best practices uit onder meer ITIL en BOMOS. Dit QA-proces is ten slotte bedoeld om het Duurzaam Releasebeleid te vertalen naar de praktijk binnen Nictiz.

Voor een eenduidig wijzigingsbeheer zijn twee zaken belangrijk:

1. De inrichting van het wijzigingsbeheer. Op het moment dat een usecase/informatiestandaard gepubliceerd wordt, moet er een beheerdocument zijn met afspraken over rolverdeling, werkwijze, etc. Hiervoor is een aanvullende checklist beschikbaar.

2. De uitvoer van het wijzigingsbeheer. Nadat een usecase/informatiestandaard gepubliceerd is, moeten wijzigingsverzoeken correct en eenduidig worden verwerkt. Dit kan alleen gedaan worden als de inrichting op orde is. Deze proceskaart geeft verder invulling aan de uitvoer van het wijzigingsbeheer.

Uitgangspunten

1. Nictiz vervult voor beheer doorgaans de rol van Functioneel Beheerder van een informatiestandaard, en aanvullend die van Technisch Beheerder en Distributeur. Daarnaast kan Nictiz Experts leveren. Dat komt erop neer dat Nictiz de organisatorische en praktische zaken rond beheer en publicatie regelt, in opdracht van de Houder.

2. Binnen Nictiz geldt de afspraak dat we BITS gebruiken voor wijzigingsbeheer. Hiervoor is het projecttype “Ontwikkeling en beheer” beschikbaar (O&B). De issuetypes “Wijzigingsverzoek” en “Verzoek” binnen dit projecttype zijn afgestemd op deze proceskaart.

3. Wijzigingsbeheer dient open en transparant te gebeuren. Dat wil onder meer zeggen dat alle wijzigingsverzoeken, alle besluitvorming rond deze wijzigingsverzoeken, en alle discussies die ten grondslag liggen aan deze besluitvorming, inzichtelijk moeten zijn voor stakeholders. Zoals hierboven beschreven, is BITS het aangewezen medium om dit te loggen.

4. In een aantal gevallen leidt een wijzigingsverzoek tot een nieuwe verkenning of ontwikkeling. Op deze momenten verwijst de proceskaart naar de relevante QA-proceskaarten.

4 Procesrisico’s en beheersmaatregelen

Risico’s	Beheersmaatregelen
Onduidelijkheid over rollen en verantwoordelijkheden, waardoor gestandaardiseerd werken wordt ondermijnd	Inzichtelijk maken en communiceren procesgang met behulp van proceskaart, inclusief RACI-tabel
Ontbreken van kennis over wet- en regelgeving en het zorgveld, waardoor het veld Nictiz onvoldoende serieus neemt en draagvlak afneemt	Opnemen in onboardings-beleid Opleiden medewerkers (Nictiz Academy)
Onvoldoende bemensing (kwantiteit en kwaliteit) bij Nictiz voor uitvoeren van beheer, waardoor werkzaamheden niet of te laat worden uitgevoerd.	Zorgdragen voor voldoende goede mensen door middel van effectieve werving en selectie Opleiden medewerkers (Nictiz Academy)
Een informatiestandaard voldoet niet aan de eisen/behoeften van stakeholders	Feeling van het veld blijven houden, vinger aan de pols Samen met externe belanghebbenden doorontwikkelen van standaarden Duidelijke specificaties voorafgaand aan doorontwikkeling opstellen Expert community inrichten
Financiering vanuit de zorg om de standaard te implementeren is niet geregeld	Zorgdragen voor financiering voorafgaand aan (door)ontwikkeling van een standaard
Releasemanagement van verschillende standaarden is arbitrair, waardoor onvoldoende rekening wordt gehouden met samenhang en gestandaardiseerd werken ondermijnd wordt	Gebruik van Duurzaam Releasebeleid en bijbehorende meerjarenplanning voor alle informatiestandaarden
Het maken van een verkeerde inschatting van de impact voor implementerende partijen, waardoor zij niet overgaan tot implementatie	Voorafgaand aan ontwikkeling consulteren stakeholders Expertcommunity inrichten
Oplossingen en releasemanagement duurt te lang waardoor ontevreden stakeholders	Balans zoeken tussen snelheid en stabiliteit Goede communicatie richting stakeholders
Releases volgen elkaar te snel op waardoor leveranciers continu systemen moeten aanpassen, waardoor mogelijk draagvlakverlies	Balans zoeken tussen snelheid en stabiliteit Goede communicatie richting stakeholders Goede grip op de impact van wijzigingen op voorgaande standaarden Duidelijk en voorspelbaar releasebeleid

5 RACI-tabel

Toelichting:

• In de tabel zijn per procesactiviteit de verantwoordelijke (Nictiz-)functies benoemd. Tussen haakjes achter de functienaam is steeds de overeenkomstige NEN 7522 rol aangeduid (indien van toepassing)
• R (Responsible) = verantwoordelijke voor de uitvoering van de activiteit
• A (Accountable) = eindverantwoordelijke voor de uitvoering van de activiteit
• C (Consulted) = geraadpleegde(n) bij de uitvoering van activiteit
• I (Informed) = geïnformeerde(n) over de uitvoering van de activiteit

		Servicemanagementloket	Productmanager	Product Owner	Informatieanalist	Specialist Gegevensuitwisseling	Adviseur	vakgroepgenoot	Externe experts (Experts)	Indiener wijzigingsverzoek (Gebruiker)	Autorisator	Leveranciers en gebruikers (Gebruikers)
Nr.	Activiteit
1.	Wijzigingsverzoek in via Servicedesk									R,A
2.	Uitvoeren intake wijzigingsverzoek	R,A								I
3.	Voldoet aan de eisen?	R,A								I
4.	Indiener vult wijzigingsverzoek aan.	C,I								R,A
5.	Analyseren wijzigingsverzoek	I		A	R	R	C	C	C	I		C
6.	Bestaande uscase?	I	A	R	C	C	C			I
7.	Gedelegeerde verantwoordelijkheid beheer?	I	A	R	C	C	C			I
8.	Classificatie is patch?	I	A	R	C	C	C			I		C
9.	Wijzigingsvoorstel	I	I	A	R	R	C	C	C	C,I	C	C
10.	Uitwerken oplossing	I		A	R	R	C	C	C	C,I		C
11.	Interne kwaliteitscontrole	C		A	C	C		R		I

6 Instructies en templates

Checklist inrichting beheer [Download]

Checklist analyse wijzigingsverzoek [Download]

7 Release notes

In onderstaande tabel staan alle wijzigingen met betrekking tot dit Quality Assurance (QA) Proces, vanaf versie 3.0.0.

Versie	Datum	Release notes