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.
First, I have seen lots of academic reports, models, "documents," and
implementation efforts end up in the 'dust bin.' The entire reasoning
behind the latest of quality efforts ( a la GE's 6 Sigma) has been to redraw
the(model) process around a business activity, identify unnecessary steps,
because activities have grown up and often not been rationalized. That poor
quality efforts are done in modeling does not mean that building around
business process is not sound. Second, there is no gain in statements such
as 'those that model are incapable of implementing' or 'those that are
consultants are incapable of executing their own business or they would be.'
On to modeling: The issue is whether to design what we do around a document
or a process. The document was a previous expression of what someone felt
was required to pass through the interface between two activities (i.e.-
send an order/receive an order). By examining the real business process,
two benefits are gained. First is a clearer understanding of the
fundamentals required. Second is (if the information is retained) the
ability to reuse components of the process. I still believe consistency
leads to greater efficiency and lower costs.
By gathering more of the organizations (internally, externally or both)
around 'that process,' you are more likely to discover common elements
without "hiding" them behind tactical interpretations (like we do purchase
order numbers differently, the fourth digit in ours means something special,
we need a new transaction set). The model removes any of the execution
specific layer from basic design.
Two examples that probably won't pass Ken's standard of rigor but have
worked elsewhere.
1. When we redesigned our electronic banking platform, we looked at the
process for entering and executing payments. When these issues were looked
at on a country specific basis we generated lots of different forms or
screens, often one per payment type. When we looked at the process we were
able to normalize the action steps around a single form with a series of sub
forms triggered only when needed. Everything else was absolutely
consistent. In fact different modules that contained the same 'action steps'
were also made consistent. It yielded a much more consistent, user friendly,
process that also makes training easier (i.e.- on one process rather than a
separate process for many different countries).
2. If we do modeling right, we would design edi/ecommerce around the
process (for example) of making a deposit at an ATM rather than just the
contents of the deposit ticket itself. That process consists of several
components in common with other processes (i.e.- making a deposit over the
counter, communicating a payment, etc.). Saving these components allows you
to reuse them in different configurations (models).
Today we have four different ways in X12 to describe a financial
transaction- and companies that engage in all four activities have to enable
four different edi expressions for a financial transaction. (This is the
820, 821, 822 and 823) If we had built our transaction sets out of a
model, each of these transaction sets would have used a common expression
extended by any additional data only when needed for that activity rather
than four completely different expressions. In other words, the
requirements of generally using standards are tactically more complicated.
(FYI- the TR2 or model in X12 does at least relate transaction sets
together. I am advocating a real model would go a step lower).
A real benefit of generating the objects (i.e.- a purchase order) that come
out of the model effort is that exactly the same content can be presented in
different languages (i.e.- XML, X12 syntax, EDIFACT syntax, etc.). In fact,
the same object has been defined with different content, in the past,
dependent on the language the work effort was built around. I have to
believe that interoperability is enhanced by this. So, GM (for example)
sends out a request to its suppliers. This request is conveyed in one
language. Half the supplier receive a traditional application to
application message and half receive it on a browser. Each send back their
response (another object) and it is normalized into the application to
application messages GM uses. Throughout the process the content is the
same because the objects being used are the same.
I don't believe anyone is saying that some day all companies will do all
things the same way. I do believe that most basic activities are the same
across companies and that where standards can be achieved, we have the
opportunity to increase the efficiency/lower the cost of an activity that
adds less point of difference and focus more resource on activities that do
add a point of difference. And explicit models of process are a better way
to get to this then implicit models that everyone has in their minds in a
standards effort but never externalize and normalize.
Len Schwartz
-----Original Message-----
From: William J. Kammerer <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Tuesday, February 29, 2000 11:36 AM
Subject: Re: To Model Or Not- An SDO's Challenge
>Getting back to the main question on this thread, whether to model or
>not, Ken Steel had also written that "[t]he only people who resort to
>modelling in my experience are those incapable of implementing. How many
>models have you seen that are even close to being sufficiently detailed
>and correct to be used in practice? Certainly, to the casual observer,
>formal modelling can look like feverish activity. But how useful is the
>end result? Most of it ends up in dusty archives or waste paper
>baskets."
>
>Modeling kind of reminds me of flowcharts. 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.
>
>But I'm unsophisticated in these matters; can someone illustrate the
>usefulness of modeling business processes, especially as it relates to
>the development of XML/EDI standards? I think Leonard & Catharine were
>attempting to do this, but I'm still not convinced. What ever became of
>the modeling efforts in X12's SITG before that group was disbanded? If
>modeling is useful, does it necessarily mean that flowcharts are the
>best way to illustrate models?
>
>William J. Kammerer
>FORESIGHT Corp.
>4950 Blazer Memorial Pkwy.
>Dublin, OH USA 43017-3305
>(614) 791-1600
>
>Visit FORESIGHT Corp. at http://www.foresightcorp.com/
>"Commerce for a New World"
>
>=======================================================================
>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/
