Een aanleverketen is geen optelsom van componenten
Portaal, validatie, koppeling naar het achterliggende systeem, monitoring. Op papier bouw je een aanleverketen door die vier stukken naast elkaar te zetten. In de praktijk ontstaat het risico juist in de spleten daartussen.
Overheidsorganisaties die informatie ontvangen van externe partijen kennen het patroon. Een portaal wordt door team A ingericht. De validatie wordt door team B beheerd. De koppeling naar het bronsysteem loopt via team C. Rapportages en overzichten leven bij team D. Wanneer een aanleverende partij belt dat er iets niet goed gaat, is de eerste vraag zelden "wat is er precies mis" maar "bij wie moet ik zijn." Dat kost twee dingen die je als uitvoeringsorganisatie of toezichthouder niet kunt missen: doorlooptijd en vertrouwen. Aanleveraars die de derde keer nul reactie krijgen op een technische vraag gaan het op hun eigen manier oplossen. Doorgaans niet in jouw voordeel.
Waar het meestal misgaat:
-
Tussen portaal en validatie. Een indiener uploadt een bestand en krijgt de melding "verwerkt." Vervolgens blijkt drie dagen later dat het pakket op een filing rule is afgekeurd. De indiener heeft in de tussentijd al zijn aandacht verlegd naar iets anders en moet nu terug in het dossier. Dat had realtime gekund.
-
Tussen validatie en verwerking. Een bestand komt door de technische controle maar bevat een inhoudelijke afwijking die pas bij de eindanalyse opvalt. Wie belt de indiener? Op welke termijn? Volgens welke procedure? Deze stukken zitten vaak in beleid, niet in het systeem, waardoor ze inconsistent worden toegepast.
-
Tussen verwerking en overzicht. Managers en beleidsmakers vragen "hoe staan we ervoor" en krijgen een export die twee weken oud is. De data zit er wel, maar niet in bruikbare vorm. Er wordt een dashboard bijgebouwd. Twee jaar later zijn er zeven dashboards. Niemand weet meer welke klopt.
Wat een goede keten wél doet:
-
Realtime feedback aan de aanleveraar op het moment dat het bestand binnenkomt. Niet alleen "je bestand is geüpload" maar "je bestand is geüpload, de taxonomie klopt, filing rule 3.2.7 slaat alarm, hier is de regel in je document." Dat bespaart correctierondes en houdt aanleveraars te vriend.
-
Eén doorgaande audit trail vanaf upload tot verwerking. Niet vier logbestanden in vier systemen, maar één keten waarin je een specifiek bestand kunt volgen van "ontvangen om 14:03" tot "goedgekeurd om 14:07, doorgezet naar systeem X om 14:08." Als er iets misgaat, is de discussie feitelijk in plaats van politiek.
-
Een ontvangersdashboard dat niet apart onderhouden hoeft te worden. Als de keten zelf goed is ingericht, is het overzicht een view op wat er al is, niet een parallelle waarheid die je moet reconciliëren.
-
En bewuste keuzes over waar de knip ligt tussen jouw organisatie en de leverancier. Alles zelf bouwen kost meer dan het lijkt: de kennis over iXBRL, ketenkoppelingen, security en beheer moet ergens opgebouwd worden. Alles uitbesteden geeft afhankelijkheid. De uitvoeringsorganisaties die dit goed doen, kiezen bewust: eigenaarschap van de business logica, uitbesteding van de generieke infrastructuur.
Tot slot:
Een aanleverketen is geen IT-project, het is een procesketen met IT erin. Wie de keten als optelsom van componenten aanbesteedt, krijgt een optelsom van componenten. Wie de keten als één stroom aanbesteedt, krijgt een stroom. Klinkt flauw, maakt in de praktijk het verschil tussen een systeem dat werkt en een systeem dat zichzelf continu verklaart.
FAQ
Bekijk hier de meestgestelde vragen over dit onderwerp. Staat jouw vraag er niet tussen of heb je een opmerking? Neem gerust contact met ons op, we staan je graag te woord.
De volledige stroom waarmee externe partijen gestructureerde informatie aanleveren bij een overheidsorganisatie: van portaal en validatie tot koppeling met het bronsysteem en de rapportages die daaruit voortkomen.
Losse componenten leveren losse verantwoordelijkheden op. Als een aanleverende partij een probleem meldt, wordt de eerste vraag "bij wie moet ik zijn" in plaats van "wat is er precies mis." Dat kost doorlooptijd en vertrouwen, en aanleveraars gaan het uiteindelijk op hun eigen manier oplossen.
Op drie plekken. Tussen portaal en validatie (indiener denkt dat het pakket goed is, hoort dagen later dat het is afgekeurd). Tussen validatie en verwerking (technisch akkoord, inhoudelijke afwijking valt pas laat op, procedure onduidelijk). Tussen verwerking en overzicht (managementrapportages lopen achter, er worden losse dashboards bijgebouwd).
Realtime feedback aan de aanleveraar op het moment van uploaden, met verwijzing naar de regel in het document. Eén doorgaande audit trail van upload tot verwerking. Een ontvangersdashboard dat een view is op de bestaande keten, geen parallel systeem. En bewuste keuzes over wat je zelf doet en wat je uitbesteedt.
Nee. Het is een procesketen met IT erin. Wie het als IT-project behandelt, krijgt een technische oplossing die zichzelf continu moet verklaren. Wie het als procesketen behandelt, krijgt een stroom die werkt.
Helder krijgen welke fouten je op welk moment wilt zien, hoeveel begeleiding je aanleveraars biedt, en wat je met de binnenkomende data gaat doen. En bepalen waar de knip ligt tussen jouw organisatie en de leverancier. Die keuzes horen niet in de uitvraag pas beantwoord te worden.
