Comment Random thoughts on Oracle (And ERP in general) (Score 2, Insightful) 147
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.
As to one posting that was asking "Why haven't we seen open-source alternatives":
I don't know that there are any open-source packages that offer a comperable list of features to either product. However, there are some Open-Source options that provide at least some of the functionality. (I believe some magazine... "ComputerWorld" maybe? ran had an article on Open-Source CRM & ERP last year).
A (very) brief list of links/projects/products:
SugarCRM.com
Compiere.org
erp5.org
ofbiz.org
Failed implementations exist for practically all products. And the reasons that those projects fail tend to come down to either:
1. Failure of the company to truly "engage" in the implementation.
You can't just hire a bunch of consultants to implement the software. The user community
MUST be involved. The consultants will not know the pecularities of your business environment. Plus, user-buy=in will lead to less confusion on your go-live date.
2. Incompetence.
An "Oracle DBA" isn't the same as an "Oracle Applications DBA". Similarly, an "Oracle DBA"
isn't the same as an "SAP DBA" (Even if you're running SAP on Oracle, which many SAP
customers are doing). Having staff that has experience with the product can make a critical
difference. Similarly with consulting. No, "SAP" and "Oracle" aren't "Just another ERP
product" (as I once heard another firm say). They have their own quirks and their own
methodologies.
You wouldn't hire a Windows admin to run your Unix boxes. Why would you hire a JDEdwards
consultant to implement Oracle Apps?
3. Failure to properly define requirements and/or set expectations.
You have to choose the correct product for your company. Simple as that. Additionally,
"Scope Creep" is a problem on almost EVERY project. Most project timelines are pretty aggressive. Adding too many extra items to the critical path is a sure way to disaster.
Make sure you truly understand the CRITICAL needs of the organization. Identify what
tasks HAVE to work and which ones are "optional". Just because the loudmouth VP doesn't
get the report he wants on Tuesday morning, doesn't mean the business stops. But, if you
can't ship product, you have an issue.
-- James
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.
As to one posting that was asking "Why haven't we seen open-source alternatives":
I don't know that there are any open-source packages that offer a comperable list of features to either product. However, there are some Open-Source options that provide at least some of the functionality. (I believe some magazine... "ComputerWorld" maybe? ran had an article on Open-Source CRM & ERP last year).
A (very) brief list of links/projects/products:
SugarCRM.com
Compiere.org
erp5.org
ofbiz.org
Failed implementations exist for practically all products. And the reasons that those projects fail tend to come down to either:
1. Failure of the company to truly "engage" in the implementation.
You can't just hire a bunch of consultants to implement the software. The user community
MUST be involved. The consultants will not know the pecularities of your business environment. Plus, user-buy=in will lead to less confusion on your go-live date.
2. Incompetence.
An "Oracle DBA" isn't the same as an "Oracle Applications DBA". Similarly, an "Oracle DBA"
isn't the same as an "SAP DBA" (Even if you're running SAP on Oracle, which many SAP
customers are doing). Having staff that has experience with the product can make a critical
difference. Similarly with consulting. No, "SAP" and "Oracle" aren't "Just another ERP
product" (as I once heard another firm say). They have their own quirks and their own
methodologies.
You wouldn't hire a Windows admin to run your Unix boxes. Why would you hire a JDEdwards
consultant to implement Oracle Apps?
3. Failure to properly define requirements and/or set expectations.
You have to choose the correct product for your company. Simple as that. Additionally,
"Scope Creep" is a problem on almost EVERY project. Most project timelines are pretty aggressive. Adding too many extra items to the critical path is a sure way to disaster.
Make sure you truly understand the CRITICAL needs of the organization. Identify what
tasks HAVE to work and which ones are "optional". Just because the loudmouth VP doesn't
get the report he wants on Tuesday morning, doesn't mean the business stops. But, if you
can't ship product, you have an issue.
-- James
