EbXML maakt bedrijven transparanter voor elkaar

Als voorlopig antwoord past hier de opmerking dat interoperabiliteit bij e-business tussen bedrijven geen eendimensionaal probleem is, maar vele deelproblemen kent. Er bestaan geen wondermiddelen. EbXML is een heel bouwwerk, dat deze deelproblemen stuk voor stuk aan de orde stelt. Dat XML een onmisbare basisstandaard is in dit bouwwerk mag geen verwondering scheppen. Waarom ebXML? Al jaren proberen bedrijven hun onderlinge elektronisch zakenverkeer te automatiseren uit overwegingen van efficiëntie en foutreductie. De leidende technologiestandaarden zijn daarbij altijd EDI en Edifact geweest. Met de komst en doorbraak van XML is er een discussie ontstaan over de meerwaarde van XML tegenover EDI. Dat XML de ideale oplossing zou zijn voor interoperabiliteit over bedrijfsgrenzen heen en daarmee een volledige vervanger van EDI, is onderhand voldoende genuanceerd. XML sec zal slechts de opvolger van de EDI-syntax (structuur) kunnen zijn; de standaardisatie van de berichteninhoud is een uitdaging die XML evengoed te wachten staat, sterker nog, waarvoor XML te rade kan en moet gaan bij de enorme ervaring en kennis die in Edifact is opgedaan. Niettemin heeft de jarenlange ervaring met Edifact een aantal nieuwe problemen aan de dag gelegd. • De hoge initiële kosten van EDI-gebruik hebben ervoor gezorgd dat met name grote en draagkrachtigere bedrijven onderling EDI gebruiken; voor kleinere bedrijven is EDI te hoogdrempelig. • Daarnaast zijn er hoge kosten verbonden aan het feitelijk realiseren van een EDI-relatie, op het moment dat bedrijven hebben besloten elektronisch zaken te willen doen. Dat zorgt ervoor dat EDI met name wordt gebruikt in vaste relaties. • De klassieke berichtenstandaardisatie is statisch. Het kost veel tijd en inspanning om in een geschikt gremium te komen tot afspraken over berichten. Daarmee kan de berichtenstaandaardisatie geen gelijke tred houden met veranderende behoeften. • De klassieke berichtenstandaardisatie is grotendeels branchegewijs georganiseerd. Bedrijven functioneren in het algemeen echter in meerdere branches tegelijkertijd. • Interoperabiliteit over bedrijfsgrenzen heen valt uiteen in veel deelaspecten. Het is niet voldoende te beschikken over hetzelfde syntaxformalisme (zelfs als dat XML is) noch te beschikken over dezelfde berichtenstructuren. Er spelen ook vragen op lagere niveaus, zoals de infrastructuur en op hogere niveaus, zoals de bedrijfsprocessen die de context zijn van de uitgewisselde berichten. Met de komst van XML is een groot aantal initiatieven ontstaan die EDI-berichtenstandaarden rechtstreeks vertalen naar XML-formaat. De discussie over wat daarvan de voor- en nadelen zijn, willen we hier achterwege laten. Feit is dat hierdoor een groot aantal, per stuk waardevolle, initiatieven zijn ontstaan, die een aantal van bovenstaande problemen verkleinen. Zo zullen in het algemeen de initiële kosten dalen en zal e-business binnen het bereik komen van meer bedrijven. Op de andere hierboven genoemde vragen is een pure formaatvertaling van EDI naar XML echter geen afdoende antwoord. Daarom zijn UN/Cefact en Oasis gestart met het ebXML-initiatief. UN/Cefact is het centrum van de Verenigde Naties ter facilitering van de handel en e-business. Oasis is een wereldwijd consortium van (vooral) ICT-bedrijven voor e-business-standaardisatie. Het project ebXML begon in de herfst van 1999 met de bedoeling consistentie te realiseren in het gebruik van XML in de elektronische uitwisseling van bedrijfsgegevens. Gedurende achttien maanden hebben bedrijvenconsortia, standaardisatie-organisaties, ICT-aanbieders, consultants en gebruikers wereldwijd deelgenomen. In mei 2001 heeft ebXML een set van specificaties en white papers opgeleverd. EbXML is een omvattende branche-overstijgende raamwerkstandaard voor elektronische uitwisseling van bedrijfsgegevens en -berichten. XML, als syntactische standaard, vormt de basis. Hoewel ebXML omvattend is – omdat het interoperabiliteit op meerdere niveaus aan de orde stelt – is het geen take-it-or-leave-it-pakket; onderdelen kunnen vaak naar believen worden gekozen. De term ‘raamwerk’ geeft aan dat ebXML de definitie van feitelijke berichtenstandaarden overlaat aan daarvoor toepasselijke gremia (zoals brancheorganisaties en bedrijven) en een keur aan samenhangende faciliteiten biedt om deze standaarden te realiseren en op basis ervan tot een operationele e-business-afspraak en -relatie te komen. Qua draagvlak is ebXML veelbelovend. Het is als project namelijk een monsterverbond van de branche- en gebruikersorganisaties die binnen Edifact actief zijn, en de IT-industrie die zich heeft verenigd in de Oasis-organisatie. EbXML weet zich momenteel dus gesteund door een groot aantal brancheorganisaties, bedrijvenconsortia en individuele bedrijven over de wereld. Het kent in zijn scope geen gelijke in de wereld, hoewel er op onderdelen zeker overeenkomsten zijn met andere initiatieven. Vaak wordt op deze onderdelen dan ook samenwerking en congruentie gezocht. In Nederland wordt de ebXML-inspanning gecoördineerd door het Electronic Commerce Platform Nederland (ECP.NL) in Leidschendam. In grote lijnen zijn er vier momenten waarop ebXML ondersteuning biedt aan het realiseren van e-business (zie figuur): • standaardisatie van berichten en processen; • vastleggen van bedrijfsprofielen voor e-business; • het maken van een e-business-afspraak met zakenrelaties; • het feitelijk uitvoeren van het operationele e-business-proces. In de ebXML-benadering komen industrieconsortia en brancheorganisaties met elkaar tot afspraken over de operationele processen waarmee zij elektronisch zakendoen en de berichten die zij in dat proces uitwisselen. Deze processen worden gemodelleerd in UML met behulp van een methode met de naam UMM. De modellen worden vervolgens vertaald in XML-formaat, omdat ze moeten worden opgeslagen in een zogenaamde repository. In deze repository zijn de modellen beschikbaar voor in beginsel willekeurige andere bedrijven. Een belangrijke rol in de repository is weggelegd voor de zogenaamde core components. Dit zijn de basiselementen van berichten die in veel branches en bedrijven gebruikt kunnen worden, bijvoorbeeld de adresgegevens van een bedrijf. Daarnaast maken individuele bedrijven zich aan (potentiële) zakenrelaties kenbaar in een register door middel van een profiel. Daarmee beschrijven ze op welke manier (processen, berichten) zij elektronisch zaken kunnen doen, maar ook over welke technologie. Zij kunnen daarvoor putten uit de genoemde repository, maar dat is geen verplichting. De beschrijving van het proces is gelaagd opgebouwd. In het profiel wordt verwezen naar de processtappen en hun volgorde. Vandaaruit wordt verwezen naar beschrijvingen van de berichten, die op zich weer verwijzen naar de core components waaruit zij zijn opgebouwd. Het profiel verwijst dus op de eerste plaats naar de orderstap en de bevestigingsstap. De orderstap verwijst naar een beschrijving van het orderbericht, waarin een verwijzing naar een adressegment is opgenomen. De selectie van passende processen en berichten uit een repository is een kwestie op zichzelf binnen ebXML. Men werkt aan een mechanisme, waarin de context van een bedrijf (bijvoorbeeld de branche waarin het zich bevindt) richtinggevend is voor de keuze van processen en berichten uit de repository. Core components zijn dan contextvrij, dat wil zeggen, toepasbaar in alle contexten. Wanneer bedrijven elkaar zakelijk gevonden hebben en via het register van elkaar weten hoe zij e-business kunnen bedrijven, moeten zij op basis daarvan komen tot een gezamenlijke overeenkomst over hoe zij e-business onderling zullen laten verlopen (de pendant van het EDI Interchange Agreement). Daarvoor gebruikt men het liefst een geheel automatisch proces waarin de profielen van de betrokken bedrijven worden gecombineerd tot een overeenkomst. De structuur van een overeenkomst lijkt veel op die van een profiel, zij het dat het hier om meerdere partijen gaat. Bovendien is het de bedoeling dat een profiel vrijheidsgraden kent: bedrijven zouden op meerdere manieren e-business kunnen uitvoeren. Een overeenkomst bevat deze vrijheidsgraden niet. Idealiter is het niet meer dan de doorsnede van de profielen van de betrokken partijen. Of dit altijd zo eenvoudig is en of een overeenkomst automatisch kan worden bepaald is echter zeer de vraag. Een verkopende partij heeft bijvoorbeeld aangegeven zowel met een raamorder als een afroeporder te kunnen werken, maar alleen over HTTP te willen communiceren. Een inkopende partij geeft in haar profiel aan alleen met raamorders te werken, maar over zowel HTTP als SMTP te kunnen communiceren. De overeenkomst zal in dit geval komen tot raamorders en HTTP. Op basis van die overeenkomst moet vervolgens natuurlijk het e-business-proces ook feitelijk gaan draaien. EbXML biedt hier een aantal voorzieningen. Op de eerste plaats, en vooralsnog het meest bekend, biedt het een envelop voor berichtenuitwisseling, gebaseerd op Soap. Verder biedt het een standaardmechanisme voor signalering en monitoring, waarin bijvoorbeeld is geregeld dat er voor een bericht ontvangstbevestigingen worden uitgewisseld. Kortom, waar de repository aangeeft op welke manier bedrijven e-business zouden kunnen uitvoeren, geeft het register aan op welke manieren specifieke individuele bedrijven dat willen en kunnen. De overeenkomst ten slotte geeft aan op welke manier twee of meer bedrijven het ook feitelijk onderling gaan uitvoeren (zie figuur). Een standaardisatie-initiatief van een dergelijke omvang en impact is geen sinecure. EbXML is nog niet af. Een groot deel van de specificaties is opgeleverd (http://www.ebxml.org), maar op een aantal, ook cruciale, onderdelen moet nog werk worden verzet en is er discussie. Daarbij gaat het bijvoorbeeld over de core components, over het context- mechanisme en over profile matching. Voor de core components en de daaruit af te leiden ‘business information entities’ (componenten die op een bepaalde sector zijn toegesneden) is nu een technische specificatie ter publieke beoordeling uitgebracht. Vooral het onderscheid tussen core components en business information entities (qua betekenis en structuur) is daarin nog enigszins onduidelijk. Voor het vullen van de bibliotheek van componenten zal de Edifact-erfenis moeten worden benut. Eén van de vragen is echter of het Edifact-proces eveneens moet worden geadopteerd en of dat niet te bureaucratisch is voor het huidige internettijdperk. Een heikel punt is ook het context- mechanisme. Het huidige ebXML-concept gaat ervan uit dat iedere zakenrelatie contextueel zo duidelijk kan worden gedefinieerd, dat de daarin betrokken partijen ‘blind’ de daarbij horende berichten en business information entities uit de repository kunnen gebruiken. Dit concept gaat voorbij aan de (soms historische of toevallige) verschillen tussen bedrijven, ook ten opzichte van hun branchegenoten. Meer individuele vrijheid, en een mechanisme om ook de berichteninhoud en te doorlopen handelsprocesstappen (geautomatiseerd) te kunnen uitonderhandelen bij het totstandkomen van de uitwisselingsovereenkomst, zou wenselijk zijn. Dit laatste zou betekenen dat het ‘profile matching’-mechanisme, dat zich nu alleen beperkt tot de netwerkparameters, zich zou moeten uitstrekken tot die processtappen en berichten. De voornaamste uitdaging voor ebXML is echter om voldoende snel met een set technisch te implementeren standaarden te komen. Snelheid en bruikbaarheid gaan hier voor schoonheid. Hoe langer het duurt, hoe groter de kans dat andere (beoogde) standaarden te veel kritische massa hebben gekregen. Dat geldt vooral voor de enkele honderden XML-dialecten die al in omloop zijn. Als antwoord op de vraag die aan het begin is gesteld – Wat moeten bedrijven en brancheorganisaties met ebXML? – past op dit moment dus geen advies om grootschalig ebXML te implementeren, omdat dat nog niet kan, op onderdelen na. Wel kan er op de komst van ebXML worden geanticipeerd. Brancheorganisaties en industrieconsortia kunnen hun onderlinge e-business- afspraken, in termen van de processen en berichten, vastleggen op de ebXML- manier. In veel gevallen zullen die afspraken voor een belangrijk deel al in enige vorm beschikbaar zijn, al is het maar op papier of in bijvoorbeeld de EDI-syntax. Liefst worden de beschrijvingen van bedrijfsgegevens reeds zoveel mogelijk beschreven in UML (de taal die binnen ebXML daarvoor gebruikt wordt) en afgestemd op de core components die momenteel in ebXML worden vastgelegd. Brancheorganisaties zouden zich ten slotte kunnen beraden op het zoeken van aansluiting bij het ebXML-initiatief. Voor individuele bedrijven geldt een vergelijkbare aanbeveling. Zij zullen zich moeten presenteren aan de zakenwereld in een profiel, waarin staat beschreven op welke manier(en) zij in staat zijn elektronisch zaken te doen met andere bedrijven. Verder kunnen bedrijven hun bedrijfssystemen alvast zo inrichten dat zij dezelfde gelaagde hoofdstructuur (blauwdruk) vertonen als ebXML. Dit maakt het mogelijk om te zijner tijd stapsgewijs de passende elementen van ebXML te adopteren. AUTEUR: Paul Oude Luttighuis en Fred van Blommestein Dr.ir. Paul Oude Luttighuis is hoofd van de e- businessgroep van TNO. Ir. Fred van Blommestein CFPIM is senior-adviseur bij Berenschot Informatica en lid van zowel de EBTWG als de EWG, de internationale werkgroepen waarin ebXML wordt ontwikkeld. Berenschot en TNO zijn partners in het Europese IST-project OpenXchange, waarin samen met vooral Duitse partijen wordt gewerkt aan een demonstratie- omgeving voor ebXML.Supportmomenten