One World Development Advise

protech7

Member
My company has recently been purchased by another company which uses One World (Version 7xxx) as it's ERP system. My company current runs a bespoke system, based around java tools running against an Oracle DB.

The internal company pressure seems to be to ditch our beskoke system and move to One World, by re-developing our current systems under One World 7xxxx, since it is used elsewhere.

Having had a look at the existing one world system, I have some concerns that this may be in many ways a step backward from what we currently have; which is a very modern fast and flexible system.

Has anyone got any thoughts on the pros/cons of doing major new development in One World? Is this the right way to go?

Is 7xxx the right version to use? It's seems OW is on 8xxx and webclient based... Should we be looking at this newer version for a fresh project (is 8xxx more java friendly)?

What version is best to leverage our current Java expertise, if any?

I can't help but feel the drive to use 7xxx is just because that's their comfort zone.. should 8xxx be pushed as an option?

What kind of timeframe would be required to cross train experienced java developers to be prodictive under One World tools?

Any thoughs or comments would be most appreiciated.
 
Very good questions indeed.

First of all, your company is using OneWorld Xe - B7333 - which is fully supported by Oracle until at least 2013. I believe that more than 50% of customers worldwide are still on B7333 or B7334 (very similar versions).

8.9x was introduced a few years ago - but 8.9 was a bit ropey and was improved dramatically with 8.10. 8.11 eliminated the production users Windows client - and the current version is 8.12.

There are advantages and disadvantages to the newer version. The biggest disadvantage, in my opinion, is the lack of support for a Windows client and therefore a lack of choice for the customer. This is the largest disadvantage by far, and although the Web Client has improved (and consistently is improved) - it is still lacking some of the functionality and performance that a Win32 client can provide under Citrix.

From a functional standpoint, however, 8.12 has more than 5 years of extra development and improvements to functionality compared to Xe. That might sound a lot - but realistically if you're just running financials, you wouldn't see much improvement at all (just a funky web client !)

The big argument, however, isn't necessarily between versions of an ERP system - but instead what an ERP system provides above and beyond a bespoke system. The easiest answer is that your company isn't a software company, and really the job of developing software shouldn't be undertaken by your company. Certainly a bespoke system, if developed well, will provide quick and rapid solutions to inhouse problems - but it is usually limited to a specific amount of functionality, and is difficult to interoperate between multiple layers of your organization. Certainly your current system is probably not a financial system - but an ERP system provides that functionality as a core.

Usually in an organization with bespoke systems - there are many different systems that are developed for specific roles in the corporation. Each system has multiple methods of interacting with one another - and this web can be extremely difficult to identify, often preventing additional functionality or alternative systems to be incorporated.

An ERP system, however, has within its scope all aspects of a corporate environment and its functionality. OneWorld is no different, and "switches" can be triggered to turn on and off functionality - changing the system to adapt to the corporate business model at will.

Oneworld or EnterpriseOne is also upgradeable with the latest technical architectures and software. Often bespoke pieces of work are tied to a specific technology - often making it difficult for a company to continue to use if the underlying architecture has support terminated. Since OneWorld has an upgrade path based on maintenance and support from Oracle, then new technology can always be introduced and utilized.

Lastly, OneWorld is its own toolset - all the functionality of OneWorld is developed through a toolset that customers have access to - and custom code is easily upgradeable to newer versions of the software. This is the most powerful aspect of Oneworld/EnterpriseOne.

As for cross training - well, the toolset is very easy to use and requires very little formal development training or background. Most "developers" on the functional side at Oracle/JDE are actually business analysts (and sometimes their code reflects that !!!) I'd say only a matter of weeks (say 3-4) would be required for a developer to cross-train and become productive.
 
Jon,

Thanks for that response, it was very helpful.

I'm not sure I totally agree with all your logic for using an ERP over bespoke. It really depends of the quality and functionally of the bespoke system. ERP's no doubt do a good job in many situations, but they do suffer from the "being all things to all men" problem. A bespoke system, well implemented to suit a businesses requirements can often be far better than a ERP that has been customized to fit the same business demands. Anyway, that discussion is probably not for here, so I'll not go down that path
wink.gif


What I would like to know more about is the choice of 7x or 8x for a new project. From an outsiders perspective it would seem using the later version would make more sense.

Assuming the plan was at some point to move to 8, would it be sensible to use 7 first then migrate to 8, or bite the bullet and use 8 up front? Would using 7 first effect the final outcoming? By which i mean, are there sufficent improvements in 8 as to effect the way you would develop the system, causing a migrated project to have missed out on the abily to maximize on these improvments?

Can you give me some more information of how the newer web clients are implemented? Do they just run in a browser? Are they just served html pages or does funcationaly exists within the client via java or other methods?

How is the web client served? is it via an application server of some kind, Java JSP, Servlet, ASP??

Can you point me in the direction of any documentation that describes this?



Thanks, Bill
 
Hi,

B7333 and B7334 will be supported until 2013; and they
have ~50% of JDE market share, so you got quite an
interesting installed base there.
On the other hand, E89 to E812 are "prettier" (from a
graphical point of view), and they're 90% similar to
B733x from the development point of view.
From the functional point of view, E8xx have interesting
improvements for some market niches such as wine cellars,
real estate, etc; but, basic modules such as G/L, A/P
and A/R are pretty much the same across all JDE releases.
It's important to remark that E811 and E812 only
support Web clients; while the other B733x, E89 and E810
still can choose between Fat, Terminal Server and Web
clients.
No matter what release you choose, they all rely on the
same development tools (which is called OMW).
It's a graphical environment with an event-driven
interpreted language, which also allows you to write
your own low-level routines in Visual C if you like so.
You're not forced to write C code, it's just an option
in case you want to develop Business Functions that
run low-level OS operations or better performance.
One of the beauties of JDE is that its code is platform
independent, so you don't have to rewrite your code if
you decide to change database or operating systems.
Please, remark that you will never touch a single line
of Java code in JDE, you write all your code in
OMW (whether interpreted or C) and then we'll be
executed/interpreted on the Enterprise Server.
JDE also converts your interactive objects (screens,
grids, buttons) automatically to WebSphere/Oracle OAS
Java code, so it's completely hidden to users and
developers.
From the user point of view, they just either a
Fat Client (B7333 to E810) or a Windows Terminal Server
session (same releases) or a Web session (JScript and
HTML code generated by WebSphere Server).
Once again, you don't need any Java training, you need
JDE OMW training (which may take one month or so for
some guy with experience on other event-driven languages
such as VB, VC++ or Java) and then you'll need to
understand the application from the functional point of
view which may take some weeks or months depending on
your general functional skills.
Regards,
 
[ QUOTE ]

What I would like to know more about is the choice of 7x or 8x for a new project. From an outsiders perspective it would seem using the later version would make more sense.


[/ QUOTE ]
Correct, and if you were a new implementation it would be a no-brainer. However, upgrading an ERP system between different major versions is actually a big project in of itself - and is never undertaken without very careful consideration of the consequences. I'm in the midst of an 8.12 upgrade from Xe, for example, at a very small customer - and it can take many months of testing before user acceptance occurs. So customers do not upgrade their ERP systems on a whim - it certainly is not the same as running "setup.exe" !

[ QUOTE ]

Assuming the plan was at some point to move to 8, would it be sensible to use 7 first then migrate to 8, or bite the bullet and use 8 up front?


[/ QUOTE ]
It would be adviseable to place your current companies data into the existing ERP system - and not to run both a deployment AND an upgrade at the same time (too many changes at once !) If you then feel that 8.12 offers functionality that your company NEEDS, then by all means later on evaluate the upgrade - but if the functionality is not desired, then your company can comfortably stay on B7333 until at least 2013 !
[ QUOTE ]

Would using 7 first effect the final outcoming? By which i mean, are there sufficent improvements in 8 as to effect the way you would develop the system, causing a migrated project to have missed out on the abily to maximize on these improvments?


[/ QUOTE ]
No. Using Xe first will get your users comfortable with the JDE application - and will consolidate your financial information and tie your corporate functional roles closer together. Upgrading to 8.12 later on (or whatever version you choose later) will provide additional functionality - but unless we know exactly what functionality your company is looking for, I can't answer if there is any benefit or not.
[ QUOTE ]

Can you give me some more information of how the newer web clients are implemented? Do they just run in a browser? Are they just served html pages or does funcationaly exists within the client via java or other methods?


[/ QUOTE ]
The web functionality is the same code as the win32 code, but specifically "compiled" to run as Java applets on a Java Application Server. The users, these days, find that the JAS environment is very similar (not 100% similar, but pretty close) to the Windows environment - so cross-training is relatively minor for experienced Xe users. The only supported browser currently is IE (6 or above) - because there are (unfortunately) some activex controls (this help make the client look like the Windows version). It is possible to create "cut down" mobile versions of certain applications to run on mobile devices (without Activex controls). I have also found no real issue, as a techie, accessing applications through firefox (but its not recommended).
[ QUOTE ]

Can you point me in the direction of any documentation that describes this?


[/ QUOTE ]
I think there is a big list somewhere on JDEList that points people to documentation. You could try looking at my website for whitepapers (including a whitepaper on how the technology works) - and there is formal documentation on the oracle website at http://www.oracle.com/technology/documentation/jdedent.html

Others might point you in a better direction !
 
Found this attached slide; see October OW and E1 installations levels.
Welcome to the JDEList!
 

Attachments

  • 130247-2007 October JD Edwards OW and EnterpriseOne Customers in Motion.doc
    60.5 KB · Views: 151
Hello
[ QUOTE ]

On the other hand, E89 to E812 are "prettier" (from a
graphical point of view), and they're 90% similar to
B733x from the development point of view.


[/ QUOTE ]
Could you elaborate on the 10% differences in the development environment please. I am new to JDE and cannot find any courses in B733x. I was hoping a course in E8x - which I can find - would allow me to develop on B733x without too many problems. Is it just a case that there may be some things that I can't do in B733x?

Regards
 
[ QUOTE ]
Hi,

B7333 and B7334 will be supported until 2013; and they
have ~50% of JDE market share, so you got quite an
interesting installed base there.


[/ QUOTE ]
It seems that from the data Adrian Chimirel posted above that this is now less than 25% and the other 75% is spread between the 8x versions, so it appears there is a significant migration.

[ QUOTE ]

On the other hand, E89 to E812 are "prettier" (from a
graphical point of view), and they're 90% similar to
B733x from the development point of view.


[/ QUOTE ]

I think I can guess the answer, but for clarity I may as well ask...

If getting JDE developer training, would getting training on the latest 8x version be a problem, if initial development would be on 7x? Since getting 7x training (assuming you can even get it) would seem pointless if both are indeed 90% the same.

Thanks,
 
Hi,

The differences I remember are :

1. E811 and above have "Power forms", you can design
screens with more than one grid on them.
2. You can test your development directly on a local Web
engine on your PC, without having to compile a package,
deploy it, convert it to Java (aka WebGen), etc.

The rest is pretty much the same and relies on the same
design and functional philosophy.
If you attend an E8.xx development workshop, you'll feel
quite confident on an earlier B733.x environment.
 
[ QUOTE ]

It seems that from the data Adrian Chimirel posted above that this is now less than 25% and the other 75% is spread between the 8x versions, so it appears there is a significant migration


[/ QUOTE ]

First of all, don't always trust marketing data. There is absolutely no way to confirm the data - and, to be honest, not even Oracle can confirm these numbers with hard-core data.

Secondly, ERP 8.0 is the same as OneWorld Xe (ERP 8.0 is actually B7334). Therefore even with the data they suggest, more than 30% of customers are still running on B7334.

Lastly, the chart that Adrian has posted states "movement" towards 8.1x versions. Therefore, it it is probably realistic to assume that the data probably comes from SHIPPED copies of software - as opposed to activated copies - and many customers have the software shipped based on availability.

JDE/Oracle like to pressurize customers to upgrade to the latest version of software as soon as possible - even though a customer might not necessarily need newer functionality available in the product. There was a poll recently on this website and it was obvious that more than 50% of JDEList users are still on B7334 (ERP 8.0) and prior versions.

While there are certainly new customers and existing customers that are steadily moving towards 8.1x - please don't let statistics pressurize your decision into an expensive, time-consuming upgrade. Instead, identify what you currently require and PLAN your upgrade to suit your business model.
 
[ QUOTE ]
If getting JDE developer training, would getting training on the latest 8x version be a problem, if initial development would be on 7x? Since getting 7x training (assuming you can even get it) would seem pointless if both are indeed 90% the same.

[/ QUOTE ]
No, there wouldn't be a problem getting trained on 8.12 Tools 8.96
If you are going to heavily customize your ERP, you better do it on a more current release.
Every ERP upgrade requires the analysis of keeping/retrofitting your customizations, or replacing them with the new functionality. Either way, you need to test the objects (retrofitted or new); the higher the degree of testing is done, the lower the risk of having unpleasant surprises after going live is. In all the upgrades I was part of, the retrofitting/testing pie division followed the 20/80 rule. That is 80% of the effort was the testing; and you usually want to have the testing done with your users. The easiest upgrade took three months, from 7.321 to 7.333, for around one hundred objects, tested by ten users, on AP, AR, GL, Sales, Procurement, and Inventory.
Therefore, the only way to avoid the retrofitting (and the costs associated with it) would be to implement a more current release.
 
Thanks for all the contributions from all the JDE experts, a lot of the blanks have now been filled in. So, is this a fair summing up;

1) Training in the latest tools is recommended, regardless of developing on 7.x or 8.x, due to high similarity.

2) Learning curve for an experienced developer would be 3-4 weeks.

3) If beginning a fresh project with heavy customization. Use latest version upfront to avoid later upgrade work.

4) If integrating JDE with legacy/bespoke Java applications, use later versions which support GenJava and/or Dynamic java business calls.

Thanks.
 
Back
Top