由 superadmin 于 2024/04/03, 16:11 最后修改
从版本< 18.1 >
由superadmin编辑
在2021/12/21, 20:07上
到版本
由roll tech编辑
在2022/08/08, 09:22上
< >
修改评论 该版本没有评论

Summary

Details

Icon Page properties
文档作者
... ... @@ -1,1 +1,1 @@
1 -XWiki.superadmin
1 +XWiki.RollTech
Content
... ... @@ -1,3 +1,8 @@
1 +
2 +
3 +
4 +[[阅读下一章>>http://itil4hub.cn/bin/view/ITIL%204%E3%80%8A%E5%88%9B%E5%BB%BA%E3%80%81%E4%BA%A4%E4%BB%98%E5%92%8C%E6%94%AF%E6%8C%81%E3%80%8B%20CDS/%E7%AC%AC6%E7%AB%A0%20%E7%BB%93%E8%AE%BA/]]  [[返回上一章>>http://itil4hub.cn/bin/view/ITIL%204%E3%80%8A%E5%88%9B%E5%BB%BA%E3%80%81%E4%BA%A4%E4%BB%98%E5%92%8C%E6%94%AF%E6%8C%81%E3%80%8B%20CDS/%E7%AC%AC4%E7%AB%A0%20%E5%88%9B%E5%BB%BA%E3%80%81%E4%BA%A4%E4%BB%98%E5%92%8C%E6%94%AF%E6%8C%81%E6%9C%8D%E5%8A%A1%E7%9A%84%E4%BB%B7%E5%80%BC%E6%B5%81/]]
5 +
1 1  {{box cssClass="floatinginfobox" title="**Contents**"}}
2 2  {{toc/}}
3 3  {{/box}}
... ... @@ -12,9 +12,9 @@
12 12  优先级排序通常是一项与支持和软件开发工作相关的活动（例如，对事件记录进行优先级排序或对冲刺待办事项集合进行优先级排序），但它其实被广泛使用。
13 13  
14 14  
15 -=== 5.1.1 按表单管理工作 ===
20 +=== 5.1.1 按工单管理工作 ===
16 16  
17 -一张表单是一份工作记录。在广泛采用数字系统之前，纸质表格是常见的通信媒介，位于工作流程的中心。这些表单通常用尺子，钢笔和打字机制作，复印分发，手工填写，并按照办文流程中放置​​在下一位雇员的物理收文盘中。尽管数据可能已经在某个时候输入进了电子系统，但是纸制单据本身就是数据（以及对数据的响应）发展的载体。
22 +一张工单(ticket)是一份工作记录。在广泛采用数字系统之前，纸质表格是常见的通信媒介，位于工作流程的中心。这些表单通常用尺子，钢笔和打字机制作，复印分发，手工填写，并按照办文流程中放置​​在下一位雇员的物理收文盘中。尽管数据可能已经在某个时候输入进了电子系统，但是纸制单据本身就是数据（以及对数据的响应）发展的载体。
18 18  
19 19  商业IT系统的出现和基于计算机的工作的规范化意味着用于信息捕获和传输的媒体发生了根本性的变化，但这并没有改变基本的工单流转过程。纸质表单上的数据字段成为由软件应用程序控制的数据库表。数据字段集合以熟悉的方式排列成表格，这些表格通过屏幕显示给用户。换言之，软件用户界面与纸质表单相呼应。
20 20  
... ... @@ -51,12 +51,12 @@
51 51  
52 52  在较高层次上，如果需求产生时有闲置产能，那么就不需要对工作进行优先级排序；这项工作可以立即开始。但是，当需求超出产能时，组织可以选择管理需求，以实现队列最小化，从而避免对工作进行优先级排序。例如：
53 53  
54 -* 通过以下方式减少价值需求的数量：
59 +* 通过以下方式减少价值需求量的变化：
55 55  ** 使用基于工作量的定价机制（例如，前十个服务请求的费率低于后十个）
56 56  ** 使用基于需求发生时间的定价机制（例如，餐厅提供每周夜间服务折扣）
57 57  ** 使用基于质量的定价机制（例如，商务舱机票的价格是经济舱机票的三倍）
58 58  ** 改变客户对完成工作所需时长的期望（例如，上午11点后提出的请求将在下一个工作日完成）
59 -* 减少纳入价值流或步骤的需求数量（例如，仅允许员工每季度提交一个更改其福利的请求）
64 +* 减少纳入价值流或步骤的需求数量变化（例如，仅允许员工每季度提交一个更改其福利的请求）
60 60  * 增加在给定的时间内可以满足的需求数量；例如，通过：
61 61  ** 使用自动化加速艰苦工作（以线性方式扩展的常见和重复性任务）的处理
62 62  ** 增加团队规模或团队数量，以便并行完成更多工作
... ... @@ -81,28 +81,28 @@
81 81  
82 82  有许多不同的技术可以对工作进行优先级排序，以最小化队列和等待时间。这些技术可大致分为以下几类：
83 83  
84 -* 资源可用性或质量优先级取决于完成工作所需资源的可用性。例如，如果一个基础设施支持团队有一名网络专家，每个网络支持案例都分配给他，那么只要网络专家被占用，团队就应该优先处理与网络无关的案例。
85 -* 当前工作量负载优先级由资源的当前工作量负载决定，前提是资源之间的质量没有差异或工作项的大小没有变化。例如，支持中心自动化可能会将来电或聊天分配给当前未与用户联系的支持专员，或分配给工作负荷较轻的专员。
86 -* 存续时间优先级由工作项的存续时间决定；例如：
87 -** 先进先出 执行最早排入的等待项。
88 -** 后进先出 执行最新排入的等待项。
89 -* 持续时间优先级由完成工作项所需的时间决定；例如，通过：
90 -** 最快速项目优先 执行可以最快完成的项目
91 -** 最耗时项目优先 执行需要最多时间的项目。
92 -* 经济或财务因素 优先级由工作项目的货币收益和成本决定。例如，一个仅能够处理一个工作项目的组织可能会优先考虑那些经济收益最高的项目，例如那些收入最多，财务影响最大或投资回报最高的项目。
93 -* 经济处罚 优先处理受经济处罚的工作项目，例如可减少监管罚款的合规性项目。
94 -* 需求的来源或类型 优先处理有权获得更直接关注的工作项，如组织CIO的请求。通常，组织会设立多种服务级别协议（并相应定价）；例如，技术供应商和支持服务提供商可能会实现一个分级合作系统，在该系统中，银牌客户的优先级高于铜牌客户。
95 -* 分流 优先级是由紧急程度决定的，它基于对延迟可能造成的影响的评估。例如，医生会优先治疗骨折而不是感冒。只有在解决了更紧急的需求时才考虑不太紧急的需求。组织应该用程序来补充这项技术，以确保低优先级工作不会无人值守。例如，当某些截止日期或阈值临近时，支持组织通常会提高开放支持问题的优先级。
89 +* **资源可用性或质量** 优先级取决于完成工作所需资源的可用性。例如，如果一个基础设施支持团队有一名网络专家，每个网络支持案例都分配给他，那么只要网络专家被占用，团队就应该优先处理与网络无关的案例。
90 +* **当前工作量负载**  优先级由资源的当前工作量负载决定，前提是资源之间的质量没有差异或工作项的大小没有变化。例如，支持中心自动化可能会将来电或聊天分配给当前未与用户联系的支持专员，或分配给工作负荷较轻的专员。
91 +* **存续时间  **优先级由工作项的存续时间决定；例如：
92 +** **先进先出** 执行最早排入的等待项。
93 +** **后进先出** 执行最新排入的等待项。
94 +* **持续时间  **优先级由完成工作项所需的时间决定；例如，通过：
95 +** **最快速项目优先** 执行可以最快完成的项目
96 +** **最耗时项目优先** 执行需要最多时间的项目。
97 +* **经济或财务因素 **优先级由工作项目的货币收益和成本决定。例如，一个仅能够处理一个工作项目的组织可能会优先考虑那些经济收益最高的项目，例如那些收入最多，财务影响最大或投资回报最高的项目。
98 +* **经济处罚** 优先处理受经济处罚的工作项目，例如可减少监管罚款的合规性项目。
99 +* **需求的来源或类型** 优先处理有权获得更直接关注的工作项，如组织CIO的请求。通常，组织会设立多种服务级别协议（并相应定价）；例如，技术供应商和支持服务提供商可能会实现一个分级合作系统，在该系统中，银牌客户的优先级高于铜牌客户。
100 +* **分流 **优先级是由紧急程度决定的，它基于对延迟可能造成的影响的评估。例如，医生会优先治疗骨折而不是感冒。只有在解决了更紧急的需求时才考虑不太紧急的需求。组织应该用程序来补充这项技术，以确保低优先级工作不会无人值守。例如，当某些截止日期或阈值临近时，支持组织通常会提高开放支持问题的优先级。
96 96  
97 97  重要的是要注意，优先级排序技术是特定于环境的。适用于一种环境或工作类型的技术可能不适用于另一种环境或工作类型。同时，将一组简单的共同目标应用在所有类型的工作的优先级排序上是很有用的。例如，以下各项的优先级排序：
98 98  
99 -* 持续改进机会 其优先级可以通过与其他项目相同的方式来确定，例如使用ROI估算。
100 -* 事件 其优先级可以通过与开发待办事项列表项相同的方式确定（例如，使用经济效益/惩罚性估算）。
104 +* **持续改进机会** 其优先级可以通过与其他项目相同的方式来确定，例如使用ROI估算。
105 +* **事件** 其优先级可以通过与开发待办事项列表项相同的方式确定（例如，使用经济效益/惩罚性估算）。
101 101  
102 102  多种优先级排列技术同时运用也是很常见的。例如：
103 103  
104 -* 在延迟成本方法11中，优先排序考虑了时间推移的经济影响或惩罚。
105 -* 在加权最短作业优先（WSJF）12方法中，优先排序考虑了延迟成本和工作持续时间。
109 +* 在延迟成本方法^^11^^中，优先排序考虑了时间推移的经济影响或惩罚。
110 +* 在加权最短作业优先（WSJF）^^12^^方法中，优先排序考虑了延迟成本和工作持续时间。
106 106  
107 107  一种常见的优先事件技术是考虑影响（经济因素）和紧迫性（时间因素）。应定期或随着更多工作进入系统而修订工作优先级；这种修订允许动态重新分配资源以管理队列。
108 108  
... ... @@ -109,7 +109,7 @@
109 109  
110 110  === 5.1.4 全功能团队 ===
111 111  
112 -全功能团队13是一种管理工作的方法，即各类专家或利益干系人在一个项目上共同工作，直到明显地表现出谁最有资格继续工作为止，这时其他人可以自由地转换到其他项目上14。
117 +全功能团队^^13^^是一种管理工作的方法，即各类专家或利益干系人在一个项目上共同工作，直到明显地表现出谁最有资格继续工作为止，这时其他人可以自由地转换到其他项目上^^14^^。
113 113  
114 114  全功能团队是专家资源分层组织结构的替代方案，在全功能团队种，工作不断升级，直到各自达到适当的能力和权限级别。被全功能团队解决的分层结构的缺陷包括：
115 115  
... ... @@ -148,7 +148,7 @@
148 148  如果工作（和工作流）的度量和报告显示收益大于预期或实际成本（例如减少了开发工作的完成时间），则可以减少这些担忧。
149 149  
150 150  
151 -=== 5.1.5 左移                                                                                ===
156 +=== 5.1.5 左移                                                                             ===
152 152  
153 153  左移是一个来自软件测试界的术语，现在也广泛应用在与IT和服务管理的其他领域。左移使得工作发生在更接近其源头的位置。价值流设计原则指出，高度相互依赖的任务应该组合起来，而不是作为一系列专门任务来执行。左移是改善工作流程，工作效率和有效性的综合方法，通过将工作交付移交给最佳团队或人员，缩短交货时间，解决时间，客户满意度和效率。在开发环境中，左移意味着将错误修复活动移至生命周期中较早的构建和测试团队。在支持环境中，则是将维修或解决问题的活动从更高级别的技术团队转移到一线通才团队。
154 154  
... ... @@ -225,7 +225,6 @@
225 225  * 向员工，客户和其他利益干系人传达已实现的收益
226 226  )))
227 227  
228 -
229 229  相同的原则可以应用于其他领域，例如：
230 230  
231 231  * 可以重新组织一线，二线和三线支持的任务划分，以便一线服务人员能够管理更具挑战性的呼叫。
... ... @@ -242,9 +242,10 @@
242 242  * 提供的自助服务界面，可以简化大量服务请求，并为常见故障提供相关且准确的解决方案，从而降低了每次事件的成本
243 243  * 团队成员可以执行的任务种类有所增加，从而提升了员工满意度和留任率
244 244  
249 +(% class="box" %)
250 +(((
251 +(% id="cke_bm_316S" style="display:none" %)** **(%%)**ITIL 故事:为什么我们需要对工作进行优先级排序？**
245 245  
246 -**ITIL 故事:为什么我们需要对工作进行优先级排序？**
247 -
248 248  [[image:1640087673488-662.png||height="42" width="41"]]**因杜:**//我一直在为自行车租赁服务开发在线支付应用程序。但是，我还需要进行另一项工作。我需要业务部门的指导，告诉我应该优先考虑哪项计划//
249 249  
250 250  [[image:1640087684124-535.png||height="54" width="41"]]**亨利: **//目前，业务和监管要求超出了我们的能力，影响了我们完成工作的产能；我们根本无法满足当前的需求。在线支付应用程序的开发很重要，但是因杜的另一个计划能将我们的财务流程与政府监管的变化结合起来。必须优先考虑这一点，以确保公司不违反监管要求//
... ... @@ -254,6 +254,7 @@
254 254  [[image:1640087703659-396.png||height="43" width="38"]]**弗朗西斯:**//由于对电动自行车在线服务的需求持续增长，我没有足够的时间来管理客户的预订以及为我们的车队进行维修、保养和采购新自行车。我们越早获得在线支付应用程序越好。客户将能够自助服务，这意味着他们可以在线付费，从而释放了我的产能。//
255 255  
256 256  [[image:1640087715612-958.png||height="39" width="43"]]**艾丽斯: **//我在租车部门的团队可以在迅速为自行车提供手动预订流程。这将有助于释放Francis的产能，直到因杜完成在线支付应用程序为止。但是，我的团队无法无限期地进行这项工作，因为这很可能会影响我们维持汽车租赁客户获得当前高标准服务的能力。//
262 +)))
257 257  
258 258  
259 259  == 5.2 商务和采购方面的考虑 ==
... ... @@ -260,37 +260,33 @@
260 260  
261 261  服务提供者可以选择自己创建服务组件，或者从合作伙伴或供应商处获取。
262 262  
263 -● 供应商是一个向消费者提供产品和服务，但与消费者没有共同目标的组织。
269 +重要的是要记住：
264 264  
265 -●“提供方”是一个通用术语，通常用于描述向客户销售产品或服务的任何组织。从服务消费者的角度来看，提供方可以是合作伙伴或供应商，也可以与服务消费者没有直接的服务关系。提供方还可以在某些领域成为合作伙伴，而在其他领域成为供应商，例如：
271 +* 合作伙伴(partner)是向消费者提供产品和服务并与其消费者密切合作以实现共同目标和目的的组织。
272 +* 供应商(supplier)是一个向消费者提供产品和服务，但与消费者没有共同目标的组织。
273 +* “提供方(Vendor)”是一个通用术语，通常用于描述向客户销售产品或服务的任何组织。从服务消费者的角度来看，提供方可以是合作伙伴或供应商，也可以与服务消费者没有直接的服务关系。提供方还可以在某些领域成为合作伙伴，而在其他领域成为供应商，例如：
274 +** 云服务提供方可以为消费者提供基础架构服务，但也可以与该消费者合作实施工具，使消费者能最大限度地利用这些服务。
275 +** 客户服务提供方可以向消费者提供熟练的人员、工具和其他资源，但也可以与消费者合作进行营销活动，突出其客户服务的质量。
266 266  
267 -● 云服务提供方可以为消费者提供基础架构服务，但也可以与该消费者合作实施工具，使消费者能最大限度地利用这些服务。
277 +本节提出通用术语“服务组件（service components）”，可以涵盖人员、工具、信息或用于创建、交付或支持产品和服务的任何其他类型资源。本节提出术语“组织”来泛指服务的购买者或消费者，使用术语“提供方”来泛指服务的提供者。
268 268  
269 -● 客户服务提供方可以向消费者提供熟练的人员、工具和其他资源，但也可以与消费者合作进行营销活动，突出其客户服务的质量。
270 -
271 -本节提出通用术语“服务组件”，可以涵盖人员、工具、信息或用于创建、交付或支持产品和服务的任何其他类型资源。本节提出术语“组织”来泛指服务的购买者或消费者，使用术语“提供方”来泛指服务的提供者。
272 -
273 273  组织仅使用其现有资源来创建产品和服务的情况越来越少，于是组织经常不得不决定是构建还是购买服务组件。这些决定应以数据和事实为依据，而不要依靠情绪、传言或未经证实的报道。为了应对日益复杂的决策，许多组织，特别是大型企业采用了正式的采购策略，其中考虑了以下因素：
274 274  
275 -●组织当前和未来的采购需求
281 +* 组织当前和未来的采购需求
282 +* 采购服务组件的当前成本和预估的未来成本（通常考虑总体拥有成本）
283 +* 生态系统中的资源稀缺性
284 +* 生态系统内竞争、供应商和客户的影响阻碍新供应商出现的壁垒，以及防止现有供应商倒闭的措施
285 +* 从多家供应商处采购组件的成本和风险
276 276  
277 -● 采购服务组件的当前成本和预估的未来成本（通常考虑总体拥有成本）
278 -
279 -●生态系统中的资源稀缺性
280 -
281 -●生态系统内竞争、供应商和客户的影响阻碍新供应商出现的壁垒，以及防止现有供应商倒闭的措施
282 -
283 -● 从多家供应商处采购组件的成本和风险
284 -
285 285  这些考虑因素用于形成采购策略，以及关于如何采购每种类型的服务组件的相关计划和模型。
286 286  
287 287  
288 -=== 5.2.1 “构建和采购”注意事项 ===
290 +=== 5.2.1 “建造与购买”的考虑 ===
289 289  
290 -重要的是要认识到以下因素引起的偏差或压力：
292 +认识到以下因素引起的偏差或压力很重要：
291 291  
292 292  * 熟悉工具的先前版本或工具供应商的产品和服务
293 -* 在没有确认环境15差异的情况下，使用关于产品和服务的先前经验
295 +* 在没有确认环境^^15^^差异的情况下，使用关于产品和服务的先前经验
294 294  * 强烈希望使用新工具或技能而仅因为它们是新的
295 295  * 供应商的积极销售战术
296 296  * 降低成本的压力，通常以质量为代价
... ... @@ -315,10 +315,9 @@
315 315  * 创建服务组件是可预测且重复的工作
316 316  * 生态系统是稳定的，通常不会波动。
317 317  
318 -
319 319  ==== 5.2.1.1 商品化 ====
320 320  
321 -随着采用的技术不断增多，通常需要通过更高级的工具来更有效地管理技术17。例如：
322 +随着采用的技术不断增多，通常需要通过更高级的工具来更有效地管理技术^^17^^。例如：
322 322  
323 323  * 随着数据中心的使用越来越普遍，以及计算能力的提高，出现了用于管理虚拟基础架构的虚拟化工具。
324 324  * 随着算力和存储成本的下降以及虚拟化工具的成熟，云计算模型（基础架构即服务）应运而生。
... ... @@ -354,10 +354,10 @@
354 354  
355 355  MoSCoW的缩写代表：
356 356  
357 -* 必须（Must）具备的需求对成功至关重要
358 -* 应该（Should）具备的需求对成功很重要，但不是必需的
359 -* 可以（Could）具备的需求是合乎需要的，但不是重要或必要的
360 -* 不需要（Won’t）需求对于成功是不必需的、不适当的或非关键的
358 +* **必须（Must）**具备的需求对成功至关重要
359 +* **应该（Should）**具备的需求对成功很重要，但不是必需的
360 +* **可以（Could）**具备的需求是合乎需要的，但不是重要或必要的
361 +* **不需要（Won’t）**需求对于成功是不必需的、不适当的或非关键的
361 361  
362 362  该方法涵盖了不会被交付的需求。这很有用，因为列表通常填充了不必要的需求，例如无人需要的报告。这些需求增加了成本，却没有增加价值。
363 363  
... ... @@ -366,34 +366,30 @@
366 366  
367 367  在寻找供应商时，组织通常会公布服务或服务组件的需求，并邀请潜在的合作伙伴和供应商做出回应。根据需求或上下文，此活动可描述为：
368 368  
369 -● 报价请求单（RFQ），当定义了需求并确定优先级，同时组织需要以下信息时，可以使用此技术：
370 +* **报价请求单（RFQ）**，当定义了需求并确定优先级，同时组织需要以下信息时，可以使用此技术：
371 +** 供应商如何满足要求
372 +** 满足已公布的需求可能需要的成本
373 +* **征求建议书（RFP**），当问题或挑战陈述已明确表述，但服务组件的确切要求或规范不明确或可能更改时，使用此技术。供应商需要提供建议或可行的解决方案，明确收益、成果以及成本。
374 +* **信息请求单（RFI）**，当需求不明确或不完整且需要外部协助来完善或添加需求时，可使用此技术，RFI之后通常是RFQ或RFP。
370 370  
371 -●供应商如何满足要求
372 -
373 -●满足已公布的需求可能需要的成本
374 -
375 -● 征求建议书（RFP），当问题或挑战陈述已明确表述，但服务组件的确切要求或规范不明确或可能更改时，使用此技术。供应商需要提供建议或可行的解决方案，明确收益、成果以及成本。
376 -
377 -● 信息请求单（RFI），当需求不明确或不完整且需要外部协助来完善或添加需求时，可使用此技术，RFI之后通常是RFQ或RFP。
378 -
379 379  在某些情况下，组织在寻找合适的供应商时，可以让内部IT团队作为供应商参与进来。这种方法允许组织将内部IT与外部组织进行比较。但是，如果发生这种情况，重要的是：
380 380  
381 -● 认识到关系的差异，并确保不会将同事视为供应商
378 +* 认识到关系的差异，并确保不会将同事视为供应商
379 +* 了解到内部IT运营模式与更广泛的组织具有相同的特征、优势、劣势、机会和威胁
380 +* 在通常成本较高的内部资源与有共享知识和目标的更广泛组织的资源之间取得平衡。
382 382  
383 -● 了解到内部IT运营模式与更广泛的组织具有相同的特征、优势、劣势、机会和威胁
384 -
385 -● 在通常成本较高的内部资源与有共享知识和目标的更广泛组织的资源之间取得平衡。
386 -
387 387  理想情况下，供应商应反映组织的愿景、使命、道德和原则，从而最大程度地减少连个团队之间的摩擦和分歧。在许多情况下，供应商可以看作是组织品牌的延申。在整个选择过程中考虑并记住这一点至关重要。
388 388  
384 +(% class="box" %)
385 +(((
386 +(% id="cke_bm_348S" style="display:none" %)** **(%%)**ITIL 故事: “构建和采购”注意事项**
389 389  
390 -**ITIL 故事: “构建和采购”注意事项**
391 -
392 392  [[image:1640087848130-820.png||height="51" width="42"]]**弗朗西斯:**//我们的目标是每辆自行车都应该安全，可靠和舒适。自行车不一定要很快，但必须要有适应性。电动自行车必须具有良好的行驶距离，并且充电站必须尽可能地标准化。//
393 393  
394 394  //我们考虑过自己生产自行车，但是由于时间太长、成本高得令人望而却步，我们购买了现成的自行车，以最大限度地降低成本，并确保自行车可供试驾。在出租之前，我已经做好了准备。//
395 395  
396 396  //我们使用现成的GPS装置，该装置易于采购但是仅具有非常基本的功能。我们不希望使用第三方供应商的免费应用程序来收集数据，以防软件被撤消或供应商修改成本模型。我们计划开发自己的GPS地图软件。//
393 +)))
397 397  
398 398  
399 399  === 5.2.2 采购模型和选择 ===
... ... @@ -428,23 +428,25 @@
428 428  
429 429  特常见的采购模型包括：
430 430  
431 -* 内包：利用组织的现有资源来创建、交付和支持服务组件
432 -* 外包：组织将交付特定输出、成果、功能或整个产品或服务的责任转移给供应商，例如：
428 +* **内包**：利用组织的现有资源来创建、交付和支持服务组件
429 +* **外包**：组织将交付特定输出、成果、功能或整个产品或服务的责任转移给供应商，例如：
433 433  ** 使用本地数据中心供应商提供计算和存储资源
434 434  ** 通过中介机构寻找公开职位的候选人或寻找承包商
435 435  
436 436  外包模式可以根据供应商或其资源的位置进一步细分。在描述许多技术供应商或云计算服务提供商（基础设施即服务、软件即服务等）时，这种分类可能不适用，因为供应商资源的物理位置并不总是公开的。供应商位置分为三类：
437 437  
438 -* 在岸供应商在同一国家/地区。
439 -* 近岸供应商位于不同的国家或大陆，但是时区差异很小（例如，英国组织使用欧洲大陆的供应商）。
440 -* 离岸供应商位于不同的国家或大陆，通常距离组织有几个时区（例如，美国组织使用印度的供应商）。
435 +* **在岸 **供应商在同一国家/地区。
436 +* **近岸 **供应商位于不同的国家或大陆，但是时区差异很小（例如，英国组织使用欧洲大陆的供应商）。
437 +* **离岸 **供应商位于不同的国家或大陆，通常距离组织有几个时区（例如，美国组织使用印度的供应商）。
441 441  
442 442  在外包工作时，将工作转移到供应商后剩余的组织资源称为“被保留组织”
443 443  
444 -
441 +(% class="box" %)
442 +(((
445 445  **ITIL 故事: 采购模型和选择**
446 446  
447 447  [[image:1640088084574-355.png||height="49" width="35"]]**弗朗西斯:**//虽然我们本可以在网上买到更便宜的自行车，但我还是有意识地从当地一家自行车商店采购自行车。这种采购模型有助于确保实现我们的目标。购买前，我可以检查自行车的可靠性和安全性。该商店提供当日服务，这意味着如果需求持续增长，我可以迅速扩大我们的车队。我们还将与合作伙伴签订服务合同，以应对任何故障或安全问题方面的问题。//
446 +)))
448 448  
449 449  
450 450  === 5.2.3 外包注意事项 ===
... ... @@ -461,7 +461,8 @@
461 461  * 组织与供应商之间的文化或语言差异
462 462  * 外包工作时是否会增加以及将增加多少管理费用
463 463  
464 -
463 +(% class="box" %)
464 +(((
465 465  **ITIL 故事: 外包注意事项**
466 466  
467 467  [[image:1640088196437-821.png||height="64" width="42"]]**索尔马兹:**//我们已向七个供应商发布了开发GPS地图软件的报价请求单（RFQ）。//
... ... @@ -471,8 +471,10 @@
471 471  [[image:1640088212979-431.png||height="57" width="36"]]**亨利:**//当外包诸如软件开发之类的服务时，供应商的位置并不像其他服务那样重要，因为我们可以把测试和发布代码过程虚拟化。对于其他服务，例如现场支持，位置是一个显而易见的考虑因素。//
472 472  
473 473  [[image:1640088220614-694.png||height="51" width="39"]]**因杜:**//我们确实必须考虑外包应用程序开发会带来哪些额外的管理开销和风险。重要的是，我们要对这些情况进行监控，以确保开发的成本和时间不会超过预期水平。//
474 +)))
474 474  
475 475  
477 +
476 476  === 5.2.4 服务集成和管理 ===
477 477  
478 478  服务集成和管理是指组织在价值流中管理和集成多个供应商的方法。这对外包服务和供应商来说是一个新的挑战，以前，多个第三方供应商的端到端所有权和协调是由一个实体管理的。
... ... @@ -484,10 +484,10 @@
484 484  
485 485  这个部分有四个主要模型（图5.2）。组织必须依据自己的情况考虑最佳模型，以便转变到更加协调的服务-供应商关系：由于多种因素，服务集成和管理的重要性日益提高：
486 486  
487 -* 保留服务集成，被保留组织管理所有供应商，并协调服务集成和管理功能本身
488 -* 单一供应商，一个供应商提供所有服务以及服务集成和管理功能。
489 -* 服务监管者，除了提供服务集成和管理功能，以及一个或多个交付功能之外，还管理其他供应商。
490 -* 服务集成作为服务，由供应商提供服务集成和管理功能并管理所有其他供应商，即使该供应商未向组织提供任何服务。
489 +* **保留服务集成**，被保留组织管理所有供应商，并协调服务集成和管理功能本身
490 +* **单一供应商**，一个供应商提供所有服务以及服务集成和管理功能。
491 +* **服务监管者**，除了提供服务集成和管理功能，以及一个或多个交付功能之外，还管理其他供应商。
492 +* **服务集成作为服务**，由供应商提供服务集成和管理功能并管理所有其他供应商，即使该供应商未向组织提供任何服务。
491 491  
492 492  由于多种因素，服务集成和管理的重要性日益提高：
493 493  
... ... @@ -524,7 +524,9 @@
524 524  ** 变更管理
525 525  ** 服务请求
526 526  
527 -**ITIL 故事: 服务集成和管理**
529 +(% class="box" %)
530 +(((
531 +(% id="cke_bm_393S" style="display:none" %)** **(%%)**ITIL 故事: 服务集成和管理**
528 528  
529 529  [[image:1640088313890-721.png||height="68" width="39"]]**索尔马兹: **//艾克苏与世界各地的众多合作伙伴合作。一些服务由全球合作伙伴提供；例如，我们的IT网络基础设施。其他服务，如我们的电动自行车故障排查服务，是专门针对蒙特勒分公司和我们的自行车租赁服务。为了支持我们的产品和服务，我们有责任有效协调和整合不同第三方所做的工作。//
530 530  
... ... @@ -531,6 +531,7 @@
531 531  [[image:1640088322398-857.png||height="61" width="36"]]**雷尼: **//我们将为租用的自行车提供的服务之一是，如果自行车发生故障，我们将提供免费接送服务。为了使它有效运转，我们需要在IT网络（其提供方位于美国）、支持中心（从其在印度的办事处提供电话支持）、蒙特勒的故障小组（受理这些电话业务）和当地的拖车合作伙伴（负责收集自行车）之间进行协调。这些组织中的每一个对于服务的有效性都至关重要。我们需要确保供应商的地点、语言、时区和工作方式的任何差异都得到妥善管理，以便该服务可以平稳运行。//
532 532  
533 533  [[image:1640088313890-721.png||height="68" width="39"]]**索尔马兹: **//目前，艾克苏负责协调我们的供应商，使其成为“保留的服务集成商”。随着服务在其他地方的增长和扩展，我们将重新审视我们的服务集成模型，以确保它仍然适用。//
538 +)))
534 534  
535 535  
536 536  == 5.3 总结 ==
... ... @@ -540,3 +540,6 @@
540 540  组织在使用这些技术时应谨慎对待，并应用系统性思考和工作的指导原则，来评估这些技术对组织其他部分、客户、利益干系人，甚至对从需求到价值流的影响。
541 541  
542 542  组织也可以求助于外部合作伙伴和供应商，以获得额外的能力，甚至转移交付输出、成果、职能或整个服务的责任。随着合作伙伴和供应商数量的增加，指导和协调外部活动的管理开销可能会急剧增加，通常需要专用的资源来集成、管理外部供应商，并使其与组织的产品和服务保持一致。
548 +
549 +
550 +[[阅读下一章>>http://itil4hub.cn/bin/view/ITIL%204%E3%80%8A%E5%88%9B%E5%BB%BA%E3%80%81%E4%BA%A4%E4%BB%98%E5%92%8C%E6%94%AF%E6%8C%81%E3%80%8B%20CDS/%E7%AC%AC6%E7%AB%A0%20%E7%BB%93%E8%AE%BA/]]  [[返回上一章>>http://itil4hub.cn/bin/view/ITIL%204%E3%80%8A%E5%88%9B%E5%BB%BA%E3%80%81%E4%BA%A4%E4%BB%98%E5%92%8C%E6%94%AF%E6%8C%81%E3%80%8B%20CDS/%E7%AC%AC4%E7%AB%A0%20%E5%88%9B%E5%BB%BA%E3%80%81%E4%BA%A4%E4%BB%98%E5%92%8C%E6%94%AF%E6%8C%81%E6%9C%8D%E5%8A%A1%E7%9A%84%E4%BB%B7%E5%80%BC%E6%B5%81/]]
深圳市艾拓先锋企业管理咨询有限公司