|
XML (eXtensible Markup Language) is the
basis of the "next big thing" - a way to connect millions of
pockets of information via the Internet so that the next generation of Internet software applications can
seamlessly work together.
ebXML (Electronic Business eXtensible Markup Language) is a
modular suite of standard specifications that enables enterprises of any size and in any
geographical location to conduct business over the Internet. The ebXML standard
was finalised during May 2001.
Fortunately a primary
objective of ebXML is to promote the use of shrink-wrapped, plug-and-play
software via the Internet. This means that ebXML's design and technical
architecture remain within the reach of smaller businesses.
This page attempts to provide enough
information so that you can ask the right questions and cut through the
advertising spin the next time a software salesman darkens your doorstep. The
sections are:
Although there are some issues to be wary of, XML / ebXML have an enormous
potential to change the way you do business, so you should embrace them.
If you are in a small to medium size company, XML / ebXML can become a key component of
your own EDI system - and then you can enjoy the benefits currently only
available to larger companies, but at a fraction of the cost.
And while you develop your systems you will have the benefit of hindsight -
the ability to learn from the successes and the failures of EDI over the last 30
years.
If you decide to use
XML / ebXML -
these are the basic steps
If you - or your industry - don't work
through these steps - then it is unlikely that you will develop an
eCommerce-capable system using XML / ebXML.
If your industry already
has XML standards it may need to change its specified message
structure to meet the requirements of ebXML. If your industry does not have an XML
standard, then you can avoid retrofitting the new standard to existing applications.
Bear in mind that you don't HAVE to
wait for the rest of your business partners to get started with XML / ebXML.
For example, if you are supplying
products and services in a niche market and the majority of your customers are
using one of (say) five industry-specific packages, chances are that it will be
cost-effective for you to go ahead and develop your own in-house XML / ebXML solution
because you don't have to cater to a wide audience.
While your competitors are hesitating
about connectivity, you will be able to benefit from the advantages of
automation. When your industry standard is established, it's only a modest
change to adopt your standard.
The recognised steps to
follow are these:
1. Agree on the the
types of documents you want XML-enabled
Before you can consider XML
/ ebXML as a
technology, you - or you and your industry partners (customers and/or
suppliers) - need to establish a standard way of describing the types of
information that flow between your respective businesses.
It may not be economic to try and
deal with everything at once - but you'll need to identify what types of
information are suitable to include. Sets of information related to Purchase
Orders, Invoices, Payments and Confirmation Messages are a good place to
start.
If your scope is broad enough, and you are part of a supply chain, using
manufacturers' product numbers by all of the companies in your industry
cluster (or supply chain) will simplify inventory tracking. Rather than using
different codes assigned to the same products as they flow from manufacturer
to distributor to retailer to consumer, unique identification makes
accumulating data easier and make it easier to forecast requirements.
Another idea that you should seriously consider within your industry is to
use a unique number for each company so trading partners have a common means
of identifying each other.
2. Identify the types of
data and the data relationships for each type of document identified in Step
1.
Once you have these various sets of
information you'll need to specify the way individual fragments of data within
each clustered set information relate to each other. For example, each
Purchase Order will probably need a Date. Each Purchase Order Line will
probably need a Purchase Order Line Type. (The skeleton you create can be
handed to a XML / ebXML developer - they will call the document they create using this
information a "DTD")
It is important to understand that
once you begin automating your information flows that you are not really
dealing with hard copy documents any more - you are dealing with information
flows - processes rather than a string of individual events.
It is a process of invoicing sales related information or the process of
purchasing / procurement rather than individual invoices or individual
purchase orders that your systems will be dealing with. The idea is that the
individual hard copy transactions disappear.
3. Identify any data
variations that may be required for each document and define these variations.
There is likely to be a mix of
standard and optional data fragments within each type of document.
Optional fragments are usually for a
particular program so they are called "application-specific
extensions". For example some people in your industry may need additional
data fields in a standard document in order to automate their in-house
software.
4. Develop a way of
clearly differentiating each type of message you want to XML / ebXML enable.
You'll need clearly to identify each
type of message - so that all of the computers involved know that a Purchase
Order IS in fact a Purchase Order. Setting up and testing the design of
prototype documents is the smartest approach.
5. Establish document
verification rules
Then you'll need to create some rules
so that when you receive a document you can make sure all of the data
fragments you MUST have are in the right place and contain valid information
and that any optional or extended data fragments are correct as well.
Obviously this is particularly important if you intend to pull XML / ebXML documents
directly into your in-house system without human intervention.
6. Establish Standards
for Message Receipting and Notification of bad Transactions
You'll need to have a standard way of
telling each sender that you have received their (say) Purchase Order Document
- and they will need a standard way of getting the receipt. You will also need
to agree on a way of dealing with bad transactions.
In some cases you might want use
simple e-mail messages, but you should consider increasing the amount and the
quality of the information you send.
For example, why not let the other system confirm your understanding of
each line on a document and list any exceptions in your receipt message - say
the differences between a delivery docket and the actual goods that were
unloaded. (The remote computer should of course then "know" what to
do about the short-delivery).
7. Prioritise how you
will automate your in-house business processes
Finally - and this is optional - for
your in-house systems you'll need to set up ways of "reacting" to
the (say) Purchase Order documents you receive.
These types of programs are are
sometimes called "DataBots" or "Agents". These programs
sit waiting on your computer until something that they "understand"
occurs - like a file arrives into a particular folder - or an document is
added with the prefix INV. then they do what they have been told to do - like
translate the information in the XML / ebXML document so that the information
contained within it can be automatically uploaded into your Order Entry
System.
These kinds of functions are often
available with large-scale "Enterprise" systems by are usually
beyond the budget of small and medium sized companies. Their options are
usually to write custom DataBots or re-key information.
The Extensible Stylesheet Language (XSL) - part of the overall XML / ebXML
concept - lets users display and format incoming data. As support for XML /
ebXML grows, more and more applications packages used by small to medium companies
will support XML / ebXML. Processing incoming XML / ebXML documents will become a mainstream
software function.
You might restrict your
initial efforts to
sending/receiving XML / ebXML documents and making sure they are valid. DataBots or
Agents may be an overkill to start with.
Integrating EDI,
XML and ebXML
If EDI is widely spread through your
industry you will need to consider ways to get EDI and XML /
ebXML working together.
Using ebXML, "companies now have a standard method to exchange business messages, conduct
trading relationships, communicate data in common terms and define and register
business processes" (See: http://www.ebxml.org/
for more details)
Although
you may not need to adopt the ebXML 100% to XML-enable your
applications, by adopting the standard you can expect to reduce future system
maintenance costs and overcome the problem of getting getting EDI and
XML data to work together seamlessly. Working to standards will also help deal
with another issue - translating EDI data into
XML format - especially when there could be several variations within your
industry.
For an official "plain-English" overview of XML / ebXML you should
read the "Frequently Asked Questions" page at http://www.ebxml.org/faq.htm.
To get the best out of your investment
in automation you should try to combine the best features of XML / ebXML with the
lessons learned from previous technologies - in particular EDI. Here are a few
ideas:
a) Leverage XML and automation into your
business processes - try to IMPROVE your business - don't just aim to automate
existing procedures. Look at the way you link with every customer and supplier
and seek way to improve and then automated your business processes. For example,
if you are (say) a wholesale glass distributor, why not consider managing
inventories for your customers.
b) Use brainstorming to extend the way you
look at the technology. You might find that by dealing in very fine detail you
can move your business to a new plateau. (If you're not sure what
brainstorming is, check out The
Learning Revolution).
For example if you are a flat glass
merchant, why not capture the Batch ID's for each pack of glass you order and
provide an ISO compliant system without any extra effort.
Or, if you are dealing with boxes and
cartons of goods, why not capture their dimensions and weights and manufacturing
batch ID's and transparently provide a quality control system that exceeds your
customer's expectations. (The same information can also be used by tools like Cube-IQ to
save 10-15% on your freight costs).
The more detail you capture the more
control you will have over your business. Disk space is cheap and it the
additional information costs you nothing - so why not?
c) Coordinate your business as if it were a
ballet! Use your detailed data to manage issues
like Just-In-Time deliveries. If you can, link with your suppliers and your
customers and form supply chain systems where error-free and low-cost
information flows are the norm - not individual labour-intensive paper-based
transactions between just two isolated parties.
d) Merge your in-house systems with other
technologies. The costs of doing this will get lower and lower and the more that
you link the closer your relationships with your customers. For example, there
is no real reason why your system cannot link to pagers or SMS/WAP cellphones.
Finally, look beyond the promises of the
self-appointed experts (including us!). It is your business and your technology
should let you
do your business your way - but better and better - especially of you take
advantage of the benefits of XML and the new ebXML standard.
See
Also:
EDI Explained
Back to Top
|
