In de logistieke wereld is een stammenstrijd gaande, die kort samengevat neerkomt op API versus EDI. Voorstanders van API’s vinden EDI maar niets voor het uitwisselen van data en vice versa. Gaat API het van EDI winnen? Of is het nog niet tijd om EDI definitief af te schrijven?
API’s lijken aan de winnende hand, maar zeker niet iedereen vindt dat het al tijd is om EDI af te schrijven. Gaan API’s het jarenlang – vooral door de retail – gepushte EDI uiteindelijk overbodig maken? En wat moet de logistieke sector met ontwikkelingen als blockchain en initiatieven als iShare? Op alle fronten werken partijen die voldoende in de melk te brokkelen hebben aan meer standaardisatie, aan meer zekerheid en betrouwbaarheid, nu het delen van data in de supply chain op ieders wensenlijstje staat. Maar niet iedereen zit op dezelfde lijn, niet iedereen wil hetzelfde.
EDI is nog verre van dood
Application Programming Interfaces (API’s) mogen dan in opkomst zijn als basis waarop softwareapplicaties onderling kunnen communiceren, Electronic Data Interchange (EDI) is nog verre van dood. EDI is de technologie voor de elektronische uitwisseling van bedrijfsdocumenten zoals orders, facturen en bevestigingen, en bestaat al tientallen jaren. Toch is de populariteit van EDI nooit erg groot geweest. Retailers hebben vanaf de jaren negentig wel hun best gedaan om zoveel mogelijk ketenpartners over te laten stappen op EDI. Het doel was en is een gestandaardiseerde en stabiele berichtenuitwisseling. Dreigen met het verbreken van een leverancier-retailerrelatie als de leverancier niet zou overstappen op EDI was regelmatig aan de orde, maar niet heel erg effectief. De matige populariteit van EDI heeft als oorzaak dat het leggen van een stabiele koppeling tussen twee systemen niet goedkoop is. Daarnaast kent EDI een veelheid aan verschillende ‘standaardkoppelingen’.
Bevestigingen van berichten
Is API een welkom alternatief voor EDI? Volgens hoogleraar Informatiesystemen aan de TU Eindhoven Paul Grefen is dat misschien wel het geval, maar zijn de verschillen tussen de communicatiemiddelen niet zo groot. “Beide zijn er om samenwerking mogelijk te maken. Bij API’s maakt bedrijf B functies toegankelijk voor bedrijf A en is een interface te gebruiken voor het plaatsen van een order. Bij EDI doet partij A een verzoek aan partij B door middel van een bericht. Bijvoorbeeld een koopverzoek in de vorm van Edifact. Er komt bij EDI niet altijd een geautomatiseerd bericht terug, bij API’s wel. Maar alleen als je dit zo instelt.” Met die laatste zin vat Grefen de voor hem belangrijkste boodschap samen: “Wat je kunt bereiken tussen ketenpartners is afhankelijk van wat je hebt afgesproken. Dat geldt ook voor bevestigingen van berichten. Als je afspreekt om binnen een bepaalde tijd te reageren, dan is helder wie wanneer een bevestiging kan verwachten. EDI is daarnaast technisch gezien veel flexibeler dan in het verleden, niet slechts via directe koppelingen tussen bedrijven, maar bijvoorbeeld ook met behulp van het internet.” Webservices vloeien volgens Grefen weer voort uit het toenemend gebruik van het internet, waarbij webgebaseerde standaarden centraal staan. “Diensten van bedrijven zijn meestal de sturende factoren bij deze vorm van gegevensuitwisseling. Kijk je naar API’s, dan zijn systemen daarbij vaak leidend voor het ontwerp en de wijze van informatie-uitwisseling.”
Handleiding of chatgesprek?
Ondanks dat EDI zeer bruikbaar is voor veel bedrijven in de logistieke sector, neigt een groeiend aantal bedrijven naar de overstap op API’s. Wat is daarvan de reden? Rick Venema van Optimizers heeft één belangrijk argument: “De behoefte aan realtime informatie neemt toe, bijvoorbeeld over levertijden. Het zijn partijen als Albert Heijn en Jumbo, maar ook Amazon, Bol.com en Coolblue die dit in gang zetten. EDI is niet realtime, dus wie deze info wel direct wil hebben, zal dit met API’s moeten adresseren, bijvoorbeeld transportdata.” Loek Boortman, CTO bij GS1 Nederland vult aan: “Het verschil tussen EDI en API is een beetje als het verschil tussen een papieren handleiding en een chatgesprek. Beide zijn nuttig, maar de tendens is om zaken steeds meer met chatgesprekken af te handelen.”
STEEDS MEER DATA GAAT VIA DE CLOUD – DAARDOOR IS API STUK LOGISCHER GEWORDEN
API is vaak sneller
EDI en API hebben beide voor- en nadelen. Grefen kan zich voorstellen dat EDI een bepaalde vorm van ‘legacy’, voortkomend uit decennia aan ontwerpbeslissingen met zich meebrengt. Daarmee zou API een voorkeur hebben bij het uitwisselen van data waar het specifieke nieuwe activiteiten betreft. “Je moet je ook afvragen hoe complex een concept is en of EDI of API er eenvoudig mee overweg kan”, aldus de hoogleraar. “Systemen zijn nog niet zo slim dat ze op natuurlijke wijze efficiënt met elkaar kunnen communiceren over complexe zaken waarvan de betekenis onvoldoende is gestandaardiseerd.” Waar EDI veelvuldig in gebruik is voor het verzenden van grote hoeveelheden berichten en er eventueel sprake is van iets meer doorlooptijd tussen een actie en reactie, staat API-berichtenverkeer te boek als iets sneller. Een aspect dat gebruikers van API-verkeer volgens de hoogleraar niet uit het oog mogen verliezen is de beveiliging. “Het is noodzakelijk om afwijkingen in berichten eruit te kunnen filteren, bij EDI is de uitwisseling zo gestandaardiseerd en beveiligd dat de risico’s kleiner kunnen zijn. Wissel je als bedrijf grote hoeveelheden kleine transacties uit, dan is API misschien de betere keuze. Voor menselijke tussenkomst is immers geen of nauwelijks tijd bij grote hoeveelheden berichten.”
De situatie waarin een logistieke onderneming zich bevindt, zou de keuze moeten bepalen voor EDI dan wel API. De logistieke sector gebruikt EDI nog zeer frequent en de hoogleraar begrijpt dat. Hij stelt dat bij de stijgende populariteit van actiegebaseerde logistiek een bepaalde vorm van vertrouwen nodig is. “Je moet weten wie data kan oproepen. Data ownership is belangrijk. Hoe directer de interactie, des te efficiënter je kunt werken, maar de risico’s nemen daarmee ook toe. Dat is een boodschap die ik vaak overbreng op bedrijven. EDI-berichtenverkeer kost misschien tien seconden, API-verkeer tien milliseconden. Daarmee lijkt de eerste langzaam. Maar als het gaat om het plannen van een containerschip en de aankomst alleen al kost twee uur, dan moet je echt afwegen of het tijdsverschil van enkele seconden heel bepalend is. Boodschappen doen met een Ferrari of met een Volkswagen levert ook geen wezenlijk tijdsverschil op.”
Geen echte standaard
EDI is ouderwets en reactief, klinkt het soms. Toch weet ook René Bruijne, general manager bij TransFollow, dat een groot deel van de logistieke sector gebruik is gaan maken van EDI. “Ondanks die overstap op EDI blijft het lastig om goede standaarden te vinden. Er zijn wat mij betreft teveel ‘dialectverschillen’, waardoor een echte standaard is uitgebleven.” Bruijne vergelijkt EDI met de start van het gebruik van e-mail. “Daarbij is eerst uitleg nodig over de werkwijze van een mailbox, en werkt iemand ermee, dan dien je gestructureerde data toe te sturen én te checken of een bericht is aangekomen. EDI-implementaties zijn zwaar en lonen vooral bij langdurige relaties of als er geen keuze is. Hetzelfde geldt overigens voor douanekoppelingen.”
Zelf actief aansturen op vervangen van EDI
Het gebruik van webgebaseerde API’s heeft voor Bruijne in veel gevallen de voorkeur boven EDI. “In B2C-omgevingen werkt dit goed, je ziet direct een betalings pop-up met geheel of deels ingevulde gegevens. Bij B2B werkt dit hetzelfde, data is realtime terug te koppelen. Een gebruiker krijgt ook direct een bericht terug als er iets fout zit. Webgebaseerde API’s zijn daarnaast eenvoudiger te implementeren dan EDI.” Bruijne gelooft absoluut in de mogelijkheden van API en is van mening, dat EDI op termijn gaat verdwijnen. “Maar, maak je gebruik van EDI en werkt het, blijf er dan vooral vanaf. Is de communicatiewijze duurzaam? Dat denk ik niet, al was het maar omdat heel veel logistiek dienstverleners een kluwen aan interpretaties van EDI hebben gemaakt. Het kost bergen met geld om dit te onderhouden en te kunnen communiceren.” Volgens Bruijne zouden ldv’ers meer actief moeten aansturen op het vervangen van EDI. “Je kunt ‘ja en amen’ zeggen en volgen, of kiezen voor de stap voorwaarts. Het IoT (Internet of Things) komt er aan. Daarbij spelen API’s een sleutelrol. Dus ik zou zeggen, neem nu alvast het heft in handen.” Een overstap op API hoeft geen veel te hoge horde te zijn. “Vrijwel alle TMS- en WMS-leveranciers verwerken API al in hun systemen. Het integreren van data en systemen is echt stukken eenvoudiger dan het ooit was. Vrijwel alle IT-oplossingen zijn cloud gebaseerd, dat is niet voor niets. Data-uitwisseling neemt hand over hand toe, al was het maar omdat het gebruik van sensoren in trucks en in magazijnen ook steeds meer op gang komt. Ook die initiatieven zijn allemaal API-gebaseerd.”
Uitgelachen om EDI
Wout van den Heuvel, beleidsadviseur digitalisering en innovatie bij TLN en secretaris van Stichting Uniforme Transport Code (SUTC), zegt dat er weinig haast geboden is. Hij constateert, dat er onder ldv’ers weinig vragen zijn over het gebruik van API’s. “Daar moet ik wel bij zeggen, dat ldv’ers eerder met leveranciers contact zullen opnemen dan met TLN. Mijn ervaring is dat dienstverleners vooral vinden dat data-uitwisseling moet werken. De manier waarop is minder belangrijk. Vanuit SUTC willen we de koppeling tussen systemen makkelijker maken. Werken met een OTM (Open Trip Model), iShare of TransFollow heeft daarbij de voorkeur.” Boortman (GS1) heeft niet de indruk dat bedrijven bezig zijn met het afwegen van de pro’s en contra’s van EDI versus API. “Ze gebruiken API bijna maniakaal overal voor, ook voor zaken waar EDI prima zou passen. Maar je wordt tegenwoordig uitgelachen als je met een EDI-oplossing aankomt.”
Omarming API door Control Towers
De omarming van API’s door de logistieke sector is op dit moment goed zichtbaar in de toenemende populariteit van Control Towers. Daar plaatst Van den Heuvel een kanttekening bij, gezien de huidige werkwijze van ldv’ers en bijvoorbeeld retailers. “Partijen delen nog te vaak dezelfde data als gevolg van diverse API’s. Ik zou graag een standaardisatie zien in de diverse API’s, zeker als gaat om informatie, zoals welke auto onderweg is en wat erin zit. De sector moet toe naar data die doet denken aan een woordenboek. Nu gebruikt elke partij een ander woord voor vrachtauto, zoals vrachtwagen of lorry, terwijl het hetzelfde vervoermiddel is. Het OTM (Open Trip Model) zou wat TLN betreft hierin leidend moeten zijn.”
Maak een echte keuze
Voor bedrijven die willen overstappen op nieuwere technologie en daarbij API willen omarmen, heeft hoogleraar Grefen een belangrijk advies. “Ondernemingen hebben de keuze om dat in kleine stapjes te doen, maar het is volgens mij vaak beter om ineens een grote stap te zetten. Wil je veranderen, dan moet je ook een keuze maken die daarbij hoort. Het is de enige manier om echt afscheid te nemen van legacy-oplossingen.” Van den Heuvel is van mening dat de druk om te veranderen groter is dan de sector beseft. ”Steeds meer communicatie vindt geautomatiseerd plaats. Het is niet meer te doen om tientallen of honderden koppelingen met klanten handmatig aan te passen.” IT-leveranciers moeten daarin ook mee. Wat hem betreft, is het stimuleren van standaarden beter in handen van IT-leveranciers dan van verladers en LDV-ers. Nu ziet hij nog veel versnippering, vaak doelbewust. “Je moet als IT-leverancier niet willen concurreren op basis van koppelingen van systemen.”
Tradecloud ondersteunt zowel EDI als berichtenverkeer via een API.