23 maart 2022 · Marcel Krassenburg · community
Actormodel voor medewerker-API
Omdat we voor het Gemeentelijk Gegevenswoordenboek nu toevallig ook kijken naar een ontologie voor samenwerken en dat daarbij ook het "actormodel" in beeld is (organisatie, functie, persoon, dus ook medewerker), is dit mogelijk ook een denkrichting voor de gewenste medewerker-API.
Medewerkermodel
Allereerst maar eens kijken naar het medewerkermodel zoals genoemd in de bijeenkomst en wat definities:
- Medewerker: Iemand die ergens in dienst is (woorden.org). Synoniemen: personeelslid, human resource.
- Werknemer: De contractuele wederpartij van de werkgever bij de arbeidsovereenkomst (Wikipedia).
- Organisatie: Doelgerichte en geordende verzameling van resources.
- Resource: Mensen en middelen, "DenkEnWerkKracht".
In GEMMA informatiemodel RGBZ 01.01
Objecttype MEDEWERKER : Een medewerker van de organisatie die zaken behandelt uit hoofde van zijn of haar functie binnen een ORGANISATORISCHE EENHEID.
Objecttype ORGANISATORISCHE EENHEID: Het deel van een functioneel afgebakend onderdeel binnen de organisatie dat haar activiteiten uitvoert binnen een VESTIGING VAN ZAAKBEHANDELENDE ORGANISATIE en die verantwoordelijk is voor de behandeling van zaken.
Objecttype BETROKKENE: Een SUBJECT, zijnde een NATUURLIJK PERSOON, NIET-NATUURLIJK PERSOON of VESTIGING, ORGANISATORISCHE EENHEID (binnen een vestiging van de zaak-behandelende niet-natuurlijk persoon), of MEDEWERKER (van die organisatorische eenheid) die een rol kan spelen bij een ZAAK.
Objecttype ROL: De taken, rechten en/of verplichtingen die een specifieke betrokkene heeft ten aanzien van een specifieke zaak
Uit Zaakgericht werken in een Gegevenslandschap een deel uit het schema van het informatiemodel conform Common Ground. Links onder de Organisatie- en Medewerker API:
In het medewerkersmodel van RGBZ is de arbeidsovereenkomst de primaire relatie tussen organisatie en persoon. Je ziet bij het object MEDEWERKER dan ook attributen zoals datum uit dienst of functie. In de toelichting wordt deze beperkende een-op-een relatie ook onderkend.
Actormodel
Een actor is "een persoon in een functie namens een organisatie". Functie is daarbij vooral een "standaardfunctie", die typerend is voor de actor-functienamen, maar die wel per actor kunnen verschillen. B.v. is de standaardfunctie "Projectleider", maar de actor heeft op het visitekaartje staan: Projectleider Innovatie".
De functies van actoren volgen vanuit een decompositie van een organisatie, die je op het hoogste niveau als functionele blackbox kan zien.
De "functie van de overheid" streeft naar waardetoevoeging aan de omgeving, middels producten/diensten die resultaat zijn van processen. Potentieel is de organisatie ingericht om die processen uit te kunnen voeren. Resources zijn daartoe gegroepeerd in organisatie-eenheden. De "human resources" vervullen weer deelfuncties, b.v. afdelingshoofd, beleidsmedewerker, klantbegeleider, systeembeheerder. Daartoe zijn deze actoren (in principe ...) competent om die functie te vervullen (opleiding, vaardigheid, kennis, etc.). Zij hebben ook mandaat en verantwoordelijkheden, rechten en plichten. Daarmee kunnen zij een geautoriseerde rol vervullen in processen.
Generieke objecten in werkprocessen
Voor hergebruik en opschalen van applicaties en gegevens is een zekere mate van standaardisatie nodig. Eén mogelijke denkrichting is om gelijkenis te vinden in de werkprocessen en in de gegevensstructuren. Onderstaand schema geeft 4 blokken van dit soort generieke objecten, die weer onderlinge relaties en eigen kenmerken hebben.
In het linker blok staat het actormodel. Dat kan meerdere werkrelaties van een persoon vastleggen: naar verschillende organisatie-eenheden of groepen (projectgroepen, tijdelijke teams, detachering, vergadergremia) en/of naar verschillende functies. Dus b.v. naast afdelingshoofd ook projectleider reorganisatie.
De domeinspecifieke objecten - die het onderwerp zijn van de werkprocessen - zijn talrijk: bomen, huizen, verkeer, belasting, zorg, etc.
Zie ook "Overige objecten" op Common Ground.
Voorbeelden van actoren voor zaakgericht werken
| Organisatie | Functie | Persoon | Actornaam |
|---|---|---|---|
| Gemeente X | - | - | |
| Hoofdafdeling Stadsbeheer | Directeur | Gerda.... | |
| Afdeling Vergunningen | Senior Medewerker | Jan ... | Medewerker bijzondere vergunningen |
| Afdeling Vergunningen | Medewerker vergunningverlening | Joke ... | |
| Projectgroep Z | Secretaris | Jan ... | |
| Hoofdafdeling Stadsbeheer | EHBO-er | Jan ... | EHBO Vleugel C |
Voorbeelden voor raadswerk
| Organisatie | Functie | Persoon | Actornaam |
|---|---|---|---|
| Gemeente X | Burgemeester | Peter ... | |
| College van BW (Gemeente X) | Wethouder | Saskia ... | Wethouder Welzijn en Zorg |
| Gemeenteraad (Gemeente X) | Raadslid | Erik ... | |
| Fractie ABC | Fractievoorzitter | Erik ... | |
| Commissie Y | Commissielid | Erik ... | |
| Griffie | Griffier | Henk .... | Waarnemend griffier |
| Raadswerkgroep communicatie | Secretaris | Erik ... |
Gebruik actor elementen
Het model is ook bruikbaar als de persoon in de functie nog niet bekend is (vacature) of dat de persoonsgegevens vanuit privacy niet gedeeld kunnen worden. Zo kan iemand in de functie "beleidsmedewerker milieu" wel bereikbaar zijn voor b.v. een voorzitter van een bewonersvereniging, zonder in eerste instantie rechtstreeks naam, email adressen of telefoonnummers te publiceren.
Ook kan een actor alleen bestaan uit een organisatie-eenheid (bv. Team handhaving) en zo deelnemen aan processen. En een actor met alleen een persoon kan je zien als "op persoonlijke titel". Bij sommige functies is het gevoelig in welke hoedanigheid iemand opereert of uitgenodigd wordt.
| Organisatie | Functie | Persoon | Actornaam |
|---|---|---|---|
| Gemeente X | - | - | |
| Afdeling Vergunningen | Senior Medewerker | Vacature | |
| Afdeling Milieu | Beleidsmedewerker milieu | <afgeschermd> | |
| Team Handhaving | - | - | |
| - | - | Jan Jansen | "Op persoonlijke titel" |
Verschil tussen actor en rol
Daarnaast kan de actor ook veelvuldig gebruikt worden om te verbinden aan een rol in bepaald werk of bij informatie, zoals eigenaar, behandelaar, contactpersoon, auteur, etc. Het verschil tussen actor en rol:
- Actoren zijn de resources die je kan inzetten voor een proces, vanwege hun vaardigheid en hun specifieke rechten en plichten (de actor kan het, mag het, moet het).
B.v. voorzitter van de raad, griffier, medewerker vergunningen, ... - Rollen zijn de serie vakmatige handelingen, met rechten en plichten, die benodigd zijn voor het daadwerkelijk uitvoeren van een (deel van een) proces door een actor. B.v. het voorzitten van een vergadering. Het notuleren ervan. Het beoordelen van een vergunningaanvraag.
Actoren zitten aan de organisatiekant, rollen zitten bij het werk/proces.
Actor en rol komen ook voor in het Kennismodel GEMMA :
- Bedrijfsactor: "organisatorische eenheid die in staat is bepaald (actief) gedrag te vertonen."
- Bedrijfsrol: "de verantwoordelijkheid voor specifiek gedrag waar een bedrijfsactor aan toegewezen kan worden."
Deze definities geven helaas niet veel houvast voor een heldere invulling van deze begrippen.
Vergelijking met popolo
Popolo is een "International open government data specification", een schema van classes en eigenschappen gericht op de entiteiten die betrokken zijn bij bijeenkomsten en besluiten nemen (organisatie, persoon, functie, evenement, stem). Zie http://www.popoloproject.com/.
Het is o.a. gebruikt in het OpenRIS (Raadsinformatiesysteem) voor de entiteiten vergadering, stemming en motie. Het beschrijft ook lidmaatschap en functie (post)
Het lijkt op het actormodel:
Het gegevensmodel van Popolo kan dus een basis zijn voor het medewerkermodel en kan ook vergeleken worden met het actormodel. Een vergelijking op entiteit en attribuutniveau heb ik destijds ook gemaakt. Dat geeft nogal wat aandachtspunten die nader uitgewerkt moeten worden. Zo komt membership/lidmaatschap in de werkelijkheid voor als arbeidsovereenkomst, als lid van vereniging, als lid van een projectgroep, als lid van een netwerk, als lid op een interesselijst. Telkens met een andere verhouding tussen groep en lid, met sterke of weinig sturing en met andere rechten en plichten.
Voordelen actormodel
- De gewenste medewerker-API is gebaseerd op een semantisch, generiek en duurzaam informatiemodel.
- Het model is ook de basis voor een set van coherente API's voor samenwerken, b.v. projectleden-API, gemeenteraad-samenstelling-API.
Informatie-architectuur voordelen
- Een universeel model van resources in werkprocessen, bruikbaar in veel informatiemodellen van de overheid.
- Functionele evenredigheid tussen doelen van de organisatie, de inrichting ervan en de bijdragen van de medewerkers hier aan middels de werkprocessen.
- Helder onderscheid tussen authenticatie (op persoon) en autorisatie (op actor).
- Eenvoudige overname van rechtenbundels vanuit de actor. De standaardfunctie kan al rechtenbundels hebben, die overerfd worden naar de actor en daar vandaan naar de rol. Zodra iemand als actor is vastgelegd, is ook de standaard rechtenbundel beschikbaar. Zo hebben projectleiders en secretarissen alle rechten over de inhoud van hun project. Op actorniveau kan dit worden aangepast, voor de afwijkingen en uitzonderingen.
- Helder onderscheid tussen een actor (potentieel inzetbaar) en een rol (werkelijke inzet in een proces)
- Historisch inzicht doordat een actor een begin- en einddatum heeft en zo aanwezig blijft in de database. Voorgaande raadssamenstellingen blijven optioneel zichtbaar, evenals voorgangers op functies.
- Overname van rechtenbundels: een secretaresse van een wethouder of een tijdelijk waarnemer kan eenvoudig rechten krijgen om "namens" iemand systeemfuncties uit te voeren.
Bijkomende voordelen
- Inzicht in wie nu wat doet in een organisatie! Stel je voor dat de dynamiek van de medewerkerspool van VNGrealisatie zo in kaart wordt gebracht :-)
- Bijdrage aan de OpenOverheid, omdat opbouw en functies van iedere gemeente transparant kunnen zijn, binnen privacy-regels.
- Een minder vervuild sociaal intranet en community sites, waar alles en iedereen een groep is (die daarna vaak stilvallen). Iedere afdeling of team in de lijnorganisatie kan automatisch een groep op het intranet zijn, ieder project ook en is minimaal gepubliceerd met de projectsamenstelling en basisgegevens zoals omschrijving of start/einddatum.
Nadelen actormodel
- Complexer door meer gegevens en expliciete duiding ervan
(maar na eerste opzet en op termijn is het eenvoudiger door toename van inhoud, kwaliteit en hergebruik) - Weer een systeem naast de andere
(nu is die medewerker informatie er ook, maar verstopt in veel systemen) - Hoe hou je dat actueel?
(terechte zorg: door meervoudig en praktisch gebruik kan het belang ervan voor iedereen duidelijk worden, door API-koppelingen met o.a. HR-systeem kunnen veel gegevens overgenomen/gekoppeld worden, basisgedachte is dat de actor zelf verantwoordelijk is en kan zijn voor de eigen actorgegevens) - Er zijn nog geen implementaties van het actormodel
(we moeten een keer beginnen ... doe een kleine proef met het concept, begin met definities van de kernbegrippen. Het werkte ooit in Zoetermeer :-), in een raadsinformatiesysteem en interne telefoonlijst met organisatie-functie indeling)
Marcel Krassenburg
- API, medewerker, ontologie, gegevenswoordenboek