ITAM vs HAM vs SAM vs CMDB: Understanding What Each Area Owns and How They Work Together
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
5 hours ago
From Laptop to License — Day 3 of 15
ITAM vs HAM vs SAM vs CMDB: Understanding What Each Area Owns and How They Work Together
Hello ServiceNow Community,
Welcome to Day 3 of the From Laptop to License series.
In Day 1, we introduced the complete ITAM journey and the importance of connecting hardware, software, CMDB, procurement, discovery, integrations, and governance.
In Day 2, we followed the end-to-end data flow:
Request → Procurement → Receiving → Stockroom → Deployment → Asset → CI → Discovery → Software Management → Reconciliation → Reclamation → Retirement
Today, we will clarify four terms that are often used together but do not mean the same thing:
ITAM, HAM, SAM, and CMDB
These areas are closely connected, but each one answers a different set of questions.
A simple way to understand them is:
ITAM governs the complete investment and lifecycle.
HAM manages the physical and financial hardware lifecycle.
SAM manages software ownership, consumption, compliance, and optimization.
CMDB manages the operational and technical context of Configuration Items.
To understand why all four are required, let us continue with the same example used throughout this series:
An employee receives a company laptop with Microsoft Visio installed.
The laptop is one physical device, but different teams and records view it from different perspectives.
ITAM asks whether the organization is managing the complete investment responsibly.
HAM asks where the laptop is, who has it, what it cost, and what lifecycle stage it is in.
CMDB asks whether the device is operational, what services it supports, and what other technology depends on it.
SAM asks whether the installed Visio product is correctly licensed, actively used, and still required.
No single record can answer all of these questions.
1. What Is IT Asset Management?
IT Asset Management is the broader operating model used to manage technology investments throughout their lifecycle.
ITAM is not simply another table or application beside HAM and SAM.
It is the overall discipline that connects:
Business demand
Standards and planning
Service Catalog requests
Procurement
Contracts
Hardware inventory
Software licensing
Cloud resources
Financial information
Assignment and ownership
Usage and reclamation
Security and lifecycle risk
Retirement and disposal
Audit evidence
Governance and reporting
The ITAM lifecycle begins before an asset is purchased and continues until the financial, operational, security, and physical obligations connected to that asset are closed.
For the laptop-and-Visio example, ITAM considers the entire journey:
The employee requires technology to perform a job. A request is submitted and approved. The laptop is sourced or purchased, received, stocked, deployed, supported, recovered, refreshed, and disposed of. Visio is requested, discovered, licensed, measured for consumption, reviewed for usage, reclaimed when no longer required, and considered during renewal.
ITAM therefore provides the complete business view.
Questions ITAM should answer
A mature ITAM program should be able to answer:
What technology does the organization own or subscribe to?
Why was it acquired?
How much did it cost?
Who is responsible for it?
Where is it currently located?
Is it being used?
Is the software correctly licensed?
Is the asset approaching end of support or end of life?
Can it be reused or reclaimed?
Should it be renewed, replaced, or retired?
Can the organization prove ownership and disposal during an audit?
ITAM depends on HAM, SAM, CMDB, procurement, HR, finance, discovery, contracts, and other systems to provide those answers.
ITAM is the governance layer
ITAM establishes the rules that connect these processes.
For example, it should define:
Which system owns purchase-order information
Which team creates and governs product models
Which source updates technical device information
Who owns Asset–CI exceptions
How software entitlements are validated
When unused software should be reclaimed
What evidence is required before an asset is considered disposed of
Which KPIs indicate reliable lifecycle management
ITAM is therefore not only about maintaining data.
It is about ensuring that the organization makes controlled decisions regarding cost, risk, compliance, ownership, and lifecycle value.
2. What Is Hardware Asset Management?
Hardware Asset Management is the ITAM discipline responsible for the physical, financial, contractual, and lifecycle management of hardware.
The HAM lifecycle can be summarized as:
Plan → Request → Source → Procure → Receive → Stock → Deploy → Support → Recover → Refresh → Retire → Dispose
HAM manages hardware such as:
Laptops
Desktops
Servers
Monitors
Mobile devices
Network equipment
Printers
Storage devices
Other trackable physical technology
The primary hardware lifecycle record is generally the Hardware Asset:
Hardware Asset [alm_hardware]
The Hardware Asset extends the base Asset table:
Asset [alm_asset]
The Asset record represents the organization’s financial and lifecycle responsibility for an individual item.
What HAM manages for the laptop
For our employee laptop, HAM should help answer:
Which Hardware Model was requested?
Was the laptop sourced from stock or purchased?
Which purchase order funded it?
What is its serial number and asset tag?
Which stockroom received it?
Who is currently assigned to it?
Where is it located?
What is its lifecycle state?
Is it covered by warranty?
Has it been repaired or replaced?
Is it due for refresh?
Was it returned during offboarding?
Was it securely disposed of?
These questions are not primarily technical questions about how the laptop operates.
They are ownership, inventory, cost, custody, and lifecycle questions.
Important HAM records and concepts
Hardware Asset
The Hardware Asset represents the individual physical device.
Two laptops of the same model require two Asset records because each device has its own serial number, asset tag, assignment, condition, and lifecycle history.
Hardware Model
The Hardware Model represents the product design rather than an individual unit.
For example, 1,000 Dell Latitude laptops may reference the same model, while each laptop has a separate Hardware Asset record.
The model standardizes information such as manufacturer, model name, model number, useful life, and product characteristics.
Model Category
The Model Category helps determine how assets associated with the model behave and whether they should relate to a particular CI class.
It helps connect the Asset data model with the CMDB data model.
Stockroom
The Stockroom represents controlled inventory.
It shows where available, reserved, defective, repair, or returned assets are physically held before their next lifecycle action.
State and Substate
State and Substate explain the current lifecycle position of the asset.
For example, an asset may be On Order, In Stock, In Use, In Maintenance, Retired, or in another configured lifecycle state.
The substate provides more detail, such as Available, Reserved, Pending Repair, Pending Transfer, or Pending Disposal.
What HAM does not replace
HAM does not replace the CMDB.
The Hardware Asset tells us that the organization owns a laptop, who is responsible for it, and where it is in its lifecycle.
It does not independently provide the complete operational picture of the device’s services, dependencies, incidents, changes, or technical relationships.
That is where the CMDB becomes important.
3. What Is the CMDB?
The Configuration Management Database manages Configuration Items and the relationships between them.
A Configuration Item is a component that needs to be managed to deliver or support a technology service.
Examples include:
Computers
Servers
Network devices
Applications
Databases
Cloud resources
Business applications
Application services
Other operational components
The base Configuration Item table is:
Configuration Item [cmdb_ci]
Specialized CI classes extend this table and provide attributes relevant to different technologies.
The CMDB is not simply another inventory of assets.
Its purpose is to create an operational model of the technology environment.
What CMDB manages for the laptop
For the employee laptop, the related CI may help answer:
Is the laptop operational?
When was it last discovered?
Which operating system is installed?
What is its hostname?
Which IP and MAC addresses are associated with it?
Which endpoint-management source reports it?
Which business application or service does it support?
Is it affected by an incident or change?
Does it have a vulnerability?
What other CIs are related to it?
What would be the operational impact if it failed?
These are operational and technical questions rather than primarily financial or custodial questions.
Asset vs CI
Asset and CI are among the most commonly confused concepts in ServiceNow.
A Hardware Asset and a CI may represent the same physical laptop, but they serve different purposes.
Perspective Hardware Asset Configuration Item
| Primary purpose | Financial, ownership, inventory, and lifecycle management | Technical, operational, service, and relationship management |
| Typical record | Hardware Asset [alm_hardware] | CI class extending [cmdb_ci] |
| Common information | Cost, purchase order, assigned user, stockroom, warranty, state, refresh, disposal | Operating system, hostname, IP address, discovery source, operational status, relationships |
| Primary users | Asset, procurement, stockroom, finance, lifecycle teams | Service desk, infrastructure, operations, change, incident, security teams |
| Key question | Who owns it, where is it, and what lifecycle stage is it in? | How is it operating, what does it support, and what depends on it? |
How Asset and CI work together
When a Hardware Asset has a corresponding CI, the records can be linked and selected fields can be synchronized.
For example, changes to assignment, location, model, serial number, or lifecycle status may need to remain aligned across both records.
However, synchronization depends on the Asset and CI pointing to each other correctly and on the fields and states being logically mapped.
A laptop should not have:
One Asset linked to the wrong CI
Multiple CIs representing the same physical device
Conflicting users or locations
A Retired Asset linked to an active CI without investigation
Software installations attached to a duplicate CI
An incorrect Asset–CI relationship affects more than CMDB quality.
It can also affect:
Incident and Change context
Vulnerability reporting
Software installations
SAM reconciliation
Refresh reporting
Employee offboarding
Lifecycle and security decisions
Does every Asset need a CI?
Not necessarily.
Some items require financial or inventory tracking but do not require operational management in the CMDB.
Simple accessories or non-operational items may be tracked as assets without corresponding CIs, depending on organizational policy.
Does every CI need an Asset?
Not necessarily.
Some logical, virtual, service, or non-owned operational components may need to exist in the CMDB without representing an individually owned physical asset.
The requirement should be based on business, financial, operational, security, and governance needs—not on a rule that every Asset and CI must always exist together.
Hardware Model vs CI Class
A Hardware Model and a CI class are also different.
Hardware Model
The Hardware Model identifies the commercial product.
For example:
Dell Latitude 5450
It explains what was purchased and standardizes product information across many individual assets.
CI class
The CI class defines the type of operational record and its technical attributes.
For example:
Computer CI class
It determines which technical fields and relationships are relevant to the CI.
A Hardware Model answers:
Which product is this?
A CI class answers:
What type of operational component is this?
The Model Category helps connect these concepts by relating a category of assets to an appropriate CI class.
4. What Is Software Asset Management?
Software Asset Management is the ITAM discipline responsible for managing software installations, ownership rights, license consumption, compliance, usage, optimization, renewals, and software lifecycle risk.
The SAM lifecycle can be summarized as:
Discover → Normalize → Model → Entitle → Reconcile → Optimize → Renew or Retire
SAM must connect two different realities:
Technical reality
What software is installed, assigned, or subscribed to?
Commercial reality
What software rights has the organization purchased or contracted?
Reconciliation connects these realities to calculate the license position.
What SAM manages for Microsoft Visio
For the Visio product installed on the laptop, SAM should help answer:
Was Visio discovered on the device?
How did the inventory source identify it?
Was the publisher, product, version, and edition normalized?
Which Software Model represents the product?
Does the organization have a valid entitlement?
What license metric applies?
How many purchased rights are available?
Does this installation or user consume a right?
Is the organization compliant?
Is Visio actively being used?
Can the license be reclaimed?
How many rights should be renewed?
The SAM data relationship can be summarized as:
Software Installation → Discovery Model → Normalization → Software Model ← Software Entitlement
Each component has a different responsibility.
Software Installation
A Software Installation provides technical evidence that software was detected on a device or CI.
The common record is:
Software Installation [cmdb_sam_sw_install]
It tells us that an inventory source reported software on a particular device.
It does not prove that the software was fully identified or licensed.
Software Discovery Model
The Software Discovery Model groups the raw publisher, product, version, and edition information reported by discovery or inventory sources.
The common record is:
Software Discovery Model [cmdb_sam_sw_discovery_model]
The Discovery Model represents how the software appeared in the source data before or during normalization.
Normalization
Normalization standardizes inconsistent discovered values into recognized publisher, product, version, and edition information.
Different tools may report Microsoft Visio using different names. Normalization allows ServiceNow to understand that those variations represent the same commercial product.
Without normalization, entitlement matching and reconciliation may be unreliable.
Software Model
The Software Model represents the commercial software product being managed.
The common record is:
Software Product Model [cmdb_software_product_model]
It connects normalized discovery data with entitlements, metrics, product-use rights, lifecycle information, and reconciliation.
The Discovery Model represents what was discovered.
The Software Model represents which licensable product the discovered software belongs to.
Software Entitlement
The Software Entitlement represents the organization’s right to use a software product.
The common record is:
Software Entitlement [alm_license]
It may include:
Software Model
Publisher part number
License metric
Purchased quantity
Subscription dates
Maintenance dates
Contract reference
Upgrade or downgrade rights
The entitlement represents purchased rights, not discovered usage.
Reconciliation
Reconciliation compares available rights with calculated consumption.
It considers relevant information such as:
Normalized software data
Software Model relationships
Entitlements
License metrics
Purchased rights
Install conditions
Allocations
Upgrade and downgrade rights
Subscription dates
Suites and components
The output helps determine whether the organization is compliant, underlicensed, or has available rights.
Usage and reclamation
Compliance tells us whether the organization owns sufficient rights.
Usage tells us whether those rights are being used effectively.
Visio may be correctly licensed but unused for several months.
A reclamation process may identify that user as a removal candidate, obtain the required approval, uninstall or revoke the product, confirm the removal, and return the right to the available pool.
SAM therefore does not end when compliance is calculated.
It also supports cost optimization, renewal decisions, and software lifecycle risk.
Software Installation vs Entitlement
This distinction is essential.
Perspective Software Installation Software Entitlement
| What it represents | Software detected on a device or associated with a user | The right purchased to use a software product |
| Source | Discovery, SCCM, Intune, Jamf, SaaS integration, or another inventory source | Purchase order, contract, invoice, license statement, or entitlement import |
| Key information | Device, discovered product, version, edition, discovery source | Software Model, quantity, metric, dates, PPN, contract, product-use rights |
| Main question | What software is deployed or assigned? | What software is the organization legally or contractually entitled to use? |
An installation does not prove ownership.
An entitlement does not prove deployment.
Both must connect through the correct Software Model and licensing rules before a reliable compliance position can be calculated.
5. How the Four Areas Work Together
Let us now view the laptop-and-Visio example through all four perspectives.
ITAM perspective
ITAM governs the complete investment.
It connects the employee’s business need with approval, procurement, contracts, hardware ownership, software rights, lifecycle risk, cost optimization, reclamation, and retirement.
ITAM asks:
Are we managing the complete technology investment responsibly?
HAM perspective
HAM manages the physical laptop.
It tracks the Hardware Model, purchase order, serial number, stockroom, assignment, warranty, lifecycle state, return, refresh, and disposal.
HAM asks:
Where is the laptop, who is responsible for it, and what should happen next in its lifecycle?
CMDB perspective
CMDB manages the laptop as an operational CI.
It tracks the technical identity, operating system, discovery status, service relationships, incidents, changes, vulnerabilities, and dependencies.
CMDB asks:
How is the laptop operating, what does it support, and what is its technical impact?
SAM perspective
SAM manages Microsoft Visio and the related license rights.
It tracks discovery, normalization, Software Model mapping, entitlement, metric, purchased rights, consumption, compliance, usage, reclamation, and renewal.
SAM asks:
Do we have the right to use Visio, how is that right being consumed, and can it be optimized?
One Device, Multiple Connected Records
For the same employee laptop and Visio installation, ServiceNow may contain:
Catalog Request and Requested Item
Purchase Order and Purchase Order Line
Hardware Model
Hardware Asset
Configuration Item
Software Installation
Software Discovery Model
Software Model
Software Entitlement
Reconciliation result
Usage and reclamation records
Return, retirement, and disposal evidence
These are not unnecessary duplicate records.
Each record represents a different business fact.
The implementation becomes unreliable only when those records are missing, duplicated incorrectly, or disconnected from one another.
Common Misunderstandings
“ITAM and HAM are the same.”
HAM is a major part of ITAM, but ITAM is broader.
ITAM also includes software, cloud, contracts, financial governance, licensing, optimization, risk, and overall lifecycle strategy.
“The Asset table is the CMDB.”
Asset Management and CMDB are related but have different objectives.
Assets support financial, contractual, inventory, ownership, and lifecycle management. CIs support technical, operational, service, and relationship management.
“Discovery creates accurate Asset data automatically.”
Discovery primarily provides technical evidence.
It may update or create CIs and contribute identification data, but procurement, receiving, ownership, cost, warranty, stockroom, and disposal information normally originate from other processes.
“If software is discovered, it is licensed.”
Discovery proves that software was detected.
Licensing depends on normalization, Software Model mapping, entitlement validity, metrics, purchased rights, and consumption rules.
“If an entitlement exists, the organization is compliant.”
An entitlement may be connected to the wrong Software Model, use the wrong metric, contain incorrect dates, or fail to cover the discovered deployment.
Compliance is determined through reconciliation—not by the existence of an entitlement alone.
“Retiring the Asset automatically closes everything.”
The Asset may be marked Retired while the CI remains active, the endpoint source continues reporting the device, software installations remain associated with it, or disposal evidence is missing.
Physical, financial, operational, software, security, and evidence closure must be validated together.
Responsibility Without Duplicate Ownership
The purpose of connecting ITAM, HAM, SAM, and CMDB is not to make every team own every record.
Ownership should be clear.
For example:
Procurement may own purchase orders and supplier transactions.
HAM may own stockrooms, assignments, lifecycle states, returns, and disposal.
CMDB and infrastructure teams may own CI quality and operational relationships.
Discovery teams may own technical inventory sources and identification quality.
SAM may own normalization exceptions, entitlements, reconciliation, and reclamation.
HR may own employee status.
Finance may own capitalization, depreciation, and financial policy.
ITAM governance may define controls, KPIs, ownership, and escalation.
The systems and teams must collaborate, but their responsibilities should not be duplicated or ambiguous.
What Good Governance Looks Like
A reliable implementation should regularly identify exceptions such as:
Hardware Assets without expected CIs
CIs without Assets where ownership tracking is required
Asset and CI records with conflicting users or locations
Duplicate Assets or CIs
Retired Assets still being discovered
Software Installations without normalized Discovery Models
Discovery Models without appropriate Software Models
Entitlements missing required product or metric information
Unlicensed products despite available purchase evidence
Assets and subscriptions assigned to inactive users
Reclamation candidates not progressing
Retirement or disposal records missing evidence
Each exception should have:
A clearly assigned owner
A target resolution time
A documented correction process
Downstream validation
A preventive control
This is how the four areas operate as one governed model rather than separate databases.
The Foundation of the Connected Model
The same principle applies across ITAM, HAM, SAM, and CMDB.
Clean Data
Models, serial numbers, CIs, relationships, installations, entitlements, users, locations, and lifecycle states must be accurate.
Trusted Integrations
Procurement, HR, Discovery, endpoint, finance, SaaS, and disposal systems must update the correct records without creating unnecessary duplicates.
Clear Ownership
Every record type, data element, integration, exception, and lifecycle decision must have an accountable owner.
Strong Governance
The organization must monitor data quality, investigate exceptions, validate corrections, and prevent the same issue from recurring.
Together:
Clean Data + Trusted Integrations + Clear Ownership + Strong Governance = Reliable ITAM Decisions
Key Takeaway
ITAM, HAM, SAM, and CMDB are not competing systems.
They are connected perspectives of the same technology environment.
ITAM manages the complete investment and governance model.
HAM manages the physical and financial hardware lifecycle.
SAM manages software rights, consumption, compliance, and optimization.
CMDB manages operational CIs and their technical relationships.
The laptop Asset tells us who owns the device and where it is in its lifecycle.
The laptop CI tells us how the device is operating and what it supports.
The Visio installation tells us that software was detected.
The Visio entitlement tells us what rights were purchased.
ITAM connects these facts so that the organization can make reliable decisions about cost, risk, compliance, ownership, usage, and lifecycle value.
POST -2 - Understanding the End-to-End ITAM Data Flow in ServiceNow
Coming Next — Day 4
Hardware Asset Management Lifecycle: From Request and Procurement to Deployment
In Day 4, we will begin the HAM deep dive and explain:
Hardware standards and demand
Catalog requests and approvals
Sourcing from existing stock
Procurement and purchase orders
Receiving
Stockroom entry
Reservations and asset picking
Deployment and assignment
Important ServiceNow records and relationships
Common implementation gaps across the flow
Which distinction creates the most confusion in your environment: ITAM versus HAM, Asset versus CI, or Software Installation versus entitlement?
#ServiceNow #ITAM #HAM #HAMPro #SAM #SAMPro #CMDB #AssetManagement #HardwareAssetManagement #SoftwareAssetManagement #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