NEW
FinOps for AI Training Now Available
This Paper is Part 2 of a three-part series on FinOps for SaaS. Learn how to apply FinOps Capabilities and best practices toward managing SaaS (software-as-a-service) cost and usage data.
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 for existing capability guidance as this is not duplicated in this paper.
| 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 (link to license-based SaaS section above) 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, but is standard on public cloud. 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 organisation 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 organisation (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 organisations unintentionally end up with multiple solutions capable of delivering requirements without realising. 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 optimisation 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. |
| SaaS and Licensing Optimization | No further considerations for SaaS. Refer to SaaS and Licensing Optimization Capability in the Framework for 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 and Enablement | FinOps Education and Enablement considerations for SaaS:
|
| Cloud Policy and 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 organisations 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 organisational 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 organisations, 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. Organisations 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 organisations 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.
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:
Licensing & SaaS