INFO6007 Week 12 IT 服务管理与流程（二）讲课总结
INFO6007 Week 12 讲课总结：IT Service Management and Processes 2
课程：INFO6007 — Project Management in IT，Semester 2 2026 来源：讲义 PDF + tutorial sheet（无转录稿） -
Lecture - INFO6007 Week 12 - ITSM and processes 2.pdf（59 页） -Tutorial sheet INFO6007 Week 12（本周 answer sheet 未发布/未下载） -Tutorial sheet INFO6007 Week 13（Week 13 的情景练习，一并整理在本文）本讲接着 Week 11，把 ITIL 4 的六个关键组件讲完：治理 → 服务价值链（SVC）→ 实践（事件、问题、变更、SLM、服务台、持续改进）→ 持续改进模型，再讲 工具（ServiceNow）、AI、采用挑战、趋势，最后回到本课主线：项目管理与 ITSM 如何衔接。
⚠️ 第九、十章的 tutorial 答案均为笔者自拟的参考答案（Week 12、13 都没有官方 answer sheet），依据是本讲和 Week 11 讲义，请按需取舍。
📝 考试相关：Practice Exam Q4(c)（服务级别管理：可衡量目标 + 监控与评审）；Question Bank Q27（SVC 活动、SVS）、Q28（可用性计算、SLM、知识管理与持续改进）。
一、ITIL 4 关键组件回顾
| # | 组件 | 本讲内容 |
|---|---|---|
| 1 | Service Value System (SVS) | 核心模型，确保所有组件和活动协同创造价值 |
| 2 | Guiding Principles | 七条（Week 11） |
| 3 | Governance | 第二章 |
| 4 | Service Value Chain (SVC) | 第三章 |
| 5 | Practices | 第四、五章 |
| 6 | Continual Improvement | 第六章 |
SVS 中各组件的定位： - Guiding Principles：普遍适用的建议 - Governance：确保政策、权限和问责到位，为 IT 服务交付提供方向和控制 - Service Value Chain：SVS 的运营核心，把需求转化为价值的活动 - Practices：34 个管理实践（一般、服务、技术） - Continual Improvement：确保服务、实践和流程随业务需求演进
二、治理（Governance）
组织被指导和控制的方式；确保与组织目标一致并合规。
| 方面 | 内容 |
|---|---|
| 组成 | 政策、程序、控制 |
| 例子 | 治理框架、合规审计 |
| 治理机构的职责 | 设定方向、监控绩效、确保合规 |
| 治理机构的结构 | 董事会、委员会、监督职能 |
| 治理活动 | 政策制定、风险管理、绩效监控 |
治理在 SVS 中的作用
- 服务价值链和组织的实践按治理机构给出的方向运作
- 治理机构直接或通过授权保持对 SVS 的监督
- 治理机构和各层级管理层通过一套清晰的共同原则和目标保持一致
- 治理和管理本身也要持续改进，以满足干系人期望
与 Week 9 的区别：Week 9 讲的是项目治理（指导委员会、PMO、发起人、阶段关口）；这里是组织层面对服务管理的治理（董事会设方向、管理层执行）。两者逻辑相同：谁有权决定什么、如何监督、如何问责。
三、服务价值链（Service Value Chain，必考）
SVC 是组织为与客户共创价值而进行的一组相互关联的活动。
六项活动
| 活动 | 作用 | 关键词 |
|---|---|---|
| Plan | 对齐愿景、战略和持续改进举措 | 方向 |
| Improve | 识别并实施服务、实践或流程的改进 | 改进 |
| Engage | 与干系人互动，了解需求、期望和反馈 | 对外接口 |
| Design & Transition | 构建、修改新的或变更的服务，并转入生产使用 | 设计与上线 |
| Obtain / Build | 获取或构建服务交付所需的组件 | 采购与开发 |
| Deliver & Support | 运行服务并提供持续支持 | 日常运营 |
记忆：「P-I-E-D-O-D」——Plan, Improve, Engage, Design & Transition, Obtain/Build, Deliver & Support。 Engage 是与客户、用户等干系人互动的主要接口；而与供应商谈判和签订合同属于 Engage 与 Obtain/Build 的交界（ITIL Foundation 的高频辨析题，讲义未展开）。 SVC 的活动不是线性顺序，而是根据具体价值流灵活组合。
讲义例子：大学 IT 服务台
需求来自学生、学者和行政人员需要 IT 支持；价值在需求被有效解决时产生（登录问题 → 恢复访问；Wi-Fi 问题 → 继续学习工作；软件请求 → 拿到工具；Canvas 问题 → 教学顺利进行；设备与打印 → 日常事务少受干扰）。
| SVC 活动 | 服务台的具体做法 |
|---|---|
| Engage | 接收工单、接听电话和邮件、在线聊天、收集用户信息、澄清问题 |
| Plan | 人员排班、服务时间、优先级等级、升级规则、支持目标和响应时间 |
| Design & Transition | 创建支持流程、设计工单分类、准备知识库文章、引入新支持工具、变更上线前培训员工 |
| Obtain / Build | 工单系统、知识库、远程支持工具、FAQ 页面、支持模板和工作流 |
| Deliver & Support | 排查问题、重置密码、升级复杂问题、向用户更新工单进度、关闭已解决工单 |
| Improve | 复盘工单趋势、减少重复问题、更新 FAQ、改善响应时间、利用师生反馈 |
产品与服务：账户支持、网络支持、软件访问、学习系统支持、设备与打印支持。 价值：更快解决问题、更好的用户体验、减少停机、对 IT 服务更有信心、更有效的教学支持。
SVS vs SVC（Menti 题）
| SVS（服务价值系统） | SVC（服务价值链） | |
|---|---|---|
| 范围 | 整个系统：指导原则 + 治理 + SVC + 实践 + 持续改进 | SVS 的一个组件：六项运营活动 |
| 回答 | 组织整体上如何把机会/需求变成价值 | 具体运营上做哪些活动来创造价值 |
| 比喻 | 整个工厂（含管理制度、文化、规则） | 工厂里的生产线 |
📝 Question Bank Q27.3（预订系统重复预订，只换技术可能不够）：用 SVS 解释——换技术只动了 Obtain/Build 和「信息与技术」维度；如果预订流程（价值流与流程）、员工做法（组织与人）和治理（谁对预订规则负责）不变，问题会照旧。应由治理设方向和问责 → 实践（服务请求管理、知识管理）提供能力 → SVC 各活动协同（Engage 收集客户反馈、Design & Transition 改流程、Improve 复盘）。
四、ITIL 4 的 34 个实践
Practice（实践）：一组为完成特定工作或达成特定目标而设计的组织资源（人、流程、信息、工具、合作伙伴）。
- ITIL 4 的实践提供灵活性和适应性——组织按自身情境取用相关部分，而不是遵循僵化的分步流程
- 支撑 SVC 的活动（Plan、Design & Transition、Obtain/Build、Deliver & Support、Improve）
为什么实践重要：灵活（适用于 Agile、DevOps 或传统环境）；通过人、流程、技术实现整体改进；鼓励整合而非孤立的流程管理；促进各层级的持续改进。
三类实践
| 类别 | 数量 | 来源 | 例子 |
|---|---|---|---|
| General Management Practices | 14 | 来自一般业务管理学科，支撑整体服务管理和治理 | 持续改进、信息安全管理、风险管理、知识管理、项目管理、架构管理、关系管理、人员与人才管理 |
| Service Management Practices | 17 | ITSM 特有，是价值共创的关键 | 事件管理、问题管理、变更实施、服务请求管理、服务级别管理、服务台、IT 资产管理、服务配置管理、发布管理、可用性/容量/服务连续性管理 |
| Technical Management Practices | 3 | 交付 IT 服务的技术方面 | 部署管理、基础设施与平台管理、软件开发与管理 |
。注意 Project Management 本身是 ITIL 的一个一般管理实践——这也是 PM 与 ITSM 衔接的一个点。 易错：Deployment Management（技术）≠ Release Management（服务）≠ Change Enablement（服务）。
讲义点名的最重要的服务实践：事件管理、问题管理、变更管理、服务请求管理、服务台、服务级别管理、知识管理（其实属一般管理实践）、服务连续性管理。
五、关键服务实践
1. Incident Management（事件管理）
在非计划中断后尽快恢复正常服务运行，同时将对业务运营的影响降到最低。
关键活动：
| 步骤 | 做法 |
|---|---|
| Identification | 通过服务台、监控工具或用户发现或报告事件 |
| Logging | 在 ITSM 工具中记录事件详情，以便跟踪和分析 |
| Categorisation & Prioritisation | 赋予类型、严重程度和紧急程度，优先处理高影响事件 |
| Investigation & Diagnosis | 确定根因或变通方案（workaround） |
| Resolution & Recovery | 应用解决方案或变通方案恢复服务 |
| Closure | 确认服务已恢复，正式关闭 |
| Continual Improvement | 分析趋势以防止再发 |
优先级通常由影响（Impact）× 紧急度（Urgency）决定——和 Week 7 的概率影响矩阵是同一思路：
影响 ↓ / 紧急度 → 高 中 低 高 P1 P2 P3 中 P2 P3 P4 低 P3 P4 P5 （常见的业界矩阵，讲义未给具体表格）
2. Problem Management（问题管理）
识别、分析和管理事件的根本原因，以防止再次发生并降低未来事件的影响。
| 步骤 | 做法 |
|---|---|
| Problem Detection | 从重复事件、重大事件或主动趋势分析中识别问题 |
| Logging | 记录问题详情、影响和受影响服务 |
| Categorisation & Prioritisation | 按紧急度和影响排序 |
| Investigation & Diagnosis | 用 RCA（根因分析）等工具确定根因 |
| Workarounds | 提供临时方案降低事件影响 |
| Known Error Record | 记录问题和变通方案供参考（「已知错误」） |
| Resolution & Closure | 实施永久修复并验证有效性 |
| Continual Improvement | 复盘趋势防止未来问题 |
Incident vs Problem（最高频考点）
| Incident（事件） | Problem（问题） | |
|---|---|---|
| 定义 | 非计划的服务中断或质量下降 | 一个或多个事件的根本原因（或潜在原因） |
| 目标 | 尽快恢复服务 | 找到并消除根因，防止再发 |
| 时间性 | 反应式、紧急 | 可主动、可在事后从容进行 |
| 典型产出 | 服务恢复（可能靠变通方案） | 已知错误记录、永久修复（通常经变更实施） |
| 大学例子 | 「我今天登不上 Canvas」 | 「每到考试周，认证服务器连接池耗尽 → 大量登录失败」 |
一句话：事件管理灭火，问题管理防火。 一个问题可以引发很多事件；事件关闭了，问题可能还开着。 变通方案（workaround）连接两者：问题管理找到的临时方案记录为已知错误，供事件管理快速恢复服务。
3. Change Enablement（变更实施）
确保对服务、系统或基础设施的变更经过评估、批准，并以最小风险和干扰实施。
| 步骤 | 做法 |
|---|---|
| Request for Change (RFC) | 正式记录所有提出的变更 |
| Assessment & Approval | 评估风险、影响、资源和业务一致性；批准或拒绝 |
| Change Planning | 排期和协调实施 |
| Implementation | 按计划实施 |
| Review & Close | 验证成功、记录结果、更新记录 |
| Emergency Changes | 针对紧急、高优先级变更的快速通道 |
ITIL 4 Foundation 还区分三种变更：Standard（预授权、低风险、例行）、Normal（需评估和授权）、Emergency（尽快实施，加速授权）——讲义只提了 Emergency，答题时可补充。
与 Week 10 的对应：项目中的整合变更控制 / CCB ↔︎ 运营中的变更实施 / 变更授权。项目交付的东西上线时，必须遵守 ITSM 的变更流程（第八章）。
4. Service Level Management（服务级别管理，SLM）
定义、商定、监控和报告 IT 服务的绩效，确保其满足约定的业务要求和期望。
| 步骤 | 做法 |
|---|---|
| Define SLAs | 商定可衡量的服务目标（可用性、响应时间、解决时间） |
| Negotiate & Agree | 让服务承诺与业务需求对齐 |
| Monitor & Report | 对照 SLA 跟踪绩效，突出违约 |
| Review & Improve | 定期服务评审，实施改进 |
| Coordinate | 与事件、问题、变更和服务台实践协作维持服务水平 |
可用性计算（Question Bank Q28 题型）
Q28：30 天 = 720 小时，非计划停机 6 小时，SLA 要求 ≥ 99.5%。
未达标（99.17% < 99.5%）。99.5% 允许的最大停机：
实际停机 6 小时，超出 2.4 小时。
Q28.2「可用性应作为主要衡量指标」——评价：可用性只反映「能不能访问」（warranty 的一部分），不反映研究人员真正关心的成果。案例中系统基本可访问，但任务在队列里等好几小时、找不到提交说明、支持答复不一致——这些可用性都测不出来。建议补充的可衡量目标： - 任务排队时间：95% 的任务在提交后 30 分钟内开始处理 - 支持质量：首次联系解决率 ≥ 80%，或用户满意度 ≥ 4/5
监控与评审：ITSM 工具自动采集指标 → 月度服务报告 → 与研究团队代表的季度服务评审会 → 对违约项做根因分析并纳入改进计划。
Q28.3（知识管理 + 持续改进，先于大规模基础设施投资）：① 知识管理：编写标准化的任务提交指南和知识库，统一支持人员口径；② 持续改进：分析调度器日志找出排队瓶颈，先优化调度策略（Start where you are / Optimise then automate）。用改进前后的排队时间、提交错误率、工单量和满意度对比来评估效果，再决定是否买算力。
Practice Exam Q4(c) 示范答案（「可靠且响应快」→ 可衡量目标）
| 目标 | 假设 | 与门店运营的关系 |
|---|---|---|
| 可用性 ≥ 99.9%（营业时间内，按月计） | 门店营业 8:00–22:00；计划维护安排在营业时间外且不计入 | 系统不可用 → 门店无法查库存、补货建议中断 |
| 95% 的库存查询在 2 秒内返回；库存数据与 POS 同步延迟 ≤ 5 分钟 | 高峰期并发为数百家门店同时访问 | 「实时」库存才能支撑补货和销售决策 |
监控与评审：服务商用监控工具自动采集指标并生成月度 SLA 报告；双方举行月度/季度服务评审会，复盘违约、事件趋势和改进行动；违约触发服务补偿（service credits）或改进计划；业务变化时重新协商目标。
5. Service Desk（服务台）
用户与 IT 组织之间的单一联系点（SPOC, Single Point of Contact），负责处理事件、服务请求和与用户的沟通。
关键活动：事件记录；服务请求履行（重置密码、开通访问等标准请求）；事件解决或升级到更高层支持；沟通（告知用户状态和预计解决时间）；监控与报告（工单、SLA、绩效指标）；知识管理（更新知识库以改善自助服务）。
Incident vs Service Request：事件是「坏了」（非计划中断）；服务请求是「要东西」（用户请求预定义的、正常的服务行动，如密码重置、软件安装、权限申请）。
6. Continual Improvement（作为实践）
通过在各层级识别并实施改进，让组织的服务、实践和流程与不断变化的业务需求保持一致。
关键活动：识别改进机会（来自事件、问题、反馈、KPI、审计）→ 评估与排序（按影响和价值）→ 规划与实施 → 衡量与复审 → 整合改进（把经验教训应用到实践、流程、服务和价值流）。
六、持续改进模型
一种在各层级反复进行的组织活动，确保组织绩效持续满足干系人期望；嵌入在 SVS 的所有组件和活动中。
七步模型（必背）
| # | 问题 | 做什么 |
|---|---|---|
| 1 | What is the vision? | 明确业务愿景、使命、目标 |
| 2 | Where are we now? | 做基线评估（baseline assessment） |
| 3 | Where do we want to be? | 定义可衡量的目标 |
| 4 | How do we get there? | 制定改进计划 |
| 5 | Take action | 执行改进行动 |
| 6 | Did we get there? | 评估指标和 KPI |
| 7 | How do we keep the momentum going? | 固化成果，回到第 1 步 |
与其他周的呼应：第 2 步「我们现在在哪」= 指导原则 Start where you are；整个循环 ≈ Week 5 的 PDCA（Plan = 1–4，Do = 5，Check = 6，Act = 7）。
ITIL 的价值主张
| 高绩效服务提供方的特征 | 战略能力 | 服务管理实践的系统化使用 | 与客户的信任伙伴关系 |
|---|---|---|---|
| 一致可靠的服务交付；与业务目标高度一致 | 主动的服务管理；预判客户需求 | 标准化流程和方法；持续改进和优化 | 建立长期关系；风险与收益共担 |
价值流（Value Streams）
组织为向干系人创造和交付有价值的产品或服务而采取的一系列步骤。
- 价值流针对具体成果（如「学生入学」「处理一个 LMS 请求」）
- 把 SVC 活动和实践整合成高效的工作流
- 每一步都应贡献价值、避免浪费、优化资源
- 意义：让 IT 和组织所有部分都对准价值创造；连接战略、运营和客户成果
七、工具、AI、挑战与趋势
ServiceNow
基于云的 ITSM 平台，自动化、管理和整合整个企业的 IT 服务，广泛用于落地 ITIL 实践。核心能力：事件管理、问题管理、变更管理/变更实施、服务请求管理（自动化密码重置、软件访问）、报告与仪表盘（监控 SLA 合规、事件和绩效指标）。
自动化与 AI 在 ITSM 中的作用
| 领域 | 影响 |
|---|---|
| Incident Management | 自动把工单路由到正确团队；AI 诊断给出可能原因或方案；聊天机器人/自助门户即时解决常见问题 |
| Problem Management | AI 分析事件趋势发现重复问题；预测性分析在影响服务前识别风险 |
| Change Enablement | 用预定义工作流自动处理例行变更；AI 评估风险、影响和依赖以辅助审批 |
| Service Request Management | 用户通过门户提交，自动化工作流快速履行；减少人工审批和重复工作 |
| Monitoring & Event Management | AI 监控系统性能、异常时触发告警；预测性维护在宕机前预防 |
ITIL 采用的三大挑战
| 挑战 | 说明 |
|---|---|
| 文化与组织阻力 | 员工抵制新流程、角色和职责；需要从被动转向主动的服务管理 |
| 复杂度与范围 | 34 个实践 + 多个组件 → 试图一次全部实施会压垮团队，应聚焦价值流 |
| 缺乏高层支持 | 没有领导承诺、资金和治理，ITIL 举措会停滞或失败 |
三个挑战分别对应前面各周：文化阻力 → Week 10 变革管理；一次全做 → 指导原则 Progress iteratively / Keep it simple；高层支持 → Week 9 治理、Chaos Report 的成功因素第二名。
当前趋势
- GRC（治理、风险与合规）整合进 ITSM 工具
- 生成式 AI：增强自动化、改善决策、个性化用户体验
- 高级 ITSM 能力：超越基础实践，追求更高灵活性和效率
- 价值证明（Value Demonstration）：越来越强调向干系人证明 ITSM 的价值
ITIL 认证路径
Foundation（入门）→ Practitioner（如何在组织中采用和调整 ITIL）→ Intermediate（Service Lifecycle 与 Service Capability）→ Expert → Master（最高级）。
八、项目管理与 ITSM 的衔接（全课收束点）
| IT Project Management | ITSM | |
|---|---|---|
| 性质 | 临时性举措，交付特定产出 | 持续交付和支持 IT 服务 |
| 例子 | 新软件、系统升级 | 持续创造价值 |
四个衔接点：
| 衔接点 | 说明 |
|---|---|
| Project to Service Transition | 项目常常创建或修改 IT 服务；ITSM 确保这些服务在项目结束后被运营、维护和支持 |
| Shared Processes and Practices | 两者都用变更管理、配置管理和知识管理；项目必须遵守 ITSM 政策，确保部署顺利、干扰最小 |
| Value continuity | 项目成功看交付产出（outputs），ITSM 成功看交付成果和价值（outcomes & value）；把两者连接起来才能让项目产出产生持久业务价值 |
| Feedback Loop | ITSM 把绩效数据和经验教训反馈给项目，让未来项目更贴合运营需求 |
💡 这一页是整门课的总结：Week 1–10 教你把项目做完，Week 11–12 告诉你「做完」只是价值的起点。Question Bank Q3（项目 A 按时按预算但只有 20% 用户采用；项目 B 超支延期但处理时间减半）考的就是这个——三重约束是产出视角，收益实现和干系人满意是成果视角。
九、课后案例：UniTech 大学 LMS 升级（讲义题，参考答案自拟）
升级 LMS，新增认证模块和在线考试监考。上线中：高峰期学生登录失败；服务台被工单淹没；部分事件在临时修复后仍反复出现；一个关键变更未经完整影响评估就部署，导致部分停机；IT 管理层希望展示价值并与 SLA 对齐。
| 问题 | 参考要点 |
|---|---|
| 识别事件与问题 | 事件：单个学生登录失败、部分停机、每张工单；问题：高峰期登录失败的共同根因（如新认证模块容量不足）、临时修复后仍复发说明根因未除 |
| 如何处理重复的登录失败 | 事件管理用变通方案快速恢复；问题管理把重复事件立为问题 → RCA（如负载测试、日志分析）→ 已知错误记录 + 变通方案发布到知识库 → 通过变更实施部署永久修复 |
| 变更实施如何避免停机 | RFC + 影响和风险评估（含高峰时段）+ 审批；在低峰时段按计划实施；回滚计划；测试环境先验证；部署后复审 |
| 服务台在升级中的角色 | 单一联系点；事前获得培训和知识库文章（Design & Transition）；上线时主动发布状态通告减少重复来电；对工单分类、关联到同一问题；向用户及时更新 |
| 持续改进计划 | 按七步模型：愿景（考试期间 LMS 稳定）→ 基线（登录失败率、工单量、MTTR）→ 目标（如高峰登录成功率 ≥ 99.5%）→ 计划 → 实施 → 衡量 → 固化 |
| 登录问题的价值流 | 学生报告（Engage）→ 服务台记录/分类/优先级（Deliver & Support）→ 二线诊断、变通方案 → 问题管理 RCA → 变更实施部署修复（Design & Transition / Obtain/Build）→ 服务恢复并通知学生 → 复盘（Improve） |
| 让项目产出产生长期价值 | 上线前与服务管理正式移交（运维文档、SLA、支持培训）；上线后跟踪成果指标（登录成功率、满意度）而不只是「上线了」 |
十、Tutorial（Week 12）：ITSM 讨论与 LMS 案例（参考答案自拟）
⚠️ Week 12 没有官方 answer sheet（Canvas 索引显示「Tutorial answer sheet week 12」处于锁定、未下载状态）。以下为依据讲义自拟的参考答案。本周 tutorial 是 Week 11 内容 + 本周事件/问题管理的练习，另有 SET 问卷。
Part A：讨论
① 为什么 ITSM 对大学或银行至关重要？
| 维度 | 大学 | 银行 |
|---|---|---|
| 业务依赖 | 教学、考试、科研完全依赖 LMS、门户、Wi-Fi | 网银、ATM、支付7×24 不能停 |
| 用户规模与峰值 | 数万学生，选课周、考试周集中访问 | 发薪日、月末交易高峰 |
| 合规与风险 | 学生隐私、学术诚信 | 金融监管、数据安全、审计 |
| ITSM 提供什么 | 可预测的服务水平（SLA）、标准化的事件/变更流程降低停机、持续改进、可审计的控制 | 同左，且对变更风险和服务连续性要求更高 |
② IT 项目管理与 ITSM 有何不同、在哪里重叠？ - 不同：项目临时、交付独特产出、看三重约束；ITSM 持续、维护与优化运行中的服务、看 SLA 和成果（见 Week 11 对照表） - 重叠：项目到服务的移交（Design & Transition）；共享的变更、配置、知识管理；ITSM 把运营反馈给新项目；Project Management 本身就是 ITIL 的一般管理实践
③ 校园里的服务关系模型
| 模型 | 校园例子 |
|---|---|
| B2C（大学作为服务提供方 → 学生） | LMS、学生门户、校园 Wi-Fi、IT 服务台 |
| B2B | 大学与 Microsoft 365 / Canvas（Instructure）/ AWS 等供应商 |
| B2E | 面向教职员工的 HR、薪资、协作系统 |
| B2G / G2B | 大学向政府报送学生数据；政府向大学提供拨款、签证（CoE）等系统 |
| C2C | 学生之间的二手教材、租房平台、学习小组论坛 |
| G2C | 学生使用 myGov、USI、Service NSW 等政府服务 |
Part B：LMS 考试周无法访问
学生在考试周无法访问 LMS；事件被报到服务台；部分问题反复出现；IT 人员不确定根因。
① 区分事件与问题
| 类型 | 本情景中的例子 |
|---|---|
| Incident | 每一个「我登不上 LMS」的报告；某次页面超时；某门考试无法提交 |
| Problem | 「考试周反复出现无法访问」这一现象背后的未知根因（可能是容量不足、认证服务瓶颈、某次变更引入的缺陷）——因为反复出现且根因不明，必须作为问题立项 |
② 立即缓解的变通方案（workarounds） - 临时扩容（增加应用服务器/云实例）、重启故障节点 - 分流：错峰安排考试开始时间，或开放备用访问入口 - 对受影响学生延长提交时限、允许邮件提交作为后备 - 在状态页和服务台脚本中发布统一通告，减少重复工单 - 把已知的绕过方法（如清除缓存、用另一认证入口）写进知识库
③ 用问题管理实践找永久修复 1. 问题检测：把考试周的重复事件关联为一个问题记录 2. 记录与排序：考试周 → 高影响 + 高紧急 3. 调查与诊断（RCA）：查看监控和日志、按时间线对比最近的变更、做负载测试复现；可用 5 Whys 或鱼骨图 4. 变通方案 + 已知错误记录：先把临时方案记录下来供服务台使用 5. 永久修复：例如容量规划与自动扩缩、优化认证/数据库瓶颈、修复缺陷——通过变更实施（RFC、评估、审批、在低峰期部署、回滚计划）上线 6. 验证与关闭：下一个高峰期确认不再复发 7. 持续改进：把考试周前的容量评估和负载测试固化为标准流程
④ LMS 事件管理工作流（标注工具、角色、产出）
| 步骤 | 角色 | 工具 | 产出 |
|---|---|---|---|
| 用户报告 | 学生/讲师 | 自助门户、电话、邮件、聊天机器人 | 原始报告 |
| 服务台 | 一线服务台人员（SPOC） | ITSM 工具（如 ServiceNow） | 事件工单（记录详情） |
| 分类 | 服务台 | ITSM 工具 + 优先级矩阵（影响 × 紧急度） | 类别、优先级（考试周 = P1/P2） |
| 指派 | 服务台 / 事件经理 | 自动路由规则 | 指派给 LMS 应用组/基础设施组 |
| 解决 | 二线/三线支持 | 监控工具、日志、知识库 | 服务恢复（修复或变通方案）；如为重复事件 → 关联到问题记录 |
| 关闭 | 服务台 | ITSM 工具、满意度调查 | 与用户确认后关闭；工单记录完整 |
| 持续改进 | 事件经理 / 问题经理 / 服务负责人 | 报表、仪表盘 | 趋势分析、新的问题记录、知识库更新、SLA 报告 |
学生报告 → 服务台记录 → 分类与定优先级 → 指派二线 → 诊断 / 变通方案 → 恢复服务 → 确认并关闭 |
十一、Tutorial（Week 13）：Wi-Fi 服务的价值链映射（参考答案自拟）
Week 13 tutorial 前半段是模拟考试（导师投屏一道题，2 分钟阅读 + 30 分钟作答，用打印的 Model Answer Sheet、可带 cheat sheet 和计算器）；后半段是下面这道情景练习。没有官方答案，以下为自拟参考。
情景：大学 IT 部门向 ITIL 4 转型。近期学生 Wi-Fi 问题频发：登录失败、频繁掉线。CIO 希望按服务价值链重新设计流程。
① 六项 SVC 活动在本情景中的应用（含角色、工具、产出）
| 活动 | 在 Wi-Fi 情景中做什么 | 角色 | 工具 | 产出 |
|---|---|---|---|---|
| Plan | 确定 Wi-Fi 服务目标（如认证成功率、覆盖率）、容量与预算规划、定义优先级和升级规则 | CIO、服务负责人、网络架构师 | 战略/路线图、容量规划工具 | Wi-Fi 服务计划、SLA 目标、改进路线图 |
| Improve | 分析事件和问题趋势、满意度数据，确定改进优先级 | 持续改进经理、服务负责人 | 仪表盘、报表、调查 | 改进登记册（如「认证服务器扩容」「AP 布点调整」） |
| Engage | 收集学生/教职工报告和反馈，主动通告故障与维护 | 服务台、学生代表、沟通团队 | ITSM 门户、聊天机器人、状态页、问卷 | 工单、需求、反馈 |
| Design & Transition | 设计新的认证流程/网络配置，测试并按变更流程上线，培训服务台、更新知识库 | 网络工程师、变更经理、服务台主管 | 测试环境、变更日历、知识库 | 已批准并上线的变更、新的 KB 文章 |
| Obtain / Build | 采购或构建所需组件：新 AP、认证服务器容量、监控工具、供应商合同 | 采购、网络团队、供应商 | 采购系统、配置管理库（CMDB） | 硬件/软件/合同到位 |
| Deliver & Support | 日常运行 Wi-Fi，处理事件和服务请求，恢复连接 | 服务台、一线/二线网络支持 | 网络监控、ITSM 工具 | 恢复的服务、关闭的工单、SLA 数据 |
② 四个实践如何协同解决问题
| 实践 | 在本情景中的作用 | 与其他实践的衔接 |
|---|---|---|
| Incident Management——快速恢复连接 | 服务台记录、按影响定优先级（如整栋教学楼断网 = 高）、二线用变通方案恢复（重启 AP、切换备用认证服务器、引导学生用访客网络） | 重复事件 → 交给问题管理 |
| Problem Management——识别反复出现的认证问题 | 关联登录失败事件，RCA（如 RADIUS 服务器在上课高峰过载、证书过期、DHCP 地址池耗尽）；记录已知错误 + 变通方案供事件管理使用 | 永久修复以 RFC 形式交给变更实施 |
| Change Enablement——安全地审批和部署网络更新 | 评估变更风险（会不会在上课时间造成断网？）、审批、安排在低峰期、准备回滚、上线后复审 | 上线后的效果由持续改进验证 |
| Continual Improvement——复盘经验提升可靠性 | 用七步模型：基线（每周登录失败数、掉线率）→ 目标 → 行动 → 衡量是否达成 → 固化（如开学前的容量检查） | 改进需求回到 Plan / Improve 活动 |
一句话串起来：事件管理恢复服务 → 问题管理找根因 → 变更实施安全地部署修复 → 持续改进验证并固化；四者都在 SVC 中运行，并由 SVS 的治理和指导原则约束。
十二、本周考点速记 / 易错点
- SVS vs SVC：SVS 是整个系统（五组件）；SVC 是其中的六项运营活动。
- SVC 六活动：Plan、Improve、Engage（唯一对外）、Design & Transition、Obtain/Build（含供应商合同）、Deliver & Support；非线性，按价值流组合。
- ITIL 治理：政策、程序、控制；治理机构设方向、监控绩效、确保合规；治理本身也要持续改进。
- 34 个实践 = 14 一般 + 17 服务 + 3 技术；Project Management 是一般管理实践。
- Incident（尽快恢复）vs Problem（找根因防复发）；workaround 与 known error 连接两者；事件关了问题可能还开着。
- Incident vs Service Request：坏了 vs 要东西。
- Change Enablement：RFC → 评估审批 → 计划 → 实施 → 复审；紧急变更走快速通道；补充 standard / normal / emergency 三类。
- SLM：定义 → 商定 → 监控报告 → 评审改进；目标必须可衡量（Practice Exam Q4c）。
- 可用性
- 可用性 ≠ 服务价值：还要看响应/排队时间、首次解决率、满意度等成果指标。
- 服务台 = SPOC；处理事件、服务请求、沟通、知识库。
- 持续改进七步：愿景 → 现状（基线）→ 目标 → 路径 → 行动 → 是否达成 → 保持势头。
- ITIL 采用挑战：文化阻力、复杂度（别一次全上）、缺乏高层支持。
- PM ↔︎ ITSM 四衔接：项目到服务的移交、共享实践、价值延续（产出 → 成果）、反馈回路。
十三、本讲与前后的衔接（全课回顾）
| Week | 内容 | 与本讲的联系 |
|---|---|---|
| 5 | 质量管理 | PDCA ≈ 持续改进模型；utility/warranty ≈ 符合要求/适合使用 |
| 7 | 风险管理 | 事件优先级矩阵 ≈ 概率影响矩阵；变更实施中的风险评估 |
| 8 | 采购管理 | Obtain/Build、合作伙伴与供应商维度、供应商 SLA |
| 9 | 治理与对齐 | SVS 中的治理；ITIL 作为对齐框架 |
| 10 | 整合管理 | 整合变更控制 ↔︎ 变更实施；收尾移交运营 |
| 11 | ITSM 1 | 四维度、SVS、七条指导原则 |
| 12 | ITSM 2 | SVC、关键实践、持续改进、PM 与 ITSM 衔接 |
| 13 | 复习周 | 讲座复习全课；tutorial 模拟考 + Wi-Fi SVC 练习（已并入本文第十一章） |
期末提醒：考试 4 题 × 15 分；Practice Exam 的 Q4(c) 和 Question Bank 的 Q26–Q28 说明 ITSM 至少会占一个小问，可用性计算、SLA 目标设计、事件 vs 问题、SVC 映射都是高概率题型。