OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: Brave new world





     As another lurker on the list, and one with 15 years experience in
implementing EDI solutions, I heartily concur with Margaret Permberton

>>>>>>>>>>>>>
until everyone uses the exact same process model, I cannot see how these
problems can be resolved by "YET
ANOTHER STANDARD".
<<<<<<<<<<<<<.

     There are essentially three problems to be solved in exchanging  data
with a trading partner.

1. Setting up the communications links - direct, via a VAN or over the
Internet. These are all well known issues and easily resolvable.

2. Getting your 'EDI' software vendor to support the standards and
communications you want to use - which is not too much of a problem. Just
pick someone who does what you need, and hope they keep up-to-date with new
developments. (For EDI, also read ebXML, BSI, BizTalk etc.)

3. Getting the data you want to exchange into or out of your business
process/systems. This is the biggie. If you have home-grown systems, you
will have to design and implement it all yourself. If you have a bespoke
package, you will need to get your supplier, if he still exists to do it,
and hope he already has something which will interface with your 'EDI'
software. If you have a standard package, then you have a better chance of
getting the vendor to have interfaces of some sort, though they will
probably be to your preferred 'EDI' vendor. If you have no business systems
( a very small business - what we call 'Fred in a shed'), then you will
have to struggle with some form of Web-Enabled interface.

     So what will ebXML do for us.

     For a start, it will replace the EDIFACT et al that we all know and
love with something more cumbersome and bandwidth hogging - let's replace
the three char segment tags and one char separators with meaningful text.
Not a problem, so long as the translation software gets updated.

     With suitable XSL we should be able to read it in a browser. Great, I
just spent years getting rid of all the manual labour of entering data from
paper orders - now you want me to do it from a screen.

     The key is automation. We need to be able to update our business
systems automatically, We need no delay and we need to be able to see what
has been updated. In short, we need PROCESSES integrated into our business
systems with standard exchange formats. The standards for the formats are
already there - EDIFACT etc. but what is being done by the package vendors
to build the interfaces and ensure that they are compatible. If you are
lucky, you might get Order Entry and Invoicing out of the box. Most likely,
you will have to either modify what they provide, or get an extension
written.

     Another exchange standard does not do a lot for us out here at the
sharp end. We need the package vendors to get together and agree on the
processes. Not just the obvious bulk data exchanges, but the those which
allow access and visibility of data between systems. Why shouldn't my
supplier see my stock levels and use them to control replenishment. Why
shouldn't my customers see how I am getting on with their order. The key to
improving business is integration between trading partners - openly, but
managed.

Chris Hill
Technical Support Manager
AP Hydraulics Ltd






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC