A Practical ServiceNow ITAM Series Connecting HAM, SAM, CMDB, Integrations,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
5 hours ago - last edited 5 hours ago
From Laptop to License: A Practical ServiceNow ITAM Series
Hello ServiceNow Community,
I am excited to begin a new 15-post series:
From Laptop to License: Connecting HAM, SAM, CMDB and Integrations
The purpose of this series is to explain ServiceNow IT Asset Management as one connected operating model rather than treating Hardware Asset Management, Software Asset Management, CMDB, procurement, discovery, contracts, finance, HR, security, and governance as unrelated areas.
ITAM is sometimes viewed as simply maintaining an inventory of laptops, servers, mobile devices, and software licenses.
In practice, reliable ITAM requires much more.
It requires clear answers to questions such as:
How do assets enter the organization?
Which system owns each type of data?
How are purchased assets received and recorded?
How are hardware assets connected to Configuration Items?
How is installed software discovered and normalized?
How are software entitlements connected to actual consumption?
How are unused hardware and software reclaimed?
How are lifecycle, compliance, cost, and security risks identified?
Who owns data-quality exceptions?
How do we confirm that a correction improved downstream results?
This series will follow that complete journey.
Why HAM, SAM, CMDB, and integrations must work together
Consider the lifecycle of one employee laptop.
The journey may begin with a Service Catalog request. Depending on the organization, the request may require manager approval, budget validation, procurement processing, purchase-order creation, and supplier fulfilment.
When the laptop is received, the organization may need to:
Validate the purchase order and receiving information
Capture the serial number and asset tag
Associate the device with the correct hardware model
Place it in the correct stockroom
Update its lifecycle state and substate
Prepare and deploy the device
Assign it to the correct employee
Associate it with a location, department, and cost centre
This is primarily the Hardware Asset Management side of the lifecycle.
After deployment, SCCM, Microsoft Intune, Jamf, ServiceNow Discovery, or another inventory source may identify the device and update its technical details.
A related Configuration Item may then be created or updated in the CMDB.
The Asset record and the Configuration Item may represent the same physical device, but they support different business needs.
The Asset record helps answer questions such as:
Who owns or uses the device?
Where is it located?
What hardware model is it?
What did it cost?
Is it in stock, reserved, deployed, missing, retired, or disposed?
Is it covered by a warranty or maintenance contract?
Is it eligible for refresh?
The Configuration Item helps answer operational questions such as:
Is the device active and discoverable?
Which business service does it support?
Is it affected by an incident, problem, or change?
What other infrastructure components depend on it?
When was it last discovered?
What would be the operational impact if it failed?
The same laptop may also contain several installed software products.
The software data may begin as raw installation information from SCCM, Intune, ServiceNow Discovery, or another inventory source.
That raw data must be processed through software discovery models and normalization so that the publisher, product, version, and edition are identified correctly.
The normalized product then needs to be associated with the correct software model.
Purchased license rights must be represented through valid software entitlements with the correct:
Publisher part number
Software model
License metric
Metric group
Purchased quantity
Contract reference
Maintenance or subscription dates
Upgrade or downgrade rights
Additional product-use rights
Reconciliation compares the organization’s software rights with calculated consumption to determine whether the position is compliant, underlicensed, or overlicensed.
Usage information can then help identify software installations or SaaS subscriptions that are assigned but no longer actively used.
Instead of purchasing additional licenses, the organization may be able to reclaim those rights and make them available to another user.
When the employee leaves, the organization may need to recover both:
The physical laptop and its accessories
The software, SaaS subscriptions, and access assigned to the employee
When the laptop reaches the end of its useful life, it may be refreshed, reused, returned, retired, securely wiped, sold, donated, recycled, or transferred to a certified disposal partner.
This full journey shows why ITAM cannot succeed through one module, one team, or one data source alone.
What This Series Will Cover
The series is divided into five connected phases.
Phase 1: ITAM Foundation
The first phase establishes the overall ITAM operating model.
Post 1: ITAM Series Introduction
Why ITAM, HAM, SAM, CMDB, integrations, and governance must work together.
This introduction provides the roadmap for the complete series and explains why asset management should be viewed as an end-to-end business process rather than a collection of separate tools.
Post 2: ITAM Data Flow Overview
We will follow the complete data journey:
Request → Approval → Procurement → Receiving → Stockroom → Deployment → Asset → CI → Discovery → Software Installation → Entitlement → Reconciliation → Reclamation → Retirement
The article will explain:
Where each record originates
Which system owns each data element
How information moves between systems
Which ServiceNow records are created or updated
Which teams participate at each stage
What happens when the data flow breaks
We will also look at common gaps such as missing purchase information, duplicate assets, incorrect user assignments, stale discovery data, and failed entitlement imports.
Post 3: ITAM, HAM, SAM, and CMDB Explained
This article will compare the purpose of each area, the records each one manages, and how they support one another.
It will also address common misunderstandings such as:
Asset versus Configuration Item
Hardware model versus CI class
Software installation versus software entitlement
Discovered inventory versus purchased rights
Financial ownership versus operational dependency
Asset lifecycle state versus CI operational status
Procurement evidence versus compliance evidence
Phase 2: Hardware Asset Management
The second phase follows the complete hardware lifecycle.
Post 4: HAM Lifecycle Deep Dive
This article will cover:
Hardware models and model categories
Catalog requests
Approvals
Procurement
Purchase orders
Receiving
Stockrooms
Reservations
Deployment
Employee assignment
Transfer orders
Asset movement between locations
We will examine how hardware assets progress through lifecycle states and substates and why accurate state management is essential for stock, assignment, refresh, and disposal reporting.
Post 5: HAM Operations and Maintenance
This article will focus on what happens after deployment, including:
Warranty management
Maintenance contracts
Repairs
Return Merchandise Authorization
Loaner assets
Asset swaps
Refresh planning
Employee returns
Lost and missing assets
Assets assigned to inactive users
The article will also explain how support, asset, procurement, and stockroom teams coordinate during repair, replacement, and return activities.
Post 6: HAM Retirement and Disposal
This article will cover:
Hardware reclamation
Employee offboarding
Refresh and replacement
Secure data wiping
Retirement approvals
Disposal orders
Disposal certificates
Donation
Resale
Recycling
Environmental and security controls
We will discuss why changing an asset state to Retired is not always enough. A defensible retirement process may also require chain-of-custody information, data-destruction evidence, disposal-vendor confirmation, and validation that the associated CI is no longer active.
Post 7: HAM and CMDB Relationship
This article will explain:
When a hardware asset should have a related CI
How Asset and CI records are connected
How selected fields synchronize
Why some assets do not require CIs
Why some CIs do not require asset records
How Identification and Reconciliation help prevent duplicate CIs
What happens when the Asset–CI relationship is missing or incorrect
How retired assets can remain connected to active or rediscovered CIs
Common HAM scenarios covered throughout this phase will include:
Duplicate hardware assets
Missing or incorrect serial numbers
Assets associated with the wrong model
Devices received without purchase-order information
Incorrect stockroom quantities
Assets assigned to inactive employees
Assets without related CIs
CIs without related assets
Retired devices still reporting from discovery sources
Missing return or disposal evidence
Phase 3: Software Asset Management
The third phase explains how raw discovery data becomes a defensible software-license position.
Post 8: SAM Data Foundations
This article will cover:
Software installation records
Inventory and discovery sources
Software discovery models
Publisher normalization
Product normalization
Version normalization
Edition normalization
Software models
Publisher part numbers
Custom software products
Custom normalization requirements
We will investigate normalization statuses such as:
Match Not Found
Publisher Normalized
Partially Normalized
Fully Normalized
Version Not Found
The article will explain how an analyst determines whether the issue is caused by incomplete source data, missing content, an unsupported product, incorrect discovery values, or a missing software-model relationship.
Post 9: SAM Licensing and Compliance
This article will explain:
Software entitlements
Publisher part numbers
License metrics
Metric groups
Purchased rights
Pack conversions
Allocations
Consumption
Install conditions
Upgrade and downgrade rights
Suites and components
Reconciliation
License position
The focus will be on understanding why a product can appear unlicensed even when an entitlement exists.
Possible causes may include:
The entitlement is linked to the wrong software model
The publisher part number is missing or incorrect
The license metric does not match the deployment
Upgrade or downgrade rights are not represented correctly
Install conditions exclude the installations
Consumption is calculated against the wrong user, device, processor, or core count
Duplicate entitlements distort purchased-right quantities
Subscription or maintenance dates have expired
Post 10: SAM Optimization and Product Lifecycle
This article will cover:
Software usage
Removal candidates
Reclamation workflows
Failed removals
User rejection of reclamation
SaaS subscription reclamation
Employee offboarding
Renewal preparation
End of support
End of extended support
End of life
Upgrade, removal, migration, extended support, and risk-acceptance decisions
The article will explain how organizations move from simply identifying compliance gaps to actively reducing unnecessary software cost and lifecycle exposure.
Post 11: Publisher-Specific SAM Capabilities
This article will introduce publisher-specific licensing complexity for products such as:
Microsoft
Oracle
IBM
Adobe
SAP
VMware
Citrix
Autodesk
SAS
We will discuss why publisher licensing cannot always be managed through simple installation counts.
Licensing may depend on:
Processor or core counts
Virtualization
Server clusters
Edition
User type
Device assignment
Concurrent usage
Suites and components
Product bundles
Subscription tiers
Publisher-specific product-use rights
Common SAM scenarios covered throughout this phase will include:
Discovery Models in Match Not Found
Partially Normalized software
Missing publisher, product, version, or edition
Discovery Models without Software Models
Missing or invalid publisher part numbers
Missing software entitlements
Duplicate entitlements
Incorrect purchased quantities
Incorrect license metrics
Unexpected consumption
Unlicensed installations despite available entitlements
Unused desktop software
Inactive SaaS subscriptions
Products approaching EOS, EOES, or EOL
Phase 4: Integrations and Governance
ITAM depends heavily on information maintained outside ServiceNow.
Post 12: Enterprise Integrations Overview
This article will explain how ITAM interacts with:
SCCM
Microsoft Intune
Jamf
ServiceNow Discovery
Procurement platforms such as Coupa or SAP Ariba
ERP and finance systems
HR systems
Contract-management platforms
SaaS providers
Disposal partners
The discussion will go beyond importing records.
We will examine:
Source-system ownership
Matching and identification rules
Import sets and staging tables
Transform maps
Reference-data validation
Duplicate prevention
Integration schedules
Stale-data detection
Import failures
Reprocessing
Error queues
Validation after correction
For example, procurement may remain the commercial source for purchase orders, invoices, suppliers, quantities, and costs, while ServiceNow manages the operational asset lifecycle, software entitlement records, and compliance processes.
Post 13: Data Quality, Governance, and KPIs
This article will focus on the controls needed to maintain trustworthy ITAM data.
Topics will include:
Data ownership
Exception queues
Data-quality rules
Model governance
Asset–CI reconciliation
Normalization coverage
Duplicate prevention
Source freshness
Ageing exceptions
Remediation ownership
Audit evidence
Dashboards and KPIs
Useful measures may include:
Assets missing serial numbers
Assets missing models
Assets without CIs
CIs without assets
Discovery Models not normalized
Discovery Models without Software Models
Entitlement-import failures
Duplicate entitlement records
Stale software installations
Installations on retired CIs
Assets assigned to inactive users
Removal candidates older than the target SLA
Products approaching lifecycle milestones
Exceptions without an assigned owner
The purpose of reporting is not only to display numbers.
Reports should help teams identify exceptions, assign ownership, take corrective action, validate the result, and prevent the issue from recurring.
Phase 5: Strategy and Value
The final phase connects ITAM operations with business risk and measurable value.
Post 14: Security, Risk, Compliance, and Audit Readiness
This article will discuss how reliable ITAM data supports:
Identification of unknown or unmanaged devices
End-of-life hardware and software exposure
Unauthorized software
Devices without owners
Missing or inactive CIs
Unlicensed software
Publisher-audit preparation
Contract and entitlement evidence
Risk acceptance
Lifecycle remediation
Security and compliance reporting
We will also discuss the difference between having data and having defensible evidence.
For example, an entitlement quantity alone may not be enough during an audit. The organization may also need a purchase order, invoice, contract, publisher part number, license statement, maintenance evidence, and a clear explanation of how the purchased rights were calculated.
Post 15: ITAM Maturity Roadmap
The final article will explain how an organization can progress through the following stages:
Basic Tracking → Controlled → Integrated → Optimized → Strategic
ITAM maturity is not measured only by the number of asset records in the system.
A mature ITAM program should be able to demonstrate:
Reliable lifecycle visibility
Trusted hardware and software data
Clear data ownership
Connected procurement and discovery processes
Accurate Asset–CI relationships
Defensible software-license positions
Effective hardware and software reclamation
Reduced audit exposure
Better renewal decisions
Lower unnecessary spend
Stronger security and operational visibility
Measurable business value
How Each Article Will Be Structured
Each article will include:
The business requirement and why it matters
How the process works operationally
Important ServiceNow records and relationships
OOTB capabilities
Configuration decisions
Integration dependencies
Common implementation issues
Troubleshooting steps
Teams involved
Corrective actions
Validation after correction
Preventive governance controls
Practical examples
Business outcomes
The goal is to move beyond definitions and explain how the different parts of ITAM behave in real implementations.
The Central Idea of This Series
Clean data alone is not enough.
Integrations alone are not enough.
Installing HAM or SAM alone is not enough.
Reliable ITAM requires:
Clean Data + Trusted Integrations + Clear Ownership + Strong Governance
When these foundations work together, organizations gain better visibility into asset ownership, software compliance, lifecycle risk, operational dependencies, renewal requirements, and opportunities for cost optimization.
I plan to share one focused topic at a time and build the complete journey from a laptop request to deployment, software-license management, reclamation, and final retirement.
Next Article
ITAM Data Flow in ServiceNow: From Request and Procurement to Retirement
In the next article, we will follow how information moves through:
Request → Procurement → Receiving → Stockroom → Deployment → Asset → CI → Discovery → Software Installations → Entitlements → Reconciliation → Reclamation → Retirement
We will also identify the important ServiceNow records, source systems, responsible teams, and common data-quality issues at each stage.
I look forward to sharing this series and learning from the experiences of other ServiceNow practitioners.
Which ITAM, HAM, SAM, CMDB, or integration topic would you like to see explored in greater detail?
#ServiceNow #ITAM #HAMPro #SAMPro #CMDB #HardwareAssetManagement #SoftwareAssetManagement #AssetManagement #Discovery #ServiceNowCommunity
Please mark this as Helpful if it helps.
If this addresses your question, please mark this response as Accepted Solution
or mark has helpful
if you find it helpful.
Thank you!
TejaswiniY