In het BOMOS activiteitendiagram zijn de verschillende activiteiten opgesomd die kunnen plaatsvinden in een standaardisatiegemeenschap. Onderstaande figuur schetst een globale organisatiestructuur hiervoor. Een belangrijk uitgangspunt is de scheiding tussen inhoudelijke activiteiten in de uitvoeringsorganisatie en de besluitvorming door het bestuur.

Het bestuur geeft opdracht aan een (not-for-profit) uitvoeringsorganisatie die verantwoordelijk is voor een groot deel van de beheertaken. Het bestuur verenigt de behoeften in dezen van zijn achterban en heeft het mandaat namens dezen te besluiten over zaken die de betreffende standaarden betreffen. Bestuur en uitvoeringsorganisatie werken bij voorkeur met wederzijdse eenhoofdige aanspreekpunten. Het bestuur is voornamelijk belast met de taak 'besluitvorming'. In de praktijk komt het bestuur een paar keer per jaar bij elkaar, wat geen belemmering mag zijn voor de gewenste besluitvorming. Het bestuur moet de uitvoeringsorganisatie voldoende mandaat geven. In de praktijk zien we dat sommige besluiten ook schriftelijk (e-mail) aan bestuursleden voorgelegd kunnen worden voor goedkeuring, of dat de verantwoordelijkheid van bepaalde activiteiten (bijv. communicatie) bij een enkel bestuurslid worden belegd. Dit maakt het eenvoudiger om bilateraal overleg tussen de uitvoeringsorganisatie en het verantwoordelijke bestuurslid te voeren en ook besluiten tussentijds te nemen (en kan als alternatief dienen voor de wederzijdse eenhoofdige aanspreekpunten).

De kern is dat duidelijk moet zijn vastgelegd welke besluiten in de bestuursvergadering genomen dienen te worden; welke schriftelijk (e-mail) voorgelegd kunnen worden, welke door een specifiek bestuurslid genomen kunnen worden, en voor welke besluiten het mandaat bij de uitvoeringsorganisatie ligt. In de praktijk worden vaak jaarplannen gebruikt voor de opdrachtformulering van het bestuur aan de uitvoeringsorganisatie. Op basis van rapportages over het jaarplan legt de uitvoeringsorganisatie dan verantwoording af aan het bestuur. Het jaarplan beschrijft welke taken uitgevoerd moeten worden; welke werkgroepen er zijn of opgestart moeten worden, wat de doelen voor de werkgroep zijn, etc. Het jaarplan wordt goedgekeurd door het bestuur en is daarmee de opdracht voor de uitvoeringsorganisatie. Het Beheer- en Ontwikkelmodel kan als kapstok dienen om de taken in het jaarplan te benoemen. Het jaarplan maakt het ook goed mogelijk om afspraken te maken over uit te besteden taken. Feitelijke standaardontwikkeling vindt plaats in werkgroepen waarin de gebruikers van de standaarden participeren. De werkgroepen worden door de uitvoeringsorganisatie gecoördineerd. Veelal worden ook de daadwerkelijke uitwerkingen opgesteld door de uitvoeringsorganisatie op basis van discussies in de werkgroepen. De uitkomst van de werkgroep, een nieuwe versie van een standaard, kan door het bestuur vastgesteld worden en uitgebracht worden als nieuwe versie. De besluitvorming, wie (bestuur/werkgroep) bepaalt wat, moet helder geregeld zijn.

Bij voorkeur wordt onderscheid gemaakt tussen verschillende zwaartes van wijzigingen in standaarden, zodat de lichtste wijzigingen door de betreffende werkgroep of de uitvoeringsorganisatie zelf kunnen worden afgehandeld en alleen de meest fundamentele wijzigingen betrokkenheid van het bestuur vragen, tot aan een bestuursbesluit. Een werkgroep die continu overruled wordt door het bestuur is niet werkbaar.

Eventueel kan een adviesorgaan opgericht worden om het bestuur met gevraagd en ongevraagd advies ter zijde te staan. De uitkomst van een werk- groep zal in dat geval als voorstel naar het adviesorgaan gaan die daarover aan het bestuur zal adviseren. Het adviesorgaan bestaat bij voorkeur uit onafhankelijke en onbetwiste deskundigen, en kan een middel zijn om de onafhankelijkheid en expertise te versterken. Het is van belang dat deze deskundigen gekozen worden op basis van kennis en ervaring en niet op basis van belangen of vertegenwoordiging van een organisatie; immers aan hen wordt enkel gevraagd om inhoudelijk advies. De vertegenwoordiging van belangen is gevestigd in het bestuur.

Een typische inhoudelijke categorische afbakening van werkgroepen vindt plaats langs de volgende (gelaagde) lijnen:

• Architectuur.
• Processen/services.
• Data/gegevens/berichten.
• Technische standaard/transactiestandaard.
• Beveiliging.

Een andere veel gebruikte afbakening is op basis van het probleemdomein, bijvoorbeeld SETU heeft gewerkt met een tweetal werkgroepen, te weten Bemiddeling en Verwerking. De werkgroep Bemiddeling houdt zich bezig met de standaarden van offerteaanvraag tot aan de plaatsing van een uitzendkracht, terwijl de werkgroep Verwerking de standaarden van plaatsing tot aan factuur tot haar scope rekent. In de praktijk zullen bij complexere standaarden bepaalde categorieën werkgroepen (bijv. 'gegevens') weer onderverdeeld worden in werkgroepen per probleemdomein (bijv. 'facturatie'), waarmee een combinatie van beide indelingen wordt gerealiseerd.

Bijzondere aandacht verdienen de leveranciers. Dit is regelmatig een heet hangijzer bij non-profit beheerorganisaties. Voor het welslagen van een standaard (zonder juiste implementatie geen werkende standaard') vaak cruciaal, maar leveranciers kunnen ook conflicterende belangen hebben. In beginsel kunnen leveranciers gewoon als deelnemer in de standaard acteren en rollen in de werkgroepen vervullen tot aan deelname in het bestuur. De praktijk laat zien dat softwareleveranciers veelal zeer nuttige bijdragen leveren in werkgroepen waardoor het zeker aan te raden is om leveranciers toegang tot de werkgroepen te verlenen. Vaak heerst er angst dat leveranciers te nadrukkelijk een stempel gaan drukken op de standaard. Een aparte leveranciersgroep zoals aangegeven in bovenstaande figuur is dan een optie waarmee de leveranciers enerzijds een platform wordt geboden terwijl ze anderzijds buiten de werkgroepen en bestuur kunnen worden gehouden. Softwareleveranciers zijn dan verenigd in een leveranciersgroep, die de uitvoeringsorganisatie van advies kunnen voorzien en overleg kunnen voeren met het adviesorgaan.

De besluitvorming binnen de werkgroep kan afhankelijk zijn van de mogelijke deelname van leveranciers, en ook afhankelijk zijn van de opstelling van de leveranciers. In de praktijk zal de keuze voor de mate van invloed ook afhangen van de manier waarop de gemeenschap is georganiseerd; indien de ontwikkeling van de standaard gedreven wordt vanuit het belang van de softwareleveranciers dan zullen deze een grotere invloed (willen) uitoefenen op 'hun' standaard. Wordt de ontwikkeling gedreven vanuit een (overheids-)gebruikersbehoefte dan zullen deze een grotere invloed (willen) uitoefenen.

In het figuur is een eenvoudige basisstructuur geschetst van bestuur, uitvoeringsorganisatie en werkgroepen. Facultatief kan daar een adviesorgaan en/of leveranciersgroep aan toegevoegd worden. Naast deze geschetste mogelijkheden zijn er nog vele alternatieven, zowel eenvoudiger als complexer. Welke structuur ook gekozen wordt, bij voorkeur worden de verslagen van de verschillende gremia openbaar ter beschikking gesteld.

In deel 1 zijn de rollen voor het ontwikkel- en beheerproces gedefinieerd, en zijn ze gekoppeld aan de hoofdactiviteiten van BOMOS. Omgekeerd kijken we er nu in meer detail naar. Onderstaande tabel geeft vanuit de rollen aan in welke BOMOS activiteiten ze betrokken kunnen zijn; dat laat ook zien dat een 1-op-1 koppeling tussen rol en activiteit niet werkt.

Voor de invulling van ontwikkelen beheertaken in een organisatiestructuur zijn verschillende mogelijkheden, variërend van het beleggen bij een standaardisatieorganisatie tot het volledig zelf invullen in een eigen organisatie. Het is geen doel op zich om voor elke standaard een eigen beheren ontwikkelorganisatie op te tuigen. De praktijk laat zien dat weinig bestaande organisaties zijn berekend op het complete takenpakket, waardoor toch vele standaardisatiecommunities hebben besloten een eigen organisatie op te tuigen. Een deel van de taken wordt dan belegd bij de eigen organisatie, maar een deel van de taken kan ook belegd worden bij andere soorten organisaties. Onderstaande figuur noemt hier (andere) standaardisatieorganisaties, research-organisaties en brancheorganisaties.

Het model maakt onderscheid tussen not-for-profit en profit organisaties. Dit onderscheid is relevant in het kader van openheid (zie sectie over openheid). Indien het beheer van een standaard is belegd bij een profit-organisatie kan er geen sprake zijn van een open standaard! Dat wil niet zeggen dat commerciële organisaties geen open standaarden kunnen ontwikkelen in opdracht van een bestuur (organisatie), of na ontwikkeling doneren aan een not-forprofit beheerorganisatie. Het ontwikkelen en beheren van standaarden dient altijd not-for-profit te gebeuren, waarbij een not-for profit organisatie wel het meest voor de hand liggend is.

Een eerste voor de hand liggende mogelijkheid is het beleggen van de beheertaken bij formele standaardisatieorganisaties. De wereld is hier wel veranderd in vergelijking met dertig jaar geleden toen het merendeel van de standaarden door deze formele organisaties werd ontwikkeld. In de huidige tijd wordt het merendeel van de standaarden buiten de formele standaardisatieorganisaties ontwikkeld in allerlei vormen van consortia, en dat aantal blijft groeien. Ook zien we weer steeds meer complexe samenwerkingsverbanden tussen standardisatie-organisaties ontstaan. Voor de semantische standaarden speelt dit in extreme mate. Deels heeft dit te maken met de traagheid van processen bij formele standaardisatieorganisaties, maar voornamelijk het gebrek aan inhoudelijke kennis en expertise. Voor semantische standaarden is domeinkennis essentieel.

Dit wil niet zeggen dat formele standaardisatieorganisaties geen waarde hebben, integendeel. Op een aantal punten hebben ze potentieel een belangrijke toegevoegde waarde. Bijvoorbeeld om de status van de standaard te verhogen. Zo is NEN3610 ontwikkeld door Geonovum, maar voor extra status ook uitgebracht als NEN-norm. Daarnaast is secretariële ondersteuning voor werkgroepen ook een prima taak die extern belegd kan worden.

De inhoudelijke kennis zal echter altijd zelf georganiseerd moeten worden. Onderzoeksorganisaties, zoals universiteiten en instituten, zijn een andere mogelijkheid om taken bij te beleggen. Voordeel is de schat aan inhoudelijke kennis, maar mogelijk ook een gebrek aan domeinkennis of kennis van het specifieke gebruik. Het tegenovergestelde is het geval bij brancheorganisaties; voordeel hier is de uitmuntende domeinkennis, maar nadeel is juist een gebrek aan inhoudelijke standaardisatie/ICT kennis. Vaak zijn (semantische) standaarden voor brancheorganisaties een ver van hun bed show. Het onderwerp wordt al snel afgedaan als iets van techneuten, wat het in de kern niet is; juist voor semantiek is domeinkennis van groot belang.

Een eigen organisatie oprichten is een mogelijkheid, evenals commerciële dienstverleners inschakelen. Dat laatste is wel op gespannen voet met de openheidprincipes. De eigen organisatie is de meest gekozen optie voor de kern van ontwikkelen beheertaken. Velen domeinen kennen inmiddels eigen organisaties die kennis hebben van zowel het domein als standaardisatie, bijvoorbeeld (Geonovum, EduStandaard, CROW, Informatiehuis Water, SETU, etc.). Tot de kern van hun werk behoren de strategische beheeractiviteiten zoals geïdentificeerd in het model, en in grote mate ook de tactische en operationele activiteiten. In deze situatie zijn bepaalde activiteiten eenvoudig en zelfs beter om uit te besteden.

Een aantal suggesties:

Moduleontwikkeling; Moduleontwikkeling is riskant om binnen de ontwikkel- en beheerorganisatie te laten plaatsvinden. Daarmee wordt men ook leverancier en concurrent van partijen in de gemeenschap. Beter is om moduleontwikkeling te stimuleren buiten de ontwikkel- en beheerorganisatie, mogelijk in de vorm van open source software. Dit kan andere leveranciers ook bewegen om de standaard te gaan ondersteunen en/of betrokken te raken bij de ontwikkeling daarvan. De beste aanpak is afhankelijk van de kenmerken van de community.

Certificeren; Essentieel bij certificeren is de onafhankelijkheid van de certificerende instelling. Gebruikelijk is dat de ontwikkel- en beheerorganisatie het toetsingskader opstelt, en vervolgens de daadwerkelijke toetsing (op basis van het toetsingskader) uitbesteedt aan externe partijen die zich specifiek richten op het toetsen en certificeren.

Architectuur/Roadmapping/Benchmarking; Ondersteuning en uitvoering hiervoor past uitstekend bij een research-organisatie in brede zin (Naast kennisinstituten, ook organisaties zoals CBS voor benchmarking). Met name voor benchmarking geldt dat dit beter bij een externe organisatie belegd kan worden.

Communicatie; Past vaak goed bij een brancheorganisatie die al een communicatieapparaat heeft ingericht. Uiteraard moet er dan wel een brancheorganisatie zijn die naadloos aansluit bij de standaard en die bereid is de communicatie als belangrijke taak mee te nemen. Communicatie rondom het beheer- en ontwikkelproces van een standaard vraagt om specifieke kennis van dat beheer en heeft een specifieke doelgroep zoals softwareleveranciers. Dit dient door een brancheorganisatie onderkend te worden. Andere opties zijn communicatieafdelingen van een andere partner organisatie.

Op hoofdniveau kunnen we concluderen dat er de keuze is om de ontwikkel- en beheertaken te beleggen bij:

1. Bestaande organisaties.
2. Nieuwe organisaties.
3. Combinatie van beiden.

Het beleggen van alle taken bij een bestaande situatie klinkt ideaal, maar er is geen organisatie die alleenstaand voor het complete takenpakket is toegerust. Ook organisaties als NEN, Forum Standaardisatie, etc. zijn daar niet op ingericht.

Daardoor is het in de praktijk vaak noodzakelijk om een nieuwe organisatie op te richten, als er binnen het domein nog geen organisatie bestaat gericht op standaardisatie. Optie 3, de combinatie van beide, betekent dat bepaalde taken door deze (nieuwe) specifieke domein standaardisatie organisatie worden opgepakt en andere taken door ander type organisaties, conform de beschrijving in deze paragraaf over het uitbesteden van taken.

Of het nu slechts een deel van de taken of alle taken door de nieuwe organisatie uitgevoerd moeten gaan worden, de nieuwe organisatie moet in beide gevallen opgericht worden waarvoor een rechtsvorm nodig is. Nederland kent tal van organisatie rechtsvormen. Openheid van de standaard is absoluut een essentieel uitgangspunt. De definitie van openheid schrijft voor dat de (besluitvorming van de) standaard belegd wordt bij een not-for-profit organisatie. Daarmee worden een groot deel van de organisatievormen uitgesloten, en zijn slechts enkel voor de hand liggen, te weten:

1. Stichting.
2. Vereniging.
3. Overheidsorganisatie (als verzamelterm).

De stichting: Een stichting is een rechtspersoon en wordt opgericht bij notariële akte, door één of meerdere natuurlijke of rechtspersonen. In de regel heeft een bestuur een voorzitter, secretaris en penningmeester. Het bestuur is het enige verplichte orgaan van een stichting. Daarnaast kan er nog een raad van toezicht zijn, die toezicht houdt op het stichtingsbestuur. In tegenstelling tot een vereniging heeft een stichting geen leden. Een stichting kan wel donateurs hebben, maar die hebben geen zeggenschap. Een stichting kan ook vrijwilligers hebben.

De vereniging: Een vereniging is een rechtspersoon voor de Nederlandse wet. Een vereniging wordt meestal opgericht door bij de notaris hiervan een akte op te maken. Dit is niet noodzakelijk, maar zonder notaris heeft de vereniging beperkte rechtsbevoegdheid (de bestuurders zijn hoofdelijk aansprakelijk). Wanneer een vereniging bij de notaris opgericht is, zijn er ook statuten. Hierin staat tenminste het doel van de vereniging, de verplichtingen van de leden, het bijeenroepen van de algemene (leden)vergadering en het benoemen/ontslaan van de bestuurders. Een vereniging heeft een doel dat nagestreefd wordt. Dit doel mag niet het verdelen van winst onder de leden zijn. Wat niet wil zeggen dat er geen winst gemaakt mag worden, maar deze moet ingezet worden voor een bepaald doel (zoals het doel van de vereniging, kennisdeling, verbetering van de kwaliteit, liefdadigheid, etc.). Een vereniging heeft leden. Dit zijn mensen die lid zijn van de vereniging omdat zij het doel steunen. De leden betalen meestal contributie om de vereniging draaiend te houden. Leden hebben invloed in het beleid van de vereniging via een algemene (leden)vergadering (ALV). Zo'n vergadering wordt minstens jaarlijks gehouden en elk lid is hiervoor uitgenodigd en stemgerechtigd. De ALV heeft alle bevoegdheden die niet door de wet of de statuten geregeld zijn en is dus het hoogste orgaan van de vereniging.

De overheidsorganisatie: Er zijn verschillende vormen van overheidsorganisaties, waardoor een korte bespreking onmogelijk is. Het inzetten van een overheidsorganisatie zou op verschillende manieren kunnen: één overheidsorganisatie als beheerorganisatie voor alle aan de overheid gerelateerde standaarden, of per standaard één overheidsorganisatie. Daarnaast kan een enkele overheidsorganisatie de uitvoering van het beheer op zich nemen, maar kunnen meerdere overheden zich ook verenigen. Dit kan bijvoorbeeld in een vereniging. De keuze van de rechtsvorm dient weloverwogen te gebeuren, waarbij ook zaken als de eenvoud van het opzetten moet worden meegenomen. Bij een stichting speelt dat het mogelijk lastig is voor overheidspartijen om aan een stichting deel te nemen, en dat een stichting geen leden mag hebben. Bij een vereniging speelt de grote macht van de ALV. Met een stichting en vereniging is het wel eenvoudig om openheid aan te tonen. Bij zowel de stichting als de vereniging zijn de statuten belangrijk; deze regelen in feite het mandaat van de rollen in de organisatie.

Ondanks het feit dat een stichting geen leden kan hebben spreekt men bij HL7 Nederland wel over leden, maar hanteert men strikt formeel de term aangeslotenen. SETU kent geen leden, maar wel participanten. Een samenwerkingsverband zonder rechtsvorm kan in de praktijk goed werken voor het beheer maar kan in praktische zaken weer nadelig zijn doordat het samenwerkingsverband als zodanig geen bevoegdheden heeft tot het aangaan van overeenkomsten; hierbij zal altijd één van de partners deze overeenkomst moeten aangaan. Mogelijke nadelen die hieraan kleven zijn het verlies van identiteit; het gebonden zijn aan regels en beperkingen van de partner; minder slagvaardigheid etc. Het voordeel van een dergelijke organisatievorm is dat deze eenvoudig is in te richten en op te heffen zonder juridische consequenties. De organisatie-inrichting kan in enige mate de vrijblijvendheid reduceren of op zijn minst expliciteren. De vrijblijvendheid van de deelnemers in standaarden is zeker een serieus aandachtspunt in het kader van een duurzaam toegepaste standaard.

Inhoudelijke visie ontwikkelen over de richting van de standaard in de context: De plek op de horizon op de lange termijn. Een compacte vertaling in bijvoorbeeld een factsheet van deze visie kan ook zeer nuttig zijn in de communicatie rond de standaard en het bevorderen van adoptie van de standaard. Ook moet er aandacht zijn voor innovatie; veel organisaties gebruiken daar hulpmiddelen voor als een radar, of specifiek een tech-radar; daarin worden innovatieve ontwikkeling geplot op een radar op basis van tijd en impact. Dit soort hulpmiddelen zijn ook hier van toepassing. De visie voor een standaard is op zich niet anders dan de visie rond een bedrijf/product, etc. Vandaar dat BOMOS hier geen specifieke invulling voor standaarden aan geeft. De verdere detailering van de in de visie benoemde innovatie onderwerpen zal veelal op tactisch niveau plaatsvinden, bijvoorbeeld als onderdeel van Architectuur.

Er mogen dan weinig cijfers beschikbaar zijn maar er is voldoende economisch onderzoek gedaan naar de vooren nadelen van standaardisatie. Bijgaande tabel geeft een samenvatting (op basis van Blind, K. (2004). The economics of standards; theory, evidence, policy):

Voor semantische (domein) standaarden zijn met name relevant:

• Positieve netwerkeffecten (wordt waardevoller met meer gebruikers).
• Voorkomen van vendor lock-ins.
• Toename variëteit in producten en diensten.
• Schaalvoordeel.
• Verlagen transactiekosten.

Wel is het mogelijk om te kijken naar de mogelijke kostenposten en opbrengsten van het beheer van standaarden. De balans vat deze samen.

De vorige paragraaf schetste een beeld van potentiële opbrengsten. De keuze van welke bronnen voor opbrengsten aangeboord worden is situationeel, maar deze paragraaf tracht te ondersteunen bij het maken van de keuzes voor geschikte bronnen van inkomsten.

De geschiktheid van een type opbrengst wordt algemeen geldend bepaald door:

• Kosten en opbrengsten in evenwicht brengend.
• Open en transparant.
• Voldoende breed draagvlak.

In andere woorden, opbrengstbronnen die geen draagvlak hebben, niet transparant zijn en de beheerorganisatie winstgevend maken zijn niet geschikt.

Om geschikte bronnen van inkomsten te bepalen is een onderscheid in verschillende situaties noodzakelijk:

1. Onderscheid tussen ontwikkeling en beheer.
2. Mate van volwassenheid: onderscheid tussen een bewezen standaard en een standaard in de beginfase van de levenscyclus.

Daarnaast hanteren we een drietal uitgangspunten:

• Aansluiten bij open standaard (toegankelijk).
• Adoptie niet belemmerend.
• Waar het voordeel zit, vindt betaling plaats.

Op basis van deze uitgangspunten hebben licenties vanwege de beperkte openheid, maar vooral omdat het adoptie belemmerend werkt, een twijfelachtige status. Dit geldt zowel voor betalen voor het specificatiedocument, als wel op betalen voor gebruik van de standaard. Gezien de ongewenstheid wordt dit niet beschouwd als potentiële opbrengsten bron voor een open standaard.

2.2.3.2 Ad 2. Mate van volwassenheid

Als een standaard een grote mate van volwassenheid heeft, gekenmerkt door brede adoptie van de standaard, dan is dienstverlening door de beheerorganisatie ook een potentiële inkomstenbron. Te denken valt aan verschillende vormen van dienstverlening:

• certificering
• opleiding
• implementatieondersteuning

Certificering kan op verschillende manieren ingezet worden, ook als middel om financiële opbrengsten te genereren. In het kader van opleidingen kan bijvoorbeeld gedacht worden aan het geven van opleidingsdagen tot aan complete cursussen over de standaard. De marge op de cursus kan een inkomstenbron zijn, helemaal gecombineerd met certificeren (het volgen van een opleiding verplicht stellen voor het certificaat). Tot slot is implementatie-ondersteuning een middel, dat kan in lichte mate door het geven van betaalde adviezen over correct gebruik van de standaard, tot aan het uitvoeren van complete implementatietrajecten. Hiermee wordt de beheerorganisatie ook een marktpartij en daar kleven nadelen aan.

Kort samengevat zal dienstverlening een inkomstenbron zijn die naar mate de standaard volwassener wordt meer mogelijkheden gaat bieden voor inkomsten. Een inkomstenbron die in de praktijk niet veel voorkomt, maar voor de toekomst niet uitgesloten moet worden is de donatie. Vooral structurele donaties zijn een prettige financieringsvorm. Dit leidt tot het volgende model:

Overigens zijn de kosten van het beheren van een standaard ook niet gelijk door de jaren heen. Sommige kostenposten kunnen flink veranderen. Tegenwoordig zien we posten als tactisch beheer flink stijgen, vooral door de relaties tussen de vele (internationale) standaarden die afstemming vergen. Indien de adoptie van de standaard succesvol is zal ook een post als implementatieondersteuning flink kunnen stijgen.

Natuurlijk wordt de vraag gesteld of standaarden niet goedkoper kunnen worden ontwikkelt en beheert. Dat is niet eenvoudig want veel standaardisatie-initiatieven, in het bijzonder ook in industriestandaardisatie, hebben de volgende kenmerken:

• Minimale kostenoriëntatie.
• Hobbyisme in de positieve zin van het woord.

Dat wil zeggen dat er veelal geen vet zit op de budgetten, en dat standaardisatieorganisaties keuzes moet maken in wat wel en niet uitvoerbaar is binnen het budget. Een relevante vraag is dan ook hoe verstandig de minimale kostenoriëntatie is in relatie tot de kwaliteit van de standaard en ook de adoptie van een standaard.

Een complexe standaard ontwikkelen kan miljoenen kosten, de voornaamste kosten zijn niet voor de ontwikkelen beheerorganisatie, maar voor de individuele deelnemers zoals:

• De tijd van de experts (vrijwilligers).
• De reis en vergaderkosten.
• Memberships fees en kosten voor aanschaf andere standaarden.

Efficiëntie kan mogelijk behaald worden in de doorlooptijd van het standaardisatie-proces. Tijd is geld en het ontwikkelproces voor standaarden is regelmatig extreem tijdrovend. Een tijdsbesparing in het ontwikkelproces kan veel kosten besparen. Voorbeeld hiervoor is de pressure cooker in de afvalbranche, waarin in een week het fundament voor de standaarden is gelegd.

De verschillende standaardisatieorganisaties per sector willen nog wel eens het wiel opnieuw gaan uitvinden, meestal uit onwetendheid, wat ook inefficiëntie tot gevolg heeft. Bijvoorbeeld de ontwikkelen beheerprocessen kunnen waarschijnlijk gekopieerd worden van een andere standaard in plaats van deze zelf te ontwikkelen. Daarnaast bijvoorbeeld is de kern van een validatie-service hetzelfde voor elke XML (of JSON) gebaseerde standaard; toch bouwen nog veel beheerorganisaties hun eigen validatie-service. Algemeen kan gesteld worden dat door middel van online tools de inzet van de vrijwilligers efficiënter gemaakt worden. Onderstaande tabel geeft als samenvatting een aantal suggesties weer om standaardisatie efficiënt in te vullen:

Besparingen door middel van innovatieve aanpakken in het ontwikkelproces kunnen ook een valkuil zijn. Een grote kostenpost zijn de face-to-face meetings. Besparingen hierop zijn de vele online mogelijkheden zoals online videoconferencing, fora, mailinglijsten, etc. Met name in de open source gemeenschap is de mening dat face-to-face meetings overbodig zijn en dat asynchrone communicatie voldoende moet zijn, ook om wereldwijd met alle tijdzones te kunnen opereren. Echter open source software ontwikkelen is niet gelijk aan open standaard ontwikkeling. Hetzelfde proces hanteren is dus een valkuil. Bij standaarden gaat het om complexe materie en functionaliteit, waarbij wederzijds begrip en ook vertrouwen van groot belang zijn. Directe communicatie, face-to-face, is belangrijk. In de COVID pandemie zijn de online ontwikkelingen snel gegaan, en ook geaccepteerd geraakt; uiteraard is het wel verstandig om hiervan te profiteren. Efficiëntie betekent de juiste mate van face-to-face, online meetings, en ander gebruik van online tools voor communicatie en het afhandelen van de technische zaken. In andere woorden: innovatieve ontwikkelaanpakken zoals de pressure cooker en gebruik van het Web kunnen zeker besparingen opleveren, maar zullen kostbare face-to-face meetings niet vervangen.

De business case van standaardisatie is een veel gehoord onderwerp. Voordat het besluit tot investering genomen kan worden is eerst inzicht in de business case noodzakelijk. Eigenlijk gaat het om verschillende business cases:

1. De business case van de standaard (oftewel de keten)
2. De business case van een individuele organisatie om de standaard te implementeren
3. De business case van een nieuwe versie van een standaard.

De eerste business case is voor de overheid interessant om beleid rond standaardisatie op af te stemmen. Vaak onderdeel van beleid rond een groter maatschappelijk of economische vraagstuk. Uiteraard is deze business case ook relevant voor de standaardisatie-organisatie, maar een individuele organisatie kan er niet veel mee. Deze heeft een andere business case nodig, specifiek voor haar rol in de keten.

Kwantitatieve onderzoeken naar de business case van standaardisatie zijn lastig uit te voeren en leiden niet altijd tot nuttige inzichten. Dit neemt niet weg dat kwalitatief onderzoek wel relevant kan zijn en wel goed uitvoerbaar is. Alleen al het inzicht te weten bij welke partijen de voordelen zitten en het identificeren van de organisaties die geen voordelen hebben is waardevol. Daarnaast is het waardevol om te weten welke partijen relatief meer voordeel hebben dan andere partijen ook al hebben ze dezelfde rol. Zo kan bijvoorbeeld de marktleider minder voordeel hebben ten opzichte van de runner-up, net zoals een organisatie die een moderne back-office heeft mogelijk meer voordeel kan hebben. Op basis van deze inzichten kan potentieel het gedrag van de deelnemers in de werkgroepen worden verklaard. De kwantitatieve business case is lastig omdat standaarden geen doel zijn maar een middel om het doel van interoperabiliteit te behalen. De business case gaat dan feitelijk ook om interoperabiliteit. In lijn hiermee zijn er in de praktijk vaak geen projecten die als doel hebben een standaard te implementeren, maar juist projecten die interoperabiliteit voor bijvoorbeeld inkoop realiseren. Dit betekent dat de business case van het project breder is dan de standaard. Bijvoorbeeld regelmatig zien we projecten die van een papieren uitwisseling overstappen naar een digitale gestandaardiseerde uitwisseling waarbij ook procesoptimalisatie gaat plaatsvinden. De standaard is daarmee een (belangrijk) onderdeel geworden van een veel groter project. Het is daarbij lastig toe te wijzen welke opbrengsten en kosten aan de standaard toekomen binnen het grotere project. Daarbij is er ook sprake van kwalitatieve baten, die vervolgens kwantitatief uitgedrukt moeten worden.

Bijzondere aandacht verdient ook business case type 3: Vervangende standaard/ nieuwe versie. Hiervoor is het relatief eenvoudig de business case op te stellen, maar deze is in de praktijk niet positief te krijgen. Bijvoorbeeld rond e-facturatie: Als een organisatie al e-factureert met bijvoorbeeld UBL of SETU, dan is de business case naar een nieuwe standaard (UN/CEFACT Cross Industry Invoice) niet of nauwelijks positief te krijgen. Daarom zullen er altijd een zeer lange tijd ook nog oude standaarden (bijv. EDI) in gebruik zien, omdat er geen positieve business case voor de nieuwe/andere standaard is, zolang er geen interoperabiliteitsprobleem is. Eén van wereldwijd meest succesvolle standaard, RosettaNet (www.rosettanet.org), illustreert dit ook: ondanks dat deze standaard al jaren een XML versie heeft ontwikkeld is er nauwelijks migratie vanuit de oude EDI versie, en lang een lage adoptie van de XML versie heeft gehad.

Ondanks de geschetste moeilijkheden en de verschillende pogingen die al gedaan zijn, proberen we toch een aanpak te schetsen die inzicht kan bieden in de business case. De aanpak in deze paragraaf beschreven is gebruikt om een business case voor een semantische standaard in de juweliersbranche op te stellen: Stappenplan:

1. Beschrijf huidige situaties en toekomstscenario's en identificeer stakeholders.
2. Bepaal de kosten en baten in de keten op basis van het raamwerk.
3. Verdeel de kosten en baten naar verschillende stakeholders (Probeer de kosten en baten per stakeholder te kwantificeren).

De eerste drie stappen worden toegelicht:

2.2.6.1 Stap 1 - Beschrijf huidige situaties en toekomstscenario's en identificeer stakeholders.

De eerste stap begint met een analyse van de stakeholders; wat zijn de partijen die een relatie hebben tot het interoperabiliteitsprobleem waarin een mogelijke standaard een oplossing kan bieden. Voor het identificeren van de stakeholders, kan de NEN stakeholderanalyse gebruikt worden (zie sectie Werkgroep en stakeholders).

Vervolgens wordt de huidige situatie geanalyseerd; wat zijn de uitgangsposities van waaruit de primaire stakeholders moeten vertrekken. Daarbij dient ook het beeld van het toekomstscenario met standaard helder te zijn, zodat de migratiepaden van de huidige situatie naar de toekomstscenario's duidelijk zijn.

Het figuur geeft dit weer voor de primaire stakeholder de juwelier in dit voorbeeld. Uiteraard is het bij de implementatie de bedoeling om ervoor te zorgen dat zoveel mogelijk partijen in toekomstscenario 1 of 2 terecht komen en de standaard gaan gebruiken.

2.2.6.2 Stap 2 - Bepaal de kosten en baten in de keten op basis van het raamwerk.

In stap 2 wordt een kosten-baten model opgesteld. Wat zijn in generieke zin de eenmalige investeringen, de operationele kosten en de baten die van toepassing zijn op de standaard. Voor vele standaarden zal dat redelijk gelijk zijn, vandaar dat gestart kan worden met het model uit de juweliersbranche, en deze vervolgens aan te passen waar nodig. Het model uit de juweliersbranche is hieronder weergegeven.

Ken Krechmer heeft een model ontwikkeld waarmee de openheid concreet gemaakt wordt en waarmee hij standaardisatieorganisaties kan vergelijken. In het model maakt hij onderscheid tussen de verschillende openheidaspecten (requirements) en de verschillende gezichtspunten op standaarden. Als gezichtspunten/rollen hanteert hij de ontwikkelaar van de standaard, de implementator van de standaard in een product, en de gebruiker van de standaard (product waarin de standaard is verwerkt). Niet elk openheidsaspect is voor elke rol even interessant, zoals het model ook laat zien:

Deze 10 criteria voor open standaarden betekenen het volgende voor de beheerorganisatie:

1. Open Meeting betekent dat iedereen mag meedoen in het standaardisatie proces. Geen stakeholders uitsluiten. Ook het mogelijk maken om tegen lage kosten op een per-meeting basis deel te nemen is belangrijk. Dit maakt het ook voor studenten of voor MKB bedrijven mogelijk om aan te sluiten. Meetings moeten duidelijk aangekondigd worden en er moeten zo min mogelijk barrières zijn voor stakeholders om deel te nemen. Een ontwikkelen beheerorganisatie moet zuinig zijn op stakeholders die willen participeren. In veel gevallen is het niet eenvoudig om voldoende stakeholders op de been te krijgen die actief willen participeren. Dus in plaats van drempels is stimulering meer op zijn plaats. De valkuil is om meetings alleen open te stellen voor slechts een bepaalde groep van (betalende) stakeholders.

2. Consensus gaat over de besluitvorming binnen de organisatie. Is er een (groep van) organisatie(s) die dominant zijn? In principe zou iedere participant gelijke rechten moeten hebben en kunnen meebeslissen. De valkuil is om een dominante groep (bijv. het bestuur/partijen die financieel fors bijdragen) te hebben die volledige controle heeft.

3. Due Process gaat over de processen hoe stemrondes zijn georganiseerd en de processen voor verzoeken tot heroverweging (appel) van beslissingen. Er moeten procedures zijn voor klachten, en die procedures moeten inzichtelijk zijn. Hetzelfde geldt voor de procedures voor besluitvorming, en in het bijzonder het proces om mogelijke patstellingen te doorbreken. Valkuil is om dit niet georganiseerd te hebben.

4. One World betekent dat idealiter voor hetzelfde doel er één standaard op de wereld wordt gebruikt, ook ter voorkoming van handelsbarrières. Dit wil uiteraard niet zeggen dat het voor een specifiek doel of context niet mogelijk zou zijn om een nieuwe standaard neer te zetten. Maar het betekent ook dat er geen regionale of nationale standaard gecreeërd dient te worden als een wereldwijde standaard voldoet. In algemene termen betekent One World ook dat de standaardisatieorganisatie niet verkokert, met oogkleppen op, een standaard ontwikkelt zonder wetenschap van andere standaarden/initiatieven. De valkuil is om als standaardisatieorganisatie oogkleppen op te hebben, en alleen bezig te zijn met eigen standaarden terwijl er goede standaarden beschikbaar zijn, eventueel als halffabricaat. Open betekent hier open in relatie met andere standaardisatieorganisaties om geen overlappende maar aansluitende zaken te ontwikkelen. Een andere valkuil is een te beperkte scope te kiezen voor de te ontwikkelen of beheren standaard; bijvoorbeeld nationaal in plaats van wereldwijd.

5. Open IPR (intellectuele eigendomsrechten) is het aspect waar de meeste discussie over is geweest, waarbij met name 'royalty free' en 'onherroepelijk' de kernwoorden uit de definitie van open zijn. Standaardisatieorganisaties en leveranciers hebben lang getracht om 'RAND' (Reasonable and Non-Discriminatory) op te nemen in de definitie van openheid. Deze standaardisatieorganisaties voldoen dan ook vaak op dit punt niet aan de definitie van open, wat betekent dat vele standaarden die in de perceptie open zijn, volgens de definitie niet open zijn op dit punt. De definitie van open standaard laat aan duidelijkheid niks te wensen over, en voorkomt discussie over RAND, bijvoorbeeld wat is reasonable? Dat leidt tot veel discussie. Royalty free en onherroepelijk beschikbaar zou de standaard moeten zijn. De valkuil is om dit niet geregeld te hebben, wat bij veel semantische standaardisatieorganisaties het geval is. De intenties zijn goed (open), maar door het niet expliciet te regelen kan dat tot problemen leiden in de toekomst. Ook is vaak niks geregeld over de rechten van de bijdrage die 'vrijwilligers' vanuit externe partijen leveren in werkgroepen van de standaard. Dit is een potentieel gevaar voor de duurzaamheid van de standaard.

6. Open Change: Als een leverancier alleen gedwongen wordt om de standaard open beschikbaar te stellen, maar zelf op elk moment wijzigingen kan doorvoeren, zullen de voordelen van standaarden nooit bereikt worden en behoudt de ene leverancier zijn macht. Een open manier van wijzigingen in de standaard doorvoeren is van groot belang, maar krijgt tot op heden weinig aandacht. Standaardisatieorganisaties die niet voldoen aan open meeting, consensus en due process kunnen per definitie niet voldoen aan open change. Een open invulling kan geschieden door het beschrijven van wijzigingsprocessen waarbij geen partij een bijzondere status heeft in de besluitvorming. De valkuil is om het proces van wijzigingen niet open in te richten, helemaal omdat er vaak geen aandacht voor is.

7. Open Documents betekent dat alle documenten open beschikbaar zijn. Dat betekent dat niet alleen de standaarden zelf maar ook work in progress beschikbaar moet zijn, notulen van meetings, e.d. Daarmee kunnen gebruikers van de standaard de complete achtergrond doorgronden. De valkuil is om alleen de standaarden zelf open beschikbaar te stellen.

8. Open Interface is vooral relevant voor technische standaarden, en heeft betrekking op het ruimte laten voor leveranciers voor gesloten uitbreidingen, en daarnaast ook de ruimte bieden voor backward en forward compatibiliteit. Valkuil: het niet adresseren van backward compabiliteit en de ruimte bieden voor tijdelijke uitbreidingen (forward compatibiliteit).

9. Open Access: Eindgebruikers vertrouwen er vaak op dat hun leverancier(s) de standaarden correct hebben geïmplementeerd. Om 'Open Access' te bereiken moet het mogelijk te zijn om de implementatie van de standaard te testen (conformiteit); dat kan door middel van conformiteittesten (testprotocollen) tot aan officiële certificatie. Een andere mogelijkheid zijn zogenoemde plugfesten waarbij de interoperabiliteit tussen verschillende implementaties van een standaard inzichtelijk wordt gemaakt. De valkuil is om hier van uitstel naar afstel te gaan. De standaarden moeten een bepaalde mate van volwassenheid hebben wil dit zinvol zijn. Daarom wordt het vaak uitgesteld. En van uitstel volgt afstel. Een open invulling betekent ook het inzichtelijk (open) maken van het gebruiken van de standaard in implementaties, bijvoorbeeld door het publiceren van implementatieoverzichten.

10. Ongoing Support is het leveren van ondersteuning op de standaard gedurende de levenscyclus. De valkuil is het stoppen met het leveren van ondersteuning als de interesse van leveranciers afneemt. Een open invulling betekent op zijn minst dat de levenscyclus van een standaard beschreven is waarmee gebruikers garantie krijgen over de ondersteuning op de standaard. Idealiter dient de ondersteuning pas af te lopen als er geen interesse meer is in de standaard bij de eindgebruiker.

Veel van de huidige discussies over openheid gaan over slechts twee aspecten van openheid te weten, 'One World' en vooral 'Open IPR', terwijl de andere aspecten daardoor onderbelicht raken. Alle punten helpen bij het inrichten van maximaal open standaardisatieorganisatie. Tot op heden is er geen organisatie bekend die op alle punten volledig open is. Volledig open op al deze punten is een utopie, maar deze punten zijn wel aandachtspunten, en kunnen het denkproces helpen om standaardisatie meer open te krijgen. Overigens is het goed te weten dat de formele standaardisatieorganisaties in veel gevallen niet (of slechts ten dele) voldoen aan de aspecten 6-10.

Op basis van het voorgaande zijn er een aantal concrete tips op te stellen: Maak besluitvorming open door:

• Publiceren van de notulen van verschillende gremia.
• Consensus besluitvorming.
• Geen partijen uitsluiten bij bijeenkomsten.
• Een website met daarop alle documenten (ook drafts) kosteloos beschikbaar.
• Een duidelijke wijzigingsprocedure.
• Het testbaar maken van de standaard door middel van testprocedures, validatie, certificatie en/of plugfests.
• Regel structurele financiering.
• Veel aandacht besteden aan de relatie met andere standaarden in de omgeving.
• De rechten expliciet hebben vastgelegd; de intellectuele eigendomsrechten op de standaarden, copyrights op documenten, de bijdrage van personen in werkgroepen en in de totstandkoming van de standaarden. Versiebeheer vastleggen: hoe om te gaan met backward en forward compatabiliteit, en daarnaast de ondersteuning vastleggen op basis van de levenscyclus van een standaard.
• Het vastleggen in een document van de ontwikkelen beheeraspecten.

Het model van Krechmer is een ideaal startpunt maar kan aangevuld worden om meer praktische handvatten te bieden. Daartoe hebben we de criteria verder uitgewerkt in variabelen per criteria. Deze variabelen zijn beter te relateren aan de praktijksituatie. Tot slot kunnen er scores toegekend worden per variabelen; dat maakt openheid tussen standaarden ook vergelijkbaar. Theoretisch gezien zou er dan bijvoorbeeld een minimale score kunnen worden gedefinieerd willen we spreken over een open standaard. Echter dat doet geen recht aan het feit dat bepaalde variabelen belangrijker zijn dan andere variabelen.

Het model op de volgende pagina is een invulling van de 10 criteria van Krechmer en is een hulpmiddel om de beheer-activiteiten op een open manier in te vullen.

Het Forum Standaardisatie toetst standaarden op onder meer openheid voor opname op de pas-toe of leg-uit lijst. In deze bredere toets zijn de criteria van Krechmer ook verwerkt. Het model hier gepresenteerd is een verdieping, bedoeld als handreiking om openheid vorm te geven en kan niet gebruikt worden in het formele proces van opname voor de lijst van pas-toe of leg-uit. Meer informatie over de toetsingscriteria is te vinden via de website van het Forum Standaardisatie.

Onderdeel van het activiteitendiagram is moduleontwikkeling, dit wil zeggen dat de organisatie software kan (laten) ontwikkelen waarin de standaard geïmplementeerd is. Gevaarlijk is om dit als standaardisatieorganisatie zelf 'commercieel' te doen aangezien de standaardisatieorganisatie een concurrent wordt van andere leveranciers in de markt. De ondersteuning van de standaard door andere leveranciers zal dan snel afnemen. Door het ontwikkelen op basis van open source wordt dit deels ondervangen. De open source module waarin de standaard is verwerkt komt dan vrij beschikbaar waardoor de commerciële leveranciers dit verder kunnen oppakken, en op termijn kan de standaardisatieorganisatie haar handen er vanaf trekken. Het is dan ook voornamelijk een middel (stimulans) om de markt in beweging te krijgen.

Verder is Open Source Software een prima alternatief voor gesloten source software. Het voornaamste verschil is het business model. Voor de adoptie van een standaard is het belangrijk dat de standaard geïmplementeerd wordt in alle software, ongeacht het business model. Het is in enige mate gevaarlijk, vanuit adoptie oogpunt, om een bepaald type leverancier een voorkeursbehandeling te geven aangezien daarmee weerstand gecreëerd wordt bij andere leveranciers.

Open Source Software dient zeker niet verward te worden met open standaarden. Dit zijn wezenlijk andere concepten, waarbij vanuit het oogpunt van interoperabiliteit alleen open standaarden essentieel zijn.

Om interoperabiliteit (uitwisselbaarheid) te bewerkstelligen tussen organisaties of systemen is een complexe set van standaarden nodig. Dit maakt de materie uitermate lastig want het gaat niet meer om het kiezen of beheren van één standaard, maar het gaat om een set van standaarden die op sommige gebieden sterk aan elkaar gerelateerd zijn. Een onderscheid is daarbij te maken in standaarden voor technische zaken en standaarden voor de semantiek van informatie-uitwisseling. Het interoperabiliteitsraamwerk (op basis van Jian, H., & Zhao, H. (2003). A Conceptual Model for Comparative Analysis of Standardization of Vertical Industry Languages.) laat dit zien; tussen haakjes staan engiszins verouderde voorbeelden van standaarden waarmee dit kan worden ingevuld.

Voor technische interoperabiliteit moeten er keuzes gemaakt worden, waarbij vaak gekozen wordt voor een technische filosofie waarbij een familie van standaarden hoort; Echt veel keuzes zijn er eigenlijk niet. Bijvoorbeeld als communicatiemechanisme is het Internet met als standaarden TCP/IP, HTTP, etc. voor de hand liggend. Op het gebied van messaging (transport) mechanisme is er misschien meer keuze, maar Web Services als familie hier lange tijd voor de hand liggend, en inmiddels zijn REST APIs defacto standaard geworden. De keuze voor Web services brengt een keuze voor de individuele standaarden (zoals SOAP, WSDL, etc.) met zich mee. Overigens is de keuze voor deze technische standaarden alleen niet voldoende. Om interoperabiliteit te bereiken zijn doorgaans nog profielen nodig bovenop deze standaarden waarin beschreven staat hoe de opties in de standaarden ingevuld moeten worden. Ook al is dit niet domeinspecifiek wordt dit nu vaak per domein ingevuld, vooral om gebruikers een complete interoperabiliteitsoplossing te kunnen bieden in combinatie met de semantische standaarden.

Tot slot is de keuze voor de technische standaard JSON tegenwoordig voor de hand liggend. In het verleden was XML, en daarvoor EDI de aangewezen technologie. Deze wordt nog veel gebruikt in bestaande situaties, maar niet meer in nieuwe situaties.

De technische standaarden zijn randvoorwaardelijk, maar de echte uitdaging ligt bij de semantische standaarden waarin de betekenis van de informatie-uitwisseling centraal staat. Verticale semantische standaarden zijn gericht op een specifieke sector, terwijl horizontale sector overstijgend zijn. In de praktijk zijn verticale standaarden noodzakelijk om goed aan te sluiten bij de context van de organisatie. Verticale standaarden kunnen een nadere invulling zijn van horizontale standaarden, zie hiervoor de volgende paragraaf.

Om het nog complexer te maken zijn er standaarden die gebruikt worden om standaarden te maken, denk bijvoorbeeld aan de standaard UML, als taal om diagrammen te tekenen die bijvoorbeeld het proces en data-model van een standaard bevatten.

Semantische standaarden kennen een ongekende complexiteit in vergelijking met andere standaarden en worden anders ontwikkeld en beheerd. Het merendeel van de IT-standaarden wordt al buiten de officiële standaardisatieorganisaties (zoals ISO en NEN) ontwikkeld, namelijk in zogenoemde industrieconsortia zoals W3C en OASIS. Wanneer we naar semantische standaarden kijken, gaat het echter nog een stap verder aangezien die grotendeels door een eigen organisatie ontwikkeld worden.

De praktijk laat zien dat alleen een onderscheid tussen horizontale en verticale standaarden te beperkt is. Internationale verticale standaarden hebben vaak nog een specifieke invulling nodig om bijvoorbeeld in de context van een land (zoals Nederland) perfect te kunnen aansluiten bij de bedrijfsprocessen in die context. Dit is noodzakelijk om interoperabiliteit te kunnen behalen. Op nationaal niveau ontstaan dan standaarden, ook wel afspraken of toepassingsprofielen genoemd, die een verdere invulling bevatten van een internationale standaard. Daarnaast worden er ook regelmatig specifieke codelijstjes voor de nationale context toegevoegd. Dit leidt tot de volgende classificatie:

• Internationale horizontale standaard
• Internationale verticale standaard
• Nationale standaard/toepassingsprofiel/afspraak/taxonomie
• Nationale vocabulaires, codelijstjes, etc.

Ook in de organisaties is dit terug te zien: HL7 is de internationale standaard, en daarnaast is er HL7 Nederland. Bij het internationale HR Open Standards is het SETU dat Nederlandse HR Open Standards profielen maakt.

Alle vormen, of het nu een internationale horizontale standaard is of een nationaal codelijstje, moeten allemaal ontwikkeld en beheerd worden! Overigens wil het niet zeggen dat alle vier de classificaties voor een bepaald toepassingsdomein moeten voorkomen. In de praktijk kan elke willekeurige combinatie voorkomen, afhankelijk van de situatie.

Tijdens de adoptiefase is nog wel eens een gehoorde opmerking dat men alleen de internationale standaard wil adopteren in plaats van de nationale. De argumentatie is meestal dat men wereldwijd zaken doet, of dat de internationale standaard breder aansluit of breder bekend is. In de praktijk zal dit echter leiden tot beperkte interoperabiliteit aangezien de internationale standaard minder goed zal aansluiten en veelal ook te veel vrijheidsgraden kent. Omdat interoperabiliteit het doel is van standaarden is het geen verstandige keus. Men zou zich moeten richten op de nationale standaard die zorg draagt voor aansluiting bij internationale standaarden en zorg draagt voor optimale toepassing in de Nederlandse context.

Belangrijk aandachtspunt daarbij is dat in een situatie van bijvoorbeeld een internationale verticale standaard in combinatie met een nationaal toepassingsprofiel, dat voor beide een andere naam wordt gehanteerd om verwarring in de praktijk voorkomen.

XBRL is een voorbeeld van een internationale verticale standaard (in de financiële sector) waarvoor nationale taxonomieën zijn opgesteld, bijvoorbeeld de US GAAP of in Nederland door het SBR programma.

In het kader van e-factureren heeft de Nederlandse overheid gekozen voor een internationale horizontale standaard (UBL), en heeft men vervolgens zelf een factuurmodel ontwikkeld om de vrijheidsgraden te beperken. Dus ook hier is er sprake van een nationaal toepassingsprofiel om uiteindelijk interoperabiliteit te kunnen bereiken.

Tot slot, ook binnen de standaarden zelf kan weer gelaagdheid ontstaan, op verschillende manieren. Tussen verticalen sector modellen en horizontale standaarden, en daarnaast worden ook andere (bv. technische) standaarden vaak samen toegevoegd om een totaal oplossing te bieden voor interoperabiliteit.

Door de sector-specifieke aanpak van de semantische standaarden ontstaat de angst voor verzuiling van sectoren. Interoperabiliteit over sectoren heen wordt niet opgelost, en wordt zelfs mogelijk steeds lastiger. Het potentiële probleem is alom bekend, en oplossingen worden daarvoor bedacht maar tot op heden stranden deze in zeer lage adoptie en gebrek aan draagvlak en ondersteuning. Dat kan twee oorzaken hebben;

1. Het probleem van sector overstijgende interoperabiliteit wordt nog niet als nijpend beschouwd aangezien binnen de sector nog grotere uitdagingen liggen.

2. De voorgestelde technische oplossingen zijn vaak uitermate complex. Bijvoorbeeld een technisch fraaie oplossing is de UN/CEFACT Core Components standaard. Deze standaard is meer dan tien jaar oud, maar is uiteindelijk nooit breed geadopteerd.

De kern van de oplossing zit hem waarschijnlijk niet in de techniek, maar in de beheerorganisaties actief in de verschillende domeinen. Deze zullen minder verkokerd moeten optreden en meer moeten samenwerken met de collega beheer-organisaties in aanverwante sectoren. Daar is de laatste jaren dan ook al verbetering in opgetreden. Mede ook op basis van het 'open' gedachtegoed, want in een one world (zie sectie over openheid) zijn er geen concurrerende standaarden en sluiten standaarden perfect op elkaar aan.

De vorige paragrafen maken helder dat semantische standaarden in de meeste gevallen een gelaagdheid kennen en daarmee voortbouwen of gebruik maken van andere standaarden. Interessant daarbij is een probleem dat generiek is voor het ontwikkelen van standaarden, maar in de pressure cooker nadrukkelijk naar voren komt: de omgang met formele (o.a. ISO, CEN, NEN) standaarden. Uitgangspunt is namelijk dat er zoveel mogelijk hergebruik plaatsvindt van bestaande standaarden en dat niet het wiel opnieuw uitgevonden wordt.

Bij formele standaarden zijn er een aantal pijnpunten:

Het niet kunnen inzien van de formele standaarden: Een aantal keren werd in de pressure cooker sessie melding gemaakt dat een bestaande formele standaard mogelijk al een (deel)oplossing bevat. Echter niemand weet het zeker want niemand heeft de standaard ingezien omdat er kosten aan verbonden zijn. Ook al kunnen de kosten beperkt zijn, de drempel is te hoog. Nu moest door de begeleider na afloop van de dag de standaard maar aangeschaft worden, om er soms na drie minuten achter te komen dat de standaard niet bruikbaar was. Dit staat snelle voortgang (in de pressure cooker) in de weg. In de praktijk blijkt (bijv. bij Geonovum en SETU) dat zelfs een 'gratis registratie' al als een te hoge drempel wordt ervaren.

De kosten tijdens het ontwikkelen van standaarden: De kosten voor aanschaf van een formele standaard (specificatiedocument) zijn gemiddeld grofweg 100 euro per standaard. Relatief een klein bedrag bij de ontwikkeling van een nieuwe standaard, soms hooguit zonde als direct na aanschaf blijkt dat die niet relevant is. Maar een groter probleem is het aantal; bijna nooit is het één standaard die aangeschaft moet worden. In het geval van de pressure cooker voor de afvalsector ging het naast de aanschaf van een DIN standaard, ook om de aanschaf van NEN-, en ISO-standaarden, waarbij een ISO standaard uit vier delen bestaat die los aangeschaft dienen te worden. Dan nemen de kosten, maar ook de frustratie over het gedoe verder toe. Dit gedoe heeft vaak ook met inkoop-proces binnen een organisatie te maken. Al snel ontstaat een laat maar, zal toch wel niet nuttig zijn gevoel.

Dit probleem kan ondervangen worden door de werkgroep/pressure cooker onder te brengen bij het NEN, aangezien NEN werkgroepen onbeperkt inzage hebben in de standaarden. Echter aan het onderbrengen van de werkgroep bij NEN zijn ook kosten verbonden.

Hergebruik: De waarde van de formele standaarden is groot. Ook in de pressure cooker voor de afvalsector werd genoeg waardevols in de bestaande formele standaarden gevonden, waardoor zeker niet het wiel opnieuw uitgevonden hoefde te worden. Alleen dan wordt het onduidelijk hoe de formele standaarden hergebruik toestaan. Er bestaan twee opties:

• Verwijzen naar de formele standaard, maar dat leidt tot kosten voor implementaties (zie onder).
• Een stuk uit de formele standaard overnemen.

Dit laatste is met name nuttig als de formele standaard veel breder (of voor een ander domein) van toepassing is maar dat de keuzes ook prima van toepassing zijn op 'onze' standaard. Wel leidt het tot vraagstukken rondom de openheid van het eindresultaat. Het NEN hanteert als vuistregel dat 10% overgenomen mag worden na overleg met het NEN. Dit laatste is ook noodzakelijk zodat NEN kan controleren of er geen patenten worden geschonden die op de formele standaarden kunnen rusten.

De kosten voor de implementaties: Als verwezen wordt naar een bestaande formele standaard, dan zal elke leverancier die de standaard wil implementeren deze formele standaard moeten aanschaffen. De eigen standaard kan dan wel open en gratis beschikbaar zijn, maar door de verwijzing creëren we toch een adoptiedrempel, en mogelijk risico dat de standaard verkeerd geïmplementeerd wordt omdat men tijdens de implementatie besluit de formele standaard niet aan te schaffen. Dus worden alle implementatie-partijen opgezadeld met kosten en wordt zo toch een adoptie en interoperabiliteits-drempel gecreëerd, wat niet de bedoeling was.

Als we in een nationale, sectorspecifieke context, een internationale standaard willen gebruiken, dan creëren we een belangrijke afhankelijkheid. De invulling van de relatie tussen de nationale en internationale standaard kan op verschillende manieren worden ingevuld, afhankelijk van de context en de gekozen strategie. Idealiter wordt gewoon de internationale standaard volledig geadopteerd, maar in de praktijk weten we dat een internationale standaard bijna nooit een op een overgenomen kan worden; soms zijn veranderingen beperkt: slechts wat extra zaken die voor de specifieke nationale context toegevoegd moeten worden om interoperabiliteit te kunnen bereiken.

De volgende situaties kunnen zich voordoen:

• De specifieke context vergt uitbreidingen/aanpassingen aan de standaard.
• Er zitten vele overbodige zaken in de standaard die zorgen voor extra complexiteit die niet nodig is voor de specifieke context.
• Er worden fouten gevonden in de internationale standaard.
• Er missen zaken in de standaard die niet specifiek zijn voor de context.
• Er is behoefte aan een nieuwe standaard.

Algemeen gesproken kunnen dan de volgende activiteiten ondernomen worden:

• Aanpassen in de internationale standaard (en brengen de aanpassingen niet terug naar de internationale standaard) (Adaptations)
• Toegestane uitbreidingen aan de standaard invullen (Extensions)
• Zaken uit de standaard halen (Ommissions)
• Passen de standaard tijdelijk aan (we brengen de gewenste aanpassingen in bij de internationale standaard, maar hebben nu een oplossing nodig die tijdelijk is, totdat de internationale standaard is aangepast) (Temporary Adaptations)

De strategieën:

Met name om interoperabiliteit internationaal mogelijk te maken is het verstandig om zoveel mogelijk in lijn te blijven met de internationale standaarden en een strategie te kiezen aan de rechterkant van het figuur, waar mogelijk compliant profiling. Echter dat vergt afstemming met de internationale standaard, waaraan kosten verbonden zijn, ondermeer door het bezoeken van de internationale standaardisatie bijeenkomsten. Een noodzakelijkheid om interoperabiliteit in internationale context na te streven.

Linked Data heeft een lange weg doorgemaakt, maar is inmiddels de defacto standaard voor semantisch modelleren. De standaarden en technologieën die hieronder vallen, zoals RDF, SPARQL en OWL, worden steeds meer in de praktijk geadopteerd. Dat begon in de academische wereld maar heeft zich de afgelopen jaren uitgebreid naar de publieke sector en het bedrijfsleven.

Linked Data brengt veranderingen in de semantische standaardisatiediscipline die BOMOS omschrijft. Het gaat niet enkel om het gebruik van nieuwe technologieën en hulpmiddelen. Linked Data betekent een andere benadering tot semantische interoperabiliteit: de nadruk verschuift van het standaardiseren van berichten (of 'transacties') naar het standaardiseren van de onderliggende domeinbeschrijving; de taal. Met vocabulaires en ontologieen wordt de taal in een domein gestandaardiseerd, maar ook relaties tussen domein-ontologieën kunnen gelegd worden, waardoor Linked Data de grenzen van sectoren weet te doorbreken en een middel voor domein-overstijgende interoperabiliteit is geworden. Daarnaast voldoen de Linked Data standaarden aan de open standaarden criteria, en een aantal zijn dan ook opgenomen op de pas-toe of leg-uit lijst van de Nederlandse Overheid.

Uit werkgroepen van het Forum Standaardisatie komt een aantal kritieke succesfactoren naar voren die bij de adoptie van verschillende standaarden een rol hebben gespeeld:

1. De standaard moet volwassen zijn; anders durft niemand te investeren.
2. Geduld: Adoptie van een standaard vergt tijd, soms meerdere jaren.
3. De voordelen moeten voor iedereen helder zijn, voor het bedrijfsproces, maatschappelijk en financieel; er is draagvlak.
4. Er moet een betrokken probleemeigenaar zijn, juist ook omdat adoptie vele jaren duurt; echt commitment is onontbeerlijk.
5. Er is een kritieke massa van gebruikers nodig.
6. Een leidende partij of een leidend proces kan adoptie sterk stimuleren.
7. Er moet een actieve community zijn die betrokken is bij ontwikkeling en gebruik van de standaard.
8. Er is geld nodig voor ondersteuning, opleiding, beloning etc.
9. Gebruik een goede mix van adoptiemiddelen.

Het is niet gemakkelijk om de juiste strategie te kiezen voor het bevorderen van de adoptie van een standaard. Soms is een dergelijke strategie niet nodig en wordt de standaard volledig 'gedragen' door partijen in het veld. Vaak hangt een standaard echter samen met een bredere ontwikkeling. Denk bijvoorbeeld aan een standaard voor digitalisering van een keten. De invoering van de standaard hangt dan samen met de vraag of een organisatie aan de slag gaat met die digitalisering.

De middelen voor adoptie kunnen onderverdeeld worden in drie groepen:

• Financieel: de 'peen' het stimuleren van de adoptie door het faciliteren van het gebruik van de standaard. Voorbeelden van middelen zijn het geven van subsidie of het bieden van implementatie-instrumenten die de kosten van een implementatie verminderen.
• Communicatief: de 'preek' het geven van voorlichting over de voordelen die de standaard biedt voor organisaties. Bijvoorbeeld door het schrijven van artikelen of het organiseren van seminars.
• Juridisch: de 'zweep' het verplichten van het gebruik van een standaard. Bijvoorbeeld door de standaard op te nemen op de lijst met open standaarden voor 'pas toe of leg uit' van het Forum Standaardisatie.

Meestal is er niet één altijd passende strategie. De keuze zal afhangen van de bestaande en gewenste situatie en van tal van omgevingsfactoren. Adoptiemiddelen kunnen bijvoorbeeld verschillen in of afhangen van:

• de keuze voor de primair aan te spreken doelgroepen: alle gebruikers specifieke gebruikers, softwareleveranciers
• de middelen die worden ingezet: verleiding, contracten, wetgeving, commerciële dwang
• de aanpak: klein beginnen, of direct groot; eerste kleine groep, of direct de hele doelgroep; eerst een klein deel van de standaard en later meer
• de bestaande situatie in de doelgroep: Is gegevensverkeer daar al gemeengoed? Worden daar al oudere of andere standaarden gebruikt?
• de dominante voordelen die de standaard met zich mee moet brengen of het dominante probleem waarvoor zij een oplossing is: Waar vallen de grootste baten van de standaard? Waar de kosten? Wie voelt het meest de huidige beperkingen?
• intrinsieke aspecten van de standaard: Hoe complex is deze? Wat is zijn werkingsgebied? Welke kennis is nodig voor de toepassing ervan?

Voorbeelden van adoptiemiddelen:

• Informeren/adviseren.
  • Informatie-event organiseren.
  • Voorlichtingsdagen.
  • Presentatie op een congres.
  • Artikelen in magazines.
  • Advies over gebruik van de standaard.
• Betrekken en beïnvloeden.
  • Collectieve business case opstellen en verspreiden.
  • Documenteren cases.
  • Publiceren overzicht met gebruikers.
  • Open standaardisatieproces.
  • Oprichten klankbordgroep.
  • Community building.
  • Oprichten samenwerkingsplatform.
  • Afstemmen softwareleveranciers van gebruikers.
• Samenwerken en faciliteren.
  • Testbed voor implementatie van de standaard.
  • Uitvoeren van gezamenlijke pilots.
  • Plugfest organiseren.
  • Partnerschappen realiseren.
  • Validators.
  • Business case tool.
  • Referentie implementaties.
• Ontlasten en subsidiëren.
  • Subsidie voor invoering.
  • Financiering implementatie bij software leveranciers.
  • Opstellen van een specifiek plan van aanpak.
  • Het invoeren van een eigen implementatie die als 'broker' fungeert.
  • Certificering.
  • Gratis implementatie ondersteuning.
• Onderhandelen en contracteren.
  • Bestuurlijke verankering bij gebruikers.
  • Opstellen convenant.
  • Contract opstellen tussen sturende actor en ketenpartijen.
• Opdragen en verplichten.
  • Opleggen via de lijst met open standaarden voor 'pas toe of leg uit'.
  • Wettelijke dwang.

We beschrijven vijf stappen om de juiste keuzes te kunnen maken voor adoptie in een bepaalde sector organisaties:

3.3.3.4 Stap 4: Middelen keuze en planning

Vervolgens moet gekeken worden naar de middelen die passend zijn bij de individuele en collectieve adoptiekans.

Een hoge individuele adoptiekans leidt doorgaans tot een communicatief middel. Immers: de kans is hoe dan ook al groot dat een organisatie besluit tot adoptie van de standaard.

Een gemiddelde individuele adoptiekans leidt doorgaans tot een financieel middel. Er is een duwtje in de rug nodig om over te gaan tot adoptie van de standaard. Een lage individuele adoptiekans leidt doorgaans tot een juridisch middel. Zonder dwang zal een organisatie waarschijnlijk niet overgaan tot adoptie van de standaard.

Een zogenoemd 'plugfest' of 'plugtest' (ook wel 'connectathon' genoemd) is een adoptiemiddel op het gebied van samenwerken & faciliteren. De kern van een plugfest is om leveranciers die de standaard geïmplementeerd hebben bij elkaar te laten komen, en interoperabiliteit tussen de leveranciers/systemen ter plekke gaan testen aan de hand van scenario's.

Tijdens een plugfest wordt in een bijeenkomst de implementatie van een standaard getoetst door te onderzoeken of de door de standaard beoogde informatie-uitwisseling tot stand komt. Om dit te toetsen kunnen scenario's gebruikt worden. In deze scenario's worden stappen doorlopen die tijdens normaal dagelijks gebruik van de standaard ook worden doorlopen. De scenario's richten zich op de uitwisseling van informatie tussen applicaties.

Indien een scenario niet succesvol wordt doorlopen dan kan worden onderzocht waar dit aan ligt. Dit hoeft overigens niet altijd aan de implementatie van de standaard te liggen, maar kan ook andere oorzaken hebben die de interoperabiliteit in de weg staan. Indien mogelijk wordt het euvel ter plaatse verholpen waarna het scenario nogmaals doorlopen kan worden.

Vanuit een standaardisatie-organisatie bekeken kan het organiseren van een plugfest een positieve bijdrage leveren aan:

interoperabiliteit: plugfests bieden leveranciers die de standaard hebben geïmplementeerd de mogelijkheid de implementatie van die standaard te toetsen tegen andere implementaties van andere leveranciers. Eventuele fouten kunnen direct of in later stadium gecorrigeerd worden en onderdelen van de standaard die nog onvoldoende helder gespecificeerd blijken, komen op deze manier boven tafel.

transparantie: leveranciers weten na afloop van een plugfest met welke collegae zij kunnen samenwerken op basis van de standaard. Indien er publiek aanwezig is bij het plugfest dan krijgt dit een beeld van de wijze waarop verschillende leveranciers met de standaard omgaan en welke applicaties van leveranciers goed samenwerken.

adoptie: leveranciers kunnen zich onderscheiden door te participeren aan een plugfest. Door publiek uit te nodigen kan de standaard ook onder aandacht van eindgebruikers gebracht worden.

Een andere manier om te kijken naar de adoptie van een standaard is door te analyseren welke factoren bijdragen aan het adoptieproces. Bij ieder van deze factoren zijn er instrumenten die de adoptie kunnen verbeteren:

Relatieve voordelen dragen bij aan de adoptie van een standaard. Een organisatie heeft voordeel bij het gebruik van een standaard. Deze voordelen kunnen zichtbaarder gemaakt worden door:

• Voordelen te communiceren.
• Business cases te tonen.
• Best practices te ontwikkelen.

Hoge adoptie kosten hebben een negatieve invloed. Getracht kan worden deze kosten te verminderen. Bijvoorbeeld door:

• Subsidie te verlenen.
• Implementaties makkelijker te maken, bijvoorbeeld door hulpmiddelen beschikbaar te stellen.

Institutionele effecten hebben betrekking op afspraken vanuit de wet of in een sector, die een meer of minder verplichtend karakter hebben voor het gebruik van de standaard. Instrumenten zijn ondermeer:

• Contractuele afspraken maken met gebruikers.
• Opnemen in wettelijke afspraken of via de lijst voor 'pas toe of leg uit'.
• Andere juridische verplichtingen.

Een belangrijk, vaak vergeten factor is community ideologie. Een sterke community rondom een standaard kan bijdragen aan de adoptie. Door de community te versterken en zo mogelijke 'evangelisten' te zoeken kan de adoptie versterkt worden.

Een toenemend gebruik versterkt zichzelf vanwege netwerkeffecten. Dit kan daarom ook onderdeel uitmaken van de adoptiestrategie. Bijvoorbeeld door een grote organisatie te strikken die gebruik gaat maken van de standaard, door het organiseren van partnerships, gratis implementaties of het organiseren van een plugfest.

Een standaardisatie-organisatie heeft doorgaans vooral een netwerkperspectief op de adoptie van hun open standaarden. Een ander perspectief is dat van een individuele organisatie. Deze individuele organisatie moet keuzes maken op het gebied van de te gebruiken standaarden. Sturingsmiddelen voor een organisatie om gericht te sturen op de adoptie van open standaarden zijn onder andere:

Compliance management: waarin een organisatie definieert hoe het met verplichte standaarden omgaat.
Het IT-beleid: waarin een organisatie de grote lijnen op het gebied ICT en open standaarden definieert. Architectuur management: de modellen en principes (waaronder de toe te passen standaarden) waaruit het ICT-landschap is opgebouwd.
Portfolio management: de kwaliteitscriteria van projecten, de inzet van middelen voor ICT-innovatie en vernieuwingsprojecten. Dit is bijvoorbeeld van belang voor het toekennen van middelen aan een migratie naar een bepaalde (nieuwe) open standaard.
Inkoop en leveranciersmanagement: de eisen die aan leveranciers worden gesteld.

Voor een standaardisatie-organisatie zijn dit aangrijpingspunten om de adoptie binnen een specifieke partij te stimuleren. Daar zit ook de samenhang met de adoptiemiddelen die een standaardisatie-organisatie kan inzetten. Bijvoorbeeld:

1. Door juridische middelen (pas toe of leg uit, opname in de wet) wordt een organisatie gedwongen om binnen het compliance managementproces te bepalen hoe een bepaalde standaard wordt ingebed.
2. Door voorbeelden te geven of referentiemodellen te bieden kan gestimuleerd worden dat een organisatie een standaard opneemt in de doelarchitectuur.
3. Via financiële middelen kan de migratie naar een standaard meer prioriteit krijgen in het portfolio management proces.
4. Tenslotte kan door bijvoorbeeld het bieden van modelbestekken de adoptie worden versneld op het gebied inkoop.

Veel organisaties streven naar interoperabiliteit, waarbij semantische standaarden een middel zijn om dit doel te behalen. De afgelopen jaren zijn dan ook vele semantische standaarden geïntroduceerd. Er is echter weinig bekend over de kwaliteit van semantische standaarden. Dat is opmerkelijk, want de kwaliteit van die standaarden is ongetwijfeld van invloed op de mate waarin het doel van interoperabiliteit behaald kan worden.

In tegenstelling tot andere disciplines, zoals software-engineering, is er weinig literatuur en kennis beschikbaar over wat een kwalitatief goede standaard is die een effectieve bijdrage levert aan interoperabiliteit. Dit definieert ook ons kwaliteitsbegrip: fitness for use! (definitie van kwaliteitsgoeroe Juran). Het overheidsbeleid richt zich voornamelijk op de openheid van een standaard, wat slechts één kwaliteitsaspect is. Een kwalitatief hoogwaardige standaard is ongetwijfeld een open standaard, maar het omgekeerde is niet noodzakelijkerwijs waar: een open standaard hoeft niet per definitie een kwalitatief hoogwaardige standaard te zijn. Overigens wordt in de toetsing van standaarden voor de 'pas-toe-of leg-uit lijst' van de Nederlandse overheid een sterke nadruk gelegd op de openheid, maar onderkent ook dat er meer kwaliteitsaspecten (bruikbaarheid, potentieel en impact) zijn die ook meegenomen worden in de toetsing voor opname op de lijst.

Semantische standaarden worden meestal door eigen organisaties ontwikkeld, en niet binnen grote standaardisatieorganisaties. Dit kan impact hebben op de kwaliteit; op zijn minst zal de kwaliteit daardoor sterk verschillen per semantische standaard.

3.4.1.1 Wat vinden de standaardisatieorganisaties zelf van de kwaliteit?

Een onderzoek onder 37 beheerorganisaties van standaarden (waaronder internationale standaarden zoals XBRL, HR-XML, ACORD en HL7 en nationale standaarden zoals SETU, StUF en Aquo) laat zien dat meer dan 90 procent van de ondervraagde opstellers van standaarden vindt dat de kwaliteit van hun standaard verbeterd kan worden (zie onderstaande figuren). Daarnaast vindt ook een zeer ruime meerderheid dat een verbetering in kwaliteit van hun standaarden zal bijdragen aan betere interoperabiliteit.

3.4.1.4 Het kwaliteitsinstrument gebruiken

De relatie tussen interoperabiliteit en standaarden is die van doel-middel. Zonder het kwaliteitsaspect in ogenschouw te nemen worden standaarden te veel gezien als heilige graal. De standaard wordt het doel, in plaats van een middel om op een effectieve en efficiënte manier interoperabiliteit te bereiken. Een aandachtsverschuiving naar de kwaliteit van standaarden voorkomt dat standaarden een doel op zich worden en zal de relatie tussen standaarden en interoperabiliteit versterken.

Het kwaliteitsmodel is een startpunt om te gebruiken om de kwaliteit van een standaard te bekijken. Bij de ontwikkeling wordt ook gekeken naar de kosten van een kwaliteitsmeting, waarbij vooral de uren relevant en kostbaar zijn. Uitgangspunt is dat de kwaliteitsmeting in slechts een paar uur uitgevoerd kan worden, zodat de kosten beperkt zijn en opbrengst dan ook al snel de kosten zal overtreffen. Het is met name geschikt voor de standaardisatie-ontwikkelaar zelf die de eigen standaard goed kent en het model als denkkader kan gebruiken om de eigen standaard mee te analyseren.

De belangrijkste vraag is wat het gebruik van het kwaliteitsinstrument voor standaarden oplevert. Kort samengevat:

• een model om naar de standaard te kijken: een frisse blik / inzicht in wat van invloed is op de kwaliteit van een standaard.
• ideeën voor verbetering van de standaard.
• ideeën voor aanpassingen in het standaardisatieproces.

Het helpt de standaardisatieontwikkelaar om met een frisse blik naar de standaard te kijken en daarbij een gevoel te krijgen hoe de kwaliteit te beïnvloeden is. Gedurende het gebruik zal de standaardisatieontwikkelaar ideeën ontwikkelen hoe de standaard te verbeteren is of mogelijkheden zien om het standaardisatieproces te veranderen om een hogere kwaliteit te bereiken.

In ultieme vorm is het kwaliteitsinstrument een meetinstrument (zoals een thermometer) voor standaarden, dat wil zeggen een compleet gereedschap inclusief 'tool' en 'gebruikshandleiding'. Maar ook alleen het kwaliteitsmodel, met een stevig fundament, kan als 'bril' worden gebruikt om standaarden in de praktijk mee te toetsen.

De kwaliteit van de standaard kan nog zo goed zijn, als de kwaliteit van de implementaties achterblijft wordt er ook geen interoperabiliteit bereikt. Deze sectie gaat in op mogelijke vormen certificering, compliancy testing, validatie, en andere vormen van toetsen van het toepassen van de standaard, met daarbij eventueel een beloning. Certificering hanteren we als containerbegrip voor alle vormen hiervan.

Nadat de standaard is ontwikkeld en in enige mate is geadopteerd in de markt komt nagenoeg altijd de certificeringsvraag wel boven drijven. Soms zijn het leveranciers, als early adopters van de standaard die zich graag in de markt door middel van een stempel positief willen onderscheiden (oftewel: ze willen graag return op hun investment als early adopter). En soms blijken in de praktijk implementaties niet interoperabel te zijn wat de vraag van certificering om interoperabiliteit te garanderen oproept. Deze verschillen laten al zien dat certificering verschillend ingezet kan worden om simpelweg verschillende vragen in te vullen.

Misschien wel de belangrijkste stap is het verzamelen van wensen en eisen. Dit moet zowel gebeuren bij het opstellen van een nieuwe standaard als bij het wijzigen van een bestaande standaard.

Kenmerk voor een open standaard is dat iedereen zijn of haar wensen kan indienen. Deze groep is idealiter zo groot mogelijk – dit vergroot immers het draagvlak van de standaard. Wel kan het zo zijn dat er door het bestuur van de standaardisatieorganisatie bepaalde richtingen zijn uitgezet die hiervoor een beperking vormen. Deze beperking kan bijvoorbeeld betrekking hebben op de overall functionele scope van de standaard. Er zijn verschillende mogelijkheden om wensen en eisen te verzamelen:

• Het inrichten van een omgeving (zoals een website, miro board, git repository of wiki) waar gebruikers ideeën kunnen achterlaten. Gebruikers kunnen daar ook met elkaar discussiëren over ideeën of wijzigingsvoorstellen.
• Via een formele consultatie. Hierbij wordt een formele vraag gesteld aan partijen rondom de standaard over toekomstige ontwikkelingen, wensen of eisen.
• Door het organiseren van workshops of discussiebijeenkomsten met stakeholders uit de gemeenschap. Tijdens deze bijeenkomsten kunnen lopende ontwikkelingen worden besproken. Zo kan er bijvoorbeeld een nieuwe ontwikkeling zijn bij één van de deelnemers, die ook voor anderen relevant is. Deze ontwikkeling kan dan aanleiding geven tot uitbreiding van de standaard.

Welke vorm ook gekozen wordt, of combinatie van vormen: uiteindelijk moet dit proces leiden tot een lijst met wensen en eisen die beoordeeld moet worden.

Het verzamelen van wensen en eisen is een doorlopend proces. Wel kan het soms zinvol zijn om vanuit de beheerorganisatie partijen in de gemeenschap actief te wijzen op de mogelijkheid om wensen en eisen aan te leveren.

Bij het opstellen van een nieuwe standaard kan een pressure cooker proces worden gevolgd, waarin in korte tijd met een aantal sleutelspelers de eerste aanzet voor de standaard wordt gegeven.

Niet ieder idee of wens leidt automatisch tot een veranderingsvoorstel voor de standaard. Grofweg zijn er de volgende mogelijkheden:

• Het idee is meer een vraag die specifiek is voor de implementatie bij een bepaalde partij. Bijvoorbeeld wanneer een organisatie nog weinig ervaring heeft met de standaard. In een dergelijk geval kan vanuit de gemeenschap of vanuit de beheerorganisatie mogelijke ondersteuning worden geboden bij het oplossen van het probleem. Het is dan niet nodig de standaard te wijzigen.
• Een wens of idee heeft betrekking op aanpassing of uitbreiding van de bestaande standaard. Dit kan voortkomen uit veranderde wetgeving, veranderde processen of andere veranderde behoefte.
• Het voorstel heeft betrekking tot fundamentele wijziging of uitbreiding van de standaard. Denk aan:
  • Functionele uitbreiding
  • Naast semantische standaardisatie ook op transportniveau vastleggen hoe gegevens uitgewisseld moeten worden. Bijvoorbeeld: vastleggen dat bepaalde XML/JSON-berichten enkel via REST-API mogen worden uitgewisseld.
  • Toepassing van de standaard in nieuwe sectoren.

Op een moment dat de indiener dit aangeeft dient de wens of eis opgenomen te worden als request for change of wijzigingsverzoek.

Afhankelijk van de inrichting van beheerorganisaties kan er door een secretariaat of ondersteunende experts alvast een eerste sortering worden gemaakt aan de hand van de genoemde categorieën. Ook kan er een eerste inschatting worden gemaakt van de impact van een wijzigingsvoorstel.

Door dit te laten doen door een secretariaat of ondersteunende experts kan de uiteindelijke beoordeling later vlotter verlopen. Daarbij is het wel van belang dat hierbij primair een neutrale rol wordt aangenomen door de beheerorganisatie: het is bij een open standaard uiteindelijk de standaardisatie gemeenschap die beslist. Soms kunnen er wensen of eisen zijn die buiten het operationele proces vallen en die op tactisch of strategisch niveau besluitvorming vereisen door het bestuur van de standaardisatie organisatie. Deze kunnen dan direct richting het bestuur worden doorgeleid.

Periodiek moet de lijst met requests for change/wijzigingsverzoeken worden doorlopen. Daarbij moeten de wijzigingsverzoeken worden beoordeeld en moet worden besloten of een wijziging wordt doorgevoerd in de standaard.

Werkgroepen zijn een belangrijk instrument voor het verzamelen, voorbereiden en beoordelen van wijzigingsverzoeken. Ondanks openheid kan om praktische redenen de deelname aan werkgroepen gelimiteerd zijn. Daarbij wordt vaak onderscheid gemaakt in type stakeholder, mede omdat het verstandig is dat de werkgroep een goede afspiegeling bevat van de stakeholders. NEN gebruikt hiervoor een stakeholderanalyse waarin de stakeholders worden geïdentificeerd door gebruik te maken van een generieke waardeketen. Deze zijn de volgende:

Een standaard wordt (idealiter) gebruikt door een groot aantal organisaties. De wijziging van een standaard heeft potentieel dan ook veel impact. Het kan er toe leiden dat een groot aantal systemen en processen aangepast moet worden. Behalve een bewuste keuze per wijzigingsverzoek vereist dit dat de beheerorganisatie ook nadenkt over het algemene versiebeleid.

Allereerst is het daarbij van belang vast te leggen welke soorten versies er zijn. Zo kunnen er major releases zijn die een grote wijziging omvatten, maar ook minor releases die slechts kleine aanpassingen inhouden. Voor gebruikers moet duidelijk zijn welke versie van de standaard men mag gebruiken. Mag men bijvoorbeeld tegelijkertijd twee versies gebruiken of niet?

Binnen de standaard geeft dit ook eisen op het gebied van migratie en compatibiliteit tussen versies. Soms worden er binnen de standaard voorzieningen getroffen om dit mogelijk te maken. Vaak wordt er bijvoorbeeld gekozen om standaarden tot een bepaalde versie backwards compatible te maken. Bijvoorbeeld: alle minor wijzigingen op een major versie zijn backwards compatible. Indien er een dergelijke afspraak is, is het goed dit expliciet te maken. Zodoende kunnen gebruikers van de standaard zich hier op instellen bij het maken van keuzes over de toe te passen versie.

Om gebruikers niet voor verrassingen te plaatsen is het wenselijk om te werken met een vaste cyclus van releasemomenten. Deze principes moeten op strategisch en tactisch niveau worden vastgelegd: ze zijn immers van invloed op de werking van de beheerorganisatie.

Veel organisaties kiezen er voor om maximaal één keer per jaar een grote release door te voeren, indien nodig aangevuld met een ‘minor’ release met slechts kleine wijzigingen. Denk daarbij aan correctie van kleine fouten in de specificatie, aanvulling met voorbeelden, etc.

Door deze keuze kan een duidelijke jaarplanning worden opgesteld voor het operationele proces. Bijvoorbeeld: in januari een aantal workshops beleggen, in april wijzigingsvoorstellen in de werkgroep en in juni de uiteindelijke wijzigingen vaststellen. Het tweede halfjaar kan worden benut voor het volgen van de ervaringen bij gebruikers en het helpen bij de overgang naar nieuwe versies. Eventuele correcties kunnen in een ‘minor’ release in december worden meegenomen.

Aan deze cyclus kan ook de versienummering worden gekoppeld. Uitgaande van bijvoorbeeld drie posities x, y en z (bijvoorbeeld versie 3.1.5) kan x bijvoorbeeld corresponderen met de hoofdversie (het ingeslagen ontwikkelpad), y met de major release en z met de minor release.

Tip: minimaliseer het aantal wijzigingen. Het is wenselijk het aantal wijzigingen beperkt te houden. Immers: een wijziging kan betekenen dat gebruikers van de standaard systemen of processen moeten aanpassen. Het feit dat er een maximum aantal wijzigingen per jaar is vastgelegd betekent daarmee nog niet dat er automatisch ook zoveel nieuwe versies moeten komen.

In veel gevallen is er een relatie met een andere standaard. Bijvoorbeeld een internationale standaard waarvoor een toepassingsprofiel is ontwikkeld. Naast wijzigingen vanuit de eigen community moet in een dergelijk geval ook rekening gehouden worden met wijziging van de onderliggende (internationale) standaard.

Het is van belang dit in het wijzigingsproces te onderkennen. Drie aspecten zijn daarbij met name van belang:

• Er moet afgesproken worden in hoeverre er een vaste relatie is tussen de ‘eigen’ standaard en de gerelateerde of onderliggende standaard: mag willekeurig een versie worden gebruikt? Of wordt een bepaalde versie voorgeschreven?
• Bij wijzigingen van de internationale/onderliggende standaard moet worden bepaald of dit impact heeft op eigen standaard.
• Er moet vastgelegd worden of en zo ja welke relatie er is tussen het releaseschema en versienummer van de eigen standaard en de onderliggende standaard.

In een ander deel wordt dieper ingegaan op de relatie met andere standaarden.

Een veel gehoorde opmerking is dat standaarden ontwikkelen een langzaam proces is dat jaren kan duren. Dat is er van oudsher ingeslopen, maar wie zegt dat men het oude traditionele proces van standaardisatie moet doorlopen?

Het kan duidelijker sneller: In de afvalbranche is het concept van Pressure cooker gebruikt voor het ontwikkelen van een standaard. In een week tijd is gewerkt aan het standaarden van koppelvlakken tussen verschillende systemen in de afvalbranche. Denk daarbij aan het koppelvlak tussen de mini-container en de vuilniswagen, en het koppelvlak van de vuilniswagen met de back-office van de gemeentelijke afvalverwerker.

Na een werkgroepweek, met gemiddeld 15 deelnemers van zowel de afvalverwerkers en de leveranciers, waarin de standaarden stuk voor stuk zijn doorlopen, volgt twee weken van uitwerking door een externe begeleider, en vervolgens een twee weken review periode door de werkgroep voordat de standaard is opgeleverd aan de stuurgroep. Geteld vanaf de start van de werkgroep ligt er dan binnen 2 maanden een standaard.

Het gevaar bestaat dat dit ten koste gaat van de kwaliteit: een slechte standaard zou veel ellende voor de toekomst kunnen opleveren. De kwaliteit van de standaard is sterk gerelateerd aan de deelnemers in de pressure cooker. Een opmerkelijk verschijnsel is dat werkgroepleden ter plekke contacten gaan leggen binnen hun eigen organisatie om extra informatie te vergaren. Daaraan gerelateerd is ook direct de achilleshiel: indien een werkgroeplid zich niet voldoende heeft voorbereid en bijvoorbeeld de noodzakelijk informatie ter plekke mist, dan kan deze informatie niet meegenomen worden in de pressure cooker. De kwaliteit en voorbereiding van de werkgroepleden zijn daarmee van groot belang.

Een belangrijke eerste graadmeter is het reviewproces; Mocht tijdens het reviewproces veel fundamentele keuzes opnieuw ter discussie worden gesteld en ook leiden tot wijzigingen in de beoogde standaard dan is dat geen positieve indicatie voor de kwaliteit. Overigens een eerste versie van een standaard is nooit perfect. Tijdens implementaties worden altijd nieuwe inzichten ontdekt en regelmatig fouten ongeacht het gebruik van een pressure cooker. Een perfecte standaard is ook niet het doel: een werkbare standaard die helpt het probleem op te lossen daarentegen wel.

De leerpunten: Belangrijke leerpunten zijn:

• Een pressure cooker is een prima middel om efficiënt een standaard te ontwikkelen. De kwaliteit moet zich nog bewijzen, maar de indruk is ontstaan dat de werkgroep bepalend is in de kwaliteit van de standaard.
• Duidelijke scope; wat in standaardisatie-kringen bekend staat als “scope-creep” (verschuivende scope) ligt sterker op de loer in een pressure cooker.
• Niet te lang en te veel willen: Meer ervaringen zijn nodig om het optimum aan lengte en inhoud te kunnen bepalen, maar er is zeker sprake dat er een optimum is; op een gegeven moment is de magie uitgewerkt.

Het gebruik van de pressure cooker wordt in standaardisatie-land nog niet veel gebruikt, hoewel het idee wel afkomstig is van internationale standaardisatie-bijeenkomsten waarin de werkgroepleden zich ook soms ook een aantal dagen buigen over een standaard. Met een ‘pressure cooker’ kan hiermee de lengte van het standaardisatie-proces flink worden bekort. Daarnaast kan de ontwikkeling van standaarden hierdoor ook efficiënter – en dus: goedkoper - worden, en dat is natuurlijk mooi meegenomen.

Er is een breder keuze aan digitale applicaties die gebruikt kunnen worden voor standaarden beheer, al zijn ze hier niet altijd voor bedoeld. Samenwerkingsapplicaties voor documentbeheer of softwareontwikkeling kunnen worden toegepast om beheerders en betrokkenen toegang te geven tot documentatie of zelfs om gebruikers de documentatie bij te laten werken.

Een voorbeeld is het gebruik van Git en Respec voor het operationeel beheer. Git is een applicatie voor wijzigingsbeheer bij softwareontwikkeling. Iedere wijziging wordt opgeslagen in een database nadat het door de auteur voorzien is van commentaar. Hierdoor kunnen versies van verschillende tijdstippen vergeleken worden en kan de verantwoording nagelezen worden. Daarnaast is er ondersteuning voor parallellopende versies waardoor er bijvoorbeeld gewerkt kan worden aan een ingrijpende wijziging zonder dat onderhoud aan de huidige werkversie verstoord wordt. Er is een aantal webomgevingen voor samenwerking aan code die gebruik maken van git zoals Github, Gitlab en Gitea. Een gebruiker kan ook zelf op basis van de beschikbare Git open source software een Git omgeving maken en daarmee onafhankelijk blijven van de grote Git platforms. De Git platforms zoals Github en Gitlab bieden hostingopties en een webinterface voor het doorvoeren en inzien van wijzigingen naast ondersteuning voor lokaal geïnstalleerde git-applicaties.

Respec is een applicatie om bestanden om te zetten in documentatie die online gepubliceerd kan worden. Het beheer van specificaties verloopt steeds vaker via een automatisch proces. Waar het in het verleden nog gebruikelijk was om losse documenten te delen binnen werkgroepen, stappen steeds meer beheerorganisaties over naar (git) repositories om teksten in te beheren. Hoewel deze omgevingen van oorsprong bedoeld zijn om programma code in te beheren, zijn deze ook goed bruikbaar voor het beheer van ‘leesbare’ tekst. Door gebruik van een responsive layout kan de documentatie onafhankelijk van schermgrootte leesbaar getoond worden. Respec maakt automatisch een inhoudsopgave waarmee een gebruiker snel door de documentatie kan browsen. Respec is specifiek bedoeld voor technische documentatie en het sluit goed aan bij applicaties voor softwareontwikkeling zoals Git.