| Panel | |
|---|---|
|
...
📽️ Check out a video demonstration for this use case, here.
| Panel | ||
|---|---|---|
| ||
Use Case Situation Description |
Enhanced profitability through cost-to-serve analytics KPIs offers precise insights into operational costs, enabling targeted optimizations. This leads to streamlined processes, resource allocation, and pricing strategies, aligning with customer needs. Improved cost recovery boosts margins while maintaining customer satisfaction, ultimately elevating profitability.
| Expand | ||
|---|---|---|
| ||
Pricing Analyst/Manager (primary) / Product or Finance Manager (secondary) Business Objective: Chemicals companies closely track their customer cost-to-serve (CTS). The core elements of this are freight, warehouse, packaging, and services. If a customer requires value-added services (e.g. special packaging) they need to pay for this extra cost (also called cost recovery). These costs change over time, but they are not always actively managed. Pricing teams will look to decrease margin compression by actively seeking out underperformance in cost-to-serve elements across their portfolio. |
| Expand | ||
|---|---|---|
| ||
· Availability of cost-to-serve data at a customer/transaction level · Visibility of cost data (e.g. data table, comparative waterfall, or heatmap) · Visibility at a ship-to level (e.g. freight cost understanding requires ship-to detail) · Timing of receipt of cost data so it is accurate and allocated correctly · Ability to move to action immediately once issue identified |
| Expand | ||
|---|---|---|
| ||
Dashboard o Data table with customer level ship-to CTS details (outliers / trending) o Time series at individual customer ship to and product category level (trending) o Comparative waterfall (showing average to single customer) o Heat map (showing CTS variation by product group, region, market…) o Pie chart – negative margin impact of each CTS category |
| Expand | ||
|---|---|---|
| ||
· Reduce margin compression over time with out-of-date CTS adjustments/costs · Increase margin by identifying underperformance / action on high CTS customers · Establish norms for cost recovery for future price setting processes |
| Expand | ||
|---|---|---|
| ||
· Cost recovery (total, by CTS category, by product/customer/region category |
| Expand | ||
|---|---|---|
| ||
· Cost recovery = CTS adjustments – CTS costs |
| Expand | ||
|---|---|---|
| ||
Cost recovery (freight, packaging, services) by product category and region  |
| Panel | ||
|---|---|---|
| ||
Prescriptive Design Requirements |
As a [Pricing Manager/Sales Rep], I want to have the ability to get access to cost-to-serve category tracking metrics, so I can:
Get visibility on cost-to-serve elements performance
Identify quickly cost recovery improvement opportunities
Manage and improve cost-to-serve strategy more frequently based on data decisions support
Improve business contribution margin
The overall design requirements are summarized in these articles.
...
| |
Business Use Case SummaryCost Recovery DashboardThis use case fills a the need for a system that provides access to cost-to-serve category tracking metrics. The primary purpose of this functionality is to enable users to gain comprehensive visibility into the performance of various cost-to-serve elements. When accessing such insights, users can quickly identify areas where cost recovery can be improved, allowing for more efficient targeting of opportunities. The solution aims to support more frequent and data-driven management and improvement of cost-to-serve strategies. Ultimately, this capability is designed to contribute to the overall improvement of the business's contribution margin by enabling more informed and timely decision-making based on accurate cost-to-serve data. |
🎯 Business Objectives
Cost recovery optimization
Margin improvement
Data-driven decision making
⌚ Time Estimation
Estimation Assumptions (based on in scope / out of scope items):
Data is available prior to the start of the build phase and functional data elements – filters, aggregations, etc. have been isolated and verified with the customer.
Relevant measurables – cost-to-serve elements – have been identified and are measurable and have the necessary data available (costs and charges)
Data has the necessary orientations (described in “Input Data”) – i.e. – cost to serve element impacts are broken out by transaction line item
Any thresholds that will be used to “traffic light” various metrics will be hardcoded, not parameterized
The “base case” charts and calculations can be used as is
No integration is considered to be part of this use case
1 sprints/1FTE CE
👥 Stakeholders
The cost-to-serve analysis dashboard serves sales representatives and pricing managers who monitor cost recovery and identify improvement opportunities. Business analysts and finance team members utilize the data for in-depth financial analysis. Product managers, regional managers, and customer segment managers gain insights specific to their domains. Admins ensure data integrity and application functionality, while executives leverage the dashboard for strategic decision-making on cost management and pricing strategies.
Business Context (Use Case Description)
This section outlines the functional requirements for a cost-to-serve metrics dashboard. The point is to collect and display up-to-date predefined metrics with adjustable granularity through various filters. Users can select time periods, customer attributes, product attributes, and currencies for display. The dashboard features four main portlets: Margin Impact, Recovery Heat Map, Recovery Trend, and Recovery Data Table. These portlets provide detailed breakdowns of cost recovery completeness, opportunities, and status across different categories. This allows for aggregation by selected attributes and includes a health indicator for recovery percentages. Additionally, it offers the functionality to download portlet data in various formats such as PNG and PDF.
Ability to get a dashboard where up-to-date predefined cost-to-serve metrics are
...
collected
Ability to switch level of granularity of the reporting using
...
filters
...
The dashboard has the following filter options:
Ability to select a time
...
period
Ability to filter on some Customer attributes, including Ship-
...
To
Ability to filter on some Product
...
attributes
Ability to select a currency for the values displayed in the
...
portlets
Ability to select an aggregation metric that will show Margin Impact and Recovery Data (in the table portlet) breakdowns by the selected
...
attribute
Features and Capabilities (Overview)
| Panel | ||
|---|---|---|
| ||
The dashboards below provide Pricing Managers and Product Managers with comprehensive insights into the impact of various factors.
|
...
Margin Impact |
...
Occurring recovery completeness and recovery opportunities expressed in margin absolute |
...
value |
...
Recovery Heat Map: Cost recovery expressed in percentage (by Country v/s Product Line)
...
Recovery TrendRecovery evolution trends over time (month, with potential to change this period type) per cost-to-serve category Recovery Data Table |
...
Recovery status overview per cost-to-serve category with Total Cost, Total Charge (to customer) and Recovery % for each cost-to-serve metric. A “health indicator” will also show any recovery % metric that falls into certain % thresholds in three traffic light (green, yellow, red) tiers. |
...
|
...
Non-functional requirements
Automatically updated metrics in the dashboard
...
| title | Reporting and Dashboards |
|---|
...
|
...
|
...
|
...
| title | Measures, Calculation and Decision-making KPIs |
|---|
...
Total Charge (per Cost-to-serve category): Is considered as “charge” the part of the cost-to-serve value that has been invoiced (charged) to the customer.
...
Total Cost (per Cost-to-serve category): Is considered as “cost” the part of the cost-to-serve value that is supported by the company.
...
Margin impact = Total Charge – Total cost. If delta >0, the margin impact is positive, else it is a margin lost. (See additional details in the user story)
...
| title | Scope Validation and Project Readiness |
|---|
During scope validation process we are ensuring that the project deliverables are completed according to the agreed scope and quality standard by asking the following questions:
...
Scope Validation and Project Readiness Workshop – Validation Questions & Answers:
...
Q1: How many cost-to-serve categories do you usually manage?
A1:
...
Q2: Where is your data stored?
A2:
...
Q3: What is the level of aggregation of data?
A3:
...
Q4: Are your transactions data enriched with those cost-to-serve elements details?
A4:
| Panel | ||
|---|---|---|
| ||
User Stories |
These are the user stories that make up this use case.
...
| title | Epic: Inbound data |
|---|
As a Pricing Manager/ Analyst I want to access transactional and historical data so I can use it throughout the application.
User Story Name - Costs data
I want to: Have access to Costs Data
so I can: Use them throughout the application and especially for my cost-to-serve analysis dashboard
Acceptance Criteria:
Costs data are available in the transactions data set
Already covered by CHEM00, a prerequisite for all CHEM Use cases, and thus for CHEM06.
User Story Name - Customers Data (and Ship-to data)
I want to: Have access to Customers Data (and Ship-to data)
so I can: Use them throughout the application and especially for my cost-to-serve analysis dashboard
Acceptance Criteria: Customers data and Ship-to are available in the transactions data set
Already covered by CHEM00, a prerequisite for all CHEM Use cases, and thus for CHEM06.
User Story Name - Historical Transactions data
I want to: Have access to Historical Transactions data
so I can: Use them throughout the application and especially for my cost-to-serve analysis dashboard
Acceptance Criteria:
Transactions Data must be enriched with Ship-To details and cost-to-serve elements details (costs and charges)
This baseline functionality / Use case covers up to 5 cost-to-serve elements.
Already covered by CHEM00, a prerequisite for all CHEM Use cases, and thus for CHEM06.
...
| title | Epic: Dashboards |
|---|
As a Sales Rep/Pricing Manager I want to have a dashboard available that I can use to monitor the cost recovery per cost-to-serve element.
User Story Name - Dashboard filter
I want to: Filter the scope of my cost-to-serve analysis
so I can: Identified outline opportunities
Acceptance Criteria:
Fields to filter on are:
From & To Date
Account Group: Ship-To
Industry
Continents
Countries
Regions
States
Customer Segments
Customer Names
Product Lines
Product Groups
Target Currency
View Recovery By
User Story Name - Dashboard Generic filter
I want to: Use a generic filter
so I can: Create an advanced filter with a complex query to filter the scope of my cost-to-serve analysis
Acceptance Criteria: Generic filter option is enabled in the dashboard
User Story Name - Margin Impact Pie chart
I want to: See what the actual negative margin impact of each cost-to-serve category is
so I can: Plan corrective actions accordingly
Acceptance Criteria: Displayed metrics are the following:
Total Recovery amount per dimension.
Total Recovery amount is equal to the delta between the Costs and the Charges. If Charges - Costs >0, margin impact is positive, else it is a margin lost.
o Dimension to be selected in the “View Recovery By” option in the dashboard filter menu.
o Value currency corresponds to the Target Currency selected in the dashboard filter menu.
Each sector of the pie chart shows the total margin impact by the selected dimension. (I.e., If the selected dimension is “Country” then the pie chart shows the total margin impact by each country.)
Each sector is clickable
When clicked, the user can access the margin impact breakdown per cost-to-serve category for the dimension clicked. In our example by Country, we will get the breakdown for a particular country.
Recovery Amount:
Is taken from the value of Total Recovey Delta:
Total Recovery Delta is calculated with the formula:
SUM (Charge Field) - SUM (Cost Field)
Recovery Breakup with Margin:
It is calculated with the formula:
If the value for Total Recovery Delta is greater than or equal to zero:
grossMargin – totalRecoveryDelta
If the value for Total Recovery Delta is less than zero:
grossMargin + totalRecoveryDelta
where:
Gross Margin is taken from Transactions data with the formula:
SUM (Gross Margin)
Total Recovery Delta is calculated with the formula:
SUM (Charge Field) - SUM (Cost Field)
User Story Name - Recovery heatmap
I want to: See the cost-to-serve recovery percentage variations per Country v/s product line
so I can: Identifiy outline opportunities
Acceptance Criteria: Displayed metrics are the following:
cost-to-serve recovery percentage variations per Country v/s product line
Recovery percentages are depicted by color
User Story Name - Recovery Trend Time series
I want to: See the cost-to-serve recovery percentage variations per cost-to-serve category
so I can: Identify outline opportunities
Acceptance Criteria: Displayed metrics are the following:
cost-to-serve recovery percentage trend per cost-to-serve category
Total Charge per cost-to-serve category
Total Cost per cost-to-serve category
All cost-to-serve category are clickable to be analysed independently
User Story Name - Recovery Data table
I want to: See the cost-to-serve recovery
so I can: Identified outline opportunities at the lowest level of detail
Acceptance Criteria: Displayed metrics are the following:
cost-to-serve recovery percentage trend per cost-to-serve category
Total Charge per cost-to-serve category
Total Cost per cost-to-serve category
Metrics are displayed at any level of granularity available in the filter option “View Recovery By”
| Panel | ||
|---|---|---|
| ||
Data Requirements |
|
| Panel | ||
|---|---|---|
| ||
Prerequisites for PDR ImplementationThe following tables can be either manually loaded in Pricefx via Pricefx Excel Client or can be automatically integrated using CSV files in a Pricefx dedicated SFTP folder: |
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
| Panel | ||
|---|---|---|
| ||
Out-of-Scope |
Out-of-scope business functions and features can be configured, but are not included in the Chemical Industry Catalog.
Any metrics reporting other than the ones explicitly mentioned above
Any customization
Additional filters
User entitlement of the dashboard
Data integration
| Panel | ||
|---|---|---|
| ||
Solution Design |
...
Costs to serve elements details (both Costs and Charges) must be part of the transactions data set and available at transaction level.
...
The transactions data set must be enriched with Ship-To details as well.
...
|
Limitations and Risks
Data formats:
As all the portlets from this dashboard will be using data from the Transactions data set
...
The cost recovery percentage will be calculated on the fly based on the selected filters applied in the dashboard.
| Expand | ||
|---|---|---|
| ||
The technical design for this use case incorporates one or more elements depending on the nature of the customer’s data:
o Dashboard filters, which can potentially vary, but the core filter fields must exist in the source datamart o The 4 core charts in the dashboard |
| Expand | ||
|---|---|---|
| ||
The dashboard should be based off a single Datamart that contains sufficient data to cover all the core requirements. It is worth noting that cost-to-serve data should be broken down to the transaction level in order to complete most of this use case design, but in particular it is necessary for the 4th portal – at the breakdown level. This means that the cost to serve data must be available at a per transaction basis and allocated out to each transaction data row, so that when the dashboard filters are applied, or data is aggregated, it can be split appropriately amongst transactions to provide an accurate view. Any cost to serve element will need to account explicitly for both the charges (revenue from customers) and cost (cost to serve) in order for the value to be shown in the dashboard. |
| Expand | ||
|---|---|---|
| ||
The need for data enrichments depends heavily on how the customer’s data is provided and set up. A core aspect of the solution for this use case is the level of granularity of the data. In order for data to be properly filterable to the use case, the cost to serve data elements must breakdown at the transaction line-item level. If the native data does not have that set up, data enrichments will be required. As an example, cost to serve elements might be tracked in a separate system (possibly not even ERP) and might be aggregated as an amount at the customer level based on a time period (like a month). This would mean that the total cost-to-serve for that customer / month would need to be allocated to each transaction line item appropriately so that data can be filtered and reflect accurate numbers. The specificity of how these elements are allocated to each transaction line item, though, can impact how accurate the metrics will be. To further the example The ”base case” for this use case assumes no data enrichment is necessary. |
...
| title | Dashboard logic |
|---|
Standard charts vs. high charts – this design focuses on the use of HighChart charts. Though those rely on the configuration to provide the data, this use case still assumes the use of all data being consolidated in a single Datamart.
It’s generally good practice to include a Constants element at the top of the logic to allow commonly used variables to be easily edited. Constants classes are commonly used in OO programming to allow common changes – like table names or field names – to be altered easily without having to make the change in many places. Library methods can be created in this element or a separate “Library” element as well.
Any number of filter inputs can be added, as well as an aggregation selector (select one of the filter fields) that can be used on the Margin Impact and Recovery Data Table. The fields used in the filters and for the aggregation must exist in the source Datamart, but otherwise there are no serious concerns.
Pulling in the cost recovery data basically means grabbing the transactions that meet the filter criteria. Creating the recovery metrics requires that all the charge data (revenue) and all the cost data (cost to serve) for each cost to serve element and then dividing the charge amount by the cost amount to reach the recovery percentage. Stoplight thresholds for coloration of the cells in the Recovery HeatMap and the coloration of the Status elements can be based on hard-coded or parameterized (in a Parameter table) for ease of adjustment.
Four kinds of charts are created in this dashboard:
...
Margin Impact – a pie chart that shows the pie as the total recovery amount and divides the pie by that total amount using the selected aggregation dimension.
...
Recovery HeatMap – a heat map chart that shows the total recovery percentage based on two dimensions – business unit and regionality in Pricefx’s demo example, but whatever metrics are considered by the customer to be the most useful are fine choices. The cell color can be driven by whatever thresholds for the recovery percent the customer prefers.
...
Recovery Trend – this bar/line chart shows bars and lines that depict the costs and charges for each cost to serve element as stacked bars as well as the trend lines representing recovery percentage from period to period. The recovery % calculation is the same as elsewhere in the dashboard. The time period to be shown in the chart can be customized, but performance will degrade the more history is required. This should be made clear when making the decision on the orientation here.
...
| Panel | ||||||
|---|---|---|---|---|---|---|
| ||||||
Out of Scope |
While there may be available features and customization based on customer requirements, the following are out of scope for this use case.
Metrics reporting beyond those mentioned above
Customization
May be done but it is out of scope for this use case and subject to discussion in terms of effort.
Additional filters
Additional filters outside what is OOTB are out-of-scope
User entitlement of the dashboard
Data integration
Any additional data transformations or integrations required to make data available needs to be considered as an additional configuration effort.
Terms and Definitions
| Info |
|---|
For common terms → Business User Glossary here and Developers here. |
| Panel | ||
|---|---|---|
| ||
📽️ Check out a video demonstration for this use case, here. |