lecture (4)

1. IS Service Management and Benefit Management

Information Systems Management (5BUIS011C)
Jakhongir Karimov, Olga Yugay
Computing Department
Tashkent, Uzbekistan
2026

2. Why “IS Service Management” matters

• IT is not “projects only” — after go-live, the system becomes a service
• Users judge availability, speed, support quality, reliability
• Business wants predictable cost + measurable value
• Regulators/auditors want controls, traceability, risk management
• Competition forces continuous improvement
Computing Department
2

3. Key definitions

• Service: a means of delivering value by facilitating outcomes customers want, without
customer owning specific costs/risks
• IT service: a service enabled by IT (apps, data, infra, support)
• ITSM: practices to design, deliver, operate, and improve IT services
• Process: repeatable activities with inputs/outputs (e.g., Incident Mgmt)
• KPI: measurable indicator of performance (e.g., MTTR, uptime)
Computing Department
3

4. “Service” vs “System” mindset

• System mindset: “We deployed the software.”
• Service mindset: “We keep it useful every day.”
• Service mindset means:
• ownership of end-to-end user outcome
• stable operations + controlled changes
• measurement (SLA/KPIs) + improvement
Computing Department
4

5. ITSM operating model

Demand → Design → Transition → Operate → Improve
• Demand: business needs, priorities, budget
• Design: architecture, security, capacity, SLAs
• Transition: change/release, testing, training, knowledge
• Operate: incidents, requests, monitoring, problem mgmt
• Improve: CSI/continual improvement, root causes, automation
Computing Department
5

6. ITSM frameworks: why we need them

Frameworks provide:
• standard language (incident, problem, change…)
• governance and accountability
• audited controls + compliance mapping
• proven practices to reduce chaos and firefighting
• benchmarking and maturity improvement
Computing Department
6

7. ITIL: what it is

ITIL = best-practice guidance for IT service management
Focus: service lifecycle / value stream and practices such as:
• incident, problem, change enablement
• service request, service catalog
• service level management
• continual improvement
• knowledge, configuration, monitoring
Computing Department
7

8. COBIT: what it is

COBIT = governance & management framework for enterprise IT
Focus:
• aligning IT goals with business goals
• governance objectives, controls, assurance
• risk management and compliance
• performance management and maturity
Computing Department
8

9. ISO/IEC 20000: what it is

ISO/IEC 20000 = international standard for IT service management systems (SMS)
Focus:
• requirements for building a certifiable ITSM management system
• documented processes, audits, continual improvement
• governance + operational discipline in one standard
Computing Department
9

10. ITIL vs COBIT vs ISO 20000

• ITIL: practical service management guidance (processes/practices)
• COBIT: governance, controls, risk, alignment with enterprise goals
• ISO/IEC 20000: certifiable standard for ITSM system and audits
Typical combo in real orgs:
• COBIT for governance + ITIL for operations + ISO 20000 for certification
Computing Department
10

11. Where frameworks meet in practice

Common overlap areas:
• clear ownership and roles (RACI)
• policies and procedures
• service performance measurement (KPIs / SLAs)
• risk and compliance evidence
• continual improvement cycle (Plan–Do–Check–Act)
Computing Department
11

12. What an ITSM tool actually does

An ITSM tool is a system of record for IT work + service quality. It typically manages:
• tickets (incidents / requests / problems)
• change approvals and calendars
• CMDB/assets/inventory
• knowledge base and self-service portal
• service catalog + request workflows
• SLAs + dashboards + reporting
• automation (routing, approvals, notifications)
Computing Department
12

13. Service desk: the “front door” of IT

Service desk functions:
• single point of contact for users
• ticket intake (portal/email/chat/phone)
• categorization, prioritization, assignment
• user communication and status updates
• escalation to specialists
• customer satisfaction feedback (CSAT)
Computing Department
13

14. Ticket types

• Incident: unplanned interruption or reduction in service quality
• Service request: standard user request (access, install, reset, new laptop)
• Problem: underlying cause of one or many incidents
• Change: planned modification to reduce risk / improve services
• Task: internal work item (often part of change/problem/request)
Computing Department
14

15. Incident Management

Goal: restore normal service quickly and minimize impact. Typical flow:
1.detect/log incident
2.categorize + assign priority (impact × urgency)
3.initial diagnosis + workaround
4.escalation (functional / hierarchical)
5.resolution + recovery
6.closure + user confirmation
Key metrics: MTTR, SLA compliance, reopen rate, incident volume
Computing Department
15

16. Incident priority matrix

• Priority often = Impact × Urgency.
Example:
• High impact + high urgency → P1 (major incident)
• Medium impact + high urgency → P2
• Low impact + low urgency → P4
Rules:
• define impact levels (single user / department / whole company)
• define urgency (time sensitivity, deadlines)
• automate escalations based on priority
Computing Department
16

17. Major Incident Management

When P1/P0 happens:
• activate war-room / incident commander
• frequent stakeholder updates (every X minutes)
• isolate blast radius, rollback if needed
• focus on restoration first, root cause later
Outputs:
• timeline, decisions, actions, communications log
• post-incident review + follow-up problem record
Computing Department
17

18. Problem Management

Goal: prevent incidents from recurring and reduce impact
Key activities:
• trend analysis (repeat incidents)
• root cause analysis (RCA)
• known error record + workaround
• permanent fix proposal (often via change)
• Typical RCA tools: 5 Whys, fishbone, fault tree
Metrics: repeat incident reduction, time to identify root cause
Computing Department
18

19. Change Management

• Goal: implement changes with controlled risk
Typical flow:
1.RFC raised (what/why/impact/backout plan)
2.assessment (risk, impact, testing, security)
3.approval (CAB or automated policy)
4.scheduling (change calendar, blackout windows)
5.implementation + validation
6.closure + documentation update
Computing Department
19

20. Change types

• Standard change: pre-approved, low-risk, repeatable (e.g., user onboarding)
• Normal change: assessed + approved each time (most changes)
• Emergency change: urgent fix to restore service; approval is fast but tracked
Rule: emergency change still requires documentation and a post-review.
Computing Department
20

21. Configuration Management (CMDB) basics

Stores “configuration items” (CIs) and relationships, e.g.:
• servers, VMs, network devices
• applications and modules
• databases, integrations
• business services (“Online Payments Service”)
Why it matters: impact analysis, faster incident resolution, safer changes
Computing Department
21

22. Inventory & Asset Management

Inventory & Asset Management
• Asset management: financial/legal ownership (purchase date, warranty, cost center)
• Inventory management: what you physically/logically have (stock, assignments)
• Configuration management: how components connect and affect services
(relationships)
Computing Department
22

23. Knowledge repository

• Purpose: reduce repeated questions and speed up resolution
Knowledge base contains:
• FAQs (password reset, VPN issues)
• troubleshooting guides + runbooks
• known errors and workarounds
• onboarding guides and policies
Good knowledge article structure: symptoms → cause → steps → validation → escalation
path
Computing Department
23

24. Service catalog

Service catalog = list of available IT services with:
• description and eligibility
• request forms + approval rules
• pricing/chargeback (if used)
• delivery time expectations
Examples: “New email account”, “Laptop request”, “Access to ERP module”
Computing Department
24

25. Service Level Management

SLA = agreement on service targets
Process steps:
1.identify service and customers
2.define measurable targets (availability, response time, MTTR)
3.negotiate + sign SLA/OLA (internal agreements)
4.monitor + report performance
5.review + improve
Computing Department
25

26. SLA / SLO / KPI

• KPI: any measure (e.g., number of incidents/week)
• SLO: target objective (e.g., 99.9% availability monthly)
• SLA: formal agreement + consequences/escalations
Also: OLA (Operational Level Agreement) between internal teams.
Computing Department
26

27. Workflow automation + dashboards

ITSM tools automate:
• routing tickets by category, CI, location, VIP user
• approvals for access and changes
• SLA timers + escalations
• notifications (email/Teams/Slack)
Dashboards show:
• SLA compliance, backlog, aging, MTTR
• top incident categories, problem trends
• change success rate, emergency change count
Computing Department
27

28. Example ITSM tools

Common tools used in organizations:
• ServiceNow ITSM
• Jira Service Management
• BMC Helix / Remedy
• Freshservice (Freshworks)
• ManageEngine ServiceDesk Plus
• Ivanti Neurons (Cherwell legacy)
• Zendesk (service desk focus)
• GLPI (open-source), OTRS / Znuny (ticketing)
Computing Department
28

29. How to select an ITSM tool

Selection criteria checklist:
• process support: incident/problem/change/catalog/SLA/CMDB
• integrations: email, AD/SSO, monitoring tools, asset discovery
• reporting maturity + API availability
• automation/low-code workflows
• security/compliance (audit logs, role-based access)
• total cost of ownership: licenses + implementation + admin effort
Computing Department
29

30. Overall IT service framework / control model

• A simple management control loop for IT services:
Planning → Budgeting → Accounting → Reporting → (back to planning)
Meaning:
• plan services + targets
• allocate budget to deliver targets
• track actual spending and usage
• report cost + performance + value
• adjust plan and investments
Computing Department
30

31. What good planning includes

Planning for IT services should include:
• service portfolio (what services exist and why)
• capacity and availability planning (growth, peak load)
• security and risk planning
• continuity / disaster recovery expectations
• staffing model and support hours
• KPI + SLA targets (measurable)
Computing Department
31

32. How services get funded

Common budgeting approaches:
• Cost center: IT as overhead
• Chargeback: business units pay for consumption
• Showback: costs are visible but not charged
Budget elements:
• people (support, on-call)
• tools/licenses
• infrastructure (cloud/on-prem)
• vendors/outsourcing
• continuous improvement projects
Computing Department
32

33. Tracking service costs

Accounting in IT service context means:
• tracking actual cost per service (labor + tools + infra)
• allocating shared costs (network, security tools)
• mapping incidents/changes to cost drivers
• identifying high-cost failure patterns (repeat incidents)
Outputs: cost per ticket, cost per service, cost per downtime hour
Computing Department
33

34. What executives want to see

Good reporting combines:
• Service performance: availability, MTTR, SLA compliance
• Operational health: backlog, aging, repeat incidents, change success rate
• Financial: cost vs budget, cost per service, ROI signals
• Risk/compliance: audit issues, high-risk changes, vulnerabilities
• Customer view: CSAT, complaint themes, NPS (if used)
Computing Department
34

35. What executives want to see

Good reporting combines:
• Service performance: availability, MTTR, SLA compliance
• Operational health: backlog, aging, repeat incidents, change success rate
• Financial: cost vs budget, cost per service, ROI signals
• Risk/compliance: audit issues, high-risk changes, vulnerabilities
• Customer view: CSAT, complaint themes, NPS (if used)
Computing Department
35

36. Service delivery gaps model (why users feel “bad service”)

A classic gap logic to diagnose service failures:
1.
2.
3.
4.
5.
Expectation gap: users expect X, IT misunderstands
Specification gap: IT knows expectation, but designs wrong SLAs/process
Delivery gap: specs exist, but operations fail (skills/tools/overload)
Communication gap: IT communicates promises incorrectly (or not at all)
Perceived service gap: overall difference between expected vs experienced
Computing Department
36

37. Gap examples

• Expectation gap: users think support is 24/7, IT is 9–6
• Specification gap: SLA says “respond in 1 hour” but no on-call staffing
• Delivery gap: change process exists, but teams bypass it → outages
• Communication gap: “system upgrade will not impact” but it does
• Perceived gap: service is improving, but users never see transparent reports
Computing Department
37

38. Benefits management: core idea

Benefit = measurable improvement enabled by IS
Not “we installed a tool” — benefits must be:
• specific (what improves?)
• measurable (how measured?)
• owned (who is responsible?)
• time-bound (by when?)
• evidenced (where is proof?)
Computing Department
38

39. outputs → outcomes → benefits

• Output: what you deliver (system feature, dashboard, automation)
• Outcome: change in behavior/process (faster approvals, fewer errors)
• Benefit: measurable improvement (cost down, revenue up, risk reduced)
Example:
• Output: automated onboarding workflow
• Outcome: HR + IT steps standardized
• Benefit: onboarding time reduced from 5 days to 1 day (measured)
Computing Department
39

40. Benefit register

• Benefit statement (what improves, for whom)
• KPI baseline (current)
• KPI target (future)
• Owner (accountable person)
• Target date (when benefit must be achieved)
• Dependencies (tech/process/people)
• Risks (what may block benefit)
• Evidence source (system logs, finance reports, surveys, audits)
Computing Department
40

41. Benefit statement examples

Weak: “Improve service quality.”
Good:
• “Reduce incident MTTR for ERP from 6 hours to 2 hours by June 2026.”
• “Increase service availability for student portal from 99.0% to 99.8% by Q3 2026.”
• “Reduce password reset tickets by 40% through self-service by May 2026.”
Computing Department
41

42. Linking benefits to objectives + service KPIs

Benefits should connect to:
Operational objectives
• efficiency: cycle time, cost per transaction, automation rate
• effectiveness: quality, accuracy, customer satisfaction, compliance
Service KPIs
• availability (% uptime)
• incident rate (incidents per 100 users / per month)
• MTTR / MTTA
• change failure rate
• request fulfilment cycle time
Computing Department
42

43. Example: benefit mapping table

Example mapping (ERP support improvement):
• Objective: reduce business downtime
• Service KPI: availability, MTTR, P1 count/month
• Benefit: MTTR ↓ from 6h → 2h
• Dependencies: monitoring + on-call + runbooks + CMDB accuracy
• Evidence: monitoring reports + incident timestamps + postmortems
Computing Department
43

44. Measuring benefits: baseline, target, evidence

Rules:
• baseline must be measured the same way as target
• pick a realistic measurement period (weekly/monthly/quarterly)
• define data source once (ITSM tool, monitoring tool, finance system)
• define who validates (service owner, finance, audit, product owner)
Computing Department
44