Aanslagen gemeentelijke belastingen, registeren in het zaaksysteem?

Beste allemaal,

De aanslagen van de gemeentelijke belastingen, archiveren jullie deze wel of niet in jullie zaaksysteem? Bij de gemeente waar ik momenteel werkzaam ben doet men dat niet. Ook kan ik in i-navigator geen proces voor aanslagen gemeentelijke belastingen vinden. Op basis waarvan bepalen jullie of iets wel of niet gearchiveerd dient te worden? Bij de meeste processen is dat duidelijk, maar nu twijfel ik even.

Alvast bedankt!

Weergaven: 707

Hierop reageren

Berichten in deze discussie

Bedankt voor je bijdrage Rens, wat is en BI tool (dtv) ?

BI=business intelligence. Bijvoorbeeld een rapportagetool zoals Crystal Reports.
 
Yvonne Welings zei:

Bedankt voor je bijdrage Rens, wat is en BI tool (dtv) ?

Het uitgangspunt dat je maar één plek hebt (zaaksysteem of DMS) waar je archiefwaardige informatie opslaat en waar je je houd aan de wet- en regelgeving mbt archivering is lovenswaardig, maar de praktijk is anders. Het hoeft ook niet persé, je kunt er ook voor kiezen om op de 'NEN2082'-manier met informatie om te gaan met meerdere systemen. Maar om dat goed te regelen, is waarschijnlijk wel wat meer nodig dan wat Rens suggereert. Veel systemen (ook al zijn ze specifiek voor gemeenten ontwikkeld) zijn daar niet op gebouwd. Overigens: of iets nou een record in een database is of een document, maakt eigenlijk niet uit voor de manier waarop je er mee omgaat...

@Yvonne: wat je over het toezicht stelt, herken ik. Alleen vraag ik me af of het horizontale toezicht hier wel werkt. Het lijkt wel alsof het normenkader op dit vlak onvoldoende scherp is. Of degenen met een informatie-of archiefachtergrond zijn niet kritisch of mondig genoeg. Of zijn bang voor nestvervuiling. Terzijde: ik hoorde laatst van een direct betrokkene van een gemeente waar de problemen (onvolledig, ongeorganiseerd, hybride digitaal/analoog archief) pas werden aangepakt na een kritisch rapport van de lokale rekenkamer. Nog een escalatiemogelijkheid...

Wij ervaren de wet RGT als een enorme vooruitgang, maar ik ken de discussie met de Rekenkamers. Wellicht dat de gemeentearchivarissen beter benoemd kunnen door de gemeenteraad in plaats van het college. Er zitten ook grote (kwalitatieve) verschillen in de rapportages, dat zal je bij een Rekenkamer ook houden.

Misschien vervelend om te zeggen maar de NEN 2082 wordt niet doorontwikkeld.

Zie ook http://www.breednetwerk.nl/profiles/blogs/is-een-centraal-dms-een-u...

Dit helpt mij zeker! En sluit exact aan op een gedachte die ik zelf inmiddels ook heb. Namelijk dat je niet moet willen dat alle informatie per se in het zaaksysteem thuis hoort (wat ik veel mensen wel hoor zeggen en schrijven). In bepaalde gevallen is dat gewoon niet handing. Wat je zegt: "Hoe ik er tegenaan kijk: een archief is vooral bedoeld om informatie makkelijk te kunnen terugvinden en hergebruiken. Vanuit die gedachte is een centraal archiefsysteem vooral geschikt voor informatie die voor meerdere processen of gebruikersgroepen relevant is..", klopt wat mij betreft dan ook precies. De kanttekening daarbij is dan wel dat we in kaart brengen waar die informatie dan wél wordt opgeslagen, welke informatie op zijn minst in welke processen aanwezig moet zijn en dat de juiste bewaartermijnen gehanteerd worden. Inderdaad zou een query daarin noodzakelijk zijn om toch regelmatig kwaliteitscontroles te doen. Zo had ik er nog niet naar gekeken, thanks :-) 
 
Rens zei:

Ja, daar heb ik zeker ervaring mee.

Om te kunnen vernietigen is het belangrijkste dat er einddata worden vastgelegd. In de meeste systemen gebeurt dat standaard, anders kan een functioneel beheerder of leverancier dat meestal wel inrichten. Het maken van vernietiglijsten kan inderdaad niet altijd via de applicatie zelf, maar je zou met een BI-tool een rapportage op de database kunnen draaien. Als je weet wat de bewaartermijn is, maak je een query van [datum afsluiting]+[huidig jaartal minus aantal jaren bewaartermijn] en dan heb je een overzicht van te vernietigen zaken. Als er verschillende bewaartermijnen van toepassing zijn dan kun je metadata als resultaattype of procestype meenemen in die query. Vernietiging kan soms door functioneel beheer worden uitgevoerd via de frontend, soms moet het via de achterkant door via een query op de database. En zoals Yvonne al aangeeft: vanuit wettelijke eisen moet je dit sowieso regelen.

Het punt dat je noemt van het bewaken van de kwaliteit is terecht, maar dat kun je oplossen door een kwaliteitsmedewerker toegang tot het systeem te geven of door rapportages te draaien op niet gevulde velden.

Hoe ik er tegenaan kijk: een archief is vooral bedoeld om informatie makkelijk te kunnen terugvinden en hergebruiken. Vanuit die gedachte is een centraal archiefsysteem vooral geschikt voor informatie die voor meerdere processen of gebruikersgroepen relevant is. En als informatie een lange bewaartermijn heeft, dan wil je graag een omgeving gebruiken die geschikt is voor langdurige bewaring. In dit geval zou je prima kunnen redeneren: informatie is maar voor een beperkte gebruikersgroep relevant en de bewaartermijn is relatief kort (denk ik), dus dan heeft opslag in een centraal systeem weinig toegevoegde waarde.
 

Helpt dit je?


Kitty Altena zei:

Heb jij daar ervaring mee? Ik heb mijn vraagtekens daarbij. De vak applicatie is niet bedoeld als archiefsysteem en mist bijvoorbeeld ook bewaartermijnen, mogelijkheid tot het uitdraaien van vernietigingslijsten + de kwaliteit van de informatie wordt zo niet bewaakt. Daarnaast is er gekozen voor een zaaksysteem om de informatie uit allerhande vak applicaties naar een centraal punt te brengen waar iedereen kan raadplegen en we daarmee meer 'grip' krijgen op de processen die lopen binnen de gemeentelijke organisatie.

Ik ben benieuwd hoe jij daar tegen aankijkt.

Rens, heb je wel eens onderzoek gedaan om te weten of je de I-Navigator op dit soort applicaties kan gebruiken?

Jaap de Jonge zei:

(...) Maar om dat goed te regelen, is waarschijnlijk wel wat meer nodig dan wat Rens suggereert. (...)

Daar heb je natuurlijk helemaal gelijk in. Een en ander is natuurlijk erg afhankelijk van het type informatie dat in een systeem wordt opgeslagen, soms volstaat een hele beperkte set maatregelen en soms is er meer nodig. Je moet ook praktisch zijn: het is niet altijd reëel om een legacy-systeem volledig compliant te maken aan beleid en regelgeving en je moet ergens beginnen.

We proberen dit op termijn te lossen door bij de aanschaf en inrichting van nieuwe systemen het informatiebeheer meteen goed in te richten en te accepteren dat we een erfenis hebben waarin niet alles op orde is. Bij een kleine organisatie zou je daar misschien nog in kunnen duiken, maar met een landschap van ca. 8.000 applicaties moet je prioriteren...
 


Yvonne Welings zei:

Rens, heb je wel eens onderzoek gedaan om te weten of je de I-Navigator op dit soort applicaties kan gebruiken?

Nee. Wat zou je precies met de I-Navigator willen doen in dit verband? Ik heb wel ooit ergens gewerkt waar de I-Navigator werd gebruikt om het applicatieportfolio in vast te leggen, daar is het volgens mij wel geschikt voor, maar in onze organisatie hebben we daar een andere portfoliotool voor.

Kitty Altena zei:

(...) De kanttekening daarbij is dan wel dat we in kaart brengen waar die informatie dan wél wordt opgeslagen, welke informatie op zijn minst in welke processen aanwezig moet zijn en dat de juiste bewaartermijnen gehanteerd worden. (...)

Dat klopt inderdaad. En niet alleen in kaart brengen, maar ook up-to-date houden.

Voor meer info van de I navigator:

Ja. Voor het overgrote deel van de op de Nederlandse markt beschikbare DMS systemen zijn koppelingen beschikbaar via de leveranciers van deze systemen. Voor zaaksystemen ontstaat een vergelijkbare situatie. Een groot aantal leveranciers van systemen met zaakfunctionaliteit heeft inmiddels koppelingen beschikbaar of anders worden die momenteel ontwikkeld.

Binnenkort wordt die uitgebreid in verband met de AVG.

Antwoorden op discussie

RSS

© 2024   Gemaakt door Marco Klerks.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden