In onderstaande figuur is het Beheer- en Ontwikkelmodel weergegeven: een gelaagde structuur van onderwerpen die nodig zijn voor het ontwikkelen en beheren van een open standaard.
De structuur bestaat uit een aantal elementen:
- Drie hoofdlagen: strategie, tactiek en operationeel.
- Twee ondersteunende lagen: implementatieondersteuning en communicatie.
- Per laag meerdere activiteiten die uitgevoerd kunnen worden.
De invulling van de ontwikkel- en beheeronderwerpen zijn situationeel afhankelijk; dit wil zeggen dat verschillende situaties kunnen leiden tot een andere invulling voor een optimaal resultaat. Voor alle onderwerpen geldt dat deze in een ‘minimum’ en ‘maximum’ scenario kunnen worden uitgevoerd of wellicht niet relevant zijn voor een bepaalde organisatie. Het is dus zeker niet zo dat elk onderwerp moet worden geïmplementeerd. In tegendeel, teveel nadruk op formalisatie kan averechts werken.
In het model worden slechts de onderwerpen beschreven die met activiteiten ingevuld kunnen worden, en waarvan sommige noodzakelijk kunnen zijn. Het is aan de inrichter van een organisatie voor beheer en ontwikkeling van standaarden om op basis van het hier gegeven model de relevante onderdelen te selecteren en in te richten. Daar waar relevant worden eventuele voor- en nadelen van een specifieke invulling van een onderwerp of activiteit gegeven.
Kernonderwerpen zijn door de situationele afhankelijkheid ook onmogelijk aan te geven, maar het moge duidelijk zijn dat ‘governance’ altijd georganiseerd moet zijn om besluitvorming te kunnen laten plaatsvinden.
Afhankelijk van de situatie is het dan te bepalen welke onderwerpen prioriteit dienen te krijgen. In het figuur zijn de drie traditionele lagen herkenbaar: strategie, tactiek en operationeel. Deze worden geflankeerd door twee ondersteunende processen: communicatie en implementatieondersteuning.
Het model kan de suggestie wekken dat de onderwerpen geïsoleerd zijn, omdat er geen onderlinge relaties zijn aangegeven. Het tegendeel is waar: veel onderwerpen zijn gerelateerd – zowel binnen een hoofdgroep als tussen de hoofdgroepen.
Afstemming tussen onderwerpen is dan ook essentieel. Het model zegt niets over de organisatievorm of indeling daarvan in een beheerorganisatie. In de praktijk kunnen meerdere activiteiten belegd zijn bij een enkel organisatieonderdeel of kunnen meerdere organisatieonderdelen zich bezighouden met een enkele activiteit. De best practice organisatiestructuur (Deel 2: De Verdieping) gaat hier verder op in.
Onder de genoemde activiteiten verstaan we het volgende:
Strategie: Richtinggevende activiteiten gerelateerd aan de strategische (lange) termijn:
- Governance: beleid uitzetten over de eigen bestuurlijke organisatie (zoals de rechtsvorm); het huishoudelijk reglement (de charter), maar ook allianties vormen met andere organisaties. Het regelen van besluitvorming is cruciaal.
- Visie: het beschrijven van een ontwikkelrichting. Dit is de stip op de horizon en geldt als focus voor de lange termijn.
- Financiën: een financieel model voor de lange termijn hebben die opbrengsten garandeert in overeenstemming met de behoefte.
Tactiek: Activiteiten die op middellang termijn voor stabiliteit zorgen:
- Adoptie & erkenning: Activiteiten die te maken hebben met de certificiering, verplichtstelling of promotie van de standaard.
- Architectuur: Opbouw van de standaard en de aangrenzende processen en technieken.
- Community: Beheer en ondersteuning van gremia en stakeholders.
- Kwaliteitsbeleid benchmarking: ontwikkeling van beleid dat toeziet op de kwaliteit van implementaties van de standaard.
- Rechtenbeleid: Vaststellen van rechten van intellectueel eigendom.
Operationeel: De uitvoerende activiteiten die leiden tot nieuwe versies van standaarden, waaronder:
- Initiatie: identificatie van nieuwe ideeën (voor bijvoorbeeld een nieuwe specificatie en nieuwe werkgroep) en alle activiteiten die horen bij het succesvol optuigen daarvan (bijv. belangenanalyse, business case, agendering).
- Wensen en eisen: opstellen van de wensen en eisen aan de te ontwikkelen en te beheren specificatie, ook wel bekend onder de naam Maintenance Requests (MRs).
- Ontwikkeling: op conceptueel niveau de inhoudelijke uitwerking van oplossingen voor de ideeën, wensen en eisen opgesteld in voorafgaande fasen. Deze oplossingen zijn zoveel mogelijk los van technologieën bedoeld voor nadere uitwerking in een (nieuwe versie van) de specificatie.
- Uitvoeren: de daadwerkelijke aanpassingen op basis van de conceptuele oplossingen doorvoeren in de specificatie en eventuele technische invulling.
- Documentatie: verzorgen van passende neerslag van de resultaten van het primaire beheerproces. Niet alleen de beschikbaarheid van de specificaties, maar bijvoorbeeld ook de mogelijkheid bieden tot een historisch overzicht van verzoeken tot wijzigingen (maintenance requests) en de actuele status daarvan.
Implementatie-ondersteuning, ondersteunende activiteiten gericht op het bevorderen van implementaties van de standaard, waaronder:
- Opleiding: Het bieden van opleidingsmogelijkheden aan verschillende gebruikersgroepen variërend van een informatiebijeenkomst totaan een (online) cursus.
- Helpdesk: Het bieden van ondersteuning aan verschillende gebruikersgroepen, bijvoorbeeld telefonisch of per e-mail volgens een service level agreement (bijv. beantwoording van vragen binnen 24 uur). Een frequently asked questionslijst opstellen en bijhouden kan ook een helpdeskactiviteit zijn.
- Module-ontwikkeling: (Stimuleren van) de ontwikkeling van breed te verspreiden softwaremodules die de standaard implementeren. Dit kan door het stimuleren van de markt om software te ontwikkelen, of, als de markt niet beweegt, zelf software te ontwikkelen en te verspreiden om de markt in beweging te krijgen.
- Pilot: Proeven met de implementatie van de specificaties. Bij sommige standaardisatieorganisaties is het verplicht dat er 1 of meerdere pilots zijn geweest voordat de standaard officieel vrijgegeven wordt.
- Validatie & Certificatie: Het bieden van mogelijkheden om de correctheid van de implementaties te testen (validatie). Daaraan kan een officieel traject verbonden worden dat leidt tot certificatie van een organisatie of product. Ook verplicht stellen van het doorlopen van validatie en certificatietrajecten behoort tot de mogelijkheden. Module-ontwikkeling en Certificatie zijn riskante activiteiten, waarmee er actief ingegrepen wordt in de markt. De uitvoering daarvan dient zorgvuldig te gebeuren en zoveel mogelijk buiten de eigen organisatie.
Communicatie, ondersteunende activiteiten gericht op het creëren van draagvlak voor de standaard, waaronder:
- Promotie: Het uitdragen van nut/noodzaak/voordelen van de standaard.
- Publicatie: Het vindbaar/kenbaar maken van de standaard en de actuele stand van zaken (website).
- Klachtenafhandeling: Het garanderen van het serieus nemen van klachten door deze volgens een zorgvuldige procedure te behandelen. Klachten kunnen ook beschouwd worden als verbetersuggesties.
De activiteiten moeten worden uitgevoerd door verschillende rollen. Een overzicht van rollen die relevant zijn bij het ontwikkelen en beheren van standaarden is opgenomen in NEN 7522:2021 "Medische informatica - Ontwikkelen en beheren van standaarden en stelsels van standaarden", en is hier in licht aangepaste versie overgenomen.
Eigenaar: eindverantwoordelijk voor het ontwikkelen en beheren van een standaard. De eigenaar bepaalt de scope en het doel van een standaard, en bepaalt de principes en de uitgangspunten die worden gehanteerd bij ontwikkeling en beheer.
Financier: verantwoordelijk voor het financieren van het ontwikkelen en beheren van standaarden.
Autorisator: keurt een standaard goed. Toelichting: een autorisator kan een persoon, organisatie of groep van personen en organisaties zijn. Het is aan de eigenaar om de autorisator te benoemen. Een autorisator bevat vaak een vertegenwoordiging van stakeholders, die als persoon of organisatie ook de ook de rol gebruiker hebben.
Functioneel beheerder: verantwoordelijk voor het proces van ontwikkelen en beheren van standaarden, binnen de kaders van de gemaakte afspraken en afgesproken governance. Toelichting: de functioneel beheerder is verantwoordelijk voor het proces van ontwikkelen en beheer van de inhoud van standaarden. Hiervoor werkt hij nauw samen met experts, gebruikers, de technische beheerder en de distributeur. De functioneel beheerder heeft vaak een regievoerende rol. Resultaten van het proces worden voorgelegd aan de autorisator.
Technisch beheerder: verantwoordelijk voor het technisch beheren van standaarden. De technisch beheerder zorgt voor de inrichting en beheer van een technische omgeving die noodzakelijk is om de artefacten die onderdeel zijn van de standaard te onderhouden. Toelichting: De technisch beheerder is verantwoordelijk voor de technische omgeving waarin de artefacten, die in beheer zijn, worden onderhouden. Zo’n technische omgeving zal bestaan uit het geheel aan ICT-middelen (tools, hardware, netwerken, e.d.) die noodzakelijk zijn om het functioneel beheer uit te kunnen voeren op de standaard. Onder de verantwoordelijkheid van de technisch beheerder valt o.a. het kunnen toepassen van versiebeheer op de technische omgeving en het beschikbaar stellen en houden van de technische omgeving, in overleg met de functioneel beheerder.
Distributeur: verantwoordelijk voor het distribueren van standaarden.
Expert: brengt specifieke noodzakelijke expertise in ten behoeve van het ontwikkelen of beheren van een standaard. Toelichting: verschillende type experts kunnen, afhankelijk van de standaard, noodzakelijk zijn. Veel voorkomende experts zijn domein-inhoudelijk of bijvoorbeeld expert op het gebied van ontologie, architectuur, vertrouwen, informatiebeveiliging, cryptografie of privacy. Vaak voorkomend is ook een vertegenwoordiging van ervaringsdeskundige stakeholders die als persoon of organisatie ook de rol gebruiker hebben.
Gebruiker: gebruikt de standaarden direct of indirect. Voorbeelden van deze gebruikers zijn leveranciers van componenten (vaak applicaties), of gebruikers van deze applicaties (indirect).
Van bovenstaande rollen kunnen de financier-rol, de expert-rol, de gebruikers-rol en de eindgebruikers-rol meervoudig worden ingevuld: meer dan één persoon of organisatie kan de rol van financier, expert, gebruiker of eindgebruiker vervullen. Meervoudigheid betekent hier ook dat de stakeholders die deze rollen invullen een ander belang of expertisegebied kunnen vertegenwoordigen en dit dus ook inbrengen. De overige rollen zijn enkelvoudig: er kan maar één persoon of organisatie in die rol zijn. Enkelvoudig kan wel betekenen dat de rol ingevuld wordt met een instantie, bijvoorbeeld een raad of een overleg, waarin meerdere personen of organisaties zijn vertegenwoordigd.
Onderstaande tabel geeft voor de BOMOS hoofdactiviteiten weer welke rol primair verantwoordelijk is, en welke rollen veelal ook betrokken zullen zijn.
| Activiteit | Primair verantwoordelijke rol | Overige betrokken rollen |
|---|---|---|
| Strategie | Eigenaar, financier | Autorisator, functioneel beheerder, experts |
| Tactiek | Autorisator | Functioneel beheerder, experts |
| Operationeel | Functioneel beheerder | Technisch beheerder, experts |
| Implementatieondersteuning | Functioneel beheerder | Technisch beheerder, experts |
| Communicatie | Distributeur | Functioneel beheerder, technisch beheerder, experts |
Eerder hebben we beschreven in welke situaties BOMOS te gebruiken is, nu maken we de stap hoe BOMOS vervolgens ingezet kan worden. Dit is niet eenvoudig eenduidig te definiëren omdat de context van de gebruiker hierin bepalend is. De context kan bepaald worden door het in kaart brengen van situatiekenmerken. Een belangrijke situationele kenmerk is de plaats van de standaard in de standaardenlevenscyclus.
De levensfase waarin een standaard zich bevindt is immers van invloed op de inrichting van het beheer. Een standaard die zich nog in de ontwikkelingsfase bevindt stelt andere eisen aan beheer dan een standaard die grootschalig is geadopteerd en geïmplementeerd. Het is dan ook als vuistregel verstandig om bij iedere overgang een controle (op basis van het Beheer- en Ontwikkelmodel) uit te voeren om te bepalen of uw beheerinrichting nog voldoet. Hieronder volgt een beschrijving van de fasen van de standaardenlevenscyclus, zodat u kunt toetsen in welke fase uw standaard zich bevindt.
1. Creatie / ontwikkeling
Deze fase markeert het moment waarop een community van belanghebbenden en geïnteresseerden de behoefte aan een standaard vaststelt en start met het opstellen van de standaard. Dit hoeft niet altijd te betekenen dat een standaard geheel ontbreekt. Ook in het geval dat een standaard met (kleine) afwijkende specificaties al bestaat kan een community tot de conclusie komen dat de behoefte aan een nieuwe standaard de inspanning rechtvaardigt. In deze fase is nog geen sprake van ingericht beheer maar hebben de meeste activiteiten vooral een projectmatig karakter. In deze fase is het bijvoorbeeld belangrijk na te denken over de besluitvormingsprocessen. Bij een modulair opgezette standaard kunnen onderdelen van de standaard al gereed zijn, terwijl andere onderdelen nog in de ontwikkelfase verkeren. Creatie heeft dan betrekking op de nieuw ontwikkelde modules.
In deze eerste fase waarin een standaard zich bevindt is vooral afstemming van besluitvorming belangrijk. Er moet een goede business case zijn die het management, de geïnteresseerde gebruikers en ontwikkelaars kan overtuigen van het nut van de standaard. Ook moet er een duidelijk adoptiebeleid zijn. In grotere organisaties is het ook belangrijk dat de processen rondom de adoptie zijn verankerd in het proceslandschap. Dit is immers een goede manier om de adoptie ook via formele wegen af te dwingen.
2. Introductiefase van de standaard
In deze fase wordt gekozen voor een specifieke standaard om in een behoefte te voorzien. Tijdens deze fase zullen veel wijzigingen aan de orde zijn. De inrichting van beheer wordt belangrijk. De keuze kan bewust en expliciet worden gemaakt in besluitvorming om een standaard algemeen geldend te verklaren of door organische groei waarbij de adoptie geleidelijk plaatsvindt. Een voorbeeld van bewuste keuze is besluitvorming door de overheid om een standaard verplicht te stellen. Ook sectorafspraken of een besluit van het Forum Standaardisatie om een standaard op de ‘Pas toe of leg uit’-lijst te plaatsen, vallen hieronder.
In de introductiefase is het nog steeds belangrijk om een goed adoptieplan te hebben. Ook het uitdragen van het nut en de noodzaak van de standaard is relevant. Nieuw in deze fase is het monitoren van de adoptie en het publiceren van de standaard. Waar er tijdens de creatiefase misschien nog geen (concept)versie beschikbaar is, moet dit tijdens de introductie wel het geval zijn.
3. Implementatie / groei van de standaard
In deze fase kiezen gebruikers bewust voor de implementatie van de standaard. In het beheer wordt ook rekening gehouden met het feit dat niet alle gebruikers beschikken over een volwaardig kennisniveau van de standaard. Beheer betekent in deze fase ook de ondersteuning en het informeren van de gebruikers. Marketingtermen als ‘early majority’ zijn in deze fase van toepassing. Uw activiteiten zijn gericht op meer professionele adoptie en professionalisatie van de open beheerprocessen, zodat bij opschaling van het gebruik alle partijen aangehaakt blijven en de processen transparant verlopen. Registraties van gebruikers/ afnemers/ experts etc. worden steeds belangrijker.
Van organische adoptie is sprake als diverse (individuele) partijen besluiten een standaard te gaan toepassen. Tijdens deze fase zullen veel wijzigingen aan de orde zijn. De inrichting voor beheer wordt belangrijk, net als de adoptie van de standaard bij de ‘early adopters’ van belang is. Uw activiteiten zullen hierop gericht moeten zijn.
4. Volwaardige toepassing / volwassenheid van de standaard
In deze fase is de standaard algemeen geaccepteerd en geïmplementeerd. Het beheer is in deze fase volledig ingericht om de stabiliteit en kwaliteit van de standaard te waarborgen.
Kwaliteitsmanagement en het volgen van de BOMOS-activiteiten zijn belangrijk, net als de relatie met andere (internationale) standaarden. Natuurlijk kan dit ook van belang zijn in eerdere fases, maar in de regel is dit voor een volwassen standaard altijd het geval.
Een volwassen standaard wordt regelmatig getoetst om vast te stellen of de standaard nog actueel is. Wanneer een standaard gebaseerd is op een onderliggende standaard, kan de beheerder hierbij controleren of deze standaard nog in actief beheer is. Daarnaast is het zinvol om na te gaan of er nieuwe (internationale) standaarden beschikbaar zijn gekomen met dezelfde toepassing als de standaard. Beschikbaarheid van een nieuwe, internationale standaard met internationale toepassing kan prioriteit gegeven worden boven een in nationale context beheerde standaard.
5. Uitfaseren / overgang naar een andere (versie van de) standaard
Tijdens het uitfaseren van een standaard is het van belang dat de samenhang met verschillende producten goed wordt bewaakt. Het kan namelijk zo zijn dat de standaard een cruciale plaats inneemt in het architectuurlandschap van derden. Daarbij is ook het bewaken van de organisatiestructuur van belang aangezien het verwijderen van standaard kan zorgen voor verschuivende verantwoordelijkheden. Verder is het afbouwen van financieringen een aandachtspunt, net als het beheersen van verwachtingen.