1. Approach
1.1. Stage 1: Planning for FinOps in an Organization
1.1.1. Do your research
1.1.1.1. Research your possible advocate/champion/executive sponsor, and have one-on-one conversations with them using a customized FinOps introduction deck or targeted interview questions to determine adoption strategy.
1.1.1.2. Research pain points being experienced by the organization during your conversations, such as cloud costs breaking business cases, general perception of cost overruns, lack of cost visibility by cloud consumers, etc.
1.1.1.3. Research impacted groups, teams, and individuals during your conversations. Who is affected by the pain points?
1.1.2. Create a plan
1.1.2.1. Identify tool requirements. Determine if existing owned tools can fill the needs of the plan.
1.1.2.2. Identify an organizational home for the FinOps function. This may be in a CCoE, in finance, or in IT. Depending on the complexity of the organization structure, creating a dedicated FinOps team might take a phased approach. Some organizations might (1) set up a cross-functional transformation program office and create workstreams/working groups, (2) create a FinOps function as part of the extended Cloud Business Office/CCoE, and (3) evolve into a dedicated cloud FinOps team.
1.1.2.3. Identify candidate early-adopter teams who can be evangelists.
1.1.2.4. Identify KPIs to measure the FinOps function and identify ways to measure engagement and performance of stakeholders like business units and application teams. These KPIs are preliminary and will evolve during Stage 2, but it’s important to have a starting set.
1.1.2.5. Prepare a communication plan that will be used in Stage 2.
1.1.3. Gather support
1.1.3.1. Highlight current state, pain points, and other issues.
1.1.3.2. Identify threats and provide scenarios that could happen if action is not taken.
1.1.3.3. Demonstrate what maturing FinOps would look like for the organization.
1.1.3.4. Examine opportunities that should be, or could be, exploited.
1.1.3.5. Present a roadmap for implementing the plan.
1.1.3.5.1. Get feedback from the executive sponsor and adjust as needed.
1.1.3.5.2. Include initial team size, budget, and timeline for initialization.
1.1.3.5.3. Include the value proposition (e.g., ROI such as the cost of having a
1.1.3.5.4. FinOps function versus an ongoing reasonable cloud overspend).
1.1.3.6. Present to other stakeholders, supporters, and a pilot set of people unfamiliar with the project such as business unit leads.
1.1.4. Perform initial resourcing
1.1.4.1. Request support from the sponsor to recruit other executive leaders as sponsors.
1.1.4.2. Form a change coalition made up of true organizational influencers and stakeholders.
1.1.4.3. Get budget approval for headcount.
1.1.4.4. Choose native, third-party, or homegrown tooling depending on need.
1.2. Stage 2: Socializing FinOps for Adoption in an Organization
1.2.1. Communicate value
1.2.1.1. Communicate the values that are central to the change.
1.2.1.2. Share a short summary of what you see the future organization looking like. Share high-level roadmap.
1.2.1.3. The What Is FinOps pitch deck available on the FinOps Foundation website is a good starting point for this pitch, but it must be customized for your organization to touch on your plan.
1.2.2. Create a plan
1.2.2.1. Provide an understanding of what FinOps is.
1.2.2.2. Understand their issues and explain/educate on how FinOps could help them.
1.2.2.3. Discuss proposed KPIs and adjust per conversation feedback.
1.2.2.4. Establish interaction model between FinOps and key partners (IT domains; controllers; app teams).
1.2.2.5. Identify future members during socialization for CCoE and executive steering committee.
1.2.3. Perform initial resourcing
1.2.3.1. Customize the FinOps model (inform, optimize, and operate) to the organization.
1.2.3.2. Identify the FinOps team with internal transfers where there is overlap with existing roles or individuals; fill remaining gaps via recruiting/contracting.
1.2.3.3. Map the change network for FinOps across the organization—sponsors, influencers, adopters. Create a clear training and communications strategy that ensures full coverage of all impacted resources.
1.2.3.4. Create a hub-and-spoke model to scale FinOps within very large organizations, detailed later in this chapter.
1.2.3.5. KPI roadmap: Finalize the first set of KPIs and reports, and identify and plan for next-gen KPIs and reports.
1.3. Stage 3: Preparing the Organization for FinOps
1.3.1. Assess FinOps readiness
1.3.1.1. Define tags, metadata, and organizational taxonomy.
1.3.1.2. Deploy, configure, and smoke-test tool(s).
1.3.1.3. Finalize the first wave of KPIs. KPIs/business adoption metrics can evolve over “adoption periods” to create a mentality of gradual FinOps maturity and not push full maturity in one go. This will allow for less mature teams and executives to not be “scared off” and do it step-by-step.
1.3.1.4. Define usage and spend thresholds for alerts and report limits.
1.3.1.5. Define and prepare persona-based self-service dashboards. These should show important metrics like the first wave of KPIs, cost allocation, budget anomalies, optimization recommendations, and other views of interest to stakeholders.
1.3.1.6. Prepare forecasting model with unit cost calculations included. At this point, this is likely just a spreadsheet.
1.3.2. Engage stakeholders
1.3.2.1. Determine business unit appetite for commitment levels (total cost for enterprise discount negotiations, RI/SP/CUD/etc.).
1.3.2.2. Engage early adopter team to get optimization wins (e.g., shutting down test environments or instances that are no longer in use to show material savings). These are important for socializing, rolling out, and winning additional adoption later
1.3.2.3. Get some additional early governance wins for getting FinOps implemented (e.g., tagging policy, lease-to-live automation, etc.).
1.3.2.4. Start cadence of regular meetings. The FinOps/CCoE team should be talking on a regular basis with the business units, app teams, practitioners, and stakeholders to implement best practices and track KPIs
2. Maturity
2.1. Crawl
2.1.1. Characteristics
2.1.1.1. Very little reporting and tooling
2.1.1.2. Measurements only provide insight into the benefits of maturing the capability
2.1.1.3. Basic KPIs set for the measurement of success
2.1.1.4. Basic processes and policies are defined around the capability
2.1.1.5. Capability is understood but not followed by all the major teams within the organization
2.1.1.6. Plans to address “low hanging fruit”
2.1.2. Goals/KPI
2.1.2.1. Should be able to allocate at least 50%
2.1.2.2. Resource-based commitments discount target coverage of approximately 60%
2.1.2.3. Forecast spend to actual spend accuracy variance is 20%
2.2. Walk
2.2.1. Characteristics
2.2.1.1. Capability is understood and followed within the organization
2.2.1.2. Difficult edge cases are identified but decision to not address them is adopted
2.2.1.3. Automation and/or processes cover most of the Capability requirements
2.2.1.4. Most difficult edge cases (ones that threaten the financial well-being of the organization) are identified and effort to resolve has been estimated
2.2.1.5. Medium to high goals/KPIs set on the measurement of success
2.2.2. Goals/KPI
2.2.2.1. Should be able to allocate at least 80%
2.2.2.2. Resource-based commitments discount target coverage is approximately 70%
2.2.2.3. Forecast spend to actual spend accuracy variance is 15%
2.3. Run
2.3.1. Characteristics
2.3.1.1. Capability is understood and followed by all teams within the organization
2.3.1.2. Difficult edge cases are being addressed
2.3.1.3. Very high goals/KPIs set on the measurement of success
2.3.1.4. Automation is the preferred approach
2.3.2. Goals/KPI
2.3.2.1. Greater than 90% of spend can be allocated
2.3.2.2. Resource-based commitments discount target coverage is approximately 80%
2.3.2.3. Forecast spend to actual spend accuracy variance is 12%
3. Phases_Lifecycle
3.1. Inform
3.1.1. Map spending data to the business
3.1.2. Create showback (and other) reporting
3.1.3. Define budgets and forecasts
3.1.4. Define your account strategy
3.1.5. Set tag strategy and compliance
3.1.6. Identify untagged (and untaggable) resources
3.1.7. Allocate shared costs equitably
3.1.8. Dynamically calculate custom rates and amortizations
3.1.9. Analyze trending and variance
3.1.10. Create scorecards
3.1.11. Benchmark against industry peers
3.1.12. Identify anomalies
3.2. Optimize
3.2.1. Analyze KPIs and set goals
3.2.2. Find and report on underutilized services
3.2.3. Evaluate centralized commitment-based discount options
3.3. Operation
3.3.1. Deliver spend data to stakeholders
3.3.2. Rightsize instances and services (or turn them off)
3.3.3. Define governance and controls for cloud usage
3.3.4. Continuously improve efficiency and innovation
3.3.5. Automate resource optimization
3.3.6. Define governance and controls for cloud usage
3.3.7. Integrate recommendations into workflows
3.3.8. Integrate chargeback into internal systems
3.3.9. Establish policy-driven tag cleanup and storage lifecycle policies
4. Principle
4.1. Teams need to collaborate
4.1.1. Finance, technology, product, and business teams work together in near real time as the cloud operates on a per-resource, per-second basis.
4.1.2. Teams work together to continuously improve for efficiency and innovation.
4.2. Decisions are driven by business value of cloud
4.2.1. Unit economic and value-based metrics demonstrate business impact better than aggregate spend.
4.2.2. Make conscious trade-off decisions among cost, quality, and speed.
4.2.3. Think of cloud as a driver of innovation.
4.3. Everyone takes ownership for their cloud usage
4.3.1. Accountability of usage and cost is pushed to the edge, with engineers taking ownership of costs from architecture design to ongoing operations.
4.3.2. Individual feature and product teams are empowered to manage their own usage of cloud against their budget.
4.3.3. Decentralize the decision making around cost-effective architecture, resource usage, and optimization.
4.3.4. Technical teams must begin to consider cost as a new efficiency metric from the beginning of the software development lifecycle.
4.4. FinOps data should be accessible and timely
4.4.1. Process and share cost data as soon as it becomes available.
4.4.2. Real-time visibility autonomously drives better cloud utilization.
4.4.3. Fast feedback loops result in more efficient behavior.
4.4.4. Consistent visibility into cloud spend is provided to all levels of the organization.
4.4.5. Create, monitor, and improve real-time financial forecasting and planning.
4.4.6. Trending and variance analysis helps explain why costs increased.
4.4.7. Internal team benchmarking drives best practices and celebrates wins.
4.4.8. Industry peer-level benchmarking assesses your company’s performance.
4.5. A centralized team drives FinOps
4.5.1. The central team encourages, evangelizes, and enables best practices in a shared accountability model, much like security, which has a central team yet everyone remains responsible for their portion.
4.5.2. Executive buy-in for FinOps and its practices and processes is required.
4.5.3. Rate, commitment, and discount optimization are centralized to take advantage of economies of scale.
4.5.4. Remove the need for engineers and operations teams to think about rate negotiations, allowing them to stay focused on usage optimization of their own environments.
4.6. Take advantage of the variable cost model of the cloud.
4.6.1. The variable cost model of the cloud should be viewed as an opportunity to deliver more value, not as a risk.
4.6.2. Embrace just-in-time prediction, planning, and purchasing of capacity.
4.6.3. Agile iterative planning is preferred over static long-term plans.
4.6.4. Embrace proactive system design with continuous adjustments in cloud optimization over infrequent reactive cleanups.
5. Personas
5.1. Core Personas
5.1.1. FinOps Practitioner
5.1.1.1. Objectives
5.1.1.1.1. Cultural change flag bearer
5.1.1.1.2. Create cloud cost management best practices
5.1.1.1.3. Create benchmarks for teams to use
5.1.1.1.4. Create visibility and transparency to cloud cost
5.1.1.1.5. Create or inform cloud budgets and forecasts
5.1.1.2. Challenges
5.1.1.2.1. Lack of access to needed data
5.1.1.2.2. Distributed accountability
5.1.1.2.3. Building adoption at enterprise scale
5.1.1.2.4. Tool reliance that does not deliver capabilities needed
5.1.1.3. Key Metrics
5.1.1.3.1. Accurate budgets
5.1.1.3.2. Accurate forecasts
5.1.1.3.3. Unit Cost Economics
5.1.1.3.4. Discount/Reservation coverage
5.1.1.3.5. Percentage untagged resources
5.1.1.3.6. Efficiency opportunity
5.1.1.4. FinOps Benefits
5.1.1.4.1. Centralized cloud cost management in single cloud or multi-cloud environment
5.1.1.4.2. Align accountability to cloud users
5.1.1.4.3. Build confidence around budgets and forecasts
5.1.1.4.4. Advance communication throughout the organization
5.1.1.5. When have won
5.1.1.5.1. The centralized FinOps team is properly funded to solve the centralized functional activities of FinOps, reducing duplicated effort by individual teams and guiding the company along its ever increasing FinOps maturity.
5.1.1.5.2. All teams communicate effectively with one another on a regular cadence, using automation and common platforms and a common vocabulary.
5.1.1.5.3. The constant updates to cloud services, new offerings, and regular creation and deletion of systems according to value derived are taken in stride across all disciplines.
5.1.2. Leadership
5.1.2.1. CEO
5.1.2.1.1. Objectives
5.1.2.1.2. Concern
5.1.2.1.3. Challenges
5.1.2.1.4. Key Metrics
5.1.2.1.5. FinOps Benefits
5.1.2.1.6. Motivations
5.1.2.2. CFO
5.1.2.2.1. Objectives
5.1.2.2.2. Concern
5.1.2.2.3. Challenges
5.1.2.2.4. Key Metrics
5.1.2.2.5. FinOps Benefits
5.1.2.2.6. Motivations
5.1.2.3. CIO/CTO
5.1.2.3.1. Objectives
5.1.2.3.2. Concern
5.1.2.3.3. Challenges
5.1.2.3.4. Key Metrics
5.1.2.3.5. FinOps Benefits
5.1.2.3.6. Motivations
5.1.2.3.7. When have won
5.1.3. Product
5.1.3.1. Objectives
5.1.3.1.1. Accelerate Product Growth YoY
5.1.3.1.2. Decrease time to market
5.1.3.1.3. Deliver innovative, market leading solutions cost effectively
5.1.3.2. Concern
5.1.3.2.1. Why did the product get moved to the cloud?
5.1.3.2.2. Are you receiving cloud consumption showback reports or being charged back for cloud use?
5.1.3.2.3. Have the costs of compute and digital storage capabilities gone down since moving to the cloud?
5.1.3.3. Challenges
5.1.3.3.1. Unpredictable, sometimes chaotic, cloud spend
5.1.3.3.2. Cannot predict the costs closely enough for new features and products resulting in pricing misses
5.1.3.3.3. Cannot predict how costs will change when launching existing products in new regions/markets
5.1.3.4. Key Metrics
5.1.3.4.1. Revenue Growth
5.1.3.4.2. Gross Margins
5.1.3.4.3. COGS (Cost of Goods Sold)
5.1.3.4.4. Unit Cost Economics – Cost per customer, Cost per product/feature
5.1.3.5. FinOps Benefits
5.1.3.5.1. Manage risk
5.1.3.5.2. Connect product decisions with business outcomes
5.1.3.5.3. Predict how much cloud infrastructure will factor into feature/ product price
5.1.3.5.4. Guide team to make good cloud investments
5.1.3.6. When have won
5.1.3.6.1. Architectures are created by engineers with cost in mind from the beginning.
5.1.3.6.2. Engineers include cost as a first-class metric, using it not only in build decisions, but also as an ongoing metric in their core KPIs to prioritize development work.
5.1.3.6.3. FinOps certification and maturity metrics become a part of their job requirements, training programs, and incentive plans.
5.1.3.6.4. Things that are scalable, elastic, or have dependencies on cloud services are all moved to cloud.
5.1.3.6.5. Product teams consider and regularly look at cost in product pricing and other decisions.
5.1.3.6.6. Engineering has a fully cloud-focused development platform with an integration pipeline and a DevOps approach. It is deploying resources only with automation and has a fully tagged environment, with consistent account and tag strategies tied to budgets aligned with business outcomes
5.1.4. Engineering
5.1.4.1. Objectives
5.1.4.1.1. Drive accountability to engineering teams that are responsible for the application/services.
5.1.4.1.2. Provide guidance to engineering teams to have a cost-effective application/service by identifying anomalies and best practices.
5.1.4.1.3. Work together with engineering teams to identify rate reductions and possible cost avoidance
5.1.4.1.4. Cost allocation
5.1.4.2. Concern
5.1.4.2.1. How is cloud use monitored?
5.1.4.2.2. What are the highest consuming workloads?
5.1.4.2.3. Are any cloud optimization processes applied during application/system migration? Or, is “lift and shift” predominately used?
5.1.4.2.4. Are they monitoring for anomalies? If yes, how are anomalies identified and mitigated?
5.1.4.2.5. Are they consulted during cloud budget formation or execution?
5.1.4.2.6. Do they have any recommendations for optimizing cloud workloads?
5.1.4.3. Challenges
5.1.4.3.1. Unsatisfied engineers as their workload keeps rising.
5.1.4.3.2. Long delivery cycles
5.1.4.3.3. Cannot predict the impact on the budget
5.1.4.3.4. Difficult to identify service or application ownership
5.1.4.3.5. Cannot predict the costs closely enough for developing new features and products.
5.1.4.4. Key Metrics
5.1.4.4.1. Revenue by infrastructure costs
5.1.4.4.2. Cost per deployed service & service utilization rates
5.1.4.4.3. Showback & Chargeback of IT costs to the business
5.1.4.5. FinOps Benefits
5.1.4.5.1. Increased visibility to cloud cost
5.1.4.5.2. Connection to cloud cost and unit economics
5.1.4.5.3. More accountability for utilization
5.1.4.5.4. Incentive towards solid architecture principles to factor efficiency
5.1.4.6. Motivations
5.1.4.6.1. Want to work on hard problems that are meaningful and challenging
5.1.4.6.2. Want to deliver software quickly and reliably
5.1.4.6.3. Hate inefficiency and want efficient use of resources
5.1.4.6.4. Stay up to speed on the latest tech
5.1.4.6.5. Are measured by performance, uptime, and resilience
5.1.4.6.6. Want to deliver features, fix bugs, and improve performance
5.1.4.7. When have won
5.1.4.7.1. Architectures are created by engineers with cost in mind from the beginning.
5.1.4.7.2. Engineers include cost as a first-class metric, using it not only in build decisions, but also as an ongoing metric in their core KPIs to prioritize development work.
5.1.4.7.3. FinOps certification and maturity metrics become a part of their job requirements, training programs, and incentive plans.
5.1.4.7.4. Things that are scalable, elastic, or have dependencies on cloud services are all moved to cloud.
5.1.4.7.5. Product teams consider and regularly look at cost in product pricing and other decisions.
5.1.4.7.6. Engineering has a fully cloud-focused development platform with an integration pipeline and a DevOps approach. It is deploying resources only with automation and has a fully tagged environment, with consistent account and tag strategies tied to budgets aligned with business outcomes
5.1.5. Finance
5.1.5.1. Objectives
5.1.5.1.1. Cost out and budget maintenance
5.1.5.1.2. Prepare accurate forecasts
5.1.5.1.3. Report actual costs and trends
5.1.5.1.4. Normalize spend predictability
5.1.5.2. Concern
5.1.5.2.1. How are cloud invoices processed?
5.1.5.2.2. What is the organization currently spending on cloud monthly? Annually?
5.1.5.2.3. How is cloud spending estimated and budgeted for?
5.1.5.2.4. Who is consulted during cloud budget formulation?
5.1.5.2.5. How are cloud costs allocated?
5.1.5.2.6. Is showback or chargeback being used with organizational cloud consumers?
5.1.5.2.7. Do you have any examples of unanticipated cloud cost spikes or substantial budget overruns?
5.1.5.3. Challenges
5.1.5.3.1. Unpredictable, sometimes chaotic, cloud spend
5.1.5.3.2. Frustrated team as cloud cost accountability is distributed
5.1.5.3.3. Challenges with legacy finance models (cap-ex vs op-ex)
5.1.5.4. Key Metrics
5.1.5.4.1. Revenue Growth
5.1.5.4.2. Gross Margins
5.1.5.4.3. COGS (Cost of Goods Sold)
5.1.5.4.4. Unit Cost Economics
5.1.5.4.5. Budget and forecast transparency and accuracy
5.1.5.4.6. Policy compliance
5.1.5.5. FinOps Benefits
5.1.5.5.1. Identify unallocated spend
5.1.5.5.2. Facilitate showback/chargebacks to increase financial accountability
5.1.5.5.3. Drive budget and forecast accuracy
5.1.5.5.4. Guide team to make good cloud investments
5.1.5.6. Motivations
5.1.5.6.1. Want to accurately forecast and predict spending
5.1.5.6.2. Want to be able to charge back and/or allocate 100% of spending
5.1.5.6.3. Seek to amortize costs appropriately to the teams responsible
5.1.5.6.4. Want to split out shared costs, like support and shared services
5.1.5.6.5. Want to control and reduce costs, but maintain quality/speed
5.1.5.6.6. Want to help executives inform cloud strategy
5.1.5.6.7. Want to be aware of budget risks ahead of time
5.1.5.7. When have won
5.1.5.7.1. Finance has moved to an agile forecasting and budgeting process, empowered by all engineering teams who take responsibility for their own forecasts and budgets.
5.1.5.7.2. Overhead on assets previously used in the data center are written down and eliminated.
5.1.5.7.3. Finance provides ongoing input to operational allocation requirements like tag prerequisites that overlay existing accounting constructs to applications, and also access to data exports required for agile forecasting and budgeting.
5.1.6. Procurement
5.1.6.1. Objectives
5.1.6.1.1. Negotiate the best win-win cloud contract
5.1.6.1.2. Exercise enterprise discount / volume commitment programs
5.1.6.1.3. Manage relationship with Cloud platform provider
5.1.6.2. Concern
5.1.6.2.1. Are CSPs contracted directly or through resellers?
5.1.6.2.2. Are one or three-year commitments being used?
5.1.6.2.3. Are any CSP discounted rates being applied (ex. Enterprise Discounts)?
5.1.6.2.4. Are any Commitment Based Discounts (ex. Savings Plans or Reserved Instances) being used?
5.1.6.2.5. How are CSP commitments scheduled/timed? Once a year? As needed?
5.1.6.3. Challenges
5.1.6.3.1. Lack of visibility to cloud cost data
5.1.6.3.2. Lack of centralized process for cloud commitments
5.1.6.4. Key Metrics
5.1.6.4.1. Software license optimization
5.1.6.4.2. Cost per license
5.1.6.4.3. Utilization of licenses per team
5.1.6.4.4. Cost or IT Spend per Vendor to provide possible consolidation opportunities
5.1.6.5. FinOps Benefits
5.1.6.5.1. Obtain the best cloud cost rates available
5.1.6.5.2. Translate billing data to activity based costing
5.1.6.5.3. Provide visibility and enable understanding of cost per technology license and contracts
5.1.6.6. Motivations
5.1.6.6.1. Traditionally measured on discounts achieved during negotiations
5.1.6.6.2. Wish to ensure spend is in line with vendor agreements
5.1.6.6.3. Want to build relationships with strategic vendor-partners
5.1.6.6.4. Want to negotiate and renew vendor contracts
5.2. Allied Personas
5.2.1. ITSM / ITIL
5.2.1.1. IT Service Management is responsible for collaborating with FinOps Practitioners to standardize and streamline IT service operations, improve service quality and reliability, and ensure that IT services meet agreed-upon service levels and performance targets are balanced against cloud cost management priorities.
5.2.1.2. Responsibilities intersecting with FinOps
5.2.1.2.1. Service Design
5.2.1.2.2. Service Operation & Improvement
5.2.1.2.3. Service Level Monitoring & Management
5.2.1.2.4. Change Management
5.2.1.2.5. Cost Analysis and Optimization
5.2.1.2.6. Documentation and Reporting
5.2.1.2.7. Stakeholder Collaboration
5.2.2. ITAM
5.2.2.1. IT Asset Management collaborates with FinOps Practitioners to achieve efficiency, transparency, and value in managing IT assets that impact cloud use, by leveraging the expertise and data from both disciplines to optimize costs, ensure compliance, and support strategic business objectives balanced against cloud cost management priorities.
5.2.2.2. Responsibilities intersecting with FinOps
5.2.2.2.1. Asset Discovery and Inventory
5.2.2.2.2. Asset Auditing and Compliance
5.2.2.2.3. License Management
5.2.2.2.4. Cost Analysis and Optimization
5.2.2.2.5. Documentation and Reporting
5.2.2.2.6. Stakeholder Collaboration
5.2.3. ITFM
5.2.3.1. IT Financial Management is responsible for collaborating with FinOps Practitioners to provide transparency into IT spending, enable informed decision-making, ensuring cloud and traditional IT investments are aligned with business priorities, cost-effective, and deliver measurable value to the organization.
5.2.3.2. Responsibilities intersecting with FinOps
5.2.3.2.1. Budgeting
5.2.3.2.2. Cost Accounting & Optimization
5.2.3.2.3. Financial Analysis
5.2.3.2.4. Investment Prioritization
5.2.3.2.5. Financial Reporting
5.2.3.2.6. Continuous Process Improvements
5.2.3.2.7. Documentation and Reporting
5.2.3.2.8. Stakeholder Collaboration
5.2.4. Security
5.2.4.1. IT Security collaborates with FinOps Practitioners to leverage their FinOps expertise and insights to optimize cloud security spending, improve IT Security financial governance, and strengthen the organization's overall cloud security posture.
5.2.4.2. Responsibilities intersecting with FinOps
5.2.4.2.1. Monitoring and Anomaly Response
5.2.4.2.2. Anomaly Investigation and Analysis
5.2.4.2.3. Policy and Compliance
5.2.4.2.4. Identity and Access Management
5.2.4.2.5. Documentation and Reporting
5.2.4.2.6. Stakeholder Collaboration
5.2.5. Sustainability
5.2.5.1. Sustainability collaborates with FinOps Practitioners to ensure cloud use optimizes for environmental impact, drive accountability, and accelerate progress towards broader sustainability goals in a way that is balanced against cloud cost management priorities.
5.2.5.2. Responsibilities intersecting with FinOps
5.2.5.2.1. Optimization for Sustainable Initiatives
5.2.5.2.2. Waste Reduction
5.2.5.2.3. Policy and Compliance
5.2.5.2.4. Efficiency and Optimization Analysis
5.2.5.2.5. Documentation and Reporting
5.2.5.2.6. Stakeholder Collaboration
6. Domain & Capabilities
6.1. Understand Cloud Usage & Cost
6.1.1. Data Ingestion
6.1.1.1. Key Activities
6.1.1.1.1. Manage data sources
6.1.1.1.2. Ensure data quality
6.1.1.1.3. Maintain data timeliness and availability
6.1.1.2. Definition
6.1.1.2.1. Data Ingestion conducts FinOps
6.1.1.2.2. Support FinOps activitie
6.1.1.3. Maturity Assessment
6.1.1.3.1. Crawl
6.1.1.3.2. Walk
6.1.1.3.3. Run
6.1.1.4. Personas Activities
6.1.1.4.1. FinOps Practitioner
6.1.1.4.2. Product
6.1.1.4.3. Finance
6.1.1.4.4. Procurement
6.1.1.4.5. Engineering
6.1.1.4.6. Leadership
6.1.1.4.7. Allied Personas
6.1.1.5. Input & Output
6.1.1.5.1. Cloud provider cost and usage data (e.g. Azure Billing, Google Cloud Billing, AWS CUR, Oracle Billing Data) generated at the required granularity, resolution & cadence
6.1.1.5.2. FOCUS datasets for cloud provider usage & cost data plus any supplementary data such as sustainability, observability, SaaS, …etc
6.1.1.5.3. Utilization, performance, or observability data containing system metrics including CPU, Memory, Disk, and/or Network utilization at the required resource or resource group level
6.1.1.5.4. Transactional data from logs or systems which record the number or quantity of use for types of resources (often shared resources)
6.1.1.5.5. Business performance data providing contextual business data such as the number of customers supported, amount of revenue or sales, number of transactions, or other business outcomes which provide context to ingested cloud cost and usage data
6.1.1.5.6. KPI requirements as determined from Unit Economics activities to support collection and correlation of data elements in the FinOps data repository
6.1.1.5.7. Policy and Governance requirements to support the overall cloud policies and performance of other FinOps requirements with the ingested data
6.1.1.6. KPIs
6.1.1.6.1. Cloud Provider data received daily/multiple times per day at expected times; For example:
6.1.1.6.2. All required data sources identified, consistently formatted and available as outlined in established agreements
6.1.1.6.3. Data quality checks complete successfully
6.1.1.6.4. FOCUS validator checks complete successfully
6.1.1.6.5. Reports of data quality or availability issues from automated notifications or reported issues investigated within 1 business day, resolved within 3 business days
6.1.1.6.6. Ingestion and Processing of data operating within expected time parameters
6.1.1.6.7. Changes in data sources are identified within 1 business day of change, and storage or processing parameters are adjusted to accommodate within 3 business days
6.1.1.6.8. New sources of data, additional granularity, or new data correlations are identified and enabled as required
6.1.1.6.9. Data Currency – time since last update from each data source, compared to expected update time
6.1.1.6.10. Ingest time – time elapsed from receipt of a new version of data from each data source to time of storage of raw data in the FinOps data repository, compared to expected time
6.1.1.6.11. ETL/Normalization/Correlation time – time elapsed from storage of raw data from each source to completing data correlation, normalization, transformation, and storage of adjusted data in the FinOps data repository, compared to expected time
6.1.1.6.12. Percentage (%) of total cost available for reporting in normalized fashion
6.1.1.6.13. Percentage (%) of matching metadata elements
6.1.2. Allocation
6.1.2.1. Key Activities
6.1.2.1.1. Maintain an allocation strategy
6.1.2.1.2. Maintain a tagging & hierarchy strategy
6.1.2.1.3. Maintain a shared cost strategy
6.1.2.1.4. Validate allocation compliance
6.1.2.2. Definition
6.1.2.2.1. The allocation strategy defining how costs should be mapped to the organization
6.1.2.2.2. The tagging or metadata strategy defining how cloud usage and resources will be mapped to the defined parts of the organization
6.1.2.2.3. The shared cost strategy which defines how each set of shared resources will be allocated to budgets
6.1.2.3. Maturity Assessment
6.1.2.3.1. Crawl
6.1.2.3.2. Walk
6.1.2.3.3. Run
6.1.2.4. Personas Activities
6.1.2.4.1. FinOps Practitioner
6.1.2.4.2. Product
6.1.2.4.3. Finance
6.1.2.4.4. Engineering
6.1.2.4.5. Leadership
6.1.2.4.6. Allied Personas
6.1.2.5. Input & Output
6.1.2.5.1. Provide requirements to inform Data Ingestion activities as a feedback loop for improving Allocation strategy goals
6.1.2.5.2. Receive requirements from initiatives related to Reporting & Analytics activities to inform the requirements of Allocation mappings to achieve organizational reporting goals
6.1.2.5.3. Incorporate Cloud Adoption Frameworks / Architecture Frameworks from Cloud Service Providers
6.1.2.5.4. Consolidate existing tag/label standards and establish consistent naming conventions
6.1.2.5.5. Overlay the organizational business metadata for each element of allocation metadata. For example: constructs like Project Names, Application IDs, Cost Center IDs, …etc.
6.1.2.5.6. Establish reports that surface any spend that is not allocated by the established allocation metadata
6.1.2.5.7. Align roles for organizational P&L groupings to map cost ownership back to Invoicing & Chargeback activities
6.1.2.5.8. Leverage the capabilities of CI/CD, platform, cloud provider capabilities
6.1.2.5.9. Ensure allocation requirements align with Policy & Governance activities, including tag compliance, allocation compliance, governance mechanisms
6.1.2.6. KPIs
6.1.2.6.1. General KPI
6.1.2.6.2. Mapping Business Metadata
6.1.2.6.3. Uncategorized Cost Percentage
6.1.2.6.4. Metadata Compliance
6.1.2.6.5. Stakeholder Notifications
6.1.2.6.6. Investigation Response Time
6.1.2.6.7. Cost Trend Variance
6.1.2.6.8. Continuous Improvement in Accuracy
6.1.2.6.9. Resource Deployment Compliance
6.1.2.6.10. Training and Awareness
6.1.3. Reporting & Analytics
6.1.3.1. Key Activities
6.1.3.1.1. Access cloud data and contextual information
6.1.3.1.2. Report on cloud
6.1.3.1.3. Support reporting and analytics needs across personas
6.1.3.2. Definition
6.1.3.3. Maturity Assessment
6.1.3.3.1. Crawl
6.1.3.3.2. Walk
6.1.3.3.3. Run
6.1.3.4. Personas Activities
6.1.3.4.1. FinOps Practitioner
6.1.3.4.2. Engineering
6.1.3.4.3. Finance
6.1.3.4.4. Procurement
6.1.3.4.5. Product
6.1.3.4.6. Leadership
6.1.3.4.7. Allied Personas
6.1.3.5. Input & Output
6.1.3.5.1. Input
6.1.3.5.2. Output
6.1.3.6. KPIs
6.1.3.6.1. Overall Tagging Compliance is greater than 90%
6.1.3.6.2. Context relevant cloud cost reporting data available to al Core Personas
6.1.3.6.3. Architecting products and services to support publishing information related to their unit economics
6.1.3.6.4. FinOps team can define desired level of commitment coverage vs. utilization
6.1.3.6.5. Self-service reporting and ability for ad hoc analysis about anomalies, utilization, cost outliers, budgets and forecast variances available to all Core Personas
6.1.3.6.6. Reduced investigative time for analysis of cloud usage and cost reporting questions
6.1.3.6.7. Increase in awareness, accountability and sustainability impact for cloud spend across all Core Personas
6.1.4. Anomaly Management
6.1.4.1. Key Activities
6.1.4.1.1. Detect anomalies
6.1.4.1.2. Enable anomaly detection
6.1.4.1.3. Manage anomalies
6.1.4.2. Definition
6.1.4.3. Maturity Assessment
6.1.4.3.1. Crawl
6.1.4.3.2. Walk
6.1.4.3.3. Run
6.1.4.4. Personas Activities
6.1.4.4.1. FinOps Practitioner
6.1.4.4.2. Engineering
6.1.4.4.3. Product
6.1.4.4.4. Finance
6.1.4.4.5. Procurement
6.1.4.4.6. Leadership
6.1.4.5. Input & Output
6.1.4.5.1. Cloud cost and usage data provided via Data Ingestion capability
6.1.4.5.2. Anomaly detection tooling (cloud provider, tooling vendor, homegrown tool)
6.1.4.5.3. Cost allocation metadata established and aligned to the organization’s reporting needs
6.1.4.5.4. Allocation strategy assigning usage to specific teams responsible for its oversight
6.1.4.5.5. Anomalous spend notification to stakeholder teams
6.1.4.5.6. Stakeholder real-time visibility into cost and usage reporting data
6.1.4.5.7. Cloud Policy & Governance associated with expectations for managing anomalies
6.1.4.5.8. Documentation of detection, analysis, and resolution processes and expectation of personas
6.1.4.5.9. Reporting & Analysis will be required to investigate and analyze anomalous spending
6.1.4.5.10. Workload optimization may be required to remediate usage-based causes of anomalous spending or to turn off resources which are not being used
6.1.4.6. KPIs
6.1.4.6.1. The count of anomalies within a period of time (week, month) in aggregate or for meaningful subset of usage
6.1.4.6.2. Consistent identification of anomalous spending vs. missed vs. false positives
6.1.4.6.3. Amount of cost associated with anomaly alerts within a period of time (week, month); represents total anomaly detection scope
6.1.4.6.4. Mean time to detect anomalies over a period of time (week, month); documents efficiency and effectiveness of tools used
6.1.4.6.5. Mean time to notify owner of anomalies over a period of time (week, month); documents the time it takes from the anomaly detection to the appropriate owner acknowledging it
6.1.4.6.6. Duration of unresolved anomalies over a period of time (week, month); the velocity of anomaly resolution
6.1.4.6.7. Time to investigate and address an identified anomaly; time of investigation of a true anomaly is real time wasted cost in many cases
6.1.4.6.8. % of teams educated on how variable cloud spending can lead to anomalous spending, definition of what is anomalous, who is accountable, how to respond
6.1.4.6.9. The count of actioned anomalies and spending amount avoided (to nearest following billing period); the amount of cost saved through resolution of anomalies that would have gone unresolved until the bill was received
6.1.4.6.10. The count of unactionable anomalies and categorized but justification to ignore (i.e. new service, performance testing, customer peak, false alert) by category
6.1.4.6.11. Tracking number of alerts suspended (ignored) to identify teams who might not be adhering to protocol or policy
6.1.4.6.12. Percentage of anomalies managed using automation of various categories; this documents the effectiveness of automation put in place
6.2. Quantify Business Value
6.2.1. Planning & Estimating
6.2.1.1. Key Activities
6.2.1.1.1. Explore scenario(s) in the cloud
6.2.1.1.2. Estimate business value for defined scenario(s)
6.2.1.1.3. Implementation plan
6.2.1.2. Definition
6.2.1.2.1. Cost Calculators
6.2.1.2.2. Carbon Calculators
6.2.1.2.3. Similar Applications
6.2.1.2.4. Extrapolation from past cost
6.2.1.2.5. Expectations of future plans
6.2.1.2.6. Trial-run estimation
6.2.1.3. Maturity Assessment
6.2.1.3.1. Crawl
6.2.1.3.2. Walk
6.2.1.3.3. Run
6.2.1.4. Personas Activities
6.2.1.4.1. FinOps Practitioner
6.2.1.4.2. Product
6.2.1.4.3. Finance
6.2.1.4.4. Engineering
6.2.1.4.5. Leadership
6.2.1.4.6. Allied Personas
6.2.1.5. Input & Output
6.2.1.5.1. Input
6.2.1.5.2. Output
6.2.1.6. KPIs
6.2.1.6.1. Estimating models leverage discount-adjusted, amortized cloud usage data
6.2.1.6.2. Estimate cost vs actual cost trends within established percentage threshold of variance.
6.2.1.6.3. Estimates are conducted quickly and with appropriate mechanisms that tie to business objectives
6.2.1.6.4. Estimates include shared costs, appropriate pricing metrics, sustainability impacts, and other appropriate elements
6.2.1.6.5. Meeting Cadence established (time specific) – ??
6.2.1.6.6. Unit costs and usage KPIs specific to your company are established (using PPAs, EDPs, etc) – assists in forecasting
6.2.2. Forecasting
6.2.2.1. Key Activities
6.2.2.1.1. Manage the forecasting strategy
6.2.2.1.2. Create forecast models
6.2.2.1.3. Track & Manage forecasts
6.2.2.2. Definition
6.2.2.3. Maturity Assessment
6.2.2.3.1. Crawl
6.2.2.3.2. Walk
6.2.2.3.3. Run
6.2.2.4. Personas Activities
6.2.2.4.1. FinOps Practitioner
6.2.2.4.2. Product
6.2.2.4.3. Finance
6.2.2.4.4. Procurement
6.2.2.4.5. Engineering
6.2.2.4.6. Leadership
6.2.2.5. Input & Output
6.2.2.5.1. Input
6.2.2.5.2. Output
6.2.2.6. KPIs
6.2.2.6.1. Forecast models leverage discount-adjusted, amortized cloud usage data
6.2.2.6.2. Forecast cost vs actual cost trends within established percentage threshold of variance. According to the FinOps Community of Practitioners, acceptable levels of forecasting accuracy translates to a maximum 20% variance from actual spend for a FinOps practice operating at a Crawl maturity level; a 15% variance for a FinOps practice operating at a Walk maturity level; and 12% variance for a FinOps practice operating at a Run maturity level.
6.2.2.6.3. Stakeholder notifications for forecast variance threshold exceeded & risk of budget overspend
6.2.2.6.4. Forecast frequency that includes intermediate forecasts to update budgets based on business drivers
6.2.2.6.5. Teams and Business Units are responsible for managing their budgets based on forecast data
6.2.3. Budgeting
6.2.3.1. Key Activities
6.2.3.1.1. Create cloud budgeting strategy
6.2.3.1.2. Set Budgets
6.2.3.1.3. Track and manage budgets
6.2.3.2. Definition
6.2.3.2.1. Budget threshold reports anticipate exceeding budget (Engineering)
6.2.3.2.2. Investigate the reasons for the overage (Engineering, Product)
6.2.3.2.3. Involve budget owner to request additional funding from holdback (Engineering, Product, and Budget Owner)
6.2.3.2.4. Involve higher level budget owner, or Finance directly to review the request (Engineering, Budget Owner, Product, Finance)
6.2.3.2.5. Involve Leadership to make adjustments to budgeted spending levels and record/adjust impacts to organizational performance expectations (Engineering, Product, Finance, Leadership)
6.2.3.3. Maturity Assessment
6.2.3.3.1. Crawl
6.2.3.3.2. Walk
6.2.3.3.3. Run
6.2.3.4. Personas Activities
6.2.3.4.1. FinOps Practitioner
6.2.3.4.2. Product
6.2.3.4.3. Finance
6.2.3.4.4. Procurement
6.2.3.4.5. Engineering
6.2.3.4.6. Leadership
6.2.3.5. Input & Output
6.2.3.5.1. Input
6.2.3.5.2. Output
6.2.3.6. KPIs
6.2.3.6.1. Budgeting leverages appropriate discount-adjusted, amortized cloud usage data, as identified in the Budgeting Strategy
6.2.3.6.2. Budget vs actual cost trends within established percentage threshold of variance. Acceptable levels of budget variance is maximum 20% variance from actual spend for a FinOps practice operating at a Crawl maturity level; a 15% variance for a FinOps practice operating at a Walk maturity level; and 12% variance for a FinOps practice operating at a Run maturity level
6.2.3.6.3. Stakeholder notifications for actual or anticipated budget variance threshold exceeded & risk of budget overspend
6.2.3.6.4. Budget cadence that includes rolling forecasts to update budgets based on business drivers
6.2.3.6.5. Teams and Business Units are responsible for managing their budgets based on forecast data and actual cost, usage, and impact
6.2.4. Unit Economics
6.2.4.1. Key Activities
6.2.4.1.1. Define Unit Metrics which support Organizational Goals
6.2.4.1.2. Ensure Unit Economic data is available
6.2.4.1.3. Validate Impact of Unit Metrics
6.2.4.2. Definition
6.2.4.2.1. Unit metrics can generally be sorted into two broad categories:
6.2.4.3. Maturity Assessment
6.2.4.3.1. Crawl
6.2.4.3.2. Walk
6.2.4.3.3. Run
6.2.4.4. Personas Activities
6.2.4.4.1. FinOps Practitioner
6.2.4.4.2. Product
6.2.4.4.3. Finance
6.2.4.4.4. Procurement
6.2.4.4.5. Engineering
6.2.4.4.6. Leadership
6.2.4.5. Input & Output
6.2.4.5.1. Data Ingestion cloud cost data, business relevant value data, requirements for common repository of usage data
6.2.4.5.2. Business Performance data from operational areas being measured with Unit Economics
6.2.4.6. KPIs
6.2.4.6.1. Defining KPIs to measure the success of using KPIs can be challenging.
6.2.4.6.2. Organizational success in this capability could be measured in terms of the percentage of teams, personas, or stakeholders that are using unit economics metrics to communicate about cloud use.
6.2.4.6.3. The use of both resource utilization unit metrics and business unit metrics should be in place for any areas of cost which impact the organization’s business results, or which drive large amounts of value.
6.2.4.6.4. Automation, or the ability to automatically calculate unit economics metrics using repositories which are well documented, accessible, and correlated should be apparent in metrics which are critical to broader business decision making.
6.2.4.6.5. Regular review and consideration of appropriate KPIs, and periodic analysis of the impacts of unit economics use should be in place to allow for adjustment of metrics where needed, addition of new metrics to drive additional good behavior, or retirement of metrics which no longer serve the needs of the organization.
6.2.5. Benchmarking
6.2.5.1. Key Activities
6.2.5.1.1. Determine Organizational Benchmarks
6.2.5.2. Definition
6.2.5.3. Maturity Assessment
6.2.5.3.1. Crawl
6.2.5.3.2. Walk
6.2.5.3.3. Run
6.2.5.4. Personas Activities
6.2.5.4.1. FinOps Practitioner
6.2.5.4.2. Product
6.2.5.4.3. Finance
6.2.5.4.4. Engineering
6.2.5.4.5. Leadership
6.2.5.4.6. Allied Personas
6.2.5.5. Input & Output
6.2.5.5.1. Unit Economics – understand which KPIs will benefit decision making via benchmarking
6.2.5.5.2. Reporting & Analytics – to get dashboards and reporting to support internal benchmarking efforts
6.2.5.5.3. Points of comparison from external cloud using organizations
6.2.5.6. KPIs
6.2.5.6.1. Sets of targeted and well-documented KPIs selected for benchmarking which inform decision making in meaningful ways
6.2.5.6.2. Important internal teams providing benchmark opportunities to identify good cloud use and FinOps practices across the organization
6.2.5.6.3. Leadership and FinOps teams can compare high level cloud performance with other external parties through appropriate channels and with appropriate data controls
6.3. Optimize Cloud Usage & Cost
6.3.1. Architecting for Cloud
6.3.1.1. Key Activities
6.3.1.1.1. Evaluate systems for attention
6.3.1.1.2. Understand cost effective designs
6.3.1.1.3. Establish an effective cadence
6.3.1.2. Definition
6.3.1.3. Maturity Assessment
6.3.1.3.1. Crawl
6.3.1.3.2. Walk
6.3.1.3.3. Run
6.3.1.4. Personas Activities
6.3.1.4.1. FinOps Practitioner
6.3.1.4.2. Product
6.3.1.4.3. Finance
6.3.1.4.4. Engineering
6.3.1.4.5. Leadership
6.3.1.5. Input & Output
6.3.1.5.1. Input
6.3.1.5.2. Output
6.3.1.6. KPIs
6.3.1.6.1. Measurement of cost efficiency through infrastructure savings, migration and support costs
6.3.1.6.2. Operational resiliency improvement in service quality and security risk posture
6.3.1.6.3. Decrease time to market by accelerating fluidity in product and service delivery
6.3.1.6.4. Enable a culture of rapid experimentation to drive innovation and cloud transformation
6.3.1.6.5. Embed true environmental and social sustainability across the organization
6.3.2. Cloud Sustainability
6.3.2.1. Key Activities
6.3.2.1.1. Determine Cloud Sustainability policies and guidelines
6.3.2.2. Definition
6.3.2.3. Maturity Assessment
6.3.2.3.1. Crawl
6.3.2.3.2. Walk
6.3.2.3.3. Run
6.3.2.4. Personas Activities
6.3.2.4.1. FinOps Practitioner
6.3.2.4.2. Product
6.3.2.4.3. Finance
6.3.2.4.4. Procurement
6.3.2.4.5. Engineering
6.3.2.4.6. Leadership
6.3.2.4.7. Allied Personas
6.3.2.5. Input & Output
6.3.2.5.1. Work with Data Ingestion to obtain cloud provider and other vendor sustainability reporting and carbon data
6.3.2.5.2. Cloud Provider and vendor sustainability contextual information and optimization recommendations (e.g. comparisons of the carbon impact of various types of compute resources or locations) used for decision making
6.3.2.5.3. Third party data and recommendations for carbon reduction opportunities
6.3.2.5.4. Reporting & Analytics to ensure available sustainability data included in cost reports
6.3.2.5.5. Unit Economics to ensure sustainability data included in key metrics
6.3.2.5.6. Training, guidance to describe how to manage, view sustainability data (by team, application, etc)
6.3.2.5.7. Intersecting Disciplines where broader organizational sustainability groups exist and require specific reporting, data, or coordination
6.3.2.6. KPIs
6.3.2.6.1. Sustainability reports available for all cloud providers; data normalized across all cloud providers; data aligns to scope/granularity needed for reporting compliance
6.3.2.6.2. Sustainability reports visible to all teams impacted and shown alongside cost data
6.3.2.6.3. Sustainability targets (e.g. carbon budgets) communicated to all teams; all teams can track their progress against targets
6.3.2.6.4. Impact on sustainability is considered during migration and optimization activities
6.3.2.6.5. Clear guidelines for taking action when comparing all types of optimization options, and specifically when sustainability goals conflict with financial goals
6.3.2.6.6. Key terms that are likely to be used in sustainability reports:
6.3.3. Workload Optimization
6.3.3.1. Key Activities
6.3.3.1.1. Creating a workload optimization strategy
6.3.3.1.2. Managing workload optimizations
6.3.3.1.3. Understanding where opportunities have value
6.3.3.2. Definition
6.3.3.2.1. Waste reduction
6.3.3.2.2. Workload Management
6.3.3.2.3. Scaling
6.3.3.2.4. Rightsizing
6.3.3.2.5. Temporal shifting
6.3.3.2.6. Geo Regional shifting
6.3.3.2.7. Modernization
6.3.3.3. Maturity Assessment
6.3.3.3.1. Crawl
6.3.3.3.2. Walk
6.3.3.3.3. Run
6.3.3.4. Personas Activities
6.3.3.4.1. FinOps Practitioner
6.3.3.4.2. Product
6.3.3.4.3. Finance
6.3.3.4.4. Procurement
6.3.3.4.5. Engineering
6.3.3.4.6. Leadership
6.3.3.5. Input & Output
6.3.3.5.1. Input
6.3.3.5.2. Output
6.3.3.6. KPIs
6.3.3.6.1. Data efficiency is applied to at least 50% of stored data (i.e. net savings coverage is >50%)
6.3.3.6.2. Effective $/GB/mo storage rates are reduced by at least 30% relative to the S3 Standard baseline
6.3.3.6.3. KPI Library
6.3.3.6.4. Waste Management library
6.3.3.6.5. Use Unit Economics to create KPIs to measure workload performance metrics per some unit of work. You might consider a compute or throughput metric (e.g. vCPU-Hours), monetary cost, or carbon emissions (CO2e) estimate per customer, transaction, or other similar unit of work.
6.3.4. Rate Optimization
6.3.4.1. Key Activities
6.3.4.1.1. Create a commitment discount strategy
6.3.4.1.2. Support negotiated discounts
6.3.4.1.3. Manage RIs, Savings Plans, and Committed Use Discounts
6.3.4.1.4. Use other mechanisms to optimize rate
6.3.4.2. Definition
6.3.4.3. Maturity Assessment
6.3.4.3.1. Crawl
6.3.4.3.2. Walk
6.3.4.3.3. Run
6.3.4.4. Personas Activities
6.3.4.4.1. FinOps Practitioner
6.3.4.4.2. Product
6.3.4.4.3. Finance
6.3.4.4.4. Procurement
6.3.4.4.5. Engineering
6.3.4.4.6. Leadership
6.3.4.4.7. Allied Personas
6.3.4.5. Input & Output
6.3.4.5.1. Input
6.3.4.5.2. Output
6.3.4.6. KPIs
6.3.4.6.1. Ability to measure the overall effective savings rate of Cloud Rate Optimization efforts for both technology-based and monetary-based commitment discounts
6.3.4.6.2. For resource-based commitment discounts, maintaining a utilization upper-waterline around 80% for steady-state usage
6.3.4.6.3. For spend-based commitment discounts, purchasing commitments with at least 90% savings per dollar of commitment for an established threshold of peak variable usage
6.3.4.6.4. Analysis and purchase decisions for commitments are made in the context of interruptible/batch/highly variable workloads
6.3.4.6.5. Ability to identify unused commitment discounts with daily resolution
6.3.4.6.6. Ability to notify stakeholder teams about expiring commitments with sufficient time to plan a new purchase
6.3.4.6.7. Purchasing of commitment discounts are viewed as investments by stakeholder teams like Execs/Productment/Finance; the investment is the cost of the commitment over the entire period, and the return is the savings provided
6.3.4.6.8. Hybrid purchasing strategy that Aligns commitment terms with infrastructure workload characteristics and lifecycle
6.3.4.6.9. Purchasing commitments that deliver more than 10% return on investment
6.3.4.6.10. Mitigate risk by purchasing commitments with a break-even within 9 months
6.3.4.6.11. Analysis and management is done centrally using a holistic view of the organization’s cloud estate and not at each individual cloud sub-account level
6.3.4.6.12. Analysis for making commitment purchases is supplemented with planned infrastructure and/or workload capacity changes
6.3.4.6.13. Commitment purchases are spread over the year to allow for flexibility by always have some % of commitments expiring; this enables re-evaluation of commitment levels at regular intervals informed by forecasted future usage
6.3.4.6.14. Analysis and purchase decisions for commitments are made in the context of any negotiated commercial discounts offered to enterprises by the cloud service provider in exchange for overall cloud spend
6.3.4.6.15. Altogether, the implementation of these strategies drives an organization’s Effective Savings Rate (ESR). It is important to note that under utilization of a commitment discount would also negatively impact ESR as would significant usage not covered by discounts.
6.3.5. Licensing & SaaS
6.3.5.1. Key Activities
6.3.5.1.1. Understanding Licensing & SaaS Pricing and Purchasing
6.3.5.1.2. Understanding Licenses & SaaS Use in Cloud
6.3.5.1.3. Managing use of Licenses & SaaS
6.3.5.2. Definition
6.3.5.3. Maturity Assessment
6.3.5.3.1. Crawl
6.3.5.3.2. Walk
6.3.5.3.3. Run
6.3.5.4. Personas Activities
6.3.5.4.1. FinOps Practitioner
6.3.5.4.2. Product
6.3.5.4.3. Finance
6.3.5.4.4. Procurement
6.3.5.4.5. Engineering
6.3.5.4.6. Leadership
6.3.5.4.7. Allied Personas
6.3.5.5. Input & Output
6.3.5.5.1. Cloud provider billing and usage data
6.3.5.5.2. Licensing data from SAM/ITAM tools
6.3.5.5.3. SaaS contract details
6.3.5.5.4. Architecting for Cloud to adjust use of licenses and SaaS products in software over time
6.3.5.5.5. Marketplace data well integrated and tagged via Data Ingestion
6.3.5.5.6. Input from license servers/license tracking services in use
6.3.5.5.7. Tagging or other ways to identify where BYOL are being used independently of the licensed type of resource in the cloud billing data (where a virtual resource sold by the cloud provider without a license is running software or OS installed by the customer)
6.3.5.6. KPIs
6.3.5.6.1. License/SaaS costs are visible and reported on
6.3.5.6.2. Licenses purchased through the CSP marketplace are fully utilized
6.3.5.6.3. Resources requiring a license are compliant
6.4. Manage the FinOps Practice
6.4.1. Cloud Policy & Governance
6.4.1.1. Key Activities
6.4.1.1.1. Establish Cloud Policy
6.4.1.1.2. Establish Cloud Governance
6.4.1.2. Definition
6.4.1.3. Maturity Assessment
6.4.1.3.1. Crawl
6.4.1.3.2. Walk
6.4.1.3.3. Run
6.4.1.4. Personas Activities
6.4.1.4.1. FinOps Practitioner
6.4.1.4.2. Product
6.4.1.4.3. Finance
6.4.1.4.4. Procurement
6.4.1.4.5. Engineering
6.4.1.4.6. Leadership
6.4.1.5. Input & Output
6.4.1.5.1. Governance
6.4.1.5.2. Policy
6.4.1.6. KPIs
6.4.1.6.1. Cloud Policy adherence: cost of resources compliant with Cloud Policies / Total Resource cost
6.4.2. FinOps Tools & Services
6.4.2.1. Key Activities
6.4.2.1.1. Manage a tool and service strategy
6.4.2.1.2. Evaluate potential tools and services
6.4.2.1.3. Implement selected tool and services
6.4.2.2. Definition
6.4.2.3. Maturity Assessment
6.4.2.3.1. Crawl
6.4.2.3.2. Walk
6.4.2.3.3. Run
6.4.2.4. Personas Activities
6.4.2.4.1. FinOps Practitioner
6.4.2.4.2. Product
6.4.2.4.3. Finance
6.4.2.4.4. Procurement
6.4.2.4.5. Engineering
6.4.2.4.6. Leadership
6.4.2.5. Input & Output
6.4.2.5.1. Cloud Policy documents
6.4.2.5.2. Security and compliance policies
6.4.2.5.3. Procurement processes
6.4.2.5.4. Requirements from most of the other FinOps Capabilities where tool use will be supportive or services are required
6.4.2.6. KPIs
6.4.2.6.1. total annual cloud cost savings/avoidance generated by the tool/service
6.4.2.6.2. percentage of the target audience successfully adopting the tool/service
6.4.2.6.3. the customer experience score, of the end users, as measured by a positive Net Promoter Score (NPS) metric, or similar
6.4.2.6.4. Post implementation assessment of the tool/service to determine whether it meets the requirements criteria from all stakeholders
6.4.3. FinOps Assessment
6.4.3.1. Key Activities
6.4.3.1.1. Define Assessment Goals
6.4.3.1.2. Set Assessment Baseline
6.4.3.1.3. Continuous Assessment
6.4.3.2. Definition
6.4.3.3. Maturity Assessment
6.4.3.3.1. Crawl
6.4.3.3.2. Walk
6.4.3.3.3. Run
6.4.3.4. Personas Activities
6.4.3.4.1. FinOps Practitioner
6.4.3.4.2. Product
6.4.3.4.3. Finance
6.4.3.4.4. Procurement
6.4.3.4.5. Engineering
6.4.3.4.6. Leadership
6.4.3.5. Input & Output
6.4.3.5.1. FinOps Framework Assessment Tool
6.4.3.5.2. FinOps Framework Assessment Paper
6.4.3.6. KPIs
6.4.3.6.1. Number of FinOps Assessments Completed per year (by capabilities assessed)
6.4.3.6.2. Percentage of Business Units Assessed
6.4.3.6.3. Percentage of FinOps Framework Assessed
6.4.3.6.4. Number of Employees trained in completing FinOps Assessments
6.4.4. FinOps Practice Operations
6.4.4.1. Key Activities
6.4.4.1.1. Build a FinOps team
6.4.4.1.2. Manage the FinOps practice
6.4.4.1.3. Collaborate and make decisions
6.4.4.1.4. Drive stakeholder adoption
6.4.4.2. Definition
6.4.4.3. Maturity Assessment
6.4.4.3.1. Crawl
6.4.4.3.2. Walk
6.4.4.3.3. Run
6.4.4.4. Personas Activities
6.4.4.4.1. FinOps Practitioner
6.4.4.4.2. Product
6.4.4.4.3. Finance
6.4.4.4.4. Procurement
6.4.4.4.5. Engineering
6.4.4.4.6. Leadership
6.4.4.4.7. Allied Personas
6.4.4.5. Input & Output
6.4.4.5.1. FinOps Tools & Services – coordinate on staffing and support needs, tools and resources to make the FinOps team more effective
6.4.4.5.2. FinOps Education & Enablement – coordinate to deliver needed training to all parts of the organization and to the FinOps team itself, to continually develop skills of the FInOps team staff
6.4.4.5.3. Executives and Leadership to support the activities of the FinOps team through executive sponsorship
6.4.4.5.4. HR and Organizational Design groups for FinOps role description development, hiring, skill development, support
6.4.4.6. KPIs
6.4.4.6.1. KPI measuring the savings / cost avoidance generated by the FinOps team are in place to demonstrate the value of FinOps and the effectiveness of the FinOps team
6.4.4.6.2. Organizational awareness of the FinOps team, and adoption of FinOps practices and culture
6.4.4.6.3. FinOps team has ready access to all levels of the organization and all disciplines within the organization to promote FinOps as an operating model and cultural practice
6.4.4.6.4. Use of reporting and dashboards provided by the FinOps teams is widespread. As new, more developed, dashboards or reports are created to track how they are utilized by staff. Use this to confirm staff are engaged with the process and if not look for feedback as to why.
6.4.4.6.5. When cross-functional or urgent business decisions need to be made, the FinOps team has identified a decision model for taking action
6.4.4.6.6. Active sharing of FinOps information within teams or from managers to staff. Confirm with managers that they feel confident using the data provided to share cost and usage information with their staff.
6.4.5. FinOps Education & Enablement
6.4.5.1. Key Activities
6.4.5.1.1. Ensure organizational Alignment
6.4.5.1.2. Enable training programs
6.4.5.2. Definition
6.4.5.2.1. Internal communications, events, and learning experiences, such as all-hands meetings, FinOps centered internal gatherings or “hackathon” style events, or informal brown-bag type gatherings. Some organizations host regular FinOps Day events, gathering engineering, finance, leadership and product personas regularly to provide training on particular capabilities of the FinOps practice, celebrate successes, and reinforce goals and good practices.
6.4.5.2.2. Training via formal or informal channels, provided internally or via external parties such as the FinOps Foundation, Linux Foundation, Cloud Providers, or external learning organizations. Cloud Providers offer standard training at the Practitioner level which covers the basics of their services and operations for all audiences. Cloud providers, publishers and other vendors will often provide training for organizations on the efficient use of, and the environmental impacts of their products
6.4.5.2.3. Conferences and external events, such as FinOps Foundation events, cloud provider, or cloud industry events centered on efficient or effective use of cloud. Major cloud providers offer large annual events, and various regional ones, as does the FinOps Foundation and many of its members.
6.4.5.2.4. Formal definition of requirements, certifications, job skills, and role descriptions for personas involved with FinOps in the organization. Working with internal Training organizations, and human capital programs internally to include FinOps awareness in onboarding, and to ensure FinOps related knowledge is included in job descriptions where required can reduce introductory FinOps training needs in the long term and ensure candidates are well prepared when they arrive.
6.4.5.2.5. Internal repositories of common FinOps documentation, terminology, glossaries, and basic concepts. This accessible, internal virtual team space or library is where terminology can be clearly defined in each discipline, where common processes or practices can be spelled out, and where FinOps deliverables (e.g. Tagging Strategy, Cloud Policies, Optimization Playbooks) can be stored as an organization matures.
6.4.5.3. Maturity Assessment
6.4.5.3.1. Crawl
6.4.5.3.2. Walk
6.4.5.3.3. Run
6.4.5.4. Personas Activities
6.4.5.4.1. FinOps Practitioner
6.4.5.4.2. Product
6.4.5.4.3. Finance
6.4.5.4.4. Procurement
6.4.5.4.5. Engineering
6.4.5.4.6. Leadership
6.4.5.4.7. Allied Personas
6.4.5.5. Input & Output
6.4.5.5.1. FinOps targeted training and enablement
6.4.5.5.2. HR data that tracks training needs, training participation and certifications achieved
6.4.5.5.3. Cross-team FinOps training courses and sharing of best practices
6.4.5.5.4. Brown-bag/Lunch-n-Learn for cross FinOps Persona training
6.4.5.5.5. Centralized knowledge based serving as a repository for FinOps documentation, training materials, and terminology
6.4.5.5.6. Defined communication strategy to evangelize FinOps and communicate impact, value, and successes throughout the organization
6.4.5.5.7. Regular opportunities to ask questions related to cost optimization, cost savings, cost management, cloud sustainability, and other FinOps capabilities
6.4.5.5.8. Centralized forum for any personas to submit questions and feedback to FinOps team
6.4.5.6. KPIs
6.4.5.6.1. Training materials are available to every discipline, at every level to include both generic, and company specific info
6.4.5.6.2. Training is proactively offered both with internal delivery as well as access to external content as applicable
6.4.5.6.3. Employees feel empowered and encouraged to learn about their discipline and other disciplines, and to help in coaching others
6.4.5.6.4. Ongoing opportunities to learn, both formal and informal, are offered consistently over time
6.4.5.6.5. Leadership drives empowerment by promoting skills development, on-the-job learning and encouraging the culture of accountability
6.4.5.6.6. Everyone in the organization understands why FinOps is important and how its practice in their persona discipline provides business value to the organization
6.4.5.6.7. Training opportunities encourage collaboration and cross-fertilization of ideas across different functions
6.4.5.6.8. Training is mindful of providing for different learning styles and needs for different individuals as well as different disciplines and levels of responsibility
6.4.5.6.9. Established centralized knowledge based serving as a repository for FinOps documentation, training materials, and terminology enabling self-directed learning
6.4.5.6.10. Main KPIs
6.4.6. Invoicing & Chargeback
6.4.6.1. Key Activities
6.4.6.1.1. Manage invoicing financial interactions
6.4.6.1.2. Manage chargeback financial interactions
6.4.6.2. Definition
6.4.6.2.1. Timing
6.4.6.2.2. Data accuracy and alignment
6.4.6.2.3. Volume of invoices
6.4.6.3. Maturity Assessment
6.4.6.3.1. Crawl
6.4.6.3.2. Walk
6.4.6.3.3. Run
6.4.6.4. Personas Activities
6.4.6.4.1. FinOps Practitioner
6.4.6.4.2. Product
6.4.6.4.3. Finance
6.4.6.4.4. Procurement
6.4.6.4.5. Engineering
6.4.6.4.6. Leadership
6.4.6.5. Input & Output
6.4.6.5.1. Input
6.4.6.5.2. Output
6.4.6.6. KPIs
6.4.6.6.1. Chargeback Processing Time – Efficiency of chargeback process from cost incur to allocation to the departments, projects and products.
6.4.6.6.2. % of Invoices Paid On-Time – adherence to terms with Service Providers
6.4.6.6.3. General Ledger Recharge Rate (Total and Per Cost Center) – variance between cloud spend in cloud management tool and amount charged in General Ledger
6.4.6.6.4. % Accuracy of Chargebacks – Proper charges allocated to the correct cost center
6.4.6.6.5. % Variance in chargeback estimates vs actuals
6.4.6.6.6. Measures of Success
6.4.7. Onboarding Workloads
6.4.7.1. Key Activities
6.4.7.1.1. Manage onboarding strategy
6.4.7.1.2. Plan migrations
6.4.7.1.3. Coordinate onboarding
6.4.7.2. Definition
6.4.7.3. Maturity Assessment
6.4.7.3.1. Crawl
6.4.7.3.2. Walk
6.4.7.3.3. Run
6.4.7.4. Personas Activities
6.4.7.4.1. FinOps Practitioner
6.4.7.4.2. Product
6.4.7.4.3. Finance
6.4.7.4.4. Procurement
6.4.7.4.5. Engineering
6.4.7.4.6. Leadership
6.4.7.4.7. Allied Personas
6.4.7.5. Input & Output
6.4.7.5.1. Input
6.4.7.5.2. Output
6.4.7.6. KPIs
6.4.7.6.1. Measurement of cost efficiency through infrastructure savings, migration and support costs
6.4.7.6.2. Operational resiliency improvement in service quality and security risk posture
6.4.7.6.3. Decrease time to market by accelerating fluidity in product and service delivery
6.4.7.6.4. Since onboarding workloads can impact so many parts of the business, there can be many KPIs that can effectively measure how well your organization is onboarding workloads. Check out the KPI Library to see which metrics may make the most sense for your organization.
6.4.8. Intersecting Disciplines
6.4.8.1. Key Activities
6.4.8.1.1. Collaborate with appropriate Allied Personas
6.4.8.1.2. Information and Data Coordination
6.4.8.2. Definition
6.4.8.2.1. This capability supports interactions between FinOps and other IT disciplines, frameworks, or teams in an organization. Widespread use of public cloud creates new challenges for traditional IT disciplines, most of which have a broader responsibility than just cloud use. The intention for this capability is to provide a place to capture FinOps’ interactions with these existing IT functions when they are in use by the organization.
6.4.8.2.2. These Financial Standards could include:
6.4.8.3. Maturity Assessment
6.4.8.3.1. Crawl
6.4.8.3.2. Walk
6.4.8.3.3. Run
6.4.8.4. Personas Activities
6.4.8.4.1. FinOps Practitioner
6.4.8.4.2. Product
6.4.8.4.3. Finance
6.4.8.4.4. Procurement
6.4.8.4.5. Engineering
6.4.8.4.6. Leadership
6.4.8.4.7. Allied Personas
6.4.8.5. Input & Output
6.4.8.5.1. FinOps Inputs
6.4.8.5.2. Allied Persona Inputs
6.4.8.5.3. Finance/Financial Inputs
6.4.8.5.4. Organizational Inputs
6.4.8.6. KPIs
6.4.8.6.1. There are some indicators of success that are universal and would apply to both the FinOps Personas and Allied Personas, such as:
6.4.8.6.2. Below are some measures of success along with KPIs that may interest with other frameworks:
6.4.8.6.3. There are a number of KPIs that could be used to help track the effectiveness of your FinOps program overlapping with Allied Personas, such as: