Elektronische orderuitwisseling voedingsketen

[Particularia]

Ik ben op zoek naar ervaringsdeskundigen cq mensen die me de weg kunnen wijzen naar de opzet van elektronische orders in het supermarktwezen.

 

Voor een bedrijf onderzoek ik de opzet van elektronische dienstverlening met oa de bedoeling dat supermarkten geautomatiseerd orders aan kunnen leveren. Nu ligt het voor de hand om een web-interface te maken, ik kan me echter ook voorstellen dat supermarkten XML bestanden aanleveren vanuit hun logistieke systeem. Nu vroeg ik me af:

is er in de voedingsmiddelenketen enige standaadisatie op gebied van orderuitwisseling? en zoja, waar wordt de standaard beschreven?

 

 

[TwaBla]

Kijk eens bij de Global Commerce Initiative. Is dit een studievraag? Binnen de sector zou dit toch wel bekend moeten zijn.

[Particularia]

Nee, het is geen studievraag maar benodigd voor de praktijk.

Bedankt voor je antwoord ik ga direct kijken!

 

 

[Particularia]

TwaLevel via GCI heb ik weer een bron van andere links die me op elektronisch dienstverleningsgebied verder helpen.

 

Ik heb echter nog geen standaard kunnen ontwaren (bijvoorbeeld een XML orderprotocol), ik hoor net vanuit de consultancy hoek dat de grote jongens waarschijnlijk hun eigen standaarden hebben.

 

Het zou voor mij wenselijk zijn om een oplossing te hebben waarmee ik een groot deel van de markt afdek. Dus naast een basaal invoerscherm (webapplicatie) een transactiesysteem om aangeleverde bestanden te verwerken, door een hybride opzet is de keus des leveranciers.

 

Ik ben momenteel in het graven in universal business language (UBL) wat sinds kort geratificeerd is. Het is een webservices protocol en bestaat uit een gestandaardiseerde XML library op business gebied aansluitend op ebXML. Hierdoor worden datatypen en definities gestandaardiseerd wat e-commerce stimuleert. Alleen voor een webservices opzet ben ik huiverig in verband met data-integriteit, die technologie is vrij onvolwassen..

 

[willemj]

Schiet me eindelijk de term te binnen: EDI. M'n zus is afgestudeerd in de bedrijfskunde op een onderzoek hiernaar voor gebruik binnen de overheid. Maar staat me bij dat dit in allerlei takken als standaard gebruikt wordt/werd. Is al weer een jaar of 12 geleden dus misschien is het al weer achterhaald. Maar een goede standaard gaat lang mee en Google levert op 'EDI supermarket' 20.000 hits op.

 

Alleen voor een webservices opzet ben ik huiverig in verband met data-integriteit, die technologie is vrij onvolwassen..

 

Huh? Je data integriteit zit toch in je database layer?

[TwaBla]

Tja ik heb geen verstand van automatiseren, maar ebXML is een thema dat bij EPCglobal volgens mij aan de orde wordt gesteld. Kijk anders eens via de EAN. Die kende je al?

 

Ook EdiTIE lijkt me een ingang.

 

En dit is wellicht wat je bedoelt?

[NathanW]

Het lijkt me dat dit inderdaad leverancierafhankelijk is.

 

Ik ken een leverancier vanuit mijn vakkenvultijd: Sperwer.

 

EDI ken ik vanuit mijn studie (1 1/2 jaar geleden) en wordt inderdaad als standaard gebruikt.

 

Ik citeer uit het ICT-Zakboekje (1458 pagina's :))

 

"Electrolic Commerce (EC) is het elektronisch afhandelen van handelstransacties tussen twee of meer partijen waarbij goederen of diensten worden uitgewisseld. "

 

"Het streven van EC is om de verschillende onderdelen van de handelstransactie volledig te integreren. "

 

"EC wordt gerealiseerd tussen bedrijven die een langlopende relatie met elkaar hadden. In deze gevallen kon de elektronische gegevensuitwisseling - EDI (Electronis Data Interchange) - gestandaardiseerd worden in zogenaamde EDI- contacten."

 

In het boek Business Data Communications" vond ik het volgende:

 

"Electronic Data Interchange (EDI) is the direct computer-to-computer exchange of information normally provided on standard business domuments, such as invoices, bills of lading, and purchase orders. "

 

Helaas niet het antwoord dat je wilde horen. Ik hoop dat ik je toch wat heb kunnen helpen. Groeten, Nathan.

 

edit: Ik heb duidelijk de eerder opgenoemde links niet eerst bekeken.

:-X

[snark]

Probeer het eens bij de VWA een tijd geleden toen ik daar aan het interimmen was, was ketenbeheersing een topic. Waarschijnlijk hebben ze daar al het nodige onderzoek naar gedaan.

[Rien Gluvers]

De branchevereniging http://www.cbl.nl kan je alles vertellen van wat er momenteel al is en naar ik heb begrepen is dat veel.

Vooral op het gebied van orders van de supermarkt naar centrale groothandel. Maar ook van groothandel naar producent schijnt meestal al in nullen en enen te worden gecommuniceerd.

 

[Particularia]

Bedankt voor de fantastische info, zeker het CBL en ECP lijken me prima aanspreekpunten. .

 

Ik duik met de vraag die ik nu stel wat dieper in de techniek zodat ik mijn beeldvorming kan voltooien::

 

Standaardiseert ebXML attrributen op het gebied van hun datatype en hun naamgeving?

 

Voorbeelden:

productnaam -->datatype char(100)

prijs --> long integer

 

Als ik het goed heb is de 'library' bij ebXML een meta-data repository bestaande uit attribuutnamen en hun datatype..

Klopt dit?

 

De xml taal zou het mogelijk maken om het bericht structuurloos op te sturen met enkel de relevante attributen. Klopt?

 

Edi is afwijkend van XML omdat het bericht gestructureerd moet zijn (vergelijkbaar met de gestructureerdheid van een CVS file)..

Klopt?

 

 

 

 

 

[TwaBla]

 

Begin dit jaar heeft Tony Burgmans van Unilever zijn collega Tony Scot van Wal-Mart gevraagd toe te treden tot de Global Commerce Initiative om te voorkomen dat 's werelds grootste retailer andere standaarden gaat gebruiken voor zijn dataverkeer met toeleveranciers dan de meeste retailers.

 

Het doel van GCI is expliciet te voorkomen dat iedereen op eigen houtje systemen gaat ontwikkelen. Er zijn bij de betrokken bedrijven en hun technologie-leveranciers waarschijnlijk duizenden mensen bezig om dmv webservices en ebXML het logistieke proces te verbeteren. Het debat daarover (en global data synchronization) vond plaats bij het AutoID Center en is nu verplaatst naar EPCglobal. De Nederlandse link ligt ondermeer bij EAN.

 

Maar het CBL stuurt je vanzelf door. ;)

[Particularia]

Twalevel, aangezien om het om een implementatie gaat met als insteek een strategische houdbaarheidsdatum is GCI idd de aangewezen partij om een lichtje op te steken. Voor de tactische oplossing denk ik dat ecp en cbl inzicht verschaffen.

 

Als ik voorlopig de diverse sites mag geloven wordt ebXML het die EDI gaat vervangen, hierbij kan vooral het MKB garen spinnen omdat EDI vaak te kostbaar voor ze is.

 

 

 

 

[PS]

Even op voorhand : navolgende is veel te lang en veel te wazig ... ::)

 

Misschien erg laat gereageerd, maar hopelijk nog nuttig :

 

Voordat je op zoek gaat naar "standaarden" in deze, moet je eerst xx andere studies volgen, c.q. moet je veeeeel meer ervaren zijn in deze "wereld". Zeker niet negatief bedoeld, maar gewoon waar. En, zo ga je je klant niet helpen hoor !

En het vervelende is dat ik langs deze weg ook niet echt kan bijdragen aan de kennis, omdat het (vak)gebied gewoon te groot is. Echt.

Maar wel een zeer globale poging :

 

Als leveranciers en klanten elektronisch met elkaar kommuniceren, wordt dit in de wandelgangen EDI genoemd. Kijk ook maar naar de afkorting : Electronic Data Interchange. Is dat een standaard ? nee natuurlijk.

 

Terzijde de opmerking dat dit niets met bestellen via Internet te maken heeft, tenzij er webservices aan de orde zijn (kom ik misschien nog op terug).

 

Een niet onbelangrijke opmerking is dat EDI feitelijk verouderd is. Immers, EDI zoals ooit bedacht mag je zien als een ascii file met daarin regels die representatief zijn voor verkooporders, verkooporderregels, Inkooporders enz., maar net zo goed pakbonnen, vrachtbrieven, en 100x etc. (kom ik zo op terug);

Wil je ooit tot je kunnen nemen wat EDI inhoudt/omvat dan mag je eerst alles van bedrijfsprocessen en (keten)logistiek. Weet je dat een beetje dan ben je nog nergens, omdat je vervolgens aan de gang moet met de software. Software die je zelf gaat maken ? ... mij krijg je niet gek hoor.

Die software is er al ("ERP"), en de EDI funktionaliteit is daarin verweven

of

De sofware is er al en EDI funktionaliteit moet worden toegevoegd (kan alleen als de software intrinsiek de betreffende processen ondersteunt), denk aan een manjaartje of wat

of

De software is er niet en dan houdt het op. Niet helemaal, want je kunt de (ERP) software aanschaffen. Denk aan xxx.xxx euro voor goede software voor de food.

 

Ben ik nou klaar ? nee, net begonnen.

"EDI" zoals we het al jaren noemen is verouderd omdat het tegenwoordig met XML moet. Dit dus versus de asii files zoals eerder genoemd (en voor de nerd : ja, XML is ook ascii). Aha ! een nieuwe standaard ? welnee, over standaards hebben we het nog niet gehad; Zie EDI en XML maar als het "transportmedium" waarover de elektronische opdrachten worden getransporteerd (klopt letterlijk niet, maar zie het even zo voor het begrip "standaard"). Dit kan dus via de aloude EDI-methode en via de XML-methode. Maakt dit verschil ? ja, veel, maar waar ik het even niet over wilde hebben omdat het daar (wat mij betreft) niet om gaat;

 

Waar het wel om gaat, is dat een zendende partij van een "bericht" niet zo maar kan kiezen of hij EDI of XML "doet". Immers, als de ontvangende partij alleen maar EDI "kan", heb je mooi pech.

En zo werkt praktisch iedereen -althans in Nederland- nog steeds met het aloude EDI ... Dus is EDI verouderd ? ja, kwa techniek wel, maar verder is het gewoon bij praktisch iedereen in gebruik.

 

Hebben we nu de "standaard" gevonden voor de food ? welnee, we zijn nog steeds niet begonnen (heb wel het gevoel al te moeten stoppen want het wordt veel te lang);

EDI als transportmiddel maakt gebruik van standaards ... aha ! nou ... bijvoorbeeld voor europa wordt EDIFACT gehanteerd en bijv. in Amerika hebben ze iets anders. Wat voor een standaard is dat dan ? wel, dat betreft de definities van de berichten die bestaan en het geheel is genoteerd op meer dan 1.000 A4 (heb je nog zin ?). 1.000 A4 met typen berichten, of eigenlijk, typen bedrijfsprocessen waar je verstand van moet hebben.

 

EDIFACT mag als een echte standaard worden gezien, en die kan worden vergeleken met de ebXML standaard; wat EDIFACT doet voor de "ascii" bestanden, doet ebXML voor de XML bestanden.

Klaar ? nee, want hier kun je helemaal niets mee, behalve dat je nu misschien kun bepalen dat het gebruik van XML niet handig is, omdat de leverancier op de hoek nog met het oude EDI werkt (eh, of nog helemaal niet aan EDI doet zoals 95% ...).

Wel is het in dit stadium goed om te weten dat alles wat XML als basis heeft, ontzettend breed kan worden ingezet. Zo kommuniceren webservices ook met XML-achtigen. XML is dus zeker the way to go; als iedereen maar mee doet (en binnen 10 jaar zal dat wel zijn gebeurd).

Weer even terzijde : er bestaan natuurlijk aan alle kanten converters, die EDI naar XML en andersom kunnen vertalen.

 

Zo, dus bijvoorbeeld in Nederland gebruikt iedereen die "EDI" gebruikt, EDIFACT ? JA ! nou, als dat geen standaard is ...

Ehh ... wel jammer dat de standaard zo enorm breed is dat ze onbruikbaar is (wat moet ik met 1000 A4). In de praktijk wordt EDIFACT echter wel degelijk altijd gebruikt, maar is het intussen een "protocol" geworden. Een drager die volgens afspraken de berichten transporteert en die afspraken zijn vervat in EDIFACT. En die ascii file dan ?

 

O jee, niet meer te volgen ...

Verwijzend naar een club als EDI-Tie maken die standaards ... standaards voor de DoeHetZelf branche, voor de Metaal, voor de Food ...

Maar wat behelst dat echt ? wel, aftreksels van EDIFACT. De van toepassing zijnde stukjes zeg maar, vervat op 50 A4 voor de DHZ.

Nou, nu zijn we dus echt in de buurt, want kennelijk kunnen we EDI-Tie opbellen en om een setje EDI voor de Food vragen. En passent krijg je je berichten ook in het Chinees of op z'n kop als je dat wilt, en van het oorspronkelijke EDIFACT herken je niets meer. 1 ding blijft : het bericht wordt toch wel in het letterlijke EDIFACT verzonden (niet proberen te begrijpen).

 

Als je bovenstaande ooit hebt kunnen volgen, dan zie je dat er EDI providers (EDI-Tie) aan de orde zijn, die standaards maken ... Oh, dat zijn er dus meerdere ? yep. Meerdere providers die meerdere standaards maken. Echt ! en dus moet je in de slag met leveranciers enz. om "de standaard" af te stemmen met elkaar. En er kan nogal wat fout gaan hoor. Datums die in andere notaties worden geschreven, credit bedragen die ook nog met een - (min) moeten worden geschreven zijn bekende voorbeelden. Stem je de software daar niet op af, dan is het hommeles.

Software ? ja, de zgn. "in-house" software. Software die altijd nog nodig is om de EDI berichten te "interpreteren" naar je eigen wensen.

 

Had ik al gezegd dat een bedrijf die EDI voor enkele simpele berichten implementeert zo maar een jaartje bezig is ? heeft niets te maken met ontwikkelen van software. Gewoon alles gebruiken wat er bestaat, en dan een jaar zwoegen en er half aan dood gaan.

 

Laat ik dit maar afsluiten met te noemen dat een EDI provider gebruikt maakt van een speciaal voor EDI ingericht netwerk, zodat de berichten daarover veilig kunnen worden getransporteerd. Helaas is dat ook al zo goed als voorbij, sinds we tegenwoordig best veilig het internet kunnen gebruiken. Maar ja, ook de "postbus" zoals bekend van EDI is een standaard, en via internet werkt dat weer anders.

 

 

Het bovenstaande zal niet zijn te volgen, en het is ook niet mijn bedoeling geweest echt iets uit te leggen; ik moest even reageren gezien de vraag van de threadstarter gezien het werkelijk onmogelijke van zijn bedoeling. Als ik hem was zou ik heel snel adviseren om eerst maar eens een ERP pakket geschikt voor de Food aan te schaffen;

Over webservices heb ik het maar niet meer ...

 

Peter

[Particularia]

AH volgt wal-mart --> Edi over internet als tussenstap naar ebxml?

 

 

AS2 project Albert Heijn

 

 

Albert Heijn (AH) wil alle elektronische communicatie met haar zakenpartners via het communicatie protocol EDI-INT AS2 laten verlopen. AH wil hierdoor haar communicatie kosten sterk reduceren.

Een EDI-INT AS2 gebruiker communiceert direct met een andere EDI-INT AS2 gebruiker. Dit geschiedt via het Internet zonder tussenkomst van een mailbox system (Value Added Network). AS2 betekent wel dat er alleen met elkaar gecommuniceerd kan worden indien er een "open" (maar wel beveiligde) verbinding via het Internet met elkaar is.

 

Op dit moment communiceert AH nog met haar leveranciers via een X.400 mailbox systeem (een VAN). Dit soort systemen vormt een brug tussen de zender en ontvanger zonder dat er een directe verbinding nodig is tussen beide partijen. Berichten worden opgeslagen voor de ontvanger en de ontvanger bepaalt zelf wanneer hij de berichten ophaalt. Per 1 mei 2005 stopt Albert Heijn zelf met het gebruik van X.400. Leveranciers die dan nog niet op AS2 zijn overgestapt dienen op een andere wijze de verbinding met AH te realiseren.

 

TIE Nederland biedt een aantal opties om met AH te kunnen communiceren:

 

 

Een AS2 software module als onderdeel van uw EDI installatie

 

Het routeren van uw EDI berichten verkeer vanaf X.400 via de TiedByTIE berichtendienst naar AH

 

Voor bestaande (of nieuwe) TIE klanten geldt een speciale aanbieding. Uw X.400 kosten met AH kunt u elimineren via TiedByTIE FreeConnect en de AS2 "brug" biedt TIE u één jaar kosteloos aan.

 

Voor niet-TIE klanten die X.400 willen blijven gebruiken bieden wij de AS2 brug aan conform de TiedByTIE tarieven die op onze website staan vermeld.

 

 

Onder de knop "documentatie" treft u meer informatie aan met betrekking tot AS2 en de mogelijkheden en varianten die TIE heeft te bieden om met elkaar te communiceren.

 

 

 

 

[Particularia]

Even op voorhand : navolgende is veel te lang en veel te wazig ... ::)

 

Misschien erg laat gereageerd, maar hopelijk nog nuttig :

 

Voordat je op zoek gaat naar "standaarden" in deze, moet je eerst xx andere studies volgen, c.q. moet je veeeeel meer ervaren zijn in deze "wereld". Zeker niet negatief bedoeld, maar gewoon waar. En, zo ga je je klant niet helpen hoor !

En het vervelende is dat ik langs deze weg ook niet echt kan bijdragen aan de kennis, omdat het (vak)gebied gewoon te groot is. Echt.

Maar wel een zeer globale poging :

 

Bedankt Peter maar je zet hier en daar een overdrijving neer, zeker als je constant van de kop naar de staart en weer terug redeneert. Ik durf zelfs te stellen dat Dick Bruna de complexiteit kan tekenen en elke kleuter het kan begrijpen.

 

EDI wordt gebruikt door 95% van de top 10.000 companies en door 2% van de SME (small-medium enterprises). Simpelweg vanwege de terugverdientijd, en de 2% van de kleine bedrijven moet simpelweg van de grotere. Wat is de complexiteit/kosten? Meestal moet je bilateraal afstemmen en testen

en is er dba werk te verrichten. Een klein bedrijf met 30 afnemers in 30 verschillende branches krijgt zo onnodig veel complexiteit terwijl een groot bedrijf met een paar leveranciers snel de investering terugverdient.

Wat betreft de wassen neus van standaarden ben ik het volledig eens, de grote spelers douwen gewoon hun leveranciers een gemodificeerde standaard door de strot en als je pech hebt als kleine leverancier heb je teveel grote bedrijven als klant en zit je met een duur probleem.

 

EDI EN TECHNIEK

 

 

Edi behelst infrastructuur ('apart servertje en inbelnummer''), protocol ('ja, bericht is ontvangen en verwerkt') en berichtinhoud ('niet daar maar daar plaats je het telefoonnummer') en berichtsyntax ('nummertjes niet langer dan 10 posities, nee niet zo'n nummertje'). En die berichtinhouden kennen 1000-en varianten naar branche(transport, toerisme) en naar doel van het bericht (rekening, orderbevestiging etc.)

 

Het bericht is opgebouwd uit headers ('hier kom 'ik' stel me even voor ben afkomstig van bedrijf A'') en data segmenten ('hallo ik ben order 1001 mag ik naast de andere orders plaatsnemen op uw beeldscherm?').

De data segmenten zijn gestandaardiseerde attributen die ook vaak voorkomen in andere transacties. Een beetje branche-organisatie heeft implementatie guidelines voor de relevante EDI berichten van de branche.

Wat betreft vakkennis: Het is inleeswerk en geen apart vak voor een geschoolde dba'er, de kunst is namelijk om data uit je model te krijgen en er weer in te pompen(=extract transform load) volgens een berichtspecificatie.

 

Proceskennis is niet vereist omdat je volgens een berichtenspecificatie werkt. als er al proceskennis noodzakelijk is dan bij de business consultant, en die zegt net zoals altijd, overal waar handjes overbodig zijn hakken we die met technologie eraf. Kortom, al het overbodige data-entry werk eruit!

 

Kennis van het datamodel is door de eenvoud van de business consultancy des te belangrijker omdat hier geen dick bruna logica meer geldt. Hier gelden de regels van seniele nerds die gestructureerd leren werken maar structuurloos uitvoeren.

Neem applicaties die zowel informatieregels (constraints) in het datamodel alswel in de applicatieinterface hebben en je hebt het probleem bij de kladden. Meestal is uitgebreide documentatie van de informatieregels on the fly 'vergeten' . Dan is er nog altijd source code voorhanden die op de zaterdag en zondag doorgespit kan worden of het beproefde trial and a lot of error model. Die kun je nl. in de avonduren op kantoor doen en al die beeps op de computer lijken net alsof je gestructureerd aan het werk bent.

 

Eruit gooien van data is tot daar aan toe maar om een bericht, wat vaak is verdeeld over je datamodel er weer in te krijgen, is een ander verhaal.

 

ebXML is opgezet om ook kleine bedrijven aan de gang te krijgen met gestandaardiseerde berichtuitwisseling. Een van de voordelen: het kan over internet maar dat voordeel is met edi over internet inmiddels achterhaald. Resteert nog een voordeel: de manier waarop het bericht geinterpreteerd moet worden staat in het bericht zelf, dit in tegenstelling tot EDI.

Het is leuk als je de waarden los in een bericht gooit en voor elke waarde aangeeft van welk attribuut het een instantiatie is, maar zolang het datatype of het domein van de waarde incompatibel is met de specificatie in het datamodel van de ontvanger blijf je hangen. Als je ebXML combineert met webservices heb je de vooruitgang van het Goto statement in de programmeertaal, ik ben dan ook zeer benieuwd wat Edsger Dijkstra over een dergelijke vooruitgang zou zeggen. Maar gelukkig kunnen we voor alle overenthousiastelingen met hun implementaties over 10 jaar puinruimen waardoor de kachel huize IT blijft branden. Niet voltooide transacties, geschade data-integriteit maak je borst maar nat.

 

Voor de dba'ers maakt het niet uit want zij blijven handenwrijvend veel werk aan deze klussen houden, of het nu edi of ebXML is. In feite zijn het allemaal geen grove verbeteringen, het probleem zit hem namelijk in de applicaties en hun datamodellen die in elk bedrijf weer anders zijn.

 

En idd Peter als iedereen hetzelfde ERP pakket zou gebruiken zou het veel makkelijker zijn, net zoals jij en ik en 90% van de andere gebruikers feilloos een .txt bestand kunnen openen. Het probleem ligt daar waar het ontstaat, namelijk bij de applicatie, en voorlopig zullen we dat ook maar zo houden

 

ik heb het helemaal begrepen ;D beter dan ik gehoopt had want liever had ik me bij de overenthousiastelingen geschaard ,nu valt er zo weinig te verkopen. Voor de verandering maar een nieuwe csv standaard uitvinden en die een paar 'op de schopstoel leveranciers' door hun strot duwen ;D, zo blijft de kachel branden.

 

 

[pascal74]

Beste ?

 

Ik las je bericht/vraagstuk over electronische orderuitwisselingsvraagstuk in supermarktindustrie. Ben zelf werkzaam bij Tie Nederland een bedrijf met expertise op het vlak van electronische informatieuitwisseling/EDI. Het staat je vrij om met ons contact op te nemen via 020-6589000 indien je nog behoefte hebt aan informatie/kennis. Mijn naam is Pascal de Kleijn.

 

MVG.

[buruschaga]

Hoi,

 

Elektronische orderuitwisseling in de sierteeltketen gebeurt al enige jaren via EDI.

 

Het heeft als grote nadeel in zich dat het hoogdrempelig is qua kosten, flexibiliteit en onderhoud. Het is ook niet geschikt om mee te werken in een 'webomgeving'.

 

ebXML daarentegen is juist laagdrempelig en ondersteunt multichannel. Daarnaast ondersteunen de meeste moderne applicaties vaak standaard xml.

 

Als je start met het standaardisatie van informatie-uitwisseling in de keten zou ebXML op dit moment het beste alternatief zijn. het vervangen van ebXML door EDI, zou altijd gepaard moeten gaan met een overgangstraject. Zit je eenmaal aan EDI vast dan kun je lastig naar een nieuwe standaard migreren. Dit is immers met grote investeringen gepaard gegaan.

 

meer info: reply

 

Raymond ;D

FloraHolland