XML is geen haarlemmerolie voor EDI
Medio 2000 gebruikte slechts iets meer dan 5 procent van de transportbedrijven electronic data interchange om gegevens uit te wisselen. EDI te duur „De toepassing van EDI is blijven steken bij de honderd grootste verladers. Het is gewoon te duur voor het midden- en kleinbedrijf, en de meeste transportbedrijven zijn MKB”, verklaart dr.ir. Wout J. Hofman van Deloitte & Touche Bakkenist. (Toen nog) Bakkenist heeft in het verleden samen met de Stichting UTC een generiek EDI-werkstation ontwikkeld voor kleinere bedrijven. Deloitte & Touche Bakkenist en UTC hebben er inmiddels een apart bedrijf voor opgezet: TMS bv. De EDI-werkstation-oplossing is met redelijk succes aan de man gebracht, maar werd lang niet zo populair als een onderdeel ervan: de module voor het printen van formulieren en vrachtbrieven. Het pakket waarin die printfunctionaliteit is ondergebracht kent inmiddels 2500 installaties, niet alleen bij kleine, maar ook bij een aantal zeer grote transporteurs en verladers. Het verschil in belangstelling is in twee opzichten karakteristiek voor de transportbranche. Enerzijds is het een uiting van het belang van het medium papier in de sector. Papier dient niet alleen voor de overdracht van informatie tussen opdrachtgever en vervoerder, vrachtbrieven worden tevens gebruikt als bewijs van contract en bewijs van levering. „Je ziet zelfs dat men in bepaalde sectoren van transport die vrijstelling hebben van het gebruik van vrachtbrieven, die vrachtbrief toch weer in wil voeren omdat er allerlei conflicten ontstonden rond de verdwijning van verpakkingsmateriaal”, aldus Hofman. „Daaruit kun je afleiden dat formulieren pas kunnen verdwijnen als de bewijsfunctie in de elektronische variant van de vrachtbrief geregeld is.” Anderzijds is de populariteit van een relatief simpele oplossing voor het printen van formulieren een uiting van de praktische inslag die de meeste bedrijven hebben. Men grijpt een kans die zich aandient. Maar de marges in de transportwereld zijn smal, dus men zit niet te wachten op grootschalige investeringen met onduidelijke terugverdientermijnen. En dat was zoals gezegd de grootste bottleneck voor invoering van EDI. EDI-projecten waren altijd behoorlijk ingrijpend, en gingen met de nodige kosten gepaard. „Zo’n project om tot elektronische uitwisseling van berichten te komen begon ermee dat de betrokkenen processen op elkaar moesten afstemmen en daarbij de EDI-berichten gingen specificeren. Vervolgens moest men dan nog relatief dure postbussoftware installeren en parametriseren, en meestal ook programmeren, want er was geen standaard interface tussen applicaties en de EDI-software. En tenslotte moest men dan ook nog een relatief dure datacommunicatielijn huren bij de PTT”, aldus Hofman. XML De eXtensible Markup Language zou aan deze problemen een eind maken. Die indruk wekken althans de apostelen van deze markeertaal. XML lijkt qua structuur op HTML, dat gebruikt wordt voor het opzetten van web-pagina’s. Ieder gegevenselement dat partijen uitwisselen wordt voorafgegaan en afgesloten door een markering (in jargon een tag) die aangeeft wat het element betekent. Een XML-bericht is daardoor wel een stuk omvangrijker dan een EDI-bericht, maar het is daardoor wel te interpreteren. De betekenissen van de markeringen worden vastgelegd in zogeheten document type definitions, ofwel DTD’s. Bedrijven die elkaar van hun DTD’s op de hoogte hebben gebracht, kunnen alle voordelen van EDI genieten, maar dan met goedkope Internet-technologie, dat wil zeggen goedkope software en goedkope communicatielijnen. Bovendien is kennis van XML dankzij verwantschap ervan met HTML en SGML redelijk verspreid, dus is personeel met kennis van deze technologie relatief eenvoudiger aan te trekken. Een laatste voordeel is het interactieve karakter van de gebruikte technologie. Oplossingen op basis van XML lenen zich dus niet zoals EDI alleen voor batch-communicatie, maar zijn als de noodzaak zich voordoet ook voor ad hoc-communicatie te gebruiken, bijvoorbeeld het op het laatste moment wijzigen of toevoegen van zendingen aan een al gemaakte planning. Werk blijft Het lijkt alsof XML de oplossing biedt voor alle problemen die de doorbraak van EDI hebben gefrustreerd. Maar dat is wat kort door de bocht geredeneerd, stelt Hofman. „Eén van de dingen die niet verandert, is dat je veel werk moet steken in het opstellen van standaard berichten. Je moet waken voor de situatie dat je met iedere handelspartij eigen XML-berichten gaat zitten definiëren. Dat leidt heel snel tot een brei van verschillende berichten die niet meer te begrijpen en te onderhouden zijn. Bij EDI zag je ook dat men erop vertrouwde dat de eigen EDI-specialist het wel zou regelen. Totdat die specialist een nieuwe baan vond... Ongetwijfeld zal een aantal bedrijven weer in die valkuil trappen, maar wie bilaterale oplossingen creëert loopt tegen dezelfde problemen aan als bij de voorlopers van Edifact. In principe moet je voor XML dus weer dezelfde standaarden ontwikkelen die ook al voor Edifact zijn ontwikkeld. Dat betekent dat precies gespecificeerd moet worden wat je verstaat onder adres, besteldatum, leverdatum et cetera en dat die specificaties vertaald moeten worden naar XML-tags en -DTD’s. Het enige voordeel dat je daarbij hebt is dat een deel van het werk al gedaan is bij de ontwikkeling van EDI-berichten.” Procesafstemming Niet alleen de specificatie-inspanningen nemen een deel van de voordelen van XML ten opzichte van EDI weg. Ook de problematiek van procesafstemming wordt door veel XML-profeten ten onrechte onder het kleed geveegd, stelt Hofman. „EDI draaide om meer dan elektronische gegevensuitwisseling. Natuurlijk, door gegevens elektronisch uit te wisselen kun je wat besparen op overtypen en de administratieve kosten die daarmee samenhangen. Maar als je je daartoe beperkt, laat je de meest interessante mogelijkheden onbenut. Optimaal zou zijn gegevensuitwisseling te gebruiken om processen beter af te stemmen. De transporteur zou daardoor beter kunnen plannen, zodat hij minder lege kilometers rijdt. Dat vraagt echter meer dan afspreken welke gegevens je wilt uitwisselen, je moet ook bekijken hoe de processen bij de betrokkenen verlopen en welke aanpassingen elektronische gegevensuitwisseling in die processen mogelijk maakt zodat de afstemming verbetert. Dat betekent dus ook aanpassingen in de informatiesystemen die die processen ondersteunen.” Dat laatste lost XML niet op, constateert Hofman. „Het ontsluiten van andere systemen blijft nog steeds een probleem dat de betrokken bedrijven zelf moeten oplossen, evenals het probleem van het aanpassen van systemen en processen. Bij EDI gingen vooral daar de kosten in zitten, en dat zal bij XML niet anders zijn. De kosten worden hooguit lager omdat de gehanteerde techniek goedkoper is, maar de techniekkosten waren nooit de bulk van de EDI-kosten.” Middleware Exit XML, dus? Dat nu ook weer niet direct. XML zal volgens Hofman wel degelijk een rol spelen, maar dan vooral op de achtergrond als onderdeel van middleware-technologie voor systeemintegratie. „Er komen nieuwe partijen op in de transportketen. Denk aan elektronische marktplaatsen. Maar er komen ook dienstverleners die administratieve processen kunnen overnemen. Een voorbeeld is mycustoms.com, een Amerikaans bedrijf waar wij een letter of intent mee hebben getekend voor de Europese vertegenwoordiging. Dat bedrijf verzorgt de douaneaangifte voor Amerikaanse bedrijven, inclusief de berekening van de afdracht en de afdracht zelf voor 7 dollar per aangifte. Hier kost die procedure bedrijven 80 tot 200 gulden. Nu is de situatie hier niet geheel vergelijkbaar met de Amerikaanse, maar het geeft wel aan dat er belangrijke besparingen te behalen zijn door het uitkoppelen van processen die niet tot je kerncompetentie behoren. Als je de vrijheid wilt hebben om met dergelijke nieuwe partijen te communiceren, is het belangrijk om je interfaces te standaardiseren. Daarvoor is XML één van de fundamenten. Maar dat is niet iets om zelf te ontwikkelen. Dergelijke middleware moet je bij voorkeur aanschaffen als onderdeel of verlengstuk van een pakketoplossing.” De EDI-werkstation-oplossing is met redelijk succes aan de man gebracht, maar werd lang niet zo populair als een onderdeel ervan: de module voor het printen van formulieren en vrachtbrieven. foto: ries van wendel de joode