Re: The initial ebXML business vocabulary - A call for a listofcandidates

[Abid Farooqui <farooqui@tampabay.rr.com>]

Howard,
Forgive me because I am ignorant about the building industry in the US a
bit. My father did build a few housing developments back in another country
and I did see them take shape there which was extremely hard and stressful
for him precisely because of slowness and wrror prone ways of paper and pen
excahnges of business documents for the most part.

The challanges for business document automation are the same. You need some
kind of a form (standard format) to develop a business document against, you
need a way to deliver it that is reliable for the most part and you need the
other party to acknowledge the reciept of that document first and then act
on it as soon as it can so that you can get on with your business.

In my opinion these needs are tackled even today by systems like traditional
EDI but I think that traditional EDI's weakness is in its complexity, lack
of similarity between document standards across verticals, its non-tagged
nature and its price (both the purchase price and the maintenance price
because you literally need to employ and EDI person to keep the maps
up-to-date, keep the software up-to-date and deal with new partners that
come onboard etc.). You need an EDI consultant basically and that is simply
not going to work in the 21st century. Those days are gone and people don't
have that kind of money to keep shelling out year after year.

Moving on to XML based standards ... XML is simple and it provides
flexibility. However, flexibility requires responsibility. What I mean by
that is that if we over engineer the solution (business document standards
etc.) even with XML then you end up just like with EDI after everything is
said and done. Too complex, requires a consultant almost full-time and so
on. That is no improvement, its just change of hands. If we are really
serious about solving the business problem then the requirements are simple,
make a solution that is not necessorily perfect but applies to 90% of the
scenarios, make it simple to use, administor and add partners with and make
it work across industry verticals because business does not happen in a
vaccum. If we should ever learn something from recent history it should be a
lesson from Microsoft. When they first came out with Windows, the operating
system was hardly even a contendor for even close to perfect (it isn't now
even) but it was simple to use. It provided the end user an interface that
is much more intuitive (visual, GUI) and it had software running on it that
solved most of the common problems. This provided a marked advantage over
Unix like operating systems even though they were and perhaps even today are
more robust than windows. Yet you can see that windows has taken off.

In essense in this particular situation with ebxml, if we are to develop a
solution, we need to develop it so that it solves most of the problems not
all (the ROE ... Return Of Effort, in going from most incrementally to all
is too large to justify even trying) and that it is asstandard across
verticals as possible to reduce complexity and is easy enough to use that
any decent computer user can administor and maintain it. I still favor the
concept of a universal PO, a universal FNACK and so on. Specific extensions
to these universal document(s) can be applied by each industry group if they
are really really needed (I discourage these from the bottom of my heart)
and as that happens software patches (perhaps even optional components) can
be released by vendors to deal with these extensions. If things are kept
simple I don't think moving from today's systems to the new ones will be as
painful as you might think.

Your other point about partners that simply won't go beyond pen and pencil.
Well, there is nothing you can do there. You can keep trying to automate
your business processes with them but there is nothing to automate there on
their side.
Sincerely,
Abid Farooqui


----- Original Message -----
From: "Howard Leslie" <hleslie@zipworld.com.au>
To: "Abid Farooqui" <farooqui@tampabay.rr.com>; "Rémy Marchand"
<rm-edi@worldnet.fr>; "Cole, Wavell (GXS)" <Wavell.Cole@gxs.ge.com>; "David
Lyon" <djlyon@one.net.au>; "Mervyn Colton" <Merv@quest.ie>;
<ebxml-dev@lists.ebxml.org>
Cc: "Rachel Foerster" <rachelf@ix.netcom.com>; "Gilles Brandel"
<Brandel.Gilles@srci.fr>
Sent: Wednesday, June 20, 2001 10:27 PM
Subject: Re: The initial ebXML business vocabulary - A call for a list
ofcandidates


Hi
First to introduce myself.  I am in the building industry and have for many
years been interested in ways to improve the performance of the building
industry by improving it ability to manage its information.  My focus has
been on understanding the flow of information between decision-makers -
assuming clarity in this area will provide the platform from which the IT
industry can more efficiently provide tools building practitioners can
understand and apply.  I'd like to make a couple of points from this
perspective.

Hopefully, in the not too distant future, the building industry will have OO
definitions of the objects about which it needs to communicate and
coordinate its decisions and actions.  I believe most of these objects will
be the subject of business messages - eg client and consultant re
commissioning, contractor and regulatory authorities, contractor and project
manager re variation to the work, contractor and manufacture re
order/invoice ..., contractor and transporter re delivery, contractor and
staff re wager and conditions of pay.  As the industry is composed primarily
of SMEs, a significant number of these exchanges will be handled by one
person wearing many hats.  That person will be stretched and have a
relatively short term perspective - primarily getting one job done and
finding the next one.  Profit margins will be tight and unlikely to support
long term planning.  In other words, change will not come easily and they
are unlikely to stop work to learn a totally new way of doing what they are
already doing - regardless of promised improvement.  Too, in this industry,
improvements undertaken by one group most commonly benefit someone else -
better construction documents do not attract a higher fee but do make it
easier for the builder.

In relation to ebXML -
    - The building industry deal with a very wide range of other sectors.
If we don't try for the universal solution how do we define the boundaries
of this industry?
    - The 'payload' of these messages will range for the traditional line
item (ordering a handbasin for a catalogue) to significant packages of
documentation (calling for quotes for the design and fabrication of a
building component).
    - The size and nature of this industry is such that it will be difficult
(impossible) to manage change if it calls for a medium to long term
initiative.
    - This industry that needs what ebXML has to offer but we need to think
about what they have to do to make the transition from their current
paper-based exchanges.
    -  Even if some enterprises take up the challenge and make the
transition they will be faced with having to communicate with those who
still use pen and ink.  Refusing work is not commonly an option.

My point is that the building industry is more likely to take up this
technology if they can grow into it.  I realise this is problem falls more
my court than yours but believe consideration of how an industry might make
the transition might  throw light on the current discussion.

As a positive contribution - a naive suggestion.  Accepting the above, we
need to look for ways that will enable the industry to evolve from current
practice.  Current paper-based messaging involve three levels of nesting;
    - payload
    - message type (commonly a pre-printed form - order, invoice, request
for information, ...)
    - message management (gets message from sender to receiver - in person,
voice, mail, email,...)

Is it possible to formulate Remy's Basic (general purpose) Core Components,
Domain specific Core
Components, Sector specific Core Components' around this sort of nesting?
For example;
    - payload - This would be application and industry specific and
therefore left to the relevant industry sector.  Over time moves could be
made to standardise this material.
    - message type - A library of agreed electronic document types could be
established that individual enterprises or industry sectors would draw upon.
Many message types would be universal but there would be room for special
types to be developed.
    - message management - The means of transmission are relatively
universal - addressor, addressee, date, ...

Elements like people, dates and addresses will appear in all three level
(payload: date/location to deliver object), (document type: date the order
was prepare or authorised), and managed (date message is sent/received).
These could be Remy's Basic Core??


Regards,
Howard Leslie

----- Original Message -----
From: "Abid Farooqui" <farooqui@tampabay.rr.com>
To: "Rémy Marchand" <rm-edi@worldnet.fr>; "Cole, Wavell (GXS)"
<Wavell.Cole@gxs.ge.com>; "David Lyon" <djlyon@one.net.au>; "Mervyn Colton"
<Merv@quest.ie>; <ebxml-dev@lists.ebxml.org>
Cc: "Rachel Foerster" <rachelf@ix.netcom.com>; "Gilles Brandel"
<Brandel.Gilles@srci.fr>
Sent: Thursday, June 21, 2001 9:48 AM
Subject: Re: The initial ebXML business vocabulary - A call for a list
ofcandidates


> I think a lot of the hurdles found in not being able to use one format (a
> single business message suitable for every industry) are at least
> technically gone with the use of XML and XML schemas.
> However as Remy suggested we should also look at OO approach to this
problem
> as well. At this point there is no harm in trying to solve the problem
both
> ways and see which works better in reality scenarios. One can only do that
> if one has a demo implementation.
> That is my 2 cents.
> Sincerely,
> Abid Farooqui
>
>
> ----- Original Message -----
> From: "Rémy Marchand" <rm-edi@worldnet.fr>
> To: "Cole, Wavell (GXS)" <Wavell.Cole@gxs.ge.com>; "Abid Farooqui"
> <farooqui@tampabay.rr.com>; "David Lyon" <djlyon@one.net.au>; "Mervyn
> Colton" <Merv@quest.ie>; <ebxml-dev@lists.ebxml.org>
> Cc: "Rachel Foerster" <rachelf@ix.netcom.com>; "Gilles Brandel"
> <Brandel.Gilles@srci.fr>
> Sent: Wednesday, June 20, 2001 4:48 AM
> Subject: Re: The initial ebXML business vocabulary - A call for a list
> ofcandidates
>
>
> > Folks,
> >
> > Speaking in my quality of EFNET (European Footwear Network), I confirm
> that
> > GCI is a good starting point.
> >
> > The XML Schema for Catalogue data and product description contains a
group
> > of data which can be tailored to each product type, in particular shoes.
> >
> > According to me XML has to define Core Components such as Dates,
> Addresses,
> > Company and product Id etc..
> >
> > Unlike UNSM, which are supposed to give the framework for any Order,
> Invoice
> > etc..and which finally produced inconsistent MIGs, XML should adopt an
> > Object Oriented approach, which means defining the few information
parcels
> > which can be found in any business document, then defining the
additional
> > information parcels used by trading activities consumer oriented, then
> > defining additional information parcels which make sense in a particular
> > domain (textile, building and construction).
> >
> > This leads us to the idea of Core Components, and according to me we
> should
> > have Basic (general purpose) Core Components, Domain specific Core
> > Components, Sector specific Core Components.
> >
> > As an example, I refer you to the www.hr-xml.org, an organisation
working
> on
> > xml for human ressources management. They have defined all the possible
> > national expressions of the group of data "Address".
> >
> > Should we have more of such basic components, the work would become much
> > easier.
> >
> > Hopefully, this will be an output of the EAN-UCC work.
> > ----- Original Message -----
> > From: "Cole, Wavell (GXS)" <Wavell.Cole@gxs.ge.com>
> > To: "Abid Farooqui" <farooqui@tampabay.rr.com>; "David Lyon"
> > <djlyon@one.net.au>; "Mervyn Colton" <Merv@quest.ie>;
> > <ebxml-dev@lists.ebxml.org>
> > Sent: Sunday, June 17, 2001 12:59 AM
> > Subject: RE: The initial ebXML business vocabulary - A call for a list
> > ofcandidates
> >
> >
> > > Folks,
> > >
> > > The EAN-UCC Global Commerce Initiative (GCI) is providing an excellent
> > base
> > > from which EAN members all around the world can employ XML messaging.
> The
> > > GCI project is producing a suite of business messages based on the XML
> > > Schema (XSD). The first of the messages is expected to be made
> commercial
> > in
> > > July this year and I believe will become the 'standard' for at least
the
> > > Retail Industry in Australia.
> > >
> > > At least one of the major retailers has already commenced in earnest
to
> > > implement the purchase order and others will follow.
> > >
> > > Attempting to develop a single business message suitable for every
> > Industry
> > > participant has never worked in the past and I doubt that it ever
will.
> > > However, considering the extensibility structure of the XSD schema
this
> is
> > > not a problem. If there is acceptance of a base schema then an exact
fit
> > for
> > > a user is always possible.
> > >
> > > I have been working with the Retail Industry in Australia on the issue
> of
> > a
> > > single standard since the late 1980's and it is yet to be realised. It
> is
> > no
> > > wonder that there is a growth in service industries acting as
> > intermediaries
> > > to ensure trading partners send or receive messages capable of
> integration
> > > or least interfacing with their back-office systems.
> > >
> > > There is still a wide view that users will somehow cope with
technology
> > but
> > > in fact, they have no interest in doing so. The expectation is one of
> > > complete technology transparency. "Give me an order, do'nt tell me
what
> is
> > > looks like!". As long as technology is as simple as the act of making
a
> > > phone call, to end users that is all they want.
> > >
> > > Wavell Cole
> > >
> > > Snr. EC Consultant
> > > GE ecXpress
> > > Level 15, 565 Bourke St.
> > > Melbourne Vic. Australia 3000
> > > Office: 61-3-9927 2502, Fax 61-3-9629 8838
> > > Mobile: 0409 148 260
> > > Dial Comm 345 0002
> > > email: wavell.cole@gxs.ge.com
> > > WAP email: colew@telstra.com
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Abid Farooqui [mailto:farooqui@tampabay.rr.com]
> > > Sent: Sunday, 17 June 2001 3:27
> > > To: David Lyon; Mervyn Colton; ebxml-dev@lists.ebxml.org
> > > Subject: Re: The initial ebXML business vocabulary - A call for a list
> > > of candidates
> > >
> > >
> > > Mervyn,
> > > I just wanted to say that David Lyon is completely on target in my
> > opinion.
> > > A horizontal transaction set covering many industries is exactly what
I
> > have
> > > been asking this list about and it simply does not exist. I have been
> > given
> > > example scenarios where a PO format for aerospace would be very
> difficult
> > to
> > > be used as a PO format for some other industries. In my opinion that
was
> > not
> > > the case and the problem could be easily solved but I guess I was a
> > minority
> > > in that opinion at least in this list. Specifics like inspections of
> > > aerospace gear that conforms to ASME standards was sighted. Well, I
> always
> > > thought that ebxml worked under the UN not under the US. In either
case
> I
> > > had suggested that inspections may be a part of any PO (optional) not
> just
> > > for aerospace industry in the US.
> > > In short what I see happening is that while ebxml and related bodies
> wait
> > to
> > > theorize the whole deal in complex lingo and jargain, some of us will
> find
> > > things already out there and use them over ebxml messaging with the
CPP
> > etc.
> > > Will that make these products ebxml compliant. Yes, because lack of
> > > something cannot and should not force us ot to make a product that
> solves
> > a
> > > real need now.
> > > Sincerely,
> > > Abid Farooqui
> > >
> > >
> > > ----- Original Message -----
> > > From: "David Lyon" <djlyon@one.net.au>
> > > To: "Mervyn Colton" <Merv@quest.ie>; <ebxml-dev@lists.ebxml.org>
> > > Sent: Saturday, June 16, 2001 4:30 AM
> > > Subject: The initial ebXML business vocabulary - A call for a list of
> > > candidates
> > >
> > >
> > > > Mervyn,
> > > >
> > > > It's a funny thing about ebXML but I'm told that there are
> > > > actually *no* defined messages yet, in the traditional sense.
> > > >
> > > > Not at this point anyway.
> > > >
> > > > However, practical neccessity will no doubt overide the
> > > > technical theorists and purists. This has to happen for ebXML
> > > > to ever work.
> > > >
> > > > Where ebXML appears to be at the moment is that
> > > > there is a reluctance to make an executive commitment to
> > > > documenting some standard messages. This may be
> > > > due to lack of funds, or maybe a perceived difficulty
> > > > that a horizontal transaction set covering many industries
> > > > will be extremely difficult to do.
> > > >
> > > > No matter, grass-roots support, from participants all
> > > > around the world, especially in developing countries, is
> > > > leading to the invevitable conclusion that a third-party
> > > > business/messaging vocabulary must be picked up for
> > > > ebXML to ever work.
> > > >
> > > > The best way forward, rather than to build a new
> > > > vocabulary from scratch is to pick up and run with an
> > > > existing one. Then, over time, adapt that to suit
> > > > requirements.
> > > >
> > > > I've checked out www.xcbl.org and noticed that
> > > > above everything, they provide a reasonably workable
> > > > XML based transaction set that could be used as
> > > > the basis to build an ebXML transaction set.
> > > >
> > > > If there are any other candidates for an ebXML
> > > > then please mail me.
> > > >
> > > > As ebXML runs under the United Nations banner, it's
> > > > a responsibility for people in all nations accross the
> > > > world to have their say on how they would like ebXML
> > > > to go forward, not only those based in Europe or
> > > > America.
> > > >
> > > > Looking forward
> > > >
> > > > David Lyon
> > > > ebXML Evangelist
> > > > Brisbane Australia
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: Mervyn Colton <Merv@quest.ie>
> > > > To: Ebxml-Dev (E-mail) <ebxml-dev@lists.ebxml.org>
> > > > Sent: Friday, June 15, 2001 5:18 PM
> > > > Subject: Newby
> > > >
> > > >
> > > > > Hi All,
> > > > >
> > > > > I'm new to these email goups on ebxml. I would like to know if
there
> > is
> > > an
> > > > > URL that explains more on the scope of the different email groups,
> and
> > I
> > > > am
> > > > > specifically interested in where the different "messages" are
> defined
> > > for
> > > > > the FMCG business place. Product catalogs for example.
> > > > >
> > > > > Any tips on where to start looking would be very much appreciated.
> > Sorry
> > > > if
> > > > > this has been covered before.
> > > > >
> > > > > Mervyn Colton
> > > > > Technical Director
> > > > > merv@quest.ie
> > > > > Quest Computing Ltd
> > > > > www.quest.ie
> > > > >
> > > > >
> > > > > ------------------------------------------------------------------
> > > > > The ebxml-dev list is sponsored by OASIS.
> > > > > To unsubscribe from this elist send a message with the single word
> > > > > "unsubscribe" in the body to: ebxml-dev-request@lists.ebxml.org
> > > > >
> > > >
> > > >
> > > > ------------------------------------------------------------------
> > > > The ebxml-dev list is sponsored by OASIS.
> > > > To unsubscribe from this elist send a message with the single word
> > > > "unsubscribe" in the body to: ebxml-dev-request@lists.ebxml.org
> > > >
> > >
> > >
> > > ------------------------------------------------------------------
> > > The ebxml-dev list is sponsored by OASIS.
> > > To unsubscribe from this elist send a message with the single word
> > > "unsubscribe" in the body to: ebxml-dev-request@lists.ebxml.org
> > >
> > > ------------------------------------------------------------------
> > > The ebxml-dev list is sponsored by OASIS.
> > > To unsubscribe from this elist send a message with the single word
> > > "unsubscribe" in the body to: ebxml-dev-request@lists.ebxml.org
> > >
> >
>
>
> ------------------------------------------------------------------
> The ebxml-dev list is sponsored by OASIS.
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-dev-request@lists.ebxml.org
>