qa:Beheren: verschil tussen versies

Uit informatiestandaarden
Ga naar: navigatie, zoeken
(→‎Procesrisico’s en beheersmaatregelen)
(→‎Procesactiviteiten)
Regel 39: Regel 39:
  
 
== Procesactiviteiten ==
 
== Procesactiviteiten ==
−
Procesactiviteiten invoegen (matrix)
+
<li><p><strong>Procesactiviteiten </strong> </p></li>
 +
</ol>
 +
<p> </p>
 +
<table>
 +
<colgroup>
 +
<col style="width: 5%" />
 +
<col style="width: 27%" />
 +
<col style="width: 51%" />
 +
<col style="width: 16%" />
 +
</colgroup>
 +
<thead>
 +
<tr>
 +
<th><strong>Nr.</strong> </th>
 +
<th><strong>Verant-woordelijk</strong> </th>
 +
<th><strong>Activiteiten</strong> </th>
 +
<th><strong>Hulpmiddelen</strong> </th>
 +
</tr>
 +
</thead>
 +
<tbody>
 +
<tr>
 +
<td>1. </td>
 +
<td> </td>
 +
<td><p><u>Wijzigingsverzoek in BITS</u> </p>
 +
<p> </p>
 +
<p>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 van Nictiz. Als een medewerker via een ander
 +
kanaal (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. </p>
 +
<p> </p>
 +
<p>“Wijzigingsverzoek” moet in de breedste zin van het woord
 +
geïnterpreteerd worden. Het kan een heel concreet verzoek tot wijziging
 +
zijn, maar ook alleen de constatering dat er iets mis is en dat verder
 +
onderzocht moet worden. </p></td>
 +
<td><p>BITS, </p>
 +
<p>Document ‘Issue en change management Nictiz (MedMij)’ </p></td>
 +
</tr>
 +
<tr>
 +
<td>2. </td>
 +
<td>Servicemanagementloket </td>
 +
<td><p><u>Intake wijzigingsverzoek Servicemanagementloket</u> </p>
 +
<p> </p>
 +
<p>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. </p></td>
 +
<td> </td>
 +
</tr>
 +
<tr>
 +
<td>3. </td>
 +
<td> </td>
 +
<td><p><u>Voldoet aan de eisen?</u> </p>
 +
<p> </p>
 +
<p>Het servicemanagementloket controleert of de volgende zaken duidelijk
 +
zijn: </p>
 +
<ul>
 +
<li><p>Gaat het om een wijzigingsverzoek of een bevinding van een
 +
probleem? Of is het eerder een vraag of klacht? </p></li>
 +
</ul>
 +
<ul>
 +
<li><p>Is het probleem duidelijk (genoeg) omschreven? </p></li>
 +
</ul>
 +
<ul>
 +
<li><p>Is het duidelijk waar het probleem over gaat? Dus welke
 +
informatiestandaard, profiel, zib, etc. en welke versie
 +
daarvan? </p></li>
 +
</ul>
 +
<ul>
 +
<li><p>Is de urgentie duidelijk? </p></li>
 +
</ul>
 +
<ul>
 +
<li><p>NB. er hoeft nog <u>geen</u> voorstel voor een oplossing te
 +
zijn. </p></li>
 +
</ul>
 +
<p> </p>
 +
<p>Bij ontbrekende of onvolledige informatie wordt de Indiener om
 +
aanvullende informatie gevraagd. <br />
 +
<br />
 +
Wanneer het wijzigingsverzoek van voldoende kwaliteit is, zet het
 +
servicemanagementloket het door naar het juiste team. Dit gebeurt in de
 +
regel op basis van hetgeen waar het wijzigingsverzoek over gaat. De
 +
werkwijze van het team bepaalt hoe het doorzetten gebeurt. </p></td>
 +
<td>BITS </td>
 +
</tr>
 +
<tr>
 +
<td>4. </td>
 +
<td> </td>
 +
<td><p><u>Analyse SGU/IA:</u> </p>
 +
<p> </p>
 +
<p>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. </p>
 +
<p> </p>
 +
<p>Tijdens de analyse moeten in ieder geval de volgende vragen
 +
beantwoord worden: </p>
 +
<ul>
 +
<li><p>(Is het issue bij het juiste team terechtgekomen? Zo niet, dan
 +
wordt het doorgezet of terugverwezen naar het
 +
servicemanagementloket). </p></li>
 +
</ul>
 +
<ul>
 +
<li><p>Bestaat het geconstateerde probleem daadwerkelijk? </p></li>
 +
</ul>
 +
<ul>
 +
<li><p>Doet het probleem zich ook voor in andere (versies van)
 +
informatiestandaarden? </p></li>
 +
</ul>
 +
<ul>
 +
<li><p>Is het direct duidelijk wat er gedaan moet worden om het probleem
 +
op te lossen, of is hier significant uitzoekwerk voor nodig? </p></li>
 +
</ul>
 +
<ul>
 +
<li><p>Indien direct duidelijk is wat er gedaan moet worden, wat is
 +
dan: </p></li>
 +
</ul>
 +
<ul>
 +
<li><p>De impact volgens SemVer? </p></li>
 +
</ul>
 +
<ul>
 +
<li><p>De tijdsinvestering? </p></li>
 +
</ul>
 +
<ul>
 +
<li><p>Bij de analyse kan de checklist ‘Analyse wijzigingsverzoek’
 +
gebruikt worden. </p></li>
 +
</ul>
 +
<ul>
 +
<li><p>De IA/SGU legt de analyse en communicatie met de Indiener vast in
 +
BITS. </p></li>
 +
</ul></td>
 +
<td><p>BITS,  </p>
 +
<p>Checklist ‘Analyse wijzigings-verzoek’, </p></td>
 +
</tr>
 +
<tr>
 +
<td>5. </td>
 +
<td> </td>
 +
<td><p><u>Bestaande UC?</u> </p>
 +
<p> </p>
 +
<p>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”. </p>
 +
<p> </p>
 +
<p>Het BITS-issue wordt gemigreerd naar type “Verzoek”. De bevindingen
 +
van de verkenning en mogelijke doorontwikkeling worden hierin
 +
geregistreerd. </p></td>
 +
<td>BITS </td>
 +
</tr>
 +
<tr>
 +
<td>6. </td>
 +
<td> </td>
 +
<td><p><u>Gedelegeerde verantwoordelijkheid beheer?</u> </p>
 +
<p> </p>
 +
<p>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 en Testen en uiteindelijk
 +
Publiceren). </p>
 +
<p> </p>
 +
<p>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 beheersdocument 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”. </p>
 +
<p> </p>
 +
<p>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. </p></td>
 +
<td>BITS </td>
 +
</tr>
 +
<tr>
 +
<td> </td>
 +
<td> </td>
 +
<td><p><u>Gebruiker moet expliciet geïnformeerd worden?</u> </p>
 +
<p> </p>
 +
<p>[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 -- ] </p>
 +
<p> </p>
 +
<p>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. </p>
 +
<p> </p>
 +
<p>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. </p>
 +
<p> </p>
 +
<p>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. </p></td>
 +
<td> </td>
 +
</tr>
 +
<tr>
 +
<td>7a </td>
 +
<td> </td>
 +
<td><p><u>Uitwerken oplossing:</u> <br />
 +
</p>
 +
<p>De IA/SGU voert de wijziging door. </p>
 +
<p> </p>
 +
<p>De acties en de voorgestelde uitwerking worden vastgelegd in het
 +
BITS-issue, zodat stakeholders inzicht krijgen in de daadwerkelijke
 +
aanpassing. </p></td>
 +
<td> </td>
 +
</tr>
 +
<tr>
 +
<td>7b </td>
 +
<td> </td>
 +
<td><p><u>Wijzigingsvoorstel:</u> </p>
 +
<p> </p>
 +
<p>De IA/SGU formuleert in samenspraak met de relevante betrokkenen een
 +
concreet oplossingsvoorstel. Hiervoor zijn de volgende
 +
mogelijkheden </p>
 +
<ul>
 +
<li><p>Voorstel tot realisatie. </p></li>
 +
</ul>
 +
<ul>
 +
<li><p>Voorstel tot afwijzing. </p></li>
 +
</ul>
 +
<ul>
 +
<li><p>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. </p></li>
 +
</ul>
 +
<ul>
 +
<li><p>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. </p></li>
 +
</ul>
 +
<p>Daarnaast worden bepaald: </p>
 +
<ul>
 +
<li><p>De impact van de wijziging volgens SemVer-methodiek. </p></li>
 +
</ul>
 +
<ul>
 +
<li><p>De release waarin de wijziging wordt doorgevoerd. </p></li>
 +
</ul></td>
 +
<td> </td>
 +
</tr>
 +
<tr>
 +
<td> </td>
 +
<td> </td>
 +
<td><p><u>Interne kwaliteitscontrole:</u> </p>
 +
<p> </p>
 +
<p>Vóór publicatie wordt de wijziging beoordeeld volgens de afgesproken
 +
interne kwaliteitscontroles. </p>
 +
<p> </p>
 +
<p>In ieder geval geldt altijd het vierogenprincipe. 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. </p>
 +
<p> </p>
 +
<p>Als de uitwerking is goedgekeurd, wordt deze via het proces
 +
Publiceren naar productie gebracht. </p></td>
 +
<td> </td>
 +
</tr>
 +
</tbody>
 +
</table>
 +
<p> </p>
 +
<ol start="7" type="1">
 
<!--== Evt. onderliggende paragraaf ==-->
 
<!--== Evt. onderliggende paragraaf ==-->
  

Versie van 10 apr 2025 om 17:51


Issue icon.png

Dit materiaal is in ontwikkeling en nog niet geschikt voor gebruik!

Back to Top

Hoofdproces


Proceskaart Beheren


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

    560×1086px

    2.2 Procesactiviteiten

  • Procesactiviteiten

    • <colgroup> <col style="width: 5%" /> <col style="width: 27%" /> <col style="width: 51%" /> <col style="width: 16%" /> </colgroup> <thead> </thead> <tbody> </tbody>
    Nr. Verant-woordelijk Activiteiten Hulpmiddelen
    1.

    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 van Nictiz. Als een medewerker via een ander kanaal (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 alleen de constatering dat er iets mis is en dat verder onderzocht moet worden.

    BITS,

    Document ‘Issue en change management Nictiz (MedMij)’

    2. Servicemanagementloket

    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.

    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. Dit gebeurt in de regel op basis van hetgeen waar het wijzigingsverzoek over gaat. De werkwijze van het team bepaalt hoe het doorzetten gebeurt.

    		BITS
    4.

    Analyse SGU/IA:

    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 wijzigings-verzoek’,

    5.

    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
    6.

    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 en Testen en uiteindelijk 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 beheersdocument 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

    Gebruiker moet expliciet geïnformeerd worden?

    [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 -- ]

    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.

    7a

    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.

    7b

    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.

    Interne kwaliteitscontrole:

    Vóór publicatie wordt de wijziging beoordeeld volgens de afgesproken interne kwaliteitscontroles.

    In ieder geval geldt altijd het vierogenprincipe. 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.

      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 ten slotte is 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.

      1. 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.

    1. 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.

    1. 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.

    1. 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.

    1. 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

      RACI-tabel invoegen

      6 Instructies en templates

      Checklist inrichting beheer [Download]

      7 Release notes

      In onderstaande tabel staan alle wijzigingen met betrekking tot Quality Assurance (QA) Proces X.


Overgenomen van "https://informatiestandaarden.nictiz.nl/index.php?title=qa:Beheren&oldid=255049"