I'm an Oracle Applications Consultant (DBA) that specializes in performing (and supporting) the implementation and upgrade of the "Oracle E-Business Suite" (or "Oracle Applications" or "Oracle Financials" as the name has evolved over a number of years).
I first got involved with this product in 1993 when it was on "Release 9". I believe it originated 5-10 years earlier. This product has been around for quite some time.
In the early/mid 90's, as another poster mentioned, moving off the mainframe to a packaged ERP solution was the "big idea" that many companies had. The various players in this packaged market were:
-- SAP AG -- Oracle -- PeopleSoft -- JD Edwards -- BAAN -- Lawson
There may be a few others, but those are the "majors" over time. From a market standpoint, it has generally been SAP vs. Oracle. Although, SAP has, admittedly, enjoyed a measurable lead (especially with larger companies).
From a functionality standpoint, which package is chosen seems to be driven (largely) by which department in a company has the most dominant personality. If it's accounting, Oracle and JDEdwards tended to be the favorites. If it was HR, PeopleSoft almost always won. If it was Manufacturing or Distribution, SAP, BAAN, or Oracle may have won out.
As far as custom development goes, the key to ANY successful implementation of ANY packaged product is "be as vanilla as possible". The reason for this should be obvious. If you customize it, you have to maintain it. This also means that, should the software vendor issue a patch that changes the data structure, you have to re-visit your custom code again. It's much easier to let the software vendor change their code.
Developers, in my experience, tend towards giving the users what they ask for. The problem with this is, it doesn't take into account the need for supportibility and tends to breed large-scale development efforts. Additionally, too few developers (and/or analysts) really press the users on their requests. There needs to be more back-and-forth discussion to truly probe the underlying reasons for the request. By probing these issue, the developer/analyst could best determine what the REAL requirement is and provide a best-of-breed solution that would both give the user what they really need and satisfy the requirements of the IT organization when it comes to maintainability. (The old adage of "Every piece of software in development at MIT will grow until it can read news and mail..." comes to mind).
Another bit on custom development. MOST companies are not in the business of developing software. Developing/testing/supporting software can be an extremely expensive proposition. Especially if you're REALLY in the business of making widgets. This is why so many companies chose to move off their custom-developed mainframe applications and onto a packaged solution. Is it better? Depends. (Typical DBA answer, I know) If you can control the user community and find a way to live with the package pretty much as it is, then yes, it can be much cheaper. If you insist on significant custom code? Then you're back in the business of developing software. (and you're totally sabotaging the benefits of a packaged solution anyway).
This is where configurability comes into play. Through the use of various configuration options (In Oracle, this would be things like "FlexFields", "Workflows", etc.), a company can modify the behavior of the application to suit their needs. This is completely maintainable and will (generally) survive patches and upgrades. These configurations are handled by the "Functional" team during the implementation process.
Obviously, there are certain customizations that may need to be done. However, in my experience, most companies should be able to keep them to a bare minimum. These tend to be things like a customized invoice (with the company logo on it) that, obviously, wouldn't be delivered by the packaged vendor.
Slashdot Mirror
Just to clarify a few things.
I'm an Oracle Applications Consultant (DBA) that specializes in performing (and supporting) the implementation and upgrade of the "Oracle E-Business Suite" (or "Oracle Applications" or "Oracle Financials" as the name has evolved over a number of years).
I first got involved with this product in 1993 when it was on "Release 9". I believe it originated 5-10 years earlier. This product has been around for quite some time.
In the early/mid 90's, as another poster mentioned, moving off the mainframe to a packaged ERP solution was the "big idea" that many companies had. The various players in this packaged market were:
-- SAP AG
-- Oracle
-- PeopleSoft
-- JD Edwards
-- BAAN
-- Lawson
There may be a few others, but those are the "majors" over time. From a market standpoint, it has generally been SAP vs. Oracle. Although, SAP has, admittedly, enjoyed a measurable lead (especially with larger companies).
From a functionality standpoint, which package is chosen seems to be driven (largely) by which department in a company has the most dominant personality. If it's accounting, Oracle and JDEdwards tended to be the favorites. If it was HR, PeopleSoft almost always won. If it was Manufacturing or Distribution, SAP, BAAN, or Oracle may have won out.
As far as custom development goes, the key to ANY successful implementation of ANY packaged product is "be as vanilla as possible". The reason for this should be obvious. If you customize it, you have to maintain it. This also means that, should the software vendor issue a patch that changes the data structure, you have to re-visit your custom code again. It's much easier to let the software vendor change their code.
Developers, in my experience, tend towards giving the users what they ask for. The problem with this is, it doesn't take into account the need for supportibility and tends to breed large-scale development efforts. Additionally, too few developers (and/or analysts) really press the users on their requests. There needs to be more back-and-forth discussion to truly probe the underlying reasons for the request. By probing these issue, the developer/analyst could best determine what the REAL requirement is and provide a best-of-breed solution that would both give the user what they really need and satisfy the requirements of the IT organization when it comes to maintainability. (The old adage of "Every piece of software in development at MIT will grow until it can read news and mail..." comes to mind).
Another bit on custom development. MOST companies are not in the business of developing software. Developing/testing/supporting software can be an extremely expensive proposition. Especially if you're REALLY in the business of making widgets. This is why so many companies chose to move off their custom-developed mainframe applications and onto a packaged solution. Is it better? Depends. (Typical DBA answer, I know) If you can control the user community and find a way to live with the package pretty much as it is, then yes, it can be much cheaper. If you insist on significant custom code? Then you're back in the business of developing software. (and you're totally sabotaging the benefits of a packaged solution anyway).
This is where configurability comes into play. Through the use of various configuration options (In Oracle, this would be things like "FlexFields", "Workflows", etc.), a company can modify the behavior of the application to suit their needs. This is completely maintainable and will (generally) survive patches and upgrades. These configurations are handled by the "Functional" team during the implementation process.
Obviously, there are certain customizations that may need to be done. However, in my experience, most companies should be able to keep them to a bare minimum. These tend to be things like a customized invoice (with the company logo on it) that, obviously, wouldn't be delivered by the packaged vendor.