Software metering for procurement optimization: measuring usage

Why measure actual software usage

Optimizing purchases with software metering starts from a simple fact: “installed” does not equal “used.” An application may be present on hundreds of PCs because of a standard image but opened once a month or never at all.

That’s how “dead licenses” appear — paid rights that nobody uses. The reasons are usually obvious: an employee left, a role changed, a project ended, but installations and access remained. Another common scenario is migrations, when old tools live alongside new ones.

Without metrics, decisions are made blindly: renewals are done on last year’s volumes “just in case,” IT hands out licenses on request “I need it,” and the business is later surprised by costs. But the opposite extreme is also dangerous. If you cut by intuition, you can stop a team during a busy period, miss deadlines and trigger shadow IT.

For measurements to work, agree roles in advance:

• IT is responsible for inventory, access to data and technical constraints.
• Security — for data-collection rules and privacy.
• Procurement — for license terms, renewal dates and optimization options.
• Process owners — for what counts as “use” in real work and what the risks are when cutting.

A practical example: in a large organization, some engineering workstations launch heavy software only before project delivery. Looking only at the last 30 days would mark those licenses as “dead,” even though this is seasonal. Metering is not for punishment but to reveal the full picture and enable safe decisions.

Key terms and what to measure

Metering is often confused with inventory and licensing, though these are different tasks. Inventory answers the question “what is installed and where.” Licensing — “what usage rights do we have and under which conditions.” Metering — “how are these actually used.”

To map data to procurement, choose clear indicators in advance. Usually a basic set is enough: launch events, active time (when the app is actually used, not just open), frequency (e.g., active days in 30/90 days), unique users and the number of devices that launched the app.

Consider the application type. For office apps, launches and active time often reflect real work. For background services (VPN clients, antivirus, drivers, agent software) a launch says little: they can be critical but not visible as active work. For web apps and SaaS, metering by installation won’t work — you need authentication logs, activity inside the system or reports from the admin console.

Another trap — different licensing models. For subscriptions you must track active users and month-to-month dynamics. For perpetual licenses the goal is often different: find where you can avoid purchases, where to redistribute, and where it’s risky to touch due to the app’s role.

A good rule: before any reductions, record what signal is sufficient (for example, 0 launches for 90 days) and which exceptions are needed (seasonal roles, emergency accounts, rare but critical tasks).

Where to get data: main metering sources

It’s important not to search for a single “perfect” source but to build a picture from several. Different systems see different parts of usage: app launches, authentication events, license checkout, or session activity.

The four most common sources:

• an agent on the PC/server (launches, activity, runtime, sometimes versions);
• OS-level data (logs and events — easier to deploy but less detailed);
• license servers (FlexLM and equivalents: checkout/checkin, peaks, pool contention);
• vendor cloud reports (Microsoft, Autodesk, etc., especially useful for SaaS).

Each source has limits. An agent gives accuracy on workstations but requires deployment and maintenance. A license server answers “why are licenses insufficient” well but doesn’t always show that an app is opened only nominally. Cloud reports sometimes count only logins, not productive work.

Complex environments need special handling. In VDI and terminal sessions it’s important to know which user used an app in which session, otherwise data will “stick” to one server. On shared devices (training labs, clinic stations) it’s more useful to count by session and schedule than by device.

For CAD, ERP and specialized software you often need additional metrics: concurrent users and time-of-day peaks, tokens/credits/modules instead of “simple licenses,” usage of key functions and signals of real activity (not just an open window).

A practical start — combine inventory, an agent on a pilot group and license-server data. This reduces the risk of “saving” money and causing downtime in critical teams.

How to prepare: project boundaries and decision rules

Software metering works when the purpose is clear in advance. Usually one of three goals applies: reduce new purchases, redistribute licenses, or verify compliance with license terms. If you mix all goals at once, data will pull in different directions and decisions will become contentious.

Next, fix the list of applications to be measured and their criticality. A useful division: “mission-critical” (stops processes), “important” (reduces quality or speed) and “auxiliary.” For critical products the rule is simple: discuss with the process owner before any changes.

A key parameter — the observation period. People commonly pick 60–90 days to capture seasonality, vacations, quarter closings and rare but mandatory tasks. A short window (e.g., 14 days) can easily mark necessary licenses as “dead.”

Prepare reference data; otherwise metrics will float: who is a user (department, role), who owns the application, who pays, which version and license type. Then the question “why are they not using it?” quickly becomes concrete: role change, duplicate tools, access not granted, training not completed.

Agree decision rules beforehand:

• who approves changes (IT, procurement, application owner, unit manager);
• which thresholds count as “not used”;
• the sequence of actions: redistribute, train, revoke, freeze renewal;
• how quickly a license can be returned if needed again.

This reduces dead licenses without taking tools away at the worst moment.

Step by step: how to start software metering and get first insights

Start with clean data and clear rules, not cuts. You can get initial conclusions in 2–4 weeks if you agree in advance what counts as “use.”

1) Build the inventory: what and who you have

Create a single list of installations, users and devices: desktops, laptops, terminal servers, VDI. Mark license type immediately (per-user, per-device, subscription) and critical roles (accounting, engineers, doctors, contact-center operators).

Then enable launch collection and validate data quality: ensure events actually arrive, compare reports with a control group of 10–20 users and fix the observation window (e.g., 30–60 days) to avoid a “quiet” season.

2) Normalize data for decision-making

Half the problems are solved by normalizing names and versions. “Adobe Reader”, “Acrobat Reader DC” and “AcroRd32.exe” should be the same product; otherwise the list of “rarely used” items is artificially inflated.

Then define metrics and activity thresholds and form candidates for optimization. Add exceptions (seasonal roles, reserve workstations, emergency accounts, rare peaks) and describe safe actions in advance: reissue a license, downgrade, uninstall, move to a cheaper plan.

Make the final step only after agreement with function owners: pilot in one group, then scale. If you need help with collection setup and interpretation, this is usually solved via SAM practice and a systems integrator in a short pilot format.

How to correctly interpret data and context

Metering data are useful only when you understand what they show. The most common mistake is treating “zero usage” as proof that a license is unnecessary. In reality an application may be rarely needed but critical at a specific moment: period closing, tenders, audits, security incidents or one-off integrations.

Look at combinations: was the app launched, how much active time was recorded, how often does a user return to the tool. If metering is silent, check for web versions, shared terminal access or alternative clients that the collector misses.

Seasonality and project peaks can mask true needs. Therefore, don’t rely on “last 7 days” but on an interval that covers a typical work cycle (often 90–180 days).

Another trap — false positives. A “process launch” can be logged by auto-updates, background services, plugins and preinstalled components. In such cases separate real user activity from technical activity.

Consider access modes. With remote work and business travel people may use VDI, RDP or corporate portals, while an agent on a laptop shows idle time. Before cutting, verify which access channels metering covers, whether there are shared devices and if licenses are assigned to roles rather than individuals.

When comparing departments, don’t conclude “department A has fewer launches — therefore surplus.” Compare tasks, procedures and risks. It’s better to confirm findings with short interviews and a pilot redistribution than to cut immediately and stop work.

Common mistakes and traps that hurt the business

Problems begin when metering is treated as a verdict. Measurement shows activity, but not always value: a rare launch can be critical for reporting, month-end closing or regulatory work.

A frequent mistake is reducing licenses before the agreed observation period ends. If you observed only 2–4 weeks, you can easily miss quarterly peaks, vacations, business trips and project changes.

Another trap — optimizing “by department average.” Such reports hide the tail of rare users, where key roles often sit: accountants during closings, lawyers before tenders, engineers during incidents.

A separate class of errors is mixing editions, versions and entitlements. A user may launch an app rarely but be entitled to a specific edition or module. Confusing entitlements risks breaching licensing conditions or depriving a team of required functionality.

Finally, it’s harmful to start by deleting without trying redistribution and short training. Sometimes someone doesn’t use a program because they don’t know access exists or prefer a workaround.

A small checklist to avoid harm:

• Wait for the agreed observation window (often 8–12 weeks).
• Check rare scenarios: period closings, audits, emergency tasks.
• Separate editions, versions and entitlements in reports and contracts.
• First redistribute; cut purchases only after confirming the effect.
• Record decisions and owners, otherwise everything will drift in 3–6 months.

Example: a bank had 20 graphic-design licenses unused for 30 days. After conversations it turned out 4 people run them quarterly for reports and brand materials. The solution: redistribute 16 licenses to active teams, keep 4 as a reserve with clear issuance rules. The main lesson — don’t assume “35 people don’t use it”; usage has seasonality and peaks. Metering helps if read together with project calendars, roles and access needs.

A short checklist before cutting licenses

Before removing access or reducing a pool, make sure you are cutting true “dead” licenses, not a buffer the business keeps for safety. Metering provides numbers, but decisions must always consider context.

Check the observation period. One or two weeks almost always misleads: vacations, quarter closings, project pauses, equipment replacement. If an app is used irregularly (e.g., for financial reporting or engineering), the period should cover at least one typical cycle.

Agree rules. Each application must have an owner (business or IT) who confirms thresholds: what counts as “not used” and which events matter (launch, active work, login, use of specific functions). Without that, the metric becomes a “user hunt.”

Check exceptions: key roles and on-call staff, regulatory and audit needs, temporary projects and seasonal peaks.

Prepare a rollback plan. It should answer who restores the license and how many hours it takes. A good test — simulate a situation where access is urgently needed on a Friday evening.

And don’t forget communication. A short notification reduces support noise: what changes, why, how to request return and where to contact.

Practical example: find “dead” licenses without random cuts

A company purchased 200 licenses of an office suite and 80 licenses of specialized software for project teams. Formally all were “needed,” but purchases grew each year while the budget didn’t. They enabled software metering to see actual usage.

Over 90 days they collected launch and active-use data. The office suite was used daily by most. The specialized software showed 35 users launched it only 1–2 times during the period. Numbers alone suggested removing licenses, but process owners explained these were project roles that need access “just in case” during acceptance, audits or stage closures.

Instead of harsh cuts:

• some licenses were reissued to those using the tool weekly;
• some were kept as a floating reserve for projects with clear issuance rules;
• some were removed with an agreement about rapid reissue when new stages start;
• short training was run and some users moved to a lighter edition where formats and rules allowed.

Result: purchases decreased without stopping processes or conflict with owners. The main conclusion — it wasn’t “35 people not using” but seasonal use and peaks. Metering helps when read alongside project calendars, roles and access requirements.

Privacy and trust: how to measure usage correctly

Metering quickly adds value, but employee trust is easily lost if data collection looks like monitoring people rather than tracking licenses. Simple rule: measure application usage, not personal behavior.

Start with a clear policy: what you collect, why, how long you keep it and who sees reports. This reduces fears and lets security evaluate risks in advance.

What to collect to avoid a sense of “spying”

Collect only what’s needed for licensing decisions: launch events, duration of active use, application version, device (as an asset), license type and department (if needed for budget allocation). Do not collect file contents, keystrokes, browsing history, email texts, screenshots or other personal telemetry.

Short rule: if a metric does not affect a licensing decision, don’t collect it.

Data access and anonymization

Limit access by roles. Usually SAM/ITAM, the application owner and security need detailed reports; managers should receive aggregated data.

For regular reports use aggregation by department or device groups. Show usernames only when investigating exceptions (e.g., access disputes or migrations). Store raw data for a shorter time and summaries longer if needed for procurement cycles. Log who and when exported reports.

If you have security and legal teams, agree the methodology before starting: legal basis, retention, employee notification and storage requirements.

How to turn metering into a repeatable process, not a one-off action

A one-time measurement often yields savings, but after 3–6 months things revert: people change roles, new projects appear, app versions update and purchases follow old habits. To make metering work continuously you need a simple repeatable cycle and clear rules.

Monthly cycle: from data to action

A practical scheme fits a month if each step has an owner: data collection (metering exports, license register, staffing and hardware changes), analysis (candidates for redistribution and reduction considering roles and seasonality), decisions (quick approvals with owners and managers), execution (redistribute, revoke access, change plans, control uninstalls where appropriate) and effect control.

Small but important detail: always redistribute first; cut purchases only after confirming the effect.

How to measure results and keep data current

Look beyond “how much saved” to decision quality. Three metrics are usually enough: direct cost reduction, number of redistributed licenses, share of unused installations/accounts for key apps.

To keep data fresh, fix update rules: added a new app — immediately define what counts as usage; a new version — check that metering sees it; a new role — revise activity thresholds and required modules.

Tie metering to procurement: budgets should be based on facts — how many active users, what buffer is needed for growth and which licenses can be closed by redistribution. For organizations with critical infrastructure, predefine products that cannot be touched without a pilot and an agreed change window even if metrics look low.

Next steps: pilot, scale and support

A practical start this week: pick the 10–20 most expensive applications (by procurement or invoices) and confirm with process owners where they are critical. Often this step already reveals licenses bought “just in case” or for projects long finished.

Pilot in 1–2 units

Choose two different profiles for a pilot, for example accounting and engineering. Participants: IT (collection tools), procurement (contracts), security and legal (rules), and a business owner (what is the minimum required).

Pilot plan: list apps and metrics, agree observation period (e.g., 4–8 weeks), define safe thresholds, prepare scenarios (redistribution, downgrade, shared/concurrent licenses, training) and get soft approvals before any changes.

After the pilot, scale by waves: first the most expensive apps, then mass ones. Document rules in a short guide: who owns data, who approves reductions, notification order and how quickly access is restored if a mistake is made.

When to involve an integrator

An integrator is useful if data sources are fragmented (AD, VPN, VDI, SaaS, terminal farms) and there is no single picture, if you need reliable infrastructure for metering and reporting without burdening users, if security and privacy requirements are strict, or if you want to link metering to procurement and SAM processes.

If you need a pilot and scaling, GSE.kz (gse.kz) as a systems integrator can help gather metrics from diverse environments, set up report access rules and connect results to procurement and support so changes happen without downtime.