ITIL 4官方核心著作
由 superadmin 于 2024/04/03, 16:11 最后修改
复制
导出
打印预览
查看源代码
子项
内容
评论
附件 (15)
历史记录
信息
修改评论
Updated parent field.
Summary
Details
-
Page properties
-
- 父
-
... ... @@ -1,1 +1,1 @@ 1 -ITIL 4《创建、交付和支持》 CDS.WebHome 1 +xwiki:Main.ITIL 4《创建、交付和支持》 CDS.WebHome - Content
-
... ... @@ -153,7 +153,7 @@ 153 153 如果工作（和工作流）的度量和报告显示收益大于预期或实际成本（例如减少了开发工作的完成时间），则可以减少这些担忧。 154 154 155 155 156 -=== 5.1.5 左移 156 +=== 5.1.5 左移 === 157 157 158 158 左移是一个来自软件测试界的术语，现在也广泛应用在与IT和服务管理的其他领域。左移使得工作发生在更接近其源头的位置。价值流设计原则指出，高度相互依赖的任务应该组合起来，而不是作为一系列专门任务来执行。左移是改善工作流程，工作效率和有效性的综合方法，通过将工作交付移交给最佳团队或人员，缩短交货时间，解决时间，客户满意度和效率。在开发环境中，左移意味着将错误修复活动移至生命周期中较早的构建和测试团队。在支持环境中，则是将维修或解决问题的活动从更高级别的技术团队转移到一线通才团队。 159 159 ... ... @@ -246,7 +246,6 @@ 246 246 * 提供的自助服务界面，可以简化大量服务请求，并为常见故障提供相关且准确的解决方案，从而降低了每次事件的成本 247 247 * 团队成员可以执行的任务种类有所增加，从而提升了员工满意度和留任率 248 248 249 - 250 250 (% class="box" %) 251 251 ((( 252 252 (% id="cke_bm_316S" style="display:none" %)** **(%%)**ITIL 故事:为什么我们需要对工作进行优先级排序？** ... ... @@ -320,7 +320,7 @@ 320 320 321 321 ==== 5.2.1.1 商品化 ==== 322 322 323 -随着采用的技术不断增多，通常需要通过更高级的工具来更有效地管理技术17。例如： 322 +随着采用的技术不断增多，通常需要通过更高级的工具来更有效地管理技术^^17^^。例如： 324 324 325 325 * 随着数据中心的使用越来越普遍，以及计算能力的提高，出现了用于管理虚拟基础架构的虚拟化工具。 326 326 * 随着算力和存储成本的下降以及虚拟化工具的成熟，云计算模型（基础架构即服务）应运而生。 ... ... @@ -356,10 +356,10 @@ 356 356 357 357 MoSCoW的缩写代表： 358 358 359 -* 必须（Must）具备的需求对成功至关重要 360 -* 应该（Should）具备的需求对成功很重要，但不是必需的 361 -* 可以（Could）具备的需求是合乎需要的，但不是重要或必要的 362 -* 不需要（Won’t）需求对于成功是不必需的、不适当的或非关键的 358 +* **必须（Must）**具备的需求对成功至关重要 359 +* **应该（Should）**具备的需求对成功很重要，但不是必需的 360 +* **可以（Could）**具备的需求是合乎需要的，但不是重要或必要的 361 +* **不需要（Won’t）**需求对于成功是不必需的、不适当的或非关键的 363 363 364 364 该方法涵盖了不会被交付的需求。这很有用，因为列表通常填充了不必要的需求，例如无人需要的报告。这些需求增加了成本，却没有增加价值。 365 365 ... ... @@ -368,24 +368,18 @@ 368 368 369 369 在寻找供应商时，组织通常会公布服务或服务组件的需求，并邀请潜在的合作伙伴和供应商做出回应。根据需求或上下文，此活动可描述为： 370 370 371 -● 报价请求单（RFQ），当定义了需求并确定优先级，同时组织需要以下信息时，可以使用此技术： 370 +* **报价请求单（RFQ）**，当定义了需求并确定优先级，同时组织需要以下信息时，可以使用此技术： 371 +** 供应商如何满足要求 372 +** 满足已公布的需求可能需要的成本 373 +* **征求建议书（RFP**），当问题或挑战陈述已明确表述，但服务组件的确切要求或规范不明确或可能更改时，使用此技术。供应商需要提供建议或可行的解决方案，明确收益、成果以及成本。 374 +* **信息请求单（RFI）**，当需求不明确或不完整且需要外部协助来完善或添加需求时，可使用此技术，RFI之后通常是RFQ或RFP。 372 372 373 -●供应商如何满足要求 374 - 375 -●满足已公布的需求可能需要的成本 376 - 377 -● 征求建议书（RFP），当问题或挑战陈述已明确表述，但服务组件的确切要求或规范不明确或可能更改时，使用此技术。供应商需要提供建议或可行的解决方案，明确收益、成果以及成本。 378 - 379 -● 信息请求单（RFI），当需求不明确或不完整且需要外部协助来完善或添加需求时，可使用此技术，RFI之后通常是RFQ或RFP。 380 - 381 381 在某些情况下，组织在寻找合适的供应商时，可以让内部IT团队作为供应商参与进来。这种方法允许组织将内部IT与外部组织进行比较。但是，如果发生这种情况，重要的是： 382 382 383 -● 认识到关系的差异，并确保不会将同事视为供应商 378 +* 认识到关系的差异，并确保不会将同事视为供应商 379 +* 了解到内部IT运营模式与更广泛的组织具有相同的特征、优势、劣势、机会和威胁 380 +* 在通常成本较高的内部资源与有共享知识和目标的更广泛组织的资源之间取得平衡。 384 384 385 -● 了解到内部IT运营模式与更广泛的组织具有相同的特征、优势、劣势、机会和威胁 386 - 387 -● 在通常成本较高的内部资源与有共享知识和目标的更广泛组织的资源之间取得平衡。 388 - 389 389 理想情况下，供应商应反映组织的愿景、使命、道德和原则，从而最大程度地减少连个团队之间的摩擦和分歧。在许多情况下，供应商可以看作是组织品牌的延申。在整个选择过程中考虑并记住这一点至关重要。 390 390 391 391 (% class="box" %) ... ... @@ -432,16 +432,16 @@ 432 432 433 433 特常见的采购模型包括： 434 434 435 -* 内包：利用组织的现有资源来创建、交付和支持服务组件 436 -* 外包：组织将交付特定输出、成果、功能或整个产品或服务的责任转移给供应商，例如： 428 +* **内包**：利用组织的现有资源来创建、交付和支持服务组件 429 +* **外包**：组织将交付特定输出、成果、功能或整个产品或服务的责任转移给供应商，例如： 437 437 ** 使用本地数据中心供应商提供计算和存储资源 438 438 ** 通过中介机构寻找公开职位的候选人或寻找承包商 439 439 440 440 外包模式可以根据供应商或其资源的位置进一步细分。在描述许多技术供应商或云计算服务提供商（基础设施即服务、软件即服务等）时，这种分类可能不适用，因为供应商资源的物理位置并不总是公开的。供应商位置分为三类： 441 441 442 -* 在岸供应商在同一国家/地区。 443 -* 近岸供应商位于不同的国家或大陆，但是时区差异很小（例如，英国组织使用欧洲大陆的供应商）。 444 -* 离岸供应商位于不同的国家或大陆，通常距离组织有几个时区（例如，美国组织使用印度的供应商）。 435 +* **在岸 **供应商在同一国家/地区。 436 +* **近岸 **供应商位于不同的国家或大陆，但是时区差异很小（例如，英国组织使用欧洲大陆的供应商）。 437 +* **离岸 **供应商位于不同的国家或大陆，通常距离组织有几个时区（例如，美国组织使用印度的供应商）。 445 445 446 446 在外包工作时，将工作转移到供应商后剩余的组织资源称为“被保留组织” 447 447 ... ... @@ -467,7 +467,6 @@ 467 467 * 组织与供应商之间的文化或语言差异 468 468 * 外包工作时是否会增加以及将增加多少管理费用 469 469 470 - 471 471 (% class="box" %) 472 472 ((( 473 473 **ITIL 故事: 外包注意事项** ... ... @@ -494,10 +494,10 @@ 494 494 495 495 这个部分有四个主要模型（图5.2）。组织必须依据自己的情况考虑最佳模型，以便转变到更加协调的服务-供应商关系：由于多种因素，服务集成和管理的重要性日益提高： 496 496 497 -* 保留服务集成，被保留组织管理所有供应商，并协调服务集成和管理功能本身 498 -* 单一供应商，一个供应商提供所有服务以及服务集成和管理功能。 499 -* 服务监管者，除了提供服务集成和管理功能，以及一个或多个交付功能之外，还管理其他供应商。 500 -* 服务集成作为服务，由供应商提供服务集成和管理功能并管理所有其他供应商，即使该供应商未向组织提供任何服务。 489 +* **保留服务集成**，被保留组织管理所有供应商，并协调服务集成和管理功能本身 490 +* **单一供应商**，一个供应商提供所有服务以及服务集成和管理功能。 491 +* **服务监管者**，除了提供服务集成和管理功能，以及一个或多个交付功能之外，还管理其他供应商。 492 +* **服务集成作为服务**，由供应商提供服务集成和管理功能并管理所有其他供应商，即使该供应商未向组织提供任何服务。 501 501 502 502 由于多种因素，服务集成和管理的重要性日益提高： 503 503 ... ... @@ -534,7 +534,6 @@ 534 534 ** 变更管理 535 535 ** 服务请求 536 536 537 - 538 538 (% class="box" %) 539 539 ((( 540 540 (% id="cke_bm_393S" style="display:none" %)** **(%%)**ITIL 故事: 服务集成和管理**