ArjanKloosterboer
commented
6 years ago Wat is nu de strekking? De laatste alinea? Die geeft weinig richting. M.i. is van belang te onderkennen dat zaakgericht werken het esperanto is opdat domeinspecifieke info ook buiten dat domein toegankelijk gemaakt kan worden. Er is dan voor de beschouwer geen domeinspecifeke kennis nodig om toch te kunnen communiceren met dat domein. Voor de burger is dit veelal prettig, het voorkomt dat 'ie met de gemeente in gesprek moet via een heleboel verschillende loketjes. Neem het Omgevings(wet)Loket: één portaal voor communicatie van de burger met de gehele overheid over leefomgevingaangelegenheden. Moet die overheid in dat loket wel met één tong spreken! De waarheid zal wel ergens in het midden liggen. Als de burger het nut niet ziet dat 'ie voor het ene bij loket A moet zijn en voor het andere bij loket B, benader hem/haar dan op één en dezelfde wijze vanuit één loket. Daar hebben we een domeinonafhankelijke taal voor: zaakgericht werken cq. zaakinfo. Heeft die burger wel degelijk nut bij zeer domeinspecifieke aangelegenheden, benader 'm dan domeinspecifiek. Maar zorg dat anderen nog steeds domeinonafhahankelijk met dat domein kunnen communiceren. Oftewel spreek ook zaakgericht. Samengevat, in Friesland mag fries met elkaar gesproken worden, in Limburg limburgs maar als friezen met limburgers spreken is ABN de voertaal.
jeffreygortmaker1
sergei-maertens
Hugo-ter-Doest
ehotting
TCIMEddy
Vraag uit architectuurdocument Beschrijving: Zaakgericht werken kent al een lange geschiedenis. Het stamt uit de tijd dat dienstverleningsambities hoger werden en backoffice-applicaties dit niet of nauwelijks aankonden. Daarna was er de gedachte dat een “alles-in-1 zaaksysteem” voor veel processen voldoende zou zijn. Inmiddels draait de slinger een beetje terug en zien we taakspecifieke systemen moderner en opener worden. In een gegevenslandschap is dit helemaal het geval. In de loop der jaren zijn er diverse doelen voor zaakgericht werken ontstaan: dienstverlening verbeteren, als basis voor het archiveren, het bieden van managementinformatie,.. waarvan het de vraag is of je ze in een modern applicatielandschap nog met zaakgericht werken wilt oplossen. In het geval van een gemeente die met één dominant generiek zaaksysteem werkt ligt de oplossingsrichting voor de hand. In een gegevenslandshap veel minder. Bovendien zien we op vele vlakken een terugtrekkende beweging op het “gemeentebrede” dienstverlenigsconcept, meer richting domeinspecifieke Apps en portalen. Een meer domeingerichte dienstverlening en informatievoorziening (ipv generiek obv zaken) ligt dan meer voor de hand. Enkele voorbeelden: Een gemeente wil alle Meldingen Openbare Ruimte op een kaart tonen. Vraag je hiertoe alle melding-zaken op met een generiek ZDS-koppelvlak? Wetende dat de AVG dit voor het overgrote deel aan zaken/zaaktypen niet toestaat? Of kies je voor een meldingen-specifiek koppelvlak, dat mogelijk functioneel rijker is: type melding, prioriteit van de melding, tekstuele toelichting…allemaal wellicht nuttig om op een dergelijke kaart te kunnen weergeven. Maar niet of slechts met moeite (zaaktypespecifieke eigenschappen) met een generiek zaken-koppelvlak te realiseren. Hoe wil je een proceseigenaar/afdelingshoofd van management-informatie voorzien? Op basis van zaken kun je erg generieke metrieken weergeven. Aantal zaken per afdeling, aantal zaken per status, zaken die voor of achter lopen op plandatum etc. Toch is het vergelijken van een subsidiezaak met een vergunnningenzaak appels met peren vergelijken. En zit een manager vergunningen vermoedelijk op heel andere metrieken te wachten: aantal vergunningen per wijk, aantal afhandeluren per bouwvolume-eenheid etc. Hoe wil je status-informatie weergeven aan de klant? Heel generiek obv enkel voorgedefinieerde “zaakstatussen”, of wil je dit functioneel rijker doen in een domeinspecifiek portal, bijvoorbeeld specifiek voor subsidies? Het is belangrijk om hier als gemeente even goed bij stil te staan. In veel gevallen zal het nog steeds handig blijken om iets met zaken op te lossen, of misschien beide: generieke informatie via zaken tonen en als aanvulling daarop enkele functioneel rijkere portalen of apps per domein.