How we run an EBS customization audit

Every Oracle EBS modernization path starts with the same question, and most estates cannot answer it precisely: what custom code do you actually own, and which of it is still used? An Oracle EBS customization audit answers exactly that question, and it is the piece of work that most changes the shape of every decision after it. This article is our methodology, published, so that anyone facing an EBS modernization conversation across the GCC in Saudi Arabia, the UAE or Qatar, or across the US, UK, Europe and Australia, can either use it themselves or hold a supplier accountable to something concrete.

Nothing in what follows is proprietary. The techniques are standard for anyone who has worked seriously inside EBS. What is often missing is the discipline to actually do the work, in order, before deciding the target state. That discipline is what an EBS customization audit is really for.

The first step in an EBS technical assessment is to inventory every non standard object in the instance. In a real EBS environment, the evidence for that inventory is spread across several places, and the audit has to visit all of them. None of it requires anything more than read only access.

• Custom schemas and objects in the data dictionary, typically under the customer's own APPS style schema.
• Custom concurrent programs and executables recorded in the FND concurrent program tables.
• Custom form functions, menus and responsibilities in the FND function and menu tables.
• Forms personalizations, held in the FND forms customization tables rather than in the Forms modules themselves.
• OAF personalizations, stored in the JDR (JRAD Design Repository) repository as XML documents against seeded regions.
• Custom workflows in the Workflow builder tables, and customizations to seeded workflows recorded as differences from the shipped versions.
• BI Publisher data definitions and templates registered in the XDO tables.
• Custom database objects, packages, views, indexes and triggers in the custom top schema.

As illustrative examples of the read only queries used to seed each of those lists, the shape of the SQL is short and non intrusive. The exact table usage varies by EBS release, so treat these as starting points and adapt to the target instance.

For custom concurrent programs, a query along the lines of select count(*) from applsys.fnd_concurrent_programs where application_id in (select application_id from applsys.fnd_application where application_short_name like 'XX%') gives an initial count of programs registered under custom application short names. For objects in a custom schema, select object_type, count(*) from dba_objects where owner = :custom_schema group by object_type produces the shape of the custom code footprint. For OAF personalizations, the JDR repository query select path, name from jdr_paths joined against jdr_components locates personalization documents against seeded regions. All three are read only, and all three are illustrative starting points rather than a finished script.

Presence is not use, and this is the step that separates a real EBS technical assessment from a spreadsheet listing objects. For each item in the inventory, the audit looks for evidence that it has actually been used over a representative period, typically the last twelve to twenty four months, chosen to span at least one full year end and one full patching cycle.

The evidence is concrete. Concurrent request history in FND concurrent requests, showing which custom programs actually ran, when and by whom. Function access history and login activity, showing which custom forms and OAF pages were actually opened. Workflow item activity history, showing which custom workflows fired. Table level statistics and DML activity, showing which custom database objects are actually being written to. The point of the exercise is to distinguish live customizations from dormant ones with evidence rather than opinion.

In every EBS estate we have audited, the volume of dormant custom code surprises the team closest to the estate. That is not a criticism, it is a natural consequence of years of accumulation and staff turnover. The audit surfaces it, and the surfacing itself is a large part of the value.

Every item that survives step two is scored on four axes. These are the axes we have found actually predict what happens to the item in a modernization programme, as opposed to what people say about it in a workshop.

1. Business criticality. If this customization stopped working tomorrow, what would happen to the business? Score high if a core process would stop, low if the impact is convenience or reporting.
2. Technical fragility. How likely is it to break under a patch, an upgrade or a platform move? Score high if the code depends on undocumented behaviour, seeded object internals, or specific technology stack versions.
3. Bench depth. How many engineers in your organisation can safely change this item today? Bench depth of one is the single most common driver of a customization becoming an urgent problem, and it is the axis most often ignored in traditional scoring rubrics.
4. Documentation quality. Does anything written down describe why this exists and what it is supposed to do? A customization with no documentation and no living author is a liability regardless of how technically clean the code is.

The scoring is honest, not scientific. What matters is that the four axes are applied consistently across every item, so that comparisons across the inventory are meaningful. The bench depth axis is the one clients most often ask us to explain, and the one that most often changes the recommendation.

The output of the audit is a ranked list, with a recommended disposition for each item in one of four categories. The categories are deliberately blunt.

• Keep. The customization is in use, is well built, has bench depth and continues to earn its cost. Leave it alone and document it if that has not been done.
• Document. The customization is in use and is worth keeping, but no one currently on the team can safely change it. Bring the documentation up to a level where a second engineer can pick it up.
• Rebuild. The customization is in use, but is fragile, undocumented, or dependent on a technology being retired. Plan a targeted rebuild, typically on APEX for data heavy items and inside Fusion tooling for items being carried to Fusion.
• Retire. The customization is not in use, or its function is now covered by standard product, or the process it supported no longer exists. Remove it.

Retire is the most valuable disposition and the least often used. Every customization retired is code that does not need to be tested against the next quarterly Critical Patch Update, does not need to be re certified against the next database upgrade, and does not need to be rebuilt in whatever target state the estate eventually moves to. It is pure ongoing saving.

A serious EBS customization audit reliably surfaces a set of patterns that clients almost never expect at the outset, and that are almost always present.

• Customizations nobody can explain, sometimes with the original author long departed and no design note in the repository.
• Duplicated functionality, built twice by different teams for the same business need, sometimes with slightly different behaviour that has quietly diverged.
• Code written for a legal entity or business process that no longer exists, still running on schedule, doing nothing useful.
• Customizations that exist only because a standard feature was not configured correctly at go live, where the correct fix is a configuration change rather than a rebuild.
• Custom concurrent programs scheduled to run nightly that have not produced meaningful output in years, because the downstream consumer of their file was decommissioned.

Naming these patterns out loud is part of the value of the audit. It creates the shared factual basis on which every subsequent modernization decision can be made without argument.

We deliver customization audits as a written deliverable inside our EBS Care retainer. The output is a document the client owns: the inventory, the usage evidence, the scored table and the ranked disposition list, with recommendations that a second party can act on even if that party is not us. There is no lock in, because there is nothing to lock in to.

In our experience, an EBS customization audit is the least regrettable spend in any modernization programme. The cost is small relative to what it saves, the output is reusable across every possible target state, and the decisions it enables are the ones that most improve the outcome. Whether the destination turns out to be an in place upgrade, an OCI replatform, a Fusion move, or the honest recommendation to leave a stable estate alone, the audit is the piece of work that makes the destination affordable.