Last modified by superadmin on 2024/04/03, 16:11
From version < 19.5 >
edited by roll tech
on 2022/08/05, 18:43
To version < 19.7 >
edited by roll tech
on 2022/08/05, 18:50
< >
Change comment: There is no comment for this version

Summary

Details

Icon Page properties
Content
... ... @@ -275,29 +275,25 @@
275 275  ** 云服务提供方可以为消费者提供基础架构服务，但也可以与该消费者合作实施工具，使消费者能最大限度地利用这些服务。
276 276  ** 客户服务提供方可以向消费者提供熟练的人员、工具和其他资源，但也可以与消费者合作进行营销活动，突出其客户服务的质量。
277 277  
278 -本节提出通用术语“服务组件”，可以涵盖人员、工具、信息或用于创建、交付或支持产品和服务的任何其他类型资源。本节提出术语“组织”来泛指服务的购买者或消费者，使用术语“提供方”来泛指服务的提供者。
278 +本节提出通用术语“服务组件（service components）”，可以涵盖人员、工具、信息或用于创建、交付或支持产品和服务的任何其他类型资源。本节提出术语“组织”来泛指服务的购买者或消费者，使用术语“提供方”来泛指服务的提供者。
279 279  
280 280  组织仅使用其现有资源来创建产品和服务的情况越来越少，于是组织经常不得不决定是构建还是购买服务组件。这些决定应以数据和事实为依据，而不要依靠情绪、传言或未经证实的报道。为了应对日益复杂的决策，许多组织，特别是大型企业采用了正式的采购策略，其中考虑了以下因素：
281 281  
282 -●组织当前和未来的采购需求
282 +* 组织当前和未来的采购需求
283 +* 采购服务组件的当前成本和预估的未来成本（通常考虑总体拥有成本）
284 +* 生态系统中的资源稀缺性
285 +* 生态系统内竞争、供应商和客户的影响阻碍新供应商出现的壁垒，以及防止现有供应商倒闭的措施
286 +* 从多家供应商处采购组件的成本和风险
283 283  
284 -● 采购服务组件的当前成本和预估的未来成本（通常考虑总体拥有成本）
285 -
286 -●生态系统中的资源稀缺性
287 -
288 -●生态系统内竞争、供应商和客户的影响阻碍新供应商出现的壁垒，以及防止现有供应商倒闭的措施
289 -
290 -● 从多家供应商处采购组件的成本和风险
291 -
292 292  这些考虑因素用于形成采购策略，以及关于如何采购每种类型的服务组件的相关计划和模型。
293 293  
294 294  
295 -=== 5.2.1 “构建和采购”注意事项 ===
291 +=== 5.2.1 “建造与购买”的考虑 ===
296 296  
297 -重要的是要认识到以下因素引起的偏差或压力：
293 +认识到以下因素引起的偏差或压力很重要：
298 298  
299 299  * 熟悉工具的先前版本或工具供应商的产品和服务
300 -* 在没有确认环境15差异的情况下，使用关于产品和服务的先前经验
296 +* 在没有确认环境^^15^^差异的情况下，使用关于产品和服务的先前经验
301 301  * 强烈希望使用新工具或技能而仅因为它们是新的
302 302  * 供应商的积极销售战术
303 303  * 降低成本的压力，通常以质量为代价
... ... @@ -324,7 +324,7 @@
324 324  
325 325  ==== 5.2.1.1 商品化 ====
326 326  
327 -随着采用的技术不断增多，通常需要通过更高级的工具来更有效地管理技术17。例如：
323 +随着采用的技术不断增多，通常需要通过更高级的工具来更有效地管理技术^^17^^。例如：
328 328  
329 329  * 随着数据中心的使用越来越普遍，以及计算能力的提高，出现了用于管理虚拟基础架构的虚拟化工具。
330 330  * 随着算力和存储成本的下降以及虚拟化工具的成熟，云计算模型（基础架构即服务）应运而生。
... ... @@ -360,10 +360,10 @@
360 360  
361 361  MoSCoW的缩写代表：
362 362  
363 -* 必须（Must）具备的需求对成功至关重要
364 -* 应该（Should）具备的需求对成功很重要，但不是必需的
365 -* 可以（Could）具备的需求是合乎需要的，但不是重要或必要的
366 -* 不需要（Won’t）需求对于成功是不必需的、不适当的或非关键的
359 +* **必须（Must）**具备的需求对成功至关重要
360 +* **应该（Should）**具备的需求对成功很重要，但不是必需的
361 +* **可以（Could）**具备的需求是合乎需要的，但不是重要或必要的
362 +* **不需要（Won’t）**需求对于成功是不必需的、不适当的或非关键的
367 367  
368 368  该方法涵盖了不会被交付的需求。这很有用，因为列表通常填充了不必要的需求，例如无人需要的报告。这些需求增加了成本，却没有增加价值。
369 369  
... ... @@ -372,24 +372,18 @@
372 372  
373 373  在寻找供应商时，组织通常会公布服务或服务组件的需求，并邀请潜在的合作伙伴和供应商做出回应。根据需求或上下文，此活动可描述为：
374 374  
375 -● 报价请求单（RFQ），当定义了需求并确定优先级，同时组织需要以下信息时，可以使用此技术：
371 +* **报价请求单（RFQ）**，当定义了需求并确定优先级，同时组织需要以下信息时，可以使用此技术：
372 +** 供应商如何满足要求
373 +** 满足已公布的需求可能需要的成本
374 +* 征求建议书（RFP），当问题或挑战陈述已明确表述，但服务组件的确切要求或规范不明确或可能更改时，使用此技术。供应商需要提供建议或可行的解决方案，明确收益、成果以及成本。
375 +* 信息请求单（RFI），当需求不明确或不完整且需要外部协助来完善或添加需求时，可使用此技术，RFI之后通常是RFQ或RFP。
376 376  
377 -●供应商如何满足要求
378 -
379 -●满足已公布的需求可能需要的成本
380 -
381 -● 征求建议书（RFP），当问题或挑战陈述已明确表述，但服务组件的确切要求或规范不明确或可能更改时，使用此技术。供应商需要提供建议或可行的解决方案，明确收益、成果以及成本。
382 -
383 -● 信息请求单（RFI），当需求不明确或不完整且需要外部协助来完善或添加需求时，可使用此技术，RFI之后通常是RFQ或RFP。
384 -
385 385  在某些情况下，组织在寻找合适的供应商时，可以让内部IT团队作为供应商参与进来。这种方法允许组织将内部IT与外部组织进行比较。但是，如果发生这种情况，重要的是：
386 386  
387 -● 认识到关系的差异，并确保不会将同事视为供应商
379 +* 认识到关系的差异，并确保不会将同事视为供应商
380 +* 了解到内部IT运营模式与更广泛的组织具有相同的特征、优势、劣势、机会和威胁
381 +* 在通常成本较高的内部资源与有共享知识和目标的更广泛组织的资源之间取得平衡。
388 388  
389 -● 了解到内部IT运营模式与更广泛的组织具有相同的特征、优势、劣势、机会和威胁
390 -
391 -● 在通常成本较高的内部资源与有共享知识和目标的更广泛组织的资源之间取得平衡。
392 -
393 393  理想情况下，供应商应反映组织的愿景、使命、道德和原则，从而最大程度地减少连个团队之间的摩擦和分歧。在许多情况下，供应商可以看作是组织品牌的延申。在整个选择过程中考虑并记住这一点至关重要。
394 394  
395 395  (% class="box" %)
深圳市艾拓先锋企业管理咨询有限公司