Commitment ID must enable 2 outcomes for practitioners

[JaxWilson]

Commitment ID must enable show back with and without award and deserved discounts and collective views of same at parent account level / or other groupings like depts / teams / product groupings etc.

Following onto the concept of the commitment ID discussio in slack channel - I feel the ID per discount applied or per savings plan or Enterprise Discount, should be reflected into focus. We MUST (please!) have an objective outcome for providers to be giving practitioners all the data to (1) enable internal charge back per consumer for their usage less their awarded/deserved discounts + (2) a company view (or collective of sub-accounts) of their Effective Savings Rates.

Proposed approach

These should be included into the calculation of ESR (yes/no?). I say yes. I say it would have been nice if that view was in the data and practitioners only needed to report on it.

[mike-finopsorg]

Can you please provide some more information and maybe a suggestion on what this looks like so we can move this forward. Thanks Maintainers Group

[JaxWilson]

Commentary under #310

[flanakin]

@JaxWilson #310 is about other types of discounts (not commitment discounts). Can you clarify what you're proposing here?

[JaxWilson]

Hi Team. What I would like to see in The Spec: 1) Commitment discountsID with metadata such as Type, Purchase Type, Monetary value would have spent, Monetary value did spend, Plans' Start & End Date, Element used in calc (e.g. Compute running hours for Compute Savings or Instance Type, Region .etc. I'm sure you get that concept. What I don't' see though in our Spec, is something called Effective Savings Rate. Maybe this topic can be separated into its own workshop. Either ESR is on the spec (highest level) or not. Ideally it should be next to each type of commitment discountID I think. This way I can use all the data from e.g. CSP and calculate the ESR for CSP. Or have all the data from any commitment discount plan and calculate each of those ID's ESR.

[shawnalpay]

Given the 1.0 inclusion of ContractedCost and the resulting FOCUS use case of Determine Effective Savings Rate (see here), I believe the need around ESR is addressed. That said, I am unclear whether this issue has been fully addressed. We will discuss as part of backlog review.

[shawnalpay]

Discussed in Oct 16 TF2 call; @cnharris10 to follow up and determine with author if #534 sufficiently encompasses this issue.

[jpradocueva]

Summary TF-2 call on Oct 16:

#298 and #534 Commitment ID and Commitment Discount Columns Primary Issue: Ensuring Commitment IDs enable two outcomes for practitioners and that discount unit prices and costs are exposed. Core Problem: Practitioners needed clearer calculations for Effective Savings Rate (ESR) based on commitment costs, but the current data model lacked support for this. Divergent Views: Some confusion on whether both issues should be handled together or separately. Final Agreement: These issues are closely linked and will be handled together under issue #534. Action Items: [TF-2-#298, #534] Chris, @cnharris10 is assigned to link the two issues and determine if #534 fully covers #298. He will follow up with relevant contributors and report back.

[jpradocueva]

Summary Members' call on Oct 17: #298 Commitment ID must enable 2 outcomes for practitioners Primary Issue: This issue addresses the need for the "Commitment ID" field to support two different outcomes that practitioners require: calculating savings rates and tracking commitments. Core Problem: Practitioners need a way to track commitment-related information while ensuring that the Commitment ID also allows for calculation of the effective savings rate. This dual-use requirement has led to questions about how best to design the Commitment ID field. Divergent Views: Some members felt that a single field could support both outcomes, while others suggested separating the tracking and calculation functionalities to avoid confusion. Final Agreement: Chris will follow up with the original author of the issue to confirm whether issue #534 could encompass the needs outlined in this issue, and the group will continue the discussion based on that feedback. Action Items:

• [ ] [Members-#298] Chris, @cnharris10 : Follow up with the author of #298 and confirm if issue #534 can resolve the two-outcome requirement for Commitment ID.

[cnharris10]

@JaxWilson and I talked earlier today.

Action Items:

1. We found that FOCUS does contain the necessary columns to calculate Estimated Savings Rate (ESR) along the lines of the examples on the bottom of this comment. @JaxWilson and I are going to continue to develop these SQL statements until aligned.
2. @JaxWilson is going to determine whether a use-case is sufficient enough or if an additional work item should be submitted for a further proposal
3. @cnharris10 has linked this issue with #534 ✅

--

ESR Calculation Options

Option 1: (1 - SUM(<What did I pay?> / <What would I pay with list costs?>)) * 100

SELECT
        BillingPeriodStartDate,
        ServiceName,
    1 - (SUM(
        CASE
        WHEN PricingCategory = 'Committed' THEN
            EffectiveCost
        ELSE
            BilledCost
        END
    ) / SUM(ListCost)) * 100
)
FROM
    <focus_dataset>
GROUP BY
        BillingPeriodStartDate,
        ServiceName

Option 2: SUM(<What did I pay?> / <What would I pay with list costs?>) * 100

SELECT
        BillingPeriodStartDate,
        ServiceName,
    SUM(
        CASE
        WHEN PricingCategory = 'Committed' THEN
            EffectiveCost
        ELSE
            BilledCost
        END
    ) / SUM(ListCost) * 100
)
FROM
    <focus_dataset>
GROUP BY
        BillingPeriodStartDate,
        ServiceName

[shawnalpay]

Discussed in Oct 21 Maintainers. @flanakin mentioned that his colleague will join this conversation, but mentions that we need commitment eligibility in order to properly calculate ESR.

[jpradocueva]

Comments from Members' call on Oct 31:

Analysis: Concerns handling ESR calculations, particularly eligibility criteria for reduced rates. Pending a meeting with Michael’s colleague for further insights. Agreements: Hold for further input on ESR from Michael and revisit for potential inclusion in 1.2 or future releases.