Het inbouwen van regelgeving in bedrijfsprocessen en informatiesystemen *

Compliance by design Het inbouwen van regelgeving in bedrijfsprocessen en informatiesystemen* J. Hulstijn 1. Inleiding Regelgeving wordt op allerlei manieren ingebouwd in informatiesystemen. Niet alleen bij handhavers en overheidsinstanties, maar eigenlijk bij elke organisatie die aan wetten of interne bedrijfsregels moet voldoen. Informatiesystemen kunnen op twee manieren bijdragen aan het aantoonbaar naleven van wetten en regels (compliance): (1) door automatisch bewijs te verzamelen en te beoordelen of men aan de regels voldoet, en (2) door onwettige of onrechtmatige handelingen lastig of onmogelijk te maken in het ontwerp van een bedrijfsproces en de onderliggende informatiesystemen. Het eerste, het automatisch verzamelen en beoordelen van bewijs, staat momenteel sterk in de belangstelling van de auditwereld, onder de noemer continuous control monitoring. Daarmee kan men bij voortduring de rechtmatigheid van een proces bewaken.1, 2 In Nederland wordt dit bijvoorbeeld toegepast in de vleesverwerkende sector, bij de controle op naleving van voorschriften voor afvoer van (risicovol) slachtafval.3 In deze bijdrage richten we ons op de tweede wijze waarop informatiesystemen kunnen bijdragen aan het aantoonbaar naleven van wet- en regelgeving, namelijk door de manier waarop ze zijn ontworpen: compliance by design.4 De term is oorspronkelijk gebruikt in de context van business process management (BPM), het vakgebied dat zich bezighoudt met het (her)ontwerpen van bedrijfsprocessen. Het idee ervan is dat automatisch kan worden getest of het ontwerp van een bedrijfsproces voldoet aan eisen die volgen uit wet- en regelgeving. Dat testen

*

1 2 3

4

88

In deze bijdrage heb ik ideeën gebruikt die zijn ontstaan in samenwerking met Welmoed Fokkema. Zie W. Fokkema & J. Hulstijn, ‘Process Compliance in Public Information Chains’, in: Proceedings of The Tenth Conference on Electronic Government (EGOV 2011), Delft 2011. Veel dank ben ik verschuldigd aan de redactie, in het bijzonder aan Mariette Lokin, voor suggesties voor verbetering. J.R. Kuhn & S.G. Sutton, ‘Continuous Auditing in ERP System Environments: The Current State and Future Directions’, Journal of Infomation Systems 2010/afl. 1, p. 91-111. M.A. Vasarhelyi, M. Alles & A. Kogan, ‘Principles of Analytic Monitoring for Continuous Assurance’, Journal of Emerging Technologies in Accounting 2004/afl. 1, p. 1-21. J. Hulstijn e.a., ‘Continuous Control Monitoring-based Regulation: A Case in the Meat Processing Industry’, in: CAISE Workshop on Governance, Risk and Compliance Information Systems (GRCIS), Londen: Springer Verlag 2011, p. 238-248. G. Governatori & S. Sadiq, ‘The Journey to Business Process Compliance’, in: Handbook of Research on Business Process Management, Hershey, PA: IGI Global 2009, p. 426-445.

RegelMaat 2012 (27) 2

Compliance by design

heet conformance checking.5 Wij gebruiken de term ‘compliance by design’ in een bredere betekenis. Hij staat dan voor een aanpak waarbij het aantoonbaar voldoen aan wet- en regelgeving zo eenvoudig mogelijk wordt gemaakt, door de manier waarop het gehele stelsel van organisatorische maatregelen, procedures, processen en informatiesystemen is ontworpen. Menselijk gedrag is bepalend voor het voldoen aan wetten en regels. Gelukkig zijn computersystemen en bureaucratische procedures nog niet zó dwingend, dat ze gedrag volledig kunnen bepalen. Wel kan men op het gewenste gedrag sturen, door bijvoorbeeld eisen te stellen aan termijnen, autorisaties, inhoud van documenten of bewijsvoering. Deze eisen worden dan afgedwongen door het systeem. Voorbeelden van ‘compliance by design’ zijn te vinden in planning- en boekhoudsystemen in het bedrijfsleven, die slechts geautoriseerde transacties toestaan en afdwingen dat bijvoorbeeld de functiescheiding tussen de inkoop- en de verkoopafdeling niet wordt doorbroken. Vergelijkbare voorbeelden vindt men in workflow management-systemen die werkprocessen sturen. Zo’n systeem kan zorgen voor tijdige waarschuwingen wanneer bijvoorbeeld de beslistermijn op een aanvraag dreigt te worden overschreden. Het gaat echter niet alleen om procesmatige eisen, maar ook om eisen aan gegevens en gegevensverwerking. Denk aan het gebruik van een door de overheid geautoriseerde taxonomie voor financiële rapportage, die selectie van de juiste gegevens uit de administratie van de onderneming ondersteunt.6 Wettelijke regels zijn echter niet zomaar in te bouwen in een bedrijfsproces of informatiesysteem. Die regels zijn algemeen: ze moeten toepasbaar zijn in verschillende gevallen. De werkprocessen en computersystemen die de naleving en het toezicht daarop ondersteunen, zijn echter particulier; ze zijn in de loop van hun ontwikkeling uniek geworden voor de situatie in die organisatie. In deze bijdrage gaan we in op de volgende onderzoeksvraag: hoe kan men algemene wet- en regelgeving vertalen in specifieke regels en gegevensdefinities, die kunnen worden ingebouwd in bedrijfsprocessen en computersystemen? Wetgeving bevat vaak open normen. Deze schrijven alleen het doel voor dat bereikt moet worden, en laten de normadressaat vrij in de middelen die hij daartoe inzet. Voorbeelden zijn doelvoorschriften en zorgplichten, onder meer toegepast in de milieuwetgeving, maar ook begrippen als goed koopmanschap en ‘getrouw beeld’ in fiscale wetgeving en jaarrekeningrecht. Het gebruik van open normen heeft invloed op de manier waarop naleving en toezicht zijn georganiseerd; het gaat vaak samen met zelfregulering. De vertaling van normen in toepasbare regels en meetbare prestatie-indicatoren is in dat geval overgelaten aan sector, bedrijf of burger. Ook het toezicht op de naleving kan deels zijn overgelaten aan private partijen. Organisaties (bedrijven, daarin vaak bijgestaan door accountants of financieel adviseurs) moeten zelf aantonen op welke manier ze ‘in control’ blij-

5 6

A. Rozinat & W.M.P. van der Aalst, ‘Conformance Checking of Processes Based on Monitoring Real Behavior’, Information Systems 2008/afl. 1, p. 64-95. R. Debreceny e.a., XBRL for Interactive Data: Engineering the Information Value Chain, Berlijn: Springer 2009.


89

J. Hulstijn

ven.7, 8 De publieke toezichthouder beperkt zich tot metatoezicht op de zelfcontrole van de organisatie. Het gebruik van het Tax Control Framework in het kader van horizontaal toezicht bij de Belastingdienst is een bekend voorbeeld.9 Het gebruik van open normen heeft invloed op de informatiebehoefte van partijen en bepaalt dus mede het ontwerp van informatiesystemen. De wijze waarop open normen het systeemontwerp beïnvloeden, komt kort aan de orde. De bijdrage van deze verhandeling ligt in een precieze beschrijving van de analyse en het ontwerpproces voor bedrijfsprocessen en informatiesystemen die zijn bedoeld voor het naleven van wetten en regels. Het is de bedoeling dat dit ontwerpproces effectief is: het moet waarborgen dat het resulterende bedrijfsproces de wet daadwerkelijk vervult. Daarnaast moet men zorgen dat de desbetreffende handelingen aantoonbaar rechtmatig zijn: geoorloofd op basis van de wettelijke regels. Deze waarborgen zijn in de eerste plaats van belang voor degene die de wet moet naleven, maar ook de toezichthouder kan er bij inspecties dankbaar gebruik van maken. Wanneer een systeem zo is ingericht dat fouten of overtredingen onmogelijk gemaakt zijn of sneller aan het licht komen, is in principe minder fysieke inspectie ter plaatse nodig. Men moet natuurlijk het beheer en de juiste werking van het systeem regelmatig controleren. De rest van de bijdrage zit als volgt in elkaar. In paragraaf 2 gaan we verder in op het vertaalproces van algemene regelgeving in contextafhankelijke specificaties. In paragraaf 3 maken we een analyse van enkele voorbeelden en trekken daaruit lessen. We sluiten in paragraaf 4 af met enkele conclusies. 2. Analyse en ontwerp 2.1 Inleiding Het ontwikkelen van informatiesystemen doorloopt over het algemeen een aantal vaste fases: analyse, ontwerp, bouwen en testen en invoeren.10 Tegenwoordig worden die fases vaak niet meer achter elkaar gepland, maar in korte cycli per onderdeel afgewerkt. Zo kan tijdens de ontwikkeling nog worden bijgestuurd. Voor juristen is de analysefase het belangrijkste. Op basis van een goed begrip van het toepassingsdomein, de verschillende actoren en hun belangen en de beoogde doelstelling van het project worden eisen en randvoorwaarden opgesteld waaraan het systeem moet voldoen. Dit is het moment dat juristen het beste bij het project kunnen worden betrokken, om bij te dragen aan een juiste interpretatie van de wettelijke regels die aan het proces ten grondslag liggen. Worden zij er pas later

J.-K. Helderman & M.E. Honingh, Systeemtoezicht: een onderzoek naar de condities en werking van systeemtoezicht in zes sectoren, Nijmegen: Radboud Universiteit Nijmegen 2009. 8 B. Burgemeestre, J. Hulstijn & Y.-H. Tan, ‘Value-based Argumentation for Justifying Compliance’, Artificial Intelligence and Law 2011/afl. 2-3, p. 149-186. 9 H. Gribnau, ‘Soft Law and Taxation: The Case of the Netherlands’, Legisprudence 2007/afl. 3, p. 291-326. 10 J. Hulstijn e.a., ‘Public Process Management: A Method for Introducing Standard Business Reporting’, in: 12th Annual International Conference on Digital Government Research (DGo’2011), College Park, MD 2011, p. 141-150. 7

90



Figuur 1.

Vereenvoudigd werkproces van de aanvraag en toekenning van een vergunning; activiteiten van partijen in verschillende rollen zijn weergegeven in een aparte baan

bij betrokken, bijvoorbeeld pas in de ontwerp- of de implementatiefase van het systeem, dan is het te laat om fundamentele keuzes nog te wijzigen. Bij het uitvoeren of naleven van wet- en regelgeving gaat het in veel gevallen om kennisintensieve processen: processen die primair draaien om het verzamelen van gegevens, het combineren en filteren van die gegevens, het redeneren met die gegevens en uiteindelijk het nemen van een beslissing waar iets van afhangt. Denk bijvoorbeeld aan het aanvragen (door de burger) en het verlenen (door de gemeente) van een vergunning. Figuur 1 toont een model van dit proces in Business Process Modeling Notation (BPMN, een open standaard voor het weergeven van processen). De burger oriënteert zich op de eisen in de desbetreffende wetgeving. Hij formuleert zijn plannen en dient, eventueel met hulp van een deskundige, een aanvraag in. De frontoffice van het bestuursorgaan beoordeelt de aanvraag op ontvankelijkheid: is de vergunning op een juiste manier aangevraagd, of ontbreken er bijvoorbeeld nog stukken? Daarna toetst een beslismedewerker de aanvraag aan de geldende regels. Uiteindelijk volgt de beslissing om de vergunning wel of niet toe te kennen. Het gaat in dit geval om een werkproces; tijdens de doorloop ontstaat een dossier, met daarin alle gegevens op basis waarvan de beslissing genomen moet worden. In de analysefase zal ook moeten worden bepaald welke eisen uit de wetgeving zich lenen voor geautomatiseerde toepassing en welke menselijke beoordeling vergen. Hier speelt een rol of sprake is van open normen of van ‘gesloten’ voorschriften zonder beoordelingsruimte, zoals bijvoorbeeld de ontvankelijkheidseisen. Ook is het van belang te bepalen welke partijen de bevoegdheid hebben de open normen verder in te vullen. Is dat overgelaten aan de marktpartijen, aan brancheorganisaties, aan de uitvoerende instantie of aan de toezichthouder? Afhankelijk hiervan is duidelijk wie moeten worden betrokken of geconsulteerd.


91

J. Hulstijn

2.2 Stappenplan Hoe kan een juridisch adviseur op een goede manier bijdragen aan de analysefase? Voor deze fase hebben we een eenvoudig stappenplan opgesteld, bestaande uit zes stappen:11 1. Analyseer de aard en doelstellingen van het proces in context. De context omvat aspecten als de betrokken actoren en hun belangen, de financiering, de aard van het domein (financieel, medisch, handel, enzovoort). Ook de aard van het proces is van belang: gaat het slechts om informatieverstrekking, uitwisseling van informatie of om een volledige transactie waarbij rechten en plichten van deelnemers kunnen veranderen? 2. Bepaal de relevante regelgeving. Wat relevant is hangt af van de context (actoren, domein), de jurisdictie van de regelgeving, de soorten gegevens en de doelstellingen van het proces. 3. Modelleer het proces. Ga uit van de achterliggende doelstellingen, niet van de huidige werkwijze. Deze kan juist worden aangepast. Analyseer de informatiebehoeften. Stel een gegevensmodel op. 4. Bepaal de specifieke juridische eisen aan het proces. Denk hierbij speciaal aan de aandachtspunten a-h hieronder. Spits deze toe op de context. Dit levert eisen op voor het proces en de gebruikte gegevens die van toepassing zijn in die context. 5. Vergelijk het proces en de gegevensdefinities, zoals beschreven, met de specifieke eisen. Voor analysedoeleinden kan men een simulatie van het proces testen. 6. Pas het proces- of gegevensmodel aan of accepteer de gevonden tekortkomingen. Merk op dat juristen en domeinexperts in stap 4 en 5 een interpretatie maken. Ze interpreteren zowel de wet als de processen; beide moeten immers nog verder worden ingevuld afhankelijk van de situatie. In de hiernavolgende paragrafen gaan we verder in op deze interpretatie. De uitkomst van de confrontatie in stap 5 geeft: – inzicht in de specifieke eisen die de regelgeving stelt aan het proces en de gegevensdefinities, zowel voor het gehele proces als op het niveau van individuele processtappen; – een overzicht van de uitzonderingen en tekortkomingen in het proces en gegevensdefinities ten opzichte van de juridische eisen. Op basis van een dergelijke analyse en de gevonden tekortkomingen kan de verantwoordelijke voor het proces beslissen om het proces aan te passen, volledig opnieuw te ontwerpen of om de tekortkomingen te laten zoals die zijn, met aanvaarding van de bijbehorende risico’s. In het laatste geval maakt men in feite een uitzondering op de regel expliciet.

11 Gebaseerd op Fokkema & Hulstijn 2011. Stap 1 en 6 zijn toegevoegd.

92



Figuur 2.

Methode voor het vertalen van regelgeving in proces- en gegevenseisen

2.3 Aandachtspunten Bij het inbouwen van regelgeving in bedrijfsprocessen blijkt dat lastige ontwerpkeuzes vaak te maken hebben met een aantal aandachtspunten:12 a. Termijnen: processen moeten voldoen aan deadlines en termijnen. Denk aan maximale responstijden na een verzoek of maximale doorlooptijden. Dat betekent dat ook eenduidig mijlpalen of statusovergangen moeten worden gedefinieerd: begin, eind, beslissing, antwoord, afwijzing, enzovoort. Dat kan aan de hand van een procesmodel als in figuur 1. 12 Fokkema & Hulstijn 2011.


93

J. Hulstijn

b. Overdracht: het overdragen van informatie of van het initiatief tot handelen tussen afdelingen, rollen of instanties geeft meestal aan dat ook verantwoordelijkheden worden overgedragen. Dat betekent dat in het proces een toets en een bevestiging van geslaagde overdracht moeten worden ingebouwd. c. Berichten: bij het definiëren van berichten let men op de verwachte inhoud, op de specificatie van de zender en ontvanger en op de betekenis van het bericht in de gehele interactie. Vaak geeft een bericht aan dat een actie voltooid is of dat actie gewenst is van een andere partij. Het is verstandig een beperkt aantal berichtensoorten te definiëren, die een duidelijke betekenis hebben binnen het communicatieprotocol dat de interactie beschrijft. d. Taken, rollen en bevoegdheden: van elke handeling of stap in een proces moet duidelijk zijn wie bevoegd is en wie verantwoordelijk is voor de uitvoering ervan. Achteraf moet zijn vast te stellen wie een handeling heeft verricht uit hoofde van welke rol (zie par. 2.4). e. Gegevensdefinities: de gegevens die worden verwerkt, moeten soms aan bepaalde eisen voldoen. Denk aan het gebruik van berichtenstandaarden of taxonomieën voor gegevensdefinities (bepalend voor het formaat en de betekenis). f. Betrouwbaarheid: op basis van de in deze processen verzamelde gegevens moeten rechtsgeldige beslissingen worden genomen. Dat betekent dat men specifiek eisen moet stellen aan de juistheid, volledigheid, tijdigheid en rechtmatigheid van de verkregen gegevens. g. Informatiebeveiliging: gevoelige gegevens moeten worden beschermd. Het gaat dan om beschikbaarheid (geen uitval, archivering), vertrouwelijkheid (geen ongeoorloofde inzage of openbaarmaking) en integriteit (geen ongeoorloofde wijziging of vernietiging). Beveiliging is vaak duur en lastig. Maatregelen moeten proportioneel zijn: zware maatregelen alleen voor de meest gevoelige gegevens. Zo’n afweging wordt gemaakt aan de hand van een risicoanalyse en aan de hand van toetsing aan de geldende regels (bijvoorbeeld het Besluit voorschrift informatiebeveiliging Rijksdienst (VIR) en het Besluit voorschrift informatiebeveiliging Rijksdienst – bijzondere informatie (VIR-BI). h. Operationele eisen: er zijn ook meer technische of operationele eisen die kunnen volgen uit wet- en regelgeving. Denk aan een voorgeschreven volgorde van handelingen en speciale eigenschappen van de opgeleverde producten of documenten, zoals het gebruik van talen, leesbaarheidsrichtlijnen of serienummering. Bij procesmodellering lijkt het vooral te gaan om de handelingen. Men is geïnteresseerd in efficiëntie en het terugdringen van doorlooptijden. Maar een groot deel van de complexiteit van kennisintensieve processen zit nu juist in de bewerking van gegevens. In een juridisch proces gaat het uiteindelijk om het nemen van een rechtmatige beslissing op basis van bewijs. Dat bewijs wordt verzameld in een dossier. Bij elke beslisstap moet het dossier zover gevorderd zijn dat de gegevens die nodig zijn voor die stap bekend zijn. Aan de andere kant wil je de organisatie niet belasten met het verzamelen van gegevens die niet nodig blijken te zijn.

94



Er zijn talloze standaarden voor gegevensopslag en uitwisseling. Veel van die standaarden zijn gebaseerd op Extensible Markup Language (XML): een manier om zogenoemde ‘tags’ (labels) te definiëren om gegevens mee te annoteren. De geannoteerde gegevens en de relaties ertussen worden vastgelegd in een systematische beschrijving: een taxonomie.13 Het gebruik van een officiële taxonomie heeft een positief effect op het naleven van wet- en regelgeving. Als iedereen in de keten dezelfde gegevensdefinities gebruikt, is de kans op fouten veel kleiner en eventuele manipulaties worden sneller ontdekt. 2.4 Rollen en bevoegdheden Bewijs is ook van belang na afloop van het proces. Een dossier moet voldoende aanknopingspunten bevatten om de verschillende stappen en beweegredenen achter een beslissing te kunnen traceren. Een dergelijk spoor van handelingen heet ook wel een audit trail. Bij processen die worden uitgevoerd namens de overheid moeten in principe alle handelingen die iets verlangen van een burger uitgevoerd zijn uit hoofde van een bevoegdheid die is toegekend bij wettelijk voorschrift (legaliteitsbeginsel). Niet iedere ambtenaar mag zomaar gegevens opvragen. Zo zijn het innen van belastingen en het opvragen van gegevens die daarbij nodig zijn een specifieke bevoegdheid die is toegekend aan de Belastingdienst. Ook in het bedrijfsleven zijn bevoegdheden toegekend aan functies of afdelingen. Denk aan de afdeling inkoop die als enige spullen mag bestellen. Dat betekent dat voor de rechtmatigheid van een proces in de audit trail moet zijn vastgelegd welke persoon met welke bevoegdheden een bepaalde handeling heeft verricht. Binnen de auditwereld wordt uitgegaan van functiescheiding.14 Men scheidt afdelingen met beslissende, uitvoerende en registrerende taken. Zo kan de uitvoer van de een aan de hand van het werk van de ander worden geverifieerd. Denk bijvoorbeeld aan scheiding tussen de frontoffice, die met de burger meedenkt, de backoffice, die de regels streng maar rechtvaardig moet toepassen, en de beleids- en wetgevingsafdeling die de regels (mede) bepalen. Omdat personen van functie kunnen wisselen, is het gebruikelijk taken en bevoegdheden aan rollen toe te kennen. Die blijven relatief stabiel. Ook in de informatiebeveiliging worden de leesen schrijfrechten op data vaak toegekend op basis van rollen. Dat heet Role-Based Access Control.15 In de praktijk blijkt het toekennen van bevoegdheden op basis van taken en rollen enorm lastig te zijn. Auditors gaan uit van het principle of least privilege: men krijgt alleen die bevoegdheden die nodig zijn voor de taak. Maar vaak is helemaal niet duidelijk welke taken iemand vervult. Denk aan tijdelijke projecten. Als het principe te streng wordt genomen, loopt de organisatie krakend vast: er is dan bij incidenten geen ruimte meer voor improvisatie. Wordt echter het principe niet

13 G. Antoniou & F. van Harmelen, A Semantic Web Primer, Cambridge, MA: MIT Press 2004. 14 R.W. Starreveld, B. de Mare & E. Joels, Bestuurlijke informatieverzorging, Vol. 1, Alphen aan den Rijn: Samsom 1994. 15 R.S. Sandhu e.a., ‘Role-based Access Control Models’, IEEE Computer 1996/afl. 2, p. 38-47.


95

J. Hulstijn

serieus genomen, dan is na afloop niet altijd meer vast te stellen of de handelingen wel rechtmatig zijn uitgevoerd. 2.5 Kennis en regels In het vakgebied van de kennissystemen onderscheidt men verschillende soorten kennisintensieve taken,16 zoals classificatie, beoordeling, monitoring, configuratie of ontwerp. Classificatie is het indelen van een geval in een bepaalde klasse op basis van eigenschappen. De meeste kennisintensieve taken blijken varianten van classificatie te zijn.17 Met een taakanalyse kan men vaststellen wat de informatiebehoeften zijn van een bepaalde processtap, en wat precies de redeneervormen zijn die nodig zijn bij het uitvoeren van een taak. De gedachte hierachter is dat grote delen van de kennis kunnen worden hergebruikt. De beoordeling van een subsidie lijkt qua proces sterk op de beoordeling van een bouwvergunning. Aan de andere kant kunnen dezelfde kennisregels worden gebruikt voor verschillende taken. De regels voor het beoordelen van een bouwvergunning zijn ook nodig bij het opstellen van de aanvraag. Ze behoren daarom ook thuis op de website van de desbetreffende overheidsorganisatie (ofwel het bevoegd gezag). Het is dus met het oog op herbruikbaarheid verstandig kennisregels zo veel mogelijk onafhankelijk van de processtappen op te slaan en te beheren. Dat vereist dat regels kunnen worden uitgewisseld, onafhankelijk van de systemen waarin ze gebruikt worden; dat maakt ze flexibel inzetbaar. Hiervoor zijn verschillende standaarden beschikbaar; de meeste zijn gebaseerd op XML.18 Samenvattend kan men stellen dat kennisregels aangeven wat er moet gebeuren (declaratief); processtappen geven aan hoe dat moet gebeuren (procedureel). 2.6 Hulpmiddelen Voor het maken van analyses zijn gelukkig steeds betere hulpmiddelen beschikbaar. Voor wat betreft procesanalyse zijn er talloze notaties en systemen. De eerdergenoemde standaard BPMN wordt veel gebruikt voor het maken van een procesmodel. Aan de hand van zo’n model is het eenvoudiger de juridische consequenties van wettelijke termijnen, overdracht van verantwoordelijkheden, berichten en eisen aan de benodigde gegevens te bepalen. Voor wat betreft de analyse van een tekst, bijvoorbeeld een wetstekst of interne richtlijn, kan men denken aan tools voor het automatisch annoteren van relevante stukken tekst. Men voegt dan met behulp van ‘tags’ een extra betekenislaag aan de tekst toe, die het eenvoudiger maakt om bijvoorbeeld de herkomst van bepalingen of definities aan te geven. Dergelijke tags zijn een voorbeeld van metadata: gegevens over de gegevens. Dergelijke tools worden vaak ontwikkeld op basis van algemene standaarden voor gegevensopslag en uitwisseling die zijn aangepast voor het juridische domein.19 16 M. Stefik, Knowledge Systems, San Francisco: Morgan Kauffman 1995. 17 A.T. Schreiber e.a., Knowledge Engineering and Management: The CommonKADS Methodology, Cambridge, MA: MIT Press 2000. 18 H. Boley e.a., Schema Specification of RuleML Version 1.0, 2011, Ruleml.org. 19 Bijv. CEN, Metalex: Open XML Interchange Format for Legal and Legislative Resources, Brussel: European Committee for Standardization (CEN) 2010.

96



Een extreem voorbeeld hiervan is de Semantic-ART-annotator.20 Dit experimentele systeem kan op basis van taalkundige principes een wetstekst automatisch ontleden en in voor machines leesbare code omzetten. Deze code wordt dan gebruikt om snel in de tekst te kunnen zoeken, om passages te vergelijken of om automatisch de eisen aan te geven die voor een proces gelden. Zo wordt per processtap duidelijk welke gegevens nodig zijn voor de te nemen beslissing. Een ander bruikbaar hulpmiddel is een teksteditor die consistent gebruik van relevante terminologie helpt beheren. Wanneer een ‘beschermd’ woord gebruikt wordt, komt vanzelf een schermpje met de tot dan bekende definities naar boven, met synoniemen, vindplaats en gebruiksvoorbeelden. In het programma Legis van het ministerie van Veiligheid en Justitie (VenJ) wordt een teksteditor voor wetgeving ontwikkeld, die nu nog gericht is op het ondersteunen van de redactie van een wetsontwerp. Op termijn zou deze uit te breiden zijn met deze functionaliteiten. Daarmee kan zo’n editor juristen ook ondersteunen bij de analyse ten behoeve van systeemontwerp en worden gebruikt bij het genereren van simulatiemodellen voor de uitvoering. 3. Voorbeeld: toepassing van SBR voor in de keten Om de voorgaande inzichten te illustreren bespreken we nu een voorbeeld. In de voorbeelden hierboven ging het steeds om processen binnen een of twee organisaties. In de praktijk gaat het bij het toezicht op de naleving van wet- en regelgeving bijna altijd om complexe informatieketens: de overheid heeft taken uitbesteed, delen van het toezicht worden overgelaten aan de sector (zelfregulering), informatie is afkomstig van verschillende partijen in een keten of verschillende overheidsorganisaties werken samen. Hoe kun je nu zorgen dat voor al die samenwerkingsverbanden een uniforme manier van gegevensuitwisseling wordt gebruikt? Dat kan door standaardisatie van gegevensdefinities. Een voorbeeld van de standaardisatie van gegevensrepresentatie en gegevensdefinities vindt men in het Standard Business Reporting (SBR)-programma,21 dat uitgaat van XBRL, een gegevensstandaard voor financiële rapportages,22 en van de gegevensdefinities in de zogenoemde Nederlandse Taxonomie (NT). Dit is een gestructureerde verzameling online toegankelijke financiële begrippen die nodig zijn voor bijvoorbeeld het wettelijk juist berekenen van de omzet, kosten en vermogenscomponenten van een onderneming, ten behoeve van het doen van belastingaangifte of het vaststellen van de jaarrekening. De begrippen worden automatisch ingelezen en gebruikt in financiële software, zoals boekhoudpakketten. Bij gebruik van (de juiste versie van) de taxonomie worden de begrippen op de juiste 20 K. Sapkota, A. Aldea, D.A. Duce, M. Younas & R. Bañares-Alcántara, ‘Semantic-ART: A Framework for Semantic Annotation of Regulatory Text’, paper gepresenteerd op ESAIR’11, Glasgow, Schotland. 21 Zie <www.sbr-nl.nl>, de site van het SBR-programma, ondergebracht bij Logius, dienst digitale overheid van het ministerie van BZK. 22 R. Debreceny e.a., XBRL for Interactive Data: Engineering the Information Value Chain, Berlijn: Springer 2009.


97

J. Hulstijn

manier gekoppeld aan de cijfers in het boekhoudpakket, en gebruikt men dus altijd de wettige definities voor het samenstellen van de vereiste rapportages. Op dit moment wordt XBRL vooral gebruikt ‘achter in’ de rapportageketen, bij het genereren van een rapportage uit het boekhoudsysteem van de ondernemer. We verwachten dat nog grotere voordelen op het gebied van compliance te behalen zijn naarmate de XBRL-tags verder voor in de rapportageketen worden gebruikt. Dus al bij de eerste vastlegging van een transactie door de ondernemer. Op deze manier krijgt men ook een beter inzicht in de betrouwbaarheid van de gegevens. De herkomst van elk data-element kan worden gevolgd. Dat betekent wel dat de rol van de accountant zal veranderen. Het verzamelen van gegevens zal steeds meer aan de ondernemer en zijn softwarepakket worden overgelaten. De accountspraktijk (controle achteraf) en de belastingadviespraktijk (advisering vooraf) groeien naar elkaar toe. De financiële intermediair wordt steeds meer een regisseur van compliance in de keten.23 Een standaard werkt alleen als voldoende mensen hem gebruiken. Aan de andere kant kunnen de specifieke eigenschappen van elk domein niet in dezelfde standaard worden ondergebracht. Dan wordt de standaard complex, log en onbeheersbaar. Als tussenoplossing gebruikt men binnen SBR daarom extensies: dat zijn uitbreidingen op de algemene taxonomie, die bedoeld zijn voor een bepaald domein. In het SBR-programma zijn extensies ontwikkeld voor de verschillende belastingstromen (bijvoorbeeld omzetbelasting, inkomstenbelasting, vennootschapsbelasting), voor statistieken en voor de jaarrekening. Ook maken de banken gebruik van een soort extensie van de NT specifiek voor kredietbeoordelingen. Het gebruik van extensies heeft ook een keerzijde. Stel dat er twee soorten winst bestaan: winst voor de belastingen en winst voor de jaarrekening. Deze begrippen verschillen: berekend met dezelfde basisbegrippen, zoals omzet, kosten en vermogen, maar op grond van andere waarderingsgrondslagen voor die componenten. Stel nu dat de experts van de ministeries van Financiën en VenJ onafhankelijk van elkaar hun definities voor de taxonomie aanleveren. Dan blijft een eventuele overlap in de benodigde basisbegrippen buiten het zicht en levert de standaard maar weinig complexiteitsreductie op. Met andere woorden: men moet actief proberen de begrippen zo veel mogelijk te normaliseren en harmoniseren. Juridische analyse van de betekenis van begrippen in de wetgeving is ook hierbij essentieel. In het SBR-programma heeft die analyse ook plaatsgevonden, wat geleid heeft tot een harmonisatie van het fiscaal en commercieel winstbegrip. Dat scheelt een groot aantal data-elementen in de taxonomie en maakt dat (kleine) ondernemers nu op basis van dezelfde gegevensset zowel hun winstaangifte als hun jaarrekening kunnen opstellen en indienen, wat leidt tot kostenbesparing.

23 A. Lok & T. Verkade, ‘Accountantsberoep moet zich rol ketenregisseur eigen maken’, Accountancy Nieuws 2010/afl. 9, p. 10-12.

98



4. Conclusies Bedrijven en overheidsorganisaties zijn steeds beter in staat om hun bedrijfsprocessen te beheren. Processen worden expliciet vastgelegd en gevolgd. Bij procesverbetering kan men eisen vanuit wet- en regelgeving meteen meenemen. Dat heet compliance by design: de werkprocessen en informatiesystemen worden zó ontworpen, dat de organisatie aantoonbaar voldoet aan wet- en regelgeving. Dat vereist een juridische interpretatie: regelgeving is per definitie algemeen van aard; specificaties van processen en systemen zijn echter specifiek voor een situatie. In deze bijdrage hebben we geprobeerd om het benodigde vertaalproces te beschrijven. Dat hebben we gedaan aan de hand van een eenvoudig stappenplan voor juridische procesanalyse. In de praktijk draait het vaak om een aantal aandachtspunten: termijnen, overdracht, berichten, rollen en bevoegdheden, gegevensdefinities, betrouwbaarheid, beveiliging en overige eisen. De analyse moet ervoor zorgen dat met deze aandachtspunten zo veel mogelijk rekening wordt gehouden, zodat de resulterende processen en informatiesystemen effectief en rechtmatig zijn. Een juridische analyse is dus onontbeerlijk om tot een goed proces te komen. Maar wie moet een juridische procesanalyse gaan uitvoeren? Welke competenties heeft men daarvoor nodig? Systeemarchitecten moeten zich realiseren dat een groot deel van de ontwerpeisen aan hun systeem juridisch van aard is. Maar dergelijke eisen zijn niet in beton gegoten; ze vereisen een juridisch onderbouwde interpretatie. Daarom moet men al in een vroeg stadium gaan samenwerken. Architecten kunnen een taakanalyse uitvoeren en de informatiebehoefte bepalen. Zij kunnen ook zorgen voor een omgeving die het mogelijk maakt dat juridische kennisregels apart van de processen worden opgeslagen en beheerd. Ook voor juristen is er nog veel te winnen. Het gaat wat ons betreft te ver om zoals Richard Susskind24 het ‘einde van de jurist’ te zien opdoemen. Wel onderschrijven we dat juristen zich moeten gaan aanpassen aan de nieuwe werkelijkheid. Automatisering en standaardisatie bieden juristen enerzijds nieuwe kansen. Ze maken andere vormen van juridische dienstverlening mogelijk, denk bijvoorbeeld aan een compliance check van bedrijfsprocessen of aan het uitbesteden van het beheer van juridische kennisregels. Anderzijds stellen ze juristen voor nieuwe opgaven. Het ontwikkelen van informatiesystemen is vanuit rechtstheoretisch oogpunt interessant omdat systeemspecificaties in zekere zin ‘hard’ zijn. In tegenstelling tot wetten en regels staan ze geen verdere interpretatie meer toe. Veel keuzes over naleving, uitvoering en handhaving van wetten en regels die van oudsher in de praktijk beslist werden, bijvoorbeeld over de vraag wat geldt als voldoende bewijs van naleving, moeten nu al in de ontwerpfase worden gemaakt. Dat is mogelijk een van de redenen dat het ontwikkelen van informatiesystemen bij de overheid in de praktijk zo lastig blijkt te zijn.25 Of populair gezegd: wanneer we het niet

24 R. Susskind, The End of Lawyers? Rethinking the Nature of Legal Services, Oxford: Oxford University Press 2008. 25 Algemene Rekenkamer, Lessen uit ICT-projecten bij de overheid. Deel A, 2007.


99

J. Hulstijn

wenselijk vinden dat programmeurs de implementatiekeuzes maken, moeten we ons verdiepen in het vertaalproces van wetten naar informatiesystemen.

100


Het inbouwen van regelgeving in bedrijfsprocessen en informatiesystemen *

Recommend Documents