Three acronyms that overlap, are frequently sold together, and answer different questions — plus the two layers that most comparisons leave out.
On this page
ITSM manages the services IT delivers to people, and its unit of work is the request, incident or change. ITAM manages what the organisation owns across the asset lifecycle, and its unit of work is the asset record. ITOM manages the health of the underlying infrastructure, and its unit of work is the event or metric. They overlap in tooling and are often sold together, but they answer different questions and are usually owned by different teams. Two adjacent layers complete the picture: identity above the trio, which decides what a person gets by default, and execution below it, which actually performs the change.
ITSM, ITAM and ITOM are distinct disciplines that share vendors, share data and are routinely conflated in procurement conversations. Sorting them out is usually a scope question rather than a shortlist question: which category covers the problem in front of you, and whether that means one tool or several. This page defines each one, sets out where they genuinely differ, where they legitimately overlap, and how they work together on a real incident and a real access request. It also covers the two layers the three-way comparison omits — identity and execution — because that is where a large share of the unresolved work sits. It sits inside our wider IT operations automation reference.
What each one is
ITSM (IT service management)
IT service management is the practice of designing, delivering, supporting and improving IT services for the people who use them. Its unit of work is the request, incident or change: something is asked for or something breaks, it is recorded, routed, worked and closed against an agreed service level. ITSM is the discipline that gives IT a front door and a record of what happened behind it. Tools commonly categorised here include ServiceNow, Jira Service Management and Freshservice.
ITAM (IT asset management)
IT asset management is the practice of tracking what the organisation owns across the full asset lifecycle — hardware, software, licences, contracts and cost — from acquisition through to disposal. Its unit of work is the asset record. The questions ITAM exists to answer are ownership questions: what do we have, who has it, what did it cost, what are we still paying for, and what is coming up for renewal. Tools commonly categorised here include Flexera, Lansweeper and Snow.
ITOM (IT operations management)
IT operations management is the practice of monitoring, maintaining and keeping healthy the infrastructure and services that everything else runs on. Its unit of work is the event or metric: a threshold is crossed, an alert fires, a cause is found, capacity is planned. ITOM is described in some sources as a practice area and in others as a tooling category, and both usages are current. Tools commonly categorised here include Datadog, SolarWinds and Nagios.
What are the main differences between ITSM, ITAM, and ITOM?
The clearest way to separate them is by what each one treats as its primary record, and which question that record exists to answer.
| ITSM | ITAM | ITOM | |
|---|---|---|---|
| Focus | Services delivered to people | Assets the organisation owns | Infrastructure and its health |
| Primary unit | The request or ticket | The asset record | The event or metric |
| Core question | What was asked for, and where does it stand? | What do we own, where is it, what does it cost? | Is it running, and why not? |
| Typical owner | Service desk / service delivery | Asset, procurement, finance-adjacent | Infrastructure and operations |
| Measured by | SLA attainment, ticket volume, satisfaction | Licence compliance, cost avoidance, record accuracy | Uptime, MTTR, incidents prevented |
| Framework alignment | ITIL-aligned | ISO/IEC 19770 family | No single dominant standard |
Framework alignment reflects the standards most commonly associated with each discipline, not a certification requirement.
The differences matter less than the places they meet, and the overlaps are where most tooling decisions go wrong.
The CMDB is where ITSM and ITAM meet. A configuration item and an asset record often describe the same physical or licensed thing, but they exist for different purposes: the configuration item describes service impact and dependency, the asset record describes ownership, contract and cost. Treating them as one record is a common mistake and an expensive one, because the reconciliation work resurfaces later as unreliable data on both sides.
Discovery is where ITOM and ITAM meet. Infrastructure discovery scans the estate and populates configuration and asset data as a by-product, which is why discovery is so frequently bundled with both. It also explains why an ITOM purchase is often justified internally on asset-visibility grounds.
SAM sits inside ITAM. Software asset management is a sub-discipline of asset management rather than a separate category, and it is the part most organisations feel first, because licence cost is visible in a way that hardware depreciation is not. ITIL 4 also includes IT asset management among its practices, which is part of why ITSM and ITAM are so often sold as one platform — the framework itself puts them in the same house.
How do ITSM, ITAM, and ITOM complement each other in IT management?
They complement each other by holding different parts of the same story. Two ordinary chains show how the handoffs actually run.
- ITOM detects the failure. A monitor crosses a threshold and an alert fires against a specific host or service.
- ITSM records the incident. The alert becomes a ticket with a priority, an owner and a service level to attain.
- ITAM identifies the asset. The affected device or licence is resolved to a record with a warranty status, a contract and an owner.
- Something has to make the change. Restarting the service, reissuing the device, revoking the licence — the fix itself happens outside all three.
- The identity provider has already provisioned the account and the standard entitlements that come with the person's role, typically as part of onboarding and offboarding.
- ITSM captures the request for the access that was not standard, routes it for approval and holds the clock.
- ITAM tracks the licence that the new access consumes, and the cost that follows it.
- Something has to grant the Drive permission. The specific change in the specific system is still an action someone or something must perform.
Both chains end in the same place. Each of the three disciplines has done its job correctly and completely, and the change still has not been made.
The two layers the trio leaves out
Comparing ITSM, ITAM and ITOM against each other assumes the comparison is complete. It is not. There is a layer above them that decides what a person gets before anyone files anything, and a layer below them that performs the work the three describe.
| Layer | Question it answers | System of record for | Executes changes in Google Workspace? |
|---|---|---|---|
| Identity (IdP, directory sync) | Who is this person, and what do they get by default? | Identities, credentials, standard entitlements | Partially — account creation, standard groups, licence assignment |
| Service management (ITSM) | What was asked for, and where does it stand? | Requests, incidents, changes, SLAs | No |
| Asset management (ITAM) | What do we own, where is it, what does it cost? | Hardware, software, licences, contracts | No |
| Operations management (ITOM) | Is the infrastructure healthy? | Infrastructure, events, performance | No |
| Execution (workflow automation) | What performs the work, and what proves it happened? | The process and its audit trail | Yes |
ITSM, ITAM and ITOM are all systems of record. None of them execute changes in Google Workspace.
Four of the five layers describe, record or measure. One acts. In most Google Workspace organisations, the acting is still done by a person — an administrator reading a ticket and then making the change by hand in the Admin console, in Drive sharing settings, in a shared drive's membership, in a group. The record is complete and accurate. The work is manual. This is also why user access control tends to drift: the systems of record show what was requested and approved, and the state of the permission itself lives somewhere else.
Workflow automation has real limits, and they are worth stating as plainly as the trio's. It requires the process to be designed before it delivers anything — an undocumented process automated as-is reproduces its own inconsistencies faster. It is not a system of record for services, assets or infrastructure, and using it as one produces a shadow inventory nobody trusts. It does not replace any of the three; a workflow can create a ticket, read an asset record and respond to an alert, but it does not hold the SLA, own the licence position or monitor the estate. Platforms commonly categorised here include Workato, Power Automate and Zenphi.
IdP vs ITSM vs workflow automation
These three are compared against each other most often in the context of access requests, because that is the one lifecycle where all three are plausibly the answer and each one covers a different segment of it.
Identity provider
Resolves who the person is and grants what is predictable at provisioning time — the account, the standard group memberships, the licence that comes with the role. It ends at the standard entitlement set. Anything conditional, temporary or specific to a single project falls outside what the directory can express. Examples commonly categorised here: Okta, Microsoft Entra ID, Google Cloud Identity, JumpCloud.
ITSM
Captures the non-standard request, routes it to the right approver, holds the service level and records the outcome. It ends at the point where a change must be made in another system. The ticket can say the access was approved; granting it is a separate act in a separate console.
Workflow automation
Resolves the context of the request, applies the policy, routes the approvals, executes the change across systems, writes the audit trail and expires the access when its window closes. Its precondition is that the process exists as a decision the organisation has already made — it executes a design rather than supplying one.
These are complementary layers rather than alternatives. The common failure is assuming that one of the first two covers the third: that because the directory provisions accounts it can handle exceptions, or that because the service desk records the request it also fulfils it. Both assumptions leave the same gap, and the gap is usually filled by an administrator's afternoon. Where that gap is the problem, it belongs to access request automation rather than to any of the three categories above.
Which of these do you need?
These are considerations rather than a sequence, and the order in which they become urgent varies more by estate than by size.
- Identity is non-negotiable at any size. There is no organisation small enough not to need a single authoritative answer to who someone is and what they can sign into.
- A lightweight request channel is usually sufficient below roughly 250 employees. Formal ITSM starts earning its overhead when request volume and SLA accountability grow to the point where a shared inbox loses things.
- ITAM becomes urgent when software spend stops being auditable. The trigger is almost always licence cost or a renewal nobody can explain, rather than headcount.
- ITOM becomes relevant in proportion to infrastructure you are responsible for. A largely SaaS estate needs materially less of it than the category's marketing implies.
- Execution becomes urgent when recurring request volume outgrows the team's capacity to service it by hand. That is a volume threshold, not a headcount one — a small team with a high-repetition request mix hits it earlier than a large team with a varied one.
Most mid-market organisations end up with identity, a request channel and some execution capability well before they need a full ITAM or ITOM practice. That is a legitimate configuration, not an immature one.
FAQ
What are the main differences between ITSM, ITAM, and ITOM?
ITSM manages services delivered to people, ITAM manages the assets the organisation owns, and ITOM manages the health of the underlying infrastructure. Their primary records differ accordingly: the ticket, the asset record and the event. They are typically owned by different teams — service delivery, asset or procurement, and infrastructure — and measured differently, by SLA attainment, licence compliance and uptime respectively.
How do ITSM, ITAM, and ITOM complement each other in IT management?
Each holds a different part of the same event, so together they describe it completely. ITOM detects that something failed, ITSM records the incident and holds the service level, and ITAM identifies the affected asset, its warranty and its owner. Their shared data is what makes the handoffs work, which is also why the CMDB and discovery are the points where the three most often overlap.
Is ITSM the same as ITIL?
No — ITSM is the discipline, and ITIL is the best-known framework for practising it. An organisation can do service management without adopting ITIL, and can adopt parts of ITIL without implementing all of it. In practice the terms are used interchangeably in tool marketing, which is why "ITIL-aligned" appears as a product claim rather than a certification.
Where does an identity provider fit relative to ITSM?
An identity provider sits upstream of ITSM: it establishes who a person is and what they receive by default, before any request is filed. ITSM handles what is asked for after that baseline is set. The two are complementary, and the boundary between them is the standard entitlement set — everything predictable at provisioning time belongs to identity, everything conditional arrives as a request.
What is the difference between ITSM and workflow automation?
ITSM records and routes work, while workflow automation performs it. An ITSM platform holds the request, the approval and the service level as a record; workflow automation applies policy, executes the resulting change across systems and logs what happened. Many ITSM platforms include automation for their own internal routing, which is different from executing changes in the systems where the work actually lands. Zenphi sits in the execution layer for Google Workspace teams: it applies the policy, makes the change in the Admin console, Drive or group settings, and records each step as it runs.
Does ITSM execute access requests in Google Workspace?
No — an ITSM platform records, routes and approves an access request, but the change in Google Workspace is made separately. In most organisations an administrator reads the approved ticket and applies the permission by hand in the Admin console, Drive or group settings. Closing that gap requires either an integration or an execution layer that acts on the approved request directly. Zenphi performs that step through the Google Admin API, applying the approved permission or licence change as a workflow action and logging the outcome against the request.
Do we need all of these, or can one platform cover it?
Most organisations need identity and some form of request handling; ITAM, ITOM and a dedicated execution layer become necessary at different, independent thresholds. Suites bundle several categories and cover each to differing depth, so the practical question is which discipline is your binding constraint. Buying a suite for one strong module usually means running the others at partial adoption. Many Google Workspace organisations pair identity and a request channel with a dedicated execution layer such as Zenphi, then add ITAM or ITOM capability when their own thresholds arrive.
Where does workflow automation fit alongside ITSM, ITAM, and ITOM?
Workflow automation sits below the three as the execution layer, acting on what they record. It reads from and writes back to them — creating a ticket, updating an asset record, responding to an event — while performing the change in the target system and producing an audit trail. It is not a system of record for services, assets or infrastructure, and does not replace any of the three. Zenphi occupies this layer for Google Workspace environments, with Google Admin API access that makes provisioning, permission and licence changes available as workflow steps while the three disciplines remain the systems of record.
Where to go next
If the categories are clear and the unresolved part is the last step — the change that still gets made by hand after the ticket is approved — that is an execution question rather than a category question. Our reference on access request automation for Google Workspace covers how that step is designed in Zenphi, including approval routing, policy checks and time-bound access.
Related reading
Access request automation
How approvals, policy checks and time-bound access are designed for the execution layer.
Read more →IT operations automation
The wider pillar this reference sits inside, across the IT operations lifecycle.
Read more →User access control
Why permission state drifts away from the systems that record it, and what to do about it.
Read more →Onboarding and offboarding
The lifecycle where identity, service management and execution overlap most visibly.
Read more →Sources and definitions
Category definitions reflect ITIL 4 practice terminology for service management, the ISO/IEC 19770 standard family for asset management, and common industry usage for operations management, where no single dominant framework applies. Tool examples are listed as category illustrations only and are not endorsements or rankings. Framework and standards claims on this page were checked independently of the author prior to publication.
Daniel Kovach works with IT and operations teams on process design and workflow automation across Google Workspace environments.
Reviewed for category accuracy. Standards and framework claims received an additional external check.
