Overheden hebben de afgelopen jaren grote stappen gezet in digitalisering. Er is geïnvesteerd in verfijnde procesmodellen, moderne zaaksystemen en slimme API-koppelingen. Daarbij gaat veel aandacht naar de invoer van gegevens, via formulieren en frontofficeprocessen en naar de opslag van informatie, bijvoorbeeld via zaakgericht werken en documentmanagementsystemen.
Maar zodra alle informatie is verzameld, gecontroleerd en opgeslagen, komt het moment dat voor de burger of klant het meest zichtbaar is: de output. Precies op dat punt gaat het vaak mis.
In de meeste overheidsapplicaties is documentcreatie en documentoutput een sluitpost. Technisch wordt het ergens achteraan geplakt, procesmatig wordt er nauwelijks over nagedacht en strategisch krijgt het amper aandacht. Het wordt meestal overgelaten aan de leverancier van een applicatie of op projectniveau geïmproviseerd. Dat is problematisch, want documentoutput is niet zomaar het einde van een traject. Het is de laatste en vaak enige tastbare interactie tussen overheid en burger. Een verkeerde naam, foutieve gegevens of onduidelijke formulering kan in één klap het hele proces onderuit halen. Bovendien is het vaak de plek waar privacygevoelige informatie letterlijk zwart op wit staat. Een verkeerd geadresseerde brief of een onjuist samengestelde PDF kan leiden tot datalekken, juridische problemen en ernstige imagoschade.
Nederland beschikt over sterke architectuurkaders voor de overheid, zoals de Gemeentelijke Modelarchitectuur (GEMMA) en de Nederlandse Overheid Referentie Architectuur (NORA). Deze modellen bieden houvast bij het structureren van processen, gegevensopslag en onderlinge koppelingen. Ze beschrijven uitvoerig hoe data wordt beheerd, hoe processen verlopen en hoe systemen met elkaar communiceren.
Toch krijgt de outputkant ook hierin nauwelijks een volwaardige plaats. In de praktijk wordt documentoutput vaak gereduceerd tot een technische koppeling. Er wordt vanuit een applicatie een PDF verstuurd naar een ander systeem, en daarmee is het afgedaan. Functionele en strategische overwegingen, zoals consistentie in toon en opmaak, kanaalstrategie of (digitale) toegankelijkheid, worden zelden meegenomen. De impliciete boodschap lijkt dat opslag en proces de kern vormen, en dat output bijzaak is. Dat leidt ertoe dat de vertaalslag naar veilige, begrijpelijke en consistente communicatie met de burger vaak geïmproviseerd wordt.
Wie een willekeurig applicatielandschap van een overheidsinstantie bekijkt, ziet al snel hoe gefragmenteerd het is. Elke applicatie heeft zijn eigen manier om documenten te maken. Soms is dat een ingebouwd sjabloonmechanisme, soms een koppeling met een tekstverwerkingssysteem en soms handmatig knip- en plakwerk. Het gevolg is dat burgers berichten ontvangen die per applicatie verschillen in opmaak, lettertype, aanhef en schrijfstijl. Een brief over een parkeervergunning ziet er daardoor heel anders uit dan een brief over gemeentelijke belastingen, ook al komen beide uit dezelfde gemeente.
Het beheer van die output is eveneens versnipperd. Een wijziging in logo, huisstijl of juridische tekst moet in elk systeem afzonderlijk worden doorgevoerd, wat foutgevoelig en tijdrovend is. Daar komt bij dat berichten via uiteenlopende kanalen bij de burger terechtkomen. Soms verschijnt een PDF in een portaal, soms wordt een bericht via MijnOverheid verstuurd en soms ontvangt iemand een e-mail. Voor de burger voelt dit alsof hij te maken heeft met verschillende instanties, terwijl het in werkelijkheid één en dezelfde organisatie is.
Output (van bijvoorbeeld documenten) omvat een hele keten van keuzes en aanpassingen. Het proces begint met de vraag via welk kanaal een boodschap de ontvanger bereikt. Dat kan een fysieke brief zijn, een e-mail, een bericht in een portaal of een signaal via een API. Elk kanaal heeft eigen eisen voor beveiliging, toegankelijkheid en opmaak.
Vervolgens moet de output worden omgezet naar specifieke formaten, zoals PDF/A voor archivering, XML of JSON voor machineleesbaarheid, of HTML voor webpublicatie. Zonder goede metadata – denk aan archiefcodes, statusinformatie en autorisatieniveaus – is het bijna onmogelijk om later iets terug te vinden of te controleren.
Output raakt ook aan de diversiteit van eindgebruikers. Iemand die laaggeletterd is, of een visuele beperking heeft, beleeft de output anders dan iemand zonder die uitdagingen. Dat betekent dat zaken als begrijpelijkheid en visuele toegankelijkheid altijd een rol moeten spelen. Output kan daarom niet worden gezien als een technisch sluitstuk, maar moet een integraal onderdeel zijn van de ketenarchitectuur.
In de meeste architectuurmodellen ontbreekt een volwaardige plek voor documentoutput. Of je nu kijkt naar GEMMA, Novius, Common Ground of lokale enterprise-architecturen: output wordt zelden als domein gedefinieerd. Daardoor ontstaan drie structurele problemen: Er zijn geen standaardkoppelingen voor outputservices, waardoor elke applicatie zelf moet uitvinden hoe documenten worden gegenereerd en verstuurd. Ook is er geen eenduidige beheerstructuur, waardoor verantwoordelijkheden versnipperd zijn. En er ontbreekt een centraal beleid voor output, terwijl dat voor data, processen en beveiliging wel aanwezig is.
De oplossing ligt voor de hand, maar vraagt om een omslag in denken. Documentcreatie en -output zouden als gedeelde dienst in de architectuur moeten worden opgenomen. Net zoals er centrale voorzieningen bestaan voor authenticatie of dataopslag, kan er ook een centrale documentgeneratieservice worden ingericht. Daarmee ontstaat grip op opmaak, consistentie en distributie, en wordt het veel eenvoudiger om nieuwe kanalen toe te voegen of wijzigingen centraal door te voeren.
De output is eigenlijk het ‘moment van de waarheid’ in de relatie tussen overheid en burger. Alles wat voorafgaat aan dat moment – het verzamelen van gegevens, het verwerken van aanvragen, het uitvoeren van berekeningen – komt samen in een boodschap, die direct bij de burger landt. Juist daarom moet output beheersbaar zijn, met centrale sturing op sjablonen, kanaalkeuze en metadata. Het moet veilig zijn, met strenge controles op autorisatie, adressering en inhoud. En het moet consistent zijn, zodat burgers altijd dezelfde kwaliteit en stijl ervaren, ongeacht vanuit welk systeem een bericht wordt gegenereerd.
Om dat te bereiken is technische modularisatie nodig. Een organisatie kan werken met herbruikbare componenten, die documenten samenstellen op basis van gegevens uit verschillende bronnen, met systemen waarin alle sjablonen en huisstijlregels centraal worden beheerd en bepalen via welk kanaal een document wordt verzonden. Door output zo te structureren, verandert het van een vergeten sluitpost in een strategische schakel in de keten.
Zonder gerichte aandacht voor output, verliest digitalisering haar waarde voor de eindgebruiker. Een perfect werkend zaaksysteem dat gekoppeld is aan uitstekende dataopslag en beveiliging, verliest zijn nut als de communicatie met de burger slordig, inconsistent of onveilig is. De eerste stap naar verbetering is het toekennen van een volwaardige plek aan output in architectuurmodellen. Wanneer eenmaal is vastgelegd hoe documentcreatie en distributie als generieke capability worden ingericht, volgt de rest vanzelf.
Door outputservices als herbruikbare componenten te ontwerpen, governance te organiseren zoals dat ook voor data en processen gebeurt en de beleving van de burger te integreren in de communicatiestrategie, kan documentoutput uitgroeien van een geïmproviseerde bijzaak tot een bewuste, strategische en veilige schakel. Zo is documentcreatie geen blinde vlek meer, maar een essentieel onderdeel van een volwassen overheids-ICT-architectuur.
Wie zich in de wereld van softwarehuizen — de zogeheten Independent Software Vendors (ISV’s) — begeeft, weet dat de druk om te moderniseren groot is. Veel leveranciers van applicaties worstelen met legacy-software en klanten die verwachten dat hun oplossing altijd actueel en toekomstbestendig is.
Lees meer
Het valt niet mee een organisatie te vinden, waar geen grote aantallen documenten gecreëerd worden. Documentcreatie is onmisbaar, maar tegelijkertijd technisch vaak ondergewaardeerd. Het vindt meestal plaats aan het einde van een proces, als een soort sluitstuk. Ieder systeem doet het op zijn eigen manier: het CRM genereert PDF’s vanuit zijn sjablonen, het zaaksysteem gebruikt Word-templates, het DMS biedt z’n eigen exportfunctie.
Lees meer
Xential is ISO 27001 gecertificeerd. Daar ging een periode aan vooraf waarin we de systeem- en informatiebeveiliging minutieus onder de loep namen.
Lees meer