由 superadmin 于 2024/04/03, 16:11 最后修改
从版本< 19.8 >
由roll tech编辑
在2022/08/08, 09:22上
到版本
由roll tech编辑
在2022/08/05, 18:24上
< >
修改评论 该版本没有评论

Summary

Details

Icon Page properties
Content
... ... @@ -56,12 +56,12 @@
56 56  
57 57  在较高层次上，如果需求产生时有闲置产能，那么就不需要对工作进行优先级排序；这项工作可以立即开始。但是，当需求超出产能时，组织可以选择管理需求，以实现队列最小化，从而避免对工作进行优先级排序。例如：
58 58  
59 -* 通过以下方式减少价值需求量的变化：
59 +* 通过以下方式减少价值需求的数量：
60 60  ** 使用基于工作量的定价机制（例如，前十个服务请求的费率低于后十个）
61 61  ** 使用基于需求发生时间的定价机制（例如，餐厅提供每周夜间服务折扣）
62 62  ** 使用基于质量的定价机制（例如，商务舱机票的价格是经济舱机票的三倍）
63 63  ** 改变客户对完成工作所需时长的期望（例如，上午11点后提出的请求将在下一个工作日完成）
64 -* 减少纳入价值流或步骤的需求数量变化（例如，仅允许员工每季度提交一个更改其福利的请求）
64 +* 减少纳入价值流或步骤的需求数量（例如，仅允许员工每季度提交一个更改其福利的请求）
65 65  * 增加在给定的时间内可以满足的需求数量；例如，通过：
66 66  ** 使用自动化加速艰苦工作（以线性方式扩展的常见和重复性任务）的处理
67 67  ** 增加团队规模或团队数量，以便并行完成更多工作
... ... @@ -114,7 +114,7 @@
114 114  
115 115  === 5.1.4 全功能团队 ===
116 116  
117 -全功能团队^^13^^是一种管理工作的方法，即各类专家或利益干系人在一个项目上共同工作，直到明显地表现出谁最有资格继续工作为止，这时其他人可以自由地转换到其他项目上^^14^^。
117 +全功能团队13是一种管理工作的方法，即各类专家或利益干系人在一个项目上共同工作，直到明显地表现出谁最有资格继续工作为止，这时其他人可以自由地转换到其他项目上14。
118 118  
119 119  全功能团队是专家资源分层组织结构的替代方案，在全功能团队种，工作不断升级，直到各自达到适当的能力和权限级别。被全功能团队解决的分层结构的缺陷包括：
120 120  
... ... @@ -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,6 +246,7 @@
246 246  * 提供的自助服务界面，可以简化大量服务请求，并为常见故障提供相关且准确的解决方案，从而降低了每次事件的成本
247 247  * 团队成员可以执行的任务种类有所增加，从而提升了员工满意度和留任率
248 248  
249 +
249 249  (% class="box" %)
250 250  (((
251 251  (% id="cke_bm_316S" style="display:none" %)** **(%%)**ITIL 故事:为什么我们需要对工作进行优先级排序？**
... ... @@ -266,33 +266,37 @@
266 266  
267 267  服务提供者可以选择自己创建服务组件，或者从合作伙伴或供应商处获取。
268 268  
269 -重要的是要记住：
270 +● 供应商是一个向消费者提供产品和服务，但与消费者没有共同目标的组织。
270 270  
271 -* 合作伙伴(partner)是向消费者提供产品和服务并与其消费者密切合作以实现共同目标和目的的组织。
272 -* 供应商(supplier)是一个向消费者提供产品和服务，但与消费者没有共同目标的组织。
273 -* “提供方(Vendor)”是一个通用术语，通常用于描述向客户销售产品或服务的任何组织。从服务消费者的角度来看，提供方可以是合作伙伴或供应商，也可以与服务消费者没有直接的服务关系。提供方还可以在某些领域成为合作伙伴，而在其他领域成为供应商，例如：
274 -** 云服务提供方可以为消费者提供基础架构服务，但也可以与该消费者合作实施工具，使消费者能最大限度地利用这些服务。
275 -** 客户服务提供方可以向消费者提供熟练的人员、工具和其他资源，但也可以与消费者合作进行营销活动，突出其客户服务的质量。
272 +●“提供方”是一个通用术语，通常用于描述向客户销售产品或服务的任何组织。从服务消费者的角度来看，提供方可以是合作伙伴或供应商，也可以与服务消费者没有直接的服务关系。提供方还可以在某些领域成为合作伙伴，而在其他领域成为供应商，例如：
276 276  
277 -本节提出通用术语“服务组件（service components）”，可以涵盖人员、工具、信息或用于创建、交付或支持产品和服务的任何其他类型资源。本节提出术语“组织”来泛指服务的购买者或消费者，使用术语“提供方”来泛指服务的提供者。
274 +● 云服务提供方可以为消费者提供基础架构服务，但也可以与该消费者合作实施工具，使消费者能最大限度地利用这些服务。
278 278  
276 +● 客户服务提供方可以向消费者提供熟练的人员、工具和其他资源，但也可以与消费者合作进行营销活动，突出其客户服务的质量。
277 +
278 +本节提出通用术语“服务组件”，可以涵盖人员、工具、信息或用于创建、交付或支持产品和服务的任何其他类型资源。本节提出术语“组织”来泛指服务的购买者或消费者，使用术语“提供方”来泛指服务的提供者。
279 +
279 279  组织仅使用其现有资源来创建产品和服务的情况越来越少，于是组织经常不得不决定是构建还是购买服务组件。这些决定应以数据和事实为依据，而不要依靠情绪、传言或未经证实的报道。为了应对日益复杂的决策，许多组织，特别是大型企业采用了正式的采购策略，其中考虑了以下因素：
280 280  
281 -* 组织当前和未来的采购需求
282 -* 采购服务组件的当前成本和预估的未来成本（通常考虑总体拥有成本）
283 -* 生态系统中的资源稀缺性
284 -* 生态系统内竞争、供应商和客户的影响阻碍新供应商出现的壁垒，以及防止现有供应商倒闭的措施
285 -* 从多家供应商处采购组件的成本和风险
282 +●组织当前和未来的采购需求
286 286  
284 +● 采购服务组件的当前成本和预估的未来成本（通常考虑总体拥有成本）
285 +
286 +●生态系统中的资源稀缺性
287 +
288 +●生态系统内竞争、供应商和客户的影响阻碍新供应商出现的壁垒，以及防止现有供应商倒闭的措施
289 +
290 +● 从多家供应商处采购组件的成本和风险
291 +
287 287  这些考虑因素用于形成采购策略，以及关于如何采购每种类型的服务组件的相关计划和模型。
288 288  
289 289  
290 -=== 5.2.1 “建造与购买”的考虑 ===
295 +=== 5.2.1 “构建和采购”注意事项 ===
291 291  
292 -认识到以下因素引起的偏差或压力很重要：
297 +重要的是要认识到以下因素引起的偏差或压力：
293 293  
294 294  * 熟悉工具的先前版本或工具供应商的产品和服务
295 -* 在没有确认环境^^15^^差异的情况下，使用关于产品和服务的先前经验
300 +* 在没有确认环境15差异的情况下，使用关于产品和服务的先前经验
296 296  * 强烈希望使用新工具或技能而仅因为它们是新的
297 297  * 供应商的积极销售战术
298 298  * 降低成本的压力，通常以质量为代价
... ... @@ -319,7 +319,7 @@
319 319  
320 320  ==== 5.2.1.1 商品化 ====
321 321  
322 -随着采用的技术不断增多，通常需要通过更高级的工具来更有效地管理技术^^17^^。例如：
327 +随着采用的技术不断增多，通常需要通过更高级的工具来更有效地管理技术17。例如：
323 323  
324 324  * 随着数据中心的使用越来越普遍，以及计算能力的提高，出现了用于管理虚拟基础架构的虚拟化工具。
325 325  * 随着算力和存储成本的下降以及虚拟化工具的成熟，云计算模型（基础架构即服务）应运而生。
... ... @@ -355,10 +355,10 @@
355 355  
356 356  MoSCoW的缩写代表：
357 357  
358 -* **必须（Must）**具备的需求对成功至关重要
359 -* **应该（Should）**具备的需求对成功很重要，但不是必需的
360 -* **可以（Could）**具备的需求是合乎需要的，但不是重要或必要的
361 -* **不需要（Won’t）**需求对于成功是不必需的、不适当的或非关键的
363 +* 必须（Must）具备的需求对成功至关重要
364 +* 应该（Should）具备的需求对成功很重要，但不是必需的
365 +* 可以（Could）具备的需求是合乎需要的，但不是重要或必要的
366 +* 不需要（Won’t）需求对于成功是不必需的、不适当的或非关键的
362 362  
363 363  该方法涵盖了不会被交付的需求。这很有用，因为列表通常填充了不必要的需求，例如无人需要的报告。这些需求增加了成本，却没有增加价值。
364 364  
... ... @@ -367,18 +367,24 @@
367 367  
368 368  在寻找供应商时，组织通常会公布服务或服务组件的需求，并邀请潜在的合作伙伴和供应商做出回应。根据需求或上下文，此活动可描述为：
369 369  
370 -* **报价请求单（RFQ）**，当定义了需求并确定优先级，同时组织需要以下信息时，可以使用此技术：
371 -** 供应商如何满足要求
372 -** 满足已公布的需求可能需要的成本
373 -* **征求建议书（RFP**），当问题或挑战陈述已明确表述，但服务组件的确切要求或规范不明确或可能更改时，使用此技术。供应商需要提供建议或可行的解决方案，明确收益、成果以及成本。
374 -* **信息请求单（RFI）**，当需求不明确或不完整且需要外部协助来完善或添加需求时，可使用此技术，RFI之后通常是RFQ或RFP。
375 +● 报价请求单（RFQ），当定义了需求并确定优先级，同时组织需要以下信息时，可以使用此技术：
375 375  
377 +●供应商如何满足要求
378 +
379 +●满足已公布的需求可能需要的成本
380 +
381 +● 征求建议书（RFP），当问题或挑战陈述已明确表述，但服务组件的确切要求或规范不明确或可能更改时，使用此技术。供应商需要提供建议或可行的解决方案，明确收益、成果以及成本。
382 +
383 +● 信息请求单（RFI），当需求不明确或不完整且需要外部协助来完善或添加需求时，可使用此技术，RFI之后通常是RFQ或RFP。
384 +
376 376  在某些情况下，组织在寻找合适的供应商时，可以让内部IT团队作为供应商参与进来。这种方法允许组织将内部IT与外部组织进行比较。但是，如果发生这种情况，重要的是：
377 377  
378 -* 认识到关系的差异，并确保不会将同事视为供应商
379 -* 了解到内部IT运营模式与更广泛的组织具有相同的特征、优势、劣势、机会和威胁
380 -* 在通常成本较高的内部资源与有共享知识和目标的更广泛组织的资源之间取得平衡。
387 +● 认识到关系的差异，并确保不会将同事视为供应商
381 381  
389 +● 了解到内部IT运营模式与更广泛的组织具有相同的特征、优势、劣势、机会和威胁
390 +
391 +● 在通常成本较高的内部资源与有共享知识和目标的更广泛组织的资源之间取得平衡。
392 +
382 382  理想情况下，供应商应反映组织的愿景、使命、道德和原则，从而最大程度地减少连个团队之间的摩擦和分歧。在许多情况下，供应商可以看作是组织品牌的延申。在整个选择过程中考虑并记住这一点至关重要。
383 383  
384 384  (% class="box" %)
... ... @@ -425,16 +425,16 @@
425 425  
426 426  特常见的采购模型包括：
427 427  
428 -* **内包**：利用组织的现有资源来创建、交付和支持服务组件
429 -* **外包**：组织将交付特定输出、成果、功能或整个产品或服务的责任转移给供应商，例如：
439 +* 内包：利用组织的现有资源来创建、交付和支持服务组件
440 +* 外包：组织将交付特定输出、成果、功能或整个产品或服务的责任转移给供应商，例如：
430 430  ** 使用本地数据中心供应商提供计算和存储资源
431 431  ** 通过中介机构寻找公开职位的候选人或寻找承包商
432 432  
433 433  外包模式可以根据供应商或其资源的位置进一步细分。在描述许多技术供应商或云计算服务提供商（基础设施即服务、软件即服务等）时，这种分类可能不适用，因为供应商资源的物理位置并不总是公开的。供应商位置分为三类：
434 434  
435 -* **在岸 **供应商在同一国家/地区。
436 -* **近岸 **供应商位于不同的国家或大陆，但是时区差异很小（例如，英国组织使用欧洲大陆的供应商）。
437 -* **离岸 **供应商位于不同的国家或大陆，通常距离组织有几个时区（例如，美国组织使用印度的供应商）。
446 +* 在岸供应商在同一国家/地区。
447 +* 近岸供应商位于不同的国家或大陆，但是时区差异很小（例如，英国组织使用欧洲大陆的供应商）。
448 +* 离岸供应商位于不同的国家或大陆，通常距离组织有几个时区（例如，美国组织使用印度的供应商）。
438 438  
439 439  在外包工作时，将工作转移到供应商后剩余的组织资源称为“被保留组织”
440 440  
... ... @@ -460,6 +460,7 @@
460 460  * 组织与供应商之间的文化或语言差异
461 461  * 外包工作时是否会增加以及将增加多少管理费用
462 462  
474 +
463 463  (% class="box" %)
464 464  (((
465 465  **ITIL 故事: 外包注意事项**
... ... @@ -486,10 +486,10 @@
486 486  
487 487  这个部分有四个主要模型（图5.2）。组织必须依据自己的情况考虑最佳模型，以便转变到更加协调的服务-供应商关系：由于多种因素，服务集成和管理的重要性日益提高：
488 488  
489 -* **保留服务集成**，被保留组织管理所有供应商，并协调服务集成和管理功能本身
490 -* **单一供应商**，一个供应商提供所有服务以及服务集成和管理功能。
491 -* **服务监管者**，除了提供服务集成和管理功能，以及一个或多个交付功能之外，还管理其他供应商。
492 -* **服务集成作为服务**，由供应商提供服务集成和管理功能并管理所有其他供应商，即使该供应商未向组织提供任何服务。
501 +* 保留服务集成，被保留组织管理所有供应商，并协调服务集成和管理功能本身
502 +* 单一供应商，一个供应商提供所有服务以及服务集成和管理功能。
503 +* 服务监管者，除了提供服务集成和管理功能，以及一个或多个交付功能之外，还管理其他供应商。
504 +* 服务集成作为服务，由供应商提供服务集成和管理功能并管理所有其他供应商，即使该供应商未向组织提供任何服务。
493 493  
494 494  由于多种因素，服务集成和管理的重要性日益提高：
495 495  
... ... @@ -526,6 +526,7 @@
526 526  ** 变更管理
527 527  ** 服务请求
528 528  
541 +
529 529  (% class="box" %)
530 530  (((
531 531  (% id="cke_bm_393S" style="display:none" %)** **(%%)**ITIL 故事: 服务集成和管理**
深圳市艾拓先锋企业管理咨询有限公司