Bij het maken van een semantisch model voor het omgevingsloket Online is gebleken dat de modellering van Betrokkene in het RGBZ niet voldoet aan de eisen die vanuit het Omgevingsloket Online (OLO) gesteld worden.
Het OLO wil dat een aanvraag kan worden ingediend door medewerker namens een Vestiging of een Niet-natuurlijk persoon. Het is daarbij niet vreselijk relevant voor welke afdeling de medewerker werkt.
Vanuit het OLO is er dus behoefte aan een directe link van Medewerker naar Vestiging en Niet-natuurlijk persoon. Daarnaast kan het natuurlijk ook nuttig zijn om Organisatorische eenheden te onderkennen. Dit zou kunnen door de huidige relaties van Medewerker naar Organisatorische Eenheid te handhaven.
Een Organisatorische eenheid is nu gelinkt aan een Vestiging. Ook dit lijkt niet correct, omdat niet zozeer Vestigingen in Organisatorische Eenheden worden onderverdeeld, maar Maatschappelijke activiteiten.
Ad 1:
Constatering dat er een directe link van Medewerker naar Vestiging en Niet-natuurlijk persoon moet komen is onjuist. In het RGBZ wordt met Medewerkers bedoeld alléén medewerkers van organisatorische eenheden van organisaties die zaken behandelen. Dus niet medewerkers van andere organisaties zoals de externe initiatoren van zaken.
Indien de betrokkene bij een zaak een niet-natuurlijk persoon of vestiging is, kan het gewenst zijn de contactpersoon te kennen namens die betrokkene in die zaak. Deze kan dan worden opgenomen in ROL.
Ad 2:
Constatering dat organisatorische eenheid gelinkt moet worden aan Maatschappelijke Activiteit in plaats van Vestiging is niet juist. Een Organisatorische Eenheid is het deel van een functioneel afgebakend onderdeel binnen de organisatie dat haar activiteiten uitvoert binnen een Vestiging en die verantwoordelijk is voor de behandeling van zaken.
Als een functioneel afgebakend onderdeel van de organisatie haar activiteiten uitvoert in meerdere vestigingen dan wordt die uitgewisseld als evenveel organisatorische eenheden als die vestigingen.
Beste mensen,
Ik heb de bedoelingen van het RGBZ niet in twijfel willen trekken, maar wel een probleempunt onder de aandacht willen brengen dat optreedt voorafgaand aan het ontstaan van een zaak bij het indienen van een aanvraag. Het is handig om te weten welke persoon namens een organisatie een aanvraag heeft ingediend. Bij het Omgevingsloket Online bestaat deze behoefte in elk geval.
Het is zeer wel mogelijk dat het RGBZ niet de plek is om dit probleem te adresseren, maar dat dit moet worden opgelost in bijvoorbeeld het RSBG of in een nieuw nog te ontwikkelen sectormodel. Mijn voorkeur voor een de plek van de oplossing gaat nadrukkelijk uit naar het RSGB of het RGBZ, omdat de problematiek geldt voor alle sectoren in een gemeente.
De nu gekozen oplossing om contactpersonen vast te leggen binnen rol werkt voor het RGBZ maar is lastig te generaliseren naar andere domeinen, omdat het objecttype Rol nadrukkelijk een relatie legt tussen de door het RGBZ gedefinieerde objecttypen Zaak en Betrokkene.
Er is nog een reden waarom de huidige constructie in het RGBZ niet te generaliseren is. Het RGBZ stelt expliciet dat alleen organisatorische eenheden (en daarmee dus ook medewerkers) beoogd worden binnen organisaties die zaken behandelen. Daarmee ontbreekt een semantische modellering van de interne structuur van een Maatschappelijke Activiteit of Vestiging die geen zaken afhandelt.
Het lijkt mij goed om binnen RSGB en/of RGBZ te komen tot een constructie waarbij contactpersonen vastgelegd kunnen worden als iets in de geest van betrokkene zoals nu gedefinieerd in het RGBZ. Een dergelijke constructie kan dan eenvoudig hergebruikt worden in andere domeinen, bijv. het OLO en hoeft daar niet gedefinieerd te worden. Nu heb ik ervoor gekozen om voor het OLO een eigen variant op betrokkene te definiëren en dit lijkt me op den duur alleen maar verwarrend te werken.
Met mijn opmerking over de relatie tussen Organisatorische eenheid en Maatschappelijke activiteit stel ik de definitie van Organisatorische eenheid ter discussie. In de gegeven reactie wordt slechts de definitie uit het RGBZ herhaald. Ik heb nog steeds het gevoel dat een Maatschappelijke Activiteit het niveau is waarop een organisatie in organisatorische eenheden wordt verdeeld en dat het in de praktijk zeer goed mogelijk is dat medewerkers van één organisatorische eenheid werken in verschillende vestigingen. Denk bijvoorbeeld aan staffunctionarissen voor HRM of Administratie. Deze werken veelal binnen één organisatorische eenheid aangestuurd vanuit de hoofdvestiging die medewerkers neerzet in nevenvestigingen. Het opsplitsen van organisatorische eenheden naar Vestigingen leidt voor dit soort afdelingen tot een forse toename van de organisatorische eenheden die geen recht doet aan de hark van de organisatie. Ik zie graag op het bovenstaande een inhoudelijke reactie.
Met vriendelijke groet,
Maarten
Naar een Medewerker en Organisatorische Eenheid is vanuit het RGBZ gekeken door een "zakenbril", ja. Daarvoor is toendertijd bewust voor gekozen. Willen we breder kijken en daarmee het ook netter modelleren zoals Maarten voorstelt, betekent dit het opstellen van een informatiemodel voor personeel & organisatie. Of dit binnen het RGBZ /RSGB opgenomen moet worden laat ik even buiten beschouwing. Het ontwikkelen van een informatiemodel voor personeel & organisatie is nu gepland voor volgend jaar. Het bljkt dat er nu al behoefte is aan zo'n model. Graag wil ik ook van anderen horen of zij ook deze behoefte hebben. Dan kunnen we kijken hoe we een en ander gaan oppakken.
In de 'post' van Maarten spelen m.i. drie onderwerpen een rol: het fenomeen 'contactpersoon', de organisatiestructuur van niet-natuurlijke personen zijnde geen overheidsorganisatie, en de wijze waarop de organisatiestructuur van zaakbehandelende organisaties gemodelleerd is.
In deze reactie ga ik op het derde onderwerp in, op de andere reageer ik separaat omdat het m.i. drie verschillende onderwerpen zijn.
Ellen heeft al in een eerdere reactie aangegeven waarom er gekozen is voor 1:N-relaties tussen VESTIGING en ORGANISATORISCHE EENHEID en ORGANISATORISCHE EENHEID en MEDEWERKER. Daarbij hebben we de modellering van het GFO Zaken aangehouden omdat er geen aanleidingen waren daarin verandering aan te brengen.
Zie ook mijn reactie op de post van Rindert Dijkstra van 4-9-2009.
Voor alle duidelijkheid, beide objecttypen cq. dit deel van het RGBZ zijn slechts bedoeld voor het modelleren van de organisatie van de zaakbehandelende organisatie, veelal de gemeente. Dus niet voor het modelleren van afdelingen en medewerkers van willekeurige andere organisaties zoals die van de aanvrager van een Wabo-vergunning. Dat modelleren we niet en nergens, simpelweg omdat het niet te onderhouden is.
In de 'post' van Maarten spelen m.i. drie onderwerpen een rol: het fenomeen 'contactpersoon', de organisatie-structuur van niet-natuurlijke personen zijnde geen overheidsorganisatie, en de wijze waarop de organisatiestructuur van zaakbehandelende organisaties gemodelleerd is.
In deze reactie ga ik op het tweede onderwerp in, op de andere reageer ik separaat omdat het m.i. drie verschillende onderwerpen zijn.
Maarten stelt dat "een semantische modellering ontbreekt van de interne structuur van een Maatschappelijke Activiteit of Vestiging die geen zaken afhandelt" hetgeen hij als een probleem ziet. De constatering is terecht, ik zie het evenwel niet als probleem, integendeel. Het modelleren daarvan zou een probleem scheppen. Immers, hoe zijn wijzigingen hierin te onderhouden? Bedrijven zijn min of meer verplicht om wijzigingen in de gegevens van Niet-natuurlijke persoon, Maatschappelijke activiteit en Vestiging bij de Kamers van Koophandel aan te melden. Op basis daarvan houdt de KvK het NHR bij. Het NHR bemoeit zich niet met de interne organisatiestructuur van een dergelijk bedrijf. En dat is maar goed ook, zou tot een wezenlijke administratieve lastenverzwaring leiden. We willen met z'n allen nu juist het tegenovergestelde.
Niet doen dus. We volgen het NHR zodat we zeker weten dat de informatie betrouwbaar is. Als er in een contact met een dergelijk bedrijf behoefte is om meer vast te leggen (bijvoorbeeld bij de behandeling van een Wabo-aanvraag), dan kan dat in het kader van dat contact en worden de desbetreffende gegevens 'historisch' bij beeindiging van het contact. Situationeel kunnen dus gedetailleerdere bedrijfsgegevens vastgelegd worden maar altijd gekoppeld aan die situatie. Niet structureel dus niet in het RSGB.
In de 'post' van Maarten spelen m.i. drie onderwerpen een rol: het fenomeen 'contactpersoon', de organisatie-structuur van niet-natuurlijke personen zijnde geen overheidsorganisatie, en de wijze waarop de organisatiestructuur van zaakbehandelende organisaties gemodelleerd is.
In deze reactie ga ik op het eerste onderwerp in, op de andere reageer ik separaat omdat het m.i. drie verschillende onderwerpen zijn.
Ik leid uit de 'post' van Maarten af dat hij contactpersoon (ook) generieker wil modelleren om twee redenen:
1. omdat voorafgaand aan het ontstaan van een zaak bij het indienen van een aanvraag, het handig zou zijn om te weten welke persoon namens een organisatie een aanvraag heeft ingediend;
2. de nu gekozen oplossing om contactpersonen vast te leggen binnen rol werkt voor het RGBZ maar zou lastig te generaliseren zijn naar andere domeinen.
Ten aanzien van het eerste punt. Het RGBZ gaat over zaken, niet over andere contacten tussen overheids-organisatie en derden. Een zaak ontstaat veelal n.a.v. een aanvraag. I.h.k.v. de Wabo leidt elke aanvraag per definitie tot een zaak. Vanuit het zaakgericht werken is de aanvraag op zich geen object van behandeling, de zaak wordt behandeld. Niet voor niets is de eerste status van een zaak veelal 'aanvraag ontvangen'. De aanvraag is dan al ingeboekt als zaak. De aanvraag kan m.i. dan ook beschouwd worden als in te boeken zaak, alsof 'de zaakintaker alle gegevens van de zaak ingeklopt heeft (o.b.v. de aanvraag) maar nog niet op de enter-toets gedrukt heeft'.
Een Wabo-aanvraag laat zich m.i. dan ook prima uitwisselen o.b.v. het RGBZ. Sterker: zo zou het moeten.
Dan de behoefte om te weten welke persoon namens een organisatie een aanvraag heeft ingediend. Aangezien bedrijven die aanvragen indienen tegelijkertijd meerdere zaken kunnen hebben lopen en de contactpersoon per zaak kan verschillen, is de contactpersoon geen kenmerk van dat bedrijf maar van de zaak die dat bedrijf heeft lopen. Da's ook niet meer dan logisch, een contactpersoon is situationeel, zeker vanuit het perspectief van het RGBZ. Ook kan het zijn dat datzelfde bedrijf op meerdere wijzen betrokken is bij een zaak (meerdere rollen) en dat er per betrokkenheid cq. rol sprake is van een andere medewerker die eerste aanspreekpersoon is. Vandaar dat het fenomeen contactpersoon een kenmerk moet zijn van de relatie van het bedrijf met een zaak i.c. de ROL.
Dan het tweede punt, het lastig generaliseren van de RGBZ-contactpersoon-oplossing naar andere domeinen. Wellicht zouden er twee soorten contactpersonen onderscheiden kunnen worden: situationele en structurele. Een contactpersoon inzake een zaak is een typisch voorbeeld van het eerste. Is de zaak beeindigd dan verliest de contactpersoon zijn rol. Veranderingen daarin (vertrek medewerker e.d.) hoeven niet meer bijgehouden te worden. Aangezien de contactpersoon situationeel is, vereist dat ook een op die situatie gerichte modellering. Binnen elk domein zal dit anders plaatsvnden. Last van het niet kunnen generaliseren van de RGBZ-oplossing is er m.i. dan ook niet, er bestaat geen behoefte aan.
De vraag is of er structurele contactpersonen bestaan en zo ja, of de gegevens daarvan onderhouden kunnen worden. In de meeste gevallen is een contactpersoon m.i. situationeel, gebonden aan een zaak. Mij schieten geen voorbeelden te binnen van strcuturele contactpersonen waarvan de overheidsorganisatie bereid is de gegevens structureel te onderhouden. Als die er al zouden zijn, is het de vraag waarvoor die bruikbaar zijn: zijn ze niet gekoppeld aan een onderwerp dat voor anderen niet van belang is? Oftewel, is het wel een basisgegeven?
Samenvattend, de aanleiding was een Wabo-aanvraag. Deze zou wat mij betreft uitgewisseld moeten en kunnen worden overeenkomstig het RGBZ, inclusief de contactpersoon-gegevens. Ik meen te lezen dat het OLO hiervan gaat afwijken en dat zou ik zeer jammer vinden. En het zou me verbazen gezien de review die EGEM in juli 2009 op het LVO heeft gedaan.
Er wordt in deze post niet ingegaan op het inhoudelijke punt dat ook voor gemeentelijke organisaties het mij niet waarschijnlijk lijkt dat de organisatorische hark en de verdeling in vestigingen samenvalt. Ik zou graag een inhoudelijke reactie op dit punt zien.
Maarten
Een Wabo-aanvraag en de aanvragen in het sectormodel eFormulieren laten zich niet uitwisselen via zkn0310 berichten, omdat er in deze berichten geen plaats is voor zaakspecifieke gegevens. Het is niet voor niets in het sectormodel eFormulieren voor elke specifieke aanvraag een bericht wordt gedefinieerd. Het is wel wenselijk dat gegevens die op alle aanvragen voorkomen, zoals de aanvraagdatum, de aanvrager en de gemachtigde, bijlagen e.d. generiek worden gemodelleerd. De hamvraag lijkt te zijn of het objecttype Zaak adequaat is voor dit generieke deel. Hier zou inhoudelijk nog eens naar gekeken moeten worden. Ik heb in eerste geval wel het gevoel dat Zaak als generieke basis voor een aanvraag te complex is en semantisch niet verhelderend werkt. Een aanvraag bestaat sowieso onafhankelijk van de zaak waarin deze behandeld wordt. Dit pleit ook al voor het onderkennen van Aanvraag als een afzonderlijk objecttype.
Ik kan me vinden in de stelling dat de contactpersoon situationeel is in het kader van de relatie naar een zaak of aanvraag. Ik deel evenwel niet de conclusie dat het situationeel van de contactpersoon onmiddellijk leidt tot de conclusie dat je contactpersoon niet onder betrokkene zou mogen modelleren. Het belangrijkste punt is dat het semantisch het je mogelijk maakt om vanuit elk willekeurig objecttype eenvoudig situationeel of niet een relatie te leggen naar de contactpersoon van een vestiging of niet-natuurlijk persoon. Omdat het patroon dat je een contactpersoon wilt kennen, veel voorkomt, lijkt een expliciete semantische modellering zeer wenselijk.
Of je betrouwbaar kunt vaststellen wie de contactpersoon is, lijkt mij niet relevant. De aanvrager geeft zelf aan wie de contactpersoon is en ik zie geen redenen om deze eigen aangifte niet te vertrouwen of onbetrouwbaar te vinden. Het criterium of iets een basisgegeven is moet zijn of het betrouwbaar is vast te stellen, maar of het door verschillende afdelingen in een gemeente wordt gebruikt. Het fenomeen contactpersoon voldoet mijns inziens zeer goed aan dit criterium en is daarom een basisgegeven.
In het niet nodig zijn van het modelleren van de interne structuur in de vorm van organisatorische eenheden van niet zaakbehandelende organisaties kan ik me vinden. Ik pleit er daarom ook voor om alleen de contactpersoon binnen Betrokkene te modelleren. Voor mij heeft de modellering in het RGBZ van Betrokkene wel voor verwarring gezorgd, omdat daarin Organisatorische Eenheden worden gekoppeld aan Vestigingen. Alleen bij close reading van de tekst constateer je, dat dit niet bedoeld is voor alle Vestigingen in het NHR maar uitsluitend voor de Vestigingen van zaakbehandelende organisaties. Dit punt zou al verduidelijkt worden door ergens een subtype van Maatschappelijke Activiteit of Niet-natuurlijk Persoon te definiëren dat zich qua populatie beperkt tot de zaakbehandelende organisaties analoog aan de subtypering binnen Natuurlijk Persoon in het RSGB.
Met je inhoudelijke punt ben ik het eens. Het is evenwel niet de bedoeling van het RGBZ geweest het inhoudelijk diepgaand en zo dicht mogelijk bij de werkelijkheid uit te werken. Zie het als een voorlopige 'view' vanuit het zaakgericht werken op dit stukje werkelijkheid. Correcte uitwerking zou m.i. in een separaat horizontaal referentiemodel moeten plaatsvinden, naast RGSB ('wat) en RGBZ ('hoe') in een model voor organisatie en medewerkers oid ('wie'). Voor het RGBZ is de vigerende modellering wat mij betreft vooralsnog afdoende.
Eens met het laatste, het onderscheiden van een subtype van Vestiging (!) zijnde vestigingen van zaakbehandelende organisaties met een relatie naar Organisatorische eenheid. Maakt het plaatje inderdaad begrijpelijker (maar doet aan de semantiek niets af).
Elke aanvraag bevat eigen aanvraagspecifieke gegevens. Als er in een zkn0310-bericht geen plek is voor aanvraag-specifieke gegevens, dan zou die er ook niet zijn in een generiek aanvraag-bericht. Niet voor niets zijn er specifieke e-formulieren voor elk type aanvraag.
De hamvraag is of zaakberichten te gebruiken zijn voor het doorsturen van een aanvraag. Een zaakbericht bevat in ieder geval alle generieke aanvraaggegevens. Een aanvraag bestaat namelijk maar heel kort als zelfstandig object. Het wordt als zaak geregistreerd, niet als aanvraag. Omgekeerd bevat een zaakbericht veel meer gegevens en relaties en een complexere structuur als voor een generieke aanvraag nodig is. En wellicht werkt het voor sommigen verwarrend om een aanvraag onder de noemer 'zaak' door te sturen. Ik zou me dan voor kunnen stellen dat de aanvraag gemodelleerd wordt als 'view' op het RGBZ, niet als deel van het RGBZ. En enkel om het begrippenkader eenduidig te maken, wat mij betreft niet als apart objecttype.
Contactpersoon is m.i. hooguit een basisgegeven in de context van het contact, niet an sich. Dat pleit er m.i. voor het niet in het RSGB maar in andere modellen op te nemen, zoals het RGBZ.
Opname van contactpersoon als subtype van betrokkene zou leiden tot een relatie van een zaak naar een contactpersoon, daar waar dat nu beperkt is tot natuurlijke personen, niet-natuurlijke personen en vestigingen. Ik betwijfel zeer of het juridisch geoorloofd is de relatie vanuit de zaak naar de contactpersoon te leggen en van daar uit naar de vestiging of niet-natuurlijk persoon.
Al met al heeft je voorstel modelleringsconsequenties waar ik niet van overtuigd ben en heeft het wellicht ongewenste juridische consequenties. Het lijkt mij dat een en ander nader onderzoek behoeft.
Ellen, zie www.openkop.nl Zit daar geen aansluiting op wat je voorstelt ?
Ellen, bij de Gemeente Breda is er tevens behoefte aan een informatiemodel P&O. Momenteel werken we aan een Medewerkers Gegevensmagazijn.
Ik zag in het te downloaden document op openkop.nl de opmerking dat gegevens uit de GBA gebruikt zouden mogen worden.
Bij toeval kwam ik er achter dat op een specifieke plek van de GEMMA-SURF-groep, i.c. de map met agendastukken voor de StUF-expertgroep van 19 mei 2010 (i.p.v. zoals te doen gebruikelijk in de RGBZ-map), een nieuwe versie van het RGBZ geplaatst is. Onaangenaam verrast was ik, bij het doornemen hiervan, dat een substantiele functionele wijziging is doorgevoerd, namelijk de introductie van een nieuw objecttype: CONTACTPERSOON. Des te opmerkelijker aangezien de discussie hierover op dit forum nog niet geleid heeft tot overeenstemming over een oplossingsrichting en ik niets teruggezien heb van het aangeraden onderzoek. Ik betreur deze gang van zaken.
Het gaat hier om een m.i. forse functionele wijziging waarvoor de StUF-expertgroep m.i. niet de plaats is om hierover te beslissen. Consequentie van deze wijziging is bijvoorbeeld dat van zaakbehandelende organisaties (gemeenten e.a.) blijkbaar verwacht wordt dat zij voor elke nieuwe contactpersoon bij een zaak verifieren of zij deze wellicht eerder al geregistreerd hadden bij andere zaken. Ik vraag me af of dit doenlijk en zinvol is. Ik vraag me ook af of de behoefte om van een willekeurige contactpersoon bij zaken (dat is dus iemand anders dan bijvoorbeeld de initiator of aanvrager van een zaak) al zijn zaken te kunnen opvragen, zodanig groot is dat dat opweegt tegen de extra eisen die dit stelt aan de registratie daarvan. M.i. zijn dit aspecten waar inhoudelijk deskundigen zich over zouden moeten buigen, zoals bijvoorbeeld de voormalige werkgroep RGBZ. Verder komt de wijze van modellering mij merkwaardig voor. Het is nu mogelijk dat ene J. Jansen, werkzaam bij het bedrijf Hupkes bv, contactpersoon is in een zaak voor de aanvrager daarvan, het bedrijf Reimer bv. Dat kan toch niet de bedoeling zijn (is het blijkbaar niet want met constraints wordt dit dan weer uitgesloten; m.i. is er gewoon een relatie te veel).
Ik raad KING aan om nu eindelijk eens versie 1.0 van het RGBZ vast te stellen (zonder deze wijziging van contactpersoon), de discussie over dit onderwerp te gaan voeren met inhoudelijk deskundigen en de resultaten daarvan t.z.t. te verwerken in versie 1.1. Dat zou tevens een mooie gelegenheid zijn om het RGBZ uit te breiden met gegevensmodellering gericht op het KCC waar vele gemeenten zich nu mee bezig gaan houden.