Out-of-the-Box Features: Profitability and Cost Management Cloud Service (PCMCS) – Intelligence and Dashboarding: Profit Curves

Welcome back to this series of blog posts to cover out-of-the-box (OOTB) features of Profitability and Cost management Cloud Service (PCMCS). There is a need within the Oracle Cloud client community to discover what can be achieved with the tools provided when subscribing to one or more Oracle Cloud Services. A lack of awareness of the features included with your subscription is an unmeasured cost and a missed opportunity to gain much needed insight without further spend.

PCMCS applications – whether built for Fully Allocated P&L Solutions, Transfer Pricing, Shared Services Allocations or Customer/Product Profitability – have OOTB reporting capabilities available via the Intelligence menu that offer insight into allocation models with reduced effort. Here, we’ll explore how to set up, configure, and use such features and fully leverage the functionality that is included in the Oracle Cloud subscription cost.

The order in which I am covering the OOTB features is directly related to the Intelligence menu options available in PCMCS.  The 6 menu options are:

Alex Mlynarzek - Analysis Views and Scatter Analysis - 2-28-19 - Image 1  1.  Analysis Views (learn how to create, customize, and use them here)

Alex Mlynarzek - Analysis Views and Scatter Analysis - 2-28-19 - Image 2  2.  Scatter Analysis (discover how to set up and configure them here)

Alex Mlynarzek - Analysis Views and Scatter Analysis - 2-28-19 - Image 3  3.  Profit Curves (this blog post focuses on Profit Curves)

Alex Mlynarzek - Analysis Views and Scatter Analysis - 2-28-19 - Image 4  4.  Traceability

Alex Mlynarzek - Analysis Views and Scatter Analysis - 2-28-19 - Image 5  5.  Queries

Alex Mlynarzek - Analysis Views and Scatter Analysis - 2-28-19 - Image 6  6.  Key Performance Indicators

The content of this blog is based on the standard Bikes (BkML30) demo application, so you can follow the step-by-step information without having to go through an app setup from scratch. You can load and deploy this application directly from your PCMCS instance through a couple of clicks via the Application menu using the + / Create button.

 

Profit Curves – What Are They?

If you are looking for a graphical representation for the concentration of your profit by either Customer, Products, Channels, or Funds, look no further than the Profit Curves section in PCMCS. Profit Curves, also referred to as Whale Curves, are used to identify which cluster of Customers, Channels, or Products generate the most profit. Profit Curves display a graphical representation of the relationship between economic profit and the quantity of output sold.

The details of the profit or net income split by unit/service/customer displayed in a Profit Curve identify issues with:

  • expansion of a production line
  • breadth of services that may have a negative impact on profit
  • onerous clients consuming numerous resources without justifying the cost for the profit gained from their engagement
  • potential costing issues of “over” or “under” costing products (for example, overburdening a product or product line inappropriately);  a cost study should be performed to determine the appropriate allocation
  • pricing

Information illustrated with a Profit Curve can be enlightening and help to put the focus on specific customers, products, or channels where the greatest profit attention is needed, indicating situations where a few products, services, or clients create enough profit to maintain the rest of the company’s offering. Profit Curves are key to strategic decision making, especially when dealing with competing projects and limited resources.

During one of my recent PCMCS implementations, a Profit Curve proved valuable when the client’s staple product, advocated as being its best and most profitable, was discovered to be the least profitable after the implementation of an accurate cost allocation methodology in PCM!

The easy-to-follow Profit Curve provides the foundational insight needed to rapidly shift gears across product lines, ensuring alignment of management decisions backed up by real information.

 

Building a Profit Curve

There are several Profit Curves available in the Demo application BksML30. In order to build a Profit Curve, there must be a corresponding Analysis View that can be leveraged as the basis for data selection. See a step-by-step guide on how to build an Analysis View here.

Analysis Views can contain multiple references to Measures and/or Accounts; however, the Profit Curve using the Views analyzes and displays only one measure at a time.  Users can choose to define names for the X and Y axis to add clarity to the Profit Curve information consumers.

Alex Mlynarzek - Profit Curves - 4-18-19 - Image 1.png

Here is an example of a Profit Curve:

Alex Mlynarzek - Profit Curves - 4-18-19 - Image 2

The curve displays a listing of Net Income generated by Customer.

From a Quarter-to-Date perspective (the Period selected at the top of the View), this Profit Curve indicates that all customers are profitable.  That may raise questions about whether or not the overhead is allocated appropriately or an even spread is used, thus skewing the results.

Note: Data in the BksML30 model at the time this Profit Curve was generated was calculated only for January, confirming the Profit Curve display, as the profit by customer distribution was evened out at Quarter-to-Date level.

The details of each customer/product/channel/segment and how much net income each is generating can be reviewed in the Category Analysis section. From a cost management and process improvement point of view, the right side is the most important.  This side generally represents customers/products/channels with a negative profit or that cost the company money.  While these customers/products/channels can’t always be eliminated, they can be watched and reviewed for pricing changes.

Using a PCMCS Profit Curve

There are options to filter data by the POV dimension, Period, or by metrics tied to Customers. For example, we can exclude from the analysis any Customers with Operating Expenses that are considered marginal. After defining the required filters, we can refresh the Profit Curve and review the newly generated pie charts.  Filters can be added to all available metrics and can be stacked up to generate any custom report.

Below is an example of the same “All Customers” Profit curve, limited to January and with a selection of all Customers who had a Net Income smaller than 1 positive unit (USD or the currency defined in the PCM model) thereby highlighting Customers creating losses.

Alex Mlynarzek - Profit Curves - 4-18-19 - Image 3

In the Details section of the Profit Curve, there is a count of 886 customers with a Net Income smaller than 1.

Alex Mlynarzek - Profit Curves - 4-18-19 - Image 4100% of the customers analyzed based on the specified criteria are unprofitable. The “Actual Profit” in this Details section can be translated into “Actual Loss” as the total accumulated value across the 886 customers is US$ -1,148,670.

If there are doubts regarding the data intersection for the remaining dimensions in the PCM model such as Product or Entity, we can analyze related information through the configuration icon located next to the “Add Filter” menu. These selections are predefined in the Analysis View that was used during the creation of the Profit Curve, and you will not be able to modify them unless you modify the underlying View.

Alex Mlynarzek - Profit Curves - 4-18-19 - Image 5

If questions are raised during the analysis on the Profit Curve screen and a list of details by Customer is requested, we have the option to launch a report from the “Analysis Links” menu under the Category section.

Alex Mlynarzek - Profit Curves - 4-18-19 - Image 6

A report in the following format will be generated to display the Customer detail records along with all the other settings defined in the Analysis View.

Alex Mlynarzek - Profit Curves - 4-18-19 - Image 7

This report can be exported in .xls format (“Export to Excel” option), and it represents a base level data dump report, in column format, containing multiple generations and references to attribute dimensions.

Alex Mlynarzek - Profit Curves - 4-18-19 - Image 8

Note: When launching this report, users must check that the parameters have transitioned correctly from the previous screen. The Period parameter, which is saved to be Quarter-to-Date on the original Analysis View used in the Profit Curve diagram, will override any other selection made during run time analysis. If there is a need to revert to a specific month before launching the Export to Excel, users will have to make this update on the Filter /POV area and perform a data Refresh.

We can make changes to the Analysis View to add further details (for example, Cost of Goods).

Alex Mlynarzek - Profit Curves - 4-18-19 - Image 9

For the 886 customers that are not profitable, we can dive deeper into their Cost of Goods data, Operating Expenses, or analyze whether or not the products sold are so heavily discounted that they no longer generate a margin.

 

Pie Charts Related to PCM Profit Curves

 

We can further analyze the resulting Profit Curve data by using the available predefined categories tied to the Attribute dimensions available in the PCMCS application, in the underlying Analysis View displayed in the adjacent Pie Chart.

Alex Mlynarzek - Profit Curves - 4-18-19 - Image 10

The available categories to display the Pie Chart data for the Profit Curve chosen are the following:

Alex Mlynarzek - Profit Curves - 4-18-19 - Image 11

When selecting the Region category/attribute, we learn that the Southeast area contains 26,07% of all the unprofitable customers.

Alex Mlynarzek - Profit Curves - 4-18-19 - Image 12

If we change the Focus of the Category to be on Top 10% most unprofitable customers by Amount vs. All Customers/Number of Customers, the following information is displayed:

Alex Mlynarzek - Profit Curves - 4-18-19 - Image 13
Alex Mlynarzek - Profit Curves - 4-18-19 - Image 14

The Pie Chart reveals that the Southeast region has the highest number of unprofitable customers both by Number of Customers as well as by Total Amount/Loss.

When adding a filter based on Customer Generation 3 which distinguishes between Department Stores and Specialty Retailers, it looks like 87.64% of the Top 10% most unprofitable customers are from Department Stores.

Alex Mlynarzek - Profit Curves - 4-18-19 - Image 15

A look at the 4th generation in the Customer dimension where we can analyze the split of the losses at Customer level indicates that one store is responsible with 65.17% of all losses within the top 10% most unprofitable Customers.

Alex Mlynarzek - Profit Curves - 4-18-19 - Image 16The Pie Chart is the only artifact that is refreshed based on the selections of the Category Analysis menu while the Profit Curve remains constant based on the selections in the POV and filter criteria.

While all users of PCMCS can generate/launch Profit Curve reports and export their associated Analysis Views, in order to create and set up a Profit Curve report, the PCMCS administrator must update the requesting user’s permissions. As with all Intelligence screens within PCMCS, the Viewer role allows the use of these artifacts, not its creation or setup.

Concluding Thoughts About OOTB Features: Profit Curves

If you have been following the posts in this blog series, you’ve become aware of the dashboarding opportunities at your disposal with a PCM subscription. The listing of PCMCS OOTB features is a good starting point for comparing any other profitability and cost management tools on the market, regardless of vendor and technology employed.

Creating insightful dashboards is now at the tips of end users’ fingers, no longer involving complex requirements gathering processes and iterating between different display options. PCMCS users have the ability to build and customize their own dashboards. As a result, IT staff is no longer burdened with reporting requests or artifact migration between environments.

Subscribe to our mailing list for updates on the next blog post covering Traceability, Queries, and KPIs. Don’t think the PCMCS OOTB features blog series will stop at the Intelligence menu options! There is more to come on Model Validation, System Reports used for maintenance and troubleshooting, Integration with Cloud Data Management, and the Application Backup and Restore functionality. All this and more will be covered in future blog posts, so watch this space for updates.  If there is a PCMCS-related topic that you would like to see covered in more depth, email us at infosolutions@alithya.com.

EDMCS and Data Governance – Part 3

Welcome to Part 3 – the finale – of the blog series “EDMCS and Data Governance!”

Part 1 provides an introduction and primer for data governance workflows in Enterprise Data Management Cloud Service (EDMCS) which was introduced in the 19.02 release.

Part 2 discusses Workflow Stages in greater detail and dives into the brains of EDMCS workflows – the Approval Policy. Approval policies at different levels of the data chain are explained, and we conclude by building a sample workflow at the dimension level.

In Part 3, I’ll attempt to tie a bow around everything and offer some parting thoughts.

Recap

As I continue to explore and learn about collaborative workflows in EDMCS, these are the key points that come to mind:

  • Emphasize the Fundamentals – No matter what tool you are using, People and Process are extremely important in any data governance solution along with strong executive sponsorship and robust change management.
  • Build the Foundation – get the client comfortable with the tool and content before you introduce workflows. A strong foundation (your applications, dimensions, views, and viewpoints) is needed before you start the plumbing and wiring (workflows).
  • Brush up on Security – I haven’t discussed security extensively in this blog series, but the Oracle EDMCS User Guide does a nice job describing security requirements for assigning and approving workflow requests. Note that security enhancements have been introduced along with workflows. A new “Submitter” permission is now available to go along with Owner, Data Manager, and Browser. And permissions can be assigned at the Application, Dimension, Hierarchy Set, and Node Type levels.
  • Ponder the Approval Policy – this is the most interesting one to me. As we discussed in Part 2, approval policies can be defined at 4 points in the data chain (see Figure 1). With the inheritance and inter-dependencies of approval policies across the data chain along with the actions each policy can govern, it is critical to efficiently design your approval policies up front.

o   For example:

  • Suppose your client requires a final “audit” type of approval across the board for any type of request for any dimension. Or they always a require an upfront “gatekeeper” type of approval to make sure the request is justified and complete before it continues down the approval chain. These would be good candidates for an approval policy at the Application level. And it would avoid having to define duplicative approval policies at lower levels in the data chain.
  • Will your application contain dimensions that do not need data governance workflows? Then Application level approval policies should be avoided.
  • Say you want to limit and govern the actions of a specific group so it can only work with existing nodes (insert, remove, update). An approval policy at the Hierarchy Set level is probably best.

o   Overall, I believe approval policies at the dimension level are a good place to start. Then as the workflows evolve and requirements become more clear, you can determine if there are common factors across all dimension approval policies that can be consolidated at a higher level (Application level approval policy), or if there are specific subsets of actions that need to be broken out to a lower level (Node Type or Hierarchy Set level approval policy).

o   All of which brings up another interesting point: effective approval policy design directly ties into effective viewpoint design. Think about it – you can define the set of Allowed Actions (Add, Insert, Move, etc.) at a Viewpoint level. Which means what? Special-purpose maintenance views are likely required to support certain approval policies, especially those at the Node Type or Hierarchy Set levels.

Figure 1 – Approval Policies and Data Chain

EDMCS and Data Governance – Part 3 - Image 1

How do EDMCS Workflows Compare with DRM/DRG?

I was reluctant to include this section at first because in general, I don’t like comparing Data Relationship Manager (DRM) and EDMCS. Yes, they are both master data management tools and yes, they do share some common concepts and terminology. But overall, the two products are so different in terms of philosophy, deployment design, and underlying architecture that I think comparing the products is often less than helpful.

However, with data governance and collaborative workflows, I feel there is enough commonality that it is worth highlighting a few items. So here goes:

Topic DRM/DRG EDMCS
Workflow Design
  • Based on workflow models and workflow tasks
  • Tasks linked to specific actions (Add Leaf, Add Limb, Insert, Move, etc.)
  • Based on Approval Policies
  • Approval policy level (Application, Dimension, Node Type, Hierarchy Type) determines context and scope of actions governed

 

Workflow Stages
  • Use a Submit stage, a Commit stage, and optionally, one or more Enrich and/or Approve stages
  • ·Use a Submit stage and (implied) Commit stage
  • Approval policies determine approval stages (sequential vs parallel, # of approvers)
  • Requests can be re-assigned for collaboration prior to Submit
User Interface (UI)
  • Form-based design
  • No forms
  • Requesters and approvers interact directly with the viewpoints
Approval Options
  • Support Approve, Reject, and Push Back
  • Support comments, narrative, attachments
  • Support Approve, Reject, and Push Back
  • Support comments, narrative, attachments
Escalations
  • Requests can be escalated based on defined intervals
  • Requests can be escalated based on defined intervals
Separation of Duties
  • Workflows can be configured to prevent a submitter from approving their own request
  • Workflows can be configured to prevent a submitter from approving their own request
Email Notifications
  • Generates email notifications
  • Generates email notifications
Other
  • Supports conditional workflows
  • Supports splitting of requests based on pre-defined criteria
  • Not yet supported

I’m curious if Oracle will introduce a form-based UI for workflows. Part of me would very much like to see that so that you can present a clean user interface to the approvers, hide unnecessary details, and display special instructions and messages, but part of me does not. One of my favorite features of EDMCS is the visual highlighting of pending request changes and the “shopping cart” of request items that are displayed prior to submitting a request. I would hate to lose that by going with a forms-based workflow UI, but perhaps there is a solution that combines the best of both worlds. 

Conclusion

Well that’s it, an initial look at workflows and approval policies in EDMCS. I’m excited to see how this functionality evolves and expands over time. Talk to you next time!

And don’t forget to follow me on Twitter (@kblackEPM) and check out these links for more information:

EDMCS and Data Governance – Part 2

Welcome to Part 2 of the blog series “EDMCS and Data Governance!”

Part 1 provides an introduction and primer for data governance workflows in Oracle Enterprise Data Management Cloud Service (EDMCS) which was introduced in the 19.02 release. This exciting feature addresses a major gap in EDMCS as the product continues to rapidly evolve and mature.

In Part 2, we dive into the details of how to configure workflows. This process revolves around the concept of an “approval policy.” Interestingly, approval policies can be configured at different points of the EDMCS data chain and cascade or inherit to affect downstream points of the data chain.

Workflow Stages

Before we dive into approval policies, let’s discuss EDMCS workflow stages a bit more. They are similar in concept to Data Relationship Governance (DRG) workflow stages. See Figure 1 for an overview:

Figure 1 – EDMCS Workflow StagesEDMCS and Data Governance – Part 2 - Image 1
  1. Submit (or Assign) Request – A request is initially created as you do today. But wait…there’s more! You can Submit the request to immediately move the request into the Approve stage OR you can Assign the request to colleagues to collaborate on the request together. When the request is ready, it is submitted to move to the Approve stage.
  2. Approve Request – The approver(s) have 3 choices:
    • Approve – the request is approved and moves forward (thanks Captain Obvious!).
    • Push Back – like DRG, the request is pushed back to the submitter for clarification or changes, who then updates and resubmits the request.
    • Reject – like DRG, the request is denied and closed. Think of “reject” as the RAID of the data governance world – it kills requests dead.
  3. Commit Request – once fully approved, the request is auto-committed and closed. EDMCS has now been updated.

Approval Policies

Now for approval policies. Approval policies can be configured at 4 levels:

  1. Application
  2. Dimension
  3. Node Type
  4. Hierarchy Set

It is important to note that each data chain object can contain one, and only one, approval policy. However, approval policies have a cascading impact so that multiple approval policies can work in concert to govern and control exactly what you want. Yes, you heard that right:  Approval Policy Inheritance – it’s not just for properties anymore!

The types of actions governed by an approval policy depend on the data chain object it is configured with – see figure 2 below:

Figure 2 – Approval Policies and Data Chain

EDMCS and Data Governance – Part 2 - Image 2As you can see, policies defined at the Application or Dimension level govern all actions (add, delete, insert, remove, move, etc.) while policies defined at the Node Type or Hierarchy Set level govern a subset of actions. Why is this important? Because it means you need to carefully design what types of actions you want to govern and who will perform them. If I define an approval policy at the Hierarchy Set level and then submit a request that Adds 3 accounts, how many approvers are required for the request? A big ZERO! Since I requested “add” actions and only have an approval policy at the Hierarchy Set level, no applicable approval policy exists to govern the request.

Putting It All Together

Let’s walk through an example.

  1. Define Approval Policy

First, I will define an approval policy for the Account dimension. To do this, Inspect either the application or default viewpoint and access the Account dimension from the Definition tab. From there, click the Policies tab.

Here you will see the Approval policy for the Account dimension. Click on the Approval link to inspect the approval policy.

EDMCS and Data Governance – Part 2 - Image 3The General tab will display basic information about the approval policy. You can edit the approval policy name and description if necessary.

EDMCS and Data Governance – Part 2 - Image 4The Definition tab is where the magic happens. Select edit to update the following parameters:

  • Enabled – click this check box to enable the approval policy.
  • Approval Method – select Serial or Parallel.
  • One Approval Per Group – if using Serial approvals, this will automatically be set to “True.” If using Parallel approvals, you can select one approval per group or define a Total Required # of approvers.
  • Include Submitter – enable this to allow the submitter to also be an approver (the submitter’s approval will be automatically granted). If “separation of duties” is required for your company, do not enable this.
  • Reminder Notification – the # of days that will elapse before reminder emails are sent.
  • Approval Escalation – the # of times a reminder occurs before an escalation email will be sent.
  • Approval Groups – select user(s) and/or group(s) to be included in the approval process. When using Parallel approvals, the order of approval groups does not matter. When using Serial approvals, the order of approval groups does matter – you need to list the approval groups in the order that approvals should be executed.

With my example approval policy, I am using serial approvals, 2 approval groups (a Planning group and GL group), a reminder interval of 5 days, and an escalation interval of 2 reminders.

EDMCS and Data Governance – Part 2 - Image 5

  1. Submit Request

Now we’re cooking with gas. It’s time to submit a request. I will submit a request to my default Account viewpoint that includes 1 add, 1 property update, and 1 move. Here is the request in Draft status:

EDMCS and Data Governance – Part 2 - Image 6

Did you notice something new? Look at the Actions button next to Submit. This is where you can assign the request to another user and collaborate with him to finish up the request.

EDMCS and Data Governance – Part 2 - Image 7

EDMCS and Data Governance – Part 2 - Image 8

  1. Approve the Request

After the request is submitted, it is considered “in flight” because it has been submitted, but not yet approved/committed. And look! EDMCS now offers a nice Activity page on the home screen displaying the status of various workflow requests:

EDMCS and Data Governance – Part 2 - Image 9

First, the users in the Planning Approvers group will receive an email notifying them that they have been “invited to approve a request” (it’s very polite):

EDMCS and Data Governance – Part 2 - Image 10

As mentioned earlier, an approver has 3 choices: Approve, Reject, or Push Back. Reject and Push Back are available under the Actions dropdown. Here are the dialog windows that will be displayed for those actions (note the comment field is required):

EDMCS and Data Governance – Part 2 - Image 11

Otherwise, the approver will click the Approve button and see this:

EDMCS and Data Governance – Part 2 - Image 12

And then the same process will continue with the GL Approvers group since I am using Serial approvals. Once again, an approver can reject, push back, or approve. Once approved, the request is committed and closed.

Congratulations! You have now completed your very first data governance workflow request in EDMCS!

Conclusion

This blog post should be useful in providing more details and clarity on workflows, workflow stages, and approval policies. In the third and final post for this series, I’ll offer a recap and some closing thoughts. Talk to you then.

Read the next post in this EDMCS blog series:  EDMCS and Data Governance – Part 3

And don’t forget to follow me on Twitter (@kblackEPM) and check out these links for more information: