Hyperion support questions, answered clearly.

Oracle Hyperion Support is the ongoing service that keeps an on-premises EPM System estate working as a whole: HFM, Planning, Essbase, FDMEE, Financial Reporting and Smart View, plus the shared infrastructure they depend on, such as Shared Services, EPM Workspace, the application and database servers and the scheduled jobs that tie them together. It is distinct from Oracle’s product support, which covers software defects but not your applications, your infrastructure or your close calendar. Namandla provides it as a managed service with a named senior consultant who knows the estate. The product-specific support FAQs on this site cover each application in depth.

Because a Hyperion estate is several applications that fail together. A Windows patch applied without checking Oracle’s certification matrix takes down Shared Services and every application behind it; an expired certificate stops Smart View for all users; a database that has not been maintained slows HFM and Planning at once; and the administrator who understood how the pieces fit has often left. Hyperion skills are scarce in South Africa. Support exists so the estate is maintained as one system, changes are made deliberately and someone who knows the whole picture can act during the close.

A typical Namandla Hyperion support scope covers monitoring of services, servers, databases and scheduled jobs across the estate; incident response with defined response times; the application-level work described on the HFM, Planning, Essbase, FDMEE and Smart View support pages; Shared Services provisioning and security; EPM Workspace and certificate management; patch assessment against Oracle’s certification matrix; backup and restore verification; quarterly estate health checks; and priority standby during month-end, budget and year-end cycles.

Usually, and often at the estate level before the application level. Common findings are database statistics never refreshed, application servers running with installation-default memory settings, scheduled jobs from different applications contending for the same window, audit tables that have grown for years, and network or virtualisation changes made without the EPM team knowing. A health check measures consolidation, calculation, load and retrieval times across the estate, identifies the shared drivers first and the application-specific ones second, and fixes them in order of impact.

A structured review of the whole estate across three layers. Applications: HFM, Planning, Essbase, FDMEE and reporting, each against its own checklist. Platform: versions and patch levels against Oracle’s certification matrix, server sizing, database health, Shared Services and Workspace configuration, certificates, backups and restore evidence, integration job history. Operational: close and budget calendars, who does what, documentation and key-person dependencies. The output is a written findings report with prioritised fixes across the estate, each with effort and expected effect, plus the remain, optimise or migrate position.

Yes, and at estate level that means one point of contact whatever fails. Namandla provides standby cover during month-end, budget and year-end cycles, with a consultant available to resolve failures in any application or in the shared infrastructure while the cycle is running. Before year-end we review the year’s changes across the estate, confirm that prior-period comparatives still consolidate to the published figures, test the critical Smart View packs, check FDMEE mappings for new ledger codes and confirm that backups have been restored successfully at least once.

Yes. At estate level the typical improvements are a single overnight schedule that sequences FDMEE loads, HFM consolidations, Planning refreshes and Essbase calculations without contention; a standard for Smart View versions and connections; documentation of how the applications depend on each other; and retirement of the scripts, scheduled tasks and workarounds that accumulated over a decade. The application-level improvements are described on each product support page. Every change is tested against prior results before it goes live.

Yes. Within the estate, support covers the data flows between HFM, Planning and Essbase, the FDMEE loads from the ERPs, Data Relationship Management hierarchies and the reporting layer. Between the estate and the cloud, it covers hybrid arrangements where on-premises applications exchange data with Oracle EPM Cloud services during a staged migration. Integration failures are usually a source change nobody communicated, so the fix includes a change-notification step with the ERP and finance teams.

Yes. The common projects are the upgrade of the whole estate from 11.1.2.4 to 11.2, which brings it back onto Premier Support and current platforms and includes the EPMA-to-Classic conversion where Planning used EPMA; a migration of part or all of the estate to Oracle EPM Cloud, staged by application; and consolidation of an estate spread across several old servers onto a supported platform. Namandla handles readiness assessment, environment build, application migration, regression testing against prior periods and cutover timed around the close calendar. The 11.2 upgrade page describes the upgrade service.

By keeping the controls in every application working and the data flows between them reconciled: FDMEE validation and check rules, HFM intercompany matching and ownership, Planning approvals and validations, Essbase load rules, and Smart View templates that point at current members. Estate-level support adds the reconciliation between applications, so the Planning baseline agrees with the HFM actuals and the Essbase reporting cube agrees with both. Accuracy problems in a Hyperion estate are usually maintenance problems somewhere in that chain.

Support that works from the close calendar and the patch calendar rather than from incident tickets. In practice that means monitoring services and scheduled jobs across the estate, reviewing changes before they reach production, checking patch levels and certificates quarterly, testing restores, tracking Oracle’s support dates for the versions in use and preparing for year-end in advance. It also means telling you when a risk exists, such as an unsupported version, a single administrator, an expiring certificate or an untested backup, before it becomes an incident during a close.

Outsourcing makes sense when Hyperion knowledge sits with one or two people, when the estate is on an older version and nobody in-house has done the upgrade before, when changes are infrequent but high-stakes, or when the finance systems team is stretched across ERP, planning and reporting. It makes less sense if you have trained administrators for each application who run every cycle and keep documentation current. Namandla’s managed support is designed to work alongside an internal team, taking the specialist and standby work while your team keeps ownership, and to hand knowledge back rather than hold it.

Break-fix support responds after something has failed, bills by the incident and learns your estate during the call. Managed support knows the applications, the infrastructure, the integrations and the calendar, monitors the estate between closes, makes changes under control and carries responsibility for keeping the close on time. Break-fix suits a stable estate with strong internal skills. For a group whose close and budget depend on Hyperion, managed support is usually cheaper over a year, because incidents during a close are the expensive ones and estate-wide incidents are the most expensive of all.

By measurable results on the estate you already own: consolidation and calculation times reduced, close days recovered, fewer failed loads and re-runs, an upgrade path that keeps the licence investment on supported software, and a documented estate that does not depend on one person. The return is highest for groups considering a migration mainly because Hyperion has become unreliable; in most cases that is maintenance debt that can be cleared for a fraction of a migration budget, which leaves the platform decision to be made on merit.

Namandla is a South African consultancy whose senior team has supported Hyperion estates for about two decades, across HFM, Planning, Essbase, FDMEE and Smart View on 11.1.2.4 and 11.2, and the consultant assigned to your estate is the one who answers during your close. We support the estate as one system rather than as separate applications, we are independent on remain, optimise or migrate, and where AI can help with the close or the forecast we apply it to the Hyperion data you already have, with human review. Contact info@namandla.com or 087 188 3388.