Re: ORACLE FINANCIALS ?

In article <limkhwee.10.0017D2D5_at_singnet.com.sg>, limkhwee_at_singnet.com.sg (Lim Kien Hwee) wrote:

> In article <3va5jl$rjt_at_nlsu110.nl.oracle.com> Andrew Sparks <asparks> writes:
 

> To add to the notion of "very customiseable". Oracle advised us during one of
> their courses that customisation is not recommended. As in later stage when
> newer upgrades are available, it will cause migration problem. As Oracle
> Financial is already a good and well constructed product, I would suggest that
> the company's business process should suit the product rather than the other
> way round. This not only applies to Oracle Financials but also any other
> financial products being offered out there.

The definition of a good product depends upon matching its functionality to user requirements. When selecting any package it is important to carry out a detailed User Requirements Specification and subsequent package selection exercise. Gaps in the required functionality will be identified, the package with the least gaps should be selected.

The significance of these gaps must then be evaluated, and some may prove to require bespoke functionality for the package to be usable. It is not sensible to force larger organisations (which Financials is aimed at) to alter their user procedures to match the functionality of any package where these deficiencies would prove seriously detrimental to the business. Obviously a lot of smaller issues will be 'lived with'.

Oracle financials is a powerful package, but many people have found problems. The package is very American and changes were needed for the European market, many users need to integrate the package with other systems and several sites have found it unsuitable for high volume purchasing operation. The beauty of Financials is that these deficiencies can be addressed in a relatively well know 'standard' RDBMS and 4GL development suite.

It is however important that customisation is done in a controlled manner, creating new menus & responsibilities rather than altering existing ones, registering any new developemnts in new applications and NEVER (well very rarely) changing the data model. So long as development is done sensibly there is little to fear from upgrades, except the need to re-visit all your code to cope with the database changes! This said it is still important to try and get any functionality changes you identify addressed by Oracle via attending their User Groups and SIGs.

Richard Avery Received on Thu Aug 03 1995 - 00:00:00 CEST