Justifying a PC refresh budget: numbers that convince

How to start the conversation with the finance committee

The finance committee often hears about “slow computers” as an IT nuisance. The conversation moves faster if you immediately convert the problem into money: how much the company loses from downtime, repairs, extra energy consumption and risks. Then a PC refresh budget looks not like a request to “buy hardware” but as a solution to a measurable problem.

You will usually be asked questions that help the committee justify the decision:

• Why not “postpone one more year” and what happens if nothing is done.
• What are the costs not only at purchase but in ownership.
• What losses already exist and where they show up (people's time, deadlines, fines, security).
• What is the payback period and what risks the project carries.
• Can the refresh be phased and how to set priorities.

To reduce argument and speed decisions, bring 6–8 key figures and data sources to the first meeting rather than a “perfect calculation.” For example: fleet size and device ages, share of PCs older than 4–5 years, average incidents per month, recovery time, employee hourly cost (or at least a range), current repair/support costs, and energy consumption benchmarks.

A strong move is to agree assumptions in advance. Decide the calculation period (often 3 years), what counts as downtime (full stop or “runs slowly”), and how to value an hour of lost time. Put this in writing in one paragraph. If people argue later, you will return to agreed rules, not emotions.

Another helpful step: split the fleet into groups (critical workstations, regular office, specialized). The committee is more likely to approve a phased refresh with clear priorities than "replace everything at once."

The numeric model: what to count and over which period

A convincing model centers on cost of ownership for the fleet, not the purchase price. Then the discussion is about predictable costs and risks over the horizon, not a one-off buy.

A convenient comparison horizon is 3–5 years. At 3 years you can see where repairs and downtime start rising. At 5 years differences in energy and support are clearer, and it's easier to compare scenarios: do nothing, partial refresh, or full replacement.

The calculation usually includes five blocks:

• Purchase: hardware, commissioning, basic licenses (if applicable).
• Support: IT and contractor labor, spare parts, warranty cases, on-site visits.
• Downtime: employee time lost due to failures, waiting for repair or replacement.
• Energy: workstation and peripheral consumption during working hours.
• Risks: expected losses from security incidents and fines for non-compliance.

Calculate by fleet, not by a single PC. A single computer can be unlucky or lucky; averages across the fleet reveal realistic metrics and make assumptions transparent: how many devices, average age, number of service requests, and recovery time.

Data often already exists inside the company. Start with a simple set:

• accounting: purchase prices, electricity bills, write-offs;
• service desk: number of incidents, average resolution time, common failures;
• IT inventory: fleet composition, age, configurations, department mapping;
• HR or function managers: employee hourly cost by category.

If you need price benchmarks for new equipment, request commercial offers from several suppliers, including local manufacturers (for example, GSE.kz), and use the average price as an input.

Downtime and productivity loss: how to convert to money

Committees find it easier to approve a refresh when “computers are slow” turns into a clear sum. The logic is simple: how many hours people lose due to PCs and how much an hour costs.

The basic formula:

Losses from downtime over a period = (hours of downtime per employee per month) × (hourly cost) × (number of employees) × (number of months).

It's important to include not only “won't turn on.” Hidden downtime is often larger:

• freezes and long app startups (waiting 5–10 minutes several times a day);
• slow performance during updates, antivirus scans, opening large files;
• peripheral failures (printers, scanners, POS) where the workstation is the root cause;
• waiting for repair: diagnostics, approvals, logistics, loaner PC.

To be credible and not look inflated, prepare 2–3 typical scenarios and corroborate them with data: a survey plus service-desk ticket analysis. Example: an average employee loses 1.5 hours/month to freezes and 2 hours/month to repair wait (including data migration and setup). Total 3.5 hours.

Example: 120 employees, hourly cost 5,000 KZT, downtime 3.5 hours/month. Monthly losses: 120 × 3.5 × 5,000 KZT = 2,100,000 KZT. Per year that is 25,200,000 KZT, excluding stress, missed deadlines and errors.

Highlight critical roles separately and use stricter figures: finance during close, call center, cash registers, reception. There downtime often equals direct lost revenue or fines. For such roles show process-level hourly cost rather than a company average.

If you have fast on-site support and loaner machines, this is also monetary: reducing downtime even by one working day for critical seats often has a bigger effect than a small saving on purchase price.

Repair and support: direct costs that are easy to prove

The committee most readily accepts items visible in invoices and tickets. So repair and support are a strong part: numbers come from the service desk, receipts and timesheets.

Split work into planned (cleaning, scheduled consumable replacement, OS reinstalls) and emergency (sudden failures, urgent visits, module replacements). Planned costs are usually stable; emergency costs grow with fleet age and consume budget and time.

For a credible calculation collect at least 6–12 months of:

• number of PC-related tickets, split by warranty and non-warranty;
• cost of parts and consumables from receipts;
• engineer labor (diagnostics, repair, setup, delivery);
• external service and on-site fees (if contractors are used);
• share of repeat tickets for the same workstation.

Then everything reduces to a formula:

Support cost = parts + (engineer hours × hourly rate) + external services.

Example: fleet of 200 PCs, 160 hardware tickets per year. Average time per ticket 1.5 hours, engineer rate 8,000 KZT/hour. Labor = 160 × 1.5 × 8,000 KZT = 1,920,000 KZT. Add parts (e.g., 2,500,000 KZT) and external services/visits (600,000 KZT) — roughly 5,000,000 KZT/year, excluding user downtime.

Also mark a threshold where repair becomes uneconomic. A practical rule: if annual repair and support per PC approaches 25–30% of the price of a new device and failures repeat, replacement is better.

Don’t ignore small items: power supplies, drives, batteries, mice, keyboards. Individually small, but over a year they form a noticeable tail of expense. Buying workstations from a vendor with clear warranty and service (including local manufacturers) often reduces these costs and approvals.

Energy consumption: a simple calculation without complex formulas

Energy is rarely the main argument, but it’s a pleasant cost to show: it’s quick to calculate and backed by bills. Show the difference between “current” and “after refresh.”

Compare old and new workstations by typical scenarios, not by peak watts. For an office you usually need average consumption during a workday: under load (meetings, browser, documents) and idle (idle, mail). If no measurements exist, use values from datasheets or do quick meter checks on 2–3 typical seats.

Basic logic:

kWh per year = (average power, kW) × (hours per day) × (working days per year).

Then multiply by the tariff and number of seats.

To keep the calculation readable, state exactly what is being replaced. Often PCs are replaced but monitors remain, so savings are smaller. If you replace monitors or switch to all-in-ones, show that as a separate line.

Single-table template for the committee

Fill lines for both “old” and “new” and show the difference in a separate row.

For a quick reality check: an old PC averages 100 W, a new one 60 W. At 8 hours and 240 working days, a 40 W difference yields roughly 77 kWh/year per seat, then apply the tariff and scale.

For trust, note which values come from datasheets and which were measured on 2–3 workstations. If part of the fleet will be replaced by locally produced models (for example, desktop PCs or all-in-ones from GSE), include them as a separate “new” option.

Security and compliance risks: how to estimate carefully

Old workstations carry technical debt for security: outdated OS or drivers stop receiving updates and vulnerabilities remain open.

To avoid making risk a “scare story,” present it as scenarios with probability and cost. Basic logic:

Expected loss = probability of event per year × cost of incident.

Use conservative probability ranges rather than a single figure.

Gather incident cost from clear parts: division downtime, IT and contractor recovery work, replacement or reinstallation, possible fines for non-compliance, and process stoppages. Reputation damage is better described qualitatively as risk of inspections and loss of trust rather than a KZT figure.

Example: finance has 40 seats with some machines no longer receiving updates. A ransomware incident causes 2 days of downtime. If the fully loaded hourly cost is 6,000 KZT, then productivity loss alone: 40 × 16 hours × 6,000 KZT = 3,840,000 KZT. Add 200–500,000 KZT for recovery and extra IT work — a magnitude comparable to part of a refresh project.

What to show the committee:

• current state: share of PCs without supported updates, number of devices older than N years;
• gaps: where disk encryption is missing, where modern protection won't run, where compatibility with new policies is broken;
• 2–3 incident scenarios with probability ranges and damage estimates;
• closure plan: phased replacement, minimum “security threshold,” timelines and owners;
• how to measure effect: reduction in unsupported OS share, fewer critical vulnerabilities, fewer emergency downtimes.

Hidden costs: support complexity and fleet heterogeneity

A heterogeneous fleet often looks cheaper on paper: you bought what's available and it runs. In practice IT manages different system images, drivers, BIOS settings, utilities, power supplies and storage types. Every unique device type adds time to prep and raises the chance the needed part isn't in stock.

The clearest conversion to money is IT hours. Take the fully loaded hourly cost of a specialist (salary + taxes + overhead) and multiply by extra hours caused by heterogeneity. Usually these are small tasks: reinstall, find driver, fit a replacement, build an image, agree compatibility.

To show scale, gather 3–4 metrics obtainable in 2–3 weeks:

• average time to prepare a workstation (from scratch or after replacement);
• average recovery time after a failure until the employee can work again;
• share of tickets requiring manual tweaks due to model/driver differences;
• number of unique models in the fleet and their shares.

Example: a standardized PC is prepared in 1.5 hours, a “zoo” machine in 3 hours — a 1.5-hour difference. With 200 preparations per year that's 300 hours of IT time. Multiply by your hourly cost and you get a recurring annual number, even ignoring user downtime.

Standardization also reduces spare parts inventory: instead of 10 part types you keep 2–3, and replacements follow a “pull out — put in” principle. Repairs accelerate: same images, predictable timelines, fewer unique failures. When choosing a supplier, assess lineup predictability and straightforward support, especially if you have requirements for unified service procedures.

Step-by-step: prepare a calculation and presentation in 1–2 weeks

To pass the finance committee you need a short numeric model and a clear implementation plan. This is feasible in 7–10 working days if you agree in advance who provides data (IT, accounting, security, HR).

1–2 week work plan

• Collect inventory and split PCs by groups: age (≤3 years, 3–5, 5+), role (office, engineering, POS, reception), criticality.
• Pick 4–6 metrics that are documentable: repair invoices, service-desk tickets, downtime hours from tickets, energy consumption by device type, number of exceptions (e.g., unsupported OS).
• Prepare 2–3 refresh scenarios: all at once; phased (e.g., 50% this year, 50% next); only critical seats. For each scenario note what stays unchanged (e.g., keep monitors, peripherals).
• Calculate effect and payback: compare “as is” vs “after” by annual costs, and separately note risk reduction.
• Summarize: what we buy, when, expected effect, and what happens if we do nothing.

Don’t aim for a perfect TCO. An honest model with ranges and source references (tickets, acts, invoices) is more persuasive than “exact” numbers without proof.

How the final slide should look

Make one slide readable in 30 seconds: project cost, savings or avoided costs, payback period, and key risks of refusal. Next to it list 2–3 assumptions (calculation period, what is included/excluded).

If you are in Kazakhstan and procurement considers local content, show a separate line for supply from a local manufacturer and the support format. For example, GSE.kz has domestic manufacturer status and 24/7 technical support with a service network, which helps address warranty and service concerns.

Common mistakes in calculations and how to avoid them

Committees often reject proposals not because the number is “too big” but because the calculation looks like a request to buy equipment rather than protecting company money.

Mistake 1: counting only purchase price

If the table shows only device cost, finance sees a one-off buy and compares it to zero, not to real ongoing costs like downtime, repairs, energy and risks.

Mistake 2: “ideal” assumptions without proof

Zero downtime, “almost no” repairs, energy savings “by 2×” without sources sound like marketing. The committee will ask for evidence and the conversation will stall.

Mistake 3: treating all users the same

An accountant during close and a person who mainly uses mail and documents have different downtime costs. Using one average often under- or overstates effects.

Mistake 4: promising savings without an implementation plan

Even a correct calculation won’t convince if there’s no clear plan: who migrates data, when, how to reduce downtime on replacement day, who accepts workstations.

Mistake 5: forgetting delivery times and replacement windows

Committees think in quarters. If delivery and deployment take longer, expected savings “this year” may not materialize.

What helps avoid these traps:

• link each number to a source: service-desk tickets, failure stats, security incident reports, electricity bills;
• prepare 2–3 scenarios (conservative, base, optimistic) and show ranges;
• segment users and calculate effects separately;
• add a one-page rollout plan: phases, owners, risks, how to measure results in 30–90 days;
• consider the calendar: replacement windows (nights, weekends), delivery times, and a 10–20 seat pilot.

If procurement is from a local manufacturer (for example, GSE.kz), confirm delivery and service terms in advance so you don't promise the committee something you can't deliver on schedule.

Short checklist before the committee meeting

Before the meeting make sure numbers reconcile and look like a single calculation, not disconnected arguments. Usually a year of data and clear assumptions for 3–5 years are enough.

Check that you have:

• fleet map: how many PCs, where they are, which department owns them, and which groups you compare (≤3 years, 3–5, 5+). This removes “what exactly are we replacing?”;
• ticket facts: number of requests, causes (disk, PSU, overheating), real 12-month costs (parts, visits, paid work). If some repairs are done in-house, present IT labor separately;
• monetary downtime estimate: hourly rate and clear logic for hours lost per incident. Be conservative but transparent;
• draft energy calculation: working hours, average power of old and new models, tariff and period. Record assumptions explicitly;
• 2–3 refresh scenarios: minimal (only oldest), base (all 5+ years), accelerated (plus critical roles). For each show procurement cost, expected savings or risk reduction, payback.

Quick test: take one department of 30–50 seats and run the calculation manually as an example. If the department head understands and agrees with assumptions, the committee is more likely to approve.

Example scenario and next steps

Imagine a fleet of 200 seats. Split into three groups so the calculation looks fair and is easy to understand: 1) office staff with old PCs (6+ years), 2) key functions (finance, HR, sales) with 4–6 year PCs, 3) high-demand roles (analysts, engineers, medical staff) with a mixed fleet.

Then show numbers over a 3-year horizon: current total cost of ownership and changes after refresh. Even a simplified table helps see the effect quickly.

A phased plan is easier to defend than “replace everything.” Start with critical departments and the most problematic machines (where downtime and repairs recur). Update other groups in a second phase after initial results.

To make the decision manageable, set KPIs and controls:

• reduce downtime hours by 30–40% within 6 months;
• cut support tickets by 20% within a quarter;
• share of seats on supported OS: 100% by date X;
• critical PC replacement lead time: 8–10 weeks;
• monthly report: actual vs plan on savings.

Then request role-based specs and run a pilot on 10–15 seats (3–4 per profile). If local production and predictable support are important, consider GSE.kz lineups: L200 desktops, M200 all-in-ones, and if needed S200 servers and system integration services.