One performance-based fee model pays the service provider a share of the savings calculated using agreed criteria. Services may include analyzing usage and billing data, recommending improvements, and changing configurations. The contract determines the provider's responsibilities and who implements the changes.

For example, if the monthly costs covered by the comparison are ¥1 million before the improvements and ¥800,000 afterward, measured on a like-for-like basis, the savings are ¥200,000. At an assumed fee rate of 30%, the fee would be ¥60,000, leaving net savings of ¥140,000. Include any additional costs when assessing the overall benefit.

When considering external support, compare the scope of services, expected cost savings, and total costs across performance-based, fixed-fee, and other pricing models.

Even with a performance-based fee, achieving real cost savings requires improvements tailored to how the system is used and configured. In some cases, reviewing pricing plans or resource configurations is enough; in others, internal processing must be optimized. The following section looks at database (DB) optimization as one example.

The database is central to business systems. Reducing resources based on cost alone could affect processing speed and system stability. Conversely, concerns about performance may lead organizations to retain more resources than they need.

When reviewing resource usage, look beyond average CPU and memory utilization. Check peak loads, I/O, lock waits, and SQL response times as well. If inefficient SQL queries or indexes are causing the load, consider improving processing performance before reducing resources.

The key is not to assume that reducing resource capacity is the answer. First, identify the underlying causes and confirm performance requirements, then combine processing improvements with changes to the resource configuration.

Assess the current state and define the scope

Review billing details, resource configurations, the departments using the resources, peak periods, and performance requirements. Define the environments and time periods in scope, identify costs excluded from the reduction effort, and establish consistent conditions for comparing results before and after improvements.

Identify workloads and their underlying causes

Review usage during normal and peak periods, compare it with billing data, and identify the main cost drivers. For databases, examine not only CPU and memory usage but also I/O, processing wait times, and SQL response times as needed.

At this stage, identify opportunities for improvement before deciding what action to take.

Evaluate Each Measure Separately

Identify potential measures such as shutting down unused resources, reviewing configurations and pricing plans, and improving SQL queries and indexes. Compare the expected savings, implementation effort, and impact on performance and operations for each measure, then decide which to implement and in what order.

Keep in mind that reducing processing load may not lower your bill for resources priced according to their configuration unless you resize them or make other changes. Check how each improvement will translate into lower costs.

Make changes in stages and monitor the results

Start by making changes in a low-impact setting, such as a test environment. Compare costs, response times, and error rates before and after the changes under consistent conditions, including data volume, processing tasks, and the number of concurrent users. Test both normal operations and expected peak conditions.

Before making changes, decide how long to monitor the results, what criteria to use, and when and how to roll back. For example, business requirements might call for 95% of key processes to finish within 1 second and for the error rate to remain within its existing acceptable limit. Evaluate whether you can meet both requirements while reducing costs. The figures of 95% and 1 second are illustrative, not universal recommendations. Set the actual thresholds based on the requirements of the business process and system.

Even if testing reveals no issues, roll out the change to production in stages. Monitor cost and performance metrics for a predefined period. If the results do not meet the agreed criteria, roll back the change or investigate the cause. Expand the rollout only after confirming that the criteria are met.

Under a performance-based fee model, it is important to distinguish between a lower bill and savings directly attributable to improvement measures. Account for factors such as reduced usage or pricing changes so that results are evaluated on a like-for-like basis.

Compare costs after adjusting for changes in usage

Suppose monthly costs before the improvements were ¥1 million: ¥400,000 in fixed costs and ¥600,000 in costs proportional to the number of transactions processed. After the improvements, the number of transactions falls by 10%, and the monthly bill drops to ¥800,000. Assume that unit prices, exchange rates, discount terms, and other conditions remain unchanged.

In this example, if no improvements were made and only the number of transactions fell, the estimated cost would be ¥400,000 + ¥600,000 × 90% = ¥940,000. The ¥140,000 difference between that estimate and the actual bill of ¥800,000 is attributed to the improvement measures. Of the total ¥200,000 reduction in the bill, the remaining ¥60,000 is due to fewer transactions.

Cloud costs may include fixed charges based on the system configuration or contract term, as well as charges that do not vary directly with usage. Rather than applying a uniform adjustment based on transaction volume, the parties should agree on a method that reflects the service's billing model and cost structure before signing the contract.

What to check before signing a contract

Before signing a contract, confirm the calculation method and the following points.

• Comparison baseline: Which period and data will be used to calculate costs before the improvements?
• Changing Conditions: How Will Usage, Exchange Rates, Discounts, and New Services Be Handled?
• Scope: Which costs count toward the savings, and which are excluded?
• Fee terms: How will the fee rate, minimum and maximum amounts, payment period, and any additional costs be determined?
• Changes and responsibilities: Who approves changes, and how will performance degradation or outages be handled?
• Access and Data: How Will Work Permissions, Data Access, and Data Handling Be Defined?
• After the contract ends: How will configurations, documentation, and operational considerations be handed over?

Document and share these criteria so the results can be evaluated not only by cost savings, but also by performance, availability, and operational workload.