Well, debate is what makes life interesting!

----- Original Message -----
From: Ken Steel <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, March 05, 2000 8:23 PM
Subject: Re: To Model Or Not- An SDO's Challenge


> Len Schwartz wrote:
>
> > The original question was who should model not whether or not to model.
> > Ken's proposition was that modeling adds little value to a standards
effort
> > as model are too high level or not really actionable with the variations
> > real implementation would reveal.
>
> You also claimed earlier that I made a similar assertion:
>
> >>> Further you imply (or state) that most model
> >>> development work is too high level to be actionable between two
specific
> >>> trading partners without the compromises you have described.
>
> I corrected you then (in an email of 27Feb) and I do so again now. This is
> what was stated:
>
> > No. My experience is that people who get involved in formal modelling
> > do not know how to implement. I have never seen a formal model that is
> > accurate enough or detailed enough for an implementation to be based
> > on it. Most end up in dust or dust bins.
>
> This statement does not say anything about "standards efforts" or
> about models being "too high level" or "not really actionable". Nor does
> it say anything about "trading partners" or "compromises".
>
> So the answer I am proposing to the question "who should model" is:
> NOBODY! - it's usually a waste of time and effort which mostly leads
> nowhere.
>
> I do support a statement made by William Kammerer:
>
> "When I look at the RosettaNet PIPs, they use a lot of real estate to
> show a UML diagram explaining the "Business Process Flow," which could
> have been economically rendered in English in a sentence or two."
>
> I have also found over many years that procedures and rules simply
> stated in English are much more reliable, understandable and informative
> than a pile "real estate" containing "models" of dubious value.
>
>
> As for "standards" organisations, I have already demonstrated in my
> email of 27Feb why those engaged in the EDI standards area have long
> since been made superfluous by the onward march of technology and
> those others attempting to produce standards in the application of
> computers to business have a track record of non-performance.
>
> Also in that and the previous email of the same date I demonstrated why
> attempting to standardise business processes was futile (with or
> without modelling). So as to the value of ANY SDO attempting the formal
> modelling of business processes, my thought is: "haven't you got something
> useful you could be doing with your time"?
>
>
>
> As for your 'saucy' comment:
>
> "The comment on secret pasta sauce recipes had to do with what really
gives a
> company more of a point of difference in the market and what doesn't
create
> a real point of difference."
>
>
> Firstly, might I remind you of precisely what was said in the previous
email:
>
>         'If one looks at the actual operation of an organisation, the
>         "business model" is highly dependent on the skills, background
>         and experience of the senior management. As a result, the way
>         the business processes actually operate is different (and needs
>         to be) in each organisation. The concept of "Common business
>         objects" doesn't appear to make much practical sense.
>
>         So adopting a "common business object" may NOT be the way to go.
>         The detailed way in which a business operates is one way of
building
>         a competitive edge. Anyone trying to implement a "common business
>         object" gives up that opportunity to build a competitive edge.'
>
> You will notice it was said that using better business processes is ONE
WAY
> of gaining a competitive edge.
>
> Having superior product (pasta sauce?) or better customer service
> (an illustration you used later) are also valid ways of building a
> competitive edge.
>
> But there's a difference. The illustrations you give are both
> competitive edges to increase sales; better business processes
> are competitive edges which reduce cost. At the bottom line
> (profit/loss), one dollar saved is often worth many dollars in
> additional sales.
>
> Therefore I disagree with your statement (since you seem to think
> that increasing sales is always of more advantage than reducing cost):
>
> > I guess I see the process for receiving a
> > payment using a Purchase Card (for example) as generating less
competitive
> > advantage then the secret recipe for a pasta sauce.
>
> [I would still like you to try to explain why this proves "standards
> are being used". ;-)]
>
> -----------------
>
> So who on earth would be silly enough to give up a competitive edge
> gained through smarter business processes to adopt a "standard"
> produced (with or without modelling) by the consensus of dubious
> "experts" on some committee of an SDO, which may work, but is more
> likely not to?
>
> Conclusion: Formal modelling of business processes, particularly by
> SDO committees, is usually quite futile.  The end result will most
> likely end up collecting dust or being confined to the dust (trash)
> bin.
>
> Who should do formal modelling for "standard" business processes? NOBODY.
>
>
> QED.  ( = "Thus it is proved")
>
> --
> Ken Steel
> ICARIS Services:        Brussels and Melbourne
> Research results:       http://www.cs.mu.oz.au/research/icaris
> Commercial report:      http://desire.riv.be
> [EMAIL PROTECTED];     [EMAIL PROTECTED]
>
> =======================================================================
> To signoff the EDI-L list,  mailto:[EMAIL PROTECTED]
> To subscribe,               mailto:[EMAIL PROTECTED]
> To contact the list owner:  mailto:[EMAIL PROTECTED]
> Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/

=======================================================================
To signoff the EDI-L list,  mailto:[EMAIL PROTECTED]
To subscribe,               mailto:[EMAIL PROTECTED]
To contact the list owner:  mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/

Reply via email to