Hi Donnie,
Thanks for your good answers. Just a couple of comments:
1. "Users would do their own programming!!! WOW!!
**** I was trying to pass on some expertise and information. We don't need
to be *****childish."
I am sure you misread my intent on this one. All the exclamations are the way others
communicated this idea to me. It was not my sarcasm back at you. I even had someone
seriously ask me what I would do for work once programmers were non-existant in a few
years (late 80s)! This person was completely serious.
My point is that even though a user is trained on a handy GUI programming tool he/she
has to decide WHAT to do in each instance. This requires design. This requires
someone to look at the new TP's guideline and compare to the existing map that the
other TPs use. Then identify differences and then decide what needs to be done. No
one will ever convince me that that task can be done by a user. Following a model of
40-20-40 (40%analysis/design, 20%programming, 40% testing/install), there is a lot
more to making mods than a user is capable of because it is a lot more than just
entering information using some tools (20% of the work).
2. "I am convinced that a large number of EDI consultants try to create million
dollar solutions to hundred dollar problems."
There is no question of the human weakness to create "job security" in making their
tasks more complex and things they have to stay around for to maintain. This weakness
extends beyond EDI and even programming to many fields although it is prevalent in
programming. Personally I think a much smarter type of job security is as you have
described your own work: being fast and efficient. This always earns repeat business
and/or word of mouth reputation.
Most of the ongoing, years-long, EDI programming and maintenance I have observed in
large companies are not primarily from consultants but from full time employees.
Often in large teams one to two dozen (along with some consultants). I am unsure why
you are targeting consultant's only here. I do not consider this to be a major source
of the EDI problems that I have discussed, however. These problems are because of
differing trading partnerships as I have described earlier.
If it really is true that "a large number of EDI consultants try to create million
dollar solutions to hundred dollar problems" (ratio of ten-thousand to one!) then you
should have no difficulty in starting a large new company and winning the bulk of
these clients over to your hundred dollar services and crowding these consultant with
million dollar services out of the market.
Steve
At 05:55 PM 7/6/00 -0400, Donnie Griffin wrote:
>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
>
>
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
