I’ll start by highlighting a few of the common major features between PBCS and EPBCS so that we can begin to focus on what is different.
In terms of functionality, PBCS and EPBCS are both built on a foundation of the established, world-class capabilities of Hyperion Planning. Planning serves as a common repository for business users to collaborate and build their plans in, and eliminates the common pain points of Excel-based planning solutions (or problems, more accurately) such as version control and data quality issues. It provides a highly interactive interface, a task-based planning process framework, scenario modeling, the ability to run calculations, and useful functions such as spreading and driver-based planning.
Subscriptions for both products are purchased as a “pod” as the unit of service, and customers buy access for a minimum of 10 users. A pod consists of 2 environments (production and pre-production) which are expected to contain the same applications. It is worth noting that the subscription includes all of the relational database licensing to support the back-end system repositories for the software and applications, which is a separate purchase for on-premise solutions.
Both products also include access to additional tools that provide significant user benefits and process efficiencies. Users have access to the Smart View add-in to enable reporting and ad-hoc analysis directly from Excel and other MS Office components. All of the web-based input forms, task lists, and other components are also available via Smart View – so build once and access either way. For production quality, formatted reporting users access the included Financial Reporting product and view reports on the web, in PDF, or in Smart View. All of the capabilities are provided in a mobile-friendly UI that provides access from tablets and smartphones.
These PBCS and EPBCS subscriptions also include the FDMEE data integration tool, which is called “Data Management” in the cloud. Data Management provides a high level of quality assurance for data load processes while also enabling data transformations and mappings to be applied and facilitating drill-back to sources. On-premise FDMEE can often be a significant cost to customers, so having it included presents a major benefit for both PBCS and EPBCS.
Lastly, there are some broader platform updates related to the EPBCS launch that will have benefits for both services. The most noteworthy for me is the ability to customize the interface tiles shown in the image above. With a new set of configurations called “Structures”, those tiles will be able to be renamed or nested into a sub-folder called a “card”. Additional tiles can be added with direct links to other areas of the application such as forms or reports. This is a nice capability that really enables the applications to be tailored to the workflow of the organization. Here is an example of what Structures look like in action:
Differences Between PBCS and EPBCS
The major difference between these products is the out-of-the-box content that is provided with EPBCS. A picture may be the best way to start, then I will explain.
Here is where we start to get into a bit of technical terminology. As we established in the previous posting, PBCS is a “bring your own app” solution. It provides for several application containers called plan types – the same language used for on-premise Planning. Plan types can take 2 different forms. First, a Block Storage Option (BSO) plan is used for collecting user inputs, performing calculations, and facilitating the planning process. The other option, an Aggregate Storage Option (ASO) plan, is used for reporting. There is a bit more to each of those classifications but for now we have covered what we need to. PBCS provides 3 BSO plan types and 4 ASO plan types.
So a simple way to think of PBCS is that you can support 3 different functional planning processes with the 3 BSO plan types. Common examples are Financials, Labor, and Projects. They are different processes because they each typically have different data elements or level of detail that warrants them being separate. Reporting applications allow these data sets to be combined for reporting purposes and also provide a place to store additional years of historical data and previous plan snapshots that we do not want to clutter our active planning applications with.
With EPBCS we have a super-set of everything that is in PBCS plus predefined, configurable, incrementally enabled content provided by Oracle. Customers can still bring their own applications, but they are not required to. Oracle decides the underlying BSO/ASO configuration of those out-of-the-box capabilities, and they are likely to change as new features are developed, so there is no value in trying to relate them into quantities of additional plan types. Here is an Oracle view of what this looks like:
Like everything in life, you don’t get something for nothing so there is incremental cost above the standard PBCS per-user cost in order to have access to these out-of-the-box capabilities of EPBCS. Customers will initially have the option to purchase all 4 of these capabilities but later this year will have another option to purchase standard PBCS +1 of the above.
The next parts of the series will explore what is in each of these new out-of-the-box capabilities.
Thanks. Questions and Feedback welcome !!