EPMware Success Story: Ninety One Asset Management

Background

Ninety One is a founder-led global investment manager overseeing more than $100 billion in assets under administration. The firm was originally established as Investec Asset Management, an independent division within Investec, before demerging in March 2020 to become Ninety One, an independently listed company on the London and Johannesburg stock exchanges.

Ninety One's finance team, led by Angela Ferguson and Alison Kennedy, came from a shared background at Investec, where they had worked extensively with JD Edwards, Essbase, Planning, and Oracle Data Relationship Management (DRM). When the demerger required Ninety One to stand up its own general ledger and reporting stack, the team's familiarity with Oracle made Oracle Fusion ERP Cloud and Oracle Enterprise Planning and Budgeting Cloud Service (ePBCS) the natural choice.

At the outset, the team assumed their environment was small enough that a dedicated metadata management layer, comparable to DRM, would not be necessary. Alongside the two core systems, the finance team also relied on a set of manually maintained Excel and SQL mapping tables used to translate journal entries from the legacy JDE format into the format required by Fusion, easing the transition for end users still learning the new chart of accounts.

To lead the implementation, Ninety One engaged AMOSCA, a UK-based Oracle EPM consultancy with a South African office and a long-standing position on Oracle's EPM advisory board. AMOSCA's Gavin Hogge served as principal consultant on the project, working directly with Ninety One's finance team throughout.

The Problem

It quickly became clear that managing metadata across two disconnected systems, without a governance layer, was not sustainable. With roughly 600 metadata changes a month, maintaining Fusion and PBCS separately introduced significant time cost and risk.

Duplicate, disconnected maintenance

In Fusion, changes were maintained through spreadsheets, imported, flattened across hierarchies, and published. In PBCS, changes were made directly on the outline, requiring immediate database refreshes to avoid errors for users retrieving data. Every change had to be made twice, in two different formats, with no system tying the two together.

Slow, error-prone, and unaudited

Change request turnaround times grew longer, and manual validation gaps meant details such as attributes or shared-hierarchy memberships were sometimes missed on one side but not the other. There was no audit trail of what had changed, when, or by whom.

Hierarchies drifting out of sync

Because Fusion and PBCS were maintained independently, their hierarchies steadily diverged. PBCS was treated as the more reliable structure by default, while Fusion changes were made wherever they would fit, since correcting them properly was too time-consuming. Reporting errors traced back to these hierarchy mismatches routinely surfaced at month-end, requiring rework.

The team also faced a monthly HR data load, reconciling starters, leavers, name changes, and location changes into their staff-code dimension by hand, a manual, several-hour exercise every cycle.

The Solution

Centralizing Metadata Without Slowing Finance Down

Ninety One and AMOSCA implemented EPMware Cloud as a single, central point for creating, validating, and deploying metadata changes to both Fusion and PBCS.

	One of the project's early technical challenges was the scale of hierarchy drift between systems: one hierarchy alone had grown to more than 5,000 nodes in PBCS versus roughly 3,000 in Fusion, a gap traced back to a legacy DRM structure with fewer levels implemented in Fusion. AMOSCA used EPMware's hierarchy rationalization reporting to compare the two applications directly. Rather than simply listing where the hierarchies differed, the report generated a ready-to-run bulk upload of the specific transactions needed to bring Fusion in line with PBCS, which the team loaded back into EPMware to synchronize the structures and build out the missing levels.
	The team established PBCS as the leading application for most shared dimensions: additions, moves, and changes made there were automatically mirrored into Fusion. A dimension-specific exception was built for the product dimension, where PBCS naming conventions (a leading “product” prefix) were automatically translated to match Fusion's format, removing a manual, easy-to-miss step for the team.
	EPMware's validation engine was configured with dimension- and application-specific rules, for example, enforcing maximum entity code length and requiring company, ledger, management reporting, function, and region properties, plus shared-structure placement, before an entity could be added. Deployments fail if these rules aren't met, effectively making incomplete or malformed metadata very difficult to submit.
	For dimensions with a secondary alias table in PBCS, alias formatting requirements varied by dimension and, in two cases, by hierarchy level. A first script populated code-and-name aliases automatically on save. A second script, triggered at workflow submission, determined whether a newly added account or entity member was a leaf or a parent, since that wasn't yet known at the point of entry, and applied the correct alias format accordingly.
	Once a request clears validation and approval, EPMware deploys directly to both Fusion and PBCS from a single request, either on a nightly schedule or, for the large majority of requests, immediately. Deployment confirmation emails, one per target system, are sent automatically with a record of everything deployed.
	The monthly HR file is now imported directly into EPMware, which identifies new, changed, and updated staff records and applies them automatically, reducing a multi-hour manual exercise to a couple of minutes.
	Ninety One chose to start EPMware adoption with its finance administrators managing requests directly in the system, while end users continued submitting change requests by email using dimension-specific Excel forms. This phased approach limited the scope of change for end users during go-live, with a second phase planned to bring self-service request workflows to a broader group of power users. The full implementation, including hierarchy alignment across both systems, took approximately eight weeks.

The Results

The Payoff: Speed, Trust, and a Real Audit Trail

With EPMware in place, Fusion and PBCS hierarchies are kept in sync from a single source of change, which unlocked Fusion's built-in Essbase reporting cube for the first time; previously, structural inconsistencies made it impractical to use. Accountants can now report confidently from either system.

The team also gained a full audit trail of metadata changes for the first time, which they now use to track changes with transfer pricing impact, alongside a general increase in trust in the accuracy of their metadata.

What's next

• Expanding self-service request workflows to power users, reducing reliance on email-based requests and administrator-driven entry.

• Integrating EPMware with the SQL-based mapping tables used to generate Fusion journals, automating maintenance that is currently manual.

• Extending EPMware as the source hierarchy for Salesforce, which today originates structural changes from the front office with no visibility into downstream finance impact, alongside other consuming systems such as Clickview and Planning, to reduce duplicate maintenance across the organization.