HERM names the systems and the capabilities they deliver. ITSM, guided by ITIL, governs how those systems are run as services day to day — how they are requested, changed, restored, and improved — so the estate is not just mapped but operated with discipline.
IT Service Management (ITSM) is the practice of designing, delivering, and running technology as services with defined value, ownership, and quality — rather than as a loose collection of systems. ITIL is the most widely adopted framework for doing ITSM well: a set of management practices for the whole service lifecycle, from strategy and design through transition, operation, and continual improvement.
Its purpose is the question that begins the moment a system goes live: not what do we run, but how do we keep it running well — handling requests, incidents, and changes without breaking the things around it. ITSM is how the estate is operated, governed, and steadily improved.
ITIL depends on knowing what you run and how it connects — which is exactly what HERM provides. The estate model becomes the backbone of a service catalog and a configuration model; ITIL practices then run on top of it. Join them and every service has a home in the reference model, and every change is assessed against real dependencies.
HERM capabilities and systems become the services users can request — a catalog grounded in what the institution actually does.
The integrations and dependencies in the catalog are the impact analysis ITIL change management needs.
The recovery tier already on each system sets incident priority and restoration order — no separate judgment call.
ITIL organizes service management as a value chain: demand comes in, value goes out, and six activities turn one into the other — all running on the shared estate model beneath. Adapted from the ITIL 4 service value chain.
Plan and Improve wrap the whole chain; the HERM model is the shared source every activity draws on. Simplified from the ITIL 4 service value chain.
ITIL 4 defines a broad set of management practices. These are the ones that map most directly onto the estate model, each running on data HERM already carries.
Fulfilling routine user requests — grounded in a service catalog built from HERM capabilities.
Restoring normal service quickly; incident priority follows each system's recovery tier.
Assessing and authorizing changes using the dependency map in the catalog as impact analysis.
Finding root causes of recurring incidents — often a capability with overlap or no owner.
Setting and tracking service targets against the systems that deliver each capability.
Maintaining the configuration model — the systems, their attributes, and how they relate.
Extending the model toward ITSM means adding service-management attributes to each record and a few operational artifacts. A pragmatic starting set:
Each system framed as one or more services, with a service owner accountable for its delivery.
The availability, response, and resolution targets promised for each service.
The systems and their dependencies as a configuration model — the CMDB, seeded from the catalog.
How issues and requests for each service are classified and routed.
Standard, normal, or emergency change, with risk assessed against real dependencies.
Who supports each service, at what tier, and during which hours.
Enterprise service management (ESM) applies ITSM practices to services delivered by offices outside IT: service portals, request workflows, knowledge bases, and automation. On a campus that means HR, facilities, finance, legal, the registrar, financial aid, housing, and research administration. The analyst firm Forrester is largely credited with coining the term.
Every office already delivers services. Most handle them through email, chat, and spreadsheets, where requests get lost or duplicated. ESM makes those services visible, consistent, and measurable through one shared platform. It is not ITSM versus ESM but ITSM plus ESM: a good ITSM practice is the base, and each office adopts the parts that fit its work rather than copying IT's processes wholesale.
One front door where students and staff find answers, submit requests, and track progress, without knowing which office owns the work.
Each office maps its own process, such as HR onboarding or facilities maintenance, while following a shared structure.
Routine steps run on their own: routing to the right person, approval notices, and status updates. Fewer manual handoffs means fewer dropped requests.
Without ESM, the hiring manager emails HR, HR emails IT for a laptop and accounts, and facilities gets a separate message about an office and keys. Each office works alone, and steps get missed.
With ESM, HR submits one request in the portal. It triggers tasks everywhere at once: IT provisions accounts, facilities prepares the workspace and ID card, payroll is set up, and the manager gets an onboarding checklist. Everyone sees the same status, and the new hire arrives to a ready desk and working logins.
Offices name what they offer and publish it in one catalog, available at any hour.
Cross-office work like onboarding follows one defined sequence instead of a chain of emails.
Once services are cataloged, their steps can be automated and every action is logged.
What is tracked can be measured. Outstanding ID cards or access grants show up in a monthly report instead of being forgotten.
Each non-IT service links to a HERM capability, such as Student Support, Human Resource Management, or Facilities and Estate Management. That gives it one owner and a place in the model.
Record the ESM platform (ServiceNow, TeamDynamix, Jira Service Management) the same way as Salesforce and Workday. Each module gets its own placement and owner.
Workflows and journey maps show where requests pass between offices, which tells you what the shared workflow needs to route.
The catalog shows the small ticketing and form tools that departments bought on their own. These are the first candidates to move onto the shared platform.
Start small, prove value, then expand. Stand up one portal for all internal requests. Publish each office's most common questions so people can help themselves. Automate repetitive, well-defined processes with several handoffs first, such as equipment, access requests, and approvals. Move to harder cross-office workflows once teams are comfortable.
When choosing a platform, weigh how it scales to many offices, how it connects to existing systems like the SIS, HR system, and Teams or Slack, how easily non-technical staff can build forms and workflows, and what reporting it offers. The procurement intake page shows how to check a candidate against the model before buying.
The usual mistake is buying the platform before agreeing who owns each service. Decide the catalog and ownership first, and involve the other offices from the start so it doesn't become "IT's tool."
Reference: What is enterprise service management (ESM)?, Atlassian. Adapted here for higher education; tool names are examples, not endorsements.
Start by turning the systems you have already recorded into a service catalog: name the service, name its owner, and seed the configuration model from the integrations already captured. Incident priority and change impact then fall out of data the model holds — so the service desk and the architecture speak the same language instead of keeping two disconnected lists.
ITIL is a registered framework of its owner; ITSM is the broader discipline. This page describes how they complement HERM; the service definitions, SLAs, and configuration items are local extensions an institution would populate with its own data.