Planning support questions, answered clearly.

Oracle Planning Support is the ongoing service that keeps a Planning application working through every budget and forecast cycle: form and business rule changes, metadata and outline maintenance, approvals hierarchy updates, FDMEE and Data Integration loads, user provisioning, database refreshes, performance tuning, patching on-premises or monthly update testing in the cloud, and standby cover during the cycle. It is distinct from Oracle’s product support, which covers software defects but not your forms, your rules or your budget calendar. Namandla provides it as a managed service with a named senior consultant who knows your application.

Because a budget cycle has a hard deadline and dozens of people depending on the application on the same days. A form that worked last year fails after a cost centre is added without its security, a rule that was changed mid-year produces a different result from the version the board approved, an actuals load fails because the ERP introduced new accounts, or the administrator who built the application has left. Support exists so changes are made deliberately and tested, and so someone who knows the application can act while the cycle is running.

A typical Namandla Planning support scope covers monitoring of services, refreshes and scheduled loads; incident response with defined response times; data form and task list changes; business rule changes with regression testing against prior results; metadata and outline maintenance including the Outline Load Utility; approvals hierarchy and planning unit administration; FDMEE or Data Integration mappings and load failures; user provisioning and access permissions; Smart View and Financial Reporting support; patch assessment on-premises or monthly update regression testing in the cloud; quarterly health checks; and priority standby during budget and forecast cycles.

Usually. Common findings are business rules that calculate the full cube rather than the changed slice, forms opened with suppression off across thousands of rows, database refreshes run more often than needed, dense and sparse settings and caches left at installation defaults, fragmented Essbase databases and outlines full of retired members. In the cloud the same form and rule design faults apply, plus Groovy rules that iterate cell by cell. A health check measures form load, rule and refresh times, identifies the drivers and fixes them in order of impact. Bringing a rule from minutes to seconds is a normal outcome.

A structured review across three layers. Application: dimension and outline design, form design, business rule logic and duplication, approvals hierarchy against the current organisation, substitution variables and access permissions. Technical: version and patch level against Oracle’s certification matrix (or update status in the cloud), Essbase settings and fragmentation, integration job history, backup and restore evidence. Operational: budget calendar, who does what, documentation and key-person dependencies. The output is a written findings report with prioritised fixes, each with effort and expected effect.

Yes, and this is the core of the service. Namandla provides standby cover during budget, forecast and quarter-end cycles, with a consultant available to resolve failed loads, rule errors, form problems, locked planning units and reporting issues while planners are working. Before a budget cycle we review the outline for organisational changes, confirm that rules still produce last cycle’s results, test forms with current security, and check loads against current ERP extracts, so the cycle opens on a known-good application.

Yes. Typical improvements are targeted business rules with FIX statements instead of full calculations, forms redesigned around what planners actually enter, run-time prompts that let one rule serve many planning units, approvals hierarchies rebuilt to match the organisation, retired members and versions removed, and loads and refreshes scheduled through the Planning utilities or EPM Automate. Every change is tested against prior results before it goes live. The aim is a shorter cycle with fewer manual interventions, measured in administrator hours and planner waiting time.

Yes. Most Planning integration work sits in the loads: FDMEE or Data Integration mappings for new ledger accounts and cost centres, payroll extracts for workforce planning, and budget pushes back to the ERP. Support also covers data movement between Planning and HFM or FCCS, shared hierarchies through Data Relationship Management or Enterprise Data Management, Smart View and Financial Reporting, and, for hybrid estates, exchanges between on-premises Planning and Oracle EPM Cloud. Integration failures are usually master data changes nobody communicated, so the fix includes closing that gap.

Yes. The three common projects are an upgrade from Planning 11.1.2.4 to 11.2, including the conversion from EPMA to Classic administration where EPMA was used; a migration from on-premises Planning to Planning Cloud using Oracle’s migration tooling, with the application redesigned where the prebuilt modules fit better than a lifted custom build; and a move between Planning Cloud module configurations. Namandla handles readiness assessment, environment build, application and security migration, regression testing of rules and forms against prior results, and cutover timed around your budget calendar.

By keeping the controls that produce a trustworthy plan in working order: data validation rules on forms, business rules tested after every change, approvals that lock submitted units, actuals loads reconciled to the ledger, and outlines that match the organisation and the ERP. Support also maintains the Financial Reporting and Smart View templates that break when members are renamed, and the substitution variables that keep reports pointing at the right period and version. Accuracy problems in Planning are usually maintenance problems, and maintenance is what the service is for.

Support that works from the budget calendar rather than from incident tickets. In practice that means preparing the application before each cycle, reviewing rule and form changes before they reach production, monitoring loads and refreshes so failures are seen before planners see them, checking patch levels or testing the monthly cloud update in the test environment before production is updated, and testing restores. It also means telling you when a risk exists, such as a single administrator, an unsupported version or an approvals hierarchy that no longer matches the organisation, before the cycle exposes it.

Outsourcing makes sense when Planning knowledge sits with one or two people, when changes cluster around the budget cycle and are high-stakes, or when the finance systems team also carries the ERP, consolidation and reporting. It makes less sense if you have trained administrators 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 day-to-day ownership, and to hand knowledge back rather than hold it.

Break-fix support responds after a rule has failed or a form will not open, bills by the incident and learns your application during the call, usually in the middle of a budget cycle. Managed support knows your forms, rules, approvals and calendar, prepares the application before each cycle, makes changes under control and carries responsibility for keeping the cycle on time. Break-fix suits a stable application with strong internal skills. For an organisation whose budget depends on Planning, managed support is usually cheaper over a year, because incidents during a cycle are the expensive ones.

By measurable results on the application you already own: cycles that open on time, rules that run in seconds rather than minutes, fewer failed loads and re-runs, planners spending their time on the numbers rather than on the tool, and an upgrade or migration path that keeps the licence or subscription investment on supported software. The return is highest where a replacement is being considered mainly because the application has become slow or unreliable; that is usually maintenance debt that can be cleared for far less than a re-implementation, which leaves the platform decision to be made on merit.

Namandla is a South African consultancy whose senior team has supported Hyperion Planning and Planning Cloud for about two decades, and the consultant assigned to your application is the one who answers during your budget cycle. We support 11.1.2.4, 11.2 and Planning Cloud, FDMEE and Data Integration, and we are independent on the remain, optimise or migrate question. Where AI can help with forecast review or commentary, we apply it to the Planning data you already have, with human review. Contact info@namandla.com or 087 188 3388.