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

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

Abid,

> And why is that Mr. Lyon. Why is it that and I quote
> "ebXML isn't going to be useful though if it tries tell an aircraft
> manufacturer or an airline what business processes it should have."

It's very simple Mr Farooqui, business success often depends upon
market, product and process differentiation. That is, what makes
a Boeing or a Fedex better than anybody else.

So to tell them to adopt what amount to inferior business processes
than they already have is a nice idea, but I don't think that it will be
all that successful in the long run.

In any case, these organisations are already hugely efficient when
compared to other organisations as they stand today. So rather
than "preach to the converted", it's a much better idea to take
the knowledge of these systems out to other parts of the world
and to smaller enterprises so that the "ancient art" of super-efficient
computer systems can become more prevalent.

> Is that the CEOs of the airlines are saying that or is it because techies
> like you and me sitting in our comfortable jobs refuse to think out of the
> box and are too comfortable with the statusquo. I doubt the higher
business
> mangement of the airline industry even knows the basics of EDI. All they
> want is the thing to work and you and me tell them hey this is the best
way
> to do it.

Airlines (to my knowledge) don't use EDI because it won't work for them.

They use Galileo and a range of other centralised booking services.

> So again my question is : Is this a political battle or a
> technical one. It sounds to me that technically it is possible but the
> politics is making it impossible and that is just plain wrong.

I don't really know the answer to that one. I would say that it's a
technical
evolution where management will try to make the best use of whatever
technology is available.

The evolution of messaging technology is going backwards now as far as
most Senior Managers that I know are concerned. It's becoming so
convoluted to the point where nothing works :- look at ebXML.

Having said this, ebXML is of all the efforts the best of them and may
have some chance of success. It really depends on how much the
individuals participating in ebXML see it as their role to somehow
change the world for the better.

The time of EDI is gone. It's time for something better.

There have been some particularly good inputs by people on
this group and it would be good to see some of them become
reality.

That's my two cents worth anyway

David







----- Original Message -----
From: Abid Farooqui <farooqui@tampabay.rr.com>
To: <ebxml-dev@lists.ebxml.org>
Sent: Thursday, June 07, 2001 10:50 AM
Subject: Re: [Fwd: Example Scenarios Used Within the Aerospace Industry]


> And why is that Mr. Lyon. Why is it that and I quote
> "ebXML isn't going to be useful though if it tries tell an aircraft
> manufacturer or an airline what business processes it should have."
>
> Is that the CEOs of the airlines are saying that or is it because techies
> like you and me sitting in our comfortable jobs refuse to think out of the
> box and are too comfortable with the statusquo. I doubt the higher
business
> mangement of the airline industry even knows the basics of EDI. All they
> want is the thing to work and you and me tell them hey this is the best
way
> to do it. So again my question is : Is this a political battle or a
> technical one. It sounds to me that technically it is possible but the
> politics is making it impossible and that is just plain wrong.
> Sincerely,
> Abid Farooqui
>
> ----- Original Message -----
> From: "David Lyon" <djlyon@one.net.au>
> To: <ebxml-dev@lists.ebxml.org>
> Sent: Wednesday, June 06, 2001 8:31 PM
> Subject: Re: [Fwd: Example Scenarios Used Within the Aerospace Industry]
>
>
> > 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
> > >
> >
> >
> > ------------------------------------------------------------------
> > 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
>