An equipment list can tell a company how many laptops it owns without explaining where those laptops are or whether they can be used again. That gap becomes visible when a new employee arrives, a device breaks or a department requests more funding. IT asset management software should help answer those operational questions throughout the life of an asset. Comparing platforms through procurement, assignment and retirement provides a more useful basis for selection than counting features.
Define the decisions your asset records must support
IT asset management concerns the control of technology assets and the information needed to manage them over time. A practical evaluation begins by identifying the decisions people cannot make confidently today. Purchasing might lack visibility of available stock, support might struggle to locate a device, and finance might receive conflicting descriptions of the same item. Write these difficulties as questions the future system should help answer, then identify the records each answer requires.
Take the example of a laptop returned by a departing employee. The company needs to know that it has been returned, where it is stored and whether it is ready for reassignment. Technical discovery alone may show a device’s hardware characteristics without establishing physical custody or readiness for use. Conversely, a signed handover document does not reveal its current technical condition. Your evaluation should test how these different forms of information can be connected and kept understandable.
Agree on identifiers before loading trial data. A serial number, an internal asset tag and a purchasing reference serve different purposes, and teams may already use them inconsistently. Ask the supplier to show how duplicates are handled and how an existing record is updated when another source uses a different identifier. Include a realistic error in the sample data. Watching its correction can reveal more about the system than importing a perfectly prepared spreadsheet.
Ownership should also be explicit. The person using equipment may differ from the team responsible for maintaining its record or the department funding it. Check whether the proposed model can represent the distinctions your company needs. Avoid adding fields merely because the software permits them. Every additional requirement creates work for someone, so a field should support a decision, an agreed process or a useful report.
Infonet Projekt develops OXARI, whose Asset Management module is presented on the ITManager website as part of a wider service management offering. The module connects asset records with ServiceDesk and CMDB capabilities. Readers exploring this approach can use the IT asset management software ranking published there to discover potential suppliers. A lifecycle-based evaluation should then establish whether the relevant functions match the company’s own equipment handling and information responsibilities.
Follow one asset from purchase to retirement
Use a realistic asset journey as the common test for shortlisted platforms. Begin with equipment arriving from a supplier, continue through assignment and repair, and finish with retirement. Different participants should perform the tasks they would own after implementation. The exercise exposes unclear handovers and shows whether the software supports a shared record across teams. It also prevents an excellent inventory screen from dominating an evaluation of much broader requirements.
At receipt, check how staff record the purchase reference, location and condition. If several identical devices arrive together, test whether the workflow avoids unnecessary repetition while preserving separate identities. Then assign one item to an employee and another to shared use. Ask how the records differ, who confirms the assignment and which evidence remains accessible. A shared meeting-room device should not be forced into a model designed exclusively for equipment allocated to individuals.
Introduce an interruption during the trial: the assigned laptop needs repair and the employee receives a replacement. Check whether support can distinguish the failed device from the temporary one and whether the records preserve that history. Purchasing should still be able to see where the original device is, while the employee should have a clear record of the equipment currently assigned. The scenario tests consistency across a process involving several people.
Software requires an additional distinction between deployment and entitlement. Finding an application installed on a device does not, by itself, establish that its use is covered by the relevant agreement. Define which information your organisation needs from purchasing records, contracts and technical sources, and who will interpret it. Ask candidates to demonstrate the recording and review workflow without assuming that an inventory result automatically resolves every licensing question.
At retirement, test the sequence of decisions as well as the final status. Equipment might be withdrawn from use before disposal or reassigned after inspection. The system should support whatever evidence your organisation requires to record those events. Agree which information must remain in the historical record and which teams confirm closure. A retired asset disappearing from operational reports should not leave staff unable to explain what happened to it.
Evaluate data quality and the cost of keeping records useful
A pilot should reveal the effort needed to maintain information after launch. Select a manageable group of assets with different locations, users and conditions. Compare the records with physical checks and documents already held by the company. When discrepancies appear, record their causes: missing handovers, duplicate identifiers, delayed updates or unclear responsibility. These findings help distinguish a software limitation from a process that needs redesign.
Automation should be assessed against the information it can actually obtain. A connector may update technical attributes while another source provides purchasing information. Ask how conflicting values are resolved and how staff recognise records that have not been refreshed. Check the permissions required for every integration and nominate someone responsible for its operation. An automated feed without an owner can stop silently while users continue to trust the data.
Reports should support specific actions. A list of unused equipment is useful only when someone can verify availability and arrange reuse. A forthcoming renewal report needs a responsible reviewer and enough context to make a decision. During the trial, ask participants to produce one report and act on its findings. This tests the connection between data collection and operational value, instead of treating a dashboard as the final outcome.
Compare commercial proposals using the same scope of assets, users, integrations and implementation work. Include the effort required to clean existing information and train the people handling equipment. Document assumptions about future growth rather than relying on the cheapest initial configuration. Choose the platform that helps the company explain the status and history of its assets with a maintenance workload it can sustain.
Sponsored article