TAGS

Recent Posts

Archives

What You Need to Know to Design an Oracle EPM Cloud Application: Part 1
Posted on December 10, 2019
Author: Ben Hogle, Performance Architects

When designing a new Oracle EPM Cloud application, there are many factors to take into consideration.  This two-part blog series addresses items necessary to design, build, and ultimately go-live with an Oracle EPM Cloud implementation. This first installment focuses on dimensionality, data, and forms, reports, and dashboards.

Dimensionality

In order to build a new application, the designer/builder must answer several questions about dimensions. Below are some necessary questions to address:

  1. What custom dimensions are needed?
  2. Do you need to rename/reuse any of the predefined dimensions for any reason?
  3. Will you need to use prefixes at the start of dimension member names?
  4. Do you have multiple members in various dimensions that are named similarly or exactly the same? For example, a “4000” account for revenue and also a Department “4000?”
  5. Will there be trial and error on dimensionality? In other words, do you know your dimensions without question, or are you unsure about the differences between dimensions, attributes, or a members of a hierarchy?
  6. Are you going to provide dimensions to build from an existing system or is this a new chart of accounts (COA) build?
  7. Are you willing and able to provide files in a loadable format, or will files need to be manipulated from what is extracted from the source system?
  8. Where will you budget and forecast? Do you intend to budget at “level zero” members, at a higher-level grouping, or at some combination of the two?
  9. Are target versions needed in order to have end users type at levels other than zero? If the answer is “yes,” this requires actively selecting “BegBalance” be included as a time period and a checkbox within the Scenario member.

Data

Data implementation should be a straightforward discussion. A few of the main questions to ask include:

  1. Where does your data currently reside (e.g., within a legacy system)?
  2. Will these legacy systems stay online after the go-live?
  3. How and when will data be extracted from the system of record?
  4. How will data flow into and within the system? How often will it be sent? Will it be automated?

Forms, Reports, and Dashboards

After dimensionality is settled, it is time to start to jump into the meat of the build by determining and designing forms, reports, and dashboards. Some important questions about forms include:

  1. How will end users input into various data forms?
  2. What is the layout of the form, including whether the dimensions will be located on the row, column, point-of-view, or page?
  3. How dynamic will the form be? For example:
    • Can users add new rows as needed?
    • If users have access to multiple Departments, Entities, etc., should they be allowed to move between those within one form or will there be multiple forms for these?
  4. Do valid intersections need to be established in order to show only “real” and proper combinations for users?
  5. Will the system be setup to handle “pre-seeding” methods to automatically manipulate loaded data into specific useful ways for the budget and forecast?
  6. Are action menus required for users to perform various tasks?
  7. What business rules are needed on the forms to run upon loading and/or saving a form?
  8. Are any smart lists required to assist users in simplifying a form, so a user is not overwhelmed with what to type?
  9. What data maps need to be established to push data between cubes? Is Smart Push an option?
  10. How quickly will the data need to be moved from one cube to another? Will users want to view reports that potentially have data that was just saved on a form seconds earlier?
  11. Does data validation (as a rule) or even simply a validation flag (setup on the form specifically) need to be placed onto forms?
  12. What reports and dashboards are needed (e.g., financial and budget/forecast/”what-if” are very common types of reports created within EPM Cloud applications, while dashboards are a great way to visualize a data set).

Stay tuned for the second post in the series which will focus on business rules, security, navigation flows, task lists and approvals, and data exports to try to help you understand the important discussions to have when designing any EPM Cloud applications.

For additional information on successfully designing, building, and going live with Oracle EPM Cloud applications, please contact us at communications@performancearchitects.com.

Share
© Performance Architects, Inc. and Performance Architects Blog, 2006 - present. Unauthorized use and/or duplication of this material without express and written permission from this blog's author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Performance Architects, Inc. and Performance Architects Blog with appropriate and specific direction to the original content.

Leave a Reply

Your email address will not be published. Required fields are marked *