De bouw- en technieksector kent een lange keten van fabrikanten, groothandels, bouwbedrijven, installatiebedrijven, onderhoudsorganisaties en opdrachtgevers. Al deze partijen wisselen voortdurend informatie met elkaar uit: van productgegevens en offertes tot bestellingen, leverbonnen en facturen.
Die uitwisseling lijkt eenvoudig, maar wordt complex zodra organisaties verschillende ERP-systemen, artikelnummers, gegevensstructuren en processen gebruiken. Een bestelling die bij de ene partij automatisch uit het ERP-systeem komt, moet bij een andere partij immers ook op de juiste manier worden geïnterpreteerd.
De DICO Standaard is ontwikkeld om precies dat probleem op te lossen. DICO biedt afspraken voor elektronische informatie-uitwisseling tussen partijen in de bouw- en technieksector. Systemen hoeven daardoor niet hetzelfde te zijn. Ze moeten de uitgewisselde informatie wel op dezelfde manier kunnen begrijpen.
1. Wat is de DICO Standaard?
DICO is een Nederlandse standaard voor digitale informatie-uitwisseling binnen de bouw- en technieksector. De standaard wordt beheerd door Ketenstandaard Bouw en Techniek en wordt gebruikt door onder andere fabrikanten, groothandels, bouw- en onderhoudsbedrijven, installateurs en woningcorporaties.
De kern van DICO is standaardisatie. Wanneer twee organisaties digitaal gegevens willen uitwisselen, moeten zij afspraken maken over de betekenis en structuur van die gegevens. Wat bedoelen we bijvoorbeeld met een ordernummer? Hoe identificeren we de leverancier? Welke gegevens horen bij een orderregel? En hoe geven we aantallen, prijzen, afleverlocaties en btw-informatie door?
Wanneer iedere combinatie van klant en leverancier daar afzonderlijke afspraken over maakt, ontstaat een groot aantal koppelingen en uitzonderingen. DICO probeert dat te voorkomen door één gemeenschappelijke taal te definiëren.
Daarmee is DICO nadrukkelijk geen softwarepakket. Het is een verzameling afspraken waarmee verschillende systemen gegevens volgens dezelfde structuur kunnen uitwisselen.
Het gebruik is inmiddels breed verspreid. Volgens Ketenstandaard gebruiken ruim 4.000 organisaties de DICO Standaard en ondersteunen meer dan 130 aangesloten softwareleveranciers de uitwisseling via hun systemen.
2. DICO gaat veel verder dan alleen elektronische facturen
DICO wordt regelmatig in verband gebracht met e-facturatie. Dat is logisch: de elektronische factuur is een belangrijk onderdeel van de standaard. Maar wie DICO alleen als factuurstandaard beschouwt, mist een belangrijk deel van de waarde.
De standaard ondersteunt verschillende soorten transactieberichten. Daaronder vallen onder andere offerteaanvragen, offertes, orders, orderbevestigingen, leverbonnen en facturen. Daarnaast bestaan er berichten voor onder meer artikel- en productgegevens en specifieke toepassingen zoals verhuur en onderhoud.
Daarmee kan informatie gedurende een veel groter gedeelte van het commerciële proces digitaal door de keten bewegen.
Een proces kan bijvoorbeeld beginnen met een digitale offerteaanvraag. Na overeenstemming ontstaat een order. De leverancier ontvangt deze order rechtstreeks in het eigen systeem en stuurt vervolgens een orderbevestiging. Bij levering volgt een elektronische leverbon en uiteindelijk een gestructureerde factuur.
Dat levert een belangrijk voordeel op: informatie hoeft niet telkens opnieuw te worden ingevoerd.
Artikelnummer, hoeveelheid, prijs, ordernummer en andere gegevens die al eerder in het proces zijn vastgelegd, kunnen gedurende de keten worden hergebruikt. Daarmee neemt niet alleen de hoeveelheid administratief werk af, maar ook de kans op interpretatiefouten.
DICO richt zich dus niet uitsluitend op het digitaliseren van documenten. De standaard maakt het mogelijk om de onderliggende data rechtstreeks tussen systemen uit te wisselen.
3. Van documentuitwisseling naar gestructureerde data
Dat onderscheid tussen documenten en data is essentieel.
Een PDF-factuur kan digitaal worden verstuurd, maar blijft in essentie een document dat voor menselijke consumptie is gemaakt. Een medewerker kan de informatie lezen, maar software moet de inhoud eerst herkennen of interpreteren voordat deze gegevens automatisch kunnen worden verwerkt.
Bij gestructureerde elektronische berichten ligt dat anders.
Een ordernummer staat niet ergens visueel boven aan een pagina, maar bevindt zich op een vooraf afgesproken positie in de gegevensstructuur. Hetzelfde geldt voor bijvoorbeeld leveranciersinformatie, orderregels, aantallen, bedragen en btw-gegevens.
Daardoor weet het ontvangende systeem niet alleen wat er staat, maar ook wat de informatie betekent.
Dat verschil maakt verdere automatisering mogelijk.
Een order kan automatisch in het systeem van de leverancier terechtkomen. Een ontvangen orderbevestiging kan met de oorspronkelijke bestelling worden vergeleken. Een leverbon kan worden gekoppeld aan dezelfde order en een factuur kan vervolgens automatisch worden gecontroleerd tegen wat besteld en geleverd is.
Hoe consistenter die gegevens door het proces bewegen, hoe minder interpretatie later nodig is.
Dat is vooral relevant voor Purchase-to-Pay. De kwaliteit van factuurautomatisering wordt namelijk niet alleen bepaald op het moment dat de factuur binnenkomt. Veel afwijkingen ontstaan eerder in het proces: verkeerde artikelnummers, ontbrekende orders, afwijkende prijzen, inconsistente leveranciersgegevens of verschillen tussen bestelling en levering.
Door eerder in de keten gestructureerde informatie uit te wisselen, ontstaat een betere basis voor automatische verwerking aan het einde ervan.
4. DICO, XML, UBL en Peppol zijn niet hetzelfde
Rond elektronische gegevensuitwisseling worden verschillende begrippen regelmatig door elkaar gebruikt. DICO, XML, UBL en Peppol hebben echter ieder een andere rol.
XML is allereerst een technische manier om gestructureerde gegevens vast te leggen. XML bepaalt hoe gegevens technisch kunnen worden opgebouwd, maar zegt op zichzelf nog niet welke bedrijfsinformatie moet worden uitgewisseld of welke betekenis die informatie heeft.
Een standaard zoals DICO voegt die afspraken toe. De standaard bepaalt bijvoorbeeld welke gegevens in een bepaald bericht voorkomen, hoe deze worden geïnterpreteerd en welke afspraken gelden voor de uitwisseling ervan.
UBL is eveneens een standaard voor elektronische bedrijfsdocumenten. UBL wordt internationaal toegepast en vormt onder meer de basis voor veel elektronische factuur- en orderformaten.
Peppol moet weer vanuit een ander perspectief worden bekeken. Peppol biedt een internationaal afsprakenstelsel en netwerk waarmee organisaties gestandaardiseerde elektronische documenten kunnen uitwisselen.
DICO richt zich juist sterk op de specifieke informatiebehoefte van de bouw- en technieksector.
Deze begrippen zijn daarom niet simpelweg alternatieven voor elkaar. In een integratielandschap kunnen verschillende standaarden, formaten en transportkanalen naast elkaar bestaan.
5. Standaardisatie maakt verdere automatisering mogelijk
Het technische versturen van een bericht is uiteindelijk maar een deel van het vraagstuk.
De grotere waarde ontstaat wanneer organisaties de ontvangen gegevens ook automatisch kunnen verwerken.
Stel dat een inkopende organisatie een order elektronisch verstuurt. De leverancier hoeft die order dan niet handmatig over te nemen, maar kan deze automatisch importeren. Wanneer vervolgens de orderbevestiging terugkomt, kunnen prijs en hoeveelheid automatisch tegen de oorspronkelijke bestelling worden gecontroleerd.
Na levering kan dezelfde relatie opnieuw worden gelegd met de leverbon. Komt uiteindelijk de factuur binnen, dan zijn veel gegevens al bekend.
Hier ontstaat de basis voor automatische matching.
In plaats van iedere factuur afzonderlijk te beoordelen, kan het systeem vaststellen of bestelling, levering en factuur met elkaar overeenkomen. Alleen uitzonderingen vereisen dan nog aandacht.
Standaardisatie vermindert daarmee de hoeveelheid interpretatie die tijdens het proces nodig is.
Dat is belangrijk, want automatisering werkt het betrouwbaarst wanneer gegevens voorspelbaar zijn. Wanneer dezelfde informatie telkens in een andere structuur binnenkomt, zijn mappings, herkenning of aanvullende controles nodig. Hoe uniformer de gegevensuitwisseling, hoe groter het gedeelte van het proces dat deterministisch kan worden afgehandeld.
6. Een DICO-koppeling begint bij goede data en procesafspraken
Een standaard lost echter niet automatisch alle problemen in een proces op.
Wanneer gegevens in het bronsysteem onjuist zijn, worden die gegevens dankzij een elektronische koppeling vooral sneller doorgegeven. Dat maakt datakwaliteit een belangrijk onderdeel van iedere implementatie.
Partijen moeten bijvoorbeeld eenduidig kunnen worden geïdentificeerd. Binnen DICO kunnen daarvoor onder andere GLN's worden gebruikt. Een Global Location Number is een unieke identificatie waarmee een bedrijf of locatie binnen elektronische berichten herkenbaar wordt gemaakt.
Daarnaast spelen artikelgegevens een belangrijke rol. Een fabrikant kan een product op een bepaalde manier classificeren, terwijl een groothandel daar commerciële en logistieke artikelgegevens aan toevoegt.
Ook intern moeten processen aansluiten.
Welke gegevens bevat een order altijd? Wanneer is een ordernummer verplicht? Hoe worden afleverlocaties geregistreerd? Welke toleranties gelden bij prijsverschillen? En wat gebeurt er wanneer een ontvangen bericht niet aan de afgesproken structuur voldoet?
Een succesvolle DICO-implementatie vraagt daardoor om meer dan een technische koppeling.
- de kwaliteit van stamdata;
- identificatie van klanten, leveranciers en locaties;
- artikel- en productgegevens;
- inrichting van het ERP-systeem;
- mappings tussen interne en externe gegevensstructuren;
- procesafspraken met handelspartners;
- validatie van inkomende en uitgaande berichten;
- en de afhandeling van uitzonderingen.
7. DICO als onderdeel van een breder integratielandschap
Voor organisaties in de bouw- en technieksector is DICO zelden de enige vorm van digitale gegevensuitwisseling.
De ene leverancier werkt volledig volgens DICO, een andere verstuurt UBL-facturen via Peppol, terwijl weer een andere partij gebruikmaakt van een API, EDI, SFTP of zelfs nog PDF per e-mail.
Aan de ontvangende kant wil je die verschillen zo min mogelijk terugzien in het financiële proces.
Daar ontstaat de rol van een integratielaag.
Een oplossing als 4CEE Exchange kan verschillende kanalen en gegevensformaten samenbrengen. Inkomende informatie kan worden ontvangen, gevalideerd en waar nodig geconverteerd naar het formaat dat het achterliggende ERP- of financiële systeem verwacht. Voor uitgaande berichten werkt dat principe andersom.
DICO wordt daarmee onderdeel van een bredere architectuur voor document- en data-uitwisseling.
Dat is uiteindelijk ook de gedachte achter standaardisatie: organisaties hoeven niet hetzelfde systeem te gebruiken om digitaal te kunnen samenwerken. Ze moeten het wel eens zijn over de betekenis van de informatie die zij uitwisselen.
DICO maakt die afspraak concreet voor de bouw- en technieksector.
En juist wanneer orders, leveringen en facturen volgens dezelfde afspraken door de keten bewegen, ontstaat meer dan alleen een snellere gegevensuitwisseling. Er ontstaat een betrouwbaardere basis voor automatische verwerking, controle en verdere optimalisatie van financiële processen.