Handboek Beheer en Onderhoud Aquo-standaard

Handboek IDsW

Deel 1: Beheer en ontwikkeling Aquo-standaard

Auteur: IDsW

Datum: 30 augustus 2010

Versie: 3.0

Rapport: Beheer en ontwikkeling Aquo-standaard Datum: 30 augustus 2010 Versie: 3.0

pagina 2 van 63 Documentbeheer

Documentbeheer

Wijzigingshistorie

Datum Versie Auteur Wijziging 25 nov 03 Concept versie 1 Werner Gerritsen Start document 21 jan-04 Definitief versie 1 Werner Gerritsen Wijzigingen na regiegroepvergadering en

overleg met servicedesk 22-jun-05 Concept versie 2 Huibert-Jan Lekkerkerk Complete herziening nav ervaringen aug. 2006 Concept versie 2

(0.91) Hinne Reitsma Wijzigings-/versiebeheer nav IDsW-sessie

feb. 2007 Concept versie 2 (0.94)

Hinne Reitsma Toegevoegd: SLA onderdelen bij procedure Vragen&Verzoeken en Wijzigingsvoorstellen.

nov. 2007 Definitief versie 2 Jacolien Eijer Updatecycli aangepast, grote updates in een jaarlijkse cyclus

Aug 2010 Definitie versie 3.0.0

Huibert-Jan Lekkerkerk Procedures geactualiseerd en aangepast aan open standaard regime

Review

Datum Versie Reviewer Functie

Controle en vrijgave

Datum Versie Controleur Functie Versie 2 Jacolien Eijer Programmamanager Versie 3 Myriam de Jong Programmamanager

Literatuurbronnen

1. ITSMF, Ruijs, L.J. en Van de Waerdt, F., “Service Management E-mail Questionnaire 2001”, Amersfoort, 2001

2. http://www.itservicecmm.org

3. Verslagen en besluitenlijsten werkoverleg IDsW, 1 sept. 2005 t/m 13 februari 2006

4. NOiV, “Beheer en Ontwikkel Model Open Standaarden (BOMOS)”, 2009

5. College Standaardisatie, “Expertadvies Aquo als Open standaard”, 2009

6. Twijnstra en Gudde, “Aquo-keurmerk”, 2009


InhoudsopgaveInleiding pagina 3 van 63

Inhoudsopgave

1. Inleiding 4

1.1 Achtergrond ............................................................. 4 1.2 Doel handboek .......................................................... 4 1.3 Afkortingen .............................................................. 4

2. Aquo en IDsW 6

2.1 Effectieve informatie-uitwisseling .................................. 6 2.2 Aquo – de gegevensstandaard ........................................ 7

2.2.1 Semantische standaard............................................................7 2.2.2 Onderdelen ..........................................................................8

2.3 InformatieDesk standaarden Water – de organisatie............10 2.3.1 Historie............................................................................. 10 2.3.2 Overzicht........................................................................... 10 2.3.3 Stuurgroep (SG)................................................................... 11 2.3.4 Gebruikers, Adviesraad (AR) en Regiegroep (RG)........................... 11 2.3.5 Programmabureau IDsW......................................................... 14 2.3.6 De ‘buitenwereld’ / het netwerk.............................................. 15

2.4 Relatie met BOMOS en Nederlandse Open Standaard ..........16 2.4.1 Inleiding............................................................................ 16 2.4.2 Vergelijking BOMOS en beheer Aquo-standaard ............................ 19 2.4.3 Vergelijking Model van Krechmer en beheer Aquo-standaard............ 22 2.4.4 Aquo als Nederlandse Open Standaard ....................................... 26

3. Procedures voor beheer en onderhoud 29

3.1 Introductie procedures ...............................................29 3.1.1 Termen en definities ............................................................ 29

3.2 Procedure: Behandeling van verzoeken ..........................31 3.2.1 Beschrijving procedurestappen ................................................ 31 3.2.2 Verantwoordelijkheden, rollen en taken..................................... 32 3.2.3 Service Level Agreement........................................................ 33

3.3 Procedure: Behandeling verzoek nieuw (standaard)product .35 3.3.1 Beschrijving procedurestappen ................................................ 35 3.3.2 Verantwoordelijkheden, rollen en taken..................................... 37

3.4 Procedure: Behandeling verzoek nieuw project ................38 3.4.1 Beschrijving procedurestappen ................................................ 38 3.4.2 Verantwoordelijkheden, rollen en taken..................................... 40

3.5 Procedure: Behandeling wijzigingsvoorstel ......................41 3.5.1 Schema verwerken van een wijzigingsvoorstel ............................. 42 3.5.2 Beschrijving procedurestappen ................................................ 42 3.5.3 Verantwoordelijkheden, rollen en taken..................................... 44 3.5.4 Performancecriteria ............................................................. 45

3.6 Procedure: Aquo update .............................................47


pagina 4 van 63 Inleiding

1. Inleiding

1.1 Achtergrond

In de watersector vindt gegevensuitwisseling tussen verschillende organisaties veelvuldig plaats. De kwaliteit van deze informatiestromen verbetert door een juiste toepassing van standaarden. Bovendien zorgt standaardisatie voor een beperking van de kosten van de informatiestromen. Om die reden hebben vijf waterbeherende partijen de InformatieDesk standaarden Water (IDsW) opgericht.

IDsW draagt zorg voor het beheer van de Aquo-standaard, de gegevensstandaard voor de sector water. IDsW ontwikkelt de Aquo-standaard tot een zo algemeen mogelijk geldende standaard die bruikbaar is voor alle partijen binnen de watersector en tevens aansluit bij andere (inter)nationale ontwikkelingen. De Aquo-standaard is als open standaard beschikbaar voor iedereen die te maken heeft met het vastleggen en gebruiken van gegevens in het waterbeheer.

IDsW adviseert en communiceert over het gebruik van standaarden en nieuwe ontwikkelingen. Daarmee is de netwerkorganisatie IDsW de spin in het web van standaarden in de sector water. IDsW is daarbij onafhankelijk.

1.2 Doel handboek

Dit handboek bevat de beschrijving van de werkprocessen voor het beheer en onderhoud van de Aquo-standaard. Dit om aan alle belanghebbenden van de Aquo-standaard duidelijk te maken hoe de processen verlopen en op welke wijze hun belangen zijn geborgd. Een belangrijk basis bij deze werkprocessen is de structuur van IDsW-organisatie.

1.3 Afkortingen

AR Adviesraad

ASL Application Services Library

BiSL Business Information Services Library

BOMOS Beheer en Ontwikkel Model Open Standaarden

CAB Change Advisory Board

HWH Het Waterschapshuis

IDsW InformatieDesk standaarden Water

IHW Informatiehuis Water

IMWA Informatie Model WAter

IPO Interprovinciaal Overleg

ITIL Information Technology Infrastructure Library

KRW Kaderrichtlijn Water

LMA Logisch Model Aquo

LNV Ministerie van Landbouw Natuur en Voedselkwaliteit


Inleiding pagina 5 van 63

PBL Planbureau voor de Leefomgeving

RfC Request for Change (Wijzigingsvoorstel)

RG Regiegroep

RWS Rijkswaterstaat

SG Stuurgroep

TCN Taxon Code Nederland

UMA Uitwissel Model Aquo

UvW Unie van Waterschappen

WG Werkgroep


pagina 6 van 63 Aquo en IDsW

2. Aquo en IDsW

2.1 Effectieve informatie-uitwisseling

De InformatieDesk standaarden water heeft als missie: voor effectieve informatie-uitwisseling tussen waterbeheerders.

De werkzaamheden van IDsW zijn daarom o.a. gericht op het ontwikkelen en beheren van de semantische standaardisatie voor het Nederlandse waterbeheer, met als doel het bevorderen van de interoperabiliteit. Met het gebruik van de Aquo-standaard zal de kwaliteit van informatiestromen en de kostenefficiëntie in de watersector sterk verbeteren.

Toelichting: Er kunnen 3 soorten interoperabiliteit onderscheiden worden: 1. Semantische interoperabiliteit, gericht op het standaardiseren van de betekenis van

gegevens, waaronder het opstellen van uitwisselmodellen voor gegevens en de methodieken voor het inwinnen van de gegevens. Dit laatste behoort nog niet tot de core business van IDsW. Recent is hier wel een eerste aanzet voor gemaakt met een inventarisatie van methodieken voor het inwinnen van gegevens.

2. Technische interoperabiliteit, gericht op het standaardiseren van applicaties en toegepaste techniek. Deze vorm van standaardisatie behoort niet tot het werkveld van IDsW. Voor het IHW is dat wel voorzien .

3. Organisatorische interoperabiliteit, gericht op partijen en werkprocessen. De richtlijn monitoring KRW (zie schema hieronder) is mede gericht op deze vorm van standaardisatie.

Standaardisatie is niets anders dan het documenteren van erkende afspraken, specificaties of criteria. IDsW adviseert en informeert iedereen die te maken heeft met het vastleggen en gebruiken van gegevens in het waterbeheer over het gebruik van standaarden en nieuwe ontwikkelingen.

Kernactiviteiten - Beheren en ontwikkelen semantische standaarden - Zorgen voor afstemming tussen de waterdata en data van andere werkvelden (operationeel)

- Participatie in overleg m.b.t. standaardisatieproces met/binnen andere werkvelden (tactisch)

- Participeren in afstemming tussen datastandaard en diverse applicaties (uitwisselmodellen)

Thema’s - Waterkwaliteit (o.a. KRW) - Waterkwantiteit - Waterketen: Drinkwater, Rioleringsbeheer en Zuiveringsbeheer - Asset management: Waterkeringbeheer, Groenbeheer, Vaarwegbeheer, Vastgoedbeheer

- Vergunningverlening en handhaving - Grondwater - Monitoring - Waterveiligheid / Overstromingsrisico’s (Calamiteitenzorg) - Voornamelijk binnenwater (zoet), zout waar het de kuststrook betreft

Focus - Inhoudelijk en tactisch

Vanuit de missie en visie zijn de volgende uitgangspunten voor de IDsW organisatie neergezet:


Aquo en IDsW pagina 7 van 63

• Autoriteit op het gebied van standaardisatie • Klantvriendelijke organisatie; klant staat centraal. • Transparant werken conform de eisen gesteld aan een (Nederlandse) Open Standaard • Het werkingsgebied van IDsW is ‘G2G – Government to government’ ofwel de (semi)

publieke sector. Daarbij wordt uiteraard de markt niet uit het oog verloren. De volgende doelen zijn voor IDsW en de Aquo-standaard afgeleid uit de missie:

• waterinformatie baseren op sectorbrede basisgegevens • elkaars taal kunnen verstaan en watergegevens kunnen lezen • gegevenskwaliteit en directe bruikbaarheid kunnen garanderen • waterinformatie waterketen breed op één punt kunnen vinden en bieden • waterinformatie eenduidig en tijdig laten rouleren • waterinformatie betekenisvol kunnen gebruiken • waterinformatie vergelijkbaar verantwoord kunnen presenteren.

2.2 Aquo – de gegevensstandaard

2.2.1 Semantische standaard

Standaarden zijn er in verschillende soorten en maten. De standaarden waarvoor het meest noodzakelijk is om een Nederlandse community te hebben zijn semantisch van aard. Vaak is het in de context van Nederlandse wetgeving en/of Nederlandse specifieke bedrijfs(overheids)processen noodzakelijk om internationale standaarden toe te spitsen op de Nederlandse situatie. Regelmatig wordt ook de term bedrijfstransactie standaarden (Business Transaction Standards) hiervoor gebruikt, wat een goede indruk geeft maar in principe vocabulaires (waardelijstjes) of documenten als standaard uitsluit omdat dit geen transacties betreft.

Kenmerken van deze semantische standaarden:

• Zijn vaak een specifieke invulling van een internationale standaard • Zijn vaak specifiek voor een specifiek inhoudelijk probleem. (bijvoorbeeld voor een

bepaalde sector / thema) • Worden vaak ontwikkeld en beheerd in het domein, en niet door formele

standaardisatieorganisaties. • De kern van de standaard is de semantiek (de betekenis), niet de techniek.

Onze gegevensstandaard Aquo is een semantische standaard, dus een standaard waarin betekenissen zijn vastgelegd. Ook de methode om gegevens te registreren en dus uitwisselbaar te maken is daarin opgenomen.

Aquo bevat standaarden voor:



• definitie van termen en begrippen • gegevensinwinning • gegevensopslag / gegevens uitwisseling • verwerking van gegevens / rapportage

2.2.2 Onderdelen

De Aquo-standaard bestaat op hoofdlijnen uit de volgende onderdelen:

1. Aquo-lex: Het waterwoordenboek Aquo-lex voorkomt spraakverwarringen. Het geeft eenduidige definities voor termen of begrippen (ca 8.000) die gebruikt worden in het waterbeheer;

2. De informatiemodellen IM water, UM Aquo en LM Aquo, die dienen ter structurering opslag en uitwisseling van informatie; Dit zijn beschrijvingen van objecten (entiteiten / klassen) met hun kenmerken (attributen) en de relaties daartussen.

3. De Aquo-domeintabellen (550 stuks). Domeintabellen zijn lijsten met toegestane waarden voor een bepaald attribuut in een informatiesysteem. Hierin zijn o.a. alle parameters zijn opgenomen die in het waterbeheer gemeten worden. Daarnaast bevatten de domeintabellen o.a. classificaties van objecten (bruggen, sluizen e.d.), watertypen, onderdelen van zuiveringen.

4. Methodieken (standaard werkwijzen voor meting, monstername, labanalyse, bewerking of verwerking van data, toetsing, integratie en systeemanalyse.

Figuur: overzicht van onderdelen van de standaard, externe invloed en de onderlinge afhankelijkheid

Naast de Aquo-standaard kent IDsW verder nog een aantal specifieke producten die helpen bij de toepassing van Aquo zoals technische richtlijnen, mapping tussen onderdelen van de standaarden etc., dit zijn:

Beschouwd naar het algemene werkproces voor het realiseren van een informatieproduct ziet dit er als volgt uit (zie de bijlage voor een meer gedetailleerde beschrijving):



Op basis van behoeften van de gebruikers van de Aquo-standaard is/wordt voor een aantal werkvelden zogenaamde Aquo-parameterlijsten gemaakt: o.a. voor Grondwater, Bodem/Sediment, Zwemwater, Drinkwater. Tussen de parameterlijsten en weten regelgeving bestaat een duidelijke relatie, zoals blijkt uit onderstaande figuur.

Aquo-parameterlijsten

Aquo- Domeintabellen

Wet- en regelgeving

Beleid

Referentiedocumenten:

Handboek, Leidraad Protocol, Richtlijn,

Methodiek etc. uitgewerkt in

vastgesteld door MRE:

verwijst naar

vastgesteld door regering

parameters opgenomen in

bron voor



2.3 InformatieDesk standaarden Water – de organisatie

IDsW is een relatief platte organisatie met sterke focus op het operationele niveau. Aansturing vindt voornamelijk plaats via de gebruikersvertegenwoordiging in de Regiegroep en Adviesraad.

2.3.1 Historie

De InformatieDesk standaarden Water (IDsW) is opgericht in 2003 door vijf waterbeherende overheden die het stroomlijnen van de informatievoorziening in de watersector hoog op de agenda hadden en hebben. De vijf oprichtende overheden zijn:

• Unie van Waterschappen (UvW); inmiddels is deze taak gedelegeerd aan Het Waterschapshuis (HWH)

• Rijkswaterstaat (RWS) • Interprovinciaal Overleg (IPO) • Planbureau voor de Leefomgeving (PBL), voorheen Milieu en Natuur Planbureau (MNP) • Ministerie van LNV (LNV)

Het programmabureau is sinds 2003 gehuisvest in Lelystad bij de RWS-Waterdienst (voorheen RWS RIZA). Per 1 januari 2011 gaat IDsW op in het InformatieHuis Water (IHW). Dit zal worden gefaciliteerd door Het Waterschapshuis (HWH) te Amersfoort

2.3.2 Overzicht

In de manier van werken kan op hoofdlijnen een opdrachtnemer en een opdrachtgever worden onderscheiden. De gebruiker van de Aquo-standaard kan als klant / opdrachtgever worden beschouwd. De Aquo-standaard wordt beheerd door de opdrachtnemer, de IDsW organisatie. Deze bestaat uit adviesraad/regiegroep, programmabureau en stuurgroep.

Gebruiker

Adviesraad

Regiegroep Programma-

bureau IDsW

Stuurgroep IDsW

Aquo-standaard

Vraag

Antwoord

Gebruikt Beheert

Adviseert Beslist

Tactisch overleg

Operationeel overleg S

ervi

cede

sk Vraag

Antwoord

Besluit

Beheer

Programmabureau IDsW

Organisatie structuur IDsW organisatie

In de organisatiestructuur onderscheiden we:

• Gebruiker. Dit is de (eind) gebruiker van de Aquo-standaard.



• Adviesraad. Een bijeenkomst van alle betrokkenen (medewerkers van overheden en leveranciers) bij de producten van de Informatiedesk standaarden Water. Zij representeert de klant van IDsW. Het programmabureau kan advies vragen bij de adviesraad.

• Regiegroep. Dagelijks bestuur van de adviesraad. De stuurgroep en het programmabureau worden gevraagd en ongevraagd geadviseerd door de adviesraad via de regiegroep.

• Stuurgroep. Bestuursorgaan samengesteld uit vertegenwoordigers van de participerende koepels en verantwoordelijk voor de inzet van mensen en middelen in het programmabureau. De stuurgroep stelt het werkplan van het bureau vast.

• Programmabureau. De medewerkers van IDsW, verantwoordelijk voor het beheer van de standaard en de uitvoering van het werkplan in opdracht van de stuurgroep. Binnen het programma bureau wordt verder nog onderscheid gemaakt tussen de Servicedesk, het Tactisch Overleg en het Operationeel Overleg als groepen.

2.3.3 Stuurgroep (SG)

De stuurgroep bestaat uit de vijf overheidspartners die gezamenlijk de eigenaar zijn van IDsW aangevuld met adviserende leden vanuit de huisvestende organisatie, de voorzitter van de regiegroep en de progamma manager IDsW. Het secretariaat wordt verzorgd door het programmabureau.

De stuurgroep heeft de volgende taken:

• De partners brengen het geld bijeen waarmee het programmabureau voor enkele jaren de IDsW gegevensstandaard kan beheren.

• Ontwikkelen en implementeren van beleid en condities voor efficiënte en betrouwbare uitwisseling van informatie om de informatievoorziening te stroomlijnen;

• Verbinden van waterbeleid en informatiebeleid, signaleren van ontwikkelingen in het waterbeleid en deze vertalen naar consequenties voor de informatievoorziening;

• Vaststellen van het jaarlijkse werkplan van het programmabureau. • Vaststellen van de begroting en controle van de uitgaven van IDsW; • Uitoefenen van netwerkfunctie richting partijen, gebruikers en belanghebbenden. • Beslissen over fundamentele vragen en grote wijzigingsverzoeken. Zij mandateert

hiervoor al dan niet de regiegroep. • Beslissen tot goedkeuring standaarden • Vertegenwoordigen van IDsW binnen de eigen organisatie • Benoemen leden regiegroep en programma manager IDsW

De stuurgroep vergadert tenminste vier keer per jaar.

2.3.4 Gebruikers, Adviesraad (AR) en Regiegroep (RG)

Gebruikers

De gebruikers van de Aquo-standaard zijn in drie hoofdgroepen in te delen:

• (ICT) Beleidsmedewerkers / projectleider / management. Het gaat hierbij om de strategisch / tactisch gebruik van de standaard. Voordelen zijn dat wat al verzonnen is niet opnieuw verzonnen hoeft te worden; ontwikkeling kan sneller plaats vinden; communicatie met de buitenwereld (en gebruik van gegevens van anderen) kan met lagere kosten en grotere efficiëntie.



� Opstellen ICT beleid � Opdrachtverstrekking bouw / aanpassing informatiesysteem � Selectie leverancier die met Aquo werkt � Begripsdefinitie in generiek beleid

• Ontwikkelaars; software architecten; Informatie analisten en andere ICT deskundigen. Bied een raamwerk voor de manier van gegevens opslag en uitwisseling; aansluiting op andere informatie systemen wordt eenvoudiger en bied daardoor nieuwe marktkansen.

� Bouw of aanpassing informatiesysteem � Beheer van gegevens � Configuratie marktpakket

• (Eind) gebruikers van informatie. Informatie wordt door iedereen op dezelfde manier opgeslagen waardoor het makkelijker wordt om gegevens van anderen te gebruiken zonder uitgebreide onderzoeken. Informatie analyse uitbesteden aan de markt wordt eenvoudiger door vaste definities bij de verschillende organisaties.

� informatie inwinnen en bewerken � Uitwisselen van data met anderen � Gebruik van gegevens voor integratie /aggregatie / rapportage

Rol van de gebruiker ten opzichte van de Aquo-standaard / IDsW:

• Toepassen Aquo in werkproces • Collega (organisaties) attenderen op nut en noodzaak standaardisatie • Inbreng tijdens gebruikersbijeenkomsten • Signaleren nieuwe ontwikkelingen • Indienen wijzigingsvoorstellen • Reageren op ingediende wijzigingsvoorstellen • Inzet van expertise tbv Werkgroepen en Change Advisory Boards.

Adviesraad

De adviesraad is een belangrijk forum voor het signaleren van ontwikkelingen op het gebied van standaardisatie en voor de uitwisseling van ervaringen en wensen rondom Aquo. In de adviesraad zijn de gebruikers verenigd. De stuurgroep en de programmamanager IDsW laten zich gevraagd en ongevraagd adviseren door de adviesraad. De adviesraad bestaat uit vertegenwoordigers van participanten en koepelorganisaties, en belangstellende marktpartijen. Via de adviesraad worden de activiteiten en projecten van IDsW besproken, evenals de wensen en ervaringen van klanten en participanten.

De adviesraad komt minimaal één keer per jaar bijeen. De samenstelling van de adviesraad is niet vast; alle belangstellenden zijn vrij om deel te nemen. De adviesraadbijeenkomsten worden aangekondigd op de website en nieuwsbrief van IDsW en via email worden deelnemers van voorgaande jaren uitgenodigd. Presentaties en verslagen van adviesraadbijeenkomsten zijn te downloaden vanaf de website.

Voor het huishoudelijk reglement van de Adviesraad zie bijlage Huishoudelijk Reglement Regiegroep en Adviesraad IDsW.



Regiegroep

Het dagelijks bestuur van de adviesraad wordt gevormd door de regiegroep. De adviesraad benoemt uit haar midden de leden van de regiegroep. In de regiegroep zijn vanuit de verschillende partners deskundigen aanwezig met zicht op zowel de operationele zijde van standaardisatie als de meer tactische kant. Naast leden vanuit de partners kent de regiegroep ook adviserende leden zonder stemrecht. Zij worden benoemd vanuit hun inhoudelijke kennis. Tot slot neemt één van de projectleiders en/of de programmamanager deel aan de regiegroep. Het secretariaat wordt verzorgd door het programmabureau.

De regiegroep organiseert adviesraadbijeenkomsten en zorgt ervoor dat de adviezen van gebruikers -al dan niet binnengekomen via de adviesraad- gebundeld bij de stuurgroep worden ingebracht. De regiegroep bespreekt inhoudelijke thema’s en agendeert deze op adviesraadbijeenkomsten. De regiegroep is een ingang voor gebruikers tot IDsW.

Taken van de regiegroep zijn:

• Organiseren adviesraad bijeenkomsten • Gevraagd en ongevraagd adviseren van de stuurgroep over nieuwe ontwikkelingen en

wijzigingsvoorstellen. Deze adviezen kunnen voortkomen uit de adviesraad. • Advisering van de stuurgroep over het werkplan IDsW • Prioriteren van uitwerking van behoeften • Beoordelen project ideeën • (Laten) instellen van werkgroepen en Change Advisory boards door het programma

bureau.

Adviesraad

Regiegroep

WG CAB

Programmabureau

Stelt in

Verzoek

Stuurgroep

Adviseert

Organisatiestructuur Adviesraad - Regiegroep

Voor het huishoudelijk reglement van de Regiegroep IDsW zie bijlage Huishoudelijk Reglement Regiegroep en Adviesraad IDsW.

Change Advisory Boards

Een Change Advisory Board (CAB) heeft tot taak wijzigingsvoorstellen (Requests for Change – RfC’s) op de Aquo-standaard te beoordelen. CAB’s worden ingericht als daartoe vanuit het wijzigingsproces de noodzaak bestaat doordat er bijvoorbeeld tegenstrijdige commentaren op een wijzigingsvoorstel komen. Een CAB bestaat uit een:

• voorzitter • secretaris • Inhoudelijke deskundigen ten aanzien van het onderwerp van het RfC



• Inhoudelijke deskundigen op het gebied van het betreffende onderdeel van de standaard.

Tenminste één van bovenstaande taken wordt vervuld door een medewerker van het programmabureau. Het reglement van een CAB is opgenomen als bijlage Reglement Change Advisory Board.

Werkgroepen

Een werkgroep onderzoekt (eenmalig) onderwerpen die een grote impact hebben op de werkwijze van waterbeheerders en hun standaarden. In een werkgroep zit een groep betrokken gebruikers en adviseurs uit het bedrijfsleven (al dan niet ingehuurd) die per onderwerp bijeenkomen (projectmatig).

Zij werken nieuwe ontwikkelingen rondom de standaard uit tot adviezen aan de regiegroep. Dit advies kan leiden tot een wijzigingsvoorstel welke aan een CAB wordt doorgegeven. Een werkgroep bestaat uit deskundigen op het gebied van de ontwikkeling; deelnemers nemen vanuit hun eigen deskundigheid plaats in de werkgroep en niet vanuit een organisatiebelang. Alle gebruikers kunnen zich aanmelden voor deelname in een werkgroep; de selectie van leden vind plaats door de regiegroep op voorspraak van het programmabureau.

Tenminste één van de taken van voorzitter of secretaris wordt vervuld door een medewerker van het programmabureau. Voor het reglement van een werkgroep zie bijlage Reglement Werkgroep.

2.3.5 Programmabureau IDsW

Het programmabureau is verantwoordelijk voor de uitvoering van het beheer en onderhoud van de Aquo-standaard. Hierbij is het programmabureau faciliterend in het proces; dat wil zeggen dat er op basis van extern gesignaleerde behoeften (via inkomende vragen, adviesraad, regiegroep, stuurgroep e.d.) wordt gezorgd voor het inpassen van deze behoefte binnen de standaard. Daarbij wordt expliciet gebruik gemaakt van kennis van de partners en overige gebruikers.

De taken van het programmabureau zijn als volgt:

• Beheer en onderhoud van de Aquo-standaard middels het uitvoeren van het werkplan en het behandelen van wijzigingsverzoeken en andere vragen

• Servicedesk / Wegwijsfunctie • Kennisfunctie / kenniscentrum standaarden • Ondersteuning bij de toepassing van standaarden • Afstemming met andere (standaardisatie) organisaties

Het programmabureau rapporteert en legt verantwoording af aan de stuurgroep. In het programmabureau zijn de volgende functies (inclusief korte beschrijving) opgenomen:

• Programmamanager o Dagelijkse leiding programmabureau (HRM, Finance, Planning & control) o Afstemming met faciliterende organisatie o Bepalen strategie IDsW ism stuurgroep o Opstellen jaarplan ism projectleider standaarden, regiegroep en stuurgroep o Adviserend lid van de diverse overleggen

• Projectleider standaarden o Leiding geven aan beheer en ontwikkeling standaarden



o Uitbesteding werkzaamheden en aansturing opdrachtnemers o Tactische planning standaarden; aansturen operationele uitvoering o Coördineren en initiëren samenwerking met partners o Kennisnemen van ontwikkelingen en onderhouden relaties

• Specialist standaarden o Innemen en registreren vragen en wijzigingsverzoeken o Dagelijks beheer en onderhoud standaard o Inhoudelijke / technische kennis standaard

• Communicatie adviseur o Communicatiebeleid (ism programma manager) o Zorgdragen voor brede bekendheid IDsW o Kennis management o Communicatie uitingen (website, nieuwsbrief etc)

• Officemanager o Secretariële ondersteuning o Logistieke organisatie vergaderingen etc o Ondersteuning programma manager bij planning & control

Binnen het programmabureau IDsW vindt een aantal structurele overleggen plaats waarbinnen de afstemming van zaken rondom organisatie / standaard plaatsvindt. Ieder overleg heeft zijn eigen aandachtsgebied en specifieke deelnemers. Het gaat daarbij om de volgende overleggen:

• Werkoverleg plenair. Hierbij worden die zaken behandeld die het programmabureau als geheel aangaan en worden de verschillende werkzaamheden organisatorisch op elkaar afgestemd. Deelnemers zijn alle medewerkers programma bureau inclusief eventuele inhuur, voor zover relevant.

• Tactisch overleg. In dit overleg worden de regiegroep en stuurgroep vergaderingen voorbereid. In dit overleg vindt tevens de afstemming over werkplannen plaats. Deelnemers zijn programmamanager en projectleiders, eventueel aangevuld met de voorzitter van de regiegroep, indien relevant.

• Operationeel overleg. In dit overleg worden inkomende verzoeken beoordeeld voor zover deze buiten de ‘reguliere’ verzoeken vallen. Het gaat in de regel om zogenaamde tweede-lijnsvragen waarbij aanvullende expertise noodzakelijk is. In dit overleg wordt het inhoudelijk beleid rondom het beheer van de standaard voorbereid. Deelnemers zijn de projectleiders en specialisten, indien nodig aangevuld met de programma manager.

• Communicatie overleg plenair. Tijdens dit overleg wordt het communicatie beleid afgestemd. Deelnemers zijn alle medewerkers programma bureau.

2.3.6 De ‘buitenwereld’ / het netwerk

IDsW bevindt zich in een zeer divers speelveld, variërend van beleid tot uitvoering en van overheid tot non-overheid. Een semantische standaard staat nooit op zichzelf en heeft vaak meerdere relaties met andere (inter)nationale standaarden, waaronder ook technische standaarden. Een belangrijke taak is afstemming blijven houden met de ontwikkel en beheerorganisaties van deze internationale standaarden.

De Aquo-standaard raakt standaarden uit andere sectoren en instanties. IDsW participeert om meerdere redenen in een breed netwerk:

• om de diverse parameterlijsten goed uit te kunnen werken; • om optimaal aan te kunnen sluiten bij gebruikersbehoeften (die op hun beurt veelal

weer voortkomen uit wettelijke verplichtingen); • om te zorgen voor een adequate afstemming op applicaties;



• om ervoor te zorgen dat de Aquo-standaard ook zo veel mogelijk wordt gebruikt door andere werkvelden, als het gaat om waterdata.

• om deskundigheid over standaarden en standaardisatie in te brengen

IDsW zorgt zo voor afstemming en werkt samen met andere partijen aan het verbeteren van informatie-uitwisseling. Een greep uit het netwerk:

2.4 Relatie met BOMOS1 en Nederlandse Open Standaard

Eén van de doelstellingen van IDsW is om de Aquo-standaard als (Nederlandse) Open Standaard neer te zetten. Om dat te bereiken is de IDsW organisatie ingericht conform het Beheer- en Ontwikkelmodel voor Open Standaarden (BOMOS). Daarnaast is de IDsW standaard getoetst (inclusief het beheer) door het college- en forum standaardisatie op de aspecten die voor een standaard op de ‘pas toe of leg uit’ lijst horen. In deze paragraaf wordt de invulling van IDsW en de Aquo standaard in deze twee nationale kaders beschreven.

2.4.1 Inleiding

BOMOS staat voor Beheer- en OntwikkelModel voor Open Standaarden (BOMOS) en is een hulpmiddel om de ontwikkeling en beheer van standaarden beter vorm te geven. Het BOMOS model beschrijft het takenpakket en de bijbehorende manier van organiseren en uitvoeren van het standaardisatiewerk. Het model is gebaseerd op de wereldwijde BiSL-standaard.

1 Ref NOiV Beheer en Ontwikkel Model voor Open Standaarden (BOMOS)



Figuur: BOMOS-model In het figuur zijn de drie traditionele lagen herkenbaar: strategie, tactiek en operationeel. Deze worden geflankeerd door twee ondersteunende processen: communicatie en implementatieondersteuning. Het geheel wordt verbonden door de taak besluitvorming. Voor alle taken geldt dat deze in een ‘minimum’ en ‘maximum’ scenario kunnen worden uitgevoerd of wellicht niet relevant zijn voor een bepaalde organisatie. In het model wordt slechts beschreven welke taken 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 taak gegeven. Het model kan de suggestie wekken dat de taken geïsoleerd zijn aangezien er geen relaties zijn aangegeven. Echter het tegendeel is waar; veel taken zijn gerelateerd zowel taken binnen een hoofdgroep als tussen de hoofdgroepen. Afstemming tussen taken is dan ook essentieel.

Het model zegt niets over de organisatievorm of indeling daarvan van een beheerorganisatie. In de praktijk kunnen meerdere taken belegd zijn bij een enkel organisatieonderdeel of kunnen meerdere organisatieonderdelen zich bezig houden met een enkele taak.



Model van Krechmer

Het BOMOS model bevat ook beschrijving van het zogenaamd Krechmer-model. Met dit door Ken Krechmer2 ontwikkelde model kan de openheid van een standaard concreet worden gemaakt wordt en kunnen standaardisatieorganisaties worden vergelijken. In het model maakt hij onderscheid tussen de verschillende openheidaspecten (requirements) en de verschillende gezichtspunten op standaarden. Als gezichtspunten/rollen hanteert hij de maker van de standaard (IDsW: Programma bureau, werkgroepen, regiegroep en Change Advisory Board), de implementator van de standaard in een product (ontwikkelaar / toepasser), en de gebruiker van de standaard (product waarin de standaard is verwerkt; eindgebruiker). Niet elk openheidaspect is voor elke rol even interessant, zoals het model ook laat zien.

Requirements Creator Implementer User

1. Open Meeting X

2. Consensus X

3. Due process X

4. Open World X X X

5. Open IPR X X X

6. Open Change X X X

7. Open Documents X X

8. Open Interface X X

9. Open Use X X

10. On-going support X

Lijst Nederland Open Standaarden

Naast het ‘Model van Krechmer’ kennen we in Nederland ook de zogenaamde ‘pas toe of leg uit’ lijst met Open Standaarden van het Forum Standaardisatie (zie www.forumstandaardisatie.nl). Het 'pas toe of leg uit'-principe houdt in dat overheidsorganisaties bij aanschaf van een ICT-dienst of -product, kiezen voor een van de open standaarden op de 'pas toe of leg uit'-lijst. Als dat tot onoverkomelijke problemen leidt, mag de organisatie ervoor kiezen om deze standaard niet te gebruiken. Daar staat echter tegenover dat in het jaarverslag verantwoordt moet worden waarom deze keuze is gemaakt (uitleggen). Opname op de lijst betekent dat voldaan wordt aan een aantal kernaspecten van een open standaard en sluit aan op het BOMOS-model.

Op 18 mei 2010 heeft het College Standaardisatie besloten om de Aquo-standaard op de “pas toe of leg uit”-lijst op te nemen zodra het beheer goed geregeld is. Hiermee wordt bedoeld dat de beheersorganisatie geen ‘eindtijd’ kent. Met het opgaan van IDsW in het InformatieHuis Water zal ook aan deze voorwaarde worden voldaan.

2 Voor meer informatie over het model: Krechmer, K., Open Standards Requirements, in: Standardization research in information technology new perspectives, pp49-65, editor: Kai Jakobs, IGI Global, 2008



2.4.2 Vergelijking BOMOS en beheer Aquo-standaard

Hieronder wordt steeds per onderdeel uit BOMOS een korte beschrijving van dat onderdeel en de daarbij behorende taken gegeven. In een kader is vermeld hoe dit binnen IDsW is belegd.

STRATEGIE:

Richtinggevende taken gerelateerd aan de strategische (lange) termijn: • Governance: beleid uitzetten over de eigen bestuurlijke organisatie; het

huishoudelijke reglement, maar ook allianties vormen met andere organisaties. Belangrijke aandacht hierbij voor besluitvorming

• Visie: inhoudelijke visie ontwikkelen over de richting van de ontwikkeling. De plek op de horizon op lange termijn.

• Financiën: een financieel model voor de lange termijn hebben die opbrengsten garandeert in overeenstemming met de behoeftes.

De strategische taken zijn binnen IDsW belegd bij de stuurgroep IDsW en worden veelal in nauwe samenwerking met de programmamanager uitgevoerd.

TACTIEK:

Taken op tactisch niveau, waaronder: • Community: het bewaken en bevorderen van een goede samenstelling van de

community.

Primair ligt deze taak bij de regiegroep als dagelijks bestuur van de adviesraad (en daarmee de gebruikersvertegenwoordiging). Ook als het gaat om het instellen van CAB’s en werkgroepen is de regiegroep primair verantwoordelijk.

• Erkenning: opstellen van voorstellen ten behoeve van de vaststelling door externe “statusverleners”.

De belangrijkste route naar externe ‘erkenning’ is het traject om Aquo op te laten nemen op de ‘comply or explain’ lijst van het forum Standaardisatie en Aquo daarmee officieel tot Nederlandse Open Standaard te verheffen.

• Rechtenbeleid: het voeren van beleid op het gebied van het intellectueel eigendom en copyright rondom de inhoudelijke producten van de community. Maar ook het toetredingsbeleid tot de community, en de rechten (en plichten) van de deelnemers in de community.

Het rechtenbeleid rondom de standaard wordt geregeld door de stuurgroep (eigendom en copyright). Daarbij is door IDsW gekozen voor het beschikbaarstellen van de Aquo-standaard op basis van een Creative Commons licentie.

Toetreden tot de IDsW community staat vrij voor iedereen; hiervoor geldt geen toetredingsbeleid. Toetreding tot de stuurgroep (en regiegroep) is gereserveerd voor betalende partners in IDsW.

IDsW kent momenteel geen formeel reglement voor gebruikers van de IDsW standaard; wel voor de leden van werkgroepen, CAB’s en de regiegroep / adviesraad.



• Architectuur, roadmapping en benchmarking: het uitzetten en toetsen van de inhoudelijke lijnen en het op hoofdlijnen bewaken van de samenhang tussen de inhoudelijke producten van de community. Bijzondere aandacht verdient hier de relatie met de internationale standaardisatie community, het oplijnen van de standaarden met de internationale standaarden. Met roadmapping wordt bedoeld de inhoudelijke lijn uit te zetten; bijvoorbeeld wanneer stappen we over de volgende versie van een onderliggende standaard. Beleid rond versiebeheer hoort hier ook bij. Benchmarken is de activiteit om de eigen activiteiten te spiegelen aan vergelijkbare organisaties om mogelijke verbetering te identificeren.

De architectuur wordt momenteel bewaakt op drie verschillende lagen in de organisatie. Het programmabureau (operationeel en tactisch overleg) is verantwoordelijk voor de inhoudelijke samenhang. Voor de architectuur op hoofdlijnen is de regiegroep verantwoordelijk.

De roadmapping is vastgelegd in de procedure versiebeheer van IDsW waarin vaste momenten zijn afgesproken waarop nieuwe versies in omloop komen. De overstap van applicaties naar een nieuwe versie is momenteel niet geregeld en is onderwerp van gesprek in overleg met de diverse informatiesystemen.

IDsW voert momenteel geen gestructureerde benchmarking uit. Wel wordt ongestructureerd informatie van vergelijkbare organisaties zoals het SIKB en Geonovum verzameld en als input gebruikt bij de ontwikkeling van de organisatiestructuur en de beheerprocessen.

OPERATIONEEL,

De uitvoerende taken die leiden tot nieuwe versies van standaarden, waaronder: • Initiatie: identificatie van nieuwe ideeën en alle activiteiten die horen bij het

succesvol optuigen daarvan.

Initiatie vindt op verschillende manieren plaats, afhankelijk van de oorsprong van het idee / de activiteit. In veel gevallen zijn nieuwe activiteiten het gevolg van ofwel vraagstelling door de gebruikers van de standaard, ofwel door identificatie binnen het programmabureau (tactisch / operationeel overleg). Indien de nieuwe activiteit voortkomt uit nieuw beleid dan wordt deze veelal ‘van bovenaf’ geïnitieerd door regiegroep of programmabureau (tactisch overleg).

• 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).

Maintenance requests worden door IDsW ‘Wijzigingsvoorstellen’ of ‘Requests for Change’s’ (RfC’s) genoemd. Procesmatig is het programmabureau hiervoor verantwoordelijk in samenwerking met de regiegroep, gebruikers en Change Advisory Boards. De afhandeling gaat volgens een vaste beheerprocedure.

• Ontwikkeling: het inhoudelijk bedenken van oplossing (zoveel mogelijk los van technologie) voor de ontwikkeling van de (nieuwe versie van) de specificatie.

Deze activiteit wordt door werkgroepen uitgevoerd voor uitgebreide / specifieke trajecten en door het programmabureau voor de overige trajecten.

• Uitvoeren: de daadwerkelijk aanpassingen doorvoeren in de specificatie en eventuele technische invulling.



Dit wordt door het programmabureau verzorgd (operationeel overleg)

• Documentatie infrastructuur: verzorgen van passende neerslag van de resultaten van het primair 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.

Dit wordt verzorgd door het programmabureau (operationeel overleg ism communicatie).

Op de IDsW website is de huidige versie van de standaard terug te vinden inclusief de wijzigingsvoorstellen over de afgelopen 3 jaar. Alle overige voorstellen en historische versies van documenten zijn op verzoek te verkrijgen via de servicedesk.

Tot slot wordt gewerkt aan de implementatie van historie bij de ontsluiting van de Aquo-domeintabellen en van Aquo-lex.

IMPLEMENTATIE-ONDERSTEUNING,

Ondersteunende taken gericht op het bevorderen van implementaties van de standaard, waaronder:

• Opleiding: Het bieden van opleidingsmogelijkheden aan gebruikers en ontwikkelaars variërend van een informatiebijeenkomst tot aan een cursus.

Op verzoek van gebruikers worden regelmatig – vaak op locatie - presentaties over IDsW en de Aquo-standaard gegeven. Een opleiding wordt momenteel niet door IDsW verzorgd; er wordt wel onderzoek gedaan naar de mogelijkheden hiertoe.

• Helpdesk: Het bieden van ondersteuning aan gebruikers en toepassers, bijvoorbeeld telefonisch of per e-mail, volgens een service level agreement. Een frequently asked questions kan ook een helpdesk activiteit zijn.

Het programmabureau verzorgt een servicedesk (helpdesk) die zowel via telefoon als e-mail toegankelijk is. Vragen worden vastgelegd in een registratiesysteem en er zijn SLA’s voor de afhandeling van vragen / voorstellen tot wijziging. Er wordt via vaste procedures gewerkt.

Verdere ondersteuning van gebruikers is er in de vorm van parameterlijsten, praktijkrichtlijnen en via de bundeling van informatie via inhoudelijke thema’s zoals waterkwaliteit en waterkwantiteit.

• Moduleontwikkeling: (stimuleren van) ontwikkeling van breed te verspreiden softwaremodules die de standaard implementeren.

Er worden door IDsW bewust geen generieke modules ontwikkeld. Wel heeft IDsW geparticipeerd in de ontwikkeling van de Aquo-kit om met name voor het KRW traject zorg te dragen voor standaardisatie en een efficiënte gegevensstroom.

Belangrijkste overwegingen voor het niet ontwikkelen van software modules zijn enerzijds efficiency (software ontwikkeling kost relatief veel geld) en anderzijds wil IDsW de markt niet verstoren met een dergelijke ontwikkeling (op de stoel van de ‘leverancier’ gaan zitten). Tot slot wordt zo voorkomen dat IDsW belang krijgt in het niet aanpassen van de standaard uit kostenoverweging (aanpassing eigen software modules).



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

Hoewel pilots geen verplichting zijn, worden er met enige regelmaat pilots uitgevoerd om de implementatie van een nieuwe standaard te toetsen.

Dit geldt niet voor wijzigingen aan de standaard; IDsW overweegt wel deze in de toekomst voor grote wijzigingen waarbij dit aan de orde is te gaan invoeren.

• Validatie & Certificatie: Het bieden van mogelijkheden bieden om de correctheid van de implementaties te testen (validatie). Daaraan kan een officieel traject verbonden worden wat leidt tot certificatie van een organisatie of product. Ook verplicht stellen van het doorlopen van validatie en certificatietrajecten behoort tot de mogelijkheden.

Momenteel biedt IDsW geen validatie of certificatie. Inmiddels is geconstateerd dat dit wel gewenst is en wordt hier onderzoek gedaan naar de juiste vorm van implementatie. Hierbij wordt zoveel mogelijk aangesloten bij lopende certificatie en validatie trajecten van SIKB en Geonovum.

COMMUNICATIE,

Ondersteunende taken gericht op het creëren van draagvlak voor de standaard, waaronder: • Promotie: Het uitdragen van nut/noodzaak/voordelen van de standaard.

Dit is een taak van alle onderdelen van IDsW. Directe promotie vindt vooral plaats via de website, maar tevens via accountmanagement.

• Publicatie: Het vindbaar / kenbaar maken van de standaard en de actuele stand van zaken, bijvoorkeur op Internet

Alle zaken rondom de Aquo-standaard worden gepubliceerd op internet op de IDsW website. Gebruikers worden hiervan (indien gewenst) via notificatie of RSS-feed op de hoogte gesteld.

• Klachtenafhandeling: Het garanderen van het serieus nemen van klachten door deze volgens een zorgvuldige procedure te behandelen.

IDsW kent geen formele klachtenprocedure anders dan de procedure voor afhandeling van reguliere vragen.

2.4.3 Vergelijking Model van Krechmer en beheer Aquo-standaard

In de volgende paragrafen wordt per openheidaspect uit het model van Krechmer aangegeven hoe dit aspect bij IDsW is belegd.



Open Meeting

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. Als ontwikkelen beheerorganisatie moet je zuinig zijn op stakeholders die willen participeren. Veelal 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.

In principe heeft iedereen, dus ook partijen die niet direct onderdeel uitmaken van het convenant, toegang tot de beheerprocedure van IDsW.

Consensus

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 (bv. het bestuur / partijen die financieel sterk bijdragen) te hebben die volledige controle heeft.

Besluitvorming bestaat uit twee zaken; de bestuurlijk / financiële besluitvorming en de inhoudelijke besluitvorming. De eerste is binnen IDsW voorbehouden aan de (betalende) partners; de tweede staat open voor iedereen dus ook van buiten de IDsW partners.

Uitzondering is dat de leveranciers een adviserende stem hebben in het besluitvormingsproces bij wijzigingen; dit is bewust gedaan om te voorkomen dat de techniek de semantiek te veel beïnvloed. Dit kan het geval zijn als een wijzigingsvoorstel bijvoorbeeld de informatie uitwisseling transparanter maakt maar lastig in applicaties te implementeren is.

Due process

Due process gaat over de processen hoe stemrondes zijn georganiseerd en de processen voor verzoeken tot heroverweging (appel) van beslissingen. Ofwel 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.

IDsW kent voor wijzigingsvoorstellen en nieuwe standaarden een duidelijke procedure waarin de diverse rollen en beslismomenten eenduidig zijn beschreven.



Open World

Open World betekent dat idealiter dat voor hetzelfde doel er 1 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 betekent ook dat er geen regionale of nationale standaard gecreëerd dient te worden als een wereldwijde standaard voldoet. In algemene termen betekent Open World ook dat de standaardisatieorganisatie verkokerd, met oogkleppen op, een standaard ontwikkeld 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.

IDsW probeert waar mogelijk aan te haken op andere standaarden of deze nader te specificeren (bv ISO, CEN en NEN standaarden). Waar in andere sectoren een goede standaard bestaat verwijst IDsW naar deze standaard vanuit Aquo (bv IMRO, IMKL). Daar waar overlap tussen standaarden bestaat streeft IDsW naar het harmoniseren van de overlap of als dat niet mogelijk is zorg te dragen voor een mapping zodat inzichtelijk wordt hoe de relatie tussen de standaarden is (bv SIKB, IM-Metingen).

Open IPR

Open IPR (intellectuele eigendomsrechten) is het aspect waar de meeste discussie over is geweest, waarbij vooral “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. Deze standaardisatieorganisaties voldoen dan ook veelal 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? 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 veelal goed (open), echter 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.

De standaard is gratis te downloaden en wordt beschikbaar gesteld onder de Creative Commons licentie:

- Naamsvermelding. Gebruikers verwijzen naar de Aquo-standaard als ze deze gebruiken.

- Niet- commercieel. De standaard mag niet voor commerciële doeleinden gebruikt worden. Het gaat hier vooral om het doorverkopen van de documentatie; uiteraard geldt dit niet voor implementaties van de standaard in informatiesystemen.

- Geen afgeleide werken. De standaard mag niet bewerkt worden door gebruikers maar dient zoals gepubliceerd overgenomen te worden.



Bij inbreng van ‘derden’ bij de ontwikkeling van de standaard via wijzigingsvoorstellen of deelname aan werkgroepen kunnen deze ‘derden’ na inbreng geen verdere rechten ontlenen aan het gebruik en verdere publicatie van deze inbreng.

Open Change

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

IDsW hanteert een open procedure en open meeting voor het beheer en onderhoud van de standaard en kan niet zelfstandig wijzigingen doorvoeren aan de standaard.

Open Documents

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, maar ook 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.

De specificaties van de getoetste deelstandaarden en ondersteunende hulpmiddelen zijn voor iedereen gratis te downloaden vanaf de website van IDsW. Er gelden geen relevante beperkingen (Creative Commons).

Werkdocumenten en notulen worden nog niet altijd op de site beschikbaar gesteld maar zijn op verzoek wel beschikbaar. IDsW werkt aan het beter beschikbaar stellen van deze documenten voor de buitenwereld.

Open Interface

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 biedt voor backward en forward comptabiliteit.

Valkuil: het niet adresseren van backward comptabiliteit en de ruimte bieden voor tijdelijke uitbreidingen (forward comptabiliteit)

Gesloten uitbreidingen op de Aquo-standaard zijn alleen mogelijk indien deze niet in tegenspraak zijn met de standaard zelf (het moeten uitbreidingen zijn). Backward compatibility wordt waar mogelijk bij wijzigingen ondersteund; forward compatibility wordt door IMWA en UM Aquo ondersteund in die zin dat het mogelijk is om hierin extensies te definiëren die later onderdeel (kunnen) worden van het model zelf.



Open Use

Open Use: Eind gebruikers vertrouwen er vaak op dat hun leverancier(s) de standaarden correct hebben geïmplementeerd. Om “Open Use” 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 zogenaamde 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.

Momenteel kent Aquo geen voorzieningen voor ‘open use’ hoewel er wel aan een Aquo-keurmerk gewerkt wordt en GML uitwisselberichten met een eenvoudige XML schema validatie gecontroleerd kunnen worden.

Voor toepassingen gebaseerd op de diverse gegevensmodellen is conformiteit minder eenvoudig vast te stellen. In de praktijk kan IDsW hierin adviseren, maar er is geen stempel om te bepalen of een toepassing ‘Aquo compliant’ is. Dit is inherent aan het feit dat het hier om een semantische standaard gaat.

Met het onderzoek naar certificatie en validatie zijn de eerste stappen gezet naar een ‘open use’. Op basis van het onderzoek zal een verdere implementatiestrategie worden bepaald die met name in het IHW zal worden geëffectueerd.

Ongoing Support

On-going 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.

De levenscyclus van de (onderdelen van de) Aquo-standaard is momenteel niet beschreven.

De besluitvorming over het al dan niet uitfaseren van een onderdeel van de standaard verloopt via de reguliere wijzigingsprocedure en wordt getoetst door de regiegroep en geaccordeerd door de stuurgroep. Met de overgang van IDsW naar het InformatieHuis Water is de ongoing support van de standaard gewaarborgd.

2.4.4 Aquo als Nederlandse Open Standaard

Door het College Standaardisatie worden de volgende toetsingscriteria gebruikt voor opname van standaarden op de lijst van Nederlandse Open Standaarden:

Openheid

• De standaard is goedgekeurd en zal worden gehandhaafd door een non-profit organisatie.



• De lopende ontwikkeling gebeurt op basis van een open besluitvormingsprocedure die toegankelijk is voor alle belanghebbende partijen (consensus of meerderheidsbeschikking enz.);

• De standaard is gepubliceerd en over het specificatiedocument van de standaard kan vrijelijk worden beschikt of het is te verkrijgen tegen een nominale bijdrage. Het moet voor een ieder mogelijk zijn om het te kopiëren, beschikbaar te stellen en te gebruiken om niet of tegen een nominale prijs

• Het intellectuele eigendom – met betrekking tot mogelijk aanwezige patenten – van (delen) van de standaard is onherroepelijk ter beschikking gesteld op een “royalty-free” basis

• Er zijn geen beperkingen omtrent het hergebruik van de standaard

De standaard en de beheersprocedure is voldoende open. Alle direct betrokken stakeholders (de convenantpartijen) participeren rechtstreeks. Daarnaast kunnen ook derden wijzigingsverzoeken indienen en participeren in het proces.

Als aanvullende opmerkingen zijn gemaakt (inmiddels afgedekt) dat de eigendomsrechten expliciet gemaakt moesten worden (Creative Commons) en dat het beheer naar de toekomst geregeld moest worden (InformatieHuis Water)

Bruikbaarheid

• Is de standaard voldoende uitgekristalliseerd? • Is verdere ontwikkeling en het onderhoud van de standaard verzekerd? • Is er een methode waarmee conformiteit aan de standaard bepaald kan worden? • Is er voldoende praktijkervaring met het gebruik van de standaard? • Is er nu en in de toekomst voldoende ondersteuning door (meerdere) marktpartijen

voor de standaard? • Is de verwachting van het toekomstig gebruik van de standaard positief? • Wat zijn de functionele eisen die aan de werking van de standaard gesteld worden

binnen het voorgestelde toepassingsgebied? In welke mate voldoet de standaard aan deze eisen? Hoe verhoudt zich dit tot concurrerende standaarden?

• Zijn er concurrerende standaarden? Zo ja, welke en door wie worden die gebruikt? • Wat zijn de voor- en nadelen van deze standaard ten opzichte van concurrerende

standaarden?

De Aquo-standaard is een volwassen standaard die goed aansluiten op de functionele eisen die gelden in het gekozen toepassingsdomein. Het aantal concurrerende standaarden is beperkt, deze bedienen bovendien vaak een specifieker toepassingsdomein. De bruikbaarheid wordt door de expertgroep als goed beoordeeld.

Potentieel

• Draagt het opnemen van de standaard op de lijst bij aan het vergroten van de leveranciersonafhankelijkheid?

• Draagt het opnemen van de standaard op de lijst bij aan het vergroten van de interoperabiliteit?



Toepassing van de Aquo-standaard draagt in hoge mate bij aan de interoperabiliteit tussen partijen die actief zijn in het Nederlandse waterbeheer. Het delen van gegevens voorkomt dubbele metingen, is nodig voor nationale processen t.b.v. de Kaderrichtlijn Water en verbetert daarmee de effectiviteit van het waterbeheer in ons land. Doordat de Aquo-standaard het resultaat is van een samenwerking tussen overheidspartijen, ontstaat een open speelveld voor (ICT-) leveranciers en (daardoor) keuzevrijheid voor overheden.

Impact

• Brengt de toepassing van de standaard risico's met zich mee op het gebied van de bedrijfsvoering?

• Brengt de toepassing van de standaard positieve effecten met zich mee op het gebied van de bedrijfsvoering?

• Brengt de toepassing van de standaard risico's met zich mee op het gebied van de informatievoorziening?

• Brengt de toepassing van de standaard positieve effecten met zich mee op het gebied van de informatievoorziening?

• Brengt de toepassing van de standaard technologische risico's met zich mee? • Brengt de toepassing van de standaard positieve technologische effecten met zich

mee op het gebied van de informatievoorziening? • Brengt de toepassing van de standaard risico's met zich mee op het gebied van

beveiliging of privacy? • Brengt de toepassing van de standaard positieve technologische effecten met zich

mee op het gebied van de beveiliging en privacy? • Kan er gemakkelijk naar de standaard toe worden gemigreerd?

Onder ‘potentieel’ zijn reeds een aantal zaken genoemd m.b.t. de impact van de Aquo-standaard op de bedrijfsvoering van waterbeheerders. De technische risico’s zijn verder beperkt. De expertgroep beseft de inherente praktische moeilijkheden die er kunnen zijn bij het migreren naar de Aquo-standaard vanuit een andere. Daar nu één standaard is waarheen gemigreerd moet worden en vanwege het feit dat nieuwe systemen nu een duidelijke standaard kunnen implementeren vormt de Aquo-standaard geen beletsel voor verbetering en vernieuwing, maar juist een stimulans.


Bijlagen pagina 29 van 63

3. Procedures voor beheer en onderhoud

3.1 Introductie procedures

De InformatieDesk standaarden Water (IDsW) beheert gegevensstandaarden binnen de sector water. Een handvat voor het opzetten van een professionele serviceorganisatie is de ITIL3 richtlijn. In deze richtlijnen bibliotheek staat beschreven hoe deze processen het beste ingericht kunnen worden. ITIL blijkt waardevol bij het opzetten van beheer om stabiliteit aan te brengen en de afstemming tussen medewerkers te vereenvoudigen. Hoewel ITIL vooral gericht is op de IT-beheerprocessen is deze ook gebruikt voor het vormgeven van de beheerprocessen rondom gegevensstandaarden zoals de IDsW.

Omdat het implementeren van ITIL ook nadelen kent (de klant vraagt in de praktijk niet om ITIL, maar gaat uit van zijn eigen behoefte en wil een dienstverlening die daarbij aansluit; samenhang tussen ITIL-processen, beheertaken, organisatorische eenheden en hulpmiddelen is in de praktijk moeilijk en ITIL ontbeert een zienswijze over hoe organisaties met kennis moeten omgaan) kiest de IDsW voor een ‘gezond verstand’-benadering bij het toepassen van ITIL.

Voor het beheer van onze standaarden hebben wij een heldere werkwijze vastgesteld met behulp van bovenstaande uitgangspunten. Vragen en verzoeken komen binnen op onze Servicedesk. Daar worden ze geregistreerd en beoordeeld. Wat is het voor een verzoek? Is het een complex probleem? Gaat het om een wijziging? Een nieuw project? Of zelfs het in beheer nemen van een nieuwe standaard? Om de verschillende soorten vragen van de klant aan de IDsW te stroomlijnen en op elkaar af te stemmen zijn er een aantal beheerprocedures. Elk soort vraag heeft een eigen werkproces.

Bij elke procedure zijn de verantwoordelijkheden, rollen en taken van de organisatieonderdelen van IDsW benoemd (zie Hoofdstuk 2 voor meer informatie over organisatieonderdelen)

3.1.1 Termen en definities

Binnen de procedures wordt regelmatig gerefereerd aan de organisatie onderdelen van IDsW; deze worden hier niet verder beschreven. We onderscheiden verder de volgende aanvullende termen binnen de procedures:

Term Uitleg

Incident; vragen en verzoeken

Voor de registratie van vragen en verzoeken wordt bij IDsW gebruik gemaakt van de module Incidentbeheer van het helpdesksysteem TOPdesk. De term incident komt uit ITIL en is gedefinieerd als:

Een incident is elke gebeurtenis, die niet tot de standaardoperatie van een service behoort, dit kunnen zowel verstoringen van de kwaliteit van dienstverlening zijn als service requests.

Deze brede definitie, die afkomstig is uit het netwerk- en

3 Staat voor Information Technologie Infrastructure Library. Het is een beschrijving van processen voor ondersteuning van IT-infrastructuur (apparatuur en/of software). Hierbij gaat het met name om het afhandelen van incidenten, het signaleren van problemen en beheer van wijzigingen of voorstellen daarvoor (zie ook het boek 'IT Service Management, een introductie op basis van ITIL, V4.0, januari 2004, Van Haren Publishing, ISBN 90-806713-2-0).


pagina 30 van 63 Bijlagen

Term Uitleg

hardwarebeheer, kan voor IDsW vertaald naar elke vraag of verzoek die bij de IDsW servicedesk binnenkomt.

Elke keer als de gebruiker contact opneemt met de Servicedesk is er sprake van een vraag of verzoek. De volgende soorten vragen of verzoeken kunnen daarbij worden onderscheiden:

- Gebruikersvraag over Aquo-standaard;

- Vraag over andere standaarden;

- Vraag over nieuwe ontwikkelingen en de betrokkenheid van IDsW daarbij;

- Verzoek om een onderzoek/project te starten of daarin deel te nemen;

- Verzoek om informatie/documentatie;

- Aanvraag voor het uitbreiden van een domeintabel;

- Wijzigingsvoorstel (wens), ofwel Request for Change (RfC) op een Aquo-standaard;

- etcetera.

1e lijn of 2e lijn Een incident is initieel een eerstelijns incident. Als het incident niet op korte termijn – door de Servicedesk - kan worden afgehandeld of door specialisten moet worden opgepakt, dan moet het geëscaleerd worden tot tweedelijns incident. Tweedelijns incidenten worden over het algemeen door specialisten uit de (externe) Back-Office afgehandeld.

Servicedesk (Front-Office)

De Servicedesk is het eerste aanspreekpunt voor incidenten. De Servicedesk is het organisatie onderdeel dat zorg draagt voor:

- Bereikbaarheid van IDsW;

- Het registreren van vragen en verzoeken (incidenten) en het toekennen van een behandelaar;

- Het afhandelen van eenvoudige of veel voorkomende incidenten;

- Voortgangsbewaking van de afhandeling van incidenten.

Oplostijd De tijd tussen het melden van een incident en het creëren van een oplossing die de betreffende verstoring verhelpt.

De oplostijd van incidenten wordt gemeten vanaf de melding van het incident bij de servicedesk tot het moment waarop de oplossing door de behandelaar aan de aanmelder is doorgegeven en het incident is afgesloten.



3.2 Procedure: Behandeling van verzoeken

Over het algemeen geldt het volgende procesdiagram voor het afhandelen van vragen/verzoeken:

Programma bureau Servicedesk (Front-Office)

Indiener

Incident / Vraag / Verzoek

Aannemen vraag +

noteren NAW

Vraag registreren

Beoordeling 1e / 2e

Programmabureau (operationeel overleg) Back-office extern

Afhandelen vraag / verzoek

1e lijn

2e lijn

Ontvangst bevestiging

Antwoord

1

2

3

4

Registratie vragen en verzoeken

3.2.1 Beschrijving procedurestappen

De werkwijze van deze procedure is als volgt:

Stap Beschrijving

1 Een vraag/verzoek komt binnen per telefoon, E-mail (ook via webformulier) of direct mondeling bij een medewerker van IDsW.

2 De vraag of het verzoek wordt geregistreerd door de Servicedesk.

De afdeling Communicatie voegt de adresgegevens toe aan het IDsW adressenbestand zodat de gebruiker ook in de toekomst geïnformeerd kan worden.

3 Beoordeeld moet worden of een vraag in de 1e lijn kan worden beantwoord, of dat escalatie naar 2e lijn noodzakelijk is. Bij afhandeling in de 1e lijn heeft het antwoord geen effect op de producten van IDsW (standaard, website) of is geen



Stap Beschrijving

actie van een (externe) backoffice vereist. In alle overige gevallen is er sprake van escalatie naar de 2e lijn.

Een vraag/verzoek wordt geëscaleerd naar de tweede lijn indien:

- Het een wijziging van de standaard inhoud. De procedure Wijzigingsvoorstellen wordt dan gestart;

- Het een verzoek voor het uitvoeren van project inhoudt (en een wijziging van het werkplan tot gevolg heef.). De procedure Nieuw project wordt dan gestart;

- Het een verzoek voor het opnemen van een nieuwe standaard inhoudt (en dus een wijziging van het werkplan tot gevolg heeft.). De procedure Nieuwe standaard wordt dan gestart;

- Dit een grote aanpassing van de website / content tot gevolg heeft.

- Indien de doorlooptijd van 5 dagen niet haalbaar is gezien de complexiteit van de vraag.

- Indien de vraag behandeld moet worden door een medewerker van de IDsW back-office;

- Hiervoor een actie van een ‘derde’ of externe backoffice noodzakelijk is.

In alle andere gevallen blijven het 1e lijns vragen.

4 In de 1e / 2e lijn wordt het incident afgehandeld door de behandelaar en wordt het antwoord teruggegeven aan de indiener van de vraag. Daarbij wordt geverifieerd of het antwoord heeft geleid tot het oplossen van de initiële vraag.

3.2.2 Verantwoordelijkheden, rollen en taken

In deze procedure zijn de volgende rollen, taken en verantwoordelijkheden gedefinieerd:

Organisatie-onderdeel

Rol / Taak / Verantwoordelijkheid / Mandaat

Indiener (een gebruiker)

Elke gebruiker of geïnteresseerde in IDsW / de Aquo-standaard kan een vraag indienen bij de servicedesk en mag op zijn / haar vraag een onderbouwd antwoord verwachten.

De gebruiker dient een vraag / verzoek / incident in en verstrekt daarbij zijn NAW gegevens voor verdere communicatie. Door het indienen van een vraag wordt de gebruiker opgenomen in het adresbestand voor verdere communicatie.

De gebruiker verifieert of het antwoord op de vraag het gewenste antwoord is en communiceert dit met de servicedesk zodat de vraag als afgehandeld kan worden beschouwd.

Servicedesk Verantwoordelijk voor de inname, registratie en bewaking van de afhandeling van de vraag. Tevens verantwoordelijk voor de afhandeling van eerstelijns vragen.

Operationeel overleg Verantwoordelijk voor de afhandeling van tweedelijns vragen en het eventueel uitzetten hiervan naar een externe back-office of andere organisatie onderdelen van IDsW zoals CAB, regiegroep en stuurgroep.

Geeft (via de servicedesk) reactie aan de indiener en communiceert over de voortgang bij langlopende trajecten.



3.2.3 Service Level Agreement

Servicedesk

Norm Normstelling Waarde

Openingstijden Werkdagen4 09:00–12:00 en van 13:00–16:00 uur

Zaterdagen / Zon- en Feestdagen

Nvt

Meldingsvormen Telefonisch 0320-298999 / 06-10968667

E-mail [email protected]

Schriftelijk – brief Postbus 17, 8200 AA Lelystad

Webformulier www.idsw.nl

Mondeling (‘balie’) Nvt

Responstijden

Norm Korte omschrijving Normstelling

Melden per telefoon Gemiddelde antwoordsnelheid door Nederlands sprekend persoon of door antwoordapparaat / voicemail van IDsW servicedesk.

In alle gevallen geldt de normstelling van 95% persoonlijk contact binnen 5 minuten.

5% van de gesprekken mag in de voicemail terecht komen.

Melden via voicemail, E-mail of internetformulier

Bevestiging van ontvangst van melding van incident door de servicedesk.

In alle gevallen geldt de normstelling:

- 80% binnen 1 werkdag

- 100% binnen 2 werkdagen

met vermelding van call nummer.

Klant informeren over oplostijd

Na inhoudelijk beoordelen van het incident door de servicedesk de klant informeren over de oplossing of geschatte doorlooptijd.




na registratie beoordelen of het incident direct (in 1e lijn) kan worden opgelost of moet worden doorgezet naar de 2de lijn.

Melding van escalatie door servicedesk per E-mail.

Gemiddelde antwoordsnelheid op het in behandeling nemen door 2de of 3de lijn.

In alle gevallen geldt de normstelling van 100% binnen 2 werkdagen.

Melding van escalatie door 2de lijn per E-mail.

3de lijn wordt door de 2de lijn ingeschakeld. Responstijden zijn hier

nvt

4Een zogenaamde blokdag, of een cursus- of beleidsdag van het gehele programmabureau worden niet als werkdag beschouwd. Deze dagen worden vooraf meegedeeld aan de gebruikers via de IDsW website.




niet benoemd omdat ze door 2de en 3de lijn in overleg met de indiener onderling worden afgesproken.

Afhandeling


Behandelingstijden De tijden waarop incidenten afgehandeld kunnen worden.

De behandelingstijden zijn minimaal gelijk aan de openingstijden van de servicedesk.

Oplostijd De tijd tussen het melden van een incident en het creëren van een oplossing die de betreffende verstoring verhelpt.

Voor de oplostijden geldt de volgende normstelling:

- 1ste lijns incidenten: 5 werkdagen, in 100% van de gevallen.

− 2de lijns incidenten: de maximale oplostijd is gekoppeld aan de uit te voeren handeling in de 2de lijn. De oplostijd is altijd minder dan de met de aanmelder afgesproken eindtijd.



3.3 Procedure: Behandeling verzoek nieuw (standaard)product

Een potentiële nieuw product (gegevensstandaard, applicatie, database of methodiek) wordt getoetst aan de volgende drempelcriteria voordat het voorstel ingediend kan worden bij de stuurgroep voor uitbreiding van de door IDsW te beheren pakket standaarden. Deze toetsing wordt uitgevoerd tijdens het vooroverleg (stap 3) en vastgelegd in het voorstel:

• Een product is gemeenschappelijk ontwikkeld door de partners van IDsW, of een relevant aantal (meer dan de helft) van deze partners.

• Een product is ontwikkeld door derden, maar dient het belang van de bij IDsW betrokken waterbeheerders of staat ten dienste van de gegevensuitwisseling van alle partners van IDsW.

• Een product is van belang voor de aanlevering van informatie volgens wettelijke verplichtingen (zoals bij de KRW).

• Een product kan als standaard worden aangemerkt en vormt een aanvulling van de standaard van IDsW.

- Tactisch overleg

In diener

Adviesgroep / Regiegroep

Stuurgroep

Servicedesk

Verzoek nieuwe

standaard

Besluit in Tactisch overleg

Verzoek registreren 2

Advies opstellen

8

Voor - over - leg

3

Voorstel maken

6

Voorstel reviewen + advies 7

Besluit over voorstel

positief

4

9

Antwoord 1 8b

Wijzigings - voorstel 10

Antwoord

positief

5b

Afmelden

5



Stap Beschrijving

1/2 Verzoek om nieuw standaardproduct in beheer te nemen is binnengekomen bij IDsW en als verzoek vastgelegd (zie procedure Vragen en Verzoeken).

3 Er vindt vooroverleg plaats met de indiener van de aanvraag. Als onderwerpen komen minimaal aan de orde:



Stap Beschrijving

- Uitleg werkzaamheden IDsW en toelichting op de beheerde (standaard)producten;

- Korte toelichting op - de ontwikkeling van - het product (door indiener);

- Gezamenlijk doorlopen van de drempelcriteria;

- Indien het product een gegevensstandaard betreft wordt het tevens gezamenlijk beoordeeld aan de hand van de criteria van een Nederlandse Open Standaard. Hiervoor wordt gebruik gemaakt van het scoreformulier van het Forum Standaardisatie.

- Indien het product een applicatie of database betreft wordt tevens gezamenlijk een oriëntatieformulier met de kenmerken van de applicatie-database ingevuld. Hiervoor wordt gebruik gemaakt van een vragenformulier gebaseerd op de ASL Intakeprocedure. Belangrijke onderdelen in het formulier zijn o.a.: doel/functionaliteit, gebruik, omvang, techniek, documentatie, ontwikkeling&beheer(kosten) en kwaliteit. Hierbij wordt nadrukkelijk aandacht besteed aan de toepassing van (open) standaarden en de Aquo-standaard in het bijzonder.

- Indien het product een methodiek betreft wordt tevens gezamenlijk een oriëntatieformulier met de kenmerken van de methodiek ingevuld. Hiervoor wordt gebruik gemaakt van een vragenformulier gebaseerd op de ASL Intakeprocedure. Belangrijke onderdelen in het formulier zijn o.a.: doel/functionaliteit, gebruik, omvang, techniek, documentatie, ontwikkeling&beheer(kosten) en kwaliteit. Hierbij wordt nadrukkelijk aandacht besteed aan de toepassing van (open) standaarden en de Aquo-standaard in het bijzonder.

- Verzoek om invulling van het voorstel door de indiener.

Aan dit vooroverleg nemen in ieder geval deel: de indiener en een projectleider Standaarden.

4/5 Het verzoek wordt door de projectleider Standaarden ingebracht in het IDsW Tactisch Overleg, waar een besluit over het verzoek wordt genomen.

6 Bij een positief besluit wordt het document “Voorstel voor het in beheer nemen van <nieuw (standaard)product>” ingevuld door de indiener. De ingevulde formulieren uit stap 3 wordt als bijlage aan het voorstel toegevoegd.

7 Het voorstel wordt gereviewed door de projectleider Standaarden. In overleg met de indiener kan het voorstel ook door de projectleider Standaarden worden aangevuld.

Onderdeel van de review is een kwaliteitsbeoordeling van het (standaard)product. Hiervoor wordt gebruik gemaakt van (een formulier gebasserd op) de kwaliteitsmatrix uit de ASL Intakeprocedure of van het Integrate Kwaliteitsmodel.

Tevens wordt door de projectleider Standaarden een inschatting gemaakt van de eenmalige en jaarlijkse kosten van (standaard)product. Hiervoor kan gebruik worden gemaakt van het Rekenmodel uit de ASL Intakeprocedure. Belangrijke onderdelen van dit formulier zijn o.a. inwerktijd, achterstallig onderhoud, beheer en het onderhoud.

De programmamanager beoordeelt het voorstel en geeft voor het in beheer nemen van het product een positief of negatief advies uit.

Het advies wordt kenbaar gemaakt aan de indiener.

8 Het voorstel wordt met het advies ingebracht in de regiegroep. Zij beoordeelt het voorstel en voorziet het van haar advies. Het advies wordt kenbaar gemaakt aan de indiener.



Stap Beschrijving

9 Het voorstel wordt met het advies van programma bureau en regiegroep ingebracht in de regiegroep. Zij beoordeelt het voorstel en voorziet het van haar advies.

De stuurgroep neemt een besluit over het wel of niet in beheer nemen van het nieuwe product. De indiener wordt op de hoogte gesteld van het besluit van de stuurgroep.

10 Indien de stuurgroep heeft besloten om het product in beheer te nemen, dan wordt de benodigde activiteiten hiervoor door het programmabureau gestart. Ofwel er wordt een wijzigingsvoorstel geregistreerd. Zie procedure Wijzigingsvoorstellen.


In deze procedure zijn de volgende rollen, taken en verantwoordelijkheden gedefinieerd:

Organisatie- onderdeel



Het staat iedere gebruiker van de Aquo-standaard vrij een verzoek tot opname van een nieuwe standaard te doen.

Dient een verzoek voor het opnemen van een nieuwe standaard in; neemt deel aan het vooroverleg en verantwoordelijk voor het opstellen van een voorstel conform het IDsW sjabloon “Voorstel voor het in beheer nemen van <nieuw standaardproduct>”

Servicedesk Registreert het verzoek en neemt eventueel deel aan het vooroverleg

Tactisch overleg Beoordeelt het verzoek; initieert het vooroverleg en zorgt voor het advies vanuit het programmabureau naar aanleiding van het voorstel.

Zorgt er tevens voor dat het voorstel en advies wordt overgedragen aan de regiegroep en dat de indiener geïnformeerd blijft over de status.

Zorgt ervoor dat het voorstel, bij goedkeuring door de stuurgroep, wordt omgezet in een wijzigingsvoorstel.

Regiegroep / Adviesraad

Stelt een advies op ten aanzien van het voorstel en communiceert dit advies aan zowel het tactisch overleg als de stuurgroep.

Stuurgroep Besluit op basis van het gezamenlijke advies van tactisch overleg en regiegroep of het voorstel wordt doorgevoerd of niet.



Tactisch overleg

Indiener

Adviesgroep / Regiegroep

Stuurgroep

Servicedesk

Werk- groep

Verzoek nieuw project

Besluit in Tactisch overleg

Verzoek registreren

2

Advies draagvlak

7

3

Besluit over voorstel

positief

4

8

Antwoord

1 8b

Wijzigings-voorstel 10

Antwoord

positief

5b

Afmelden

5

Project-plan

maken

Voor- overleg

klein

Project uitvoeren

9 3 6

3.4 Procedure: Behandeling verzoek nieuw project

Deze procedure is bedoeld om nieuwe ontwikkelingen uit te werken/onderzoeken, doel hierbij is het planmatig ontwikkelen van een nieuw product of (grote) aanpassing van een bestaande standaard. Projecten worden een keer per jaar in het werkplan vastgesteld.

Waarom een procedure voor toelating van projecten binnen IDsW? Omdat anders de kans bestaat dat er een wildgroei optreedt aan projecten die worden opgestart zonder de consequenties daarvan goed in kaart te hebben gebracht; wat de slagingskans van een individueel project sterk zal kunnen verminderen. Hoe gaan we bijvoorbeeld om met verzoeken om een project op te starten ten behoeve van een Europese richtlijn of verzoeken/verwachtingen uit het werkveld die kunnen leiden tot een wijzigingsvoorstel op onze standaarden?



Stap Beschrijving

1/2 Verzoek voor een nieuw project is ingediend bij IDsW en als melding vastgelegd. Overigens kunnen projecten ook worden ingediend door medewerkers van het Programmabureau zelf

3 Er vindt vooroverleg plaats tussen het tactisch overleg en de indiener van de aanvraag om alle projectdetails helder te krijgen. Tijdens het vooroverleg vindt



Stap Beschrijving

een eerste toetsing van het project plaats aan de hand van de volgende toetsingsvragen:

- Past het projectdoel binnen de visie van IDsW?

- Is het voor onze doelgroep(en)?

- Is het projectresultaat helder?

- Resulteert het project in een wijzigingsvoorstel?

- Past het in het geldende werkplan van het jaar waarin het project loopt?

4/5 Het verzoek en de resultaten van het vooroverleg wordt ingebracht in het IDsW werkoverleg, waar een besluit over het verzoek wordt genomen.

Het resultaat van het vooroverleg en het besluit worden vastgelegd bij het Incident. Dit Incident wordt vervolgens afgesloten.

Bij een klein project, waarbij het werkplan dus ongewijzigd blijft, kan direct met de uitvoering van het project (stap 9) gestart worden.

6 Indien in de werkgroep een positief besluit is genomen wordt het projectvoorstel door de projectleider standaarden IDsW samen met de indiener verder uitgewerkt. Het projectplan moet minimaal antwoord geven op de volgende vragen:

Voorwaardelijke vragen

- Zijn er voldoende middelen? Is er budget begroot of te vinden? Zijn de kosten gedekt?

- Zijn er randvoorwaarden voor het project te benoemen?

- Is er voldoende capaciteit / draagvlak?

- Is de projectmethodiek duidelijk?

- Wat zijn de uitgangspunten/bronnen van dit project?

- Hoe zit het met extern uitbesteden, moet er rekening met offertetraject(en) worden gehouden?

Organisatorische vragen

- Wie is de projectleider?

- Hoe ziet de projectorganisatie eruit?

- Zijn de verantwoordelijkheden duidelijk, en ook helder gecommuniceerd?

- Is de communicatie goed beschreven/geregeld? Is er bijvoorbeeld een projectpagina?

- Is de planning reëel en helder?

7 Het projectplan wordt ingediend bij de Regiegroep voor advies. De Regiegroep bekijkt of er binnen de Adviesraad voldoende draagvlak voor is.

De Regiegroep stelt een advies op voor de Stuurgroep om er extra middelen voor vrij te maken of om er een werkgroep voor op te richten.

8 Het projectplan wordt met het advies van de Regiegriep ter besluitvorming aan de Stuurgroep voorgelegd.

In de eerstvolgende bijeenkomst van de stuurgroep vindt besluitvorming plaatst en wordt het project wel of niet opgestart. Indien de volgende vergadering te ver in de toekomst ligt is het ook mogelijk dat de stuurgroep tot schriftelijke besluitvorming overgaat. De servicedesk informeert de indiener en de doelgroepen.

9 Het project wordt uitgevoerd door de deelnemers aan het operationeel overleg. Op advies van de Regiegroep of op initiatief van het tactisch overleg kan worden besloten om voor de uitvoering van het project een aparte werkgroep op te richten. Zie hiervoor Bijlage Reglement Werkgroep.



Stap Beschrijving

10 Eventueel wordt als resultaat van het project een Wijzigingsvoorstel opgeleverd. Zie procedure Wijzigingsvoorstellen.


In deze procedure worden de volgende rollen, taken en verantwoordelijkheden gedefinieerd:




Het staat iedere gebruiker van de Aquo-standaard vrij een verzoek voor een nieuw project te doen.

Dient een verzoek voor het uitvoeren van een nieuw project in; neemt deel aan het vooroverleg en is medeverantwoordelijk voor het opstellen van een projectplan.

Servicedesk Registreert het verzoek en neemt eventueel deel aan het vooroverleg. Draagt ervoor zorg dat een eventuele uitkomst van het project als wijzigingsvoorstel wordt geregistreerd en behandeld.

Operationeel overleg Voert het project uit / zorgt dat het project uitgevoerd wordt.

Tactisch overleg Beoordeelt het verzoek; initieert het vooroverleg en zorgt voor het medeopstellen van het projectplan.

Zorgt er tevens voor dat het voorstel en advies wordt overgedragen aan de regiegroep en dat de indiener geïnformeerd blijft over de status.

Zorgt ervoor dat het voorstel, bij goedkeuring door de stuurgroep, wordt uitgevoerd; eventueel in samenwerking met een daarvoor op te richten werkgroep.

Regiegroep / Adviesraad

Stelt een advies op ten aanzien van het voorstel en communiceert dit advies aan zowel het tactisch overleg als de stuurgroep.

Werkgroep Voert werkzaamheden uit ten behoeve van het project. Wordt ontbonden zodra het product is opgeleverd.

Stuurgroep Besluit op basis van het gezamenlijke advies van tactisch overleg en regiegroep of het voorstel wordt uitgevoerd of niet.



3.5 Procedure: Behandeling wijzigingsvoorstel

Dit is de procedure voor het afhandelen van Wijzigingsvoorstellen ofwel RfC’s (Request for Changes) voor wijzigingen op bestaande standaarden. Het programmabureau IDsW vraagt van de gebruikers altijd een reactie op de voorstellen. Reageren op een wijzigingsvoorstel kan via inspraak of door zitting te nemen in een Change Advisory Board (CAB). Als een CAB meer tijd nodig heeft om tot een advies te komen, dan wordt de wijziging pas in een latere versie meegenomen.

IDsW maakt bij de voorstellen onderscheid naar impact. Wijzigingsvoorstellen worden ingedeeld in drie categorieën op basis van de impact van de wijziging (zie bijlage E voor een gedetailleerd overzicht van de impact van verschillende typen wijzigingen):

Impact Update standaard Instemming gebruikers

Klein Direct (maximaal 5 werkdagen tenzij anders overeengekomen met de indiener). Wel worden ze formeel beschikbaar gesteld via de eerstvolgende Aquo update (zie procedure Versies en updates)

Indien noodzakelijk, schriftelijk *1

Middelgroot Eerstvolgende Aquo update in juni of december (zie procedure Versies en updates)

Altijd schriftelijk, CAB indien noodzakelijk

Groot Eerstvolgende Aquo-update in juni (grote wijzigingen worden slechts eenmaal per jaar doorgevoerd; zie procedure Versies en updates)

CAB indien

Wijzigingen in uitvoering zijn altijd gekoppeld aan een bepaalde Aquo-versie (zie procedure Versies en updates).

In het stroomschema wordt duidelijk gemaakt hoe een wijzigingsaanvraag wordt afgehandeld. In dit schema wordt aangegeven welke rollen betrokken zijn en welke activiteiten worden uitgevoerd. De volgende aanvullende opmerkingen over het wijzigingsproces kunnen hierbij gemaakt worden:

• Voor kleine wijzigingen geldt een meldingsplicht naar de gebruikers. De wijzigingen worden hiervoor geregistreerd en samen met de update van de standaard naar de gebruikers gecommuniceerd. Op deze manier worden tussentijdse wijzigingen inzichtelijk gemaakt.

• Resultaten van werkgroepen (nieuwe ontwikkelingen / onderdelen standaard) worden na oplevering behandeld als wijzigingsvoorstel en ingeschaald op basis van hun impact. De ingediende resultaten doorlopen vervolgens het reguliere wijzigingstraject.



3.5.1 Schema verwerken van een wijzigingsvoorstel

Programma Manager i.s.m. Stuurgroep

CAB

Tactisch overleg i.s.m. Regiegroep

Operationeel Overleg

Servicedesk

Indieners Wijzigings aanvraag

(RfC) 1

RfC Compleet?

3

Instellen

CAB 6

Opstellen

Advies 7

Inhoudelijk Beoordelen

+ Comm. plan 4

CAB instellen?

5

Wijziging akkoord?

8

Doorvoeren

Wijziging 14

Wijziging inpasbaar?

9

Terugmelding

status 15

Terugmelding status en voortgang

Past in werkplan ?

10

plannen in Versie of Update

13

Reserveren

budget 12

Budget beschikbaar?

11

Ja

Ja

Ja

Ja

Ja

Ja

Nee

Nee Nee

Nee

Nee

Nee

Registratie "Wijzigings aanvraag”

Afwijzen Wijziging

Uitstellen Wijziging

Afsluiten Wijziging

2 2a 2b 2c

impact=klein, wijziging=akkoord

Gebruikers Openbare Consultatie



Stap Beschrijving

1 De gebruiker dient een wijzigingsvoorstel / Request for Change (RfC) in bij de Servicedesk,

2 De Servicedesk registreert het wijzigingsvoorstel.

3 Het Operationeel Overleg beoordeelt de Wijzigingsaanvraag (RfC) op volledigheid. Indien het volledig is wordt het in behandeling genomen.



Stap Beschrijving

NB Om de gebruiker te helpen een wijzigingsvoorstel compleet in te dienen zijn er een aantal richtlijnen opgesteld. Deze kan de gebruiker tevens als sjabloon gebruiken.

4/5 Het RfC wordt nu door het operationeel overleg inhoudelijk beoordeeld in samenwerking met deskundige gebruikers. De volgende acties worden uitgevoerd.

a. Het Operationeel Overleg toetst of de motivatie van het ingediende RfC voldoende is. Bij twijfel wordt eea bij gebruikers en leveranciers gecontroleerd die op het desbetreffende gebied deskundig worden geacht.

b. Het Operationeel Overleg toetst de inpassing van het RfC in de standaard. Hierbij wordt speciaal gelet op de koppeling met andere delen van de standaard en eventuele overlappingen. De impact van het RfC wordt beoordeel op basis van de impact analyse van de gebruikers en eigen inschatting. Zie definitie.

c. Kleine wijzigingen worden zonder advies aan de gebruikers te vragen doorgevoerd. Alle overige wijzigingen vragen om een reactie van de gebruikers en worden als ‘openbare consultatie’ via de IDsW website gepubliceerd.

d. Het Operationeel Overleg stelt een advies op voor de regiegroep / adviesraad en een eventuele CAB. Dit advies bevat tenminste een inschatting van de impact, inpasbaarheid en algemeen nut van het RfC. Verder worden de eventuele reacties van gebruikers opgenomen in het advies.

e. Het Operationeel Overleg overweegt of het noodzakelijk is om het ingediende voorstel eerst te toetsen via een pilot bij enkele ‘kern’ gebruikers van het onderdeel van de standaard waarop het voorstel betrekking heeft.

f. In overleg met de Adviseur Communicatie wordt een beknopt communicatieplan wordt opgesteld.

Naar aanleiding van de inhoudelijke beoordeling en de reacties van de gebruikers wordt besloten om al dan niet een CAB in te stellen. De status van de RfC verandert niet.

6 De CAB wordt door het Tactisch Overleg in nauwe samenwerking met het operationeel overleg samengesteld en vastgesteld door de regiegroep. Zie ook de procedure instellen_CAB

7/8 De CAB beoordeelt het ingediende RfC en weegt daarbij de argumenten voor en tegen het RfC tegen elkaar af. Hieruit volgt een advies wat aan de regiegroep wordt voorgelegd.

Op basis van alle reacties en overlegstandpunten wordt door de CAB en het tactisch overleg een definitief oordeel gevormd. Dit oordeel van het werkveld wordt als advies opgestuurd aan de secretaris van de regiegroep. De CAB is gemandateerd door de regiegroep om besluiten te nemen over een wijzigingsvoorstel. De regiegroep wordt altijd formeel ingelicht over een oordeel en bij escalatie (onenigheid, conflicten) ingeschakeld. De laatste escalatiestap is de stuurgroep.

Indien het RfC in zijn geheel niet akkoord wordt bevonden volgt een afwijzing van het RfC. De Indiener van de RfC wordt hiervan op de hoogte gesteld.

9 Het is mogelijk dat een RfC als zodanig wel akkoord is, maar dat de inpassing in de standaard op dit moment niet gewenst is. Als gevolg hiervan wordt het RfC uitgesteld totdat inpassing van het RfC wel mogelijk is. Kan het RfC wel worden ingepast in de standaard dan kan de inpassing in het werkplan en de uitvoering



Stap Beschrijving

van het RfC worden opgestart.

10 Het tactisch overleg beoordeelt of de uitvoering van het RfC past binnen het werkplan (tijd; budget). Indien het voorstel past, dan wordt de wijziging gepland. Past het voorstel niet, dan wordt het voorstel voorgelegd aan de stuurgroep.

11 De stuurgroep bepaald of er budget beschikbaar is voor de uitvoering / doorvoering van het RfC. Is er geen budget beschikbaar, dan wordt de RfC uitgesteld tot een andere versie. Is er wel budget beschikbaar dan kan het RfC worden ingepast in de planning.

12 De stuurgroep regelt in samenspraak met de programma manager het budget voor de uitvoering van het RfC.

13 Het operationeel overleg plant het RfC in volgens de procedure Versies en updates en indien dit bestaat uit meerdere (deel) RfC’s dan worden deze van prioriteit voorzien in overleg met de indiener.

14 Het RfC wordt doorgevoerd door het operationeel overleg. De wijze waarop het RfC wordt doorgevoerd is afhankelijk van het product waarop dit betrekking heeft.

Zie hiervoor deelprocedure Doorvoeren RfC.

Zowel de gebruiker, als de regiegroep en stuurgroep krijgen een terugmelding over de uitvoering van de RfC.

Aan het eind van de uitvoering wordt met de met de gebruiker gecontroleerd of het RfC naar wens is uitgevoerd. Alle bij het voorstel betrokken personen worden ingelicht, de Call wordt afgesloten in het registratie systeem en de CAB wordt tijdelijk geschorst.


In deze procedure worden de volgende rollen, taken en verantwoordelijkheden gedefinieerd:




Dient een wijzigingsvoorstel in wat voldoet aan de daartoe gestelde eisen in het desbetreffende sjabloon. NB: Ook leden van het programma bureau kunnen wijzigingsaanvragen indienen.

Servicedesk Registreert het voorstel en communiceert de status daarvan terug naar de indiener.

Operationeel overleg Voert de beoordeling uit van het voorstel en voert de wijziging na goedkeuring uit.

Gebruikers Reageren op openbare consultatie door het insturen van reacties en zijn indien noodzakelijk beschikbaar om de gegeven reactie in een CAB verder te onderbouwen.

Regiegroep / Tactisch overleg

Dragen zorg voor het instellen van een CAB en beoordelen de inpasbaarheid van het voorstel.

Zorgt voor inplanning van de wijziging in een bepaalde versie of update van de standaard.



CAB Stelt een advies op ten aanzien van het wijzigingsvoorstel

Stuurgroep Beoordeelt of er budget is voor het doorvoeren van de wijziging indien deze niet in het reguliere werkplan valt of zorgt ervoor dat er budget beschikbaar komt.

3.5.4 Performancecriteria

Responstijden en bewaking


Klant informeren over doorlooptijd

Na beoordelen van de impact van het wijzigingsvoorstel door de servicedesk, informeert de servicedesk de klant over de doorlooptijd.




na registratie beoordelen of de impact van het wijzigingsvoorstel ‘klein’ is en direct kan worden doorgevoerd of ‘middel’/‘groot’ is.

Melding van registratie wijzigingsvoorstel door servicedesk aan toegewezen behandelaar.

Na registratie van het wijzigingsvoorstel, meldt de Servicedesk de registratie van het wijzigingsvoorstel aan de aangewezen behandelaar - in de 2de of 3de lijn - en draagt daarmee ook de verantwoordelijkheid van de afhandeling over.

In alle gevallen geldt de normstelling van 100% binnen 2 werkdagen na registratie van het wijzigingsvoorstel.

Melding van escalatie door 2de lijn aan 3de lijn .

Bij doorvoeren van een wijzigingsvoorstel kan door de 2de lijn een 3de lijns behandelaars worden ingeschakeld. Responstijden zijn hier niet benoemd omdat ze door 2de en 3de lijn onderling worden afgesproken.

nvt

Bewaking doorlooptijd

Controle of afgesproken doorlooptijd van de wijziging niet is overschreden.

In alle gevallen geldt de normstelling wekelijks te controleren met het registratiesysteem.

Intern informeren over voortgang

De 2de of 3de lijns ondersteuning is verantwoordelijk voor het informeren van de 1ste respectievelijk 2de lijn omtrent voortgang en afronding van wijzigingen.

In alle gevallen geldt de normstelling van 100% binnen 2 werkdagen na relevante acties

Registratie voortgang

De servicedesk is verantwoordelijk voor het op globaal niveau bijhouden

In alle gevallen geldt de normstelling van 100% binnen 2 werkdagen.




van de voortgang en afronding van wijziging in het registratiesysteem op aangeven van de 2de lijns.

Indien mogelijk krijgt de 2de

lijn toegang tot het registratiesysteem, in dat geval ligt ook de verantwoordelijkheid bij de 2de lijns.

Afhandeling


Behandelingstijden De tijden waarop wijzigingsvoorstellen kunnen worden afgehandeld.

De behandelingstijden zijn minimaal gelijk aan de openingstijden van de servicedesk.

Doorlooptijd De tijd tussen het melden van een wijzigingsvoorstel en het doorvoeren van de wijziging in de standaard. .

Voor de doorlooptijd geldt een normstelling die afhankelijk is van de impact:

- Klein: 5 werkdagen, tenzij anders overeengekomen met de indiener

− Middel: - minimaal 4 maanden - maximaal 10 maanden, tenzij het noodzakelijk is dat een CAB wordt ingesteld.

− Groot: veelvoud van half jaar (update cyclus Aquo), afhankelijk van planning en werkzaamheden CAB.

Publicatietijd De tijd tussen doorvoeren van de wijziging in de standaard en publicatie van de gewijzigde standaard.

Voor de publicatietijd geldt een normstelling die afhankelijk is van de impact:

- Klein: 5 werkdagen - Middel/Groot: maximaal 1 maand.



3.6 Procedure: Aquo update

Versiebeheer is nodig voor het bijhouden van wijzigingen op de Aquo-standaard. Doel hierbij is het bieden van een overzicht van de wijzigingen in de tijd. Op de website wordt een overzicht gegeven van de meest recente versies.

Updatecyclus Aquo

Voor de Aquo-standaard – als geheel van de onderliggende onderdelen - worden twee updatecycli onderscheiden. Eén halfjaarlijkse cyclus voor middelgrote wijzigingen en een jaarlijkse cyclus voor grote wijzigingen. Zie voor de cycli onderstaand tijdschema.

MIDDELGROOT GROOT

Juli /aug indienen indienen

sept Completeren completeren

Okt / nov Commentaar op concept

wijzigingsvoorstellen door Aquo-

gebruikers

Commentaar op concept


gebruikers

Dec Doorvoeren wijzigingen Verwerken commentaar

gebruikers

Jan/feb Indienen Reageren op definitieve


gebruikers

maart completeren Instellen CAB (indien van

toepassing)

Apr/mei Commentaar op concept


gebruikers

Definitief maken

juni Doorvoeren wijzigingen Doorvoeren wijzigingen



Figuur: Updatecyclus (Links: middelgrote wijzigingen; rechts: grote wijzigingen)

Er is voor gekozen om de updatecyclus voor grote wijzigingen te laten starten in juli in plaats van januari. Door deze keuze komt de druk van de implementatie niet te liggen bij de eerste maanden van het jaar, waar ook de rapportagedruk voor waterbeheerders hoog is en waar wijzigingen in de standaard niet zijn gewenst. Er wordt naar gestreefd om grote wijzigingen voor een bepaald onderwerp / onderdeel te bundelen zodat niet jaarlijks, maar eens in de 3 tot 5 jaar voor een bepaalde sector een grote wijziging is te verwachten. IDsW zal jaarlijks een meerjarenplanning uitgeven voor grote wijzigingen.

De versie naam van de Aquo-update is gerelateerd aan de periode waarin zij beschikbaar komen. Zij hebben dan de volgende ‘versienaam’ Aquo versie <jun/dec><jaar>’.

De algemene versienummering van de onderdelen van de Aquo-standaard is als volgt:

Versie nr. Omschrijving Impact Opmerking

x Hoofdversie nummer

Groot Een nieuwe hoofdversie, wordt uitgebracht als er duidelijk een andere versie is ontstaan door de wijzigingen die sinds de start van de vorige hoofdversie doorgevoerd zijn.

x.x Subversie nummer

Middelgroot Een subversie wordt uitgebracht als de doorgevoerde wijzigingen een impact kunnen hebben op het gebruik van de betreffende Aquo-standaard.

x.x.x Interne doornummering bij kleine wijzigingen tussentijds

Klein Interne doornummering wordt gebruikt bij kleine wijzigingen tussentijds die geen of een lage impact hebben voor de betreffende Aquo-standaard. Onder kleine wijzigingen worden gerekend: herstel van kleine fouten, uitbreiding van een entiteit met een extra attribuut, toevoeging van een domeinwaarde.

De wijziging met de grootste impact bepaalt op welk niveau de versienummering verandert.



Bijlage A Huishoudelijk Reglement Regiegroep en Adviesraad IDsW

Artikel 1 - Begripsbepalingen

Stuurgroep Bestuursorgaan samengesteld uit vertegenwoordigers van de participerende koepels en verantwoordelijk voor de inzet van mensen en middelen in het programmabureau. De stuurgroep stelt het werkplan van het bureau vast.

Adviesraad Een bijeenkomst van alle betrokkenen (medewerkers van overheden en leveranciers) bij de producten van de Informatiedesk standaarden Water. Zij representeert de klant van IDsW. Het programmabureau kan advies vragen bij de adviesraad.

Leden De leden van de adviesraad zijn een representatieve vertegenwoordiging van de in IDsW participerende koepels. Leveranciers zijn geen lid.

Regiegroep Dagelijks bestuur van de adviesraad. De stuurgroep en het programmabureau worden gevraagd en ongevraagd geadviseerd door de adviesraad via de regiegroep.

Huishoudelijk reglement Beschrijft de dagelijkse werking van een orgaan. Het heeft betrekking op de interne werking, procedures en gewoonten.

Programmabureau De medewerkers van IDsW, verantwoordelijk voor het beheer van de standaard en de uitvoering van het werkplan in opdracht van de stuurgroep.

IDsW organisatie Deze bestaat uit adviesraad/regiegroep, programmabureau en stuurgroep.

Artikel 2 - Algemene vergadering van de adviesraad

Werkwijze van de adviesraad

De adviesraad komt minimaal twee keer per jaar bijeen om relevante onderwerpen binnen IDsW te bespreken om vervolgens de stuurgroep IDsW te adviseren. Adviezen worden opgesteld met meerderheid van stemmen van de leden.

De organisatoren van de regiegroep bereiden deze bijeenkomsten voor. De adviesraad houdt zich op de hoogte van relevante zaken door het onderhouden van contacten met de achterban. De adviesraad verzorgt zo nodig voorlichting en publiciteit rond relevante onderwerpen, ondersteund door de promotor van de regiegroep.

Wijze van uitnodigen.

De regiegroep schrijft minimaal twee keer per jaar een adviesraad bijeenkomst uit. Op verzoek van minimaal drie regiegroepleden kan een extra bijeenkomst worden belegd.



De oproep voor de adviesraadbijeenkomst wordt minimaal 4 weken van tevoren geplaatst op de IDsW website. Minimaal drie weken voor de bijeenkomst wordt de schriftelijke uitnodiging rondgestuurd.

Ook op verzoek van de stuurgroep/programmabureau IDsW kan een vergadering worden uitgeschreven.

Instelling van werkgroepen

Op advies van de regiegroep kan het programmabureau besluiten tot het instellen van een werkgroep met een bepaald omschreven doel. De werkgroep rapporteert aan het programmabureau.

Instelling van Change Advisory Boards

Op advies van de regiegroep kan het programmabureau besluiten tot het instellen van een CAB. De CAB rapporteert in principe aan het programmabureau. Wijzigingsvoorstellen met een hoge impact worden ook aan de regiegroep voorgelegd.

Artikel 3 - Regiegroep

De adviesraad benoemt uit haar midden de leden van de regiegroep. De regiegroep kan zelf nieuwe leden voorstellen. Deze voorstellen moeten gesteund worden door drie leden van de adviesraad. Benoeming van de regiegroepleden vindt plaats in de adviesraad bij meerderheid van stemmen.

Nieuwe kandidaten moeten minimaal 2 weken voor de bekendmaking van de adviesraad vergadering bij de secretaris worden aangemeld.

Samenstelling van de regiegroep

De leden van de regiegroep zijn een representatieve vertegenwoordiging van de in IDsW participerende koepels. De adviesraad kiest uit haar midden een voorzitter voor de regiegroep.

Leden van het programmabureau IDsW, voorzitters van werkgroepen en andere deskundigen kunnen als adviseurs worden uitgenodigd. Zij hebben geen stemrecht.

De regiegroep bestaat uit:

• een voorzitter • een secretaris • twee organisatoren • twee productdeskundigen • twee beleidsadviseurs • een promotor

Het regiegroeplidmaatschap eindigt twee jaar na het moment van aantreden of op eigen verzoek. Om de continuïteit te waarborgen treedt slechts de helft van de regiegroep af. Ontslag van een regiegroeplid vindt plaats in een vergadering waarin de voltallige regiegroep aanwezig is.



Taken van de regiegroep

De regiegroep adviseert gevraagd en ongevraagd de stuurgroep en het programmabureau. De regiegroep handelt in de doelstellingen van de IDsW organisatie.

Taken van de voorzitter

De voorzitter leidt de vergaderingen van de regiegroep en de adviesraad. De voorzitter is verantwoordelijk voor de adviezen van de regiegroep aan de stuurgroep en het programmabureau namens de adviesraad. De voorzitter vertegenwoordigt de adviesraad naar buiten.

De voorzitter stelt samen met de secretaris de agenda op voor de regiegroep/adviesraad vergaderingen.

Taken van de secretaris

De secretaris is medewerker van het programmabureau IDsW.

De secretaris houdt de notulen van de bijeenkomsten bij. Deze worden na goedkeuring door de regiegroep/adviesraad vergadering door de secretaris en voorzitter ondertekend. De secretaris voert de briefwisseling uit naam van de regiegroep/adviesraad. De secretaris houdt de adressenlijst bij van de adviesraad/regiegroep. De secretaris stelt het eindejaarsverslag op. Bij afwezigheid van de voorzitter neemt de secretaris diens functie waar. De secretaris treedt, zolang de waarneming duurt, in alle rechten en plichten van de voorzitter.

De secretaris plaatst de aankondigingen van de vergaderingen op de IDsW website. Tevens stuurt de secretaris de schriftelijke uitnodigingen rond.

Taken van de overige leden

De beleidsadviseurs bewaken het beleid van het programmabureau en toetsen dat aan de ervaringen die worden geuit in de adviesraad en de stuurgroep.

De productdeskundigen geven adviezen over de IDsW producten. Zij bereiden de inhoudelijk adviezen aan de stuurgroep en het programmabureau voor.

De organisatoren bereiden de bijeenkomsten van de adviesraad inhoudelijk voor.

De promotor is de schakel tussen de werkgroep communicatie van IDsW en de adviesraad/regiegroep. Hij adviseert de adviesraad/regiegroep bij communicatieactiviteiten.

Artikel 4 Werkwijze IDsW organisatie

Het programmabureau is belast met de uitvoering van de werkzaamheden vastgelegd in het werkplan IDsW. De stuurgroep van IDsW prioriteert de werkzaamheden en zet middelen in. De regiegroep adviseert gevraagd en ongevraagd de stuurgroep en het programmabureau IDsW.



Artikel Slotbepaling

1. In alle gevallen waarin dit reglement niet voorziet, beslist de regiegroep IDsW.

2. Dit reglement is vastgesteld door de stuurgroep IDsW. Wijzigingen worden altijd voorgelegd aan de stuurgroep van IDsW en door de stuurgroep vastgesteld.



Bijlage B Reglement Change Advisory Board (CAB)

Doel en opzet:

• Een CAB wordt ingesteld door de regiegroep-adviesraad en de samenstelling heeft een permanent karakter;

• Optreden als adviserend orgaan naar de IDsW, ten behoeve van het opstellen van een advies/oordeel over een ingediend wijzigingsvoorstel;

• In het CAB komen alle wijzigingen behalve de routine wijzigingen aan de orde; • De aandacht in het CAB richt zich met name op de major changes;

Verantwoordelijkheden:

• Het CAB streeft er in de regel naar het advies voor te bereiden tot een niveau, waarop snelle accordering door de regiegroep-adviesraad mogelijk wordt;

• Het CAB is een belangrijk orgaan in het wel of niet doorgang laten vinden van binnengekomen wijzigingsvoorstellen en de wijze waarop; De regiegroep-adviesraad mandateert de CAB om over voorstellen te adviseren/oordelen en zodoende wordt er zwaar op dit oordeel geleund;

• Het CAB bewaakt de voortgang van de reeds in gang gezette wijzigingen;

Focus voor de CAB-leden:

• Functionaliteit • Architectuur • Beveiliging • Beheer

Wijzigingen:

• Wijzigingen hebben niet alleen betrekking op de standaarden maar ook op de procedures, de diensten en de rapportages;

• Het CAB zal opereren aan de hand van een basisadministratie (statuslijst) van wijzigingsvoorstellen en lopende wijzigingen;

• De lijst zal de status en de prioriteit bevatten; • Een CAB wordt globaal per aandachtgebied ingesteld door de regiegroep-adviesraad;

Samenstelling CAB:

De CAB zal bestaan uit, zo veel mogelijk, een vaste groep mensen en per wijzigingsvoorstel een mogelijk aantal specifieke betrokkenen die dienen te worden geconsulteerd. Leden kunnen zijn:

• Indiener(s) • IDsW • Waterbeheerders • Leveranciers (formeel als agendaleden)



Relaties met:

• Regiegroep-adviesraad: Is de formele opdrachtgever van de werkgroep. Keurt de samenstelling goed en ontvangt de uitkomsten/producten van de CAB.

• Werkgroep: Vrijwillige medewerkers die samen een opdracht van de regiegroep uitvoeren. De werkgroep levert zelf een voorzitter en secretaris. Het is niet de bedoeling dat leden erg veel tijd kwijt zijn, naast de enkele bijeenkomsten van de werkgroep. Mocht er een substantiële hoeveelheid werk liggen dan moet ondersteuning via de regiegroep worden aangevraagd. Het eindproduct van de werkgroep kan zijn een wijzigingsvoorstel.

• IDsW : faciliterende en adviserende rol. Is de coördinator van de betrokken partijen en uitvoerder van de eventuele hieruit voortvloeiende wijzigingsvoorstellen.



Bijlage C Reglement Werkgroep (WG)

Doel en opzet:

• Een WG wordt ingesteld door de regiegroep-adviesraad en de samenstelling heeft een eenmalig en eindig karakter. Regiegroep keurt de samenstelling goed en ontvangt de uitkomsten/producten van de werkgroep.

Verantwoordelijkheden:

• Voert een specifieke opdracht uit van de regiegroep-adviesraad. • werkt nauw samen met partijen uit het werkveld. • bereidt evt. wijzigingsvoorstellen voor op Aquo. • definieert nieuwe entiteiten en attributen • bereid het instellen van een CAB voor (indien nodig) • biedt evt. wijzigingsvoorstellen aan de CAB

Focus voor de WG-leden:

• Functionaliteit • Architectuur • Beveiliging • Beheer

Samenstelling WG:

• De werkgroepleden zijn vrijwillige medewerkers die samen een opdracht van de regiegroep uitvoeren.

• De werkgroep levert zelf een voorzitter en secretaris. Het is niet de bedoeling dat leden erg veel tijd kwijt zijn, naast de enkele bijeenkomsten van de werkgroep.

• Mocht er een substantiële hoeveelheid werk liggen dan moet ondersteuning via de regiegroep worden aangevraagd.

• Het eindproduct van de werkgroep kan zijn een wijzigingsvoorstel.

Relaties met:

• Regiegroep-adviesraad: Is de formele opdrachtgever van de werkgroep. Keurt de samenstelling goed en ontvangt de uitkomsten/producten van de CAB.

• CAB: Is de beoordelaar van wijzigingsvoorstellen. Deze groep besluit (gemandateerd door de regiegroep) of een voorstel wordt doorgevoerd door de IDsW.

• IDsW: Heeft een faciliterende en adviserende rol. Is de coördinator van de betrokken partijen en uitvoerder van de eventuele hieruit voortvloeiende wijzigingsvoorstellen. Diensten: o Beschikbaar stellen website pagina voor deze werkgroep o Vergaderruimte regelen o Leveren van evt. projectleiding uitvoering o Advies over Aquo o Ondersteuning bij evt. externe inhuur o Coördinatiefunctie IDsW organisatie



Bijlage D Toelichting op de Aquo-standaard

D.1 Toelichting op de Aquo onderdelen

1. Aquo-lex en 2. Aquo-domeinen

Het waterwoordenboek Aquo-lex voorkomt spraakverwarringen. Het geeft voor zo’n 8.000 begrippen uit het waterbeheer eenduidige definities, afkorting en toelichting. De diverse begrippen kunnen ruwweg in drie categorieën worden onderverdeeld:

• Begrippen die in andere onderdelen van de standaard terugkomen en daardoor definiërend zijn voor de informatie uitwisseling tussen partijen en systemen

• Begrippen die de-facto standaard zijn of in wetgeving terugkomen zoals die uit de Kaderrichtlijn Water of de Hydrologie

• Begrippen die het beheerproces ondersteunen en in rapportages gebruikt kunnen worden voor de definitie en toelichting van bepaalde processen uit het waterbeheer.

Domeintabellen zijn lijsten met toegestane waarden voor een bepaald informatie element (attribuut). Binnen de gegevensmodellering/uitwisseling spelen domeintabellen een centrale rol. De Aquo-standaard bevat honderden domeintabellen waaronder de Taxa Waterbeheer Nederland (> 16.500 organismen) en de Chemische stoffen (> 3.000).

3. IMWA, 4. UM Aquo en 5. OpenMI

De uitwisselmodellen/formaten IMWA en UM Aquo maken het mogelijk om informatie op een gestructureerde (en verifieerbare) manier uit te wisselen tussen waterbeheerders. Hierbij is IMWA (InformatieModel Water) het model voor de uitwisseling van geografische gegevens en UM Aquo voor de meer administratieve/rapportage verplichtingen. Momenteel zijn in UM Aquo en IMWA de volgende uitwisselingen opgenomen:

• Watertoets informatie van waterbeheerders naar provincie/gemeente (IMWA) • Generieke geografische uitwisseling (IMWA) • Kaderrichtlijn Water rapportages (UM Aquo) • Meet- en monitoring gegevens en resultaten (UM Aquo) • Normen voor het waterbeheer (UM Aquo) • Vergunning aanvraag/verlening Waterwet (UM Aquo; in ontwikkeling)

OpenMI is een uit een Europees project voortvloeiende standaard voor het aan elkaar koppelen van modelinstrumenten voor berekening van bijvoorbeeld waterkwantiteit en overstromingen. Deze standaard is in 2006 bij IDsW in beheer gegeven.

6. Logisch Model Aquo

Het LM Aquo is een beschrijving van objecten, hun kenmerken en de relaties tussen de verschillende objecten uit het waterbeheer. De indeling/clustering is gebaseerd op de werkprocessen van de waterschappen en omvat o.a. waterbeheer, zuiveringsbeheer, monitoring maar ook vergunningverlening en belastingheffing. Het Logisch Model Aquo vormt de basis voor het waterschapsinformatiesysteem IRIS en is daarmee met name geschikt voor de opslag van proces gerelateerde informatie.



D.2 Indeling naar werkproces

Inwinnen

Om iets te kunnen zeggen over de bruikbaarheid en kwaliteit van de ingewonnen gegevens is het van belang om iets te weten over de meetmethode, de grondslagen onder de meetmethode en de eenheden en grootheden waarin meetgegevens zijn opgesteld.

Valideren

Het valideren van gegevens doet men door ruwe data te controleren op plausibiliteit, juistheid en volledigheid. Daarnaast kunnen gegevens ook gevalideerd worden of ze binnen een bepaald waardebereik of domein vallen.

Vastleggen/aggregeren

Om gegevens met elkaar te kunnen vergelijken, combineren en te analyseren dient men eenduidige gegevensvormen, logische begrippen en structuur van data te hanteren die in onderlinge samenhang in een informatiemodel zijn weergegeven.

Distribueren/raadplegen

Meta-informatie is die informatie die inzicht geeft in hoe, door wie en wanneer gegevens zijn ingewonnen, gevalideerd en vastgelegd. Deze informatie over de informatie wordt vastgelegd zodat iemand die de data raadpleegt weet hoe deze tot stand is gekomen. Meta-informatie wordt in alle processtappen vastgelegd maar wordt pas voor het eerst echt noodzakelijk als de data daadwerkelijk wordt gebruikt waarvoor het aan de voorkant van de keten is ingewonnen.

Het beschikbaar stellen van gegevens ten behoeve van raadpleging kan leiden tot interne of externe uitwisseling van datasets tussen informatiesystemen.



Om deze uitwisseling van informatie tussen informatiesystemen mogelijk te maken, dienen standaarden te worden afgesproken op basis waarvan gegevens kunnen worden uitgewisseld. Voorbeelden van dit soort standaarden zijn de technische standaarden GML (Geography Markup Language), XML (Extensible Markup Language) en StUF (Standaard Uitwisseling Formaat).

Bewerken/verrijken

In sommige gevallen dienen gegevens volgens een bepaalde standaardwijze te worden bewerkt om deze later te kunnen/mogen gebruiken voor bepaalde analyses. Er kunnen afspraken gemaakt zijn over de vorm, de methode of welke eigenschappen bewerkt mogen worden. Een andere vorm van het bewerken van data is het plaatsen van data in bepaalde klassenindelingen. Als men bij het combineren van gegevens verschillende bewerkingsvormen gebruikt, (bijvoorbeeld in de afronding van getallen) kunnen hierdoor fouten sluipen in de gecombineerde data, hierdoor kunnen onzichtbare onnauwkeurigheden in analyses worden geïntroduceerd. Dit maakt sommige analyses onbetrouwbaarder dan ze op het eerste gezicht lijken.

Voor het vergelijken of combineren van gegevens in de analyse of presentatie, is het noodzakelijk afspraken te maken welke klassenindeling men gebruikt.

Analyseren van data

Het is noodzakelijk om herleidbare gegevensanalysemethoden toe te passen om consistente wijze van integrale rapportages te borgen. Dit kan betekenen dat bepaalde gegevensanalysemethoden worden geharmoniseerd voor bepaalde rapportages.

Presenteren van data

Bij het presenteren van data is het belangrijk dat gebruikte symbolen en kleuren bekend zijn bij diegenen die de kaarten moeten lezen. Dit geldt zeker als gelijksoortige kaarten over verschillende gebieden vergeleken dienen te worden. Hierbij valt te denken aan gebruikte symbolen, kleuren, kaartschaal klassenindelingen (bijvoorbeeld gradueel of stapsgewijs), lijntypen, lijndikte, maar ook gebruikte eenheden.

Ook van de wijze van het rapporteren van gegevens in rapporten of op websites kan worden verlangd dat het op een gelijkvormige manier wordt gepresenteerd. Hier kan gedacht worden aan het afrondingsniveau van gegevens of de gebruikte klassenindeling.

D.3 Indeling naar doelen

De volgende doelen zijn voor IDsW en de Aquo-standaard geschetst: • waterinformatie baseren op sectorbrede basisgegevens • elkaars taal kunnen verstaan en watergegevens kunnen lezen • gegevenskwaliteit en directe bruikbaarheid kunnen garanderen • waterinformatie waterketen breed op één punt kunnen vinden en bieden • waterinformatie eenduidig en tijdig laten rouleren • waterinformatie betekenisvol kunnen gebruiken • waterinformatie vergelijkbaar verantwoord kunnen presenteren.



Waterinformatie baseren op sectorbrede basisgegevens

Momenteel wordt door IDsW geen ‘basisregistratie’ onderhouden; wel levert IDsW de belangrijkste ingrediënten daarvoor. De verschillende onderdelen van de Aquo-standaard zijn onderling allemaal op elkaar afgestemd en gebruiken daarbij dezelfde definities en domeintabellen waar mogelijk.

Afstemmening met aanpalende velden zoals de basisregistraties vind plaats om ervoor te zorgen dat de verschillende standaarden en definities op elkaar aansluiten.

Elkaars taal kunnen verstaan en watergegevens kunnen lezen

Dit doel zit in het hart van de huidige Aquo-standaard. Dit is ook te zien aan de componenten die bijdragen aan dit doel. De Aquo-lex, het logische opslagmodel, IMWA, parameterlijsten en domeintabellen zijn allemaal onderdeel van de taal van de watersector. Iets wat nog wel dient te gebeuren, is deze taal te bestendigen aan de Europese INSPIRE-richtlijn die ook zijn invloed op de watersector zal hebben.

Gegevenskwaliteit en directe bruikbaarheid garanderen

Momenteel garandeert IDsW niet de gegevenskwaliteit en directe bruikbaarheid. Wel beheert IDsW de metadata formats voor de aanlevering van watergegevens richting Inspire zodat deze eenvoudig vergelijkbaar zijn tussen de verschillende waterbeheerders.

Waterinformatie in de waterketen breed op één punt kunnen vinden en bieden

De Aquo-standaard heeft nu al 2 informatiemodellen die zijn ontwikkeld om transport van gegevens tussen organisaties mogelijk te maken; UM-Aquo en het uitwisselingsmodel water (IMWA). Het mogelijk maken van transport is een basisvereiste om het genoemde doel te realiseren. Daarnaast is een loket nodig; momenteel bied IDsW hiervoor geen voorzieningen.

Waterinformatie eenduidig en tijdig laten rouleren

Voor het eenduidig laten rouleren van de waterinformatie kunnen onder andere de parameterlijsten gebruikt worden; verder houd IDsW zich momenteel niet bezig met de regie op de informatievoorziening.

Waterinformatie betekenisvol kunnen gebruiken

De Kaderrichtlijn protocol toetsen en de Kaderrichtlijn water monitorrichtlijn geven aan welke eisen gelden voor de KRW-rapportage richting de EU (Brussel). Beiden zijn nu geen onderdeel van de Aquo-standaard maar zijn een handreiking aan de sector om ervoor zorg te dragen dat rapportages op een zelfde manier opgesteld worden en daarmee onderling vergelijkbaar zijn.

De praktijkrichtlijn geografie en geometrie behandelt een aantal basis onderwerpen rondom geografie en geometrie in de watersector. Ook geeft zij een aantal symbolen voor veel voorkomende objecten in de watersector.



Waterinformatie eenduidig vergelijkbaar verantwoord kunnen presenteren

De Aquo-kit is een instrumentarium voor het op gestandaardiseerde wijze vastleggen, distribueren en bewerken van gegevens bij de rapportages van de stroomgebiedbeheersplannen Daarnaast dragen de componenten, genoemd in de beschrijving van het vorige doel, ook bij aan dit doel. Hoewel de Aquo-kit geen onderdeel is van de door IDsW beheerde producten heeft deze (zoals uit de naam blijkt) daarmee wel nauwe banden.



Bijlage E Impactmatrix

Aquo-onderdeel

element Toevoegen Wijzigen Verwijderen

Begrip/Definitie Laag Middel Groot Afkorting/Synoniem Laag Laag Laag Eenheid/Taal/ Toelichting/Bron Laag Laag Laag

Aquo-lex

Overig Laag Laag Laag Domeintabel Laag Middel Groot Domeinwaarde code Laag Groot Groot Domeinwaarde code omschrijving Laag middel Groot Domeinwaarde code omschrijving indien sleutelveld in een XSD

Laag Groot Groot

Aquo-domeintabellen

Aanvullende domeinwaarde informatie. Laag Laag Laag Entiteit Middel Groot Groot Entiteit code Groot Groot Entiteit definitie Middel Groot Entiteit toelichting Laag Laag Laag Entiteit Bron Laag Laag Laag Entiteit Onderdeel CIW standaard Laag Entiteit Grafische primitief Laag Laag Laag Entiteit Representatie in het LMA Laag Laag Laag Entiteit Representatie IMWA en UMaquo Laag Groot Groot Entiteit Geometriebepaling Laag Laag Laag Entiteit Meetkundige referentie Laag Laag Laag Entiteit kenmerk (attribuut) Middel Groot Groot Entiteit cardinaliteit Middel Groot Groot Entiteit Relatie Middel Groot Groot - Attribuut Middel Groot Groot - Sub/supertype Middel Groot Groot - Entiteit Middel Groot Groot ERD (Entiteit cluster) Groot Groot Groot Attribuut Middel Groot Groot Attribuut code Middel Groot Groot Attribuut definitie Middel Middel Groot Attribuut bron Laag Laag Laag Attribuut toelichting Laag Laag Laag Attribuut identificatie Middel Attribuut type Middel Middel Attribuut lengte, onderdeel standaard specifiek

Middel klein

Attribuut domein Middel Groot Groot Attribuut relatie Middel Groot Groot

Aquo modellen: - LM Aquo - IMWA - UM Aquo

- Entiteit Middel Groot Groot Nieuw product Groot Groot

(vervangen) Groot

Foutherstel in Aquo begrip/definitie: impact = laag?

Handboek Beheer en Onderhoud Aquo-standaard

Documents

Transcript of Handboek Beheer en Onderhoud Aquo-standaard