I did not mean to imply that my accomplishments were due to in any large
part to my ability. In fact a good portion of what I accomplish is due to
the IBM AS/400 and the Harbinger EDI400 software.
In response to your questions, My answers are inserted below. Let me know if
you would like to discuss offline and will provide a phone number.
-----Original Message-----
From: Steve Bollinger [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 06, 2000 4:54 PM
To: [EMAIL PROTECTED]
Subject: Re: The REAL Problem is
Dear [EMAIL PROTECTED]
If you can truely do all this with little or no programming than you are by
far a better EDI consultant than I have been. It does sound a bit too
"perfect world" to me, but maybe I am wrong here.
I do have some questions though:
1. In your point #1 you say "Then when the data base(s) are built". This
indicates to me that you are not only involved in setting up EDI for your
clients, but also involved in some of the database and application design
and construction. Doesn't this involve.... um programming? Not just for
the database structure but for the applications that use these database
structures? I have worked on such projects that involved dozens of
programmers for months. What am I missing here?
***** ANSWER: The majority of my experience is on IBM AS/400. The data
base(s) that I ***** referenced fall into two categories.
***** A1) Those files already existing in the ERP or legacy systems (my
involvement is to *****review with/without in-house personnel to identify
which data must be populated to ******meet the existing system requirements)
I make no changes to these.
**** A2) I do create new files to store and forward data back to trading
partners (all of *****the information required by your trading partner that
is not pertinent to your *****system) Since this data is not applicable to
in-house systems no programming is *****necessary. For example I would pull
a saved field containing buyers number or name *****and send it back as part
of the invoice. With IBM AS/400 I would typically spend no *****more than
30 minutes per file to create these( not because of my ability. It is just
*****very easy). Since his information is not used in any systems, I am free
to build a ****few "all inclusive" files( I often do so by building a single
HDR01 HDR02 DTL01 DTL02****(4 files at 30 minutes each) and map data from
any number of inbound EDI documents to *****these same files and can extract
it with or without regard to the original document type.
2. Having work fields to accomodate differing data needs of different
partners is a great idea. This could be stored in a key/value pair array so
what the field represented was stored in the key field. This is an
excellent idea and would certainly help the application be more Trading
Partner generic. Where a client has an ERP (all that I have seen) without
these features, they would still need to programmed in, correct?
*** It probably depends on the ERP and how tight the structure is managed.
*** I have used this approach several times on J.D Edwards and SAP I just
keep the generic ***files in the EDI libraries to prevent upgrade problems
3. RE: "The advantage of these mappers (at least the ones I work
with) is that in a period of 1 week, I can train almost anyone in the office
environment to perform maintenance and/or additional mapping for new Trading
Partners without ANY assistance from a programmer."
If you can do this with almost anyone in the office environment, then I know
you are a better EDI consultant than I! Yes, people can be trained to use
these good tools. The problem is that a non-programmer will rarely make
correct choices on what conditional statements to make and what to setup and
why. If you mean doing some data input to setup the next Trading partner
who is using generic EDI format, then yes. But putting in conditionals to
do something special for that TP, then I highly doubt it.
**** Certainly the ability to use conditional mapping would vary. However,
for most ****organizations when you complete an EDI inbound document you are
working with the same ****requirements over and over and although the value
of the condition would be changing ****the element being testing normally
would not. Since on the outbound side we have ****saved all of the trading
partners original data we would normally not have to ****condition anything.
This sounds unusually similar to the personal DB hype of the late 1980's and
early 1990's. Small personal, or departmental Databases were the rage:
dBase, FoxBase, Access, etc. They were so easy to use that non-programmers
could do queries and even program them! The hype at the time was that they
would make programmers obsolete and not needed anymore. Users would do
their own programming!!! WOW!!
**** I was trying to pass on some expertise and information. We don't need
to be *****childish.
Did that happen? Why not? It is because most users except a few power users
don't understand the science of information. Things like: the repeating
nature of data elements and thus correct ways of structuring data, what is
grouped together and why, etc. Even though it is not writing code, setting
up a conditional choice in a nice GUI tool is still programming. I have
learned from experience, users are NOT capable of programming. Hell, I have
known my share of programmers who weren't that capable of it either
especially when you add design decisions into the mix. The biggest part of
programming is not writing the code. It is the design choices that go into
it.
**** Actually I think that it is because most "POWER USERS" Do not
understand that ****business is business and you do what you need to do with
the resources available so ****that you can book orders ship goods and send
proper invoices etc.
** You are right about the design part. Where we differ is that when a
design is ****complete the resulting software, hardware, conditional data or
whatever else is in ****fact a set of tools that should have been designed
for the benefit of the user not ****the programmer. If a finished product
requires a programmer, I contend that it is not ****finished .
No, I have to say that your #2 statement above is too "perfect world" for me
to accept. I wish it were true, because then I could go do more interesting
things with my programming skills, than boring EDI programming.
***As always different people have different ideas about "right and wrong",
Since leaving ***the corporate world for consulting, I have finished nearly
all of my assignments ahead ***of schedule using this approach. I am
convinced that a large number of EDI consultants try to create million
dollar solutions to hundred dollar problems.
*** Donnie
Steve
At 10:25 AM 7/6/00 -0400, info wrote:
>Steve,
>
>If an organization is finding it necessary to do programming for each
>Trading Partner's variation of a purchase order one of two things has
>occurred.
>
>1) A failure to do complete analysis of the Order Processing system (be it
>ERP or legacy). As an EDI consultant, I compile data defining every
>possible required field for Order Processing and a separate list of all
data
>that has to be returned to the Trading Partner (although not used on the
>vendor's end). Then when the data base(s) are built they are
"all-inclusive"
>and will book correct orders in the Vendor's system and maintain all data
>required to return to the customer. Additionally, I provide a set of "work
>fields" that allow for variations in data requirements for that "next
>Trading Partner". After all, the receiver of a document should know what
>his/her requirements are and anything other than that constitutes
>meaningless data. If your Trading Partner insist on receiving that
>"meaningless data" back on other EDI documents (ASN etc) simply map it to
>the "store and forward fields" described above.
>
>2) A poor choice of EDI software solutions. There are currently many EDI
>software packages for various platforms which are capable of handling all
>sorts of manipulations (I call them creative interpretations) of the X12
and
>EDIFACT standards.
>
>I too have been in EDI for over 10 years and have spent the last 6 as an
EDI
>consultant. I spend the majority of time installing and implementing EDI
>software for small to mid-sized companies. Typically, the only programming
>required are is any driver programs to execute the in-house (ERP or legacy)
>edit/update jobs after each communication (be it internet, VAN or direct).
>
>The mappers available in today's EDI software are fully capable of
providing
>conditioned results, doing math operation and manipulation of codes and
>field differences. The advantage of these mappers (at least the ones I
work
>with) is that in a period of 1 week, I can train almost anyone in the
office
>environment to perform maintenance and/or additional mapping for new
Trading
>Partners without ANY assistance from a programmer.
Steve Bollinger 408-853-8478
Cisco Systems GPS-IT XML/EDI Logistics & Maintenance Project
------ XML/edi Group Discussion List ------
Homepage = http://www.XMLedi-Group.org
Unsubscribe = send email to: [EMAIL PROTECTED]
Leave the subject and body of the message blank
Questions/requests: [EMAIL PROTECTED]
To receive only one message per day (digest format)
send the following message to [EMAIL PROTECTED],
(leave the subject line blank)
digest xmledi-group your-email-address
To join the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
------ XML/edi Group Discussion List ------
Homepage = http://www.XMLedi-Group.org
Unsubscribe = send email to: [EMAIL PROTECTED]
Leave the subject and body of the message blank
Questions/requests: [EMAIL PROTECTED]
To receive only one message per day (digest format)
send the following message to [EMAIL PROTECTED],
(leave the subject line blank)
digest xmledi-group your-email-address
To join the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
