ServiceNow Hardware Asset Management Requirements Workshop Questions

This page gives a question bank for a Hardware Asset Management requirements workshop, grouped by the design decision each answer controls. Questions cover what hardware gets tracked and how detailed records are, where device data comes from, how devices move through their lifecycle, financial and compliance needs, and who may access records.

Inventory Scope Questions

These questions establish what hardware will be tracked and how detailed the tracking will be.

What types of hardware will you track? Just computing devices like laptops and desktops? Servers too? Networking equipment? Printers? Storage devices? Scope affects implementation complexity. Most organizations start with computing devices and expand later.

Will you track all devices or only assets above a certain value? Tracking every device is more accurate but requires more data entry. Tracking only expensive devices (over a threshold value) reduces work but creates blind spots. Define your policy based on compliance requirements and financial materiality.

How detailed will device records be? Just basic info (model, serial, location) or detailed info (RAM, storage, OS version, software licenses)? More detail helps with provisioning and support but requires more maintenance.

Integration and Data Source Questions

These questions establish where device data comes from and how it stays current.

Where will initial device data come from? Procurement system? Finance system (capitalized assets)? Discovery scanning? Manual entry? Procurement and finance are usually the most reliable sources. Discovery works for servers and network equipment. Manual entry is slow but necessary for devices that cannot be automatically discovered.

How will new device data flow into Hardware Asset Management? When procurement receives a new laptop, how does that data get to Hardware Asset Management? If procurement has an API, automated integration is best. If not, manual entry might be necessary.

How will you keep device data current as devices move or change? When a laptop is reassigned to a new user, how does that update get recorded? If IT provisioning is in ServiceNow, update workflows can automatically record the change. If provisioning is manual or in another system, discipline is needed.

Lifecycle and Process Questions

These questions establish what hardware processes will be tracked and what workflows are needed.

What hardware workflows do you need to automate? New device requests? Device provisioning to users? Transfer when a user changes roles? Repair and return? Retirement and scrapping? Each workflow has different design requirements.

How will device provisioning work? When a user requests a new device, should Hardware Asset Management automatically allocate one from available inventory, or should it trigger a purchase request if none is available? This affects design significantly.

How will decommissioned devices be handled? Are devices repurposed (wiped and given to another user), recycled (sent to a recycler), or stored? How is device data secured when a device leaves the organization? Design must address data security.

Financial and Compliance Questions

These questions establish what business purposes Hardware Asset Management serves.

How will Hardware Asset Management support financial reporting? Are devices capitalized and depreciated? Do they need to be tracked by cost center for chargeback? Do you need to track total value of hardware by department? Financial requirements affect what data you must collect.

What compliance requirements apply? Data protection (devices handling sensitive data must meet security standards)? Hardware refresh cycles (certain device types must be replaced by a certain age)? Documentation for audits? Compliance requirements shape what you track and how you report.

Access Control Questions

These questions establish who can see and edit device data.

Who needs access to Hardware Asset Management? IT Operations to manage inventory? Finance to see depreciation data? Help desk to look up device info? Each role has different access needs.

Should users be able to see device details for devices assigned to them? Some organizations let users see their own device details (warranty, support contact) but not other users’ devices. Others restrict all access to IT staff. Define policy based on privacy and security requirements.

Warning Signs

If you cannot identify where device data comes from (procurement? finance? nowhere?), that is a problem to solve before implementing Hardware Asset Management. If devices are not tracked anywhere currently, implementing Hardware Asset Management will reveal you own more than you thought and that financial records are incomplete. Plan for that discovery.

Run the workshop to find the answers that would stop the build

A requirements workshop for hardware assets is usually judged by how many items it captures. A better measure is how many of the captured items could change the design if the answer turned out differently. Most hardware programs are shaped by a handful of answers: who receives stock, who may change a custodian, what happens to a device that cannot be found, and which ledger is authoritative for cost. The workshop should spend its time on those, and treat the rest as detail to be confirmed later. The questions below are grouped by the design decision they affect, and each one notes the weak answer that should prompt a follow-up before the session closes.

Attendance matters as much as the question list. Finance, the receiving desk, the service desk and the security team each hold a different piece of the answer, and a workshop run with only the project team often produces requirements that the people who must use them will reject.

Questions grouped by the design decision they control

The table is a working bank of questions for the session. The third column is the answer that signals a risk, usually because it describes an intention rather than a process that exists today. Those answers should not be recorded as requirements until someone can name the process behind them.

A running order for the workshop

The order matters because later sessions depend on decisions made earlier. Keep each block to the decisions it must produce, and close each block with a written statement that the room has accepted.

1. Confirm the decisions the register must support, starting with the two or three decisions people already make using spreadsheets.
2. Walk the lifecycle of one real device from purchase to disposal, using a recent example, and note every point where the record is touched.
3. Agree who owns each of those touch points and what evidence each owner produces. Access rights for each of those roles are worth settling in the same session. The security and access design guide covers how access to hardware records can be structured by role.
4. Test the custody and missing-device answers against an uncomfortable case, such as a laptop returned without a record.
5. Read back the agreed statements and mark any that depend on a process that does not yet exist as conditional, with an owner for the gap.

How to recognize an answer that is really a wish

Stakeholders often describe the process they want rather than the one they run, and the difference matters. A useful test is to ask for the last occurrence: when did this last happen, who did it, and where is the record? If the answer points to a record that exists, the requirement is grounded. If it points to a meeting, a shared folder that nobody checks, or a memory, the requirement is an aspiration, and the design should account for the gap rather than assume it is closed.

A second test is to ask what breaks if the answer turns out to be no. A group that cannot describe the failure mode of a requirement has not yet understood it. This is also the point to surface disagreements between finance and operations, because the register often inherits whichever definition is written first.

Outputs a sponsor should expect from the session

A long requirement list is not evidence of a finished session. The outputs that justify the time are a short set of agreed decisions, an owner for each open question, a list of processes that must exist before the design can rely on them, and a parking list of features that were requested but do not change any decision in the first release. The last list protects the schedule and gives the requesters a visible answer.

How many people should attend the session?

Enough to speak for each touch point in the lifecycle, and no more. Observers can read the outputs afterwards. A room that is too large tends to produce requirements by vote rather than by evidence.

Should the workshop cover reporting requirements?

Only the reports that feed a named decision. A requirement for a report that nobody will act on is a cost without a benefit, and it often hides a gap in the data that the report would have exposed.

What if two departments give opposite answers on cost?

Record both answers, name the decision that depends on them, and escalate that single decision to the person with authority over the ledger. Do not let the design choose a side by default.

Is it worth asking about devices that are not yet in service?

Yes, because planned devices in a procurement pipeline show whether the intake route will work for the next cycle. Ask for the pipeline volume and the expected receiving steps rather than a forecast of quantities. Where those devices hold data that must be classified, the data classification workflow note is a useful read on the handling questions.

Before the first session, the demand intake and prioritization note covers how new requests are assessed before they are ranked.