CHEM03: Improve spot price target achievement with real-time market/cost/value pricing models

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

• Margin improvement = CM2 (new pricing) – CM1 (old pricing)

For this use case, the functional requirements are separated into these categories:

Complication:

• 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.

Capability Needed:

• 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.

Benefit:

• 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

KPI:

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

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

Core Requirements

• Spot pricing can be managed in several different ways:

  • Explicitly set pricing – when the spot pricing is created, the pricer sets a price for the product. Unless all price adjustments are manually maintained or pricing expires in a set period, there would need to be some formula or approach for how the spot prices would change over time. In this case, the initial price would need to be provided by a user and would then would be managed by pricers in this use case. Negotiated prices might fit into this category.

  • Formula-based pricing – the prices might be set based on raw material or/and index based factors – either market or cost based calculations. This is likely the more common approach, but would need these formulas, formula components and formula calculations defined in order to make it work. If this is the desired functionality, the concepts from use case 1 should be used here to define and manage formulas. This use case would handle the ongoing management of the prices based on those formulas. This would include more list-like pricing, but could also include negotiated pricing with a cost plus or market index adder, similar to use case 1.

• Spot pricing can be maintained at various levels:

  • Spot prices can be set for any individual product (sku) in the product master.

  • Spot prices will generally have at least one other dimension:

    • Customer attribute or grouping (not individual customer level)

    • Region or geography

    • Business unit / distribution channel

    • Some other grouping factor

  • Spot pricing will almost certainly need to have several prices per product on the basis of the additional granularity factors above. However, prices should be mutually exclusive (only one price can apply to a given situation) or have a distinct hierarchy to define which price should be selected (based on the attributes) when there are conflicts.

• Spot pricing will need the ability to manage and adjust prices along defined approaches.

  • Pricing should be separated by key segments or categories (product attributes, customer attributes, regions, etc.) that are maintained and adjusted together.

  • Prices should be stored and visible in a price setting object that allows users to make mass adjustments to these prices.

  • Mass price changes should be able to be made along various attributes of the product, customer group, region or other factor. This should be defined by the key pricing factors of the customer.

  • Mass price changes should include being able to add an (currency) amount or percentage to a price as a part of an individual product or mass price change. The price should be adjusted by this amount and be held for approval.

  • Additional price change approaches (outside amount / percentage changes) can be possible but would require specific requirements.

  • When prices are anchored to costs or market indices (or other time-bound factors), it should be possible to automated price changes.

    o Automated price changes must have a basis in factors that are updated on some time interval or be tied to regular price changes (i.e. - +5% every year, etc.)

  • Automated price changes should adhere to a schedule, set at the same levels (defined above) that the prices will be managed, that dictate when new price factors should be picked up and the price recalculated.

  • The price changes should trigger in the designated time windows and recalculate prices and make them available for approval.

• A user should be able to make a product (individual sku) level price change as a direct override – entering a new price for the product – a manual override of the price.

• Price protection agreements should be able to be set up along the same levels (defined above) as price are managed (i.e. – customer groupings, distribution channels, etc.). These agreements should prevent prices from changing until the specified agreement date has completed.

  • Price protection agreements can be set up only at the same level as the prices are created. An agreement with an individual customer can’t be managed if the agreement is at a customer group level.

  • The price protection should allow a user to set a date for the validity and immutability of the price – meaning regardless of any changes, that set of prices cannot change until that date has passed.

  • Any changes that also cover the protected price(s) should not take effect until the protection agreement’s expiration date. At that point, they should be made available for approval.

Non-Functional Requirements

None

The following are the primary KPIs and useful metrics for this use case:

Result Price - Floor Price

= result price chemicals + Floor adjustment

= (Base price + warehousing costs + packaging cost) + Strategy selection + Market area adjustment +

Floor adjustment

Margin - Floor Price

= “Result Price - Floor Price” - Total Variable Costs

= “Result Price - Floor Price” - (Base price + warehousing costs + packaging cost)

Margin - Target Price

= “Result Price - Target Price” - Total Variable Costs · Result Price - Stretch Price

= (Base price + warehousing costs + packaging cost) + Strategy selection + Market area adjustment + Stretch adjustment

Margin - Stretch Price

= “Result Price - Stretch Price” - Total Variable Costs

Result Price

= (Base price + warehousing costs + packaging cost ) + Strategy selection

Margin

= Result Price - Total Variable Costs

Change in Price

= Result price this month - Result price previous month

Change in Price (% )

= ((Result price this month - Result price previous month) / Result price previous month ) x100

There are no reports or dashboards associated with this use case.

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:

As a Pricing Manager/Pricing Administrator, I want to see KPIs in the LPG I use to compare scenarios

User Story Name - LPG Header KPIs

I want to: Define the appropriate header level KPIs for my business

so I can: Use them to validate the overall LPG

Acceptance Criteria: Examples: current and future revenues, margins, margin %...

User Story Name - LPG Line KPIs

I want to: Define the appropriate line level KPIs for my business

so I can: Use them to validate each line of the LPG

Acceptance Criteria: KPIs to be displayed in columns Examples: current and future revenues, margins, margin %, detailed cost, price, volume values…

As a Pricing Manager/Pricing Administrator, I want to see KPIs in the scenario comparison window of the LPG I use to compare scenarios

User Story Name - Scenario comparison KPIs definition

I want to: Define the appropriate KPIs to compare scenarios with

so I can: Use them to choose the best scenario

Acceptance Criteria: KPIs will be displayed in columns/fields Examples: current and future revenues, margins, margin %, detailed cost, price, volume values… Calculation logic defined Sources for all parameters clearly defined.

As a Pricing Manager/Pricing Administrator, I want to set up several scenarios covering several price, volume, revenue or cost hypotheses, so I can compare them to help decide which prices to increase and by how much.

User Story Name - Parameters definitions

I want to: Define the appropriate metrics for my business

so I can: Adjust them in each scenario to see their impact on costs, volumes, revenues, prices, etc

Acceptance Criteria: The chosen parameters are relevant to the business context under consideration

User Story Name - Parameters tables

I want to: Have a table for each parameter to store values I want to work with

so I can: Use them in the calculation of costs, volumes, revenues, prices, etc.

Acceptance Criteria:

Each parameter has its own table with appropriate fields for each scenario, e.g.

• Dimensions: dates, geographies, product or customer groupings, distribution channel, etc

• Values: raw materials costs, absolute, % variation, factors

User Story Name - Approach selection

I want to: Have several approaches to select from when managing/adjusting prices

so I can: Be flexible in my pricing strategy and choose the most appropriate approach for any given situation

Acceptance Criteria: Parameters are maintained and adjustable in conjunction. Prices to be stored and visible in a price setting object that allows users to make mass adjustments. Mass price changes with possibility to:

• be made based on any given parameter.

• add a (currency) amount or percentage to a price as a part of an individual product or mass price change.

Ability to define all approaches client needs. For e.g., Explicitly set; Explicitly set with expiration; Formula-based; Anchored prices with automated price changes, etc. Manual overrides. Clearly defined system of managerial approvals or price changes.

User Story Name - Price protection

I want to: Set up a system of price protection

so I can: Prevent prices from changing until specific agreement date expires.

Acceptance Criteria: Set up at along the same level at which prices are manages (e.g., distribution channel, customer grouping, etc.) Price protection to allow a user to set a date for the validity and immutability of the price – meaning regardless of any changes, that set of prices cannot change until that date has passed. Subject to Approval workflow after expiration.

As a Pricing Manager/Pricing Administrator, I want to use the goal seeking functionality in my LPG.

User Story Name - Configure the “Revenue Change By” setting for goal seeking

I want to: Define the appropriate dimension in my goal seeking setting

so I can: Use the goal seeking functionality in a relevant way

Acceptance Criteria: Any LPG output field can be used and will show in the drop down list for the user to choose from

The LPGs used for this use case can be set up with any structure. LPG orientation essentially ask what business scenarios will have their own LPG and which will be consolidated into LPGs together. The goal here is to fragment groups of pricing so that the prices are as easy as possible to maintain without creating too many disparate objects – which increase the operational burden. Having many LPGs makes prices easier to maintain in smaller groups, but requires far more objects to be created and managed, increasing work and creating opportunities for human error (i.e. – multiple items for a single generated price).

A ”business scenario” in this definition is simply a set of prices that are maintained. Those prices will of course by for products, but the prices themselves may apply only for a certain product group, customer group, region or some other dimension that makes prices unique within an organization. This is a key question to establish with the customer – along what dimensions are your prices set?

The key questions to ask when determining LPG orientation are:

1. Who (and how) will manage the prices for each business scenario? Are certain pricing analysts responsible for certain product groupings or regions? Does a single cohesive team manage all pricing? Are different customer groups represented by specific teams?

2. What prices tend to change or move at the same time or in the same situations? Examples of this might be prices that are region-specific and have their own differing pricing cycle or prices for products that are all keyed on the same raw material prices.

Once the LPG orientation (or often before) has been decided, the LPG logic can be created. The calculations may vary depending on the way calculations are structured – BOM or no BOM. The concepts below have the potential for variation, so the base case scenarios are defined below, or at least the high level structure. The items below are general additional details – and at least pieces of the design – though they may not be present on every implementation.

• (Dependent on customer requirements) Depending on the approach for spot pricing (see requirements), a pricing BOM may be required. Additionally, costs / amounts for the components of the BOM will be required. This is only needed if prices will need to be calculated off of the BOMs for automated changes or any other calculations. BOMs can have a number of structures, but should largely follow a component / percentage format (specifying a component – either raw material or market index – the percentage of the price calculations that component should contribute) for our “base case” set up.

  • In addition to the BOM table, there will also need to be a component costs / prices table(s). This should show the component, a price and validity dates when those costs are valid.

  • BOM calculations should be defined by the customer and accounted for in the pricing calculations.

• Parameter tables will need to be defined for the mass update calculations. These should be based on the pricing levels defined in the requirements and use those, in a single table or several (for hierarchical set ups). The calculations should be simple and additive unless the customer has significantly different requirements, the base case should always be straightforward additive calculations.

The calculations in the LPG can then take two forms – BOM calculations (price adjustments based on changes to the underlying raw materials or indices) or mass updates (price changes based on the parameter calculation factors). The specifics of the calculations for BOMs will largely be dictated by the customer, but should generally follow this pattern:

In this scenario, the current price would be (100*0.6) + (200*0.15) + (150*0.25) = $127.50

Price calculations can be set up within the LPG logic if there’s only one calculation method (likely with BOM pricing), but can also be set up using the Custom Actions capability if there are more than one operation. If Custom Actions are used, Parameter tables may not be necessary for the mass changes as the parameters for the change can be entered directly into the action execution in the LPG Mass Actions menu. Depending on the orientation of the LPGs, there may be multiple prices per sku in a given LPG using the matrix logic option.

LPG calculations may also have additional factors, even if a BOM calculation is used. In this case, the proper values will need to be looked up from one or more tables and included in the calculation. These values may also need to be displayed in the LPG. These adders may be cost-to-serve items like packaging and freight, target margins or other additional pricing factors.

• Price protection agreements may be represented in many different ways, but for the base use case in spot pricing, these should be set up in a Parameter table. These tables can be constructed in the same way that the mass price change tables are (using the pricing level dimensions) and should include validity dates for the invalid price change period.

• The price protections (only valid ones that apply to the LPG being calculated) should be looked up and stored during price calculation. If a protection period is in effect for the product / price the calculation should be skipped and no action should be taken.

• Users may find a notification or warning indicator to be useful to indicate that a price was not changed due to price protection.

NOTE: This solution design capability is currently TBD