ServiceNow Hardware Asset Management Use Cases for Enterprise Teams

Hardware Asset Management is the ServiceNow application area that keeps a record of each physical device, who holds it, and the contracts and warranties attached to it. This page sets out nine use cases and helps a program lead decide which one to build first.

Use Case 1: IT Asset Refresh and Replacement Planning

A large financial services firm has thousands of computers deployed globally. Computers are refreshed on a regular cycle. Without HAM, the company did not know which computers were old and needed replacement. With HAM, the company can run a report: “computers due for refresh based on age”. This report shows 500 computers ready for refresh. Finance uses this data to budget for replacements. Operations uses it to plan the refresh project: which computers to replace first, which users will be affected, how to minimize disruption. The company replaces 125 computers per quarter in a planned, controlled manner. Without HAM visibility, computer failures would drive replacements reactively, disrupting operations.

Use Case 2: Software License Compliance

An enterprise purchases software licenses for 1,000 seats but has actually deployed the software on 1,200 computers. With HAM, the company discovers this by matching installed software to asset records. The company is over-licensed and not compliant. The company removes software from 200 computers to bring into compliance. HAM is the tool that enabled discovery of the compliance gap. This is common: organizations buy licenses but do not track deployment carefully.

Use Case 3: Warranty and Support Contract Management

An enterprise with global operations manages thousands of warranty and support contracts for hardware. Each contract has different terms, renewal dates, and pricing. HAM tracks all contracts associated with hardware. When a contract is about to expire, HAM alerts the asset team. They can renew the contract on time, negotiate better terms, or let it lapse if the hardware is being retired. This systematic approach reduces the cost of support contracts by thousands of dollars per year through better negotiation and prevention of accidental lapses.

Use Case 4: Environmental and Security Compliance

A regulated organization must ensure that all computers meet security standards: encrypted hard drives, recent antivirus updates, approved operating system versions. HAM is integrated with compliance scanning tools. Computers that do not meet standards are flagged in HAM. The security team receives a report of non-compliant assets and remediation steps. As remediation completes, HAM is updated. This enables continuous compliance tracking instead of periodic manual audits.

Use Case 5: Cost Allocation by Department

Finance wants to allocate IT hardware costs to the departments using the hardware. Department A’s employees use 200 computers; Department B uses 150. Equipment, maintenance, and support costs can be allocated accordingly. HAM tracks asset assignment by department, enabling accurate cost allocation. Department heads see what they are spending on IT hardware, which helps with budgeting and may prompt them to optimize asset usage.

Use Case 6: Vendor Management and Warranty Optimization

HAM tracks vendor information and warranty details for each asset. When a computer needs warranty service, HAM identifies the vendor, warranty terms, and service level. This ensures that warranty is used properly and avoids paying for out-of-warranty service when warranty is still active. Warranty tracking also helps with vendor management: which vendors have the most warranty claims, which vendors provide the best service? This data helps with vendor negotiations and selection.

Use Case 7: Mobile Device Management and Security

Mobile devices (laptops, phones, tablets) are challenging to manage because they move frequently and are often taken off-site. HAM tracks mobile device assignments, current location (to the extent trackable), and security compliance. If a device is lost or stolen, HAM helps IT locate it, disable network access, and coordinate replacement. Mobile device tracking is essential for security and cost management.

Use Case 8: Support and Maintenance Contract Management

Many IT assets have associated support contracts beyond warranty: extended support, on-site service, or prioritized replacement. HAM tracks all these contracts associated with each asset. When a contract is about to expire, HAM alerts so renewal can be negotiated or the decision made to let the contract lapse if the hardware is being retired. This systematic tracking avoids accidentally paying for unwanted contracts and ensures that hardware needing service has current support contracts.

Use Case 9: Disaster Recovery and Business Continuity

In a disaster, knowing what hardware you have and where it is located helps with recovery. HAM contains this information: inventory of assets by location, asset details, and spare equipment locations. In a data center outage, HAM helps you determine what was lost and what can be restored from backups or spares. HAM is not a backup system, but it provides the information needed to manage disaster recovery effectively.

Choosing the first use case to build

A hardware asset program rarely fails because the module cannot support a use case. It fails because the team tried three use cases at once, each needing a different feed, and none reached a state where its answers could be trusted. The practical question for a program lead is which single use case will produce a reliable answer soonest, and which one has a named person who will check that answer every cycle. Use cases that depend only on the device record and its assignment are usually a better start than use cases that depend on contract or cost data that nobody has entered yet. Consider a hypothetical team that wants lifecycle reporting and warranty control in the same quarter. Warranty control depends on contract records held by procurement, while lifecycle reporting depends only on the device record, so the lifecycle report is the one to release first.

Data dependencies for each use case focus

The table below sets out what each common focus needs before its output can be believed. Read it from left to right when deciding whether a use case is ready. If the middle column asks for data your team has never collected, that use case is a data project in its own right and should not be the first one attempted.

The right-hand column is the warning sign to watch after go-live. The first failure in each row often does not look like an error. It usually shows up as a report that looks plausible but disagrees with a number the owner already knows, and that disagreement is the signal to trace back to the feed.

Piloting one use case before it reaches the business

Run the pilot on a bounded group of devices, such as one site or one device class, and agree the acceptance test before any data is loaded. Without that agreement, a pilot turns into an open-ended cleaning exercise with no finish line.

1. Write the question the report must answer in one sentence, for example which laptops at one site are due for replacement and who currently holds each of them.
2. Name the table or report view the answer will come from, and confirm every field it uses is populated for the pilot group.
3. Take a manual sample of the pilot group, record what the device owner believes is true, and compare each item with the report.
4. Log every disagreement with a cause: missing data, wrong data, or a rule that does not match how the business counts devices.
5. Fix each cause at its source, in the feed or the intake form, rather than correcting the report output by hand.
6. Repeat the comparison on a second sample before the report reaches the people who make decisions from it.

Where use cases fail once they are live

Three failure patterns often recur. The first is a device that is correct in its record but missing from the report, because its status is a value the report filter excludes. Local status values are often added by one team and never added to the report, so the gap stays invisible. The second is a use case built on a person link that goes stale when people leave or change roles. Cost and accountability reports then keep charging a department for a laptop returned months earlier. The third is a use case that is accurate but unused, because the people who should act on it were never given a route or a standing review. A report that nobody is expected to answer does not change how the business behaves.

When to hold a use case back

Hold a use case back when the underlying device data is known to be incomplete and no one has a plan to complete it. A mobile fleet with no reliable assignment history cannot support a loss response use case, and a dashboard built on it will mislead responders at the moment accuracy matters most. Also hold it back when a second system already owns the same answer and nobody has decided which system wins. Two sources that disagree do not produce a better answer by being shown side by side. Decide the system of record for that field first, then build on that decision.

Checklist before a use case goes live

• The person who acts on the output has agreed in writing to the question it answers.
• Every field the report depends on has a named maintainer and a known update route.
• A manual comparison has been completed on a sample, and each disagreement is either closed or explained.
• The report filter excludes only statuses the business has agreed are out of scope.
• There is a documented response for each kind of problem the report can reveal.

Should a first use case always be refresh planning?

Not always. Refresh planning is easy to justify because its value is obvious to finance, but it depends on in-service dates that many organizations have never captured consistently. If the dates are sound and the planning group already meets on a fixed cycle, it is a strong first choice. If they are not, a use case built on the link between a device and its current holder is often safer, because that link is captured at handover and tends to be checked by the holder anyway.

How many use cases should run at the same time?

Run only as many as the owners can staff. Each live use case needs someone who reads its output, resolves discrepancies and tells the data maintainers what to correct. A single report that is reviewed every cycle is often more useful than three reports with one reviewer.

What do we do when the report and the finance figure disagree?

Do not simply trust whichever figure you prefer. Trace the difference down to individual devices. The common causes are a device that finance capitalized but was never received into the hardware records, a device disposed of in one system and still active in the other, or a cost center that changed after a transfer without the record being updated. Record the cause, then decide which system is authoritative for that field.

Can a use case rely on discovered data alone?

Discovery covers network-connected equipment well, because it finds what is powered on and reachable. It cannot say who holds a laptop, which room a spare sits in, or whether a device is sitting unused in a cupboard. Pair discovery with an assignment process before relying on any answer that depends on people or locations.

After the first use case goes live, the metrics guide for hardware asset management covers how to define each measure and its blind spot, which helps check that the report still answers its question. For the feeds behind it, see the integration patterns guide.