Changing JDE code

In shops I worked at in the past, the trend was to not change any JDE Code. I was recently at a shop that said that they have made extensive code changes. Is this the norm? In what areas would you normally make such major code changes?

We have changed/modified many JDE program.
67 CL's
366 RPG's + 22 Server RPG's (X.....)
65 PRTF's
114 DSPF's
For a total of 634 program/objects.

I worked as a consultant for almost 9 years before working at my current job
for 2 years. Prior to coming here I consulted/worked at other companies with
JDE and they too modified JDE code quite a bit.
Modifying their code is not a difficult thing to do nor is it a bad thing.
When it becomes a bad thing is when you do not mark your mods clearly or you
remove some of there code......then when you get cume updates it becomes
more difficult to retro fit your changes into the newer cume source.
If you are diligent in your source mod marking then upgrading is not that
difficult.

Jim Rubino
Senior Business Systems Analyst
FIKE CORPORATION
704 South 10th Street
Blue Springs, Mo.  64015
(816) 229-6216  Ext. 213
 

Obviously you would prefer to NOT change code so that future upgrades would not be quite as hard but the fact is, JDE just doesn't fit every single need of every single company. We have mod'd quite a bit of existing code for many years now. Simple changes such as moving fields around on an entry screen to make more sense (to us) or report layout changes to complete logic changes to make programs respond more to our needs. And don't get me started on completely custom stuff. We have quite a bit of that as well. Again, anywhere from reports (which we write to look like JDE Dreamwriters) to inquiry and entry programs the serve our needs better than JDE has.

It has to come down to company needs. If they really need something changed to have a definite reflection on business (such as $'s saved because of the change) to even user performance (which ends up being $'s when it comes right down to it). If the user can use the software better because of the changes, then it is likely worth it.

And... since we are a World customer and likely not to be headed down the OneWorld/ERPx path any time soon, our changes with affects to upgrades are diminishing. We will likely upgrade to cume 14 sometime this year and will likely be there for quite awhile. My .02 worth...

Dang Me,

What a crock of technically biased and ill informed (from the business
process perspective) based statements.

I have worked with JDE software for 10+ (ten plus) years both as a senior
consultant and Project Manager with (what was then a JDE business partner)
and as a 'freelance consultant' and I have almost always found that "mods"
can be limited to the generally basic set of output layout specifics (cheque
print, statement print, invoice print etc) and the obvious "bug" fixes that
all software suffers from.

I am not a newbie and until 10-15 years ago was a Chartered Accountant (in
USA speak a CPA) with extensive experience in many "packages" including
MAPICS, IMAS, INSIGHT, BPCS etc etc . What most organisations (businesses)
fail to address is THE BUSINESS PROCESS. What is so different about Sales
Order Processing in Australia or the UK or the USA, or any other module in
JDE (or any other software package) that requires "program code" changes?

In most cases if you understand the JDE software properly (or any other
software brand) and the BUSINESS PROCESS (read this as very strong skills in
business systems - not computer systems) there are usually 2-5 potential
ways in JDE to overcome a "need" without code changes. Of these potential
solutions maybe only 1 or even 2 are acceptable due to data entry volume
etc..

If, properly presented, most organisations will understand that to get the
best out of a software change requires changes to business processes,
practices. procedures etc. I cannot conceive a site with "366 RPG's + 22
Server RPG's (X.....) changes".

Manage expectations and manage business processes and you have success,
change code unnecessarily and you have major problems going in to the
future.

Regards

Colin HUGILL

----- Original Message -----
From: "Jim_rubino" <[email protected]>
To: <[email protected]>
Sent: Wednesday, April 02, 2003 1:55 AM
Subject: RE: Changing JDE code


job
with
you



Colin Hugill
Consultant
(World A7.3 cum12)

Sannan,

I can only concur on your "...NOT change code.." statement.

Moving fields about on screens or report layouts is a fact of life that we
would all like to avoid but really can't, but changing the basic processing
logic of programs is another kettle of fish altogether. Custom stuff in a
mods library separate from JDE supplied code is "kinda acceptable".

Me, I am a very experienced JDE consultant (at least in my opinion - and I
am not looking for work unless there is good trout flyfishing in near
proximity) so in some ways I am biased. But I have found that requests for
changes to JDE, when put under the microscope, tend to evaporate. If we
were talking BPCS back in 1989/90 on the AS/400 then changes in all aspects
of the word were more often a necessity, but lets not go there!

According to my philosophy, changes to packaged software only occur if the
business (not one person in one functional or activity area) can
substantively justify the change versus a change in business process - that
is "we have always done this way" is not a good enough justification.

Just a few thoughts to stir the pot

Colin HUGILL

----- Original Message -----
From: "ssolberg" <[email protected]>
To: <[email protected]>
Sent: Wednesday, April 02, 2003 1:23 AM
Subject: Re: Changing JDE code


would not be quite as hard but the fact is, JDE just doesn't fit every
single need of every single company. We have mod'd quite a bit of existing
code for many years now. Simple changes such as moving fields around on an
entry screen to make more sense (to us) or report layout changes to complete
logic changes to make programs respond more to our needs. And don't get me
started on completely custom stuff. We have quite a bit of that as well.
Again, anywhere from reports (which we write to look like JDE Dreamwriters)
to inquiry and entry programs the serve our needs better than JDE has.
changed to have a definite reflection on business (such as $'s saved because
of the change) to even user performance (which ends up being $'s when it
comes right down to it). If the user can use the software better because of
the changes, then it is !
OneWorld/ERPx path any time soon, our changes with affects to upgrades are
diminishing. We will likely upgrade to cume 14 sometime this year and will
likely be there for quite awhile. My .02 worth...



Colin Hugill
Consultant
(World A7.3 cum12)

I whole heartily agree with Colin! What was the ROI for the expenditure anyway?? Hopefully reduced operating expenses, or increased volume,,,etc. Don't accept "We've always done it that way"! What a copout! Push the envelope! Explore! Continue with your existing processes, and be out of business!

Changing THE BUSINESS PROCESS is key!

GM

What is a crock here is your attitude!!! Not every business is going to change their processes to suit "canned" software. If they did I would be out of a job. With 10+ years JDE experience I can tell you that MOST companies require changes to the base code to make it conform to the way they do business. If you can convince people to conform to base JDE, more power to you. But don't expect others to accept this as a norm. Having been the author of 100's of programs using JDE (some that have been adapted by JDE) I find your comments insulting and uncalled for!!!

Can you give us some examples where you HAVE to change the code, besides the forms changes of course.

Tim,Can you give us some examples where you HAVE to change the code, besides the forms changes of course.

I agree with both Tim and Colin - there are pros and cons to both arguments.
I would not agree with changing base code unnecessarily, however there are
business situations where it is necessary.
Examples would be:
o Additional data or data validation required on sales order entry
o Additional fields required to be printed on sales invoices
o Updating user defined fields on item / customer master files in
maintenance program
o Modifying work order creation to create multiple orders with 1 item per
order
These are just a few areas where I have seen change requirements for
specific industries - sometimes it's necessary, but if you change too much
code unnecessarily then you are just making a rod for your own back and
making upgrades extremely difficult.
Apart from the Euro changes, one good reason for moving to cum13 and beyond
is that cum11 contains the completed / corrected Y2K modifications and
beyond that you have a number of corrections and enhancements following the
JDE decision to continue support of World.



Best Regards
Tony Payne - Senior Analyst/Programmer
Aker Plastics, Plymouth, Indiana
--------------------
4+ yrs JDE World Financials / Manufacturing
V5R2 / A7.3 cum14

Tim,

I feel you really missed the basic thrust of my argument. Hence I am =
now responding with an analytical critique, rebuttal, and review of your =
posting, which is based from my experience and skill sets (not from =
yours). =20

Let me be very clear. I am not technical, that is to say I am not of a =
programming background. Despite this statement I point out that I have =
a pretty damn good understanding of the AS/400, S/38, S/36, S/34 =
technical and functional capabilities, and a reasonable (for a business =
systems consultant) skill level at reading and understanding RPG.

I agree that, quote, "..Not every business is going to change their =
processes.." but my argument is that these businesses really need to =
thoroughly examine what their objectives are and what it is that they =
really want to achieve. In many installs this has been overlooked =
resulting in what I, as a business systems consultant, often regard (and =
formally report) as unnecessary and expensive changes to software that =
when viewed after the event do not contribute any real or hard benefit.=20

Based on my experience, you cannot "..tell me.." that "..MOST companies =
require changes to the base code to make it conform to the way they do =
business..". You can, however, say that your experience indicates that =
this is the case.

Your emotive statement "..If they did I would be out of a job.." has no =
relevance to the issues I raised, and therefore should never have been =
stated. No personal affront intended, but you should consider that your =
comment might however be presumed by other readers of your post to =
indicate where your allegiances might lie. I did not regard it this =
way, I assume that you read my post and immediately reacted with a reply =
post without taking a bit of quiet or quality time to think through your =
response. Yes I am human too, and have done the same thing and, like =
you, have been on the receiving end of a response like that which I am =
writing. Like I said, no offence intended, just a thought or two based =
on my experiences and exposures.

Turning now to your "..If you can convince people to conform to base =
JDE, more power to you.." I have to say that; firstly, I have been very =
successful at convincing organisations that the basic JDE functionality =
is sound (of course I accept there are bugs, quirks, cultural =
differences, etc., etc., inherent in both the software and the =
country/organisation in which is being implemented) and that they should =
seriously look at the business processes and clerical/managerial =
practices before undertaking software code changes. Secondly, I am not =
interested in "..more power to you..". I am very seriously committed to =
achieving successful implementations with 'minimal' modifications, =
maximum efficiency, and, quality of information to support managerial =
decision making.=20

As for "..don't expect others to accept this as a norm.." - I do strive =
to achieve this!! However, as a basic and realistic human being, I =
don't expect to reach 100% or even somewhere close thereto. There are =
several philosophical sayings that are relevant (please pardon the =
poetic variations):-=20

if you try to reach the stars and fail, you usually don't wind up with =
a handful of mud
when you are up to your neck in water with crocodiles it is hard to =
remember that your objective was to drain the swamp
you can't soar like an eagle when you are "embedded" in a flock of =
turkeys=20
I wholly support any activity (technical, programing, database design, =
training, reference guides etc) that is adopted (or adapted) by JDE in =
part or in whole. How many times in my past have I raised SAR's or put =
forward strong business cases to Denver "pushing" very hard for =
realistic and practical changes (and also with other software =
companies)? There have been times that when my "push" has been so =
strong that I have been "ticked" off by my immediate superiors at =
"business partners" - fine I can live with the ticking off but I have =
maintained my integrity and professionalism. Of course I get a "thrill" =
down the track when I have seen those self same suggestions adopted in a =
later cume or release (albeit in concept rather than specific detail).

Finally if you found that my comments were "..insulting and uncalled =
for!!!.." then I can only refer you to my opening paragraph. I see no =
need for apology. My comments were not intended to be insulting, maybe =
blunt, evocative and to the point. But then I am an Australian and as a =
national body, we have not yet fully embraced the concept of =
"politically correct speak". Australians are basically up front, =
honest, with integrity, and are apt to call a spade a spade (not an =
agricultural implement for turning soil). I suggest (not, emphatically =
claim) that your assessment, of a general set of statements made by me =
as being critical of yourself, may be of an angle from the paranoia =
side. =20

Life is to be enjoyed. The views of others should be regarded as =
stimuli for a healthy, inquisitive and constructive basis for assessing =
one's own set of reality checks.=20

Regards

Colin HUGILL=20


Tim originally posted:-

What is a crock here is your attitude!!! Not every business is going to =
change their processes to suit "canned" software. If they did I would be =
out of a job. With 10+ years JDE experience I can tell you that MOST =
companies require changes to the base code to make it conform to the way =
they do business. If you can convince people to conform to base JDE, =
more power to you. But don't expect others to accept this as a norm. =
Having been the author of 100's of programs using JDE (some that have =
been adapted by JDE) I find your comments insulting and uncalled for!!!

Tim Lint
Fike Corporation
AS/400 730 V4R5M00
World Software A7.3 Cume 10
http://www.jdelist.com/ubb/showthreaded.php?Cat=3D&Board=3DW&Number=3D525=
76



Colin Hugill
Consultant
(World A7.3 cum12)

Tim, I think you missed his point that code change should be a last resort,
and that creative use of existing behaviors should rule out the need in
almost all cases. Too many mods have been implemented for bad reasons, lazy
consultants, or greedy, because customization of code creates more billing
opportunities now, and down the road.
But you did pretty much say that didnt you? One of the reasons you said mods
are needed was because without them, "you would be out of a job"! Thank you
for the LAUGH.

Case against mods:

Higher upfront costs
More complex enviroment
Higher long term costs

Dale
a7.3c9

Collin,

One example that we have in the Life Sciences business is that when a
customer orders a controlled substance they have to have something called a
"Form 222" in effect at the time of the order. This is a requirment by the
US FDA that says what they can order, how much they can order, when they can
order it, and where it can be shipped. Now the most logical place to put
this is in the Sales Order Entry program to validate and verifiy the form is
in effect at the time of the order. It also must not have expired by the
time the order is ready to be shipped. Some businesses choose to create
add-on programs others (like us) choose to embed the code in the program,
but any way it gets done it still has to be OKed before the order can be
accepted.

Douglas Belcher
KV Pharmaceutical Inc.
St. Louis MO
Opinions expressed are not necessarily those of my employe

To the group,

I totally disagree with Colins comments to the list and find it a bit
puzzling, he is/was a consultant and worked with JDE for 10+ years and he
says that "he almost always found that "mods"can be limited to the generally
basic set of output layout specifics (cheque print, statement print, invoice
print etc) and the obvious "bug" fixes that all software suffers from". I
too have been a consultant for 9+ years and I have changed and would change
any software companies program to do what a user wanted.

As my colleague has stated so clearly (Tim Lint), there is a very small
number of companies out there that uses JDE or any other software as a
"Canned" or "AS-IS" software. You also cannot convince me that your users do
not deserve to have their jobs made more streamlined, more efficient or more
productive as possible. Your users are your customers and you should be more
than willing to try to help them with their work flow. If you are telling
them to change their processes so they can use JDE as it is, then you should
not have a job.........what could you possibly be doing for your company??
The way I see it - if you are good at what you do and you are confident in
your abilities than there is no reason why you shouldn't change the software
to work better. If you are telling your company and users to change their
processes to work with JDE, then you nothing short of being lazy.
We have added options and function keys to various programs to give our
users access to other information so they would not have to exit programs to
see this information. We have also modified some programs to use different
logical files so screens load faster.

We have also modified the sales order entry program to use the configurator
program and to allow for a lot-copy function. We have also added many of our
own in-house written programs to interface with some of JDE programs to show
more information. JDE is a super product don't get me wrong, the best I
have worked with...............and I have worked with BPCS, MAPICS and PRMS
(Pansophic) over the years as a consultant. We have also written our own
in-house project tracking system, that allows us to take a source member in
SVR to our development area and move it through to test and then to
production..........all through controls and automation. I have written
some articles to the JDE Tips newsletter sharing some of the ways to help
JDE be more efficient.
Lastly - if you are not doing all that you can to make your users jobs
easier and more productive then you are doing them an injustice.
As I had said in my post - Tim and I both have been trough many JDE upgrades
and as long as you mark all of your code changes, then retro fitting to the
upgrade software is not that bad.
If everyone thought the way Colin and some of the others did, then there
would not be a JDElist!!!!!!!!

Jim Rubino
Senior Business Systems Analyst
FIKE CORPORATION



To view this thread, go to:
<http://www.jdelist.com/ubb/showthreaded.php?Cat=&Board=W&Number=52576>
http://www.jdelist.com/ubb/showthreaded.php?Cat=&Board=W&Number=52576
+ - - - - - - - - - - - - - - - - - - - - - - - -+
This is the JDEList World(tm) mailing list/forum.
Archives and information on how to SUBSCRIBE, and
UNSUBSCRIBE can be found on the JDEList Forum at
<http://www.JDEList.com> http://www.JDEList.com

JDEList is not affiliated with JDEdwards®

+ - - - - - - - - - - - - - - - - - - - - - - - -+

to the upgrade software is not that bad.

How bad does it have to be before it is too bad for you? Not all companies
have a programming staff.

there would not be a JDElist!!!!!!!!

This is a puzzling justification for making modifications to a program. I
guess it's akin to the other programmer's statement "If mods weren't done, I
wouldn't have a job". As if that were justification for making them.






Jim Rubino
Senior Business Systems Analyst
FIKE CORPORATION
To view this thread, go to:
<http://www.jdelist.com/ubb/showthreaded.php?Cat=&Board=W&Number=52576>
http://www.jdelist.com/ubb/showthreaded.php?Cat=&Board=W&Number=52576
+ - - - - - - - - - - - - - - - - - - - - - - - -+
This is the JDEList World(tm) mailing list/forum.
Archives and information on how to SUBSCRIBE, and
UNSUBSCRIBE can be found on the JDEList Forum at
<http://www.JDEList.com> http://www.JDEList.com
JDEList is not affiliated with JDEdwards®
+ - - - - - - - - - - - - - - - - - - - - - - - -+
--------------------------
To view this thread, visit the JDEList forum at:
http://www.jdelist.com/ubb/showflat.php?Cat=&Board=W&Number=52638
+ - - - - - - - - - - - - - - - - - - - - - - - -+
This is the JDEList World(tm) mailing list/forum.
Archives and information on how to SUBSCRIBE, and
UNSUBSCRIBE can be found on the JDEList Forum at
http://www.JDEList.com

JDEList is not affiliated with JDEdwards®

+ - - - - - - - - - - - - - - - - - - - - - - - -+

To the list and all "listers" in general,

Ladies and gentlemen, programmers and consultants too, some levity and
humour to defuse the polarised groundswells arising from my comments.

I promise that I will never again respond to such fundamental issues after
6:00 pm (1800 hours) and I will not issue my comments without have the draft
proofed, vetted and edited by at least two Public Relations firms and at
least two Professors of lexicography, dialectics and linguistics (one of
whom should be at a prestigious United States of America based university).
All translations from Native Australian into English and then into American
English will be undertaken by combined contracts with ASIO, CIA, NSA, MI5
and MI6, the Mossad maybe called upon in a consulting role to ensure all
translations are kosher and can be translated to Arabic if needed.
Spelling will checked using the Oxford English Dictionary and Webster's.
After all that, I will endeavour to have the USA Secretaries of State and
Defence to add their imprimaturs. Finally I will ask our Prime Minister and
the President of the USA to release some our Australian special forces
troops (SAS) from Iraq and Afghanistan to undertake deep reconnaissance of
the potential readership to identify the location and strength of both
hostile and friendly forces.

Yes and I watch kangaroos flying past my window every day with a pig or two
in their pouch because even I know pigs can't fly on their own.

Well it is the start of April but I wasn't attempting an April fool's joke.
The responses have been lively and seeming evenly divided. Hopefully
everyone's input (mine included) has created some good intellectual stimulus
and the opportunity to see the other side.

Jim Rubino wrote:

generally
invoice
change
do
more
more
should
software
to
different
configurator
our
show
PRMS
in
upgrades
the



Colin Hugill
Consultant
(World A7.3 cum12)

Obviously, quite a few people have not heard of "Best Practices". I believe
we just heard an opinion from another programmer and I am a staunch believer
that programmers do not make good implementation project team leaders
because of these very issues. I hope that does not offend anyone, but a
programmer's first instinct is to develop code. Modifications become the
easy way out rather than dealing with the business issues at hand. I think
doing a modifications is a bigger cop out compared to challenging a user to
change how they perform their job.

Don't get me wrong, there is almost always a need to do some type of
modification to canned software programs during an implementation, but the
goal should always be to minimize this development. It costs money and you
risk project delays and can get side-tracked. Modifications always come
back to bite you in the end one way or another.

One major point and then I'm done. If you have to change the software as
much as you are describing below, you probably did a very poor job of
software selection to begin with and JD Edwards was probably not the best
fit for your organization. Either that or management is not behind the
project and therefore not making users conform to the new way of doing
business.

CMirth wrote"... I am a staunch believer that programmers do not make
good implementation project team leaders because of these very issues.
I hope that does not offend anyone, but a programmer's first instinct is
to develop code. ..."

I am sure that was not meant to encompass ALL programmers. As a
programmer, my FIRST instinct is that a code change is the LAST resort.
Every time the code is touched is another opportunity for failure at
some point in the game - regardless of the rigorousness (or lack
thereof) in the QA / pre-implementation phase.

Unfortunately, in my 12 years experience, management dictates the action
taken with little regard for the position of programmers who know the
code and the technical risks and complexities. In theory, this would
not be true in company where IS (or IT or whatever the name of the week
may be) is adequately empowered within the corporate structure to do the
job properly - which includes saying 'No' to a modification request. I
wonder if such a place truly exists; it might well be the programmer's
nirvana.



J Walker
JDE A7.3 cum(mongrel)

Re: RE: Changing JDE code

Hey now we have quality responses. CMirth and JWalker81 have put up well thought through responses, thanks guys (or gals) for taking the time to contribute.

JWalker81, rest assurred you defintely do not fit into the generic category of what CMirth referred to with his reference to programmers. You maybe a programmer(I would guess a very good one too) but you probably should bill yourself as an analyst (managerial) and programmer. The last half of your closing paragraph is succint, apt and very much on the ball

Maybe we can close this thread with some more humour (or humor - it's tough
being a Brit in the USA...) - after all it is Friday.

Just print a copy of the following, frame it and put it on your desk...



Another day gone
All targets met
All systems fully operational
All customers satisfied
All staff keen and well motivated
All pigs fed and ready to fly




Have a great weekend.



Best Regards
Tony Payne - Senior Analyst/Programmer
Aker Plastics, Plymouth, Indiana
--------------------
4+ yrs JDE World Financials / Manufacturing
V5R2 / A7.3 cum14