Joining Asset Data to Everything Else

An asset register that stands alone answers questions about assets. Joined to other systems, it answers questions about the organisation.

The joins worth making

To the directory. Application access joined to people, teams and cost centres. This enables per-team reporting, offboarding checklists and access reviews.

To endpoint management. Devices joined to the hardware register, which is the reconciliation that keeps it honest.

To the finance ledger. Applications joined to actual spend, which converts a register into a cost view.

To the service desk. Tickets joined to assets, which reveals which models and which applications generate support load.

To HR. Joiner and leaver events joined to provisioning tasks, which is what makes offboarding reliable.

Five joins. Each is on an identifier both systems already hold.

What each enables

Directory join: who has what, per team spend, orphan detection, the offboarding task list.

Endpoint join: device existence verification, encryption status, assignment drift detection.

Finance join: cost per application, cost per head, chargeback, savings verification.

Service desk join: support cost per model, applications generating friction, refresh evidence.

HR join: automated triggers rather than remembered ones.

The identifier problem

Email address is the usual person join and it breaks on name changes, aliases and people who signed up with variants.

Employee number is more stable and frequently absent from application data.

Serial number is the device join and it is reliable.

Application name is the least reliable join of all, which is why the alias mapping exists.

Invest in the person identifier. Getting employee number into your identity provider and out to applications where possible makes every subsequent join more robust.

Doing it without a data platform

A scheduled export from each system into one place, monthly.

A spreadsheet or a small database.

The joins as lookups.

This is entirely adequate for most organisations and it is how most working registers actually operate. A data platform is not the prerequisite people assume.

What it produces

Questions answered in minutes that previously took a week: what does this team cost, who has access to this system, which devices are unencrypted, what does this leaver need removed.

Findings nobody was looking for: a model generating disproportionate tickets, a team with twice the software cost per head of its peers, an application with more administrators than users.

Evidence, for audits and for budget conversations.

Where to stop

Do not build a data warehouse for this. The value is in five joins, not in a platform.

Do not automate the reconciliation before doing it by hand a few times, because the rules only become clear through the manual version.

Do not join what you will not use. Each join is maintenance, and a join nobody queries is a scheduled job that will break unnoticed.

Starting with one join

Five joins is the destination. One is the sensible start, and it should be the directory.

Application access joined to people, teams and cost centres.

It enables the four things people ask for most: who has access to this, what does this team cost, what does this leaver hold, and which accounts belong to nobody.

The join is on email address, with the known fragility, and it is good enough to start.

A monthly export from each side into a spreadsheet is an adequate implementation.

Add the endpoint join second, since it keeps the hardware register honest and requires no new data.

Add the rest only when someone asks a question that needs them.

The employee identifier

The person join is the fragile one, and improving it improves everything built on top.

Email address is what applications hold and it breaks on name changes, aliases and variant signups.

Employee number is stable and usually absent from application data.

Push it where you can: into the identity provider's profile, and out to applications that accept custom attributes.

Maintain an alias table for email addresses — current, previous, and variants — which resolves most of the residue.

Handle the edge cases explicitly: contractors without employee numbers, people rehired with a second record, and shared accounts with no person at all.

This is unglamorous work and it determines the accuracy of every per-person figure the programme produces.