PM 03 - Prescriptive Delivery Requirements (PDR) Overview

Owned by Mike Deskis
Last updated: Sept 03, 2024 by Ioana Kocurova
17 min read

For a similar and more updated use case see PM04.

Check out a video demonstration for this use case, here.

Use Case Situation Description

Real-time market/cost/value pricing models enhance spot price target achievement in the process industry by optimizing pricing decisions. These models utilize up-to-the-minute market data and cost analysis, leading to accurate pricing adjustments. This improves profitability by maximizing revenue during price fluctuations and minimizing losses. Additionally, it enhances competitiveness, fosters better customer relations, and supports data-driven strategic planning, ultimately resulting in improved financial performance and overall operational efficiency.

Pricing Analyst/Manager

Business Objective:

Spot pricing is utilized for customers who a) do NOT have a long-term pricing agreement (e.g. smaller customers or companies who do not need to guarantee supply) or b) who do have an agreement but are purchasing outside of their contract (e.g. buying products not covered by a contract / buying quantities above their negotiated volume).

Spot customers negotiate a short-term (e.g. monthly / quarterly) price and quantity schedule based on a “spot-price.” This business is planned out using an annual operating plan (AOP). Financial forecasts are created based on selling at defined volume / price / cost (margin) assumptions. Periodic price changes occur during the year based on market conditions (cost changes), market demand (supply vs. demand vs. alternatives), and other factors. As changes in business conditions create a gap between expected and project earnings performance chemicals manufacturers evaluate and implement pricing actions per portfolio, geography, customer segment, and competitive status, so performance meets or exceeds financial targets.

  • Spot price changes occur frequently (daily/weekly/monthly) per market segment

  • 3rd party reference data needs to be updated frequently (daily/weekly/monthly)

  • Calculating and communicating updated pricing is time-consuming and error-prone

  • Notification requirements and price protection rules are complex and time-consuming

  • Evaluating potential impact to price actions is complicated and requires scenario tools

  • Flexible spot pricing interface accounting for margin by product, market, and geography

  • Real-time pricing updates based on new input triggers and recalculation logic

  • Connection to 3rd party market, cost, and cost-to-serve data

  • Impact modeling based on updated data, forecasts, and other scenario modeling

  • Connection to ERP or other system to publish/execute updated customer contract pricing

  • Increase margin due to more frequent and faster spot price updates

  • Increased margin with decision support, simulation, and profitability forecast modeling

  • Reduced margin compression with reduction in manual errors and timely pricing updates

  • Higher margin improvement and price realization due to more frequent price changes

  • Margin improvement due to more effective targeting of mass price changes

Prescriptive Design Requirements

Primary:

As a Pricing Analyst / Manager, I sometimes have to use spot-pricing with customers who either:

  • Do NOT have a long-term pricing agreement (e.g., smaller customers or companies who do not need to guarantee supply)

OR

  • Do have an agreement but are purchasing outside of their contract (e.g., buying products not covered by a contract / buying quantities above their negotiated volume).

Spot customers negotiate a short-term (e.g., monthly / quarterly) price and quantity schedule based on a “spot-price.” This business is planned out using an annual operating plan (AOP). Financial forecasts are created based on selling at defined volume / price / cost (margin) assumptions. Periodic price changes occur during the year based on market conditions (cost changes), market demand (supply vs. demand vs. alternatives), and other factors.

As changes in business conditions create a gap between expected and project earnings performance, as a Pricing Analyst / Manager, I must evaluate and implement pricing actions per:

  • Portfolio

  • Geography

  • Customer segment

  • Competitive status

So, their performance meets or exceeds financial targets.

The overall design requirements are summarized in these articles:

The following showcase the user stories for this use case.

Core Pricing Data Requirements

As an underlying standard practice, prices for Chemicals products are adjusted according to a certain number of components:

  • Raw materials index:

    • each product do not refer to only one raw material but rather to a combination of multiple raw materials that are volatiles over time.

    • the weight of each component required to produce one Product id is specified into the BoM table

    • The Raw materials indexes are stored monthly in the “RawMaterialIndex” Company Parameters table

    • Those indexes are populated in the LPG and correspond to the “raw material baseline” column corresponding to each raw material.

  • Packaging type

    • each packaging type as a weight in ton defined in the “tonPackagingWeight” Company Parameters table

    • the packaging costs and warehousing will be both defined based on the packaging type in the “PackagingCosts” and “WarehousingCosts” Company Parameters table corresponding.

  • Product group

    • to keep it simple, we have selected a “Cost+” approach for all scenario, however, the Cost + markup will vary by Product Group

    • either the product is a commodity product or a specialty product

      • some “Cost +” markup will be used to set the price

  • Market area / End-use

    • some price up-lift by market area are defined in the “MarketAreaAdjustment” Company Parameters table

    • Often in chemicals, prices vary according to the end-use.
      Instead of defining price variation according to the Industry of the end user, we have defined 3 different levels, 3 different market areas that are somehow reflecting the willingness to pay of the end-user : Low, Medium and high.

    • Those “Market area” are used in the LPG as a secondary key. Thus, all prices for all market areas, that means all prices for each scenario are calculated. Consequently, we have 3 different rows for 3 different prices for the same product according to the Market Area.

LPG Calculation Logic Data Requirements

NOTE: There have been no out-of-scope functions or features identified at this time.

Core to this use case is the concept that there is no established pricing agreement in place for the prices that are being managed. Essentially the pricing for these scenarios is not covered by contracts or other existing deals, and pricing may be based on a formula (and must be to allow automated price changes) or may not be and may be set based on some arbitrary concepts.

Prices will be managed using live price grids or price lists, depending on the granularity of the pricing action that will be used and how pricing is managed. For purposes of this design, we’re assuming that live price grids (LPGs) will be used.