Understanding PeopleSoft Enterprise Performance Management Foundation

This chapter provides an overview of Enterprise Performance Management (EPM) and EPM Foundation, and discusses:

• EPM Architecture.

• Extract, Transform, and Load (ETL) in EPM Foundation.

• Operational Warehouse - Staging (OWS).

• Operational Warehouse - Enriched (OWE).

• Multidimensional Warehouse (MDW).

• EPM Foundation Tools.

• PeopleSoft EPM Analytical Applications.

• PeopleSoft Performance Management Warehouse and reporting.

• EPM Implementation.

Overview

PeopleSoft EPM is a comprehensive, integrated analytic business solution designed to increase the efficiency of your organization. PeopleSoft EPM helps your organization achieve operational excellence by providing insight into the information you need to drive predictability, accountability, and manage operational risk. EPM enables you to produce detailed activity analyses and resource plans, understand the cause-and-effect relationship between cost and behavior, organize strategic thinking and performance measurement, use continuous, collaborative forecasting to manage the plan and budget in real-time, and clearly communicate strategy and success measures.

EPM is supported by robust data warehouses, related data models, and EPM Foundation infrastructure, metadata and tools. EPM Foundation provides all the necessary tools to gather and manage data from PeopleSoft, legacy, and external data sources, enrich that data, and store it in an intuitive analytic context for you to analyze in a variety of ways and at a variety of levels. EPM Foundation enables you to deliver a single, accurate view of information across your organization.

PeopleSoft EPM Architecture

PeopleSoft Analytical Applications and the Performance Management Warehouse (which includes all functional warehouses), are built on a foundation of specialized data warehouses, target warehouse tables, ETL jobs, metadata, tools, and processes that enable complex analysis and reporting of your data. Each component of the foundation performs a specialized function, which supports the applications and/or the Performance Management Warehouse.

Target warehouse tables provide a way to consolidate and store your source data. EPM target warehouse tables reside in two high-level warehouse structures: the Operational Warehouse (OW) and the Multidimensional Warehouse (MDW). The Operational Warehouse can be further divided into the Operational Warehouse - Staging (OWS) and the Operational Warehouse - Enriched (OWE). Each warehouse structure has its own set of specialized target warehouse tables that are unique to that structure. For example, the Operational Warehouse - Enriched (OWE) structure stores enriched data that is arranged in a normalized format to promote complex analytics. And the Multidimensional Warehouse (MDW) structure stores data that is arranged in a denormalized format for enhanced reporting capabilities.

EPM architecture

The dual warehouse architecture helps to:

• Isolate and channel specific source data to the appropriate warehouse structure for individual enrichment and modeling.

  PeopleSoft provides extract, transform, and load (ETL) jobs to extract information contained in your source systems, load it into the Operational Warehouse - Staging (OWS) structure, and migrate that data to the Operational Warehouse - Enriched (OWE) and the Multidimensional Warehouse (MDW) structures. And because the warehouse structures are logically separated, the ETL jobs can isolate and channel specific source data to the OWE or the MDW.

• Facilitate specialized, or tailored, data enrichment for your source data.

  PeopleSoft provides EPM Foundation tools and processes (a set of specialized tools, processes, and metadata) that prepare and enrich your source data for the analytical applications and the functional warehouses.

The target warehouse tables, ETL jobs, and EPM Foundation tools work together to provide the underlying infrastructure on which the analytical applications and functional warehouses are built. Detailed information regarding the OWS, OWE, MDW, and EPM Foundation Tools can be found in this chapter.

See Also

Operational Warehouse - Staging (OWS)

Multidimensional Warehouse (MDW)

EPM Foundation Tools

Extract, Transform, and Load (ETL) in EPM Foundation

PeopleSoft has an original equipment manufacturer (OEM) agreement with Ascential to supply extract, transform, and load (ETL) technology that supports source data acquisition and data movement within EPM Foundation. The ETL tool, Ascential DataStage, is delivered with EPM.

PeopleSoft uses Ascential DataStage to deliver prepackaged ETL jobs that extract information contained in PeopleSoft source systems, load it into the Operational Warehouse - Staging (OWS), and migrate that data to the Operational Warehouse - Enriched (OWE) and the Multidimensional Warehouse (MDW). But ETL jobs do more than migrate data; they also identify data for extraction and ensure the consistency and validity of your data. Because the ETL jobs are so versatile, separate tools and engines that extract, stage, and move data are not necessary.

The following diagram demonstrates the ETL process in EPM Foundation.

ETL process in EPM

As depicted in the diagram, source transaction data is extracted into OWS tables and migrated across warehouse layers using the aforementioned ETL jobs. You can also use Ascential DataStage to build custom jobs for mapping your data into EPM Foundation.

Detailed information regarding the ETL process can be found in the ETL section of this PeopleBook.

See Also

Preparing to Load Data Into EPM

Operational Warehouse - Staging (OWS)

The OWS structure is one of two subcomponents that comprise the Operational Warehouse. The OWS acts as an entry-point for your source transaction data into EPM Foundation and can house data from one or more of your PeopleSoft, legacy, or external source systems. The main function of the OWS is to provide a platform to offload, consolidate, and stage your source transaction data in preparation for enrichment.

Operational Warehouse - Staging (OWS)

Source data is extracted into the OWS using prepackaged ETL jobs and loaded into target staging tables. No transformations are performed on your source data during this process and the system maintains the same source-level of granularity for your data. Source tables are extracted into the OWS, including all logically related tables, to ensure your source system data is semantically complete. For example, a table extracted into the OWS may have an associated related language table in the source system. The related language data from the associated table is also extracted into the OWS to maintain completeness and data integrity. Data stored in the OWS is used as input for the Operational Warehouse - Enriched (OWE) and the Multidimensional Warehouse (MDW) structures.

Note. The OWS does not contain reporting tables nor prepackaged reports built on the core OWS target tables.

OWS Core Target Tables

OWS core target tables contain data migrated from PeopleSoft Enterprise and Enterprise One source systems. OWS target tables are permanent tables (as opposed to temporary tables), and can store historical data. However, it is not the recommended location for historical data as the tables can be purged from time to time depending on your operational needs. The structure of the OWS target tables match the structure of the source transaction tables with the addition of a source system identification column (SRC_SYS_ID) , which enables you to track the origin of your data.

Note. Certain OWS target tables have specific non-key columns that can be “activated” as key columns if your business requirements necessitate it.

See PeopleSoft Enterprise Planning and Budgeting 9.0 PeopleBook

Sample OWS Target Table

The following is a sample OWS target table page shown in Application Designer.

OWS target table - ABS_CLASS_TBL

OWS Target Table Naming Convention

OWS target tables use the following naming conventions:

• S_[source table name]

• [source table name]

OWS Error Tables

The OWS contains error tables used in the data validation process. The data validation process uses ETL jobs to verify the integrity and completeness of the data entering OWE and MDW target tables. The validation process can perform dimension key validation (for example, verifying that customer ID fact value has a corresponding customer ID dimension value) and general key validation (for example, verifying the pre-fact customer ID in the OWS table has a corresponding customer ID in the OWE or MDW table), as well as ensure source business unit and setID are properly mapped to EPM values and source codes are properly mapped to EPM code values.

Data failing the validation process are sent to OWS error tables. It is important to note that the OWS error tables have a different structure than the error tables in the OWE and perform a very different function. The OWS error table mirrors the key structure and other columns of its corresponding data table and has additional fields to facilitate troubleshooting. The following OWS error table columns represent some of the columns provided for troubleshooting:

• LOAD_OWS_SBR: The values for these columns are copied from the failing data row. The reason for copying values from the failed data row is that it provides vital load information such as batchID and load timestamp for the data row.

• Target Table: This column lists the target table for the job.

• Failed data source table and column name: The source table and column from which the failing data originated. Knowing the name of the failed source data table is especially useful when the job loading the failed data contains a multi-source-table join.

• Failed Data Value: The actual value that failed validation.

• Lookup table & column name: The table and column against which the failed lookup was performed.

Detailed information regarding the data validation process can be found in the ETL section of this PeopleBook.

See Understanding Data Validation and Error Handling in the ETL Process.

Sample OWS Error Table

The following is a sample OWS error table page shown in Application Designer.

OWS error table - E_ABS_CLASS_TBL

OWS Error Table Naming Convention

OWS error tables use the following naming conventions:

• E_[OWS table name]

• ES_[OWS table name]

Operational Warehouse - Enriched (OWE)

The OWE structure is the second of two subcomponents that comprise the Operational Warehouse. The OWE stores enriched data that is arranged in a normalized format and mapped to warehouse business units (WBU). Enrichment can entail many transformations to your data, including (but not limited to) conversion to a common currency, common calendar, or a common ledger, or aggregating data to a common warehouse business unit. The PeopleSoft analytical applications use the enriched data in the OWE to perform analysis and reporting.

Operational Warehouse - Enriched (OWE)

Data is extracted into the OWE using prepackaged ETL jobs and loaded into target dimension (D00) and fact (F00) tables. The structure of these tables are quite different from the OWS tables because they are arranged in a normalized format and organized data around warehouse business units. In addition, OWE tables are augmented with subrecords which help facilitate the ETL process and tracking data lineage. OWE tables store data permanently and can maintain history (as opposed to temporary tables which remove data at the end of an ETL job).

Tools and Processes Associated with the OWE

EPM Foundation is delivered with several tools and processes that enable you to enrich and manage the data stored in the OWE. The following are some of the tools and processes used only with the OWE:

• Warehouse business unit setup.

• Performance ledger template setup.

• Detail ledger setup.

• Model and scenario setup.

• Roll-up processing.

• Profit manager.

• EPM object auditing.

• Mass validate processing.

• Mass compile processing.

• Tree utility setup.

• Data manager processing.

• Allocation manager processing.

OWE Dimension (D00) Tables

An OWE dimension table provides additional attributes about a fact for greater flexibility in reporting. Dimensions are derived from operational applications and are cleansed and transformed during data migration. Examples of dimension tables include: product, customer, channel, department, personal data, and accounts. Some of the fields associated with an OWE dimension table are:

• SetID: Key column.

• DIMENSION_ID: Key column.

• EFFDT: This is the same date as the source. If an EFFDT or an alternative date, such as a date time stamp, does not exist, the system creates one and sets it to the date the dimension data is loaded.

• EFF_STATUS.

• KEY Fields from the source table.

• SET CONTROL FIELD. This is BUSINESS_UNIT.

• RELATED LANGUAGE RECORD. This is the same with an extension of _LNG.

Sample OWE Dimension Table

The following is a sample OWE dimension table page shown in Application Designer.

OWE dimension - CUSTOMER_D00

OWE Dimension Table Naming Convention

OWE dimension tables use the following naming convention, [table name]_D00

OWE Fact (F00) Tables

An OWE fact table contains measures (from across the enterprise) for analyzing performance. Some of the fields associated with an OWE fact table are:

• BUSINESS_UNIT: This field enables the fact data to be shared across different dimensions, as they are based on SetIDs.

• FACT KEY.

• ASOF_DT: This is for non-cumulative facts (for example, account balance).

• PF_TRANS_DT: This is for cumulative facts (for example, billing transactions).

• All KEY Fields: These are required for uniqueness.

• DEFAULT VALUES include:

  • BUSINESS_UNIT: This will have a default table set to OPR_DEF_TBL_FS and a default field set to BUSINESS_UNIT.

  • EFFDT: This will have a default set to %DATE.

  • EFF_STATUS: This will have a default set to A.

  • TRANSLATE VALUES: These values, if any exist, must be set to the XLATTABLE.

• PF_TRANS_DT: This is set to the source record's transaction date. In addition, the source transaction date field is included in the data warehouse fact table.

Sample OWE Fact Table

The following is a sample OWE fact table page shown in Application Designer.

OWE fact - ACCT_REC_F00

OWE Fact Table Naming Convention

OWE fact tables use the following naming convention, [table name]_F00

OWE Temporary Tables

OWE temporary tables support parallel processing. EPM is delivered with three sets of temporary tables. You can define additional sets of tables when needed.

The project EPM_TEMP_TABLES contains one instance of every temporary table, enabling you to create new temporary table suites, if necessary. A temporary table layout and key structure differs from its respective fact or dimension data warehouse table in that the organizational unit (setID or business unit) and the effective date are not keys.

Note. If you must create more temporary tables than the ones delivered with PeopleSoft EPM, see the delivered project, EPM_TEMP_TABLES. It contains one instance of every temporary table, enabling you to create new temporary table suites, if necessary.

See Creating Additional Instances of Temporary Tables for Record Suites.

OWE Temporary Table Naming Convention

OWE temporary tables use the following naming convention, [table name]_T

Specialized Reporting Tables

The OWE features tables that have been designed specifically to enhance reporting capabilities. Those tables are the performance ledger table (PF_LEDGER_F00), performance journal table (PF_JRNL_F00), and the performance statistics table (PF_STAT_F00). Creating specialized tables in this manner enables you to move away from storing all of your accounting data in your general ledger to make your general ledger perform as it should—as a method for compliance reporting only.

The performance journal and performance ledger tables are described in more detail later in this PeopleBook.

Performance Ledger Table

The performance ledger table (PF_LEDGER_F00) is a central fact table within EPM. The performance ledger table is an accumulation of monetary amount facts over a period of time. The primary function of the performance ledger table is to support PeopleSoft EPM reporting. The PF_LEDGER_F00 is the source for one of the data marts.

Note. The performance ledger table should not be confused with a general ledger from an online transaction processing (OLTP) system. The performance ledger contains all information mapped from a general ledger and enriched through one (or more) of the PeopleSoft EPM engines.

Information that has been processed through an PeopleSoft EPM engine, for instance the ABM engine or Data Manager, is stored in a temporary performance journal staging table (PF_JRNL_T).

The PF Edit engine enables you to verify the data in the temporary journal table and moves valid data to the final table, the PF_JRNL_F00. Errors are placed in the PF_JRNL_E00, the error table for the journal table. The PF Post takes the detailed information from the performance journal table, aggregates it to the desired level of summarization and posts it to the PF_LEDGER_F00 for reporting.

PeopleSoft EPM reporting tools support multidimensional analysis based primarily on profitability dimensions such as customer, product, and channel. You can use one, two, or more of these dimensions within your models, or configure the application to add more dimensions, or change the existing ones. No matter which dimensions you select, however, you need to consider how to populate the performance ledger table with meaningful multidimensional data.

Performance Journal Table

The performance journal table (PF_JRNL_F00):

• Contains data that is not yet summarized.

• Is a fact table, or multiple fact tables, within EPM.

• Is a collection of batches of amount facts staged for validation and posting to the performance ledger table.

• Supports drill down from reports produced against the performance ledger table.

The PF Edit engines moves data to the performance journal fact table. The PF Post process accumulates valid transactions from the performance journal table, and inserts summarized rows into the performance ledger. There is a “many to one” relationship between the performance journal and the performance ledger tables.

Performance Statistics Table

The performance statistics table (PF_STAT_F00) is similar to the performance ledger table in its layout, except that it is used to support different decimal precision for statistical rather than monetary values. For example, the performance ledger can store monetary amounts with a decimal precision of two, while the performance statistics table can store statistical values with a decimal precision of eight.

OWE Error Tables (for Profit Manager only)

The OWE contains error tables used to identify flawed data in certain OWE target tables. There are a small number of delivered OWE error tables and they are used only for Profit Manager. Profit Manager uses specific business rules to validate and format data in its related OWE target tables. If the business rules are not met, then the flawed records are written to an OWE error table and a message describing the error is written to a detail error message table (TSE table). If your load results in errors, you can use PF Modification to correct the errors. You can correct the errors using the PeopleSoft Application Designer and then migrate the corrected tables to the target. The following OWE error tables are delivered:

• BP_LED_BUDG_E00

• BP_LED_E00

• BP_LED_KK_E00

• BP_LED_PROJ_E00

• GC_JRNL_MGT_E00

• LEDGER_E00

• PF_JRNL_E00

See Setting Up and Using Profit Manager.

Sample OWE Error Table

The following is a sample OWE error table page shown in Application Designer.

OWE error table - BP_LED_E00

OWE Error Table Naming Convention

OWE error tables use the following naming convention, [table name]_E00

Multidimensional Warehouse (MDW)

The Multidimensional Warehouse is the third data structure in EPM.

Multidimensional Warehouse

The MDW stores dimensionalized data that is grouped into one or more business processes, better known as a dimensional schema, used for business intelligence and ad hoc reporting. The data is stored in a star schema (a fact table associated with a series of dimension tables) and generally contains data loaded from the OWS.

The star schema arrangement depends entirely on primary key and foreign key relationships. A primary key is a column (or columns) in a dimension table whose values uniquely identify each row in the table. Primary keys enforce entity integrity by uniquely identifying entity instances. A foreign key is a column or columns in a fact table whose values match the primary key values of a given dimension table. This way references can be made between a fact and dimension table. Foreign keys enforce referential integrity by completing an association between two entities.

Note. MDW dimensions use a surrogate key, a unique key generated from production keys by the ETL process. The surrogate key is not derived from any data in the EPM database and acts as the primary key in a MDW dimension. See the next section for more information on surrogate keys in the MDW.

The following graphic provides an example of a star schema and its primary and foreign key relationships:

Dimensional Model Example

Although data loaded into the MDW is primarily derived from the OWS, there are exceptions to this rule. Profitability and Global Consolidations data for the Financials Warehouse is loaded into the MDW from the OWE.

External survey data for the HCM Warehouse is loaded into the MDW from the OWE.

Online Marketing data is loaded into the MDW directly from the source system, and bypasses the Operational Warehouse entirely.

Surrogate Key Generation

Surrogate keys provide a means of defining unique keys whose values, with the exception of the Time and Calendar dimensions, are anonymous—that is, the value of a surrogate key has no significance to the application using it and is strictly an artificial value. The system uses surrogate keys specifically as a means of joining structures. To speed up query access, the MDW resolves PeopleSoft-specific programming constructs, such as SetIDs and effective dates and replaces them with surrogate IDs as key columns.

Surrogate keys are generated from production keys by an extract, transform, and load (ETL) mapping process and have no relationship to the business or production key. Surrogate keys are present in dimension tables as the primary key and in fact tables as foreign keys to dimensions. However, the dimension record retains the business key as an alternate-key attribute. Surrogate keys are four-byte integers and their size does not change even when production key changes in size.

Although surrogate keys usually do not have any “intelligence,” that is, their value has no meaning, in certain situations, such as the Gregorian Calendar and Time dimensions, intelligent surrogate keys are used. These intelligent keys enable the ETL process to run more quickly by providing the option of avoiding a lookup on corresponding dimensions.

Surrogate keys can be unique within a database or unique within each dimension table. You configure this feature by the value you give to the environment parameter SID_UNIQUENESS. Surrogate key fields usually have the suffix _SID (Surrogate ID).

Surrogate Key Benefits

Surrogate keys provide benefits such as:

• The ability to easily and structurally conform a dimension when being sourced from multiple systems.

• Disassociation from operational system changes.

  Because surrogate key generation is controlled by the warehouse, it is not influenced by operational system changes.

• The ability to handle unspecified or missing key values.

• A graceful mechanism to handle changes in history.

  Multiple versions of a dimension can be maintained with different surrogate (primary) keys, yet with the same business (identifying) key.

• Performance enhancement of queries, because a surrogate key is a single column numeric key, thus the joins using surrogate keys are faster than ones using multi-column business keys.

Surrogate Keys and the ETL Process

You do not have to take any action to create surrogate keys; they are created automatically during ETL. Surrogate keys are generated during the ETL process within DataStage routines. The DataStage routine retrieves the next surrogate key value and assigns it to the surrogate key that it is currently creating. When the ETL process copies a dimension row from the source system into the MDW, the ETL process performs a lookup on the dimension table. If the dimension row (with same business keys) does not exist in the dimension table, the process inserts a row with a new surrogate key value. If the dimension row already exists in the dimension table, the process updates the existing row with the incoming row value. When the ETL process copies a fact row from the source system into the MDW, for each dimension key in the fact row, the system performs a lookup on the dimension table and retrieves the corresponding surrogate key value. This surrogate key is the foreign key value in the fact row in the MDW. If the system does not locate a dimension value in the fact row in the dimension table, that is a data exception and an error results.

Audit Fields

Audit fields track extract, transform, and load (ETL) loading information, such as when the row was loaded or last modified or the batch in which the row was loaded. This information is included in a subrecord. Although all OWS and MDW tables have a subrecord, only OWE tables that are loaded from the OWS using ETL have subrecords. OWE tables that are loaded by enrichment engines using other OWE tables typically do not have subrecords. The subrecord added to MDW tables is called LOAD_MDW_SBR. Subrecords are always added at the end of a record; no fields exist after this subrecord in any table.

The following example shows a typical LOAD_MDW_SBR record.

LOAD_MDW_SBR record example

Data Aggregation

Tables in the MDW contain source data at the same granularity as the source system. Required data aggregation is carried out at run time by the business intelligence tool. This allows for better control of aggregation strategies by the business intelligence tool, because aggregation requirements vary from customer to customer.

MDW Dimension Tables

Dimension tables contain surrogate keys as the primary key and are a single column key containing only the surrogate key column. Surrogate keys usually have _SID (surrogate ID) appended to the field name. Dimension tables retain source system business key fields as non-key attribute columns in the dimension table. However, these are not used for joins with fact tables. For example, in the Customer dimension, the original business key field CUST_ID is retained, if it exists in the source table, but is no longer included in the key. The SetID is also retained, if it exists in the source table, as a nonkey attribute; the value contained in the SetID is the same as in the source system.

If a dimension is SetID-based, the MDW table contains the source SetID and the performance (PF) SetID, which is named SETID.

If a dimension contains a description text, a related language table is often defined for this dimension. The ETL process populates this table if a customer requires multilanguage processing. The key for this table is the surrogate key ID, plus the language code field, LANGUAGE_CD, which contains the code for the additional language.

See Setting Up Multilanguage Processing and Running the Language Swap Utility (Optional).

Conformed Dimensions

Conformed dimensions are either exactly the same—including key structure—or an exact subset of another dimension, That is, conformed dimensions are structurally identical every place in which they are used. When using a conformed dimension, the system consistently interprets attributes; hence rollups across data marts are possible and consistent. When a warehouse is provided data from multiple sources, a conformed dimension is typically (but not always) built from multiple source structures.

The steps in conforming a dimension are:

1. Conforming structures:

   In a warehouse environment, many dimensions may come from multiple sources. When dimensions are structurally conformed, the warehouse model combines unique attributes from multiple sources to produce a single definition in the warehouse that includes all of the important associated attributes. The MDW contains structurally conformed dimensions with important attributes from all functional areas. Thus, there is a single model for entities such as customer, product, and department, even though multiple source systems such as HCM, CRM, Financials, and EnterpriseOne may define these entities individually.

2. Cleansing and removing duplicated data:

   You can choose to have a data cleansing process as part of the warehouse loading process. For example, the process can take multiple definitions of a value, such as a specific customer, that exist in multiple systems and create a single definition in the MDW. Since the requirements of cleansing and deduping vary from customer to customer, PeopleSoft does not deliver a prepacked data cleansing solution.

The following is a sample MDW conformed dimension shown in Application Designer.

EPM conformed dimension

Shared Dimensions

Dimensions such as Customer, Department, and Item are shared between functional areas or marts within a functional area. To accomplish this, shared dimensions must be consistent in their view of the data. That is, shared dimensions must be identical in structure and content.

In creating shared dimensions, the system has combined the components from various functional warehouses into one dimension. Although a shared dimension has attributes from various functional warehouses and any functional warehouse can use this dimension, one warehouse is the owner of each dimension (for example, in the case of the Customer dimension, CRM is the owner).

The following is a sample MDW shared dimension shown in Application Designer.

EPM shared dimension

For a list of delivered shared dimensions see the PDF file that is published on CD-ROM with your documentation.

MDW Dimension Table Naming Convention

MDW dimension tables use the following naming convention: D_[table name].

MDW Fact Tables

Fact tables foreign common key fields to dimensions. Dimension tables have a surrogate ID column that is the primary key of that dimension. A fact table may use these dimension surrogate IDs as foreign keys to the dimension table. In the dimensional model example graphic presented previously, the Sales fact table contains six foreign keys, each one matching a dimension surrounding the fact table.

MDW Fact Table Naming Convention

MDW fact tables use the following naming convention: F_[table name].

EPM Foundation Tools

EPM Foundation is delivered with EPM Foundation tools. These set of tools enable you to enrich, audit, and manage the rich content included with EPM Foundation with a high degree of automation. For example, the Clone Metadata tool enables you to quickly and easily create a duplicate copy of your existing metadata. EPM Foundation tools can be used with content included in the Operational Warehouse and the Multidimensional Warehouse.

EPM Foundation Tools

The following sections provide additional details about EPM Foundation Tools.

Setup Tools

Implementing EPM Foundation requires that you specify parameters within the warehouse that reflect your organization's basic business processes and parameters. For example, you must define parameters for unit of measure, country, and accounting calenders in EPM Foundation.

EPM Foundation delivers several setup tools which enable you to quickly and easily setup basic information in the warehouse including unit of measure, multiple language and currency, and operator defaults.

See Setting Up EPM Foundation.

Security Tools

EPM security enables you to set up data access at a variety of entry points and control access to meet your business needs, right down to an individual field. Security tools enable you to:

• Use application security to control access to applications, menus, and objects. You can specify which applications are available to a group of users, which menus and EPM objects they can access.

• Use row-level security, for example, to implement dimension-level access to particular products, customers, or key performance metrics. This ensures that highly sensitive data is protected.

You can also set up a specific security for the Ascential ETL tool.

See Securing EPM.

Data Storage and Classification Tools

Implementing EPM Foundation involves configuring the system's structures to how your business operates. You can share common tables across reporting and analytic applications to minimize redundant data and system maintenance tasks.

Record metadata, for example, defines the first level of EPM Foundation metadata. It is used to identify and classify the tables that constitute the EPM Foundation data model. The record metadata identifies EPM tables as fact tables, fact reference tables, dimension tables, dimension reference tables, or transaction-dated tables. Each table is also classified to a specific data layer: the OWE or the MDW.

Tree manager provides an intuitive way to create, view, and maintain hierarchical definitions. An easy to understand user interface facilitates the creation and maintenance of trees. Tree mover enables you to moved PeopleSoft trees between different PeopleSoft application databases.

See Setting Up EPM Foundation.

See Setting Up and Working with EPM Foundation Metadata.

Performance Management Related Tools

EPM Foundation utilizes shared components that provide functionality key to supporting high-volume analytic applications:

• Reusable filters and constraints stored in the metadata enable you to define sets of rules that can be shared across applications.

• Jobstreams streamline analytic processes and enable applications to run concurrently.

See Setting Up and Working with EPM Foundation Metadata.

See Streamlining Processing with Jobstreams.

PeopleSoft EPM Analytical Applications

EPM provides the applications necessary to analyze business situations, model business scenarios, and monitor performance.

EPM Analytical Applications

PeopleSoft analytical applications is comprised of the following individual applications:

• PeopleSoft Enterprise Activity-Based Management

• PeopleSoft Enterprise Demand Planning

• PeopleSoft Enterprise Financials Services Industry

• PeopleSoft Enterprise Funds Transfer Pricing

• PeopleSoft Enterprise Global Consolidations

• PeopleSoft Enterprise Inventory Policy Planning

• PeopleSoft Enterprise Performance Management Portal Pack

• PeopleSoft Enterprise Planning and Budgeting

• PeopleSoft Enterprise Risk-Weighted Capital

• PeopleSoft Enterprise Sales Incentive Management

• PeopleSoft Enterprise Sales Incentive Management for High Tech and Industrial

• PeopleSoft Enterprise Scorecard

• PeopleSoft Enterprise Supply Planning

• PeopleSoft Enterprise Supplier Rating System

• PeopleSoft Enterprise Workforce Analytics Applications

• PeopleSoft Enterprise Workforce Planning

• PeopleSoft Enterprise Workforce Rewards

For more details on the application or applications you have licensed, please refer to the specific PeopleBook or PeopleBooks.

PeopleSoft Performance Management Warehouse and Reporting

The PeopleSoft Performance Management Warehouse provides a comprehensive reporting and analysis tool set including PS/Query, Crystal Reports, PS n/Vision, and SQR. The Performance Management Warehouse is comprised of the following subject-specific functional warehouses:

• Financials Warehouse

• HRMS Warehouse

• CRM Warehouse

• Supply Chain Warehouse

• Campus Solutions Warehouse

Each functional warehouse is comprised of:

• Predefined ETL jobs for moving data from operational systems to the OWS and MDW.

• Dimensional models for multidimensional reporting and analysis.

Performance Management Warehouse

PeopleSoft's reporting architecture enables you to report when and where it makes the most sense. Reporting tables are built in the MDW to enable offloading of operational reports from your transactional systems. As part of your implementation, you need to consider which operational reports it makes sense to offload to the Performance Management Warehouse.

In addition, the PeopleSoft Performance Management Warehouse open reporting platform enables you to use the delivered PeopleSoft reporting tools or integrate third-party reporting tools. The Enterprise Performance Management Warehouse 9.0 PeopleBook provides more details on the Performance Management Warehouse and each of its functional warehouses.

Implementing EPM

This section discusses the tasks required to install, setup, and implement EPM.

Warning! The task orders presented in this section are not supported by PeopleSoft; they are merely a suggestion and an informal guide to implementing EPM. Some task orders may be interchanged or performed concurrently.

EPM Implementation Overview

EPM implementation requires that you set up EPM infrastructure tables (for example, CURRENCY_CD_TBL, META_REC_TBL) and populate warehouse target tables (staging, D00, F00, DIM, and FACT) with your source transaction data. Most of the implementation tasks to set up and populate these tables are mandatory. However, some tasks relate only to implementing the analytical applications or the functional warehouses. Consequently, if you have only licensed the analytical applications, for example, you need not perform the implementation tasks related to the functional warehouses.

EPM implementation can be broken down into three high level steps:

1. Perform installation tasks.

   The details of these tasks are not documented in this PeopleBook. However, the following sections indicate where the related documentation can be found.

2. Perform EPM Foundation implementation tasks.

   The details of these tasks are documented in this PeopleBook. The following sections indicate where in this book the task-documentation can be found.

3. Perform application and/or functional warehouse implementation tasks, depending on the EPM products you have purchased.

   The details of these tasks are not documented in this PeopleBook. However, the following sections indicate where the related documentation can be found.

EPM Implementation Overview

PeopleSoft Setup Manager can also help you determine which implementation tasks you are required to perform by generating a list of setup tasks based on the features you have licensed. The setup tasks include the components that you must set up, listed in the order in which you must enter data into the component tables, and links to the corresponding PeopleBook documentation.

Note. The structure of this PeopleBook is designed to mirror, as closely as possible, the task order associated with the EPM Foundation implementation tasks. In addition, the structure separates chapters according to whether they relate to all warehouse layers (common), or only the OWS, the OWE, or the MDW.

If you are implementing EPM with the assistance of a PeopleSoft consultant, the consultant can access a searchable, online version of the EPM Foundation PeopleBook in the following location: Planet PeopleSoft, Communities, Products and Technologies, Development, Developer's Portal, PeopleBooks, EPM, 9.0, PeopleSoft EPM Foundation for Analytical Applications and Performance Management Warehouse PeopleBook.

EPM Installation Tasks

The first step in implementing EPM is to install all the necessary software on your designated machine(s). The following table lists all the install tasks, task order, and where documentation related to each install task can be found.

EPM Foundation Implementation Tasks

The bulk of the tasks related to EPM Foundation implementation are related to setting up EPM infrastructure tables and populating warehouse target tables with source transaction data. Some of these tasks include defining currency conversion methodology, setting up warehouse business units, and configuring ETL environmental parameters.

The EPM Foundation implementation tasks can be divided into four broad categories:

• Common infrastructure setups.

• Common ETL setups.

• Operational Warehouse - Enriched (OWE) setups.

• Multidimensional Warehouse (MDW) setups.

Common Infrastructure Setups

The following table lists all the common infrastructure setup tasks, task order, and where documentation related to each implementation task can be found.

Common ETL Setups

The following table lists all the common ETL setup tasks, task order, and where documentation related to each implementation task can be found.

Multidimensional Warehouse Setups

The following table lists all the MDW setup tasks, task order, and where documentation related to each implementation task can be found.

Operational Warehouse - Enriched Setups

The following table lists all the OWE setup tasks, task order, and where documentation related to each implementation task can be found.

Post EPM Foundation Implementation Tasks

After all installation and EPM Foundation implementation tasks are completed, you must perform specific implementation tasks that are only applicable to a certain analytical application or functional warehouse. For example, if you purchased the Global Consolidations analytical application you must define data flows, which is an implementation task specific to that application. Both the applications and functional warehouses have their own implementation tasks that must be completed prior to going live in a production environment.

To view implementation tasks associated with a certain analytical application, see your product-specific PeopleBook (for example, PeopleSoft Enterprise Global Consolidations 9.0 PeopleBook) located on the EPM installation CD. To view implementation tasks associated with a certain functional warehouse, see the PeopleSoft Enterprise Performance Management Warehouse 9.0 PeopleBook. These tasks are not documented in this PeopleBook.