Re: [Fwd: Example Scenarios Used Within the Aerospace Industry]

[David Lyon <djlyon@one.net.au>]

David W,

Your assertion is probably true.

ebXML isn't going to be useful though if it tries tell an aircraft
manufacturer or an airline what business processes it should have. That's up
to them.

What ebXML can do is provide a marketplace framework where the interactions
between companies at a technical level, that is define how to put together
message payloads.

These days the whole idea of inspectability/non-inspectability is becoming
blurred.

We supply products for Real-Estate agents that have a "virtual-tour". It's a
software program that shows a video of the house and it's contents. The
prospect watches the "virtual-tour" on their PC.

So even while Houses are not commodity products per se, and require
inspection (most often). It's possible to build a framework in which these
products can be sold.

In summary, defining the business process is only applicable to large
corporations within specific industries where the business process is quite
simple. In smaller organisations, the processes are often more dynamic.

Defining some simple messages over a beer or two is a good idea. I believe
that the Compaq luggable computer (which evolved into the modern notebook)
was designed that way. It's design scratched into a napkin.

If anybody is interested in such an event, I'm happy to provide the beer.

David Lyon

----- Original Message -----
From: Welsh, David <David.Welsh@nordstrom.com>
To: <chucka@hr-xml.org>; <ebxml-dev@lists.ebxml.org>
Sent: Thursday, June 07, 2001 6:01 AM
Subject: RE: [Fwd: Example Scenarios Used Within the Aerospace Industry]


> Guys,
> Very interesting discussions; landing struts, ....
>
> Could I make the following assertion, and this has everything to do with
the
> focus on ebXML business processes. In building a commercial plane :
>
> 1. it "might be" possible to come up with more or less THE SAME PAYLOAD
> FORMAT OF A PO BUSINESS DOCUMENT (say in XML)
>
> BUT
>
> 2. with respect to the runtime XML business process model (BPSS), each par
ty
> uses to manage the B2B relationship, there will be RADICALLY DIFFERECT
ebXML
> BUSINESS PROCESS models between "non-inspectable commodity items" and
> "inspectable items".
>
> Thanks
> Dave Welsh
>
>
>
> > -----Original Message-----
> > From: Chuck Allen - HR-XML [mailto:chucka@hr-xml.org]
> > Sent: Wednesday, June 06, 2001 11:27 AM
> > To: ebxml-dev@lists.ebxml.org
> > Subject: RE: [Fwd: Example Scenarios Used Within the
> > Aerospace Industry]
> >
> >
> > Ron Schuldt wrote:
> > > >The is a major difference between buying non-inspectable
> > commodity items
> > > >such as light bulbs used in a facility versus inspectable
> > items such as
> > > >landing gear struts that go into a passenger plane.
> >
> > [snip]
> >
> > > >Bottom line - the requirements in a landing gear strut
> > purchase order are
> > > >vastly different from those in a simple light bulb
> > procurement. As a result,
> > > >should the PO for a light bulb pay the penalty of having
> > to address the
> > > >multitude of topics (extra overhead) that are required for
> > the landing gear
> > > >strut? My strong suspicion is --- no.
> >
> > > >Having stated my point - it is my hope that common (core
> > component) data
> > > >elements applicable across multiple industries and used
> > within multiple
> > > >transactions will be addressed by this ebXML list.
> > Examples include -
> > > >address, currency, organization, etc.
> >
> > [snip]
> >
> > David Lyon wrote:
> > > I tend to agree with you Abid. There are too many technical
> > people that say
> > > that a Purchase Order for an Electronics company is
> > entirely different and
> > > non interchangable for those say, for Insurance. It's ridiculous.
> >
> > I guess I wouldn't assert that POs for one industry have to be
> > "entirely different and non interchangable" than those from
> > another. However,
> > hopefully there will be some standard ways of plugging in
> > industry-specific
> > detail. There will be a need for vocabularies to handle the
> > needs of particular
> > industries and functions.
> >
> > Here's another example - staffing. Temporary and contract
> > staff (human resources)
> > are about the farthest thing that I can imagine from an
> > undifferentiated
> > commodity. Twelve months ago, I perhaps naively assumed that
> > HR-XML would not
> > have much of an intersection with purchasing processes.
> > However, we have
> > had a strong interest from both staffing purchasers and
> > suppliers in building
> > in specific support for the procurement of temporary and
> > contract staffing.
> >
> > Is HR-XML going to be coming up with its own PO spec? I hope
> > not. On the
> > other hand, we have a strong interest in exploring how HR-XML
> > compliant
> > job requisitions -- which can capture rich detail about
> > required skills,
> > experience, etc. -- fit into major procurement frameworks and
> > perhaps how
> > they might work across different frameworks. I believe most of HR-XML
> > members in the staffing space (companies like Kelly Services,
> > Adecco, Randstad,
> > Manpower) are at least to some extent connecting with customers via
> > XML-enabled commerce platforms. Unfortunately, the description of what
> > the customer wants -- i.e., the skills, experience,
> > qualifications, etc. --
> > usually comes in as a blob of text versus an HR-XML payload.
> >
> >
> >
> > Best Regards,
> >
> > Chuck Allen
> > Director, HR-XML Consortium, Inc.
> >
> >
> >
> >
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: ebxml-dev-request@lists.ebxml.org
> >
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-dev-request@lists.ebxml.org
>