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

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

That is kind of where I am coming from too but I think ebXML is simply
providing us a standard to pass business data around not actually define
what that data should look like. Well, that is all good and well but this is
kind of also putting the cart before the horse. Now we have a XML framework
standardized which we can use to to pass business data around but BTW we
have not yet decided on a standard (at least in XML) to say what that data
should be like. I ask why??
This to me is political rather than technical hinderance. I think it is
because UN/CEFACT does not want to step on CommerceOne or BizTalk schemas or
RosettaNet. That is what I call copout or backing away from solving the
whole problem. RosettaNet and other such entities like even X12 and EDIFACT
groups have become entities in their own and they will be mean when you say
I have a mechanism that may cause your demise but the point is that that
mehanism will solve the core business automation problem that troubles IT
people as well as the businessman. You come up with that solution and demo
it and put it out and the cry babies will die in time ( a long time but they
will ). The businessman will eventually see how this solution will save them
money because of reduced complexity, less maintenance and more ability to do
business automation across verticals and that directly affects the bottom
line. However, you cannot ask the people who are part of the problem now to
create that solution. Their survival depends on that problem being there you
know. Just common sense.
I would like to see ebXML initiative enlarge their requirements (if you can
call them requirements at all, its more like documentation of features of
ebXML) to recommend this bold solution using the most obvious choice XML
(precisely because of tagged description). I am not saying that ebXML folks
have not done well. They have actually done tremendously well but lets not
just make the "ROAD", lets make the automobiles that use it also or at least
define what an automobile is so that all can make it in somewhat similar
fashion.


----- Original Message -----
From: "David Lyon" <djlyon@one.net.au>
To: <ebxml-dev@lists.ebxml.org>
Sent: Tuesday, June 05, 2001 11:49 PM
Subject: Re: [Fwd: Example Scenarios Used Within the Aerospace Industry]


> Abid,
>
> 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.
>
> The fact is that every day, Electronics companies get Insurance, and
> Insurance companies buy light bulbs. That's the way it was last time I
knew
> of anyway.
>
> So for anybody to say that an Electronics Industry PO can't be understood
by
> Insurance, is either off the planet or an EDI consultant.
>
> Invoicing between Electronics and Insurance, and account payments have
also
> happened for the last one hundred years as far as I am aware.
>
> Of course, there are going to be certain elements that may need to be
added
> into documents between particular trading partners. It was only because
EDI
> elements weren't tagged that this was so difficult with EDI. With XML, the
> problem has gone away and trading partners can add elements without having
> to redefine and register completely new documents.
>
> POs aren't super complicated documents, nor invoices, nor statements.
>
> ebXML needs to be forward looking, not looking to solve all the answers
for
> all industries, but just provide a basic framework of XML documents that
can
> then be "extended" to suit per trading partner requirements.
>
> Once again, it was only a technology limitation that prevented EDI from
> being able to do this in the first place.
>
> David
>
>
> ----- Original Message -----
> From: Abid Farooqui <farooqui@tampabay.rr.com>
> To: <ebxml-dev@lists.ebxml.org>
> Sent: Wednesday, June 06, 2001 1:07 PM
> Subject: Re: [Fwd: Example Scenarios Used Within the Aerospace Industry]
>
>
> > Looks like I hit a nerve there Mike.
> > I actually do have a line of work and it is certainly not directly in
EDI
> or
> > similar. I am an engineer and a computer Scientist and busines problems
> are
> > just one thing a computer scientist can work on in conjunction with
> business
> > people. I was simply pointing out what I have seen around.
> > Just consider it a fresh outsider perspective or similar. Standing
> outside,
> > I simply cannot come up with a good reason why a PO for an electronics
> > company would have to have completely different fields and options than
a
> PO
> > for companies in lets say insurance industry. Now before you go and
state
> > the obvious that the business processes for both these industries are
> > completely different, think about it from outside the box and outside of
> > that world. What we are trying to achieve is automation of the business
> > process. You can divide a business process or any other process for that
> > matter into unit of works completely independent of each other. If you
> can't
> > your approach isn't quite hitting the nail. When this unit of work is
> > completely independent of any other UOW in the process then this UOW is
> > serving the exact same purpose for the insurance industry as it is for
the
> > electronics industry. Perhaps what is happening is that we are carrying
> > information around in the POs that is really not relevent directly there
> but
> > is relevent further along after immediately processing the PO. In that
> case
> > we have not really defined PO as a completely independent unit of work
and
> > more work is needed and my point was that this is the domain of a
> standards
> > body. In the end something like this will make business processing
easier.
> I
> > hope you see my point.
> > Thanks for the link to the tutorial. I am familiar with X12 to the point
> of
> > understanding some basics but I will make sure to check it out.
> > Thanks
> > Sincerely,
> > Abid Farooqui
> >
> > ----- Original Message -----
> > From: "Mike Rawlins" <mike@rawlinsecconsulting.com>
> > To: <ebxml-dev@lists.ebxml.org>
> > Sent: Tuesday, June 05, 2001 10:35 PM
> > Subject: Re: [Fwd: Example Scenarios Used Within the Aerospace Industry]
> >
> >
> > > In response to Abid Farooqui's comments about EDI not being standard,
> > concerns
> > > about ebXML going the same way, and his proposed solution, I can only
> say
> > this:
> > >
> > > Yes, it is a pain (if you want a little more detail about why it's a
> pain
> > in
> > > EDI, I invite you to check out the article of the same name under the
> X12
> > > Technical tutorial at my web site:  www.rawlinsecconsulting.com).
But,
> > you have
> > > to remember a few basic truths.  Even though it would be ideal if
> business
> > folks
> > > were a bit more aware of some of the IT costs involved in doing what
> they
> > want
> > > to do, it is ultimately business needs that drive things and not IT
> needs
> > or
> > > wants.  We can't put the cart before the horse.  EDI POs and ebXML
> > compliant POs
> > > will be different for different companies and industries because the
> > business
> > > processes in which they are used are different.  It is as simple as
> that.
> > If
> > > you want the POs to be the same, then the business processes need to
be
> > changed
> > > - something that probably will not happen in any of our lifetimes.  If
> you
> > have
> > > problems accepting any of this, you probably need to find a different
> line
> > of
> > > work.  There has been at least one other suggestion that a "least
common
> > > denominator" approach such as the one you suggest would work, but it
> will
> > almost
> > > certainly not work because the data requirements of the business
> processes
> > will
> > > not be met.
> > >
> > > The context dependent core component work should help ease or at least
> > make it
> > > easier to identify the differences in POs, but it won't eliminate
them.
> > >
> > > Cheers,
> > >
> > > Mike
> > >
> > >
> > >
> > > ------------------------------------------------------------------
> > > 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