Document toolboxDocument toolbox

Volwassenheidsmodel

Inleiding

De kwaliteit van de onderwerpen voor het afsprakenstelsel is niet altijd goed genoeg geweest. Dit zorgde geregeld voor problemen na publicatie, vooral in de periode vlak voor een verplichtstelling, en daardoor voor benodigde verbeteringen in de gepubliceerde versies van het afsprakenstelsel. Te noemen redenen voor de te lage kwaliteit zijn:

  1. Geen focus. Continu, ook nu, wordt er aan veel onderwerpen tegelijk gewerkt. Hierdoor is er verdeelde aandacht en kan niet gefocust worden op één onderwerp. Er lopen altijd andere onderwerpen tegelijk, waarbij de verschillende onderwerpen vaak afhankelijk van elkaar zijn en invloed op elkaar hebben. Hierdoor raakt het overzicht vertroebeld.

  2. Te hoge werkdruk. Onderwerpen werden gepland voor een bepaalde publicatie, zonder vooraf goed te weten hoeveel tijd besteed moest worden om het onderwerp te analyseren en uit te werken. Vaak bleken de onderwerpen zo groot dat er te weinig tijd was om de analyse en uitwerking goed uit te voeren. Toch moesten deze onderwerpen wel volgens plan worden opgeleverd.

  3. Publicatie zonder te testen. Veel onderwerpen zijn gepubliceerd zonder deze vooraf goed te testen, mede omdat er geen tijd was om te testen. Hoewel veel gewerkt wordt aan onderwerpen waarvoor al standaarden bestaan, moet goed gekeken worden hoe de standaarden gebruikt kunnen/moeten worden. Soms werd verwacht dat het uitgebreid testen niet nodig was, omdat gebruikgemaakt werd van standaarden. Gebleken is dat dit een verkeerde verwachting was.

  4. Deelnemers ontwikkelen pas laat in het proces. Daar waar de verwachting altijd was dat deelnemers starten met de ontwikkeling richting de nieuwe versie van het afsprakenstelsel, is gebleken dat zij dit veelal pas doen zodra een versie verplicht wordt. Dit betekent in de praktijk dat mogelijke fouten pas laat in het proces gevonden worden en dat veel vragen ontstaan in de laatste periode voor een verplichtstelling.

Om de situatie te verbeteren is gekozen om een volwassenheidsmodel op te stellen en te verwerken in het afsprakenstelsel. Dit betekent voor deelnemers bijvoorbeeld dat zij moeten voldoen aan een hernieuwd testbeleid. Maar ook dat MedMij zelf volgens een bepaald stramien moet werken om onderwerpen door te voeren in het afsprakenstelsel. Dit betekent vooral wijzigingen in het 'Change- en Releasebeleid'.

Minimum viable product

Deze uitwerkingen en uiteindelijk de benodigde wijzigingen van het afsprakenstelsel worden gezien als het minimale dat doorgevoerd moet worden. Waarschijnlijk is doorontwikkeling van dit onderwerp aan de orde.

Fasering van onderwerpen

Er is besloten dat nieuwe onderwerpen altijd een bepaald proces moeten volgen voordat zij in het afsprakenstelsel doorgevoerd kunnen worden. Dit proces moet er voor zorgen dat de in de inleiding genoemde redenen van de te lage kwaliteit worden gemitigeerd.

Alpha-fase

De eerste analyse van een onderwerp wordt uitgevoerd in de alpha-fase. Hierin wordt de architectuur opgesteld. Bij deze analyse wordt gebruikgemaakt van Archimate modellen om te bepalen welke onderdelen van het afsprakenstelsel geraakt worden. Processen worden uitgewerkt in BPMn en UML diagrammen.

Proof of Concept

Tijdens de alpha-fase kan een Proof of Concept (PoC) worden uitgevoerd om te testen of het onderwerp in de praktijk haalbaar is. Een Proof of Concept (PoC) is een methode om de praktische haalbaarheid van een concept, theorie, technologie, idee of functionaliteit te bepalen. De uitvoering van een PoC wordt nadrukkelijk buiten de productieomgevingen van de deelnemende partijen uitgevoerd, zodat de productieomgevingen geen hinder ondervinden. Waar nodig worden systemen

Bij de start van een pilot wordt vastgelegd welke doelen worden nagestreefd, wat de scope is, wie aan de pilot deelnemen en hoe lang de pilot duurt. Een MedMij PoC kan worden uitgevoerd met MedMij deelnemers, maar ook met andere (markt)partijen. Of en wanneer een PoC moet worden uitgevoerd, wordt tezamen bepaald door de Product Owner MedMij, Product Manager en Lead Architect.

Tijdens de uitvoering van een PoC wordt een eerste versie van een prototype toegevoegd aan de MedMij referentieimplementatie.

Publicatie

Onderwerpen in de alpha-fase worden gepubliceerd op changemanagement.medmij.nl, zodat de uitvoerders van de PoC de benodigde informatie kunnen inzien. Als er gekozen is geen PoC uit te voeren, is de publicatie van het onderwerp één van de laatste handelingen van deze fase.

Acceptatie afronding alpha-fase

De analyse is afgerond (uitvoerder).
Indien gekozen is een PoC uit te voeren, dan is deze afgerond (Product Owner MedMij, Product Manager, Lead Architect).
Het onderwerp is behandeld tijdens een expertgroepsessie (uitvoerder).
Het onderwerp is gepubliceerd op changemanagement.medmij.nl (redactie).
De uitwerkingen zijn geaccepteerd door de Product Owner Medmij, Product Manager en Lead Architect

Beta-fase

Als de alpha-fase is afgerond en besloten is dat het onderwerp verder uitgevoerd wordt, kan de beta-fase worden gepland. Deze hoeft niet direct op de alpha-fase te volgen, maar wordt gepland aan de hand van de op dat moment gestelde prioriteiten. De beta-fase start alleen als aan de definition of done van de alpha-fase is voldaan.

In de beta-fase wordt het onderwerp naar het afsprakenstelsel geschreven. Dit betekent dat wordt bepaald waar en welke wijzigingen moeten worden doorgevoerd in het afsprakenstelsel. Bijvoorbeeld in de architectuur (rollen, functies en verantwoordelijkheden), in het normenkader of in het beleid. De in de alpha-fase uitgewerkte onderdelen worden omgezet naar teksten die in het afsprakenstelsel kunnen landen.

Prototype

Tegelijk met het vertalen van de analyse naar wijzigingen in het afsprakenstelsel, wordt het onderwerp als prototype doorgevoerd in de MedMij referentieimplementatie. Als voor het onderwerp een PoC is uitgevoerd, kan een deel al aanwezig zijn in het prototype.

Pilot

Tijdens de beta-fase kan een pilot worden uitgevoerd. Een pilot is een kleinschalige implementatie van het onderwerp om de levensvatbaarheid aan te tonen.

Het doel is om te beoordelen of het geteste succesvol zou kunnen zijn bij een grootschalige implementatie en of het onderwerp daadwerkelijk in het afsprakenstelsel gepubliceerd moet worden. Tevens wordt getest of de geboden oplossing(en) daadwerkelijk als een verbetering wordt gezien. Mogelijke tekortkomingen worden tijdens de pilot geïdentificeerd en vervolgens kan daar actie op worden ondernomen.

Bij de start van een pilot wordt vastgelegd welke doelen worden nagestreefd, wat de scope is, wie aan de pilot deelnemen en hoe lang de pilot duurt. Een MedMij pilot kan worden uitgevoerd met MedMij deelnemers, maar ook met andere (markt)partijen. Of en wanneer een pilot moet worden uitgevoerd, wordt tezamen bepaald door de Product Owner MedMij, Product Manager en Lead Architect.

Publicatie

Onderwerpen in de beta-fase worden gepubliceerd op changemanagement.medmij.nl, zodat de uitvoerders van de pilot de benodigde informatie kunnen inzien. Als er gekozen is geen pilot uit te voeren, is de publicatie van het onderwerp één van de laatste handelingen van deze fase.

De wijzigingen vormen per onderwerp en set van Service Requests die klaar zijn voor publicatie.

Acceptatie afronding beta-fase

Het beschrijven van wijzigingen van het afsprakenstelsel is afgerond (uitvoerder).
Indien gekozen is een pilot uit te voeren, dan is deze afgerond (Product Owner MedMij, Product Manager, Lead Architect).
Het onderwerp is behandeld tijdens een expertgroepsessie (uitvoerder).
Het onderwerp is gepubliceerd op changemanagement.medmij.nl (redactie).
De wijzigingen zijn geaccepteerd door de Product Owner Medmij, Product Manager en Lead Architect

Release candidate

Onderwerpen die klaarstaan voor publicatie in het afsprakenstelsel worden release candidate genoemd. Per release canditate moet worden bepaald of het om een patch een minor of een major gaat. En er moet gepland worden wanneer deze doorgevoerd kunnen worden. Patches en minors kunnen invloed hebben op de optionele en verplichte versie van het afsprakenstelsel. Majors zorgen voor een wijziging zoals beschreven in het dakpanmodel.

Patches

Als de wijzigingen naar verwachting geen invloed hebben op de functionaliteit van de stakeholders en daarmee backward compatible zijn, kunnen deze worden doorgevoerd als patch. Het is aan de redactie en de Product Manager te bepalen wanneer deze worden doorgevoerd. Voorbeelden van patches zijn tekstuele fouten, inconsistenties, extra toelichtingen, etc.

Minors

Als de wijzigingen naar verwachting wel invloed hebben op de functionaliteit van de stakeholders, maar wel backward compatible zijn, spreken we over minors. Deze kunnen tijdens ieder van de 12 windows worden gepubliceerd, mits alle stakeholders het eens zijn over de datum.

Majors

Als de wijzigingen naar verwachting wel invloed hebben op de functionaliteit van de stakeholders en niet backward compatible zijn, spreken we over majors. Dit zijn meestal de grote onderwerpen. Op dit moment kunnen deze alleen in de windows van april en oktober worden gepubliceerd, maar de wens is om deze maanden los te laten. Net als bij de minors is het voorstel de publicatie van majors te plannen met de stakeholders, waarbij de publicatie van twee majors niet binnen 6 maanden mag plaatsvinden.