Ron Brill
Anglepoint
This paper provides practitioners with guidance related to the Scope of FinOps for SaaS, whether it is license-based or consumption-based, no matter how it is procured (i.e., direct, reseller or marketplace). This guidance will help the FinOps practitioner as to the scope of their activities when being asked to work with SaaS and how the FinOps Framework can be applied along with additional considerations both theoretical and actual examples. FOCUS™ will also be discussed, but finer data-level details will be covered in separate FOCUS™ documents. We agreed to keep this at a high level, vendor agnostic and to speak generally in ways that apply to most FinOps teams managing SaaS.
This paper applies to FinOps teams managing public cloud costs who have been asked to additionally manage technology spending on SaaS purchases and usage.
An existing understanding of the FinOps Framework Domains and Capabilities for public cloud.
A FinOps Scope is a segment of technology-related spending to which FinOps Practitioners apply FinOps concepts.
FinOps Scopes expand the Framework operating model to include intersecting areas of technology spend that practitioners manage with FinOps in addition to the public cloud.
FinOps Personas apply Framework Capabilities to another Scope of cost and usage data in addition to public cloud – such as SaaS or data center infrastructure – to extend FinOps’ collaborative and timely decision making practices in a consistent way across a broader scope of an organization’s technology landscape.
In order to get a better understanding of what types of costs FinOps Practitioners are managing, the FinOps Foundation conducted polls at the September 2024 North America & EMEA Virtual Summit and at the Asia Pacific Virtual Summit.
Results indicated that the majority of FinOps Practitioners across the globe are already managing SaaS (c.70%), Licensing (c.65%), and other technology costs in addition to public cloud spending.
These signals have made it clear that the practice of FinOps is being applied to areas of technology spending in many areas in addition to public cloud Infrastructure-as-a-Service (IaaS) costs.
The purpose of this paper is to expand on the FinOps Scope for SaaS, and support existing FinOps teams to understand:
Software-as-a-Service (SaaS) is a software distribution model where applications are hosted by a service provider/vendor and made available to customers over the Internet. The software provider manages the underlying infrastructure, maintenance, and support.
SaaS has become increasingly popular due to its flexibility, scalability, and ease of use. While license-based SaaS is more traditional, the landscape has changed and we’re seeing consumption-based SaaS applications grow and present many of the same challenges as public cloud.
Here’s a quick overview of common types of SaaS:
The challenges of managing public cloud spending are mirrored in the proliferation of SaaS across organizations through the use of decentralized, individual-level procurement and corporate-credit-card-funded purchase orders, resulting in limited organizational-level visibility into cost and usage.
Additionally, SaaS is a consideration in the typical Build-vs-Buy-vs-Rent discussions. Often, engineers have a choice between building their own solutions or purchasing one via a SaaS provider. Because of this, there is less of a clear distinction between what workloads are managed in Public Cloud versus workloads managed by SaaS vendors (or where they are shared). Therefore, the spend is all part of the same value creation process, and engineering teams want to know the total cost of running their solutions. And naturally, the other FinOps goals and outcomes follow.
By iteratively applying Framework Capabilities to achieve the outcomes described by the four FinOps Domains: to Understand our Cost & Usage, to Quantify its Business Value, to Optimize our Cost & Usage, and to effectively Manage the FinOps Practice, the same financial accountability and transparency can be established for SaaS spending, ensuring organizations can keep their SaaS costs aligned with business goals and associated technology strategy.
To manage the SaaS Scope, it is essential to build an inventory of the used SaaS products in your organization, ideally by automatically discovering them. However you can approach this in a Crawl, Walk, Run manner. There are numerous methods to discover SaaS and FinOps Practitioners will likely use a range of these to gain a holistic picture of the SaaS usage:
| Maturity | Discovery Methods |
|---|---|
| Crawl |
|
| Walk |
|
| Run |
|
Using a SaaS Management Platform (SMP) is crucial for effective SaaS discovery management. SMPs streamline the process and provide insights for optimizing usage and costs.
In addition to granular and timely data related to the cost and usage of SaaS products, there is also a need for metadata related to each SaaS product in existence within the organization. Think of this catalogue as similar to the metadata required for Public Cloud FinOps; You are looking for this metadata to solve the usual FinOps challenges in mapping to organizational constructs and understanding ownership information.
However, in addition you should also be looking to capture metadata relating to the SaaS contracts themselves so you can build up a catalogue/inventory for the SaaS products you intend to apply FinOps to. This should include close collaboration with Procurement, ITAM/SAM and Finance teams to align with any current system of record and not duplicate data. This inventory will also help to identify and articulate opportunities for cost optimization. Having good data on what actually drives the variable costs of SaaS (if any) is very important.
Attributes to consider (not exhaustive):
Please note: The above list is not a list of attributes intended to impact/replace/undermine any existing contract management/procurement system within your organization. It is to be considered a list of interesting attributes that may or may not be covered by the FinOps team. Apply sound data architecture thinking when defining your data model and understand the data lineage for all attributes.
Suggestion: Consider creating additional table(s) where you store your Public Cloud FinOps metadata so that you can benefit from any previous hard work you may have done to capture/curate metadata (Business Unit mappings, Cost Centers, Owners) as part of your Public Cloud FinOps practice. It is highly likely that there will be some useful mappings that can be done with the existing metadata. For example, expect familiar names in the list of owners for the SaaS products (especially where the SaaS is “IT for IT”).
SaaS has significantly transformed how businesses interact with and utilize software tools. SaaS pricing models govern how charges are incurred for using the software.
There are multiple ways to purchase SaaS including:
Understanding your payment terms for a SaaS contract will help you determine the best way to get the most value during the contract term.
For each SaaS product, you will need to understand if there are situations that will lead to an overage, how those overages are handled, and if/how you will be charged for them. The information you gather about overages may be leveraged in custom reports or may be something you need to monitor and alert on.
Here are some questions you’ll want to answer:
Getting answers to the above questions will help you determine what is important to monitor during the length of your contract to ensure you have enough warning to deal with potential overages and react before they occur. How you monitor overages may be a combination of leveraging features within the SaaS product, using a third party tool, creating your own custom reporting that tracks status, or creating/leveraging an existing monitoring/alerting process.
Depending on the method of procurement (direct, reseller, through cloud marketplace), the amount you spend may be eligible for discounts that are generally available or privately negotiated. These discounts may be based on volume, bundling with other products, or get better with longer contract terms.
Check to see if educational and government discounts are available from the vendor, if applicable.
Avoid discount traps by taking a stepped approach to your purchases. If you have the ability to add on licenses or infuse additional funds into your consumption-based contract, leverage it to help ensure you aren’t paying for what you aren’t using. Be sure to review your contracts to determine if discounts apply to the overall timeframe, or perhaps only the first year.
License-based SaaS is a software delivery/pricing model where consumers pay a pre-determined monthly or annual fee, for access to software under specific licensing terms. These licenses define parameters such as user limits, feature access, duration, and deployment environments. Unlike pure consumption-based pricing, this model offers predictable costs for customers and recurring revenue streams for providers.
Licensed-based SaaS models charge based on a specific metric which will be defined within the license grant. Common license metrics include:
Unlike consumption-based models, there is no billing fluctuation based on actual usage. Licenses are acquired up-front and, while additional licenses can typically be added at any time, reductions may only be made at certain pre-determined points in the contract (e.g., an annual anniversary or agreement renewal).
Managing licensed-based SaaS involves navigating complexities that can impact both financial and operational efficiency. Common areas to consider are:
Consumption-based SaaS is a pricing model where customers are charged based on their actual usage of the service, rather than paying a fixed subscription or license fee.
Some SaaS products provide a mechanism for tagging in two ways:
These tags may be added through the UI or via API directly in the SaaS product, or they may be ingested from another source location (e.g., tags on cloud resources ingested into an observability tool). Tagging your SaaS objects and/or usage provides the same benefits we see with IaaS – it allows us to break down the usage, visualize it, and allocate it.
When SaaS products are complementing traditional cloud services, such as an observability SaaS, it is meaningful to apply a shared tagging policy across the cloud and the SaaS products. Utilizing the same set of standard keys and values helps to allocate the cost with the same logic to the consuming entities such as applications/services or teams, giving them more complete and integrated visibility of their cloud and tooling costs at a glance.
Allocation of SaaS costs is important when trying to calculate Total Cost of Ownership (TCO). For some SaaS products, they may be owned/used entirely by an individual business unit or integrated with a single product, which makes allocation simple. For SaaS products that are used by multiple business units or integrated with multiple applications, allocation will be crucial in determining who is responsible for the cost.
If tagging is available, it should be leveraged to help with allocation. In cases where tagging is not available, you’ll need to rely on another method to allocate. If you have metrics that you can use to quantify usage, you can then proportionally allocate the costs to the appropriate application/business unit. If you do not have a way to identify usage based on metrics, you may instead choose to split costs evenly or based on a set percentage between applications/business units.
As consumption-based SaaS products become more complex with multiple SKUs, possible limits, or minimum usage/spend requirements, having visibility at a granular level is key. Some SaaS products have great built-in dashboards to view usage and/or cost at a granular level, but may limit you to how much data can be viewed at one time, how much historical data you can see, or may not make it easy to pull the data together in a single view.
Much like cloud, you may need to extract your SaaS product usage and cost data, transform it and ingest it into another tool or a datastore so that you can create custom reports in order to have full flexibility in how you show back your usage and costs. Some SaaS products have started to pull in usage and cost data from other SaaS products in an attempt to be a single pane of glass for their customers. There is no right or wrong way to provide visibility for your consumption-based SaaS usage and cost.
As SaaS products become more integrated with applications your organization is creating, it is likely that they make up a sizable portion of the overall cost. With the potential for multiple applications and/or business units using SaaS, you’ll want to ensure that your allocation and chargeback is done as fairly as you do for cloud. It is advisable to focus on charging back usage elements that can be influenced by consumption, while allowing shared or common components to be managed by the SaaS product owner. This approach will drive efficiencies among the user base as well as the product owner. This approach also simplifies budgeting and forecasting, as users only have to focus on their own usage.
Optimize the business value versus cost of your SaaS solution(s) by understanding, analyzing, and influencing the variable cost drivers (“usage”) of your existing SaaS solution.
Constraints
The extent to which you can optimize SaaS usage costs after initial purchase varies by product and depends on:
Consumption-based SaaS products provide some additional challenges when it comes to reporting and tracking. Not only are we looking at SKU-level usage (likely across multiple SKUs), but there are other key things to track, like limits per SKU, minimum consumption agreements, and overages. With SaaS we also see lump-sum, prepaid contracts, so we need a way to track how we’re burning down that balance and if we’re in danger of depleting it too soon. While cost visibility tooling is evolving, there isn’t a tool in the market today that brings all of these pieces of data together – thus creating the need for custom reporting.
Below are some data points that could be shown in custom reports that will help both FinOps and ITAM Practitioners get a complete picture of where things stand for a consumption-based SaaS product:
The goal is to be able to look at these data points and:
This section provides practical considerations for each of the FinOps Framework Capabilities when being applied by practitioners to the scope of SaaS. Please refer to the Framework Capabilities for existing guidance as this is not duplicated in this paper.
| Framework Capability | Application to SaaS Considerations |
| Data Ingestion | For SaaS, the cost and usage Data Ingestion Capability functions similarly to public cloud. However, there are limitations on the granularity available in most SaaS cost and usage data. License-based SaaS is less likely to provide less usage details because it is based on a pre-determined cost and terms. Consumption-based SaaS (link to Consumption-based SaaS section above) usage is variable by design, resulting in more monitoring and data collection.
Like CSPs, some SaaS vendors provide the ability to export usage data through CSV or XML files, extract, load, transform (ELT) processes, and API calls to external platforms for analysis. This usage data may include account (i.e., user, user group, or license), service and/or function-level details (for example, number of active user licenses, amount of storage usage, and count of function calls). But, unlike CSP data, SaaS usage data may not include the associated cost information. If SaaS usage data does include account, service, or function-level costs, it is likely not at the same granularity provided in CSP consumption data (e.g., costs per CPU, GB, hour). Therefore, data ingestion is often more complex for SaaS because usage and cost details may come from disparate sources, requiring additional processing, transformation, and correlation to align. A few SaaS vendors are adopting FOCUS™ to provide customers with enhanced and easier to align billing data which will improve data normalization efficiency. |
| Allocation | First, ensure you have the full inventory and ability to identify all SaaS.
Some vendors provide the ability to apply tags to usage or environments, similarly to Public Cloud. Apply existing shared cost allocation techniques, such as using internal telemetry data to create allocation formulas. Useful for any fixed cost portion of the SaaS bill License-Based:
Consumption-Based:
|
| Reporting and Analytics | Measures of Success & KPIs: FinOps teams can report on key dates for renewals and expiries for commitments, marketplace purchases, BYOL usage and SaaS services.
Inputs & Outputs: Detailed cloud billing, usage, license and carbon data |
| Anomaly Management | Anomaly detection functionality is not always provided on SaaS platforms. Usually in public cloud you can catch anomalies from a daily baseline. This is true for SaaS if you can get your cost and usage data daily. But for SaaS platforms that bill monthly, a different approach is needed.
Nature of the license is different in SaaS:
Tooling:
Anomaly scenarios:
|
| Planning & Estimating | Planning and Estimating for SaaS involve similar processes to those enabled in public cloud, with two distinctions.
SaaS costs, particularly for license-based SaaS, are often easier to predict since they are based on fixed fees for a specified time period. When usage-based costs are applied, they are often capped allowing for better control over variable spending. There is still a risk however of exceeding limits and for it to be allowed within the terms of the contract/ license. Unlike IaaS, which can be used to host an endless variety of workloads, SaaS products are purpose-built and typically provide distinct functionality, thereby making it easier to estimate the number of licenses, subscriptions, accounts, users, services, and/or functional capabilities utilizing the product. |
| Forecasting | Similar to Planning and Estimating, Forecasting SaaS costs is often easier than public cloud. SaaS platforms offer specific functionality which simplifies variation in the scope and scale of usability within an organization. IaaS consumption is elastic and impacted by the capacity needs of the myriad of workload types that can be hosted in public cloud making it more challenging to accurately forecast. |
| Budgeting | No further considerations for SaaS. Refer to Budgeting Capability in the Framework for information. Also refer to Planning and Estimating and Forecasting in this paper. |
| Benchmarking | One area of success that’s been seen in benchmarking that aligns between FinOps and SaaS, is when an organization has built their own services, for example VPN, comparing this for both functionality and cost versus buying a SaaS solution. This helps demonstrate value to the organization (in whichever way the results may show).
Like in FinOps, it can be challenging to benchmark between vendors, where this is challenging cloud to cloud in FinOps, benchmarking SaaS providers can be even more difficult as the services are often purposely marketed and designed to not be the same. Internal benchmarking of SaaS solutions is very important, often organizations unintentionally end up with multiple solutions capable of delivering requirements without realizing. This may happen because software is purchased to achieve a certain goal/requirement but also has other capabilities which are then not considered when new requirements are found and a new vendor selection process begins. There are some providers who offer some level of scoring for FinOps benchmarking (namely Google Cloud), in the SaaS world, there are third parties who can offer indications of what level of discount is expected/average within your industry. This is important as in SaaS/licensing it is common that discount bands can be set by industry/sector. As an example, financial services generally receive less discounts than the public sector. |
| Unit Economics | Understanding unit cost economics for businesses that rely on SaaS services are crucial for cost optimization and profitability. The goal is to assess how SaaS costs impact revenue and margins per unit.
Similar to the process of determining unit economics within the Public Cloud, it is key to determine what constitutes a “unit”. This could be a customer, order, transaction as examples and determine the revenue generated by each unit. Break down SaaS expenses into variable and fixed costs to allocate it accurately. SaaS cost per unit = Total SaaS cost/Total units
The next step is to determine gross profit per unit
Evaluate contribution margin to assess if the unit economics is sustainable. Whilst the process of understanding unit cost does not significantly differ from Public Cloud spend, the fixed and variable nature of the potential metrics and agreements does require a solid understanding to calculate correctly. |
| Architecting for Cloud | Decisions regarding leveraging consumption-based SaaS integrations should be made early in the process of architecting a new application, feature or service. The first step should be to determine whether to use a SaaS product or to build out the functionality instead. A FinOps practitioner may be involved in helping estimate the cost impact of going with SaaS or what the cost of the equivalent cloud resources may be.
If the decision is made to go with a SaaS product, there may be options if the product has a free, open source version versus a paid version with more enterprise features. There may also be different editions that require careful consideration so that you are only paying for features you actually need. Working with architects and developers to understand the requirements and with the vendor to understand the right fit with their product should be a standard practice. The vendor may allow you to run a POC to help validate functionality or estimate usage to help with the decision, or may even have case studies from other customers who have implemented the same thing. During the early design phase, you also need to consider how using a SaaS product may impact usage and cost in other platforms or other SaaS products. Consider data transfer, storage in other platforms, build systems, analytics and observability tools as usage in the SaaS product may lead to increased usage in other areas. |
| Workload Optimization | Depending on the form of SaaS, workload or usage optimization can have various levels of importance. When the metrics driving cost are based on usage, it can be critical and often SaaS can be neglected compared to cloud when it comes to reviewing usage.
For usage based SaaS, it’s critical to ensure that user management exists (adding and removing people when they join/leave, but also maintaining a view on how a user is (or isn’t) using the SaaS application and looking to revoke licenses that aren’t used to reduce costs where allowed under the contract.Equally, consider license bundles vs buying individual applications – each can be cost effective in different scenarios. Any SaaS contract with variable usage e.g., Databricks, can be handled very similarly to cloud workload optimization. |
| Licensing & SaaS | No further considerations for SaaS. Refer to the Licensing & SaaS Framework Capability for optimization information. |
| Rate Optimization | Most SaaS Rate Optimization will typically occur at the negotiation stage through volume discounts. Good, timely, and accessible data (and forecasting) around usage will enable identification of the correct pricing tiers and increased chances of additional discounts at the pre-purchase stage – this can include overage SKUs for consumption elements. Collaboration between FinOps, ITAM/SAM, and Procurement is key.
Where software allows for multiple models i.e., user-licensing and/or PAYG, ensure you have the data, and a process, to define which offers more value in different scenarios. Where license/consumption usage increases, tiers offering lower per unit pricing can be reached during the contract. However, for license-based SaaS in particular, decreasing quantities mid-contract is often contractually prohibited or incurs financial penalties. Identify where SaaS software can be purchased via Cloud Marketplaces (AWS, Azure etc.) as this may offer lower pricing than current purchase methods via reseller or direct with the provider. However,be aware of existing contractual terms that may prevent this and also new terms agreed to via the Marketplace. Collaboration between FinOps, ITAM/SAM, and Procurement is key to opportunity identification. Licenses can be used up to a limit to help you meet your cloud commit (not directly rate optimization for SaaS but can help with wider rate optimization of cloud) |
| Cloud Sustainability | There are challenges with Cloud emission data in a similar way to other usage optimization data, this includes data/ reporting availability and timeliness. FOCUS™ is also impacted by this challenge.
Most SaaS providers are not as advanced in this space as the large cloud providers, impacting selection choices. It is recommended that there is joint consideration of SaaS purchases with the sustainability team in your organization, particularly from a license based SaaS perspective (per seat). This should be addressed as part of intersecting disciplines and agreed based on the specific organizational setup of where the responsibilities sit – An example would be that the FinOps team focuses on SaaS usage optimization and associated carbon emissions and the sustainability team focuses on governance of seat licenses in relation to carbon emissions. Carbon accounting may be an excellent intersection for both “cost” and “sustainability” objectives to align on common KPIs. Global or multi-national corporations (MNCs) typically use carbon accounting or track similar cost-sustainability KPIs – to realize / optimize the business value of existing and anticipated ESG-related tax and tax-credit impacts to an organization across relevant jurisdictions. |
| FinOps Practice Operations | FinOps Practice Operations consideration for SaaS:
|
| FinOps Education & Enablement | FinOps Education and Enablement considerations for SaaS:
|
| Cloud Policy & Governance | Cloud Policy and Governance considerations for SaaS:
|
| Invoicing & Chargeback | Areas where the existing principles can be easily applied to SaaS:
However, there are areas where applying these principles may face limitations:
|
| FinOps Assessment | Where existing ITAM/ SAM teams exist there is likely to be existing assessments for that team. It is useful to keep this in place along with the FinOps assessment. Any variance in the assessments on common areas could trigger early warning to better improve collaboration/ resolution.
Elements to consider when assessing maturity include:
ITAM involvement and support should also be part of an organizations FinOps Maturity Assessment, understanding the processes in place and also ensuring that open-source is fully understood. |
| Onboarding Workloads | You may consider onboarding workloads to SaaS for various reasons. You may take a workload from on-premises or a workload that is already self-hosted in the cloud and move it into a SaaS solution. If the SaaS solution is already in place, there are also reasons for onboarding new or additional workloads; a new team is onboarding, a new service or feature has been created and will integrate with the SaaS solution or you may be consolidating workloads from other solutions and replace them by onboarding to a single solution. Before a workload is onboarded to a new, or existing, SaaS solution, architectural discussions should take place as well as planning and estimating usage/cost. |
| FinOps Tools & Services | See Tools for SaaS section of this document. |
| Intersecting Disciplines | Considerations for this Capability are formed throughout all sections of this paper. |
Some SaaS products have built-in monitoring and options for setting alerts when certain conditions are met. These might include alerts when you are getting close to a limit or running out of licenses or when your usage hits a defined threshold. Options will vary between products and some products may not have any options at all. You may be able to ingest your usage into another tool (third party or homegrown) and do your monitoring and alerting externally. The goal is to automate as much as possible to avoid having to manually check dashboards or reports reactively.
In this section, learn of potential roles and responsibilities of the FinOps team for SaaS and intersection of responsibilities with existing ITAM/SAM and other teams.
FinOps teams are getting increasingly involved in the management of SaaS products with various roles and responsibilities. The scope of the FinOps team largely depends on the organizational setup and the presence and maturity of intersecting disciplines.
On one end of the spectrum, FinOps teams may manage the entire SaaS Scope alone. On the other end, FinOps teams may play a less prominent role and rather collaborate with a long-established ITAM/SAM team, Procurement, Finance, and other teams with solid existing processes.
The set of roles and responsibilities in the SaaS management lifecycle include, but are not limited to, the following key activities:
When the FinOps team manages the SaaS Scope end-to-end, it performs most of these activities independently. However, when working with other connected areas, which is often the case in larger organizations, clarity about the split of roles and responsibilities among the teams and smooth collaboration are the critical success factors.
The table below illustrates where these roles and responsibilities might fall when working together with intersecting disciplines in their role of managing the purchase and ongoing cost and usage of any SaaS type. However, this RACI matrix is not meant as a prescription or best practice, more an example considering where the different roles and responsibilities traditionally fall. Organizations can and will differ in their implementation.
| Key Activities (Not Exhaustive – will differ by organization) | FinOps | ITAM/SAM | Procurement | Finance | SaaS Owner | Security |
| Purchase Request | C | A | I | R | ||
| Discovery and monitoring | I | R | C | A | C | |
| Inventory of SaaS tools | I | A/R | I | I | I | |
| Demand management and forecasting | C | A | I | R | ||
| Budgeting | C | C | A | R | ||
| Vendor/tool selection | R | A/R | C | I | R | C |
| Vendor negotiation | C | C | A/R | I | ||
| License management | R | C | A | C | ||
| Consumption (usage) tracking and optimisation | R | C | A | I | ||
| Invoice validation and payment | R | A | ||||
| Vendor relationship management (including contract management and category management) | C | C | R | I | A |
Strategic and tactical decisions, such as whether to buy or build a SaaS product, renew an existing tool, look for alternatives, or completely discontinue, are often made in a group setting where the representatives of different areas make a joint decision.
As organizations evolve, it is also worth assessing the advantages of ITAM/SAM, FinOps, and other related areas working closer together in the organizational hierarchy, which has been an observed pattern of evolution in recent years.
By following these best practices, you can optimize your SaaS investments, reduce costs, and ensure compliance with licensing agreements.
FinOps Open Cost and Usage Specification (FOCUS™) is an open-source specification that defines clear requirements for vendors such as cloud service providers and SaaS vendors to produce consistent cost and usage datasets. Supported by the FinOps Foundation, FOCUS reduces complexity for FinOps Practitioners so they can drive data-driven decision-making. This specification is designed to help organizations manage their spending more effectively by ensuring billing and usage data is collected and normalized consistently . It is especially valuable for SaaS buyers who need consistent data to optimize cost, usage, and performance across multiple software solutions.
The FOCUS™ standard offers SaaS buyers a powerful set of tools to standardize cost and usage data, enabling them to better manage, monitor, and optimize their cloud-based software investments. By adopting this standard, SaaS providers can demonstrate their commitment to transparency and empower their customers to make data-driven purchasing decisions.
For more information about the key elements of the FOCUS™ Specification that are particularly useful for companies purchasing SaaS, visit the FOCUS website.
FOCUS™ simplifies how companies view and analyze their SaaS expenditures by normalizing billing and usage data across different vendors. This is essential when working with multiple SaaS providers, as it eliminates the need for time-consuming data wrangling across diverse formats and terminologies. For example, standard columns such as BilledCost, UsageQuantity, and AmortizedCost allow businesses to measure and compare costs uniformly across services.
The standard requires detailed reporting on both actual and amortized costs, helping SaaS buyers make informed decisions based on predictable expense structures. This transparency is critical for managing large portfolios of SaaS tools, where understanding costs associated with each service allows businesses to adjust consumption and optimize budgets.
FOCUS™ supports cross-cloud and multi-vendor compatibility, offering a consistent data format that can be applied to a wide variety of analytics tools. This compatibility enables companies to track key SaaS metrics (like utilization and efficiency) more easily and create actionable insights that can drive cost-saving initiatives or justify increased investments where necessary.
With FOCUS™, companies can ingest usage data into their internal analytics systems or BI tools, allowing for real-time monitoring of SaaS consumption. This capability is crucial for optimizing SaaS usage based on current data and adjusting services before costs spiral out of control.
FOCUS™ allows companies to compare costs across different SaaS providers consistently, reducing vendor lock-in risks. By having a common specification, SaaS buyers can compare solutions not only on features but also on cost and usage efficiency, leading to better procurement decisions and the ability to negotiate contracts based on transparent cost structures.
In summary, the FOCUS™ standard offers SaaS buyers a powerful set of tools to standardize cost and usage data, enabling them to better manage, monitor, and optimize their cloud-based software investments. By adopting this standard, SaaS providers can demonstrate their commitment to transparency and empower their customers to make data-driven purchasing decisions.
See Vendors Currently Supporting FOCUS™
[Your Company Name]
[Your Address]
[City, State, Zip Code]
[Date]
[Recipient’s Name]
[Software Publisher’s Company Name]
[Address]
[City, State, Zip Code]
Dear [Recipient’s Name],
As part of our ongoing commitment to maximizing cloud financial management through the FinOps Framework, we are increasingly aligning our procurement decisions with standards that provide transparency, consistency, and actionable insights into usage and cost data. One such standard is the FinOps Open Cost and Usage Specification (FOCUS™), which enables streamlined and accurate cloud cost management across multiple platforms.
We are reaching out to request that your organization adopts and provides electronic cost and usage data in the FOCUS™ format for your product(s) as a requisite for our and your other customers’ future purchases. Key aspects of FOCUS™ that are particularly valuable to our operations include:
By adopting FOCUS™, your organization will not only facilitate our procurement process but also positively impact all of your customers and demonstrate a commitment to transparency and interoperability, which are essential in today’s rapidly evolving cloud and SaaS environments.
We encourage you to review the FOCUS™ Specification, which is already supported by major cloud providers like Microsoft, AWS, Google Cloud, and Oracle Cloud, and look forward to your confirmation that your solution will comply with the Specification.
Thank you for your attention to this matter. We look forward to continuing our relationship with a shared focus on enhancing cloud financial operations.
Sincerely,
[Your Name]
[Your Position]
[Your Company Name]
[Your Contact Information]
In today’s market, there are two main types of tools for managing SaaS technology investments. Traditional FinOps tools, primarily designed for public cloud, lack comprehensive SaaS management capabilities. Conversely, SaaS management tools have yet to fully integrate advanced features of modern FinOps tools, such as the ingestion of detailed daily usage data and actual SaaS consumption costs.
SaaS management tools vary widely. They can be standalone solutions, part of a larger platform, or focused on a single publisher. FinOps teams should work with their ITAM peers to determine if a solution is already in place. The FinOps Landscape and analysts like Gartner can help identify tools that specialize in SaaS or offer SaaS management features.
When evaluating a SaaS Management Platform (SMP), key considerations include supported discovery methods, the number of recognizable SaaS services, the frequency of updates to the SaaS recognition library, licensing models, scalability, security, and extensibility. Point solutions are cost-effective for getting started but may lack the interoperability and features of platform-based solutions.
Many SMPs offer monitoring and alerting features, such as:
Increasingly, SMPs use AI and ML to automate tasks and proactively identify potential issues. To reduce inefficiencies, it’s essential to use the FOCUS™ billing format for data exchange. Choose solutions that support this format.
As with any tooling decision, there is a build vs. buy choice. If you are considering building an in-house solution, important factors to evaluate include:
By considering these factors, organizations can determine the best-fit tooling for their needs.
We’d like to thank the following people for their work on this Paper:
We’d also like to thank our Community Members for insights during Community Calls on this topic and the FinOps Foundation staff for their help: Vas Markanastasakis, Rob Martin, Andrew Nhem, Samantha White, Amber Gregorio, and Dean Oliver.
Licensing & SaaS
