IT Asset Management Platform Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the scope collapse into another asset register?

Because a register is what everyone asks for. The request that reaches a developer is that the current one is out of date and hard to use, so the specification becomes a better database with a nicer interface and some import tooling. That gets built, and within six months it is as wrong as the last one, for the same reason: nothing tells it when reality changes.

The interesting information lives in the differences between systems and almost nobody computes it. Devices in the endpoint console with no purchase record are usually acquisitions nobody imported or personal devices that found their way onto the estate. Register entries with no check in for ninety days are the recovery backlog. Purchase records with no matching device were either never deployed or lost between the loading dock and a desk.

The fix is to scope the project as reconciliation rather than storage, and to say so in the first conversation. Produce those three lists on a schedule, route each to a named owner, and give every exception a state and a clock so it either gets explained or escalates. A useful test of any developer: ask what they would do with a device that appears in the endpoint console with no purchase record. If they call it a data quality error, they have missed the point.

What goes wrong when you match records across systems?

Serial numbers, mostly. This sounds trivial and it is the most underestimated task in the category. The same laptop reports a serial with a leading zero in one console and without it in another. A manufacturer pads with spaces. An endpoint agent reports a system board identifier rather than the chassis serial after a repair. Purchase records carry the reseller's line item reference instead of a serial. Asset tags are often absent because nobody was at receiving that week.

Then there is history. Devices get reimaged and appear as new records. A machine repaired under warranty returns with a replaced board and a changed identifier, so the discovery system thinks one device retired and another arrived.

The fix is a tolerant matching layer with an explicit confidence model and a human review path for ambiguous matches, rather than a join that assumes clean keys. Normalise serials per vendor with the rules written down. Keep every source record as received, so a bad match can be undone rather than argued about. Expect a period after launch where exception volume is high and staff it deliberately. When an acquisition arrives with several hundred untagged devices, bring their discovery data in first to establish what exists, then run tagging at the next physical touch point rather than as a separate project nobody has time for.

Why do the discovery, HR and procurement integrations break after launch?

The human resources feed is the one that costs you hardware. Leaver records trigger every recovery case, and the feed fails in ways that look like nothing happening: a contractor termination that never appears because contractors sit in a different system, a backdated leaving date, or a rehire reusing an identifier. If recovery cases are only created from leaver events, a silent gap means devices stop being chased and no error appears anywhere.

Endpoint consoles are the second. Intune, Jamf, a Lansweeper scan and an endpoint detection product each report a subset of the estate with their own field names, and a console upgrade quietly alters what arrives. Devices that stop reporting look identical whether they were decommissioned properly, went to a repair vendor, or left with a leaver. Procurement is the third and often the weakest link technically, because older purchasing platforms have no usable interface and you end up with a scheduled file rather than a connection.

The discipline is the same in each case. Alert on absence rather than on errors: a feed delivering zero leavers in a week should page someone. Reconcile counts per source on every run and store the result, so a partial import is visible. Never let an integration change an asset state without recording which source asserted it and when, because the point of this system is explaining a disagreement rather than averaging it away.

What happens when lease, warranty and disposal evidence are not covered?

They are the obligations everyone leaves to phase two, and the ones with money attached. Leased hardware carries a return date and penalties for units returned late, damaged or missing. Warranty and support contracts renew unless cancelled. Depreciation schedules feed the fixed asset register your auditors look at. All of it typically lives in a spreadsheet maintained by whoever last cared.

The failure is timing rather than record keeping. Discovering that a lease return is due next week is how organisations buy out equipment they fully intended to give back, because the units cannot be located, retrieved, wiped and packaged in five days across four sites.

Disposal is the quieter exposure. When data bearing devices leave, your asset disposition vendor issues a certificate listing the serials they received and destroyed. Almost nobody reconciles that against the list of serials actually sent, which means a device that fell out of the process leaves no trace, and years later a data protection question arrives with no chain from decommission through collection to destruction.

The fixes are unremarkable and they have to be in scope from the start. Model the agreement as a first class object with its term, return window, penalty terms and covered assets, then generate work weeks ahead rather than reporting the miss later. Reconcile disposition certificates automatically against what you sent, hold each certificate against the asset record, and record whether the vendor holds R2 or e-Stewards certification.

Should you build custom or configure what you already own?

Configure or buy if you are under roughly 500 devices on one or two sites with low turnover. Snipe-IT costs nothing and holds a clean register, Asset Panda adds a decent mobile experience for receiving and audits, and at that size a person can reconcile once a quarter.

Buy Oomnitza or ServiceNow if your integration surface is mainstream, your processes are close to standard, and you are willing to adapt your workflow to the product. Oomnitza is the closest commercial fit at scale because cross system reconciliation is its premise, and what to evaluate is how well your specific systems are modelled, since that determines everything it can tell you. ServiceNow asset management is right when you already run ServiceNow well and your configuration data is maintained. Lansweeper is strong at discovery and weak on lifecycle and finance, which is worth knowing before expecting it to carry the whole problem.

Build when your obligations are unusual, when you reconcile across systems no product ships a connector for, when your fleet includes categories beyond laptops and phones such as clinical devices in a hospital group, or when recovery from leavers is a known and unmeasured loss. A first step you can run this week: export your asset register, export ninety days of endpoint check ins, and count records appearing in one and not the other. That number usually ends the debate.

How do hidden costs get into the quote?

Five places. Source system count is the first, and legacy procurement platforms without usable interfaces are worse than they sound, because a scheduled file with inconsistent columns costs more to make reliable than a modern connection. The number of sites is the second, and specifically whether receiving happens locally, since asset tagging at the point of receipt is a process design question with a physical component rather than a software feature.

Reseller pre-enrolment is the third. Having the reseller tag and pre-enrol devices before shipping is worth doing, and it requires them to send structured data in an agreed format, which is a negotiation and an integration rather than a request.

Acquisitions are the fourth. Each arrives with its own estate, tagging scheme and identifiers, and each is a reconciliation project. If you grow by buying companies, say so in the first conversation, because it changes the matching design and not just the data volume. Mobile phones are the fifth, dragging in carrier contracts and a different lifecycle from laptops.

What separates a build that works from one that fails here?

The working builds model the states that actually exist. Real fleets spend a great deal of time in transit, at a repair vendor, out as a loaner, sitting in a branch cupboard, awaiting collection from a leaver, or staged for disposal. A register with three states records all of that as assigned, which is precisely why it is wrong. Give every intermediate state an expected duration and an owner, so a device that has been in transit for six weeks generates work for a named person rather than sitting quietly in a report nobody opens. That one change makes ageing visible, and ageing is where losses are.

They also treat offboarding as logistics rather than a checklist item. A recovery case opens automatically from the leaver record, carrying that person's specific assets and a deadline. The label goes with the box, the chase runs on a schedule through channels the person can still reach given their work account is disabled, and escalation moves to their manager and then human resources. The case closes when the serial is physically scanned at receiving, never on a courier status of delivered. Organisations that put an owner and a clock on this see recovery rates change materially, because somebody is now accountable for an outcome rather than a task.

The builds that fail close the case when the account is disabled and let the physical object become someone else's problem. They also ship without an exception queue, so the reconciliation runs and nobody acts on it.

Agree ownership before kickoff: the repository, the cloud accounts and the freedom to bring in another firm, in writing. At Digital Heroes the client owns the code from the first commit. This system becomes the reconciliation point between finance, IT operations and security, and none of those three should need a vendor relationship to answer questions about their estate.