Changes for page 第5章 设定工作优先级和管理供应商

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

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
...	...	@@ -267,37 +267,33 @@
267	267
268	268	服务提供者可以选择自己创建服务组件，或者从合作伙伴或供应商处获取。
269	269
270		-● 供应商是一个向消费者提供产品和服务，但与消费者没有共同目标的组织。
	270	+重要的是要记住：
271	271
272		-●“提供方”是一个通用术语，通常用于描述向客户销售产品或服务的任何组织。从服务消费者的角度来看，提供方可以是合作伙伴或供应商，也可以与服务消费者没有直接的服务关系。提供方还可以在某些领域成为合作伙伴，而在其他领域成为供应商，例如：
	272	+* 合作伙伴(partner)是向消费者提供产品和服务并与其消费者密切合作以实现共同目标和目的的组织。
	273	+* 供应商(supplier)是一个向消费者提供产品和服务，但与消费者没有共同目标的组织。
	274	+* “提供方(Vendor)”是一个通用术语，通常用于描述向客户销售产品或服务的任何组织。从服务消费者的角度来看，提供方可以是合作伙伴或供应商，也可以与服务消费者没有直接的服务关系。提供方还可以在某些领域成为合作伙伴，而在其他领域成为供应商，例如：
	275	+** 云服务提供方可以为消费者提供基础架构服务，但也可以与该消费者合作实施工具，使消费者能最大限度地利用这些服务。
	276	+** 客户服务提供方可以向消费者提供熟练的人员、工具和其他资源，但也可以与消费者合作进行营销活动，突出其客户服务的质量。
273	273
274		-● 云服务提供方可以为消费者提供基础架构服务，但也可以与该消费者合作实施工具，使消费者能最大限度地利用这些服务。
	278	+本节提出通用术语“服务组件（service components）”，可以涵盖人员、工具、信息或用于创建、交付或支持产品和服务的任何其他类型资源。本节提出术语“组织”来泛指服务的购买者或消费者，使用术语“提供方”来泛指服务的提供者。
275	275
276		-● 客户服务提供方可以向消费者提供熟练的人员、工具和其他资源，但也可以与消费者合作进行营销活动，突出其客户服务的质量。
277		-
278		-本节提出通用术语“服务组件”，可以涵盖人员、工具、信息或用于创建、交付或支持产品和服务的任何其他类型资源。本节提出术语“组织”来泛指服务的购买者或消费者，使用术语“提供方”来泛指服务的提供者。
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" %)