Understanding PeopleSoft Planning and Budgeting

This chapter discusses:

• Planning and budgeting process.

• Application architecture.

• Rule-based methodology.

• Activities.

• Role-based processing.

• Workflow.

• Memory limitations and data considerations.

Planning and Budgeting Process

Planning and Budgeting is an analytical application that helps you set top-down targets and generate a bottom-up budget, which is at the foundation of your organization's operations. It helps management evaluate business alternatives and set financial targets, and it enables the organization to work cooperatively and efficiently through the budgeting iterative process—reevaluating expenses and revenue estimates; changing start and end dates; and modifying objectives.

Planning and Budgeting enables different departments to use compatible tools based on the same assumptions. By delivering a shared business model with role-based access over the internet, every participant can interact with his or her portion of the business plan or budget at any time, from any global location. You can respond quickly and efficiently to the changing business environment. Through what-if analysis and modeling, you can simulate headcount changes, expense control strategies, and capital investment plans before implementation. Marketing volatility and other deviations from the original plan can be handled proactively, in real time, rather than once a year.

Use Planning and Budgeting to:

• Develop planning targets.

• Access and analyze historical and current data.

• Connect strategic objectives with daily processes.

• Link top-down targets with bottom-up budgets.

• Integrate and update financial statements as business conditions change.

• Conduct continuous forecasting.

• Perform real-time, multidimensional modeling of your planning and budgeting data.

Like other PeopleSoft applications, Planning and Budgeting stores data in relational database tables. You can extract, view, analyze, and modify this data and then move it back into the original tables. Understanding the concepts behind this process—and the tools that help you manipulate the data—helps you perform your role in the planning and budgeting process at your organization.

This flowchart illustrates the Planning and Budgeting process, which includes defining budget objectives; accessing historical and actual data; developing a base budget; preparing, reviewing and refining a budget; posting and reporting results; and monitoring progress and amending the budget.

Planning and Budgeting process

Application Architecture

This section discusses:

• PeopleSoft Enterprise Performance Management data warehouse.

• PeopleSoft Pure Internet Architecture.

• PeopleSoft Analytic Calculation Engine.

• PeopleSoft HRMS and Financial Management databases.

• Reporting and analysis.

This diagram illustrates the Planning and Budgeting architecture:

Planning and Budgeting architecture

PeopleSoft Enterprise Performance Management Data Warehouse

Planning and Budgeting is delivered with the PeopleSoft Enterprise Performance Management (EPM) data warehouse, which is the data repository for all source system, planning, and forecasting budget information that is created by your organization. The EPM data warehouse supports enterprise-wide business analytics and enables easy data migration from PeopleSoft and non-PeopleSoft systems.

The EPM data warehouse stores the historical data used in the planning and budgeting process, as well as the results of the planning and budgeting process.

The EPM data warehouse includes these components:

• Extract, transform, and load (ETL) tool.

• Operational Warehouse Staging (OWS) tables.

• Operational Warehouse Enriched (OWE) tables.

The extract, transform, and load process into the OWS and OWE tables collects data from dissimilar data sources such as PeopleSoft Financial Management system, Supply Chain Management, HRMS, and Customer Relationship Management so that analytical applications like Planning and Budgeting can access and use the data. Moving information from multiple sources onto one common platform lets managers and decision-makers more easily access their data for enrichment, analysis, and reporting.

See Also

Enterprise Performance Management Fundamentals 9.1 PeopleBook

PeopleSoft Pure Internet Architecture

PeopleSoft Pure Internet Architecture lets you access Planning and Budgeting online. Pure Internet Architecture is comprised of the PeopleTools Web Server and the PeopleTools Application Server. The PeopleTools Web Server serves pages to the browser and maintains states. The PeopleTools Application Server sends instructions to the web server and the PeopleSoft EPM database, and also implements the Planning and Budgeting business rules.

PeopleSoft Analytic Calculation Engine

PeopleSoft Analytic Calculation Engine (ACE) is a decision support tool that provides real-time, multidimensional modeling. ACE is embedded in the Planning and Budgeting line item activity for data calculations, and is used in inquiry pages, where you can compare data across scenarios, versions, and time, as well as drag and drop dimensions to customize your analysis.

Use ACE to:

• Perform scenario-based modeling and multidimensional analysis of financial data.

• Generate accurate budget models using formulas to define rules and relationships across several dimensions.

• Implement multiuser, role-based security.

• Use interactive reporting to view, filter, group, and sort data to gain more insight into your enterprise.

Note. You can use ACE to analyze line item, position, and asset activity data via analysis reports, but ACE is not used as part of data entry into your position and asset activities.

See PeopleTools PeopleBook: PeopleSoft Analytic Calculation Engine.

PeopleSoft HRMS and Financial Management Databases

The delivered ETL tool lets you import data from the PeopleSoft Human Resource Management System (HRMS) and PeopleSoft Financial Management System (FMS) databases into PeopleSoft EPM to help you prepare the budget and exchange data between Planning and Budgeting and these PeopleSoft applications:

• Asset Management

• General Ledger

• HRMS

• Projects

This diagram illustrates how Planning and Budgeting integrates with other PeopleSoft databases using ETL:

Planning and Budgeting integration points

You can also use data from third-party applications. Supplemental information about third-party application integrations is located on My Oracle Support.

Reporting and Analysis

To help you assess and adjust your planning and budgeting process, a delivered reporting and analysis feature enables you to view query results online when you use any of these pages:

• Variance Analysis to compare scenarios for an activity and planning center in the planning model.

• Version Analysis to compare budget versions for an activity, scenario, and planning center in the planning model.

• Position Budgeting Analysis to access cost and full-time equivalent data by account, position, job code, and employee.

• Asset Analysis to access data about an asset account, capital acquisition plan, capital acquisition sequence, or asset catalog item.

These query results appear online in an ACE grid. Use the web-based drag-and-drop feature to refine your analysis, preview results, and modify the report format.

See Also

Reporting and Analyzing Results

Rule-Based Methodology

Planning and Budgeting requires a general rule, formula, or method that specifies how to calculate each value in an activity. This rule, formula, or method provides a highly configurable framework in which to build formulas—from easy to complex. Each organization is unique, so the system allows you to configure formulas for your industry and business.

This flexible formula framework is presented in a wizard format that includes built-in validations. The formula framework spans planning centers, scenarios, and user-defined activities, defining relationships within the planning model.

Activities

Planning and Budgeting activities allow planning administrators and budgeting analysts to add and define each activity with the dimensionality that best fits their unique planning and budgeting needs. Activities may either be set up along functional areas or configured along lines of business such as geography or product line. Each activity can have unique or shared dimensions, and unique or shared planning and budgeting centers that support their own workflow and security. This flexibility extends to configurable review and approval processes for each activity.

The three types of activities are:

• Line item activity.

  Used to view and change plan or budget amounts in a line item format.

• Position activity.

  Used to add, modify, or view position data details, including salary, earnings, benefits, and employer-paid tax costs associated with positions.

• Asset activity.

  Used to create, modify, or view assets and depreciation costs associated with capital acquisition plans.

The position activity and asset activity represent a greater level of detail than a line item; therefore, they are typically summarized into a line item activity defined by activity relationships.

Role-Based Processing

For each organization, the planning process may be an iterative process and it may involve many people at different levels of the organization. The types of activities performed may depend on the individual job responsibilities associated with the specific role. PeopleSoft Planning and Budgeting enables you to set up security based on user roles. Users can be assigned multiple roles that describe their part in the workflow. Planning and Budgeting uses these six roles:

• A coordinator manages the overall budgeting process, including setup, distribution, and consolidation of the budget; determines parameters and guidelines; and builds the planning model.

• An analyst is responsible for a planning center, typically a unit, department, or division, within an organization.

  This user may break a plan or budget into smaller units for distribution to lower levels.

• A preparer, who is at the lowest level of preparation for a planning center, provides line item, asset, and position amounts and justifications to higher level users.

  This user does not usually perform allocations or aggregated analysis.

• A casual preparer provides the same services as the preparer role when access is granted.

  The system does not allow casual preparers to define their own private views for line item activities.

• A system administrator defines user security and access.

• A reviewer is responsible for reviewing and approving submitted budgets or plans for a planning center.

  In many cases, an analyst and a reviewer may be the same person.

PeopleSoft Planning and Budgeting uses standard security definitions from PeopleTools and the PeopleSoft EPM Warehouses to provide the correct access to various areas of the application, depending on your role in the organization.

This diagram illustrates how these roles interact within the budgeting process:

Roles in the budgeting process

See Also

Setting Up Security and Roles

Workflow

Workflow enables you to control and monitor the planning and budgeting review and approval process. You define workflow relationships for activities and use email to notify team members when milestone events occur during the preparation process, such as submit and reject. Trees are used to establish a routing hierarchy among the people notified.

Using workflow, you assign each user a role in the approval hierarchy, defining his or her planning centers, actions, and notifications. You can notify users when an action is required, such as entering or reviewing a budget. You communicate overall status through emails, alerts, and workspaces.

Memory Limitations and Data Considerations

Planning and Budgeting uses the integrated PeopleTools Analytic Calculation Engine (ACE), which is included in PeopleTools release 8.46 and higher. ACE functions primarily as the multi-dimensional calculation engine for line item type activities, including flexible formula methods. ACE is also used to display line item data in data entry views as well as read-only analysis views, such as variance analysis.

Planning and Budgeting customers with large amounts of data can encounter memory limitations when PeopleTools runs as a 32-bit process and as a result certain Planning and Budgeting processes and/or data views fail to complete or successfully load into pages that contain line item data. This is due to the use of ACE to create Planning and Budgeting models.

Note. Position budgeting and asset detail activities are written using PeopleCode and are not dependent on ACE.

ACE is an in-memory model. Each activity-scenario combination in EPM Planning and Budgeting creates an underlying ACE model. ACE loads all the necessary data to complete a process. User security is respected and the system loads only the appropriate data based on a user's access. For instance, a data entry view for a preparer will typically require much less in-memory data than for a coordinator role.

Certain processes and data views fail to complete when the PeopleTools process runs out of available addressable memory. PeopleTools releases support multiple operating systems and operating system versions. Depending on the PeopleTools release, PeopleTools will run as a 32-bit process or as a 64-bit process. Even if an operating system version is 64-bit, PeopleTools may run only as a 32-bit process on that version.

Furthermore, each operating system has its own unique methods for handling and allocating addressable memory. As a result, each operating system has significantly different limits for handling data volumes on 32-bit operating systems.

ACE Index Limit

When loading the multi dimension data in memory, ACE doesn't store the index array for the multi dimension data; instead it uses an algorithm to map the index array to a unique integer index that will be used as the index to store the cube cell data values in memory. This index is defined as a PSI64 type (the largest integer currently supported by PeopleTools). Since ACE will also need to use one bit of this PSI64 type as the mask for the modify/non-modify flag, the maximum integer number for this index will be 2⁶³ (~9.2e¹⁸). Thus the unique mapping algorithm requires the cross product of the number of the dimension members in the cube to be less than 2⁶³, otherwise the index will overflow and the in memory data storage cannot handle the overage.

When the number of the cross products is over 2⁶³, the potential index overflow problem might cause problems in ACE internal in memory cube storage. There could be different unexpected behaviors depending on whether/how an overflowed index was created and how the system responds/accesses the memory pointed by that index. This depends on which cube cell needs to be indexed (it is possible that all the cube cells that have values and need to be indexed have the index value less than 2⁶³ even though the total cross product of the number of the dimension members are over 2⁶³. You can think of it as to assign the integer for each of the dimension tuples, and that integer can range from 1 to 2⁶³). If that is the case, then the results will be correct. But most likely there could be integer index for cube cells that need to be indexed larger than 2⁶³ if the total cross product of the number of the dimension members are over 2⁶³, and the result could be crashes or some incorrect results.

One common error is the "memory access error", which results in the following error in the message log: "BP_ACT_CALC.Calc.Calc engine abends during line item stage with the message: 'Initiated' or 'Processing' no longer running". Another common error is zero amounts in the analysis report grids.

Impacts to EPM Planning and Budgeting Processes and Data Views

The data volume limitation applies to the following areas, which are generally limited to the coordinator role:

• Staging.

  Each activity-scenario combination represents a single ACE model and is staged individually. If a particular activity-scenario is too large, the addressable memory for the operating system is exceeded and the activity-scenario (ACE model) does not get staged.

• Recalculation.

  A full model recalculation, in application terms, includes ACE model loading, the GetRowCount function and calls, and the ACE cube collection. During recalculation, the internal ACE model routine named GetRowCount has to build many internal structures in memory. If the data volumes in the model are too great, addressable memory can be exceeded.

• Analysis views (especially coordinators that have access to all data).

  When selecting all planning centers, or a large group of planning centers for a particular activity-scenario, the amount of data loaded may exceed the addressable memory for the operating system if the volume is too high.

• Data entry views (especially coordinators that have access to all data).

  When selecting all planning centers or a large group of planning centers for a particular activity-scenario, the amount of data loaded may exceed the addressable memory for the operating system if the volume is too high.

Data Volumes

The primary driver is the number of rows stored for a given activity-scenario (the ACE model). The number of rows is based on the number of dimensions and the number of members for each dimension, including budget periods. A separate row is created for each budget period (for example, Jan, Feb, Mar).

There are no known sizing issues that are caused by the raw number of planning centers.

The maximum number of rows that we were able to process for a single activity-scenario/ACE model varies by operating system, ranging between 380,000 and 800,000 when running as a 32-bit process. The wide variation by operating system is determined by the algorithms and number of segments used for managing addressable memory on that particular operating system. These limits do not apply to environments where PeopleTools runs as a 64-bit process.

See Operating System Considerations.

Estimating Data Volumes

The following factors determine the overall size, and therefore memory requirements, for a given activity-scenario:

• Number of dimensions and the number of members in a dimension.

• Planning time horizon, multiple years.

• Number of budget periods in a scenario (days, weeks, months, quarters, annual).

• Number of comparison scenarios.

• Number of FLEX formulas, especially where dimension selection is set to all members.

• Number of rows in data view.

The number of rows of data for a given ACE model is a function of the number of dimensions, the number of dimension members, and the sparsity factor of the data. Sparsity refers to the density of the dimension intersections. The equation for calculating data volume is:

Data Volume = Total Possible Rows × Sparsity Factor

To calculate the approximate value for the number of total possible rows, compute the cross product of the number of dimension members by multiplying together the count of the number of members in each dimension, then multiply that amount by the number of periods, the number of currencies (use 1 if you are not using multiple currencies), and the number of budget centers. If department is the budget center, for example, then you will use department twice in the calculation (once in the count of dimension members, and once in the number of budget centers). The total should be less than 2⁶³ or 9.2e¹⁸.

The unknown factor in the equation is determining how sparsely populated the data will be for any given activity-scenario. If a 99% sparsity rate is assumed, this means that of all the possible data combinations, 99% of those combinations have a null value and they are not used. Only the physical rows of data are loaded into the ACE model. ACE has a feature called "explicit tuples" which handles the sparsity issue in terms of the size of the database. Having a very sparse model isn't an issue for ACE, unless the cross product of the number of dimension members (the total possible rows) exceeds the index limit of 2⁶³.

See ACE Index Limit.

Estimating data volumes using surrogate data is a practical approach when estimating size. In some cases a more straightforward approach is to look at the number of physical rows used for last year's actuals or a prior budget. Estimating based on historical data assumes the same dimensionality, number of dimension members including number of time periods, and so on. For instance, if the actuals are stated as annual amount and the budget model calls for 12 months, the number of rows in the actuals would need to be multiplied by a factor of 12, since data would presumably be stored in all 12 budget time periods. Similarly, you would multiply the number of rows in the actuals by the number of comparison scenarios, assuming each comparison scenario has the same combination of dimension members as the actuals.

On the other hand, if actual data did not have a product dimension and the budget has 58 products in a product dimension, not all data will be budgeted to all 58 products. You would not multiply the actual data rows by a factor of 58 to estimate the number of budget rows. Unlike time periods, the product dimension is sparse in relation to all the other dimensions. A sparsity assumption would need to be applied (for example, 58 x (1-95%)).

Using fewer dimensions in your budget model than exist in your source system also affects this calculation. If your actual data includes a dimension for region, but the region dimension is not included in your budget model, then those rows will be aggregated away, and you end up with fewer rows in Planning and Budgeting than exist in your actuals ledger.

Implementation Design Options for Reducing Data Volume

The best solution for the memory limit issue is to implement Planning and Budgeting with PeopleTools running as a 64-bit process. However, the following design considerations should be taken into account as such an environment may not be available. In addition, an efficiently designed model will generally have better performance than a larger, less efficient model. This is the only solution for the index limit issue. The following list outlines implementation approaches to reduce data volumes:

• Use multiple activities.

  • Break up a Planning and Budgeting model into multiple activities. Since each ACE model represents a scenario-activity combination, more combinations have fewer rows of data than a single large activity.

  • Data that is distributed in multiple activities can be integrated into parent activities.

  • A collection of smaller activities leverages the Planning and Budgeting data model and distributed architecture, and helps to scale the model.

• Use fewer dimensions.

  • Consider concatenating some dimensions into valid dimension combinations (for example, operating unit with department for a planning center, or concatenate customer with channel or product or location).

  • Remove dimensions which are actually attributes and don't generate additional combinations. If those dimensions are needed only for exporting to General Ledger, they can be added later during the export process (this does, however, require some customization).

• Use fewer dimension members.

  • Reduce the number of accounts.

    For example, if only one department has a corporate jet consider using a common travel account instead.

  • Reduce the number of time periods.

    Weekly planning generates more rows of data than monthly planning.

    Multi-year planning for a single scenario generates more data than a single or partial year

  • Use a single currency.

    Single currency budgeting is less sparse than multiple currency models.

• Include fewer comparison scenarios.

  Reducing the number of comparison scenarios brings less data into memory during staging.

• Create efficient FLEX formulas.

  To maximize performance, use explicit member selection or 'same as target' rather than 'all members' when possible.

Following these implementation design recommendations will help resolve memory limits and index limits, and improve performance.

Operating System Considerations

Running the application server as a 64-bit process should resolve memory limitation issues, but not the index limit issue. As stated previously, this may not help improve performance, but will keep the application from failing due to lack of addressable memory. 64-bit processes have a vastly greater amount of addressable memory available compared to 32-bit processes (2⁶⁴ versus 2³²).

When running as a 32-bit process, in the calculation portion of the staging process at certain levels of data and complexity, we have seen the process requests memory, but no more addressable memory is available; the process dies. When running the same process on the same database as a PeopleTools 8.46 64-bit process, the process runs to completion.