Versions Compared

Version Old Version 3 New Version Current
Changes made by

Ioana Kocurova

Ioana Kocurova

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Panel
bgColor#E6FCFF#B3F5FF

Business Use Case Summary

Automate Formula-Based Pricing for Better Profitability

The use case addresses the complexities of pricing in process manufacturing markets by leveraging market indices to create agreements that stabilize profit margins and enhance competitiveness.

This approach helps manufacturers manage the risks associated with fluctuating raw material costs, ensuring accurate and timely pricing. Key benefits include improved alignment with customer pricing strategies, increased gross margins through refined cost calculations, and reduced manual errors, which enhance customer trust.

Additionally, the automation of price calculations and integration with ERP and CRM systems streamline workflows and decision-making. Pain points include the challenges of managing complex formulas and ensuring timely updates to agreements, which can lead to outdated pricing and margin compression.

🎯 Business Objectives

  1. Efficiently create formula-based pricing agreements 

  2. Easily manage formulas and rules complexity 

  3. Provide workflows and analytics to support customer negotiation and related decision support 

  4. Recalculate formulas automatically at certain periods based on most current inputs 

  5. Execute agreement pricing outputs to ERP or similar “system of record” as well as required integrations to CRM, CLM, and regular formatted customer-facing documents 

  6. Maintain and adjust agreements mid-term or in anticipation of agreement renewal 

  7. Manage agreement approvals and workflow 

⌚ Time Estimation

The level of effort in this use case varies significantly based on required adjustments and must-have criteria. Baseline estimates and guidelines on factors causing variation are outlined below for discussions with the customer. This use case is characterized by high complexity and variability, making the estimation process intricate.

Factors influencing estimation include agreement types, inputs, approvals, and data structures. These elements will directly impact the implementation effort. Considerations that are likely company-specific are listed below, along with constraints and relative estimations on changes in effort.

👥 Stakeholders

Key stakeholders, including Sales Representatives, Pricing Managers, and Pricing Administrators, are targeted in this use case to load essential data into Pricefx for accurate pricing calculations, create and negotiate tailored formula agreements for customers, and ensure these agreements are approved and implemented seamlessly. The use case focuses on calculating formula-based prices during designated intervals, enabling easy review and integration with downstream systems.

Additionally, stakeholders are supported with maintenance and pricing agreements revision, incorporating supplemental capabilities to enhance the overall pricing strategy.

Business Context (Use Case Description)

Agreement Lifecycle Workflow

image-20240828-105001.png

Agreement Workflow 

 Formula Management 

 Agreements can either be fixed or formula based. Fixed agreements are based on a fixed price or are fixed based on an adjustment relative to standard list price or other reference, they do not require the use of formula management. Formula-based agreements utilize a dedicated formula creation and management capability within Pricefx. For more details see the cross-referenced documentation below. 

Agreement Setup 

The primary focus of the agreement set-up step is to create a new agreement for the first time. This step assumes that: 

  • formulas needed in an agreement have already been created in the formula library, and  

  • any and all required reference data, including market index data and other related data, is available. 

The key elements of the agreement setup step are broken down into header and line item inputs. Additional elements for workflow, attachments, messages, analytics, and published documents will be addressed here in some detail but may have other extended documentation as noted. 

Note: Multiple agreements templates can be used for unique and configured requirements per business unit, product category, sales team or wherever required based on unique agreement setup requirements. 

Scenario Evaluation 

A variety of tools are available to compare formula agreement scenarios in order to present the customer with options or to consider as strategic alternatives during a sales negotiation. 

 Business analysts can utilize forecast data to simulate Formula impactacross multiple scenarioson predefined KPIs (Key Performance Indicators) such as margin, revenue and volume. In most cases, looking at historical data will be possible and sufficient to show what a previous period (e.g. - last 12 months) would have looked like given alternate formulas or agreement inputs. 

The accelerator will allow users to compare scenarios and to activate the desired scenario directly from comparison dashboard to simply decide which scenario to use. Active and Inactive flags support multiple comparisons and the ability to save alternative scenarios for future use. 

Forecast-focused evaluations require the customer to generate and deploy required forecast data as a standard data object / data table. 

Governance & Workflow 

Before an agreement is approved and transmitted to the ERP or other system of record for use in live pricing, many teams will require a managerial review and approval step.  Workflow and approval capabilities include automated approval workflows as well as establishing the parameters to comply with corporate goals. 

The Accelerate Approval Workflow Package core capability supports: 

  • Workflow creation and changes 

  • Agreements specific approval steps 

  • Conditional expression creation and management of each approval step 

  • Full execution of workflow processes 

  • Workflow history tracking 

 Out of the box accelerator steps can include: 

  • Approvals based on math or logical expressions and data lookups 

  • Approver types (e.g. - approver and watcher) 

  • Support from user and user group assignments 

Execution 

Once an agreement has all required fields populated by the user, is successfully calculated, saved, and has completed all required approvals, it is ready to be executed. Execution in this case is focused on generation and transmission of the final price and other details to the ERP or other system of record. The Accelerator generates condition records within Pricefx. Once executed, the agreement will then recalculate prices as required by the calculation period inputs. 

Publishing documents

Draft and/or finalized documentation can be created in MS Word, Excel, and PDF formats as a standard. These publication templates are configured based on customer needs and typically include header/footer and branding, body elements for calculated pricing, formula, and inputs, and other related documentation.

Info

There is no out-of-the-box format for exportable documents as they are company specific. 

Once generated, documents can be exported or emailed to the customer from within Pricefx. However, Pricefx does not have a documents repository and is not an email server system. Pricefx is also not a CLM (contract lifecycle management tool). Pricefx can send CLM systems agreement pricing and related details as needed via API. Pricefx is not used for CLM “paper process” functions like legal clause libraries, redlining, and contract repositories.  

(Re) - calculation 

The calculation period defines the primary logic for recalculating pricing for the agreement's duration. This can be initiated based on dates/times, updated or more current and complete formula inputs, or can be manually triggered. Time and event-based triggers can also be useful as a part of this process. It is also possible for a manual approval to be required before a recalculated result price is approved for production use. 

Recalculation can also act as a trigger for the creation of new customer-facing documents. 

  •  Calculation runs according to schedule or related calculation logic 

  • Once a calculation is completed and approved, pricing records (Condition Records) are generated and can be exported or otherwise actioned 

Revision / Renewal 

Agreements are valid only for a duration from start date to end date. Once the agreement end date is reached, the agreement pricing will no longer be used in the system of record for active pricing purposes. It is important to have alerting and dashboards to make sure that there is always an active agreement price if desired (See “Actionable Insights.”). When no agreement pricing can be found or the agreement has expired, standard functionality in the ERP system will typically resolve. 

Business analysis may wish to renew an agreement with changes or maintenance of the same rules. Best practice for agreements in Pricefx is to duplicate an agreement and rename/edit the newer duplicate version. Changes can be made, and all new agreement workflow steps are taken to completion. 

Panel
bgColor#F4F5F7

Features and Capabilities (Overview)

Inline analytics and decision support 

Below are examples of both dashboards and in-line analytics or contextual decision support that can be configured in an agreement template. Outside of agreement comparison, other analytics shown below will require configuration. Current agreements accelerators have limited out of the box analytics.

Customer Insights Dashboard

It is also highly recommended to leverage for use in agreements (see PM-07 “Customer insights analytics to monitor feedback and improve strategy effectiveness). A customer level view of customer history and trending can be valuable to decision making in the agreement creation, negotiation, and renewal processes. 

Agreements

Agreements renewals dashboards are also recommended for long-term agreement performance and renewal tracking. This type of dashboard can be configured based on an example implementation configuration code as reference (see PM-02 “Agreements performance analytics to support renewals and improve profitability”). 

Panel
bgColor#DEEBFF

Prerequisites for PDR Implementation

  • Formula management is necessary as the basis for this use case but is not covered within it. This requires the implementation of the Pricefx PM-15 use case. 

  • Data structures for all relevant data tables needed to support agreement creation and price calculations should be set up and fully populated with data needed. 

 Agreement creation and management: users should be able to create and manage formula-based pricing agreements for customers or groups of customers that allow agreement line items containing a product or elements of the product hierarchy to be set up with formulas that determine the product pricing. 

  • Agreements can be set up in different contexts – by business unit, region or some other distinguishing factor.  

  • Agreements are set up based on one or more “scenarios” - groupings of terms for different products that can be compared to one another. The scenarios would generally be set up as variations of the same group of products so that they can be compared to one another to understand which one is the best option. 

  • Agreements include inputs for the user for the following information at the whole agreement level: 

  • Name of the agreement 

  • Effective dates (start and end) for the pricing agreement 

  • Customer(s) that are covered by the pricing terms of the agreement 

  • A base UOM and currency for the agreement 

  • A UOM and currency conversion table that includes alternate UOM and currencies that the products must be priced in 

  • Any additional header level fields that are needed to price the agreement 

  • Analytics that cover metrics for the totality of the deal 

  • Users should be able to set up scenarios that each will encompass a full group of agreement terms so that they can compare agreement terms across the scenarios. Scenarios should have the following inputs: 

  • A flag designating the scenario as active. An active scenario will become the “live” version of the agreement and will have prices calculated. Non-active scenarios will not be priced. Only one scenario can be chosen as active. 

  • A calculation period that designates how frequently and when new prices will be calculated 

  • Users should be able to add line items to the agreement that represent one or more products and the associated formula for pricing with the following information: 

  • The product(s) that are being priced 

  • Selection of the applicable pricing formula from a formula library 

  • An adder override and override type (absolute or percentage) 

  • A product exception matrix that will allow products within the line item scope to have different adder values 

  • Any additional line item level fields that are needed to properly calculate the price with the formula 

  • Any additional line item level fields that are needed to create price conditions or classify elements within the pricing agreement 

  • Analytics that cover metrics for the line item 

  • Agreements should incorporate the ability to create a structured approval workflow with simple conditionals and up to 3 levels of approval 

  • Price Calculations: all approved agreement should calculate the pricing using the designated formulas, based on the calculation period set and using any relevant underlying data available 

    • Index, cost, surcharge / fee and any other data relevant to generating formula-based pricing should have data sources available and populated with relevant data. 

    • The price calculation process should run frequently so that prices from any calculation period prices are properly calculated. 

    • All formula-based prices in any formula-based pricing agreements should be calculated within the proper time frames and using the appropriate supporting data in time to make the final prices available to other systems by the pricing effective dates. 

    • Final calculated prices can be published to downstream systems as data at the appropriate times to prevent disruption of business. 

     

    Agreement maintenance: formula pricing agreements can be updated and adjusted during the agreement duration or renewed before or after agreement expiration. 

    • Pricing agreements can be revised at any point during the pricing agreement's duration if the business allows revisions during that time frame. 

    • Users can make the allowed changes to the agreements during the revision process. 

    • Pricing agreements can be renewed and changed as needed before or after the expiration / end date of the agreement. 

Key availability requirements: 

  • The system should be available to users during standard business hours for the regions involved. 

  • The system should be able to export prices on the required schedules. 

  • The system should be available to complete calculations off during non business hours, depending on the requirements for calculation times 

Key performance considerations: 

  • Pricing calculations must start and complete in a time frame that will not impact business operations. The specifics of these time frames depend heavily on the calculation periods (pricing cycles) used by the organization and operating process. Daily or weekly calculation periods will need much more active processing speed than quarterly or longer pricing cycles. Additionally, the availability of calculation factor data in the system also has an impact, as the later the underlying data is available, the shorter the time window for calculations becomes. 

  • Typical performance concerns apply in this and most other use cases. <Performance concerns at xx data sizing, other things.> Logic complexity plays a significant part in calculation speed, so organizations with more complex formulas - both in formula logic and the number of data contexts accessed during calculation – should expect reduced velocity for processing. 

Limitations and Risks

exclamation point.png

Limited capability OOTB

Out-of-the-box capabillities are limited for Agreements in this implementation.

Panel
panelIconIdatlassian-cross_mark
panelIcon:cross_mark:
bgColor#FFFFFF

Out of Scope

The following features and concepts are out of scope for this use case. The features incorporated in this use case are the more common items that would be expected in the scope of formula-based pricing.  Key items that may arise around the use case but are not included and not recommended in the scope are: 

Core Changes to Formula Structure and New Formula Creation

Values for existing features can be specified in the agreement if they’re accounted for in the formula structure. However, no structural changes to formulas are included in the scope of this use case. Any changes to formulas are accounted for in use case PM-15. 

Mass formula revision

When formulas are added included in a formula-based pricing agreement the versioned snapshot of the formula is included in the agreement. The version of the formula that exists at the agreement's approval will stay with it until it is revised. The versioning of the formulas in an agreement, however, cannot be mass changed without revising each agreement manually. 

Agreement construction without scenarios

Agreements cannot be created without the scenario structure that is described in this use case. This is typically only a small inconvenience as a pricing agreement without concern for scenarios could be built with just one scenario that would achieve the same impact. Forecasts or analysis could still be done on that single scenario. 

Configured products

Any products added to agreements must exist in the product master and have a formula defined at agreement creation time as well as any underlying data needed to calculate price. Creation and pricing of custom configured products or products that do not exist in the product master is not in scope. 

Automated import of existing agreements

A key consideration when creating and setting up agreements in a new system is the management of existing agreements that still have validity or are needed for historical information. Generally, even in the best case, importing agreements from another system is technically complex and difficult. It is not recommended to try to bring in existing agreements from another system except in the most extreme and ideal circumstances. The more complex an agreement structure is, the more complex the process of importing agreements becomes – which makes the exercise far less than ideal for formula-based pricing. Simpler agreements are less complicated, so the only circumstances where attempting this might make sense is for large numbers of very simple agreements. But it’s important to keep in mind that any agreement created automatically would need human validation before being executed. 

Additional data enrichment or maintenance beyond this use case

Any component or other data required to execute pricing calculations, agreement construction or any other functions needed for this use case should be brought into the system in a fully usable format. Data enrichment or maintenance is possible in Pricefx, but that type of capability is largely better served in a master data management or data lake type of system rather than in the pricing system. 

Advanced or additional notifications and alerts

No additional notifications or alerts outside of error handling in the agreement creation. This can be configured for but is not included in the scope of the use case.  

In addition, the following capabilities are not common requirements for formula-based pricing and are broadly out of scope: 

  • Any additional reporting and dashboards not included in the core use case requirements 

  • Any real time or interactive pricing API integration 

Terms and Definitions

Info

For common terms → Business User Glossary here and Developers here.

Formula-Based Pricing →

Market Indices →

Downstream Systems →

A pricing strategy that uses mathematical formulas to determine prices based on various inputs.

Statistical measures that track the performance of a group of assets, often used in pricing calculations.

Systems that receive data from other systems, such as ERP or CRM platforms.