Management news and products.

Managing Changes to ERP 

Now that the Internet is becoming a natural extension to business systems, fear and loathing may be spreading like wild-fire through financial departments as they realise that to web enable current ERP and financial systems presents a major headache. This is because virtually all deployed ERP and financial applications are customised to meet highly individual requirements. Consequently, the challenge is to maintain all of the existing customisation, within the next generation of software necessary to take advantage of the Internet. It's not easy but it can be done

What is the best path to fast implementation of ever-evolving, enabled ERP and financial applications?

An organisation can develop e-enabled ERP applications from scratch and get the exact capability they require. The disadvantage of this approach is that the applications are very costly and time-consuming to develop. Alternately, an organisation can purchase e-enabled ERP packaged applications. This reduces time to market and generally reduces cost. An additional advantage is that external (outsourced) resources familiar with the packaged applications are often available to assist with the implementation. The disadvantage is that purchased ERP applications are delivered vanilla:flavoured and not tailored to individual needs. The optimal path toe-enabled applications will depend upon the requirements of each enterprise. Often the best path is a combination of buying packaged applications and modifying them to meet specific business requirements. This approach will provide the capabilities required without the expense of developing the applications from scratch. The challenge arises with new releases, patches, upgrades or completely new versions of the suite purchased.

For example, the latest release from Oracle (release l1i) for its packaged ERP applications includes important new functionality for e-commerce. Release 11i is precisely developed to help companies leverage new Internet business practices in the areas of Internet Procurement, Internet Human Resources, and Internet Supply Chain Management. These new Internet business practices have emerged as the key to e-business efficiency and effectiveness, allowing customers to leverage the Internet to expand their markets, retain customers and increase business efficiency

The challenge

As we know, Oracle and other ERP applications, such as SAP R/3, form the foundation of many IT business functions and are 99% of the time customised. In fact, part of the appeal of such applications is strong baseline functionality combined with the ability to be tailored, given the diversity of business requirements. Certainly, vendors cannot be expected to develop a one-size suite that fits every business equally well. However, Oracle, in this case, recommends against customisations, and for some very good reasons. Buyer beware: any customisation is not a simple one-dimensional change, but often has ramifications and implications throughout forms, reports, libraries, database schemes, and integration with fine-of-business software that calls the Oracle database. As a result, companies typically expend considerable development and database management resources to custom-tailor Oracle Applications and to align the database schema, forms and applications.

One can still have a well-functioning system, despite the warning against customisation, until Oracle announces an upgrade or new release, such as 11 i Or a bug is found and Oracle ships a patch. It is hard to tell which customisations will be affected by a new patch or by a totally new release. At this point companies do not want to make massive investments and reinvent the wheel i.e., re-create call of the customisations and re-stabilize them around the new version.

Oracle and its piers, have historically issued barrage of patches to their systems--this is the way of the software world This approach enables customers to receive the most up-to-date software with the fewest number of bugs. One problem with the fast rate of change is the impact it has on its end users, ergo the financial department, which needs to maintain its services and reporting without interruption. As a new version lands on the desk of IT or worse case hits the FD's desk the question becomes 'is it worth it?' However, in this new age of the Internet the answer has ton be yes/ Therefore, it is essential to keep up with new versions that are designed to extend applications out to the Internet. However, maintaining the customisations in multiple environments like development, test and production, the upgrade process becomes unmanageable and certainly not something that an FD should have to figure out. The application code frequently changes yet there is no focused way to determine what code has changed, and what the impact will be on any customisations.

The most common problems

The following are some of the most common problems related to managing changes in ERP and Financial applications in this case Oracle:

(1) Change identification: You cannot determine, in a timely manner, what changes have been made to forms, reports, libraries or databases. In fact, it is not immediately apparent what Oracle has changed, or what you have customized, without laborious code sleuthing. Furthermore, database administrators and developers may spend hours attempting to find out why code works in TEST but not in PROD. They spend more hours determining why code that worked fine yesterday is broken today. What has changed?

(2) Assessing impact of change: It is not possible to perform impact analysis on modification to forms, libraries and database objects in a timely manner. Other parts of the application will break, costing down time and research time to resolve the problem. Inconsistencies will appear in the application because some modules needing modification will be missed. Additionally, it is difficult to determine which areas of your customized application need testing after installing patches or upgrades: A full system test would solve the problem, but it is time consuming. Foregoing testing cancause down time and frustration for end users.

(3) Processing changes: It is difficult to manage change across the multiple promotion level environments such as DEV, TEST and PROD. Several hours each night will be spent manually installing new code into every environment. The manual method is error-prone, and becomes more so as workload increases. Plus, there is no method to verify that daily installation of software was successful. Taking shortcuts such as deploying the same executable across multiple environments can turn compilation errors into runtime errors. This is the leading frustration for your end users, because it creates sporadic, seemingly unfathomable failures. In other words, the environment has been destabilized. Application performance is unpredictable.

(4) Safeguarding changes: Customised forms, reports, libraries, and other files are valuable assets that are costly to replace if the are inadvertently overwritten or lost. Additionally, most customized systems are poorly documented, making maintenance unnecessarily difficult and costly.

The cumulative effect of these problems is that if implementing a patch or update, customisations could break-and there will be no way to know where or how, because it has not been possible to track or version control and manage the changes.

This situation leaves an uncomfortable choice between two equally unappealing options: upgrade and re-create A customisations which could take months to schedule and implement, or wait to see what breaks and then fix those - not a happy scenario for FDs to be left with what could be a ticking bomb just waiting to go off. A third option is to simply freeze applications where they are, and ignore patches and upgrades. But then, the option of benefiting from valuable new functionality is taken away and this is not acceptable in today's fast paced environment.

The solution

The obvious solution is to impose some kind of application change management discipline, essential for managing and transferring customised financial applications.

The concept of ACM (Application Change Manager) is fairly simple: identify what has changed within a form report, library, or schema, as compared to its previous state. The challenge with respect to Oracle Applications is in the analysis of the internal structure of Oracle's database and program objects, i.e., their constituent characteristics and properties, which can be complex in their interrelationships and result in unanticipated impacts caused by changes elsewhere. Moreso, there needs to be a means to convey the knowledge of these changes and dependencies to developers, so that developers can easily ascertain which changes are noteworthy, and which can be ignored. The, goal is to manage change migration within all Oracle environments. By change migration, we mean being able to migrate changes created by your customisations, changes from patches and changes from new revisions-to and from all environments with dependencies on those changes. This prevents the changes from getting out of sync and causing cu stomisations to break.

To manage the change, means being able to identify the change (what was changed?), assess the impact of the change (what does it do?), process the change (do we need to migrate the change or can we ignore it? If we add the change, how do we do it?), and safeguard the change (store previous versions and document the current version). Historically, achieving all of this has been a genuine hurdle, contributing to "fear of change" because of the development resources involved in identifying, assessing, processing and versioning change to Oracle Applications.

Conclusion

If a company is customizing Oracle Applications, it needs to gain better control of the changes. Change management is a necessity in supporting complex Oracle environments. Without change management, too much time and money will be spent manually managing the environments and resolving day-to-day problems.

For the financial department an automatic change management system will speed up the deployment of new versions, patches etc. without impacting it, in terms of lack of services. It also means that the IT service is able to meet demand for changes in software and applications faster without draining its precious resources.