EPM Planning, formerly known and sold as Planning and Budgeting Cloud Service (PBCS), is a full-featured data input and reporting tool built for annual planning and periodic forecasting. If you get the enterprise edition, you get access to additional modules that create plan types for workforce planning, capital depreciation planning, and project planning with additional modules available. This purpose-built tool can be leveraged as is straight out-of-the-box. The only requirement is a stable, known general ledger chart of accounts with all chart fields and their respective hierarchical structures to be complete and available for uploading into EPM.
The typical timeline for a bare-bones implementation is generally between eight to twelve weeks. There are some considerations when deciding to use the additional pre-built modules because the time saved implementing those modules is redirected to additional configurations—demanding extra attention. So, depending on the module being implemented, you should anticipate adding additional time to the eight to twelve-week estimate. The typical end to end implementation of EPM Planning is between 16 to 24 weeks as part of a larger ERP implementation. Although as will be described later in this article, it is possible for EPM Planning to go live and be deployed independently.
Big Three Best Practices for Implementing & Deploying EPM Planning
Regardless of the specific business objectives for implementing and deploying EPM Planning, there are some universally agreed best practices that should guide your approach. The “big three” absolutes are as follows.
- Always set object account segment and time period dimensions as “dense” with all parental members set to dynamically calculate upon retrieval.
- Always prefix the long descriptions (aliases) of all account segments with key code and a leading designator based on dimension to ensure uniqueness among all database outline members.
- Always arrange database outline where “Account” and “Time” tagged dimensions appear first (on top) and all sparse dimensions appear in order from largest to smallest to improve retrieval and calculation performance.
When creating your application, following these three major “rules” will save you infinite stress and potential headaches later. Now for the rest of the story…
The perceived success of the implementation of ANY purpose-built tool is based on satisfying expectations and managing perceptions. In the case of EPM Planning, it is often that the quick win of creating the database outline, and seeing the first web input forms, tends to encourage the mindset that the application is “done”. Certainly, the setup and configuration of the database outline with the preliminary proto-typical input forms can be completed within the initial two weeks of the project (commonly during what is called the “discovery phase”). This is where a great deal of open conversation should take place to forecast continuing effort after the discovery phase.
7 Major Tasks on EPM Planning Implementation Critical Path
These are the major tasks/activities on the critical path for the implementation of EPM Planning.
- Master data collection (extraction of the GL chart fields into text files for building the database outline)
- Creation of database outline (adhering the rules previously mentioned)
- Validation and upload of actual data into database
- Creating/updating the basic web input forms that reflect the business process for collection of annual budget or periodic forecast updates
- Creating specialized calculations scripts or business rules for advanced analysis (this can include allocations, eliminations, payroll taxes, etc.)
- Assembly of reports using Hyperion Financial Reporting Studio or adhoc analysis/retrieval templates using SmartView for Office (both tools come as part of the EPM Planning bundle)
- Final security and workflow setup for all designated planning/approval users
Although this critical path may seem straight-forward from a project management perspective, it should be clearly explained that this is not a description of a basic “waterfall” methodology. In truth this is where the expectation setting needs to focus. The best approach for an implementation/configuration of EPM Planning is an “Agile” methodology due to the very highly iterative nature of all the connected tasks/activities on the described critical path. You should expect to cycle through those seven major activities many times. Training and familiarization for people participating during the implementation happens organically as part of the effort. No official conference room pilot occurs natively in a EPM Planning project.
Critical Milestones
These are generally the more critical milestones.
- Completion/verification of database outline
- Validation of initial data set (historical actuals)
- Completion of web input forms based on business process use cases
- Validation of calculations and business rules (also based on business process use cases)
- Completion/validation of reporting objects and other required output
Security setup, training and deployment are more appropriately part of the project management effort. The previous list focuses on the “hands on keyboard” activities and tasks required for the completion of the planning model.
Expectations
Since the nature of an EPM Planning implementation effort is very iterative, it is possible to cycle through the critical path many times before being able to complete any single milestone. Once again, the “Agile” methodology which focuses on “user stories” (business process use cases) will give you a better idea on how to track progress—it is very much like a Rubik’s Cube. You have to “break” some things, or undo items that may have been previously been perceived as “complete”, in order to move other items on the critical path forward.
The good news is that EPM Planning can be deployed independently and does not need to wait for other work silos to be complete in a larger ERP implementation. Most often EPM Planning can go live at the beginning of any forecast cycle independent of any other activities in flight.
The only thing you must have is a stable general ledger to form the backbone of the application outline. The business process and related use cases flow from this starting point.
EPM Planning does not typically hold journal-level details. Debits, credits, and invoice detail is rarely (if ever) part of the data contained in EPM Planning. It is possible to connect to that very granular level of detail from within EPM Planning, but the tool is purpose-built for the collection of annual plan/budget data or update of periodic/rolling forecasts. EPM Planning generally contains a static data view (generally monthly closed values). It is a performance monitoring tool comparing actual to budget to forecast.
The ultimate key to success is knowing and sticking to the business process (use cases) for which you are deploying this tool. Focusing on the key business process of budget planning and forecasting is the best way to avoid confusion and set proper expectations for greater user acceptance.
