If I had to summarize what we do in one sentence, it’s this:  We give you the structure and foundation you need to solve your own JD Edwards problems independently, by teaching you how to “think JDE”.

So what does “think JDE” mean?  It means that you learn how JD Edwards works at its core, that you learn to think like a JD Edwards developer thinks when creating the applications.  Remember, the software is innately stupid—it does exactly what it is told to do, nothing more, nothing less.  To understand the software, you have to figure out what the developer was thinking while writing the program. 

To me, “think JDE” means all of the following:

• Recognizing the basic structure of the applications.
• Understanding the processing options, hard coded UDC values, and system setup values that drive the applications.
• Knowing the data files—how they are related to each other, keys to each file, how the master data is used, and where transaction data comes from. 
• Keeping in mind the maintenance implications of your setup decisions.  You don’t want to create an on-going data maintenance headache for IT or the users. 
• Knowing the “gotchas” and recent enhancements, even the ones that aren't in your version.  Often, knowing these will increase your knowledge of current functionality.  Knowing what’s not there helps draw the boundaries of what is there.

Here’s an example of what I mean.  You start with a business problem.  You decide the solution to your particular problem is that you need the system to automatically find existing blanket orders when a sales order is entered. You turn on the processing options for blanket order search in Sales Order Entry.  You enter a blanket order, and then you enter a sales order for the same item/customer and you expect the blanket order to be found and used.  Nothing happens.  No blanket order is found, and the availability screen shows that the blanket order quantity is still what it was before. 

If we are doing our job of teaching you how to “think JDE”, what would be your next move?  Would you check the system constants for Sales Order Management?  There aren’t any.  OK, you think, “I’ll check the Inventory Constants for something on blanket orders.”  Nada. “OK, there must be a UDC table, so I’ll check the System 42 UDCs.”  Bupkiss.  But, you’ve been around the block, and you check the System 40 UDCs and there’s your answer—the 40/BT UDC table.  It needs to have the document types listed that are to be treated as blanket orders.  Then you stop and think and you realize that “of course the document types had to be identified, and a UDC table is the right place to do that.  Hey, this whole thing makes sense.”  Cue the lights!

In the old days, pre OneWorld, we used to joke with clients that the only thing they had to know about JDE was F24, and if they couldn’t remember that, F1 would work.  But maybe the real thing you need to know are specifics about how to “think JDE”.

After 16 years of learning JD Edwards, I still try to “think JDE” when I occasionally get involved in solving client problems.  But more importantly, I try to communicate to our writers, instructors, and consultants that we need to teach our clients how to “think JDE.”

***********************************************************************************

Email your comments and ideas on this topic to Andy.Klee@ERPtips.com.