IT Service Management and Enterprise Operations

01Purpose and scope

• This manual supports the course IT Service Management and Enterprise Operations. It is written for service desk analysts, incident and problem coordinators, change managers, service owners, and operations leads who need a working reference for how services are delivered, supported, and changed inside a larger organization.
• The scope covers the practices that keep business services available and predictable: intake and triage of requests, incident restoration, problem analysis, change control, service level commitments, configuration and asset records, and the handoffs between internal teams and external providers. It does not teach hardware repair, software development, or cloud architecture in depth, although those fields feed into service operations every day.
• Practice varies a great deal by context. A bank with regulated payment systems, a hospital with clinical applications, and a manufacturer with plant floor networks each run service management differently, with different tolerances for downtime and different approval rules. Treat this manual as a baseline you adapt, not a rulebook you copy.

02Core principles

• Services exist for users and business outcomes, not for the tools that track them. A ticket closed without the user regaining the ability to work is a failed ticket, even if every field in the system is complete. Start each decision by asking what the affected person can now do, and what they could not do before.
• Restore first, then find the cause. During a major incident, the priority is returning the service to a usable state through a workaround or rollback. Root cause analysis belongs in a separate problem record where people have time to test theories without pressure from the business.
• Make change visible and reversible. Every change to a production service should have an owner, a stated purpose, a risk assessment, a back-out plan, and a record. Changes that cannot be backed out need stronger review and a named decision maker.
• Use a single source of truth for service relationships. Incidents, changes, and requests are only as useful as the configuration data behind them. If the service catalog says an application depends on a database that no longer exists, every downstream decision is compromised.
• Match control to consequence. A password reset and a firewall rule change should not pass through the same approval path. Tiered controls keep routine work moving and focus scrutiny where failure would be expensive.

03Planning and preparation

• Before running operations, define the service catalog. Each entry should name the service, the business owner, the technical owner, the users, the supported hours, the dependencies, and the criticality rating. Many teams find that the catalog is the hardest artifact to keep current, so assign a named owner and a review cycle from the start.
• Agree service level targets with the business before they are needed. Targets usually cover response time for incidents and requests, restoration time for major incidents, and availability over a reporting period. Write down what each target measures and how the clock starts and stops. Ambiguous clock rules cause most disputes about breached commitments.
• Set up the toolchain with defined categories, priorities, and routing rules. Priority is normally derived from impact and urgency, so that a single user with a broken printer does not outrank a payroll run for an entire site. Keep the category list short enough that analysts choose consistently.
• Establish the change advisory process before the first major change. Decide who sits on the board, how often it meets, what counts as a standard change that needs no board review, and how emergency changes are authorized and reviewed afterward. Publish these rules so teams know the path before they need it.
• Plan for staffing coverage and escalation. Document on-call rotations, escalation paths to vendors, and contact details for after-hours decision makers. Test the contact list at least once a quarter, because people change roles and phone numbers more often than documents reflect.

04Recommended workflow

1. 1
   : Capture the request or incident with enough detail to act. Record who is affected, what they were doing, what changed recently, the exact error text if available, and the time it started. Avoid free text that says only that something is broken.
2. 2
   : Classify and prioritize. Assign category, service, and priority using the agreed impact and urgency matrix. If several users report the same symptom, link the records to one parent incident rather than working them separately.
3. 3
   : Restore service. Apply the known error workaround if one exists in the knowledge base. If none exists and the impact is high, escalate to the major incident process, name an incident commander, open a shared communication channel, and post updates at a fixed interval such as every thirty minutes until service is restored.
4. 4
   : Diagnose and document. Record each action taken, the result, and the time. Analysts who skip this step make the next shift repeat the same tests. Keep notes factual and avoid guesses presented as findings.
5. 5
   : Plan and route any change needed for a permanent fix. A problem record captures the underlying cause, the proposed correction, and the risk. The change request references the problem and the affected configuration items. Standard changes with pre-approved templates can proceed quickly, while normal changes go to the board.
6. 6
   : Verify and close. Confirm with the user that the service works for their actual task, not only that the system reports green. Record the resolution code, the workaround or fix, and whether a problem record is still open. Closing without confirmation inflates reported performance and hides recurring faults.
7. 7
   : Review. For major incidents, hold a post-incident review within a few working days. Focus on timeline, decisions, communication gaps, and changes to detection or runbooks. Assign actions with owners and dates, and check that they are finished.

05Quality checks, risk controls and compliance

• Quality checks happen at three points: at intake, at closure, and in periodic sampling. At intake, check that required fields are complete and that the category matches the described symptom. At closure, check that the resolution describes what was actually done. In sampling, have a reviewer read a random set of closed records each month and score them against a short rubric.
• Risk controls for change include a documented impact assessment, a test or validation step appropriate to the change, a scheduled window that avoids peak business activity, a communication notice to affected users, and a tested back-out procedure. For high-risk changes, require a second technical reviewer who did not write the change.
• Segregation of duties matters. The person who requests a production change should not be the only person who approves it, and the person who deploys it should not be the only person who verifies it. Access to production systems should be granted through a recorded request and reviewed on a schedule.
• Compliance requirements depend on jurisdiction, industry, and contract. Frameworks such as ISO/IEC 20000-1, which specifies requirements for a service management system, and COBIT, which is a governance framework, are commonly used as references, but their applicability and certification status depend on your organization. Regulated sectors such as healthcare, finance, and public sector work carry their own record retention, privacy, and change control rules. Confirm current requirements with your compliance function and the authoritative regulator for your jurisdiction. This guidance does not replace qualified professional judgment, approved procedures, or required authorization for regulated work.
• Vendor and outsourced services need the same discipline. Contracts should define service levels, reporting, escalation, and termination assistance. Review vendor performance reports against your own records, because vendors measure their clocks differently.

06Collaboration and documentation

• Service management depends on handoffs between the service desk, technical groups, application owners, facilities, security, and business units. Each handoff should carry the full context. A ticket reassigned three times without notes forces each new group to restart diagnosis, and users notice the delay.
• Maintain a knowledge base with articles tied to known errors, common requests, and standard procedures. Each article should state the symptom, the verified workaround, the date it was last tested, and the owner. Remove or flag articles that no longer match the current environment.
• Use runbooks for recurring operational tasks such as backup verification, certificate renewal, and failover testing. A runbook should list prerequisites, exact steps, expected output, and what to do if the output differs. Analysts should be able to follow it at two in the morning without asking a colleague.
• Communication during incidents follows a predictable pattern. Tell affected users what is broken, what is being done, what they should do in the meantime, and when the next update will come. Avoid technical jargon in user notices, and avoid promising restoration times you cannot control.

07Measures and continuous improvement

• Track a small set of indicators that reflect service outcomes. Useful measures include percentage of incidents restored within target, number of major incidents per service per period, change success rate with and without incidents traced to change, percentage of requests fulfilled on first contact, backlog age, and availability of critical services measured from the user side where possible.
• Interpret measures with care. A low incident count can mean stable services or poor logging. A high change success rate can mean that changes are too small to matter. Read indicators alongside sampled records and user feedback before deciding a process is failing or succeeding.
• Use problem records to reduce repeat demand. Count how many incidents each known error generated and prioritize the permanent fixes that remove the most user disruption per unit of effort. Track whether fixes actually reduced incident volume after deployment.
• Review the process itself on a fixed cycle. Each quarter, look at the top sources of rework, the categories most often reclassified, the changes that caused incidents, and the approval steps that added delay without reducing risk. Remove steps that do not earn their cost, and strengthen steps that repeatedly catch problems.

08Common mistakes and how to prevent them

• Treating the service catalog as finished after the first load. Catalogs decay when services are retired, merged, or moved to a new provider. Schedule owner reviews and tie catalog updates to the change process so that new services cannot go live without an entry.
• Measuring response time and ignoring resolution quality. Fast closure of tickets with vague resolutions creates hidden rework. Include sampled quality reviews in the reporting pack alongside speed targets.
• Approving changes without understanding dependencies. A patch to a shared component can affect several services. Use the configuration records to list affected services before the change board meets, and require owners of those services to confirm they have been consulted.
• Running emergency changes without follow-up. Emergency changes are sometimes necessary, but they bypass normal review. Require a retrospective change record within a set number of working days, and report the count of emergency changes to management each period.
• Letting the knowledge base drift. Articles that describe retired systems mislead analysts under pressure. Assign owners, review dates, and a simple retirement step for articles.

09Practical checklist

• Confirm each live service has a catalog entry with a named business owner, technical owner, and criticality rating.
• Verify that service level targets have written clock rules and have been agreed with the business in writing.
• Check that the impact and urgency matrix is published and that analysts use it consistently in sampled records.
• Confirm that major incident roles, communication channels, and update intervals are documented and tested.
• Require a risk assessment, back-out plan, and affected-service list for every normal and major change.
• Review emergency changes for retrospective records within the agreed period.
• Sample closed tickets monthly and score resolution quality against the agreed rubric.
• Confirm that runbooks for recurring tasks list exact steps and expected output, and that they were tested in the last review cycle.
• Review the knowledge base for articles past their review date and retire or update them.
• Hold post-incident reviews for major incidents and track each action to completion.
• Check vendor performance reports against internal records each quarter.
• Confirm current compliance obligations with the appropriate function and authoritative source for your jurisdiction and sector.

★Learning sources

• Micro Degree: IT Service Management and Enterprise Operations
• Micro Degree: Data Analytics Applications
• Micro Degree: Azure Cloud Fundamentals
• Micro Degree: Google Cloud Platform Basics