Success with DRM at General Dynamics

Transcription

1 Success with DRM at General Dynamics Edward J. Cody Michelle Pham

2 Introduction

3 General Dynamics Corporation General Dynamics has four main business segments: Aerospace - designs, develops, manufacturers and services a comprehensive offering of advanced business-jet aircraft. Combat Systems - is a global leader in producing, supporting and sustaining land and expeditionary combat systems for the U.S. military and its allies. Marine Systems - designs, builds and supports submarines and a variety of surface ships for the U.S. Navy and commercial customers. Information Systems and Technology - offers a breadth and depth of technology and service capabilities that support a wide range of government and commercial needs, including systems integration expertise; hardware and software products; and engineering, management and support services. Key Statistics: $32.4 B annual revenue (2010) More than 50 years of strategic and innovative work in defense, intelligence, space, and homeland security

4 Business Intelligence Collaborative - Delivering Value & Recognition

5 Agenda Oracle Hyperion DRM Overview Realizing Value from DRM at General Dynamics BIC Approach to DRM for Hyperion Planning Managing Primary Hierarchies & Attributes Managing Alternate Hierarchies & Attributes Additional Validations Formulas Reports Managing Security Questions

6 Overview of Oracle Hyperion DRM

7

8 Agenda Oracle Hyperion DRM Overview Realizing Value from DRM at General Dynamics BIC Approach to DRM for Hyperion Planning Managing Primary Hierarchies & Attributes Managing Alternate Hierarchies & Attributes Additional Validations Formulas Managing Security Questions

9 Realizing Value from DRM at General Dynamics C4 Systems 100+ User Hyperion Planning Deployment Multiple Planning Applications Project structure of ~14,000 members Multiple entities managing projects. Plan entered at various detailed levels with lower level actuals Attribute Dimensions for both Oracle EBS and Plan Members Hierarchy logic required to derive custom attributes. Multiple General Ledgers Electric Boat Company 20+ User Hyperion Planning Deployment 100+ downstream recipients of data No central department master data repository Multiple planning applications and levels of plan detail Department versions needed for historical reporting.

10 Agenda Oracle Hyperion DRM Overview Realizing Value from DRM at General Dynamics BIC Approach to DRM for Hyperion Planning Managing Primary Hierarchies & Validations Managing Alternate Hierarchies & Validations Formulas Managing Security Questions

11 BIC Approach to DRM for Hyperion Planning Source Systems - DRM - Hyperion Planning Primary Usage: Allow management of master data and custom planning members. Source system consolidation in DRM for financial system detail. Plan member creation at various levels and custom properties for attribute assignments and tagging. High-level automated approach to refresh Hyperion Planning (Batch Process): Interface / Flat File extract from source systems of members & attributes (Tag with Source System Attribute) Export current dimensional structures from Hyperion Planning Export DRM Hierarchies into relational database. Validate & fix Parents without children before exporting. Compare Planning and DRM using PL/SQL for deleted members. Run delete member update in Hyperion Planning. Load current attribute dimension structures. Load primary and alternate hierarchies. Execute Planning Refresh to Essbase.

12 Managing Primary & Alternate Hierarchies and Validations Primary Hierarchy & Attribute Hierarchies Contains actual financial system members source from multiple general ledgers. All system and custom properties are set to read-only. Contains custom planning members with properties created by users. Hyperion Planning constraints drive specific DRM Validations Restrict converting members between limb and leaf that exist in Hyperion Planning. Restrict renaming leaf nodes once loaded to Hyperion Planning. Attributes properties can only be assigned to Leaf nodes. Leverage DRM Reports for user error checking. Restrict node deletion if it has a shared node in the Alternate Hierarchy. Limbs without Leaves Validation (Batch Validation) Validations and other Hyperion Planning Best Practices Implemented Custom Sort is allowed in the Primary Hierarchy for the flexibility in displaying the programs to user s business needs. Nodes no longer have to be listed alphabetically. Removal and deletion can only occur on limb nodes without children. Restrict node names from contain spaces (best practice).

13 Managing Alternate Hierarchies & Validations Alternate Hierarchies Setup as an additional hierarchy in DRM Validations implemented to tie it back to the primary hierarchy. Prefix all nodes with Alt_ Enables node uniqueness and flexibility in structuring new and existing nodes without impacting the parentchild relationship in the primary hierarchy. Without using the prefix, the Alternate Hierarchies have to use the Shared node functionality and are dependent completely on the primary structure. Any changes in the primary structure, such as adding or removing a child will be reflected in the alternate hierarchy. Other Validations placed within the Alternate Hierarchies A leaf node must exist in the primary hierarchy. A node may not be deleted when it has a dependent shared node. Only the remove action is allowed. A node that exists in the primary hierarchy may not be added as a limb in the alternate hierarchy.

14 Formulas Hierarchy Node Type is determined through a complex formula Hierarchy Type and Name (Primary, Alternate or Attribute) Data Source Type within the Primary Hierarchy (Source System vs. Plan) Leaf Property Many custom properties are derived formulas Storage Type declaration of Shared or Store property for Hyperion Planning application IF(Equals(String,PropValue(Core.HierName),C4S_Programs),Store,IF(NodeInHier(PropValue(Custom.Node_Name),C4S_Programs),Shar ed,store)) Plan List Attribute categorization of planning members for an attribute dimension in Hyperion Planning based on a specific set of business rules for the members. IF(Equals(String,And(And(ListContains(ListAncestors(),ITR_Programs,[comma]),PropValue(Core.Leaf)),Equals(String,UpperCase(SubStri ng(abbrev(),1,5)),plan_)),true),itr_plan_programs,if(equals(string,and(and(and(and(listcontains(listancestors(),stc_programs,[co mma]),not(listcontains(listancestors(),id_programs,[comma]))),not(listcontains(listancestors(),sa_programs,[comma]))),propvalue(c ore.leaf)),equals(string,uppercase(substring(abbrev(),1,5)),plan_)),true),stc_plan_programs,))

15 Reports & Audit Program Reports Programs & Attributes Reports Shows a list of programs from each Management Group and all their assigned attributes Management Group Hierarchy Reports Shows a list of all programs from each Management Group, top-down structure with level, children and leaf indicators Programs with Missing Attributes Report Shows all programs that don t have an attribute assigned Limbs without Leaves Report Lists out limb nodes that have no children Audit Reports Leverages Interactive Reporting to create formatted administrative reports to track the followings: Users and groups Node access and Security settings Transaction history details Property definition formulas

16 Managing Security Security Users / Groups 3 types of users: Administrators, Financial Planners, and Management Groups Administrators are given the roles of Application Administrator, Data Creator and Data Manager Financial Planners and Management Groups are given the Data Creator role Node Access Groups are set up based on user type and by business group: Admins have full Write access to all hierarchies Financial Planners have full Write access to most hierarchies Management Groups have Write access to a sub-hierarchy that is directly relating to their business group Node Access Group Primary Hierarchy Alternate Hierarchy Attribute Hierarchies Administrators Write All Write All Write All Financial Planners Write All Read Write All Management Groups Write Limited Read Read

17 Thank You!