The Top 15 Common Requirements for Managing Change to Oracle E-Business Suite


The integrity of Oracle E-Business Suite applications directly impacts the success and profitability of an organization. Changes to the underlying components and architecture of the applications are required to implement new business processes, adopt new corporate regulations, and correct defects. Because these changes affect the entire organization, it is vital to employ a process based on proven principles.

Many organizations that we work with today still find themselves manually managing change to their critical applications. Moreover, often the management teams do not have any visibility into what changes are planned, who requested the changes, why the changes were requested, and when the changes were actually executed.

This lack of visibility and control can be detrimental to the reliability of the affected applications and ultimately affect the customer.

An effective change management system can help establish a repeatable and consistent means of managing the inevitable changes to a business IT environment. This document outlines the top fifteen requirements that we come across when helping customers implement change management solutions for their Oracle E-Business Suite R12 applications and explains how Stat® for Oracle E-Business Suite can help address each requirement.


Requirement #1: Issue Tracking

The Need: To be able to show who requested the change, why the change was requested, who authorized the change, what was changed, and when it was done, for management reporting and auditing purposes. Issue tracking captures all this information and serves as the catalyst for implementing change.  

What Stat Provides: Stat tracks each change with a change/service request (CSR). A CSR must be created in order to initiate any change using Stat. The CSR captures who did what, what was changed, and when it was done. A CSR can be created within the tool manually, auto-generated from an e-mail, or auto-generated from an existing helpdesk tool.

Using CSRs ensures a complete and accurate trail of every change, including who created the request, due dates, and last modified dates. You can incorporate templates to gather additional information, and you can create custom templates for various types of applications and changes to suit your business needs.

The Value: Stat will ensure you have complete and accurate documentation and audit trail for changes within the Oracle E-Business Suite.


Requirement #2: Change Workflows

The Need: Both external regulatory compliance initiatives and internal audit initiatives are driving organizations to adopt a sound change management process.

Implementing a change management process involves introducing components such as approvals and tasks to ensure the proper procedures are followed as changes are introduced. This is best accomplished through the use of a workflow that has a direct correlation to each of your application environments.

What Stat Provides: Stat’s workflow can be used to define and enforce the lifecycle of all types of changes. Each change type can have its own unique workflow, or even multiple workflows users can choose from based on severity or need. For instance, when you need to migrate objects, your migration workflow will ensure that the objects are not migrated until the approvals, tasks, and other activities you defined have been achieved. For example, developers might be required to create a detailed log of what was changed and get approval before objects are promoted to production. Requirements like these can be defined as steps that Stat can enforce before the change can be migrated.  

Because there are always some exceptions to the rules, as well as emergency fixes, you may give some users “override” privileges. If an override is invoked, it will be tracked (like every activity within Stat) and will be an auditable event so that the user can document its justification.

The Value: Stat’s workflow enforces your change procedures and ensures that all types of change are performed in a repeatable and consistent manner. You can be sure that no premature or unauthorized changes will be introduced into your environments.


Requirement #3: Approvals

The Need: Many organizations still administer approvals through manual processes. They want a better process that notifies the appropriate personnel when an approval is required, enables the approval to be made online, and notifies the requestor that the change has been approved. The system should also automatically create an escalation if an approval is not received during a prescribed response time.

What Stat Provides: When an approval is required, an approval request is sent electronically to whomever you specify—a specific user, members of a class (i.e. managers), or a combination of the two. The specified approvers can approve (or deny) the request either via e-mail or by logging into either the Web or Windows interface. Business rules can be created to automatically escalate requests that are not approved within a pre-determined timeframe.

The Value: Stat automates the approval process: it ensures that approval requests are sent to the right people and enables them to accept or reject approval requests electronically. Rules escalate requests that do not receive a timely response.


Requirement #4: Enforced Security

The Need: Organizations need to ensure that only authorized personnel can approve changes to your Oracle applications and to the change management tool itself.

Different users require different privileges and roles in the change process; for example, some might need privileged passwords.

What Stat Provides: Stat uses a class-based security rights system (very similar to Oracle responsibilities) to protect your applications and the change management process itself. Each user is assigned an appropriate “queue” that enables that user to perform the activities needed for his or her role.

Stat also provides a more granular level of control that determines which applications, objects, and environments each user has access to. In order to work within Oracle E-Business Suite, a user must enter the apps and system passwords in an encrypted field; this will enable Stat to execute migrations and gain access to conduct its activities. By securing the password within Stat, you enable your users to perform their activities without the need to give them privileged passwords. By not disseminating privileged passwords, you have added another layer of protection to your application environments.

The Value: Stat helps ensure security and access within the Oracle E-Business Suite application and within Stat itself. Stat enables you to secure privileged passwords while allowing users to conduct authorized activities.


Requirement #5: Version Control and Object Management

The Need: The maintenance and support of Oracle E-Business Suite can involve many people and be very complex. Modifications in the form of extensions or customizations may be needed to meet user requirements. These modifications can cause challenges like the following:

  • Changing seeded objects can be challenging and can create problems because of interdependencies on other objects.
  • Changes to application setups and AOL objects are common but are outside the scope of most version control tools.
  • Developers sometimes need to work on the same object concurrently without overwriting each other’s code.

Therefore, organizations need a tool that can version both file-based and configuration objects, and keep developers from overwriting each other’s code.

What Stat Provides: Out of the box, Stat supports version control and migration of a wide variety of objects, including Oracle flat-file, developer, and AOL objects, as well as many application setups. By leveraging the Oracle E-Business Suite domain knowledge embedded within Stat, Stat can call the appropriate technology and ensure that the objects are being migrated in an Oracle-supported manner.  

In addition, Stat uses object locking and reservations to track who is working on a particular object, ensuring that only one person is able to deploy that object at a given time and preventing developers from overwriting each other’s work.

The Value: Stat helps ensure version control and safe migration of objects. Developers will not overwrite other’s code because they cannot access an object until they have the appropriate rights through the lock and reservation system.


Requirement #6: Object Recovery

The Need: Occasionally a change introduced into an environment has an undesired effect and needs to be backed out. Typically, this process is complicated and requires a previous version of the changed object. Sometimes, reverting to a backup of the entire environment is necessary, which can mean losing valuable information and work.

What Stat Provides: With Stat, if you introduce a change that has a negative or undesired effect on your environment, you can easily recover any previous version of the changed object or bring it back to its original (baseline) state. To recover a single object, simply use the rapid recovery wizard’s straightforward GUI interface. For all objects in a given archive set, use the migration wizard, which offers drag-and-drop functionality. All recoveries are recorded and become part of the audit trail for that environment as well as the history of the CSR.

The Value: Stat enables you to restore objects to a previous state without lots of manual work or reverting to a previous backup.


Requirement #7: Release Management/Mass Migrations

The Need: Organizations need a release methodology that enables them to package the work of multiple developers together in order to make a set of changes at the same time and on a specific schedule. In addition, more than one project may need to be implemented at the same time. Manual processes cannot ensure that all changes are executed in the proper order.  

What Stat Provides: Stat’s release management and mass migration functionality can assist you with a release methodology or with large migrations associated with a project. Even when multiple developers are working in a joint effort, Stat ensures that all the changes are made at the prescribed time and in a consistent manner.
Stat’s process helps eliminate inconsistencies around some objects being promoted and others being left behind. Specifically, a developer can associate an archive set with a particular release or flag it as “ready to migrate.” That is, although developers are still bound by the workflow rules and approvals defined within each CSR, they have the ability to specify whether particular archive sets should or should not be included in a given build.

Stat provides a release recovery wizard in case a release needs to be rolled back. As mentioned previously, all migrations are recorded for auditing and reporting purposes.

The Value: Stat enables you to implement an effective “release methodology” and coordinate the efforts of multiple developers into consolidated projects.


Requirement #8: Environment Refreshes and Cloning

The Need: Refreshing environments and cloning is a routine event for most organizations. For example, developers request refreshes to update stale data. However, objects, such as flat files or configuration objects, may be lost during the refresh and need to be restored.

What Stat Provides: While Stat does not do the actual “refresh,” it supports the refresh process in multiple ways. First, Stat incorporates the refresh process into a workflow, ensuring it is consistent and that all steps, such as the resetting of passwords, are completed.

Second, during a refresh, patches and objects that were in the target and not in the source can be lost; Stat traces all refresh operations, enabling lost attributes to be recovered.

Third, Stat helps refresh objects in a safe and timely fashion. Since all objects that have been versioned within Stat reside in the repository, they cannot be lost. Developers can easily pull the desired objects back in from their CSRs using either the rapid recovery wizard or your release methodology. By creating a new release for the refresh, developers can systematically select objects to be recovered , saving time and effort.

The Value: Stat ensures safety and consistency in the refresh process, documents all changes, and enables you to recover desired objects efficiently.


Requirement #9: Comparisons and Merging

The Need: Occasionally two environments may exhibit different behaviors, leading you to suspect there are differences in code or setups. However, organizations typically lack the ability to compare the underlying objects and determine whether they are identical. Similarly, as developers make changes to objects, they need to see the differences between their own version and the version in another environment or another developer’s version. They also need to know what will change when a new patch is introduced. Ideally, developers would have a way of selecting each line and merging the two together to create a hybrid version that will fulfill your requirements.

What Stat Provides: Stat allows you to do side-by-side comparisons of any of the pre-defined technical objects types, as well as many flat-file objects. Developer objects appear in the same format as they do in the native Oracle tools, such as the forms and reports builder. Stat allows you to pick from any subset of environments, archive sets, or patches. For example, you can easily see whether an object in development is different in production. You can also compare your current version of work to what is currently in production or to another developer’s version.

Stat allows you to choose to “show only major differences” so you can quickly focus on important issues. You can drill down to particular lines of code in order to understand the differences at the lowest possible level, and you can produce a file differences report. For flat-file objects, Stat allows you to pick the lines of code you want to compare between two different versions and merge them into one “master” file that you can save. That master file can then be sent to the working directory, versioned through an archive set, and migrated into your environments.

The Value: Stat enables you to compare versions and identify differences in objects within environments, archive sets, and patches. Stat also enables you to merge different versions of flat-file objects together.


Requirement #10: Object History

The Need: As objects are changed, organizations need a full and accurate history of each change, including who made the change. Sometimes they need to revert to the version of an object before its latest change, or investigate the evolution of an object from its creation to its current state.

What Stat Provides: All object changes are captured within Stat, giving you a full history of the evolution of each object. You can easily see which CSR a given object has been affected by, including who requested the CSR, the date of each change, and a description of the issue the CSR was intended to resolve. Additional information is available through reports you can run using Stat’s reporting tools.

The Value: Stat records a complete history of all changes to objects and enables you to easily see the evolution of any object.


Requirement #11: Impact Analysis

The Need: Before any patch is introduced into your application environments, you need to determine what will be affected. In particular, proactive impact analysis will alert you if a patch will overwrite any existing customizations so you can investigate how to preserve the customization while taking advantage of the fix or new functionality provided by the patch. Unfortunately, many organizations do not have the ability to perform effective, proactive impact analysis; instead, they must run the patch in “no apply” mode and then manually cross-check a list of objects that were changed by the process.

What Stat Provides: Stat provides powerful and accurate impact analysis capabilities specifically for the Oracle E-Business Suite. By running Stat’s impact analysis before applying a patch, you can determine how it will affect your environment. Performing impact analysis with Stat is easy: simply upload the patch that you have downloaded to your desktop from Metalink to Stat. This allows Stat to check for prerequisite patches, run an impact analysis, and eventually apply the patch. Regardless of the size of the patch, Stat’s impact analysis will show all of the affected objects.

The impact analysis shows what object changes will occur if the patch is applied and identifies any “custom” objects that have been modified by your developers. Stat can also identify “indirect impact” objects. Indirect impact occurs when you have created and call your own version of an object instead of Oracle’s seeded one. The Oracle patch has no knowledge of your object and therefore it will affect only the object that is no longer called. By identifying indirect impact objects, Stat enables you to incorporate the new fix or functionality into your object or add your changes to the new version of Oracle’s object.

The Value: Stat protects your customizations and any objects that have been replaced by any new objects from being lost during patch application, resulting in substantial cost savings.


Requirement #12: Automating Patching

The Need: One of the shortcomings of Oracle’s native patching tools is the inability to schedule patches. Automating the release of patches is an imperative, especially when there are numerous patches that need to be frequently rolled out or for release teams that are globally distributed.

What Stat Provides: Stat enables DBAs to schedule when patches should be applied. Automating the process of patch deployment increases operational efficiency by eliminating human error. In addition to ensuring the timely application of patches, patch scheduling enables organizations to schedule downtimes when it is convenient for the business, such as late at night, during weekends, or on holidays. In addition, Stat allows for sequential scheduling of patches based on defined rules. For example, three patches may need to be applied, and the second patch is a prerequisite for the third, Stat allows the DBA to easily specify that the second patch should be applied regardless of whether the first patch was successful but that the third patch should be deployed only if the second patch was successful,

The Value: Stat enables you to easily schedule patch deployment. Automating this process saves time and reduces errors.


Requirement #13: Patch Back-Out

The Need: Every patch management process must take into account all potential scenarios and include a strategy for backing out patches. However, Oracle does not readily provide adequate back-out capabilities, which leaves a large void in availability management.

What Stat Provides: Through Stat’s proprietary version control capabilities, backups of all objects are created and stored in the Stat repository. If patches contain only new versions of objects and have no DDL or DML code (which cannot be fully backed out), Stat can “back out” the patches in the order in which they were applied. In essence, Stat replaces the current versions of the objects with the previous versions of those objects in the system so that the environment can immediately be brought back into a positive state.

The Value: Stat can save you time and effort in recovering from an object level patch that had an undesired effect.


Requirement #14: Merging Patches

The Need: Merging patches together is a common practice among DBAs, especially when many patches need to be applied during a limited time.. Although merging patches reduces the time required to apply them, tracking merged patches can create additional challenges.

What Stat Provides: Stat enables you to merge patches within the product as well as track the individual patches and show their relationships to the merged patch. To provide this functionality, Stat leverages Oracle’s native ADMerge tool. Stat allows you to easily merge any patches using ADMerge: simply select the patches you want to merge from the Stat repository and specify a new name for the merged patch.

When doing environment comparisons, Stat will reflect that the patches inside the new patch have been applied as if they had been applied individually, and can also show that they were part of a larger patch.

The Value: Stat enables you to easily merge patches and track them.


Requirement #15: Auditing and Reporting

The Need: Organizations need to produce a complete audit trail and do effective reporting on all change activities. Any audit, internal or external, requires proving that you have control over the change process and demonstrating its effectiveness. Gathering this evidence can be time-consuming, especially if it involves a variety of media, such as e-mails, spreadsheets, and handwritten notes.

What Stat Provides: Since all change is conducted within a single, integrated solution and stored in a global repository, Stat provides a comprehensive view and reduces the time needed to access critical information. As a result, organizations can respond to internal or external auditors more quickly and more effectively.

The Value: Stat makes compiling reports for auditors much easier and keeps management apprised of change management activities.



Managing change within an Oracle E-Business Suite environment can be a complex and daunting task. Compliance initiatives, service level agreements (SLAs), and other external factors can further complicate matters. Additionally, manual processes can produce errors or holes in audits. Stat provides the ability to easily mitigate the risk to your environments through its issue tracking, workflow, version control, migration, recovery, patching, and reporting functionality. By leveraging its automation you can ensure consistency and accuracy when enacting change. Stat’s validation from Oracle reinforces that you can conduct change safely and in an Oracle-supported manner. Instead of building a patchwork of various disparate point solutions, Stat provides the ability to address your various change management challenges and pains in a single, integrated solution.