Tag Archives: Cloud Services

Peruse the Account Reconciliation Cloud Service (ARCS) forums on Oracle’s Cloud Customer Connect and you’ll notice a theme: Transaction Matching. Questions, comments, and critiques have been flooding in from across companies and industries, clients and consultants alike. Combine this with Oracle’s game-changing announcement of the EPM Cloud price simplification plan teased for 2019 – that is, the strategic move to strictly sell bundled EPM Cloud products in the near future (more on this another time – it’s a doozy) – the changes released for ARCS in Patches 1811 and 1812 could not have come at a more opportune time. Furthermore, these changes provide a sneak peek into Oracle’s crystal ball of what’s to come.

The WHAT has come: Changes for ARCS at the end of 2018

The most important change to ARCS from the 2018 season finale, Patch 1812, is the shift from having separate reconciliations between Transaction Matching and Reconciliation Compliance to one standardized use of Profiles. This is configured through the new reconciliation methods provided in Formats (Balance Comparison with Transaction Matching, Account Analysis with Transaction Matching, and Transaction Matching only).

The implication is that Transaction Matching reconciliations receive all the benefits that previously only Reconciliation Compliance enjoyed, including but not limited to: bulk uploads/updates to Profiles and reconciliations, access to new Workflow options such as Reviewers and Teams, and detailed filtering options including the more hidden statistical metrics (such as attributes related to count, etc.). It is important to note, though, that these new features will almost exclusively relate to new reconciliations using one of the two ‘*with Transaction Matching’ format options, as seen below. Still, the opportunity for clever design is there.

Furthermore, to support this change, Period will now be shared between the two feature sets. Additionally, reconciliations that are performed in Transaction Matching will now utilize their period-end Balances loaded to Reconciliation Compliance. While historically there have been business processes put in place to ensure that the balance loaded to Transaction Matching equaled the balance loaded for the month-end reconciliation in Reconciliation Compliance, patch 1812 ensures that a system process governs the data’s integrity – certainly a more reassuring thought.

Two additional under-the-radar features introduced in Patch 1812 are (1) the ability to have Workflow that includes multiple members while not requiring an order precedence to the work and (2) the option to now have end-users approve their own re-assignments, reducing the administrative bottleneck. These changes provide value-add functionality that demonstrate Oracle’s willingness to listen to customer feedback even during these more “stuffed” patches.

The last item to mention was actually included in Patch 1811. In Transaction Matching, a text file can now be generated with the transactions or adjustments from the tool which can then be uploaded to the ERP source systems as a journal adjustment. This has been an ongoing request, and I am happy to see it finally actualized.

The WHAT does it mean: Implications and Expectations for ARCS in 2019

Transaction Matching’s relative strength to its competitors is becoming increasingly apparent, as Oracle continues to sure up areas in need of support while also providing updates that show a sensitivity to market demand. The move to unify Transaction Matching and Reconciliation Compliance is not a new idea, as Patch 1805 made apparent with the uniting of the two UIs (and much more – see Oracle Product Management’s webinar update here), but nonetheless is a bold one that I anticipate will pay dividends. The automatic conversion of Transaction Matching reconciliations to Profiles is a nice touch too, making the transition an easier pill to swallow for skeptical clients who I am sure were not eager to pay expensive consulting fees for this. Even smaller changes such as providing a space for strictly manual matching (i.e. without Auto Match rules; Patch 1811 change) demonstrate ARCS’ commitment to be an approachable and modular product that grows with your company – a benefit I have consistently touted in the past, and I expect to continue to do so in the future. More details about the benefits of ARCS are shared in the posts A Safe Step into the Cloud: The Argument for Account Reconciliation Cloud Service (ARCS) and Modularity in Account Reconciliation Cloud Service (ARCS): No Mistakes from “Day 1” to “Day 100”

Changes continue to come to ARCS that only slowly trickle, if at all, down to Account Reconciliation Manager (ARM). This was true for the Variance Analysis reconciliation method which arrived in May 2017 for ARCS, but not until Dec 2017 for ARM, and it is a fair guess that this will be true for the aforementioned “All Preparers” and “All Reviewers” workflow options and end-user re-assignment configuration setting. Combine this with more and more dollars being invested in Transaction Matching compared to Reconciliation Compliance (from where I’m looking, anyway), and the message is clear on who the favorite is in the Oracle product family. While ARM contains strong functionality as an on-premise option, expect the functionality gap to increase compared to its Cloud counterpart.

Lastly, the inclusion of a journal adjustment export out of Transaction Matching is a combo solution: a “we can do that too” to product competitor Blackline’s existing functionality as well as a demonstration of Oracle’s willingness to think outside of the product. This highlights ARCS’ flexibility as a tool capable of being used within other processes. In fact, the Oracle EPM Cloud ecosystem is one of ARCS’ biggest strengths over its competitors. I would love to see this journaling ability out of Reconciliation Compliance as well which would provide the functionality to most ARCS clients. Regardless, this is a step in the right direction.

Oracle’s Profitability and Cost Management Cloud Service (PCMCS) provides a powerful service for allocating General Ledger profits and costs. Recently, we worked with a banking industry client to provide a model that calculates profitability at a Product/Channel level while maintaining Account level detail. We accomplished this through a framework we refer to as Micro-Costing where detailed profits and costs are calculated in a database using rates developed at the summary level in PCMCS. Alithya began development of this framework in 2016 to meet a functional gap in PCMCS and provide a common framework that can be used either on-premise or in the Cloud.

To highlight the capabilities of Micro-Costing, I will use the solution deployed at our banking client as a specific example. The following table describes the two layers where profits and costs are provided:

Definitions:

Product – a loan or deposit offering. Examples of a loan are an auto loan or credit card; examples of a deposit are a savings account or a checking account.

Origination Channel – where the account was originated.

Service Channel – where the financial or transactional cost or profit is occurring or assigned to.

Customer – a legal entity responsible for accounts; for example, a person with both a home loan and a savings account.

Customer Account – a product that is assigned to a customer.

Financial Costs and Profits – the cost or profit of servicing a loan or deposit for a customer; for example, interest paid on a savings account.

Transactional Costs and Profits – the cost or profit of interacting with a customer; for example, the cost of an ATM transaction.

A simple way of thinking about the client’s business model:

Origination channels offer Products

Products are assigned to Customers as Customer Accounts

Customer Accounts are used by Customers through Service Channels

The generation of an Account level profit or cost is a C = A*B calculation where

WAREHOUSE-STAR – Persists the drivers, the rates, and the calculated profits and costs at the Customer Account level. The Driver Lookup and Driven Value Lookup functions are used to define the drivers and driven values so that the addition of a driver or driven value is a configuration activity for an administrator rather than a coding activity.

Data Integration

A high-level summary of the data flows as deployed:

The source data is broken down into 3 types:

General Ledger

Operational Data

Metadata

Data Integration uses interim flat files to maintain flexibility regarding the source data by establishing an API via the flat files without requiring knowledge of the source systems. This allows for the introduction of source data that comes from 3rd parties not available for automated extraction from the source.

The operational data includes both Customer Account financial information and transactional activities or fees. Product and Channel references are provided along with this information:

1 million+ Customer Accounts

Approximately 6 million transactions per month

Some transactional drivers represent an activity that cannot be associated with a specific Customer Account; for example, a new loan application. Proxy Customer Accounts for each product are generated to provide a place for these activities.

Additionally, although not graphically displayed in the above diagram, Branch level drivers are directly fed into the PCM Model, examples of which are Branch square footage and number of branch employees. These drivers were used for non-Customer Account PCM costs and profits.

All Batch processing is built using SQL Server Integration Services. This is based upon an agreement with the client regarding the preferred tool sets with the database selected being SQL Server. Framework is transferable to other integration tools and databases including Hadoop framework, and in-house solutioning by Alithya was performed in preparation for use of the Micro-Costing framework with larger clients.

The data integration is as follows:

Set POV

Update metadata and stage

Stage financial and transactional information

Validate staged data and reprocess as necessary

Load staged data to ODS and then to Star

Upload PCMCS with GL and drivers

Process allocations in PCMCS

Download rates

Run A*B calculations for each Customer Account and populate profit and cost table

Key Design Principles

The following design principles were focused on during development of the Micro-Costing framework. These principles facilitate an easy-to-use and easy-to-maintain solution as deployed for our client.

Dimensional synchronization between the Micro-Costing warehouse and PCM

Validation checks as close to the original data as possible

Configurable drivers and driven values

Dimensional Synchronization

All dimensional mapping must occur prior to the warehouse star schema. It is not possible to perform the Micro-Costing A*B calculations to derive profits and costs detail otherwise. This has an impact on any deployment that uses FDMEE or Cloud Data Manager as they cannot perform additional mappings during upload to the cube.

Dimensional Synchronization includes a Point of View: Year, Period, Scenario, and Version to allow for loading multiple sets of drivers during a month, and for transfer of ‘what-if’ rates back to the Customer Account level, if desired.

Validation Checks

Validation kick-outs and checks occur as early in the data integration process as possible, with a “simple” validation during staging and a “complex” validation during generation of the fact information in the warehouse. This allows the administrator to catch quality issues with a minimum amount of overall process duration occurring. The data integration process is broken into a series of steps that allows for validation review and then re-running a step prior to moving on to the next step. This principle held up in deployment, ensuring that time wasn’t wasted running later processes with invalid data, the result being an improved overall process and a significant reduction in the number of days required to produce profit and cost analysis for a given month. A lesson learned during the initial roll-out was that our client had not previously required a rigorous validation of the drivers at the Customer Account level and had to develop new techniques for validating the source information to ensure accuracy.

Configurable Driver and Driven Values

A key feature of Oracle’s PCM applications is configurability, and the Micro-Costing framework is built to provide an easy-to-maintain solution that allows for rapid addition of drivers and driven values without the administrator having to manually update the tables and views required to manage the transformation and persistence of data. This was accomplished by defining the drivers and driven values in tables and providing stored procedures for maintaining the tables and views.

The process for adding a new driver and driven value is very straightforward:

Backup the database and the PCM cube.

Update the source feeds to include the new activity or fee.

Update the activity to Driver Lookup and Driven Value Lookup tables with the new values. *Note: The driven value record references the driver for the A*B calculation.

Execute the “Update Costing Tables and Views” stored procedure. *Note: removing a driver or driven value does not modify the tables.

Update HPCM Account dimension for the new driver and driven value.

Update HPCM rules to use the new driver and allocate expenses to the new driven value, and calculate the rate for the new driven value.

Run the entire data integration process for the POV, and review results.

Key Benefits

The successful deployment of the solution provides the following key business benefits:

An improved ability to provide Product/Channel level costs and profits.

Reduced monthly cycle time and effort. The prior data integration process was disjointed and required a large amount of effort to produce results.

Aggregation along other dimensional paths. Starting at the Customer Account level allows for aggregation along Customer attributes such as zip-code or credit score, providing new insights and enhanced executive decision making. A follow-on project to use the Customer Account level data in OAC is currently being assessed.

Additionally, the following benefits to the administrative team are realized:

Model flexibility. The configuration of an additional driver and driven value in Micro-Costing takes fewer than 15 minutes.

Operational Data Store (ODS) and Warehouse. This allows for future projects to use a common curated source of information. This was a pot sweetener for our client who was dissatisfied with its prior warehouse, but needed a business reason to refresh. The prior warehouse lacked the following items that were addressed in the new ODS and warehouse:

Explicit mappings such as Activity Code to Driver Code that are controlled by the business

Easy troubleshooting, validation, and auditing capabilities with PCM. Errors or mismatches in profit or cost at the Product/Channel level can be reduced to either rule definition mistakes or driver data entry mistakes. Finding out where the issue is and correcting it with a few clicks has a positive impact on the overall analysis and maintenance effort.

Final Thoughts

Alithya has developed a Micro-Costing framework that allows an integrated view of profits and costs at both a summary and detailed level. This framework is successfully deployed at a banking industry client to provide a superior solution.

Framework is deployable either on-premise or in the Cloud and is available for other industries such as:

Patient encounters in Healthcare

Claims in Insurance

SKUs in Retail

Subcomponents in Manufacturing

…or anywhere the allocations occur at a summary level with drivers aggregated from a detail level.

As an earlier blog mentioned, the 18.07 release of Enterprise Data Management Cloud Service (EDMCS) delivered one eagerly anticipated piece of functionality: Subscriptions! And do not fear – these subscriptions are useful and do not involve a 1-year subscription to the Fruit of the Month Club (not that there’s anything wrong with that).

This blog post dives deeper into this new functionality, describes how it works, and highlights some lessons learned from utilizing Subscriptions with a current project involving multiple EDMCS Custom applications supporting multiple Profitability and Cost Management Cloud Service (PCMCS) applications.

Why Are Subscriptions Important?

Subscriptions are a huge step towards true “mastering” of enterprise data assets within a single master data Cloud platform. With EDMCS, it is important to build deployment-specific applications configured to the dimensionality requirements of the target applications to most effectively use the packaged adapters, validations, and integration capabilities. But in many cases, you also need to share common hierarchies across applications and avoid duplicative (that’s my big word for today) maintenance. After all, why have a master data management tool if you still must perform maintenance in multiple places? That’s just silly.

The answer to this dilemma is Subscriptions. By implementing Subscriptions, requests submitted to a primary viewpoint will automatically generate parallel subscription requests to subscribing viewpoints to automatically synchronize your hierarchy changes across EDMCS applications.

Note

This comment is important: “automatically generate parallel subscription requests.” EDMCS will not update a target, or subscribing, viewpoint behind the scenes with no visibility or audit trail to what has occurred. A parallel Subscription request will be generated along with the Interactive request that will be visible in the Requests window, along with the full audit trail and details that you find in an Interactive request. Even better, the Subscription request will generate an email and attach a Request File of the changes.

Nerdy Details

Views and Viewpoints

The first thing to really think about is the View and Viewpoint design of your EDMCS applications. Subscriptions are defined at the Viewpoint level, so you need to identify the source and target viewpoint for your business situation. With my current project, I have multiple EDMCS applications supporting multiple PCMCS applications. While the dimensionality is similar across the applications, the hierarchies vary, especially with the alternate hierarchies. So, it has been important to isolate the “common” or shared structures that should be synchronized across applications into their own viewpoint so that a subscription mechanism can be created.

Node Type Converters

You will likely need to create a node type converter. If the source and target viewpoints do not share a common node type, you must create a node type converter for subscriptions to work. In my situation, I had already created node type converters since I wanted to compare common structures across EDMCS applications, so the foundation was there to readily implement subscriptions.

Permissions

To create a Subscription, the creator must have (at a minimum) View Browser permission to the source view, View Owner permission to the target view, and Data Manager permission to the target application.

The Subscription assignee (this is the user who will “submit” the subscription request) must have (at a minimum) View Browser permission to the source view and Data Manager permission to the target application.

Creating a Subscription

Once the foundation is in place in terms of viewpoints, node type converters, and permissions, the actual creation of a subscription is easy.

Inspect the target viewpoint (the viewpoint that is to receive the changes from a source viewpoint via subscription), navigate to the Subscriptions tab, and click Edit. From there you can select the source viewpoint, the request assignee, and enable Auto Submit if needed. Save the subscription and you are all set.

Currently, there is no capability to edit an existing subscription. You must delete and add a new subscription to effect a change.

Any validation errors for your subscription will appear on this dialog as well. These are documented nicely in the Oracle EDMCS administration guide.

Auto-Submit and Email Notifications

Emails will be generated and sent to the Request Assignee, whether Auto-Submit is enabled or not. The email will include details such as the original request #, the subscription request #, and how many request items were processed or skipped.

Note

Remember, the subscription request will have a Request File attached to it. View the request file attachment to see details on why specific request items were skipped.

The request file is not attached to the email itself, only to the request in EDMCS.

Lessons Learned

Like I mentioned earlier, the foundation is important to making subscriptions work. And it all boils down to design and ensuring the building blocks of that foundation are in place:

Design, Design, Design!

The importance of dimension, view, and viewpoint design cannot be overstated. For each dimension, evaluate the primary and alternate hierarchy content and identify what will be shared across dimensions or applications and what will be unique to each dimension and application.

Based on that analysis, carefully design your viewpoints to enable subscriptions across EDMCS applications for hierarchies that truly need “mastering.”

As early as possible, identify the EDMCS user population along with permission levels for applications and views. This is important to identify the appropriate “Request Assignee” for your Subscriptions. I recommend creating a security matrix identifying each user and the permissions each will have.

Without a clear and well thought out design, you will find yourself constantly re-doing your views and viewpoints which, in turn, will cause constant rework of your subscriptions. The “measure twice, cut once” adage certainly applies here!

I am a big proponent of standard, consistent naming conventions to improve the usability and end user experience. The same holds true for Subscriptions. Consider using a standard naming convention for your viewpoints so it is clear which viewpoints have a subscription. It’s not obvious – unless you Inspect the viewpoint – that a subscription exists.

One approach I’ve been using is to name my source and target viewpoints identically with a special tag or symbol at the end of the target viewpoint name to indicate a subscription is present. I’m sure there are other and probably better ideas, but I find the visual cue to be helpful.

Perhaps in the future, Oracle will display subscription details when you hover over a viewpoint name (hint hint).

Node Type Converters

I ran into an issue where updates to one property in my source viewpoint were not being applied to my target viewpoint via subscription requests, but all other property updates worked fine. The reason? I had recently modified my App Registration and added this property to a dimension’s node type. But my node type converter had already been created and wasn’t mapping or recognizing the new property. Once I updated my node type converter, the problem was solved.

Troubleshooting

The request files attached to subscription requests are a valuable troubleshooting tool. Status codes and error messages are included in these Excel files that are extremely helpful to determine why your request was not auto-submitted.

Inspect the Subscriptions on your viewpoints. Any validation issues will be displayed and are easily addressed. Typical Subscription validation errors include:

The request assignee no longer has the correct permission levels

The viewpoint no longer is active

A node type converter is missing

Conclusion

I have been looking forward to the subscription functionality in EDMCS and am pleased with it so far. Subscriptions are easy to configure, can be configured to auto-submit if desired, and generate emails to remind the requester a request has occurred and to act if the request was not submitted or request items were skipped. EDMCS Subscriptions are a big step forward to enabling true mastering of your enterprise data management assets!

Over the last year, we have been fielding, positioning, and aligning more with Oracle’s new Cloud products. Some of the most common questions we are asked are:

Has Edgewater Ranzal done that before?

What “gotchas” have you encountered in your implementations and how have you addressed them?

What unique offerings do you bring?

These are all smart questions to ask your implementation partner because the answers provide insight into their relevant experience.

Has Edgewater Ranzal done that before?

Edgewater Ranzal is an Oracle PCMCS thought leader and collaborates with Oracle as a Platinum partner to enhance PCMCS with continued development. To date, we’ve completed nearly 20 PCMCS (Cloud) implementations, and almost 80 Oracle Hyperion Profitability and Cost Management (HPCM – on premise) implementations spanning multiple continents, time zones, and industries. Our clients gladly provide references for us which is a testament to our success and abilities. Additionally, we frequently have repeat clients and team up with numerous clients to present at various conferences to share their successes.

As a thought leader in the industry and for PCMCS, we sponsor multiple initiatives that deliver implementation accelerators, test the latest product enhancements prior to their release, and work in tandem with Oracle to enhance the capabilities of PCMCS.

Now let’s explore some of the data integration challenges one might unexpectedly encounter and the intellectual property (IP) Ranzal offers to mitigate these and other data integration challenges that lurk.

What gotchas have you encountered in your implementations and how do you mitigate them?

We could go into great depth when detailing the PROs for using FDMEE with PCMCS…but it is much more beneficial to instead share some of the other less obvious discoveries made. Note that we work directly and continuously with Oracle to improve the product offering.

Extracting data via FDMEE data-sync is challenging. The size of the data cube and configuration settings of PCMCS has a threshold limit – 5,000,000 records and a 1GB file size – both of which are quite often reached. As a result, we have developed a custom solution for the data-sync routine.

Large datasets directly into PCMCS via DM (Cloud-based Data Management) can exhibit performance problems due to the server resources available in the Cloud. Functionality in on-premise FDMEE (scripting, Group-By, etc.) helps reduce the number of records going into the Cloud and therefore provides a performance gain.

Patching to the latest FDMEE patch set is crucial. Cloud applications (PCMCS, FCCS, E/PBCS) update monthly. As a result, we need to consistently check/monitor for FDMEE patches. These patches help ensure that canned integrations from Oracle are top-notch.

Executing two or more jobs concurrently via EPMAutomate is quite troublesome due to the workflows needed and how EPMAutomate is designed. As a result, we have invested considerable time into cURL and RESTful routines. We discovered that the login/logout commands are tied to the machine, not the user-process, so any logout from another executing run logs out all sessions.

The use of EPMAutomate is sometimes difficult. It requires a toolset on a PC – “JumpBox” – or on-premise EPM servers. It also requires the use of .BAT files or other scripted means. By using FDMEE, the natural ease of the GUI improves the end-user experience.

Loading data in parallel via FDMEE or DM can cause Essbase Load Rule contention due to how the automatic Essbase load rules are generated by the system. Oracle has made every effort to resolve this before the next Cloud release. Stay tuned… this may be resolved in the next maintenance cycle of PCMCS (18.10) and then the on-premise update of patch-set update 230.

We all know that folks (mainly consultants) are always looking to work around issues encountered and come up with creative ways to build/deliver new software solutions. But the real question that needs to be asked is: Should we? Since FDMEE has most of the solutions already packaged up, that would be the best tool for the job. The value that FDMEE can bring is scores better than any home-grown solution.

What unique offerings do you bring?

At Edgewater Ranzal, we have started to take some of our on-premise framework and adopt it for PCMCS. Some of the key benefits and highlights we provide are:

To combat the complications with loading data via FDMEE because of FDMEE’s inability to execute PCMCS clears out-of-the-box, we have added the functionality into the Ranzal IP catalog and can deploy this consistently for our clients. This is done via the RESTful functionality of PCMCS. Some of the items we have developed using REST are:

Import/export mappings

Execute data load rules or batch jobs from 3rd party schedulers

Refresh metadata in the Cloud

Augment EPMAutomate for enhanced flexibility

Execute business rules/clear POV commands as part of the FDMEE workflow

Execute stored procedures (PL/SQL) against DBaaS (see below)

Enhanced validation framework (see below)

We have redeveloped our Essbase Enhanced Validate to function with the PCMCS Cloud application. FDMEE on-premise can now validate all the mapped data prior to loading. This is great for making sure data is accurate before loading.

The Edgewater Ranzal tool-kip for FDMEE includes the ability to connect to other Cloud offerings for data movements, including DBaaS and OAC.

Can FDMEE do that…and should FDMEE do that?

Yes, you should use FDMEE to load to PCMCS, and it is an out-of-the-box functionality! As you can see, unlike DM whose feature comparison to FDMEE will be discussed in a later blog and white-paper, there are a lot of added benefits. The current release of FDMEE v11.1.2.4.220 provides product functionality enhancements and has greater stability for integrations with most Cloud products. Suffice it to say, having python scripting available and server-side processing for large files will greatly enhance your performance experience.

Contact us at info@ranzal.com with questions about this product or its capabilities.

What is Oracle Profitability and Cost Management?

Organizations with world class finance operations generally can close in a minimal number of days (2-3 in an ideal organization) and have frequent and efficient budget and forecast cycles while also visiting different ‘what if’ scenario analysis along the way. These organizations often deliver in-depth profitability and cost management analysis reports at fund, project, product, and/or customer level, completing the picture of an accurate close cycle.

Oracle offers packaged options in support of all these finance processes, but the focus of this post will be Profitability and Cost Management (PCM).

One of the most painful and time-consuming processes for any business entity is PCM analysis. The reasons why cost allocations processes are time consuming are too many to count – from model complexity to data granularity, driver metric availability, rigidity of allocation rules, delays with implementing allocation changes, and almost impossible-to-justify results. Instead of focusing on the negative aspect, let’s focus on what can be done to alleviate such pain and energize the cost accounting department by giving it access to meaningful and accurate data and empowering users through flexibility to perform virtually unlimited “what if” analysis.

The PCM Journey

The initial Profitability and Cost Management product, like almost all Oracle EPM offerings, was released on-premise in July 2008 and is known as Oracle Hyperion Profitability and Cost Management (HPCM). 10 years later, HPCM continues to deliver an easier way to design, maintain, and enhance allocation processes with little to no IT involvement as it has since it was initially launched, but with a greater focus on flexibility and transparency. The intent for HPCM was to be a user-driven application where finance teams would be involved beginning with the definition of the methodology all the way to the steps needed to execute day-to-day processing. Any cost or revenue allocation methodology is supported via HPCM while graphical traceability and allocation balancing reports support any query from top-level analysis all the way down to the most granular detail available in the application.

There are 3 HPCM modules available on-premise today. Each was designed and developed for a different type of allocation methodology or complexity need:

Simple allocations – Detailed Profitability (a.k.a. single-step allocations. Example: From Accounts and Departments, allocate data to same Accounts, new target Departments, and to granular Products/SKU based on driver metric data. This module allows for a very high degree of granularity with dimensions >100k members, but it does not cater to complex driver calculations or to allocations requiring more than 1 stage).

Average to high complexity allocations – Standard Profitability (a.k.a. multi-step allocations of up to 9 iterations/stages, allowing for reciprocal allocations. Example: Allocations from accounts and departments to channels, funds, and other departments. Allocation of results from previous steps are redistributed onto Products, Customers etc. Driver metric complexity is achievable with this module; custom generated drivers are available as well, but there are limitations regarding driver data granularity, granularity of allocated data, and overall hierarchy sizing).

High complexity allocations – Management Ledger (unlimited number of steps, high number of complex drivers, custom driver calculations, custom allocations, more granularity, and increased flexibility in terms of defining and expanding allocation methodology). This is the last module added to the HPCM family and the only one available as SaaS Cloud Offering.

The Cloud is Your Oyster

In 2016, Oracle introduced the Cloud version of HPCM: Profitability and Cost Management Cloud Service (PCMCS). PCMCS is a Software as a Service (SaaS) offering, and as with many of Oracle’s Cloud offerings, PCMCS includes key improvements that are not available in the on-premise version, and enhancements are made at a much faster pace.

There is currently no indication that the two HPCM modules – Detailed and Standard Profitability – will make their way to the Cloud, since increased allocation complexity as well as increased hierarchy sizing supported by the Management Ledger module caters to most, if not all, potential requirements.

The Management Ledger module included with the PCMCS SaaS subscription has a core strength in the ease of use and flexibility to change, enabling finance users to define and update allocation rules and methodologies via a point-and-click interface. While the initial setup is advisable to be performed with support from an experienced service provider, the maintenance and expansion of PCMCS (Management Ledger) models can be achieved by leveraging solely functional resources, in most cases. “What-if” scenario creation and analysis has never been easier. Users not only can copy data and allocation methodologies between scenarios, but they can also update the data sets and allocation steps independently from a standard scenario, generating as many simulation models as they need, gaining increased insight into decision making.

Standard Profitability models perform allocations in Block Storage Databases (BSO). While BSO applications are great for complex calculations and reciprocal allocation methodologies, they have the disadvantage of being limited in terms of structure or hierarchy sizing. This hierarchy restriction is not as pressing in Aggregate Storage Option (ASO) type applications, which is the technology used by Management Ledger. The design considerations for a Standard Profitability model are also significantly more rigid when compared with the Management Ledger module, which has no limitations regarding allocation stages, allocation sequencing, or a maximum number of dimensions per each allocation step.

Detailed Profitability models heavily leverage a database repository while any connected Essbase applications are used solely for reporting purposes. Initial setup and future changes, outside of the realm of simply adding new hierarchy members, will require specialized database management skills, and the usage of a single step allocation model is not as pervasive. Complex allocation methodologies may require the usage of Detailed Profitability models in conjunction with Management Ledger, but these situations represent the exception rather than the rule.

Why Should You Choose Oracle Profitability and Cost Management?

One of the key strengths for HPCM, available since it was released, and now included in PCMCS, is transparency – the ability to identify and explain any value resulting from the allocation process, with minimal effort. Each allocation rule or allocation step is uniquely identified, enabling users to easily navigate via the embedded/out-of-the-box balancing report to the desired member intersection opened through a point and click action in Excel (using Smart View) for further analysis and investigation. The out-of-the-box-program documentation reports identify the setup of each rule and can be leveraged for quick search by account, department, segment code, or any other dimension available in the application. The execution statistics reports delivered as part of the PCMCS offering enable users to quickly understand which allocation process is taking longer than expected and identify opportunities for overall process improvement or to simply monitor performance over time. These two out-of-the-box reports – execution statistics and program documentation – are the most heavily used reports during application development, troubleshooting, and particularly when new methodologies are developed. Users can quickly search through these documents, leverage them to keep track of methodology changes, and use them as documentation for training new team members.

Performing mass updates to existing allocation rules has never been faster. PCMCS contains a menu that allows end users to find and replace specific member name references in their allocations for each individual data slice, allocation step, or an entire scenario. A quick turnaround of such maintenance tasks results in an increased number of iterations through different data sets, giving the cost accounting team more time to perform in-depth analysis rather than waiting for system updates.

PCMCS-embedded analytics and dashboarding functionality is also a significant differentiator, enabling end users to create and share dashboards with the rest of the application users through the common web interface and without the need for IT support. Reports created in PCMCS are available immediately and without time consuming initial setup or migrations between environments followed by further security setup tasks.

A comparison of On-Prem vs Cloud will be available in a future post, so please subscribe below to receive notifications for PCMCS-related blog updates.

Last time, in the Wonderful World of Enterprise Data Management Cloud Service (EDMCS), we discussed initial impressions of this exciting new Oracle Cloud product and highlighted some early functionality enhancements.

Enhanced searching across members (name and descriptions) and data objects

Lifecycle management of data objects

Incremental imports

Viewpoint download from selected node

Furthermore, in the areas of REST API and metadata integrations, Tony Scalese, Vice President at Edgewater Ranzal and Oracle ACE, has written several blogs. These posts were written from the perspective of hands-on, real-world experience by working with one of three customers accepted into the Oracle EDMCS Early Adopter program. The blog posts include:

In this post, I’d like to highlight another feature that was recently added to EDMCS: enhanced request load files.

Enhanced Request Load Files

In the initial release, EDMCS provides a mechanism to perform bulk updates to EDMCS hierarchies – the Excel request load file. While the feature immediately had some advantages over its distant cousin in Data Relationship Manager (DRM) (action scripts), there were limitations. Primarily, EDMCS would only recognize the first tab or worksheet in an Excel file.

Well that has been fixed! Request load files can now contain multiple worksheets, and EDMCS will recognize all of them (provided the worksheet names match your viewpoint names of course). Additionally, EDMCS will automatically select all valid worksheets to load into EDMCS when loading a request file. This makes it very easy to download viewpoints to Excel and build a request file containing updates for multiple viewpoints to bulk upload at one time.

This also means you need to be careful! Since EDMCS auto-selects any matching worksheet name, if you were not paying attention, you could accidentally load outdated requests from a worksheet. But you can still delete any unwanted request items prior to submitting the request, if you catch them first.

While you could always load multiple request files in a single request since the initial release of EDMCS, this feature is a nice usability and productivity enhancement. It works great for situations such as adding a node to a primary hierarchy/viewpoint and inserting it into an alternate hierarchy/viewpoint, all from the same request.

Conclusion (and a teaser)

While EDMCS is the new kid on the block in the Oracle EPM cloud space, it’s exciting to see how it’s quickly closing the gap with new functionality being added regularly! REST API operations, enhanced request files, and the other enhancements mentioned above show how far EDMCS has come in just 6 months.

But wait, there’s more!

The 18.07 release of EDMCS looks to be a HUGE release chock full of new features, including one I am especially excited for: subscriptions!

Look for more blog posts coming soon to discuss the subscription functionality and utilizing EDMCS for a Profitability and Cost Management Cloud Service (PCMCS) implementation.

Recently my team and I had the opportunity to implement Oracle’s newest offering – Enterprise Data Management Cloud Service (EDMCS). EDMCS for those of you who are not familiar provides a cloud-based solution for managing master data (also referred to as metadata) across the organization. Some like to refer to EDMCS as Data Relationship Manager (DRM) in the Cloud, but the truth is, EDMCS is not DRM in the Cloud.

EDMCS is a completely new vision of what master data management can and should be. The architect of this new cloud offering is the same person who founded Razza Solutions which was the company that developed the product now known as DRM. That is important to know because it ensures that the best of what DRM has to offer is brought forward. But, more importantly, it ensures that the learnings and wish list of capabilities that DRM should have are in the forefront of the developers’ minds.

Ok, now let’s get back to fun stuff. In the 18.05 patch for EDMCS, the REST API (v1) was exposed for public usage. The documentation for the REST API can be found here:

As I highlighted in the previous post Troubleshooting Cloud Data Management Metadata Load Errors, I had developed an automation routine to upload EDMCS extracts to both PBCS and FCCS using FDMEE and Cloud Data Management. We had been eagerly awaiting the REST API for EDMCS to finalize this automation routine and provide a true end-to-end process that can be scheduled or initialized via a single action.

Let’s take a quick look back at the automation routine developed for this customer. After the metadata has been exported to a flat file from EDMCS, the automation would upload a copy to the PBCS and FCCS pods, launch Cloud Data Management data load rules which would process the EDMCS metadata extracts, run a restructure of the database after all dimensions had been loaded, and then send a status email alerting the administrator of the result. While elegant, I considered this to be incomplete.

Automation, in my view, is a process that can be executed without user interaction. While an automation routine certainly has parameters that must be generally maintained, once those parameters are set/updated, the automation cycle should not be dependent on user input or action. In the aforementioned solution, we were beholden to the fact that EDMCS exports had to be run interactively; however, with the introduction of the publicly exposed REST API in the 18.05 EDMCS patch, we are now able to automate the extract of metadata from EDMCS. That means we can finally complete our fully automated, end-to-end solution for loading metadata. Let’s review the EDMCS REST API and how we did it.

The REST API for EDMCS is structured similar to other Oracle EPM REST APIs. By this, I mean that multiple REST commands may need to be executed to achieve a functional result. For example, when executing a Cloud Data Management data load rule via the Data Management REST API, the actual execution of the data load rule is handled by a POST call to the jobs function with the required payload (e.g. DLR name, start period, etc.). This call is just one portion of a functional requirement. To achieve an actual data load, a file may need to be uploaded to the cloud, the data load rule initialized, and then the status of the data load rule be retrieved. To achieve this functional result, three unique REST API executions would need to occur.

To export metadata from EDMCS to a flat file using the REST API, the following needs to be executed:

Get the dimension information for the EDMCS application from which metadata will be exported

Execute an export of the dimension(s)

Determine the status of export

Download the export to a flat file

Let’s explore each of these in a little more detail. First, we need to get the dimension IDs for the application from which we will be downloading metadata. This is accessed from the applications function.

When executing this function, the JSON object return includes all applications that exist in EDMCS (including those archived). So the JSON needs to be iterated to find the record that relates to the application from which metadata needs to be exported. In this case, the name of the application is unique and can be used to locate the appropriate record. Next, we need to query the JSON object to get the actual dimension id (circled in red). The dimension ID is used in subsequent calls to actually export the dimension.

Great, now we have the dimension ID. Next, we need to execute the REST API call to export the dimension.

And there you have it, a fully automated solution to download metadata to flat files from EDMCS. Those files are then provided to the existing automation routine and our end-to-end process is truly complete.

And for my next trick…let’s explore some of the different REST API tools that are available to help you in your journey with the EPM REST APIs.

In my last post, I highlighted a solution that was recently deployed for a customer that leveraged Enterprise Data Management Cloud Service (EDMCS), Financial Data Quality Management Enterprise Edition (FDMEE), and Cloud Data Management (CDM) to create an automated metadata integration process for both Planning and Budgeting Cloud Service (PBCS) and Financial Close and Consolidation Cloud Service (FCCS). In this post, I want to take a bit of a deeper dive into the technical build and share some important learnings.

Cloud Data Management introduced the ability to load metadata from a flat file to the Oracle EPM Cloud Services in the 17.11 patch. This functionality provides customers the ability to leverage a common platform for loading both data and metadata within the Cloud. Equally important, CDM allows metadata to be transformed using its familiar mapping functionality.

As noted, this customer deployed both PBCS and FCCS. Within the PBCS application, four plan types are active while FCCS has the default two plan types. A design decision was made for EDMCS to create a single custom application type that would store the metadata for both cloud applications. This decision was not reached without significant thought as well as counsel with Oracle development. While the pros and cons of the decision are outside the scope of this post, the choice to use a custom application registration in EDMCS ensured that metadata was input a single time but still fed to both cloud applications. As a result of the EDMCS design decision, a single metadata file (per dimension) was supplied with properties necessary to support each plan type.

CDM leverages its 23 “dimensions” to store metadata information for processing. Exactly like data, metadata is imported using an import format into the CDM relational repository. Each field from a metadata file is aligned to a CDM dimension field. The CDM Account dimension always represents the target application member name and the CDM Entity dimension represents the parent of the member. All other fields can be aligned to any of the remaining 21 dimensions. CDM Attribute dimensions can be utilized in the import and mapping process but are not available for exporting to the cloud application. This becomes an important constraint especially in a multi-plan type deployment. These 21 fields can be used to store any of the properties required to successfully load metadata to the target plan type.

Let’s consider this case study for a moment. The PBCS application has four plan types. If a process were to be built to load all plan types from a single CDM data load rule, then we would not be able to have more than five plan type specific attributes or properties because we would not have enough CDM fields/dimensions to store the relevant information. This leads to an important design approach. Instead of a single CDM data load rule to load all plan types, a data load rule was created for each plan type. This greatly increased the number of metadata properties and attributes that could be loaded by CDM and ensured that future growth could be accommodated without a redesign of the integration process.

It is important to understand that CDM utilizes the Planning Outline Load Utility (OLU) to actually perform the metadata load to the cloud application. The OLU loads metadata using merge (yes Planning experts, I realize that I am not discovering fire) which is important to understand especially when processing multiple metadata loads for a single application. When loading metadata, there are certain properties that are Application level. I like to think of these as being global. Additionally, there are plan type specific attributes that can align (or not align) to the application level value/setting. I like to think of these as local.

Why is this important? Well when loading a metadata file, if certain global properties are excluded from the metadata load file, the local properties (if specified) are utilized to default the global properties. Since metadata is loading using merge, this only becomes problematic when a new member is being added to the outline.

In this particular example, an alternate hierarchy with shared members was specified in one of the plan types. The storage property of the alternates was obviously set as Shared; however, when attempting the metadata load, the following error was encountered:

A Base Member cannot be changed to a Shared Member.

After much investigation (details to follow), I discovered that the global property should also be included in the metadata load.

While CDM utilizes the OLU to load metadata, it does not provide as much verbosity in the error information as the PBCS web interface (which also uses OLU) when loading metadata. Below is an example of the error in the CDM process log. As a tangent, I’d love to check the logs without needing to open a Service Request. Maybe Oracle will build an enhancement that allows that in the future (hint, hint, wink, wink to my friends at Oracle).

So where do I go from here? Well, what do we know about CDM loading metadata to the cloud application? We know that CDM uses the OLU to load a flat file generated by CDM. Bingo! The metadata file output by CDM is a good starting point. That file is in the Outbox of the CDM application and can be downloaded in several different ways – CDM Import process (get creative folks), CDM process details, or EPM Automate. Now we have the metadata file and can test to determine if the error is caused by CDM or the metadata itself. It’s all about ruling out variables. So, we take the metadata file and import it manually within the PBCS web interface and are able to replicate the error. But now we have an important new data point – the line number from the metadata file that is causing the error.

Now that we have actionable information, we can review each property and start isolating and eliminating different variables. We determined that this error was only occurring for new alternate hierarchy parents being added to the outline. As a test, we added the global storage property and voila, the metadata load completed successfully. Face palm!

Maybe this would have been obvious to folks with a lot of Planning experience, but there are plenty of folks learning the intricacies of Planning and Essbase (including our friends converting from HFM to FCCS), so I wanted to share a lesson learned in my journey of metadata integration using CDM.

CDM functionality for metadata represents two of the three primary operations of ETL. In my next post, we’ll dive deeper into how the extract component of ETL was accomplished to provide a seamless end- to-end ETL solution for metadata.

A friendly game of laser tag between out-of-shape technology consultants became a small gold mine of analytics simply by combining the power of Essbase and the built-in data visualization features of Oracle Analytics Cloud (OAC)! As a “team building activity,” a group of Edgewater Ranzal consultants recently decided to play a thrilling children’s game of laser tag one evening. At the finale of the four-game match, we were each handed a score card with individual match results and other details such as who we hit, who hit us, where we got hit, and hit percentage based on shots taken. Winners gained immediate bragging rights, but for the losers, it served as proof that age really isn’t just a number (my lungs, my poor collapsing lungs). BUT…we quickly decided that it would be fun to import this data into OAC to gain further insight about what just happened.

Analyzing Results in Essbase

Using Smart View, a comprehensive tool for accessing and integrating EPM and BI content from Microsoft Office products, we sent the data straight to Essbase (included in the OAC platform) from Excel, where we could then apply the power of Essbase to slice the data by dimensions and add calculated metrics. The dimensions selected were:

Metrics (e.g. score, hit %)

Game (e.g.Game 1, Game 2, Total),

Player

Player Hit

Target (e.g. front, back, shoulder)

Bonus (e.g. double points, rapid fire)

With Essbase’s rollup capability, dimensions can be sliced by any one item or at a “Total” level. For example, the Player dimension’s structure looks like this:

Players

Red Team

Red Team Player 1

Red Team Player 2

Blue Team

Blue Team Player 1

Blue Team Player 2

This provides instant score results by player, by “Total” team, or by everybody. Combined with another dimension like Player Hit, it’s easy to examine details like number of times an individual player hit another player or another team in total. You can drill in to Red Team Player 1 shot Blue Team or Red Team Player 1 shot Blue Team Player 1 to see how many times a player shot an individual player. A simple Smart View retrieval along the Player dimension shows scores by player and team, but the data is a little raw. On a simple data set such as this, it’s easy to pick out details, but with OAC, there is another way!

Even More Insight with Oracle Analytics Cloud (OAC)

Using the data visualization features of OAC, it’s easy to build queries against the OAC Essbase cube to gain interesting insight into this friendly folly and, more importantly, answer the questions everybody had: what wasthe rate of friendly fire and who shot who? Building an initial pivot chart by simply dragging and dropping Essbase dimensions onto the canvas including the game number, player, score, and coloring by our Essbase metric “Bad Hits” (a calculated metric built in Essbase to show when a player hit a teammate), we discovered who had poor aim…

Dan from the Blue team immediately stands out as does Kevin and Wayne from the Red team! This points us in the right direction, but we can easily toggle to another visualization that might offer even more insight into what went on. Using a couple of sunburst type data visualizations, we can quickly tie who was shooting and who was getting hit – filtered by the same team and then weight by the score (and also color code it by team color).

It appears that Wayne and Kevin from the Red Team are pretty good at hitting teammates, but it is also now easy to conclude that Wayne really has it out for Kevin while Kevin is an equal opportunity shoot-you-in-the-back kind of teammate!

Reimagining the data as a scatter plot gives us a better look at the value of a player in relation to friendly fire. By dragging the “Score” Essbase metric into the size field of the chart, correlations are discovered between friendly fire and hits to the other team. While Wayne might have had the highest number of friendly fire incidents, he also had the second highest score for the Red team. The data shows visually that Kevin had quite a few friendly fire incidents, but he didn’t score as much (it also shows results that allow one to infer that Seema was probably hiding in a corner throughout the entire game, but that’s a different blog post).

What Can You Imagine with the Data Driving Your Business?

By combining the power of Essbase with the drag-and-drop analytic capabilities of Oracle Analytics Cloud, discovering trends and gaining insight is very easy and intuitive. Even in a simple and fun game of laser tag, results and trends are found that aren’t immediately obvious in Excel alone. Imagine what it can do with the data that is driving your business!

First, some background: these observations are based on an actual project from working with a client who was 1 of 3 selected for the EDMCS Early Adopter Program. This client is essentially going all-in on Oracle EPM Cloud, with Planning and Budgeting Cloud Service (PBCS), Financial Consolidation and Close Cloud Service (FCCS), and Account Reconciliation Cloud Service (ARCS). One on-premise component, Financial Data Quality Management Enterprise Edition (FDMEE), is also in the mix. This client quickly realized its reporting structures between the Planning/Budgeting and Financial Close/Consolidation worlds, while not identical, were similar and contained a high degree of shared structures. The idea of maintaining these reporting structures in multiple tools did not make sense, leading the client to inquire about EDMCS. After an evaluation, Oracle selected them to participate in the early adopter program for EDMCS with Edgewater Ranzal as the implementation partner.

EDMCS = DRM in the Cloud, Right?

Well, not exactly, but that’s not necessarily the right question to ask. EDMCS is NOT a lift-and-shift of Data Relationship Management (DRM) to the Cloud. Yes, there are similar concepts and constructs in EDMCS that a DRM administrator will quickly grasp (Add/Insert/Delete/Remove of members, Shared members, properties, and node types to name a few). But EDMCS utilizes a different philosophy to manage your enterprise master data along with a different data model, all geared around effective master data management for EPM Cloud products. It’s crucial to adopt a new mindset as you embrace EDMCS and not be constrained by “this is how DRM did it.”

With EDMCS, you will immediately notice new functionality such as the capability to create an Enterprise Planning and Budgeting Cloud Service (EPBCS) or PBCS application in EDMCS, which provides the built-in connectors, properties, and validations for those target applications. Simply step through the Register Application wizard, specify your dimensions and plan types, and EDMCS will automatically build the rest for you. The built-in properties and validations enforce constraints and business rules to ensure no changes can be made that could break EPBCS/PBCS.

For other use cases, EDMCS provides the ability to create a custom application along with custom properties. As EDMCS matures, the number of packaged connectors, applications, and validations will surely increase.

So, the Data Model is Different?

The EDMCS data model is quite different from DRM. Understanding the EDMCS data chain is crucial to effective administration, especially given new concepts such as Viewpoints, Hierarchy Sets, and Node Sets.

Key data objects include:

Node Type – a collection of nodes and associated properties for your application

Hierarchy Set – defines the parent-child relationships of nodes

Node Set – defines a group of nodes available for a viewpoint. This may include all nodes in a hierarchy set or a subset of nodes

Viewpoint – the other data objects come together to provide the viewpoint, which is essentially the “hierarchy” you interact with to modify nodes, parent-child relationships, and properties

The diagram below, taken from the Oracle EDMCS Administration Guide, is a useful reference as you start to build out your EDMCS applications. Future blog posts will explore these key constructs in more detail.

Does EDMCS include Data Relationship Governance (DRG)?

Not yet, but workflows, approvals, separation of duties, and other data governance goodness is on the roadmap for EDMCS. But fear not! EDMCS already provides a “request” mechanism. Modifications to master data can only be performed within the context of a request. Requests can include interactive changes through the UI or batch loading of changes through an Excel request file (think of request files like automator or action scripts, but easier to use and yes, in Excel!). Comments can be included with a request and, continuing with one of the strongest features of DRM, requests provide auditability by capturing the who/what/when/where of every change performed in EDMCS.

How is the User Interface?

One of my favorite features is the visual feedback EDMCS provides as you make changes within a request. As you add, insert, remove, delete, reorder, or modify a member, visual icons and highlights are displayed for that member in real-time to capture the action being performed on that member. You basically get a preview of the change before it’s committed. Changes to properties are visually highlighted and easy to spot. Validations are performed as the request is in Draft status and instantly flag any violations with error messages highlighting the problem node and issue.

Summary

Overall, EDMCS is an exciting entry into the EPM Cloud market and a foundational tool critical to maximizing your EPM Cloud investment. While DRM administrators will experience an adjustment period as they learn EDMCS due to the data chain and new terminology, they will be pleasantly surprised with the available functionality such as pre-packaged connectors and properties for PBCS/EPBCS, the use of requests (and did I mention you can load Excel files?!), and the real-time visual feedback as you modify and validate your master data.